(هدف ۱) کمینه‌کردن هزینه‌های تولید

در تمام فازهای چرخه‌ی توسعه‌ی نرم‌افزار، در فکر تولید مقرون به‌صرفه‌ی فراورده‌ی نر‌م‌افزاری هستیم. اگر تنها در فاز ساخت به این موضوع بیاندیشیم، مسلماً شکست خواهیم خورد و به این هدف دست پیدا نخواهیم کرد. اگر فاز معماری به‌درستی انجام شده باشد، نتیجه‌ی آن ایجاد یک معماری قابل اِجرا، مستحکم، و تثبیت‌شده خواهد بود. بر اساس این معماری، قادر خواهیم بود یک راهکارِ مقرون‌به‌صرفه‌ ارائه نماییم. این اِمکان از آنجایی حاصل می‌شود که با داشتن چنین معماری‌ای، امکان استفاده‌ی مجدد از مکانیزم‌های معماری به‌وجود آمده و نیز قادر خواهیم بود با توجه به معماری، فعالیت‌های موازی را تعریف نماییم. در ضمن، با توجه به اینکه بسیاری از ریسک‌های عمده‌ی فنی به‌وسیله‌ی معماری رفع شده‌اند، به احتمال زیاد با مشکلات و چالش‌های کمتری روبرو خواهیم شد.

در ادامه، برخی ملاحظات مرتبط با فازِ ساخت را که تیم‌ها و پروژه‌های بزرگ برای موفقیت در تولید نرم‌افزار باید آنها را مدنظر قرار دهند، ذکر خواهیم نمود.

سازماندهی حول معماری

یکی از مهم‌ترین مزایای یک معماری تثبیت‌شده و مستحکم این‌ است که این معماری مسئولیت‌های سیستم‌ را در میان یک‌سری زیرسیستمِ به‌خوبی‌تعریف‌شده، تقسیم می‌نماید. در این صورت، یک معمار یا یک تیم معماری خواهیم داشت که نگران معماری و چگونگی حفظِ یکپارچگی و مجتمع‌سازی آن بوده و بقیه‌ی افراد بر زیرسیستم‌ یا زیرسیستم‌هایی که به آنها اختصاص یافته است، تمرکز خواهند داشت.
توجه داشته باشید که با وجود شکسته‌شدن مسئولیت‌های سیستم در قالب زیرسیستم‌ها، کلیه‌ی افراد در تیم‌های مختلف (اَعَم از تحلیل‌گران، طراحان، برنامه‌نویسان، کارشناسان تست، مدیران پروژه و …)، باید درک مناسبی از سرتاسر (کلیت) سیستم داشته باشند، اما تمرکز اصلی‌شان بر زیرمجموعه‌ی مشخصی از سیستم که متشکّل از یک یا چند زیرسیستم است، خواهد بود.

هنگامی که سازماندهی فعالیت‌ها حُولِ معماری صورت پذیرد، فعالیت‌های هیچ یک از افراد تیم با هم تداخل نخواهد داشت. سازماندهی حُولِ معماری به برقراری ارتباطات مناسب‌تر نیز کمک می‌کند. معمولاً ارتباطاتِ رو در رو مؤثرترین شکل ارتباطات است، اما با بزرگ‌تر شدن پروژه و یا توزیع جغرافیایی آن، به ناچار اِمکان برقراری ارتباطات رو در رو کمتر می‌شود.

مدیریت پیکره‌بندی

سیستم و زیرساخت مدیریت پیکره‌بندی (Configuration Management) عموماً در طولِ فاز استارتاپ نصب و راه‌اندازی شده و در فاز معماری همزمان با تثبیتِ معماری سیستم، بازبینی و تصحیح می‌شود. در اینجا مختصراْ چرایی و مزایای داشتن یک سیستم مدیریت پیکربندی را بررسی می‌نماییم.

با پیشرفت پروژه، به علّتِ افزایش میزان تغییرات اِعمالی در بسیاری از دستاوردها از جمله کد، پیگیری نسخه‌های مختلف از این دستاوردها، به شکل روزافزونی مشکل‌تر و پیچیده‌تر خواهد شد. خصوصاً، با داشتن رویکرد تکرارشونده، مستمراً نسخه‌های جدیدی از نرم‌افزار به وجود می‌آید و بنابراین لازم است که ابزار مناسبی برای موفقیت در هر یک از موارد و شرایط زیر، در اختیار داشته باشیم:

  • توسعه‌ی تکرارشونده (iterative development) به معنای ایجادِ نسخه‌های متعدد از سیستم نرم‌افزاری است. این نسخه‌ها حتی ممکن است به‌صورت روزانه ایجاد شوند. در این حالت، باید مشخص نماییم که چه نسخه‌ای از مؤلفه‌های مختلف در هر ساخت‌وسازِ میانی (build) استفاده خواهد شد. در برخی از موارد، نسخه‌ی نهایی از یک مؤلفه‌ی خاص و در مواردی نیز نسخه‌های قبلی آن که درستی عملکردشان اثبات‌شده یا به علت کامل‌نشدن نسخه‌ی نهایی، در ایجادِ نسخه‌ی جدید استفاده می‌شود.
  • در توسعه‌ی تکرارشونده، معمولاً راهکارهای مختلفی را برای دستیابی به نتایج مطلوب آزمایش می‌نماییم. در این صورت، لازم است محیط مناسبی برای مدیریت راهکارهای مختلف در طول مسیر وجود داشته باشد.
  • با بزرگ‌تر شدن حجم و ازدیادِ فعالیت‌های پروژه، برای جلوگیری از تداخل و ایجاد اثرات نامطلوب، ضروری خواهد بود که تغییرات ایجاد شده توسط یک تیم از دیدِ سایر تیم‌ها پنهان بماند. علاوه بر این، اعضای تیم‌ها نیز علاقمند به کنترل محیط کارشان می‌باشند.
  • در پروژه‌های بزرگ، باید افرادی را که اجازه‌ی اِعمال یک‌سری تغییرات خاص در پروژه را دارند، کنترل نماییم.
  • هنگامی که با یک خطا و اشتباه برخورد می‌نماییم، علاقمند هستیم که به عقب برگشته و خطا را ریشه‌یابی نماییم. در ضمن، بسیار ضروری است که بتوانیم به سرعت به نسخه‌های قبلی که تثبیت شده‌اند، دسترسی پیدا کرده و در صورت لزوم آنها را جایگزینِ سیستم مشکل‌دارِ فعلی نماییم.

راه‌حل مناسب، استفاده از یک سیستم مدیریت پیکره‌بندی است. بعد از اینکه چنین سیستمی راه‌اندازی شد، اعضای تیم نگرانِ هزاران فایل و دستاورد تهیه‌شده، نسخه‌های مختلف و نیز وابستگی و ارتباط میان آنها، نخواهند بود و بدین ترتیب قادر خواهند بود وقت بیشتری را به فعالیت‌های اصلی پروژه اختصاص دهند.

برنامه‌ریزی یکپارچه‌سازی

در رویکردِ تکرارشونده (iterative development)، یکپارچه‌سازی و تستِ یکپارچه‌سازی، بسیار پیچیده‌تر است. در هر تکرار، باید یک برنامه‌ی یکپارچه‌سازی (integration) داشته باشیم که بیانگر قابلیت‌هایی قابلِ تست (آزمون) در هر نسخه‌ از سازه‌ی میانی (build) به علاوه‌ی مؤلفه‌هایی که برای ارائه‌ی این قابلیت‌ها باید با هم تلفیق شوند، است. قابلیت‌های مورد نظر ممکن است یک یا چند موردِ کاربرد (use case)، قسمتی از مواردِ کاربرد و یا هر وظیفه‌مندی قابل تست (آزمون) دیگری، باشد. تست‌ها (آزمون‌ها) نیز ممکن است دربرگیرنده‌ی تست‌های وظیفه‌مندی، بارگذاری، فشار، و دیگر تست‌هاس (آزمون‌های) متداول باشد.

اجبار در به‌کارگیری و پایبندی به معماری

برای اینکه به طور کامل از مزایای معماری بهره‌مند شویم، لازم است که به طور فعّال، از پایبندی به آن اطمینان حاصل نماییم. در یک تیم کوچک، این کار با داشتن یک سری جلساتِ بحث در رابطه با طراحی معماری، امکان‌پذیر است. اما در تیم‌های بزرگ‌تر، دقت و دیسیپلین بیشتری لازم است.

اطمینان از به‌کارگیری مکانیزم‌های معماری که در قالبِ معماری سیستم، تعریف شده‌اند، پرهیز از اِبداعِ این مکانیزم‌ها توسط افراد تیم، و نیز اِطمینان از عدمِ تغییر دلخواهانه‌ی واسط‌ها (interfaces)، از دیگر نکات مهم در رابطه با معماری است. در این خصوص، ممکن است که لازم باشد همه‌ی افراد تیم، آموزش‌های لازم را درباره‌ی معماری و مکانیزم‌های موجود در آن ببینند.

اطمینان از پیشرفت مستمر

برای اطمینان از پیشرفت مستمر پروژه، باید ضمن قرار دادن اهداف میانی و کوتاه‌مدت در طول پروژه، به طور مستمر، دستیابی به آن اهداف را نیز اثبات نماییم. برای اطمینان از موفقیت باید به نکات ذیل توجه داشته باشید:

  • تنها یک تیم و با یک ماموریتِ واحد ایجاد نمایید. باید از ایجاد تیم‌های به اصطلاح تخصصی جدا مانند تیم تحلیل‌گران و یا تیم طراحان پرهیز شود. برای مثال داشتن یک تیم جداگانه‌ی تحلیل که پس از تکمیل نیازمندی‌های سیستم، دستاوردهای مربوط را در اختیار تیمی متشکل از طراحان و برنامه‌نویسان برای طراحی و پیاده‌سازی قرار می‌‌دهند و آنها نیز دستاوردهای خود را در اختیار تیمِ تست قرار می‌دهند، اصلاً توصیه نمی‌شود. در عوض، مناسب‌ترین و موفق‌ترین تیم‌ها، ترکیبی از تخصص‌های مختلف را در خود دارند؛ تیم‌هایی که در آنها هر یک از اعضای تیم، خود را در دستیابی به اهداف و پیشرفت کارِ تیم مسئول و پاسخگو می‌داند.
  • تعیین اهداف شفاف و قابل دستیابی برای افراد. هر یک از اعضای تیم باید تصویر روشنی از آنچه که در یک تکرار یا بخشی از آن، انجام خواهد شد و آنچه که حاصل می‌شود، داشته باشند. همه‌ی اعضای تیم باید درباره‌ی قابل دستیابی‌بودن نتایج با هم توافق داشته باشند.
  • آزمون و ارائه‌ی مستمر کدها و نسخه‌‌های اجرایی از نرم‌افزار. مهم‌ترین معیار برای سنجش میزان پیشرفت، نسخه‌ی قابل اجرای (executable) نرم‌افزار است.
  • اجبار در رابطه با یکپارچه‌سازی مستمر. در صورت امکان سازه‌های میانی (build) را به‌صورت روزانه ایجاد نمایید. البته، در پروژه‌های بزرگ و نیز در پروژه‌هایی که ابزارهای مناسب مدیریت پیکره‌بندی وجود ندارد، امکان ایجاد سازه‌های میانی به صورت روزانه، وجود نخواهد داشت. نتیجه‌ی مستقیمِ ایجاد نسخه‌هایی از سازه‌های میانی متعدّد، انجام یکپارچه‌سازی و تست مستمرِ یکپارچگی در طول پروژه است.

تماس با ما

در حال ارسال

Log in with your credentials

Forgot your details?