Ostatni artykuł o procesie analizy i projektowania kończył się tak:

Po wykonaniu powyższego, otrzymamy kompletny model aplikacji w notacji UML. Będzie to właśnie model PIM. Wszelkie niejasności powinny zostać wyjaśnione. Pozostaje realizacja, model PSM, czyli opakowanie projektu  ?technikaliami? (w tym realizacja wymagań pozafunkcjonalych) czyli tym co dają nam np. frameworki MVC i podobne. Oczywiście nie jest to ?trywialny problem?, ale w takim projekcie developer rozwiązuje problemy jakości systemu a nie logiki biznesowej systemu (podobnie jak inżynier budowlany, który ma postawić mocny i bezpieczny dom, bo jego funkcjonalność to problem mieszkańca i zadanie projektanta architekta). (UML Process czyli od biznesu do projektu logiki systemu).

Często dostaję pytania o ogólną, poglądową mapę takiego projektu by łatwo było ocenić czym jest opisywane śladowanie, jaka jest kolejność pracy i jakie modele powstają. Podjąłem próbę pokazania tego:

Kolejność pracy (kliknij by powiększyć):

1. Określenie celu biznesowego, powstaje dokument wyjaśniający jakie “biznesowe” korzyści chcemy (organizacja) osiągnąć, nie powinno być celem samym w sobie kupienie czegoś (np. systemu ERP), korzyści te powinny być wyrażone ostatecznie w pieniądzu (potrzebne do analizy rentowności projektu).
2. Kolejny etap to opracowanie modelu motywacji biznesowej, będzie to materiał do wypracowania Wymagań Biznesowych. Model ten zawiera przełożenie celu biznesowego na wymagane działania: taktykę i strategię jego osiągnięcia: raz jest to reorganizacja a raz nowy system ERP. Tu pojawiają się takie elementy jak analiza SWOT czy oddziaływania, analiza wykonywalności i oceny wpływu otoczenia na projekt. Powstają Wymagania Biznesowe (źródłem są strategia i taktyka osiągania celu biznesowego).
3. Następnie kolej na opracowanie modelu procesów biznesowych dla całej organizacji na poziomie opisującym kluczowe produkty (dokumenty i fakty). Zaczyna powstawać słownik pojęć i reguł biznesowych.
4. Kolejny etap to dekomponowanie procesów biznesowych “odpowiedzialnych” (powiązanych) za realizacje Wymagań Biznesowych, te procesy dekomponujemy (uszczegółowione modele) do poziomu czynności tworzących i zmieniających dokumenty i fakty. Dodajemy kolejne zidentyfikowane pojęcia i reguły. Na tym etapie możliwa jest optymalizacja procesów.
5. Jeżeli optymalizacja realizuje wymagania  biznesowe projekt się kończy. Jeżeli okazuje się, że wymagania biznesowe wymagają np. technologii IT, projekt ma dalszy ciąg.
6. Określenie wymagań na oprogramowanie to wskazanie tych czynności w procesach, których wsparcie tą technologią pomoże zrealizować wymagania biznesowe. Po analizie powstaje na jej podstawie lista oczekiwanych usług oprogramowania, są to tak zwane przypadki użycia systemu. Każdy przypadek użycia ma określony stan początkowy, końcowy (ewentualnie dokument jaki ma powstać), cel biznesowy (uzasadnienie) oraz aktora czyli wskazanie użytkownika (a konkretnie roli jaką pełni w organizacji). Powstaje specyfikacja wymagań funkcjonalnych i poza-funkcjonalnych (jakościowych, np. takich jak wydajność czy niezawodność). Na tym etapie dysponujemy specyfikacją pozwalającą na szukanie gotowego oprogramowania na rynku oferującego tak opisane funkcjonalności. Elementem specyfikacji wymagań jest słownik pojęć i reguł biznesowych. Można dołączyć modele procesów.
7. Jeżeli nie znajdujemy produktu spełniającego wszystkie wymagania w 100%, decydujemy, które brakujące wymagania funkcjonalne jesteśmy gotowi wytworzyć specjalnie dla nas. Wymaga to utworzenia dla każdej takiej funkcjonalności (przypadku użycia, PU) specyfikacji w postaci opisu jej realizacji. Jest to projekt (dokument)   zawierający tak zwany model dziedziny systemu czyli obiekty biznesowe i logikę ich współdziałania. Dla każdego PU powstaje diagram opisujący jak obiekty modelu dziedziny “realizują” (współdziałanie) każdy przypadek użycia (diagramy sekwencji).

Projekt ma trzy kluczowe etapy: audyt organizacji czyli jej poznanie i opracowanie modelu działania. Kolejny to Specyfikowanie wymagań na oprogramowanie. Ostatni etap analizy i projektowania to opracowanie modelu logiki jaką ma realizować zamawiane oprogramowanie. Cała ta dokumentacja zawiera know-how organizacji warty ochrony.

Na diagramie pokazano tak zwane “śladowanie” czyli kolejne wywodzenie elementów modeli z poprzedzających  je ogólniejszych etapów analizy. Taka dokumentacja pozwala uniknąć kosztownego odkrywania potrzebnych funkcjonalności podczas dostarczania kolejnych wersji oprogramowania i przeprojektowywania go. Specyfikacja logiki systemu pozwala dokładnie sprecyzować jakie oprogramowanie jest zamawiane (co ma ono realizować i jak). Całość to opis know-how, który nadal zostaje przy zamawiającym (jest posiadaczem praw do tej dokumentacji bo wykonał ja sam lub zlecił niezależnemu analitykowi a nie dostawcy oprogramowania).

Skąd się biorą problemy

Przytłaczająca większość projektów to rozpoczęcie pracy od próby zebrania wymagam funkcjonalnych z pominięciem całej analizy biznesowej. Jedynym więc ich źródłem są przyszli użytkownicy, Ci jednak po pierwsze nie mają wiedzy o kontekście zaś ich cele są inne niż sponsora projektu. Nie mamy żadnego narzędzia pozwalającego sprawdzić  zasadność każdego z tak zebranych wymagań ani tego czy są “spójne i kompletne”.  W efekcie niespójności i brakujące wymagania odkrywany dopiero w trakcie projektu.

Metody zwane zwinnymi idą jeszcze dalej: prace deweloperskie są rozpoczynane są zanim powstanie kompletna specyfikacja, pojawiające się wymagania są natychmiast, z pominięciem ich modelowania i weryfikacji pomysłu, implementowane (kod to pierwszy model i weryfikacja). Ryzyko, że nowe, odkrywane w trakcie tego procesu, wymagania i metody ich implementacji będą niespójne czy wręcz sprzeczne jest ogromne co pokazuje praktyka: metody zwinne dają produkty nie raz po bardzo wielu iteracjach i najczęściej są kontraktowane umowami “czas i materiał”, bo w zasadzie inaczej się tym wypadku nie da. Deklarowanie terminów  i budżetu wymagało by ogromnych narzutów na niewiedzę w momencie rozpoczynania pracy (co jest także powszechna praktyką).

Na zakończenie

Opisany proces jest zgodny z zaleceniami OMG.org (https://www.omg.org/mda). Audyt to etap CIM (standardowo [[notacja BPMN]], system pojęć i [[notacja BMM]], hierarchia struktury organizacyjnej, słownik reguł i pojęć)  a projektowanie przypadków użyci i modelu dziedziny to etap PIM (Platform Independent Model, [[notacja UML]]).

Wykonanie takiej analizy jest pracochłonne i wymaga dużego doświadczenia, umiejętności analizy procesów biznesowych, projektowania obiektowego i dobrego narzędzia CASE, jednak modele te pozwalają także przeprowadzić analizy wpływu (zależności pomiędzy procesami, skutki i podatność na awarie oprogramowania itp.) oraz zredukować do minimum prawdopodobieństwo przekroczenia terminu i kosztów (statystyki wskazują na średnie przekroczenie kosztów o 60% i terminów o 200% projektów z niskiej jakości specyfikacji wymagań).

Praktyka autora wskazuje, że warto taką analizę przeprowadzić dla projektów, których budżet przekracza 50-70 tys, zł i większych, jej koszt jest zawsze znacznie niższy niż ryzykowane 60% budżetu. Paradoksalnie, w tych większych projektach, zbieranie wymagań i zarządzanie nimi metodami warsztatów i ankiet wymaga zaangażowania wielu pracowników po stronie zarówno klienta jak i dostawcy (np. [[sesje JAD]]), z reguły jest to większy koszt niż jeden analityk z opisanymi kompetencjami i narzędziami pracy, a otrzymany produkt – specyfikacja wymagań – niższej jakości (problemy spójności i kompletności).

(autor używa pakietu CASE analityczno-projektowego firmy Visual Paradigm)