نموذج الشلال
هذه المقالة بحاجة إلى التحديث . ( أكتوبر 2021 ) |

نموذج الشلال هو تقسيم أنشطة التطوير إلى مراحل متسلسلة خطية ، مما يعني أن كل مرحلة تنتقل إلى بعضها البعض، حيث تعتمد كل مرحلة على مخرجات المرحلة السابقة وتتوافق مع تخصص المهام. [1]
هذا النهج نموذجي لمجالات معينة من التصميم الهندسي . في تطوير البرمجيات ، [1]
يميل إلى أن يكون من بين الأساليب الأقل تكرارًا ومرونة، حيث يتدفق التقدم في اتجاه واحد إلى حد كبير (إلى أسفل مثل الشلال ) من خلال مراحل التصور والبدء والتحليل والتصميم والبناء والاختبار والنشر والصيانة . [2] نموذج الشلال
هو أقدم نهج لدورة حياة تطوير الأنظمة ( SDLC ) المستخدم في تطوير البرمجيات. [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] إلا أنه انتقد الالتزام الصارم بالمراحل التالية:
- متطلبات النظام والبرمجيات : تم تسجيلها في وثيقة متطلبات المنتج
- التحليل : ينتج عنه نماذج ومخططات وقواعد عمل
- التصميم : مما أدى إلى هندسة البرمجيات
- الترميز : تطوير وإثبات وتكامل البرمجيات
- الاختبار : الاكتشاف المنهجي للعيوب وتصحيحها
- العمليات : التثبيت ، والنقل ، والدعم ، والصيانة للأنظمة الكاملة
وهكذا، يؤكد نموذج الشلال أنه ينبغي الانتقال إلى مرحلة معينة فقط بعد مراجعة المرحلة السابقة لها والتحقق منها.
ومع ذلك، يمكن أن تتضمن نماذج الشلال المعدلة المختلفة (بما في ذلك نموذج رويس النهائي) اختلافات طفيفة أو كبيرة في هذه العملية. [8] تتضمن هذه الاختلافات العودة إلى الدورة السابقة بعد العثور على عيوب في مجرى النهر، أو العودة إلى مرحلة التصميم إذا اعتُبرت المراحل اللاحقة غير كافية.
الحجج الداعمة
إن الوقت الذي يتم إنفاقه في وقت مبكر من دورة إنتاج البرمجيات يمكن أن يقلل التكاليف في المراحل اللاحقة. على سبيل المثال، فإن المشكلة التي يتم اكتشافها في المراحل المبكرة (مثل تحديد المتطلبات) تكون أرخص في الإصلاح من نفس الخطأ الذي يتم اكتشافه لاحقًا في العملية (بعامل يتراوح من 50 إلى 200). [17]
في الممارسة الشائعة، تؤدي منهجيات الشلال إلى جدول زمني للمشروع مع استثمار 20-40% من الوقت في المرحلتين الأوليين، و30-40% من الوقت للترميز، والباقي مخصص للاختبار والتنفيذ. نظرًا لأن تنظيم المشروع يحتاج إلى هيكلة عالية، فإن معظم المشاريع المتوسطة والكبيرة ستشمل مجموعة مفصلة من الإجراءات والضوابط، والتي تنظم كل عملية في المشروع. [18] [ فشل التحقق ]
هناك حجة أخرى تدعم نموذج الشلال وهي أنه يركز على التوثيق (مثل وثائق المتطلبات ووثائق التصميم) بالإضافة إلى الكود المصدر . [ بحاجة لمصدر ] في المنهجيات الأقل تصميمًا وتوثيقًا، تُفقد المعرفة إذا غادر أعضاء الفريق قبل اكتمال المشروع، وقد يكون من الصعب على المشروع التعافي من الخسارة. إذا كانت وثيقة التصميم العاملة بالكامل موجودة (كما هو الحال في نية التصميم الكبير في المقدمة ونموذج الشلال)، فيجب أن يتمكن أعضاء الفريق الجدد والفرق الجديدة من التعرف على المشروع من خلال قراءة الوثائق. [19]
يوفر نموذج الشلال نهجًا منظمًا؛ حيث يتقدم النموذج نفسه خطيًا عبر مراحل منفصلة وسهلة الفهم والتفسير وبالتالي يسهل فهمه. كما يوفر أيضًا معالم يمكن التعرف عليها بسهولة في عملية التطوير، وغالبًا ما يتم استخدامه كمثال أولي لنموذج التطوير في العديد من نصوص ودورات هندسة البرمجيات. [20]
وعلى نحو مماثل، يمكن للمحاكاة أن تلعب دوراً قيماً في نموذج الشلال. فمن خلال إنشاء محاكاة حاسوبية أو رياضية للنظام الذي يجري تطويره، يمكن للفرق أن تكتسب رؤى حول كيفية أداء النظام قبل الانتقال إلى المرحلة التالية. وتسمح المحاكاة باختبار وتحسين التصميم، وتحديد المشكلات أو الاختناقات المحتملة، واتخاذ قرارات مستنيرة بشأن وظائف النظام وأدائه.
نقد
قد لا يعرف العملاء المتطلبات الدقيقة قبل أن يروا البرنامج العامل وبالتالي يغيرون متطلباتهم فيما بعد، مما يؤدي إلى إعادة التصميم وإعادة التطوير وإعادة الاختبار وزيادة التكاليف. [21]
قد لا يكون المصممون على دراية بالصعوبات المستقبلية عند تصميم منتج أو ميزة برمجية جديدة، وفي هذه الحالة فإن مراجعة التصميم في البداية يمكن أن تزيد من الكفاءة مقارنة بتصميم غير مبني لمراعاة القيود أو المتطلبات أو المشكلات المكتشفة حديثًا. [22]
قد تحاول المنظمات التعامل مع نقص المتطلبات الملموسة من العملاء من خلال توظيف محللي الأنظمة لفحص الأنظمة اليدوية الحالية وتحليل ما تفعله وكيف يمكن استبدالها. ومع ذلك، من الصعب عمليًا الحفاظ على الفصل الصارم بين تحليل الأنظمة والبرمجة، [23] حيث أن تنفيذ أي نظام غير تافه غالبًا ما يكشف عن قضايا وحالات هامشية لم يأخذها محلل الأنظمة في الاعتبار.
بعض المنظمات، مثل وزارة الدفاع الأمريكية، لديها الآن تفضيل واضح ضد منهجيات نوع الشلال، بدءًا من MIL-STD-498 التي تم إصدارها في عام 1994، والتي تشجع على الاستحواذ التطوري والتطوير التكراري والتدريجي . [24]
نماذج الشلال المعدلة
استجابةً للمشكلات الملحوظة في نموذج الشلال "الخالص"، تم تقديم العديد من "نماذج الشلال المعدلة". وقد تعالج هذه النماذج بعض أو كل الانتقادات الموجهة إلى نموذج الشلال "الخالص".
تتضمن هذه النماذج نماذج التطوير السريع التي يطلق عليها ستيف ماكونيل "الشلالات المعدلة": [17] "نموذج الساشيمي" لبيتر دي جريس (شلال بمراحل متداخلة)، وشلال بمشاريع فرعية، وشلال مع تقليل المخاطر. توجد أيضًا مجموعات أخرى من نماذج تطوير البرمجيات مثل "نموذج الشلال التدريجي". [25]
النموذج النهائي لرويس
النموذج النهائي لوينستون دبليو رويس ، التحسين المقصود على "نموذج الشلال" الأولي الخاص به، أوضح أن ردود الفعل يمكن (يجب، وغالبًا ما تفعل) أن تؤدي من اختبار الكود إلى التصميم (حيث كشف اختبار الكود عن عيوب في التصميم ) ومن التصميم إلى مواصفات المتطلبات (حيث قد تتطلب مشاكل التصميم إزالة المتطلبات المتضاربة أو غير القابلة للإرضاء / غير القابلة للتصميم). في نفس الورقة، دعا رويس أيضًا إلى كميات كبيرة من الوثائق، وإنجاز المهمة "مرتين إذا أمكن" (شعور مشابه لشعور فريد بروكس ، المشهور بكتابة شهر الرجل الأسطوري - وهو كتاب مؤثر في إدارة مشاريع البرمجيات - الذي دعا إلى التخطيط "لرمي واحد بعيدًا")، وإشراك العميل قدر الإمكان (شعور مشابه لشعور البرمجة المتطرفة ).
ملاحظات رويس على النموذج النهائي هي التالية:
- تصميم البرنامج بالكامل قبل البدء في التحليل والترميز
- يجب أن تكون الوثائق حديثة وكاملة
- قم بأداء المهمة مرتين إذا كان ذلك ممكنا
- يجب التخطيط للاختبار والتحكم فيه ومراقبته
- اشراك العميل
انظر أيضا
- قائمة فلسفات تطوير البرمجيات
- تطوير البرمجيات الرشيقة
- تصميم كبير في المقدمة
- نموذج الفوضى
- ديف أوبس
- التطوير التكراري والتدريجي
- مراقبة دورة حياة الصيانة
- التحليل والتصميم الموجه نحو الكائنات
- تطوير التطبيقات السريع
- عملية تطوير البرمجيات
- نموذج حلزوني
- طريقة تحليل وتصميم النظم المنظمة (SSADM)
- منهجية تطوير النظام
- الهندسة التقليدية
- نموذج V
مراجع
- ^ ab Petersen, Kai; Wohlin, Claes; Baca, Dejan (2009). "نموذج الشلال في التطوير واسع النطاق". في Bomarius, Frank; Oivo, Markku; Jaring, Päivi; Abrahamsson, Pekka (eds.). تحسين عملية البرمجيات الموجهة نحو المنتج . محاضرات في معالجة المعلومات التجارية. المجلد 32. برلين، هايدلبرغ: سبرينغر . ص. 386-400. رمز Bibcode :2009pfsp.book..386P. doi :10.1007/978-3-642-02152-7_29. ISBN 978-3-642-02152-7.
- ^ توم جيلب . "التوصيل التطوري مقابل "نموذج الشلال"
" ملاحظات هندسة البرمجيات ACM SIGSOFT . 10 (3): 49–61. doi : 10.1145/1012483.1012490.
- ^ ليندا شيريل (2013). "نموذج الشلال". موسوعة العلوم والأديان (ALC Runehov؛ L. Oviedo (المحرران)) . دوردرخت ، هولندا: سبرينغر : 2343–2344. doi :10.1007/978-1-4020-8265-8_200285. ISBN 978-1-4020-8264-1.
- ^ أندرياس ب. شميت؛ كريستين كونزمان (16 سبتمبر 2014). التصميم من أجل نضج المعرفة: من البرمجيات القائمة على المعرفة إلى دعم تيسير تطوير المعرفة . i-KNOW '14: وقائع المؤتمر الدولي الرابع عشر حول تقنيات المعرفة والأعمال القائمة على البيانات. ACM . ص. 1-7. doi :10.1145/2637748.2638421.
- ^ الولايات المتحدة، اللجنة الاستشارية للحوسبة الرياضية التابعة للبحرية (29 يونيو 1956)، ندوة حول أساليب البرمجة المتقدمة لأجهزة الكمبيوتر الرقمية ، [واشنطن العاصمة]: مكتب البحوث البحرية، وزارة البحرية، OCLC 10794738
- ^ بينينجتون، هربرت د. (1 أكتوبر 1983). "إنتاج برامج الكمبيوتر الكبيرة" (PDF) . حوليات تاريخ الحوسبة في معهد مهندسي الكهرباء والإلكترونيات . 5 (4). قسم الأنشطة التعليمية في معهد مهندسي الكهرباء والإلكترونيات: 350-361. doi :10.1109/MAHC.1983.10102. S2CID 8632276. تم الاسترجاع في 2011-03-21 .تم أرشفته في 18 يوليو 2011 على موقع Wayback Machine
- ^ Larman, Craig; Basili, Victor (June 2003). "التطوير التكراري والتزايدي: تاريخ موجز" (PDF) . Computer . 36 (6): 47–56. doi :10.1109/MC.2003.1204375.
- ^ abcd Royce, Winston (1970), "Managing the Development of Large Software Systems" (PDF) , Proceedings of IEEE WESCON , 26 (August): 1–9
- ^ "الشلال". جامعة بريمن - الرياضيات وعلوم الكمبيوتر .
- ^ عباس، نورا؛ جرافيل، أندرو م؛ ويلز، جاري ب. (2008). "الجذور التاريخية لأساليب Agile: من أين جاء "التفكير Agile"؟" (PDF) . في أبراهامسون، بيكا؛ باسكرفيل، ريتشارد؛ كونبوي، كيران؛ فيتزجيرالد، برايان؛ مورغان، لورين؛ وانج، شياوفينج (المحررون). العمليات الرشيقة في هندسة البرمجيات والبرمجة المتطرفة . مذكرات محاضرات في معالجة المعلومات التجارية. المجلد 9. برلين، هايدلبرغ: سبرينغر . ص 94-103. doi :10.1007/978-3-540-68255-4_10. ISBN 978-3-540-68255-4.
- ^ كونراد ويزرت، منهجية الشلال: لا يوجد شيء من هذا القبيل!
- ^ Lineberger, Rob (25 أبريل 2024). Inheriting Agile: The IT Practitioner's Guide to Managing Software Development in a Post-Agile World. Durham, NC: Sandprint Press. p. 36. ISBN 9798989149605.
- ^ بيل، توماس إي، وتا ثاير. متطلبات البرمجيات: هل هي مشكلة حقيقية؟ وقائع المؤتمر الدولي الثاني حول هندسة البرمجيات. مطبعة جمعية مهندسي الكهرباء والإلكترونيات، 1976.
- ^ ab DOD-STD-2167 - Military Standard : Defence System Software Development" . وزارة الدفاع، الولايات المتحدة الأمريكية. 1985-06-04. ص. 11.
- ^ "تطوير برمجيات نظام الدفاع القياسي العسكري" (PDF) .
- ^ Lineberger, Rob (25 أبريل 2024). Inheriting Agile: The IT Practitioner's Guide to Managing Software Development in a Post-Agile World. Durham, NC: Sandprint Press. p. 37. ISBN 9798989149605.
- ^ ab McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules. Microsoft Press. ISBN 1-55615-900-5.
- ^ "نموذج تطوير البرمجيات الشلال". 5 فبراير 2014. تم الاسترجاع في 11 أغسطس 2014 .
- ^ تقنيات Arcisphere (2012). "Tutorial: The Software Development Life Cycle (SDLC)" (PDF) . تم الاسترجاع في 2012-11-13 .
- ^ هيوجي، دوغلاس (2009). "مقارنة تحليل وتصميم الأنظمة التقليدية بمنهجيات Agile". جامعة ميسوري – سانت لويس . تم الاسترجاع في 11 أغسطس 2014 .
- ^ بارناس، ديفيد إل.؛ كليمنتس، بول سي. (1986). "عملية تصميم عقلانية: كيف ولماذا نتظاهر بها" (PDF) . معاملات معهد مهندسي الكهرباء والإلكترونيات في هندسة البرمجيات (2): 251-257. doi :10.1109/TSE.1986.6312940. S2CID 5838439. تم الاسترجاع في 2011-03-21 .
- ^ McConnell, Steve (2004). Code Complete، الطبعة الثانية. Microsoft Press. ISBN 1-55615-484-4.
- ^ Ensmenger, Nathan (2010). The Computer Boys Take Over . MIT Press. p. 42. ISBN 978-0-262-05093-7.
- ^ Larman, Craig; Basili, Victir (2003). "التطوير التكراري والتزايدي: تاريخ موجز". IEEE Computer . 36 (6) (يونيو ed.): 47–56. doi :10.1109/MC.2003.1204375. S2CID 9240477.
- ^ "المنهجية: أساليب التصميم".
روابط خارجية
- فهم إيجابيات وسلبيات نموذج الشلال في تطوير البرمجيات
- نماذج دورة حياة المشروع: ما هي الاختلافات بينها ومتى يتم استخدامها
- عبور الشلال باستخدام RUP بقلم فيليب كروشتن
- تتعاون CSC وIBM Rational لتقديم C-RUP ودعم التغيير السريع في الأعمال
- ج2:شلال
- [1]
