books rapid application development
If you do not find what you're looking for, you can use more accurate words.
تطوير تطبيقات سريع (Info)
تطوير التطبيقات السريع(RAD) هو منهجية تطوير البرمجيات التي تستخدم الحد الأدنى من التخطيط لصالح النماذج الأولية السريعة. إن "تخطيط" البرمجيات الذي تم تطويره بواسطة RAD يتبادل مع كتابة البرنامج نفسه. إن عدم وجود التخطيط المسبق المكثف يسمح عامة بكتابة البرمجيات بصورة أسرع بكثير كما يجعل من الأسهل تغيير المتطلبات.
نظرة عامة
التطوير السريع للتطبيق هو منهجية تطوير البرمجيات التي تتضمن أساليب مثل التطوير التكراري ووضع النماذج الأولية للبرمجيات. وفقا لويتن 2004 فهي دمج تقنيات مختلفة النظم وخاصة هندسة المعلومات التي تعتمد على البيانات مع نمذجة التقنيات لتسريع تطوير نماذج البرمجيات. في التطوير السريع للتطبيق تستخدم تقنيات منظمة ونماذج خاصة لتحديد متطلبات المستخدمين ولتصميم النظام النهائي. إن عملية التطوير تبدأ بتطوير نماذج بيانات الأولية ونماذج العمليات التجارية باستخدام تقنيات منظمة. في المرحلة التالية، يتم التحقق من المتطلبات باستخدام النمذجة لتحسين البيانات ونماذج العملية في النهاية. وتتكرر هذه المراحل تكرارا، مزيد من نتائج التطوير ينتج عنها "متطلبات عمل مشتركة وبيان التصميم التكنيكي لاستخدامه في بناء نظم جديدة". قد يترتب على دراسات RAD تنازلات في الوظائف والأداء في الصرف للتمكن من تطوير أسرع وتسهيل تطبيق الصيانة.
التاريخ
التطوير السريع للتطبيق هو مصطلح يستخدم في الأصل لوصف عملية تطوير البرمجيات التي قدمها جيمس مارتن في 1991. تتضمن منهجية مارتن تطويرا تكراريا وبناء النماذج.وفي الآونة الأخيرة تم استخدام المصطلح والمختصر بالمعنى العام الأوسع الذي يشمل مجموعة متنوعة من الأساليب تهدف إلى تسريع تطوير التطبيقات مثل استخدام اطار عمل برمجة بأنواع مختلفة مثل أطر تطبيق الويب. إن التطوير السريع للتطبيق كان استجابة للعمليات غير المرنة التي طورت في السبعينيات والثمانينيات مثل تحليل النظم الهيكلية ومنهج التصميم وغيرها من نماذج الشلال. مشكلة واحدة مع المنهجيات السابقة كانت أن التطبيقات استغرقت وقتا طويلا لبنائها لدرجة أن المتطلبات قد تغيرت قبل اكتمال النظام مما أدى إلى نظم غير ملائمة أو حتى غير مستخدمة. مشكلة أخرى كانت افتراض أن مرحلة تحليل المتطلبات المنهجي وحدها ستحدد جميع المتطلبات الحرجة. أدلة وافرة تشهد على حقيقة أن هذه حالة نادرة حتى بالنسبة للمشاريع التي بها مهنيين ذوي خبرة عالية في جميع المستويات. بداية من أفكار برايان جالاغر، أليكس بالشن، بارين بويهم، سكوت شالتز وجيمس مارتن التي طورت دراسة التطوير السريع للتطبيق خلال الثمانينيات في آي بي إم وجعلتها رسمية أخيرا بنشر كتاب في 1991، التطوير السريع للتطبيق.
الفعالية النسبية
إن التحول من التطوير التقليدي الذي يعتمد على الدورة المهنية للعميل/الخدمة للتطوير المفتوح الذي لا يعتمد على دورات والتعاوني مثلويب 2.0قد زاد الحاجة لتكرار أسرع من خلال مراحل SDLC. هذا مع الحاجة المتزايدة للبرمجيات مفتوحة المصدر والمنتجات في أساس التطوير التجاري بالنسبة للكثير من المطورين جددت الفائدة من ايجاد الرصاصة الفضية لمنهجية RAD على الرغم من أن معظم منهجيات RAD تعزز برامج إعادة الاستخدام فإن بنية فريق صغيرة وحوسبة موزعة فإن معظم العاملين في RAD يدركون أن لا توجد منهجية أحد "سريع" في النهاية تستطيع تقديم تحسينقيمة أسية أكثر من أي منهجية تطوير أخرى. جميع أنواع RAD لديها القدرة على توفير إطار جيد لتطوير سريع للمنتج بجودة البرمجيات محسنة ولكن التنفيذ الناجح والمنافع غالبا ما تتوقف على نوع المشروع، الجدول الزمني،دورة حياة إصدار البرمجيات وثقافة الشركات. قد يكون أيضا من المهم أن بعض أكبر بائعي البرمجيات مثل مايكروسوفت وآي بي إم لا تستعمل RAD على نطاق واسع في تطوير منتج أساسي وبالنسبة للجزء الأكبر فهي تعتمد في المقام الأول على منهجيات الشلال التقليدية مع درجة معينة من التصاعد.
يحتوي هذا الجدول على ملخص رفيع المستوى لبعض الأنواع الرئيسية من RAD ونقاط قوتها وضعفها النسبية.
نقد
حيث أن التطوير السريع للتطبيق عملية تكرارية وتدريجية فإنه يمكن أن يؤدي إلى سلسلة من النماذج التي لن تنتهي أبدا بإنتاج تطبيق مرض. ويمكن تجنب مثل هذه الإخفاقات إذا كانت أدوات تطوير التطبيقات قوية ومرنة وموضوعة في موضع ملائم للاستخدام الصحيح. يتم تناول هذا في أساليب مثل طريقة التنمية 2080 أو غيرها من متغيرات ما بعد أجيل.
علاوة على ذلك، هناك ظاهرة وراء سلسلة فاشلة من النماذج الغير مرضية: المستخدمين النهائيين في المقام الأول وبكل حدسي ينظرون إلى واجهة مستخدم رسومية GUI)) كمقياس أولي لجودة البرمجيات. وكلما كانت "رؤية" شيئا يعمل أسرع كلما زادت "سرعة" رؤيتهم لدورة التطوير. وذلك لأن GUI لديها قوة طبيعية للحضور المرئي مباشرة بينما كود مشاكل البيانات الأخرى يجب أن يستخلص أو يستنتج وهذا ما لا يلاحظ إلى حد كبير.
بما أن المبرمجين عامة هم مستخدمين نهائيين للبرمجيات أولا ومبرمجين ثانيا فإن هذه الجاذبية الطبيعية نحو"الرؤية" راسخة من البداية (مثل"مرحبا أيها العالم" فهو ليس عن البيانات أو مجال العمل وإنما عن "رؤية" شيء على شاشة). إن المبرمجين بدون تدريب صريح على فهم هذه النوعية من البرامج الخادعة يميلون أيضا إلى انجذاب قياسهم نحو "السرعة " في RAD تبعا لمدى سرعة تقدم GUI. ويتعزز هذا الاتجاه من خلال حقيقة أن المستخدمين النهائيين يعقدون المكافأة المالية لسعي المبرمجين مما يقودهم لتلبية القياس العقلي للمستخدمين بجهل، أكثر من البديل المناسب والأكثر واقعية.
وبناء على ذلك، فإن العديد من أدوات تطوير البرمجيات تركز بقوة في المقام الأول على GUI أيضا. هذا الاتجاه لقياس "السرعة" من خلال GUI يتعزز من قبل المبرمجين الذين(بدورهم) يصبحون أدوات لإنتاج RAD كما أن لديهم مصلحة مالية قوية وتلبية لنموذج مجتمع تطوير البرمجيات الذي يركز على GUI. وأخيرا، باستعراض روايات أدوات RAD تكشف عن التركيز القوي على GUI حيث"مرحبا أيها العالم" والأمثلة الأخرى الكثيرة التي تركز على واجهة المستخدم الرسومية ويندر وجود البيانات أو أمثلة مشاكل مجال العمل.
وفي النهاية، فإن ثلاثي من اللاعبين (على سبيل المثال المستخدمين النهائيين، المبرمجين ومطوري الأدوات) كل مع التركيز القوي في غير محله على مجالات GUI في تطبيقات البرمجيات يؤدي إلى التقليل من التأكيد الثقافي على معظم ما نص عليه البرنامج فعليا: مجالات مشاكل البيانات والعمل. علاوة على ذلك، فإن ثقافة RAD (وفي الحقيقة البرمجيات بوجه عام) مع التأكيد المركزي على GUI تمثل مشكلة متعددة الأوجه للمهندسين الذين يدركون هذه المشكلة ويحاولون التغلب عليها وتوليد بيئة معاكسة (المستخدمين النهائيين، المطورين والأدوات). أولا، هناك نقص في التطوير السريع للتطبيق الذي يركز على نطاق المشكلة المناسب. بعد ذلك، المهندسين المدربين بطريقة مناسبة لديهم مهمة تدريب وتعليم المستخدمين النهائيين مشاهدة البيانات الغير بديهية وكود العمل كمقياس مناسب لمدى سرعة أو جودة تطوير البرنامج المنتج. وأخيرا هناك نقص في مهنسي المشروع الفاهمين لنطاق المشكلة في غير محله والقابلين للتدريب والقادرين على مهمة إعادة توجيه أنفسهم لوجهة نظر المواجهة الغير بديهية.
الآثار العملية
عندما تعتمد المنظمات منهجية التطوير السريع، فيجب أن تتوخى الحذر لتجنب مسئولية ودور ومسئولية الارتباك وانهيار الاتصالات في فريق التطوير وبين الفريق والعميل. بالإضافة إلى ذلك، خاصة في حالة غياب العميل أو عدم قدرته على المشاركة مع السلطة في عملية التطوير، فينبغي أن يهب محلل النظام مع هذه السلطة نيابة عن العميل لضمان تحديد الأولويات المناسبة للمتطلبات الغير وظيفية. علاوة على ذلك، أي زيادة على النظام يجب تطويرها دون مرحلة تصميم دقيق وموثق رسميا.
لمزيد من القراءة
- ستيف ماكونيل (1996). Rapid Development: Taming Wild Software Schedules, Microsoft Press Books, ISBN 978-1-55615-900-8
- Kerr, James M.; Hunter, Richard (1993). Inside RAD: How to Build a Fully-Functional System in 90 Days or Less. McGraw-Hill. ISBN 0070342237. الوسيط
|CitationClass=تم تجاهله (مساعدة) - Ellen Gottesdiener (1995). "RAD Realities: Beyond the Hype to How RAD Really Works" Application Development Trends
- Ken Schwaber (1996). Agile Project Management with Scrum, Microsoft Press Books, ISBN 978-0-7356-1993-7
- ستيف ماكونيل (2003). Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers, Microsoft Prese s Books, ISBN 978-0-321-19367-4
- Dean Leffingwell (2007). Scaling Software Agility: Best Practices for Large Enterprises, Addison-Wesley Professional, ISBN 978-0-321-45819-3
قالب:Software Engineering قالب:Computer science
