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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

سلبيات الطراز البدئي التطوري قد يُبعد الفريق عن منهجية التطوير المنظمة نحو المزيد من عمليات ”البرمجة والتصحيح“ (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

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

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

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

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

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

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

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

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

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

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