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

پایانِ فاز ساخت، متناظر با یکی دیگر از گام‌های اصلی (major milestone) یا نقاطِ تصمیم‌گیری سازمانی در چرخه‌ی توسعه‌ی نرم‌افزار است. این گامِ اصلی تحتِ عنوان گامِ رسیدنِ به «قابلیتِ عملیاتی آغازین» (Initial Operational Capability) یا «بِتا (beta)»، جایی است که اصطلاحاً نسخه‌ی بِتای سیستم (راهکار) ارائه می‌شود. نسخه‌ی بِتایِ یک فراورده‌ی نرم‌افزاری عبارت است از یک سیستمِ نرم‌افزاری که در آن تمام قابلیت‌های توصیف‌شده در نیازمندی‌ها و چشم‌انداز پروژه، پیاده‌سازی‌شده و سیستم آماده‌ی استقرار در محیطِ مشتری و کاربرانِ‌ ‌نهایی است. البتّه، ممکن است که هنوز اشکالات و نواقصی وجود داشته باشد که در طی تکرارهای فازِ بعد، یعنی فازِ اِنتقال، رفع خواهد شد.

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

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

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

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

در حقیقت، معمولاً فاز ساخت زمان زیادی از پروژه را به خود اختصاص می‌دهد. به طور متوسط در حدود ۶۵ درصد از کلِ حجم فعالیت‌ها و حدود ۵۰ درصد از زمان کلی پروژه به این فاز اختصاص دارد. توجه داشته باشید که این اعداد و ارقام در پروژه‌های مختلف متفاوت خواهد بود. ولی قدر مسلم اینکه به طور متوسط حجم زیادی از هزینه‌های پروژه در این فاز صرف می‌شود چه به لحاظ زمانی و چه به لحاظ مالی.

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

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

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

اهدافِ فازِ ساخت

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

  1. کمینه‌کردن هزینه‌‌های تولید و بهره‌گیری مناسب از اِمکانِ توسعه به صورت موازی و همروند.
    در این فاز سعی می‌شود که با هدف بهینه‌کردن منابع و پرهیز از دوباره‌کاری‌های غیر ضروری، هزینه‌های تولید اعم از هزینه‌های زمانی و مالی به کمترین مقدار ممکن تقلیل یابد. در ضمن با کمک معماری مبتنی بر مؤلفه، اِمکان توسعه‌ی موازی مؤلفه‌های مستقل از هم به وجود می‌آید و این خود تأثیر بسزایی بر کاهش هزینه‌های تولید و کم کردن زمان تولید خواهد داشت.
  2. توسعه‌ی تدریجی و تکرارشونده‌ی یک فراورده‌ی کامل که آماده‌ی انتقال به محیط کاربران است.
    اولین نسخه‌ی عملیاتی سیستم (تحت عنوان نسخه‌ی بِتـا) به وسیله‌ی توصیفِ مواردِ کاربرد، تشریح سایر نیازمندی‌های باقی‌مانده، تفصیل بیشتر جزئیات طراحی‌ها، تکمیل پیاده‌سازی، و تست نرم‌افزار ایجاد می‌شود. در ضمن، آماده‌بودنِ محل‌های راه‌اندازی و استقرار و نیز آمادگی کاربران برای کار با سیستم مورد بررسی قرار می‌گیرد.

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

فازِ ساخت و تکرارها

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

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

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

(مایلستون) بتا – ارائه‌ی اولین قابلیت‌های عملیاتی

فاز ساخت با یکی از مهم‌ترین گام‌های اصلی در پروژه خاتمه می‌یابد. این گام اصلی، به اصطلاح گامِ ارائه‌ی اولین قابلیت‌های عملیاتی یا گامِ بِتـا (Beta) نامیده می‌شود. در این گام، زمان تصمیم‌گیری درباره‌ی این موضوع است که آیا محصول آماده‌ی استقرار و تست در محیط کاربران می‌باشد یا نه. برای اتخاذ این تصمیم و خاتمه‌ی فازِ ساخت، باید پرسش‌های زیر را پاسخ داد:

  • آیا محصول به‌دست‌آمده به اندازه‌ی کافی پایدار‌ (stable) و کامل هست که بتوان آن‌را در محیط کاربر مستقر کرد؟
  • آیا همه‌ی ذینفعان آماده‌ی انتقالِ سیستم به محیط کاربر هستند؟
  • آیا برآمدِ هزینه‌ی منابع هنوز نسبت به برآورد برنامه‌ریزی‌شده، قابل قبول است؟

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

تماس با ما

در حال ارسال

Log in with your credentials

Forgot your details?