Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Info
titleDokument on uuendamisel

Käesolev juhend on uuendamisel, peagi ilmub uus versioon.

1.      Sissejuhatus


Juhend on mõeldud kõigile teenuste omanikele, kes puutuvad kokku IT-teenuste arendamise ja arenduste tellimisega. Tegemist on nö abimaterjaliga, mis on mõeldud täiendama justiitsministeeriumi infotehnoloogia planeerimise, juhtimise ja haldamise korra lisa 1, milleks on IT-teenuste arenduste algatamine ja läbiviimine ning IT-teenuste haldamine ja lõpetamine. Arendusprojekti planeerimine omaniku visioonist, mis tuleb vormistada lähteülesandena. Lähteülesanne on vastavalt IT-juhtimise korrale soovitava arendustöö detailne kirjeldus, mis hõlmab täpsustatud arendusvajadust ning kirjeldab põhjalikult arendustööle esitatavaid nõudeid, andmete, tööprotsessi jt infovajaduste muudatusi. Lähteülesande vormina kasutatakse MKM-i eeltaotluse vormi. Tegelikult kujutab lähteülesanne endast piisavat sisendit ärianalüütikule omaniku soovi „tõlkimiseks“ arendajale arusaadavasse keelde.

Kõnesoleva juhendi eesmärk ei ole eelnimetatud vormi ümberjutustamine, vaid tuua välja sisuliselt olulised punktid, mida LÜ peab sisaldama. RIK-i ärianalüütiku jaoks, kes hakkab teenuse omaniku soovi põhjal kirjeldama soovitud muudatust arendajale, on oluline sisu ja just see ongi antud juhendi eesmärk. IT-projektidega seotud inimeste hulgas ringleb alljärgnev pilt, mis võtab hästi kokku erinevate osapoolte soove. Kui kõiki osapooli ei kaasata või kui lõppkasutaja vajadused ei saa kirja, siis juhtub just see:

 


Seetõttu on oluline, et LÜ koostamisel mõtleks tellija järgmistele olulistele asjadele:

  • Tellitava arenduse mõju
  •  AS-IS kirjeldus
  • TO-BE kirjeldus
  • Mittefunktsionaalsed nõuded
  • Tellitava arenduse rakendamise kava ja üleminekureeglid


Küsimusele, miks on LÜ´d vaja, saab vastata järgmiselt:

  • Aeg
    • Kõigi tööaega saab kokku hoida kui välistada see, et tööd tuleb mitu korda ringi teha.
  • Raha
    • Aja kokkuhoid aitab kokku hoida topelt tööle kuluvat raha
    • Hea LÜ välistab selle, et tellitud lahendust tuleb ringi teha/uuesti teha
  • Ühine eesmärk
    • Kui algusest peale on kõigil ühine arusaam tellitavast muudatusest ja selle eesmärgist, on lihtsam projekti skoopi hoida ja ühiselt selle saavutamisse panustada
       
  • Koostöö ja kaasamine
    • Üles tuleb leida õiged inimesed, siis koostöö sujub ja lahendused tulevad kõigile osapooltele sobivad
  • Konflikti vältimine
    • Hästi läbi mõtlemata lahenduse arendamine ja juurutamine tekitab konflikte nii arendaja kui ka kasutajatega.

2.       Tellitava arenduse mõju

Soovitava muudatuse mõju võib hinnata väga erinevalt, kuid see sisend, mida ärianalüütikud tellijalt ootavad, peab vastama vähemalt alljärgnevatele küsimustele:


1.1.    Mida tellitav arendus muudab? St kui palju läheb teenuse kasutamine lihtsamaks?

1.2.    Millal saab/peab arenduse kasutusele võtma?  

1.3.    Mis juhtub kui arendatud funktsionaalsust hakatakse kasutama?

1.4.    Kas arendusega on seotud kolmandad osapooled/süsteemid? Milline on suur pilt, kus tellitav arendus asub? Hea on omada pilti nt seinal, et oleks teada?

1.5.    Kas mõju on lühi- või pikaajaline?

Kui muudatuse mõju kirjeldada, siis tuleb alati mõelda tegevuste optimeerimisele ja lihtsustamisele. Muudatus ei saa olla vajalik selleks, et paberprotsessi digimaailmas üks-üheselt peegeldada, alati on võimalik leida kohti, mida saab lihtsustada või mida peab kasutaja tegevustes muutma. Lõppkasutajate jaoks tekitab iga muudatus segadust ja nad kipuvad jääma kinni hetkeolukorda, kuid siinkohal saabki omanik otsustada ja kasutajaid suunata, koolitada ja läbi rääkida, kuidas peaks ja võiks kasutaja tegevused muutuda ning selgitada, mis läheb lihtsamaks. Kui omanik on oodatud tulemuse enda jaoks läbi mõelnud, on väga lihtne kirjeldada ära muudatuse mõju ning tellida uus teenus või teenuse muudatus lõppkasutajate heaolu arvestades. Lõppkasutajate kaasamine on äärmiselt oluline juba visiooni kujundamisel, ära ei tohi unustada ka ärianalüütikut, kes saab anda soovitusi parima protsessi kujundamiseks. Ärianalüütik oskab aimata ja soovitada, kuidas visiooni teenuses realiseerida.

Muudatuse haldus on võtmesõna, lisaks teenuse/protsessi muutmisele vastutab omanik ka kasutajate igapäevaste tegevuste muutmise eest (need tegevused, mis ei sõltub otseselt infosüsteemist).

Muudatuse mõju hindamisel tasub kindlasti mõelda lõppkasutajate jaoks tajutavale muudatusele, st kuidas nende käitumine muutub. Lõppkasutajate käitumise tundmaõppimiseks on kõige parem kasutada persoona-põhist lähenemist.


NB! Majandusliku kasu ehk tasuvuse tõestamine ei ole RIK-i jaoks oluline, pigem on see vajalik juhtkonnale otsuste tegemiseks.  

3.       AS-IS kirjeldus või viide

Hetkeolukorra kirjeldamine on oluline selleks, et kõik projektiga seotud osapooled teadvustaksid, milline on hetkeseis, mida muutma minnakse. Vastavalt LÜ koostamise vormile tuleb selles punktis välja tuua:

3.1.    Finantsiline ülevaade;

3.2.    Protsesside lühiülevaade;

3.3.    Kasutajate rahulolu ülevaade;

3.4.    Meetrika selgitus;

3.5.    Tehniline ülevaade

Ärianalüütiku vaatest on kõige olulisem AS-IS protsesside lühiülevaade, milles tuleb ära märkida vähemalt:

  • Viide varasemale arendustellimusele, kasutusjuhendile vms.
  • Kuidas asi täna käib, st milliseid tegevusi tehakse ja millised on iga tegevuse põhisammud.
  • Miks see täna nii on, st miks selline protsess ja reeglid üldse kokku lepiti.
  • Põhirollid AS-IS protsessides, st kes on peamised osapooled ja mida nad protsessis teevad.
  • Kindlasti ei tohiks kopeerida seaduse või määruse teksti


Halvad näited:

a. Täna antud protsessi elektroonilisel kujul olemas ei ole.

b. Tellija  ei tea isegi täpselt, et kuidas senine protsess õieti toimib.


Kui protsessi elektroonilisel kujul olemas ei ole, siis tuleb ära kirjeldada paberprotsessile toetuv olukord. See annab ärianalüütikule infot selle kohta, millised harjumused ja praktika on teenuse kasutajatel täna ning millised on nende ootused.

Hea näide:

Näide aastast 2007, kui osaühingu asutamisel ettevõtjaportaali kaudu ei saanud veel avada ühingule e-stardikontot vaid pidi osakapitali kohtu deposiitkontodele kandma. Alljärgnevas kirjeldatakse protsessi muudatusi.

Hetkel toimiv protsessimudel (AS_IS)

  1. Kasutaja siseneb portaali      autoriseerides end ID-kaardi abil.
  2. Kasutaja täidab ettevõtte loomiseks      esmakandeavalduse.
  3. Kasutaja (asutajad ja juhatus)      allkirjastavad esmakandeavalduse digitaalselt ID-kaardi abil.
  4. Kasutaja tasub internetipanga kaudu      avalduse menetlemiseks nõutava riigilõivu.
  5. Kasutaja kannab pangalingi vahendusel      ühe maksega kohtu deposiitkontole osakapitali rahalise sissemakse.
  6. Kasutaja saadab avalduse menetlusse.
  7. Kohtu registriosakond kannab      ettevõtte registrisse hiljemalt järgmisel tööpäeval (kui avalduses puudusi      ei ole).
  8. Kasutaja läheb pangakontorisse ning      avab ettevõttele arvelduskonto.
  9. Kasutaja siseneb taas portaali ning      esitab avalduse osakapitali sissemakse tagasikandmiseks kohtu      deposiitkontolt ühingu kontole.
  10. Kohtute raamatupidamiskeskus kannab      osakapitali sissemakse tagasi 5 tööpäeva jooksul.

 

 Protsessi nõrgim lüli (kõige aeganõudvam samm) on osakapitali edasi-tagasi liigutamine, mis üldjuhul võtab aega 4-5 tööpäeva. Seetõttu pakutakse tulevikus pankade vastutuleku korral ettevõtjale võimalust koos ettevõtte asutamisega luua samas portaalis ettevõtte stardikonto (deposiitkonto), kuhu saab kohe üle kanda osakapitali rahalise sissemakse. Peale ettevõtte registrisse kandmist saab ettevõtja pangakontoris vormistada stardikonto ümber arvelduskontoks.


Vana protsessi hinnanguline kestus:
(vaadatakse tegevusi mille kestus ei sõltu kasutajast, näiteks avalduse menetlemine ning osakapitali tagastamine). 

    • Parim juht – 4 tööpäeva.
    • Keskmine juht – 5 kuni 6 tööpäeva.
    • Halvim juht – 7 tööpäeva.

4.      TO-BE kirjeldus tegevuste lõikes

Vastavalt LÜ koostamise vormile tuleb selles punktis välja tuua oodatava mõõdetava lõpptulemuse kirjeldus, mille saavutamisel saab projekti pidada edukaks:

4.1.    Finantsilised eesmärgid

4.2.    Protsesside muudatuste ülevaade

4.3.    Kasutajate rahulolu

4.4.    Tehnilise lahenduse muudatuse ülevaade

Ärianalüütiku töö jaoks on kõige olulisem protsesside muudatuste kirjeldamine ehk omaniku TO-BE visioon. TO-BE kirjeldamine tähendab järgmistele küsimustele vastamist:

  • Kuidas peaks asi käima?
  • miks see peab nii käima?
  • millised on rollid muudetud tegevustes? mis seal muutub - tuleb juurde uusi rolle,       kasutajate arv muutub vms?
  • seos eelnevate ja järgnevate arendustega
  • kolmandate osapoolte/süsteemide seos uute/muudetud tegevustega
  • viide seadusele, määrusele vms koos lühikirjeldusega (nt viide seletuskirja       punktile, §-le jne)
  • kuidas uus lahendus muudab kasutaja tegevusi (nii süsteemis teostatavaid tegevusi kui ka süsteemiväliseid tegevusi)?


Lisaks kirjeldamisele võib oma soovi visualiseerida, st joonistada üles tegevuste jada, lihtsustatud äriprotsesse, koostada mock-up´e jne. Ka siin kehtib ütlus: „Üks pilt räägib rohkem kui 1000 sõna“. Tellija ülesanne on ära kirjeldada oodatud tulemus, see, kuidas selleni jõuda ja mida täpselt peab süsteemis ringi tegema, võiks jääda äri- ja analüütiku otsustada.

Kui soove on palju, siis:

  • võib välja tuua ka erinevad alternatiivid, märkides ära ideaalvajaduse;
  • peab välja tooma muudatuste tähtsusjärjekorra koos põhjendustega.

Halb näide:

KIS2-s telliti vastusnõude ja edasikaebuste tähtaegade kohustuslik märkimine. Tellimus oli otseselt seotud dokumendi ehk toimingu kinnitamisega ning esitatud kujul "Toimingut ei tohi saada enne kinnitada, kui tähtaeg on märgitud". Kui arendus oli tehtud, avastati, et kasutajate tööprotsess käib mõnedes olukordades teistmoodi ning sageli kinnitatakse toiming enne tähtaegade märkimist. Kui tellija oleks teinud AS-IS TO-BE skeemi ning uurinud alternatiivkäitumiste olemasolu kohta, oleks välja tulnud, et osade kasutajate tegevus toimub enne tähtaegade märkimist, kuid peale dokumendi esmast kinnitamist.

Hea näide:

Uus protsessimudel (TO_BE):

  1. Kasutaja siseneb portaali autoriseerides end ID-kaardi abil.
  2. Kasutaja täidab ettevõtte loomiseks  esmakandeavalduse.
  3. Kasutaja (asutajad ja juhatus) allkirjastavad esmakandeavalduse digitaalselt ID-kaardi abil.
  4. Kasutaja tasub internetipanga kaudu  avalduse menetlemiseks nõutava riigilõivu.
  5. Kasutaja avab portaali ja      internetipanga abil asutatava ettevõtte stardikonto.
  6. Kasutaja (asutajad) kannab ühe või  mitme maksena stardikontole osakapitali rahalise sissemakse.
  7. Pank saadab ettevõtjaportaalile digitaalse kinnituse osakapitali sissemakse tasumise kohta.
  8. Kasutaja saadab avalduse menetlusse.
  9. Kohtu registriosakond kannab ettevõtte registrisse hiljemalt järgmisel tööpäeval (kui avalduses puudusi ei ole).
  10. Kasutaja läheb pangakontorisse ning vormistab stardikonto ümber arvelduskontoks.

Uue protsessi hinnanguline kestus:

(vaadatakse tegevusi mille kestus ei sõltu kasutajast, näiteks avalduse menetlemine ning osakapitali tagastamine). 

  • Parim juht – 2 tundi.
  • Keskmine – 1 tööpäev.
  • Halvim juht – 2 tööpäeva.

5.      Mittefunktsionaalsed nõuded

Mittefunktsionaalsed nõuded kipuvad kõige sagedamini ununema või siis ei pöörata neile piisavalt tähelepanu. Lähteülesannet koostades tuleks alati mõelda läbi, milliseid muudatusi ISKE nõuetes või SLA´s kirjeldatu kaasa võib tuua.

Üldjoontes defineerivad funktsionaalsed nõuded, mida süsteem peab tegema, ning mittefunktsionaalsed nõuded defineerivad, milline süsteem peab olema. Funktsionaalsed nõuded on üldiselt vormis "süsteem teeb <nõue>", individuaalne tegevus, mis on osa süsteemist, mille juurde see kuulub. Mittefunktsionaalset nõuet esitatakse kujul "süsteem hakkab olema <nõue>" ehk üldine süsteemi omadus või mingi eriline aspekt ja mitte täpne funktsioon. Süsteemi üldised omadused tavaliselt näitavad, kas projektiarendus on õnnestunud või läbikukkunud (allikas).

5.1.   ISKE


ISKE kujutab endast infosüsteemide kolmeastmelist etalonturbe süsteemi ja infoturbe standardit, mille eesmärk on tagada teenuse töö ja terviklus. ISKE nõuete kirjeldamisel on aluseks võetud BSI IT Grundschutz Handbuch.  Täpsemalt saab lugeda ISKE turvaklassi määramise juhendist: https://www.ria.ee/et/kuberturvalisus/infosusteemide-turvameetmete-susteem-iske.html

ISKE´l on kolm astet:

  • Käideldavus - eelnevalt kokkulepitud ajal andmete kättesaadavus – K0, K1, K2, K3
  • Terviklus - andmete õigsuse tagatus  - T0, T1, T2, T3
  • Konfidentsiaalsus - andmete kättesaadavus ainult selleks volitatud tarbijaile – S0, S1, S2, S3


LÜ´ s tuleb vastata järgmistele küsimustele:


1. Kas olemasoleva teenuse puhul ISKE muutub? Muutmise vajadus sõltub andmetest, sest ISKE tuleb määrata alati lähtuvalt andmetest, mida teenus kasutab. Kui andmekoosseis muutub, siis tuleb üle vaadata, kas ISKE klass vastab, nt kui tekib vajadus koguda delikaatseid andmeid, mida varem ei kogutud, siis võib muutuda ka konfidentsiaalsuse turvaklass.

Halb näide:

Määratakse nt S0, kui reaalne vajadus on S2 või vastupidi. Halb näide on ka see, kui andmekoosseis muutub, aga ISKE jääb üldse üle vaatamata.

2. Mis on uue teenuse ISKE klass)  Määramine toimub vastavalt ISKE juhendile, täpsemaid häid soovitusi siinjuures ei olegi, st sõltub andmetest. Kui puudub raha ISKE rakendamiseks, siis tuleb koostada jääkriskide kaardistus ja teha plaan, kuidas tulevikus ISKE tagada. Nt kui teenus kasutab delikaatseid isikuandmeid, siis ei saa määrata konfidentsiaalsust 0-ks vaid põhjendusel, et raha ei ole. Tuleb määrata õige klass ja kirjutada juurde, millistel põhjustel seda rakendada ei saa.

Halb näide:

ISKE on määratud suvaliselt ja selle määramiseks ei ole tehtud analüüsi.

5.2.   SLA

SLA ehk Service Level Agreement sõlmitakse IT-teenuste kvaliteedi haldamise ja parendamise tagamiseks, sätestades teenustaseme kokkuleppe sõlmimise tegevused, vastutajad ja parameetrid. Tegemist on kokkuleppega teenuse pakkuja ja omaniku vahel. Juhend SLA koostamise kohta: https://rik.just.sise/dokument/naidis-iske-turvaklassi-ja-sla-koostamiseks

 

1. Olemasoleva teenuse puhul tuleb vastata küsimusele, kas SLA muutub? Ideaalis tekib muutmisvajadus teenustaseme leppe aruandest (SLA aruanne tellijatele), nii nõuete muutmise kui infra vajaduste osas. Kui tellija ei ole aruandeid saanud, siis tuleks vaadata, millistel põhjustel neid ei ole ja kas SLA on üldse mõõdetav. Häid näiteid on siinkohal mitmeid: nt vajadus uuendada infrat, optimeerida/parandada teenuse reaktsiooniaegu jne. SLA esmakordne ülevaatamine ei saa jääda projekti lõppu, seda tuleb teha IT-teenuse tellimise ja arendamise faasis ning vajadusel paralleelselt seda täiendada. Pärast viimast juhtrühma toimub SLA sõlmimine, mis on olemuselt pigem lõplik vormistamine.

Hea näide:

Kui teenustaseme vajadus muutub, siis küsitakse, kas on ka SLA-d vaja muuta. Sisend tellijale tuleb sisuosakonnast või infrast koos põhjendustega.

Halb näide:

Muutmisvajadus jääb üldse tähelepanuta.


2. Uue teenuse puhul SLA kinnitatakse küll hiljem, kuid LÜ faasis on vaja teada:

  • Maksimaalne kasutajate arv. Eristada tuleb maksimaalset kasutajate arvu (palju on teenusel reaalselt kasutajaid) ja maksimaalseid üheaegseid kasutajaid, mis on sisendiks koormustestidele! Esimesel juhul on vaja teada tavapärast kasutajate arvu.


Halb näide:

Kunagi oli meil korraga 1500 kasutajat, tegemist ei ole tavapärase olukorraga.
Teisel juhul on vaja teada võimalikke teenuse kasutuse "kõrghetki", palju peab süsteem olema võimeline kasutajaid korraga teenindama.

 

Hea näide:

Siinkohal on asjakohane viidata, et kunagi oli meil korraga 1500 kasutajat.
 

  • Tööaeg. Oluline on endale teadvustada, et tööaja klassi tõstmine võib kaasa tuua lisakulud nt valveadministraatori lisandumisega. Üldreegel on, et tööaeg I määratakse nendele teenustele, mida kasutatakse tavapärasel tööajal (E-R 8-18). Tööaeg II määratakse nendele teenustele, mille kasutamise vajadus jääb väljapoole öötöö aega (6-22) ja tööaeg III nendele teenustele, mis on 24/7 kasutuses. Tööaeg II ja III võivad kaasa tuua lisakulusid nt valveadministraatori lisandumisega.


Halb näide: 

Soov on saada teenust tööajaga I, aga hooldustöid võib teha ainult peale kella 23, siis ei saa määrata tööajaks I-te, vaid reaalne vajadus on III.

 

  • Reaktsiooniajad. Mõelda, kas funktsioon on teenuse jaoks oluline, mis näitaks teenuse kvaliteetset toimimist ja kas funktsioon on mõõdetav. Sest, milleks kokku leppida funktsioone, mida mõõta ei saa (mis see vajadus on?) Kui mõõta ei saa, aga siiski on olemas vajadus, siis märge juurde, et aeglus vaadatakse üle tellija pöördumise korral.

Halb näide:

SLA-sse on kirjeldatud ~30-100 funktsiooni reaktsiooniaega, millest 90% kas ei saa mõõta või ei ole vaja mõõta.

Hea näide:

Kirjeldatud on ainult vajalikud funktsioonid, mida on võimalik ka mõõta.

Kuldreegel: kirjeldada neli funktsiooni, mis toimivad ka teenuse toimivuse/püstioleku indikaatorina.

  • Kriitilisuse klass. Mõelda, milline on reaalne vajadus ning millised nõuded see infrale esitab. Peamine erinevus tuleb taasteaegade pikkustest (I - taasteaeg kuni 2 ööpäeva, II - taasteaeg kuni 7 ööpäeva, III - taasteaeg kuni 21 ööpäeva ja IV - taasteaeg kuni 28 ööpäeva). Kriitilisuse klassist sõltub otseselt teenuse maksumus! Samuti annab see funktsionaalsusnõuete sisendi arendusele.

 

Halb näide:

Tellijalt info, et teenus on ülioluline ja kõige kriitilisem, aga kui küsida, mis siis juhtub kui teenus ei ole nt 1 päev kättesaadav, siis on vastus, et ei juhtugi midagi.

Hea näide:

Tellija adub reaalselt teenuse vajadust ning mõistab, millised on riigi jaoks tegelikult olulised teenused.
 

Kriitilisuse klass

Infrastruktuuri ressurss (server, storage,   võrgukomponendid)

Lülitused teise saiti

Andmete replikatsioon

Sideoperaatorid

I

1 sait klastris ja 2 sait ei   pea olema klastris, peab   olema tagatud 1.sait n+1, 2. sait   n       võrguseadmete osas mõlemas saidis n+1   olemas, 1. saidis dubleeritud   võrguseadmed, 2. sait dubleeritud   võrguseadmed

1 x poolaastas

Sünkroonne või asünkroonne     (viivitus kuni 15 minutit),   kõik infosüsteemi komponendid

2 tk avalike teenuste puhul,   muidu 1 tk

II

1 sait klastris ja 2 sait ei   ole klastris    võrguseadmete osas mõlemas saidis n+1     olemas, 1. saidis dubleeritud võrguseadmed, 2. sait dubleeritud võrguseadmed

-

asünkroonne (viivitus kuni 1   tund), andmed on olemas ja   halduri jaoks vaadeldavad

1 tk

III

1 sait klastris (või teisel riistvaral käivitatav   SLAs   lubatud planeerimata katkestuse jooksul) ja 2 saiti ei ole

-

asünkroonne (viivitus kuni 1 tund), toimub ainult   andmete   sünkroniseerimine

1 tk

IV

1 server (ei pea olema klastris) ja 2 saiti ei ole      võrguseadmete osas mõlemas saidis n+1   olemas, 1. saidis dubleeritud   võrguseadmed, 2. sait dubleeritud võrguseadmed

-

-

1 tk


5.3.    Nõuded kujundusele

Lähteülesannet koostades, eriti uue teenuse lähteülesande puhul tuleb mõelda, kas ja millise sümboolikaga tuleb uue süsteemi loomisel arvestada. Nt kas tuleb kasutada väikest riigivappi?

Erinevate sisuelementide rakendamise reegleid ja juhiseid kasutajaliidestes on ära toodud siin:

http://uig.rik.ee/


Head näited:

a. Süsteemis tuleb keskselt kasutada vanglateenistuse värvilahendust (must-kuldne-valge)

b. Oluline info tuleb infosüsteemis esile tõsta kasutades selleks läbivalt ühte lahendust. Näiteks punast värvi.


Halvad näited:

a. Süsteem peab olema ilus ja mugav kasutada.

b. Süsteem peab vastama riigikantselei stiilijuhisele https://riigikantselei.ee/et/node/1156


5.4.   Avaandmed


Avaandmed on avalikult vabalt kasutamiseks antud, veebist kättesaadavaid, masinloetavas formaadis toorandmeid ilma kasutamis-, patentide- ja levitamispiiranguteta.
Riigile kuuluvate andmekogude avaandmeid puudutav info on koondatud avaandmete portaal: https://opendata.riik.ee/about
RIK-i poolt hallatavate andmekogude avaandmed on kättesaadavad siit: http://www.rik.ee/et/avaandmed


Vastata tuleb küsimusele, kas avaandmete osa tuleb luua või olemasolevat täiendada/muuta? Sarnaselt mittefunktsionaalsetele nõuetele ei pöörata avaandmeid puudutavale piisavalt tähelepanu, mistõttu võib see projekti lõppfaasis tekitada liigset segadust ja nõuda täiendavaid arendusi.


Hea näide:

Olemasolevatele avaandmetele tuleb lisada kaks uut andmevälja – otsuse koostamise kuupäev ja otsuse koostaja. Uusi andmevälju võib välja kuvada alles alates 01.01.2017 tehtud lahendite puhul, varasemate lahendite andmete kuvamist muutma ei pea.

Halb näide:

Avaandmed on kõik süsteemis olevad andmed.


5.5.   Logimine - millest peab jälg maha jääma?

Lähteülesanne peab andma vastuse, kuidas see mõjutab logimist, st millistest tegevustest peab süsteemis jälg maha jääma. Logimise säilitamise vajadus lepitakse kokku SLA-s. Oluline on, et tellija oskaks küsida, mida on vaja logida või küsiks, mida hakatakse logima, et otsustada nende säilitamise vajaduse üle. Nt kas teenuses on raamatupidamisega seonduvaid andmeid, siis säilitamise kohustus 7 aastat, aga ka nt distsiplinaarsüütegude aegumise aeg jne. Hea näide: tellijal on ülevaade, mida logitakse ning oskab nende säilitamise vajadust sisuliselt põhjendada.

Hea näide:

Kõik kasutajate tehtud sissekanded ja muudatused tuleb logida selliselt, et oleks võimalik teha väljavõte, kus kajastuks andmeid vaadanud kasutaja nimi, kande tegemise/muutmise kuupäev ja kellaaeg ning sisestatud/muudetud kanne.

Halb näide:

Kõiki andmeid tuleb logida ja igavesti säilitada.

 

5.6.    Tõestusvajadus - millistel andmetel on tõestusväärtus

Teenuse omanik peab siinkohal vastama küsimusele:

  • Millistel andmetel on tõestusväärtus?
  • Millised on nõuded andmete ja dokumentide arhiveerimisele?
  • Millised on säilitustähtajad?

Nt aja- või digitembeldamise vajaduse lisandumine mõjutab arendatava funktsionaalsuse mahtu märgatavalt, mistõttu tuleks juba lähteülesannet koostades mõelda, kuidas peab andmeid kaitsma. Samamoodi on oluline mõelda arhiveerimisele, st kas kasutajad peavad ise saama alustada andmete arhiveerimist või nende hävitamise aktide koostamist. Vastata tuleb küsimusele, mida arhiveerimine tegelikult tähendab? Kas need andmed ei tohi olla enam kättesaadavad kasutajatele jne.


Lisaks tuleks mõelda, kas andmed on arhiiviväärtusega, st kas juba ette tuleb mõelda andmete arhiivi üleandmisele ja vastav funktsionaalsus luua.


Hea näide:

Tõestusväärtust omab ainult toimiku funktsionaalsus. Kõik toimiku funktsionaalsusega seotud kannete sisestamised ja muutmised tuleb ajatembeldada. Toimik ja kõik selles sisalduvad andmed arhiveeritakse lõpp kuupäeva täitumisel ja arhiveeritud toimikut säilitatakse 5 aastat.


5.7.    Mis seadmetega peab saama teenust kasutada?


Ärianalüütik ootab siinkohal vastuseid:

  • Kas on vaja nt mobiilile kohandatud vaateid?
  • Mis osa funktsionaalsusest peab teistes seadmetes olemas olema? Kas piiratud funktsionaalsus või kõik?


Head näited:

a. Tahvelarvutitel ja välisvõrgust peab kasutatav olema piiratud funktsionaalsus: s.o. funktsionaalsus 1, funktsionaalsus 2 ja funktsionaalsus 3

b. Süsteem peab olema kasutatav ka tahvelarvutites. (Kõige väiksem ekraan, millel süsteem peab olema kasutatav on iPad2)

 

Halb näide:

Peab olema kasutatav tahvelarvutitel


5.8.   Kas on eelistusi tarkvarale?

Kuigi tark- ja riistvaralised lahendused on reeglina RIK-i pärusmaa, siis on tellijal võimalik öelda, milliste tarkvaraga lahendus peab töötama.


6.      Tellitava arenduse rakendamise kava, sh üleminekureeglid vanalt lahenduselt uuele  


Arendusprotsessi läbiviimise üldine tegevuste järjekord:


Algatamine -> Tellimine -> Arendamine -> Juurutamine -> Stabiliseerimine -> Projekti lõpetamine


Juurutamine on tugevalt seotud muudatuste halduse protsessiga. Juurutamiseks nimetatakse aega ja tegevusi, kus tarkvara jõuab arendusest lõppkasutaja kätte (algab rutiinne töö).

Juurutamiseks vajalikud tegevused ja otsused peavad saama läbi mõeldud juba projekti planeerides ja algatades, st lähteülesannet koostades või rahastustaotlust koostades, kuna vastused mõjutavad projekti nii ajaliselt kui ka rahaliselt. Näiteks: väljast koolituste tellimine maksab lisaraha; andmesiire on reeglina kallis tegevus, samuti andmeparandused; paralleelkasutuse puhul ristandmesiire - keeruline ja kallis tegevus.


Küsimused, millele teenuse omanik peab vastused leidma, on järgmised:

6.1.    Andmetega seonduvad küsimused

6.1.1. kas vanu andmeid on vaja siirata? Kui on vaja, siis tuleb läbi viia olemasolevate andmete analüüs ja tuvastada:

          
      • millised andmed on vaja siirata?
      •   
      • kas osad andmed võib/peab siirdama nö arhiivi kujul        (aktiivsed/passivsed andmed)? (Näiteks, ET-s KOLA andmed on passiivsed        ja XML kujul mitte baasitabelites.)
      •   
      • milline on olemasolevate andmete kvaliteet?
      •   
      • kas ühed andmed on millegi poolest tähtsamad kui teised? (annab sisendi selleks, kui palju andmeid on vaja parandada enne siiret ja mis järjekorras siirata)
          
      • milline peab olema siirdatavate andmete kvaliteet uues süsteemis? 

6.1.2. kes tegeleb andmekvaliteediga - kontrollib, täiendab/parandab vanu andmeid?


Soovitus: vältida tuleb ebakonkreetseid nõudeid, mis näitavad, et ülemineku tegevuste peale mõeldud ei ole. Kasutada tuleb kindlat kõneviisi, kindlate tähtaegadega ja konkreetse sisuga.


Head näited:

a. Uude süsteemi tuleb üle viia kõik ülemineku faasis pooleliolevate toimingutega seotud andmed (nt andmed x, y ja z). Üleviidavas andmestikus tehakse enne andmesiiret parandusi. Vanas süsteemis olev andmestik, mida üle ei viida, tuleb säilitada kuni 2 aastat peale uue süsteemi rakendumist.

b. "Üleviidavast andmestikust on oluline x, y ja z.

c. Üleviidavast andmestikust tuleb korda teha y, z ja k

d. Vana teenuse/süsteemi toetamine peab olema eelkõige p ja r raames 

e. Vana teenuse/süsteemi kasutamine jätkub kuni xx.xx.xxxx, peale seda on tegevused f ja g 



Halvad näited:

a. Kõik andmed tuleb olemasoleval kujul üle viia.

Mis andmed, mis kujul, kas ka dokumendid jne? Selline sisend tekitab rohkem küsimusi kui vastuseid ning arendusmahu hindamiseks ja/või ärianalüüsi alustamiseks tuleb koheselt hakata täpsustavaid küsimusi esitama. Selline sisend näitab, et tellija ei ole üleminekureegleid tegelikult ise täpselt läbi mõelnud.

b. Toetada vana teenuse/süsteemi toimimist kuni selle järgi kaob vajadus.

Kellel kaob vajadus, mis ajaks ikkagi, mis osas jne. 


6.2.    Koolitusega seotud küsimused 

6.2.1. kas on vaja koolitada? 

6.2.2. kui palju koolitavaid on? Mitu koolitust, mitmes kohas? 

6.2.3. kas piisab peakasutajate koolitusest?

6.2.4. kes koolitab? Kas saame ise koolitamisega hakkama? Tellime väljast?

6.2.5. esimesel päeval rakendada hoopis nö käehoidmist kasutajate juures?

6.2.6. kasutusjuhendid - kas on vaja ja milliseid on mõistlik küsida?


Lõppkasutajate koolitamine ei ole ainult arenduspartneri või ärianalüütiku ülesanne, sest reeglina teab iga kasutaja, et nupp "Salvesta" salvestab andmed. Lõppkasutajat huvitab, miks selline muudatus üldse tehti, kuidas see mõjutab tema igapäevatööd ja milline on muudatusega seotud õiguslik regulatsioon. Ärianalüütik ei pea ega tohi asuda õigusakte või Riigikohtu lahendeid tõlgendama.

Arendusprojekti ajakava on varasemalt kokku lepitud ja see võimaldab omanikul planeerida oma aega nii, et ta saab koolitustest ja nende planeerimistest osa võtta.


Head näited:

a. Kasutajate koolitamine toimub rakendamise eelselt infopäevana. Koolituse viivad läbi tellija ja RIK

b. Koolitused toimuvad piirkonniti ühe kuu jooksul peale süsteemi rakendamist. Koolitab tellija.

c. Pakkuja korraldab auditoorse sisulise koolituse süsteemi lõppkasutajatele. Koolituse sisuks on uue menetlustarkvara funktsionaalsuse kasutamine ja haldamine. Koolituspäev salvestatakse ning antakse DVD-l üle tellijale.


Halvad näited:

a. Koolitust lähteülesandes ei mainitagi.

b. Omanik ei osale koolitusel.

c. Koolitusele kaasamist ja osalemist ei mõelda läbi.


6.3.    Testimisega seotud küsimused

6.3.1. kas lõppkasutajad on testimisse kaasatud?

6.3.2. kuidas on testimine planeeritud?

Lõppkasutajate kaasamine testimisse ei ole ainult arendustiimi ülesanne. Siinkohal on oluline roll omanikul, kes aitab planeerida ka lõppkasutaja kaasamist ja vajadusel nende ressurssi, nt on kohtutes määratudki lõppkasutajate esindajad, kes kokkulepitud mahus ja ajal panustavad uue või muudetud teenuse testimisse. Praktikas on olnud palju halbu näiteid, kus lõppkasutajad ei taha või leia testimiseks aega ning seetõttu kannatab oodatud tulemus, sest seda lihtsalt ei saavutata.

Testimist korraldatakse testkeskkonnas testandmetega ning seal võib ja peabki tekitama keerulisemaid olukordi, milles vigade ilmnemine on suurema tõenäosusega.

RIK ja arenduspartner tagavad tehnilise testimise, kuid lisaks ärianalüütikule on olulune, et igapäevaseid tegevusi testivad lõppkasutajaid, kes teenust oma igapäevatöös kasutama hakkavad. See tagab selle, et erinevate piirkondade praktikat on võimalik ühildada ja teha kiireid parandusi kui see on võimalik. Praktikas on esinenud olukordi, kus lõppkasutajate kaasamine testimisse on välja toonud asjaolu, et üks peamisi igapäevaseid tegevusi on täiesti realiseerimata ning seda ei ole kajastatud ei LÜ, ärianalüüsis ega süsteemianalüüsis. Põhjuseid vüib olla erinevaid, kasvõi see, et omanik ega ärianalüütik ei teadnudki konkreetset praktikast.


Hea näide:

Testimine toimub 7 piloodina lõppkasutajate poolt. Igal piloodil viiakse kasutajateni üks suurem funktsionaalsus ning lõppkasutajatel on võimalik funktsionaalsust paralleelselt olemasoleva süsteemiga kasutada kuu ajalise perioodi vältel. Igas pilootgrupis on kuni 10 spetsialisti ning iga piloodi järgselt viiakse parandusettepanekud funktsionaalsusesse

Registriosakonna töötajatele tuleb korraldada periooditi testpäevi või võimaldada demokeskkonna kaudu neil täisfunktsionaalse prototüübiga tutvuda.


Halb näide

Testimist lähteülesandes ei mainitagi.


6.4.    Piloteerimisega seotud küsimused

Väga lihtne on vastata, et süsteemid/teenused peavad paralleelselt töötama, keerukam on aga selgitada, mis osa on vanast süsteemist tähtis ja miks. Just seda selgitust ootab ärianalüütik omaniku poolses sisendis.

6.4.1. Kuidas toimub piloteerimine? 

6.4.2. Kas ja miks uus ning vana teenus peavad paralleelselt töötama?

6.4.3. Kui kaua on vaja vana ja uue süsteemi paralleelkasutust?

6.4.4. millised kasutajad peavad mõlemat süsteemi kasutada saama?

6.4.5. kas paralleelkasutus on seotud asukohtade või asutustega?

6.4.6. mis saab paralleelkasutuse käigus sisestatud andmetest? kas nende jaoks on vaja lisasiiret?

6.4.7. kas uue teenuse rakendamine toimub etapiviisiliselt? millisteks etappideks on see jagatud?

 

 Suuremaid muudatusi on otstarbekas piloteerida näiteks ühes piirkonnas, asutuses või struktuuriüksuses. Piloteerimine tähendab tellitud lahenduse sobivuse kontrolli reaalses olukorras reaalsete andmetega eesmärgiga leida üles kohad, mis vajavad täiendamist. Testimine ei ole enamasti samaväärne reaalse igapäevatööga ja andmetega, olenemata sellest kui palju on testimisega kaetud. Piloteerimine aitab veenda lõppkasutajaid lahenduse sobivuses ja leevendab üleminekuga seotud negatiivseid emotsioone.


Head näited

a. X projekti eesmärgiks on viia kaks suuremat süsteemi ühele platvormile ja lisada sinna täiendavat funktsionaalsust. Projekt on jaotunud kolmeks etapiks 1) Y andmekogu kasutajateni viimine 2) Z andmekogu kasutajateni viimine 3) täiendava funktsionaalsuse loomine.

b. X registrisse üle viimisel andmesiiret ei teostata. Kõik live hetkel süsteemis olevad aktiivsed toimingud lõpetatakse vanas süsteemis. Kõik uued toimingud live järgselt luuakse Y registrisse. Paralleelkasutus toimub kuni kõik pooleliolevad toimingud on lõpetatud ning seejärel antud süsteem sulgetakse.

c. Toimus paber protsessilt üleminek täisdigi protsessile. Vältimaks andmete siirdamist ja tagantjärgi sisestamist otsustati võtta uus süsteem kasutusele ainult uute asjade puhul. Vanades asjades säilis vana protsess ja andmebaas. Peale puhverperioodi, kus vanad asjad saavad oma loomuliku lõpu, toimub protsess ainult uues süsteemis. Uue kasutusele võtmisel peab aga mõtlema, kuidas lahendada peale puhverperioodi mitte lõpetatud asjade süsteemi kandmine ehk kui algsfaasis sellest loobuti, siis suure tõenbäosusega nõuab see siiski mõningast arendustööd.


Halvad näited

a. Uuele süsteemile minnakse üle etapiviisiliselt, kuid etapid ei ole läbimõeldud ja kasutaja peab tegema pooled tegevused vanas süsteemis, pooled uues.

b. Probleemide ilmnemisel läheb tellija/tellimise projektijuht otse arendaja juurde kaasamata süsteemiga seotud ärianalüütikuid ja süsteemianalüütikuid. Parandused ja parendusettepanekud tellijalt viiakse küll sisse kiirelt ja lõppkasutaja mured saavad ajutise leevenduse, kuid sellised lahendused:

  • ei ole spetsifikatsioonis fikseeritud - keegi ei tea pärast miks ja mida tehti, mingit algelist infot saab ainult programmi koodist, küll aga sealt ei saa lahenduse põhjuseid.
  • ei pruugi olla jätkusuutlikud, kuna lahendajad ei vaadanud probleemi laiemalt ning lahendus põhjustab omakorda teisi probleeme tulevikus.


c. X üleminek uuele süsteemile oli järk-järguline, mis lisaks ühekordsele andmesiirdele, nõudis ka igapäevaseid kahepoolseid andmesiirdeid, sest nii vanas kui uues rakenduses pidid olema nähtavad ja töödeldavad andmed, olenemata nende päritolust. Andmesiirded olid teostatud äriloogikat puutumata ning seetõttu esines hiljem tõrkeid andmete kasutamisel kummaski süsteemis. Tegelikkuses tuleb ka andmesiirete puhul äriloogikaga arvestama. Olukordades, kus tuleb teha möönduseid (nt võtta siirde ajaks mingid konktrollid/piirangud maha), tuleb teha selged piirangud ja kokkulepped - kui kauaks piirang maha võetakse ja millal peab see olema tagasi pandud, et süsteemid saaks oma tööd edasi veatult teha ja kasutajate töö poleks häiritud. Juhtus aga see, et baasipiirangud (mis tohib olla NULL ehk tühi, täitmata, ja mis mitte ning millises olukorras) võetakse siirde ajaks maha ja siis ei pandagi tagasi. Ja seega taoline paralleelne toimimine, mille ajal piirangud tuli maha võtta ja selge tähtajata sedasi hoida, tootis hulga "katkiseid" andmeid, mille parandamine ja haldamine esineb tihedalt käesoleva ajani.


6.5.    Live´i viimise ja selle eeldustega seotud küsimused


6.5.1. Kuidas minnakse uuele süsteemile üle? Bürookaupa? piirkonna kaupa? allasutuse kaupa? funktsionaalsuste kaupa? täielik üleminek ("suure pauguga")?riskide hindamine ehk riskianalüüs

6.5.2.  Mis bürokraatilised tegevused on live eeldused: õigusaktid, lepingud, RIHA registreering jne.

6.5.3. Äriklienditeenuste puhul kuidas tootestada - hind, lepingud, turundus?

6.5.4. kommunikatsiooniplaani ja/või kava vajadus ja selle olemasolu?

6.5.5. teenuse kirjeldamine RIK teenuste portfellis ja SLA - kas muutub? (monitooring , kasutajatoe planeerimine) 

6.5.6. kliendi rahulolu uue teenusega

6.5.7. planeerida mõõtmised enne uue teenuse kasutuselevõttu ja mõistlikul ajal peale uue teenuse kasutuselevõttu (juhendmaterjal tulemas RIK teenuste rahulolu mõõtmise strateegia näol)

6.5.8. kas rakendamine on seotud seaduse muudatusega? millal muudatus jõustub? kas arendust ei või enne rakendada kui seadus/määrus on jõustunud?

6.5.9. kuidas toimitakse pooleliolevate asjadega? Pooleliolevad asjad - tasub mõelda, kas nt paberprotsessilt üleminekul digitaalsele tuleb uude süsteemi sisestada kõik pooleliolevad tööd ja andmed, sest see nõuab lõppkasutajatelt lisaressurssi ja tekitab pahameelt. Siinkohal võib küsida, mis juhtub, kui pooleliolevad ja/või juba lõpetatud toimikud/menetlused ei jõuagi uude süsteemi. Tasub mõelda ka sellele, kas pooleliolevate asjade kohta on vaja taaskasutada andmeid või saab need nt pildi kujul uude süsteemi lisada.


Kui tegemist on projektiga, milles on palju osapooli, tuleb panustada aega ka kommunikatsiooni, sest palju probleeme tekib sellest, et inimesed ei räägi omavahel.


Hea näide

1.01.2017 jõustub x seadustiku y paragrahv, millega muutub süsteemis funktsionaalsus z. z funktsionaalsust tuleb täiendada selliselt et  /seaduse muudatuse sisu selgitus/. Muudatus peab rakenduma koos seaduse muudatuse jõustumisega.


Halb näide

  • 3 kuud tagasi jõustus seaduse muudatus. Vaja on muudatus viia infosüsteemi kasutajateni.
  • X portaali valmimine lükkus edasi (ei olnud piisavalt aega planeeritud) ja ministri määrust tuli viimasel hetkel muutma hakata.


7.      Hea teenuse omaniku meelespea


  • Omaniku roll projektis ei lõpe LÜ esitamisega, vaid kestab kogu arenduse ettevalmistamise, arenduse ja rakendamise aja.
  • Omanik tunneb teenusega seotud tegevusi ja lõppkasutajate vajadusi
  • Oluline on leida lõppkasutajad, keda kaasata, st juba LÜ koostamisel tuleks arvestada lõppkasutajate soovidega/vajadustega
  • Enne LÜ kirjutamist tule ja räägi ärianalüütikuga oma ideed läbi.
  • Tellimuse tükeldamine väiksemateks osadeks tasub ennast ära.
  • Pärast tööde valmimist teenuse elu alles algab ja selle haldamine on oluline.