Ontwikkelmodellen en het Agile model
In dit deel worden drie ontwikkelmodellen kort besproken en daarbij bekeken hoe deze in principe afgeleiden van elkaar zijn. De ontwikkelmethoden zijn het watervalmodel, het V-model en vanzelfsprekend het Agile ontwikkelmodel.
Het watervalmodel
De ontwikkeling in een klassiek watervalmodel kan als volgt omschreven worden. Als eerste wordt een idee geopperd. Dat idee wordt in business specificaties uitgeschreven waarbij de wensen vanuit de business beschreven worden. De business specificaties worden in functionele specificaties uitgeschreven. Hierbij wordt beschreven hoe een te ontwikkelen stuk software zich functioneel moet gaan gedragen. De functionele specificaties worden uitgeschreven in een architectuur en technische specificaties. De uitgeschreven technische specificaties worden ontwikkeld in componenten van databases tot code en gebruikersinterfaces. Deze componenten worden vervolgens aan elkaar gekoppeld tot een geheel werkend stuk software. Het hele softwarepakket wordt vervolgens aan een test onderworpen. De fouten worden hersteld door het ontwikkelteam. Daarna wordt er nog een korte controle uitgevoerd. Vervolgens wordt de software aan de klant opgeleverd
Het V-model
Het probleem bij het klassieke watervalmodel is dat testen pas betrokken wordt aan het einde van de ontwikkelfase. Testen mag dan een controle uitvoeren, maar door uitlopende ontwikkelingen wordt daar vaak veel te weinig tijd voor ingeschat. Tevens is niet geheel voorbereid en een belangrijke kwaliteitsslag wordt gemist, namelijk het controleren van de documentatie op basis waarvan de software is gemaakt. Testen wordt kortweg te laat betrokken. En het is algemeen bekend dat hoe later fouten gevonden worden in het ontwikkeltraject hoe duurder het is om deze fouten op te lossen. Het is namelijk niet altijd duidelijk waar de fouten het ontwikkelde systeem raken. Dus als een fout wordt opgelost kan het eenvoudig nieuwe fouten introduceren.
Om dit manco tegen te gaan is het V-model ontwikkeld. Het is eigenlijk niets anders dan het aanbreng van een knik op de plek van ontwikkeling in het watervalmodel.
Wat er dan te zien is dat tegenover elke vorm van documentatie een vorm van testen staat. Dat betekent ook dat op het moment dat een eerste stuk documentatie opgesteld wordt, testen al een globaal plan kan opstellen wat er getest moet worden en wat de risico’s in de software gaan zijn. Er kan ook al gecontroleerd worden of er fouten in de documentatie zitten, waardoor deze opgelost kunnen worden nog voordat deze ontwikkeld worden. Er worden Early testcase designs opgesteld, waarbij het vaak is dat de volledige details nog ontbreken, maar het framework er wel al staat.
Wat er met het V-model ontstaat is een kwaliteitsproces vanaf het begin van een project.
Wat grappig is om te zien is dat veel organisaties pretenderen volgens een V-model te werken, maar eigenlijk een watervalmodel hanteren, omdat ze testen niet vanaf dag één betrekken om de kwaliteit te controleren. Testen mag na het opstellen van de specificaties, eigenlijk aan het begin van de ontwikkeling de testgevallen opstellen om ze vervolgens in meerdere fasen uit te voeren.
Dat is uiteraard wel een verbetering, omdat er meer en dieper getest wordt, maar het is eigenlijk een verlenging van het watervalmodel zonder de voordelen van een V-model te gebruiken.
Grappig genoeg wordt de inzet van testen aan het begin van een project als te duur gezien, terwijl het vinden van een fout in een testfase al vele malen duurder is dan het vinden van een fout in een documentatiefase, voordat software ontwikkeld wordt.
Het agile ontwikkelmodel
Het agile ontwikkelmodel zorgt ervoor dat ontwikkelteams kleine stukken software kunnen maken in korte perioden. Het geheel uitschrijven van een project met complete functionele documenten, uitgebreide technische beschrijvingen en dergelijke wordt achterwege gelaten, zodat er snel een resultaat kan worden neergezet. De klant heeft een directe input en werkt nauw samen om onder andere de betrokkenheid te verhogen.
Zoals dit beschreven wordt is de agile ontwikkelmethode eigenlijk de juiste toepassing van het V-model. Dit wordt verkregen door de ontwikkeltijden kort te houden en direct terug te koppelen en af te stemmen wat er gebouwd gaat worden. Omdat het in feite veel kleine V-modelletjes achter elkaar zijn is het testen binnen een agile project niet slechts testen maar een gehele kwaliteitscontrole (QA of Quality Assurance). Testen dient vanaf moment één in de gaten te houden dat er geen gaten vallen in de specificaties. Alle juiste risico’s vastgesteld worden en alle testsituaties bepaald worden om de kwaliteit van de software binnen een en dezelfde sprint vast te stellen.
Let op: zodra er gesproken wordt dat testen een sprint later wordt uitgevoerd, dan is dit niet meer een schone agile manier van ontwikkelen, maar een afgeleide, waardoor er in principe aan de voordelen van de agile ontwikkelmethode gesleuteld wordt. Vaak overigens niet ten goede. Het doel van één sprint is namelijk werkende software. De basis van de agile ontwikkelmethode.
Het Agile ontwikkelmodel is eigenlijk gebaseerd op de continue terugkoppeling en de wisselwerking tussen alle betrokken partijen. Dit gaat van het samenzitten door ontwikkelaars met de klant, de testgedreven ontwikkeling, de dagelijkse standups, retrospectives, etc. tot het continue verbeteren van het gehele ontwikkelteam en de brede inzetbaarheid van het team in verschillende onderdelen.