Archive for June, 2010

Jun 22 2010

Teenusearendus vs tootearendus 3

Published by Targo under Hea kood, Raha

Eelnevalt alustatud teema kokkuvõtteks vastuseid mõnedele küsimustele, mida mult vahel Microsofti ja muu tootearenduse kohta on küsitud.

Kui Office’i ajagraafik on sellisel määral fikseeritud (vt teema 2.osa), kuidas jääb vigade parandamisega?

Vigade puhul kehtib sama põhimõte, mis feature’de puhulgi. Vigade parandamiseks on planeeritud teatud aeg ning kui tähtaeg lähemale jõuab, tõuseb järk-järgult latt, millise tõsidusega vigu veel parandatakse ja milliseid mitte. Peamiseks põhjuseks on siin kusjuures ära hoida, et ühe tuntud vea parandamine ei tekitaks uusi tundmatuid vigu. Kui release’ini on jäänud loetud päevad, parandatakse vaid tõsiseid turvavigu ning kui mõni selline leitakse, lükkub release tõesti edasi, et täiendavaks testimiseks aega anda. Iga selline edasilükkamine on aga kulla hinnaga, sest ka kõik seonduvad ja planeeritud tegevused alates CD-de trükkimisest kuni SteveB kõneni mõnel asjakohasel üritusel lükkuvad edasi.

Vead, mida ei jõutud parandada, jäävad (vastavalt tõsidusele) kas service pack‘i või järgmisse versiooni. Kuna tarkvara poodidesse jõudmine võtab aga mõnevõrra aega, saamegi situatsiooni, kus vahel on poest ostmise ajaks juba ka esimene service pack downloaditav.

Milline võiks olla tootearenduse versioonihaldus?

Eristaks siin kõigepealt kaht äärmust:

“Rätsepatöö” tarkvara oluliseks eripäraks on, et kliendile tehakse pidevalt mingeid väikesi kohendusi ja mugandusi. Niipea kui klient midagi tahab ja selle eest on nõus maksma, tehakse ka vastav asi ära.

Teises servas on tarkvara nagu MS Windows, mis elab oma elu, ja kui sa pole just Citigroup või US Department of Defence, on sul üsna vähe võimalust seda kuidagi suunata.

Samas on hulk tarkvarasid, mis on alguse saanud rätsepatööst, aga sealt edasi on neid veel (esialgu) käputäiele klientidele müüdud. Kuna arendusmeeskond on harjunud kliendi erisoovidele orienteeruma, tehakse ka siin mõnda aega samamoodi edasi. Tulemuseks on, et lisaks ilusale ja elegantsele põhifunktsionaalsusele kasvab tootele veel igasuguseid erikujulisi kombitsaid ja konfiguratsioone, mida läheb vaja vaid ühel või teisel meie klientidest. Ja kui me igaühele natuke erineva asja paigaldame, on versioonihalduse seisukohalt tulemuseks tohutu peavalu, sest selles situatsioonis muutub kasvõi regressioonitestimine kiiresti võimatuks.

Minu isiklik arvamus on, et sellist koodibaasi fragmenteerumist tuleks iga hinna eest vältida ja erinevad kliendid peavad saama võimalikult standardseid ja ühetaolisi tükke, nii on pikas perspektiivis ka nende enda elu lihtsam ja vigu vähem. See lähenemine aitab vältida ka “dll hell’i”. Tootearenduse puhul on meil igasuguseid versioone niigi palju (vanad versioonid, viimased versioonid, uued beetad jne), nii et peame oma konfiguratsiooni võimalikult lihtsana hoidma.

Suurte toodete näitena võib siin jälle tuua MS Office’i, mis koosneb praeguseks juba kümnetest erinevatest üksiktoodetest, aga selle asemel, et lasta kasutajail sealt suvalisi kombinatsioone valida, müüb Microsoft ikkagi ainult näputäit standardkonfiguratsioone. Sellegipoolest on Office’i arenduses terve tiim, mis tegeleb täiskohaga ainult versioonide ning build scriptide haldamisega.

Kui palju meil dokumentatsiooni vaja läheb?

Tootearenduse puhul tuletame meelde esimeses osas sissetoodud suurust ϰ, mis muuhulgas mõjutab otseselt ka aega, mis programmeerijatel tuleb kulutada toote hilisemalt toetamisele. Seetõttu on ka dokumentatsioon palju olulisem kui teenusena loodud tarkvara puhul, et toetusprotsess efektiivsem oleks. Konkreetselt Microsofti standardiks on see, et koodile tekib neli erinevat dokumentatsiooni: spetsifikatsioon, arendaja loodud tehniline disain, testija kirjutatud testplaan ja technical writeri tehtud kasutajajuhend.

Selle üle, kas viimase jaoks peaks eraldi inimene olema, võib muidugi vaielda. Me kõik oleme lugenud dokumentatsioone, mis on kirjutatud inimese poolt, kellel pole ilmselgelt olnud piisavalt võimalust asjast aru saada, vt kasvõi LRF-1914 näidet Joeli artiklis.

No responses yet