Ohjelmistotekniikka - Luento 6

Transkriptio

1 Ohjelmistotekniikka - Luento 6 Luku 24: Projektin hallinnan käsitteet - ihmiset, tuote, prosessi ja projekti - W5HH 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!1

2 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 Yksilöt & tiimi Tarkoitus & laajuus Prosessin parantaminen Metriikat Projekti (Project) kaikki työvaiheet, joilla haluttu tuote toteutetaan Kustannusten arviointi!2

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

4 Organisationaaliset paradigmat Constantine 1993 Suljettu (closed) paradigma Satunnainen (random) paradigma Avoin (open) paradigma Synkroninen(synchronous) paradigma Satunnainen - innovatiivinen yksilö Synkroninen - yhtenäinen liittoutuminen ryhmän koheesio luontainen joustavuus Avoin -sopeutuvaa yhteistyötä Suljettu - perinteinen hierarkia

5 Organisationaaliset Suljettu (closed) paradigma paradigmat 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 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 Constantine 1993!5

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

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

8 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!8

9 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!9

10 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?!10

11 25. Prosessi- ja projektimetriikat prosessi prosessimetriikat mittaus projektimetriikat tuotemetriikat tuote Mitä käytetään perusmittareina? -kokoa (LOC, FP) -aikaa -työpanosta -tuottavuutta -luotettavuutta (virheiden määrää)!11

12 Ohjelmistoprosessin parantaminen (Software Process Improvement, SPI) Prosessimalli Suositukset prosessin parantamiseksi Parantamisen tavoitteet SPI Prosessimetriikat esim. - virheen poiston tehokkuus - löydettyjen virheiden määrä / kehitysvaihe!12

13 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ä.!13

14 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.!14

15 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!15

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

17 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)!17

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

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

20 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!20

21 Toiminnallinen ositus Tavoite ja laajuus (scope) Jäsennys tekstin perusteella toiminnallinen ositus!21

22 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.!22

23 Esimerkki: LOC pohjainen arvio Funktio 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) Arvio LOC 2,300 5,300 6,800 3,350 4,950 2,100 8,400 arvio koodiriveistä 33,200 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.!23

24 Esimerkki: toimintopistepohjainen arvio x x x x x 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.!24

25 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 /

26 Esimerkki: prosessipohjainen arvio Työkustannukset ovat 8,000 euroa / htkk Arvioidut projektin kustannukset 368,000 euroa Tarvittava työpanos arviolta 46 htkk.!26

27 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.!27

28 Esimerkki: käyttötapausperustainen arvio päätekijät 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.!28

29 Kokemusperäiset arviomallit Yleinen muoto: exponent effort = tuning coefficient * size tavallisesti työpanos (htkk) vakio tai projektin mutkikkuutta kuvaava numero tavallisesti LOC voi olla myös FP aiemman kokemuksen perusteella tehty arvio!29

30 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!30

31 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ä!31

32 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!32

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

34 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!34

35 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!35

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

37 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!37

38

39 Task network chart with critical path (red)

40 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)!40

41 Projektin aikataulutus Tietty tehtävä toteutetaan aktiviteetilla Aktiviteettiin liittyy alkamisajankohta, päättymisajankohta tekijät, käytettävä työpanos vaihetuotteet (deliverables) Aktiviteetti 1 Aktiviteetti 2 Aktiviteetti 3 Aktiviteetti 4... Aktiviteettien päättymisajankohtia sanotaan etapeiksi (milestones) Etappi on saavutettu, kun aktiviteetin vaihetuotteet on hyväksytty projektisuunnitelman määrittämällä tavalla (esim. projektikatselmuksessa)!41

42 Esimerkki aikataulutuksesta (Ganttkaavio) Katso myös MS Project ja

43 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!43

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!44

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

46 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.!46

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!47