Software development-processen verbeteren met CMMI
If anything can go wrong, it will. De wet van Murphy geldt zeker voor software-ontwikkeling. Projecten van softwareontwikkeling hebben een lamentabele reputatie, ook na 30 jaar ervaring. In de USA werd een verbeteringsmodel gecreëerd om IT-afdelingen te helpen. Het heet CMMI, Capability Maturity Model Integration, en wordt ook in België al door enkele bedrijven toegepast. Hoog tijd dus voor een woordje uitleg over deze methode.
In de productiebedrijven doet men het al lang, bedrijfsprocessen meten en verbeteren om ze onder controle te krijgen, om sneller, beter en goedkoper te werken. Informatica is een jonge sector waarin het werk lang op een ambachtelijke manier gebeurde. Maar nu zijn er toch al enkele verbeteringsmodellen, frameworks van best practices, die elkaar aanvullen.
Het framework COBIT gaat bijvoorbeeld over IT governance, ITIL helpt de werking van de supportafdeling te verbeteren, en CMMI bevat richtlijnen voor software development. Software van hoge kwaliteit afleveren, sneller ontwikkelen en tegen een redelijke prijs: dat is de bedoeling. CMMI is het bekendste referentiemodel voor procesverbetering in software-ontwikkeling. Het werkt met 25 process areas, 4 functional areas en 5 niveau’s van maturiteit. Een woordje uitleg.
Software development is een groot domein. U wil iets verbeteren, maar hoe pakt u het aan? Het antwoord van CMMI is: volgens de processen. De processen van software development zijn onder andere: de analyse opstellen, de softwarearchitectuur definiëren, programmeren, de zelfgeschreven software laten samenwerken met aangekochte software, testen, een project plannen en beheren, de evolutie opvolgen, configuration management, quality assurance, omgaan met leveranciers en subcontractors, en risk management. CMMI werkt met 25 process areas; ze dragen namen als OID – Organisational Innovation and Deployment, PMC – Project Monitoring and Control, REQM – Requirements Management en CAR – Casual Analysis and Resolution.
Een aantal processen wordt uitgevoerd door ontwikkelaars, enkele andere door supportmensen, nog andere door een projectleider of een processpecialist (of ‘organisatiespecialist’). Daarom worden ze ingedeeld in vier domeinen, de ‘functional areas’: Process Management, Project Management, Engineering en Support.
CMMI werkt met vijf niveau’s van maturiteit van een IT-organisatie. In een organisatie van niveau 1, initial, is de manier van werken niet vastgelegd. Succes hangt af van de aanpak van de personen die op het project werken. In een organisatie van niveau 2 zijn de processen repeatable: er zijn enkele afspraken over de manier van werken en er wordt aan projectbeheer gedaan om de planning, de kosten en de functionaliteit in het oog te houden. In een organisatie van niveau 3 zijn de processen defined: de organisatie beschikt over standaarden, procesbeschrijvingen en procedures, die op elk project toegepast worden. In een organisatie van niveau 4 zijn de processen managed: de resultaten worden gemeten en met statistische procestechnieken verbeterd. In een organisatie van niveau 5 doet men aan optimizing: men werkt continu aan de verbetering van de processen.
Uit de praktijk
En hoe verloopt dat in de praktijk? We spraken met Bart Willems, IT engineer, MBA. Hij is certified lead assessor voor CMM, was tot voor kort actief als senior quality manager in de IT-afdeling van Belgacom en werkt nu bij Euroclear. Volgens Bart Willems moeten informatici CMMI niet zien als een extra last die op hun schouders wordt gelegd: ‘Nee, het is veeleer een kans om hun werkwijze te verbeteren. Het is ook niet nodig alle instructies uit het boek te volgen. Ik zie het als een medicijnkastje: men gebruikt enkel díe geneesmiddelen die passen bij het probleem, de symptomen en het doel dat men wil bereiken. CMMI bevat geen gedetailleerde voorschriften. Het bevat wel een rijke verzameling succespraktijken, op algemeen niveau. Die moet men telkens aanpassen aan het geval in kwestie.’ De voorschriften van CMMI zien er soms erg eenvoudig uit. Is dit niet meer dan gezond verstand? ‘Toch is het nodig dat deze regels expliciet vermeld worden’, volgens Willems, ‘omdat er in de praktijk zo vaak tegen gezondigd wordt.’
Ziet hij ook een veelgemaakte fout? ‘Soms beginnen IT-afdelingen overhaast aan het verbeteringstraject. Men moet eerst de context bestuderen en de zwakke punten identificeren. Men moet zorgvuldig de succespraktijken bestuderen en de doelstellingen bepalen. Dan pas duikt men in de gereedschapskist die CMMI is, en begint men met de verbetering van de processen,’ aldus Willems, ‘Het gebruik van CMMI lost niet automatisch alle problemen op. Gebruik het met verstand. Ga op zoek naar de oplossing op maat van het probleem in uw organisatie.’
Voorgeschiedenis
In de jaren 1980 werd de methode CMM, Capability Maturity Model, ontworpen door het Software Engineering Institute (SEI) van Carnegie Mellon University in Pittsburgh. De sponsor was het Amerikaanse Department of Defense, dat iets wou ondernemen tegen de steeds terugkerende problemen met grote IT-projecten. Achteraf heeft het SEI een nieuwe versie uitgebracht die de naam CMMI draagt, Capability Maturity Model Integration. Deze nieuwe versie omvat niet alleen software maar ook het hardwaregedeelte van grote projecten, en is bovendien veel meer gericht op het bereiken van businessdoelstellingen.
