نموذج الشلال

نموذج ضعيف للمشاريع الطويلة والمستمرة

علاوةً على ذلك، غير مناسب للمشاريع حيث المتطلبات فيها مخاطر عالية من التغيير

ومن جهة أخرى، عندما يكون لدى العميل ثقة عالية في المنظمة، والمشروع يكون صغير. يعتبر هذا النهج مثالياً للمشاريع التي تحتوي على متطلبات ثابتة وموارد وفيرة وجدول زمني ثابت وتكنولوجيا واضحة وثابتة، ولكنه لا يصلح مع المشاريع المُعقدة أو المشاريع غير المُستقرة، التي قد تتغير مُتطلباتها باستمرار وفجأة.

متى نستعمله؟

ومن ناحية أخرى، عندما يكون لدينا متطلبات واضحة ولا توجد متطلبات غامضة ومعقدة، عندما يوجد موارد متوفرة بحرية وتوافر الخبرة.

النموذج

• في نموذج الشلال الأصلي ل رويس تتبع المراحل التالية:
• متطلبات النظام والبرنامج: الموجودة في وثائق متطلبات المنتج.
• التحليل: النتائج إلى نماذج، المخطط، وقواعد العمل.
• التصميم: اظهار نتائج في بناء وهندسة البرمجيات.
• الترميز: التطوير والإثبات، وتكامل البرمجيات.
• الاختبار: اكتشاف المنهجيات وتصحيح العيوب.
• العمليات: عملية التثبيت، والهجرة، والدعم، وصيانة النظام بالكامل.

من جهة ثانية، لا يجب لأحد ان ينتقل إلى المرحلة التالية إلا عند الانتهاء من المرحلة السابقة والتحقق منها. يوجد نماذج مختلفة معدلة (بما في ذلك النموذج النهائي لرويس)، ويمكن أن تشمل اختلافات كبيرة على هذه العملية. هذه الاختلافات شملت العودة إلى الدورة السابقة بعد العثور على العيوب، أو العودة إلى الطريق لمرحلة التصميم، إذا تعتبر المراحل النهائية غير كافية.

النموذج اللولبي

• تحليل النظم الهيكلية وطرق التصميم (SSADM)
• عملية تطوير البرمجيات
• هندسة تقليدية
• V-model

المراحل

وفي هذا الصدد، التحليل: عملية تجميع المتطلبات لفهم المشكلة، وعملية تقسيم أو توزيع موضوع كبير أو معقد إلى اجزاء اصغر من اجل اكتساب فهم أفضل وأسهل للمشكلة والاهداف.

كذلك، التصميم: تصميم حلول للمتطلبات التي جمعناها، عملية تحتوي على انشطة معينة مثل صياغة وترتيب، لتحقيق الاهداف.

دعم الادلة

ومن جهة أخرى، في الممارسات الشائعة تؤدي منهجيات الشلال في الجدول الزمني للمشروع مع 20-40 ٪ من الوقت، استثمرت في المرحلتين الأولى والثانية، 30-40 ٪ من الوقت إلى الترميز، والباقي مخصص للاختبار والتنفيذ. وسوف تشمل أغلب المشاريع المتوسطة والكبيرة مجموعة مفصلة من الإجراءات والضوابط التي تنظم كل عملية على المشروع.

من جهة ثانية، وفر نموذج الشلال نهج منظم؛ النموذج نفسه تقدم خطيا من خلال مراحل منفصلة، يسهل فهمها وتفسيرها، وبالتالي من السهل أن نفهم. كما يوفر المعالم التي يسهل التعرف عليها في عملية التنمية. ولعله لهذا السبب نموذج الشلال يستعمل كنموذج بداية لنموذج التنمية في الكثير من النصوص هندسة البرمجيات والدورات.

علاوةً على ذلك، وهناك حجة أخرى لنموذج الشلال وهو أنه يركز على وثائق (مثل المستندات ومتطلبات وثائق التصميم)، وكذلك شفرة المصدر. في منهجيات أقل مصممة بدقة وموثقة، تُفْقَد المعرفة إذا ترك أعضاء الفريق قبل الانتهاء من المشروع، وأنه قد يكون من الصعب على مشروع ليتعافى من الخسارة. إذا كان مستند تصميم العمل موجودًا كاملًا (كما هو القصد من تصميم كبير في خط الهجوم ونموذج الشلال)، وأعضاء فريق جديد أو حتى فرق جديدة تماما يجب أن تكون قادرة على التعرف من خلال قراءة الوثائق. Arcisphere technologies (2012). "Tutorial: The Software Development Life Cycle (SDLC)" (PDF). Retrieved 2012-11-13.

ومن ناحية أخرى، ان نموذج الشلال يمكن أن يكون مناسب للمشاريع حيث يجري إصلاح متطلبات ونطاقها، المنتج في حد ذاته ثابت ومستقر، وتفهم التقانةبوضوح.

وفي هذا الصدد، اقضاء وقت مبكر في دورة إنتاج البرمجيات يمكن من تجنب التكاليف في مراحل لاحقة، مثلًا مشكلة وجدت في المراحل المبكرة (مثل متطلبات المواصفات) هي أرخص للإصلاح من نفس مشكلة وجدت في وقت لاحق في العملية (بمعامل 50 إلى 200).

المراحل تكتمل وتعالج مرحلة تلو الأخرى

علاوةً على ذلك، يفضل في المشاريع حيث الجودة هي أكثر اهمية بالمقارنة مع الجدول الزمني والتكلفة

العمل يقسم إلى مشاريع صغيرة حيث المتطلبات تصبح سهلة للفهم

تاريخ النموذج

من جهة ثانية، وكثيرا ما يستشهد أول وصف رسمي لنموذج الشلال على أنه مقالة ونستون رويس التي طرحها عام 1970 ، وذلك رغم أن رويس لم يستعمل مصطلح شلال في تلك المادة. قام رويس بعرض هذا هذا النموذج على أنه نموذج خاطئ وغير عامل؛ وهي الطريقة التي تستعمل هذا المصطلح في الكتابة عن تطوير البرمجيات لوصف رؤية نقدية لممارسات تطوير البرمجيات شائعة الاستخدام.

من جانب آخر، وفي عام 1985 حددت وزارة الدفاع في الولايات المتحدة هذا النهج في DOD-STD-2167A ، ومعاييرها للعمل مع مقاولي تطوير البرمجيات كانت تنص على أن «يقوم المقاول بتنفيذ دورة تطوير البرمجيات التي تشمل المراحل التالية: التصميم الأولي ثم التصميم التفصيلي ثم الترميز ووحدة الاختبار ثم التكامل ثم الاختبار».

ومن ناحية أخرى، عقد أول عرض واصفاً استخدام مراحل مماثلة في هندسة البرمجيات من قبل هربيرت د. بينينجتون في ندوة حول أساليب البرمجة المتقدمة لأجهزة الكمبيوتر الرقمية يوم 29 يونيو عام 1956. ، وكان هذا عرض حول تطوير البرمجيات ل SAGE . عام 1983 أُعيد نشر الورقة مع تقديم من بينينجتون مشيراً إلى أن العملية لم تكن في الواقع من أعلى إلى أسفل ولكنها تعتمد على النموذج الأصلي.

في هذا الإطار، أقرب استخدام لمصطلح «الشلال» قد يكون في ورقة بيل وثاير في عام 1976.

السلبيات

نسبة كبيرة من المخاطر واحتمال حصول اخطاء

ليس نموذج جيد للمشاريع المعقدة

من جهة ثانية، لا يمكن ان تعود خطوة، إذا مرحلة ما يوجد بها خطأ لا يمكن الرجوع اليها وتعديلها لانها تصبح العمليات معقدة في المرحلة، حتى لو تغيير بسيط في أي مرحلة سابقة يمكن ان يسبب مشاكل كبيرة للمراحل اللاحقة حيث ان جميع المراحل تعتمد على بعضها.

النقد

من جانب آخر، في حين يجادل دعاة تطوير البرمجيات رشيقة نموذج الشلال هو عملية غير فعالة لتطوير البرمجيات، تشير بعض المتشككين بأن نموذج الشلال هو حجة كاذبة تستعمل بحتة لتسويق منهجيات التنمية البديلة

• انظر كذلك
• قائمة فلسفات تطوير البرمجيات
• أجايل
• نموذج الفوضى
• ديف أوبس
• تطوير متكرر ومتزايد
• تطوير تطبيقات سريع
• عملية تطوير البرمجيات

ومن جهة أخرى، العملاء قد لا يعرفون بالضبط ما هي متطلباتهم قبل أن يروا برنامج العمل وذلك بتغيير متطلباتها، مما أدى إلى إعادة تصميم، إعادة الإعمار، وإعادة الاختبار، وزيادة التكاليف.

ومن جهة أخرى، بعض المنظمات، مثل الولايات المتحدة وزارة الدفاع، لديها الآن التفضيل المعلن ضد منهجيات نوع شلال، بدءا MIL- STD- 498، والتي تشجع اكتساب التطوري والتنمية التكرارية وتدريجية.

وفي هذا الصدد، ردا على المشاكل التي لوحظت مع نموذج الشلال النقي، وأدخلت نماذج شلال تعديل، مثل «الساشيمي (الشلال مع مراحل متداخلة)، الشلال مع المشاريع الفرعية، والشلال مع الحد من المخاطر».

وعلى صعيد آخر، المصممين قد لا يكون على بينة من صعوبات في المستقبل عند تصميم منتج البرنامج الجديد أو الميزة. في هذه الحالة، فمن الأفضل لإعادة النظر في التصميم من التمادي في التصميم الذي لا يأخذ في الحسبان أي المكتشفة حديثا القيود، والاحتياجات، أو مشاكل.

الصيانة

لماذا نستعمله؟

• ايجابيات النموذج
• نموذج سهل للفهم
• سهل للإدارة

وفي هذا الصدد، يوفر هذا النموذج نهج منظم من خلال مراحل منفصلة يسهل فهمها وتفسيرها، ويوفر المعالم التي يسهل التعرف عليها في عملية التطوير، ويمكن ان يكون مناسب لمشاريع حيث تُصلح متطلبات نطاقها.

البناء

وفي هذا السياق، الاختبار: وهي عملية تجريب المنتج إذا كان يتشابه مع المتطلبات التي حددناها.

الإنتاج