ISO Forge/Baza wiedzy ISO/AQAP 2210
AQAP 2210

AQAP 2210 - wymagania jakości oprogramowania dla dostawców NATO

13 sierpnia 2026·5 min czytania·Marcin Rabiasz · Pełnomocnik ZSZ

Czym jest AQAP 2210 i czym różni się od AQAP 2110?

AQAP 2210 to suplement do AQAP 2110 (lub AQAP 2310) - nie jest samodzielną normą, tylko dokumentem dokładającym wymagania jakościowe specyficzne dla oprogramowania. Pełna nazwa dokumentu to NATO Supplementary Software Quality Assurance Requirements to AQAP 2110 or AQAP 2310 - i już sam tytuł mówi wszystko o jego roli.

Podstawowa różnica między tymi dwoma dokumentami:

1.AQAP 2110 - reguluje zarządzanie jakością w projektowaniu, rozwoju i produkcji wyrobu jako całości (sprzęt, konstrukcja, proces produkcyjny).
2.AQAP 2210 - dodaje wymagania dla części softwarowej tego samego kontraktu: cyklu życia oprogramowania, weryfikacji kodu, zarządzania wersjami i konfiguracją.

W praktyce dostawca dostaje w kontrakcie oba dokumenty jednocześnie, jeśli dostarczany system zawiera oprogramowanie wbudowane, sterujące lub aplikacyjne istotne dla działania całego wyrobu. AQAP 2210 zastąpił wcześniejszy AQAP 159 (edycja 2) i opiera się na podejściu do cyklu życia oprogramowania zbliżonym do ISO/IEC 12207.

Jeśli szukasz pełnego porównania trzech poziomów AQAP dla oprogramowania i sprzętu, zobacz pełny przewodnik AQAP 2110 vs 2210 vs 2131 - tam wyjaśniamy kiedy stosuje się który dokument.

Project Software Quality Plan (PSQP) - centralny dokument

Centralnym artefaktem AQAP 2210 jest Project Software Quality Plan (PSQP) - plan zarządzania jakością oprogramowania dla konkretnego projektu, a nie ogólna polityka firmy. Dostawca przygotowuje go i przedstawia zamawiającemu, często przed podpisaniem kontraktu lub na wczesnym etapie realizacji.

PSQP standardowo obejmuje:

•Zakres i organizację - kto odpowiada za jakość oprogramowania w projekcie i jakie zasoby (ludzie, narzędzia, środowiska) są przypisane.
•Model cyklu życia - jaki model rozwoju oprogramowania został wybrany (kaskadowy, iteracyjny, przyrostowy) i jak mapują się na niego działania QA.
•Standardy i procedury - jakie wewnętrzne procedury i normy odniesienia będą stosowane przy kodowaniu, testowaniu i dokumentowaniu.
•Punkty przeglądów i audytów - kiedy i przez kogo oprogramowanie będzie weryfikowane w trakcie projektu.
•Zarządzanie ryzykiem projektu softwarowego - ryzyka specyficzne dla oprogramowania, np. zależności od podwykonawców czy komponenty COTS.
•Zarządzanie podwykonawcami - jeśli część oprogramowania jest zlecana dalej, PSQP musi opisywać jak dostawca nadzoruje jakość u poddostawcy.

PSQP nie jest dokumentem jednorazowym - powinien być aktualizowany razem z postępem projektu i realnie odzwierciedlać to, co dzieje się w zespole. Szerszy kontekst dokumentacji jakościowej budowanej dla kontraktów obronnych poza samym PSQP znajdziesz w przewodniku po dokumentacji AQAP 2110 dla dostawców przemysłu obronnego.

Cykl życia oprogramowania

AQAP 2210 rozkłada wymagania na procesy cyklu życia oprogramowania, podzielone na dwie grupy:

ISO Forge
Wygeneruj dokumentację ISO w minuty
3 dokumenty za darmo - bez karty kredytowej
Zacznij za darmo →
•Procesy podstawowe - pozyskanie, dostawa, rozwój (analiza wymagań, projektowanie, kodowanie, testowanie), eksploatacja i utrzymanie.
•Procesy wspierające - dokumentacja, zarządzanie konfiguracją, zapewnienie jakości, weryfikacja, walidacja, wspólne przeglądy, audyty i rozwiązywanie problemów.

Dostawca sam określa w PSQP, jaki model cyklu życia stosuje - dokument nie narzuca jednego podejścia. Podejście zwinne może być dopuszczalne, jeśli działania QA są zmapowane na sprinty i przyrosty. Kluczowa jest identyfikowalność (traceability) - każde wymaganie klienta musi dać się prześledzić przez projekt, kod i przypadki testowe aż po potwierdzenie w wynikach testów.

Weryfikacja i walidacja oprogramowania

AQAP 2210 rozróżnia dwa często mylone pojęcia:

•Weryfikacja - odpowiada na pytanie "czy zbudowaliśmy oprogramowanie zgodnie ze specyfikacją?". Obejmuje przeglądy kodu, analizę statyczną, testy jednostkowe i integracyjne na każdym etapie.
•Walidacja - odpowiada na pytanie "czy zbudowaliśmy oprogramowanie, które rzeczywiście spełnia potrzebę operacyjną użytkownika?". To testy systemowe i akceptacyjne, często z udziałem zamawiającego.

Dla oprogramowania o wyższym znaczeniu dla bezpieczeństwa lub krytyczności misji zamawiający może wymagać niezależnej weryfikacji i walidacji (IV&V) - czyli wykonania tych czynności przez zespół niezależny od dewelopera. Wyniki muszą być udokumentowane i powiązane z macierzą identyfikowalności wymagań.

Zarządzanie konfiguracją oprogramowania

Zarządzanie konfiguracją oprogramowania (Software Configuration Management, SCM) to jeden z najbardziej praktycznych elementów AQAP 2210 - i często najbardziej zaniedbywany przez dostawców, którzy traktują go jak zwykłą kontrolę wersji w Git.

W ujęciu AQAP 2210 SCM obejmuje:

1.Identyfikację elementów konfiguracji - kod źródłowy, dokumentację, dane testowe, środowiska budowania - wszystko musi mieć jednoznaczną wersję.
2.Kontrolę zmian - formalny proces zgłoszenia, oceny i zatwierdzenia każdej zmiany, często przez ciało typu Change Control Board.
3.Zarządzanie baselinami - zamrożone punkty odniesienia (np. wersja przekazywana do testów akceptacyjnych), do których można się odwołać i które można odtworzyć.
4.Zarządzanie wydaniami i budowaniem - powtarzalność procesu budowania konkretnej wersji oprogramowania, nawet po latach.
5.Audyty statusu konfiguracji - okresowa weryfikacja, czy stan faktyczny odpowiada zapisanemu stanowi w dokumentacji.

Ostatni punkt ma szczególne znaczenie w kontraktach obronnych - systemy uzbrojenia i systemy dowodzenia bywają eksploatowane i utrzymywane przez dekady. Bez rzetelnego SCM nikt po latach nie odtworzy dokładnie tej wersji oprogramowania, która działała na danym sprzęcie w danym momencie.

Kiedy potrzebujesz AQAP 2210 i jak się przygotować

AQAP 2210 pojawia się w kontrakcie, gdy zamawiający - np. agencja NATO, MON lub integrator systemu - uzna, że dostarczany wyrób zawiera oprogramowanie na tyle istotne dla działania i bezpieczeństwa systemu, że samego AQAP 2110 nie wystarczy. Ocena PSQP i praktyk SCM często jest elementem audytu Government Quality Assurance Representative (GQAR) lub równoważnej jednostki nadzoru jakości, zanim dostawca zostanie dopuszczony do realizacji kontraktu.

Jeśli Twoja rola ogranicza się do odbioru końcowego gotowego wyrobu bez udziału w rozwoju oprogramowania, AQAP 2210 może być zbędny - warto wtedy sprawdzić, czy nie wystarczy lżejszy AQAP 2131 dla dostawców realizujących wyłącznie odbiór końcowy.

Najczęstszy błąd dostawców to przygotowanie PSQP jako dokumentu "na papier", który nie odzwierciedla realnych praktyk zespołu. Audytor szybko to wyłapie, porównując PSQP z faktycznym repozytorium kodu, historią zmian i zapisami testów.

ISO Forge generuje szkielet Project Software Quality Plan zgodny ze strukturą AQAP 2210 w kilka minut - z gotowymi sekcjami do uzupełnienia dla Twojego konkretnego projektu.

Przygotowujesz dokumentację pod kontrakt obronny z wymaganiem AQAP 2210? Zaloguj się do ISO Forge i wygeneruj Project Software Quality Plan dopasowany do Twojego projektu.

Zobacz generator dokumentacji AQAP 2210 w ISO Forge.

Wygeneruj dokumentację ISO w minuty

Pierwszy dokument za darmo. Bez karty kredytowej.

Zacznij za darmo →

Inne artykuły