©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Specyfikowanie systemów

krytycznych



Celem tego rozdziału jest wyjaśnienie,
jak

specyfikować

wymagania

funkcjonalne i niefunkcjonalne wobec
pewności.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Cele



Znać kilka miar służących do określania

niezawodności i wiedzieć, jak należy ich

używać do specyfikowania wymagań

niezawodnościowych.



Wiedzieć, jak z analizy ryzyka i zagrożeń

wywnioskować

wymagania

stawiane

bezpieczeństwu systemów krytycznych.



Znać podobieństwa między procesami

specyfikowania

wymagań

stawianych

bezpieczeństwu i zabezpieczeniu.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Zawartość



Specyfikowanie niezawodności systemu



Specyfikowanie bezpieczeństwa



Specyfikowanie zabezpieczenia

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Jakość specyfikacji systemów

krytycznych



Z powodu wysokiego kosztu awarii
systemu

trzeba

sprawić,

by

specyfikacja

systemu

krytycznego

miała wysoką jakość i precyzyjnie
odzwierciedlała prawdziwe potrzeby
użytkowników systemu.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Pewność systemów

krytycznych



Oczekiwanie

pewności

systemów

krytycznych

prowadzi

do

wymagań

funkcjonalnych i niefunkcjonalnych:

•

Systemowe wymagania funkcjonalne mogą
być definicjami udogodnień do wykrywania
błędów i odtwarzania oraz definicjami
właściwości systemu, które chronią go przed
awariami.

•

Wymagania

niefunkcjonalne

mogą

być

definicjami

wymaganej

niezawodności

i

dostępności systemu.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Wymagania typu „nie będzie”



Służą do określenia nieakceptowalnych
zachowań systemu. Oto przykłady takich
wymagań:

•

System nie będzie umożliwiał użytkownikom
modyfikowania praw dostępu do plików, których
nie utworzyli (zabezpieczenie).

•

System nie będzie umożliwiał wybrania trybu
wstecznej siły ciągu, gdy samolot jest w powietrzu
(bezpieczeństwo).

•

System nie będzie umożliwiał jednoczesnego
uruchomienia

więcej

niż

trzech

sygnałów

alarmowych (bezpieczeństwo).

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Specyfikowanie

niezawodności systemu



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.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Wymiary, które należy wziąć pod

uwagę przy specyfikowaniu

niezawodności



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?

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

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)

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

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.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17



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.

Miary niezawodności

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Miara

Objaśnienie

POFOD

Prawdopodobieństwo awarii przy zleceniu. Prawdopodobieństwo, że

Probability

system ulegnie awarii po zleceniu mu usługi. POFOD o wartości 0,001

of failure oznacza, że jedno zlecenie na tysiąc skończy się awarią.
on demand

ROCOF

Częstotliwość występowania awarii. Częstotliwość występowania

Rateof failure

nieoczekiwanych zachowań. ROCOF o wartości 0,002 oznacza, że w

Occurence

ciągu 100 jednostek czasu działania prawdopodobnie zdarza się 2

awarie. Ta miara bywa czasem nazywana intensywnością awarii.

MTTF

Średni czas do awarii. Średni czas między zaobserwowanymi awariami

Mean time

systemu. MTTF o wartości 500 oznacza, że co 500 jednostek czasu

to

Failure

można oczekiwać jednej awarii.

AVAIL

Dostępność. Prawdopodobieństwo, że system jest dostępny dla

Availability

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.

Miary niezawodności

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Miary niezawodności



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.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

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.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

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.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Klasyfikacja 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

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

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 rysunku.



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

.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

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.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Specyfikacja niezawodności

bankomatu

Klasa awarii

Przykład

Miara niezawodności

Trwała System nie działa z żadną wsuwaną

ROCOF

nieniszcząca

kartą. Usunięcie awarii wymaga ponownego 1

zdarzenie/1000 dni
uruchomienia oprogramowania.

Chwilowa

Pasek magnetyczny nieuszkodzonej

ROCOF

nieniszcząca

wsuniętej karty nie może być odczytany 1 na 1000 transakcji

Trwała

Zestaw jednoczesnych transakcji w sieci Niemierzalna! Nie

powinna

niszcząca

powoduje uszkodzenie bazy danych

się zdarzyć w

czasie życia

systemu

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17



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.

Rodzaje awarii

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

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.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Specyfikowanie

bezpieczeństwa



Bezpieczne działanie jest wymaganą cechą

systemów oprogramowania związanych z

bezpieczeństwem.



W czasie procesu inżynierii wymagań należy

więc rozważyć potencjalne zagrożenia.



W wypadku każdego zagrożenia należy

oszacować powodowane przez nie ryzyko.



W

specyfikacji

można

opisać,

jak

oprogramowanie powinno się zachowywać,

żeby zmniejszyć to ryzyko, lub stwierdzić, że

ryzyko nie może się nigdy pojawić.

Cykl życia

bezpieczeństwa

zgodny z IEC

61508

©Ian Sommerville 2000

Dependable systems specification

Slide 23

Budowanie systemów

związanych z bezpieczeństwem

Budowanie systemów

związanych z bezpieczeństwem

Planowanie

Zatwierdzenie i instalacja

Planowanie

Zatwierdzenie i instalacja

Instalacja

i przekazanie

Instalacja

i przekazanie

Zatwierdzenie

bezpieczeństwa

Zatwierdzenie

bezpieczeństwa

Działanie

i pielęgnacja

Działanie

i pielęgnacja

Likwidacja systemu

Likwidacja systemu

Zewnętrzne udogodnienia

do redukcji ryzyka

Zewnętrzne udogodnienia

do redukcji ryzyka

Analiza zagrożeń

i ryzyka

Analiza zagrożeń

i ryzyka

Definicja pojęć

i zakresu

Definicja pojęć

i zakresu

Przyporządkowanie

wymagań bezpieczeństwa

Przyporządkowanie

wymagań bezpieczeństwa

Opracowanie wymagań

bezpieczeństwa

Opracowanie wymagań

bezpieczeństwa

Planowanie i
budowanie

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Zarządzanie

bezpieczeństwem



Nie kończy się w chwili dostarczenia systemu.



Po dostarczeniu system musi być zainstalowany zgodnie z

planem, aby analiza ryzyka była ciągle aktualna.



Zatwierdzenie bezpieczeństwa również ma miejsce w

trakcie działania i (zwłaszcza) pielęgnacji systemu.



Do wielu kłopotów z bezpieczeństwem dochodzi z powodu

złego procesu pielęgnacji systemu, a zatem

zaprojektowanie systemu zdatnego do pielęgnacji jest

szczególnie ważne.



Ostatecznie ważne jest także, aby wziąć pod uwagę

kwestie bezpieczeństwa związane z likwidacją systemu

(np. utylizacja groźnych materiałów użytych do budowy

układów).

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Analiza zagrożeń i ryzyka



Analiza zagrożeń i ryzyka polega na badaniu systemu i środowiska,

w jakim system działa.



Jej celem jest znalezienie potencjalnych zagrożeń, które mogą

pojawić się w środowisku, pierwotnych przyczyn tych zagrożeń i

związanego z nimi ryzyka.



To złożony i trudny proces, który wymaga niestandardowego

myślenia i wiedzy ekspertów z rozmaitych dziedzin.



Powinien być wykonywany przez doświadczonych inżynierów z

udziałem ekspertów z dziedziny zastosowania i profesjonalnych

doradców od bezpieczeństwa.



Do identyfikacji zagrożeń można użyć sposobów pracy grupowej,

takich jak burza mózgów.



Zagrożenia mogą być znalezione także dzięki temu, że jeden z

uczestniczących analityków bezpośrednio doświadczył incydentu,

który doprowadził do zagrożenia.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Analiza zagrożeń i ryzyka

Rozpoznawanie

zagrożeń

Rozpoznawanie

zagrożeń

Analiza ryzyka

i klasyfikacja

zagrożeń

Analiza ryzyka

i klasyfikacja

zagrożeń

Rozkładanie

zagrożeń

Rozkładanie

zagrożeń

Ocena szans

zmniejszenia

ryzyka

Ocena szans

zmniejszenia

ryzyka

Opis zagrożeń

Opis zagrożeń

Oszacowanie

ryzyka

Oszacowanie

ryzyka

Analiza drzewa

awarii

Analiza drzewa

awarii

Wstępne

wymagania

bezpieczeństwa

Wstępne

wymagania

bezpieczeństwa

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17



Rozpoznawanie

zagrożeń.

Rozpoznaje

się

potencjalne zagrożenia, które mogą wystąpić. Ich

zbiór zależy od środowiska, w którym system będzie

użytkowany.



Analiza ryzyka i klasyfikacja zagrożeń. Każde

zagrożenie rozpatruje się oddzielnie. Te szczególnie

poważne i nie wykluczone są wybierane do dalszej

analizy.



Rozkładanie zagrożeń. Każde zagrożenie rozpatruje

się oddzielnie i szuka jego przyczyn.



Ocena szans zmniejszenia ryzyka. Znajduje się

propozycje zmniejszenia i redukcji rozpoznanego

ryzyka.

Proces analizy zagrożeń i

ryzyka

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Etapy analizy dla wielkich

systemów



Wstępna analiza zagrożeń, która polega na
rozpoznaniu najważniejszych zagrożeń.



Bardziej szczegółowa analiza zagrożeń w
systemach i podsystemach.



Analiza zagrożeń oprogramowania, w czasie
której

rozważa

się

ryzyko

awarii

oprogramowania.



Analiza zagrożeń operacyjnych, która jest
poświęcona

systemowemu

interfejsowi

użytkownika i ryzyku, wynikającemu z błędów
operatora.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17



Za duża dawka insuliny (niepowodzenie usługi).



Za mała dawka insuliny (niepowodzenie usługi).



Brak zasilania w związku z wyczerpaniem baterii (elektryczne).



Elektryczna interferencja maszyny z innym sprzętem

medycznym, takim jak rozrusznik serca (elektryczne).



Złe podłączenie detektora lub efektora spowodowane przez

niedopasowanie (fizyczne).



Części maszyny pozostawione w ciele chorego (biologiczne).



Zakażenie spowodowane podłączeniem maszyny

(biologiczne).



Reakcja alergiczna na materiał lub insulinę używaną w

maszynie (biologiczne).

System podawania insuliny

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Analiza drzewa awarii



W wypadku każdego rozpoznanego zagrożenia należy

przeprowadzić analizę, której celem jest znalezienie

sytuacji powodujących to zagrożenie.



Istnieją dedukcyjne i indukcyjne metody analizy

zagrożeń.



Metody dedukcyjne (zwykle łatwiejsze w użyciu)

polegają na rozpoczęciu od zagrożenia i na jego

podstawie poszukiwania możliwych awarii systemu.



Metody indukcyjne polegają na rozpoczęciu od awarii

systemu i poszukiwaniu zagrożeń, które mogą powstać.



Jeśli to możliwe, w analizie zagrożeń należy użyć obu

rodzajów metod

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Analiza drzewa awarii



Ta szeroko stosowana metoda analizy

zagrożeń jest łatwa do zrozumienia bez

fachowej wiedzy.



Analiza drzewa awarii polega na

rozpoznaniu niepożądanego zdarzenia i

badania go wstecz, aby odkryć możliwe

przyczyny tego zagrożenia.



Zagrożenie jest korzeniem tego drzewa,

a

liście

reprezentują

potencjalne

przyczyny zagrożenia.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Drzewo awarii systemu

podawania insuliny

Podano nieodpowiednią

dawkę insuliny

Awaria systemu

podawania

Odpowiednia dawka

podana w niewłaściwym

czasie

Błędne sygnały pompy

Niepoprawny pomiar

poziomu cukru

Awaria zegara

Błąd przy obliczaniu

poziomu cukru

Awaria detektora

Błąd

arytmetyczny

Błąd

algorytmiczny

Błąd przy
obliczaniu
poziomu cukru

Błąd

algorytmiczny

Błąd

arytmetyczny

lub

lub

lub

lub

lub

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Szacowanie ryzyka



Proces szacowania ryzyka rozpoczyna się
po zidentyfikowaniu wszystkich zagrożeń.



Szacując ryzyko, ocenia się znaczenie
każdego zagrożenia, prawdopodobieństwo
jego wystąpienia i prawdopodobieństwo,
że doprowadzi ono do wypadku.



W wyniku tego procesu dla każdego
zagrożenia powstaje opinia o jego
akceptowalności.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Poziomy akceptowalności

zagrożenia



Nie do przyjęcia. System musi być zaprojektowany

tak, że to zagrożenie nie może wystąpić, a nawet jeśli

wystąpi, nie może doprowadzić do wypadku.



Tak małe, jak to jest możliwe (ALARP- as low as

reasonably practical). System musi być

zaprojektowany tak, aby biorąc pod uwagę koszty, czas

dostawy, itd., zmniejszyć prawdopodobieństwo

wystąpienia wypadku z powodu tego zagrożenia.



Akceptowalne. Projektanci powinni przedsięwziąć

wszystkie kroki w celu zmniejszenia

prawdopodobieństwa powstania zagrożenia, jednak

tylko pod warunkiem, że nie zwiększą one kosztu, nie

opóźnią czasu dostawy, ani nie pogorszą atrybutów

niefunkcjonalnych.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Poziomy ryzyka

Obszar
ALARP

Ryzyko
nieistotne

Obszar nieakceptowalny
Ryzyko nie jest
tolerowane

Ryzyko jest tolerowane
jedynie wtedy, kiedy
jego
redukcja jest
praktycznie
niemożliwa lub
niezwykle
kosztowna

Obszar akceptowalny

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Proces szacowania ryzyka



Obejmuje kalkulacje prawdopodobieństwa i dotkliwości

zagrożenia.



Zwykle osiągnięcie dokładnych wyników tej czynności jest

bardzo trudne i najczęściej zależy od inżynierskiego

rozsądku.



Prawdopodobieństwa i dotkliwość są oceniane za pomocą

wartości

względnych,

takich

jak

„prawdopodobne”,

„niemożliwe”, „rzadkie”, „duża”, „średnia” i „mała”.



Doświadczenia zdobyte przy pracy nad poprzednimi

systemami umożliwiają skojarzenie z tymi pojęciami

pewnych wartości liczbowych.



Wypadki są jednak dość rzadkie, zwykle więc trudno jest

zweryfikować dokładność takiej wartości.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Analiza ryzyka związanego z

zagrożeniami

Rozpoznane zagrożenie Prawdo- Dotkliwość

Oszacowanie

Akcepto-

podobieństwo zagrożenia ryzyka

walność

Przedawkowanie insuliny

Średnie Duża Wysokie Nie do przyjęcia

Niedostateczna dawka insuliny

Średnie Mała Niskie

Akceptowalne

Zanik zasilania

Duże Mała Niskie Akceptowalne

Maszyna podłączona niewłaściwie Duże Duża Wysokie Nie do przyjęcia

Maszyna rani pacjenta Małe Duża Średnie ALARP

Maszyna powoduje infekcję Średnie

Średnia Średnie ALARP

Zakłócenia elektryczne

Małe Duża Średnie ALARP

Reakcja alergiczna Małe Mała Małe Akceptowalne

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Redukcja ryzyka



Po rozpoznaniu potencjalnych zagrożeń i
ich przyczyn formułuje się taką
specyfikacje systemu, aby
prawdopodobieństwo, że zagrożenie
doprowadzi do wypadku było niewielkie.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Strategie redukcji ryzyka



Unikanie zagrożeń.

• System jest zaprojektowany tak, aby

zagrożenia nie mogły się pojawić.



Wykrywanie i eliminowanie.

• System jest zaprojektowany tak, aby

wykrywać i eliminować zagrożenia, zanim

doprowadzą do wypadku.



Ograniczanie szkód.

• System jest zaprojektowany tak, aby

zminimalizować konsekwencje wypadków.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Potencjalne problemy

oprogramowania



Błąd arytmetyczny.

• Pojawia się, gdy jakieś obliczenie

arytmetyczne powoduje błąd reprezentacji.

W specyfikacji trzeba wskazać wszystkie

błędy arytmetyczne, które mogą się

zdarzyć. Zależą one od zastosowanego

algorytmu.



Błąd algorytmiczny.

• To znacznie trudniejsza sytuacja, ponieważ

trudno wykryć jakiekolwiek nienormalne

okoliczności. Można je wykryć przez

porównanie obliczonej potrzebnej dawki

insuliny z poprzednio podaną.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Przykłady wymagań stawianych

bezpieczeństwu pompy

insulinowej

WB1

Jedna dawka insuliny podana przez system nie będzie większa

niż maksimum określone przez użytkownika systemu.

WB2

Całkowita dzienna dawka insuliny podana przez system nie

będzie

większa niż maksimum określone przez użytkownika

systemu.

WB3

System będzie zawierał udogodnienia do diagnozowania

sprzętu, które

należy uruchamiać co najmniej 4 razy na

godzinę.

WB4

System będzie zawierał procedurę obsługi wszystkich wyjątków

wskazanych w tabeli 3.

WB5

Dźwiękowy sygnał alarmowy będzie włączany po wykryciu

każdej

anomalii sprzętu; wówczas należy również wyświetlić

komunikat diagnostyczny zgodnie z definicjami z tabeli 4.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Specyfikowanie

zabezpieczenia



Specyfikacja

wymagań

stawianych

zabezpieczeniu ma coś wspólnego z
wymaganiami stawianymi bezpieczeństwu.



Nie ma sensu określać ich liczbowo,
ponieważ

wymagania

stawiane

zabezpieczeniom

są

zwykle

wymaganiami”nie będzie”, w których
definiuje się niedopuszczalne zachowania,
a nie oczekiwaną funkcjonalność systemu.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Różnice pomiędzy specyfikacjami

wymagań, a specyfikacjami

bezpieczeństwa



Cykl życia bezpieczeństwa obejmujący wszystkie aspekty

zarządzania

bezpieczeństwem

jest

starannie

opracowany.

Dziedzina specyfikowania i zarządzania zabezpieczeniem jest

jeszcze bardzo niedojrzała i nie istnieje powszechnie przyjęty

odpowiednik cyklu życia bezpieczeństwa.



Zbiór sytuacji grożących zabezpieczeniu systemu jest uniwersalny.

Wszystkie systemy muszą być chronione przed intruzami, odmową

realizacji usług itd.. Zagrożenia w systemach krytycznych dla

bezpieczeństwa są zwykle charakterystyczne dla jednej dziedziny.



Techniki i technologie zabezpieczenia, takie jak szyfrowanie i

urządzenia do uwierzytelniania, są dobrze opracowane. Wiele

technologii zabezpieczenia przygotowano jednak dla szczególnych

systemów (takich jak systemy wojskowe i finansowe). Ich

przekazanie do powszechnego użytku wiąże się z pewnymi

trudnościami.

Techniki

związane

z

bezpieczeństwem

oprogramowania są ciągle tematem badań.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Specyfikowanie zabezpieczeń

Macierz

groźba-ryzyko

Macierz

groźba-ryzyko

Lista aktywów

systemowych

Lista aktywów

systemowych

Opis aktywów

i gróźb

Opis aktywów

i gróźb

Wymagania

stawiane

zabezpieczeniom

Wymagania

stawiane

zabezpieczeniom

Analiza

technologii

zabezpieczeń

Analiza

technologii

zabezpieczeń

Przyporządkowanie

gróźb

Przyporządkowanie

gróźb

Analizowanie

technologii

Analizowanie

technologii

Analiza gróźb

i oszacowanie

ryzyka

Analiza gróźb

i oszacowanie

ryzyka

Identyfikacja

aktywów

Identyfikacja

aktywów

Specyfikacja
wymagań
stawianych
zabezpieczeniom

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Kroki procesu specyfikowania

wymagań



Identyfikacja i wycena aktywów. Rozpoznaje się aktywa (dane i

programy) i ich oczekiwany stopień ochrony. Stopień pożądanej

ochrony zależy zwykle od wartości składnika majątku. Plik z

hasłami ma zatem zwykle większa wartość niż zbiór ogólnie

dostępnych witryn WWW, ponieważ potencjalny atak na plik z

hasłami ma poważne konsekwencje dla całego systemu.



Analiza gróźb i oszacowanie ryzyka. Rozpoznaje się możliwe

groźby dla zabezpieczeń systemu i ocenia ryzyko związane z

każdą z tych gróźb.



Przyporządkowanie gróźb. Rozpoznane groźby przyporządkowuje

się do aktywów. Dla każdego zidentyfikowanego składnika

majątku powstaje lista związanych z nim gróźb.



Analizowanie technologii. Ocenia się dostępne technologie

zabezpieczeń i ich skuteczność na rozpoznane groźby.



Specyfikacja

wymagań

stawianych

zabezpieczeniom.

Specyfikuje się wymagania stawiane zabezpieczeniom. Tam,

gdzie ma to sens, w specyfikacji wymagań wskazuje się

technologie zabezpieczeń, które można zastosować w celu

ochrony systemu przed groźbami.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Główne tezy



Wymagania niezawodnościowe należy zdefiniować

ilościowo i uwzględnić w specyfikacji wymagań systemu.



Istnieje

kilka

miar

niezawodności,

takich

jak

prawdopodobieństwo wystąpienia awarii przy zleceniu,

częstość występowania awarii, średni czas awarii i

dostępność. Wybór najbardziej odpowiedniej miary w

wypadku konkretnego systemu zależy od jego rodzaju i

dziedziny zastosowania. W różnych podsystemach

można wykorzystać inne miary.



Niefunkcjonalna specyfikacja niezawodnościowa może

powodować funkcjonalne wymagania systemu, w

których wskazuje się jego cechy umożliwiające

zmniejszenie liczby awarii systemu i przez to

zwiększenie jego niezawodności.

©Ian Sommerville 2004

Inżynieria oprogramowania, Rozdział 17

Główne tezy



Analiza

zagrożeń

to

zasadnicza

czynność

procesu

specyfikowania bezpieczeństwa. Obejmuje identyfikację

sytuacji zagrożeń, które czyhają na bezpieczeństwo systemu.

Opracowuje się wówczas wymagania systemowe, których

spełnienie ma zapewnić, że te zagrożenia się nie pojawią, a

nawet ich wystąpienie nie doprowadzi do wypadku.



Analiza ryzyka to proces oceny prawdopodobieństwa, ze

zagrożenie doprowadzi do wypadku. W czasie analizy ryzyka

identyfikuje się krytyczne zagrożenia, których należy uniknąć,

i klasyfikuje ryzyka według ich wagi.



Aby określić wymagania stawiane zabezpieczeniom, należy

rozpoznać aktywa, które trzeba chronić, i ustalić, jakie

techniki i technologie zabezpieczenia wykorzystać do ochrony

tych aktywów, oraz w jaki sposób to zrobić.