امکان‌سنجی
یکی از مهم‌ترین فرآیندها در ارتباط با ساخت نرم‌افزارها برآورد و تحلیل نیازمندی‌های سامانه هدف است. مشتریان به‌طور معمول تصور مفهومی، انتزاعی و مبهمی از خواسته خود دارند و در اغلب اوقات به درستی نمی‌دانند نرم‌افزار موردنظر آن‌ها باید چه ویژگی‌هایی داشته باشد و به چه قابلیت‌های کاربردی نیاز دارد. در این مرحله نیازمندی‌های مبهم، ناشناخته و حتا متضاد با ایده‌های اولیه توسط مهندسان نرم‌افزار مشخص می‌شوند. در این مرحله ممکن است یک نمونه کلی و اولیه که بیشتر یک نمونه مفهومی است برای مشتری آماده شود و تا شناخت کلی از محصولی که قرار است دریافت کند را به‌دست آورد. این‌کار بیشتر با هدف کم کردن ریسک‌ها و شناسایی دقیق نیازمندی‌ها انجام می‌شود. در این مرحله ابتدا نیازمندی‌های عمومی مشتریان جمع‌آوری می‌شود تا دامنه توسعه و تولید نرم‌افزار که باید ساخته شود شناسایی و تحلیل شود، در ادامه مستندات به شکل شفاف مکتوب می‌شوند. به‌طور معمول به این نوشته‌ها، مستند دامنه یا محدوده سامانه گفته می‌شود. برخی قابلیت‌ها ممکن است در ابتدای پروژه به خاطر مسائل مالی یا نیازمندی‌های غیر شفاف و نامشخص خارج از محدوده پروژه باشند. اگر تولید و توسعه نرم‌افزار برون‌سپاری شود (یعنی به شرکت‌های خارجی محول شود) این مستندات به عنوان مستندات قانونی و حقوقی در نظر گرفته می‌شود؛ بنابراین در صورت اتفاق هرگونه دعوای حقوقی یا ابهام در مورد تعهدات داده‌شده به کاربر، این مسائل قابل شفاف‌سازی خواهد بود.
پیاده‌سازی، آزمایش و مستندسازی
پیاده‌سازی به بخش مشخصی از روند ساخت نرم‌افزارها اشاره دارد که برنامه‌نویسان اقدام به کدنویسی پروژه می‌کنند. در این مرحله بر مبنای نیازمندی‌های استخراج شده و وایرفریم طراحی شده کدنویسان دست به کار می‌شوند و ماژول‌های نرم‌افزاری را ایجاد می‌کنند. در بیشتر موارد نرم‌افزارها در قالب ماژول‌های کوچک نوشته می‌شوند تا فرآیند اشکال‌زدایی آن‌ها ساده‌تر شود. در ادامه این ماژول‌ها در کنار یکدیگر قرار داده می‌شوند تا محصول واحدی به‌دست آید. آزمون نرم‌افزار بخش مهم فرآیند تولید نرم‌افزار است. این قسمت از فرآیندها کمک می‌کند تا مشکلات سامانه به صورت سریع شناسایی شوند. مستندسازی در تمام مراحل پروژه چون طراحی داخلی نرم‌افزار برای تعیین اهداف سیستم، نگهداری آینده و ارتقاء و بهبود سامانه هرچند پروژه پایان یافته باشد انجام می‌شود. همچنین ممکن است این مستندسازی شامل نوشتن ساختار تکه‌های برنامه ظاهر برنامه کاربردی داخلی و خارجی هم باشند. این مطلب خیلی مهم است که همه چیز پروژه مستندسازی شود.
استقرار و نگهداری از نرم‌افزار
استقرار و تحویل نرم‌افزار پس از آن‌که آزمایش‌های کمی و کیفی مختلف انجام شدند اجرا می‌شود که در حقیقیت به فرآیند انتشار، فروش یا هر نوع توزیع برای محیط کار نهایی اشاره دارند. در ارتباط با آزمایش‌های کمی، شرکت‌ها به سراغ آزمایش‌های الفا و بتا می‌روند که پروسه‌ای زمان‌بر است و گاهی اوقات ممکن است یکسال به طول انجامد تا محصول نهایی آماده عرضه به بازار شود. آموزش نرم‌افزار و پشتیبانی یکی دیگر از فرآیندهای مهم تولید نرم‌افزار است که متاسفانه برخی از شرکت‌های نرم‌افزاری توجهی به این مقوله نمی‌کنند. مهم نیست چقدر زمان و برنامه‌ریزی توسط تیم تولید و توسعه نرم‌افزار برای ایجاد نرم‌افزار شده باشد، اگر در آخر کار کاربر نتواند از نرم‌افزار استفاده کند، محصول ساخته شده ارزش چندانی ندارد. کاربران به‌طور معمول در برابر تغییرات مقاومت نشان می‌دهند و از ماجراجویی در محیط ناآشنا اجتناب می‌کنند، برای همین در فاز استقرار مهم است کلاس‌های آموزشی برای کاربران جدید نرم‌افزار گذاشته شود. نگهداری و ارتقای نرم‌افزاری برای پوشش، مسائل پوشش داده نشده یا نیازمندی‌های تازه‌ای که ممکن است به وجود آیند مدت خیلی زیادی حتی بیشتر از زمان اولیه تولید نرم‌افزار زمان بگیرد. این مرحله ممکن است نیاز باشد تا کدهای برنامه‌نویسی تازه‌ای که در طراحی اصلی برنامه نیز دیده نشده اضافه شود تا مسائل و مشکلات دیده‌نشده حل شوند یا ممکن است کاربر درخواست عملیات اصلی دیگری کند و برنامه‌نویسی‌های تازه‌ای برای برآورده کردن نیازهای جدید انجام گیرد. اگر هزینه کار فاز نگهداری از ۲۵ درصد هزینه فاز قبلی (پیاده‌سازی) بیشتر باشد، این احتمال وجود دارد که کیفیت کلی فاز قبلی خیلی ضعیف بوده باشد. در این صورت مدیران پروژه باید گزینه ایجاد مجدد سامانه (یا بخشی از سامانه) را قبل از اینکه هزینه‌های نگهداری غیرقابل کنترل شود را مطرح کنند.
روندهای ساخت نرم‌افزار
نرم‌افزارهای به‌طور معمول بر مبنای الگوهای مختلفی همچون آبشاری، برنامه‌نویسی مفرط، چابک، اسکرام و… ساخته می‌شوند که هر یک مزایا و معایب خاص خود را دارند.
الگوی آبشاری
الگوی آبشاری به توسعه‌دهندگان اعلام می‌دارد نرم‌افزارها را بر مبنای فازهای مشخص و تعریف شده‌ای پیاده‌سازی کنند. این فرآیندها را به زیر هستند:
مشخصات مورد نیاز (تحلیل نیازمندی‌ها)
طراحی نرم‌افزار
پیاده‌سازی و یکپارچه سازی
تست نرم‌افزار (یا اعتبارسنجی)
گسترش نرم‌افزار (یا نصب)
نگهداری نرم‌افزار
در این مدل فعالیت‌های تولید نرم‌افزار در قالب فازهای با توالی مشخص و به ترتیب، برنامه‌ریزی و اجرا می‌شوند. اشکال عمده این روش این است که بازبینی و تجدید نظر در فازهای انجام شده امکان‌پذیر نیست لذا خطای تخمین ابعاد پروژه، ریسک اشتباه در فهم درست و تحلیل نیازمندی‌ها و نیز امکان انتخاب نابجای معماری بسیار بالا می‌باشد.در سختگیرانه‌ترین حالت آبشاری، بعد از اینکه هر فاز کاملاً پایان پذیرفت، به مرحله بعدی می‌رویم. بازبینی که اجازه ایجاد تغییرات در سامانه را بدهد (که ممکن است شامل تغییرات فرایندهای کنترل رسمی باشد) فقط قبل از رفتن به مرحله بعد امکان‌پذیر است. همچنین بازبینی ممکن است جهت اطمینان از پایان قطعی این فاز (مرحله) بکار گرفته شود. فازی که معیارهای تکمیل آن کامل شده، معمولاً با عنوان دروازه اطلاق می‌شود که نشان می‌دهد پروژه از فاز فعلی به فاز بعدی منتقل شده‌است. الگو آبشاری از بازبینی و تجدید نظر فازهای قبلی که کامل شده‌اند، جلوگیری می‌کند. این عدم انعطاف‌پذیری مفصل در الگو آبشاری محض، دست مایه انتقاد پشتیبانی کنندگان الگوهای انعطاف‌پذیر است.
الگو ی چرخشی/مارپیچ (Spiral Model)
ویژگی شاخص الگوی مارپیچ مدیریت ریسک در تمام مراحل چرخه تولید نرم‌افزار است. این الگو ترکیبی از برخی کلیدهای تأیید شده متدولوژی الگو آبشاری و نمونه‌سازی سریع است، اما احساس می‌شود الگو ارائه شده تأکید در ناحیه‌های کلیدی (الگو آبشاری) را با متدهای دیگری همچون بررسی دقیق و تحلیل دائمی ریسک‌ها، سیستم‌های خاص مناسب برای سامانه پیچیده و بزرگ، کوتاه‌تر کرده‌است. الگو مارپیچ این روش را با چهار نمودار که نشان دهنده فعالیت‌های زیر است، به تصویر می‌کشد. فرایندها در چند مرحله تکرار انجام می‌شود:
تدوین و فرموله کردن برنامه‌ریزی خوب است برای شناسایی اهداف سیستم، قسمت‌های انتخاب شده جهت پیاده‌سازی برنامه، محدودیت‌های واضح و مشخص پروژه.
تحلیل ریسک و مشکلات سامانه: ارزیابی تحلیلی برنامه‌های انتخاب شده، جهت مشخص کردن چگونگی شناسایی و از بین بردن ریسک‌ها.
پیاده‌سازی پروژه: پیاده‌سازی تولید نرم‌افزار و تأیید کارایی سامانه.
الگو مارپیچ مبتنی بر ریسک، بر اختیار انتخاب گزینه‌ها و محدودیت‌ها در سفارش‌ها برای پشتیبانی استفاده مجدد نرم‌افزار و اینکه کیفیت نرم‌افزار می‌تواند در ادغام اهداف ویژه در تولید نرم‌افزار کمک می‌کند، تأکید می‌کند.
از مهم‌ترین معایب الگوی مارپیچی به موارد زیر می‌توان اشاره کرد:
الگو مارپیچ تحلیل ریسک‌ها را تأکید می‌کند و بنابراین کاربران باید این تحلیل را قبول کنند و فکری برایش کنند (این مطالب را در نظر داشته باشند). این مسئله نیازمند اعتماد متقابل و همچنین تمایل به هزینه کردن برای رفع ایرادات، در هنگام تولید نرم‌افزار است و این دلیل استفاده شدن این الگو تولید نرم‌افزار پروژه‌های بزرگ است.
درصورتی‌که در هنگام پیاده‌سازی تحلیل ریسک‌ها تأثیر منفی روی سود پروژه زیاد باشد نبایستی از الگو مارپیچ استفاده گردد.
تولید و توسعه دهندگان نرم‌افزار به صورت فعال حواسشان به ریسک‌های قابل حل خواهد بود و به دقت آن‌ها را در الگو مارپیچ تحلیل می‌کنند.
مرحله اول تدوین و فرموله کردن یک برنامه برای رسیدن به اهداف با این محدودیت‌ها، و پس از آن تلاش برای پیدا کردن و حذف تمام خطرات بالقوه (ریسک‌های بالقوه) از طریق تجزیه و تحلیل دقیق و در صورت لزوم، با ساخت نمونه اولیه است. اگر برخی ریسک‌ها قابل حل نبودند در این صورت مشتریان باید تصمیم بگیرند که آیا می‌خواهند انجام پروژه را خاتمه دهند یا از ریسک‌های مورد نظر چشم پوشی کنند و به هر ترتیب ادامه دهند. در نهایت، نتایج ارزیابی شده و طراحی مرحله بعدی آغاز می‌شود. در حالت کلی یک الگو تکاملی است که به صورت مجموعه‌ای از نسخه‌های افزایشی توسعه میابد و همچنین در طی تکرارهای اولیه ممکن است یک الگو کاغذی یا یک نمونه اولیه باشد ولی در طول تکرارهای بعدی هر بار نسخه کامل‌تری از سامانه تولید می‌شود و این الگو به ۳ تا ۶ نواحی کاری تقسیم می‌شود.
الگوی تکرارشونده و افزایشی
رویکرد تکرارشوندگی ساخت نرم‌افزار اجازه می‌دهد که پروژه در ابتدا از بخش‌های کوچک شروع شود و به مرور زمان سامانه رشد کند تا کمک کند در این درگیری مشکلات مهم پیدا شوند قبل از اینکه فرضیات اشتباه باعث خراب شدن سامانه شوند. الگو تکرار فرایندها به وسیله تولید کنندگان نرم‌افزارهای تجاری انتخاب و استفاده می‌شود چون این الگو اجازه می‌دهد تا نیازهای کاربرانی که در زمان طراحی دقیقاً نمی‌دانند چگونه نیازمندی‌هایشان از سامانه را معرفی کنند به صورت بالقوه برآورده شود.
الگوی توسعه سریع نرم‌افزار
روش توسعه سریع نرم‌افزار (RAD) روش تکراری را به عنوان پایه کار استفاده می‌کند اما طرفداری نظریه سبک‌تر و محبوبیت بیشتر از روش سنتی است. روش سریع از بازخوردها به جای برنامه‌ریزی به عنوان سازوکار اصلی کنترل پروژه استفاده می‌کند. بازخوردها به وسیله آزمون‌های مرتب و انتشار پیاپی در بازه‌های زمانی کوتاه نرم‌افزارهای در حال تکامل تولید می‌شوند. روش‌های گوناگونی از فرایند سریع برای تولید نرم‌افزار استفاه می‌شود:
الگوی اسکرام
اسکرام یک روش چابک تکرارشونده و افزایشی برای مدیریت پروژه است که به‌طور معمول در الگوی تولید نرم‌افزار چابک به عنوان نوعی متدولوژی توسعه نرم‌افزار دیده می‌شود. با اینکه روش اسکرام در واقع برای مدیریت محصولات تولید و توسعه پروژه‌ها پیشنهاد شده بود، اما استفاده آن در مدیریت پروژه‌های تولید نرم‌افزار متمرکز شد؛ همچنین امکان دارد جهت مدیریت تیم نگهداری نرم‌افزار، مدیریت پروژه‌ها یا برنامه‌های عمومی مدیریت خط مشی‌ها استفاده شود.
الگوی تکامل قابلیت یکپارچه‌سازی (CMMI)
الگوی تکامل قابلیت یکپارچه‌سازی (CMMI) یکی از الگوهای پیشنهادی و تکنیک‌های پیشتاز است. ارزیابی سازمان‌های مستقل و رتبه‌بندی در مورد کیفیت چگونگی تعریف فرایندهای آن سازمان‌ها را دنبال می‌کند، نه بر کیفیت خود فرایندها یا نرم‌افزار تهیه شده‌است. الگوی CMMI جایگزین الگوی CMM شده‌است.
استاندارد بررسی بهبود قابلیت نرم‌افزار
ایزو 15504 که با عنوان فرایند تشخیص و تعیین بهبود قابلیت نرم‌افزار (SPICE) سرنام Software Process Improvement and Capability Determination شناخته می‌شود، چارچوبی برای ارزیابی فرایندهای نرم‌افزار است. این استاندارد تنظیمات قالب روشنی برای مقایسه فرایندها به‌شمار می‌رود. SPICE خیلی شبیه CMMI استفاده می‌شود. فرایندهای این الگو برای مدیریت، کنترل، راهنمایی و نظارت تولید نرم‌افزار است. این الگو جهت سنجش سازماندهی تولید و توسعه یا تیم پروژه به صورت واقعی در طول مدت تولید نرم‌افزار استفاده می‌شود. تجزیه و تحلیل این اطلاعات برای شناسایی نقاط ضعف و حرکت به سمت بهبود پروژه استفاه می‌شود. همچنین برای تشخیص نقاط قوت پروژه که می‌تواند برای سازمان یا تیم پروژه ادامه پیدا کند یا برای امور مشترک یکپارچه شود.