Trochę inna analiza procesu

W trakcie nakładania metryk na proces (np. pod kątem BPMS), przedstawiony podczas wcześniejszej analizy, używana jest analiza wejść i wyjść procesów, a także próbuje się określić krytyczne punkty procesu. W trakcie analizy przebiegu procesu określa się punkty, w których można zebrać dane do oceny procesu, jego efektywności, czasu realizacji, powtarzalności, ilości wykorzystanych obiektów. Na poniższym diagramie zaprezentowano w sposób poglądowy (uproszczony) czas przebiegu procesu – miejsce startu i końca weryfikowanego fragmentu procesu. Podobnie można określić:

• liczbę zamówień;
• liczbę przesyłek;
• wagi przesyłek (średnia, łączna, mediana)
• liczbę oczekujących zamówień (wpływających w czasie realizacji poprzedniego);
• liczbę zrealizowanych zamówień;

Na podstawie pomiaru czasu (najdłuższy, najkrótszy, średni) można policzyć ilość czasu przypadającego na zamówienie, na przygotowanie przesyłki. Można to użyć do weryfikacji, czy dostępny czas pracy, biorąc pod uwagę zatrudnionych pracowników, jest wystarczający na realizację wszystkich zamówień złożonych w danym okresie czasu.

Reklama

Obiekty na diagramie (UML)

Na przykładowym diagramie klas znajdowala się klasa „Klient”. Na podstawie tej klasy mamy obiekt „DaneKlienta”, który został zamieszczony na poniższym diagramie – diagramie czynności (ang. activity diagram).

Natomiast na drugim przykładowym diagramie jest obiekt „DaneZamowienia”:

Diagram klas (UML) po raz 2

W związku z tym, że poprzedni diagram klas wywołał dyskusję na pewnym forum nt. jego zawartości, konstrukcji, zastosowanych elementów, atrybutów oraz realizacji między nimi, przygotowany został nowy diagram (poniżej). Dyskusja jak najbardziej konstruktywna (miejmy nadzieję, że dla wszystkich czytelników), została zapoczątkowana przez Analityka Biznesowgo, którego wizyta na moim blogu mnie bardzo zaskoczyła. Zamieszczam poniższy diagram z komentarzem i czekam na dalszy ciąg. Na tym blogu zawarte są treści, które są analizowane i później proponowane są nowe rozwiązania – taka jest idea tego bloga („modelowanie trochę od innej strony…”). Tym razem zostałem w swoich planach wyprzedzony z analizą przykładu.

Kilka komentarzy:

• nie zastosowano w nim kompozycji, ponieważ jest za mocną relacją, nie oddaje rzeczywistości. W szczególności w tego typu dziedzinie Klient może istnieć samodzielnie, nie musi złożyć zamówienia, może tylko przeglądać. Podobnie produkt może istnieć samodzielnie. Diagram dotyczy dziedziny zamówień przez internet i wtedy produkt w dziedzinie istnieje przed klientem i przed zamówieniem;
• atrybut „płeć” jest jak najbardziej przydatnym elementem w prezentowaniu Klienta, w szczególności w diagramach, które odpowiadają systemom zakładającym takie coś jak personalizacja, czy badanie zachowań klientów. Nie ma tego na diagramie, bo to nie było celem samym w sobie;
• niektóre atrybuty rzeczywiście były zbędne lub umieszczone w nieprawidłowej klasie. W związku z tym, niektóre usunąłem, a niektóre przeniosłem;
• zmienione zostały klasy uczestniczące w relacji dziedziczenia;
• na diagramie warto byłoby dodać, dla jasności sytuacji, klasy użytkownika oraz interfejs koszyk, żeby lepiej zilustrować charakter;
• można dodać klasę faktura;

Diagram klas (UML)

Na diagramach prezentujących warstwę reiżnynierii zostały zamieszczone informacje o następujących obiektach:

• DaneKlienta – zaprezentowane jako klasa „Klient” na poniższym diagramie;
• DaneZamowienia – zaprezentowane jako klasa „Zamowienie” na poniższym diagramie;
• DaneDostawy – zaprezentowane jako klasa „Dostawa” na poniższym diagramie;

Były one używane do realizacji określonych czynności. Na poniższym diagramie – tzw. diagramie klas (ang. class diagram) – zostały one zaprazentowane jako klasy wraz z przykładowymi atrybutami (ang. attribute) oraz operacjami (ang. operation). Dodatkowo zostały umieszczone dodatkowe klasy – np. Płatność – silnie powiązane z tą dziedziną. Między poszczególnymi klasami zostały określone związki. Przy niektórych podana liczebność. Inne natomiast są w relacji uogólnienia.

Powyższy diagram ma charakter przykładowy. Kolejna wersja diagramu z komentarzami znajduje się tutaj.

Diagram przypadków użycia (UML)

W czasie tworzenia systemu informacyjnego – w tym przypadku systemu wspierającego złożenie zamówienia przez Klienta i jego realizację przez dostawcę – istotne jest to, aby spojrzeć na:

1. czynności wykonywane przez klientów – np. „Określenie zamówienia” czy wybranie produktu, określenie jego ilości, „Realizacja zamówienia”, czyli określenie w jaki sposób ma do nas trafić i kiedy/jak za produkt chemy zapłacić
2. czynności wykonywane przez pracowników dostawcy – np. „Analiza zamówienia” czy „Realizacja wysyłki”.

Każdą z tych przykładowych czynności można dalej rozbijać, identyfikując jej elementy składowe. Przykładowe powiązanie aktorów (klient, pracownik) oraz wykonywanych czynności jest przedstawione na poniższym diagramie – tzw. diagram przypadków użycia (ang. use case diagram).