Upload
others
View
12
Download
0
Embed Size (px)
Citation preview
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?
http://www.ilves.net
http://www.eits.ee
http://www.ekk.edu.ee