Projektijuhtimine

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

2. Teemad • Arendusmetoodika valik. • Näiteid arendusmetoodikatest: • Koskmudel • Kahefaasiline ja mitmeetapiline mudel • Paindlikud metoodikad • Tarkvaraprotsessi küpsusmdelid (CMM-SW ja CMMI). • NASA protsesside parendusmudel. • Tarkvara arendusprotsessi hindamismetoodika SPICE. • Kvaliteedijuhtimine. • Tarkvaraarenduse maksumuse hindamine.

3. Arendusmetoodika valik • 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. Soovitatav on kasutada kolmeastmelist jaotust: kohustuslik, soovitatav, lubatav.

4. Koskmudel (kaskaadmudel – the waterfall model) ja kahefaasiline mudel • Nõuded Disain Kodeerimine Testimine Juurutamine • 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.

5. Koskmudel - 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. • Koodilugemisega on võimalik leida ja parandada vaid 60% vigadest. • 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).

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

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

8. Paindlikud arendusmetoodikad • Kent Beck (1996). • Märksõnad: Kommunikatsioon, Lihtsus, Tagasiside ja Tarmukus. • 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. • Muud terminid: väle, agiilne metoodika; algselt – ekstreemne (extreme programming, XP). • Levinuim - SCRUM

9. Paindlike arendusmetoodikate põhijooned • Lähtub soovilugudest (stories, realiseerimine keskmiselt 2 nädalat). • Arendajate rollide ja ülesannete vahetumine projekti täitmisel. • Igahommikused (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!

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

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

12. CMM-SW – 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?

13. Capability Maturity Model Integration – CMMI • Kriteeriumiks ettevõtte arengueesmärkide toetamine. • Protsessipiirkonnad: • protsessijuhtimine, • projektijuhtimine, • arendamine, • 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) • informative (materjalid, mis võimaldavad eesmärkide ja praktikate paremat mõistmist) – ning üksikute protsesside hindamiseks võimekustasemed 0-5.

14. CMMI protsesside võimekustasemed • Tase 0 (mittetäielik, incomplete): protsess, mida kas ei viida läbi viiakse läbi vaid osaliselt. Ü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.

15. NASA Software Process Improvement (SPI)‏ • NASA tarkvara parendamise metoodika on iteratiivne ja suhteline (momendi tasemest lähtuv). • 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.

16. NASA SPI versus CMM-SW • 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.

17. Tarkvaraprotsessi hindamise metoodika SPICE • Tarkvaraprotsessi hindamise metoodika (Software Process Improvement and Capability dEtermination): erinevate aspektide hindamine 0...5 skaalal. • Võimaldab eneseanalüüsi läbiviimist. • On rakendatav eritüübiliste ja erineva suurusega organisatsioonide puhul. • Aluseks standardile ISO/IEC 15504 “Information technology – Software process assessment”.

18. SPICE struktuur • Sissejuhatus ja põhimõisted. • 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. • Juhis rakendamiseks protsessi parandamisel. • Juhis rakendamiseks protsesside võimekuse määramisel. • Sõnastik, mis sisaldab kõiki SPICE dokumentides kasutatud spetsiifilisi mõisteid.

19. Kvaliteedikindlustus • 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.

20. Tarkvara väljastamine • 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.

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

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

23. Järgmine õppus: • Pühapäev 11.detsember kell 14.00 • Ruum P412 – Haridustehnoloogia jt • Ruum T416 – IT-juhtimine jt