ANALIZA SYSTEMOWA
Trzeci etap metodyki OMNIS, którego celem jest opisanie sposobu realizacji wymagań wobec IT, zdefiniowanych na etapie analizy biznesowej.
Analiza systemowa, w metodyce OMNIS jest etapem, w trakcie którego tworzy się opis realizacji wymagań wobec IT wyspecyfikowanych na etapie analizy biznesowej. Wstępem do rozpoczęcia prac nad realizacją funkcjonalności, szczególnie w dużych organizacjach, jest identyfikacja systemów, które wymagają modyfikacji lub utworzenia. Po wskazaniu systemów, możliwe jest rozpoczęcie analizy systemowej dla każdego z nich.
Analiza systemowa rozpoczyna się od przekształcenia wymagań funkcjonalnych skojarzonych z krokami procesów biznesowych w przypadki użycia, dzięki czemu określany jest wstępny zakres funkcjonalny systemu. Przekształcenie to nie jest w żadnym stopniu automatyczne, czy oczywiste i wynika z jego charakteru. Należy pamiętać, że wymagania skojarzone z krokami były definiowane niezależnie od jakiegokolwiek systemu, co oznacza, iż w szczególnych sytuacjach z jednym wymaganiem funkcjonalnym może być skojarzonych wiele przypadków użycia z różnych systemów, i z każdym takim skojarzeniem może być związany inny zakres funkcjonalny. W przypadkach wymagających jawnego podania funkcjonalności wynikającej z wymagania funkcjonalknego dla danego systemu metodyka OMNIS zaleca wprowadzenie kolejnego poziomu wymagań (w większych szczegółach zostanie to opisane na sronie dotyczącej tego aspektu analizy systemowej).
Wstępnie określony zakres funkcjonalny pozwala na przejście do kolejnych etapów analizy systemowej, w ramach których określane będą przebiegi realizacji przypadków użycia oraz konstruowany będzie model informacyjny systemu, wymagany do tego, by ustalić zakres informacji wymaganych do realizacji planowanych funkcjonalności. Równolegle z konstruowaniem przebiegów realizacji przypadków użycia, metodyka OMNIS zaleca rozpoczęcie prac nad interfejsem użytkownika. Uważamy, iż są to dwa nierozerwalnie połączone ze sobą aspekty funkcjonalności, i w żadnym stopniu nie powinny być konstruowane w sposób kaskadowy. Jedynie równoległa praca nad przebiegami i interfejsem użytkownika może przynieść pożądane rezultaty. W ramach specyfikowania aspektu interfejsu użytkownika, metodyka zaleca utworzenie map systemowych dla przypadków użycia oraz wizualizacji elementów interfejsu użytkownika. W metodyce zawarliśmy zalecenia dotyczące zakresu informacji wymaganych do przekazania prac do dalszych etapów, dzięki czemu metodyka nie narzuca żadnych zasad współpracy pomiędzy różnymi stronami biorącymi udział w powstawaniu tego aspektu modelu analitycznego (specjaliści UX, analitycy systemowi, analitycy biznesowi, specjaliści dziedzinowi).
Rezultatem tak przeprowadzonej analizy jest spójny model analityczny, w którym jego ortogonalne aspekty są ze sobą powiązane. Tworzenie tych powiązań ma dwie podstawowe zalety:
- w trakcie prowadzenia prac analitycznych na bieżąco są weryfikowane czynione postanowienia, co pozwala usunąć sporą część błędów analitycznych przed przekazaniem ich do dalszych prac,
- finalny model stanowi doskonałą bazę do późniejszych korekt i rozbudowy.
Najczęściej wykorzystywane techniki:
- diagram wymagań (SysML bądź odpowiednik),
- diagram przypadków użycia (UML),
- diagram aktywności (UML),
- diagram klas (UML),
- maszyna stanów (UML),
- OCL (UML).
Odniesienie do Siatki Zachmana
Analiza systemowa w metodyce OMNIS wpasowuje się w trzeci wiersz Siatki Zachmana.
FUNKCJONALNOŚCI ŚLADOWANE
Proszę kliknąć w ikonę, aby przejść do sekcji opisującej diagram wymagań.
KROK W PROCESIE
Krok procesu biznesowego, który wymaga wsparcia projektowanym rozwiązaniem IT.
WYMAGANIE
Metodyka OMNIS zakłada, w swoim bazowym scenariuszu, iż pierwsze wymagania wobec IT są utworzone na etapie analizy biznesowej i wywodzone są z kroków procesów biznesowych. Logika rozumowania za tym stojąca jest nasępująca - krok w procesie biznesowym będziemógł być wykonany zgodnie z przyjętymi założeniami tylko wówczas, gdy będzie wsparty funkcjonalnością rozwiązania informatycznego zgodną z opisanym wymaganiem. Oczywiście, w OMNIS istnieje także możliwość definiowania wymagań tego poziomu pomimo braku formalnie opsianych procesów a także zgodnie z zaleceniami podejść zwinnych (np. user stories).
PRZYPADEK UŻYCIA
Przypadek użycia jest elementem reprezentującym realizację jednego lub większej liczby wymagań wobec IT, pochodzących z etapu analizy biznesowej. W OMNIS posługujemy się podejściem do tworzenia przypadków użyciopierającym się o Use Case 2.0 oraz Use Case Slices (pozwalającym na przyrostowe tworzenie docelowej funkcjonalności).
PRZYPADKI UŻYCIA
Proszę kliknąć w ikonę, aby przejść do sekcji opisującej diagram przypadków użycia.
PRZYPADEK UŻYCIA NA WIELU DIAGRAMACH
Przypadek użycia zidentyfikowany podczas analizy diagramu wymagań jest umieszczany także na diagramie przypadków użycia w troszkę innym kontekście.
REALIZACJA DEKLAROWANEJ FUNKCJONALNOŚCI
Przypadek użycia, odzwierciedlający funkcjonalność stanowiącą mierzalną wartość dla użytkownika, jest opisywany diagramem aktywności, konstruowanym według specyficznych zasad określonych w metodyce OMNIS. W OMNIS ta technika nazywa się analizą odpowiedzialności.
ANALIZA ODPOWIEDZIALNOŚCI
Proszę kliknąć w ikonę, aby przejść do sekcji opisującej analizę odpowiedzialności.
ODPOWIEDZIALNOŚĆ INTERFEJSU UŻYTKOWNIKA
Każda odpowiedzialność interfejsu użytkownika (akcji umieszczonej na torze UI) jest kojarzona z makietą (bądź tylko jej fragmentem) prezentującą realizację odpowiedzialności.
MAKIETA
Proszę kliknąć w ikonę, aby przejść do sekcji opisującej sposób opisywani makiet w metodyce OMNIS.
PIN AKCJI A MODEL INFORMACYJNY SYSTEMU
Piny wejściowe oraz wyjściowe, reprezentujące odpowiednio dane dostarczane do akcji i dane wyjściowe akcji, muszą mieć określony typ. W zdecydowanej większości przypadków będą to klasy określone w modelu informacyjnym systemu. W przypadku architektur usługowych mogą to być także ich struktury wejściowe lub wyjściowe.
PIN AKCJI A MASZYNA STANÓW
Jeśli dane wchodzące bądź wychodzące z akcji wymagają podania stanów danych, wówczas stany powinny pozostawać w zgodności z maszynami stanów skojarzonymi z typem danych pina.
DANE W KONTROLCE A PINY
Kontrolka na makiecie może mieć dostęp jedynie do danych przekazanych w pinie akcji na torze UI wraz z danymi wynikającymi z trawersowani modelu klas.
DANE W KONTROLCE A MODEL INFORMACYJNY SYSTEMU
Kontrolka na makiecie może mieć dostęp na wejściu ma dostęp do danych skojarzonych z pnie wejściowym akcji na torze UI. Aczkolwiek, możliwe jest trawersowanie po modelu informacyjnym systemy, wychodząc od klasy będącej typem danych pina.
DANE W KONTROLCE A MASZYNA STANÓW
Kontrolka może wymagać odwoływania się do stanów klas. W takiej sytuacji stany te powinny być zgodne z maszyną stanów określoną dla klasy, do której obiektów odwołuje się kontrolka.
MODEL INFORMACYJNY SYSTEMU
Proszę kliknąć w ikonę, aby przejść do sekcji opisującej sposób opisu modelu informacyjnego systemu.
MASZYNA STANÓW
Proszę kliknąć w ikonę, aby przejść do sekcji opisującej sposób opisu maszyn stanów.