Planning & Requirements: Full lesson content. # Casussen ## Casus 1 [Section titled “Casus 1”](#casus-1) Een buurtbewoner van het district Wanica dient een bewijs van goed gedrag te overleggen voor de aanvraag van een visum. Hij vraagt dit aan bij zijn districtscommissariaat met de vereiste documenten, zoals een ID kaart en een nationaliteitsverklaring. Na de aanvraag kan hij het bewijs na weken persoonlijk ophalen indien goedgekeurd en tegen een specifieke betaling. Het bovenstaande zal in de toekomst via een website aangevraagd worden. Hij kan de aanvraag online doen en tevens online betalen. Na de online betaling ontvangt hij een bevestiging van de bestelling op zijn ingevulde e-mailadres of mobiele nummer. ## Casus 2 [Section titled “Casus 2”](#casus-2) In Suriname is het proces van grondaanvragen inmiddels gedigitaliseerd. Aanvragers kunnen hun aanvraag online indienen, samen met de vereiste documenten zoals een ID-kaart, nationaliteitsverklaring en GLIS-documenten. Na het indienen van de aanvraag ontvangen zij een bevestigingsmail met een aanvraagnummer. De status van de aanvraag wordt vervolgens handmatig door een medewerker van Grondzaken via e-mail gecommuniceerd. Momenteel bevindt het systeem zich in een transitieperiode, waarbij veel van de communicatie en updates nog handmatig plaatsvinden. De uitdaging is om de digitale ervaring te verbeteren door aanvragers in staat te stellen hun aanvraagstatus direct online in te zien, zonder afhankelijk te zijn van e-mailupdates. # Casussen ## Casus 1 [Section titled “Casus 1”](#casus-1) Een buurtbewoner van het district Wanica dient een bewijs van goed gedrag te overleggen voor de aanvraag van een visum. Hij vraagt dit aan bij zijn districtscommissariaat met de vereiste documenten, zoals een ID kaart en een nationaliteitsverklaring. Na de aanvraag kan hij het bewijs na weken persoonlijk ophalen indien goedgekeurd en tegen een specifieke betaling. Het bovenstaande zal in de toekomst via een website aangevraagd worden. Hij kan de aanvraag online doen en tevens online betalen. Na de online betaling ontvangt hij een bevestiging van de bestelling op zijn ingevulde e-mailadres of mobiele nummer. ### Uitwerking [Section titled “Uitwerking”](#uitwerking) ## Casus 2 [Section titled “Casus 2”](#casus-2) In Suriname is het proces van grondaanvragen inmiddels gedigitaliseerd. Aanvragers kunnen hun aanvraag online indienen, samen met de vereiste documenten zoals een ID-kaart, nationaliteitsverklaring en GLIS-documenten. Na het indienen van de aanvraag ontvangen zij een bevestigingsmail met een aanvraagnummer. De status van de aanvraag wordt vervolgens handmatig door een medewerker van Grondzaken via e-mail gecommuniceerd. Momenteel bevindt het systeem zich in een transitieperiode, waarbij veel van de communicatie en updates nog handmatig plaatsvinden. De uitdaging is om de digitale ervaring te verbeteren door aanvragers in staat te stellen hun aanvraagstatus direct online in te zien, zonder afhankelijk te zijn van e-mailupdates. ### Uitwerking [Section titled “Uitwerking”](#uitwerking-1) # DevOps DevOps is een combinatie van **Development** (ontwikkeling) en **Operations** (beheer). Het is een **werkwijze en cultuur** binnen IT waarbij ontwikkelaars en systeembeheerders **samenwerken** om software sneller, betrouwbaarder en continu te kunnen opleveren.  ### Kernideeën [Section titled “Kernideeën”](#kernideeën) * **Automatisering** van bouwen, testen, deployen en monitoren. * **Continue integratie (CI)** en **continue levering (CD)**. * **Samenwerking** tussen teams in plaats van silo’s. * **Snelle feedback** en continue verbetering. ### Doel [Section titled “Doel”](#doel) Kortere ontwikkelcycli, hogere kwaliteit, en stabielere releases. ### Kernbegrippen [Section titled “Kernbegrippen”](#kernbegrippen) * CI (Continuous Integration): automatische build en tests bij codewijzigingen. * CD (Continuous Delivery/Deployment): automatisering van het releaseproces tot staging/production. * IaC (Infrastructure as Code): infrastructuur definiëren en beheren met code (bijv. Terraform, CloudFormation). * Immutable infrastructure: veranderingen door nieuwe images of deployments, niet door in-place wijzigingen. ### Praktische principes [Section titled “Praktische principes”](#praktische-principes) * Automatiseren zoveel mogelijk: builds, tests, linting, security checks, deployments. * Kleine, frequente releases (trunk-based development / feature flags). * Observability: metrics, logs en traces als eerste-class citizens. * Fail fast & recover fast: goede rollback strategieën en health checks. * Securify early: shift-left security (SAST, dependency checks). # Planning & Requirements > Introductie tot Planning & Requirements Welkom bij het programmaonderdeel Planning & Requirements. ## Leerdoelen [Section titled “Leerdoelen”](#leerdoelen) 1. De fasen van de software development lifecycle (SDLC) uitwerken. 2. De functionele en niet functionele randvoorwaarden (requirements) toelichten. 3. De randvoorwaarden van een IT-oplossing vaststellen. 4. Een plan om voor een praktijksituatie een webapplicatie te ontwikkelen, maken. 5. Aan de hand van onderzoek de requirements voor een webapplicatie in kaart brengen. ## Beroepsproduct [Section titled “Beroepsproduct”](#beroepsproduct) * Plan van aanpak * Requirementdocument (incl. ontwerp) * Presentatie * Individuele bevraging [Meer info in SHL](https://unasat.notion.site/DevOps-28450cdc0bfd80a299eddad976bf5fc0#28450cdc0bfd8000ac62c5d28dfdc0af) ## Bronnen [Section titled “Bronnen”](#bronnen) * **Mastering the Requirements Process** * Auteurs: Suzanne Robertson, James Robertson * ISBN: 978-0-321-81574-3 # Process ### Overzicht van de fases [Section titled “Overzicht van de fases”](#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 [Section titled “1) Initiatie en intake”](#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 [Section titled “2) Probleem- en contextanalyse”](#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 [Section titled “3) Stakeholders en doelgroep”](#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 [Section titled “4) Scope en afbakening”](#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) [Section titled “5) Eisen en wensen (requirements)”](#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](/docs/pr/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 [Section titled “6) Risico’s en aannames”](#6-risicos-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 [Section titled “7) Planning en mijlpalen”](#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](/docs/pr/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 [Section titled “8) Team en rollen”](#8-team-en-rollen) * Doel: Heldere verantwoordelijkheden en samenwerking. * Oplevering: RASCI/rollenmatrix, vergaderritme, werkafspraken. * Benodigd: Teambeschikbaarheid, vaardigheden. Zie ook: [Rollen](/docs/pr/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 [Section titled “9) Architectuur en technologiekeuze”](#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) [Section titled “10) Ontwerp (UX/UI, data, API)”](#10-ontwerp-uxui-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 [Section titled “11) Proof of Concept / MVP”](#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) [Section titled “12) Implementatie (werkafspraken en code)”](#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 [Section titled “13) Testen”](#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 [Section titled “14) CI/CD en kwaliteitsbewaking”](#14-cicd-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](/docs/pr/devops) Checklist: * [ ] Pipeline faalt bij lint/test fouten, drempelwaarde voor coverage * [ ] Artefacten en release-notes automatisch * [ ] Rollback/feature toggles, monitoring na deploy ## 15) Documentatie [Section titled “15) Documentatie”](#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 [Section titled “16) Oplevering en acceptatie”](#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 [Section titled “17) Beheer en onderhoud”](#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 [Section titled “18) Reflectie en evaluatie”](#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 [Section titled “Handige templates”](#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 # Requirements  ## Functional Requirements [Section titled “Functional Requirements”](#functional-requirements) Een functionele eis beschrijft een handeling die het product moet uitvoeren om nuttig te zijn voor de gebruiker — deze eisen komen voort uit het werk dat je stakeholders moeten doen. * Dingen die het product moet doen * Specificeert wat het systeem moet doen * Handelingen die het product moet uitvoeren * Afgeleid van het hoofddoel van het product * Geen kwaliteitseigenschap * Wordt gekenmerkt door werkwoorden ## Voorbeelden [Section titled “Voorbeelden”](#voorbeelden) * Het systeem moet gebruikers laten inloggen met e‑mail en wachtwoord. * Het systeem moet een bevestigingsmail sturen na elke bestelling. * De gebruiker moet producten kunnen zoeken op naam en categorie. * Het systeem moet maandelijkse rapportages genereren in PDF‑formaat. * De applicatie moet betalingen kunnen verwerken via Uni5Pay+ en creditcard. * De student moet zijn cijfers online kunnen raadplegen. ## Non-functional Requirements [Section titled “Non-functional Requirements”](#non-functional-requirements) Niet-functionele eisen zijn eigenschappen of kwaliteiten die het product moet hebben om acceptabel te zijn voor de eigenaar en gebruiker. * In sommige gevallen zijn niet-functionele eisen — zoals performance, look-and-feel, usability, security en juridische eigenschappen — cruciaal voor het succes van het product. * Soms zijn het eisen omdat ze het product verbeteren of aantrekkelijker maken. * Soms zorgen ze ervoor dat het product bruikbaar is. * Eigenschappen of kwaliteiten die het systeem moet hebben. * Worden gekenmerkt door bijvoeglijke naamwoorden. * Checklist: * Look-and-feel * usability * performance * onderhoudbaarheid * portabiliteit ## Voorbeelden [Section titled “Voorbeelden”](#voorbeelden-1) * De website moet binnen 2 seconden laden bij normaal gebruik. (performance) * Het systeem moet 24/7 beschikbaar zijn met een uptime van minimaal 99,5%. (betrouwbaarheid) * De gebruikersinterface moet intuïtief en eenvoudig te gebruiken zijn zonder training. (usability) * Gevoelige gegevens moeten versleuteld worden opgeslagen volgens de ISO richtlijnen. (security, juridisch) * De applicatie moet onderhoudbaar zijn zodat een ontwikkelaar in < 1 dag een eenvoudige wijziging kan doorvoeren. (onderhoudbaarheid) * De oplossing moet op zowel mobiele apparaten als desktop goed werken. (portabiliteit / compatibiliteit) ## Casus 1 [Section titled “Casus 1”](#casus-1) Een buurtbewoner van het district Wanica dient een bewijs van goed gedrag te overleggen voor de aanvraag van een visum. Hij vraagt dit aan bij zijn districtscommissariaat met de vereiste documenten, zoals een ID kaart en een nationaliteitsverklaring. Na de aanvraag kan hij het bewijs na weken persoonlijk ophalen indien goedgekeurd en tegen een specifieke betaling. Het bovenstaande zal in de toekomst via een website aangevraagd worden. Hij kan de aanvraag online doen en tevens online betalen. Na de online betaling ontvangt hij een bevestiging van de bestelling op zijn ingevulde e-mailadres of mobiele nummer. ### Uitwerking [Section titled “Uitwerking”](#uitwerking) # 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 [Section titled “1. Planning”](#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 [Section titled “2. Analysis”](#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 [Section titled “3. Design”](#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 [Section titled “4. Implementation”](#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 [Section titled “5. Testen”](#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 [Section titled “6. Deployment”](#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 [Section titled “7. Maintenance”](#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 [Section titled “Bronnen”](#bronnen) * ISO/IEC 12207 (software lifecycle processes) * DevOps- en Agile-praktijken voor continue levering en verbetering