O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
Methodisch Begroten van software projecten 
Hanzehogeschool Groningen 5 december 2014
Harold van Heeringen Software Cost Engineer, Sogeti Nederland B.V. ISBSG president NESMA bestuur werkgroep COSMIC werkgroe...
3 
Sogeti Nederland 
ICT dienstverlener met ruim 35 jaar ervaring en 3.000 medewerkers Vestigingen in: 
>Vianen (hoofdkant...
4 
Sogeti & Capgemini
5 
Sogeti Group 
+20,000 werknemers over 100 locaties in 15 landen 
USA 2,000 
Chicago, Cincinatti, Houston, New York, Sea...
6 
Titel | Onderwerp | Plaats | Datum | 
Resultaat door passie voor ICT
7 
Enkele klanten van Sogeti
8 
In de prijzen 
•Beste Werkgever Incompany Award: Beste werkgever van 2013 (5e keer!) 
•Beste Werkgever Imago onderzoek ...
9 
Duurzaam ondernemen 
2011: Sogeti CO2-neutraal 
Duurzaam betekent voor Sogeti: Verspilling voorkomen en verantwoord omg...
10 
Jouw carrière & het ontwikkeltraject 
YP 
2 – 3 jaar 
Specialist 
YP 
Vakinhoudelijk 
Vak specialist / Architect 
Cons...
11 
Ohio (USA) 
High Performance Teaming (HPT), klantgericht werken, coaching, persoonlijke vaardigheden 
3 weken, 2 weeke...
12 
www.werkenbijsogeti.nl
13 
Introductie 
Het belang van het goed begroten van projecten; Het verschil tussen expert begroting en methodische begro...
14 
Het belang van het goed begroten van projecten
15 
Probleem: software projecten
16 
Commissie Elias (15-10-2015) 
Waarom falen IT projecten bij de overheid zo vaak? Conclusies o.a. (geparafraseerd): 
►D...
17 
2 belangrijkste redenen falen 
Instabiele user requirements 
► Te weinig aandacht voor requirements analyse; 
► Te vro...
18 
Begroten van software 
Zo denken veel klanten erover als ze om een begroting voor softwarerealisatie vragen. 
Het is b...
19 
Waarom is een goede begroting belangrijk? 
De begroting is basis voor: 
• de business case; 
• de planning; 
• de aanb...
20 
Begroten in de IT 
IT industrie: relatief jonge industrie Lage volwassenheid op het gebied van begroten. Druk vanuit k...
21 
Wat is een goede begroting? 
Een goede begroting is een plan dat de stakeholders voldoende betrouwbaar vinden om te ge...
22 
Overschatten/onderschatten 
Onderschatten 
Overschatten 
Lineaire extra kosten 
Extra uren worden besteed 
Te lage sch...
23 
Traditioneel begroten
24 
Traditioneel begroten 
Start: klant stelt functionele documentatie op. De scope van het project wordt bepaald door de ...
25 
Cone of uncertainty 
0 
-50 
50 
100 
150 
200 
Feasibility 
study 
Requirements specification 
Software development 
...
26 
Het verschil tussen Expert- en methodische begroting
27 
2 typen begrotingen 
1.Expertbegroting (technische calculatie) Bottom-up , uren toekennen aan work items, kennis en er...
28 
2 typen begrotingen 
2.Methodische begroting (cost engineering) Top-down o.b.v. objectieve omvangbepaling, relevante p...
29 
Sogeti begrotingen 
CoE expertbegroting 
Functioneel ontwerper: F.O. uren 
Technisch architect: T.O., coding +UT uren ...
30 
Volwassen begrotingen 
Waarom worden softwarerealisatie projecten vaak niet op een volwassen manier begroot? 
•In de m...
31 
Methodische Begrotingen 
1.Meet de functionele omvang van de ‘functional user requirements’. 
•ISO methodes NESMA, IFP...
32 
Meten van Functionele omvang 
Functional UR 
Technical UR 
Quality UR 
User Requirements 
Functiepunt analyse (FPA) en...
33 
Functiepunt Analyse (FPA)
34 
Wat is FPA 
Uniforme methode om de aan de gebruiker geboden en door de gebruiker gevraagde hoeveelheid functionaliteit...
35 
FPA en begroten 
Analogie: verven van een muur (professionele schilder) 
•Meten oppervlakte: 20 m2 (= objectieve omvan...
36 
Functiepunt Analyse 
ILGV 
KGV 
Gebruikers 
Transacties 
Gegevensverzamelingen 
IF 
OF 
UF
37 
Voorbeeld 
Gevraagde functionaliteit 
>Een overzicht met de geboortedata van de leerlingen, gesorteerd op klas, maand,...
38 
In de praktijk 
Indicatieve FPA 
Op basis van een conceptueel datamodel: 
35 FP per systeemeigen object 
15 FP per sys...
39 
Vraag 
Je moet een hondenregistratie programma maken voor de uitlaatservice van je buurvrouw. De requirements: 
- Je k...
40 
Antwoord: LGV’s 
Je moet een hondenregistratie programma maken voor de uitlaatservice van je buurvrouw. De requirement...
41 
Antwoord: Invoerfuncties 
Je moet een hondenregistratie programma maken voor de uitlaatservice van je buurvrouw. De re...
42 
Antwoord: Opvragingsfuncties 
Je moet een hondenregistratie programma maken voor de uitlaatservice van je buurvrouw. D...
43 
Hondenregistratie 
Type 
Aantal 
FP 
ILGV 
3 
21 
KGV 
0 
0 
IF 
8 
32 
OF 
3 
12 
UF 
0 
0 
Totaal 
65 FP
44 
Productiviteit 
De functionele omvang is bekend. Om een ruwe begroting te maken vermenigvuldigen we de omvang met een ...
45 
Historische Data - ISBSG 
International Software Benchmarking Standards Group (ISBSG - www.isbsg.org) 
- Not for profi...
46 
Ruwe Begroting 
Hondenregistratie systeem: 65 FP Min: 8 uur/FP * 65 FP = 520 uur Likely: 11 uur/FP * 65 FP = 715 uur M...
47 
De impact van doorlooptijd (Putnam) 
Omvang/productiviteit = Inspanning1/3 * doorlooptijd4/3 
Inspanning 
Doorlooptijd...
48 
Project bij verschillende doorlooptijden 
Doorlooptijd 
A 
Doorlooptijd: 6 maanden 
Inspanning: 4.500 uur 
Max. teamom...
49 
Begrotingstools 
Begrotingstools 
- QSM SLIM 
- Galorath SEER-SEM 
- Op basis van input parameters, wordt een begrotin...
50 
Hondenregistratie 
Staffing & Probability Analysis 
Avg Staff (people) 
<Control Panel - Peak = 3,0> 
1 
okt 
'13 
nov...
51 
Hondenregistratie – 3 fte 
Staffing & Probability Analysis 
Avg Staff (people) 
<Control Panel - Peak = 3,0> 
1 
okt 
...
52 
Hondenregistratie – 1 mnd 
Staffing & Probability Analysis 
Avg Staff (people) 
<Single Goal - C&T Duration 1,0> 
1 
o...
53 
Begroten van agile projecten 
Is de documentatie uit agile projecten geschikt om te meten m.b.v. (traditionele) omvang...
54 
Is agile documentatie meetbaar? 
Vaak: User stories. 
Als een <type gebruiker> wil ik <iets doen> zodat ik <er iets aa...
55 
Agile projecten 
Vaak gehoord: “Waarom begroten? We gaan starten, werken in sprints en leveren de meeste waarde aan de...
56 
De ijzeren driehoek 
Kwaliteit 
Geld/middelen 
Tijd 
Functionaliteit 
Omdat het in agile projecten mogelijk is om de g...
57 
Waterval vs. agile 
Waterval projecten: Scope is ‘fixed’. Halen van doorlooptijd en uren gaat vaak mis. Risico bij lev...
58 
Begroten van agile projecten 
De hamvraag: hoeveel functionaliteit moet er gemaakt worden en hoeveel functionaliteit k...
59 
Ras 
Hondpunten 
Poedel 
5 
Schnautzer 
6 
Duitse herder 
10 
Chihuahua 
2 
Labrador 
11 
Sint Bernhard 
12 
Bulldog 
...
60 
Planning poker 
Planning poker meeting met alle teamleden Kaarten: 0,1,2,3,5,8,13,20,40 en 100 (voorbeeld) Moment: Spr...
61 
Voordelen planning poker 
“Planning is everything, plans are nothing.” 
1.Discussie vanuit verschillende invalshoeken ...
62 
Onze visie
63 
Typische size metrieken 
Een story point is een arbitraire (maar intuïtieve) eenheid voor de omvang van een feature {1...
64 
Productiviteit vs. velocity 
Agile velocity ≈ productiviteit ? 
Velocity is tactisch – “Hoeveel kunnen we realiseren i...
65 
Wat willen we? 
Aanbieding t.b.v. een bid of PvA voor het project Zo goed mogelijk begroten van het project Methode: c...
66 
Begroten van een agile project 
Input: 
•Functionele documentatie (mag high-level) 
•Begrotingsparameters 
•doorloopti...
67 
Sogeti en cost engineering 
Afdeling Shared SEC (Sizing, Estimating & Control) Gebundelde kennis, ervaring, skills, me...
68 
Conclusies 
De IT industrie is zeer onvolwassen als het gaat om begroten 
•Veel organisaties gebruiken alleen ‘expertb...
Young Professional @Sogeti
70 
www.werkenbijsogeti.nl
Bedankt voor jullie aandacht! SEC@sogeti.nl
@haroldveendam Harold.van.heeringen@sogeti.nl 
Harold van Heeringen 
Senior Consultant Software Metrics /Software Cost Eng...
Próximos SlideShares
Carregando em…5
×

Methodisch begroten van projecten hanzehogeschool groningen december2014

531 visualizações

Publicada em

Guest lecture at the Hanzehogeschool Groningen, 4th year students Informatica.

Publicada em: Negócios
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Methodisch begroten van projecten hanzehogeschool groningen december2014

  1. 1. Methodisch Begroten van software projecten Hanzehogeschool Groningen 5 december 2014
  2. 2. Harold van Heeringen Software Cost Engineer, Sogeti Nederland B.V. ISBSG president NESMA bestuur werkgroep COSMIC werkgroep Benchmarking werkgroep FPA in contract(ing) COSMIC IAC, NL afgevaardigde harold.van.heeringen@sogeti.nl @haroldveendam haroldveendam haroldvanheeringen
  3. 3. 3 Sogeti Nederland ICT dienstverlener met ruim 35 jaar ervaring en 3.000 medewerkers Vestigingen in: >Vianen (hoofdkantoor) >Groningen >Amsterdam Zuidoost >Amersfoort >Rotterdam >Eindhoven
  4. 4. 4 Sogeti & Capgemini
  5. 5. 5 Sogeti Group +20,000 werknemers over 100 locaties in 15 landen USA 2,000 Chicago, Cincinatti, Houston, New York, Seattle, Washington… India 1,000 Mumbai, Bangalore Europe 18,600 Frankrijk 10,000 Paris, Toulouse, Lyon, Marseille… Benelux 4,000 Brussels, Antwerpen, Vianen Spanje 1,100 Madrid, Barcelona, Valencia… Scandinavië 1,100 Stockholm, Oslo, Copenhagen… UK & Ierland 300 London, Dublin, Galway Duitsland 230 Hamburg, Munich, Frankfurt… Zwitserland 110 Geneva, Basel, Zürich Finland 35 Helsinki
  6. 6. 6 Titel | Onderwerp | Plaats | Datum | Resultaat door passie voor ICT
  7. 7. 7 Enkele klanten van Sogeti
  8. 8. 8 In de prijzen •Beste Werkgever Incompany Award: Beste werkgever van 2013 (5e keer!) •Beste Werkgever Imago onderzoek Intomart/GfK (Telegraaf Media Groep & Elsevier): Beste werkgever van 2011 •Beste Imago, MT500 Bedrijven met het beste imago, van nr 123 naar 47 •Beste ICT- dienstverlener Computable Awards: Beste ICT-dienstverlener van 2011 ( 2e keer!) •IBM Beacon Awards Internationaal Winnaar in de categorieën “Cloud Computing Innovation - Cloud Builder” en “Outstanding Collaboration with IBM Global Technology Services” •Nummer 1 in Testen volgens internationaal onderzoeksbureau Ovum. •Microsoft Partner of the Year 2011
  9. 9. 9 Duurzaam ondernemen 2011: Sogeti CO2-neutraal Duurzaam betekent voor Sogeti: Verspilling voorkomen en verantwoord omgaan met mens en milieu.
  10. 10. 10 Jouw carrière & het ontwikkeltraject YP 2 – 3 jaar Specialist YP Vakinhoudelijk Vak specialist / Architect Consultant Management Projectmanagement Lijnmanagement
  11. 11. 11 Ohio (USA) High Performance Teaming (HPT), klantgericht werken, coaching, persoonlijke vaardigheden 3 weken, 2 weekenden
  12. 12. 12 www.werkenbijsogeti.nl
  13. 13. 13 Introductie Het belang van het goed begroten van projecten; Het verschil tussen expert begroting en methodische begroting; Traditioneel begroten (waterval); FPA overview + eenvoudige oefening; Historische data en ervaringscijfers; Begroten van agile projecten in de praktijk; Benchmarking en performance measurement van afgeronde projecten;
  14. 14. 14 Het belang van het goed begroten van projecten
  15. 15. 15 Probleem: software projecten
  16. 16. 16 Commissie Elias (15-10-2015) Waarom falen IT projecten bij de overheid zo vaak? Conclusies o.a. (geparafraseerd): ►De overheid begroot haar projecten onrealistisch en niet goed onderbouwd; ►De overheid legt geen data vast van projecten met als doel beter te gaan begroten; ►De overheid gunt projecten voor een groot deel gebaseerd op laagste prijs; ►De overheid weet niet wat een realistische prijs is en wat de risico’s zijn van onderschatting; ►De overheid is slecht in het specificeren van requirements. -… (zie o.a. http://bit.ly/1zQcZUR)
  17. 17. 17 2 belangrijkste redenen falen Instabiele user requirements ► Te weinig aandacht voor requirements analyse; ► Te vroeg starten met realisatie; ► Gebruikers weinig betrokken. Onrealistische begroting en planning ► Onvolwassen begrotingstechnieken (optimistisch!!); ► Druk om doorlooptijd korter te maken en kosten laag te houden; ► Ineffectieve projectmanagement technieken
  18. 18. 18 Begroten van software Zo denken veel klanten erover als ze om een begroting voor softwarerealisatie vragen. Het is belangrijk een realistische, onderbouwde, objectieve en verdedigbare begroting aanbieden!
  19. 19. 19 Waarom is een goede begroting belangrijk? De begroting is basis voor: • de business case; • de planning; • de aanbieding (fixed price / fixed date ; winst/verlies); • voortgangsrapportages  kleur van de smileys; • het financieel resultaat van het project; • het vastleggen/vrijgeven van resources; • ‘alignment’ met de business/klant; • et cetera!
  20. 20. 20 Begroten in de IT IT industrie: relatief jonge industrie Lage volwassenheid op het gebied van begroten. Druk vanuit klant/business op kosten, leidt tot onrealistische verwachtingen (misplaatst optimisme). Business: levert set requirements, vaak onvoldoende gedetailleerd Business: het is te duur  bevordert optimisme Business: het moet sneller  bevordert optimisme IT: weet niet precies ‘hoe groot het is’ IT: kent eigen performance niet  matige onderbouwing, weinig zicht op realiteitswaarde, gaat relatief eenvoudig mee met druk vanuit de klant. Gevolg: veel mislukte projecten, overschrijdingen, gestopte projecten  imago probleem IT, lage klanttevredenheid!
  21. 21. 21 Wat is een goede begroting? Een goede begroting is een plan dat de stakeholders voldoende betrouwbaar vinden om te gebruiken voor het nemen van beslissingen. Een begroting geeft inzicht in de potentiële risico’s. Een begroting is altijd een distributie, nooit een getal. Bijvoorbeeld: min. 500 uur, waarschijnlijk 800 uur, max. 1.300 uur. Een begroting is nooit exact. Een begroting komt bij voorkeur tot stand, gebruik makend van verschillende methoden. Eén van die methoden is bij voorkeur gebaseerd op historische data.
  22. 22. 22 Overschatten/onderschatten Onderschatten Overschatten Lineaire extra kosten Extra uren worden besteed Te lage schattingen Extra Kosten 0% >100% Te hoge schattingen Realistische schattingen Non- Lineaire extra kosten Planningsfouten Vergroten team veel duurder maar nauwelijks sneller Extra management attentie/overhead Stress: Meer defects, lagere onderhoudbaarheid
  23. 23. 23 Traditioneel begroten
  24. 24. 24 Traditioneel begroten Start: klant stelt functionele documentatie op. De scope van het project wordt bepaald door de beschreven functionaliteit binnen de aangegeven technische kaders. Sogeti: begroot hoeveel uren het gaat kosten om het project uit te voeren: • TO, coding, u-test, s-test, ond. a-test, oplevering, PL, QA • Wat is de doorlooptijd? • Wat is de teamsize en hoeveel FTE van welke expertise nodig? Risico: te optimistische begroting leidt tot overruns Risico: te pessimistische begroting leidt tot het niet winnen van het project
  25. 25. 25 Cone of uncertainty 0 -50 50 100 150 200 Feasibility study Requirements specification Software development Project closure Variability (%) Slecht begroot of slecht beheerst project De kegel wordt niet vanzelf nauwer. Men neemt beslissingen om hem nauwer te maken. Het later wijzigen van deze beslissingen leidt ertoe dat de kegel weer wijder wordt.
  26. 26. 26 Het verschil tussen Expert- en methodische begroting
  27. 27. 27 2 typen begrotingen 1.Expertbegroting (technische calculatie) Bottom-up , uren toekennen aan work items, kennis en ervaring Voordelen: •Altijd uit te voeren (als er een expert beschikbaar is); •Experts lezen documentatie door en zien ‘de beren’. Nadelen: •Niet alle activiteiten worden meegenomen (testscripts??); •Vaak ontbreekt een onderbouwing van de cijfers (‘gevoel’); •Een expert gaat niet het werk doen (wie wel?); •Is de expert eigenlijk wel een expert? (projecten zijn uniek); •Geen impact van doorlooptijd, team size, et cetera?; •Geen check op realiteitswaarde (historie). Resultaat: Meestal optimistisch (gemiddeld 30% onderschatting)
  28. 28. 28 2 typen begrotingen 2.Methodische begroting (cost engineering) Top-down o.b.v. objectieve omvangbepaling, relevante productiviteitscijfers en geavanceerde begrotingstools Voordelen: •Objectief, herhaalbaar, verifieerbaar, verdedigbaar! •Inzicht in risico’s •Scenario analyse: doorlooptijd, team size, % confidence Nadelen: •Vereist bepaalde volwassenheid van de organisatie: •meten en analyseren afgeronde projecten •investeren in expertise en tooling •Stelt minimale eisen aan de documentatie
  29. 29. 29 Sogeti begrotingen CoE expertbegroting Functioneel ontwerper: F.O. uren Technisch architect: T.O., coding +UT uren Tester: testuren Projectleider: PL uren Cost engineering begroting (SEC) Omvangmeting (FP / CFP) Methodische begroting - Uren, doorlooptijd, FTE, kosten - Scenario’s - Risico’s Challenge Aanbieding Plan van aanpak
  30. 30. 30 Volwassen begrotingen Waarom worden softwarerealisatie projecten vaak niet op een volwassen manier begroot? •In de meeste organisaties: alleen expertbegrotingen; •Miljoenenprojecten worden begroot op basis van de meningen van individuele ‘experts’; •Onderzoek: experts zijn gemiddeld 30% te optimistisch. Gevolg: het merendeel van de projecten start op basis van onrealistische begrotingen en verwachtingen  overschrijdingen in budget, doorlooptijd en … vaak zelfs slechte kwaliteit. En dat terwijl er voldoende cost engineering methoden, technieken en tools voorhanden zijn om projecten onderbouwd en verdedigbaar te begroten!
  31. 31. 31 Methodische Begrotingen 1.Meet de functionele omvang van de ‘functional user requirements’. •ISO methodes NESMA, IFPUG of COSMIC FPA •Resultaat: omvang van de te realiseren functional user requirements is x functiepunten •Objectief / verifieerbaar / herhaalbaar / verdedigbaar 2.Bepaal de te verwachten Productiviteit (Uren/FP) voor het project •Historische data (afgeronde projecten) •Benchmark data (ISBSG) 3.Verwerk de omvang en de productiviteit met een Begrotingstool •Scenario’s – doorlooptijd, teamgrootte, risico’s
  32. 32. 32 Meten van Functionele omvang Functional UR Technical UR Quality UR User Requirements Functiepunt analyse (FPA) en COSMIC meten alleen de Functional User Requirements – Wat moet de software doen voor de gebruiker? Voordelen: - Kan vroegtijdig worden toegepast (Requirements analyse) - Omvang is onafhankelijk van techniek en implementatie
  33. 33. 33 Functiepunt Analyse (FPA)
  34. 34. 34 Wat is FPA Uniforme methode om de aan de gebruiker geboden en door de gebruiker gevraagde hoeveelheid functionaliteit van een informatiesysteem uit te drukken in een eenheid (functiepunt). Kenmerken: •Objectief (ISO standaard) •Begrijpelijk voor niet automatiseerders •Reproduceerbaar, verifieerbaar, herhaalbaar, verdedigbaar •Onafhankelijk van de technische oplossing
  35. 35. 35 FPA en begroten Analogie: verven van een muur (professionele schilder) •Meten oppervlakte: 20 m2 (= objectieve omvang) •Gebruik penseel (1 m2 p.u) - 20 uur (historische data) •Gebruik kwast (2 m2 p.u) – 10 uur (historische data) •Gebruik roller (5 m2 p.u) - 4 uur (historische data) aantal uren afhankelijk van omvang en productiviteit Realiseren van een informatiesysteem •Omvang op basis van functiepunten: 100 FP (= objectieve omvang) •Productiviteit uit ervaringscijfers/benchmarks •Java: 8 uur/FP – 800 uur (historische data) •Cobol: 22 uur/FP – 2.200 uur (historische data) aantal uren afhankelijk van omvang en productiviteit
  36. 36. 36 Functiepunt Analyse ILGV KGV Gebruikers Transacties Gegevensverzamelingen IF OF UF
  37. 37. 37 Voorbeeld Gevraagde functionaliteit >Een overzicht met de geboortedata van de leerlingen, gesorteerd op klas, maand, dag Benodigde gegevens: >Leerling : naam, geboortedatum >Klas : Klasnaam Soort functie: >Uitvoerfunctie 2 gerefereerde LGV : 3 gerefereerde DET : >Complexiteit Eenvoudig 4fp 0 - 1 2 -3 > 3 > 19 M(7) G(5) M(7) 6 - 19 E(4) G(5) M(7) 1 - 5 E(4) E(4) G(5)
  38. 38. 38 In de praktijk Indicatieve FPA Op basis van een conceptueel datamodel: 35 FP per systeemeigen object 15 FP per systeemvreemd object Op basis van genormaliseerd datamodel: 25 FP per interne logische gegevensverzameling 10 FP per koppelingsgegevensverzameling Globale FPA Gegevensverzamelingen: eenvoudig ILGV = 7 FP, KGV = 5 FP Transacties: gemiddeld IF = 4 FP, UF = 5 FP, OF = 4 FP > 50% 10 -15 % tijdbandbreedte15 -25 % FunctioneelDetailOntwerp DefinitiestudieBasisontwerpDetailontwerp Realisatie> Realisatie
  39. 39. 39 Vraag Je moet een hondenregistratie programma maken voor de uitlaatservice van je buurvrouw. De requirements: - Je kunt honden toevoegen, wijzigen, verwijderen en raadplegen - Je kunt klanten toevoegen, wijzigen, verwijderen en raadplegen - Je kunt uitlaatafspraken toevoegen en wijzigen Maak een globale FPA - LGV’s eenvoudig (ILGV: 7 FP, KGV: 5 FP) - Functies: gemiddeld (IF en OF: 4 FP, UF: 5 FP)
  40. 40. 40 Antwoord: LGV’s Je moet een hondenregistratie programma maken voor de uitlaatservice van je buurvrouw. De requirements: - Je kunt honden toevoegen, wijzigen, verwijderen en raadplegen - Je kunt klanten toevoegen, wijzigen, verwijderen en raadplegen - Je kunt uitlaatafspraken toevoegen en wijzigen Maak een globale FPA - LGV’s eenvoudig (ILGV: 7 FP, KGV: 5 FP) - functies: gemiddeld (IF en OF: 4 FP, UF: 5 FP) 3 ILGV’s * 7FP = 21 FP Geen KGV’s
  41. 41. 41 Antwoord: Invoerfuncties Je moet een hondenregistratie programma maken voor de uitlaatservice van je buurvrouw. De requirements: - Je kunt honden toevoegen, wijzigen, verwijderen en raadplegen - Je kunt klanten toevoegen, wijzigen, verwijderen en raadplegen - Je kunt uitlaat afspraken toevoegen en wijzigen Maak een globale FPA - LGV’s eenvoudig (ILGV: 7 FP, KGV: 5 FP) - functies: gemiddeld (IF en OF: 4 FP, UF: 5 FP) 8 IF’s * 4 FP = 32 FP
  42. 42. 42 Antwoord: Opvragingsfuncties Je moet een hondenregistratie programma maken voor de uitlaatservice van je buurvrouw. De requirements: - Je kunt honden toevoegen, wijzigen, verwijderen en raadplegen - Je kunt klanten toevoegen, wijzigen, verwijderen en raadplegen - Je kunt uitlaat afspraken toevoegen en wijzigen Maak een globale FPA - LGV’s eenvoudig (ILGV: 7 FP, KGV: 5 FP) - functies: gemiddeld (IF en OF: 4 FP, UF: 5 FP) 3 OF’s * 4 FP = 12 FP Uitvoerfuncties?? Raadplegen ??
  43. 43. 43 Hondenregistratie Type Aantal FP ILGV 3 21 KGV 0 0 IF 8 32 OF 3 12 UF 0 0 Totaal 65 FP
  44. 44. 44 Productiviteit De functionele omvang is bekend. Om een ruwe begroting te maken vermenigvuldigen we de omvang met een ‘Project Delivery Rate (PDR)’. Dit is het waarschijnlijke aantal uur/FP dat in het project gerealiseerd kan worden. PDR: - Bij voorkeur eigen ervaringscijfers (afgeronde projecten) - Databases met marktdata (ISBSG repositories)
  45. 45. 45 Historische Data - ISBSG International Software Benchmarking Standards Group (ISBSG - www.isbsg.org) - Not for profit organisatie, verzamelt projectdata uit de markt - Nieuwbouw en Releases - Beheer - Stelt de data ter beschikking aan de markt (anoniem) in .xls - Analyse van en rapporten over de data - Deze data is zeer geschikt voor: - Begroten projecten waar geen eigen ervaringscijfers van zijn - Reality check van offertes - Benchmarken van afgeronde projecten - Beantwoorden RFP’s - Etc.
  46. 46. 46 Ruwe Begroting Hondenregistratie systeem: 65 FP Min: 8 uur/FP * 65 FP = 520 uur Likely: 11 uur/FP * 65 FP = 715 uur Max: 15 uur/FP * 65 FP = 975 uur Voor de fasen: F.O., T.O., coding, unit test, systeemtest, acceptatietest, implementatie. Stel: er is een team van 3 fte beschikbaar om dit uit te voeren. De klant wil het hebben binnen 1 maand. Lukt dit?
  47. 47. 47 De impact van doorlooptijd (Putnam) Omvang/productiviteit = Inspanning1/3 * doorlooptijd4/3 Inspanning Doorlooptijd Plan A: 6 maanden, 4.500 uur Plan B: 7 maanden, 2.400 uur
  48. 48. 48 Project bij verschillende doorlooptijden Doorlooptijd A Doorlooptijd: 6 maanden Inspanning: 4.500 uur Max. teamomvang: 5,8 fte MTTD: 1,764 dagen B Doorlooptijd: 7 maanden Inspanning: 2.400 uur Max. teamomvang: 2,7 fte MTTD: 2,816 dagen Inspanning (fte - uren)
  49. 49. 49 Begrotingstools Begrotingstools - QSM SLIM - Galorath SEER-SEM - Op basis van input parameters, wordt een begroting vastgesteld - Omvang (bv. Functiepunten) - Productiviteit (uit ervaringscijfers / marktdata) - Karakteristieken als ervaring team, complexiteit, e.d. - Doorlooptijd - Team omvang - ‘Confidence levels’ (begroting is een distributie!) - Output: Scenario’s (b.v. doorlooptijd) - uren en kosten per activiteit en rol - risico’s
  50. 50. 50 Hondenregistratie Staffing & Probability Analysis Avg Staff (people) <Control Panel - Peak = 3,0> 1 okt '13 nov dec 0,0 0,5 1,0 1,5 2,0 2,5 3,0 3,5 Avg Staff (people) 3 4 5 6 7 8 Milestones 0 - CSR 1 - SRR 2 - HLDR 3 - LLDR 4 - CUT 5 - IC 6 - STC 7 - UAT 8 - FCR 9 - 99R 10 - 99.9R RISK GAUGE <Control Panel - Peak = 3,0> <No constraints> Duration Effort Peak Staff Quality % 0 10 20 30 40 50 60 70 80 90 100 SOLUTION PANEL - <Control Panel - Peak = 3,0> Duration Effort Cost Peak Staff MTTD Start Date C&T 1,7 739 73,9 3,0 2,670 1-11-2013 Life Cycle 1,7 739 73,9 3,0 2,670 1-11-2013 Months MHR EUR (K) people Day s PI=17,4 MBI=7,7 Eff FP=65 CONTROL PANEL <Control Panel - Peak = 3,0> PI 14,0 20,9 17,4 Peak Staff 2,4 3,6 3,0 Eff FP 52 78 65 Max. 3 fte, 65 FP, 1 maand lukt niet
  51. 51. 51 Hondenregistratie – 3 fte Staffing & Probability Analysis Avg Staff (people) <Control Panel - Peak = 3,0> 1 okt '13 nov dec 0,0 0,5 1,0 1,5 2,0 2,5 3,0 3,5 Avg Staff (people) 3 4 5 6 7 8 Milestones 0 - CSR 1 - SRR 2 - HLDR 3 - LLDR 4 - CUT 5 - IC 6 - STC 7 - UAT 8 - FCR 9 - 99R 10 - 99.9R RISK GAUGE <Control Panel - Peak = 3,0> <No constraints> Duration Effort Peak Staff Quality % 0 10 20 30 40 50 60 70 80 90 100 SOLUTION PANEL - <Control Panel - Peak = 3,0> Duration Effort Cost Peak Staff MTTD Start Date C&T 1,7 739 73,9 3,0 2,670 1-11-2013 Life Cycle 1,7 739 73,9 3,0 2,670 1-11-2013 Months MHR EUR (K) people Day s PI=17,4 MBI=7,7 Eff FP=65 CONTROL PANEL <Control Panel - Peak = 3,0> PI 14,0 20,9 17,4 Peak Staff 2,4 3,6 3,0 Eff FP 52 78 65 Max. 3 fte, 65 FP, 1 maand lukt niet
  52. 52. 52 Hondenregistratie – 1 mnd Staffing & Probability Analysis Avg Staff (people) <Single Goal - C&T Duration 1,0> 1 okt '13 nov dec 0 10 20 30 40 Avg Staff (people) 3 4 5 6 7 8 Milestones 0 - CSR 1 - SRR 2 - HLDR 3 - LLDR 4 - CUT 5 - IC 6 - STC 7 - UAT 8 - FCR 9 - 99R 10 - 99.9R RISK GAUGE <Single Goal - C&T Duration 1,0> <No constraints> Duration Effort Peak Staff Quality % 0 10 20 30 40 50 60 70 80 90 100 SOLUTION PANEL - <Single Goal - C&T Duration 1,0> Duration Effort Cost Peak Staff MTTD Start Date C&T 1,0 6.037 603,7 34,9 0,505 1-11-2013 Life Cycle 1,0 6.037 603,7 34,9 0,505 1-11-2013 Months MHR EUR (K) people Day s PI=17,4 MBI=13,0 Eff FP=65 CONTROL PANEL <Single Goal - C&T Duration 1,0> PI 14,0 20,9 17,4 Peak Staff 27,9 41,9 34,9 Eff FP 52 78 65 Max. 35 fte, 65 FP, 1 maand lukt ‘wel’
  53. 53. 53 Begroten van agile projecten Is de documentatie uit agile projecten geschikt om te meten m.b.v. (traditionele) omvangbepalingsmethoden?
  54. 54. 54 Is agile documentatie meetbaar? Vaak: User stories. Als een <type gebruiker> wil ik <iets doen> zodat ik <er iets aan heb>. Als een boekkoper wil ik de klantbeoordelingen van een boek lezen, zodat ik beter kan beslissen of ik het boek wil kopen. De omvang van dit soort requirements is met traditionele omvangbepalingsmethoden als Functiepuntanalyse en COSMIC prima te meten. Ook high level requirements als, “Er moet een faciliteit komen voor klanten om reviews te plaatsen, te wijzigen, te verwijderen en te lezen” zijn prima te meten.
  55. 55. 55 Agile projecten Vaak gehoord: “Waarom begroten? We gaan starten, werken in sprints en leveren de meeste waarde aan de klant….” Maar: er is altijd een klant of een opdrachtgever met een zak geld en die wil weten wat hij wel en niet gaat krijgen voor dit geld. 100 features? 200 features? 300 features?
  56. 56. 56 De ijzeren driehoek Kwaliteit Geld/middelen Tijd Functionaliteit Omdat het in agile projecten mogelijk is om de gewenste functionaliteit tussentijds te wijzigen, moet deze zijde variabel zijn, anders gaat het ten kosten van de kwaliteit.
  57. 57. 57 Waterval vs. agile Waterval projecten: Scope is ‘fixed’. Halen van doorlooptijd en uren gaat vaak mis. Risico bij leverancier (fixed price). Agile projecten: Doorlooptijd en uren staan vast, scope is variabel (maar wel geprioriteerd). Risico bij klant (wat krijgt hij?).
  58. 58. 58 Begroten van agile projecten De hamvraag: hoeveel functionaliteit moet er gemaakt worden en hoeveel functionaliteit kunnen we maken? Als de doorlooptijd vast staat (vaak wens van klant) en de teamomvang staat vast, dan zijn twee zijden van de ijzeren driehoek ingevuld. Het aantal te besteden uren staat vast. Hoeveel functionaliteit kunnen we met de gegeven teamomvang, in de gegeven doorlooptijd in deze omgeving opleveren? In hoeverre match dit op de verwachtingen (impliciete of expliciete backlog) van de klant?
  59. 59. 59 Ras Hondpunten Poedel 5 Schnautzer 6 Duitse herder 10 Chihuahua 2 Labrador 11 Sint Bernhard 12 Bulldog 7 Story points Relatieve omvangsmaat, meet de omvang van user stories t.o.v. elkaar. VB: Hondpunten (o.b.v. hoogte). Team X: Duitse herder = 10 Team Y: Schnautzer = 10 Team Z: Chihuahua = 1 Hondpunten/Story points is geen standaard Niet bruikbaar voor opbouwen historische data Niet bruikbaar voor begroten project Niet bruikbaar voor benchmarking Wel bruikbaar voor begroten sprint Wel bruikbaar voor velocity/burn down
  60. 60. 60 Planning poker Planning poker meeting met alle teamleden Kaarten: 0,1,2,3,5,8,13,20,40 en 100 (voorbeeld) Moment: Sprint 0 + als er nieuwe user stories bijkomen 1.Een moderator leest de beschrijving van de user story. 2.Teamleden stellen vragen aan product owner. 3.Ieder teamlid kiest een kaart en houdt deze privé. 4.Alle teamleden draaien tegelijk de kaart om. 5.Vaak: significante verschillen in gekozen kaart. 6.De teamleden met de hoogste en laagste kaart leggen uit. 7.De groep discussieert over de oplossingen. 8.De user story wordt opnieuw begroot op dezelfde manier. 9.De kaarten moeten nu bij elkaar in de buurt liggen, zo niet: nog een ronde. 10.Herhalen tot er consensus is.
  61. 61. 61 Voordelen planning poker “Planning is everything, plans are nothing.” 1.Discussie vanuit verschillende invalshoeken leidt tot meer inzicht bij iedereen. 2.Te grote features worden onderkend en opgesplitst in kleinere features. 3.Team commitment op afgegeven schatting.
  62. 62. 62 Onze visie
  63. 63. 63 Typische size metrieken Een story point is een arbitraire (maar intuïtieve) eenheid voor de omvang van een feature {1,2,4,8,16…}, {1,2,3,5,8…}. Een functiepunt (FP) is een objectieve en uniforme eenheid voor de omvang van een feature vanuit een functioneel perspectief. Lines of code (LOC) is een subjectieve en niet-uniforme eenheid voor de omvang van een feature vanuit een fysiek perspectief.
  64. 64. 64 Productiviteit vs. velocity Agile velocity ≈ productiviteit ? Velocity is tactisch – “Hoeveel kunnen we realiseren in een sprint?” Productiviteit is strategisch – “Hoeveel kunnen we realiseren in een project?” Velocity – “story points per sprint” Productiviteit – “functiepunten per uur, dag of maand” Beide metrieken zijn belangrijk, maar voor verschillende redenen/doelen.
  65. 65. 65 Wat willen we? Aanbieding t.b.v. een bid of PvA voor het project Zo goed mogelijk begroten van het project Methode: cost engineering begroting o.b.v. productiviteit Begroten van sprint X Planning poker Gebaseerd op velocity X-1 (X-2, X-3, etc.) Gedurende volledige project: Project control Bewaken van de geleverde features o.b.v. de actuals en de match op de ‘minimum releasable scope’ van de klant. Gebaseerd op bestede uren en opgeleverde features (FP en SP) Na afloop van project Performance measurement + benchmark + vastleggen data
  66. 66. 66 Begroten van een agile project Input: •Functionele documentatie (mag high-level) •Begrotingsparameters •doorlooptijd •team omvang •technische omgeving •onshore/offshore •activiteiten in scope/uit scope Output: •Functionele omvangmeting van de backlog, uitgedrukt in FP •Cost engineering begroting: aantal FP dat binnen doorlooptijd en uren gerealiseerd kan worden •Inschatting van de risico’s •Aanbeveling t.a.v. doorlooptijd/uren/FTE
  67. 67. 67 Sogeti en cost engineering Afdeling Shared SEC (Sizing, Estimating & Control) Gebundelde kennis, ervaring, skills, methoden, technieken, data, literatuur en tools op het gebied van software cost engineering. Sizing: FP, CFP, UCP, CP, IBRA, slocs, et cetera Data: Sogeti databases, ISBSG industry data Tools: QSM SLIM, Galorath SEER-SEM, Sogeti wizards Best in class als het gaat om begroten van IT projecten en beheer Al jarenlang betrokken bij de RVO’s binnen Sogeti. Externe opdrachten: o.a. KPN, Belastingdienst, ING, RDW, AEGON en vele andere. Ondersteunend aan de hele Sogeti organisatie.
  68. 68. 68 Conclusies De IT industrie is zeer onvolwassen als het gaat om begroten •Veel organisaties gebruiken alleen ‘expertbegroting’ •Dit leidt tot optimistische begrotingen (gem. 30%) •Resultaat: enorme overruns (non-liniair) Dit manifesteert zich vooral ook bij de overheid (focus op prijs). Realistisch begroten •Combineer expertbegroting en methodische begroting •Objectieve omvangbepaling, historische data, tooling Agile projecten zijn prima te begroten: op een andere manier •Hoeveel functionaliteit bij gegeven doorlooptijd/teamsize? •Objectieve omvangbepaling, historische data, tooling •Story points zijn alleen bruikbaar binnen sprints, niet voor het begroten van projecten.
  69. 69. Young Professional @Sogeti
  70. 70. 70 www.werkenbijsogeti.nl
  71. 71. Bedankt voor jullie aandacht! SEC@sogeti.nl
  72. 72. @haroldveendam Harold.van.heeringen@sogeti.nl Harold van Heeringen Senior Consultant Software Metrics /Software Cost Engineer Sogeti Sizing, Estimating & Control (SEC) President ISBSG (International Software Benchmarking Standards Group (www.isbsg.org)) Board member NESMA (Netherlands Software Metrics Association (www.nesma.nl)) IAC member COSMIC (www.cosmicon.com)

×