When clients outsource their software development projects, they need to make sure that these suppliers don't overprice the projects. As it is often not longer possible to select the best offer, there should be another mechanism to measure the value that they are getting in comparison to the money they are paying. Supplier Performance Measurement enables clients to keep in control of theis project costs in outsourcing situations and to negotiate performance improvements with the suppliers.
4. 4
Supplier Performance Measurement
• Organisaties besteden IT ontwikkeling en
beheer uit aan 1 leverancier
• Deze ene leverancier wordt gekozen o.b.v.
diverse criteria, bijvoorbeeld:
− Omvang en schaalbaarheid
− Technische en functionele domeinkennis
− Bereidheid te investeren in verbetering
− Beloften v.w.b. productiviteitsverbetering
− Transparantie en voorspelbaarheid
• Leverancier moet meten en openheid geven
5. 5
SPM – 3 fasen
1. Selectie van de juiste leverancier
− Kwalitatieve criteria
− Kwantitatieve criteria
2. Vaststellen baseline productiviteit en prijs per
UoM per domein
3. Voortdurend meten van prestaties van
leverancier
6. 6
Typische vragen in RFP fase SPM
• Wat is uw productiviteit in Java projecten?
• Wat is het percentage productiviteitswinst dat u
de komende x jaar gaat realiseren?
• Hoe gaat u deze productiviteitswinst realiseren?
• Op welke manier stelt u voor om de
productiviteit te meten?
7. 7
Hoe word je de ‘chosen one’
• Volwassenheid
− Minimum CMMI level 3, liefst hoger
• Hoge en aantoonbare productiviteit en kwaliteit
− Kennis en vaardigheden medewerkers
− Efficiënte en effectieve processen, beperkte overhead
• Flexibel en meedenkend
− Snel kunnen schakelen is een vereiste
− Inhoudelijk advies wordt verwacht
• Beloftes doen en nakomen
− Basis is vertrouwen en transparantie
− Meten en rapporteren van productiviteit en kwaliteit
8. 8
Volwassenheid (CMMI)
• Vanaf CMMI level 3 zijn processen voldoende
gedefinieerd en beschreven in standaards,
procedures, tools en methodes
10. 10
Functiepunten
• In de meeste SPM trajecten komen de volgende
zaken terug:
− Unit of Measurement (UoM): b.v. functiepunten
− Productiviteit (PDR = uren per functiepunt)
− Kwaliteit (#defects per functiepunt na oplevering)
• Waarom functiepunten?
− Functionaliteit is wat gebruiker wil
− Meer functionaliteit mag meer kosten
• Alternatief: regels code (technisch)
− Is regels code wat de gebruiker wil?
− Meer regels code betekent niet meer functionaliteit
11. 11
Functiepunten
• Functiepuntanalyse
− Objectief (ISO standaard)
− Herhaalbaar
− Verifieerbaar
• Kwantificeert de omvang van de functional user
requirements
− Onafhankelijk van de technologie
− Onafhankelijk van de implementatie
• Zegt niets over non-functionals
12. 12
Technologie onafhankelijk
• Applicatie A
− Omvang = 500 FP
− Technologie: Java
− Architectuur stand alone
• Applicatie B
− Omvang = 500 FP
− Technologie: Cobol / .NET
− Architectuur SOA
• Omvang is hetzelfde, maar productiviteit niet!
Applicatie A
Applicatie B
Uren besteed: 3.000
= 6 uur/FP
Uren besteed: 6.000
= 12 uur/FP
13. 13
Productiviteit (uur/FP) – organisatie specifiek
• Kennis en vaardigheden van de mensen
− Ervaring
− Certificering in technische omgevingen
− Bijscholingsmogelijkheden
• Volwassenheid van de organisatie
− Aanwezigheid kwaliteitssysteem
− Processen, procedures, standaarden
• Overhead
− Hoeveel tijd wordt gespendeerd aan activiteiten als
urencodes regelen, boeken van uren, vergaderingen, etc.
• Locatie en facilities
− Onshore / offshore (veel video overleg)
− Prettige werkomgeving, goede tools, etc.
14. 14
Productiviteit (uur/FP) – project specifiek
• Afhankelijk van technische requirements
− Java, Oracle of MS.NET
− Client/server of SOA architectuur
• Afhankelijk van kwaliteit requirements
− Performance eisen
− Security eisen
• Afhankelijk van uit te voeren activiteiten
− Wel of geen performance test
− Wel of geen handleiding als deliverable
• Afhankelijk van doorlooptijd
− Hoe korter de doorlooptijd, hoe lager de productiviteit
15. 15
Het effect van doorlooptijd
Omvang/productiviteit
= Inspanning1/3 * doorlooptijd4/3
Inspanning
Doorlooptijd
Plan A: 6 maanden, 4.500 uur
Plan B: 7 maanden, 2.400 uur
22. 22
Scope bepaling SPM
• Welke domeinen?
• Welke applicaties?
• Welke technologieën?
• Welke activiteiten?
− Nieuwbouw
− Adaptief onderhoud
− Correctief onderhoud
• Welke meetmomenten?
− Voor handover aan leverancier: reality check
− Voor handover aan klant: performance measurement
• Projectactiviteiten in en uit scope
23. 23
Documentatie scan en UoM
• Documentatie scan
− Kwaliteit en meetbaarheid documentatie
− Welke UoM is geschikt
− Moet documentatie worden aangepast om meetbaarheid te
vergroten?
• UoM in contracten:
− Objectief, herhaalbaar, verifieerbaar
− Maat voor functionaliteit
− Functiepunten, tenzij niet mogelijk n.a.v. documentatie
scan
24. 24
Performance metrieken (voorbeelden)
• Productiviteit:
− Project Delivery Rate (Uur/UoM)
− Productivity Index (PI)
− FP per manmaand
• Kwaliteit:
− Defects/UoM totaal
− Defects/UoM opgeleverd aan klant (A-test + productie)
− %Defects opgeleverd aan klant
• Snelheid (Time to market)
− UoM per kalendermaand
− Schedule conformance
26. 26
Organisatorische inrichting
• Nieuw organisatie onderdeel of rol: metrics desk
• Management commitment
• Proces eigenaarschap
• Training
• Awareness sessies
• Communicatie
27. 27
Proces op hoofdlijnen
Klant
-Feasibility study
-Requirements
-analysis
-Requirements
-design
-Global functional
-design
SOW based on
UoM and
historical data
Performance
measurement
Leverancier
-Detailed
-functional design
-Technical design
-Coding +
-programmer test
-Systems test
-Delivery to klant
Klant
-System integration
-test
-User acceptance
-test
-Implementation
36. 36
Conclusies
• Inrichten SPM is niet eenvoudig en kan alleen bij
voldoende volwassenheid
• Meten productiviteit(sverbetering) vergt
inspanning van zowel leverancier als klant
• Keuze leverancier gaat verder dan kijken naar
prijs en/of totale productiviteit
• Inrichten SPM is omvangrijke operatie die een
behoorlijke inspanning en doorlooptijd vergt