|
تضامنًا مع حق الشعب الفلسطيني |
تطوير تطبيقات سريع
| جزء من سلسلة مقالات حول |
| عملية تطوير البرمجيات |
|---|
 |
 بوابة برمجيات |
تطوير التطبيقات السريع (بالإنجليزية: Rapid application devolopment) اختصاراً RAD، هو منهجية تطوير البرمجيات التي تستخدم الحد الأدنى من التخطيط لصالح النماذج الأولية السريعة. إن «تخطيط» البرمجيات الذي تم تطويره بواسطة RAD يتبادل مع كتابة البرنامج نفسه. إن عدم وجود التخطيط المسبق المكثف يسمح عامة بكتابة البرمجيات بصورة أسرع بكثير كما يجعل من الأسهل تغيير المتطلبات.
نظرة عامة
التطوير السريع للتطبيق هو منهجية تطوير البرمجيات التي تتضمن أساليب مثل التطوير التكراري ووضع النماذج الأولية للبرمجيات. وفقا لويتن 2004 فهي دمج تقنيات مختلفة النظم وخاصة هندسة المعلومات التي تعتمد على البيانات مع نمذجة التقنيات لتسريع تطوير نماذج البرمجيات.[1] في التطوير السريع للتطبيق تستخدم تقنيات منظمة ونماذج خاصة لتحديد متطلبات المستخدمين ولتصميم النظام النهائي. إن عملية التطوير تبدأ بتطوير نماذج بيانات الأولية ونماذج العمليات التجارية باستخدام تقنيات منظمة. في المرحلة التالية، يتم التحقق من المتطلبات باستخدام النمذجة لتحسين البيانات ونماذج العملية في النهاية. وتتكرر هذه المراحل تكرارا، مزيد من نتائج التطوير ينتج عنها «متطلبات عمل مشتركة وبيان التصميم التكنيكي لاستخدامه في بناء نظم جديدة».[1] قد يترتب على دراسات RAD تنازلات في الوظائف والأداء في الصرف للتمكن من تطوير أسرع وتسهيل تطبيق الصيانة.
التاريخ
التطوير السريع للتطبيق هو مصطلح يستخدم في الأصل لوصف عملية تطوير البرمجيات التي قدمها جيمس مارتن في 1991. تتضمن منهجية مارتن تطويرا تكراريا وبناء النماذج.وفي الآونة الأخيرة تم استخدام المصطلح والمختصر بالمعنى العام الأوسع الذي يشمل مجموعة متنوعة من الأساليب تهدف إلى تسريع تطوير التطبيقات مثل استخدام اطار عمل برمجة بأنواع مختلفة مثل أطر تطبيق الويب. إن التطوير السريع للتطبيق كان استجابة للعمليات غير المرنة التي طورت في السبعينيات والثمانينيات مثل تحليل النظم الهيكلية ومنهج التصميم وغيرها من نماذج الشلال. مشكلة واحدة مع المنهجيات السابقة كانت أن التطبيقات استغرقت وقتا طويلا لبنائها لدرجة أن المتطلبات قد تغيرت قبل اكتمال النظام مما أدى إلى نظم غير ملائمة أو حتى غير مستخدمة. مشكلة أخرى كانت افتراض أن مرحلة تحليل المتطلبات المنهجي وحدها ستحدد جميع المتطلبات الحرجة. أدلة وافرة [بحاجة لمصدر] تشهد على حقيقة أن هذه حالة نادرة حتى بالنسبة للمشاريع التي بها مهنيين ذوي خبرة عالية في جميع المستويات. بداية من أفكار برايان جالاغر، أليكس بالشن، بارين بويهم، سكوت شالتز وجيمس مارتن التي طورت دراسة التطوير السريع للتطبيق خلال الثمانينيات في آي بي إم وجعلتها رسمية أخيرا بنشر كتاب في 1991، التطوير السريع للتطبيق.
الفعالية النسبية
إن التحول من التطوير التقليدي الذي يعتمد على الدورة المهنية للعميل/الخدمة للتطوير المفتوح الذي لا يعتمد على دورات والتعاوني مثلويب 2.0قد زاد الحاجة لتكرار أسرع من خلال مراحل SDLC.[2] هذا مع الحاجة المتزايدة للبرمجيات مفتوحة المصدر والمنتجات في أساس التطوير التجاري بالنسبة للكثير من المطورين جددت الفائدة من ايجاد الرصاصة الفضية لمنهجية RAD على الرغم من أن معظم منهجيات RAD تعزز برامج إعادة الاستخدام فإن بنية فريق صغيرة وحوسبة موزعة فإن معظم العاملين في RAD يدركون أن لا توجد منهجية أحد «سريع» في النهاية تستطيع تقديم تحسين قيمة أسية أكثر من أي منهجية تطوير أخرى. جميع أنواع RAD لديها القدرة على توفير إطار جيد لتطوير سريع للمنتج بجودة البرمجيات محسنة ولكن التنفيذ الناجح والمنافع غالبا ما تتوقف على نوع المشروع، الجدول الزمني،دورة حياة إصدار البرمجيات وثقافة الشركات. قد يكون أيضا من المهم أن بعض أكبر بائعي البرمجيات مثل مايكروسوفت[3] وآي بي إم[4] لا تستعمل RAD على نطاق واسع في تطوير منتج أساسي وبالنسبة للجزء الأكبر فهي تعتمد في المقام الأول على منهجيات الشلال التقليدية مع درجة معينة من التصاعد.[5]
يحتوي هذا الجدول على ملخص رفيع المستوى لبعض الأنواع الرئيسية من RAD ونقاط قوتها وضعفها النسبية.
| نشاط تطوير البرمجيات (Agile) | |
|---|---|
| الايجابيات | يقلل من زحف الخصائصعن طريق التطوير على مسافات قصيرة مما ينتج عنه مشاريع برمجية حاسوب مصغرة وإطلاق المنتج في زيادات صغيرة. |
| السلبيات | -قد يضيف التكرار القصير وظائف قليلة جدا مما يؤدي إلى تأخر كبير في التكرار النهائي. حيث أكد أجيل على الوقت الحقيقي للاتصالات (يفضل وجها لوجه) مستخدما الاشكالية لتطوير نظم عدد كبير من الفرق الموزعة. أساليب أجيل تنتج وثائق مكتوبة قليلة جدا وتتطلب قدرا كبيرا من وثائق ما بعد المشروع. |
| البرمجة القصوى (XP) | |
| الايجابيات | يخفض تكلفة التغييرات من خلال عن طريق اللوالب السريعة للمتطلبات الجديدة. معظم نشاط التصميم يحدث تدريجيا وأثناء الطيران. |
| السلبيات | يجب أن يعمل المبرمجون في أزواج وهي صعبة بالنسبة لبعض الناس. لا يحدث تقديم "للتصميم التفصيلي" والذي يمكن أن ينتج عنه بذل المزيد من الجهد في اعادة التصميم على المدى الطويل. العمل الرئيسي المرتبط بالمشروع كامل الوقت قد يشكل نقطة فشل للمشروع ومصدر رئيسي للتوتر للفريق. |
| تصميم الطلب الجماعي (JAD) | |
| الايجابيات | يلتقط صوت العميل من خلال إشراكهم في تصميم وتطوير التطبيق من خلال سلسلة من حلقات العمل التعاونية تسمى دورات JAD. |
| السلبيات | قد يخلق العميل رؤية غير واقعية للمنتج ويطلب طلاء زائدا بالذهب مما يؤدي بالفريق إلى تطوير وظيفي فوق أو دون المستوى. |
| تطوير البرمجيات الانسيابي (LD) (LD) | |
| الايجابيات | يخلق الحد الأدنى من الحلول (أي تحديد احتياجات التكنولوجيا)ويوفر وظائف أقل في وقت سابق بسياسة أن 80%اليوم أفضل من 100% غدا. |
| السلبيات | .قد يفقد المنتج استراتيجية التسويق بسبب عدم كفاية الوظائف الأساسية وربما يعرض جودة شاملة سيئة. |
| التطوير السريع للتطبيق (RAD) | |
| الايجابيات | يعزز مناخ التعاون القوي وديناميكية تجميع المتطلبات.يشارك صاحب العمل بفاعلية في النمذجة بكتابة حالات الاختبار وأداء وحدة الاختبار. |
| السلبيات
|
الاعتماد على فرق قوية ومتماسكة والالتزام الفردي للمشروع. صنع القرار يعتمد على المميزات الوظيفية للفريق وعملية صنع القرار الجماعي بدرجة أقل مركزية إدارة مشروعات وسلطة هندسة تطبيقية. |
| سكروم | |
| الايجابيات | تحسين الإنتاجية في فرق كانت مشلولة من قبل بعملية"ثقيلة"، القدرة على إعطاء الأولوية للعمل، استخدام المتأخرات لاكمال بنود في سلسلة من التكرارات القصيرة أو الاسراعات والقياس اليومي للتقدم والاتصالات.. |
| السلبيات | الاعتماد على تسهيلات الرئيس الذي قد يفتقر إلى المهارات السياسية لإزالة العقبات وتحقيق هدف السباق.بسبب الاعتماد على فرق التنظيم الذاتي ورفض "التحكم بالعملية" التقليدي المركزي، فإن الصراعات الداخلية على السلطة يمكن أن تشل الفريق. |
نقد
حيث أن التطوير السريع للتطبيق عملية تكرارية وتدريجية فإنه يمكن أن يؤدي إلى سلسلة من النماذج التي لن تنتهي أبدا بإنتاج تطبيق مرض. ويمكن تجنب مثل هذه الإخفاقات إذا كانت أدوات تطوير التطبيقات قوية ومرنة وموضوعة في موضع ملائم للاستخدام الصحيح. يتناول هذا في أساليب مثل طريقة التنمية 2080 أو غيرها من متغيرات ما بعد أجيل.
علاوة على ذلك، هناك ظاهرة وراء سلسلة فاشلة من النماذج الغير مرضية: المستخدمين النهائيين في المقام الأول وبكل حدسي ينظرون إلى واجهة مستخدم رسومية GUI)) كمقياس أولي لجودة البرمجيات. وكلما كانت «رؤية» شيئا يعمل أسرع كلما زادت «سرعة» رؤيتهم لدورة التطوير. وذلك لأن GUI لديها قوة طبيعية للحضور المرئي مباشرة بينما كود مشاكل البيانات الأخرى يجب أن يستخلص أو يستنتج وهذا ما لا يلاحظ إلى حد كبير.
بما أن المبرمجين عامة هم مستخدمين نهائيين للبرمجيات أولا ومبرمجين ثانيا فإن هذه الجاذبية الطبيعية نحو«الرؤية» راسخة من البداية (مثل«مرحبا أيها العالم» فهو ليس عن البيانات أو مجال العمل وإنما عن «رؤية» شيء على شاشة). إن المبرمجين بدون تدريب صريح على فهم هذه النوعية من البرامج الخادعة يميلون أيضا إلى انجذاب قياسهم نحو «السرعة» في RAD تبعا لمدى سرعة تقدم GUI. ويتعزز هذا الاتجاه من خلال حقيقة أن المستخدمين النهائيين يعقدون المكافأة المالية لسعي المبرمجين مما يقودهم لتلبية القياس العقلي للمستخدمين بجهل، أكثر من البديل المناسب والأكثر واقعية.
وبناء على ذلك، فإن العديد من أدوات تطوير البرمجيات تركز بقوة في المقام الأول على GUI أيضا. هذا الاتجاه لقياس «السرعة» من خلال GUI يتعزز من قبل المبرمجين الذين (بدورهم) يصبحون أدوات لإنتاج RAD كما أن لديهم مصلحة مالية قوية وتلبية لنموذج مجتمع تطوير البرمجيات الذي يركز على GUI. وأخيرا، باستعراض روايات أدوات RAD تكشف عن التركيز القوي على GUI حيث«مرحبا أيها العالم» والأمثلة الأخرى الكثيرة التي تركز على واجهة المستخدم الرسومية ويندر وجود البيانات أو أمثلة مشاكل مجال العمل.
وفي النهاية، فإن ثلاثي من اللاعبين (على سبيل المثال المستخدمين النهائيين، المبرمجين ومطوري الأدوات) كل مع التركيز القوي في غير محله على مجالات GUI في تطبيقات البرمجيات يؤدي إلى التقليل من التأكيد الثقافي على معظم ما نص عليه البرنامج فعليا: مجالات مشاكل البيانات والعمل. علاوة على ذلك، فإن ثقافة RAD (وفي الحقيقة البرمجيات بوجه عام) مع التأكيد المركزي على GUI تمثل مشكلة متعددة الأوجه للمهندسين الذين يدركون هذه المشكلة ويحاولون التغلب عليها وتوليد بيئة معاكسة (المستخدمين النهائيين، المطورين والأدوات). أولا، هناك نقص في التطوير السريع للتطبيق الذي يركز على نطاق المشكلة المناسب. بعد ذلك، المهندسين المدربين بطريقة مناسبة لديهم مهمة تدريب وتعليم المستخدمين النهائيين مشاهدة البيانات الغير بديهية وكود العمل كمقياس مناسب لمدى سرعة أو جودة تطوير البرنامج المنتج. وأخيرا هناك نقص في مهندسي المشروع المدركين لنطاق المشكلة في غير محله والقابلين للتدريب والقادرين على مهمة إعادة توجيه أنفسهم لوجهة نظر المواجهة غير البديهية.
الآثار العملية
عندما تعتمد المنظمات منهجية التطوير السريع، فيجب أن تتوخى الحذر لتجنب مسئولية ودور ومسئولية الارتباك وانهيار الاتصالات في فريق التطوير وبين الفريق والعميل. بالإضافة إلى ذلك، خاصة في حالة غياب العميل أو عدم قدرته على المشاركة مع السلطة في عملية التطوير، فينبغي أن يهب محلل النظام مع هذه السلطة نيابة عن العميل لضمان تحديد الأولويات المناسبة للمتطلبات غير الوظيفية. علاوة على ذلك، أي زيادة على النظام يجب تطويرها دون مرحلة تصميم دقيق وموثق رسميا.[6]
أدوات تطوير التطبيقات السريعة
إن منهج تطوير التطبيقات السريعة لا يمر وفق مراحل اصدار البرمجيات فتمثل فعاليتها في التطبيقات التي تضع تركيز أقل على التخطيط ومواصفات التصميم، وتسلم النماذج الأولية بسرعة إلى المستخدمين لضمان مشاركتهم المباشرة في التعليقات والتطوير. ومن أهم أدوات التطوير السريع للتطبيقات (RAD) التي تساعدك في البدء في عملية التطوير لأنشاء التطبيقات بسرعة وكفاءة عالية دون الحاجة إلى ميزانية كبيرة في تطوير التطبيقات والتي أكدت فعاليتها منصة تطوير التطبيقات السريعة (RAD) kissflow للمطورين في هذا المجال الآتي وهي من أفضل 5 أدوات في تطوير التطبيقات السريعة (RAD ):
- Kissflow
- Zoho Creator
- OutSystems
- Bizagi
- Appian
المراجع
- ^ أ ب Whitten, Jeffrey L.; لوني د. بنتلي, Kevin C. Dittman. (2004). Systems Analysis and Design Methods. 6th edition. ISBN 0-256-19906-X.
- ^ Maurer and S. Martel. (2002). "Extreme Programming: Rapid Development for Web-Based Applications". IEEE Internet Computing, 6(1) pp 86-91 January/February 2002.
- ^ Andrew Begel، Nachiappan Nagappan. "Usage and Perceptions of Agile Software Development in an Industrial Context: An Exploratory Study, Microsoft Research" (PDF). مؤرشف من الأصل (PDF) في 2016-05-19. اطلع عليه بتاريخ 2008-11-15.
- ^ E. M. Maximilien and L. Williams. (2003). "Assessing Test-driven Development at IBM". Proceedings of International Conference of Software Engineering, Portland, OR, pp. 564-569, 2003.
- ^ M. Stephens, Rosenberg, D. (2003). "Extreme Programming Refactored: The Case Against XP". Apress, 2003.
- ^ Gerber, Aurona; Van der Merwe, Alta; Alberts, Ronell; (2007), Implications of Rapid Development Methodologies, CSITEd 2007, Mauritius, November 2007 [1] نسخة محفوظة 4 مارس 2016 على موقع واي باك مشين.
