Vijftig procent van de totale projectkosten gaan op aan testen. De belangrijkste oorzaak van het uit de hand lopen van testen is een onvolledige beschrijving van de vereisten, aldus adviseur Tom DeMarco. In een interview geeft hij zijn visie op hot items in de informatietechnologie.
Tom DeMarco was de belangrijkste spreker op Euro Star 96, een congres over het testen van software. Computable greep de gelegenheid aan om de visie van deze goeroe-consultant te horen over testen en andere items in de informatietechnologie.
Vanuit heel Europa trokken meer dan vierhonderd deelnemers naar Amsterdam om te praten over het testen van software, kennelijk een actueel onderwerp. Iedereen spreekt echter over dezelfde zaken als tien jaar geleden. Hoe kan dat?
DeMarco: "Daar zit een kern van waarheid in, maar vergeet niet dat de computerwereld een grote inertie kent. Het duurt meestal minimaal vijftien jaar voordat een nieuw idee op grote schaal is ingevoerd. De afgelopen tien tot twintig jaar zijn er echt grote vorderingen gemaakt op het gebied van testen, anders zou de enorme groei in de omvang van programmatuur nooit gerealiseerd zijn. Er is erg veel gereedschap ontwikkeld, veel meer dan ik vroeger voor mogelijk hield. Het gebruik daarvan is echter nog niet wijd verbreid."
Tijdens de lezingen kwam regelmatig naar voren dat de kosten van testen ongeveer 50 procent uitmaken van de totale projectkosten. Je kunt je afvragen hoe reëel die vooruitgang dan wel is.
DeMarco: "Dat percentage noemde IBM al in de jaren zestig. Ik verwacht ook niet dat het de komende tijd zal veranderen, ook al wordt er steeds beter gereedschap gebruikt en worden we nog slimmer en effectiever in het vinden van fouten. De nieuwe statische analyse-programma’s onderzoeken programma’s zonder ze uit te voeren. Ze geven aan in welke gebieden zich mogelijk problemen kunnen voordoen, zodat men zich daarop kan concentreren.
Realiseer je overigens dat testen een ruim begrip is. Het behelst de allereerste activiteiten van programmeurs om te zien of hun programma werkt tot en met bruikbaarheids- en acceptatietesten. De vooruitgang is wellicht niet zo zichtbaar, maar hij is er wel degelijk. Vroeger sprak men alleen maar over veel zaken; het meeste daarvan doen we nu gewoon."
Toch leeft de gedachte dat er, vergeleken met zo’n tien jaar geleden, weinig nieuws te ontdekken valt. Volgens één van de sprekers op het congres gaat het met object-georiënteerd programmeren niet goed: minder produktiviteit en meer fouten! Van het geroemde hergebruik van programmatuur komt nauwelijks iets terecht.
Is er eigenlijk vooruitgang op het gebied van ontwerpen en programmeren?
DeMarco: "Toch wel, maar het gaat allemaal niet zo snel als veel mensen denken. Vijftien jaar na het voorstel van gestructureerd programmeren, bleek dit belangrijke concept goed te zijn ingevoerd. Met object-georiënteerd programmeren zitten we nog in het begin van de aanloopfase; we moeten nog leren met dit nieuwe paradigma te werken. Geen wonder dat het nog niet zulke goede resultaten oplevert als de oude vertrouwde manier! Ik verwacht overigens wel dat object-georiënteerd programmeren op den duur voordelen biedt."
Hyperlinks
Op het gebied van gebruikers-interfaces lijkt wel een doorbraak te komen door Internet en met name door het Web. Naar verwachting zullen binnenkort veel PC’s een browser-interface krijgen om naadloos met de eigen bestanden en die op Internet te kunnen werken.
DeMarco: "Het Web is inderdaad binnen enkele jaren enorm aangeslagen. Hyperlinks werden al in het begin van de jaren tachtig gebruikt, maar het is een potentieel sterk idee om hun werking uit te breiden tot Internet. Ik weet niet of het wat wordt. Iedereen was vijftien jaar geleden erg te spreken over Apple’s Hyper Card – ook een goed idee – maar dat is beperkt gebleven tot demo’s. Er zijn nooit echte toepassingen voor gemaakt. Met het Web zitten we in een vergelijkbare aanloopfase. Het zal moeten blijken of het meer oplevert dan fraaie demo’s van wat er allemaal mogelijk is. De werkelijke invoering is afhankelijk van veel factoren: beveiliging, betrouwbaarheid, responstijd, nuttige toepassingen, een andere manier van betalen, enzovoort. Desondanks ben ik optimistisch."
Een belangrijke stap in die richting lijkt de invoering van intranetten en de komende introductie van netwerk-computers. Het ziet ernaar uit dat deze technologie veel client/server-systemen zal gaan vervangen. Volgens DeMarco is dat niet onmogelijk, maar vooralsnog niet zeker. "Het grote voordeel van een centrale server is wèl, dat het administreren veel eenvoudiger wordt dan bij client/server-systemen. Omdat Internet nu nog vrijwel helemaal gratis is, moeten de informatieleveranciers hun geld verdienen via advertenties. Daardoor is Internet één gigantisch reclamebord geworden en komt werkelijk nuttige informatie nauwelijks tot haar recht. Als je via centrale servers af en toe een klein bedrag kunt innen, zal er veel meer nuttige informatie beschikbaar komen. Het web-interface kent wel enkele beperkingen en is daarom niet voor alle werkzaamheden geschikt. Een eventuele overgang zal heel gradueel plaatsvinden."
"In de computerwereld zijn heel veel goede ideeën gelanceerd – soms op grote schaal – die het niet gehaald hebben of pas vele jaren later. Toen ik in het begin van de jaren zestig bij Bell Labs in dienst kwam, was het idee van time-sharing ontwikkeld in Dartmouth. Dat was de toekomst, dat wisten we heel zeker! Binnen twee jaar zou het dè manier worden waarop mensen met computers werken. Toen het zo’n vijftien jaar later eindelijk gerealiseerd werd, was het te laat. Andere technologieën bleken toen effectiever. Zo gaat het vaker in de computerwereld," aldus DeMarco.
Meten van functioneren
In 1992 was Ed Yourdon in Nederland. Hij promote het capability maturity model (cmm) van Watts Humphrey – vijf fasen naar volwassenheid in het ontwikkelen van software. Is dat wel ingevoerd? DeMarco: "Ik heb daar niet zoveel mee op; het leent zich erg voor cultusvorming, net zoals iso-9000. Er zijn nog steeds maar weinig bedrijven die de laatste stadia bereiken. Het zal vanzelf uitsterven, denk ik. Humphrey’s personal software process is volgens mij veel belangrijker. Dat is een soort zelfstudiecursus voor informatici om hun eigen functioneren en kunnen kwantitatief te meten. Van iemand die dat kan, kun je een betrouwbaar antwoord krijgen op de vraag hoeveel tijd hij of zij nodig heeft om een bepaalde ontwikkelingstaak te verrichten. Bovendien stimuleert het de persoonlijke ontwikkeling: mensen gaan zich afvragen hoe ze beter kunnen werken."
Yourdon voorspelde destijds dat bedrijven als Microsoft, die niet werken volgens het cmm-model, binnen een aantal jaren het loodje zouden leggen. Maar Microsoft lijkt sterker dan ooit!
"Die uitspraak verbaast me. Er zijn vele wegen naar verbetering. Om software-ontwikkeling te verbeteren, moet je investeren. Dat kan op verschillende manieren: door te investeren in procedures, maar ook door je technische infrastructuur te verbeteren. Microsoft heeft enorm geïnvesteerd in gereedschappen, protocollen (Ole, OCX enzovoort), componenten en testlaboratoria. Op de conferentie hebben diverse sprekers benadrukt dat de kwaliteit van Windows te wensen overlaat. Toch moet je bewondering hebben voor de inspanningen van het bedrijf gezien de enorme hoeveelheid nieuwe software die het uitbrengt. Het zou volslagen onmogelijk zijn geweest om die in zo’n relatief kort tijdsbestek volgens het cmm-model en iso-9000 te ontwikkelen," aldus DeMarco
In het boek Why does software cost so much breekt DeMarco een lans voor grote bedrijven, die niet zouden moeten worden vervolgd door het Amerikaanse Ministerie van Justitie vanwege vermeende monopolistische praktijken. Hij stelt dat zonder hun grote omzet zulke bedrijven nooit de ontwikkeling van de transistor (AT&T) of de Xerox Parc-ontwikkelingen (grafische gebruikersomgevingen) hadden kunnen financieren. IBM heeft zijn ontwikkeling van de PC niet kunnen voltooien vanwege de klonen die het heeft moeten tolereren. Nu wordt Microsoft vervolgd omdat het de PC-softwaremarkt te sterk zou domineren.
DeMarco: "Ik ben er – net als veel Amerikanen – mordicus op tegen dat de overheid zulke acties onderneemt, omdat die altijd veel meer kwaad doen dan goed. Maar het is prima als consumenten en masse tegen Microsoft optreden. Het zou mij erg spijten als een prima leverancier als Apple het loodje zou moeten leggen onder druk van Microsoft, maar dat is dan de keuze van de consumenten, niet van de overheid. Als ‘iedereen’ vindt dat Microsoft goede software maakt, dan heb ik daar geen enkel probleem mee."
Vereistenspecificaties
Volgens veel sprekers op de conferentie is één van de hoofdoorzaken van problemen met de ontwikkeling van software gelegen in het feit dat de vereistenspecificatie meestal incompleet is of niet deugt. Dat is een oud probleem waarvoor kennelijk nog geen oplossing gevonden is. Zeker in het licht van steeds weer veranderende technologieën zou een algemene specificatie, die voor elke technologie bruikbaar is, nuttig zijn. Als men het eens is over de taal en die zou invoeren, volgen de gereedschappen en hulpmiddelen vanzelf. Dan hoef je later geen re-engineeringtechnieken te gebruiken om het ontwerp te vinden.
DeMarco: "Zo’n taal is nog niet ontwikkeld. Ik zie dat ook niet gebeuren. Het is relatief eenvoudig om een nieuwe taal te ontwerpen; het probleem is om die geaccepteerd te krijgen – kijk maar naar Ada. Er zijn inmiddels erg veel pakketten te gebruiken voor zowel re-engineering als voor implementeren. De leveranciers hebben daar dus weinig belang bij. Voor universiteiten is het een weinig interessant project. Wil je toch iets? Dan mag je van mij de gebruikershandleidingen gebruiken als vereistenspecificatie. Die zijn redelijk consistent, meestal begrijpelijk geschreven en uitstekend te gebruiken voor re-engineering. Helaas worden ze meestal pas na afloop van de initiële ontwikkeling geschreven; bovendien lenen ze zich niet voor het gebruik van gereedschappen."
In de jaren zestig en zeventig ontstonden de grote computersystemen. Ze zijn er nog steeds. Minicomputers hebben wel succes gehad, maar worden nu meestal gebruikt als server in netwerken met PC’s. IBM zou nu meer aan zijn grote computers verdienen dan tien jaar geleden. Hoe ziet u hun verdere ontwikkeling?
DeMarco: "Voorspellen is moeilijk, zeker in de computerindustrie. Het is wel duidelijk dat die grote computers twintig jaar geleden vervangen zouden moeten zijn, maar het is niet gebeurd. Lees Lord Jim van Joseph Conrad er maar op na: oud ijzerwerk beschikt over verbazingwekkende capaciteiten om stormen te overleven. Ook de computerindustrie is inert, waardoor de meeste dingen langzaam veranderen. Denk maar aan Unix: vijftien jaar heeft het geduurd voordat de doorbraak kwam, en nu zal het niet zo snel verdwijnen als sommigen denken. Zo werkt de markt nu eenmaal."
Gemeenschappen
Met wat voor onderwerpen en nieuwe ontwikkelingen houdt u zich nu mee bezig?
DeMarco: "Ik werk als consultant voor bedrijven met problemen en geef cursussen en lezingen. Veel problemen liggen niet zozeer op technisch maar op organisatorisch gebied. De woorden ‘cultuur’ en ‘bedrijfscultuur’ zijn nogal beladen in de VS, vandaar dat wij spreken over het bouwen van ‘gemeenschappen’. Door de grote mobiliteit en de criminaliteit in de grote Amerikaanse steden, spreekt dat beter aan. De mens is een gemeenschapsdier – wij functioneren veel beter in een gemeenschap dan in isolatie. Mensen hebben behoefte aan reacties van anderen. Gemeenschappen zijn veel effectiever in hun werk dan losse verbanden, vandaar dat veel bedrijven nu onze hulp inroepen om hen te helpen bij hun gemeenschapsvorming. Dit is echt een groot probleem aan het worden, nu de mobiliteit zo enorm is toegenomen en de banden met het bedrijf steeds losser worden door het inschakelen van mensen met een kort dienstverband, telewerkers en subcontractors. In ons bedrijf, Atlantic System Guild, houden we elke dag contact via e-mail en gaan we vaak met zijn tweeën op pad. Dat is overigens niet hetzelfde als direct contact. Ook al zou er meer dan voldoende bandbreedte beschikbaar zijn, dan nog is het probleem van direct contact niet opgelost. Sommige bedrijven investeren flink in hun gemeenschap als onderdeel van de zo belangrijke infrastructuur. Ik heb gewerkt voor een bedrijf dat binnen het eigen kantoorgebouw een lagere school voor de kinderen van zijn medewerkers heeft gevestigd; die kinderen trekken eenmaal per dag onder luid gejoel door het kantoor. Dat is stimulerend en bevredigend!
Hein van Steenis, freelance medewerker Computable
Literatuur
DeMarco, T en Lister, T. Peopleware: productive projects and teams. Dorset House Publishing, 1987 (http://www.dorsethouse.com/).
DeMarco, T.: Why Does Software Cost So Much, and other puzzles of the information age. Dorset House Publishing, 1995 (http://www.dorsethouse.com/).
Humphrey, W.S.: A Discipline for Software Engineering. Addison-Wesley 1995
Aandachtspunten bij ontwerpen en testen
Tom DeMarco was dè keynote spreker op het congres Euro Star 96 over het testen van software. Zijn hoofdstelling was dat testen (en het daarbij behorende oplossen van de gevonden fouten) een beheersbaar proces kan zijn. Voorwaarde daarvoor is dat er aan zeven punten moet worden voldaan, anders kan het flink uit de hand lopen. Het betreft vooral een andere manier van samenwerken, niet van testen.
Er is iets goed mis als de manager van een ontwikkelingsproject alleen maar de voornaamste fan van een project is.
Zo’n manager speelt de rol van aanmoedigend publiek, terwijl hij zou moeten optreden als coach van het team, die – waar nodig – veranderingen aanbrengt, knelpunten oplost, kansen pakt en beslissingen neemt. Projecten die geleid worden door ‘fan-managers’ lopen meestal volledig volgens plan tot op 20 procent van het einde. Dan komen de grote problemen pas aan het licht en zijn oplossingen vrijwel niet meer mogelijk of zeer kostbaar. Het is vergelijkbaar met een Griekse tragedie waarin mensen in het begin meester zijn over hun situatie. Uiteindelijk beheerst de situatie de mensen.
Het uit de hand lopen van testen wordt vrijwel nooit veroorzaakt door testproblemen, maar door eerdere, niet opgeloste problemen.
Verreweg de belangrijkste oorzaak is een onvolledige beschrijving van de vereisten, die door allerlei instanties is goedgekeurd. Niemand zal je vertellen dat die niet compleet is! De onvolledigheid is vrij eenvoudig te constateren. Iedere specificatie van de vereisten die aan het begin van elk project wordt opgesteld, bestaat uit twee onderdelen: de interne functionaliteit èn een overzicht van de input-triggers (gebeurtenissen, stimuli enzovoort) met de responsen van het systeem. De functionaliteit is moeilijk te beoordelen, maar de inputs en resulterende outputs niet. Daaraan kun je eenvoudig zien of een vereisten-specificatie compleet is of niet.
Onvolledigheid van een vereisten-specificatie is vrijwel altijd het gevolg van niet-opgeloste conflicten in de organisatie.
De introductie van elk nieuw computersysteem veroorzaakt veranderingen in de organisatiestructuur en dus in de machtstructuur. Sommige mensen raken macht kwijt en anderen krijgen extra macht. Dat houdt intrinsiek een conflict in dat moet worden opgelost, anders kunnen de vereisten niet goed bepaald worden. Omdat dit veel tijd kost, probeert men daar vaak overheen te schrijven. Later leidt dit onherroepelijk tot problemen. Als voorbeeld noemt DeMarco de vereisten-specificaties voor vijf nieuwe systemen voor de Amerikaanse luchtvaartdienst. Hier liep het conflict tussen de centrale en de regionale organisaties: wie was er verantwoordelijk voor het beheer van de systeemconfiguraties?
Helaas worden informatici niet getraind in het oplossen van conflicten.
Begin nooit aan ontwerpen voordat alle conflicten rond de vereisten-specificatie volledig opgelost zijn.
Het is onmogelijk een goed ontwerp te maken als de vereisten-specificatie incompleet is. Ontwerpfouten binnen een module zijn meestal eenvoudig op te lossen; de fouten in het ontwerp van de koppelingen tussen modules niet – die worden veroorzaakt door incomplete vereisten.
Het ontwerpen wordt vaak op een verkeerde manier aangepakt en het belang van inspecties van het ontwerp wordt onderschat.
In enkele gevallen is er helemaal geen echt (conceptueel of gedetailleerd) ontwerp gemaakt. Het werk wordt opgedeeld in hapklare brokken en de groepjes moeten dan zelf maar zien hoe ze die verder uitwerken. Dat valt eenvoudig te constateren door het ontwerp van programma’s te bepalen met reverse-engineering en dit te vergelijken met het oorspronkelijke ontwerp. Het probleem is meestal de haast die gebruikers hebben, waardoor te veel mensen te vroeg aan het ontwerp worden gezet. Je kunt echt niet meer dan drie tot maximaal vijf ontwerpers gebruiken. Als dat er vijftig zijn, weet je zeker dat het misgaat: dan krijg je een systeemontwerp dat isomorf is met de projectorganisatie.
De voornaamste oorzaak van fouten in het ontwerp is het inschakelen van te veel mensen.
DeMarco veronderstelt dat de haast van de gebruikers vrijwel nooit wordt ingegeven door de tijd waarop het systeem echt nodig is, maar door de angst voor budgetoverschrijdingen. Daarbij is de redenering dat als een systeem binnen tien maanden klaar moet zijn, men niet meer dan een bepaalde hoeveelheid geld kan uitgeven. Deze redenering is onjuist omdat de haast meer menskracht vergt en meer fouten tot gevolg heeft. Volgens DeMarco moet je in de opbouw van een project pas op het allerlaatste moment de troepen laten aanrukken, bijvoorbeeld pas op 80 procent van de doorlooptijd. Dat is geen populair idee en vereist een moedige manager. Het resultaat is 50 procent reductie in de totale kosten en een veel betere kwaliteit, slechts ten koste van een langere doorlooptijd. Dit is een argument waarmee gebruikers vaak toch zijn over te halen.
Concentreer op ontwerp-inspecties, niet op code-inspecties.
Veel code-inspecties zijn in feite inspecties van het ontwerp. Omdat het ontwerp compacter is en op een hoger niveau gespecificeerd, is het makkelijker te inspecteren dan de code en ook eenvoudiger te corrigeren. Dit vermindert de kans op veranderingen op het laatste moment. Code-inspecties moeten alleen verricht worden op kritieke plaatsen, bijvoorbeeld in heel kleine of heel grote modules.
Tot slot pleitte DeMarco voor een betere manier om de vooruitgang in een project te beschrijven. Vaak wordt gesteld dat driekwart van het werk is gedaan als driekwart van de manmaanden zijn opgenomen. Dat is pure nonsens. Het enige dat telt zijn de onderdelen van het bouwplan die door de acceptatietest zijn gekomen. Wanneer er vier van de tachtig af zijn, is 5 procent klaar. Ook voor dit soort uitspraken zal een projectmanager over de nodige moed moeten beschikken.
Tom DeMarco
Na zijn werk bij Bell Labs was Tom DeMarco verantwoordelijk voor de ontwikkeling van gedistribueerde online banksystemen in diverse Europese landen. Vervolgens heeft hij veel bijdragen geleverd aan de theorie en praktijk van software-ontwikkeling door middel van artikelen en boeken, lezingen en adviseurswerk. In 1986 kreeg hij de ‘Warnier prize for lifetime contribution to the information sciences’ en in 1997 wacht hem een volgende grote prijs.
Naast zijn baanbrekende boeken ‘Structured analysis and system specification’ (1979) en ‘Controlling software projects’ (1982) schreef hij meer dan honderd artikelen en diverse boekjes. Hij is een van de oprichters van het Atlantic Systems Guild, een collectief van Amerikaanse en Engelse topadviseurs. Hij werkt en geeft lezingen over de gehele wereld.
