Het ontwikkelproces van maatwerksoftware, stap voor stap

Geschreven voor wie de software laat maken. 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 de fasen in korte cycli. Een bouw met een vaste scope doorloopt ze één keer, bewust. Hoe dan ook komen ze in dezelfde volgorde, en wie er een overslaat, loopt vast. Voor de volledige definitie zie je het item software development life cycle.

Het belang van scoping is oud en goed gedocumenteerd. In het oorspronkelijke CHAOS-rapport van de Standish Group (1994) kwam 52,7% van de projecten in de problemen, en die projecten kostten gemiddeld 189% van hun oorspronkelijke raming (een latere review vond dat laatste cijfer waarschijnlijk te hoog). Onvolledige eisen, te weinig inbreng van gebruikers en veranderende specificaties stonden bovenaan de lijst met oorzaken.

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 op te sporen wat ontbreekt zolang het nog een zin op papier is. 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. 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. Verwerkt de software persoonsgegevens, dan horen privacy by design en privacy by default hier al thuis, en valt je organisatie onder de Cyberbeveiligingswet, dan vraagt de zorgplicht ook beveiliging bij het ontwikkelen en onderhouden van je systemen. 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. Regelmatige afstemming met de scope signaleert een afwijking vroeg, 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 getoetst aan 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. Leg de test en de testresultaten vast en voer nieuwe systemen of versies pas na formele acceptatie en goedkeuring door de opdrachtgever in. Voor de definitie zie je het item user acceptance testing.

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 met echte scenario's: de rare bestelling, de ongewone klant, de data die niet in het hokje past. Worden tijdens ontwikkeling, pilots of tests persoonsgegevens in een algoritmisch systeem verwerkt, dan kan een DPIA verplicht zijn; dat geldt volgens de Nederlandse Autoriteit Persoonsgegevens ook voor pilots, testen en proefprojecten. 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: 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, naast een login op een draaiende app. 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 hoeveel praktische onafhankelijkheid je krijgt.

Hoe AI-ondersteuning het tijdpad verandert

AI-ondersteunde ontwikkeling kan het midden van dit proces flink samenpersen, zonder één fase te schrappen. Waar de bouwfase vroeger maanden vergde, gaat een gescopete workflow-automatisering bij ons in twee tot drie weken van goedgekeurde scope naar productie, een volledige webapplicatie in drie tot zes en een meertalig platform in vijf tot acht.

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. 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

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 →