Jarosław Kuchta Jakość Systemów Informatycznych Jakość Oprogramowania

Prezentacja na temat: "Jarosław Kuchta Jakość Systemów Informatycznych Jakość Oprogramowania"— Zapis prezentacji:

1 Jarosław Kuchta Jakość Systemów Informatycznych Jakość Oprogramowania
Studium przypadku Jarosław Kuchta Jakość Systemów Informatycznych Jakość Oprogramowania

2 Wypadki z THERAC-25 Jakość Systemów Informatycznych Case study

3 Geneza THERAC-25 Hardware CGR Neptune + Sagittaire + minikomputer PDP 11 Trzy klasy urządzeń: THERAC MeV (X) THERAC MeV (X/E) THERAC MeV (X/E) W THERAC-6 i THERAC-20 zabezpieczenia sprzętowe, w THERAC-25 tylko softwerowe Oprogramowanie THERAC-20 i THERAC-25 było projektowane niezależnie, oba w oparciu o oprogramowanie THERAC-6 Jakość Systemów Informatycznych Case study

4 Testy bezpieczeństwa (1983)
Drzewo błędów Tylko hardware Stwierdzenia dotyczące softweru: W wyniku dokładnego testowania w symulatorze sprzętowym i w warunkach polowych zredukowano liczbę błędów programowych. Analiza nie wykazała rezydentnych błędów softwerowych. Oprogramowanie nie podlega degradacji w wyniku zużycia, zmęczenia czy procesu reprodukcji. Błędy wykonania programu przez komputer są spowodowane przez przypadkowe zakłócenia działania komponentów sprzętowych poprzez cząstki alfa i szum elektromagnetyczny (prawdopodobieństwo ) Jakość Systemów Informatycznych Case study

5 Użytkowanie 11 maszyn THERAC-25
5 w USA 6 w Kanadzie 6 przypadków przedawkowania w latach 1987 gruntowne przeprojektowanie maszyn THERAC-25 z dodaniem zabezpieczeń sprzętowych Ten sam problem softwerowy znaleziono w THERAC-20, przedawkowanie nie nastąpiło, bo zadziałało zabezpieczenie hardwerowe Jakość Systemów Informatycznych Case study

6 Przypadki przedawkowania
czerwiec Marietta (Georgia) lipiec Hamilton (Ontario) grudzień Yakima (Washington) marzec Tyler (Texas) kwiecień Tyler (Texas) styczeń Yakima (Washington) Jakość Systemów Informatycznych Case study

7 Kennestone Regional Oncology Center, Marietta (Georgia, USA) 1985
61-letnia pacjentka, terapia 10 MeV „Straszliwe uczucie gorąca” Zaczerwienienie i obrzęk w miejscu terapii Uczucie „zamrożenia” ramienia Martwica tkanek Utrata władzy w ramieniu Pozew do sądu (odrzucony z braku dokumentacji) Szacunkowa dawka promieniowania tys. radów (dawka terapeutyczna 200 radów) 61-letnia pacjentka po usunięciu płata płuca, terapia 10 MeV na sąsiadujące węzły chłonne. Po włączeniu maszyny pacjentka odczuła "straszliwe uczucie gorąca". Krótko po zabiegu pojawiło się zaczerwienienie i obrzęk w okolicy, na którą było oddziaływanie radiologiczne. Ból powiększał się z czasem tak, że pacjentka czuła jakby "zamrożenie" ramienia. Po dwóch tygodniach zaczerwienienie i obrzęk pojawiły się również na plecach, doszło do martwienia tkanek, pacjentka straciła władzę w ramieniu. Złożyła pozew do sądu. Producent i operator maszyny wykluczyli możliwość awarii maszyny. Z braku dokumentacji zabiegu (drukowanie było wyłączone) pozew został odrzucony. Później radiolog oszacował przyjętą dawkę promieniowania na tys. radów (dawka terapeutyczna to 200 radów) Jakość Systemów Informatycznych Case study

8 Ontario Cancer Foundation, Hamilton (Ontario, Canada), 1985
40-letnia pacjentka, 24 zabieg na THERAC-25. Awaryjne wyłączenie po pięciu sekundach z komunikatem błędu „H-tilt”. Dozymetr - „brak dawki” – przejście w stan „treatment pause”. 5-krotne powtórzenie (klawisz „P” – „proceed”) – przejście w stan „treatment suspend” Nie stwierdzono przyczyny błędu. Wrażenie „porażenia prądem elektrycznym”, bóle i obrzęk w miejscu terapii. Zgon po 4 miesiącach w wyniku bardzo złośliwego raka – stwierdzono poparzenie radiologiczne. Szacunkowa dawka promieniowania tys. radów. 40-letnia pacjentka przyszła na 24 zabieg na THORAC-25. Operator włączył maszynę, ale ta wyłączyła się po pięciu sekundach z komunikatem błędu "H-tilt". Dozymetr pokazał "brak dawki" i maszyna weszła w stan "treatment pause". Ponieważ pacjentka nie otrzymała żadnej dawki, więc operator nacisnął klawisz "P" ("proceed") aby powtórzyć zabieg. Maszyna ponownie się wyłączyła. Ta sekwencja nastąpiła jeszcze cztery razy. Po piątym wyłączeniu maszyna weszła w stan "treatment suspend" i wezwano technika, który nie stwierdził przyczyny błędu. Po zabiegu pacjentka uskarżała się jakby na "porażenie prądem elektrycznym", bóle i obrzęk w miejscu terapii. Pacjentka zmarła po 4 miesiącach w wyniku bardzo złośliwego raka. Sekcja zwłok wykazała, że gdyby nie śmierć pacjentki, byłaby konieczność wymiany stawu biodrowego na protezę z powodu poparzenia radiologicznego. Radiolog określił dawkę promieniowania na tys. radów. Jakość Systemów Informatycznych Case study

9 Przyczyny wypadku Komputer odczytywał 3-bitowy sygnał z trzech mikroprzełączników obrotowej tablicy kontrolnej. Błędny odczyt w zakresie 1 bitu wprowadzał maszynę w stan nieustalony. Rozwiązanie - wprowadzenie dodatkowego, blokującego przycisku. Zalecono usunięcie komendy „P - proceed” Zmniejszono liczbę powtórzeń z pięciu do trzech. Zalecenie wprowadzenia potencjometru do weryfikacji położenia obrotowej tablicy kontrolnej. Komputer odczytywał i kontrolował 3-bitowy sygnał z trzech mikroprzełączników pokazując położenie obrotowej tablicy kontrolnej. Błędny odczyt w zakresie 1 bitu wprowadzał maszynę w stan nieustalony. Problem został rozwiązany przez wprowadzenie dodatkowego przycisku, który blokował pozycje tych trzech mikroprzełączników na kluczowych pozycjach. Zalecono usunięcie z softweru komendy "proceed" umożliwiającej kontynuację przez proste naciśnięcie przycisku "P" Zalecono zamianę stanu "treatment pause" na stan "treatment suspend". Z tym jednak nie zgodził się producent, w zamian zmniejszając liczbę powtórzeń z pięciu do trzech. Niezależny specjalista zalecił wprowadzenie potencjometru do weryfikacji położenia obrotowej tablicy kontrolnej. Jakość Systemów Informatycznych Case study

10 Yakima Valley Memorial Hospital, Yakima (Washington, USA), 1985
THERAC-25 w Yakima zmodyfikowany po wypadku w Hamilton. Pasiaste zaczerwienienie w miejscu zabiegu Szczeliny w blokującej tacy? Brak możliwości odtworzenia położenia tacy. Nie ustalono przyczyny zaczerwienienia. THERAC-25 w Yakima został zmodyfikowany po wypadku w Hamilton. Po jednym z zabiegów u pacjentki pojawiło się pasiaste zaczerwienienie w miejscu zabiegu. Ten efekt mógł być wywołany przez szczeliny w blokującej tacy, lecz położenie tacy nie mogło zostać odtworzone. Ponieważ odkryto, że pacjentka używała koca podgrzewanego, więc podejrzewano, że to ten koc spowodował zaczerwienienie. Nie ustalono przyczyny zaczerwienienia. Jakość Systemów Informatycznych Case study

11 East Texas Cancer Center, (Tyler, USA), marzec 1986 (1/2)
Pacjent na dziewiąty z serii zabiegów. Planowana dawka 180 radów na obszar 170 cm2 na karku. Pomyłka operatorki („x” – Rentgen zamiast „e” – elektron) Korekta bez zmiany pozostałych parametrów – polecenie „B” („beam on”) Awaryjne wyłączenie z komunikatem „Malfunction 54” – przejście w stan „treatment pause”. Wyjaśnienie „dose input 2”, (dawka zbyt duża lub zbyt mała). Wskazania dozymetru = 6 zamiast 202 jednostek. Polecenie „P” („proceed”) – ponowne awaryjne wyłączenie. Therac-25 był do czasu pierwszego wypadku użytkowany przez 2 lata u przeszło 500 pacjentów. 21 marca pacjent przyszedł na dziewiąty z serii zabiegów i miał otrzymać dawkę 180 radów na obszar 170 cm2 na karku. Operatorka wprowadziła dane na panel kontrolny i zauważyła, że zamiast "e" (dla terapii elektronowej) wpisała "x" (dla terapii promieniami Rentgena). Przesunęła kursor w górę na odpowiednią pozycję i zmieniła "e" na "x". Ponieważ pozostałe parametry były już wprowadzone, więc nacisnęła kilka razy "Return" pozostawiają parametry nie zmienione, aż dotarła do dołu ekranu, gdzie widniał komunikat "Beam ready" i nacisnęła przycisk "B" ("beam on"). Po chwili maszyna wyłączyła się i na konsoli pojawił się napis "Malfunction 54". Jednocześnie maszyna weszła w stan "treatment pause". Umieszczony z boku maszyny spis komunikatów u błędach podawał wyjaśnienie "dose input 2", co mogło oznaczać dawkę zbyt dużą lub zbyt małą. Monitor dozymetru pokazywał dawkę zbyt małą. Na żądane 202 jednostki monitor pokazywał 6 jednostek.. Ponieważ operatorka była przyzwyczajona do częstego pauzowania maszyny, więc nacisnęła przycisk "P". Maszyna wyłączyła się z tym samym komunikatem. Jakość Systemów Informatycznych Case study

12 East Texas Cancer Center, (Tyler, USA), marzec 1986 (2/2)
Interkom i kamera w pomieszczeniu zabiegowym odłączone. Pierwsza dawka – wrażenie „oparzenia gorącą kawą”. Druga dawka – wrażenie „szoku elektrycznego” i „odpadnięcia ręki od ciała” Brak możliwości odtworzenia sytuacji Podejrzenie „wyładowania elektrycznego” Bóle karku i ramienia, utrata władzy w ramieniu, nudności i wymioty. Zgon 5 miesięcy o wypadku. Szacunkowa dawka 16, tys. radów. Pomieszczenie zabiegowe jest oddzielone od pomieszczenia kontrolnego. Drogą komunikacji jest interkom i kamera, które były w tym czasie odłączone. Po pierwszej dawce pacjent poczuł się oparzony jakby "gorącą kawą", więc podniósł się ze stołu zabiegowego i w tym czasie dostał drugą dawkę, z którą poczuł, jakby "szok elektryczny" i jakby "ręka mu odpadła od ciała". Natychmiast pojawiło się zaczerwienienie. Pacjent stanął w drzwiach pomieszczenia kontrolnego i operatorka przerwała zabieg. Therac-25 został wyłączony dzień po wypadku i poddany drobiazgowej kontroli. Wezwany specjalista od producenta nie mógł odtworzyć sytuacji, która doprowadziła do komunikatu "Malfunction 54". Producent stwierdził, że to niemożliwe, by zaczerwienienie było wynikiem przedawkowania i winą obarczono "wyładowanie elektryczne" Po kilku tygodniach pacjent odczuwał bóle karku i ramienia. Stracił władzę w ramieniu, miewał nudności i wymioty. Umarł w wyniku przedawkowania 5 miesięcy po wypadku. Radiolog określił przyjętą przez niego dawkę na 16, tys. radów. Jakość Systemów Informatycznych Case study

13 East Texas Cancer Center, (Tyler, USA), kwiecień 1986
Trzy tygodnie po pierwszym wypadku pacjent 10 MeV na 70 cm2 na twarz. Ta sama operatorka. Taki sam błąd – to samo postępowanie. Takie samo awaryjne wyłączenie Z interkomu wołanie pacjenta o pomoc. Wrażenie „rozbłysku światła” i uczucie uderzenia. Odgłos „smażonych jajek”. Zgon trzy tygodnie po wypadku. Szacunkowa dawka 25 tys. radów Trzy tygodnie po pierwszym wypadku na zabieg zgłosił się mężczyzna, który miał otrzymać dawkę 10 MeV na obszar 70 cm2 na twarz. Pacjenta tego obsługiwała ta sama operatorka. Podobnie jak przy pierwszym wypadku pomyliła ona literkę "x" oraz "e", więc postąpiła tak samo, jak za pierwszym razem. Po kilku sekundach maszyna wyłączyła się z komunikatem "Malfunction 54". Jednocześnie z włączonego interkomu dało się słyszeć trzeszczenie i wołanie pacjenta o pomoc. Operatorka pospieszyła do pomieszczenia zabiegowego i spytała pacjenta "co się stało". Ten powiedział, że zobaczył rozbłysk światła i "coś go uderzyło". Jednocześnie usłyszał odgłos jakby "smażonych jajek". Pacjent zmarł z przedawkowania trzy tygodnie po wypadku. Producent ustalił, że dawka w środku wiązki wynosiła ok 25 tys. radów. Jakość Systemów Informatycznych Case study

14 Przyczyny wypadku Komunikat „Malfunction 54” można uzyskać w wyniku bardzo szybkiego wprowadzania danych. Po wypełnieniu wszystkich pól danych następuje ustawianie magnesów koncentrujących wiązkę (8 sekund). Wszelkie zmiany danych w tym czasie są ignorowane (na ekranie są pokazywane zmienione dane). Usunięto klawisz „kursor w górę” i wprowadzono przycisk „R” („reset”). Zmieniono stan „treatment pause” na „treatment suspend” dla błędów od „Malfunction 1” do „Malfuncion 64” Natychmiast po wypadku maszynę Thorac-25 wyłączono z eksploatacji i poddano badaniom, którymi zajął się miejscowy radiolog wraz z operatorką. Ustalili oni, że komunikat "Malfunction 54" można uzyskać w wyniku bardzo szybkiego wprowadzania danych. Ustalono, że przyczyną wypadków był błąd w oprogramowaniu. Po wypełnieniu przez operatora wszystkich pól danych w panelu sterującym oprogramowanie przystępowało do ustawienia magnesów koncentrujących wiązkę, co trwało ok 8 sekund. Wszelkie zmiany danych następujące w tym czasie były ignorowane (chociaż na ekranie były pokazywane zmienione dane). Dla uniknięcia dalszych wypadków usunięto klawisz "kursor w górę" i zmodyfikowano oprogramowanie tak, by wszelkie zmiany już wprowadzonych danych wymagały naciśnięcia przycisku "R" ("reset'). Ponadto zmieniono stan "treatment pause" na "treatment suspend" dla błędów od "Malfunction 1" do "Malfuncion 64" Jakość Systemów Informatycznych Case study

15 Yakima Valley Memorial Hospital, 1987
Planowano dwie dawki elektronów 4 i 3 rady oraz 1 dawkę promieni X – 79 radów. Wrażenie palenia i pieczenia, cztery dni po zabiegu zaczerwienienie o pasiastym wzorze. Taki wzór powstaje, jeśli maszyna emituje promienie X, gdy tablica kontrolna jest ustawiona na "oświetlenie pola". Emisja od 4 do 5 tys. radów. Dwie dawki razem od 8 do 10 tys. radów (zamiast 86 radów). Zgon po 4 miesiącach. Pacjent miał otrzymać dwie dawki elektronów 4 i 3 rady oraz 79-radową dawkę promieni X Przy zabiegu pacjent odczuł palenie i pieczenie, a cztery dni po zabiegu pojawiło się zaczerwienienie o charakterystycznym pasiastym wzorze. Również film, który operator przypadkowo pozostawił pod pacjentem, wykazywał taki sam wzór. Badanie wykazało, że taki wzór powstaje wówczas, jeśli maszyna emituje promienie X wówczas, gdy pozycja obrotowej tablicy kontrolnej jest ustawiona na "oświetlenie pola". Emitowana wówczas dawka promieni X wynosi od 4 do 5 tys. radów. Ponieważ pacjentowi podano dwie dawki, więc otrzymał od 8 do 10 tys. radów (zamiast 86 radów). Pacjent zmarł w wyniku przedawkowania po 4 miesiącach. Jakość Systemów Informatycznych Case study

16 Przyczyny wypadku Wyścigi między dwoma procedurami. Wynik zależał od tego, która procedura zakończyła się szybciej. Zalecenie zamknięcia wszystkich maszyn Therac-25 Ustalono, że przyczyną wypadku była wadliwa konstrukcja oprogramowania, która dopuszczała wyścigi między dwoma procedurami. Wynik zależał od tego, która procedura zakończyła się szybciej. Chociaż producent twierdził, że dla uniknięcia tego problemu wystarczy niewielka modyfikacja oprogramowania, to FDA (Food and Drug Administration) zaleciła zamknięcie wszystkich maszyn Therac-25 do czasu ich gruntownego przeprogramowania i skonstruowania mechanizmów zabezpieczających Jakość Systemów Informatycznych Case study

17 Wnioski (1) Wypadki są często następstwem skomplikowanego splotu rozmaitych czynników, a więc: Błędem jest przypuszczanie, że wypadek ma jedną, prostą przyczynę Przypisanie człowiekowi odpowiedzialności za awarie niczego nie rozwiązuje. Wyłączne przypisanie odpowiedzialności do oprogramowania nie rozwiązuje problemu (niemożliwe jest stworzenie oprogramowania nie zawierającego błędów) Wypadki są często następstwem skomplikowanego splotu rozmaitych czynników (technicznych, organizacyjnych ludzkich). Jedną z poważnych błędów, które doprowadziły do wypadków THERAC-25 było mylne przekonanie, że wypadek ma jedną prostą przyczynę (np. uszkodzenie mikroprzełączników). Innym błędem jest przypuszczenie, że usunięcie określonego błędu może wyeliminować kolejne awarie. Często awarie są przypisywane błędowi człowieka. Ale w ten sposób prawie wszystkie czynniki mogą być przypisane błędowi człowieka (może poza błędnym zadziałaniem sprzętu spowodowanym przypadkowym zakłóceniem). Chociaż i tego rodzaju błąd może być przypisany projektantowi, który nie przewidział tego rodzaju zakłóceń i nie zapewnił np. redundancji sprzętu. Przypisanie człowiekowi odpowiedzialności za awarie niczego nie rozwiązuje. Również przypisanie odpowiedzialności do oprogramowania nie rozwiązuje problemu. Jeśli to rzeczywiście błąd w oprogramowaniu spowodował awarię, to jedynym sposobem na uniknięcie awarii jest stworzenie oprogramowania idealnego, nie zawierającego błędów, co jest niemożliwe. Jakość Systemów Informatycznych Case study

18 Wnioski (2) Czynniki ryzyka:
niedostatki zarządzania i brak procedur postępowania po wypadkach, zbyt duże zaufanie do oprogramowania i usunięcie zabezpieczeń sprzętowych, prawdopodobnie praktyki inżynierii oprogramowania poniżej poziomu akceptacji. nierealistyczne przypisanie ryzyka wraz ze zbyt dużym zaufaniem do tych wyliczeń Problem awarii w złożonych systemach trzeba rozpatrywać z punktu widzenia inżynierii systemowej i rozważyć wszystkie możliwe czynniki ryzyka. W przypadku Therac-25 były to: niedostatki zarządzania i brak procedur postępowania we wszystkich zgłoszonych wypadkach, zbyt duże zaufanie do oprogramowania i usunięcie zabezpieczeń sprzętowych, prawdopodobnie praktyki inżynierii oprogramowania poniżej poziomu akceptacji. nierealistyczne przypisanie ryzyka wraz ze zbyt dużym zaufaniem do tych wyliczeń Jakość Systemów Informatycznych Case study

19 Wnioski (3) Projektowe błędy oprogramowania są trudne do znalezienia i wyeliminowania. Błędy oprogramowania mogą być o wiele bardziej różnorodne niż błędy sprzętowe. W systemach wrażliwych na bezpieczeństwo nie wystarczają zabezpieczenia softwerowe. Inżynierowie nie mający na co dzień styczności z oprogramowaniem wierzą, że nie powinno ono zawieść, bowiem nie podlega ono degradacji wskutek zużycia czy zmęczenia, jak komponenty sprzętowe. Tymczasem projektowe błędy oprogramowania są trudne do znalezienia i wyeliminowania. Ponadto błędy oprogramowania mogą być o wiele bardziej różnorodne niż błędy sprzętowe, więc o wiele trudniej jest stworzyć dla nich skuteczne zabezpieczenia. Sprzętowe zabezpieczenia są często zastępowane przez zabezpieczenia softwerowe w różnych systemach, takich jak samoloty, elektrownie atomowe, systemy uzbrojenia. Takie projektowanie systemu, że awaria jednego komponentu może prowadzić do wypadku, jest pogwałceniem podstawowych zasad projektowania. W tym przypadku oprogramowanie należy traktować jako jeden, pojedynczy komponent. Jakość Systemów Informatycznych Case study

20 Wnioski (4) Wszystkie potencjalnie niebezpieczne systemy muszą mieć ścieżki kontrolne i procedury analizy awarii. Przy szacowaniu ryzyka nie można polegać na prostym mnożeniu prawdopodobieństwa awarii pojedynczego komponentu. Wszystkie potencjalnie niebezpieczne systemy muszą mieć ścieżki kontrolne i procedury analizy awarii, które będą mogły być podejmowane zanim nastąpi wypadek. Przy szacowaniu ryzyka nie można polegać na prostym mnożeniu prawdopodobieństwa awarii pojedynczego komponentu. Do wszelkich danych liczbowych trzeba podchodzić bardzo ostrożnie. Jakość Systemów Informatycznych Case study

21 Wnioski (5) O dokumentacji należy myśleć w czasie trwania projektu, a nie po jego wykonaniu. Powinno się stosować praktyki i standardy zapewniające jakość (SQA). Projekty powinny być proste. Sposoby uzyskania informacji o błędach powinny być włączone do projektu od samego początku. Oprogramowanie powinno być poddane intensywnemu testowaniu i analizie formalnej już na poziomie modułów, testowanie systemowe nie jest wystarczające Jakość Systemów Informatycznych Case study

22 Literatura Nancy Leveson, University of Washington, Clark S. Turner, University of California, Irvine, An Investigation of the Therac-25 Accidents, Jakość Systemów Informatycznych Case study