نمذجة الأعمال (business) : ينمذج تدفق المعلومات بين وظائف الأعمال بطريقة تجيب عن الأسئلة التالية: ما المعلومات التي تقود (تسير) عملية برمجة الأعمال؟ ما المعلومات التي يجري توليدها؟ من الذي يولدها؟ أين تذهب المعلومات؟ من يعالجها؟
نمذجة البيانات : نلخص أولا تدفق المعلومات، الذي عرف انه جزء من مرحلة نمذجة الأعمال وتدفقه، في مجموعة من أهداف البيانات اللازمة لدعم الأعمال ثم نحدد المميزات (تسمى سمات، attributes) لكل هدف ويتم تعريف العلاقات بين هذه الأهداف.
نمذجة عملية البرمجة : تحول أهداف البيانات، التي تم تعريفها في مرحلة نمذجة البيانات لتحقيق تدفق المعلومات الضروري، اللازمة بدورها لتحقيق وظيفة الأعمال، ثم نعمل على توليد سمات معالجة لكل عملية من عمليات إضافة أو تعديل أو حذف أو استرجاع أهداف البيانات.
توليد التطبيق: يفترض التطوير السريع للبرنامج RAD استخدم تكنولوجيات الجيل الرابع 4GT (Fourth Generation Technology) . فبدلا من إيجاد برمجيات باستخدام لغات برمجة تقليدية من الجيل الثالث، تعمل عملية التطوير السريع للبرنامج RAD على إعادة استخدام مكونات البرنامج الموجودة(عندما يكون ممكنا)أو إنشاء مكونات قابلة لإعادة الاستخدام (عند الضرورة) وتستخدم الأدوات المؤتمتة في كل الأحوال لتسهيل بناء البرنامج.
الاختبار والتطوير( Turnover ) : لما كان التطوير السريع للبرنامج RAD يشدد على إعادة الاستخدام، سيكون قد سبق وتم اختبار العديد من مكونات البرنامج، وهذا ما يقلل من زمن الاختبار الكلي ومع ذلك يجب اختبار المكونات الجديدة وتجربة كل الواجهات تجريبا كاملا.
[ندعوك للتسجيل في المنتدى أو التعريف بنفسك لمعاينة هذا الرابط]إن نموذج عملية البرمجة RADالموضح في الشكل السابق يوضح إن التقييد الزمني المفروض على مشروع RAD يتطلب أفقا قابلا للتحجيم [KER94] (scalable scope) .فإذا أمكن تقسيم تطبيق الأعمال بحيث نستطيع انجاز كل وظيفة رئيسة في اقل من ثلاثة أشهر (باستخدام المنهج الموصوف سابقا) يكون هذا التطبيق مرشحا جيدا لـ RAD ، يمكن تناول كل وظيفة رئيسة بواسطة فريق RAD مستقل، ثم تتكامل لتشكل كيانا واحداً.
الأسلوب RAD ككل نماذج عملية البرمجة له بعض المساوئ [BUT94]:
• يتطلب RAD في حالة المشاريع الكبيرة القابلة للتحجيم موارد بشرية كافية لإنشاء العدد المطلوب من الفرق RAD ,
• يتطلب RAD مطورين وزبائن ملتزمين بالنشاطات السريعة والمتلاحقة الضرورية لإتمام النظام في زمن مختصر جدا، فإذا فقد الالتزام من احد الطرفين، ستخفق مشاريع RAD.
ليست كل أنماط التطبيقات مناسبة لاستعمال RAD فان لم يكن ممكنا تقسيم النظام بشكل مناسب ستبرز مشاكل عند بناء المكونات الضرورية لـ RAD ، وكذلك إذا كان الأداء العالي هو احد المتطلبات وكان علينا تحقيقه بتوليف الواجهات مع مكونات النظام، فقد لا يعمل الأسلوب RAD من جهة أخرى، RAD غير مناسب أيضا عندما تكون المخاطر التقنية عالية، ويحدث هذا عندما يستخدم تطبيق جديد تكنولوجيا جديدة استخداما كثيفا أو عندما تتطلب البرمجيات الجديدة درجة عالية من التشغيلية البينية ( interoperability أو قابلية العمل المتبادل) لبرامج الكمبيوتر.
يركز نموذج التطوير السريع للبرنامج RAD على إيجاد مكونات برامج قابلة لإعادة استخدام فإعادة الاستخدام هي حجر الزاوية للتكنولوجيات الغرضية وسنصادف مبدأ إعادة الاستخدام أيضا في نموذج عملية تجميع المكونات.
5. النماذج التطورية لعملية البرمجة :
هناك اعتراف متزايد إن البرمجيات، مثل جميع الأنظمة المعقدة، تتطور على مر الزمن [GII88] إذ تتغير غالبا متطلبات الأعمال والمنتج مع تقدم عملية تطوير هذا المنتج، وهذا ما يجعل المسار المستقيم باتجاه إنتاجه غير واقع، يضاف إلى ذلك إن المواعيد المقيدة لطرح المنتج في السوق تجعل إكمال منتج برمجي شامل شيئا مستحيلا، ولكن عندما نرغب بتقديم نسخة محدودة لمواجهة المنافسة أو ضغط العمل نجد هذا النموذج جيدا شرط أن تكون نواة المنتج أو متطلبات النظام مفهومة جدا، ولو لم تعرف بعد توسيع المنتج أو النظام، يحتاج مهندسو البرمجيات في هذه الحالات وفي حالات أخرى مشابهة إلى نموذج لعملية البرمجة صمم بوضوح (بالتفصيل) لاستيعاب منتج يتطور مع الزمن.
لقد صمم النموذج ألتتابعي الخطي لحالات التطوير المباشر (خط مستقيم) وبمعنى آخر، تفترض هذه الطريقة الشلالية انه سيتم تسليم كامل النظام بعد اكتمال هذا التتابع الخطي، ومن جهة أخرى فقد صمم النموذج الأولي لمساعدة الزبون أو (المطور) على فهم المتطلبات، ولم يصمم عموما لتسليم نظام نهائي. لم تلاحظ الطبيعة التطورية للبرمجيات في كلا هذين النموذجين الاتباعيين (التقليديين) لهندسة البرمجيات.
إن النماذج التطورية (Evolutionary models) تكرارية، وتوصف بطريقة تمكن مهندس البرمجيات من تطوير نسخ أكثر تعقيدا من البرمجيات، وسنذكر فيما يلي ثلاثة منها.
5-1 . النموذج ألتزايدي :
يجمع النموذج ألتزايدي (incremental mode) عناصر من النموذج ألتتابعي الخطي (مطبقة بصورة متكررة) مع الفلسفة التكرارية. وعليه يقوم النموذج ألتزايدي (كما في الشكل اللاحق) بتطبيق تتابعات خطية بأسلوب متعاقب مع تقدم زمن الإنتاج (الجداول الزمنية للإنتاج) وينتج كل تتابع خطي تزايدا من البرنامج يمكن تسليمه للزبون [MCDE94] فمثلا قد تقدم برمجيات معالجة النصوص المطورة باستخدام النموذج ألتزايدي إدارة أساسية للملفات والتحرير ووظائف إنتاج الوثائق في التزايد الأول، وتقدم إمكانيات أكثر تطورا (تعقيدا وتقدما) كتحرير وإنتاج وثائق في التزايد الثاني، وتقدم التصحيح الإملائي والقواعد في التزايد الثالث، وتقدم إمكانات متقدمة لضبط تنسيق الصفحة (page layout) في التزايد الرابع، ومن الجدير بالذكر انه يمكن استخدام نموذج النمذجة الأولية في سير عملية البرمجة في أي تزايد.
يكون التزايد الأول عادة عبارة عن نواة منتج (core product) عند استخدام النموذج ألتزايدي، أي انه يتم تحديد المتطلبات الأساسية، ولكن تبقى مظاهر إضافية عديدة غير محققة (بعضها معروف والآخر غير معروف). يستعمل المستخدم نواة المنتج (أو تخضع هذه النواة لمراجعة تفصيلية)، ويجري نتيجة للاستخدام و/أو للتقييم تطوير خطة التزايد التالي، وتحدد الخطة تعديلات نواة المنتج لتلبية حاجات الزبون بشكل أفضل وتقديم مزايا ووظائف إضافية، وتتكرر هذه العملية بعد تسليم كل تزايد حتى يتم إنتاج كامل النظام.
[ندعوك للتسجيل في المنتدى أو التعريف بنفسك لمعاينة هذا الرابط]إن نموذج عملية البرمجة ألتزايدي هو تكراري بطبيعته مثل النمذجة الأولية وجميع الأساليب التطورية، ولكنه بخلاف النمذجة الأولية يحرص على تقدم منتج عامل في كل تزايد، تكون التزايدات الأولى "نسخا ممسوخة" عن المنتج النهائي، ولكنها تستطيع تقديم إمكانيات تفيد المستخدم وتقدم أيضا منصة (platform) ليقيمها.
إن التطوير ألتزايدي مفيد، خاصة عند عدم توفر فريق كاف من الموظفين لانجاز الأعمال في الموعد النهائي الذي تم تحديده للمشروع يمكن انجاز التزايدات الأولية بعدد قليل من العاملين، وإذا جرى تقبل النواة المنتج باستحسان، يمكن عندئذ إضافة موظفين جدد (إذا كان ذلك ضروريا) لانجاز التزايد التالي.
بالإضافة إلى ذلك يمكن وضع خطة للتزايدات من اجل إدارة المخاطر التقنية مثلا، قد يتطلب نظام رئيسي توفر عتاد جديد ما يزال قيد التطوير، وتاريخ تسليمه غير مؤكد قد يكون ممكنا تخطيط التزايدات الأولى بطريقة يمكن فيها تجنب استخدام هذا العتاد، وبالتالي يمكن تقدم وظائف جزئية للمستخدم دون تأخير.
5-2 . النموذج الحلزوني:
النموذج الحلزوني (spiral mode) الذي اقترحه أولا [BOE88] Boehm هو نموذج تطوري لعملية البرمجة، ويقرن الطبيعة التكرارية للنمذجة الأولية بالنواحي النظامية والمحكومة للنموذج ألتتابعي الخطي، ويقدم إمكانية تطوير سريع لنسخ تزايدية من البرنامج، يتم تطوير البرنامج حسب النموذج الحلزوني في سلسلة من الإصدارات التزايدية، وقد يكون الإصدار ألتزايدي خلال التكرار الأولي نموذجا ورقياً أو نموذجاً أولياً، ويجري إنتاج نسخ أكثر اكتمالا من النظام الذي تمت هندسته خلال التكرارات التالية.
ينقسم النموذج الحلزوني إلى عدد من نشاطات الهيكل (framework activities) تسمى أيضا منطقة المهمة (task region) ( ) ، هناك عادة ما بين ثلاث إلى ست مناطق يمثل الشكل الاحق نموذجا حلزونيا يحتوي على ست مناطق هي :
• الاتصال بالزبون – المهام اللازمة للتواصل الفعال بين المطور والزبون .
• التخطيط – المهام اللازمة لتعريف الموارد، المسارات الزمنية (Timelines)، معلومات أخرى متعلقة بالمشروع.
• تحليل المخاطرة – المهام اللازمة لتقييم المخاطرة التقنية.
• الهندسة – المهام اللازمة لبناء تمثيل أو أكثر للتطبيق.
• التشييد والإصدار (construction & release) – المهام اللازمة لبناء واختبار وتثبيت وتقديم دعم للمستخدم (كالتوثيق والتدريب).
• تقييم الزبون (customer evaluation) – المهام اللازمة للحصول على تعليقات الراجعة بالاعتماد على تقييم تمثيلات البرمجية التي انشات خلال مرحلة الهندسة وتم انجازها خلال مرحلة التثبيت.
كل منطقة من هذه المناطق الستة مأهولة بسلاسل من مهام العمل التي جرى تكييفها مع خصائص المشروع الذي يجري تنفيذه، يكون عدد مهام العمل الرسمية المتعلقة بها منخفضا في حالة المشاريع الصغيرة، إما في المشاريع الكبيرة ذات الحساسية الأعلى، فتحتوي كل منطقة على مهام عمل أكثر، يجري تعريفها لتحقيق مستوى أعلى من الرسمية، وتطبق في جميع الحالات نشاطات المظلة(مثل إدارة تشكيلة البرمجيات وضمان جودة البرمجيات) .
حالما تبدأ عملية البرمجة التطورية، يتحرك فريق هندسة البرمجيات حول الحلزون باتجاه عقارب الساعة بدءاً من النواة قد ينتج عن الدورة الأولى حول الحلزون تطوير مواصفات المنتج، وقد تستعمل الدورات التالية حول الحلزون لتطوير نموذج أولي، ثم شيئاً فشيئاً تعد نسخ من البرنامج أكثر تطورا ينتج عن كل مرور عبر منطقة التخطيط ضبط لخطة المشروع، ويجري ضبط الكلفة والجدول الزمني بالاعتماد على تعليقات الزبون إضافة إلى ذلك يضبط مدير المشروع عدد التزايدات المخطط لها والمطلوبة لانجاز البرنامج.
خلافا للنماذج التقليدية لعملية البرمجة التي تنتهي عند تسليم البرنامج، يمكن تكييف النموذج الحلزوني لتطبيقه على امتداد كامل حياة البرنامج، يعرف الشكل أعلاه محور نقطة دخول المشروع (point project entry) يمثل كل مكعب يوضع على هذا المحور نقطة البداية لمشروع جديد آخر.
يبدأ مشروع تطوير المفاهيم (concept development project) في نواة الحلزون ويستمر (تحدث تزايدات متعددة على مسار الحلزون الذي يحيط بالمنطقة المظللة المركزية) حتى يكتمل تطوير المفهوم ، تتقدم عملية البرمجة عبر المكعب التالي (نقطة دخول المشروع تطوير منتج جديد) إذا كان المطلوب تطوير المفهوم ليصبح منتجا حقيقيا وتوضع في بداية لتطوير مشروع جديد، يتطور المنتج الجديد في عدد من التزايدات حول الحلزون متبعا المسار الذي يحيط بالمنطقة التي لها تظليل اخف من تظليل النواة، ويحدث تدفق مشابه لعملية برمجة أنواع أخرى من المشاريع .
في الحقيقة، يبقى الحلزون عند تعريفه بهذه الطريقة يعمل حتى نهاية عمر البرنامج (وضعه خارج الخدمة)، هناك أوقات تكون عملية البرمجة فيها نائمة، ولكن حالما يحدث تغيير ما، تبدأ عملية البرمجة عند نقطة بداية مناسبة (مثل تحسين المنتج).
إن النموذج الحلزوني طريقة واقعية لتطوير أنظمة وبرمجيات واسعة النطاق، ولان البرمجيات تتطور مع تقدم عملية البرمجة، فانه من الأفضل للمطور والزبون فهم المخاطر والقيام بالإجراء المناسب لها في كل مستوى من مستويات التطور، يستخدم النموذج الحلزوني النمذجة الأولية كآلية لتقليل المخاطر، ولكن الأهم من ذلك هو انه يمكن المطور من تطبيق نموذج النمذجة الأولية في أي مرحلة من مراحل تطور المنتج فهو يحافظ على الطريقة التدريجية النظامية التي تقترحها دورة الحياة التقليدية، ولكن يطبقها بإطار تكراري يعكس واقع العالم الحقيقي ويتطلب النموذج الحلزوني اعتباراً مباشراً للمخاطر التقنية في جميع مراحل المشروع، وإذا طبق بالوجه المناسب، وجب أن يقلل المخاطر قبل أن تصبح مشكلة يصعب حلها.
بيد إن النموذج الحلزوني ككل الطرق الأخرى ليس دواءً عاماً، إذ يصعب إقناع الزبون (وخاصة في حالات توقيع عقود) بأنه يمكن التحكم بالطريقة التطورية، ثم إن هذا النموذج يتطلب خبرة جيدة في تقدير المخاطرة، ويعتمد على هذه الخبرة في نجاحه، فإذا لم يكشف وجود مخاطرة رئيسة ولم تعالج، فان المشاكل ستقع دون شك. وأخيراً النموذج بحد ذاته جديد نسبياً ولم يستخدم على نطاق واسع بعد كالنموذج ألتتابعي الخطي أو نموذج النمذجة الأولية، وسيستغرق تحديد فعالية هذا النموذج الجديد الهام بثقة مطلقة عددا من السنوات.
