f r projektet besluttes n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Før projektet besluttes PowerPoint Presentation
Download Presentation
Før projektet besluttes

Loading in 2 Seconds...

play fullscreen
1 / 67

Før projektet besluttes - PowerPoint PPT Presentation


  • 140 Views
  • Uploaded on

Før projektet besluttes. Efter denne lektion skal du:. Kunne foretage estimering af et mindre projekt hvor der er mange erfaringsdata til rådighed Kende til en række forskellige estimeringsteknikker, kunne forklare deres fordele og ulemper Kunne bruge historiske data til at udlede et estimat

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Før projektet besluttes' - philena


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
efter denne lektion skal du
Efter denne lektion skal du:
  • Kunne foretage estimering af et mindre projekt hvor der er mange erfaringsdata til rådighed
  • Kende til en række forskellige estimeringsteknikker, kunne forklare deres fordele og ulemper
  • Kunne bruge historiske data til at udlede et estimat
  • Kende faren ved urealistiske og ”politiske” estimater
denne lektion

FØR projektet besluttes

Planlægn. & spec. arbejdet

Udfø-relse

Denne lektion

Aflevering og eval.

Drift & vedl.hold

X

  • Project Scope Management
  • Project Quality Management
  • Project Human Resource Management
  • Project Time Management
  • Project Cost Management

6. Project Communication Management

7. Project Risk Management

8. Project Procurement Management

9. Project Integration Management

X

X

Findes også i PMI

X

slide4

Benefit

Ana-

lyse

Overskud

Driftslevetid

Udvikling

Break Even

Pay Back Periode

Cost

CBA = Cost/Benefit analyse

Kvantitativ opgørelse baseret på omkostninger afledt af projektets gennemførelse og indtægter afledt af produktets implementering.

cost analyse
Udviklingen af det nye system / service

Løn og overhead

Konsulenter

Uddannelse

Computer tid og –værktøjer

Rekruttering af nye kompetencer

Kontorplads og –udstyr

Rejseomkostninger

Igangsætning af det nye system / service

Brugeruddannelse

Database konvertering

Leverandør installation

Myndighedsgodkendelse

Paralleldrift

Installationsteamet

Costs

Benefits

Cost analyse

Driftsomkostninger

  • Hardware, netværk m.m.
  • Software
  • Produktionsfolk
  • Marketing og salgsomkostninger
  • Vedligeholdelse
  • Faciliteter

Finansielle omkostninger

  • Rente af lån / eksisterende midler
  • Offeromkostninger
benefit analyse
Forøget salg / profit

Forøget antal transaktioner

Bedre dækningsbidrag

Fastholde kunder  Mistede kunder 

Bedre kvalitet

Bedre og opdateret information

Højere pålidelighed – færre fejl

Højere sikkerhed

Firewall, virusbeskyttelse etc.

Kundetilfredshed

Opfattelse af højere værdi

Bedre åbningstider 7 tilgængelighed

Hurtigere responstid

Strategiske fordele

“First mover advantage”

Konkurrencemæssig fordel

Strategisk fleksibilitet

Formindskede omkostninger

Færre ansatte

Undgå nyansættelser

Erstatte metoder/værktøjer/systemer

Lavere driftsomkostninger

Costs

Benefits

Benefit analyse
slide7

Hvornår skal man lave CBA?

Projektet Produktets levetid

Skal

projektet

fortsætte ?

Hvad kom

projektet

til at koste ?

Skal

projektet

startes ?

Hvor god var

investeringen

i forhold til

forventet ?

Glemmes ofte!

slide8

Styring af projektets Scope

Benefit hænger ofte tæt sammen med “Scope” for projektet.

Scope = Det indhold og omfang som det nye system

(eller den nye service) skal have

Der indgår 5 processer i styringen af Scope:

  • Initiering
  • Planlægning af Scope
  • Fastlæggelse af Scope
  • Formel accept af Scope
  • Opfølgning på Scope
slide9

1. Initiering af projektet

  • Fra den gode idé til etableringen af et projekt
  • Cost-Benefit analysen er ofte et vigtigt redskab til at beslutte om et projekt skal sættes i gang
  • Nogen kalder det en “Business case”
  • Der udpeges en projektleder
  • Der afsættes en pose penge
slide10

2. Planlægning af Scope

  • Der laves en projektbeskrivelse omfattende projektets berettigelse (benefits igen), dvs. det forretningsbehov som projektet bliver iværksat for at dække
  • Der laves en produktbeskrivelse – måske i form af en overordnet kravspecifikation
  • Projektets leverancer fastlægges
  • De mål som skal nås defineres – helst som noget målbart “har vi nået det, er projektet færdigt”
slide11

Produkt

ALFA

BRAVO

CHARLIE

DELTA

EKKO

3. Fastlæggelse af Scope

Og så kommer alle vores værktøjer i brug!

  • Produktbeskrivelse kan bruges til at lave nedbrydning i arbejdspakker (Work Breakdown Structure)
  • Nedbrydningen i arbejdspakker kan bruges som udgangspunkt for estimering – og med successiv kalkulation får man hjælp til at fokusere sit arbejde
slide12

4. Formel accept af Scope

  • Når Scope er beskrevet, nedbrydning, estimering og planlægning foretaget, så er der ofte et formelt GO eller NO GO

5. Opfølgning på Scope

  • Lige som de andre ting i projektet skal der følges op på om omfang og indhold ændrer sig.
  • Det gør man bedst ved at holde god kontakt til sine interessenter hele tiden
skab overblik work breakdown structure wbs

Produkt

Opdeling i

arbejdspakker

efter:

  • Proces
  • Produkt
  • Begge dele

ALFA

BRAVO

CHARLIE

DELTA

EKKO

Skab overblik - Work Breakdown Structure (WBS)
gode arbejdspakker kendetegnes ved
Gode arbejdspakker kendetegnes ved:
  • De er uafhængige af, eller har klart definerede koblinger til, omverdenen og andre arbejdspakker
  • De er klart definerede med hensyn til omfang, ansvar og autoritet
  • De er målelige
  • Deres ressourcebehov, omfang, varighed og omkostninger kan estimeres
  • De resulterer i et ”produkt” (leverance)
to typer metoder og teknikker til estimering
To typer metoder og teknikker til estimering

Basalt findes to typer metoder og teknikker:

  • Erfaringsbaserede, som f.eks. analogier og eksperter, anvendelse af historiske data, samt successiv kalkulation og DELFI-teknikken
  • Modelbaserede (parameter-baserede), som f.eks. COCOMO 1.0 og 2.0, Use Case point og Function Points.
analogier og eksperter
Analogier og eksperter
  • Denne aktivitet ligner en aktivitet som vi tidligere har brugt X timer på i projekt Y
  • Denne type aktivitet er N.N. ekspert i. Vi beder ham give et estimat
brug historiske data
Brug historiske data
  • Vores database viser, at aktiviteter af denne type tager X timer
  • Eksempel: At lægge 1 m3 fliser på en terrasse tager 2 timer.
  • Vi har Y aktiviteter af typen
  • Eksempel: At lægge 50 m3 vil tage 100 timer
successiv kalkulation id en
Successiv kalkulation - Idéen

“Enhver forkalkulation beskæftiger sig … med fremtidige forhold og indeholder derfor nødvendigvis en række skøn, der alle er behæftet med en vis usikkerhed”

“Et gammel grundprincip ved kalkulationsarbejde er, at man tilstræber at opdele kalkulationen i et mindre antal hovedposter og herefter opdele de mest betydningsfulde af disse i delposter, som så igen - afhængig af den ønskede nøjagtighed - opdeles yderligere.”

“Ved … at anvende nogle statistiske grundbegreber er det lykkedes at opstille en metode, der synes at kunne gøre meget kalkulationsarbejde såvel mere effektivt som hurtigere.”

Kilde: Steen Lichtenberg (1971). Rapport over successiv kalkulation. DtH. Citeret fra forordet.

slide20
Vo = mest optimistiske skøn (mindsteværdi)Vs = mest sandsynlige værdiVp = mest pessimistiske værdi (størsteværdi)Vm = middelværdi
successiv kalkulation
Successiv kalkulation

For en Erlang funktion med en k-værdi på 10 (hvor “k” er et udtryk for fordelingsfunktionens skævhed) beregnes middelværdien som:

Vm = (Vo + 2,95*Vs + Vp) / 4,95

Og standardafvigelsen “S” som:

S2 = (Vp - Vo)2 / 21,66

K = 10 er valgt “… fordi den må anses for at være mest repræsentativ. For andre k-værdier er ovennævnte udtryk for middelværdien behæftet med en en fejl, der dog for for de mere hyppigt forekommende k-værdier (K = 5 til 15) kun når op til få promille.”Citat: Steen Lichtenberg (1971, side 20)

successiv kalkulation formler
Successiv kalkulation - formler

Som tilnærmede formler kan vi bruge:

Vm = (Vo + 3*Vs + Vp) / 5

S = (Vp - Vo)/ 5

Usikkerheden kan beregnes således at:

68% er omfattet. Formel: (Vm - S) - (Vm + S)

95% er omfattet. Formel: (Vm - 2S) - (Vm + 2S)

99% er omfattet. Formel: (Vm - 3S) - (Vm + 3S)

opgave i successiv kalkulation
Opgave i Successiv kalkulation

For et nyt skærmbillede A i et program har du skønnet:

Vo (mindsteværdi) = 70 timer

Vs (mest sandsynlig) = 80 timer

Vp (størsteværdi) = 110 timer

Beregn Vm, S samt øvre og nedre værdi i 95%-intervallet.

Anvend de tilnærmede formler:

Vm = (Vo + 3*Vs + Vp) / 5

S = (Vp - Vo)/ 5

95% interval: (Vm - 2S) - (Vm + 2S)

forts t nedbrydningen indtil
Fortsæt nedbrydningen indtil ...

Tommelfingerregel fra Lichtenberg (1971:side 14):

“Den eller de poster der har den største varians … opdeles i et antal delposter … Således fortsættes indtil man enten har nået en tilfredsstillende nøjagtighed eller møder usikkerheder, der ikke kan nedbringes ved opdeling eller på anden vis.”

Tommelfingerregel fra Peter Willkan, A.P. Møller, på en Workshop om estimering Dansk Dataforening:

Bliv ved med at nedbryde aktiviteterne indtil standardafvigelsen er mindre end en tyvendedel af middelværdien: S < Vm*20

Erfaringen viser dog, at det ofte er urealistisk at nå ned på så små usikkerheder som en tyvendedel.

slide29

DELFI-teknikken

  • Hvert medlem af en gruppe giver et estimat
  • De der ligger i nederste og øverste kvartil fortæller resten af gruppen hvorfor deres estimat blev som det blev
  • Gruppen estimerer igen, nu under hensyn-tagen til de argumenter man lige har hørt
  • Kan fortsættes 2, 3, 4 eller flere gange efter behov
slide30

DELFI-teknikken – et eksempel

1. gang

2. gang

3. gang

andre simple teknikker
Andre simple teknikker
  • Oppefra-ned. Først estimeres helheden - systemet set som en sort kasse - siden brydes ned vha. procenttal baseret på erfaring. Teknikken kan f.eks. bruges til et første overslag meget tidligt.
  • Nedefra-op. Selve programmet nedbrydes i detaljer - f.eks. i delsystemer og moduler. Hver enkelt lille del estimeres i timer. Summen af timer ganges op til en sum for helheden vha. procenttal baseret på erfaring.
  • Nedefra-op alternativ…. Hver enkelt lille del estimeres i antal linier. Summen af linier bruges som input til at inddrage historiske data eller til en estimeringsmodel.
del 2 modelbaserede teknikker
Del 2Modelbaserede teknikker
  • COCOMO
  • Use Case point
  • Fnction points
supplerende litteratur cocomo function points
Supplerende litteratur - COCOMO & Function Points
  • Hughes & Cotterell, ”Software Project management”, 4th edition, 2006, Chapter 5 – Software effort estimation
cocomo modellen
COCOMO-modellen

Organisk udvikling

Relativ lille gruppe udvikler software af en velkendt type til in-house brug. Hovedparten af gruppen har erfaring med tilsvarende systemer i organisationen.

PM = 2,4 (KDSI)1,05 MU = 2,5 (PM)0,38

PM = PersonMåneder KDSI = Tusind linier kildetekst

MU = Måneder til udvikling

cocomo eksempel
COCOMO-eksempel

Vi skal lave et program på 10.000 linier kildetekst. Udviklingstypen er organisk.

PM = 2,4 (10)1,05 = 27 personmåneder

MU = 2,5 (27)0,38 = 8,7 måneder til udv.

Men hvordan kommer vi fra kravspec. til antallet af linier kildetekst ?

cocomo embedded
COCOMO Embedded

Embedded (Indlejret) udvikling

Projektet kan omfatte ny teknologi, algoritmer vi ikke kender godt, eller en ny innovativ udviklingsmetode. mest karakteristisk er, at projektet er underlagt mange bindinger (“tight constraints”)

PM = 3,6 (KDSI)1,20 MU = 2,5 (PM)0,32

cocomo semi detached
COCOMO Semi-detached

Semi-detached udvikling

Mellemting mellem organisk og embedded

PM = 3,0 (KDSI)1,12 MU = 2,5 (PM)0,35

Eksempel med 10.000 linier kode (10 KDSI):

PM = 3,0 (10)1,12 = 40 personmåneder

MU = 2,5 (40)0,35 = 9,1 måneder til udvikling

Gennemsnitlig bemanding 40 / 9,1 = 4,4 mand

udvidet cocomo
Udvidet COCOMO

PM = 3,0 (KDSI)1,12 * f1 * f2 * f3 … f14 * f15

SOFTWARE FAKTORER

f1 = Pålidelighed krævet af systemet (RELY)

f2 = Størrelsen af databasen (DATA)

f3 = Kompleksitet af systemet (CPLX)

COMPUTER FAKTORER

f4 = Krav til hastighed i drift (TIME)

f5 = Krav til hovedlager (“Main storage”) i drift (STOR)

f6 = Hyppighed af ændringer i teknisk platform (VIRT)

f7 = Ventetid ved testkørsler på at få resultater (TURN)

udvidet cocomo1
Udvidet COCOMO

PERSONLIGE FAKTORER

f8 = Analytikernes kapabilitet / evne (ACAP)

f9 = Udviklernes erfaring i applikationsdomæne (AEXP)

f10 = Programmørernes kapabilitet / evne (PCAP)

f11 = Udviklernes erfaring med teknisk platform (VEXP)

f12 = Programmørernes erfaring med prog.sprog (LEXP)

PROJEKT FAKTORER

f13 = Graden af anvendelse af moderne programmering (MODP)

f14 = Brug af programmeringsværktøjer (TOOL)

f15 = Krav til tidsplan / leveringstidspunkt (SCED)

cocomo 2 0 1995
COCOMO 2.0 (1995)

Stadie 1: Under for-analyse => Objekt point (se side 52)

Stadie 2: Krav-specifikation => Function Points

Stadie 3: Udvikling begyndt => Linier kode (som gl. COCOMO)

NYE FAKTORER i COCOMO 2.0

n1 = Dokumentationskrav

n2 = Grad af krævet genbrug

n3 = Udviklerkontinuitet

n4 = Udvikling spredt på flere lokationer

n5 = Organisationens erfaring med projekttype

n6 = Kravenes fleksibilitet

n7 = Opgavens velafklarethed

n8 = Team Spirit

n9 = Den faglige modenhed i udviklingsorganisation

use case point estimering

Use Case Point - estimering

Kilde: Geri Schneider & Jason P. Winters (2001). Applying Use Cases. 2nd Edition. Addison Wesley.

God til tidlig estimering

God hvor objekt-orienteret udvikling anvendes

Eller hvor kravspecifikationer skrives med Use Cases

hvordan en use case ser ud forenklet
Hvordan en Use Case ser ud forenklet
  • Use Case: Kunde ønsker container flyttet
  • Aktører: Kunde, kontorist
  • Type: Primær
  • Formål: At modtage en ordre fra en kunde om at flytte en

container

  • Beskrivelse: En kunde ringer og ønsker en container flyttet fra varehus A til varehus B. Kontoristen finder containeren

i varehus A. Derefter findes en ledig plads i varehus B.

Og endelig findes en ledig plads og tid for en lastvogn

der kører fra varehus A til B.

  • Hændelser:
    • Aktør handling Systemets svar:

X gør y

 Systemet gør z

...

hvordan en use case ser ud fortsat
1 Denne Use Case starter da kunden ringer til kontoristen og beder om at få container X flyttet fra varehus A til varehus B

2 Kontoristen noterer flytteønsket og checker om container X er i varehus A

4 Kontoristen forespørger om ledige pladser i varehus B

6 Kontoristen reserverer plads nr. Z i varehus B

8 Derefter beder kontoristen om at få en oversigt over lastbiler der kører fra varehus A til varehus B inden for den næste uge

10 Kontoristen vælger en plads på en lastbil der kører fra varehus A til varehus B næste mandag

12 Kontoristen sender så en bekræftelse til kunden, som fortæller at halv-containeren X bliver flyttet fra varehus A til varehus B næste mandag, og at containeren vil være til rådighed i varehus på plads nr. Z dagen efter mandag.

3 Systemet bekræfter at halv-containeren X (dvs. en container i halv størrelse) findes i varehus A på plads nr. Y

5 Systemet svarer med en liste over ledige pladser i varehus B til containere i halv størrelse

7 Systemet bekræfter reservationen af plads nr. Z i varehus B

9 Systemet svarer med en liste over lastbiler der kører fra varehus A til varehus B næste uge, og som har ledig plads

11 Systemet bekræfter reservationen af en plads til halv-størrelse container på en lastbil der kører fra varehus A til varehus B næste mandag. Endvidere bekræfter systemet reservationen af plads nr. Z i varehus B, samt frigivelsen af plads nr. Y i varehus A

Hvordan en Use Case ser ud fortsat

Alternativer

Linie 3: Container X findes ikke i varehus A. Indiker fejl.

Linie 8: Der er ingen lastbiler der kører fra A til B i kommende uge.

slide45

Fremgangsmåde - Use Case point

  • Tildel hver aktør en vægt (1, 2 eller 3). Beregn TAW (Total Actor Weight)
  • Klassificer hver Use Case med en faktor 5, 10 eller 15. Enten som transaktions-baseret Use case eller efter hvor mange (objekt-)klasser der indgår i Use Casen. Læg tallene sammen til UUCP (Unadjusted Use Case Points)
  • Giv point fra 1-5 for en række tekniske faktorer. Beregn TCF (technical Complexity Factor) som et produkt af de tekniske faktorer
  • Giv point fra 1-5 for en række omgivelses-faktorer. Beregn EF (Environmental Factors) som en produkt af faktorer.
  • Beregn antallet af Use Case Point UCP = UUCP * TCF * EF

6a.Beregn antal mandtimer ved at gange UCP med 20, hvis 2 eller færre af omgivelsesfaktorerne (EF) er 3 eller derover.

6b.Beregn antal mandtimer ved at gange UCP med 28, hvis 3 eller 4 af omgivelsesfaktorerne (EF) er 3 eller derover.

6c.Hvis 5 af omgivelsesfaktorerne er 3 eller derover – så lav projektet om

taw total actor weight
TAW – Total Actor Weight

Hver aktør i hver Use Case tildeles

et pointtal fra 1 til 3

transaktions use cases
Transaktions Use Cases

Vurdér antallet af transaktioner i hver Use

Case inklusiv alternative veje

objekt klasse use cases
(Objekt-)klasse Use Cases

Hvis du allerede har lavet en første klasse-

-diagram (ofte kaldet konceptuel model), så

kan du i stedet for antal transaktioner tælle

antallet af klasser

tcf technical complexity factor
TCF – Technical Complexity Factor

Hver faktor rates 0 til 5. Nul = nej.

TCF = 0,6 + (0,01 *Tfaktor) sum af alle faktorer

ef environmental factors
EF – Environmental Factors

Hver faktor rates 0 til 5. Nul = nej.

EF = 1,4 + (-0,03 * Efaktor) sum af alle faktorer

beregn use case point
Beregn Use Case point

5. Beregn antallet af Use Case Point UCP = UUCP * TCF * EF

6a.Beregn antal mandtimer ved at gange UCP med 20, hvis 2 eller færre af omgivelsesfaktorerne (EF) er 3 eller derover.

6b. Beregn antal mandtimer ved at gange UCP med 28, hvis 3 eller 4 af omgivelsesfaktorerne (EF) er 3 eller derover.

6c. Hvis 5 af omgivelsesfaktorerne er 3 eller derover – så lav projektet om

erfaring med use case point
Erfaring med Use Case Point
  • Anvendt hos Internet-softwarehus, stor virksomhed i finansektoren, og talrige studenterprojekter
  • I softwarehus var estimatet dobbelt op af faktiske tal
  • Faktorer skulle gennem betydelig tilpasning i finans-firma
  • Let at lære for studerende – 10 timer incl. arbejde med konkret projekt
function points
Function Points
  • En faktorvurderingsteknik oprindeligt publiceret af Albrecht (1979)
  • Revideret 1984, 1986, 1990 … etc.
  • SPR - Software Productivity Research definerer Feature Points i 1986
  • IFPUG - International Function Points User Group. Permanent i 1992. Version 4.0 i 1994.
eksempel function point beregner
Eksempel:Function Point beregner

Et skærmbillede med eksterne inddata (EI). Et skærm-billede med eksterne uddata (som vist). Mulighed for at udskrive en rapport af skærmbillede = 2 Eksterne uddata

function point justering
Function Point justering

Justering kan ske efter flere modeller fra +/- 25% til meget avancerede modeller der går op til +/- 125%

I eksemplet bruges IBM´s 1984 metode der frem til 1995 svarede til IFPUG´s fremgangsmåde

Justeringsmultiplikator

= (SUM*0,01) + 0,65

= (10*0,01) + 0,65 = 0,75

24 ikke-justerede FP * 0,75

Justerede Function Points

Data Comunications 0

Distributed functions 0

Heavily used configuration 0

Transaction rate 0

On-line data entry 2

End-user efficiency 3

On-line update 2

Complex processing 0

Installation ease 0

Operational ease 3

Multiple sites 0

Facilitated change 0

TOTAL INFLUENCE SUM 10

buffer projektlederens reserve
Buffer – projektlederens reserve
  • Skal dække forventede omkostninger, hvor det ikke på estimeringstidspunktet er muligt at fastlægge hvor og hvornår, eller hvor store. Der afsættes derfor ét samlet beløb til dækning af disse særlige forhold
  • Kan f.eks. være +1*s eller +2*s som beregnet ved Trepunkts-estimeringen
  • Frigives til de aktiviteter der ligger over Middelværdien under gennemførelsen
  • Reduceres efterhånden som projektet skrider fremad
contingency budgetreserve
”Contingency” budgetreserve
  • Skal dække forventede omkostninger, hvor det ikke på estimeringstidspunktet er muligt at fastlægge hvor og hvornår, eller hvor store. Der afsættes derfor ét samlet beløb til dækning af disse særlige forhold
  • ”Contingency” kaldes også budgetreserve, management reserve, diverse, eller uforudsete omkostninger
  • ”Contingency” kan fastsættes som en procent af de øvrige poster. Procenten varierer med branche og projekttype
  • Frigives af Styregruppen efter behov
lad dig ikke presse af politiske forhold
Lad dig ikke presse af politiske forhold

Lad dig ikke presse af politiske forhold - Ingen vinder ved det i længden. Estimering er ikke politisk - men det er derimod projektets slutdato ofte. Hvis hverken ressourcemængde eller kalendertid hænger sammen, så må ledelsen eller styregruppen skære ned i projektets omfang (husk dokumentation!).

politisk estimering nogle metoder der ikke anbefales
Politisk estimering: Nogle metoder der IKKE anbefales
  • Parkinson. Arbejdet udvider sig til det dækker den til rådighed værende arbejdstid.
  • Vind kontrakten. Estimatet fastlægges så man kan vinde kontrakten.
  • Så meget som tillades. Estimatet er lig med sidste estimat + den forsinkelse kunden/chefen er villig til at acceptere. Eller estimatet er lig med et udefra givent “rigtigt” svar
  • Gang med  + 10%. Denne formel og lignende formler kan selvfølgelig udtrykke usikkerheden i projektet. Men hvordan ved vi at den gør det?
etablere erfaringsdatabase
Etablere erfaringsdatabase
  • Baseret på de 23 kategorier (Capers Jones) indsamles data fra så mange nyligt afsluttede projekter som muligt.
  • Lav en prototype af den brugergrænseflade, som projektledere skal bruge, når de skal trække data ud af databasen.
  • Efter et par iterationer vil prototypen virke tilfredsstillende, hvorefter den kan færdigudvikles med fuld funktionalitet.
indf r ny estimeringsprocedure
Indfør ny estimeringsprocedure
  • Pilottest en række forskellige estimerings-teknikker. Brug testresultaterne til at beslutte at bruge 2-3 teknikker. F.eks.: Delfi-teknikken og historiske data til den første estimering (overslag) af projekters størrelsesorden.
  • Pilottest og vælg teknik til den ”rigtige” estimering. F.eks.: Successiv kalkulation samt objekt point - beskrevet i en procedure, som blive gjort til en del af virksomhedens kvalitetssystem.