Projektijuhtimine

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

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

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).

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; • vastama laia (ja reeglina mittehomogeense!) kasutajaskonna vajadustele; • olema kergesti kohandatav spetsiifilistele vajadustele vastavaks (näiteks seadusandlusele, asutuse regulatsioonidele või kasutatavate tehnoloogiatele/metoodikatele).

Ü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); • toetama rakendusvaldkonna põhiprotsesse; • võimeline adekvaatselt reageerima tahtlikele (näiteks ründed) ja tahtmatutele (näiteks voolukatkestus) häiretele.

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 (näiteks SWEBOK) ja küpsusmudelite loomine (näiteks CMM-SW). • Õppekava-alaste soovituste väljatöötamine. • IKT-pädevuste alaste sertifikaatide ja sertfitseerimisasutuste massiline loomine. • IKT (projekti)juhtimise professionaliseerumine.

Tarkvaraprojektide edu kriitilised faktorid • Näiteid (TLÜ/TPÜ poolt täidetud) tarkvaraprojektidest: Tähelinn, õpetajate analüüs, “Juku” õpitarkvara, IVA, VIKO, DiPo, … . • Kõige kriitilisemad edufaktorid: tarkvaranõuded ja ressursid. N: Dippler. • 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). Esimese 10% indikaator. • NB! Natuke rohkem protsessijuhtimist projekti algfaasis hoiab projekti lõppfaasis kokku võrratult rohkem aega vigade paranduselt; probleemid tuleb lahendada koheselt peale nende tekkimist.

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.

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).

Diskussioon • Milliseid aspekte tuleks eelkõige arvestada pakkumiskutse otsustamisel?

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.

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): 15 teadmusvaldkonda (knowledge areas) + alavaldkonnad (topics). • Näiteks nõuete põhifaasi alafaasid: • nõuete määratlemine, • nõuete analüüs, • nõuete spetsifitseerimine, • nõuete hindamine (validation),

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.

Tarkvaraprojekti kestvuse määramatus • Projekti tegevuste konkretiseerimisel tuleks kohandada ka ajakava. • Projekti kestvuse hinnangu määramatuse kordajad: • c 1/c • 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

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 (inimkuude jaotus): 1/3 kavandamisele, 1/6 kodeerimisele, 1/4 üksuse testimisele, 1/4 integreerimisele. Brooksi seadus: “adding manpower to a late software project makes it later”. • Arendaja vahetus on väga kulukas  personali säilitamine ja professionaalne kasv on projektijuhi oluline kvaliteedinäitaja. • Probleem: teadmiste, oskuste ja kasutatavate praktikate mittevastavus. • Näide: GP magistritöö.

Projekti mehitamine – rollid • Erinevad arendusmudelid määratlevad mõnevõrra erinevad rollid. • Näide (Belbini rollimudel): • koordinaaror • vormistaja • ideede generaator • järelevaataja-hindaja • juurutaja • meeskonnatöö tugi • varustaja • spetsialist • lõpuleviija.

Soovitused personalivajaduse arvestamiseks • Kavandada tööjõud 75% ulatuses. • Pigem investeerida kogenud eksperti kui värvata “odav” algaja ja loota tema koolitamisse ja arengusse (tootlus 10x, kiirus 5x). • 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.

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.

Kvaliteedikindlustus • Toote kvaliteediprobleemid ulatuvad kaugele peale projekti lõppu  kvaliteet on olulisem kui projekti lõpptätajast kinnipidamine. • Mõned olulised aspektid: • Lõpptestimise peavad läbi viima arenduses mitteosalenud inimesed. • Kehtib Pareto reegel. Probleemsed moodulid tuleb lokaliseerida ja parandada võimalikult varakult. • Projekti tarnimisküpsuse otsustamine (näiteks vealeidmise ajalise jaotuse või valemi N*M/L kasutamisega). • Veaparanduse protseduurid peavad olema sätestatud.

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).

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öö.

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.

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 1) informeerimine ja 2) 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).

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.

Tarkvaraprojekti maksumuse hindamine • Üldvalem: Töömaht = KoodimahtProtsess × Meeskond × Vahendid × Kvaliteet • Koodimaht: funktsioonide või koodiridade arv (ühikuks 1000 koodirida). • Protsess: Inimtöö efektiivsus, mittevajaliku töö osakaal jmt. • Meeskond: töö vastavus oskustele, motivatsioon, meeskonnatöö, … • Vahendid: arendusvahendid ja –tehnikad • Kvaliteet: sobivate mõõdikute kasutamine, vastastikku toetamine, …

Tarkvara väljastamine • Tegevused: • Vigade jaotus on saavutanud vastuvõetava taseme. • Kõik kriitilised vead on leitud ja parandatud. • Kontrollnimekirja täitmine. • Projektijärgse veaparanduse/täienduste tegemise protseduuride kokkuleppimine. • Probleem: beeta-testimine.

Soovitused I – 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.

Soovitused II – 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 spetsifikatsioonitehnikad. 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).

Ülesanded - iseseisvalt • Tuua näiteid ebaõnnestunud tarkvaraprojektidest ning ebaõnnestumise põhjustest. • Leida näide projektist, mis ebaõnnestus skoobi ülemäärase paisutamise tõttu. • Veebiallikate põhjal määratle tarkvara projektijuhtide olulisemad isiksuslikud omadused ja võrdle neid PMCD raamistikus olevate isiksuslike kompetentside nimekirjaga. • Veebiallikate põhjal sõnasta IT projektimeeskonna koostamise alaseid soovitusi/seisukohti. • Leida tarkvaraprojekti mõni võimalik rollijaotus.

Kodutöö • Individuaalselt: • Loe läbi Project risk management peatükk raamatust “Head First PMP” (http://www.headfirstlabs.com/books/hfpmp/hfpmp_ch11.pdf) ja sõnasta kolm enda jaoks leitud suurimat tarkusetera. • Veebiallikate põhjal leia IKT-alaseid müüte. • Leida enda temperamenditüüp Kersey klassifikatsiooni (http://www.keirsey.com/4temps/overview_temperaments.asp) alusel: Guardian (supervisor, inspector, provider, protector), Artisan (promoter, crafter, performer, composer), Idealist (teacher, counselor, champion, healer), Rational (fieldmarshal, mastermind, inventor, architect).

Järgmine loeng • Pühapäev, 15. dets kell 14:00 • Teemad: • Tarkvaraprotsessi juhtimine • Projektijuhtimise toe aspektid • Eksamitööde senised probleemid

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

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.

Õppekava-alaste soovituste näiteid • Association for Computing Machinery (ACM) and IEEE-Computer Society: http://www.acm.org/education/curricula-recommendations • http://ai.stanford.edu/users/sahami/CS2013/final-draft/CS2013-Final-v0.9-prerelease.pdf • The European Centre for the Development of Vocational Training (CEDEFOP): www.cedefop.europa.eu/etv/Upload/Information_resources/Bookshop/50/2204_en.pdf • European Quality Assurance Network for Informatics Education (EQANIE): http://www.eqanie.eu/pages/quality-label/framework-standards-criteria.php

Projektijuhtimine