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

📅 آخر تحديث: ١ أغسطس ٢٠٢٦
✍️ نُشر في: ١ أغسطس ٢٠٢٦
📷 يحتوي على 1 صور
الموسوعة الحرة

يُعدّ التطوير السريع للتطبيقات ( RAD )، والذي يُطلق عليه أيضًا بناء التطبيقات السريع ( RAB )، مصطلحًا عامًا لأساليب تطوير البرمجيات التكيفية ، وهو أيضًا اسم منهج جيمس مارتن للتطوير السريع. وبشكل عام، تُركّز أساليب RAD في تطوير البرمجيات على عملية تكيفية أكثر من التخطيط. وغالبًا ما تُستخدم النماذج الأولية بالإضافة إلى مواصفات التصميم، أو حتى بدلاً منها أحيانًا.

يُعدّ تطوير التطبيقات السريع (RAD) مناسبًا بشكل خاص (وإن لم يقتصر عليه) لتطوير البرامج التي تعتمد على متطلبات واجهة المستخدم . غالبًا ما تُسمى أدوات بناء واجهات المستخدم الرسومية بأدوات تطوير التطبيقات السريع. تشمل الأساليب الأخرى للتطوير السريع النماذج التكيفية ، والمرنة ، والحلزونية ، والموحدة .

تاريخ

كان تطوير التطبيقات السريع استجابةً لعمليات الشلال القائمة على التخطيط ، والتي طُوّرت في سبعينيات وثمانينيات القرن الماضي، مثل منهجية تحليل وتصميم الأنظمة الهيكلية (SSADM). إحدى مشكلات هذه المنهجيات أنها كانت تستند إلى نموذج هندسي تقليدي يُستخدم لتصميم وبناء أشياء مثل الجسور والمباني. البرمجيات نوع مختلف بطبيعته، إذ يمكنها تغيير العملية المستخدمة لحل المشكلة. وبالتالي، يمكن للمعرفة المكتسبة من عملية التطوير نفسها أن تُغذي متطلبات الحل وتصميمه. [ 1 ] تحاول المناهج القائمة على التخطيط تحديد المتطلبات والحل وخطة التنفيذ، ولديها عملية تُثبّط التغييرات. أما مناهج التطوير السريع للتطبيقات، فتُدرك أن تطوير البرمجيات عملية كثيفة المعرفة، وتُوفّر عمليات مرنة تُساعد على الاستفادة من المعرفة المكتسبة خلال المشروع لتحسين الحل أو تكييفه.

طُوِّر أول بديل من هذا النوع لمنهجية التطوير السريع للتطبيقات (RAD) على يد باري بوهم، وعُرف باسم النموذج الحلزوني . ركّز بوهم وغيره من مناهج التطوير السريع للتطبيقات اللاحقة على تطوير النماذج الأولية، بالإضافة إلى أو بدلاً من مواصفات التصميم الدقيقة. تميّزت النماذج الأولية بعدة مزايا مقارنةً بالمواصفات التقليدية:

  • تقليل المخاطر. يمكن للنموذج الأولي اختبار بعض أصعب أجزاء النظام المحتملة في وقت مبكر من دورة حياته . وهذا يوفر معلومات قيّمة حول جدوى التصميم، ويمنع الفريق من اتباع حلول معقدة أو تستغرق وقتًا طويلاً في التنفيذ. تُعدّ هذه الميزة، المتمثلة في اكتشاف المشكلات مبكرًا في دورة الحياة بدلًا من اكتشافها لاحقًا، ميزةً رئيسيةً لمنهجية التطوير السريع للتطبيقات (RAD). فكلما تم اكتشاف المشكلة مبكرًا، انخفضت تكلفة معالجتها.
  • يُجيد المستخدمون استخدام النظام والتفاعل معه أكثر من وضع المواصفات. في نموذج الشلال، كان من الشائع أن يُوافق المستخدم على مجموعة من المتطلبات، ثم يُدرك فجأةً عند عرض النظام المُنفذ أن التصميم يفتقر إلى بعض الميزات الأساسية أو أنه مُعقد للغاية. عمومًا، يُقدم معظم المستخدمين ملاحظات أكثر فائدة عندما يُجرّبون نموذجًا أوليًا للنظام قيد التشغيل، بدلًا من تحديد ماهية هذا النظام بشكل نظري.
  • يمكن استخدام النماذج الأولية وتطويرها لتصبح المنتج النهائي. يتمثل أحد الأساليب المستخدمة في بعض طرق التطوير السريع للتطبيقات (RAD) في بناء النظام كسلسلة من النماذج الأولية التي تتطور من الحد الأدنى من الوظائف إلى وظائف مفيدة إلى حد ما وصولاً إلى النظام النهائي المكتمل. وتتمثل ميزة هذا الأسلوب، بالإضافة إلى الميزتين السابقتين، في إمكانية حصول المستخدمين على وظائف تجارية مفيدة في وقت مبكر من العملية. [ 2 ]

انطلاقًا من أفكار باري بوهم وآخرين، طوّر جيمس مارتن منهجية التطوير السريع للتطبيقات (RAD) خلال ثمانينيات القرن الماضي في شركة IBM ، ثمّ قام بصياغتها رسميًا بنشر كتابه " التطوير السريع للتطبيقات" (Rapid Application Development ) عام ١٩٩١. وقد أدّى ذلك إلى بعض اللبس حول مصطلح RAD حتى بين متخصصي تكنولوجيا المعلومات. من المهم التمييز بين RAD كبديل عام لنموذج الشلال، وRAD كمنهجية محددة ابتكرها مارتن. صُممت منهجية مارتن خصيصًا لأنظمة الأعمال كثيفة المعرفة وواجهات المستخدم.

طُوِّرت هذه الأفكار وحُسِّنت على يد رواد منهجية التطوير السريع للتطبيقات (RAD) مثل جيمس كير وريتشارد هنتر، اللذين ألّفا معًا كتابًا مرجعيًا في هذا المجال بعنوان "داخل منهجية التطوير السريع للتطبيقات" [ 3 ] ، والذي تناول رحلة مدير مشروع RAD أثناء تطبيقه وتحسينه لمنهجية RAD في مشروع RAD فعلي. وقد ساهم هؤلاء الممارسون، ومن على شاكلتهم، في اكتساب منهجية RAD شعبيةً واسعة كبديل لأساليب دورة حياة مشاريع الأنظمة التقليدية.

تطورت منهجية التطوير السريع للتطبيقات (RAD) خلال فترة ذروة الاهتمام بإعادة هندسة العمليات التجارية . وتقوم فكرة إعادة هندسة العمليات التجارية على إعادة التفكير جذريًا في العمليات الأساسية، مثل المبيعات ودعم العملاء، مع مراعاة الإمكانيات الجديدة لتكنولوجيا المعلومات. وكانت منهجية التطوير السريع للتطبيقات (RAD) غالبًا جزءًا أساسيًا من برامج إعادة هندسة العمليات التجارية الأوسع نطاقًا. وشكّلت منهجية النماذج الأولية السريعة في منهجية التطوير السريع للتطبيقات (RAD) أداةً رئيسيةً لمساعدة المستخدمين والمحللين على التفكير الإبداعي والابتكار في الطرق التي يمكن للتكنولوجيا من خلالها إعادة ابتكار العمليات الأساسية بشكل جذري. [ 4 ] [ 5 ]

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

المشاريع الناجحة التي شملت بنك ANZ ، وLendlease ، وBHP ، وCoca-Cola Amatil ، وAlcan ، ونادي هونغ كونغ للفروسية ، وغيرها الكثير.

النجاح الذي أدى إلى قضاء كل من سكوت شولتز وجيمس مارتن بعض الوقت في أستراليا مع جون أندروود لفهم أساليب وتفاصيل سبب نجاح أستراليا بشكل غير متناسب في تنفيذ مشاريع RAD الهامة ذات الأهمية البالغة.

نهج جيمس مارتن

مراحل منهج جيمس مارتن في العلاج بالراد

يقسم منهج جيمس مارتن في تطوير البرمجيات السريعة (RAD) العملية إلى أربع مراحل متميزة:

  1. مرحلة تخطيط المتطلبات – تجمع هذه المرحلة عناصر من مرحلتي تخطيط النظام وتحليله ضمن دورة حياة تطوير الأنظمة (SDLC). يناقش المستخدمون والمديرون وموظفو تقنية المعلومات احتياجات العمل ونطاق المشروع والقيود ومتطلبات النظام ويتفقون عليها. وتنتهي هذه المرحلة عندما يتفق الفريق على القضايا الرئيسية ويحصل على موافقة الإدارة للمتابعة.
  2. مرحلة تصميم المستخدم - خلال هذه المرحلة، يتفاعل المستخدمون مع محللي النظم ويطورون نماذج أولية تمثل جميع عمليات النظام ومدخلاته ومخرجاته . تستخدم مجموعات أو مجموعات فرعية من فرق التطوير السريع للتطبيقات ( RAD) عادةً مزيجًا من تقنيات التصميم المشترك للتطبيقات (JAD) وأدوات هندسة البرمجيات بمساعدة الحاسوب (CASE) لترجمة احتياجات المستخدمين إلى نماذج عملية. تصميم المستخدم هو عملية تفاعلية مستمرة تُمكّن المستخدمين من فهم نموذج النظام وتعديله، وفي النهاية الموافقة عليه بما يلبي احتياجاتهم.
  3. مرحلة البناء – تركز على مهام تطوير البرامج والتطبيقات، على غرار دورة حياة تطوير البرمجيات (SDLC). مع ذلك، في مرحلة التطوير السريع للتطبيقات (RAD)، يستمر المستخدمون في المشاركة ويمكنهم اقتراح تغييرات أو تحسينات أثناء تطوير الشاشات أو التقارير الفعلية. وتشمل مهامها البرمجة وتطوير التطبيقات، وكتابة الأكواد ، وتكامل الوحدات، واختبار النظام .
  4. مرحلة الانتقال – تشبه المهام النهائية في مرحلة تنفيذ دورة حياة تطوير البرمجيات، بما في ذلك تحويل البيانات، والاختبار، والانتقال إلى النظام الجديد، وتدريب المستخدمين. بالمقارنة مع الطرق التقليدية، يتم ضغط العملية بأكملها. ونتيجة لذلك، يتم بناء النظام الجديد وتسليمه وتشغيله في وقت أقرب بكثير. [ 6 ]

المزايا

في بيئات تكنولوجيا المعلومات الحديثة، تُبنى العديد من الأنظمة الآن باستخدام درجة ما من منهجية التطوير السريع للتطبيقات [ 7 ] (ليس بالضرورة منهجية جيمس مارتن). بالإضافة إلى منهجية مارتن، تُستخدم المنهجيات الرشيقة وعملية التطوير الموحدة العقلانية بشكل شائع في تطوير التطبيقات السريعة.

تشمل المزايا المزعومة لتقنية RAD ما يلي:

  • جودة أفضل. من خلال تفاعل المستخدمين مع النماذج الأولية المتطورة، يمكن أن تكون وظائف الأعمال الناتجة عن مشروع التطوير السريع للتطبيقات (RAD) أعلى بكثير من تلك التي يتم تحقيقها عبر نموذج الشلال. يمكن أن يكون البرنامج أكثر سهولة في الاستخدام ، ولديه فرصة أفضل للتركيز على مشاكل الأعمال التي تهم المستخدمين النهائيين بدلاً من المشاكل التقنية التي تهم المطورين. ومع ذلك، هذا يستثني فئات أخرى مما يُعرف عادةً بالمتطلبات غير الوظيفية (المعروفة أيضًا بالقيود أو سمات الجودة)، بما في ذلك الأمان وقابلية النقل .
  • التحكم في المخاطر. على الرغم من أن معظم الأدبيات المتعلقة بتطوير البرمجيات السريع (RAD) تركز على السرعة ومشاركة المستخدم، إلا أن أحد السمات الأساسية لتطبيق RAD بشكل صحيح هو تخفيف المخاطر. من الجدير بالذكر أن بوهم وصف النموذج الحلزوني في البداية بأنه نهج قائم على المخاطر. يمكن لنهج RAD التركيز مبكرًا على عوامل الخطر الرئيسية والتكيف معها بناءً على الأدلة التجريبية التي تم جمعها في المراحل الأولى من العملية. على سبيل المثال، تعقيد تصميم النماذج الأولية لبعض أكثر أجزاء النظام تعقيدًا.
  • تم إنجاز المزيد من المشاريع في الوقت المحدد وضمن الميزانية. من خلال التركيز على تطوير الوحدات التدريجية، تقل احتمالات الإخفاقات الكارثية التي لطالما عانت منها مشاريع نموذج الشلال. في نموذج الشلال، كان من الشائع التوصل إلى استنتاج بعد ستة أشهر أو أكثر من التحليل والتطوير يتطلب إعادة نظر جذرية في النظام بأكمله. مع منهجية التطوير السريع للتطبيقات (RAD)، يمكن اكتشاف هذا النوع من المعلومات والتعامل معه في وقت مبكر من العملية. [ 2 ] [ 8 ]

العيوب

تشمل العيوب المزعومة للعلاج الإشعاعي ما يلي:

  • مخاطر اتباع نهج جديد. بالنسبة لمعظم أقسام تقنية المعلومات، كان تطبيق التطوير السريع للتطبيقات (RAD) نهجًا جديدًا يتطلب من المحترفين ذوي الخبرة إعادة النظر في أساليب عملهم. يميل البشر بطبيعتهم إلى النفور من التغيير، وأي مشروع يُنفذ باستخدام أدوات أو أساليب جديدة يكون أكثر عرضة للفشل في المرة الأولى، وذلك ببساطة بسبب حاجة الفريق إلى التعلم.
  • عدم التركيز على المتطلبات غير الوظيفية ، والتي غالباً ما تكون غير مرئية للمستخدم النهائي في التشغيل العادي. [ 9 ]
  • يتطلب ذلك وقتًا وموارد شحيحة. من السمات المشتركة بين جميع مناهج التطوير السريع للتطبيقات (RAD) تقريبًا، التفاعل المكثف بين المستخدمين والمطورين طوال دورة حياة المشروع. في نموذج الشلال، يحدد المستخدمون المتطلبات ثم ينسحبون في الغالب مع قيام المطورين بإنشاء النظام. أما في RAD، فيشارك المستخدمون منذ البداية وطوال المشروع تقريبًا. وهذا يتطلب استعداد المؤسسة لاستثمار وقت خبراء مجال التطبيق. المفارقة هي أنه كلما كان الخبير أكثر كفاءة، وأكثر إلمامًا بمجاله، زادت الحاجة إليه لإدارة العمل، وقد يصعب إقناع رؤسائه باستثمار وقتهم. بدون هذه الالتزامات، لن تنجح مشاريع RAD.
  • تقليل التحكم. من مزايا منهجية التطوير السريع للتطبيقات (RAD) أنها توفر عملية مرنة وقابلة للتكيف. والهدف الأمثل هو القدرة على التكيف السريع مع المشكلات والفرص على حد سواء. ثمة مفاضلة حتمية بين المرونة والتحكم، فزيادة أحدهما تعني نقصان الآخر. إذا كان مشروع ما (مثل برنامج بالغ الأهمية ) يُعطي الأولوية للتحكم على حساب المرونة، فإن منهجية التطوير السريع للتطبيقات (RAD) غير مناسبة.
  • تصميم رديء. قد يُبالغ في التركيز على النماذج الأولية في بعض الحالات، مما يؤدي إلى منهجية "التجربة والخطأ" حيث يُجري المطورون باستمرار تغييرات طفيفة على المكونات الفردية ويتجاهلون مشكلات بنية النظام التي قد تُسفر عن تصميم أفضل بشكل عام. وقد يُشكل هذا مشكلة خاصة بالنسبة لمنهجيات مثل منهجية مارتن التي تُركز بشكل كبير على واجهة المستخدم للنظام. [ 10 ]
  • يُعاني منهج التطوير السريع للتطبيقات (RAD) من نقص قابلية التوسع، حيث يركز عادةً على فرق المشاريع الصغيرة والمتوسطة الحجم. وتُشكل المشكلات الأخرى المذكورة أعلاه (قلة التصميم والتحكم) تحديات خاصة عند استخدام هذا المنهج مع الأنظمة واسعة النطاق. [ 11 ] [ 12 ] [ 13 ]

انظر أيضاً

مفاهيم عملية لتطبيق منهجية التطوير السريع للتطبيقات (RAD):

مفاهيم أخرى مشابهة:

مراجع

  1. ↑ بروكس، فريد (1986). كوجلر، إتش جيه (محرر). لا يوجد حل سحري: جوهر وحوادث هندسة البرمجيات (ملف PDF) . معالجة المعلومات 86. دار نشر إلسيفير للعلوم (شمال هولندا). رقم ISBN 0-444-70077-3تم الاطلاع عليه بتاريخ 2 يوليو 2014 .
  2. 1 2 بوهم، باري (مايو 1988). "نموذج حلزوني لتطوير البرمجيات" (ملف PDF) . مجلة IEEE Computer . doi : 10.1109/2.59 . S2CID 1781829. مؤرشف من الأصل (ملف PDF) في 29 مارس 2018. تم الاطلاع عليه في 1 يوليو 2014 . 
  3. ↑ كير، جيمس م.؛ هنتر، ريتشارد (1993). داخل RAD: كيفية بناء نظام كامل الوظائف في 90 يومًا أو أقل. ماكجرو هيل. ISBN 0-07-034223-7.
  4. ↑ دراكر، بيتر (3 نوفمبر 2009). مجتمع ما بعد الرأسمالية . كتب هاربر كولينز الإلكترونية. ISBN 978-0887306204.
  5. ↑ مارتن، جيمس (1991). التطوير السريع للتطبيقات . ماكميلان. ISBN 0-02-376775-8.
  6. ↑ مارتن، جيمس (1991). التطوير السريع للتطبيقات . ماكميلان. الصفحات 81-90 . ISBN  0-02-376775-8.
  7. ↑ "تفكك التنمية العمرانية: إعادة بنائها" (ملف PDF) . gartner.com.br. مؤرشف من الأصل (ملف PDF) بتاريخ 14 يوليو 2014. تم الاطلاع عليه بتاريخ 13 أبريل 2010 .
  8. ↑ بيك، كينت (2000). شرح البرمجة المتطرفة . أديسون ويسلي. الصفحات 3-7 . ISBN  0201616416.
  9. ↑ فريد، وئام م. (2012). "منهجية نورماب: هندسة مبسطة للمتطلبات غير الوظيفية للعمليات الرشيقة". المؤتمر التاسع عشر لهندسة البرمجيات في آسيا والمحيط الهادئ 2012. المجلد 1. الصفحات 322-325 . Bibcode : 2012apse....1...55F . doi : 10.1109/APSEC.2012.23 . ISBN   978-1-4673-4930-7.
  10. ↑ جيربر، أورونا؛ فان دير ميروي، ألتا؛ ألبرتس، رونيل (16-18 نوفمبر 2007). "الآثار العملية لمنهجيات التطوير السريع". وقائع مؤتمر تعليم علوم الحاسوب وتكنولوجيا المعلومات، CSITEd-2007 . مؤتمر تعليم علوم الحاسوب وتكنولوجيا المعلومات . موريشيوس. ص 233-245 . CiteSeerX 10.1.1.100.645 . ISBN   978-99903-87-47-6.
  11. ↑ أندرو بيجل، ناتشيبان ناجابان (سبتمبر 2007). "استخدامات وتصورات تطوير البرمجيات الرشيقة في سياق صناعي: دراسة استكشافية" (ملف PDF) . الندوة الدولية الأولى حول هندسة البرمجيات التجريبية والقياس (ESEM 2007) . الصفحات 255-264 . doi : 10.1109/esem.2007.12 . ISBN  978-0-7695-2886-1. S2CID 1941370 . 
  12. ↑ ماكسيميليان، إي إم؛ ويليامز، إل. (2003). "تقييم تطوير البرمجيات الموجه بالاختبار في شركة آي بي إم". المؤتمر الدولي الخامس والعشرون لهندسة البرمجيات، 2003. وقائع المؤتمر . الصفحات 564-569 . doi : 10.1109/icse.2003.1201238 . ISBN  0-7695-1877-X. S2CID 16919353 . 
  13. ↑ ستيفنز، مات؛ روزنبرغ، دوغ (2003). إعادة هيكلة البرمجة المتطرفة: الحجة ضد البرمجة المتطرفة . doi : 10.1007/978-1-4302-0810-5 . ISBN 978-1-59059-096-6. S2CID 29042153 . 

للمزيد من القراءة

  • ستيف ماكونيل (1996). التطوير السريع: ترويض جداول البرمجيات الجامحة ، منشورات مايكروسوفت برس، رقم ISBN 978-1-55615-900-8
  • كير، جيمس م.؛ هنتر، ريتشارد (1993). داخل منهج RAD: كيفية بناء نظام كامل الوظائف في 90 يومًا أو أقل . ماكجرو هيل. ISBN 0-07-034223-7.
  • إيلين غوتسدينر (1995). " حقائق التطوير السريع للتطبيقات: ما وراء الضجة الإعلامية إلى كيفية عمل التطوير السريع للتطبيقات فعليًا " اتجاهات تطوير التطبيقات
  • كين شوابر (1996). إدارة المشاريع الرشيقة باستخدام سكروم ، منشورات مايكروسوفت برس، رقم ISBN 978-0-7356-1993-7
  • ستيف ماكونيل (2003). تطوير البرمجيات الاحترافي: جداول زمنية أقصر، منتجات ذات جودة أعلى، مشاريع أكثر نجاحًا، مسارات مهنية مُحسّنة ، أديسون-ويسلي، رقم ISBN 978-0-321-19367-4
  • دين ليفينغويل (2007). توسيع نطاق مرونة البرمجيات: أفضل الممارسات للمؤسسات الكبيرة ، أديسون-ويسلي بروفيشنال، رقم ISBN 978-0-321-45819-3
  • سكوت ستاينر (2016). قائمة فوربس: "التطوير السريع للتطبيقات (RAD): عملية ذكية وسريعة وقيمة لمطوري البرامج"