Systeemontwikkelprojecten waarvan het budget is overschreden, de einddatum niet wordt gehaald of die niet (geheel) voldoen aan de wensen, lijken eerder regel dan uitzondering. Soms wordt dit zelfs als onvermijdelijk aanvaard. Omdat de meeste organisaties voor hun bedrijfsvoering afhankelijk zijn van informatie, zullen systeembouwers het beter moeten doen om nog serieus genomen te worden. Met ‘zes principes’ zijn veel voorkomende valkuilen te omzeilen, aldus een consultant van een software-ontwikkelbedrijf.
In bedrijfsprocessen gaat het steeds vaker om informatieverwerking en in allerlei apparatuur wordt steeds meer software ingebouwd. Fouten in deze software staan het functioneren meestal niet in de weg, maar zijn bijzonder ergerlijk. Toch is het mogelijk de meeste problemen goed het hoofd te bieden. Aan de hand van de zes onderstaande praktijkervaringen kunnen ontwikkelaars een aantal veel voorkomende valkuilen omzeilen.
Naast de overschrijdingen van het budget en de opleverdatum gaat er bij projecten vaak meer mis. Voorbeelden zijn: onbegrip voor de behoeften van de eindgebruiker, niet kunnen inspelen op nieuwe eisen tijdens de bouw van een informatiesysteem en geringe kwaliteit van het systeem en slechte prestaties ten gevolge van bugs. Ook kan na oplevering blijken dat de delen van het systeem slecht op elkaar aansluiten en dat de software moeilijk te onderhouden is. Deze lijst laat zich nog verder uitbreiden, maar als ontwikkelaars al deze problemen kunnen voorkomen, zijn ze al een heel eind op de goede weg.
Oorzaken
Bovengenoemde problemen zijn echter symptomen, de werkelijke oorzaken zitten dieper. Om de symptomen te bestrijden moeten derhalve deze oorzaken worden aangepakt. Onvoldoende aandacht voor het managen van de eisen die aan het te bouwen systeem gesteld worden en de wijzigingen die het eisenpakket tijdens het project kunnen ondergaan, alsmede onduidelijke en onnauwkeurige communicatie tussen betrokkenen, behoren tot die oorzaken.
Maar ook kunnen de toegepaste architecturen niet flexibel zijn en kunnen ontwikkelaars het overzicht verliezen door een te grote complexiteit. Vaak doen zich ook inconsistenties voor tussen eisen en wensen, ontwerp en implementatie en zijn de functionaliteit en prestaties onvoldoende getest. Daarnaast kan er op managementgebied een en ander mis gaan, met als gevolg onvoldoende inzicht in de vordering van het project, onvoldoende risicomanagement en het niet in de hand houden van wijzigingen. Ook hier zijn nog wel meer oorzaken te noemen. Sommige problemen zijn echter specifiek voor een bepaalde omgeving. Bovenstaande oorzaken hebben een algemeen karakter.
Zes praktijkervaringen
De hoofdoorzaken van het mislukken van projecten zijn goed aan te pakken; met als gevolg dat de ontwikkelde applicaties aansluiten bij de wensen van degenen die er mee moeten werken. Daarvoor biedt bijvoorbeeld het bedrijf Rational gereedschappen waarmee één of meer hoofdoorzaken van de problemen kunnen worden bestreden.
Bovendien versterken zij elkaar en kunnen zij daarom het beste in combinatie worden gebruikt voor een maximaal resultaat. Bij het ontwikkelen van software gaat de leverancier van deze ontwikkeltools uit van de volgende zes principes:
- Ontwikkel software volgens een iteratief proces.
- Beheer(s) de wensen en eisen ten aanzien van het te bouwen systeem (zie tabel Principe 1 & 2).
- Gebruik op componenten gebaseerde architecturen.
- Modelleer het systeem (zie tabel Principe 3 & 4).
- Verifieer voortdurend de kwaliteit van de software.
- Beheers wijzigingen (zie tabel Principe 5 & 6).
Iteratief proces
Principe 1: Ontwikkel software volgens een iteratief proces.
De twee basisbegrippen voor dit principe zijn: proces en iteratief. Een proces beschrijft hoe men komt van eisen en wensen tot het te ontwikkelen systeem. Het proces geeft aan welke stappen er zijn, wat er gedaan moet worden en door wie. Om systemen reproduceerbaar en beheersbaar te ontwikkelen is een robuust ontwikkelproces onontbeerlijk.
Maar niet elk proces zal even effectief zijn. Rational gaat daarom uit van een iteratief proces. Tijdens de ontwikkeling van het systeem zullen de inzichten van de betrokkenen meestal veranderen, wat zijn weerslag heeft op de eisen die aan het systeem worden gesteld. De ontwikkelaar dient daar rekening mee te houden en moet dus regelmatig controleren of het ontwerp en de implementatie nog wel aan de (al dan niet gewijzigde) wensen en eisen voldoen.
Bij een traditionele watervalaanpak worden de wensen en eisen na de zogeheten requirements-fase (de fase waarin de eisen worden vastgelegd) bevroren. Pas tijdens de testfase blijkt dan of alles werkt volgens plan. Deze werkwijze is niet meer te handhaven. Ontwikkelaars moeten zich er nu in een zo vroeg mogelijk stadium van vergewissen dat de oplossing werkt, niet alleen in functioneel maar ook in technisch opzicht. Dit kan door het project op te breken in een aantal kleine trajecten waarbinnen vroegtijdig tests plaatsvinden. Om te bepalen welke onderdelen in een volgende iteratie aan bod komen, dient de ontwikkelaar steeds die zaken te bekijken die het meeste risico voor het project kunnen opleveren. Deze risico’s moeten dan als eerste de wereld uit, zodat alle betrokkenen bij het project zo snel mogelijk zekerheid krijgen over de uitkomst van het project. Tevens moeten wijzigingen in de gestelde eisen (indien relevant) direct worden meegenomen.
Eisenbeheer
Principe 2: Beheer(s) de wensen en eisen.
De wensen en eisen die aan een te bouwen systeem worden gesteld heten ook wel de ‘requirements’. Bedoeld zijn alle voorwaarden waaraan het (nieuwe) systeem moet voldoen en de mogelijkheden die het moet bieden. Het gaat hier dus niet alleen om de eisen en wensen inzake de functionaliteit, maar ook ten aanzien van de bruikbaarheid, de betrouwbaarheid, de prestaties, de onderhoudbaarheid, de economische randvoorwaarden en de eventuele wettelijke voorschriften.
Het spreekt eigenlijk vanzelf dat het noodzakelijk is om al deze eisen te verzamelen en te documenteren. Voor een goed verloop van het project is het immers van groot belang dat iedere betrokkene inzicht heeft in alle eisen, aangezien deze impact kunnen hebben op de werkzaamheden. Op basis hiervan kan de ontwikkelaar de omvang van het project en de eventuele wijzigingen van de eisen bewaken.
Op basis van componenten
Principe 3: Gebruik op componenten gebaseerde architecturen.
Ook dit principe is gebaseerd op twee begrippen: architectuur en componenten. Een architectuur is de blauwdruk voor de oplossing en biedt een overzicht van de structuur van het te bouwen systeem. De architectuur bepaalt hoe de verschillende delen van een systeem met elkaar samenwerken. Voor de keuze van een architectuur is het van belang te weten in hoeverre eerder gebouwde delen van het systeem opnieuw bruikbaar zijn. Het hanteren van deze systeemdelen of componenten zorgt ervoor dat bij het ontwerp op een hoger abstractieniveau kan worden gewerkt. De kwaliteit van de architectuur neemt toe naarmate er meer goed geconstrueerde componenten beschikbaar zijn. De architectuur moet uiteraard robuust zijn en bestand zijn tegen veranderende omstandigheden.
Ontwerpmodel cruciaal
Principe 4: Modelleer het systeem.
Systeemontwikkeling komt in feite neer op een transformatieproces dat de wensen en de eisen omzet in een werkend systeem. Deze transformatie verloopt aan de hand van een aantal modellen. De eisen en wensen krijgen de vorm van een zogeheten use case-model: het ontwerp levert een ontwerpmodel, dat wordt geïmplementeerd door het implementatiemodel en getest door middel van het testmodel.
Het ontwerpmodel speelt een cruciale rol, omdat dit model de structuur en het gedrag van de gekozen architectuur inzichtelijk maakt. Het laat zien hoe de verschillende elementen van het systeem in elkaar passen en biedt de mogelijkheid om op verschillende niveaus naar het ontwerp te kijken, zodat het overzicht bewaard blijft. De consistentie tussen eisen, ontwerp en implementatie wordt bewaakt met behulp van zogeheten tracebility-links die laten zien waaruit iets is ontstaan, eventueel aangevuld met een aantekening over het waarom.
Bij het opstellen van het ontwerpmodel kan de ontwikkelaar het beste gebruik maken van een standaardnotatie, zodat de gebruikte diagrammen voor iedere betrokkene dezelfde betekenis hebben. Het gebruik van de Unified Modelling Language (UML) is een verstandige keuze, aangezien UML in korte tijd is uitgegroeid tot de wereldstandaard voor visueel modelleren.
Verifieer en beheer
Principe 5: Verifieer voortdurend de kwaliteit van de software.
Kwaliteit betekent hier de mate waarin het opgeleverde systeem voldoet aan de wensen en de eisen die eraan gesteld zijn, in het licht van de criteria die ervoor zijn geformuleerd. Aangezien niet van elke eis direct duidelijk is hoe deze geverifieerd moet worden, dient deze in elk geval te worden aangevuld met meetbare argumenten.
Het opstellen van deze testvereisten moet zo vroeg mogelijk in het project beginnen. De uitvoering van tests en controles start al tijdens de eerste iteratie. Dit is uiteraard van groot belang, want hoe langer het duurt voordat een fout wordt ontdekt, hoe meer moeite het kost deze op te lossen. De hoeveelheid uit te voeren tests zal dan ook groeien als de omvang van het systeem toeneemt. Vrijwel elk systeemdeel zal na een iteratie in omvang zijn toegenomen en dat betekent dat alle eerdere tests opnieuw moeten worden uitgevoerd. Deze regressietests zijn overigens te tijdrovend om met de hand uit te voeren. Tools zijn hiervoor onontbeerlijk.
Principe 6: Beheers de wijzigingen.
Tijdens een project komen allerlei (tussen)producten beschikbaar. Deze zijn over het algemeen ontwikkeld door meerdere ontwikkelaars, al dan niet georganiseerd in diverse sub-projectteams op één of meerdere locaties. Regelmatig zullen ontwikkelaars het werk van een ander als uitgangspunt moeten nemen voor de eigen ontwikkelactiviteiten. Vandaar dat het nodig is om zekerheid te verkrijgen of er wel aan de juiste versie wordt gewerkt. Een product kan opgebouwd zijn uit een aantal sub-producten en ook deze samenstelling zal moeten worden beheerd. Wil het project niet ontaarden in een chaos dan is het noodzakelijk om het hele wijzigingenproces goed in de hand te houden. Dat betekent bijvoorbeeld dat iedere betrokkene op de hoogte moet worden gebracht van relevante wijzigingen.
Problemen en symptomen
De hierboven gepropageerde zes principes pakken bij het ontwikkelen van software de hoofdoorzaken van de problemen aan en daarmee ook de symptomen. Bovendien vormen die principes een eenheid, aangezien zij elkaar versterken. Zo zorgt iteratief ontwikkelen ervoor dat wensen en eisen in de hand kunnen worden gehouden, terwijl de kwaliteit wordt geverifieerd.
Zonder het beheren en beheersen van wijzigingen is het onmogelijk om het ontwikkelproces in de hand te houden. Goed gebruik van op componenten gebaseerde architecturen kan bovendien niet zonder modelleren. En zonder al in een vroeg stadium regelmatig testen, is iteratieve ontwikkeling niet mogelijk. Aan het succesvol ontwikkelen van software kan het toepassen van deze zes principes derhalve een zinnige bijdrage leveren.
Gert Jan Niessink, consultant en docent, Rational Software Benelux
Principe 1 & 2
Hoofdoorzaak | Iteratief ontwikkelen | Requirements-management |
Onvoldoende aandacht voor het managen van de eisen en wensen ten aanzien van het te bouwen systeem en de wijzigingen die daarin tijdens het project in optreden. | De iteratieve aanpak maakt feedback van alle betrokkenen in een vroegtijdig stadium mogelijk en moedigt deze aan. | Op basis van de ‘zes principes’ van Rational is het beheer van de requirements op een gedisciplineerde manier aan te pakken. |
Dubbelzinnige, onduidelijke en onnauwkeurige communicatie tussen betrokkenen. | Door deze vroegtijdige feedback worden misverstanden eerder duidelijk. | Alle eisen zijn op een voor alle betrokkenen begrijpelijke manier vastgelegd, samen met duidelijke omschrijvingen van alle daarin gebruikte termen. |
Een te grote complexiteit waardoor het overzicht op het geheel is verloren. | Tijdens het ontwikkelen van het systeem concentreren we ons op de meest kritieke zaken. | Door het filteren en traceren van de requirements wordt overzicht verkregen. |
Inconsistenties tussen eisen en wensen, ontwerp en implementatie. | Door vroegtijdig testen worden deze inconsistenties eerder ontdekt. | Door het filteren en traceren worden inconsistenties eerder duidelijk. |
Onvoldoende inzicht in de echte stand van zaken met betrekking tot de projectvoortgang. | De mijlpalen voor elke iteratie zijn duidelijk, we weten wat er getest en wat de stand van zaken is. | De eisen (waar test-req’s deel van uitmaken) zijn duidelijk en er bestaat een goed inzicht in de huidige werkzaamheden en de voortgang daarvan. |
Onvoldoende testen van functionaliteit en performance. | Het testen start zeer vroeg in de levenscyclus. | |
Onvoldoende risico-management: dit is het te lang tijdens het project de kans lopen dat het systeem mislukt, in het licht van de daaraan gestelde eisen en wensen, waardoor tijd en geld verloren gaan. | Risico’s worden vroeg aangepakt, de hoogste het eerst, waarbij steeds wordt bekeken of het nog zinvol is om door te gaan met het project. | |
Onvoldoende gebruik van geautomatiseerde hulpmiddelen die onze taken ondersteunen. | Een tool voor eisenbeheer slaat de gegevens van de eisen op en biedt mogelijkheden tot filteren en traceren. |
Principe 3 & 4
Hoofdoorzaak | Component Based Architectures | Modelleer visueel |
Onvoldoende aandacht voor het managen van de eisen en wensen ten aanzien van het te bouwen systeem en de wijzigingen die daar tijdens het project in optreden. | Use-cases en scenario’s beschrijven op ondubbelzinnige wijze het gewenste systeemgedrag. | |
Dubbelzinnige, onduidelijke en onnauwkeurige communicatie tussen betrokkenen. | De betekenis van hetgeen gemodelleerd is, moet voor iedere betrokkene duidelijk zijn en is niet voor tweeërlei uitleg vatbaar. | |
Gebruik van breekbare, ‘weinig buigzame’ en niet uitbreidbare of aanpasbare architecturen. | Het werken met componenten verhoogt de flexibiliteit van de architectuur. Hergebruik van commercieel verkrijgbare componenten en frameworks wordt vergemakkelijkt. | Niet-modulaire en inflexibele architecturen worden blootgelegd. |
Een te grote complexiteit waardoor het overzicht op het geheel verloren gaat. | De opdeling van de architectuur in duidelijk zichtbare, redelijk onafhankelijke modules biedt de mogelijkheid om subteams te vormen die zich slechts met een deel bezig houden; slechts een deel hoeft het grote geheel te kennen. | Onnodige details kunnen worden verborgen. |
Inconsistenties tussen eisen en wensen, ontwerp en implementatie. | Modelleren maakt een ontwerp inzichtelijk zodat inconsistenties bij het traceren eerder aan het licht komen. | |
Onvoldoende testen van functionaliteit en performance. | Een goede systeemkwaliteit begint bij een ontwerp van goede kwaliteit. | |
Het niet beheersen van de wijzigingen en de impact ervan. | Componenten bieden een natuurlijke basis voor configuratie- en change-management. | |
Onvoldoende gebruik van geautomatiseerde hulpmiddelen die onze taken ondersteunen. | Modelleringstools geven de mogelijkheid om de architectuur in kaart te brengen en componenten te ontwerpen. | ‘Visual modelling tools’ maken het werk gemakkelijk en zij ondersteunen UML. |
Principe 5 & 6
Hoofdoorzaak | Verifieer kwaliteit continu | Control changes |
Onvoldoende aandacht voor het managen van de eisen en de wensen ten aanzien van het te bouwen systeem en de wijzigingen die daarin tijdens het project in optreden. | De workflow die gevolgd moet worden voor het beheren en beheersen van deze wijzigingen in eisen is bekend en reproduceerbaar. | |
Dubbelzinnige, onduidelijke en onnauwkeurige communicatie tussen betrokkenen. | Alle wijzigingen in de eisen lopen via een duidelijk afgebakend pad. | |
Een te grote complexiteit waardoor het overzicht op het geheel is verloren. | Door het afschermen van de eigen werkomgeving is er geen inbreuk vanuit het werk van anderen dat parallel wordt uitgevoerd. Tevens kan het blikveld beperkt worden tot alleen het deel dat we willen zien. | |
Inconsistenties tussen eisen en wensen, ontwerp en implementatie. | Vroeg testen legt inconsistenties in een vroeg stadium bloot. | Het versiebeheer zorgt ervoor dat we steeds over de correcte versies beschikken. |
Onvoldoende inzicht in de echte stand van zaken met betrekking tot de projectvoortgang. | Door een goed inzicht in wat er getest is en wat nog niet, ontstaat een objectief inzicht in de stand van zaken van het project. | Het CCRM-systeem geeft ons statistieken met betrekking tot wijzigingen waaruit we kunnen afleiden welke delen stabiel zijn en welke nog niet. |
Onvoldoende testen van functionaliteit en performance. | Fouten worden vroeg in het project gevonden en zijn dus goedkoper te herstellen. | |
Onvoldoende risico-management: dit is het te lang tijdens het project de kans lopen dat het systeem mislukt in het licht van de daaraan gestelde eisen en wensen, waardoor tijd en geld verloren gaan. | Het testen en verifiëren van de kwaliteit richt zich met name op de meest risicovolle aspecten. | |
Het niet beheersen van wijzigingen en de impact ervan. | Het doel van het beheersen van wijzigingen is na te kunnen gaan wat en wie er door een wijziging geraakt kan worden voordat deze wordt uitgevoerd. | |
Onvoldoende gebruik van geautomatiseerde hulpmiddelen die onze taken ondersteunen. | Geautomatiseerde testhulpmiddelen helpen bij alle vormen van testen: functioneel, betrouwbaarheid en performance. | Een goed CCRM-systeem helpt ons wijzigingen beter te beheren en beheersen. |