Cathal Griffin werkt bij Borland (www.borland.nl) als countrymanager in de Benelux.

1 July 2005

Het is geen nieuws dat softwareprojecten vaak teleurstellend eindigen. Ze zijn te laat klaar, voldoen niet aan de eisen, gaan zwaar over het budget heen of worden zelfs vroegtijdig stopgezet. Cathal Griffin van Borland legt uit hoe je dergelijke teleurstellingen kunt voorkomen. ’Softwareontwikkeling moet als een beheerbaar bedrijfsproces worden aangepakt, waarbij het draait om voorspelbaarheid en efficiëntie.‘ Ook hamert hij op het belang van een goede requirementsmanagementstrategie.

Onderwerp uw organisatie aan een kritische blik en stel uzelf de volgende vraag: ’Houdt mijn organisatie op het gebied van IT genoeg rekening met de daadwerkelijke behoefte van mijn opdrachtgever en lever ik de gevraagde projecten op tijd en volgens budget af?‘

Informatietechnologie is nog steeds een zeer gecompliceerd onderdeel van de bedrijfsvoering. IT-afdelingen slokken jaarlijks miljoenen euro op en worden vaak gezien als een financieel zwart gat. Marktonderzoek zegt dat softwareontwikkelprojecten nog steeds een groot risico lopen op falen. Vele projecten lijden aan vertragingen en budgetoverschrijdingen. Andere voldoen niet aan de originele doelstelling en sommige worden zelfs compleet geschrapt.

Zo blijkt uit een rapport van de Standish Group uit 2004 dat 30 procent van de softwareprojecten geannuleerd wordt, 44 procent het budget overschrijdt, 60 procent niet aan de gestelde eisen voldoet en dat maar liefst 90 procent niet op tijd wordt afgeleverd.

Wat gaat er mis en wat kunnen de stakeholders in het ontwikkelproject – bedrijfsanalisten, architecten, ontwikkelaars en testers – doen om deze situatie te verbeteren? Het is tijd om tot een andere benadering te komen om de kans op succes te vergroten. Door van softwareontwikkeling een beheersbaar en herhaalbaar bedrijfsproces te maken kunnen bedrijven dit realiseren.

 advertorial 

Hands-on GaN Doherty amplifier design

During the Benelux RF Conference at Van der Valk Nijmegen on 1 June, Martijn Brethouwer (Bruco IC) will take you through the paces of a Doherty amplifier development process with all its pitfalls and hurdles. Take a look at the complete program. We only have a limited number of tickets left, so sign up in time.

Hoe maak je softwareontwikkeling beheersbaar? Projecten falen niet door de fouten in de technologie zelf. Er bestaan vandaag de dag volop tools om eersteklas software in een recordtempo te leveren. Bij falende IT-projecten is er meestal sprake van slechte communicatie tussen opdrachtgever en de ontwikkelorganisatie. Het daadwerkelijke probleem ligt in de communicatie tussen de verschillende belanghebbenden (stakeholders) die betrokken zijn bij het proces. Door betere communicatie en continue terugkoppeling binnen het softwareontwikkeltraject nemen de risico‘s af en is een hogere kwaliteit binnen handbereik.

Borland_grafiek
Relatieve kosten voor foutherstel

Bedrijven moeten de kloof tussen IT en business dichten om de resultaten te verbeteren. De organisaties moeten voor meer zichtbaarheid voor alle betrokkenen zorgen, zodat er meer grip ontstaat op de softwareontwikkelcyclus. Doel is orde te scheppen in de chaos, door softwareontwikkeling te transformeren naar een beheersbaar en herhaalbaar bedrijfsproces.

Een belangrijke eerste stap is het verbeteren van de kwaliteit. De nadruk ligt daarbij op het op één lijn brengen van mensen, processen en technologie. Samenwerking tussen deze groepen moet communicatiekloven minimaliseren en leiden tot begrip tussen de gespecialiseerde rollen die betrokken zijn bij het ontwikkeltraject.

Goed begin is halve werk

Met requirementsmanagement kunnen bedrijven het begrip tussen de traditionele tegenpolen business en IT vergoten. Door eisen van het management te vertalen naar duidelijke IT-requirements is voor iedereen duidelijk wat de bedoeling is. Een goede requirementsmanagementstrategie verschaft inzicht in het project voor iedereen die erbij betrokken is, waar en wanneer nodig.

Maar liefst 80 procent van de softwaredefecten zijn te verhalen op slecht gedefinieerde of slecht gecommuniceerde requirements. Met andere woorden: ontwikkelaars bouwen software op basis van een gebrekkige blauwdruk. Dit is rampzalig, omdat de kosten voor het oplossen van problemen altijd escaleren in het eindstadium (zie figuur).

Hoe meer geld en energie organisaties in een softwareontwikkelproject steken voordat mogelijke defecten of gemiste verwachtingen ontdekt worden, des te meer het zal kosten om deze aan te passen. Helaas is deze waarheid zelden gereflecteerd in de aandacht voor detail in het definitiestadium van requirements. Bouwers kunnen hun werk niet uitvoeren zonder architecten, software is niet te ontwikkelen grondig gedefinieerde en geteste requirements. Zo leerde de ontwerper van de bekende wiebelige brug in Londen uit bittere ervaring dat het herstellen van defecten tijdens of na de constructiefase een dure zaak is. Hetzelfde geldt voor software. Defecten die in productie gaan kunnen organisaties miljoenen euro‘s kosten.

Van lineair naar circulair

Een ander probleem is de lineaire structurering van de meeste ontwikkelteams. Die veroorzaakt verwarring als requirements veranderen. Er is behoefte aan een meer herhaalbare, circulaire structuur waarin de verantwoordelijken voor ontwerp en het bouwen van software in continu communiceren gedurende de levenscyclus van een project blijven staan. Op geen enkel moment mag een teamspeler ervan uitgaan dat de race al is gewonnen wanneer het stokje wordt doorgegeven.

Requirements moeten toegankelijk zijn voor ontwikkelaars. Het is niet handig om een dik boek te laten circuleren waar niemand ooit in kijkt. Het is mogelijk om requirementsdata direct op te nemen in de ontwikkelomgeving, maar boekwerken zie je nog steeds verrassend vaak. Met een goed inzicht in de requirementsview moeten ontwikkelaars de wens van de klant kunnen horen in de cockpit van de softwareontwikkelorganisatie.

Veel projecten falen door het gebrek aan betrokkenheid tussen IT en eindgebruikers, de belangrijkste belanghebbenden van allemaal. De auteur en erkend Requirements Engineering-goeroe Karl Wiegers suggereerde in zijn boek ’Software Requirements‘ dat bij softwareontwikkelprojecten een officiële overeenkomst op te stellen om vast te leggen wat de business kan verwachten van IT en omgekeerd. Medewerkers moeten het gevoel hebben dat een project eigendom van hen is zodat ze zich actief zullen bemoeien met de kwaliteit van begin tot eind. Verder zijn eindgebruikers een onschatbare bron van informatie, ideeën en kennis. Als de IT-afdeling niet rechtstreeks kan onderhandelen met de eindgebruiker is de kans groot dat er kansen worden gemist.

De volgende stap

Hoe kunnen organisaties ervoor zorgen dat softwareontwikkeling wel succesvol verloopt? Allereerst is het belangrijk om vast te stellen waarom een systeem of verandering gewenst is. De uitkomst is meteen de definitie van de klantbehoefte. Deze behoefte moet de requirements aansturen. De volgende stap is gedetailleerd definiëren hoe de oplossing ontworpen zal worden. Als hierover overeenstemming is bereikt, is het belangrijk om taken toe te kennen aan het ontwikkelteam, zodat iedereen zijn verantwoordelijkheden kent. Er moet continue feedback zijn tussen ontwikkelaar en eindgebruiker in beide richtingen om problemen in de kiem te smoren.

Requirements bepalen is één, maar belangrijker is de kunst om met veranderingen in eisen om te gaan. Wanneer iedereen accepteert dat requirements tussentijds kunnen veranderen, dan kunnen organisaties zich richten op duidelijke, krachtige en bewezen methoden om met veranderingen om te gaan. Als kwaliteit en duidelijkheid vastliggen in het requirementsstadium en als de goede feedbackmechanismen in werking zijn, dan is de kans groter dat deze terugkomen in de volledige projectcyclus en dat het een succes wordt.

Geen utopie

Hoge kwaliteit in softwareontwikkeling is geen utopie. De meeste organisaties hebben de tools, kennis én medewerkers in huis om dit te realiseren. De eerste stap die ze moeten zetten is het integreren van mensen, processen en technologie om het ontwikkelproces te verbeteren. Softwareontwikkeling is een beheerbaar bedrijfsproces dat draait om voorspelbaarheid en efficiëntie.

Softwareontwikkeling die geïntegreerd is in de hele organisatie en afgestemd is op zowel zakelijke als operationele doelstellingen kan de eerste stap zijn naar succes.

De IT-organisatie kan verwachtingen die niet realistisch zijn matigen door inzicht te geven in de mogelijkheden van medewerkers en technologie en processen. De duidelijkheid die hierdoor ontstaat zorgt ervoor dat organisaties zich op de juiste softwareontwikkelingsprojecten kunnen richten. Hierdoor komt een hoge kwaliteit in softwareontwikkelingen binnen handbereik, waarbij snelheid, precisie en betrouwbaarheid worden gegarandeerd.