Estimering av arbeids- og tids-forbruk ved systemutvikling

Preview:

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 Presentation

Citation preview

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.

Recommended