From 195d63c50849d1a6d11871087530b176897bcc28 Mon Sep 17 00:00:00 2001
From: Frank Niessink
Date: Fri, 6 Dec 2024 15:41:35 +0100
Subject: [PATCH] Fix eisentabellen in NFE-template. Release v4.0.3.
---
Content/Templates/NFE/Template-Inhoud.md | 82 +++---
Content/Wijzigingsgeschiedenis.md | 6 +
docs/index.html | 40 +--
.../ICTU-Kwaliteitsaanpak-Checklist.xlsx | Bin 0 -> 36770 bytes
.../ICTU-Kwaliteitsaanpak-Samenvatting.css | 250 ++++++++++++++++++
.../ICTU-Kwaliteitsaanpak-Samenvatting.html | 22 ++
...aliteitsaanpak-Wijzigingsgeschiedenis.html | 22 ++
docs/v4.0.3/ICTU-Kwaliteitsaanpak.css | 250 ++++++++++++++++++
docs/v4.0.3/ICTU-Kwaliteitsaanpak.docx | Bin 0 -> 574660 bytes
docs/v4.0.3/ICTU-Kwaliteitsaanpak.html | 22 ++
docs/v4.0.3/ICTU-Kwaliteitsaanpak.pptx | Bin 0 -> 1149382 bytes
.../ICTU-Template-Compacte-Voorfase.docx | Bin 0 -> 212459 bytes
...ate-Detailtestplan-Softwarerealisatie.docx | Bin 0 -> 215436 bytes
docs/v4.0.3/ICTU-Template-Generiek.docx | Bin 0 -> 209723 bytes
...-Template-Globaal-Functioneel-Ontwerp.docx | Bin 0 -> 211860 bytes
...Template-Inwerkplan-Kwaliteitsmanager.docx | Bin 0 -> 214336 bytes
docs/v4.0.3/ICTU-Template-Kwaliteitsplan.docx | Bin 0 -> 225555 bytes
...mplate-Plan-van-Aanpak-Realisatiefase.docx | Bin 0 -> 218769 bytes
...CTU-Template-Plan-van-Aanpak-Voorfase.docx | Bin 0 -> 217189 bytes
...emplate-Software-architectuurdocument.docx | Bin 0 -> 213801 bytes
docs/v4.0.3/ICTU.png | Bin 0 -> 9122 bytes
docs/v4.0.3/Neutraal-Template-Generiek.docx | Bin 0 -> 30739 bytes
...l-Template-Infrastructuurarchitectuur.docx | Bin 0 -> 32862 bytes
.../Neutraal-Template-Mastertestplan.docx | Bin 0 -> 206126 bytes
...traal-Template-Niet-Functionele-Eisen.docx | Bin 0 -> 48672 bytes
docs/v4.0.3/relaties-tussen-producten.png | Bin 0 -> 344126 bytes
docs/v4.0.3/word-cloud.png | Bin 0 -> 169699 bytes
docs/wip/ICTU-Kwaliteitsaanpak-Checklist.xlsx | Bin 36766 -> 36766 bytes
.../ICTU-Kwaliteitsaanpak-Samenvatting.html | 2 +-
...aliteitsaanpak-Wijzigingsgeschiedenis.html | 2 +-
docs/wip/ICTU-Kwaliteitsaanpak.docx | Bin 574653 -> 574653 bytes
docs/wip/ICTU-Kwaliteitsaanpak.html | 2 +-
docs/wip/ICTU-Kwaliteitsaanpak.pptx | Bin 1149379 -> 1149379 bytes
docs/wip/ICTU-Template-Compacte-Voorfase.docx | Bin 212600 -> 212451 bytes
...ate-Detailtestplan-Softwarerealisatie.docx | Bin 215566 -> 215429 bytes
docs/wip/ICTU-Template-Generiek.docx | Bin 209857 -> 209717 bytes
...-Template-Globaal-Functioneel-Ontwerp.docx | Bin 212002 -> 211854 bytes
...Template-Inwerkplan-Kwaliteitsmanager.docx | Bin 214449 -> 214330 bytes
docs/wip/ICTU-Template-Kwaliteitsplan.docx | Bin 225685 -> 225551 bytes
...mplate-Plan-van-Aanpak-Realisatiefase.docx | Bin 218915 -> 218760 bytes
...CTU-Template-Plan-van-Aanpak-Voorfase.docx | Bin 217307 -> 217182 bytes
...emplate-Software-architectuurdocument.docx | Bin 213934 -> 213796 bytes
docs/wip/Neutraal-Template-Generiek.docx | Bin 30872 -> 30731 bytes
...l-Template-Infrastructuurarchitectuur.docx | Bin 33000 -> 32854 bytes
.../wip/Neutraal-Template-Mastertestplan.docx | Bin 206266 -> 206120 bytes
...traal-Template-Niet-Functionele-Eisen.docx | Bin 48839 -> 48665 bytes
46 files changed, 636 insertions(+), 64 deletions(-)
create mode 100644 docs/v4.0.3/ICTU-Kwaliteitsaanpak-Checklist.xlsx
create mode 100644 docs/v4.0.3/ICTU-Kwaliteitsaanpak-Samenvatting.css
create mode 100644 docs/v4.0.3/ICTU-Kwaliteitsaanpak-Samenvatting.html
create mode 100644 docs/v4.0.3/ICTU-Kwaliteitsaanpak-Wijzigingsgeschiedenis.html
create mode 100644 docs/v4.0.3/ICTU-Kwaliteitsaanpak.css
create mode 100644 docs/v4.0.3/ICTU-Kwaliteitsaanpak.docx
create mode 100644 docs/v4.0.3/ICTU-Kwaliteitsaanpak.html
create mode 100644 docs/v4.0.3/ICTU-Kwaliteitsaanpak.pptx
create mode 100644 docs/v4.0.3/ICTU-Template-Compacte-Voorfase.docx
create mode 100644 docs/v4.0.3/ICTU-Template-Detailtestplan-Softwarerealisatie.docx
create mode 100644 docs/v4.0.3/ICTU-Template-Generiek.docx
create mode 100644 docs/v4.0.3/ICTU-Template-Globaal-Functioneel-Ontwerp.docx
create mode 100644 docs/v4.0.3/ICTU-Template-Inwerkplan-Kwaliteitsmanager.docx
create mode 100644 docs/v4.0.3/ICTU-Template-Kwaliteitsplan.docx
create mode 100644 docs/v4.0.3/ICTU-Template-Plan-van-Aanpak-Realisatiefase.docx
create mode 100644 docs/v4.0.3/ICTU-Template-Plan-van-Aanpak-Voorfase.docx
create mode 100644 docs/v4.0.3/ICTU-Template-Software-architectuurdocument.docx
create mode 100644 docs/v4.0.3/ICTU.png
create mode 100644 docs/v4.0.3/Neutraal-Template-Generiek.docx
create mode 100644 docs/v4.0.3/Neutraal-Template-Infrastructuurarchitectuur.docx
create mode 100644 docs/v4.0.3/Neutraal-Template-Mastertestplan.docx
create mode 100644 docs/v4.0.3/Neutraal-Template-Niet-Functionele-Eisen.docx
create mode 100644 docs/v4.0.3/relaties-tussen-producten.png
create mode 100644 docs/v4.0.3/word-cloud.png
diff --git a/Content/Templates/NFE/Template-Inhoud.md b/Content/Templates/NFE/Template-Inhoud.md
index 950e0923..4be0f223 100644
--- a/Content/Templates/NFE/Template-Inhoud.md
+++ b/Content/Templates/NFE/Template-Inhoud.md
@@ -104,9 +104,9 @@ Van WCAG versie 2.2 is op het moment nog geen Nederlandse vertaling, wel van ver
Conform de EN 301 549, hanteert {opdrachtgevende organisatie} de succescriteria voor niveau A en AA als eisen.
-| Nr. | Eis | Prio | Rationale | Bewijs |
-|:----|:--------------------------------------------------------------------|:-------|:------------------------|:--------------------|
-| 1 | De applicatie voldoet aan de WCAG2.2 succescriteria, niveau A en AA | {prio} | Wettelijke verplichting | Axe-core rapportage |
+| Nr. | Eis | Prio | Rationale | Realisatie in | Realisatie door | Bewijs |
+| :--- | :------------------------------------------------------------------ | :----- | :---------------------- | :------------ | :-------------- | :------------------ |
+| 1 | De applicatie voldoet aan de WCAG2.2 succescriteria, niveau A en AA | {prio} | Wettelijke verplichting | {software} | ICTU | Axe-core rapportage |
Onderstaande tabel bevat de WCAG2.2 succescriteria. {Verwijder de AAA-succescriteria indien gewenst.} Per succescriterium is aangegeven of Axe-core, en zo ja met welke regels, het criterium geautomatiseerd kan controleren. {Geef aan of de succescriteria die Axe-core niet geautomatiseerd kan controleren wel of niet met de hand zullen worden gecontroleerd.}
@@ -121,10 +121,10 @@ Naast de aan NEN-ISO/IEC 25010 ontleende hoofdeigenschap bruikbaarheid zijn voor
* Taal: welke talen dienen te worden ondersteund.
* Leesbaarheid: teksten moeten makkelijk te lezen zijn. Korte zinnen hebben de voorkeur. Hoe gemakkelijker de zin en de woorden, hoe beter de leesbaarheid.
-| Nr. | Eis | Prio | Rationale | Bewijs |
-|:----|:-----------------------------------------------|:-------|:---------------------------------------------------------------------------------------------------------------------|:---------|
-| 1 | De applicatie gebruikt maximaal taalniveau B1 | {prio} | [Aanbevolen richtlijn](https://www.communicatierijk.nl/vakkennis/rijkswebsites/aanbevolen-richtlijnen/taalniveau-b1) | {bewijs} |
-| 2 | De applicatie ondersteunt {ondersteunde talen} | {prio} | {rationale} | {bewijs} |
+| Nr. | Eis | Prio | Rationale | Realisatie in | Realisatie door | Bewijs |
+| :--- | :--------------------------------------------- | :----- | :------------------------------------------------------------------------------------------------------------------- | :------------ | :-------------- | :------- |
+| 1 | De applicatie gebruikt maximaal taalniveau B1 | {prio} | [Aanbevolen richtlijn](https://www.communicatierijk.nl/vakkennis/rijkswebsites/aanbevolen-richtlijnen/taalniveau-b1) | {software} | {partij} | {bewijs} |
+| 2 | De applicatie ondersteunt {ondersteunde talen} | {prio} | {rationale} | {software} | ICTU | {bewijs} |
# Betrouwbaarheid
@@ -164,40 +164,40 @@ De overheid is gebonden aan kaderstelling op het gebied van informatiebeveiligin
BIO en SSD bevatten ook een aantal maatregelen ten aanzien van software en/of de infrastructurele componenten waar deze software gebruik van maakt. Deze maatregelen zijn hieronder als eisen opgenomen.
-| Nr. | Eis | Prio | Rationale | Realisatie in | Realisatie door | Bewijs |
-|:----|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:---------------------------------|:----------------|:---------|
-| 1 | Applicaties zijn gebaseerd op een formele, met de beheerorganisatie afgestemde standaard stack | {prio} | Dit maakt integrale beveiliging mogelijk en beperkt het risico op nieuwe en onbekende zwakheden door het gebruik van onbekende componenten of services | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 2 | De architectuur van een (web)applicatie is gebaseerd op een gelaagde structuur door de presentatielaag, de applicatielaag en de gegevens te scheiden | {prio} | Hierdoor kunnen de lagen beschermd worden binnen de netwerkzones | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 3 | (Web)applicaties stellen de identiteit van externe gebruikers vast op basis van een mechanisme voor identificatie en authenticatie, waarbij de authenticatiegegevens in een geconsolideerde authenticatievoorziening worden beheerd | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 4 | (Web)applicaties stellen de identiteit van interne gebruikers vast op basis van een mechanisme voor identificatie en authenticatie, waarbij de authenticatie- en autorisatiegegevens in een geconsolideerde authenticatie- en autorisatievoorziening worden beheerd | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 5 | Inrichting van de autorisaties van gebruikers (inclusief beheerders) binnen een (web)applicatie: | {prio} | Autorisaties kunnen worden toegewezen aan organisatorische functies en scheiding van niet te verenigen autorisaties is mogelijk | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 5a | In de applicatie zijn de autorisaties op een beheersbare wijze geordend. De applicatie maakt daartoe gebruik van autorisatiegroepen | {prio} | | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 5b | Op basis van taken, verantwoordelijkheden en bevoegdheden zijn de niet te verenigen taken en autorisaties geïdentificeerd | {prio} | | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 5c | Verantwoordelijkheden voor beheer en wijziging van gegevens en bijbehorende informatiesysteemfuncties moeten eenduidig toegewezen zijn aan één specifieke (beheerders)rol | {prio} | | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 5d | Er is een scheiding tussen beheertaken en overige gebruikstaken. Beheerswerkzaamheden worden alleen uitgevoerd wanneer ingelogd als beheerder, normale gebruikstaken alleen wanneer ingelogd als gebruiker | {prio} | | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 6 | Applicaties hebben een beheerinterface dat gescheiden is van de standaard gebruikersinterface. Deze scheiding komt zowel in de operationele interfaces (dat wil zeggen de deployment van de onderdelen) als in de autorisaties die toegang geven tot de interfaces tot uitdrukking. Het uiterlijk van de beheerinterface onderscheidt zich eveneens van de gebruikersinterface | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 7 | Activiteiten van gebruikers, uitzonderingen en informatiebeveiligingsgebeurtenissen behoren te worden vastgelegd in audit-logbestanden. Deze logbestanden behoren gedurende een overeengekomen periode te worden bewaard | {prio} | Mogelijk maken van toekomstig onderzoek en toegangscontrole | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 8 | Applicaties normaliseren de invoer, valideren de invoer op syntax en semantiek en normaliseren uitvoer waar dit toepasbaar is | {prio} | Normaliseren en valideren van de invoer beschermt een applicatie tegen manipulatie (cross-site scripting, cross-site request forgery SQL-injectie, buffer overflow, et cetera). Normaliseren van uitvoer beschermt de ontvanger tegen manipulatie. | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 9 | Wanneer de invoervalidatie faalt, stopt de verwerking van de betreffende invoer in zijn geheel en hervat de applicatie zijn normale functies alsof de invoer nooit ontvangen was. Het falen wordt wel gelogd | {prio} | Onbeschikbaarheid van de applicatie voorkomen en tegelijkertijd analyse van de opgetreden situatie mogelijk maken | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 10 | Applicaties maken gebruik van statisch geconfigureerde queries en/of commando’s, waarbij parameters/variabelen zodanig worden ingevoegd dat zij de beoogde werking niet kunnen beïnvloeden. Voor databases is dit bekend als een ‘prepared query’. Voor commando’s is een constructie gekozen die interpretatie van een parameter/variabele door een commando interpreter/shell uitsluit. Mocht het niet mogelijk zijn hieraan te voldoen, dan wordt de waarde van elke parameter/variabele voor gebruik zodanig behandeld dat dezelfde zekerheid wordt verkregen. Te allen tijde wordt voorkomen dat vrije toegang tot het commando- of query-interface gegeven wordt. Dit geldt zowel voor waarden die door een gebruiker (in)direct worden aangeleverd, als voor waarden uit configuraties of databases | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 11 | Een (web)applicatie is voorzien van Concurrent Session Control, die slechts één sessie per gebruiker toestaat, tenzij onderbouwd is dat meer noodzakelijk is | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 12 | Een applicatie heeft een instelbare maximale sessieduur en een maximale duur van inactiviteit. Na deze periode wordt een sessie automatisch afgesloten, alsof de gebruiker zelf de sessie beëindigd heeft | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 13 | De maximale sessieduur en maximale inactiviteit zijn door (of namens) de opdrachtgevende organisatie in te stellen. De instelbare waarden zijn per default begrenst op 10 uur (sessieduur) en 15 minuten (inactiviteit). Alleen op expliciet aangeven van de opdrachtgevede organisatie kan hiervan worden afgeweken | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 14 | Applicaties maken gebruik van gangbare protocollen en cryptografische technieken, versleutelen informatie volgens de maatregelenselectie in het IB-plan en borgen de onweerlegbaarheid van daartoe aangewezen transacties via cryptografische technieken. De gebruikte cryptografische algoritmen voor versleuteling zijn als open standaard gedocumenteerd en zijn door onafhankelijke betrouwbare deskundigen getoetst. De cryptografische beveiligingsvoorzieningen en componenten voldoen aan algemeen gangbare beveiligingscriteria (zoals FIPS 140-2 en waar mogelijk NBV) | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 15 | (Web)applicatie voorkomen de mogelijkheid van dynamische file includes. Indien gebruik gemaakt wordt van een applicatieserver sluit de serverconfiguratie file includes uit. Mocht het niet mogelijk zijn aan hieraan te voldoen, dan wordt voor de includes gebruik gemaakt van een vertrouwde locatie en een expliciete whitelist voor de files | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 16 | Applicaties hebben geen run-time afhankelijkheid van externe codebronnen | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 17 | Applicaties zijn gemaakt met de op het moment van uitleveren meest recente en/of door de leverancier aanbevolen versies van externe bibliotheken, raamwerken of andersoortige bouwblokken | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 18 | Een applicatie vangt interne fouten (excepties) af op hoofdniveau, zonder ongecontroleerd te falen (crash). Afgevangen fouten worden vastgelegd (log) en aan gebruikers wordt een melding getoond die geen inhoudelijke details bevat. Een betekenisloze referentie (code) van de fout ten behoeve van communicatie over de fout mag wel getoond worden | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 19 | Een applicatie heeft een uniforme en veilige wijze van applicatie-logging. De logging bevat geen inloggegevens (credentials) of vertrouwelijke gegevens over personen. Referenties (bv identifiers) zijn wel toegestaan | {prio} | De logging zorgt voor traceerbaarheid van gebeurtenissen en activiteiten in relatie tot ten minste personen, systemen, applicaties en tijd | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 20 | Een applicatie beperkt de gebruikte protocollen, parameters (headers) en functionaliteit tot wat nodig is. Hieronder vallen ook HTTP-headers en HTTP-methoden (liefst niet meer dan GET en POST): | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 20a | De webserver stuurt bij een antwoord aan een gebruiker alleen die informatie in de HTTP-headers mee die van belang is voor het functioneren van HTTP | {prio} | | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 20b | De webapplicatie toont alleen noodzakelijke informatie in HTTP-headers die van belang is voor het functioneren van HTTP | {prio} | | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 20c | De webserver gebruikt alleen de HTTP-functionaliteiten die nodig zijn voor het functioneren van de webapplicatie | {prio} | | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 21 | De aan de gebruiker aangeboden scripts / code bevat geen commentaar | {prio} | Voorkomt misbruik van het commentaar | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 22 | De aan de gebruiker getoonde informatie bevat geen directory listings | {prio} | Voorkomt misbruik van de directory listing | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 23 | Wanneer toegang tot (de inhoud van) het filesysteem nodig is, gebeurt dit altijd onder expliciete autorisatie en controle door de applicatie | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
-| 24 | In de (web)applicatieomgeving zijn signaleringsfuncties (registratie en detectie) actief en efficiënt, effectief en beveiligd ingericht | {prio} | {rationale}{software, hardware, combinatie} | {partij} | | {bewijs} |
-| {nr} | {eis} | {prio} | {rationale} |{software, hardware, combinatie} | {partij} |{software, hardware, combinatie} | {partij} | {bewijs} |
+| Nr. | Eis | Prio | Rationale | Realisatie in | Realisatie door | Bewijs |
+| :--- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------- | :-------------- | :------------------------------- | -------- | -------- |
+| 1 | Applicaties zijn gebaseerd op een formele, met de beheerorganisatie afgestemde standaard stack | {prio} | Dit maakt integrale beveiliging mogelijk en beperkt het risico op nieuwe en onbekende zwakheden door het gebruik van onbekende componenten of services | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 2 | De architectuur van een (web)applicatie is gebaseerd op een gelaagde structuur door de presentatielaag, de applicatielaag en de gegevens te scheiden | {prio} | Hierdoor kunnen de lagen beschermd worden binnen de netwerkzones | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 3 | (Web)applicaties stellen de identiteit van externe gebruikers vast op basis van een mechanisme voor identificatie en authenticatie, waarbij de authenticatiegegevens in een geconsolideerde authenticatievoorziening worden beheerd | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 4 | (Web)applicaties stellen de identiteit van interne gebruikers vast op basis van een mechanisme voor identificatie en authenticatie, waarbij de authenticatie- en autorisatiegegevens in een geconsolideerde authenticatie- en autorisatievoorziening worden beheerd | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 5 | Inrichting van de autorisaties van gebruikers (inclusief beheerders) binnen een (web)applicatie: | {prio} | Autorisaties kunnen worden toegewezen aan organisatorische functies en scheiding van niet te verenigen autorisaties is mogelijk | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 5a | In de applicatie zijn de autorisaties op een beheersbare wijze geordend. De applicatie maakt daartoe gebruik van autorisatiegroepen | {prio} | | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 5b | Op basis van taken, verantwoordelijkheden en bevoegdheden zijn de niet te verenigen taken en autorisaties geïdentificeerd | {prio} | | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 5c | Verantwoordelijkheden voor beheer en wijziging van gegevens en bijbehorende informatiesysteemfuncties moeten eenduidig toegewezen zijn aan één specifieke (beheerders)rol | {prio} | | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 5d | Er is een scheiding tussen beheertaken en overige gebruikstaken. Beheerswerkzaamheden worden alleen uitgevoerd wanneer ingelogd als beheerder, normale gebruikstaken alleen wanneer ingelogd als gebruiker | {prio} | | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 6 | Applicaties hebben een beheerinterface dat gescheiden is van de standaard gebruikersinterface. Deze scheiding komt zowel in de operationele interfaces (dat wil zeggen de deployment van de onderdelen) als in de autorisaties die toegang geven tot de interfaces tot uitdrukking. Het uiterlijk van de beheerinterface onderscheidt zich eveneens van de gebruikersinterface | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 7 | Activiteiten van gebruikers, uitzonderingen en informatiebeveiligingsgebeurtenissen behoren te worden vastgelegd in audit-logbestanden. Deze logbestanden behoren gedurende een overeengekomen periode te worden bewaard | {prio} | Mogelijk maken van toekomstig onderzoek en toegangscontrole | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 8 | Applicaties normaliseren de invoer, valideren de invoer op syntax en semantiek en normaliseren uitvoer waar dit toepasbaar is | {prio} | Normaliseren en valideren van de invoer beschermt een applicatie tegen manipulatie (cross-site scripting, cross-site request forgery SQL-injectie, buffer overflow, et cetera). Normaliseren van uitvoer beschermt de ontvanger tegen manipulatie. | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 9 | Wanneer de invoervalidatie faalt, stopt de verwerking van de betreffende invoer in zijn geheel en hervat de applicatie zijn normale functies alsof de invoer nooit ontvangen was. Het falen wordt wel gelogd | {prio} | Onbeschikbaarheid van de applicatie voorkomen en tegelijkertijd analyse van de opgetreden situatie mogelijk maken | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 10 | Applicaties maken gebruik van statisch geconfigureerde queries en/of commando’s, waarbij parameters/variabelen zodanig worden ingevoegd dat zij de beoogde werking niet kunnen beïnvloeden. Voor databases is dit bekend als een ‘prepared query’. Voor commando’s is een constructie gekozen die interpretatie van een parameter/variabele door een commando interpreter/shell uitsluit. Mocht het niet mogelijk zijn hieraan te voldoen, dan wordt de waarde van elke parameter/variabele voor gebruik zodanig behandeld dat dezelfde zekerheid wordt verkregen. Te allen tijde wordt voorkomen dat vrije toegang tot het commando- of query-interface gegeven wordt. Dit geldt zowel voor waarden die door een gebruiker (in)direct worden aangeleverd, als voor waarden uit configuraties of databases | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 11 | Een (web)applicatie is voorzien van Concurrent Session Control, die slechts één sessie per gebruiker toestaat, tenzij onderbouwd is dat meer noodzakelijk is | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 12 | Een applicatie heeft een instelbare maximale sessieduur en een maximale duur van inactiviteit. Na deze periode wordt een sessie automatisch afgesloten, alsof de gebruiker zelf de sessie beëindigd heeft | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 13 | De maximale sessieduur en maximale inactiviteit zijn door (of namens) de opdrachtgevende organisatie in te stellen. De instelbare waarden zijn per default begrenst op 10 uur (sessieduur) en 15 minuten (inactiviteit). Alleen op expliciet aangeven van de opdrachtgevede organisatie kan hiervan worden afgeweken | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 14 | Applicaties maken gebruik van gangbare protocollen en cryptografische technieken, versleutelen informatie volgens de maatregelenselectie in het IB-plan en borgen de onweerlegbaarheid van daartoe aangewezen transacties via cryptografische technieken. De gebruikte cryptografische algoritmen voor versleuteling zijn als open standaard gedocumenteerd en zijn door onafhankelijke betrouwbare deskundigen getoetst. De cryptografische beveiligingsvoorzieningen en componenten voldoen aan algemeen gangbare beveiligingscriteria (zoals FIPS 140-2 en waar mogelijk NBV) | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 15 | (Web)applicatie voorkomen de mogelijkheid van dynamische file includes. Indien gebruik gemaakt wordt van een applicatieserver sluit de serverconfiguratie file includes uit. Mocht het niet mogelijk zijn aan hieraan te voldoen, dan wordt voor de includes gebruik gemaakt van een vertrouwde locatie en een expliciete whitelist voor de files | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 16 | Applicaties hebben geen run-time afhankelijkheid van externe codebronnen | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 17 | Applicaties zijn gemaakt met de op het moment van uitleveren meest recente en/of door de leverancier aanbevolen versies van externe bibliotheken, raamwerken of andersoortige bouwblokken | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 18 | Een applicatie vangt interne fouten (excepties) af op hoofdniveau, zonder ongecontroleerd te falen (crash). Afgevangen fouten worden vastgelegd (log) en aan gebruikers wordt een melding getoond die geen inhoudelijke details bevat. Een betekenisloze referentie (code) van de fout ten behoeve van communicatie over de fout mag wel getoond worden | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 19 | Een applicatie heeft een uniforme en veilige wijze van applicatie-logging. De logging bevat geen inloggegevens (credentials) of vertrouwelijke gegevens over personen. Referenties (bv identifiers) zijn wel toegestaan | {prio} | De logging zorgt voor traceerbaarheid van gebeurtenissen en activiteiten in relatie tot ten minste personen, systemen, applicaties en tijd | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 20 | Een applicatie beperkt de gebruikte protocollen, parameters (headers) en functionaliteit tot wat nodig is. Hieronder vallen ook HTTP-headers en HTTP-methoden (liefst niet meer dan GET en POST): | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 20a | De webserver stuurt bij een antwoord aan een gebruiker alleen die informatie in de HTTP-headers mee die van belang is voor het functioneren van HTTP | {prio} | | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 20b | De webapplicatie toont alleen noodzakelijke informatie in HTTP-headers die van belang is voor het functioneren van HTTP | {prio} | | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 20c | De webserver gebruikt alleen de HTTP-functionaliteiten die nodig zijn voor het functioneren van de webapplicatie | {prio} | | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 21 | De aan de gebruiker aangeboden scripts / code bevat geen commentaar | {prio} | Voorkomt misbruik van het commentaar | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 22 | De aan de gebruiker getoonde informatie bevat geen directory listings | {prio} | Voorkomt misbruik van de directory listing | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 23 | Wanneer toegang tot (de inhoud van) het filesysteem nodig is, gebeurt dit altijd onder expliciete autorisatie en controle door de applicatie | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} |
+| 24 | In de (web)applicatieomgeving zijn signaleringsfuncties (registratie en detectie) actief en efficiënt, effectief en beveiligd ingericht | {prio} | {rationale}{software, hardware, combinatie} | {partij} | | {bewijs} |
+| {nr} | {eis} | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {software, hardware, combinatie} | {partij} | {bewijs} |
## Vertrouwelijkheid
diff --git a/Content/Wijzigingsgeschiedenis.md b/Content/Wijzigingsgeschiedenis.md
index 0de324db..9e383b34 100644
--- a/Content/Wijzigingsgeschiedenis.md
+++ b/Content/Wijzigingsgeschiedenis.md
@@ -1,3 +1,9 @@
+# Versie 4.0.3, 6 december 2024
+
+## Template Niet-Functionele Eisen
+
+* Gezorgd dat alle eisentabellen dezelfde kolommen hebben.
+
# Versie 4.0.2, 26 november 2024
## Alle templates
diff --git a/docs/index.html b/docs/index.html
index 1cfccec6..60197076 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -8,28 +8,28 @@
ICTU heeft jarenlange ervaring met het realiseren van software en past de opgedane ervaring toe bij de ontwikkeling van nieuwe software. Die ervaring is vastgelegd in een werkwijze, deze “ICTU Kwaliteitsaanpak Softwareontwikkeling”, die telkens wordt aangepast en aangevuld op basis van de praktijk.
ICTU is ervan overtuigd dat het bouwen van duurzame software, die goed aansluit bij de behoeften van gebruikers en andere belanghebbenden, bijdraagt aan betere informatiesystemen en een betere dienstverlening door de overheid. Dienstverlening die betrouwbaar moet zijn voor burgers, bedrijven en ambtenaren. Om samen met opdrachtgevende organisaties passende oplossingen te realiseren ontwikkelt ICTU daarom software volgens een agile proces. En om de duurzaamheid en betrouwbaarheid te bevorderen besteedt ICTU standaard aandacht aan beveiliging, privacy, performance, gebruikskwaliteit en toegankelijkheid. De Kwaliteitsaanpak dient daarvoor als leidraad, maar de aanpak voorziet ook in mogelijkheden om het project en het eindproduct aan te passen aan de specifieke situatie.
Om projecten, die software realiseren volgens de Kwaliteitsaanpak, efficiënt en effectief te ondersteunen, heeft ICTU twee gespecialiseerde afdelingen in het leven geroepen. Deze afdelingen staan projecten bij door middel van kennis, menskracht en technische hulpmiddelen. Zo profiteren projecten van schaalgrootte en hergebruik van inzichten.
Met behulp van de ICTU Kwaliteitsaanpak Softwareontwikkeling heeft ICTU samen met andere overheden inmiddels enige tientallen projecten succesvol uitgevoerd. ICTU wil deze aanpak graag aanvullen met de ervaringen en geleerde lessen van andere organisaties en deze overdraagbaar maken en breder uitdragen. Om die reden stelt ICTU deze Kwaliteitsaanpak aan iedereen beschikbaar via https://www.ictu.nl/kwaliteitsaanpak en heeft zij, samen met normalisatie-instituut NEN en partijen uit overheid en markt, een praktijkrichtlijn “Risicobeheersing bij ontwikkeling en onderhoud van maatwerksoftware” [NEN NPR 5326:2019] gepubliceerd, die mede is gebaseerd op de ICTU Kwaliteitsaanpak Softwareontwikkeling.
Doelstellingen
De ICTU Kwaliteitsaanpak Softwareontwikkeling heeft drie doelstellingen:
Opdrachtgevende organisaties helpen bekende risico's bij softwareontwikkeling, zoals technische schuld, vertraging en defecten, zo veel mogelijk te voorkomen.
ICTU helpen om software te ontwikkelen die de missie van ICTU, namelijk bijdragen aan een betere digitale overheid, ondersteunt.
De overheid als geheel helpen bij het zo goed mogelijk ontwikkelen van software.
De Kwaliteitsaanpak zelf is geformuleerd in de vorm van maatregelen die elke software-ontwikkelende organisatie kan treffen om risico's van softwareontwikkeling te mitigeren en de kans op succesvolle softwareontwikkelprojecten te vergroten. De maatregelen zijn gebaseerd op geleerde lessen uit de praktijk van ICTU.
De Kwaliteitsaanpak is een evoluerende aanpak, gebaseerd op de ervaringen die ICTU continu opdoet in de projecten waarin ICTU samen met opdrachtgevende organisaties maatwerksoftware ontwikkelt en onderhoudt. ICTU hanteert daarbij de vuistregel dat als tenminste 80% van de projecten minstens 80% van de tijd een bepaalde werkwijze hanteren, voor die werkwijze een maatregel in de Kwaliteitsaanpak wordt opgenomen. Maar het kan ook voorkomen dat maatregelen om andere redenen landen in de Kwaliteitsaanpak; denk aan het toegankelijk maken van software dat wettelijk verplicht is. Zie ook de wijzigingsgeschiedenis in PDF-formaat of HTML-formaat.
De maatregelen vormen het startpunt voor de aanpak van ieder ICTU-softwareproject, waarbij ruimte wordt geboden voor variatie of alternatieve invulling. Bijvoorbeeld stelt de Kwaliteitsaanpak: software wordt minimaal bij iedere grote release of tenminste twee keer per jaar onderworpen aan een beveiligingstest door beveiligingsexperts die ICTU daarvoor inhuurt (zie M26: Het project laat de beveiliging van het ontwikkelde product periodiek beoordelen). Een alternatief is dat de opdrachtgevende organisatie de verantwoordelijkheid neemt voor het laten uitvoeren van beveiligingstests. Hierover maakt de projectleider nadere afspraken met de opdrachtgever.
De Kwaliteitsaanpak is dus zowel voorschrijvend als beschrijvend. Voorschrijvend omdat ICTU verwacht dat projecten die maatwerksoftware ontwikkelen en onderhouden de aanpak toepassen, en alleen aanpassen als daar een goede reden voor is, en mits dat wettelijk is toegestaan. Tegelijkertijd is de aanpak beschrijvend omdat de meeste maatregelen voortkomen uit de bestaande werkwijzen van de projecten. Zoals blijkt uit de self-assessment die ICTU regelmatig uitvoert op de toepassing van de Kwaliteitsaanpak.
Maatregelen
Hieronder zijn alle maatregeldefinities uit de Kwaliteitsaanpak opgenomen. Zie de Kwaliteitsaanpak zelf voor een uitgebreidere beschrijving van de maatregelen, inclusief context en rationale.
Producten
M31: Het project beschikt over actuele vastgestelde informatie Voor een goede uitvoering van het project is specifieke informatie nodig. De opdrachtgevende organisatie zorgt dat het project bij de start van de voorfase inzicht heeft in de informatie die typisch wordt vastgelegd in een projectstartarchitectuur, business impact analysis en privacy impact assessment. Waar nodig werkt de opdrachtgevende organisatie de informatie bij tijdens de voorfase en realisatiefase.
M01: Het project levert in elke fase vastgestelde producten en informatie op Iedere projectfase levert specifieke informatie op. De voorfase levert inzicht in de functionele en niet-functionele eisen, ontwerp en architectuur, testplannen, operationele risico's, en benodigde kwaliteitsmaatregelen. Deze informatie wordt tijdens de realisatiefase waar nodig bijgewerkt. De realisatiefase levert één of meerdere werkende versies van de software met regressietests, aangevuld met een vrijgaveadvies, release notes en installatiedocumentatie.
M32: Het project onderzoekt de kwaliteit van over te nemen software Als tijdens een project bestaande software dient te worden afgebouwd, onderhouden en/of herbouwd, vindt een onderzoek plaats naar de kwaliteit van deze software.
M02: Het project bewaakt continu dat het product aan de kwaliteitsnormen voldoet Projecten bewaken zo snel mogelijk vanaf de start de door het project en ICTU vastgestelde kwaliteitsnormen en voldoen daar zo snel en goed mogelijk aan. De kwaliteit van producten, die nog niet zijn afgerond of nog niet aan de normen voldoen, wordt door het project bewaakt. Het voldoen aan de kwaliteitsnormen is onderdeel van de Definition of Done en herstel van de kwaliteit wordt planmatig opgepakt.
M03: Het project zorgt dat het product traceerbaar aan eisen voldoet Eisen zijn wederzijds traceerbaar naar bewijsmateriaal, zoals logische testgevallen, dat de eis gerealiseerd is; dat wil zeggen dat geadministreerd is bij welke eis bewijsmateriaal hoort en vice versa. Dit wordt waar mogelijk met tooling ondersteund.
M13: Het project gebruikt ISO-25010 voor de specificatie van productkwaliteitseisen Voor specificatie en documentatie van vereiste en gewenste kwaliteitseigenschappen, de niet-functionele eisen, maken projecten gebruik van de terminologie en categorisering uit NEN-ISO/IEC 25010. Projecten gebruiken NEN-ISO/IEC 25010 om te controleren of alle relevante kwaliteitseigenschappen van het op te leveren eindproduct worden meegenomen in de ontwikkeling en/of onderhoud van het product.
M04: Het project borgt de correcte werking van het product met geautomatiseerde regressietests Regressietests - tests die verifiëren of eerder ontwikkelde software nog steeds correct werkt na wijzigingen in de software of aansluiting op andere externe koppelvlakken - zijn geautomatiseerd.
M07: Het project gebruikt een continuous delivery pipeline om het product te bouwen, testen en op te leveren Er is een geautomatiseerde continuous delivery pipeline die aantoonbaar correct werkt en de software bouwt, installeert in de testomgevingen, test op functionele en niet-functionele eigenschappen en oplevert, al dan niet inclusief installatie in de productieomgeving.
M16: Het project gebruikt tools voor vastgestelde taken ICTU stelt het gebruik van tools verplicht voor de volgende taken:
backlog management en agile werken,
inrichten en uitvoeren van een continuous delivery pipeline,
monitoren van de kwaliteit van broncode,
versiebeheer van op te leveren producten,
release van software,
maken van testrapportages,
maken van kwaliteitsrapportages,
controleren van de configuratie op aanwezigheid van bekende kwetsbaarheden,
controleren van door de applicatie gebruikte versies van externe software op aanwezigheid van bekende kwetsbaarheden,
statische controle van de software op aanwezigheid van kwetsbare constructies,
dynamische controle van de software op aanwezigheid van kwetsbare constructies,
controleren van container images op aanwezigheid van bekende kwetsbaarheden,
testen van performance en schaalbaarheid,
testen op toegankelijkheid van de applicatie,
produceren van een "software bill of materials" (SBoM),
opslaan van artifacten,
registratie van incidenten bij gebruik en beheer, en
bij het uitvoeren van operationeel beheer; uitrollen van de software in de productieomgeving.
M08: Het project maakt technische schuld inzichtelijk en lost deze planmatig op Technische schuld is inzichtelijk en wordt planmatig aangepakt. De kwaliteitsmanager is verantwoordelijk voor het inzichtelijk maken van de technische schuld. De software delivery manager is verantwoordelijk voor het planmatig aanpakken van de technische schuld en zorgt dat het Scrumteam regelmatig en voldoende tijd heeft om technische schuld te voorkomen en op te lossen. Het Scrumteam is verantwoordelijk voor het zoveel mogelijk voorkomen van technische schuld en voor het identificeren van technische schuld die toch optreedt.
M26: Het project laat de beveiliging van het ontwikkelde product periodiek beoordelen Projecten laten periodiek de beveiliging van de ontwikkelde software beoordelen. Een beveiligingsexpert onderzoekt de code zowel geautomatiseerd als handmatig op veelvoorkomende kwetsbaarheden en op het voldoen aan voorgeschreven beveiligingsnormen. Overheidsspecifieke beveiligingsnormen of -raamwerken, zoals de BIO (Baseline Informatiebeveiliging Overheid), bieden een basis voor de beoordeling. Bevindingen uit de beveiligingstest worden vastgelegd als onderdeel van de werkvoorraad voor het ontwikkelproces.
Processen
M14: Het project bereidt samen met opdrachtgevende organisatie en betrokken partijen de realisatie voor Projecten hebben een voorbereidingsfase, "voorfase" genoemd, voorafgaand aan de realisatiefase. Voor het uitvoeren van de voorfase zijn vertegenwoordigers van de opdrachtgevende organisatie, de beoogde beheerorganisatie en andere partijen betrokken die meewerken aan het realiseren van een deel van de op te leveren producten. Het doel van de voorfase is beeld krijgen van de te realiseren oplossing, van de risico's die zich tijdens realisatie kunnen voordoen en van de kaders waarbinnen de oplossing moet passen; tijdens de realisatiefase vinden bouw en onderhoud van de software en actualiseren en afronden van documentatie plaats.
M21: Het project selecteert medewerkers op basis van kwaliteit Bij de inzet van medewerkers gaat kwaliteit boven andere aspecten, zoals beschikbaarheid, prijs en doorlooptijd.
M23: Het project zorgt voor de aanwezigheid van ervaring met de Kwaliteitsaanpak De software delivery manager zorgt ervoor dat bij nieuwe projecten wordt gestart met ten minste twee projectleden die bekend zijn met de Kwaliteitsaanpak.
M05: Het project hanteert een iteratief en incrementeel ontwikkelproces Projecten werken iteratief en incrementeel; dit betekent dat een project in korte iteraties werkt, waarbij elke iteratie een werkende versie van de software oplevert die extra waarde vertegenwoordigt voor de opdrachtgevende organisatie. Behalve de software werkt het project ook iedere iteratie alle andere producten bij. Elke iteratie worden verwachtingen en werkelijke resultaten vergeleken en wordt de werkwijze aangescherpt op basis van inzichten en bevindingen.
M35: Het project hanteert een agile architectuuraanpak Tijdens de voorfase verwerkt het project de door de opdrachtgevende organisatie opgestelde projectstartarchitectuur (PSA) in een eerste versie van het softwarearchitectuurdocument (SAD). Tijdens de realisatiefase werkt het project het SAD bij op basis van nieuwe inzichten.
M10: Het project kent een wekelijks projectoverleg De projectleider organiseert een periodiek projectoverleg. Dit overleg vindt wekelijks plaats en duurt niet langer dan een uur. Vereiste aanwezigen zijn de projectleider, de software delivery manager, de Scrummaster, een vertegenwoordiger uit elk van de Scrumteams en de kwaliteitsmanager van het project; andere aanwezigen kunnen zijn: de projectarchitect en de product owner. De agenda voor dit overleg bestaat ten minste uit de volgende onderwerpen: mededelingen, actie- en besluitenlijst, personele zaken, planning en voortgang, kwaliteit en architectuur, risico's en aandachtspunten.
M28: Het project voert periodiek een self-assessment uit tegen de actuele versie van de Kwaliteitsaanpak De projectleider organiseert periodiek een self-assessment tegen de actuele versie van de Kwaliteitsaanpak en zet verbeteracties uit, waar nodig.
M30: Het project identificeert, mitigeert en bewaakt risico's Het project identificeert, mitigeert en bewaakt projectspecifieke risico's voorafgaand aan en tijdens de projectuitvoering. Het project houdt een risicolog bij met geïdentificeerde risico's. De uitkomsten van de "Doordacht-van-Start-sessie", die al voorafgaand aan de start van het project wordt uitgevoerd, vormen het startpunt van deze risicolog. Risico's die tijdens de voorfase worden geïdentificeerd, bijvoorbeeld bij de productrisicoanalyse, worden toegevoegd aan de risicolog. Ook bij de start van de realisatiefase worden risicosessies gehouden met (vertegenwoordigers van) de belanghebbenden om verdere risico's te identificeren. Het project identificeert en implementeert mitigerende maatregelen danwel accepteert expliciet de geïdentificeerde risico's. Het project bewaakt de risicolog en uitvoering van de mitigerende maatregelen tijdens het IPO.
M34: Het project draagt software beheerst over Als de software op enig moment door een andere partij dan ICTU verder ontwikkeld en/of onderhouden zal worden, draagt het project zorg voor een beheerste overdracht. Beheerdocumentatie, broncode en testmiddelen zijn van dusdanige kwaliteit en compleetheid dat de andere partij de software efficiënt en effectief kan doorontwikkelen en/of onderhouden.
M27: Het project sluit projectfasen en zichzelf expliciet af Afsluiting van een projectfase gebeurt expliciet en gecontroleerd: alle producten, zoals documentatie, broncode, referentiedata en credentials, die in de af te sluiten fase nodig waren of zijn opgeleverd, worden gearchiveerd. Indien er geen volgende fase is voorzien op korte termijn, dienen alle producten van de laptops van de projectmedewerkers verwijderd te worden.
Organisatie
M29: ICTU organiseert voor aanvang van een project de interne dienstverlening Voordat ICTU een softwareontwikkelproject start, dat gaat werken conform de Kwaliteitsaanpak, maakt de beoogde ICTU-projectleider afspraken met de afdelingen ICTU Software Diensten (ISD) en ICTU Software Expertise (ISE) over de af te nemen dienstverlening.
M19: ICTU biedt projecten een afgeschermde digitale omgeving ICTU geeft de projecten de beschikking over eigen, afgeschermde digitale omgevingen, waarbinnen ze de door het project ontwikkelde software en tools kunnen installeren en waartoe op een beheerste manier toegang wordt verleend.
M18: ICTU biedt ondersteuning voor verplicht gestelde tools ICTU zorgt voor technische en functionele ondersteuning aan projecten bij het gebruik van alle verplichte tools.
M11: ICTU beheert, onderhoudt en implementeert de Kwaliteitsaanpak en kwaliteitsnormen ICTU beheert, onderhoudt en implementeert de Kwaliteitsaanpak en de kwaliteitsnormen. Aanpassingen zijn gebaseerd op praktijkervaring, nieuwe inzichten en nieuwe mogelijkheden voor meting en analyse. Iedere medewerker kan wijzigingsvoorstellen indienen bij ICTU. ICTU behandelt de wijzigingsvoorstellen, kiest de te nemen actie bij elk wijzigingsvoorstel en legt de wijzigingsvoorstellen en besluiten vast.
M12: ICTU publiceert nieuwe versies van de Kwaliteitsaanpak en normen periodiek en op een vaste locatie ICTU publiceert periodiek een nieuwe versie van de Kwaliteitsaanpak en/of de kwaliteitsnormen op een vaste, bekende locatie.
M33: ICTU organiseert periodiek een gezamenlijke self-assessment ten aanzien van de Kwaliteitsaanpak ICTU organiseert periodiek een gezamenlijke self-assessment ten aanzien van de Kwaliteitsaanpak die inzicht geeft in de huidige status van de Kwaliteitsaanpak en aanleiding kan geven tot het nemen van maatregelen om de Kwaliteitsaanpak en de ondersteuning daarvan door ICTU te verbeteren.
\ No newline at end of file
diff --git a/docs/v4.0.3/ICTU-Kwaliteitsaanpak-Wijzigingsgeschiedenis.html b/docs/v4.0.3/ICTU-Kwaliteitsaanpak-Wijzigingsgeschiedenis.html
new file mode 100644
index 00000000..7fded49d
--- /dev/null
+++ b/docs/v4.0.3/ICTU-Kwaliteitsaanpak-Wijzigingsgeschiedenis.html
@@ -0,0 +1,22 @@
+
+ICTU Kwaliteitsaanpak Softwareontwikkeling versie v4.0.3
ICTU Kwaliteitsaanpak Softwareontwikkeling
Wijzigingsgeschiedenis
Versie v4.0.3, 06-12-2024
Versie 4.0.3, 6 december 2024
Template Niet-Functionele Eisen
Gezorgd dat alle eisentabellen dezelfde kolommen hebben.
Versie 4.0.2, 26 november 2024
Alle templates
Colofon vereenvoudigd door reviewers te noemen in de revisiehistorie en niet in een aparte tabel, de vereiste goedkeuringen te vervangen door een tabel met versies die feitelijk zijn goedgekeurd, een losse tabel met betrokkenen toe te voegen en door de verzendlijsttabel te verwijderen.
Versie 4.0.1, 20 november 2024
Kwaliteitsaanpak
Een Word-versie toegevoegd, om het makkelijker te maken wijzigingsvoorstellen in te dienen.
De PDF-versie wordt niet langer gemaakt. De software (wkhtmltopdf) om de PDF te genereren wordt niet meer onderhouden. Overstappen op een andere oplossing kost te veel tijd. Indien nodig kunnen gebruikers de HTML-versie zelf naar PDF exporteren met behulp van een webbrowser.
Een inhoudsopgave toegevoegd aan de HTML-versie.
In maatregel M01 "Het project levert in elke fase vastgestelde producten en informatie op" verduidelijkt dat de aparte detailtestplannen die onder verantwoordelijkheid van het project door een derde partij worden uitgevoerd doorgaans de vorm hebben van een offerteaanvraag gemaakt door ICTU en een offerte met plan van aanpak gemaakt door de leverancier. Tevens de ontbrekende link naar het template Mastertestplan toegevoegd.
Samenvatting Kwaliteitsaanpak
De PDF-versie wordt niet langer gemaakt. De software (wkhtmltopdf) om de PDF te genereren wordt niet meer onderhouden. Overstappen op een andere oplossing kost te veel tijd. Indien nodig kunnen gebruikers de HTML-versie zelf naar PDF exporteren met behulp van een webbrowser.
Een inhoudsopgave toegevoegd aan de HTML-versie.
Wijzigingsgeschiedenis
De PDF-versie wordt niet langer gemaakt. De software (wkhtmltopdf) om de PDF te genereren wordt niet meer onderhouden. Overstappen op een andere oplossing kost te veel tijd. Indien nodig kunnen gebruikers de HTML-versie zelf naar PDF exporteren met behulp van een webbrowser.
Een inhoudsopgave toegevoegd aan de HTML-versie.
Alle documenten
"OWASP Dependency-Check" consistent gespeld.
"OWASP ZAP" hernoemd naar "ZAP by Checkmarx".
Versie 4.0.0, 26 april 2024
Kwaliteitsaanpak
Het hoofdstuk 'Begrippenkader' is verwijderd. De begrippen die hierin werden besproken staan ook in de bijlage 'Terminologie'. Het hoofdstuk 'Leeswijzer' verwijst nu naar deze bijlage.
Op relevante plekken zijn verwijzingen naar templates, self-assessment checklist en wijzigingsgeschiedenis toegevoegd.
Paragraaf 3.5 "Evolutie van de aanpak zelf" verwijderd uit hoofdstuk 3 "Leeswijzer". Deze tekst staat ook al in hoofdstuk 2 "Doelstellingen en uitgangspunten".
In M01 "Het project levert in elke fase vastgestelde producten en informatie op": Een kolom toegevoegd aan de tabel met daarin de verantwoordelijke organisatie per regel van de tabel. Hiermee is de paragraaf "Verantwoordelijkheden" overbodig en verwijderd. De opmerking in de paragraaf "Verantwoordelijkheden" over onderzoek naar her te gebruiken software verplaatst naar de paragraaf over de plannen van aanpak. De testplannen uitgesplitst naar MTP en detailtestplannen zodat deze apart kunnen worden ingevuld in de self-assessment. Onder het kopje Vrijgaveadvies, opgenomen dat het de verantwoordelijkheid van de opdrachtgevende organisatie is om te organiseren dat betrokken partijen informatie aanleveren voor het vrijgaveadvies. De informatie die de opdrachtgevende organisatie dient aan te leveren ook opgenomen in de tabel en daaronder verwezen naar M31.
De titel van maatregel M02 is veranderd van "Het project zorgt dat het product continu aan de kwaliteitsnormen voldoet" in "Het project bewaakt continu dat het product aan de kwaliteitsnormen voldoet". Continue aan alle kwaliteitsnormen voldoen is in de praktijk onmogelijk (zie ook M08 "Het project maakt technische schuld inzichtelijk en lost deze planmatig op"). Hiermee is de overlap met M06 "Het project meet kwaliteitsnormen geautomatiseerd en frequent" zo groot dat deze laatste maatregel is komen te vervallen.
In maatregel M10 "Het project kent een wekelijks projectoverleg" de bewaking van actie- en besluitenlijst en risicolog door Quality-time verwijderd, aangezien Microsoft Planner, dat de meeste projecten gebruiken, niet door Quality-time wordt ondersteund.
De naam van maatregel M14 "Het project bereidt samen met opdrachtgever en belanghebbenden de realisatie voor" veranderd in "M14: Het project bereidt samen met opdrachtgevende organisatie en betrokken partijen de realisatie voor". Daarnaast toegevoegd dat bij significante wijzigingen aan de projectkaders de voorfase geheel of deels opnieuw wordt uitgevoerd.
In maatregel M16 "Het project gebruikt tools voor vastgestelde taken" toegevoegd dat projecten de genoemde tools of gelijkwaardige alternatieven gebruiken. Verder GitLab SAST verwijderd uit de lijst van tools, Dependency-Track toegevoegd en SonarQube en OWASP ZAP over twee regels verspreid zodat ze apart kunnen worden ingevuld in de self-assessment. Daarnaast M16 verplaatst naar het hoofdstuk "Producten".
De scope van maatregel M29 "ICTU zorgt dat een project verantwoord kan starten" gereduceerd tot het organiseren van de interne dienstverlening voor aanvang van een project en de titel hieraan aangepast: "ICTU organiseert voor aanvang van een project de interne dienstverlening". Tevens een opmerking over externe dienstverlening toegevoegd.
De naam van maatregel M31 "Het project beschikt over vastgestelde informatie" veranderd in "Het project beschikt over actuele vastgestelde informatie" en de tekst van de maatregel hieraan aangepast. Een extra kopje "Afspraken tussen opdrachtgevende organisatie en beheerpartij" toegevoegd. Toegevoegd dat de opdrachtgevende organisatie na start van een project de PSA uitwerkt in een solution architectuur.
Maatregel M35 "Het project hanteert een agile architectuuraanpak" toegevoegd.
De bijlage 'Wijzigingsgeschiedenis' verplaatst naar een los document in PDF- en HTML-formaat.
Samenvatting Kwaliteitsaanpak
Een HTML-versie van de samenvatting toegevoegd aan de set van documenten zodat er een toegankelijk alternatief is voor de PDF-versie van de samenvatting.
Template Mastertestplan
Een neutraal template Mastertestplan toegevoegd aan de set van templates.
Template Niet-Functionele Eisen
Axe-core bijgewerkt naar de laatste versie in de tabel met de WCAG 2.2 succescriteria.
Template Kwaliteitsplan
Paragraaf 3.1.4 "Werkwijze" hernoemd naar "Ontwikkelproces", overeenkomstig maatregel M05 "Het project hanteert een iteratief en incrementeel ontwikkelproces".
De tekst over kwaliteitsnormen uit paragraaf 3.1.4 ondergebracht in een nieuwe paragraaf 3.1.5 "Bewaken van kwaliteitsnormen". Een alinea toegevoegd met afspraken over hoe/aan wie de kwaliteitsmanager rapporteert over het al dan niet behalen van de kwaliteitsnormen.
In paragraaf 5.3.3 "Broncodereviews", de term pull request vervangen door merge request omdat dat de terminologie is die in GitLab wordt gebruikt.
Koppeling tussen use cases, logische testgevallen, user stories en epics minder strikt gemaakt in bijlage D "Gebruik van Jira".
Template Detailtestplan
Template detailtestplan hernoemd naar Template detailtestplan softwarerealisatie om duidelijk te maken dat het alleen gericht is op softwarerealisatie en niet op andere onderwerpen waarvoor een detailtestplan zou kunnen worden gemaakt zoals infrastructuurtesten.
Template Inwerkplan Kwaliteitsmanager
Verwijzingen naar Eco1 verwijderd.
URLs naar ICTU-bronnen bijgewerkt.
Alle templates
De labels voor te vervangen teksten geuniformeerd om zoek-en-vervang te vereenvoudigen: {de opdrachtgevende organisatie} vervangen door {opdrachtgevende organisatie}, {(de) applicatie} en {(het) systeem} vervangen door {het product}, {projectnaam} door {het project}, {productnaam} door {het product}, {samenwerkende partijen} door {partijen}, {referentie} door {documentreferentie} en in de colofons aan {naam} ook de rol toegevoegd (bijvoorbeeld {naam projectleider beheerorganisatie}).
Waar relevant Dependency-Track toegevoegd aan genoemde beveiligingstools.
Waar gesproken wordt over vrijgaveadvies de tekst aangepast zodat duidelijk is dat ICTU het vrijgaveadvies niet zelf maakt, maar informatie ten behoeve van het vrijgaveadvies oplevert.
WCAG bijgewerkt naar versie 2.2.
Self-assessment checklist
Het mogelijk gemaakt bij maatregelen met submaatregelen ook de hoofdmaatregel te scoren.
Alle documenten
De term "DevOps-werkwijze" vervangen door "operationeel beheer" of door "operationeel en/of applicatiebeheer" op de plekken waar het gaat over de dienstverlening en niet zozeer over de aanpak.
De term "high level design" (HLD) vervangen door "infrastructuurarchitectuur" (IA) of waar beide termen werden gebruikt HLD verwijderd. Het HLD-template hernoemd naar IA-template.
"Beheerorganisatie" en "beheerpartij" werden door elkaar gebruikt. Alle voorkomens van beheerpartij vervangen door beheerorganisatie.
De term "opdrachtgever" vervangen door "opdrachtgevende organisatie" waar dat bedoeld werd. Opdrachtgever en opdrachtgevende organisatie toegevoegd aan de terminologie bijlagen.
De term "Testplan softwarerealisatie" vervangen door "Detailtestplan softwarerealisatie".
Versie 3.0.1, 4 april 2023
Kwaliteitsaanpak
In M01 toegevoegd dat het ICTU-kwaliteitsplan waar nodig aansluit op het overkoepelende kwaliteitsplan van de opdrachtgever.
Bij M02 ontbrak (een verwijzing naar) de self-assessment als activiteit om aan de kwaliteitsnormen te voldoen.
Bij M16 is Jira ook van toepassing bij applicatiebeheer en niet alleen bij DevOps.
De criteria uit NPR 5325 in M34 zijn niet SMART. Toegevoegd dat project en opdrachtgever de criteria voor overdracht aanscherpen.
Referenties naar 'zeepkist' als communicatiekanaal verwijderd.
De link naar de toegankelijkheidsverklaring was niet correct.
Definitie voor 'operationeel beheer' toegevoegd aan de bijlage 'Terminologie'.
Template Kwaliteitsplan
Het Jira-type "Systeemfunctie" verwijderd uit bijlage D omdat dit niet meer gebruikt wordt.
Self-assessment checklist
Een deel van de tekst van maatregel M05 was weggevallen.
Versie 3.0.0, 28 februari 2023
Kwaliteitsaanpak
HTML-versie van de Kwaliteitsaanpak toegevoegd als toegankelijk alternatief voor de PDF-versie.
Op meerdere plekken in de Kwaliteitsaanpak de gebruikte rollen aangescherpt of verbeterd door bijvoorbeeld ICTU te vervangen door project, team door Scrumteam en projectleider door software delivery manager.
Bij maatregel "Het project levert in elke fase vastgestelde producten en informatie op" (M01): software bill of materials toegevoegd als op te leveren informatie, toegevoegd dat al het werk van het Scrumteam via de product backlog loopt, deploymentdocumentatie verbreed tot documentatie voor deployment en operationeel beheer en, tenslotte, broncode en regressietest verplaatst naar de nieuwe maatregel "Het project draagt software beheerst over" (M34).
Bij maatregel "Het project levert in elke fase vastgestelde producten en informatie op" (M01): de due diligence activiteiten afgesplitst naar een nieuwe maatregel "Het project onderzoekt de kwaliteit van over te nemen software" (M32).
De maatregel "Het project implementeert nieuwe versies van de Kwaliteitsaanpak binnen de gestelde termijn" (M09) is vervallen en gecombineerd met maatregel "Het project voert periodiek een self-assessment uit ten aanzien van de Kwaliteitsaanpak" (M28).
Bij maatregel "Het project gebruikt tools voor vastgestelde taken" (M16): de lijst van verplichte tools en ondersteunde tools gelijk getrokken, de genoemde tools bijgewerkt en software bill of materials toegevoegd als taak.
Bij maatregel "Het project voert periodiek een self-assessment uit ten aanzien van de Kwaliteitsaanpak" (M28): de rol van de kwaliteitsmanager bij het uitvoeren van de self-assessment toegevoegd.
Nieuwe maatregel "ICTU organiseert periodiek een gezamenlijke self-assessment ten aanzien van de Kwaliteitsaanpak" (M33) toegevoegd.
Nieuwe maatregel "Het project draagt software beheerst over" (M34) toegevoegd.
Kruisverwijzingen tussen maatregelen verwijderd om de onderhoudbaarheid van de tekst te vergroten.
Versioneringsstrategie voor de Kwaliteitsaanpak toegegoegd aan de leeswijzer.
De term 'standup' vervangen door de officiële term 'daily scrum'.
De Scrumrollen toegevoegd aan de bijlage 'Terminologie'.
Samenvatting Kwaliteitsaanpak
Gebruik dezelfde volgorde van de maatregelen in de samenvatting als in de gehele Kwaliteitsaanpak.
Template Niet-Functionele Eisen
Paragraaf "Relaties met andere documenten" verder uitgewerkt.
In de paragraaf "Over dit document" handreiking voor het scherp formuleren van eisen toegevoegd.
Axe-core bijgewerkt naar de laatste versie in de tabel met de WCAG 2.1 succescriteria.
Template neutraal gemaakt (ICTU logo's verwijderd) omdat dit document een verantwoordelijkheid van de opdrachtgever is.
Kolommen aan eisentabellen toegevoegd om eisen toe te wijzen aan systeemonderdelen en verantwoordelijke partijen.
Template High Level Design
Template neutraal gemaakt (ICTU logo's verwijderd) omdat dit document een verantwoordelijkheid van de opdrachtgever is.
Template Kwaliteitsplan
In de beschrijving van het vrijgaveadvies "testresultaten" vervangen door toetsing van functionele en niet-functionele eisen.
Paragraaf over linters, checkers en formatters toegevoegd aan het hoofdstuk "Kwaliteitsmaatregelen realisatiefase".
Paragraaf over broncodereviews specifieker gemaakt.
De scope van de paragraaf over certificeringen uitgebreid zodat ook externe testen en toetsen eronder vallen.
Template Generiek
Een neutrale versie van het generieke template toegevoegd.
Template Compacte Voorfase
Een template toegevoegd voor het vastleggen van de uitkomsten van een compacte voorfase. Dit template is bedoeld om functionele eisen, niet-functionele eisen, ontwerp en plan van aanpak voor de realisatiefase vast te leggen bij een project waar het maken van aparte en uitgebreidere (HLD, SAD, NFE, etc.) documenten niet nodig is. Dit zijn typisch interne ICTU-projecten met beperkte omvang.
Alle templates
Beheerpartijrollen toegevoegd aan colofon.
Alle documenten
Voor toepassing van de DevOps-werkwijze zijn uitzonderingen, extra maatregelen en extra rollen toegevoegd.
Verwijzingen naar Checkmarx vervangen door verwijzingen naar SonarQube.
Versie 2.4.0, 12 januari 2022
Kwaliteitsaanpak
De titel van maatregel "Het project levert in elke fase vastgestelde informatie over het product op" (M01) veranderd in "Het project levert in elke fase vastgestelde producten en informatie op" zodat de titel beter past bij de scope van de maatregel.
Bij maatregel "Het project levert in elke fase vastgestelde producten en informatie op" (M01): de tabel uitgebreid met product backlog, en de lopende tekst aangevuld en aangepast opdat deze consistent is met de tabel.
Bij maatregel "Het project zorgt dat het product continu aan de kwaliteitsnormen voldoet" (M02): "Ook zorgt het project dat de performance van de software regelmatig wordt getest." toegevoegd.
Template Kwaliteitsplan
Bijlage met periodieke (kwaliteits)controles toegevoegd.
Beschrijvingen van release notes en performancetest toegevoegd.
Template Niet-Functionele Eisen
Axe-core bijgewerkt naar versie 4.3 in de tabel met de WCAG 2.1 succescriteria.
Template Plan van Aanpak Realisatiefase
UX: aanpassing producten uit de voorfase; verantwoordelijkheden van rol UX-designer aangevuld.
Toelichting op te maken afspraken voor: release notes, vrijgaveadvies, beveiligingstest, performancetest.
In hoofdstuk Verwachte inzet ICTU een tabel toegevoegd met te verwachten kosten voor door ICTU te benutten diensten.
Definities toegevoegd: release notes en vrijgaveadvies.
Self-assessment checklist
Invulinstructie uitgebreid.
Duidelijk gemaakt dat als maatregelen submaatregelen hebben alleen de status van submaatregelen hoeft te worden ingevuld.
Inwerkplan Kwaliteitsmanager
Inwerkplan voor de rol van kwaliteitsmanager toegevoegd.
Versie 2.3.0, 14 mei 2021
Kwaliteitsaanpak
Verwijzingen naar BIRT en de Releasemanager verwijderd uit de maatregel "Het project gebruikt tools voor vastgestelde taken" (M16) omdat deze tools niet meer ondersteund worden.
Manifest verwijderd omdat de inhoud grotendeels terugkomt op andere plekken in de Kwaliteitsaanpak.
Samenvatting Kwaliteitsaanpak
Een samenvatting van de Kwaliteitsaanpak als los document toegevoegd.
Presentatie Kwaliteitsaanpak
Een presentatie van de Kwaliteitsaanpak als los document toegevoegd.
Alle templates
Lijst van reviewers toegevoegd aan colofon.
Leeswijzer uitgebreid met een beschrijving van de (standaard) bijlagen van de templates.
Hoofdstuk "Managementsamenvatting" toegevoegd.
Template Detailtestplan
Verwijzingen naar BIRT en de Releasemanager verwijderd.
Template Globaal Functioneel Ontwerp
Template aangepast naar het gebruik van use cases om de functionaliteit te beschrijven.
Kaders die niet relevant waren voor een GFO verwijderd.
Template Niet-Functionele Eisen
Tabel met de WCAG 2.1 succescriteria toegevoegd. Per succescriterium geeft de tabel aan of Axe-core, en zo ja met welke regels, het succescriterium geautomatiseerd kan controleren.
Template Kwaliteitsplan
Het kwaliteitsplantemplate sprak van een verantwoordingsparagraaf in alle documenten, maar deze paragraaf zat niet in de andere templates. Deze verantwoordingsparagrafen waren bedoeld om de eisen traceerbaar te maken. Omdat niet alle projecten dit nodig hebben, en er andere manieren in gebruik zijn om eisen traceerbaar te maken (bijvoorbeeld een losse administratie in Confluence) is de tekst over verantwoordingsparagrafen vervangen door een optionele paragraaf over tracering van eisen die nader kan worden ingevuld.
Uit de bijlage "Gebruik van Jira" is de paragraaf "Velden in Jira" verwijderd omdat deze out-of-date en incompleet was en bovendien niet ging over velden in Jira, maar over metrieken die met behulp van de informatie in Jira gemeten kunnen worden. In plaats van deze paragraaf verwijst het kwaliteitsplantemplate naar de lijst op GitHub van metrieken die Quality-time kan meten.
Uit de bijlage "Gebruik van Jira" is het issue type "Sprint bug" verwijderd omdat bugs die tijdens sprints worden gevonden normaal gesproken niet worden vastgelegd in Jira.
Uit de bijlage "Gebruik van Jira" is het issue type "Custom issue" verwijderd omdat custom issues optioneel zijn en in de praktijk te weinig worden toegepast om apart te beschrijven.
Het hoofdstuk "Kwaliteitsmaatregelen projectafsluiting" bevatte een lijst van activiteiten voor de software delivery manager. Die activiteiten zijn verplaatst naar het template plan van aanpak realisatiefase. De kwaliteitsmaatregelen bij projectafsluiting zijn beperkt tot een controle door de kwaliteitsmanager van de uitvoering van die activiteiten.
Template Plan van Aanpak Voorfase
Paragraaf over projectafsluiting toegevoegd.
Template Plan van Aanpak Realisatiefase
Paragraaf over projectafsluiting en bijlage met activiteiten voor projectafsluiting toegevoegd.
Alle documenten
Vervang 'privacy impact analyse' door 'privacy impact assessment' en 'business impact analyse' door 'business impact analysis' zodat beide termen consequent op dezelfde manier geschreven worden.
Versie 2.2.0, 27 januari 2021
Kwaliteitsaanpak
Afdeling ICTU Software Realisatie vervangen door de afdelingen ICTU Software Diensten en/of ICTU Software Expertise.
ICTU ondersteunt alleen nog Quality-time als kwaliteitssysteem; HQ verwijderd.
Leeswijzer uitgebreid met uitleg over beschrijvend en voorschrijvend karakter van de Kwaliteitsaanpak.
Nieuwe maatregel "Het project beschikt over vastgestelde informatie" (M31) toegevoegd die beschrijft welke informatie de opdrachtgever aan een project beschikbaar stelt.
Bij maatregel "Het project levert in elke fase vastgestelde informatie over het product op" (M01) met een plaatje de relaties tussen de voorfase producten toegelicht.
De maatregel "Het project is gesplitst in een voorfase en een realisatiefase" (M14) hernoemd naar "Het project bereidt samen met opdrachtgever en belanghebbenden de realisatie voor".
De maatregel "ICTU geeft de voorkeur aan open source tools" (M15) is verwijderd. De inhoud van M15 is verplaatst naar "ICTU biedt ondersteuning voor verplicht gestelde tools" (M18). Reden is dat de voorkeur voor open source geen apart uitvoerbare maatregel is, maar deel uitmaakt van de ondersteuning van projecten met tools.
Bij maatregel "Het project gebruikt tools voor vastgestelde taken" (M16) performancetesttools toegevoegd.
Maatregel "ICTU zorgt dat een aantal vastgestelde tools snel beschikbaar is voor een project" (M17) verwijderd omdat projecten deze tools ofwel via de kantoorautomatisering van ICTU kunnen gebruiken of zelf kunnen draaien in de afgeschermde digitale omgeving zoals beschreven bij M19.
Bij maatregel "Het project laat de beveiliging van het ontwikkelde product periodiek beoordelen" (M26) beter toegelicht onder welke voorwaarden de beveiligingstesten alleen door de opdrachtgever kunnen worden uitgevoerd.
Bijlage "Risico's van softwareontwikkeling" verwijderd vanwege de overlap met de bijlage "Relatie met NEN NPR 5326".
Template Projectvoorstel Voorfase
Template veranderd in een template voor een plan van aanpak voor de voorfase. Gebruik voor projectvoorstellen het ICTU-brede template.
Template Projectvoorstel Realisatiefase
Template veranderd in een template voor een plan van aanpak voor de realisatiefase. Gebruik voor projectvoorstellen het ICTU-brede template.
Template Kwaliteitsplan
Toegevoegd bij projectafsluiting dat VPN-keys, LDAP-accounts, Jira-accounts en werkstations moeten worden opgeschoond.
Bij projectafsluiting de verantwoordelijke rol aangepast naar software delivery manager, conform Maatregel 27 in de Kwaliteitsaanpak.
Het hanteren van codeerstandaarden toegevoegd aan de kwaliteitsmaatregelen tijdens de realisatiefase.
Versie 2.1.0, 2 september 2020
Kwaliteitsaanpak
M30 ontbrak in de bijlage met het overzicht van alle maatregelen.
Link naar Kwaliteitsaanpak op ICTU-website toegevoegd.
Rubriceringsniveau, rubriceringsduur en totaal aantal bladzijden conform VIRBI 2013, bijlage 1, eis 6J toegevoegd.
Link naar Kwaliteitsaanpak op ICTU-website toegevoegd in de bijlage over de Kwaliteitsaanpak.
Template Projectvoorstel Realisatiefase
Projectvoorstel Realisatiefase template toegevoegd dat als basis kan dienen voor een projectvoorstel voor het uitvoeren van een realisatiefase aansluitend aan een voorfase.
Generiek template
Generiek template toegevoegd dat als basis kan dienen voor documenten waarvoor nog geen specifiek template is.
Template Kwaliteitsplan
Paragrafen 1.2, 1.5 en 1.6 uitgebreid met standaard teksten.
Stakeholder management vervangen door het bescheidener identificeren van belanghebbenden en belangen.
Template Niet-Functionele Eisen
Link naar Nederlandse vertaling van WCAG 2.1 toegevoegd aan het NFE-template.
Versie 2.0.0, 29 april 2020
Naam van de Kwaliteitsaanpak veranderd van "Kwaliteitsaanpak ICTU Software Realisatie" naar "ICTU Kwaliteitsaanpak Softwareontwikkeling". Waar relevant "softwarerealisatie" veranderd in "softwareontwikkeling".
Maatregelen, waar mogelijk, compacter geformuleerd.
Maatregelen herverdeeld over de drie maatregelhoofdstukken.
De maatregel "Het project levert in elke fase vastgestelde informatie over het product op" (M01) beknopter geformuleerd en toelichting op documenten uitgebreid.
Bij de maatregelen "Het project zorgt dat het product continue aan de kwaliteitsnormen voldoet" (M02), "Het project maakt technische schuld inzichtelijk en lost deze planmatig op" (M08) en "Het project gebruikt tools voor vastgestelde taken" (M16) naast HQ ook Quality-time vermeld.
Bij de maatregel "Het project maakt technische schuld inzichtelijk en lost deze planmatig op" (M08) toegevoegd dat projecten regelmatig en voldoende tijd besteden aan het voorkomen en oplossen van technische schuld.
Bij de maatregel "Het project gebruikt tools voor vastgestelde taken" (M16) versiebeheer toegevoegd, met als concrete tools GitLab en Azure DevOps.
Explicieter aandacht besteed aan gebruikskwaliteit in de maatregelen "Het project levert in elke fase vastgestelde informatie over het product op" (M01) en "Het project zorgt dat het product continue aan de kwaliteitsnormen voldoet" (M02). ISO 9241-210 opgenomen als standaard die ICTU hanteert voor gebruikskwaliteit.
De maatregel "Betrokkenheid bij inzet" (M22) verwijderd.
De maatregel "Implementatie van wijzigingen aan de kwaliteitsaanpak en -normen" (M24) verwijderd.
Nieuwe maatregel toegevoegd voor het starten van projecten: "ICTU zorgt dat een project verantwoord kan starten" (M29).
Nieuwe maatregel toegevoegd voor risicomanagement: "Projecten identificeren, mitigeren en bewaken risico's" (M30).
Termen aangepast: 'projectverantwoordelijke' is vervangen door 'projectleider', 'projectenorganisatie' en 'projectorganisatie' door 'ICTU' en 'realiserend team' door 'projectteam'.
De beschrijving van de rollen van software delivery manager en kwaliteitsmanager aangescherpt.
Waar relevant bij de rationale van maatregelen verwezen naar overeenkomende risicobeheersmaatregelen uit de NPR 5326.
Referenties aan de Baseline Informatiebeveiliging Rijksdienst (BIR) omgezet naar de Baseline Informatiebeveiliging Overheid (BIO).
Referenties aan tools geactualiseerd.
Tekstuele en stilistische verbeteringen.
Actielijst toegevoegd aan self-assessment spreadsheet.
Generatie van documenttemplates is onderdeel van de Kwaliteitsaanpak.
Versie 1.3.1, 1 mei 2019
M14: Maatregeltitel ingekort zodat paginanummers in de inhoudsopgave niet overlappen.
Versie 1.3, 5 april 2019
Overbodig kopje in de wijzigingsgeschiedenis van de generieke versie verwijderd.
Bijlage met afkortingen toegevoegd.
M07: Toegankelijkheidstests toegevoegd.
M10: Aanwezigen bij periodiek projectoverleg aangepast.
M16: Een tool voor het testen van toegankelijkheid toegevoegd.
M01: Wbni, EN 301 549 en WCAG 2.1 als bron voor niet-functionele eisen toegevoegd. Toegankelijkheidsverklaring als mogelijke deliverable genoemd.
M05: Iteratief en incrementeel ontwikkelproces: Sprint retrospective en sprint backlog toegevoegd.
M16: Axe toegevoegd.
WCAG 2.1 toegevoegd aan bijlage C: Documenten voor M01.
Versie 1.2, 1 augustus 2018
M01: Op te leveren producten: Niet alle producten hoeven door het project te worden gemaakt.
M02: Continu voldoen aan kwaliteitsnormen: Zo snel mogelijk voldoen aan kwaliteitsnormen in plaats van altijd.
M13: Gebruik van NEN-ISO/IEC 25010: Verduidelijkt dat het om het toepassen van NEN-ISO/IEC 25010 in projecten gaat en verplaatsen naar hoofdstuk Producten.
M19: Afgeschermde digitale omgeving: De titel van de maatregel verduidelijkt naar "afgeschermde digitale omgeving".
M25: De inhoud is verplaatst naar M01: Op te leveren producten, M25 zelf is vervallen.
M28: Self-assessment: Maatregel met betrekking tot self-assessment toegevoegd.
Tekstuele en stilistische verbeteringen.
Manifest toegevoegd.
ICTU-specifieke invulling van maatregelen aangepast aan nieuwe organisatiestructuur en rollen zoals die in 2018 gelden.
In M16: Verplichte tools, de verwijzing naar ICTU-specifieke SonarQube kwaliteitsprofielen verwijderd omdat ICTU de standaard Sonar Way kwaliteitsprofielen gebruikt.