Zarządzanie zagrożeniami

Zarządzanie zagrożeniami Ważnymi zadaniami zarządzającego przedsięwzięciem są przewidywanie zagrożeń, które mogą mieć wpływ na harmonogram przedsięwzięcia lub jakość budowanego oprogramowania, oraz podejmowanie działań w celu uniknięcia tych zagrożeń. Wyniki analizy zagrożeń powinny być udokumentowane w planie przedsięwzięcia wraz z analizą konsekwencji wystąpienia każdego zagrożenia. Identyfikowanie zagrożeń i opracowanie planów zmniejszenia ich skutków to zarządzanie zagrożeniami. Zagrożenie to prawdopodobieństwo wystąpienia pewnych niesprzyjających okoliczności. Kategorie zagrożeń są następujące: zagrożenia przedsięwzięcia mają wpływ na jakość i efektywność oprgramowania jest rozległym zagadnieniem.

Kategorie zagrożeń są następujące: zagrożenia przedsięwzięcia mają wpływ na zasoby i harmonogram przedsięwzięcia, zagrożenia produktu mają wpływ na jakość i efektywność oprogramowania, zagrożenia przedsiębiorstwa mają wpływ na przedsiębiorstwo budujące bądź zaopartujące się w oprogramowanie. Zarządzanie zagrożeniami jest szczególnie ważne w wypadku przedsięwzięć programistycznych z powodu nieuniknionych niepewności, które dotyczą większości takich przedsięwzięć. Wynikają one z nieprecyzyjnie zdefiniowanych wymagań, trudności w szacowaniu czasu i zasobów wymaganych do zbudowania oprogramowania, uzależnienia od indywidualnych umiejętności oraz zmiany wymagań na skutek zmian potrzeb użytkownika.

Proces zarządzania zagrożeniami 1. Identyfikacja zagrożeń - identyfikuje się możliwe zagrożenia przedsięwzięcia, produktu i przedsiębiorstwa. 2. Analiza zagrożeń - ocenia się prawdopodobieństwo i konsekwencje tych zagrożeń. 3. Planowanie przeciwdziałania zagrożeniom - opracowuje się plan radzenia sobie z tymi zagrożeniami przez ich unikanie lub zmniejszanie ich następstw. 4. Monitorowanie zagrożeń - ustawicznie ocenia się zagrożenia i koryguje plany ich łagodzenia w miarę napływu coraz lepszych informacji o tych zagrożeniach. Proces zarządzania zagrożeniami jest iteracyjny i trwa przez całe przedsięwzięcie.

Identyfikacja zagrożeń Identyfikacja zagrożeń to pierwszy krok zarządzania zagrożeniami. Polega na wykrywaniu możliwych zagrożeń przedsięwzięcia. Identyfikacja zagrożeń może być wykonana przez zespół i mieć formę burzy mózgów albo być oparta na indywidualnym doświadczeniu menedżera. Typy możliwych zagrożeń: 1. Zagrożenia technologiczne, które wynikają z technologii oprogramowania i sprzętu, użytych do tworzenia części systemu. 2. Zagrożenia ze strony ludzi, które są związane z członkami zespołu wytwórczego. 3. Zagrożenia organizacyjne, które wynikają ze środowiska organizacyjnego, w którym tworzone jest oprogramowanie.

Identyfikacja zagrożeń 4. Zagrożenia narzędziowe, które są powodowane przez narzędzia CASE i inne oprogramowanie wspomagające budowanie systemu. 5. Zagrożenia wymagań, które wynikają ze zmian wymagań użytkownika i procesu zarządzania zmianami wymagań. 6. Zagrożenia szacowania, które są związane z menedżerskimi oszacowaniami charakterystyk systemu i zasobów niezbędnych do zbudowania systemu.

Analiza zagrożeń W trakcie procesu analizy zagrożeń każde zagrożenie jest ponownie rozważane. Ocenia się prawdopodobieństwo i znaczenie każdego z nich. Czynność ta wymaga zdolności do oceny i doświadczenia menedżera przedsięwzięcia. Nie musi to być precyzyjna liczbowa ocena, ale powinna być oparta na pewnych ustalonych zakresach: 1. Prawdopodobieństwo zagrożenia może być oceniane na bardzo małe (<10%), małe (10-25%), średnie (25-50%), duże (50-75%) lub bardzo duże (>75%). 2. Konsekwencje zagrożenia mogą być oceniane jako katastroficzne, poważne, znośne lub nieistotne. Wyniki analizy zagrożeń należy przedstawić w tabeli, w której zagrożenia są uporządkowane wg znaczenia.

Planowanie przeciwdziałania zagrożeniom W procesie planowania przeciwdziałania zagrożeniom bierze się pod uwagę każde poważne zagrożenia i opracowuje strategie panowania nad nimi. Strategie dzieli się na trzy kategorie: 1. Strategie unikania - ich zastosowanie prowadzi do zmniejszenia prawdopodobieństwa wystąpienia zagrożenia. 2. Strategie minimalizacji - ich zastosowanie prowadzi do zmniejszenia konsekwencje zagrożenia 3. Plany awaryjne - ich zastosowanie polega na przygotowaniu się i opracowaniu strategii przeciwdziałania na wypadek najgorszego.

Monitorowanie zagrożeń Monitorowanie zagrożeń polega na ocenie, czy każde ze zidentyfikowanych zagrożeń staje się bardziej lub mniej prawdopodobne oraz czy zmieniły się jego konsekwencje. Zwykle nie da się tego bezpośrednio zaobserwować, należy więc zbadać inne czynniki, które umożliwiają wnioskowanie o prawdopodobieństwie zagrożeń i ich następstwach. Czynniki te zwykle zależą od typu zagrożenia. Monitorowanie zagrożeń powinno być procesem ustawicznym. Przy każdym menedżerskim przeglądzie postępów każdego zagrożenia należy oddzielnie rozpatrzyć i rozważyć w czasie spotkania.

Wymagania stawiane oprogramowaniu W przemyśle informatycznym pojęcie wymaganie nie jest stosowane konsekwentnie. Niekiedy wymaganie jest postrzegane jako zapisane na wysokim poziomie, abstrakcyjne określenie usług, które system powinien oferować, albo ograniczenie działania systemu. Niektórzy określają wymaganie jako szczegółową, matematycznie formalną definicję funkcji systemu. 1. Wymagania użytkownika to wyrażania w języku naturalnym oraz diagramy o usługach oczekiwanych od systemu oraz o ograniczeniach, w których system ma działać. 2. Wymagania systemowe szczegółowo ustalają usługi systemu i ograniczenia. Dokumentacja wymagań systemowych powinna być precyzyjna. Ma służyć za kontrakt między nabywcą systemu a wytwórcą oprogramowania.

Wymagania stawiane oprogramowaniu 3. Specyfikacja projektu oprogramowania jest abstrakcyjną opisem projektu oprogramowania, który jest podstawą bardziej szczegółowego projektu i implementacji. Ta specyfikacja daje nowe informacje do specyfikacji wymagań systemowych.

Wymagania funkcjonalne, niefunkcjonalne i dziedzinowe Wymagania funkcjonalne są stwierdzeniami, jakie usługi ma oferować system, jak ma reagować na określone dane wejściowe oraz jak ma się zachowywać w określonych sytuacjach. W niektórych wypadkach wymagania funkcjonalne określają, czego system nie powinien robić. Wymagania niefunkcjonalne to ograniczenia usług i funkcji systemu. Obejmują ograniczenia czasowe, ograniczenia dotyczące procesu tworzenia, standardy itd.. Wymagania dziedzinowe pochodzą z dziedziny zastosowania systemu i odzwierciedlają jej charakterystykę. Mogą być funkcjonalne lub niefunkcjonalne.

Wymagania systemowe Są one bardziej szczegółowymi opisami wymagań użytkownika. Mogą być podstawą kontraktu na implementację systemu, powinny być zatem pełną i niesprzeczną specyfikacją całego systemu. Są traktowane prze inżynierów oprogramowania jako punkt wyjścia do projektowania systemu. Specyfikacja wymagań systemowych może zawierać różne modele systemu, takie jak model obiektów lub model przepływu danych.