Product en sprint backlog consistent geschreven, conform de Scrumgids…

… (behalve hoofdletters).

Closes #994.

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) | |

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 |

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.
 

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,

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,

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.
 

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.
 

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),

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

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. |

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"

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.