Autor: Raul Ennus • 22. oktoober 2017

Tähelepanu! Artikkel on enam kui 5 aastat vana ning kuulub väljaande digitaalsesse arhiivi. Väljaanne ei uuenda ega kaasajasta arhiveeritud sisu, mistõttu võib olla vajalik kaasaegsete allikatega tutvumine.

Suurte tarkvarahangete läbiviimine on seotud väga suurte riskidega. Globaalse statistika kohaselt ebaõnnestuvad ligi pooled suured projektid. Lisaks veel kolmandik viiakse läbi suurte mööndustega – sisuliselt ei saavuta need projektid täielikult oma eesmärki ja/või lähevad oluliselt üle eelarve ja tähtaja.

Tarkvaraarenduse eripära on väga suur määramatus projekti alguses ja esimese poole jooksul. Projekti alguses on pea võimatu näha ette kõiki vajalikke detaile, lahendusi ja seoseid. Kui tuua näide tavaehitusest, siis seal on võimalik kogu projekteeritav hoone palju väiksema määramatusega kuni detailsete sõlmedeni ära kirjeldada. Kuigi ka tavaehituses jäävad alles riskid ja projekti elluviimise käigus tuleb teha teatud määral muudatusi. Riskide minimeerimiseks on kasutusele võetud näiteks 3D modelleerimine.

Majade ja tarkvara ehitamise oluline erinevus on, et hoone projekti joonistades luuakse valmivast hoonest minimaalne, kuid üpris sarnane mudel. Tarkvara puhul aga sellist 1:1 mudelit alati ei looda. Tarkvara lähteülesanne pole tihti mitte süsteemi vähendatud prototüüp, vaid suur hulk teksti – analüüsidokument. Ja see on oluline riskikoht – teksti mitmetimõistetavus on liiga suur ja ainult teksti abil planeeritavat süsteemi läbi projekteerides on risk, et pole mõistetud tegelikku vajadust.

Tarkvaraprojekti alguses tuleb teha võimalikult palju prototüüpimist

Siit jõuame olulise tõdemuseni. Iganenud tarkvaraarendusmetoodikate (kose, ingl keeles waterfall mudel) puhul arvati, et projekti alguses on võimalik kõik detailid lõplikult teksti abil ära modelleerida. Kaasaegsed metoodikad (paindlikud, ingl keeles agile ja lean mudelid) väidavad vastupidist – projekti alguses saame vaid määratleda ärilised eesmärgid ja üldisemad   n õ u d e d süsteemile. Detailsed süsteemi  o m a d u s e d  tuleb teatud määral proovimise teel selgitada välja projekti käigus. Sarnaselt 3D modelleerimise loogikale tavaehitusega, on oluline luua loodavast tarkvarast mitte tekstilisi, vaid võimalikult elulähedasi kirjeldusi (prototüüpe) loodavast süsteemist. Ehk pildid, dünaamilised prototüübid, minimaalsed tooteideed (ing keeles minimal viable product) on väga oluline osa loodava tarkvara kirjeldamisel ja projekti edukuse tagamisel.

Tarkvaraarenduses on väga palju erinevaid võimalusi riskide maandamiseks ja vastupidi – karisid, kuhu otsa sõita. Kui järgida projektide elluviimisel kaasaegseid tarkvaraarendusemetoodikaid, siis on võimalik riske ja määramatust oluliselt vähendada.

Mitmete suurte riigihangete ja ka erasektori projektide probleem on olnud iganenud tarkvaraarendusmetoodikate kasutamine. Riigil erinevalt erasektorist, on võimalik keskselt teatud norme ja reegleid kehtestada. Riik peaks seda võimalust kasutama ning selgelt deklareerima, et iganenud metoodikate kasutamine riigihangetel ei ole lubatud. Loomulikult eeldab selle juurutamine erinevaid toetavaid tegevusi (juhendmaterjale, koolitusi, seminare jne) ja üleminekuaega, mis on suuremate muudatuste elluviimiseks vältimatu.