Vaihtoehtoja Työmäärän arviointi Sami Kollanus TJTA0 Ohjelmistotuotanto 2.1.2007 Arvioidaan niin myöhään kuin mahdollista (projektin jälkeen onnistuu varmasti) Verrataan karkeasti samanlaisiin aiempiin projekteihin Ositetaan projekti ja arvioidaan yksinkertaisesti kustannukset (asiantuntija-arvio) Käytetään empiirisiä kustannusmalleja OHTU 2007 Sami Kollanus 2 Arviointiprosessi Ohjelmiston koon arviointi Ohjelmiston koon laskeminen Projektin ympäristön arviointi Aiempien kokemusten hyödyntäminen Riskien arviointi OHTU 2007 Sami Kollanus Sumea logiikka Arvioidaan suuruusluokka ohjelmiston tyypin mukaan Koodirivien määrä (LOC) Ilman tyhjiä rivejä ja kommentteja Toimintopisteet (function points) Periaatteet ISO-standardoitu Silti monta eri menetelmää! Muutosten arviointi Arvioidaan muutosten määrä ja tyyppi Käyttötapauksiin perustuva arviointi OHTU 2007 Sami Kollanus
Karkea kahtiajako Toimintopiste = toimintopiste???? Asiantuntija-arviot Subjektiivinen arviointi Empiiriset mallit Tilastotiedon hyödyntäminen http://www.fisma.fi/ OHTU 2007 Sami Kollanus 5 OHTU 2007 Sami Kollanus 6 IFPUG-menetelmä International Function Point Users Group (IFPUG) http://www.ifpug.org Kehittää ja ylläpitää standardoitua IFPUGmenetelmää toimintopisteiden laskemiseksi Nykyinen versio.2 IFPUG-menetelmän komponentit 1. Internal logical files (ILF) Loogisia, pysyviä entiteettejä, joita ohjelmisto ylläpitää 2. External interface files (EIF) Loogisia pysyviä entiteettejä, joihin ainoastaan viitataan sovelluksesta, mutta niitä ylläpitää toinen sovellus. External inputs (EI) Loogisia liiketoimintaprosesseja, jotka ylittävät sovelluksen rajan niin, että esim. ylläpitävät ohjelman sisäistä tietoa (esim. käyttäjän toiminnot). External outputs (EO) Datan ulosmeno (raportit, tiedostot, yms.) 5. External queries (EQ) Siis kysellään ulkopuolelta jotain tietoa OHTU 2007 Sami Kollanus 7 OHTU 2007 Sami Kollanus 8
IFPUG-menetelmän komponentit Arvioidaan kompleksisuus EI SOVELLUKSEN RAJAPINTA EIF ILF EIF Low 7 5 Average 10 7 High 15 10 EO EQ ILF EI EO EQ 5 6 7 6 OHTU 2007 Sami Kollanus 9 OHTU 2007 Sami Kollanus 10 Esimerkki: vaatimukset Esimerkki: vaatimukset 1. Ohjelmiston on talletettava ja ylläpidettävä seuraavia työntekijätietoja: nimi, numero, virka-asema, katuosoite, kaupunki, osavaltio, postinumero, syntymäaika, puhelinnumero, toimipiste ja viimeinen tietojen päivitysaika. 2. Ohjelmiston täytyy pystyä lisäämään uusia työntekijöitä, päivittää tietoja, poistaa tietoja ja yhdistää useampaan kertaan rekisteröidyt työntekijät.. Ohjelmiston täytyy tuottaa aikataulutettuna viikkoraportti, joka sisältää listan niistä työntekijöistä (nimi ja numero), joiden tiedot ovat muuttuneet viimeisen seitsemän vuorokauden aikana.. Käyttäjän täytyy pystyä katsomaan ja selaamaan kaikkia työntekijätietoja. 5. Käyttäjäturvaan liittyvä tieto (käyttäjätunnus ja salasana) on erillisen ohjelman vastuulla, jota käytetään sisään kirjauduttaessa käyttäjän tunnistamiseen. 6. Mihinkään muuhun ohjelmiston ulkopuoliseen tietoon ei ole viittauksia 7. Syntymäaika salataan riittävän monimutkaisella algoritmilla, jotta sitä ei voida suoraan lukea käyttäjätiedoista. 8. Ohjelmiston täytyy suoriutua tiedon ylläpidosta alle sekunnin vasteajassa suurimman kuormituksen aikaan kello 8-17 (Itäisen USA:n aikavyöhyke, GMT -5) 9. Ohjelmiston täytyy käyttää ohjelmointikieliä, jotka tukevat järjestelmän avoimuutta ja ovat yhteensopivia Oraclen tietokantojen kanssa. OHTU 2007 Sami Kollanus 11 OHTU 2007 Sami Kollanus 12
Esimerkkilaskelma Esimerkkilaskelma Oletetaan kaikissa kohdissa kompleksisuus alhaiseksi: Internal logical file: Työntekijöiden tiedot 1 IFL = 7 unadjusted FP External interface file: Käyttäjätietoa hallitseva järjestelmä 1 EIF = 5 unadjusted fp External input processes: käyttäjän lisäys, tietojen päivitys, työntekijän poisto ja duplikaattien yhdistäminen EI = * = 12 unadjusted fp External output processes: Näkymä käyttäjätietoihin, sisältää syntymäajan kryptauksen. 1 EO = unadjusted fp OHTU 2007 Sami Kollanus 1 OHTU 2007 Sami Kollanus 1 Esimerkkilaskelma External query process: Viikkoraportti ja sisäänkirjautumiskysely 2 EQ = 2* = 6 unadjusted fp Lopputulos: 7+5+12++6 = unadjusted fp Tuotteen kompleksisuustekijät 1. Does the system require reliable back up and recovery? 2. Are data communication required. Are there distributed processing functions?. Is performance critical 5. Will the system run in an existing, heavily utilized operating system 6. Does the system require on-line entry? 7. Does the on-line data entry require the input transaction to be built over multiple screen or operations? OHTU 2007 Sami Kollanus 15 OHTU 2007 Sami Kollanus 16
Tuotteen kompleksisuustekijät Toimintopisteiden laskeminen 8. Are the master files updated on-line? 9. Are the inputs, outputs, files, or inquiries complex? 10. Is the internal processing complex? 11.Is the code designed to be reusable 12.Are the conversion and installation included in the design? 1.Is the system designed for multiple installations in different organizations? 1.Is the application designed to facilitate change and ease by the user? Arvioidaan jokaisen kompleksisuustekijän merkittävyys asteikolla 0-5 (5 = erittäin merkittävä) Lasketaan toimintopisteet kaavalla FP = UFP * [0,65 + 0,01* (F i )] (F i ) on kompleksisuustekijöiden summa OHTU 2007 Sami Kollanus 17 OHTU 2007 Sami Kollanus 18 Jatkoa esimerkkiin ja jatkuu Kompleksisuustekijä Does the system require reliable back up and recovery? Are data communication required? Are there distributed processing functions? Is performance critical? Will the system run in an existing, heavily utilized operating system? Does the system require on-line entry? Does the on-line data entry require the input transaction to be built over multiple screen or operations? Are the master files updated on-line? Are the inputs, outputs, files, or inquiries complex? Is the internal processing complex? Is the code designed to be reusable? Are the conversion and installation included in the design? Is the system designed for multiple installations in different organizations? Is the application designed to facilitate change and ease by the user? Yhteensä Merkittävyys 2 1 0 1 0 5 1 2 0 29 Esimerkin laskelmassa saatiin tulokseksi ufp Kompleksisuustekijöiden painokertoimeksi saatiin 29 Sijoitetaan kaavaan: ufp * (0,65 + 0,01 * 29) = 2 fp OHTU 2007 Sami Kollanus 19 OHTU 2007 Sami Kollanus 20
Työmäärän arviointi - empiirisen malli Laskentakaava on yleisesti muotoa: Työmäärä = A * koko B * M A = vakio, joka riippuu organisaatiosta ja kehitellävän ohjelmiston tyypistä B = eksponentti korjaa laajojen projektien erityistä kuormitusta M = kuvaa projektikohtaisia ominaisuuksia COCOMO COnstructive COst MOdel Varmasti tunnetuin estimointimalli Barry Boehm 1981: Software Engineering Economics Taustalla laaja tutkimusaineisto ohjelmistojen kustannuksiin vaikuttavista tekijöistä COCOMO II vuonna 1997 Sommerville 2001, 521. OHTU 2007 Sami Kollanus 21 OHTU 2007 Sami Kollanus 22 COCOMO:n peruskaavat Yksinkertainen projekti, pieni tiimi: Data base size Schedule constraint Turnaraund time Virtual machine experience 1,2 1,2 1,2 1, Software productivity range PM = 2, * (KDSI) 1,05 * M Kompleksisempi projekti, uusi sovellusalue Software tools Virtual machine volatility Modern programming practices Storage constraint 1,9 1,9 1,51 1,56 PM =,0 * (KDSI) 1,12 * M Application experience 1,57 Sulautetut järjestelmät: PM =,6 * (KDSI) 1,20 * M Timing constraint Required reliability Product complexity 1,66 1,87 2,6 Personel / team capacity,18 0 0,5 1 1,5 2 2,5,5,5 OHTU 2007 Sami Kollanus 2 OHTU 2007 Sami Kollanus 2
COCOMO:n kustannustekijät Kustannustekijöiden vaikutus Tuotetekijät: luotettavuusvaatimus, tietokannan koko, kompleksisuus Laitetekijät: Suoritusaikarajoitus, talletuskapasiteetti, virtuaalikoneen epävakaus, vasteaikarajoite Henkilötekijät: kokemus sovellusalueesta, virtuaalikoneesta ja ohjelmointikielestä sekä kyvykkyys analyysiin ja ohjelmointiin Projektitekijät: ohjelmointikäytänteet, työkalut, aikataulurajoite Esimerkki: luotettavuusvaatimuksen määritys Arvio vaatimuksesta Very low Low Nominal High Very high Vaatimukset + suunnitelmat 0,80 0,90 1,10 1,0 Tarkka suunnittelu 0,80 0,90 1,10 1,0 Koodaus + yks. testaus 0,80 0,90 1,10 1,0 Kokonaiskerroin Itegraatiotestaus 0,60 0,80 1,0 1,70 0,75 0,88 1,15 1,0 OHTU 2007 Sami Kollanus 25 OHTU 2007 Sami Kollanus 26 Kustannustekjöiden arviointi Arvioidaan erikseen 2, * (KDSI) 1,05 * M M = m 1 * m 2 * m n Kuinka kauan kestää Tarvittava työmäärä Kuinka monta ihmistä osallistuu Riskit Esim. M = 0,8 * 0,7 *1, * 1 * 1,2 = 0,9 OHTU 2007 Sami Kollanus 27 OHTU 2007 Sami Kollanus 28
Estimointi Suomessa Finnish Software Measurement Association (FiSMA) www.fisma.fi Miksi kummassa tällaista estimointia kannattaa tehdä? Estimoinnin tarkkuus (???) Hyvillä menetelmillä ei olla riippuvaisia tietyistä ihmisistä Ohjelmiston koon arvioinnista on hyötyä erilaisia metriikoita seurattaessa Käytännössä esim. hinnoittelu /fp Kustannustekijöitä seuraamalla voidaan kehittää prosessia Vaatimukset on pakko tehdä kunnolla OHTU 2007 Sami Kollanus 29 OHTU 2007 Sami Kollanus 0 Erikseen huomattavia asioita ainakin: Uudelleenkäyttö Alihankinta Ylläpito Ketterät menetelmät??? Erityisalueet, kuten www-pohjaiset sovellukset Syitä estimoinnin virheisiin Epärealistinen ylioptimismi Toistuvat muutokset Käytetään aikaa muuhun kuin suunniteltuun työhön Aliarvioidaan sovelluksen kompleksisuus Käyttäjien toistuvat muutospyynnöt Käyttäjät eivät ymmärrä omia vaatimuksiaan OHTU 2007 Sami Kollanus 1 Jørgensen & Moløkken-Østwold 200. Reasons for Software Effort Estimation Error: Impact of Respondent Role, Information Collection Approach, and Data Analysis Method. IEEE Transactions on Software Engineering 0(12), 99-1007. OHTU 2007 Sami Kollanus 2
syitä estimoinnin virheisiin syitä estimoinnin virheisiin Huomioimatta jätetyt tehtävät Käyttäjien näkökulman puute Epätäydelliset vaatimukset ja spesifikaatiot Muuttuvat vaatimukset Vaatimusmuutokset Tiimin kokemus, vaihtuvuus Työkalujen käyttö Joku muu kuin tekijä itse arvioi Johto ei tarkista estimaatteja Ei formaalia prosessia kustannusten seurantaan Virhe kasvaa suhteessa ohjelman kokoon Jørgensen & Moløkken-Østwold 200. Reasons for Software Effort Estimation Error: Impact of Respondent Role, Information Collection Approach, and Data Analysis Method. IEEE Transactions on Software Engineering 0(12), 99-1007. OHTU 2007 Sami Kollanus Jørgensen & Moløkken-Østwold 200. Reasons for Software Effort Estimation Error: Impact of Respondent Role, Information Collection Approach, and Data Analysis Method. IEEE Transactions on Software Engineering 0(12), 99-1007. OHTU 2007 Sami Kollanus Yhteenvetoa virheiden syistä Huomattava osa estimoinnin virheiden syistä on estimoinnin ulottumattomissa Vaatimusmuutosten hallinta on selkeimmin esille tuleva asia Jørgensen & Moløkken-Østwold 200. Reasons for Software Effort Estimation Error: Impact of Respondent Role, Information Collection Approach, and Data Analysis Method. IEEE Transactions on Software Engineering 0(12), 99-1007. OHTU 2007 Sami Kollanus 5