Tarkvara-arenduse praktika ja soovitused

tellija vaatenurgast tellija vaatenurgast

Aivar Ilves

TÜ MIT kursuse “Tarkvaraprojekt” loeng

Tartu 26.04.2007.a.

Kes ma olen?� Informaatika bakalaureus – Tartu Ülikool 2000,

informaatika magister – Tallinna Ülikool 200… � IT (töö)kogemused alates alates 1990 (1995)� Alates nov 2004 – Riikliku Eksami- ja

Kvalifikatsioonikeskuse IT juht� Alates okt 2004 – Eesti Infotehnoloogia Seltsi president� Alates okt 2004 – Eesti Infotehnoloogia Seltsi president� Mai 2001 kuni okt 2004 – Riigikogu Kantselei IT talituse

juhataja� Märts 1999 kuni jaanuar 2001 – Rahvusarhiivi

lõunaregiooni IT peaspetsialist� Seotud paljude huvitavate IT-projektidega: Arhiivi-

Infosüsteem, Valimiste Infosüsteem, Eesti Hariduse Infosüsteem, Sisseastumise Infosüsteem, Riigieksamite Infosüsteem

Millest räägime ?

� Ideest projektiks

� Planeerimine

� Hankimine� Hankimine

� Leping ja koostöö

� Testimine

Ideed

� Idee äripoolelt (juhtkond, üksuse juht jt) või IT poolelt (IT juht, IT spetsialist) – igal juhul rääkida mure-valupunkt ärajuhul rääkida mure-valupunkt ära

� Idee eeldab üldjuhul mõtlemist “raamidest väljas”

� Idee vajab üldjuhul veidi settimist – ehk tekib veel parem idee

Ideega kaasnevad muudatused

� Üldiselt võib jagada muudatused 3-sambaliseks:�Äriline ehk protsessipõhine – äriprotsessid�Õiguslik ehk juriidiline – õigusaktid, sisemised �Õiguslik ehk juriidiline – õigusaktid, sisemised

korrad-reeglid�Tehnoloogiline ehk IT-põhine – vajadus

eelnevaid toetava tarkvara või riistvara järele, samuti ka infosüsteemi (täiendamise) vajadus

� Tüüpviga: Tihti unustatakse mõni neist sammastest üldse ära!

Projekti maksumus� Mida rohkem alguses, seda raskem

maksumust hinnata – projekti kirjelduse olemasolul võimalik anda mõnel pakkujal indikatiivne pakkumusindikatiivne pakkumus

� Kompaktsuse ja hallatavuse huvides tihti mõistlik suurem idee-projekt jagada alamprojektideks ehk projektülesanneteks

Projekti finantseerimine� Finantsvahendid:

�Riigieelarve (riigiasutuse puhul)�KOV eelarve (KOV või KOV asutuse puhul)�EL vahendid (nii riigiasutusel, KOV-il kui ka �EL vahendid (nii riigiasutusel, KOV-il kui ka

erafirmal)�Firma eelarve (sh äriplaan)

� Tava- ja lihtjuhul:�Organisatsiooni IT eelarve�Vastava(te) kasusaaja(te) struktuuriüksus(t)e

eelarve(d)

Arendusprotsessi põhisammud� Tulevikuseisundi määratlemine arvestades IT

võimalusi� Tänase olukorra analüüs� Väliskeskkonna analüüs� Kriitiliste edufaktorite määramine� Kriitiliste edufaktorite määramine� Arendusvajaduste väljaselgitamine� Arendusvajaduste analüüs� Vajaduste prioriteetide määramine� Projektülesannete formuleerimine� Projektide käivitamine� Projektide realiseerimine

IT projektide kriitilised edufaktorid

� Vajaduste põhjalik eelanalüüs ja projektide õige valik

� Projektide tihe seostatus asutuse ärieesmärkidegaärieesmärkidega

� Läbimõeldud projektitöö metoodika ja professionaalne projektijuhtimine

Arengu- ja arendusdokumendid� Eesti infoühiskonna arengukava kuni 2013 (Vabariigi

Valitsuses heaks kiidetud 30.11.2006) -http://www.riso.ee/et/infopoliitika/arengukava

� Riigi IT arhitektuuri ja koosvõime raamistik (ver 2.0) -http://www.riso.ee/et/koosvoime/raamistikRiigi IT arhitektuur (ver 1.01) –� Riigi IT arhitektuur (ver 1.01) –http://www.riso.ee/et/koosvoime/arhitektuur

� Infoturbe koosvõime raamistik –http://www.riso.ee/wiki/Versioon_2007-01-31

� Semantilise koosvõime strateegia -http://www.riso.ee/et/koosvoime/semantika

� Euroopa infoühiskonna lähtekohad -http://www.riso.ee/et/foorum/EUstrateegia

Arengu- ja arendusdokumendid� Infosüsteemide turvameetmete süsteem (ISKE) (VV määrus nr

273 12.08.2004) -https://www.riigiteataja.ee/ert/act.jsp?id=791875

� Infosüsteemide arendamise kord -http://www.ria.ee/public/IS_projektide_arendamise_kord.dochttp://www.ria.ee/public/IS_projektide_arendamise_kord.doc

� Mittefunktsionaalsete nõuete kirjeldamise juhend -http://www.ria.ee/public/Mittefunk_nouded.doc

� Riigi IS komponendid -http://www.ria.ee/public/riigi_IS_komponendid.pdf

� Riigi IS keskse infrastruktuuri teenuste kontseptsioon -http://www.ria.ee/27300

Projektiplaan 1/11

� Arenduse soovija koostab projektiplaani, üldjuhul koos IT poolega

� Määrab omapoolse vastutaja - projektijuhi

� Keegi volitatud institutsioon (direktsioon/juhatus, mingi vastav nõukogu) otsustab projekti algatamise:�Kinnitades projektiplaani

�Määratledes realiseerimise aja

Projektiplaan 2/11

� Tänane olukord ja probleemid�Milline on tänane olukord ja millised on

tänased probleemid?tänased probleemid?

� Nt.� Info liikumine on aeglane.

�Liiga palju käsitsitööd ning eksimisvõimalusi.

Projektiplaan 3/11

� Eesmärk�Projekti eesmärk. Vastus küsimusele: Mida

saavutada vaja on?saavutada vaja on?

� Nt.• Tagada organisatsioonisisene

kommunikatsioon ja infovahetus

• Vähendada süsteemi haldusprotseduure

Projektiplaan 4/11� Nõuded

� Millega peab projekti käigus arvestama?� Millistele tingimustele peavad projekti eesmärgid või

tulemused vastama?� Nt� Nt

� Seadustest või muust regulatsioonist tulenevad nõuded

� Nõuded funktsionaalsusele� Nõuded tehnilisele platvormile� Nõuded liidestamisele ja andmete migratsioonile� Infoturbenõuded: etalonturbe metoodika järgi,

seatavad käideldavus ja erinõuded (isikuandmed jms)� Viited raamistikes kasutatavatele nõuetele

Projektiplaan 5/11� Tulemus

� Projekti kirjeldus, sihtgrupid, kasutamise ulatus� Mõõdetav lõpptulemus. Saavutuse kirjeldus. Kas

eesmärk on saavutatud?� Mis muutub praegusega võrreldes?� Mis muutub praegusega võrreldes?� Kes on projekti tulemuse omanik? (sisetellija

esindaja)

� Nt� Andmed saavad nähtavaks koheselt pärast nende

sisestamist.� Saab kontrollida suvalisel ajal protsessi olekut.� Info leidmine on kiirem.

Projektiplaan 6/11� Kasu

�Mõõdetav kasu rahalises või kvaliteedi mõttes. Vastus küsimusele: miks oleks mõistlik see projekt ette võtta?

Nt� Nt�Tööjõukulude vähenemine, läbipaistvuse

suurendamine, parem hallatavus ja kontroll, rahaline võit, eksimisvõimaluste vähendamine, maine kujundamine ja parandamine, usalduse suurenemine

Projektiplaan 7/11� Tegevus ja etapid

� Iga tegevuse ja etapi puhul tuleks märkida mõõdetav lõpptulemus ja teostaja ning vastutaja

� Ajagraafiku juures märkida kestvus, võimaluse korral ka oletatav algusaeg

� NB! Mitte unustada ajapuhvreid (etappide-vahelised ja lõpu-eelne)!

� Nt � Lisas või lisana tabel, mille veergudeks on: Tegevus,

Kirjeldus, Vastutaja, Teostajad, Eelnev tegevus, Kestvus, Algusaeg, Tähtaeg, Tulemus

Projektiplaan 8/11� Tegijad ja organisatsioon

� Projektijuhid (tellija ja täitja poolel)� Tellija projektijuht – vastutaja, tellija, otsuste tegija,

töörühma määraja, projektrühma eestvedaja

Juhtrühm – tippjuhtide kogu, kinnitab lähteülesande � Juhtrühm – tippjuhtide kogu, kinnitab lähteülesande ning võtab vastu vahepealsed ja lõplikud tulemused

� Projektrühm – valmistab ette lähteülesande ja on projekti käigus arenduse detaile arutav-kinnitav organ, annab perioodiliselt juhtrühmale ülevaate tehtud töödest ning informeerib muudatustest

� Tööde vastutajad ja tegijad, vajadusel töörühmad (sisuline, tehniline, kasutajatugi)

Projektiplaan 9/11

� Vajalikud vahendid ja ressursid�Projekti läbiviimiseks vajalikud vahendid ja

ressursidressursid

�Jooksvad kulud projekti lõppedes

�Projekti eeldused (eelnevad otsused, tegevused, seadusandlus)

� NB! Mitte unustada inimressurssi!

Projektiplaan 10/11

� Edufaktorid�Millised tegurid mõjutavad kõige enam

projekti õnnestumist ja millised on eeldused ?projekti õnnestumist ja millised on eeldused ?

� Nt�Hea ülesandepüstitus, tihe koostöö, projekti

järelevalve, kasutamise lihtsus, koolitus jne

Projektiplaan 11/11

� Riskid� Millised on projekti õnnestumist ohustavad riskid?� Kuidas saaks riske maandada?� Peatamise tingimused� Peatamise tingimused

� Nt� Nõrk kasutajadokumentatsioon, tarkvara madal

kvaliteet, kiirustamine turu survel, kasutajanõuete pidev muutumine, kasutajavaenulik disain, keerukas kasutus jne

� Peatamise tingimused: tähtaegade põhjendamatu ületamine, arenduspartneri kompetentsipuudus

Tarkvara hange

� Hankimisel põhieesmärk saada võimalikult soodne pakkumus võrreldavate pakkumuste seastVähegi suurema projekti puhul eraldada � Vähegi suurema projekti puhul eraldada analüüsi ja realiseerimise hange

� Sellega tagatakse:�Pakkumuste üheselt-mõistetavus�Pakkumuste võrreldavus

Hankimine - põhimõtted

� Eduka (riigi)hanke alustala on üheselt mõistetav, konkreetne ja pädev pakkumise kutse dokument ehk hankedokument

� Hankedokument koosneb omakorda � Hankedokument koosneb omakorda kolmest alustalast:�Nõuded pakkujale ehk

kvalifitseerimistingimused�Nõuded pakkumusele ehk tehniline kirjeldus�Hindamiskriteeriumid

Hankimine – nõuded pakkujale

� Nt�Valdkonnas tegutsemine x aastat (x=3..5)�Kirvereegel: viimase 3 aasta netokäibe piirang

3x[3-5]x[eeldatav hanke maht]3x[3-5]x[eeldatav hanke maht]�Sama mahuga hankeid 3-… tk perioodi (nt

aasta) kohta�Õigus tegeleda tootja toodetega, kogemused

toodetega - tootja sertifikaatide koopiad või tootja (esinduse) kinnitused

Hankimine – nõuded pakkumusele� Lisaks funktsionaalsetele nõuetele ka nõuded

olla vastavuses standarditega, raamistikega vms� Nõue infosüsteemi turvaklassile� Tehniline kirjeldus ühele tootele või pakkujale

suunata ohtlik!suunata ohtlik!� Normaalne võimalik pakkumiste arv 3-5� Tarkvara arenduse hankes tehniline kirjeldus on

(eel)analüüsi dokument� Ideaaljuhul täiendavalt ka tarkvaraprojekti

dokumentatsioon koos arhitektuurilise spetsifikatsiooniga

Hankimine - hindamine� Hinnata saab ainult mõõdetavaid asju!� Hinnakriteerium 100% mõistlik ainult

tarkvaralitsentside hankel� Tarkvara arenduse (ka nt riistvara soetuse-Tarkvara arenduse (ka nt riistvara soetuse-

rendi) hankel hinnakriteerium ~50%� Ülejäänud ~50% tehniline täiuslikkus, sobivus

ostja/hankija keskkonnaga, garantii- ja hooldustingimused

� Riigihankel tohib hinnata pakkujat ainult pakkumisega seotud raamides! (al 01.05.2007 kehtivas riigihangete seaduses)

Leping ja koostöö� Lepingus peab olema sätestatud minimaalselt:

� Mõisted ja tõlgendamine� Lepingu ese ehk sisu� Lepingu kehtivusaeg� Tööde ja teenuste maht, tasumine� Tööde ja teenuste maht, tasumine� Poolte (Täitja ja Tellija) õigused ja kohustused� Töö tulemuse omandi-, kasutus- ja autoriõigus� Garantii, lisatööde teostamine ja hooldus� Konfidentsiaalsus� Rakendussätted� Kontaktisikud (lisana)� Tehniline kirjeldus (lisana)� Vormid (üa-vv akt, pretensioon jms; lisana)

Leping ja koostöö� Üleandmine-vastuvõtmine ja tasumine etapiti,

viimane osa peale lõplikku kompleks-testimist� Töö käigus tekkinud muudatused alati

dokumenteeritakse koos põhjustega!dokumenteeritakse koos põhjustega!� Toote üleandmise-vastuvõtutingimused peavad

olema selged ja konkreetsed� Analüüsidokumendi muutmise rutiin reguleeritud� Kohustused peavad olema sanktsioneeritud, kuid

need peavad olema mõistlikud ja tasakaalus

Leping ja koostöö

� Õigus kaasata vajadusel-võimalusel kolmas osapool – projekti järelevalve, kes ohjab ja kaitseb nii täitjat kui tellijat, ohjab ja kaitseb nii täitjat kui tellijat, halvemal juhul leida üksik väline ekspert

� Kaasata kindlasti eelnimetatu ka üleandmise-vastuvõtuprotsessi juurde

Testimine - üldpõhimõtted� Planeerimatu testimine ei ole testimine !

� Testiplaan sisaldab testimise korraldust, tööjaotust, ajakava, testide tüüpe, vastuvõtukriteeriume, vigade menetlemise vastuvõtukriteeriume, vigade menetlemise korda, testjuhtumite kirjeldust.

� Testide tüübid: funktsionaalne testimine, koormustestimine, turvalisuse testimine

� Funktsionaalsed testjuhtumid baseeruvad analüüsi dokumendil. Testjuhtumil on alati sisend ja väljund.

Testimine - metoodika� Korraldada vigade raporteerimine (nt Mantis, Bugzilla vms)� Sõlmida kokkulepped, kuidas vigadele hinnanguid antakse (nt

kriitiline – 100 p, vähemkriitiline – 40 p ja pisiviga 10 p)� Regulaarselt käia osapooltega raporteeritud vead üle ja panna

neile hindedneile hinded� Sõlmida kokkulepe, millal testimine lõpetatakse ja süsteem üle

antakse (nt pole ühtegi 100 p viga ja vigade kogusumma pole suurem kui x p)

� Süsteemi testimise ajal ei muudeta� Testitakse ainult testiplaani (kasutuslugude) põhjal, mitte testija

arvamuse põhjal� Tekkinud ideed ja arvamused lähevad arendusettepanekutesse

Üleandmine ja vastuvõtmine� Infosüsteem ehk tarkvara

�Sätestada piir, millal tarkvara on nn “valmis” –vigadevaba tarkvara ei ole olemas

� Dokumentatsioon� Dokumentatsioon�Dokumentide loetelu�Dokumentide piisavus

� Nõutav dokumentatsioon selgelt sõnastatud ja suvalisele kolmanda isikuna esinevale tarkvaraspetsialistile selgelt ja üheselt arusaadav

Üa-vv – dokumentide loetelu� Installeerimise juhendid: andmebaasiserver(id),

rakendus-serverid, rakendus

� Tehniline dokumentatsioon: andmemudel, alamsüsteemide klassmudeli kirjeldused (iga alamsüsteemi kohta), liideste (nt X-tee adapterserver) alamsüsteemi kohta), liideste (nt X-tee adapterserver) kirjeldus, süsteemiadministraatori haldusjuhendid

� Kasutusjuhendid (koostöös tellijaga): kasutaja töökohtade (rollide) lõikes, toimingud loogilises järjekorras

� Projekti käigus tekkinud dokumendid (võrrelda loetelusid)

Juurutamine ja hooldus� Juurutamine - kõige vaevarikkam protsess

� Eeldab harjumuste muutmist� Esineb vigu, puudusi, ebaloogilisust, ebastabiilsust� Ettepanekutele süsteemi parendamiseks koheselt ei

reageerita� Eeldus: “Süsteem peab kõik mured lahendama”� => motivatsioon madal

� Tähtis ülesanne: kasutajate motivatsioon kõrgel hoida

� Hooldusleping - täitjast sõltumatute puuduste viimistlemine, paranduste tegemine, peakasutajate kasutajatugi – eesmärgiks saavutada stabiilne ja talutav olukord

Majutus� Defineerida ära vajadused:

� Kasutajate arv kokku� Sama-aegsete kasutajate arv - min ja max� Päringute arv päevas, sekundis – min ja max� Andmemaht, kasv aastas� Andmemaht, kasv aastas� Tööaeg, tööväline aeg, muu aeg � Kasutusintensiivsuse periood aastas: normaalne,

kõrge, ülikõrge� IS põhimõtteline skeem koos vajalike serverite ja

teenus-seadmete vajadusega (koos tehnilise spetsifikatsiooniga)

� Kasutusviisid (nt üle http, https jms)� Vajalikud täiendavad keskkonnad (test-keskkond,

koolitus-keskkond, arendus-keskkond jms)

Majutus� Nõuded haldusele, klienditoele ja monitooringule – sh monitooringu

kasutajaliides tellijale

� Kvaliteedinõuded:

� IS turvaklass (nt S2K2R1T2)

� Käideldavusprotsent (nt 99% - 3,65 päeva/aastas rikkeaega)� Käideldavusprotsent (nt 99% - 3,65 päeva/aastas rikkeaega)

� Maksimaalsed teenuse seisaku ajad, nt:Periood Min

servereid Aeg Perioodil

lubatud seisak

Ühe seisaku max pikkus

Seisakuid perioodil

kokku

Seisakuid perioodil

kokku kuus Normaalne (15.10. – 19.01., 01.05.- 19.06.)

1 DBS, 2 APS, 1 XTS

T V M

4 h 8 h 8 h

2 h 4 h 8 h

8x 8x 8x

20x, 16 h (T+V+M)

Kõrge (1.01-20.01., 20.08. – 14.10.)

1 DBS, 4 APS, 2 XTS

T V M

2 h 4 h 8 h

30 min 1 h 4 h

4x 4x 4x

16x, 12 h (T+V+M)

Ülikõrge (20.06. – 19.08.)

1 DBS, 4 APS, 2 XTS

T V M

1 h 2 h 8 h

30 min 30 min

2 h

2x 4x 4x

12x, 6 h (T+V+M)

Kokkuvõtteks� Eelnevalt riskid läbi mõelda

� Panna kõik kirja, mida keegi teab

� Levitada infot asjassepuutuvate isikute vahel

� Küsida ja välja selgitada, kui ei tea või pole � Küsida ja välja selgitada, kui ei tea või pole kindel

� Olla alati konkreetne ja aus

� Otsustega mitte venitada

� Käituda mõistlikult ja heas usus

� Austada koostööpartnerit (win-win)

Suur aitäh kuulamast!

Küsimusi?

Aivar@Ilves.net

http://www.ilves.net

http://www.eits.ee

http://www.ekk.edu.ee