Dziś miała miejsce konferencja Virtu GigaCon. Mój referat dotyczył wpływu wirtualizacji (jej wprowadzenia jako narzędzia pracy) na ryzyka związane z działaniem systemu IT w organizacji. Tu podzielę się kilkoma jednak nie całym referatem (zapraszam na następne konferencje ;)) a wątkiem dotyczącym analizy oddziaływania. Analiza taka polega na opracowaniu np. listy tego na co w organizacji ma wpływ coś, np. na co ma wpływ Proces XXX albo na co ma wpływ Pracownik JK czy tez na co w organizacji ma wpływ Serwer XXX.
Analizy takie robi się najczęściej w projektach związanych z oceną ryzyka funkcjonowania, jednak jest to bardzo przydatne narzędzie w pracy nad wymaganiami na oprogramowanie i opracowywanie wymagań poza-funkcjonalnych. Podam prosty przykład: dobrą praktyką jest priorytetyzacja przypadków użycia, na jakiej podstawie nadajemy te priorytety? Najczęściej na bazie deklaracji zamawiającego, jednak nie raz okazuje się, że pozornie mało istotna usługa systemu jako sama w sobie, jest w pewnych sytuacjach kluczowym elementem. Po pierwsze warto znać przebieg procesu w jakim dana usługa jest wykorzystywana, tu mam sytuację relatywnie prostą bo łańcuch jest tak dobry jak najsłabsze ogniwo. Jeżeli jakiś proces ma wysoki priorytet to znaczy, że wszystkie przypadki użycia (wymagane funkcjonalności) związane w tym procesem także. deklaratywna lista przypadków użycia raczej nam tego nie powiem.
Ale to dość “prosta analiza”, wystarczy mieć modele procesów i wyprowadzone z nich przypadki użycia. Zaczynają się problemy przy próbie oceny związanej np. ze stanowiskiem zajmowanym przez aktora (role w procesie. Można domniemywać, że pewne funkcjonaliści są ważne, nie z powodu udziału w ważnym procesie, ale z powodu tego, że ich użytkownikiem jest ważna osoba w firmie. Inny rodzaj zależności: które aplikacje powinny mieć wysoką niezawodność a które nie, wiedząc, że cześć z nich współdzieli platformę sprzętową czy systemową z innym, procesy są wspierane przez wiele posiadanych systemów.
Tu daje o sobie znać metoda specyfikowania wymagań poza-funkcjonalnych jako osobnej listy dla całego systemu (i tu pytanie co nazywamy tu systemem, konkretne oprogramowanie czy wszystkie zasoby IT jakie mamy). Pokaże to na przykładzie.
Podstawą dobrze opracowanego modelu jest tworzenie go od ogółu do szczegółu i śladowanie to jest wyprowadzanie każdego szczegółu z nadrzędnego modelu uogólnionego lub powiązanego.
Po lewej stronie “piramida”, standardowy trójwarstwowy model organizacji, od góry:
- warstwa strategii
- warstwa łańcucha wartości dodanej i procesów biznesowych
- warstwa wykonawcza i zasoby
Warstwa pierwsza to strategia i taktyka działania firmy. Tu może sie pojawić ogólna architektura procesów (taktyka działania). Kolejna to kluczowy element, abstrakcja opisująca jak firma buduje wartość, jak powstają jej produkty (także pośrednie). Najniżej mamy zasoby: ludzie, IT, inne. Taki model to nic innego jak model architektury korporacyjnej (tyle, że jak widać nie musi to być notacja [[ArchiMate]] a wystarczy BPMN i UML).
Kompletny opis (model) organizacji to:
- modele opisujące cele biznesowe i kluczowe działania (architektura procesów),
- modele procesów biznesowych,
- modele struktury organizacyjnej wraz z opisami kompetencji oraz modele architektury systemu IT.
Model zawierający wyżej opisane śladowania (i tylko taki!) pozwala na analizę zalezności, np. chcemy dowiedzieć się na co ma wpływ Proces_2, wtedy powinien powstać np. taki diagram:
Jak widać, śladowanie jest tu warunkiem koniecznym dlaczego? Taki model może powstać “automatycznie” (narzędzie do modelowania musi posiadać taka funkcjonalność). jednak to nie jedyny warunek: model musi zachowywać formalna poprawność, czyli nie używamy pojęcia Rola (pas na modelu procesów) do symulowania “systemu” który coś robi, bo oprogramowanie to narzędzie człowieka (rola w procesie), specyfika użycia danego narzędzia to umiejętności aktora (użytkownika) i jest to co najwyżej problem skojarzenia danej czynności (procesu) z dokumentem opisującym procedurę lub instrukcję użytkownika (to także narzędzie powinno umożliwiać).
Wszelkie łamanie formalizmów notacji odnosi taki sam skutek jak np. wykorzystywanie pól w bazie danych do przechowywania innych danych niż te z nagłówka np. wpisywanie drugiego imienia do pola Nazwisko czy nazwy dzielnicy w pole Miasto. Z takiej bazy danych żaden sensowny raport już nie powstanie. Jeżeli na modelu procesów użyto symboli w innych znaczeniach niż to wynika z użytej notacji żadnej sensownej informacji też nie uzyskamy… to już nie modele tylko zwykłe obrazki.
