Tradisjonelle estimeringsmetoder Estimering med use case modeller Måling Hvordan ta beslutninger Estimeringsteknikker Ekspertestimering, estimering ved analogi, estimering ved bruk av algoritmer Kirsten Ribu 03.02.04 HiO - Kirsten Ribu 2005 1 HiO - Kirsten Ribu 2005 2 Man estimerer for å avdekke utviklingskostnadene ved å lage et datasystem Det er ikke nødvendigvis en relasjon mellom utviklingskostnader og den prisen kunden betaler Forretnings-, organisasjonsmessige, økonomiske hensyn og politikk virker inn på prisen HiO - Kirsten Ribu 2005 3 Måling = Å tilordne tall eller symboler til entiteter for å beskrive dem på en meningsfylt måte. Hvorfor måle? Målinger har vært en viktig del av all vitenskapelig aktivitet siden middelalderen Galileo skrev for over 500 år siden: Gjør målbart det som ikke lar seg måle. Tom DeMarco : You can not manage what you do not measure. - NB!->Systemutvikling er fortatt en industri der det måles for lite. HiO - Kirsten Ribu 2005 4 Ingen enkel oppgave: Tidlige estimater baserer seg på ufullstendig informasjon i kravspesifikasjonen Man må kanskje benytte ny teknologi Det kan være ukjente folk i prosjektteamet Estimater kan være selvoppfyllende profetier: Estimatet bestemmer budsjettet produktet justeres for å holde budsjettet Telle antall kodelinjer Ekspertestimering Analogier Algoritmer - kostnadsmnodeller Funksjonspoengmetoden Use case poeng metoden HiO - Kirsten Ribu 2005 5 HiO - Kirsten Ribu 2005 6 1
Størrelsen på systemet = størrelsen på hele prosjektet: Prosjektledelse Analyse, design, koding Testing Systemintegrasjon Størrelsen på prosjektet må måles og oversettes til et tall som representerer tidskostnader (effort) og prosjektets varighet HiO - Kirsten Ribu 2005 7 Kostnadene = kundens budsjett En ikke uvanlig strategi Kan synes uetisk og lite profesjonelt Men det er fordeler: Kunde og leverandør må alltid forhandle om funksjonalitet innenfor visse kostnadsrammer Kostnader er den virkelige begrensningen, ikke kravspesifikasjonen, den kan justeres Et mindre firma/en nykommer i markedet kan bevisst underby andre for å få kontrakten HiO - Kirsten Ribu 2005 8! Det kan være store forskjeller på tidligere og framtidige prosjekter Mange prosjektledere kan ha problemer med å estimere nye prosjekter pga bla: objekt-orientert systemutvikling i motsetning til funksjonsorientert Klient/tjener systemer Bruk av ferdige komponenter i motsetning til å lage alt selv Gjenbruk vs. utvikling fra scratch CASE verktøy med kodegenerering " Mest systematisk framgangsmåte Ikke nødvendigvis nøyaktig En algoritme lages ved å analysere kostnader og attributter på ferdige prosjekter En matematisk formel brukes for å forutsi kostnader basert på estimater av systemets størrelse, antall programmere, og ulike prosess- og produktfaktorer Er basert på empiriske observasjoner HiO - Kirsten Ribu 2005 9 HiO - Kirsten Ribu 2005 10 # $ Defineres som et sett interne attributter: Lengde, funksjonalitet og kompleksitet Kan måles uten å kjøre systemet: Lengde: Systemets fysiske størrelse, kan måles for spesifikasjonen, designet og koden Funksjonalitet måler funksjonene slik brukeren ser dem. Kompleksitet referer til både effektivitet og problemkompleksitet " %& Bottom-up estimering begynner med komponentene på laveste nivå, og det lages et estimat for hver del. Bottom-up tilnærmingen setter sammen estimering av enkelttdeler til høynivå estimater. Top-down estimering begynner med det overordnede produkt Estimater for enkeltdelene regnes ut som deler (prosenter) av estimatet for hele systemet. HiO - Kirsten Ribu 2005 11 HiO - Kirsten Ribu 2005 12 2
' ' Prosjektledelse 20% Analyse: 15% Design: 20% Koding: 25% Testing 15% Systemintegrasjon 5% Totalt 100% Kostnadsoverslag gjøres av eksperter basert på tidligere erfaringer Kan resultere i ganske nøyaktige estimater, men det er helt avhengig av ekspertens erfaringsbakgrunn Expertbaserte teknikker er nyttige når man ikke har empiriske data Fordel: Metoden anvender kunnskap om forskjeller og likheter på tidligere prosjekter (erfaring). Ulempe: Estimatene er ikke bedre enn ekspertens vurderinger. De er ikke målbare, og er preget av enkeltpersoners holdninger og forventninger HiO - Kirsten Ribu 2005 13 HiO - Kirsten Ribu 2005 14 ( Analogi = en mer formell tilnærming til ekspertestimering Estimererne sammenligner det planlagte prosjektet med ett eller flere tidligere prosjekter Forskjeller og likheter brukes til å justere estimatet: Type applikasjon blir identifisert, et tidlig overslag gjøres, og justeres i henhold til prosjekterfaringer. Nøyaktighet er avhengig av at det finnes informasjon om tidligere prosjekter. Psykologi i beslutningsprosessen HiO - Kirsten Ribu 2005 15 HiO - Kirsten Ribu 2005 16 ) Det er umulig å ta en nøytral avgjørelser Avgjørelser er avhengige av sammenhengen (kontekst) Alle avgjørelser beror på måten vi betrakter verden på Kilde: Scott Plous: The Psychology of Judgement and Decision making # ) Persepsjon (oppfattelse) avhenger av motivasjon og kognitive faktorer Spørsmål: Hvilke forventninger har jeg i denne situasjonen? Er jeg innstilt på å se ting på en bestemt måte? Ville jeg sett ting annerledes i dersom jeg hadde andre motiver? Har jeg konferert med andre som ikke deler mine forventninger og motiver? HiO - Kirsten Ribu 2005 17 HiO - Kirsten Ribu 2005 18 3
Kostnader avgjøres av tilgjengelige ressurser, ikke objektiv vurdering Arbeidet har en tendens til å fylle tiden som er til rådighet. Eks: Hvis systemet skal leveres innen 12 måneder og teamet er på 5 personer, blir tidskostnadene estimert til 60 månedsverk. * $ Et lite eksperiment HiO - Kirsten Ribu 2005 19 HiO - Kirsten Ribu 2005 20 ( + 10 65 Eksempel 1: Lykkehjulet lander på 65. Spørsmål: Er prosentandelen av afrikanske land i FN høyere eller lavere enn 65? HiO - Kirsten Ribu 2005 21 Ny situasjon: Ny forsøksperson. Lykkehjulet stopper på 10 Spørsmål: Er prosentandelen av afrikanske land i FN høyere eller lavere enn 10? HiO - Kirsten Ribu 2005 22 ) Eksperiment av Amos Tversky og Daniel Kahneman (1974) Tilfeldig sammensetning av forsøkspersoner Resultat: Nåla stoppet på 65: Gjennomsnittssvar = 45% Nåla stoppet på 10: Gjennomsnittssvar = 25% Ankereffekten er blitt dokumentert i mange sammenhenger Spørsmål: Er sannsynligheten for en atomkrig mellom USA og Sovjetunionen: 1. Høyere eller lavere enn 1 prosent (lav-anker) 2. Høyere eller lavere enn 90% (høy-anker) 3. Ingen anker Resultat: Høyt anker gir høy prosent, lavt anker lav prosent HiO - Kirsten Ribu 2005 23 HiO - Kirsten Ribu 2005 24 4
( Kostnadsmodeller, - Algoritmer som relaterer et bestemt input til et bestemt output f.eks systemstørrelse til antall arbeidstimer Modellene frambringer estimater direkte Det finnes 2 typer modeller: Matematiske ligninger Oppslagstabeller HiO - Kirsten Ribu 2005 25 HiO - Kirsten Ribu 2005 26 Ligninger bruker systemstørrelse som input variabel og arbeidstid (effort) som output. I tillegg brukes ulike justeringsfaktorer = kostnadsdrivere (cost drivers). Disse påvirker produktiviteten Er ofte i form av en skala: (for eksempel som et mål på programmeringserfaring): Svært erfaren, erfaren, middels, lite, novise 1-5. Fordeler: Kan brukes av ikke-eksperter Ulemper: Formelen må oppdateres for å ta høyde for endringer i system utviklingsmetoder. Modeller antar at fremtiden er lik fortiden Gir derfor resultater som passer på gjennomsnittsprosjekter. HiO - Kirsten Ribu 2005 27 HiO - Kirsten Ribu 2005 28. ) Function points oppfunnet i 1979 av Alan Albrecht Metoden måler størrelsen på problemet sett fra brukerens synsvinkel Hovedprinsippet er å fokuserer på kravspesifikasjonen, slik at man får et tidlig estimat over utviklingstid og kostnader. Anvender 5 eksterne attributter som mål: Input til systemet Output fra systemet Forespørsler fra bruker Antall logiske filer eller filer som skal oppdateres av systemet Grensesnitt til andre systemer Passer ikke til sanntidsapplikasjoner eller dagens objektorienterte virkelighet Men lever likevel i beste velgående: IFPUG (International Function Points User Group) www.ifpug.org HiO - Kirsten Ribu 2005 29 HiO - Kirsten Ribu 2005 30 5
MkII (brukt i Storbritannia) nå gammeldags -> COSMIC FFP (full function points) er nå en internasjonal standard: ISO 19761 Use case poeng metoden oppfunnet i 1993 av Gustav Karner Use case poeng metoden (Karners metode) HiO - Kirsten Ribu 2005 31 HiO - Kirsten Ribu 2005 32 ' Gode resultater på ulike prosjekter Use case modellen beskriver funksjonaliteten til systemet Attributter ved use case modellen kan dermed brukes som et mål på størrelsen til systemet som skal lages Samme filosofi som funksjonspoengmetoden Størrelsesmålet brukes som input til et top-down estimat. Use case baserte estimater kan brukes sammen med ekspertvurderinger Eksempler: Prosjekt Ekspertestimat UC-estimat Faktisk tidsbruk 1 7000 10831 10043 2 12600 14965 13933 3 2730 2550 3670 4 2340 2730 2860 5 2080 2100 2740 HiO - Kirsten Ribu 2005 33 HiO - Kirsten Ribu 2005 34 / 0 Identifiser, klassifiser og vekt aktører Identifiser, klassifiser og vekt use case Identifiser og vekt tekniske faktorer Identifiser og vekt omgivelsesfaktorer Konverter poeng til arbeidstimer Kalkuler justerte poeng Framgangsmåte 1. Tell aktører og definer kompleksitet: Enkel aktør: Programgrensesnitt Medium aktør: Interaktivt grensesnitt eller protokolldrevet grensesnitt (f.eks TCP/IP) Kompleks aktør: Grafisk brukergrensesnitt (person) HiO - Kirsten Ribu 2005 35 HiO - Kirsten Ribu 2005 36 6
( $' Aktørtype Beskrivelse Faktor Enkel Program-grensesnitt 1 Use case Enkel Beskrivelse 3 eller færre transaksjoner Faktor 5 Middels Interaktivt grensesnitt 2 Middels 4 til 7 transaksjoner 10 Kompleks Grafisk brukergrensesnitt 3 Kompleks Mer enn 7 transaksjoner 15 HiO - Kirsten Ribu 2005 37 HiO - Kirsten Ribu 2005 38 #$) 3 aktører: 1 eksternt system = enkel 2 personer = komplekse HiO - Kirsten Ribu 2005 39 12$) 034 ) Use Case Aktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Generer spørreskjema Ansatt Ansatt ønsker å opprette et nytt spørreskjema Ansatt har valgt å sette opp et nytt spørreskjema 1.Nytt spørreskjema opprettet eller 2. Ansatt har fått feilmelding 1. Systemet ber om overskrift, innledning og antall spørsmål som spørreskjemaet skal bestå av 2. Ansatt skriver inn nødvendig informasjon 3. Systemet sjekker at alle felt er utfylt 4. Systemet viser et spørreskjema der tekst til spørsmål skal fylles inn. 5. Ansatt skriver inn tekst og evnt. svaralternativ til hvert av spørsmålene 6. Systemet sjekker at riktig antall spørsmål har fått tekst 7. Ansatt ber om at spørreskjema blir lagret 8. Systemet lagrer spørreskjemaet 3a. Alle felt er ikke tilfredsstillende utfylt. 3a1. Systemet informerer ansatt om hvilke felt som ikke er utfylt, og går ikke videre før dette har blitt ordnet. 6a. Alle de angitte spørsmålene har ikke fått en tekst. 6a1. Systemet informerer sekretæren om hvilke spørsmål som ikke har fått tekst, og går ikke videre før dette har blitt ordnet. Svar på spørsmål kan være fritekst eller avkrysningsbokser med alternativer. HiO - Kirsten Ribu 2005 40 Legg sammen Summen av antall use case* kompleksitetsfaktor UUCW (unadjusted use case weights) + Summen av antall aktører*kompleksitetsfaktor UAW (unadjusted actor weights) = UUCP (unadjusted use case points) Antallet use case poeng ganges med en justeringsfaktor = (omgivelsesfaktor) & Opprinnelig: 13 tekniske faktorer Kan antakelig utelates. Dette forskes det på. 8 omgivelsesfaktorer ytre påvirkning som har innflytelse på tidsbruken HiO - Kirsten Ribu 2005 41 HiO - Kirsten Ribu 2005 42 7
/ F1 Erfaring med RUP/ anvendt prosessmodell F2 Team-erfaring med tilsvarende applikasjon F3 Team-erfaring med objekt-orientering/ UML modellering F4 Prosjektleders kompetanse F5 Team-motivasjon F6 Stabile krav/domenekunnskap F7 Ustabile ressurser (deltidsansatte, ikke tilgjengelige ressuser) F8 Ukjent programmeringsspråk/ ny teknologi HiO - Kirsten Ribu 2005 43 " ' 0 Omgivelsesfaktorene påvirker antall timer pr use case poeng Erfaring viser at timer pr use case poeng i større prosjekter varierer mellom 20 og 36 Studentprosjekter: 2-3 timer pr ucp HiO - Kirsten Ribu 2005 44 Eksempel: Regneark Ingen forelesning mandag Torsdag: Mønstre: Design patterns Ukeoppgave: lag et estimat for Zebrasystemet utfra de use casene du har spesifisert. Bruk malen/regnearket. Omgivelsesfaktorene må bestmmes ved gjetning. HiO - Kirsten Ribu 2005 45 HiO - Kirsten Ribu 2005 46 8