Is Correct begroten van softwareontwikkeling/- onderhoud toch mogelijk? Software Sizing, Estimating, Control en Benchmarking

Transcriptie

1 Is Correct begroten van softwareontwikkeling/- onderhoud toch mogelijk? Software Sizing, Estimating, Control en Benchmarking

2 Verwachtingen NGI Uitnodiging NGI 20 april 2006 Software sizing Estimating, control, benchmarking 70 % projecten niet volgens verwachting RAD, RUP, DSDM, webapplicaties, ERP FPA technieken Hulpmiddelen om te begroten (SLIM) Praktijkvoorbeelden Randvoorwaarden Baten van de aanpak voor verschillende partijen: opdrachtgever, opdrachtnemer, ontwikkelaar.financiële controller, inkoper, klant, management

3 Wie van u is in staat om goed te begroten? Transparant Herhaalbaar Gebaseerd op een product (omvang) Onzekerheden Kwaliteit Tijdsdruk Wijzigingen tijdens de ontwikkeling (of heeft u die niet?) Complexiteit Ontwikkelomgevingen Industrie (administratief financieel, overheid, Telecom, scientific, control, real time? ) Pakket implementaties (SAP, Siebel.)

4 Agenda wie is QSM welke dienstverlening welke klanten Hoe werkt QSM Omvang Begroten Pauze Demonstratie Estimate, Control en Benchmark Baten van de aanpak voor verschillende partijen valkuilen, waarheden, onzin van metrics wat kan QSM wel en niet

5 Wie is QSM? Quantitative Software Management Een Bedrijf en een Concept WAT IS ONS DOEL? Software ontwikkeling / inkoop nauwkeurig te begroten, te monitoren om daarmee risico s van software ontwikkeling te managen HOE DOEN WIJ HET? Door Hulpmiddelen, Scholing en Expertise te leveren

6 Historie QSM? QSM inc. opgericht in 1978 door Lawrence Putnam Ex-officier US-Army, Statisticus, Ontwikkelde het SLIM model Industriedatabase >7200 projecten 4 e generatie architectuur tools QSM Europe opgericht in 1994 door Hans Vonk Econoom, bestuurlijke informatiekunde Metrics specialist Managing Partner QSM Europa FPA Expertise Centrum opgericht in 2002 Voorzitter NESMA

7 Wat Biedt QSM? SOFTWARE MANAGEMENT HULPMIDDELEN SLIM Estimate SLIM Control SLIM Metrics FPA Scope Manager OPLEIDING en TRAINING QSM in SW Ontwikkeling QSM in het SW Inkoop Proces QSM Introductie voor Managers FPA (Intro, Basis, FPAi, Certificering, workshops) EXPERTISE/CONSULTANCY Software project planning Software project monitoring en rapportage Software benchmarking Metrics implementatie FPA Consultancy / outsourcing

8 Klanten

9 Quantitative Software Management Hoe QSM Werkt

10 Succesvol begroten en bijsturen van projecten Productiviteit Omvang Estimate Randvoorwaarden: - Budget -Tijd - Kwaliteit -Staf Voortgangsdata Plan -Omvang - Mijlpalen - Fasen -Defects - inspannin Metrics Post Project Analyse Project evaluatie data Control Voortgang, Impact Afwijkingen

11 Veel gestelde vragen Wat is het verschil tussen omvang en begroten? Waarom is omvang belangrijk? Wat is de relatie tussen omvang, doorlooptijd, inspanning en kwaliteit? Wanneer is een project gereed om te worden opgeleverd?

12 Verschil Omvang en Begroten Omvang is het meten van de grootte van een product in kleine gelijkvormige eenheden. (vergelijk aantal m3 van een bedrijfspand) Begroten is het voorspellen van de benodigde inspanning, de kosten, de doorlooptijd en de kwaliteit om een product te maken op basis van omvang en ervaringscijfers. (vergelijking: de kosten om een luxe bedrijfspand in Breukelen te bouwen zijn bv euro per m3, inclusief bestrating etc. en heeft een doorlooptijd van 6 maanden nadat het ontwerp door de gemeente is goedgekeurd)

13 Quantitative Software Management Omvang

14 Omvang Omvang is essentieel om historie op te bouwen en om vervolgens herhaalbaar en transparant te kunnen begroten (omvang kan bv. worden uitgedrukt in regels sourcecode, functiepunten, use-cases, requirements, componenten etc.)

15 Wanneer tijdens een project kan Omvang worden gemeten? Omvang kan vanaf de start van een project worden bepaald. Onzekerheid in omvang is een vorm van risico en is zeker in een vroeg stadium in een project een natuurlijk gegeven, maar kan worden gebruikt om de reserve binnen begrotingen te berekenen. (Onzekerheid kan worden uitgedrukt in een range, bv. Min. 100, Verw. 300 en Max eenheden)

16 In welke gevallen kan de Omvang worden bepaald? In alle gevallen waarbij software wordt ontwikkeld, onderhouden, geïmplementeerd, dus ook bij: DSDM, RUP, RAD, WEB, ERP Pakketten (SAP, SIEBEL..) Technische ontwikkeling, Control, Real time, Systeem, Embedded, Telecom

17 Waarom Omvang? Beschrijft het product Basis voor transparantie Basis voor opbouw historische projectendatabase Basis voor herhaalbare begrotingen Basis voor contract met opdrachtgever Basis voor beoordeling kwaliteit basisdocumenten (requirements, basisontwerp, technische ontwerp) Basis voor Project- en Scope Management

18 Waarom FPA? Wereldwijde ISO gecertificeerde standaard Uitstekende methode om omvang herhaalbaar vast te stellen Onafhankelijk van de techniek, ontwikkelmethoden en hulpmiddelen, industrieën, Geeft een functionele, op het gebruik gerichte methode en biedt daarom een goede basis om met de opdrachtgever te bespreken Voldoende ervaringscijfers bekend om te gebruiken bij het begroten

19 Waarom wordt FPA onvoldoende gebruikt? FPA kan niet 1 op 1 worden vertaald in kosten en doorlooptijd (Er is dus geen betrouwbare, eenvoudige norm om te begroten zoals uren/functiepunt, ranges tussen de 3 en 100 uur per functiepunt) Arbeidsintensief Wordt niet gezien als vak Wordt onvoldoende gewaardeerd Onvoldoende experts beschikbaar Vooroordelen door onvoldoende kennis oude standaard, Zou niet objectief en vergelijkbaar zijn (verschillende interpretaties) Zou niet geschikt zijn voor nieuwe methode en technieken Zou niet geschikt zijn voor technische omgevingen Zou niet geschik zijn voor pakketimplementaties Zou niet geschikt zijn voor onderhoud

20 Quantitative Software Management Estimate, Control en Benchmarking

21 Succesvol begroten en bijsturen van projecten Productiviteit Omvang Estimate Randvoorwaarden: - Budget -Tijd - Kwaliteit -Staf Voortgangsdata Plan -Omvang - Mijlpalen - Fasen -Defects - inspannin Metrics Post Project Analyse Projectevaluatie data Control Voortgang, Impact Afwijkingen

22 Ken U Doelen en realiseer ze Op tijd leveren Binnen budget leveren Leveren wat beloofd is Betrouwbare Producten

23 Om Software Management Doelen te kunnen realiseren Meten is het sleutel woord Indien u niet meet, kunt u het niet managen!

24 Er zijn honderden mogelijke factoren en elke omgeving is uniek Management Specificatie Gebruikers Training Methoden Hulpmiddelen Meer dan 175 factoren onderkend Technieken Scholing We moeten in het factoren vinden die Praktisch en Bruikbaar zijn

25 QSM Identificeert Drie Praktische en Bruikbare Ontwikkel Proces Factoren Software Product - Hoe groot? Software Proces - Hoe Efficiënt? Doorlooptijd - Hoeveel Tijdsdruk

26 De Belangrijkste Ontwikkel Proces Factoren die Tijd, Effort en Betrouwbaarheid Verklaren Belangrijkste Management Factoren Proces Factor Tijd Totale Effort Fouten roduct Omvang roductiviteit ijdsdruk

27 De Belangrijkste Ontwikkel Proces Factoren die Tijd, Effort en Betrouwbaarheid Verklaren RELATIES MOETEN GEKWANTIFICEERD WORDEN OM BRUIKBAAR TE ZIJN Belangrijkste Management Factoren Proces Factor Tijd Totale Effort Fouten Produkt Omvang Productiviteit Tijdsdruk

28 Hoe Kunnen We deze relaties Kwantificeren? Verzamel empirische gegevens en analyseer ze!

29 Gegevens tonen de Relaties Ontwikkeltijd neemt toe met produkt omvang Dezelfde trend is waarneembaar voor effort en fouten Duration, Effort, Discovered Defects vs. Size Duration vs. Size QSM Database Effective SLOC (thousands) 10 1 Months Effort vs. Size QSM Database Effective SLOC (thousands) 10 1 Person-Months Discovered Defects vs. Size QSM Database Effective SLOC (thousands) 10 1 Discovered Defects Quantitative Software Management, Inc. #23

30 Gegevens tonen de Relaties Produkt Omvang Team Effort Projekt Tijd Kwaliteit / Betrouwbaarheid QSM Heeft de Relaties Gekwantificeerd

31 QSM Heeft de Relaties Gekwantificeerd Larry Putnam, oprichter van QSM, definieerde de QSM Software Proces Model ook bekend als Software LIifecycle Management of SLIM Model

32 SLIM : De QSM Software Proces Vergelijking is gebaseerd op gegevens OMVANG INSPANNING DOORLOOPTIJD Staf PP = ESLOC / [((PM/12)/B)^1/3*((Maanden/12))^4/3] Piek Stijging Daling Tijd

33 SLIM Gebruikt Twee Belangrijke Proces Parameters PI - De Productiviteits Index Meet de efficiency van het software ontwikkel proces Management schaal 1-40 MBI -De Manpower Buildup Index Meet de tijdsdruk op de software ontwikkelingen 14 punts management schaal Omvat alle type software en alle ontwikkel methoden. Is gebaseerd op gegevens van meer dan 7200 actuele software projecten.

34 PI is de QSM Proces Productiviteits Index Alle Factoren die de Productiviteit Beïnvloeden Management Specificatie Gebruikers Training Methoden Hulpmiddelen Meer dan 175 factoren onderkend Technieken Uniek voor elke omgeving Scholing

35 QSM Proces Productiviteits Index Invloed: Administratieve omgeving Omvang = 500 FP JAVA Mens Jaar = euro Productiviteits Index Effort Tijd Kosten Hoog Laag ,

36 QSM Proces Productiviteits Index Invloed: Administratieve omgeving Productiviteits Hoog Index Omvang = 500 FP JAVA Mens Jaar = euro , doorlooptijd fixed op 9 maanden 16 Effort 70 Tijd 9 Kosten , Laag ,

37 MBI is de QSM Manpower Buildup Index (Zegt iets over staffing en tijdsdruk) Management Schaal Meet Tijdsdruk Kalender Maanden 2006 J F M A M J J A S O N D Staf Maanden

38 QSM Manpower Buildup Index Invloed: Omvang = 500 FP, JAVA Mens Jaar = euro , PI = 15 MBI Effort Tijd Kosten

39 Pauze

40 Quantitative Software Management Methods For Excellence Begroten met behulp van SLIM Estimate Elk schot in de roos

41 Voorbeeld Estimate Staffing & Probability Analysis CD R&D C&T Milestones P_Mnt 0 - CSR 1 - SRR 2 - HLDR 3 - LLDR 4 - CUT 5 - IC 6 - STC 7 - UAT 8 - FCR 9-99R R 0 1 Avg Staff (people) <QSM Default Solution> okt nov dec jan feb mrt apr mei jun '03 ' jul aug sep okt nov dec jan feb mrt ' Avg Staff (people) Phase 1: Concept Definition Determine project scope and feasibility Secure project sponsorship Define and secure preliminary resources Phase 2: Reqts & Design Analysis/Software Requirements Conduct needs analysis Draft preliminary software specifications Develop preliminary budget Review/refine s/w specifications/budget with team Develop delivery timeline Design Review preliminary software specifications Develop functional specs/high level design Develop prototype based on functional specificatio Final verification functional specifications Phase 3: Construct & T est Development Detailed Design Develop code Perform developer unit testing System Testing Develop test plans Perform system integration testing Perform system acceptance testing Documentation Develop and review help system Develop and review user manuals Pilot/Training Phase 4: Perfective Maint Deployment Post Implementation Review 0 Work Breakdown Structure <QSM Default Solution> okt nov dec jan feb mrt apr mei jun '03 '04 10 jul aug sep okt nov dec jan feb mrt '05 Tasks SOLUTION PANEL <QSM Default Solution> Duration Effort Cost Peak Staff MTTD C&T 6, ,8 7,3 1,5 Life Cycle 15, ,0 7,3 63,8 Months MHR EUR (K) people Days Start Date PI=17,5 MBI=3,6 Eff FP=1.000 CONTROL PANEL <QSM Default Solution> 17,5 7, ,0 21,0 PI 5,8 8,7 Peak Staff Eff FP Project: test

42 Voorbeeld Estimate SOLUTION PANEL <QSM Default Solution> Duration Effort Cost Peak Staff MTTD C&T 6, ,8 7,3 1,5 Life Cycle 15, ,0 7,3 63,8 Months MHR EUR (K) people Days Start Date PI=17,5 MBI=3,6 Eff FP=1.000

43 Voorbeeld Estimate R&D R&D C&T C&T CD R&D C&T P_Mnt Avg Staff (people) Avg Staff (people) <Single Goal - C&T Duration 4,4> <Single 2 Avg Goal 3Staff - C&T (people) Duration 4 4,4> 5 2 <QSM Default 3 Solution> Milestones Milestones 0 - CSR 0 Milestones - CSR 1 - SRR SRR CSR 2 - HLDR HLDR SRR 3 - LLDR LLDR HLDR 4 - CUT CUT LLDR 5 - IC IC CUT 6 - STC STC IC 7 - UAT UAT STC 8 - FCR FCR UAT 9-99R R FCR R R 99.9R R Avg Avg Staff Staff (people) Avg Staff (people) okt nov dec jan feb mrt apr mei jun okt1 2 nov3 4 dec5 6 jan7 8 feb9 10 mrt apr mei jun 17 '03 '04 okt '03 nov dec jan feb mrt apr'04 mei jun jul aug sep okt nov dec jan feb mrt '03 '04 ' Project: test Project: test Project: test

44 Voorbeeld Estimate Phase 1: Concept Definition Determine project scope and feasibility Secure project sponsorship Define and secure preliminary resou... Phase 2: Reqts & Design Analysis/Software Requirements Conduct needs analysis Draft preliminary software specifica... Develop preliminary budget Review/refine s/w specifications/bu... Develop delivery timeline Design Review preliminary software specif... Develop functional specs/high level... Develop prototype based on functio... Final verification functional specifica... Phase 3: Construct & Test Development Detailed Design Develop code Perform developer unit testing System Testing Develop test plans Perform system integration testing Perform system acceptance testing Documentation Develop and review help system Develop and review user manuals Pilot/Training Phase 4: Perfective M aint Deployment Post Implementation Review okt ' Work Breakdown Structure <QSM Default Solution> nov dec jan feb mrt apr mei jun jul aug sep okt nov dec jan feb mrt '04 ' Tasks Project: test

45 Vergelijking Plan versus industrie en eigen historische projecten Validate Estimate with History Validate Estimate with History C&T Duration (Months) vs Effective SLOC C&T Duration (Months) vs Effective SLOC C&T Effort (MHR) vs Effective SLOC C&T Effort (MHR) vs Effective SLOC Effective SLOC (thousands) Effective SLOC (thousands) C&T Duration (Months) C&T Duration (Months) ,1 0, Effective SLOC (thousands) Effective SLOC (thousands) C&T Effort (MHR) (thousands) C&T Effort (MHR) (thousands) PI vs Effective SLOC PI vs Effective SLOC PI PI CONTROL PANEL <Single Goal - C&T Duration 4,4> CONTROL PANEL <Single Goal - C&T Duration 4,4> 20,4 31, ,4 31, ,3 16,3 24,5 24,5 24,8 24,8 37,2 PI 37, Peak Staff Eff FP 1200 PI Peak Staff Eff FP Effective SLOC (thousands) Effective SLOC (thousands) Current Solution Historical Projects QSM 2005 Business Avg. Line Style 1 Sigma Line Style Project: test Current Solution Historical Projects QSM 2005 Business Avg. Line Style 1 Sigma Line Style Project: test

46 Quantitative Software Management Methods For Excellence Monitoren van de Project Voortgang en het Beheersen van uit de hand gelopen Projecten Elk schot in de roos

47 Vergelijk Voortgang met Plan Actual Actual Interpolated Interpolated Plan Plan Green CB Green CB Yellow CB Yellow CB S = Start S = Start 2 = G-CDR 2 = G-CDR 3 = G-FCC 3 = G-FCC 4 = C-CDR 4 = C-CDR 5 = G-SIT 5 = G-SIT 6 = C-FCC 6 = C-FCC 7 = N-CDR 7 = N-CDR 8 = CDR 8 = CDR 9 = C-SIT 9 = C-SIT 10 = FCC 10 = FCC 11 = N-FCC 11 = N-FCC 12 = N-SIT 12 = N-SIT 13 = SIT 13 = SIT 14 = UOST 14 = UOST 15 = IOC 15 = IOC 16 = FOC 16 = FOC Size Size S SS S Stoplichten geven advies voor herplanning * * Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul '95 '96 '95 ' ESLOC (thousands) ESLOC (thousands) De actuele data is structureel buiten de groene bandbreedte. Date 31/07/96 (19.00 mos) Date 31/07/96 (19.00 mos) Plan Actual %Diff Plan Actual %Diff Size (ESLOC(K)) Size (ESLOC(K)) PI 14.1 PI 14.1 MBI 4.1 MBI 4.1

48 Wanneer dingen fout gaan... Actual Interpolated Forecast Plan Green CB Yellow CB S = Start 2 = G-CDR 3 = G-FCC 4 = C-CDR 5 = G-SIT 6 = C-FCC 7 = N-CDR 8 = CDR 9 = C-SIT 10 = FCC 11 = N-FCC 12 = N-SIT 13 = SIT 14 = UOST 15 = IOC 16 = FOC Herplan Size S S QSM zoekt passende curve bij de actuele data om de bijbehorende einddatum te vinden * Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul '95 ' ESLOC (thousands) Date 31/07/96 (19.00 mos) Plan Actual/ Forecast %Diff Size (ESLOC(K)) PI MBI

49 Monitor Project Voortgang tegen Plan Schatten, Volgen en Voorspel wanneer het project gereed is met SLIM Control MB Maint Jan '96 Jan '96 Jan '96 Gantt Chart S 24 7 S * Jul Jan Jul Jan Jul '97 '98 Total Defect Rate S 24 7 S * Jul Jan Jul Jan Jul '97 '98 Size S 24 7 S * Jul Jan Jul Jan Jul '97 '98 Defects ESLOC (thousands) Aggregate Staffing Rate Jan '96 S 24 7 S * Jul Jan Jul Jan Jul '97 '98 Total Cum Normalized Defects Jan '96 Jan '96 S 24 7 S * Jul Jan Jul Jan Jul '97 '98 Total Cum Cost S 24 7 S * Jul Jan Jul Jan Jul '97 '98 People $ (millions) Defects Jan '96 Jan '96 Total Cum Effort S 24 7 S * Jul Jan Jul Jan Jul '97 '98 Total MTTD S 24 7 S * Jul Jan Jul Jan Jul '97 '98 PM Days Date 12/6/97 (19.18 mos) Plan Actual/ Forecast %Diff Elapsed Months Agg. Staff Total Cum Effort (PM) Total Defect Rate Total Cum Normal Defects Total MTTD (Days) Size (ESLOC(K)) Total Cum Cost ($ M) PI Current Plan Actual Interpolated Current Forecast Green Control Bound Yellow Control Bound Life Cycle includes MB, Maint S = Start, 2 = DDES, 4 = CUT, 7 = DEL

50 Quantitative Software Management Baten voor verschillende partijen

51 Baten van de aanpak voor verschillende partijen QSM levert alleen informatie waarmee partijen kunnen sturen. Alleen die partijen die bereid zijn om te sturen met deze informatie hebben baat bij deze aanpak. Kritieke succesfactor ligt in het op het juiste niveau binnen de organisatie plaatsen van deze aanpak: dwz dicht bij beslissers. Beslissingen worden transparant, onderbouwd op feiten. Inkopers kunnen leveranciers beoordelen op hun prestaties. Leveranciers kunnen objectief de impact van omvang, complexiteit, doorlooptijd, kwaliteit en wijzigingen aantonen en bespreken. Opdrachtgevers kunnen een bewustere keus maken waarin zij investeren en wat de alternatieven zijn. Verwachtingen worden gemanaged. Projecten hoeven niet meer te falen!!!!

52 Quantitative Software Management Onzin, valkuilen, waarheden

53 Onzin van metrics vervangt expert schattingen is alleen functiepunten invoeren een vaste prijs per FP (absoluut dus niet!!!) simpele modellen, tegen geringe kosten zelf te ontwikkelen levert vooral weerstanden op levert geen directe besparingen op

54 Valkuilen Te veel aandacht voor een technisch model en niet voor de invoering (veranderingsproces) Informatie niet tijdig beschikbaar Informatie wordt niet gebruikt Informatie komt niet bij de beslissers Informatie maakt falen uit het verleden duidelijk Misbruik en manipulatie van informatie Meet het proces en niet de medewerkers Metrics functie te laag in de organisatie gepositioneerd Metrics functie als een part-time functie zien

55 Waarheden Projecten falen >70 % Veel falen kan voorkomen worden Daarmee kunnen besparing van > 20 % worden bereikt Het SW ontwikkelproces wordt inzichtelijk Levert (initieel) weerstanden op Grote projecten zijn relatief goedkoper, maar risicovoller Kleine teams zijn productiever, leveren betere kwaliteit, tegen een gering verlies aan doorlooptijd Cijfers kunnen worden gemanipuleerd

56 Hoe kunnen wij u helpen? Informatie leveren om projecten / outsourcing te managen Omvang van projecten bepalen een marktconform plan leveren offertes vergelijken met de industrie database projectgegevens verzamelen produceren van voortgangsrapportages verzamelen historische gegevens leveranciers leveranciers benchmarken Ondersteuning bij het selecteren van de leverancier QSM levert essentiële informatie!!!

57 Tot slot U bent succesvol, als u in staat bent om de geleverde informatie daadwerkelijk te gebruiken om uw projecten beter te beheersen.

58