دورة حياة النظام البرمجي Software life cycle
دورة الحياة لغة هي الأطوار المختلفة التي يمر بها كائن حي ما في أثناء حياته.
أما إصطلاحاً في الهندسة البرمجيات فنعني به هي بناء البرنامج منذة لحظة ورود الفكرة في الذهن إلي خروج البرنامج للعميل بل و خدمة ما بعد البيع وهذا تعريقف مختصر جداً و إلا فإن دورة الحياة للنظام البرمجي طويلة و تمر بمراحل مختلفة و عديدة ليخرج للنور و يصل في أيدي العملاء و كما ذكرنا في المقال السابق أنة ليست كتابة الأكواد و الشفرات Coding هو النقطة الرئيسة في دورة الحياة تلك بل ممكن أن تكون أقلها و قتلاً و مجهوداً.
و قبل الشروع في شرح بعض نماذج دورات الحياة للنظام البرمجي Software life cycle models نتكلم باختصار عن معنى كلمة دورة حياة النظام
الشرارة الأولى
ما الذي يجبر شركة في اتخاذ قرار البدأ في برنامج معين ؟ أظن هذا لا يخرج عن سببين رئيسيين و هما: 1- الفكرة ‚ نعم و أصحاب الأفكار هم المبدعون الذين يقودون السوق ‚ فيبدأ البرنامج في أذهانهم مجرد فكرة و بمجرد وضعها علي الورق تصبح الفكرة قيد التنفيذ. 2- السبب الثاني هو احتياجات السوق الملحة ‚ و بحصر تلك الاحتياجات فتبدأ العقول في شحذ أفكارها لإخراج البرنامج المطلوب لسد تلك الاحتياجات
و بمجرد وجود فكرة البرنامج سواء كانت من أي سبب فأنت تملك الشرارة الأولى التي تظنها في منتهى الصغر و لكنها ستشعل المحرك الذي بدورة سيحرك قطار كبير من الأفكار و الأدوات و القوى البشرية و التي توصلك في النهاية لاستخراج برنامج قوي و هذا ما نحلم به بالأخص في منطقتنا العربية.
والآن بدأ العمل
ربما تظن أن الآن يبدأ العمل ... لا ‚ بل قد بدأ بالفعل و نحن في الشرارة الأولى ‚و لا تظن أخي أن هذا وقت التشفير أو كتابة الأكواد Coding ‚ و هذا ما يحدث للأسف في معظم الشركات إلا الكبير منهافقط الذي يتنبنى العمل بـ نموج بناء لعملية إنتاج نظام برمجي software process فننتقل بعد الاتفاق علي الفكرة مراحل الانتاج الفعلي و هي التخطيط مروراً بالتصميم ثمكتابة الأكواد و تبدأ مراحل الاختبار بأنواعها ثم التقييم ثم التوزيع للعملاء و خدمات ما بيعد البيع
و كل هذه المراحل تختلف في الاحتياجات من حيث الموارد البشرية و الوقت و باختلاف النموذج المتبع لانتاج نظام برمجي Software process ستختلف مراحل الانتاج و أوقاتها بل و أهميتها أيضاً
و نشرع الآن في شرح نماذج دورة حياة النظام البرمجي :
نموذج المراحل المتتابعة Stagewise model
يعد هذا النوذج بأنة هو النموذج التقليدي لدورة حياة النظم البرمجية ‚ و تعتمد علي فكرة تقسيم خطوات إنشاء برنامج حاسوبي إلي مراحل تتم بالتتابع و لا يتم الانتقال من مرحلة إلا بعد استكمال المرحلة السابقة لها تماماً.فعملية إنشاء برنامج حاسوبي تبدأ من مرحلة التخطيط و هي تشمل جمع قائمة بالمتطلبات Requirements و بخصائص البرنامج و مميزاتة Features ‚ و كلما كانت تلك المرحلة محكمة و مكتملة كانت فرصة نجاح المنتج كبيرة ‚ ثم يتم الانتقال إلي مرحلة التصميم و هي مثل المرحلة السابقة في كونها لابد أن تكون محمكة و مكتملة ثم كتابة الشفرات ثم الاختبار ثم التقييم.
تكمن المشكلة الرئيسية في هذا النموذج من نماذج دورات حياة النظم الحاسوبية أنه لا يمكنك فعلياً إنهاء مرحلة كاملة مع عدم وجود أي نوع من أنواع الرجوع للمرحلة السابقة أو رؤية مستقبلية للمرحلة التالية مما يوقع المشروع في أخطاء لم تكن بالحسبان ‚ مثال لذلك : من الصعوبة بمكان أن تكون في مرحلة التصميم و تريد أن تنتهي منها مع عدم كتابة أي كود و مثال أوضح : ما هي فائدة أن تصل إلي مرحلة الاختبارات و أنت عاجز عن الرجوع لمرحلة كتابة الشفرات حتى تقوم بإصلاح الأخطاء إن وجدت – و غالباً ما توجد- فتأمل.
و لما فشل الرد عن تلك الأمثلة فأصبحنا مضطريين لإضافة بعض التعديلات و التحسينات علي ذلك النوذج فظهر في الأفق نموذج جديد وهو نموذج الشلال waterfall model.
نموذج الشلال waterfall model
في أوائل السبعينات تمت إضافة بعض التعديلات و التحسينات علي نموذج المراحل المتتابعة Stagewise model و كان التحديث الرئيسي هو وجود نوع من أنواع تَغْذِيَةٌ مُرْتَجِعَةٌFeedback بين المراحل بعضها و بعض سواء المراحل السابقة أو التالية و بالطبع هي نفس المراحل السابقة في المنوذج السابق (التخطيط – التصميم – كتابة الشفرات – الاختبار - التقييم) و لكن فقط يختلف الانتقال من مرحلة إلي أخرى مع إمكانية عمل تجاوزات Overlap (أي البدء ثم الرجوع ثم البدء – و تسمي تراكيب أو تجاوزات) و من هنا نسمح لتعديل طرء علي مرحلة ما بأن ينعكس علي المراحل الأخرى أو العكس بأن يتم القيام بجزء من مرحلة قبل الانتهاء من المرحلة الحالية مما يفك كثيراً من الجمود الذي كان في نموذج المراحل المتتابعة stagewise model.و معظم المشاريع تبدأ بنفس الطريقة و هي فقط إعداد قائمة بالمتطلبات و الخصائص و المميزات و تكون نسبة نجاح تلك الطريقة (النموذج) أكبر كلما كان المشروع (المنتج ) صغيراً.
فائدة: أحترس دائما من تعديلات و طلبات العميل الجديدة ففي كثيراً من الأحيان لا يكون هدف البرنامج متضح كاملاً في ذهن العميل فبالتالي تطرأ التعديلات و التحسينات و يمكنك نموذج الشلال في أن ترجع إلي مرحلة سابقة و هي مرحلة التصميم و تنظر أنت كمدير للمشروعات أن التعديل متاح و سهل ثم تنزلق قدمك في تعديلات و تحسينات لا تنتهي و بالتالي تستمر الدائرة إلي ما لا نهاية مما ينذر بتأخر المشروع أو عدم تسليمه بالمرة.
و تظهر هنا عيوب ذلك النموذج حيث أنه لن يكون بالديناميكية الكافية لتواجه تلك التعديلات التي لا تنتهي و لن تستطيع التجاوزات و التراكيب Overlap بعمل رد كامل لجزء كبير من مرحلة لتواكب تلك التعديلات أو المطلب الجديد للعميل
الطريقة الحلزوني The Spiral method
تم تقديم تلك الطريقة بواسطة باري دبليو بوهم Barry W. Boehm سنة 1988 و كان الدافع لذلك هو التعرف علي الأخطاء و المشاكل الغير متوقعة و التعديلات في المتطلبات التي غالباً ما تصيب تقدم المشروع.
و تعد الطريقة الحلزونية فرد من أفراد عائلة إدارة هندسة البرمجيات بطريقة العمليات التكرارية Iterative process (و هي تكرار خوارزم كل مسألة محددة بحيث يكون المخرج من أي مرحلة هو المدخل للمرحلة الثانية)
و الحلزون يتكون منعدد من الدورات أو الدورانات (Cycle ‚ spin) و كل دورة مرتبطة بالدورة التي تليها و الدورة التالية دائما أكبر من الدورة السابقة و هكذا حتى ينتهي الحلزون
من هنا يتضح بأن كل دورة ستكون وحدة متكاملة لإنتاج مرحلة من مراحل المشروع و بالتالي فإن الفكرة الرئيسية لهذه الطريقة هي أنك لا تقلق بأن يحدث خطأ ما أو تعديل ما فأنك سوف تكون قادراً علي إصلاة و القيام به في الدورة القادمة و هكذا حتى تنتهي الدورات و يخرج المشروع للنور
و تعتمد مراحل الطريقة الحلزونية تقريبا علي نفس مراحل الطرق السابقة لكن مع بعض التعديلات ‚ فتأتي مرحلة الاستكشاف discovery كأول مرحلة و هي المتعلقة بجمع المتطلبات و تحديد الأهداف Objectives . و في خلال مرحلة الاستكشاف ربما نضطر لكتابة بعض الأكواد الأولية Prototypes
أما المرحلة الثانية و هي أكبر المراحل أهمية هي التقييم Evaluation فهي المنوطة بتقدير المهام الأكثر خطورة في الدورة الحالية
أما المرحلة الثالثة هي مرحلة البناء و التطوير Development و يتم فيها بناء المهمات التي تم توضيح خطورتها في مرحلة التقييم ( المرحلة الثانية ) و نضرب لذلك مثالاً : لو نتج عن مرحلة التقييم أن الخوارزم Algorithm المكتوب يحتمل أن يكون صعباً جداً أو ربما مستحيلاً فستكون المهمة الرئيسية في المرحلة الثالثة في الدورة الحالية هي تمثيل ز بناء و اختبار ذلك الخواريزم
و نصل إلي المرحلة الرابعة و هي التحليل و التخطيط
و بهذا نكون قد أنهينا دورة كاملة في الحلزون و ننتقل للدروة التالية و هكذا حتى ننتهي و من المتوقع أن يكون كل دورة قصيرة الوقت و هذا يعتمد علي نتائج الدورة السابقة لها
مميزات و عيوب الطريقة الحلزونية
اعطائنا الأولية للقيام بالمهام الكبر خطورة يعطي فرصة أكبر لنجاح المشروع لأنك تتجنب الكثير من المخاطر التي غالباً ما تحدث في أي مشروع أو تحت ضغط المتطلبات الجديدة التي قد تطرأ علي النظام و هذا يمثل ميزة كبيرة للطريقة الحلزونية و بتكرار التحليل و التخطيط و تجديدهما في كل دورة من دورات الطريقة الحلزونية فذلك يزيل معظم العوائق الكامنة في طريق إنهاء المشروع. فإنك مع كل دورة من الدورات تحصل علي ميزة جديدة و معرفة أكبر بالمشروع مما يثري التصميم و يصب ذلك كملة في مصلحة المشروع و خروجة بشكل قوي.
تكمن العيوب الرئيسية في تلك الطريقة في صعوبة الحصول علي مخرج نهائي أو تقييم لتطور المشروع بعد كل دورة من الدورات . و ربما في أسؤ الحالات تتحول الطريقة إلي طريقة الشلال بسبب تضخم كل دورة علي حدى.
و عيب آخر أن إخراج تصور مبدئي لعدد الدورات التي ستكون كفيلة بإخراج المشروع ربما تكون مستحيلة لأن ذلك سيختلف من مشروع لآخر
أما العيب الرئيسي من وجه نظري هو العبئ الثقيل الناتج من القيام ب أربع مراحل في كل دورة و صعوبة عمل التربيط اللازم لتلك الدورات و تعظم المشكلة لو انقسم فريق العمل إلي عدة فرق عمل في آن واحد فعندها غالباً ما سنفقد التزامن Synchronization في عمل تلك الفرق و نضرب مثالاً علي ذلك :لو أفترضنا وجود مشروع بناء نظام تشغيل فالمجموعة المسئولة عن واجهة المستخدمين ربما تكون جاهزة لاستكشاف الدورة الخاصة بجزئية مدير النظام و لكن المجوعة المسئول عن قلب أو محرك نظام التشغيل مازالت في مرحلة تطوير ذاكرة النظام الفرعية
دورة الحياة لغة هي الأطوار المختلفة التي يمر بها كائن حي ما في أثناء حياته.
أما إصطلاحاً في الهندسة البرمجيات فنعني به هي بناء البرنامج منذة لحظة ورود الفكرة في الذهن إلي خروج البرنامج للعميل بل و خدمة ما بعد البيع وهذا تعريقف مختصر جداً و إلا فإن دورة الحياة للنظام البرمجي طويلة و تمر بمراحل مختلفة و عديدة ليخرج للنور و يصل في أيدي العملاء و كما ذكرنا في المقال السابق أنة ليست كتابة الأكواد و الشفرات Coding هو النقطة الرئيسة في دورة الحياة تلك بل ممكن أن تكون أقلها و قتلاً و مجهوداً.
و قبل الشروع في شرح بعض نماذج دورات الحياة للنظام البرمجي Software life cycle models نتكلم باختصار عن معنى كلمة دورة حياة النظام
الشرارة الأولى
ما الذي يجبر شركة في اتخاذ قرار البدأ في برنامج معين ؟ أظن هذا لا يخرج عن سببين رئيسيين و هما: 1- الفكرة ‚ نعم و أصحاب الأفكار هم المبدعون الذين يقودون السوق ‚ فيبدأ البرنامج في أذهانهم مجرد فكرة و بمجرد وضعها علي الورق تصبح الفكرة قيد التنفيذ. 2- السبب الثاني هو احتياجات السوق الملحة ‚ و بحصر تلك الاحتياجات فتبدأ العقول في شحذ أفكارها لإخراج البرنامج المطلوب لسد تلك الاحتياجات
و بمجرد وجود فكرة البرنامج سواء كانت من أي سبب فأنت تملك الشرارة الأولى التي تظنها في منتهى الصغر و لكنها ستشعل المحرك الذي بدورة سيحرك قطار كبير من الأفكار و الأدوات و القوى البشرية و التي توصلك في النهاية لاستخراج برنامج قوي و هذا ما نحلم به بالأخص في منطقتنا العربية.
والآن بدأ العمل
ربما تظن أن الآن يبدأ العمل ... لا ‚ بل قد بدأ بالفعل و نحن في الشرارة الأولى ‚و لا تظن أخي أن هذا وقت التشفير أو كتابة الأكواد Coding ‚ و هذا ما يحدث للأسف في معظم الشركات إلا الكبير منهافقط الذي يتنبنى العمل بـ نموج بناء لعملية إنتاج نظام برمجي software process فننتقل بعد الاتفاق علي الفكرة مراحل الانتاج الفعلي و هي التخطيط مروراً بالتصميم ثمكتابة الأكواد و تبدأ مراحل الاختبار بأنواعها ثم التقييم ثم التوزيع للعملاء و خدمات ما بيعد البيع
و كل هذه المراحل تختلف في الاحتياجات من حيث الموارد البشرية و الوقت و باختلاف النموذج المتبع لانتاج نظام برمجي Software process ستختلف مراحل الانتاج و أوقاتها بل و أهميتها أيضاً
و نشرع الآن في شرح نماذج دورة حياة النظام البرمجي :
نموذج المراحل المتتابعة Stagewise model
يعد هذا النوذج بأنة هو النموذج التقليدي لدورة حياة النظم البرمجية ‚ و تعتمد علي فكرة تقسيم خطوات إنشاء برنامج حاسوبي إلي مراحل تتم بالتتابع و لا يتم الانتقال من مرحلة إلا بعد استكمال المرحلة السابقة لها تماماً.فعملية إنشاء برنامج حاسوبي تبدأ من مرحلة التخطيط و هي تشمل جمع قائمة بالمتطلبات Requirements و بخصائص البرنامج و مميزاتة Features ‚ و كلما كانت تلك المرحلة محكمة و مكتملة كانت فرصة نجاح المنتج كبيرة ‚ ثم يتم الانتقال إلي مرحلة التصميم و هي مثل المرحلة السابقة في كونها لابد أن تكون محمكة و مكتملة ثم كتابة الشفرات ثم الاختبار ثم التقييم.
تكمن المشكلة الرئيسية في هذا النموذج من نماذج دورات حياة النظم الحاسوبية أنه لا يمكنك فعلياً إنهاء مرحلة كاملة مع عدم وجود أي نوع من أنواع الرجوع للمرحلة السابقة أو رؤية مستقبلية للمرحلة التالية مما يوقع المشروع في أخطاء لم تكن بالحسبان ‚ مثال لذلك : من الصعوبة بمكان أن تكون في مرحلة التصميم و تريد أن تنتهي منها مع عدم كتابة أي كود و مثال أوضح : ما هي فائدة أن تصل إلي مرحلة الاختبارات و أنت عاجز عن الرجوع لمرحلة كتابة الشفرات حتى تقوم بإصلاح الأخطاء إن وجدت – و غالباً ما توجد- فتأمل.
و لما فشل الرد عن تلك الأمثلة فأصبحنا مضطريين لإضافة بعض التعديلات و التحسينات علي ذلك النوذج فظهر في الأفق نموذج جديد وهو نموذج الشلال waterfall model.
نموذج الشلال waterfall model
في أوائل السبعينات تمت إضافة بعض التعديلات و التحسينات علي نموذج المراحل المتتابعة Stagewise model و كان التحديث الرئيسي هو وجود نوع من أنواع تَغْذِيَةٌ مُرْتَجِعَةٌFeedback بين المراحل بعضها و بعض سواء المراحل السابقة أو التالية و بالطبع هي نفس المراحل السابقة في المنوذج السابق (التخطيط – التصميم – كتابة الشفرات – الاختبار - التقييم) و لكن فقط يختلف الانتقال من مرحلة إلي أخرى مع إمكانية عمل تجاوزات Overlap (أي البدء ثم الرجوع ثم البدء – و تسمي تراكيب أو تجاوزات) و من هنا نسمح لتعديل طرء علي مرحلة ما بأن ينعكس علي المراحل الأخرى أو العكس بأن يتم القيام بجزء من مرحلة قبل الانتهاء من المرحلة الحالية مما يفك كثيراً من الجمود الذي كان في نموذج المراحل المتتابعة stagewise model.و معظم المشاريع تبدأ بنفس الطريقة و هي فقط إعداد قائمة بالمتطلبات و الخصائص و المميزات و تكون نسبة نجاح تلك الطريقة (النموذج) أكبر كلما كان المشروع (المنتج ) صغيراً.
فائدة: أحترس دائما من تعديلات و طلبات العميل الجديدة ففي كثيراً من الأحيان لا يكون هدف البرنامج متضح كاملاً في ذهن العميل فبالتالي تطرأ التعديلات و التحسينات و يمكنك نموذج الشلال في أن ترجع إلي مرحلة سابقة و هي مرحلة التصميم و تنظر أنت كمدير للمشروعات أن التعديل متاح و سهل ثم تنزلق قدمك في تعديلات و تحسينات لا تنتهي و بالتالي تستمر الدائرة إلي ما لا نهاية مما ينذر بتأخر المشروع أو عدم تسليمه بالمرة.
و تظهر هنا عيوب ذلك النموذج حيث أنه لن يكون بالديناميكية الكافية لتواجه تلك التعديلات التي لا تنتهي و لن تستطيع التجاوزات و التراكيب Overlap بعمل رد كامل لجزء كبير من مرحلة لتواكب تلك التعديلات أو المطلب الجديد للعميل
الطريقة الحلزوني The Spiral method
تم تقديم تلك الطريقة بواسطة باري دبليو بوهم Barry W. Boehm سنة 1988 و كان الدافع لذلك هو التعرف علي الأخطاء و المشاكل الغير متوقعة و التعديلات في المتطلبات التي غالباً ما تصيب تقدم المشروع.
و تعد الطريقة الحلزونية فرد من أفراد عائلة إدارة هندسة البرمجيات بطريقة العمليات التكرارية Iterative process (و هي تكرار خوارزم كل مسألة محددة بحيث يكون المخرج من أي مرحلة هو المدخل للمرحلة الثانية)
و الحلزون يتكون منعدد من الدورات أو الدورانات (Cycle ‚ spin) و كل دورة مرتبطة بالدورة التي تليها و الدورة التالية دائما أكبر من الدورة السابقة و هكذا حتى ينتهي الحلزون
من هنا يتضح بأن كل دورة ستكون وحدة متكاملة لإنتاج مرحلة من مراحل المشروع و بالتالي فإن الفكرة الرئيسية لهذه الطريقة هي أنك لا تقلق بأن يحدث خطأ ما أو تعديل ما فأنك سوف تكون قادراً علي إصلاة و القيام به في الدورة القادمة و هكذا حتى تنتهي الدورات و يخرج المشروع للنور
و تعتمد مراحل الطريقة الحلزونية تقريبا علي نفس مراحل الطرق السابقة لكن مع بعض التعديلات ‚ فتأتي مرحلة الاستكشاف discovery كأول مرحلة و هي المتعلقة بجمع المتطلبات و تحديد الأهداف Objectives . و في خلال مرحلة الاستكشاف ربما نضطر لكتابة بعض الأكواد الأولية Prototypes
أما المرحلة الثانية و هي أكبر المراحل أهمية هي التقييم Evaluation فهي المنوطة بتقدير المهام الأكثر خطورة في الدورة الحالية
أما المرحلة الثالثة هي مرحلة البناء و التطوير Development و يتم فيها بناء المهمات التي تم توضيح خطورتها في مرحلة التقييم ( المرحلة الثانية ) و نضرب لذلك مثالاً : لو نتج عن مرحلة التقييم أن الخوارزم Algorithm المكتوب يحتمل أن يكون صعباً جداً أو ربما مستحيلاً فستكون المهمة الرئيسية في المرحلة الثالثة في الدورة الحالية هي تمثيل ز بناء و اختبار ذلك الخواريزم
و نصل إلي المرحلة الرابعة و هي التحليل و التخطيط
و بهذا نكون قد أنهينا دورة كاملة في الحلزون و ننتقل للدروة التالية و هكذا حتى ننتهي و من المتوقع أن يكون كل دورة قصيرة الوقت و هذا يعتمد علي نتائج الدورة السابقة لها
مميزات و عيوب الطريقة الحلزونية
اعطائنا الأولية للقيام بالمهام الكبر خطورة يعطي فرصة أكبر لنجاح المشروع لأنك تتجنب الكثير من المخاطر التي غالباً ما تحدث في أي مشروع أو تحت ضغط المتطلبات الجديدة التي قد تطرأ علي النظام و هذا يمثل ميزة كبيرة للطريقة الحلزونية و بتكرار التحليل و التخطيط و تجديدهما في كل دورة من دورات الطريقة الحلزونية فذلك يزيل معظم العوائق الكامنة في طريق إنهاء المشروع. فإنك مع كل دورة من الدورات تحصل علي ميزة جديدة و معرفة أكبر بالمشروع مما يثري التصميم و يصب ذلك كملة في مصلحة المشروع و خروجة بشكل قوي.
تكمن العيوب الرئيسية في تلك الطريقة في صعوبة الحصول علي مخرج نهائي أو تقييم لتطور المشروع بعد كل دورة من الدورات . و ربما في أسؤ الحالات تتحول الطريقة إلي طريقة الشلال بسبب تضخم كل دورة علي حدى.
و عيب آخر أن إخراج تصور مبدئي لعدد الدورات التي ستكون كفيلة بإخراج المشروع ربما تكون مستحيلة لأن ذلك سيختلف من مشروع لآخر
أما العيب الرئيسي من وجه نظري هو العبئ الثقيل الناتج من القيام ب أربع مراحل في كل دورة و صعوبة عمل التربيط اللازم لتلك الدورات و تعظم المشكلة لو انقسم فريق العمل إلي عدة فرق عمل في آن واحد فعندها غالباً ما سنفقد التزامن Synchronization في عمل تلك الفرق و نضرب مثالاً علي ذلك :لو أفترضنا وجود مشروع بناء نظام تشغيل فالمجموعة المسئولة عن واجهة المستخدمين ربما تكون جاهزة لاستكشاف الدورة الخاصة بجزئية مدير النظام و لكن المجوعة المسئول عن قلب أو محرك نظام التشغيل مازالت في مرحلة تطوير ذاكرة النظام الفرعية
