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