Assurance case stosowany w systematyczny i profesjonalny sposób może być podstawowym narzędziem komunikacji w pracach zapewnienia bezpieczeństwa systemu, wczesnym wykrywaniu problemów i zagrożeń oraz podejmowaniu decyzji dotyczących bezpieczeństwa. Może być istotnym czynnikiem wpływającym na efektywność całego procesu rozwoju systemu. Ale gdy nie jest rozwijany we właściwy sposób, może stać się kosztowym i nikomu niepotrzebnym artefaktem. Ryzykujesz porażkę podczas kwalifikacji czy certyfikacji systemu.
Zwykle doradzamy jak budować wiarygodną argumentację, ale dziś spojrzymy na to z drugiej strony i powiemy, jak można skutecznie zepsuć assurance case. Poniższa lista przedstawia osiem najgorszych praktyk podczas budowy argumentacji. Pewnie jest ich więcej, ale te przedstawione na pewno robią duże szkody. Jeżeli widzisz oznaki takich praktyk, to spodziewaj się, że tworzona argumentacja nie będzie użyteczna.
Programiści mają brzydkie zapachy kodu (code smells), czyli złe praktyki programistyczne. Gdy je zauważą w kodzie, to powinni wykonać odpowiednie refaktoryzacje, aby poprawić strukturę i jakość kodu. Poniżej mamy listę praktyk, które możemy nazwać brzydkimi zapachami argumentacji.
Zacznijmy od definiowania celu dla argumentacji.
1. Zdefiniuj bardzo ogólne cele
Po co poświęcać czas na precyzyjne definiowanie głównego postulatu (top claim) argumentacji. Ogólnie zdefiniowany cel da większą elastyczność w czasie projektu, szczególnie gdy zostawimy niedookreślone warunki eksploatacji. Wymagane cechy systemu nie muszą być mierzalne, żeby rozpocząć prace projektu.
W rzeczywistości nieprecyzyjne cele to recepta na porażkę. Różne osoby mogą je różnie interpretować. Nawet gdy zrobisz dobrą inżynierską robotę i dostarczysz dobrej jakości dowody, to całość zostanie uznana za mało wiarygodną. Jedynym rozwiązaniem jest od początku precyzyjnie definiować cele, kontekst i kryteria akceptacji.
2. Twórz argumentację, gdy system jest już wytworzony
Dlaczego zajmować się argumentacją, gdy jesteśmy zajęci rozwojem systemu? Można po prostu na końcu zebrać wytworzoną dokumentację i zbudować na tym argumentację. Najpierw zbuduj system, a potem zrób diagramy GSN.
Sednem assurance case jest argumentacja, nie diagramy. Prawdziwym celem jest budowanie wiarygodności systemu tak wcześnie, jak to tylko możliwe. Możliwie wcześnie należy identyfikować wymagane do wytworzenia dowody. Później wytworzenie czy naprawa dowodów może być zbyt kosztowna. Późny rozwój argumentacji może powodować, że niektóre ryzyka zostaną późno wykryte, gdy już są podjęte i wdrożone decyzje projektowe. Jedyne rozwiązanie, to szybkie rozpoczęcie prac nad argumentacją na początku projektu, wykonywanie iteracji w kolejnych fazach prac wytwórczych oraz uwzględnianie informacji z argumentacji w podejmowanych decyzjach projektowych.
3. Rób prostą dekompozycję postulatów
Po prostu dekomponuj postulaty na postulaty podrzędne bez dodawania wyjaśnień. Bez strategii, bez uzasadnień. Gdy trzeba, stosuj proste strategie typu „Argumentacja przez testy / analizę / zgodność procesu” unikając analizy, czy jest to wystarczające i adekwatne. Innym przykładem prostej strategii jest „stosujemy followed ISO 26262 / DO-178C / IEC 61508, więc system jest bezpieczny”. Stosuj możliwe uproszczenia dekomponując argumentację.
Niewyjaśniona dekompozycja postulatów nie stanowi argumentacji. Tworzenie argumentacji oznacza definiowanie strategii z jawnymi regułami wnioskowania oraz ich uzasadnienia oraz w razie potrzeby również argumentację zaufania. Wnioskowanie musi pokrywać pełny zakres i kontekst postulatu, a wszelkie wyjątki, warunki, założenia, wątpliwości lub ograniczenia powinny być wyraźnie określone. Każdy krok wnioskowania powinien zwiększać poziom pewności osiągania bezpieczeństwa i innych cech systemu. Ciągle zadawaj pytanie: „Czy to naprawdę buduje pewność?” Pytaj też ekspertów o weryfikację.
4. Ignoruj problemy zapewnienia wiarygodności
Przypisz odpowiedzialność za assurance case osobie, która ma mały wpływ na decyzje podejmowane w projekcie. Traktuj assurance case jako pracę administracyjną i dokumentacyjną na potrzeby certyfikacji. Nie angażuj z te prace osób decyzyjnych.
Rzeczywistość jest taka, że jeżeli mamy realnie obniżyć ryzyko w systemie, to właśnie assurance case jest narzędziem, aby możliwie szybki wskazać potrzebne decyzje. Dlatego właśnie odpowiedzialność na rozwój argumentacji powinna mieć osoba decyzyjna. Zwykle w projektach stosowane są dwie główne role, jedna odpowiedzialna za rozwój i druga za weryfikację i kontrolę jakości. Zalecane jest, aby do nich dołączyła trzecia osoba, odpowiedzialna za assurance. Można ją nazwać Lead Assurance Architect lub inaczej. Niezależnie od nazwy roli, ważne jest, aby wyniki assurance case miały wpływ na decyzje projektowe. Wszelkie ostrzeżenia, ryzyka i wymagania na dowody nie powinny być ignorowane. Reakcją na wszelkie problemy zgłaszane z assurance case powinny być odpowiednie akcje, aby zapewnić wymagany poziom zaufania do argumentacji assurance case.
5. Użyj dowodów, które masz pod ręką
Gdy budujesz argumentację opartą o testy, po prostu użyj raportu z testów. Nie trać czasu na sprawdzanie, czy zakres testów jest wystarczający, by w pełni uzasadnić dany postulat. Ufaj, że te dowody, które masz, są właściwe dla celu argumentacji.
Tanie i mylące podejście. Potrzeba dowodów wynika z argumentacji i to argumentacja jest źródłem wymagań na dowody. Najpierw patrz w argumentacji, jakie dowody są potrzebne, a dopiero potem, jaka dokumentacja jest dostępna, nie odwrotnie. Gdy nie ma dowodów spełniających w pełni wymagania, to albo postaraj się, żeby je wzmocnić lub uzupełnić, albo jawnie opisz luki i odstępstwa. Każdy dowód powinien być dokładnie oceniony. W ten sposób budujemy zaufanie do argumentacji.
Należy zauważyć, że postulaty i dowody działają na różnych poziomach abstrakcji. Dowody zazwyczaj przedstawiają dane techniczne, analizy, modelowanie, testy lub innego rodzaju dane techniczne, które agregujemy, aby tworzyć postulaty dotyczące właściwości systemu. Ważne są też kompetencje techniczne, aby w właściwy sposób interpretować dowody, rozumieć wszystkie ograniczenia i kontekst. Wiarygodne argumentacje wymagają wiarygodnych interpretacji dowodów.
6. Ignoruj założenia
Określ założenia tylko kiedy i gdzie jest to wygodne. Można je również umieszczać w opisach postulatów, nie jako osobne elementy. Koncentruj się na głównej argumentacji, nie szczegółach, takich jak założenia. Zakłada się, że założenia są spełnione, więc to nie ma dużej różnicy, czy są wymionione, czy nie.
Jeśli założenia nie są jawnie przedstawione, czytelnicy mogą interpretować assurance case jako zapewnienie, że opisywane właściwości systemu są zawsze zachowanie, również poza zakresem niejawnych założeń, podczas gdy w rzeczywistości tak nie jest. Unikanie dyskusji o założeniach podczas opracowywania argumentacji może prowadzić do późnego zidentyfikowania powiązanych problemów.
Pomijanie założeń jest jak wprowadzający w błąd marketing: ktoś twierdzi, że produkt jest bardzo atrakcyjny, ale zapomina wspomnieć o ograniczeniach i sytuacjach, gdy nie działa.
7. Zakładaj pewność i zerowe ryzyko resztkowe
Skup się na głównym rozumowaniu w argumentacji, nie wchodząc w szczegóły dotyczące ograniczeń, poziomu zaufania czy występująch luk. Zakładaj, że cała argumentacja jest w pełni skuteczna. Gdy minimalizujesz ryzyko, pomijaj problem ryzyka resztkowego. Pomijaj właściwości, których nie da się przetestować lub wymagają innych metod weryfikacji.
To bardzo naiwne podejście. Żaden system nie jest całkowicie bezpieczny ani zabezpieczony. Celem argumentacji jest wyraźne pokazanie pozostałego poziomu niepewności, ograniczeń oraz tego, czy jaki jest poziom ryzyka po wprowadzeniu zabezpieczeń i czy jest on akceptowalny. Akceptacja czy kwalifikacja systemu powinna być świadomą decyzją, biorącą pod uwage wszystkie ograniczenia i niepewności oraz ryzyko resztkowe.
7. Nie aktualizuj argumentacji
Celem jest formalna akceptacja assurance case. Gdy to zostanie osiągnięte, traktuj je jako formalny dokument, a nie jako produkt techniczny, który wymaga aktualizacji, tak jak wszystkie inne elementy konfiguracji systemu.
Assurance case, które nie są zgodne z aktualną wersją systemów, stają się bezużyteczne dla inżynierów. Argumentacja ma wartość tylko wtedy, gdy jest aktualizowana zgodnie ze wszystkimi produktami procesu wytwórczego systemu. W przeciwnym razie staje się jedynie dokumentem historycznym. Aby tego uniknąć, potrzebny jest skuteczny proces konfiguracji i zarządzania zmianami. Należy utrzymywać jawne informacje o statusie, czy dany fragment argumentu jest aktualny.
Podsumowanie
Warto sprawdzić, czy wymienione powyżej problemy występują w Twoich projektach. Musimy na nie szybko reagować, aby nie zaszkodziły naszym argumentacjom i skuteczności procesu. Właściwe stosowanie assurance case wymaga odpowiedniego przygotowania, warunków organizacyjnych oraz umiejętności technicznych. Dbajmy nie tylko o to, aby diagram GSN ładnie wyglądały, ale przede wszystkim o jakość procesu.