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 rozwiązania wymagań wyspecyfikowanych na etapie analizy biznesowej. W zależności od kontekstu, wymagania mogą być bezpośrednio przekształcane w przypadki użycia, bądź też ten etap musi być poprzedzony analizą wpływu wymagań na systemy jakie posiada organizacja (ten scenariusz nie jest pokazany na poniższym schemacie koncepcyjnym, ale będzie ujęty w technikach opisanych dla poszczególnych rodzajów diagramów). W dalszej części prac przypadki użycia są opisywane techniką nazywaną analizą odpowiedzialności – która jest punktem wyjścia dla docelowego opracowania makiet. Równolegle z przypadkami użycia tworzony jest model informacyjny systemu oraz ewentualnie maszyny stanów dla klas, które ich wymagają. Do tego aspektu referuje się zarówno z analizy odpowiedzialności jak i z makiet.

Najczzęś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.

I

FUNKCJONALNOŚCI ŚLADOWANE

Proszę kliknąć w ikonę, aby przejść do sekcji opisującej diagram wymagań.

c

KROK W PROCESIE

Krok procesu biznesowego, który wymaga wsparcia projektowanym rozwiązaniem IT.

c

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).

c

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).

I

PRZYPADKI UŻYCIA

Proszę kliknąć w ikonę, aby przejść do sekcji opisującej diagram przypadków użycia.

c

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.

c

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.

I

ANALIZA ODPOWIEDZIALNOŚCI

Proszę kliknąć w ikonę, aby przejść do sekcji opisującej analizę odpowiedzialności.

c

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.

I

MAKIETA

Proszę kliknąć w ikonę, aby przejść do sekcji opisującej sposób opisywani makiet w metodyce OMNIS.

c

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.

c

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.

c

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.

c

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.

c

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.

I

MODEL INFORMACYJNY SYSTEMU

Proszę kliknąć w ikonę, aby przejść do sekcji opisującej sposób opisu modelu informacyjnego systemu.

I

MASZYNA STANÓW

Proszę kliknąć w ikonę, aby przejść do sekcji opisującej sposób opisu maszyn stanów.