Projektijuhtimine

1. Projektijuhtimine • Teema 7: • Tarkvaraprojektide üldküsimused • Peeter Normak

2. Loengu kava • Üldised nõuded tarkvarale tänapäeval • Tarkvaraprojektide spetsiifika • Tarkvaraprojektide edu kriitilised faktorid • Tarkvaraprojekti esialgne kavandamine • Tarkvara nõuete väljatöötamine • Tarkvaraprojekti mehitamine • Muudatuste ja riskide haldamine • Koostöö juhtkonnaga • Tarkvaraprotsessi alane kogemus

3. IKT kui kõiki valdkondi läbiv valdkond • Kaasaegse majanduse ja ühiskonna arengusuundumused: • Majandustegevuse sisu muutumine: • Teenuste osakaalu kasv tootmise suhtes (1970 – 1:1; 2010 – 3:1; IBM: 1995…2005 – 28%  55%), • Teenuste vahenduskeskkond – Internet, • Teenuste individualiseeritus (tarbija osalus endale teenuse kujundamisel). • Ettevõtete-organisatsioonide toimimismudelite muutumine: • Tekivad institutsioonide ökosüsteemid (koostoimivad võrgustikud/klastrid), N: Opel • Majandusruum globaliseerub, • Järjest enam protsesse standardiseeritakse ja automatiseeritakse. • Arengusuundumuste realiseerumisel on oluline roll IKT vahenditel: tootlikkuse kasvust ligikaudu 50% tuleneb IKT vahendite rakendamisest. • Määravaks on töötajate e-oskused (e-skills).

4. Tarkvaraprojekti spetsiifika - üldised nõuded • Tarkvaraprojekti spetsiifika tuleneb tulemile esitatavatest üldnõuetest, mille järgi peaks tarkvara: • üldjuhul toimima erinevatel platvormidel ja erineva riistvara korral; • olema muu tarkvaraga koostoimevõimeline; • toetama rakendusvaldkonna põhiprotsesse; • vastama laia (ja reeglina mittehomogeense!) kasutajaskonna vajadustele; • olema kergesti kohandatav spetsiifilistele vajadustele vastavaks (näiteks seadusandlusele, asutuse regulatsioonidele või kasutatavate tehnoloogiatele/metoodikatele).

5. Üldnõuetest tulenevad erinõuded • Üldnõuetest tulenevaid erinõudeid tarkvarale: • rangelt järgima standardeid; • olema visuaalselt (graafiline disain) ja loogiliselt (kasutatavus) optimeeritud, kooskõlaline kasutajate käitumismustritega; • olema kergesti laiendatav (sh kood kommenteeritud); • võimeline adekvaatselt reageerima tahtlikele (näiteks ründed) ja tahtmatutele (näiteks voolukatkestus) häiretele.

6. Tarkvaraprojekti spetsiifika - süsteemsus • Tarkvaraprojektide arendamisel muutusid teatud ühtsed alused ja sellest tulenev süsteemsus eriti kriitiliseks seoses lokaalsete ja globaalsete arvutivõrkude massilise kasutuselevõtuga 1980-ndatel ja 1990-ndatel aastatel. • Tegevussuunad: • Arendusprotsessi süstemaatiline analüüs ning arendusmetoodikate ja –vahendite loomine, aga samuti tarkvaratehnika meetodite arendamine. • IKT-alaste standardite ja spetsifikatsioonide loomine. • Erinevate raamistike (sh CC2001, SE2004, SWEBOK jmt) ja küpsusmudelite loomine. • IKT-pädevuste alaste sertifikaatide ja sertfitseerimisasutuste massiline loomine. • IKT-juhtimise professionaliseerumine.

7. Tarkvaraprojektide edu kriitilised faktorid • Näiteid (TLÜ/TPÜ poolt täidetud) tarkvaraprojektidest: Tähelinn, õpetajate analüüs, õpitarkvara, IVA, VIKO, DiPo, … . • Fundamentaalne: optimeerida (minimeerida) tarkvara ümbertegemise osakaal. • Selleks on oluline, et projekti tegevused oleksid kavandatud äärmiselt läbimõeldult (eriti projekti algfaasis, mil võetakse vastu kõige kaalukamad otsused). • NB! Natuke rohkem protsessijuhtimist projekti algfaasis hoiab projekti lõppfaasis kokku võrratult rohkem aega vigade paranduselt; probleemid tuleb lahendada koheselt peale nende tekkimist. Esimese 10% indikaator.

8. Tarkvaraprojekti kriitilised edufaktorid • Tarkvaraprojekti kriitilised edufaktorid tulenevad tarkvarale esitatavatest üld- ja erinõuetest (vt ka konspekti lisa 6). • Näiteid : • Kasutajate kaasamine kogu projekti jooksul. • Muudatuste efektiivne juhtimine. • Kvaliteedikindlustus ja probleemitundlikkus. NB! Vigade parandamist mitte edasi lükata! • Komponentide õigeaegne integreerimine. • Ajagraafiku vajadustele vastav korrigeerimine. • Sobiva arendusprotsessi mudeli määratlemine/kujundamine ja järgimine.

9. Projektikonkursil osaluse otsustamine (Smith, 2001) • Nõuete selgus ja konkreetsus. • Kooskõlalisus taotleja strateegiaga. • Varasemad koostöösuhted tellijaga. • Moodulite olemasolu, mis sobivad taotluses kasutamiseks. • Taotluse koostamiseks ja täitmiseks vajalike oskustega täitjate olemasolu. • Kõrgetasemelise/võitva taotluse koostamiseks vajaliku ajaressursi olemasolu. • Tellija maksevõime ja valmisolek adekvaatse hinna tasumiseks. • Konkurentide arvust ning nende kvaliteedist tulenev võidu tõenäosus. • Konkurentidest positiivse eristumise määr. • Võime pakkuda konkurentidest odavamaid lahendusi. • Võimalused tellijaga tema nõudeid, prioriteete, võimalusi, hindamise põhimõtteid ja taotleja võimalikke lahendusi arutada.

10. Kolm põhiküsimust (arendaja vaade) • Projekti planeerimise kulud on 5-10% projekti maksumusest. • Enne projektikonkursil osalemise otsustamist tuleb saada selgus järgmistes küsimustes: • Võidame projektikonkursi, kuna … (võimaldab rõhuda tugevustele), • Kui me kaotame, siis selle põhjuseks on … (võimaldab elimineerida võimalike kaotuste põhjuseid), • Taotlemise kolm põhilist riski on … (võimaldab vähendada riske).

11. Tarkvaraprotsessi faasid • Lihtsaim üldine arendusmudel: ADDIE (Analyse, Design, Development, Implementation, Evaluation). • Tarkvaraarenduse puhul: nõuded, disain, kodeerimine, testimine, juurutamine. • SWEBOK (SoftWare Egineering Body Of Knowledge): 10 põhifaasi + alafaasid. • Näiteks nõuete põhifaasi alafaasid: • nõuete määratlemise protsess, • nõuete määratlemine, • nõuete analüüs, • nõuete spetsifitseerimine, • nõuete fikseerimine, • nõuete haldamine

12. Tarkvaraprojekti esialgne kavandamine • Tarkvaraprojekti esialgse kavandamise tulem: tarkvaraarenduskava. See peaks sisaldama järgmist: • Projekti visiooni määratlemine, • Põhiotsustaja määratlemine, • Projekti eesmärkide määratlemine, • Riskihaldus, • Efektiivsete personalikasutuse strateegiate kujundamine, • Ajaarvestus.

13. Tarkvaraprojekti kestvuse määramatus • Projekti kestvuse hinnangu määramatuse kordajad: • Nõuete väljatöötamise järel 2,0 0,5 • Nõuete analüüsi järel 1,75 0,57 • Esialgse disaini järel 1,4 0,71 • Detailse disaini järel 1,25 0,80 • Kodeerimise järel 1,1 0,91 • Testimise järel 1.05 0,95

14. Ülesanne • Tuua näiteid ebaõnnestunud tarkvaraprojektidest ning ebaõnnestumise põhjustest.

15. Ülesanded - iseseisvalt • Loetle olulisemad töötajate väheste IKT-alaste oskustega seonduvad probleemid, mis pärsivad tootlikkuse kasvu (tutvu ka Euroopa Komisjoni dokumendiga 52007DC0496). • Veebiallikate põhjal määratle tarkvaraprojektijuhtide olulisemad isiksuslikud omadused. • Veebiallikate põhjal leia IKT-alaseid müüte. • Leida ADDIE eestikeelne akronüüm.

16. Personalivajadus ja personalijuhtimine • Personalivajadus sõltub kasutatavast arendusmudelist; üldjuhul nõuab nõuete analüüs rohkem aega ja kõrgemat kvalifikatsiooni, mistõttu mõned töömahu hindamise mudelid jätavad selle hoopis kõrvale. • Brooksi reegel: 1/3 kavandamisele, 1/6 kodeerimisele, 1/4 üksuse testimisele, 1/4 integreerimisele. • Probleem: teadmiste, oskuste ja kasutatavate praktikate mittevastavus. N: GP magistritöö. • Arendaja vahetus on väga kulukas  personali säilitamine ja professionaalne kasv on projektijuhi oluline kvaliteedinäitaja. • Projektimeeskonna koostamisel tuleks arvestada rollide esindatust ja tasakaalustatust; rollid võivad olla näiteks järgmised (võrdle XP-metoodika rollidega, p 7.6): esimees, vormistaja, ideede generaator, kriitik, töömesilane, meeskonna tugi, varustaja, lõpuleviija.

17. Soovitused personalivajaduse arvestamiseks • Kavandada tööjõud 75% ulatuses. • Pigem investeerida kogenud eksperti kui värvata “odav” algaja ja loota tema koolitamisse ja arengusse. N: ±3x • Projektimeeskonna kooskõla on olulisem kui individuaalsed teadmised/oskused; projektimeeskonna sagedaim etteheide projektijuhile. • Isiksuslikud omadused on olulisemad kui teadmised/oskused: esimesed on raskemini kujundatavad kui teised (R.Woolfe, 10:6). • Projektijuht peab olema vaba projektimeeskonna kujundamisel; selles ei tohi avaldada survet. • Projektimeeskonna kujundamisel peab jälgima, et muus kontekstis kujunenud rollid ei pärsiks projektis olulisi rollivahekordi. N: Victoria ülikooli üliõpilasprojektid.

18. Muudatuste haldamine/juhtimine • Projektiplaan vajab pidevat kohandamist/täpsustamist. • Muudatuste sisseviimine peab käima kindla protseduuri järgi; näiteks: • Muudatuste kavandajad peavad koostama vastava kirjaliku Muudatusettepaneku, kus on kavandatav muudatus ning selle läbi saavutatavad tulemused kirjeldatud, • Juhtrühm saadab Muudatusettepaneku arvamuse saamiseks muudatusest puudutatud osapooltele, • Esitatavates arvamustes hinnatakse nii muudatuste sisseviimise kulusid kui ka selle läbi saavutatavat kasu, • Arvamuste alusel võtab juhtrühm vastu asjakohase otsuse ja teavitab sellest asjakohaseid osapooli. NB! Muudatuste haldamisele/juhtimisele tuleb allutada ka kõik teised projekti täitmisel olulised dokumendid (riskid, stiilijuhis, väljastuse kontroll-loetelu jne).

19. Muudatuste haldamine • Arvestatavad faktorid, näiteks: • Kuidas mõjutab muudatus projekti ajakava, kvaliteeti ja ressursijaotust (näiteks kas suurendab eriti hõivatud inimeste töökoormust); • Kas muudatuse tegemist on otstarbekas edasi lükata; • Millised on muudatuse sisseviimisega kaasnevad riskid jne. • Hästi korraldatud muudatuste haldus vähendab ebaõnnestumise riske, kuna: • Otsused on läbi räägitud, rohkem aktsepteeritud ja paremini põhjendatud, • Projekti käik on paremini dokumenteeritud, • Osapooled on üksteise tööst paremini informeeritud, misläbi saavutatakse parem koostöö.

20. Riskihalduse aspekte • Riskihaldus on sisuliselt optimeerimisülesande lahendamine; üldjuhul on optimaalne 5-10%. • Soovitav on koostada põhiliste riskide tabel: • riski kirjeldus, • riski suuruse hinnang, • riski maandamise teed, • riski realiseerumisel võimalikud tagajärjed, • vastutajad, • …. • NB! Riskide tabel on vaja regulaarselt üle vaadara.

21. Koostöö juhtkonnaga – vajadus • Standish Group: Koostöö juhtkonnaga on IT-projektide õnnestumise olulisuselt 2. kohal olev tingimus, vähene koostöö ebaõnnestumise 4. kohal olev põhjus. • Koostööks on oluline juhtide informeerimine ja kaasatus (juhid peavad projekti pidama “omaks”, mitte “võõraks”). • Hea koostöö nimel peaks vältima järgmiseid olukordi: 1) Juhtide kahtlused projekti adekvaatse kavandamise (eelkõige selleks kuluva aja) suhtes. Selle vältimiseks peaks projekti olulised aspektid olema põhjalikult ja veenvalt põhjendatud ning juhtidega läbi räägitud. 2) Juhtide poolt vähesest informeeritusest tulenevalt projekti täitmist pärssivad tegevused (kokkulepped kolmandate osapooltega, oluliste ressursside kavandamine muude projektide peale jmt).

22. Näide juhtkonna meetmetest – “alkoholitest” • “Alkoholitest” projekti kavandamise ja täitmise kvaliteedi üle otsustamiseks: oluliste küsimuste (ootamatu) esitamine projektijuhile ja projektimeeskonna liikmetele. • Testi eesmärk: veenduda, et projekti täitjad on projektist, selle täitmisest ja enda rollist põhjalikult aru saanud. • Testi edukaks läbimiseks vajalik projektijuhi ennetav tegevus: endale võimalike küsimuste esitamine, neile vastuste leidmine (vajadusel koostöös projektimeeskonna teiste liikmetega) ning vastuste projektimeeskonnas läbiarutamine.

23. Nõuete väljatöötamine ja analüüs • Standish Group: Nõuete kvaliteet on IT-projektide õnnestumise olulisuselt 3. kohal olev tingimus, nõuete mittetäielikkus ebaõnnestumise 3. kohal olev põhjus. Fundamentaalne: kasutajate kaasamine. • Probleemid: • Liiga üldine/ebamäärane ülesandepüstitus. Võtted: seonduvate protsesside määratlemine ning nendest lähtuvalt nõuete konkretiseerimine, kasutuslugude koostamine. • Kaasatavate kasutajate määratlemine. Kõik olulisemad profiilid (personad) peavad olema esindatud. N: õppetööle registreerumine. • Kasutajatega ühtse keele leidmine. Võtted: koolitused, seminarid. • Kasutajate poolt oma vajaduste teadvustamine. Võtted: intervjuud, kasutuslugude ja persona-de koostamine. • Efektiivse kasutatavuse (usability) tagamine. Võtted: ühtne stiilijuhis (sh arusaadavad ikoonid), prototüübid, kasutusjuhend. • Nõuete muutumine projekti täitmise jooksul. Võtted: paindlike arendusmetoodikate kasutamine, muudatuste juhtimise tagamine.

24. Tarkvaraprotsessi alane kogemus • Tutvusta tarkvaratoodet tarbijaile võimalikult vara. Ükskõik kuidas ka ei püüa nõuete formuleerimise faasis tarbija vajadusi tundma õppida, efektiivseim viis selleks on anda talle toode ja lasta tal sellega tööd teha. • Kasuta sobivat protsessimudelit. Iga projekt peab valima protsessi, mis on sellele projektile sobivaim antud organisatsioonikultuuri, riskivalmiduse, nõuete selguse, rakendusvaldkonna jne korral. • Minimeeri intellektuaalset distantsi (arendusprotsessi osapoolte vahel). Tarkvara struktuur peab olema võimalikult lähedane reaalse maailma struktuuridele; see on tinginud objekt-orienteeritud tehnikate, komponent-tehnoloogiate ja visuaalse modelleerimise kasutuselevõtu. • Enne programmi kiiremaks tegemist tee see korrektseks. Palju lihtsam on teha töötav programm lihtsamaks kui teha kiire programm korrektseks, st ei tasu algse kodeerimise juures programmi optimiseerimise üle väga muretseda.

25. Tarkvaraprotsessi alane kogemus II • Hea juhtimine on olulisem kui hea tehnoloogia. Halba juhtimist ei kompenseeri hea tehnoloogia ja küllaldased ressursid, küll aga hea juhtimine kompenseerib halba tehnoloogiat ja väheseid ressursse. Vähe sellest, hea juht tõmbab häid inimesi, saavutab nende vajaliku pädevuse ja kujundab hea meeskonna. • Saa aru ja järgi tarbija prioriteete. Tarbija lepib sellega, et 90% funktsionaalsusest hilineb, kui ainult kõige olulisem 10% valmiks tähtajaliselt. • Disaini muutmisvalmina. Muutusi peab võimaldama nii arhitektuur, komponendid kui ka kasutatavad spetsifikat­sioonitehnikad. Seejuures muutmine ei tohi oluliselt kaasa tuua keerukuse kasvu. • Tarkvaraarenduse käigus loodav peab enamuses olema isedokumenteeruv. Disain ilma dokumenteerimata ei ole disain, neid peab looma paralleelselt (sageli kohatav ütlus “Disain on lõpetatud, tuleb see vaid veel dokumenteerida” viitab protsessi nõrkusele).

26. Ülesanded - iseseisvalt • Tuua näiteid tarkvarast, mida on ebamugav kasutada või mis on liiga piiratud või ülepaisutatud funktsionaalsusega. • Veebiallikatele (näiteks http://www.keirsey.com/) tuginedes analüüsi erinevaid isiksuslike tüüpide ja rollide klassifikatsioone. • Veebiallikate põhjal sõnasta IT projektimeeskonna koostamise alaseid soovitusi/seisukohti. • Leida internetiallikaid, milles käsitletakse IT-projekti skoobi liigsest laiendamisest (scope creep) tingitud ebaõnnestumisi. • Sõnast tehnoloogia omaksvõtu mudeli (Technology Acceptance Model) ja vajadustele vastavuse mudeli (Task-Technology Fit) põhijooned.

27. Järgmine loeng • Pühapäev, 16. dets kell 14:00 • Teemad: • Projektijuhtimise tarkvara (Martin Sillaots) • Tarkvaraprotsessi juhtimine • Eksamitööde probleemid

28. E-oskuste (e-skills) arendamine EL poliitika (“Technology for innovation/ICT industries and e-business”): http://ec.europa.eu/enterprise/ict/policy/ict-skills.htm NB! EK ettevõtluse ja tööstuse peadirektoraat! Thessaloniki resolutsioon (2006): Euroopa Liidu globaalse konkurentsivõime tagamiseks on ülitähtis (“crucial”) rakendada pikaajaline töötajate e-oskuste arendamise tegevuskava. Avalik ja erasektor peavad tegema ühiseid jõupingutusi, kujundamaks e-oskuste arendamisel välja põhikoolituse, kutse- ja kõrghariduse ning professionaalse tegevuse ühtne süsteem. Ettevõtted ja poliitikakujundajad peavad süstemaatiliselt propageerima professionaalsuse ja IKT rolli tööviljakuse, tööhõive ja tööperspektiivide suurendamisel. E

29. E-oskuste arendamise põhisuunad E-oskuste tegevuskava (Euroopa Komisjoni teatis 7.9.2007 “E-skills for the 21st century: fostering competitiveness, growth and jobs”) võtmekomponendid (läbiv põhimõte – heade praktikate levitamine): Avaliku ja erasektori koostöö ja ühisalgatused (“Multi-stakeholder partnership”): õppekavade kohandamine, välisspetside värbamine, … Investeerida (nii avaliku kui erasektori poolt) e-oskuste arendamisse, töötada välja e-oskuste raamistikud, mis seoks formaalse ja mitteformaalse hariduse ja sertifitseerimise ühtsesse süsteemi. Propageerida e-oskuste ja IKT elukutsete kaudu avanevaid karjäärivõimalusi (eelkõige õpilaste, vanemate ja õpetajate seas). Töötada välja ja realiseerida e-kaasatuse (e-Inclusion) programm (sh VKE jaoks). N: 30.11-2.12.2008 ministrite konverents Viinis. Elupideva õppe kontseptsioonist lähtuvalt töötada välja ettevõtete töötajatele suunatud e-kursuseid.