Type a search term to find related articles by LIMS subject matter experts gathered from the most trusted and dynamic collaboration tools in the laboratory informatics industry.
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]
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:
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]
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 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.
Selles jaotises kirjeldatakse kuut tarkvarahooldusprotsessi järgmiselt:
Hoolduse meeskonnale on omased rida protsesse, tegevusi ja tavasid, näiteks:
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:
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% |
LIMS forum content by LIMS forum members is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. Based on a work at www.limsforum.com.
