Het ontwikkelproces van maatwerksoftware, stap voor stap

Het ontwikkelproces van maatwerksoftware is de weg die een project aflegt van een ruw idee naar werkende software waarvan jij eigenaar bent, en die weg loopt altijd door vijf fasen: scoping, ontwerp, bouw, acceptatietest en oplevering. De namen verschillen per leverancier. De volgorde niet. Wie de volgorde kent, herkent een serieus proces van een open proces voordat je tekent, en weet in welke fase je zit zodra het werk begint.

Geschreven voor wie de software laat maken, niet voor wie hem schrijft. Onze pagina over maatwerk-softwareontwikkeling behandelt kosten, doorlooptijden en de keuze tussen bouwen en kopen; hier draait het om de mechaniek van de bouw zelf, wat er in elke fase gebeurt, en wat je zou moeten kunnen controleren voordat het naar de volgende fase gaat.

De vijf fasen die elk project doorloopt

Onder welke methode dan ook volgt het werk de software development life cycle (SDLC): de reeks van eisen tot een draaiend, onderhouden systeem. Agile teams doorlopen deze fasen in korte cycli; een bouw met een vaste scope doorloopt ze één keer, bewust. Hoe dan ook verschijnen vijf fasen in volgorde, en er één overslaan is precies waar projecten misgaan. Voor de volledige definitie zie je het item software development life cycle (in het Engels).

Het belang van die volgorde is oud en goed gedocumenteerd. In het oorspronkelijke CHAOS-rapport van de Standish Group (1994) overschreed meer dan de helft van de softwareprojecten hun schatting, met een gemiddelde kostenoverschrijding van 189%. De belangrijkste oorzaak houdt al decennia stand: werk dat begint met bouwen voordat het scopen af is. De fasen hieronder staan in een volgorde die precies dat voorkomt.

Fase 1: eisen en scoping

Alles wat volgt rust op deze fase, die jouw proces omzet in een geschreven specificatie. Schermen, gebruikersrollen, bedrijfsregels, koppelingen en acceptatiecriteria, allemaal in gewone taal die je kunt lezen en nakijken.

Hier wordt een project gewonnen of verloren. Een vage scope ("bouw ons een portaal") is de manier waarop projecten in nacalculatie uit de hand lopen, want elke onuitgesproken aanname wordt later een wijzigingsverzoek. Een scherpe scope benoemt wat de software doet en, net zo belangrijk, wat hij niet doet. Als opdrachtgever is het jouw taak in deze fase om te vangen wat ontbreekt zolang het nog een zin op papier is, geen functie om opnieuw te bouwen. Eis dat de scope acceptatiecriteria bevat: de precieze voorwaarden waaraan de afgeronde software moet voldoen. Die criteria worden de test in fase vier, en daarom voorkomt ze nu opschrijven ruzie later.

Goed teken: de leverancier stelt ongemakkelijke, precieze vragen over randgevallen (wat gebeurt er met een deelbetaling, een geannuleerde bestelling, een gebruiker met twee rollen). Slecht teken: hij knikt mee en belooft het "tijdens de ontwikkeling wel uit te zoeken".

Fase 2: ontwerp en architectuur

Nu het wat vaststaat, bepaalt deze fase het hoe. Het datamodel, de integratieaanpak, het beveiligingsmodel en, voor alles wat grenzen oversteekt, het internationalisatieplan.

De meeste van deze keuzes zijn onzichtbaar voor jou en duur om later te veranderen, en daarom vallen ze vóór elke functie, niet tijdens. Het datamodel bepaalt wat de software wel en niet kan weergeven. De integratieaanpak bepaalt hoe schoon hij praat met je ERP, je betaalprovider of je vervoerders. Het beveiligingsmodel bepaalt wie wat mag zien en doen. En als de software ooit meer dan één taal of valuta gaat bedienen, is dit de fase waarin die mogelijkheid in het fundament komt of er later pijnlijk aan wordt vastgeplakt. Je zult de meeste van deze beslissingen niet in detail nalezen, maar je hoort te weten dat ze bewust zijn genomen, en te kunnen vragen waarom.

Fase 3: bouw

Dit is de fase die de meeste mensen voor zich zien bij "ontwikkeling": de software wordt echt geschreven. In ons geval betekent dat ontwikkeling met AI (kunstmatige intelligentie), waarbij ingenieurs AI-codeertools aansturen die de software genereren, en daarna elk onderdeel van de output nakijken, testen en verstevigen.

Het enige waar je tijdens de bouw op moet staan, is zichtbaarheid. Je hoort werkende software te zien tijdens deze fase, geen zwarte doos die op de dag van de lancering opengaat. Regelmatige afstemming met de scope vangt afwijking vroeg op, wanneer die goedkoop te corrigeren is. Een proces dat wekenlang stilvalt en weer opduikt met een afgerond product is een proces dat zijn scope-problemen verbergt tot het te laat is om ze zonder kosten te herstellen. Hoe wij deze fase draaien, inclusief hoe door AI geschreven code wordt nagelezen voordat die jou bereikt, lees je op hoe we scopen, bouwen en reviewen.

Fase 4: acceptatietest

Nu wordt de software gecontroleerd tegen de acceptatiecriteria uit fase één. Deze fase is de user acceptance testing (UAT): jij, of je team, controleert of de software doet wat de scope zei, voordat hij live gaat. Voor de definitie zie je het item user acceptance testing (in het Engels).

Dit is de fase die opdrachtgevers het vaakst onderschatten, en de fase die hen het meest beschermt. Is fase één helder geschreven, dan kent fase vier geen ruzie: elk criterium slaagt of niet, en er is een document om naar te wijzen. Was fase één vaag, dan komen de meningsverschillen hier boven, op het slechtst denkbare moment. Test tegen echte scenario's, niet alleen het ideale verloop: de rare bestelling, de ongewone klant, de data die niet in het hokje past. Software die een demo doorstaat, kan alsnog struikelen op een doordeweekse dinsdag. Beter nu ontdekken, met de leverancier aan zet, dan in productie.

Fase 5: oplevering en onderhoud

De bouw eindigt met uitrol, documentatie, training en, op een maatwerkproject, code-eigendom (in het Engels): de volledige broncode en de repository in jouw handen. Dat is wat het bezitten van software scheidt van het huren ervan.

Een echte oplevering omvat de code, de infrastructuurconfiguratie en de aantekeningen die een nieuwe ontwikkelaar nodig heeft om hem over te nemen, geen kale login op een draaiende app. Vanaf daar is onderhoud een keuze, geen afhankelijkheid. Software in eigendom heeft nog steeds hosting, updates en de incidentele wijziging nodig, en dat kan een onderhoudsabonnement met het oorspronkelijke team zijn, een interne ontwikkelaar, of een heel andere leverancier, want de code is van jou. Vraag elke leverancier, voordat je begint, precies wat je bij de oplevering krijgt. Het antwoord vertelt je of je een bezit koopt of een leiband.

Hoe AI-ondersteuning het tijdpad verandert, niet de fasen

AI-ondersteunde ontwikkeling heeft het midden van dit proces flink samengeperst, zonder één fase te schrappen. De bouwfase die vroeger maanden duurde, duurt nu weken: een gescopete workflow-automatisering in twee tot drie weken, een volledige webapplicatie in drie tot zes, een meertalig platform in vijf tot acht, van goedgekeurde scope tot productie.

Wat niet veranderde, is de discipline rond de bouw. Scoping komt nog steeds eerst, want AI kan geen eis raden die je niet hebt uitgesproken. De acceptatietest komt nog steeds als laatste, want gegenereerde code moet net zo goed geverifieerd worden als elke andere. De oplevering geeft nog steeds code die je bezit. Het typen werd sneller; het oordeel, de architectuur en de verantwoordelijkheid bleven menselijk. Een leverancier die AI gebruikt om het scopen of het testen over te slaan, gaat niet sneller, hij verschuift alleen het risico naar jou.

Veelgestelde vragen over het ontwikkelproces van software

Wat zijn de fasen van het ontwikkelproces van maatwerksoftware?

Vijf, in volgorde: eisen en scoping, ontwerp en architectuur, bouw, acceptatietest, en oplevering met onderhoud. Samen vormen ze de software development life cycle. De namen verschillen per leverancier en methode, maar de volgorde ligt vast, en een fase overslaan is waar projecten falen.

Wat is de software development life cycle (SDLC)?

De software development life cycle is de volledige reeks die een bouw volgt, van eisen tot een draaiend, onderhouden systeem. Agile methoden herhalen de fasen in korte cycli; projecten met een vaste scope doorlopen ze één keer. Hoe dan ook omvat het scoping, ontwerp, bouw, testen, uitrol en onderhoud.

Welke fase van softwareontwikkeling is het belangrijkst?

Eisen en scoping. Een vage scope is de belangrijkste oorzaak van overschrijdingen en geschillen, want elke onuitgesproken aanname wordt later een kostbare wijziging. Tijd die je besteedt aan een scherpe scope, met heldere acceptatiecriteria, betaalt zich terug in elke volgende fase, vooral bij het testen.

Wat is user acceptance testing (UAT)?

User acceptance testing is de fase waarin jij, de opdrachtgever, de afgeronde software controleert tegen de acceptatiecriteria die tijdens de scoping zijn afgesproken, voordat hij live gaat. Test echte scenario's, inclusief de lastige randgevallen, niet alleen het pad uit de demo. Heldere criteria die vroeg zijn opgeschreven, maken deze fase snel en zonder ruzie.

Verandert AI-ondersteunde ontwikkeling het proces?

Het perst de bouwfase samen van maanden naar weken, maar de fasen blijven hetzelfde. Scoping komt nog steeds eerst, de acceptatietest nog steeds als laatste, en code-eigendom wordt nog steeds bij de oplevering geleverd. AI versnelt het typen; het menselijk oordeel, de architectuur en de review blijven. Fasen overslaan is geen snelheid, het is verschoven risico.

Begin met een scope die je kunt lezen

Vertel ons het proces dat je gebouwd wilt hebben, en wij zetten het om in een geschreven scope met acceptatiecriteria die je goedkeurt voordat er één regel code wordt geschreven, daarna een vaste prijs en een opleverdatum in weken. Is een maatwerkbouw niet de juiste keuze, dan zeggen we dat, zoals we uitleggen in wanneer maatwerksoftware bouwen.

Vraag een offerte tegen vaste prijs aan →