ھندسة البرمجیات الدرس الثاني

دورة حیاة تطوير  المشروع

أھداف   الدرس

كما  رأينا في الدرس الاول فإن ھندسة البرمجیات ھو عمل إبداعي يتم إداءه خطوة بخطوة، ويتعاون فیه عدد

من الاشخاص لكل منھم مھمة محددة .في ھذا الدرس سوف نناقش الخطوات التي يتم اتباعھا عند تطوير

مشروع برمجي بمزيد من التفاصیل ونبحث في الطرق المستخدمة لتنظیم ھذا العمل (صناعة البرمجیات(

مقدمة:

ومما تعلمنا في الدرس ،" Life Cycle عملیة بناء أي منتج تمر بعدة مراحل يطلق علیھا عادة "دورة الحیاة

تتضمن المراحل التالیة: Software development life cycle السابق فإن دروة حیاة تطوير أي نظام برمجي

Requirements analysis and definition 1تحديد وتعريف المتطلبات .

System design 2تصمیم النظام .

Program design 3تصمیم البرنامج .

) Program implementation 4كتابة البرنامج (تطويره .

Unit testing 5أختبار وحدات البرنامج .

system testing 6أختبار النظام .

system delivery 7تسلیم النظام .

maintenance 8الصیانة .

كل مرحلة من تلك المراحل تتضمن العديد من الخطوات أو النشاطات ولكل منھا مدخلاتھا ومخرجاتھا وتأثرھا

على جودة المنتج النھائي) البرنامج.(

دورة حیاة أي منتج تبدأ بأول خطوة وھي تحديد المتطلبات وتتدرج إلى باقي الخطوات كما ھي مرتبة حتى

الوصول إلى آخر خطوة وھي تسلیم البرنامج وصیانته (إن دعت الحاجة)، إلا أن التجارب العملیة تظھر أن ھذا

لیسضروريا وأن دورة حیاة تطوير البرامج قد تأخذ أشكال (أو أنماط) مختلفة. وفي ھذا الدرسسوف نتعرف

إلى ھذه الأنماط

Lifecycle Models: أنماط دورة الحیاة

Waterfall Model النموذج الانحداري

في ھذا النموذج تسیر دورة الحیاة بشكل تدريجي بدأ من الخطوة ( 1) وحتى الخطوة ( 8)، وكما يظھر

بالشكل ( 1) فإن كل مرحلة تبدأ بعد الأنتھاء من المرحلة التي تسبقھا مباشرة.

يتمیز النموذج الانحداري بالبساطة، ولذا فإنه يسّھل على المطور توضیح كیفیة سیر العمل بالمشروع

للعمیل (الذي عادة لا يعرف الكثیر عن صنع البرمجیات) والمراحل المتبقیة من العمل. وقد كان ھذا النموذج

أساس عمل كثیر من المؤسسات لفترة طويلة مثل وزارة الدفاع الامريكیة، واستنبط منه العديد من النماذج

الاكثر تعقیدا.

إلا أن لھذا النموذج العديد من العیوب، أھمھا أنه لا يعكسالطريقة التي يعمل بھا المطورون في الواقع.

فباستثناء المشاريع الصغیرة والبسیطة (أي أنھا مفھومة بشكل جید للمطور) فإن البرمجیات عادة ما تنتج

بعد قدر ھائل من التكرار والاعادة. في حین أن ھذا النموذج يفترض أن يكون الحل واضح ومفھوم وسبق

تحلیله بالكامل قبل مباشرة مرحلة التصمیم وھو أمر يكاد يكون شبه مستحیل مع الانظمة الضخمة. وحتى

إن كان ممكن فإنه يأخذ وقت طويل جدا (ربما سنوات!(

باختصار،النموذج الانحداري سھل الفھم و بسیط في إدارته. لكن ممیزاته تبدأ في التداعي بمجرد أن يزداد

تعقید المشروع.

Phased Development التطوير على مراحل

حسب النموذج الانحداري فإنه يجب على المطورين إنھاء مرحلة تحلیل المشروع بشكل تام قبل البدأ في

التصمیم، وكما وضحنا فإن ھذه المرحلة قد تتطلب وقت طويل في بعض المشاريع وقد تمر عدة سنوات قبل

أن يرى البرنامج النھائي النور، ولكن ھل يمكن لسوق العمل الانتظار كل ھذا الوقت؟!

الاجابة بالطبع لا.

أحد ھذه الطرق ھي التطوير Cycle time. لذا كان لابد من ايجاد طرق آخرى لتقلیل زمن تطوير المشروع

حیث يتم تطوير النظام على عدة مراحل، بتقديم إصدار من البرنامج به Phased Development على مراحل

بعض الوظائف للعمیل والعمل على تطوير الاصدار الاحق الذي سوف يقدم له بقیة الوظائف.

يوجد عدة طرق يمكن بھا تنظیم عملیة تطوير إصدارات البرنامج، ومن اشھرھا:

Incremental model النموذج التزايدي ·

حیث يتم تقسیم النظام المطلوب تطويره إلى عدة اجزاء حسب الوظائف التي يعتین علیه القیام بھا، يبدأ

أول إصدار بأحد تلك الاجزاء ومع الوقت يتم إضافة المزيد من الاجزاء (الوظائف) حتى يتم الانتھاء من تطوير

النظام بشكل تام وحسب متطلبات العمیل.

Iterative model النموذج التكراري ·

ھذه المرة يتم تسلیم برنامج بكامل الوظائف من أول مرة، ولكن يتم تعديل وتغییر بعضتلك الوظائف مع كل

إصدار من البرنامج.

من ممیزات ھذا الأسلوب أنه يمكن المطورين من الحصول على ملاحظات وتقییم الزبون مبكرا و بصورة

منتظمة، ورصد الصعوبات المحتملة قبل التمادي بعیدا في عملیات التطوير.كم أنه يمّكن من اكتشاف مدى

حجم و تعقید العمل مبكرا.

Spiral Model النموذج اللولبي

وھو شبیه لدرجة كبیرة إلى النموذج التزايدي والتكراري، ولكن فیه يتم دمج فعالیات التطوير مع إدارة المخاطر

من إجل التحكم بھا وتقلیلھا. risk

يبدأ النموذج اللولبي بمتطلبات العمیل مع خطة العمل المبدئیة (المیزانیة، قیود النظام، والبدائل المتاحة). ثم

يتقدم خطوة إلى الامام بتقدير المخاطر وتمثیل البدائل المتاحة قبل تقديم ما يعرف ب "وثیقة العملیات "

التي تصف وبشكل عام (بدون الدخول في التفاصیل) كیف يجب على النظام أن Concept of Operations

يعمل. بعدھا يتم تحديد وتدقیق المتطلبات للتأكد من أنھا تامة ودقیقة إلى أقصى حد ممكن.

بذلك تكون وثیقة العملیات ھي المنتج من الطور الأول، و المتطلبات ھي المنتج الاساسي من الطور الثاني.

وفي الطور الثالث تتم عملیة التصمیم، أما الاختبار فیتم خلال الطور الرابع.

في كل طور أو مرحلة يساعد تحلیل المخاطر على تقدير البدائل المختلفة في ضوء متطلبات وقیود النظام،

وتساعد النمذجة على التحقق من ملائمة أي بديل قبل أعتماده.

) •·.·´¯`·.·• نقاش الدرسالثاني •·.·´¯`·.·• (

WaterFall Model .. لي ملاحظه و ھي في ال

لأخر و كلما كان ھذا الرجوع أكبر كلما كان مكلف أكثر Phase من back track ھل من الممكن أن يكون ھناك

من ناحیة الوقت و التعديل و المال ؟؟

Phase من back track نعم من الممكن أن يكون ھناك

وغالبا ما يكون ھذا ما يحصل بالفعل عند التطبیق العملي...

ولیس ھذا فقط .. فبعد كل مرحلة ممكن يُكتشف أن ناتج models ممكن يحدث في جمیع ال backtrack ال

أحد المراحل السابقة لم يكن صحیح ويحتاج إلى تعديل

وھذا ما يجعل أنماط آخرى كالنمط اللولبي أكثر تفضیلا.

Waterfall Model بالنسبة لل backtrack صورة لل backtrack