Archive for the 'Põhialused' Category

Feb 20 2008

Tarkvaratootmise põhiteoreem II

Published by Targo under Põhialused

(Vaata esimest osa siin.)
Kõigepealt veelkord tarkvaratootmise põhiteoreemi sõnastus:

Vea parandamise hind kasvab aja möödudes. 

houseofcards.jpg

  • Näide 5: Programmeerija Priit läheb kuuks ajaks puhkusele, aga klient nõuab, et programmi kohe-kohe paar muudatust tehtaks. Peeter teeb asja ära, annab üle, aga siis selgub, et mingid teised asjad on samal ajal katki läinud. Klient Kustav poetab mürgiseid märkusi, kus võrdleb programmeerijate tööd kaardimaja ehitamisega.
  • Metoodiline lahendus 1: Iga programmeerija kirjutab koos koodiga ka piisava hulga automatiseeritud unit teste, mis tagavad igas olukorras keerulisema funktsionaalsuse toimimise. Kui kellelgi teisel on vaja programmis parandusi ja muudatusi teha, kontrollib ta, kas unit testid endiselt töötavad, ja tal on võimalik viga kohe parandada. Testide kirjutamine võtab muidugi lisaaega, aga see tasub end peaaegu alati ära, eriti kui on tegemist pikema projektiga, mille kallal töötab palju inimesi. Unit testingust asjana iseeneses ja pikemate/suuremate projektidega seotud iseärasustest kirjutan kunagi hiljem veel pikemalt.
  • Metoodiline lahendus 2: ettevõte peaks koodi kirjutamisel kasutama ühtseid standardeid, mis võimaldavad inimestel üksteise koodi paremini mõista ja täiendada.

ratwheel.jpg

  • Näide 6: Kustavil on kombeks alatasa mitmesuguseid väikesi täiendusi nõutada. Priit korraldab asjad tavaliselt kiiresti ära ja annab asjad üle. Kustav ei ole aga sellegipoolest rahul, kord crashib üks vorm, kord teine, ja talle jääb üleüldiselt kehv tunne. Samuti kulub Priidu ajast 30% esialgsete paranduste tegemisele ning 70% paranduste järel parandamisele.
  • Metoodiline lahendus: defineerida hulk teste, mis kontrollivad programmi põhiomaduste korrektse töö. Erinevates organisatsioonides kutsutakse neid erinevalt, ma kasutan siin ja edaspidi nimetust Build Verification Test (BVT). Ilma BVT-de töötamiseta ei tee ükski programmeerija check-ini ja kliendile ei näe samuti kunagi midagi mis poleks sellest sõelast läbi käinud. BVT-de automatiseerimise korral on nende kasutamisele kuluv ajakulu mõõdetav minutites, tühine aeg võrreldes tühja töö ja vaimunärimisega, mis kaasneb paranduste parandustele paranduste tegemisega.
  • Näide 7: aastal 1999 kontrollisid tuhanded ettevõtted kogu maailmas paaniliselt oma infosüsteeme, et ennetada Y2K probleemi. Tihti oli tegu süsteemidega, mille esialgsed loojad olid ammu pensionil ja hallihabemelistele Cobolihäkkeritele maksti ränka raha lihtsalt koodi ülevaatamise eest. Kui vigu leiti, oli tihti tegemist olukorraga, kus kood jooksis juba tuhandetel arvutitel üle maailma ja paranduste installeerimine põhjustas kalleid tööseisakuid. Sellest, kas Y2K oli tegelikult probleem või ei, on palju vaieldud, aga lugu illustreerib hästi asjaolu, et viga (konkreetses süsteemis), mille parandamine oleks aastal 1976 võtnud tunni, võttis nüüd tuhandeid inimtunde.

Loo üldine moraal on see, et tarkvarategemise igas etapis peab toimuma kvaliteedikontroll, mis tuleb teha võimalikult kiiresti, siis kui inimestel on asjad veel korralikult meeles, dokumentatsioon pole kusagile ära kadunud ega moraalselt vananenud. Kvaliteedikontrollist läbi lipsanud vead (olgu nad siis vead kliendi soovides, spetsifikatsioonis, disainis, koodis või kasutajajuhendis) põhjustavad üldjuhul selle, et järgmise etapi töö on tehtud valesti ning tuleb uuesti teha, mis ei mõju enamasti kellegi tujule hästi.
Tegelikult kõik väga elementaarne jutt ja paljud ehk küsivad, miks ma sellele ruumi raiskan: ühelt poolt on põhiteoreemi teadvustamine vajalik selleks, et mõista teemasid, millest hiljem juttu tuleb, teiseks aga toimub tarkvaratööstuses selle epideeminiline eiramine.

Miks põhiteoreemi eiratakse? Tihti on asi selles, et inimesed ei tea, millised metoodikad eksisteerivad asjade paremini korraldamiseks. Kui nad teavad, on nad tihti liiga laisad selleks, et neid ellu viia (ja peavad hiljem mitu korda rohkem tööd tegema, kui põhiteoreemi tagajärgede likvideerimiseks läheb).
Pahatihti juhtub ka, et inimesed leiavad, et nende töö on nii hea, et mingit kvaliteedikontrolli pole vajagi. Mul on olnud õnn töötada koos mõnede maailma tasemel inseneridega ning peamine, mis nende tegevuses silma torkab, on see, et nad panevad tohutut rõhku kvaliteedi tagamisele ning otsivad alati võimalusi selleks, et keegi nende tööd üle saaks vaadata. Aga sellest tuleb ka juba kord eraldi teema.

Lisalugemiseks veel põhiteoreeme: http://en.wikipedia.org/wiki/Fundamental_theorem

2 responses so far

Feb 17 2008

Tarkvaratootmise põhiteoreem I

Published by Targo under Joostes Marss, Põhialused

bug_cost.jpg

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.

mad-dog.gif persiankitty.jpg

  • 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)

One response so far

« Prev