Geprinte versie: V.1.0.0, uitgebracht op 23-11-2020

Bijsluiter - 4.6 Ontwerpfase - Logica

Deze ‘bijsluiter’ is de gebruikershandleiding behorend bij de Handreiking Duurzaam Toegankelijke Algoritmes. Deze handreiking bestaat uit een overzichtsplaat, een vragenlijst en deze bijsluiter. Alle onderdelen van zowel de overzichtsplaat als de vragenlijst worden in dit document nader toegelicht en waar mogelijk voorzien van praktische voorbeelden.

4.6 Ontwerpfase - Logica

In de ontwerpfase komen er vragen aan bod per component (zie paragraaf 3). Deels zijn die vragen generiek, dus voor elk component hetzelfde, deels zijn ze componentgebonden. In deze subparagraaf worden de vragen toegelicht op het component ‘Logica’.

4.6.1 Wat - Wie is de auteur van de broncode?

De broncode (het programma waar het algoritme draait) kan open source, shared source, privaat of zelf ontwikkeld zijn. Dit heeft invloed op de wijze waarop toegankelijkheid wordt geregeld.

4.6.2 Wat - Heeft de organisatie/afdeling toegang tot de broncode?

Het kan zijn dat de organisatie/afdeling zelf geen toegang heeft tot de broncode, dit kan het geval zijn wanneer het is ontwikkeld door een commerciële partij. Het is hierbij aangeraden om een escrow contract te regelen voor wanneer deze partij stopt met het leveren van de service. Deze overeenkomst wordt gearchiveerd als onderdeel van de documentatie.

4.6.3 Wat - Ontwikkelt de broncode zich of is deze statisch?

Worden nieuwe versies van de broncode ontwikkeld en ingezet? Bij extern ontwikkelde software is het een overweging om de release notes te archiveren, wanneer er geen toegang is tot de broncode. Bij intern ontwikkelde software is de broncode beschikbaar en kan eventuele archivering intern worden georganiseerd. Hierbij kunnen release notes ook worden meegenomen.

Release notes zijn overzichtelijker en sneller te scannen/begrijpen dan broncode. In het licht van uitlegbaarheid is het archiveren van release notes een goed idee. 

4.6.4 Wat - Is het datamodel statisch of dynamisch?

Wordt het datamodel verder ontwikkeld of is dit een eenmalig proces. Wanneer deze dynamisch is, met welke interval wordt deze gearchiveerd? (Elke versie, om de zoveel tijd of na zoveel veranderingen). 

4.6.5 Hoe lang - Welk impactprofiel is van toepassing?

Bij de logica is deze vraag van belang om te bepalen wat de juiste te treffen maatregelen zijn n.a.v. het gebruik van de trainingsdata. Deze afweging kun je maken o.b.v. selectielijst(en). In paragraaf 2 zijn de impactprofielen afzonderlijk beschreven. Het bewaren van de logica is een van de belangrijkste componenten van dit archief.

4.6.6 Hoe lang? Volstaat het om enkel het datamodel langere tijd te bewaren en niet de broncode?

Aan de hand van het datamodel kan herleid worden op basis van welke opgegeven categorieën gegevens (bijvoorbeeld locatiegegevens, persoonsgegevens, procesgegevens) tot een de output is gekomen. Voor verantwoording kan het in sommige gevallen al voldoende zijn om dit te bewaren, zonder de daarop toegepaste rekenregels.

4.6.7 Hoe lang - Als broncode en/of datamodel zich in de loop der tijd ontwikkelen, met welke frequentie wordt er dan een nieuwe versie bewaard?

Hierbij kan gekozen worden om elke versie op te slaan, of om de zoveel tijd/versies bij grote wijzigingen.

4.6.8 Waar - Wordt de logica bij een commerciële partij opgeslagen?

Aansluitend op vraag 4.6.1. wordt de logica op dezelfde plek opgeslagen.

4.6.9 Waar - Wordt de logica intern opgeslagen?

Wanneer deze extern wordt opgeslagen/gebruikt, is het aan te bevelen hier een interne backup van te maken.

4.6.10 Vorm - In welke vorm wordt de logica opgeslagen?

De logica wordt opgeslagen in de oorspronkelijke bestandsvorm, hoe deze kan worden ingelezen door het programma. Hierbij is de voorwaarde dat het bestand ook te openen/lezen is buiten het programma. In elk geval bij een lange bewaartermijn, is het van belang om de logica in een open standaard vast te leggen.

4.6.11 Vorm - In welke vorm wordt de logica beschikbaar gesteld?

De minimale vorm van beschikbaar stellen is de bestanden als download aanbieden. Bij een uitgebreidere vorm kan gedacht worden aan een dashboard. Het is hierbij aan te raden een functionaris aan te wijzen die kennis over dit onderwerp borgt en zo eventuele vragen kan beantwoorden en indien van toepassing ontwikkelpunten kan meenemen (wanneer het algoritme nog in gebruik is).

4.6.12 Beschikbaarstelling - Wie zijn belanghebbenden van de data (primaire en secundaire gebruikers, ook op lange termijn)?

Welke partijen moeten toegang hebben tot de logica, zijn dit alleen interne gebruikers of moet deze ook voor externe beschikbaar zijn.

4.6.13 Beschikbaarstelling - Welk openbaarheidsregime is van toepassing?

Het is van belang om te weten welke eventuele beperkingen op de openbaarheid of de toegang geldend zijn. 

4.6.14 Beheer - Als de broncode zich ontwikkeld: hoe wordt de gedragsmonitoring en het versiebeheer georganiseerd?

Wordt deze geautomatiseerd gearchiveerd of moet deze handmatig worden opgeslagen bij elke versie? In het eerste geval, waar wordt deze opgeslagen? In het tweede geval, wie is hiervoor verantwoordelijk?

4.6.15 Beheer - Als er een dynamisch datamodel wordt gehanteerd: hoe wordt het versiebeheer georganiseerd?

Het kan verstandig zijn een script in te stellen die bij wijziging of om de zoveel tijd een export maakt van het datamodel naar een interne (opslag)locatie.

4.6.16 Beheer - Hoe wordt nieuwe/actuele informatie toegevoegd aan de dataset?

Wie wordt hiervoor verantwoordelijk gesteld?