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.
Alle hoofdstukken bij BIO Thema-uitwerking 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, gevoeligheid van de gegevens, belang van de applicatie voor de organisatie bepalen of en welke normen van toepassing zijn.
Context applicatieontwikkeling
Alle pagina's van applicatieontwikkeling bevatten de uitwerking van de BIO Thema-uitwerking Applicatieontwikkeling. 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 onderstaande afbeelding). 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.
In deze BIO Thema-uitwerking zullen de beveiligingseisen voor applicatieontwikkeling worden samengesteld. Het uitgangspunt hierbij is de noodzakelijke beveiligingseisen, in de vorm van controls en onderliggende maatregelen uit de BIO en NEN-EN-ISO/IEC 27002:2017 (in deze thema-uitwerking genoemd ISO 27002), in een samenhangende context te plaatsen en waar nodig deze aan te vullen met controls uit andere ISO-standaarden, National Institute of Standards and Technology (NIST) en de The Standard of Good Practice (SoGP) 2018 e.d.
Eerst wordt een algemene ontwikkelcyclus beschreven om een beter beeld te krijgen over de te hanteren fases voordat de controls die gerelateerd zijn aan objecten worden geïdentificeerd. Deze exercitie is ook zinvol om geïdentificeerde objecten uit de BIO en overige best practices beter contextueel in samenhang te plaatsen. De beschrijving van de fases vindt plaats in Ontwikkelcyclus van applicatieontwikkeling.
Doel applicatieontwikkeling
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 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
In deze BIO Thema-uitwerking wordt voornamelijk gericht op conditionele beveiligings- en beheersingsaspecten die gerelateerd zijn aan het ontwikkelen van applicaties. Geen aandacht wordt besteed aan:
- de activiteiten die gerelateerd zijn aan onderhoud van applicaties, webapplicaties en Enterprise Resource Planning (ERP)-pakketten (zie onderstaande afbeelding);
- de typen gebruikers en bedrijfseisen omdat deze eisen organisatieafhankelijk zijn;
- de toegangsbeveiligingsaspecten omdat deze aspecten in het thema ‘Toegangsbeveiliging’ geadresseerd zijn.
De begrenzing van deze BIO Thema-uitwerking is in onderstaande afbeelding weergegeven.
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 (succes) van een applicatie wordt onder andere bepaald door:
- hoe goed het PvE de gebruikerseisen en -wensen weerspiegelt;
- hoe goed de gebruikerseisen en -wensen de reële situatie (daadwerkelijke noodzakelijkheden) weerspiegelt;
- hoe goed 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 worden1 (zie ook Ontwikkelmethoden). De onderkende activiteiten zijn: analyseren, specificeren, ontwerpen, ontwikkelen, valideren, gebruiken en beheren. Onderstaande afbeelding 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.
Hiernaast 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 in bovenstaande afbeelding weergegeven.
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. Om een goede beheersing te waarborgen, is het vanuit best practices noodzakelijk de verschillende fases 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 de context van 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 tijdens in de eerdere fase gedetailleerde en vastgestelde uitwerking van informatie en modellen plaats. 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 met 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-features (eisen: 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, zoals:
- 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 (gebruikers)/het ontwerp (security by design) en de AVG).
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. Na de totstandkoming van dit thema kan met de definitieve versie een versie worden gemaakt die gerelateerd is aan applicatieonderhoud en een versie die gerelateerd is aan de Agile-methode. Dit zullen aparte documenten zijn die overeenkomsten zullen hebben met dit document, maar vanuit de optiek van onderhoud of Agile-aanpak kunnen objecten aangepast en/of toegevoegd worden.
- ↑ Bij Agile worden in ieder geval het ontwikkelen en een deel van het valideren als één activiteit uitgevoerd. Een deel van het ontwerpen kan daar ook bij horen. Ook wordt het andere deel van valideren en gebruiken wel gelijktijdig gedaan. Hiervoor zijn verschillende modellen bekend.