Często jestem pytany: “a co to jest to śladowanie”? Artykuł adresuje nie tylko analitykom, ale także osobom zlecającym wykonanie analizy, projektu i ich dokumentacji. W artykule podaje przykłady bazujące na obiektowych metodach i wzorcach analitycznych jednak nie jest to wiedza wymagana do jego zrozumienia.

Po kolei…

Jedną z cech dokumentacji wysokiej jakości, jest wywodzenie (konstruowanie) każdego wymagania i pozostałych elementów modeli od ogółu do szczegółu (metoda analizy top-down) i weryfikowanie ich w drugą stronę (metoda analizy bottom-up). Nazywane jest to coraz częściej jako tak zwane śladowanie (zależność ‘trace’ na modelach popularyzowana przez organizację IIBA). Śladowanie pozwala przede wszystkim:

  1. uzasadnić każde wymaganie,
  2. uzasadnić każdy element projektu implementacji,
  3. zweryfikować kompletność i spójność całej dokumentacji,
  4. zapobiec nie kontrolowanemu rozrostowi zakresu projektu,
  5. umożliwia ocenę rentowności projektu per każde wymaganie niezależnie.

Cóż to jest śladowanie? 

Przede wszystkim potrzebny jest “szczyt”, korzeń drzewa śladowania. Powinien nim być cel biznesowy projektu, jak nie trudno się domyśleć, dla jednego projektu powinien być zdefiniowany jeden cel główny, on wyznacza kierunek. Możliwe są cele składowe, podrzędne, ale jeden główny jest wymagany.

Jednym z podstawowych elementów strategii osiągania celów biznesowych jest ulepszanie procesów biznesowych w organizacji. w tym celu wykonuje się audyt organizacji, którego produktem jest jej pełny model, ten zawiera między innymi, jako składowe, modele procesów biznesowych.

Każdy proces biznesowy to jedna lub szereg powiązanych czynności. Wymagania są kojarzone (wywodzone) z tych czynności, które planujemy usprawnić np. z pomocą narzędzia jakim jest planowane nowe lub rozbudowywane oprogramowanie.

W przypadku oprogramowania dedykowanego, to jest tworzonego na zamówienie, tymi wymaganiami są oczekiwane usługi, tak zwane przypadki użycia, oprogramowania (systemu). Są one wywodzone z tych czynności, które nowe oprogramowanie ma wspierać. Tak się określa zakres projektu, który jak widać, też wywodzony jest z modelu (procesów).

Kolejny projektowany element to model dziedziny systemu. Zawiera on obiekty biznesowe oraz elementy odpowiedzialne za realizacje każdej usługi nowego oprogramowania. Są to klasy (i obiekty) w modelu dziedziny. Każdy przypadek użycia  jest wywodzony z czynności w procesie, klasy sterujące są wywodzone z przypadków użycia, klasy reprezentujące obiekty przetwarzane, są wywodzone z dokumentów i zdarzeń.

Dalej z przypadków użycia wywodzone są diagramy sekwencji modelujące scenariusze zachowania systemu w reakcji na działania użytkownika (tak zwanego aktora). Klasy na modelach sekwencji są wywodzone z modelu dziedziny.

Jeżeli model procesów biznesowych zawiera definicje reguł biznesowych, wywodzone są z nich   klasy lub ich operacje, odpowiedzialne za “przestrzeganie” tych reguł.

Śladowanie w opisanej powyżej konwencji ma następująca postać:

Jak widać nadzorowanych jest (śladowanie) wiele logicznych skojarzeń. Tego rodzaju diagramów w projekcie jest nie mało, nie raz  kilkadziesiąt i więcej, logicznych połączeń (czerwone linie przerywane obrazujące śladowanie) są więc setki. Jak nietrudno się domyśleć, “ręczne” śledzenie tych powiązań jest praktycznie nie możliwe. (podobnie zresztą jak ręczne opracowywanie złożonych raportów finansowych z tysięcy danych).

Bez specjalnego narzędzia utrzymanie wysokiej jakości projektu jest praktycznie nie możliwe przy zachowaniu rozsądnego nakładu pracy. Narzędzia te to pakiety oprogramowania wspomagające projektowanie CASE (ang. computer aided systems engineering lub computer aided software engineering, osobiście preferuje to pierwsze rozwinięcie tego skrótu).

Jak zapewne czytelnicy już zauważyli,…

…modele bez systemu śladowania są praktycznie nieweryfikowalne, ich jakości nie da się ocenić a ich stosowanie jest wysoce ryzykowne o ile w ogóle sensowne.

Po co to wszystko? 

Jak wspomniano na początku, do zapanowania na złożonością projektu i jego rentownością. Kolejny powód to możliwość weryfikacji kompletności wymagań. Odkrywanie wymagań dopiero w trakcie realizacji projektu (weryfikacja wymagań dopiero z pomocą kolejnych jego prototypów) to powszechnie znany “zabójca projektów”.

Dobrze opracowany, kompletny model organizacji, jego wykonanie poprzedza opisany powyżej model, łączy w sobie:

  1. model motywacji biznesowej,
  2. model struktury organizacyjnej,
  3. model procesów biznesowych (wymieniony już powyżej),
  4. model reguł biznesowych.

Elementy każdego z tych modeli są ze sobą powiązane: role w procesach są wywodzone ze stanowisk w modelu organizacyjnym,  analizowane procesy są wywodzone ze strategii w modelu motywacji, reguły biznesowe są kojarzone z czynnościami w procesach i wywodzone z aktów prawnych i wewnętrznych zarządzeń.

Mając tak opracowany kompletny model organizacji, zawierający śladowanie,  i odpowiednie oprogramowanie CASE można przeprowadzić analizę oddziaływania, np. sprawdzić na jakie osoby w organizacji przeniesie się zmiana wybranych reguł biznesowych. Mając model systemu informatycznego skojarzony z procesami, można sprawdzić wpływ awarii poszczególnych podsystemów na procesy biznesowe i ich skutki dla firmy. Takich analiz można wykonać wiele, nie było by to możliwe bez tak skonstruowanego modelu.

Dlatego, podstawową wartością poprawnie wykonanych modeli organizacji i użycia właściwych narzędzi, jest nie tylko opracowanie wymagań np. na oprogramowanie. Możliwe jest testowanie reakcji elementów struktury organizacji na zdarzenia np. awarie. Możliwe jest opracowanie projektów integracji, wymiany oprogramowania. Możliwe jest sprawdzenie na co ma wpływ np. nieoczekiwana nieobecność pracownika. To tylko wybrane przykłady, jednak możliwe jest to wyłącznie pod warunkiem posiadania poprawnie wykonanego modelu.

Wartość dodana takiej analizy może być bardzo duża. Jeżeli podejmuje się decyzje o inwestycjach rzędu setek tysięcy a nie raz dziesiątek milionów złotych to wsparcie tych decyzji analizami, których wartość jest o rząd albo dwa rzędy mniejsza ma głęboki sens…

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 2 komentarzy

  1. Andrzej Sibik

    Cenne uwagi o wartości “śladowania”.
    Ale ponieważ śladowanie dotyczy nie tylko dziedziny analizy biznesowej, to uzupełniłbym odniesienie do realizacji takiego śladowania w UML – nie tylko przez wspomniane Dependency, ale również dużo innych, w tym zestandaryzowanych stereotypowanych powiązań Dependency i jej specjalizacji: ‘Usage’, ‘Realization’, ‘Substitution’, itp.

    1. Jarek Żeliński

      to prawda, to także “warte uwagi narzędzia’, inna sprawa, że gdy ich używam nie raz słyszę pytania “a po co to”? Nie żebym się tym martwił, ale bardzo wielu ludzi traktuje diagramy jednak wyłącznie jako ilustracje (obrazki) a nie modele, wtedy im te związki faktycznie “niepotrzebnie komplikują” obraz :)… cóż…

      (tak przy okazji, ‘usage’, ‘substitution’, ‘realization’ to nie śladowanie a zależności, śladowanie ma dedykowany stereotyp: ‘trace’)

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.