1 / 67

Før projektet besluttes

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

philena
Download Presentation

Før projektet besluttes

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

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

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

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

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

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

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

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

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

  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ærdiVp = 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 2Modelbaserede 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å 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 ?

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

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

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

More Related