Одржавање софтвера у софтверском инжењерству је модификација софтверског производа након стварања да исправи грешке, да би побољшали перформансе или друге атрибуте..[1][2]
Заједничка перцепција одржавања је да се само укључује везивање недостатака. Међутим, једна студија показала је да се преко 80% напора одржавања користи за не-корективне акције.[3] Ово мишљење су овековечили корисници који подносе проблеме јављања да је у стварности функционалност побољшања у систему. Новије студије ставиле баг-причвршћивање ближе 21%.[4]
За одржавање софтвера и еволуцију система се прво обратио Меир М. Леман 1969. У периоду од двадесет година, његова истраживања довела су до формулисања Леман закона (Леман 1997). Кључни налази његовог истраживања укључују да је одржавање заиста еволутивни развој и да одлуке одржавања су помагале разумевању шта се дешава са системима (и софтвера) током времена. Леман је показао да је систем наставио да се развија током времена. Док еволуирају, они расту више комплексно, осим ако се нека акција као што је рефакторисање кода узима да се смањи сложеност.
У касним 1970-им, познато и широко цитирано студијско истраживање Лиенц и Свансон, изложило је веома висок део трошкова животног циклуса који се утрошио на одржавање. Активности одржавања су подељене у четири класе:
- Адаптивна - мењање система да се носи са променама у окружењу софтвера (DBMS, OS)[5]
- Перфектна - имплементација нових или измењених потреба корисника које се тичу функционалног побољшања софтвера
- Корективна - дијагнозе и исправљање грешака, евентуално оне које пронађу корисници[5]
- Превентивна - повећање одржавања софтвера и поузданости како би се спречили проблеми у будућности[5]
Истраживање је показало да је око 75% од напора одржавања било на прва два типа, и исправљање грешака конзумира око 21%. Многи каснији студији показују сличну величину проблема. Студије показују да допринос крајњег корисника је од кључне важности током новог прикупљања података услова и анализе. И то је био главни узрок проблема током еволуције софтвера и одржавање. Дакле, одржавање софтвера је важно јер троши велики део укупних трошкова животног циклуса и такође немогућности да брзо и поуздано промените софтвер и значи да су пословне могућности изгубљене. [6] [7] [8]
Кључна питања одржавања софтвера су и менаџерска и техничка. Кључна питања управљања су: усклађивање са приоритетима клијената, особља, које организација нема одржавања, процена трошкова. Кључна техничка питања су: ограничено разумевање, анализа утицаја, тестирање, мерење одржавање.
Одржавање софтвера је веома широка активност која укључује корекцију грешака, побољшања способности, брисање застарелих могућности и оптимизацију. Због промена је неизбежна, морају бити успостављени механизми за евалуацију, контролу и прављењем измена.
Дакле, све што је урађено да промени софтвер након што је у функцији сматра се радовима на одржавању. Циљ је да се очува вредност софтвера током времена. Вредност се може побољшати проширењем базе клијената, испуњавањем додатних захтева, постаје лакши за коришћење, ефикаснији и запошљава новију технологију. Одржавање може спан за 20 година, док развој може бити 1-2 година.
Саставни део програма је одржавање, што захтева прецизни план одржавања да буде урађен у току развоја софтвера. То би требало да прецизира колико ће корисници захтевати измене или пријавити проблем. Буџет треба да обухвати ресурсе и трошкове. Нова одлука треба да буде упућена у развоју сваког новог система функција и циљева квалитета. Одржавање софтвера, који може трајати 5-6 година (или чак деценија) након процеса развоја, позива на ефективан план који може обратити обим одржавања софтвера, занат на пост испоруке / распоређивања процеса, именовање ко ће обезбедити одржавање и процену трошкова животног циклуса. Избор правилног спровођења стандарда је прави изазов од ране фазе софтверског инжењерства која није добила дефинитиван значај од стране заинтересованих страна.
Ово поглавље описује шест процеса одржавања софтвер као:
- Процес имплементације садржи софтверске припреме и транзиционе активности, као што су концепције и стварање плана одржавања; припрема за руковање проблема идентификованих током развоја; и праћење о управљању конфигурацијом производа.
- Процес анализе проблема и модификација, која се извршава након примене постала је одговорност групе одржавања. Програмер одржавање мора да анализира сваки захтев, потврди (за репродукцију ситуације) и провери његову ваљаност, истражи га и предложи решење, документује захтев и предлог решења, и коначно, добије сва потребна овлашћења да примени измене.
- Процес с обзиром на примену саме модификације.
- Прихватање процеса модификације, потврђујући модификован рад са појединцем који је поднео захтев како би били сигурни да је модификација безбедно решење.
- Процес миграције (платформа миграције, на пример) је изузетан, и није део свакодневних задатака одржавања. Ако програм мора бити промењен на другу платформу, без било какве промене у функционалности, овај процес ће се користити и пројекат одржавања тима ће вероватно бити додељен овом задатаку.
- Коначно, последњи процес одржавања, такође догађај који се не јавља свакодневно, је пензионисање комада софтвера.
Постоји велики број процеса, активности и праксе које су јединствене за одржаваоца, на пример:
- Транзиција: контролисана и координирана секвенца активности током којих је систем пренесен прогресивно од програмера до одржаваоца;
- Service Level Agreements (SLAs) и специјализованог (Домаин-Специфиц) уговора о одржавању договорене са маинтаинерс;
- Измена захтева и Проблем пријаве помоћи : процес проблема руковања користи одржаваоца као приоритет, документа и путем захтевима које примају;
Е. Б. Свансон, првобитно идентификоване три категорије одржавања: корективну, адаптивну, и перфективну.
[9]
Оне су од тада ажуриране и ISO/IEC 14764 представља:
- Интервентно одржавање: реактивна модификација софтвера производа врши се након испоруке да исправи откривене проблеме.
- Адаптивно одржавање: Модификација софтверског производа обавља се након испоруке како би софтверски производ био употребљив у измењеном или променљивом окружењу.
- Перфектно одржавање: Модификација софтверског производа након испоруке за побољшање перформанси или способности снабдевања.
- Превентивно одржавање: Модификација софтверског производа након стварања за откривање и исправљање латентних грешака у софтверском производу пре него што постану ефективне грешке.
Ту је и појам пре испоруке / пре пуштања одржавања који све добре ствари које радите да смањи укупне трошкове власништва софтвера. Ствари као у складу са кодирањем стандарда који укључује софтвер одржавања циљева. Управљање спојницама и кохезија софтвера. Постизање софтверских могућности подршке циљева (САЕ ЈА 1004 ЈА 1005 и 1006 ЈА на пример). Постизање софтверских могућности подршке циљева. Имајте на уму да неке академске институције врше истраживања квантификовати трошкова за текуће одржавање софтвера, због недостатка средстава, као што су пројектне документације и систем / Софтвер разумевања обуке и ресурса (помножите трошкове за око 1.5-2.0 где. нема дизајн расположивих података).
Утицај кључних фактора прилагођавања на одржавању (разврстаних у циљу максималног позитивног утицаја)
| Фактори одржавања | Плус опсег |
|---|---|
| Специјалисти одржавања | 35% |
| Високо искуство особља | 34% |
| Променљиве и подаци табеле | 33% |
| Ниска сложеност базе кода | 32% |
| Y2K и специјални претраживачи | 30% |
| Алати за реструктурирања кода | 29% |
| Реинжењерски алати | 27% |
| Програмски језици на високом нивоу | 25% |
| Алати за инжењерски преокрет | 23% |
| Алати за сложеност анализе | 20% |
| Алати дефекта праћења | 20% |
| Y2K “Масовна ажурирања” специјалисти | 20% |
| Алати за аутоматску контролу промене | 18% |
| Неплаћени прековремени рад | 18% |
| Мерења квалитета | 16% |
| Формална база кода инспекције | 15% |
| Регресија тест библиотеке | 15% |
| Одлично време одзива | 12% |
| Годишња обука> 10 дана | 12% |
| Високо искуство менаџмента | 12% |
| Шалтер информација аутоматизације | 12% |
| Нема модула склоних грешкама | 10% |
| У продаји извештавање дефекта | 10% |
| Продуктивност мерења | 8% |
| Одлична лакоћа употребе | 7% |
| Мерења задовољства корисника | 5% |
| Високи тимски морал | 5% |
| Збир | 503% |
Не само да су грешкама склони модули проблематично, али многи други фактори могу деградирати перформансе превише. На пример, веома комплексни "шпагети код" је прилично тешко да се безбедно одржава. Веома честе ситуације које често деградирају перформансе је недостатак одговарајућих алата за одржавање, као што су праћење дефекта софтвера, управљање променама софтвера, и теста библиотека софтвера. Испод описује неке од фактора и распон утицаја на одржавања софтвера.
Утицај кључних фактора прилагођавања на одржавању (разврстаних у циљу максималног негативног утицаја)
| Фактори одржавања | Минус опсег |
|---|---|
| Модули склони грешкама | -50% |
| Уграђене променљиве и подаци | -45% |
| Неискуство особља | -40% |
| Висока комплексност кода | -30% |
| Нема Y2K посебних претраживача | -28% |
| Ручне методе контроле промена | -27% |
| Програмски језици ниског нивоа | -25% |
| Нема алата за праћење дефекта | -24% |
| Нема Y2K "Масовна ажурирања" | -22% |
| Слаба једноставност употребе | -18% |
| Неквалитет мерења | -18% |
| Нема специјалиста за одржавање | -18% |
| Лоше време одзива | -16% |
| Нема кода инспекције | -15% |
| Нема регресије теста библиотеке | -15% |
| Нема шалтера информација аутоматизације | -15% |
| Нема онлајн извештавање дефекта | -12% |
| Менаџмент искуство | -15% |
| Нема алати за реструктурирање кода | -10% |
| Не годишња обука | -10% |
| Нема алата реинжињеринга | -10% |
| Нема алата за инжењерски преокрет | -10% |
| Нема алата за сложеност анализе | -10% |
| Не мерење продуктивности | -7% |
| Слаб тимски морал | -6% |
| Нема мерења задовољства корисника | -4% |
| Не неплаћени прековремени рад | 0% |
| Збир | -500% |
- Апликација за пензионисање
- ''Journal of Software Maintenance and Evolution: Research and Practice''
- Дугорочна подршка
- Археологија софтвера
- Одржавалац софтвера
- Развој софтвера
- Софтверски дизајн
- Дебаговање
- Софтверско распоређивање
- Анализа захтева
- Конструкција софтвера
- Тестирање софтвера
- Развојни циклус софтвера
- Софтверско инежењерство
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
