You are on page 1of 21

‫هندسة البرمجيات‬

‫د‪ /‬عبدالملك الحميري‬


‫دورة حياة تطوير البرمجيات‬
‫‪SDLC‬‬
‫‪ ‬توجد مجموعة من النماذج أو أطر العمل )‪ (Framework‬التاي تصف الفعاليات التي يجب أن يتم‬
‫إنجازها في كل مرحلة من مراحل تطوير المشاريع البرمجية‪.‬‬
‫‪ ‬جميع النماذج تتنافس قيما بينها من ناحية تقليل التكلفة‪ ,‬الزمن‪ ,‬زيادة كفائة المبرمجين‪ ,‬زيادة رضى‬
‫المستخدمين ‪....‬‬
‫‪ ‬سيتم مناقشتها من ناحية المفهوم العام ونقاط القوة والضعف ومتى وأين يتم استخدامها‪ ,‬وذلك فيما‬
‫يلي‪:‬‬

‫‪2‬‬
‫‪ ‬نموذج بسيط يبدأ بتعريف المتطلبات (المعلومات المطلوبة من العميل لبنأ البرمجيات‪ ,‬الوظائف‪,‬‬
‫األداء‪ ,‬الواجهات)‪ .‬ومن ثم مرحلة التصميم والتي يتم فيها تحديد المعمارية البرمجية‪ ,‬تمثيل‬
‫الواجهات‪ ,‬وتفاصيل الخوارزميات المستخدمة‪ .‬ومن ثم مرحلة التنفيذ وهي مرحلة بناء الكود‪ ,‬قاعدة‬
‫البيانات المستخدمة‪ ,‬توثيق المستخدم‪ ,‬واالختبار‪ .‬ومن ثم التنصيب في بيئة اختبار ومن ثم قي البيئة‬
‫الحقيقية‪ .‬ومن ثم تتم عملية الصيانة والتطوير‪.‬‬

‫‪3‬‬
‫‪ ‬نقاط القوة‪:‬‬
‫‪ ‬سهل الفهم وسهل االستخدام )‪.(Easy to understand, easy to use‬‬
‫‪ ‬يوفر هيكل أساسي للكادر الغير خبير )‪.(Provide structure to inexperienced staff‬‬
‫‪ ‬نقاط التسليم األساسية في كل مرحلة من المراحل واضحة ‪(Milestones are well‬‬
‫)‪understood‬‬
‫‪ ‬يفترض أن متطلبات المستخدمين لن تتغير )‪ (Sets requirements stability‬أثناء التطوير‪.‬‬
‫‪ ‬جيد للتحكم من قبل اإلدارة ))‪ (Good for management control (plan, staff, track‬من‬
‫ناحية الخطط والموظفين ومن ناحية تتبع الخطوات أثناء التنفيذ‪.‬‬
‫‪ ‬مفيد عند تصميم برمجيات تبحث عن نوعية اإلنتاج (ذات جودة) بغض النظر عن الكلفة والجدول‬
‫الزمني )‪.(quality is more important‬‬

‫‪4‬‬
‫‪ ‬نقاط الضعف‪:‬‬
‫‪ ‬كل المتطلبات يجب أن تكون معروفة مسبقا )‪ (Requirement must be known‬حيث أن‬
‫االجتماع الولي يجب أن العمالء يجب أن نعرفه فيه كل المتطلبات وهذا صعب نسبياً للفرق البرمجية‬
‫المبتدأه مما يجعلها تصنع وثيقة متطلبات ناقصة ال تلبي متطلبات العميل‪.‬‬
‫‪ ‬التسليمات )‪ (Deliverables‬في كل مرحلة ثابتة وتمنع المرونة )‪ (inhibits flexibility‬بسبب‬
‫عدم وجود تغذية راجعة‪.‬‬
‫‪ ‬قد تعطي إنطباع خاطئ عن التقدم عند االنتقال من مرحلة ألخرى ‪(false impression of‬‬
‫)‪ progress‬إلنه عند تسليم المنتج النهائي قد ال يلبي متطلبات العميل (المتطلبات لم تكن معروفة‬
‫جيدا)‪.‬‬
‫‪ ‬ال يعكس طبيعة حل المشاكل في البرمجيات )‪(does not reflect problem-solving nature‬‬
‫النها تعتمد في الغالب على تكرار المراحل )‪ (iteration of phases‬التوجد مرحلة تنتهي بشكل‬
‫نهائي من المحاولة األولى (النها دائما تجربة وخطأ وفحص واختبار الى أن نصل الى متطلبات‬
‫المستخدم بشكل مثالي)‪.‬‬

‫‪5‬‬
‫‪ ‬نقاط الضعف‪:‬‬
‫‪ ‬عملية التكامل بين عمل الفرق المختلفة لن تتم بشكل مستمر أثناء دورة حياة المشروع البرمجي وأنما‬
‫تتم في نهاية المشروع البرمجي )‪ (one big bang at the end‬واذا كان هناك مشكلة في مرحلة‬
‫التكامل (خطأ عند أحد الفرق البرمجية) فستؤدي إلى إنهيار المشروع والرجوع الى المرحلة األولى‪.‬‬
‫‪ ‬ال توجد الية لفحص النظام ومراجعته من قبل المستخدم اال في المرحلة النهائية ‪(little‬‬
‫)‪ opportunity for customer to preview the system‬مما يعقد من تحقيق متطلبات‬
‫المستخدم (وهذا قد يؤدي الى فسخ العقد مع المستخدم أو العودة الى كتابة كل شيء من البداية وهذا‬
‫يؤدي الى خسائر كبيرة للفرق البرمجية وشركات البرمجيات)‪.‬‬

‫‪6‬‬
‫‪ ‬متى وأين يتم استخدامه‪:‬‬
‫‪ ‬متطلبات المشروع معروفة بشكل جيد وواضحة للمبرمجين ‪(Requirement are very well‬‬
‫)‪.known‬‬
‫‪ ‬تعريف المنتج ثابت )‪.(Production definition is stable‬‬
‫‪ ‬التقنيات المادية والبرمجية التي سيتم استخدمها واضحة للمطورين ‪(Technology is‬‬
‫)‪.understood‬‬
‫مسبقا ‪(new‬‬
‫ً‬ ‫‪ ‬عندما يكون البرنامج الذي نعمل عليه نسخة جديدة (إصدار جديد) من برنامج موجود‬
‫)‪ version of an existing product‬حتى ولو تم تطوير اإلصدار األولى بمنهجية مختلفة‪.‬‬
‫‪ ‬عندما نريد االنتقال بالبرنامج من منصة ألخرى ‪(Porting an existing product to a new‬‬
‫)‪( platform‬برنامج يعمل في بيئة األندرويد ونريد نقله الى بيئة الـ ‪.)IOS‬‬

‫‪7‬‬
‫‪ ‬يستخدمه المطورين من أجل بناء نموذج أولي للبرمجيات المطلوب بنائها أثناء مرحلة دراسة‬
‫المتطلبات‪.‬‬
‫‪ ‬يجب التقييم من قبل المستخدم النهائي‪.‬‬
‫‪ ‬المستخدم يعطي تغذية راجعة )‪ (Corrective feedback‬يستفيد منها المطور في تصحيح عمله‬
‫الحالي‪.‬‬
‫‪ ‬المطور يستمر في عملية التصحيح للنموذج األولي )‪ (Refine the prototype‬الى أن يصل الى‬
‫مرحلة رضى العميل‪.‬‬
‫‪ ‬في األخير المنتج يصل الى مرحلة الـ ‪ standers‬بالنسبة للمنتج النهائي‪.‬‬
‫‪ ‬يمر بالخطوات التالية‪ :‬خطة المشروع األولية )‪ (Preliminary project plan‬ومن ثم مرحلة‬
‫النموذج الورقي عالي المستوى الجزئي )‪ (Partial high-level paper model‬ومن ثم مرحلة‬
‫موصفات المتطلبات األولية )‪ (Partial requirements specification‬ومن ثم يتم بناء النموذج‬
‫األولي الذي يحتوي على موصفات النظام األساسية والمهمة جدا )‪(Basic & critical attributes‬‬
‫ومن ثم سيبدأ المصمم ببناء قواعد البيانات وواجهات المستخدم ومن ثم سيقوم المطور بتوضيح هذا‬
‫النموذج األولي للمستخدم )‪ (Demonstrates the prototype‬والمستخدم يقيم النموذج ويقترح‬
‫بعض التطويرات ومن ثم تستمر هذه الدورة حتى نحصل على رضى المستخدم‪.‬‬
‫‪8‬‬
‫‪ ‬نقاط القوة‪:‬‬
‫‪ ‬المستخدم سيعاين بنفسه مرحلة تجميع المتطلبات ‪(customers can see the system‬‬
‫)‪requirements gathering‬‬
‫‪ ‬المطور لديه فرصة للتعلم من المستخدم )‪.(Developers learn from customers‬‬
‫‪ ‬المنتج النهائي يكون أكثر دقة )‪ (A mor accurate end product‬وأكثر مطابقة لوجهة نظر‬
‫المستخدم‪.‬‬
‫‪ ‬بعض المتطلبات الغير متوقعة )‪ (unexpected requirements‬يمكن تحصيلها من التغذية الراجعة‬
‫من المستخدم النهائي‪.‬‬
‫‪ ‬يسمح للمطور بتصميم أكثر مرونة )‪.(flexible design‬‬
‫‪ ‬مراحل التقدم في انتاج المنتج النهائي البرمجي تكون واضحة ‪(Visible signs of progress‬‬
‫)‪produced‬‬
‫‪ ‬يوجد تفاعل بين المنتج األولي والتطبيقات الخاصة به ووعي المستخدم النهائي لكيفية عمل المنتج‬
‫األولي وكيفية تطوره لما يلبي متطلبات المستخدم‪.‬‬

‫‪9‬‬
‫‪ ‬نقاط الضعف‪:‬‬
‫‪ ‬سيكون لدى المطورين نزعة إلهمال الهيكلية عند تطوير البرامج ‪(tendency to abandon‬‬
‫)‪ structured program development for code-and-fix development‬ويتحول الى‬
‫مجرد كتابة كود ومن ثم تصحيح األخطاء‪.‬‬
‫‪ ‬سمعة سيئة عن هذا النوع من التطوير ألن المطور يلجأ الى الحلول السريعة ‪(Bas reparation‬‬
‫)‪ for quick-and-dirty methods‬وكتابة الكود بشكل سئ بسبب التماس المباشر مع المستخدم‪.‬‬
‫‪ ‬سيؤثر بشكل كبير على صيانة وادامة المنتج على المدى البعيد ‪(Maintainability may be‬‬
‫)‪.overlooked‬‬
‫‪ ‬قد يطلب المستخدم ارسال النماذج اليه ‪(the customer may want the prototype‬‬
‫)‪ delivered‬وهذا قد يؤدي الى حالة تالعب من قبل المستخدم‪.‬‬
‫‪ ‬يمكن أن تستمر مرحلة التغذية العكسية والتكرار الى ماالنهاية ‪(process may continue‬‬
‫))‪ forever (scope creep‬بسبب عدم معرفة المستخدم النهائي لمتطلباته‪.‬‬

‫‪10‬‬
‫‪ ‬متى وأين يتم استخدامه‪:‬‬
‫‪ ‬اذا كانت المتطلبات غير مستقرة )‪ (Requirement are unstable‬ويجب التأكد منها من قبل‬
‫المستخدمين (أو اذا كان المستخدمين غير قادر على تحديد المتطلبات بشكل كامل من المرحلة‬
‫األولى)‪.‬‬
‫‪ ‬قد تستخدم هذه الطريقة جزء من أجزاء دورة حياة تطوير البرمجيات ‪(requirements‬‬
‫)‪clarification stage of a waterfall model‬‬
‫‪ ‬تستخدم في مرحلة تطوير واجهة برامج المستخدمين )‪(developed user interface‬‬
‫‪ ‬وقد تستخدم اذا اردنا تطوير منتج جديد )‪(New, original development‬‬
‫‪ ‬في بعض األحيان قد تستخدم في تطوير أجزاء التحليل والتصميم في البرمجة الموجهة نحو الكائنات‬
‫)‪(with the analysis and design portions of object-oriented development‬‬

‫‪11‬‬
‫‪ ‬يتم تصميم النظام على شكل‬
‫الدفعات‬ ‫من‬ ‫مجموعة‬
‫(الزيادات) وكل دفعة تقدم‬
‫مجموعة من الوظائف تبدأ‬
‫باالهم (اإلصدار األول)‬
‫حتى‬ ‫تدريجي‪,‬‬ ‫وبشكل‬
‫الوصول الى تلبية كل‬
‫متطلبات المستخدم‪.‬‬

‫‪12‬‬
‫‪ ‬نقاط القوة‪:‬‬
‫‪ ‬يستخدم في تطوير البرمجيات التي تحتوي على مخاطر عالية ‪(Develop high-risk or major‬‬
‫)‪ function first‬من ناحية عدم معرفة المستخدم لمتطلباته‪ ,‬باإلضافة الى أنه يستخدم عند االحتياج‬
‫لتطوير الوظائف األساسية أوال (األكثر فائدة للمستخدم) بحيث ال يتم انتاج وظائف ال تهم المستخدم‬
‫في البداية وبالذات اذا كان ال يوجد تقبل من المستخدم لهذا النظام‪.‬‬
‫‪ ‬كل اصدار يقوم بإيصال منتج قابل للعمل )‪( (Operational product‬منتج يمكن تسويقه)‪.‬‬
‫‪ ‬العميل قادر على االستجابة لكل اصدار )‪(respond to each build‬‬
‫‪ ‬يستخدم تقنية فرق تسد )‪ (Divide and conquer‬من أجل تقسيم المهام الى أجزاء صغيرة من أجل‬
‫السيطرة عليها ومن ثم عملية تكامل النظام‪.‬‬
‫‪ ‬تكلفة االيصال األولية اقل من بقية النماذج )‪(lower initial delivery cost‬‬
‫‪ ‬سرعة إيصال المنتج األولي للمستخدم )‪(initial product delivery is faster‬‬
‫‪ ‬المستخدم سيحصل على الوظائف المهمة في البداية )‪(Important functionality early‬‬
‫‪ ‬مخاطر تغيير المتطلبات تكون أقل )‪.(Risk of changing requirements is reduced‬‬
‫‪13‬‬
‫‪ ‬نقاط الضعف‪:‬‬
‫‪ ‬يحتاج الى تخطيط وتصميم )‪ (Good planning and design‬جيد ألنه سيبدأ بالوظائف الرئيسية‬
‫(النه اذا كان هناك خلل في اإلصدار األول فسوف يؤثر على باقي اإلصدارات)‪.‬‬
‫‪ ‬تعريف مبكر لكامل وظيفية النظام ‪(Requires early definition of a complete and fully‬‬
‫)‪ functional system‬لمعرفة الوظائف التي سيتم وضعها أوال وفي كل اصدار‪.‬‬
‫‪ ‬واجهات المستخدمين يجب أن تكون معرفة بشكل جيد )‪(Well-defined module interfaces‬‬
‫لذلك قد يجب تطويرها قبل األمور األخرى‪.‬‬
‫‪ ‬الكلفة اإلجمالية للنظام تكون مكافئة لبقية النماذج ‪(Total cost of the complete system is‬‬
‫)‪.not lower‬‬

‫‪14‬‬
‫‪ ‬متى وأين يتم استخدامه‪:‬‬
‫‪ ‬يستخدم اذا كان هناك مخاطر في النظام )‪ ,(Risk‬مشاكل في الميزانية )‪ ,(Funding‬مشاكل في‬
‫الجدول الزمني )‪ ,(Schedule‬تعقيد في البرنامج )‪ (Program complexity‬ال يوجد اتفاق بين‬
‫المطور والمستخدم‪ ,‬أو الحاجة الى إصدارات من النظام بشكل مبكر ‪(Early realization of‬‬
‫)‪benefits‬‬
‫‪ ‬يمكن استخدامه اذا كانت معظم المتطلبات معروفة في البداية ويتوقع لها التطور في المستقبل‬
‫)‪.(evolve over time‬‬
‫‪ ‬اذا كان هناك حاجة للوصول الى الوظيفة الرئيسية وايصالها الى السوق بسرعة ‪(get basic‬‬
‫)‪ functionality to the market early‬خصوصا اذا كان هناك التنافس بين بعض الشركات‬
‫وهناك حاجة الطالق المنتج بأسرع وقت بالوظائف الرئيسية‪.‬‬
‫‪ ‬يستخدم في المشاريع التي تكون جداولها الزمنية في التطوير طويلة جداً ‪(Length development‬‬
‫)‪.schedules‬‬
‫‪ ‬وفي المشاريع ذات التقنيات الجديدة )‪ (on a project with new technology‬لم يتم تجربتها‬
‫سابقا مما يعطي مخاطر أقل‪.‬‬

‫‪15‬‬
‫‪ ‬من أهم نماذج تطوير البرمجيات وكان األكثر استخدما خصوصا في المشاريع الكبيرة حتى ظهرت‬
‫النماذج الحديثة‪.‬‬
‫‪ ‬يقوم بإضافة تحليل المخاطر )‪ (Risk Analysis‬ولغات البرمجة من الجيل الرابع )‪ (4gl RAD‬مع‬
‫التطوير المتسارع للتطبيقات باإلضافة الى نموذج الشالل‪.‬‬
‫‪ ‬سمي حلزوني الن كل دورة تتكون من خطوات نموذج الشالل مع تكرارها حتى تحقيق األهداف‬
‫النهائية‪.‬‬

‫‪16‬‬
‫‪ ‬نقاط القوة‪:‬‬
‫‪ ‬يوفر تحديد مسبق للمخاطر التي ال يمكن التغلب عليها )‪ (insurmountable risk‬بدون تكلفة كبيرة‬
‫مما يسمح لنا باخذ قرار االستمرارية في المشروع أو التوقف (المشروع مجدي اقتصاديا او ال)‪.‬‬
‫‪ ‬المستخدم يستطيع رؤية النظام بشكل مبكر باستخدام أدوات النمذجة األولية ‪(Rapid prototyping‬‬
‫)‪tools‬‬
‫‪ ‬الوظائف عالية المخاطر )‪ (Critical high-risk functions‬سيتم تطويرها أوال وبالتالي‬
‫سيشاهدها المستخدم في البداية ومن ثم يحدد هل يريد االستمرار في المشروع أو التوقف‪.‬‬
‫‪ ‬التصميم ال يكون مثالي من البداية ألنه حلزوني وتكراري وسيستمر في الدوران حتى تحقيق المثالية‪.‬‬
‫‪ ‬المستخدم قريب من كل مراحل دورة حياة تطوير البرنامج ‪(users can be closely tied to all‬‬
‫)‪ lifecycle steps‬فيكون مطلع على كل التفاصيل وبالتالي مساعدة المطور تطوير أو الغا وظائف‬
‫معينة‪.‬‬
‫‪ ‬ستكون هناك تغذية راجعة متكررة وسريعة من المستخدمين من أجل تحسين التصميم‪.‬‬
‫‪ ‬تقييم التكلفة التراكمية بشكل متكرر من أجل معرفة الجدوى االقتصادية والتكلفة الكلية للمشروع‬
‫بشكل مبكر‪.‬‬
‫‪17‬‬
‫‪ ‬نقاط الضعف‪:‬‬
‫‪ ‬يحتاج وقت كبير لتحليل وتحديد المخاطر وهذا غير مجدي بالنسبة للمشاريع الصغيرة والمتوسطة أو‬
‫التي لديها مخاطر قليلة جدا‪.‬‬
‫‪ ‬الوقت المستهلك في التخطيط وضبط األهداف وتحديد المخاطر وتقليلها وبناء النموذج االولي يمكن‬
‫أن يكون كبير جدا مما يؤدي الى نفقات كبيرة وعدم رضى المستخدمين‪.‬‬
‫‪ ‬النموذج معقد وغير مناسب للمشاريع الصغيرة والمتوسطة الحجم‪.‬‬
‫‪ ‬يحتاج خبرة في تقييم المخاطر )‪ (Risk assessment‬وليس كل المطورين لديهم هذه الخبرات‪.‬‬
‫‪ ‬الدورة الحلزونية يمكن أن تستمر الى ماالنهاية خصوصا اذا لم يكن هناك تقارب في وجهات النظر‬
‫بين المطورين و المستخدمين‪.‬‬
‫‪ ‬المطورين قد يتم توزيعهم في المراحل التي ال تحتوي على عمليات تطوير على مراحل فيها نشاطات‬
‫بعيده عن تخصصاتهم‪.‬‬
‫‪ ‬من الصعب تحديد األهداف ونقاط التسليم القابلة للتدقيق من قبل المستخدمين ‪(verifiable‬‬
‫)‪ milestones‬والتي تحدد استعداد المنتج لالنتقال الى المرحلة المقبلة (والسبب قد يكون عدم وجود‬
‫الخبرة أو التجارب السابقة)‪.‬‬
‫‪18‬‬
‫‪ ‬متى وأين يتم استخدامه‪:‬‬
‫‪ ‬عندما يكون انشاء النموذج الولي مفيد ومهم‪.‬‬
‫‪ ‬اذا كانت التكلفة والمخاطر وتقيمها مهم في البداية‪.‬‬
‫‪ ‬مهم في المشاريع التي تمتلك مخاطر عالية أو متوسطة (التكلفة‪ ,‬الجدول الزمني‪ ,‬الخبرات‪ ,‬ظروف‬
‫العمل‪ ,‬البيئة المحيطة)‪.‬‬
‫‪ ‬اذا كان االلتزام الطويل في المشروع غير منطقي )‪ (Long-term commitment unwise‬بسبب‬
‫التغيرات المحتملة في األوليات االقتصادية )‪(Potential changes to economic priorities‬‬
‫النه البد من تحديد جدوى اقتصادية في البداية‪.‬‬
‫‪ ‬اذا كان المستخدم غير متأكد من احتياجته‬
‫‪ ‬اذا كانت المتطلبات معقدة‬
‫‪ ‬اذا كان خط انتاج جديد )‪.(New product line‬‬
‫‪ ‬اذا كانت التغييرات المتوقعة كبيرة وخصوصا عندما يكون المستخدم في مرحلة البحث والتوقع‬
‫)‪(Research & exploration‬‬
‫‪19‬‬
‫‪ ‬تقنية جديدة ولكنها مستخدمة في معظم برامج التطوير حول العالم في الوقت الحالي‪.‬‬
‫‪ ‬تتكون من مجموعة من الطرق وليس طريقة واحدة‪.‬‬
‫‪ ‬تستخدم من اجل تسريع عملية تطوير البرمجيات ‪(Speed up or bypass one or more life‬‬
‫)‪ cycle phases‬بتجاوز بعض مراحل التطوير‪.‬‬
‫‪ ‬أقل رسمية من الطرق السابقة )‪.(Usually less formal‬‬
‫‪ ‬تستخدم في التطبيقات الحرجة من ناحية الزمن )‪.(Used for time-critical application‬‬

‫‪20‬‬
Some Agile Methods
‫ وهذا‬:(Adaptive Software Development (ASD)) ‫ نموذج تطوير البرمجيات التفاعلي‬
.‫النموذج يتغير مع الوقت‬
(Feature Driven Development ‫ نموذج تطوير البرمجيات المقاد بالخصائص المستقبلية‬
(FDD))
(Crystal Clear) ً‫ طريقة التطوير الواضحة جدا‬
(Dynamic Software Development Method ‫ طريقة تطوير البرمجيات الديناميكية‬
(DSDM))
(Rapid Application Development (RAD)) ‫ طريقة التطوير السريعة‬
Scrum 
(Extreme Programming (XP)) ‫ طريقة البرمجة القصوى‬
Rational Unify Process (RUP) 

21

You might also like