AQAP 2210 w projektach IT dla sektora obronnego – wymagania jakościowe dla oprogramowania

W projekcie obronnym jakość oprogramowania nie kończy się na poprawnym działaniu aplikacji w dniu odbioru. Zamawiający potrzebuje kontroli nad wymaganiami, konfiguracją, zmianami, testami, poddostawcami i dowodami potwierdzającymi zgodność produktu z umową. Musi również wiedzieć, jaka wersja została dostarczona, na jakiej podstawie ją zaakceptowano i czy można ją bezpiecznie utrzymywać oraz rozwijać.

AQAP 2210 porządkuje te zagadnienia na poziomie projektu programistycznego. Publikacja określa wymagania NATO dotyczące zapewnienia jakości oprogramowania i jest stosowana jako uzupełnienie AQAP 2110 albo AQAP 2310. Jej znaczenie nie wynika jednak z samego występowania skrótu AQAP. W praktyce decydujące są wymagania konkretnej umowy, zakres dostawy, krytyczność oprogramowania oraz uzgodniony sposób nadzoru i odbioru.

Dla zamawiającego oznacza to, że wybór dostawcy IT powinien obejmować znacznie więcej niż ocenę technologii, dostępności programistów i ceny. Potrzebny jest partner zdolny do kontrolowanego wytwarzania oprogramowania, utrzymywania identyfikowalności oraz przedstawienia wiarygodnych dowodów jakości. Ten artykuł wyjaśnia, jak rozumieć wymagania AQAP 2210 i jak wykorzystać je podczas wyboru dostawcy IT dla sektora obronnego.

NAJWAŻNIEJSZY WNIOSEK: Certyfikat AQAP jest istotnym potwierdzeniem dojrzałości systemu jakości dostawcy. Nie zastępuje jednak analizy wymagań konkretnej umowy ani dowodów jakości powstających podczas realizacji projektu.

1. AQAP 2210 – najważniejsze informacje w skrócie

• AQAP 2210 dotyczy zapewnienia jakości oprogramowania w projektach realizowanych w środowisku obronnym.
• Aktualne wydanie to AQAP 2210, wydanie B, wersja 1, opublikowane w 2022 roku.
• Publikacja jest uzupełnieniem AQAP 2110 albo AQAP 2310 i nie jest projektowana jako całkowicie samodzielny system wymagań.
• Jej zastosowanie w projekcie wynika przede wszystkim z umowy, specyfikacji zamówienia i przywołanych dokumentów jakościowych.
• Obejmuje procesy zarządcze i techniczne, w tym planowanie jakości, analizę krytyczności, wymagania, konfigurację, weryfikację, walidację, testy i nadzór nad poddostawcami.
• Nie narzuca jednego modelu wytwarzania oprogramowania. Może współistnieć z Agile i DevSecOps, jeżeli organizacja zachowuje kontrolę, odpowiedzialność i obiektywne dowody.
• Certyfikat dostawcy nie oznacza automatycznej zgodności każdego produktu lub projektu. Liczą się zakres certyfikacji, wymagania umowy i sposób zastosowania procesów w realizowanym przedsięwzięciu.

2. Czym jest AQAP 2210?

AQAP to skrót od Allied Quality Assurance Publications, czyli sojuszniczych publikacji dotyczących zapewnienia jakości. Dokumenty z rodziny AQAP wspierają wspólne podejście państw NATO do jakości dostaw realizowanych na potrzeby obronności. Ich rolą jest zwiększenie zaufania, że dostawca potrafi dostarczyć wyrób zgodny z wymaganiami kontraktowymi i zapewnić zamawiającemu odpowiednią widoczność procesów wpływających na jakość.

AQAP 2210, wydanie B, wersja 1, zawiera uzupełniające wymagania NATO dotyczące zapewnienia jakości oprogramowania. Publikacja jest zorientowana na projekt i obejmuje zarówno procesy zarządcze, jak i techniczne. Jej celem nie jest wskazanie konkretnej metodyki programistycznej, języka, narzędzia czy architektury. Chodzi o ustanowienie takiego poziomu planowania, kontroli i dowodów, który daje zamawiającemu uzasadnione zaufanie do procesu i produktu.

AQAP 2210 należy stosować razem z AQAP 2110 albo AQAP 2310, zależnie od podstawowego zestawu wymagań przywołanego w kontrakcie. W Polsce aktualne publikacje wykorzystywane w procesach certyfikacji opisują między innymi Polskie Centrum Badań i Certyfikacji oraz Centrum Certyfikacji Jakości Wojskowej Akademii Technicznej. Status AQAP 2210 jako aktywnej publikacji w wydaniu B można również zweryfikować w amerykańskim rejestrze dokumentów standaryzacyjnych ASSIST.

2.1 Wymaganie kontraktowe, a nie powszechnie obowiązująca ustawa

AQAP 2210 nie należy przedstawiać jako aktu prawnego, który automatycznie obowiązuje każdą firmę tworzącą oprogramowanie dla obronności. Zakres wiążących zobowiązań wynika przede wszystkim z kontraktu, specyfikacji, klauzuli jakościowej oraz dokumentów przywołanych przez zamawiającego.

W jednym projekcie AQAP 2210 może obejmować pełny cykl rozwoju nowego systemu. W innym zastosowanie może dotyczyć modyfikacji istniejącego rozwiązania, integracji komponentu albo utrzymania oprogramowania. Wymagania mogą podlegać uzasadnionemu dostosowaniu, jeśli publikacja i zamawiający na to pozwalają. Takie decyzje powinny być jednak jawne, zatwierdzone i udokumentowane. Dostawca nie powinien samodzielnie uznawać niewygodnego wymagania za niestosowalne.

3. AQAP 2110 a AQAP 2210 – jaka jest różnica?

AQAP 2110 i AQAP 2210 są ze sobą powiązane, ale pełnią inne funkcje. Pierwszy dokument ustanawia szerokie wymagania jakościowe dotyczące projektowania, prac rozwojowych i produkcji. Drugi rozwija te wymagania w odniesieniu do oprogramowania i pracy na poziomie konkretnego projektu.

ISO 9001 pozostaje ważną podstawą systemowego zarządzania jakością, ale nie opisuje wszystkich mechanizmów potrzebnych w projekcie obronnym ani szczegółowych wymagań jakościowych dla oprogramowania. Dlatego ocena potencjalnego partnera nie powinna kończyć się na pytaniu o ISO 9001. Należy sprawdzić, czy jego system obejmuje właściwy zakres AQAP i czy organizacja potrafi zastosować go w konkretnym projekcie.

4. Kiedy AQAP 2210 ma zastosowanie w projekcie IT?

Najbardziej wiarygodną odpowiedź daje dokumentacja kontraktowa. Wymóg może zostać wskazany bezpośrednio w umowie, specyfikacji warunków zamówienia, klauzuli jakościowej, planie jakości albo wymaganiach przekazanych głównemu wykonawcy i przenoszonych na poddostawców.

AQAP 2210 może być istotny w projektach obejmujących:

• tworzenie nowego oprogramowania na zamówienie;
• rozwój lub istotną modyfikację istniejącego systemu;
• utrzymanie i pielęgnację oprogramowania;
• integrację oprogramowania ze sprzętem, sensorami, efektorami lub platformami;
• systemy dowodzenia, kierowania i świadomości sytuacyjnej;
• rozwiązania klasy C2, C4ISR i systemy wsparcia bojowego;
• oprogramowanie wbudowane albo komponent będący częścią większego wyrobu;
• wykorzystanie lub modyfikację oprogramowania COTS;
• dostawę komponentu programistycznego przez poddostawcę głównego wykonawcy.

Sam fakt, że w produkcie występuje kod, nie przesądza jednak o identycznym zakresie wymagań. Innej kontroli może wymagać aplikacja wspierająca proces administracyjny, a innej komponent mający wpływ na realizację funkcji krytycznej. Dlatego przed rozpoczęciem prac trzeba zidentyfikować co najmniej zakres dostawy, odpowiedzialność stron, krytyczność oprogramowania, zależności, sposób odbioru i dowody wymagane przez zamawiającego.

4.1 Pytania, które warto zadać przed podpisaniem umowy

• Które publikacje AQAP i ich wydania zostały przywołane?
• Czy wymagania dotyczą całej dostawy, konkretnego komponentu czy wybranych procesów?
• Czy dopuszczono dostosowanie wymagań, a jeśli tak, kto je zatwierdza?
• Jakie prawa nadzoru i dostępu otrzymuje zamawiający lub przedstawiciel rządowego zapewnienia jakości?
• Jakie plany, rejestry, raporty i dowody są wymagane przy przeglądach i odbiorze?
• Które obowiązki muszą zostać przeniesione na poddostawców?
• Jak będzie oceniana krytyczność oprogramowania i jaki wpływ ma ona na rygor prac?

Wczesne wyjaśnienie tych kwestii ogranicza ryzyko kosztownej przebudowy dokumentacji, procesu testowego albo łańcucha dostaw już w trakcie realizacji.

5. Dlaczego AQAP 2210 ma znaczenie dla zamawiającego?

W zwykłym projekcie komercyjnym część niejednoznaczności można rozwiązać negocjacją zakresu lub przesunięciem terminu. W projekcie obronnym konsekwencje błędnej konfiguracji, niepełnego testu lub utraty identyfikowalności mogą być znacznie poważniejsze. System może współpracować ze sprzętem, przetwarzać dane istotne operacyjnie albo działać w środowisku o ograniczonej łączności i podwyższonym zagrożeniu.

AQAP 2210 pomaga zamawiającemu ograniczać między innymi następujące ryzyka:

• dostarczenie funkcjonalności niezgodnej z wymaganiami umowy;
• zmiany wprowadzone bez oceny wpływu i zatwierdzenia;
• brak powiązania pomiędzy wymaganiem, projektem, kodem i wynikiem testu;
• niemożność jednoznacznego wskazania konfiguracji przekazanej do odbioru;
• wykrycie kluczowych błędów dopiero podczas testów akceptacyjnych;
• brak obiektywnych dowodów potwierdzających wykonanie testów;
• niekontrolowane wykorzystanie komponentów zewnętrznych;
• niewystarczający nadzór nad poddostawcą;
• utrata wiedzy potrzebnej do utrzymania i dalszego rozwoju systemu;
• zamknięcie niezgodności bez potwierdzenia skuteczności korekty.

Najważniejszą wartością nie jest więc sama liczba dokumentów. Jest nią przejrzystość: zamawiający może sprawdzić, jak dostawca interpretuje wymagania, jak kontroluje pracę, jakie ryzyko pozostaje otwarte i na jakiej podstawie uznaje produkt za gotowy.

6. Najważniejsze wymagania AQAP 2210 w projekcie programistycznym

AQAP 2210 obejmuje wiele powiązanych procesów. Ich szczegółowe zastosowanie zależy od kontraktu, ale poniższe obszary należą do najważniejszych podczas oceny dostawcy i planowania realizacji.

6.1 Plan jakości oprogramowania projektu

Plan jakości oprogramowania projektu, często określany jako Project Software Quality Plan, powinien pokazywać, w jaki sposób organizacja spełni wymagania jakościowe w konkretnym przedsięwzięciu. Nie jest to ogólna polityka jakości ani dokument przygotowywany dopiero przed audytem.

Dobry plan łączy wymagania kontraktu z realnym sposobem pracy. Określa zakres, role, odpowiedzialności, cykl życia, przeglądy, metody weryfikacji i walidacji, zarządzanie konfiguracją, nadzór nad poddostawcami, metryki oraz wymagane zapisy. Powinien także wskazywać zależności pomiędzy dokumentami i sposób aktualizacji planu po zmianie projektu.

Zamawiający powinien móc na jego podstawie zrozumieć nie tylko, co dostawca deklaruje, ale również kiedy otrzyma dowody, kto podejmie decyzję i jak zostanie obsłużone odstępstwo.

6.2 Analiza krytyczności oprogramowania

Krytyczność pomaga dostosować rygor działań do skutków potencjalnego błędu. Analiza powinna uwzględniać funkcję oprogramowania, jego relację z całym systemem oraz wpływ nieprawidłowego działania na ludzi, misję, sprzęt, informacje i ciągłość operacji.

Wynik analizy może wpływać na niezależność przeglądów, zakres testów, wymagane pokrycie, częstotliwość raportowania, poziom kontroli zmian i sposób postępowania z ryzykiem. Nie chodzi o automatyczne zastosowanie najbardziej kosztownych środków do każdego komponentu. Chodzi o świadomą, udokumentowaną i uzasadnioną decyzję.

6.3 Zarządzanie wymaganiami i identyfikowalność

Wymagania powinny być jednoznaczne, możliwe do zweryfikowania i objęte kontrolą zmian. Dostawca musi rozumieć wymagania systemowe, programistyczne i komponentowe, a także ograniczenia wynikające z architektury, interfejsów, bezpieczeństwa i środowiska działania.

Identyfikowalność pozwala przejść od wymagania do rozwiązania projektowego, implementacji i testu, a następnie wrócić od wyniku testu do podstawy kontraktowej. Może być utrzymywana w macierzy albo dedykowanym narzędziu. Najważniejsze, by była aktualna i pozwalała wykryć wymaganie bez projektu, kod bez uzasadnienia lub test bez powiązania.

W dojrzałym projekcie zmiana wymagania uruchamia ocenę wpływu na architekturę, kod, testy, dokumentację, terminy i poddostawców. Sama aktualizacja pozycji w backlogu nie wystarcza, jeżeli reszta dowodów pozostaje nieaktualna.

6.4 Zarządzanie konfiguracją oprogramowania

Zarządzanie konfiguracją oprogramowania, czyli SCM, ma zapewnić jednoznaczną identyfikację elementów produktu oraz kontrolę nad ich zmianami. Dotyczy to nie tylko kodu źródłowego. Zakres może obejmować wymagania, modele, skrypty, konfiguracje środowisk, biblioteki, dokumentację, dane testowe, narzędzia, artefakty budowania i pakiety instalacyjne.

Zamawiający powinien oczekiwać odpowiedzi na kilka praktycznych pytań:

• Jakie elementy tworzą konkretną wersję produktu?
• Kto zatwierdził zmianę i na jakiej podstawie?
• Czy można odtworzyć build przekazany do testów lub odbioru?
• Jak rejestrowany jest status zmian i niezgodności?
• Czy dostawca kontroluje zależności, biblioteki i wersje narzędzi?
• W jaki sposób zabezpiecza repozytoria i ogranicza dostęp?

Bez tych mechanizmów nawet poprawnie przetestowana funkcja może trafić do niewłaściwego wydania albo zostać nadpisana przez późniejszą zmianę.

6.5 Weryfikacja, walidacja i testowanie

Weryfikacja odpowiada na pytanie, czy produkt został zbudowany zgodnie z określonymi wymaganiami i projektem. Walidacja sprawdza, czy rozwiązanie spełnia potrzeby i zamierzone zastosowanie w docelowym kontekście. W praktyce oba rodzaje działań powinny być zaplanowane, mieć kryteria, właścicieli i zachowane wyniki.

Program testów może obejmować testy jednostkowe, integracyjne, systemowe, wydajnościowe, bezpieczeństwa, odpornościowe i akceptacyjne. Zakres zależy od produktu i umowy. Kluczowe znaczenie mają:

• powiązanie testów z wymaganiami;
• zdefiniowane środowisko i dane testowe;
• wersja badanego produktu;
• kryteria rozpoczęcia i zakończenia testów;
• wynik, odchylenia i dowody wykonania;
• rozdzielenie ról, jeśli wymagana jest niezależność;
• sposób obsługi błędów, retestów i regresji.

Automatyzacja może zwiększyć powtarzalność, ale raport z pipeline’u nie jest sam w sobie pełnym dowodem, jeśli nie wiadomo, czego dotyczył, na jakiej wersji został wykonany i według jakich kryteriów został oceniony.

6.6 Niezgodności i działania korygujące

Dostawca powinien mieć kontrolowany proces rejestrowania, oceny i zamykania niezgodności. Ważne jest odróżnienie doraźnej korekty błędu od działania korygującego eliminującego jego przyczynę.

Rejestr powinien pozwalać ustalić między innymi wpływ problemu, dotknięte wersje, decyzję dotyczącą dalszego postępowania, odpowiedzialność, wynik retestu oraz ewentualną potrzebę poinformowania zamawiającego. Powtarzające się problemy powinny prowadzić do analizy trendu i oceny skuteczności procesu, a nie wyłącznie do kolejnych poprawek kodu.

6.7 Poddostawcy, COTS i komponenty zewnętrzne

Współczesne oprogramowanie korzysta z bibliotek, narzędzi, usług, urządzeń i gotowych komponentów. AQAP 2210 nie pozwala traktować ich jako obszaru poza odpowiedzialnością dostawcy. Organizacja powinna oceniać przydatność komponentu, jego ograniczenia, prawa do użycia, dokumentację, konfigurację i wpływ na wymagania.

W przypadku COTS potrzebne są obiektywne podstawy uznania, że produkt spełni wymaganą funkcję. Jeżeli pełna identyfikowalność nie jest możliwa, ograniczenie powinno zostać rozpoznane, ocenione i odpowiednio zarządzone. Modyfikacja gotowego oprogramowania może dodatkowo zmienić profil ryzyka i odpowiedzialność za utrzymanie.

Podobna zasada dotyczy poddostawców. Główny wykonawca powinien określić wymagania, monitorować wykonanie i zachować dowody nadzoru. Certyfikat poddostawcy może wspierać kwalifikację, ale nie zwalnia z odpowiedzialności za zgodność całej dostawy.

7. Czy Agile i DevSecOps można pogodzić z AQAP 2210?

Tak. AQAP 2210 nie narzuca jednego modelu cyklu życia ani obowiązkowego podejścia kaskadowego. Agile i DevSecOps mogą być stosowane, jeśli organizacja potrafi wykazać kontrolę nad wymaganiami, konfiguracją, testami, odpowiedzialnością i wydaniami.

Najczęstszy błąd polega na utożsamieniu zwinności z brakiem dokumentacji. Dokumentacja w projekcie Agile może być lżejsza, generowana automatycznie i utrzymywana w narzędziach. Nadal musi jednak być wiarygodna, dostępna i zrozumiała dla osób sprawujących nadzór.

Drugim ryzykiem jest nadmierne zaufanie do automatyzacji. Pipeline może wykonać tysiące testów, ale zamawiający potrzebuje także kontekstu: wersji produktu, zakresu testów, kryteriów, odchyleń i zatwierdzenia. DevSecOps wspiera AQAP wtedy, gdy automatyzuje kontrolowany proces, a nie gdy ukrywa brak odpowiedzialności za strumieniem logów.

8. Jakich dokumentów i dowodów może oczekiwać zamawiający?

Ostateczny zestaw dowodów wynika z kontraktu. Nie istnieje jeden segregator właściwy dla każdego projektu. W praktyce zamawiający może oczekiwać materiałów takich jak:

Dowód powinien być wiarygodny, aktualny, powiązany z zakresem i możliwy do odtworzenia. Zrzut ekranu bez daty, wersji i właściciela ma ograniczoną wartość. Podobnie polityka opisująca proces nie dowodzi jeszcze, że proces rzeczywiście zastosowano w projekcie.

9. Co certyfikat AQAP potwierdza, a czego nie gwarantuje?

Certyfikacja systemu zarządzania jakością przez kompetentną jednostkę jest ważnym sygnałem dla zamawiającego. Pokazuje, że określony zakres działalności organizacji został oceniony pod kątem wskazanych wymagań, a firma utrzymuje procesy potrzebne do kontrolowanej realizacji.

Certyfikat może potwierdzać:

• wdrożenie i utrzymywanie systemu jakości zgodnego z określoną publikacją AQAP;
• objęcie oceną wskazanego zakresu działalności i lokalizacji;
• istnienie kontrolowanych procesów, odpowiedzialności i zapisów;
• cykliczną ocenę systemu przez stronę trzecią;
• organizacyjną podstawę do realizacji kontraktów wymagających AQAP.

Sam certyfikat nie gwarantuje automatycznie:

• zgodności każdego projektu z każdą umową;
• braku błędów w produkcie;
• spełnienia wymagań znajdujących się poza zakresem certyfikacji;
• posiadania wszystkich poświadczeń, koncesji lub kompetencji domenowych wymaganych w projekcie;
• skutecznego zastosowania procesów bez odpowiedniego zespołu i nadzoru;
• akceptacji dostawcy przez każdego zamawiającego bez dalszej kwalifikacji.

Dlatego należy sprawdzić jednostkę wydającą certyfikat, jego ważność, publikację i wydanie AQAP, zakres certyfikacji, lokalizacje oraz zgodność tego zakresu z planowanym zamówieniem. Warto również poprosić dostawcę o pokazanie, w jaki sposób jego system jakości zostanie zastosowany w konkretnym projekcie.

10. Jak wybrać dostawcę IT do projektu obronnego?

Dobry dostawca łączy trzy warstwy: zdolność organizacyjną, kompetencje techniczne i znajomość środowiska obronnego. Brak jednej z nich może ujawnić się dopiero na etapie integracji, nadzoru lub odbioru.

10.1 Checklista dla zamawiającego

• [ ] Zakres certyfikacji obejmuje rozwój, dostawę lub utrzymanie oprogramowania odpowiadające planowanemu projektowi.
• [ ] Dostawca potrafi przełożyć wymagania umowy na plan jakości i codzienny sposób pracy zespołu.
• [ ] Wymagania, decyzje projektowe, implementacja i testy pozostają identyfikowalne.
• [ ] Zarządzanie konfiguracją obejmuje kod, dokumentację, zależności, środowiska i wydania.
• [ ] Build przekazany do testów lub odbioru można jednoznacznie odtworzyć.
• [ ] Proces V&V ma określone role, kryteria, środowiska i zachowane wyniki.
• [ ] Niezgodności są oceniane, śledzone, retestowane i zamykane na podstawie dowodów.
• [ ] Poddostawcy i komponenty COTS podlegają kwalifikacji oraz monitoringowi.
• [ ] Zespół rozumie integrację oprogramowania ze sprzętem i ograniczenia środowiska docelowego.
• [ ] Dostawca zna specyfikę systemów obronnych, standardów NATO i pracy w łańcuchu dostaw.
• [ ] Potrafi przygotować dowody jakości wymagane podczas przeglądów, nadzoru i odbioru.
• [ ] Może zapewnić utrzymanie, zarządzanie zmianą i kontrolowany rozwój po wdrożeniu.
• [ ] Model współpracy jasno określa odpowiedzialność za produkt, jakość, bezpieczeństwo i decyzje.
• [ ] Deklarowane doświadczenie odpowiada faktycznemu zakresowi oraz krytyczności zamówienia.

10.2 Sygnały ostrzegawcze podczas kwalifikacji

Ostrożność powinny wzbudzić odpowiedzi ograniczające się do stwierdzenia, że firma posiada certyfikat albo pracuje w Agile. Istotne są również następujące sygnały:

• brak możliwości wyjaśnienia zakresu certyfikacji;
• plan jakości kopiowany bez dostosowania do projektu;
• brak właściciela procesu zarządzania konfiguracją;
• testy niepowiązane z wymaganiami i wersją produktu;
• poddostawcy traktowani jako odpowiedzialni za własną jakość bez nadzoru głównego wykonawcy;
• brak kontrolowanego sposobu zatwierdzania odstępstw;
• dokumentacja przygotowywana dopiero bezpośrednio przed odbiorem;
• niemożność przedstawienia sposobu obsługi zmian po wdrożeniu.

Najlepszym sprawdzianem jest rozmowa oparta na przykładowym scenariuszu: zmienia się wymaganie o wysokiej krytyczności, dotyka komponentu poddostawcy i wymaga nowego testu integracyjnego. Dojrzały partner potrafi opisać ocenę wpływu, decyzje, aktualizację konfiguracji, testy i dowody bez zasłaniania się ogólną procedurą.

11. Dlaczego TTMS jako partner dla sektora obronnego?

Wybór partnera technologicznego powinien opierać się na dopasowaniu do konkretnego przedsięwzięcia. W przypadku TTMS istotne jest połączenie certyfikowanego systemu jakości z kompetencjami technicznymi i doświadczeniem domenowym.

11.1 Certyfikowane procesy jakościowe

TTMS uzyskał certyfikaty AQAP 2110 i AQAP 2210, o czym informuje komunikat w pressroomie TTMS. Dla potencjalnego zamawiającego jest to potwierdzenie, że określony zakres systemu zarządzania jakością firmy został poddany niezależnej ocenie według wymagań stosowanych w sektorze obronnym i w zapewnieniu jakości oprogramowania.

Certyfikacja nie jest przedstawiana jako substytut analizy projektu. Stanowi organizacyjną podstawę, na której można zbudować plan jakości, identyfikowalność, zarządzanie konfiguracją i dowody wymagane przez daną umowę.

11.2 Kompetencje techniczne i znajomość domeny

Publiczna oferta TTMS dla sektora obronnego i kosmicznego obejmuje między innymi rozwój oprogramowania, usługi inżynierii obronnej IT, integrację sprzętu z oprogramowaniem, doradztwo techniczne, zarządzanie projektami oraz dostarczanie wyspecjalizowanych zespołów. TTMS opisuje również doświadczenie związane z systemami C2, C4ISR i systemami wsparcia bojowego oraz pracą w środowisku organizacji międzynarodowych.

Takie połączenie ma znaczenie, ponieważ zgodność procesu nie zastępuje kompetencji inżynierskich. Z drugiej strony nawet bardzo dobry zespół programistyczny może nie sprostać projektowi obronnemu, jeśli nie potrafi pracować z wymaganiami kontraktowymi, nadzorem jakościowym i formalnymi dowodami.

11.3 Możliwość dopasowania modelu współpracy

Projekt może wymagać kompletnego rozwiązania, wydzielonego komponentu, integracji, zespołu programistycznego albo pojedynczych kompetencji. Model powinien zostać dobrany po analizie zakresu, odpowiedzialności i wymagań jakościowych. Niezależnie od formy współpracy należy jasno ustalić właścicieli wymagań, konfiguracji, testów, ryzyka i akceptacji.

TTMS może wejść do projektu jako partner technologiczny wspierający rozwój, integrację i utrzymanie oprogramowania. Ostateczne zobowiązania, zastosowane publikacje AQAP oraz zakres dowodów powinny zostać określone w dokumentacji konkretnego przedsięwzięcia.

12. Jak może wyglądać współpraca z TTMS?

12.1 Analiza kontekstu i wymagań

Pierwszy etap obejmuje zrozumienie celu systemu, zakresu dostawy, interesariuszy, architektury, wymagań jakościowych i ograniczeń bezpieczeństwa. Zespół identyfikuje publikacje i klauzule przywołane w umowie oraz obszary wymagające doprecyzowania.

12.2 Określenie modelu realizacji

Ustalane są odpowiedzialności, skład zespołu, interfejsy z zamawiającym i innymi dostawcami, cykl życia, przeglądy, narzędzia, konfiguracja i wymagane dowody. Na tym etapie należy również zaplanować przeniesienie wymagań na poddostawców.

12.3 Kontrolowany rozwój i raportowanie

Realizacja łączy pracę inżynierską z zarządzaniem wymaganiami, ryzykiem, konfiguracją, jakością i niezgodnościami. Zamawiający otrzymuje uzgodnioną widoczność postępu, wyników i otwartych decyzji.

12.4 Weryfikacja, walidacja i odbiór

Testy i przeglądy są wykonywane na kontrolowanych wersjach według zatwierdzonych kryteriów. Pakiet odbiorowy powinien jednoznacznie pokazywać zawartość dostawy, wyniki, odstępstwa i pozostałe ograniczenia.

12.5 Utrzymanie i kontrolowany rozwój

Po wdrożeniu nadal potrzebne są zarządzanie konfiguracją, obsługa problemów, aktualizacje, ocena wpływu zmian i utrzymanie dokumentacji. Model wsparcia powinien odpowiadać znaczeniu systemu i wymaganej dostępności.

13. Szukasz partnera IT do projektu dla sektora obronnego?

Projekt obronny wymaga jednoczesnego zrozumienia technologii, jakości, integracji, bezpieczeństwa i odpowiedzialności kontraktowej. Warto zaangażować dostawcę przed zamknięciem architektury i planu realizacji, aby wymagania AQAP nie zostały potraktowane jako dokumentacyjny dodatek przygotowywany dopiero przed odbiorem.

Skontaktuj się z TTMS, aby omówić wymagania techniczne i jakościowe projektu, zakres odpowiedzialności oraz możliwy model współpracy z zespołem Defence.

14. Najczęściej zadawane pytania o AQAP 2210