نموذج الشلال

نموذج الشلال هو عملية تنفيذ مراحل دورة حياة تطوير البرمجيات (SDLC) النموذجية بترتيب تسلسلي . تُستكمل كل مرحلة قبل البدء بالمرحلة التالية، وتُحدد نتائج كل مرحلة المراحل اللاحقة. ^{[ 1 ]} بالمقارنة مع منهجيات دورة حياة تطوير البرمجيات البديلة، مثل منهجية أجايل ، يُعد نموذج الشلال من بين الأقل تكرارًا ومرونة، ^{[ 1 ]} حيث يسير التقدم في اتجاه واحد إلى حد كبير (مثل الشلال ) عبر مراحل التصور، وتحليل المتطلبات ، والتصميم ، والبناء ، والاختبار ، والنشر، والصيانة . ^{[ 2 ]} يُعد نموذج الشلال أقدم منهجية لدورة حياة تطوير البرمجيات. ^{[ 3 ]} عند اعتماده لأول مرة، لم تكن هناك بدائل معترف بها للعمل الإبداعي القائم على المعرفة. ^{[ 4 ]}

أول عرض معروف يصف استخدام هذه المراحل في هندسة البرمجيات قدمه هربرت د. بينينجتون في ندوة أساليب البرمجة المتقدمة للحواسيب الرقمية في 29 يونيو 1956. ^{[ 5 ]} تناول هذا العرض تطوير برمجيات لنظام SAGE . في عام 1983، أعاد بينينجتون نشر بحثه مع مقدمة توضح أن المراحل نُظمت عمدًا وفقًا لتخصص المهام، مشيرًا إلى أن العملية لم تُنفذ في الواقع بطريقة هرمية صارمة، بل اعتمدت على نموذج أولي. ^{[ 6 ]}

على الرغم من عدم استخدام مصطلح "النموذج التتابعي" في هذه الورقة، إلا أن أول رسم تخطيطي رسمي ومفصل لهذه العملية يُستشهد به غالبًا ^{[ 7 ]} باعتباره مأخوذًا من مقال نُشر عام 1970 بقلم وينستون دبليو . رويس. ^{[ 8 ] [ 9 ] [ 10 ]} ومع ذلك، فقد علّق رويس على وجود عيوب جوهرية في هذا النموذج، نابعة من اقتصار الاختبار على نهاية العملية، وهو ما وصفه بأنه "محفوف بالمخاطر ويؤدي إلى الفشل". ^{[ 8 ]} وقدّم في بقية ورقته خمس خطوات رأى أنها ضرورية "للقضاء على معظم مخاطر التطوير" المرتبطة بالنموذج التتابعي دون تعديل. ^{[ 8 ]} لم تلقَ خطوات رويس الخمس الإضافية (والتي تضمنت كتابة وثائق كاملة في مراحل مختلفة من التطوير) رواجًا واسعًا، لكن رسمه التخطيطي لما اعتبره عملية معيبة أصبح نقطة الانطلاق عند وصف نموذج "النموذج التتابعي". ^{[ 11 ] [ 12 ]}

ربما كان أول استخدام لمصطلح "الشلال" في ورقة بحثية نشرها بيل وثاير عام 1976. ^{[ 13 ]}

في عام 1985، اعتمدت وزارة الدفاع الأمريكية نموذج الشلال في معيار DOD-STD-2167 للعمل مع مقاولي تطوير البرمجيات. يشير هذا المعيار إلى دورات تطوير البرمجيات ^{[ 14 ]} باعتبارها "المراحل المتسلسلة لدورة تطوير البرمجيات"، وينص على أن "على المقاول تنفيذ دورة تطوير برمجيات تتضمن المراحل الست التالية: تحليل متطلبات البرمجيات، والتصميم الأولي، والتصميم التفصيلي، والبرمجة واختبار الوحدات، والتكامل، والاختبار". ^{[ 14 ] [ 15 ]}

يصف النموذج تسلسلًا خطيًا من الخطوات. على الرغم من وجود نسخ مختلفة، إلا أن ما يلي يصف جوهره. ^{[ 16 ] [ 17 ] [ 18 ] [ 19 ]}

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

في الممارسة الشائعة، تُنتج منهجيات الشلال جدولًا زمنيًا للمشروع يُخصص فيه ما بين 20% و40% من الوقت للمرحلتين الأوليين، وما بين 30% و40% للبرمجة، ويُخصص الباقي للاختبار والتنفيذ. ونظرًا لضرورة وجود هيكل تنظيمي مُحكم للمشروع، فإن معظم المشاريع المتوسطة والكبيرة تتضمن مجموعة مفصلة من الإجراءات والضوابط التي تُنظم كل عملية في المشروع. ^{[ 24 ]}

من الحجج الأخرى التي تدعم نموذج الشلال أنه يركز على التوثيق (مثل وثائق المتطلبات ووثائق التصميم) بالإضافة إلى شفرة المصدر . في المنهجيات الأقل دقة في التصميم والتوثيق، تُفقد المعرفة إذا غادر أعضاء الفريق قبل اكتمال المشروع، وقد يصعب على المشروع التعافي من هذه الخسارة. إذا كانت وثيقة تصميم كاملة وجاهزة للاستخدام (كما هو الحال في التصميم الشامل المسبق ونموذج الشلال)، فسيكون بإمكان أعضاء الفريق الجدد والفرق الجديدة التعرف على المشروع من خلال قراءة الوثائق. ^{[ 25 ]}

يُقدّم نموذج الشلال منهجًا مُنظّمًا؛ إذ يتقدّم النموذج نفسه بشكل خطي عبر مراحل منفصلة، ​​سهلة الفهم والتفسير، وبالتالي يسهل فهمه. كما يُوفّر معالم بارزة يسهل تحديدها في عملية التطوير، وغالبًا ما يُستخدم كمثال تمهيدي لنموذج تطوير في العديد من كتب ودورات هندسة البرمجيات. ^{[ 26 ]}

قد لا يعرف العملاء المتطلبات الدقيقة قبل رؤية البرنامج العامل، وبالتالي قد يغيرون متطلباتهم لاحقًا، مما يؤدي إلى إعادة التصميم وإعادة التطوير وإعادة الاختبار، وزيادة التكاليف. ^{[ 27 ]}

قد لا يكون المصممون على دراية بالصعوبات المستقبلية عند تصميم منتج أو ميزة برمجية جديدة، وفي هذه الحالة، يمكن أن تؤدي مراجعة التصميم في البداية إلى زيادة الكفاءة مقارنةً بتصميم لم يُبنَ مع مراعاة القيود أو المتطلبات أو المشكلات المكتشفة حديثًا. ^{[ 28 ]}

قد تحاول المؤسسات معالجة نقص المتطلبات المحددة من العملاء بتوظيف محللي نظم لدراسة الأنظمة اليدوية الحالية وتحليل وظائفها وكيفية استبدالها. مع ذلك، يصعب عمليًا الفصل التام بين تحليل النظم والبرمجة، ^{[ 29 ]} إذ غالبًا ما يكشف تطبيق أي نظام معقد عن مشكلات وحالات استثنائية لم يأخذها محلل النظم في الحسبان.

بعض المنظمات، مثل وزارة الدفاع الأمريكية، لديها الآن تفضيل معلن ضد المنهجيات من نوع الشلال، بدءًا من معيار MIL-STD-498 الصادر في عام 1994، والذي يشجع على الاكتساب التطوري والتطوير التكراري والتراكمي . ^{[ 30 ]}

استجابةً للمشاكل التي لوحظت في نموذج الشلال الأصلي، تم ابتكار العديد من النسخ المعدلة لمعالجة هذه المشاكل. تشمل هذه النماذج نماذج التطوير السريع التي يسميها ستيف ماكونيل "الشلالات المعدلة": ^{[ 23 ]} نموذج "الساشيمي" لبيتر ديغريس (شلال بمراحل متداخلة)، وشلال مع مشاريع فرعية، وشلال مع تقليل المخاطر. كما توجد تركيبات أخرى لنماذج تطوير البرمجيات مثل "نموذج الشلال التزايدي". ^{[ 31 ]}

أوضح نموذج رويس النهائي أن التغذية الراجعة يمكن (بل ينبغي، وغالبًا ما تفعل) أن تقود من اختبار الكود إلى التصميم (حيث يكشف اختبار الكود عن عيوب في التصميم)، ومن التصميم إلى تحديد المتطلبات (حيث قد تستلزم مشاكل التصميم إزالة المتطلبات المتضاربة أو غير القابلة للتنفيذ/التصميم). وفي الورقة البحثية نفسها، دعا رويس أيضًا إلى توثيق كميات كبيرة من الوثائق، وإنجاز المهمة "مرتين إن أمكن" ^{[ 32 ]} (وهو رأي مشابه لرأي فريد بروكس ، مؤلف كتاب "أسطورة شهر الرجل" - وهو كتاب مؤثر في إدارة مشاريع البرمجيات - الذي دعا إلى التخطيط "للتخلص من وثيقة واحدة")، وإشراك العميل قدر الإمكان (وهو رأي مشابه لمنهجية البرمجة المتطرفة ).

ملاحظات رويس على النموذج النهائي هي:

1. أكمل تصميم البرنامج قبل البدء في التحليل والبرمجة
2. يجب أن تكون الوثائق حديثة وكاملة
3. قم بالعمل مرتين إن أمكن
4. يجب تخطيط الاختبارات والتحكم فيها ومراقبتها.
5. أشرك العميل

• فهم مزايا وعيوب نموذج الشلال في تطوير البرمجيات
• نماذج دورة حياة المشروع: كيف تختلف ومتى يتم استخدامها
• عبور الشلال باستخدام جهاز RUP بقلم فيليب كروشتن
• تتعاون شركتا CSC و IBM Rational لتقديم C-RUP ودعم التغيير السريع في الأعمال.
• ج2: شلال