چرخه‌ی تولیدِ یک محصول نرم‌افزاری به چهار بازه‌ی زمانی به نامِ «فاز» تقسیم میشود:
فازِ استارتاپ
فازِ معماری
فازِ ساخت
فازِ انتقال.
این چرخه با انتشارِ یک فراورده‌ی نرم‌افزاریِ کامل پایان می‌پذیرد.
به طور کلی در رادنت، چرخه‌ی توسعه یا تولید فراورده‌ی نرم‌افزاری دارای دو مرحله‌ی اصلی می‌باشد. این مراحل عبارتند از:
مرحله‌ی مهندسی رادنت، شامل فازهای استارتاپ (آغاز) و معماری
مرحله‌ی فرآوری رادنت، شامل فازهای ساخت و انتقال
یادآور می شویم که چارچوب فرایند توسعه‌ی نرم‌افزار اساساً رویکردی است تکرارشونده (iterative) و مبتنی بر ریسک (risk-driven).
درست است که در هفته‌ها یا ماه‌های اوّلِ یک پروژه در رادنت، تأکید بیشتری بر شناخت نیازمندی‌ها داریم و در طی هفته‌ها یا ماه‌های آخر، تست و رفع نواقص در اولویت قرار می‌گیرد، اما این موضوع منطقاً به دلیل ماهیت نیازها و ریسک‌های موجود در یک پروژه می‌باشد. مهمترین ریسک در شروع یک پروژه، درک و شناخت اَبعاد و ماهیّت مسأله و راه‌حل یا راه‌حل‌های ممکن می‌باشد. قسمت عمده‌ای از این شناخت و درک از طریق تمرکز بر نیازمندی‌ها بدست می‌آید اّما ممکن است بنا به شرایط مسأله، حصول اطمینان از درک کامل ماهیّت مسأله و راه‌کارهای مطلوبِ آن و نیز اثباتِ به‌صرفه‌بودن انجام آن، مستلزم انجام فعالیت‌های متنوع دیگری نیز باشد و لذا در فاز استارتاپ ممکن است هر یک از فعالیت‌های مختلف تولید نرم‌افزار، اَعَم از تحلیل و طراحی، پیاده‌سازی، تست، و حتی استقرار انجام شود.
بعد از اثبات صحّتِ شناخت و مقرون به صرفه بودن تولید فراورده، مدیریت ریسک‌های فنی در اولویت قرار می‌گیرد. در فاز معماری که فاز دوم از فرآیند توسعه‌ی نرم‌افزار می‌باشد، عمده‌ی ریسک‌های فنی به کمک طراحی، پیاده‌سازی، و تستِ معماری رفع می‌شوند. در این فاز، به‌طور معمول، فعالیت‌های تحلیل و طراحی درصد بیشتری از فعالیت‌ها را به خود اختصاص می‌دهند ولی کماکان فعالیت‌های مرتبط با شناخت نیازمندی‌ها، پیاده‌سازی، تست، و استقرار هم انجام می‌شوند.
پس از اینکه معماری تثبیت شد و کارایی آن به اثبات رسید، نوبت به ساخت و بنا نمودنِ سیستم است. همانگونه که در ساخت یک ساختمان به‌طور معمول فعالیت‌های بنّایی حجم زیادی از مرحله‌ی ساخت را به خود اختصاص می‌دهند، مسلماً بیشتر فعالیت‌های ساختِ یک نرم‌افزار نیز به برنامه‌نویسی و تست کارشناسان رادنت اختصاص دارد. اما سایر فعالیت‌های لازم برای تکمیل ساخت یک نرم‌افزار مانند تکمیل نیازمندی‌ها، تحلیل، طراحی، و استقرار نیز انجام میشود. بنابراین در فاز سوم که کم‌کم به انتهای پروژه نزدیک می‌شویم، حجم فعالیت‌های برنامه‌نویسی و تست بیشتر خواهد شد.
در فاز نهایی که فاز اِنتقال نام دارد، برای اِنتقال سیستمِ آماده‌شده از رادنت به محیط مشتری، تدابیر لازم اتخاذ میشود. در طولِ این فاز، برای اطمینان از بی‌نقص بودن و تحویل کامل نرم‌افزار به مشتری، آخرین تست‌ها و بررسی‌های لازم روی نرم‌افزار انجام میشود. در این فاز هم ممکن است که کماکان پیاده‌سازی مختصری داشته باشیم. حتی، فعالیت‌های مربوط به نیازمندی‌ها، تحلیل، و طراحی نیز ممکن است انجام شود. اما به طور منطقی فعالیت‌های مرتبط با تست و استقرار بیشترین حجم را به خود اختصاص می‌دهند.
فاز استارتاپ (Inception):
اولین فاز از مرحله‌ی مهندسی در چرخه‌ی توسعه‌ی یک سیستم نرم‌افزاری و نقطه‌ی شروع پروژه است.
اهداف فازِ استارتاپ (آغاز):
به‌طور کلی، هدفِ اصلی این فاز، رفع و تسکینِ ریسک‌های کلانِ سازمانی (مخاطرات کسب‌وکار)، ریسک‌های مربوط به درک اهداف و محدوده‌ی پروژه، و نیز به دست آوردن اطلاعات کافی برای اطمینان از ادامه‌ی پروژه و یا توقف آن می‌باشد.
پنج هدفِ اصلی فازِ استارتاپ در رادنت، عبارتند از:
۱٫رسیدن به درک مناسبی از راهکاری که باید در طولِ فرایندِ توسعه ایجاد شود. تعیین چشم‌انداز (ویژن) و محدوده و مرز سیستم، بایدها و نبایدهای سیستم، آنچه در درون سیستم قرار می‌گیرد و آنچه در بیرون آن، شناسایی کسانی که سیستم را می‌خواهند و اینکه سیستم چه ارزش و جایگاهی برای آنان دارد.
۲٫شناسایی وظیفه‌مندی‌ها و کارکردهای کلیدی سیستم.
۳٫تعیین حداقل یک راهکار ممکن با مشخص‌کردن حداقل یک معماری کاندید.
۴٫درک هزینه، زمان، و ریسک‌های مرتبط با پروژه.
تصمیم‌گیری درباره‌ی فرایند مناسب و نیز ابزارهای مورد نیاز (برخی از جزئیات مرتبط با فرایند، از جمله فعالیت‌ها و دستاوردها در این فاز مشخص میشود).
می‌دانیم که درک کاملِ ابعاد، اهداف، و چیستیِ مسأله، معادلِ حلِ نیمی از آن می‌باشد. تیم توسعه‌ی محصول رادنت در فازِ استارتاپ، تمام نیرو و توانِ خود را صرف درک مسأله می‌نماید. ممکن است در یک پروژه‌ی کوچک، این کار با یک مشاهده و مصاحبه‌ی ساده، انجام شود ولی در پروژه‌های بزرگ به اقداماتی فَرایِ شناختِ نیازمندی‌ها نیاز داریم. در یک پروژه‌ی بزرگ ممکن است فازِ آغازین یکی دو ماه به طول بیانجامد. با این توصیف، فاز استارتاپ تفاوت‌های بسیاری با فازِ اولِ رویکردِ آبشاری (یعنی همان به اصطلاح فازِ شناخت) دارد.
فاز معماری (Elaboration Phase):
دوّمین فاز از چرخه‌ی تولید فراورده‌های نرم‌افزاری است که آخرین فاز از مرحله‌ی مهندسی است.
این فاز به مایلستون (نقطه‌ی تصمیم‌گیری) در رابطه با تثبیتِ معماری ختم میشود. در این فاز، غلبه بر ریسک‌های فنی با تثبیت و مبنا قرار دادنِ معماری سیستم، امکان‌پذیر میشود.
در این فاز، معماری سیستم مطلوب با توجه به نیازمندی‌هایی که از نظر معماری، قابل ملاحظه می‌باشند (یا به اصطلاح، نیازمندی‌های معماری‌گونه) و نیز بر اساس ارزیابی ریسک‌ها، و نیز ملاحظاتی مانندِ محدودیت‌های هزینه و زمان، شکل گرفته و پس از انجامِ تست و آزمون‌های لازم، تثبیت میشود.
اهداف فاز معماری :
درک جزئیاتِ بیشتری از نیازمندی‌ها
طراحی، پیاده‌سازی، اعتبار سنجی، و مبنا قرار دادنِ (تثبیت) معماری
تسکین ریسک‌های عمده و بهبود تخمین‌های هزینه و زمانِ پروژه
پالایش قالب و الگوی فرایند تولید و آماده‌سازی بستر، محیط، و ابزارهای مناسب فازِ تشریح (معماری) و تکراره
فاز ساخت:
سومین فاز از چرخه‌ی تولید فراورده‌های نرم‌افزاری، و اولین فاز از مرحله‌ی فرآوری در چارچوب فرایند توسعه است. با پایان یافتن فازهای استارتاپ و معماری، مرحله‌ی مهندسی خاتمه‌یافته و اکنون با ورود به فازِ ساخت، وارد مرحله‌ی فرآوری خواهیم شد.
این فاز معمولاً طولانی‌ترین و در عین حال قابل انعطاف‌ترین فاز در چارچوب فرایند توسعه است. مهمترین ریسک‌های موجود در فازِ ساخت، ریسک‌های به اصطلاح لُجستیکی‌اند.
بخش عمده و قابل توجهی از حجم کاری پروژه در فاز ساخت انجام میشود. بنابراین، بهتر است حتماً با یک معماری تثبیت‌شده پا به این فاز بگذاریم؛ در غیر این صورت، هزینههای زیادی را که عمدتاْ ناشی از دوبا‌ره‌کاری و انجام کارهای زاپد است، باید متحمّل شویم.
توجه داشته باشید که ممکن است براساس واقعیت‌هایی که یک معماری پیاده‌سازی‌شده و قابل اجرا نشان می‌دهد، تصمیم بر عدمِ ورود به فازِ ساخت و بستن پروژه بگیریم. عدمِ تثبیت مناسبِ معماری سبب بروز دوباره‌کاری‌های زیادی در فازِ ساخت میشود.
بیشتر حجمِ کار در فازِ ساخت، مربوط به پیاده‌سازی، تست، و نیز طراحی تفصیلی و دقیق‌تر کردن نیازمندی‌ها می‌باشد. در اواخر این فاز که سیستم تقریباً در حال شکل‌گیری و کامل‌شدن می‌باشد، فعالیت‌های مرتبط با استقرار نیز حجم کاری زیادی خواهند داشت. فعالیت‌های مرتبط با مدیریت پیکره‌بندی و تغییرات، بیشترین حجم کاری را نسبت به فازهای قبل داشته و تقریباً در تمام طول این فاز به‌طور ثابت مورد توجه است.
در حقیقت، معمولاً فاز ساخت زمان زیادی از پروژه را به خود اختصاص می‌دهد. به طور متوسط در حدود ۶۵ درصد از کلِ حجم فعالیت‌ها و حدود ۵۰ درصد از زمان کلی پروژه به این فاز اختصاص دارد.
رادنت در طول فازِ ساخت به تولید کدهای با کیفیت مطلوب و مقرون به‌صرفه تمرکز دارد، می‌توانیم با استفاده از مکانیزم‌ها (سازوکارهای) معماری تولیدِ کد را تسریع نماییم. خصوصاً در پروژه‌های بزرگ، اطمینان از تمامیّت و یکپارچگی معماری، توسعه به صورت موازی و همروند، مدیریت منسجم پیکره‌بندی و تغییرات، و خودکارسازیِ تست (آزمون)، جزء ضروریات پروژه برای دستیابی به موفقیت محسوب می‌شوند. معماری نرم‌افزار نقش بسیار مهم و تعیین کننده‌‌ای در دستیابی به اهداف مدنظر در فازِ ساخت ایفا می‌نماید. بنابراین هرچه معماری دقیق‌تر و تثبیت‌شده‌تر باشد، احتمال موفقیت بیشتر میشود.
اهدافِ فازِ ساخت :
۱٫کمینه‌کردن هزینههای تولید و بهره‌گیری مناسب از اِمکانِ توسعه به صورت موازی و همروند.
۲٫توسعه‌ی تدریجی و تکرارشونده‌ی یک فراورده‌ی کامل که آماده‌ی انتقال به محیط کاربران است.
فاز انتقال (Transition):
چهارمین و در واقع آخرین فاز از چرخه‌ی توسعه‌ی سیستم‌های نرم‌افزاری و آخرین فاز از مرحله‌ی فراوری است.
در انتهایِ این فاز، فراورده‌ی نرم‌افزاری به‌طور کامل به محیط مشتری و کاربران اِنتقال‌یافته و تمام کاربران نهاییِ سیستم قادر خواهند بود تمامی خدمات مورد نیازشان را بدون نیاز به حضور مستمر تولید‌کنندگان نرم‌افزار، از سیستم مستقرشده دریافت نمایند؛ پروژه به طور کامل بسته‌شده و سیستم نرم‌افزاری به مرحله‌ی نگهداری و تکامل وارد میشود. پایانِ این فاز، معادلِ آخرین نقطه‌ی تصمیم‌گیری سازمانی در چرخه‌ی توسعه‌ی نرم‌افزار، یعنی انتشار فراورده (Product Release) است.
تمرکز اصلی فعالیت‌ها در فاز انتقال، بر این موضوع است که اطمینان یابیم، سیستمِ نرم‌افزاری تولید شده، به طورِ کامل نیازهای کاربرانش را برآورده می‌نماید. به‌طور معمول، در این فاز یک یا دو تکرار برنامه‌ریزی میشود که عمدتاً شاملِ تست (آزمون) فراورده‌ی نرم‌افزاری به‌منظور آماد‌سازی آن برای تحویل و نیز اِعمال تنظیمات و اصلاحات جزئی بر اساس بازخوردهای دریافت‌شده از کاربران است.
اهدافِ فازِ انتقال:
۱٫انجام آزمون‌های بِتـا به منظور تأیید اینکه سیستم پاسخ‌گوی انتظارات کاربران است.
۲٫آموزش کاربران و نگهدارندگان سیستم به منظور دستیابی به قابلیت خوداتکایی آنان. این دسته از فعالیت‌ها برای اطمینان از اینکه سازمان یا سازمان‌های پذیرنده‌ی نرم‌افزار، شرایط و قابلیت‌های به‌کارگیری اصولیِ سیستم را داشته باشند، انجام میشود.
۳٫آماده‌سازی محل استقرار و انتقال و کانورت بانک‌های اطلاعاتیِ عملیاتی. برای اینکه سیستم جدید با موفقیت را‌ه‌اندازی شود. ممکن است که لازم باشد سخت‌افزارهای جدیدی خریداری شود، فضای جدیدی برای سخت‌افزارهای جدید افزوده شده و یا داده‌های موجود در بانک‌های اطلاعاتی فعلی به قالب مناسب برای سیستم جدید تبدیل شود.
۴٫دستیابی به توافق تمام ذینفعان نسبت به اینکه نسخه‌های تثبیت‌شده در استقرار، کامل بوده و با معیارها و شرایط ارزیابی مورد بحث در چشم‌انداز پروژه، تطابق دارد.
