نموذج الشلال

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

"نموذج الشلال" غير المعدل. يتدفق التقدم من الأعلى إلى الأسفل، مثل شلال متتالي.

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

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

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

عقد أول عرض واصفاً استخدام مراحل مماثلة في هندسة البرمجيات من قبل هربيرت د. بينينجتون في ندوة حول أساليب البرمجة المتقدمة لأجهزة الكمبيوتر الرقمية يوم 29 يونيو عام 1956.[2] ، وكان هذا عرض حول تطوير البرمجيات ل SAGE . عام 1983 أُعيد نشر الورقة مع تقديم من بينينجتون مشيراً إلى أن العملية لم تكن في الواقع من أعلى إلى أسفل ولكنها تعتمد على النموذج الأصلي.[1] وكثيرا ما يستشهد أول وصف رسمي لنموذج الشلال على أنه مقالة ونستون رويس التي طرحها عام 1970 [3]، وذلك رغم أن رويس لم يستخدم مصطلح شلال في تلك المادة. قام رويس بعرض هذا هذا النموذج على أنه نموذج خاطئ وغير عامل؛ وهي الطريقة التي تستخدم هذا المصطلح في الكتابة عن تطوير البرمجيات لوصف رؤية نقدية لممارسات تطوير البرمجيات شائعة الاستخدام.[4] أقرب استخدام لمصطلح «الشلال» قد يكون في ورقة بيل وثاير في عام 1976.[5]

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

النموذج

في نموذج الشلال الأصلي ل رويس، يتم اتباع المراحل التالية:

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

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

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

لماذا نستخدمه؟

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

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

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

متى نستخدمه؟

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

دعم الادلة

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

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

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

النقد

العملاء قد لا يعرفون بالضبط ما هي متطلباتهم قبل أن يروا برنامج العمل وذلك بتغيير متطلباتها، مما أدى إلى إعادة تصميم، إعادة الإعمار، وإعادة الاختبار، وزيادة التكاليف.[12] المصممين قد لا يكون على بينة من صعوبات في المستقبل عند تصميم منتج البرنامج الجديد أو الميزة. في هذه الحالة، فمن الأفضل لإعادة النظر في التصميم من التمادي في التصميم الذي لا يأخذ في الحسبان أي المكتشفة حديثا القيود، والاحتياجات، أو مشاكل.[13] ردا على المشاكل التي لوحظت مع نموذج الشلال النقي، وأدخلت نماذج شلال تعديل، مثل «الساشيمي (الشلال مع مراحل متداخلة)، الشلال مع المشاريع الفرعية، والشلال مع الحد من المخاطر».[9] بعض المنظمات، مثل الولايات المتحدة وزارة الدفاع، لديها الآن التفضيل المعلن ضد منهجيات نوع شلال، بدءا MIL- STD- 498، والتي تشجع اكتساب التطوري والتنمية التكرارية وتدريجية.[14] في حين يجادل دعاة تطوير البرمجيات رشيقة نموذج الشلال هو عملية غير فعالة لتطوير البرمجيات، تشير بعض المتشككين بأن نموذج الشلال هو حجة كاذبة تستخدم بحتة لتسويق منهجيات التنمية البديلة [15]

انظر أيضًا

المراجع
  1. Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs" (PDF). IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. doi:10.1109/MAHC.1983.10102. Retrieved 2011-03-21.
  2. United States, Navy Mathematical Computing Advisory Panel (29 June 1956), Symposium on advanced programming methods for digital computers, [Washington, D.C.]: Office of Naval Research, Dept. of the Navy, OCLC 10794738
  3. Wasserfallmodell > Entstehungskontext, Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Retrieved on 2007-11-28 from http://cartoon.iguw.tuwien.ac.at/fit/fit01/wasserfall/entstehung.html نسخة محفوظة 2020-04-16 على موقع واي باك مشين.
  4. Conrad Weisert, Waterfall methodology: there's no such thing!
  5. Bell, Thomas E., and T. A. Thayer. Software requirements: Are they really a problem? Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976.
  6. Military Standard Defense System Software Development
  7. Royce, Winston (1970), "Managing the Development of Large Software Systems" (PDF), Proceedings of IEEE WESCON 26 (August): 1–9
  8. "ترجمة وتعريف مصطلح Waterfall Model نموذج الشّلال بالعربية | ميم | قاموس ومترجم مصطلحات الأعمال"، www.meemapps.com، مؤرشف من الأصل في 4 فبراير 2020، اطلع عليه بتاريخ 04 فبراير 2020.
  9. McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules. Microsoft Press. ISBN 1-55615-900-5.
  10. "Waterfall Software Development Model". 5 February 2014. Retrieved 11 August 2014.
  11. When should you use Waterfall Model?
  12. Parnas, David L.; Clements, Paul C. (1986). "A rational design process: How and why to fake it" (PDF). Software Engineering, IEEE Transactions: 251–257. Retrieved 2011-03-21.
  13. McConnell, Steve (2004). Code Complete, 2nd edition. Microsoft Press. ISBN 1-55615-484-4.
  14. Larman, Craig; Basili, Victir (2003). "Iterative and Incremental Development: A Brief History". IEEE Computer (June ed.
  15. A Waterfall Systems Development Methodology … Seriously? David Dischave 2012
  • بوابة إدارة أعمال
  • بوابة تقنية المعلومات
  • بوابة علم الحاسوب
  • بوابة هندسة
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.