Nieke Roos

17 November 2006

Onlangs publiceerde Bits&Chips een interview met ASML‘er Durk van der Ploeg, getiteld ’Weg met requirements‘. In het stuk veegt hij in forse bewoordingen de vloer aan met producteisen en het beheer daarvan. Ik vind het, op zijn zachtst gezegd, merkwaardig dat bij een groot internationaal hightechbedrijf een dergelijke mening heerst.

Uit het interview spreekt een opvatting die het best is te beschrijven als ’met een troepje hackers gaat het altijd goed‘, ’zonder wiskunde kan het allemaal niet‘ en ’tekeningen zijn voor watjes‘. Dat zijn relicten uit de oertijd van het programmeren. De ouderen onder ons weten het vast nog wel, dat was toen de marketingafdeling zei: ’Begin maar vast met programmeren. Wij kijken wel wat we gaan maken.‘

Van der Ploegs argumenten tegen requirements zijn vreemd genoeg allemaal juist voor het gebruik van moderne grafische ontwikkeltools. Zo verwijst hij naar Doug Dunn, die ooit zei dat elke generatie twee keer zoveel ontwikkelaars vereist. Dit is niets meer dan de oude managementwet dat als een project niet snel genoeg gaat, we er gewoon meer mensen aan moeten zetten. Volgens Van der Ploeg (en Dunn) is een project van 1 manjaar gemakkelijk in een uurtje te doen, als we maar 1920 mensen tot onze beschikking hebben.

Iedereen ziet dat zoiets onmogelijk is. Elk project heeft een optimale grootte. Tom Demarco heeft daar een boekenkast over vol geschreven. Zelfs al zou de benadering gedeeltelijk werken, dan zijn er niet genoeg programmeurs om de wet van Dunn te bedwingen, wat ASML blijkbaar zelf ook inziet.

 advertorial 

The waves of Agile

Derk-Jan de Grood created a rich source of knowledge for Agile coaches and leaders. With practical tips to create a learning organization that delivers quality solutions with business value. Order The waves of Agile here.

We zullen betere methodes moeten inzetten om de doorlooptijd onder controle te houden. Ook de geniale programmeurs die alles aan het lopen krijgen, houden er een keer mee op. Aan alle carrières komt een eind, zij het door een boom op de weg of doordat een dieet van pizza‘s en cola toch niet zo goed is voor de gezondheid. Dan zullen we het met ’gewone‘ softwareontwikkelaars moeten doen. En die doen hun werk beter als dat beter is gespecificeerd.

Een van Van der Ploegs bezwaren is dat we er veel te laat achterkomen als we iets zijn vergeten. Reden temeer om van tevoren na te denken over wat we willen en dat zo nauwgezet mogelijk te beschrijven. Moderne tools ondersteunen dit op hoog niveau. De combinatie van requirementsmanagementtools en UML-gereedschap met codegeneratie en model-level testing neemt veel van de bezwaren uit het artikel weg.

Van der Ploeg spoort aan om na te gaan denken over het oplossen van problemen in termen van modellen. Requirements zijn er juist voor om vast te stellen wat we gaan doen. Voor we überhaupt aan een model kunnen beginnen, zullen we eerst moeten specificeren wat we maken. De aansporing klinkt als de marketingafdeling van weleer, in een moderner jasje: ’Begin maar vast met modelleren. Wij kijken wel wat we gaan maken.‘

0611141427470
Willert Van der Heiden

De problemen die het artikel beschrijft, zijn in de moderne modelleringstools al grotendeels opgelost. Van der Ploeg mijmert over executeerbare modellen waaruit we de implementatie kunnen genereren. Dat is allemaal al lang geregeld. Er zijn meerdere UML-tools die modellen kunnen uitvoeren waarmee we kunnen testen, die zelfs automatisch tests en productiecode kunnen genereren, op de kleinste target-CPU‘s.

Volgens Van der Ploeg zijn UML-diagrammen altijd wel waar, maar zegt dat niets over de kwaliteit van de oplossing. UML is echter een formele methode die alles nauwkeurig definieert. Daarom kunnen we ook code genereren uit de diagrammen en die laten lopen op een pc of een targetplatform. Een UML-model kan zeker iets zeggen over de kwaliteit van de oplossing. Voorwaarde is dat we codegeneratie gebruiken, maar dat zouden we naar mijn mening altijd moeten doen als we UML inzetten.

In embedded gaat het niet meer alleen over software-engineering. Meestal bouwen we complete systemen die bestaan uit complexe hardware en software. ASML is daar een uitstekend voorbeeld van. Van der Ploeg wil dergelijke multidisciplinaire ontwikkelingen al tijdens het modelleren kunnen testen, ’nog voor mechanici, optici en elektronici het apparaat klaar hebben‘. Daar hebben we SysML voor.

Met de op UML gebaseerde System Modeling Language kunnen we requirements omzetten in werkende systemen, al dan niet ondersteund door codegeneratie. Testen kan automatisch vanuit een model, op basis van requirements. Het is zelfs mogelijk om geheel geautomatiseerd tests te genereren. Met menselijke inbreng natuurlijk. We kunnen wel tests genereren maar we zullen altijd zelf moeten aangeven wat voor uitkomsten eruit moeten komen.

Dit alles staat of valt met de inzet van een goed softwareontwikkelproces. Hier zijn er verschillende van, allemaal gebaseerd op het gebruik van tools met een zo goed mogelijk ondersteuning daarvan. Een voorbeeld is het Harmony-proces voor systeem- en softwareontwikkeling.

’Softwarehuizen, technologieontwikkelaars, universiteiten: regel het maar‘, roept Van der Ploeg. Veel is al geregeld. Toegegeven, op het UML-vlak is er nog werk aan de winkel. Ook in technische software is UML echter hard op weg om onmisbaar te worden. Ik breng Van der Ploeg graag in contact met een van onze klanten om hem hiervan te overtuigen.

Walter van der Heiden is CTO bij Willert Software Tools in het Duitse Bückeburg, onder meer leverancier van de Keil/Arm-tools en Telelogics Rhapsody-gereedschap.