Одржавање софтвера у софтверском инжењерству је модификација софтверског производа након стварања да исправи грешке, да би побољшали перформансе или друге атрибуте..^[1][2]

Заједничка перцепција одржавања је да се само укључује везивање недостатака. Међутим, једна студија показала је да се преко 80% напора одржавања  користи за не-корективне акције.^[3] Ово мишљење су овековечили корисници који подносе проблеме јављања да је у стварности функционалност побољшања у систему. Новије студије ставиле баг-причвршћивање ближе 21%.^[4]

За одржавање софтвера и еволуцију система се прво обратио Меир М. Леман 1969. У периоду од двадесет година, његова истраживања довела су до формулисања Леман закона (Леман 1997). Кључни налази његовог истраживања укључују да је одржавање заиста еволутивни развој и да одлуке одржавања су помагале разумевању шта се дешава са системима (и софтвера) током времена. Леман је показао да је систем наставио да се развија током времена. Док еволуирају, они расту више комплексно, осим ако се нека акција као што је рефакторисање кода узима да се смањи сложеност.

У касним 1970-им, познато и широко цитирано студијско истраживање Лиенц и Свансон, изложило је веома висок део трошкова животног циклуса који се утрошио на одржавање. Активности одржавања су подељене у четири класе:

• Адаптивна - мењање система да се носи са променама у окружењу софтвера (DBMS, OS)^[5]
• Перфектна - имплементација нових или измењених потреба корисника које се тичу функционалног побољшања софтвера
• Корективна - дијагнозе и исправљање грешака, евентуално оне које пронађу корисници^[5]
• Превентивна - повећање одржавања софтвера и поузданости како би се спречили  проблеми у будућности^[5]

Истраживање је показало да је око 75% од напора одржавања било на прва два типа, и исправљање грешака конзумира око 21%. Многи каснији студији показују сличну величину проблема. Студије показују да допринос крајњег корисника је од кључне важности током новог прикупљања података услова и анализе. И то је био главни узрок  проблема током еволуције софтвера и одржавање. Дакле, одржавање софтвера је важно јер троши велики део укупних трошкова животног циклуса и такође немогућности да брзо и поуздано промените софтвер и значи да су пословне могућности изгубљене. ^{[6] [7] [8]}

Кључна питања одржавања софтвера су и менаџерска и техничка. Кључна питања управљања су: усклађивање са приоритетима клијената, особља, које организација нема одржавања, процена трошкова. Кључна техничка питања су: ограничено разумевање, анализа утицаја, тестирање, мерење одржавање.

Одржавање софтвера је веома широка активност која укључује корекцију грешака, побољшања способности, брисање застарелих могућности и оптимизацију. Због промена је неизбежна, морају бити успостављени механизми за евалуацију, контролу и прављењем измена.

Дакле, све што је урађено да промени софтвер након што је у функцији сматра се радовима на одржавању. Циљ је да се очува вредност софтвера током времена. Вредност се може побољшати проширењем базе клијената, испуњавањем додатних захтева, постаје лакши за коришћење, ефикаснији и запошљава новију технологију. Одржавање може спан за 20 година, док развој може бити 1-2 година.

Саставни део програма је одржавање, што захтева прецизни план одржавања да буде урађен у току развоја софтвера. То би требало да прецизира колико ће корисници захтевати измене или пријавити проблем. Буџет треба да обухвати ресурсе и трошкове. Нова одлука треба да буде упућена у развоју сваког новог система функција и циљева квалитета.  Одржавање софтвера, који може трајати 5-6 година (или чак деценија) након процеса развоја, позива на ефективан план који може обратити обим одржавања софтвера, занат на пост испоруке / распоређивања процеса, именовање ко ће обезбедити одржавање и процену трошкова животног циклуса. Избор правилног спровођења стандарда је прави  изазов од ране фазе софтверског инжењерства која није добила дефинитиван значај од стране заинтересованих страна.

Ово поглавље описује шест процеса одржавања софтвер као:

1. Процес имплементације садржи софтверске припреме и транзиционе активности, као што су концепције и стварање плана одржавања; припрема за руковање проблема идентификованих током развоја; и праћење о управљању конфигурацијом производа.
2. Процес анализе проблема и модификација, која се извршава након примене постала је одговорност групе одржавања. Програмер одржавање мора да анализира сваки захтев, потврди (за репродукцију ситуације) и провери његову ваљаност, истражи га и предложи решење, документује захтев и предлог решења, и коначно, добије сва потребна овлашћења да примени измене.
3. Процес с обзиром на примену саме модификације.
4. Прихватање процеса модификације, потврђујући модификован рад са појединцем који је поднео захтев како би били сигурни да је модификација безбедно решење.
5. Процес миграције (платформа миграције, на пример) је изузетан, и није део свакодневних задатака одржавања. Ако програм мора бити промењен на другу платформу, без било какве промене у функционалности, овај процес ће се користити и пројекат одржавања тима ће вероватно бити додељен овом задатаку.
6. Коначно, последњи процес одржавања, такође догађај који се не јавља свакодневно, је пензионисање комада софтвера.

Постоји велики број процеса, активности и праксе које су јединствене за одржаваоца, на пример:

• Транзиција: контролисана и координирана секвенца активности током којих је систем пренесен прогресивно од програмера до одржаваоца;
• Service Level Agreements (SLAs) и специјализованог (Домаин-Специфиц) уговора о одржавању договорене са маинтаинерс;
• Измена захтева и Проблем пријаве помоћи : процес проблема руковања користи одржаваоца као приоритет, документа и путем захтевима које примају;

Е. Б. Свансон, првобитно идентификоване три категорије одржавања: корективну, адаптивну, и перфективну.

• Интервентно одржавање: реактивна модификација софтвера производа врши се након испоруке да исправи откривене проблеме.
• Адаптивно одржавање: Модификација софтверског производа обавља се након испоруке како би софтверски производ био употребљив у измењеном или променљивом окружењу.
• Перфектно одржавање: Модификација софтверског производа након испоруке за побољшање перформанси или способности снабдевања.
• Превентивно одржавање: Модификација софтверског производа након стварања за откривање и исправљање латентних грешака у софтверском производу пре него што постану ефективне грешке.

Ту је и појам пре испоруке / пре пуштања одржавања који све добре ствари које радите да смањи укупне трошкове власништва софтвера. Ствари као у складу са кодирањем стандарда који укључује софтвер одржавања циљева. Управљање спојницама и кохезија софтвера. Постизање софтверских могућности подршке циљева (САЕ ЈА 1004 ЈА 1005 и 1006 ЈА на пример). Постизање софтверских могућности подршке циљева. Имајте на уму да неке академске институције  врше истраживања квантификовати трошкова за текуће одржавање софтвера, због недостатка средстава, као што су пројектне документације и систем / Софтвер разумевања обуке и ресурса (помножите трошкове за око 1.5-2.0 где. нема дизајн расположивих података).

Утицај кључних фактора прилагођавања на одржавању (разврстаних у циљу максималног позитивног утицаја)

Не само да су грешкама склони модули проблематично, али многи други фактори могу деградирати перформансе превише. На пример, веома комплексни "шпагети код" је прилично тешко да се безбедно одржава. Веома честе ситуације које често деградирају перформансе је недостатак одговарајућих алата за одржавање, као што су праћење дефекта софтвера, управљање променама софтвера, и теста библиотека софтвера. Испод описује неке од фактора и распон утицаја на одржавања софтвера. 

Утицај кључних фактора прилагођавања на одржавању (разврстаних у циљу максималног  негативног утицаја)

^[10]

• Апликација за пензионисање
• ''Journal of Software Maintenance and Evolution: Research and Practice''
• Дугорочна подршка
• Археологија софтвера
• Одржавалац софтвера
• Развој софтвера
• Софтверски дизајн
• Дебаговање
• Софтверско распоређивање
• Анализа захтева
• Конструкција софтвера
• Тестирање софтвера
• Развојни циклус софтвера
• Софтверско инежењерство

• ISO/IEC 14764 IEEE Std 14764-2006 Software Engineering — Software Life Cycle Processes — Maintenance. 2006. ISBN 978-0-7381-4960-8. doi:10.1109/IEEESTD.2006.235774. 
• Pigoski, Thomas M. (1996). Practical Software Maintenance. New York: John Wiley & Sons. ISBN 978-0-471-17001-3. 
• Pigoski, Thomas M. Description for Software Evolution and Maintenance (version 0.5). SWEBOK Knowledge Area. 
• April, Alain; Abran, Alain (2008). Software Maintenance Management. New York: Wiley-IEEE. ISBN 978-0-470-14707-8. 
• Ramesh, Gopalaswamy; Bhattiprolu, Ramesh (2006). Software maintenance : effective practices for geographically distributed environments. New Delhi: Tata McGraw-Hill. ISBN 978-0-07-048345-3. 
• Grubb, Penny; Takang, Armstrong (2003). Software Maintenance. New Jersey: World Scientific Publishing. ISBN 978-981-238-425-6. 
• Lehman, M. M.; Belady, L. A. (1985). Program evolution : processes of software change. London: Academic Press Inc. ISBN 978-0-12-442441-8. 
• Page-Jones, Meilir (1980). The Practical Guide to Structured Systems Design. New York: Yourdon Press. ISBN 978-0-917072-17-8.