Oma iseseisva töö projekti tegemise käigus tuleb Teil ennast panna süsteemianalüütiku rolli. Siin on 15.02.2017 Postimehes ilmunud artikkel analüüsi olulisusest süsteemide loomisel ning sellega seotud valikutest haridusmaastikul.

Tööelus võite puutuda infosüsteemide arendamisega kokku tellijana, täitjana või näiteks tellija esindajana, kes täitjat igapäevaselt konsulteerib. Hästi toimiva infosüsteemi loomine algab õige ülesandepüstituse koostamisest. Elu näitab, et "IT-probleemide püstitamine ja kirjeldamine viisil, mis tagaks efektiivse tööprotsessi ja tõhusad lahendused", ei tule sageli nii hästi välja kui võiks. Seega ei jookse mööda külge maha oskus ülesandepüstitust (nõudeid) kirja panna. Arendaja rollis on jällegi vajalik oskus kirjapandud nõuetest aru saada.

Üheks suure infosüsteemi ebaõnnestunud arendamise näiteks on Ruumilise planeeringu infosüsteem (RPIS). See loodi detailplaneeringutete avaliku väljapaneku kättesaadavuse parandamiseks ning planeeringute kooskõlastamise kiiremaks, jälgitavamaks ja mugavamaks muutmiseks. Süsteemi arendatakse alates 2009. aastast, sellele on kulutatud peaaegu miljon eurot, kuid kasutajaid peaaegu ei ole. Kohalikud omavalitsused eelistavad teisi turul saadaolevaid süsteeme. Selle asemel, et hakata suure hooga nullist uut süsteemi tegema oleks tulnud kõigepealt aru saada, kas ning mida on vaja - võibolla oleks piisanud mõne turul oleva süsteemi kohandamisest. Sellistele küsimustele annab vastuse süsteemianalüüs. Võibolla oleks olnud ka abi tööprotsesside lihtsustamisest - sellega tegeleb ärianalüüs (business analysis), millega käesolev kursus ei tegele.

Jaakkola et al. (2016) kohaselt kasvavad nõuete kogumise (analüüsi) faasis tehtud vigade parandamiseks kuluv pingutus iga järgmise süsteemiarenduse faasiga kolm korda. Disaini faasis on neid 3, realiseerimise faasis 9 ja testimise faasis 27 korda kulukam parandada kui nõuete kogumise faasis.

Jaakkola, H., Henno, J., Welzer-Druzovec, T., Thalheim, B., Mäkelä, J., 2016. Why Information Systems Modelling Is Difficult. In SQAMIA. pp. 29– 39.

Ehk olete kuulnud sotsiaalkaitse infosüsteemi uue versiooni (SKAIS2) arendamise saagast. Praeguseks on kulud kasvanud kaugelt üle algselt planeeritu ja projekti lõppu ei paista. 2019. aasta jaanuaris kuulutati välja järjekordne riigihange süsteemi uute osade tegemiseks ning olemasolevate parandamiseks. Hanke dokumendid on avalikkusele kättesaadavad riigihangete registris ja neid tasub huvi korral sirvida selle pilguga, et:

• kui mahukas on keerulise infosüsteemi kirjeldus,
• milliseid dokumente peavad pakkumise koostajad, sh majandusinimesed oskama kirjutada,
• milliseid dokumente peavad pakkumisele reageerijad ja ka hiljem analüütikud ning arendajad oskama lugeda.

Huvi korral vaadake näiteks "Lisa 3. Nõuded infosüsteemi dokumentatsioonile", "Lisa 2. Mittefunktsionaalsed nõuded", "Lisa 1. Arhitektuuri ülevaade". Mitmed soovitud dokumentidest (sh mittefunktsionaalsed nõuded, kuid mitte arhitektuuri kirjeldus) on ka iseseisva töö projektis.

"Lisa 5. Tehniline kirjeldus" esitatud tekstilise jutu süsteemilt oodatavatest funktsionaalsustest peab süsteemianalüütik oskama tõlkida täpsemate mudelite keelde (kasutusjuhtude mudelid, protsessimudelid, seisundidiagrammid, andmemudel jne).

"Lisa 11.1. Ärianalüüs" dokumendis on väljatoodud põhimõisted ja nende definitsioonid. Selleks, et midagi koos arendada on oluline, et kõik arendusest huvitatud osapooled mõistetest võimalikult täpselt ja ühtemoodi aru saavad. Teie projektis on selliseks mõistete kataloogiks kontseptuaalse andmemudeli osaks olev olemitüüpide ja atribuutide definitsioon.

Veel üks sarnane näide on 2024. aasta veebruaris Põhja-Eesti Regionaalhaigla uue elektroonilise haigla infosüsteemi riigihange, mille hankedokumente saab samuti vaadata riigihangete registrist. "Tehniline kirjeldus lisa 1 - Funktsionaalsed nõuded" loetleb nimekirjana nii funktsionaalseid kui mittefunktsionaalseid nõudeid. "Tehniline kirjeldus lisa 2 - Protsessianalüüs" toob näitena välja mõned keerukad protsessid, mille läbiviimist uus infosüsteem toetama peab. Protsessimudelid on ülesjoonistatud BPMN (Business Process Modelling Notation) modelleerimiskeeles.

Informaatika (ilmselt ka äriinfotehnoloogia) lõputööde kaitsmiskomisjonid peavad oluliseks seda, et arenduse teemaline lõputöö ei oleks etteantud tööülesannete (nõuete) täitmise aruanne, vaid et töö käigus tegeletakse ka nõuete kogumise ja väljendamisega. Kui arendaja peab kellegi teise etteantud nõuete järgi kirjutama koodi, siis see ei sobi lõputööks või vähemasti tõmbab see hindajate silmis töö väärtust väga palju alla. Õppekavades, kus on "Andmebaasid I", on see praktiliselt ainus aine, mis puudutab süsteemianalüüsi. Seega kus siis veel kui mitte siin.

Siin, siin, siin ja siin on näide äriinfotehnoloogia lõputöödest, mille sisuks oli mahukas süsteemianalüüs. Kuid ka informaatika arenduse teemalistes lõputöödes ei tohi süsteemianalüüs puududa. Siin ja siin on näited informaatika lõputöödest, kus süsteemianalüüs on hästi olemas.

Lõpetuseks veel üks pildirida, mis illustreerib seda, mis võib süsteemi arendamise, sh analüüsi käigus valesti minna.