Transcript Slide 1
نماذج إلجرائيات التطوير البرمجية Software Development Life Cycle Models محتويات المحاضرة • النموذج الشاللي ()Waterfall Model • نموذج الطراز البدئي ()Prototype Model • النموذج الحلزوني ()Spiral Model 2 ITA330 – S2 ما هي اإلجرائية البرمجية؟ (تذكرة) • مجموعة من األنشطة المرتبة هدفها النهائي تطوير منتج برمجي جديد أو تحسين منتج موجود. • تتمحور كل اإلجرائيات البرمجية حول أنشطة عامة رئيسية: – التوصيف ( :)Specificationما يجب أن يؤديه النظام والقيود المفروضة عليه. – التطوير ( :)Developmentعملية إنتاج النظام البرمجي. – التحقق ( :)Validationالتأكد من أن النظام يحقق ما يريده الزبون. – التحسين ( :)Evolutionتغيير النظام استجابة لمتطلبات متغيرة. 3 ITA330 – S2 دورة حياة المنتج البرمجي (Software Development Life Cycle – SDLC) ITA330 – S2 4 أربع مراحل أساسية في أي إجرائية تطوير • انتقاء المتطلبات ( )Requirementsوتحليلها وتوصيفها. • تصميم النظام (.)System Design • تحقيق البرامج (.)Program Implementation • االختبارات (.)Test 5 ITA330 – S2 لكل مرحلة مخرجاتها المرحلة 6 المخرجات • تحليل المتطلبات • توصيف متطلبات البرمجية • التصميم • وثيقة التصميم • التنفيذ • الرماز • االختبار • تقرير االختبارات وطلبات التعديل ITA330 – S2 النموذج الشاللي )Waterfall Model( ITA330 – S2 7 النموذج الشاللي الصرف • أول نموذج تطوير • تسلسل خطي للمراحل – ال تقاطعات بين المراحل المختلفة. • موجّ ه بالوثائق. • تجري عملية التخطيط بأكملها بشكل مسبق. 8 ITA330 – S2 النموذج الشاللي • يفترض أنه يمكن جمع كل المتطلبات واستكمال التحليل قبل البدء بالتصميم. – يعتمد على مجموعة مراحل متعاقبة :توصيف المنتج ،التصميم ،البرمجة ( ،)Codingاالختبارات. – ال يمكن االنتقال إلى مرحلة جديدة إال بعد تجاوز آخر نقطة عالم ( )check pointمن المرحلة السابقة بنجاح. 9 ITA330 – S2 النموذج الشاللي 10 ITA330 – S2 مراحل النموذج الشاللي • تحليل المتطلبات وتعريفها • تصميم النظام • التنفيذ واالختبارات الوحدوية (.)Unit Testing • المكاملة واختبارات النظام ( Integration and System .)Testing • التشغيل والصيانة. • من أهم عقبات النموذج صعوبة تبني التعديالت بعد البدء باإلجرائية. يجب إكمال كل مرحلة قبل االنتقال إلى المرحلة التالية. 11 ITA330 – S2 المخرجات الممكنة لمراحل النموذج 12 ITA330 – S2 االستطالع األولي ()Concept Exploration • تركز المرحاة على طرح السؤال “لماذا نريد النظام؟”. • ليست إلزامية (ليست من النموذج): – ُتدعى أحيانا مرحلة “ما قبل المشروع”. • موجهة إلعداد الخطط األولية وتقدير الكلفة وزمن التنفيذ. • المخرجات المحتملة: – وثيقة المفهوم ( ،)Concept Documentوصف المنتج ( Product ،)Descriptionمقترح النظام ( ،)System Proposalبيان العمل ( ،)Statement of Workميثاق المشروع (.)Project Charter 13 ITA330 – S2 تحليل المتطلبات ()1 ()Requirements Analysis • مرحلة السؤال “ماذا؟”. • ما المقصود بالمتطلبات: – المتطلب :بيان لخدمة من خدمات النظام أو لقيد من قيوده ،ويصف بيان الخدمة السلوك المطلوب من النظام بالنسبة لمستخدم مفرد أو بالنسبة لمجموعة من المستخدمين. – بيان الخدمة :يعرف بيان الخدمة قاعدة ضبط ) (business ruleيجب احترامها دوما .وقد يعبر بيان الخدمة عن عملية حسابية يجب أن يجريها النظام. – بيان القيد :يعبر بيان القيد عن قيد مفروض على سلوك النظام أو على تطويره. 14 ITA330 – S2 تحليل المتطلبات ()2 • نوعان من المتطلبات: – متطلبات وظيفية )(Functional – ويُقصد بها إمكانات النظام والوظائف التي يجب أن يقدمها. – متطلبات غير وظيفية )(Non-functional – االستخدام ،الوثوقية ،األداء ،إدارة النظام ،التثبيت ،االتصال مع أنظمة أخرى، إضافة إلى متطلبات أخرى (قانونية ،التجهيزات.)... • يجب ترتيبها ضمن قائمة أولويات: • ضرورية (.)Must-have • يُحبذ وجودها (.)Should-have • من الجيد توفيرها )(Could-have / Nice-to-have 15 ITA330 – S2 تحليل المتطلبات ()3 • مدخالت المرحلة :بيان العمل ،مقترح النظام. • المخرجات: – وثيقة المتطلبات )(Requirements Document – وثيقة توصيف المتطلبات ( Requirements Specification )Document - RSDأو (Software Requirements Specification - )SRS – ُتعتبر النقطة المرجعية األولى (.)1st Project Baseline 16 ITA330 – S2 التصميم ()Design • السؤال األساسي في المرحلة هو “كيف؟”. • المدخالت :وثيقة توصيف المتطلبات. • المخرجات: – – – – 17 التوصيف الوظيفي (.)Functional Specification وثيقة التصميم التفصيلي (.)Detailed Design Document توصيف واجهات االستخدام (.)User Interface Specification نموذج البيانات (.)Data Model ITA330 – S2 التصميم • يُقسم عادة إلى مرحلتين: .1تصميم البنيان ( :)Architectural Designهو توصيف النظام بداللة المجتزآت التي تكونه ،والذي يجب أن يتخذ قرارات بشأن استراتيجيات الحل بالنسبة لكل من الزبون والمخدم. .2التصميم التفصيلي ( :)Detailed Designهو توصيف العمل الداخلي لكل مجتزأ في النظام ،والذي يجب أن يتضمن الخوارزميات التفصيلية وفق المعطيات الخاصة بالمجتزأ والتي يجب أن تخضع لقيود بنية العمل النهائية. ويجب أن يتضمن التصميم التفصيلي: .1 .2 18 تصميم واجهات االستخدام البيانية. تصميم بنى وقواعد المعطيات. ITA330 – S2 التحقيق ()Implementation • • • • مرحلة القيام بالفعل ”“Do It كتابة الرماز واختبار الوحدات. تتراكب غالبا مع مرحلتي التصميم والمكاملة. أنشطة أخرى موازية للمرحلة: – إكمال التصميم. – بدء المكاملة. – اختبار الوحدات بشكل مستقل بعضها عن بعض. 19 ITA330 – S2 التحقيق • أهم ما يميز المرحلة: – زيادة الضغوط على الفريق – إشغال الفريق في أعلى مستوياته. • اإلشكاليات: – تعديالت اللحظة األخيرة. – صعوبات التنسيق بين أعضاء الفريق (ال سيما في المشاريع الكبيرة). 20 ITA330 – S2 المكاملة واالختبارات ()Integration & Test • تبدأ مع نهاية مرحلة التحقيق. • ُتنفذ غالبا على مرحلتين على التوازي: – المكاملة الجزئية و االختبارات األولية. • تبدأ بمكاملة المجتزآت (.)Modules • تؤدي إلى بناء نسخة أولية غير مكتملة من النظام. • ُتضاف مجتزآت جديدة تدريجيا. 21 ITA330 – S2 المكاملة واالختبارات • ُتعتبر المكاملة مبدئيا من مهمات المبرمجين. • ُتعتبر االختبارات من مهمات فريق ضمان الجودة (.)QA Team • طرق المكاملة: – تنازلية ( :)Top-downنبدأ بمكاملة المجتزآت الوظيفية المركزية مع محاكاة للبرامج غير المكتملة. – تصاعدية ( :)Bottom upنبدأ بمكاملة مجتزآت المستويات األدنى. – نفضل عادة الطريقة التنازلية. 22 ITA330 – S2 المكاملة واالختبارات • االختبارات: – اختبارات المكاملة (.)Integration testing – اختبارات الصندوق األبيض والصندوق األسود ( & Black .)White-box testing – اختبارات العمل تحت األعباء (.)Load & Stress testing – اختبارات القبول (.)Acceptance testing 23 ITA330 – S2 المكاملة واالختبارات • أهم ما يميز المرحلة: – زيادة الضغوط على الفريق. – تجاوز مواعيد الخطة. – الخالف مع الزبون حول مزايا النظام. – اإلحباط الناتج عن الفشل وأخطاء اللحظات األخيرة. – تجاوز الموازنة. 24 ITA330 – S2 التسليم والصيانة ()Deployment & Maintenance • غالبا ما ُتهمل الخطط مرحلة الصيانة. • الصيانة: – إصالح األخطاء. – إضافة مزايا جديدة. – تحسين األداء (.)Improve performance • تصبح مسألة إدارة اإلصدارات على درجة عالية من األهمية. • تظهر الضرورة لتحديث الوثائق السابقة. 25 ITA330 – S2 إيجابيات النموذج الشاللي • • • • • • 26 سهل الفهم واالستخدام والتتبع. مناسب لفرق العمل التي ال تتمتع بخبرات عالية (ويطور خبراتها). يسمح بتعريف نقاط عالم ( )Milestonesواضحة لعملية التطوير. يدفع باتجاه تثبيت المتطلبات. يسهل على اإلدارة عملية التخطيط (للموارد البشرية واألزمنة والكلف). تنتهي كل مرحلة بإنتاج وثيقة تسمح بفهم ما جرى إنجازه (األمر الذي يسهل إدخال عناصر جديدة في فريق العمل في أية مرحلة). ITA330 – S2 سلبيات النموذج الشاللي • يجب أن تكون كافة المتطلبات معروفة مسبقا. • ُتعتبر مخرجات كل مرحلة نهائية (تقلل من مرونة التعديالت). • قد يعطي انطباعات خاطئة عن درجة التقدم واإلنجاز. • ال يتماشى مع منطق حل المشكالت (تكرار المراحل). • ال يعطي فرصة للزبون لمعاينة النظام (إال ربما بعد فوات األوان). • تجري عمليات المكاملة واالختبارات فقط في نهاية المشروع (مع ما ينطوي عليه ذلك من مخاطر). • يمكن أن ينتج كما كبيرا من الوثائق. 27 ITA330 – S2 متى نستخدم النموذج الشاللي؟ • المتطلبات واضحة ومعرفة بشكل جيد. • هناك تعريف ووصف مستقر للمنتج. • عند بناء إصدار جديد من منتج موجود مسبقا. • عند نقل منتج موجود إلى منصة عمل جديدة. • عندما يكون فريق العمل ضعيفا فنيا. 28 ITA330 – S2 المنهجيات المهيكلة ()Structured Methods • يُعتبر النموذج الشاللي مثاال نمطيا عن المنهجيات المهيكلة. • المنهجية المهيكلة :تستند عادة على تقنيتين أساسيتين: – مخططات تدفق المعطيات (Data Flow Diagrams) DFDلنمذجة اإلجرائيات – مخططات عالقات الكيانات (Entity Relationship Diagrams) ERDلنمذجة المعطيات. • خصائص ميزات المنهجية المهيكلة: .1 تأخذ المنهجية منحى تسلسليا وتحويليا أكثر منه تكراريا وتزايديا. .2 تعطي المنهجية حلوال غير مرنة تلبي وظائف العمل المعرفة مسبقا ويصعب توسيعها تدريجيا في المستقبل. .3 تفترض المنهجية أن التطوير يبدأ دوما من الصفر وال تدعم إعادة استخدام مكونات برمجية موجودة. 29 ITA330 – S2 النموذج V 30 ITA330 – S2 النموذج V • نسخة مع ّدلة عن النموذج الشاللي. • مصممة لتعزيز قابلية االختبار (تركز على التوثق والتحقق). • إيجابيات النموذج: – التركيز على التوثق والتحقق في كل المراحل. • سلبيات النموذج: – تزداد صعوبة التعامل مع التعديالت. • خيار جيد لتطوير األنظمة التي تتطلب درجة عالية من الوثوقية كاألنظمة الطبية(.)Patient Control Systems 31 ITA330 – S2 متى نستخدم النموذج V؟ • عند بناء أنظمة تتطلب درجة عالية من الوثوقية. • عندما تكون المتطلبات معروفة مسبقا. • عند توفر مرونة بجدول تنفيذ المشروع. 32 ITA330 – S2 نموذج الطراز البدئي ()prototype 33 ITA330 – S2 استخدامات نموذج الطراز البدئي • لمساعدة الزبائن والمطورين على فهم متطلبات النظام. – انتقاء المتطلبات ( :)Requirements Elicitationيمكن للمستخدمين اختبار الطراز لفهم آلية دعم النظام ألعمالهم. – التحقق من المتطلبات ( :)Requirements Validationيسمح الطراز بكشف أخطاء المتطلبات والمتطلبات الناقصة. • يساعد في تخفيض احتماالت وآثار المخاطر (من خالل تخفيض احتماالت األخطاء في توصيف المتطلبات). 34 ITA330 – S2 مناهج بناء الطراز البدئي Ev o lu ti on ary p ro to ty pi ng Del i vered s ys tem Ou t li ne R equ irem ent s Th row-away P ro to ty pi ng ITA330 – S2 Execut able P rot ot yp e + S y st em S peci ficat io n 35 مناهج بناء الطراز البدئي • بناء الطراز التطوري ()Evolutionary prototyping – يُعاد تحسين الطراز الذي تم بناؤه عبر عدد من المراحل المتعاقبة وصوال إلى النظام النهائي المستهدف. – يُبنى الطراز التطوري بهدف تسليم المستخدمين نظام صالح للعمل .وفي هذه الحالة يتم البدء بتحقيق المتطلبات األكثر وضوحا. • بناء الطراز المهمل ()Throw-away prototyping – يُبنى الطراز بهدف اكتشاف المتطلبات ومشكالتها ومن ثم يُهمل ،حيث يمكن بعد ذلك استخدام إجرائية تطوير أخرى. – يُبنى الطراز المهمل بهدف اكتشاف المتطلبات والتحقق منها .وفي هذه الحالة يتم البدء بأقل المتطلبات وضوحا. 36 ITA330 – S2 نموذج الطراز البدئي التطوري ()Evolutionary Prototype • يُبنى النظام كسلسلة من اإلصدارات التزايدية (ُ )Incrementalتسلم تباعا للزبون. – – – – – 37 يبني المطورون طرازا بدئيا خالل مرحلة جمع المتطلبات. يقوم المستخدمون بتقييم الطراز المنجز. يقوم المستخدمون باقتراح اإلجراءات التصحيحية. يقوم المطورون بتحسين الطراز زبناء نسخة جديدة. عند بلوغ الزبون درجة مقنعة من الرضى والكفاية ،يقوم المطورون بمراجعة رماز النموذج األخير لتحسينه من خالل تطبيق المعايير الالزمة العتباره منتجا نهائيا. ITA330 – S2 إيجابيات الطراز البدئي التطوري • يستطيع الزبائن معاينة متطلبات النظام أثناء جمعها (إشراك والتزام الزبون). • يتعلم المطورون من الزبائن (وبالعكس). • يكون المنتج النهائي أكثر دقة وتوافقا مع ما هو متوقع أو مطلوب. • يمكن اكتشاف المتطلبات غير الواضحة في مراحل مبكرة. • يوفر درجة عالية من المرونة أثناء التصميم والتطوير. • يعطي مؤشرات واضحة وصحيحة لدرجة التقدم باتجاه المنتج. • يسمح بتسليم سريع لوظائف مفيدة. 38 ITA330 – S2 سلبيات الطراز البدئي التطوري • • • • • • • 39 قد يُبعد الفريق عن منهجية التطوير المنظمة نحو المزيد من عمليات ”البرمجة والتصحيح“ (.)code-and-fix يجب أن يتمتع فريق التطوير بمهارات عالية. تزداد صعوبة تقدير الكلفة والزمن. قد يزيد من تعقيد عمليات الصيانة الالحقة. قد يضغط الزبون باتجاه تسليم طراز غير نهائي. قد تتحول عملية تحسين الطراز إلى حلقة غير منتهية مع اكتشاف المزيد من االحتياجات والمتطلبات ).(scope creep ال يمكن اختبار المتطلبات غير الوظيفية بشكل كا ٍ ف (قد ال يُظهر النموذج متطلبات األمان الحساسة بشكل واضح). ITA330 – S2 نموذج الطراز البدئي المهمل )Throw-away Prototype( Ou t li ne requ irem en ts Dev elo p p ro to ty pe Evalu at e p ro to ty pe S p eci fy s ys tem Reus abl e com p on ent s Develo p s oft ware ITA330 – S2 Vali dat e s ys tem Del ivered s oft ware s ys tem 40 مشكالت الطراز البدئي المهمل • قد يتعرض المطورون لضغوط بهدف تسليم الطراز كمنتج نهائي. • يجب تجنب الوقوع في هذا الخطأ: – قد يكون مستحيال تحسين الطراز لتلبية المتطلبات غير الوظيفية. – يبقى الطراز من دون توثيق. – قد تنهار بنية النظام عند إجراء تعديالت إضافية. – يصبح احترام معايير الجودة أمرا غاية في الصعوبة. 41 ITA330 – S2 فوائد نموذج الطراز البدئي • يسمح بحل المشكالت الناجمة عن سوء الفهم بين المطورين والمستخدمين. • يسمح باكتشاف الخدمات الناقصة وبتوضيح الخدمات الملتبسة. • يمكن الحصول على نظام صالح للعمل في مرحلة مبكرة من اإلجرائية. • يمكن االستفادة من الطراز لوضع توصيف دقيق للنظام. • يساعد على نجاح تدريب المستخدمين واختبار النظام. 42 ITA330 – S2 النموذج الحلزوني ()Spiral • الصيغة المبسطة – هو نموذج الطراز البدئي السريع مضافا إليه عملية تحليل مخاطر قبل كل مرحلة. • إذا لم يكن ممكنا تخفيف كل المخاطر يتم إنهاء المشروع مباشرة. 43 ITA330 – S2 النموذج الحلزوني • يجمع ما بين الطبيعة التكرارية لنموذج الطراز البدئي والطبيعة التسلسلي للنموذج الممنهجة (الشاللي). • مع تطوير سريع لنسخ تزايدية من النظام البرمجي في سلسلة من اإلصدارات التزايدية. 44 ITA330 – S2 النموذج الحلزوني • يسبق كل مرحلة – دراسة البدائل – تحليل المخاطر • يلي كل مرحلة – تقييم للنسخة – تخطيط للمرحلة التالية 45 ITA330 – S2 النموذج الحلزوني • يركز على تحليل المخاطر وإدارتها في كل مرحلة. • يمكن النظر إليه كسلسلة مشاريع صغيرة يهتم كل منها بمعالجة مجموعة من المخاطر ( Start small, explore risks, prototype, .)plan, repeat • ال يمكن تحديد عدد الحلقات مسبقا (تشبه الحلقة األخيرة منه النموذج الشاللي). 46 ITA330 – S2 إيجابيات النموذج الحلزوني • يعطي مؤشرات مبكرة للمخاطر التي ال يمكن تجاوزها (وبقليل من الكلفة). • يستطيع المستخدمون رؤية النظام مبكرا (بسبب االعتماد على تقنيات بناء الطراز). • ُتبنى الوظائف األكثر خطورة في البداية. • يبقى المستخدمون قريبين من كل مراحل العمل. • يمكن الحصول على انطباعات وآراء المستخدمين بشكل مبكر. 47 ITA330 – S2 سلبيات النموذج الحلزوني • يصبح زمن تقييم المخاطر غير مبرر في المشاريع الصغيرة. • قد يتطلب التخطيط وتقييم المخاطر وبناء الطرز وقتا طويال جدا. • النموذج معقد (غير شائع االستخدام). • يحتاج لخبراء في تقييم المخاطر. • قد يتزايد عدد الحلقات بطريقة ال يمكن التنبؤ بنتائجها. • من الصعب تعريف مؤشرات ونقاط عالم لتقدير درجة التقدم باتجاه المنتج النهائي. 48 ITA330 – S2 متى نستخدم النموذج الحلزوني؟ • يُعتبر منطقيا بالنسبة لألنظمة الكبيرة المعقدة (أو الموجهة لالستخدام الداخلي). • يُعتبر مناسبا للمشاريع التي تنطوي على مخاطر كثيرة. • عندما تكون المتطلبات معقدة جدا وال يدرك المستخدمون احتياجاتهم بشكل واضح. • عند العمل على إعداد منتج جديد كليا (غير مسبوق). 49 ITA330 – S2 مقارنة بين النماذج المختلفة • تم عرض نماذج مختلفة لتطوير البرمجيات (مع إيجابيات وسلبيات كل منها). • تتضمن معايير انتقاء النموذج األنسب: – المؤسسة (حجمها ،خبراتها ،إدارتها.)... – خبرات ومهارات فريق العمل. – طبيعة المنتج المطلوب. • االقتراح األفضل؟ 50 ITA330 – S2