Functioneel ontwerp, dus watervalmodel?

Vooraf alles vastleggen maakt het makkelijker om een fixed price offerte op te vragen aan je leverancier (zie ook: Functioneel ontwerp: Overeenkomst tussen klant en leverancier). Vaak wordt een functioneel ontwerp toegepast binnen het watervalmodel:

-       requirementsanalyse
-       functioneel ontwerp
-       technisch ontwerp
-       grafisch ontwerp
-       bouwfase
-       testfase
-       oplevering

Het lijkt namelijk erg logisch om je scope vooraf te bepalen en zo min mogelijk te wijzigen tijdens de bouw om zo de beruchte scope creep te voorkomen. Wijzigingen in functionaliteit tijdens de bouw zorgen namelijk vaak voor grote ellende, vooral wanneer het grote wijzigingen betreft waar in het technisch ontwerp bijvoorbeeld geen rekening mee is gehouden. Alhoewel ik een groot voorstander ben van het watervalmodel (goed nadenken voor je geld uitgeeft), merk je toch dat er blijkbaar grote behoefte is aan flexibiliteit (of dit nu veroorzaakt wordt door mensen die er van te voren niet goed genoeg over nadenken is een tweede), maar soms moet je nu eenmaal aanpassingen doorvoeren om aan wensen van de klant te voldoen, en natuurlijk bestaat er ook nog zoiets als veranderende marktomstandigheden, organisatorische wijzigingen en plain basic voortschrijdend inzicht.

Een wat meer flexibele methodiek om projecten te realiseren is bijvoorbeeld het opkomende SCRUMM-model. Daar leg je van te voren niet perse 100% vast wat er gerealiseerd moet worden, maar bedenk je de details van de invulling vooral on the go.

Alhoewel er genoeg kritiek te vinden is op deze soms (schertsend bedoeld) Cowboy Coding –methodiek kan ik mij voorstellen dat het soms wenselijk is om op zeer korte termijn iets werkends te hebben staan. Gelukkig lees ik steeds meer dat ook bij deze methodiek gebruik wordt gemaakt van een functioneel ontwerp. Dat wordt steeds in iedere sprint uitgewerkt en bijgesteld zodat ook de laatste voortschrijdende inzichten worden verwerkt. Altijd fijn om een applicatie gedocumenteerd te hebben wanneer deze moet worden getest of naar beheer overgaat (of wanneer de betrokken business analist of projectleiders vertrekken)….Of wanneer er bugs ver na oplevering worden geconstateerd….of wanneer er achteraf discussie ontstaat over de kosten vs hetgeen is opgeleverd of…nou ja….enfin, genoeg redenen te bedenken waarom je ook hier de zaken goed moet vastleggen

Ik zal binnenkort enkele artikelen die ik in het verleden heb geschreven over het watervalmodel publiceren, ik heb ze nog eens nagelezen en denk dat ook hier nog steeds wel waardevolle informative in staat…