Ärianalüüs, eelanalüüs ja detailanalüüs - mille poolest need erinevad?
Tegeled ettevõttes äriprotsessiga ja jõuad järeldusele, et selmet kõike käsitsi teha, võiks see protsess toimuda infosüsteemis. Mõte on hea, aga kuidas kirjeldada, mida sa infosüsteemilt ootad?
Pärast mõningast guugeldamist jõuad arusaamani, et vaja on nõuete spetsifikatsiooni ehk dokumenti, mis sisaldab süsteemi- ja kasutajanõudeid. See üsna levinud lähenemine kipub praktikas jääma liiga üldsõnaliseks ega anna selget vastust, mida sul tegelikult vaja on.
Tarkvaraarenduses käib analüüsiprotsess arendustööga algusest lõpuni kaasas ning selle metoodika erineb oluliselt näiteks ehitusvaldkonnas kasutatavast. Ehituses saab tõmmata selge piiri, kus lõpeb projekteerimine ja algab ehitustöö.
Tarkvaraarenduses sellist luksust pole - lahenduse kavandamine kestab tavaliselt kogu arendustöö vältel. Oluline on mõista, et eri etappides tegeletakse analüüsiga erineval detailsusastmel.
Trinidad Wisemanis pakume sulle tuge kogu analüüsiprotsessi ulatuses – ärianalüüsiga, et hinnata idee väärtust, eelanalüüsiga, et sõnastada kasutajanõuded, ja detailanalüüsiga, et anda arendajatele selge sisend. Loe lähemalt meie analüüsi teenuse lehelt, tutvu tehtud projektidega ja võta meiega ühendust.
Ükski tarkvara spetsifikatsioon ei saa olla lõpmata detailne
Veel umbes 8 aastat tagasi oli analüüsiprojektides klientide seas üsna levinud arusaam, et kui analüüs kord ära tehakse, on kõik nõuded kirjas, neid enam muuta ei tule ja arendust saab alustada ilma täiendava arutelu, uurimise või küsimusteta – ehk ilma edasise analüüsita.
Tegelikult ei saa ükski spetsifikatsioon ehk nõuete kirjeldus vastata kõigile arendaja küsimustele, sest sellise dokumendi koostamiseks kuluv töömaht oleks võrreldav kogu tarkvara valmisehitamisega.
Kuna ideaalset, kõikehõlmavat kasutajanõuete dokumenti ei ole võimalik koostada, tuleb leida just sellele projektile sobiv detailsusaste – tasakaal, mis võimaldab arendust alustada, säilitades samas paindlikkuse.
NB! Süsteemianalüüsi kontekstis tekitavad sageli segadust mõisted "eelanalüüs" ja "detailanalüüs", kuna need on üldised ning nende tähendus varieerub tellijate lõikes. Oleme näinud olukordi, kus üks klient tellib eelanalüüsi, kuid ootab selle tulemusena väga suurt detailsust – rohkemgi kui teine klient, kes arvab, et tellib detailanalüüsi.
Samuti oleme saanud projekte, mille kohta on väidetud, et detailanalüüs on tehtud, kuid poole rakenduse keerukus oli peidetud ühe kõrvalise lause taha.
Järgnevalt kirjeldame erinevaid analüüsi detailsustasemeid:
- ärianalüüs;
- eelanalüüs ehk kasutajanõuete analüüs;
- detailanalüüs.
Ärianalüüs ehk ärinõuete analüüs (visiooni tase) keskendub äriliste vajaduste sõnastamisele ning saab alguse probleemi püstitamisest. Analüüsitakse, miks on arendust praegu vaja, milline on soovitava süsteemi eesmärk ja ulatus.
Näiteks võib äripool näha, et ettevõtte mahud kasvavad: „praegu on 50 000 arvet kuus, aasta pärast juba 100 000, aga olemasolev süsteem jääb juba praegu aeglaseks.“
Ärianalüüs aitab tuvastada, milliseid muudatusi on vaja ja milline on nende mõju. See ei pea alati viima süsteemi arenduseni – vahel võib selguda, et tõhusam lahendus on hoopis äriprotsessi ümberkorraldamine või üleliigsete tegevuste eemaldamine. Ärianalüüsi võib kasutada ka valmis lahenduste hindamiseks, et selgitada välja, milline lahendus sobib ettevõtte äriprotsessidega kõige paremini.
Ärianalüüs tarkvaraarenduse kontekstis on suunatud süsteemi omanikele – inimestele, kes otsustavad, kas süsteemi arendamisse investeerida. Kavandatava lahenduse kirjeldus peab olema piisavalt selge, et mõista võimalikku ärilist kasu ja samas hinnata ka arenduse ligikaudset maksumust (näiteks: kas see on suurusjärgus 50 000, 100 000 või 300 000 eurot). Tavaliselt keskendub ärianalüüs ärivaldkonnale, äriprotsessidele ja lahendatavatele probleemidele.
Kui ärianalüüs on tehtud ning kulud ja kasud kaardistatud, saab tellija teha esimese ja väga olulise otsuse: kas projektiga kohe edasi liikuda, see ajutiselt edasi lükata või üldse loobuda.
Eelanalüüs ehk kasutajanõuete analüüs keskendub sellele, milline peaks süsteem olema kasutaja vaatepunktist. Selle eesmärk on kirjeldada süsteemi käitumist juba täpsemalt kui ärianalüüsis. Analüüsitakse äriprotsessi ning jõutakse kasutuslugude (use case) või soovilugudeni (user story).
Paralleelselt algab töö ka interaktiivse kasutajaliidese prototüübiga. Prototüüp aitab kasutajal kõige paremini mõista, kuidas süsteem lõppkasutaja jaoks välja hakkab nägema ning kuidas see töötab.
Eelanalüüs on suunatud süsteemi tulevastele lõppkasutajatele – inimestele, kes hakkavad süsteemi päriselt kasutama. Kasutajanõuete analüüsi tulemusena saavad nad öelda: „jah, sellisest tarkvarast oleks meile kasu“või „just sellist lahendust me ootame.“
Eelanalüüsis defineeritakse ka süsteemi esmased mittefunktsionaalsed nõuded - tehnilised piirangud või tingimused, mida süsteem peab täitma. Nende alla kuuluvad näiteks liidestused, turvalisus, kasutusmugavus ja muud sarnased aspektid.
Lisaks võivad siia kuuluda ka arendusprotsessiga seotud nõuded, näiteks kuidas peaks toimuma testimine ja süsteemi üleandmine. Need saab aga sageli täpsemalt kokku leppida juba konkreetse arendajaga, võttes arvesse tema tavapäraseid tööpraktikaid.
Eelanalüüsi tulemusena saab arenduse maksumust hinnata oluliselt täpsemalt. Kui ärianalüüsi põhjal tehtud hinnang võib tegelikust maksumusest erineda kuni kahekordselt, siis eelanalüüsi puhul jääb võimalik eksimus tavaliselt 20–50% vahele.
Detailanalüüs keskendub süsteemi käitumise aspektidele, mis ei pruugi lõppkasutaja vaates olla esmatähtsad, kuid on hädavajalikud tarkvara realiseerimiseks ja haldamiseks. Detailanalüüsi dokumendid on väga tehnilised ning nende peamiseks sihtrühmaks on arendajad.
Detailsete süsteeminõuete dokument peab sisaldama kõiki eriolukordi, millega arendaja peab arvestama. Näiteks: millised on andmebaasi tabelid ja nende omavahelised seosed, kuidas on lahendatud autentimine ja sisselogimine, milliseid andmeside protokolle kasutatakse, kuidas süsteem dokumenteeritakse ning milliseid tehnoloogilisi lahendusi tuleb rakendada. Lisaks kirjeldatakse liideseid front-end'i ja back-end'i vahel ning iga kasutajaliidese elemendi täpset käitumist.
Sageli on otstarbekas detailanalüüsi koostada paralleelselt arendustööga, kuna see peegeldab ka konkreetse meeskonna tööstiili ja arenduse käigus kujunevaid valikuid. Näiteks oleme näinud projekte, kus liideste täpne kirjeldus jääb arendajate ülesandeks ja analüütikud kirjeldavad vaid seda osa, mis hõlmab vaid äriliselt olulise andmevahetuse kirjeldust. Teisalt on olnud projekte, kus kõik detailid peavad olema eelnevalt analüüsis dokumenteeritud.
Detailanalüüsi ei ole mõistlik pikalt ette koostada, kuna ärivajadused võivad ajas muutuda ja sellega muutuvad ka süsteemi nõuded. Seetõttu on paindlik, arenduse käigus täienev detailanalüüs sageli tulemuslikum kui liiga vara lukku pandud tehniline dokumentatsioon.
Analüüsi kvaliteedikriteeriumid
Konsensuslik – analüüsi tulemeid on korduvalt läbi arutatud ja kõik osapooled on veendunud, et just sellist süsteemi soovitakse. Kuna infosüsteemide muudatused mõjutavad tavaliselt mitmeid eri valdkondade inimesi, tuleb tagada, et kõigil osapooltel oleks ühine arusaam kavandatavast lahendusest. Analüüsiprotsessi lõpuks peab olema selge, et see on süsteem, mis on organisatsioonile tõepoolest kasu(m)lik.
Arusaadav – dokument peab olema vormistatud ja sõnastatud nii, et ka ärikasutaja mõistab selle sisu ilma liigse vaevata. Mahuka dokumentatsiooni puhul on eriti oluline selge struktuur: liikuda üldiselt tasemelt detailsemale, kasutada täpselt viidatavaid alalõike ning selgitada kõik erialaterminid. Kasutajanõudeid koostades tasub alati hinnata, kas nii tarkvara tulevane kasutaja kui ka arendaja mõistavad sõnakasutusi ühtmoodi.
Eelanalüüsis võib küll kasutada näiteks UML-diagramme, kuid sageli ei saa dokumentatsiooni lugejad neist aru. Sellisel juhul tekib segadus ja dokument ei täida oma eesmärki. Seetõttu soovitame eelistada lihtsat ja võimalikult arusaadavat tähistusviisi.
Vastuoludeta – dokumentatsioon ei tohi endale vastu rääkida ega sisaldada vastuolulist teavet erinevate dokumentide vahel. Sellised vead tekivad sageli siis, kui projektiga töötab korraga mitu inimest. Tulemuseks võib olla olukord, kus andmed liiguvad küll süsteemi, aga puudub koht, kuhu need salvestada – lihtsalt seetõttu, et nõuetes jäi see osa defineerimata või vastuoluliselt kirjeldatud.
Terviklik – analüüs peab katma kogu lahenduse ulatuse. Sageli tehakse viga, et keskendutakse mõnele huvitavale probleemile, kuid pärast arendusmahtude hindamist ja töö algust ilmneb, et olulisi osi on üldse analüüsist välja jäänud. Siinkohal ei ole kõige olulisem detailsus, vaid see, et lahendus oleks sisuliselt täielik ja kõik vajalikud komponendid oleksid läbi mõeldud.
Sõltumatu – ärianalüüsi ja eelanalüüsi puhul peaks analüüs jääma tehnoloogilisest lahendusest sõltumatuks. See on oluline, et mitte põhjendamatult mõjutada või piirata hilisemat tehnoloogia valikut. Reeglina väldime oma töös olukordi, kus nõuetes juba varakult eelistatakse konkreetset tehnilist lahendust. Kui tehnoloogiline piirang siiski kasutajanõuetes välja tuuakse, peab sellel olema selge ja hästi põhjendatud vajadus.
Testitav ja verifitseeritav – detailsed nõuded peavad olema üheselt mõistetavad ja objektiivselt kontrollitavad. Ärianalüüsi tulemusel sõnastatud vajadused on sageli üldisemad ega võimalda täpset testimist, kuna need annavad pigem suuniseid kui konkreetseid kriteeriume.
Detailide selgus mõjutab otseselt süsteemi lõplikku kvaliteeti. Seetõttu tuleb kasutajanõuded kirjeldada piisavalt täpselt, et nende täitmist saaks testimise käigus üheselt hinnata. Näiteks pole „süsteem peab olema kiire“ testitav nõue, kuid „toiming peab toimuma kolme sekundi jooksul“ juba on.
Sarnane probleem esineb ka kasutusmugavuse nõuetega. Väljend „süsteem peab olema mugav“ ei ütle iseenesest midagi. Kui loome kasutajaliidese prototüüpi, on meie ülesanne täpselt lahti kirjutada, mida „mugav“ antud kontekstis tähendab. Sageli sõltub see väikestest, kuid olulistest detailidest – näiteks kas süsteem määrab vaikimisi sobivad väärtused või kas professionaalne kasutaja saab kiiresti infole ligi ja tegevused tehtud.
Kuidas edasi?
Kui oled tarkvaraprojekti tellija, tasub esmalt mõelda, millises faasis sinu idee parasjagu on ja kui selge on sinu enda nägemus kavandatavast lahendusest. Kas sul on näiteks ärianalüüs juba mõttes tehtud – ehk oled jõudnud arusaamani, et soovid oma ideesse investeerida?
Või oled juba kirja pannud oma parima arusaama süsteemi funktsioonidest ja peamistest äriprotsessidest ning tunned, et sooviksid nüüd minna detailsemaks?
Ärianalüüs on faas, kus on vaja partnerit, kes aitab hinnata idee elujõulisust. Eelanalüüs on hetk, kus on vaja kedagi, kes aitab sinu mõtted süstematiseeritult ja üheselt mõistetavalt kirja panna. Detailanalüüs on etapp, kus süsteem lihvitakse põhjalikult läbi ning pannakse paika konkreetne tööülesannete struktuur arendajatele.
Lõppkokkuvõttes on edasiliikumiseks kõige olulisem, et tarkvara tellija võtmeisikutel oleks selge ja ühine visioon loodavast lahendusest.
