Ohjelmistotekniikka - Luento 12 Jouni Lappalainen Luku 24: Projektin hallinnan käsitteet - ihmiset, tuote, prosessi ja projekti - W 5 HH periaate Luku 25: Prosessi- ja projektimetriikat - ohjelmiston mittaminen (LOC, FP, luokka) - laatumetriikat, DRE - viisi metriikkaa / Putnam & Myers Luku 26: Projektin koon arviointi (estimointi) - ositustekniikat (LOC, FP, prosessi ja käyttötapausperustaiset) - empiiriset estimointimallit (COCOMO) - olioprojektien koon arviointi Luku 27: Projektin aikataulun kiinnittäminen - työnositus (WBS) - aikataulutustekniikat ja ansaitun arvon arvio
Soveltuvat lait ja pohdiskelun aiheita 1. Kehittyvä järjestelmä monimutkaistuu, kunnes erityisillä toimenpiteillä vähennetään monimutkaisuutta / no 28, Lehman 1980 2. Ohjelmoijien suorituskyky vaihtelee huomattavasti /no 31, Sackman 1968 3. Ryhmän käytös on riippuvainen siihen kohdistetusta huomiosta /hyp_no 19, Hawthorne 1932 (Parsons 1974)
Soveltuvat lait ja pohdiskelun aiheita Toimit projektipäällikkönä ohjelmistoyrityksessä. Tehtävänäsi on hallita laajassa käytössä olevan tekstinkäsittelysovelluksen seuraavan sukupolven version kehittämistä. Työlle on suunniteltu ja hyväksytty tiukka aikataulu. Millainen organisationaalinen paradigma soveltuu parhaiten ja miksi? Millaisen prosessimallin valitset ja miksi? Tarkastele Putnam & Myersin esittämää metriikoiden yhteysmatriisia. Oletko samaa mieltä nuolien suunnasta? Millaista johtajuutta Royce ehdottaa projektin hallintaan?
24. Projektin hallinta Projektin hallinnassa on neljä tärkeää elementtiä (4 P s) Ihmiset (People) tärkein elementti onnistuneelle projektille Tuote (Product) rakennettava ohjelmisto Prosessi (Process) ohjelmistotuotannon tehtävät, jotka liittyvät työn tekemiseen Projekti (Project) kaikki työvaiheet, joilla haluttu tuote toteutetaan Yksilöt & tiimi Tarkoitus & lajuus Prosessin parantaminen Metriikat Kustannusten arviointi
Ihmiset Tiimin vetäjät MOI johtaminen /Weinberg 1986 Motivointi kyky rohkaista tekemään parhaansa Organisointi kyky muokata prosessi tehokkaaksi Ideat, innovaatiot kyky kannustaa tiimiä työskentelemään luovasti Projektipäällikkö johtaa kuten ongelman ratkaisussa pyrkii ymmärtämään ongelman toimii ideoiden koordinoijana laadusta ei tingitä - ei kompromisseja Ihmiset ovat tärkein resurssi palkkaa hyviä työtekijöitä rakenna tiimit oikein keskinkertaisesta materiaalista voi tulla huipputiimi pidä työntekijät työntekijät kehittyvät ajan myötä anna aikaa vaikeiden ongelmien ratkaisu vaatii aikaa
Organisationaaliset paradigmat Suljettu (closed) paradigma Satunnainen (random) paradigma Avoin (open) paradigma Synkroninen(synchronous) paradigma Constantine 1993 Satunnainen - innovatiivinen yksilö Avoin - sopeutuvaa yhteistyötä ryhmän koheesio Synkroninen - yhtenäinen liittoutuminen luontainen joustavuus Suljettu - perinteinen hierarkia
Organisationaaliset paradigmat Suljettu (closed) paradigma hierarkkinen organisaatio ja selvät roolit, esim. armeija, hallinto ei sovellu innovatiivisuutta vaativiin Satunnainen (random) paradigma painottaa yksilöllisiä aloitteita ja innovatiivisuutta Avoin (open) paradigma Constantine 1993 yhteistyötä painottava, korostaa kommunikointia ja konsensusta soveltuu vaikeiden ongelmien ratkaisuun, ei välttämättä tehokas Synkroninen(synchronous) paradigma ongelma ositetaan ja tiimin jäsenet toimivat suhteellisen itsenäisesti
Ohjelmistotuotteen tarkoitus/laajuus (scope) Product scope Piirteet ja toiminnot, jotka määrittelevät tuotteen Konteksti. Miten rakennettava ohjelmisto sopii laajempaan järjestelmään, tuotteeseen tai liiketoimintaympäristöön? Informaatio. Mitä tietoja ohjelmisto tuottaa tulosteina käyttäjille ja mitä se vaatii syötteinä? Toiminta ja suorituskyky. Miten ohjelmisto käsittelee syötteet tulosteiksi? Onko toiminnalle asetettu suorituskykyvaatimuksia? Project scope: työ, joka tarvitaan tuotteen (valituilla piirteillä ja toiminnoilla) tekemiseen mitkä ovat projektin tavoitteet mitä riskeja ja vaikeuksia tunistetaan miten projekti tulisi organisoida
Milloin projekti on vaarassa? Projekti joutuu vaikeuksiin, kun... Ohjelmistosuunnittelijat eivät ymmärrä asiakkaan tarpeita Tuotteen tarkoitus on huonosti määritelty Muutokset on hallittu huonosti Valittu teknologia muuttuu Liiketoimintatarpeet muuttuvat (tai ovat huonosti määriteltyjä) Aikataulut ovat epärealistisia Käyttäjät vastustavat projektia Projektin tuki häviää (tai sitä ei ole koskaan saatu) Projektitiimistä puuttuu tarpellista osaamista Johto (ja ohjelmistoammattilaiset) ei hyödynnä parhaita käytäntöjä eikä oppimaa (best practices and lessons learned)» John Reel 1999
Ohjelmistoprojektin johtamistyyli /Royce 2005 Johtaminen lähempänä taloustiedettä kuin ohjelmistotekniikkaa päivittäiset päätökset perustuvat kustannusvaihtoehtoihin, henkilöstöön, teknologiatrendeihin, markkinatilanteeseen, ajoitukseen Royce suosittelee ohjaus (steering) tyyppistä johtamista aktiivista johtamista usein tapahtuvaa kurssin korjausta Ohjaustyyppinen johtaminen perustuu iteratiiviseen kehitysprosessiin, kuten RUP johtamistyyliin, joka on tulosperustaista (ei aktiviteettiperustaista) toimiva ohjelma on ensisijainen tarkkuuden ja ymmärryksen yhteyteen täytyy muistaa, että projektin alkuvaiheessa ennusteet eivät ole tarkkoja kun ymmärrys kasvaa, tarkkuus paranee
Neljä mallia (pattern) ohjauksen onnistumiseksi Tarkoitusjohtaminen (scope management) ratkaisut kehittyvät käyttäjän määrittelyistä vaihtoehtoisiin ratkaisuihin lähdetään liikkeelle visiosta, kehitetään käyttötapaukset ja arviointikriteerit (tavoitteet esiteltäville julkaisuille) Prosessin kurinalaisuus kurinalaisuutta kaivataan, jos tiimit ovat hajautuneita, projekti on suuri, laaja sidosryhmä, laatuvaatimukset tiukkoja, projekti on loppuvaiheessa kurinalaisuus kasvaa projektin loppuvaiheessa parannetaan virheenkestoa, suorituskykyä Edistymisen rehellisyys terveet projektit näyttävät edistymisen ja poikkeamat Laadunvalvonta demojulkaisujen testaus tärkeää koko kehitysprosessin ajan
W 5 HH periaate / Boehm 1996 Kysymysten avulla voidaan johtaa projektin tarkoitus ja projektisuunnitelma Miksi (Why) järjestelmää kehitetään? Mitä (What) tehdään? Milloin (When) tehdään? Kuka/ketkä (Who) on/ovat vastuussa? Missä (Where) osallistujat toimivat? myös tiimin ulkopuoliset (käyttäjät, sidosryhmä) Kuinka (How) työ tehdään teknisesti ja hallinnollisesti? Kuinka (How much) paljon resursseja tarvitaan? 12
25. Prosessi- ja projektimetriikat prosessi" tuote" mittaus" prosessimetriikat" projektimetriikat" tuotemetriikat" Mitä käytetään" perusmittareina?" - kokoa (LOC, FP)" - aikaa" - työpanosta" - tuottavuutta" - luotettavuutta (virheiden määrää)" 13
Ohjelmistoprosessin parantaminen (Software Process Improvement, SPI) Prosessimalli" Suositukset prosessin" parantamiseksi" Parantamisen tavoitteet" SPI" Prosessimetriikat" esim. " - virheen poiston tehokkuus" - löydettyjen virheiden määrä / kehitysvaihe" 14
Virheen poiston tehokkuus (Defect Removal Efficiency, DRE) DRE = E /(E + D)! E ennen loppukäyttäjälle toimitusta löydettyjen virheiden määrä! D toimituksen jälkeen löydettyjen virheiden määrä.! " 15
Ohjeita prosessimetriikan käsittelylle/ Grady 1992 Käytä maalaisjärkeä ja organisaatiokohtaista herkkyyttä metriikkatiedon tulkinnassa. Kerro säännöllisesti mittaustuloksista henkilöille, jotka keräävät dataa. Älä käytä metriikoita yksilöiden arviointiin. Aseta tavoitteet ja kiinnitä metriikat yhteistyössä tiimien kanssa. Älä koskaan käytä metriikoita yksilöiden ja tiimien uhkailuun. Metriikkatieto, joka paljastaa ongelmia, ei ole negatiivista, sitä tulee käyttää prosessin parantamiseen.
Viisi metriikkaa / Putnam & Myers 2003 Koko tai työn määrä (tuote) Koodiriveinä, toimintopistearviona, käyttötapauksina Aika (projekti) Kuukausina, viikkoina Työpanos (projekti) Henkilötyökuukausina, henkilötyötunteina Tuottavuus tai tehokkuus (projekti, prosessi) Koko / käytetyt työkuukaudet Luotettavuus (virheet tai puutteellisuudet (defects)) (projekti, prosessi, tuote) Virheen vakavuus Virheiden kokonaismäärä, virheitä / KLOC
Miten metriikat liittyvät toisiinsa? Ihmiset, jotka tekevät työtä tietyllä tuottavuudella, saavat aikaan tietyn määrän tietyn laatutason toimintoja tai tuotteita (work product) käyttäen siihen tietyn työpanoksen tietyssä kalenteriajassa.
Metriikoiden yhteydet / Putnam & Myers 2003 Tavoite ( mantra ) Koko Aika Työpanos Tuottavuus (koko/työpanos) Luotettavuus Nopeammin (pyritään tekemään nopeammin) Paremmin (pyritään tekemään paremmin) Halvemmalla (pyritään tekemään halvemmalla)
Onnistuneessa projektissa viisi metriikkaa näkyvät seuraavasti 1. Projektiin osallistujat saavat jotain tehtyä... 2. sovelluksen vaatimalla laatutasolla... 3. suunnitellussa kalenteriajassa... 4. suunnitellulla työpanoksella... 5. kilpailukykyisellä tuottavuustasolla 20
Tyypillisiä projektimetriikoita Työpanos/aika tiettyä tehtävää kohden Löydettyjen virheiden määrä katselmointituntia kohden Aikataulutetut vs. todelliset etapit Muutosten määrä ja luonne Työpanoksen jakautuminen eri tehtäville
26. Projektin koon arviointi Projektin tarkoitus täytyy ymmärtää Tarvitaan yksityiskohtaista suunnittelua ja osittamista Historiallinen metriikkatieto on yleensä välttämätöntä ja aina erittäin tärkeää. Pitäisi käyttää kahta eri tekniikkaa, esim. LOC, FP Arvioinnin epävarmuus täytyy muistaa 22
Toiminnallinen ositus Tavoite ja " laajuus" (scope)" Jäsennys tekstin perusteella" toiminnallinen" ositus" 23
Esimerkkejä projektikustannusten arvioinneista (Pressman 2005) Kehitettävä ohjelmisto (yritys on aikaisemminkin tehnyt samankaltaisia ohjelmistoja): CAD (computer aided design) sovellus mekaanisten komponenttien piirtoon. Ohjelmisto käyttää syöttötietoina kaksi- ja kolmiulotteista geometrista dataa. Käyttäjän ja ohjelmiston vuorovaikutuksen suunnittelussa noudatetaan hyviä käyttöliittymäsuunnittelun periaatteita. Kaikki data ja käsittelyn aikana syntyvä tieto talletetaan tietokantaan. Sekä kaksi- että kolmiulotteisen datan käsittely ja tulostus eri muodoissa tehdään omissa moduuleissa. Ohjelmiston syöttö- ja tulostuslaitteistoina käytetään hiirtä, digitoijaa, kirjoitinta ja piirturia. 24
Esimerkki: LOC pohjainen arvio Funktio Arvio LOC user interface and control facilities (UICF) two-dimensional geometric analysis (2DGA) three-dimensional geometric analysis (3DGA) database management (DBM) computer graphics display facilities (CGDF) peripheral control (PC) design analysis modules (DAM) Keskimääräinen tuottavuus (perustuu historiatietoon) = 620 LOC/htkk. Työkustannukset 8000 euroa/kk, koodirivin kustannus noin 13 euroa Rivimääräarvion ja kustannusarvion pohjalta saadaan arvio projektikustannuksille: 431,000 euroa ja arvioitu työpanos 54 htkk. 2,300 5,300 6,800 3,350 4,950 2,100 8,400 arvio koodiriveistä 33,200 25
Esimerkki: toimintopistepohjainen arvio Information Weighting factor Domain Value Count simple average complex External Inputs (EIs) External Outputs (EOs) External Inquiries (EQs) Internal Logical Files (ILFs) External Interface Files (EIFs) 24 16 22 4 2 x3 x3 3x 3x 3x 3 4 6 4 5 7 3 4 6 7 10 15 5 7 10 = = = = = 96 80 88 40 14 Count total 318 FP arvio = 318 * [0.65 + 0.01 * SUM (Fi)] = 318 * [0.65 + 0.01 * 52] = 318 * 1.17 = 372 Keskimääräinen tuottavuus (perustuu historiatietoon) = 6,5 FP/htkk. Työkustannukset 8000 euroa/kk, FP kustannus noin 1230 euroa FP-arvion ja kustannusarvion pohjalta saadaan arvio projektikustannuksille: 458,000 euroa ja arvioitu työpanos 57 htkk. 26
Rivimäärän ja toimintopisteen vertailu Programming LOC per Function point Language avg. median low high Ada 154-104 205 Assembler 337 315 91 694 C 162 109 33 704 C++ 66 53 29 178 COBOL 77 77 14 400 Java 63 53 77 - JavaScript 58 63 42 75 Perl 60 - - - PL/1 78 67 22 263 Powerbuilder 32 31 11 105 SAS 40 41 33 49 Smalltalk 26 19 10 55 SQL 40 37 7 110 Visual Basic 47 42 16 158 perustuvat QSM tuloksiin /www.qsm.com" 27
Esimerkki: prosessipohjainen arvio Activity CC Planning Risk Analysis Engineering Construction Release CE Totals Task analysis design code test Function UICF 2DGA 3DGA CGDF DSM PCF DAM 0.50 0.75 0.50 0.50 2.50 4.00 4.00 3.00 0.40 0.60 1.00 1.00 5.00 2.00 3.00 1.50 n/a n/a n/a n/a 8.40 7.35 8.50 6.00 0.50 3.00 0.75 1.50 n/a 5.75 0.25 2.00 0.50 1.50 n/a 4.25 0.50 2.00 0.50 2.00 n/a 5.00 Totals % effort 0.25 0.25 0.25 3.50 20.50 4.50 16.50 46.00 1% 1% 1% 8% 45% 10% 36% CC = customer communication CE = customer evaluation Työkustannukset ovat 8,000 euroa / htkk" Arvioidut projektin kustannukset 368,000 euroa" Tarvittava työpanos arviolta 46 htkk.! 28
Korjattu prosessipohjainen arvio + 1 htkk (esitutkimus) Analysis Design Code Test Total UICF 0.4 1.5 0.7 1.4 4 2DGA 0.75 3 1.25 2 7 3DGA 0.8 5 1.2 3 10 CGDF 0.8 4 1.2 2 8 DBM 0.4 3 0.6 1.75 5.75 PCF 0.5 1.5 0.75 1.5 4.25 DAM 1 6 3 5 15 Total 4.65 24 8.7 16.65 54 % effort 8.61 44.44 16.11 30.83 Työkustannukset ovat 8,000 euroa / htkk" Arvioidut projektin kustannukset 440,000 euroa" Tarvittava työpanos arviolta 55 htkk.! 29
Esimerkki: käyttötapausperustainen arvio päätekijät use cases scenarios pages scenarios pages LOC LOC estimate User interface e subsystem 6 10 6 12 5 560 3,366 Engineering subsystem group 10 20 8 16 8 3100 31,233 Infrastructure e subsystem group group 5 6 5 10 6 1650 7,970 Total LOC estimate stimate 42,568 LOC estimate = N * LOC avg + [(S a / S h - 1) + [(P a / P h - 1)] * LOC adjust keskimääräinen tuottavuus on 620 LOC/htkk ja! työkustannukset 8000 euroa / htkk, koodirivin kustannus noin 13 euroa Arvioidut projektin kustannukset 552,000 euroa ja! arvioitu työmäärä 68 htkk.! 30
Kokemusperäiset arviomallit Yleinen muoto:" effort = tuning coefficient * size" exponent" tavallisesti" työpanos (htkk)" vakio tai projektin" mutkikkuutta " kuvaava numero" aiemman" kokemuksen" perusteella" tavallisesti LOC" tehty arvio" voi olla myös FP" 31
LOC ja FP perustaiset mallit LOC perustaiset E = 5.2 * (KLOC) 0.91 Walston-Felix malli E = 5.5 + 0.73 * (KLOC) 1.16 Bailey-Basili malli E = 3.2 * (KLOC) 1.05 Boehm (keskinkertainen) malli FP perustaiset E = -91.4 + 0.355 FP Albrect & Gaffney malli E = -37 + 0.96 FP Kemerer malli E = -12.88 + 0.405 FP pienten projektien regressiomalli Mallit antavat samoilla KLOC ja FP arvoilla eri työmääräarvion Siksi mallit täytyy aina kalibroida paikallisiin olosuhteisiin FP arvojen sijaan voidaan käyttää Object points, OP erilaisten näyttöjen määrä, yksinkertainen = 1 OP, mutkikas = 3 OP tuotettujen raporttien määrä, 1-8 OP lausekielisten moduulien määrä, moduuli = 10 OP
COCOMO (Constructive Cost Model) Boehm 1981 Mallista on kolme versiota: Basic, Intermediate ja Detailed Basic mallissa projektit luokitellaan kolmeen luokkaan: helppo tehtävä (organic), normaali tehtävä (semi detached) ja vaikea tehtävä (embedded). Henkilötyömääräarvio (MM, man month) perustuu pitkälle tuotteen KDSI (thousand delivered source instruction) arvoon ja saadaan vaikeusasteesta riippuen seuraavilla kaavoilla helppo: MM = 2.4 * KDSI 1.05 hyvin ymmärretyt sovellukset, pienet tiimit normaali: MM = 3.0 * KDSI 1.12 mutkikkaampia projekteja, tiimillä ei riittävästi kokemusta sovellusalueelta vaikea: MM = 3.6 * KDSI 1.20 vaikeat projektit, ohjelmisto osa mutkikkaasta kokonaisuudesta, joka koostuu tiukasti toisiinsa liittyvistä laitteistoista, ohjelmistoista, säädöksistä
COCOMO (Constructive Cost Model) Kalenteriaika-arvio perustuu laskettuun MM arvoon ja saadaan vaikeusasteesta riippuen seuraavilla kaavoilla helppo: T dev = 2.5 * MM 0.38 normaali: T dev = 2.5 * MM 0.35 vaikea: T dev = 2.5 * MM 0.32 Esimerkkinä 15.000 rivin Web sovellus, joka toteutetaan Java kielellä ja kehittäjät ovat kokeneita, jolloin vaikeusaste on helppo MM = 2.4 * 15 1.05 = 41 htkk T dev = 2.5 * 41 0.38 = 10 kk
Työmäärä (HTKK) 100 200 300 400 500 600 700 800 900 1000 10 20 30 40 50 60 70 80 90 100 Ohjelmiston koko (KDSI) Kalenteriaika (KK) 0 2 4 6 8 10 12 14 16 18 20 22 24 10 20 30 40 50 60 70 80 90 100 Ohjelmiston koko (KDSI) helppo tehtävä normaali tehtävä vaikea tehtävä Koon vaikutus työmäärään Koon vaikutus kalenteriaikaan
COCOMO (Constructive Cost Model) Intermediate mallissa arvio tehdään kahdessa vaiheessa alkuarvio (nimellinen MM) perustuu tuotteen KDSI (thousand delivered source instruction) ja kehitettävän tuotteen haastavuuteen (helppo, normaali, vaikea) esim. helppo tuote, arvio koosta 12.000 DSI työpanos (nmm) = 3.2 * (12) 1.05 htkk = 43 htkk tätä arviota voidaan korjata kustannuskertoimella, joka perustuu 15 osatekijään esim. vaadittu luotettavuus, suoritusaikarajoitukset ohjelmoijan kyvykkyys, uusien ohjelmointikäytäntöjen käyttö tekijät voivat saada arvoja 0.70, 0.85, 1.00, 1.15, 1.30 ja 1.65 jos kokonaiskerroin on esim. 1.35, niin korjattu työpanos (MM) = 1.35 * 43 = 58 htkk
COCOMO-II COCOMO II koostuu neljästä mallista (joita voidaan käyttää kehityksen eri vaiheissa): Sovelluksen rakenteeseen perustuva (Application composition model) käytetään hyvin varhaisessa vaiheessa, kun tiedetään rakennettavan sovelluksen perusrakenne ja käytettävä teknologia laskennan perustana application points = object points Aikaiseen suunnitteluun perustuva (Early design model) käytetään, kun vaatimusmäärittelyt pysyvät vakaana laskennan perustana function points Uudelleenkäyttöön perustuva (Reuse model) käytetään yhdessä post-architecture mallin kanssa arvioidaan uudelleenkäytettävien komponenttien ja koodin generoinnin vaatimaa työmäärää, laskennan perustana LOC Arkkitehtuurivaiheen jälkeinen (Post-architecture model) käytetään ohjelmiston rakentamisen aikana laskennan perustana LOC, joka on summa uudesta koodista, uudelleenkäytetystä koodista ja muutetusta koodista korjauskertoimena voidaan käyttää 17 attribuuttia
Olioprojektin koon arviointi Skenaarioiden määrä (käyttötapaukset) Ydinluokkien määrä (määritelty jo analyysivaiheessa) Tukiluokkien määrä (tarvitaan järjestelmän rakentamiseen, mutta eivät ole ongelman ratkaisuun käytettäviä ydinluokkia) Yhtä ydinluokkaa vastaavien tukiluokkien määrä. GUI sovelluksissa tukiluokkia 2-3 kertaa ydinluokkien määrä Ei-GUI sovelluksissa tukiluokkia 1-2 kertaa ydinluokkien määrä Lorenz & Kidd Arvioi tukiluokkien määrä kertomalla edellisessä vaiheessa saadulla kertoimella avainluokkien lkm:n. Kerro näin saatu luokkien kokonaismäärä yhden luokan rakentamiseen tarvittavalla työmääräarviolla (Lorenz ja Kidd ehdottavat 15-20 työpäivää/luokka). Tarkista saatu arvio käyttötapausperustaisella arviolla
27. Projektin aikataulun kiinnittäminen työn osittaminen - WBS WBS (work breakdown structure) on puurakenne, joka kuvaa esim. projektin tai sopimuksen vaatiman työpanoksen. Tällöin kuvataan lopputulos ja sen jakaminen hallittaviin komponentteihin (järjestelmät, osajärjestelmät, komponentit, tehtävät, osatehtävät, työpakkaukset) Tehtävät (tai osatehtävät) ovat yhdelle henkilölle ositettavissa oleva rajattu työkokonaisuus, josta henkilö selviää 2-3 viikossa
http://www.criticaltools.com/wbschartprosoftware.htm
Projektin vastuiden määrittely Responsibility Assignment Matrix (RAM) Projektin vastuiden määrittelyn pohjana ovat projektin tehtävien määritys WBS (work breakdown structure) siihen liittyvät työmääräarviot käytettävissä olevat resurssit osaaminen työpanos vastuu Lopputuloksena on Responsibility Assignment Matrix (RAM) 41
Projektin aikataulutus Tietty tehtävä toteutetaan aktiviteetilla Aktiviteettiin liittyy alkamisajankohta, päättymisajankohta tekijät, käytettävä työpanos vaihetuotteet (deliverables) Aktiviteettien päättymisajankohtia sanotaan etapeiksi (milestones) Etappi on saavutettu, kun aktiviteetin vaihetuotteet on hyväksytty projektisuunnitelman määrittämällä tavalla (esim. projektikatselmuksessa) Aktiviteetti 1 Aktiviteetti 2 Aktiviteetti 3 Aktiviteetti 4...
Esimerkki aikataulutuksesta (Gantt-kaavio) Aktiviteetti" viikko 30" viikko 31" viikko 32" viikko 33" viikko 34" viikko 35" Aktiviteetti 1 Aktiviteetti 2 Aktiviteetti 3 Aktiviteetti 4 Aktiviteetti 5 Aktiviteetti 6 Aktiviteetti 7 Tarkasteluajankohta
Earned Value Management (EVM) (Earned Value Analysis, EVA) Projektin hallinta ansaitun arvon perusteella Ansaittu arvo (Earned value) mittaa kehitystä arvioidaan projektin valmiusastetta suorittamalla määrämuotoista analyysiä aikataulutettujen tehtävien suoritusasteesta 44
Miten ansaittu arvo lasketaan... Työn budjetoitu kustannus (budgeted cost of work scheduled, BCWS) on määritelty jokaiselle aikataulun tehtävälle BCWS i on suunniteltu työpanos tehtävälle i. tietyllä ajan hetkellä voidaan laskea arvo BCWS, joka on niiden tehtävien BCWS i arvojen summa, joiden pitäisi olla suunnitelmien (aikataulun) mukaan olla valmiina käytetään myös termiä PV (planned value) Valmiiden tehtävien budjetti (budget at completion, BAC) määritellään kaikkien tehtävien BCWS i arvojen summana. BAC = (BCWS k ) kaikille tehtäville k 45
Ansaitun arvon laskenta CPI = EV / AC SPI = EV / PV PV BAC kustannukset AC SV CV EV aika Lipke & Henderson 2006
Miten ansaittu arvo lasketaan... Seuraavaksi lasketaan suoritetun työn budjetoidut kustannukset (budgeted cost of work performed, BCWP). BCWP on kaikkien valmiiden tehtävien BCWS arvojen summa tietyllä ajan hetkellä. käytetään myös termiä EV (earned value) the distinction between the BCWS and the BCWP is that the former represents the budget of the activities that were planned to be completed and the latter represents the budget of the activities that actually were completed. [WIL99] BCWS, BAC ja BCWP arvojen perusteella voidaan laskea : Aikataulupohjainen suorituskyky (Schedule performance index, SPI) = BCWP/BCWS tai EV/PV (hyvä, jos > 1) Aikataulupoikkeama (Schedule variance, SV) = BCWP BCWS SPI kuvaa resurssien käytön tehokkuutta. 47
Miten ansaittu arvo lasketaan... Arvioitu valmiusaste (Percent scheduled for completion) = BCWS/BAC = (PV /BAC) mikä prosenttiosuus tulisi olla valmiina hetkellä t. Todellinen valmiusaste (Percent complete) = BCWP/ BAC = (EV/BAC) mikä osuus todella on valmiina hetkellä t. Todellinen työkustannus (Actual cost of work performed, ACWP = AC), todellinen työkustannus tehtävistä, jotka ovat valmiina tietyllä hetkellä. Sen jälkeen voidaan laskea kustannuspohjainen suorituskyky (Cost performance index, CPI) = BCWP/ACWP = EV/AC Kustannuspoikkeama (Cost variance, CV) = BCWP ACWP 48
Soveltuvat lait ja pohdiskelun aiheita 1. Kehittyvä järjestelmä monimutkaistuu, kunnes erityisillä toimenpiteillä vähennetään monimutkaisuutta / no 28, Lehman 1980 ajan mittaan järjestelmän ylläpito käy mahdottomaksi, silloin tarvitaan järjestelmän uudelleenrakentamista 2. Ohjelmoijien suorituskyky vaihtelee huomattavasti / no 31, Sackman 1968 lakiin on uskottu, eikä vastaavaa koetta ole järjestetty 35 vuoteen
Soveltuvat lait ja pohdiskelun aiheita 3 Ryhmän käytös on riippuvainen siihen kohdistetusta huomiosta /hyp_no 19, Hawthorne 1932 (Parsons 1974) hypoteesi on peräisin kokeesta sähköyhtiössä ryhmän sosiaalisilla normeilla ja ei-taloudellisilla palkkioilla ja rangaistuksilla on suuri vaikutus työkäyttäytymiseen soveltuvuudesta myös ohjelmistokehitykseen ollaan eri mieltä kokeen tulkinnoista monia näkemyksiä
Soveltuvat lait ja pohdiskelun aiheita Toimit projektipäällikkönä ohjelmistoyrityksessä. Tehtävänäsi on hallita laajassa käytössä olevan tekstinkäsittelysovelluksen seuraavan sukupolven version kehittämistä. Työlle on suunniteltu ja hyväksytty tiukka aikataulu. Millainen organisationaalinen paradigma soveltuu parhaiten ja miksi? Millaisen prosessimallin valitset ja miksi? Tarkastele Putnam & Myersin esittämää metriikoiden yhteysmatriisia. Oletko samaa mieltä nuolien suunnasta? Millaista johtajuutta Royce ehdottaa projektin hallintaan? Royce W., Successful Software Management Style: Steering and Balance, IEEE Software, vol 22, no 5, 2005, pp. 40-47
Harjoitustehtävät: viikko 8 Toimintopistearvio annetulle tehtävälle Suunnittelemanne keskusteluohjelmiston työmääräarvio käyttötapausten perusteella. Projektin tilanteen arvio ansaitun arvon menetelmällä. 52