1 / 23

Projektijuhtimine

Projektijuhtimine. Teema 7 Tarkvaraprotsessi juhtimine Peeter Normak. Teemad. Arendusmetoodika valik. Näiteid arendusmetoodikatest: Koskmudel Kahefaasiline ja mitmeetapiline mudel Paindlikud metoodikad Tarkvaraprotsessi küpsusmdelid (CMM-SW ja CMMI). NASA protsesside parendusmudel.

avani
Download Presentation

Projektijuhtimine

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related