بعد بداية رحلتنا في سلسلة تطوير البرمجيات والتحدث عن المراحل التي تمر بها أثناء عملية التطوير سنقوم في هذه المقالة بالتحدث عن أوائل النماذج العملية التي وُضعت لتنفيذ هذه المراحل، كيف تعمل، ما هي سلبياتها وما هي إيجابياتها؟ ومتى يمكن الاستفادة منها؟
يمكنك الاطلاع على المقال الأول من خلال هذا الرابط: هنا
نموذج الشلال
نموذج الشلال أولُ نموذجٍ عمليّ من نماذج دورة حياة تطوير البرمجيات SDLC (Software Development Lifecycle)، تم إنشاؤه من قبل وينستون رويس Winston Royce عام 1970. استُخدِم على نطاقٍ واسعٍ في هندسة البرمجيات لضمان نجاح المشروع. يعتمد النموذج الشلال على تقسيم عملية تطويرِ البرمجيّةِ إلى عدةِ مراحلَ منفصلةٍ عن بعضها البعض، يتم مراجعةُ كلِّ مرحلةٍ وتوثيقُها بشكلٍ كامل، لا يُمكنُ لمرحلةٍ أن تبدأ قبل انتهاء المرحلة السابقة لها ولا يُمكن للمراحل أن تتداخل فيما بينها، حيث يُعرف هذا النموذج أيضاً بـ linear-sequential life cycle model، أي أنّ المراحل فيه متسلسلةٌ خطيّة، يمثّل الخَرجُ الناتجُ عن مرحلةٍ ما، الدخلَ للمرحلة اللاحقة لها.
ما هي المراحل التسلسلية الموجودة في النموذج الشلال؟
1- جمع وتحليل المتطلبات: يتم في هذه المرحلة جمعُ كافة متطلبات النظام وتوثيقُها ضمن ما يدعى "وثيقة توصيف المتطلبات requirement specification doc".
2- تصميم النظام: تتم في هذه المرحلة دراسةُ متطلبات النظام التي تم جمعها في المرحلة السابقة وتجهيزُ تصميم النظام. حيث تساعد هذه المرحلة بتحديد متطلبات النظام والعتاد، كما تساعد أيضاً بتحديد بنية النظام العامة.
3- التنفيذ: باستخدام الخَرْجِ الناتج عن المرحلة السابقة وهي مرحلة التصميم، يتم تقسيم النظام إلى برامجَ صغيرةٍ تُدعى وحدات Units، يتم دمجها في المرحلة التالية. ويتم تطوير واختبار التوابع الوظيفية لكلٍّ واحدةٍ Unit والذي يُشار إليها باختبار الواحدة "Unit Testing".
4- الدمج والاختبار: يتم دمج كافة الوحدات المطوَّرَة في المرحلة السابقة في النظام بعد اختبارها. ويتم اختبار النظام بعد عملية الدمج بأكمله من أجل اكتشاف أيِّ خطأٍ أو فشل.
5- نشر النظام: بعد انتهاء كافة عمليات الاختبار الوظيفية وغير الوظيفية للنظام، يتم نشر المنتج في بيئة الزبون أو يتم إطلاقه في السوق.
6- الصيانة: هناك بعض المشكلات التي تظهرُ في بيئة الزبون، وذلك بعد استخدام المنتج، حيث يتم استخدام ما يُعرف بالرقع patches لحل تلك المشاكل (الـ patch هو برمجيّةٌ مصممةٌ لتحديث البرامج الحاسوبية أو المعطيات المرتبطة بها وذلك لإصلاح أو تحسين هذه البرامج). كما يتم إطلاق إصداراتٍ أفضلَ جديدةٍ من المنتج، ويتم القيام بعمليةِ الصيانةِ هذه لتسليم التغييرات الحاصلة في المنتج للزبون.
والشكل التالي يوضح المراحل السابقة:


Image: http://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm

حيثُ أتت تسمية هذا النموذج بالنموذج الشلال "Waterfall Model" نتيجةَ تتالي هذه المراحل مع بعضها البعض بشكلٍ تدفقي باتجاه الأسفل بما يشبه الشلال، فلا تبدأ مرحلةٌ قبل انتهاء المرحلة السابقة لها، ولا يمكن أن تتداخل فيما بينها.
ما هي مشاكل النموذج؟
يوجد مشكلتان أساسيتان في هذا النموذج: الأولى صعوبة التحقيق، حيث لا يجب أن تبدأ مرحلةٌ قبل أن تنتهي المرحلة السابقة لها تماماً، فلا يجبُ مثلاً أن تبدأ مرحلةُ تصميمِ النظام قبل انتهاء مرحلة تجميع وتحليل المتطلبات، أي يجب أن تكون جميع متطلبات النظام محدّدةً قبل هذه المرحلة. نظرياً، هذا عظيم. حيث سيكون لديك مجموعةٌ كاملةٌ من المتطلبات، وستكون على درايةٍ كاملة بما يريده الزبون، عندها يمكن الانتقال بثقة لمرحلة تصميم النظام.
عملياً، لن يحدث ذلك. حيث لا يمكنُ أن نرى مشروعاً يُمكِنُ تحديدُ جميعِ متطلباتِه في بداية العمل، أو ألا يحدث أيُّ تغييرٍ في أيٍّ من مكوناته أثناء عملية التطوير، لذلك فإنهاءُ مرحلةٍ ما، قبلَ أُخرى يشكِّلُ مُعضلة.
المشكلة الثانية، أنه لا يتضمن أيَّ بندٍ من أجل النسخ الاحتياطي؛ مما يعني أنه لا يمكنك العودة وإعادة التصميم في حال واجهتك أيُّ مشكلةٍ أثناء التنفيذ. وهي مشكلةٌ مشابهةٌ للمشكلة الأولى، حيث عليك الانتهاء بالكامل من المرحلة ومراجعة كلِّ شيءٍ بالتفصيل قبل الانتقال للمرحلة التالية. في الواقع، فإنّ هذا غيرُ عمليّ، فالعالم لا يعمل هكذا. إذ أنّهُ ليس بإمكانك أبداً معرفةُ كلِّ ما تُريد في الوقت الذي تُريد أن تعرفه فيه تماماً.
كما يُقال، النموذج الشلال نموذجٌ نظريٌّ رائع؛ حيث يقوم بعزل المراحل عن بعضها البعض ويجعلك تعرف تماماً ما تحتاج قبل المُضيِّ قُدُماً. كما أنّهُ طريقةٌ جيدةٌ للبدء بالتفكير بالمشاريع الضخمة جداً، بالإضافة إلى أنه نموذجٌ جيدٌ لفِرَق العمل ذات الخبرة المحدودة، فهو يرشدهم عبر دورة حياة البرمجيّة بشكلٍ واضح، لكنَه ليس بنموذجٍ عمليٍّ جيد.
متى يمكننا تطبيق نموذج الشلال؟
كلُّ برنامج يتم تطويره بشكلٍ مختلف ويتطلب منهجيةَ SDLC مناسبةً لتطويره، وذلك بالاعتماد على مجموعةٍ من العوامل الداخلية والخارجية. بعضُ الحالات التي يكون فيها استخدامُ النموذج الشلال هو الأنسب:
-المتطلبات موثّقةٌ بشكلٍ جيد، واضحة وثابتة (لن تتغير).
-تعريفُ المنتج مستقر.
-التكنولوجيا مفهومة وليست ديناميكية.
-لا تُوجدُ متطلباتٌ غامضة.
-الموارد والخبرة المطلوبة متوفرةٌ لدعم المنتج.
-المشروع مُوجَز.
-ما هي إيجابيات وسلبيات النموذج الشلال؟
الإيجابيات:
-بسيطٌ وسهلُ الفهم والاستخدام.
-سهلُ الإدارة نظراً لصلابته، حيثُ أنّه لكلِّ مرحلةٍ نواتجُ محددةٌ وعمليةُ مُراجعة.
-تتم معالجة المراحل وإنهاؤها في وقتٍ واحد.
-يعملُ بشكلٍ جيدٍ في المشاريع الصغيرة والتي تكون متطلباتها مفهومةً بشكلٍ جيدٍ جداً.
-المراحلُ المحدّدة واضحة.
-Milestones مفهومة جيداً (milestone هي نقاط يتم تحديدها على خط سير المشروع لتقسيمه لمراحل، ومن الممكن الاستفادة من هذه المراحل في تحديد الخط الزمني وإجراء اختباراتٍ مرحلية).
-سهولة ترتيب المهام.
-يتم توثيق العمليات والنتائج بشكلٍ جيد.
السلبيات:
-لا يتم إنتاج أيِّ برمجيةٍ قابلةٍ للعمل حتى انتهاء دورة الحياة بكاملها.
-كميةٌ كبيرة من المخاطر والشك.
-غير مناسبٍ للمشاريع المعقّدة وغرضية التوجه.
-غير مناسبٍ للمشاريع ذات المتطلبات المتغيرة.
-من الصعب قياس مدى التقدم خلال المراحل.
-نموذجٌ ضعيف بالنسبة للمشاريع الطويلة والمستمرة.
-لا يمكنه استيعاب المتطلبات المتغيرة.
-أيُّ تعديلٍ في نطاق المشروع ضمنَ دورة حياته يمكن أن ينهيه.
-لا يُسمح بتحديد أي اختناقاتٍ أو تحدياتٍ في التكنولوجيا أو الأعمال التجارية في وقتٍ مبكر.
-فيه ضياعٌ كبير للوقت وذلك لانتظار انتهاء المرحلة السابقة تماماً.
-صعوبة اختبار النظام.

Backing Up the Waterfall
تمت إضافة عملية النسخ الاحتياطي للنموذج الشلال، حيث يتم القيام بنسخٍ احتياطي للمرحلة السابقة عند اكتشاف خطأٍ في المرحلة الحالية. يقول هذا النموذج "Waterfall with Feedback Model" أنك ستضطر لأن تبدأ المشروع بمراحلَ غيرِ مكتملة، ثم سيتوجب عليك العودة إليها عند معرفة معلوماتٍ جديدة حول المشروع، يمكن أن تكون هذه المعلومات متطلباتٍ جديدة، تحديثاً للمتطلبات الأساسية، عيوباً في التصميم، عيوباً في خطط الاختبار، وما شابه ذلك. أيٌّ مما سبق يتطلبُ العودة إلى المراحل السابقة لتدارك المشاكل.
لا يزال هذا النموذج محافظاً على صلابته، كما أنه يملك إيجابيات النموذج الشلال، إلا أنه يملك مشكلتين رئيسيتين، أنه أفسدَ الجدولة الخاصة بك وأنه من الصعب جداً معرفة الوقت الحقيقي للانتهاء؛ فمن الممكن أن تطرأ تغييراتٌ في أي لحظة، لذلك ظهر نموذجٌ جديد يحل مشكلة الجدولة والشك.
النماذج التي ظهرت كتحسينٍ للنموذج الشلال والتغلب على سلبياته:
نموذج Sashimi:
نموذجٌ معدّلٌ عن النموذج الشلال، حيثُ المراحلُ نفسها الموجودة في النموذج الشلال، إلا أنه يمكن للمراحل في هذا النموذج أن تتداخل فيما بينها بالإضافة إلى اعتماد مبدأ التغذية الراجعة مما يعطى العديد من المزايا. كمثالٍ على هذه المزايا، أنه لا يوجد هدرٌ للوقت، فقبل أن تنتهي المرحلة I تكون المرحلة II قد بدأت فعلاً. بالإضافة إلى ذلك وبسبب تداخل المراحل، فإنه يمكن العودة لمرحلةٍ سابقة عندما نريد، ويمكن لنا اكتشاف الأخطاء في وقتٍ مبكر مما يساعد في التقليل من إعادة العمل وتقديم منتجٍ أفضل. حيث أن أسلوب التكرار الموجود في هذا النموذج يسمح بالقضاء أو الحدِّ من التكاليف المرتبطة بالنموذج الشلال، ولكن يجب على فريق الإنتاج أو المدراء الحذرُ لتجنب تكرار مرحلةٍ سابقة تم الانتهاء منها، أو القيام بالكثير من التكرارات التي تؤثر بشكلٍ سلبيٍّ على نجاح المُنتَج.
نموذج Aorta Life Cycle Model:
الفرق في هذا النموذج أنه يعتمد كثيراً على التغذية الراجعة من المراحل، قبل التقدم إلى المرحلة التالية.
نموذج V Waterfall Model:
يقوم هذا النموذج بتنفيذ عملياته بطريقةٍ متسلسلة تشبه الحرف V، يُعرف أيضاً بنموذج التحقيق والتحقُّق Verification and Validation model. هو عبارةٌ عن امتدادٍ للنموذج الشلال حيث يقوم على ربطِ مرحلةِ اختبارٍ بكلِّ مرحلةِ تطويرٍ مُقابِلة؛ هذا يعني أنّه لكلِّ مرحلةٍ من دورة التطوير، مرحلةُ اختبارٍ مرتبطةٌ بها بشكلٍ مباشر. وهو نموذجٌ منضبطٌ للغاية ولا تبدأ فيه مرحلةٌ قبل انتهاء المرحلة السابقة. تُنفَّذُ مراحل الاختبار المرتبطة بمراحل التطوير، على التوازي؛ حيث تمثّل مراحل التطوير أو التحقيق (Verification) الجانبَ الأول من الشكل V، بينما تمثّل مراحل الاختبار أو التحقق (Validation) الجانبَ الآخر.
والصورة التالية توضّح هذا النموذج


Image: http://www.tutorialspoint.com/sdlc/sdlc_v_model.htm

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

المصادر:
هنا
هنا
Software Development and Professional Practice - Copyright © 2011 by John Dooley - ISBN-13 (electronic): 978-1-4302-3802-7