estimering av arbeids- og tids-forbruk ved systemutvikling
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
Estimering av arbeids- og tids-forbruk ved systemutvikling
In 140 Forelesning Nr 18 bSommerville kap 23
2
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
3
Introduksjon
Prosjektlederen må anslå– Arbeidsmengde– Tidsforbruk– Totalkostnad
Kostnadsestimering samtidig med prosjektplanlegging
Stadig oppdatering av anslag Handling nødvendig ved betydelige avvik
4
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
5
Faktorer som påvirker prissetting
Markedsmuligheter Usikkerhet i kostnadsestimatet Kontraktsbetingelser Usikker kravspesifikasjon Finansiell styrke Konkurransesituasjonen
6
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
Analysis Design Coding Validation
Low-level language
Analysis Design Coding Validation
High-level language
Systemutvikling - tidsforbruk
Analysis Design Coding Testing DocumentationAssembly codeHigh-level language
3 weeks3 weeks
5 weeks5 weeks
8 weeks8 weeks
10 weeks6 weeks
2 weeks2 weeks
Size Effort ProductivityAssembly codeHigh-level language
5000 lines1500 lines
28 weeks20 weeks
714 lines/month300 lines/month
9
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
10
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
11
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
12
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
13
Problemer med kvantitetsmål
Hva med kodeforenkling Hva med kodekvalitet Bør ikke brukes i evaluering av
personale Bare veiledende Krever omtanke
14
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
15
Estimeringsteknikker
Algoritmisk kostnadsestimering Ekspertvurdering Estimering ved analogi Parkinsons lov "Pricing to win"
16
Estimeringsteknikker
Tidlige estimater Usikkerhet ved endret teknologi
– OO– C/S– COTS– Gjenbruk– CASE og programgeneratorer
17
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 ...
18
Usikkerhet ved estimatet
x
2x
4x
0.5x
0.25x
Feasibility Requirements Design Code Delivery
Alternative kostnader
A. Use existing hardware,development system and
development team
C. Memoryupgrade only
Hardware costincrease
B. Processor andmemory upgrade
Hardware cost increaseExperience decrease
D. Moreexperienced staff
F. Staff withhardware experience
E. New developmentsystem
Hardware cost increaseExperience decrease
Alternative kostnader
Option RELY STOR TIME TOOLS LTEX Total effort Software cost Hardwarecost
Total cost
A 1.39 1.06 1.11 0.86 1 63 949393 100000 1049393B 1.39 1 1 1.12 1.22 88 1313550 120000 1402025C 1.39 1 1.11 0.86 1 60 895653 105000 1000653D 1.39 1.06 1.11 0.86 0.84 51 769008 100000 897490E 1.39 1 1 0.72 1.22 56 844425 220000 1044159F 1.39 1 1 1.12 0.84 57 851180 120000 1002706
21
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
22
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.