W bardzo ciekawym artykule o identyfikowaniu “udziałowców” projektu (polecam: How to Effectively Engage Requirement Contributors to Achieve Project Success) autor opisał istotę analizy wpływu otoczenia (podmioty zewnętrzne) i udziałowców na projekt tworzenia (dostarczenia) oprogramowania, bardzo ważnego etapu analizy biznesowej.

Osobiście jestem gorącym zwolennikiem traktowania oprogramowania jako zestawu narzędzi pracy i środków do jej wykonywania (ang. metafora tools&materials czyli oprogramowanie to narzędzia i materiały). Wtedy łatwiej “umieścić” sobie wyobrażenie powstającego oprogramowania w naszym otoczeniu. To pociąga za sobą potrzebę zrozumienia tego “otoczenia” i jego wpływu na nasz projekt. Tu pojawia się drobny “niuans”. Analiza systemowa wymaga jednoznacznego określane granicy Systemu i określenia czym on jest. W swoich projektach definiuję to tak:

System to oprogramowanie, które powstanie oraz projekt, którego jest on produktem. Dzięki takiej definicji wiem, że jeżeli coś ma wpływ na projekt tworzenia oprogramowania to ma także wpływ na samo oprogramowanie, jeżeli coś ma wpływ na powstające oprogramowanie to ma także wpływ na zarządzanie projektem jego wytworzenia.

Dlatego na etapie analizy wpływów otoczenia, utożsamiam projekt z jego produktem. Analiza wpływu otoczenia na projekt ma na celu (źr. wspomniany artykuł):

1. Identyfikację instytucji regulujących (ograniczających) działanie podmiotu dla którego powstaje narzędzie, to ograniczenie przenosi się na System bo musi on być zgodny z tymi ograniczeniami,
2. Identyfikację tego, kto w otoczeniu dostarcza a kto konsumuje dane (wymagane i przetwarzane przez System oraz wytworzone),
3. Identyfikację wszystkich interfejsów

Moim zdaniem podmioty identyfikowane w punktach punktach 2 i 3 można potraktować łącznie, gdyż interfejs jest narzędziem wymiany danych, więc identyfikacja dawcy lub biorcy danych implikuje postawienia wymagania na interfejs. Warto jedynie zaznaczyć czy w danym wypadku chodzi o człowieka czy o inny system, jednak z perspektywy analiz systemowej obaj są Aktorami Systemu. Rozróżnienie to jednak ma konsekwencje w postaci budowy typu interfejsu: graficzny użytkownika czy komunikacyjny (system – system).

Modelowanie zależności pomiędzy udziałowcami

Autor artykułu słusznie zauważa, że etap analizy udziałowców projektu jest bardzo ważny, wskazuje na kluczowe korzyści płynące z tej fazy analizy, są to:

1. zrozumienie skutków wprowadzanych zmian oraz wpływu na zakres projektu i jego miary,
2. minimalizowanie ryzyka powstania złej specyfikacji wymagań (rozmijanie się z prawdziwymi potrzebami),
3. jasne i zrozumiałe przekazanie oczekiwań oraz ról  w projekcie, każdego “zainteresowanego” a należą do nich sponsorzy projektu i przyszli użytkownicy powstającego systemu.

W początkowej fazie projektu bardzo ważne jest to ostatnie, gdyż pomyłka tu potrafi zniweczyć wszystkie pozostałe wysiłki.

Tu jednak pojawia się problem w treści artykułu. Użyto w nim pewnych modeli (diagramów) “nieco” nagiętych semantycznie. Pojęcia (użyte diagramy i ich elementy)  są nieco  przemieszane i nie zachowują spójności znaczeń użytych symboli. Czy to aż takie złe? Niestety tak. Dlaczego? Notacja UML (jak każda) to pewien system pojęciowy: zestaw pojęć i ich definicji. Łamanie ich, ten sam symbol używany do wyrażenia różnych pojęć, prowadzi do utraty jednoznaczności modeli i nieporozumień.

Diagramy autora artykułu:

udziałowcy:

Autor powyższych diagramów (i wymienionego we wstępie artykułu) nazwał pierwszy “Diagram przepływu danych (ang. DFD, Data Flow Diagram) poziomu zero” a drugi, diagramem zależności udziałowców projektu. Formalnie DFD nie zawiera pojęcia aktor, powyższe to diagram aktywności UML (poprawny). W UML aktorem jest każdy zewnętrzny byt, będący beneficjentem usługi świadczonej przez System. Pojęcia <<External Entity>> w notacji DFD oznacza “zewnętrzne obiekty” (źródła danych lub ich cel), w UML nie ma ono odpowiednika jako odrębne pojęcie (UML i paradygmat obiektowy nie operuję pojęciem danych).

Ogólnie w UML strzałki przerywane mają znaczenie “Zależy od” (jest biorcą usługi) i jako takie mają tu zły kierunek, gdyż symbol zależności w UML to wskazanie na obiekt, od którego coś jest uzależnione, lub z usług czego korzysta. Tu strzałki obrazują coś, co autor nazwał “kierunek przepływu”, co jest niepoprawne bo ta “strzałka” w UML nie oznacza przepływu. Tak więc powyżej Pilot nie zależy od Lotu a jest raczej odwrotnie. Umieszczenie takiego diagramu w dokumentacji zawierającej inne diagramy UML prawie na pewno doprowadzi do nieporozumień (diagram zostanie źle zinterpretowany). Jeżeli Załoga (CabinCrew) świadczy usługi Pasażerowi, to strzałka powinna mieć kierunek przeciwny (Pasażer korzysta, jest zależny, z usług Załogi). Jeżeli intencją było zobrazowanie przepływu należało utworzyć inny diagram, tym bardziej, że powyższy diagram nie pokazuje, co tak na prawdę przepływa od Załogi do Pasażera (?). Jednak zachowując semantykę UML, diagram taki można utworzyć.

Jak to powinno wyglądać poprawnie?

UML i diagramy przypadków użycia jako model udziałowców

Pomijając samą nazwę (przypadki użycia), diagramy te pozwalają na modelowanie pojęć takich jak:

1. System, czyli byt (jakieś np. oprogramowanie) świadczący jakieś usługi (cechujący się jakimiś funkcjonalnościami),
2. Aktor czyli zewnętrzny względem systemu byt, mający bezpośrednią lub pośrednią interakcję z systemem,
3. Zależność, czyli wskazanie pary obiektów będących w relacji “klient-usługodawca”, klient jest uzależniony od usługodawcy,
4. Realizacja czyli wskazanie pary obiektów, gdzie jeden (implementacja) jest fizyczną realizacją drugiego (idealizacja, model).

Dla rozróżnienia aktorów na osoby (fizyczne) i inne systemy można użyć stereotypów. Na diagramie wygląda to tak (zmieniłem kontekst na własny przykład):

System konkretny to jakieś istniejące oprogramowanie wymagające integracji.  Inny system to zgodna z UML abstrakcja Aktora Projektowanego Systemu (System konkretny jest jego Realizacją). Aktorzy mogą zależeć od siebie a także od Projektowanego Systemu. Projektowany System może zależeć od Aktora.  Jak to wygląda “realnie” czyli na konkretnym przykładzie?

Powyższy diagram, w pełni zgodny z UML,  ma następujące zalety:

1. Użyte pojęcia są godne ze standardem a więc nie prowadzą do niejednoznaczności w interpretacji modeli,
2. Narzędzia typu CASE bez problemu pozwolą narysować powyższe, a elementy tego diagramu mogą posłużyć zgodnie z UML, jako klasyfikatory dalszych, podległych (zależnych),  elementów modelu (obiektów i innych diagramów),
3. Model poprawnie odwzorowuje modelowane elementy bez zapożyczania znaczeń z innych, nieobiektowych, notacji i bez łamania zasad UML a więc model jest jednoznaczny i weryfikowalny.

Wydaje mi się, że powyższy diagram nie wymaga komentarza. Diagramy takie stosuję jako element dokumentacji biznesowej, przedstawianej sponsorowi projektu do zatwierdzenia. Są one czytelne, nazywa się je także analizą “interesariuszy” (ja staram się unikać tego dziwnego tłumaczenia słowa stakeholders).

Stosowanie  reguł (semantyki i syntaktyki) UML pozwala utrzymać spójność modeli zależnych (podległe temu diagramowi uszczegółowienia Projektu Systemu, realizacja Aktorów, przypadki użycia  itp.) oraz zachować spójność logiczną i pojęciową całej dokumentacji. To zaś jest warunkiem weryfikacji poprawności całego projektu.

UML to notacja, której kluczowym pojęciem jest klasyfikator (oparta jest na definiowanych pojęciach i relacjach między nimi)  dlatego warto przestrzegać (zawsze warto) zasad notacji i np. nie utożsamiać Aktora System CRM (jest to jakaś abstrakcja systemu integrowanego) z konkretnym Jakimś Systemem CRM. Aktor ma konkretne znaczenie na diagramie UML (zdefiniowane wyżej) i konkretny system także. Zachowanie tego podziału (abstrakcja i jej realizacja) pozwala zdefiniować oddzielnie wymagania i oddzielnie konkretne rozwiązania je spełniające, co jest istotą rozdziału wymagań od spełniających je rozwiązań (a także metodyki MDA rozdzielającej projekt od jego implementacji).

Diagramy przypadków użycia są bardzo ważnymi diagramami, gdyż stanowią “korzeń” modelu realizacji systemu zaś łamanie zasad notacji już na początku projektu prowadzi praktycznie zawsze do utraty możliwości ich, modeli, weryfikacji.

Udziałowcy projektu

Uzupełnieniem modelu wpływu udziałowców projektu jest ich specyfikacja. Tu wypada tylko przytaknąć autorowi artykułu, zaleca on by każdego aktora opisać atrybutami:

1. opis,
2. dane kontaktowe,
3. oczekiwania (aktora względem systemu),
4. w jakiej dziedzinie jest specjalistą (ekspert dziedzinowy),
5. wpływy w organizacji (formalne i nieformalne),
6. cele.

Osobiście jestem zwolennikiem całkowitej jawności komunikacji w projektach dlatego nie stosuję pojęcia “nieformalnego wpływu” w projektach. To pozwala mi z jednej strony uprościć zarządzanie dokumentacja projektową (mam jedną wersję dostępną dla Zamawiającego i Wykonawcy) a drugiej nie narażam innych na ryzyko przypadkowego “odkrycia” informacji nieformalnych, mogących być dla jednej ze stron projektu powodem “emocji”.

Analiza RACI

W przypadku udziałowców projektu dobrą praktyką jest budowa prostej macierzy RACI (kliknij po opis tego narzędzia). Co do zasady przyjmuje się, że każdy obszar projektu ma:

1. jedną osobę (lub grono osób, komitet) odpowiedzialną za realizację (Responsible),
2. jedna osobą (lub grono osób, komitet) akceptującą zakres (Accauntable/Approver),
3. osoby, których opinie mogą lub muszą być uwzględniane, eksperci dziedzinowi (Consulted),
4. osoby, które muszą być na bieżąco informowane o postępach projektu (Informed).

Określenie roli każdego udziałowca  w stosunku do każdego z wymagań pozwala ustalić w projekcie jednoosobową odpowiedzialność po stronie Zamawiającego. Ja osobiście stosuję tę metodę jednak w stosunku do obszarów dziedzinowych lub grup wymagań. Użycie macierzy RACI w stosunku do pojedynczych wymagań jest chyba zbyt drobiazgowym podejściem. Takie uogólnienie daje jako efekt relatywnie mniej złożone dokumenty, a wiec łatwiejsze w percepcji.

Uwaga na zakończenie

Model kontekstowy systemu (“udziałowców”) nie jest diagramem modelującym wymagania, więc nie należy na nim umieszczać przypadków użycia systemu (mimo, że używamy zestawu pojęć UML z grupy Przypadki użycia).

Dobrą praktyką tworzenia modeli (także w w UML) jest tworzenie diagramów w jednym kontekście. Umieszczanie na jednym diagramie “wszystkiego co wiemy i co można pokazać” prowadzi to utrudnienia percepcji tych diagramów, a nie raz wręcz do utraty kontekstu i co za tym idzie, ich  zrozumiałości w ogóle.

Zwracam tu także uwagę, że diagram ten to nie relacje znane z modeli danych. Po pierwsze nie są to (Aktor czy System) dane, po drugie związek logiczny pomiędzy danymi to zupełnie inne pojęcie niż zależność “klient-usługodawca”. Jeżeli  wiadomo co oznacza fakt, że oprogramowanie świadczy pewną usługę aktorowi to  interpretacja relacji “encja system i encja aktor” mogła by tu być trudna do interpretacji. Po drugie encje w modelach ERD to byty pasywne, czego nie można powiedzieć o Udziałowcach i Systemach, dlatego modelowane są tu w paradygmacie obiektowym notacją UML.