niezawodnosc_systemow_oprogramowania [mgr Wiki]

[[niezawodnosc_systemow_oprogramowania]]
mgr Wiki

# Niezawodność systemów oprogramowania

Niezawodność jest złożonym pojęciem, które zawsze należy rozważać na poziomie systemu, a nie poszczególnych komponentów.

Komponenty systemu zależą od siebie nawzajem, awaria jednego z nich może się więc przenieść na cały system i wpłynąć na działanie innych komponentów.

Często projektanci systemu nie są w stanie przewidzieć, jak konsekwencje awarii przenoszą się na cały system.

Nie mogą zatem podać wiarygodnych oszacowań niezawodności systemu.

## Czynniki wpływające na niezawodność całego systemu

- Niezawodność sprzętu - Jakie jest prawdopodobieństwo awarii komponentu sprzętowego i jak dużo czasu potrzeba na jej usunięcie?

- Niezawodność oprogramowania - Jakie jest prawdopodobieństwo wytworzenia niepoprawnego wyniku przez komponent programowy?

- Niezawodność operatora - Jakie jest prawdopodobieństwo popełnienia błędu przez operatora?

## Zależność czynników niezawodności

Awarie sprzętu mogą spowodować wysłanie fałszywych sygnałów, które są poza zakresem danych wejściowych spodziewanych przez oprogramowanie. W takim wypadku oprogramowanie może zachować się w sposób nieprzewidywalny.

Błąd operatora jest najbardziej prawdopodobny w sytuacjach stresowych. Dochodzi do tego najczęściej wówczas, gdy system ulega awarii. Błędy operatora mogą mogą mieć wpływ na działanie sprzętu, co prowadzi do dalszych błędów i tak dalej, i tak dalej.

Awaria jednego podsystemu, którą można by łatwo naprawić, przeradza się w poważny problem wymagający całkowitego wyłączenia systemu.

## Inżynieria niezawodności oprogramowania

Jest specjalistyczna gałęzią inżynierii oprogramowania, poświęconą dokonywaniu ogólnej oceny niezawodności systemów.

Bierze się w niej pod uwagę prawdopodobieństwa awarii różnych komponentów systemu i sposób ich połączenia, wpływający na całkowitą niezawodność systemu.

Przyjmijmy dla uproszczenia, że system zależy od komponentów A i B z prawdopodobieństwami awarii P (A) i P (B). Wówczas całkowite prawdopodobieństwo awarii systemu P(S) wynosi: P (S) = P (A) + P (B)

## Przykłady wymagań niezawodnościowych

- Należy wyspecyfikować zakres wartości, które mogą być wprowadzone przez operatora. System będzie sprawdzał, czy wszystkie dane wejściowe otrzymane od operatora mieszczą się w tym przedziale.

- W procesie inicjowania system będzie sprawdzał, czy wszystkie dyski nie zawierają uszkodzonych bloków.

- System musi być zaimplementowany za pomocą bezpiecznego podzbioru Ady i sprawdzony za pomocą analizy statycznej.

## Miary niezawodności

- Pierwsze miary niezawodności dotyczyły komponentów sprzętowych.

- Awarie takich komponentów są nieuchronne ze względu na czynniki fizyczne, takie jak zużycie ścierne, ogrzewanie elektryczne itd.

- Te miary sprzętowe nie zawsze są odpowiednie do specyfikowania niezawodności oprogramowania, ponieważ natury awarii sprzętu i oprogramowania są różne.

- Awarie komponentów sprzętowych są zwykle chwilowe, a nie trwałe. Pojawiają się jedynie dla pewnych danych wejściowych. Jeśli nie uszkodzono danych, to system często może kontynuować działanie po wystąpieniu awarii.

Miara | Objaśnienie
--- | ---
POFOD - Probability of failure on demand | Prawdopodobieństwo awarii przy zleceniu. Prawdopodobieństwo, że system ulegnie awarii po zleceniu mu usługi. POFOD o wartości 0,001 oznacza, że jedno zlecenie na tysiąc skończy się awarią.
ROCOF - Rate of failure Occurence | Częstotliwość występowania awarii. Częstotliwość występowania nieoczekiwanych zachowań. ROCOF o wartości 0,002 oznacza, że w ciągu 100 jednostek czasu działania prawdopodobnie zdarza się 2 awarie. Ta miara bywa czasem nazywana intensywnością awarii.
MTTF - Mean time Failure | Średni czas do awarii. Średni czas między zaobserwowanymi awariami systemu. MTTF o wartości 500 oznacza, że co 500 jednostek czasu to można oczekiwać jednej awarii.
AVAIL - Availability | Dostępność. Prawdopodobieństwo, że system jest dostępny dla użytkownika w określonej chwili. Dostępność o wartości 0,998 oznacza, że na 1000 jednostek czasu system prawdopodobnie będzie dostępny w czasie 998 jednostek.

Prawdopodobieństwo awarii przy zleceniu - Ta miara najbardziej nadaje się w wypadku systemów, których usługi są oczekiwane w nieprzewidywalnych i dość długich odstępach czasu, a niezrealizowanie tych usług ma poważne konsekwencje.

Częstotliwość występowania awarii - Tę miarę należy używać tam, gdzie żądania usług systemu są regularne i jest ważne, aby te usługi poprawnie zrealizować.

Średni czas awarii - Tę miarę należy używać w wypadku systemów z długimi transakcjami, tzn. tam gdzie ludzie używają systemu przez długi czas. Średni czas do awarii powinien być dłuższy niż średni czas trwania transmisji.

Dostępność - Tę miarę warto używać w wypadku systemów działających bez przerwy, których użytkownicy oczekują ciągłej realizacji usług.

## Rodzaje pomiarów, które można wykonać szacując niezawodność systemu

Liczba awarii systemu w czasie obsługi ustalonej liczby żądań usług. Służy do wyznaczenia POFOD.

Czas (lub liczba transakcji) między awariami systemu. Służy do wyznaczania ROCOF i MTTF.

Czas spędzony przy naprawie lub ponownym uruchomieniu systemu po awarii. Przy założeniu, że system musi być bez przerwy dostępny, ten pomiar umożliwia wyznaczanie AVAIL.

## Niefunkcjonalne wymagania niezawodnościowe

- W wielu dokumentacjach wymagań systemowych wymagania niezawodnościowe są niestarannie określone.

- Specyfikacje niezawodności są subiektywne i niemierzalne.

- Zdania, takie jak „Oprogramowanie powinno być niezawodne przy normalnym użytkowaniu”, nic nie znaczą.

- Stwierdzenia niby ilościowe są równie bezużyteczne.

## Klasyfikacje awarii

Klasa awarii | Opis
--- | ---
Chwilowa | Zdarza się tylko dla niektórych danych wejściowych
Trwała | Następuje dla wszystkich danych wejściowych
Usuwalna | System może ją usunąć bez interwencji operatora
Nieusuwalna | Usunięcie awarii wymaga interwencji operatora
Nieniszcząca | Awaria nie powoduje zniszczenia stanu i danych systemu
Niszcząca | Awaria powoduje zniszczenie stanu i danych systemu

## Czynności prowadzące do opracowania specyfikacji niezawodności

Dla każdego zidentyfikowanego podsystemu należy wskazać różne rozdaje możliwych awarii systemu i zanalizować konsekwencje tych awarii.

Na podstawie wyników analizy awarii systemu trzeba podzielić awarie na klasy. Dobrym punktem wyjściowym może być klasyfikacja z tabeli zaprezentowanej powyżej.

Dla każdej rozpoznanej klasy awarii trzeba zdefiniować wymaganie niezawodnościowe za pomocą odpowiedniej miary niezawodności. Nie trzeba używać tej samej miary dla różnych klas. Jeśli usunięcie awarii wymaga interwencji, to jej prawdopodobieństwo przy zleceniu nie jest najlepszą miarą.

Tam gdzie trzeba, należy określić niezawodnościowe wymagania niefunkcjonalne, w których wskaże się funkcjonalność systemu umożliwiającą zmniejszenie prawdopodobieństwa awarii krytycznych.

## Przykład specyfikacji niezawodności

Rozważmy wymagania niezawodnościowe stawiane bankomatowi.

Przypuśćmy, że każda maszyna w sieci jest używana około 300 razy dziennie.

Czas życia sprzętu systemu wynosi osiem lat, a oprogramowanie jest aktualizowane średnio raz na dwa lata.

W czasie działania jednej wersji oprogramowania każda maszyna obsługuje około 200 000 transakcji.

Sieć banku składa się z 1000 maszyn.

Oznacza to, że dziennie następuje 300 000 transakcji w centralnej bazie danych (około 100 milionów rocznie).

Awarie dzieli się na dwie duże klasy: te, które wpływają na jedną maszynę w sieci, oraz te, które wpływają na bazę danych, a zatem na wszystkie bankomaty w sieci.

### Specyfikacja niezawodności bankomatu

Klasa awarii | Przykład | Miara niezawodności
--- | --- | ---
Trwała nieniszcząca | System nie działa z żadną wsuwaną kartą. Usunięcie awarii wymaga ponownego uruchomienia oprogramowania. | ROCOF - 1 zdarzenie/1000 dni
Chwilowa nieniszcząca | Pasek magnetyczny nieuszkodzonej wsuniętej karty nie może być odczytany | ROCOF 1 na 1000 transakcji
Trwała niszcząca | Zestaw jednoczesnych transakcji w sieci powoduje uszkodzenie bazy danych | Niemierzalna! Nie powinna się zdarzyć w czasie życia systemu

## Rodzaje awarii

- Awarie chwilowe, które mogą być usunięte przez użytkownika, np. przez ponowne uruchomienie lub dostrojenie maszyny.

- Awarie trwałe, które wymagają naprawy maszyny przez producenta. Prawdopodobieństwo awarii tego rodzaju powinno być znacznie mniejsze.

## Uwagi

- Koszt opracowania i zatwierdzenia specyfikacji niezawodności systemu jest bardzo wysoki.

- Firmy musza realnie oceniać konieczność ponoszenia takich kosztów.

- Są one na pewno uzasadnione w wypadku systemów, których niezawodne działanie jest krytyczne, takich jak systemy central telefonicznych,i systemów, których awaria może doprowadzić do wielkich start gospodarczych.

- Takie koszty nie są na pewno uzasadnione w wypadku większości rodzajów systemów gospodarczych i naukowych.

- Takie systemy maja zwykle skromne wymagania niezawodnościowe, ponieważ koszt ich awarii to jedyne opóźnienia w przetwarzaniu, a usunięcie skutków tych awarii jest mało kosztowne.

niezawodnosc_systemow_oprogramowania.txt · Last modified: 2006/05/20 23:52 by 62.233.163.154