Fouten in software kosten heel veel geld en kunnen desastreuze gevolgen hebben. De ontploffing van de Ariane-raket vorig jaar toonde dat aan. Softwareconsultant Les Hatton wees onlangs in Computable op de lichtzinnigheid van de systeemontwikkelaar die niet leert van het verleden. Hans Sassenburg van Alert Automation Services denkt dat de PSP-methode (Personal Software Process) de individuele ontwikkelaar in staat stelt om betrouwbare software te bouwen op een voorspelbare en efficiënte manier.
Eén van de methoden om het proces van software-ontwikkeling te optimaliseren is CMM (Capability Maturity Model). In de praktijk blijkt het echter moeilijk om deze methodiek in organisaties in te voeren. W.S. Humphrey ontwikkelde daarom een nieuwe methode die gericht is op de verbetering van het vakmanschap van de individuele automatiseerder. Deze methode heet Personal Software Process (PSP). Het Veldhovense bedrijfje Alert Automation Services geeft – tot nu toe als enige – cursussen in de PSP-methode.
Als freelancer werd Sassenburg vroeger voornamelijk bij crises ingeschakeld. Uit frustratie dat hij steeds met identieke problemen te maken kreeg, ontstond bij hem de behoefte om het proces van software-ontwikkeling beter te structureren. CMM, dat uit het einde van de jaren tachtig dateert, leek een goed referentiemodel te zijn. In de praktijk blijkt het echter heel moeilijk te zijn om het model dat uit vijf niveaus bestaat (zie kader) in een organisatie te implementeren. Sassenburg: "In Nederland is na al die jaren alleen Ericsson in Rijen op niveau 3 gekomen. Er zijn enkele organisaties, waaronder Hollandse Signaal Apparaten en Baan, op niveau 2, maar de meeste bedrijven blijven op het eerste niveau steken. Veel bedrijven proberen CMM toe te passen. Het succes staat of valt uiteindelijk met het vakmanschap van de individuele automatiseerders. Er wordt wel eens gesproken over ‘lerende organisaties’. Maar organisaties kunnen niet leren, alleen de mensen die daarin werken. Vandaar dat ik zeer geïnteresseerd was toen in januari 1995 het eerste PSP-boek uitkwam: A Discipline for Software Engineering."
Registreren
Sassenburg schrok in het begin wel van het aantal formulieren dat de PSP-methode met zich meebrengt. Dat gold ook voor de mate waarin planmatig en gedisciplineerd werken wordt onderwezen. "Als je even naar het toilet gaat, moet je registreren dat je een onderbreking van een aantal minuten hebt gehad. En dat terwijl ik daar juist de meest briljante ideeën krijg… Toch is de basis van de methode, leren op individuele basis, uitstekend. Ik heb er alle vertrouwen in dat PSP uiteindelijk beter werkt dan CMM. Het uiteindelijke doel van de methode is te bereiken dat een individu betrouwbare software ontwikkelt op een voorspelbare en efficiënte manier. Het Amerikaanse Software Engineering Institute (SEI) geeft hiervoor een cursus van twee weken met tien programmeeroefeningen. De bedoeling van die oefeningen is zowel een confrontatie met je eigen onvermogen als de bouw van een persoonlijke ervaringsdatabase over je eigen manier van werken. Deze database wordt gebruikt in het verdere werk en steeds uitgebreid en verfijnd met nieuwe ervaringen. De vele formulieren worden gebruikt om de ervaringen te boekstaven, zodat aan het einde van elk project een postmortem kan worden gehouden. Dat is een retrospectie waarbij de resultaten op een rij worden gezet en geanalyseerd, om te leren hoe een volgend project beter kan worden aangepakt.
Om te profiteren van eerdere ervaringen moet dus veel geregistreerd worden. Bij CMM vindt registratie per project plaats, terwijl het gehele proces door het management wordt gestuurd. PSP werkt individueel. Kunnen mensen het opbrengen om zelfstandig de extra handelingen daarvoor te verrichten tijdens hun normale werkzaamheden? Sassenburg: "Het is wel even wennen. Mensen moeten zelfstandig extra handelingen verrichten naast hun normale werkzaamheden. Maar met behulp van spreadsheets en enig pragmatisme hoeft het toch niet zo veel tijd te kosten. Het gaat om maximaal vijftien minuten per dag. Dat is natuurlijk toch wel zo’n drie procent van je werktijd waarin je ook dingen van onmiddellijk belang kan doen. PSP werkt weliswaar van onderaf, maar kan alleen gedijen in een omgeving waarin het management of de opdrachtgever oog heeft voor het verbeteren van de werkprocessen. Een optimale introductie van PSP is het trainen van alle betrokken medewerkers bij aanvang van een nieuw project. Vanzelfsprekend moet iedereen tijdens het project worden gestimuleerd om eraan te blijven meedoen. Het zou ook heel nuttig zijn voor freelancers en gedetacheerden. Zij kunnen de kwaliteit van hun werk – en dus hun marktwaarde – er fors mee verbeteren. Zij worden helaas veelal ingezet op haastklussen, waarbij geen tijd beschikbaar wordt gesteld om ordelijk en gestructureerd te werken. Op deze wijze wordt verzuimd van de nuttige effecten te profiteren."
Het gevaar is volgens Sassenburg niet denkbeeldig dat het management de cijfers gaat gebruiken voor het beoordelen van hun medewerkers. "Dat werkt averechts. Als managers op die manier te werk gaan, is dat een zekere manier om de kwaliteit van het software-ontwikkelproces naar de bliksem te helpen. Ik heb gehoord van een manager die mensen ging beoordelen op het aantal regels code dat zij per kwartaal schreven. Dat aantal regels was het volgende kwartaal verdrievoudigd. Dat is voor een programmeur niet zo moeilijk. Maar registratie is echt nodig om betrouwbaar schattingen te kunnen maken. Daarvoor kun je niet volstaan met wat ongestructureerde notities die aan het einde van elke werkdag worden gemaakt. Nogmaals, het gaat erom dat je leert accurate schattingen te maken en op een efficiënte manier betrouwbare programmatuur te ontwikkelen. Je kunt dat alleen zelf bepalen en verbeteren aan de hand van cijfers. PSP biedt daarvoor de methodiek."
Methodieken
Ontwikkelaars beweren vaak dat elk project verschillend is. Eerdere ervaringen kunnen, zo zeggen zij, niet of nauwelijks een basis vormen voor het ontwikkelen van software. Volgens Sassenburg kan met PSP wèl van eerdere ervaringen gebruik worden gemaakt. "Als zaken te veel verschillen, moet je een hoger abstractieniveau kiezen, waarop de processen wel gemeenschappelijke karakteristieken vertonen. Dat is wat Humphrey gedaan heeft. In wezen volgt software-ontwikkeling steeds eenzelfde volgorde: analyseren, plannen, ontwerpen, reviewen, coderen, reviewen, compileren en testen. Deze volgorde bestaat ook bij rapid application development (rad). Alleen is de cyclustijd daar veel korter. Vandaar dat PSP ook geschikt is voor rad. Maar mensen blijven vaak op dezelfde inefficiënte manier werken en maken daarom steeds weer dezelfde fouten, uiteraard zonder dat zij zich dat bewust zijn. Met PSP word je daarmee geconfronteerd."
PSP is een persoonlijk leerproces. De meeste ontwikkelaars specialiseren zich echter op een bepaald gebied en werken in teams. Het is de vraag of in een dergelijke situatie PSP kan worden gebruikt. "Ja en nee", zo luidt het antwoord van Sassenburg. "Iedereen werkt steeds in een bepaalde volgorde en moet dus een schatting van zijn tijd en werkzaamheden maken. Dat geldt ook voor mensen die in teamverband werken. Dus kun je PSP ook in teams gebruiken. Als mensen daardoor goed en voorspelbaar kunnen werken en tegelijkertijd de logica van het ontwikkelingsproces goed begrijpen, zijn ze voor een team hoe dan ook een goede aanwinst. Het wordt nog aantrekkelijker om hen in de organisatie in te zetten bij andere projecten; dat vergroot de persoonlijke motivatie voor de PSP-technieken. PSP werkt alleen individueel, nog niet in teamverband. Maar Humphrey, nu 76 jaar oud, werkt onverdroten voort: hij is nu bezig met de ontwikkeling van TSP (Team Software Process)."
Het Capability Maturity Model kent vijf niveaus. Een organisatie kan van niveau naar niveau groeien. Dat gaat met heel veel moeite, zo blijkt in de praktijk. PSP kent vier verschillende niveaus (zie kader) die wat makkelijker te bereiken zijn. Volgens Sassenburg is PSP een zelfverbeteringsproces dat ervan uitgaat dat mensen hun eigen vakmanschap willen verbeteren. "Daarvoor moet je over voldoende doorzettingsvermogen beschikken, want zo’n verbetering houdt het nodige werk en discipline in. Het loont zeker de moeite, maar niet iedereen zal hetzelfde kunnen of willen bereiken. Je kunt zelf de vorm bepalen. De evaluatie en de afwegingen maak je ook zelf, aangezien er geen controlerende instantie is. De PSP-cursus leert je alle technieken en processen; daarna moet je zelf zien hoever je komt. Onlangs hebben we de besloten om voor onze cursisten een terugkomdag te organiseren voor het uitwisselen van ervaringen. Daaraan blijkt behoefte te bestaan."
Daling aantal fouten
Alert Automation Services geeft cursussen in PSP. Volgens Sassenburg is zijn bedrijf tot nu toe de enige die zich in deze opleiding heeft gespecialiseerd. Sommige bedrijven, zoals Philips, sturen hun mensen naar de Verenigde Staten en zetten vervolgens zelf een interne cursus op. Andere organisaties, zoals Baan, halen Amerikaanse trainers naar Nederland om de eigen mensen op te leiden. De officiële cursus duurt twee weken met daarnaast het nodige huiswerk. "Veel bedrijven vinden deze officiële cursus dan ook een te grote investering in tijd en geld. Vandaar dat we zelf een verkorte cursus van twee dagen hebben ontwikkeld met vier in plaats van tien oefeningen. Deze basiscursus is opgezet in samenwerking met het Software Engineering Institute (SEI) en blijkt in de praktijk zeer goed te voldoen", aldus Sassenburg die inmiddels vijftig mensen heeft opgeleid. Over de effecten van de cursus in de dagelijkse praktijk van software-ontwikkeling kan Sassenburg nog weinig vertellen. Daarvoor is PSP nog onvoldoende ingeburgerd in Nederland. Wel zijn onlangs resultaten uit Amerika bekend geworden. "Gegevens van het SEI over 104 software-ingenieurs die een PSP-training hebben gevolgd, tonen aan dat fouten bij het schatten van de programmagrootte met bijna 26 procent zijn verminderd en fouten bij het schatten van de tijdsduur met ruim 43 procent. De stijging in de productiviteit, gemeten naar het aantal regels per uur, bedraagt bijna 21 procent, terwijl de compileertijd daalde met ruim 81 procent. De testtijd daalde met ruim 43 procent, het totaal aantal fouten met bijna 60 procent en het aantal fouten gevonden tijdens de testfase met 73 procent. Bij drie projecten binnen AIS, een bedrijf met afdelingen in Amerika en India, waren de resultaten nog spectaculairder, met name bij het inschatten van de tijdsduur en het aantal gemaakte fouten. Daar wordt nu iedereen in PSP getraind. Ook bij Motorola werden uitstekende resultaten geboekt, vooral bij het voorkómen van fouten. Bij Union Switch & Signal verliep het werk op tijd en foutloos."
Sassenburg benadrukt dat het in sommige bedrijven bittere noodzaak is om software beter te ontwikkelen. Vooral om fouten in de programmatuur te vermijden. Nu alles computergestuurd wordt, kunnen fouten bijvoorbeeld in medische apparatuur rampzalig zijn en mensenlevens eisen. Het is tegenwoordig nog steeds zo, dat één op de tien regels een fout bevat. Door goede review- en testtechnieken kan 95 procent van de fouten gevonden en gecorrigeerd worden. Maar per duizend regels blijven er dan nog vijf regels over met een fout. Voor een Boeing 747 met acht miljoen programmaregels betekent het dat zich nog 40.000 fouten in de programmatuur zouden bevinden. Dat is volslagen ondenkbaar en onacceptabel. Sassenburg: "Mede daarom wordt verbetering van het software-ontwikkelingsproces steeds belangrijker, sterker nog: een bittere noodzaak."
ISO 9000 en Itil hebben een lange aanlooptijd van vijf tot tien jaar gehad. Na zo’n vijf jaar begint CMM zo langzamerhand brede bekendheid en acceptatie te krijgen. Sassenburg: "Met de acceptatie van PSP zal het niet veel anders gaan. Een experimentele versie van PSP is pas in 1994 geïntroduceerd. Het is dus allemaal nog erg nieuw. Ik ben overigens van mening dat je PSP tijdens je informatica-studie zou moeten leren. Dat zou de invoering aanzienlijk versnellen. Bij de opleidingen gaat het nu vooral om technische kennis, maar leren goed te werken is minstens even belangrijk, misschien wel belangrijker. Technische kennis zul je je hele leven moeten verwerven omdat er voortdurend van alles verandert. Een goede manier van werken hoef je maar één keer aan te leren. Daar heb je je hele verdere loopbaan profijt van. Wij zijn in overleg met de TU Eindhoven om te zien hoe we dit onderwerp kunnen inpassen in een college, zowel in de eerste als de tweede fase opleidingen. PSP wordt al op meer dan 20 universiteiten en instituten over de hele wereld onderwezen."
Hein van Steenis,
freelance medewerker Computable
Literatuur
1. W.S. Humphrey: A Discipline for Software Engineering. Addison Wesley, Reading, Mass., 1995. Het oorspronkelijke, uitgebreide boek over PSP.
2. W.S. Humphrey: An Introduction to the Personal Software Process. Addison Wesley, Reading, Mass., 1997. Een eenvoudiger en beter leesbaar boek over PSP.
3. P. Ferguson, W.S. Humprey e.a.: Results of Applying the Personal Software Process. IEEE Computer, mei 1997, p. 24-31.
4. M.C. Paulk e.a.: The Capability Maturity Model: Guidelines for Improving the Software Process. Addison-Wesley, Reading, Mass., 1995.
Capability Maturity Model
CMM kent vijf niveaus:
1) Initial. Het software ontwikkelingsproces verloopt ad hoc en soms chaotisch.
2) Repeatable. Processen voor projectmanagement zijn vastgelegd en ingevoerd, zoals configuration-management, kwaliteitsborging en projectplanning.
3) Defined. Alle processen met betrekking tot projectmanagement en software-engineering-activiteiten zijn gestandaardiseerd en vastgelegd voor de hele organisatie; alle projecten binnen de organisatie worden conform dit standaardproces uitgevoerd.
4) Managed. Aan de hand van kwantitatieve metingen ten aanzien van processen en producten worden objectieve beslissingen genomen.
5) Optimizing. Continue procesverbetering wordt mogelijk gemaakt door het vermijden van fouten en het invoeren van innovatieve technieken.
Personal Software Process
PSP kent vier niveaus:
(1) PSP0: Baseline. Dit is de basis van waaruit men werkt, waarbij men werktijden en fouten bijhoudt en het eigen ontwikkelproces in kaart brengt, inclusief schattingen.
(2) PSP1: Personal Planning. Hier vervolmaakt men het planningproces: het schatten van de benodigde tijd, het opstellen van een realistisch werkplan en het evalueren van de status van het werk.
(3) PSP2: Personal Quality. Op dit niveau wordt de kwaliteit van werken vervolmaakt. Door middel van reviews van ontwerp en programma wordt het aantal fouten gereduceerd en aan de hand van een checklijst wordt gecontroleerd of het ontwerp compleet is. Het is geschikt voor programma’s tot rond de duizend regels.
(4) PSP3: Cyclic Process. Abstractietechnieken worden aangeleerd om een groot project op te delen in stukken die voor PSP2 geschikt zijn. Het is geschikt voor programma’s tot meer dan 10.000 regels (voor nog grotere programma’s wordt TSP (Team Software Process) ontwikkeld).
* In de oorspronkelijke beschrijving van PSP door W.S. Humphrey zijn drie additionele subprocessen beschreven: PSP0.1, PSP1.1, PSP2.1. De inhoud hiervan wordt nu meestal bij de respectieve hoofdgroepen gerekend.
