Politechnika Warszawska. Metody testowania systemów wielosystemowych

Politechnika Warszawska Wydział Matematyki i Nauk Informacyjnych Praca dyplomowa magisterska Metody testowania systemów wielosystemowych Autor: Rafał Gajdulewicz Opiekun pracy: dr Lucjan Stapp Warszawa Grudzień 2010

podpis promotora podpis autora

Streszczenie Praca ta stanowi analizę zagadnienia testowania systemów wielosystemowych. Przeprowadzona została analiza cech odróżniajacych systemy wielosystemowe od systemów klasycznych oraz ich skutków dla procesu testowania, weryfikacji i walidacji. Praca zawiera opis metod, które były dotychczas używane do testowania systemów wielosystemowych: Metodologii Testów Zdolności (ang. Capability Test Method), Metody Testów Międzyprogramowych (Cross Program Approach) oraz metody Testowania Opartego na Ryzyku (ang. Risk Based Testing), stanowiacej podstawę doboru testowanych wymagań. Analiza przypadków testowania stworzonych dotychczas systemów wielosystemowych stanowi podstawę zawartych w pracy wniosków dotyczacych kluczowych aspektów procesu testowania i wspierajacych go procesów. W pierwszym rozdziale pracy zostały przedstawione i omówione dwie różne definicje systemu wielosystemowego. Rozdział ten zawiera też definicję i wprowadzenie do zagadnienia testowania oraz omówienie jego roli w procesie wytwarzania oprogramowania. Drugi rozdział pracy zawiera przykłady systemów wielosystemowych, omówienie ich cech według dwóch różnych klasyfikacji oraz najistotniejsze kwestie odróżniajace systemy wielosystemowe od klasycznych systemów. Trzeci rozdział pracy opisuje specyfikę procesu testowania systemów wielosystemowych oraz najpoważniejsze trudności w jego realizacji. Uwzględnione zostały też procesy wspierajace testowanie oraz późniejsza weryfikację i walidację systemu wielosystemowego. Czwarty rozdział zawiera opis metod stosowanych dotychczas do testowania systemów wielosystemowych oraz przypadki ich użycia wraz z wnioskami. Dodatkowo w rozdziale czwartym została opisana metoda Testowania Opartego na Ryzyku, której stosowanie powinno przynieść korzyści na wielu etapach wytwarzania systemu wielosystemowego. Piaty rozdział pracy jest podsumowaniem wniosków płynacych z analizy metod testowania systemów wielosystemowych. Zostały one przedstawione w kolejności odpowiadajacej etapom ich użycia w procesie wytwarzania oprogramowania, dzięki czemu rozdział ma charakter całościowego opisu aktywności testerów systemu wielosystemowego.

Spis treści 1. Wstęp............................................. 1 2. Wprowadzenie........................................ 2 2.1. Systemy wielosystemowe............................... 2 2.1.1. Definicja.................................... 2 2.2. Testowanie....................................... 2 2.2.1. Definicja.................................... 2 2.2.2. Podstawowe zasady.............................. 3 2.2.3. Rola testowania w procesie wytwarzania oprogramowania....... 4 3. Systemy wielosystemowe................................. 8 3.1. Przykłady........................................ 8 3.1.1. Systemy kontroli pojazdów.......................... 8 3.1.2. Systemy obrony powietrznej......................... 9 3.1.3. System nadzoru pola walki......................... 10 3.1.4. Systemy telekomunikacyjne......................... 10 3.2. 5 cech według Maier a................................ 11 3.2.1. Niezależność operacyjna........................... 11 3.2.2. Niezależność zarzadzania........................... 11 3.2.3. Emergent behaviour ( wyłaniajace się zachowanie)........... 11 3.2.4. Ewolucyjność rozwoju............................ 11 3.2.5. Niezależność geograficzna.......................... 11 3.3. Cechy według CTAL [15]............................... 12 3.3.1. Złożone z wielu elementów i warstw.................... 12 3.3.2. Krytyczność dostarczanej funkcjonalności................. 12 3.3.3. Heterogeniczność komponentów...................... 12 3.3.4. Możliwość ewolucji komponentów...................... 13 3.4. Różnice w stosunku do klasycznych systemów.................. 13 3.4.1. Problemy organizacyjne........................... 13 3.4.2. Wysoki stopień współpracy i zależności.................. 13 3.4.3. Konieczność zewnętrznej kwalifikacji.................... 15 4. Testowanie systemów wielosystemowych....................... 17 4.1. Problemy w procesie testowania........................... 17 4.1.1. Złożoność procesu wytwarzania....................... 17 4.1.2. Złożoność procesu testowego........................ 18 4.2. Inne kwestie zwiazane z testowaniem systemów wielosystemowych...... 19 4.2.1. Testuj wcześnie i często........................... 19 4.2.2. Kwestia odpowiedzialności i nadzoru.................... 20 4.2.3. Zarzadzanie ryzykiem............................. 20 4.2.4. Zapewnienie spójności pomiarowej ang. traceability........... 20 4.2.5. Kwestia weryfikacji i walidacji........................ 21 5. Metody testowania systemów wielosystemowych.................. 23 5.1. Risk based testing................................... 23 5.2. Metody testowania.................................. 26 5.2.1. C4ISR / DODAF................................ 26 5.2.2. Cross program approach........................... 28

Spis treści ii 5.3. Case studies...................................... 32 5.3.1. Krygiel - Behind the Wizard s Curtain.................. 32 5.3.2. Sledge - Army ASSIP System-of-Systems Test Metrics Task...... 34 5.3.3. Brooks i Sage - System of systems integration and test........ 36 5.3.4. Joglekar - Test Strategy for Net-Centric C4ISR System........ 37 6. Wnioski dotyczace testowania systemów wielosystemowych........... 39 6.1. Ogólnie......................................... 39 6.2. Planowanie i projektowanie............................. 40 6.2.1. Specyfikacja wymagań i ocena ryzyka................... 40 6.2.2. Podział pracy.................................. 42 6.2.3. Stworzenie harmonogramu......................... 43 6.3. Implementacja i wczesne testowanie........................ 44 6.3.1. Procesy wspierajace.............................. 44 6.3.2. Miary i metryki................................ 45 6.3.3. Wczesne testowanie.............................. 46 6.4. Formalne testowanie................................. 46 6.4.1. Przygotowanie i integracja.......................... 46 6.4.2. Weryfikacja, walidacja i kwalifikacja.................... 48 6.4.3. Zakończenie testowania........................... 49 7. Podsumowanie....................................... 50 Bibliografia........................................... 51

1. Wstęp System wielosystemowy (ang. system-of-systems) jest stosunkowo nowym pojęciem w inżynierii oprogramowania. Oznacza ono system zbudowany na zasadzie współpracy dużych systemów, zarówno istniejacych wcześniej, jak i wytwarzanych specjalnie na potrzeby kooperacji. Wytwarzanie tak złożonych systemów obarczone jest dużym ryzykiem błędu, a ocena jakości powstajacego produktu jest kluczowa dla powodzenia projektu. Aby dostarczyć wymaganych informacji o jakości niezbędne jest właściwe zaplanowanie i przeprowadzenie procesu testowania zarówno systemów komponentowych, jak i całości systemu wielosystemowego. Testowanie tak złożonych systemów wymaga zastosowania innego podejścia niż w przypadku klasycznych, pojedynczych systemów. Celem pracy jest analiza tego, jak powinien przebiegać proces testowania systemu wielosystemowego. Opisane zostana dwie metody, które zostały stworzone z myśla o zastosowaniu w procesie wytwarzania systemów wielosystemowych, przeanalizowane zostana też opisane w literaturze przypadki ich użycia. We wnioskach z pracy przedstawione zostanie podejście do testowania systemu wielosystemowego będace wynikiem analizy wspomnianych powyżej metod, przypadków ich użycia oraz ogólnych sugestii zawartych w pracach na temat systemów wielosystemowych. Praca opiera się na udostępnionych publicznie opisach przypadków i metod testowania systemów wielosystemowych, głównie wytwarzanych na zlecenie Departamentu Obrony USA. Podstawowymi źródłami informacji na temat testowania systemów wielosystemowych były prace Bernarda Homes a [12] oraz Rolanda Brooks a i Andrew Sage a [7]. Wszystkie pozycje bibliograficzne zostały napisane w języku angielskim, w zwiazku z czym większość terminów dotyczacych systemów wielosystemowych została przetłumaczone na potrzeby pracy.

2. Wprowadzenie 2.1. Systemy wielosystemowe 2.1.1. Definicja Poniższa definicja pochodzi z Certified Tester Advanced Level Syllabus (CTAL) [15]: Definicja 2.1.1 (System wielosystemowy (ang. System-of-systems)). Zbiór współpracujacych komponentów ( sprzęt, poszczególne aplikacje i metody komunikacji) połaczonych w celu osiagnięcia wspólnego rezultatu, nie posiadajacych jednolitej struktury zarzadzania Szczególnie istotnym zarówno dla wytwarzania, jak i dla testowania, stwierdzeniem jest [...] nie posiadajacych jednolitej struktury zarzadzania. Jest to jedna z najbardziej oczywistych cech odróżniajacych systemy wielosystemowe od klasycznych systemów. Zarówno ta, jak i inne cechy zostana szczegółowo omówione poniżej. Alternatywna definicja, pochodzaca z http://en.wikipedia.org/wiki/ System_of_systems podkreśla z kolei inna istotna właściwość systemów wielosystemowych - fakt, że dostarczana przez nie funkcjonalność jest znaczaco większa od sumy funkcjonalności poszczególnych komponentów: Definicja 2.1.2 (System wielosystemowy (ang. System-of-systems)). Zbiór zorientowanych zadaniowo lub dedykowanych systemów, które współdziela zasoby i możliwości by stworzyć nowy, bardziej złożony "meta system", który przewyższa funkcjonalnościa i wydajnościa sumę użytych systemów 2.2. Testowanie 2.2.1. Definicja Istnieje wiele definicji równoważnych definicji testowania, przytoczona poniżej pochodzi z pracy Cem Kaner a Exploratory Testing. Podkreśla ona aspekty testowania istotne dla procesu wytwarzania oprogramowania. Definicja 2.2.1. Testowanie oprogramowania to empiryczne, technologiczne badanie dostarczajace interesariuszom informacji na temat jakości testowanego oprogramowania lub usługi. Po pierwsze, testowanie jest badaniem przeprowadzanym w usystematyzowany i zaplanowany sposób na podstawie obserwowalnych faktów. Wykorzystuje ono podejście technologiczne, a więc używa narzędzi, metod i aparatu matematycznego w celu zdobycia obserwacji oraz opracowania i sprawdzenia wyników.

2.2. Testowanie 3 Po drugie, celem testowania jest ocena jakości oprogramowania, a nie, wbrew popularnemu przekonaniu, jego poprawności. Roger Pressman w pracy Software Engineering: A Practitioner s Approach [27] przytacza wiele standardowych czynników wpływajacych na jakość, z których pierwsza - opracowana przez McCall a - zawiera aż 10 czynników, a poprawność jest tylko jednym z nich: 1. Poprawność 2. Niezawodność 3. Wydajność 4. Możliwość kontroli dostepu 5. Użyteczność 6. Łatwość utrzymania 7. Elastyczność modyfikacji 8. Testowalność 9. Możliwość ponownego użycia 10. Zdolność współpracy z innymi programami Po trzecie, wynikiem procesu testowania powinny być informacje użyteczne dla interesariuszy i innych osób majacych wpływ na decyzję o wdrożeniu gotowego produktu. W tym celu niezbędne jest właściwe opracowanie zgromadzonych wyników, umożliwiajace ich zrozumiała prezentację i podsumowanie, a w konsekwencji wyciagnięcie wniosków przez zainteresowane osoby. Przykładem metody umożliwiajacej powiazanie celów biznesowych, realizujacych je wymagań oraz miar umożliwiajacych ocenę stopnia realizacji jest podejście GQM. [4] Zakłada ono trójstopniowy model definicji problemu biznesowego: Cel (ang. Goal) Cel biznesowy który ma być realizowany przez określony system lub jego część Pytanie (ang. Question) Pytania umożliwiajace ocenę spełnienia celu biznesowego Metryka (ang. Metric) Metryki umożliwiajace weryfikację tego czy i w jakim stopniu system umożliwia odpowiedź na postawione pytania 2.2.2. Podstawowe zasady Testuj wcześnie i często Podstawowa zasada testowania jest zapewnienie, by rozpoczęcie planowania i realizacji procesu testowania następowało tak wcześnie (w kontekście zaawansowania procesu wytwarzania), jak to możliwe. Takie podejście umożliwia lepsze zrozumienie i zaprojektowanie wytwarzanego systemu oraz, wraz z wprowadzeniem częstego, a najlepiej ciagłego (ang. continous testing) testowania, umożliwia wczesne wykrycie błędów. Jest to istotne nie tylko dlatego, że odkrycie usterki po wprowadzeniu systemu do użycia może być przyczyna strat lub porażki całego projektu, ale także dlatego, że koszt naprawy usterki wykrytej w trakcie wytwarzania produktu rośnie wykładniczo z czasem, jaki upłynał do jej wykrycia.

2.2. Testowanie 4 Tablica 2.1: Koszt naprawy błędu Faza implementacji Koszt błędu Analiza 1 Projekt 5 Implementacja 10 Testy modułowe 15-40 Testy systemowe 30-70 Po wdrożeniu 40-100 Źródło: Software Engineering: A Practitioner s Approach, Roger S. Pressman Pełne testowanie jest niemożliwe Pełne przetestowanie systemu, porzadane z teoretycznego punktu widzenia jako możliwość udowodnienia poprawności systemu, jest niemożliwe w akceptowalnym (z punktu widzenia klienta) czasie. Cem Kaner podaje następujace powody takiego stanu rzeczy [18]: Brak możliwości przetestowania wszystkich wartości wejść do programu Brak możliwości przetestowania wszystkich kombinacji wejść do programu Brak możliwości przetestowania wszystkich możliwych ścieżek wykonania Brak możliwości przewidzenia wszystkich możliwych błędów zewnętrznych majacych wpływ na wykonanie programu W takiej sytuacji, gdy osiagnięcie idealnej jakości jest niemożliwe, kluczem do sukcesu procesu zapewnienia jakości staje się taki wybór testowanych cech systemu, który zapewni wystarczajaco dobra (ang. good enough) jakość. Opisane w dalszej części metody testowania skupiaja się w dużej mierze na podaniu sposobu wyboru tego, co będzie testowane. Celem testowania jest dostarczenie informacji o jakości, a nie udowodnienie braku błędów Konsekwencja opisanych wyżej obserwacji jest fakt, że niemożliwe jest udowodnienie, że oprogramowanie nie zawiera błedów. Celem testowania jest badanie oprogramowania i dostarczanie informacji o jego jakości. Umożliwia to osobom zarzadzaj acym projektem ocenę korzyści i zagrożeń zwiazanych z wytwarzaniem i wydaniem programu. [3] [19] Oprócz wymienionych powyżej funkcji wyniki procesu testowego sa podstawa zewnętrznej kwalifikacji systemów komputerowych, która jest wymagana dla coraz szerszej klasy systemów. 2.2.3. Rola testowania w procesie wytwarzania oprogramowania W przypadku systemów o dużym koszcie porażki (ang. cost of failure) często stosowana modelem rozwoju oprogramowawania jest model V (lub jego rozwinięcia). Stanowi ona rozwinięcie klasycznego modelu kaskadowego o dodatkowa, odwrócona kaskadę, reprezentujac a czynności zwiazane z integracja, testowaniem i kwalifikacja systemu. Na poniższym diagramie można zauważyć, w jaki sposób czynności zwiazane z testowaniem skorelowane sa z czynnościami zwiazanymi z wytwarzaniem.

2.2. Testowanie 5 Rysunek 2.1: Model V Źródło: http://www.onestoptesting.com/images/v-model.jpg Wersja polska: opracowanie własne Projekt testów Projekt testów to dokument opisujacy funkcjonalności i części systemu, które będa podlegały testom, oraz projektowany sposób ich wykonania. W przypadku zaproponowanego wyżej podziału projekty testów sa tworzone na różnych poziomach szczegółowości, odpowiadajacych zaawansowaniu prac projektowych. W takim modelu projekt testów nie służy jedynie jako podstawa późniejszego ich planowania, ale może też stanowić sposób weryfikacji poprawności stworzonego projektu systemu. Plan testów Plan testów to dokument stanowiacy podstawę wykonania projektu testowego. Najpopularniejszym standardem specyfikujacym strukturę planu testów jest norma IEEE 829 [1], według której zawartość plan testów powinien zawierać następujace sekcje: Elementy testowe Zawiera szczegółowa listę funkcjonalności, modułów i funkcji podlegajacych testowaniu Cechy testowane Lista cech podlegajacych testowaniu wraz z odniesieniami do ich specyfikacji Cechy nie testowane Lista cech nie podlegajacych testowaniu wraz z uzasadnieniem Podejście

2.2. Testowanie 6 Stanowi opis sposobu przeprowadzenia procesu testowego, z uwzględnieniem informacji na temat typu wykonywanych testów, sposobu ich projektowania i wykonania, momentu i kryteriów rozpoczęcia i zakończenia testowania. Kryteria zaliczenia/nie zaliczenia testów Opis reguł decydujacych o zaliczeniu/ nie zaliczenu poszczególnych testów przez poszczególne cechy Kryteria zawieszenia / kontynuowania testów Opis reguł decydujacych o zawieszeniu procesu testowego oraz wymagań do jego kontynuowania Produkty procesu testowego Lista artefaktów będacych skutkiem pracy zespołu testowego, takich jak przypadki i scenariusze testowe, specyfikacje testów i ich wymagań, wyniki pracy narzędzi testowych, raporty itp. Zadania testowe Opis zadań testowych, ich wzajemnych zależności, wymagań, procesu przygotowania i wykonania Uwarunkowania środowiska Opis uwarunkowań środowiska i stanu niebędnych do wykonania poszczególnych testów Odpowiedzialności Opis osób i organizacji odpowiedzialnych za wykonanie odpowiednych części procesu testowego Potrzeby kadrowe i szkoleniowe Opis zasobów ludzkich i szkolenia wymaganego do realizacji procesu testowego Harmonogram Opis poszczególnych faz testowania, ich kamieni milowych, wymaganych zasobów oraz powiazań z procesem wytwórczym Ryzyka i sposób zapobiegania Opis najistotniejszych zagrożeń dla procesu testowego, prawdopodobieństwa ich wystapienia, szacowanego wpływu oraz sposobu zapobiegania Potwierdzenie zgody na realizację planu testów Lista osób akceptujacych plan testów oraz ich podpisów Powyższy opis powstał przy użyciu Słownika wyrażeń zwiazanych z testowaniem w wersji 2.0, dostępnej pod adresem http://www.sjsi.org/webgears//files/ sjsi/file/slownik_terminow%20_testowych_2_0_ver_0_99.pdf Testy modułowe Pierwsza faza testów dynamicznych, zazwyczaj występujaca najwcześniej w cyklu implementacji systemu, polegajaca na weryfikowaniu poprawności kodu tworzacego poszczególne moduły zanim zostana one zintegrowane. Może się ona rozpoczać się jeszcze w trakcie implementacji systemu, przebiegajac równolegle z powstawaniem nowych funkcji. Powstałe w tej fazie - często przy wparciu programistów systemu - testy moga być przydatne także w późniejszych etapach procesu testowego oraz stanowić jedna z miar tzw. pokrycia kodu testami (ang. test coverage).

2.2. Testowanie 7 Testy integracyjne wewnętrzne ( małe ) Faza testów polegajacych na weryfikacji poprawności współpracy już zbudowanych i przetestowanych modułów systemu. Służa one sprawdzeniu, czy komunikacja pomiędzy modułami przebiega poprawnie, czy wspólnie dostarczaja one wymaganej funkcjonalności oraz czy zwiazane z komunikacja obciażenie nie zaburza właściwego funkcjonowania komponentów. Testy systemowe Faza testów polegajacych na sprawdzeniu poprawności funkcjonowania zintegrowanego systemu. Najczęściej wykonywanymi w tej fazie testami sa testy funkcjonalne, sprawdzajace poprawność implementacji kluczowych funkcjonalności oraz spełnienie przez nie wymagań użytkownika. Innymi typowymi testami wykonywanymi podczas tej fazy sa: Testy użyteczności (interfejsu) Testy wydajnościowe Testy instalacyjne Testy bezpieczeństwa i zabezpieczeń (ang. safety and security) Testy akceptacyjne Jest to faza testów będaca podstawa przekazania systemu klientowi i jego rozliczenia. Testy akceptacyjne sa zazwyczaj przeprowadzane w środowisku będacym kopia środowiska produkcyjnego lub odzwierciedlajacym je środowisku testowym dostarczanym przez klienta, przez docelowych użytkowników systemu i przedstawicieli klienta, we współpracy z wytwórcami systemu. Testy utrzymaniowe Testy wykonywane w czasie eksploatacji systemu, obejmuja głównie testy regresji, polegajace na sprawdzeniu, czy system działa poprawnie po zmianach spowodowanych np. dodaniem nowej funkcjonalności, zmiana środowiska lub naprawa istniejacych błędów.

3. Systemy wielosystemowe 3.1. Przykłady Systemy wielosystemowe wraz z rozwojem technologicznym znajduja zastosowanie w coraz większej liczbie dziedzin, z których kilka najpopularniejszych zostało omówionych poniżej. Wśród nieomówionych klas systemów wielosystemowych można jeszcze wymienić systemy medyczne, systemy nadzoru przestrzeni powietrznej czy zintegrowane systemy transportowe. 3.1.1. Systemy kontroli pojazdów Pierwsza omawiana klasa systemów wielosystowych sa systemy kontroli pojazdów i pocisków powietrznych, wśród których klasycznym przykładem jest system obsługi pocisków Tomahawk. Został on wprowadzony do użycia w roku 1983, a po raz pierwszy został zastosowany w walce w roku 1991 podczas konfliktu w Zatoce Perskiej. Od tamtej pory przeszedł kilka istotnych modyfikacji, dotyczacych nie tylko samego pocisku, ale także sposobu kontroli nad nim i źródeł danych wykorzystywanych do namierzania celu. Rysunek 3.1: Schemat systemu Tomahawk Źródło:Jeffrey S. Mayer Tactical Tomahawk Weapon System [24]

3.1. Przykłady 9 System Tactical Tomahawk jest ciekawy nie tylko jako wzorcowy wręcz przykład systemu posiadajacego wszelkie cechy systemu wielosystemowego, ale także z powodu zmian w kluczowych elementach jego struktury, takich jak system sterowania i pobierania danych o położeniu. System sterowania pociskiem ewoluował od systemu TWCS, będacego adaptacja starego systemu sterowania czołgami, poprzez system ATWCS, należacy do klasy komercyjnego oprogramowania z półki (ang. commercial-off-the-shelf), do systemu TTWCS, tworzonego specjalnie pod katem systemu Tomahawk i umożliwiajacego dodanie zupełnie nowych funkcjonalności, takich jak zmiana celu w czasie lotu pocisku. Dodatkowym polem działania systemu Tomahawk na którym nastapił istotny postęp jest dołaczenie w 1993 roku - a więc po 10 lata używania systemu Tomahawk - systemu GPS, służacego do zdalnego namierzania lokalizacji celu. W tym wypadku system GPS częściowo zastapił systemy TERCOM i DSMAC. 3.1.2. Systemy obrony powietrznej Kolejna przykładowa klasa systemów wielosystemowych sa systemy antyrakietowe tworzone przez różne kraje w celu obrony własnej przestrzeni powietrznej. Wśród krajów, które wytworzyły własne wersje takiego systemu można wymienić: Stany Zjednoczone, Wielka Brytanię, Rosję, Francję, Chiny, Indie i Izrael (za http://en.wikipedia.org/wiki/missile_defense). Rysunek 3.2: System obrony powietrznej Francji Źródło: Bernard Homes Governing testing systems of systems [12]

3.1. Przykłady 10 3.1.3. System nadzoru pola walki System Task Force XXI to projekt Departamentu Obrony USA umożliwiajacy wspieranie żołnierzy na polu walki poprzez umożliwienie im skutecznej komunikacji na duża odległość oraz dostarczanie informacji pochodzacych z różnorodnych, normalnie niedostępnych dla pojedynczego żołnierza źródeł. Projekt pod różnymi nazwami jest realizowany od 1992 roku do tej pory, jego testowe wdrożenie miało miejsce w roku 1997, wnioski płynace z niego zostały opisane w pracy Anette Krygiel Behind the Wizard s Curtain [20]. Rysunek 3.3: Task Force XXI Źródło: Monica Farah-Stapleton Proposing a C4ISR Architecture Methodology for Homeland Security 3.1.4. Systemy telekomunikacyjne Ostatnia klasa systemów wielosystemowych sa systemy telekomunikacyjne, wykorzystujace różnorodne metody przesyłania informacji na odległość do budowania nowych metod komunikacji i dostarczania funkcjonalności rozproszonym użytkownikom. Najczęściej przytaczanym przykładem systemu tego typu jest Internet, jednak trudno uznać go za system wzorcowy dla tej klasy chociażby ze względu na

3.2. 5 cech według Maier a 11 brak uporzadkowanego systemu jego ewolucji. Inne przykłady systemów wielosystemowych z klasy systemów telekomunikacyjnych to systemy rezerwacji podróży, takie jak SABRE lub AMADEUS, lub zintegrowane systemy billingowe [12]. 3.2. 5 cech według Maier a Systemy wielosystemowe z definicji należa do zupełnie innej klasy złożoności niż systemy tradycyjne, jednak oprócz tej oczywistej właściwości można też wyróżnić kilka innych cech wspólnych dla tego typu systemów. Opisane w kolejnych punktach cechy sa oparte na tzw. klasyfikacji Maier a [23]. Pierwsze dwie sa według niego warunkiem koniecznym zakwalifikowania danego systemu do klasy systemów wielosystemowych. Ostatnia z nich, niezależność geograficzna, miała istotne znaczenie w momencie powstawania pracy Maiera (roku 1998), obecnie norma jest lokalizowanie komponentów jednego systemu w wielu niezależnych lokalizacjach. 3.2.1. Niezależność operacyjna Oznacza ona, że poszczególne komponenty działaja niezależnie od siebie, dostarczajac części funkcjonalności systemu wielosystemowego. Dodatkowo moga one pełnić oddzielna, często znacznie szersza rolę jako niezależne systemy. 3.2.2. Niezależność zarzadzania Poszczególne systemy moga być zarzadzane poprzez niezależne organizacje, często konkurujace ze soba lub realizujace niezależne cele. Wpływa to istotnie na cele stawiane systemowi wielosystemowemu oraz na sposób kontroli jego funkcjonowania. 3.2.3. Emergent behaviour ( wyłaniajace się zachowanie) Ze względu na złożoność systemów wielosystemowych trudno jest dokładnie przewidzieć i udokumentować ich zachowanie zanim docelowy system zacznie funkcjonować. Może to powodować konieczność wprowadzenia zmian w projekcie systemu w póżniejszych etapach jego cyklu życia, co dodatkowo komplikuje proces wytwarzania systemu wielosystemowego. 3.2.4. Ewolucyjność rozwoju Proces wytwarzania systemu wielosystemowego trudno uznać za ostatecznie zakończony, często jego poszczególne elementy musza być dostosowywane do wymagań stawianych zarówno przez system wielosystemowy, jak i ich niezależna rolę. W takim wypadku istotna staje się możliwość weryfikacji poprawności nowej wersji komponentów np. poprzez testy regresji. 3.2.5. Niezależność geograficzna Poszczególne komponenty systemu wielosystemowego sa często zlokalizowane w różnych miejscach, a często także cechuja się różnym sposobem i stopniem kontroli.

3.3. Cechy według CTAL [15] 12 3.3. Cechy według CTAL [15] 3.3.1. Złożone z wielu elementów i warstw Na przykładzie wymienionych powyżej systemów łatwo zauważyć, że w przeciwieństwie do klasycznych systemów, które sa projektowane i wytwarzane jako całość, systemy wielosystemowe stosunkowo rzadko posiadaja strukturę hierarchiczna. Zazwyczaj sa one w dużej mierze budowane z już istniejacych komponentów, które musza zostać dostosowane do współpracy w ramach wspólnej całości. Komponenty te moga też należeć do różnych podmiotów (patrz 3.2.2), a także moga znajdować się w różnych miejscach (patrz 3.2.5). Dodatkowa komplikacja może być konieczność powielenia kluczowych funkcjonalności po to, by zapewnić ich redundancję na wypadek awarii. 3.3.2. Krytyczność dostarczanej funkcjonalności Systemy wielosystemowe często tworzone sa w celu dostarczenia funkcjonalności militarnej lub sprawowania kontroli nad ruchem pojazdów (samolotów, satelitów, rakiet itd.), co sprawia, że konieczne staje się spełnienie wymagań charakterystycznych dla systemów dotarczajacych krytycznej funkcjonalności (ang. life-critical). Inna popularna i nie mniej krytyczna klasa systemów wielosystemowych sa tzw. telecomy, czyli zintegrowane systemy umozliwajace komunikację na szeroka skalę. 3.3.3. Heterogeniczność komponentów Systemy wielosystemowe moga składać się z podsystemów o różnych typach budowy, a co za tym idzie różnej charakterystyce wytwarzania. Najistotniejsze typy zostały omówione poniżej. Systemy ładowalne Klasa systemów obejmujaca programy w pewnym stopniu niezależne od sprzętu na którym działaja, co pozwala na łatwe i elastyczne zmiany oprogramowania. Zmiana sprzętu w przypadku systemów ładowalnych nie powoduje konieczności wymiany oprogramowania, jednak w takim przypadku powinna zostać przeprowadzona pewna forma testów regresji - ich brak może być tragiczny w skutkach, czego przykładem jest katastrofa rakiety Arianne 5 (patrz http://en.wikipedia.org/ wiki/ariane_5_flight_501). Systemy wbudowane Klasa systemów obejmujaca oprogramowanie ściśle zwiazane z osprzętem, stanowiaca często jego część (np. firmware). Systemy tej klasy musza spełniać ścisłe wymagania stawiane przez osprzęt, będac od niego wysoce zależne, co ogranicza możliwość zmian sprzętu i oprogramowania. Systemy czasu rzeczywistego Jest to klasa systemów zawierajaca systemy, dla których wynik działania nie zależy tylko od poprawności osiagniętego rezultatu, ale także od czasu jego uzyskania. W przypadku przekroczenia tego czasu nawet prawidłowy - zgodny z przewidywaniami teoretycznymi - wynik jest uznawany za bład.

3.4. Różnice w stosunku do klasycznych systemów 13 3.3.4. Możliwość ewolucji komponentów Oprócz kwesti ewolucyjności rozwoju istotnym dla działania systemu wielosystemowego jest fakt, że niektóre jego podsystemy funkcjonowały przed jego powstaniem, a więc ich dojrzałośc i czas do zakończenia pracy może się diametralnie różnić od pozostałych jego części. Może to powodować konieczność zastapienia ich innymi systemami, często różnymi w ramach systemu wielosystemowego i poza nim. 3.4. Różnice w stosunku do klasycznych systemów W tej części pracy zostana omówione główne różnice pomiędzy klasycznymi systemami a systemami wielosystemowymi. 3.4.1. Problemy organizacyjne Brak jednolitej struktury zarzadzania W przypadku systemów nadzorowanych przez organizacje o różnym stopniu rozwoju i sposobie zarzadzania często dochodzi zarówno do niezgodności procesów towarzyszacych wytwarzaniu oprogramowania, jak i do problemów podczas użytkowania systemu. Przykładowe pola konfliktu: Zarzadzanie zmiana Zarzadzanie ryzykiem Sposób współpracy zespołów obsługi i wsparcia systemu Problemy we współpracy Partnerstwo państwowo - prywatne W przypadku systemów realizowanych we współpracy państwa z firmami prywatnymi część informacji / dokumentacji nie może być współdzielona ze względu na tajemnicę państwowa. Rywalizacja między konkurencyjnymi firmami W przypadku współpracy konkurujacych firm niechęć do dzielenia się informacjami / wola rywalizacji może stać się problemem utrudniajacym właściwe planowanie i wytwarzanie systemu wielosystemowego Praktyki antymonopolowe Konieczność przestrzegania zasad uniemożliwiaja- cych uzyskanie dominujacej pozycji jednemu podmiotowi może sprawić, że pewne zadania będa musiały zostać wykonane przez usługodawców niekoniecznie posiadajacych najwyższe kompetencje w określonej dziedzinie. 3.4.2. Wysoki stopień współpracy i zależności Biorac pod uwagę duży stopień interakcji komponentów systemu wielosystemowego Bernard Homes [12] zauważa 3 istotne problemy zwiazane z zarzadzaniem ryzykiem, które zostały omówione poniżej. Ograniczenia wpływaja nie tylko na bezpośrednio połaczone systemy Niezbędna jest szczegółowa i nie ograniczajaca się do jednego poziomu analiza ryzyka zwiazanego z funkcjonowaniem i zmianami poszczególnych podsystemów.

3.4. Różnice w stosunku do klasycznych systemów 14 Systemy (i organizacje) moga mieć różna tolerancję ryzyka Poszczególne systemy moga mieć różna tolerancję ryzyka, często zależna także od ich właściciela / operatora. W tym przypadku niezbędna jest dodatkowa analiza uwarunkowań wpływajacych na ryzyko zwiazane z poszczególnymi podsystemami. Należy rozpatrywać nie tylko ryzyko zwiazane z pojedynczym systemem W klasycznych systemach analiza ryzyka ogranicza się do rozpatrzenia zagrożeń zwiazanych z działaniem systemu i wpływajacych na niego czynników zewnętrznych. W systemie wielosystemowym, biorac pod uwagę wysoki stopień współpracy i zależności podsystemów równie istotna staje się analiza ryzyk przyjmowanych (ang. inherited ) i powodowanych (ang. imposed ). Dopiero wtedy można określić, z jakim ryzykiem wiaże się działanie określonego systemu i czy duplikacja jego funkcjonalności / zmiana sposobu współpracy nie pozwola na zmniejszenie ogólnego poziomu ryzyka systemu. Przykład Kwestia tolerancji ryzyka w przypadku wytwarzania złożonych produktów w warunkach intensywnej współpracy może mieć istotny wpływ na ostateczny czas wytworzenia funkcjonalności, co obrazuje poniższy diagram 3.4 stworzony przez Bernard a Homes a [12]. W tym wypadku poziom tolerancji ryzyka organizacji odnosi się do tolerancji na opóźnienia, zaś cały diagram ilustruje planowany i faktyczny przebieg wykonania określonego, złożonego zadania przez systemy należace do różnych organizacji. Rysunek 3.4: Tolerancja ryzyka Źródło: Bernard Homes Governing testing systems of systems [12]

3.4. Różnice w stosunku do klasycznych systemów 15 W tym przypadku względnie niewielkie opóźnienie, które wystapiło w zadaniu A3 wykonywanym przez organizację A spowodowało istotne opóźnienia w organizacji D, co ostatecznie doprowadziło do poważnego opóźnienia w wykonaniu całego zadania. Widać tutaj znaczenie zarówno wielopoziomowej analizy wpływów i ryzyka przyjmowanego i powodowanego- opóźnienie w organizacji D nie wynikało bezpośrednio z działania jej samej ani jej bezpośrednich sasiadów. Isotna jest też kwestia zapewnienia odpowiedniej kolejności wykonania zadań i ewentualnej redundancji - gdyby działania organizacji D nie zależały od działań organizacji o większej tolerancji ryzyka lub gdyby jej wymagania mogły być dostarczone przez różne zadania poprzedzajace możnaby uniknać lub ograniczyć opóźnienie. 3.4.3. Konieczność zewnętrznej kwalifikacji Systemy wielosystemowe zazwyczaj musza spełnić narzucone zewnęrznie wymagania, zwiazane z jedna z dwóch przyczyn: Wymagania zwiazane z nadzorem państwowym Nadzór lub udział organizacji państowych w wytwarzaniu systemu wiaże się z koniecznościa spełnienia określonych norm i wymagań np. narzucanych przez DoDAF (patrz 5.2) w przypadku Departamentu Obrony USA. Wymagania zwiazane z krytycznościa systemu Systemy life-critical często przechodza oddzielna kwalifikację organizacji odpowiedzialnych za ich nadzór, takich jak AWST (www.awst.at) w przypadku elektrowni atomowych, RTCA w przypadku systemów awiacyjnych czy CCHIT w przypadku systemów medycznych. Zgodność z regulacjami jest sprawdzana zarówno poprzez weryfikację i walidację finalnego systemu, jak i sprawdzenie istnienia i poprawności dokumentacji stworzonej podczas procesu wytwarzania, np. dokumentów opisuja- cych [12]: Sposób kontroli spełnienia wymagań Zarzadzanie konfiguracja Zarzadzanie wersja i zmianami ( traceability ) Silny wpływ zapewnienia jakości W wytwarzaniu systemów wielosystemowych niezbędne jest realizowanie procesu zapewnienia jakości (ang. quality assurance ). Zapewnienie jakości w odniesieniu do oprogramowania według Standard for Software Assurance NASA [25] polega na Definicja 3.4.1. Stosowaniu zaplanowanego i systematycznego podejścia do oceny jakości oprogramowania rozumianej jako jego zgodność ze standardami, procesami i procedurami. Norma NASA-STD 8739.8 definuje trzy typy standardów: Standardy dokumentacji Specyfikujace formę i zawartość dokumentacji dotyczacej planowania, kontroli oraz samego wytworzonego produktu Standardy projektowe

3.4. Różnice w stosunku do klasycznych systemów 16 Specyfikujace formę i zawartość projektu produktu. Zawieraja one zasady i metody umożliwajace przełożenie wymagań wobec produktu na jego projekt oraz jego właściwa dokumentację Standardy kodu Specyfikujace sposób i język implementacji produktu, jej ograniczenia oraz sposób wewnętrznej dokumentacji. na jego projekt oraz jego właściwa dokumentację

4. Testowanie systemów wielosystemowych Specyfika systemów wielosystemowych sprawia, że proces ich testowania staje się nie tylko o wiele bardziej złożony, co w dość oczywisty sposób jest implikowane przez stopień skomplikowania samego systemu, ale także zmusza do rozwiazywania problemów nie występujace zazwyczaj w przypadku klasycznych systemów. Powoduje to nie tylko konieczność zaanagażowania większej ilości środków, ale też konieczność zastosowania innego podejścia ze względu na fakt, że komponenty systemów wielosystemowych sa niezależnymi systemami, z własnymi wymaganiami, ograniczeniami i procesami życia. 4.1. Problemy w procesie testowania W tym rozdziale opisane zostana specyficzne dla systemów wielosystemowych problemy zwiazane z procesem testowania. 4.1.1. Złożoność procesu wytwarzania Podstawowym problemem w testowaniu systemów wielosystemowych jest ich złożoność, której poszczególne aspekty zostały omówione poniżej. Ilość kodu Złożoność systemu wielosystemowego to nie tylko suma złożoności jego komponentów, ale także złożoność interfejsów pomiędzy nimi, także tych umożliwiajacych redundancję. Kwestie integracji zostana poruszone później, ale należy wziać pod uwagę, że testowanie interfejsów między systemami jest zadaniem trudnym nawet w przypadku prostych systemów. Wymaga ono kooperacji organizacji sprawujacych kontrolę nad współpracuja- cymi systemami, co ze względów opisanych w poprzednim rozdziale (3.4.1) może być problematyczne. Homes [12] postuluje w takim przypadku rozdzielenie odpowiedzialności za testy w taki sposób, by systemy komponentowe były testowane przez zespoły odpowiedzialne za ich testowanie z ramienia właściciela, zaś interfejsy były testowane przez obejmujacy całośc (ang. overarching) zespół testerów systemu wielosystemowego [30], podlegajac nadzorowi interesariuszy systemu wielosystemowego. Procesy kontroli zmian Przy wytwarzaniu klasycznych systemów proces kontroli zmian może być realizowany przy użyciu powszechnie dostępnych narzędzi do wersjonowania kodu, zarzadzania zmianami oraz odpowiedniej dyscypliny. Heterogeniczność budowy systemów wielosystemowych (w tym obecność silnie powiazanego ze sprzętem oprogramowania wbudowanego) oraz problemy z współdzieleniem informacji i zarzadza- niem prowadza do poważnych komplikacji procesu kontroli zmian.

4.1. Problemy w procesie testowania 18 Dodatkowo w przypadku systemów wielosystemowych bardzo utrudnione jest precyzyjne planowanie procesu zmian, co wynika z możliwości niezależnej ewolucji komponentów systemu wielosystemowego i braku bezpośredniej kontroli nad ich wytwarzaniem. Ilość i dostępność dokumentacji Problemy zwiazane z będac a podstawa procesu testowego dokumentacja systemów wielosystemowych można podzielić na dwie kategorie: zwiazane z niedostatecznym udokumentowaniem systemu badź brakiem dostępności istniejacej dokumentacji. Pierwsza kategoria problemów powodowana jest przede wszystkim innowacyjnościa stosowanych technologii i ich wyłaniajacym się zachowaniem, które to cechy utrudniaja umożliwiajacej zaplanowanie i realizację testów. Przykładem takich cech moga być na przykład problemy z ocena dokładności nowo powstajacych urzadzeń naprowadzajacych w przypadku systemów kontroli pojazdów, czy też wydajność sprzętu budowanego na potrzeby konkretnego systemu telekomunikacyjnego. Druga kategoria problemów zwiazana jest z brakiem dostępności szczegółowej dokumentacji w przypadku gotowych i wcześniej istniejacych systemów, których dokumentacja często nie jest udostępniana z przyczyn opisanych w poprzednim rozdziale (patrz 3.4.1). Długi okres trwania projektu Długi czas trwania projektu i różnice w etatach rozwojowych komponentów sprawiaja, że w dłuższym terminie problematyczny staje się nadzór nad przetestowanymi funkcjonalnościami i spełnionymi wymaganiami. Systemy komponentowe, które w momencie projektowania systemu wielosystemowego były wyznacznikiem standardów i wzorem nowoczesności w momencie jego wdrażania moga być już przestarzałe (patrz 3.1.1), lub może zachodzić konieczność uzupełnienia ich o nowe funkcjonalności, które pierwotnie nie były uwzględnione w planie testów. Dodatkowo w przypadku długich projektów występuje znacznie większa rotacja personalna, zarówno na stanowiskach wytwórczych jak i nadzorczych, co nie tylko wydłuża czas wytwarzania, ale też może być źródłem dodatkowych nieporozumień i konfliktów. 4.1.2. Złożoność procesu testowego Złożoność procesu testowego jest istotnym problemem w przypadku testowania systemów wielosystemowych - w ich przypadku niemożliwe jest często zrozumienie i bezpośrednie nadzorowanie testów przez jedna osobę [7] [30]. Rozpatrujac charakterystykę poszczególnych poziomów testowania sprawdzimy, dlaczego konieczne jest podzielenie odpowiedzialności za testy pomiędzy wiele zespołów testowych. Testy jednostkowe Poszczególne systemy wymagaja różnych środowisk testowych Sprawowanie bezpośredniej, centralnej kontroli nad testami jest utrudnione Ilość testów utrudnia lub nawet uniemożliwia ich uruchamianie w trybie ciagłym dla wszystkich systemów jednocześnie, np. jako część procesu ciagłej integracji (ang. continous integration)

4.2. Inne kwestie zwiazane z testowaniem systemów wielosystemowych 19 Testy integracyjne duże Przeprowadzenie testów integracyjnych wymaga współpracy między organizacjami Konieczne jest wcześniejsze wyspecyfikowanie i przygotowanie środowiska testowego W przypadku niepowodzenie niezbędna jest: Ocena przyczyn Znalezienie organizacji odpowiedzialnej za jego wystapienie Określenie działań naprawczych Identyfikacja możliwych konsekwencji Testy systemowe Funkcję wykonawcy, a często także klienta pełni wiele organizacji jednocześnie Niezbędne jest ogólne spojrzenie na projekt i obiektywna ocena możliwości i cech podsystemów Zwiazana z krytycznościa systemów redundancja utrudnia przewidywanie koniecznych testów Testy akceptacyjne W przypadku systemów wielosystemowych akceptacja systemu oprócz jego odbioru przez klienta wymaga także kwalifikacji (ang. qualification) przez zewnętrzna organizację dopuszczajac a system do użycia. Proces kwalifikacji zazwyczaj opiera się na analizie zgromadzonych podczas wytwarzania dokumentów i uczestnictwie w testach systemowych - ponowne przeprowadzenie testów całego systemu jest zazwyczaj zbyt kosztowne. 4.2. Inne kwestie zwiazane z testowaniem systemów wielosystemowych Opisane wcześniej problemy nie znacza, że klasyczne metody testowania nie maja zastosowania dla systemów wielosystemowych. Nadal pełnia one fundamentalna rolę w procesie testowania komponentów, można też próbować zastosować ich ideę do testowania systemu wielosystemowego, tworzac niejako oddzielny proces testowy, działajacy na innym poziomie abstrakcji - pojedyncze systemy pełnia w nim rolę komponentów, a ich testowanie często polega na analizie wyników szczegółowego procesu testowego. 4.2.1. Testuj wcześnie i często W przypadku systemów wielosystemowych stosowanie zasady testuj wcześnie i często jest zdecydowanie utrudnione. Podstawowymi problemami według Homes a [12] sa: Problemy z dostępnościa środowiska testowego - opisane poniżej (patrz 4.2.4). Częste i trudne do przewidzenia zmiany konfiguracji Problem ewolujacych wymagań Przepychanie testów na wyższy poziom - opisane poniżej (patrz 4.2.4).

4.2. Inne kwestie zwiazane z testowaniem systemów wielosystemowych 20 4.2.2. Kwestia odpowiedzialności i nadzoru W sytuacji, gdy własność i kontrola nad wytwarzaniem nie sa skupione w rękach jednej organizacji problemem staje się wyznaczenie osoby nadzorujacej i odpowiedzalnej za przebieg projektu. Ze względu na to, że testerzy biora, a na pewno powinni brać czynny udział w wytwarzaniu systemu od jego najwcześniejszych etapów, nie reprezentujac zazwyczaj interesów żadnej z pojedynczych organizacji sa często postrzegani jako osoby, które odpowiadaja za jakość systemu i kontrolę nad tym, w jaki sposób powstaje. [12] 4.2.3. Zarzadzanie ryzykiem Jednym z istotnych wyników procesu testowania jest dostarczenie informacji na temat aktualnego poziomu ryzyka zwiazanego z systemem. W przypadku systemów wielosystemowych jest to o tyle istotne, że poszczególne organizacje, a także pojedyncze systemy moga mieć różna jego tolerancję (patrz 3.4.2). W tej sytuacji istotna staje się odpowiednia analiza zarówno ryzyka zwiazanego z poszczególnego systemami, jak i ryzyka powodowanego i przyjmowanego. Miara ryzyka Klasyczna miara ryzyka, opisujac a wielkość potencjalnych strat można zaprezentować za pomoca formuły ryzyko = prawdopodobieństwo koszt błędu Od poziomu ryzyka zależy to, na jakim szczeblu zarzadzania dany bład będzie obsługiwany. W przypadku systemów wielosystemowych takie podejście jest nie do końca wystarczajace, np. Homes proponuje wyróżnienie trzech rodzajów wpływu (ang. impact) ryzyka na wyniki procesu : 1. Koszt - mierzony procentem przekroczenia budżetu 2. Funkcjonalność - określany przez to, jak poważny jest bład 3. Czas - procentowe opóźnienie lub ważność niedotrzymanych terminów Proponuje też alternatywny sposób eskalacji błędów, który zostanie opisany w dalszej części pracy (patrz 6.2.1). 4.2.4. Zapewnienie spójności pomiarowej ang. traceability Autorzy prac na temat systemów wielosystemowych [12] [7] zwracaja uwagę na duże znaczenie zapewnienia spójności pomiarowej. Spójność pomiarowa jest rozumiana jako możliwość wzajemnego powiazania i przedstawienia historii oraz sposobu ewolucji wymagań, części kodu źródłowego, przypadków testowych i dostarczanych przez system funkcjonalności. Jest to szczególnie istotne w przypadku systemów wielosystemowych ze względu na opisane poniżej problemy. Problemy z dostępnościa środowiska testowego W przypadku systemów wielosystemowych stworzenie środowiska testowego odzwierciedlajacego środowisko produkcyjne jest zazwyczaj drogie i skomplikowane, a bywa także niemożliwe - chociażby ze względu na innowacyjność stosowanych technologii (patrz 4.1.1), implementowanych w pojedynczych prototypach. W tej

4.2. Inne kwestie zwiazane z testowaniem systemów wielosystemowych 21 sytuacji testy odbywaja się po upływie długiego - w niektórych przypadkach mierzonego w latach [24]- czasu od stworzenia wymagań, w czasie których sposób i cel testowania może się zmienić. Problem z analiza wpływu (impact analysis) wprowadzanych zmian Ilość komponentów systemu wielosystemowego i stopień ich interakcji sprawia, że każda zmiana może mieć skutki w funkcjonowaniu nie tylko zmienianego komponentu, ale też tych współpracujacych z nim bezpośrednio i pośrednio. W tym wypadku spójność pomiarowa służy zapewnieniu możliwości prześledzenia zmian, które moga wpływać na dana funkcjonalność i zapewnieniu, że potencjalne odstępstwa od planu zostana właściwie wykryte i obsłużone. Przepychanie testów na wyższy poziom Biorac pod uwagę, że testowanie systemu wielosystemowego przebiega na wielu poziomach, zarówno w odniesieniu do komponentów jak i całego systemu, istnieje pokusa działania majacego na celu zmianę organizacji odpowiedzialnej za przetestowanie problematycznej funkcjonalności. Jest to wygodne i uzasadnione z punktu widzenia pojedynczych interesariuszy, ale z punktu widzenia całego systemu opóźnia przeprowadzenie testów, a tym samym właściwa ocenę postępu projektu i ryzyka, co może powodować zwiększenie skutków ewentualnych błędów. Kontrola konfiguracji Autorzy [12] [7] zwracaja uwagę na to, że w przypadku systemów systemowych bardzo istotna kwestia jest kontrola konfiguracji. Jest to o tyle istotne, że dotyczy nie tylko komponentów ładowalnych, a więc oprogramowania, ale też komponentów wbudowanych, w których oprogramowanie jest silnie połaczone ze sprzętem na którym pracuje. W takim przypadku należy kontrolować nie tylko wersje poszczególnych systemów i ich ustawienia, ale też nawet sprzęt na którym działaja. W przeciwnym wypadku przeprowadzenie wymaganej kwalifikacji systemu na podstawie raportów z testów może być niemożliwe. 4.2.5. Kwestia weryfikacji i walidacji Istotna częścia procesu zapewnienia jakości (ang. quality assurance - QA) jest kwestia weryfikacji i walidacji wytworzonego produktu. Jest ona podstawa kwalifikacji systemu do użycia, co w przypadku systemów wielosystemowych często wymaga uzyskania aprobaty zewnętrznych organizacji. Weryfikacja - złożoność systemu i procesu Proces weryfikacji służy sprawdzeniu, czy system został wytworzony zgodnie z projektem i z zachowaniem wewnętrznych / zewnętrznych standardów i dobrych praktyk. Jest to możliwe dzięki właściwemu zarzadzaniu wersja, zmianami i konfiguracja w taki sposób, by zapewnić realizację zawartych projekcie systemu założeń oraz umożliwić kontrolę sposobu ich ewoluowania.

4.2. Inne kwestie zwiazane z testowaniem systemów wielosystemowych 22 Walidacja - problem zdefiniowania precyzyjnych i weryfikowalnych wymagań Walidacja polega na sprawdzeniu, czy wytworzony system spełnia wymagania i założenia postawione przez zleceniodawcę. Jest ona zdecydowanie trudniejsza do przeprowadzenia od weryfikacji. W przypadku systemów wielosystemowych kłopotliwe jest nie tylko udokumentowanie sposobu spełnienia i testowania wymagań, ale też fakt, że wiele ich funkcjonalności jest na tyle nowoczesne, że podczas projektowania trudno przestawić wymagania, które będa jednocześnie precyzyjnie opisywały nowa funkcjonalność i dawały się zweryfikować [30] [28]. Złożoność systemu wielosystemowego i opisane wyżej problemy z kontrola konfiguracji i dostępnościa środowiska testowego praktycznie uniemożliwaja przeprowadzenie oddzielnych testów w celu weryfikacji i walidacji systemu, co powoduje, że niezależna weryfikacja i walidacja (ang. verification & validation - V&V) opiera się na dokumentacji powstałej w trakcie procesu wytwarzania.

5. Metody testowania systemów wielosystemowych W pierwszej części tego rozdziału zostanie omówiona metoda testowania opartego na ryzyku (ang. Risk Based Testing), która jest elementem wspólnym praktycznie wszystkich metod i opisów testowania systemów wielosystemowych. W drugiej części rozdziału przedstawione zostana opisane w literaturze metody, które były dotychczas stosowane do testowania systemów wielosystemowych. W trzeciej części opisane zostały studia przypadków (ang. case study), opisujace sposób, wyniki i wnioski płynace ze stosowania różnych metod testowania systów wielosystemowych. 5.1. Risk based testing Testowanie oparte na ryzyku jest pojęciem używanym dość często, jednak nie koniecznie zawsze w tym samym znaczeniu. Opis tej metody w tej pracy zostanie oparty na pracach James a Bach a Heuristic Risk-Based Testing [3] oraz Rex a Black a [5] Managing the Testing Process i Risk-Based Testing: What It Is and How You Can Benefit [6]. Opis metody Stosowanie metody testowania opartego na ryzyku ma zwiększyć jakość oceny poprawności / prawdopodobieństwo znalezienia błędów w funkcjonalnościach, dla których ryzyko wystapienia jest największe, a więc najbardziej dotkliwych. Jest to szczególnie istotne biorać pod uwagę fakt, że w większości przypadków pełne testowanie nie jest możliwe nie tylko w praktyce, ze względu na ograniczenia zasobów i czasu, ale nawet w teorii, ze względu na złożoność testowanych produktów. W tej sytuacji zgodne z intuicja jest założenie, że najistotniejsze jest znalezienie problemów, które moga przynieść największe straty. Rex Black [6] definiuje ryzyko jako prawdopodobieństwo negatywnego lub nieporzadnego zdarzenia lub wyniku, zaś ryzyko dla jakości - na którym opiera się cała metoda - jako możliwość nie spełnienia przez produkt kluczowych wymagań dotyczacych jakości. Ocena ryzyka dla jakości polega w tym przypadku na zbadaniu i sklasyfikowaniu dwóch czynników: prawodopodobieństwa wystapienia i wpływu. To właśnie te dwa czynniki sa podstawa decyzji co i jak dokladnie testować. Metoda Risk Based Testing zakłada udział w procesie przygotowania testów nie tylko testerów i członków zespółów technologicznych, ale także najważniejszych interesariuszy - członków kierownictwa projektu, zarzadu, użytkowników i przedstawicieli działów wspierajacych. Ich obecność jest szczególnie istotna dla właściwej ocen ryzyk nie zwiazanych bezpośrednio z cechami technicznymi systemu.

5.1. Risk based testing 24 Analiza ta może przebiegać na dwa sposoby, w podejściu inside-out (ang. od wewnatrz do zewnatrz) i outside-in (ang. od zewnatrz do wewnatrz). Sa to podejścia komplementarne, moga ( i powinny ) być używane jednocześnie. Inside-out Podejście inside-out polega w ogólności na analizie poszczególnych komponentów systemu i ocenie powodowanych przez nie ryzyk. Bach sugeruje przyjrzenie się trzem kryteriom: Słabości (ang. vulnerabilities) - jakie błędy / niedoskonałości moga być zawarte w komponencie Zagrożenia (ang. threats) - jakie sytuacje / kombinacje wejść moga być powodem wystapienia błędów Ofiary (ang. victims) - kto lub co i jak poważnie zostanie dotknięty w razie niepowodzenia. Podejście inside-out wymaga dobrej znajomości budowanego systemu, a więc w większości przypadków ścisłej współpracy z osobami odpowiedzialnymi za jego wytwarzanie. Outside-in Podejście outside-in polega na analizie zagrożeń dla jakości w konkretnym projekcie lub zastosowaniu listy znanych ryzyk do znalezienia komponentów, które moga stanowić źródło problemów. Bach podaje trzy typy list ryzyk stosowanych przy tego typu analizie: Kategorie jakości Podana w [3] lista jest bardzo rozbudowana, inspiracja dla jej stworzenia były (między innymi) mniej skomplikowane FURPS i norma ISO 9126 [14] Lista typowych ryzyk (ang. Generic risk list) Zawierajaca typy ryzyk charakterystycznych dla projektów informatycznych Katalogi ryzyka Zawierajaca typy ryzyk występujace przy projektach z określonej dziedziny Na podstawie wyników analizy można stworzyć listę ryzyk dla jakości uszeregowana względem prawdopodobieństwa ich wystapienia i wpływu. Dostarcza ona informacji o tym, co, w jakiej kolejności i jak długo należy testować. Lista taka umożliwia też analizę wyników już dokonanych testów w kontekście weryfikacji ryzyka zwiazanego z poszczególnymi komponentami. Organizacja testowania opartego na ryzyku W tej części pracy zostanie przedstawiony przykładowy przebieg testowania opartego na ryzyku opisany przez Rex a Black a w pracy Managing the Testing Process. Analiza i klasyfikacja ryzyk dokonywana przed rozpoczęciem testowania może być oparta na metodzie FURPS: Functionality - funkcjonalność Usability - użyteczność Reliability - niezawodność Performance - wydajność Safety - bezpieczeństwo lub innych, szerszych klasyfikacjach, takich jak zawarta w normie ISO 9126 czy proponowana przez Bacha. Po stworzeniu katalogu ryzyk należy ocenic prawdopodobieństwo ich wystapie- nia i wpływ (w klasycznym ujęciu tożsamy z kosztem, alternatywny sposób oceny

5.1. Risk based testing 25 skutków błędu zostanie przedstawiony w następnym rozdziale) w jednolitej i precyzyjnie zdefiniowanej skali. Black proponuje użycie skali od 1 do 5, dla prawdopodobienstwa: 1. Bardzo prawdopodobne 2. Prawdopodobne 3. Możliwe 4. Mało prawdopodobne 5. Nie prawdopodobne oraz dla wpływu: 1. Trzeba naprawić od razu 2. Naprawić w pierwszej kolejności 3. Należy naprawić 4. Można naprawić 5. Nie trzeba naprawiać Bach zaś sugeruje, że skala może być dowolna, najistotniejsze jest precyzyjne i zrozumiałe dla wszystkich zdefiniowanie różnic pomiędzy kolejnymi stopniami, a ich ilość i sposób wzrostu (liniowe, geometryczne, Fibonacciego) jest sprawa mniej istotna. Przykładem zastosowania innej, 3 stopniowej skali jest tzw. stoplight taxonomy, opisana przez Sledge (patrz 5.3.2) Po wymnożeniu obydwu miar przypisanych konkretnemu ryzyku otrzymujemy jego priorytet, który będzie podstawa decyzji dotyczacych przebiegu procesu testowania. Black zauważa w swojej pracy, że przed stworzeniem planu testów warto sprawdzić, czy przypisane priorytety maja właściwy (zbliżony dla normalnego) rozkład, w przeciwnym wypadku może zachodzić konieczność sprecyzowania lub przedefiniowania podanych wyżej miar. Wymnażajac miary prawdopodobieństwa i wpływu otrzymujemy wartość w przedziale [1;25], opisujac a priorytet przypisany danemu ryzyku. Black proponuje następujace przypisanie przedziałów priorytetu i odpowiadajacych im nakładów testowych: 1-12 Znaczny - należy wykonać wiele testów badajacych dane zagadnienie zarówno wszerz, jak i w głab 13-16 Szeroki - należy wykonać wiele testów sprawdzajacych różnorodne interesujace przypadki 17-20 Powierzchowny - należy wykonać niewiele testów badajacych najbardziej interesujace przypadki 21-25 Okazyjny - przy okazji innych testów lub jeśli będzie taka możliwość można wykonać 1-2 testy sprawdzajace najbardziej interesujacy przypadek Na podstawie ryzyk ocenionych według powyższej metody można stworzyć plan testów, a także dokument umożliwiajacy powiazanie wykonywanych testów z weryfikowanymi ryzykami oraz funkcjonalnościami i wymaganiami, w których moga one wystapić. Podsumowanie Rex Black w swojej pracy podaje kilka korzyści płynacych ze stosowania metody Risk-based testing. Pierwsza z nich jest możliwość efektywnego przydzielenia wysiłków testowych, uwzględniajacego ograniczenia budżetowe i czasowe w taki sposób, by przetestowane zostały najistotniejsze z punktu widzenia ryzyka funkcjonalności.

5.2. Metody testowania 26 Druga korzyścia jest możliwość znalezienia najpoważniejszych błędów i zagrożeń najwcześniej jak to możliwe, co pozwala na dokonanie największych niezbędnych zmian i poprawek na względnie wczesnym etapie wytwarzania. Trzecia z korzyści jest możliwość elastycznej reakcji na ograniczenie czasu i zasobów przeznaczonych na testowanie tak, aby zapewnić zweryfikowanie poprawności możliwie największej liczby istotnych wymagań. Ostatnia i najistotniejsza z korzyści jest możliwość optymalizacji jakości, czyli zapewniania możliwie największej satysfakcji klienta przy założonym zakresie testowania. Pewna komplikacja, stanowiac a jednak o sile metody Risk Based Testing jest konieczność udziału w przygotowaniach do testowania wielu osób reprezentuja- cych różne grupy zainteresowane projektem. Zważywszy na to, że taka współpraca jest istotna częścia tworzenia wymagań systemowych zarówno w omawianych w tej pracy metodach, jak i większości współczesnych metodologii wytwarzania projektów (np. poprzez proces porzadkowania wymagań czy udział testerów biznesowych) oraz biorac pod uwagę korzyści płynace ze stosowania metody testowania opartego na ryzyku wydaje się, że dodatkowy wysiłek przy planowaniu testów jest uzasadniony. 5.2. Metody testowania Wśród dostępnych prac zawierajacych metody testowania systemów wielosystemowych większość dotyczy systemów wytwarzanych przez departament obrony USA lub na jego zamówienie. Obowiazuj acym w nim framework iem architekturalnym jest C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance - Dowodzenie, Kontrola, Komunikacja, Komputery, Wywiad, Inwigilacja i Rekonensans ) Architecture Framework, obecnie znany jako DoDAF (Department of Defense Architecture Framework). W pracy System of systems integration and test [7], opisujacej system wielosystemowy wytwarzany przez przedsiębiorstwo Lockheed Martin stosowano inny framework - CPIV&VTP (Cross-program Independent Verification & Validation Test Process). Podobnie jak w przypadku DoDAF, proces testowania jest w nim ściśle powiazany z procesem integracji systemu wielosystemowego. 5.2.1. C4ISR / DODAF Pierwotnie model organizacji architektury obowiazuj acy w Departamencie Obrony USA był nazywany C4ISR, jednak po opublikowaniu jego drugiej wersji w 1997 kolejne wydanie, majace miejsce w roku 2003, nosiło już nazwę DoDAF. Aktualnie dostępna jest już kolejna wersja DoDAF u oznaczona numerem 2.0. CTM - opis metody Podstawowa metoda testowania systemów wielosytemowych używana przy projektach realizowanych przy pomocy DoDAF jest Metodologia Testów Zdolności (ang. Capability Test Methodology), która została opisana na podstawie oficjalnej dokumentacji [2]. Faza 1 - Stworzenie strategii testów i oceny Faza pierwsza ma na celu wytworzenie dwóch głównych produktów: dokumentu strategii testów i Zintegrowanego Kontekstu Operacyjnego dla Testów (ang. Joint Operational Context for Test -

5.2. Metody testowania 27 JOC-T). Strategia testów definiuje sposób, w jaki zostanie określone to, czy system i jego zdolności spełniaja postawione im wymagania, zaś JOC-T specyfikuje środowisko, w jakim system lub jego określona zdolność będzie funkcjonowała, a więc także będzie testowana. Faza 2 - charakterystyka Jest to faza w której zarzadcy projektu wraz z zespołem testowym uszczegóławiaja strategię testów, identyfikujac zdolności podlegajace testowaniu, wymagane zasoby i tworzac harmonogram testów. Trzy główne zadania w tej fazie to: Stworzenie ogólnej koncepcji testów Określenie celu testowania i szczegółowych zadań Uszczegółowienie strategii oceny Ocena technologiczna Ocena wymagań powstałych w poprzednich krokach powinna prowadzić do stworzenia dokumentu opisujacego środowisko testowe oznaczane skrótem LVC-DE (ang. Live Virtual and Construction Distributed Environment) Faza 3 - planowanie W tej fazie na podstawie wytworzonych wcześniej dokumentów powstaje formalny plan testów. Pierwszym etapem tej fazy jest rozwój Projektu Testów (ang. Test Design) - polega na stworzeniu Planu Analizy Danych ( ang. Data Analysis Plan) i Zintegrowanej Listy Wymagań (ang. Integrated Data Requirements List). Wytwarzanie DAP wymaga przeanalizowania produktów poprzednich faz w celu opracowania projektu testów poszczególnych zdolności. Podczas tego procesu analitycy powinni stworzyć i uaktualniać IDRL oraz dopracowywać szczegóły wymagań dotyczacych zbieranych danych, które będa stanowiły podstawę dokumentu DCP (ang. Data Collection Plan - plan gromadzenia danych). Ostatecznie dokument DAP powinien specyfikować metody i procesy niezbędne do zbierania danych testowych i dostarczania na ich podstawie ilościowych i jakościowych wyników testów. Drugim etapem fazy planowania jest przeprowadzenie analizy wymagań i stworzenie dokumentacji funkcjonalnej dla środowiska testowego LVC-DE. Trzecim, końcowym etapem jest stworzenie planu testów zawierajacego: Dane zgromadzone w DAP Spis parametrów funkcjonalnych Projekt funkcjonalny LVC-DP Analizę procesów wspierajacych testowanie Harmonogram testów Faza 4- Stworzenie środowiska testowego Faza piata zakłada stworzenie środowiska testowego LVC-DE składajacego się z komponentów produkcyjnych (Live), stworzonych specjalnie na potrzeby testów (Construction) i wirtualnych (Virtual), umożliwajacych testowanie w środowisku odwierciedlajacym warunki operacyjne systemu wielosystemowego, a więc rozproszonym (Distributed Environment). Wytwarzanie opiera się na trzech głównych czynnościach: Pierwsza z nich jest stworzenie projektu LVC-DE, specyfikujacego wymagania wobec środowiska testowego które umożliwi przetestowanie systemu z uwzględnieniem parametrów funkcjonalnych zawartych w planie testów.

5.2. Metody testowania 28 Druga z nich jest fizyczne wytworzenie komponentów środowiska testowego, z użyciem zweryfikowanego i zwalidowanego projektu LVC-DE. Trzecia z nich jest integracja komponentów środowiska testowego (sprzętu, oprogramowania, baz danych i sieci) i przetestowania ich w celu sprawdzenia, czy spełniaja założone wymogi i sa zgodne z kryteriami wejścia procesu testowania. Faza 5- Zarzadzanie wykonaniem testów W tej fazie zespół odpowiadajacy za testowanie systemu wielosystemowego powinien skupić się na analizie postępów procesu testowego realizowanego przez zespoły testowe poszczególnych wytwórców. Głównym zadaniami sa tu kontrola raportów testów, reagowanie na nieprzewidziane zdarzenia i zapewnienie, że poszczególne zespoły pracuja zgodnie z planem i (tam gdzie to potrzebne) w sposób zsynchronizowany. Ważne jest też zapewnienie, żeby kolejne aktywności testowe rozpoczęły się dopiero po zakończeniu się poprzedzajacych działań i ich ocenie według wcześniej zdefiniowanych kryteriów. Faza 6- Ocena zdolności systemu Jest to ostatnia faza testowania, która jest podstawa procesu weryfikacji i walidacji. Polega ona na analizie zgromadzonych danych, wyników testów i zademonstrowanych zdolności w celu ocenienia wydajności systemu wielosystemowego i jego pojedynczych funkcjonalności oraz zależności między zaobserwowana wydajnościa a miarami efektywności działania. Faza ta często ma przebieg iteracyjny, poszczególne analizy sa powtarzane w zależności od tego, jaka część systemu wielosystemowego / cecha / zadanie jest aktualnie rozpatrywane. Pierwszym etapem oceny zdolności systemu jest analiza danych. Polega ona na przekształceniu danych testowych na informację o tym, co i dlaczego wydarzyło się podczas testów. Dane ilościowe i jakościowe zebrane podczas testowania umożliwiaja porównanie efektywności działania testowanego systemu z miarami wydajności dotyczacymi atrybutów i zadań systemu wielosystemowego. Dane zgromadzone podczas różnych etapów i typów testów sa także analizowane statystycznie w celu potwierdzenia istotności wpływu testowanych funkcjonalności na realizowane przez nie zdolności systemu wielosystemowego, a także w poszukiwaniu nowych wyników, które wystapiły podczas testowania. Drugim etapem oceny zdolności systemu jest wykorzystanie wyników analizy danych do oceny, czy i jak dobrze testowany system spełnia stawiane mu wymagania. Jest to podstawa formalnych rekomendacji dostarczanych komitetowi sterujacemu przez zespół testowy, a w konsekwencji decyzji dotyczacych dalszego przebiegu procesu wytwarzania. 5.2.2. Cross program approach Opis metody Autorzy metody Cross Program Approach (CPA), Roland Brooks i Andrew Sage [7] zakładaja, że kluczem do skutecznego działania systemu wielosystemowego jest zapewnienie współdziałania (ang. interoperability) podsystemów będacych jego komponentami. Współdziałanie jest tu rozumiane jako zdolność systemu do poprawnej wymiany danych z innymi systemami poprzez wzajemnie wspierajace zachowania (ang. mutually supportive actions), wymianę pożytecznych informacji i wiedzy w celu osia- gnięcia prawidłowej wydajności operacyjnej.

5.2. Metody testowania 29 Współdziałanie nie oznacza przy tym, że interfejs użytkownika musi być identyczny dla wszystkich systemów, powinien raczej być dostosowany do konkretnego zadania i preferencji ( język, kultura) jego operatorów. Planowanie Autorzy pracy sugeruja użycie przy planowaniu metody Planowania opartego na Zdolnościach (ang. Capability Based Planning - CBP), skupiajacej się na analizie obecnych i przyszłych braków w funkcjonalnościach planowanego systemu. Opiera się ona na podejściu top-down, a więc na przechodzeniu od ogólnych założeń wobec możliwości systemu do ich szczegółowej implementacji. Takie podejście umożliwia efektywna współpracę wielu organizacji, wykorzystujac ich specyficzna wiedzę i doswiadczenie do realizacji poszczególnych zadań. Specyfikacja wymagań Tak jak zostało to opisane w rodziale dotyczacym weryfikacji i walidacji (4.2.5), jednym z najistotniejszych wyzwań stojacych przed projektantami systemu wielosystemowego jest właściwa analiza zdolności systemu i stworzenie odpowiednich wymagań. Brooks i Sage stwierdzaja, że dobrze stworzone wymagania systemu wielosystemowego musza: 1. Umożliwiać wydajna i szybka implementację systemu w najczęściej stosowanych metodykach ewolucyjnych i spiralnych 2. Specyfikować odpowiednie miary wydajności umożliwiajace testowanie i weryfikację postępu projektu 3. Zawierać minimalne ograniczenia (spełniane standardy, wymagania architekturalne) i zachowania umożliwiajace skuteczna integrację, współpracę i zarzadza- nie konfiguracja Testowanie Podstawa przeprowadzenia procestu testowania systemu wielosystemowego jest według Brooks a i Sage a Zintegrowany Plan Weryfikacji i Walidacji, który powinien zawierać następujace sekcje: 1. Strategia testowania 2. Role i odpowiedzialności 3. Harmonogram 4. Plan koordynacji 5. Cele 6. Wymagania 7. Kryteria wejścia i wyjścia 8. Opis scenariuszy testowych Widoczne jest tutaj podobieństwo do planu testów sugerowanego przez normę IEEE 829 (patrz 2.2.3). Proces testowania proponowany przez autorów metody CPA został przedstawiony na diagramie 5.1.

5.2. Metody testowania 30 Rysunek 5.1: Proces testowania systemu wielosystemowego Źródło: Opracowanie własne na podstawie [7] Brooks i Sage podzielili aktywności zwiazane z testowaniem na cztery główne fazy, różniace się zarówno poziomem przeprowadzanych testów, jak i ich celem. Faza testowania komponentów Pierwsza z proponowanych faz jest faza testowania komponentów, obejmujaca całościowy proces testowania (patrz 2.2.3) podsystemów implementowanych od zera. W przypadku systemów, które sa dostosowywane do działania w nowym środowisku powinny zostać przeprowadzone testy regresji, wskazana jest także weryfikacja kluczowych parametrów wydajnościowych już istniejacych systemów. Wczesne Testowanie Interfejsów Jest to faza testów, której głównym zadaniem jest dostarczenie informacji o kompatybilności systemów komponentowych tak szybko, jak to możliwe. Nie musi ona przebiegać w sposób ściśle sformalizowany ze względu na brak powiazania z ostateczna kwalifikacja systemu, istotniejsza jest raczej szybkość identyfikacji potencjalnych zagrożeń i możliwość dostosowania do nich procesu wytwórczego. Faza Wczesnego Testowania Interfejsów wymaga ścisłej współpracy zespołu odpowiadajacego za testowanie systemu wielosystemowego z zespołami wytwórczymi. Oprócz możliwości kontrolowania postępu prac i poziomu realizacji wymagań taka kooperacja umożliwia też między innymi weryfikację poprawności projektu, wyspecyfikowanie środowiska testowego dla testów międzyprogramowych czy też znalezienie odpowiednich metod weryfikacji i walidacji poszczególnych zdolności. Dodatkowym aspektem współpracy testerów systemu wielosystemowego z poszczególnymi dostawcami jest możliwość właściwej oceny przez ciało nadzorujace

5.2. Metody testowania 31 powstawanie systemowego przyczyn, potencjalnych ryzyk i odpowiedzialności za ewentualne niepowodzenia w dostarczeniu wymaganych zdolności. Testy międzyprogramowe Testy międzyprogramowe sa formalna faza testów, stanowiac a podstawę procesów weryfikacji a także kwalifikacji systemu wielosystemowego. Podstawa testowania sa Dokumenty Kontroli Interfejsów (ang. Interface Control Document) i Specyfikacje Wymagań wobec Interfejsów ( ang. Interface Requirement Specification) stworzone podczas fazy projektowania systemu. Testy międzyprogramowe opieraja się głównie na sprawdzeniu zgodności interfejsów z Dokumentami Kontroli Interfejsów oraz na zapewnieniu, że zdolności realizowane dzięki współpracy komponentów funkcjonuja we właściwy sposób. Każde testy rozpoczynane sa od przegladu gotowości do testów, który musi uwzględniać nie tylko stan oprogramowania podlegajacego testowi, ale też zgodność architektury i konfiguracji z założonymi standardami. Testowaniu podlegaja zarówno same funkcjonalności interfejsów, jak też ich zgodność z wyspecyfikowanymi wcześniej miarami wydajności. Wynikiem testowania interfejsów jest nie tylko ocena jakości ich wykonania, ale też formalna decyzja o gotowości do integracji współpracujacych systemów. W przypadku wystapienia błędów konieczne jest stworzenie raportu niezgodności, który umożliwi ocenę zwiazanego z nimi ryzyka i będzie podstawa oceny przyczyn i odpowiedzialności za wystapienie niezgodności. Testy oparte na zdolnościach Jest to ostatnia faza testów systemu wielosystemowego, której głównym celem jest walidacja całości systemu wielosystemowego poprzez sprawdzenie jego poszczególnych zdolności. Polega ona na wykonaniu zaplanowanych wcześniej w procesie Planowania opartego na Zdolnościach scenariuszy sprawdzajacych implementację zdolności systemu w podejściu end-to-end. Oprócz wymagań funkcjonalnych sprawdzane sa też wymagania niefunkcjonalne, takie jak użyteczność dla użytkownika końcowego, zarzadzalność, wspieralność czy wydajność w środowisku produkcyjnym. Zarzadzanie wymaganiami W celu zapewnienia właściwego zarzadzania wymaganiami autorzy pracy proponuja stosowanie trzech uzupełniajacych metod, które zostały opisane poniżej. Top down Zarzadzanie w trybie top down umożliwia sprawowanie kontroli nad wymaganiami w stosunku do całości systemu wielosystemowego i wymaganiami w stosunku do jego komponentów. Takie podejście zapewnia też spójność pomiarowa pomiędzy ogólnymi możliwościami systemu a konkretnymi wymaganiami zapewniajacymi ich realizację, co pozwala zintegrować, przetestować i uruchomić dana funkcjonalność, kiedy wszystkie jej wymagania zostana spełnione. Horizontal threads-based Oparte na watkach podejście horyzontalne umożliwia powiazanie występujacych we systemach komponentowych funkcji oraz zachodza- cymi między nimi procesów wymiany informacji z wymaganiami dotyczacymi funkcjonalności i integracji. Odpowiednia alokacja wymagań do poszególnych watków umożliwia zawarcie w dokumentacji testowej odpowiednich informacji dotyczacych architektury i współpracy komponentów w celu dostarczenia wymaganych zdolności. Dzięki takiemu podejściu możliwe jest realizowanie jednego z najistotniejszych

5.3. Case studies 32 postulatów Brooks a i Sage a, Wczesnego Testowania Interfejsów (ang. Early Interface Testing). Reenigneering Oparta na podejściu bottom-up koncepcja zmian w zdolnościach operacyjnych (ang. operational capability reengineering) ma na celu zapewnienie, że wszelkie zmiany wymaganych od systemu zdolności znajda swoje odbicie w procesach wytwarzania i testowania. W tym celu autorzy proponuja rozpoczęcie dostosowania do nowych wymagań od najniższych poziomów struktury organizacyjnej tak, aby zapewnić, że zmiany zdolności znajda faktyczne odbicie w wytworzonym produkcie, a nie tylko dotyczacej go dokumentacji. Weryfikacja i walidacja Weryfikacja W tej fazie celem jest sprawdzenie zgodności wytworzonego systemu ze specyfikacja, oraz ocena poprawności dostarczanych przezeń zdolności w środowisku operacyjnym. Istotne jest też sprawdzenie, czy spełniane sa założone podczas projektowania Kluczowe Parametry Wydajnościowe ( ang. Key Performance Parameters) oraz wymagania dotyczace funkcjonowania aplikacji w środowisku produkcyjnym ( np. stabilność, odporność na przeciażenia ). Proces weryfikacji systemu wielosystemowego wymaga współpracy zespołu testujacego całość systemu z przedstawicielami zespołów wytwórczych, w czym pomocne jest doświadczenie zdobyte w fazie Wczesnego Testowania Interfejsów. Współpraca jest niezbędna w celu właściwego przygotowania testowanych komponentów, kontroli przepływu danych i weryfikacji poprawności działania w punktach integracji i interakcji z użytkownikiem. Walidacja Pierwszym celem walidacji jest zweryfikowanie, czy system wielosystemowy spełnia wymagania użytkownika i dostarcza wymaganych zdolności w środowisku operacyjnym. Dodatkowo często przeprowadzane sa porównania wydajnościowe z wycofanymi już systemami. Wymagania niefunkcjonalne definiowane w Zintegrowanym Planie Możliwości ( ang. Integrated Capability Plan) obejmuja między innymi obsługiwalność (ang. maintainability), wspieralność (ang. supportability) czy możliwość poprawnego zarzadzania systemem przy użyciu dostarczonych dokumentacji i podręczników użytkownika. Weryfikacja tych wymagań pozwala zrealizować pozostałe cele walidacji zdefiniowane przez Brooksa i Sage a, czyli efektywność użytkowania systemu przed odbiorców końcowych w oparciu o dostępna dokumentacja i możliwość właściwego wspierania i zarzadzania systemem. 5.3. Case studies W tym rozdziale zostana zaprezentowane prace, które zawieraja praktyczne informacje na temat testowania systemów wielosystemowych. 5.3.1. Krygiel - Behind the Wizard s Curtain Testowane systemy Ksi ażka Behind the Wizard s Curtain [20] zawiera opis wytwarzania, integracji i testowania dwóch systemów:

5.3. Case studies 33 1. Task Force XXI - zintegrowanego systemu zarzadzania jednostkami piechoty, wykorzystujacego różnorodne formy komunikacji i kontroli pola walki 2. Digital Production System - systemu, który miał za zadanie digitalizację materiałów MC&G ( obecnie określanych mianem Geospatial Information and Services - Informacji i Serwisów Geoprzestrzennych) zgromadzonych przez największa agencję kartograficzna świata, Defense Mapping Agency (obecnie National Geospatial-Intelligence Agency). Oba systemy były wytwarzane według wytycznych Departamentu Obrony, a więc z użyciem metodyki C4ISR. Wnioski dotyczace testowania Krygiel w swej pracy skupia się na procesie integracji systemu wielosystemowego, jednak we wnioskach przedstawia też kilka zaleceń dotyczacych testowania. Pierwszym z nich jest sformułowanie i zaakceptowanie przez wszystkie zainteresowane strony planu i procesu testów, który uzwględnia zidentyfikowane i uzgodnione podczas projektowania i wytwarzania ryzyka. Jest to podstawa do przeprowadzenia testów i oceny znaczenia ich wyników. Biorac pod uwagę, że oba systemy były testowane w dużej mierze przez ich operatorów, reprezentujacych różne organizacje o niekoniecznie zgodnych celach istotne jest wcześniejsze uzgodnienie i akceptacja scenariuszy testowych i sposobu intepretacji ich wyników. Drugim zaleceniem jest dobór scenariuszy testowych w taki sposób, by były one reprezentatywne dla wymagań funkcjonalnych stawianych przed produkcyjnym systemem. Zalecenie takie nie jest szczególnie zaskakujace, jednak zwłaszcza w przypadku systemu Task Force XXI, którego testy polegały na wykonaniu ćwiczeń na polu walki i scenariuszy bojowych dobór testowanych zagadnień stanowił duży problem. Po zakończeniu testowania i integracji w przypadku obu systemów pojawiły się problemy dotyczace zagadnień, które zostały uznane za niewymagajace testowania. Rozwiazaniem problemu doboru testowanych funkcjonalności może być metoda Risk Based Testing, opisana w pierwszej części tego rozdziału (patrz 5.1). Trzecim zaleceniem Krygiel jest użycie w procesie testowania produkcyjnego systemu wielosystemowego lub jego wierniej kopii, tak jak miało to miejsce w przypadku DPS. Jest to o tyle istotne, że oba testowane systemy ( w przeciwieństwie np. do systemów kontroli pocisków / pojazdów) charakteryzowały się duża intensywnościa pracy operatorów. W takim wypadku ważne jest, by operatorzy mieli do czynienia z taka wersja systemu / interfejsu, jaka będzie używana produkcyjnie. Krygiel zauważa też, że symulowanie niedostępnych komponentów (zazwyczaj za pomoca uproszczonych modeli) oprócz oczywistego problemu jakości odwzorowania wprowadzało też dodatkowe problemy zwiazane bezpośrednio z funkcjonowaniem symulatorów, co dodatkowo utrudniało testowanie. We wnioskach z testowania nie została bezpośrednio zawarta informacja, że wiele interfejsów była testowana w sposób nieformalny długo przed rozpoczęciem fazy integracji. W opisie procesu wytwarzania Krygiel podkreśla jednak, że miało to pozytywny wpływ na proces wytwarzania systemu. Widoczne jest tu podobieństwo do fazy Wczesnego Testowania Interfejsów opisanej w metodzie Cross Program Approach.

5.3. Case studies 34 5.3.2. Sledge - Army ASSIP System-of-Systems Test Metrics Task Kolejna praca dotyczac a tematu testowania systemów wielosystemowych jest publikacja Carol H. Sledge z 2006 roku. Dotyczy ona metryk używanych w procesie integracji i testowania systemów wielosystemowych, ale zawiera też szereg rekomendacji dotyczacych tych procesów. Praca powstała na podstawie analizy sposobu powstawania i współpracy z wytwórcami i zarzadzaj acymi systemem Warfighter. Te, które można odnieść do ogólnego procesu testowania systemów wielosystemowych zostały opisane poniżej. Wnioski dotyczace testowania Rekomendacja 1 Sledge sugeruje, że w celu właściwego nadzorowania postępów pracy nad systemem wielosystemowym należy ustanowić obejmujacy całość zespół zajmujacy się kierowaniem systemem wielosystemowym (ang. overarching SoS executive). Ma to spowodować stworzenie jasnej wizji systemu wielosystemowego jako całości, co ułatwia podejmowanie decyzji właściwych z punktu widzenia pełnego projektu oraz umozliwia właściwy podział, a co za tym idzie finansowanie podejmowanych działań. Stworzenie takiego kierownictwa może pozwolić uniknać opisanych wcześniej problemów organizacyjnych, charakterystycznych dla systemów wielosystemowych. Ułatwia też zachowanie niezależności zespołu odpowiedzialnego za testowanie całości systemu wielosystemowego. Rekomendacja 2 W drugiej rekomendacji Sledge podkreśla znaczenie właściwego zdefiniowania zdolności systemu wielosystemowego oraz stworzenia formalnego planu testów umożliwiajacego ich weryfikację (patrz 4.2.5). Autor podkreśla przy tym konieczność większego niż wcześniej (w odniesieniu do systemu Warfighter XXI) udziału użytkowników końcowych (ang. end users) w procesie definiowania zdolności, które powinny zostać zawarte w Dokumencie Wstępnych Zdolności (ang. Initial Capabilities Document - ICD). Sledge postuluje też stworzenie na podstawie ICD formalnego planu testów systemu wielosystemowego, którego brak skutkował według niego: Brakiem zrozumienia sposobu testowania poszczególnych wymagań przez ogół odpowiedzialnych za testowanie Problemami w stworzeniu środowiska testowego odpowiedniego do weryfikacji i walidacji wymagań, a przy tym odzwierciedlajacego środowisko produkcyjne Testowaniem tyle ile zdażymy czyli dopóki nie nadejdzie deadline, zamiast aż produkt będzie wystarczajaco dobry Brakiem zrozumienia pojęcia wystarczajaco dobry, a co za tym idzie kryteriów gotowości systemu do wdrożenia Sledge sugeruje, że Formalny Plan Testów systemu wielosystemowego powinien zawierać: Opis przygotowania środowiska testowego Opis scenariuszy testowych, ich wymagań i powiazań z testowanymi zdolnościami systemu Oczekiwanych wartości wyjściowych Czasu planowanego na wykonanie poszczególnych przypadków testowych Sposób kategoryzacji, dokumentacji, przypisywania i komunikowania defektów

5.3. Case studies 35 Rekomendacja 3 Trzecia rekomendacja podkreśla znaczenie działań majacych na celu integrację i testowanie nowo powstajacych systemów / interfejsów jeszcze przed rozpoczęciem właściwej fazy testów systemu wielosystemowego (jak w metodzie CTM - patrz 5.2.2). Umożliwia to weryfikację spełnienia przez poszczególne komponenty często zmieniajacych się wymagań wobec ich roli w systemie wielosystemowym, dostarcza informacji na temat poziomu ryzyka, a weryfikacja protokołów z nieformalnej fazy testów może stanowić formę testów dymnych (ang. smoke test), kwalifikujacych dany produkt do rozpoczęcia formalnego testowania. Takie podejście umożliwia zarówno redukcję / właściwa alokację kosztów procesu testowego, jak i skrócenie czasu potrzebnego na naprawę ewentualnych usterek. Rekomendacja 4 Czwarta rekomendacja jest stworzenie centralnego systemu zarzadzania defektami, wspólnego zarówno dla całości systemu wielosystemowego jak i poszczególnych podsystemów. Oprócz pełnej kontroli nad ilościa i poważnościa defektów umożliwia to właściwe ustalenie, wyliczanie i modyfikowanie metryk i miar opisujacych proces testowania. Stworzenie takiego systemu jest powszechna praktyka w wytwarzaniu oprogramowania, jednak według Sledge doświadczenia zdobyte podczas wytwarzania systemu Warfighter XXI wskazuja na dwa pola, na których powinna nastapić poprawa. Po pierwsze, większość defektów była zgłaszana w odniesieniu do systemów komponentowych, jednak bez właściwego powiazania ich z wymaganiami w stosunku do całości systemu wielosystemowego. W tej sytuacji zarzadzaj acy całościa procesu wytwarzania mieli dużo gorszy przeglad sytuacji, muszac samemu analizować skutki defektów dla systemu wielosystemowego. Po drugie, defekty powinny obowiazkowo zawierać informacje dotyczace sposobu kontaktu z osobami i organizacjami do których sa przypisane i których moga dotyczyć, co powinno umożliwić efektywna komunikację. Rekomendacja 5 Połaczenie sugestii zawartych w rekomendacji 3 i 4 umożliwia stworzenie i egzekwowanie minimalnych wymagań wobec każdego systemu dostarczanego do formalnego środowiska integracji i testów. Negatywnymi skutkami braku takich wymagań sa: Brak możliwości stabilizacji testowanego produktu, a co za tym idzie precyzyjnego określenia wersji testowanych komponentów Duży wysiłek poświęcony na instalację i testy regresji poprawek ( przy dostarczaniu ich na bieżaco) Ogólne zmniejszenie wydajności zespołu testowego i innych osób bioracych udział w testach Straty ponoszone przez wszystkie organizacje, nawet jeśli zawiniła tylko jedna z nich Rekomendacja 7 Rekomendacja 7 dotyczy sposobu prezentacji wyników otrzymanych podczas testowania systemu. Sledge zaleca przy tym wyliczanie zarówno metryk postępu testów, jak i metryk jakości ( ang. goodness) przetestowanej cześci

5.3. Case studies 36 systemu. Dane te powinny być podstawa ewentualnych zmian w procesie testowym, np. decyzji o rozmiarze watków testowych czy ograniczeniu / rozszerzeniu zakresu testowania określonej funkcjonalności. Rekomendacja 8 Należy zdefiniować spójne i zrozumiałe kategorie błędów, które będa stosowane na wszystkich poziomach ich rejestrowania. Sledge podaje przykład tzn. metody sygnalizatora ( ang. stoplight taxonomy), w której do oznaczania błędów używa się trzech kolorów: zielonego, żółtego i czerwonego, będacej odpowiednikiem klasycznej 3 stopniowej skali wagi błędów. Oprócz ustalenia, jaki typ błędu jest klasyfikowany pod jakim kolorem należy też ustalić, jak kolor poszczególnych błędów wpływa na status całego watku testowego oraz jak kolor watku testowego wpływa na kolor testowanej przez niego zdolności SW. 5.3.3. Brooks i Sage - System of systems integration and test Brooks i Sage w swojej pracy [7] oprócz metody testowania Cross Program Approach prezentuja też przypadek jej zastosowania do implementacji i testowania systemu wielosystemowego (którego nazwa nie została jawnie podana). Był on wytwarzany w metodyce spiralnej przez niezależnych podwykonawców, zaś integracja i testowaniem na zlecenie Departamentu Obrony USA zajmowała się firma Lockheed Martin, nie powiazana z żadnym z dostawców. Ze względu na skalę i specyfikę systemu większość projektów implementacyjnych musiało spełnić wymagania formalne specyficzne dla projektów klasy Major Defense Acquisition Programs, co stanowiło dodatkowe wyzwanie dla procesu testowania. Autorzy pracy przy analizie skuteczności metody CPA używali framework u zaproponowanego w pracy Case Studies of Systems Engineering and Management in Systems Acquisition autorstwa Friedman a i Sage a. Umożliwił on nie tylko spójna i efektywna interpretację zgromadzonych danych, ale też właściwa analizę podziału obowiazków między trzy główne domeny odpowiedzialności: Odpowiedzialność wytwórców Odpowiedzialność głównego integratora (Lockheed Martin) i właściciela (Departamentu Obrony) Odpowiedzialność właściciela Wnioski dotyczace testowania Brooks i Sage przedstawili w swojej pracy 8 sugestii dotyczacych testowania i integracji systemów wielosystemowych, podażaj ac za podziałem zawartym w używanym przez nich framework u. Płynace z nich wnioski można podzielić na trzy główne kategorie. Po pierwsze, bardzo istotne jest jak najwcześniejsze zaangażowanie w pracę osób odpowiedzialne za integrację i testowanie. Z doświadczeń zawartych w pracy wynika, że tak naprawdę powinny brać udział w projektowaniu systemu od pierwszych jego etapów, czyli analizy wymagań i zdolności systemu. W opisywanym przypadku w pierwotnie stworzonych wymaganiach wykryto wiele braków, niespójności i powtórzeń, które mogły być przyczyna poważnych dodatkowych kosztów i opóźnień. Zostały one wykryte przez Głównego Integratora Systemu (ang. Lead System Integrator), firmę Lockheed Martin, i także przez nia naprawione. Po drugie, ważne jest aby wszelkie kluczowe decyzje dotyczace projektu były podejmowane biorac pod uwagę całość systemu wielosystemowego. Naturalnym

5.3. Case studies 37 jest, że przedstawiciele poszczególnych zespołów zwracaja uwagę przede wszystkim na kwestie dotyczace ich dziedziny, pomijajac kwestie nie dotyczace ich bezpośrednio. W przypadku systemów wielosystemowych jest to o tyle bardziej znaczace, że szczegółowa znajomość całego systemu jest praktycznie niemożliwa, a najistotniejsze funkcjonalności sa dostarczane przez komponenty wytwarzane przez różnych dostawców. W celu ułatwienia podejmowania właściwych decyzji Brooks i Sage zalecaja stworzenie modelu architekturalnego umożliwiajacego całościowe spojrzenie na wytwarzany system, z użyciem powszechnie przyjętych i zrozumiałych modeli komponentów. Po trzecie, Brooks i Sage kłada duży nacisk na planowanie działań zwiazanych z testowaniem i integracja oraz procesów je wspierajacych. W celu właściwego nadzorowania integracji kluczowe według nich jest stworzenie i utrzymywanie trzech dokumentów: Planu Zarzadzania Interfejsami Definujacego procesy zarzadzania i wytwarzanie interfejsów pomiędzy poszczególnymi komponentami Diagramu Kontekstu Interfejsów Ilustrujacego w przystępny, graficzny sposób interfejsy zawarte w systemie wielosystemowym Raportu Stanu Interfejsów Zawierajacego informacje na temat etapu wytwarzania, stanu i dojrzałości interfejsów. W kwestii weryfikacji i walidacji systemu autorzy podkreślaja (zgodnie z przedstawiona przez nich metoda CTA) znaczenie stworzenia Zintegrowanego Planu Weryfikacji i Walidacji (patrz 5.2.2), będacego podstawa procesu testowego. D zięki ustaleniu wspólnego dla wszystkich programów wytwórczych okresu trwania cyklu wytwarzania możliwe było jednoczesne testowanie najnowszej wersji poszczególnych komponentów. Istotne okazały się też wnioski wyciagnięte z fazy Wczesnego Testowania Interfejsów, które umożliwiły efektywne zarzadzanie ryzykiem i zaplanowanie zarówno fazy testów przedwdrożeniowych, jak i dokonywanych w czasie funkcjonowania systemu. 5.3.4. Joglekar - Test Strategy for Net-Centric C4ISR System Anil N. Joglekar porusza w swojej pracy [16] kwestię systemów C4ISR opartych na sieciach (ang. Net-Centric C4ISR Systems ). Przewiduje on, że w przyszłości coraz więcej systemów wielosystemowych będzie powstawało dzięki połaczeniu funkcjonalności już istniejacych systemów w celu uzyskania nowej, wspólnej funkcjonalności, w przeciwieństwie do obecnego trendu budowania nowych aplikacji dla nowych zadań. Podkreśla on tym samym istotność właściwych testów integracyjnych i regresji, koniecznych przy łaczeniu systemów nie projektowanych do określonego typu współpracy. Joglekar zauważa też, że większość systemów wielosystemowych jest sterowana przez technologię (ang. technology driven). Skutkuje to ich szybkim starzeniem (ang. obsolescence), które rodzi presję na przyspieszanie tempa wytwarzania i wdrażania produktu, ograniczajac tym samym czas i środki dostępne na testowanie. W tej sytuacji (oraz wobec opisanej wcześniej niemożności pełnego testowania) kluczowa staje się decyzja, co i w jakim stopniu (a także jakiej kolejności) zostanie przetestowane.

5.3. Case studies 38 Dodatkowo, jak zostało to wspomniane w rozdziale dotyczacym specyfiki systemów wielosystemowych w przypadku nowoczesnych, często powstałych na potrzeby konkretnego projektu technologii możliwość i jakość ich symulacji na potrzeby procesu testowego jest dyskusyjna. W tej sytuacji często jedynym wyjściem staje się wykorzystanie w testach części środowiska produkcyjnego. Joglekar proponuje odseparowanie komunikacji na potrzeby testów za pomoca oddzielnego szyfrowania, co według niego (przy zachowaniu właściwej przepustowości) powinno umożliwić realistyczne testy bez negatywnego wpływu na już funkcjonujace systemy. Wnioski dotyczace testowania Joglekar sugeruje stosowanie kilku zasad, które powinny umożliwić właściwe testowanie systemów wielosystemowych. Pierwsza z nich jest wykonywanie testów częściowo w środowisku produkcyjnym i przykładanie dużej wagi do sprawdzania założeń całego systemu wielosystemowego. W rozpatrywanym przez niego przypadku systemów pola walki jest to możliwe dzięki wykorzystaniu odmiennego sposobu szyfrowania wiadomości, co pozwala na testowanie nowych funkcjonalności w ich docelowym środowisku bez konieczności jego duplikowania. Weryfikacja spełnienia założeń jest możliwa także dzięki temu, że w ostatecznych testach biora udział jego operatorzy - w przypadku rozpatrywanym przez Joglekar a żołnierze i operatorzy systemów pola walki. Jest to możliwe dzięki temu, że do celów testowych wykorzystywane sa także realne sposoby wydawania rozkazów i sterowania systemami komponentowymi. Zalecenie to jest odzwierciedleniem znanej z systemów niemilitarnych fazy testów akceptacyjnych wykonywanych przez użytkowników końcowych, nazywanej w literaturze angielskojęzycznej UAT - User Acceptance Testing. Kolejna zaleceniem, odzwierciedlajacym podejście opisane w Cross Program Approach, jest stworzenie zespołów odpowiedzialnych za wczesne / ciagłe testowanie powstajacych komponentów. Joglekar zaleca przy tym, by zapewnić niezależność testerów całości systemu wielosystemowego, ale jednocześnie umożliwiać ich współpracę z poszczególnymi zespołami wytwórczymi. Ostatnim zaleceniem jest stosowanie metody testowania opartego na ryzyku (patrz 5.1) do testowania poszczególnych produktów pośrednich procesu wytwarzania oraz weryfikowanie poprawności działania procesu kontroli i dowodzenia (ang. command and control) za pomoca ustalonych wcześniej scenariuszy.

6. Wnioski dotyczace testowania systemów wielosystemowych 6.1. Ogólnie Właściwe testowanie systemów wielosystemowych wymagania wykonania wszystkich tych czynności, które niezbędne sa w przypadku klasycznych systemów, a poszczególne komponenty w trakcie wytwarzania podlegaja standardowym procedurom testowania, za które odpowiedzialni sa ich wytwórcy. Główna różnica polega na koordynacji działania poszczególnych systemów i zapewnieniu, że dzięki komunikacji sa one w stanie dostarczać funkcjonalność możliwa do osiagnięcia tylko przy ich współpracy. Jak wynika z opisanych w poprzednim rozdziale przykładów, wskazane jest utworzenie zespołu osób odpowiedzialnych za testowanie systemu wielosystemowego i realizację procesów je wspierajacych. Zespół ten powinien byc niezależny od poszczególnych dostawców i organizacji, odpowiadajac przed głównym klientem lub wyznaczonym przez niego pełnomocnikiem, na przykład takim jak Lockheed Martin w pracy Brooksa i Sage a. Wnioski dotyczace ich głównych zadań i sposobu ich wypełniania zostana najpierw podane poniżej, a potem omówione szczegółowo, wraz z przykładami i odwołaniami do prac, w których zostały zaproponowane. Weryfikacja poprawności integracji i współpracy Istota systemów wielosystemowych i jednocześnie jedna z cech stanowiacych największe utrudnienie w ich testowaniu jest wysoki stopień współpracy i współzależności ich komponentów. Sprawia ona, że integracja systemu wielosystemowego z pojednyczych komponentów jest procesem bardzo skomplikowanym, szczególnie biorac pod uwagę różnorodność ich typów oraz fakt, że zazwyczaj sa wytwarzane przez różnych dostawców, różnia się stopniem dojrzałości i wymagaja zmian nie zmieniajacych ich funkcjonowania poza systemem wielosystemowym. Nadzorowanie postępów i poprawności procesu wytwarzania Wytwarzanie systemów wielosystemowych jest procesem długotrwałym (np. tworzenie DPS trwało ponad 10 lat [20], zaś systemu Tomahawk 30 lat 3.1.1) i skomplikowanym, w zwiazku z czym bardzo istotna jest kontrola i raportowanie postępów przebiegajacych prac. Integracja poszczególnych części systemu, a co za tym idzie ich testowanie zazwyczaj rozpoczyna się jeszcze zanim zakończy się wytwarzanie (np. faza Early Interface Testing w metodzie CPA [7]). Dlatego też gromadzenie wyników

6.2. Planowanie i projektowanie 40 testów na poziomie komponentów, weryfikacja ich gotowości do integracji i interpretacja zgromadzonych w ten sposób informacji powinna przebiegać w sposób ciagły od samego poczatku wytwarzania. Właściwa dla specyfiki systemów wielosystemowych organizacja pracy Cecha charakterystyczna systemów wielosystemowych jest duża liczba organizacji biora- cych udział w ich wytwarzaniu, które niekoniecznie (w sposób mniej lub bardziej jawny) musza posiadać i realizować wspólne cele. Dodatkowo moga istnieć omówione wcześniej (3.4.1) bariery wymiany informacji pomiędzy poszczególnymi kooperantami. Dlatego istotna dla kontroli całego procesu jest właściwa organizacja pracy, precyzyjne określenie obowiazków i przywilejów, a także zapewnienie zespołowi nadzorujacemu prace niezależności i możliwości współpracy ze wszystkimi zainteresowanymi stronami. Identyfikacja i kontrola ryzyka Ze względu na kluczowość systemów wielosystemowych i stopień ich skomplikowania ryzyko zwiazane z występowaniem w nich błędów jest szczególnie duże. Z tego powodu bardzo ważna jest właściwa identyfikacja ryzyk, ocena prawdopodobieństwa ich wystapienia i zapobieganie im, w czym wydatnie pomaga proces testowania. W poprzednich rozdziałach zostały opisane metody, w których analiza i kontrola ryzyka jest fundamentalna częścia procesu wytwarzania systemów. Nadzorowanie procesów wspomagajacych testowanie W celu umożliwienia właściwej weryfikacji i walidacji systemu wielosystemowego, a co za tym idzie, możliwości poddania go wymaganej kwalifikacji niezbędne jest, oprócz samego testowania, spełnienie dodatkowych wymagań formalnych i funkcjonalnych dotyczacych procesów towarzyszacych wytwarzaniu oprogramowania. Wielu autorów podkreśla przy tym konieczność zapewnienia spójności pomiarowej, zarzadzania wymaganiami / zdolnościami, zmiana i cyklem życia oprogramowania. Aktywności zespołu testerów systemu wielosystemowego, obejmujace testowanie i wspierajace je procesy zostały opisane poniżej w porzadku odpowiadajacym poszczególnym etapom procesu wytwarzania systemu. Bardziej dokładnie zostały opisane kwestie, które autorzy prac dotyczacych testowania systemów wielosystemowych uznali za szczególnie istotne. 6.2. Planowanie i projektowanie Aktywności testerów w pierwszej fazie implementacji dotycza głównie kwestii specyfikacji wymagań wobec systemu wielosystemowego i sposobu organizacji pracy umożliwajacego ich realizację. 6.2.1. Specyfikacja wymagań i ocena ryzyka Podstawa zarówno procesu testowego, jak i całości procesu wytwarzania jest wyspecyfikowanie wymagań wobec systemu w taki sposób, by były one zrozumiałe zarówno dla klienta, jak i dla wykonawców, a przy tym były weryfikowalne i (przynajmniej teoretycznie) możliwe do spełnienia przy założonych ograniczeniach czasowych i budżetowych. Omówiona wcześniej (patrz 5.1) metoda Risk Based

6.2. Planowanie i projektowanie 41 Testing jest podstawa obydwu formalnych metod używanych dotad do testowania systemów wielosystemowych, może więc służyć jako podstawowy sposób definiowania formalnych wymagań wobec systemu. Wspomniana we wprowadzeniu analiza GQM (patrz 2.2.1) może uzupełniać proces analizy ryzyka, dajac też osobom zwia- zanym z klientem poczucie lepszego zrozumienia analizowanego problemu. Ocena ryzyka Większość metod i przypadków testowania systemów wielosystemowych podkreśla znaczenie właściwego sposobu pomiaru, zarzadzania i minimalizacji ryzyka. W tym celu istotna jest dokładna analiza obu jego komponentów: podatności oraz wpływu. Podatność Generalna konkluzja płynac a z prac dotyczacych testowania systemów wielosystemowych jest fakt, że najbardziej problematyczna częścia procesu ich wytwarzania jest integracja poszczególnych komponentów w jedna całość. Możliwość właściwej oceny prawdopodobieństwa wystapienia błędów w komunikacji, które powinny zostać wykryte (najpóźniej) właśnie podczas fazy testów integracyjnych ma zapewniać zaproponowana w metodzie CTM faza Wczesnego Testowania Interfejsów (patrz 5.2.2). Prawdopodobieństwo wystapienia innych błędów może zostać ocenione przy użyciu opisanych wcześniej podejść: inside-out i outside-in (patrz 5.1). Podsumowaniem sposobu oceny podatności na ryzyko jest poniższa tabela. Tablica 6.1: Prawdopodobieństwo ryzyka Warunki Prawdopodobieństwo Ocena Wystapi prawie na pewno 90+% 1 Nie wystapi tylko przy optymistycznych 60-90% 2 założeniach Może wystapić, brak szczegółowych przesłanek 30-60% 3 Wystapi tylko przy pestymistycznych założeniach 0-30% 4 Źródło: Bernard Homes, Governing Testing of Systems of Systems Wpływ Homes sugeruje, że w przypadku złożonych systemów ocena wpływu powinna zostać dokonana w trzech oddzielnych kategoriach: czasu, kosztu oraz funkcjonalności. Każdy z nich może być oceniany z inna waga, w zależności od podatności konkretnego projektu na opóźnienia, elastyczności jego finansowania oraz istotności zagrożonej funkcjonalności. Kryteria przydziału zostały przedstawione poniżej:

6.2. Planowanie i projektowanie 42 Tablica 6.2: Wpływ ryzyka Budżet Funkcjonalność Czas Ocena >25% przekroczenia Niedostarczenie produktu >25% spóźnienia lub 1 - krytyczna budżetu możliwego do zaakceptowaninów niedotrzymanie termi- projektu 10-25% przekroczenia Niespełnienie kluczowych 10-25% spóźnienia 2 - wysoka budżetu wymagań i brak obejścia lub niedotrzymanie kamieni milowych 5-10% przekroczenia Niespełnienie wymagań, ale 5-10% spóźnienia lub 3 - średnia budżetu istnieja obejście i możliwość naprawy brak zmian planów Mniej niż 5% przekroczenia Niespełnienie wymagań ak- Mniej niż 5% spóźnie- 4 - niska budżetu ceptowane przez odbiorcę nia lub akceptowalne spóźnienie Źródło: Bernard Homes, Governing Testing of Systems of Systems Ocena ryzyka i eskalacja problemów Homes opisuje sposób przydziału ryzyka do różnych stopni kierowania, biorac pod uwagę ocenę prawdopobieństwa lub każda z trzech ocen wpływu. Sposób ten umożliwia też informowanie właściwych osób o wykrytach defektach systemu wielosystemowego. Jego propozycja została przedstawiona na poniższym diagramie, w legendzie zostały podane stopnie kierowania oraz odpowiadajace im role w propozycji Brooks a i Sage a (patrz 6.2.2). Tablica 6.3: Ocena ryzyka 1 2 3 4 5 6 7 8 9 10 11 12 13 12 15 16 Krytyczne 1 krytyczna lub 2+ wysokie Odbiorca Odbiorca Wysokie 1 wysoka lub 2+ średnie Zarzadca systemu Integrator Średnie 1 średnie, reszta niskie Zarzadca podsystemu Wykonawca i Integrator Niskie Tylko niskie Zarzadca sprzętu Wykonawca Źródło: Bernard Homes, Governing Testing of Systems of Systems 6.2.2. Podział pracy Po stworzeniu wymagań kolejna istotna kwestia jest ustalenie tego, kto będzie je wykonywał, kto odpowiadał za poprawność ich funkcjonowania, a kto weryfikował i rozliczał. Kwestia doboru wykonawców zazwyczaj nie dotyczy bezpośrednio członków zespołu testowego, jednak już podział odpowiedzialności i sposób weryfikacji poprawności jest bardzo istotny dla przebiegu procesu testowania. W celu dokonania właściwego podziału ról warto skorzystać z podejścia zaproponowanego przez Brooks a i Sage a.

6.2. Planowanie i projektowanie 43 Podział ról w wytwarzaniu Biorac pod uwagę konflikty interesów, wielu autorów prac na temat systemów wielosystemowych - Brooks i Sage [7], Cuppan i Sage [28], Joglekar [16] czy Homes [12] - sugeruje oddzielenie zespołu testowego od kierownictwa projektu i zespołów wytwórczych. Ma to na celu zapewnienie ich niezależności i obiektywizmu, a z drugiej strony powinno dawać możliwość współpracy ze wszystkimi organizacjami zaangażowanymi w wytwarzanie systemu. Ogólne sugestie różnych autorów moga być podsumowane z użyciem frameworku zaproponowanego przez Brooks a i Sage a [7], a opisanego szczegółowo w pracy Friedman a i Sage a [10]. Zakłada on wyróżnienie 8 obszarów koncepcyjnych, zaprezentowanych w poniższej tabeli. Dla każdego z nich należy wyznaczyć sposób odpowiedzialności. Autorzy zakładaja trzy możliwe sposoby przydzielenia odpowiedzialności: odpowiedzialność wytwórców, odpowiedzialność zamawiajacego ( w oryginalnej pracy był to rzad) oraz odpowiedzialność dzielona - w pracy Brooks a i Sage a obszary odpowiedzialności dzielonej były nadzorowane przez Głównego Integratora Systemu (patrz 5.3.3). Poniższa tabela nie jest wypełniona, gdyż autorzy pracy dotyczacej wytwarzania systemu wielosystemowego pod nadzorem Lockheed Martin nie sugeruja żadnego przykładu konkretnego przydziału odpowiedzialności, podkreślajac wagę właściwego dopasowania jej do wymagań konkretnego projektu. Szczegółowy opis każdego z 24 wariantów przydziału odpowiedzialności został omówiony, wraz z przykładowym przypadkiem użycia, w pracy Friedman a i Sage a [10]. Tablica 6.4: Podejście do podziału odpowiedzialności Odpowiedzialność Obszary koncepcyjne Wytwórcy Dzielona Odbiorcy Zdolności całego systemu Definicja i nadzorowanie wymagań Projekt systemu i architektury Integracja komponentów i interfejsów Weryfikacja i walidacja Wsparcie cyklu życia Ocena i zarzadzanie ryzykiem Zarzadzanie systemem i programem Źródło: Brooks a i Sage, System of systems integration and test [7] 6.2.3. Stworzenie harmonogramu Ostatnia z istotnych aktywności testerów w fazie projektowania i planowania systemu wielosystemowego jest stworzenie harmonogramu umożliwiajacego realizację postawionych przed testerami zadań. W tym celu niezbędne jest oszacowanie czasu potrzebnego na testy oraz wymagań - wobec poszczególnych komponentów, dokumentacji, środowiska itd. - umożliwiajaych rozpoczęcie formalnego testowania i jego ukończenie w zakładanym terminie.

6.3. Implementacja i wczesne testowanie 44 6.3. Implementacja i wczesne testowanie W momencie rozpoczęcia faktycznej implementacji, a jeszcze przed rozpoczęciem testowania na poziomie systemu wielosystemowego konieczne jest rozpoczęcie realizacji procesów je wspierajacych oraz umożliwajacych powiazanie działań wytwórczych z konkretnymi wymaganiami wobec systemu wielosystemowego. Procesy te obejmuja między innymi zarzadzanie zmiana, konfiguracja, raportowanie błędów, zapewnienie spójności pomiarowej czy wyliczanie miar i metryk. 6.3.1. Procesy wspierajace Autorzy prac na temat systemów wielosystemowych podkreślaja, że w przypadku tak złożonych systemów bardzo istotne jest właściwe zarzadzanie testowaniem i innymi procesami wspierajacymi ich weryfikację i walidację. Według Certified Tester Advanced Level Syllabus [15] procesy te obejmuja: Zapewnienie spójności pomiarowej (ang. traceability) Zarzadzania wymaganiami (wobec systemu wielosystemowego i komponentów) Zarzadzania zmiana w odniesieniu do funkcjonalności systemu wielosystemowego i jego konfiguracji Zarzadzania procesem życia poszczególnych elementów systemu (dostarczanie pożadanej funkcjonalności, redundancja, starzenie) Propozycja Homes a Bernard Homes [12] wyróżnia pięć aktywności testerów systemu wielosystemowego, które sa kluczowe dla powodzenia projektu, a nie sa bezpośrednio zwiazane z testowaniem. Pierwsza z nich jest sprawdzenie zgodności działań zarzadców, podwykonawców i dostawców ze zdefiniowanymi procesami wytwarzania i harmonogramem. Umożliwia to identyfikację potencjalnych niezgodności i odpowiednia korektę planów i kontraktów. Druga aktywnościa jest analiza dostępnej dokumentacji w celu zapewnenia, że nie ma zagrożeń dla kluczowych działań (ang. activities), wymagań (ang. dependencies) i harmonogramu (ang. schedule), zarówno systemów komponentowych jak i całości systemu wielosystemowego. Trzecia aktywnościa powinno być monitorowanie defektów, ryzyka i prowadzonych działań naprawczych i aktualizowanie oceny ich wpływu. Czwarta aktywnościa jest zapewnienie, że ogólne zdolności i wymagania wydajnościowe systemu wielosystemowego sa właściwie realizowane, z zachowaniem ograniczeń czasowych i kosztowych. Ostatnia, piat a aktywnościa testerów jest dostarczanie statystyk, metryk i pomiarów, tworzacych razem zestaw Kluczowych Wskaźników Efektywności (ang. Key Performance Indicators - KPI). Oprogramowanie wspierajace Wsparcie dla opisanych powyżej procesów, a także wiele narzędzi przeznaczonych do modelowania, implementacji i testowania systemów jest zawarta w pakiecie oprogramowania IBM Rational. Jeden z jego komponentów, Rational Rhapsody, umożliwia też modelowanie i zarzadzanie wymaganiami wobec systemu z zachowaniem wytycznych zawartych we wspomnianym wcześniej (patrz 5.2) frameworku architekturalnym DODAF.

6.3. Implementacja i wczesne testowanie 45 6.3.2. Miary i metryki W obliczu konieczności nadzorowania postępów projektu oraz oceny jakości finalnego produktu niezbędna jest możliwość analizy wszelkich dostępnych informacji i rezultatów dotyczacych procesu wytwórczego. W tym celu pomocne jest użycie miar (ang. measures) i metryk (ang. metric), umożliwiajacych podsumowanie dostępnych danych oraz prognozowanie na ich podstawie. Proces definiowania i stosowania miar i metryk jest szczególnie istotny w przypadku systemów wielosystemowych ze względu na ogromna ilość informacji oraz duża liczbę osób i organizacji, które musza je zrozumieć i stosować. Powinny one powstać na samym poczatku procesu wytwarzania, tak, aby możliwe było ich stosowanie na każdym etapie cyklu wytwórczego. Dla każdej ze zdefiniowanych miar niezbędne jest ustalenie jej wartości docelowej (ang. baseline) tak, aby przez cały czas w sposób spójny i zrozumiały można było monitorować postęp w jej realizacji. Miary efektywności i wydajności David Pianta w pracy Measures of Effectiveness (MOE) and Measures of Performance (MOP) [26] proponuje wyróżnienie dwóch typów miar - miar efektywności i miar wydajności. Miary efektywności sa zazwyczaj miarami jakościowymi, odzwierciedlajacymi podejście użytkownika i jego oczekiwania wobec projektu. Miary wydajności sa zaś zazwyczaj miarami ilościowymi, stanowiacymi sposób pomiaru stopnia realizacji wymagań użytkownika z punktu widzenia inżyniera. Zazwyczaj każda miara efektywności ma przypisanych wiele miar wydajności, które razem weryfikuja to, czy produkt posiada wymagane z punktu widzenia odbiorcy cechy. W podejściu Pianta widać analogię do opisanej wcześniej (patrz 2.2.1) metody GQM, moga one być wdrażane na tym samym etapie projektu i uzupełniać się. Miary efektywności systemów wielosystemowych Brooks i Sage w cytowanej wcześniej pracy [7] proponuja następujace miary efektywności systemów wielosystemowych Skalowalność Współdziałanie (ang. interoperability) Zapewnienie informacji Odporność na błedy (ang. robustness) Zwinność (ang. agility) Elastyczność (ang. flexibility) Zorientowanie na serwisy - SOA Zgodność ze standardami biznesowymi Metryki testowe Podstawa do oceny postępów projektu poprzez analizę danych dostarczanych przez proces testowy moga być metryki testowe, które obrazuja stopień zmian metryki w stosunku do założonej wartości docelowej. Poniższe metryki zostały zaproponowane przez Brooks a i Sage a jako użyteczne przy wytwarzaniu systemu wielosystemowego: Ilość zweryfikowanych funkcjonalności Ilość przetestowanych/spełnionych/niespełnionych wymagań Ilość przetestowanych interfejsów

6.4. Formalne testowanie 46 Ilość otwartych/zamkniętych raporty niezgodności Czas testów Ilość zintegrowanych serwisów Widoczne jest położenie przez autorów nacisku na kwestie zwiazane z integracja, zgodnie z założeniem, że to wysoki poziom współpracy jest najistotniejszym wyzwaniem przy tworzeniu systemów wielosystemowych. Autorzy prac na temat testowania zwracaja jednak uwagę, że w przypadku każdego projektu zbiór metryk powinien być dostosowany do jego specyfiki, a kluczowym kryterium powinna być raczej możliwość szybkiego wyliczenia metryk i ich interpretacji, a nie ich szczegółowość i duża ilość. 6.3.3. Wczesne testowanie Zgodnie z zasada testuj wcześnie i często proces testowania powinien rozpoczać się tak wcześnie, jak to możliwe. W przypadku systemów wielosystemowych najwcześniej wykonywanymi testami sa testy systemów komponentowych, wykonywane zazwyczaj przez ich dostawców. Testerzy systemu wielosystemowego nie musza brać w nich udziału, jednak wskazana - np. przez Bernarda Homesa [12] - jest analiza ich wyników w celu określenia stopnia gotowości podsystemów do integracji, a także właściwego przygotowania docelowego środowiska testowego. W momencie, kiedy współpracujace ze soba systemy przejda pomyślnie wewnętrzne testy, zgodnie z postulatami metody CPA powinno się rozpoczać Wczesne Testowanie Interfejsów, szczegółowo opisane w rozdziale 5.2.2. Dzięki temu możliwe jest wczesne wykrycie usterek, a także błędów popełnionych w trakcie projektowania. Rezultatem wczesnego testowania interfejsów jest też możliwość uaktualnienia oceny ryzyk dokonanej w trakcie wstępnej analizy wymagań. 6.4. Formalne testowanie W momencie spełnienia przez wszystkie systemy komponentowe wymagań umożliwiajacych rozpoczęcie procesu integracji i testowania zaczyna się etap formalnych testów, będacych często podstawa późniejszej kwalifikacji od użycia. 6.4.1. Przygotowanie i integracja Zanim rozpocznie się integracja całości systemu wielosystemowego niezbędne jest stworzenie środowiska testowego. Powinno ono odzwzorowywać środowisko produkcyjne tak dokładnie, jak to możliwe, uwzględniajac przy tym wszelkie zmiany konfiguracyjne, które zaszły od momentu planowania jego struktury. Niezbędne do tego jest właściwe zarzadzanie konfiguracja, tym bardziej, że systemy wielosystemowe intensywnie korzystaja z oprogramowania wbudowanego. Integracja Przeprowadzenie procesu integracji systemu wielosystemowego z jego systemów komponentowym jest najbardziej skomplikowanym zadaniem, jakie stoi przed jego twórcami, dlatego też trzeba dokonać właściwego doboru podejścia, według którego

6.4. Formalne testowanie 47 będzie ona przebiegała. Ze względu na złożoność integrowanego systemu i różnorodność komponentów i ich sposobów współpracy sugerowane podejścia uwzględniaja użycie różnego typu metod. Omówione zostana dwa z nich, zaprezentowane przez Brooks a i Sage a [7] oraz Homes a [12]. Propozycja Brooksa i Sage a Rysunek 6.1: Capability Based Integration Źródło: Opracowanie własne na podstawie [7] Brooks i Sage wielokrotnie podkreślaja znaczenie fazy Wczesnego Testowania Interfejsów, realizujacej założenia podstawowej zasady testowania "testuj wcześnie i często". Jest to przykład zastosowania metody pairwise integration, polegajacej na integrowaniu systemów "parami w celu sprawdzenie poprawności ich współpracy zanim zostanie stworzony cały system. Takie podejście umożliwia wcześniejsze rozpoczęcie testowania oraz ułatwia właściwa analizę funkcjonowania interfejsu oraz samych systemów poprzez ich izolację od reszty skomplikowanego środowiska. Dodatkowo Brooks i Sage stwierdzaja, że stosowane przy projektowaniu i zarzadzaniu wymaganiami podejście może być użyteczne także przy planowaniu właściwego testowania gotowego systemu. W takim przypadku testowanie integracji stanowi połaczenie metod: Integracji opartej na zdolnościach ( Capability based integration ) Integrujemy i testujemy najpierw te systemy, które razem dostarczaja konkretnych zdolności systemu wielosystemowego. W tym celu używana jest metodyka Top-Down,