تطوير متكرر ومتزايد

يُقسم التطوير المتزايد وظائف النظام إلى أجزاء متزايدة. تُقدم شريحة من الوظائف في كل جزء متزايد بواسطة العمل متعدد التخصصات، بدءًا من المتطلبات وحتى النشر. تتكرر/ تزداد مجموعات العمليات الموحدة إلى مراحل: البداية، والإعداد، والبناء والانتقال.

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

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

تُقدم العديد من أمثلة الاستخدام المبكر في مقال كريغ لارمان وفيكتور باسيلي «التطوير المتكرر والمتزايد: تاريخ موجز»، مع واحد من أوائل مشاريع ناسا في الستينيات وهو مشروع ميركوري.

شكّل لاحقًا بعض مهندسي ميركوري قسمًا جديدًا داخل آي بي إم، حيث كان «جوهر برمجيات مكوك الفضاء التابع لناسا نظامَ برمجيات إلكترونيات الطيران الأساسي، الذي بنوه منذ عام 1977 إلى 1980، هو أحد الأمثلة المبكرة والمذهلة على نجاح التطوير المتكرر والمتزايد الكبير، طبق الفريق التطوير المتكرر والمتزايد في سلسلة من 17 تكرارًا على مدى 31 شهرًا، بمتوسط يُقدر بنحو ثمانية أسابيع لكل تكرار. كان دافعهم لتجنب دورة الحياة الشلالية هو تغيير متطلبات برنامج المكوك خلال عملية تطوير البرمجيات.[4]

تفضل بعض المنظمات، مثل وزارة الدفاع الأمريكية، المنهجيات التكرارية بدءًا من (إم آي إل-إس تي دي-498) «التي تشجع بوضوح التحصيل التطوري والتطوير المتكرر والمتزايد».

وجاء في تعليمات وزارة الدفاع رقم 5000.2 الصادرة عام 2000 تفضيلًا واضحًا للتطوير المتكرر والمتزايد:

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

لم تعد التنقيحات الأخيرة التي أجريت على تعليمات وزارة الدفاع رقم 5000.2 تشير إلى «التطوير الحلزوني»، ولكنها تدعو إلى اتباع النهج العام بوصفه أساسًا لبرامج التطوير/ الشراء البرمجية المكثفة.[5] وبالإضافة إلى ذلك، تستخدم الوكالة الأمريكية للتنمية الدولية نهجًا متطورًا ومتزايدًا في دورة برمجتها لتصميم، ومراقبة، وتقييم، وتعلم وتكييف مشاريع التنمية الدولية باتباع نهج لإدارة المشاريع يركز على دمج استراتيجيات التعاون والتعلم والتكيف لتكرار البرامج وتكييفها.[6]

السبب الرئيسي لفشل مشاريع تطوير البرمجيات هو اختيار النموذج، لذلك يجب اختياره بعناية فائقة.[7]

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

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

تتضمن الإرشادات للبرامج وتحليلها ما يلي:

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