Projektijuhtimine

1. Projektijuhtimine • Teema 8 • Tarkvaraprotsessi juhtimine • Peeter Normak

2. Arendusmetoodika valik • Arendusmetoodika lähtub suuresti projekti raames loodava toote loomise/arendamise mudelist. Arendusmetoodika on omakorda aluseks arendusvahendite valikul. • Kursuses käsitletavad: koskmudel, mitmeetapiline (iteratiivne), XP. • Arendusmetoodika valiku üldised põhimõtted: • Olulisem sellest, milline metoodika valida, on see, et valitud metoodikat hästi vallatakse. Kriitiliste ning kõrge riskiastmega projektide puhul peaks uue metoodika kasutuselevõttu põhjalikult kaaluma (st üldjuhul peaks seda vältima). • Uue metoodika juurutamisel tuleks õppida teiste kogemustest (näiteks kaasates/palgates seda valdavaid spetsialiste). • Mistahes metoodika valikul peab seda kohandama asutuse organisatsioonikultuuriga ning projektirühma harjumuste ja oskustega; valitud (kohandatud) metoodika peab saama aktsepteeritud kogu projektirühma poolt. • Kasutatavat metoodikat peab arvestama ka arendus- ja muude vahendite valikul. Ka siin on soovitatav kasutada kolmeastmelist jaotust: kohustuslik, soovitatav, lubatav.

3. Koskmudel (kaskaadmudel – waterfall model) ja kahefaasiline mudel • Nõuded Disain Kodeerimine Testimine Juurutamine • Koskmudeli majandusnäitajad: • Tarkvara väljastamise järgne vea parandus maksab ligikaudu 100 korda rohkem kui see viga oleks parandatud varases disaini faasis. • Vaid ligikaudu 15% tarkvaarenduse töökulust läheb programmeerimisele. • Arendusprotsessis on üldkehtiv Pareto reegel (80% tegevusest kulub 20% nõuetele; 80% kulutustest 20%-le komponentidele; 80% vigu on 20% komponentides; 80% tulemusest saavutatakse 20% inimeste poolt jne). • Kahefaasilise mudeli eelised: • Annab firmale võimaluse projekti katkestamiseks kui tehtud on alles suhteliselt väikesed kulutused. • Võimaldab summaarselt kavandada projekti palju adekvaatsemalt kui ühefaasilise mudeli korral. • Sunnib projektijuhti pöörama suurt tähelepanu projekti kavandamisele.

4. Ülesanded • Iseseisvalt: selgita välja ajakirja “Software Process Improvement and Practice” eesmärgid. • Iseseisvalt: sõnasta artiklis “Developing and Implementing an IT Project Management Process” esitatud metoodika põhimõtted. • Iseseisvalt: selgita, milles seisneb Pareto printsiip projektijuhtimises. • Iseseisvalt: milles seisneb Microsoft Solutions Framework protsessimudeli põhierinevus koskmudelist? • Iseseisvalt: sõnasta Boehm’i spiraalmudeli põhiprintsiibid.

5. Mitmeetapiline (iteratiivne) mudel • Mudeli üldkuju: • Arenduse 1. Faas (nõuded ja arhitektuur)‏ • Etapp 1: disain, kodeerimine, testimine ja väljastamine • Etapp 2: disain, kodeerimine, testimine ja väljastamine • … • Etapp n: disain, kodeerimine, testimine ja väljastamine • Tarkvara lõplik väljastamine • Eelised: • Tarkvara varane kasutuselevõtt. • Riskid on vähendatud. • Probleemid ilmnevad varakult. • Väheneb vahearuannete kirjutamise aeg (töötav tarkvara on parem kui mistahes muud tüüpi aruanne). • Suureneb valikute arv funktsionaalsuse osas. • Suureneb planeerimise adekvaatsus (etapijärgne tagasiside!)‏ • Tarkvaraprotsessi parem paindlikkus, efektiivsus ja süsteemsus (muudatusi arutatakse iga etapi järel). • Vigade töötlus on efektiivsem (vigade lokaliseerimine kergem). • Töö jaguneb ühtlasemalt (Näiteks saavad testijad tööle asuda juba esimese mooduli valmimisel).

6. XP arendusmetoodika ja Chrystal-metoodikad • XP – extreme programming (ka väle, agiil- ja paindmetoodika). • Märksõnad: Kommunikatsioon, Lihtsus, Tagasiside ja Tarmukus. • Põhijooned: • Lähtub soovilugudest (stories, realiseerimine keskmiselt 2 nädalat). • Arendajate rollide ja ülesannete vahetumine projekti täitmisel. • Iga-hommikused (püstijala-)koosolekud. • Aluseks minimaalsuse põhimõte (lisa uus funktsionaalsus vaid selge vajaduse korral). • Tihe ja pidev koostöö tarbijaga. • Kokkulepitud reeglid, spetsifikatsioonid, standardid. • Paarisprogrammeerimine. • Ei ületunnitööle! • Rollid: programmeerija, klient/kasutaja, testija, jäljekütt, treener, konsultant, suur juht. • Spetsiifika: distsipliin, kõrge mitmekülgne kvalifikatsioon, väikesed arendusmeeskonnad, nõuete muutmine võimalik ka projekti hilises faasis, inimtööjõu võimalikult efektiivne kasutamine.

7. Tarkvaraprotsessi küpsusmudel CMM-SW • Projekti kavandamisel ja täitmisel on oluline arvestada projektimeeskonna võimekusega. • 5 taset: kaootiline, stabiilne, edenev, mõõdetav, optimeeritud (jaotus väga ebaühtlane!). • Igal tasemel oma võtmeprotsessid, nõuded ja kontrollküsimused. Näiteks 2. taseme küsimused: • Kas projekti kavandamiseks ja jälgimiseks on olemas dokumenteeritud (mahu, maksumuse, ajakulu jne) hinnangud? • Kas on fikseeritud kavandatavad tegevused ja täitjate ülesanded? • Kas kõik rühmad ja üksiktäitjad aktsepteerivad neile pandud kohustusi? • Kas projekt järgib organisatsiooni kirjalikku tarkvara arendamise poliitikat? • Kas projekti kavandamiseks on eraldatud adekvaatsed ressursid? • Kas kasutatakse meetmeid, mis võimaldavad määratleda projekti kavandamise seisu (näit. vahekokkuvõtted)? • Kas projekti juht annab regulaarseid ülevaateid projekti kavandamise tegevustest? • 2003.a Eesti analüüs (laekus 69 ankeeti): mitte ükski ettevõte ei vastanud taseme 2 nõuetele. • Ettepnek (G.Piho): vaadelda taseme 2 järgmiseid alatasemeid: • CMM2-nõuded (heatasemeline nõuete haldamine)‏ • CMM2- plaanid (CMM2-nõuded+tegevused on planeeritud ja ressurssidega adekvaatselt kaetud)‏ • CMM2-tulemused (CMM2-plaanid+toimib tegevuste/tulemuste monitooring ning mingil määral ka kvaliteedisüsteem).

8. Capability Maturity Model Integration – CMMI • Kriteeriumiks ettevõtte arengueesmärkide toetamine. • Protsessipiirkonnad: 1) protsessijuhtimine, 2) projektijuhtimine, 3) arendamine, 4) tugi. • Suur tähelepanu juhtide tööülesannetele. • Tugineb nn protsessimudelitele, millede valik sõltub konkreetsetest tingimustest. • Lisaks viiele küpsustasemele on kolm komponentide rühma – required (organisatsiooni üld- ja üksikud eesmärgid), expected (eesmärkide saavutamiseks juurutatavad praktikad) ja informative (materjalid, mis võimaldavad eesmärkide ja praktikate paremat mõistmist) – ning üksikute protsesside hindamiseks võimekustasemed 0-5: • Tase 0 (mittetäielik, incomplete): protsess, mida kas ei viida läbi viiakse läbi vaid osaliselt. Protsessipiirkonna üks või mitu spetsiifilist eesmärki ei ole täidetud. • Tase 1 (sooritatud, performed): protsess, mille toel saavutatakse kõik protsessipiirkonna spetsiifilised eesmärgid. • Tase 2 (hallatud, managed): sooritatud protsessid, mis on kavandatud ja läbi viidud kooskõlas esialgselt kavandatud plaanile. On loodud ja toimivad protsesside kavandamise ja läbiviimise (ning nende dokumenteerimise) põhimõtted. • Tase 3 (defineeritud, defined): hallatud protsessid, mis on kavandatud ja läbi viidud organisatsiooni standardprotsessidele tuginevalt: protsessid on kirjeldatud ja saadud kogemust kasutatakse edaspidise töö kavandamisel ja täitmisel. • Tase 4 (kvantitatiivselt hallatud, quantitatively managed): defineeritud protsessid, mida on võimalik kirjeldada kvantitatiivsete (mõõdetavate) tunnuste abil. Põhierinevus tasemel 3 olevatest protsessidest seisneb selles, et kvantitatiivselt hallatud protsesside tulemit on võimalik sisendparameetrite alusel ette ennustada. • Tase 5 (optimeeritud, optimising): kvantitatiivselt hallatud protsessid, mida täiustatakse vastavalt konkreetselt antud momendi tingimustele ja ärieesmärkidele. Täiustuste läbi saavutatava efekti suurust mõõdetakse.

9. NASA Software Process Improvement (SPI)‏ • NASA tarkvara parendamise metoodika on iteratiivne. • Arusaamine (understanding): eesmärkide ja nende saavutamiseks võimalike protsesside, mudelite, seoste ja indikaatorite määratlemine (st eesmärgiks on vajalikest protsessidest aru saada). • Hindamine (assessing): eesmärkide täpsustamine, erinevate meetodite ja vahendite rakendamisest tuleneva mõju hindamine (st eesmärgiks on suurima mõjuga meetodite ja vahendite väljaselgitamine). • Pakendamine (packaging): ennast õigustanud meetodite ja vahendite üldkasutatavaks muutmine. • NASA SPI ja CMM-SW olulisemad erinevused: • 1) kontseptsiooni osas: NASA – alt-üles, CMM – ülalt alla; • 2) eesmärkide osas: NASA – konkreetsest vajadusest lähtuv, CMM – üldine protsessi kvaliteet; • 3) hindamise alus: NASA – suhteline (momendi tase), CMM – absoluutne; • 4) skaala: NASA – pidev, CMM - 5-astmeline. • NASA SPI mitmed põhimõtted on realiseeritud CMMI-s.

10. Protsessi hindamise metoodika SPICE • Tarkvaraprotsessi hindamise metoodika (Software Process Improvement and Capability dEtermination): erinevate aspektide hindamine 0...5 skaalal. • Struktuur: • Sissejuhatus ja põhimõisted. Annab ülevaate sellest, millised on dokumentatsiooni üksikute osade omavahelised seosed, aga samuti juhised dokumentatsiooni üksikute osade valikuks ja kasutamiseks. • Protsessihalduse mudel. Määratleb tarkvaraarenduse põhitegevused, järjestatuna protsessi keerukuse kasvamise järgi. • Protsesside hindamine. Lisaks hindamise raamistiku (st mida hinnata) määratlemisele annab ka hindamise alused (st kuidas määrata taset). • Hindamise läbiviimise juhis. • Hindamise instrumentide ja vahendite loomine ja valik. • Hindajate kvalifikatsioon ja koolitus. Kirjeldab ka võtteid, kuidas kompetentsusastet määrata. • Juhis rakendamiseks protsessi parandamisel. Kirjeldab ka indikaatorite määratlemist ning seda, kuidas kasutada hindamise tulemusi protsessi parandamiseks; toob hulgaliselt näiteid. • Juhis rakendamiseks protsesside võimekuse määramisel. Kirjeldab ka indikaatorite määratlemist ning kuidas kasutada hindamise tulemusi protsessi võimekuse määratlemiseks. • Sõnastik, mis sisaldab kõiki SPICE dokumentides kasutatud spetsiifilisi mõisteid. Aluseks standardile ISO/IEC 15504 “Information technology – Software process assessment”.

11. Kvaliteedikindlustus ja tarkvara väljastamine • Kvaliteedi mõju ulatub kaugele väljapoole projekti lõppu: kvaliteet on määratult olulisem kui näiteks projekti aja ülekulu. • Olulised aspektid: 1) Kvaliteedikindlustus peab olema kavandatud, eelkõige peaks sätestatud olema testimise korraldus. 2) Integreeritud süsteemi ja tehniline testimine peaks toimuma mitte arendajate poolt. 3) Üldjuhul kehtib Pareto reegel, mistõttu peaks vigased/probleemsed moodulid lokaliseerima võimalikult varakult. 4) Määratleda, millal lõpetada testimine (näiteks vigade leidmise intervalli järgi või valemi N*M/L alusel). 5) Sätestatud peavad olema avastatud vigadest tulenevad muudatuste sisseviimise reeglid. • Probleem: beta-testimise otstarbekus. • Tarkvara vigade suhtes väljastamisküpsus: 1) Loendamine, testirühm, vigade testgenereerimine. 2) Fataalsed vead peavad kõik olema leitud ja parandatud. 3) Väljastamise kontroll-lehe läbimine. 4) Vajadusel edaspidi (st peale projekti lõppu) leitavate vigade parandamise kord (kirjalikult, allkirjastatult). • Projekti ajaloodokumendi koostamine ja läbiarutamine.

12. Tarkvaraprojekti maksumus • Mudeli üldkuju: • Töökulu = MahtProtsess×PersonalKeskkondKvaliteet • Mahu mõõtühik enamasti kas 1000 koodirida või realiseeritav funktsioon. • Mahu vähendamine: korduvkasutus, koodi autom. genereerimine, kõrgtaseme keelte kasut. • Protsessis olulisim optimeerida tööjõu kasutamist, minimeerida mittevajalikku tegevust. Peab eristama meta-, makro- ja mikrotasandit. • Personal: tasakaalustatud meeskond on olulisem kui individualistidest tipptegijad. • Kasuta vähem ja paremaid inimesi, • Kohanda ülesanded inimeste võimete ja motivatsiooni järgi (arvestada Peteri printsiibiga edutamisel), • Inimesi peab aitama saavutada eneseteostust, • Vali üksteist täiendavad ja omavahel harmoneeruvad inimesed. • Keskkond: arendusvahendid, nõuete-, konfiguratsiooni jt haldamise vahendid, tehnikad • Kvaliteet: • Sobivate mõõdikute/meetrikate kasutamine • Töökultuuri kujundamine (sh noorte juhendamine ja abistamine).

13. Ülesanded • Loetle kahefaasilise tarkvaraarenduse mudeli võimalikud puudused. • Loetle mitmeetapilise tarkvaraarenduse mudeli võimalikud puudused. • Milliseid arendusmetoodikaid olete kasutanud? • Iseseisvalt: sõnastada individuaalse tarkvaraprotsessi PSP põhiseisukohad. • Iseseisvalt: loe läbi loengukonspektis viidatud Mark C. Paulk koostatud CMM ja XP ning ISO9001 vahekorda käsitlevad artiklid.