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:
| ||||||||||
Inleiding
Het belang en de risico’s die de organisatie aan het bedrijfsproces 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.
Wij willen u erop attenderen dat in dit document de termen applicatie en informatiesysteem worden gehanteerd. De ISO spreekt over informatiesystemen, dit thema betreft applicaties, wat een onderdeel is van een informatiesysteem. Bij de controls hanteren we informatiesysteem om bij de tekst van de ISO te blijven.
Context Applicatieontwikkeling
Dit document bevat de uitwerking van het thema ‘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 afbeelding 'Overzicht van type applicaties'). 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 zal voldaan moeten zijn aan zowel functionele als beveiligingseisen. Ook moeten bij de ontwikkeling het informatiebeveiligingsbeleid, wet en regelgeving (o.a. AVG, BIO) en eisen ten aanzien van de technische omgeving worden betrokken.
In dit thema zullen de beveiligingseisen ten aanzien van applicatieontwikkeling worden samengesteld. Het uitgangspunt hierbij is de noodzakelijke beveiligingseisen, in de vorm van controls en onderliggende maatregelen, uit de BIO en ISO27002 (2013) in een samenhangende context te plaatsen en waar nodig deze aan te vullen met controls uit andere ISO standaarden, NIST of Standard of Good practice.
Alvorens de controls, die gerelateerd zijn aan objecten, te identificeren, wordt eerst een algemene ontwikkelcyclus beschreven om een beter beeld te krijgen over de te hanteren stadia. Deze exercitie is zinvol om de geïdentificeerde objecten uit ISO/BIO en overige standaarden beter contextueel in samenhang te plaatsen. De beschrijving van de stadia vindt plaats in § 1.4 ‘Ontwikkelcyclus van applicaties’.
Doel van het thema Applicatieontwikkeling
Dit thema is opgesteld om zowel de interne als de externe leverancier over een instrument te laten beschikken gericht op de implementatie van applicaties in de technische omgeving van de leverancier of van de klant zelf.
Het thema 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 van Applicatieontwikkeling
In dit thema zullen we ons voornamelijk richten op conditionele, beveiligings- en beheersingsaspecten die gerelateerd zijn aan het ontwikkelen van applicaties. We beperken ons binnen dit thema tot het inhouse ontwikkelen van applicaties en waarbij geen aandacht wordt besteed aan:
- de activiteiten die gerelateerd zijn aan onderhoud van applicaties, webapplicatie en ERP pakketten (zie afbeelding 'Overzicht van type applicaties');
- het type gebruikers- en business eisen omdat deze eisen organisatieafhankelijk zijn;
- de toegangsbeveiligingsaspecten omdat deze aspecten in het thema ‘Toegangsbeveiliging’ en in de SIG ISO25010 geadresseerd zijn.
Ontwikkelcyclus van applicatieontwikkeling
Een applicatie (software) wordt ontwikkeld om een (bedrijfs)proces te ondersteunen. Hiervoor dient eerst een context analyse 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). Dit PvE wordt ontwikkeld in samenwerking met informatie analisten, softwareontwikkelaars en -gebruikers.
De kwaliteit (succes) van een applicatie wordt o.a. bepaald door:
- hoe goed de applicatie het vastgestelde programma van eisen weerspiegelt;
- hoe goed het programma van eisen de gebruikerseisen en wensen weerspiegelt;
- hoe goed de gebruikerseisen en wensen de reële situatie (daadwerkelijke noodzakelijkheden) weerspiegelt.
Slechte kwaliteit van het PvE wordt o.a. veroorzaakt door onjuistheden, verkeerde aannames, inconsistenties, onduidelijk taalgebruik en ontoereikendheid. Bij applicatieontwikkeling is een goede inrichting van projectmanagement en de te hanteren systeem ontwikkelmethode (Systeem Development Life cycle) essentieel.
Het applicatieontwikkeling proces wordt verdeeld in activiteiten die niet noodzakelijk als sequentiële stappen doorlopen worden (zie ook §1.5 ‘Ontwikkelmethoden’). De onderkende activiteiten zijn:
- analyseren;
- specificeren;
- ontwerpen;
- ontwikkelen;
- valideren(testen);
- gebruik en beheer.
Opmerking: Bij agile worden in ieder geval 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.
Afbeelding 'De ontwikkelactiviteiten van software en indeling van essentiële elementen in drie domeinen' geeft een schematische weergave van een ontwikkelproces in de vorm van het V-Model. De activiteiten zullen hieronder worden toegelicht. Ze verschaffen mogelijkheden om de geïdentificeerde operationele objecten uit BIO, ISO27001/2 en overige standaarden te rubriceren.
Hiernaast spelen ook essentiële randvoorwaardelijke- en beheersingselementen een rol bij de ontwikkel- en onderhoudsactiviteiten. De operationele-, randvoorwaardelijke- en beheersingselementen voor het thema Applicatieontwikkeling kunnen ingedeeld worden in drie domeinen: Beleid, Uitvoering en Control. Deze indeling wordt eveneens afgebeeld in afbeelding 'De ontwikkelactiviteiten van software en indeling van essentiële elementen in drie domeinen'.
Perspectieven De linkerkant van het model beschrijft het ontwikkelperspectief en de rechterkant het gebruikersperspectief. Als de applicatieontwikkeling plaatsvindt bij een externe organisatie of een aparte businessunit zijn deze perspectieven gescheiden. Ingeval van uitbesteding wordt, afhankelijk van de afspraken tussen de klant en de leverancier, de rechterkant aangeduid als het leveranciersperspectief en de linkerkant als het klantperspectief. Hierover dienen klant en leverancier heldere afspraken te maken. Afspraken dienen gericht te zijn 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 lifecycle stadia 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.
Analyseren In deze fase wordt de context van het businessproces, 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 ten aanzien van 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 In deze fase worden de softwarecomponenten geconstrueerd (gecodeerd). De relaties en afhankelijkheden van de te automatiseren processen en modules worden vastgelegd in een softwarearchitectuur. Uiteindelijk zullen de programma’s geschreven worden op basis van deze (applicatie/software) architectuur. Hierbij moet ook rekening worden gehouden met enkele ontwikkeleisen, zoals:
- reproduceerbaarheid van code;
- effectief testbaarheid;
- toepassing van externe programma bibliotheek;
- toepassing tools en gebruik van licenties;
- toepassing van gestandaardiseerde vocabulaire (ISO25010);
- inzicht in relaties en afhankelijkheden tussen softwareobjecten;
- softwarefeatures (eisen: interfaces, koppelingen, API’s);
- richten op aantoonbaar veilig programmeren (Secure Software Design).
Valideren In deze fase worden de ontwikkelde modules/programma’s getest en uiteindelijk geaccepteerd. Gecontroleerd wordt of de software volgens de ontwerprichtlijnen is gebouwd. In deze fase kunnen ook fouten boven water komen die al in eerdere stadia gemaakt zijn. In deze fase wordt aandacht besteed aan bepaalde eisen, zoals:
- de applicatie biedt slechts die functionaliteit die in de specificaties/ontwerp zijn opgenomen. (m.a.w.: geen functionaliteit buiten specificaties/ontwerp);
- conformiteit aan de gespecificeerde functionaliteit (gebruikers)/ontwerp (Security by Design), AVG).
Gebruiken Als de software voltooid en getest is zal het in gebruik genomen moeten worden volgens een standaardprocedure van de ‘OTAP-straat’.
Onderhoud/Beheer Tenslotte dient de software periodiek op basis van nieuwe functionele eisen en of voorkomende fouten te worden onderhouden en (weer) in beheer te worden genomen.
Ontwikkelmethoden
Er zijn verschillende modellen voor het ontwikkelen van applicaties, zoals: lineair, iteratief en Agile.
- 'Lineaire methode'
Het meest bekend voorbeeld is de watervalmethode (zie §1.4). In deze lineaire ontwikkelmethode wordt het eindproduct (softwareproduct) in een aantal fases opgeleverd. In elke fase wordt een concreet gedefinieerd deelproduct vervaardigd. Requirements moeten duidelijk zijn en vooraf zijn vastgelegd. Kennisoverdracht en monitoring vinden plaats op basis van specifieke documenten en formats.
- 'Iteratieve ontwikkelmethode'
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 iteratieve- en lineaire ontwikkelmethoden met elkaar gecombineerd.
- 'Agile methode'
Een 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 product features 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. Prioriteit wordt gegeven aan 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. Afbeelding 'Schematische weergave van een iteratie/agile ontwikkelproces in de vorm van het V-Model' geeft een schematische weergave van een iteratie/agile ontwikkelproces in de vorm van het V-Model.
Applicatie objecten uit baseline in relatie tot ontwikkelmethode
Bij de selectie van applicatie objecten uit ISO en overige baselines is in eerste instantie uitgegaan van de lineaire-/iteratieve aanpak van applicatieontwikkeling. Mogelijk volgen later een versie 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.