انتخاب روش مهندسی نرم افزار یا همان فرآیند توسعه نرم افزار دغدغه بسیاری از مدیران پروژه نرم افزاری می باشد. به طور قطع نمی توان گفت که چه متدولوژی ای برای توسعه همه نرم افزارها مناسب است. زیرا هر نرم افزار روند توسعه خود را دارد و نمی توان گفت که مثلا فرآیند چابک (Agile) برای توسعه همه نرم افزارها مناسب است.

خوشبختانه، فرآیندها و روشهای مهندسی و توسعه نرم افزار بی شماری وجود دارد که می توانید هنگام شروع پروژه خود، انتخاب کنید. اما کدام یک برای تولید نرم افزار شما مناسب است؟

بیاید قبل از هر چیز به چرخه عمر نرم افزار (SDLC) بپردازیم.

7 مرحله چرخه عمر نرم افزار

1. تجزیه و تحلیل و برنامه ریزی
2. نیازمندی ها
3. طراحی و نمونه سازی
4. توسعه نرم افزار
5. تست کردن
6. استقرار
7. نگهداری و به روز رسانی

5 تا از بهترین فرآیندهای توسعه نرم افزار

در زیر به 5 تا از بهترین و شناخته شده ترین روش مهندسی نرم افزار اشاره می کنیم.

1. آبشاری
2. چابک و Scrum
3. افزایشی و تکراری
4. V شکل
5. مارپیچ

چرخه عمر نرم افزار چیست و چرا وجود آن بسیار مهم است؟

همه نرم افزارها از روزی که ایده آن مطرح می شود تا روزی که به اتمام می رسد، دارای روندی هستند. چه این روند را برنامه ریزی کرده باشید و چه نکرده باشید. چرخه عمر نرم افزار، توالی مراحلی است که در طول توسعه و مهندسی یک نرم افزار انجام می شود.

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

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

حتی اگر می توانید نرم افزاری را بدون روند واضحی اجرا کنید ، به این معنی نیست که باید این کار را انجام دهید. به لطف سالها آزمایش، تکرار و توسعه، فرآیندهای مدرن توسعه و مهندسی نرم افزار ساخت ابزارهای جدید را ارزان تر، کارآمدتر و کم ریسکتر می کند.

فواید استفاده از روشهای مهندسی و متدولوژی نرم افزار

• برای هر مرحله واژگان مشترک ایجاد می کند
• کانالهای ارتباطی و انتظارات بین توسعه دهندگان و ذینفعان پروژه را تعریف می کند
• نقش ها و مسئولیت های واضح را برای کل تیم تعیین می کند (توسعه دهندگان، طراحان، مدیران پروژه، و غیره …)
• اتمام هر مرحله به طور توافقی باعث می شود که تیم طراحی و توسعه از محدوده پروژه خارج نشود و به ادامه پروژه بپردازد
• نحوه رسیدگی به اشکالات، درخواست های ویژگی و به روزرسانی ها را به صورت رسمی انجام می دهد

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

تصمیم گیری در مورد داشتن یک فرایند رسمی توسعه نرم افزار مانند این است که بپرسید آیا ترجیح می دهید در گرمای شدید کویر به امید اینکه به یک آبادی برسید، حرکت کنید، یا نقشه ای داشته باشید که شما را به آنجا هدایت کند.

بنابراین بیایید با درک بلوکهای چرخه عمر نرم افزار شروع کنیم و سپس به نحوه بهینه سازی آنها با انتخاب فرآیند مناسب توسعه نرم افزار برای تیم خود بپردازیم.

7 مرحله از چرخه عمر نرم افزار

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

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

1. تجزیه و تحلیل و برنامه ریزی

هنگامی که مشتری یا ذینفع، پروژه ای را درخواست کرد، اولین مرحله چرخه عمر نرم افزار برنامه ریزی است. این معمولا به معنی بررسی موارد زیر است:

• هم ترازی: چگونه این پروژه با ماموریت و اهداف بزرگتر شرکت شما ارتباط برقرار می کند؟
• در دسترس بودن و تخصیص منابع: آیا افراد و ابزار لازم را برای استفاده در اختیار دارید؟
• زمان بندی پروژه: این پروژه چگونه در اهداف و سایر وظایف شرکت شما قرار می گیرد؟
• برآورد هزینه: هزینه آن چقدر است؟

مرحله برنامه ریزی اطمینان می دهد که شما پروژه را درست شروع می کنید. بنابراین سعی کنید اطمینان حاصل کنید که تمام بخشهایی را که قرار است تحت تاثیر این پروژه قرار بگیرند، شامل مدیران پروژه، توسعه دهندگان، عملیات، امنیت و ذینفعان اصلی کنید.

در پایان این مرحله مدیر پروژه باید بداند که درحال ساخت چه چیزی می باشند و چگونه قرار است آن را بسازند.

مطالعه بیشتر: 5 فاز مدیریت پروژه های نرم افزاری

2. نیازمندی ها

مرحله بعدی درک نیازهای فنی این پروژه است. هر نرم افزاری (چه برنامه، طراحی مجدد وب سایت یا ویژگی جدید) برای حل مشکل مشتری بوجود می آید.

هنگامی که از مرحله برنامه ریزی رد شدید و محدوده پروژه را مشخص کردید، باید به این سوالات پاسخ داده باشید:

• این پروژه چه مشکلی را حل خواهد کرد؟
• چه کسی می خواهد از این نرم افزار استفاده نماید و چرا؟
• چه اطلاعاتی مورد نیاز است؟
• آیا نیاز هست که از نرم افزارها و یا api های دیگری استفاده شود؟
• امنیت این محصول چگونه تامین خواهد شد؟

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

3. طراحی و نمونه سازی

در این بخش طراحی نرم افزار و نحوه عملکرد آن آغاز می شود. در این مرحله نحوه عملکرد سیستم و نحوه ارتباط اجزا با هم مورد بررسی قرار می گیرد.

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

این مرحله به تیم و ذینفعان کمک می کند ایده ها را تایید کرده و بازخورد ارزشمندی دریافت کنید قبل از اینکه ایده های خود را شروع به پیاده سازی کنید.

4. توسعه نرم افزار

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

5. تست کردن

در هنگام توسعه نرم افزار، مرحله تست آغاز می شود. به طوری که در هنگام کد نویسی، توابع و کدها توسط توسعه دهندگان تست می شود اما بعد از آماده شدن محصول، دور بعدی تست آغاز می شود که این تست ممکن است توسط افرادی انجام شود که هیچ دانش کدنویسی ای نداشته باشند. به طوری که محصول به گروه کوچکی از آزمایش کنندگان داده می شود تا عملکرد آن را تست کنند و خطاهای کدنویسی و UX را گزارش کنند.

این مرحله از چرخه عمر توسعه نرم افزار ممکن است طولانی شود اما مهم است که محصول نهایی باگ یا خطایی نداشته باشد. زیرا این خطاها ممکن است اعتبار و بازار شما را نابود کنند. حتی ممکن است زمان خیلی طولانی تری برای صرف شود تا باگ ها رفع شوند.

6. استقرار

در این مرحله زمان آن رسیده است که محصول خود را برای کابران عرضه کنید. در این مرحله کار بازاریابی و فروش آغاز می شود.

7. نگهداری و به روز رسانی

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

نیازهای مشتری همیشه در حال تغییر است. و هنگامی که کاربران شروع به استفاده از نرم افزار شما می کنند، بدون شک اشکالاتی را پیدا می کنند، ویژگی های جدیدی را درخواست می کنند و عملکردهای متفاوت یا بیشتری را درخواست می کنند. پس برای جلب رضایت کاربران همیشه باید نرم افزار بهترین عملکرد را داشته باشد.

5 تا از بهترین متدولوژی های تولید نرم افزار و نحوه انتخاب آنها

مراحل تجزیه و تحلیل سیستم در فرایند تولید نرم افزار

فرآیندی که انتخاب می شود به اهداف پروژه، اندازه محدوده پروژه، تیم توسعه و سایر عوامل بستگی دارد. در اینجا 5 مورد از فرآیندهای توسعه نرم افزار آورده شده است که هر یک موافقان و مخالفان خود را دارد.

1. آبشاری یا Waterfall

فرآیند توسعه نرم افزار آبشاری چیست؟

فرآیند توسعه نرم افزار آبشاری (همچنین به عنوان “مدل پی در پی خطی” یا “مدل چرخه عمر کلاسیک” شناخته می شود) یکی از قدیمی ترین و سنتی ترین مدل ها برای ساخت نرم افزار است. در ابتدایی ترین شکل، شما می توانید به روش آبشاری فکر کنید که هر مرحله از چرخه عمر نرم افزار را به ترتیب دنبال می کند. شما باید هر یک را به ترتیب قبل از حرکت به پایان برسانید. با این حال، در بیشتر برنامه های کاربردی، فازها با بازخورد و اطلاعاتی که بین آنها منتقل می شود، کمی با هم همپوشانی دارند.

برخی از افراد همچنین دوست دارند این روند را “برنامه محور” بنامند ، زیرا برای انجام یک پروژه ابتدا باید همه کارهایی که باید انجام شود و به چه ترتیب انجام شود را بدانید. از این رو نام “آبشار” را انتخاب کرده اند، زیرا هر بخش به قسمت بعدی می رود.

فازها

• برنامه ریزی
• نیازمندی ها
• طراحی سیستم و نرم افزار
• پیاده سازی
• تست
• استقرار
• نگهداری و بروزرسانی

برای چه پروژه هایی مناسب است؟ تیم هایی با ساختار منظم که نیاز به مستندات دارند.

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

به عبارتی عملی تر، فرایند آبشاری برای سازمانهای بزرگتر (مانند سازمانهای دولتی) که قبل از شروع پروژه به ثبت نام و مستندات مربوط به تمام شرایط و دامنه نیاز دارند، مناسب است.

برای چه پروژه هایی مناسب نیست؟

اگر در حال توسعه محصولی هستید که نیاز هست کاربر در طول پروژه نظر خود را اعلام کند و پروژه در طول توسعه تغییر خواهد کرد، پس این فرآیند برای شما مناسب نخواهد بود.

در عین سادگی، بزرگترین اشکال این فرآیند عدم انعطاف پذیری آن است. شما نمی توانید نمونه های اولیه را بسازید و آزمایش کنید و نظر خود را در این راه تغییر دهید. و به همین دلیل، اگر اشتباهی در مرحله برنامه ریزی و یا نیازمندی ها وجود داشته باشد، ممکن است در نهایت بدون دانستن آن تا روز راه اندازی، به یک راه اشتباه بروید.

2. چابک (Agile) و Scrum

فرآیند توسعه نرم افزار چابک یا Agile چیست؟

فرایند توسعه نرم افزار چابک (و محبوب ترین روش آن، Scrum) رویکرد تکراری و پویایی را برای توسعه انتخاب می کند.

بر خلاف جریان سخت و متوالی روند آبشار، در چابک، محصول به عملکردهایی (task) 2 هفته ای تا 2 ماهه ای تقسیم می شوند تا نرم افزار قابل استفاده را برای بازخورد به مشتریان ساخته شود.

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

برای مثال، شما در حال ساخت ویژگی جدیدی برای یکی از محصولات خود هستید که می تواند دارای ویژگی های X ، Y و Z باشد. به جای اینکه ماه ها برای ساختن همه چیز وقت صرف کنید، 2 الی 4 هفته وقت صرف می کنید و محصولی را تولید می کنید که حداقل نیاز ضروری و مفید قابل استفاده کاربر را فراهم می کند.

این امکان باعث می شود که حلقه های بازخورد محکم تری در طول فرآیند توسعه نرم افزار وجود داشته باشد تا بتوانید به نیازهای واقعی مشتری بپردازید.

فازها

• پیش زمینه محصول
• پیش زمینه عملکردها (task ها)
• مرحله طراحی و پیاده سازی
• ارائه محصولی که کار میکند
• دریافت بازخورد و تصحیح محصول
• برنامه ریزی برای عملکرد بعدی

برای چه پروژه هایی مناسب است؟ تیم های پویایی که در حال به روزرسانی مداوم محصولات هستند.

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

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

برای چه پروژه هایی مناسب نیست؟ تیمهایی با بودجه و جدول زمانی بسیار محدود.

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

استفاده از فرآیند چابک و Scrum برای انجام صحیح فرآیند اساسی نیاز به فداکاری و درک کامل دارد. به همین دلیل مهم است که حداقل یک استاد اختصاصی Scrum در تیم خود داشته باشید تا اطمینان حاصل کنید که پروژه با شکست مواجه نمی شود.

3. افزایشی و تکراری

فرآیند توسعه نرم افزار افزایشی و تکراری چیست؟

فرآیند توسعه نرم افزار افزایشی و تکراری، یک حد وسط بین ساختار و برنامه ریزی پیشرو فرآیند آبشاری و انعطاف پذیری چابک است.

مانند چابک ایده این فرآیند نیز ایجاد محصولات کوچک و قرار دادن آنها در اختیار کاربر برای بازخورد می باشد. اما مواردی که در هر نسخه یا محصول ایجاد می شود با بقیه تکرارها فرق دارد.

در روند توسعه نرم افزار افزایشی، هر افزایش از محصول فرم ساده ای از عملکرد یا ویژگی جدید را اضافه می کند. مانند اینکه هسته اصلی نرم افزار در افزایش اول ایجاد می شود و سپس در افزایش های بعدی امکانات اضافی به آن افزوده می شود.

در فرآیند توسعه نرم افزار تکراری یا Iterative، هر نسخه ای که منتشر می کنید شامل نسخه ای از تمام ویژگی های برنامه ریزی شده شما می باشد. به آن فکر کنید مانند ساخت v0.1 با ساده ترین نسخه از هر ویژگی و سپس ارتقا v آن در v0.2 ، v0.3 و غیره.

فازهای افزایشی

• برنامه ریزی افزایشی
  • مشخصات فنی
  • توسعه
  • اعتبارسنجی
• تکرار برای هر نسخه

فازهای تکراری

• تحلیل
• طراحی
• توسعه
• تست

برای چه پروژه هایی مناسب است؟ تیم هایی با نیاز واضح که انعطاف پذیری بیشتری نسبت به روش آبشاری نیاز دارند.

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

با روند افزایشی ، بازخورد زودهنگام درباره ویژگی اصلی خود دریافت می کنید، که می تواند به شما کمک کند پروژه تجاری خود را تایید کنید. در حالی که رویکرد تکراری به کاربران امکان می دهد تا در مورد محصول کامل بررسی کنند تا بتوانید بازخورد بهتر و متمرکزتری داشته باشید.

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

برای چه پروژه هایی مناسب نیست؟ تیمهایی بدون برنامه بلند مدت.

ممکن است اهداف، رویه ها یا فناوری های تیم شما با گذشت زمان تغییر کند و تکرارهای قبلی را بی فایده یا از بین ببرد. یا شاید به دلیل افزودن قابلیت، کد شما نامرتب شود.

علاوه بر این، هر دو این مدل ها (و به ویژه رویکرد تکراری) از همان اوایل به برنامه ریزی سنگین و معماری نیاز دارند. به این معنی که آنها برای پروژه های کوچکتر یا تیم هایی که هنوز موارد استفاده را آزمون و خطا می کنند، ایده آل نیستند.

تفاوت بین افزایشی، تکراری و چابک چیست؟

اگر به قسمت های و فرآیندهای قبلی توجه کرده باشید، ممکن است در مورد تفاوت فرآیندهای توسعه نرم افزاری افزایشی، تکراری و چابک کنجکاو باشید. اگرچه آنها کاملا شبیه به هم هستند، اما چند تفاوت اساسی وجود دارد.

هر افزایش در رویکرد افزایشی یک ویژگی کامل ایجاد می کند. در حالی که در تکراری، در حال ساخت بخشهای کوچکی از همه ویژگیها هستید.

از سوی دیگر، چابک، جنبه های هر دو رویکرد را ترکیب می کند. در چابک، قسمت کوچکی از هر ویژگی را یکی یکی می سازید و سپس با گذشت زمان به تدریج قابلیت ها و ویژگی های جدید را اضافه می کنید.

4. V شکل

فرآیند توسعه نرم افزار V شکل چیست؟

فرایند توسعه نرم افزار V شکل برداشتی از روش کلاسیک آبشاری است با این تفاوت که بزرگترین ایراد آن را که عدم تست محصول می باشد را جبران می کند.

به جای اینکه تمام آزمایشات خود را برای پایان نگهدارید، هر مرحله از روند V شکل با یک مرحله دقیق “اعتبار سنجی و تایید” انجام می شود که در آن شرایط مورد نیاز قبل از رفت به مرحله بعد، آزمایش می شوند.

فازها

• نیازمندی ها
• مشخصات فنی
• طراحی سطح بالا
• طراحی سطح پایین
• توسعه
• تست واحد
• تست ارتباط اجزا
• تست سیستم
• تست پذیرش

برای چه پروژه هایی مناسب است؟ تیم هایی که روی پروژه های کوچکتر با دامنه محدود کار می کنند.

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

برای چه پروژه هایی مناسب نیست؟ تیم هایی که انعطاف پذیری بیشتر و ورود زود هنگام کاربران را دارند.

حتی بهترین برنامه ریزی ها نیز غالبا به بیراهه می روند. و نکات منفی این فرآیند اساسا عکس ویژگیهای مثبت آن است.

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

5. مارپیچ

فرآیند توسعه نرم افزار مارپیچ چیست؟

فرآیند توسعه نرم افزار مارپیچ تمرکز فرآیند V شکل را در آزمایش و ارزیابی ریسک با ماهیت افزایشی تکراری و چابک ترکیب می کند.

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

فازها

• برنامه ریزی
• ارزیابی ریسک
• توسعه و اعتبارسنجی
• ارزیابی نتایج و برنامه ریزی برای تکرار بعدی

برای چه پروژه هایی مناسب است؟ تیم های خطرپذیر که روی پروژه های بزرگ کار می کنند.

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

برای چه پروژه هایی مناسب نیست؟ بیشتر پروژه ها

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

منبع: Software Development Process