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. Veel softwareprojecten kunnen worden beschreven aan de hand van vijf terugkerende activiteiten: scoping, ontwerp, bouw, acceptatietest en oplevering; de precieze indeling en volgorde verschillen per methode en project. De namen verschillen per leverancier. Wie deze activiteiten kent, onderscheidt een serieus proces van een vrijblijvend 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 activiteiten in korte, herhalende cycli, met overlap tussen fasen; een bouw met een vaste scope doorloopt ze doorgaans één keer, bewust. Het overslaan of onvoldoende uitwerken van een van deze activiteiten kan het risico op problemen vergroten. Voor de volledige definitie zie je het item software development life cycle.

Het belang van scoping is oud en goed gedocumenteerd, al vraagt het cijfermateriaal om precisie. Het oorspronkelijke CHAOS-rapport van de Standish Group (1994) rapporteerde dat 52,7% van de onderzochte projecten als "challenged" werd aangemerkt, met een gemiddelde kostenoverschrijding van 189%; latere methodologische review concludeert dat dit cijfer waarschijnlijk te hoog is om representatief te zijn voor typische softwareprojecten, mede door een steekproef die mogelijk sterk overhelt naar mislukte projecten. Het rapport noemde onvolledige eisen, gebrek aan gebruikersinbreng en veranderende specificaties als door respondenten genoemde factoren bij problematische projecten, wat geen universele of tijdloze causaliteitsclaim ondersteunt, maar wel de aandacht voor scoping in de fasen hieronder onderbouwt.

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, 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 NCSC beschrijft veilige softwareontwikkeling niet als één losse controle, maar als een geheel van organisatorische maatregelen, toepassingsgerichte beveiliging en evaluatie-, meet- en beheerprocessen; die aanpak hoort al in deze fase thuis. 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. Wanneer persoonsgegevens worden verwerkt, moeten privacy by design en privacy by default en passende technische en organisatorische beveiligingsmaatregelen al bij deze ontwikkeling worden meegenomen, en voor organisaties die onder de Cyberbeveiligingswet vallen, omvat de zorgplicht ook beveiliging bij het ontwikkelen en onderhouden van netwerk- en informatiesystemen, inclusief passende maatregelen voor kwetsbaarheden en updates. 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 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. In deze fase wordt de software aan vooraf vastgelegde eisen en acceptatiecriteria getoetst voordat ingebruikname plaatsvindt; de concrete testvorm en verantwoordelijkheden moeten per project worden vastgelegd. 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, niet alleen het ideale verloop: 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 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, geen kale login op een draaiende app. Volledige broncode en overdrachtsdocumentatie kunnen de overstap naar een andere leverancier vergemakkelijken, maar hosting, licenties, specialistische kennis, beveiligingsupdates en operationele afhankelijkheden kunnen blijven bestaan. 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, niet de fasen

AI-ondersteunde ontwikkeling kan het midden van dit proces flink samenpersen, zonder één fase te schrappen. In onze eigen projecten zien we soms kortere doorlooptijden dan de maanden die de bouwfase vroeger vergde: bijvoorbeeld 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. Deze termijnen zijn indicatief en hangen af van scope, integraties, kwaliteits- en beveiligingseisen en beschikbare capaciteit.

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. AI kan delen van het schrijfwerk versnellen, maar menselijke beoordeling, architectuurkeuzes, testen en verantwoordelijkheid blijven noodzakelijk. 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?

Veel softwareontwikkelprocessen bevatten activiteiten voor eisen en scoping, ontwerp en architectuur, bouw, acceptatietest, en oplevering met onderhoud. Samen vormen ze de software development life cycle. De benaming, volgorde en mate van herhaling verschillen per methode en project; bij Agile worden deze activiteiten doorgaans in iteraties uitgevoerd, en het onvoldoende uitwerken van een activiteit kan het risico op problemen vergroten.

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 wegen zwaar. Een vage scope kan bijdragen aan overschrijdingen en geschillen, want elke onuitgesproken aanname wordt later een kostbare wijziging; de beschikbare bronnen stellen echter geen universele rangorde van oorzaken vast. Tijd die je besteedt aan een scherpe scope, met heldere acceptatiecriteria, betaalt zich doorgaans 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 toetst aan 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?

AI-ondersteuning kan de bouwfase flink bekorten, maar de fasen blijven hetzelfde en de doorlooptijd hangt af van scope, integraties, beveiliging, gegevens, review en acceptatie. Scoping komt nog steeds eerst, de acceptatietest nog steeds als laatste, en code-eigendom wordt nog steeds bij de oplevering geleverd. AI kan bepaalde programmeeractiviteiten versnellen, maar menselijke beoordeling, architectuurkeuzes, testen en verantwoordelijkheid blijven in dit proces noodzakelijk. 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 →