صيانة البرمجيات  في سياق هندسة البرمجيات، يشير مصطلح صيانة البرمجيات إلى التعديلات التي تجرى على منتج برمجي بعد التسليم بهدف تصحيح العيوب أو تحسين أداء البرمجية أو أي خاصية من خصائصها.  يعد مير إم. ليمان أول من تناول موضوع صيانة البرمجيات وتطوّر الأنظمة عام 1969. أدت أبحاثه التي استمرت لعشرين عامًا إلى صياغة قوانين ليمان (ليمان 1997). وأهم النتائج التي توصلت إلها أبحاثه هي أن الصيانة تَطوّر تدريجي حقيقي وأن قرارات الصيانة تُدعم بفهم ما يحدث للأنظمة (والبرمجيات) مع مرور الوقت. أثبت ليمان أن الأنظمة تستمر في التطور بمرور الوقت. ومع تطورها تصبح أكثر تعقيدًا ما لم تُتخذ بعض الإجراءات مثل إعادة تشكيل الكود لتقليل التعقيد.  أظهرت دراسة استقصائية شهيرة ومستشهد بها على نطاق واسع أجراها لينتز وسوانسون في أواخر السبعينيات، أن جزءًا كبيرًا جدًا من تكاليف دورة الحياة كانت تُنفق على الصيانة. صنّفوا أنشطة الصيانة إلى أربع فئات:   أظهر الاستقصاء أن نحو 75% من جهود الصيانة كانت تبذل في النوعين الأولين، واستهلك تصحيح الأخطاء نحو 21% منها. أشارت العديد من الدراسات اللاحقة إلى حجم مشاكل مماثل. تشير الدراسات إلى أن مساهمة المستخدمين النهائيين خلال جمع وتحليل بيانات المتطلبات الجديدة بالغة الأهمية. وهي السبب الرئيسي لأي مشكلة أثناء تطوير البرمجيات وصيانتها. تعد صيانة البرمجيات مهمة لأنها تستهلك جزءًا كبيرًا من تكاليف دورة الحياة الإجمالية، وعدم القدرة على تغيير البرمجيات بسرعة وموثوقية يعني خسارة فرص العمل.  المسائل الرئيسية لصيانة البرمجيات هي المسائل الإدارية والفنية. المسائل الإدارية الرئيسية هي: التوافق مع أولويات العملاء، والتوظيف، وأي منظمة تقوم بالصيانة، وتقدير التكاليف. المسائل الفنية الرئيسية هي: الفهم المحدود، وتحليل أثر التغيير، والاختبار، وقياس إمكانية الصيانة.  تعد صيانة البرامج نشاطًا واسعًا للغاية يشمل تصحيح الأخطاء، وتحسين الإمكانيات، وإلغاء الإمكانيات القديمة، والتحسين (الأمثًلة). ولأنه لا بد من التغيير، يجب تطوير آليات للتقييم والتحكم وإجراء التعديلات.  لذا يعتبر أي عمل يجرى لتغيير البرمجيات بعد تشغيلها أعمال صيانة. الغرض منها هو الحفاظ على قيمة البرمجيات بمرور الوقت. يمكن تعزيز القيمة من خلال توسيع قاعدة العملاء، وتلبية المتطلبات الإضافية، وتسهيل الاستخدام، وزيادة الكفاءة واستخدام تقنية أحدث. قد تستمر عملية الصيانة لمدة 20 عامًا، في حين قد يتم التطوير في عام أو عامين.  تعد الصيانة جزءًا أساسيًا من البرمجيات، ما يتطلب إعداد خطة صيانة دقيقة أثناء تطوير البرمجيات. يجب أن تحدد كيفية طلب المستخدمين لإجراء تعديلات أو الإبلاغ عن المشاكل. يجب أن تتضمن الميزانية تقديرات الموارد والتكاليف. ويجب معالجة قرار جديد لتطوير كل ميزة جديدة للنظام وأهداف جودته. إن صيانة البرمجيات، التي قد تستمر لمدة تتراوح بين 5 إلى 6 سنوات (أو حتى عقود) بعد عملية التطوير، تتطلب خطة فعّالة يمكنها معالجة نطاق صيانة البرمجيات، تكييف عمليات ما بعد التسليم/النشر، وتحديد من الذي سيوفر الصيانة، وتقدير تكاليف دورة الحياة. إن اختيار التطبيق الصحيح للمعايير هو المهمة الصعبة منذ المراحل الأولى في هندسة البرمجيات والتي لم تكسب أهمية حاسمة لدى أصحاب المصالح المعنيين.  يصف هذا القسم عمليات صيانة البرمجيات الستة كما يلي:   هناك عدد من العمليات والأنشطة والممارسات التي ينفرد بها القائمون على الصيانة، مثلًا:   حدد إي. بي  سوانسون مبدئيًا ثلاث فئات من الصيانة: التصحيحية والتكيفية والمثالية. استبدل معيار IEEE 1219 في يونيو 2010 بمعيار P14764. وحُدثت هذه الفئات من ذلك الوقت ويقدم معيار آيزو/ آي إي سي 14764 ما يلي:   هناك أيضًا مفهوم للصيانة قبل التسليم / قبل الإصدار وهو كل الأشياء الجيدة التي يمكن القيام  بها لخفض التكلفة الإجمالية لملكية البرمجيات. مثل الامتثال لمعايير الترميز التي تتضمن أهداف إمكانية صيانة البرمجيات. إدارة ربط البرمجيات وتماسكها. تحقيق أهداف دعم البرمجيات (SAE JA1004 وJA1005 وJA1006 مثلًا). لاحظ أيضًا أن بعض المؤسسات الأكاديمية تجري أبحاثًا لتحديد التكلفة اللازمة لصيانة البرمجيات المستمرة نظرًا لنقص الموارد مثل توثيق التصميم والتدريب على فهم الأنظمة/البرمجيات والموارد (تضاعف التكاليف نحو 1.5-2.0 مرة عند عدم وجود بيانات تصميم متاحة).