Process

Overzicht van de fases

• Initiatie en intake
• Probleem- en contextanalyse
• Stakeholders en doelgroep
• Scope en afbakening
• Eisen en wensen (requirements)
• Risico’s en aannames
• Planning en mijlpalen
• Team en rollen
• Architectuur en technologiekeuze
• Ontwerp (UX/UI, data, API)
• Proof of Concept / MVP
• Implementatie (werkafspraken, code)
• Testen (strategie en uitvoering)
• CI/CD en kwaliteitsbewaking
• Documentatie
• Oplevering en acceptatie
• Beheer en onderhoud
• Reflectie en evaluatie

---

1) Initiatie en intake

• Doel: Snappen welk probleem je oplost en wat de aanleiding is.
• Oplevering: Korte projectomschrijving (1 pagina), projectcanvas, eerste doelen (SMART).
• Benodigd: Intakegesprek, bestaande info, globale verwachtingen.

Checklist:

• Eén zin: voor wie, wat, waarom
• Doelstelling SMART geformuleerd
• Randvoorwaarden en constraints genoteerd (tijd, budget, tech, data)
• Succescriteria op hoofdlijnen

Voorbeeldvragen: Wat is precies het probleem? Wie merkt daar last van? Wat gebeurt er als we niets doen? Hoe ziet “succes” eruit?

2) Probleem- en contextanalyse

• Doel: Dieper begrip van het probleem en de omgeving.
• Oplevering: Contextschets, huidige processen, relevante wet-/regelgeving, concurrentie/alternatieven.
• Benodigd: Deskresearch, interviews, bestaande systemen/datasets.

Checklist:

• Current state (as-is) beschreven (processen/systeem)
• Beperkingen en afhankelijkheden benoemd
• Alternatieven/benchmark verkend

3) Stakeholders en doelgroep

• Doel: Weten wie belang hebben en wat ze verwachten.
• Oplevering: Stakeholderlijst met rollen, belangen, invloed; persona’s/gebruikersprofielen.
• Benodigd: Interviews, observaties, workshops.

Checklist:

• Primaire en secundaire stakeholders in kaart
• Contactmomenten/feedbackritme vastgelegd
• Doelgroepbehoeften vertaald naar gebruikersdoelen

4) Scope en afbakening

• Doel: Bepalen wat wel/niet in het project zit.
• Oplevering: Scope statement, in-scope/out-of-scope, duidelijke Definition of Done (DoD).
• Benodigd: Projectdoelen, constraints, prioriteiten.

Checklist:

• Scope is kort en ondubbelzinnig
• Out-of-scope expliciet benoemd (verwachtingsmanagement)
• DoD met acceptatie-eisen per deliverable

5) Eisen en wensen (requirements)

• Doel: Vastleggen wat het systeem moet kunnen (functioneel) en hoe het moet presteren (niet-functioneel).
• Oplevering: Requirementsdocument met prioriteiten (MoSCoW) en acceptatiecriteria.
• Benodigd: Stakeholderinput, procesinzichten, kwaliteitsdoelen.

Zie ook: Requirements

Checklist:

• Functionele eisen (use cases/user stories met “zodat”)
• Niet-functionele eisen (performantie, security, privacy, usability, reliability)
• Prioritering (Must/Should/Could/Won’t)
• Meetbare acceptatiecriteria per eis

6) Risico’s en aannames

• Doel: Verrassingen voorkomen en transparant maken wat je aanneemt.
• Oplevering: Risicolog (kans x impact, mitigatie), aannamelijst met validatieplan.
• Benodigd: Teambrainstorm, ervaring, input stakeholders.

Checklist:

• Top-5 risico’s met mitigatie en eigenaar
• Aannames expliciet + hoe/wanneer valideren (spike, prototype, gesprek)
• Besliscriteria voor “go/no-go” momenten

7) Planning en mijlpalen

• Doel: Realistische route naar oplevering.
• Oplevering: Roadmap, sprintplanning (bij agile), mijlpalen, buffer/tijd voor testen.
• Benodigd: Scope, teamcapaciteit, risks.

Zie ook: Planning

Checklist:

• Korte iteraties (1-2 weken) met demo/review
• Tijd gereserveerd voor testen, refactoren, documentatie
• Heldere mijlpalen (MVP, beta, release)

8) Team en rollen

• Doel: Heldere verantwoordelijkheden en samenwerking.
• Oplevering: RASCI/rollenmatrix, vergaderritme, werkafspraken.
• Benodigd: Teambeschikbaarheid, vaardigheden.

Zie ook: Rollen

Checklist:

• Rollen: Product Owner, Projectleider/Scrum Master, Developers, QA/Tester, UX/UI, DevOps
• Werkafspraken: code reviews, PR-richtlijnen, Definition of Ready/Done
• Communicatiekanalen afgesproken (Slack/Teams, issue tracker)

9) Architectuur en technologiekeuze

• Doel: Verantwoorde, passende technische basis.
• Oplevering: Architectuurschets (C4/diagrammen), tech stack, rationale/ADR’s.
• Benodigd: Kwaliteitseisen, constraints, teamervaring.

Checklist:

• Keuze onderbouwd met eisen (bijv. performance, maintainability, learning curve)
• Spikes/PoC gedaan voor onzekere onderdelen
• Security/privacy-by-design meegenomen

10) Ontwerp (UX/UI, data, API)

• Doel: Zichtbaar maken hoe het gaat werken.
• Oplevering: Wireframes, flows, design tokens, ERD/datamodel, API-contracten (OpenAPI/GraphQL schema’s).
• Benodigd: UX input, data-eisen, integratiebehoeften.

Checklist:

• Belangrijkste schermen en gebruikersflows uitgewerkt
• Datamodel en relaties duidelijk
• API endpoints, payloads en foutcodes vastgelegd

11) Proof of Concept / MVP

• Doel: Snel leren of je aanpak werkt en waarde levert.
• Oplevering: Minimale werkende versie die de kernwaarde demonstreert.
• Benodigd: Afgeslankte scope, testdata, demo.

Checklist:

• MVP-scope afgesproken en haalbaar binnen tijd
• Demo gepland met stakeholders, feedback vastgelegd
• Leerpunten terugzetten naar planning en scope

12) Implementatie (werkafspraken en code)

• Doel: Voorspelbaar en samenwerkend bouwen.
• Oplevering: Repo-structuur, branching-strategie, coding standards, PR-sjabloon.
• Benodigd: Git-platform, CI, linters/formatters.

Checklist:

• Branching: Git Flow of Trunk-based; kleine, frequente PR’s
• Commit conventies (bijv. Conventional Commits)
• Code review regels (2 ogen, checklist, tests verplicht)
• Feature flags waar passend

13) Testen

• Doel: Kwaliteit aantoonbaar maken.
• Oplevering: Teststrategie, testplan, geautomatiseerde tests (unit/integratie/E2E), testdata.
• Benodigd: Testtools/kaders, testomgevingen.

Checklist:

• Unit tests voor kernlogica, integratietests voor interfaces
• End-to-end tests voor kritieke gebruikersflows
• Acceptatietests met stakeholders; performance/security checks waar relevant

14) CI/CD en kwaliteitsbewaking

• Doel: Continu kwaliteit controleren en snel kunnen releasen.
• Oplevering: Pipeline met lint/typecheck/test/build, coverage-rapport, automatische deploy naar test/acceptatie/produktie.
• Benodigd: CI/CD-platform, secretsbeheer.

Zie ook: DevOps

Checklist:

• Pipeline faalt bij lint/test fouten, drempelwaarde voor coverage
• Artefacten en release-notes automatisch
• Rollback/feature toggles, monitoring na deploy

15) Documentatie

• Doel: Kennis overdraagbaar en project navolgbaar maken.
• Oplevering: README (installatie/gebruik), architectuurnotities/ADR’s, API-docs, changelog, gebruikershandleiding.
• Benodigd: Doc-format (Markdown), voorbeelden/screenshots.

Checklist:

• Installatie en run-instructies getest door iemand anders
• Belangrijke beslissingen vastgelegd (waarom)
• Gebruikersdocumentatie afgestemd op doelgroep

16) Oplevering en acceptatie

• Doel: Formele goedkeuring en overname.
• Oplevering: Release, release-notes, acceptatieformulier, overdracht (technisch/gebruik).
• Benodigd: Acceptatiecriteria, planning met opdrachtgever.

Checklist:

• Acceptatiecriteria aantoonbaar gehaald
• Demo + Q&A, bevindingen verwerkt of gepland
• Overdrachtsdocumenten en accounts geregeld

17) Beheer en onderhoud

• Doel: Duurzame werking en continuïteit borgen.
• Oplevering: Beheerplan (updates, monitoring, incidentproces), backup/restore, licenties.
• Benodigd: Toegang tot hosting/monitoring, afspraken met beheer.

Checklist:

• Monitoring/alerts op kritieke paden
• Security updates en afhankelijkhedenbeleid
• Incident- en change-proces afgesproken

18) Reflectie en evaluatie

• Doel: Leren voor volgende iteratie/project en leeruitkomsten onderbouwen.
• Oplevering: Retrospective, leerpunten, verbeteracties, persoonlijke reflectie (HBO-competenties).
• Benodigd: Feedback van stakeholders/coach, meetresultaten.

Checklist:

• Wat ging goed? Wat kan beter? Wat stoppen/starten/continueren?
• Relatie met leeruitkomsten/competenties expliciet maken
• Concrete acties met eigenaar en termijn

---

Handige templates

Projectcanvas (1 pagina):

• Probleem & doelgroep
• Doelen & succescriteria
• Scope (in/out)
• Belangrijkste stakeholders
• Belangrijkste risico’s/aannames
• Tijdlijn/mijlpalen

User story + acceptatiecriteria:

• Als [type gebruiker] wil ik [doel] zodat [waarde].
• Acceptatiecriteria: [concreet, testbaar]

Risicolog (voorbeeldkolommen):

• Risico | Kans | Impact | Score | Mitigatie | Eigenaar | Status

Definition of Done (voorbeeld):

• Code geformatteerd en lint-vrij
• Tests toegevoegd en groen (≥ drempel coverage)
• Review door minimaal 1 teamlid
• Documentatie bijgewerkt
• Geïntegreerd en draait op test/acceptatie

Pull Request checklist (kort):

• Koppeling met issue/user story
• Beschrijving van wijziging en motivatie
• Tests en documentatie bijgewerkt
• Screenshots (UI) of API voorbeelden toegevoegd