AQAP 2110 is de Allied Quality Assurance Publication die vereisten voor kwaliteitsbeheersystemen regelt voor ontwerp, ontwikkeling en productie van software binnen defensiecontracten. Terwijl ISO 9001 de basisnorm voor kwaliteit is die in alle sectoren wordt erkend, gaat AQAP 2110 verder — het is specifiek geschreven voor de defensieaanbestedingscontext en legt aanvullende vereisten op die de unieke eisen van militaire softwareprogramma's weerspiegelen: toezicht van de Overheidsborging (GQA), formele softwareontwikkelplanning en stringent configuratiebeheer.

Voor een softwarevendor die wil werken aan contracten uitgegeven door lidnaties, is het begrijpen wat AQAP 2110 vereist — en hoe het in de praktijk verschilt van ISO 9001 — essentiële voorbereiding. Dit artikel behandelt de structuur van de norm, de belangrijkste vereisten en het certificeringsproces dat vendors moeten doorlopen.

Wat AQAP 2110 Is en Hoe Het Verschilt van ISO 9001

AQAP 2110 is gebaseerd op ISO 9001 en neemt al zijn vereisten op. Vendors gecertificeerd voor AQAP 2110 voldoen impliciet aan ISO 9001. AQAP 2110 voegt echter een laag defensiespecifieke vereisten toe die ISO 9001 niet bevat.

De meest significante toevoeging is de Overheidsborging (GQA). Onder AQAP 2110 behoudt de contracterende autoriteit (doorgaans een nationaal defensieministerie of aanbestedingsagentschap) het recht om surveillance-audits van het kwaliteitsbeheersysteem van de vendor uit te voeren tijdens contractuitvoering. Een overheids-kwaliteitsborging-vertegenwoordiger (GQAR) kan de locatie van de vendor bezoeken, ontwikkelartefacten bekijken, tests bijwonen en verifiГ«ren dat de gecontracteerde softwareontwikkelingsprocessen daadwerkelijk worden gevolgd. Dit verschilt fundamenteel van ISO 9001, waar de auditrelatie puur is tussen de organisatie en zijn certificerende instelling.

AQAP 2110 vereist ook dat vendors een Softwareontwikkelplan (SDP) produceren — een formeel document dat definieert hoe de vendor het softwareontwikkelproces voor het specifieke contract zal beheren. Het SDP moet het gekozen softwarelevenscyclusmodel, de ontwikkelomgeving, kwaliteitsactiviteiten, configuratiebeheer, risicobeheer en de processen voor verificatie en validatie adresseren. Het SDP is onderworpen aan goedkeuring door de klant voor het ontwikkelen begint.

Een verder onderscheid is de expliciete vereiste voor Softwareconfiguratiebeheer (SCM) dat meer voorschrijvend is dan de algemene configuratiebeheersvereisten van ISO 9001. Onder AQAP 2110 moet configuratiebeheer identificatie van configuratie-items, beheersing van wijzigingen, statustelling en configuratieaudits omvatten.

Sleutelvereisten: SDP, SCM, Verificatie en Validatie, en Reviews

Softwareontwikkelplan (SDP). Het SDP is het contractspecifieke planningsdocument dat de algemene KBS-mogelijkheden van de vendor koppelt aan het specifieke programma. Het moet de softwareonderdelen in bereik identificeren, de te gebruiken ontwikkelingsmethodologie, de ontwikkel- en testomgevingen, de configuratiebeheerbenadering, het risicoregister en mitigatiestrate­gieën, en het schema en de mijlpalen voor kwaliteitsactiviteiten. Het SDP is een levend document — het moet worden bijgewerkt naarmate het programma evolueert en significante wijzigingen vereisen formele goedkeuring van de klant.

Softwareconfiguratiebeheer (SCM). AQAP 2110 vereist een formeel SCM-systeem dat volledige traceerbaarheid biedt van vereisten via ontwerp, implementatie en testen tot geleverde software. Identificatie van configuratie-items moet broncode, buildscripts, testsuites, documentatie en componenten van derden omvatten. Wijzigingsbeheer moet ervoor zorgen dat geen enkele wijziging aan een configuratie-item wordt aangebracht zonder autorisatie, beoordeling en documentatie.

Verificatie en Validatie (V&V). AQAP 2110 maakt onderscheid tussen verificatie (bevestigen dat de software correct zijn specificatie implementeert) en validatie (bevestigen dat de specificatie correct de behoeften van de klant vastlegt). Beide moeten worden gepland in het SDP en uitgevoerd met gedocumenteerd bewijs. Verificatieactiviteiten omvatten codebeoordelingen, statische analyse, unit-testing, integratietesten en systeemtesten.

Formele Reviews. De norm vereist formele reviews op gedefinieerde stadia van de softwarelevenscyclus. Dit omvat doorgaans een Softwarevereistenreview (SRR) aan het einde van vereistendefinitie, een Voorlopig Ontwerpbeoordeling (PDR) en Kritieke Ontwerpbeoordeling (CDR) tijdens ontwerp, en een Testgereedheidsreview (TRR) voor het testen begint. De reviews zijn niet puur intern — de klant (of GQAR) wordt doorgaans uitgenodigd als waarnemer of deelnemer.

Praktische impact: De SDP-vereiste is waar veel vendors de betrokken inspanning onderschatten. Een compliant SDP voor een niet-triviaal programma is doorgaans 50–150 pagina's, adresseert de volledige ontwikkellevenscyclus en moet worden overeengekomen met de klant voor het werk begint. Vendors die het SDP benaderen als een vinkjes-oefening — een minimaal document produceren dat de juiste woorden zegt zonder de werkelijke praktijk weer te geven — zullen waarschijnlijk moeilijkheden ondervinden tijdens GQA-audits.

Hoe AQAP 2110 SDLC-processen BeГЇnvloedt

Het praktische effect van AQAP 2110 op softwareontwikkelprocessen is aanzienlijk. De norm verbiedt agile of iteratieve methoden niet — het vereist dat welke methode ook wordt gebruikt, wordt gedocumenteerd, gepland en consistent gevolgd. Vendors die agile methoden gebruiken, moeten documenteren hoe hun agile praktijken voldoen aan de AQAP 2110-vereisten voor planning, configuratiebeheer en V&V.

Wijzigingsbeheer wordt aanzienlijk rigoreuzer. In commerciГ«le ontwikkeling kan een ontwikkelaar die halverwege een sprint een betere aanpak identificeert dit implementeren met minimale procesoverhead. In een AQAP 2110-context vereisen wijzigingen aan baseline-ontwerpartefacten een wijzigingsverzoek, impactanalyse, goedkeuring van de relevante autoriteit en een update van de getroffen configuratie-items.

Testevidentienvereisten beГЇnvloeden hoe testen wordt uitgevoerd en vastgelegd. Het is niet voldoende te beweren dat tests zijn uitgevoerd; testplannen, testprocedures, testresultaten en anomalierapportages moeten worden bijgehouden als formele dossiers. Defecten gevonden tijdens testen moeten worden bijgehouden, oorzaakanalyseerd, gecorrigeerd en regressiegetest met gedocumenteerd bewijs bij elke stap.

Certificeringsproces: NSPA en Nationale Certificerende Instanties

AQAP 2110-certificering voor individuele contracten wordt doorgaans anders beheerd dan ISO 9001-certificering. In plaats van een enkele globale certificering wordt AQAP-naleving over het algemeen beoordeeld op contractniveau, met GQA-toezicht uitgevoerd door de nationale autoriteit van de contracterende natie.

Het NATO-ondersteunings- en aanbestedingsagentschap (NSPA) biedt AQAP-gerelateerde ondersteuning en kan GQA uitvoeren namens lidnaties voor bepaalde categorieën contracten. Vaker hebben nationale defensieaanbestedingsagentschappen hun eigen kwaliteitsborging-organisaties — Defence Equipment and Support (DE&S) in het VK, de Direction Générale de l'Armement (DGA) in Frankrijk, het Bundesamt für Ausrüstung, Informationstechnik und Nutzung der Bundeswehr (BAAINBw) in Duitsland — die GQA-toezicht uitvoeren op contracten in hun jurisdictie.

Vendors die AQAP 2110-naleving willen demonstreren, volgen doorgaans een van twee paden: contractspecifieke naleving, waarbij de KBS-implementatie wordt beoordeeld als onderdeel van het contractgunningsproces; of derde-partijcertificering, waarbij een geaccrediteerde certificerende instelling het KBS formeel certificeert aan AQAP 2110-vereisten. Derde-partijcertificering biedt bewijs van mogelijkheid dat kan worden geciteerd in offertes voor een specifiek contract is gegund.

De relatie tussen AQAP 2110 en nationale defensiekwaliteitsnormen moet ook worden begrepen. Sommige naties passen AQAP-normen direct toe; anderen hebben nationale equivalenten (de DEFSTAN 05-serie van het VK, bijvoorbeeld) die naar AQAP verwijzen of daarmee overeenkomen.