Softwareontwikkeling wordt vaak gezien als een technisch proces waarin programmeurs code schrijven. In werkelijkheid is het een bestuurlijk, analytisch en technisch voortbrengingsproces waarin een organisatievraag systematisch wordt vertaald naar een werkend en beheersbaar informatiesysteem. Het schrijven van code vormt daarin slechts een van de fasen.
Professionele softwareontwikkeling onderscheidt zich niet door snelheid of technologische innovatie alleen, maar door de mate waarin het proces logisch is opgebouwd en beheerst wordt uitgevoerd. Elke fase heeft een duidelijke functie, een eigen beslismoment en concrete producten die de basis vormen voor de volgende stap. Wanneer deze samenhang ontbreekt, ontstaan interpretatieverschillen, herwerk, budgetoverschrijdingen en kwaliteitsproblemen.
Het ontwikkelproces volgt in essentie een vaste causale lijn:
- Eerst wordt vastgesteld wat nodig is;
- Vervolgens wordt bepaald of en hoe dit verantwoord kan worden gerealiseerd;
- Daarna wordt de gekozen oplossing gestructureerd en gemodelleerd;
- Het ontwerp wordt vervolgens gerealiseerd in software;
- De realisatie wordt getoetst aan de oorspronkelijke eisen;
- Tot slot wordt bestuurlijk vastgesteld of het systeem geschikt is voor gebruik.
Deze logica vormt de ruggengraat van elk professioneel ontwikkeltraject. Onderstaand wordt deze keten nader uiteengezet.
1. Specificeren
Ieder softwareproject begint met een behoefte. Die behoefte kan voortkomen uit inefficiënte processen, veranderende regelgeving, groeiende informatiebehoefte, concurrentiedruk of strategische vernieuwing. In eerste instantie is deze behoefte vaak globaal en ambigu. Er wordt gesproken over verbetering, versnelling of digitalisering, maar zelden in termen van concrete systeemeisen.
Specificeren is het proces waarin deze impliciete behoefte wordt vertaald naar expliciete, toetsbare en samenhangende eisen. Dit is geen technische activiteit, maar een analytisch en bestuurlijk proces. De kernvraag luidt niet hoe het systeem wordt gebouwd, maar wat het systeem moet betekenen voor de organisatie.
In deze fase worden fundamentele vragen beantwoord:
- Welke processen moeten worden ondersteund?
- Welke informatie moet worden vastgelegd en verwerkt?
- Welke beslissingen moet het systeem faciliteren?
- Welke kwaliteit wordt verwacht?
Om volledigheid te waarborgen worden eisen doorgaans onderscheiden in drie categorieën.
Functionele eisen beschrijven wat het systeem moet doen. Zij definiëren de taken, processen en informatiestromen die ondersteund moeten worden.
Niet functionele eisen beschrijven hoe goed het systeem moet functioneren. Dit betreft onder meer prestaties, betrouwbaarheid, beschikbaarheid, beveiliging, onderhoudbaarheid en gebruiksvriendelijkheid. Juist deze eisen bepalen in sterke mate de totale kosten over de levensduur van het systeem.
Randvoorwaarden en beperkingen beschrijven de context waarbinnen de oplossing moet worden gerealiseerd, zoals budget, wettelijke kaders, bestaande architectuur en organisatorische beleidslijnen.
Het resultaat van deze fase is een Programma van Eisen of een formele requirements set. Dit document fungeert als normatief referentiepunt voor het gehele vervolgtraject. Zonder expliciete specificatie ontbreekt immers de maatstaf waaraan later kan worden getoetst.
Wanneer duidelijk is wat het systeem moet opleveren, ontstaat echter direct een volgende vraag. Is dit haalbaar en zo ja, op welke wijze?
2. Definitiestudie
Het vastleggen van eisen impliceert nog geen keuze voor een oplossing. Zeker bij complexe of organisatiekritische systemen bestaan vaak meerdere oplossingsrichtingen. Het kan gaan om nieuwbouw, hergebruik van bestaande systemen, aanschaf van standaardsoftware of uitbesteding aan externe partijen.
De definitiestudie vormt de schakel tussen wens en ontwerp. In deze fase wordt onderzocht welke oplossingsrichting het meest geschikt is, gegeven de vastgestelde eisen en organisatorische context.
De analyse richt zich op drie samenhangende dimensies:
- Technische haalbaarheid: Kan de gewenste functionaliteit gerealiseerd worden met beschikbare technologie, kennis en infrastructuur?
- Economische haalbaarheid: Zijn de investeringen verantwoord in verhouding tot de verwachte baten, inclusief beheer en onderhoudskosten over meerdere jaren?
- Organisatorische inpasbaarheid: Kan de organisatie de verandering dragen. Sluit de oplossing aan bij bestaande processen, competenties en cultuur.
De definitiestudie voorkomt dat een organisatie te vroeg vastloopt in een specifieke technische richting. Door alternatieven expliciet te vergelijken ontstaat een onderbouwde keuze. Deze keuze vormt het fundament voor het ontwerp.
Wanneer de oplossingsrichting is vastgesteld, verschuift de focus van keuze naar concretisering.
3. Ontwerpen
Ontwerpen is het proces waarin de gekozen oplossingsrichting wordt vertaald naar een samenhangend en toetsbaar systeemmodel. Het ontwerp maakt inzichtelijk hoe de eisen concreet worden ingevuld. Ontwerpen kent doorgaans twee niveaus die logisch op elkaar voortbouwen:
- Functioneel ontwerp beschrijft wat het systeem doet binnen het bedrijfsproces. Het legt vast welke functies aanwezig zijn, hoe gegevens worden verwerkt en hoe gebruikers met het systeem interacteren. Tevens wordt de relatie met andere systemen beschreven. Het functioneel ontwerp vormt de inhoudelijke vertaling van de eisen. Hier wordt gecontroleerd of de gekozen oplossingsrichting daadwerkelijk aansluit bij de oorspronkelijke behoefte. Het creëert een gemeenschappelijk begrip tussen business en techniek.
- Technisch ontwerp vertaalt de functionele structuur naar concrete technische keuzes. Hier worden architectuur, technologie, infrastructuur, integratie, beveiliging en schaalbaarheid uitgewerkt. Het technisch ontwerp maakt de oplossing realiseerbaar en beheersbaar. Zodra het ontwerp voldoende is uitgewerkt kan de realisatie starten.
4. Programmeren
Programmeren betreft het proces waarin het ontwerp wordt omgezet in werkende software. In deze fase worden abstracte modellen vertaald naar concrete instructies in een programmeertaal.
Hoewel programmeren vaak wordt gezien als het centrale onderdeel van softwareontwikkeling, is het sterk afhankelijk van de kwaliteit van voorgaande fasen. Onduidelijke eisen of een zwak ontwerp leiden vrijwel altijd tot interpretatieproblemen en herwerk.
Professioneel programmeren kenmerkt zich door discipline en kwaliteit. Het gaat niet alleen om het correct implementeren van functionaliteit, maar ook om leesbare code, robuuste foutafhandeling, onderhoudbaarheid en uitbreidbaarheid.
Wanneer de software is gerealiseerd, moet worden vastgesteld of het systeem daadwerkelijk voldoet aan de eisen.
5. Testen
Testen is het proces waarin wordt vastgesteld of het gerealiseerde systeem voldoet aan de eerder vastgestelde eisen. Testen is een controlemechanisme dat inzicht geeft in kwaliteit en risico’s.
Testen vindt plaats op meerdere niveaus, namelijk:
- Unittests controleren afzonderlijke onderdelen van de software.
- Integratie en systeemtests beoordelen de samenhang tussen onderdelen en de werking van het systeem als geheel.
- Acceptatietests richten zich op het functioneren van het systeem binnen het bedrijfsproces.
Testen grijpt altijd terug op de oorspronkelijke specificaties. Zonder duidelijke eisen kan immers niet objectief worden vastgesteld of het systeem voldoet.
Wanneer uit testen blijkt dat het systeem voldoet aan de eisen en resterende afwijkingen acceptabel zijn, kan de laatste stap worden gezet.
6. Accepteren
Acceptatie is het formele moment waarop wordt vastgesteld dat het systeem geschikt is voor ingebruikname. Het vormt de overgang van projectfase naar reguliere bedrijfsvoering.
Acceptatiecriteria zijn rechtstreeks afgeleid van het Programma van Eisen. Daarmee sluit de keten zich logisch. Tijdens acceptatie wordt niet alleen gekeken naar technische werking, maar ook naar gebruik in realistische situaties, prestaties onder belasting en gebruikerservaring.
Na acceptatie wordt het systeem overgedragen aan beheer. De verantwoordelijkheid verschuift van ontwikkelteam naar organisatie. Het systeem moet vanaf dat moment stabiel functioneren binnen de dagelijkse operatie.
De kwaliteit van softwareontwikkeling wordt bepaald door de mate waarin deze procesketen zorgvuldig en consistent wordt doorlopen. Wanneer elke fase voortbouwt op duidelijke resultaten uit de vorige fase ontstaat een beheerst en kwalitatief sterk ontwikkelproces.
Winstgevendheid verhogen en uw bedrijf in waarde laten toenemen?
UBS Business Value Creation Services ondersteunt organisaties bij het verhogen van winst- en bedrijfswaarde. Ons team focust zich hierbij op domeinen die de grootste impact hebben op het bedrijfsresultaat. Lees meer →
Reageer op dit bericht