نماذج الجيل القديم لإدارة تطوير البرمجيات

https://drive.google.com/file/d/0B5zxZ0A1AI-XMjB2aEN1c3lZV28/view

هذا المقال جزء من كتيب إطلالة على نماذج إدارة تطوير البرمجيات (22 صفحة)




من خلال هذا الاستعراض سنحاول سوياً أن نلقي نظرة سريعة على أهم الأساليب والنماذج التي تستخدم في عملية تطوير النظم والبرمجيات والتي يمكن تصنيفها على أنها من الجيل القديم الذي بدأ مع بداية عصر تطوير البرمجيات حوالي منتصف القرن العشرين وامتد إلى أوائل التسعينيات منه.

نموذج شلال المياه Waterfall Model

سمي كذلك لأن شكل النموذج يوحي بانسياب عملية التطوير من الأعلى إلى الأسفل من خلال مراحل النموذج بما يشبه سقوط شلال المياه. والشكل التالي يعطينا تصوراً واضحاً عن هذا النموذج.


Waterfall Model
يأخذ هذا النموذج المكونات الأساسية لعملية التطوير ويضع كل منها في مرحلة مستقلة لا يتم البدء في المرحلة التالية لها إلا بعد اكتمال الأولى ونظراً لوجود التعديلات التي تظهر في المراحل المتأخرة فإنه يحوي أيضاً عملية التغذية المرتدة من المراحل المتأخرة إلى المراحل الأولى.

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

ولكن ماذا عن الجانب الآخر, ما هي المشاكل التي تصادف مستعملي هذا النموذج؟ الحقيقة أن هناك العديد من هذه المشاكل فمثلا تقسيم مراحل العمل في شكل مراحل مستقلة يجعل استعماله أمراً لا يتسم بالمرونة كما أنه من الصعب جداً الاستجابة للتغيرفي متطلبات المستخدم في المراحل المتأخرة من العمل ومن الممكن في حال محاولة تغيير نطاق العمل أو محاولة توسيعه أن يؤدي ذلك لفشل المشروع ككل. وكما ذكرنا فإنه يحتاج إلى أن تكون كل المتطلبات معروفة منذ بداية العمل وبناء عليه فإنه من الصعب جداً استخدامه في تطوير الأنظمة المعقدة أو استخدامه لإدارة المشاريع التي تستمر لفترات طويلة أو تلك التي تتطلب طبيعتها الاستجابة المتكررة لتغيرات رغبات المستخدمين أو تطويرها.

كما أنه لا يوجد من خلال النموذج أي تقدير للمخاطرة أو مدى إمكانية نجاح المشروع من فشله, و لا يتوفر منتج جاهز يمكن للمستخدم الاستفادة منه حتى تتم جميع مراحل العمل. أضف إلى ذلك أن هناك الكثير من الإجراءات الروتينية التي يتطلبها إعداد الوثائق في المراحل الأولى وأنه لا يعطي حيزاً يذكر للاستفادة من الأفكار الجديدة التي تظهر أثناء العمل.

وبشكل عام يمكن اعتباره مثالاً جيداً لبيئة العمل البيروقراطية.

نموذج التطور Evolutionary  Development

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

ويتم استعمال هذا الأسلوب بطريقتين:

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

• إطلاق نموذج أولي (
Prototype): وتستعمل هذه الطريقة حين يكون الهدف هو التعرف على احتياجات المستخدم وتقديم تعريف واضح لمتطلبات النظام الذي يريده. ويركز النموذج الأولي عادة على الأجزاء التي يكون تحديد المستخدم لمتطلباتها غير واضح ويحتاج إلى أجراء تجارب تمكنه من الحكم بالمتطلبات التي تلبي احتياجاته بشكل أفضل.
 Evolutionary Development Model
وبالرغم من أن هذا النموذج أكثر فعالية من نموذج شلال المياه من خلال تقديم أنظمة توافق الاحتياجات الحالية للعميل. وأنه يسمح بالتطور التدريجي في فهم متطلبات النظام الذي يلبي احتياجات العميل وتطوير المواصفات المناسبة لها وبالتالي فهو أيضاً يسمح بالاستجابة المباشرة للتغير في رغبات العميل ويسمح بحرية كبيرة في الاستفادة من الأفكار الجديدة التي تظهر أثناء عملية التطوير. إلا أنه على الرغم من ذلك كله يظهر مشاكل جديدة فمثلاً العمليات غير ظاهرة بما يصعب على المديرين متابعة سير المشروع, فهم عادة يحتاجون إلى مستلمات محددة لتقييم مدى التقدم في سير العمل. وفي هذا السياق فإن عملية التوثيق التي يمكن التعويل عليها من أجل هذا الغرض لا تعتبر عملية اقتصادية فمن الصعب جداً أن تقوم فرق العمل بإعداد توثيق المشروع لكل إصدارة من النظام. كما أن التغيرات المستمرة تؤدي إلى تشويه الهيكل الرئيسي للنظام وهو ما يؤدي عادة في النهاية إلى هيكل ضعيف للنظام وتزداد المشكلة سوءاً حين تتعاون عدة فرق عمل مختلفة تطوير النظام.

إطلاق النموذج الأولي Throw-away Prototyping

إن عملية إطلاق النموذج الأولي تهدف بشكل أساسي إلى تطوير معرفتنا باحتياجات المستخدم ومتطلباته بشكل يمكننا من تقديم مواصفات أكثر دقة لموائمة هذه المتطلبات. 

إن هذه الطريقة تستعمل أساساً في مجال تطوير الأجهزة والهاردوير من أجل التأكد من ملائمة النماذج للاحتياجات وعملها بشكل سليم قبل الإنتاج بكميات كبيرة منعاً لحدوث خسائر قد تنجم عن عيوب في التصميم. 

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

Throw-away Prototyping Model

نموذج التطوير النمطي Formal System Development

تعتمد طريقة التطوير النمطي على تطوير نمطية رياضية تقوم مقام المواصفات المطلوبة لتحقيق متطلبات النظام, ومن ثم يتم استخدام الطرق الرياضية لتحويل هذه المواصفات إلى برامج. وتتم عملية الاختبار والتصحيح من خلال استخدام المعاملات الرياضية التي تصف الحالات المختلفة للاستعمال. 

الميزة الرئيسية لهذه الطريقة أن عملية التأكد من أن البرنامج يوافق المواصفات تتم بسهولة أكبر اعتماداً على أن المسافة بين كل عملية تحويل وأخرى أقرب من تلك التي توجد بين المواصفات والبرنامج نفسه. إلا أن هذه العملية صعبة جداً وأحياناً غير عملية مع النظم الكبيرة. كما أن عملية التحويل بحد ذاتها تحتاج إلى مهارة عالية وأحياناً متخصصين على درجة كبيرة من التعمق لاختيار عمليات التحويل المناسبة.

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

 Formal System Development Model

نموذج إعادة الاستخدام الموجه Reuse-oriented Development

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

ميزة هذا النموذج الأساسية هي أنه يقلل من حجم البرمجيات المطلوب تطويرها وبالتالي يقلل من التكاليف والمخاطرة, كما أنه يؤدي عادة إلى التسليم السريع للنظام إلى مستخدميه.

إلا أنه في الحقيقة مع هذا النموذج يتعذر تجنب حدوث التسويات ويتحتم في كثير من الأحيان اللجوء إلى الحلول الوسط بين ما يمكن للنظام تقديمه وبين احتياجات المستخدم. كما أنه يصعب التحكم في تطور النظام مع وجود إصدارات جديدة من المكونات القابلة لإعادة الاستخدام والتي تم استخدامها في هذا النظام وذلك لأن هذه الإصدارات واقعة تحت سيطرة الجهات المنتجة لها وليس تحت تحكم المنشآت التي تقوم بإعادة استخدامها.

ومن منظوري الخاص فأنا أرى أن هذا النموذج هو حقيقة متضمن ضمن أي نموذج آخر شئنا أم أبينا وذلك لأننا أياً ما كانت طبيعة النظام الذي نقوم بتطويره فإننا نستخدم على الأقل لغات برمجة تعتبر الإمكانيات التي تقدمها لنا نوعاً من المكونات الداخلة في تكوين نظامنا الذي نقوم بتطويره. إلا أن اعتبار هذا الأسلوب فقط في عملية التطوير يؤدي بنا إلى السلبيات السابقة وهو ما يؤدي بنا في النهاية إلى القبول بعدم التوافق الكامل بين النظام والاحتياجات أو إلى تقليل عدد هذه المكونات إلى أقل قدر ممكن من أجل تقليص الفرق بين النظام والاحتياجات, هذا الفرق الذي يزيد مع كل مكون معد سلفاً نضيفه إلى النظام وهو ما يعود بنا إلى نقطة البداية وهي أننا ما زلنا نحتاج إلى مكونات أخرى نقوم بتطويرها بأنفسنا.

وعليه لا نستطيع اعتبار هذا الأسلوب أسلوباً مجدياً قائماً بذاته إلا ضمن إطار ضيق من النظم التي لا تشكل مثل هذه الفروقات فيها مشكلة كبيرة, والأصح اعتباره أسلوباً فرعياً يمكن استخدامه ضمن إطار نموذج آخر.



Reused-oriented Development Model

نموذج التطوير بالإضافة Incremental Developing

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

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

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

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

Incremental Development Model

النموذج الحلزوني Spiral Model

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

يحتوي النموذج الحلزوني أربعة أطوار هي (تحديد الأهداف, تحليل المخاطرة, التنفيذ و المصادقة, التخطيط). ويمر المشروع من خلال هذه الأطوار الأربعة في دورات متتالية يمثلها الحلزون. ويمثل الشكل أدناه نموذجاً للعمل الحلزوني في تطوير النظم.

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

Spiral Model

نموذج   V-Shaped Model

اشتق هذا النموذج اسمه من شكله الذي يماثل حرف (في) الإنجليزي أو ما يقارب الرقم 7 في اللغة العربية وفي الحقيقة هو تطوير لنموذج شلال المياه من خلال المزيد من التشديد على الاختبارات وباستثناء ذلك فإن جميع ما ينطبق على نموذج شلال المياه ينطبق عليه. وميزته الوحيدة أنه يضمن سلامة النظام من المشاكل بدرجة أكبر من نموذج شلال المياه كنتيجة للتشديد على عملية الاختبار وذلك رغم أنه لم يوضح مساراً واضحاً لمعالجة المشاكل التي تظهر أثناء عمليات الاختبار. 



V-Shaped Model

نموذج الغرفة النظيفة Clean-room software development

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

ويقوم النموذج على خمسة أشياء رئيسية:

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

وأهم مميزات هذا النموذج أنه يقدم برامج بها عدد قليل جداً من المشاكل كما أنه عملية اقتصادية فالتكلفة المستخدمة لتطبيق النموذج عادة ما تكون أقل من تكلفة إعادة اكتشاف الأخطاء وتصحيحها.

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


Clean Room Software Development Model

نماذج الجيل القديم لإدارة تطوير البرمجيات نماذج الجيل القديم لإدارة تطوير البرمجيات Reviewed by Ammar Moussa on 1:00 ص Rating: 5