إحصائية العضو

آخـر مواضيعي

0 Sams Teach Yourself The CSharp Language in 21 Days 0 Essential CSharp 2.0 0 كيف تعرف ان موقعك متوافق مع web2 ؟ 0 فلاشات اسلاميه 0 Essential ASP.NET with Examples in CSharp

المستوى: 13 []
الحياة 31 / 313

النشاط 70 / 703
المؤشر 52%

الفصل 2
UML داخل عملية التطوير
<H2 align=right>UML كترميز</H2>عند تطويرهم لUML ، اتخذ الأصدقاء الثلاثة قرارا واضحا جدا بعدم تضمين اللغة أية قضايا تتعلق بالعمليات process. ذلك لأن العمليات تثير الكثير من الجدل - فما يسري على شركة ما قد يشكل كارثة بالنسبة لشركة أخرى. فشركة مختصة بمجالات الدفاع تتطلب عمليات توثيق و جودة و اختبارات أعقد بكثير من شركة مختصة بالتجارة الإلكترونية. لذلك فإن لغة UML عمومية، لغة عامة تسمح بالتقاط المفاهيم الأساسية لتطوير البرمجيات و وضعها على "ورقة".

بعبارة أخرى، UML هي ببساطة لغة أو أداة ترميز أو قواعد نحوية ، سمّها ما شئت. المهم، أنها لن ترشدك الى كيف يتم تطوير البرمجيات.

لكي تتعلم كيفية استخدام UML بكفاءة، سوف نتعامل مع عملية process مبسّطة خلال الدروس القادمة، و نحاول فهم كيف تساعدنا UML في كل مرحلة. و كبداية، لنلقى نظرة أولا على بعض العمليات البرمجية الشائعة.


النموذج الإنحداري Waterfall Model


بحسب النموذج الانحداري كل مرحلة يجب إنهائها قبل الشروع في المرحلة التي تليها.

هذه العملية المبسطة (و التي يسهل ادارتها) تبدأ بالتداعي بمجرد أن يزداد تعقيد و حجم المشروع. أهم مشاكلها هي:

• حتى الأنظمة الضخمة يجب أن تكون مفهومة و سبق تحليلها بالكامل قبل مباشرة مرحلة التصميم. فيزداد بهذا التعقيد و يصبح عبئا على المطوّرين.
• المخاطر Risk تتجمع لاحقا. المشاكل عادة ما تظهر في المراحل الأخيرة من العملية - خاصة خلال التحام النظام. و للأسف، تزداد تكلفة تصحيح الأخطاء بصورة مضاعفة مع مرور الزمن.
• في المشاريع الكبيرة، كل مرحلة تستغرق فترات طويلة مبالغ فيها. مرحلة اختبار بطول سنتين ليست بالتأكيد وصفة جيدة لشحن ذاكرة فريق العمل!

أيضا، حيث أن مرحلة التحليل تنجز في مخاض قصير مع تدشين المشروع، سنواجه مخاطرة جدية تتمثل في القصور في فهم متطلبات الزبون. حتى لو التزمنا باجراءات صارمة لادارة المتطلبات و قمنا بصياغتها تعاقديا مع الزبون. هناك دائما احتمال بأنه مع استكمال التوليف coding و الدمج integration و الاختبار لن يكون المنتج النهائي بالضرورة هو ما يتوقعه الزبون.

برغم كل ما ذكرنا، لا يوجد عيب في النموذج الانحداري، بشرط أن يكون المشروع صغيرا بما يكفي. صحيح ان تعريف "صغير بما يكفي" قابل للنقاش، و لكنه أساسي، فإذا أمكن لمشروع أن يتصدى له فريق صغير من الأفراد، كل فرد على دراية بجميع جوانب المشروع، و إذا كانت فترة المشروع قصيرة (بضعة أشهر)، عندها يكون النموذج الانحداري عملية لها قيمتها. فهو أفضل بكثير من الخبط العشوائي!

بايجاز، النموذج الانحداري سهل الفهم و بسيط في ادارته. لكن مميزات هذا النموذج تبدأ في التداعي بمجرد أن يزداد تعقيد المشروع.


النموذج اللولبي
الاسلوب البديل هو النموذج اللولبي، حيث نقوم بالتصدّي للمشروع عن طريق تقسيمة إلى سلسلة من الدورات الحياتية lifecycles القصيرة ، كل دورة تنتهي باصدار لبرنامج قابل للتنفيذ.



مع هذا الاسلوب:

• يستطيع فريق العمل أن يشتغل على كامل الدورة الحياتية (تحليل، تصميم، توليف Code، اختبار) بدلا من صرف سنوات على نشاط واحد.
• يمكننا الحصول على ملاحظات وتقييم الزبون مبكرا و بصورة منتظمة، ورصد الصعوبات المحتملة قبل التمادي بعيدا في عمليات التطوير.
• يمكننا التصدّي لنقاط المخاطرة مقدما، بالأخص التكرارات ذات المجازفة العالية (مثلا: التكرار الذي يتطلب تنفيذ بعض التقنيات الجديدة غير المجرّبة) يمكن تطويرها أولا.
• يمكن اكتشاف مدى حجم و تعقيد العمل مبكرا.
• الاصدار المنتظم للبرنامج يعزّز من الثقة.
• الوضع الحالي للمشروع (مثل: مقدار ماتم انجازه) يمكن تحديده بدقة أكبر.

عيوب العملية اللولبية هي:

• عادة ما ترتبط هذه العملية بما يعرف بالتنشئة السريعة للتطبيقات Rapid Application Development ، و التي تعتبر من قبل كثيرين مجرد hacker's charter.
• العملية أكثر صعوبة في إدارتها. في النموذج الانحداري يمكن الاستعانة بالتقنيات التقليدية لإدارة المشروعات مثل مخططات كانط Gantt، لكن العمليات اللولبية تتطلب أساليب مختلفة.

من أجل تدارك عيوب العملية اللولبية، لنلقي نظرة على أسلوب مشابه لكن أكثر تقنينا و يدعى اطار العمل التكراري التزايدي Itrative, Incremental Framework.




اطار العمل التكراري التزايدي
اطار العمل التكراري التزايدي Itreative, Incremental Framework هو امتداد منطقي للنموذج اللولبي، لكنه أكثر تقنينا و صرامة. سوف نقوم بتبنّي اطار العمل التكراري التزايدي خلال بقية هذه الدروس.

ينقسم اطار العمل الى أربعة أطوار رئيسية: الاستهلال Inception، التفصيل Elaboration، البناء Construction و التنقل Transition. يتم انجاز هذه الأطوار على التوالي، لكن يجب أن لا نخلط بين هذه الأطوار و المراحل في الدورة الحياتية للنموذج الانحداري. في هذا القسم سوف نشرح هذه الأطوار و نستعرض النشاطات التي يتم أداؤها في كل طور.



</STRONG>
الاستهلال
يتعلق طور الاستهلال بوضع نطاق المشروع و تحديد التصوّر العام له. بالنسبة للمشاريع الصغيرة يمكن لهذا الطور أن يكون مجرد دردشة بسيطة على فنجان قهوة يعقبها اتفاق على البدء في المشروع. في المشاريع الكبيرة يتطلب الأمر المزيد من التحرّي. المخرجات deliverables المحتملة من هذا الطور هي:

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

سوف نناقش طور الاستهلال بشيء من التفصيل عندما نتعرض لدراسة حالة case study في الفصل الرابع.


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

نموذجان من UML يكون لهما قيمة كبيرة في هذه المرحلة. نموذج حالة الاستخدام Use Case سيساعدنا في متطلبات المستفيد= الزبون ، و مخطط الطبقة Class Diagram و الذي ايضا يمكن استخدامه لاستكشاف المفاهيم العامة التي يتصورها المستفيد. المزيد حول هذا الموضوع قريبا.




البناء
في طور البناء، نقوم ببناء المنتج. هذا الطور لن يتحقق بأسلوب خطي Linear ؛ بل يتم بناؤه بنفس أسلوب النموذج اللولبي، من خلال سلسلة من التكرارات. كل تكرار هو نفسه الاسلوب القديم: نموذج انحداري([عزيزي الزائر يتوجب عليك التسجيل للمشاهدة الرابطللتسجيل اضغط هنا]) بسيط. و من خلال الحرص على أن يكون كل تكرار أقصر ما يمكن، نأمل أن نتجنب المشاكل المزعجة التي ترافق الانحداريات.




مع نهاية أكبر عدد من من التكرارات سوف نطمح في الحصول على منظومة تعمل (مبدئيا بالطبع، ستكون منظومة محدودة جدا في المراحل المبكرة). هذه التكرارات تسمّى تزايدات Increments، ومن هنا أتت تسمية اطار العمل هذا!


التحوّل (الانتقال) Transition
الطور النهائي يتعلق بنقل المنتج النهائي الى الزبائن. النشاطات المعتادة في هذا الطور تتضمن:

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

يجب أن لا نخلط بين طور التحوّل هذا و طور الاختبار التقليدي في نهاية النموذج الانحداري ، فمنذ بداية التحوّل يجب ان يكون لدينا منتجا قابلا للتشغيل و تم اختباره بالكامل، و أن يكون جاهزا و متوفرا للمستخدمين. و كما اوضحنا سابقا، بعض المشاريع قد تتطلب خطوة اختبار مبدئية ، و لكن المنتج يجب ان يكون مكتملا قد الامكان فبل الدخول في هذا الطور.


كم عدد هذه التكرارات؟ و كم يجب ان تطول؟
التكرار الواحد يجب عادة ان يمتد من اسبوعين الى شهرين، أية زيادة على شهرين سوف تؤدي الى زيادة في التعقيد و الوصول الى النقطة التي لامناص منها : "الانفجار الكبير" ، دوّامة ضم الأجزاء الى بعضها البعض، حيث العديد من المكونات البرمجية ستحتاج الى ان تنتظم و تلتحم لأول مرة.

اذا كبر المشروع و زاد تعقيده فلا يعني هذا أن تكون التكرارات أطول - لأن هذا سوف يزيد من مستوى التعقيد الذي سيكون على المطوّرين التعامل معه في المرّة الواحدة. بدلا من ذلك المشروع الأكبر يجب أن يخصص له تكرارات أكثر.

فيما يلي بعض العوامل التي يجب أن توثر في طول مدّة النكرار:

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

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


القيد الزمني Time Boxing
الأسلوب الأمثل لادارة عملية تكرارية تزايدية هو هو فرض قيد زمني. بهذا الاسلوب الحازم يتم تحديد فترة زمنية ثابتة يجب خلالها اتمام تكرارية معينة.

اذا لم تكتمل التكرارية مع نهاية القيد الزمني، فالتكرارية يتم انهاؤها على أية حال. النشاط الأهم في التقييد الزمني هو المراجعة في نهاية التكرارية. المراجعة يجب أن تبحث في أسباب التأخير، و أن تعيد جدولة الأعمال غير المنتهية و تضمينها في التكرارات القادمة.

احدى النصائح لكيفية تطبيق القيد الزمني، أن يكون المطورون هم المسؤولون (أو على الأقل الكلمة العليا) عن تحديد ما هي المتطلبات التي يتم تغطيتها في كل تكرار ، باعتبارهم الذين سوف يلتزمون بهذه الآجال.

الالتزام بالقيد الزمني يعد صعبا، فهو يتطلّب حسّا عاليا بالانضباطية خلال كامل المشروع. من المغري جدا التخلّي عن المراجعة و تخطّي القيد الزمني اذا حان أجل التكرار و كانت نسبة اكتمال"99%" . حالما يرضخ المشروع لمثل هذا الاغراء و يتم تجاهل مراجعة واحدة ، فان المفهوم بكامله يبدأ في التداعي. اذا تم تجاهل عدة مراجعات ، فان التخطيط للتكرارات القادمة سوف تكون مائعة و تبدأ الفوضى في أخذ مكانها.

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

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

بصورة اساسية، يسمح القيد الزمني للمشروع بكامله أن يتريث مرة بعد الأخرى ليحزم أمره من جديد. انه لا يعرقل امكانيات الارجاء، و يحتاج الى ادارة مشروعات قوية كي يعمل بصورة صحيحة.


التوقيتات النمطية للمشروع
كم يجب ان يستغرق كل طور من الأطوار الأربعة؟ هذا يتباين من مشروع لآخر، و لكن كمؤشّر عام 10% للإستهلال، 30% للتفصيل، 50% للبناء و 10% للإنتقال.




العملية الموّحدة من راشيونال

The Rational Unified Process
العملية الموحّدة من راشيونال (the RUP) هي المثال الأكثر شهرة للدورة الحياتية التكرارية قيد الاستعمال حاليا. تم تطوير RUP من قبل نفس "الاصدقاء الثلاثة" الذين قاموا بتطوير UML ، و لذلك فان RUP متكاملة جدا مع UML.

بصورة أساسية، تقدّر مؤسسة راشيونال بأن كل مشروع يختلف عن الآخر، و ذو احتياجات مختلفة، مثلا، بعض المشاريع لاتتطلب الا طورا قصيرا للإستهلال، بينما مشاريع ذات علاقة بأمور عسكرية فإن طور الاستهلال فيها قد يمتد لسنوات.

حتى هذه النقطة، تعد RUP مرنة و تسمح باعادة تكييف كل طور في العملية. ايضا تحدد RUP و بكل عناية قواعدا لكل فرد في المشروع و بحسب الاحتياج.

و قد اصدرت مؤسسة راشيونال منتوجا لمساعدة المشاريع التي تتبنى RUP و يمكن ايجاد المزيد من التفاصيل في [عزيزي الزائر يتوجب عليك التسجيل للمشاهدة الرابطللتسجيل اضغط هنا] . المنتوج بالأساس عبارة عن دليل على شبكة الانترنت يضم جميع ملامح RUP. و تقدم الشركة امكانية استعمالة على سبيل التجربة لمدة 30 يوما.

vcb




مصغرة بنسبة : 43% من الحجم الأصلي [ 593 x 398 ] - إضغط هنا لعرض الحجم الأصلي


شكل 8: لقطة من RUP 2000 (مؤسسة راشيونال).

تفصيل مزايا و عيوب RUP خارج نطاق درسنا هذا، و لكن بصفة عامة فان أساس RUP هي الدورة الحياتية التكرارية التزايدية و التي سيتم تبنّيها خلال دروسنا هذه,


موجز
اطار العمل التكراري التزايدي يقدم العديد من الفوائد مقارنة بالعمليات التقليدية.

اطار العمل هذا ينقسم الى أربعة أطوار الاستهلال، النفصيل، البناء، الانتقال.

التطوير التصاعدي يعني استهداف الحصول على توليف قابل للتشغيل في نهاية كل تكرار (بأكبر عدد ممكن منها).

التكرارات يمكن تقييدها زمنيا كأسلوب صارم لجدولة و مراجعة التكرارات.

بقية هذه الدروس سوف تركز على اطار العمل Framework ، و كيف تقوم UML بدعم مخرجات كل طور في اطار العمل.

(3)لاحظ أنه في أطوار الاستهلال و التفصيل، يمكن بناء مجسمات (برمجية) أولية. هذه المجسمات يمكن تطويرها تماما بنفس الطريقة ؛ أي سلسلة من التكرارات الانحدارية المصغرة. عموما و بقصد التوضيح في هذه الدروس سوف نبقي على أطوار الاستهلال و التفصيل بسيطة قدر الامكان، و نستعمل الانحداريات عند البناء فقط.