Same dokumenty to za mało. Jak przygotować organizację do audytu AQAP, AS/EN 9100 oraz wymagań defence?

Wiele organizacji nadal przygotowuje się do audytów tak, jakby celem było wyłącznie sprawdzenie kompletności dokumentacji. Tymczasem audyt lub ocena zgodności w projektach defence wygląda inaczej. Same zapisy w procedurach nie wystarczą, jeśli organizacja nie jest w stanie pokazać, w jaki sposób przekłada wymagania na architekturę, implementację, testy, kontrolę zmian, nadzór nad dostawcami i końcową akceptację rozwiązania. Dlatego dobre przygotowanie zaczyna się dużo wcześniej niż w dniu wizyty audytora – na etapie budowania procesów, zarządzania ryzykiem i utrzymywania spójnego łańcucha dowodowego dla całego cyklu życia produktu. To szczególnie ważne w projektach, w których bezpieczeństwo, niezawodność i identyfikowalność decyzji mają bezpośredni wpływ na działanie systemu.

Nie tylko AQAP, czyli od czego zacząć analizę wymagań

W projektach defence nie należy zakładać, że jeden standard automatycznie opisuje cały zakres wymagań. Punktem wyjścia powinna być analiza kilku elementów: zapisów kontraktu, charakteru dostarczanego rozwiązania, sektora zastosowania, udziału oprogramowania, rodzaju przetwarzanych informacji oraz zakresu działalności organizacji. Dopiero zestawienie tych czynników pozwala określić, które normy, regulacje i wymagania kontraktowe będą miały znaczenie w konkretnym projekcie. W zależności od jego specyfiki mogą to być między innymi:

• AQAP 2110,
• AQAP 2310,
• AQAP 2210,
• AS/EN 9100,
• AS/EN 9115,
• Wewnętrzny System Kontroli (WSK),
• koncesja,
• wymagania klienta,
• przepisy dotyczące informacji niejawnych,
• wymagania dotyczące cyberbezpieczeństwa,
• wymagania dotyczące kontroli eksportu i transferu technologii.

Nie każdy projekt będzie wymagał wszystkich tych elementów jednocześnie, dlatego w ramach przygotowań do audytu warto najpierw opracować mapę wymagań, jasno wskazując, które z nich wynikają z kontraktu, regulacji, charakteru dostawy lub profilu działalności organizacji.

AQAP 2110 – system zarządzania jakością w projektach defence

AQAP 2110 odnosi się do systemu zarządzania jakością dostawcy w szeroko pojętych projektach obronnych. Bazuje na wymaganiach normy ISO 9001, ale jej nie zastępuje – rozszerza te wymagania o oczekiwania charakterystyczne dla kontraktów NATO i sektora defence. Oznacza to większy nacisk na kontrolę procesów, kontrolę zmian, zarządzanie ryzykiem i konfiguracją, nadzór nad dostawcami oraz zapisy jakościowe. Szczególne znaczenie ma możliwość wykazania, że organizacja działa zgodnie z wymaganiami kontraktu. Nie wystarczy, że procedury zostały opisane – istotna jest spójność między ich zapisami a rzeczywistym przebiegiem procesu.

W ramach audytu szczególnie ważne są obszary takie jak:

• zarządzanie konfiguracją,
• kontrola zmian,
• nadzór nad wymaganiami,
• zarządzanie ryzykiem,
• nadzór nad dostawcami,
• jednoznaczne przypisanie odpowiedzialności,
• dostępność zapisów jakościowych i dowodów wykonania działań.

AQAP 2310 – wymagania jakościowe dla sektora aviation, space and defence

W przeciwieństwie do AQAP 2110, właściwego dla szeroko rozumianych projektów defence, AQAP 2310 ma bardziej specjalistyczny charakter. Jest stosowany przede wszystkim w projektach z obszaru lotnictwa, przestrzeni kosmicznej i obronności, w których punktem odniesienia dla systemu jakości jest branżowy standard AS/EN 9100.

W takim środowisku szczególne znaczenie mają:

• bezpieczeństwo produktu,
• zarządzanie konfiguracją,
• nadzór nad cyklem życia wyrobu,
• kontrola dostawców,
• identyfikowalność,
• zarządzanie zmianą,
• formalne dowody spełnienia wymagań jakościowych.

AQAP 2210 – wymagania dla oprogramowania jako nakładka

AQAP 2210 nie powinien być traktowany jako samodzielny system zarządzania jakością. Jest „nakładką” na AQAP 2110 albo AQAP 2310, gdy istotnym elementem dostawy jest oprogramowanie.

Oznacza to, że organizacja najpierw musi posiadać bazowy system zarządzania jakością, a AQAP 2210 doprecyzowuje oczekiwania dotyczące procesu rozwoju oprogramowania, analizy krytyczności, zarządzania wymaganiami, projektowania, implementacji, weryfikacji i walidacji (V&V), zarządzania konfiguracją oraz dowodów jakościowych dla oprogramowania.

Analiza krytyczności funkcji i komponentów oprogramowania stanowi jeden z najważniejszych elementów AQAP 2210. Pozwala ona dopasować poziom rygoru do skutków potencjalnej awarii oraz określić zakres testów, poziom niezależnej weryfikacji i walidacji, wymagany poziom dokumentacji, rygor kontroli zmian oraz zakres dowodów jakościowych.

Więcej informacji na ten temat znajdziesz w e-booku „Analiza krytyczności oprogramowania zgodnie z AQAP 2210 w sektorze lotniczo-kosmicznym, obronnym i w systemach wbudowanych”

AS/EN 9100 i AS/EN 9115 – ważny kontekst dla sektora aerospace and defence

W projektach związanych z oprogramowaniem realizowanych dla sektora lotniczego, kosmicznego i obronnego AQAP 2210 nie zawsze jest jedynym punktem odniesienia. W zależności od kontraktu i charakteru projektu równie istotne mogą być wymagania wynikające z AS/EN 9100 oraz, gdy oprogramowanie stanowi przedmiot dostawy lub jego istotny element, z AS/EN 9115. Standard ten uzupełnia AS/EN 9100 w zakresie oprogramowania stanowiącego przedmiot dostawy i doprecyzowuje wymagania jakościowe dotyczące organizacji projektujących, rozwijających lub dostarczających oprogramowanie dla sektora aviation, space and defence.

WSK i koncesja – wymagania poza systemem jakości

W niektórych projektach defence sama zgodność z AQAP lub AS/EN 9100 może nie wystarczyć. Jeżeli działalność organizacji obejmuje obrót uzbrojeniem, technologią, produktami podwójnego zastosowania (dual-use) lub innymi towarami o znaczeniu strategicznym, istotne mogą być również wymagania związane z wewnętrznym systemem kontroli. WSK nie jest odpowiednikiem AQAP ani klasycznego systemu zarządzania jakością – to system organizacyjny służący kontroli obrotu i zarządzaniu ryzykiem związanym z przepływem towarów, technologii, usług lub informacji o znaczeniu strategicznym. W praktyce oznacza to konieczność określenia odpowiedzialności, kontroli dostępu, zasad klasyfikacji transakcji, nadzoru nad transferem technologii oraz sposobu dokumentowania decyzji.

Osobnym wymaganiem może być koncesja, która może stanowić formalny warunek prowadzenia określonej działalności gospodarczej w zakresie wytwarzania lub obrotu wyrobami, technologią, bronią, amunicją albo materiałami o przeznaczeniu wojskowym lub policyjnym.

Podczas przygotowań do projektu defence warto oddzielić wymagania dotyczące systemu jakości od obowiązków związanych z kontrolą obrotu, transferem technologii oraz formalnymi wymaganiami dotyczącymi prowadzonej działalności.

Co naprawdę sprawdza audytor

Audyty AQAP i AS/EN 9100 oraz ocena zgodności w projektach defence nie polegają na mechanicznym przeglądzie procedur i checklist. Zadaniem audytora lub klienta jest ocena, czy organizacja faktycznie kontroluje proces i czy potrafi to wykazać w sposób spójny, oparty na identyfikowalnych dowodach.

Dlatego podczas audytu najczęściej pojawiają się pytania takie jak:

• Czy proces jest jasno zdefiniowany?
• Czy działa w praktyce?
• Czy decyzje są uzasadnione?
• Czy istnieją dowody wykonania działań?
• Czy można prześledzić cały cykl życia wymagań i zmian?
• Czy wymagania kontraktowe zostały przełożone na procesy projektowe?
• Czy organizacja kontroluje dostawców i komponenty zewnętrzne?
• Czy zakres wymagań został właściwie ustalony na początku projektu?

Kluczowe znaczenie ma kompletny łańcuch dowodowy, który powstaje dzięki utrzymywaniu spójności między wymaganiami systemowymi, architekturą, implementacją (w tym kodem), wynikami testów, raportami z weryfikacji i walidacji, historią zmian, przeglądami technicznymi, artefaktami konfiguracji oraz zapisami akceptacji i zatwierdzeń.

Jeżeli organizacja potrafi szybko pokazać logiczne powiązania między wymaganiem, decyzją i wynikiem weryfikacji, audyt przebiega zwykle znacznie sprawniej. Problemy zaczynają się wtedy, gdy proces jest obecny wyłącznie „w wiedzy zespołu”, a nie pozostawia po sobie identyfikowalnych zapisów. Z perspektywy audytora brak dowodu często oznacza brak kontroli nad procesem – nawet wtedy, gdy zespół rzeczywiście wykonał wymaganą pracę.

Przygotowanie do audytu w 90 dni

Dni 1–30: zakres, analiza luk i analiza ryzyka

Przygotowanie do audytu warto rozpocząć od określenia zakresu oceny na podstawie wcześniej przygotowanej mapy wymagań. Na tym etapie trzeba ustalić między innymi:

• które wymagania zostały przywołane w kontrakcie,
• czy zastosowanie ma AQAP 2110, AQAP 2310 lub AQAP 2210,
• czy zastosowanie ma AS/EN 9100 lub AS/EN 9115,
• czy organizacja musi spełnić wymagania WSK lub posiadać koncesję,
• które procesy podlegają ocenie,
• kto jest właścicielem konkretnych procesów i obszarów,
• jakie artefakty i dowody już istnieją,
• gdzie występują luki proceduralne lub dokumentacyjne,
• które obszary są najbardziej ryzykowne z perspektywy audytu.

To również moment na ocenę krytyczności funkcji i komponentów oprogramowania oraz weryfikację, czy poziom rygoru rzeczywiście odpowiada poziomowi ryzyka.

Dobrze wykonana analiza luk pozwala zawczasu uzupełnić braki i uniknąć sytuacji, w której potencjalne problemy wychodzą na jaw tuż przed audytem.

Dni 31–60: identyfikowalność, dostawcy i łańcuch dowodowy

Kolejny etap obejmuje uporządkowanie identyfikowalności procesu rozwoju oprogramowania oraz kontroli jakości w całym łańcuchu dostaw. To zwykle najbardziej pracochłonna część przygotowań, ponieważ wymaga połączenia wielu rozproszonych artefaktów i decyzji projektowych oraz uporządkowania ich w jeden spójny proces.

Organizacja powinna być w stanie wykazać:

• powiązania między wymaganiami, implementacją i testami,
• historię zmian i decyzji projektowych,
• sposób nadzoru nad dostawcami i komponentami zewnętrznymi,
• dostępność dowodów jakościowych i zapisów V&V,
• sposób kontroli komponentów off-the-shelf,
• sposób zarządzania ryzykiem i krytycznością oprogramowania,
• zgodność działań z wymaganiami kontraktowymi.

W zakresie identyfikowalności organizacja musi być w stanie jasno wskazać, kto podjął konkretną decyzję, kiedy została ona zatwierdzona, jaki miała wpływ na system i jakie działania weryfikacyjne wykonano po zmianie.

W obszarze współpracy z dostawcami istotne dla audytora zagadnienia to sposób kwalifikowania dostawców, ścieżka przekazywania wymagań jakościowych, procesy kontroli zgodności dostarczanych komponentów oraz działania podejmowane w przypadku niezgodności.

Natomiast analizując łańcuch dowodowy, audytor powinien móc odtworzyć pełną ścieżkę: od wymagania, przez decyzję projektową, implementację, test, wynik testu i zatwierdzenie, aż po kontrolę zmiany.

Dni 61–90: audyt próbny i przygotowanie zespołu

Ostatni etap powinien obejmować audyt próbny oraz przygotowanie organizacji do rozmów z audytorem lub klientem. Warto zweryfikować, czy dowody są łatwo dostępne, czy właściciele obszarów znają swoje zakresy odpowiedzialności oraz czy proces jest opisywany spójnie przez różne osoby.

Audyt w dużej mierze opiera się na rozmowie i analizie konkretnych przykładów działania procesów, dlatego dobrą praktyką jest przeprowadzenie symulacji rozmów audytowych. Pozwala to wcześniej wykryć miejsca, w których proces funkcjonuje poprawnie, ale nie został odpowiednio udokumentowany albo nie jest jednakowo rozumiany przez zespół.

Audytor nie oczekuje wyuczonych odpowiedzi, ale jasnego i spójnego wyjaśnienia:

• jak działa proces,
• dlaczego został zorganizowany w określony sposób,
• dlaczego podjęto konkretne decyzje projektowe i jakościowe,
• gdzie znajdują się dowody,
• jak organizacja kontroluje ryzyko i zmiany,
• jak wymagania kontraktowe zostały przełożone na działania projektowe.

Dobrze przygotowany zespół potrafi szybko i rzeczowo odpowiedzieć na pytania, nie opierając się wyłącznie na dokumentacji, i swobodnie przechodzi od wymagania do konkretnego artefaktu, decyzji projektowej lub wyniku testu. Dzięki temu audytor może zobaczyć, że realizacja wymagań jakościowych jest naturalnym elementem codziennej pracy zespołu.

Najczęstsze pułapki przed audytem

1. Dokumentacja, która nie odzwierciedla rzeczywistości

Problem pojawia się, gdy organizacja posiada komplet procedur, ale rzeczywisty sposób prowadzenia projektu wygląda inaczej niż opisany proces. Rozbieżności bardzo szybko wychodzą na jaw podczas rozmów z zespołem lub analizy historii zmian i zapisów jakościowych.

2. Brak właściwego określenia zakresu wymagań

Błąd na etapie określania zakresu wymagań może spowodować, że przygotowania będą prowadzone w niewłaściwym kierunku. Przykładowo: organizacja zakłada, że wystarczy przygotować się do AQAP 2110, podczas gdy kontrakt lub charakter projektu wskazuje również na AQAP 2310, AQAP 2210, AS/EN 9100, AS/EN 9115, WSK, koncesję albo inne wymagania klienta.

3. Traktowanie AQAP 2210 jako samodzielnego standardu

AQAP 2210 jest nakładką dotyczącą rozwoju oprogramowania, stosowaną razem z AQAP 2110 albo AQAP 2310. Problem pojawia się wtedy, gdy organizacja traktuje go jako osobny system jakości, zamiast powiązać wymagania dotyczące oprogramowania z bazowym systemem zarządzania jakością (QMS), procesami projektowymi, zarządzaniem konfiguracją, kontrolą zmian i zapisami jakościowymi.

4. Brak spójnej identyfikowalności

Dzieje się tak, gdy nie da się jednoznacznie powiązać wymagania, implementacji, testu i zatwierdzenia zmiany. W praktyce uniemożliwia to wykazanie, że wymagania zostały poprawnie zaimplementowane i zweryfikowane. Brak identyfikowalności szybko prowadzi do utraty kontroli nad procesem.

5. Analiza ryzyka tylko na papierze

Nie powinno dojść do sytuacji, w której analiza krytyczności lub analiza ryzyka została przeprowadzona jedynie formalnie i nie przekłada się na rzeczywiste decyzje projektowe, zakres testów ani poziom kontroli zmian. Audytorzy szybko zauważają brak powiązania między klasyfikacją ryzyka a rzeczywistym poziomem rygoru procesu.

6. Niewłaściwy poziom rygoru

Nie wszystkie funkcje wymagają tego samego poziomu kontroli, dokumentacji i testów. Problem pojawia się wtedy, gdy organizacja stosuje identyczne podejście do elementów o zupełnie różnej krytyczności albo odwrotnie – stosuje zbyt niski poziom weryfikacji dla funkcji wysokiego ryzyka.

7. Brak kontroli nad dostawcami

Problemy jakościowe często pojawiają się poza organizacją – u podwykonawców lub dostawców komponentów zewnętrznych. Szczególnie problematyczne są sytuacje, w których organizacja nie posiada pełnej wiedzy o wersjach używanych komponentów, nie monitoruje zmian po stronie dostawcy, nie dysponuje dowodami odbioru lub akceptacji jakościowej albo nie przekazała podwykonawcy wymagań jakościowych.

8. Brak dowodów mimo wykonanej pracy

Taka sytuacja ma miejsce, gdy zespół wykonał wymagane działania, ale nie pozostawił po nich identyfikowalnych zapisów, raportów lub logów. Z perspektywy audytu brak dowodu często oznacza brak możliwości potwierdzenia kontroli procesu, co może zaważyć na przebiegu całej oceny.

Audyt potwierdza dojrzałość operacyjną

Przygotowanie do audytu AQAP, AS/EN 9100 lub oceny zgodności w projekcie defence rozpoczyna się znacznie wcześniej niż tuż przed wizytą audytora – już podczas projektowania procesów, przypisywania odpowiedzialności oraz budowania identyfikowalności, dzięki czemu dowody jakościowe powstają naturalnie w trakcie realizacji projektu i pozwalają wykazać zgodność z wymaganiami na każdym etapie cyklu życia systemu.

W organizacji działającej w sektorze defence zgodność nie może być osobnym elementem na końcu projektu – powinna stanowić część codziennego zarządzania jakością, ryzykiem, konfiguracją, dostawcami i zmianą. Dzięki temu audyt to nie jedynie sprawdzian dokumentacji, ale potwierdzenie realnej dojrzałości operacyjnej.

Autorami artykułu są specjaliści z grupy Spyrosoft, świadczącej usługi doradztwa i inżynierii oprogramowania m.in. dla branży obronnej, lotniczo-kosmicznej, motoryzacyjnej, robotyki, energii odnawialnej, Przemysłu 4.0 oraz sektora danych geoprzestrzennych. Kompetencje grupy obejmują enterprise i embedded software engineering, AI/ML, rozwiązania chmurowe, cyberbezpieczeństwo, HMI oraz platformy low-code i CRM.

Spyrosoft to polska firma działająca na skalę globalną – posiada 24 lokalizacje w 9 krajach i zatrudnia ponad 2000 specjalistów. Wysoką jakość usług potwierdzają międzynarodowe certyfikaty: AQAP 2110:2016, AS EN 9100:2018, AQAP 2310:2022, AQAP 2210:2022, WSK oraz PN-EN ISO 9001:2015. Firma posiada również koncesję MSWiA na prowadzenie działalności gospodarczej w zakresie usług na rzecz obronności i bezpieczeństwa.

Artykuł sponsorowany przygotowany przez firmę Spyrosoft.