Ohjelmistotekniikka - Luento 12 Jouni Lappalainen

Transkriptio

1 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

2 Soveltuvat lait ja pohdiskelun aiheita 1. Kehittyvä järjestelmä monimutkaistuu, kunnes erityisillä toimenpiteillä vähennetään monimutkaisuutta / no 28, Lehman Ohjelmoijien suorituskyky vaihtelee huomattavasti /no 31, Sackman Ryhmän käytös on riippuvainen siihen kohdistetusta huomiosta /hyp_no 19, Hawthorne 1932 (Parsons 1974)

3 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?

4 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 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

15 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

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

17 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

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

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

20 Onnistuneessa projektissa viisi metriikkaa näkyvät seuraavasti 1. Projektiin osallistujat saavat jotain tehtyä sovelluksen vaatimalla laatutasolla suunnitellussa kalenteriajassa suunnitellulla työpanoksella kilpailukykyisellä tuottavuustasolla 20

21 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

22 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

23 Toiminnallinen ositus Tavoite ja " laajuus" (scope)" Jäsennys tekstin perusteella" toiminnallinen" ositus" 23

24 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

25 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

26 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) x3 x3 3x 3x 3x = = = = = Count total 318 FP arvio = 318 * [ * SUM (Fi)] = 318 * [ * 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

27 Rivimäärän ja toimintopisteen vertailu Programming LOC per Function point Language avg. median low high Ada Assembler C C COBOL Java JavaScript Perl PL/ Powerbuilder SAS Smalltalk SQL Visual Basic perustuvat QSM tuloksiin / 27

28 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 n/a n/a n/a n/a n/a n/a n/a 5.00 Totals % effort % 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

29 Korjattu prosessipohjainen arvio + 1 htkk (esitutkimus) Analysis Design Code Test Total UICF DGA DGA CGDF DBM PCF DAM Total % effort Työkustannukset ovat 8,000 euroa / htkk" Arvioidut projektin kustannukset 440,000 euroa" Tarvittava työpanos arviolta 55 htkk.! 29

30 Esimerkki: käyttötapausperustainen arvio päätekijät use cases scenarios pages scenarios pages LOC LOC estimate User interface e subsystem ,366 Engineering subsystem group ,233 Infrastructure e subsystem group group ,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

31 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

32 LOC ja FP perustaiset mallit LOC perustaiset E = 5.2 * (KLOC) 0.91 Walston-Felix malli E = * (KLOC) 1.16 Bailey-Basili malli E = 3.2 * (KLOC) 1.05 Boehm (keskinkertainen) malli FP perustaiset E = FP Albrect & Gaffney malli E = FP Kemerer malli E = 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

33 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ä

34 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ä rivin Web sovellus, joka toteutetaan Java kielellä ja kehittäjät ovat kokeneita, jolloin vaikeusaste on helppo MM = 2.4 * = 41 htkk T dev = 2.5 * = 10 kk

35 Työmäärä (HTKK) Ohjelmiston koko (KDSI) Kalenteriaika (KK) Ohjelmiston koko (KDSI) helppo tehtävä normaali tehtävä vaikea tehtävä Koon vaikutus työmäärään Koon vaikutus kalenteriaikaan

36 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 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

37 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

38 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 työpäivää/luokka). Tarkista saatu arvio käyttötapausperustaisella arviolla

39 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

40

41 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

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

43 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

44 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

45 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

46 Ansaitun arvon laskenta CPI = EV / AC SPI = EV / PV PV BAC kustannukset AC SV CV EV aika Lipke & Henderson 2006

47 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

48 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

49 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

50 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ä

51 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

52 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