Methodisch Begroten
van software projecten

Hogeschool Rotterdam
5 november 2013
Harold van Heeringen
Software Cost Engineer, Sogeti Nederland B.V.
ISBSG president
NESMA bestuur
werkgroep COSMIC
werkgroe...
Introductie
•Het belang van het goed begroten van projecten;
•Het verschil tussen expert begroting en methodische begrotin...
Het belang van het goed begroten van projecten

4
Probleem: Software projecten

5
2 belangrijkste redenen
Instabiele user requirements
- Te weinig aandacht voor requirements analyse
- Te vroeg starten met...
Begroten van software
Zo denken veel klanten
erover als ze om een
begroting voor
softwarerealisatie vragen.
Het is belangr...
Waarom is een goede begroting belangrijk?
De begroting is basis voor:
• de business case;
• de planning;
• de aanbieding (...
Begroten in de IT
IT industrie: relatief jonge industrie
Lage volwassenheid op het gebied van begroten.
Druk vanuit klant/...
Wat is een goede begroting?
Een goede begroting is een plan dat de stakeholders voldoende
betrouwbaar vinden om te gebruik...
Overschatten/onderschatten
Non- Lineaire extra kosten
>100%

Planningsfouten
Vergroten team veel duurder maar nauwelijks ...
Traditioneel begroten

12
Traditioneel begroten
Start: klant stelt functionele documentatie op. De scope van het
project wordt bepaald door de besch...
Variability (%)

200

Feasibility
study

Requirements
specification

Software development

150

100

50

De kegel wordt ni...
Het verschil tussen Expert- en methodische begroting

15
2 typen begrotingen
1. Expertbegroting (technische calculatie)
Bottom-up , uren toekennen aan work items, kennis en ervari...
2 typen begrotingen
2. Methodische begroting (cost engineer)
Top-down o.b.v. objectieve omvangbepaling, relevante
producti...
Sogeti begrotingen
CoE expertbegroting
Functioneel ontwerper: F.O. uren
Technisch architect: coding +UT uren
Tester: testu...
Volwassen begrotingen
Waarom worden softwarerealisatie projecten vaak niet op een
volwassen manier begroot?
• In de meeste...
Methodische Begrotingen
1. Meet de functionele omvang van de ‘functional user
requirements’.
• ISO methodes NESMA, IFPUG o...
Meten van Functionele omvang
FPA en COSMIC meten alleen de Functional User
Requirements

Functional UR

Technical UR

Qual...
Functiepunt Analyse (FPA)

22
Wat is FPA
Uniforme methode om de aan de gebruiker
geboden en door de gebruiker gevraagde
hoeveelheid functionaliteit van ...
FPA en begroten
• Analogie: verven van een muur
•
•
•
•

Meten oppervlakte: 20 m2 (= omvang)
Gebruik penseel (1 m2 p.u)
Ge...
Functiepunt Analyse
Gebruikers

Transacties

IF

UF

Gegevensverzamelingen

ILGV

KGV

OF
25
Interne Logische Gegevens Verzameling ILGV
Een logische groep permanente gegevens
vanuit het gezichtspunt van de gebruiker...
Koppelings Gegevens Verzameling KGV
Een logische groep permanente gegevens
vanuit het gezichtspunt van de gebruiker die aa...
Invoerfunctie IF
Een unieke door de gebruiker onderkende
functie waarbij gegevens (data- en/of
besturingsinformatie) van b...
Uitvoerfunctie UF
Een unieke door de gebruiker onderkende
uitvoer die de systeemgrens passeert,
waarvan de omvang variabel...
Opvraagfunctie OF
Een unieke door de gebruiker onderkende invoer/
uitvoer combinatie waarbij de uitvoer, waarvan de
omvang...
Voorbeeld
Gevraagde functionaliteit
> Een overzicht met de geboortedata van de
medewerkers, gesorteerd op afdeling, maand,...
In de praktijk
Indicatieve FPA
Op basis van een conceptueel datamodel:
35 FP per systeemeigen object
15 FP per systeemvree...
Vraag
Je moet een hondenregistratie programma maken voor de
uitlaatservice van je buurvrouw. De requirements:
- Je kunt ho...
Antwoord: LGV’s
Je moet een hondenregistratie programma maken voor de
uitlaatservice van je buurvrouw. De requirements:
- ...
Antwoord: Invoerfuncties
Je moet een hondenregistratie programma maken voor de
uitlaatservice van je buurvrouw. De require...
Antwoord: Opvragingsfuncties
Je moet een hondenregistratie programma maken voor de
uitlaatservice van je buurvrouw. De req...
Hondenregistratie
Type

Aantal

FP

ILGV

3

21

KGV

0

0

IF

8

32

OF

3

12

UF

0

0

Totaal

65 FP

37
Productiviteit
De functionele omvang is bekend. Om een ruwe begroting te
maken vermenigvuldigen we de omvang met een ‘Proj...
Historische Data - ISBSG
International Software Benchmarking Standards Group
(ISBSG)
- Not for profit organisatie, verzame...
Ruwe Begroting
Hondenregistratie systeem: 65 FP
Min: 8 uur/FP * 65 FP = 520 uur
Likely: 11 uur/FP * 65 FP = 715 uur
Max: 1...
De impact van doorlooptijd (Putnam)

Inspanning

Omvang/productiviteit
= Inspanning1/3 * doorlooptijd4/3

Plan A: 6 maande...
Inspanning (uren)

Project bij verschillende doorlooptijden
A
Doorlooptijd: 6 maanden
Inspanning: 4.500 uur
Max. teamomvan...
Begrotingstools
Begrotingstools
- QSM SLIM
- Galorath SEER-SEM
- Op basis van input parameters, wordt een begroting vastge...
Hondenregistratie
Staffing & Probability Analysis
Avg Staff (people)
<Control Panel - Peak = 3,0>
3

4

5

6

78

3,5
3,0
...
Hondenregistratie – 3 fte
Staffing & Probability Analysis
Avg Staff (people)
<Control Panel - Peak = 3,0>
3

4

5

6

78

...
Hondenregistratie – 1 mnd
Staffing & Probability Analysis
Avg Staff (people)
<Single Goal - C&T Duration 1,0>
3

4

5

6

...
COSMIC FPA
•
•
•
•
•
•
•
•
•
•
•

Methode voor de bepaling van de functionele omvang van software
Bestaat sinds eind jaren...
COSMIC FPA

48
Data movements
E

Entry

verplaatst gegevens naar binnen

X eXit

verplaatst gegevens naar buiten

R Read

Alle Data Movem...
COSMIC voorbeeld
Functioneel proces:
Aanmaken nieuwe medewerker
Trigger: oproepkracht meldt zich
Persistent OOI
WERKNEMER
...
Begroten van agile projecten

Is de documentatie uit agile projecten geschikt om te meten
m.b.v. (traditionele) omvangbepa...
Is agile documentatie meetbaar?
Vaak: User stories.
Als een <type gebruiker> wil ik <iets doen> zodat ik <er iets aan heb>...
Agile projecten
Vaak gehoord: “Waarom begroten? We gaan starten, werken in
sprints en leveren de meeste waarde aan de klan...
De ijzeren driehoek
Functionaliteit

Kwaliteit

Geld/middelen

Tijd

Omdat het in agile projecten mogelijk is om de gewens...
Waterval vs. agile
Waterval projecten: Scope is ‘fixed’. Halen van doorlooptijd en
uren gaat vaak mis. Risico bij leveranc...
Begroten van agile projecten
De hamvraag: hoeveel functionaliteit moet er gemaakt worden en
hoeveel functionaliteit kunnen...
Story points
Relatieve omvangsmaat, meet de omvang van user stories t.o.v.
elkaar.
VB: Hondpunten (o.b.v. hoogte).
Ras

Ho...
Planning poker
Planning poker meeting met alle teamleden
Kaarten: 0,1,2,3,5,8,13,20,40 en 100 (voorbeeld)
Moment: Sprint 0...
Voordelen planning poker
“Planning is everything, plans are nothing.”
1.Discussie vanuit verschillende invalshoeken leidt ...
Ideal days vs actual days
Feature X: inschatting 3 dagen werk voor ontwikkelaar.
Vraag: hoe lang duurt dit in de praktijk?...
Onze visie

61
Typische size metrieken
Een story point is een arbitraire (maar intuïtieve) eenheid voor de
omvang van een feature {1,2,4,...
Productiviteit vs. velocity
Agile velocity ≈ productiviteit ?
Velocity is tactisch – “Hoeveel kunnen we realiseren in een ...
Velocity/Burn down charts

64
Wat willen we?
Aanbieding t.b.v. een bid of PvA voor het project
Zo goed mogelijk begroten van het project
Methode: cost e...
Begroten van een project
Input:
• Functionele documentatie (mag high-level)
• Begrotingsparameters
• doorlooptijd
• team o...
Case – SNS Bank RPU
Aanbieding het project RPU
Input:
• High level functional requirements;
• Team: 7 FTE;
• Max. offshore...
425 FP, 3 maanden

Functionaliteit vast
Doorlooptijd vast
Effort variabel

Staffing & Probability Analysis
D Act
R Act

Av...
7 FTE, 3 maanden

Functionaliteit variabel
Doorlooptijd vast
Effort vast

Staffing & Probability Analysis
D Act
R Act

Avg...
Project benchmark
Ook in agile projecten wordt functionaliteit gerealiseerd in
een x aantal uren met een doorlooptijd van ...
Sogeti en cost engineering
Afdeling Shared SEC (Sizing, Estimating & Control)
Gebundelde kennis, ervaring, skills, methode...
Bedankt voor
jullie aandacht!
SEC@sogeti.nl
Harold van Heeringen
Senior Consultant Software Metrics /Software Cost Engineer
Sogeti Sizing, Estimating & Control (SEC)
...
Upcoming SlideShare
Loading in …5
×

Begroten van software projecten - Hogeschool Rotterdam gastcollege 05-11-2013

667 views

Published on

Inleiding/basics begroten van software projecten. Verschillen tussen waterval en agile projecten en de manier waarop deze begroot moeten worden.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
667
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
18
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Begroten van software projecten - Hogeschool Rotterdam gastcollege 05-11-2013

  1. 1. Methodisch Begroten van software projecten Hogeschool Rotterdam 5 november 2013
  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. Introductie •Het belang van het goed begroten van projecten; •Het verschil tussen expert begroting en methodische begroting; •Traditioneel begroten (waterval); •FPA overview en COSMIC overview; + eenvoudige oefening; •Historische data en ervaringscijfers; •Begroten van agile projecten in de praktijk; •Benchmarking en performance measurement van afgeronde projecten; 3
  4. 4. Het belang van het goed begroten van projecten 4
  5. 5. Probleem: Software projecten 5
  6. 6. 2 belangrijkste redenen 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 6
  7. 7. 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! 7
  8. 8. Waarom is een goede begroting belangrijk? De begroting is basis voor: • de business case; • de planning; • de aanbieding (RVO; winst/verlies); • voortgangsrapportages; • het financieel resultaat van het project; • het vastleggen/vrijgeven van resources; • ‘alignment’ met de business/klant; • et cetera! 8
  9. 9. 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. 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! 9
  10. 10. Wat is een goede begroting? Een goede begroting is een plan dat de stakeholders voldoende betrouwbaar vinden om te gebruiken als 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. 10
  11. 11. Overschatten/onderschatten Non- Lineaire extra kosten >100% Planningsfouten Vergroten team veel duurder maar nauwelijks sneller Extra Kosten Extra management attentie/overhead Stress: Meer defects, lagere onderhoudbaarheid Lineaire extra kosten Extra uren worden besteed Onderschatten Overschatten 0% Te lage schattingen Realistische schattingen Te hoge schattingen 11
  12. 12. Traditioneel begroten 12
  13. 13. 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 13
  14. 14. Variability (%) 200 Feasibility study Requirements specification Software development 150 100 50 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. Slecht begroot of slecht beheerst project Project closure Cone of uncertainty 0 -50 14
  15. 15. Het verschil tussen Expert- en methodische begroting 15
  16. 16. 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) 16
  17. 17. 2 typen begrotingen 2. Methodische begroting (cost engineer) 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 17
  18. 18. Sogeti begrotingen CoE expertbegroting Functioneel ontwerper: F.O. uren Technisch architect: coding +UT uren Tester: testuren Projectleider: PL uren Challenge Cost engineering begroting (SEC) Omvangmeting (FP / CFP) Methodische begroting - Uren, doorlooptijd, FTE, kosten - Scenario’s - Risico’s Aanbieding Aanbieding ABF ABF Plan van Plan van aanpak aanpak 18
  19. 19. 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 … soms zelfs slechte kwaliteit. En dat terwijl er voldoende cost engineering methoden, technieken en tools voorhanden zijn om projecten onderbouwd en verdedigbaar te begroten! 19
  20. 20. 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 999 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 20
  21. 21. Meten van Functionele omvang FPA en COSMIC meten alleen de Functional User Requirements Functional UR Technical UR Quality UR User Requirements Voordelen: - Kan vroegtijdig worden toegepast (Requirements analyse) - Omvang is onafhankelijk van techniek en implementatie 21
  22. 22. Functiepunt Analyse (FPA) 22
  23. 23. 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 23
  24. 24. FPA en begroten • Analogie: verven van een muur • • • • Meten oppervlakte: 20 m2 (= omvang) Gebruik penseel (1 m2 p.u) Gebruik kwast (2 m2 p.u) Gebruik roller (5 m2 p.u) aantal uren afhankelijk van omvang en productiviteit • Realiseren van een informatiesysteem • Omvang op basis van functiepunten • Productiviteit uit ervaringscijfers/benchmarks • aantal uren afhankelijk van omvang en productiviteit 24
  25. 25. Functiepunt Analyse Gebruikers Transacties IF UF Gegevensverzamelingen ILGV KGV OF 25
  26. 26. Interne Logische Gegevens Verzameling ILGV Een logische groep permanente gegevens vanuit het gezichtspunt van de gebruiker die aan elk van de volgende criteria voldoet: – Wordt gebruikt door het te tellen informatiesysteem – Wordt onderhouden door het te tellen informatiesysteem Voorbeelden: Klant Order 26
  27. 27. Koppelings Gegevens Verzameling KGV Een logische groep permanente gegevens vanuit het gezichtspunt van de gebruiker die aan elk van de volgende criteria voldoet: – Wordt gebruikt door het te tellen informatiesysteem – Wordt niet onderhouden door het te tellen informatiesysteem – Wordt wel door een ander informatiesysteem onderhouden – Is direct benaderbaar door het te tellen systeem Voorbeelden: >Kredietbestand BKR >Kentekentabel RDW 27
  28. 28. Invoerfunctie IF Een unieke door de gebruiker onderkende functie waarbij gegevens (data- en/of besturingsinformatie) van buiten het informatiesysteem naar binnen worden gehaald. De functie moet door de gebruiker als een elementaire functie worden gezien. Voorbeelden: >Toevoegen klant >Wijzigen order >Verwijderen verzekering 28
  29. 29. Uitvoerfunctie UF Een unieke door de gebruiker onderkende uitvoer die de systeemgrens passeert, waarvan de omvang variabel is of waarvoor verdere gegevensverwerking nodig is. De functie moet door de gebruiker als een elementaire functie worden gezien. Voorbeelden: >Het printen van een overzicht met daarop de omzet en winst per maand. 29
  30. 30. Opvraagfunctie OF Een unieke door de gebruiker onderkende invoer/ uitvoer combinatie waarbij de uitvoer, waarvan de omvang volledig bepaald is, zonder verdere gegevensverwerking, naar aanleiding van de invoer door het informatiesysteem wordt verstrekt. De functie moet door de gebruiker als een elementaire Functie worden gezien. Voorbeeld: >Opvragen medewerkergegevens op medewerkernummer 30
  31. 31. Voorbeeld Gevraagde functionaliteit > Een overzicht met de geboortedata van de medewerkers, gesorteerd op afdeling, maand, dag Benodigde gegevens: > medewerker : > afdeling : naam, geboortedatum afdelingsnaam 1-5 6 - 19 0-1 E(4) E(4) G(5) 2 -3 E(4) G(5) M(7) >3 G(5) M(7) M(7) Soort functie: > Uitvoerfunctie 2 gerefereerde LGV : 3 gerefereerde DET : > Complexiteit Eenvoudig 4fp > 19 31
  32. 32. 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 b a n d b r e e d t e > 50% 15 - 25 % 10 - 15 % Definitie studie Basis ontwerp Functioneel Detail Ontwerp tijd Detail ontwerp Realisatie 32
  33. 33. 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) 33
  34. 34. 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 34
  35. 35. 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 35
  36. 36. 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 Raadplegen ?? Raadplegen ?? 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?? 36
  37. 37. Hondenregistratie Type Aantal FP ILGV 3 21 KGV 0 0 IF 8 32 OF 3 12 UF 0 0 Totaal 65 FP 37
  38. 38. 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) 38
  39. 39. Historische Data - ISBSG International Software Benchmarking Standards Group (ISBSG) - 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. 39
  40. 40. 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 Stel: er is een team van 3 fte beschikbaar om dit uit te voeren. De klant wil het hebben binnen 1 maand. Lukt dit? 40
  41. 41. De impact van doorlooptijd (Putnam) Inspanning Omvang/productiviteit = Inspanning1/3 * doorlooptijd4/3 Plan A: 6 maanden, 4.500 uur Plan B: 7 maanden, 2.400 uur Doorlooptijd 41
  42. 42. Inspanning (uren) Project bij verschillende doorlooptijden 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 Doorlooptijd 42
  43. 43. 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 43
  44. 44. Hondenregistratie Staffing & Probability Analysis Avg Staff (people) <Control Panel - Peak = 3,0> 3 4 5 6 78 3,5 3,0 2,5 2,0 1,5 1,0 Avg Staff (people) Milestones 0 - CSR 1 - SRR 2 - HLDR 3 - LLDR 4 - CUT 5 - IC 6 - STC 7 - UAT 8 - FCR 9 - 99R 10 - 99.9R 0,5 0,0 1 okt '13 nov RISK GAUGE Duration Effort Peak Staff Quality % 0 <Control Panel - Peak = 3,0> 10 20 30 40 50 60 <No constraints> 70 80 90 100 SOLUTION PANEL - <Control Panel - Peak = 3,0> C&T Life Cycle Duration 1,7 1,7 Months Effort 739 739 MHR Cost 73,9 73,9 EUR (K) Peak Staff 3,0 3,0 people MTTD 2,670 2,670 Day s Start Date 1-11-2013 1-11-2013 PI=17,4 MBI=7,7 Eff FP=65 Max. 3 fte, 65 FP, 1 maand lukt niet dec CONTROL PANEL <Control Panel - Peak = 3,0> 17,4 14,0 3,0 20,9 PI 2,4 3,6 Peak Staff 65 52 78 Eff FP 44
  45. 45. Hondenregistratie – 3 fte Staffing & Probability Analysis Avg Staff (people) <Control Panel - Peak = 3,0> 3 4 5 6 78 3,5 3,0 2,5 2,0 1,5 1,0 Avg Staff (people) Milestones 0 - CSR 1 - SRR 2 - HLDR 3 - LLDR 4 - CUT 5 - IC 6 - STC 7 - UAT 8 - FCR 9 - 99R 10 - 99.9R 0,5 0,0 1 okt '13 nov RISK GAUGE Duration Effort Peak Staff Quality % 0 <Control Panel - Peak = 3,0> 10 20 30 40 50 60 <No constraints> 70 80 90 100 SOLUTION PANEL - <Control Panel - Peak = 3,0> C&T Life Cycle Duration 1,7 1,7 Months Effort 739 739 MHR Cost 73,9 73,9 EUR (K) Peak Staff 3,0 3,0 people MTTD 2,670 2,670 Day s Start Date 1-11-2013 1-11-2013 PI=17,4 MBI=7,7 Eff FP=65 Max. 3 fte, 65 FP, 1 maand lukt niet dec CONTROL PANEL <Control Panel - Peak = 3,0> 17,4 14,0 3,0 20,9 PI 2,4 3,6 Peak Staff 65 52 78 Eff FP 45
  46. 46. Hondenregistratie – 1 mnd Staffing & Probability Analysis Avg Staff (people) <Single Goal - C&T Duration 1,0> 3 4 5 6 7 8 40 Milestones 0 - CSR 1 - SRR 2 - HLDR 3 - LLDR 4 - CUT 5 - IC 6 - STC 7 - UAT 8 - FCR 9 - 99R 10 - 99.9R 30 10 Avg Staff (people) 20 0 1 okt '13 nov RISK GAUGE Duration Effort Peak Staff Quality % 0 <Single Goal - C&T Duration 1,0> 10 20 30 40 50 60 70 <No constraints> 80 90 100 SOLUTION PANEL - <Single Goal - C&T Duration 1,0> C&T Life Cycle Duration 1,0 1,0 Months Effort 6.037 6.037 MHR Cost 603,7 603,7 EUR (K) Peak Staff 34,9 34,9 people MTTD 0,505 0,505 Day s Start Date 1-11-2013 1-11-2013 PI=17,4 MBI=13,0 Eff FP=65 Max. 35 fte, 65 FP, 1 maand lukt ‘wel’ dec CONTROL PANEL <Single Goal - C&T Duration 1,0> 17,4 14,0 34,9 20,9 PI 27,9 41,9 Peak Staff 65 52 78 Eff FP 46
  47. 47. COSMIC FPA • • • • • • • • • • • Methode voor de bepaling van de functionele omvang van software Bestaat sinds eind jaren ’90 ISO standaard, objectief, herhaalbaar, verifieerbaar Open standaard, gratis documentatie Beter geschikt voor moderne ontwikkelmethodieken dan FPA Beter geschikt om moderne architecturen te begroten dan FPA Ook geschikt voor traditionele ontwikkelmethodieken en architecturen Realtime / embedded software Mobile apps, cloud Modernere methode dan FPA, maar nog weinig ingeburgerd in NL Vooral groot in Canada, Turkije, Polen, India, Frankrijk 47
  48. 48. COSMIC FPA 48
  49. 49. Data movements E Entry verplaatst gegevens naar binnen X eXit verplaatst gegevens naar buiten R Read Alle Data Movements: 1 CFP verplaatst gegevens vanuit opslag W Write verplaatst gegevens naar opslag Functioneel proces E R W X Generiek Software Model Notitiewijze sluit aan bij UML - Activity Diagram 49
  50. 50. COSMIC voorbeeld Functioneel proces: Aanmaken nieuwe medewerker Trigger: oproepkracht meldt zich Persistent OOI WERKNEMER FUNCTIE Attributen Nr, naam, adres, datum in dienst, functiecode functiecode, omschrijving, salaris schaal Data Movement Entry {Werknemergegevens} Read FUNCTIE Write WERKNEMER Exit {Werknemergegevens} Exit {Meldingen} Data group naam, adres, functiecode functiecode naam, adres, datum in dienst, functiecode Werknemernr. boodschap (fout / bevestiging) 5 COSMIC FP 50
  51. 51. Begroten van agile projecten Is de documentatie uit agile projecten geschikt om te meten m.b.v. (traditionele) omvangbepalingsmethoden? 51
  52. 52. 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. 52
  53. 53. 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? 53
  54. 54. De ijzeren driehoek Functionaliteit Kwaliteit Geld/middelen Tijd Omdat het in agile projecten mogelijk is om de gewenste functionaliteit tussentijds te wijzigen, moet één van de zijden variabel zijn, anders gaat het ten kosten van de kwaliteit. 54
  55. 55. 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?). 55
  56. 56. 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? 56
  57. 57. Story points Relatieve omvangsmaat, meet de omvang van user stories t.o.v. elkaar. VB: Hondpunten (o.b.v. hoogte). Ras Hondpunten Poedel 5 Schnautzer 6 Duitse herder Chihuahua 10 2 Labrador 11 Sint Bernhard 12 Bulldog 7 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 57
  58. 58. 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. 58
  59. 59. 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. 59
  60. 60. Ideal days vs actual days Feature X: inschatting 3 dagen werk voor ontwikkelaar. Vraag: hoe lang duurt dit in de praktijk? • Andere taken (b.v. support huidige release) • Meetings • Reistijd tussen kantoren • Stand-ups, koffie, wc, pauze, vragen collega’s • Telefoon, e-mail • Training, • Ziekte, vakantie? Niemand is 8 uur per dag volledig productief. In de praktijk zal de ontwikkeling van feature X eerder 4 of 5 dagen duren! 60
  61. 61. Onze visie 61
  62. 62. 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 eenheid voor de omvang van een feature vanuit een functioneel perspectief. Lines of code (LOC) is een eenheid voor de omvang van een feature vanuit een fysiek perspectief. 62
  63. 63. 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. 63
  64. 64. Velocity/Burn down charts 64
  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 65
  66. 66. Begroten van een 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 66
  67. 67. Case – SNS Bank RPU Aanbieding het project RPU Input: • High level functional requirements; • Team: 7 FTE; • Max. offshore; • Java; • Klant wil op 15 december een werkende en zinvolle applicatie; • Geen prioritering. SEC: size = 425 FP (indicatieve FPA: 225 > 425 > 635 FP). 67
  68. 68. 425 FP, 3 maanden Functionaliteit vast Doorlooptijd vast Effort variabel Staffing & Probability Analysis D Act R Act Avg Staff (people) <Single Goal - Life Duration 3,5 incl FO> 1 2 3 4 5 6 20 15 10 Avg Staff (people) Milestones 1-1#6 2-2#6 3-3#6 4-4#6 5-5#6 6-6#6 5 0 1 jul '13 aug RISK GAUGE <Single Goal - Life Duration 3,5 incl FO> Duration Effort Peak Staff Quality % 0 10 20 30 40 50 60 <No constraints> 70 80 90 100 sep 2 okt SOLUTION PANEL - <Single Goal - Life Duration 3,5 incl FO> R Act Life Cycle Duration 3,4 3,5 Months Effort 7.925 10.779 MHR Cost 673,7 916,2 EUR (K) Peak Staff 17,0 23,1 people MTTD 0,468 0,468 Day s Start Date 2-9-2013 2-9-2013 PI=18,6 MBI=7,4 Eff FP=425 3 nov dec CONTROL PANEL <Single Goal - Life Duration 3,5 incl FO> 18,6 14,9 17,0 22,3 PI 13,6 20,4 Peak Staff 425 340 510 Eff FP 68
  69. 69. 7 FTE, 3 maanden Functionaliteit variabel Doorlooptijd vast Effort vast Staffing & Probability Analysis D Act R Act Avg Staff (people) <Control Panel - Peak = 7,0, incl fo> 1 2 3 4 5 6 6 5 3 2 Avg Staff (people) 4 Milestones 1-1#6 2-2#6 3-3#6 4-4#6 5-5#6 6-6#6 1 0 1 jul '13 aug RISK GAUGE - <Control Panel - Peak = 7,0, incl fo> Duration Effort Peak Staff Quality % 0 10 20 30 40 50 60 <No constraints> 70 80 90 100 sep 2 okt SOLUTION PANEL - <Control Panel - Peak = 7,0, incl fo> R Act Life Cycle Duration 3,5 3,5 Months Effort 2.477 3.369 MHR Cost 210,6 286,4 EUR (K) Peak Staff 5,2 7,0 people MTTD 0,977 0,977 Day s Start Date 2-9-2013 2-9-2013 PI=18,8 MBI=6,0 Eff FP=343 3 nov dec CONTROL PANEL <Control Panel - Peak = 7,0, incl fo> 18,8 15,0 5,2 22,6 PI 4,1 6,2 Peak Staff 343 274 411 Eff FP Is 343 FP genoeg voor de ‘minimum releasable scope’? 69
  70. 70. Project benchmark Ook in agile projecten wordt functionaliteit gerealiseerd in een x aantal uren met een doorlooptijd van een y aantal maanden. Benchmark is zeker mogelijk! Speed of Delivery vs Effective FP PI vs Omvang (FP) 800 30 25 600 400 PI 15 200 Project X Speed of Delivery 20 10 0 5 0 100 200 300 400 500 600 700 800 900 0 1.000 0 100 200 300 Microsoft Totaal Special Project QSM Business Avg. Line Style 500 600 700 800 900 -200 1.000 Effective FP Omvang (FP) Microsoft New Developmen... 400 Special Project QSM Business Avg. Line Style 1 Sigma Line Style 1 Sigma Line Style 70
  71. 71. 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. Nu ondersteunend aan de hele Sogeti organisatie. 71
  72. 72. Bedankt voor jullie aandacht! SEC@sogeti.nl
  73. 73. Harold van Heeringen Senior Consultant Software Metrics /Software Cost Engineer Sogeti Sizing, Estimating & Control (SEC) @haroldveendam Harold.van.heeringen@sogeti.nl 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)

×