Tarkvarahooldus
Tarkvara hooldus on etapp tarkvara elutsüklis, mille käigus toimub tarnitud tarkvaratoote modifitseerimine eesmärgiga parandada vigu, jõudlust või muid näitajaid.[1]
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.[2] Uuemad uuringud on hinnanud veaparanduste osakaaluks 21%.[3]
Ajalugu muuda
Tarkvara hooldust ja süsteemide arengut käsitles esmakordselt 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) [4]
- 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.[5][6][7]
Tarkvara hoolduse olulisus muuda
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 muuda
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 muuda
Selles jaotises kirjeldatakse kuut tarkvarahooldusprotsessi järgmiselt:
- Rakendusprotsess sisaldab tarkvara ettevalmistamist ja üleminekutoiminguid, nagu hooldusplaani koostamine ja loomine, ettevalmistumine arenduse käigus tuvastatud probleemide käsitlemiseks ja toote konfiguratsiooni haldamine.
- 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.
- Muudatuse realiseerimise protsess, mis keskendub tarkvara muutmisele soovitud viisil.
- Modifikatsiooni vastuvõtmise protsess, mille käigus vaadatakse tehtud muudatused üle koos taotluse esitanud isikuga, et veenduda tehtud muudatuste korrektsuses.
- 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.
- 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 muuda
E.B. Swanson määratles algselt hoolduse kolm kategooriat: korrigeeriv, kohandav ja täiustav.[8] IEEE 1219 standard asendati 2010. aasta juunis dokumendiga P14764 .[9] 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 muuda
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 muuda
- ↑ "ISO/IEC 14764:2006 Software Engineering – Software Life Cycle Processes – Maintenance". Iso.org. 17. detsember 2011. Vaadatud 13.08.2019.
- ↑ Pigoski, Thomas M., 1997: Practical software maintenance: Best practices for managing your software investment. Wiley Computer Pub. (New York)
- ↑ Eick, S., Graves, T., Karr, A., Marron, J., and Mockus, A. 2001. Does Code Decay? Assessing Evidence from Change Management Data. IEEE Transactions on Software Engineering. 27(1) 1–12.
- ↑ Software Maintenance and Re-engineering, CSE2305 Object-Oriented Software Engineering
- ↑ Lientz B., Swanson E., 1980: Software Maintenance Management. Addison Wesley, Reading, MA
- ↑ Lehman M. M., 1980: Program, Life-Cycles and the Laws of Software Evolution. In Proceedings of IEEE, 68, 9,1060–1076
- ↑ Penny Grubb, Armstrong A. Takang, 2003: Software Maintenance: Concepts and Practice. World Scientific Publishing Company
- ↑ "E. Burt Swanson, The dimensions of maintenance. Proceedings of the 2nd international conference on Software engineering, San Francisco, 1976, pp 492 — 497". Portal.acm.org. DOI:10.1145/359511.359522. Vaadatud 13.08.2019.
- ↑ Status of 1219–1998 by IEEE Standards