Autor: Maciej Gajdzica (Senior Software Developer)
Therac-25 jest urządzeniem do radioterapii z lat 80-tych używanym w dwunastu szpitalach w USA i w Kanadzie. Zapisało się w historii w sposób niechlubny – jako najbardziej znany przypadek błędu software’u, skutkującego śmiercią ludzi. W latach 1985-87 miało miejsce 6 przypadków nadmiernego napromieniowania pacjentów, prowadzących do ich śmierci.
Powołani przez sąd eksperci znaleźli dokładne linie w kodzie, będące przyczyną wypadków. Nie zakończyli jednak na tym swojej pracy. Byli przekonani, że błąd w kodzie jest tylko skutkiem nieprawidłowości w prowadzeniu projektu. Dalsze poszukiwania pozwoliły im odkryć, że praktycznie cały kod został napisany przez jedną osobę. Nie była ona w żaden sposób sprawdzana i z nikim nie konsultowała swoich decyzji. Brakowało również podstawowej dokumentacji, takiej jak choćby lista wymagań czy projekt architektury.
Ale to nie jedyne błędy. Niewłaściwa analiza ryzyka skłoniła producenta do rezygnacji z zabezpieczeń mechanicznych, uniemożliwiających nadmierne napromieniowanie. Brakowało również testów oprogramowania przed oddaniem urządzenia do użytku. Producent także źle reagował na zgłaszane problemy, próbując zrzucić winę na pracowników szpitali. Ostatecznie producent urządzenia musiał płacić ogromne kary, stracił reputację i wycofał się z branży medycznej.
Przypadek Therac-25 był ważną lekcją dla twórców systemów krytycznych, od których zależy ludzkie życie. Zrozumieliśmy, że poleganie na indywidualnych umiejętnościach i doświadczeniu zespołów to za mało, aby zapewnić najwyższy poziom bezpieczeństwa. Każdemu mogą przytrafić się błędy.
Dla oprogramowania takiego jak systemy embedded (oprogramowanie wbudowane) niezbędny jest sam proces jego wytwarzania będący siatką bezpieczeństwa, wyłapującą błędy na różnych poziomach rozwoju projektu, aby nie pozwolić im przedostać się do końcowego produktu. Proces ten nazywany jest V-modelem i został opisany w normach takich jak IEC62304 (medyczna) DO-178C (lotnicza) ISO26262 (samochodowa).
V-model składa się z trzech części – Projektowania, Implementacji i Weryfikacji. Podczas projektowania zaczynamy od stworzenia ogólnej koncepcji systemu, następnie spisujemy wymagania, tworzymy architekturę systemu i doprecyzowujemy szczegóły działania poszczególnych modułów. Implementacja to proces przekuwania projektu w kod źródłowy. Na weryfikację natomiast składają się testy różnych poziomów: jednostkowe, integracyjne, systemowe, a także certyfikacja przez niezależną instytucję sprawdzającą zgodność projektu z normami.
V-model zawdzięcza swą nazwę charakterystycznemu kształtowi litery V. Każdy element po prawej stronie sprawdza zgodność końcowego produktu z odpowiednią częścią projektowania po lewej. Szczegóły implementacyjne są więc sprawdzane przez testy jednostkowe, współpraca modułów przez testy integracyjne, a wymagania przez testy akceptacyjne.
Nikogo nie powinna dziwić potrzeba utworzenia dużej ilości dokumentacji. W każdej fazie projektowania i weryfikacji powstaje po kilka dokumentów. Mamy więc do czynienia z różnymi planami, specyfikacjami, raportami, czy analizami ryzyka. Utworzenie tych dokumentów jest warunkiem koniecznym do przejścia certyfikacji, bez której projekt nie może być ukończony.
Można łatwo zauważyć podobieństwo V-modelu do Waterfalla, o którym już od 20 lat wiemy, że się nie sprawdza. Rozwój oprogramowania w modeluBig Design Up Front powoduje wydłużanie projektu w nieskończoność, nie da się od razu przewidzieć wszystkich problemów, a zmiany są ciężkie do wprowadzania. W efekcie jakość tworzonego w ten sposób systemu nie jest zbyt wysoka. Dlaczego więc najbardziej odpowiedzialne systemy mielibyśmy konstruować w taki sposób?
W praktyce wygląda to trochę inaczej, co zostało dobrze podsumowane przez jedno zdanie z normy medycznej IEC62304: „It does not require that any particular lifecycle model is used, but it does require that the plan include certain ACTIVITIES and have certain ATTRIBUTES.”
Norma nie narzuca więc konkretnego cyklu życia produktu. Pozostawia nam pewną dowolność pod warunkiem, że realizujemy opisane w niej aktywności i w efekcie powstają wymagane dokumenty. Dlatego najczęściej prace wykonuje się w sposób iteracyjny. Zgodność procesu ze standardem jest weryfikowana w procesie certyfikacji.
