Før projektet besluttes

Præsentationer af emnet: "Før projektet besluttes"— Præsentationens transcript:

1 Før projektet besluttes

2 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

3 Denne lektion X X X X FØR projektet besluttes
Planlægn. & spec. arbejdet Udfø-relse Aflevering og eval. Drift & vedl.hold Denne lektion 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

4 CBA = Cost/Benefit analyse
Kvantitativ opgørelse baseret på omkostninger afledt af projektets gennemførelse og indtægter afledt af produktets implementering. Cost Benefit Udvikling Driftslevetid Ana- lyse Pay Back Periode Break Even Overskud

5 Cost analyse Udviklingen af det nye system / service Løn og overhead
Costs Benefits 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 Driftsomkostninger Hardware, netværk m.m. Software Produktionsfolk Marketing og salgsomkostninger Vedligeholdelse Faciliteter Finansielle omkostninger Rente af lån / eksisterende midler Offeromkostninger

6 Benefit analyse Forøget salg / profit Forøget antal transaktioner
Costs Benefits 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

7 Hvornår skal man lave CBA?
Projektet Produktets levetid Skal projektet startes ? Skal projektet fortsætte ? Hvad kom projektet til at koste ? Hvor god var investeringen i forhold til forventet ? Glemmes ofte!

8 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

9 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

10 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”

11 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 Produkt ALFA BRAVO CHARLIE DELTA EKKO

12 4. Formel accept af Scope 5. Opfølgning på 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

13 Skab overblik - Work Breakdown Structure (WBS)
Produkt ALFA BRAVO CHARLIE DELTA EKKO Opdeling i arbejdspakker efter: Proces Begge dele

14 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)

15 Estimering er en del af projektledelsens kerneområder

16 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.

17 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

18 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

19 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.

20 Vo = mest optimistiske skøn (mindsteværdi) Vs = mest sandsynlige værdi Vp = mest pessimistiske værdi (størsteværdi) Vm = middelværdi

21 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)

22 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)

23 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)

24 Eksempel på beregning 1

25 Eksempel på beregning 2

26 Eksempel på beregning 3

27 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.

28 Håndtering af fælles usikkerhed

29 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

30 DELFI-teknikken – et eksempel
1. gang 2. gang 3. gang

31 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.

32 Fordele og ulemper ved metoder og teknikker

33 Del 2 Modelbaserede teknikker
COCOMO Use Case point Fnction points

34 Supplerende litteratur - COCOMO & Function Points
Hughes & Cotterell, ”Software Project management”, 4th edition, 2006, Chapter 5 – Software effort estimation

35 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

36 COCOMO-eksempel Vi skal lave et program på 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 ?

37 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

38 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 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

39 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)

40 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)

41 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

42 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

43 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  ...

44 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 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.

45 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

46 TAW – Total Actor Weight
Hver aktør i hver Use Case tildeles et pointtal fra 1 til 3

47 Transaktions Use Cases
Vurdér antallet af transaktioner i hver Use Case inklusiv alternative veje

48 (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

49 Beregn UUCP Unadjusted Use Case Points

50 TCF – Technical Complexity Factor
Hver faktor rates 0 til 5. Nul = nej. TCF = 0,6 + (0,01 *Tfaktor) sum af alle faktorer

51 EF – Environmental Factors
Hver faktor rates 0 til 5. Nul = nej. EF = 1,4 + (-0,03 * Efaktor) sum af alle faktorer

52 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

53 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

54 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 Version 4.0 i 1994.

55 Fem ting skal tælles

56 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

57 Eksempel på tælling af Function Points

58 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

59 Fordele og ulemper ved modelbaserede metoder og teknikker

60 Afrunding – nogle vigtige pointer

61 Estimeringsnøjagtighed

62 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

63 ”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

64 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!).

65 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?

66 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.

67 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.