Kui teha asendused „vundament“ - > „nõuded, „maja“ - > „tarkvara“, „keskmine majaelanik“ -> „keskmine tarkvara kasutaja“, siis jäävad nimetatud väited siiski kehtima.
Isegi kui me aktsepteerime asjaolu, et väljend „külmutatud nõuded“ on oksüümoron*, ei saa nõuetesse suhtuda hooletult ja pealiskaudselt, mõeldes, et „need niikuinii muutuvad, ei pea vaeva nägema“. Nõuete kirjeldamise puhul peaks olema eesmärgiks saada kirja kõik vajalik (ja mitte sõnagi rohkem), eemaldada mitmetimõistetavused – mis on tihti keelelise ebatäpsuse ja inimliku ekslikkuse tulemus – ja hoolitseda saadud tulemuse eest kuninga kassi vääriliselt.
Missuguse kivi all on nõuded peidus?
Nõuded pole tegelikult miski, mida saab „rehaga kokku rehitseda“ või tavapäraselt „koguda“. Kuna loodav tarkvara on midagi uut (keegi ei tee ju uut tarkvara, et see oleks täpselt samasugune, kui juba mõni olemasolev), siis valmis nõudeid lihtsalt ei ole olemas! Olemas on reaalse maailma poolt tulevad ootused, vajadused, aimdused, piirangud ja kohustused, mis asuvad erinevate osapoolte peades. Kas peade omanikud oskavad oma mõtteid alati väljendada? Kas nõuete „koguja“ oskab alati leida õige allika?
Sisuliselt õigem väljend oleks hoopiski „nõuete väljatöötamine" või „nõuete ehitamine“. Ingliskeelne väljend kõlab requirements engineering, kuid päris head eestikeelset vastet ma polegi osanud sellele sõnapaarile leida.
Nõuded on niisiis vajaduse, ootuse või piirangu kirjalik, taasesitust ja kommunikatsiooni võimaldav esitusviis. Nõuded võivad tuleneda loodava tarkvara tulevastelt kasutajatelt, aga ka muudelt huvipooltelt. Oluline on kõik nõuete allikad üles leida.
Näiteks, kui me arendaksime kooli õppeinfosüsteemi, siis kust tulevad nõuded sellele? Kas lisaks sisseastujate, õppurite, õpetajate, juhtkonna ning kooli personali vajadustele peaksime arvestama veel millegagi? Aga loomulikult. Üheks oluliseks nõuete allikaks on ka valdkonda reguleeriv seadusandlus. Kooli õppeinfosüsteemi loomisel peame arvatavasti arvestama (olenevalt kooli tasemest ja funktsionaalsuse ulatusest) ülikooliseadusega, erakooliseadusega, haridusseadusega, raamatupidamisseadusega, võlaõigusseadusega...
Tihti lähevad olulised nõuete allikad, näiteks eelnimetatud seadused, lihtsalt meelest.. Tüüpiline puudus, mida testimise käigus nõuete ülevaatusel täheldanud olen, on ka näiteks kasutajaõiguste halduse ning rollide kirjeldamata unustamine. Seda pärast tarkvarale „juurde pookida“ on juba keeruline. Vilunud (või kontrollnimekirja omav) analüütik teab, kus kivi all nõuded peidus on, ja oskab sinna vaadata.
Luuletused, haikud ja novellid ... programmeerija ja testija laual
Inimkeel on imeline asi oma väljendusrikkuses ja annab lõpmatul hulgal materjali ilusate luuletuste ja sügavamõtteliste romaanide kirjutamiseks, kus tekstiridadesse on kirjutatud vähem kui nende vahele. Tarkvaraspetsifikatsioonid on aga tähtsad dokumendid, ning nende juures pole inimkeele värvikus just kiiduväärt omadus.
Sõnade tähendused keeles on suhteliselt kokkuleppelised, seetõttu inimesed lähtuvalt oma taustast, haridusest ja kujutlusvõimest võivad mõista sõnu erinevalt. „Tõlkes kadumaminek“ võib juhtuda vähemalt neljas erinevas kohas:
- Idee autor ei suuda oma mõtteid väljendada nii nagu ta mõtleb;
- Idee kirjapanija (analüütik) ei oska aru saada (kuulata) nii nagu idee autor mõtleb;
- Idee kirjapanija ei suuda end väljendada nii nagu ta tahaks;
- Kirjutatu lugeja (nt programmeerija) ei saa aru nii nagu kirjutaja mõtles.
Teatud keelelised iseärasused ei pruugi samuti soodustada kirjutatu üheseltmõisteavust. Võtame näiteks järgmise lause „Kõik lambid on seotud lülitiga“.
Hea lugeja, mõtle korraks, kuidas Sa sellist „konfiguratsiooni“ ette kujutaksid? Keeleliselt kannab see konstruktsioon nime „üldistus + mitmus“ ning ta on juba oma ülesehituselt kahetimõistetav nii eesti, inglise kui ka saksa keeles.
Esimene interpretatsioon oleks selline: Iga lamp on seotud oma lülitiga (1:1 suhe).
 |
| Pildi allikas: flickr |
 |
| Pildi allikas: wikimedia.org |
Nii elektritöödel juhtmete vedamise kui ka andmebaasi ehitamise seisukohalt on tegemist kahe väga erineva lahendusega. Niisiis aitab ohtlike keelekonstruktsioonide teadmine (neid on palju rohkem kui eelnevalt käsitletud näide) neid vältida ja ära tunda – seega vältida võimalikku vääritimõistmist enne, kui see jõuab vale realisatsioonina koodi.
Kuidas hallata kuninga kassi?
Analüütik on lõpuks kõigi vajalike osapooltega vestelnud, uurinud seadusi ja standardeid ning nende põhjal nõuete komplekti valmis ehitanud. See kunstiteos ei ole mõeldud kindlasti kusagile sahtlisse tolmu koguma!
Esiteks peavad nõuded jõudma oma tarbijani, kelleks on nii realiseerijad/edasiarendajad (arhitektid, disainerid, programmeerijad) kui ka testijad. Missuguste tööriistadega seda kõige paremini saavutada? Kas tekstidokumentides „elavad“ nõuded on kõigile hästi leitavad ja kättesaadavad, või oleks tarvis mõnda nõuetehaldustarkvara, mis oleks ka integreeritud mõne testihaldustarkvaraga? Kõik see oleneb organisatsiooni ja projekti suurusest.
Teiseks, väljend „lõplikud nõuded“ kipub olema oksüümoron. Nõuded muutuvad ja see ongi elu. Kuid muudatustele tuleb reageerida ja neid hallata – ilma soojemaks muutudes on ju loogiline kasukas päikesevarju vastu vahetada. Üldjuhul peaks ka nõude muutumisele järgnema terve kaskaad tegevusest – muudatuse mahtude hindamine, seotud osade/komponentide/protsesside leidmine, disaini muutmine, ümberkodeerimine, testimine. Kõik need tegevused on vajalikud ja kõik osapooled, kes arendusprotsessis osalevad, peavad muudatuse info õigeaegselt saama, vastasel juhul väljendub see kohe tarkvara kvaliteedi languses.
Hea analüütik tagab ka selle, et tema raske töö tähtsat tulemust on võimalik teistel osapooltel kasutada, ja haldab nõuete muudatusi nii, et kõigil osapooltel oleks kättesaadaval just ajakohane ja antud ajahetkel õige info.
Kokkuvõtteks
Tarkvaranõuete puhul on oluline need kätte saada – unustamata ühtki osapoolt või mõjutajat – ja üheselt mõistetavalt kirja panna. Hea analüütik ja kindlasti ka hea testija peaks tundma konkse, kus informatsioon kaduma läheb ning moondub. Nõuetest endist pole vähem tähtis ka see, kuidas neid hiljem hallatakse ja kaasajastatakse. Juhin tähelepanu – nõuded on elusad olevused, nendega ei tohi hoolimatult ümber käia – surnud nõuded lähevad haisema!
Maili Markvardt
ASA Kvaliteediakadeemia
Maili on Eesti Testijate Liidu asutajaliige ja kuulub ka ETLi juhatusse. Ühtlasi õpetab ta tarkvara kvaliteediteemasid Tallinna Tehnikaülikoolis ja Eesti Infotehnoloogia Kolledžis. "Testimine ei ole elukutse, testimine on elustiil!"
* oksüümoron – vastandtähendusi sisaldav väljend
Kommentaare ei ole:
Postita kommentaar