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