From 8c9977ec9f09510d7e66515e47a93fb3b49dc758 Mon Sep 17 00:00:00 2001 From: Frank Niessink Date: Tue, 30 Jan 2024 13:37:01 +0100 Subject: [PATCH] De term "opdrachtgever" vervangen door "opdrachtgevende organisatie" waar dat bedoeld werd. Opdrachtgever en opdrachtgevende organisatie toegevoegd aan de terminologie bijlagen. 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". Closes #717. --- Content/Bijlagen/Terminologie.md | 4 +- Content/Doelstellingen-tekst.md | 6 +- Content/Inleiding-tekst.md | 2 +- Content/Leeswijzer.md | 2 +- Content/Maatregelen/M01/Maatregel.md | 22 +++---- Content/Maatregelen/M02/Maatregel.md | 2 +- Content/Maatregelen/M05/Definitie.md | 2 +- Content/Maatregelen/M05/Maatregel.md | 2 +- Content/Maatregelen/M07/Maatregel.md | 4 +- Content/Maatregelen/M08/Maatregel.md | 2 +- Content/Maatregelen/M14/Definitie.md | 2 +- Content/Maatregelen/M14/Maatregel.md | 6 +- Content/Maatregelen/M26/Maatregel.md | 2 +- Content/Maatregelen/M28/Maatregel.md | 2 +- Content/Maatregelen/M29/Maatregel.md | 2 +- Content/Maatregelen/M31/Definitie.md | 2 +- Content/Maatregelen/M31/Maatregel.md | 18 +++--- Content/Maatregelen/M32/Maatregel.md | 4 +- Content/Maatregelen/M34/Maatregel.md | 4 +- Content/Maatregelen/M35/Definitie.md | 2 +- Content/Maatregelen/M35/Maatregel.md | 4 +- Content/Templates/Colofon.md | 36 +++++------ .../Templates/Compacte-Voorfase/Doelgroep.md | 2 +- .../Detailtestplan/Template-Inhoud.md | 6 +- .../Detailtestplan/Uitgangspunten.md | 2 +- Content/Templates/GFO/Over-dit-document.md | 4 +- Content/Templates/GFO/Template-Inhoud.md | 4 +- .../Template-Inhoud.md | 8 +-- .../Kwaliteitsplan/Managementsamenvatting.md | 4 +- .../Kwaliteitsplan/Over-dit-document.md | 2 +- .../Kwaliteitsplan/Template-Inhoud.md | 16 ++--- Content/Templates/NFE/Template-Inhoud.md | 2 +- .../PvA-Realisatiefase/Over-dit-document.md | 2 +- .../PvA-Realisatiefase/Template-Inhoud.md | 62 +++++++++---------- .../PvA-Realisatiefase/Uitgangspunten.md | 12 ++-- .../PvA-Voorfase/Over-dit-document.md | 2 +- .../Templates/PvA-Voorfase/Template-Inhoud.md | 58 ++++++++--------- .../Templates/PvA-Voorfase/Uitgangspunten.md | 6 +- Content/Templates/SAD/Template-Inhoud.md | 2 +- Content/Wijzigingsgeschiedenis.md | 7 ++- DocumentDefinitions/Shared/variables.json | 2 +- 41 files changed, 169 insertions(+), 166 deletions(-) diff --git a/Content/Bijlagen/Terminologie.md b/Content/Bijlagen/Terminologie.md index 2b6ad158..3e904b42 100644 --- a/Content/Bijlagen/Terminologie.md +++ b/Content/Bijlagen/Terminologie.md @@ -39,6 +39,8 @@ De onderstaande tabel bevat afkortingen en termen die voorkomen in de $KWALITEIT | **NORA** | Nederlandse Overheidsreferentie-architectuur | | **NPR** | Nederlandse Praktijkrichtlijn | | **ontwikkelaars** | Ontwikkelaars (*developers* in de Scrumgids) zijn de mensen in het **Scrumteam** die iedere sprint gecommitteerd zijn aan het maken van elk aspect van een bruikbaar increment [Scrumgids] | +| **opdrachtgevende organisatie** | overheidsorganisatie die opdracht geeft aan ICTU tot ontwikkeling en/of onderhoud van **software** | +| **opdrachtgever** | medewerker van de **opdrachtgevende organisatie** die eindverantwoordelijk is voor de opdracht aan ICTU | | **operationeel beheer** | activiteiten die zorgen dat software operationeel is en blijft, zoals het oplossen van incidenten, het uitvoeren van onderhoud, het implementeren van upgrades en patches, het beheren van configuraties, en het monitoren van prestaties en beschikbaarheid | | **OTAP** | ontwikkel, test, acceptatie, productie; gebruikt om verschillende soorten omgevingen aan te duiden | | **persona** | een min of meer realistische beschrijving van een fictief persoon, veelal met naam, persoonskenmerken, drijfveren en behoeften, die een groep gebruikers representeert en gebruikt wordt om te redeneren over de gewenste functionele en niet-functionele eigenschappen van de **software** | @@ -47,7 +49,7 @@ De onderstaande tabel bevat afkortingen en termen die voorkomen in de $KWALITEIT | **PRA** | productrisicoanalyse | | **Product owner** | De product owner is verantwoordelijk voor het maximaliseren van de waarde van het product, dat het resultaat is van het werk van het **Scrumteam** [Scrumgids] | | **programmatuur** | zie **software** | -| **project** | een tijdelijke organisatie voor het realiseren van een resultaat - bij ICTU bestaat een **softwareontwikkelproject** uit medewerkers van ICTU, opdrachtgever, beheerorganisatie en eventueel andere partijen | +| **project** | een tijdelijke organisatie voor het realiseren van een resultaat - bij ICTU bestaat een **softwareontwikkelproject** uit medewerkers van ICTU, de **opdrachtgevende organisatie**, beheerorganisatie en eventueel andere partijen | | **projectleider** | medewerker eindverantwoordelijk voor het projectresultaat - bij ICTU-softwareontwikkelprojecten is de projectleider een medewerker van ICTU | **PSA** | De projectstartarchitectuur is een concreet en doelgericht ICT-architectuurkader waarbinnen het **project** moet worden uitgevoerd | | **PvE** | programma van eisen | diff --git a/Content/Doelstellingen-tekst.md b/Content/Doelstellingen-tekst.md index 8dc8b70a..6ca4e0e7 100644 --- a/Content/Doelstellingen-tekst.md +++ b/Content/Doelstellingen-tekst.md @@ -1,15 +1,15 @@ De $KWALITEITSAANPAK$ heeft drie doelstellingen: -1. Opdrachtgevers helpen bekende risico's bij softwareontwikkeling, zoals technische schuld, vertraging en defecten, zo veel mogelijk te voorkomen. +1. Opdrachtgevende organisaties helpen bekende risico's bij softwareontwikkeling, zoals technische schuld, vertraging en defecten, zo veel mogelijk te voorkomen. 2. ICTU helpen om software te ontwikkelen die de missie van ICTU, namelijk bijdragen aan een betere digitale overheid, ondersteunt. 3. 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 opdrachtgevers 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]($BASE_URL$/$VERSIE$/ICTU-Kwaliteitsaanpak-Wijzigingsgeschiedenis.pdf) of [HTML-formaat]($BASE_URL$/$VERSIE$/ICTU-Kwaliteitsaanpak-Wijzigingsgeschiedenis.html). +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]($BASE_URL$/$VERSIE$/ICTU-Kwaliteitsaanpak-Wijzigingsgeschiedenis.pdf) of [HTML-formaat]($BASE_URL$/$VERSIE$/ICTU-Kwaliteitsaanpak-Wijzigingsgeschiedenis.html). -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$](#m26)). Een alternatief is dat de opdrachtgever de verantwoordelijkheid neemt voor het laten uitvoeren van beveiligingstests. Hierover maakt de projectleider nadere afspraken met de opdrachtgever. +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$](#m26)). 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. diff --git a/Content/Inleiding-tekst.md b/Content/Inleiding-tekst.md index ec8fa361..81465f54 100644 --- a/Content/Inleiding-tekst.md +++ b/Content/Inleiding-tekst.md @@ -4,7 +4,7 @@ Overheidsprojecten waarin software wordt ontwikkeld of onderhouden kampen nog va 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 “$KWALITEITSAANPAK$”, 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 opdrachtgevers 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. +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. diff --git a/Content/Leeswijzer.md b/Content/Leeswijzer.md index a0e0e2fc..b1e623c1 100644 --- a/Content/Leeswijzer.md +++ b/Content/Leeswijzer.md @@ -22,7 +22,7 @@ De beschrijving van elke maatregel is voorzien van een rationale: waarom behoort Bij de omschrijving van de maatregelen is gebruik gemaakt van de volgende rollen om aan te geven wie verantwoordelijkheid draagt voor het uitvoeren van de maatregelen: -* Project: de tijdelijke organisatie die de software ontwikkelt, onderhoudt en/of operationeel beheert. Het project bestaat uit medewerkers van ICTU, van de opdrachtgever en mogelijk ook van de beheerorganisatie of andere partijen. De softwareontwikkeling binnen het project gebeurt door één of meer Scrumteams, bestaande uit een product owner, ontwikkelaars en een Scrummaster. De product owner is altijd een medewerker van de opdrachtgevende organisatie. Als het project de software ook operationeel beheert past ICTU DevOps toe en maken ook DevOps-engineers deel uit van een Scrumteam. Eén van de ontwikkelaars heeft de rol van softwarearchitect. +* Project: de tijdelijke organisatie die de software ontwikkelt, onderhoudt en/of operationeel beheert. Het project bestaat uit medewerkers van ICTU, van de opdrachtgevende organisatie en mogelijk ook van de beheerorganisatie of andere partijen. De softwareontwikkeling binnen het project gebeurt door één of meer Scrumteams, bestaande uit een product owner, ontwikkelaars en een Scrummaster. De product owner is altijd een medewerker van de opdrachtgevende organisatie. Als het project de software ook operationeel beheert past ICTU DevOps toe en maken ook DevOps-engineers deel uit van een Scrumteam. Eén van de ontwikkelaars heeft de rol van softwarearchitect. * Projectleider: de ICTU-medewerker verantwoordelijk voor uitvoering van het project, * Software delivery manager: organiseert het ontwikkelen en opleveren van software conform de vastgestelde eisen en de Kwaliteitsaanpak, rapporteert aan de projectleider, * Kwaliteitsmanager: controleert en borgt de kwaliteit van software conform de vastgestelde eisen en de Kwaliteitsaanpak, rapporteert aan de projectleider. Voor de rol van kwaliteitsmanager is een [inwerkplan template]($BASE_URL$/$VERSIE$/ICTU-Template-Inwerkplan-Kwaliteitsmanager.docx) beschikbaar. diff --git a/Content/Maatregelen/M01/Maatregel.md b/Content/Maatregelen/M01/Maatregel.md index 452cb3e7..3f87c106 100644 --- a/Content/Maatregelen/M01/Maatregel.md +++ b/Content/Maatregelen/M01/Maatregel.md @@ -2,7 +2,7 @@ #include "Content/Maatregelen/M01/Definitie.md" -Opdrachtgever, ICTU, beheerorganisatie en andere meewerkende partijen leveren de onderstaande informatie op. Voor een aantal documenten zijn als onderdeel van de Kwaliteitsaanpak templates beschikbaar. Ook kan gebruik worden gemaakt van bestaande templates uit bijvoorbeeld de NORA. Zie [$M29$](#m29). +Opdrachtgevende organisatie, ICTU, beheerorganisatie en andere meewerkende partijen leveren de onderstaande informatie op. Voor een aantal documenten zijn als onderdeel van de Kwaliteitsaanpak templates beschikbaar. Ook kan gebruik worden gemaakt van bestaande templates uit bijvoorbeeld de NORA. Zie [$M29$](#m29). De onderstaande tabel bevat de in deze paragraaf beschreven producten. Het ✔ geeft aan in welke fase ze worden opgeleverd. @@ -29,7 +29,7 @@ De onderstaande tabel bevat de in deze paragraaf beschreven producten. Het ✔ g Het plan van aanpak voor de voorfase en het plan van aanpak voor de realisatiefase beschrijven de in deze fasen te realiseren producten en diensten, en de planning, werkwijze en verantwoordelijkheden voor de totstandkoming van die producten en diensten. -Als operationeel en/of applicatiebeheer onderdeel is van de te leveren dienstverlening tijdens de realisatiefase bevat het plan van aanpak voor de realisatiefase de hiervoor noodzakelijke afspraken met de opdrachtgever en de beheerorganisatie. De afspraken omvatten zowel de te behalen kwaliteitsniveaus van de dienstverlening als de uit te voeren operationele en applicatiebeheertaken. Daarnaast beschrijft het plan hoe informatie zal worden verzameld over de software tijdens het gebruik en over de uitgevoerde beheeractiviteiten. En hoe hierover zal worden gerapporteerd. Ook worden de criteria voor het beëindigen van de dienstverlening vastgelegd. De te leveren dienstverlening is afgestemd op het beheerplan van de beheerorganisatie. +Als operationeel en/of applicatiebeheer onderdeel is van de te leveren dienstverlening tijdens de realisatiefase bevat het plan van aanpak voor de realisatiefase de hiervoor noodzakelijke afspraken met de opdrachtgevende organisatie en de beheerorganisatie. De afspraken omvatten zowel de te behalen kwaliteitsniveaus van de dienstverlening als de uit te voeren operationele en applicatiebeheertaken. Daarnaast beschrijft het plan hoe informatie zal worden verzameld over de software tijdens het gebruik en over de uitgevoerde beheeractiviteiten. En hoe hierover zal worden gerapporteerd. Ook worden de criteria voor het beëindigen van de dienstverlening vastgelegd. De te leveren dienstverlening is afgestemd op het beheerplan van de beheerorganisatie. Beschikbare templates: @@ -40,7 +40,7 @@ Beschikbare templates: De beschrijving van functionele eisen bestaat uit epics en/of user stories, eventueel aangevuld met use cases. De beschrijving bevat tevens eisen voor ondersteuning van beheerfuncties, die door de beoogd beheerder gesteld worden, en voor logging, inclusief de globale inhoud van te loggen business events (gebeurtenissen op procesniveau) en de daarvoor geldende bewaartermijnen. -Bronnen van de opdrachtgever zoals de projectstartarchitectuur, een programma van eisen en procesbeschrijvingen vormen het startpunt voor de functionele eisen. Tijdens het project worden use cases in samenwerking met de product owner vertaald naar epics en user stories. +Bronnen van de opdrachtgevende organisatie zoals de projectstartarchitectuur, een programma van eisen en procesbeschrijvingen vormen het startpunt voor de functionele eisen. Tijdens het project worden use cases in samenwerking met de product owner vertaald naar epics en user stories. ### Beschrijving van niet-functionele eisen @@ -58,7 +58,7 @@ De beschrijving van niet-functionele eisen moet expliciet aandacht besteden aan Overheidsorganisaties moeten een [toegankelijkheidsverklaring](https://www.digitoegankelijk.nl/wetgeving/toegankelijkheidsverklaring) op hun websites plaatsen. Indien gewenst ondersteunt ICTU bij het opstellen van de toegankelijkheidsverklaring. -Bronnen van de opdrachtgever zoals procesbeschrijvingen, privacy impact assessment (PIA), beheeracceptatiecriteria, beveiligingsbeleid en projectstartarchitectuur vormen het startpunt voor de niet-functionele eisen. +Bronnen van de opdrachtgevende organisatie zoals procesbeschrijvingen, privacy impact assessment (PIA), beheeracceptatiecriteria, beveiligingsbeleid en projectstartarchitectuur vormen het startpunt voor de niet-functionele eisen. Beschikbare templates: @@ -98,7 +98,7 @@ Beschikbare templates: De testplannen bestaan uit een mastertestplan (MTP), gemaakt op basis van een productrisicoanalyse (PRA), en detailtestplannen. Het doel van een mastertestplan is om betrokkenen bij het testproces te informeren over de strategie, aanpak, activiteiten, inclusief de onderlinge relaties en afhankelijkheden, en de op te leveren producten met betrekking tot het testtraject. Het mastertestplan beschrijft deze strategie, aanpak, activiteiten en eindproducten, die in de detailtestplannen verder worden gedetailleerd. -Opdrachtgever is verantwoordelijk voor het mastertestplan. Het project maakt een detailtestplan voor de testsoorten die tijdens de realisatiefase door het project worden uitgevoerd. Voor testen die onder verantwoordelijkheid van het project door een derde partij worden uitgevoerd, denk aan penetratietesten en evaluaties van gebruikskwaliteit, worden aparte detailtestplannen gemaakt. +De opdrachtgevende organisatie is verantwoordelijk voor het mastertestplan. Het project maakt een detailtestplan voor de testsoorten die tijdens de realisatiefase door het project worden uitgevoerd. Voor testen die onder verantwoordelijkheid van het project door een derde partij worden uitgevoerd, denk aan penetratietesten en evaluaties van gebruikskwaliteit, worden aparte detailtestplannen gemaakt. Logische testgevallen worden vastgelegd en gekoppeld met use cases en user stories. Fysieke testgevallen worden vastgelegd in het formaat van de gebruikte tooling en gekoppeld met de logische testgevallen. Op basis hiervan worden testrapportages gegenereerd die laten zien dat alle use cases en user stories zijn getest en dat die tests zijn geslaagd. @@ -116,11 +116,11 @@ Bij ICTU wordt daarvoor een TVA gebruikt. Hierin worden de betrouwbaarheidseisen ### Kwaliteitsplan -Het ICTU-kwaliteitsplan beschrijft de standaard kwaliteitsmaatregelen die ICTU-projecten treffen om software te realiseren die voldoet aan de kwaliteitseisen van de opdrachtgever en andere belanghebbenden en aan de kwaliteitsnormen van ICTU. +Het ICTU-kwaliteitsplan beschrijft de standaard kwaliteitsmaatregelen die ICTU-projecten treffen om software te realiseren die voldoet aan de kwaliteitseisen van de opdrachtgevende organisatie en andere belanghebbenden en aan de kwaliteitsnormen van ICTU. Als er bijzondere of hoge niet-functionele eisen zijn, beschrijft het ICTU-kwaliteitsplan ook de extra projectspecifieke kwaliteitsmaatregelen die het project treft om deze eisen te realiseren. -Als de opdrachtgever een overkoepelend kwaliteitsplan heeft zorgt het project dat het ICTU-kwaliteitsplan aansluit op het overkoepelende kwaliteitsplan. +Als de opdrachtgevende organisatie een overkoepelend kwaliteitsplan heeft zorgt het project dat het ICTU-kwaliteitsplan aansluit op het overkoepelende kwaliteitsplan. Beschikbare templates: @@ -138,7 +138,7 @@ De documentatie voor operationeel beheer bevat tenminste informatie over: back-u ### Software bill of materials -Voor elke release stelt het project een "software bill of materials" op: een overzicht van de gebruikte libraries, frameworks, componenten en andere software(deel)producten in de release. Software draagt inherent het risico in zich van verborgen fouten. Deze fouten kunnen mogelijk misbruikt worden, waardoor (beveiligings)problemen ontstaan. Met dit overzicht heeft de opdrachtgever of diens beheerorganisatie informatie over de gebruikte software(deel)producten, die geraadpleegd kan worden wanneer fouten in software bekend wordt, zodat een risico-inschatting gemaakt kan worden en eventueel actie kan worden ondernomen. +Voor elke release stelt het project een "software bill of materials" op: een overzicht van de gebruikte libraries, frameworks, componenten en andere software(deel)producten in de release. Software draagt inherent het risico in zich van verborgen fouten. Deze fouten kunnen mogelijk misbruikt worden, waardoor (beveiligings)problemen ontstaan. Met dit overzicht heeft de opdrachtgevende organisatie of diens beheerorganisatie informatie over de gebruikte software(deel)producten, die geraadpleegd kan worden wanneer fouten in software bekend wordt, zodat een risico-inschatting gemaakt kan worden en eventueel actie kan worden ondernomen. ### Release notes @@ -146,9 +146,9 @@ Voor elke release stelt het project release notes op: een overzicht van de wijzi ### Vrijgaveadvies -De opdrachtgever organiseert dat voor elke release de betrokken partijen informatie aanleveren voor een vrijgaveadvies. +De opdrachtgevende organisatie organiseert dat voor elke release de betrokken partijen informatie aanleveren voor een vrijgaveadvies. -Het project levert bij elke release informatie aan de opdrachtgever over nog openstaande testbevindingen en geconstateerde beveiligingsbevindingen; zie ook [$M26$](#m26) en [$M16$](#m16). Als er issues zijn, bijvoorbeeld rondom kwaliteit of beveiliging, zijn deze voorzien van een beschrijving van de voorziene impact. +Het project levert bij elke release informatie aan de opdrachtgevende organisatie over nog openstaande testbevindingen en geconstateerde beveiligingsbevindingen; zie ook [$M26$](#m26) en [$M16$](#m16). Als er issues zijn, bijvoorbeeld rondom kwaliteit of beveiliging, zijn deze voorzien van een beschrijving van de voorziene impact. ### Samenhang voorfaseproducten @@ -158,7 +158,7 @@ Bovenstaande figuur laat de belangrijkste relaties zien tussen de verschillende ### Verantwoordelijkheden -De opdrachtgever is primair verantwoordelijk voor het beschrijven van de functionele en niet-functionele eisen, de geprioriteerde backlog, het mastertestplan en het informatiebeveiligingsplan. +De opdrachtgevende organisatie is primair verantwoordelijk voor het beschrijven van de functionele en niet-functionele eisen, de geprioriteerde backlog, het mastertestplan en het informatiebeveiligingsplan. ICTU is primair verantwoordelijk voor plan van aanpak, softwarearchitectuurdocumentatie, globaal functioneel ontwerp, prototype, detailtestplannen en testrapportages voor bouwtesten, kwaliteitsplan, deploybare versie van de software, documentatie voor deployment en operationeel beheer, release notes en vrijgaveadvies. diff --git a/Content/Maatregelen/M02/Maatregel.md b/Content/Maatregelen/M02/Maatregel.md index 6b4e1ab2..d7c41357 100644 --- a/Content/Maatregelen/M02/Maatregel.md +++ b/Content/Maatregelen/M02/Maatregel.md @@ -31,7 +31,7 @@ Als operationeel beheer onderdeel is van de dienstverlening tijdens de realisati ### Realisatiefase: handmatige evaluatie -Kwaliteitseigenschappen van de software die niet (volledig) geautomatiseerd kunnen worden gemeten, worden tijdens de realisatiefase periodiek handmatig geëvalueerd. Minimaal betreft dit de beveiliging van de software, zie [$M26$](#m26). Ook zorgt het project dat de performance van de software regelmatig wordt getest. Voor kwaliteitsaspecten als toegankelijkheid en gebruikskwaliteit organiseert het project handmatige testen en/of evaluaties in een vorm en met een frequentie die aansluit bij de aard van de applicatie en de door de opdrachtgever gestelde eisen. De kwaliteitsmanager houdt in Quality-time bij wanneer de laatste test of evaluatie is uitgevoerd en wanneer het tijd is voor de volgende. +Kwaliteitseigenschappen van de software die niet (volledig) geautomatiseerd kunnen worden gemeten, worden tijdens de realisatiefase periodiek handmatig geëvalueerd. Minimaal betreft dit de beveiliging van de software, zie [$M26$](#m26). Ook zorgt het project dat de performance van de software regelmatig wordt getest. Voor kwaliteitsaspecten als toegankelijkheid en gebruikskwaliteit organiseert het project handmatige testen en/of evaluaties in een vorm en met een frequentie die aansluit bij de aard van de applicatie en de door de opdrachtgevende organisatie gestelde eisen. De kwaliteitsmanager houdt in Quality-time bij wanneer de laatste test of evaluatie is uitgevoerd en wanneer het tijd is voor de volgende. ### Realisatiefase: actualisering en review documentatie diff --git a/Content/Maatregelen/M05/Definitie.md b/Content/Maatregelen/M05/Definitie.md index fb0fcd0f..24d42fef 100644 --- a/Content/Maatregelen/M05/Definitie.md +++ b/Content/Maatregelen/M05/Definitie.md @@ -1,4 +1,4 @@ **$M05$** -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 opdrachtgever. 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. +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. diff --git a/Content/Maatregelen/M05/Maatregel.md b/Content/Maatregelen/M05/Maatregel.md index ab674aeb..9c00e8ca 100644 --- a/Content/Maatregelen/M05/Maatregel.md +++ b/Content/Maatregelen/M05/Maatregel.md @@ -13,4 +13,4 @@ Als operationeel beheer onderdeel is van de dienstverlening, past ICTU de DevOps ### Rationale -De incrementele oplevering levert vrijwel iedere iteratie toegevoegde waarde en stelt opdrachtgevers, gebruikers en anderen in staat om gaandeweg ervaring op te doen en bij te sturen. Verder dwingt het vroegtijdige tests en kwaliteitscontroles af, die daarmee verankerd worden in het ontwikkel- en onderhoudsproces. Door naast de software telkens ook alle andere producten bij te werken en op te leveren, wordt bereikt dat het product als geheel consistent blijft en dat er geen achterstallig onderhoud ontstaat. Dit leidt tot een zich continu verbeterend proces. +De incrementele oplevering levert vrijwel iedere iteratie toegevoegde waarde en stelt opdrachtgevers, product owners, gebruikers en anderen in staat om gaandeweg ervaring op te doen en bij te sturen. Verder dwingt het vroegtijdige tests en kwaliteitscontroles af, die daarmee verankerd worden in het ontwikkel- en onderhoudsproces. Door naast de software telkens ook alle andere producten bij te werken en op te leveren, wordt bereikt dat het product als geheel consistent blijft en dat er geen achterstallig onderhoud ontstaat. Dit leidt tot een zich continu verbeterend proces. diff --git a/Content/Maatregelen/M07/Maatregel.md b/Content/Maatregelen/M07/Maatregel.md index 398d7e33..5e76c100 100644 --- a/Content/Maatregelen/M07/Maatregel.md +++ b/Content/Maatregelen/M07/Maatregel.md @@ -13,7 +13,7 @@ De geautomatiseerde continuous delivery pipeline voert ten minste de volgende ac 7. Broncodekwaliteitscontroles, 8. Installatie van de software in test, acceptatie en/of productieomgevingen, 9. Produceren van een "software bill of materials" (SBoM), -10. Oplevering van het totale product, dus inclusief alle deliverables, in de vorm zoals bruikbaar voor en afgesproken met de opdrachtgever. +10. Oplevering van het totale product, dus inclusief alle deliverables, in de vorm zoals bruikbaar voor en afgesproken met de opdrachtgevende organisatie. Performance- en beveiligingstests zijn ook onderdeel van de continuous delivery pipeline, maar vanwege doorlooptijden en licenties is dat niet altijd haalbaar; in dat geval vinden de performance- en beveiligingstests zo veel mogelijk, en bij voorkeur dagelijks, plaats. @@ -21,7 +21,7 @@ Niet alle testen en controles kunnen altijd geautomatiseerd worden uitgevoerd. D De afdeling ICTU Software Diensten (ISD) voorziet in tools en ondersteuning, zodat projecten deze pipeline kunnen toepassen. Projecten zijn verantwoordelijk voor de correcte werking van de pipeline. -ICTU gebruikt Jenkins, GitLab CI of Azure DevOps als tool voor de implementatie van de continuous delivery pipeline. ISD biedt de projecten een voorziening om releases van het totale product veilig op te leveren aan opdrachtgevers en beheerorganisaties. +ICTU gebruikt Jenkins, GitLab CI of Azure DevOps als tool voor de implementatie van de continuous delivery pipeline. ISD biedt de projecten een voorziening om releases van het totale product veilig op te leveren aan opdrachtgevende organisaties en beheerorganisaties. ### Rationale diff --git a/Content/Maatregelen/M08/Maatregel.md b/Content/Maatregelen/M08/Maatregel.md index 4320b907..1af8c5b9 100644 --- a/Content/Maatregelen/M08/Maatregel.md +++ b/Content/Maatregelen/M08/Maatregel.md @@ -6,7 +6,7 @@ Technische schuld zijn eigenschappen van de software die de lange termijn inzetb De kwaliteitsmanager maakt de technische schuld inzichtelijk met behulp van Quality-time, het kwaliteitssysteem van ICTU. Technische schuld die niet geautomatiseerd kan worden gemeten legt de kwaliteitsmanager handmatig vast. -Als het Scrumteam of de kwaliteitsmanager constateert dat er technische schuld is, markeert de kwaliteitsmanager deze technische schuld in Quality-time om te voorkomen dat de technische schuld ongemerkt verder toeneemt. Vervolgens vraagt de kwaliteitsmanager het Scrumteam om de omvang van de technische schuld in te schatten in user-story-punten. Daarna wordt een plan gemaakt om de technische schuld in een beheerst tempo weg te werken; uitgangspunt is ongeveer 10% van de punten die het Scrumteam normaal in een sprint doet. Dit kan in principe zonder overleg met de opdrachtgever omdat het leveren van kwaliteit onderdeel van het werk is. +Als het Scrumteam of de kwaliteitsmanager constateert dat er technische schuld is, markeert de kwaliteitsmanager deze technische schuld in Quality-time om te voorkomen dat de technische schuld ongemerkt verder toeneemt. Vervolgens vraagt de kwaliteitsmanager het Scrumteam om de omvang van de technische schuld in te schatten in user-story-punten. Daarna wordt een plan gemaakt om de technische schuld in een beheerst tempo weg te werken; uitgangspunt is ongeveer 10% van de punten die het Scrumteam normaal in een sprint doet. Dit kan in principe zonder overleg met de opdrachtgevende organisatie omdat het leveren van kwaliteit onderdeel van het werk is. ### Rationale diff --git a/Content/Maatregelen/M14/Definitie.md b/Content/Maatregelen/M14/Definitie.md index 846fbb18..8ba1ab6a 100644 --- a/Content/Maatregelen/M14/Definitie.md +++ b/Content/Maatregelen/M14/Definitie.md @@ -1,4 +1,4 @@ **$M14$** -Projecten hebben een voorbereidingsfase, "voorfase" genoemd, voorafgaand aan de realisatiefase. Voor het uitvoeren van de voorfase zijn vertegenwoordigers van de opdrachtgever, de beoogde beheerorganisatie en andere belanghebbenden 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. +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. diff --git a/Content/Maatregelen/M14/Maatregel.md b/Content/Maatregelen/M14/Maatregel.md index 3aa7ffa2..e018cf3c 100644 --- a/Content/Maatregelen/M14/Maatregel.md +++ b/Content/Maatregelen/M14/Maatregel.md @@ -4,12 +4,12 @@ Bij voorkeur zijn dezelfde deskundigen in zowel de voorfase als in de realisatiefase betrokken. -In de realisatiefase wordt de prioriteit van werk van het Scrumteam bepaald door een product owner van de opdrachtgever. Bij aanvang van de voorfase is deze beoogde product owner bekend en werkt deze ook mee in de voorfase. +In de realisatiefase wordt de prioriteit van werk van het Scrumteam bepaald door een product owner van de opdrachtgevende organisatie. Bij aanvang van de voorfase is deze beoogde product owner bekend en werkt deze ook mee in de voorfase. -Als tijdens de realisatiefase blijkt dat de kaders van het project significant wijzigen, dan stemmen opdrachtgever, ICTU en andere betrokken partijen af welke onderdelen van de voorfase opnieuw moeten worden uitgevoerd. +Als tijdens de realisatiefase blijkt dat de kaders van het project significant wijzigen, dan stemmen opdrachtgevende organisatie, ICTU en andere betrokken partijen af welke onderdelen van de voorfase opnieuw moeten worden uitgevoerd. ### Rationale Het doel van de voorfase is ten eerste om uitgangspunten, risico's en randvoorwaarden voor verdere projectuitvoering te bepalen en ten tweede om te zorgen dat aan de randvoorwaarden wordt voldaan en voor zoveel mogelijk projectspecifieke risico's maatregelen genomen zijn. Het doel van de realisatiefase is het daadwerkelijk bouwen en onderhouden van de software. Een expliciete splitsing zorgt ervoor dat projecten doordacht van start gaan. -Al tijdens de voorfase moeten keuzes gemaakt worden die invloed hebben op de beveiligingsmaatregelen. Aanwezigheid van een voldoende gemandateerde vertegenwoordiger van de opdrachtgever zorgt dat deze keuzes gemaakt en bekrachtigd kunnen worden. De keuzes komen onder meer tot uitdrukking in de ontwerp- en architectuurdocumentatie, zie [$M01$](#m01). De infrastructuur gerelateerde documentatie wordt opgesteld door de beoogd beheerder en dekt een deel van de totale beveiligingsmaatregelen af. Aanwezigheid van de beoogd beheerder in de voorfase zorgt dat dekking van dit deel van de beveiligingsmaatregelen geborgd blijft gedurende de realisatie en exploitatie. +Al tijdens de voorfase moeten keuzes gemaakt worden die invloed hebben op de beveiligingsmaatregelen. Aanwezigheid van een voldoende gemandateerde vertegenwoordiger van de opdrachtgevende organisatie zorgt dat deze keuzes gemaakt en bekrachtigd kunnen worden. De keuzes komen onder meer tot uitdrukking in de ontwerp- en architectuurdocumentatie, zie [$M01$](#m01). De infrastructuur gerelateerde documentatie wordt opgesteld door de beoogd beheerder en dekt een deel van de totale beveiligingsmaatregelen af. Aanwezigheid van de beoogd beheerder in de voorfase zorgt dat dekking van dit deel van de beveiligingsmaatregelen geborgd blijft gedurende de realisatie en exploitatie. diff --git a/Content/Maatregelen/M26/Maatregel.md b/Content/Maatregelen/M26/Maatregel.md index 82a46cc9..1befa50c 100644 --- a/Content/Maatregelen/M26/Maatregel.md +++ b/Content/Maatregelen/M26/Maatregel.md @@ -6,7 +6,7 @@ Software wordt minimaal bij iedere grote release of ten minste twee keer per jaa ICTU zorgt ervoor dat de benodigde expertise op afroep beschikbaar gesteld kan worden aan projecten. -Opdrachtgever kan een derde partij opdracht geven beveiligingstesten uit te voeren in een daarvoor door de opdrachtgever beschikbaar gestelde omgeving. Dit kan zowel incidenteel als structureel worden ingericht. Als de opdrachtgever dit structureel inricht en als deze beveiligingstesten voldoen aan de eisen die het project zou stellen, dan kunnen opdrachtgever en het project besluiten dat het project zelf geen beveiligingstesten laat uitvoeren. Afspraken hierover worden bij voorkeur al in de voorfase gemaakt, inclusief een controle dat de opdrachtgever de benodigde contractuele mogelijkheden heeft beveiligingstesten uit te besteden. Het project ontvangt in dat geval de beveiligingstestrapportages van de opdrachtgever. +De opdrachtgevende organisatie kan een derde partij opdracht geven beveiligingstesten uit te voeren in een daarvoor door de opdrachtgevende organisatie beschikbaar gestelde omgeving. Dit kan zowel incidenteel als structureel worden ingericht. Als de opdrachtgevende organisatie dit structureel inricht en als deze beveiligingstesten voldoen aan de eisen die het project zou stellen, dan kunnen de opdrachtgevende organisatie en het project besluiten dat het project zelf geen beveiligingstesten laat uitvoeren. Afspraken hierover worden bij voorkeur al in de voorfase gemaakt, inclusief een controle dat de opdrachtgevende organisatie de benodigde contractuele mogelijkheden heeft beveiligingstesten uit te besteden. Het project ontvangt in dat geval de beveiligingstestrapportages van de opdrachtgevende organisatie. De beveiligingstesten vinden altijd plaats in aanvulling op de door tools uitgevoerde continue beveiligingsanalyse van de gerealiseerde software. Bevindingen uit beveiligingstesten en de continue analyse die niet direct worden opgelost, worden in Jira als issue vastgelegd op de backlog van het project. diff --git a/Content/Maatregelen/M28/Maatregel.md b/Content/Maatregelen/M28/Maatregel.md index c6392369..8589dfa4 100644 --- a/Content/Maatregelen/M28/Maatregel.md +++ b/Content/Maatregelen/M28/Maatregel.md @@ -15,7 +15,7 @@ Voor de belangrijkste verschillen beschrijft de projectleider: De projectleider is verantwoordelijk voor het doen van de self-assessment, die in de regel door de software delivery manager wordt uitgevoerd. De kwaliteitsmanager reviewt de self-assessment, of de software delivery manager en kwaliteitsmanager voeren de self-assessment samen uit. -De self-assessment is een intern product, maar kan gedeeld worden met opdrachtgevers en andere betrokkenen. Voor het uitvoeren en vastleggen van de self-assessment stelt ICTU een [self-assessment formulier]($BASE_URL$/$VERSIE$/ICTU-Kwaliteitsaanpak-Checklist.xlsx) beschikbaar. +De self-assessment is een intern product, maar kan gedeeld worden met opdrachtgevende organisatie en andere betrokken partijen. Voor het uitvoeren en vastleggen van de self-assessment stelt ICTU een [self-assessment formulier]($BASE_URL$/$VERSIE$/ICTU-Kwaliteitsaanpak-Checklist.xlsx) beschikbaar. ### Rationale diff --git a/Content/Maatregelen/M29/Maatregel.md b/Content/Maatregelen/M29/Maatregel.md index 000e7bd9..52b58f7e 100644 --- a/Content/Maatregelen/M29/Maatregel.md +++ b/Content/Maatregelen/M29/Maatregel.md @@ -2,7 +2,7 @@ #include "Content/Maatregelen/M29/Definitie.md" -Voordat ICTU een project start en een overeenkomst sluit met de opdrachtgever maakt de beoogde projectleider afspraken met de afdeling ISD over de door ISD geleverde voorzieningen die het project gaat afnemen en met de afdeling ISE over de medewerkers van de afdeling ISE die het project gaat inzetten. +Voordat ICTU een project start en een overeenkomst sluit met de opdrachtgevende organisatie maakt de beoogde projectleider afspraken met de afdeling ISD over de door ISD geleverde voorzieningen die het project gaat afnemen en met de afdeling ISE over de medewerkers van de afdeling ISE die het project gaat inzetten. Hierbij bewaken ISD en ISE dat de omvang, de snelheid van opschaling, en de behoefte aan ondersteuning van het project zodanig is dat dit samengaat met ongestoorde dienstverlening aan de lopende projecten. diff --git a/Content/Maatregelen/M31/Definitie.md b/Content/Maatregelen/M31/Definitie.md index dfb5089e..8080f30d 100644 --- a/Content/Maatregelen/M31/Definitie.md +++ b/Content/Maatregelen/M31/Definitie.md @@ -1,4 +1,4 @@ **$M31$** - Voor een goede uitvoering van het project is specifieke informatie nodig. De opdrachtgever 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 opdrachtgever de informatie bij tijdens de voorfase en realisatiefase. + 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. diff --git a/Content/Maatregelen/M31/Maatregel.md b/Content/Maatregelen/M31/Maatregel.md index 6ecfd6e4..d724009a 100644 --- a/Content/Maatregelen/M31/Maatregel.md +++ b/Content/Maatregelen/M31/Maatregel.md @@ -2,18 +2,18 @@ #include "Content/Maatregelen/M31/Definitie.md" -De opdrachtgever zorgt dat het project vanaf de start van de voorfase beschikt over: +De opdrachtgevende organisatie zorgt dat het project vanaf de start van de voorfase beschikt over: 1. Projectstartarchitectuur, 2. Business impact analysis, 3. Privacy impact assessment, -4. Afspraken tussen opdrachtgever en beheerpartij. +4. Afspraken tussen opdrachtgevende organisatie en beheerorganisatie. -Als de benodigde informatie niet gereed is bij de start van de voorfase dan maken opdrachtgever en ICTU nadere afspraken over de manier waarop de benodigde informatie nog tijdens de voorfase beschikbaar komt voor het project. +Als de benodigde informatie niet gereed is bij de start van de voorfase dan maken opdrachtgevende organisatie en ICTU nadere afspraken over de manier waarop de benodigde informatie nog tijdens de voorfase beschikbaar komt voor het project. ### Projectstartarchitectuur -Een projectstartarchitectuur (PSA) is bedoeld om te borgen dat nieuwe ontwikkelingen en veranderingen in samenhang worden gerealiseerd en passen binnen de toekomstig gewenste informatievoorziening. De PSA is een concreet en doelgericht ICT-architectuurkader waarbinnen het project moet worden uitgevoerd. In de PSA zijn de architectuurvisie, enterprise-architectuur en overige architecturen van de opdrachtgever vertaald naar aan het product te stellen eisen. Een PSA bevat in ieder geval de volgende onderwerpen: +Een projectstartarchitectuur (PSA) is bedoeld om te borgen dat nieuwe ontwikkelingen en veranderingen in samenhang worden gerealiseerd en passen binnen de toekomstig gewenste informatievoorziening. De PSA is een concreet en doelgericht ICT-architectuurkader waarbinnen het project moet worden uitgevoerd. In de PSA zijn de architectuurvisie, enterprise-architectuur en overige architecturen van de opdrachtgevende organisatie vertaald naar aan het product te stellen eisen. Een PSA bevat in ieder geval de volgende onderwerpen: * Een beschrijving van de doelen en ambities waaraan het project bijdraagt en invulling geeft. Dus niet de projectdoelen en -ambitie. * Een afbakening van het project en de context van de voorziening/oplossing die het project gaat realiseren. De PSA beschrijft niet de implementatie van de voorziening zelf (dit blijft een 'black box'), maar wel het gewenste gedrag in het grotere geheel. Denk o.a. ook aan relaties met andere projecten en generieke en specifieke diensten (services). @@ -37,18 +37,18 @@ In een privacy impact assessment (PIA) legt de opdrachtgevende organisatie vast Als een PIA niet nodig is, dan is een verklaring daaromtrent vereist. -### Afspraken tussen opdrachtgever en beheerpartij +### Afspraken tussen opdrachtgevende organisatie en beheerorganisatie -Opdrachtgever heeft afspraken gemaakt met een (interne of externe) beheerpartij die voornemens is het beheer van de software uit te voeren. De afspraken omvatten in ieder geval de inzet van medewerkers van de beheerpartij tijdens de voorfase en het type beheer dat de beheerpartij voornemens is te gaan uitvoeren: operationeel beheer, applicatiebeheer en/of functioneel beheer. +De opdrachtgevende organisatie heeft afspraken gemaakt met een (interne of externe) beheerorganisatie die voornemens is het beheer van de software uit te voeren. De afspraken omvatten in ieder geval de inzet van medewerkers van de beheerorganisatie tijdens de voorfase en het type beheer dat de beheerorganisatie voornemens is te gaan uitvoeren: operationeel beheer, applicatiebeheer en/of functioneel beheer. -De beheerpartij stelt relevante informatie ter beschikking aan het project zoals beveiligingsbeleid, beheeracceptatiecriteria, documentatie van de te gebruiken voorzieningen voor bijvoorbeeld authenticatie en autorisatie en verder te hanteren kaders en richtlijnen. +De beheerorganisatie stelt relevante informatie ter beschikking aan het project zoals beveiligingsbeleid, beheeracceptatiecriteria, documentatie van de te gebruiken voorzieningen voor bijvoorbeeld authenticatie en autorisatie en verder te hanteren kaders en richtlijnen. ### Aanvullende informatie -Waar mogelijk stelt de opdrachtgever ook andere relevante informatie ter beschikking aan het project zoals een eventueel programma van eisen, procesbeschrijvingen van te ondersteunen bedrijfsprocessen, documentatie van te koppelen systemen en verder te hanteren kaders en richtlijnen. +Waar mogelijk stelt de opdrachtgevende organisatie ook andere relevante informatie ter beschikking aan het project zoals een eventueel programma van eisen, procesbeschrijvingen van te ondersteunen bedrijfsprocessen, documentatie van te koppelen systemen en verder te hanteren kaders en richtlijnen. ### Rationale De genoemde producten hebben tot doel om de benodigde omvang, kosten en doorlooptijd van de voorfase te kunnen schatten. De projectstartarchitectuur vormt input voor de tijdens de voorfase te ontwikkelen producten zoals functionele en niet-functionele eisen, functioneel ontwerp en softwarearchitectuur. Een BIA en eventuele PIA zijn richtinggevend voor de in de voorfase te selecteren beveiligingsmaatregelen. -Als deze producten er niet zijn, niet actueel zijn, en/of niet compleet zijn, dan moeten ze in de voorfase alsnog worden gemaakt, bijgewerkt en/of aangevuld. Dit vereist grote betrokkenheid van de organisatie van de opdrachtgever, en is in de regel lastig op korte termijn te organiseren. +Als deze producten er niet zijn, niet actueel zijn, en/of niet compleet zijn, dan moeten ze in de voorfase alsnog worden gemaakt, bijgewerkt en/of aangevuld. Dit vereist grote betrokkenheid van de opdrachtgevende organisatie, en is in de regel lastig op korte termijn te organiseren. diff --git a/Content/Maatregelen/M32/Maatregel.md b/Content/Maatregelen/M32/Maatregel.md index e112558e..162b352a 100644 --- a/Content/Maatregelen/M32/Maatregel.md +++ b/Content/Maatregelen/M32/Maatregel.md @@ -2,11 +2,11 @@ #include "Content/Maatregelen/M32/Definitie.md" -Als tijdens een project bestaande software dient te worden afgebouwd, onderhouden en/of herbouwd, vindt een onderzoek plaats naar de compleetheid en consistentie van de bestaande softwareproducten (zie de tabel in [$M01$](#m01), inclusief de deliverables in de kolom 'Realisatiefase') en wordt de kwaliteit van de bestaande softwareproducten getoetst. Dit onderzoek, dat bij ICTU een "due diligence" heet, is onderdeel van de voorfase en wordt uitgevoerd door vertegenwoordigers van ICTU en medewerkers van het desbetreffende project, samen met vertegenwoordigers van de opdrachtgever. +Als tijdens een project bestaande software dient te worden afgebouwd, onderhouden en/of herbouwd, vindt een onderzoek plaats naar de compleetheid en consistentie van de bestaande softwareproducten (zie de tabel in [$M01$](#m01), inclusief de deliverables in de kolom 'Realisatiefase') en wordt de kwaliteit van de bestaande softwareproducten getoetst. Dit onderzoek, dat bij ICTU een "due diligence" heet, is onderdeel van de voorfase en wordt uitgevoerd door vertegenwoordigers van ICTU en medewerkers van het desbetreffende project, samen met vertegenwoordigers van de opdrachtgevende organisatie. De uitkomsten van het onderzoek bestaan uit: -1. Een rapportage met tenminste de bevindingen, risico's voor opdrachtgever en ICTU, en mitigerende maatregelen, +1. Een rapportage met tenminste de bevindingen, risico's voor opdrachtgevende organisatie en ICTU, en mitigerende maatregelen, 2. Een transitieplan dat de activiteiten beschrijft die nodig zijn om de software af te bouwen of te herbouwen en te onderhouden, en 3. Als er significante technische schuld aanwezig is in de bestaande software: een plan voor het aflossen van deze schuld. diff --git a/Content/Maatregelen/M34/Maatregel.md b/Content/Maatregelen/M34/Maatregel.md index 8b9e41a0..f000f455 100644 --- a/Content/Maatregelen/M34/Maatregel.md +++ b/Content/Maatregelen/M34/Maatregel.md @@ -4,7 +4,7 @@ Het project gebruikt de Nederlandse praktijkrichtlijn NEN NPR 5325:2017 als leidraad voor de overdracht van software aan een andere partij. De paragraafnummers hieronder verwijzen naar de betreffende paragraaf in NPR 5325. -Het project zorgt, bij voorkeur altijd maar in ieder geval bij de overdracht, dat de software, documentatie en testmiddelen aantoonbaar voldoen aan onderstaande criteria. Waar nodig scherpt het project, in afstemming met opdrachtgever en ontvangende partij, de criteria aan. +Het project zorgt, bij voorkeur altijd maar in ieder geval bij de overdracht, dat de software, documentatie en testmiddelen aantoonbaar voldoen aan onderstaande criteria. Waar nodig scherpt het project, in afstemming met opdrachtgevende organisatie en ontvangende partij, de criteria aan. 1. De documentatie beschrijft de ontwikkel- en testomgeving die is toegepast (5.1), 1. De functionele documentatie beschrijft gegevensmodellen, functionele indeling, koppelingen, berichtdefinities en workflows/processen (5.2), @@ -21,4 +21,4 @@ Het project zorgt, bij voorkeur altijd maar in ieder geval bij de overdracht, da 1. Er is traceerbaarheid van eisen naar testgevallen (7.5), en 1. De testset is goed opgebouwd (7.6). -Ten behoeve van de overdracht maakt het project, in afstemming met opdrachtgever en ontvangende partij, een plan voor de voorbereiding van de overdracht, de kennisoverdracht, de overdracht van de software zelf en eventuele nazorg. +Ten behoeve van de overdracht maakt het project, in afstemming met opdrachtgevende organisatie en ontvangende partij, een plan voor de voorbereiding van de overdracht, de kennisoverdracht, de overdracht van de software zelf en eventuele nazorg. diff --git a/Content/Maatregelen/M35/Definitie.md b/Content/Maatregelen/M35/Definitie.md index 0e3f0e9d..74193863 100644 --- a/Content/Maatregelen/M35/Definitie.md +++ b/Content/Maatregelen/M35/Definitie.md @@ -1,4 +1,4 @@ **$M35$** -Tijdens de voorfase verwerkt het project de door de opdrachtgever 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. +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. diff --git a/Content/Maatregelen/M35/Maatregel.md b/Content/Maatregelen/M35/Maatregel.md index f187cc99..e2f1f1f2 100644 --- a/Content/Maatregelen/M35/Maatregel.md +++ b/Content/Maatregelen/M35/Maatregel.md @@ -2,13 +2,13 @@ #include "Content/Maatregelen/M35/Definitie.md" -Ten behoeve van de agile architectuuraanpak werkt het Scrumteam nauw samen met de architecten van de opdrachtgever en de beheerorganisatie, zowel in de voorfase als tijdens de realisatiefase. +Ten behoeve van de agile architectuuraanpak werkt het Scrumteam nauw samen met de architecten van de opdrachtgevende organisatie en de beheerorganisatie, zowel in de voorfase als tijdens de realisatiefase. Tijdens de voorfase schrijft de softwarearchitect (het teamlid met de rol van architect) het SAD, inclusief genomen ontwerpbeslissingen. Tijdens de realisatiefase ondersteunt de softwareachitect het team bij het realiseren van de software conform het SAD. Daarbij kunnen nieuwe inzichten ontstaan die van invloed zijn op het SAD, bijvoorbeeld dat gekozen technologie niet voldoet of dat benodigde brondata niet eenvoudig ontsluitbaar is. -De softwarearchitect informeert de opdrachtgever en de beheerorganisatie over deze nieuwe inzichten en stemt de gevolgen hiervan af. Deze nieuwe inzichten kunnen voor de opdrachtgever en de beheerorganisatie aanleiding zijn om hun architectuur aan te passen. +De softwarearchitect informeert de opdrachtgevende organisatie en de beheerorganisatie over deze nieuwe inzichten en stemt de gevolgen hiervan af. Deze nieuwe inzichten kunnen voor de opdrachtgevende organisatie en de beheerorganisatie aanleiding zijn om hun architectuur aan te passen. ### Rationale diff --git a/Content/Templates/Colofon.md b/Content/Templates/Colofon.md index 25ece43f..f3f0f2e7 100644 --- a/Content/Templates/Colofon.md +++ b/Content/Templates/Colofon.md @@ -18,30 +18,30 @@ Rubricering conform [VIRBI 2013, art. 4](https://wetten.overheid.nl/BWBR0033507/ ###### Reviewers -| Functie/rol | Naam | Datum | Versie | -|:--------------------------------------|:-------|:--------|:--------:| -| Kwaliteitsmanager {opdrachtgever} | {naam} | {datum} | {versie} | -| Kwaliteitsmanager {beheerorganisatie} | {naam} | {datum} | {versie} | -| Kwaliteitsmanager ICTU | {naam} | {datum} | {versie} | +| Functie/rol | Naam | Datum | Versie | +|:------------------------------------------------|:-------|:--------|:--------:| +| Kwaliteitsmanager {opdrachtgevende organisatie} | {naam} | {datum} | {versie} | +| Kwaliteitsmanager {beheerorganisatie} | {naam} | {datum} | {versie} | +| Kwaliteitsmanager ICTU | {naam} | {datum} | {versie} | ###### Vereiste goedkeuringen -| Functie/rol | Naam | Datum | Versie | -|:----------------------------------|:-------|:--------|:--------:| -| Projectleider {opdrachtgever} | {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} | {datum} | {versie} | +| Projectleider {beheerorganisatie} | {naam} | {datum} | {versie} | +| Projectleider ICTU | {naam} | {datum} | {versie} | +| Product owner | {naam} | {datum} | {versie} | ###### Verzendlijst huidige versie -| Naam | Organisatie | Functie/rol | -|:-------|:--------------------|:--------------------------| -| {naam} | {opdrachtgever} | Projectleider | -| {naam} | {opdrachtgever} | Product owner | -| {naam} | {beheerorganisatie} | Projectleider | -| {naam} | ICTU | Projectleider | -| {naam} | ICTU | Software delivery manager | +| Naam | Organisatie | Functie/rol | +|:-------|:------------------------------|:--------------------------| +| {naam} | {opdrachtgevende organisatie} | Projectleider | +| {naam} | {opdrachtgevende organisatie} | Product owner | +| {naam} | {beheerorganisatie} | Projectleider | +| {naam} | ICTU | Projectleider | +| {naam} | ICTU | Software delivery manager | ###### Template versie diff --git a/Content/Templates/Compacte-Voorfase/Doelgroep.md b/Content/Templates/Compacte-Voorfase/Doelgroep.md index 923552c9..f963531f 100644 --- a/Content/Templates/Compacte-Voorfase/Doelgroep.md +++ b/Content/Templates/Compacte-Voorfase/Doelgroep.md @@ -1,6 +1,6 @@ ## Doelgroep -Dit document is in eerste instantie bestemd voor de opdrachtgever van {het product}. Het biedt ook inzicht en overzicht aan andere betrokkenen bij het project, namelijk: +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: * de ontwikkelaar(s) van het systeem, * de beheerder(s) van het systeem. diff --git a/Content/Templates/Detailtestplan/Template-Inhoud.md b/Content/Templates/Detailtestplan/Template-Inhoud.md index 672f178c..2b68f104 100644 --- a/Content/Templates/Detailtestplan/Template-Inhoud.md +++ b/Content/Templates/Detailtestplan/Template-Inhoud.md @@ -14,7 +14,7 @@ Dit hoofdstuk beschrijft welke projecten, systemen, componenten, releases, use c Dit hoofdstuk beschrijft hoe de testen conform de teststrategie, beschreven in het Mastertestplan, concreet worden aangepakt. -{De Kwaliteitsaanpak schrijft voor dat er in de voorfase een Mastertestplan (door de opdrachtgever) is opgesteld. Mocht dit niet zijn opgesteld, dan zal het detailtestplan minimaal aan de door ICTU gestelde kwaliteitsnormen moeten voldoen.} +{De Kwaliteitsaanpak schrijft voor dat er in de voorfase een Mastertestplan (door de opdrachtgevende organisatie) is opgesteld. Mocht dit niet zijn opgesteld, dan zal het detailtestplan minimaal aan de door ICTU gestelde kwaliteitsnormen moeten voldoen.} ## Soorten testen @@ -29,10 +29,10 @@ Binnen het project worden door ICTU de volgende testsoorten onderscheiden en toe + **Handmatig testen van nieuwe functionaliteit:** Het handmatig uitvoeren van fysieke testgevallen om de werking van de nieuwgebouwde functionaliteit te testen. + **Handmatig regressietest:** Het handmatig uitvoeren van fysieke testgevallen om de werking van de bestaande functionaliteit te controleren. Deze testgevallen zijn veelal te complex om te automatiseren. * Niet-functionele testen: - + **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 opdrachtgever op de eigen productieomgeving een performancetest moet uitvoeren om te controleren dat er aan de gestelde performance-eisen is voldaan. + + **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 opdrachtgever 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. {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. * **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 diff --git a/Content/Templates/Detailtestplan/Uitgangspunten.md b/Content/Templates/Detailtestplan/Uitgangspunten.md index 205ec17b..e7ae2f9c 100644 --- a/Content/Templates/Detailtestplan/Uitgangspunten.md +++ b/Content/Templates/Detailtestplan/Uitgangspunten.md @@ -6,7 +6,7 @@ De volgende uitgangspunten zijn van toepassing op dit document: |:-----|:----| | 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 opdrachtgever en/of product owner besluiten om bepaalde functionaliteit, bijvoorbeeld geleverd door externe partijen, niet te testen. Indien dit voorkomt, dan zal dit expliciet worden opgenomen in de managementsamenvatting van het vrijgaveadvies. | +| U03 | Per release of per sprint kan de product owner besluiten om bepaalde functionaliteit, bijvoorbeeld geleverd door externe partijen, niet te testen. Indien dit voorkomt, dan zal dit expliciet worden opgenomen in de managementsamenvatting van het vrijgaveadvies. | | U04 | De multidisciplinaire samenstelling van de Scrumteams — test engineers en ontwikkelaars zitten in hetzelfde team — geeft mogelijkheid tot snelle interactie. Issues gevonden binnen een sprint kunnen hierdoor vaak nog binnen dezelfde sprint worden opgelost en hoeven dus niet apart geadministreerd te worden. | | U05 | Issues gevonden tijdens de acceptatietesten of in productie worden op de backlog verwerkt samen met de user stories. | | U06 | De ontwikkel- en testplanning zijn met elkaar verweven. Het ontwikkelen en testen van de user stories zijn onlosmakelijk met elkaar verbonden en beginnen op hetzelfde moment. | diff --git a/Content/Templates/GFO/Over-dit-document.md b/Content/Templates/GFO/Over-dit-document.md index e33f5de2..9d4191ea 100644 --- a/Content/Templates/GFO/Over-dit-document.md +++ b/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 opdrachtgever}. 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 {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. {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 opdrachtgever 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 {de opdrachtgevende organisatie} en in overleg met de ontvangende partij een actueel GFO maken. diff --git a/Content/Templates/GFO/Template-Inhoud.md b/Content/Templates/GFO/Template-Inhoud.md index a33a1a9c..b776a2a3 100644 --- a/Content/Templates/GFO/Template-Inhoud.md +++ b/Content/Templates/GFO/Template-Inhoud.md @@ -36,7 +36,7 @@ Dit hoofdstuk beschrijft de werking van {de applicatie} op hoofdlijnen. Het besc # Use cases -{Gebruik voor de beschrijving van use cases in de voorfase een methode als de “casual” variant van Cockburn ("Writing effective use cases", 2001). In de realisatiefase en/of voor overdracht naar een andere partij kan de “fully dressed” variant (of een andere methode voor uitgebreidere beschrijvingen) worden toegepast. Doe dit gezien de onderhoudslast alleen als de opdrachtgever en/of ontvangende partij daar expliciet om vraagt.} +{Gebruik voor de beschrijving van use cases in de voorfase een methode als de “casual” variant van Cockburn ("Writing effective use cases", 2001). In de realisatiefase en/of voor overdracht naar een andere partij kan de “fully dressed” variant (of een andere methode voor uitgebreidere beschrijvingen) worden toegepast. Doe dit gezien de onderhoudslast alleen als de opdrachtgevende organisatie en/of ontvangende partij daar expliciet om vraagt.} {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.} @@ -55,7 +55,7 @@ De use cases zijn gegroepeerd naar de functies zoals beschreven in het vorige ho ## {F1} - {naam functie 1} -Deze paragraaf bevat de use cases behorende bij functie "{functie}". +Deze paragraaf bevat de use cases behorende bij functie "{functie}". ### {UC1.1} - {naam use case 1.1} diff --git a/Content/Templates/Inwerkplan-Kwaliteitsmanager/Template-Inhoud.md b/Content/Templates/Inwerkplan-Kwaliteitsmanager/Template-Inhoud.md index a0fb8e5e..caf89557 100644 --- a/Content/Templates/Inwerkplan-Kwaliteitsmanager/Template-Inhoud.md +++ b/Content/Templates/Inwerkplan-Kwaliteitsmanager/Template-Inhoud.md @@ -109,17 +109,17 @@ Leerdoelen (week 3): ## Projectcontext Leerdoelen (week 1): -* Je begrijpt wat de doelstelling van de opdrachtgever met het project is, c.q. je weet welk probleem het project moet oplossen +* Je begrijpt wat de doelstelling van de opdrachtgevende organisatie met het project is, c.q. je weet welk probleem het project moet oplossen * Je weet wie de beoogde gebruikers zijn en wie er verder belanghebbende zijn bij het projectresultaat -* Je weet welke organisaties naast de opdrachtgever en ICTU bij het project zijn betrokken +* Je weet welke organisaties naast de opdrachtgevende organisatie en ICTU bij het project zijn betrokken ## Projectorganisatie Leerdoelen (week 2): * Je weet welke governancestructuur er is afgesproken (stuurgroep, projectleidersoverleg, rapportages, e.d.) -* Je weet wie welke rol speelt bij de opdrachtgever, ICTU en andere betrokken organisaties (projectleider, product owner, software delivery manager, e.d.) +* Je weet wie welke rol speelt bij de opdrachtgevende organisatie, ICTU en andere betrokken organisaties (opdrachtgever, projectleider, product owner, software delivery manager, e.d.) * Je weet wie welke rol speelt binnen het/de Scrumteam(s) in je project (ontwikkelaar, tester, devops-engineer, ontwerper, etc.) -* Je hebt kennisgemaakt met de kwaliteitsmanager aan de kant van de opdrachtgever +* Je hebt kennisgemaakt met de kwaliteitsmanager aan de kant van de opdrachtgevende organisatie ## Proces diff --git a/Content/Templates/Kwaliteitsplan/Managementsamenvatting.md b/Content/Templates/Kwaliteitsplan/Managementsamenvatting.md index 6ef6b7ff..533e4627 100644 --- a/Content/Templates/Kwaliteitsplan/Managementsamenvatting.md +++ b/Content/Templates/Kwaliteitsplan/Managementsamenvatting.md @@ -1,4 +1,4 @@ -ICTU hanteert voor het ontwikkelen van maatwerksoftware de $KWALITEITSAANPAK$. Deze Kwaliteitsaanpak houdt in dat ICTU voor elk softwareproject een aantal standaard maatregelen toepast, min of meer onafhankelijk van de precieze eisen die de opdrachtgever stelt aan de software. Dit kwaliteitsplan geeft een overzicht van deze standaard kwaliteitsmaatregelen. Voor de realisatiefase zijn de belangrijkste maatregelen: +ICTU hanteert voor het ontwikkelen van maatwerksoftware de $KWALITEITSAANPAK$. Deze Kwaliteitsaanpak houdt in dat ICTU voor elk softwareproject een aantal standaard maatregelen toepast, min of meer onafhankelijk van de precieze eisen die {de opdrachtgevende organisatie} stelt aan de software. Dit kwaliteitsplan geeft een overzicht van deze standaard kwaliteitsmaatregelen. Voor de realisatiefase zijn de belangrijkste maatregelen: * Het hanteren van expliciete entry-en exitcriteria voor het oppakken en afronden van werk * Het toepassen van het ICTU-kwaliteitssysteem (Quality-time) @@ -7,6 +7,6 @@ ICTU hanteert voor het ontwikkelen van maatwerksoftware de $KWALITEITSAANPAK$. D * Het zichtbaar maken en managen van technische schuld * {Als operationeel beheer onderdeel is van de dienstverlening:} Het bewaken van de kwaliteit van de applicatie in de operatie op aspecten als performance en resource gebruik -Omdat de opdrachtgever specifieke eisen stelt aan de kwaliteitsaspecten {kwaliteitsaspecten} zullen de volgende extra kwaliteitsmaatregelen worden getroffen om deze eisen te borgen: +Omdat {de opdrachtgevende organisatie} specifieke eisen stelt aan de kwaliteitsaspecten {kwaliteitsaspecten} zullen de volgende extra kwaliteitsmaatregelen worden getroffen om deze eisen te borgen: * {Projectspecifieke kwaliteitsmaatregel 1} * {Projectspecifieke kwaliteitsmaatregel 2} diff --git a/Content/Templates/Kwaliteitsplan/Over-dit-document.md b/Content/Templates/Kwaliteitsplan/Over-dit-document.md index 9a2c25be..1a054979 100644 --- a/Content/Templates/Kwaliteitsplan/Over-dit-document.md +++ b/Content/Templates/Kwaliteitsplan/Over-dit-document.md @@ -1,6 +1,6 @@ ## Over dit document -Kwaliteitsmanagement is gericht op het borgen dat het projectresultaat voldoet aan de kwaliteitseisen van de opdrachtgever en andere belanghebbenden en aan de kwaliteitsnormen van ICTU. Tegelijkertijd bevordert het de efficiëntie en effectiviteit, en daarmee de doorlooptijd, van het project. Alle betrokkenen in en bij het project dragen bij aan de kwaliteit van producten en processen. De ICTU-projectleider is verantwoordelijk voor het opleveren van een eindresultaat dat voldoet aan de eisen en normen. +Kwaliteitsmanagement is gericht op het borgen dat het projectresultaat voldoet aan de kwaliteitseisen van {de opdrachtgevende organisatie} en andere belanghebbenden en aan de kwaliteitsnormen van ICTU. Tegelijkertijd bevordert het de efficiëntie en effectiviteit, en daarmee de doorlooptijd, van het project. Alle betrokkenen in en bij het project dragen bij aan de kwaliteit van producten en processen. De ICTU-projectleider is verantwoordelijk voor het opleveren van een eindresultaat dat voldoet aan de eisen en normen. De $KWALITEITSAANPAK$ (zie bijlagen) ligt ten grondslag aan dit kwaliteitsplan en vereist dat projecten continu voldoen aan de kwaliteitsnormen: diff --git a/Content/Templates/Kwaliteitsplan/Template-Inhoud.md b/Content/Templates/Kwaliteitsplan/Template-Inhoud.md index 9730843a..f3a752fb 100644 --- a/Content/Templates/Kwaliteitsplan/Template-Inhoud.md +++ b/Content/Templates/Kwaliteitsplan/Template-Inhoud.md @@ -32,7 +32,7 @@ De volgende rapportage/escalatielijnen worden gehanteerd indien kwaliteitsnormen 2. Indien 1. niet tot resultaat leidt, escaleert de kwaliteitsmanager de situatie naar de ICTU-projectleider; 3. Indien 2. niet tot resultaat leidt, escaleert de kwaliteitsmanager de situatie naar het hoofd van de afdeling ICTU Software Expertise (ISE). -Als ontdekte kwaliteitsproblemen daartoe aanleiding geven, worden het kwaliteitsplan en/of Quality-time uitgebreid met nieuwe maatregelen en metrieken om de problemen in de toekomst te signaleren en te voorkomen. Dat gebeurt ook proactief, bijvoorbeeld naar aanleiding van ervaringen in andere projecten of als er nieuwe tools beschikbaar komen. De projectleiders van opdrachtgever, de beheerorganisatie en ICTU zorgen er gezamenlijk voor dat de gewenste uitbreidingen worden gerealiseerd. +Als ontdekte kwaliteitsproblemen daartoe aanleiding geven, worden het kwaliteitsplan en/of Quality-time uitgebreid met nieuwe maatregelen en metrieken om de problemen in de toekomst te signaleren en te voorkomen. Dat gebeurt ook proactief, bijvoorbeeld naar aanleiding van ervaringen in andere projecten of als er nieuwe tools beschikbaar komen. De projectleiders van {de opdrachtgevende organisatie}, de beheerorganisatie en ICTU zorgen er gezamenlijk voor dat de gewenste uitbreidingen worden gerealiseerd. ## Projectdocumenten @@ -54,7 +54,7 @@ De opstellers verwerken het commentaar. Vervolgens sturen de opstellers een toel Het doel van de voorfase is tweeledig: het voorbereiden van de realisatiefase, zodat ICTU verantwoord een projectovereenkomst kan opstellen voor de realisatiefase, en het identificeren van risico’s die van toepassing zijn op de realisatiefase en het verdere verloop van het project. -De opdrachtgever 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 opdrachtgever de informatie bij tijdens de voorfase en realisatiefase. +{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. Dit kwaliteitsplan wordt opgesteld tijdens de voorfase, maar is tevens al deels van toepassing, in ieder geval aan het eind van de voorfase. Voor de voorfase gelden de onderstaande kwaliteitsmaatregelen. @@ -62,13 +62,13 @@ Dit kwaliteitsplan wordt opgesteld tijdens de voorfase, maar is tevens al deels De kwaliteit van de deliverables wordt mede bepaald door de verwachtingen van de belanghebbenden. Het is van belang dat alle belanghebbenden zijn geïdentificeerd en hun verwachtingen zijn vastgelegd, geanalyseerd en vertaald naar de eisen voor het te implementeren systeem. De belanghebbenden worden geïdentificeerd in het projectvoorstel voor de voorfase. De eisen aan het te ontwikkelen systeem worden vastgelegd in Backlog en NFE-document. -De tijdens de voorfase geïdentificeerde eisen vormen het startpunt van de opdrachtgever en kunnen gedurende de vervolgfases in overeenstemming met de opdrachtnemer aangepast worden. De product owner vertegenwoordigt gedurende de vervolgfasen de geïdentificeerde belanghebbenden. +De tijdens de voorfase geïdentificeerde eisen vormen het startpunt van {de opdrachtgevende organisatie} en kunnen gedurende de vervolgfases in overeenstemming met de opdrachtnemer aangepast worden. De product owner vertegenwoordigt gedurende de vervolgfasen de geïdentificeerde belanghebbenden. ## Verwerking eisen ### Functionele eisen -Het programma van eisen en de projectstartarchitectuur, beide opgesteld door de opdrachtgever, zijn de basis voor de op te leveren ICTU-documenten, zoals architectuur en ontwerpdocumenten. +Het programma van eisen en de projectstartarchitectuur, beide opgesteld door {de opdrachtgevende organisatie}, zijn de basis voor de op te leveren ICTU-documenten, zoals architectuur en ontwerpdocumenten. ### Niet-Functionele eisen @@ -76,7 +76,7 @@ Niet-functionele eisen aan het te ontwikkelen systeem worden vastgelegd op basis Niet-functionele eisen voor onderstaande kwaliteitsattributen worden als volgt verwerkt: -* De informatiebeveiligingseisen worden in een afzonderlijk informatiebeveiligingsplan vastgelegd. De software zal zodanig worden voortgebracht en {in geval van operationeel en/of applicatiebeheer:} beheerd dat deze de BIO-compliance van de opdrachtgever niet zal hinderen. +* De informatiebeveiligingseisen worden in een afzonderlijk informatiebeveiligingsplan vastgelegd. De software zal zodanig worden voortgebracht en {in geval van operationeel en/of applicatiebeheer:} beheerd dat deze de BIO-compliance van {de opdrachtgevende organisatie} niet zal hinderen. * Gebruikskwaliteit (usability) is ingebed in de standaard werkwijze van ICTU voor de realisatie van maatwerksoftware. Dit aspect wordt geborgd door opname in het plan van aanpak, het ontwerp en de testplannen. * Toegankelijkheid is een wettelijke verplichting voor webgebaseerde en mobiele applicaties, zie de EN 301 549 en de WCAG 2.1, niveau A en AA. Toegankelijkheid wordt geborgd via toegankelijkheidstesten, zie de kwaliteitsmaatregelen in paragraaf [Toegankelijkheidstesten](#toegankelijkheidstesten). * Performance- en securityeisen worden via performance- en securitytests geborgd, zie de kwaliteitsmaatregelen in paragraaf [Testen](#testen). Voor de borging van andere niet-functionele eisen moeten projectspecifieke maatregelen getroffen worden. Deze worden in dit kwaliteitsplan opgenomen. @@ -272,7 +272,7 @@ Deze performancetesten worden uitgevoerd in de {performancetestomgeving}. De loa Quality-time rapporteert over de geautomatiseerde performancetesten. Als de verantwoordelijke tester performancerisico's ontdekt die ook aanwezig zijn in een versie van de software die reeds is opgeleverd, rapporteert de tester deze risico's aan het Scrumteam. Issues die voortkomen uit performancetesten worden opgenomen in Jira met het label "performance_bevinding". -{Als operationeel beheer geen onderdeel is van de dienstverlening:} De testen van ICTU kunnen geen uitsluitsel geven over de uiteindelijke performance in de productie-omgeving: ze geven niet meer dan een relatief resultaat ten opzichte van eerdere testen in dezelfde testomgeving. Toch hanteert ICTU ze als een standaard kwaliteitsmaatregel, vóór de oplevering van een nieuwe versie van de software. Want ze geven het inzicht of de performance voor wat betreft de software geen achteruitgang betekent ten opzichte van de bestaande situatie. De uiteindelijke performance in de productieomgeving dient de opdrachtgever zelf te laten testen. +{Als operationeel beheer geen onderdeel is van de dienstverlening:} De testen van ICTU kunnen geen uitsluitsel geven over de uiteindelijke performance in de productie-omgeving: ze geven niet meer dan een relatief resultaat ten opzichte van eerdere testen in dezelfde testomgeving. Toch hanteert ICTU ze als een standaard kwaliteitsmaatregel, vóór de oplevering van een nieuwe versie van de software. Want ze geven het inzicht of de performance voor wat betreft de software geen achteruitgang betekent ten opzichte van de bestaande situatie. De uiteindelijke performance in de productieomgeving dient {de opdrachtgevende organisatie} zelf te (laten) testen. ## Security-testen @@ -292,7 +292,7 @@ Elke beveiligingstest resulteert in een beveiligingstestrapportage met daarin de Quality-time rapporteert of gevonden beveiligingsissues niet te lang open staan. -{Als operationeel beheer geen onderdeel is van de dienstverlening:} Merk op: de beveiliging van de software in de acceptatie- en productieomgeving kan niet door ICTU getest worden. Deze test moet de opdrachtgever of de beheerorganisatie uitvoeren. +{Als operationeel beheer geen onderdeel is van de dienstverlening:} Merk op: de beveiliging van de software in de acceptatie- en productieomgeving kan niet door ICTU getest worden. Deze test moet de opdrachtgevende organisatie of de beheerorganisatie uitvoeren. ## Toegankelijkheidstesten @@ -310,7 +310,7 @@ Issues die voortkomen uit usability-testen worden opgenomen in Jira met het labe Technische schuld zijn eigenschappen van de software die de lange-termijninzetbaarheid en onderhoudbaarheid van de software bedreigen; denk hierbij aan hoge complexiteit, lage testdekking, ontbrekende testsoorten en ontbrekende documentatie. -Als het Scrumteam of de kwaliteitsmanager constateert dat er technische schuld is, markeert de kwaliteitsmanager deze technische schuld in Quality-time als zodanig om te voorkomen dat de technische schuld ongemerkt verder toeneemt. Vervolgens vraagt de kwaliteitsmanager het Scrumteam, in overleg met de software delivery manager, om de omvang van de technische schuld in te schatten in user-storypunten. Vervolgens wordt een plan gemaakt om de technische schuld in een beheerst tempo - de ontwikkeling/onderhoud van de software moet wel doorgang vinden - weg te werken. Uitgangspunt is ongeveer 10% van de user-storypunten die het Scrumteam normaal in een sprint realiseert; dit kan in principe zonder overleg met de opdrachtgever, omdat het leveren van kwaliteit onderdeel van het werk is. +Als het Scrumteam of de kwaliteitsmanager constateert dat er technische schuld is, markeert de kwaliteitsmanager deze technische schuld in Quality-time als zodanig om te voorkomen dat de technische schuld ongemerkt verder toeneemt. Vervolgens vraagt de kwaliteitsmanager het Scrumteam, in overleg met de software delivery manager, om de omvang van de technische schuld in te schatten in user-storypunten. Vervolgens wordt een plan gemaakt om de technische schuld in een beheerst tempo - de ontwikkeling/onderhoud van de software moet wel doorgang vinden - weg te werken. Uitgangspunt is ongeveer 10% van de user-storypunten die het Scrumteam normaal in een sprint realiseert; dit kan in principe zonder overleg met de opdrachtgevende organisatie, omdat het leveren van kwaliteit onderdeel van het werk is. ## Beheer diff --git a/Content/Templates/NFE/Template-Inhoud.md b/Content/Templates/NFE/Template-Inhoud.md index b77f8229..4165141b 100644 --- a/Content/Templates/NFE/Template-Inhoud.md +++ b/Content/Templates/NFE/Template-Inhoud.md @@ -178,7 +178,7 @@ BIO en SSD bevatten ook een aantal maatregelen ten aanzien van software en/of de | 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} | {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} | {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} | {bewijs} | -| 13 | De maximale sessieduur en maximale inactiviteit zijn door (of namens) de opdrachtgever in te stellen. De instelbare waarden zijn per default begrenst op 10 uur (sessieduur) en 15 minuten (inactiviteit). Alleen op expliciet aangeven van de opdrachtgever kan hiervan worden afgeweken | {prio} | {rationale} | {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} | {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} | {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} | {bewijs} | | 16 | Applicaties hebben geen run-time afhankelijkheid van externe codebronnen | {prio} | {rationale} | {bewijs} | diff --git a/Content/Templates/PvA-Realisatiefase/Over-dit-document.md b/Content/Templates/PvA-Realisatiefase/Over-dit-document.md index 83ce393a..dbe0374d 100644 --- a/Content/Templates/PvA-Realisatiefase/Over-dit-document.md +++ b/Content/Templates/PvA-Realisatiefase/Over-dit-document.md @@ -6,7 +6,7 @@ Bij de uitvoering van softwareontwikkelprojecten hanteert ICTU de $KWALITEITSAAN Tijdens de voorfase {voorfaseproject} zijn de volgende activiteiten uitgevoerd: -1. Vaststellen of het mogelijk is om binnen de door de opdrachtgever gestelde kaders productierijpe software op te leveren {en operationeel te beheren} met de gevraagde functionaliteit en kwaliteit, en zo ja, onder welke randvoorwaarden. Hierbij wordt gekeken naar: +1. Vaststellen of het mogelijk is om binnen de door {de opdrachtgevende organisatie} gestelde kaders productierijpe software op te leveren {en operationeel te beheren} met de gevraagde functionaliteit en kwaliteit, en zo ja, onder welke randvoorwaarden. Hierbij wordt gekeken naar: a. techniek (zoals platform, voortbrengingsproces software en koppelingen), a. scope, a. planning, diff --git a/Content/Templates/PvA-Realisatiefase/Template-Inhoud.md b/Content/Templates/PvA-Realisatiefase/Template-Inhoud.md index adab2df6..2d175061 100644 --- a/Content/Templates/PvA-Realisatiefase/Template-Inhoud.md +++ b/Content/Templates/PvA-Realisatiefase/Template-Inhoud.md @@ -20,7 +20,7 @@ ICTU levert de volgende producten en diensten op: a. een actuele versie van de kwaliteitsrapportage, a. {eventueel bijgewerkte andere documentatie waarvoor ICTU verantwoordelijk en/of penvoerder is, zoals testplannen en kwaliteitsplan}. -{Als operationeel beheer onderdeel is van de dienstverlening: Het DevOps-team voert operationele beheertaken uit, conform overeengekomen kwaliteitsniveaus (quality of services). Hiertoe maakt het project beheerafspraken met de opdrachtgever en de beheerorganisatie en legt deze vast in een dossier afspraken en procedures (DAP). Het vastleggen en rapporteren van informatie over de software tijdens het gebruik en over de uitgevoerde beheeractiviteiten kan hiervan deel uitmaken. De afspraken zijn afgestemd op het beheerplan van de beheerorganisatie, waarin is beschreven hoe de verschillende vormen van beheer van de applicaties en de infrastructuur worden uitgevoerd.} +{Als operationeel beheer onderdeel is van de dienstverlening: Het DevOps-team voert operationele beheertaken uit, conform overeengekomen kwaliteitsniveaus (quality of services). Hiertoe maakt het project beheerafspraken met de opdrachtgevende organisatie en de beheerorganisatie en legt deze vast in een dossier afspraken en procedures (DAP). Het vastleggen en rapporteren van informatie over de software tijdens het gebruik en over de uitgevoerde beheeractiviteiten kan hiervan deel uitmaken. De afspraken zijn afgestemd op het beheerplan van de beheerorganisatie, waarin is beschreven hoe de verschillende vormen van beheer van de applicaties en de infrastructuur worden uitgevoerd.} {Als operationeel en/of applicatiebeheer onderdeel is van de dienstverlening: beschrijf wanneer en hoe de dienstverlening eindigt of verlengd wordt. Bijvoorbeeld, geef aan wat de minimale hoeveelheid aan ontwikkel- en onderhoudwerk is waarbij ICTU nog een geschikte partij is om het operationeel en applicatiebeheer uit te voeren.} @@ -32,25 +32,25 @@ Binnen de scope van de opdracht valt de {ontwikkeling en/of het onderhoud} van { * Engineering tools voor versiebeheer (GitLab of Azure DevOps), bouwen en testen (Azure DevOps, GitLab en/of Jenkins), kwaliteitscontrole (SonarQube), beveiligingscontrole (SonarQube, OWASP Dependency Checker, OWASP ZAP, OpenVAS), toegankelijkheid (Axe), performancetesten (JMeter) en integrale kwaliteitsrapportage (Quality-time), * {Als operationeel beheer onderdeel is van de dienstverlening:} Uitrollen in de productieomgeving (Ansible), container registry (Harbor), performance monitoring (APM), security monitoring ({vul aan met concreet product}), controle van kwetsbaarheden in frameworks ({vul aan met concreet product}), controle van images van containers (Trivy), registratie van incidenten bij gebruik en beheer (Topdesk of Jira). * Backlog management tools (Jira en/of Azure DevOps), -* Beveiligings- en performancetesten in de ICTU-testomgevingen. ICTU voert deze tests uit voordat een nieuwe versie van de software wordt opgeleverd. {Beschrijf hier eventuele andere afspraken met opdrachtgever}. +* Beveiligings- en performancetesten in de ICTU-testomgevingen. ICTU voert deze tests uit voordat een nieuwe versie van de software wordt opgeleverd. {Beschrijf hier eventuele andere afspraken met de opdrachtgevende organisatie}. {Als operationeel beheer geen onderdeel is van de dienstverlening:} Buiten de scope van de opdracht valt: * Acceptatie- en productieomgevingen en de installatie van de software op acceptatie- en productieomgevingen, -* Beveiligings- en performancetesten in acceptatie- en productieomgevingen, die onder verantwoordelijkheid van de opdrachtgever worden uitgevoerd, +* Beveiligings- en performancetesten in acceptatie- en productieomgevingen, die onder verantwoordelijkheid van de opdrachtgevende organisatie worden uitgevoerd, * Keten- en integratietesten met aanpalende systemen in acceptatie- en productieomgevingen, * Testen met (geanonimiseerde) productiedata, * Beheeractiviteiten door ICTU. # Werkwijze -Het succes van het uit te voeren realisatietraject is sterk afhankelijk van de beschikbaarheid en inzet van alle betrokkenen. Deze betrokkenheid dient daarom voor aanvang van het project expliciet te worden geborgd door de betrokken organisaties. Dit zal door de projectleider ICTU en {opdrachtgever} gemonitord worden. +Het succes van het uit te voeren realisatietraject is sterk afhankelijk van de beschikbaarheid en inzet van alle betrokkenen. Deze betrokkenheid dient daarom voor aanvang van het project expliciet te worden geborgd door de betrokken organisaties. Dit zal door de projectleider ICTU en {de opdrachtgevende organisatie} gemonitord worden. ## Scrum-aanpak Tijdens dit project wordt agile gewerkt volgens de Scrum-aanpak. ICTU propageert de kernwaarden van Scrum. Dit vertaalt zich concreet in: -* Een Scrumteam, bestaande uit een product owner, door {opdrachtgever} aangesteld, die de uiteindelijke inhoudelijke keuzes maakt, en ontwikkelaars (zoals programmeurs, testers en ontwerpers) en een Scrummaster, door ICTU aangesteld. +* Een Scrumteam, bestaande uit een product owner, door {de opdrachtgevende organisatie} aangesteld, die de uiteindelijke inhoudelijke keuzes maakt, en ontwikkelaars (zoals programmeurs, testers en ontwerpers) en een Scrummaster, door ICTU aangesteld. * Een proces met sprints van {twee of drie} weken waarin de Scrumactiviteiten sprint planning, sprint refinement, daily scrum, sprint demonstratie/review en retrospective plaatsvinden. * Een definition of ready en een definition of done voor respectievelijk het beginnen en afronden van werk. * Een product backlog en een sprint backlog. @@ -79,9 +79,9 @@ Voor een goede start wordt er, bij aanvang van de realisatiefase, een kick-off g ## Samenwerking -{Opdrachtgever/partijen} en ICTU werken gezamenlijk aan de op te leveren software in een Scrumteam. Voor een goed resultaat is het van belang dat er minimaal {aantal} {dagen/dagdelen} per week door alle partijen wordt samengewerkt. {partij} stelt hiervoor {fysieke en/of online} ruimte en samenwerkhulpmiddelen beschikbaar; projectmedewerkers zorgen zelf voor een laptop. {Als met hulpmiddelen van ICTU wordt gewerkt: Om deze bij ICTU te gebruiken moeten de laptops voldoen aan de bij ICTU geldende beveiligingsnormen, welke zijn opgenomen in het ICTU-voorschrift Zakelijk gebruik ICT-diensten en voorzieningen.} +{Opdrachtgevende organisatie, andere partijen} en ICTU werken gezamenlijk aan de op te leveren software in een Scrumteam. Voor een goed resultaat is het van belang dat er minimaal {aantal} {dagen/dagdelen} per week door alle partijen wordt samengewerkt. {partij} stelt hiervoor {fysieke en/of online} ruimte en samenwerkhulpmiddelen beschikbaar; projectmedewerkers zorgen zelf voor een laptop. {Als met hulpmiddelen van ICTU wordt gewerkt: Om deze bij ICTU te gebruiken moeten de laptops voldoen aan de bij ICTU geldende beveiligingsnormen, welke zijn opgenomen in het ICTU-voorschrift Zakelijk gebruik ICT-diensten en voorzieningen.} -Vertegenwoordigers van het project nemen deel aan de volgende overleggen met de opdrachtgever en de beheerorganisatie: +Vertegenwoordigers van het project nemen deel aan de volgende overleggen met {de opdrachtgevende organisatie} en de beheerorganisatie: * het architectuuroverleg, * het informatiebeveiligingsoverleg, * het beheeroverleg, @@ -93,28 +93,28 @@ Vertegenwoordigers van het project nemen deel aan de volgende overleggen met de ## Oplevering software -De realisatiefase bestaat uit {aantal} sprints. Tijdens elke sprint verwerkt het Scrumteam door de product owner geselecteerde functionaliteit in de software. Geselecteerde functionaliteit die niet afkomt tijdens de sprint kan door de product owner opnieuw geselecteerd worden voor de volgende sprint, of voor een latere sprint. Als er na afronding van de realisatiefase nieuwe wensen of fouten aan het licht komen, dan kan {opdrachtgever} deze later alsnog verwerken of ICTU vragen dit in een eventuele vervolgopdracht uit te voeren. -{Beschrijf hier de afspraken tussen ICTU en opdrachtgever over de opzet van vrijgaveadvies, release notes en goedkeuringsproces.} +De realisatiefase bestaat uit {aantal} sprints. Tijdens elke sprint verwerkt het Scrumteam door de product owner geselecteerde functionaliteit in de software. Geselecteerde functionaliteit die niet afkomt tijdens de sprint kan door de product owner opnieuw geselecteerd worden voor de volgende sprint, of voor een latere sprint. Als er na afronding van de realisatiefase nieuwe wensen of fouten aan het licht komen, dan kan {de opdrachtgevende organisatie} deze later alsnog verwerken of ICTU vragen dit in een eventuele vervolgopdracht uit te voeren. +{Beschrijf hier de afspraken tussen ICTU en de opdrachtgevende organisatie over de opzet van vrijgaveadvies, release notes en goedkeuringsproces.} ## Kwaliteitsbeheersing De kwaliteitsbeheersing is door ICTU beschreven in het Kwaliteitsplan. Eén van de kwaliteitsmaatregelen is dat ICTU een geautomatiseerd kwaliteitssysteem (Quality-time) inricht dat de kwaliteit van de software en het ontwikkelproces bewaakt. De ICTU-kwaliteitsmanager configureert de metrieken in Quality-time en bewaakt de metingen. -## Inzet {opdrachtgever/partijen} +## Inzet {opdrachtgevende organisatie/andere partijen} -Betrokkenheid van inhoudsdeskundigen van {opdrachtgever/partijen} is randvoorwaardelijk voor de uitvoering van de opdracht. Van de betrokken medewerkers van deze organisatie{s} wordt het volgende verwacht: +Betrokkenheid van inhoudsdeskundigen van {opdrachtgevende organisatie/andere partijen} is randvoorwaardelijk voor de uitvoering van de opdracht. Van de betrokken medewerkers van deze organisatie{s} wordt het volgende verwacht: * Actief bijdragen aan workshops en demo's; * Buiten de workshops uitzoeken van onduidelijkheden en binnen de eigen organisatie(s) op zoek gaan naar antwoorden; -* Opstellen, onderhouden en/of reviewen van documenten namens opdrachtgever. +* Opstellen, onderhouden en/of reviewen van documenten namens de opdrachtgevende organisatie. -Onderstaand is de verwachte inzet van {opdrachtgever/partijen} voor de uitvoering van dit plan van aanpak (één persoon kan eventueel meer dan één rol vervullen): +Onderstaand is de verwachte inzet van per rol van {opdrachtgevende organisatie/andere partijen} voor de uitvoering van dit plan van aanpak (één persoon kan eventueel meer dan één rol vervullen): {Selecteer de juiste rollen en vul aan, vul ook de juiste verantwoordelijkheden in, onderstaande is een eerste opzet met zoveel mogelijk rollen} | Rollen | Verwachte inzet per week | Verantwoordelijkheden | |:----------------------------------------------|:-------------------------|:-----------------------------------------------------------------------------------------------------------------------------| -| Projectleider (Opdrachtgever) | {aantal} dagen | Bespreken voortgang en eventuele exceptions met de projectleider (opdrachtnemer), deelname aan demo's en eventuele workshops | +| Projectleider ({opdrachtgevende organisatie}) | {aantal} dagen | Bespreken voortgang en eventuele exceptions met de projectleider (opdrachtnemer), deelname aan demo's en eventuele workshops | | Product owner | {aantal} dagen | Prioritering user stories, sprintplanning, demo, onderhouden backlog | | Business analist | {aantal} dagen | Epics opstellen voor de product backlog, eventueel uitgewerkt in user stories | | Architect | {aantal} dagen | Bewaken en onderhouden van de softwarearchitectuur | @@ -138,7 +138,7 @@ Omdat ICTU tijdens het project de software, inclusief documentatie, regelmatig o # Planning en doorlooptijd -De start van het project vindt uiterlijk {aantal} weken na ondertekening van het voorstel inclusief projectovereenkomst plaats. In deze periode bemensen zowel ICTU als {opdrachtgever} het project. Daarbij is rekening gehouden met de doorlooptijd van de werving en selectie van de geschikte mensen. +De start van het project vindt uiterlijk {aantal} weken na ondertekening van het voorstel inclusief projectovereenkomst plaats. In deze periode bemensen zowel ICTU als {de opdrachtgevende organisatie} het project. Daarbij is rekening gehouden met de doorlooptijd van de werving en selectie van de geschikte mensen. De verwachte doorlooptijd van de uitvoering van dit plan van aanpak is {aantal} weken. @@ -161,14 +161,14 @@ Met een eventuele vakantieperiode is nog geen rekening gehouden, dit zal direct Voor de uitvoering van de realisatiefase gelden de volgende randvoorwaarden: -| Nr | Randvoorwaarde | -|:-------------|:----------------------------------------------------------------------------------------------------------------------------------------------| -| R01 | De vereiste inzet van betrokkenen van {opdrachtgever/partijen} is georganiseerd en gegarandeerd. | -| R02 | De product owner is gemandateerd om zelfstandig besluiten te nemen over de functionaliteit van de software. | -| R03 | Er is een afgestemde en afgesproken werkwijze tussen {opdrachtgever}, {beheerorganisatie} en ICTU. Deze is in lijn met de $KWALITEITSAANPAK$. | -| R04 | De voorfaseproducten {producten} zijn beschikbaar voor aanvang van de realisatiefase. | -| R05 | Koppelvlakbeschrijvingen van aanpalende systemen zijn beschikbaar. | -| {volgnummer} | {randvoorwaarde} | +| Nr | Randvoorwaarde | +|:-------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------| +| R01 | De vereiste inzet van betrokkenen van {de opdrachtgevende organisatie/andere partijen} is georganiseerd en gegarandeerd. | +| R02 | De product owner is gemandateerd om zelfstandig besluiten te nemen over de functionaliteit van de software. | +| R03 | Er is een afgestemde en afgesproken werkwijze tussen {opdrachtgevende organisatie}, {beheerorganisatie} en ICTU. Deze is in lijn met de $KWALITEITSAANPAK$. | +| R04 | De voorfaseproducten {producten} zijn beschikbaar voor aanvang van de realisatiefase. | +| R05 | Koppelvlakbeschrijvingen van aanpalende systemen zijn beschikbaar. | +| {volgnummer} | {randvoorwaarde} | # Projectrisico’s @@ -178,17 +178,17 @@ De risico’s worden door het project bijgehouden in het risicolog. De risico’ {Deze tabel dient op basis van het concrete project en voorstel aangepast te worden.} -| Projectrisico | Maatregel | -|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Verwachtingen over dit project tussen verschillende partijen ({partijen}, ICTU) kunnen niet waargemaakt worden, waardoor vertraging ontstaat | Wekelijks projectoverleg, samenwerken door middel van werkgroepen en fysiek bij elkaar komen, kick-off met alle betrokkenen waarbij {opdrachtgever} de productvisie uiteenzet. | -| Scope-uitbreiding, gebrek aan focus | Scope bewaken, alleen de scope uitbreiden als dit noodzakelijk is voor {doel} | -| Onvoldoende bemensing door vakanties | Rekening houden met langere doorlooptijd dan de (te) eenvoudige rekensom suggereert. | -| {Bij DevOps werkwijze} Onduidelijkheid over de verdeling van verantwoordelijkheden tussen DevOps-team en beheerorganisatie (incident management, backup & restore, etc.) | Afspraken over onderlinge samenwerking vastleggen in een dossier afspraken en procedures (DAP). | -| {risico} | {maatregel} | +| Projectrisico | Maatregel | +|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Verwachtingen over dit project tussen verschillende partijen ({andere partijen}, ICTU) kunnen niet waargemaakt worden, waardoor vertraging ontstaat | Wekelijks projectoverleg, samenwerken door middel van werkgroepen en fysiek bij elkaar komen, kick-off met alle betrokkenen waarbij opdrachtgever of product owner de productvisie uiteenzet. | +| Scope-uitbreiding, gebrek aan focus | Scope bewaken, alleen de scope uitbreiden als dit noodzakelijk is voor {doel} | +| Onvoldoende bemensing door vakanties | Rekening houden met langere doorlooptijd dan de (te) eenvoudige rekensom suggereert. | +| {Bij DevOps werkwijze} Onduidelijkheid over de verdeling van verantwoordelijkheden tussen DevOps-team en beheerorganisatie (incident management, backup & restore, etc.) | Afspraken over onderlinge samenwerking vastleggen in een dossier afspraken en procedures (DAP). | +| {risico} | {maatregel} | # Verwachte inzet ICTU -Onderstaand is de verwachte inzet van ICTU voor de uitvoering van dit plan van aanpak: +Onderstaand is de verwachte inzet per rol van ICTU voor de uitvoering van dit plan van aanpak: {Selecteer de rollen die nodig zijn en vul ze aan. Vul de juiste verantwoordelijkheden in. De onderstaande tabel is een eerste opzet met veel voorkomende rollen.} diff --git a/Content/Templates/PvA-Realisatiefase/Uitgangspunten.md b/Content/Templates/PvA-Realisatiefase/Uitgangspunten.md index b78ebb3e..6cfc58b8 100644 --- a/Content/Templates/PvA-Realisatiefase/Uitgangspunten.md +++ b/Content/Templates/PvA-Realisatiefase/Uitgangspunten.md @@ -2,9 +2,9 @@ De volgende uitgangspunten zijn van toepassing op dit plan van aanpak: -| Nr | Uitgangspunt | -|:-------------|:----------------------------------------------------------------------------------------------------------------------------------| -| U01 | Het werven van personeel voor het uitvoeren van dit project start na ondertekening van het eveneens verstuurde voorstel inclusief projectovereenkomst door de opdrachtgever. | -| U02 | {opdrachtgever} is verantwoordelijk voor het betrekken van {de andere betrokken partijen} en het tijdig opleveren van reviews. | -| U03 | {opdrachtgever} is verantwoordelijk voor het aanstellen van een product owner met voldoende tijd en mandaat. | -| {volgnummer} | {uitgangspunt} | +| Nr | Uitgangspunt | +|:-------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| U01 | Het werven van personeel voor het uitvoeren van dit project start na ondertekening van het eveneens verstuurde voorstel inclusief projectovereenkomst door {de opdrachtgevende organisatie}. | +| U02 | {de opdrachtgevende organisatie} is verantwoordelijk voor het betrekken van {de andere betrokken partijen} en het tijdig opleveren van reviews. | +| U03 | {de opdrachtgevende organisatie} is verantwoordelijk voor het aanstellen van een product owner met voldoende tijd en mandaat. | +| {volgnummer} | {uitgangspunt} | diff --git a/Content/Templates/PvA-Voorfase/Over-dit-document.md b/Content/Templates/PvA-Voorfase/Over-dit-document.md index e8c62c7b..8f3278ba 100644 --- a/Content/Templates/PvA-Voorfase/Over-dit-document.md +++ b/Content/Templates/PvA-Voorfase/Over-dit-document.md @@ -6,7 +6,7 @@ Bij de uitvoering van softwareontwikkelprojecten hanteert ICTU de $KWALITEITSAAN De voorfase heeft de volgende doelen: -1. Vaststellen of het mogelijk is om binnen de door de opdrachtgever gestelde kaders productierijpe software op te leveren {en operationeel te beheren} met de gevraagde functionaliteit en kwaliteit, en zo ja, onder welke randvoorwaarden. Hierbij wordt gekeken naar: +1. Vaststellen of het mogelijk is om binnen de door {de opdrachtgevende organisatie} gestelde kaders productierijpe software op te leveren {en operationeel te beheren} met de gevraagde functionaliteit en kwaliteit, en zo ja, onder welke randvoorwaarden. Hierbij wordt gekeken naar: a. techniek (zoals platform, voortbrengingsproces software en koppelingen), a. scope, a. planning, diff --git a/Content/Templates/PvA-Voorfase/Template-Inhoud.md b/Content/Templates/PvA-Voorfase/Template-Inhoud.md index 587575da..3d6c2ead 100644 --- a/Content/Templates/PvA-Voorfase/Template-Inhoud.md +++ b/Content/Templates/PvA-Voorfase/Template-Inhoud.md @@ -47,8 +47,8 @@ Het succes van deze voorfase, en van het eventueel later uit te voeren realisati Tijdens dit project wordt zoveel mogelijk agile gewerkt volgens de Scrum-aanpak. Dit vertaalt zich concreet in: -* Eén Scrumteam met medewerkers van {opdrachtgever/partijen} en ICTU werkt minimaal {aantal} dagdelen per week aan de gedefinieerde documenten. -* Er is een product owner door {opdrachtgever} aangesteld die de uiteindelijke inhoudelijke keuzes maakt. +* Eén Scrumteam met medewerkers van {opdrachtgevende organisatie/andere partijen} en ICTU werkt minimaal {aantal} dagdelen per week aan de gedefinieerde documenten. +* Er is een product owner door {de opdrachtgevende organisatie} aangesteld die de uiteindelijke inhoudelijke keuzes maakt. * Voor elk product is een inhoudelijk verantwoordelijke, een penvoerder/schrijver en één of meer reviewers. Alle partijen werken constructief samen. Reviews zijn gericht op kwaliteitsverbeteringen. Waar nodig schrijven reviewers mee aan de documenten. * Nieuwe tussentijdse versies van documenten worden kortcyclisch opgeleverd, elke {termijn}. * Alle tussentijdse versies worden gereviewd door {reviewers} binnen de afgesproken termijn (maximaal {aantal} werkdagen). @@ -65,9 +65,9 @@ Voor een goede start wordt er, bij aanvang van de voorfase, een kick-off georgan ## Samenwerking -{Opdrachtgever/partijen} en ICTU werken gezamenlijk aan de op te leveren documenten in een Scrumteam. Voor een goed resultaat is het van belang dat er minimaal {aantal} {dagen/dagdelen} per week door alle partijen wordt samengewerkt. {partij} stelt hiervoor {fysieke en/of online} ruimte en samenwerkhulpmiddelen beschikbaar; projectmedewerkers zorgen zelf voor een laptop. {Als met hulpmiddelen van ICTU wordt gewerkt: Om deze bij ICTU te gebruiken moeten de laptops voldoen aan de bij ICTU geldende beveiligingsnormen, welke zijn opgenomen in het ICTU-voorschrift Zakelijk gebruik ICT-diensten en voorzieningen.} +{Opdrachtgevende organisatie/andere partijen} en ICTU werken gezamenlijk aan de op te leveren documenten in een Scrumteam. Voor een goed resultaat is het van belang dat er minimaal {aantal} {dagen/dagdelen} per week door alle partijen wordt samengewerkt. {partij} stelt hiervoor {fysieke en/of online} ruimte en samenwerkhulpmiddelen beschikbaar; projectmedewerkers zorgen zelf voor een laptop. {Als met hulpmiddelen van ICTU wordt gewerkt: Om deze bij ICTU te gebruiken moeten de laptops voldoen aan de bij ICTU geldende beveiligingsnormen, welke zijn opgenomen in het ICTU-voorschrift Zakelijk gebruik ICT-diensten en voorzieningen.} -Vertegenwoordigers van het project nemen deel aan de volgende overleggen met de opdrachtgever en de beheerorganisatie: +Vertegenwoordigers van het project nemen deel aan de volgende overleggen met vertegenwoordigers van {de opdrachtgevende organisatie} en de beheerorganisatie: * het architectuuroverleg, * het informatiebeveiligingsoverleg, * het beheeroverleg, @@ -79,7 +79,7 @@ Vertegenwoordigers van het project nemen deel aan de volgende overleggen met de ## Oplevering producten -De voorfase is op basis van sprints ingericht. Aan het einde van elke sprint zijn alle tot dan toe opgedane inzichten verwerkt in de producten. Na de laatste sprint levert ICTU het geheel op aan de opdrachtgever. +De voorfase is op basis van sprints ingericht. Aan het einde van elke sprint zijn alle tot dan toe opgedane inzichten verwerkt in de producten. Na de laatste sprint levert ICTU het geheel op aan {de opdrachtgevende organisatie}. ## Kwaliteitsbeheersing @@ -92,15 +92,15 @@ De experts reviewen op zaken zoals: * interne en onderlinge consistentie; * volledigheid. -## Inzet {opdrachtgever/partijen} +## Inzet {opdrachtgevende organisatie/andere partijen} -Betrokkenheid van inhoudsdeskundigen van {opdrachtgever/partijen} is randvoorwaardelijk voor de uitvoering van de opdracht. Van de betrokken medewerkers van deze organisatie{s} wordt het volgende verwacht: +Betrokkenheid van inhoudsdeskundigen van {opdrachtgevende organisatie/andere partijen} is randvoorwaardelijk voor de uitvoering van de opdracht. Van de betrokken medewerkers van deze organisatie{s} wordt het volgende verwacht: -* De producten worden opgesteld tijdens verschillende werksessies. Aanwezigheid bij de werksessies (welke zoveel mogelijk tijdens de dagdelen waarop {opdrachtgever/partijen} en ICTU samenwerken worden gepland) en indien gewenst aan vervolgafspraken in dat kader; +* De producten worden opgesteld tijdens verschillende werksessies. Aanwezigheid bij de werksessies (welke zoveel mogelijk tijdens de dagdelen waarop {opdrachtgevende organisatie/andere partijen} en ICTU samenwerken worden gepland) en indien gewenst aan vervolgafspraken in dat kader; * Actief bijdragen aan het schrijven en reviewen van de producten; * Buiten de workshops uitzoeken van onduidelijkheden en binnen de eigen organisatie(s) op zoek gaan naar antwoorden. -Onderstaand is de verwachte inzet van {opdrachtgever/partijen} voor de uitvoering van dit plan van aanpak (één persoon kan eventueel meer dan één rol vervullen): +Onderstaand is de verwachte inzet per rol van {opdrachtgevende organisatie/andere partijen} voor de uitvoering van dit plan van aanpak (één persoon kan eventueel meer dan één rol vervullen): {Selecteer de juiste rollen en vul aan, vul ook de juiste verantwoordelijkheden in, onderstaande is een eerste opzet met zoveel mogelijk rollen} @@ -110,11 +110,11 @@ Onderstaand is de verwachte inzet van {opdrachtgever/partijen} voor de uitvoerin | Privacy-expert | {aantal} dagen | Opstellen PIA, reviewen {documenten} | | Infrastructuurarchitect | {aantal} dagen | Opstellen infrastructuurarchitectuur, reviewen SAD, NFE en IB-plan | | Architect | {aantal} dagen | Richting geven aan architectuur, opstellen PSA, reviewen SAD, NFE en infrastructuurarchitectuur | -| Testmanager | {aantal} dagen | Uitvoeren PRA, opstellen mastertestplan, reviewen kwaliteitsplan, testplan softwarerealisatie | +| Testmanager | {aantal} dagen | Uitvoeren PRA, opstellen mastertestplan, reviewen kwaliteitsplan, detailtestplan softwarerealisatie | | Diverse inhoudelijk deskundigen | {aantal} dagen | Eventuele betrokkenheid van (eind)gebruikers en belanghebbenden | | Product owner | {aantal} dagen | Inhoudelijk sturing / prioritering, opstellen backlog, NFE, minimal viable product, reviewen GFO en prototype | -| Projectleider (Opdrachtgever) | {aantal} dagen | Bespreken voortgang en eventuele exceptions met de projectleiders van opdrachtnemer, deelname aan kick-off en eventuele workshops | -| Projectleider (beheerorganisatie) | {aantal} dagen | Opstellen plan van aanpak realisatiefase voor het inrichten van technisch en operationeel beheer, deelname aan kick-off en eventuele workshops | +| Projectleider ({opdrachtgevende organisatie}) | {aantal} dagen | Bespreken voortgang en eventuele exceptions met de projectleiders van opdrachtnemer, deelname aan kick-off en eventuele workshops | +| Projectleider ({beheerorganisatie}) | {aantal} dagen | Opstellen plan van aanpak realisatiefase voor het inrichten van technisch en operationeel beheer, deelname aan kick-off en eventuele workshops | | Diverse technisch en inhoudelijk specialisten | ad hoc | Inzet op ad-hocbasis ter ondersteuning van de andere rollen | ## Projectafsluiting @@ -125,7 +125,7 @@ Omdat ICTU tijdens het project de documenten regelmatig oplevert is er geen spec {Verwijs naar dit hoofdstuk in hoofdstuk 5 van het voorstel inclusief POK} -De start van het project vindt uiterlijk {aantal} weken na ondertekening van het eveneens verstuurde voorstel inclusief projectovereenkomst plaats. In deze periode bemensen zowel ICTU als {opdrachtgever} het project. Daarbij is rekening gehouden met de doorlooptijd van de werving en selectie van de geschikte mensen. +De start van het project vindt uiterlijk {aantal} weken na ondertekening van het eveneens verstuurde voorstel inclusief projectovereenkomst plaats. In deze periode bemensen zowel ICTU als {de opdrachtgevende organisatie} het project. Daarbij is rekening gehouden met de doorlooptijd van de werving en selectie van de geschikte mensen. De verwachte doorlooptijd van de uitvoering van deze voorfase is {aantal} weken. @@ -149,14 +149,14 @@ NB: Onderdeel van het afronden en afsluiten van de voorfase is een GO/NO GO voor Voor de uitvoering van de voorfase gelden de volgende randvoorwaarden: -| Nr | Randvoorwaarde | -|:-------------|:----------------------------------------------------------------------------------------------------------------------------------------------| -| R01 | De vereiste inzet van betrokkenen van {opdrachtgever/partijen} is georganiseerd en gegarandeerd. | -| R02 | De product owner is gemandateerd om zelfstandig besluiten te nemen over de inhoud van de producten. | -| R03 | Er is een afgestemde en afgesproken werkwijze tussen {opdrachtgever}, {beheerorganisatie} en ICTU. Deze is in lijn met de $KWALITEITSAANPAK$. | -| R04 | De producten {producten} zijn beschikbaar voor aanvang van de voorfase. | -| R05 | Koppelvlakbeschrijvingen van aanpalende systemen zijn beschikbaar. | -| {volgnummer} | {randvoorwaarde} | +| Nr | Randvoorwaarde | +|:-------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------| +| R01 | De vereiste inzet van betrokkenen van {opdrachtgevende organisatie/andere partijen} is georganiseerd en gegarandeerd. | +| R02 | De product owner is gemandateerd om zelfstandig besluiten te nemen over de inhoud van de producten. | +| R03 | Er is een afgestemde en afgesproken werkwijze tussen {opdrachtgevende organisatie}, {beheerorganisatie} en ICTU. Deze is in lijn met de $KWALITEITSAANPAK$. | +| R04 | De producten {producten} zijn beschikbaar voor aanvang van de voorfase. | +| R05 | Koppelvlakbeschrijvingen van aanpalende systemen zijn beschikbaar. | +| {volgnummer} | {randvoorwaarde} | # Projectrisico’s @@ -164,16 +164,16 @@ De onderstaande projectrisico’s, die het succes van de voorfase kunnen belemme {Deze tabel dient op basis van het concrete project en voorstel aangepast te worden.} -| Projectrisico | Maatregel | -|:---------------------------------------------------------------------------------------------------------------------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Verwachtingen over dit project tussen verschillende partijen ({partijen}, ICTU) kunnen niet waargemaakt worden, waardoor vertraging ontstaat | Wekelijks projectoverleg, samenwerken door middel van werkgroepen en fysiek bij elkaar komen, kick-off met alle betrokkenen waarbij {opdrachtgever} het doel van de voorfase uiteenzet. | -| Scope-uitbreiding, gebrek aan focus | Scope voorfase bewaken, alleen de scope uitbreiden als dit noodzakelijk is voor {doel} | -| Onvoldoende bemensing door vakanties | Rekening houden met langere doorlooptijd dan de (te) eenvoudige rekensom suggereert. | -| {risico} | {maatregel} | +| Projectrisico | Maatregel | +|:---------------------------------------------------------------------------------------------------------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Verwachtingen over dit project tussen verschillende partijen ({partijen}, ICTU) kunnen niet waargemaakt worden, waardoor vertraging ontstaat | Wekelijks projectoverleg, samenwerken door middel van werkgroepen en fysiek bij elkaar komen, kick-off met alle betrokkenen waarbij de opdrachtgever het doel van de voorfase uiteenzet. | +| Scope-uitbreiding, gebrek aan focus | Scope voorfase bewaken, alleen de scope uitbreiden als dit noodzakelijk is voor {doel} | +| Onvoldoende bemensing door vakanties | Rekening houden met langere doorlooptijd dan de (te) eenvoudige rekensom suggereert. | +| {risico} | {maatregel} | # Verwachte inzet ICTU -Onderstaand is de verwachte inzet van ICTU voor de uitvoering van dit plan van aanpak: +Onderstaand is de verwachte inzet per rol van ICTU voor de uitvoering van dit plan van aanpak: {Selecteer de rollen die nodig zijn en vul ze aan. Vul de juiste verantwoordelijkheden in. De onderstaande tabel is een eerste opzet met veel voorkomende rollen.} @@ -197,4 +197,4 @@ Onderstaand is de verwachte inzet van ICTU voor de uitvoering van dit plan van a {Voor de begroting wordt uitgegaan van een gemiddeld bruto tarief. De werkelijke kosten worden bekend als de projectmedewerkers bekend zijn. Wanneer overschrijding van het budget dreigt (bijvoorbeeld vanwege substantieel hogere tarieven), wordt dit tijdig met de opdrachtgever besproken.} -{Er moet budget gereserveerd worden voor het werven van externe medewerkers voor de voorfase en voor een eventuele overgangsfase tussen voorfase en realisatie. Dit laatste voor het geval er nog geen opdracht is en de opdrachtgever nog niet betaalt, terwijl ICTU wel kosten maakt (bijvoorbeeld voor het vasthouden van ingehuurde deskundigen voor de realisatiefase).} +{Er moet budget gereserveerd worden voor het werven van externe medewerkers voor de voorfase en voor een eventuele overgangsfase tussen voorfase en realisatie. Dit laatste voor het geval er nog geen opdracht is en de opdrachtgevende organisatie nog niet betaalt, terwijl ICTU wel kosten maakt (bijvoorbeeld voor het vasthouden van ingehuurde deskundigen voor de realisatiefase).} diff --git a/Content/Templates/PvA-Voorfase/Uitgangspunten.md b/Content/Templates/PvA-Voorfase/Uitgangspunten.md index 62a605c5..6f55cd5b 100644 --- a/Content/Templates/PvA-Voorfase/Uitgangspunten.md +++ b/Content/Templates/PvA-Voorfase/Uitgangspunten.md @@ -4,7 +4,7 @@ De volgende uitgangspunten zijn van toepassing op dit plan: | Nr | Uitgangspunt | |:-------------|:----------------------------------------------------------------------------------------------------------------------------------| -| U01 | Het werven van personeel voor het uitvoeren van dit project start na ondertekening van het eveneens verstuurde voorstel inclusief projectovereenkomst door de opdrachtgever. | -| U02 | {opdrachtgever} is verantwoordelijk voor het betrekken van eventuele andere partijen bij het project en het tijdig opleveren van reviews. | -| U03 | {opdrachtgever} is verantwoordelijk voor het aanstellen van een product owner met voldoende tijd en mandaat. | +| U01 | Het werven van personeel voor het uitvoeren van dit project start na ondertekening van het eveneens verstuurde voorstel inclusief projectovereenkomst door {de opdrachtgevende organisatie}. | +| U02 | {de opdrachtgevende organisatie} is verantwoordelijk voor het betrekken van eventuele andere partijen bij het project en het tijdig opleveren van reviews. | +| U03 | {de opdrachtgevende organisatie} is verantwoordelijk voor het aanstellen van een product owner met voldoende tijd en mandaat. | | {volgnummer} | {uitgangspunt} | diff --git a/Content/Templates/SAD/Template-Inhoud.md b/Content/Templates/SAD/Template-Inhoud.md index 8e6b20cb..515ae486 100644 --- a/Content/Templates/SAD/Template-Inhoud.md +++ b/Content/Templates/SAD/Template-Inhoud.md @@ -2,7 +2,7 @@ Dit hoofdstuk bevat de ontwerpbeslissingen die betrekking hebben op de software. Zij zijn de basis voor de in dit document uitgewerkte software-architectuur. -{Dit hoofdstuk bevat een aantal veelgebruikte ontwerpbeslissingen. Waar nodig moeten ze worden aangevuld of aangepast, waarbij de relaties met de door opdrachtgever en beheerorganisatie gedefinieerde eisen en architectuurkaders traceerbaar zijn.} +{Dit hoofdstuk bevat een aantal veelgebruikte ontwerpbeslissingen. Waar nodig moeten ze worden aangevuld of aangepast, waarbij de relaties met de door opdrachtgevende organisatie en beheerorganisatie gedefinieerde eisen en architectuurkaders traceerbaar zijn.} ## Ontwerpprincipes diff --git a/Content/Wijzigingsgeschiedenis.md b/Content/Wijzigingsgeschiedenis.md index d177334a..f9f2aee2 100644 --- a/Content/Wijzigingsgeschiedenis.md +++ b/Content/Wijzigingsgeschiedenis.md @@ -5,12 +5,12 @@ * 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": 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 opdrachtgever is om te organiseren dat betrokken partijen informatie aanleveren voor het vrijgaveadvies. +* In M01 "Het project levert in elke fase vastgestelde producten en informatie op": 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 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 M14 "Het project bereidt samen met opdrachtgever en belanghebbenden de realisatie voor" toegevoegd dat bij significante wijzigingen aan de projectkader de voorfase geheel of deels opnieuw wordt uitgevoerd. +* 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 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". -* 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 opdrachtgever en beheerpartij" 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. * Maatregel M35 "Het project hanteert een agile architectuuraanpak" toegevoegd. * De bijlage 'Wijzigingsgeschiedenis' verplaatst naar een los document in PDF- en HTML-formaat. @@ -37,6 +37,7 @@ * 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. ### Versie 3.0.1, 4 april 2023 diff --git a/DocumentDefinitions/Shared/variables.json b/DocumentDefinitions/Shared/variables.json index 89b66c5a..acebb039 100644 --- a/DocumentDefinitions/Shared/variables.json +++ b/DocumentDefinitions/Shared/variables.json @@ -12,7 +12,7 @@ "M11": "M11: ICTU beheert, onderhoudt en implementeert de Kwaliteitsaanpak en kwaliteitsnormen", "M12": "M12: ICTU publiceert nieuwe versies van de Kwaliteitsaanpak en normen periodiek en op een vaste locatie", "M13": "M13: Het project gebruikt ISO-25010 voor de specificatie van productkwaliteitseisen", - "M14": "M14: Het project bereidt samen met opdrachtgever en belanghebbenden de realisatie voor", + "M14": "M14: Het project bereidt samen met opdrachtgevende organisatie en betrokken partijen de realisatie voor", "M16": "M16: Het project gebruikt tools voor vastgestelde taken", "M18": "M18: ICTU biedt ondersteuning voor verplicht gestelde tools", "M19": "M19: ICTU biedt projecten een afgeschermde digitale omgeving",