Targo tarkvara

Tarkvaratootmise põhiteoreem on ambitsioonikas pealkiri, aga tegemist on niivõrd fundamentaalse asjaoluga, et väiksemat nimetust pole ka mõtet kasutada. Pealegi, kui pokkeril võib oma põhiteoreem olla, olgu siis ka tarkvaral.
Sõnastus siis:

Vea parandamise hind kasvab aja möödudes.

Lihtne ja elementaarne, eks? Samas on praktiliselt kõik ebaõnnestunud tarkvaraprojektid võimalik taandada põhiteoreemi mingis vormis eiramisele ja enamik tarkvarametodoloogiaid tegelevad põhiteoreemi tagajärgede pehmendamisega.
Enamik tarkvaraga tegelejaid mõistab seaduspärasuse olemust intuitiivselt, kuid ei pruugi taibata selle täit ulatust. Näiteks programmeerija ei pruugi mõista, et juba analüüs ja disain, millel tema kood põhineb, on vigased ja nende parandamiseks tuleb suur osa koodist ümber kirjutada. Projektijuht ei taipa jällegi, et väga tähtis on värskelt kirjutatud koodile kohe ka mõned testid kirjutada, et vead saaksid parandatud, kui programmeerija peas kõik veel värskelt meeles on. Kasutajapoolsest mittetaipamisest saab juba eraldi artikli kirjutada

Sõna “maksumuse” definitsioonist: Tarkvara maksumuse all pean ma üldjuhul silmas inimtundide arvu, mis sellesse on pandud, olgu siis analüüsi, kodeerimise, parandamise, testimise või muuna. Efektiivne projektihaldamine minimiseerib seda tegelikku maksumust ja püüab ülesande lahendada minimaalse energiakuluga. See kehtib nii vaba kui ka kommertstarkvara puhul. Hind, mida tegelikult kliendilt küsitakse, on juba teine teema.

Kõige hullemad näited tarkvaratootmise põhiteoreemi eiramisest on enamasti seotud tellija vajaduste puuduliku tundmaõppimisega.

• Näide 1: Kurikuulsamaid näiteid ebaõnnestunud tarkvaraprojektidest oli FBI Virtual Case File süsteem. Projektiga tegelejad rajasid süsteemi lähtudes tavaliste kontoritöötajate kogemustest, inimestel on tööjaam, kohtvõrk, andmed jooksevad kõik andmebaasist jne. Ainult et FBI agendid ei ole tavalised kontoritöötajad, nad liiguvad “objektidel” ringi ja neil on vaja andmeid kaasa võtta ning ka offline’is sisestada. Ja keegi ei tulnud ka selle peale enne, kui süsteemi juurutama hakati. Kui palju võtab aega olemasolevale süsteemile turvaliste offline-võimaluste juurdepookimine, võib igaüks ise nuputada, kuid antud projekt katkestati (selle ja paljude, paljude muude probleemide tõttu) pärast 170 miljoni dollari maksumaksja raha kulutamist. Kui vajadused oleks tuvastatud õigeaegselt, oleks kogu süsteemi loodud hoopis teistel alustel ning tohutu hulk aega oleks jäänud raiskamata.
• Näide 2, natuke lähemalt: analüütik Albert (nimed ja muud konkreetsed faktid siin ja edaspidi muudetud, kuid põhinevad sellegipoolest tõestisündinud seikadel) Eesti tuntud tarkvarafirmast Joostes Marss vestles klient Kustaviga Hulkuvate Kasside Riiklikust Inspektsioonist, et luua infosüsteem kasside nummerdamiseks. Kustav oli igati asjalik ja pädev, rääkis, et on vaja seda ja seda, joonistas isegi tahvlile skeeme jne, aga Albert ei pannud mitte kõike juttu kirja, vaid eeldas, et oh, see on kõik lihtne, teeme ära. Projektijuht Joosep oli äsja lõpetanud majanduskooli ega tulnud selle peale, et Alberti tööd üle vaadata. Programmeerija Peeter aga, ilma konkreetse spetsifikatsioonita peale selle, et “see on kõik lihtne, tee ära”, oli aga teisel arvamusel lihtsusest ja loodu sarnases kliendi joonisega nagu raudteejaam lennujaamaga, pealtvaadates nagu sarnane, aga olemuselt midagi hoopis muud. Eesti riik on õnneks leplik ja asi tehti suurema pahanduseta ringi (ringitegemise kulu siis ka sarnane raudteejaama lennujaamaks ümber ehitamise kuluga). Parandamise hind oleks võinud olla mitu suurusjärku väiksem, kui analüütiku viga oleks korraliku projektijuhtimise poolt kinni püütud ja Albert kliendi juurde tagasi saadetud korralikke märkmeid tegema enne, kui Peeter ridagi koodi oleks jõudnud kirjutada.
• Metoodiline lahendus mõlema näite puhul: spetsifikatsioonide ülevaatamine, milles osalevad nii kliendi- kui ka tööettevõtjapoolsed projektijuhid, lõppkasutaja ja tehniliste teostajate esindajad.

Muidugi pole analüütikud ainsad, kes vigu teevad, programmeerijate elus võib pisikesi näiteid põhiteoreemi rakendamisest leida igal sammul:

• Näide 3: Peeter kirjutas just uue protseduuri ja vajutas nuppu Compile. Samal ajal küsis teine programmeerija, Priit, temalt, mis vahe on SendMessage‘il ja PostMessage‘il. Seletuse lõpetanud, leidis Peeter, et kompilaator oli leidnud tema koodist kolm viga, kuid kuna värskelt kirjutatud kood oli Peetri lühiajalisest mälust välja uhutud, kulus tal lisaks veel kümme minutit, et meelde tuletada, mida ta ennist oli tegemas ja vead parandada. Näide on eelmistega võrreldes mikroskoopiline, aga kui selliseid väikesi segajaid, mis takistavad programmeerijal vigade kohest parandamist, tuleb päevas ette palju, kahaneb tema produktiivsus mitukümmend protsenti.
• Metoodiline lahendus: töökeskkond, kus programmeerijal on võimalik vaikselt keskenduda, ja töökultuur, kus inimestel on kombeks lihtsatele küsimustele ise kiirelt MSDNist vastuseid leida.

• Näide 4: Priit leiab, et tema kirjutatav uus hulkuvate kasside andmebaasipäring teeb enamvähem sedasama, mis hulkuvate koerte päring, ja teeb kiire copy/paste. Päring on aga keeruline ja ühes kohas jääb “koer” kogemata “kassiga” asendamata, tekitades olukorra, kus varjupaigas pannakse marutaudis rotveiler Raudhamba asemel magama hoopis pärsia kass Viktooria, kellele omanik järgmisel päeval järele pidi tulema. Lisaks tarkvaraparandusega seotud kulule oleme jõudnud kahjudeni muudes valdkondades.
• Metoodiline lahendus: iga rida koodi vaadatakse kellegi teise poolt üle. Tihti juhtub, et kui inimene vaatab omaenda kirjutatud teksti, libiseb ta detailidest alateadlikult üle, aga teisele inimesele torkab kohe silma, kuhu koer on maetud. Koodiülevaatusele kulunud aeg: 30 minutit, vea parandamisele kulunud aeg: 3 minutit. Vea parandusele ja kliendi juures paigaldamisele kulunud aeg, kui ülevaatust ei toimunud: mitu inimpäeva, halvemal juhul veel palju rohkemgi, pluss kohtukulud. (Loomulikult on ka vahepealsed võimalused, kus viga tuleb testimises välja, aga ka siis on testimise+vea raporteerimise+diagnoosimise+parandamise kulu kõvasti suurem kui esialgne 33 minutit.)

(järgneb)

Trackback URI | Comments RSS