AQAP 2110 to Sojusznicza Publikacja Zapewnienia Jakości regulująca wymagania dotyczące systemu zarządzania jakością przy projektowaniu, opracowywaniu i produkcji oprogramowania w ramach kontraktów obronnych. Podczas gdy ISO 9001 jest bazowym standardem jakości uznawanym we wszystkich branżach, AQAP 2110 idzie dalej — jest napisany specjalnie dla kontekstu zamówień obronnych, nakładając dodatkowe wymagania odzwierciedlające unikalne potrzeby wojskowych programów oprogramowania: nadzór rządowego zapewnienia jakości (GQA), formalne planowanie tworzenia oprogramowania i rygorystyczne zarządzanie konfiguracją.

Dla dostawcy oprogramowania dążącego do pracy na kontraktach wydawanych przez państwa członkowskie, zrozumienie wymagań AQAP 2110 i tego, jak różni się od ISO 9001 w praktyce, jest niezbędnym przygotowaniem.

Czym jest AQAP 2110 i jak różni się od ISO 9001

AQAP 2110 opiera się na ISO 9001 i zawiera wszystkie jego wymagania. Dostawcy certyfikowani na AQAP 2110 domyślnie spełniają ISO 9001. Jednak AQAP 2110 dodaje warstwę wymagań specyficznych dla obrony, której ISO 9001 nie zawiera.

Najistotniejszym uzupełnieniem jest Rządowe Zapewnienie Jakości (GQA). Zgodnie z AQAP 2110, organ zamawiający zachowuje prawo do prowadzenia audytów nadzoru systemu zarządzania jakością dostawcy podczas realizacji kontraktu. Rządowy przedstawiciel ds. zapewnienia jakości (GQAR) może odwiedzać obiekty dostawcy, przeglądać artefakty wytwarzania, uczestniczyć w testach i weryfikować, czy uzgodnione procesy tworzenia oprogramowania są rzeczywiście przestrzegane.

AQAP 2110 wymaga również od dostawców opracowania Planu Wytwarzania Oprogramowania (SDP) — formalnego dokumentu definiującego sposób zarządzania procesem tworzenia oprogramowania dla konkretnego kontraktu. SDP podlega zatwierdzeniu przez klienta przed rozpoczęciem prac, co daje organowi zamawiającemu wgląd i wpływ na decyzje dotyczące procesu wytwarzania.

Kluczowe wymagania: SDP, SCM, weryfikacja i walidacja, przeglądy

Plan Wytwarzania Oprogramowania (SDP). SDP jest specyficznym dla kontraktu dokumentem planowania, który wiąże ogólne możliwości systemu zarządzania jakością dostawcy z konkretnym programem. Musi on identyfikować elementy oprogramowania objęte zakresem, metodologię wytwarzania, środowiska wytwarzania i testowania, podejście do zarządzania konfiguracją, rejestr ryzyk i strategie ich łagodzenia oraz harmonogram i kamienie milowe dla działań zapewnienia jakości. SDP jest dokumentem żywym — musi być aktualizowany w miarę rozwoju programu, a istotne zmiany wymagają formalnego zatwierdzenia przez klienta.

Zarządzanie konfiguracją oprogramowania (SCM). AQAP 2110 wymaga formalnego systemu SCM zapewniającego pełną identyfikowalność od wymagań przez projekt, implementację i testowanie do dostarczonego oprogramowania. Identyfikacja elementów konfiguracji musi obejmować kod źródłowy, skrypty budowania, zestawy testów, dokumentację i komponenty stron trzecich.

Weryfikacja i walidacja (V&V). AQAP 2110 rozróżnia weryfikację (potwierdzenie, że oprogramowanie poprawnie implementuje swoją specyfikację) i walidację (potwierdzenie, że specyfikacja poprawnie odzwierciedla potrzeby klienta). Obydwie muszą być zaplanowane w SDP i przeprowadzone z udokumentowanymi dowodami. Działania weryfikacyjne obejmują przeglądy kodu, analizę statyczną, testowanie jednostkowe, integracyjne i systemowe.

Formalne przeglądy. Standard wymaga formalnych przeglądów na określonych etapach cyklu życia oprogramowania: Przegląd Wymagań Oprogramowania (SRR), Wstępny Przegląd Projektu (PDR), Krytyczny Przegląd Projektu (CDR) oraz Przegląd Gotowości do Testów (TRR). Każdy przegląd ma zdefiniowane kryteria wejścia, porządek obrad, uczestników i kryteria wyjścia. Klient lub GQAR jest zazwyczaj zapraszany jako obserwator lub uczestnik.

Praktyczny wpływ: Wymaganie SDP to miejsce, gdzie większość dostawców nie docenia wymaganego wysiłku. Zgodny SDP dla nietrywialnego programu liczy zazwyczaj 50–150 stron, obejmuje pełny cykl życia wytwarzania i musi być uzgodniony z klientem przed rozpoczęciem prac. Dostawcy, którzy podchodzą do SDP jako do formalności — przygotowując minimalny dokument zawierający odpowiednie słowa bez odzwierciedlania rzeczywistych praktyk — napotkają trudności podczas audytów GQA.

Jak AQAP 2110 wpływa na procesy SDLC

Praktyczny wpływ AQAP 2110 na procesy tworzenia oprogramowania jest znaczący. Standard nie zakazuje metod zwinnych lub iteracyjnych — wymaga, aby jakakolwiek stosowana metoda była udokumentowana, zaplanowana i konsekwentnie przestrzegana. Dostawcy stosujący metody zwinne muszą udokumentować, w jaki sposób ich praktyki Agile spełniają wymagania AQAP 2110 dotyczące planowania, kontroli konfiguracji i V&V.

Zarządzanie zmianami staje się znacznie bardziej rygorystyczne. Zmiany w bazowych artefaktach projektowych wymagają wniosku o zmianę, analizy wpływu, zatwierdzenia przez właściwy organ (potencjalnie z udziałem klienta) oraz aktualizacji elementów konfiguracji. Dowody testów muszą być utrzymywane jako formalne zapisy.

Proces certyfikacji: NSPA i krajowe organy certyfikacji

Certyfikacja AQAP 2110 dla poszczególnych kontraktów jest zazwyczaj zarządzana inaczej niż certyfikacja ISO 9001. Zamiast jednej globalnej certyfikacji, zgodność AQAP jest generalnie oceniana na poziomie kontraktu, a nadzór GQA jest wykonywany przez organ krajowy kraju zawierającego kontrakt.

Agencja Wsparcia i Zamówień NATO (NSPA) świadczy wsparcie związane z AQAP i może prowadzić GQA w imieniu państw członkowskich dla określonych kategorii kontraktów. Dostawcy dążący do wykazania zgodności z AQAP 2110 zazwyczaj obierają jedną z dwóch ścieżek: zgodność specyficzna dla kontraktu lub certyfikacja przez stronę trzecią. Certyfikacja przez stronę trzecią dostarcza dowodów zdolności, na które można się powoływać w ofertach przed udzieleniem konkretnego kontraktu.