Blog: Zarzadzanie wymaganiami i testowanie

GDY JAKOŚĆ OZNACZA ŻYCIE.

GDY JAKOŚĆ OZNACZA ŻYCIE.
  • 2 833 views

Teorie zarządzania ryzykiem jak i nadzorowania jakości oprogramowania nader często posiłkują się opisem przypadków z dziedziny lotnictwa – i nie powinno to dziwić, bo skala potencjalnych strat jest w tej dziedzinie trudna do pominięcia. Incydenty i katastrofy lotnicze pozostają na długo w pamięci społeczeństwa, a koszty przeliczalne w takich sytuacjach bywają horrendalne.

Udostępnij!

GDY JAKOŚĆ OZNACZA ŻYCIE.

 

Teorie zarządzania ryzykiem jak i nadzorowania jakości oprogramowania nader często posiłkują się opisem przypadków z dziedziny lotnictwa – i nie powinno to dziwić, bo skala potencjalnych strat jest w tej dziedzinie trudna do pominięcia. Incydenty i katastrofy lotnicze pozostają na długo w pamięci społeczeństwa, a koszty przeliczalne w takich sytuacjach bywają horrendalne. Aspektem, o którym wspomina się nieco rzadziej, jest powiązana z powyższymi faktami sprawność i dokładność w uściślaniu zabezpieczeń i reagowaniu na zaistniałe zagrożenia, która lokuje producentów z branży lotniczej w czołówce graczy dbających o jakość swoich produktów i usług. Poprawa bezpieczeństwa lotów odczytywana ze statystyk śmiertelności wśród pasażerów na przestrzeni ostatnich 70 lat jest tak wyraźna, że kwituje się ją często powiedzeniem „Każdy wie, że lotnictwo jest niebezpieczne, a więc dlatego jest tak bezpieczne.” [Klich, 2011], a i popularne jest powiedzenie, że „statystycznie podróże lotnicze są najbezpieczniejsze ze wszystkich” [por. Griffihs, Christian, 2018, s.211; por. Smith, 2019, ss. 41 – 96].

Nie dziwi wstrząs, jaki wywołały głośne katastrofy samolotów Boeing 737 MAX 8 w październiku 2018 i marcu 2019.

Jeden  z najistotniejszych czynników został wskazany właśnie w lakonicznym zdaniu powyżej. Od katastrofy lotu Lion Air 610 do katastrofy lotu Ethiopian Airlines 302 upłynęły tylko 132 dni. W świetle rozpoznania tej samej przyczyny źródłowej katastrof jest to liczba przerażająca i niespotykana zapewne od czasu działań wojennych podczas Drugiej Wojny Światowej. Prawdopodobieństwo jest rozumiane w zarządzaniu ryzykiem przede wszystkim jako częstotliwość wystąpień [Klich, s. 183] (wynika to z dostosowania rozważań do badania wydarzeń, których przyczyn przez jakiś czas nie znamy; stopniowo analiza wzbogacana jest o strukturę systemu, którego elementy uwikłane są w wydarzenie). A zatem, uwzględniając nadzwyczajną sprawność branży lotniczej w łagodzeniu ryzyka, można stwierdzić, że pierwsza z katastrof przeraziła opinię publiczną skalą nieszczęścia ludzkiego – ale już druga skalą zaniedbań producenta samolotu.

Co się wydarzyło.

W modernizowanej starej konstrukcji samolotu Boeing 737 wprowadzono modyfikację polegającą na zainstalowaniu wydajniejszych silników CFM LEAP-18 (wskazywaną przyczyną jest wyścig z głównym konkurentem Boeinga, Airbusem, który ogłosił w 2010 wprowadzenie wydajniejszej maszyny – A320 neo). Wydajniejsze silniki mogły powodować problemy przy lądowaniu mimo dostosowania gondoli. Zdecydowano się na przesunięcie silników bliżej kadłuba samolotu, co okazało się wpływać na zachowanie liniowca w pewnych sytuacjach. Piloci testowi donosili o dyskomforcie i ryzyku przeciągnięć. Producent nie chciał modyfikować zbudowanych maszyn, a zatem zdecydował się na wprowadzenie wcześniej stosowanego w wojskowych samolotach KC-46 systemu modyfikującego charakterystykę manewrową (MCAS) opierającego swoje działanie na oprogramowaniu wyzwalanym umieszczonym w dziobie samolotu czujnikiem AoA (kąta ataku). Czujnik AoA miał tendencję do wyzwalania działania systemu MCAS w sytuacjach nie wymaganych, co skutkowało automatycznym odchyleniem elementów usterzenia samolotu. Lecący samolot zaczynał zachowywać się niezgodnie z intencjami pilotów trzymających wolanty, kręcących kółkiem nastawy trymerów i ustawiających parametry lotu.

Obecność systemów wpływających automatycznie na lot samolotu nie jest niczym niezwykłym w obecnych czasach, ale oczywistą sprawą jest pozostawienie pilotowi możliwości wyboru, czy taki system pracuje, czy nie. Powiązanie czujnika AoA z systemem MCAS było awaryjne – sygnał informujący o sprzeczności danych płynących z czujnika miał się wyświetlać na głównym ekranie,  w który patrzy pilot, jednak nie wyświetlał się. Sprawa była nawet rozpoznana podczas lotów, ale, jako że praca całego układu została wyceniona poniżej ryzyka katastrofalnego w ramach standaryzacji SAE ARP 4754, nie potraktowano tego zagadnienia jako usterki, a jako temat obsłużony płatną aktualizacją oprogramowania. Nie wszystkie linie lotnicze zdecydowały się na zakup tego „dodatku”, który z perspektywy nawet początkującego testera oprogramowania jest ni mniej, ni więcej, ale koniecznym elementem interfejsu (dostarczanie aktualnej informacji o aktywności ważnych komponentów systemu jest jednym z najbardziej tradycyjnych sygnałów, jaki można opisać w komunikacji człowieka z systemem informatycznym, o czym więcej poniżej).

Problematyczne oprogramowanie oraz wdrożenie systemu do urządzeń testowych okazało się być wykonane przez firmy podwykonawcze – stosunkowo odległe w łańcuchu dostawy, co skutkowało podnoszonymi ex post utrudnieniami komunikacyjnymi. Osobną, pozamerytoryczną już, sprawą były powiązania handlowe głównego gracza, które znacznie utrudniły zarządzanie kryzysem medialnym. Sprawą dużo bardziej interesującą kontrolera jakości oprogramowania natomiast było pominięcie informacji o nie tylko sposobie działania, ale w ogóle obecności systemu MCAS w ramach programu treningowego dla pilotów. Kolejne treningi różnic, którym obowiązkowo muszą poddawać się licencjonowani piloci, generują spore koszty i opóźnienia, i mają niebagatelne przełożenie na zakupy maszyn przez linie lotnicze. Opracowanie programu treningowego jest też ściśle powiązane z wymaganymi certyfikacjami, co doprowadziło do decyzji o uznaniu systemu MCAS za element, którego praca jest na tyle niezawodna i oczywista, że można go pozostawić poza świadomością pilotujących.  Doniesienia pilotów testowych i byłych programistów firmy wskazują na to, że wielokrotnie zwracano uwagę na anomalie związane z obszarem zachowania samolotu, w który system MCAS i czujnik AoA są zaangażowane, ale niejednokrotnie testujący nie otrzymywali informacji o ich obecności.

Katastrofy, które wydarzyły się po wdrożeniu feralnych systemów doprowadziły do śmierci 346 osób. Sumaryczne straty Boeinga oszacowano w styczniu 2020 na 18,4 mld dolarów. W tym samym roku raport wykazał 183 odwołane zamówienia. Model 737 Max 8 był najdłużej uziemionym samolotem w historii lotnictwa USA (uziemienie rozpoczęło się w marcu 2019, 3 dni po katastrofie w Etiopii; Etiopia ogłosiła przywrócenie modelu w swojej przestrzeni powietrznej z początkiem lutego 2022. Wcześniejsze najdłuższe uziemienie samolotu amerykańskiego wynosiło 3 miesiące). Wśród masy konsekwencji natury prawnej wymienić można zbiorowe pozwy wniesione przez pilotów, rodziny ofiar oraz przez klientów, wśród których znajdował się też polski LOT.

Ze stanowiska odszedł po siedmiu latach pracy CEO Boeinga, oraz wiele osób z kadry zarządzającej. Katastrofy pociągnęły za sobą liczne kontrowersje dotyczące powiązań między Boeingiem a amerykańskim organem nadzoru lotniczego FAA. Europejski odpowiednik tej agencji – EASA zadeklarował odstąpienie od praktyki „automatycznego” przyjmowania wyników prac FAA.

Prywatny dramat zapewne przeżywał też niedawno uznany za niewinnego pilot testujący, którego w październiku 2021 postawiono w stan oskarżenia zarzucając mu dostarczenie fałszywych wyników jego testów do FAA. Ciekawostką jest to, że sprawa ta pokazuje też, jak mocne są powiązania producenta z organem nadzoru, gdyż zagrożony 20  latami więzienia pilot pracował wcześniej właśnie dla agencji FAA, a potem przeniósł się do Boeinga. W mowie obrońców przed obliczem sądu w Fort Worth określono go jako „kozła ofiarnego”, który miał wziąć na siebie winy obu tych podmiotów.

Standardowe środki zapobiegania

Po odsunięciu na bok oczywistych aspektów etycznych i biznesowych sprawy tym, co może zdziwić specjalistę do spraw jakości, jest niespotykana skala zaniedbań dotyczących dostępnych standardów bezpieczeństwa. Certyfikacja rzeczonego samolotu opiera się między innymi na standardzie SAE International ARP 4754. Zastosowanie tego standardu przewiduje zgodność ze standardem ARP 4761 oraz ze znanym większości testerów oprogramowania RTCA DO-178C (popularnych za sprawą wzmianki w programach szkoleniowych dla certyfikowanych testerów). Wiedza testerska obejmuje informacje o tym, jaka minimalna liczba ścieżek testowych jest wymagana dla weryfikowanych komponentów, których awaria mogłaby doprowadzić do katastrofy lotniczej – wyznacza to pokrycie MC/DC [por. Myers 2005, s. 73, Binder, 2003, ss. 365 – 384]. O ile akurat tutaj wiedza o pokryciu kodu jest z przyczyn oczywistych niedostępna, to wskazać można na wyraziste uchybienia w zakresie charakterystyk niefunkcjonalnych – zwłaszcza użyteczności i niezawodności.

Teoria testowania oprogramowania dzieli z lotnictwem duży zasób terminologii ORM (Zarządzanie Ryzykiem Operacyjnym) leżącym u podstaw decyzyjnych w  branży lotniczej [por. Klich, r.5, passim]. Podstawowy podział typów ryzyka przedstawia się następująco:

  • Ryzyko całkowite
  • Ryzyko wykryte
  • Ryzyko nieakceptowalne
  • Ryzyko pozostałe (zwane też „rezydualnym”)
  • Ryzyko akceptowane
  • Ryzyko ukryte

Gdzie (Ryzyko Ukryte  Ryzyko Akceptowane = Ryzyko Pozostałe) [Klich, s. 184]

O ile do dnia pierwszej katastrofy – 29 października 2018 w Indonezji działanie systemu MCAS w powiązaniu z czujnikiem AoA można było próbować uznawać za ryzyko ukryte (choć wiele późniejszych doniesień byłej kadry w postaci programistów, projektantów, pilotów testowych i części kierowników wskazuje, że decyzja o takim zakwalifikowaniu była arbitralna i niezgodna z ich opiniami), to po tej katastrofie taka ocena była trudna do zrozumienia. Wszystko wskazuje na to, że ryzyko to ulokowano w rejonie czynników pozostałych-akceptowanych, ze znanymi teraz powszechnie konsekwencjami.

Jednym  z popularniejszych modeli stosowanych w lotnictwie jest model zarządzania 5M, który zbiera kluczowe czynniki w przejrzystą strukturę:


Gdzie odpowiednio terminy możemy rozumieć jako:

  • Man = Operator
  • Machine = System obsługiwany, technika
  • Management = Procedury użycia i przepisy
  • Media = Czynniki środowiskowe
  • Mission = Wykonywane zadanie.

Gdy rozważane są kluczowe zagrożenia w procesie, model ten często zyskuje postać sekwencji ilustrującej, jak kumulują się potencjalne zagrożenia [Klich, 42]:


W opisywanej sytuacji pomijalne są relacje między procedurami, środowiskiem i zadaniem, natomiast połączenia między człowiekiem, techniką a procedurami zaszwankowały w sposób dramatyczny.

Opis zagadnień symbolizowanych pierwszymi dwiema z czerwonych strzałek to fundamenty wiedzy testerskiej opisywane choćby przez standaryzację ISO 25010 w sekcji dotyczącej charakterystyki użyteczności.
Testerzy oprogramowania, projektanci interfejsów i inżynierowie wymagań często korzystają ze zilustrowanego przykładami opisu tej charakterystyki pod postacią „heurystyk” Jakoba Nielsena, ale też często korzysta się tu z „Ośmiu Złotych Zasad” Bena Shneidermana.

Wymieńmy 10 zasad z „Heurystyk” Nielsena:

  1. Uwidaczniaj status działającego systemu. (Zbieżne z trzecią zasadą Shneidermana: „Dostarczaj informacji zwrotnej”).
  2. Zachowaj zgodność między systemem a rzeczywistością.
  3. Daj użytkownikowi kontrolę nad systemem. (Zbieżne z większością prawideł Shneidermana).
  4. Przestrzegaj standardów i zachowaj spójność. (Tożsame z pierwszą zasadą Shneidermana).
  5. Zapobiegaj błędom użytkownika. (Tożsame z piątą zasadą).
  6. Pozwalaj wybierać, a nie każ pamiętać. (Zbieżne z piątą).
  7. Zapewnij efektywne użycie i jego usprawnianie. (Tożsame z drugą).
  8. Dbaj o estetykę i prostotę.
  9. Zapewnij skuteczne radzenie sobie z błędami systemu. (Zbieżne z piątą).
  10. Dostarcz wystarczający trening i dokumentację.

[por. Roman, 2015, ss. 420 – 426].

Zachowując ostrożność, można uznać, że zaniedbania dotyczyły w przypadku wdrożenia systemu MCAS w 737 MAX 8 punktów: 10, 1, 2, 3, 9 ex aequo oraz  4, 6 w nieco mniejszym stopniu:

  • „Dostarcz wystarczający trening i dokumentację”: system MCAS został pominięty w instrukcjach obsługi z 2018 roku (argumentowano to m.in. „unikaniem zalewania pilotów nadmiarowymi informacjami”). Wzmianka o istnieniu systemu MCAS pojawiła się dopiero 12 dni po pierwszej katastrofie, ale nie oznaczało to zmienienia programu szkoleń dla pilotów. Zgoda na udostępnienie takiej dokumentacji została wydana przez samą FAA. [Laris, 2019]
  • „Uwidaczniaj status działającego systemu”: pilotujący nie wiedzieli, że system MCAS się wzbudza. Nie wiedzieli też, że wynika to z nieprawdziwych informacji płynących z czujnika AoA. Obecny w koncepcjach projektantów napis „AoA DISAGREE”, który miał pojawiać się w prawym, górnym rogu ekranu przed oczami pilota, nie wyświetlał się jednak – a potem wręcz uczyniono z tej funkcji płatny dodatek. [Zetlin, 2019]
  • „Zachowaj zgodność między systemem a rzeczywistością”: zachowanie czujnika AoA okazało się kluczowym wyzwalaczem działania systemu MCAS, który wpływał na kąt trymera bez wiedzy pilotujących. O ile zawodność czujnika jest zdarzeniem, które zawsze trzeba brać pod uwagę, to niezrozumiałe jest zarówno zaimplementowanie opartej na nim funkcji w sposób nie dający informacji o sprzeczności we wskazaniach, jak i pozostawienie czujnika w roli jedynego obecnego wyzwalacza.
  • „Daj użytkownikowi kontrolę nad systemem”: piloci nie wiedzieli, że MCAS się aktywuje, co wynikało początkowo z nieświadomości jego istnienia, a potem z niewiedzy o ciągłym jego wzbudzaniu przez czujnik AoA. Przy prędkościach rozwijanych podczas wznoszenia się przejście na ręczne kontrolowanie trymera było niemożliwe ze względu na pęd powietrza. Obrazowo przedstawiła to dziennikarka CBS, Nora O’Donnell, w rozmowie z CEO Boeinga: „[załączenie MCAS] miało miejsce więcej niż wiele razy, to były dwa tuziny. Piloci zostali dosłownie wystawieni na przeciąganie liny z własną maszyną, by podtrzymać kontrolę […]”. [O’Donnell, 2019]
  • „Zapewnij skuteczne radzenie sobie z błędami systemu”: tu ponownie należałoby umieścić wcześniejszy opis braku możliwości ominięcia szwankującego układu. Problemy związane ze sterowaniem MAX 8 były wspominane przez pilotów od momentu prób na nowych silnikach, ale ryzyko przeciągnięcia nie było przez nich wskazywane jako dominujące. Działanie systemu MCAS można więc nazwać ryzykiem wtórnym, wygenerowanym wskutek działań zapobiegawczych podjętych wobec pierwotnego czynnika, który okazał się być znacznie mniej groźny.

 

Kwestią niezależną od zagadnień użyteczności jest to, dlaczego czujnik AoA był jedynym wyzwalaczem pracy system MCAS. Wspomniana standaryzacja ISO 25010 opisuje problem w ramach definicji charakterystyki niezawodności systemów.

Typowym podejściem wykorzystywanym przy projektowaniu rozwiązań lotniczych jest stosowanie nadmiarowości elementów niepodobnych, gdzie kluczowo istotnemu układowi towarzyszy układ duplikujący jego pracę w razie potrzeby. Praktyka niepodobności zakłada zastosowanie innych rozwiązań, części i dostawców niż w systemie podstawowym. Podejście to służy zapobieżeniu obecności części systemu zwanej popularnie SPOF – czyli single point of failure. Okazało się, że kwestia była podnoszona zarówno przez konkretnych specjalistów, jak prof. Andrew Kornecki [Baker, Gates, 2019], jak i przez europejską EASA, wskazującą, że preferowana przez nią nadmiarowość zakłada potrójne (sic), a nie podwójne systemy, które kojarzyła z Boeingiem. [Gates, 2019]. Można odnieść wrażenie, że powstałe ryzyko przekierowano do sfery dopiero co opisanej, czyli użyteczności, gdyż kierownictwo Boeinga, zaprzeczając istnieniu elementów SPOF w systemie, wspomniało o tym, że „to piloci stanowią drugi element zabezpieczający” [Useem, 2019].

Lista zaniedbań jest, jak widać na tyle zasobna, że wzbudziłaby w wielu etapach dostarczania protest większości kontrolerów jakości oprogramowania dzierżących certyfikat poziomu podstawowego ISTQB®. Nie powinno dziwić w tym kontekście, że w latach bezpośrednio poprzedzających katastrofy z organizacji producenta odeszło wiele osób, które w późniejszych wypowiedziach tylko jeszcze pogorszyły wizerunek organizacji.

 

Bibliografia:

  1. Baker, D. Gates, Lack of redundancies on Boeing 737 MAX system baffles some involved in developing the jet, [w:] „The Seattle Times”, 26 III 2019, https://www.seattletimes.com/business/boeing-aerospace/a-lack-of-redundancies-on-737-max-system-has-baffled-even-those-who-worked-on-the-jet/
  2. V. Binder, Testowanie systemów obiektowych, Warszawa, 2003.
  3. Gates, European regulator plans its own test flights of Boeing 737 MAX in sign of rift with FAA, [w:] „The Seattle Times”, 10 IX 2019,
    https://www.seattletimes.com/business/boeing-aerospace/european-regulator-plans-its-own-test-flights-of-boeing-737-max-in-sign-of-differences-with-faa/
  4. Griffiths, B. Christian, Algorytmy. Kiedy mniej myśleć, Łódź, 2018.
  5. Klich, Bezpieczeństwo lotów, Radom, 2011.
  6. Laris, Changes to flawed Boeing 737 Max were kept from pilots, DeFazio says, [w:] „The Washington Post”, 19 VI 2019,
    https://www.washingtonpost.com/local/trafficandcommuting/changes-to-flawed-boeing-737-max-were-kept-from-pilots-defazio-says/2019/06/19/553522f0-92bc-11e9-aadb-74e6b2b46f6a_story.html
  7. J. Myers [i in.], Sztuka testowania oprogramowania, Gliwice 2005.
  8. O’Donell [wywiad w CBS, 29 V 2019, 6:50, zapis:] https://www.cbsnews.com/news/boeing-ceo-dennis-muilenburg-says-he-would-put-his-family-737-max-without-any-hesitation-exclusive-2019-05-29/
  9. Roman, Testowanie i jakość oprogramowania, Warszawa, 2015.
  10. Smith, Pilot ci tego nie powie, Warszawa, 2019.
  11. Useem, The Long-Forgotten Flight That Sent Boeing Off Course, [w:] „The Atlantic”, 20 XI 2019, https://www.theatlantic.com/ideas/archive/2019/11/how-boeing-lost-its-bearings/602188/
  12. Zetlin, Boeing CEO Says Safety Is Highest Priority. The Company’s Pricing Says Something Different, [w:] „Inc”, 24 III 2019,
    https://www.inc.com/minda-zetlin/boeing-safety-features-options-upgrades-angle-attack-disagree-light-mcas-lion-air-ethiopian.html