Vastus: 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. 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.

Võibolla 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.

Õppekavades, kus on "Andmebaasid I", on see praktiliselt ainus aine, mis puudutab süsteemianalüüsi. Seega kus siis veel kui mitte siin.

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