التحوّل (الانتقال) Transition
الطور النهائي يتعلق بنقل المنتج النهائي إلى
الزبائن. النشاطات المعتادة في هذا الطور تتضمن:
·
الإصدارات المبدئية
لأغراض الاختيار من قبل بيئة المستخدم.
·
الاختبارات في الموقع،
أو تشغيل المنتج بالتوازي مع النظام القديم الذي سيستبدل.
·
تجهيز البيانات (مثل
تحويل قواعد البيانات و صبّها في قوالبها الجديدة، توريد البيانات ، الخ..)
·
تدريب المستخدمين
الجدد.
·
التسويق والتوزيع و
المبيعات.
يجب أن لا نخلط بين طور التحوّل هذا و
طور الاختبار التقليدي في نهاية النموذج الانحداري، فمنذ بداية التحوّل يجب أن
يكون لدينا منتجا قابلا للتشغيل بعد أن تم اختباره بالكامل، و أن يكون جاهزا و
متوفرا للمستخدمين. و كما أوضحنا سابقا، بعض المشاريع قد تتطلب خطوة اختبار مبدئية
، و لكن المنتج يجب أن يكون مكتملا قدر الإمكان قبل الدخول في هذا الطور.
كم عدد هذه التكرارات؟ و كم يجب أن تطول؟
التكرار الواحد يمتد عادة من أسبوعين إلى
شهرين، أية زيادة على شهرين سوف تؤدي إلى زيادة في التعقيد و الوصول إلى النقطة
التي لامناص منها: "الانفجار الكبير" ، دوّامة ضم الأجزاء إلى
بعضها البعض، حيث العديد من المكونات البرمجية ستحتاج إلى أن تنتظم و تلتحم
لأول مرة.
إذا كبر المشروع و زاد تعقيده فلا يعني
هذا أن تكون التكرارات أطول - لأن هذا سوف يزيد من مستوى التعقيد الذي سيكون على
المطوّرين التعامل معه في المرّة الواحدة. بدلا من ذلك يجب أن يخصص للمشروع الأكبر
تكرارات أكثر.
فيما يلي بعض العوامل التي يجب أن توثر في طول
مدّة التكرار:
·
دورات التطوير المبكرة
قد تحتاج لأن تكون أطول. هذا يعطي المطوّرين فرصة لأداء أعمال استكشافية على
تقنيات جديدة أو غير مختبرة ، أو لتحديد البنية التحتية للمشروع.
·
الأفراد حديثو الخبرة.
·
فرق العمل المتعددة
والتي تعمل على التوازي.
·
فرق العمل الموزعة (في
أكثر من موقع).
أيضا ، نريد أن نضم إلى هذه
القائمة المشروع ذو المراسمية
العالية (الشكليات التعاقدية) الذي سيحتاج عادة إلى تكرارات أطول. و نقصد
بالمشروع ذو المراسمية العالية ذلك الذي يتطلّب إصدار و توفير الكثير من الوثائق
الخاصة بالمشروع إلى الزبون، أو ربما مشروع يجب أن يلبّي العديد من المتطلبات
القانونية. مثال جيد على هذا المشاريع ذات العلاقة بالأمور العسكرية، ففي هذه
الحالة فان أعمال التوثيق سوف تزيد من طول فترة التكرار - و لكن كمية التطوير
البرمجي الذي يتم التصدي لها في هذا التكرار يجب أن تكون في حدودها الدنيا لتجنّب
عدّونا الرئيسي و هو عبء التعقيد.
القيد الزمني Time Boxing
الأسلوب الأمثل لإدارة عملية تكرارية تزايدية
هو فرض قيد زمني (صندقة زمنية). بهذا الأسلوب الحازم يتم تحديد فترة زمنية
ثابتة يجب خلالها إتمام تكرارية معينة.
إذا لم تكتمل التكرارية مع نهاية القيد
الزمني، يتم إنهاء التكرارية على أية حال. النشاط الأهم في التقييد الزمني هو
المراجعة في نهاية التكرارية. يجب أن تبحث المراجعة في أسباب التأخير، و أن
تعيد جدولة الأعمال غير المنتهية و تضمينها في التكرارات القادمة.
إحدى النصائح لكيفية تطبيق القيد الزمني، أن
يكون المطورون هم المسؤولين (أو على الأقل من لهم الكلمة العليا) عن تحديد ما هي
المتطلبات التي يتم تغطيتها في كل تكرار ، باعتبارهم هم الذين سوف يلتزمون بهذه
الآجال.
يعد الالتزام بالقيد الزمني أمرا صعبا، فهو
يتطلّب حسّا عاليا بالانضباطية خلال كامل المشروع. من المغري جدا التخلّي عن
المراجعة و تخطّي القيد الزمني إذا حان أجل التكرار و كانت نسبة اكتماله
"99%". حالما يرضخ المشروع لمثل هذا
الإغراء و يتم تجاهل مراجعة واحدة ، فإن المفهوم بكامله يبدأ في التداعي. إذا تم
تجاهل عدة مراجعات، فان التخطيط للتكرارات القادمة سوف تكون مائعة و تبدأ الفوضى
في أخذ مكانها.
يفترض بعض المدريرون أن التقييد الزمني يعيق
مرونة الإرجاء، هذا غير صحيح، فإذا لم تكتمل التكرارية وقت انتهاء أجل القيد
الزمني فإن العمل غير المكتمل يجب نقله إلى التكرارات التالية، و يتم إعادة
جدولة خطط التكرارات - يمكن أن يتضمن هذا إرجاء تاريخ التسليم أو إضافة تكرارات
أكثر. عموما للتقييد الزمني فوائد هي:
·
تفرض الهيكلية الصارمة
عملية التخطيط و معاودتها. فلا يتم التخلّي عن الخطط إذا بدأ المشروع في التمطيط.
·
إذا تم فرض التقييد
الزمني، تتضاءل فرص أن يغص المشروع في الفوضى إذا ما ظهرت مشاكل، حيث أن هناك
دائما مراجعة رسمية منتظمة تلوح في الأفق.
·
إذا ما تسرّب الخوف و
بدأ المطوّرون في التخبّط بصورة عشوائية، سيتم وقف هذا التخبّط حالما تتم
المراجعة.
بصورة أساسية، يسمح القيد الزمني للمشروع بكامله
أن يتريث مرة بعد الأخرى ليحزم أمره من جديد. انه لا يعرقل إمكانيات الإرجاء، و
يحتاج إلى إدارة مشروعات قوية كي يعمل بصورة صحيحة.
التوقيتات النمطية للمشروع.
كم يجب أن يستغرق كل طور من
الأطوار الأربعة؟ يتباين ذلك من مشروع لآخر، و لكن كمؤشّر عام 10% للاستهلال، 30%
للتفصيل، 50% للبناء و 10% للانتقال.
شكل7: التوقيتات المحتملة لكل طور. هذا المثال
يوضح طول كل طور لمشروع يستغرق سنتين.
العملية الموّحدة من راشيونال
العملية الموحّدة من أي بي ام The Rational Unified Process (the RUP) هي إحدى
أكثر الأمثلة شهرة للدورة الحياتية التكرارية
قيد الاستعمال حاليا. تم تطوير هذه المنهجية من قبل نفس "الأصدقاء
الثلاثة" الذين قاموا بتطوير UML ،
و لذلك فان RUP
متكاملة جدا مع UML.
بصورة أساسية، يقدّر القائمون على هذه
المنهجية بأن كل مشروع يختلف عن الآخر، و ذو احتياجات مختلفة، مثلا، بعض المشاريع
لا تتطلب إلا طورا قصيرا للاستهلال، بينما المشاريع ذات العلاقة بأمور عسكرية فإن
طور الاستهلال فيها قد يمتد لسنوات.
حتى هذه النقطة، تعد RUP مرنة و تسمح بإعادة تكييف كل طور في العملية. أيضا تحدد RUP و بكل عناية قواعد لكل فرد في المشروع و بحسب الاحتياج.
و قد أصدرت وقتها شركة راشيونال منتوجا
لمساعدة المشاريع التي تتبنى RUP ، يمكن إيجاد المزيد من
التفاصيل في www.rational.com .* المنتوج بالأساس عبارة
عن دليل على شبكة الانترنت أو برنامجا يضم جميع ملامح RUP. و تقدم الشركة إمكانية استعماله على سبيل التجربة. (تم بيعها
لاحقا لشركة IBM
في فبراير 2003)
شكل 8: لقطة من RUP (مؤسسة IBM).
تفصيل مزايا و عيوب RUP خارج نطاق درسنا هذا، و لكن بصفة عامة فان أساس RUP هي الدورة الحياتية التكرارية التزايدية و التي سيتم تبنّيها خلال
دروسنا هذه.
ملخص
يقدم إطار العمل التكراري التزايدي العديد من
الفوائد مقارنة بالعمليات التقليدية.
ينقسم إطار العمل هذا إلى أربعة أطوار
الاستهلال، التفصيل، البناء، الانتقال.
يعني التطوير التصاعدي استهداف الحصول على
توليف قابل للتشغيل في نهاية كل تكرار (بأكبر عدد ممكن منها).
التكرارات يمكن تقييدها زمنيا كأسلوب صارم
لجدولة و مراجعة التكرارات.
بقية هذه الدروس سوف تركز على إطار العمل Framework ، و كيف
تقوم UML
بدعم مخرجات كل طور في إطار العمل.
قد يعجبك ايضا