1. النماذج الإجرائية لتطوير البرمجيات

2. محتويات المحاضرة
مراحل دورة حياة المنتج البرمجي(Software Development Life Cycle )
نموذج الشلال (Waterfall Model)
نموذج الطراز البدئي (Prototype Model)
النموذج الحلزوني (Spiral Model)
نموذج التطوير المتزامن (Synchronized developing Model)
ITA330

3. ما هي الإجرائية البرمجية؟
مجموعة من الأنشطة المرتبة هدفها النهائي تطوير منتج برمجي جديد أو تحسين منتج موجود.
تتمحور كل الإجرائيات البرمجية حول أنشطة عامة رئيسية:
التحليل
التصميم
التحقيق
اما المراحل التفصيلية فهي على النحو التالي:
تحديد المتطلبات
توصيف المتطلبات
تصميم البنيان
التصميم التفصيلي
المكاملة
الصيانة
ITA330

4. دورة حياة المنتج البرمجي (Software Development Life Cycle – SDLC)
ITA330

5. النموذج الشلالي (Waterfall Model)
ITA330

6. النموذج الشلالي أول نموذج تطوير تسلسل خطي للمراحل موجّه بالوثائق.
لا تقاطعات بين المراحل المختلفة.
موجّه بالوثائق.
تجري عملية التخطيط بأكملها بشكل مسبق.
ITA330

7. النموذج الشلالي
يفترض أنه يمكن جمع كل المتطلبات واستكمال التحليل قبل البدء بالتصميم.
يعتمد على مجموعة مراحل متعاقبة: توصيف المنتج، التصميم، البرمجة (Coding)، الاختبارات.
لا يمكن الانتقال إلى مرحلة جديدة إلا بعد تجاوز آخر نقطة علام (check point) من المرحلة السابقة بنجاح.
ITA330

8. مراحل النموذج الشلالي تحليل المتطلبات وتعريفها تصميم النظام
التنفيذ والاختبارات الوحدوية (Unit Testing).
المكاملة واختبارات النظام (Integration and System Testing).
التشغيل والصيانة.
من أهم عقبات النموذج صعوبة تبني التعديلات بعد البدء بالإجرائية. يجب إكمال كل مرحلة قبل الانتقال إلى المرحلة التالية.
ITA330

9. الاستطلاع الأولي (Concept Exploration)
تركز المرحلة على طرح السؤال “لماذا نريد النظام؟”.
ليست إلزامية (ليست من النموذج):
تُدعى أحياناً مرحلة “ما قبل المشروع”.
موجهة لإعداد الخطط الأولية وتقدير الكلفة وزمن التنفيذ.
المخرجات المحتملة:
وثيقة المفهوم (Concept Document)، وصف المنتج (Product Description)، مقترح النظام (System Proposal)، بيان العمل (Statement of Work)، ميثاق المشروع (Project Charter).
ITA330

10. تحليل المتطلبات (1) (Requirements Analysis)
مرحلة السؤال “ماذا؟”.
ما المقصود بالمتطلبات:
المتطلب: بيان لخدمة من خدمات النظام أو لقيد من قيوده، ويصف بيان الخدمة السلوك المطلوب من النظام بالنسبة لمستخدم مفرد أو بالنسبة لمجموعة من المستخدمين.
بيان الخدمة: يعرف بيان الخدمة قاعدة ضبط (business rule) يجب احترامها دوماً. وقد يعبر بيان الخدمة عن عملية حسابية يجب أن يجريها النظام.
بيان القيد: يعبر بيان القيد عن قيد مفروض على سلوك النظام أو على تطويره.
ITA330

11. تحليل المتطلبات (2) نوعان من المتطلبات: يجب ترتيبها ضمن قائمة أولويات:
متطلبات وظيفية (Functional)
ويُقصد بها إمكانات النظام والوظائف التي يجب أن يقدمها.
متطلبات غير وظيفية (Non-functional)
الاستخدام، الوثوقية، الأداء، إدارة النظام، التثبيت، الاتصال مع أنظمة أخرى، إضافة إلى متطلبات أخرى (قانونية، التجهيزات...).
يجب ترتيبها ضمن قائمة أولويات:
ضرورية (Must-have).
يُحبذ وجودها (Should-have).
من الجيد توفيرها (Could-have / Nice-to-have)
ITA330

12. تحليل المتطلبات (3) مدخلات المرحلة: بيان العمل، مقترح النظام.
المخرجات:
وثيقة المتطلبات (Requirements Document)
وثيقة توصيف المتطلبات (Requirements Specification Document - RSD) أو (Software Requirements Specification - SRS)
تُعتبر النقطة المرجعية الأولى (1st Project Baseline).
ITA330

13. التصميم (Design) السؤال الأساسي في المرحلة هو “كيف؟”.
المدخلات: وثيقة توصيف المتطلبات.
المخرجات:
التوصيف الوظيفي (Functional Specification).
وثيقة التصميم التفصيلي (Detailed Design Document).
توصيف واجهات الاستخدام (User Interface Specification).
نموذج البيانات (Data Model).
ITA330

14. التصميم يُقسم عادة إلى مرحلتين:
تصميم البنيان (Architectural Design): هو توصيف النظام بدلالة المجتزآت التي تكونه، والذي يجب أن يتخذ قرارات بشأن استراتيجيات الحل بالنسبة لكل من الزبون والمخدم.
التصميم التفصيلي (Detailed Design): هو توصيف العمل الداخلي لكل مجتزأ في النظام، والذي يجب أن يتضمن الخوارزميات التفصيلية وفق المعطيات الخاصة بالمجتزأ والتي يجب أن تخضع لقيود بنية العمل النهائية. ويجب أن يتضمن التصميم التفصيلي:
تصميم واجهات الاستخدام البيانية.
تصميم بنى وقواعد المعطيات.
ITA330

15. التحقيق (Implementation)
مرحلة القيام بالفعل “Do It”
كتابة الرماز واختبار الوحدات.
تتراكب غالباً مع مرحلتي التصميم والمكاملة.
أنشطة أخرى موازية للمرحلة:
إكمال التصميم.
بدء المكاملة.
اختبار الوحدات بشكل مستقل بعضها عن بعض.
ITA330

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

17. المكاملة والاختبارات (Integration & Test)
تبدأ مع نهاية مرحلة التحقيق.
تُنفذ غالباً على مرحلتين على التوازي:
المكاملة الجزئية و الاختبارات الأولية.
تبدأ بمكاملة المجتزآت (Modules).
تؤدي إلى بناء نسخة أولية غير مكتملة من النظام.
تُضاف مجتزآت جديدة تدريجياً.
ITA330

18. المكاملة والاختبارات تُعتبر المكاملة مبدئياً من مهمات المبرمجين.
تُعتبر الاختبارات من مهمات فريق ضمان الجودة (QA Team).
طرق المكاملة:
تنازلية (Top-down): نبدأ بمكاملة المجتزآت الوظيفية المركزية مع محاكاة للبرامج غير المكتملة.
تصاعدية (Bottom up): نبدأ بمكاملة مجتزآت المستويات الأدنى.
نفضل عادة الطريقة التنازلية.
ITA330

19. المكاملة والاختبارات الاختبارات:
اختبارات المكاملة (Integration testing).
اختبارات الصندوق الأبيض والصندوق الأسود (Black & White-box testing).
اختبارات العمل تحت الأعباء (Load & Stress testing).
اختبارات القبول (Acceptance testing).
ITA330

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

21. التسليم والصيانة (Deployment & Maintenance)
غالباً ما تُهمل الخطط مرحلة الصيانة.
الصيانة:
إصلاح الأخطاء.
إضافة مزايا جديدة.
تحسين الأداء (Improve performance).
تصبح مسألة إدارة الإصدارات على درجة عالية من الأهمية.
تظهر الضرورة لتحديث الوثائق السابقة.
ITA330

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

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

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

25. المنهجيات المهيكلة (Structured Methods)
يُعتبر النموذج الشلالي مثالاً نمطياً عن المنهجيات المهيكلة.
المنهجية المهيكلة: تستند عادة على تقنيتين أساسيتين:
مخططات تدفق المعطيات (Data Flow Diagrams) DFD لنمذجة الإجرائيات
مخططات علاقات الكيانات (Entity Relationship Diagrams) ERD لنمذجة المعطيات.
خصائص ميزات المنهجية المهيكلة:
تأخذ المنهجية منحى تسلسلياً وتحويلياً أكثر منه تكرارياً وتزايدياً.
تعطي المنهجية حلولاً غير مرنة تلبي وظائف العمل المعرفة مسبقاً ويصعب توسيعها تدريجياً في المستقبل.
تفترض المنهجية أن التطوير يبدأ دوماً من الصفر ولا تدعم إعادة استخدام مكونات برمجية موجودة.
ITA330

26. نموذج الطراز البدئي (prototype)
ITA330

27. استخدامات نموذج الطراز البدئي
لمساعدة الزبائن والمطورين على فهم متطلبات النظام.
انتقاء المتطلبات (Requirements Elicitation): يمكن للمستخدمين اختبار الطراز لفهم آلية دعم النظام لأعمالهم.
التحقق من المتطلبات (Requirements Validation): يسمح الطراز بكشف أخطاء المتطلبات والمتطلبات الناقصة.
يساعد في تخفيض احتمالات وآثار المخاطر (من خلال تخفيض احتمالات الأخطاء في توصيف المتطلبات).
ITA330

28. مناهج بناء الطراز البدئي
ITA330

29. مناهج بناء الطراز البدئي
بناء الطراز التطوري (Evolutionary prototyping)
يُعاد تحسين الطراز الذي تم بناؤه عبر عدد من المراحل المتعاقبة وصولاً إلى النظام النهائي المستهدف.
يُبنى الطراز التطوري بهدف تسليم المستخدمين نظام صالح للعمل. وفي هذه الحالة يتم البدء بتحقيق المتطلبات الأكثر وضوحاً.
بناء الطراز المهمل (Throw-away prototyping)
يُبنى الطراز بهدف اكتشاف المتطلبات ومشكلاتها ومن ثم يُهمل، حيث يمكن بعد ذلك استخدام إجرائية تطوير أخرى.
يُبنى الطراز المهمل بهدف اكتشاف المتطلبات والتحقق منها. وفي هذه الحالة يتم البدء بأقل المتطلبات وضوحاً.
ITA330

30. نموذج الطراز البدئي التطوري (Evolutionary Prototype)
يُبنى النظام كسلسلة من الإصدارات التزايدية (Incremental) تُسلم تباعاً للزبون.
يبني المطورون طرازاً بدئياً خلال مرحلة جمع المتطلبات.
يقوم المستخدمون بتقييم الطراز المنجز.
يقوم المستخدمون باقتراح الإجراءات التصحيحية.
يقوم المطورون بتحسين الطراز بناء نسخة جديدة.
عند بلوغ الزبون درجة مقنعة من الرضى والكفاية، يقوم المطورون بمراجعة رماز النموذج الأخير لتحسينه من خلال تطبيق المعايير اللازمة لاعتباره منتجاً نهائياً.
ITA330

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

32. سلبيات الطراز البدئي التطوري
قد يُبعد الفريق عن منهجية التطوير المنظمة نحو المزيد من عمليات ”البرمجة والتصحيح“ (code-and-fix).
يجب أن يتمتع فريق التطوير بمهارات عالية.
تزداد صعوبة تقدير الكلفة والزمن.
قد يزيد من تعقيد عمليات الصيانة اللاحقة.
قد يضغط الزبون باتجاه تسليم طراز غير نهائي.
قد تتحول عملية تحسين الطراز إلى حلقة غير منتهية مع اكتشاف المزيد من الاحتياجات والمتطلبات (scope creep).
لا يمكن اختبار المتطلبات غير الوظيفية بشكل كافٍ (قد لا يُظهر النموذج متطلبات الأمان الحساسة بشكل واضح).
Management problems
Existing management processes assume a waterfall model of development
Maintenance problems
Continual change tends to corrupt system structure so long-term maintenance is expensive
Contractual problems
An implementation has no legal standing as a contract
ITA330

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

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

35. النموذج الحلزوني
يجمع ما بين الطبيعة التكرارية لنموذج الطراز البدئي والطبيعة الممنهجة للنموذج التسلسلي (الشلالي).
مع تطوير سريع لنسخ تزايدية من النظام البرمجي في سلسلة من الإصدارات التزايدية.
ITA330

36. النموذج الحلزوني يسبق كل مرحلة يلي كل مرحلة دراسة البدائل
تحليل المخاطر
يلي كل مرحلة
تقييم للنسخة
تخطيط للمرحلة التالية
ITA330

37. النموذج الحلزوني يركز على تحليل المخاطر وإدارتها في كل مرحلة.
يمكن النظر إليه كسلسلة مشاريع صغيرة يهتم كل منها بمعالجة مجموعة من المخاطر (Start small, explore risks, prototype, plan, repeat).
لا يمكن تحديد عدد الحلقات مسبقاً (تشبه الحلقة الأخيرة منه النموذج الشلالي).
ITA330

38. إيجابيات النموذج الحلزوني
يعطي مؤشرات مبكرة للمخاطر التي لا يمكن تجاوزها (وبقليل من الكلفة).
يستطيع المستخدمون رؤية النظام مبكراً (بسبب الاعتماد على تقنيات بناء الطراز).
تُبنى الوظائف الأكثر خطورة في البداية.
يبقى المستخدمون قريبين من كل مراحل العمل.
يمكن الحصول على انطباعات وآراء المستخدمين بشكل مبكر.
Advantages
Can be combined with other models
As costs increase, risks decrease
ITA330

39. سلبيات النموذج الحلزوني
يصبح زمن تقييم المخاطر غير مبرر في المشاريع الصغيرة.
قد يتطلب التخطيط وتقييم المخاطر وبناء الطرز وقتاً طويلاً جداً.
النموذج معقد (غير شائع الاستخدام).
يحتاج لخبراء في تقييم المخاطر.
قد يتزايد عدد الحلقات بطريقة لا يمكن التنبؤ بنتائجها.
من الصعب تعريف مؤشرات ونقاط علام لتقدير درجة التقدم باتجاه المنتج النهائي.
Disadvantages
Requires more management
ITA330

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

41. نموذج التطوير المتزامن
حل لمشاكل إدارة المشاريع البرمجية
تنفيذ مراحل تطوير المنتج البرمجي بشكل متزامن و متساير
حل أمثلي للمديرين، كابوس للمطورين
ITA330

42. مقارنة بين النماذج المختلفة
تم عرض نماذج مختلفة لتطوير البرمجيات (مع إيجابيات وسلبيات كل منها).
تتضمن معايير انتقاء النموذج الأنسب:
المؤسسة (حجمها، خبراتها، إدارتها...).
خبرات ومهارات فريق العمل.
طبيعة المنتج المطلوب.
الاقتراح الأفضل؟
“Mix-and-match” life-cycle model
ITA330