در دو قسمت قبلی این مقاله به بررسی دو روش آبشاری (Waterfall) و پیش‌نمونه‌سازی (Prototyping) پرداختیم. در ادامه روش افزایشی یا Incremental را بررسی می‌کنیم.
Incremental (روش افزایشی)
نوع چارچوب: ترکیبی از خطی و تکرارشونده
اصول پایه:
روش‌های مختلفی برای ترکیب دو روشگانِ (methodology) توسعۀ تکرارشونده و خطی موجود است؛ هدف اولیۀ هرکدام از این روش‌ها کاهش ریسک ذاتی پروژه با تقسیم پروژه به بخش‌های کوچک‌تر و تسهیل تغییرات در طی فرایندهای توسعه است. فرایند توسعۀ افزایشی به قرار زیر است:
- یک سری از واترفال‌های کوتاه اجرا می‌شوند و قبل از پیشروی به افزایش بعدی، تمام فازهای مدل توسعۀ واترفال (آبشاری) برای یک بخش کوچک از سیستم کامل می‌شود؛ یا
- قبل از آغاز توسعۀ تکاملی و آبشاری، هرکدام از افزایش‌های سیستم، معادل نیازمندی‌های کلی سیستم تعریف می‌شوند؛ یا
- مفهوم اولیۀ نرم‌افزار، تحلیل نیازمندی‌ها و طراحی معماری و هستۀ سیستم با استفاده از رویکرد واترفال (آبشاری) تعریف می‌شوند و پیگیری آن‌ها با پیش‌نمونه‌سازیِ تکرارشونده صورت می‌گیرد که با پیاده‌سازی پیش‌نمونۀ نهایی تکمیل می‌شود.
نقاط قوت:
- در توسعۀ افزایش‌های بعدی، این پتانسیل وجود دارد که بتوان از دانشی که در اولین افزایش کسب می‌شود استفاده کرد؛
- با به‌کارگیری مستندات مکتوب و بازبینی رسمی و تأیید/ اعلام خاتمه هر مایلستون اصلی توسط کاربر یا مدیر فناوری اطلاعات، کنترل متوسطی در روند حیات پروژه اعمال می‌شود؛
- می‌توان به ذی‌نفعان شواهد ملموسی از وضعیت پروژه در طی چرخۀ حیات پروژه ارائه داد؛
- به کاهش اولیۀ ریسک‌های معماری و یکپارچه‌سازی پروژه کمک می‌کند؛
- امکان تحویل مجموعه‌ای از پیاده‌سازی‌ها که به‌تدریج کامل‌تر می‌شوند و زودتر از زمان‌های تعیین‌شده برای عرضه به تولید می‌رسند وجود دارد؛
- به دلیل پیاده‌سازی تدریجی، امکان نظارت بر تأثیر تغییرات افزایشی، ایزوله کردن مشکلات و اعمال تنظیمات پیش از اینکه بر سازمان تأثیر منفی بگذارد وجود دارد.
نقاط ضعف:
- هنگام استفاده از یک سری از واترفال‌های کوتاه برای بخش کوچکی از سیستم، قبل از رفتن به افزایش بعدی، مشکلات تجاری و نیازمندی‌های فنی سیستم در نظر گرفته نمی‌شود؛
- به دلیل اینکه برخی از ماژول‌ها بیشتر از بقیه کامل می‌شوند، نیاز به واسط‌ها با تعریف‌های مناسب است؛
- مسائل دشوار معمولاً به آینده معوق می‌شوند تا موفقیت اولیه پروژه نشان داده شود.
موقعیت‌هایی که بیشتر برای آن مناسب است:
- پروژه‌های بزرگی که شناخت مناسبی از نیازمندی‌ها وجود ندارد و به دلیل تغییرات خارجی، تغییر انتظارات، تغییرات بودجه یا تغییر سریع فناوری، نیازمندی‌ها در تغییر هستند؛
- سیستم‌های اطلاعات وب (WIS) یا دستگاه‌های رویدادمحور؛
- کاربردهای پیشرفته.
موقعیت‌هایی که کمتر برای آن مناسب است:
- پروژه‌هایی که بسیار کوچک باشند و طول‌مدت‌های بسیار کوتاهی داشته باشند؛
- ریسک معماری یا یکپارچه‌سازی بسیار کم باشد؛
- کاربردهایی که بسیار تکرار شوند؛ به‌طوری که داده‌های پروژه ازقبل موجود باشد (کاملاً یا بخشی از آن) و تحلیل‌ها یا گزارش داده‌های وسیعی برای پروژه وجود داشته باشد.
در قسمت بعدی این مقاله روشگان مارپیچی یا اسپیرال را بررسی می‌کنیم.
انتخاب رویکرد توسعه (قسمت اول)
