المعلوماتية > برمجيات
نموذج تطوير التطبيقات السريع RAD
ما هو نموذج تطوير التطبيقات السريع RAD؟
هو أحد مفاهيم تطوير البرمجيات المتزايد (Incremental)، تم تطويره عام 1980 من قبل James Martin.
يعتمدُ هذا النموذج على مجموعةٍ من دوراتِ تطوير البرمجيات التكرارية قصيرة الزمن، ويُعتبر RAD حلاً للنماذج البطيئة التقليدية مثل Waterfall، حيث أنه عالي السرعة و باستخدامه فإنّ مدة تطوير البرمجيات لا تتجاوز 2-3 أشهر.
يركّز نموذج تطوير التطبيقات السريع على جمع متطلّبات الزبائن بشكلٍ دقيق من خلال مجموعةٍ من الخبراء، والسماحِ للزبائن بالقيام بعملية الاختبار Testing في وقتٍ مبكّر، وذلك عن طريق استخدام مفهوم التكرار Iteration؛ حيث يتمّ توزيعُ الوحدات الوظيفيّة للمشروع أو المنتج ويتمُّ العملُ على كلٍّ منها بشكلٍ متوازٍ، ثم يتم دمج هذه الوحدات ليشكلوا المنتجَ بأكمله، مما يزيد في سرعة التسليم.
كما يعتمدُ على منهج Components-based أو المكونات البرمجية والنماذج القائمة ،Prototypes وكلُّ مكوِّنٍ هو عبارةٌ عن نموذجِ عملٍ تم بناؤه مُسبقاً، ويُعادل وظيفياً أحدَ مكونات المشروع المطلوب. فيتمُّ إعادة استعماله مما يساعد في التكامل والتسليم السريع.
الجانبُ الأكثرُ أهميةً لنجاحِ RAD هو التأكد أنّ المكوناتِ والمكتباتِ البرمجيةِ الجديدةِ التي يتم تطويرها، قابلةٌ لإعادة الاستخدام في مشاريعَ أُخرى.
يتم تلخيصُ المفاهيمِ القائمُ عليها نموذجُ RAD بالـ ICU
I: Iterative Development
C: Construction of Prototypes
U: Use of Computer-aided software engineering (CASE) tools
CASE tool: هي أداةٌ أو برنامجٌ يُساعد في جانبٍ واحدٍ من جوانب مراحل حياة تطوير البرمجيات، حيث يُصنف إلى صنفين:
Upper Case tool (front-end tool)
وهي البرامج التي تساعد في المراحل الأولى من مراحل التطوير مثل مرحلة جمع المتطلبات (requirements).
Lower Case tool (back-end tool)
وهي البرامج التي تساعد في المراحل الأخيرة من مراحل التطوير مثل مرحلة تنفيذ Implementation.
في RAD، عادةً ما يتألف فريق العمل من فِرَقٍ صغيرةٍ من المطورين وخبراءِ المجال، كلٌّ منها مسؤولٌ عن مكوِّنٍ معينٍ وممثلينَ عن الزبائن، ومجموعةٍ أخرى من الموارد التقنية.
متى يُستعمل RAD؟
يتم استخدام نموذج RAD لمشاريعَ ذاتِ بنيويةٍ واضحةٍ مفهومةٍ وقابلةٍ للتقسيم إلى عدة أجزاء. فيما يلي بعض الأمثلة النموذجية التي يمكن استخدام RAD معها:
- يجب استخدام RAD عندما يكون النظام قابلاً للتقسيم إلى عدة أجزاء وللتسليم بشكلٍ تدريجي Incremental.
- في حال وجود إمكانيةٍ عاليةٍ للمصممين القادرين على وضع النماذج.
- في حال وجود ميزانيةٍ تسمح باستخدام الأدوات المساعِدة مثلَ أدواتِ توليد الأكواد أو السطور البرمجية.
- تواجد عدد من المطورين ومهندسي البرمجيات ذوي الخبرة في المجال، مع معرفةٍ مرتبطةٍ بالأعمال التجارية.
- في حال كانت المتطلبات غيرَ ثابتةٍ أو قد تتغير خلال عملية التطوير، لذلك يجب إبقاء الزبون أو المستخدم على معرفةٍ بآخر التطورات من خلال تقديم نماذجِ العمل كلَّ شهرين أو ثلاثة أشهر.
ما هي مراحل RAD؟
1. جمع تخطيط ودراسة المتطلبات Requirements Planning:
تجمعُ هذه المرحلة بين مراحل دراسة النظام وتحليله في دورة حياة تطوير البرمجيات SDLC. يجتمع كلٌّ من المستخدمين والمدراء والتقنيين للمناقشةِ والاتفاق على احتياجات العمل ونطاق المشروع والقيود ومتطلبات النظام. تنتهي هذه المرحلة عندما يتّفقُ الفريق على جميع هذه النقاط.
2. تصميم المستخدمين أو الزبائن User Design:
أثناء هذه المرحلة يجتمع المستخدمون مع محللي النظم لتطوير النماذج prototypes التي تمثل جميع النقاط الوظيفية للنظام والمُدخلات والمُخرجات. ثم يستخدم أعضاء كلِّ فريق مجموعةً من أدوات المساعدة CASE وتقنيات JAD (Joint Application Development)، وهي عبارة عن منهجيةِ تطويرٍ تعتمدُ على التفاعل المستمر مع المستخدمين في جميع مراحل التطوير وذلك لترجمة احتياجات المستخدمين إلى نماذج عمل.
تُعتبر هذه المرحلة تفاعليةً ومستمرةً مع المستخدم فتسمح له فهمَ وتعديلَ وموافقةً على جميع نقاط نماذج العمل التي تلبي احتياجاته.
3. مرحلة البناء Construction:
تركّز هذه المرحلة على تنفيذِ مهام تطوير النظام Implementation ضمنَ الوقت المحدد لكل مهمة. وفي هذه المرحلة أيضاً يستمرُّ المستخدم في المشاركة وإعطاء الملاحظات والتعديلات.
4. مرحلة الاختبار والتسليم Cutover:
يتم في هذه المرحلة الانتهاءً من المهام الأخيرة مثل الاختبار Testing وتنصيب النظام وتدريب المستخدمين.
بالمقارنة مع باقي النماذج التقليدية نلاحظ أنّه باستخدام RAD يتم ضغط العملية بأكملها فينتُجُ في وقتٍ أقل، نظامٌ كاملٌ جديدٌ جاهزٌ للتسليم وللاستخدام.
ما هي إيجابيات و سلبيات RAD؟
الإيجابيات:
- استيعاب التغيرات التي قد تحدث في المتطلبات.
- إمكانية تتبع تطور العمل وتقدمه.
- قد يكون الوقت اللازم لكلِّ دورةٍ تكراريةٍ قصيراً جداً في حالِ تم استخدام أدواتٍ مساعدةٍ جيدة.
- إنجاز العمل مع عددٍ أقل من الأشخاص وفي وقت قصير.
- تخفيض الوقت اللازم للتطوير.
- زاد من إعادة استخدام المكونات الموجودة والاستفادة منها.
- تلقّي الملاحظات عن العمل من الزبون بشكل مستمر.
- التكامل المتواجد من بداية العمل يحلُّ العديدَ من المشاكل التي قد تظهر خلال سير العمل.
السلبيات:
- الاعتماد على أعضاء فريق ذوي خبرةٍ عالية في النواحي التقنية لتحديد متطلبات العمل.
- يتم استخدامه فقط على الأنظمة القابلة للتقسيم والنمذجة.
- يتطلب مبرمجين ومصممين ذوي كفاءةٍ عالية وقادرينَ على إنجاز المهام بشكلٍ سريعْ وضمن الوقت المحدد.
- غيرُ مناسبٍ في حالِ وجودِ مخاطرَ تقنيةٍ عالية، ويحدث هذا في حال كان المشروع المراد تطويره يعتمد على الاستخدام المكثف للتقنيات الجديدة.
- يتطلب ميزانيةً للأدوات المساعدة.
- أصبحت عملية إدارة سير العمل أكثر تعقيداً.
- يتطلبُ إشراكَ المستخدمين خلال كلِّ دورةِ حياةِ تطوير.
المصادر:
Software Engineering by McGraw-Hill - 5th Edition - ISBN 0073655783
Systems Analysis and Design، 8th Edition - ISBN: 0-324-59766-5