SFMEA (SwFMEA) – o co w tym właściwie chodzi?

Po co robi się analizę wad i skutków oprogramowania?

Analiza SFMEA, czyli analiza wad oprogramowania i ich skutków, to młodsza siostra znanych powszednie DFMEA i PFMEA. I to dużo młodsza bo ma „dopiero” około 40 lat. Nie ma się temu właściwie co dziwić, bo znacznie niezawodności oprogramowania wcześniej, w latach 50-tych i 60-tych ubiegłego wieku było mało znaczące, bo nie było ono praktycznie wykorzystywane masowo, powszechnie. Ostatnie jednak dziesięciolecia to znaczący wzrost wpływu oprogramowania na nasze codzienne życie. „Jakiś” program decyduje kiedy nasz samochód zacznie awaryjnie hamować, „jakiś” program decyduje kiedy nasza kuchenka przestanie gotować zupę albo „jakiś” inny program decyduje czy w domu włączy się alarm w przypadku pożaru. Zważywszy na to trudno nie uznać, że temat niezawodności oprogramowania powinien być coraz głośniej poruszany.

Jak zrobić analizę SFMEA?

Co bardzo ważne, i od tego zaczynamy każde szkolenie z tej metody, SFMEA to analiza oprogramowania (systemu), a nie programowania (kodowania). Jest to więc metoda bliższa DFMEA, niż PFMEA.

1. Określ viewpoint

Bez wątpienia interesującym aspektem pracy z SFMEA jest konieczność wybrania na początku jednego z ośmiu tzw. viewpoints (punktów widzenia):

1. Functional – funkcjonalność, realizacja wymagań oprogramowania lub wymagań systemowych (SRS, SyRS)
2. Interface – dokumentacja projektowa (IDD, IDS)
3. Detamiled – szczegóły projektowe (DDD) lub kod
4. Maintenance – kod lub projekt, który w wyniku działań naprawczych uległ zmianie
5. Usability – użyteczność
6. Vulnerability – podatność na działanie systemów zewnętrznych
7. Serviceability – serwisowalność, skrypty instalacyjne, pliki readme
8. Production – proces tworzenia oprogramowania, plan rozwoju (SDP)

Inaczej bowiem przebiega analiza dla każdego z tych punktów widzenia, np.:

• podatności (odporności na działanie systemów zewnętrznych),
• funkcjonalności (realizacja założonych zadań).
• użyteczność (gdy analizuje się wpływ użytkownika na program),
• interfejsu (gdy analizuje się poszczególne współpracujące „pary”)
• lub serwisowalność (gdy zwraca się uwagę m.in. na problemy przy instalacji).

Każdy z tych aspektów analizy ma specyficzny formularz i specyficzny zbiór dokumentów wejściowych. Można też oczywiście podejść do SFMEA „standardowo” i wykorzystać typowy dla FMEA formularz, ale może się to okazać podejściem bardzo nieskutecznym.

2. Zdefiniuj wady, przyczyny, skutki

Viewpoint definiuje co w naszej SFMEA będzie wadą (failure), a na tej podstawie możemy już dopisać przyczyny oraz skutki dla poszczególnych modułów systemu komputerowego (lokalny, subsystem, system).

3. Wybierz metodę „wyceniania” ryzyka

Kolejnym ważnym aspektem, który na szkoleniach zajmuje sporo czasu, jest wybór metody „wycenienia” ryzyka. Wachlarz opcji jest tu ogromny.

Do wyboru mamy m.in.:

• kilka rodzajów macierzy krytyczności,
• trzy rodzaje wskaźnika RPN (jeden bardzo, bardzo nietypowy),
• ARPN
• ostatnio popularne AP.

Trzeba sobie więc to dokładnie przemyśleć i wyraźnie opisać w wewnętrznej procedurze dotyczącej SFMEA.

Kiedy należy robić SFMEA?

SFMEA to bez wątpienia rozbudowana i skomplikowana, ale bardzo cenna metoda, którą powinny zainteresować się wszystkie firmy tworzące oprogramowanie – od takiego obsługującego np. czujniki zabezpieczające maszyny, po te, które sterują pracą samochodów i znacznie bardziej skomplikowanych systemów.

Jak pokazuje wiele standardów zajmujących się niezawodnością oprogramowania, pierwsza analiza ryzyka powinna zostać przeprowadzona możliwie wcześnie. Już po zdefiniowaniu wymagań i zaprojektowaniu architektury systemu, można zacząć rozpoznawać pierwsze potencjalne problemy. Później, w miarę rozwoju projektu, SFMEA powinno być rozbudowywane i aktualizowane o nowe dane, w tym nowe ryzyka.

Podsumowanie

Rozpisując krok po kroku jak powinno przeprowadzać się analizę SFMEA trzeba:

1. Określić viewpoint
2. Na podstawie wybranego aspektu analizy zdefiniować wady „failure”
3. Przypisać do wad przyczyny
4. Określić skutki dla poszczególnych modułów systemu komputerowego takich jak: lokalny, system, subsystem.
5. Ocenić S, O, opcjonalnie D.
6. Podjąć decyzje w kwestii działań na podstawie wybranej metody „wyceniania” ryzyka.

Pobierz skrócony schemat wykonywania analizy SFMEA.