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

التطوير المتكرر والمتزايد (بالإنكليزية Iterative and incremental development) هو من أهم عمليات تطوير البرمجيات الدورية التي تم تصميمها للرد على العيوب الموجودة في نموذج الشلال.^[1][2] تبدأ العملية بخطة مبدئية وتنتهي بالنشر (deployment) آخذةً شكلاً دورياً. التطوير المتكرر والمتزايد يعتبر جزءاً أساسيا من العملية الموحدة للراشيونال والبرمجة القصوى ومن شتى أنواع أطر عمل أجايل لتطوير البرمجيات على وجه العموم.

بدأ استخدام هذا المصطلح في تطوير البرمجيات، مع تركيبة التجمع الطويلة الأمد لمصطلحي التكرار والتزايد اللذين اقتُرحا بشدة لجهود التطوير الكبيرة. فمثلًا، يذكر معيار (دي أو دي-إس تي دي-2167) لعام 1985 (في القسم 4-1-2): «أثناء تطوير البرمجيات، قد يكون هناك تكرار واحد أو أكثر لدورة تطوير البرمجيات يجري في نفس الوقت» و«يمكن وصف هذه العملية بأنها نهج «تحصيل تطوري» أو «بناء متزايد». تُحدد العلاقة بين التكرارات والزيادات في البرمجيات بواسطة عملية تطوير البرمجيات الشاملة.^[3]

نظرة عامة

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

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

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

المراحل

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

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

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

الاستخدام/ التاريخ

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

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

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

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

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

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

التناقض مع التطوير الشلالي

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

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

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

إرشادات التنفيذ

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

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

مراجع

موسوعات ذات صلة :

• موسوعة إدارة أعمال