تطوير تطبيقات سريع

نظرة عامة

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

التاريخ

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

نقد

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

الآثار العملية

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