1 Tarkvara kvaliteet

Selles peatükis õpid:

• tundma tarkvara kvaliteedi mõistet
• kirjeldama tarkvaraarenduse protsessi eeldusi ja etappe
• võrdlema tarkvaraarenduse protsessi koskmudelit ja agiilset mudelit
• osalema tarkvara arendustiimi koostöös projektijuhtimiskeskkonnas

Kvaliteedi mõiste

Kuigi kõigil on mingi ettekujutus, mille poolest erineb kvaliteetne toode mittekvaliteetsest, on lähemal vaatlusel tegemist väga keerulise mõistega. Ühelt poolt seostub toote või teenuse kvaliteet selle väärtusega. Seega oleks lihtne järeldada, et kallim auto, arvuti või maja on alati kvaliteetsem kui odav, aga see pole alati tõsi.

Keskajal ja enne seda tegid kvaliteetseid relvi, ehteid, laevu ja ehitisi oma ala meistrid. Iga ese oli unikaalne ja iga meistri eesmärgiks oli säilitada oma maine, mistõttu meistri poolt oma loomingule jäetud tunnusmärk oli justkui kvaliteedi garantiiks. Uusajal tõi tööstuslik pööre kaasa masstootmise, kus ühesarnased tooted valmisid sadade töötajate panuse tulemusena keerukal tootmisliinil. Masstoodetud kaupade puhul ei suuda keegi kontrollida iga üksiku toote kvaliteeti või uskuda, et ühest tehasest tulevad alati paremad tooted kui teisest, mitte niivõrd tuntud/tunnustatud mainega tootjalt. Tehastes hakati kontrollima toodete kvaliteeti pigem pisteliselt, näiteks testides põhjalikumalt iga sajandat või tuhandendat toodet ja otsides neist tüüpilisi vigu (sellega tegelesid eraldi tehnilise kontrolli spetsialistid). Viimastel aastakümnetel on võitnud populaarsust hoopis ettevõtte enda sisemiste protsesside, mitte üksikute toodete kvaliteedi hindamine. Näiteks ISO 9001 kvaliteeditunnistuse saab ettevõte, mis suudab tõestada, et ta pidevalt parendab oma teenuseid kliendikeskselt, firmas toimib eesmärgikeskne ja inimesi kaasav juhtimine, tõenduspõhine otsustamine ja töötajate pidev koolitamine. Sellises ettevõttes on suure tõenäosusega ka kõik tooted ja teenused hea kvaliteediga. Nagu näha, on läbi ajaloo kujunenud erinevaid lähenemisi toodete ja teenuste kvaliteedi hindamisele.

Üldiselt tähendab mingi toote või teenuse (näiteks nutirakenduse) kvaliteet vastavust eelnevalt kliendi ja arendaja vahelises lepingus kirjapandud nõuetele ehk skoobile. Tarkvara analüüsi protsess keskendubki taoliste nõuete sõnastamisele ja kliendiga läbirääkimisele, millest edaspidi juhenduvad nii tarkvara arendajad kui ka testijad. Paraku soovivad kliendid kvaliteetset toodet, millel on võimalikult palju funktsionaalsusi ja seda veel võimalikult odavalt ja kiiresti. Analüütiku kohuseks on mõista ja kliendile selgitada, et neid kõiki korraga ei saa ja tuleb otsida sobivat tasakaalu projektijuhtimise kolmnurgas.

Tavaliselt on lihtsamad ja universaalsemat sorti arendusnõuded seotud tarkvara ühilduvusega (nt nutirakendus toimib nii IOS kui Android platvormil, uue ja vana nutiseadme peal), jõudluse ja töökindlusega (ei esine tõrkeid ka suure koormuse või rumalate kasutajate puhul) või turvalisusega (pahatahtlikud ründajad ei pääse kasutaja andmetele ligi). Samas on suurem osa arendusnõudeid siiski otseselt seotud tarkvara funktsionaalsustega ja nende väljaselgitamine ongi analüütiku ülesanne.

Tänapäeval üha enam suuri tehnoloogiaettevõtteid (Eestis nt Telia ja Elisa) oma kvaliteedijuhtimise protsessi üldisele parendamisele ja on taotlenud ISO 9001 tunnistuse. Sel juhul võetakse teenuse kvaliteedi hindamisel arvesse arendusprotsessi kavandamist, juhtimist, jälgimist ja dokumenteerimist üle kõigi arendusprojektide.

Tarkvaraarenduse protsess

Majade ehitamise protsess on Eestis suhteliselt rangelt reguleeritud ja koosneb paljudest sammudest, mida saab teostada ainult siis kui eelmine samm on lõpetatud. Näiteks oma kodumaja ehitama asudes peab esmalt taotlema kohalikust linna- või vallavalitsusest projekteerimistingimused, seejärel tellitakse arhitektilt nendele tingimustele vastav ehitusprojekt. Valminud ehitusprojekti põhjal väljastab omavalitsus ehitusloa ja alles siis võib ehitama asuda. Ehitamisprotsessi ja valminud maja vastavust nõuetele ja projektile jälgib pidevalt ehitusjärelvalve eest vastutav firma või spetsialist. Kui lõpuks on valminud maja vastavust kõigile nõuetele kontrollinud nii omavalitsus kui päästeamet, siis väljastatakse kasutusluba ja võib sisse kolida.

Sarnaselt majaehitusega toimis veel mõne aastakümne eest ka tarkvaraarendus. Esmalt kehtestati projekteerimistingimused, siis koostas inseneribüroo tarkvara-arendusplaani ja pani selles paika arendusprotsessi etapid ja hindamiskriteeriumid. Teise arendusetapi juurde enne ei asutud kui esimene oli kontrollitud ja nõuetele vastavaks kuulutatud. Sellisel viisil võttis tarkvaraarendus suhteliselt palju aega ning suuremahulisemaks ja keerukamaks muutuvate infosüsteemide lähtekoodist oli üha raskem vigu üles leida. Ka kasutajad polnud rahul sellisel moel arendatud tarkvaraga, sest neid arendusprotsessi ei kaasatud.

Sellist traditsioonilist lähenemist tarkvaraarendusele nimetatakse koskmudeliks (i.k. waterfall model), kuna see visuaalselt meenutab ka näiteks Tallinnas Kosmose kino ees paiknevat purskkaevu või kuulsat Trevi purskkaevu Roomas, milles vesi valgub kolmandasse basseini alles siis kui esimene ja teine täis saanud on. Traditsioonilises koskmudelil põhinevas tarkvaraarendusprotsessis ei pöördutud tagasi nõuete muutmise juurde sageli ka siis kui programmeerimise või testimise etapis leiti nõuete osas probleeme.

10-15 aastat tagasi hakkasid väikesed tarkvarafirmad kasutama uudseid lähenemisi tarkvara-arendusele, mis võimaldavad juba esimeses arendusetapis kasutajatele loodava süsteemi esialgset prototüüpi tutvustada ning seeläbi kasutajatelt tagasisidet ja arendusettepanekuid koguda. Selliseid tarkvara-arendusmeetodeid nimetatakse agiilseteks ehk väledateks (i.k. agile development). Enamus välemeetodeid koosneb üldjuhul intensiivsetest arendustsüklitest. Iga tsükkel ehk sprint kestab vaid 1-2 nädalat, sel on oma kitsas eesmärk (rakenduse järgmise versiooni väljalase) ja selles läbitakse kiirendatult nii planeerimise, disaini, arendus kui testimise etapp. Eesmärgiks on anda võimalikult kiiresti kasutajatele katsetamiseks minimaalsete võimalustega prototüüp (i.k. Minimal Viable Product, MVP).

Lisalugemist: uuri lähemalt, kuidas toimib agiilne arendus XP meetodil Eesti tarkvarafirmas Codeborn.

Näide välearenduse kohta: Scrum

Scrum on üks populaarsematest välearendusmeetodeist Eesti tarkvaraarenduse maastikul. Scrumi meeskonna tööd juhib Scrum Master, lisaks arendajatele, disainerile ja analüütikule on tiimi kaasatud ka tooteomanik (kes võib olla tellija esindaja). Scrumi sprindi alguses pannakse paika sprindi eesmärk ja kava, mille põhjal sõnastatakse sprindi konkreetsed ülesanded (sprindi skoop, mis on väike osa toote skoobist). Sprindi käivitudes tehakse igal hommikul kiirülevaade erinevate tiimiliikmete poolt eile tehtud asjadest ja tänastest plaanidest. Sprint lõpeb kui kõik skoobis kavandatu on valmis ja kokkuvõte tehtud. Tavaliselt tehakse enne järgmise sprindi kavandamist veel ka tagasivaade möödunud sprindile (retrospektiiv), mille käigus analüüsitakse Scrumi meeskonna toimimist ja sprindi korralduse parendamise võimalusi. Scrumi meeskonna omavaheline suhtlus ja kõigi tegevuste dokumenteerimine on ülioluline sprindi õnnestumiseks, selleks kasutatakse erinevaid veebipõhiseid projektijuhtimise platvorme (Trello, Asana, Jira, Confluence).

Rühmatööülesanne

1. Moodustage 3-4 liikmeline tiim
2. Tiimi ülesandeks on kavandada sprint teie kooli kodulehe kujunduse ja sisu uuendamiseks.
3. Tehke Trello keskkonnas kasutajakontod ja jagage tiimiliikmete vahel ülesanded esimese sprindiga seoses: kooli kodulehe visuaalne kujundus, kasutajaliidese struktuur menüüd, sisu (sh seadusega nõutud info ja piirangud seoses isikuandmete kaitsega), veebilehe kasutajate rollid ja õigused, heade eeskujude leidmine jne.
4. Mängige läbi mini-sprint, mille raames iga tiimiliige saab vähemalt ühe ülesande ja selle ka ära teeb. Seejärel viige läbi sprindi kokkuvõte, pannes kirja sprindi tulemusena tehtud asjad.
5. Dokumenteerige sprindi kokkuvõte ja tagasivaade, esitage see teisele tiimile hindamiseks ja hinnake ise teise tiimi kokkuvõtet sprindist.

Kasutatud allikad:

https://eopearhiiv.edu.ee/e-kursused/eucip/juhtimine/521_kuidas_on_omavahel_seotud_aeg_kulud_ja_kvaliteet.html)