SDLC

SDLC staat voor Software Development Life Cycle.

Het is het stapsgewijze proces dat wordt gevolgd om software te plannen, ontwikkelen, testen en onderhouden.

De standaardfasen zijn:

1. Planning – Doelen, scope en resources bepalen.
2. Analysis – Functionele en niet-functionele eisen vastleggen.
3. Design – Architectuur, databases, interfaces en systeemstructuur uitwerken.
4. Implementation – Code schrijven op basis van het ontwerp.
5. Testen – Controleren of de software correct werkt en voldoet aan de eisen.
6. Deployment – De software wordt uitgerold naar gebruikers.
7. Maintenance – Fouten herstellen, updates uitvoeren, prestaties verbeteren.

1. Planning

Doel

• Vaststellen waarom het project belangrijk is, welke problemen het oplost en welke doelen behaald moeten worden.

Belangrijkste activiteiten

• Stakeholderidentificatie: wie heeft belang bij het project?
• Business case en haalbaarheidsstudie: kosten, baten en risicoanalyse.
• Scope-definitie: wat hoort wél en wat hoort níet bij het project.
• Resourceplanning: team, budget, tijdlijn en benodigde tooling.

Deliverables

• Projectopdracht of business case
• Initiële scope-omschrijving en milestones
• Risicoanalyse en budgetraming

Stakeholders

• Producteigenaar/business, projectmanager, technisch architect, financiën, potentiële eindgebruikers.

Best practices

• Begin met minimale scope (MVP) en plan iteraties.
• Betrek eindgebruikers vroeg om veronderstellingen te valideren.

Veelvoorkomende valkuilen

• Te brede scope (scope creep) waardoor deadlines en budgetten ontsporen.
• Onvoldoende aandacht voor niet-functionele eisen (security, performance).

2. Analysis

Doel

• Verzamelen en verfijnen van functionele en niet-functionele eisen zodat het team precies weet wat gebouwd moet worden.

Belangrijkste activiteiten

• Requirements elicitation (verzamelen): interviews, workshops, user stories en use cases.
• Prioritering: MoSCoW (Must/Should/Could/Won’t), of backlog grooming.
• Validatie: review met stakeholders en prototyping voor onduidelijke onderdelen.

Deliverables

• Functionele requirements (user stories, acceptatiecriteria)
• Niet-functionele requirements (performance, security, schaalbaarheid)

Stakeholders

• Businessanalist, product owner, eindgebruikers, security officer, operations.

Best practices

• Schrijf acceptatiecriteria per user story zodat testen vanaf start duidelijk is.
• Gebruik prototypes of wireframes om UI-eisen te toetsen.

Veelvoorkomende valkuilen

• Onduidelijke of tegenstrijdige eisen.
• Te laat betrekken van operations/security waardoor revisies nodig zijn.

3. Design

Doel

• Technische vertaalslag van eisen naar een uitvoerbaar systeemontwerp: architectuur, datamodellen en componentinterfaces.

Belangrijkste activiteiten

• Architectuurbeslissingen: monolith vs. microservices, deploymentmodel, data-architectuur.
• Detailontwerp: API-specificaties, database-schema’s, UI-ontwerpen en integratiepunten.
• Proof-of-concept (PoC) voor technische risico’s.

Deliverables

• Architectuurdiagrammen (component, deployment)
• API-contracten en sequence diagrams
• Database-schema’s en datamigratieplan

Stakeholders

• Technisch architect, backend/frontend-ontwikkelaars, QA, devops.

Best practices

• Documenteer architectuurrationales (decision records) zodat toekomstige wijzigingen begrijpelijk blijven.
• Hou ontwerp modulair en testbaar.

Veelvoorkomende valkuilen

• Over-engineering van het ontwerp (te complex voor de werkelijke behoefte).
• Onvoldoende aandacht voor operationele aspecten zoals logging, monitoring en back-up.

4. Implementation

Doel

• De daadwerkelijke bouw van het systeem: implementeren van features conform ontwerp en eisen.

Belangrijkste activiteiten

• Opzetten van de ontwikkelomgeving en CI/CD-pijplijnen.
• Iteratief ontwikkelen volgens de gekozen methodiek (Scrum, Kanban).
• Code reviews, pair programming en refactoring.

Deliverables

• Werkende code in versiebeheer
• Unit- en integratietests
• Build-artifacts en container images

Stakeholders

• Ontwikkelaars, teamlead, QA, CI/CD-engineer.

Best practices

• Kleine, frequente commits en pull requests met duidelijke beschrijvingen.
• Automatische testuitvoering in CI en het afdwingen van kwaliteitschecks.

Veelvoorkomende valkuilen

• Gebrek aan testdekking en technische schuld die zich opstapelt.
• Ontwikkeling zonder integratie met ops/CI leidt tot integratieproblemen later.

5. Testen

Doel

• Verifiëren dat de software voldoet aan de eisen en vrij is van kritieke fouten voordat deze naar productie gaat.

Belangrijkste activiteiten

• Unit-, integratie- en end-to-end testen
• Performance- en loadtests voor niet-functionele eisen
• Security testing (vulnerability scans, pen-tests) en toegankelijkheidstests
• Acceptatietesten met de business (UAT)

Deliverables

• Testplannen en testcases
• Testrapporten en bugtracking-items
• Testomgevingen die productie zoveel mogelijk nabootsen

Stakeholders

• QA-engineers, ontwikkelaars, product owner, operations

Best practices

• Testautomatisering voor regressietests, met dagelijks of per-commit draaien.
• Meet code coverage, maar focus vooral op relevante en betrouwbare tests.

Veelvoorkomende valkuilen

• Alleen handmatig testen — schaalproblemen en regressies ontstaan sneller.
• Tests die flakey zijn en daardoor vertrouwen in de test-suite ondermijnen.

6. Deployment

Doel

• De software veilig en betrouwbaar naar productie brengen en beschikbaar maken voor eindgebruikers.

Belangrijkste activiteiten

• Release planning en cutover-strategie (blue/green, canary releases)
• Deployment naar productie via CI/CD-pijplijn
• Communicatie met stakeholders en gebruikers over downtime/changes
• Rollback-plannen en monitoring configureren

Deliverables

• Release notes en deployment scripts
• Monitoring en alerting dashboards
• Rollback- of mitigatieprocedure

Stakeholders

• DevOps/Platform engineers, support, product owner, communicatie

Best practices

• Automatische en toetsbare deployments, met imagereproductie en versiebeheer.
• Observability: metrics, logs en traces direct na uitrol controleren.

Veelvoorkomende valkuilen

• Geen rollbackplan of ongeteste deploymentscripts.
• Gebrek aan monitoring waardoor problemen pas laat worden ontdekt.

7. Maintenance

Doel

• Garanderen van beschikbaarheid, stabiliteit en doorlopende verbetering van de software na livegang.

Belangrijkste activiteiten

• Bugfixes en securitypatches
• Systeemonderhoud: updates van afhankelijkheden, database-optimalisaties
• Functionele updates en continue verbetering op basis van gebruikersfeedback
• SLA-ondersteuning en incidentmanagement

Deliverables

• Patch releases en changelogs
• Roadmap-updates en backlog voor toekomstige releases
• Incidentrapporten en post-mortems

Stakeholders

• Support, development, operations, product owner

Best practices

• Voer post-mortems uit na incidenten en gebruik de lessen om processen te verbeteren.
• Houd technische schuld bij en plan tijd in voor refactoring.

Veelvoorkomende valkuilen

• Verwaarlozing van onderhoud waardoor de codebase veroudert en kwetsbaar wordt.
• Te veel ad-hoc fixes zonder terugkerende structurele verbeteringen.

---

Bronnen

• ISO/IEC 12207 (software lifecycle processes)
• DevOps- en Agile-praktijken voor continue levering en verbetering