# Tarkvarahooldus

**Tarkvarahooldus** on etapp tarkvara elutsüklis, mille käigus toimub tarnitud tarkvaratoote modifitseerimine eesmärgiga parandada vigu, jõudlust või muid näitajaid.

Hoolduse kohta on levinud arusaam, et see hõlmab ainult defektide parandamist. Samas on uuringud näidanud, et üle 80% hooldustöödest tegeleb mittekorrigeerivate toimingutega. Uuemad uuringud on hinnanud veaparanduste osakaaluks 21%.

## Ajalugu

Tarkvarahooldust ja süsteemide arengut käsitles esimesena Meir M. Lehman 1969. aastal. Kahekümne aasta jooksul viis tema uurimistöö Lehmani seaduste väljatöötamiseni (Lehman 1997). Tema uurimistöö peamisteks järeldusteks on, et hooldus on tõepoolest evolutsiooniline areng ja hooldusotsuste tegemisel on abiks, kui saadakse aru, mis toimub süsteemidega (ja tarkvaraga) aja möödudes. Lehman näitas, et süsteemid arenevad aja jooksul edasi. Nende arenedes muutuvad nad üha keerukamaks, kui keerukuse vähendamiseks ei võeta ette mõnda toimingut, tarkvara korral näiteks koodi refaktoriseerimist.

1970. aastate lõpus avaldasid Lientz ja Swanson kuulsa ja laialdaselt viidatud uuringu, mis tõstis esile, et väga suure osa elutsükli kuludest moodustavad kulud hooldusele. Nad liigitasid hooldustegevused nelja klassi:

* Kohandav hooldus – süsteemi muutmine, et tulla toime muutustega tarkvara keskkonnas (DBMS, OS)
* Täiustav hooldus – uute või muudetud kasutajanõuete realiseerimine, mis seisnevad tarkvara funktsionaalsuse täiustamises
* Korrigeeriv hooldus – kasutajate leitud vigade diagnoosimine ja parandamine
* Ennetav hooldus – tarkvara hooldatavuse või töökindluse suurendamine, et tulevikus probleeme vältida

Uuring näitas, et umbes 75% hooldustöödest oli seotud kahe esimese tüübiga ja vigade parandamisele kulus umbes 21%. Paljud hilisemad uuringud näitavad sarnast jaotust. Uuringud näitavad ka, et lõpptarbijate panus uute nõuete kohta andmete kogumisse ja analüüsi on ülioluline. Puudujäägid selles etapis on tarkvara arendamise ja hoolduse ajal tekkivate probleemide peamine põhjus. Tarkvara hooldus on oluline, kuna sellele kulub suur osa kogu elutsükli kuludest ning suutmatus tarkvara kiiresti ja usaldusväärselt uuendada tähendab, et sellega seotud ärivõimalused kaovad.

## Tarkvara hoolduse olulisus

Peamised tarkvarahoolduse probleemid on nii juhtimislikud kui ka tehnilised. Juhtimise põhiküsimused on järgmised: kliendi prioriteetidega arvestamine, personali komplekteerimine, hooldust tegeva organisatsiooni määratlemine, kulude hindamine. Peamised tehnilised probleemid on: valdkonna ja süsteemi piiratud mõistmine, mõjuanalüüs, testimine, hooldatavuse mõõtmine.

Tarkvara hooldus on väga lai tegevus, mis hõlmab vigade parandamist, funktsionaalsuse täiustamist, vananenud funktsionaalsuse eemaldamist ja optimeerimist. Kuna muutused on vältimatud, tuleb välja töötada mehhanismid muutuste mõju hindamiseks, kontrollimiseks ja muudatuste tegemiseks.

Seega, igasugust tööd, mida tehakse tarkvara muutmiseks pärast selle töölerakendamist, peetakse hoolduseks. Selle töö eesmärgiks on hoida tarkvara väärtust läbi selle kasutamise aja. Tarkvara väärtust saab ka tõsta, kui laiendada selle kasutajate hulka, tulla vastu täiendavatele nõuetele, lisada kasutajamugavust ja efektiivsust või võtta kasutusele uuemaid tehnoloogiaid. Kui tarkvara arendus võib kesta 1–2 aastat, siis hooldus võib kesta kuni 20 aastat.

## Tarkvara hoolduse planeerimine

Tarkvara elutsükli lahutamatu osa on selle hooldamine, mis nõuab tarkvaraarenduse ajal täpse hooldusplaani koostamist. See peaks määratlema, kuidas kasutajad taotlevad muudatusi või teatavad probleemidest. Eelarve peaks sisaldama ressursi- ja kuluprognoose. Süsteemi iga uue funktsiooni ja selle kvaliteedieesmärkide väljatöötamiseks tuleks võtta vastu uus otsus. Tarkvara hooldus, mis võib kesta 5–6 aastat (või isegi aastakümneid) pärast arendusprotsessi, nõuab tõhusat kava, mis käsitleks tarkvarahoolduse ulatust, juurutamisprotsessi kohandamist, elutsükli kulude hinnanguid ja hooldustööde teostaja määramist. Standardite nõuetekohase jõustamise meetodite valimine on keeruline ülesanne juba tarkvaraarenduse varases staadiumis, kuna ei ole asjassepuutuvate huvigruppide poolt piisavalt tähtsustatud.

## Tarkvara hooldusprotsessid

Selles jaotises kirjeldatakse kuut tarkvarahooldusprotsessi järgmiselt:

1. **Rakendusprotsess** sisaldab tarkvara ettevalmistamist ja üleminekutoiminguid, nagu hooldusplaani koostamine ja loomine, valmistumine arenduse käigus tuvastatud probleemide käsitlemiseks ja toote konfiguratsiooni haldamine.
2. **Probleemide ja muudatuste analüüsi protsess**, mis viiakse läbi pärast rakenduse üleandmist hooldusgrupi vastutusalasse. Hooldusprogrammeerija peab igat taotlust analüüsima, selle kinnitama (koos olukorra taasesitamisega) ja kontrollima selle õigsust, uurima seda ja pakkuma välja lahenduse, dokumenteerima taotluse ja lahenduse ettepaneku ning lõpuks hankima kõik muudatuste rakendamiseks vajalikud volitused.
3. **Muudatuse realiseerimise protsess**, mis keskendub tarkvara muutmisele soovitud viisil.
4. **Modifikatsiooni vastuvõtmise protsess**, mille käigus vaadatakse tehtud muudatused üle koos taotluse esitanud isikuga, et veenduda tehtud muudatuste korrektsuses.
5. **Migratsiooniprotsess** (näiteks platvormidele vahetus) on erandlik ja ei kuulu igapäevaste hooldusülesannete hulka. Kui tarkvara tuleb teisaldada teisele platvormile ilma funktsionaalsust muutmata, kasutatakse seda protsessi ja tõenäoliselt määratakse seda tööd tegema hooldusprojekti meeskond.
6. **Tarkvara tagandamise protsess** on hooldusprotsess, mida igapäevaselt ei esine ja mille eesmärgiks on tarkvara kasutusest eemaldamine või väljavahetamine.

Hoolduse meeskonnale on omased rida protsesse, tegevusi ja tavasid, näiteks:

* Üleminek: kontrollitud ja koordineeritud tegevuste jada, mille käigus süsteem antakse arendajalt järk-järgult üle hooldusettevõttele;
* Hooldusteenuste pakkujate poolt läbi räägitud teenusetaseme lepingud (SLA) ja spetsialiseeritud (domeenipõhised) hoolduslepingud;
* Muutmistaotluste ja probleemide raporti infolaud: probleemide käsitlemise protsess, mida hooldajad kasutavad saadud taotluste tähtsuse järjekorda seadmiseks, dokumenteerimiseks ja suunamiseks.

## Hoolduskategooriad standardis ISO / IEC 14764

E.B. Swanson määratles algselt hoolduse kolm kategooriat: korrigeeriv, kohandav ja täiustav. **IEEE 1219** standard asendati 2010. aasta juunis dokumendiga **P14764** . Neid on hiljem uuendatud ja ISO / IEC 14764 sisaldab järgmiseid kategooriaid:

* Korrigeeriv hooldus: pärast tarkvaratoote tarnimist teostatud reaktiivne modifitseerimine avastatud probleemide kõrvaldamiseks.
* Kohandav hooldus: pärast tarkvaratoote tarnimist läbi viidav modifitseerimine selleks, et tarkvaratoode oleks kasutatav muutunud või muutuvas keskkonnas.
* Täiustav hooldus: pärast tarkvaratoote tarnimist tehtav modifitseerimine toimivuse või hooldatavuse parandamiseks.
* Ennetav hooldus: pärast tarkvaratoote tarnimist tehtav modifitseerimine selleks, et tuvastada ja parandada tarkvaratoote varjatud vigu enne, kui need muutuvad tegelikeks tõrgeteks.

## Hooldusfaktorid

Peamiste faktorite mõju hooldusele (sorteeritud maksimaalse positiivse mõju järjekorras):

| Hooldusfaktorid | Mõju, % |
| --- | --- |
| Hooldusspetsialistid | 35 |
| Suur personali kogemus | 34 |
| Tabelipõhised muutujad ja andmed | 33 |
| Lähtekoodi madal keerukus | 32 |
| Y2K ja spetsiaalsed otsingumootorid | 30 |
| Lähtekoodi ümberkorraldamise tööriistad | 29 |
| Ümberprojekteerimise tööriistad | 27 |
| Kõrgetasemelised programmeerimiskeeled | 25 |
| Pöördprojekteerimise tööriistad | 23 |
| Keerukuse analüüsimise tööriistad | 20 |
| Defektide jälgimise tööriistad | 20 |
| Y2K massivärskenduse spetsialistid | 20 |
| Automatiseeritud muudatuste juhtimise tööriistad | 18 |
| Tasustamata ületunnid | 18 |
| Kvaliteedimõõtmised | 16 |
| Lähtekoodi ametlikud ülevaatused | 15 |
| Regressioonitestide teegid | 15 |
| Suurepärane reageerimise aeg | 12 |
| Iga-aastane koolitus > 10 päeva | 12 |
| Kõrge juhtimiskogemus | 12 |
| HELP laua automatiseerimine | 12 |
| Vigadeta moodulite puudumine | 10 |
| Vigadest teatamine veebis | 10 |
| Tootlikkuse mõõtmine | 8 |
| Suurepärane kasutusmugavus | 7 |
| Kasutaja rahulolu mõõtmine | 5 |
| Meeskonna kõrge moraal | 5 |

Mitte ainult vigased moodulid pole tülikad, vaid ka paljud muud tegurid võivad halvendada jõudlust. Näiteks on väga keerulist spagetikoodi on üsna raske turvaliselt käsitleda. Väga levinud olukord, mis sageli jõudlust halvendab, on sobivate hooldustööriistade, näiteks defektide jälgimistarkvara, muudatuste haldamise tarkvara ja testide teegi tarkvara puudumine. Allpool kirjeldame mõnda tegurit ja selle mõju ulatust tarkvara hooldusele.

Peamiste faktorite mõju hooldusele (sorteeritud maksimaalse negatiivse mõju järjekorras):

| Hooldusfaktorid | Mõju, % |
| --- | --- |
| Vigadega moodulid | −50 |
| Sissekirjutatud muutujad ja andmed | −45 |
| Personali kogenematus | −40 |
| Suur lähtekoodi keerukus | −30 |
| Spetsiaalsete otsingumootorite Y2K toe puudumine | −28 |
| Käsitsi läbi viidavad muudatuste juhtimise meetodid | −27 |
| Madala taseme programmeerimiskeeled | −25 |
| Defektide jälgimise tööriistade puudumine | −24 |
| Y2K "massiuuenduse" spetsialistide puudumine | −22 |
| Kehv kasutusmugavus | −18 |
| Kvaliteedimõõtmiste puudumine | −18 |
| Hooldusspetsialistide puudumine | −18 |
| Kehv reageerimisaeg | −16 |
| Lähtekoodi kontrollimiste puudumine | −15 |
| Regressioonitestide teegid puuduvad | −15 |
| Puudub kasutajatoe automatiseerimine | −15 |
| Veebis puudustest teatamise puudumine | −12 |
| Juhtimiskogemuse puudumine | −15 |
| Lähtekoodi ümberkorraldamise tööriistade puudumine | −10 |
| Iga-aastaste koolituste mittetoimumine | −10 |
| Ümberprojekteerimise tööriistade puudumine | −10 |
| Pöördprojekteerimise tööriistade puudumine | −10 |
| Keerukuse analüüsimise tööriistade puudumine | −10 |
| Tootlikkuse mõõtmise puudumine | −7 |
| Kehv meeskonnamoraal | −6 |
| Kasutaja rahulolu mõõtmiste puudumine | −4 |
| Tasustamata ületundide puudumine | 0 |

## Viited