Karol C H R A B A Ń S K I
Wstęp
Norma ISO /IEC 12207 została opracowana przez Wspólną Komisję Techniczną ISO /IEC JT C 1, Technologia informacyjna, Podkomisja SC 7, Inżynieria programowania. Jej tytuł jest następujący Technologia informacyjna - procesy cyklu życia oprogramowania” 1
Wskazanie powodów dla których powstała norma
Zapoznając się z treścią normy ( ISO /IEC 12 207) można przedstawić następujące powody dla których to podjęto i zakończono prace z nią związane.2 Oto one:
Powód 1 :
Oprogramowanie stanowi integralną część : a) technologii informacyjnej i
b) systemów konwencjonalnych, takich, jak transport, wojsko, opieka medyczna i finanse
Powód 2 :
Daje się zaobserwować niekontrolowany wzrost ilości norm, procedur, metod, narzędzi i warunków służących rozwijaniu oprogramowania i zarządzania nim.
Powód 3 :
Ten niekontrolowany wzrost rodzi problemy w sferze zarządzania oprogramowaniem
i inżynierii oprogramowania. W szczególności w zakresie integrowania produktów i usług.
W oparciu o te obserwacje można wysnuć następującą tezę
1 Projekty Norm Międzynarodowych przyjęte przez wspólną komisję techniczną są przekazywane organom krajowym i poddawane glosowaniu. Opublikowanie jako Normy Międzynarodowej wymaga akceptacji co najmniej 75% spośród krajowych organów biorących udział w glosowaniu.
2 Norma posiada trzy aneksy . Aneks A stanowi integralną część niniejszej normy międzynarodowej. Aneksy B i C mająjedynie charakter informacyjny.
183
Dyscyplina oprogramowania wymaga przejścia od stanu niekontrolowanego wzrostu do pewnego wspólnego modelu.
Wspomniany wspólny model powinien spełnić następujące wymaganie c e l:
Praktycy zajmujący się oprogramowaniem mogliby stosować ten model . co pozwoliłoby na rozmawianie ..wspólnym językiem” w procesie tworzenia oprogramowania i zarządzania nim.
Norma ISO/ IE C 12207 opisuje wspomniany model . Obejmuje on cykl życia oprogramowania od fazy konceptualizacji pomysłów do wycofania programu (oprogramowania ) zużycia. Model ten składa się z procesów nabywania i dostarczania produktów i usług związanych z oprogramowaniem. Umożliwia on ponadto kontrolowanie
i doskonalenie tych procesów.
Założenia modelu cyklu życia oprogramowania
Poniżej podjęto próbę zidentyfikowania -poprzez analizę normy -założeń opisanego modelu cyklu życia oprogramowania. Oto te założenia :
1.Procesy objęte modelem tworzą kompleksowy zestaw . Dodatkowo procesy są uszczegółowiane poprzez podprocesy, działania i zadania
2.0rganizacja, zależnie od celu, może wybrać odpowiednie elementy (podzbiory) kompleksowego zestawu -o strukturze podanej w punkcie 1- odpowiadające jej potrzebom. Model jest zatem tak pomyślany, aby można było go dostosować do konkretnej organizacji, projektu (przedsięwzięcia) lub aplikacji (systemu informatycznego) . Proces przystosowania polega na pomijaniu procesów, działań i zadań nie mających zastosowania
3. Z modelu można korzystać zarówno wtedy, gdy : 3.1 oprogramowanie stanowi odrębną całość, jak i wtedy gdy 3.2 osadzone jest w ogólnym systemie lub
3.3 stanowi jego integralną część.
4. Model powinien dla procesów cyklu życia oprogramowania uwzględniać odpowiednio zdefiniowaną terminologię , która może stanowić punkt odniesienia dla branży oprogramowania.
5.Wspomniane procesy, działania i zadania, należy stosować w trakcie:
5.1 nabywania systemu, którego częścią jest oprogramowanie,
5.2 nabywania produktu programistycznego stanowiącego odrębną całość oraz 5.3 nabywania usług programistycznych, a także
5.4 dostarczania, rozwijania, obsługi i konserwowania produktów programistycznych, (oprogramowanie obejmuje związaną z nim część oprogramowania sprzętowego.)
6. Model powinien obejmować również proces, który można zastosować do definiowania, kontrolowania i doskonalenia procesów cyklu życia oprogramowania.
7. Model powinien mieć zastosowanie do realizacji procesów podanych w punkcie 5. Zarówno w przypadku oprogramowania wytwarzanego wewnątrz organizacji, jak i poza nią.
8. Procesy uwzględniane przez model w trakcie cyklu życia oprogramowania muszą być kompatybilne z procesami stosowanymi w trakcie cyklu życia systemu.
9. Model jest adresowany do sytuacji, w której występują dwie strony i może być z powodzeniem stosowany, gdy te dwie strony reprezentują tę samą organizację.
Sytuacja może dotyczyć zarówno nieformalnych porozumień, jak i prawomocnych kontraktów. Model może być stosowany przez jedną tylko stronę jako podjęte dobrowolnie zadania.
10. Model nie powinien być przeznaczony dla produktów programistycznych
„z półki” , o ile nie wchodzą one w skład dostarczanego produktu.
11.Model powinien być przeznaczony dla :
11.1 nabywców systemów oraz produktów i usług programistycznych, 11.2 ponadto dla dostawców,
11.3 twórców oprogramowania, 11.4 operatorów,
11.5 konserwatorów i użytkowników produktów programistycznych, a także 11.6 personelu kierowniczego, w tym kierowników odpowiedzialnych za zapewnienie jakości.
12. W kontrakcie ( umowie spisanej pomiędzy stronami) a nie w modelu powinny być uwzględniane dodatkowe procesy, działania i zadania o charakterze unikalnym lub specjalnym
Opracowany w oparciu o podane powyżej zasady model obrazujący cykl życia oprogramowania może posłużyć do oceny zgodności
Sposób określania zgodności projektu programistycznego z modelem cyklu życia oprogramowania
Tak jak już wspomniano norma opisuje model cyklu życia oprogramowania. Przykładowo dla konkretnego przedsięwzięcia (projektu) programistycznego z modelu wybiera się - w oparciu o wymagania ustalone w kontrakcie- procesy, działania i zadania . Sposób wyboru ułatwia znajomość zawartości aneksu A. Traktuje on o procesie przystosowania . Z uwagi na ograniczone ramy artykułu zagadnienie jest jedynie sygnalizowane.
Model cyklu życia oprogramowania opisany normą ISO /IEC 12 207 posiada również swoje ograniczenia. Opisuje je następny podrozdział
Ograniczenia stosowania modelu (normy)
Nie w każdej sytuacji należy stosować wspomnianą normę. Poniżej wskazano przypadki ograniczeń w jej stosowaniu.
1. Norma opisuje architekturę procesów cyklu życia oprogramowania, ale nie 185
określa szczegółowo, w jaki sposób należy wdrażać lub wykonywać działania i zadania składające się na te procesy.
2.Norma nie ma na celu określenia nazwy, formatu lub formalnej treści dokumentów, jakie należy sporządzić. Może ona wymagać opracowania dokumentów zbliżonych pod względem kategorii lub rodzaju. Przykładem mogą być różne plany. Z normy nie wynika jednak, że dokumenty takie mają być opracowane lub zestawiane osobno lub łączone w jakiś określony sposób. Decyzje takie pozostawia się użytkownikowi normy.
3. Norma nie określa konkretnego modelu cyklu życia, ani metody rozwoju oprogramowania. Użytkownicy normy odpowiadają za wybór modelu cyklu życia dla projektu programistycznego oraz za odwzorowanie w tym modelu procesów, działań i zadań przewidzianych w niniejszej normie . Strony odpowiadają również za wybór i zastosowanie metod rozwoju oprogramowania oraz za wykonanie działań i zadań odpowiednich dla danego projektu programistycznego.
4. Norma z założenia nie pozostaje w sprzeczności z wytycznymi, normami lub procedurami już obowiązującymi w danej organizacji, niemniej wszelkie takie konflikty należy rozwiązywać, a ewentualne warunki i sytuacje, w których norma nie obowiązuje, należy określić na piśmie jako wyjątki od niej.
5. Używane w tekście niniejszej normy słowo „powinien” wyraża postanowienie, które jest wiążące dla dwóch lub większej liczby stron, czas przyszły wyraża zamiar lub intencję jednej strony, „zaleca się” wyraża zalecenie wyboru jednej spośród większej liczby możliwości, a czasownik „może” wskazuje sposób postępowania dopuszczalny w ramach ograniczeń niniejszej normy .
6. W niniejszej normie pojawia się szereg wykazów zadań: żaden z nich nie jest rozumiany jako wyczerpujący - mają jedynie charakter przykładowy.
7. Opisywana norma przywołuje inne normy.3
Wymienione w przypisie normy zawierają postanowienia, które przywołane w tym tekście tworzą postanowienia niniejszej normy (ISO /IEC 12 207). Podane wersje były obowiązujące w momencie publikacji. Wszystkie normy mogą ulec zmianie, dlatego stronom umów opartych na niniejszej normie zaleca się sprawdzenie, czy istnieje możliwość zastosowania najbardziej aktualnych wersji podanych niżej norm. Organizacje członkowskie IE C i ISO przechowują rejestry aktualnie obowiązujących Norm Międzynarodowych.
3 ISO/AFNOR: 1989, Słownik informatyki. ,ISO/IEC 2382-1: 1993, Technologia informacyjna - Słownictwo - część 1: Terminy podstawowe , ISO/IEC 2382-20: 1990, Technologia informacyjna - Słownictwo - część 20: Rozwijanie systemów, ISO 8402:
1994, Zarządzanie jakością i zapewnienie jakości - Słownictwo, ISO 9001: 1994, Systemy jakości — Model zapewnienia jakości w projektowaniu, rozwoju, produkcji, instalowaniu i serwisie, ISO/IEC 9126: 1991, Technologia informacyjna - Ocena produktów programistycznych - Charakterystyki jakościowe i wytyczne odnośnie ich stosowania.
Prezentacja procesów, podprocesów i działań dla cyklu życia oprogramowania
Norma wskazuje na trzy rodzaje procesów :
a) Podstawowe procesy cyklu życia obejmują pięć procesów, które służą stronom podstawowym w trakcie cyklu życia oprogramowania. Zalicza się do nich następujące podprocesy: nabywania, dostawy, rozwoju, obsługi, konserwacji .Strona pierwsza to strona, która inicjuje lub realizuje rozwój, obsługę lub konserwację produktów programistycznych. Są to: nabywca, dostawca, twórca oprogramowania i konserwator produktów programistycznych. Proces podstawowy z podziałem na podprocesy i działania pokazuje rysunek nr 1 b) Pomocnicze procesy cyklu życia to takie za które odpowiada organizacja
inicjująca i realizująca ten proces. Organizacja ta zapewnia samo istnienie i funkcjonowanie procesu. Można do nich zaliczyć podprocesy dokumentowania, zarządzania konfiguracją, zapewnienia jakości, weryfikacji, walidacji, wspólnych przeglądów, audytu i rozwiązywania problemów. Proces pomocniczy z podziałem na podprocesy i działania pokazuje rysunek nr 2 c) Organizacyjne procesy cyklu życia oprogramowania odnoszą się do
realizowanego projektu ( przedsięwzięcia ) .Elementy wymagane przez projekt są podprocesami organizacyjnych procesów cyklu życia oprogramowania . Zalicza się do nich takie podprocesy jak: zarządzania , infrastruktury, doskonalenia, szkolenia. Proces organizacyjny z podziałem na podprocesy i działania pokazuje rysunek nr 3
Wydaje się , że zasadnym jest zainteresowanie się miejscem zapewnienia jakości w cyklu życia oprogramowania
Miejsce zapewnienia jakości w cyklu życia oprogramowania
Zapewnienie jakości jest podprocesem w ramach pomocniczych procesów cyklu życia oprogramowania . M a zabezpieczyć z dostateczną pewnością zgodność produktów programistycznych i procesów w cyklu życia projektu z określonymi dla nich wymaganiami. Dodatkowo chodzi o zapewnienie przestrzegania ustalonych dla nich planów. Zachowanie bezstronności w procesie zapewnienia jakości wymaga swobody organizacyjnej i uprawnień w przypadku osób bezpośrednio odpowiedzialnych za opracowanie produktu programistycznego lub zrealizowanie procesu w projekcie.
Zapewnienie jakości może mieć charakter wewnętrzny lub zewnętrzny.
Zależnie od tego, czy dowody jakości produktu lub procesu są okazywane kierownictwu dostawcy, czy klientowi. W procesie zapewnienia jakości mogą być wykorzystywane wyniki innych procesów pomocniczych, tzn. weryfikacji, walidacji, wspólnych przeglądów, audytów
i rozwiązywania problemów.
Opublikowana w maju 2002 roku poprawka oznaczona jako 1 do normy ISO /IEC 12 207 określa cel zapewnienia jakości jako zapewnienie zgodności
187
produktów roboczych i procesów z ustalonymi postanowieniami i planami.
W wyniku pomyślnego wdrożenia procesu zapewnienia jakości powinny być osiągnięte następujące wyniki:
a) opracowana zostanie strategia zapewnienia jakości
b) są tworzone i przechowywane dowody zapewnienia jakości
c) są identyfikowane i rejestrowane problemy i/lub przypadki niezgodności z wymaganiami umowy
d) weryfikowana jest zgodność produktów, procesów i działań z odpowiednimi normami, procedurami i wymaganiami
Bliższa charakterystyka podprocesu zapewnienie jakości nastąpi poprzez wskazanie
i charakterystykę poniższych działań : 1) Wdrożenie procesu;
2) Zapewnienie produktu;
3) Zapewnienie procesu;
4) Zapewnienie systemów jakości.
Podproces wdrażania procesu składa się z następujących zadań:
Zadanie 1: Należy ustalić proces zapewnienia jakości przystosowany do projektu.
Celami procesu zapewnienia jakości powinno być zapewnienie zgodności tych produktów i procesów wykorzystywanych do ich dostarczenia z określonymi dla nich wymaganiami i przestrzeganie ustalonych planów.
Zadanie 2 : Podproces zapewnienia jakości powinien być skoordynowany z odpowiednimi podprocesami takimi jak: weryfikacja, walidacja, wspólne przeglądy, audyt, rozwiązywanie problemów
Zadanie 3 : Należy opracować, udokumentować, wdrożyć plan wykonywania działań i zadań procesu zapewnienia jakości i utrzymywać go przez okres obowiązywania kontraktu. Plan powinien obejmować:
a) Normy jakości, metodologie, procedury i narzędzia wykonywania działań zapewnienia jakości (lub odniesienia do nich w oficjalnej dokumentacji organizacji);
b) Procedury przeglądania kontraktów i ich koordynacji;
c) Procedury identyfikacji, gromadzenia, segregowania, utrzymywania i usuwania zapisów dotyczących jakości;
d) Zasoby, harmonogram i zakresy odpowiedzialności związane z prowadzeniem działań zapewnienia jakości;
e) Wybrane działania i zadania dotyczące procesów pomocniczych (tak jak podano w zadaniu 2)
Zadanie 4 : Należy wykonywać zaplanowane i aktualnie realizowane działania i zadania dotyczące zapewnienia jakości. W razie stwierdzenia problemów lub niezgodności dotyczących wymagań kontraktu, należy je udokumentować i posłużyć się nimi jako danymi wejściowymi do podprocesu rozwiązywania
problemów . Należy sporządzać i utrzymywać zapisy dotyczące tych działań i zadań, ich wykonania, problemów z nimi związanych i ich rozwiązywania.
Zadanie 5 : Zapisy dotyczące działań i zadań dotyczących zapewnienia jakości należy udostępnić nabywcy, stosownie do postanowień kontraktu.
Zadanie 6 : Osobom odpowiedzialnym za zapewnienie zgodności z wymaganiami kontraktu należy zapewnić swobodę organizacyjną zasoby i uprawnienia umożliwiające dokonanie obiektywnych ocen oraz zainicjowanie, przeprowadzenie i rozwiązanie problemów oraz weryfikację rozwiązań.
Poniżej podano i opisano działania wchodzące w skład podprocesu zapewnienia produktu:
Zadanie 1 : Należy zapewnić udokumentowanie wszystkich planów wymaganych na podstawie kontraktu, ich zgodność z kontraktem, wzajemną spójność i realizację stosownie
do wymagań.
Zadanie 2: Należy zapewnić zgodność z kontraktem , planową realizację produktów programistycznych i dotyczących ich dokumentów.
Zadanie 3: Przygotowując produkty programistyczne do dostarczenia należy zapewnić ich pełną zgodność z wymaganiami kontraktowymi i oczekiwaniami nabywcy.
Poniżej podano i opisano działania wchodzące w skład podprocesu zapewnienie procesu.
Zadanie 1: Należy zapewnić zgodność z kontraktem i planową realizację procesów cyklu życia oprogramowania (dostawy, rozwoju, obsługi, konserwacji i procesów pomocniczych,
w tym procesu zapewnienia jakości).
Zadanie 2 : Należy zapewnić zgodność z kontraktem wewnętrznych praktyk programistycznych, środowiska rozwoju, środowiska testów i bibliotek.
Zadanie 3: Należy zapewnić przekazanie podwykonawcy odpowiednich wymagań głównego kontraktu oraz spełnienie tych wymagań przez produkty programistyczne podwykonawcy.
Zadanie 4 : Należy zapewnić nabywcy i innym podmiotom wymagane wsparcie i współpracę, zgodnie z kontraktem, negocjacjami i planami.
Zadanie 5: Należy zapewnić zgodność pomiarów produktu programistycznego i procesu
z ustalonymi normami i procedurami.
Zadanie 6: Należy zapewnić posiadanie przez przydzielonych do zadań pracowników umiejętności i wiedzy niezbędnych do spełnienia wymagań projektu oraz umożliwić im niezbędne szkolenie.
Odnośnie działań wchodzących w skład podprocesu zapewnienie systemów jakości określono jedno zadanie. Polega ono na zapewnieniu dodatkowych
189
działań w zakresie zarządzania jakością zgodnie z wymaganiami normy ISO 9001, stosownie do postanowień kontraktu..
Ocena przydatności modelu dla projektowania, dokumentowania i utrzymania systemów zarządzania jakością w organizacji wytwarzającej oprogramowania
Autor dokonał oceny przydatności modelu cyklu życia oprogramowania, który został opisany w normie ISO /IEC 12 207 sięgając do swoich wieloletnich doświadczeń jako audytora wiodącego systemów zarządzania jakością zgodnych z ISO 9001:2000 w organizacjach wytwarzających oprogramowanie, projektanta systemów zarządzania jakością dla tychże organizacji zgodnych z ISO 9001:2000, przedsiębiorcy prowadzącego organizację wytwarzającą oprogramowanie. Ocena przydatności scharakteryzowanego modelu dotyczy:
a) wskazania, że zapewnienie jakości jest jedynie jednym z elementów składających się na model cyklu życia oprogramowania
b) wskazania przez normę ISO /IEC 12 207 wymagań podanych przez normę ISO 9001 jako właściwą do zaprojektowania, udokumentowania, utrzymania systemu zarządzania jakością dla organizacji wytwarzającej oprogramowanie
c) podane w normie ISO /IEC 12 207 etapy cyklu życia oprogramowania mogą być przydatne w realizacji wymagań normy ISO 9001 i zaleceń podanych w ISO /IEC 90003. Szczególnie dotyczy to punktu 7 normy (realizacja wyrobu), podpunkt 7.1 (planowanie realizacji wyrobu).
Wspomniany podpunkt nakłada na organizację wymóg zaplanowania i opracowania procesów potrzebnych do realizacji wyrobu (tutaj oprogramowania)
Wypada wskazać, że poruszana w artykule tematyka powinna mieć coraz szersze grono odbiorców z uwagi na powszechność występowania oprogramowania w życiu codziennym .
Z tym związana jest konieczność wytwarzania oprogramowania, konserwowania i rozwijania. A te procesy zawierają się w cyklu życia oprogramowania.
Literatura
1. PN -EN ISO 9001 . Systemy zarządzania jakością .Wymagania. PKN wrzesień 2001
2. ISO /IEC 90003. Software engineering - Guidelines for the application of ISO 9001:2000 to Computer software. ISO first edition 2004-02-15.
3. ISO /IEC 12207. Information technology - Software life cycle processes.
ISO /IEC first edition 1995-08-01.
4. ISO /IEC 12207. Information technology - Software life cycle processes.
Amendment 1. ISO /IEC 2002 , amendment 2002-05-01.
Kjwwoo^^dO^
5. www.chrabanski.omi.pl
W Y K A Z D Z IA ŁA Ń
Inicjowania
Przygotowania z a p ia n ia ofertowego (przetargi) Proces nabywania Przygotowania i aktualizacji kontraklu
M onitorowania dostawcy Odbioru i zakończania
Inicjowania
Przygotowanie odpowiedzi Kontrakt
Proces dostawy' Planowanie W ykonanie i kontrola Przegląd i ocena D ostaw a i zakańczana
W drożenie procesu A naliza wymagań systemu Proj ektowanie architektury sy stan u A naliza wymagań oprogramowania Projektowanie architektury oprogramowania Szczegółowe projektowanie oprogramowania Proces rozwoju Kodowanie i testowanie oprogramowania
Integracja oprogramowania
Testowanie kwalifikacyjne oprogramowania Integracja systanu
Testowanie kwalifikacyjne systornu Instalacja oprogramowania
W sparcie przy' odbiorze oprogramowania
W drożenie procesu Proces obsŁia Testy obsługi
Obsługa systomu
W spomaganie użytkow nika
Wdrcżento procesu
A naliza p ro b lan u i m odyfikacji Proces konserwacji W drożenie m odyfikacji
Przeglądodbior konserwacji Migracja
Wycofanie oprogramowania
Rys.l Podstawowe procesy cyklu życia.
191
RO ZDZIAŁ XII
Z A R Z Ą D Z A N IE R Y Z Y K I E M S Y S T E M Ó W IN F O R M A C Y JN Y C H
Franciszek W O Ł O W S K I
Wprowadzenie
Plan działań na rzecz rozwoju społeczeństwa informacyjnego w Polsce na lata 2001-2006 zakłada, że administracja rządowa wykorzystująca techniki społeczeństwa informacyjnego ma służyć obywatelom poprzez swoją dostępność, poufność, wiarygodność i jakość - jednakowo na terenie całej Polski oraz w
powiązaniu z zasobami informacyjnymi innych krajów
Oznacza to, że należy zarządzać bezpieczeństwem tych systemów a z kolei aby to realizować należy Z A R Z Ą D Z A Ć R Y Z Y K IE M systemów informacyjnych.
Organizacje zawsze narażone były na ryzyko błędów i oszustw, ale skala tego ryzyka i szybkość zjaką mogą te zjawiska obecnie wystąpić, zwiększyła się wydatnie. Wraz z rozwojem komputerowych systemów pracujących w sieciach rozległych w tym w sieciach publicznych przetwarzających informacje, jak również rozliczające płatności, przepływ informacji i środków pieniężnych odbywa się w skali całego świata a problemy dotyczące systemów informatycznych i telekomunikacyjnych mogą przyczynić się do zakłóceń w działaniu organizacji i/lub jej niewypłacalności. Nie wywiązanie się z zobowiązań umownych, a także inne zakłócenia, czasem płynące też z organizacji i o dobrym standingu finansowym, poprzez reakcję łańcuchowa, mogą narazić każda organizację (mająca powiązania z organizacją dotknięta niekorzystnym zdarzeniem) na straty, powodując paraliż i zagrożenie dla całego systemu informacyjnego i finansowego.
Z tego względu „Zarządzanie ryzykiem” nie jest już indywidualna sprawa poszczególnych podmiotów gospodarczych lecz staje się obowiązkiem wobec środowiska, w którym ten podmiot działa, w niektórych krajach ten obowiązek jest określony prawem.
Częstokroć ryzyko w potocznym znaczeniu utożsamiane jest z zagrożeniem. Nie należy jednak tych pojęć utożsamiać.
Ryzyko jest to miernik narażenia 1 określający możliwość zaistnienia negatywnego zdarzenia w wyniku wykorzystania podatności zasobu z uwzględnieniem prawdopodobieństwa zaistnienia tego zdarzenia i wynikowego skutku - przez określone źródło zagrożenia. A bardziej zwięźle:
R Y Z Y K O = (szansa zaistnienia czyli prawdopodobieństwo) x (konsekwencje-czyli strata -negatywny skutek). Wynika z tego, że ryzyko jest wyrażone konkretną wartością, którą organizacja musi uwzględnić w swojej działalności.
1 wyrażony wielkością kwantyfikatywną lub kwalifikatywną
193
Uwzględnienie oznacza, że organizacja powinna porównać ryzyko z swoimi możliwościami pokrycia ewentualnych strat, gdy straty powstaną w przypadku urzeczywistnienia się ryzyka i w zależności od wyniku porównania powinna określić strategię i politykę w zakresie zarządzania ryzykiem. Możliwości pokrycia ewentualnych strat są wyrażone przez Maksymalne Dopuszczalne Ryzyko (M D R).
Jest to wielkość funduszy jakie organizacja może ponieść w przypadku wystąpienia niekorzystnych zdarzeń i w dalszym ciągu utrzymać się na rynku. Istnieje wiele złożonych sposobów wyliczenia tej wielkości, upraszczając można określić, że jest to część funduszy własnych, jaką organizacja, zważywszy jego strategię2, „godzi się” stracić w razie katastrofy - do czego można dodać część zysków operacyjnych („cash-flow” ), które także mogą pomóc we wchłonięciu ryzyka, oraz gwarancje, zwłaszcza o charakterze odszkodowań, obejmujące dany typ zdarzeń3.
Zatem M D R = □ F W + □ Zysk + □ Gwarancje4
gdzie □ F W jest częścią funduszy własnych (np. 20% ustalone jako maksymalny limit strat w przypadku totalnej katastrofy), □ Zysk to część rocznego zysku operacyjnego brutto, pozwalającego na wchłonięcie skutków katastrofy, zaś □ to szacunkowy wskaźnik odszkodowań (przy zbadaniu prawdopodobieństwa ich otrzymania) jako ewentualnej rekompensaty pieniężnej (bądź technicznej) w przypadku szkód powstałych w systemie informacyjnym.
Znając tą wielkość wystarczy ją porównać z wyliczoną wielkością realnie występującego ryzyka i gdy jest ona większa od tegoż ryzyka można się specjalnie nie martwić, gdyż nasza organizacja z każdej katastrofy wyjdzie obronną ręką.
Niestety takich przypadków jest niewiele. Najczęściej zdolności wchłonięcia skutków katastrofy są znacznie mniejsze niż nakłady jakie musielibyśmy ponieść w w przypadku urzeczywistnienia się scenariusza niekorzystnych zdarzeń. W tym przypadku należy zarządzać ryzykiem aby go ograniczyć do rozmiarów mniejszych od M DR.
2 w szczególności środki i fundusze, jakimi dysponuje, oraz stopień jego „awersji” na ryzyko.
3 Chodzi o ustalenie limitu strat, podobnie, jak czyni to organizacja w różnych innych dziedzinach.
4 Wg. Biała Księga
Rys. 1. Schemat zarządzania ryzykiem
Konfiguracja Ryzyka
Organizacja musi poradzić sobie wieloma ryzykami Biała Księga, która jest monograficznym opracowaniem związku banków francuskich wyróżnia trzy
Organizacja musi poradzić sobie wieloma ryzykami Biała Księga, która jest monograficznym opracowaniem związku banków francuskich wyróżnia trzy