Estimering av arbeids- og tids-forbruk ved systemutvikling In 140 Forelesning Nr 18 b Sommerville kap 23

Mål Forstå grunnleggende prinsipper og sammenhenger for kostnads- og prisestimering Kjenne til tre måltall for vurdering av programvareproduktivitet Innse at forskjellige beregningsmåter er nødvendige

Introduksjon Prosjektlederen må anslå Arbeidsmengde Tidsforbruk Totalkostnad Kostnadsestimering samtidig med prosjektplanlegging Stadig oppdatering av anslag Handling nødvendig ved betydelige avvik

Kostnadsberegning og prissetting Tre kostnadskomponenter Maskin- og programvarekostnader Reise og treningskostnader Arbeidskostnader Den siste er normalt den største Overhead typisk 100% Prissetting Ikke det samme som kostnad Mange faktorer spiller inn

Faktorer som påvirker prissetting Markedsmuligheter Usikkerhet i kostnadsestimatet Kontraktsbetingelser Usikker kravspesifikasjon Finansiell styrke Konkurransesituasjonen

Produktivitet Programvareprodukter er forskjellig Vanskelig å sammenligne tidsforbruk Estimering er nødvendig To måltallstyper Størrelsesrelatert (linjer, sider, objektkode) Funksjonalitetsrelatert (funksjons- eller objektpoeng) Svært vanlig: Linjer kode per måned Stammer fra korttiden Tellingsmåter Kan gi meningsløse resultater

Høy- og lavnivåspråk

Systemutvikling - tidsforbruk

Funksjonspoengtelling (Albrecth 1979) Språkuavhengig Funksjonspoeng per personmåned Best egnet for databehandlingssystemer Det tildeles poeng med ulik vekt (3-15) for Inn og utdata Brukeraksjoner Eksterne grensesnitt Filer som brukes UFC = Summen av antall elementer x vekt Korreksjonsfaktorer for Distribuert, Gjenbruk, Ytelseskrav Ikke objektivt mål

Objektpoengtelling Egnet for 4. generasjonsspråk Ingen sammenheng med objektorientering Veid estimering av Antall skjermbilder (1-3 op avh av kompleksitet) Antall rapporter (2-8 op avh av kompleksitet) Antall 3. GL støttemoduler (10 op) Lettere å estimere enn funksjonspoeng. Tillater tidlig estimering

Funksjons- og objektpoeng Tillater tidlig estimering Kan også brukes for estimering av kodestørrelse = AVC x Sum av FP AVC Assembly 200-300 LOC per FP 4. GL 2-40 LOC per FP

Faktorer som påvirker utviklerens produktivitet Individuelle ferdigheter viktigst En forskjell på 10x Små og store lag Ellers Erfaring fra anvendelsesområdet Prosesskvaliteten Prosjektstørrelsen Støtte fra teknologi Arbeidsmiljø Varierer sterkt med hva som lages 30 LOC/mnd – 900 LOC/mnd 4-50 OP/mnd

Problemer med kvantitetsmål Hva med kodeforenkling Hva med kodekvalitet Bør ikke brukes i evaluering av personale Bare veiledende Krever omtanke

Estimeringsteknikker Ikke enkelt å estimere Vanskelig å vurdere estimeringsnøyaktighet Selvoppfyllende estimater Prosjektledere og estimering Arbeidsmengde: Bra Kodestørrelse: Svakere Bottom-up vs Top-Down Store og små systemer

Estimeringsteknikker Algoritmisk kostnadsestimering Ekspertvurdering Estimering ved analogi Parkinsons lov "Pricing to win"

Estimeringsteknikker Tidlige estimater Usikkerhet ved endret teknologi OO C/S COTS Gjenbruk CASE og programgeneratorer

Algoritmisk kostmodellering Systematisk Arbeidsmengde = A x StørrelseB x M A konstant for organisasjon og produkttype Størrelse LOC B kompleksitetskorrigering (1-1,5) M avhenger av Språk, Gjenbruk, Prosess ... Kalibrering Flere estimater Worst Case, Best Case ...

Usikkerhet ved estimatet

Alternative kostnader

Alternative kostnader

Prosjektvarighet og -bemanning Ingen enkel sammenheng Ved flere deltakere: Mer kommunikasjon Flere grensesnitt å definere Nominell varighet: TDEV=3xPM(0,33+0,2*(B-1,01)) NB! Antall medarbeidere er ikke med i formelen Kan akselereres Antall deltakere på prosjektet Rask oppbygging korrelerer med forsinkelser

Hovedpoeng Produktivitet påvirkes av dyktighet, erfaring, prosess, størrelse, CASE og arbeidsmiljø Ulike metoder for kostnadsestimering Prissetting ofte for å få kontrakten – funksjonaliteten justeres til prisen stemmer Algoritmisk kostnadsmodellering bygger på egenskaper ved det ferdige produktet Algoritmiske kostnadsmodeller og veivalg Tidsforbruket er ikke direkte avhengig av antall deltakere – forsinkelser blir ofte verre ved å tildele flere personer.