Analiza błędnie działających systemów safety-critical takich jak Therac-25, czy Ariane-5, a także doświadczenie z wielu projektów zakończonych sukcesem doprowadziły do konkluzji, że same umiejętności inżynierów to za mało, aby zapewnić niezawodność systemów. W tym celu niezbędny jest odpowiedni proces wytwarzania oprogramowania. Takie procesy zostały opisane w normach regulujących wytwarzanie oprogramowania dla urządzeń medycznych, samolotów, pociągów, czy elektrowni atomowych. Większość z tych norm opiera się na tym samym procesie zwanym V-modelem. W tym artykule omówię jego założenia.
Na czym polega V-model?
Moim celem nie jest tutaj wchodzenie w konkretne punkty norm i tłumaczenie każdego punktu V-modelu. To szczegóły implementacyjne, które różnią się pomiędzy normami. Chcę raczej pokazać, że proces ten opiera się na logicznych założeniach, które w ogólnej formie powinny być przestrzegane praktycznie w każdym projekcie programistycznym. Zanim zaczniemy pracę nad systemem dla konkretnej branży należy zapoznać się z odpowiednimi normami.
V-model zawdzięcza swoją nazwę charakterystycznemu kształtowi widocznemu na rysunku.
Składa się on z trzech faz:
- Koncepcyjnej (lewa strona litery V)
- Implementacyjnej (dół)
- Weryfikacyjnej (prawa strona)
Faza koncepcyjna
Faza koncepcyjna służy sprecyzowaniu zadań stawianych przed tworzonym systemem i sposobu ich realizacji. Zaczynamy od bardzo ogólnego poziomu, a następnie dodajemy coraz więcej szczegółów. W fazie koncepcyjnej:
- Nakreślamy ogólną wizję produktu.
- Zbieramy wymagania.
- Tworzymy architekturę aplikacji.
- Precyzujemy zadania stawiane poszczególnym komponentom i interakcje między nimi.
Po wykonaniu każdego z tych punktów precyzujemy od razu w jaki sposób będziemy później sprawdzać, czy otrzymany produkt jest zgodny z koncepcją.
Faza implementacyjna
Do implementacji przystępujemy dopiero, gdy wiemy, co chcemy osiągnąć. Zbyt wczesne przejście do implementacji powoduje nieoptymalny design. Z drugiej strony niektóre problemy wychodzą dopiero, gdy siądziemy do kodu. Dlatego w tej fazie koncepcja musi być aktualizowana. Implementacja obejmuje nie tylko kod produkcyjny, ale również testy. W tej fazie powstają testy różnych poziomów – jednostkowe, integracyjne i systemowe.
Faza weryfikacyjna
W fazie weryfikacyjnej możemy wyróżnić trzy etapy:
- Weryfikacja – w tym kroku sprawdzamy, czy implementacja jest zgodna z koncepcją na wszystkich poziomach szczegółowości (wymagania, architektura, komponenty). Wykorzystujemy w tym celu scenariusze testowe napisane w fazie implementacji i plany testów z fazy koncepcji. Możemy również posiłkować się różnymi metrykami i toolami np. performace, code coverage, statyczna analiza.
- Walidacja – sprawdzenie, czy był przestrzegany proces o wystarczającym rygorze dla zapewnienia niezbędnego poziomu bezpieczeństwa. W tym etapie sprawdzamy na przykład czy były prowadzone code review, albo czy zmiany w kodzie są zgodne z dokumentacją.
- Certyfikacja – sprawdzenie procesu wytwarzania oprogramowania przez niezależny organ wolny od nacisków związanych z czasem i budżetem projektu.
Dokumentacja
Systemy safety-critical wymagają dużo większej dokumentacji niż standardowe projekty. Dla potwierdzenia posłużę się listą dokumentów dla poszczególnych faz według normy kolejowej EN50128:
Norma precyzuje jakie informacje muszą się znaleźć w poszczególnych dokumentach. Wiele osób ma awersję do pisania jakiejkolwiek dokumentacji, jednak w systemach safety-critical jest ona niezbędna. Na szczęście nie każdy z tych dokumentów musi mieć kilkaset stron, poza tym można łączyć kilka w jeden, a część informacji generować automatycznie. Poza tym żaden z tych dokumentów nie powstaje za jednym zamachem. Są one raczej tworzone na początku, a potem systematycznie uzupełniane i modyfikowane. W ten sposób nie grozi nam bycie programistą Worda, a dokumentacja jest rzeczywiście aktualna i przydatna.
Waterfall, czy Agile?
Opisany przeze mnie do tej pory proces ma wszystkie cechy Waterfalla – podział na fazy, dużo planowania przed implementacją, dużo dokumentacji. Faktycznie, pierwsze wersje norm powstawały w latach 90-tych, kiedy to był główny sposób prowadzenia projektów. Jednak dzisiaj już wiemy, że ma on kilka poważnych wad:
- Nie da się wszystkiego przewidzieć z góry.
- Zmiana koncepcji jest bardzo kosztowna.
- Testowanie po zakończeniu implementacji jest nieefektywne.
Dlatego waterfall ustąpił miejsca metodom iteracyjnym. W systemach safety-critical również nie jesteśmy na niego skazani. Norma nie narzuca nam konkretnego procesu wytwarzania oprogramowania. Mówi jedynie o punktach, które nasz proces musi spełniać. Dlatego próby z Agile dla systemów safety trwają już od dłuższego czasu. Ciekawe zestawienie metodyk prowadzenia projektu można znaleźć w dokumencie NASA Software Safety Guidebook z 2004 roku (rozdział 4.2.1, od strony 52).
Możemy tam poczytać między innymi o podejściu Rapid Prototyping, które zakłada szybkie tworzenie prototypów mających potwierdzić lub obalić pewne założenia oraz ułatwić decyzję dotyczącą wyboru docelowych rozwiązań.
Inną metodą iteracyjną wspomnianą w dokumencie NASA jest „Spiral Model”, który łączy tworzenie prototypów z nieco większym rygorem.
Inne materiały na ten temat:
Extreme Programming w systemach lotniczych:
https://www.researchgate.net/publication/224087444_Escape_the_waterfall_Agile_for_aerospace
Agile w systemach medycznych:
Należy jednak pamiętać o pewnych cechach szczególnych tego typu systemów. Dokumentacja jest integralną częścią systemu. Bez niej produkt nie przejdzie certyfikacji. Dlatego aby spełniała wymagania, musi być rozwijana z odpowiednią starannością. Zasada „Działający soft jest ważniejszy niż dokumentacja” nie może być wymówką, aby ją zaniedbywać. Poza tym częste release’y nie mają sensu ze względu na ryzyko związane z błędami i potrzebę certyfikacji i spełnienia różnych regulacji przed dopuszczeniem produktu do użytku.
Podsumowanie
V-model jest formalnym zapisem zdrowego inżynierskiego podejścia do tworzenia systemów informatycznych. Mówi nam po prostu, że aby stworzyć dobrze działający system musimy najpierw zastanowić się, czego od niego oczekujemy i jak chcemy go osiągnąć, następnie powinniśmy to zaimplementować i sprawdzić, czy otrzymany efekt jest zgodny z założeniami. Te czynności powinniśmy wykonywać w każdym projekcie, nie tylko safety. Bez zastanowienia się nad wymaganiami i architekturą daleko nie zajdziemy. Nawet jeśli te założenia mają się potem zmienić. W praktyce praca nad projektem realizującym V-model najczęściej odbywa się w sposób iteracyjny, gdzie kod, dokumentacja i testy są stopniowo uzupełniane aż do osiągnięcia ostatecznej wersji. V-model wymaga również tworzenia obszernej dokumentacji, co nie budzi najlepszych skojarzeń, ale może okazać się wielkim plusem. Aktualna, przydatna i szczegółowa dokumentacja niesamowicie usprawnia komunikację w zespole.
19 listopada 2018 at 08:50
Odnośnie V-modelu polecam lekturę Automotive Spice (Software Process Improvement and Capability dEtermination). Prawie każdy producent samochodów wymaga od swoich dostawców tego procesu, który oparty jest na V-modelu.
Szczególnie ciekawe jest to, że dokumentacja z poszczególnych kroków jest częścią produktu tak jak harware czy software.
28 listopada 2018 at 19:25
Dzięki Adam. Z tego co widzę, SPICE jest ogólnie dostępny, a nie w formie płatnej normy http://www.automotivespice.com/fileadmin/software-download/Automotive_SPICE_PAM_30.pdf.