Estimeringsmetoder.

1. Estimeringsmetoder. Tradisjonelle estimeringsmetoder Estimering med use case modeller Kirsten Ribu 03.02.04 HiO - Kirsten Ribu 2005

2. I dag • Måling • Hvordan ta beslutninger • Estimeringsteknikker • Ekspertestimering, estimering ved analogi, estimering ved bruk av algoritmer HiO - Kirsten Ribu 2005

3. Kostnader og prisfastsettelse • 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

4. Estimering = måling • 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’. • TomDeMarco : “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

5. Kostnadsestimering • 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 selvoppfyllendeprofetier: • Estimatet bestemmer budsjettet • produktet justeres for å holde budsjettet HiO - Kirsten Ribu 2005

6. Ulike estimeringsmetoder • Telle antall kodelinjer • Ekspertestimering • Analogier • Algoritmer - kostnadsmnodeller • Funksjonspoengmetoden • Use case poeng metoden HiO - Kirsten Ribu 2005

7. Måling av programvare • 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 prosjektetsvarighet HiO - Kirsten Ribu 2005

8. ’Pricing-to-win’ • 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

9. Nye systemutviklingsmetoder/ teknologi gir nye utfordringer • 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 HiO - Kirsten Ribu 2005

10. Bruk av algoritmer • 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

11. Størrelse på systemet • 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 HiO - Kirsten Ribu 2005

12. Bottom-up vs. Top-down • 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

13. Prosentvis bottom-up estimering basert på empiri • Prosjektledelse 20% • Analyse: 15% • Design: 20% • Koding: 25% • Testing 15% • Systemintegrasjon 5% • Totalt 100% HiO - Kirsten Ribu 2005

14. Ekspert-estimering • Kostnadsoverslag gjøres av ’eksperter’ basert på tidligere erfaringer • Kan resultere i ganske nøyaktige estimater, men det er helt avhengig av ekspertens erfaringsbakgrunn • Expertbaserteteknikker 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

15. Analogi • 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. HiO - Kirsten Ribu 2005

16. Psykologi i beslutningsprosessen HiO - Kirsten Ribu 2005

17. Persepsjon og kontekst • 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 HiO - Kirsten Ribu 2005

18. Selektiv persepsjon • 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

19. Parkinsons lov • Kostnader avgjøres av tilgjengeligeressurser, 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 60månedsverk. HiO - Kirsten Ribu 2005

20. Hva kan forkludre ’nøytrale’ vurderinger • Et lite eksperiment HiO - Kirsten Ribu 2005

21. ’Anker’-effekten • Eksempel 1: Lykkehjulet lander på 65. • Spørsmål: Er prosentandelen av afrikanske land i FN høyere eller lavere enn 65? 65 HiO - Kirsten Ribu 2005

22. Eksempel 2 • 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? 10 HiO - Kirsten Ribu 2005

23. Konklusjon • 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 HiO - Kirsten Ribu 2005

24. Eksempel • Spørsmål: Er sannsynligheten for en atomkrig mellom USA og Sovjetunionen: • Høyere eller lavere enn 1 prosent (lav-anker) • Høyere eller lavere enn 90% (høy-anker) • Ingen anker • Resultat: Høyt anker gir høy prosent, lavt anker lav prosent HiO - Kirsten Ribu 2005

25. Algoritmer Kostnadsmodeller HiO - Kirsten Ribu 2005

26. Kostmodeller (cost models) • 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

27. Kostnadsdrivere • 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 HiO - Kirsten Ribu 2005

28. Fordeler og ulemper • 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

29. Funksjonspoengmetoden • 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 HiO - Kirsten Ribu 2005

30. Utdatert metode • 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

31. Nyere varianter • 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 HiO - Kirsten Ribu 2005

32. Estimering med use cases Use case poeng metoden (Karners metode) HiO - Kirsten Ribu 2005

33. Estimering basert på use cases • 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 HiO - Kirsten Ribu 2005

34. Gode resultater på ulike prosjekter 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

35. Oversikt over metoden: • 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 HiO - Kirsten Ribu 2005

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

37. Use case poeng metodenAktørbeskrivelse HiO - Kirsten Ribu 2005

38. Use case kompleksitet HiO - Kirsten Ribu 2005

39. Spørreskjemageneratoren 3 aktører: 1 eksternt system = enkel 2 personer = komplekse HiO - Kirsten Ribu 2005

40. UC ’Generer spørreskjema’: >8 transaksjoner = komplekst HiO - Kirsten Ribu 2005

41. 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) HiO - Kirsten Ribu 2005

42. Tekniske faktorer og omgivelsefaktorer • 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

43. Omgivelsesfaktorer HiO - Kirsten Ribu 2005

44. Beregn timeforbruk per use case poeng: • 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

45. Use case poeng totalt Eksempel: Regneark HiO - Kirsten Ribu 2005

46. Neste gang • 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