چرا مدل آبشاری هنوز جزو برترین متدولوژی‌های دنیای نرم‌افزار است؟

این مطلب یکی از مقالات پرونده ویژه«متدولوژی‌ها، الگوها و معماری نرم‌افزار» شماره 207 ماهنامه شبکه است. علاقه‌مندان می‌توانند کل این پرونده ویژه را از روی سایت شبکه دانلود کنند.

 دلیل محبوبیت مدل آبشاری می‌تواند به تغییر نگرش شرکت‌ها بازگردد. به عبارت دقیق‌تر، شرکت‌ها موفق شده‌اند راهکاری برای غلبه بر ضعف‌های این مدل پیداکرده و از طریق به‌کارگیری مهندسی معکوس ضعف‌ها را به نقاط قوت تبدیل کرده و حتی در برخی موارد متدولوژی‌های خاصی را بر پایه این مدل ارائه کنند. مدلی که روی پروژه‌های کوچک نرم‌افزار بازدهی خیلی خوبی دارد.این مدل یکی از قدیمی‌ترین مدل‌های ارائه‌شده در فرآیند توسعه نرم‌افزار است. اگر به تاریخچه شکل‌گیری این مدل نگاه کنید، مشاهده می‌کنید، این مدل ماحصل پژوهش و تفکر عمیقی است که ریشه در صنایع تولیدی و ساخت‌و‌ساز دارد. صنایعی که دو ویژگی شاخص دارند. اول آن‌که زیرساخت‌های آن‌ها کاملا ساخت‌یافته است؛ دوم آن‌که در برابر تغییرات فیزیکی دنیای ملموس کاملا مقاوم بوده و برای اجتناب از افزایش هزینه‌ها تغییرات در آن‌ها به‌سختی اعمال می‌شود. بر همین اساس باید بگوییم که مدل آبشاری در اصل یک مدل سخت‌افزارگرا است. تا قبل از پیدایش مدل آبشاری، دنیای نرم‌افزار به شکل امروزی فاقد یک مدل ساخت‌یافته منسجم و دقیق بود. بر همین اساس شرکت‌ها تصمیم گرفتند به سراغ سیستمی شماتیک بروند تا دو فاکتور افزایش کیفیت و کاهش هزینه‌ها را به همراه داشته باشد. درحالی‌که این مدل در ابتدا سخت‌افزارگرا بود اما به‌مرورزمان متناسب با توسعه نرم‌افزارها تغییراتی در آن به وجود آمد. نخستین جرقه شکل‌گیری مدل آبشاری به سخنرانی ژوی بنینگتون در سمپوزیم روش‌های پیشرفته برنامه‌نویسی کامپیوترهای دیجیتالی به سال 1956 بازمی‌گردد که دیدگاه خود را در ارتباط با توسعه نرم‌افزارها برای سامانه‌های SAGE (سرنام Semi-Automatic Ground Environment) ارائه کرد. SAGE به سامانه‌ای اشاره دارد که مشتمل بر کامپیوترهای بزرگ و شبکه‌های مرتبط به یکدیگر است که داده‌هایی را از سایت‌های رادار و به شکل هماهنگ دریافت کرده، پردازش‌هایی روی داده‌ها انجام داده و در نهایت یک تصویر واحد و یکپارچه را از حریم هوایی یک منطقه وسیع ارائه می‌کنند. بعدها مقاله‌ای با پیشگفتار بنینگتون به چاپ رسید که به فرآیندی اشاره داشت که در آن مقاله به الگویی خاص از طراحی اشاره‌شده بود که رویکردی از «بالا به پایین» داشت. هر چند در آن مقاله به شکل مستقیم به واژه «آبشاری» اشاره‌ای نشده بود، اما همان مفهوم را منتقل می‌کرد. نخستین توصیف رسمی از مدل آبشاری با عنوان «یک شروع برای مدل آبشاری» در سال 1970 توسط وینستون رویس به چاپ رسید. هرچند رویس نیز در آن مقاله به مفهوم «آبشاری» اشاره دقیقی نکرد، اما به تشریح معایب و مزایای چنین مدلی پرداخت. سرانجام برای نخستین بار واژه آبشاری در سال 1976 از سوی بل و تایر به کار گرفته شد. در مدلی که رویس نخستین بار به آن اشاره کرد، مراحل به‌صورت ترتیبی از بالا به پایین اجرا می‌شدند. اما در مجموع، به دلیل این‌که گذر از هر مرحله‌به‌مرحله بعد به‌صورت آبشاری و رو به پایین انجام می‌گرفت، این مدل به نام مدل آبشاری چرخه حیات نرم‌افزار نامیده شد. مدل آبشاری بر این اصل تاکید دارد که پیشرفت و کامل شدن مراحل باید در طول چرخه حیات توسعه نرم‌افزار (SDLC) به وجود آید. درحالی‌که در طول این سال‌ها محبوبیت مدل آبشاری در سایه متدولوژی‌های چابک قرارگرفته، بااین‌حال نمی‌توان ماهیت منطقی توالی روندها را انکار کرد. این روند طراحی منطقی هنوز هم در بسیاری از صنایع وجود دارد. در مدل آبشاری شما با مجموعه‌ای از فرآیندهای طراحی ترتیبی روبه‌رو هستید که این فرآیندها عبارتند از مفاهیم (Conception) شروع (Initiation)، تجزیه‌وتحلیل (Analysis)، طراحی (Design)، ساخت (Construction)، تست (Testing)، تولید و پیاده‌سازی(Production/Implementation) و نگهداری (Maintenance). این فرآیندها با یکدیگر ترکیب‌شده و در پنج مرحله شالوده مدل آبشاری را به وجود می‌آورند. 

مطلب پیشنهادی

راهکارهایی برای رسیدن به موفقیت که معمولا نادیده گرفته می‌شوند

۹ توصیه مهم برای موفقیت برنامه‌نویسان یا دانشجویان رشته نرم‌افزار

5 مرحله مدل آبشاری 

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

1. تعریف و تحلیل نیازمندی‌ها
(Requirements analysis and definition)

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

2. طراحی نرم‌افزار و سیستم
(System and software design)

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

3. پیاده‌سازی و تست واحد
(Implementation and unit test)

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

4. یکپارچه‌سازی و آزمایش سیستم
(Integration and system testing)

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

5. عملیات و نگهداری
(Operation and maintenance)

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

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

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

مطلب پیشنهادی

رایگان دانلود کنید: کتاب الکترونیکی «کتاب در کتاب»

مزایای مدل آبشاری 

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

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

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

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

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

مطلب پیشنهادی

یادگیری قدرتمند با اتکا بر رفتار هوشمندانه

برای یادگیری برنامه‌نویسی به این 13 نکته دقت کنید

معایب

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

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

• نادیده گرفتن بازخوردهای کاربر/مشتری در میانه فرآیندها: با توجه به این‌که فرآیندها در مدل آبشاری گام‌به‌گام و دقیق هستند مشکل دیگری به وجود می‌آید که همانا دریافت دیرهنگام بازخوردها از کاربر یا مشتری است که عمدتا در اواخر چرخه توسعه دریافت می‌شود. درحالی‌که مدیران پروژه می‌توانند یک فرآیند بازگشت به مرحله قبل را به‌منظور بررسی نیازمندی‌های پیش‌بینی‌نشده یا تغییر پیدا کرده از سوی مشتری به مرحله اجرا بگذارند، اما این کار نه تنها برای تیم‌های توسعه، بلکه برای مشتری هم وقت‌گیر بوده و هزینه‌های جانبی را به همراه خواهد داشت.

• دوره آزمایش همراه با تاخیر: درحالی‌که بیشتر مدل‌های مدرن SDLC سعی می‌کنند فاز آزمایش را با فرآیندهای زیربنایی و درحال‌توسعه یکپارچه کنند، اما در مدل آبشاری این رویکرد تا حدودی با تاخیر همراه است. البته توجه داشته باشید که این حرف به معنای آن نیست که مشکلات در همه فرآیندها به شکل پنهان و غیرقابل شناسایی باقی خواهند ماند، اما وجود فاز آزمایش در هر مرحله به کم کردن هزینه‌ها کمک فراوانی خواهد کرد. باوجود یک مرحله آزمایش دقیق و کامل هنگام اجرای یک پروژه در مدل آبشاری، اما این آزمایش دیرهنگام انجام‌شده و کافی نیست. علاوه بر این در نظر داشته باشید که تیم شما باید از ابزار مدیریتی توانمند در زمینه مدیریت خطاها در چرخه توسعه نرم‌افزار استفاده کند. Airbrake از جمله ابزارهای قدرتمندی است که برای این منظور ارائه‌شده است.

در پایان

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