arviointi edellyttää historiatietoja, esim. mittareiden kalibroimiseksi

Transkriptio

1 Työmäärän arviointi algoritmiset menetelmät asiantuntija-arviot analogiaan perustuvat arviot Parkinsonin laki: "Työ vie kaiken käytettävissä olevan ajan." hinnoittelu kilpailun mukaan top-down arviointi bottom-up arviointi arviointi edellyttää historiatietoja, esim. mittareiden kalibroimiseksi useimmiten arviointi perustetaan kokonaisuuden jakamiseen komponenteiksi miten jako pystytään tekemään jo projektin alkaessa? kokemukset aiemmista projekteista periaatepäätökset on syytä arvioida kustannuksia useilla menetelmillä ja verrata: esim. algoritminen kustannusmalli aiemman projektin kustannusarvio (modifioituna) jaottelu, osakustannusten arviointi ja summaus Ohjelmistotuotanto kevät Harri Laine - työmäärän arviointi 1

2 Työmääräarviot Lähtökohtana arvioitu tuotteen koko. Yksikkönä käskyt, rivimäärä, monimutkaisuus, Ohjelmakoodin määrä - lähdekielisten käskyjen lukumäärä DSI (delivered source instructions) - ohjelmarivien lukumäärä LOC (lines of code) - vaikea arvioida projektin alkuvaiheessa - kokoon perustuvat arviot eivät yleensä ota huomioon vaatimusanalyysivaihetta - koko vaikuttaa kustannuksiin ylilineaarisesti Mitä lasketaan vaikuttaa tulokseen (max/min = noin 5) vain 'loogiset rivit' eli syntaktiset rakenteet (source instruction) vain suoritettavat rivit suoritettavat rivit ja tietomäärittelyt suoritettavat rivit, tietomäärittelyt ja kommentit suoritettavat rivit, tietomäärittelyt, kommentit ja käännösdirektiivit Ohjelmistotuotanto kevät Harri Laine - työmäärän arviointi 2

3 Miten suhtaudutaan muunnettuun ja / tai uudelleenkäytettävään koodiin: lasketaan vain uudet rivit uudet ja muutetut uudet, muutetut ja uudelleenkäytetyt (kirjastosta otetut) kaikki toimitetut kaikki toimitetut ja kehityksessä tarvitut kaikki toimitetut, kehityksessä tarvitut ja tukikoodi Jonkinlainen yhteensovitus paikallaan, esim riviä uudelleenkäytettyä koodia = 500 riviä uutta 1000 riviä kommentteja = 200 riviä uutta koodia Ohjelmiston muunnettu koko = uusien rivien lukumäärä + 0.5* uudelleenkäytettyjen rivien lukumäärä + 0.2* kommenttirivien lukumäärä. Tiettyyn tehtävään tarvittavien ohjelmarivien lukumäärä riippuu sekä käytettävästä ohjelmointikielestä että tehtävän luonteesta Toimintopisteet (Function points) toimintopisteet mittaavat ohjelmiston kokoa syötteiden, tulosteiden ja käsittelyn määrään perustuen. Ohjelmistotuotanto kevät Harri Laine - työmäärän arviointi 3

4 Työmäärä ei riipu yksin ohjelmiston koosta, vaan useat tekijät vaikuttavat lisäksi, esim: - vaadittu luotettavuus: tiukat luotettavuusvaatimukset lisäävät kustannuksia projektin kaikissa vaiheissa, erityisesti testausvaiheessa - monimutkaisuus: keskeisimpiä kustannuksia lisääviä tekijöitä monimutkaisuuteen vaikuttavia tekijöitä: kontrollin kulku, rinnakkaisuus moduulien välinen kommunikointi kirjastorutiinien käyttö tiedonhallintaoperaatiot I/O-operaatiot - työympäristön (laitteiston) ominaisuudet nopeus- ja tilarajoitukset toimivaa sovellusta koskevat ohjelmistoprojektia koskevat työympäristön muuttuvuus - projektiin liittyvät tekijät - työmenetelmät ja työkalut koulutus: hyöty ei välttämättä näy ensimmäisissä projekteissa työmoraali, viihtyvyys yms. Miten mitataan? - aikataulurajoitukset Ohjelmistotuotanto kevät Harri Laine - työmäärän arviointi 4

5 Esimerkki algoritmisesta kustannusten arvioinnista: COCOMO (Boehm) - yleinen sopii kaikenlaisille järjestelmille COnstructive COst MOdel kolme laajuudeltaan erilaista versiota, joissa otetaan huomioon erilainen määrä vaikuttavia osatekijöitä - perustuu koodirivien määrän arviointiin 1. Basic COCOMO - kustannusten (= työmäärän) ja projektin keston arviointi perustuu ohjelman kokoon missä MM = a*k b, T = c*mm d, MM on projektin työmäärä henkilötyökuukausina T on projektin kesto kuukausina K on ohjelmiston koko tuhansina lauseina Ohjelmistotuotanto kevät Harri Laine - työmäärän arviointi 5

6 vakiot a, b, c ja d riippuvat ohjelmiston tyypistä: helppo malli(organic) normaali (semidetached) vaativa (embedded) tekijä helppo normaali vaativa a b c d Esim.: helppo rivin Pascal kääntäjä MM= 2.4 * = n. 41 henkilötyökuukautta T= 2.5 * = n. 10 kuukautta joten projektiryhmän koko on 41/10 eli 4-5 henkilöä. huomioita: ohjelmiston koon kasvaessa työmäärä kasvaa ylilineaarisesti aikataulua ei voida kiristää mielin määrin pelkästään lisäämällä työntekijöitä Ohjelmistotuotanto kevät Harri Laine - työmäärän arviointi 6

7 2. Intermediate COCOMO - perusmallista saatua työmäärää modifioidaan työn ominaisuuksista riippuvilla korjauskertoimilla: MM = a*k b * c1 * c2 *... * c15 missä kukin ci kuvaa tietyn tekijän vaikutusta työmäärään - korjauskertoimen c i arvot vaihtelevat tyypillisesti välillä (0.7,..., 1.6) - tärkeimpiä tekijöitä: henkilöstön kyvykkyys tuotteen monimutkaisuus luotettavuusvaatimus tekijä helppo normaali vaativa a b c d Detailed COCOMO - jaottelee ohjelmiston osiksi: moduulit, alijärjestelmät, vaiheet - kunkin osakokonaisuuden kustannuksia arvioidaan erikseen - vaiheiden osuus kokonaisuudesta Ohjelmistotuotanto kevät Harri Laine - työmäärän arviointi 7

8 COCOMO:n (ja muiden vastaavien) ongelmia - epätarkkuus - tuotantoprosessin vaikutus? - tulevan tuotteen koon arvioiminen vaikeaa - kustannusarvio sisältää suunnittelu- ja toteutusvaiheen kustannukset ei vaatimusanalyysin kustannuksia - kertoimien vaihteluvälit ovat suuret, jolloin pieni arviointivirhe kertointa määrättäessä voi johtaa suuriin eroihin lopputuloksissa - kertoimet on syytä kalibroida oikeaan ympäristöön: malli on käyttökelpoinen vain, jos kalibrointiin käytetty aineisto vastaa käyttötilannetta - käytetty kertoimien joukko ei välttämättä ole paras: uusien kertoimien lisääminen vaatii kalibroinnin riittävän laajalla aineistolla Ohjelmistotuotanto kevät Harri Laine - työmäärän arviointi 8

9 Toimintopistemenetelmä (Albrecht) Albrecht: Measuring Application Development Productivity, Proc. IBM Application Development Symposium, Monterey, CA, 1979, Työmäärän mittana toimintopisteet vaikuttavat tekijät - syötteiden määrä - tulosteiden määrä - kyselyjen määrä - kantatiedostojen määrä - liittymien määrä nämä jaotellaan: - yksinkertaisiin, - tavallisiin ja - vaativiin jolloin saadaan 15 luokkaa kuhunkin 15 luokkaan liittyy oma painokerroin, jolla lukumäärä kerrotaan, painotettu summa on toimintopisteiden peruslukumäärä (PP) simple average complex total inputs * 3 * 4 * 6 outputs * 4 * 5 * 7 inquiries * 3 * 4 * 6 files * 7 * 10 * 15 interfaces * 5 * 7 * 10 Ohjelmistotuotanto kevät Harri Laine - työmäärän arviointi 9

10 Toimintopistemäärä saadaan kun lisäksi otetaan huomioon tuotteen monimutkaisuustekijät (14 kpl): (F i : pisteytys 0-5) - varmistus - tietoliikenne - hajautettu käsittely - suorituskykyvaatimukset - laiteympäristö - on-line -käyttö - syöttötapahtumien laajuus - on-line -päivitys - syötteiden, tulosteiden ja tiedostojen monimutkaisuus - käsittelyn monimutkaisuus - koodin uudelleenkäytettävyys - sisältyykö konversio ja asennus - käytön laajuus - muutettavuus ja helppokäyttöisyys no incidental moderate average significant essential influence TP = PP*( *SUM(F i )) vaihteluväli 0.65*PP *PP Ohjelmistotuotanto kevät Harri Laine - työmäärän arviointi 10

11 Edut ja ongelmat: - luokittelun subjektiivisuus - korjaustekijöiden arviointi - vanhentuneet korjaustekijät ja perustekijät - sopiiko uusiin suunnittelumenetelmiin? + riippumaton ohjelmointikielestä + arvioitavissa aiemmin kuin rivilukumäärä + nopeus Toimintopisteiden muunnelmia - perustana käsitemalli/oliomalli - tuotetyyppikohtaiset tekijät vastaavuus toimintopisteet / ohjelmarivit Assembler 300 Cobol 110 Pascal 90 PL/I 65 Oliokielet 30 4GL 25 Ohjelmistotuotanto kevät Harri Laine - työmäärän arviointi 11

12 Arviointiohjeita: - tee arvio mahdollisimman myöhään - käytä yksinkertaisia arviointiperusteita - luo kokemusperäinen työmäärämalli - hanki jokin arviointiohjelmisto ja viritä se Työmäärä / projektin kesto Projekteilla optimaalinen kestoaika esim. COCOMO: kaavan mukaan T= 2.5 * MM d, missä d=(0.38,0.35, 0.32) henkilöiden lisääminen lisää kommunikointia => yksittäisen henkilön tuottavuus laskee henkilöiden lisääminen myöhässäolevaan projektiin ei yleensä edistä aikataulun saavuttamista vaan voi jopa lisätä myöhästymistä projektin eri vaiheissa tarvitaan eri määrä henkilöitä nyrkkisääntö työmäärän jakautumisesta suunnittelun, koodauksen ja testauksen kesken: Ohjelmistotuotanto kevät Harri Laine - työmäärän arviointi 12