diff --git a/.dockerignore b/.dockerignore index 7fa671d8..6991f6ad 100644 --- a/.dockerignore +++ b/.dockerignore @@ -1,4 +1,3 @@ -# Ignore everything except the fonts, needed for the wkhtml image, and dependencies, needed for the ka image. +# Ignore everything except the dependencies, needed for the ka image. * -!thirdparty/fonts !requirements.txt diff --git a/.pylintrc b/.pylintrc deleted file mode 100644 index c367b074..00000000 --- a/.pylintrc +++ /dev/null @@ -1,540 +0,0 @@ -[MASTER] - -# A comma-separated list of package or module names from where C extensions may -# be loaded. Extensions are loading into the active Python interpreter and may -# run arbitrary code -extension-pkg-whitelist= - -# Add files or directories to the blacklist. They should be base names, not -# paths. -ignore= - -# Add files or directories matching the regex patterns to the blacklist. The -# regex matches against base names, not paths. -ignore-patterns= - -# Python code to execute, usually for sys.path manipulation such as -# pygtk.require(). -init-hook="from pylint.config import find_pylintrc; import os, sys; sys.path.append(os.path.dirname(find_pylintrc()))" - -# Use multiple processes to speed up Pylint. -jobs=1 - -# List of plugins (as comma separated values of python modules names) to load, -# usually to register additional checkers. -load-plugins= - -# Pickle collected data for later comparisons. -persistent=yes - -# Specify a configuration file. -#rcfile= - -# When enabled, pylint would attempt to guess common misconfiguration and emit -# user-friendly hints instead of false-positive error messages -suggestion-mode=yes - -# Allow loading of arbitrary C extensions. Extensions are imported into the -# active Python interpreter and may run arbitrary code. -unsafe-load-any-extension=yes - - -[MESSAGES CONTROL] - -# Only show warnings with the listed confidence levels. Leave empty to show -# all. Valid levels: HIGH, INFERENCE, INFERENCE_FAILURE, UNDEFINED -confidence= - -# Disable the message, report, category or checker with the given id(s). You -# can either give multiple identifiers separated by comma (,) or put this -# option multiple times (only on the command line, not in the configuration -# file where it should appear only once).You can also use "--disable=all" to -# disable everything first and then reenable specific checks. For example, if -# you want to run only the similarities checker, you can use "--disable=all -# --enable=similarities". If you want to run only the classes checker, but have -# no Warning level messages displayed, use"--disable=all --enable=classes -# --disable=W" -disable=print-statement, - parameter-unpacking, - unpacking-in-except, - old-raise-syntax, - backtick, - long-suffix, - old-ne-operator, - old-octal-literal, - import-star-module-level, - non-ascii-bytes-literal, - raw-checker-failed, - bad-inline-option, - locally-disabled, - locally-enabled, - file-ignored, - suppressed-message, - useless-suppression, - deprecated-pragma, - apply-builtin, - basestring-builtin, - buffer-builtin, - cmp-builtin, - coerce-builtin, - execfile-builtin, - file-builtin, - long-builtin, - raw_input-builtin, - reduce-builtin, - standarderror-builtin, - unicode-builtin, - xrange-builtin, - coerce-method, - delslice-method, - getslice-method, - setslice-method, - no-absolute-import, - old-division, - dict-iter-method, - dict-view-method, - next-method-called, - metaclass-assignment, - indexing-exception, - raising-string, - reload-builtin, - oct-method, - hex-method, - nonzero-method, - cmp-method, - input-builtin, - round-builtin, - intern-builtin, - unichr-builtin, - map-builtin-not-iterating, - zip-builtin-not-iterating, - range-builtin-not-iterating, - filter-builtin-not-iterating, - using-cmp-argument, - eq-without-hash, - div-method, - idiv-method, - rdiv-method, - exception-message-attribute, - invalid-str-codec, - sys-max-int, - bad-python3-import, - deprecated-string-function, - deprecated-str-translate-call, - deprecated-itertools-function, - deprecated-types-field, - next-method-defined, - dict-items-not-iterating, - dict-keys-not-iterating, - dict-values-not-iterating, - bad-continuation - -# Enable the message, report, category or checker with the given id(s). You can -# either give multiple identifier separated by comma (,) or put this option -# multiple time (only on the command line, not in the configuration file where -# it should appear only once). See also the "--disable" option for examples. -enable=c-extension-no-member - - -[REPORTS] - -# Python expression which should return a note less than 10 (10 is the highest -# note). You have access to the variables errors warning, statement which -# respectively contain the number of errors / warnings messages and the total -# number of statements analyzed. This is used by the global evaluation report -# (RP0004). -evaluation=10.0 - ((float(5 * error + warning + refactor + convention) / statement) * 10) - -# Template used to display messages. This is a python new-style format string -# used to format the message information. See doc for all details -#msg-template= - -# Set the output format. Available formats are text, parseable, colorized, json -# and msvs (visual studio).You can also give a reporter class, eg -# mypackage.mymodule.MyReporterClass. -output-format=text - -# Tells whether to display a full report or only the messages -reports=no - -# Activate the evaluation score. -score=yes - - -[REFACTORING] - -# Maximum number of nested blocks for function / method body -max-nested-blocks=5 - -# Complete name of functions that never returns. When checking for -# inconsistent-return-statements if a never returning function is called then -# it will be considered as an explicit return statement and no message will be -# printed. -never-returning-functions=optparse.Values,sys.exit - - -[LOGGING] - -# Logging modules to check that the string format arguments are in logging -# function parameter format -logging-modules=logging - - -[SPELLING] - -# Limits count of emitted suggestions for spelling mistakes -max-spelling-suggestions=4 - -# Spelling dictionary name. Available dictionaries: none. To make it working -# install python-enchant package. -spelling-dict= - -# List of comma separated words that should not be checked. -spelling-ignore-words= - -# A path to a file that contains private dictionary; one word per line. -spelling-private-dict-file= - -# Tells whether to store unknown words to indicated private dictionary in -# --spelling-private-dict-file option instead of raising a message. -spelling-store-unknown-words=no - - -[MISCELLANEOUS] - -# List of note tags to take in consideration, separated by a comma. -notes=FIXME, - XXX, - TODO - - -[TYPECHECK] - -# List of decorators that produce context managers, such as -# contextlib.contextmanager. Add to this list to register other decorators that -# produce valid context managers. -contextmanager-decorators=contextlib.contextmanager - -# List of members which are set dynamically and missed by pylint inference -# system, and so shouldn't trigger E1101 when accessed. Python regular -# expressions are accepted. -generated-members= - -# Tells whether missing members accessed in mixin class should be ignored. A -# mixin class is detected if its name ends with "mixin" (case insensitive). -ignore-mixin-members=yes - -# This flag controls whether pylint should warn about no-member and similar -# checks whenever an opaque object is returned when inferring. The inference -# can return multiple potential results while evaluating a Python object, but -# some branches might not be evaluated, which results in partial inference. In -# that case, it might be useful to still emit no-member and other checks for -# the rest of the inferred objects. -ignore-on-opaque-inference=yes - -# List of class names for which member attributes should not be checked (useful -# for classes with dynamically set attributes). This supports the use of -# qualified names. -ignored-classes=optparse.Values,thread._local,_thread._local - -# List of module names for which member attributes should not be checked -# (useful for modules/projects where namespaces are manipulated during runtime -# and thus existing member attributes cannot be deduced by static analysis. It -# supports qualified module names, as well as Unix pattern matching. -ignored-modules= - -# Show a hint with possible names when a member name was not found. The aspect -# of finding the hint is based on edit distance. -missing-member-hint=yes - -# The minimum edit distance a name should have in order to be considered a -# similar match for a missing member name. -missing-member-hint-distance=1 - -# The total number of similar names that should be taken in consideration when -# showing a hint for a missing member. -missing-member-max-choices=1 - - -[VARIABLES] - -# List of additional names supposed to be defined in builtins. Remember that -# you should avoid to define new builtins when possible. -additional-builtins= - -# Tells whether unused global variables should be treated as a violation. -allow-global-unused-variables=yes - -# List of strings which can identify a callback function by name. A callback -# name must start or end with one of those strings. -callbacks=cb_, - _cb - -# A regular expression matching the name of dummy variables (i.e. expectedly -# not used). -dummy-variables-rgx=_+$|(_[a-zA-Z0-9_]*[a-zA-Z0-9]+?$)|dummy|^ignored_|^unused_ - -# Argument names that match this expression will be ignored. Default to name -# with leading underscore -ignored-argument-names=_.*|^ignored_|^unused_ - -# Tells whether we should check for unused import in __init__ files. -init-import=no - -# List of qualified module names which can have objects that can redefine -# builtins. -redefining-builtins-modules=six.moves,past.builtins,future.builtins - - -[FORMAT] - -# Expected format of line ending, e.g. empty (any line ending), LF or CRLF. -expected-line-ending-format= - -# Regexp for a line that is allowed to be longer than the limit. -ignore-long-lines=^\s*(# )??$ - -# Number of spaces of indent required inside a hanging or continued line. -indent-after-paren=4 - -# String used as indentation unit. This is usually " " (4 spaces) or "\t" (1 -# tab). -indent-string=' ' - -# Maximum number of characters on a single line. -max-line-length=120 - -# Maximum number of lines in a module -max-module-lines=1000 - -# List of optional constructs for which whitespace checking is disabled. `dict- -# separator` is used to allow tabulation in dicts, etc.: {1 : 1,\n222: 2}. -# `trailing-comma` allows a space between comma and closing bracket: (a, ). -# `empty-line` allows space-only lines. -no-space-check=trailing-comma, - dict-separator - -# Allow the body of a class to be on the same line as the declaration if body -# contains single statement. -single-line-class-stmt=no - -# Allow the body of an if to be on the same line as the test if there is no -# else. -single-line-if-stmt=no - - -[SIMILARITIES] - -# Ignore comments when computing similarities. -ignore-comments=yes - -# Ignore docstrings when computing similarities. -ignore-docstrings=yes - -# Ignore imports when computing similarities. -ignore-imports=yes - -# Minimum lines number of a similarity. -min-similarity-lines=4 - - -[BASIC] - -# Naming style matching correct argument names -argument-naming-style=snake_case - -# Regular expression matching correct argument names. Overrides argument- -# naming-style -#argument-rgx= - -# Naming style matching correct attribute names -attr-naming-style=snake_case - -# Regular expression matching correct attribute names. Overrides attr-naming- -# style -#attr-rgx= - -# Bad variable names which should always be refused, separated by a comma -bad-names=foo, - bar, - baz, - toto, - tutu, - tata - -# Naming style matching correct class attribute names -class-attribute-naming-style=any - -# Regular expression matching correct class attribute names. Overrides class- -# attribute-naming-style -#class-attribute-rgx= - -# Naming style matching correct class names -class-naming-style=PascalCase - -# Regular expression matching correct class names. Overrides class-naming-style -#class-rgx= - -# Naming style matching correct constant names -const-naming-style=UPPER_CASE - -# Regular expression matching correct constant names. Overrides const-naming- -# style -#const-rgx= - -# Minimum line length for functions/classes that require docstrings, shorter -# ones are exempt. -docstring-min-length=-1 - -# Naming style matching correct function names -function-naming-style=snake_case - -# Regular expression matching correct function names. Overrides function- -# naming-style -#function-rgx= - -# Good variable names which should always be accepted, separated by a comma -good-names=i, - j, - k, - ex, - Run, - _ - -# Include a hint for the correct naming format with invalid-name -include-naming-hint=no - -# Naming style matching correct inline iteration names -inlinevar-naming-style=any - -# Regular expression matching correct inline iteration names. Overrides -# inlinevar-naming-style -#inlinevar-rgx= - -# Naming style matching correct method names -method-naming-style=snake_case - -# Regular expression matching correct method names. Overrides method-naming- -# style -#method-rgx= - -# Naming style matching correct module names -module-naming-style=snake_case - -# Regular expression matching correct module names. Overrides module-naming- -# style -#module-rgx= - -# Colon-delimited sets of names that determine each other's naming style when -# the name regexes allow several styles. -name-group= - -# Regular expression which should only match function or class names that do -# not require a docstring. -no-docstring-rgx=^_ - -# List of decorators that produce properties, such as abc.abstractproperty. Add -# to this list to register other decorators that produce valid properties. -property-classes=abc.abstractproperty - -# Naming style matching correct variable names -variable-naming-style=snake_case - -# Regular expression matching correct variable names. Overrides variable- -# naming-style -#variable-rgx= - - -[IMPORTS] - -# Allow wildcard imports from modules that define __all__. -allow-wildcard-with-all=no - -# Analyse import fallback blocks. This can be used to support both Python 2 and -# 3 compatible code, which means that the block might have code that exists -# only in one or another interpreter, leading to false positives when analysed. -analyse-fallback-blocks=no - -# Deprecated modules which should not be used, separated by a comma -deprecated-modules=optparse,tkinter.tix - -# Create a graph of external dependencies in the given file (report RP0402 must -# not be disabled) -ext-import-graph= - -# Create a graph of every (i.e. internal and external) dependencies in the -# given file (report RP0402 must not be disabled) -import-graph= - -# Create a graph of internal dependencies in the given file (report RP0402 must -# not be disabled) -int-import-graph= - -# Force import order to recognize a module as part of the standard -# compatibility libraries. -known-standard-library= - -# Force import order to recognize a module as part of a third party library. -known-third-party=enchant - - -[CLASSES] - -# List of method names used to declare (i.e. assign) instance attributes. -defining-attr-methods=__init__, - __new__, - setUp - -# List of member names, which should be excluded from the protected access -# warning. -exclude-protected=_asdict, - _fields, - _replace, - _source, - _make - -# List of valid names for the first argument in a class method. -valid-classmethod-first-arg=cls - -# List of valid names for the first argument in a metaclass class method. -valid-metaclass-classmethod-first-arg=mcs - - -[DESIGN] - -# Maximum number of arguments for function / method -max-args=5 - -# Maximum number of attributes for a class (see R0902). -max-attributes=7 - -# Maximum number of boolean expressions in a if statement -max-bool-expr=5 - -# Maximum number of branch for function / method body -max-branches=12 - -# Maximum number of locals for function / method body -max-locals=15 - -# Maximum number of parents for a class (see R0901). -max-parents=7 - -# Maximum number of public methods for a class (see R0904). -max-public-methods=20 - -# Maximum number of return / yield for function / method body -max-returns=6 - -# Maximum number of statements in function / method body -max-statements=50 - -# Minimum number of public methods for a class (see R0903). -min-public-methods=2 - - -[EXCEPTIONS] - -# Exceptions that will emit a warning when being caught. Defaults to -# "Exception" -overgeneral-exceptions=Exception diff --git a/Content/Maatregelen/M01/Maatregel.md b/Content/Maatregelen/M01/Maatregel.md index 8c96adc5..cb4ac716 100644 --- a/Content/Maatregelen/M01/Maatregel.md +++ b/Content/Maatregelen/M01/Maatregel.md @@ -42,8 +42,8 @@ Als operationeel en/of applicatiebeheer onderdeel is van de te leveren dienstver Beschikbare templates: -- [Template plan van aanpak voorfase]($BASE_URL$/$VERSIE$/ICTU-Template-Plan-van-Aanpak-Voorfase.docx). -- [Template plan van aanpak realisatiefase]($BASE_URL$/$VERSIE$/ICTU-Template-Plan-van-Aanpak-Realisatiefase.docx). +* [Template plan van aanpak voorfase]($BASE_URL$/$VERSIE$/ICTU-Template-Plan-van-Aanpak-Voorfase.docx). +* [Template plan van aanpak realisatiefase]($BASE_URL$/$VERSIE$/ICTU-Template-Plan-van-Aanpak-Realisatiefase.docx). ### Beschrijving van functionele eisen @@ -71,7 +71,7 @@ Bronnen van de opdrachtgevende organisatie zoals procesbeschrijvingen, privacy i Beschikbare templates: -- [Template niet-functionele eisen]($BASE_URL$/$VERSIE$/Neutraal-Template-Niet-Functionele-Eisen.docx). +* [Template niet-functionele eisen]($BASE_URL$/$VERSIE$/Neutraal-Template-Niet-Functionele-Eisen.docx). ### Product backlog @@ -99,9 +99,9 @@ Een prototype is een eerste, ruwe versie van de applicatie. Het prototype illust Beschikbare templates: -- [Template globaal functioneel ontwerp]($BASE_URL$/$VERSIE$/ICTU-Template-Globaal-Functioneel-Ontwerp.docx). -- [Template softwarearchitectuurdocument]($BASE_URL$/$VERSIE$/ICTU-Template-Software-architectuurdocument.docx). -- [Template infrastructuurarchitectuur]($BASE_URL$/$VERSIE$/Neutraal-Template-Infrastructuurarchitectuur.docx). +* [Template globaal functioneel ontwerp]($BASE_URL$/$VERSIE$/ICTU-Template-Globaal-Functioneel-Ontwerp.docx). +* [Template softwarearchitectuurdocument]($BASE_URL$/$VERSIE$/ICTU-Template-Software-architectuurdocument.docx). +* [Template infrastructuurarchitectuur]($BASE_URL$/$VERSIE$/Neutraal-Template-Infrastructuurarchitectuur.docx). ### Testplannen en -rapportages @@ -113,7 +113,7 @@ Logische testgevallen worden vastgelegd en gekoppeld met use cases en user stori Beschikbare templates: -- [Template detailtestplan softwarerealisatie]($BASE_URL$/$VERSIE$/ICTU-Template-Detailtestplan-Softwarerealisatie.docx). +* [Template detailtestplan softwarerealisatie]($BASE_URL$/$VERSIE$/ICTU-Template-Detailtestplan-Softwarerealisatie.docx). ### Informatiebeveiligingsplan @@ -133,7 +133,7 @@ Als de opdrachtgevende organisatie een overkoepelend kwaliteitsplan heeft zorgt Beschikbare templates: -- [Template kwaliteitsplan]($BASE_URL$/$VERSIE$/ICTU-Template-Kwaliteitsplan.docx). +* [Template kwaliteitsplan]($BASE_URL$/$VERSIE$/ICTU-Template-Kwaliteitsplan.docx). ### Deploybare versie van de software diff --git a/Content/Wijzigingsgeschiedenis.md b/Content/Wijzigingsgeschiedenis.md index 8dc0643b..2ff05c4b 100644 --- a/Content/Wijzigingsgeschiedenis.md +++ b/Content/Wijzigingsgeschiedenis.md @@ -1,5 +1,17 @@ ### [Unreleased] +#### Kwaliteitsaanpak + +* De PDF-versie wordt niet langer gemaakt. De software (wkhtmltopdf) om de PDF te genereren wordt niet meer onderhouden. Overstappen op een andere oplossing kost te veel tijd. Indien nodig kunnen gebruikers de HTML-versie zelf naar PDF exporteren met behulp van een webbrowser. + +#### Samenvatting Kwaliteitsaanpak + +* De PDF-versie wordt niet langer gemaakt. De software (wkhtmltopdf) om de PDF te genereren wordt niet meer onderhouden. Overstappen op een andere oplossing kost te veel tijd. Indien nodig kunnen gebruikers de HTML-versie zelf naar PDF exporteren met behulp van een webbrowser. + +#### Wijzigingsgeschiedenis + +* De PDF-versie wordt niet langer gemaakt. De software (wkhtmltopdf) om de PDF te genereren wordt niet meer onderhouden. Overstappen op een andere oplossing kost te veel tijd. Indien nodig kunnen gebruikers de HTML-versie zelf naar PDF exporteren met behulp van een webbrowser. + #### Alle documenten * "OWASP Dependency-Check" consistent gespeld. diff --git a/Dockerfile b/Dockerfile index 4951b6ab..facf75f5 100644 --- a/Dockerfile +++ b/Dockerfile @@ -1,24 +1,5 @@ FROM python:3.12.4-bullseye -# Work-around for https://github.com/docker/for-mac/issues/7025: -RUN echo 'Acquire::http::Pipeline-Depth 0;\nAcquire::http::No-Cache true;\nAcquire::BrokenProxy true;\n' > /etc/apt/apt.conf.d/99fixbadproxy - -RUN apt-get update \ - && apt-get -y upgrade \ - && apt-get install -y --no-install-recommends fontconfig libjpeg62-turbo libx11-6 libxcb1 libxext6 libxrender1 xfonts-75dpi xfonts-base wget \ - && apt-get install -y --no-install-recommends make docker.io docker-compose ghostscript \ - && apt-get clean \ - && rm -rf /var/lib/apt/lists/* - -ARG ARCH - -RUN wget --quiet https://github.com/wkhtmltopdf/packaging/releases/download/0.12.6.1-2/wkhtmltox_0.12.6.1-2.bullseye_${ARCH}.deb \ - && dpkg -i wkhtmltox_0.12.6.1-2.bullseye_${ARCH}.deb \ - && rm -f wkhtmltox_0.12.6.1-2.bullseye_${ARCH}.deb - -ADD ./thirdparty/fonts/muli /usr/share/fonts/truetype/muli -RUN fc-cache -fv - ADD ./requirements.txt /tmp/requirements.txt RUN pip install -r /tmp/requirements.txt diff --git a/DocumentDefinitions/Shared/document.css b/DocumentDefinitions/Shared/document.css index e2c4bcb4..15c28b53 100644 --- a/DocumentDefinitions/Shared/document.css +++ b/DocumentDefinitions/Shared/document.css @@ -1,44 +1,102 @@ @import url("https://use.fontawesome.com/releases/v5.2.0/css/all.css"); +@page { + size: A4; /* DIN A4 standard, Europe */ + margin-top: 25mm; + margin-bottom: 25mm; +} + body { font-size: 12pt !important; color: #000 !important; - font-family: 'Muli', sans-serif; + font-family: "Muli", sans-serif; width: 680px; margin: auto; counter-reset: section; } -h1::before { +/* Front matter */ + +img[title="word-cloud"] { + width: 95%; + padding-top: 100px; +} + +/* Table of contents *.keep-together */ + +#toc { + counter-reset: toc-h1; +} + +#toc div.h1::before { + counter-increment: toc-h1; + content: counter(toc-h1) " "; + color: #2c64ad; + margin-left: -2em; + width: 2em; + position: absolute; +} + +#toc div.h1.bijlage::before { + counter-reset: toc-h1; + content: ""; +} + +#toc div.h1 { + margin-top: 1em; + margin-left: 2em; + counter-reset: toc-h2; +} + +#toc div.h1.bijlage { + margin-left: 0em; +} + +#toc div.h2.bijlage::before { + counter-increment: toc-h2; + content: counter(toc-h2, upper-alpha) " "; + color: #2c64ad; + margin-left: -2em; + width: 2em; + position: absolute; +} + +#toc div.h2::before { + counter-increment: toc-h2; + content: counter(toc-h1) "." counter(toc-h2) " "; + color: #2c64ad; + margin-left: -2em; + width: 2em; + position: absolute; +} + +#toc div.h2 { + margin-left: 4em; +} + +/* Headers */ + +h1:not(toc)::before { counter-increment: section; content: counter(section) " "; - color: #2C64AD; + color: #2c64ad; } h1 { line-height: 150%; - color: #2C64AD; + color: #2c64ad; font-size: 20pt; font-weight: bold; page-break-before: always; counter-reset: subsection; } -p.title { - margin-top: 30px; - color: #2C64AD; - font-size: 42pt; - font-weight: bold; - line-height: 130%; -} - -img[title='word-cloud'] { - width: 95%; - padding-top: 100px; +h1.toc::before { + content: ""; /* The table of contents title has no counter */ } -#bijlagen::before { - content: ""; /* The Bijlagen section has no counter */ +h1.toc { + counter-reset: section; } h2.bijlage::before { @@ -51,13 +109,9 @@ h2::before { content: counter(section) "." counter(subsection) " "; } -h2.toc::before { - content: ""; /* The table of contents title has no counter */ -} - h2 { margin-top: 20px; - color: #DB1778; + color: #db1778; font-size: 16pt; font-weight: bold; } @@ -67,17 +121,17 @@ h3 { color: black; font-size: 14pt; font-weight: bold; - margin-bottom: -15px; /* Remove vertical space between header and next element */ + margin-bottom: -15px; /* Remove vertical space between header and next element */ } h4 { font-size: 12pt; - color: #B500C7; - margin-bottom: -15px; /* Remove vertical space between header and next element */ + color: #b500c7; + margin-bottom: -15px; /* Remove vertical space between header and next element */ } h4.risk { - background-color: #4C76BA; + background-color: #4c76ba; color: white; padding: 1em; } @@ -88,14 +142,35 @@ h5 { font-weight: bold; } +#bijlagen::before { + content: ""; /* The Bijlagen section has no counter */ +} + +/* Paragraphs */ + +p.title { + margin-top: 30px; + color: #2c64ad; + font-size: 42pt; + font-weight: bold; + line-height: 130%; +} + +.keep-together { + page-break-inside: avoid; +} + +/* Tables */ + tr { page-break-inside: avoid; } -th,td { +th, +td { text-align: left; vertical-align: top; - background-color: #E6F6FD; + background-color: #e6f6fd; padding: 5px; padding-left: 10px; padding-right: 10px; @@ -103,9 +178,11 @@ th,td { } th { - background-color: #83D0F5; + background-color: #83d0f5; } +/* Numbered lists */ + ol { list-style-type: none; counter-reset: ol-item; @@ -114,15 +191,16 @@ ol { padding: 0; } -ol > li:before { +ol > li::before { counter-increment: ol-item; content: counter(ol-item) ". "; margin-left: -3em; position: absolute; + color: #4c76ba; } ol ol > li:before { - content: counters(item, ".") " "; /* Use nested counters when ol's are nested */ + content: counters(item, ".") " "; /* Use nested counters when ol's are nested */ } ol > li { @@ -141,29 +219,32 @@ ol.bijlage { margin-top: 0.1em; } +/* Bulleted lists */ + ul { padding-left: 1.2em; + list-style: none; } -ul > li { - /* Since we can't easily give the bullet a different color than the text, we use a SVG. */ - list-style-image: url('data:image/svg+xml,'); - padding-left: 1.7em; +ul > li::before { + content: "●"; + color: #4c76ba; + display: inline-block; + width: 1.2em; + margin-left: -1.2em; } -.keep-together { - page-break-inside: avoid; -} +/* Domain specific styles */ .maatregel { - background-color: #E6F6FD; + background-color: #e6f6fd; border-style: solid; border-width: 1px; padding: 1em; } .risk { - background-color: #4C76BA; + background-color: #4c76ba; color: white; padding: 1em; } diff --git a/DocumentDefinitions/Shared/footer.html b/DocumentDefinitions/Shared/footer.html deleted file mode 100644 index 018d81c1..00000000 --- a/DocumentDefinitions/Shared/footer.html +++ /dev/null @@ -1,8 +0,0 @@ - - - -
- -
- - \ No newline at end of file diff --git a/DocumentDefinitions/Shared/header.html b/DocumentDefinitions/Shared/header.html deleted file mode 100644 index e65867af..00000000 --- a/DocumentDefinitions/Shared/header.html +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - - - - - -
- - diff --git a/DocumentDefinitions/kwaliteitsaanpak-samenvatting.json b/DocumentDefinitions/kwaliteitsaanpak-samenvatting.json index 41617934..0d71463a 100644 --- a/DocumentDefinitions/kwaliteitsaanpak-samenvatting.json +++ b/DocumentDefinitions/kwaliteitsaanpak-samenvatting.json @@ -7,8 +7,8 @@ "FrontPage": "ICTU", "IncludeTableOfContents": false, "OutputFormats": { - "pdf": { - "OutputFile": "ICTU-Kwaliteitsaanpak-Samenvatting.pdf", + "html": { + "OutputFile": "ICTU-Kwaliteitsaanpak-Samenvatting.html", "OutputPaths": [ "docs/$VERSIE$" ], @@ -16,45 +16,25 @@ { "from": "DocumentDefinitions/Shared/document.css", "to": [ - "build/Kwaliteitsaanpak/ICTU-Kwaliteitsaanpak.css" + "docs/$VERSIE$/ICTU-Kwaliteitsaanpak-Samenvatting.css" ] }, { "from": "Content/Images/ICTU.png", "to": [ - "build/Kwaliteitsaanpak/ICTU.png" + "docs/$VERSIE$/ICTU.png" ] }, { "from": "Content/Images/word-cloud.png", "to": [ - "build/Kwaliteitsaanpak/word-cloud.png" + "docs/$VERSIE$/word-cloud.png" ] } ] - }, - "html": { - "OutputFile": "ICTU-Kwaliteitsaanpak-Samenvatting.html", - "OutputPaths": [ - "docs/$VERSIE$" - ], - "CopyFiles": [ - { - "from": "DocumentDefinitions/Shared/document.css", - "to": ["docs/$VERSIE$/ICTU-Kwaliteitsaanpak-Samenvatting.css"] - }, - { - "from": "Content/Images/ICTU.png", - "to": ["docs/$VERSIE$/ICTU.png"] - }, - { - "from": "Content/Images/word-cloud.png", - "to": ["docs/$VERSIE$/word-cloud.png"] - } - ] } }, "VariablesFiles": [ "DocumentDefinitions/Shared/variables.json" ] -} \ No newline at end of file +} diff --git a/DocumentDefinitions/kwaliteitsaanpak.json b/DocumentDefinitions/kwaliteitsaanpak.json index ec989e95..16f3106c 100644 --- a/DocumentDefinitions/kwaliteitsaanpak.json +++ b/DocumentDefinitions/kwaliteitsaanpak.json @@ -6,53 +6,44 @@ "FrontPage": "ICTU", "IncludeTableOfContents": true, "OutputFormats": { - "pdf": { - "OutputFile": "ICTU-Kwaliteitsaanpak.pdf", + "html": { + "OutputFile": "ICTU-Kwaliteitsaanpak.html", "OutputPaths": [ "docs/$VERSIE$" ], "CopyFiles": [ { "from": "DocumentDefinitions/Shared/document.css", - "to": ["build/Kwaliteitsaanpak/ICTU-Kwaliteitsaanpak.css"] + "to": [ + "docs/$VERSIE$/ICTU-Kwaliteitsaanpak.css" + ] }, { "from": "Content/Images/relaties-tussen-producten.png", - "to": ["build/Kwaliteitsaanpak/relaties-tussen-producten.png"] + "to": [ + "docs/$VERSIE$/relaties-tussen-producten.png" + ] }, { "from": "Content/Images/ICTU.png", - "to": ["build/Kwaliteitsaanpak/ICTU.png"] + "to": [ + "docs/$VERSIE$/ICTU.png" + ] }, { "from": "Content/Images/word-cloud.png", - "to": ["build/Kwaliteitsaanpak/word-cloud.png"] + "to": [ + "docs/$VERSIE$/word-cloud.png" + ] } ] }, - "html": { - "OutputFile": "ICTU-Kwaliteitsaanpak.html", + "docx": { + "OutputFile": "ICTU-Kwaliteitsaanpak.docx", "OutputPaths": [ "docs/$VERSIE$" ], - "CopyFiles": [ - { - "from": "DocumentDefinitions/Shared/document.css", - "to": ["docs/$VERSIE$/ICTU-Kwaliteitsaanpak.css"] - }, - { - "from": "Content/Images/relaties-tussen-producten.png", - "to": ["docs/$VERSIE$/relaties-tussen-producten.png"] - }, - { - "from": "Content/Images/ICTU.png", - "to": ["docs/$VERSIE$/ICTU.png"] - }, - { - "from": "Content/Images/word-cloud.png", - "to": ["docs/$VERSIE$/word-cloud.png"] - } - ] + "ReferenceFile": "DocumentDefinitions/reference-ictu.docx" }, "xlsx": { "OutputFile": "ICTU-Kwaliteitsaanpak-Checklist.xlsx", @@ -71,4 +62,4 @@ "VariablesFiles": [ "DocumentDefinitions/Shared/variables.json" ] -} \ No newline at end of file +} diff --git a/DocumentDefinitions/wijzigingsgeschiedenis.json b/DocumentDefinitions/wijzigingsgeschiedenis.json index 67dbd483..b168f9aa 100644 --- a/DocumentDefinitions/wijzigingsgeschiedenis.json +++ b/DocumentDefinitions/wijzigingsgeschiedenis.json @@ -7,8 +7,8 @@ "FrontPage": "ICTU", "IncludeTableOfContents": false, "OutputFormats": { - "pdf": { - "OutputFile": "ICTU-Kwaliteitsaanpak-Wijzigingsgeschiedenis.pdf", + "html": { + "OutputFile": "ICTU-Kwaliteitsaanpak-Wijzigingsgeschiedenis.html", "OutputPaths": [ "docs/$VERSIE$" ], @@ -16,44 +16,26 @@ { "from": "DocumentDefinitions/Shared/document.css", "to": [ - "build/Wijzigingsgeschiedenis/ICTU-Kwaliteitsaanpak.css" + "docs/$VERSIE$/ICTU-Kwaliteitsaanpak.css" ] }, { - "from": "Content/Images/ICTU.png", + "from": "Content/Images/relaties-tussen-producten.png", "to": [ - "build/Wijzigingsgeschiedenis/ICTU.png" + "docs/$VERSIE$/relaties-tussen-producten.png" ] }, { - "from": "Content/Images/word-cloud.png", + "from": "Content/Images/ICTU.png", "to": [ - "build/Wijzigingsgeschiedenis/word-cloud.png" + "docs/$VERSIE$/ICTU.png" ] - } - ] - }, - "html": { - "OutputFile": "ICTU-Kwaliteitsaanpak-Wijzigingsgeschiedenis.html", - "OutputPaths": [ - "docs/$VERSIE$" - ], - "CopyFiles": [ - { - "from": "DocumentDefinitions/Shared/document.css", - "to": ["docs/$VERSIE$/ICTU-Kwaliteitsaanpak.css"] - }, - { - "from": "Content/Images/relaties-tussen-producten.png", - "to": ["docs/$VERSIE$/relaties-tussen-producten.png"] - }, - { - "from": "Content/Images/ICTU.png", - "to": ["docs/$VERSIE$/ICTU.png"] }, { "from": "Content/Images/word-cloud.png", - "to": ["docs/$VERSIE$/word-cloud.png"] + "to": [ + "docs/$VERSIE$/word-cloud.png" + ] } ] } @@ -61,4 +43,4 @@ "VariablesFiles": [ "DocumentDefinitions/Shared/variables.json" ] -} \ No newline at end of file +} diff --git a/README.md b/README.md index 00f923ee..10bd7554 100644 --- a/README.md +++ b/README.md @@ -6,7 +6,7 @@ This repository contains the source information and automation scripts for gener ## Documents -The Kwaliteitsaanpak consists of a main document containing the Kwaliteitsaanpak itself, a number of templates, and a self-assessment checklist. The sources are a collection of Markdown files and supporting material. Scripts convert the Kwaliteitsaanpak main document to html and pdf, the templates to docx, and the self-assessment checklist to xslx. +The Kwaliteitsaanpak consists of a main document containing the Kwaliteitsaanpak itself, a number of templates, and a self-assessment checklist. The sources are a collection of Markdown files and supporting material. Scripts convert the Kwaliteitsaanpak main document to html, the templates to docx, and the self-assessment checklist to xslx. ## Authoring guidelines diff --git a/docker-compose.yml b/docker-compose.yml index 1f0979b7..a57b991d 100644 --- a/docker-compose.yml +++ b/docker-compose.yml @@ -2,8 +2,6 @@ services: ka: build: context: . - args: - ARCH: ${ARCH:-amd64} environment: VERSION: ${VERSION:-wip} working_dir: /work diff --git a/docs/index.html b/docs/index.html index a4b6a620..e8796f24 100644 --- a/docs/index.html +++ b/docs/index.html @@ -38,11 +38,10 @@

Release v4.0.0, 26-4-2024

Onderhanden werk

diff --git a/docs/wip/ICTU-Kwaliteitsaanpak-Checklist.xlsx b/docs/wip/ICTU-Kwaliteitsaanpak-Checklist.xlsx index 91165364..14b9f444 100644 Binary files a/docs/wip/ICTU-Kwaliteitsaanpak-Checklist.xlsx and b/docs/wip/ICTU-Kwaliteitsaanpak-Checklist.xlsx differ diff --git a/docs/wip/ICTU-Kwaliteitsaanpak-Samenvatting.css b/docs/wip/ICTU-Kwaliteitsaanpak-Samenvatting.css index e2c4bcb4..15c28b53 100644 --- a/docs/wip/ICTU-Kwaliteitsaanpak-Samenvatting.css +++ b/docs/wip/ICTU-Kwaliteitsaanpak-Samenvatting.css @@ -1,44 +1,102 @@ @import url("https://use.fontawesome.com/releases/v5.2.0/css/all.css"); +@page { + size: A4; /* DIN A4 standard, Europe */ + margin-top: 25mm; + margin-bottom: 25mm; +} + body { font-size: 12pt !important; color: #000 !important; - font-family: 'Muli', sans-serif; + font-family: "Muli", sans-serif; width: 680px; margin: auto; counter-reset: section; } -h1::before { +/* Front matter */ + +img[title="word-cloud"] { + width: 95%; + padding-top: 100px; +} + +/* Table of contents *.keep-together */ + +#toc { + counter-reset: toc-h1; +} + +#toc div.h1::before { + counter-increment: toc-h1; + content: counter(toc-h1) " "; + color: #2c64ad; + margin-left: -2em; + width: 2em; + position: absolute; +} + +#toc div.h1.bijlage::before { + counter-reset: toc-h1; + content: ""; +} + +#toc div.h1 { + margin-top: 1em; + margin-left: 2em; + counter-reset: toc-h2; +} + +#toc div.h1.bijlage { + margin-left: 0em; +} + +#toc div.h2.bijlage::before { + counter-increment: toc-h2; + content: counter(toc-h2, upper-alpha) " "; + color: #2c64ad; + margin-left: -2em; + width: 2em; + position: absolute; +} + +#toc div.h2::before { + counter-increment: toc-h2; + content: counter(toc-h1) "." counter(toc-h2) " "; + color: #2c64ad; + margin-left: -2em; + width: 2em; + position: absolute; +} + +#toc div.h2 { + margin-left: 4em; +} + +/* Headers */ + +h1:not(toc)::before { counter-increment: section; content: counter(section) " "; - color: #2C64AD; + color: #2c64ad; } h1 { line-height: 150%; - color: #2C64AD; + color: #2c64ad; font-size: 20pt; font-weight: bold; page-break-before: always; counter-reset: subsection; } -p.title { - margin-top: 30px; - color: #2C64AD; - font-size: 42pt; - font-weight: bold; - line-height: 130%; -} - -img[title='word-cloud'] { - width: 95%; - padding-top: 100px; +h1.toc::before { + content: ""; /* The table of contents title has no counter */ } -#bijlagen::before { - content: ""; /* The Bijlagen section has no counter */ +h1.toc { + counter-reset: section; } h2.bijlage::before { @@ -51,13 +109,9 @@ h2::before { content: counter(section) "." counter(subsection) " "; } -h2.toc::before { - content: ""; /* The table of contents title has no counter */ -} - h2 { margin-top: 20px; - color: #DB1778; + color: #db1778; font-size: 16pt; font-weight: bold; } @@ -67,17 +121,17 @@ h3 { color: black; font-size: 14pt; font-weight: bold; - margin-bottom: -15px; /* Remove vertical space between header and next element */ + margin-bottom: -15px; /* Remove vertical space between header and next element */ } h4 { font-size: 12pt; - color: #B500C7; - margin-bottom: -15px; /* Remove vertical space between header and next element */ + color: #b500c7; + margin-bottom: -15px; /* Remove vertical space between header and next element */ } h4.risk { - background-color: #4C76BA; + background-color: #4c76ba; color: white; padding: 1em; } @@ -88,14 +142,35 @@ h5 { font-weight: bold; } +#bijlagen::before { + content: ""; /* The Bijlagen section has no counter */ +} + +/* Paragraphs */ + +p.title { + margin-top: 30px; + color: #2c64ad; + font-size: 42pt; + font-weight: bold; + line-height: 130%; +} + +.keep-together { + page-break-inside: avoid; +} + +/* Tables */ + tr { page-break-inside: avoid; } -th,td { +th, +td { text-align: left; vertical-align: top; - background-color: #E6F6FD; + background-color: #e6f6fd; padding: 5px; padding-left: 10px; padding-right: 10px; @@ -103,9 +178,11 @@ th,td { } th { - background-color: #83D0F5; + background-color: #83d0f5; } +/* Numbered lists */ + ol { list-style-type: none; counter-reset: ol-item; @@ -114,15 +191,16 @@ ol { padding: 0; } -ol > li:before { +ol > li::before { counter-increment: ol-item; content: counter(ol-item) ". "; margin-left: -3em; position: absolute; + color: #4c76ba; } ol ol > li:before { - content: counters(item, ".") " "; /* Use nested counters when ol's are nested */ + content: counters(item, ".") " "; /* Use nested counters when ol's are nested */ } ol > li { @@ -141,29 +219,32 @@ ol.bijlage { margin-top: 0.1em; } +/* Bulleted lists */ + ul { padding-left: 1.2em; + list-style: none; } -ul > li { - /* Since we can't easily give the bullet a different color than the text, we use a SVG. */ - list-style-image: url('data:image/svg+xml,'); - padding-left: 1.7em; +ul > li::before { + content: "●"; + color: #4c76ba; + display: inline-block; + width: 1.2em; + margin-left: -1.2em; } -.keep-together { - page-break-inside: avoid; -} +/* Domain specific styles */ .maatregel { - background-color: #E6F6FD; + background-color: #e6f6fd; border-style: solid; border-width: 1px; padding: 1em; } .risk { - background-color: #4C76BA; + background-color: #4c76ba; color: white; padding: 1em; } diff --git a/docs/wip/ICTU-Kwaliteitsaanpak-Samenvatting.html b/docs/wip/ICTU-Kwaliteitsaanpak-Samenvatting.html index 448725eb..f0d6b5b0 100644 --- a/docs/wip/ICTU-Kwaliteitsaanpak-Samenvatting.html +++ b/docs/wip/ICTU-Kwaliteitsaanpak-Samenvatting.html @@ -1,2 +1,22 @@ -ICTU Kwaliteitsaanpak Softwareontwikkeling versie wipICTU logo

ICTU Kwaliteitsaanpak Softwareontwikkeling

Samenvatting

Versie wip, 31-07-2024

Inleiding

De overheid is in hoge mate afhankelijk van informatiesystemen voor de uitvoering van haar taken. Veel van die informatiesystemen zijn dusdanig specifiek dat de benodigde software “op maat” gemaakt moet worden. De totstandkoming van op maat gemaakte software is meestal een complex proces, waarin vele belangen en behoeften worden afgewogen en afgezet tegen de mogelijkheden die technologie biedt. Eenmaal operationeel zal een informatiesysteem verantwoord onderhouden moeten worden; behoeften en technologie veranderen in de loop van de tijd.

Overheidsprojecten waarin software wordt ontwikkeld of onderhouden kampen nog vaak met vertraging, budgetoverschrijding of een eindresultaat met te lage kwaliteit. Zo concludeerde de commissie-Elias in haar eindrapport: "De Rijksoverheid heeft haar ICT (Informatie- en communicatietechnologie)-projecten niet onder controle". Eén van de fundamentele problemen is dat de risico's, die inherent zijn aan softwareontwikkeling, door organisaties nog onvoldoende worden herkend, erkend en gemitigeerd. Dit terwijl de risico's bij de ontwikkeling van software, binnen het ICT-domein, algemeen bekend zijn en er ook voor veel risico's passende maatregelen bestaan.

ICTU heeft jarenlange ervaring met het realiseren van software en past de opgedane ervaring toe bij de ontwikkeling van nieuwe software. Die ervaring is vastgelegd in een werkwijze, deze “ICTU Kwaliteitsaanpak Softwareontwikkeling”, die telkens wordt aangepast en aangevuld op basis van de praktijk.

ICTU is ervan overtuigd dat het bouwen van duurzame software, die goed aansluit bij de behoeften van gebruikers en andere belanghebbenden, bijdraagt aan betere informatiesystemen en een betere dienstverlening door de overheid. Dienstverlening die betrouwbaar moet zijn voor burgers, bedrijven en ambtenaren. Om samen met opdrachtgevende organisaties passende oplossingen te realiseren ontwikkelt ICTU daarom software volgens een agile proces. En om de duurzaamheid en betrouwbaarheid te bevorderen besteedt ICTU standaard aandacht aan beveiliging, privacy, performance, gebruikskwaliteit en toegankelijkheid. De Kwaliteitsaanpak dient daarvoor als leidraad, maar de aanpak voorziet ook in mogelijkheden om het project en het eindproduct aan te passen aan de specifieke situatie.

Om projecten, die software realiseren volgens de Kwaliteitsaanpak, efficiënt en effectief te ondersteunen, heeft ICTU twee gespecialiseerde afdelingen in het leven geroepen. Deze afdelingen staan projecten bij door middel van kennis, menskracht en technische hulpmiddelen. Zo profiteren projecten van schaalgrootte en hergebruik van inzichten.

Met behulp van de ICTU Kwaliteitsaanpak Softwareontwikkeling heeft ICTU samen met andere overheden inmiddels enige tientallen projecten succesvol uitgevoerd. ICTU wil deze aanpak graag aanvullen met de ervaringen en geleerde lessen van andere organisaties en deze overdraagbaar maken en breder uitdragen. Om die reden stelt ICTU deze Kwaliteitsaanpak aan iedereen beschikbaar via https://www.ictu.nl/kwaliteitsaanpak en heeft zij, samen met normalisatie-instituut NEN en partijen uit overheid en markt, een praktijkrichtlijn “Risicobeheersing bij ontwikkeling en onderhoud van maatwerksoftware” [NEN NPR 5326:2019] gepubliceerd, die mede is gebaseerd op de ICTU Kwaliteitsaanpak Softwareontwikkeling.

Doelstellingen

De ICTU Kwaliteitsaanpak Softwareontwikkeling heeft drie doelstellingen:

  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 opdrachtgevende organisaties maatwerksoftware ontwikkelt en onderhoudt. ICTU hanteert daarbij de vuistregel dat als tenminste 80% van de projecten minstens 80% van de tijd een bepaalde werkwijze hanteren, voor die werkwijze een maatregel in de Kwaliteitsaanpak wordt opgenomen. Maar het kan ook voorkomen dat maatregelen om andere redenen landen in de Kwaliteitsaanpak; denk aan het toegankelijk maken van software dat wettelijk verplicht is. Zie ook de wijzigingsgeschiedenis in PDF-formaat of HTML-formaat.

De maatregelen vormen het startpunt voor de aanpak van ieder ICTU-softwareproject, waarbij ruimte wordt geboden voor variatie of alternatieve invulling. Bijvoorbeeld stelt de Kwaliteitsaanpak: software wordt minimaal bij iedere grote release of tenminste twee keer per jaar onderworpen aan een beveiligingstest door beveiligingsexperts die ICTU daarvoor inhuurt (zie M26: Het project laat de beveiliging van het ontwikkelde product periodiek beoordelen). Een alternatief is dat de opdrachtgevende organisatie de verantwoordelijkheid neemt voor het laten uitvoeren van beveiligingstests. Hierover maakt de projectleider nadere afspraken met de opdrachtgever.

De Kwaliteitsaanpak is dus zowel voorschrijvend als beschrijvend. Voorschrijvend omdat ICTU verwacht dat projecten die maatwerksoftware ontwikkelen en onderhouden de aanpak toepassen, en alleen aanpassen als daar een goede reden voor is, en mits dat wettelijk is toegestaan. Tegelijkertijd is de aanpak beschrijvend omdat de meeste maatregelen voortkomen uit de bestaande werkwijzen van de projecten. Zoals blijkt uit de self-assessment die ICTU regelmatig uitvoert op de toepassing van de Kwaliteitsaanpak.

Maatregelen

Hieronder zijn alle maatregeldefinities uit de Kwaliteitsaanpak opgenomen. Zie de Kwaliteitsaanpak zelf voor een uitgebreidere beschrijving van de maatregelen, inclusief context en rationale.

Producten

M31: Het project beschikt over actuele vastgestelde informatie
Voor een goede uitvoering van het project is specifieke informatie nodig. De opdrachtgevende organisatie zorgt dat het project bij de start van de voorfase inzicht heeft in de informatie die typisch wordt vastgelegd in een projectstartarchitectuur, business impact analysis en privacy impact assessment. Waar nodig werkt de opdrachtgevende organisatie de informatie bij tijdens de voorfase en realisatiefase.
M01: Het project levert in elke fase vastgestelde producten en informatie op
Iedere projectfase levert specifieke informatie op. De voorfase levert inzicht in de functionele en niet-functionele eisen, ontwerp en architectuur, testplannen, operationele risico's, en benodigde kwaliteitsmaatregelen. Deze informatie wordt tijdens de realisatiefase waar nodig bijgewerkt. De realisatiefase levert één of meerdere werkende versies van de software met regressietests, aangevuld met een vrijgaveadvies, release notes en installatiedocumentatie.
M32: Het project onderzoekt de kwaliteit van over te nemen software
Als tijdens een project bestaande software dient te worden afgebouwd, onderhouden en/of herbouwd, vindt een onderzoek plaats naar de kwaliteit van deze software.
M02: Het project bewaakt continu dat het product aan de kwaliteitsnormen voldoet
Projecten bewaken zo snel mogelijk vanaf de start de door het project en ICTU vastgestelde kwaliteitsnormen en voldoen daar zo snel en goed mogelijk aan. De kwaliteit van producten, die nog niet zijn afgerond of nog niet aan de normen voldoen, wordt door het project bewaakt. Het voldoen aan de kwaliteitsnormen is onderdeel van de Definition of Done en herstel van de kwaliteit wordt planmatig opgepakt.
M03: Het project zorgt dat het product traceerbaar aan eisen voldoet
Eisen zijn wederzijds traceerbaar naar bewijsmateriaal, zoals logische testgevallen, dat de eis gerealiseerd is; dat wil zeggen dat geadministreerd is bij welke eis bewijsmateriaal hoort en vice versa. Dit wordt waar mogelijk met tooling ondersteund.
M13: Het project gebruikt ISO-25010 voor de specificatie van productkwaliteitseisen
Voor specificatie en documentatie van vereiste en gewenste kwaliteitseigenschappen, de niet-functionele eisen, maken projecten gebruik van de terminologie en categorisering uit NEN-ISO/IEC 25010. Projecten gebruiken NEN-ISO/IEC 25010 om te controleren of alle relevante kwaliteitseigenschappen van het op te leveren eindproduct worden meegenomen in de ontwikkeling en/of onderhoud van het product.
M04: Het project borgt de correcte werking van het product met geautomatiseerde regressietests
Regressietests - tests die verifiëren of eerder ontwikkelde software nog steeds correct werkt na wijzigingen in de software of aansluiting op andere externe koppelvlakken - zijn geautomatiseerd.
M07: Het project gebruikt een continuous delivery pipeline om het product te bouwen, testen en op te leveren
Er is een geautomatiseerde continuous delivery pipeline die aantoonbaar correct werkt en de software bouwt, installeert in de testomgevingen, test op functionele en niet-functionele eigenschappen en oplevert, al dan niet inclusief installatie in de productieomgeving.
M16: Het project gebruikt tools voor vastgestelde taken
ICTU stelt het gebruik van tools verplicht voor de volgende taken:
  1. backlog management en agile werken,
  2. inrichten en uitvoeren van een continuous delivery pipeline,
  3. monitoren van de kwaliteit van broncode,
  4. versiebeheer van op te leveren producten,
  5. release van software,
  6. maken van testrapportages,
  7. maken van kwaliteitsrapportages,
  8. controleren van de configuratie op aanwezigheid van bekende kwetsbaarheden,
  9. controleren van door de applicatie gebruikte versies van externe software op aanwezigheid van bekende kwetsbaarheden,
  10. statische controle van de software op aanwezigheid van kwetsbare constructies,
  11. dynamische controle van de software op aanwezigheid van kwetsbare constructies,
  12. controleren van container images op aanwezigheid van bekende kwetsbaarheden,
  13. testen van performance en schaalbaarheid,
  14. testen op toegankelijkheid van de applicatie,
  15. produceren van een "software bill of materials" (SBoM),
  16. opslaan van artifacten,
  17. registratie van incidenten bij gebruik en beheer, en
  18. bij het uitvoeren van operationeel beheer; uitrollen van de software in de productieomgeving.
M08: Het project maakt technische schuld inzichtelijk en lost deze planmatig op
Technische schuld is inzichtelijk en wordt planmatig aangepakt. De kwaliteitsmanager is verantwoordelijk voor het inzichtelijk maken van de technische schuld. De software delivery manager is verantwoordelijk voor het planmatig aanpakken van de technische schuld en zorgt dat het Scrumteam regelmatig en voldoende tijd heeft om technische schuld te voorkomen en op te lossen. Het Scrumteam is verantwoordelijk voor het zoveel mogelijk voorkomen van technische schuld en voor het identificeren van technische schuld die toch optreedt.
M26: Het project laat de beveiliging van het ontwikkelde product periodiek beoordelen
Projecten laten periodiek de beveiliging van de ontwikkelde software beoordelen. Een beveiligingsexpert onderzoekt de code zowel geautomatiseerd als handmatig op veelvoorkomende kwetsbaarheden en op het voldoen aan voorgeschreven beveiligingsnormen. Overheidsspecifieke beveiligingsnormen of -raamwerken, zoals de BIO (Baseline Informatiebeveiliging Overheid), bieden een basis voor de beoordeling. Bevindingen uit de beveiligingstest worden vastgelegd als onderdeel van de werkvoorraad voor het ontwikkelproces.

Processen

M14: Het project bereidt samen met opdrachtgevende organisatie en betrokken partijen de realisatie voor
Projecten hebben een voorbereidingsfase, "voorfase" genoemd, voorafgaand aan de realisatiefase. Voor het uitvoeren van de voorfase zijn vertegenwoordigers van de opdrachtgevende organisatie, de beoogde beheerorganisatie en andere partijen betrokken die meewerken aan het realiseren van een deel van de op te leveren producten. Het doel van de voorfase is beeld krijgen van de te realiseren oplossing, van de risico's die zich tijdens realisatie kunnen voordoen en van de kaders waarbinnen de oplossing moet passen; tijdens de realisatiefase vinden bouw en onderhoud van de software en actualiseren en afronden van documentatie plaats.
M21: Het project selecteert medewerkers op basis van kwaliteit
Bij de inzet van medewerkers gaat kwaliteit boven andere aspecten, zoals beschikbaarheid, prijs en doorlooptijd.
M23: Het project zorgt voor de aanwezigheid van ervaring met de Kwaliteitsaanpak
De software delivery manager zorgt ervoor dat bij nieuwe projecten wordt gestart met ten minste twee projectleden die bekend zijn met de Kwaliteitsaanpak.
M05: Het project hanteert een iteratief en incrementeel ontwikkelproces
Projecten werken iteratief en incrementeel; dit betekent dat een project in korte iteraties werkt, waarbij elke iteratie een werkende versie van de software oplevert die extra waarde vertegenwoordigt voor de opdrachtgevende organisatie. Behalve de software werkt het project ook iedere iteratie alle andere producten bij. Elke iteratie worden verwachtingen en werkelijke resultaten vergeleken en wordt de werkwijze aangescherpt op basis van inzichten en bevindingen.
M35: Het project hanteert een agile architectuuraanpak
Tijdens de voorfase verwerkt het project de door de opdrachtgevende organisatie opgestelde projectstartarchitectuur (PSA) in een eerste versie van het softwarearchitectuurdocument (SAD). Tijdens de realisatiefase werkt het project het SAD bij op basis van nieuwe inzichten.
M10: Het project kent een wekelijks projectoverleg
De projectleider organiseert een periodiek projectoverleg. Dit overleg vindt wekelijks plaats en duurt niet langer dan een uur. Vereiste aanwezigen zijn de projectleider, de software delivery manager, de Scrummaster, een vertegenwoordiger uit elk van de Scrumteams en de kwaliteitsmanager van het project; andere aanwezigen kunnen zijn: de projectarchitect en de product owner. De agenda voor dit overleg bestaat ten minste uit de volgende onderwerpen: mededelingen, actie- en besluitenlijst, personele zaken, planning en voortgang, kwaliteit en architectuur, risico's en aandachtspunten.
M28: Het project voert periodiek een self-assessment uit tegen de actuele versie van de Kwaliteitsaanpak
De projectleider organiseert periodiek een self-assessment tegen de actuele versie van de Kwaliteitsaanpak en zet verbeteracties uit, waar nodig.
M30: Het project identificeert, mitigeert en bewaakt risico's
Het project identificeert, mitigeert en bewaakt projectspecifieke risico's voorafgaand aan en tijdens de projectuitvoering. Het project houdt een risicolog bij met geïdentificeerde risico's. De uitkomsten van de "Doordacht-van-Start-sessie", die al voorafgaand aan de start van het project wordt uitgevoerd, vormen het startpunt van deze risicolog. Risico's die tijdens de voorfase worden geïdentificeerd, bijvoorbeeld bij de productrisicoanalyse, worden toegevoegd aan de risicolog. Ook bij de start van de realisatiefase worden risicosessies gehouden met (vertegenwoordigers van) de belanghebbenden om verdere risico's te identificeren. Het project identificeert en implementeert mitigerende maatregelen danwel accepteert expliciet de geïdentificeerde risico's. Het project bewaakt de risicolog en uitvoering van de mitigerende maatregelen tijdens het IPO.
M34: Het project draagt software beheerst over
Als de software op enig moment door een andere partij dan ICTU verder ontwikkeld en/of onderhouden zal worden, draagt het project zorg voor een beheerste overdracht. Beheerdocumentatie, broncode en testmiddelen zijn van dusdanige kwaliteit en compleetheid dat de andere partij de software efficiënt en effectief kan doorontwikkelen en/of onderhouden.
M27: Het project sluit projectfasen en zichzelf expliciet af
Afsluiting van een projectfase gebeurt expliciet en gecontroleerd: alle producten, zoals documentatie, broncode, referentiedata en credentials, die in de af te sluiten fase nodig waren of zijn opgeleverd, worden gearchiveerd. Indien er geen volgende fase is voorzien op korte termijn, dienen alle producten van de laptops van de projectmedewerkers verwijderd te worden.

Organisatie

M29: ICTU organiseert voor aanvang van een project de interne dienstverlening
Voordat ICTU een softwareontwikkelproject start, dat gaat werken conform de Kwaliteitsaanpak, maakt de beoogde ICTU-projectleider afspraken met de afdelingen ICTU Software Diensten (ISD) en ICTU Software Expertise (ISE) over de af te nemen dienstverlening.
M19: ICTU biedt projecten een afgeschermde digitale omgeving
ICTU geeft de projecten de beschikking over eigen, afgeschermde digitale omgevingen, waarbinnen ze de door het project ontwikkelde software en tools kunnen installeren en waartoe op een beheerste manier toegang wordt verleend.
M18: ICTU biedt ondersteuning voor verplicht gestelde tools
ICTU zorgt voor technische en functionele ondersteuning aan projecten bij het gebruik van alle verplichte tools.
M11: ICTU beheert, onderhoudt en implementeert de Kwaliteitsaanpak en kwaliteitsnormen
ICTU beheert, onderhoudt en implementeert de Kwaliteitsaanpak en de kwaliteitsnormen. Aanpassingen zijn gebaseerd op praktijkervaring, nieuwe inzichten en nieuwe mogelijkheden voor meting en analyse. Iedere medewerker kan wijzigingsvoorstellen indienen bij ICTU. ICTU behandelt de wijzigingsvoorstellen, kiest de te nemen actie bij elk wijzigingsvoorstel en legt de wijzigingsvoorstellen en besluiten vast.
M12: ICTU publiceert nieuwe versies van de Kwaliteitsaanpak en normen periodiek en op een vaste locatie
ICTU publiceert periodiek een nieuwe versie van de Kwaliteitsaanpak en/of de kwaliteitsnormen op een vaste, bekende locatie.
M33: ICTU organiseert periodiek een gezamenlijke self-assessment ten aanzien van de Kwaliteitsaanpak
ICTU organiseert periodiek een gezamenlijke self-assessment ten aanzien van de Kwaliteitsaanpak die inzicht geeft in de huidige status van de Kwaliteitsaanpak en aanleiding kan geven tot het nemen van maatregelen om de Kwaliteitsaanpak en de ondersteuning daarvan door ICTU te verbeteren.
\ No newline at end of file +ICTU Kwaliteitsaanpak Softwareontwikkeling versie wipICTU logo

ICTU Kwaliteitsaanpak Softwareontwikkeling

Samenvatting

Versie wip, 02-08-2024

Inleiding

De overheid is in hoge mate afhankelijk van informatiesystemen voor de uitvoering van haar taken. Veel van die informatiesystemen zijn dusdanig specifiek dat de benodigde software “op maat” gemaakt moet worden. De totstandkoming van op maat gemaakte software is meestal een complex proces, waarin vele belangen en behoeften worden afgewogen en afgezet tegen de mogelijkheden die technologie biedt. Eenmaal operationeel zal een informatiesysteem verantwoord onderhouden moeten worden; behoeften en technologie veranderen in de loop van de tijd.

Overheidsprojecten waarin software wordt ontwikkeld of onderhouden kampen nog vaak met vertraging, budgetoverschrijding of een eindresultaat met te lage kwaliteit. Zo concludeerde de commissie-Elias in haar eindrapport: "De Rijksoverheid heeft haar ICT (Informatie- en communicatietechnologie)-projecten niet onder controle". Eén van de fundamentele problemen is dat de risico's, die inherent zijn aan softwareontwikkeling, door organisaties nog onvoldoende worden herkend, erkend en gemitigeerd. Dit terwijl de risico's bij de ontwikkeling van software, binnen het ICT-domein, algemeen bekend zijn en er ook voor veel risico's passende maatregelen bestaan.

ICTU heeft jarenlange ervaring met het realiseren van software en past de opgedane ervaring toe bij de ontwikkeling van nieuwe software. Die ervaring is vastgelegd in een werkwijze, deze “ICTU Kwaliteitsaanpak Softwareontwikkeling”, die telkens wordt aangepast en aangevuld op basis van de praktijk.

ICTU is ervan overtuigd dat het bouwen van duurzame software, die goed aansluit bij de behoeften van gebruikers en andere belanghebbenden, bijdraagt aan betere informatiesystemen en een betere dienstverlening door de overheid. Dienstverlening die betrouwbaar moet zijn voor burgers, bedrijven en ambtenaren. Om samen met opdrachtgevende organisaties passende oplossingen te realiseren ontwikkelt ICTU daarom software volgens een agile proces. En om de duurzaamheid en betrouwbaarheid te bevorderen besteedt ICTU standaard aandacht aan beveiliging, privacy, performance, gebruikskwaliteit en toegankelijkheid. De Kwaliteitsaanpak dient daarvoor als leidraad, maar de aanpak voorziet ook in mogelijkheden om het project en het eindproduct aan te passen aan de specifieke situatie.

Om projecten, die software realiseren volgens de Kwaliteitsaanpak, efficiënt en effectief te ondersteunen, heeft ICTU twee gespecialiseerde afdelingen in het leven geroepen. Deze afdelingen staan projecten bij door middel van kennis, menskracht en technische hulpmiddelen. Zo profiteren projecten van schaalgrootte en hergebruik van inzichten.

Met behulp van de ICTU Kwaliteitsaanpak Softwareontwikkeling heeft ICTU samen met andere overheden inmiddels enige tientallen projecten succesvol uitgevoerd. ICTU wil deze aanpak graag aanvullen met de ervaringen en geleerde lessen van andere organisaties en deze overdraagbaar maken en breder uitdragen. Om die reden stelt ICTU deze Kwaliteitsaanpak aan iedereen beschikbaar via https://www.ictu.nl/kwaliteitsaanpak en heeft zij, samen met normalisatie-instituut NEN en partijen uit overheid en markt, een praktijkrichtlijn “Risicobeheersing bij ontwikkeling en onderhoud van maatwerksoftware” [NEN NPR 5326:2019] gepubliceerd, die mede is gebaseerd op de ICTU Kwaliteitsaanpak Softwareontwikkeling.

Doelstellingen

De ICTU Kwaliteitsaanpak Softwareontwikkeling heeft drie doelstellingen:

  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 opdrachtgevende organisaties maatwerksoftware ontwikkelt en onderhoudt. ICTU hanteert daarbij de vuistregel dat als tenminste 80% van de projecten minstens 80% van de tijd een bepaalde werkwijze hanteren, voor die werkwijze een maatregel in de Kwaliteitsaanpak wordt opgenomen. Maar het kan ook voorkomen dat maatregelen om andere redenen landen in de Kwaliteitsaanpak; denk aan het toegankelijk maken van software dat wettelijk verplicht is. Zie ook de wijzigingsgeschiedenis in PDF-formaat of HTML-formaat.

De maatregelen vormen het startpunt voor de aanpak van ieder ICTU-softwareproject, waarbij ruimte wordt geboden voor variatie of alternatieve invulling. Bijvoorbeeld stelt de Kwaliteitsaanpak: software wordt minimaal bij iedere grote release of tenminste twee keer per jaar onderworpen aan een beveiligingstest door beveiligingsexperts die ICTU daarvoor inhuurt (zie M26: Het project laat de beveiliging van het ontwikkelde product periodiek beoordelen). Een alternatief is dat de opdrachtgevende organisatie de verantwoordelijkheid neemt voor het laten uitvoeren van beveiligingstests. Hierover maakt de projectleider nadere afspraken met de opdrachtgever.

De Kwaliteitsaanpak is dus zowel voorschrijvend als beschrijvend. Voorschrijvend omdat ICTU verwacht dat projecten die maatwerksoftware ontwikkelen en onderhouden de aanpak toepassen, en alleen aanpassen als daar een goede reden voor is, en mits dat wettelijk is toegestaan. Tegelijkertijd is de aanpak beschrijvend omdat de meeste maatregelen voortkomen uit de bestaande werkwijzen van de projecten. Zoals blijkt uit de self-assessment die ICTU regelmatig uitvoert op de toepassing van de Kwaliteitsaanpak.

Maatregelen

Hieronder zijn alle maatregeldefinities uit de Kwaliteitsaanpak opgenomen. Zie de Kwaliteitsaanpak zelf voor een uitgebreidere beschrijving van de maatregelen, inclusief context en rationale.

Producten

M31: Het project beschikt over actuele vastgestelde informatie
Voor een goede uitvoering van het project is specifieke informatie nodig. De opdrachtgevende organisatie zorgt dat het project bij de start van de voorfase inzicht heeft in de informatie die typisch wordt vastgelegd in een projectstartarchitectuur, business impact analysis en privacy impact assessment. Waar nodig werkt de opdrachtgevende organisatie de informatie bij tijdens de voorfase en realisatiefase.
M01: Het project levert in elke fase vastgestelde producten en informatie op
Iedere projectfase levert specifieke informatie op. De voorfase levert inzicht in de functionele en niet-functionele eisen, ontwerp en architectuur, testplannen, operationele risico's, en benodigde kwaliteitsmaatregelen. Deze informatie wordt tijdens de realisatiefase waar nodig bijgewerkt. De realisatiefase levert één of meerdere werkende versies van de software met regressietests, aangevuld met een vrijgaveadvies, release notes en installatiedocumentatie.
M32: Het project onderzoekt de kwaliteit van over te nemen software
Als tijdens een project bestaande software dient te worden afgebouwd, onderhouden en/of herbouwd, vindt een onderzoek plaats naar de kwaliteit van deze software.
M02: Het project bewaakt continu dat het product aan de kwaliteitsnormen voldoet
Projecten bewaken zo snel mogelijk vanaf de start de door het project en ICTU vastgestelde kwaliteitsnormen en voldoen daar zo snel en goed mogelijk aan. De kwaliteit van producten, die nog niet zijn afgerond of nog niet aan de normen voldoen, wordt door het project bewaakt. Het voldoen aan de kwaliteitsnormen is onderdeel van de Definition of Done en herstel van de kwaliteit wordt planmatig opgepakt.
M03: Het project zorgt dat het product traceerbaar aan eisen voldoet
Eisen zijn wederzijds traceerbaar naar bewijsmateriaal, zoals logische testgevallen, dat de eis gerealiseerd is; dat wil zeggen dat geadministreerd is bij welke eis bewijsmateriaal hoort en vice versa. Dit wordt waar mogelijk met tooling ondersteund.
M13: Het project gebruikt ISO-25010 voor de specificatie van productkwaliteitseisen
Voor specificatie en documentatie van vereiste en gewenste kwaliteitseigenschappen, de niet-functionele eisen, maken projecten gebruik van de terminologie en categorisering uit NEN-ISO/IEC 25010. Projecten gebruiken NEN-ISO/IEC 25010 om te controleren of alle relevante kwaliteitseigenschappen van het op te leveren eindproduct worden meegenomen in de ontwikkeling en/of onderhoud van het product.
M04: Het project borgt de correcte werking van het product met geautomatiseerde regressietests
Regressietests - tests die verifiëren of eerder ontwikkelde software nog steeds correct werkt na wijzigingen in de software of aansluiting op andere externe koppelvlakken - zijn geautomatiseerd.
M07: Het project gebruikt een continuous delivery pipeline om het product te bouwen, testen en op te leveren
Er is een geautomatiseerde continuous delivery pipeline die aantoonbaar correct werkt en de software bouwt, installeert in de testomgevingen, test op functionele en niet-functionele eigenschappen en oplevert, al dan niet inclusief installatie in de productieomgeving.
M16: Het project gebruikt tools voor vastgestelde taken
ICTU stelt het gebruik van tools verplicht voor de volgende taken:
  1. backlog management en agile werken,
  2. inrichten en uitvoeren van een continuous delivery pipeline,
  3. monitoren van de kwaliteit van broncode,
  4. versiebeheer van op te leveren producten,
  5. release van software,
  6. maken van testrapportages,
  7. maken van kwaliteitsrapportages,
  8. controleren van de configuratie op aanwezigheid van bekende kwetsbaarheden,
  9. controleren van door de applicatie gebruikte versies van externe software op aanwezigheid van bekende kwetsbaarheden,
  10. statische controle van de software op aanwezigheid van kwetsbare constructies,
  11. dynamische controle van de software op aanwezigheid van kwetsbare constructies,
  12. controleren van container images op aanwezigheid van bekende kwetsbaarheden,
  13. testen van performance en schaalbaarheid,
  14. testen op toegankelijkheid van de applicatie,
  15. produceren van een "software bill of materials" (SBoM),
  16. opslaan van artifacten,
  17. registratie van incidenten bij gebruik en beheer, en
  18. bij het uitvoeren van operationeel beheer; uitrollen van de software in de productieomgeving.
M08: Het project maakt technische schuld inzichtelijk en lost deze planmatig op
Technische schuld is inzichtelijk en wordt planmatig aangepakt. De kwaliteitsmanager is verantwoordelijk voor het inzichtelijk maken van de technische schuld. De software delivery manager is verantwoordelijk voor het planmatig aanpakken van de technische schuld en zorgt dat het Scrumteam regelmatig en voldoende tijd heeft om technische schuld te voorkomen en op te lossen. Het Scrumteam is verantwoordelijk voor het zoveel mogelijk voorkomen van technische schuld en voor het identificeren van technische schuld die toch optreedt.
M26: Het project laat de beveiliging van het ontwikkelde product periodiek beoordelen
Projecten laten periodiek de beveiliging van de ontwikkelde software beoordelen. Een beveiligingsexpert onderzoekt de code zowel geautomatiseerd als handmatig op veelvoorkomende kwetsbaarheden en op het voldoen aan voorgeschreven beveiligingsnormen. Overheidsspecifieke beveiligingsnormen of -raamwerken, zoals de BIO (Baseline Informatiebeveiliging Overheid), bieden een basis voor de beoordeling. Bevindingen uit de beveiligingstest worden vastgelegd als onderdeel van de werkvoorraad voor het ontwikkelproces.

Processen

M14: Het project bereidt samen met opdrachtgevende organisatie en betrokken partijen de realisatie voor
Projecten hebben een voorbereidingsfase, "voorfase" genoemd, voorafgaand aan de realisatiefase. Voor het uitvoeren van de voorfase zijn vertegenwoordigers van de opdrachtgevende organisatie, de beoogde beheerorganisatie en andere partijen betrokken die meewerken aan het realiseren van een deel van de op te leveren producten. Het doel van de voorfase is beeld krijgen van de te realiseren oplossing, van de risico's die zich tijdens realisatie kunnen voordoen en van de kaders waarbinnen de oplossing moet passen; tijdens de realisatiefase vinden bouw en onderhoud van de software en actualiseren en afronden van documentatie plaats.
M21: Het project selecteert medewerkers op basis van kwaliteit
Bij de inzet van medewerkers gaat kwaliteit boven andere aspecten, zoals beschikbaarheid, prijs en doorlooptijd.
M23: Het project zorgt voor de aanwezigheid van ervaring met de Kwaliteitsaanpak
De software delivery manager zorgt ervoor dat bij nieuwe projecten wordt gestart met ten minste twee projectleden die bekend zijn met de Kwaliteitsaanpak.
M05: Het project hanteert een iteratief en incrementeel ontwikkelproces
Projecten werken iteratief en incrementeel; dit betekent dat een project in korte iteraties werkt, waarbij elke iteratie een werkende versie van de software oplevert die extra waarde vertegenwoordigt voor de opdrachtgevende organisatie. Behalve de software werkt het project ook iedere iteratie alle andere producten bij. Elke iteratie worden verwachtingen en werkelijke resultaten vergeleken en wordt de werkwijze aangescherpt op basis van inzichten en bevindingen.
M35: Het project hanteert een agile architectuuraanpak
Tijdens de voorfase verwerkt het project de door de opdrachtgevende organisatie opgestelde projectstartarchitectuur (PSA) in een eerste versie van het softwarearchitectuurdocument (SAD). Tijdens de realisatiefase werkt het project het SAD bij op basis van nieuwe inzichten.
M10: Het project kent een wekelijks projectoverleg
De projectleider organiseert een periodiek projectoverleg. Dit overleg vindt wekelijks plaats en duurt niet langer dan een uur. Vereiste aanwezigen zijn de projectleider, de software delivery manager, de Scrummaster, een vertegenwoordiger uit elk van de Scrumteams en de kwaliteitsmanager van het project; andere aanwezigen kunnen zijn: de projectarchitect en de product owner. De agenda voor dit overleg bestaat ten minste uit de volgende onderwerpen: mededelingen, actie- en besluitenlijst, personele zaken, planning en voortgang, kwaliteit en architectuur, risico's en aandachtspunten.
M28: Het project voert periodiek een self-assessment uit tegen de actuele versie van de Kwaliteitsaanpak
De projectleider organiseert periodiek een self-assessment tegen de actuele versie van de Kwaliteitsaanpak en zet verbeteracties uit, waar nodig.
M30: Het project identificeert, mitigeert en bewaakt risico's
Het project identificeert, mitigeert en bewaakt projectspecifieke risico's voorafgaand aan en tijdens de projectuitvoering. Het project houdt een risicolog bij met geïdentificeerde risico's. De uitkomsten van de "Doordacht-van-Start-sessie", die al voorafgaand aan de start van het project wordt uitgevoerd, vormen het startpunt van deze risicolog. Risico's die tijdens de voorfase worden geïdentificeerd, bijvoorbeeld bij de productrisicoanalyse, worden toegevoegd aan de risicolog. Ook bij de start van de realisatiefase worden risicosessies gehouden met (vertegenwoordigers van) de belanghebbenden om verdere risico's te identificeren. Het project identificeert en implementeert mitigerende maatregelen danwel accepteert expliciet de geïdentificeerde risico's. Het project bewaakt de risicolog en uitvoering van de mitigerende maatregelen tijdens het IPO.
M34: Het project draagt software beheerst over
Als de software op enig moment door een andere partij dan ICTU verder ontwikkeld en/of onderhouden zal worden, draagt het project zorg voor een beheerste overdracht. Beheerdocumentatie, broncode en testmiddelen zijn van dusdanige kwaliteit en compleetheid dat de andere partij de software efficiënt en effectief kan doorontwikkelen en/of onderhouden.
M27: Het project sluit projectfasen en zichzelf expliciet af
Afsluiting van een projectfase gebeurt expliciet en gecontroleerd: alle producten, zoals documentatie, broncode, referentiedata en credentials, die in de af te sluiten fase nodig waren of zijn opgeleverd, worden gearchiveerd. Indien er geen volgende fase is voorzien op korte termijn, dienen alle producten van de laptops van de projectmedewerkers verwijderd te worden.

Organisatie

M29: ICTU organiseert voor aanvang van een project de interne dienstverlening
Voordat ICTU een softwareontwikkelproject start, dat gaat werken conform de Kwaliteitsaanpak, maakt de beoogde ICTU-projectleider afspraken met de afdelingen ICTU Software Diensten (ISD) en ICTU Software Expertise (ISE) over de af te nemen dienstverlening.
M19: ICTU biedt projecten een afgeschermde digitale omgeving
ICTU geeft de projecten de beschikking over eigen, afgeschermde digitale omgevingen, waarbinnen ze de door het project ontwikkelde software en tools kunnen installeren en waartoe op een beheerste manier toegang wordt verleend.
M18: ICTU biedt ondersteuning voor verplicht gestelde tools
ICTU zorgt voor technische en functionele ondersteuning aan projecten bij het gebruik van alle verplichte tools.
M11: ICTU beheert, onderhoudt en implementeert de Kwaliteitsaanpak en kwaliteitsnormen
ICTU beheert, onderhoudt en implementeert de Kwaliteitsaanpak en de kwaliteitsnormen. Aanpassingen zijn gebaseerd op praktijkervaring, nieuwe inzichten en nieuwe mogelijkheden voor meting en analyse. Iedere medewerker kan wijzigingsvoorstellen indienen bij ICTU. ICTU behandelt de wijzigingsvoorstellen, kiest de te nemen actie bij elk wijzigingsvoorstel en legt de wijzigingsvoorstellen en besluiten vast.
M12: ICTU publiceert nieuwe versies van de Kwaliteitsaanpak en normen periodiek en op een vaste locatie
ICTU publiceert periodiek een nieuwe versie van de Kwaliteitsaanpak en/of de kwaliteitsnormen op een vaste, bekende locatie.
M33: ICTU organiseert periodiek een gezamenlijke self-assessment ten aanzien van de Kwaliteitsaanpak
ICTU organiseert periodiek een gezamenlijke self-assessment ten aanzien van de Kwaliteitsaanpak die inzicht geeft in de huidige status van de Kwaliteitsaanpak en aanleiding kan geven tot het nemen van maatregelen om de Kwaliteitsaanpak en de ondersteuning daarvan door ICTU te verbeteren.
\ No newline at end of file diff --git a/docs/wip/ICTU-Kwaliteitsaanpak-Samenvatting.pdf b/docs/wip/ICTU-Kwaliteitsaanpak-Samenvatting.pdf deleted file mode 100644 index aa0a1b94..00000000 Binary files a/docs/wip/ICTU-Kwaliteitsaanpak-Samenvatting.pdf and /dev/null differ diff --git a/docs/wip/ICTU-Kwaliteitsaanpak-Wijzigingsgeschiedenis.html b/docs/wip/ICTU-Kwaliteitsaanpak-Wijzigingsgeschiedenis.html index 44420702..04cc1d27 100644 --- a/docs/wip/ICTU-Kwaliteitsaanpak-Wijzigingsgeschiedenis.html +++ b/docs/wip/ICTU-Kwaliteitsaanpak-Wijzigingsgeschiedenis.html @@ -1,2 +1,22 @@ -ICTU Kwaliteitsaanpak Softwareontwikkeling versie wipICTU logo

ICTU Kwaliteitsaanpak Softwareontwikkeling

Wijzigingsgeschiedenis

Versie wip, 31-07-2024

[Unreleased]

Alle documenten

Versie 4.0.0, 26 april 2024

Kwaliteitsaanpak

Samenvatting Kwaliteitsaanpak

Template Mastertestplan

Template Niet-Functionele Eisen

Template Kwaliteitsplan

Template Detailtestplan

Template Inwerkplan Kwaliteitsmanager

Alle templates

Self-assessment checklist

Alle documenten

Versie 3.0.1, 4 april 2023

Kwaliteitsaanpak

Template Kwaliteitsplan

Self-assessment checklist

Versie 3.0.0, 28 februari 2023

Kwaliteitsaanpak

Samenvatting Kwaliteitsaanpak

Template Niet-Functionele Eisen

Template High Level Design

Template Kwaliteitsplan

Template Generiek

Template Compacte Voorfase

Alle templates

Alle documenten

Versie 2.4.0, 12 januari 2022

Kwaliteitsaanpak

Template Kwaliteitsplan

Template Niet-Functionele Eisen

Template Plan van Aanpak Realisatiefase

Template Plan van Aanpak Voorfase

Template Generiek

Self-assessment checklist

Inwerkplan Kwaliteitsmanager

Versie 2.3.0, 14 mei 2021

Kwaliteitsaanpak

Samenvatting Kwaliteitsaanpak

Presentatie Kwaliteitsaanpak

Alle templates

Template Detailtestplan

Template Globaal Functioneel Ontwerp

Template Niet-Functionele Eisen

Template Kwaliteitsplan

Template Plan van Aanpak Voorfase

Template Plan van Aanpak Realisatiefase

Alle documenten

Versie 2.2.0, 27 januari 2021

Kwaliteitsaanpak

Template Projectvoorstel Voorfase

Template Projectvoorstel Realisatiefase

Template Kwaliteitsplan

Versie 2.1.0, 2 september 2020

Kwaliteitsaanpak

Alle templates

Template Projectvoorstel Realisatiefase

Generiek template

Template Kwaliteitsplan

Template Niet-Functionele Eisen

Versie 2.0.0, 29 april 2020

Versie 1.3.1, 1 mei 2019

Versie 1.3, 5 april 2019

Versie 1.2, 1 augustus 2018

Versie 1.1, 7 november 2017

Versie 1.0.2, 9 mei 2017

\ No newline at end of file +ICTU Kwaliteitsaanpak Softwareontwikkeling versie wipICTU logo

ICTU Kwaliteitsaanpak Softwareontwikkeling

Wijzigingsgeschiedenis

Versie wip, 02-08-2024

[Unreleased]

Kwaliteitsaanpak

Samenvatting Kwaliteitsaanpak

Wijzigingsgeschiedenis

Alle documenten

Versie 4.0.0, 26 april 2024

Kwaliteitsaanpak

Samenvatting Kwaliteitsaanpak

Template Mastertestplan

Template Niet-Functionele Eisen

Template Kwaliteitsplan

Template Detailtestplan

Template Inwerkplan Kwaliteitsmanager

Alle templates

Self-assessment checklist

Alle documenten

Versie 3.0.1, 4 april 2023

Kwaliteitsaanpak

Template Kwaliteitsplan

Self-assessment checklist

Versie 3.0.0, 28 februari 2023

Kwaliteitsaanpak

Samenvatting Kwaliteitsaanpak

Template Niet-Functionele Eisen

Template High Level Design

Template Kwaliteitsplan

Template Generiek

Template Compacte Voorfase

Alle templates

Alle documenten

Versie 2.4.0, 12 januari 2022

Kwaliteitsaanpak

Template Kwaliteitsplan

Template Niet-Functionele Eisen

Template Plan van Aanpak Realisatiefase

Template Plan van Aanpak Voorfase

Template Generiek

Self-assessment checklist

Inwerkplan Kwaliteitsmanager

Versie 2.3.0, 14 mei 2021

Kwaliteitsaanpak

Samenvatting Kwaliteitsaanpak

Presentatie Kwaliteitsaanpak

Alle templates

Template Detailtestplan

Template Globaal Functioneel Ontwerp

Template Niet-Functionele Eisen

Template Kwaliteitsplan

Template Plan van Aanpak Voorfase

Template Plan van Aanpak Realisatiefase

Alle documenten

Versie 2.2.0, 27 januari 2021

Kwaliteitsaanpak

Template Projectvoorstel Voorfase

Template Projectvoorstel Realisatiefase

Template Kwaliteitsplan

Versie 2.1.0, 2 september 2020

Kwaliteitsaanpak

Alle templates

Template Projectvoorstel Realisatiefase

Generiek template

Template Kwaliteitsplan

Template Niet-Functionele Eisen

Versie 2.0.0, 29 april 2020

Versie 1.3.1, 1 mei 2019

Versie 1.3, 5 april 2019

Versie 1.2, 1 augustus 2018

Versie 1.1, 7 november 2017

Versie 1.0.2, 9 mei 2017

\ No newline at end of file diff --git a/docs/wip/ICTU-Kwaliteitsaanpak-Wijzigingsgeschiedenis.pdf b/docs/wip/ICTU-Kwaliteitsaanpak-Wijzigingsgeschiedenis.pdf deleted file mode 100644 index a5e0d397..00000000 Binary files a/docs/wip/ICTU-Kwaliteitsaanpak-Wijzigingsgeschiedenis.pdf and /dev/null differ diff --git a/docs/wip/ICTU-Kwaliteitsaanpak.css b/docs/wip/ICTU-Kwaliteitsaanpak.css index e2c4bcb4..15c28b53 100644 --- a/docs/wip/ICTU-Kwaliteitsaanpak.css +++ b/docs/wip/ICTU-Kwaliteitsaanpak.css @@ -1,44 +1,102 @@ @import url("https://use.fontawesome.com/releases/v5.2.0/css/all.css"); +@page { + size: A4; /* DIN A4 standard, Europe */ + margin-top: 25mm; + margin-bottom: 25mm; +} + body { font-size: 12pt !important; color: #000 !important; - font-family: 'Muli', sans-serif; + font-family: "Muli", sans-serif; width: 680px; margin: auto; counter-reset: section; } -h1::before { +/* Front matter */ + +img[title="word-cloud"] { + width: 95%; + padding-top: 100px; +} + +/* Table of contents *.keep-together */ + +#toc { + counter-reset: toc-h1; +} + +#toc div.h1::before { + counter-increment: toc-h1; + content: counter(toc-h1) " "; + color: #2c64ad; + margin-left: -2em; + width: 2em; + position: absolute; +} + +#toc div.h1.bijlage::before { + counter-reset: toc-h1; + content: ""; +} + +#toc div.h1 { + margin-top: 1em; + margin-left: 2em; + counter-reset: toc-h2; +} + +#toc div.h1.bijlage { + margin-left: 0em; +} + +#toc div.h2.bijlage::before { + counter-increment: toc-h2; + content: counter(toc-h2, upper-alpha) " "; + color: #2c64ad; + margin-left: -2em; + width: 2em; + position: absolute; +} + +#toc div.h2::before { + counter-increment: toc-h2; + content: counter(toc-h1) "." counter(toc-h2) " "; + color: #2c64ad; + margin-left: -2em; + width: 2em; + position: absolute; +} + +#toc div.h2 { + margin-left: 4em; +} + +/* Headers */ + +h1:not(toc)::before { counter-increment: section; content: counter(section) " "; - color: #2C64AD; + color: #2c64ad; } h1 { line-height: 150%; - color: #2C64AD; + color: #2c64ad; font-size: 20pt; font-weight: bold; page-break-before: always; counter-reset: subsection; } -p.title { - margin-top: 30px; - color: #2C64AD; - font-size: 42pt; - font-weight: bold; - line-height: 130%; -} - -img[title='word-cloud'] { - width: 95%; - padding-top: 100px; +h1.toc::before { + content: ""; /* The table of contents title has no counter */ } -#bijlagen::before { - content: ""; /* The Bijlagen section has no counter */ +h1.toc { + counter-reset: section; } h2.bijlage::before { @@ -51,13 +109,9 @@ h2::before { content: counter(section) "." counter(subsection) " "; } -h2.toc::before { - content: ""; /* The table of contents title has no counter */ -} - h2 { margin-top: 20px; - color: #DB1778; + color: #db1778; font-size: 16pt; font-weight: bold; } @@ -67,17 +121,17 @@ h3 { color: black; font-size: 14pt; font-weight: bold; - margin-bottom: -15px; /* Remove vertical space between header and next element */ + margin-bottom: -15px; /* Remove vertical space between header and next element */ } h4 { font-size: 12pt; - color: #B500C7; - margin-bottom: -15px; /* Remove vertical space between header and next element */ + color: #b500c7; + margin-bottom: -15px; /* Remove vertical space between header and next element */ } h4.risk { - background-color: #4C76BA; + background-color: #4c76ba; color: white; padding: 1em; } @@ -88,14 +142,35 @@ h5 { font-weight: bold; } +#bijlagen::before { + content: ""; /* The Bijlagen section has no counter */ +} + +/* Paragraphs */ + +p.title { + margin-top: 30px; + color: #2c64ad; + font-size: 42pt; + font-weight: bold; + line-height: 130%; +} + +.keep-together { + page-break-inside: avoid; +} + +/* Tables */ + tr { page-break-inside: avoid; } -th,td { +th, +td { text-align: left; vertical-align: top; - background-color: #E6F6FD; + background-color: #e6f6fd; padding: 5px; padding-left: 10px; padding-right: 10px; @@ -103,9 +178,11 @@ th,td { } th { - background-color: #83D0F5; + background-color: #83d0f5; } +/* Numbered lists */ + ol { list-style-type: none; counter-reset: ol-item; @@ -114,15 +191,16 @@ ol { padding: 0; } -ol > li:before { +ol > li::before { counter-increment: ol-item; content: counter(ol-item) ". "; margin-left: -3em; position: absolute; + color: #4c76ba; } ol ol > li:before { - content: counters(item, ".") " "; /* Use nested counters when ol's are nested */ + content: counters(item, ".") " "; /* Use nested counters when ol's are nested */ } ol > li { @@ -141,29 +219,32 @@ ol.bijlage { margin-top: 0.1em; } +/* Bulleted lists */ + ul { padding-left: 1.2em; + list-style: none; } -ul > li { - /* Since we can't easily give the bullet a different color than the text, we use a SVG. */ - list-style-image: url('data:image/svg+xml,'); - padding-left: 1.7em; +ul > li::before { + content: "●"; + color: #4c76ba; + display: inline-block; + width: 1.2em; + margin-left: -1.2em; } -.keep-together { - page-break-inside: avoid; -} +/* Domain specific styles */ .maatregel { - background-color: #E6F6FD; + background-color: #e6f6fd; border-style: solid; border-width: 1px; padding: 1em; } .risk { - background-color: #4C76BA; + background-color: #4c76ba; color: white; padding: 1em; } diff --git a/docs/wip/ICTU-Kwaliteitsaanpak.docx b/docs/wip/ICTU-Kwaliteitsaanpak.docx new file mode 100644 index 00000000..12b1fdf1 Binary files /dev/null and b/docs/wip/ICTU-Kwaliteitsaanpak.docx differ diff --git a/docs/wip/ICTU-Kwaliteitsaanpak.html b/docs/wip/ICTU-Kwaliteitsaanpak.html index 8097d318..d165b2a6 100644 --- a/docs/wip/ICTU-Kwaliteitsaanpak.html +++ b/docs/wip/ICTU-Kwaliteitsaanpak.html @@ -1,2 +1,22 @@ -ICTU Kwaliteitsaanpak Softwareontwikkeling versie wipICTU logo

ICTU Kwaliteitsaanpak Softwareontwikkeling

Versie wip, 31-07-2024

Inleiding

De overheid is in hoge mate afhankelijk van informatiesystemen voor de uitvoering van haar taken. Veel van die informatiesystemen zijn dusdanig specifiek dat de benodigde software “op maat” gemaakt moet worden. De totstandkoming van op maat gemaakte software is meestal een complex proces, waarin vele belangen en behoeften worden afgewogen en afgezet tegen de mogelijkheden die technologie biedt. Eenmaal operationeel zal een informatiesysteem verantwoord onderhouden moeten worden; behoeften en technologie veranderen in de loop van de tijd.

Overheidsprojecten waarin software wordt ontwikkeld of onderhouden kampen nog vaak met vertraging, budgetoverschrijding of een eindresultaat met te lage kwaliteit. Zo concludeerde de commissie-Elias in haar eindrapport: "De Rijksoverheid heeft haar ICT (Informatie- en communicatietechnologie)-projecten niet onder controle". Eén van de fundamentele problemen is dat de risico's, die inherent zijn aan softwareontwikkeling, door organisaties nog onvoldoende worden herkend, erkend en gemitigeerd. Dit terwijl de risico's bij de ontwikkeling van software, binnen het ICT-domein, algemeen bekend zijn en er ook voor veel risico's passende maatregelen bestaan.

ICTU heeft jarenlange ervaring met het realiseren van software en past de opgedane ervaring toe bij de ontwikkeling van nieuwe software. Die ervaring is vastgelegd in een werkwijze, deze “ICTU Kwaliteitsaanpak Softwareontwikkeling”, die telkens wordt aangepast en aangevuld op basis van de praktijk.

ICTU is ervan overtuigd dat het bouwen van duurzame software, die goed aansluit bij de behoeften van gebruikers en andere belanghebbenden, bijdraagt aan betere informatiesystemen en een betere dienstverlening door de overheid. Dienstverlening die betrouwbaar moet zijn voor burgers, bedrijven en ambtenaren. Om samen met opdrachtgevende organisaties passende oplossingen te realiseren ontwikkelt ICTU daarom software volgens een agile proces. En om de duurzaamheid en betrouwbaarheid te bevorderen besteedt ICTU standaard aandacht aan beveiliging, privacy, performance, gebruikskwaliteit en toegankelijkheid. De Kwaliteitsaanpak dient daarvoor als leidraad, maar de aanpak voorziet ook in mogelijkheden om het project en het eindproduct aan te passen aan de specifieke situatie.

Om projecten, die software realiseren volgens de Kwaliteitsaanpak, efficiënt en effectief te ondersteunen, heeft ICTU twee gespecialiseerde afdelingen in het leven geroepen. Deze afdelingen staan projecten bij door middel van kennis, menskracht en technische hulpmiddelen. Zo profiteren projecten van schaalgrootte en hergebruik van inzichten.

Met behulp van de ICTU Kwaliteitsaanpak Softwareontwikkeling heeft ICTU samen met andere overheden inmiddels enige tientallen projecten succesvol uitgevoerd. ICTU wil deze aanpak graag aanvullen met de ervaringen en geleerde lessen van andere organisaties en deze overdraagbaar maken en breder uitdragen. Om die reden stelt ICTU deze Kwaliteitsaanpak aan iedereen beschikbaar via https://www.ictu.nl/kwaliteitsaanpak en heeft zij, samen met normalisatie-instituut NEN en partijen uit overheid en markt, een praktijkrichtlijn “Risicobeheersing bij ontwikkeling en onderhoud van maatwerksoftware” [NEN NPR 5326:2019] gepubliceerd, die mede is gebaseerd op de ICTU Kwaliteitsaanpak Softwareontwikkeling.

Doelstellingen en uitgangspunten

De ICTU Kwaliteitsaanpak Softwareontwikkeling heeft drie doelstellingen:

  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 opdrachtgevende organisaties maatwerksoftware ontwikkelt en onderhoudt. ICTU hanteert daarbij de vuistregel dat als tenminste 80% van de projecten minstens 80% van de tijd een bepaalde werkwijze hanteren, voor die werkwijze een maatregel in de Kwaliteitsaanpak wordt opgenomen. Maar het kan ook voorkomen dat maatregelen om andere redenen landen in de Kwaliteitsaanpak; denk aan het toegankelijk maken van software dat wettelijk verplicht is. Zie ook de wijzigingsgeschiedenis in PDF-formaat of HTML-formaat.

De maatregelen vormen het startpunt voor de aanpak van ieder ICTU-softwareproject, waarbij ruimte wordt geboden voor variatie of alternatieve invulling. Bijvoorbeeld stelt de Kwaliteitsaanpak: software wordt minimaal bij iedere grote release of tenminste twee keer per jaar onderworpen aan een beveiligingstest door beveiligingsexperts die ICTU daarvoor inhuurt (zie M26: Het project laat de beveiliging van het ontwikkelde product periodiek beoordelen). Een alternatief is dat de opdrachtgevende organisatie de verantwoordelijkheid neemt voor het laten uitvoeren van beveiligingstests. Hierover maakt de projectleider nadere afspraken met de opdrachtgever.

De Kwaliteitsaanpak is dus zowel voorschrijvend als beschrijvend. Voorschrijvend omdat ICTU verwacht dat projecten die maatwerksoftware ontwikkelen en onderhouden de aanpak toepassen, en alleen aanpassen als daar een goede reden voor is, en mits dat wettelijk is toegestaan. Tegelijkertijd is de aanpak beschrijvend omdat de meeste maatregelen voortkomen uit de bestaande werkwijzen van de projecten. Zoals blijkt uit de self-assessment die ICTU regelmatig uitvoert op de toepassing van de Kwaliteitsaanpak.

Leeswijzer

Doelgroep

Dit document "ICTU Kwaliteitsaanpak Softwareontwikkeling", verder ook aangeduid met 'de Kwaliteitsaanpak', is bedoeld voor software en gerelateerde producten, voor processen waarmee die producten worden gerealiseerd en voor de overkoepelende organisatie waarin op projectbasis wordt gewerkt (ICTU). Dit betekent dat deze Kwaliteitsaanpak betrekking heeft op de drie aspecten van softwareontwikkeling:

  1. Producten - Het eerste deel van de Kwaliteitsaanpak betreft de eigenschappen van de ontwikkelde producten. De broncode valt hieronder, maar ook alle andere producten, zoals eisen, ontwerpen en testscripts.
  2. Processen - Het tweede deel gaat over het ontwikkelproces; werkwijze, gebruik van hulpmiddelen en projectaanpak.
  3. Organisatie - Het derde deel betreft de organisatie waarbinnen projecten worden uitgevoerd: ICTU; dit gaat over de samenhang tussen projecten en de faciliteiten die projecten ter beschikking moeten hebben.

Maatregelen

Om de risico's die samenhangen met softwareontwikkeling te mitigeren treft ICTU risicobeheersmaatregelen. Deze risicobeheersmaatregelen, verder maatregelen genoemd, vormen de kern van de Kwaliteitsaanpak. De maatregelen zijn onderverdeeld naar de genoemde aspecten product, proces en organisatie.

De onderverdeling is in overeenstemming met de praktijkrichtlijn “Risicobeheersing bij ontwikkeling en onderhoud van maatwerksoftware” [NEN NPR 5326:2019]. Deze praktijkrichtlijn beschrijft veelvoorkomende risico's van maatwerksoftwareontwikkeling en adviseert bijbehorende risicobeheersmaatregelen. Bijlage Relatie met NEN NPR 5326 beschrijft hoe de maatregelen in deze Kwaliteitsaanpak samenhangen met de maatregelen die de NPR 5326 adviseert.

De beschrijving van elke maatregel is voorzien van een rationale: waarom behoort de maatregel tot de Kwaliteitsaanpak? Waar mogelijk verwijst de rationale naar maatregelen uit standaarden en richtlijnen die overeenkomen met de door ICTU getroffen maatregelen.

Rollen

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:

Ondersteuning

Projecten bij ICTU die software ontwikkelen en/of onderhouden volgens deze Kwaliteitsaanpak, kunnen ondersteuning krijgen van de afdelingen ICTU Software Diensten (ISD) en ICTU Software Expertise (ISE). ISD levert ontwikkel- en testomgevingen, tools en ondersteunende diensten. ISE levert expertise in de vorm van software delivery managers, kwaliteitsmanagers en software-ontwikkelaars. ISE onderhoudt tevens deze Kwaliteitsaanpak. ISD en ISE zijn niet verantwoordelijk voor de projectuitvoering, maar voor het bieden van expertise en diensten om projecten in staat te stellen efficiënt en effectief volgens de Kwaliteitsaanpak te werken.

Versionering

Elke release van de Kwaliteitsaanpak heeft een versienummer in de vorm majornummer.minornummer.patchnummer.

Terminologie

Deze Kwaliteitsaanpak heeft betrekking op de ICTU-projecten waarin software ontwikkeld wordt. De terminologie in dit document is daarop afgestemd en sluit, waar relevant, aan op andere begrippenkaders. De bijlage Terminologie en afkortingen bevat een lijst met veel gebruikte begrippen en afkortingen.

Producten

M31: Het project beschikt over actuele vastgestelde informatie

M31: Het project beschikt over actuele vastgestelde informatie
Voor een goede uitvoering van het project is specifieke informatie nodig. De opdrachtgevende organisatie zorgt dat het project bij de start van de voorfase inzicht heeft in de informatie die typisch wordt vastgelegd in een projectstartarchitectuur, business impact analysis en privacy impact assessment. Waar nodig werkt de opdrachtgevende organisatie de informatie bij tijdens de voorfase en realisatiefase.

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 opdrachtgevende organisatie en beheerorganisatie.

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 opdrachtgevende organisatie vertaald naar aan het product te stellen eisen. Een PSA bevat in ieder geval de volgende onderwerpen:

Zie https://www.noraonline.nl/wiki/PSA.

Conform NORA werkt de opdrachtgevende organisatie na de start van het project de PSA uit in een solution architectuur (SA).

Zie https://www.noraonline.nl/wiki/Solution-architectuur.

Business impact analysis

In een business impact analysis (BIA) legt de opdrachtgevende organisatie vast hoe belangrijk informatiebeveiliging is voor de eigen bedrijfsvoering/processen. Naast de gevoeligheid voor incidenten komt hierin ook de 'risk appetite' van de organisatie tot uiting: de risico’s die een organisatie bereid is te accepteren. Alleen de opdrachtgevende organisatie zelf kan hierover een uitspraak doen.

Privacy impact assessment

In een privacy impact assessment (PIA) legt de opdrachtgevende organisatie vast wat de privacy-gevoeligheid is van de gegevens die in een proces of informatiesysteem worden verzameld en verwerkt. De rechtmatigheid van de verwerking wordt beoordeeld. En de PIA stelt grenzen aan de gegevens die mogen worden verzameld en verwerkt. Zicht op privacygevoelige gegevens en het (laten) treffen van adequate en afdoende beschermingsmaatregelen is een wettelijke plicht die een organisatie niet aan een andere partij kan overdragen.

Als een PIA niet nodig is, dan is een verklaring daaromtrent vereist.

Afspraken tussen opdrachtgevende organisatie en beheerorganisatie

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 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 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 opdrachtgevende organisatie, en is in de regel lastig op korte termijn te organiseren.

M01: Het project levert in elke fase vastgestelde producten en informatie op

M01: Het project levert in elke fase vastgestelde producten en informatie op
Iedere projectfase levert specifieke informatie op. De voorfase levert inzicht in de functionele en niet-functionele eisen, ontwerp en architectuur, testplannen, operationele risico's, en benodigde kwaliteitsmaatregelen. Deze informatie wordt tijdens de realisatiefase waar nodig bijgewerkt. De realisatiefase levert één of meerdere werkende versies van de software met regressietests, aangevuld met een vrijgaveadvies, release notes en installatiedocumentatie.

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: ICTU organiseert voor aanvang van een project de interne dienstverlening.

De onderstaande tabel bevat de in deze paragraaf beschreven producten. Het ✔ geeft aan in welke fase ze worden opgeleverd.

ProductVoor startVoorfaseRealisatiefaseVerantwoordelijke organisatie
Projectstartarchitectuur✔opdrachtgever
Business impact analysis✔opdrachtgever
Privacy impact assessment✔opdrachtgever
Plan van aanpak: voorfase✔ICTU
Beschrijving van functionele eisen✔✔opdrachtgever
Beschrijving van niet-functionele eisen✔✔opdrachtgever
Product backlog✔✔opdrachtgever
Ontwerp- en architectuurdocumentatie✔✔ICTU, beheerorganisatie
Mastertestplan✔✔opdrachtgever
Detailtestplannen✔✔ICTU, beheerorganisatie
Informatiebeveiligingsplan✔✔opdrachtgever
Kwaliteitsplan✔✔ICTU
Plan van aanpak: realisatiefase✔ICTU
Deploybare versie van de software✔ICTU
Testrapportages✔ICTU, beheerorganisatie
Documentatie voor deployment en operationeel beheer✔ICTU
Software bill of materials✔ICTU
Release notes✔ICTU
Vrijgaveadvies✔opdrachtgever

Projectstartarchitectuur, business impact analysis en privacy impact assessment

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. Zie M31: Het project beschikt over actuele vastgestelde informatie.

Plan van aanpak

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 tijdens de realisatiefase van het project bestaande software dient te worden afgebouwd, onderhouden en/of herbouwd, bevat het plan van aanpak voor de voorfase een onderzoek naar de kwaliteit van deze software, zie M32: Het project onderzoekt de kwaliteit van over te nemen software.

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:

Beschrijving van functionele eisen

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

Niet-functionele eisen specificeren criteria om het functioneren van de software te beoordelen, maar beschrijven niet het specifieke gedrag zelf. Voor de beschrijving en onderverdeling van niet-functionele eisen maakt het project gebruik van:

De beschrijving van niet-functionele eisen moet expliciet aandacht besteden aan de door de beoogd beheerder gewenste ondersteuning van beheerfuncties. Bepaalde niet-functionele eisen kunnen aanleiding zijn tot het treffen van beveiligingsmaatregelen. Door deze eisen expliciet in de voorfase te benoemen, wordt voorkomen dat de bijbehorende beveiligingsmaatregelen achteraf moeten worden toegevoegd.

Overheidsorganisaties moeten een toegankelijkheidsverklaring op hun websites plaatsen. Indien gewenst ondersteunt ICTU bij het opstellen van de toegankelijkheidsverklaring.

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:

Product backlog

De product backlog is een geprioriteerd overzicht van alle nog te realiseren functionele en niet-functionele eigenschappen van de software. Al het werk dat het Scrumteam doet loopt via de backlog, niet alleen werk aan de broncode zelf maar bijvoorbeeld ook het schrijven van beheerdocumentatie. De product owner is de eigenaar van de product backlog. De zaken op de lijst zijn normaal gesproken in de vorm van een epic of user story. Hierin staat:

De product owner is verantwoordelijk voor de inhoud en bepaalt de prioritering van de eisen. Er staan ook ruwe schattingen bij van de waarde voor de organisatie en van de ontwikkelkosten.

Zie https://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog.

Ontwerp- en architectuurdocumentatie

De ontwerp- en architectuurdocumentatie beschrijft de opzet van de te bouwen software in de context waarbinnen deze moet opereren en de ontwerpkeuzes en -principes die zijn gevolgd. Die documentatie laat tevens zien hoe de software aan de gestelde functionele en niet-functionele eisen voldoet.

Het project legt ontwerp- en architectuurinformatie vast in verschillende documenten en producten, zoals een softwarearchitectuurdocument (SAD), een infrastructuurarchitectuur (IA), een globaal functioneel ontwerp (GFO) en een prototype en/of interactieontwerp.

Het softwarearchitectuurdocument verschaft een compleet overzicht van de architectuur van de te ontwikkelen software, en de rationale hiervoor, waarbij diverse relevante views diverse aspecten van de software belichten. Zie bijvoorbeeld https://www.win.tue.nl/~wstomv/edu/2ip30/references/Kruchten-4+1-view.pdf; andere manieren van architectuurbeschrijving zijn ook toegestaan.

De infrastructuurarchitectuur beschrijft de topologie van de implementatie-omgeving waaronder protocollen, beveiligingsniveaus en services. Deze architectuur biedt een logische afbeelding van de eisen naar de implementatie-omgeving en geeft onderbouwing voor de gemaakte keuzes.

Een prototype is een eerste, ruwe versie van de applicatie. Het prototype illustreert waar men uiteindelijk met de toepassing naar toe wil. Het maakt ideeën tastbaar en creëert een eerste indruk van structuur, ontwerp en functionaliteit.

Beschikbare templates:

Testplannen en -rapportages

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.

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.

Beschikbare templates:

Informatiebeveiligingsplan

Het informatiebeveiligingsplan vormt een praktisch toepasbaar document dat uitlegt binnen welke kaders bescherming geleverd wordt tegen welke dreigingen en met welke maatregelen die bescherming vorm krijgt. Mogelijke bronnen voor het informatiebeveiligingsplan zijn de business impact analysis (BIA), privacy impact assessment (PIA) en de threat and vulnerability assessment (TVA).

Het Besluit Voorschrift Informatiebeveiliging Rijksdienst 2007 (VIR 2007) bevat een methode om te komen tot een systematische aanpak van informatiebeveiliging. Eén van de vereisten van het VIR 2007 is dat voor elk informatiesysteem en voor elk verantwoordelijkheidsgebied een afhankelijkheids- en kwetsbaarheidsanalyse (A&K-analyse) wordt uitgevoerd.

Bij ICTU wordt daarvoor een TVA gebruikt. Hierin worden de betrouwbaarheidseisen, die aan de bedrijfsprocessen en dientengevolge aan het informatiesysteem of verantwoordelijkheidsgebied worden gesteld, tijdens een afhankelijkheidsanalyse geïnventariseerd. Vervolgens worden de bedreigingen geïdentificeerd en geanalyseerd. De TVA levert zodoende een deel van een traceerbare onderbouwing voor de te treffen beveiligingsmaatregelen. De TVA wordt tijdens de voorfase opgesteld op basis van de resultaten van de BIA, de eventuele PIA en de inhoud van de ontwerp- en architectuurdocumentatie.

Kwaliteitsplan

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 opdrachtgevende organisatie een overkoepelend kwaliteitsplan heeft zorgt het project dat het ICTU-kwaliteitsplan aansluit op het overkoepelende kwaliteitsplan.

Beschikbare templates:

Deploybare versie van de software

Het project levert deploybare versies van de software in een formaat dat is afgestemd met de beheerorganisatie.

Documentatie voor deployment en operationeel beheer

De deploymentdocumentatie bevat informatie over de eisen die een applicatie stelt aan een omgeving en de stappen die nodig zijn om de applicatie in die omgeving veilig te installeren en configureren. De documentatie bevat daartoe onder meer aanwijzingen voor de HTTP-header en -request-configuratie van de webserver en voor het verwijderen van overbodige header-informatie zoals de 'Server'-header. Ook zijn er aanwijzingen voor veilige configuratie(s) van (externe) toegang tot de beheerinterface. De documentatie bevat daarnaast in ieder geval een beschrijving van de protocollen en services die de applicatie aanbiedt, de protocollen, services en accounts die het product gebruikt en de protocollen, services en accounts die de applicatie gebruikt voor beheer.

De documentatie voor operationeel beheer bevat tenminste informatie over: back-up/recovery, procedures bij calamiteiten, regelmatig terugkerende beheeractiviteiten, opstart- en afsluitprocedures.

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

Voor elke release stelt het project release notes op: een overzicht van de wijzigingen in de release. Software delivery manager en opdrachtgever maken afspraken over de opzet van de release notes.

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 opdrachtgevende organisatie over nog openstaande testbevindingen en geconstateerde beveiligingsbevindingen; zie ook M26: Het project laat de beveiliging van het ontwikkelde product periodiek beoordelen en M16: Het project gebruikt tools voor vastgestelde taken. Als er issues zijn, bijvoorbeeld rondom kwaliteit of beveiliging, zijn deze voorzien van een beschrijving van de voorziene impact.

Samenhang voorfaseproducten

Relaties tussen producten: Projectstartarchitectuur (PSA), business impact analysis (BIA) en privacy impact assessment (PIA) zijn input voor de voorfase. Functionele eisen (FE), niet-functionele eisen (NFE), informatiebeveiligingsplan (IB), backlog (BL), ontwerp en architectuur (O&A), kwaliteitsplan (KP) en testplannen (TP) zijn de output van de voorfase. De relaties tussen de verschillende producten zijn als volgt. De projectstartarchitectuur vormt input voor functionele eisen en niet-functionele eisen. De business impact analyse vormt input voor de niet-functionele eisen en informatiebeveiligingsplan. De privacy impact analyse vormt input voor de niet-functionele eisen en het informatiebeveiligingsplan. De functionele eisen vormen input voor de backlog en voor ontwerp en architectuur. De niet-functionele eisen vormen input voor backlog, ontwerp en architectuur en kwaliteitsplan. Het informatiebeveiligingsplan vormt input voor ontwerp en architectuur en kwaliteitsplan. De backlog en ontwerp en architectuur, tenslotte, zijn input voor de testplannen.

Bovenstaande figuur laat de belangrijkste relaties zien tussen de verschillende producten die de input en output van de voorfase vormen. Naast de informatiestromen zoals door de pijlen weergegeven zijn er in de praktijk nog meer verbanden tussen de producten. Zo kan de gekozen oplossing in de architectuur van invloed zijn op de maatregelen in het informatiebeveiligingsplan of leiden niet-functionele eisen tot extra functionele eisen.

Rationale

Het uniformeren van op te leveren producten biedt voordelen voor planning (het is bekend welke producten gemaakt moeten worden), voor bemensing (het is bekend welke expertise nodig is) en voor het uitwisselen van medewerkers.

De voorgeschreven producten stellen de beheerorganisatie in staat om de opgeleverde software uit te rollen, te beheren en eventueel te onderhouden. Daarnaast is duidelijk welke eventueel openstaande punten er nog zijn. De voorgeschreven producten bieden voldoende verantwoording richting de ontvanger voor uitgevoerde werkzaamheden.

De genoemde producten uit de voorfase hebben tot doel om enerzijds de omvang, kosten en doorlooptijd van de realisatiefase te kunnen schatten en anderzijds om de kaders voor de realisatiefase te bepalen, zodat de scope, aanpak en oplossingsrichting in grote lijnen bekend zijn.

M32: Het project onderzoekt de kwaliteit van over te nemen software

M32: Het project onderzoekt de kwaliteit van over te nemen software
Als tijdens een project bestaande software dient te worden afgebouwd, onderhouden en/of herbouwd, vindt een onderzoek plaats naar de kwaliteit van deze software.

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: Het project levert in elke fase vastgestelde producten en informatie op, 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 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.

Als kader voor het onderzoek gebruikt ICTU de Nederlandse praktijkrichtlijn NEN NPR 5325:2017.

Rationale

De kwaliteit van software is van grote invloed op de inspanning benodigd voor het afbouwen, onderhouden en/of herbouwen van de software. Inzicht in die kwaliteit helpt bij het plannen van de realisatiefase.

M02: Het project bewaakt continu dat het product aan de kwaliteitsnormen voldoet

M02: Het project bewaakt continu dat het product aan de kwaliteitsnormen voldoet
Projecten bewaken zo snel mogelijk vanaf de start de door het project en ICTU vastgestelde kwaliteitsnormen en voldoen daar zo snel en goed mogelijk aan. De kwaliteit van producten, die nog niet zijn afgerond of nog niet aan de normen voldoen, wordt door het project bewaakt. Het voldoen aan de kwaliteitsnormen is onderdeel van de Definition of Done en herstel van de kwaliteit wordt planmatig opgepakt.

De kwaliteitsnormen voor het product zijn beschreven in de niet-functionele eisen, het informatiebeveiligingsplan, het kwaliteitsplan en deze Kwaliteitsaanpak, zie M01: Het project levert in elke fase vastgestelde producten en informatie op.

Om continu te bewaken dat het product aan de kwaliteitsnormen voldoet, voert het project de volgende activiteiten uit:

  1. Tijdens de voorfase: het project reviewt de deliverables periodiek.
  2. Tijdens de realisatiefase: het project bewaakt op dagelijkse basis en geautomatiseerd de kwaliteit van de software.
  3. Als operationeel beheer onderdeel is van de dienstverlening tijdens de realisatiefase: het project bewaakt op dagelijkse basis en geautomatiseerd het gedrag van de software in gebruik en beheer.
  4. Tijdens de realisatiefase: het project evalueert periodiek en handmatig de kwaliteitseigenschappen van de software die niet geautomatiseerd kunnen worden gemeten.
  5. Tijdens de realisatiefase: het project actualiseert en reviewt periodiek de documentatie.
  6. Indien nodig: de kwaliteitsmanager escaleert het langdurig niet halen van de kwaliteitsnormen.

Daarnaast voert het project periodiek een self-assessment uit tegen de actuele versie van de Kwaliteitsaanpak, zie M28: Het project voert periodiek een self-assessment uit tegen de actuele versie van de Kwaliteitsaanpak.

Voorfase: review documenten

Tijdens de voorfase wordt het voldoen aan de kwaliteitsnormen met behulp van reviews gecontroleerd, normaal gesproken elke sprint. Als onderdeel van het op te stellen kwaliteitsplan wordt tijdens de voorfase bepaald hoe het project de kwaliteit tijdens realisatie gaat controleren; voor producten die niet geautomatiseerd kunnen worden gecontroleerd, beschrijft het kwaliteitsplan een alternatieve aanpak. Als bijvoorbeeld door de gekozen technologie geen ondersteuning van het kwaliteitssysteem mogelijk is, kunnen periodieke, handmatige controles als alternatief ingezet worden.

Realisatiefase: geautomatiseerde kwaliteitsmeting

Tijdens de realisatiefase wordt de kwaliteit diverse malen per uur gemeten door Quality-time, een door ICTU ontwikkeld, open source, geautomatiseerd kwaliteitssysteem. De kwaliteitsmanager configureert de kwaliteitsrapportage in Quality-time en past waar nodig de normen aan, op basis van de projectspecifieke kwaliteitseisen.

Het Scrumteam kijkt dagelijks of er afwijkingen van de normen zijn en onderneemt actie, indien nodig. Ook de kwaliteitsmanager signaleert afwijkingen en meldt deze bij het Scrumteam tijdens de daily scrum en/of tijdens het projectoverleg.

Realisatiefase operationeel beheer: geautomatiseerde monitoring

Als operationeel beheer onderdeel is van de dienstverlening tijdens de realisatiefase monitort en test het project continue het gedrag van de software in gebruik en beheer. Hiertoe gebruikt het project operationele monitoringsoftware, bijvoorbeeld Nagios en/of Zabbix.

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: Het project laat de beveiliging van het ontwikkelde product periodiek beoordelen. 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

Documenten, die onderdeel uitmaken van het op te leveren projectresultaat, zijn zo veel mogelijk geactualiseerd; eventuele achterstand wordt planmatig weggewerkt. De kwaliteitscontrole van documenten gebeurt op basis van reviews. De auteur van een document en de software delivery manager zorgen dat de juiste reviewers benoemd zijn; hiertoe behoort in ieder geval de kwaliteitsmanager. De auteur van het document zorgt voor een correct versiebeheer van het document. De auteur koppelt aan de reviewers terug of en hoe het ontvangen commentaar is verwerkt in de volgende versie van het betreffende document.

Escalatie

Als de kwaliteitsnormen langdurig niet worden behaald heeft de kwaliteitsmanager de volgende escalatielijn:

Rationale

Vaak de kwaliteitsnormen bewaken maakt een actueel inzicht mogelijk. Projectleden kunnen snel reageren op afwijkingen, die in de regel ook pas recent zijn ontstaan en dus meestal gerelateerd zijn aan huidige activiteiten. Met name afwijkingen van de normen op het vlak van informatiebeveiliging en onderhoudbaarheid komen zo snel aan het licht en kunnen dan ook snel worden beoordeeld en - indien nodig en mogelijk - opgelost.

M03: Het project zorgt dat het product traceerbaar aan eisen voldoet

M03: Het project zorgt dat het product traceerbaar aan eisen voldoet
Eisen zijn wederzijds traceerbaar naar bewijsmateriaal, zoals logische testgevallen, dat de eis gerealiseerd is; dat wil zeggen dat geadministreerd is bij welke eis bewijsmateriaal hoort en vice versa. Dit wordt waar mogelijk met tooling ondersteund.

Functionele eisen in de vorm van user stories zijn gekoppeld aan logische testgevallen. Ontwerpdocumentatie in de vorm van use cases is gekoppeld aan logische testgevallen. ICTU gebruikt hiervoor Jira. Logische testgevallen zijn gekoppeld aan fysieke testgevallen. De fysieke testgevallen worden geannoteerd met een identifier van de logische testgevallen. Het project is verantwoordelijk voor het traceerbaar voldoen aan de eisen.

Niet-functionele eisen zijn input voor onder andere softwarearchitectuurdocument, mastertestplan en detailtestplannen. De traceerbaarheid hiervan is (nog) niet geadministreerd met behulp van tooling.

Rationale

Door eisen en testgevallen te koppelen en traceerbaar te maken, is het mogelijk de dekking van tests ten opzichte van eisen te bepalen. Logische testgevallen worden gekoppeld aan use cases om zo aan te tonen dat alle ontworpen en geïmplementeerde functionaliteit getest wordt. Logische testgevallen worden gekoppeld aan user stories om aan te tonen dat alle wijzigingen die in een sprint zijn gemaakt ook getest zijn.

M13: Het project gebruikt ISO-25010 voor de specificatie van productkwaliteitseisen

M13: Het project gebruikt ISO-25010 voor de specificatie van productkwaliteitseisen
Voor specificatie en documentatie van vereiste en gewenste kwaliteitseigenschappen, de niet-functionele eisen, maken projecten gebruik van de terminologie en categorisering uit NEN-ISO/IEC 25010. Projecten gebruiken NEN-ISO/IEC 25010 om te controleren of alle relevante kwaliteitseigenschappen van het op te leveren eindproduct worden meegenomen in de ontwikkeling en/of onderhoud van het product.

De standaard NEN-ISO/IEC 25010:2011, kortweg "ISO-25010", biedt een model voor het beschrijven van productkwaliteit. Kwaliteitseigenschappen zijn voorzien van een naam, definitie en classificatie. ISO-25010 dekt een breed spectrum van kwaliteitseigenschappen af.

Rationale

ISO-25010 biedt een model voor productkwaliteit. De standaard biedt geen concrete maatregelen, maar biedt wel een begrippenkader en dekt het volledige spectrum van mogelijk relevante kwaliteitseigenschappen af. Het gebruiken van een standaard voor specificatie van kwaliteit voorkomt miscommunicatie over kwaliteitseigenschappen en de breedte van de standaard zorgt ervoor dat alle relevante aspecten aan bod komen.

M04: Het project borgt de correcte werking van het product met geautomatiseerde regressietests

M04: Het project borgt de correcte werking van het product met geautomatiseerde regressietests
Regressietests - tests die verifiëren of eerder ontwikkelde software nog steeds correct werkt na wijzigingen in de software of aansluiting op andere externe koppelvlakken - zijn geautomatiseerd.

Het project hanteert een norm voor de dekking van regressietests, legt deze vast in Quality-time en bewaakt deze.

Rationale

Handmatig uitgevoerde regressietests zijn arbeidsintensief, foutgevoelig en afhankelijk van de aanwezigheid van specifieke medewerkers. Gelet op de vrijwel continue metingen op en leveringen van de software, zijn de nadelen van handmatige regressietests niet acceptabel. Door ze te automatiseren zijn ze herhaalbaar en kunnen ze onderdeel uitmaken van de continuous delivery pipeline.

M07: Het project gebruikt een continuous delivery pipeline om het product te bouwen, testen en op te leveren

M07: Het project gebruikt een continuous delivery pipeline om het product te bouwen, testen en op te leveren
Er is een geautomatiseerde continuous delivery pipeline die aantoonbaar correct werkt en de software bouwt, installeert in de testomgevingen, test op functionele en niet-functionele eigenschappen en oplevert, al dan niet inclusief installatie in de productieomgeving.

De geautomatiseerde continuous delivery pipeline voert ten minste de volgende activiteiten uit:

  1. Bouw van de software,
  2. Unit tests,
  3. Regressietests,
  4. Beveiligingstests,
  5. Performancetests,
  6. Toegankelijkheidstests,
  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 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.

Niet alle testen en controles kunnen altijd geautomatiseerd worden uitgevoerd. Denk aan kwaliteitscontroles op architectuurbeslissingen of het testen van toegankelijkheidseisen. Waar mogelijk wordt wel een zo groot mogelijk deel van de testen en controles geautomatiseerd en als onderdeel van de pipeline uitgevoerd.

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 opdrachtgevende organisaties en beheerorganisaties.

Rationale

Software incrementeel opleveren vereist dat de software frequent gebouwd, getest en opgeleverd kan worden. Om dit efficiënt en foutvrij te doen, dient het proces van bouwen, testen en opleveren geautomatiseerd te zijn; een continuous delivery pipeline faciliteert dit.

M16: Het project gebruikt tools voor vastgestelde taken

M16: Het project gebruikt tools voor vastgestelde taken
ICTU stelt het gebruik van tools verplicht voor de volgende taken:
  1. backlog management en agile werken,
  2. inrichten en uitvoeren van een continuous delivery pipeline,
  3. monitoren van de kwaliteit van broncode,
  4. versiebeheer van op te leveren producten,
  5. release van software,
  6. maken van testrapportages,
  7. maken van kwaliteitsrapportages,
  8. controleren van de configuratie op aanwezigheid van bekende kwetsbaarheden,
  9. controleren van door de applicatie gebruikte versies van externe software op aanwezigheid van bekende kwetsbaarheden,
  10. statische controle van de software op aanwezigheid van kwetsbare constructies,
  11. dynamische controle van de software op aanwezigheid van kwetsbare constructies,
  12. controleren van container images op aanwezigheid van bekende kwetsbaarheden,
  13. testen van performance en schaalbaarheid,
  14. testen op toegankelijkheid van de applicatie,
  15. produceren van een "software bill of materials" (SBoM),
  16. opslaan van artifacten,
  17. registratie van incidenten bij gebruik en beheer, en
  18. bij het uitvoeren van operationeel beheer; uitrollen van de software in de productieomgeving.

Onder het ondersteunen van "agile werken" vallen het opvoeren van eisen, het opvoeren van logische testgevallen, het koppelen van logische testgevallen aan eisen, het bijhouden van een werkvoorraad, het plannen van iteraties en het toewijzen van eisen aan iteraties. De 'eisen' worden, conform Scrumterminologie, geregistreerd als epics en/of user stories, de werkvoorraad als backlog en de iteraties als sprints.

ICTU adviseert en ondersteunt voor de genoemde taken onderstaande tools. Projecten gebruiken deze tools, of gelijkwaardige alternatieven:

  1. backlog management en agile werken: Azure DevOps of Jira,
  2. inrichten en uitvoeren van een continuous delivery pipeline: Jenkins, GitLab CI/CD (Continuous Integration, Delivery, and Deployment) of Azure DevOps,
  3. monitoren van de kwaliteit van broncode: SonarQube,
  4. versiebeheer van op te leveren producten: GitLab of Azure DevOps,
  5. release van software: Releaseserver in het ontwikkelplatform,
  6. maken van testrapportages: JUnit, Robot Framework, TestNG, of hiermee compatible tools,
  7. maken van kwaliteitsrapportages: Quality-time,
  8. controleren van de configuratie op aanwezigheid van bekende kwetsbaarheden in configuratie: OpenVAS (Vulnerability Assessment System),
  9. controleren op aanwezigheid van bekende kwetsbaarheden in externe software: OWASP (Open Web Application Security Project) Dependency-Check en/of Dependency-Track,
  10. statische controle van de software op aanwezigheid van kwetsbare constructies: SonarQube,
  11. dynamische controle van de software op aanwezigheid van kwetsbare constructies: OWASP ZAP (Zed Attack Proxy),
  12. controleren van container images op aanwezigheid van bekende kwetsbaarheden: Trivy,
  13. testen van performance en schaalbaarheid: JMeter en Performancetestrunner,
  14. testen op toegankelijkheid van de applicatie: Axe,
  15. produceren van een "software bill of materials" (SBoM): tools die een SBoM in CycloneDX-formaat (zie https://cyclonedx.org) genereren,
  16. opslaan van artifacten: Nexus of Harbor,
  17. registratie van incidenten bij gebruik en beheer: Jira, en
  18. bij het uitvoeren van operationeel beheer; uitrollen van de software in de productieomgeving: Ansible.

Rationale

Projecten hebben een redelijke vrijheid bij het kiezen en gebruiken van tools, maar voor een aantal taken is het gebruik verplicht gesteld. Deze tools zijn nodig voor een efficiënte uitvoering van de Kwaliteitsaanpak. Uniform gebruik van deze tools maakt het mogelijk koppeling tussen die tools voor alle projecten te standaardiseren; daarnaast bevordert het de uitwisselbaarheid van medewerkers en neemt het risico op het gebruik van onvolwassen tools af. Tot slot is het gebruik in een aantal gevallen, ten behoeve van informatiebeveiliging bij de overheid, verplicht.

M08: Het project maakt technische schuld inzichtelijk en lost deze planmatig op

M08: Het project maakt technische schuld inzichtelijk en lost deze planmatig op
Technische schuld is inzichtelijk en wordt planmatig aangepakt. De kwaliteitsmanager is verantwoordelijk voor het inzichtelijk maken van de technische schuld. De software delivery manager is verantwoordelijk voor het planmatig aanpakken van de technische schuld en zorgt dat het Scrumteam regelmatig en voldoende tijd heeft om technische schuld te voorkomen en op te lossen. Het Scrumteam is verantwoordelijk voor het zoveel mogelijk voorkomen van technische schuld en voor het identificeren van technische schuld die toch optreedt.

Technische schuld zijn eigenschappen van de software die de lange termijn inzetbaarheid en onderhoudbaarheid van de software bedreigen. Denk hierbij aan hoge complexiteit, lage testdekking, ontbrekende testsoorten en ontbrekende documentatie.

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 opdrachtgevende organisatie omdat het leveren van kwaliteit onderdeel van het werk is.

Rationale

De aanwezigheid van technische schuld heeft nadelige invloed op de kwaliteit van de eindproducten. Wel is het ontstaan van technische schuld gedurende een project vaak onvermijdelijk. Het is daarnaast ook mogelijk dat een deel van de technische schuld bij aanvang van het project al bestond en mogelijk niet wordt opgelost. In alle gevallen is het verstandig om te weten welke technische schuld bestaat. Om te voorkomen dat technische schuld niet wordt opgelost en uitsluitend toeneemt, is het zaak om het verminderen van technische schuld planmatig aan te pakken.

M26: Het project laat de beveiliging van het ontwikkelde product periodiek beoordelen

M26: Het project laat de beveiliging van het ontwikkelde product periodiek beoordelen
Projecten laten periodiek de beveiliging van de ontwikkelde software beoordelen. Een beveiligingsexpert onderzoekt de code zowel geautomatiseerd als handmatig op veelvoorkomende kwetsbaarheden en op het voldoen aan voorgeschreven beveiligingsnormen. Overheidsspecifieke beveiligingsnormen of -raamwerken, zoals de BIO (Baseline Informatiebeveiliging Overheid), bieden een basis voor de beoordeling. Bevindingen uit de beveiligingstest worden vastgelegd als onderdeel van de werkvoorraad voor het ontwikkelproces.

Software wordt minimaal bij iedere grote release of ten minste twee keer per jaar onderworpen aan een beveiligingstest door beveiligingsexperts die ICTU daarvoor inhuurt. Op basis van documentatie en architectuurstudie, crystalbox security audits (broncodescan) en penetratieaudits beoordelen deze experts of de software voldoet aan de projectspecifieke niet-functionele eisen met betrekking tot beveiliging, of bekende kwetsbaarheden (zoals bijvoorbeeld in de OWASP Top-10 genoemd) vermeden zijn en of voldoende invulling gegeven is aan de normen die vanuit BIO en SSD gelden.

ICTU zorgt ervoor dat de benodigde expertise op afroep beschikbaar gesteld kan worden aan projecten.

De opdrachtgevende organisatie kan een derde partij opdracht geven beveiligingstesten uit te voeren in een daarvoor door de opdrachtgevende organisatie beschikbaar gestelde omgeving. Dit kan zowel incidenteel als structureel worden ingericht. Als de opdrachtgevende organisatie dit structureel inricht en als deze beveiligingstesten voldoen aan de eisen die het project zou stellen, dan kunnen de opdrachtgevende organisatie en het project besluiten dat het project zelf geen beveiligingstesten laat uitvoeren. Afspraken hierover worden bij voorkeur al in de voorfase gemaakt, inclusief een controle dat de opdrachtgevende organisatie de benodigde contractuele mogelijkheden heeft beveiligingstesten uit te besteden. Het project ontvangt in dat geval de beveiligingstestrapportages van de opdrachtgevende organisatie.

De beveiligingstesten vinden altijd plaats in aanvulling op de door tools uitgevoerde continue beveiligingsanalyse van de gerealiseerde software. Bevindingen uit beveiligingstesten en de continue analyse die niet direct worden opgelost, worden in Jira als issue vastgelegd op de backlog van het project.

De kwaliteitsmanager van het project bewaakt de opvolging van de kritische beveiligingsissues. De kwaliteitsmanager bewaakt tevens of de beveiligingstesten voldoende frequent plaatsvinden, bij voorkeur door Quality-time te laten waarschuwen als het tijd is voor de volgende beveiligingstest.

Rationale

Het inschakelen van actuele, specifieke expertise vergroot de kans dat eventuele kwetsbaarheden in de gerealiseerde software tijdig herkend worden.

Processen

M14: Het project bereidt samen met opdrachtgevende organisatie en betrokken partijen de realisatie voor

M14: Het project bereidt samen met opdrachtgevende organisatie en betrokken partijen de realisatie voor
Projecten hebben een voorbereidingsfase, "voorfase" genoemd, voorafgaand aan de realisatiefase. Voor het uitvoeren van de voorfase zijn vertegenwoordigers van de opdrachtgevende organisatie, de beoogde beheerorganisatie en andere partijen betrokken die meewerken aan het realiseren van een deel van de op te leveren producten. Het doel van de voorfase is beeld krijgen van de te realiseren oplossing, van de risico's die zich tijdens realisatie kunnen voordoen en van de kaders waarbinnen de oplossing moet passen; tijdens de realisatiefase vinden bouw en onderhoud van de software en actualiseren en afronden van documentatie plaats.

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 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 opdrachtgevende organisatie, ICTU en andere betrokken partijen af welke onderdelen van de voorfase opnieuw moeten worden uitgevoerd. Denk bij significante wijzigingen aan grote aanpassingen aan de scope, het budget, de belanghebbenden en/of de planning van het project.

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 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: Het project levert in elke fase vastgestelde producten en informatie op. 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.

M21: Het project selecteert medewerkers op basis van kwaliteit

M21: Het project selecteert medewerkers op basis van kwaliteit
Bij de inzet van medewerkers gaat kwaliteit boven andere aspecten, zoals beschikbaarheid, prijs en doorlooptijd.

Rationale

Goede kwaliteit van producten ontstaat primair door het werk van mensen; standaardisatie, kwaliteitsnormen en monitoring zijn hulpmiddelen. De kans dat kwalitatief goede medewerkers ook goede producten maken, is groter dan bij minder goede medewerkers.

M23: Het project zorgt voor de aanwezigheid van ervaring met de Kwaliteitsaanpak

M23: Het project zorgt voor de aanwezigheid van ervaring met de Kwaliteitsaanpak
De software delivery manager zorgt ervoor dat bij nieuwe projecten wordt gestart met ten minste twee projectleden die bekend zijn met de Kwaliteitsaanpak.

Rationale

Het inzetten van teamleden die bekend zijn met de Kwaliteitsaanpak zorgt voor een soepeler start van een nieuw project omdat zij bekend zijn met de inhoud van de Kwaliteitsaanpak, zoals kwaliteitsnormen en tools, en omdat zij al doende nieuwe teamleden bekend kunnen maken met de Kwaliteitsaanpak.

M05: Het project hanteert een iteratief en incrementeel ontwikkelproces

M05: Het project hanteert een iteratief en incrementeel ontwikkelproces
Projecten werken iteratief en incrementeel; dit betekent dat een project in korte iteraties werkt, waarbij elke iteratie een werkende versie van de software oplevert die extra waarde vertegenwoordigt voor de opdrachtgevende organisatie. Behalve de software werkt het project ook iedere iteratie alle andere producten bij. Elke iteratie worden verwachtingen en werkelijke resultaten vergeleken en wordt de werkwijze aangescherpt op basis van inzichten en bevindingen.

ICTU gebruikt hiervoor Scrum, een raamwerk voor agile productontwikkeling. ICTU propageert de kernwaarden van Scrum en vereist de volgende onderdelen van Scrum:

  1. Scrumteam bestaand uit product owner, ontwikkelaars (zoals programmeurs, testers en ontwerpers) en Scrummaster,
  2. Proces met daily scrum, sprints, sprint planning, sprint review, sprint retrospective en sprint refinement,
  3. Definition of Ready en Definition of Done,
  4. Product backlog en sprint backlog.

Als operationeel beheer onderdeel is van de dienstverlening, past ICTU de DevOps-werkwijze toe door operationeel beheeractiviteiten te integreren in de Scrum-processen van het Scrumteam.

Rationale

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.

M35: Het project hanteert een agile architectuuraanpak

M35: Het project hanteert een agile architectuuraanpak
Tijdens de voorfase verwerkt het project de door de opdrachtgevende organisatie opgestelde projectstartarchitectuur (PSA) in een eerste versie van het softwarearchitectuurdocument (SAD). Tijdens de realisatiefase werkt het project het SAD bij op basis van nieuwe inzichten.

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 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 (solution) architectuur aan te passen.

Rationale

Maatwerksoftwareontwikkeling is per definitie het ontwikkelen van een nieuw product. In de praktijk blijkt dat tijdens de ontwikkeling van het product altijd nog zaken ontdekt worden die bij aanvang niet bekend waren, of waarvan het belang eerder niet op waarde werd geschat. Het initiële SAD zal dus in de praktijk altijd moeten worden bijgewerkt op basis van die nieuwe inzichten.

M10: Het project kent een wekelijks projectoverleg

M10: Het project kent een wekelijks projectoverleg
De projectleider organiseert een periodiek projectoverleg. Dit overleg vindt wekelijks plaats en duurt niet langer dan een uur. Vereiste aanwezigen zijn de projectleider, de software delivery manager, de Scrummaster, een vertegenwoordiger uit elk van de Scrumteams en de kwaliteitsmanager van het project; andere aanwezigen kunnen zijn: de projectarchitect en de product owner. De agenda voor dit overleg bestaat ten minste uit de volgende onderwerpen: mededelingen, actie- en besluitenlijst, personele zaken, planning en voortgang, kwaliteit en architectuur, risico's en aandachtspunten.

Het periodiek projectoverleg heet bij ICTU het "Intern Projectoverleg" of "IPO".

Nadere toelichting op de agenda:

Rationale

Het doel van het periodiek projectoverleg is alle betrokkenen op hetzelfde informatieniveau te brengen en te houden. Het overleg is intern om vrijuit te kunnen praten over personele zaken en risico's voor het project.

M28: Het project voert periodiek een self-assessment uit tegen de actuele versie van de Kwaliteitsaanpak

M28: Het project voert periodiek een self-assessment uit tegen de actuele versie van de Kwaliteitsaanpak
De projectleider organiseert periodiek een self-assessment tegen de actuele versie van de Kwaliteitsaanpak en zet verbeteracties uit, waar nodig.

Deze self-assessment geeft inzicht in de huidige status van het project en kan aanleiding geven tot het nemen van maatregelen binnen het project.

De projectleider identificeert de belangrijkste verschillen tussen Kwaliteitsaanpak en werkwijze in het project en rapporteert hierover aan ICTU. In overleg tussen projectleider en ICTU wordt besloten of het verschil tijdelijk of permanent wordt geaccepteerd. In het geval van tijdelijke acceptatie stelt de projectleider een verbeteractie op. Merk op dat de verbeteractie ook kan bestaan uit het opstellen van een verbetervoorstel voor de Kwaliteitsaanpak.

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 opdrachtgevende organisatie en andere betrokken partijen. Voor het uitvoeren en vastleggen van de self-assessment stelt ICTU een self-assessment formulier beschikbaar.

Rationale

Net als bij technische producten is het periodiek meten van de kwaliteit van belang om in controle te blijven. Aangezien veel maatregelen uit de Kwaliteitsaanpak zich niet geautomatiseerd laten meten, is menselijke inbreng nodig.

Omdat implementatie van maatregelen in een project tijd kost is de self-assessment gericht op het in kaart brengen van de belangrijkste verschillen tussen de Kwaliteitsaanpak en de in het project toegepaste werkwijze, maar niet op het uitputtend inventariseren van alle verschillen.

M30: Het project identificeert, mitigeert en bewaakt risico's

M30: Het project identificeert, mitigeert en bewaakt risico's
Het project identificeert, mitigeert en bewaakt projectspecifieke risico's voorafgaand aan en tijdens de projectuitvoering. Het project houdt een risicolog bij met geïdentificeerde risico's. De uitkomsten van de "Doordacht-van-Start-sessie", die al voorafgaand aan de start van het project wordt uitgevoerd, vormen het startpunt van deze risicolog. Risico's die tijdens de voorfase worden geïdentificeerd, bijvoorbeeld bij de productrisicoanalyse, worden toegevoegd aan de risicolog. Ook bij de start van de realisatiefase worden risicosessies gehouden met (vertegenwoordigers van) de belanghebbenden om verdere risico's te identificeren. Het project identificeert en implementeert mitigerende maatregelen danwel accepteert expliciet de geïdentificeerde risico's. Het project bewaakt de risicolog en uitvoering van de mitigerende maatregelen tijdens het IPO.

Rationale

Een flink deel van de risico's die komen kijken bij het ontwikkelen van software is beschreven in de Nederlandse praktijkrichtlijn NEN NPR 5326:2019. De richtlijn geeft voor de beschreven risico's beheersmaatregelen die organisaties kunnen implementeren. De maatregelen in deze Kwaliteitsaanpak komen grotendeels overeen met de beheersmaatregelen in NPR 5326.

Echter, naast generieke risico's loopt elke project ook projectspecifieke risico's die voortkomen uit de scope van het project (is bijvoorbeeld operationeel beheer binnen de scope) en de context waarin het wordt uitgevoerd (bijvoorbeeld software die bijzondere persoonsgevens verwerkt). Alleen door deze risico's voorafgaand aan en tijdens het project actief te identificeren en te mitigeren kan de potentiële impact ervan beperkt worden.

M34: Het project draagt software beheerst over

M34: Het project draagt software beheerst over
Als de software op enig moment door een andere partij dan ICTU verder ontwikkeld en/of onderhouden zal worden, draagt het project zorg voor een beheerste overdracht. Beheerdocumentatie, broncode en testmiddelen zijn van dusdanige kwaliteit en compleetheid dat de andere partij de software efficiënt en effectief kan doorontwikkelen en/of onderhouden.

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 opdrachtgevende organisatie en ontvangende partij, de criteria aan.

  1. De documentatie beschrijft de ontwikkel- en testomgeving die is toegepast (5.1),
  2. De functionele documentatie beschrijft gegevensmodellen, functionele indeling, koppelingen, berichtdefinities en workflows/processen (5.2),
  3. Als operationeel beheer onderdeel was van de dienstverlening: de operationele bedieningsinstructies beschrijven minimaal back-up/recovery, procedures bij calamiteiten, regelmatig terugkerende beheeractiviteiten en opstart- en afsluitprocedures (5.3),
  4. De productbacklog bevat de bekende bugs en wensen (5.4),
  5. De broncode kent een gezonde balans tussen isolatie, cohesie en koppeling (6.1),
  6. De broncode heeft een beperkte mate van duplicatie (6.2),
  7. De broncode heeft een beperkte mate van complexiteit (6.3),
  8. De broncode bevat geen of een beperkt aantal niet-afgeronde werkzaamheden ("todo's") (6.4).
  9. De tests raken een voldoende groot deel van de broncode (code dekking) (7.1),
  10. De tests raken een voldoende groot deel van de functionaliteit (functionele dekking) (7.2),
  11. De onderkende productrisico's zijn gedekt (7.3),
  12. Er is een regressietest beschikbaar (7.4),
  13. Er is traceerbaarheid van eisen naar testgevallen (7.5), en
  14. De testset is goed opgebouwd (7.6).

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.

M27: Het project sluit projectfasen en zichzelf expliciet af

M27: Het project sluit projectfasen en zichzelf expliciet af
Afsluiting van een projectfase gebeurt expliciet en gecontroleerd: alle producten, zoals documentatie, broncode, referentiedata en credentials, die in de af te sluiten fase nodig waren of zijn opgeleverd, worden gearchiveerd. Indien er geen volgende fase is voorzien op korte termijn, dienen alle producten van de laptops van de projectmedewerkers verwijderd te worden.

De software delivery manager is verantwoordelijk voor het archiveren. De software delivery manager geeft het Scrumteam opdracht de archivering voor te bereiden en geeft de afdeling ICTU Software Diensten (ISD) de opdracht de archivering uit te voeren.

Alle documentatie, broncode, referentiedata en credentials die tijdens de werkzaamheden nodig waren of zijn opgeleverd, worden gearchiveerd en van laptops van medewerkers verwijderd.

Rationale

Archiveren faciliteert het eventueel herstarten of overdragen van het project op een later tijdstip. Verwijderen neemt een onnodig risico op inbreuk op vertrouwelijkheid weg en vrijwaart projectmedewerkers en ICTU van verdenking en aansprakelijkheid wanneer een incident optreedt.

Het expliciet afsluiten van het project is conform Maatregel 14: "Archivering" uit de NEN NPR 5326:2019.

Organisatie

M29: ICTU organiseert voor aanvang van een project de interne dienstverlening

M29: ICTU organiseert voor aanvang van een project de interne dienstverlening
Voordat ICTU een softwareontwikkelproject start, dat gaat werken conform de Kwaliteitsaanpak, maakt de beoogde ICTU-projectleider afspraken met de afdelingen ICTU Software Diensten (ISD) en ICTU Software Expertise (ISE) over de af te nemen dienstverlening.

Voordat ICTU een project start en een overeenkomst sluit met de opdrachtgevende organisatie maakt de beoogde ICTU-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.

Merk op dat een project vaak ook externe dienstverlening nodig heeft, bijvoorbeeld security testen of onderhoudbaarheidstoetsen. Deze externe dienstverlening hoeft echter normaal gesproken niet voor de start van het project te worden ingekocht.

Rationale

Door tijdig de interne dienstverlening aan projecten te organiseren helpt ICTU startende projecten de Kwaliteitsaanpak succesvol in te zetten, zonder de dienstverlening aan bestaande projecten te hinderen.

M19: ICTU biedt projecten een afgeschermde digitale omgeving

M19: ICTU biedt projecten een afgeschermde digitale omgeving
ICTU geeft de projecten de beschikking over eigen, afgeschermde digitale omgevingen, waarbinnen ze de door het project ontwikkelde software en tools kunnen installeren en waartoe op een beheerste manier toegang wordt verleend.

ICTU ondersteunt dit met Docker en/of virtuele machines en een VLAN (Virtual local area network) per project. Een nieuwe afgeschermde digitale omgeving is binnen een werkweek na aanvraag beschikbaar.

De software delivery manager is verantwoordelijk voor het autoriseren van personen voor toegang tot de beveiligde projectomgeving. De afdeling ICTU Software Diensten (ISD) beheert de basisconfiguratie van de afgeschermde digitale omgevingen. Projecten wijken alleen in overleg met ISD af van de basisconfiguratie. Als bepaalde afwijkingen vaker voorkomen, kan dit leiden tot het maken van aanpassingen aan de basisconfiguratie.

Rationale

Door het bieden van een afgeschermde digitale omgeving zijn de afhankelijkheden en invloeden tussen projecten minimaal en worden beveiligingsrisico's verkleind.

M18: ICTU biedt ondersteuning voor verplicht gestelde tools

M18: ICTU biedt ondersteuning voor verplicht gestelde tools
ICTU zorgt voor technische en functionele ondersteuning aan projecten bij het gebruik van alle verplichte tools.

ICTU zorgt voor ondersteuning van de bij M16: Het project gebruikt tools voor vastgestelde taken verplicht gestelde tools. Een team van specialisten met kennis, ervaring en capaciteit is beschikbaar voor ondersteuning aan projecten.

Bij de selectie van tools ter ondersteuning van de projectuitvoering geeft ICTU de voorkeur aan open source tools. Ook tools die ICTU zelf ontwikkelt ter ondersteuning van softwareontwikkelprojecten worden bij voorkeur open source beschikbaar gesteld.

Rationale

De keuze om het gebruik van een aantal tools verplicht te stellen (M16: Het project gebruikt tools voor vastgestelde taken) volgt uit de belangrijke rol die die tools spelen in de ontwikkelstraat en in Quality-time, het kwaliteitssysteem van ICTU. Met de verplichting komt ook een verantwoordelijkheid: om projecten in staat te stellen snel en effectief met deze tools te werken, moeten die projecten ondersteund worden.

De verplicht gestelde tools zijn beperkt in aantal, bewezen en gangbaar; veel medewerkers zullen deze tools al kennen.

De voorkeur voor open source tools is conform de rationale uit NORA (Nederlandse Overheid Referentiearchitectuur) voor het gebruik van open source tools, zoals beschreven in NORA v3.0 drijfveer "Beleid open standaarden". De voorkeur voor het open source beschikbaar stellen van eigen ontwikkelde tools is conform de "Beleidsbrief vrijgeven van de broncode van overheidssoftware" van de staatssecretaris van Binnenlandse Zaken en Koninkrijksrelaties, 17 april 2020.

M11: ICTU beheert, onderhoudt en implementeert de Kwaliteitsaanpak en kwaliteitsnormen

M11: ICTU beheert, onderhoudt en implementeert de Kwaliteitsaanpak en kwaliteitsnormen
ICTU beheert, onderhoudt en implementeert de Kwaliteitsaanpak en de kwaliteitsnormen. Aanpassingen zijn gebaseerd op praktijkervaring, nieuwe inzichten en nieuwe mogelijkheden voor meting en analyse. Iedere medewerker kan wijzigingsvoorstellen indienen bij ICTU. ICTU behandelt de wijzigingsvoorstellen, kiest de te nemen actie bij elk wijzigingsvoorstel en legt de wijzigingsvoorstellen en besluiten vast.

De Kwaliteitsaanpak wordt voor ICTU onderhouden door de afdeling ICTU Software Expertise (ISE). Iedereen die betrokken is bij softwareontwikkelprojecten kan een wijzigingsvoorstel indienen bij het hoofd van de afdeling ISE; die zorgt voor behandeling van en besluitvorming over het wijzigingsvoorstel. De afdeling zorgt ook zelf voor actualisering van de Kwaliteitsaanpak, op basis van praktijkervaringen en nieuwe inzichten uit onder andere de gezamenlijkse self-assessment, zie M33: ICTU organiseert periodiek een gezamenlijke self-assessment ten aanzien van de Kwaliteitsaanpak.

Bij een verandering van de Kwaliteitsaanpak zorgt het hoofd van de afdeling ISE voor een passend implementatie- en verandertraject.

Rationale

Expliciet beheer en onderhoud van de ICTU Kwaliteitsaanpak Softwareontwikkeling is nodig om geleerde lessen, nieuwe inzichten uit bijvoorbeeld wetenschappelijke literatuur en nieuwe technische mogelijkheden voor meting en analyse te verwerken in de Kwaliteitsaanpak. De Kwaliteitsaanpak wordt door ICTU - en niet door een project - onderhouden, zodat deze bij meerdere projecten uniform kan worden toegepast.

M12: ICTU publiceert nieuwe versies van de Kwaliteitsaanpak en normen periodiek en op een vaste locatie

M12: ICTU publiceert nieuwe versies van de Kwaliteitsaanpak en normen periodiek en op een vaste locatie
ICTU publiceert periodiek een nieuwe versie van de Kwaliteitsaanpak en/of de kwaliteitsnormen op een vaste, bekende locatie.

De ICTU Kwaliteitsaanpak Softwareontwikkeling is te vinden via de ICTU-website (https://www.ictu.nl/kwaliteitsaanpak) en, inclusief templates en self-assessment checklist, op het ICTU Portaal (Sharepoint). Publicatie van een nieuwe versie wordt aangekondigd via een e-mail naar belanghebbenden en/of een bericht op MS Teams.

Rationale

Medewerkers moeten te allen tijde de actuele Kwaliteitsaanpak en -normen kunnen raadplegen. Welke versie actueel is en wanneer een nieuwe versie actueel wordt, is essentiële informatie voor de planning van werkzaamheden binnen de projecten en binnen de afdeling als geheel.

M33: ICTU organiseert periodiek een gezamenlijke self-assessment ten aanzien van de Kwaliteitsaanpak

M33: ICTU organiseert periodiek een gezamenlijke self-assessment ten aanzien van de Kwaliteitsaanpak
ICTU organiseert periodiek een gezamenlijke self-assessment ten aanzien van de Kwaliteitsaanpak die inzicht geeft in de huidige status van de Kwaliteitsaanpak en aanleiding kan geven tot het nemen van maatregelen om de Kwaliteitsaanpak en de ondersteuning daarvan door ICTU te verbeteren.

ICTU nodigt de lopende projecten jaarlijks uit om deel te nemen aan de gezamelijke self-assessment. Deelname door projecten is vrijwillig. Voor het doen van de self-assessment stelt ICTU een ondersteunend formulier beschikbaar.

De projecten identificeren aan de hand van het formulier de belangrijkste verschillen tussen Kwaliteitsaanpak en werkwijze in het project en rapporteren hierover aan ICTU.

ICTU voegt de self-assessments van de deelnemende projecten samen en maakt een analyse van de resultaten. De analyse gaat in op:

ICTU organiseert een bespreking van de analyse met de deelnemende projecten. Hieruit vloeiende verbeteracties voor de Kwaliteitsaanpak worden door ICTU geprioriteerd en via de backlog voor de Kwaliteitsaanpak afgehandeld. Bij grotere verbeteracties betrekt ICTU de kwaliteitsmanagers van de belanghebbende projecten.

De gezamenlijke self-assessment is een intern product en de niet-geanonimiseerde resultaten worden alleen gedeeld met de deelnemende projecten. De geanonimiseerde resultaten kunnen worden gedeeld met belanghebbenden en belangstellenden binnen en buiten ICTU.

Rationale

Door een gezamenlijke self-assessment te doen met meerdere projecten tegelijkertijd onstaat er inzicht in de mate waarin maatregelen van de Kwaliteitsaanpak toegepast worden en zinvol zijn. Het gesprek over de uitkomsten van de gezamenlijke self-assessment levert input voor verbetering van de Kwaliteitsaanpak zelf.

Bijlagen

Terminologie en afkortingen

De onderstaande tabel bevat afkortingen en termen die voorkomen in de ICTU Kwaliteitsaanpak Softwareontwikkeling en bijbehorende templates.

Term/afkortingToelichting
actoreen persoon die, of een extern informatiesysteem dat, een handeling verricht op het informatiesysteem
architectuureen beschrijving van de structuur van een systeem, inclusief onderdelen, relaties tussen die onderdelen en eigenschappen van die onderdelen en relaties
APIapplication programming interface
ARTautomatische regressietest
auditingVastlegging van de door een actor verrichte handelingen
authenticatiehet vaststellen van de identiteit van een actor
autorisatieaan een actor toegekende rechten
beheerorganisatieeen (samenwerkingsverband van) organisatie(s) die in opdracht van een opdrachtgevende organisatie het operationeel beheer, applicatief beheer en/of functioneel beheer van software uitvoert
BIAbusiness impact analysis
BIOBaseline Informatiebeveiliging Overheid
broncodesoftware in een vorm die leesbaar is voor mensen en de intentie van een programmeur uitdrukt
deploymentinstallatie van software op een systeem waardoor de software beschikbaar wordt gemaakt voor gebruik door actoren
developersDevelopers zijn de mensen in het Scrumteam die iedere sprint gecommitteerd zijn aan het maken van elk aspect van een bruikbaar increment [Scrumgids]
DevOpseen praktijk die tot doel heeft softwareontwikkeling en operationeel beheer samen te brengen
DoDdefinition of done
DoRdefinition of ready
gebruikskwaliteitmate waarin een systeem, product of dienst kan worden gebruikt door gespecificeerde gebruikers, voor het bereiken van gespecificeerde doelen, met effectiviteit, efficiëntie en tevredenheid in een gespecificeerde gebruikscontext
GFOglobaal functioneel ontwerp
IB-planinformatiebeveiligingsplan
informatiesysteemeen samenhangend geheel van gegevensverzamelingen en de daarbij behorende personen, procedures, processen en programmatuur alsmede de voor het informatiesysteem getroffen voorzieningen voor opslag, verwerking en communicatie [VIR 2007, NORA]
infrastructuurarchitectuureen architectuur die vooral de hardwareonderdelen en -relaties (housing, hardware, virtuals, standaard software en middleware) van een systeem beschrijft
IPOintern projectoverleg
ISDICTU Software Diensten, afdeling van ICTU die softwareontwikkelprojecten ondersteunt met ontwikkel- en testomgevingen, tools en diensten
ISEICTU Software Expertise, afdeling van ICTU die softwareontwikkelprojecten ondersteunt met expertise op het gebied van softwareontwikkeling en die de ICTU Kwaliteitsaanpak Softwareontwikkeling onderhoudt
ISOInternational Organization for Standardization
Jiratool om use cases, user stories, logische testgevallen en issues vast te leggen
klantreisalle directe en indirecte interactie van een klant of gebruiker met een product of dienst
KPIkey performance indicator
kwaliteitsmanagercontroleert en borgt de kwaliteit van software conform de vastgestelde eisen en de Kwaliteitsaanpak en rapporteert aan de projectleider
minimum viable productde eerste versie van een product of dienst, die zo vroeg mogelijk wordt uitgerold naar de gebruikers; het bevat net voldoende functionaliteit om het gestelde doel te behalen, en niet meer dan dat
MTPmaster testplan
MVPminimum viable product
NFEniet-functionele eis(en)
NORANederlandse Overheidsreferentie-architectuur
NPRNederlandse Praktijkrichtlijn
ontwikkelaarsOntwikkelaars (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 organisatieoverheidsorganisatie die opdracht geeft aan ICTU tot ontwikkeling en/of onderhoud van software
opdrachtgevermedewerker van de opdrachtgevende organisatie die eindverantwoordelijk is voor de opdracht aan ICTU
operationeel beheeractiviteiten 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
OTAPontwikkel, test, acceptatie, productie; gebruikt om verschillende soorten omgevingen aan te duiden
personaeen 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
PIAprivacy impact assessment
PKIpublic key infrastructure
PRAproductrisicoanalyse
Product ownerDe product owner is verantwoordelijk voor het maximaliseren van de waarde van het product, dat het resultaat is van het werk van het Scrumteam [Scrumgids]
programmatuurzie software
projecteen 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
projectleidermedewerker eindverantwoordelijk voor het projectresultaat - bij ICTU-softwareontwikkelprojecten is de projectleider een medewerker van ICTU
PSADe projectstartarchitectuur is een concreet en doelgericht ICT-architectuurkader waarbinnen het project moet worden uitgevoerd
PvEprogramma van eisen
Quality-timeeen door ICTU ontwikkeld, open source, geautomatiseerd kwaliteitssysteem
realisatiefasefase van een softwareontwikkelproject waarin de software daadwerkelijk wordt gebouwd en onderhouden, en bij een DevOps werkwijze ook operationeel wordt beheerd
regressietesttest die na een wijziging controleert of niet-gewijzigde delen van een systeem nog steeds correct functioneren
release noteseen overzicht van de wijzigingen in een release
releaseeen voor gebruik vrijgegeven versie van de software
SADsoftware-architectuurdocument
ScrumScrum is een lichtgewicht raamwerk dat mensen, teams en organisaties helpt om waarde te creёren door middel van adaptieve oplossingen voor complexe problemen [Scrumgids]
ScrummasterDe Scrummaster is verantwoordelijk voor het opzetten van Scrum, zoals staat beschreven in de Scrumgids [Scrumgids]
ScrumteamEen Scrumteam bestaat uit één Scrummaster, één product owner en ontwikkelaars (developers in de Scrumgids) [Scrumgids]
softwarearchitectuureen architectuur die vooral de softwareonderdelen en -relaties (processen, modules, interfaces, datamodel) van een systeem beschrijft
software delivery managerorganiseert het ontwikkelen en opleveren van software conform de vastgestelde eisen en de Kwaliteitsaanpak en rapporteert aan de projectleider
softwaresoftware is de verzameling instructies die bepalen wat een computer uitvoert en is uiteindelijk wat de gebruiker ziet, ervaart en waarmee hij interacteert
softwareontwikkelingeen activiteit die nieuwe software maakt en/of bestaande software aanpast
softwareontwikkelprojecteen project dat de oplevering van software als enige of voornaamste projectresultaat heeft
solution architectuurbeschrijving van de gewenste oplossing van een specifiek probleem, of het eindresultaat van een project [NORA]
technische schuldeigenschappen van de software die de lange-termijninzetbaarheid en onderhoudbaarheid bedreigen
TVAthreat and vulnerability assessment
usabilitygebruiksvriendelijkheid
use caseeen afgebakende eenheid van interactie tussen een actor en het systeem
UXuser experience
VIRVoorschrift Informatiebeveiliging Rijksdienst
VIRBIVoorschrift Informatiebeveiliging Rijksdienst Bijzondere Informatie
VMvirtual machine, virtuele machine
voorfasefase van een softwareontwikkelproject, voorafgaande aan de realisatiefase, waarin de uitgangspunten, risico's en randvoorwaarden voor de realisatiefase worden bepaald en waarin wordt gezorgd dat aan de randvoorwaarden wordt voldaan en dat voor zoveel mogelijk risico's maatregelen getroffen zijn
vrijgaveadviesadvies om een release vrij te geven voor ingebruikname, met een testverslag dat tenminste alle nog openstaande testbevindingen en geconstateerde beveiligingsbevindingen bevat

Bronnen

De onderstaande tabel verwijst naar regelmatig gebruikte bronnen.

BronToelichting
BIOBaseline Informatiebeveiliging Overheid.
ISO 9241-210:2019Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems.
NCSC ICT-beveiligingsrichtlijnen voor webapplicatiesDe ICT-beveiligingsrichtlijnen voor webapplicaties geven een leidraad voor veiliger ontwikkelen, beheren en aanbieden van webapplicaties en bijbehorende infrastructuur.
NEN-ISO/IEC 25010:2011Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models.
NEN-ISO/IEC 27001:2017Informatietechnologie - Beveiligingstechnieken - Managementsystemen voor informatiebeveiliging - Eisen
NEN-ISO/IEC 27002:2017Informatietechnologie - Beveiligingstechnieken - Praktijkrichtlijn met beheersmaatregelen op het gebied van informatiebeveiliging
NEN 7510:2017Informatiebeveiliging in de zorg.
NEN NPR 5325:2017Praktijkrichtlijn voor het overdragen van software.
NEN NPR 5326:2019Praktijkrichtlijn voor risicobeheersing bij softwareontwikkeling.
NORAReferentiearchitectuur voor de Nederlandse Overheid.
OWASP Top-10De OWASP Top-10 is een op consensus gebaseerd overzicht van de meest kritische beveiligingsrisico's voor webapplicaties.
ScrumgidsDe Scrum Gids - De Definitieve Gids voor Scrum: De Regels van het Spel.
VIR 2007Besluit Voorschrift Informatiebeveiliging Rijksdienst 2007.
VIRBI 2013Besluit Voorschrift Informatiebeveiliging Rijksdienst Bijzondere Informatie 2013.
Wbni 2018Wet Beveiliging Netwerk- en Informatiesystemen. Beschrijft de meldplicht en de zorgplicht die van toepassing zijn op organisaties die vitaal zijn én op digitale dienstverleners.

Overzicht maatregelen

Hieronder zijn alle maatregeldefinities uit deze Kwaliteitsaanpak opgenomen, op volgorde van maatregelnummer.

M01: Het project levert in elke fase vastgestelde producten en informatie op
Iedere projectfase levert specifieke informatie op. De voorfase levert inzicht in de functionele en niet-functionele eisen, ontwerp en architectuur, testplannen, operationele risico's, en benodigde kwaliteitsmaatregelen. Deze informatie wordt tijdens de realisatiefase waar nodig bijgewerkt. De realisatiefase levert één of meerdere werkende versies van de software met regressietests, aangevuld met een vrijgaveadvies, release notes en installatiedocumentatie.
M02: Het project bewaakt continu dat het product aan de kwaliteitsnormen voldoet
Projecten bewaken zo snel mogelijk vanaf de start de door het project en ICTU vastgestelde kwaliteitsnormen en voldoen daar zo snel en goed mogelijk aan. De kwaliteit van producten, die nog niet zijn afgerond of nog niet aan de normen voldoen, wordt door het project bewaakt. Het voldoen aan de kwaliteitsnormen is onderdeel van de Definition of Done en herstel van de kwaliteit wordt planmatig opgepakt.
M03: Het project zorgt dat het product traceerbaar aan eisen voldoet
Eisen zijn wederzijds traceerbaar naar bewijsmateriaal, zoals logische testgevallen, dat de eis gerealiseerd is; dat wil zeggen dat geadministreerd is bij welke eis bewijsmateriaal hoort en vice versa. Dit wordt waar mogelijk met tooling ondersteund.
M04: Het project borgt de correcte werking van het product met geautomatiseerde regressietests
Regressietests - tests die verifiëren of eerder ontwikkelde software nog steeds correct werkt na wijzigingen in de software of aansluiting op andere externe koppelvlakken - zijn geautomatiseerd.
M05: Het project hanteert een iteratief en incrementeel ontwikkelproces
Projecten werken iteratief en incrementeel; dit betekent dat een project in korte iteraties werkt, waarbij elke iteratie een werkende versie van de software oplevert die extra waarde vertegenwoordigt voor de opdrachtgevende organisatie. Behalve de software werkt het project ook iedere iteratie alle andere producten bij. Elke iteratie worden verwachtingen en werkelijke resultaten vergeleken en wordt de werkwijze aangescherpt op basis van inzichten en bevindingen.
M07: Het project gebruikt een continuous delivery pipeline om het product te bouwen, testen en op te leveren
Er is een geautomatiseerde continuous delivery pipeline die aantoonbaar correct werkt en de software bouwt, installeert in de testomgevingen, test op functionele en niet-functionele eigenschappen en oplevert, al dan niet inclusief installatie in de productieomgeving.
M08: Het project maakt technische schuld inzichtelijk en lost deze planmatig op
Technische schuld is inzichtelijk en wordt planmatig aangepakt. De kwaliteitsmanager is verantwoordelijk voor het inzichtelijk maken van de technische schuld. De software delivery manager is verantwoordelijk voor het planmatig aanpakken van de technische schuld en zorgt dat het Scrumteam regelmatig en voldoende tijd heeft om technische schuld te voorkomen en op te lossen. Het Scrumteam is verantwoordelijk voor het zoveel mogelijk voorkomen van technische schuld en voor het identificeren van technische schuld die toch optreedt.
M10: Het project kent een wekelijks projectoverleg
De projectleider organiseert een periodiek projectoverleg. Dit overleg vindt wekelijks plaats en duurt niet langer dan een uur. Vereiste aanwezigen zijn de projectleider, de software delivery manager, de Scrummaster, een vertegenwoordiger uit elk van de Scrumteams en de kwaliteitsmanager van het project; andere aanwezigen kunnen zijn: de projectarchitect en de product owner. De agenda voor dit overleg bestaat ten minste uit de volgende onderwerpen: mededelingen, actie- en besluitenlijst, personele zaken, planning en voortgang, kwaliteit en architectuur, risico's en aandachtspunten.
M11: ICTU beheert, onderhoudt en implementeert de Kwaliteitsaanpak en kwaliteitsnormen
ICTU beheert, onderhoudt en implementeert de Kwaliteitsaanpak en de kwaliteitsnormen. Aanpassingen zijn gebaseerd op praktijkervaring, nieuwe inzichten en nieuwe mogelijkheden voor meting en analyse. Iedere medewerker kan wijzigingsvoorstellen indienen bij ICTU. ICTU behandelt de wijzigingsvoorstellen, kiest de te nemen actie bij elk wijzigingsvoorstel en legt de wijzigingsvoorstellen en besluiten vast.
M12: ICTU publiceert nieuwe versies van de Kwaliteitsaanpak en normen periodiek en op een vaste locatie
ICTU publiceert periodiek een nieuwe versie van de Kwaliteitsaanpak en/of de kwaliteitsnormen op een vaste, bekende locatie.
M13: Het project gebruikt ISO-25010 voor de specificatie van productkwaliteitseisen
Voor specificatie en documentatie van vereiste en gewenste kwaliteitseigenschappen, de niet-functionele eisen, maken projecten gebruik van de terminologie en categorisering uit NEN-ISO/IEC 25010. Projecten gebruiken NEN-ISO/IEC 25010 om te controleren of alle relevante kwaliteitseigenschappen van het op te leveren eindproduct worden meegenomen in de ontwikkeling en/of onderhoud van het product.
M14: Het project bereidt samen met opdrachtgevende organisatie en betrokken partijen de realisatie voor
Projecten hebben een voorbereidingsfase, "voorfase" genoemd, voorafgaand aan de realisatiefase. Voor het uitvoeren van de voorfase zijn vertegenwoordigers van de opdrachtgevende organisatie, de beoogde beheerorganisatie en andere partijen betrokken die meewerken aan het realiseren van een deel van de op te leveren producten. Het doel van de voorfase is beeld krijgen van de te realiseren oplossing, van de risico's die zich tijdens realisatie kunnen voordoen en van de kaders waarbinnen de oplossing moet passen; tijdens de realisatiefase vinden bouw en onderhoud van de software en actualiseren en afronden van documentatie plaats.
M16: Het project gebruikt tools voor vastgestelde taken
ICTU stelt het gebruik van tools verplicht voor de volgende taken:
  1. backlog management en agile werken,
  2. inrichten en uitvoeren van een continuous delivery pipeline,
  3. monitoren van de kwaliteit van broncode,
  4. versiebeheer van op te leveren producten,
  5. release van software,
  6. maken van testrapportages,
  7. maken van kwaliteitsrapportages,
  8. controleren van de configuratie op aanwezigheid van bekende kwetsbaarheden,
  9. controleren van door de applicatie gebruikte versies van externe software op aanwezigheid van bekende kwetsbaarheden,
  10. statische controle van de software op aanwezigheid van kwetsbare constructies,
  11. dynamische controle van de software op aanwezigheid van kwetsbare constructies,
  12. controleren van container images op aanwezigheid van bekende kwetsbaarheden,
  13. testen van performance en schaalbaarheid,
  14. testen op toegankelijkheid van de applicatie,
  15. produceren van een "software bill of materials" (SBoM),
  16. opslaan van artifacten,
  17. registratie van incidenten bij gebruik en beheer, en
  18. bij het uitvoeren van operationeel beheer; uitrollen van de software in de productieomgeving.
M18: ICTU biedt ondersteuning voor verplicht gestelde tools
ICTU zorgt voor technische en functionele ondersteuning aan projecten bij het gebruik van alle verplichte tools.
M19: ICTU biedt projecten een afgeschermde digitale omgeving
ICTU geeft de projecten de beschikking over eigen, afgeschermde digitale omgevingen, waarbinnen ze de door het project ontwikkelde software en tools kunnen installeren en waartoe op een beheerste manier toegang wordt verleend.
M21: Het project selecteert medewerkers op basis van kwaliteit
Bij de inzet van medewerkers gaat kwaliteit boven andere aspecten, zoals beschikbaarheid, prijs en doorlooptijd.
M23: Het project zorgt voor de aanwezigheid van ervaring met de Kwaliteitsaanpak
De software delivery manager zorgt ervoor dat bij nieuwe projecten wordt gestart met ten minste twee projectleden die bekend zijn met de Kwaliteitsaanpak.
M26: Het project laat de beveiliging van het ontwikkelde product periodiek beoordelen
Projecten laten periodiek de beveiliging van de ontwikkelde software beoordelen. Een beveiligingsexpert onderzoekt de code zowel geautomatiseerd als handmatig op veelvoorkomende kwetsbaarheden en op het voldoen aan voorgeschreven beveiligingsnormen. Overheidsspecifieke beveiligingsnormen of -raamwerken, zoals de BIO (Baseline Informatiebeveiliging Overheid), bieden een basis voor de beoordeling. Bevindingen uit de beveiligingstest worden vastgelegd als onderdeel van de werkvoorraad voor het ontwikkelproces.
M27: Het project sluit projectfasen en zichzelf expliciet af
Afsluiting van een projectfase gebeurt expliciet en gecontroleerd: alle producten, zoals documentatie, broncode, referentiedata en credentials, die in de af te sluiten fase nodig waren of zijn opgeleverd, worden gearchiveerd. Indien er geen volgende fase is voorzien op korte termijn, dienen alle producten van de laptops van de projectmedewerkers verwijderd te worden.
M28: Het project voert periodiek een self-assessment uit tegen de actuele versie van de Kwaliteitsaanpak
De projectleider organiseert periodiek een self-assessment tegen de actuele versie van de Kwaliteitsaanpak en zet verbeteracties uit, waar nodig.
M29: ICTU organiseert voor aanvang van een project de interne dienstverlening
Voordat ICTU een softwareontwikkelproject start, dat gaat werken conform de Kwaliteitsaanpak, maakt de beoogde ICTU-projectleider afspraken met de afdelingen ICTU Software Diensten (ISD) en ICTU Software Expertise (ISE) over de af te nemen dienstverlening.
M30: Het project identificeert, mitigeert en bewaakt risico's
Het project identificeert, mitigeert en bewaakt projectspecifieke risico's voorafgaand aan en tijdens de projectuitvoering. Het project houdt een risicolog bij met geïdentificeerde risico's. De uitkomsten van de "Doordacht-van-Start-sessie", die al voorafgaand aan de start van het project wordt uitgevoerd, vormen het startpunt van deze risicolog. Risico's die tijdens de voorfase worden geïdentificeerd, bijvoorbeeld bij de productrisicoanalyse, worden toegevoegd aan de risicolog. Ook bij de start van de realisatiefase worden risicosessies gehouden met (vertegenwoordigers van) de belanghebbenden om verdere risico's te identificeren. Het project identificeert en implementeert mitigerende maatregelen danwel accepteert expliciet de geïdentificeerde risico's. Het project bewaakt de risicolog en uitvoering van de mitigerende maatregelen tijdens het IPO.
M31: Het project beschikt over actuele vastgestelde informatie
Voor een goede uitvoering van het project is specifieke informatie nodig. De opdrachtgevende organisatie zorgt dat het project bij de start van de voorfase inzicht heeft in de informatie die typisch wordt vastgelegd in een projectstartarchitectuur, business impact analysis en privacy impact assessment. Waar nodig werkt de opdrachtgevende organisatie de informatie bij tijdens de voorfase en realisatiefase.
M32: Het project onderzoekt de kwaliteit van over te nemen software
Als tijdens een project bestaande software dient te worden afgebouwd, onderhouden en/of herbouwd, vindt een onderzoek plaats naar de kwaliteit van deze software.
M33: ICTU organiseert periodiek een gezamenlijke self-assessment ten aanzien van de Kwaliteitsaanpak
ICTU organiseert periodiek een gezamenlijke self-assessment ten aanzien van de Kwaliteitsaanpak die inzicht geeft in de huidige status van de Kwaliteitsaanpak en aanleiding kan geven tot het nemen van maatregelen om de Kwaliteitsaanpak en de ondersteuning daarvan door ICTU te verbeteren.
M34: Het project draagt software beheerst over
Als de software op enig moment door een andere partij dan ICTU verder ontwikkeld en/of onderhouden zal worden, draagt het project zorg voor een beheerste overdracht. Beheerdocumentatie, broncode en testmiddelen zijn van dusdanige kwaliteit en compleetheid dat de andere partij de software efficiënt en effectief kan doorontwikkelen en/of onderhouden.

Relatie met NEN NPR 5326

De Nederlandse Praktijkrichtlijn "Risicobeheersing bij ontwikkeling en onderhoud van maatwerksoftware" [NEN NPR 5326:2019] beschrijft beheersmaatregelen voor een deel van de risico’s die inherent zijn aan softwareontwikkeling op maat. Onderstaande tabel laat de relatie zien tussen de risicobeheersmaatregelen uit de NPR 5326 en de maatregelen uit deze Kwaliteitsaanpak.

NPR 5326 risicobeheersmaatregelMaatregelen KwaliteitsaanpakToelichting
Maatregel 01: Belanghebbenden identificeren en betrekkenM14: Het project bereidt samen met opdrachtgevende organisatie en betrokken partijen de realisatie voorVoorafgaand aan en tijdens de voorfase identificeert en betrekt ICTU de belanghebbenden
Maatregel 02: Belangrijke niet-functionele eisen identificerenM01: Het project levert in elke fase vastgestelde producten en informatie opDe niet-functionele eisen zijn een van de uitkomsten van de voorfase
Maatregel 03: Belangrijke functionele eisen identificerenM01: Het project levert in elke fase vastgestelde producten en informatie opDe functionele eisen zijn een van de uitkomsten van de voorfase
Maatregel 04: Productdecompositie in incrementeel opleverbare delen met business-waardeM01: Het project levert in elke fase vastgestelde producten en informatie opDe product backlog is een van de uitkomsten van de voorfase
Maatregel 05: Technische schuld identificeren, inzichtelijk maken en planmatig oplossenM08: Het project maakt technische schuld inzichtelijk en lost deze planmatig op, M32: Het project onderzoekt de kwaliteit van over te nemen software
Maatregel 06: Oplossingsrichtingen verkennenM01: Het project levert in elke fase vastgestelde producten en informatie opTijdens de voorfase worden oplossingsrichtingen verkend, bijvoorbeeld met behulp van een prototype
Maatregel 07: Incrementele oplevering van het productM05: Het project hanteert een iteratief en incrementeel ontwikkelprocesICTU hanteert een iteratief en incrementeel ontwikkelproces
Maatregel 08: Iteratieve ontwikkelaanpakM05: Het project hanteert een iteratief en incrementeel ontwikkelprocesICTU hanteert een iteratief en incrementeel ontwikkelproces
Maatregel 09: Geautomatiseerde ontwikkelpijplijn inrichtenM07: Het project gebruikt een continuous delivery pipeline om het product te bouwen, testen en op te leveren
Maatregel 10: Voortdurend voldoen aan de eisen met regressietestsM04: Het project borgt de correcte werking van het product met geautomatiseerde regressietests
Maatregel 11: Voortgangsbewaking met burndown chartsM10: Het project kent een wekelijks projectoverlegProjecten bespreken de voortgang in het wekelijks projectoverleg aan de hand van backlog informatie uit het backlog management systeem
Maatregel 12: Een officiële producteigenaar met mandaatM05: Het project hanteert een iteratief en incrementeel ontwikkelprocesICTU hanteert Scrum, inclusief de rol van de product owner
Maatregel 13: Toepassen van een kwaliteitgedreven ontwikkelmethodeDe Kwaliteitsaanpak schrijft geen ontwikkelmethode voor aan de projecten; de borging van kwaliteitsnormen zal echter wel invloed hebben op de gevolgde ontwikkelmethode
Maatregel 14: ArchiveringM27: Het project sluit projectfasen en zichzelf expliciet af
Maatregel 15: Deugdelijke overdrachtM34: Het project draagt software beheerst over
Maatregel 16: Teams met specialistische kennis en hulpmiddelen ondersteunenM18: ICTU biedt ondersteuning voor verplicht gestelde tools, M19: ICTU biedt projecten een afgeschermde digitale omgeving
Maatregel 17: Continu risicomanagementM02: Het project bewaakt continu dat het product aan de kwaliteitsnormen voldoet, M10: Het project kent een wekelijks projectoverleg, M30: Het project identificeert, mitigeert en bewaakt risico'sProjecten voldoen continu aan de kwaliteitsnormen, identificeren en mitigeren projectspecifieke risico's en bespreken de risico's in het wekelijkse projectoverleg
\ No newline at end of file +ICTU Kwaliteitsaanpak Softwareontwikkeling versie wipICTU logo

ICTU Kwaliteitsaanpak Softwareontwikkeling

Versie wip, 02-08-2024

Inleiding

De overheid is in hoge mate afhankelijk van informatiesystemen voor de uitvoering van haar taken. Veel van die informatiesystemen zijn dusdanig specifiek dat de benodigde software “op maat” gemaakt moet worden. De totstandkoming van op maat gemaakte software is meestal een complex proces, waarin vele belangen en behoeften worden afgewogen en afgezet tegen de mogelijkheden die technologie biedt. Eenmaal operationeel zal een informatiesysteem verantwoord onderhouden moeten worden; behoeften en technologie veranderen in de loop van de tijd.

Overheidsprojecten waarin software wordt ontwikkeld of onderhouden kampen nog vaak met vertraging, budgetoverschrijding of een eindresultaat met te lage kwaliteit. Zo concludeerde de commissie-Elias in haar eindrapport: "De Rijksoverheid heeft haar ICT (Informatie- en communicatietechnologie)-projecten niet onder controle". Eén van de fundamentele problemen is dat de risico's, die inherent zijn aan softwareontwikkeling, door organisaties nog onvoldoende worden herkend, erkend en gemitigeerd. Dit terwijl de risico's bij de ontwikkeling van software, binnen het ICT-domein, algemeen bekend zijn en er ook voor veel risico's passende maatregelen bestaan.

ICTU heeft jarenlange ervaring met het realiseren van software en past de opgedane ervaring toe bij de ontwikkeling van nieuwe software. Die ervaring is vastgelegd in een werkwijze, deze “ICTU Kwaliteitsaanpak Softwareontwikkeling”, die telkens wordt aangepast en aangevuld op basis van de praktijk.

ICTU is ervan overtuigd dat het bouwen van duurzame software, die goed aansluit bij de behoeften van gebruikers en andere belanghebbenden, bijdraagt aan betere informatiesystemen en een betere dienstverlening door de overheid. Dienstverlening die betrouwbaar moet zijn voor burgers, bedrijven en ambtenaren. Om samen met opdrachtgevende organisaties passende oplossingen te realiseren ontwikkelt ICTU daarom software volgens een agile proces. En om de duurzaamheid en betrouwbaarheid te bevorderen besteedt ICTU standaard aandacht aan beveiliging, privacy, performance, gebruikskwaliteit en toegankelijkheid. De Kwaliteitsaanpak dient daarvoor als leidraad, maar de aanpak voorziet ook in mogelijkheden om het project en het eindproduct aan te passen aan de specifieke situatie.

Om projecten, die software realiseren volgens de Kwaliteitsaanpak, efficiënt en effectief te ondersteunen, heeft ICTU twee gespecialiseerde afdelingen in het leven geroepen. Deze afdelingen staan projecten bij door middel van kennis, menskracht en technische hulpmiddelen. Zo profiteren projecten van schaalgrootte en hergebruik van inzichten.

Met behulp van de ICTU Kwaliteitsaanpak Softwareontwikkeling heeft ICTU samen met andere overheden inmiddels enige tientallen projecten succesvol uitgevoerd. ICTU wil deze aanpak graag aanvullen met de ervaringen en geleerde lessen van andere organisaties en deze overdraagbaar maken en breder uitdragen. Om die reden stelt ICTU deze Kwaliteitsaanpak aan iedereen beschikbaar via https://www.ictu.nl/kwaliteitsaanpak en heeft zij, samen met normalisatie-instituut NEN en partijen uit overheid en markt, een praktijkrichtlijn “Risicobeheersing bij ontwikkeling en onderhoud van maatwerksoftware” [NEN NPR 5326:2019] gepubliceerd, die mede is gebaseerd op de ICTU Kwaliteitsaanpak Softwareontwikkeling.

Doelstellingen en uitgangspunten

De ICTU Kwaliteitsaanpak Softwareontwikkeling heeft drie doelstellingen:

  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 opdrachtgevende organisaties maatwerksoftware ontwikkelt en onderhoudt. ICTU hanteert daarbij de vuistregel dat als tenminste 80% van de projecten minstens 80% van de tijd een bepaalde werkwijze hanteren, voor die werkwijze een maatregel in de Kwaliteitsaanpak wordt opgenomen. Maar het kan ook voorkomen dat maatregelen om andere redenen landen in de Kwaliteitsaanpak; denk aan het toegankelijk maken van software dat wettelijk verplicht is. Zie ook de wijzigingsgeschiedenis in PDF-formaat of HTML-formaat.

De maatregelen vormen het startpunt voor de aanpak van ieder ICTU-softwareproject, waarbij ruimte wordt geboden voor variatie of alternatieve invulling. Bijvoorbeeld stelt de Kwaliteitsaanpak: software wordt minimaal bij iedere grote release of tenminste twee keer per jaar onderworpen aan een beveiligingstest door beveiligingsexperts die ICTU daarvoor inhuurt (zie M26: Het project laat de beveiliging van het ontwikkelde product periodiek beoordelen). Een alternatief is dat de opdrachtgevende organisatie de verantwoordelijkheid neemt voor het laten uitvoeren van beveiligingstests. Hierover maakt de projectleider nadere afspraken met de opdrachtgever.

De Kwaliteitsaanpak is dus zowel voorschrijvend als beschrijvend. Voorschrijvend omdat ICTU verwacht dat projecten die maatwerksoftware ontwikkelen en onderhouden de aanpak toepassen, en alleen aanpassen als daar een goede reden voor is, en mits dat wettelijk is toegestaan. Tegelijkertijd is de aanpak beschrijvend omdat de meeste maatregelen voortkomen uit de bestaande werkwijzen van de projecten. Zoals blijkt uit de self-assessment die ICTU regelmatig uitvoert op de toepassing van de Kwaliteitsaanpak.

Leeswijzer

Doelgroep

Dit document "ICTU Kwaliteitsaanpak Softwareontwikkeling", verder ook aangeduid met 'de Kwaliteitsaanpak', is bedoeld voor software en gerelateerde producten, voor processen waarmee die producten worden gerealiseerd en voor de overkoepelende organisatie waarin op projectbasis wordt gewerkt (ICTU). Dit betekent dat deze Kwaliteitsaanpak betrekking heeft op de drie aspecten van softwareontwikkeling:

  1. Producten - Het eerste deel van de Kwaliteitsaanpak betreft de eigenschappen van de ontwikkelde producten. De broncode valt hieronder, maar ook alle andere producten, zoals eisen, ontwerpen en testscripts.
  2. Processen - Het tweede deel gaat over het ontwikkelproces; werkwijze, gebruik van hulpmiddelen en projectaanpak.
  3. Organisatie - Het derde deel betreft de organisatie waarbinnen projecten worden uitgevoerd: ICTU; dit gaat over de samenhang tussen projecten en de faciliteiten die projecten ter beschikking moeten hebben.

Maatregelen

Om de risico's die samenhangen met softwareontwikkeling te mitigeren treft ICTU risicobeheersmaatregelen. Deze risicobeheersmaatregelen, verder maatregelen genoemd, vormen de kern van de Kwaliteitsaanpak. De maatregelen zijn onderverdeeld naar de genoemde aspecten product, proces en organisatie.

De onderverdeling is in overeenstemming met de praktijkrichtlijn “Risicobeheersing bij ontwikkeling en onderhoud van maatwerksoftware” [NEN NPR 5326:2019]. Deze praktijkrichtlijn beschrijft veelvoorkomende risico's van maatwerksoftwareontwikkeling en adviseert bijbehorende risicobeheersmaatregelen. Bijlage Relatie met NEN NPR 5326 beschrijft hoe de maatregelen in deze Kwaliteitsaanpak samenhangen met de maatregelen die de NPR 5326 adviseert.

De beschrijving van elke maatregel is voorzien van een rationale: waarom behoort de maatregel tot de Kwaliteitsaanpak? Waar mogelijk verwijst de rationale naar maatregelen uit standaarden en richtlijnen die overeenkomen met de door ICTU getroffen maatregelen.

Rollen

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:

Ondersteuning

Projecten bij ICTU die software ontwikkelen en/of onderhouden volgens deze Kwaliteitsaanpak, kunnen ondersteuning krijgen van de afdelingen ICTU Software Diensten (ISD) en ICTU Software Expertise (ISE). ISD levert ontwikkel- en testomgevingen, tools en ondersteunende diensten. ISE levert expertise in de vorm van software delivery managers, kwaliteitsmanagers en software-ontwikkelaars. ISE onderhoudt tevens deze Kwaliteitsaanpak. ISD en ISE zijn niet verantwoordelijk voor de projectuitvoering, maar voor het bieden van expertise en diensten om projecten in staat te stellen efficiënt en effectief volgens de Kwaliteitsaanpak te werken.

Versionering

Elke release van de Kwaliteitsaanpak heeft een versienummer in de vorm majornummer.minornummer.patchnummer.

Terminologie

Deze Kwaliteitsaanpak heeft betrekking op de ICTU-projecten waarin software ontwikkeld wordt. De terminologie in dit document is daarop afgestemd en sluit, waar relevant, aan op andere begrippenkaders. De bijlage Terminologie en afkortingen bevat een lijst met veel gebruikte begrippen en afkortingen.

Producten

M31: Het project beschikt over actuele vastgestelde informatie

M31: Het project beschikt over actuele vastgestelde informatie
Voor een goede uitvoering van het project is specifieke informatie nodig. De opdrachtgevende organisatie zorgt dat het project bij de start van de voorfase inzicht heeft in de informatie die typisch wordt vastgelegd in een projectstartarchitectuur, business impact analysis en privacy impact assessment. Waar nodig werkt de opdrachtgevende organisatie de informatie bij tijdens de voorfase en realisatiefase.

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 opdrachtgevende organisatie en beheerorganisatie.

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 opdrachtgevende organisatie vertaald naar aan het product te stellen eisen. Een PSA bevat in ieder geval de volgende onderwerpen:

Zie https://www.noraonline.nl/wiki/PSA.

Conform NORA werkt de opdrachtgevende organisatie na de start van het project de PSA uit in een solution architectuur (SA).

Zie https://www.noraonline.nl/wiki/Solution-architectuur.

Business impact analysis

In een business impact analysis (BIA) legt de opdrachtgevende organisatie vast hoe belangrijk informatiebeveiliging is voor de eigen bedrijfsvoering/processen. Naast de gevoeligheid voor incidenten komt hierin ook de 'risk appetite' van de organisatie tot uiting: de risico’s die een organisatie bereid is te accepteren. Alleen de opdrachtgevende organisatie zelf kan hierover een uitspraak doen.

Privacy impact assessment

In een privacy impact assessment (PIA) legt de opdrachtgevende organisatie vast wat de privacy-gevoeligheid is van de gegevens die in een proces of informatiesysteem worden verzameld en verwerkt. De rechtmatigheid van de verwerking wordt beoordeeld. En de PIA stelt grenzen aan de gegevens die mogen worden verzameld en verwerkt. Zicht op privacygevoelige gegevens en het (laten) treffen van adequate en afdoende beschermingsmaatregelen is een wettelijke plicht die een organisatie niet aan een andere partij kan overdragen.

Als een PIA niet nodig is, dan is een verklaring daaromtrent vereist.

Afspraken tussen opdrachtgevende organisatie en beheerorganisatie

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 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 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 opdrachtgevende organisatie, en is in de regel lastig op korte termijn te organiseren.

M01: Het project levert in elke fase vastgestelde producten en informatie op

M01: Het project levert in elke fase vastgestelde producten en informatie op
Iedere projectfase levert specifieke informatie op. De voorfase levert inzicht in de functionele en niet-functionele eisen, ontwerp en architectuur, testplannen, operationele risico's, en benodigde kwaliteitsmaatregelen. Deze informatie wordt tijdens de realisatiefase waar nodig bijgewerkt. De realisatiefase levert één of meerdere werkende versies van de software met regressietests, aangevuld met een vrijgaveadvies, release notes en installatiedocumentatie.

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: ICTU organiseert voor aanvang van een project de interne dienstverlening.

De onderstaande tabel bevat de in deze paragraaf beschreven producten. Het ✔ geeft aan in welke fase ze worden opgeleverd.

ProductVoor startVoorfaseRealisatiefaseVerantwoordelijke organisatie
Projectstartarchitectuur✔opdrachtgever
Business impact analysis✔opdrachtgever
Privacy impact assessment✔opdrachtgever
Plan van aanpak: voorfase✔ICTU
Beschrijving van functionele eisen✔✔opdrachtgever
Beschrijving van niet-functionele eisen✔✔opdrachtgever
Product backlog✔✔opdrachtgever
Ontwerp- en architectuurdocumentatie✔✔ICTU, beheerorganisatie
Mastertestplan✔✔opdrachtgever
Detailtestplannen✔✔ICTU, beheerorganisatie
Informatiebeveiligingsplan✔✔opdrachtgever
Kwaliteitsplan✔✔ICTU
Plan van aanpak: realisatiefase✔ICTU
Deploybare versie van de software✔ICTU
Testrapportages✔ICTU, beheerorganisatie
Documentatie voor deployment en operationeel beheer✔ICTU
Software bill of materials✔ICTU
Release notes✔ICTU
Vrijgaveadvies✔opdrachtgever

Projectstartarchitectuur, business impact analysis en privacy impact assessment

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. Zie M31: Het project beschikt over actuele vastgestelde informatie.

Plan van aanpak

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 tijdens de realisatiefase van het project bestaande software dient te worden afgebouwd, onderhouden en/of herbouwd, bevat het plan van aanpak voor de voorfase een onderzoek naar de kwaliteit van deze software, zie M32: Het project onderzoekt de kwaliteit van over te nemen software.

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:

Beschrijving van functionele eisen

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

Niet-functionele eisen specificeren criteria om het functioneren van de software te beoordelen, maar beschrijven niet het specifieke gedrag zelf. Voor de beschrijving en onderverdeling van niet-functionele eisen maakt het project gebruik van:

De beschrijving van niet-functionele eisen moet expliciet aandacht besteden aan de door de beoogd beheerder gewenste ondersteuning van beheerfuncties. Bepaalde niet-functionele eisen kunnen aanleiding zijn tot het treffen van beveiligingsmaatregelen. Door deze eisen expliciet in de voorfase te benoemen, wordt voorkomen dat de bijbehorende beveiligingsmaatregelen achteraf moeten worden toegevoegd.

Overheidsorganisaties moeten een toegankelijkheidsverklaring op hun websites plaatsen. Indien gewenst ondersteunt ICTU bij het opstellen van de toegankelijkheidsverklaring.

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:

Product backlog

De product backlog is een geprioriteerd overzicht van alle nog te realiseren functionele en niet-functionele eigenschappen van de software. Al het werk dat het Scrumteam doet loopt via de backlog, niet alleen werk aan de broncode zelf maar bijvoorbeeld ook het schrijven van beheerdocumentatie. De product owner is de eigenaar van de product backlog. De zaken op de lijst zijn normaal gesproken in de vorm van een epic of user story. Hierin staat:

De product owner is verantwoordelijk voor de inhoud en bepaalt de prioritering van de eisen. Er staan ook ruwe schattingen bij van de waarde voor de organisatie en van de ontwikkelkosten.

Zie https://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog.

Ontwerp- en architectuurdocumentatie

De ontwerp- en architectuurdocumentatie beschrijft de opzet van de te bouwen software in de context waarbinnen deze moet opereren en de ontwerpkeuzes en -principes die zijn gevolgd. Die documentatie laat tevens zien hoe de software aan de gestelde functionele en niet-functionele eisen voldoet.

Het project legt ontwerp- en architectuurinformatie vast in verschillende documenten en producten, zoals een softwarearchitectuurdocument (SAD), een infrastructuurarchitectuur (IA), een globaal functioneel ontwerp (GFO) en een prototype en/of interactieontwerp.

Het softwarearchitectuurdocument verschaft een compleet overzicht van de architectuur van de te ontwikkelen software, en de rationale hiervoor, waarbij diverse relevante views diverse aspecten van de software belichten. Zie bijvoorbeeld https://www.win.tue.nl/~wstomv/edu/2ip30/references/Kruchten-4+1-view.pdf; andere manieren van architectuurbeschrijving zijn ook toegestaan.

De infrastructuurarchitectuur beschrijft de topologie van de implementatie-omgeving waaronder protocollen, beveiligingsniveaus en services. Deze architectuur biedt een logische afbeelding van de eisen naar de implementatie-omgeving en geeft onderbouwing voor de gemaakte keuzes.

Een prototype is een eerste, ruwe versie van de applicatie. Het prototype illustreert waar men uiteindelijk met de toepassing naar toe wil. Het maakt ideeën tastbaar en creëert een eerste indruk van structuur, ontwerp en functionaliteit.

Beschikbare templates:

Testplannen en -rapportages

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.

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.

Beschikbare templates:

Informatiebeveiligingsplan

Het informatiebeveiligingsplan vormt een praktisch toepasbaar document dat uitlegt binnen welke kaders bescherming geleverd wordt tegen welke dreigingen en met welke maatregelen die bescherming vorm krijgt. Mogelijke bronnen voor het informatiebeveiligingsplan zijn de business impact analysis (BIA), privacy impact assessment (PIA) en de threat and vulnerability assessment (TVA).

Het Besluit Voorschrift Informatiebeveiliging Rijksdienst 2007 (VIR 2007) bevat een methode om te komen tot een systematische aanpak van informatiebeveiliging. Eén van de vereisten van het VIR 2007 is dat voor elk informatiesysteem en voor elk verantwoordelijkheidsgebied een afhankelijkheids- en kwetsbaarheidsanalyse (A&K-analyse) wordt uitgevoerd.

Bij ICTU wordt daarvoor een TVA gebruikt. Hierin worden de betrouwbaarheidseisen, die aan de bedrijfsprocessen en dientengevolge aan het informatiesysteem of verantwoordelijkheidsgebied worden gesteld, tijdens een afhankelijkheidsanalyse geïnventariseerd. Vervolgens worden de bedreigingen geïdentificeerd en geanalyseerd. De TVA levert zodoende een deel van een traceerbare onderbouwing voor de te treffen beveiligingsmaatregelen. De TVA wordt tijdens de voorfase opgesteld op basis van de resultaten van de BIA, de eventuele PIA en de inhoud van de ontwerp- en architectuurdocumentatie.

Kwaliteitsplan

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 opdrachtgevende organisatie een overkoepelend kwaliteitsplan heeft zorgt het project dat het ICTU-kwaliteitsplan aansluit op het overkoepelende kwaliteitsplan.

Beschikbare templates:

Deploybare versie van de software

Het project levert deploybare versies van de software in een formaat dat is afgestemd met de beheerorganisatie.

Documentatie voor deployment en operationeel beheer

De deploymentdocumentatie bevat informatie over de eisen die een applicatie stelt aan een omgeving en de stappen die nodig zijn om de applicatie in die omgeving veilig te installeren en configureren. De documentatie bevat daartoe onder meer aanwijzingen voor de HTTP-header en -request-configuratie van de webserver en voor het verwijderen van overbodige header-informatie zoals de 'Server'-header. Ook zijn er aanwijzingen voor veilige configuratie(s) van (externe) toegang tot de beheerinterface. De documentatie bevat daarnaast in ieder geval een beschrijving van de protocollen en services die de applicatie aanbiedt, de protocollen, services en accounts die het product gebruikt en de protocollen, services en accounts die de applicatie gebruikt voor beheer.

De documentatie voor operationeel beheer bevat tenminste informatie over: back-up/recovery, procedures bij calamiteiten, regelmatig terugkerende beheeractiviteiten, opstart- en afsluitprocedures.

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

Voor elke release stelt het project release notes op: een overzicht van de wijzigingen in de release. Software delivery manager en opdrachtgever maken afspraken over de opzet van de release notes.

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 opdrachtgevende organisatie over nog openstaande testbevindingen en geconstateerde beveiligingsbevindingen; zie ook M26: Het project laat de beveiliging van het ontwikkelde product periodiek beoordelen en M16: Het project gebruikt tools voor vastgestelde taken. Als er issues zijn, bijvoorbeeld rondom kwaliteit of beveiliging, zijn deze voorzien van een beschrijving van de voorziene impact.

Samenhang voorfaseproducten

Relaties tussen producten: Projectstartarchitectuur (PSA), business impact analysis (BIA) en privacy impact assessment (PIA) zijn input voor de voorfase. Functionele eisen (FE), niet-functionele eisen (NFE), informatiebeveiligingsplan (IB), backlog (BL), ontwerp en architectuur (O&A), kwaliteitsplan (KP) en testplannen (TP) zijn de output van de voorfase. De relaties tussen de verschillende producten zijn als volgt. De projectstartarchitectuur vormt input voor functionele eisen en niet-functionele eisen. De business impact analyse vormt input voor de niet-functionele eisen en informatiebeveiligingsplan. De privacy impact analyse vormt input voor de niet-functionele eisen en het informatiebeveiligingsplan. De functionele eisen vormen input voor de backlog en voor ontwerp en architectuur. De niet-functionele eisen vormen input voor backlog, ontwerp en architectuur en kwaliteitsplan. Het informatiebeveiligingsplan vormt input voor ontwerp en architectuur en kwaliteitsplan. De backlog en ontwerp en architectuur, tenslotte, zijn input voor de testplannen.

Bovenstaande figuur laat de belangrijkste relaties zien tussen de verschillende producten die de input en output van de voorfase vormen. Naast de informatiestromen zoals door de pijlen weergegeven zijn er in de praktijk nog meer verbanden tussen de producten. Zo kan de gekozen oplossing in de architectuur van invloed zijn op de maatregelen in het informatiebeveiligingsplan of leiden niet-functionele eisen tot extra functionele eisen.

Rationale

Het uniformeren van op te leveren producten biedt voordelen voor planning (het is bekend welke producten gemaakt moeten worden), voor bemensing (het is bekend welke expertise nodig is) en voor het uitwisselen van medewerkers.

De voorgeschreven producten stellen de beheerorganisatie in staat om de opgeleverde software uit te rollen, te beheren en eventueel te onderhouden. Daarnaast is duidelijk welke eventueel openstaande punten er nog zijn. De voorgeschreven producten bieden voldoende verantwoording richting de ontvanger voor uitgevoerde werkzaamheden.

De genoemde producten uit de voorfase hebben tot doel om enerzijds de omvang, kosten en doorlooptijd van de realisatiefase te kunnen schatten en anderzijds om de kaders voor de realisatiefase te bepalen, zodat de scope, aanpak en oplossingsrichting in grote lijnen bekend zijn.

M32: Het project onderzoekt de kwaliteit van over te nemen software

M32: Het project onderzoekt de kwaliteit van over te nemen software
Als tijdens een project bestaande software dient te worden afgebouwd, onderhouden en/of herbouwd, vindt een onderzoek plaats naar de kwaliteit van deze software.

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: Het project levert in elke fase vastgestelde producten en informatie op, 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 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.

Als kader voor het onderzoek gebruikt ICTU de Nederlandse praktijkrichtlijn NEN NPR 5325:2017.

Rationale

De kwaliteit van software is van grote invloed op de inspanning benodigd voor het afbouwen, onderhouden en/of herbouwen van de software. Inzicht in die kwaliteit helpt bij het plannen van de realisatiefase.

M02: Het project bewaakt continu dat het product aan de kwaliteitsnormen voldoet

M02: Het project bewaakt continu dat het product aan de kwaliteitsnormen voldoet
Projecten bewaken zo snel mogelijk vanaf de start de door het project en ICTU vastgestelde kwaliteitsnormen en voldoen daar zo snel en goed mogelijk aan. De kwaliteit van producten, die nog niet zijn afgerond of nog niet aan de normen voldoen, wordt door het project bewaakt. Het voldoen aan de kwaliteitsnormen is onderdeel van de Definition of Done en herstel van de kwaliteit wordt planmatig opgepakt.

De kwaliteitsnormen voor het product zijn beschreven in de niet-functionele eisen, het informatiebeveiligingsplan, het kwaliteitsplan en deze Kwaliteitsaanpak, zie M01: Het project levert in elke fase vastgestelde producten en informatie op.

Om continu te bewaken dat het product aan de kwaliteitsnormen voldoet, voert het project de volgende activiteiten uit:

  1. Tijdens de voorfase: het project reviewt de deliverables periodiek.
  2. Tijdens de realisatiefase: het project bewaakt op dagelijkse basis en geautomatiseerd de kwaliteit van de software.
  3. Als operationeel beheer onderdeel is van de dienstverlening tijdens de realisatiefase: het project bewaakt op dagelijkse basis en geautomatiseerd het gedrag van de software in gebruik en beheer.
  4. Tijdens de realisatiefase: het project evalueert periodiek en handmatig de kwaliteitseigenschappen van de software die niet geautomatiseerd kunnen worden gemeten.
  5. Tijdens de realisatiefase: het project actualiseert en reviewt periodiek de documentatie.
  6. Indien nodig: de kwaliteitsmanager escaleert het langdurig niet halen van de kwaliteitsnormen.

Daarnaast voert het project periodiek een self-assessment uit tegen de actuele versie van de Kwaliteitsaanpak, zie M28: Het project voert periodiek een self-assessment uit tegen de actuele versie van de Kwaliteitsaanpak.

Voorfase: review documenten

Tijdens de voorfase wordt het voldoen aan de kwaliteitsnormen met behulp van reviews gecontroleerd, normaal gesproken elke sprint. Als onderdeel van het op te stellen kwaliteitsplan wordt tijdens de voorfase bepaald hoe het project de kwaliteit tijdens realisatie gaat controleren; voor producten die niet geautomatiseerd kunnen worden gecontroleerd, beschrijft het kwaliteitsplan een alternatieve aanpak. Als bijvoorbeeld door de gekozen technologie geen ondersteuning van het kwaliteitssysteem mogelijk is, kunnen periodieke, handmatige controles als alternatief ingezet worden.

Realisatiefase: geautomatiseerde kwaliteitsmeting

Tijdens de realisatiefase wordt de kwaliteit diverse malen per uur gemeten door Quality-time, een door ICTU ontwikkeld, open source, geautomatiseerd kwaliteitssysteem. De kwaliteitsmanager configureert de kwaliteitsrapportage in Quality-time en past waar nodig de normen aan, op basis van de projectspecifieke kwaliteitseisen.

Het Scrumteam kijkt dagelijks of er afwijkingen van de normen zijn en onderneemt actie, indien nodig. Ook de kwaliteitsmanager signaleert afwijkingen en meldt deze bij het Scrumteam tijdens de daily scrum en/of tijdens het projectoverleg.

Realisatiefase operationeel beheer: geautomatiseerde monitoring

Als operationeel beheer onderdeel is van de dienstverlening tijdens de realisatiefase monitort en test het project continue het gedrag van de software in gebruik en beheer. Hiertoe gebruikt het project operationele monitoringsoftware, bijvoorbeeld Nagios en/of Zabbix.

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: Het project laat de beveiliging van het ontwikkelde product periodiek beoordelen. 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

Documenten, die onderdeel uitmaken van het op te leveren projectresultaat, zijn zo veel mogelijk geactualiseerd; eventuele achterstand wordt planmatig weggewerkt. De kwaliteitscontrole van documenten gebeurt op basis van reviews. De auteur van een document en de software delivery manager zorgen dat de juiste reviewers benoemd zijn; hiertoe behoort in ieder geval de kwaliteitsmanager. De auteur van het document zorgt voor een correct versiebeheer van het document. De auteur koppelt aan de reviewers terug of en hoe het ontvangen commentaar is verwerkt in de volgende versie van het betreffende document.

Escalatie

Als de kwaliteitsnormen langdurig niet worden behaald heeft de kwaliteitsmanager de volgende escalatielijn:

Rationale

Vaak de kwaliteitsnormen bewaken maakt een actueel inzicht mogelijk. Projectleden kunnen snel reageren op afwijkingen, die in de regel ook pas recent zijn ontstaan en dus meestal gerelateerd zijn aan huidige activiteiten. Met name afwijkingen van de normen op het vlak van informatiebeveiliging en onderhoudbaarheid komen zo snel aan het licht en kunnen dan ook snel worden beoordeeld en - indien nodig en mogelijk - opgelost.

M03: Het project zorgt dat het product traceerbaar aan eisen voldoet

M03: Het project zorgt dat het product traceerbaar aan eisen voldoet
Eisen zijn wederzijds traceerbaar naar bewijsmateriaal, zoals logische testgevallen, dat de eis gerealiseerd is; dat wil zeggen dat geadministreerd is bij welke eis bewijsmateriaal hoort en vice versa. Dit wordt waar mogelijk met tooling ondersteund.

Functionele eisen in de vorm van user stories zijn gekoppeld aan logische testgevallen. Ontwerpdocumentatie in de vorm van use cases is gekoppeld aan logische testgevallen. ICTU gebruikt hiervoor Jira. Logische testgevallen zijn gekoppeld aan fysieke testgevallen. De fysieke testgevallen worden geannoteerd met een identifier van de logische testgevallen. Het project is verantwoordelijk voor het traceerbaar voldoen aan de eisen.

Niet-functionele eisen zijn input voor onder andere softwarearchitectuurdocument, mastertestplan en detailtestplannen. De traceerbaarheid hiervan is (nog) niet geadministreerd met behulp van tooling.

Rationale

Door eisen en testgevallen te koppelen en traceerbaar te maken, is het mogelijk de dekking van tests ten opzichte van eisen te bepalen. Logische testgevallen worden gekoppeld aan use cases om zo aan te tonen dat alle ontworpen en geïmplementeerde functionaliteit getest wordt. Logische testgevallen worden gekoppeld aan user stories om aan te tonen dat alle wijzigingen die in een sprint zijn gemaakt ook getest zijn.

M13: Het project gebruikt ISO-25010 voor de specificatie van productkwaliteitseisen

M13: Het project gebruikt ISO-25010 voor de specificatie van productkwaliteitseisen
Voor specificatie en documentatie van vereiste en gewenste kwaliteitseigenschappen, de niet-functionele eisen, maken projecten gebruik van de terminologie en categorisering uit NEN-ISO/IEC 25010. Projecten gebruiken NEN-ISO/IEC 25010 om te controleren of alle relevante kwaliteitseigenschappen van het op te leveren eindproduct worden meegenomen in de ontwikkeling en/of onderhoud van het product.

De standaard NEN-ISO/IEC 25010:2011, kortweg "ISO-25010", biedt een model voor het beschrijven van productkwaliteit. Kwaliteitseigenschappen zijn voorzien van een naam, definitie en classificatie. ISO-25010 dekt een breed spectrum van kwaliteitseigenschappen af.

Rationale

ISO-25010 biedt een model voor productkwaliteit. De standaard biedt geen concrete maatregelen, maar biedt wel een begrippenkader en dekt het volledige spectrum van mogelijk relevante kwaliteitseigenschappen af. Het gebruiken van een standaard voor specificatie van kwaliteit voorkomt miscommunicatie over kwaliteitseigenschappen en de breedte van de standaard zorgt ervoor dat alle relevante aspecten aan bod komen.

M04: Het project borgt de correcte werking van het product met geautomatiseerde regressietests

M04: Het project borgt de correcte werking van het product met geautomatiseerde regressietests
Regressietests - tests die verifiëren of eerder ontwikkelde software nog steeds correct werkt na wijzigingen in de software of aansluiting op andere externe koppelvlakken - zijn geautomatiseerd.

Het project hanteert een norm voor de dekking van regressietests, legt deze vast in Quality-time en bewaakt deze.

Rationale

Handmatig uitgevoerde regressietests zijn arbeidsintensief, foutgevoelig en afhankelijk van de aanwezigheid van specifieke medewerkers. Gelet op de vrijwel continue metingen op en leveringen van de software, zijn de nadelen van handmatige regressietests niet acceptabel. Door ze te automatiseren zijn ze herhaalbaar en kunnen ze onderdeel uitmaken van de continuous delivery pipeline.

M07: Het project gebruikt een continuous delivery pipeline om het product te bouwen, testen en op te leveren

M07: Het project gebruikt een continuous delivery pipeline om het product te bouwen, testen en op te leveren
Er is een geautomatiseerde continuous delivery pipeline die aantoonbaar correct werkt en de software bouwt, installeert in de testomgevingen, test op functionele en niet-functionele eigenschappen en oplevert, al dan niet inclusief installatie in de productieomgeving.

De geautomatiseerde continuous delivery pipeline voert ten minste de volgende activiteiten uit:

  1. Bouw van de software,
  2. Unit tests,
  3. Regressietests,
  4. Beveiligingstests,
  5. Performancetests,
  6. Toegankelijkheidstests,
  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 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.

Niet alle testen en controles kunnen altijd geautomatiseerd worden uitgevoerd. Denk aan kwaliteitscontroles op architectuurbeslissingen of het testen van toegankelijkheidseisen. Waar mogelijk wordt wel een zo groot mogelijk deel van de testen en controles geautomatiseerd en als onderdeel van de pipeline uitgevoerd.

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 opdrachtgevende organisaties en beheerorganisaties.

Rationale

Software incrementeel opleveren vereist dat de software frequent gebouwd, getest en opgeleverd kan worden. Om dit efficiënt en foutvrij te doen, dient het proces van bouwen, testen en opleveren geautomatiseerd te zijn; een continuous delivery pipeline faciliteert dit.

M16: Het project gebruikt tools voor vastgestelde taken

M16: Het project gebruikt tools voor vastgestelde taken
ICTU stelt het gebruik van tools verplicht voor de volgende taken:
  1. backlog management en agile werken,
  2. inrichten en uitvoeren van een continuous delivery pipeline,
  3. monitoren van de kwaliteit van broncode,
  4. versiebeheer van op te leveren producten,
  5. release van software,
  6. maken van testrapportages,
  7. maken van kwaliteitsrapportages,
  8. controleren van de configuratie op aanwezigheid van bekende kwetsbaarheden,
  9. controleren van door de applicatie gebruikte versies van externe software op aanwezigheid van bekende kwetsbaarheden,
  10. statische controle van de software op aanwezigheid van kwetsbare constructies,
  11. dynamische controle van de software op aanwezigheid van kwetsbare constructies,
  12. controleren van container images op aanwezigheid van bekende kwetsbaarheden,
  13. testen van performance en schaalbaarheid,
  14. testen op toegankelijkheid van de applicatie,
  15. produceren van een "software bill of materials" (SBoM),
  16. opslaan van artifacten,
  17. registratie van incidenten bij gebruik en beheer, en
  18. bij het uitvoeren van operationeel beheer; uitrollen van de software in de productieomgeving.

Onder het ondersteunen van "agile werken" vallen het opvoeren van eisen, het opvoeren van logische testgevallen, het koppelen van logische testgevallen aan eisen, het bijhouden van een werkvoorraad, het plannen van iteraties en het toewijzen van eisen aan iteraties. De 'eisen' worden, conform Scrumterminologie, geregistreerd als epics en/of user stories, de werkvoorraad als backlog en de iteraties als sprints.

ICTU adviseert en ondersteunt voor de genoemde taken onderstaande tools. Projecten gebruiken deze tools, of gelijkwaardige alternatieven:

  1. backlog management en agile werken: Azure DevOps of Jira,
  2. inrichten en uitvoeren van een continuous delivery pipeline: Jenkins, GitLab CI/CD (Continuous Integration, Delivery, and Deployment) of Azure DevOps,
  3. monitoren van de kwaliteit van broncode: SonarQube,
  4. versiebeheer van op te leveren producten: GitLab of Azure DevOps,
  5. release van software: Releaseserver in het ontwikkelplatform,
  6. maken van testrapportages: JUnit, Robot Framework, TestNG, of hiermee compatible tools,
  7. maken van kwaliteitsrapportages: Quality-time,
  8. controleren van de configuratie op aanwezigheid van bekende kwetsbaarheden in configuratie: OpenVAS (Vulnerability Assessment System),
  9. controleren op aanwezigheid van bekende kwetsbaarheden in externe software: OWASP (Open Web Application Security Project) Dependency-Check en/of Dependency-Track,
  10. statische controle van de software op aanwezigheid van kwetsbare constructies: SonarQube,
  11. dynamische controle van de software op aanwezigheid van kwetsbare constructies: OWASP ZAP (Zed Attack Proxy),
  12. controleren van container images op aanwezigheid van bekende kwetsbaarheden: Trivy,
  13. testen van performance en schaalbaarheid: JMeter en Performancetestrunner,
  14. testen op toegankelijkheid van de applicatie: Axe,
  15. produceren van een "software bill of materials" (SBoM): tools die een SBoM in CycloneDX-formaat (zie https://cyclonedx.org) genereren,
  16. opslaan van artifacten: Nexus of Harbor,
  17. registratie van incidenten bij gebruik en beheer: Jira, en
  18. bij het uitvoeren van operationeel beheer; uitrollen van de software in de productieomgeving: Ansible.

Rationale

Projecten hebben een redelijke vrijheid bij het kiezen en gebruiken van tools, maar voor een aantal taken is het gebruik verplicht gesteld. Deze tools zijn nodig voor een efficiënte uitvoering van de Kwaliteitsaanpak. Uniform gebruik van deze tools maakt het mogelijk koppeling tussen die tools voor alle projecten te standaardiseren; daarnaast bevordert het de uitwisselbaarheid van medewerkers en neemt het risico op het gebruik van onvolwassen tools af. Tot slot is het gebruik in een aantal gevallen, ten behoeve van informatiebeveiliging bij de overheid, verplicht.

M08: Het project maakt technische schuld inzichtelijk en lost deze planmatig op

M08: Het project maakt technische schuld inzichtelijk en lost deze planmatig op
Technische schuld is inzichtelijk en wordt planmatig aangepakt. De kwaliteitsmanager is verantwoordelijk voor het inzichtelijk maken van de technische schuld. De software delivery manager is verantwoordelijk voor het planmatig aanpakken van de technische schuld en zorgt dat het Scrumteam regelmatig en voldoende tijd heeft om technische schuld te voorkomen en op te lossen. Het Scrumteam is verantwoordelijk voor het zoveel mogelijk voorkomen van technische schuld en voor het identificeren van technische schuld die toch optreedt.

Technische schuld zijn eigenschappen van de software die de lange termijn inzetbaarheid en onderhoudbaarheid van de software bedreigen. Denk hierbij aan hoge complexiteit, lage testdekking, ontbrekende testsoorten en ontbrekende documentatie.

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 opdrachtgevende organisatie omdat het leveren van kwaliteit onderdeel van het werk is.

Rationale

De aanwezigheid van technische schuld heeft nadelige invloed op de kwaliteit van de eindproducten. Wel is het ontstaan van technische schuld gedurende een project vaak onvermijdelijk. Het is daarnaast ook mogelijk dat een deel van de technische schuld bij aanvang van het project al bestond en mogelijk niet wordt opgelost. In alle gevallen is het verstandig om te weten welke technische schuld bestaat. Om te voorkomen dat technische schuld niet wordt opgelost en uitsluitend toeneemt, is het zaak om het verminderen van technische schuld planmatig aan te pakken.

M26: Het project laat de beveiliging van het ontwikkelde product periodiek beoordelen

M26: Het project laat de beveiliging van het ontwikkelde product periodiek beoordelen
Projecten laten periodiek de beveiliging van de ontwikkelde software beoordelen. Een beveiligingsexpert onderzoekt de code zowel geautomatiseerd als handmatig op veelvoorkomende kwetsbaarheden en op het voldoen aan voorgeschreven beveiligingsnormen. Overheidsspecifieke beveiligingsnormen of -raamwerken, zoals de BIO (Baseline Informatiebeveiliging Overheid), bieden een basis voor de beoordeling. Bevindingen uit de beveiligingstest worden vastgelegd als onderdeel van de werkvoorraad voor het ontwikkelproces.

Software wordt minimaal bij iedere grote release of ten minste twee keer per jaar onderworpen aan een beveiligingstest door beveiligingsexperts die ICTU daarvoor inhuurt. Op basis van documentatie en architectuurstudie, crystalbox security audits (broncodescan) en penetratieaudits beoordelen deze experts of de software voldoet aan de projectspecifieke niet-functionele eisen met betrekking tot beveiliging, of bekende kwetsbaarheden (zoals bijvoorbeeld in de OWASP Top-10 genoemd) vermeden zijn en of voldoende invulling gegeven is aan de normen die vanuit BIO en SSD gelden.

ICTU zorgt ervoor dat de benodigde expertise op afroep beschikbaar gesteld kan worden aan projecten.

De opdrachtgevende organisatie kan een derde partij opdracht geven beveiligingstesten uit te voeren in een daarvoor door de opdrachtgevende organisatie beschikbaar gestelde omgeving. Dit kan zowel incidenteel als structureel worden ingericht. Als de opdrachtgevende organisatie dit structureel inricht en als deze beveiligingstesten voldoen aan de eisen die het project zou stellen, dan kunnen de opdrachtgevende organisatie en het project besluiten dat het project zelf geen beveiligingstesten laat uitvoeren. Afspraken hierover worden bij voorkeur al in de voorfase gemaakt, inclusief een controle dat de opdrachtgevende organisatie de benodigde contractuele mogelijkheden heeft beveiligingstesten uit te besteden. Het project ontvangt in dat geval de beveiligingstestrapportages van de opdrachtgevende organisatie.

De beveiligingstesten vinden altijd plaats in aanvulling op de door tools uitgevoerde continue beveiligingsanalyse van de gerealiseerde software. Bevindingen uit beveiligingstesten en de continue analyse die niet direct worden opgelost, worden in Jira als issue vastgelegd op de backlog van het project.

De kwaliteitsmanager van het project bewaakt de opvolging van de kritische beveiligingsissues. De kwaliteitsmanager bewaakt tevens of de beveiligingstesten voldoende frequent plaatsvinden, bij voorkeur door Quality-time te laten waarschuwen als het tijd is voor de volgende beveiligingstest.

Rationale

Het inschakelen van actuele, specifieke expertise vergroot de kans dat eventuele kwetsbaarheden in de gerealiseerde software tijdig herkend worden.

Processen

M14: Het project bereidt samen met opdrachtgevende organisatie en betrokken partijen de realisatie voor

M14: Het project bereidt samen met opdrachtgevende organisatie en betrokken partijen de realisatie voor
Projecten hebben een voorbereidingsfase, "voorfase" genoemd, voorafgaand aan de realisatiefase. Voor het uitvoeren van de voorfase zijn vertegenwoordigers van de opdrachtgevende organisatie, de beoogde beheerorganisatie en andere partijen betrokken die meewerken aan het realiseren van een deel van de op te leveren producten. Het doel van de voorfase is beeld krijgen van de te realiseren oplossing, van de risico's die zich tijdens realisatie kunnen voordoen en van de kaders waarbinnen de oplossing moet passen; tijdens de realisatiefase vinden bouw en onderhoud van de software en actualiseren en afronden van documentatie plaats.

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 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 opdrachtgevende organisatie, ICTU en andere betrokken partijen af welke onderdelen van de voorfase opnieuw moeten worden uitgevoerd. Denk bij significante wijzigingen aan grote aanpassingen aan de scope, het budget, de belanghebbenden en/of de planning van het project.

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 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: Het project levert in elke fase vastgestelde producten en informatie op. 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.

M21: Het project selecteert medewerkers op basis van kwaliteit

M21: Het project selecteert medewerkers op basis van kwaliteit
Bij de inzet van medewerkers gaat kwaliteit boven andere aspecten, zoals beschikbaarheid, prijs en doorlooptijd.

Rationale

Goede kwaliteit van producten ontstaat primair door het werk van mensen; standaardisatie, kwaliteitsnormen en monitoring zijn hulpmiddelen. De kans dat kwalitatief goede medewerkers ook goede producten maken, is groter dan bij minder goede medewerkers.

M23: Het project zorgt voor de aanwezigheid van ervaring met de Kwaliteitsaanpak

M23: Het project zorgt voor de aanwezigheid van ervaring met de Kwaliteitsaanpak
De software delivery manager zorgt ervoor dat bij nieuwe projecten wordt gestart met ten minste twee projectleden die bekend zijn met de Kwaliteitsaanpak.

Rationale

Het inzetten van teamleden die bekend zijn met de Kwaliteitsaanpak zorgt voor een soepeler start van een nieuw project omdat zij bekend zijn met de inhoud van de Kwaliteitsaanpak, zoals kwaliteitsnormen en tools, en omdat zij al doende nieuwe teamleden bekend kunnen maken met de Kwaliteitsaanpak.

M05: Het project hanteert een iteratief en incrementeel ontwikkelproces

M05: Het project hanteert een iteratief en incrementeel ontwikkelproces
Projecten werken iteratief en incrementeel; dit betekent dat een project in korte iteraties werkt, waarbij elke iteratie een werkende versie van de software oplevert die extra waarde vertegenwoordigt voor de opdrachtgevende organisatie. Behalve de software werkt het project ook iedere iteratie alle andere producten bij. Elke iteratie worden verwachtingen en werkelijke resultaten vergeleken en wordt de werkwijze aangescherpt op basis van inzichten en bevindingen.

ICTU gebruikt hiervoor Scrum, een raamwerk voor agile productontwikkeling. ICTU propageert de kernwaarden van Scrum en vereist de volgende onderdelen van Scrum:

  1. Scrumteam bestaand uit product owner, ontwikkelaars (zoals programmeurs, testers en ontwerpers) en Scrummaster,
  2. Proces met daily scrum, sprints, sprint planning, sprint review, sprint retrospective en sprint refinement,
  3. Definition of Ready en Definition of Done,
  4. Product backlog en sprint backlog.

Als operationeel beheer onderdeel is van de dienstverlening, past ICTU de DevOps-werkwijze toe door operationeel beheeractiviteiten te integreren in de Scrum-processen van het Scrumteam.

Rationale

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.

M35: Het project hanteert een agile architectuuraanpak

M35: Het project hanteert een agile architectuuraanpak
Tijdens de voorfase verwerkt het project de door de opdrachtgevende organisatie opgestelde projectstartarchitectuur (PSA) in een eerste versie van het softwarearchitectuurdocument (SAD). Tijdens de realisatiefase werkt het project het SAD bij op basis van nieuwe inzichten.

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 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 (solution) architectuur aan te passen.

Rationale

Maatwerksoftwareontwikkeling is per definitie het ontwikkelen van een nieuw product. In de praktijk blijkt dat tijdens de ontwikkeling van het product altijd nog zaken ontdekt worden die bij aanvang niet bekend waren, of waarvan het belang eerder niet op waarde werd geschat. Het initiële SAD zal dus in de praktijk altijd moeten worden bijgewerkt op basis van die nieuwe inzichten.

M10: Het project kent een wekelijks projectoverleg

M10: Het project kent een wekelijks projectoverleg
De projectleider organiseert een periodiek projectoverleg. Dit overleg vindt wekelijks plaats en duurt niet langer dan een uur. Vereiste aanwezigen zijn de projectleider, de software delivery manager, de Scrummaster, een vertegenwoordiger uit elk van de Scrumteams en de kwaliteitsmanager van het project; andere aanwezigen kunnen zijn: de projectarchitect en de product owner. De agenda voor dit overleg bestaat ten minste uit de volgende onderwerpen: mededelingen, actie- en besluitenlijst, personele zaken, planning en voortgang, kwaliteit en architectuur, risico's en aandachtspunten.

Het periodiek projectoverleg heet bij ICTU het "Intern Projectoverleg" of "IPO".

Nadere toelichting op de agenda:

Rationale

Het doel van het periodiek projectoverleg is alle betrokkenen op hetzelfde informatieniveau te brengen en te houden. Het overleg is intern om vrijuit te kunnen praten over personele zaken en risico's voor het project.

M28: Het project voert periodiek een self-assessment uit tegen de actuele versie van de Kwaliteitsaanpak

M28: Het project voert periodiek een self-assessment uit tegen de actuele versie van de Kwaliteitsaanpak
De projectleider organiseert periodiek een self-assessment tegen de actuele versie van de Kwaliteitsaanpak en zet verbeteracties uit, waar nodig.

Deze self-assessment geeft inzicht in de huidige status van het project en kan aanleiding geven tot het nemen van maatregelen binnen het project.

De projectleider identificeert de belangrijkste verschillen tussen Kwaliteitsaanpak en werkwijze in het project en rapporteert hierover aan ICTU. In overleg tussen projectleider en ICTU wordt besloten of het verschil tijdelijk of permanent wordt geaccepteerd. In het geval van tijdelijke acceptatie stelt de projectleider een verbeteractie op. Merk op dat de verbeteractie ook kan bestaan uit het opstellen van een verbetervoorstel voor de Kwaliteitsaanpak.

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 opdrachtgevende organisatie en andere betrokken partijen. Voor het uitvoeren en vastleggen van de self-assessment stelt ICTU een self-assessment formulier beschikbaar.

Rationale

Net als bij technische producten is het periodiek meten van de kwaliteit van belang om in controle te blijven. Aangezien veel maatregelen uit de Kwaliteitsaanpak zich niet geautomatiseerd laten meten, is menselijke inbreng nodig.

Omdat implementatie van maatregelen in een project tijd kost is de self-assessment gericht op het in kaart brengen van de belangrijkste verschillen tussen de Kwaliteitsaanpak en de in het project toegepaste werkwijze, maar niet op het uitputtend inventariseren van alle verschillen.

M30: Het project identificeert, mitigeert en bewaakt risico's

M30: Het project identificeert, mitigeert en bewaakt risico's
Het project identificeert, mitigeert en bewaakt projectspecifieke risico's voorafgaand aan en tijdens de projectuitvoering. Het project houdt een risicolog bij met geïdentificeerde risico's. De uitkomsten van de "Doordacht-van-Start-sessie", die al voorafgaand aan de start van het project wordt uitgevoerd, vormen het startpunt van deze risicolog. Risico's die tijdens de voorfase worden geïdentificeerd, bijvoorbeeld bij de productrisicoanalyse, worden toegevoegd aan de risicolog. Ook bij de start van de realisatiefase worden risicosessies gehouden met (vertegenwoordigers van) de belanghebbenden om verdere risico's te identificeren. Het project identificeert en implementeert mitigerende maatregelen danwel accepteert expliciet de geïdentificeerde risico's. Het project bewaakt de risicolog en uitvoering van de mitigerende maatregelen tijdens het IPO.

Rationale

Een flink deel van de risico's die komen kijken bij het ontwikkelen van software is beschreven in de Nederlandse praktijkrichtlijn NEN NPR 5326:2019. De richtlijn geeft voor de beschreven risico's beheersmaatregelen die organisaties kunnen implementeren. De maatregelen in deze Kwaliteitsaanpak komen grotendeels overeen met de beheersmaatregelen in NPR 5326.

Echter, naast generieke risico's loopt elke project ook projectspecifieke risico's die voortkomen uit de scope van het project (is bijvoorbeeld operationeel beheer binnen de scope) en de context waarin het wordt uitgevoerd (bijvoorbeeld software die bijzondere persoonsgevens verwerkt). Alleen door deze risico's voorafgaand aan en tijdens het project actief te identificeren en te mitigeren kan de potentiële impact ervan beperkt worden.

M34: Het project draagt software beheerst over

M34: Het project draagt software beheerst over
Als de software op enig moment door een andere partij dan ICTU verder ontwikkeld en/of onderhouden zal worden, draagt het project zorg voor een beheerste overdracht. Beheerdocumentatie, broncode en testmiddelen zijn van dusdanige kwaliteit en compleetheid dat de andere partij de software efficiënt en effectief kan doorontwikkelen en/of onderhouden.

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 opdrachtgevende organisatie en ontvangende partij, de criteria aan.

  1. De documentatie beschrijft de ontwikkel- en testomgeving die is toegepast (5.1),
  2. De functionele documentatie beschrijft gegevensmodellen, functionele indeling, koppelingen, berichtdefinities en workflows/processen (5.2),
  3. Als operationeel beheer onderdeel was van de dienstverlening: de operationele bedieningsinstructies beschrijven minimaal back-up/recovery, procedures bij calamiteiten, regelmatig terugkerende beheeractiviteiten en opstart- en afsluitprocedures (5.3),
  4. De productbacklog bevat de bekende bugs en wensen (5.4),
  5. De broncode kent een gezonde balans tussen isolatie, cohesie en koppeling (6.1),
  6. De broncode heeft een beperkte mate van duplicatie (6.2),
  7. De broncode heeft een beperkte mate van complexiteit (6.3),
  8. De broncode bevat geen of een beperkt aantal niet-afgeronde werkzaamheden ("todo's") (6.4).
  9. De tests raken een voldoende groot deel van de broncode (code dekking) (7.1),
  10. De tests raken een voldoende groot deel van de functionaliteit (functionele dekking) (7.2),
  11. De onderkende productrisico's zijn gedekt (7.3),
  12. Er is een regressietest beschikbaar (7.4),
  13. Er is traceerbaarheid van eisen naar testgevallen (7.5), en
  14. De testset is goed opgebouwd (7.6).

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.

M27: Het project sluit projectfasen en zichzelf expliciet af

M27: Het project sluit projectfasen en zichzelf expliciet af
Afsluiting van een projectfase gebeurt expliciet en gecontroleerd: alle producten, zoals documentatie, broncode, referentiedata en credentials, die in de af te sluiten fase nodig waren of zijn opgeleverd, worden gearchiveerd. Indien er geen volgende fase is voorzien op korte termijn, dienen alle producten van de laptops van de projectmedewerkers verwijderd te worden.

De software delivery manager is verantwoordelijk voor het archiveren. De software delivery manager geeft het Scrumteam opdracht de archivering voor te bereiden en geeft de afdeling ICTU Software Diensten (ISD) de opdracht de archivering uit te voeren.

Alle documentatie, broncode, referentiedata en credentials die tijdens de werkzaamheden nodig waren of zijn opgeleverd, worden gearchiveerd en van laptops van medewerkers verwijderd.

Rationale

Archiveren faciliteert het eventueel herstarten of overdragen van het project op een later tijdstip. Verwijderen neemt een onnodig risico op inbreuk op vertrouwelijkheid weg en vrijwaart projectmedewerkers en ICTU van verdenking en aansprakelijkheid wanneer een incident optreedt.

Het expliciet afsluiten van het project is conform Maatregel 14: "Archivering" uit de NEN NPR 5326:2019.

Organisatie

M29: ICTU organiseert voor aanvang van een project de interne dienstverlening

M29: ICTU organiseert voor aanvang van een project de interne dienstverlening
Voordat ICTU een softwareontwikkelproject start, dat gaat werken conform de Kwaliteitsaanpak, maakt de beoogde ICTU-projectleider afspraken met de afdelingen ICTU Software Diensten (ISD) en ICTU Software Expertise (ISE) over de af te nemen dienstverlening.

Voordat ICTU een project start en een overeenkomst sluit met de opdrachtgevende organisatie maakt de beoogde ICTU-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.

Merk op dat een project vaak ook externe dienstverlening nodig heeft, bijvoorbeeld security testen of onderhoudbaarheidstoetsen. Deze externe dienstverlening hoeft echter normaal gesproken niet voor de start van het project te worden ingekocht.

Rationale

Door tijdig de interne dienstverlening aan projecten te organiseren helpt ICTU startende projecten de Kwaliteitsaanpak succesvol in te zetten, zonder de dienstverlening aan bestaande projecten te hinderen.

M19: ICTU biedt projecten een afgeschermde digitale omgeving

M19: ICTU biedt projecten een afgeschermde digitale omgeving
ICTU geeft de projecten de beschikking over eigen, afgeschermde digitale omgevingen, waarbinnen ze de door het project ontwikkelde software en tools kunnen installeren en waartoe op een beheerste manier toegang wordt verleend.

ICTU ondersteunt dit met Docker en/of virtuele machines en een VLAN (Virtual local area network) per project. Een nieuwe afgeschermde digitale omgeving is binnen een werkweek na aanvraag beschikbaar.

De software delivery manager is verantwoordelijk voor het autoriseren van personen voor toegang tot de beveiligde projectomgeving. De afdeling ICTU Software Diensten (ISD) beheert de basisconfiguratie van de afgeschermde digitale omgevingen. Projecten wijken alleen in overleg met ISD af van de basisconfiguratie. Als bepaalde afwijkingen vaker voorkomen, kan dit leiden tot het maken van aanpassingen aan de basisconfiguratie.

Rationale

Door het bieden van een afgeschermde digitale omgeving zijn de afhankelijkheden en invloeden tussen projecten minimaal en worden beveiligingsrisico's verkleind.

M18: ICTU biedt ondersteuning voor verplicht gestelde tools

M18: ICTU biedt ondersteuning voor verplicht gestelde tools
ICTU zorgt voor technische en functionele ondersteuning aan projecten bij het gebruik van alle verplichte tools.

ICTU zorgt voor ondersteuning van de bij M16: Het project gebruikt tools voor vastgestelde taken verplicht gestelde tools. Een team van specialisten met kennis, ervaring en capaciteit is beschikbaar voor ondersteuning aan projecten.

Bij de selectie van tools ter ondersteuning van de projectuitvoering geeft ICTU de voorkeur aan open source tools. Ook tools die ICTU zelf ontwikkelt ter ondersteuning van softwareontwikkelprojecten worden bij voorkeur open source beschikbaar gesteld.

Rationale

De keuze om het gebruik van een aantal tools verplicht te stellen (M16: Het project gebruikt tools voor vastgestelde taken) volgt uit de belangrijke rol die die tools spelen in de ontwikkelstraat en in Quality-time, het kwaliteitssysteem van ICTU. Met de verplichting komt ook een verantwoordelijkheid: om projecten in staat te stellen snel en effectief met deze tools te werken, moeten die projecten ondersteund worden.

De verplicht gestelde tools zijn beperkt in aantal, bewezen en gangbaar; veel medewerkers zullen deze tools al kennen.

De voorkeur voor open source tools is conform de rationale uit NORA (Nederlandse Overheid Referentiearchitectuur) voor het gebruik van open source tools, zoals beschreven in NORA v3.0 drijfveer "Beleid open standaarden". De voorkeur voor het open source beschikbaar stellen van eigen ontwikkelde tools is conform de "Beleidsbrief vrijgeven van de broncode van overheidssoftware" van de staatssecretaris van Binnenlandse Zaken en Koninkrijksrelaties, 17 april 2020.

M11: ICTU beheert, onderhoudt en implementeert de Kwaliteitsaanpak en kwaliteitsnormen

M11: ICTU beheert, onderhoudt en implementeert de Kwaliteitsaanpak en kwaliteitsnormen
ICTU beheert, onderhoudt en implementeert de Kwaliteitsaanpak en de kwaliteitsnormen. Aanpassingen zijn gebaseerd op praktijkervaring, nieuwe inzichten en nieuwe mogelijkheden voor meting en analyse. Iedere medewerker kan wijzigingsvoorstellen indienen bij ICTU. ICTU behandelt de wijzigingsvoorstellen, kiest de te nemen actie bij elk wijzigingsvoorstel en legt de wijzigingsvoorstellen en besluiten vast.

De Kwaliteitsaanpak wordt voor ICTU onderhouden door de afdeling ICTU Software Expertise (ISE). Iedereen die betrokken is bij softwareontwikkelprojecten kan een wijzigingsvoorstel indienen bij het hoofd van de afdeling ISE; die zorgt voor behandeling van en besluitvorming over het wijzigingsvoorstel. De afdeling zorgt ook zelf voor actualisering van de Kwaliteitsaanpak, op basis van praktijkervaringen en nieuwe inzichten uit onder andere de gezamenlijkse self-assessment, zie M33: ICTU organiseert periodiek een gezamenlijke self-assessment ten aanzien van de Kwaliteitsaanpak.

Bij een verandering van de Kwaliteitsaanpak zorgt het hoofd van de afdeling ISE voor een passend implementatie- en verandertraject.

Rationale

Expliciet beheer en onderhoud van de ICTU Kwaliteitsaanpak Softwareontwikkeling is nodig om geleerde lessen, nieuwe inzichten uit bijvoorbeeld wetenschappelijke literatuur en nieuwe technische mogelijkheden voor meting en analyse te verwerken in de Kwaliteitsaanpak. De Kwaliteitsaanpak wordt door ICTU - en niet door een project - onderhouden, zodat deze bij meerdere projecten uniform kan worden toegepast.

M12: ICTU publiceert nieuwe versies van de Kwaliteitsaanpak en normen periodiek en op een vaste locatie

M12: ICTU publiceert nieuwe versies van de Kwaliteitsaanpak en normen periodiek en op een vaste locatie
ICTU publiceert periodiek een nieuwe versie van de Kwaliteitsaanpak en/of de kwaliteitsnormen op een vaste, bekende locatie.

De ICTU Kwaliteitsaanpak Softwareontwikkeling is te vinden via de ICTU-website (https://www.ictu.nl/kwaliteitsaanpak) en, inclusief templates en self-assessment checklist, op het ICTU Portaal (Sharepoint). Publicatie van een nieuwe versie wordt aangekondigd via een e-mail naar belanghebbenden en/of een bericht op MS Teams.

Rationale

Medewerkers moeten te allen tijde de actuele Kwaliteitsaanpak en -normen kunnen raadplegen. Welke versie actueel is en wanneer een nieuwe versie actueel wordt, is essentiële informatie voor de planning van werkzaamheden binnen de projecten en binnen de afdeling als geheel.

M33: ICTU organiseert periodiek een gezamenlijke self-assessment ten aanzien van de Kwaliteitsaanpak

M33: ICTU organiseert periodiek een gezamenlijke self-assessment ten aanzien van de Kwaliteitsaanpak
ICTU organiseert periodiek een gezamenlijke self-assessment ten aanzien van de Kwaliteitsaanpak die inzicht geeft in de huidige status van de Kwaliteitsaanpak en aanleiding kan geven tot het nemen van maatregelen om de Kwaliteitsaanpak en de ondersteuning daarvan door ICTU te verbeteren.

ICTU nodigt de lopende projecten jaarlijks uit om deel te nemen aan de gezamelijke self-assessment. Deelname door projecten is vrijwillig. Voor het doen van de self-assessment stelt ICTU een ondersteunend formulier beschikbaar.

De projecten identificeren aan de hand van het formulier de belangrijkste verschillen tussen Kwaliteitsaanpak en werkwijze in het project en rapporteren hierover aan ICTU.

ICTU voegt de self-assessments van de deelnemende projecten samen en maakt een analyse van de resultaten. De analyse gaat in op:

ICTU organiseert een bespreking van de analyse met de deelnemende projecten. Hieruit vloeiende verbeteracties voor de Kwaliteitsaanpak worden door ICTU geprioriteerd en via de backlog voor de Kwaliteitsaanpak afgehandeld. Bij grotere verbeteracties betrekt ICTU de kwaliteitsmanagers van de belanghebbende projecten.

De gezamenlijke self-assessment is een intern product en de niet-geanonimiseerde resultaten worden alleen gedeeld met de deelnemende projecten. De geanonimiseerde resultaten kunnen worden gedeeld met belanghebbenden en belangstellenden binnen en buiten ICTU.

Rationale

Door een gezamenlijke self-assessment te doen met meerdere projecten tegelijkertijd onstaat er inzicht in de mate waarin maatregelen van de Kwaliteitsaanpak toegepast worden en zinvol zijn. Het gesprek over de uitkomsten van de gezamenlijke self-assessment levert input voor verbetering van de Kwaliteitsaanpak zelf.

Bijlagen

Terminologie en afkortingen

De onderstaande tabel bevat afkortingen en termen die voorkomen in de ICTU Kwaliteitsaanpak Softwareontwikkeling en bijbehorende templates.

Term/afkortingToelichting
actoreen persoon die, of een extern informatiesysteem dat, een handeling verricht op het informatiesysteem
architectuureen beschrijving van de structuur van een systeem, inclusief onderdelen, relaties tussen die onderdelen en eigenschappen van die onderdelen en relaties
APIapplication programming interface
ARTautomatische regressietest
auditingVastlegging van de door een actor verrichte handelingen
authenticatiehet vaststellen van de identiteit van een actor
autorisatieaan een actor toegekende rechten
beheerorganisatieeen (samenwerkingsverband van) organisatie(s) die in opdracht van een opdrachtgevende organisatie het operationeel beheer, applicatief beheer en/of functioneel beheer van software uitvoert
BIAbusiness impact analysis
BIOBaseline Informatiebeveiliging Overheid
broncodesoftware in een vorm die leesbaar is voor mensen en de intentie van een programmeur uitdrukt
deploymentinstallatie van software op een systeem waardoor de software beschikbaar wordt gemaakt voor gebruik door actoren
developersDevelopers zijn de mensen in het Scrumteam die iedere sprint gecommitteerd zijn aan het maken van elk aspect van een bruikbaar increment [Scrumgids]
DevOpseen praktijk die tot doel heeft softwareontwikkeling en operationeel beheer samen te brengen
DoDdefinition of done
DoRdefinition of ready
gebruikskwaliteitmate waarin een systeem, product of dienst kan worden gebruikt door gespecificeerde gebruikers, voor het bereiken van gespecificeerde doelen, met effectiviteit, efficiëntie en tevredenheid in een gespecificeerde gebruikscontext
GFOglobaal functioneel ontwerp
IB-planinformatiebeveiligingsplan
informatiesysteemeen samenhangend geheel van gegevensverzamelingen en de daarbij behorende personen, procedures, processen en programmatuur alsmede de voor het informatiesysteem getroffen voorzieningen voor opslag, verwerking en communicatie [VIR 2007, NORA]
infrastructuurarchitectuureen architectuur die vooral de hardwareonderdelen en -relaties (housing, hardware, virtuals, standaard software en middleware) van een systeem beschrijft
IPOintern projectoverleg
ISDICTU Software Diensten, afdeling van ICTU die softwareontwikkelprojecten ondersteunt met ontwikkel- en testomgevingen, tools en diensten
ISEICTU Software Expertise, afdeling van ICTU die softwareontwikkelprojecten ondersteunt met expertise op het gebied van softwareontwikkeling en die de ICTU Kwaliteitsaanpak Softwareontwikkeling onderhoudt
ISOInternational Organization for Standardization
Jiratool om use cases, user stories, logische testgevallen en issues vast te leggen
klantreisalle directe en indirecte interactie van een klant of gebruiker met een product of dienst
KPIkey performance indicator
kwaliteitsmanagercontroleert en borgt de kwaliteit van software conform de vastgestelde eisen en de Kwaliteitsaanpak en rapporteert aan de projectleider
minimum viable productde eerste versie van een product of dienst, die zo vroeg mogelijk wordt uitgerold naar de gebruikers; het bevat net voldoende functionaliteit om het gestelde doel te behalen, en niet meer dan dat
MTPmaster testplan
MVPminimum viable product
NFEniet-functionele eis(en)
NORANederlandse Overheidsreferentie-architectuur
NPRNederlandse Praktijkrichtlijn
ontwikkelaarsOntwikkelaars (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 organisatieoverheidsorganisatie die opdracht geeft aan ICTU tot ontwikkeling en/of onderhoud van software
opdrachtgevermedewerker van de opdrachtgevende organisatie die eindverantwoordelijk is voor de opdracht aan ICTU
operationeel beheeractiviteiten 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
OTAPontwikkel, test, acceptatie, productie; gebruikt om verschillende soorten omgevingen aan te duiden
personaeen 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
PIAprivacy impact assessment
PKIpublic key infrastructure
PRAproductrisicoanalyse
Product ownerDe product owner is verantwoordelijk voor het maximaliseren van de waarde van het product, dat het resultaat is van het werk van het Scrumteam [Scrumgids]
programmatuurzie software
projecteen 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
projectleidermedewerker eindverantwoordelijk voor het projectresultaat - bij ICTU-softwareontwikkelprojecten is de projectleider een medewerker van ICTU
PSADe projectstartarchitectuur is een concreet en doelgericht ICT-architectuurkader waarbinnen het project moet worden uitgevoerd
PvEprogramma van eisen
Quality-timeeen door ICTU ontwikkeld, open source, geautomatiseerd kwaliteitssysteem
realisatiefasefase van een softwareontwikkelproject waarin de software daadwerkelijk wordt gebouwd en onderhouden, en bij een DevOps werkwijze ook operationeel wordt beheerd
regressietesttest die na een wijziging controleert of niet-gewijzigde delen van een systeem nog steeds correct functioneren
release noteseen overzicht van de wijzigingen in een release
releaseeen voor gebruik vrijgegeven versie van de software
SADsoftware-architectuurdocument
ScrumScrum is een lichtgewicht raamwerk dat mensen, teams en organisaties helpt om waarde te creёren door middel van adaptieve oplossingen voor complexe problemen [Scrumgids]
ScrummasterDe Scrummaster is verantwoordelijk voor het opzetten van Scrum, zoals staat beschreven in de Scrumgids [Scrumgids]
ScrumteamEen Scrumteam bestaat uit één Scrummaster, één product owner en ontwikkelaars (developers in de Scrumgids) [Scrumgids]
softwarearchitectuureen architectuur die vooral de softwareonderdelen en -relaties (processen, modules, interfaces, datamodel) van een systeem beschrijft
software delivery managerorganiseert het ontwikkelen en opleveren van software conform de vastgestelde eisen en de Kwaliteitsaanpak en rapporteert aan de projectleider
softwaresoftware is de verzameling instructies die bepalen wat een computer uitvoert en is uiteindelijk wat de gebruiker ziet, ervaart en waarmee hij interacteert
softwareontwikkelingeen activiteit die nieuwe software maakt en/of bestaande software aanpast
softwareontwikkelprojecteen project dat de oplevering van software als enige of voornaamste projectresultaat heeft
solution architectuurbeschrijving van de gewenste oplossing van een specifiek probleem, of het eindresultaat van een project [NORA]
technische schuldeigenschappen van de software die de lange-termijninzetbaarheid en onderhoudbaarheid bedreigen
TVAthreat and vulnerability assessment
usabilitygebruiksvriendelijkheid
use caseeen afgebakende eenheid van interactie tussen een actor en het systeem
UXuser experience
VIRVoorschrift Informatiebeveiliging Rijksdienst
VIRBIVoorschrift Informatiebeveiliging Rijksdienst Bijzondere Informatie
VMvirtual machine, virtuele machine
voorfasefase van een softwareontwikkelproject, voorafgaande aan de realisatiefase, waarin de uitgangspunten, risico's en randvoorwaarden voor de realisatiefase worden bepaald en waarin wordt gezorgd dat aan de randvoorwaarden wordt voldaan en dat voor zoveel mogelijk risico's maatregelen getroffen zijn
vrijgaveadviesadvies om een release vrij te geven voor ingebruikname, met een testverslag dat tenminste alle nog openstaande testbevindingen en geconstateerde beveiligingsbevindingen bevat

Bronnen

De onderstaande tabel verwijst naar regelmatig gebruikte bronnen.

BronToelichting
BIOBaseline Informatiebeveiliging Overheid.
ISO 9241-210:2019Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems.
NCSC ICT-beveiligingsrichtlijnen voor webapplicatiesDe ICT-beveiligingsrichtlijnen voor webapplicaties geven een leidraad voor veiliger ontwikkelen, beheren en aanbieden van webapplicaties en bijbehorende infrastructuur.
NEN-ISO/IEC 25010:2011Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models.
NEN-ISO/IEC 27001:2017Informatietechnologie - Beveiligingstechnieken - Managementsystemen voor informatiebeveiliging - Eisen
NEN-ISO/IEC 27002:2017Informatietechnologie - Beveiligingstechnieken - Praktijkrichtlijn met beheersmaatregelen op het gebied van informatiebeveiliging
NEN 7510:2017Informatiebeveiliging in de zorg.
NEN NPR 5325:2017Praktijkrichtlijn voor het overdragen van software.
NEN NPR 5326:2019Praktijkrichtlijn voor risicobeheersing bij softwareontwikkeling.
NORAReferentiearchitectuur voor de Nederlandse Overheid.
OWASP Top-10De OWASP Top-10 is een op consensus gebaseerd overzicht van de meest kritische beveiligingsrisico's voor webapplicaties.
ScrumgidsDe Scrum Gids - De Definitieve Gids voor Scrum: De Regels van het Spel.
VIR 2007Besluit Voorschrift Informatiebeveiliging Rijksdienst 2007.
VIRBI 2013Besluit Voorschrift Informatiebeveiliging Rijksdienst Bijzondere Informatie 2013.
Wbni 2018Wet Beveiliging Netwerk- en Informatiesystemen. Beschrijft de meldplicht en de zorgplicht die van toepassing zijn op organisaties die vitaal zijn én op digitale dienstverleners.

Overzicht maatregelen

Hieronder zijn alle maatregeldefinities uit deze Kwaliteitsaanpak opgenomen, op volgorde van maatregelnummer.

M01: Het project levert in elke fase vastgestelde producten en informatie op
Iedere projectfase levert specifieke informatie op. De voorfase levert inzicht in de functionele en niet-functionele eisen, ontwerp en architectuur, testplannen, operationele risico's, en benodigde kwaliteitsmaatregelen. Deze informatie wordt tijdens de realisatiefase waar nodig bijgewerkt. De realisatiefase levert één of meerdere werkende versies van de software met regressietests, aangevuld met een vrijgaveadvies, release notes en installatiedocumentatie.
M02: Het project bewaakt continu dat het product aan de kwaliteitsnormen voldoet
Projecten bewaken zo snel mogelijk vanaf de start de door het project en ICTU vastgestelde kwaliteitsnormen en voldoen daar zo snel en goed mogelijk aan. De kwaliteit van producten, die nog niet zijn afgerond of nog niet aan de normen voldoen, wordt door het project bewaakt. Het voldoen aan de kwaliteitsnormen is onderdeel van de Definition of Done en herstel van de kwaliteit wordt planmatig opgepakt.
M03: Het project zorgt dat het product traceerbaar aan eisen voldoet
Eisen zijn wederzijds traceerbaar naar bewijsmateriaal, zoals logische testgevallen, dat de eis gerealiseerd is; dat wil zeggen dat geadministreerd is bij welke eis bewijsmateriaal hoort en vice versa. Dit wordt waar mogelijk met tooling ondersteund.
M04: Het project borgt de correcte werking van het product met geautomatiseerde regressietests
Regressietests - tests die verifiëren of eerder ontwikkelde software nog steeds correct werkt na wijzigingen in de software of aansluiting op andere externe koppelvlakken - zijn geautomatiseerd.
M05: Het project hanteert een iteratief en incrementeel ontwikkelproces
Projecten werken iteratief en incrementeel; dit betekent dat een project in korte iteraties werkt, waarbij elke iteratie een werkende versie van de software oplevert die extra waarde vertegenwoordigt voor de opdrachtgevende organisatie. Behalve de software werkt het project ook iedere iteratie alle andere producten bij. Elke iteratie worden verwachtingen en werkelijke resultaten vergeleken en wordt de werkwijze aangescherpt op basis van inzichten en bevindingen.
M07: Het project gebruikt een continuous delivery pipeline om het product te bouwen, testen en op te leveren
Er is een geautomatiseerde continuous delivery pipeline die aantoonbaar correct werkt en de software bouwt, installeert in de testomgevingen, test op functionele en niet-functionele eigenschappen en oplevert, al dan niet inclusief installatie in de productieomgeving.
M08: Het project maakt technische schuld inzichtelijk en lost deze planmatig op
Technische schuld is inzichtelijk en wordt planmatig aangepakt. De kwaliteitsmanager is verantwoordelijk voor het inzichtelijk maken van de technische schuld. De software delivery manager is verantwoordelijk voor het planmatig aanpakken van de technische schuld en zorgt dat het Scrumteam regelmatig en voldoende tijd heeft om technische schuld te voorkomen en op te lossen. Het Scrumteam is verantwoordelijk voor het zoveel mogelijk voorkomen van technische schuld en voor het identificeren van technische schuld die toch optreedt.
M10: Het project kent een wekelijks projectoverleg
De projectleider organiseert een periodiek projectoverleg. Dit overleg vindt wekelijks plaats en duurt niet langer dan een uur. Vereiste aanwezigen zijn de projectleider, de software delivery manager, de Scrummaster, een vertegenwoordiger uit elk van de Scrumteams en de kwaliteitsmanager van het project; andere aanwezigen kunnen zijn: de projectarchitect en de product owner. De agenda voor dit overleg bestaat ten minste uit de volgende onderwerpen: mededelingen, actie- en besluitenlijst, personele zaken, planning en voortgang, kwaliteit en architectuur, risico's en aandachtspunten.
M11: ICTU beheert, onderhoudt en implementeert de Kwaliteitsaanpak en kwaliteitsnormen
ICTU beheert, onderhoudt en implementeert de Kwaliteitsaanpak en de kwaliteitsnormen. Aanpassingen zijn gebaseerd op praktijkervaring, nieuwe inzichten en nieuwe mogelijkheden voor meting en analyse. Iedere medewerker kan wijzigingsvoorstellen indienen bij ICTU. ICTU behandelt de wijzigingsvoorstellen, kiest de te nemen actie bij elk wijzigingsvoorstel en legt de wijzigingsvoorstellen en besluiten vast.
M12: ICTU publiceert nieuwe versies van de Kwaliteitsaanpak en normen periodiek en op een vaste locatie
ICTU publiceert periodiek een nieuwe versie van de Kwaliteitsaanpak en/of de kwaliteitsnormen op een vaste, bekende locatie.
M13: Het project gebruikt ISO-25010 voor de specificatie van productkwaliteitseisen
Voor specificatie en documentatie van vereiste en gewenste kwaliteitseigenschappen, de niet-functionele eisen, maken projecten gebruik van de terminologie en categorisering uit NEN-ISO/IEC 25010. Projecten gebruiken NEN-ISO/IEC 25010 om te controleren of alle relevante kwaliteitseigenschappen van het op te leveren eindproduct worden meegenomen in de ontwikkeling en/of onderhoud van het product.
M14: Het project bereidt samen met opdrachtgevende organisatie en betrokken partijen de realisatie voor
Projecten hebben een voorbereidingsfase, "voorfase" genoemd, voorafgaand aan de realisatiefase. Voor het uitvoeren van de voorfase zijn vertegenwoordigers van de opdrachtgevende organisatie, de beoogde beheerorganisatie en andere partijen betrokken die meewerken aan het realiseren van een deel van de op te leveren producten. Het doel van de voorfase is beeld krijgen van de te realiseren oplossing, van de risico's die zich tijdens realisatie kunnen voordoen en van de kaders waarbinnen de oplossing moet passen; tijdens de realisatiefase vinden bouw en onderhoud van de software en actualiseren en afronden van documentatie plaats.
M16: Het project gebruikt tools voor vastgestelde taken
ICTU stelt het gebruik van tools verplicht voor de volgende taken:
  1. backlog management en agile werken,
  2. inrichten en uitvoeren van een continuous delivery pipeline,
  3. monitoren van de kwaliteit van broncode,
  4. versiebeheer van op te leveren producten,
  5. release van software,
  6. maken van testrapportages,
  7. maken van kwaliteitsrapportages,
  8. controleren van de configuratie op aanwezigheid van bekende kwetsbaarheden,
  9. controleren van door de applicatie gebruikte versies van externe software op aanwezigheid van bekende kwetsbaarheden,
  10. statische controle van de software op aanwezigheid van kwetsbare constructies,
  11. dynamische controle van de software op aanwezigheid van kwetsbare constructies,
  12. controleren van container images op aanwezigheid van bekende kwetsbaarheden,
  13. testen van performance en schaalbaarheid,
  14. testen op toegankelijkheid van de applicatie,
  15. produceren van een "software bill of materials" (SBoM),
  16. opslaan van artifacten,
  17. registratie van incidenten bij gebruik en beheer, en
  18. bij het uitvoeren van operationeel beheer; uitrollen van de software in de productieomgeving.
M18: ICTU biedt ondersteuning voor verplicht gestelde tools
ICTU zorgt voor technische en functionele ondersteuning aan projecten bij het gebruik van alle verplichte tools.
M19: ICTU biedt projecten een afgeschermde digitale omgeving
ICTU geeft de projecten de beschikking over eigen, afgeschermde digitale omgevingen, waarbinnen ze de door het project ontwikkelde software en tools kunnen installeren en waartoe op een beheerste manier toegang wordt verleend.
M21: Het project selecteert medewerkers op basis van kwaliteit
Bij de inzet van medewerkers gaat kwaliteit boven andere aspecten, zoals beschikbaarheid, prijs en doorlooptijd.
M23: Het project zorgt voor de aanwezigheid van ervaring met de Kwaliteitsaanpak
De software delivery manager zorgt ervoor dat bij nieuwe projecten wordt gestart met ten minste twee projectleden die bekend zijn met de Kwaliteitsaanpak.
M26: Het project laat de beveiliging van het ontwikkelde product periodiek beoordelen
Projecten laten periodiek de beveiliging van de ontwikkelde software beoordelen. Een beveiligingsexpert onderzoekt de code zowel geautomatiseerd als handmatig op veelvoorkomende kwetsbaarheden en op het voldoen aan voorgeschreven beveiligingsnormen. Overheidsspecifieke beveiligingsnormen of -raamwerken, zoals de BIO (Baseline Informatiebeveiliging Overheid), bieden een basis voor de beoordeling. Bevindingen uit de beveiligingstest worden vastgelegd als onderdeel van de werkvoorraad voor het ontwikkelproces.
M27: Het project sluit projectfasen en zichzelf expliciet af
Afsluiting van een projectfase gebeurt expliciet en gecontroleerd: alle producten, zoals documentatie, broncode, referentiedata en credentials, die in de af te sluiten fase nodig waren of zijn opgeleverd, worden gearchiveerd. Indien er geen volgende fase is voorzien op korte termijn, dienen alle producten van de laptops van de projectmedewerkers verwijderd te worden.
M28: Het project voert periodiek een self-assessment uit tegen de actuele versie van de Kwaliteitsaanpak
De projectleider organiseert periodiek een self-assessment tegen de actuele versie van de Kwaliteitsaanpak en zet verbeteracties uit, waar nodig.
M29: ICTU organiseert voor aanvang van een project de interne dienstverlening
Voordat ICTU een softwareontwikkelproject start, dat gaat werken conform de Kwaliteitsaanpak, maakt de beoogde ICTU-projectleider afspraken met de afdelingen ICTU Software Diensten (ISD) en ICTU Software Expertise (ISE) over de af te nemen dienstverlening.
M30: Het project identificeert, mitigeert en bewaakt risico's
Het project identificeert, mitigeert en bewaakt projectspecifieke risico's voorafgaand aan en tijdens de projectuitvoering. Het project houdt een risicolog bij met geïdentificeerde risico's. De uitkomsten van de "Doordacht-van-Start-sessie", die al voorafgaand aan de start van het project wordt uitgevoerd, vormen het startpunt van deze risicolog. Risico's die tijdens de voorfase worden geïdentificeerd, bijvoorbeeld bij de productrisicoanalyse, worden toegevoegd aan de risicolog. Ook bij de start van de realisatiefase worden risicosessies gehouden met (vertegenwoordigers van) de belanghebbenden om verdere risico's te identificeren. Het project identificeert en implementeert mitigerende maatregelen danwel accepteert expliciet de geïdentificeerde risico's. Het project bewaakt de risicolog en uitvoering van de mitigerende maatregelen tijdens het IPO.
M31: Het project beschikt over actuele vastgestelde informatie
Voor een goede uitvoering van het project is specifieke informatie nodig. De opdrachtgevende organisatie zorgt dat het project bij de start van de voorfase inzicht heeft in de informatie die typisch wordt vastgelegd in een projectstartarchitectuur, business impact analysis en privacy impact assessment. Waar nodig werkt de opdrachtgevende organisatie de informatie bij tijdens de voorfase en realisatiefase.
M32: Het project onderzoekt de kwaliteit van over te nemen software
Als tijdens een project bestaande software dient te worden afgebouwd, onderhouden en/of herbouwd, vindt een onderzoek plaats naar de kwaliteit van deze software.
M33: ICTU organiseert periodiek een gezamenlijke self-assessment ten aanzien van de Kwaliteitsaanpak
ICTU organiseert periodiek een gezamenlijke self-assessment ten aanzien van de Kwaliteitsaanpak die inzicht geeft in de huidige status van de Kwaliteitsaanpak en aanleiding kan geven tot het nemen van maatregelen om de Kwaliteitsaanpak en de ondersteuning daarvan door ICTU te verbeteren.
M34: Het project draagt software beheerst over
Als de software op enig moment door een andere partij dan ICTU verder ontwikkeld en/of onderhouden zal worden, draagt het project zorg voor een beheerste overdracht. Beheerdocumentatie, broncode en testmiddelen zijn van dusdanige kwaliteit en compleetheid dat de andere partij de software efficiënt en effectief kan doorontwikkelen en/of onderhouden.

Relatie met NEN NPR 5326

De Nederlandse Praktijkrichtlijn "Risicobeheersing bij ontwikkeling en onderhoud van maatwerksoftware" [NEN NPR 5326:2019] beschrijft beheersmaatregelen voor een deel van de risico’s die inherent zijn aan softwareontwikkeling op maat. Onderstaande tabel laat de relatie zien tussen de risicobeheersmaatregelen uit de NPR 5326 en de maatregelen uit deze Kwaliteitsaanpak.

NPR 5326 risicobeheersmaatregelMaatregelen KwaliteitsaanpakToelichting
Maatregel 01: Belanghebbenden identificeren en betrekkenM14: Het project bereidt samen met opdrachtgevende organisatie en betrokken partijen de realisatie voorVoorafgaand aan en tijdens de voorfase identificeert en betrekt ICTU de belanghebbenden
Maatregel 02: Belangrijke niet-functionele eisen identificerenM01: Het project levert in elke fase vastgestelde producten en informatie opDe niet-functionele eisen zijn een van de uitkomsten van de voorfase
Maatregel 03: Belangrijke functionele eisen identificerenM01: Het project levert in elke fase vastgestelde producten en informatie opDe functionele eisen zijn een van de uitkomsten van de voorfase
Maatregel 04: Productdecompositie in incrementeel opleverbare delen met business-waardeM01: Het project levert in elke fase vastgestelde producten en informatie opDe product backlog is een van de uitkomsten van de voorfase
Maatregel 05: Technische schuld identificeren, inzichtelijk maken en planmatig oplossenM08: Het project maakt technische schuld inzichtelijk en lost deze planmatig op, M32: Het project onderzoekt de kwaliteit van over te nemen software
Maatregel 06: Oplossingsrichtingen verkennenM01: Het project levert in elke fase vastgestelde producten en informatie opTijdens de voorfase worden oplossingsrichtingen verkend, bijvoorbeeld met behulp van een prototype
Maatregel 07: Incrementele oplevering van het productM05: Het project hanteert een iteratief en incrementeel ontwikkelprocesICTU hanteert een iteratief en incrementeel ontwikkelproces
Maatregel 08: Iteratieve ontwikkelaanpakM05: Het project hanteert een iteratief en incrementeel ontwikkelprocesICTU hanteert een iteratief en incrementeel ontwikkelproces
Maatregel 09: Geautomatiseerde ontwikkelpijplijn inrichtenM07: Het project gebruikt een continuous delivery pipeline om het product te bouwen, testen en op te leveren
Maatregel 10: Voortdurend voldoen aan de eisen met regressietestsM04: Het project borgt de correcte werking van het product met geautomatiseerde regressietests
Maatregel 11: Voortgangsbewaking met burndown chartsM10: Het project kent een wekelijks projectoverlegProjecten bespreken de voortgang in het wekelijks projectoverleg aan de hand van backlog informatie uit het backlog management systeem
Maatregel 12: Een officiële producteigenaar met mandaatM05: Het project hanteert een iteratief en incrementeel ontwikkelprocesICTU hanteert Scrum, inclusief de rol van de product owner
Maatregel 13: Toepassen van een kwaliteitgedreven ontwikkelmethodeDe Kwaliteitsaanpak schrijft geen ontwikkelmethode voor aan de projecten; de borging van kwaliteitsnormen zal echter wel invloed hebben op de gevolgde ontwikkelmethode
Maatregel 14: ArchiveringM27: Het project sluit projectfasen en zichzelf expliciet af
Maatregel 15: Deugdelijke overdrachtM34: Het project draagt software beheerst over
Maatregel 16: Teams met specialistische kennis en hulpmiddelen ondersteunenM18: ICTU biedt ondersteuning voor verplicht gestelde tools, M19: ICTU biedt projecten een afgeschermde digitale omgeving
Maatregel 17: Continu risicomanagementM02: Het project bewaakt continu dat het product aan de kwaliteitsnormen voldoet, M10: Het project kent een wekelijks projectoverleg, M30: Het project identificeert, mitigeert en bewaakt risico'sProjecten voldoen continu aan de kwaliteitsnormen, identificeren en mitigeren projectspecifieke risico's en bespreken de risico's in het wekelijkse projectoverleg
\ No newline at end of file diff --git a/docs/wip/ICTU-Kwaliteitsaanpak.pdf b/docs/wip/ICTU-Kwaliteitsaanpak.pdf deleted file mode 100644 index 2ebfa190..00000000 Binary files a/docs/wip/ICTU-Kwaliteitsaanpak.pdf and /dev/null differ diff --git a/docs/wip/ICTU-Kwaliteitsaanpak.pptx b/docs/wip/ICTU-Kwaliteitsaanpak.pptx index c5abc553..e042d912 100644 Binary files a/docs/wip/ICTU-Kwaliteitsaanpak.pptx and b/docs/wip/ICTU-Kwaliteitsaanpak.pptx differ diff --git a/docs/wip/ICTU-Template-Compacte-Voorfase.docx b/docs/wip/ICTU-Template-Compacte-Voorfase.docx index ec3fd5d2..007be6a8 100644 Binary files a/docs/wip/ICTU-Template-Compacte-Voorfase.docx and b/docs/wip/ICTU-Template-Compacte-Voorfase.docx differ diff --git a/docs/wip/ICTU-Template-Detailtestplan-Softwarerealisatie.docx b/docs/wip/ICTU-Template-Detailtestplan-Softwarerealisatie.docx index 47c8e9c3..cf024558 100644 Binary files a/docs/wip/ICTU-Template-Detailtestplan-Softwarerealisatie.docx and b/docs/wip/ICTU-Template-Detailtestplan-Softwarerealisatie.docx differ diff --git a/docs/wip/ICTU-Template-Generiek.docx b/docs/wip/ICTU-Template-Generiek.docx index c01c98ef..9861359d 100644 Binary files a/docs/wip/ICTU-Template-Generiek.docx and b/docs/wip/ICTU-Template-Generiek.docx differ diff --git a/docs/wip/ICTU-Template-Globaal-Functioneel-Ontwerp.docx b/docs/wip/ICTU-Template-Globaal-Functioneel-Ontwerp.docx index d3701c43..023b635a 100644 Binary files a/docs/wip/ICTU-Template-Globaal-Functioneel-Ontwerp.docx and b/docs/wip/ICTU-Template-Globaal-Functioneel-Ontwerp.docx differ diff --git a/docs/wip/ICTU-Template-Inwerkplan-Kwaliteitsmanager.docx b/docs/wip/ICTU-Template-Inwerkplan-Kwaliteitsmanager.docx index d0f53496..0e3a6c31 100644 Binary files a/docs/wip/ICTU-Template-Inwerkplan-Kwaliteitsmanager.docx and b/docs/wip/ICTU-Template-Inwerkplan-Kwaliteitsmanager.docx differ diff --git a/docs/wip/ICTU-Template-Kwaliteitsplan.docx b/docs/wip/ICTU-Template-Kwaliteitsplan.docx index 0bb79c7d..9ad4ca3c 100644 Binary files a/docs/wip/ICTU-Template-Kwaliteitsplan.docx and b/docs/wip/ICTU-Template-Kwaliteitsplan.docx differ diff --git a/docs/wip/ICTU-Template-Plan-van-Aanpak-Realisatiefase.docx b/docs/wip/ICTU-Template-Plan-van-Aanpak-Realisatiefase.docx index c1c6521a..5bd60338 100644 Binary files a/docs/wip/ICTU-Template-Plan-van-Aanpak-Realisatiefase.docx and b/docs/wip/ICTU-Template-Plan-van-Aanpak-Realisatiefase.docx differ diff --git a/docs/wip/ICTU-Template-Plan-van-Aanpak-Voorfase.docx b/docs/wip/ICTU-Template-Plan-van-Aanpak-Voorfase.docx index 55a361e6..654799bb 100644 Binary files a/docs/wip/ICTU-Template-Plan-van-Aanpak-Voorfase.docx and b/docs/wip/ICTU-Template-Plan-van-Aanpak-Voorfase.docx differ diff --git a/docs/wip/ICTU-Template-Software-architectuurdocument.docx b/docs/wip/ICTU-Template-Software-architectuurdocument.docx index 0e20ac42..eaa247ba 100644 Binary files a/docs/wip/ICTU-Template-Software-architectuurdocument.docx and b/docs/wip/ICTU-Template-Software-architectuurdocument.docx differ diff --git a/docs/wip/Neutraal-Template-Generiek.docx b/docs/wip/Neutraal-Template-Generiek.docx index 87791e7b..9857f906 100644 Binary files a/docs/wip/Neutraal-Template-Generiek.docx and b/docs/wip/Neutraal-Template-Generiek.docx differ diff --git a/docs/wip/Neutraal-Template-Infrastructuurarchitectuur.docx b/docs/wip/Neutraal-Template-Infrastructuurarchitectuur.docx index f84d5118..f867854b 100644 Binary files a/docs/wip/Neutraal-Template-Infrastructuurarchitectuur.docx and b/docs/wip/Neutraal-Template-Infrastructuurarchitectuur.docx differ diff --git a/docs/wip/Neutraal-Template-Mastertestplan.docx b/docs/wip/Neutraal-Template-Mastertestplan.docx index 06fc8a6c..db4a2e75 100644 Binary files a/docs/wip/Neutraal-Template-Mastertestplan.docx and b/docs/wip/Neutraal-Template-Mastertestplan.docx differ diff --git a/docs/wip/Neutraal-Template-Niet-Functionele-Eisen.docx b/docs/wip/Neutraal-Template-Niet-Functionele-Eisen.docx index 4696dccb..ff1bd23b 100644 Binary files a/docs/wip/Neutraal-Template-Niet-Functionele-Eisen.docx and b/docs/wip/Neutraal-Template-Niet-Functionele-Eisen.docx differ diff --git a/pyproject.toml b/pyproject.toml index d615d227..8276e21a 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -14,6 +14,7 @@ dependencies = [ optional-dependencies.dev = [ "black==24.4.2", "coverage==7.6.0", + "lxml-stubs==0.5.1", "mypy==1.11.1", "pip-tools==7.4.1", "pylint==3.2.6", @@ -22,3 +23,22 @@ optional-dependencies.dev = [ [tool.black] line-length = 120 + +[tool.pylint] +max-line-length=120 + +[tool.mypy] +ignore_missing_imports = false +incremental = false +warn_redundant_casts = true +warn_return_any = true +warn_unreachable = true +warn_unused_ignores = true + +[[tool.mypy.overrides]] +module = [ + "pptx", + "pptx.util", + "xlsxwriter", +] +ignore_missing_imports = true diff --git a/requirements.txt b/requirements.txt index 02740920..9d4747cb 100644 --- a/requirements.txt +++ b/requirements.txt @@ -2,21 +2,75 @@ # This file is autogenerated by pip-compile with Python 3.12 # by the following command: # -# pip-compile pyproject.toml +# pip-compile --extra=dev # +astroid==3.2.4 + # via pylint +black==24.4.2 + # via ictu-kwaliteitsaanpak (pyproject.toml) +build==1.2.1 + # via pip-tools +click==8.1.7 + # via + # black + # pip-tools +coverage==7.6.0 + # via ictu-kwaliteitsaanpak (pyproject.toml) +dill==0.3.8 + # via pylint +isort==5.13.2 + # via pylint lxml==5.2.2 # via # python-docx # python-pptx +mccabe==0.7.0 + # via pylint +mypy==1.11.1 + # via ictu-kwaliteitsaanpak (pyproject.toml) +mypy-extensions==1.0.0 + # via + # black + # mypy +packaging==24.1 + # via + # black + # build +pathspec==0.12.1 + # via black pillow==10.4.0 # via python-pptx +pip-tools==7.4.1 + # via ictu-kwaliteitsaanpak (pyproject.toml) +platformdirs==4.2.2 + # via + # black + # pylint +pylint==3.2.6 + # via ictu-kwaliteitsaanpak (pyproject.toml) +pyproject-hooks==1.1.0 + # via + # build + # pip-tools python-docx==1.1.2 # via ictu-kwaliteitsaanpak (pyproject.toml) python-pptx==0.6.23 # via ictu-kwaliteitsaanpak (pyproject.toml) +tomlkit==0.13.0 + # via pylint typing-extensions==4.12.2 - # via python-docx + # via + # mypy + # python-docx +vulture==2.11 + # via ictu-kwaliteitsaanpak (pyproject.toml) +wheel==0.43.0 + # via pip-tools xlsxwriter==3.2.0 # via # ictu-kwaliteitsaanpak (pyproject.toml) # python-pptx + +# The following packages are considered to be unsafe in a requirements file: +# pip +# setuptools diff --git a/setup.cfg b/setup.cfg deleted file mode 100644 index 3eeaa2e8..00000000 --- a/setup.cfg +++ /dev/null @@ -1,38 +0,0 @@ -[mypy] -html_report = build/mypy -ignore_missing_imports = false -incremental = false -warn_redundant_casts = true -warn_return_any = true -warn_unreachable = true -warn_unused_ignores = true - -[mypy-docx] -ignore_missing_imports = true - -[mypy-docx.oxml] -ignore_missing_imports = true - -[mypy-docx.oxml.ns] -ignore_missing_imports = true - -[mypy-docx.table] -ignore_missing_imports = true - -[mypy-docx.text.paragraph] -ignore_missing_imports = true - -[mypy-docx.enum.text] -ignore_missing_imports = true - -[mypy-lxml] -ignore_missing_imports = true - -[mypy-pptx] -ignore_missing_imports = true - -[mypy-pptx.util] -ignore_missing_imports = true - -[mypy-xlsxwriter] -ignore_missing_imports = true diff --git a/src/builder/__init__.py b/src/builder/__init__.py index fab51def..671c7c16 100644 --- a/src/builder/__init__.py +++ b/src/builder/__init__.py @@ -2,6 +2,6 @@ from .builder import Builder from .docx_builder import DocxBuilder -from .html_builder import HTMLBuilder, HTMLContentBuilder, HTMLCoverBuilder +from .html_builder import HTMLBuilder from .pptx_builder import PptxBuilder from .xlsx_builder import XlsxBuilder diff --git a/src/builder/builder.py b/src/builder/builder.py index 23e02409..33f45477 100644 --- a/src/builder/builder.py +++ b/src/builder/builder.py @@ -8,7 +8,7 @@ class Builder: """Abstract builder.""" - # pylint: disable=unused-argument,no-self-use + # pylint: disable=unused-argument def __init__(self, filename: pathlib.Path) -> None: self.filename = filename diff --git a/src/builder/docx_builder.py b/src/builder/docx_builder.py index 4ae26c6a..879efe76 100644 --- a/src/builder/docx_builder.py +++ b/src/builder/docx_builder.py @@ -2,10 +2,11 @@ import pathlib import shutil -from typing import List, Optional +from typing import cast from docx import Document from docx.enum.text import WD_COLOR_INDEX, WD_PARAGRAPH_ALIGNMENT +from docx.shared import Cm from docx.table import Table from docx.table import _Row as Row from docx.text.paragraph import Paragraph @@ -17,7 +18,7 @@ from .table_of_contents import add_table_of_contents -class DocxBuilder(Builder): +class DocxBuilder(Builder): # pylint: disable=too-many-instance-attributes """Docx builder.""" SCHEMA = "{http://schemas.openxmlformats.org/wordprocessingml/2006/main}" @@ -41,13 +42,13 @@ def __init__( super().__init__(filename) filename.unlink(missing_ok=True) shutil.copy(docx_reference_filename, filename) - self.doc = Document(filename) + self.doc = Document(str(filename)) self.images_folder = images_folder - self.paragraph: Optional[Paragraph] = None # The current paragraph - self.current_list_style: List[str] = [] # Stack of list styles - self.previous_list_item: List[Optional[Paragraph]] = [] # Stack of previous list items - self.table: Optional[Table] = None - self.row: Optional[Row] = None + self.paragraph: Paragraph | None = None # The current paragraph + self.current_list_style: list[str] = [] # Stack of list styles + self.previous_list_item: list[Paragraph | None] = [] # Stack of previous list items + self.table: Table | None = None + self.row: Row | None = None self.column_index = 0 def start_element(self, tag: str, attributes: TreeBuilderAttributes) -> None: # pylint:disable=too-many-branches @@ -71,7 +72,10 @@ def start_element(self, tag: str, attributes: TreeBuilderAttributes) -> None: # style = f"Kop {level} Bijlage" if in_appendix else f"heading {level}" self.paragraph = self.doc.add_paragraph(style=style) elif tag == xmltags.TABLE: - self.table = self.doc.add_table(0, int(attributes[xmltags.TABLE_COLUMNS]), style="Tabelraster1") + self.table = cast( + Table, + self.doc.add_table(0, int(attributes[xmltags.TABLE_COLUMNS]), style="Tabelraster1"), + ) # Set table width to 100% self.table._tbl.tblPr.xpath("./w:tblW")[0].attrib[f"{self.SCHEMA}type"] = "pct" self.table._tbl.tblPr.xpath("./w:tblW")[0].attrib[f"{self.SCHEMA}w"] = "100%" @@ -82,7 +86,7 @@ def start_element(self, tag: str, attributes: TreeBuilderAttributes) -> None: # elif tag == xmltags.TABLE_CELL: self._add_table_cell(attributes) elif tag == xmltags.HEADER: - self.paragraph = self.doc.sections[0].header.paragraphs[0] + self.paragraph = cast(Paragraph, self.doc.sections[0].header.paragraphs[0]) self.paragraph.paragraph_format.alignment = WD_PARAGRAPH_ALIGNMENT.RIGHT # pylint: disable=no-member elif tag == xmltags.TITLE: self.paragraph = self.doc.add_paragraph(style="Title") @@ -90,14 +94,14 @@ def start_element(self, tag: str, attributes: TreeBuilderAttributes) -> None: # self.doc.add_paragraph(attributes[xmltags.TABLE_OF_CONTENTS_HEADING], style="TOC Heading") add_table_of_contents(self.doc.add_paragraph()) elif tag == xmltags.IMAGE: - self.doc.add_picture(str(self.images_folder / str(attributes["src"]))) + self.doc.add_picture(str(self.images_folder / str(attributes["src"])), width=Cm(int(attributes["width"]))) def _add_list_item(self) -> None: """Add a list item.""" # pylint: disable=protected-access self.paragraph = self.doc.add_paragraph(style=self.current_list_style[-1]) level = len(self.current_list_style) - 1 - self.paragraph._p.get_or_add_pPr().get_or_add_numPr().get_or_add_ilvl().val = level + self.paragraph_number(self.paragraph).get_or_add_ilvl().val = level if self.current_list_style[-1] == "Lijstnummering1": if self.previous_list_item[-1] is None: # Add a new concrete numbering for Lijstnummering1. "0" is the id of the abstract numbering of @@ -108,24 +112,30 @@ def _add_list_item(self) -> None: num.add_lvlOverride(ilvl=level).add_startOverride(1) # Restart the numbering num = num.numId else: - num = self.previous_list_item[-1]._p.pPr.numPr.numId.val - self.paragraph._p.get_or_add_pPr().get_or_add_numPr().get_or_add_numId().val = num + num = self.previous_list_item[-1]._p.pPr.numPr.numId.val # type: ignore[union-attr] + self.paragraph_number(self.paragraph).get_or_add_numId().val = num self.previous_list_item[-1] = self.paragraph + @staticmethod + def paragraph_number(paragraph: Paragraph): + """Return the current paragraph number .""" + # pylint: disable=protected-access + return paragraph._p.get_or_add_pPr().get_or_add_numPr() # type: ignore[attr-defined] + def _add_table_cell(self, attributes: TreeBuilderAttributes) -> None: """Add a table cell.""" # pylint: disable=protected-access assert self.row cell = self.row.cells[self.column_index] - cell._tc.tcPr.tcW.type = "auto" - self.paragraph = cell.paragraphs[0] + cell._tc.tcPr.tcW.type = "auto" # type: ignore[union-attr] + self.paragraph = cast(Paragraph, cell.paragraphs[0]) if alignment_attr := attributes.get(xmltags.TABLE_CELL_ALIGNMENT): # pylint: disable=no-member - alignment = dict( - left=WD_PARAGRAPH_ALIGNMENT.LEFT, - right=WD_PARAGRAPH_ALIGNMENT.RIGHT, - center=WD_PARAGRAPH_ALIGNMENT.CENTER, - )[str(alignment_attr)] + alignment = { + "left": WD_PARAGRAPH_ALIGNMENT.LEFT, + "right": WD_PARAGRAPH_ALIGNMENT.RIGHT, + "center": WD_PARAGRAPH_ALIGNMENT.CENTER, + }[str(alignment_attr)] self.paragraph.paragraph_format.alignment = alignment self.column_index += 1 @@ -160,4 +170,4 @@ def end_element(self, tag: str, attributes: TreeBuilderAttributes) -> None: self.previous_list_item.pop() def end_document(self) -> None: - self.doc.save(self.filename) + self.doc.save(str(self.filename)) diff --git a/src/builder/html_builder.py b/src/builder/html_builder.py index 49d10633..bba7c1f5 100644 --- a/src/builder/html_builder.py +++ b/src/builder/html_builder.py @@ -1,7 +1,7 @@ """HTML builder.""" import pathlib -from typing import List, Optional +from typing import cast from xml.etree.ElementTree import ElementTree, TreeBuilder import xmltags @@ -30,70 +30,69 @@ def __init__(self, filename: pathlib.Path, stylesheet_path: pathlib.Path) -> Non super().__init__(filename) self.stylesheet_path = stylesheet_path self.builder = TreeBuilder() - self.heading_class: List[str] = [] # Heading class stack - self.heading_level: List[int] = [] # Heading level stack - self.table_cell_html_tag: Optional[str] = None + self.heading_class: list[str] = [] # Heading class stack + self.heading_level: list[int] = [] # Heading level stack + self.table_cell_html_tag: str | None = None self.in_keep_together_div = False self.in_measure = False - self.frontpage_done = False def start_element(self, tag: str, attributes: TreeBuilderAttributes) -> None: # pylint:disable=too-many-branches - if tag == xmltags.DOCUMENT: - self.builder.start(html_tags.HTML, {html_tags.LANGUAGE: "nl"}) - self.builder.start(html_tags.HEAD, {}) - self.builder.start(html_tags.META, {html_tags.META_CHARSET: "UTF-8"}) - self.builder.end(html_tags.META) - self.builder.start(html_tags.TITLE, {}) - self.builder.data(f"{attributes['title']} versie {attributes['version']}") - self.builder.end(html_tags.TITLE) - self.builder.start( - html_tags.LINK, - {html_tags.LINK_REL: "stylesheet", html_tags.LINK_HREF: self.STYLESHEET}, - ) - self.builder.end(html_tags.LINK) - self.builder.end(html_tags.HEAD) - self.builder.start(html_tags.BODY, {}) - elif tag == xmltags.PARAGRAPH: - if not self.in_measure: - self.builder.start(html_tags.PARAGRAPH, attributes) - elif tag in self.LIST: - self.builder.start(self.LIST[tag], {}) - elif tag in self.FORMAT: - self.builder.start(self.FORMAT[tag], {}) - elif tag == xmltags.SECTION: - self.heading_class.append("bijlage" if attributes.get(xmltags.SECTION_IS_APPENDIX) else "") - self.heading_level.append(int(attributes[xmltags.SECTION_LEVEL])) - elif tag == xmltags.TABLE: - self.builder.start(html_tags.TABLE, {}) - elif tag == xmltags.TABLE_HEADER_ROW: - self.table_cell_html_tag = html_tags.TABLE_HEAD_CELL - self.builder.start(html_tags.TABLE_HEAD, {}) - self.builder.start(html_tags.TABLE_ROW, {}) - elif tag == xmltags.TABLE_ROW: - self.table_cell_html_tag = html_tags.TABLE_BODY_CELL - self.builder.start(html_tags.TABLE_ROW, {}) - elif tag == xmltags.TABLE_CELL: - assert self.table_cell_html_tag - alignment = str(attributes[xmltags.TABLE_CELL_ALIGNMENT]) - self.builder.start(self.table_cell_html_tag, {html_tags.STYLE: f"text-align:{alignment}"}) - elif tag == xmltags.ANCHOR: - self.builder.start( - html_tags.ANCHOR, - {html_tags.ANCHOR_LINK: attributes[xmltags.ANCHOR_LINK]}, - ) - elif tag == xmltags.IMAGE: - image_attributes = { - html_tags.STYLE: "max-width: 100%", - html_tags.IMAGE_SOURCE: attributes["src"], - } - title = attributes.get("title", "") - alt = attributes.get("alt", "") - image_attributes[html_tags.IMAGE_ALT] = f"{title}{': ' if title and alt else ''}{alt}" - self.builder.start(html_tags.IMAGE, image_attributes) - self.builder.end(html_tags.IMAGE) - elif tag == xmltags.MEASURE: - self.builder.start(html_tags.DIV, {html_tags.CLASS: "maatregel"}) - self.in_measure = True + match tag: + case xmltags.DOCUMENT: + self.builder.start(html_tags.HTML, {html_tags.LANGUAGE: "nl"}) + self.builder.start(html_tags.HEAD, {}) + self.builder.start(html_tags.META, {html_tags.META_CHARSET: "UTF-8"}) + self.builder.end(html_tags.META) + self.builder.start(html_tags.TITLE, {}) + self.builder.data(f"{attributes['title']} versie {attributes['version']}") + self.builder.end(html_tags.TITLE) + self.builder.start( + html_tags.LINK, + {html_tags.LINK_REL: "stylesheet", html_tags.LINK_HREF: self.STYLESHEET}, + ) + self.builder.end(html_tags.LINK) + self.builder.end(html_tags.HEAD) + self.builder.start(html_tags.BODY, {}) + case xmltags.PARAGRAPH: + if not self.in_measure: + self.builder.start(html_tags.PARAGRAPH, attributes) + case tag if tag in self.LIST: + self.builder.start(self.LIST[tag], {}) + case tag if tag in self.FORMAT: + self.builder.start(self.FORMAT[tag], {}) + case xmltags.SECTION: + self.heading_class.append("bijlage" if attributes.get(xmltags.SECTION_IS_APPENDIX) else "") + self.heading_level.append(int(attributes[xmltags.SECTION_LEVEL])) + case xmltags.TABLE: + self.builder.start(html_tags.TABLE, {}) + case xmltags.TABLE_HEADER_ROW: + self.table_cell_html_tag = html_tags.TABLE_HEAD_CELL + self.builder.start(html_tags.TABLE_HEAD, {}) + self.builder.start(html_tags.TABLE_ROW, {}) + case xmltags.TABLE_ROW: + self.table_cell_html_tag = html_tags.TABLE_BODY_CELL + self.builder.start(html_tags.TABLE_ROW, {}) + case xmltags.TABLE_CELL: + alignment = str(attributes[xmltags.TABLE_CELL_ALIGNMENT]) + self.builder.start(self.table_cell_html_tag, {html_tags.STYLE: f"text-align:{alignment}"}) + case xmltags.ANCHOR: + self.builder.start( + html_tags.ANCHOR, + {html_tags.ANCHOR_LINK: attributes[xmltags.ANCHOR_LINK]}, + ) + case xmltags.IMAGE: + image_attributes = { + html_tags.STYLE: "max-width: 100%", + html_tags.IMAGE_SOURCE: attributes["src"], + } + title = attributes.get("title", "") + alt = attributes.get("alt", "") + image_attributes[html_tags.IMAGE_ALT] = f"{title}{': ' if title and alt else ''}{alt}" + self.builder.start(html_tags.IMAGE, image_attributes) + self.builder.end(html_tags.IMAGE) + case xmltags.MEASURE: + self.builder.start(html_tags.DIV, {html_tags.CLASS: "maatregel"}) + self.in_measure = True def text(self, tag: str, text: str, attributes: TreeBuilderAttributes) -> None: if tag == xmltags.TITLE: @@ -115,39 +114,70 @@ def text(self, tag: str, text: str, attributes: TreeBuilderAttributes) -> None: self.builder.data(text) def end_element(self, tag: str, attributes: TreeBuilderAttributes) -> None: - if tag == xmltags.DOCUMENT: - self.builder.end(html_tags.BODY) - self.builder.end(html_tags.HTML) - elif tag == xmltags.FRONTPAGE: - self.frontpage_done = True - elif tag == xmltags.PARAGRAPH: - self.end_paragraph() - elif tag in self.LIST: - self.end_list(tag) - elif tag in self.FORMAT: - self.builder.end(self.FORMAT[tag]) - elif tag == xmltags.SECTION: - self.heading_class.pop() - self.heading_level.pop() - elif tag == xmltags.HEADING: - self.builder.end(html_tags.HEADING + str(self.heading_level[-1])) - elif tag == xmltags.TABLE: - self.builder.end(html_tags.TABLE_BODY) - self.builder.end(html_tags.TABLE) - elif tag == xmltags.TABLE_HEADER_ROW: - self.builder.end(html_tags.TABLE_ROW) - self.builder.end(html_tags.TABLE_HEAD) - self.builder.start(html_tags.TABLE_BODY, {}) - elif tag == xmltags.TABLE_ROW: - self.builder.end(html_tags.TABLE_ROW) - elif tag == xmltags.TABLE_CELL: - assert self.table_cell_html_tag - self.builder.end(self.table_cell_html_tag) - elif tag == xmltags.ANCHOR: - self.builder.end(html_tags.ANCHOR) - elif tag == xmltags.MEASURE: - self.builder.end(html_tags.DIV) - self.in_measure = False + match tag: + case xmltags.DOCUMENT: + self.builder.end(html_tags.MAIN) + self.builder.end(html_tags.BODY) + self.builder.start(html_tags.SCRIPT, {}) + self.builder.data( + """document.addEventListener('DOMContentLoaded', function() { + const toc = document.getElementById("toc"); + const headings = [].slice.call(document.body.querySelectorAll('main h1, main h2')); + + headings.forEach(function (heading, index) { + let ref = "toc" + index; + if (heading.hasAttribute("id")) + ref = heading.getAttribute("id"); + else + heading.setAttribute("id", ref); + + const div = toc.appendChild(document.createElement("div")); + div.setAttribute("class", heading.tagName.toLowerCase()); + heading.classList.forEach((className) => div.classList.add(className)) + + const link = div.appendChild(document.createElement("a")); + link.setAttribute("href", "#"+ ref); + link.textContent = heading.textContent; + }); + }); + """ + ) + self.builder.end(html_tags.SCRIPT) + self.builder.end(html_tags.HTML) + case xmltags.FRONTPAGE: + self.builder.start(html_tags.NAV, {"id": "toc"}) + self.builder.start(html_tags.HEADING + "1", {html_tags.CLASS: "toc"}) + self.builder.data("Inhoudsopgave") + self.builder.end(html_tags.HEADING + "1") + self.builder.end(html_tags.NAV) + self.builder.start(html_tags.MAIN, {}) + case xmltags.PARAGRAPH: + self.end_paragraph() + case tag if tag in self.LIST: + self.end_list(tag) + case tag if tag in self.FORMAT: + self.builder.end(self.FORMAT[tag]) + case xmltags.SECTION: + self.heading_class.pop() + self.heading_level.pop() + case xmltags.HEADING: + self.builder.end(html_tags.HEADING + str(self.heading_level[-1])) + case xmltags.TABLE: + self.builder.end(html_tags.TABLE_BODY) + self.builder.end(html_tags.TABLE) + case xmltags.TABLE_HEADER_ROW: + self.builder.end(html_tags.TABLE_ROW) + self.builder.end(html_tags.TABLE_HEAD) + self.builder.start(html_tags.TABLE_BODY, {}) + case xmltags.TABLE_ROW: + self.builder.end(html_tags.TABLE_ROW) + case xmltags.TABLE_CELL: + self.builder.end(cast(str, self.table_cell_html_tag)) + case xmltags.ANCHOR: + self.builder.end(html_tags.ANCHOR) + case xmltags.MEASURE: + self.builder.end(html_tags.DIV) + self.in_measure = False def end_paragraph(self) -> None: """End the paragraph.""" @@ -168,21 +198,8 @@ def end_list(self, tag: str) -> None: self.builder.end(html_tags.DIV) def end_document(self) -> None: + """End the document and save it.""" tree = ElementTree(self.builder.close()) with open(self.filename, mode="w", encoding="utf-8") as html_file: html_file.write("\n") tree.write(html_file, "unicode", method="html") - - -class HTMLContentBuilder(HTMLBuilder): - """HTML document content builder.""" - - def accept_element(self, tag: str) -> bool: - return tag != xmltags.FRONTPAGE - - -class HTMLCoverBuilder(HTMLBuilder): - """HTML cover builder.""" - - def accept_element(self, tag: str) -> bool: - return not self.frontpage_done diff --git a/src/builder/html_tags.py b/src/builder/html_tags.py index 90268205..2f0b22dd 100644 --- a/src/builder/html_tags.py +++ b/src/builder/html_tags.py @@ -19,10 +19,13 @@ LINK_HREF = "href" LINK_REL = "rel" LIST_ITEM = "li" +MAIN = "main" META = "meta" META_CHARSET = "charset" +NAV = "nav" ORDERED_LIST = "ol" PARAGRAPH = "p" +SCRIPT = "script" STRIKETROUGH = "s" STYLE = "style" TABLE = "table" diff --git a/src/builder/pptx_builder.py b/src/builder/pptx_builder.py index 20e19599..aa1b92a7 100644 --- a/src/builder/pptx_builder.py +++ b/src/builder/pptx_builder.py @@ -61,8 +61,8 @@ def text(self, tag: str, text: str, attributes: TreeBuilderAttributes) -> None: paragraph.font.size = Pt(20) elif ( tag == xmltags.HEADING - and self.in_element(xmltags.SECTION, dict(level="1")) - and not self.in_element(xmltags.SECTION, dict(level="2")) + and self.in_element(xmltags.SECTION, {"level": "1"}) + and not self.in_element(xmltags.SECTION, {"level": "2"}) ): self.chapter_heading = text elif tag == xmltags.LIST_ITEM and self.in_element(xmltags.SLIDE): @@ -87,6 +87,7 @@ def add_text_box(self): def remove_bullet(self, paragraph_index: int): """Remove bullets from the paragraph.""" + # pylint: disable=c-extension-no-member no_bullet = etree.Element("{http://schemas.openxmlformats.org/drawingml/2006/main}buNone") # pylint: disable=protected-access self.current_slide.shapes[1].text_frame.paragraphs[paragraph_index]._pPr.insert(0, no_bullet) # type: ignore diff --git a/src/builder/xlsx_builder.py b/src/builder/xlsx_builder.py index 3f6d7511..14d2aad5 100644 --- a/src/builder/xlsx_builder.py +++ b/src/builder/xlsx_builder.py @@ -33,20 +33,20 @@ def __init__(self, filename: pathlib.Path) -> None: @staticmethod def __create_formats(workbook: xlsxwriter.Workbook) -> Dict[str, xlsxwriter.format.Format]: """Create the formats.""" - measure_format_options = dict(bg_color="#BCD2EE", text_wrap=True, valign="top") - status_format_options = dict(bg_color="#FED32D", text_wrap=True) + measure_format_options = {"bg_color": "#BCD2EE", "text_wrap": True, "valign": "top"} + status_format_options = {"bg_color": "#FED32D", "text_wrap": True} return { - "header": workbook.add_format(dict(text_wrap=True, font_size=14, bold=True, bg_color="#B3D6C9")), - "instructions": workbook.add_format(dict(text_wrap=True, font_size=13, bg_color="#B3D6C9")), + "header": workbook.add_format({"text_wrap": True, "font_size": 14, "bold": True, "bg_color": "#B3D6C9"}), + "instructions": workbook.add_format({"text_wrap": True, "font_size": 13, "bg_color": "#B3D6C9"}), "measure": workbook.add_format(measure_format_options), - "submeasure": workbook.add_format(dict(align="vjustify", indent=1, **measure_format_options)), - "explanation": workbook.add_format(dict(bg_color="#FFFFA5", text_wrap=True)), + "submeasure": workbook.add_format({"align": "vjustify", "indent": 1, **measure_format_options}), + "explanation": workbook.add_format({"bg_color": "#FFFFA5", "text_wrap": True}), "status": workbook.add_format(status_format_options), - "substatus": workbook.add_format(dict(indent=1, **status_format_options)), - "voldoet": workbook.add_format(dict(fg_color="#0B5101", bg_color="#BBEDC3")), - "voldoet deels": workbook.add_format(dict(fg_color="#894503", bg_color="#FEE88A")), - "voldoet niet": workbook.add_format(dict(fg_color="#880009", bg_color="#FEB8C3")), - "niet van toepassing": workbook.add_format(dict(fg_color="#6D6D6D", bg_color="#EFEFEF")), + "substatus": workbook.add_format({"indent": 1, **status_format_options}), + "voldoet": workbook.add_format({"fg_color": "#0B5101", "bg_color": "#BBEDC3"}), + "voldoet deels": workbook.add_format({"fg_color": "#894503", "bg_color": "#FEE88A"}), + "voldoet niet": workbook.add_format({"fg_color": "#880009", "bg_color": "#FEB8C3"}), + "niet van toepassing": workbook.add_format({"fg_color": "#6D6D6D", "bg_color": "#EFEFEF"}), } def start_element(self, tag: str, attributes: TreeBuilderAttributes) -> None: @@ -81,7 +81,7 @@ def text(self, tag: str, text: str, attributes: TreeBuilderAttributes) -> None: if tag == xmltags.BOLD: self.measure_row = self.row self.measure_id, measure_title = text.split(":") - has_submeasures = self.in_element(xmltags.MEASURE, dict(composite="true")) + has_submeasures = self.in_element(xmltags.MEASURE, {"composite": "true"}) self.__write_measure(self.measure_id, measure_title.strip(), has_submeasures=has_submeasures) self.measure_text.append(text) elif self.measure_text: @@ -116,7 +116,7 @@ def __write_measure( self.checklist.write_comment( self.row, self.STATUS_COLUMN, - "Tip: bepaal eerst de status per submaatregel en daarna de status van de hoofdmaatregel." + "Tip: bepaal eerst de status per submaatregel en daarna de status van de hoofdmaatregel.", ) self.checklist.write(self.row, self.STATUS_COLUMN, "", self.formats[status_format_key]) self.checklist.write(self.row, self.EXPLANATION_COLUMN, "", self.formats["explanation"]) @@ -130,7 +130,7 @@ def end_element(self, tag: str, attributes: TreeBuilderAttributes) -> None: self.measure_row, self.MEASURE_COLUMN, "".join(self.measure_text), - dict(x_scale=7, y_scale=8, font_name="Courier", font_size=9), + {"x_scale": 7, "y_scale": 8, "font_name": "Courier", "font_size": 9}, ) self.measure_text = [] self.row += 1 @@ -209,7 +209,7 @@ def __write_assessment_choices(self, row: int, column: int) -> None: column, {"type": "cell", "criteria": "==", "value": f'"{choice}"', "format": self.formats[choice]}, ) - self.checklist.data_validation(row, column, row, column, dict(validate="list", source=assessment_choices)) + self.checklist.data_validation(row, column, row, column, {"validate": "list", "source": assessment_choices}) def __create_action_list(self) -> None: """Create a worksheet with room for actions from the self-assessment.""" diff --git a/src/convert.py b/src/convert.py index e5983635..d996e283 100644 --- a/src/convert.py +++ b/src/convert.py @@ -15,7 +15,7 @@ from cli import parse_cli_arguments from converter import Converter -from builder import DocxBuilder, HTMLBuilder, HTMLContentBuilder, HTMLCoverBuilder, PptxBuilder, XlsxBuilder +from builder import DocxBuilder, HTMLBuilder, PptxBuilder, XlsxBuilder from markdown_converter import MarkdownConverter from markdown_syntax import VARIABLE_USE_PATTERN from custom_types import JSON, Settings, Variables @@ -33,9 +33,6 @@ def convert(settings_filename: str, version: str) -> None: converter = Converter(xml) if "docx" in settings["OutputFormats"]: convert_docx(converter, settings) - if "pdf" in settings["OutputFormats"]: - copy_files(settings, "pdf") - convert_pdf(converter, settings, variables) if "pptx" in settings["OutputFormats"]: convert_pptx(converter, settings) if "xlsx" in settings["OutputFormats"]: @@ -45,11 +42,11 @@ def convert(settings_filename: str, version: str) -> None: convert_html(converter, settings) -def read_variables(settings_filename: str, version: str) -> dict: +def read_variables(settings_filename: str, version: str) -> Variables: """Read the variables.""" settings = cast(Settings, read_json(settings_filename)) variables = cast(Variables, {}) - for variable_file in settings["VariablesFiles"]: + for variable_file in settings["VariablesFiles"]: # pylint: disable=unsubscriptable-object variables.update(cast(Variables, read_json(variable_file))) variables["VERSIE"] = version if version == "wip" else f"v{version}" variables["VERSIE_ZONDER_V"] = version @@ -57,22 +54,23 @@ def read_variables(settings_filename: str, version: str) -> dict: return variables -def read_settings(settings_filename: str, variables: Variables) -> dict: +def read_settings(settings_filename: str, variables: Variables) -> Settings: """Read the settings.""" settings = read_json(settings_filename, variables) + # pylint: disable=unsupported-assignment-operation settings["Version"] = variables["VERSIE"] settings["Date"] = variables["DATUM"] - return settings + return cast(Settings, settings) def read_json(json_filename: str, variables: Variables | None = None) -> JSON: """Read JSON from the specified filename.""" - variables = variables or {} + variables = variables or cast(Variables, {}) with open(json_filename, encoding="utf-8") as json_file: json_text = re.sub( VARIABLE_USE_PATTERN, lambda variable: variables.get(variable.group(1), variable.group(0)), - json_file.read() + json_file.read(), ) return JSON(json.loads(json_text)) @@ -102,37 +100,6 @@ def convert_html(converter, settings: Settings) -> None: copy_output(html_build_filename, settings, "html") -def convert_pdf(converter, settings: Settings, variables: Variables) -> None: - """Convert the XML to PDF.""" - build_path = get_build_path(settings) - html_filename = build_path / pathlib.Path(settings["InputFile"]).with_suffix(".html").name - html_builder = HTMLContentBuilder(html_filename, build_path) - converter.convert(html_builder) - html_cover_filename = build_path / pathlib.Path(settings["InputFile"]).with_suffix(".cover.html").name - html_cover_builder = HTMLCoverBuilder(html_cover_filename, build_path) - converter.convert(html_cover_builder) - with open("DocumentDefinitions/Shared/header.html", encoding="utf-8") as header_template_file: - header_contents = header_template_file.read() % variables["KWALITEITSAANPAK"] - header_filename = build_path / "header.html" - with open(header_filename, mode="w", encoding="utf-8") as header_file: - header_file.write(header_contents) - pdf_build_filename = build_path / pathlib.Path(settings["OutputFormats"]["pdf"]["OutputFile"]) - os.system( - f"""wkhtmltopdf \ - --enable-local-file-access \ - --footer-html DocumentDefinitions/Shared/footer.html --footer-spacing 10 \ - --header-html {header_filename} --header-spacing 10 \ - --margin-bottom 27 --margin-left 34 --margin-right 34 --margin-top 27 \ - --title '{settings["Title"]}' \ - cover {html_cover_filename} \ - {"toc --xsl-style-sheet DocumentDefinitions/Shared/toc.xsl" if settings["IncludeTableOfContents"] else ""} \ - {html_filename} {pdf_build_filename}""" - ) - pdf_build_filename2 = build_path / pathlib.Path(settings["OutputFormats"]["pdf"]["OutputFile"] + ".step2") - os.system(f"gs -o {pdf_build_filename2} -sDEVICE=pdfwrite -dPrinted=false -f {pdf_build_filename} src/pdfmark.txt") - copy_output(pdf_build_filename2, settings, "pdf") - - def convert_docx(converter, settings: Settings) -> None: """Convert the XML to docx.""" build_path = get_build_path(settings) diff --git a/src/markdown_converter.py b/src/markdown_converter.py index 4d8e5e84..9fd08b19 100644 --- a/src/markdown_converter.py +++ b/src/markdown_converter.py @@ -29,12 +29,12 @@ def __init__(self, variables: Variables) -> None: def convert(self, settings: Settings) -> ElementTree: """Convert the markdown to XML.""" - self.start_document(settings) - self.convert_markdown_file(pathlib.Path(settings["InputFile"]), settings) - self.end_document() + self._start_document(settings) + self._convert_markdown_file(pathlib.Path(settings["InputFile"]), settings) + self._end_document() return ElementTree(self.builder.close()) - def convert_markdown_file(self, markdown_filename: pathlib.Path, settings: Settings) -> None: + def _convert_markdown_file(self, markdown_filename: pathlib.Path, settings: Settings) -> None: """Convert markdown file to XML.""" with open(markdown_filename, encoding="utf-8") as markdown_file: for line in markdown_file.readlines(): @@ -43,87 +43,94 @@ def convert_markdown_file(self, markdown_filename: pathlib.Path, settings: Setti filename = filename.replace( "{{DOCUMENT-FOLDER}}", settings.get("DocumentFolder", "DocumentFolder missing in settings") ) - self.convert_markdown_file(pathlib.Path(filename), settings) + self._convert_markdown_file(pathlib.Path(filename), settings) else: - self.process_line(line) + self._process_line(line) - def start_document(self, settings: Settings) -> None: + def _start_document(self, settings: Settings) -> None: """Start the document.""" document_attributes: TreeBuilderAttributes = {} for setting, tag in (("Title", xmltags.DOCUMENT_TITLE), ("Version", xmltags.DOCUMENT_VERSION)): document_attributes[tag] = str(settings[setting]) self.builder.start(xmltags.DOCUMENT, document_attributes) - self.create_frontpage(settings) - self.create_header(settings) - self.create_footer() + self._create_frontpage(settings) + self._create_header(settings) + self._create_footer() if settings["IncludeTableOfContents"]: - self.create_table_of_contents() + self._create_table_of_contents() - def create_frontpage(self, settings: Settings) -> None: + def _create_frontpage(self, settings: Settings) -> None: """Create a front page.""" if not settings.get("FrontPage"): return document_type = settings["DocumentType"] with self.element(xmltags.FRONTPAGE): if settings["FrontPage"] == "ICTU": - self.add_element( + self._add_element( xmltags.IMAGE, - attributes={xmltags.IMAGE_SRC: "ICTU.png", xmltags.IMAGE_TITLE: "ICTU logo"}, + attributes={ + xmltags.IMAGE_SRC: "ICTU.png", + xmltags.IMAGE_TITLE: "ICTU logo", + xmltags.IMAGE_WIDTH: "5", + }, ) with self.element(xmltags.TITLE): - self.process_formatted_text(settings["Title"]) + self._process_formatted_text(settings["Title"]) if document_type == "Template": with self.element(xmltags.PARAGRAPH): with self.element(xmltags.INSTRUCTION): - self.add_element(xmltags.BOLD, settings["Subtitle"]) - self.add_element(xmltags.PARAGRAPH) + self._add_element(xmltags.BOLD, settings["Subtitle"]) + self._add_element(xmltags.PARAGRAPH) with self.element(xmltags.PARAGRAPH): - self.process_formatted_text("Rubriceringsniveau {Rubriceringsniveau}") + self._process_formatted_text("Rubriceringsniveau {Rubriceringsniveau}") with self.element(xmltags.PARAGRAPH): self.builder.data("Versie ") - self.add_element(xmltags.INSTRUCTION, "{Versienummer}") + self._add_element(xmltags.INSTRUCTION, "{Versienummer}") self.builder.data(", ") - self.add_element(xmltags.INSTRUCTION, "{Datum}") - self.add_element(xmltags.PARAGRAPH) + self._add_element(xmltags.INSTRUCTION, "{Datum}") + self._add_element(xmltags.PARAGRAPH) elif document_type == "Kwaliteitsaanpak": if settings.get("Subtitle"): with self.element(xmltags.PARAGRAPH): - self.add_element(xmltags.BOLD, settings["Subtitle"]) + self._add_element(xmltags.BOLD, settings["Subtitle"]) with self.element(xmltags.PARAGRAPH): self.builder.data(f"Versie {settings['Version']}, {settings['Date']}") else: raise ValueError(f"Unknown document type '{document_type}' in the settings") if settings["FrontPage"] == "ICTU": - self.add_element(xmltags.IMAGE, attributes={xmltags.IMAGE_SRC: "word-cloud.png"}) - self.add_element(xmltags.PAGEBREAK) + self._add_element( + xmltags.IMAGE, + attributes={xmltags.IMAGE_SRC: "word-cloud.png", xmltags.IMAGE_WIDTH: "15"}, + ) + self._add_element(xmltags.PAGEBREAK) - def create_header(self, settings: Settings) -> None: + def _create_header(self, settings: Settings) -> None: """Create the page header.""" title = settings["Title"] with self.element(xmltags.HEADER): if settings["DocumentType"] == "Template": - self.process_formatted_text(f"{title} ") - self.add_element(xmltags.INSTRUCTION, settings["Subtitle"]) + self._process_formatted_text(f"{title} ") + self._add_element(xmltags.INSTRUCTION, settings["Subtitle"]) else: self.builder.data(title) - def create_footer(self) -> None: + def _create_footer(self) -> None: """Create the page footer.""" - self.add_element(xmltags.FOOTER) + self._add_element(xmltags.FOOTER) - def create_table_of_contents(self) -> None: + def _create_table_of_contents(self) -> None: """Create the table of contents placeholder. Actually creating a table of contents is the responsibility of the target format (e.g. docx).""" - self.add_element(xmltags.TABLE_OF_CONTENTS, attributes={xmltags.TABLE_OF_CONTENTS_HEADING: "Inhoudsopgave"}) - self.add_element(xmltags.PAGEBREAK) + self._add_element(xmltags.TABLE_OF_CONTENTS, attributes={xmltags.TABLE_OF_CONTENTS_HEADING: "Inhoudsopgave"}) + self._add_element(xmltags.PAGEBREAK) - def process_line(self, line: str) -> None: + def _process_line(self, line: str) -> None: """Process a line of Markdown.""" if not (stripped_line := line.strip()): # pylint: disable=superfluous-parens - self.end_lists() - self.end_table() + self._end_lists() + self._end_table() return # Empty line, nothing further to do - stripped_line = self.process_variables(stripped_line) + stripped_line = self._process_variables(stripped_line) if match := re.match(markdown_syntax.BEGIN_PATTERN, stripped_line): attributes: dict[bytes | str, bytes | str] = {} if attribute := match.group(2): @@ -133,24 +140,24 @@ def process_line(self, line: str) -> None: elif match := re.match(markdown_syntax.END_PATTERN, stripped_line): self.builder.end(match.group(1)) elif match := re.match(markdown_syntax.HEADING_PATTERN, stripped_line): - self.process_heading(heading=match.group(2), level=len(match.group(1))) + self._process_heading(heading=match.group(2), level=len(match.group(1))) elif re.match(markdown_syntax.BULLET_LIST_PATTERN, stripped_line): list_level = {"*": 1, "+": 2, "-": 3}[stripped_line[0]] - self.process_list(stripped_line, xmltags.BULLET_LIST, list_level) + self._process_list(stripped_line, xmltags.BULLET_LIST, list_level) elif re.match(markdown_syntax.NUMBERED_LIST_PATTERN, stripped_line): list_level = 1 if line[0].isdigit() else (3 if stripped_line[0].isdigit() else 2) - self.process_list(stripped_line, xmltags.NUMBERED_LIST, list_level) + self._process_list(stripped_line, xmltags.NUMBERED_LIST, list_level) elif stripped_line[0] == markdown_syntax.TABLE_MARKER: - self.process_table_row(stripped_line) + self._process_table_row(stripped_line) else: with self.element(xmltags.PARAGRAPH): - self.process_formatted_text(stripped_line) + self._process_formatted_text(stripped_line) - def process_variables(self, line: str) -> str: + def _process_variables(self, line: str) -> str: """Replace the variables with their values.""" return re.sub(markdown_syntax.VARIABLE_USE_PATTERN, lambda variable: self.variables[variable.group(1)], line) - def process_heading(self, heading: str, level: int) -> None: + def _process_heading(self, heading: str, level: int) -> None: """Process a heading.""" if level == self.APPENDIX_LEVEL and heading == self.APPENDIX_HEADING: self.context.add(self.APPENDIX_HEADING) @@ -172,38 +179,38 @@ def process_heading(self, heading: str, level: int) -> None: self.current_section_level = level self.builder.start(xmltags.SECTION, {**is_appendix, xmltags.SECTION_LEVEL: str(self.current_section_level)}) with self.element(xmltags.HEADING): - self.process_formatted_text(heading) + self._process_formatted_text(heading) - def end_sections(self): + def _end_sections(self): """Close all sections.""" while self.current_section_level > 0: self.builder.end(xmltags.SECTION) self.current_section_level -= 1 - def process_list(self, line: str, tag: str, list_level: int) -> None: + def _process_list(self, line: str, tag: str, list_level: int) -> None: """Process a bullet or numbered list.""" - self.start_lists(tag, list_level) - self.end_lists(list_level) + self._start_lists(tag, list_level) + self._end_lists(list_level) self.list_counter[list_level - 1] += 1 number = str(self.list_counter[list_level - 1]) attributes: TreeBuilderAttributes = {xmltags.LIST_ITEM_NUMBER: number} if tag == xmltags.NUMBERED_LIST else {} with self.element(xmltags.LIST_ITEM, attributes): - self.process_formatted_text(line.split(" ", maxsplit=1)[1]) + self._process_formatted_text(line.split(" ", maxsplit=1)[1]) - def start_lists(self, tag: str, level: int) -> None: + def _start_lists(self, tag: str, level: int) -> None: """Start (possibly nested) lists until the required level is reached.""" while len(self.current_list_tags) < level: self.current_list_tags.append(tag) self.list_counter.append(0) self.builder.start(tag, {xmltags.LIST_LEVEL: str(len(self.current_list_tags))}) - def end_lists(self, level: int = 0) -> None: + def _end_lists(self, level: int = 0) -> None: """End (possibly nested) lists until the required level is reached.""" while len(self.current_list_tags) > level: self.list_counter.pop() self.builder.end(self.current_list_tags.pop()) - def process_table_row(self, line: str) -> None: + def _process_table_row(self, line: str) -> None: """Process table row.""" cells = Table.get_table_cells(line) if self.table is None: @@ -211,7 +218,7 @@ def process_table_row(self, line: str) -> None: else: self.table.process_table_cells(cells) - def end_table(self) -> None: + def _end_table(self) -> None: """Flush the table.""" def table_row(tag: str, cells, row_index: int) -> None: @@ -227,7 +234,7 @@ def table_row(tag: str, cells, row_index: int) -> None: xmltags.TABLE_CELL_WIDTH: str(width), } with self.element(xmltags.TABLE_CELL, attributes): - self.process_formatted_text(cell) + self._process_formatted_text(cell) if self.table is None: return @@ -241,7 +248,7 @@ def table_row(tag: str, cells, row_index: int) -> None: table_row(xmltags.TABLE_ROW, row, row_index + 1) self.table = None - def process_formatted_text(self, line: str) -> None: + def _process_formatted_text(self, line: str) -> None: """Process formatted Markdown text.""" seen = "" formats = [ @@ -257,36 +264,37 @@ def process_formatted_text(self, line: str) -> None: for md_start, md_end, xml_tag in formats: if line.startswith(md_start) and md_end in line[len(md_start) :]: format_found = True - self.flush(seen) + self._flush(seen) seen = "" with self.element(xml_tag): if xml_tag == xmltags.INSTRUCTION: self.builder.data(md_start) formatted_text, line = line[len(md_start) :].split(md_end, maxsplit=1) - self.process_formatted_text(formatted_text) + self._process_formatted_text(formatted_text) if xml_tag == xmltags.INSTRUCTION: self.builder.data(md_end) break else: if match := re.match(markdown_syntax.LINK_PATTERN, line): format_found = True - self.flush(seen) + self._flush(seen) seen = "" match = cast(re.Match, match) with self.element(xmltags.ANCHOR, {xmltags.ANCHOR_LINK: match.group(2)}): - self.process_formatted_text(match.group(1)) + self._process_formatted_text(match.group(1)) line = line[len(match.group(0)) :] elif match := re.match(markdown_syntax.IMAGE_PATTERN, line): format_found = True - self.flush(seen) + self._flush(seen) seen = "" match = cast(re.Match, match) - self.add_element( + self._add_element( xmltags.IMAGE, attributes={ xmltags.IMAGE_ALT: match.group(1), xmltags.IMAGE_SRC: match.group(2), xmltags.IMAGE_TITLE: match.group(3), + xmltags.IMAGE_WIDTH: "15", }, ) line = line[len(match.group(0)) :] @@ -294,19 +302,19 @@ def process_formatted_text(self, line: str) -> None: if not format_found: seen += line[0] if line else "" line = line[1:] - self.flush(seen) + self._flush(seen) - def end_document(self) -> None: + def _end_document(self) -> None: """End the document.""" - self.end_lists() - self.end_table() - self.end_sections() + self._end_lists() + self._end_table() + self._end_sections() self.builder.end(xmltags.DOCUMENT) - def add_element(self, tag: str, text: str = "", attributes: TreeBuilderAttributes | None = None) -> None: + def _add_element(self, tag: str, text: str = "", attributes: TreeBuilderAttributes | None = None) -> None: """Add an element with text.""" with self.element(tag, attributes): - self.flush(text) + self._flush(text) @contextlib.contextmanager def element(self, tag: str, attributes: TreeBuilderAttributes | None = None): @@ -317,7 +325,7 @@ def element(self, tag: str, attributes: TreeBuilderAttributes | None = None): finally: self.builder.end(tag) - def flush(self, text: str) -> None: + def _flush(self, text: str) -> None: """Flush the text.""" if text: self.builder.data(text) diff --git a/src/pdfmark.txt b/src/pdfmark.txt deleted file mode 100644 index 3d964103..00000000 --- a/src/pdfmark.txt +++ /dev/null @@ -1 +0,0 @@ -[{Catalog} <> /PUT pdfmark diff --git a/src/xmltags.py b/src/xmltags.py index 571a6f94..524d89e7 100644 --- a/src/xmltags.py +++ b/src/xmltags.py @@ -15,6 +15,7 @@ IMAGE_ALT = "alt" IMAGE_SRC = "src" IMAGE_TITLE = "title" +IMAGE_WIDTH = "width" # Image width in centimeters ITALIC = "i" INSTRUCTION = "instruction" LIST_ITEM = "item" diff --git a/tests/test_markdown_converter.py b/tests/test_markdown_converter.py index 76df2329..a5d2f93d 100644 --- a/tests/test_markdown_converter.py +++ b/tests/test_markdown_converter.py @@ -30,7 +30,7 @@ def setUp(self): def xml(self): """Create the XML.""" - return MarkdownConverter(Variables(dict(var="variable"))).convert(self.settings) + return MarkdownConverter(Variables({"var": "variable"})).convert(self.settings) @patch("markdown_converter.open", mock_open(read_data="")) diff --git a/thirdparty/fonts/muli/Muli-Bold.ttf b/thirdparty/fonts/muli/Muli-Bold.ttf deleted file mode 100644 index a1d70c4e..00000000 Binary files a/thirdparty/fonts/muli/Muli-Bold.ttf and /dev/null differ diff --git a/thirdparty/fonts/muli/Muli-BoldItalic.ttf b/thirdparty/fonts/muli/Muli-BoldItalic.ttf deleted file mode 100644 index 4c50ab08..00000000 Binary files a/thirdparty/fonts/muli/Muli-BoldItalic.ttf and /dev/null differ diff --git a/thirdparty/fonts/muli/Muli-ExtraLight.ttf b/thirdparty/fonts/muli/Muli-ExtraLight.ttf deleted file mode 100644 index ad12000b..00000000 Binary files a/thirdparty/fonts/muli/Muli-ExtraLight.ttf and /dev/null differ diff --git a/thirdparty/fonts/muli/Muli-ExtraLightItalic.ttf b/thirdparty/fonts/muli/Muli-ExtraLightItalic.ttf deleted file mode 100644 index dde2cd10..00000000 Binary files a/thirdparty/fonts/muli/Muli-ExtraLightItalic.ttf and /dev/null differ diff --git a/thirdparty/fonts/muli/Muli-Italic.ttf b/thirdparty/fonts/muli/Muli-Italic.ttf deleted file mode 100644 index 824ee712..00000000 Binary files a/thirdparty/fonts/muli/Muli-Italic.ttf and /dev/null differ diff --git a/thirdparty/fonts/muli/Muli-Light.ttf b/thirdparty/fonts/muli/Muli-Light.ttf deleted file mode 100644 index 0ffcfba2..00000000 Binary files a/thirdparty/fonts/muli/Muli-Light.ttf and /dev/null differ diff --git a/thirdparty/fonts/muli/Muli-LightItalic.ttf b/thirdparty/fonts/muli/Muli-LightItalic.ttf deleted file mode 100644 index e8b3c3ac..00000000 Binary files a/thirdparty/fonts/muli/Muli-LightItalic.ttf and /dev/null differ diff --git a/thirdparty/fonts/muli/Muli-Semi-BoldItalic.ttf b/thirdparty/fonts/muli/Muli-Semi-BoldItalic.ttf deleted file mode 100644 index 3ea891d5..00000000 Binary files a/thirdparty/fonts/muli/Muli-Semi-BoldItalic.ttf and /dev/null differ diff --git a/thirdparty/fonts/muli/Muli-SemiBold.ttf b/thirdparty/fonts/muli/Muli-SemiBold.ttf deleted file mode 100644 index dc27bcbe..00000000 Binary files a/thirdparty/fonts/muli/Muli-SemiBold.ttf and /dev/null differ diff --git a/thirdparty/fonts/muli/Muli.ttf b/thirdparty/fonts/muli/Muli.ttf deleted file mode 100644 index 01313e90..00000000 Binary files a/thirdparty/fonts/muli/Muli.ttf and /dev/null differ diff --git a/thirdparty/fonts/muli/SIL Open Font License.txt b/thirdparty/fonts/muli/SIL Open Font License.txt deleted file mode 100644 index b91810c1..00000000 --- a/thirdparty/fonts/muli/SIL Open Font License.txt +++ /dev/null @@ -1,44 +0,0 @@ -Copyright (c) 2011 by vernon adams (vern@newtypography.co.uk), -with Reserved Font Name "Muli". - -This Font Software is licensed under the SIL Open Font License, Version 1.1. -This license is copied below, and is also available with a FAQ at: http://scripts.sil.org/OFL - ------------------------------------------------------------ -SIL OPEN FONT LICENSE Version 1.1 - 26 February 2007 ------------------------------------------------------------ - -PREAMBLE -The goals of the Open Font License (OFL) are to stimulate worldwide development of collaborative font projects, to support the font creation efforts of academic and linguistic communities, and to provide a free and open framework in which fonts may be shared and improved in partnership with others. - -The OFL allows the licensed fonts to be used, studied, modified and redistributed freely as long as they are not sold by themselves. The fonts, including any derivative works, can be bundled, embedded, redistributed and/or sold with any software provided that any reserved names are not used by derivative works. The fonts and derivatives, however, cannot be released under any other type of license. The requirement for fonts to remain under this license does not apply to any document created using the fonts or their derivatives. - -DEFINITIONS -"Font Software" refers to the set of files released by the Copyright Holder(s) under this license and clearly marked as such. This may include source files, build scripts and documentation. - -"Reserved Font Name" refers to any names specified as such after the copyright statement(s). - -"Original Version" refers to the collection of Font Software components as distributed by the Copyright Holder(s). - -"Modified Version" refers to any derivative made by adding to, deleting, or substituting -- in part or in whole -- any of the components of the Original Version, by changing formats or by porting the Font Software to a new environment. - -"Author" refers to any designer, engineer, programmer, technical writer or other person who contributed to the Font Software. - -PERMISSION & CONDITIONS -Permission is hereby granted, free of charge, to any person obtaining a copy of the Font Software, to use, study, copy, merge, embed, modify, redistribute, and sell modified and unmodified copies of the Font Software, subject to the following conditions: - -1) Neither the Font Software nor any of its individual components, in Original or Modified Versions, may be sold by itself. - -2) Original or Modified Versions of the Font Software may be bundled, redistributed and/or sold with any software, provided that each copy contains the above copyright notice and this license. These can be included either as stand-alone text files, human-readable headers or in the appropriate machine-readable metadata fields within text or binary files as long as those fields can be easily viewed by the user. - -3) No Modified Version of the Font Software may use the Reserved Font Name(s) unless explicit written permission is granted by the corresponding Copyright Holder. This restriction only applies to the primary font name as presented to the users. - -4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font Software shall not be used to promote, endorse or advertise any Modified Version, except to acknowledge the contribution(s) of the Copyright Holder(s) and the Author(s) or with their explicit written permission. - -5) The Font Software, modified or unmodified, in part or in whole, must be distributed entirely under this license, and must not be distributed under any other license. The requirement for fonts to remain under this license does not apply to any document created using the Font Software. - -TERMINATION -This license becomes null and void if any of the above conditions are not met. - -DISCLAIMER -THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM OTHER DEALINGS IN THE FONT SOFTWARE. \ No newline at end of file