BIO Thema Applicatieontwikkeling - Inleiding
De wijzigingen betreffen met name de uniformering van objectdefinities en objectnamen in en tussen BIO Thema-uitwerkingen.
Versie 2.1 in PDF-formaat is op de website CIP-overheid/producten gepubliceerd.
| ID: | APO_INL |
|---|---|
| Hoofdstuk normenkader | |
| Status: | Actueel |
- BIO Thema Applicatieontwikkeling - Inleiding
- BIO Thema Applicatieontwikkeling - Beveiligingsobjecten applicatieontwikkeling
- BIO Thema Applicatieontwikkeling - Invalshoeken gekoppeld aan het V-model
- BIO Thema Applicatieontwikkeling - Objecten ingedeeld naar invalshoeken
De BIO Thema-uitwerking Applicatieontwikkeling is opgesteld om overheidsorganisaties een beeld te geven van de meest relevante onderwerpen die een rol spelen bij applicatieontwikkeling. Deze BIO Thema-uitwerking bevat de beveiligingseisen voor applicatieontwikkeling. Deze zijn tot stand gebracht door de toepasselijke controls en onderliggende maatregelen uit de BIO2 en NEN-EN-ISO/IEC 27002:2022 (hierna genoemd ISO 27002), in een samenhangende context te plaatsen en waar nodig aan te vullen met controls en maatregelen uit andere ISO-standaarden, National Institute of Standards and Technology (NIST), The Standard of Good Practice (SoGP) 2018 e.d.
Context applicatieontwikkeling
Het belang en de risico’s die de organisatie aan het bedrijfs- of beheerproces stelt, bepalen inherent de eisen die gesteld moeten worden aan de applicatie(s) die het betreffende proces ondersteunen. De risicobeoordeling van de functionaliteit, de gevoeligheid van de gegevens en het belang van de applicatie voor de organisatie bepalen welke normen van toepassing zijn.
Een applicatie kan worden verworven door interne ontwikkeling, uitbesteding of inkoop van een commercieel product. Dit kan ook door een combinatie van interne ontwikkeling en uitbesteding (zie afbeelding 1). Hierbij kan het voortraject (het specificeren) door de klant zelf worden verricht, terwijl het technische deel (het ontwikkelen) door de externe partij wordt uitgevoerd. Hierbij zullen extra afspraken over de beveiligingsaspecten gemaakt moeten worden.
Gedurende de ontwikkelcyclus van de applicatie moet voldaan worden aan functionele en beveiligingseisen. Ook moeten bij de ontwikkeling het informatiebeveiligingsbeleid, wet- en regelgeving (onder andere de Baseline Informatiebeveiliging Overheid (BIO) en de Algemene Verordening Gegevensbescherming (AVG)) en eisen van de technische omgeving worden betrokken.
Om de voor applicatieontwikkeling relevante objecten en hun controls en maatregelen te kunnen identificeren en goed in context te kunnen plaatsen, is aangesloten bij de fasen van de ontwikkelcyclus. De beschrijving van deze fasen vindt plaats in paragraaf 1.4 Ontwikkelcyclus van applicatieontwikkeling.
Doel van dit document
Deze BIO Thema-uitwerking is opgesteld voor de interne en externe leverancier, als instrument gericht op de implementatie van applicaties in de technische omgeving van de leverancier of van de klant zelf.
De thema-uitwerking geeft hiermee inzicht in de kwaliteitszorg die de leverancier dient toe te passen en in wat de klant kan verwachten bij het opleveren van nieuwe software. Het geeft tegelijkertijd de verplichte activiteiten weer van de klant. Hiernaast kan het als instrument dienen voor het geven van inzicht in het beveiligings- en beheersingsniveau van de ontwikkel- en onderhoudsorganisatie van de leverancier.
Scope en begrenzing applicatieontwikkeling
Deze BIO Thema-uitwerking behelst de conditionele beveiligings- en beheersingsaspecten die gerelateerd zijn aan het ontwikkelen van applicaties. Aan de volgende onderwerpen wordt geen aandacht besteed:
- activiteiten die gerelateerd zijn aan onderhoud van applicaties, webapplicaties en Enterprise Resource Planning (ERP)-pakketten (zie afbeelding 1);
- typen gebruikers en bedrijfseisen (deze zijn namelijk organisatieafhankelijk);
- toegangsbeveiligingsaspecten (deze zijn geadresseerd in de thema-uitwerking ‘Toegangsbeveiliging’).
De begrenzing van dit document is weergegeven in afbeelding 2.
Ontwikkelcyclus applicatieontwikkeling
Een applicatie (software) wordt ontwikkeld om een (bedrijfs)proces effectief te ondersteunen. Hiervoor dient eerst een contextanalyse te worden gemaakt om de juiste functionele vereisten te identificeren. De applicatie moet voldoen aan de behoeften van gebruikers en stakeholders in de vorm van wet- en regelgeving, eisen en requirements, of te wel een programma van eisen (PvE). Het PvE wordt ontwikkeld in samenwerking met informatieanalisten, softwareontwikkelaars en -gebruikers.
De kwaliteit en het succes van een applicatie wordt onder andere bepaald door de mate waarin:
- het PvE de gebruikerseisen en -wensen weerspiegelt;
- de gebruikerseisen en -wensen de reële situatie (daadwerkelijke noodzakelijkheden) weerspiegelen;
- de applicatie het vastgestelde PvE weerspiegelt.
Slechte kwaliteit van het PvE wordt onder andere veroorzaakt door onjuistheden, verkeerde aannames, inconsistenties, taalgebruik en ontoereikendheid. Bij applicatieontwikkeling is een goede inrichting van projectmanagement en de te hanteren systeem-ontwikkelmethode (System Development Life Cycle) essentieel.
Het applicatieontwikkelingsproces wordt verdeeld in activiteiten die niet noodzakelijk als sequentiële stappen doorlopen behoeven te worden (zie ook paragraaf 1.5 Ontwikkelmethoden). De onderkende activiteiten zijn: analyseren, specificeren, ontwerpen, ontwikkelen, valideren, gebruiken en beheren. Afbeelding 3 geeft een schematische weergave van een ontwikkelproces in de vorm van het V-model. De activiteiten uit dit model worden in de volgende paragrafen toegelicht. Ze verschaffen mogelijkheden om de geïdentificeerde operationele objecten uit de BIO en overige best practices te rubriceren.
Naast operationele elementen spelen ook essentiële randvoorwaardelijke en beheersingselementen een rol bij ontwikkel- en onderhoudsactiviteiten. De randvoorwaardelijke, operationele en beheersingselementen voor applicatieontwikkeling zijn daarom ingedeeld in het beleids-, uitvoerings- en control-domein. Ook deze indeling wordt weergegeven in afbeelding 3.
Perspectieven
De linkerkant van het bovenstaande V-model beschrijft het ontwikkelperspectief en de rechterkant het gebruikersperspectief. Als applicatieontwikkeling plaatsvindt bij een externe organisatie of een aparte businessunit zijn deze op perspectieven gescheiden. Afhankelijk van de afspraken tussen de klant en leverancier wordt bij uitbesteding de rechterkant aangeduid als het leveranciersperspectief en de linkerkant als het klantperspectief. Hierover maken de klant en leverancier heldere afspraken. De afspraken zijn gericht op:
- het uitwisselen van kennis, specifiek over de overdracht van proceskennis van de (gebruiks)organisatie naar de ontwikkelorganisatie;
- het tijdens het ontwikkelproces niet verstoren van het primaire proces;
- het toezien op de bescherming van intellectuele eigendommen en van gevoelige informatie.
De verantwoordelijken binnen het ontwikkelproces moeten verantwoording kunnen afleggen over de kwaliteit van het geleverde product. Voor een goede beheersing, is het vanuit best practices noodzakelijk de verschillende fasen van de levenscyclus te isoleren in een eigen omgeving zodat gegarandeerd kan worden dat het primaire proces niet wordt verstoord. Daarbij vindt een expliciete afsluiting van een fase plaats zodat een gecontroleerde overgang mogelijk wordt. Dit concept wordt een OTAP-straat genoemd. OTAP staat voor Ontwikkel, Test, Acceptatie en Productie.
Analyseren
In deze fase wordt het bedrijfsproces, dat door de te ontwikkelen applicatie ondersteund moet worden, geanalyseerd. Hierbij worden de noodzakelijke requirements, waaronder de bedrijfsfuncties, gegevens en veranderwensen vanuit de bedrijfsprocessen geïdentificeerd en vastgelegd. De focus ligt op de ‘waarom’-aspecten. Onder andere de volgende activiteiten worden uitgevoerd:
- onderzoeken en brainstormen over de te ontwikkelen software om duidelijkheid te krijgen wat het doel is van de software;
- analyseren van eisen en wensen van gebruikers, beheerders en partners over functionele en niet-functionele aspecten.
Specificeren
Deze activiteit richt zich op de ‘wat’-aspecten. De business-, gebruikers-, stakeholders- (non)functionele en data-requirements worden gespecificeerd. Ook worden de noodzakelijke business rules en de noodzakelijke beperkingen in de vorm van constraints vastgelegd in een functioneel ontwerp.
Ontwerpen
Bij deze activiteit vindt de uitwerking plaats van de in eerdere fasen verkregen informatie. Deze fase richt zich op de relaties en afhankelijkheden tussen de te bouwen componenten. Hierbij worden de bedrijfs- en procesvereisten gemodelleerd in een ontwerp (architectuur) voor het te bouwen informatie(deel)systeem. Aandacht dient besteed te worden aan de kwaliteitseisen gerelateerd aan gebruikers, functionaliteit en beveiliging.
Ontwikkelen (implementeren)
In deze fase worden de softwarecomponenten geconstrueerd (gecodeerd). De relaties en afhankelijkheden van de te automatiseren processen en modules worden vastgelegd in een software-architectuur. Uiteindelijk zullen de programma’s geschreven worden binnen het kader van deze (applicatie-/software-)architectuur. Hierbij moet ook rekening worden gehouden met enkele ontwikkeleisen, zoals:
- Reproduceerbaarheid van code;
- Effectieve testbaarheid;
- Toepassing van externe programmabibliotheek;
- Toepassing van tools en gebruik van licenties;
- Toepassing van gestandaardiseerde vocabulaire (zie de NEN-ISO/IEC 25010 Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models);
- Inzicht in relaties en afhankelijkheden tussen software-objecten;
- software-functies, waaronder interfaces, koppelingen en Application Programming Interfaces (API’s);
- Richten op aantoonbaar veilig programmeren.
Valideren
In deze fase worden de ontwikkelde modules/programma’s getest en uiteindelijk geaccepteerd. Gecontroleerd wordt of de software volgens de ontwerprichtlijnen is gebouwd. Ook kunnen fouten, gemaakt in eerdere stadia, boven water komen. Er wordt aandacht besteed aan eisen als:
- De applicatie biedt slechts die functionaliteit die in de specificaties/het ontwerp zijn opgenomen (anders gezegd, geen functionaliteit buiten de specificaties/het ontwerp);
- Er is conformiteit aan de gespecificeerde functionaliteit (gebruikerseisen en -wensen), het ontwerp (security by design) en de AVG (privacy by design).
Gebruiken
Als de software voltooid en getest is, zal het in gebruik worden genomen volgens een standaardprocedure van de OTAP-straat.
Onderhouden en beheren
Tenslotte wordt de software periodiek onderhouden en (weer) in beheer genomen. Nieuwe functionele eisen zijn uitgewerkt en/of voorkomende fouten worden hersteld.
Ontwikkelmethoden
Er zijn verschillende modellen voor het ontwikkelen van applicaties, zoals de:
- Lineaire methode, Het meest bekende voorbeeld is de Watervalmethode (zie Ontwikkelcyclus van applicatieontwikkeling). In deze ontwikkelmethode wordt het eindproduct (software-product) in een aantal fases opgeleverd. In elke fase wordt een concreet gedefinieerd deelproduct uitgevoerd. De requirements zijn duidelijk en vooraf vastgelegd. Kennisoverdracht en monitoring vinden plaats met specifieke documenten en formats.
- Iteratieve methode, De iteratieve ontwikkeling is een methode waarbij het eindproduct niet in één keer wordt opgeleverd, maar gefaseerd tot stand komt, waarbij fases herhaaldelijk worden doorlopen. Na elke zogenaamde iteratie wordt het proces geëvalueerd en zo nodig aangepast. In de praktijk worden de iteratieve en lineaire ontwikkelmethode met elkaar gecombineerd.
- Agile-methode, De Agile-methode wordt gekenmerkt door korte, in tijd gelimiteerde sprints. De inhoud van een sprint wordt bij de start ervan bepaald. De gevolgde werkwijze kan (dagelijks) worden aangepast al naar gelang de wensen van de zelfsturende teams. Er wordt gebruik gemaakt van een geordende lijst van productfeatures die gedurende het gehele project wordt bijgewerkt op basis van de behoefte van de klant. Daarmee worden in feite de productspecificaties opgebouwd. De nadruk ligt op samenwerking en mondelinge kennisoverdracht. De prioriteit ligt bij het opleveren van sprints en producten met de op dat moment hoogste toegevoegde waarde. De sprints worden gedaan door zelfsturende teams met multidisciplinaire teamleden en zonder vastgelegde taken, rollen en verantwoordelijkheden. Onderstaande afbeelding geeft een schematische weergave van een iteratie/Agile-ontwikkelproces met het V-model.
Applicatieobjecten in relatie tot ontwikkelmethode
Bij de selectie van applicatieobjecten uit de BIO en overige best practices is in eerste instantie uitgegaan van de lineaire/iteratieve aanpak van applicatieontwikkeling. Ook in de onderhoudsfase en in Agile werkmethoden zijn de in dit document geïdentificeerde objecten, controls en maatregelen relevant. Het borgen van de toepassing ervan in de applicatie is daarin lastiger vanwege het ontbreken van de natuurlijke faseovergangen van de lineaire aanpak. Met name geldt dit bij Agile ontwikkeling.
Ga naar de gebruikerspagina van Gebruiker:GvdB
Contact: +31611307897 (Signal)
9 april 2026 08:46:49
8 mei 2019 08:37:23
9 april 2026 08:46:49
63
Informatief
2 februari 2026
