diff --git a/Content/Bijlagen/NPR5326.md b/Content/Bijlagen/NPR5326.md index 32d0aca4..0ace8394 100644 --- a/Content/Bijlagen/NPR5326.md +++ b/Content/Bijlagen/NPR5326.md @@ -14,7 +14,7 @@ De Nederlandse Praktijkrichtlijn "Risicobeheersing bij ontwikkeling en onderhoud | Maatregel 08: Iteratieve ontwikkelaanpak | [$M05$](#m05) | ICTU hanteert een iteratief en incrementeel ontwikkelproces | | Maatregel 09: Geautomatiseerde ontwikkelpijplijn inrichten | [$M07$](#m07) | | | Maatregel 10: Voortdurend voldoen aan de eisen met regressietests | [$M04$](#m04) | | -| Maatregel 11: Voortgangsbewaking met burndown charts | [$M10$](#m10) | Projecten bespreken de voortgang in het wekelijks projectoverleg aan de hand van backlog informatie uit het backlog management systeem | +| Maatregel 11: Voortgangsbewaking met burndown charts | [$M10$](#m10) | Projecten bespreken de voortgang in het wekelijks projectoverleg aan de hand van informatie over product en sprint backlog uit het backlog management systeem | | Maatregel 12: Een officiële producteigenaar met mandaat | [$M05$](#m05) | ICTU hanteert Scrum, inclusief de rol van de product owner | | Maatregel 13: Toepassen van een kwaliteitgedreven ontwikkelmethode | | De Kwaliteitsaanpak schrijft geen ontwikkelmethode voor aan de projecten; de borging van kwaliteitsnormen zal echter wel invloed hebben op de gevolgde ontwikkelmethode | | Maatregel 14: Archivering | [$M27$](#m27) | | diff --git a/Content/Bijlagen/Terminologie.md b/Content/Bijlagen/Terminologie.md index 92872a0c..633d4115 100644 --- a/Content/Bijlagen/Terminologie.md +++ b/Content/Bijlagen/Terminologie.md @@ -49,7 +49,8 @@ De onderstaande tabel bevat afkortingen en termen die voorkomen in de $KWALITEIT | **PIA** | $PIA$ | | **PKI** | public key infrastructure | | **PRA** | $PRA$ | -| **Product owner** | De product owner is verantwoordelijk voor het maximaliseren van de waarde van het product, dat het resultaat is van het werk van het **Scrumteam** [Scrumgids] | +| **product backlog** | De product backlog is een levende, geordende lijst van wat nodig is om het product te verbeteren. Het is de enige bron van het werk dat door het **Scrumteam** gedaan wordt [Scrumgids] | +| **product owner** | De product owner is verantwoordelijk voor het maximaliseren van de waarde van het product, dat het resultaat is van het werk van het **Scrumteam** [Scrumgids] | | **programmatuur** | zie **software** | | **project** | een tijdelijke organisatie voor het realiseren van een resultaat - bij ICTU bestaat een **softwareontwikkelproject** uit medewerkers van ICTU, de **opdrachtgevende organisatie**, beheerorganisatie en eventueel andere partijen | | **projectleider** | medewerker eindverantwoordelijk voor het projectresultaat - bij ICTU-softwareontwikkelprojecten is de projectleider een medewerker van ICTU | diff --git a/Content/Maatregelen/M01/Maatregel.md b/Content/Maatregelen/M01/Maatregel.md index c5e21c36..3afd7209 100644 --- a/Content/Maatregelen/M01/Maatregel.md +++ b/Content/Maatregelen/M01/Maatregel.md @@ -75,7 +75,7 @@ Beschikbare templates: ### Product backlog -De product backlog is een geprioriteerd overzicht van alle nog te realiseren functionele en niet-functionele eigenschappen van de software. Al het werk dat het Scrumteam doet loopt via de backlog, niet alleen werk aan de broncode zelf maar bijvoorbeeld ook het schrijven van beheerdocumentatie. De product owner is de eigenaar van de product backlog. De zaken op de lijst zijn normaal gesproken in de vorm van een epic of user story. Hierin staat: +De product backlog is een geprioriteerd overzicht van alle nog te realiseren functionele en niet-functionele eigenschappen van de software. Al het werk dat het Scrumteam doet loopt via de product backlog, niet alleen werk aan de broncode zelf maar bijvoorbeeld ook het schrijven van beheerdocumentatie. De product owner is de eigenaar van de product backlog. De zaken op de lijst zijn normaal gesproken in de vorm van een epic of user story. Hierin staat: * _Wat_ er gemaakt moet worden, * _Waarom_, @@ -162,7 +162,7 @@ Het project levert bij elke release informatie aan de opdrachtgevende organisati ### Samenhang voorfaseproducten -![Projectstartarchitectuur (PSA), business impact analyse (BIA) en privacy impact assessment (PIA) zijn input voor de voorfase. Functionele eisen (FE), niet-functionele eisen (NFE), informatiebeveiligingsplan (IB), backlog (BL), ontwerp en architectuur (O&A), kwaliteitsplan (KP) en testplannen (TP) zijn de output van de voorfase. De relaties tussen de verschillende producten zijn als volgt. De projectstartarchitectuur vormt input voor functionele eisen en niet-functionele eisen. De business impact analyse vormt input voor de niet-functionele eisen en informatiebeveiligingsplan. De privacy impact analyse vormt input voor de niet-functionele eisen en het informatiebeveiligingsplan. De functionele eisen vormen input voor de backlog en voor ontwerp en architectuur. De niet-functionele eisen vormen input voor backlog, ontwerp en architectuur en kwaliteitsplan. Het informatiebeveiligingsplan vormt input voor ontwerp en architectuur en kwaliteitsplan. De backlog en ontwerp en architectuur, tenslotte, zijn input voor de testplannen.](relaties-tussen-producten.png "Relaties tussen producten") +![Projectstartarchitectuur (PSA), business impact analyse (BIA) en privacy impact assessment (PIA) zijn input voor de voorfase. Functionele eisen (FE), niet-functionele eisen (NFE), informatiebeveiligingsplan (IB), product backlog (BL), ontwerp en architectuur (O&A), kwaliteitsplan (KP) en testplannen (TP) zijn de output van de voorfase. De relaties tussen de verschillende producten zijn als volgt. De projectstartarchitectuur vormt input voor functionele eisen en niet-functionele eisen. De business impact analyse vormt input voor de niet-functionele eisen en informatiebeveiligingsplan. De privacy impact analyse vormt input voor de niet-functionele eisen en het informatiebeveiligingsplan. De functionele eisen vormen input voor de product backlog en voor ontwerp en architectuur. De niet-functionele eisen vormen input voor product backlog, ontwerp en architectuur en kwaliteitsplan. Het informatiebeveiligingsplan vormt input voor ontwerp en architectuur en kwaliteitsplan. De product backlog en ontwerp en architectuur, tenslotte, zijn input voor de testplannen.](relaties-tussen-producten.png "Relaties tussen producten") Bovenstaande figuur laat de belangrijkste relaties zien tussen de verschillende producten die de input en output van de voorfase vormen. Naast de informatiestromen zoals door de pijlen weergegeven zijn er in de praktijk nog meer verbanden tussen de producten. Zo kan de gekozen oplossing in de architectuur van invloed zijn op de maatregelen in het informatiebeveiligingsplan of leiden niet-functionele eisen tot extra functionele eisen. diff --git a/Content/Maatregelen/M16/Definitie.md b/Content/Maatregelen/M16/Definitie.md index e007dc61..2b42d5e2 100644 --- a/Content/Maatregelen/M16/Definitie.md +++ b/Content/Maatregelen/M16/Definitie.md @@ -2,7 +2,7 @@ **$M16$** ICTU stelt het gebruik van tools verplicht voor de volgende taken: -1. backlog management en agile werken, +1. Product en sprint backlog management en agile werken, 2. inrichten en uitvoeren van een continuous delivery pipeline, 3. monitoren van de kwaliteit van broncode, 4. versiebeheer van op te leveren producten, diff --git a/Content/Maatregelen/M16/Maatregel.md b/Content/Maatregelen/M16/Maatregel.md index b6fcc669..c371d882 100644 --- a/Content/Maatregelen/M16/Maatregel.md +++ b/Content/Maatregelen/M16/Maatregel.md @@ -2,11 +2,11 @@ #include "Content/Maatregelen/M16/Definitie.md" -Onder het ondersteunen van "agile werken" vallen het opvoeren van eisen, het opvoeren van logische testgevallen, het koppelen van logische testgevallen aan eisen, het bijhouden van een werkvoorraad, het plannen van iteraties en het toewijzen van eisen aan iteraties. De 'eisen' worden, conform Scrumterminologie, geregistreerd als epics en/of user stories, de werkvoorraad als backlog en de iteraties als sprints. +Onder het ondersteunen van "agile werken" vallen het opvoeren van eisen, het opvoeren van logische testgevallen, het koppelen van logische testgevallen aan eisen, het bijhouden van een werkvoorraad, het plannen van iteraties en het toewijzen van eisen aan iteraties. De 'eisen' worden, conform Scrumterminologie, geregistreerd als epics en/of user stories, de werkvoorraad als product backlog en de iteraties als sprints. ICTU adviseert en ondersteunt voor de genoemde taken onderstaande tools. Projecten gebruiken deze tools, of gelijkwaardige alternatieven: -1. backlog management en agile werken: Azure DevOps of Jira, +1. Product en sprint backlog management en agile werken: Azure DevOps of Jira, 2. inrichten en uitvoeren van een continuous delivery pipeline: Jenkins, GitLab CI/CD (Continuous Integration, Delivery, and Deployment) of Azure DevOps, 3. monitoren van de kwaliteit van broncode: SonarQube, 4. versiebeheer van op te leveren producten: GitLab of Azure DevOps, diff --git a/Content/Maatregelen/M26/Maatregel.md b/Content/Maatregelen/M26/Maatregel.md index 1befa50c..bffa3c71 100644 --- a/Content/Maatregelen/M26/Maatregel.md +++ b/Content/Maatregelen/M26/Maatregel.md @@ -8,7 +8,7 @@ ICTU zorgt ervoor dat de benodigde expertise op afroep beschikbaar gesteld kan w De opdrachtgevende organisatie kan een derde partij opdracht geven beveiligingstesten uit te voeren in een daarvoor door de opdrachtgevende organisatie beschikbaar gestelde omgeving. Dit kan zowel incidenteel als structureel worden ingericht. Als de opdrachtgevende organisatie dit structureel inricht en als deze beveiligingstesten voldoen aan de eisen die het project zou stellen, dan kunnen de opdrachtgevende organisatie en het project besluiten dat het project zelf geen beveiligingstesten laat uitvoeren. Afspraken hierover worden bij voorkeur al in de voorfase gemaakt, inclusief een controle dat de opdrachtgevende organisatie de benodigde contractuele mogelijkheden heeft beveiligingstesten uit te besteden. Het project ontvangt in dat geval de beveiligingstestrapportages van de opdrachtgevende organisatie. -De beveiligingstesten vinden altijd plaats in aanvulling op de door tools uitgevoerde continue beveiligingsanalyse van de gerealiseerde software. Bevindingen uit beveiligingstesten en de continue analyse die niet direct worden opgelost, worden in Jira als issue vastgelegd op de backlog van het project. +De beveiligingstesten vinden altijd plaats in aanvulling op de door tools uitgevoerde continue beveiligingsanalyse van de gerealiseerde software. Bevindingen uit beveiligingstesten en de continue analyse die niet direct worden opgelost, worden in Jira als issue vastgelegd op de product backlog. De kwaliteitsmanager van het project bewaakt de opvolging van de kritische beveiligingsissues. De kwaliteitsmanager bewaakt tevens of de beveiligingstesten voldoende frequent plaatsvinden, bij voorkeur door Quality-time te laten waarschuwen als het tijd is voor de volgende beveiligingstest. diff --git a/Content/Maatregelen/M33/Maatregel.md b/Content/Maatregelen/M33/Maatregel.md index 3584a76d..ee7d6e64 100644 --- a/Content/Maatregelen/M33/Maatregel.md +++ b/Content/Maatregelen/M33/Maatregel.md @@ -13,7 +13,7 @@ ICTU voegt de self-assessments van de deelnemende projecten samen en maakt een a * Opvallende maatregelen, bijvoorbeeld maatregelen die veel projecten niet of deels toepassen, en * Gemaakte opmerkingen door de deelnemende projecten. -ICTU organiseert een bespreking van de analyse met de deelnemende projecten. Hieruit vloeiende verbeteracties voor de Kwaliteitsaanpak worden door ICTU geprioriteerd en via de backlog voor de Kwaliteitsaanpak afgehandeld. Bij grotere verbeteracties betrekt ICTU de kwaliteitsmanagers van de belanghebbende projecten. +ICTU organiseert een bespreking van de analyse met de deelnemende projecten. Hieruit vloeiende verbeteracties voor de Kwaliteitsaanpak worden door ICTU geprioriteerd en via de product backlog voor de Kwaliteitsaanpak afgehandeld. Bij grotere verbeteracties betrekt ICTU de kwaliteitsmanagers van de belanghebbende projecten. De gezamenlijke self-assessment is een intern product en de niet-geanonimiseerde resultaten worden alleen gedeeld met de deelnemende projecten. De geanonimiseerde resultaten kunnen worden gedeeld met belanghebbenden en belangstellenden binnen en buiten ICTU. diff --git a/Content/Maatregelen/M34/Maatregel.md b/Content/Maatregelen/M34/Maatregel.md index f000f455..c672ef90 100644 --- a/Content/Maatregelen/M34/Maatregel.md +++ b/Content/Maatregelen/M34/Maatregel.md @@ -9,7 +9,7 @@ Het project zorgt, bij voorkeur altijd maar in ieder geval bij de overdracht, da 1. De documentatie beschrijft de ontwikkel- en testomgeving die is toegepast (5.1), 1. De functionele documentatie beschrijft gegevensmodellen, functionele indeling, koppelingen, berichtdefinities en workflows/processen (5.2), 1. Als operationeel beheer onderdeel was van de dienstverlening: de operationele bedieningsinstructies beschrijven minimaal back-up/recovery, procedures bij calamiteiten, regelmatig terugkerende beheeractiviteiten en opstart- en afsluitprocedures (5.3), -1. De productbacklog bevat de bekende bugs en wensen (5.4), +1. De product backlog bevat de bekende bugs en wensen (5.4), 1. De broncode kent een gezonde balans tussen isolatie, cohesie en koppeling (6.1), 1. De broncode heeft een beperkte mate van duplicatie (6.2), 1. De broncode heeft een beperkte mate van complexiteit (6.3), diff --git a/Content/Templates/Detailtestplan-Softwarerealisatie/Template-Inhoud.md b/Content/Templates/Detailtestplan-Softwarerealisatie/Template-Inhoud.md index 0643ccac..06364ff5 100644 --- a/Content/Templates/Detailtestplan-Softwarerealisatie/Template-Inhoud.md +++ b/Content/Templates/Detailtestplan-Softwarerealisatie/Template-Inhoud.md @@ -32,7 +32,7 @@ Binnen het project worden door ICTU de volgende testsoorten onderscheiden en toe + **Performancetesten:** Het testen van de snelheid van afhandeling van bepaalde functies van het systeem onder een vooraf gedefinieerde belasting. Performancetesten vinden bij voorkeur plaats in een productie-like omgeving, maar kunnen ook in een niet-productie-like omgeving plaatsvinden ten behoeve van het volgen van de relatieve performance van verschillende versies van de software. Er vinden zowel een loadtest (normale en piekbelasting), als een duurtest (normale belasting voor langere tijd), als een stresstest (verhogen van de belasting totdat het systeem het begeeft) plaats. De Kwaliteitsaanpak schrijft voor dat er tijdens de realisatiefase performancetesten worden uitgevoerd. Deze worden bij voorkeur automatisch uitgevoerd. Belangrijk is dat de performancetest die op de testomgeving wordt uitgevoerd, niet vanzelfsprekend representatief is voor de productieomgeving. Dit betekent dat een opdrachtgevende organisatie op de eigen productieomgeving een performancetest moet (laten) uitvoeren om te controleren dat er aan de gestelde performance-eisen is voldaan. + **Securitytesten:** Security- en penetratietesten uitgevoerd door een externe partij. Normaliter worden deze minimaal twee maal per jaar of met elke grote release uitgevoerd en niet elke sprint. Securitytesten vinden bij voorkeur plaats in een productie-like omgeving, maar kunnen ook in een niet-productie-like omgeving plaatsvinden ten behoeve van het testen van de beveiliging van de software zelf. De securitytest is inclusief een review van de broncode. Tijdens de realisatie draaien standaard al de volgende securitytesttools mee in de geautomatiseerde pijplijn: SonarQube, OWASP Dependency-Check en/of Dependency-Track, ZAP by Checkmarx en OpenVAS; de bevindingen die uit deze tools komen worden meteen tijdens de realisatie van het systeem opgepakt. * **Integratietesten:** Tijdens deze test wordt de onderlinge verwerkingswijze tussen de verschillende applicaties getest. Denk hierbij aan gewijzigde applicaties die samen werken met ongewijzigde applicaties. Indien van toepassing zullen hier ook externe systemen bij betrokken worden, in de vorm van stubs. Integratietesten zijn normaal gesproken geautomatiseerde tests. Als onderdeel van de integratietesten wordt getest of de software kan omgaan met fouten in andere applicaties en na een herstart goed blijft functioneren. -* **Gebruikersacceptatietest (GAT):** In tegenstelling tot de ‘traditionele’ watervalmethode biedt agile ontwikkelen meer ruimte voor de gebruiker om te participeren in het ontwikkeltraject. Tijdens elke sprint wordt nieuwe functionaliteit gedemonstreerd door het Scrumteam in een demo-omgeving. {opdrachtgevende organisatie} en/of beheerorganisatie kan een GAT-testomgeving beschikbaar stellen waar gebruikers kunnen werken met de nieuwe applicaties. Bevindingen worden tijdens trainingen of workshops verzameld om in de backlogs verwerkt te worden. De product owner prioriteert vervolgens deze bevindingen. +* **Gebruikersacceptatietest (GAT):** In tegenstelling tot de ‘traditionele’ watervalmethode biedt agile ontwikkelen meer ruimte voor de gebruiker om te participeren in het ontwikkeltraject. Tijdens elke sprint wordt nieuwe functionaliteit gedemonstreerd door het Scrumteam in een demo-omgeving. {opdrachtgevende organisatie} en/of beheerorganisatie kan een GAT-testomgeving beschikbaar stellen waar gebruikers kunnen werken met de nieuwe applicaties. Bevindingen worden tijdens trainingen of workshops verzameld om in de product backlog verwerkt te worden. De product owner prioriteert vervolgens deze bevindingen. * **Usabilitytesten:** Het doel van deze test is om te bepalen hoe gemakkelijk / toegankelijk het systeem is in het gebruik ervan. Onderdeel van deze test is de toegankelijkheidstest; hiermee wordt bepaald in welke mate de software voldoet aan de wettelijke vereisten van de Web Content Accessibility Guidelines (WCAG2.2) en eventuele aanvullende toegankelijkheidseisen. Deze toegankelijkheidstesten worden waar mogelijk geautomatiseerd uitgevoerd. De toegankelijkheidseisen die niet geautomatiseerd getest kunnen worden, worden periodiek handmatig getest. ## Agile werkwijze diff --git a/Content/Templates/Detailtestplan-Softwarerealisatie/Uitgangspunten.md b/Content/Templates/Detailtestplan-Softwarerealisatie/Uitgangspunten.md index d813a9db..de98dc55 100644 --- a/Content/Templates/Detailtestplan-Softwarerealisatie/Uitgangspunten.md +++ b/Content/Templates/Detailtestplan-Softwarerealisatie/Uitgangspunten.md @@ -8,7 +8,7 @@ De volgende uitgangspunten zijn van toepassing op dit document: | U02 | De als testbasis geïdentificeerde documenten dienen door alle acceptanten, inclusief het testteam, te zijn geaccordeerd, alvorens met de testspecificatie kan worden begonnen. | | U03 | Per release of per sprint kan de product owner besluiten om bepaalde functionaliteit, bijvoorbeeld geleverd door externe partijen, niet te testen. Indien dit voorkomt, dan zal dit expliciet worden opgenomen in de managementsamenvatting van het vrijgaveadvies. | | U04 | De multidisciplinaire samenstelling van de Scrumteams — test engineers en ontwikkelaars zitten in hetzelfde team — geeft mogelijkheid tot snelle interactie. Issues gevonden binnen een sprint kunnen hierdoor vaak nog binnen dezelfde sprint worden opgelost en hoeven dus niet apart geadministreerd te worden. | -| U05 | Issues gevonden tijdens de acceptatietesten of in productie worden op de backlog verwerkt samen met de user stories. | +| U05 | Issues gevonden tijdens de acceptatietesten of in productie worden op de product backlog verwerkt samen met de user stories. | | U06 | De ontwikkel- en testplanning zijn met elkaar verweven. Het ontwikkelen en testen van de user stories zijn onlosmakelijk met elkaar verbonden en beginnen op hetzelfde moment. | | U07 | De testomgeving wordt conform planning tijdig en correct werkend opgeleverd. | | U08 | Er is voldoende en gepaste testdata ter beschikking. Zie de paragraaf Testdata in het hoofdstuk Infrastructuur voor een beschrijving van de testdata. | diff --git a/Content/Templates/Kwaliteitsplan/Kaders.md b/Content/Templates/Kwaliteitsplan/Kaders.md index b12902d2..ea024264 100644 --- a/Content/Templates/Kwaliteitsplan/Kaders.md +++ b/Content/Templates/Kwaliteitsplan/Kaders.md @@ -1,5 +1,5 @@ ## Kaders -De volgende kaders zijn van toepassing op het realisatieproces van het project. Merk op dat kaders die van toepassing zijn op het te realiseren *product* opgenomen zijn in PSA, NFE en/of backlog. +De volgende kaders zijn van toepassing op het realisatieproces van het project. Merk op dat kaders die van toepassing zijn op het te realiseren *product* opgenomen zijn in PSA, NFE en/of product backlog. #include "Content/Templates/Standaard-Proces-Kaders.md" diff --git a/Content/Templates/Kwaliteitsplan/Over-dit-document.md b/Content/Templates/Kwaliteitsplan/Over-dit-document.md index 02649b09..8848dcdd 100644 --- a/Content/Templates/Kwaliteitsplan/Over-dit-document.md +++ b/Content/Templates/Kwaliteitsplan/Over-dit-document.md @@ -8,4 +8,4 @@ De $KWALITEITSAANPAK$ (zie bijlagen) ligt ten grondslag aan dit kwaliteitsplan e Dit kwaliteitsplan beschrijft in nader detail hoe invulling wordt gegeven aan de maatregelen uit de Kwaliteitsaanpak en benoemt eventuele afwijkingen. Als er bijzondere of hoge niet-functionele eisen zijn, beschrijft het kwaliteitsplan ook de extra projectspecifieke kwaliteitsmaatregelen die het project treft om deze eisen te realiseren. Het kwaliteitsplan wordt gedurende de voorfase van een softwareontwikkelproject opgesteld en heeft betrekking op zowel de voorfase als realisatiefase van het project. -De opdrachtgever en de ICTU-projectleider accorderen dit kwaliteitsplan. Omdat de maatregelen invloed kunnen hebben op de backlog, zal de product owner het kwaliteitsplan ook accorderen. +De opdrachtgever en de ICTU-projectleider accorderen dit kwaliteitsplan. Omdat de maatregelen invloed kunnen hebben op de product backlog, zal de product owner het kwaliteitsplan ook accorderen. diff --git a/Content/Templates/Kwaliteitsplan/Template-Inhoud.md b/Content/Templates/Kwaliteitsplan/Template-Inhoud.md index 7c312aaa..8430a2ca 100644 --- a/Content/Templates/Kwaliteitsplan/Template-Inhoud.md +++ b/Content/Templates/Kwaliteitsplan/Template-Inhoud.md @@ -62,7 +62,7 @@ Dit kwaliteitsplan wordt opgesteld tijdens de voorfase, maar is tevens al deels ## Belanghebbenden -De kwaliteit van de deliverables wordt mede bepaald door de verwachtingen van de belanghebbenden. Het is van belang dat alle belanghebbenden zijn geïdentificeerd en hun verwachtingen zijn vastgelegd, geanalyseerd en vertaald naar de eisen voor het te implementeren systeem. De belanghebbenden worden geïdentificeerd in het projectvoorstel voor de voorfase. De eisen aan het te ontwikkelen systeem worden vastgelegd in Backlog en NFE-document. +De kwaliteit van de deliverables wordt mede bepaald door de verwachtingen van de belanghebbenden. Het is van belang dat alle belanghebbenden zijn geïdentificeerd en hun verwachtingen zijn vastgelegd, geanalyseerd en vertaald naar de eisen voor het te implementeren systeem. De belanghebbenden worden geïdentificeerd in het projectvoorstel voor de voorfase. De eisen aan het te ontwikkelen systeem worden vastgelegd in product backlog en NFE-document. De tijdens de voorfase geïdentificeerde eisen vormen het startpunt van {opdrachtgevende organisatie} en kunnen gedurende de vervolgfases in overeenstemming met de opdrachtnemer aangepast worden. De product owner vertegenwoordigt gedurende de vervolgfasen de geïdentificeerde belanghebbenden. @@ -90,7 +90,7 @@ In aanvulling op de maatregelen met betrekking tot reviews, zie paragraaf [Docum ### Tracering eisen -{Als de eisen traceerbaar moeten zijn vanuit de Backlog/NFE-document/Informatiebeveiligingsplan via GFO en SAD naar broncode, beschrijf dan hier de wijze waarop de eisen uniek identificeerbaar zijn gemaakt, hoe de relaties tussen eisen en ontwerp(beslissingen) worden bijgehouden en hoe de relaties tussen ontwerp(beslissingen) en code worden bijgehouden. Beschrijf hier ook wie deze relaties op welke momenten verifieert en hoe de verificatie wordt gedocumenteerd.} +{Als de eisen traceerbaar moeten zijn vanuit product backlog/NFE-document/Informatiebeveiligingsplan via GFO en SAD naar broncode, beschrijf dan hier de wijze waarop de eisen uniek identificeerbaar zijn gemaakt, hoe de relaties tussen eisen en ontwerp(beslissingen) worden bijgehouden en hoe de relaties tussen ontwerp(beslissingen) en code worden bijgehouden. Beschrijf hier ook wie deze relaties op welke momenten verifieert en hoe de verificatie wordt gedocumenteerd.} # Kwaliteitsmaatregelen realisatiefase diff --git a/Content/Templates/MTP/Relatie-documenten.md b/Content/Templates/MTP/Relatie-documenten.md index c7187c28..04403ebc 100644 --- a/Content/Templates/MTP/Relatie-documenten.md +++ b/Content/Templates/MTP/Relatie-documenten.md @@ -12,7 +12,7 @@ Het mastertestplan is gebaseerd op de volgende documenten, die beschrijven welke * Niet-functionele eisen (NFE), {documentreferentie}, * Globaal functioneel ontwerp (GFO), {documentreferentie}, * Interactie-ontwerp (UX), {documentreferentie}, -* Geprioriteerde backlog met user stories, {documentreferentie}, +* Product backlog, {documentreferentie}, * Vastgesteld minimal viable product, {documentreferentie}, * Wireframe, mockup, prototype, animatie, {documentreferentie}. diff --git a/Content/Templates/MTP/Template-Inhoud.md b/Content/Templates/MTP/Template-Inhoud.md index bac48b02..5ea03b8d 100644 --- a/Content/Templates/MTP/Template-Inhoud.md +++ b/Content/Templates/MTP/Template-Inhoud.md @@ -232,7 +232,7 @@ De op de tests toe te passen acceptatiecriteria worden als volgt bepaald: | Unittest (UT) | {Beschrijf wanneer en hoe de acceptatiecriteria worden bepaald} | | Unit-integratietest (UIT) | {Beschrijf wanneer en hoe de acceptatiecriteria worden bepaald} | | Systeemtest (ST) | De testspecificaties voor de systeemtest worden tijdens de sprints gemaakt, parallel aan de realisatie. | -| Functionele acceptatietest (FAT) | Functionele acceptatiecriteria voor een sprint worden vóór een sprint opgesteld (backlog refinement). {Alternatief: De testspecificaties voor de functionele acceptatietest worden tijdens de sprints gemaakt, parallel aan de realisatie.} | +| Functionele acceptatietest (FAT) | Functionele acceptatiecriteria voor een sprint worden vóór een sprint opgesteld (product backlog refinement). {Alternatief: De testspecificaties voor de functionele acceptatietest worden tijdens de sprints gemaakt, parallel aan de realisatie.} | | Gebruikers-acceptatietest (GAT) | {Beschrijf wanneer en hoe de acceptatiecriteria worden bepaald} | | Penetratietest (PEN) | {Beschrijf wanneer en hoe de acceptatiecriteria worden bepaald} | | Performancetest (PERF) | {Beschrijf wanneer en hoe de acceptatiecriteria worden bepaald} | @@ -415,8 +415,8 @@ Onderstaande tabel bevat de bevindingenprocedures per testsoort en/of testvorm. |:----------|:-----------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | UT | {testvorm} | {bevindingenprocedure} | | UIT | {testvorm} | {bevingingenprocedure} | -| ST | {testvorm} | De bevindingen die niet binnen de sprint worden opgelost zullen geregistreerd worden in het bevindingenregistratiesysteem. Deze bevindingen komen op de backlog en zullen op basis van prioriteit door de product owner in één van de volgende sprints worden gepland. | -| FAT | {testvorm} | De bevindingen worden vastgelegd in het bevindingenregistratiesysteem en in bevindingenoverleg besproken. Deze bevindingen komen op de backlog en worden op basis van prioriteit door de product owner in dezelfde sprint of in één van de volgende sprints gepland. Een uitzondering hierop vormen blokkerende testbevindingen. Voor deze bevindingen moet zo snel mogelijk binnen de lopende sprint een oplossing worden gerealiseerd. Dit zal in overleg met het ontwikkelteam door de product owner worden bepaald. | +| ST | {testvorm} | De bevindingen die niet binnen de sprint worden opgelost zullen geregistreerd worden in het bevindingenregistratiesysteem. Deze bevindingen komen op de product backlog en zullen op basis van prioriteit door de product owner in één van de volgende sprints worden gepland. | +| FAT | {testvorm} | De bevindingen worden vastgelegd in het bevindingenregistratiesysteem en in bevindingenoverleg besproken. Deze bevindingen komen op de product backlog en worden op basis van prioriteit door de product owner in dezelfde sprint of in één van de volgende sprints gepland. Een uitzondering hierop vormen blokkerende testbevindingen. Voor deze bevindingen moet zo snel mogelijk binnen de lopende sprint een oplossing worden gerealiseerd. Dit zal in overleg met het ontwikkelteam door de product owner worden bepaald. | | GAT | {testvorm} | Zie FAT. | | PEN | {testvorm} | Zie FAT. | | PERF | {testvorm} | {bevingingenprocedure} | diff --git a/Content/Templates/MTP/Uitgangspunten.md b/Content/Templates/MTP/Uitgangspunten.md index be81cf41..748127ae 100644 --- a/Content/Templates/MTP/Uitgangspunten.md +++ b/Content/Templates/MTP/Uitgangspunten.md @@ -8,7 +8,7 @@ De volgende uitgangspunten zijn van toepassing op dit document: | U02 | De als testbasis geïdentificeerde documenten zijn door alle acceptanten, inclusief het testteam, geaccordeerd, alvorens met de testspecificatie is begonnen. | | U03 | Per release of per sprint kan de opdrachtgever en/of product owner besluiten om bepaalde functionaliteit, bijvoorbeeld geleverd door externe partijen, niet te testen. Indien dit voorkomt, dan zal dit expliciet worden opgenomen in de managementsamenvatting van het vrijgaveadvies. | | U04 | De multidisciplinaire samenstelling van de Scrumteams - testers en ontwikkelaars zitten in hetzelfde team - geeft mogelijkheid tot snelle interactie. Issues gevonden binnen een sprint kunnen hierdoor vaak nog binnen dezelfde sprint worden opgelost en worden in dat geval niet apart geadministreerd. | -| U05 | Issues gevonden tijdens de acceptatietests of in productie worden op de backlog verwerkt samen met de user stories. | +| U05 | Issues gevonden tijdens de acceptatietests of in productie worden op de product backlog verwerkt samen met de user stories. | | U06 | Testomgevingen worden conform planning tijdig en correct werkend opgeleverd. | | U07 | Er is voldoende en gepaste testdata ter beschikking. Zie de paragraaf 'Testdata' in het hoofdstuk 'Infrastructuur' voor een beschrijving van de testdata. | | U08 | De testspecificatie voor een testsoort start pas als aan de entry-criteria (Definition of Ready), die hiervoor gelden, is voldaan. Hieraan is voldaan voor het deel (van de testbasis) dat in de betreffende sprint gerealiseerd en getest wordt (bijvoorbeeld een aantal bij elkaar horende user stories). | diff --git a/Content/Templates/NFE/Over-dit-document.md b/Content/Templates/NFE/Over-dit-document.md index 63d84161..4af6034d 100644 --- a/Content/Templates/NFE/Over-dit-document.md +++ b/Content/Templates/NFE/Over-dit-document.md @@ -9,7 +9,7 @@ Deze hoofdeigenschappen zijn nog te globaal en te abstract om de gewenste kenmer De opzet, formulering en inhoud van de niet-functionele eisen voldoen aan algemeen erkende kwaliteitskenmerken: een eis gaat over één onderwerp en is toe te wijzen aan één partij. Daarnaast is de eis compleet, consistent met andere eisen, herleidbaar naar organisatie-eisen, van erkend belang voor de organisatie, actueel, ondubbelzinnig en verifieerbaar. De belangrijke niet-functionele eisen zijn identificeerbaar tot een zodanig niveau dat het mogelijk is: 1. de realisatiefase te begroten met voldoende zekerheid over de benodigde expertise, doorlooptijd en kosten, en -1. op controleerbare wijze te verwerken in software-architectuurdocument (SAD), backlog en testplannen. +1. op controleerbare wijze te verwerken in software-architectuurdocument (SAD), product backlog en testplannen. In totaal zijn de volgende 31 eigenschappen onderkend: diff --git a/Content/Templates/PvA-Realisatiefase/Kaders.md b/Content/Templates/PvA-Realisatiefase/Kaders.md index c3d1b591..6386ac10 100644 --- a/Content/Templates/PvA-Realisatiefase/Kaders.md +++ b/Content/Templates/PvA-Realisatiefase/Kaders.md @@ -1,5 +1,5 @@ ## Kaders -De volgende kaders zijn van toepassing op het realisatieproces van het project. Kaders die van toepassing zijn op het te realiseren *product* zijn opgenomen in PSA, NFE en/of backlog. +De volgende kaders zijn van toepassing op het realisatieproces van het project. Kaders die van toepassing zijn op het te realiseren *product* zijn opgenomen in PSA, NFE en/of product backlog. #include "Content/Templates/Standaard-Proces-Kaders.md" diff --git a/Content/Templates/PvA-Realisatiefase/Over-dit-document.md b/Content/Templates/PvA-Realisatiefase/Over-dit-document.md index a30fee29..2550be0e 100644 --- a/Content/Templates/PvA-Realisatiefase/Over-dit-document.md +++ b/Content/Templates/PvA-Realisatiefase/Over-dit-document.md @@ -12,6 +12,6 @@ Tijdens de voorfase van {het project} zijn de volgende activiteiten uitgevoerd: a. planning, a. samenwerking, a. risico’s. -1. Voorbereiden van een eventuele start van de realisatie, zodat het Scrumteam van een voldoende uitgewerkte backlog is voorzien bij de start. +1. Voorbereiden van een eventuele start van de realisatie, zodat het Scrumteam van een voldoende uitgewerkte product backlog is voorzien bij de start. Om tot {projectresultaat} te komen, ontwikkelt ICTU in samenwerking met {partijen} {het product}; zie voor een beschrijving hiervan het hoofdstuk "Producten". Dit plan van aanpak beschrijft verder de planning van en werkwijze tijdens de realisatiefase. Het is een aanvulling op het voorstel inclusief projectovereenkomst {titel, versie en datum}. diff --git a/Content/Templates/PvA-Realisatiefase/Relatie-documenten.md b/Content/Templates/PvA-Realisatiefase/Relatie-documenten.md index 44ef290a..f5353774 100644 --- a/Content/Templates/PvA-Realisatiefase/Relatie-documenten.md +++ b/Content/Templates/PvA-Realisatiefase/Relatie-documenten.md @@ -14,7 +14,7 @@ De realisatiefase is een vervolg op de voorfase van {het project}. De documenten * Niet-functionele eisen (NFE), versie {versie}, * Globaal functioneel ontwerp (GFO), versie {versie}, * Interactie-ontwerp (UX), versie {versie}, -* Geprioriteerde backlog met user stories, versie {versie}, +* Product backlog, versie {versie}, * Vastgesteld minimal viable product, versie {versie}, * Wireframe, mockup, prototype, animatie, versie {versie}, * Tussentijdse rapportage t.b.v. go/no-go besluit, versie {versie}. diff --git a/Content/Templates/PvA-Realisatiefase/Template-Inhoud.md b/Content/Templates/PvA-Realisatiefase/Template-Inhoud.md index 34da4073..5b81eae2 100644 --- a/Content/Templates/PvA-Realisatiefase/Template-Inhoud.md +++ b/Content/Templates/PvA-Realisatiefase/Template-Inhoud.md @@ -31,7 +31,7 @@ Binnen de scope van de opdracht valt de {ontwikkeling en/of het onderhoud} van { * Ontwikkel, test- en demo-omgevingen, * Engineering tools voor versiebeheer (GitLab of Azure DevOps), bouwen en testen (Azure DevOps, GitLab en/of Jenkins), kwaliteitscontrole (SonarQube), beveiligingscontrole (SonarQube, OWASP Dependency-Check en/of Dependency-Track, ZAP by Checkmarx, OpenVAS), toegankelijkheid (Axe), performancetesten (JMeter) en integrale kwaliteitsrapportage (Quality-time), * {Als operationeel beheer onderdeel is van de dienstverlening:} Uitrollen in de productieomgeving (Ansible), container registry (Harbor), performance monitoring (APM), security monitoring ({vul aan met concreet product}), controle van kwetsbaarheden in frameworks ({vul aan met concreet product}), controle van images van containers (Trivy), registratie van incidenten bij gebruik en beheer (Topdesk of Jira). -* Backlog management tools (Jira en/of Azure DevOps), +* Product en sprint backlog management tools (Jira en/of Azure DevOps), * Beveiligings- en performancetesten in de ICTU-testomgevingen. ICTU voert deze tests uit voordat een nieuwe versie van de software wordt opgeleverd. {Beschrijf hier eventuele andere afspraken met de opdrachtgevende organisatie}. {Als operationeel beheer geen onderdeel is van de dienstverlening:} Buiten de scope van de opdracht valt: @@ -118,7 +118,7 @@ Onderstaand is de verwachte inzet van per rol van {opdrachtgevende organisatie} | Rollen | Verwachte inzet per week | Verantwoordelijkheden | |:----------------------------------------------|:-------------------------|:-----------------------------------------------------------------------------------------------------------------------------| | Projectleider ({opdrachtgevende organisatie}) | {aantal} dagen | Bespreken voortgang en eventuele exceptions met de projectleider (opdrachtnemer), deelname aan demo's en eventuele workshops | -| Product owner | {aantal} dagen | Prioritering user stories, sprintplanning, demo, onderhouden backlog | +| Product owner | {aantal} dagen | Prioritering user stories, sprintplanning, demo, onderhouden product backlog | | Business analist | {aantal} dagen | Epics opstellen voor de product backlog, eventueel uitgewerkt in user stories | | Architect | {aantal} dagen | Bewaken en onderhouden van de softwarearchitectuur | | Infrastructuurarchitect | {aantal} dagen | Bewaken en onderhouden infrastructuurarchitectuur, opstellen infrastructuurarchitectuur (IA) | diff --git a/Content/Templates/PvA-Voorfase-Producten/Template-Inhoud.md b/Content/Templates/PvA-Voorfase-Producten/Template-Inhoud.md index 107275f1..19e7917e 100644 --- a/Content/Templates/PvA-Voorfase-Producten/Template-Inhoud.md +++ b/Content/Templates/PvA-Voorfase-Producten/Template-Inhoud.md @@ -1,6 +1,6 @@ | Onderdeel voorfase | Definitie | Input voor | Inhoudelijk verantwoordelijk | Penvoerder | Review en meewerken aan | Week 1 | Week 2 | Week 3 | Week 4 | | :-------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :---------------------------------------------------------------- | :--------------------------- | :----------- | :---------------------- | :----- | :----- | :----- | :----- | -| Projectstartarchitectuur (PSA) | $PSA$ | Backlog en Niet-functionele eisen | {verantwoordelijke} | {penvoerder} | ICTU, {reviewers} | | | | | +| Projectstartarchitectuur (PSA) | $PSA$ | Product backlog en Niet-functionele eisen | {verantwoordelijke} | {penvoerder} | ICTU, {reviewers} | | | | | | Business impact analyse (BIA) | $BIA$ | IB-plan | {verantwoordelijke} | {penvoerder} | ICTU, {reviewers} | | | | | | Privacy impact assessment (PIA) | $PIA$ | IB-plan en Niet-functionele eisen | {verantwoordelijke} | {penvoerder} | ICTU, {reviewers} | | | | | | Globaal functioneel ontwerp (GFO) | $GFO$ | Detailtestplan softwarerealisatie | ICTU | {reviewers} | | | | | @@ -12,9 +12,9 @@ | Detailtestplan softwarerealisatie | $DTPSR$ | | {verantwoordelijke} | ICTU | {reviewers} | | | | | | Threat & vulnerability assessment (TVA) | $TVA$ | IB-plan | {verantwoordelijke} | {penvoerder} | ICTU, {reviewers} | | | | | | Informatiebeveiligingsplan (IB-plan) | $IB$ | SAD, GFO, Kwaliteitsplan | {verantwoordelijke} | {penvoerder} | ICTU, {reviewers} | | | | | -| Niet-functionele eisen (NFE) | $NFE$ | Backlog, SAD, GFO, Kwaliteitsplan | {verantwoordelijke} | {penvoerder} | ICTU, {reviewers} | | | | | +| Niet-functionele eisen (NFE) | $NFE$ | Product backlog, SAD, GFO, Kwaliteitsplan | {verantwoordelijke} | {penvoerder} | ICTU, {reviewers} | | | | | | Kwaliteitsplan | $KP$ | | {verantwoordelijke} | ICTU | {reviewers} | | | | | -| Geprioriteerde backlog met user stories | Een geprioriteerd overzicht van alle nog te realiseren functionele en niet-functionele eigenschappen van de software | Plan van aanpak realisatiefase | {verantwoordelijke} | {penvoerder} | ICTU, {reviewers} | | | | | +| Product backlog | Een geprioriteerd overzicht van alle nog te realiseren functionele en niet-functionele eigenschappen van de software | Plan van aanpak realisatiefase | {verantwoordelijke} | {penvoerder} | ICTU, {reviewers} | | | | | | Vastgesteld minimal viable product | $MVP$ | Plan van aanpak realisatiefase | {verantwoordelijke} | {penvoerder} | ICTU, {reviewers} | | | | | | Wireframe, mockup, prototype, animatie | Vroege weergaven/schetsen van hoe het eindresultaat er uit komt te zien | | {verantwoordelijke} | ICTU | {reviewers} | | | | | | Voorstel realisatiefase | Aanbieding van ICTU voor de uitvoering van de realisatie, rekening houdende met de specifieke behoeften, wensen en voorwaarden van de opdrachtgever | | ICTU | ICTU | {reviewers} | | | | | diff --git a/Content/Templates/PvA-Voorfase/Kaders.md b/Content/Templates/PvA-Voorfase/Kaders.md index 832c028a..00700662 100644 --- a/Content/Templates/PvA-Voorfase/Kaders.md +++ b/Content/Templates/PvA-Voorfase/Kaders.md @@ -1,5 +1,5 @@ ## Kaders -De volgende kaders zijn van toepassing op het softwareontwikkelingsproces. Merk op dat kaders die van toepassing zijn op het tijdens de realisatiefase te realiseren *product* opgenomen zijn en/of worden in PSA, NFE en/of backlog. +De volgende kaders zijn van toepassing op het softwareontwikkelingsproces. Merk op dat kaders die van toepassing zijn op het tijdens de realisatiefase te realiseren *product* opgenomen zijn en/of worden in PSA, NFE en/of product backlog. -#include "Content/Templates/Standaard-Proces-Kaders.md" \ No newline at end of file +#include "Content/Templates/Standaard-Proces-Kaders.md" diff --git a/Content/Templates/PvA-Voorfase/Over-dit-document.md b/Content/Templates/PvA-Voorfase/Over-dit-document.md index be3e896c..9376e6b0 100644 --- a/Content/Templates/PvA-Voorfase/Over-dit-document.md +++ b/Content/Templates/PvA-Voorfase/Over-dit-document.md @@ -12,6 +12,6 @@ De voorfase heeft de volgende doelen: a. planning, a. samenwerking, a. risico’s. -1. Voorbereiden van een eventuele start van de realisatie, zodat het Scrumteam van een voldoende uitgewerkte backlog is voorzien bij de start. +1. Voorbereiden van een eventuele start van de realisatie, zodat het Scrumteam van een voldoende uitgewerkte product backlog is voorzien bij de start. Om deze doelen te realiseren, ontwikkelt ICTU in samenwerking met {partijen} een aantal producten, zie voor een beschrijving hiervan het hoofdstuk "Projectresultaat". Dit plan van aanpak beschrijft verder de planning van en werkwijze tijdens de voorfase. Het is een aanvulling op het voorstel inclusief projectovereenkomst {titel, versie en datum}. diff --git a/Content/Templates/PvA-Voorfase/Template-Inhoud.md b/Content/Templates/PvA-Voorfase/Template-Inhoud.md index 9d4449be..9e69ce0c 100644 --- a/Content/Templates/PvA-Voorfase/Template-Inhoud.md +++ b/Content/Templates/PvA-Voorfase/Template-Inhoud.md @@ -24,7 +24,7 @@ In de voorfase worden de volgende producten gerealiseerd op basis van {bronnen, | Informatiebeveiligingsplan (IB-plan) | {verantwoordelijke} | {penvoerder} | ICTU, {reviewers} | | Niet-functionele eisen (NFE) | {verantwoordelijke} | {penvoerder} | ICTU, {reviewers} | | Kwaliteitsplan | {verantwoordelijke} | ICTU | {reviewers} | -| Geprioriteerde backlog met user stories | {verantwoordelijke} | {penvoerder} | ICTU, {reviewers} | +| Product backlog | {verantwoordelijke} | {penvoerder} | ICTU, {reviewers} | | Vastgesteld minimal viable product | {verantwoordelijke} | {penvoerder} | ICTU, {reviewers} | | Wireframe, mockup, prototype, animatie | {verantwoordelijke} | ICTU | {reviewers} | | Voorstel realisatiefase | ICTU | ICTU | {reviewers} | @@ -113,7 +113,7 @@ Onderstaand is de verwachte inzet per rol van {opdrachtgevende organisatie} en { | Architect | {aantal} dagen | Richting geven aan architectuur, opstellen PSA, reviewen SAD, NFE en infrastructuurarchitectuur | | Testmanager | {aantal} dagen | Uitvoeren PRA, opstellen mastertestplan, reviewen kwaliteitsplan, detailtestplan softwarerealisatie | | Diverse inhoudelijk deskundigen | {aantal} dagen | Eventuele betrokkenheid van (eind)gebruikers en belanghebbenden | -| Product owner | {aantal} dagen | Inhoudelijk sturing / prioritering, opstellen backlog, NFE, minimal viable product, reviewen GFO en prototype | +| Product owner | {aantal} dagen | Inhoudelijk sturing / prioritering, opstellen product backlog, NFE, minimal viable product, reviewen GFO en prototype | | Projectleider ({opdrachtgevende organisatie}) | {aantal} dagen | Bespreken voortgang en eventuele exceptions met de projectleiders van opdrachtnemer, deelname aan kick-off en eventuele workshops | | Projectleider ({beheerorganisatie}) | {aantal} dagen | Opstellen plan van aanpak realisatiefase voor het inrichten van technisch en operationeel beheer, deelname aan kick-off en eventuele workshops | | Diverse technisch en inhoudelijk specialisten | ad hoc | Inzet op ad-hocbasis ter ondersteuning van de andere rollen | diff --git a/Content/Wijzigingsgeschiedenis.md b/Content/Wijzigingsgeschiedenis.md index d466b3ff..76fe05a7 100644 --- a/Content/Wijzigingsgeschiedenis.md +++ b/Content/Wijzigingsgeschiedenis.md @@ -1,3 +1,9 @@ +# Versie 4.1.1, nog te releasen + +## Alle documenten + +* Product backlog, sprint backlog en product owner consistent geschreven. + # Versie 4.1.0, 17 januari 2025 ## Kwaliteitsaanpak