2 Kes on analüütik?

Selles peatükis õpid:

• tundma analüütiku tööülesandeid
• kirjeldama funktsionaalsete ja mittefunktsionaalsete nõuete erinevust
• võrdlema ärianalüütiku ja süsteemianalüütiku tööd
• kirjeldama sinule tuttavat äriprotsessi ja esitama seda diagrammi kujul

Eelnevas peatükis sisalduv andis põgusa ülevaate tarkvaraarenduse protsessis sisalduvatest tegevustest ja täpsemalt ka rollidest Scrum arendusraamistikus. Hoolimata projektimeeskonna valitud arendusraamistikust, tuleb meeskonnal kokku puutuda samade ülesannetega – sealhulgas kliendi käest nõuete kogumise ja analüüsiga. Käesolevas peatükis tutvume lähemalt arendusmeeskonna rollidega, kelle tööks on selgitada välja kliendi poolt esitatud probleemi reaalne olemus, tuvastada kliendi vajadused selle probleemi lahendamisel ning seejärel pakkuda koos meeskonnaga välja lahendus, mille kallal projektimeeskond töötama hakkab. Antud ülesannetega tegelevad nimelt analüütikud, keda sageli jaotatakse täpsemate ülesannete põhjal äri– või süsteemianalüütikuteks.

Miks “analüüs”?

Esmapilgul võib ehk tunduda, et milleks selline roll meeskonnas vajalik on, kes tegeleb lihtsalt vahelülina kliendi ja arendajate vahel. Miks ei võiks klient lihtsalt oma soove otse arendajatele saata? Põhjus on nimelt selles, et analüütiku töö ei seisne pelgalt info vahendamises kliendilt arendajatele, vaid ka põhjalikult kliendi poolt esitatud vajaduste ja nende mõju uurimises ehk analüüsimises. Analüütikud peavad õppima tundma oma kliendi äri ja selles toimuvaid protsesse, et mõista, mispärast kliendi esitatud nõuded on reaalselt vajalikud ja kas nendele vajadustele lahenduse leidmisel on kliendil võimalik saavutada oma soovitud eesmärgid. Võib juhtuda, et klient ei oska küsida täpselt sellist lahendust nagu ta vajab, kuna tegemist ei ole tarkvaraarenduse võimalustega kursis, ja siin tulebki appi analüütik.

Igale probleemile ei pruugi aga lahenduseks olla mõne tarkvara arendamine ja kasutusele võtmine, mistõttu on analüütiku oskustest ja kogemustest kasu igas valdkonnas, kus on vaja leidlikult probleemidele lahendus leida. Kuna aga käesolevas õpikus keskendume just tarkvara analüüsile, vaatame lähemalt kuidas ja milliseid vahendeid kasutades tegelevad analüütikud probleemi tuvastamise ja lahendamisega tarkvaraarenduse projektides.

Nõuete analüüs

Enne kui analüütik saab pakkuda välja lahenduse, on teadupoolest vaja õppida tundma probleemi, mis on vaja lahendada, ja tuvastada arendusnõuded, millest edaspidi lähtutakse tarkvara arendusel. Kui tarkvara on valmis üleandmiseks Tellijale, siis hinnatakse tehtud töö vastavust nõuetele. Arendusnõudeid on kahte liiki:

• funktsionaalsed nõuded kirjeldavad tarkvara funktsioone, ehk mida kasutaja selle tarkvara abil teha saab
• mittefunktsionaalsed nõuded kirjeldavad pigem ootusi tarkvara kasutamise protsessile, sh jõudlusele, turvalisusele, riistvarale, ühildumisele jne.

Kuigi funktsionaalseid nõudeid loevad eelkõige programmeerijad, peaks need kirja panema sellisel kujul, et neist ka “tavainimene” aru saaks. Nõuete sõnastamisest räägime lähemalt järgmises peatükis.

On hulgaliselt erinevaid viise, kuidas analüütik saab koguda infot kliendi esindajatelt või loodava/kasutatava süsteemi lõppkasutajatelt nende soovide ja vajaduste kohta, et täpsemini nõudeid sõnastada:

• Dokumendianalüüs – tihti on klientidel enda vajaduste ja ka ärieesmärkide jaoks loodud dokumendid, mis pakuvad analüütikutele hulgaliselt informatsiooni selleks, et saada esialgne arusaam nende ärist ja soovidest.
• Intervjuud ja koosolekud – kõige sagedamini kasutavad analüütikud võimalust kohtuda kliendiga näost näkku, et oleks võimalik nende soove, äri ja protsesse tundma õppida. See annab võimaluse küsida jooksvalt täpsustavaid küsimusi, kui midagi jääb segaseks, ning pakkuda ka omalt poolt välja potentsiaalseid probleeme, mis analüütikule on silma jäänud, kuid klient ei ole maininud.
• Vaatlused – üheks enim aega nõudvaks viisiks kliendi protsesside kohta õppimiseks on vaatlusel põhinevad uurimused. See tähendab, et analüütik jälgib protsesse, millega seotud probleemide lahendamiseks on klient tarkvara tellinud.
• Küsimustikud – kui soov on koguda suure hulga inimeste tagasisidet, kes on antud probleemvaldkonnaga seotud, on võimalik jagada nii paberil kui ka digitaalsel teel küsimustikke, millega uuritakse nende inimeste käitumist, soove ja muresid selles valdkonnas.

Lisaks otseselt kliendi poolt välja käidud vajaduste analüüsimisele on võimalik kasutada juba olemasolevate infosüsteemide puhul ka erinevaid tarkvarasid (näiteks Google Analytics), mille abiga on võimalik jälgida süsteemi kasutajate käitumise kohta statistikat. Selle abil on võimalik tuvastada juba kasutusel oleva tarkvara puhul probleeme, millest süsteemi omanikud ise ei pruugi täpselt teadlikud olla. Peale probleemide tuvastamist on võimalik leida lahendusi, et süsteemi ja selle kasutamist paremaks muuta.

Google Analytics annab infot näiteks selle kohta, milliste veebilehtede kaudu kasutajad jõuavad kliendi süsteemini ning milliste lehtede vahel antud süsteemis kasutajad liiguvad. Kui tegemist on näiteks mõne e-poega, on võimalik tuvastada, kui suur hulk kliente jõuab ostukorvi protsessis lõpuni ning millise sammu juures kõige enam katkestatakse. Selle informatsiooni abil on võimalik parandada või täiendada kasutuskogemust e-poe klientide jaoks kõige keerulisemates kohtades, et tulevikus enam need sammud probleemiks ei kujuneks.

Nõuete analüüsi tulemusena saab analüütik kogutud infole tuginedes defineerida ära uuritud probleemi olemuse, kliendi või kasutajate nõuded ja protsessid ning kirjeldada arendajatele, milliseid kasutusvõimalusi ja tegevusi ehk funktsionaalsuseid antud lahendus peab kasutajatele pakkuma. Selleks koondavad analüütikud kõik eelnevalt mainitu kokku ühte dokumenti, mida nimetatakse nõuete spetsifikatsiooniks.

Kuna nõuete spetsifikatsioonis olevate kirjelduste alusel hakkavad arendajad tööle tarkvara programmeerimisega, on oluline kõik need nõuded kirjeldada lihtsalt ja arusaadavalt, et vältida vigu ja hiljem juba arendatud funktsionaalsuste ümber tegemist.

Mõned levinud vead nõuete määratlemisel on näiteks järgnevad (Paul & Yeates 2006: 136):

• Nõue pole seotud projekti eesmärkidega
• Segaselt sõnastatud või mitmetähenduslik
• Sama nõue mitmes sõnastuses
• Täitmist pole võimalik kontrollida
• Erinevad nõuded on kirjeldatud erineva detailsusastmega

Ärianalüütik

Sisend ärianalüüsi jaoks tuleb organisatsiooni strateegilistest dokumentidest.

Selleks, et koguda täpsemat sisendit, suheldakse erinevate osapooltega ettevõttes ning uuritakse probleemide tausta ja põhjuseid ning seosed ning uuritakse mõtteid lahenduste osas.

Ärianalüüsi nõuete juures kaardistatakse hetke olukord näiteks probleemide nimekirjana ja siis täpsemalt näiteks protsessina. Peale seda analüüsitakse, millega peaks tulevikus arvestama ning siis kirjeldatakse ära soovitud tuleviku olukord.

Oluline on keskenduda kõige kriitilisematele probleemidele ehk teha valik, millele esmalt keskenduda. Lisaks on tarvis aru saada, kuidas need probleemid ja nende parandusettepanekud mõjutavad teisi süsteemi osi.

Mõlemas firmas paneb ärianalüütik kokku sisendi tarkvaraarenduse jaoks.

Ärianalüütik

Äriprotsesside kaardistamine

Selleks, et infosüsteemi luua, teha edasiarenduse või tagantjärele luua infosüsteemide dokumentatsiooni, on tarvis aru saada, kuidas infosüsteem töötab. Selleks on väga head äriprotsessi joonised. Äriprotsessi kaardistamine aitab välja selgitada näiteks, millised etapid infosüsteemis toimuvad, et süsteem saaks enda peamise eesmärgi täita.

Äriprotsesside kaardistamisel on 4 olulist märgendit:

Start – punane ring, algab sooviga

Lõpp – roheline ring, lõppeb tulemusega

Tegevus – ristkülik

Otsustuskoht positiivse ja negatiivse stsenaariumiga – romb

Osade ühendamine, et näidata tegevuste järjekorda protsessis – nool

NÄIDE. Hinde vaatamine e-koolis

SÜSTEEMIANALÜÜTIK

Süsteemianalüütik on enamasti arendustiimi pool peal ning aitab leida äripoolel/kliendil sobiva lahenduse enda murekohale ning kirjutab arendustiimile vajalikku dokumentatsiooni.

Dokumenatsioon peab alati olema ajakohane, siis on sellest kõige enam kasu. Pahatihti kipub olema nii, et dokumentatsioon infosüsteemi kohta puudub ning siis on raske teha uusi arendusi, sest muudatustega võivad olla seotud mõned võtmeseosed.

Dokumentatsioon on vajalik selleks, et kõik saaksid aru, millised nõuded on tulnud äri poole pealt ning kuidas on need tehniliselt lahendatud. See aitab jäädvustada projekti jooksul vastuvõetud otsuseid ja neid paremini vajadusel kliendile põhjendada. Lisaks aitab dokumentatsioon vältida seda olukorda, kui keegi võtmeisik peab ära minema ning tekib teadmiste tühimik. See informatsioon on hea ka arendustiimiga liitujale, et kiiresti olla projektiga kursis.

Süsteemianalüütik

NÄIDE. Tarkvara analüüs

Klient soovib enda firma sees soodustada paremat koostööd töötajate vahel, aga ei tea, millist koostööplatvormi valida. Faile on palju ja mahud on suured. Väga oluline on, et saaks toimetada sisselogituna, samal ajal samas dokumendis tööd teha ning lahendus tasuta. Lähtudest kliendi sisendist (vt omadusi 1. tulbas) võiks analüüs näha välja umbes selline:

Antud juhul sobiks ilmselt enim Google Drive lahendus, sest kliendi sõnul on faile palju ja nende mahud suured.

Rühmatööülesanne

1. Alusta Scrum retrospektiiviga – mis läks hästi eelmisel korral Trellos koos tegutsedes, mida teete täna, kas on takistusi (kui on, kuidas neid eemaldada)
2. Jaotage Trellos oma rühmaliikmete vahel järgmised ülesanded:

• kirjelda samm-sammult äriprotsessi parooli taastamiseks mõnel tuttaval veebiplatvormil (Facebook, Google Drive, eKool vm) ja joonista selle kohta diagramm
• kirjelda samm-sammult äriprotsessi samas süsteemis uue kasutajakonto loomiseks ja joonista selle kohta diagramm

Kasutatud allikad:

https://courses.cs.ut.ee/2009/tvt/uploads/Main/workshop3.pdf

Yeats, D., Paul, D. (2006). Business Analysis. Swinton, United
Kingdom: British Computer Society