1 / 34

Estimeringsmetoder.

Estimeringsmetoder. Kirsten Ribu. I dag. Estimeringsteknikker Ekspertestimering, estimering ved analogi, estimering ved bruk av algoritmer Prosjektplanen med akrivitetetsdiagram. Kostnader og prisfastsettelse. Man estimerer for å avdekke utviklingskostnadene ved å lage et datasystem

Download Presentation

Estimeringsmetoder.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related