Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Specyfikowanie systemów krytycznych l Celem tego rozdziału jest wyjaśnienie, jak specyfikować

Podobne prezentacje


Prezentacja na temat: "©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Specyfikowanie systemów krytycznych l Celem tego rozdziału jest wyjaśnienie, jak specyfikować"— Zapis prezentacji:

1 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Specyfikowanie systemów krytycznych l Celem tego rozdziału jest wyjaśnienie, jak specyfikować wymagania funkcjonalne i niefunkcjonalne wobec pewności.

2 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Cele l Znać kilka miar służących do określania niezawodności i wiedzieć, jak należy ich używać do specyfikowania wymagań niezawodnościowych. l Wiedzieć, jak z analizy ryzyka i zagrożeń wywnioskować wymagania stawiane bezpieczeństwu systemów krytycznych. l Znać podobieństwa między procesami specyfikowania wymagań stawianych bezpieczeństwu i zabezpieczeniu.

3 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Zawartość l Specyfikowanie niezawodności systemu l Specyfikowanie bezpieczeństwa l Specyfikowanie zabezpieczenia

4 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Jakość specyfikacji systemów krytycznych l 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.

5 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Pewność systemów krytycznych l 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.

6 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Wymagania typu nie będzie l 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).

7 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Specyfikowanie niezawodności systemu l Niezawodność jest złożonym pojęciem, które zawsze należy rozważać na poziomie systemu, a nie poszczególnych komponentów. l 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.

8 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Wymiary, które należy wziąć pod uwagę przy specyfikowaniu niezawodności l Niezawodność sprzętu. Jakie jest prawdopodobieństwo awarii komponentu sprzętowego i jak dużo czasu potrzeba na jej usunięcie? l Niezawodność oprogramowania. Jakie jest prawdopodobieństwo wytworzenia niepoprawnego wyniku przez komponent programowy? l Niezawodność operatora. Jakie jest prawdopodobieństwo popełnienia błędu przez operatora?

9 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Inżynieria niezawodności oprogramowania l Jest specjalistyczna gałęzią inżynierii oprogramowania, poświęconą dokonywaniu ogólnej oceny niezawodności systemów. l 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. l 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)

10 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Przykłady wymagań niezawodnościowych l 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. l W procesie inicjowania system będzie sprawdzał, czy wszystkie dyski nie zawierają uszkodzonych bloków. l System musi być zaimplementowany za pomocą bezpiecznego podzbioru Ady i sprawdzony za pomocą analizy statycznej.

11 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 l Pierwsze miary niezawodności dotyczyły komponentów sprzętowych. l Awarie takich komponentów są nieuchronne ze względu na czynniki fizyczne, takie jak zużycie ścierne, ogrzewanie elektryczne itd. l Te miary sprzętowe nie zawsze są odpowiednie do specyfikowania niezawodności oprogramowania, ponieważ natury awarii sprzętu i oprogramowania są różne. l 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

12 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 MiaraObjaśnienie POFODPrawdopodobieństwo awarii przy zleceniu. Prawdopodobieństwo, że Probability system ulegnie awarii po zleceniu mu usługi. POFOD o wartości 0,001 of failureoznacza, że jedno zlecenie na tysiąc skończy się awarią. on demand ROCOFCzęstotliwość występowania awarii. Częstotliwość występowania Rateof failurenieoczekiwanych zachowań. ROCOF o wartości 0,002 oznacza, że w Occurencecią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 timesystemu. MTTF o wartości 500 oznacza, że co 500 jednostek czasu to Failuremożna oczekiwać jednej awarii. AVAILDostępność. Prawdopodobieństwo, że system jest dostępny dla Availabilityuż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

13 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Miary niezawodności l 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. l 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ć. l Ś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. l 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.

14 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Rodzaje pomiarów, które można wykonać szacując niezawodność systemu l Liczba awarii systemu w czasie obsługi ustalonej liczby żądań usług. Służy do wyznaczenia POFOD. l Czas (lub liczba transakcji) między awariami systemu. Służy do wyznaczania ROCOF i MTTF. l 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.

15 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Niefunkcjonalne wymagania niezawodnościowe l W wielu dokumentacjach wymagań systemowych wymagania niezawodnościowe są niestarannie określone. l Specyfikacje niezawodności są subiektywne i niemierzalne. l Zdania, takie jak Oprogramowanie powinno być niezawodne przy normalnym użytkowaniu, nic nie znaczą. l Stwierdzenia niby ilościowe są równie bezużyteczne.

16 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Klasyfikacja awarii Klasa awariiOpis ChwilowaZdarza się tylko dla niektórych danych wejściowych TrwałaNastępuje dla wszystkich danych wejściowych UsuwalnaSystem może ją usunąć bez interwencji operatora NieusuwalnaUsunięcie awarii wymaga interwencji operatora NieniszczącaAwaria nie powoduje zniszczenia stanu i danych systemu NiszczącaAwaria powoduje zniszczenie stanu i danych systemu

17 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Czynności prowadzące do opracowania specyfikacji niezawodności l Dla każdego zidentyfikowanego podsystemu należy wskazać różne rozdaje możliwych awarii systemu i zanalizować konsekwencje tych awarii. l Na podstawie wyników analizy awarii systemu trzeba podzielić awarie na klasy. Dobrym punktem wyjściowym może być klasyfikacja z rysunku. l 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ą. l 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.

18 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Przykład specyfikacji niezawodności l Rozważmy wymagania niezawodnościowe stawiane bankomatowi. l Przypuśćmy, że każda maszyna w sieci jest używana około 300 razy dziennie. l Czas życia sprzętu systemu wynosi osiem lat, a oprogramowanie jest aktualizowane średnio raz na dwa lata. l W czasie działania jednej wersji oprogramowania każda maszyna obsługuje około transakcji. l Sieć banku składa się z 1000 maszyn. l Oznacza to, że dziennie następuje transakcji w centralnej bazie danych (około 100 milionów rocznie). l 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.

19 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Specyfikacja niezawodności bankomatu Klasa awariiPrzykład Miara niezawodności TrwałaSystem nie działa z żadną wsuwaną ROCOF nieniszczącakartą. Usunięcie awarii wymaga ponownego 1 zdarzenie/1000 dni uruchomienia oprogramowania. ChwilowaPasek magnetyczny nieuszkodzonej ROCOF nieniszczącawsuniętej karty nie może być odczytany 1 na 1000 transakcji Trwała Zestaw jednoczesnych transakcji w sieci Niemierzalna! Nie powinna niszczącapowoduje uszkodzenie bazy danych się zdarzyć w czasie życia systemu

20 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 l Awarie chwilowe, które mogą być usunięte przez użytkownika, np. przez ponowne uruchomienie lub dostrojenie maszyny. l Awarie trwałe, które wymagają naprawy maszyny przez producenta. Prawdopodobieństwo awarii tego rodzaju powinno być znacznie mniejsze. Rodzaje awarii

21 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Uwagi l Koszt opracowania i zatwierdzenia specyfikacji niezawodności systemu jest bardzo wysoki. l Firmy musza realnie oceniać konieczność ponoszenia takich kosztów. l 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. l Takie koszty nie są na pewno uzasadnione w wypadku większości rodzajów systemów gospodarczych i naukowych. l 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.

22 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Specyfikowanie bezpieczeństwa l Bezpieczne działanie jest wymaganą cechą systemów oprogramowania związanych z bezpieczeństwem. l W czasie procesu inżynierii wymagań należy więc rozważyć potencjalne zagrożenia. l W wypadku każdego zagrożenia należy oszacować powodowane przez nie ryzyko. l W specyfikacji można opisać, jak oprogramowanie powinno się zachowywać, żeby zmniejszyć to ryzyko, lub stwierdzić, że ryzyko nie może się nigdy pojawić.

23 Cykl życia bezpieczeństwa zgodny z IEC ©Ian Sommerville 2000Dependable 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 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

24 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Zarządzanie bezpieczeństwem l Nie kończy się w chwili dostarczenia systemu. l Po dostarczeniu system musi być zainstalowany zgodnie z planem, aby analiza ryzyka była ciągle aktualna. l Zatwierdzenie bezpieczeństwa również ma miejsce w trakcie działania i (zwłaszcza) pielęgnacji systemu. l 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. l 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).

25 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Analiza zagrożeń i ryzyka l Analiza zagrożeń i ryzyka polega na badaniu systemu i środowiska, w jakim system działa. l 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. l To złożony i trudny proces, który wymaga niestandardowego myślenia i wiedzy ekspertów z rozmaitych dziedzin. l Powinien być wykonywany przez doświadczonych inżynierów z udziałem ekspertów z dziedziny zastosowania i profesjonalnych doradców od bezpieczeństwa. l Do identyfikacji zagrożeń można użyć sposobów pracy grupowej, takich jak burza mózgów. l 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.

26 ©Ian Sommerville 2004Inż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ń Oszacowanie ryzyka Oszacowanie ryzyka Analiza drzewa awarii Analiza drzewa awarii Wstępne wymagania bezpieczeństwa Wstępne wymagania bezpieczeństwa

27 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 l 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. l 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. l Rozkładanie zagrożeń. Każde zagrożenie rozpatruje się oddzielnie i szuka jego przyczyn. l Ocena szans zmniejszenia ryzyka. Znajduje się propozycje zmniejszenia i redukcji rozpoznanego ryzyka. Proces analizy zagrożeń i ryzyka

28 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Etapy analizy dla wielkich systemów l Wstępna analiza zagrożeń, która polega na rozpoznaniu najważniejszych zagrożeń. l Bardziej szczegółowa analiza zagrożeń w systemach i podsystemach. l Analiza zagrożeń oprogramowania, w czasie której rozważa się ryzyko awarii oprogramowania. l Analiza zagrożeń operacyjnych, która jest poświęcona systemowemu interfejsowi użytkownika i ryzyku, wynikającemu z błędów operatora.

29 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 l Za duża dawka insuliny (niepowodzenie usługi). l Za mała dawka insuliny (niepowodzenie usługi). l Brak zasilania w związku z wyczerpaniem baterii (elektryczne). l Elektryczna interferencja maszyny z innym sprzętem medycznym, takim jak rozrusznik serca (elektryczne). l Złe podłączenie detektora lub efektora spowodowane przez niedopasowanie (fizyczne). l Części maszyny pozostawione w ciele chorego (biologiczne). l Zakażenie spowodowane podłączeniem maszyny (biologiczne). l Reakcja alergiczna na materiał lub insulinę używaną w maszynie (biologiczne). System podawania insuliny

30 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Analiza drzewa awarii l W wypadku każdego rozpoznanego zagrożenia należy przeprowadzić analizę, której celem jest znalezienie sytuacji powodujących to zagrożenie. l Istnieją dedukcyjne i indukcyjne metody analizy zagrożeń. l Metody dedukcyjne (zwykle łatwiejsze w użyciu) polegają na rozpoczęciu od zagrożenia i na jego podstawie poszukiwania możliwych awarii systemu. l Metody indukcyjne polegają na rozpoczęciu od awarii systemu i poszukiwaniu zagrożeń, które mogą powstać. l Jeśli to możliwe, w analizie zagrożeń należy użyć obu rodzajów metod

31 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Analiza drzewa awarii l Ta szeroko stosowana metoda analizy zagrożeń jest łatwa do zrozumienia bez fachowej wiedzy. l Analiza drzewa awarii polega na rozpoznaniu niepożądanego zdarzenia i badania go wstecz, aby odkryć możliwe przyczyny tego zagrożenia. l Zagrożenie jest korzeniem tego drzewa, a liście reprezentują potencjalne przyczyny zagrożenia.

32 ©Ian Sommerville 2004Inż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

33 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Szacowanie ryzyka l Proces szacowania ryzyka rozpoczyna się po zidentyfikowaniu wszystkich zagrożeń. l Szacując ryzyko, ocenia się znaczenie każdego zagrożenia, prawdopodobieństwo jego wystąpienia i prawdopodobieństwo, że doprowadzi ono do wypadku. l W wyniku tego procesu dla każdego zagrożenia powstaje opinia o jego akceptowalności.

34 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Poziomy akceptowalności zagrożenia l 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. l 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. l 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.

35 ©Ian Sommerville 2004Inż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

36 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Proces szacowania ryzyka l Obejmuje kalkulacje prawdopodobieństwa i dotkliwości zagrożenia. l Zwykle osiągnięcie dokładnych wyników tej czynności jest bardzo trudne i najczęściej zależy od inżynierskiego rozsądku. l Prawdopodobieństwa i dotkliwość są oceniane za pomocą wartości względnych, takich jak prawdopodobne, niemożliwe, rzadkie, duża, średnia i mała. l Doświadczenia zdobyte przy pracy nad poprzednimi systemami umożliwiają skojarzenie z tymi pojęciami pewnych wartości liczbowych. l Wypadki są jednak dość rzadkie, zwykle więc trudno jest zweryfikować dokładność takiej wartości.

37 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Analiza ryzyka związanego z zagrożeniami Rozpoznane zagrożenie Prawdo- Dotkliwość OszacowanieAkcepto- 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

38 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Redukcja ryzyka l 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.

39 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Strategie redukcji ryzyka l Unikanie zagrożeń. System jest zaprojektowany tak, aby zagrożenia nie mogły się pojawić. l Wykrywanie i eliminowanie. System jest zaprojektowany tak, aby wykrywać i eliminować zagrożenia, zanim doprowadzą do wypadku. l Ograniczanie szkód. System jest zaprojektowany tak, aby zminimalizować konsekwencje wypadków.

40 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Potencjalne problemy oprogramowania l 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. l 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ą.

41 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Przykłady wymagań stawianych bezpieczeństwu pompy insulinowej WB1Jedna dawka insuliny podana przez system nie będzie większa niż maksimum określone przez użytkownika systemu. WB2Całkowita dzienna dawka insuliny podana przez system nie będzie większa niż maksimum określone przez użytkownika systemu. WB3System będzie zawierał udogodnienia do diagnozowania sprzętu, które należy uruchamiać co najmniej 4 razy na godzinę. WB4System będzie zawierał procedurę obsługi wszystkich wyjątków wskazanych w tabeli 3. WB5Dź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.

42 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Specyfikowanie zabezpieczenia l Specyfikacja wymagań stawianych zabezpieczeniu ma coś wspólnego z wymaganiami stawianymi bezpieczeństwu. l Nie ma sensu określać ich liczbowo, ponieważ wymagania stawiane zabezpieczeniom są zwykle wymaganiaminie będzie, w których definiuje się niedopuszczalne zachowania, a nie oczekiwaną funkcjonalność systemu.

43 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Różnice pomiędzy specyfikacjami wymagań, a specyfikacjami bezpieczeństwa l 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. l 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. l 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ń.

44 ©Ian Sommerville 2004Inż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

45 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Kroki procesu specyfikowania wymagań l 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. l 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. l 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. l Analizowanie technologii. Ocenia się dostępne technologie zabezpieczeń i ich skuteczność na rozpoznane groźby. l 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.

46 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Główne tezy l Wymagania niezawodnościowe należy zdefiniować ilościowo i uwzględnić w specyfikacji wymagań systemu. l 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. l 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.

47 ©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Główne tezy l 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. l 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. l 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ć.


Pobierz ppt "©Ian Sommerville 2004Inżynieria oprogramowania, Rozdział 17 Specyfikowanie systemów krytycznych l Celem tego rozdziału jest wyjaśnienie, jak specyfikować"

Podobne prezentacje


Reklamy Google