تطور البرمجيات

📅 آخر تحديث: ١٩ يوليو ٢٠٢٦
✍️ نُشر في: ١٩ يوليو ٢٠٢٦
الموسوعة الحرة

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

مقدمة عامة

يذكر فريد بروكس في كتابه الرئيسي The Mythical Man-Month [ 1 ] أن أكثر من 90 ٪ من تكاليف النظام النموذجي تنشأ في مرحلة الصيانة، وأن أي برنامج ناجح سيتم صيانته حتماً.

في الواقع، تنبع أساليب Agile من أنشطة تشبه الصيانة في وحول التقنيات القائمة على الويب، حيث تأتي غالبية القدرة من الأطر والمعايير.

تعالج صيانة البرامج إصلاح الأخطاء والتحسينات الطفيفة، بينما يركز تطوير البرامج على التكيف والهجرة .

ستستمر تقنيات البرمجيات في التطور. وستتطلب هذه التغييرات وضع قوانين ونظريات جديدة وتبريرها. كما ستتطلب بعض النماذج جوانب إضافية في تطوير البرامج المستقبلية. وتؤدي الابتكارات والتحسينات إلى ظهور أشكال غير متوقعة لتطوير البرمجيات. ومن المرجح أن تتغير مسائل الصيانة أيضًا للتكيف مع تطور البرمجيات المستقبلية. وتتطور عمليات البرمجيات نفسها باستمرار، فبعد المرور بمراحل التعلم والتحسين، تتحسن كفاءتها وفعاليتها باستمرار. [ 2 ]

المفاهيم الأساسية

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

لقد تأثر تطور البرمجيات بشكل كبير بالإنترنت:

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

أنواع صيانة البرمجيات

حدد إي. بي. سوانسون في البداية ثلاث فئات للصيانة: التصحيحية، والتكيفية، والتحسينية. ثم قام لينتز وسوانسون (1980) بتصنيف البرمجيات إلى أربع فئات. [ 5 ] وقد تم تحديث هذه الفئات وتوحيدها دوليًا في معيار ISO/IEC 14764:2006: [ 6 ]

  • الصيانة التصحيحية : تعديل تفاعلي لمنتج برمجي يتم إجراؤه بعد التسليم لتصحيح المشاكل المكتشفة؛
  • الصيانة التكيفية : تعديل منتج برمجي يتم إجراؤه بعد التسليم للحفاظ على قابلية استخدام المنتج البرمجي في بيئة متغيرة أو متغيرة؛
  • الصيانة التحسينية : تعديل منتج برمجي بعد تسليمه لتحسين الأداء أو قابلية الصيانة؛
  • الصيانة الوقائية : تعديل منتج برمجي بعد تسليمه لاكتشاف وتصحيح الأخطاء الكامنة في المنتج البرمجي قبل أن تصبح أخطاء فعالة.

كل ما سبق يحدث عندما تكون هناك حاجة معروفة للتغيير.

على الرغم من أن هذه الفئات قد تم استكمالها من قبل العديد من المؤلفين مثل وارين وآخرون (1999) [ 7 ] وشابين (2001) [ 8 ] فقد حافظ المعيار الدولي ISO/IEC 14764:2006 على الفئات الأربع الأساسية.

في الآونة الأخيرة، تم وصف صيانة وتطوير البرمجيات باستخدام الأنطولوجيات ( Kitchenham et al. (1999), [ 9 ] Deridder (2002), [ 10 ] Vizcaíno (2003), [ 11 ] Dias (2003), [ 12 ] و Ruiz (2004) [ 13 ] )، مما يثري وصف العديد من أنشطة التطوير.

نموذج المسرح

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

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

قوانين ليمان لتطور البرمجيات

حدد البروفيسور مئير م. ليمان ، الذي عمل في إمبريال كوليدج لندن من عام 1972 إلى عام 2002، وزملاؤه مجموعة من السلوكيات في تطور البرمجيات الاحتكارية . تُعرف هذه السلوكيات (أو الملاحظات) بقوانين ليمان. ويشير إلى أنظمة النوع E بأنها تلك المصممة لأداء نشاط واقعي. يرتبط سلوك هذه الأنظمة ارتباطًا وثيقًا بالبيئة التي تعمل فيها، ويحتاج هذا النظام إلى التكيف مع المتطلبات والظروف المتغيرة في تلك البيئة. القوانين الثمانية هي:

  1. (1974) "التغيير المستمر" - يجب تكييف نظام النوع E باستمرار وإلا سيصبح أقل إرضاءً تدريجيًا [ 15 ]
  2. (1974) "زيادة التعقيد" - مع تطور نظام من النوع E، يزداد تعقيده ما لم يتم القيام بعمل صريح للحفاظ عليه أو تقليله [ 15 ]
  3. (1974) "التنظيم الذاتي" - عمليات تطور النظام من النوع E هي عمليات تنظيم ذاتي مع توزيع مقاييس المنتج والعملية بالقرب من الوضع الطبيعي [ 15 ]
  4. (1978) "الحفاظ على الاستقرار التنظيمي ( معدل العمل الثابت )" - متوسط ​​معدل النشاط العالمي الفعال في نظام من النوع E المتطور ثابت على مدار عمر المنتج [ 15 ]
  5. (1978) "الحفاظ على الألفة" - مع تطور نظام من النوع E، يجب على جميع المرتبطين به، من مطورين وموظفي مبيعات ومستخدمين على سبيل المثال، الحفاظ على إتقان محتواه وسلوكه لتحقيق تطور مُرضٍ. النمو المفرط يُقلل من هذا الإتقان. وبالتالي، يظل متوسط ​​النمو التراكمي ثابتًا مع تطور النظام. [ 15 ]
  6. (1991) "النمو المستمر" - يجب زيادة المحتوى الوظيفي لنظام من النوع E باستمرار للحفاظ على رضا المستخدم طوال فترة استخدامه
  7. (1996) "تراجع الجودة" - ستظهر جودة نظام من النوع E في تراجع ما لم تتم صيانته بدقة وتكييفه مع تغيرات بيئة التشغيل
  8. (1996) "نظام التغذية الراجعة" (تم ذكره لأول مرة عام 1974، وتم إضفاء الطابع الرسمي عليه كقانون عام 1996) - تشكل عمليات التطور من النوع E أنظمة تغذية راجعة متعددة المستويات ومتعددة الحلقات ومتعددة العوامل ويجب التعامل معها على هذا النحو لتحقيق تحسين كبير على أي أساس معقول [ 16 ].

تجدر الإشارة إلى أن مدى انطباق هذه القوانين على جميع أنواع أنظمة البرمجيات قد دُرِسَ من قِبَل العديد من الباحثين. على سبيل المثال، انظر إلى عرض نانجانجود سي ناريندرا [ 17 ] حيث يصف دراسة حالة لمشروع مؤسسي يعتمد على منهجية أجايل في ضوء قوانين ليمان لتطور البرمجيات. ويبدو أن بعض الملاحظات التجريبية المستقاة من دراسة تطوير البرمجيات مفتوحة المصدر تُشكِّك في بعض هذه القوانين .

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

تم تطوير نماذج النضج الخاصة بتطور البرمجيات لتحسين العمليات، والمساعدة في ضمان التجديد المستمر للبرمجيات أثناء تطورها بشكل متكرر .

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

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

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

انظر أيضاً

مراجع

  1. ↑ فريد بروكس ، الشهر الأسطوري للرجل . أديسون-ويسلي ، 1975 و1995. ISBN 0-201-00650-2 و ISBN 0-201-83595-9.
  2. ↑ aeddy؛ المرجع: فهم تطور البرمجيات مفتوحة المصدر، معهد والت سكاتشي لأبحاث البرمجيات
  3. ↑ بينيت، ك.هـ؛ راجليتش، ف.ت؛ مزرول، ر. محمد (1995). "النظام القديم: التعامل مع النجاح". مجلة IEEE للبرمجيات . الصفحات 19-23 . 
  4. ↑ ترونغ هونغ فو (2007)، صيانة البرمجيات
  5. ↑ لينتز، بي بي وسوانسون، إي بي، إدارة صيانة البرمجيات: دراسة لصيانة برامج تطبيقات الحاسوب في 487 مؤسسة لمعالجة البيانات . أديسون-ويسلي، ريدينغ، ماساتشوستس، 1980. ISBN 0-201-04205-3
  6. ↑ ISO/IEC 14764:2006، 2006.
  7. ↑ بول وارين؛ كورنيليا بولديريف؛ مالكولم مونرو (1999). "تطور مواقع الويب". وقائع ورشة العمل الدولية السابعة حول فهم البرامج . معهد مهندسي الكهرباء والإلكترونيات. الصفحات 178-185 . 
  8. ↑ نيد تشابين؛ جوان إي هيل؛ خالد محمد خان؛ خوان إف راميل؛ ووي جي تان (2001). "أنواع تطور البرمجيات وصيانتها". مجلة صيانة البرمجيات وتطويرها: البحث والممارسة . 13 (1): 3-30 . doi : 10.1002/smr.220 .
  9. ↑ باربرا كيتشنهام ؛ غيلهيرمي ترافاسوس؛ أنيليز فون مايرهاوزر؛ فرانك نيسينك؛ نورمان شنايدويند؛ جانيس سينغر؛ شينغو تاكادا؛ ريستو فيهفيلاينن؛ هونغجي يانغ (1999). "نحو أنطولوجيا لصيانة البرمجيات" . مجلة صيانة البرمجيات: البحث والممارسة . 11 (6): 365-389 . doi : 10.1002/(SICI)1096-908X(199911/12)11:6 < 365::AID - SMR200 > 3.0.CO ; 2- W.hdl : 10945/55140 .
  10. ↑ ديرك ديريدر (2002). "نهج قائم على المفاهيم لدعم أنشطة صيانة وإعادة استخدام البرمجيات". وقائع المؤتمر المشترك الخامس حول هندسة البرمجيات القائمة على المعرفة .
  11. ↑ أورورا فيزكاينو؛ خيسوس فافيلا؛ ماريو بياتيني (2003). "نظام متعدد الوكلاء لإدارة المعرفة في صيانة البرمجيات". أنظمة المعلومات والهندسة الذكية القائمة على المعرفة . سبرينغر. ص 415-421 . 
  12. ^ مارسيو دياس. نيكولا أنكيتيل؛ كاتيا دي أوليفيرا (2003). "تنظيم المعرفة المستخدمة في صيانة البرمجيات". مجلة علوم الكمبيوتر العالمية . 9 (7): 641- 658.
  13. ↑ فرانسيسكو رويز؛ أورورا فيزكاينو؛ ماريو بياتيني؛ فيليكس غارسيا (2004). "أنطولوجيا لإدارة مشاريع صيانة البرمجيات". المجلة الدولية لهندسة البرمجيات وهندسة المعرفة . 14 (3): 323-349 . doi : 10.1142/S0218194004001646 . S2CID 15592498 . 
  14. 1 2 3 4 5 6 بينيت، كيث؛ راجليتش، فاكلاف (1 يوليو 2000). "نموذج مرحلي لدورة حياة البرمجيات" (ملف PDF) . مجلة الكمبيوتر . 33 (7). جمعية مهندسي الكهرباء والإلكترونيات: 66-71 . doi : 10.1109/2.869374 . S2CID 7547412. تاريخ الاسترجاع: 23 مايو 2020 . 
  15. 1 2 3 4 5 ليمان، م.م. (1980). "حول فهم القوانين والتطور والحفظ في دورة حياة البرامج الكبيرة". مجلة الأنظمة والبرمجيات . 1 : 213-221 . doi : 10.1016/0164-1212(79)90022-0 .
  16. ↑ قوانين ليمان لتطور البرمجيات
  17. ↑ ناريندرا، نانجانغود (29 أبريل 2011). "تطور البرمجيات في التطوير الرشيق" . InfoQ . تم الاطلاع عليه في 19 مارس 2016 .

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

  • أندريا كابيلوبي، خيسوس م. جونزاليس باراهونا، إسرائيل هيرايز، جريجوريو روبلز، تكييف "النموذج المرحلي لتطور البرمجيات" مع FLOSS
  • مارك سي. بولك، تاريخ نموذج نضج القدرات في البرمجيات