Baan Series, de vijfde versie van de applicatiesoftware, bevat naar schatting al 50 procent minder fouten dan de vorige versie. Om het ontwikkelen van software beter in de vingers te krijgen begon de R&D-afdeling van Baan Company in 1995 een zogenoemd SPI-project. De organisatie moest volwassener en de kwaliteit van de software moest beter worden – het aantal fouten in de software moest omlaag. Cor van Dijk en Jaap Meeuse belichten de ups en downs in het verbetertraject, gesubsidieerd met Esprit-geld.
| Esprit ‘Le défi americain’ noemden we het vroeger in Europa: de Amerikaanse uitdaging. Om de afstand aan te duiden die de Oude Wereld technologisch scheidde van de Nieuwe. Die kloof mag niet breder worden, vindt ook de Europese Commissie. Investeringsprogramma’s en subsidies prikkelen bedrijven en wetenschappelijke instellingen in Europa tot (fundamenteel) onderzoek. En ook nu weer valt de keuze op een Franse naam: Esprit. In een serie artikelen neemt Computable een aantal Nederlandse Esprit-projecten onder de loep. |
"Zonder subsidiegeld zouden we óók een CMM-project uitgevoerd hebben, maar waarschijnlijk minder nauwkeurig", begint Meeuse. Het softwarebedrijf was zelfs al bezig met een SPI-project op basis van het CMM-model. Dat project bleek binnen de subsidieregels te vallen. Achteraf gezien meent Baan dat niet alleen het geld belangrijk was. Vooral de eisen die ‘Brussel’ aan het project stelde hadden een positieve invloed op de gang van zaken. "We werden gedwongen om het structureler aan te pakken dan we gewend waren. De tussentijdse rapportages die we naar Brussel stuurden werden kritisch bekeken. De eerste versie was meestal niet meteen acceptabel." Baan bleef niet met het gevoel achter dat er in Brussel een grote pot met geld stond, waar ze vrijblijvend een graantje van meepikten en vervolgens hun gang konden gaan.
Het project viel onder de paraplu van het European Systems and Software Initiative (Essi). Ook was een zogenoemd ‘baseline’-project vereist. De procesverbetering uit het gesubsidieerde project moest zichtbaar gemaakt worden en dus gemeten worden op een bepaald ontwikkelproject. Het bedrijf besloot de verbeteringen toe te passen op de productiesoftware Baan Manufacturing.
Niet voorspelbaar
Baan bevond zich destijds op het laagste niveau van het vijf niveaus tellende CMM-referentiemodel. "Daar moest dus hoognodig wat aan gedaan worden. Planningen liepen ongecontroleerd uit. We hadden de kwaliteit niet echt onder controle. Bij de oplevering zaten we zelf nog met teveel vragen over de kwaliteit." Baan kampte kortom met een gebrek aan voorspelbaarheid. Het oorspronkelijke doel was dan ook vooral het met enige nauwkeurigheid kunnen aangeven van een afleverdatum en tevens weten wat de kwaliteit van de ontwikkelde software is en, last but not least, die kwaliteit verbeteren.
De enigszins vage doelstelling werd toegespitst op een aantal meetbare indicatoren. Het ongecontroleerd uitlopen van projecten moest teruggebracht worden van 18 naar minder dan 5 procent. Het aantal niet juist verbeterde fouten in de software moest terug van 4 naar 2 procent en het aantal fouten na oplevering moest dalen van twee naar minder dan één fout per duizend regels code.
Een belangrijk bijverschijnsel was de enorme groei van het aantal medewerkers. In het begin van het project telde Baan 250 R&D-medewerkers, momenteel zijn dat er 1500, verdeeld over drie continenten. "Je moet kwalitatief opboksen tegen de enorme groei. De kwaliteit van de processen moet sterker groeien dan de organisatie zelf. Anders win je per saldo nog niets."
Baan is te spreken over de manier waarop de Europese instanties met het project omsprongen. "Ze zijn zeer flexibel wat betreft het wijzigen van de projectdoelstellingen en de realisatie daarvan. Een project hoeft niet per se een succes te zijn. Als onze conclusie zou zijn geweest dat het CMM-model niet toepasbaar is in ons type organisatie, zou dat een hele belangrijke boodschap zijn."
Flexibiliteit noodzaak
Het project zelf werd door een aantal werkgroepen uitgevoerd, die volgens een klassieke SDM-achtige (Systems Development Methodology) manier verschillende stukken van het softwareproces beschreven. In het midden van het traject besloot Baan de aanpak om te gooien en het met een flexibelere werkproduct-georiënteerde beschrijving te proberen. Werkproducten zijn tastbare resultaten van alle mogelijke activiteiten, procedures en werkinstructies die in een software-ontwikkelproject uitgevoerd kunnen worden, zoals het maken van een projectplan, het opstellen van specificaties of het opstellen van een ontwerp. Elk project bestaat uit zijn eigen specifieke combinatie van werkproducten, die dus standaard beschrijvingen kennen. "Het lijkt een beetje op objectgeoriënteerd projecten invullen. Daar hebben we ook weer een aantal standaard profielen voor. In bepaalde typen projecten komen altijd dezelfde werkproducten in dezelfde volgorde voor."
Dat beschrijvingsproces loopt nog steeds. Alle procedures zijn tevens via het intranet van Baan te benaderen. Dit moet het bekende ‘ISO-9000 fenomeen’ voorkomen, waarbij dikke ordners volgeschreven worden met procedures om ze vervolgens links te laten liggen en over te gaan tot de orde van de dag. Via het intranet is alle informatie ‘onder je muis’ beschikbaar, zoals Meeuse het uitdrukt. Al dit soort wijzigingen in de aanpak en inhoud van het project zijn niet vooraf te plannen. "Ook als Brussel er niet mee akkoord zou gaan, zouden we dit soort wijzigingen doorgevoerd hebben, maar Brussel ging overal in mee. Flexibiliteit is een bittere noodzaak."
De werkproductbeschrijvingen werden in eerste instantie door de ontwikkelaars zelf gemaakt. "Daar zit de kennis. Met het CMM-model in het achterhoofd werden allerlei werkproducten beschreven en verbeterd." De betrokkenheid van de ontwikkelorganisatie is cruciaal. Ook Humphrey wijst daar in zijn inmiddels legendarische boek ‘Managing the Software Process’ nadrukkelijk op.
"Maar we ontdekten dat het te intensief erbij betrekken van ontwikkelaars toch ook niet ideaal was." Van Dijk voert hiervoor drie redenen aan. In de eerste plaats is de kernactiviteit van software-engineers het bouwen van software – daar zijn ze ook voor opgeleid – en niet het verbeteren van processen. "Mensen vinden het belangrijk, maar het staat niet bovenaan op hun prioriteiten-lijstje. Ze worden afgerekend op de software die ze produceren."
Het tweede probleem is dat software-engineers geen of onvoldoende kennis en ervaring hebben om processen te verbeteren. Procesverbeteraars moeten kunnen presenteren, mensen overtuigen en het ‘not invented here’-syndroom kunnen doorbreken. Dat kunnen ontwikkelaars vaak minder goed. "Zij kunnen goed communiceren met hun beeldscherm", ‘stereo’-typeert Van Dijk de software-ontwikkelaar. Het laatste probleem dat Baan ondervond had te maken met continuïteit. "Clubjes van ontwikkelaars beschreven een werkproduct. Als die klus geklaard was, werd dat stukje van het project opgeheven en zweefde het tussenresultaat ergens in de organisatie. Niemand kon er nog op aangesproken worden." Vragen of ideeën voor verbetering konden bij niemand ingediend worden.
De Sepg-club
Om deze problemen te voorkomen besloot Baan medio vorig jaar een centraal coördinerend orgaan in het leven te roepen: de Sepg (Software Engineering Process Group). "Dat is een club waar fulltime gespecialiseerde process-engineers inzitten." Wereldwijd zijn momenteel elf mensen werkzaam in Baans Sepg. Kennis en bereikbaarheid zijn nu beter in orde, maar het aspect draagvlak vraagt meer aandacht. Ontwikkelaars moeten een nieuwe werkwijze van de procesgroep overnemen en toe gaan passen, daar is acceptatie voor nodig.
De grote procesklussen worden door Sepg uitgevoerd. Alleen voor specifieke kennis, suggesties en feedback wordt een beroep gedaan op de ontwikkelaars. Een jaar na invoering van de speciale groep concludeert Van Dijk dat deze aanpak werkt. "In de mailbox van de groep zitten elke dag ideeën. Soms hele wilde en soms hele pragmatische dingen." De organisatie is er mee bezig en dus werkt het, redeneert Van Dijk.
Steun van directie
Commitment van het management – dat in veel organisaties een onoverkoombaar struikelblok blijkt – was in het geval van Baan geen probleem. Binnen de directie bestaat grote steun voor het professioneel inrichten van het softwareproces. Wel ontstond er regelmatig discussie over de prioriteiten. "Het product moet ook de deur uit en dan moet je vechten om aandacht voor je procesverbeteringen. Dat is een reële discussie. Met het verkopen van producten verdienen we immers ons brood. Die spanning hou je toch. Ik moet zeggen dat de keuze opvallend vaak ten gunste van ons uitviel, hoewel we ook wel eens op het tweede plan werden gezet."
Roy op het Veld, redacteur
De hele serie:
- 18/12/98 – De geest uit de subsidiefles?
- 04/12/98 – Elektronisch beschermen van gegevens niet eenvoudig
- 27/11/98 – Wide-project pakt transactiebeheer aan
- 20/11/98 – Brussel stimuleert beter R&D-beheer
- 13/11/98 – Internationaal samenwerken in virtueel bedrijf
- 06/11/98 – Europa geeft Baan weer Spirit
- 30/10/98 – Nederland eet goed mee uit Esprit-ruif
30/10/98 – Nederland eet goed mee uit Esprit-ruif
