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.

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.

Technika 5 Sił Portera

utworzone przez | kwi 4, 2022 |

We wpisie omówiono podstawowe cechy techniki 5 Sił Portera.Informacje ogólneCel Wskazanie zasadności stosowania techniki 5 Sił Portera w procesie opracowywania strategii organizacji. Opis „5 sił Portera” („Porter’s 5 forces”) to narzędzie pomagające w obrazowej ocenie...

Technika Macierz Ansoffa

utworzone przez | mar 31, 2022 |

We wpisie omówiono podstawowe cechy Macierzy Ansoffa.Informacje ogólneCel Uzasadnienie stosowania techniki Macierzy Ansoffa w procesie oporacowywania strategii organizacji. Opis Macierz Ansoffa w czytelny sposób przedstawia możliwości rozwoju przedsiębiorstwa. W...