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, iż 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 systemu 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ć, iż 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:

1. Koncepcyjnej (lewa strona litery V)
2. Implementacyjnej (dół)
3. 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:

1. Nakreślamy ogólną wizję produktu.
2. Zbieramy wymagania.
3. Tworzymy architekturę aplikacji.
4. 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:

1. 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.
2. 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ą.
3. Certyfikacja – sprawdzenie procesu wytwarzania systemu 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, iż 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 realizowane są już od dłuższego czasu. interesujące 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:

https://www.johner-institute.com/articles/software-iec-62304/software-lifecycle/agile-software-development/

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, iż 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. choćby jeżeli 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.