صيانة البرامج

صيانة البرمجيات هي تعديل البرمجيات بعد تسليمها.

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

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

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

في أوائل سبعينيات القرن العشرين، بدأت الشركات بفصل صيانة البرمجيات وتخصيص فريق هندسي مستقل لها، وذلك لتخفيف العبء عن فرق تطوير البرمجيات من مهام الدعم. ^{[ 1 ]} وفي عام 1972، نشر آر جي كانينغ كتابه "جبل الجليد للصيانة " ، الذي جادل فيه بأن صيانة البرمجيات هي امتداد لتطوير البرمجيات مع إضافة عنصر أساسي: النظام القائم. ^{[ 1 ]} لم يطرأ تغيير يُذكر على مجال صيانة البرمجيات منذ ذلك الحين. ^{[ 2 ]} ومن ابتكارات القرن الحادي والعشرين قيام الشركات بإصدار برمجيات غير مكتملة عمدًا، مع التخطيط لإكمالها بعد الإصدار. يُطلق على هذا النوع من التغيير، وغيره من التغييرات التي تُوسّع وظائف البرمجيات، غالبًا اسم " تطور البرمجيات" بدلًا من "الصيانة". ^{[ 2 ]}

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

إذا نُظر إلى الصيانة كجزء من دورة حياة تطوير البرمجيات ، فإنها تُعدّ المرحلة الأخيرة والأطول عادةً في هذه الدورة، ^{[ 7 ] [ 8 ]} حيث تُشكّل ما بين 80 و90 بالمئة من تكلفة دورة الحياة. ^{[ 9 ]} بينما تُعتبر نماذج أخرى الصيانة منفصلة عن تطوير البرمجيات، بل جزءًا من دورة حياة صيانة البرمجيات (SMLC). ^{[ 8 ]} وتشمل نماذج SMLC عادةً فهم الكود، وتعديله، وإعادة التحقق من صحته. ^{[ 8 ]}

الانتقال من مرحلة الإصدار إلى مرحلة الصيانة إلى نهاية العمر الافتراضي

في كثير من الأحيان، يتم تسليم البرامج في حالة غير مكتملة. يختبر المطورون المنتج حتى ينفد الوقت أو التمويل، لأنهم يتحملون عواقب أقل للمنتج غير الكامل مقارنةً بتجاوز الوقت أو الميزانية. ^{[ 10 ]} غالبًا ما تكون عملية الانتقال من فريق التطوير إلى فريق الصيانة غير فعالة، لعدم وجود قوائم بالمشاكل المعروفة أو اختبارات التحقق، والتي من المرجح أن يعيد فريق الصيانة إنشاؤها. ^{[ 11 ]} بعد الإصدار، من المرجح أن يُعاد تعيين أعضاء فريق التطوير أو يصبحوا غير متاحين لأسباب أخرى. سيحتاج فريق الصيانة إلى موارد إضافية خلال السنة الأولى بعد الإصدار، سواء للدعم الفني أو لإصلاح العيوب المتبقية من عملية التطوير. ^{[ 10 ]}

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

يتمثل الهدف الرئيسي لصيانة البرمجيات في ضمان استمرار المنتج في تلبية متطلبات سهولة الاستخدام. وقد يعني هذا أحيانًا توسيع قدرات المنتج لتتجاوز ما تم تصوره في البداية. ^{[ 30 ]}

وفقًا لمواصفات ISO / IEC 14764، يمكن تصنيف صيانة البرمجيات إلى أربعة أنواع: ^{[ 31 ]}

• الصيانة التصحيحية : تعديل البرمجيات لإصلاح خلل أو أي خلل آخر لا يفي بالمتطلبات، وعادةً ما يتم الإبلاغ عنه من قبل المستخدم النهائي. ^{[ 31 ] [ 32 ]}
• الصيانة الوقائية : هي تعديل استباقي للبرمجيات بعد تسليمها لضمان استمرارها في تلبية المتطلبات أو إصلاح المشكلات التي لم تظهر بعد. ^{[ 33 ] [ 31 ]} يُجرى هذا النوع من الصيانة بشكل خاص على الأنظمة التي تتطلب مستوى عالٍ من الأمان أو التوافر. ^{[ 33 ]} يُعدّ تجديد البرمجيات أحد أشكال الصيانة الوقائية لتنظيف حالة النظام ومنع المشكلات المستقبلية. ^{[ 33 ]}
• الصيانة التكيفية: تعديل البرمجيات بعد تسليمها لضمان استمرارية استخدامها في بيئة متغيرة أو قابلة للتغيير. ^{[ 31 ] [ 33 ]}
• الصيانة التحسينية: هي تحسين البرمجيات بعد تسليمها لتعزيز خصائصها، مثل تجربة المستخدم ، وكفاءة المعالجة، وسهولة الصيانة . ^{[ 33 ] [ 34 ]} تُعدّ الصيانة التحسينية ضرورية في حال إجراء أنواع أخرى من الصيانة، لأن تعديل قاعدة بيانات برمجية موجودة سيؤدي إلى زيادة التعقيد وتدهور البنية الحالية. ^{[ 34 ]} قد تشمل الصيانة التحسينية إعادة كتابة الوثائق ، وإعادة هيكلة الكود ، وتحسين الأداء. ^{[ 33 ]}

تشير بعض التقديرات إلى أن التحسين (الفئتان الأخيرتان) يشكلان حوالي 80 بالمائة من صيانة البرمجيات. ^{[ 35 ]}

تُعرَّف قابلية الصيانة بأنها جودة البرمجيات التي تُمكّن من تعديلها بسهولة دون التأثير على وظائفها الحالية. ^{[ 31 ]} ووفقًا لمواصفات ISO/IEC 14764، يُعدّ النشاط الذي يضمن قابلية صيانة البرمجيات قبل إصدارها جزءًا من صيانة البرمجيات. ^{[ 5 ]} تتجاهل العديد من مؤسسات تطوير البرمجيات قابلية الصيانة، على الرغم من أن ذلك سيزيد التكاليف على المدى الطويل. ^{[ 36 ]} ينشأ الدين التقني عندما يختار المبرمجون، غالبًا بدافع الكسل أو الاستعجال للوفاء بالموعد النهائي، حلولًا سريعة وغير متقنة بدلًا من دمج قابلية الصيانة في شفرة برمجتهم. ^{[ 37 ]} ومن الأسباب الشائعة التقليل من تقدير جهد تطوير البرمجيات ، مما يؤدي إلى عدم كفاية الموارد المخصصة للتطوير. ^{[ 38 ]} ومن الجوانب المهمة وجود عدد كبير من اختبارات البرمجيات الآلية التي يمكنها اكتشاف ما إذا كانت الوظائف الحالية قد تأثرت سلبًا بالتغيير. ^{[ 31 ]}

يمكن حساب مؤشر قابلية الصيانة باستخدام صيغ معينة من مقاييس أسطر التعليمات البرمجية ، ومقاييس مكابي ، ومقاييس تعقيد هالستيد .

يهدف قياس وتتبع قابلية الصيانة إلى المساعدة في تقليل أو عكس ميل النظام نحو "إنتروبيا الكود" أو تدهور السلامة، وإلى الإشارة إلى متى يصبح إعادة كتابة الكود أرخص و/أو أقل خطورة من تغييره.

من التحديات التي تواجه قابلية الصيانة أن العديد من دورات هندسة البرمجيات لا تُوليها الاهتمام الكافي، وتُقدم مهامًا لمرة واحدة بمواصفات واضحة وثابتة. ^{[ 39 ]} كما أن دورات هندسة البرمجيات لا تُغطي الأنظمة المعقدة كما هو الحال في الواقع. ^{[ 40 ]} ومهندسو التطوير الذين يعلمون أنهم لن يكونوا مسؤولين عن صيانة البرمجيات لا يملكون حافزًا لتضمين قابلية الصيانة في مناهجهم. ^{[ 2 ]}

غالباً ما يُنظر إلى الصيانة على أنها وظيفة غير مُجزية لمهندسي البرمجيات ، الذين يميلون إلى ترك العمل إذا ما تم تكليفهم بها. ^{[ 41 ] [ 42 ]} كما أن أجرها غالباً ما يكون أقل من أجر وظيفة مماثلة في مجال تطوير البرمجيات. ^{[ 42 ]} وكثيراً ما تُسند هذه المهمة إلى عمال مؤقتين أو موظفين ذوي مهارات أقل، ^{[ 2 ] [ 43 ]} مع أن مهندسي الصيانة عادةً ما يكونون أكبر سناً من المطورين، ويعود ذلك جزئياً إلى ضرورة إلمامهم بالتقنيات القديمة. ^{[ 43 ]} في عام 2008، كان حوالي 900 ألف من أصل 1.3 مليون مهندس ومبرمج برمجيات يعملون في الولايات المتحدة يقومون بأعمال الصيانة. ^{[ 44 ]}

بدأت الشركات بتشكيل فرق منفصلة للصيانة، مما أدى إلى الاستعانة بمصادر خارجية لهذه المهمة، وبحلول مطلع القرن الحادي والعشرين، لجأت أحيانًا إلى نقل العمل إلى دولة أخرى، سواء كجزء من الشركة الأصلية أو ككيان منفصل. ^{[ 45 ] [ 9 ]} وتشمل المصادر النموذجية للاستعانة بمصادر خارجية الدول المتقدمة مثل الولايات المتحدة والمملكة المتحدة واليابان وأستراليا، بينما تكون الوجهات عادةً دولًا ذات تكلفة منخفضة مثل الصين والهند وروسيا وأيرلندا. ^{[ 46 ]} وتشمل أسباب نقل العمل إلى الخارج الاستفادة من انخفاض تكاليف العمالة، وتوفير الدعم على مدار الساعة، وتخفيف ضغط الوقت على المطورين، وتقريب الدعم من سوق المنتج. ^{[ 47 ]} أما سلبيات نقل العمل إلى الخارج فتشمل عوائق التواصل الناتجة عن عوامل مثل اختلاف المناطق الزمنية والاختلافات التنظيمية والثقافية. ^{[ 9 ]} على الرغم من أن العديد من أصحاب العمل يعتبرون الصيانة عملاً منخفض المهارة ومرحلة تطوير البرمجيات الأنسب للاستعانة بمصادر خارجية، ^{[ 9 ] [ 48 ]} إلا أنها تتطلب تواصلاً وثيقاً مع العميل واستجابة سريعة، وكلاهما يتعثر بسبب صعوبات التواصل هذه. ^{[ 9 ]}

في هندسة البرمجيات، لا يحمل مصطلح " النظام القديم" معنىً محددًا، ولكنه يشير غالبًا إلى الأنظمة القديمة الضخمة التي يصعب تعديلها، والتي تُعد ضرورية أيضًا لتلبية احتياجات العمل الحالية. غالبًا ما تُكتب الأنظمة القديمة بلغات برمجة عفا عليها الزمن ، وتفتقر إلى التوثيق، وتتدهور بنيتها بعد سنوات من التغييرات، وتعتمد على الخبراء للحفاظ على تشغيلها. ^{[ 49 ]} عند التعامل مع هذه الأنظمة، يتراكم قدر كبير من الديون التقنية في مرحلة ما، مما يجعل صيانتها غير عملية وغير اقتصادية. ^{[ 12 ]} تشمل الخيارات الأخرى ما يلي:

• التجميد - التوقف عن إجراء أي عمل إضافي على النظام القديم. ^{[ 50 ]} يمكن اختيار هذا الخيار إذا أراد المورّد الاستمرار في جني الإيرادات لأطول فترة ممكنة مع تجنب تكاليف الصيانة. ^{[ 12 ]}
• الاستعانة بمصادر خارجية لتنفيذ وظائف النظام القديم إلى شركة أخرى، خاصة إذا لم تكن تعتبر وظيفة أساسية من وظائف العمل. ^{[ 50 ]}
• التخلي عن النظام القديم الحالي وإعادة تطوير تطبيق جديد من الصفر ليؤدي نفس الغرض. ^{[ 50 ]} ومع ذلك، فإن هذا النهج غير فعال لأنه يتخلى عن نظام عامل، كما أنه ينطوي على خطر عدم قدرة النظام الجديد على تلبية متطلبات العمل المتغيرة. ^{[ 50 ]}
• تغليف التطبيق القديم بطبقة تجريدية لتبسيط الواجهات القديمة. ^{[ 50 ]} لا يتم تعديل شفرة المصدر، ولكن الواجهة الجديدة تسمح للتطبيقات الأحدث بالوصول إلى مكون مجرب ومختبر. لا يحل هذا النهج أيًا من مشكلات صيانة النظام القديم. ^{[ 51 ]} يمكن تغليف قواعد البيانات والوظائف والتطبيقات بأكملها بهذه الطريقة. ^{[ 52 ]}
• يُمكن أن يُساهم نقل النظام القديم إلى منصة جديدة في تقليل تكلفة تطوير البرمجيات الجديدة من خلال إعادة استخدام عناصر التنفيذ والتصميم والمواصفات والمتطلبات الخاصة بالنظام القديم. ^{[ 53 ]} قد تستغرق عملية النقل من 5 إلى 10 سنوات، ولكنها تُؤدي إلى مرونة أكبر وتوفير طويل الأجل في صيانة البرمجيات. ^{[ 54 ]} تصل نسبة التكاليف المُخصصة للاختبار إلى 80%؛ أي ضمان أن يُنتج النظام الجديد نفس مخرجات النظام القديم. ^{[ 55 ]} بعد الانتهاء من النظام الجديد، يجب الانتقال منه بسلاسة وبأقل قدر من التأثير على سير العمل. ^{[ 55 ]}

على الرغم من أن الصيانة تستحوذ على الحصة الأكبر من موارد تطوير البرمجيات، إلا أنها المرحلة الأقل دراسة في هذا المجال. ^{[ 56 ] [ 57 ]} وقد ركزت معظم الدراسات على كيفية تطوير برمجيات قابلة للصيانة منذ البداية، مع إيلاء اهتمام أقل لتحفيز المهندسين على جعل الصيانة أولوية. ^{[ 58 ]} اعتبارًا من عام 2020تُعدّ الحلول الآلية لإعادة هيكلة التعليمات البرمجية لتقليل جهد الصيانة مجالًا نشطًا للبحث، ^{[ 59 ]} وكذلك تقييم قابلية الصيانة المعزز بالتعلم الآلي . ^{[ 60 ]}

• تقدير التكاليف في هندسة البرمجيات
• التكلفة الإجمالية للملكية ، وتكلفة المنتج بما في ذلك تكاليف الصيانة والتكاليف غير المباشرة الأخرى