في سياق هندسة البرمجيات، يشير مصطلح صيانة البرمجيات (Software maintenance) إلى التعديلات التي تجرى على منتج برمجي بعد التسليم بهدف تصحيح العيوب أو تحسين أداء البرمجية أو أي خاصية من خصائصها.[1][2][3]
| عملية تطوير البرمجيات | |
|---|---|
| نشاطات وخطوات | |
|
المتطلبات · مواصفة وظيفية البنيان · تصميم البرمجيات التنفيذ · الفحص نشر البرمجيات · صيانة البرمجيات | |
| منهجيات | |
|
أجيل · هندسة برمجيات الغرفة النظيفة · Iterative RAD · RUP · Spiral Waterfall · XP · Lean سكرم · V-Model · TDD | |
| اختصاصات داعمة | |
|
إدارة تكوين البرمجيات توثيق البرمجيات ضمان الجودة Project management تصميم تجربة المستخدم | |
| أدوات | |
|
المصرف · المصحح · Profiler GUI designer · ب ت م | |
التاريخ
يعد مير إم. ليمان أول من تناول موضوع صيانة البرمجيات وتطوّر الأنظمة عام 1969. أدت أبحاثه التي استمرت لعشرين عامًا إلى صياغة قوانين ليمان (ليمان 1997). وأهم النتائج التي توصلت إلها أبحاثه هي أن الصيانة تَطوّر تدريجي حقيقي وأن قرارات الصيانة تُدعم بفهم ما يحدث للأنظمة (والبرمجيات) مع مرور الوقت. أثبت ليمان أن الأنظمة تستمر في التطور بمرور الوقت. ومع تطورها تصبح أكثر تعقيدًا ما لم تُتخذ بعض الإجراءات مثل إعادة تشكيل الكود لتقليل التعقيد.
أظهرت دراسة استقصائية شهيرة ومستشهد بها على نطاق واسع أجراها لينتز وسوانسون في أواخر السبعينيات، أن جزءًا كبيرًا جدًا من تكاليف دورة الحياة كانت تُنفق على الصيانة. صنّفوا أنشطة الصيانة إلى أربع فئات:
- التكيفية - تعديل النظام للتكيف مع التغيرات في البيئة البرمجية (نظام إدارة قواعد البيانات، نظام التشغيل)[3]
- المثالية - تنفيذ متطلبات المستخدم الجديدة أو المتغيرة التي تتعلق بالتحسينات الوظيفية للبرمجيات
- التصحيحية - تشخيص الأخطاء وإصلاحها، التي قد يجد المستخدمون بعضها
- الوقائية - زيادة صيانة البرمجيات ووثوقيتها لمنع حدوث مشاكل في المستقبل
أظهر الاستقصاء أن نحو 75% من جهود الصيانة كانت تبذل في النوعين الأولين، واستهلك تصحيح الأخطاء نحو 21% منها. أشارت العديد من الدراسات اللاحقة إلى حجم مشاكل مماثل. تشير الدراسات إلى أن مساهمة المستخدمين النهائيين خلال جمع وتحليل بيانات المتطلبات الجديدة بالغة الأهمية. وهي السبب الرئيسي لأي مشكلة أثناء تطوير البرمجيات وصيانتها. تعد صيانة البرمجيات مهمة لأنها تستهلك جزءًا كبيرًا من تكاليف دورة الحياة الإجمالية، وعدم القدرة على تغيير البرمجيات بسرعة وموثوقية يعني خسارة فرص العمل.[4][5][6]
أهمية صيانة البرمجيات
المسائل الرئيسية لصيانة البرمجيات هي المسائل الإدارية والفنية. المسائل الإدارية الرئيسية هي: التوافق مع أولويات العملاء، والتوظيف، وأي منظمة تقوم بالصيانة، وتقدير التكاليف. المسائل الفنية الرئيسية هي: الفهم المحدود، وتحليل أثر التغيير، والاختبار، وقياس إمكانية الصيانة.
تعد صيانة البرامج نشاطًا واسعًا للغاية يشمل تصحيح الأخطاء، وتحسين الإمكانيات، وإلغاء الإمكانيات القديمة، والتحسين (الأمثًلة). ولأنه لا بد من التغيير، يجب تطوير آليات للتقييم والتحكم وإجراء التعديلات.
لذا يعتبر أي عمل يجرى لتغيير البرمجيات بعد تشغيلها أعمال صيانة. الغرض منها هو الحفاظ على قيمة البرمجيات بمرور الوقت. يمكن تعزيز القيمة من خلال توسيع قاعدة العملاء، وتلبية المتطلبات الإضافية، وتسهيل الاستخدام، وزيادة الكفاءة واستخدام تقنية أحدث. قد تستمر عملية الصيانة لمدة 20 عامًا، في حين قد يتم التطوير في عام أو عامين.
تخطيط صيانة البرمجيات
تعد الصيانة جزءًا أساسيًا من البرمجيات، ما يتطلب إعداد خطة صيانة دقيقة أثناء تطوير البرمجيات. يجب أن تحدد كيفية طلب المستخدمين لإجراء تعديلات أو الإبلاغ عن المشاكل. يجب أن تتضمن الميزانية تقديرات الموارد والتكاليف. ويجب معالجة قرار جديد لتطوير كل ميزة جديدة للنظام وأهداف جودته. إن صيانة البرمجيات، التي قد تستمر لمدة تتراوح بين 5 إلى 6 سنوات (أو حتى عقود) بعد عملية التطوير، تتطلب خطة فعّالة يمكنها معالجة نطاق صيانة البرمجيات، تكييف عمليات ما بعد التسليم/النشر، وتحديد من الذي سيوفر الصيانة، وتقدير تكاليف دورة الحياة. إن اختيار التطبيق الصحيح للمعايير هو المهمة الصعبة منذ المراحل الأولى في هندسة البرمجيات والتي لم تكسب أهمية حاسمة لدى أصحاب المصالح المعنيين.
عمليات صيانة البرمجيات
يصف هذا القسم عمليات صيانة البرمجيات الستة كما يلي:
- تتضمن عملية التنفيذ أنشطة الإعداد والانتقال البرمجية، مثل تصور ووضع خطة الصيانة؛ والإعداد لمعالجة المشاكل المحددة أثناء التطوير؛ ومتابعة إدارة تكوين المنتجات.
- عملية تحليل المشكلة والتعديل، التي تنفذ عندما يصبح التطبيق من مسؤولية فريق الصيانة. يجب على مبرمج الصيانة تحليل كل طلب، وتأكيده (بإعادة إنتاج الحالة)، والتحقق من صلاحتيه، والتحقيق فيه، واقتراح حل وتوثيق الطلب، وأخيرًا الحصول على جميع التصريحات المطلوبة لتطبيق التعديلات.
- العملية التي تنظر في تنفيذ التعديل نفسه.
- قبول العملية للتعديل، من خلال تأكيد العمل المعدل مع الشخص الذي قدم الطلب للتأكد من أن التعديل قد وفّر حلًا.
- تعتبر عملية الترحيل (ترحيل الأنظمة الأساسية مثلًا) وهي عملية استثنائية وليست جزءًا من مهام الصيانة اليومية. إذا كان يجب نقل البرمجيات إلى نظام أساسي آخر دون أي تغيير في الوظائف، تُستخدم هذه العملية ومن المحتمل أن يُعيّن فريق مشروع صيانة لهذه المهمة.
- أخيرًا، عملية الصيانة الأخيرة، وهي أيضًا لا تحدث يوميًا، هي سحب البرمجيات.
هناك عدد من العمليات والأنشطة والممارسات التي ينفرد بها القائمون على الصيانة، مثلًا:
- الانتقال: تسلسل مراقب ومنسَق للأنشطة يتم خلالها نقل النظام تدريجياً من المطور إلى المشرف؛
- اتفاقات مستوى الخدمة (إس إل إيه) وعقود الصيانة المتخصصة (الخاصة بمجال معيّن) التي يفاوض عليها القائمون على الصيانة؛
- الدعم الفني لطلب التعديل وتقرير المشكلة: عملية معالجة المشاكل يستخدمها القائمون على الصيانة لتحديد أولويات وتوثيق وتوجيه الطلبات التي يتلقونها.
فئات الصيانة في معيار المنظمة الدولية للمعايير(آيزو)/ اللجنة الكهروتقنية الدولية 14764
حدد إي. بي سوانسون مبدئيًا ثلاث فئات من الصيانة: التصحيحية والتكيفية والمثالية.[7] استبدل معيار IEEE 1219 في يونيو 2010 بمعيار P14764. وحُدثت هذه الفئات من ذلك الوقت[8] ويقدم معيار آيزو/ آي إي سي 14764 ما يلي:
- الصيانة التصحيحية: التعديل التفاعلي للمنتج البرمجي المنفذ بعد التسليم لتصحيح المشكلات المكتشفة.
- الصيانة التكيفية: تعديل المنتج البرمجي المنفذ بعد التسليم للحفاظ على استخدام المنتج البرمجي في بيئة متغيرة أو تغيرت مسبقًا.
- الصيانة المثالية: تعديل المنتج البرمجي بعد التسليم لتحسين الأداء أو إمكانية الصيانة.
- الصيانة الوقائية: تعديل المنتج البرمجي بعد التسليم لاكتشاف الأخطاء الخفية في المنتج البرمجي وتصحيحها قبل أن تصبح أخطاء فعلية.
هناك أيضًا مفهوم للصيانة قبل التسليم / قبل الإصدار وهو كل الأشياء الجيدة التي يمكن القيام بها لخفض التكلفة الإجمالية لملكية البرمجيات. مثل الامتثال لمعايير الترميز التي تتضمن أهداف إمكانية صيانة البرمجيات. إدارة ربط البرمجيات وتماسكها. تحقيق أهداف دعم البرمجيات (SAE JA1004 وJA1005 وJA1006 مثلًا). لاحظ أيضًا أن بعض المؤسسات الأكاديمية تجري أبحاثًا لتحديد التكلفة اللازمة لصيانة البرمجيات المستمرة نظرًا لنقص الموارد مثل توثيق التصميم والتدريب على فهم الأنظمة/البرمجيات والموارد (تضاعف التكاليف نحو 1.5-2.0 مرة عند عدم وجود بيانات تصميم متاحة).
مراجع
- "ISO/IEC 14764:2006 Software Engineering — Software Life Cycle Processes — Maintenance". Iso.org. 2011-12-17. مؤرشف من الأصل في 11 مايو 201602 ديسمبر 2013.
- Pigoski, Thomas. "Chapter 6: Software Maintenance" ( كتاب إلكتروني PDF ). SWEBOK. IEEE. مؤرشف من الأصل ( كتاب إلكتروني PDF ) في 10 أغسطس 201705 نوفمبر 2012.
- Software Maintenance and Re-engineering, CSE2305 Object-Oriented Software Engineering نسخة محفوظة 18 نوفمبر 2016 على موقع واي باك مشين.
- Lientz B., Swanson E., 1980: Software Maintenance Management. Addison Wesley, Reading, MA
- Lehman M. M., 1980: Program, Life-Cycles and the Laws of Software Evolution. In Proceedings of IEEE, 68, 9,1060-1076
- Penny Grubb, Armstrong A. Takang, 2003: Software Maintenance: Concepts and Practice. World Scientific Publishing Company
- "E. Burt Swanson, The dimensions of maintenance. Proceedings of the 2nd international conference on Software engineering, San Francisco, 1976, pp 492 — 497". Portal.acm.org. doi:10.1145/359511.359522. مؤرشف من الأصل في 27 مايو 202002 ديسمبر 2013.
- Status of 1219-1998 by IEEE Standards نسخة محفوظة 6 فبراير 2020 على موقع واي باك مشين.