Estimeringsmetoder.

1. Estimeringsmetoder. Kirsten Ribu HiO - Kirsten Ribu 2005

2. I dag • Estimeringsteknikker • Ekspertestimering, estimering ved analogi, estimering ved bruk av algoritmer • Prosjektplanen med akrivitetetsdiagram 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. Kostnadsestimering • Ingen enkel oppgave: • Tidlige estimater baserer seg på ufullstendig informasjon i kravspesifikasjonen • Man må kanskje benytte ny teknologi • Det kan være uerfarne folk i prosjektteamet • Estimater kan være selvoppfyllendeprofetier: Estimatet bestemmer budsjettet - produktet justeres for å holde budsjettet HiO - Kirsten Ribu 2005

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

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

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

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

9. Bruk av algoritmer • Mest systematisk framgangsmåte • Ikke nødvendigvis nøyaktig • En algoritme lages ved å analyserekostnader 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

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

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

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

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

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

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

16. Algoritmer Kostnadsmodeller HiO - Kirsten Ribu 2005

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

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

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

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

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

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

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

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

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

26. Use case kompleksitet HiO - Kirsten Ribu 2005

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

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

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

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

31. Omgivelsesfaktorer HiO - Kirsten Ribu 2005

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

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

34. Neste gang • Testing (Validering og verifisering) kvalitetssikring • Gurholt & Hasle kapittel 14 • Ukeoppgave: lag et estimat for systemet ditt utfra de use casene du har spesifisert. • Bruk malen/regnearket. Omgivelsesfaktorene må bestemmes ved gjetning. HiO - Kirsten Ribu 2005