Waarom softwareapplicaties falen!
In het artikel Scoping and Requirements Woes van Frank Buschmann (Gang of Four) in IEEE Software November/December 2009 worden weer een aantal punten naar voren gebracht waardoor softwareapplicaties de mist in gaan. De belangrijkste redenen zijn:
- scope van de applicatie, veel applicatieontwikkelingen worden gestart zonder voldoende de scope van de te ontwikkelen applicatie te bepalen;
- onvoldoende rekening te houden of niet definieren van vage niet-functionele eisen.
Door onvoldoende de scope van de applicatie te kennen loopt de ontwikkeling kans dat de applicatie te veel en zelfs verkeerde functionaliteit gaat bevatten. Het realiseren van te veel functionaliteit levert gevaar op voor de kwaliteit.
Om een oplossing te vinden voor het scoping probleem zijn context diagrammen zeer toepasbaar. Met een context diagram wordt de (functionele) omgeving van de applicatie in kaart gebracht. Deze omgeving wordt strakker gedefinieerd door antwoord te vinden op de volgende vragen:
- Waar begint het systeem/applicatie?
- Wie gebruikt het systeem en waarvoor/waarom?
- Welke resources zijn beschikbaar?
- Waar stopt het systeem of is het afhankelijk van andere systemen?
Als de grenzen zo ongeveer bekent zijn is het aan de softwarearchitect om te bepalen of deze niet te breed of te smal is. De scope wordt tijdens de verdere ontwikkeling continue bewaakt en eventueel langzaam aangepast.
Door gebruik te maken van ATAM (Architecture Trade-off Analysis Method (P. Clements e.a.)) of door Use Cases te gebruiken wordt de systeem scope gevalideerd.
Scoping is noodzakelijk om te voorkomen dat een klant meer wil dan waar hij initieel om heeft gevraagd.
Vage niet-functionele requirements zijn een andere bron van frustratie of klantontenvredenheid. Dit soort requirements staan los van het functionele gedrag van een systeem. Zelfs een systeem dat functioneel precies doet wat er van verlangd wordt kan door een klant niet worden geaccepteerd, omdat de responsetijden langer zijn dan hij verwacht had, schaalbaarheid onvoldoende is, of analyseerbaarheid van een berekening niet mogelijk is.
Het is aan de architect om vage niet-functionele requirements om te zetten naar, concrete vragen met concrete antwoorden. Bijvoorbeeld door te vragen:
Hoeveel gebruikers zullen het systeem parallel aan elkaar gaan gebruiken op welke momenten?
Met welke functionele requirement is de niet-functionele requirement verbonden?
Scope, functionele en niet-functionele requirements moeten passen bij een business doelstelling. Met een iteratieve aanpak zijn we in staat om de scope langzaam maar zeker uit te breiden terwijl we continu functionaliteit leveren waar de klant daadwerkelijk iets mee kan. Door deze aanpak zal de klant een functioneel systeem krijgen waar hij om gevraagd heeft.
- Han van Roosmalen's blog
- Login to post comments