مدل آبشاری یک رویکرد طراحی خطی و متوالی نسبتاً برای برخی از حوزه‌های طراحی مهندسی است.
در توسعه نرم‌افزار، این رویکرد معمولاً یکی از رویکردهای کمتر تکراری و انعطاف‌پذیر است، زیرا پیشرفت عمدتاً در یک جهت به سمت پایین، مانند یک آبشار، از طریق مراحل تصور، آغاز، تحلیل، طراحی، ساخت، آزمایش، استقرار و نگهداری جریان دارد. در پروژه‌های توسعه نرم‌افزار، مراحل معمولاً به این شکل هستند:
۱. الزامات
اگر شما در توسعه نرم‌افزار یا هر نوع تیم ایجاد پروژه هستید، می‌خواهید زمینه کسب‌وکار آنچه را که در حال ایجاد آن هستید بدانید – می‌خواهید مشخص کنید که چه نوع مشکلاتی را می‌خواهید حل کنید و مردم چگونه به محصول نهایی شما واکنش نشان خواهند داد. پس از تعریف تمام این «الزامات»، ورودی لازم برای ادامه به مرحله بعدی را دارید.
۲. طراحی
این مرحله شامل تمام مراحلی است که برای برآورده کردن تمام الزامات تعیین شده قبلی نیاز دارید. در توسعه نرم‌افزار، این بخشی است که شما تمام معماری نرم‌افزار و سخت‌افزار، زبان برنامه‌نویسی، ذخیره‌سازی داده‌ها و غیره را تعریف می‌کنید. این همچنین بخشی است که در آن تعیین می‌کنید پروژه چگونه برای کاربر نهایی مفید خواهد بود.
۳. پیاده‌سازی
در این مرحله، شما شروع به ساخت آنچه که در برنامه‌تان طراحی کرده‌اید می‌کنید. این بخش از روش آبشاری به برآورده کردن استانداردهایی که در مراحل قبلی تعیین کرده‌اید اختصاص دارد. این بخشی است که افراد تیم توسعه وارد می‌شوند و تمام موارد بحث شده در مراحل قبلی را به واقعیت تبدیل می‌کنند.
۴. تأیید
این بخشی از روش است که افراد تضمین کیفیت وارد می‌شوند تا اطمینان حاصل کنند که تیم توسعه هیچ اشتباهی مرتکب نشده است. این همچنین احتمالاً بخشی است که افراد متوجه می‌شوند چه چیزی در برنامه‌شان کار می‌کند یا کار نمی‌کند.
توجه داشته باشید
زمانی که همه چیز توسط توسعه‌دهندگان پروژه تأمین شد، مشتری یا کاربر نهایی وارد می‌شود و تصمیم نهایی می‌گیرد که آیا پروژه آماده راه‌اندازی است یا خیر.
روش آبشاری تأکید می‌کند که وقتی چیزی در یک مرحله خاص اشتباه می‌شود، افراد می‌توانند به مرحله قبلی برگردند تا ببینند چه چیزی اشتباه شده است. به عنوان مثال، اگر در پیاده‌سازی برنامه مشکلی وجود داشته باشد و افراد بدانند که آنها فقط از نقشه‌ای که به آنها داده شده پیروی کرده‌اند، سپس مدیران به برنامه خود نگاه می‌کنند و اصلاحات خود را از آنجا انجام می‌دهند.
مشکل مدل آبشاری چیست؟
مشتریان ممکن است دقیقاً ندانند که الزامات آنها چیست قبل از اینکه نرم‌افزار کارا را ببینند و بنابراین الزامات خود را تغییر دهند که منجر به طراحی مجدد، توسعه مجدد و آزمایش مجدد و افزایش هزینه‌ها می‌شود.
توسعه‌دهندگان ممکن است از مشکلات آینده هنگام طراحی یک محصول یا ویژگی جدید نرم‌افزاری آگاه نباشند، در این صورت بهتر است طراحی را اصلاح کنند تا اینکه در طراحی که هیچ محدودیت، الزامات یا مشکلات جدیدی را در نظر نمی‌گیرد، پافشاری کنند.
بنابراین، هیچ تضمینی وجود ندارد که الزامات مورد نظر سازمان واقعاً کار کند. از اینجا متوجه می‌شوید که مدل آبشاری مشکلات زیر را دارد:
1. افراد به طور کورکورانه از برنامه‌ها پیروی می‌کنند.
در روش سنتی، افراد بیشتر به این توجه می‌کنند که چگونه چیزها در زمان مناسب اتفاق می‌افتد بدون اینکه به این فکر کنند که آیا واقعاً همه چیز در حال درست شدن است یا خیر. در حالی که برنامه‌ریزی مهم است، همچنین مهم است که توسعه‌دهندگان و بازرسان کیفیت درک کنند که چگونه چیزها باید اتفاق بیفتد، به ویژه با مشتری یا کاربر نهایی. همچنین مهم است که همه افراد درگیر در پروژه بتوانند بلافاصله بگویند که چگونه یک مرحله خاص در تحقق پروژه می‌تواند خراب شود بدون اینکه مجبور باشند منتظر مرحله آزمایش بمانند.
2. فرآیند متوالی و تغییرات هزینه‌بر می‌شود
این رویکرد اجازه تغییر الزامات تعریف شده را در حین پیشرفت پروژه نمی‌دهد. بنابراین احتمال زیادی وجود دارد که نرم‌افزار به طور کامل الزامات کاربر را برآورده نکند، ناکارآمد باشد و عملکرد ضعیفی داشته باشد.
این ناکافی است زیرا توسعه‌دهندگان نمی‌توانند به سادگی به مرحله قبلی برگردند و چیزی را تغییر دهند زیرا الزامات مصرف‌کننده تغییر می‌کند، بلکه توسعه‌دهنده باید به جایی برگردد که الزامات نیاز به تغییر دارد و آن مرحله را از نو شروع کند. تا زمانی که آن مرحله کامل نشود، نمی‌تواند به مرحله بعدی برود.
3. کاربران نهایی نمی‌دانند چه می‌خواهند.
بیشتر اوقات ذهن کاربران نهایی به طور مداوم در حال تغییر است و اکثر افراد ایده مبهمی از الزامات نرم‌افزاری خود دارند و این در حین توسعه نرم‌افزار است که آنها الزامات خود را مشخص می‌کنند.
زمانی که زمان تحویل محصول نهایی به مشتری فرا می‌رسد، احتمالاً آنها از نتیجه کار راضی نخواهند بود، با وجود اینکه در مراحل اولیه به طور عمدی خلاف آن را گفته‌اند. برای مشتریان و کاربران نهایی آسان است که در طول زمان آنچه را که می‌خواهند تغییر دهند. سیستم آبشاری هنوز راهی برای حل این مشکل ندارد، بدون اینکه مجبور به اصلاح برنامه‌ها و انجام مجدد کل پروژه باشد.
4. آزمایش برای کیفیت ممکن است آسیب ببیند.
پیش‌بینی دقیق نتایج یک پروژه غیرممکن است و زمانی که کل تیم تحت فشار زمان است، ممکن است مرحله آزمایش به منظور رعایت مهلت کوتاه شود.
5. هرگز نخواهید دانست که در چه مرحله‌ای واقعاً هستید.
از آنجا که محصولی که در حال تلاش برای ایجاد آن هستید تا پایان تولید نخواهد شد، شما واقعاً مطمئن نیستید که آیا هنوز در مرحله برنامه‌ریزی هستید یا در حال حاضر در مرحله توسعه هستید. این بدان معناست که احتمالاً زمان بیشتری را در یک مرحله نسبت به آنچه که انتظار داشتید صرف خواهید کرد به دلیل این عدم وضوح.
در نهایت، روش آبشاری می‌تواند بسیار پرخطر باشد زیرا بسیار سختگیر است. برای اینکه شما محصولی تولید کنید که کار کند و به اندازه کافی انعطاف‌پذیر باشد تا به شما کمک کند بفهمید چه چیزی کار می‌کند یا نمی‌کند.
منابع مرتبط
This post is also available in Deutsch, English, Español, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文.