Verbeteringen KP-template en andere templates. Closes #840.

Content/Templates/Colofon.md

@@ -12,36 +12,36 @@ Rubricering conform [VIRBI 2013, art. 4](https://wetten.overheid.nl/BWBR0033507/
 
 ###### Revisiehistorie
 
-| Versie   | Auteur | Datum   | Status               | Opmerkingen   |
-|:---------|:-------|:--------|:---------------------|:--------------|
-| {versie} | {naam} | {datum} | {concept/definitief} | {opmerkingen} |
+| Versie   | Auteur        | Datum   | Status               | Opmerkingen   |
+|:---------|:--------------|:--------|:---------------------|:--------------|
+| {versie} | {naam auteur} | {datum} | {concept/definitief} | {opmerkingen} |
 
 ###### Reviewers
 
-| Functie/rol                                     | Naam   | Datum   |  Versie  |
-|:------------------------------------------------|:-------|:--------|:--------:|
-| Kwaliteitsmanager {opdrachtgevende organisatie} | {naam} | {datum} | {versie} |
-| Kwaliteitsmanager {beheerorganisatie}           | {naam} | {datum} | {versie} |
-| Kwaliteitsmanager ICTU                          | {naam} | {datum} | {versie} |
+| Functie/rol                                     | Naam                                                 | Datum   |  Versie  |
+|:------------------------------------------------|:-----------------------------------------------------|:--------|:--------:|
+| Kwaliteitsmanager {opdrachtgevende organisatie} | {naam kwaliteitsmanager opdrachtgevende organisatie} | {datum} | {versie} |
+| Kwaliteitsmanager {beheerorganisatie}           | {naam kwaliteitsmanager beheerorganisatie}           | {datum} | {versie} |
+| Kwaliteitsmanager ICTU                          | {naam kwaliteitsmanager ICTU}                        | {datum} | {versie} |
 
 ###### Vereiste goedkeuringen
 
-| Functie/rol                                 | Naam   | Datum   |  Versie  |
-|:--------------------------------------------|:-------|:--------|:--------:|
-| Projectleider {opdrachtgevende organisatie} | {naam} | {datum} | {versie} |
-| Projectleider {beheerorganisatie}           | {naam} | {datum} | {versie} |
-| Projectleider ICTU                          | {naam} | {datum} | {versie} |
-| Product owner                               | {naam} | {datum} | {versie} |
+| Functie/rol                                 | Naam                                             | Datum   |  Versie  |
+|:--------------------------------------------|:-------------------------------------------------|:--------|:--------:|
+| Projectleider {opdrachtgevende organisatie} | {naam projectleider opdrachtgevende organisatie} | {datum} | {versie} |
+| Projectleider {beheerorganisatie}           | {naam projectleider beheerorganisatie}           | {datum} | {versie} |
+| Projectleider ICTU                          | {naam projectleider ICTU}                        | {datum} | {versie} |
+| Product owner                               | {naam product owner}                             | {datum} | {versie} |
 
 ###### Verzendlijst huidige versie
 
-| Naam   | Organisatie                   | Functie/rol               |
-|:-------|:------------------------------|:--------------------------|
-| {naam} | {opdrachtgevende organisatie} | Projectleider             |
-| {naam} | {opdrachtgevende organisatie} | Product owner             |
-| {naam} | {beheerorganisatie}           | Projectleider             |
-| {naam} | ICTU                          | Projectleider             |
-| {naam} | ICTU                          | Software delivery manager |
+| Naam                                             | Organisatie                   | Functie/rol               |
+|:-------------------------------------------------|:------------------------------|:--------------------------|
+| {naam projectleider opdrachtgevende organisatie} | {opdrachtgevende organisatie} | Projectleider             |
+| {naam product owner}                             | {opdrachtgevende organisatie} | Product owner             |
+| {naam projectleider beheerorganisatie}           | {beheerorganisatie}           | Projectleider             |
+| {naam projectleider ICTU}                        | ICTU                          | Projectleider             |
+| {naam software delivery manager}                 | ICTU                          | Software delivery manager |
 
 ###### Template versie
 

Content/Templates/Compacte-Voorfase/Doelgroep.md

@@ -1,6 +1,6 @@
 ## Doelgroep
 
-Dit document is in eerste instantie bestemd voor medewerkers van {de opdrachtgevende organisatie} die {het product} laat ontwikkelen. Het biedt ook inzicht en overzicht aan andere betrokkenen bij het project, namelijk:
+Dit document is in eerste instantie bestemd voor medewerkers van {opdrachtgevende organisatie} die {het product} laat ontwikkelen. Het biedt ook inzicht en overzicht aan andere betrokkenen bij het project, namelijk:
 
 * de ontwikkelaar(s) van het systeem,
 * de beheerder(s) van het systeem.

Content/Templates/Detailtestplan-Softwarerealisatie/Doelgroep.md

@@ -1,3 +1,3 @@
 ## Doelgroep
 
-Dit document is bedoeld voor iedereen die betrokken is bij het testtraject van {Projectnaam}.
+Dit document is bedoeld voor iedereen die betrokken is bij het testtraject van {het project}.

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 checker, OWASP ZAP 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. {De 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 backlogs 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.1) 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

@@ -4,7 +4,7 @@ De volgende uitgangspunten zijn van toepassing op dit document:
 
 | Volgnummer  | Uitgangspunt |
 |:-----|:----|
-| U01 | De realisatie van de software wordt door ICTU uitgevoerd. Het beheer wordt door {Beheerorganisatie} uitgevoerd. |
+| U01 | De realisatie van de software wordt door ICTU uitgevoerd. Het beheer wordt door {beheerorganisatie} uitgevoerd. |
 | 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. |

Content/Templates/GFO/Doelgroep.md

@@ -1,3 +1,3 @@
 ## Doelgroep
 
-Dit document is bedoeld voor degenen die direct betrokken zijn bij de realisatie, het beheer en het onderhoud van {de applicatie}: product owners, analisten, ontwikkelaars en beheerders. Daarnaast is het GFO nuttig voor belanghebbenden bij de functionele werking van {de applicatie}, zoals domeinexperts, (vertegenwoordigers van) gebruikers en architecten, om een overzicht te krijgen van de functionaliteit van {de applicatie}.
+Dit document is bedoeld voor degenen die direct betrokken zijn bij de realisatie, het beheer en het onderhoud van {het product}: product owners, analisten, ontwikkelaars en beheerders. Daarnaast is het GFO nuttig voor belanghebbenden bij de functionele werking van {het product}, zoals domeinexperts, (vertegenwoordigers van) gebruikers en architecten, om een overzicht te krijgen van de functionaliteit van {het product}.

Content/Templates/GFO/Kaders.md

@@ -1,6 +1,6 @@
 ## Kaders
 
-De volgende kaders zijn van toepassing op de functionaliteit van {de applicatie}:
+De volgende kaders zijn van toepassing op de functionaliteit van {het product}:
 
 | Volgnummer | Kader     |
 |:-----------|:----------|

Content/Templates/GFO/Over-dit-document.md

@@ -1,9 +1,9 @@
 ## Over dit document
 
-Dit globaal functioneel ontwerp (GFO) beschrijft op hoofdlijnen de functionele werking van {de applicatie}. Het GFO geeft inzicht in de manier waarop {gebruikers} {de applicatie} gebruiken en hoe {de applicatie} samenwerkt met andere applicaties in het applicatielandschap van {de opdrachtgevende organisatie}. Het document bevat een globale beschrijving van wíe met de applicatie wát kan doen, in de vorm van use cases.
+Dit globaal functioneel ontwerp (GFO) beschrijft op hoofdlijnen de functionele werking van {het product}. Het GFO geeft inzicht in de manier waarop {gebruikers} {het product} gebruiken en hoe {het product} samenwerkt met andere applicaties in het applicatielandschap van {opdrachtgevende organisatie}. Het document bevat een globale beschrijving van wíe met de applicatie wát kan doen, in de vorm van use cases.
 
 {Verwijder één van de volgende twee paragrafen:}
 
 Bij elke release levert ICTU een versie van het GFO dat is aangepast aan wat daadwerkelijk is gebouwd. Daartoe geeft het document per use case weer of deze al is gerealiseerd. Ook bevat het GFO de tijdens de realisatiefase genomen of aangepaste ontwerpbesluiten.
 
-Het GFO wordt tijdens de realisatiefase niet onderhouden. Bij overdracht van het onderhoud naar een andere partij zal ICTU in opdracht van {de opdrachtgevende organisatie} en in overleg met de ontvangende partij een actueel GFO maken.
+Het GFO wordt tijdens de realisatiefase niet onderhouden. Bij overdracht van het onderhoud naar een andere partij zal ICTU in opdracht van {opdrachtgevende organisatie} en in overleg met de ontvangende partij een actueel GFO maken.

Content/Templates/GFO/Template-Inhoud.md

@@ -1,6 +1,6 @@
 # Context
 
-Dit hoofdstuk beschrijft de context waarin {de applicatie} zal opereren aan de hand van de organisaties en mensen die {de applicatie} gebruiken, de processen die de applicatie ondersteunt en het applicatielandschap waarbinnen {de applicatie} functioneert.
+Dit hoofdstuk beschrijft de context waarin {het product} zal opereren aan de hand van de organisaties en mensen die {het product} gebruiken, de processen die de applicatie ondersteunt en het applicatielandschap waarbinnen {het product} functioneert.
 
 ## Betrokken organisaties en gebruikers
 
@@ -16,7 +16,7 @@ Dit hoofdstuk beschrijft de context waarin {de applicatie} zal opereren aan de h
 
 # Werking op hoofdlijnen
 
-Dit hoofdstuk beschrijft de werking van {de applicatie} op hoofdlijnen. Het beschrijft de hoofdfuncties die het systeem biedt, de ondersteunende functies, de belangrijkste informatie die het systeem bevat, en de klantreizen.
+Dit hoofdstuk beschrijft de werking van {het product} op hoofdlijnen. Het beschrijft de hoofdfuncties die het systeem biedt, de ondersteunende functies, de belangrijkste informatie die het systeem bevat, en de klantreizen.
 
 ## Hoofdfuncties
 
@@ -40,12 +40,12 @@ Dit hoofdstuk beschrijft de werking van {de applicatie} op hoofdlijnen. Het besc
 
 {Leg bij een update in de realisatiefase vast welke use cases zijn gerealiseerd, eventueel met de rationale en met een verwijzing naar de ontwerpbesluiten (in het SAD) die daarvoor zijn genomen.}
 
-Dit hoofdstuk beschrijft de use cases die {de applicatie} ondersteunt. Per use case worden de volgende aspecten benoemd:
+Dit hoofdstuk beschrijft de use cases die {het product} ondersteunt. Per use case worden de volgende aspecten benoemd:
 
 * Id: Unieke identificatie van de use case.
 * Naam: Korte aanduiding van de use case.
 * Doel: Het resultaat dat de (belangrijkste) actor wil bereiken door middel van de use case.
-* Actor(en): Een actor is een persoon of een systeem; de actor gebruikt {de applicatie} om zijn of haar doel te bereiken door middel van de use case.
+* Actor(en): Een actor is een persoon of een systeem; de actor gebruikt {het product} om zijn of haar doel te bereiken door middel van de use case.
 * Precondities: Wat moet er waar zijn om de use case te kunnen starten?
 * Trigger: Wat start de use case?
 * Primaire scenario: Beschrijving van de interactie tussen actor en systeem waarmee het doel bereikt wordt.

Content/Templates/GFO/Uitgangspunten.md

@@ -4,6 +4,6 @@ De volgende uitgangspunten zijn van toepassing op dit document:
 
 | Volgnummer  | Uitgangspunt |
 |:-----|:----|
-| U01 | Voor het beschrijven van de functionele werking van {de applicatie} worden use cases gebruikt. |
+| U01 | Voor het beschrijven van de functionele werking van {het product} worden use cases gebruikt. |
 | U02 | De use cases worden uitgewerkt tot op het niveau van het primaire scenario. Alleen essentiële alternatieve scenario's worden uitgewerkt. |
 | {volgnummer} | {uitgangspunt} |

Content/Templates/IA/Over-dit-document.md

@@ -1,6 +1,6 @@
 ## Over dit document
 
-De infrastructuurarchitectuur (IA) heeft als doel om een globaal overzicht te geven van de technische infrastructuur van {systeem}. Hierbij is er vanuit gegaan dat de oplossing ten minste {aantal} jaar conform specificaties kan functioneren. In de praktijk is een kortere of langere periode mogelijk.
+De infrastructuurarchitectuur (IA) heeft als doel om een globaal overzicht te geven van de technische infrastructuur van {het product}. Hierbij is er vanuit gegaan dat de oplossing ten minste {aantal} jaar conform specificaties kan functioneren. In de praktijk is een kortere of langere periode mogelijk.
 
 Onder infrastructuur wordt verstaan het samenstel van alle generieke off-the-shelf ICT-componenten die nodig zijn om de applicatie te kunnen installeren, operationeel te maken en houden. De infrastructuur eindigt daar waar specifieke elementen (code) en applicatiespecifieke configuraties ontstaan. Concreet omvat de infrastructuur:
 

Content/Templates/IA/Uitgangspunten.md

@@ -7,7 +7,7 @@ De volgende uitgangspunten zijn van toepassing op dit document:
 | U01          | {Toepassing OTAP-omgevingen. NB. Er kan sprake zijn van additionele O-, T- en A-omgevingen, maar ook van omgevingen als pre-productie- en experimenteeromgevingen.} |
 | U03          | {3-Tier.} |
 | U03          | {IP-adres onafhankelijkheid. IP-adressen van systemen of systeemonderdelen zijn te wijzigen zonder dat dit een significantie impact heeft op de applicatie, bijvoorbeeld door ontkoppeling middels DNS.} |
-| U04          | Communicatie via {netwerk} of {internet}. Systeem-naar-systeemcommunicatie van en naar {systeem} verloopt via {netwerk}. |
+| U04          | Communicatie via {netwerk} of {internet}. Systeem-naar-systeemcommunicatie van en naar {het product} verloopt via {netwerk}. |
 | U05          | {Virtualisatie tenzij. In het kader van schaalbaarheid, flexibiliteit en kosten wordt gebruik gemaakt van virtuele servers tenzij dit technisch niet kan.} |
 | U06          | {Uitgangspunten met betrekking tot redundantie.} |
 | {volgnummer} | {uitgangspunt} |

Content/Templates/Inwerkplan-Kwaliteitsmanager/Relatie-documenten.md

@@ -4,7 +4,7 @@ Relevant voor dit inwerkplan zijn de volgende documenten:
 
 | Titel                                  |  Versie  |
 |:---------------------------------------|:--------:|
-| Projectstartarchitectuur {projectnaam} | {versie} |
-| Niet-functionele eisen {productnaam}   | {versie} |
-| Kwaliteitsplan {projectnaam}           | {versie} |
+| Projectstartarchitectuur {het project} | {versie} |
+| Niet-functionele eisen {het product}   | {versie} |
+| Kwaliteitsplan {het project}           | {versie} |
 | {titel}                                | {versie} |