Jarosław Żeliński Analiza systemowa przedsiębiorstwa odpowiada na dwa pytania: Jak jest, i dlaczego jest tak jak jest?Jak powinno być, i co zrobić by było tak jak powinno być? Moja oferta…
Opisując wymagania wyłącznie jako “czarną skrzynkę” nie wiem co dostanę. Większość developerów będzie dążyło do uproszczenia implementacji (ich koszt, nie raz brak wiedzy) by zaspokoić na minimalnym poziomie wymagania opisane przypadkami użycia. Nie raz klient słyszy “tu musimy to uprościć bo tak się nie da”, a zamawiający, nie mając kompetencji by polemizować z taką opinią, zgadza się i dostarczony system staje się zgniłym kompromisem opartym właśnie na “czarnej skrzynce” jako specyfikacji zamówień: “dostaliśmy dokładnie to co zamówiliśmy ale zupełnie nie to czego naprawdę potrzebujemy”.
Tak więc,
nie ma znaczenia fakt, że na pewno są na rynku developerzy znający problem, który opisałem i stosujący opisane tu rozwiązanie takich problemów. Jednak nawet cień ryzyka (a jest ono na prawdę duże), że dostaniemy bubla, daje zamawiającemu prawo do szczegółowego definiowania wymagań jako “białej skrzynki”, bo dzięki temu zamawiający dostanie “to czego potrzebuje a nie tylko to co zamówił”.
Kim więc jest dobry analityk?
Jest to projektant, który potrafi analizowaną organizację “rozłożyć na elementy składowe”. Tymi elementami są wzorce projektowe, elementy stosowanej notacji. Wynik analizy to nie “rysunek”. Jest modelem w postaci schematu blokowego (diagramu), na którym każdy element ma ściśle określone znacznie, konstrukcję i zasady wzajemnego łączenia.
Analiza Biznesowa to rozłożenie analizowanego “przedmiotu” na skończony zestaw elementów, który z określoną dokładnością zachowuje się jak analizowana organizacja. Jeżeli te elementy składowe mają także swoje odwzorowanie w kodzie programu, to wynik analizy staje się projektem tego oprogramowania.
Poziomy szczegółowości wymagań to:
cele biznesowe (produkty procesów biznesowych)
opis usług żądanych od oprogramowania (tu także formatki papierowe/ekranowe, przypadki użycia oprogramowania)
opis (projekt) wewnętrznej logiki biznesowej (wewnętrzne elementy składowe i scenariusze ich współdziałania)
Powyższe jest zgodne z zaleceniami OMG.org (https://www.omg.org/mda), audyt to etap CIM a projektowanie przypadków użyci i modelu dziedziny to etap PIM.
Wykonanie takiej analizy jest pracochłonne i wymaga dużego doświadczenia, umiejętności analiz 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.
Analiza Biznesowa i specyfikacja wymagań opracowana metodą opisywaną tu i na stronach OMG, jest od tej ostatniej (grupa konsultantów i sesje warsztatowe) znacznie tańsza. W czasie trwa podobnie, jednak robi to z reguły jedna osoba (tak! ale przy założeniu ma stosuje zaawansowane narzędzia CASE nie tylko do tworzenia diagramów ale także do ich weryfikacji śladowania zarządzania spójnością modeli itp.), a efektem jest projekt logiczny a nie dopiero lista wymaganych cech. Korzyść jest więc podwójna. Jeżeli zrobi to Analityk wynajęty przez Klienta a nie Dostawcy, to wszelkie prawa (know-how) do projektu pozostają po stronie nabywcy.
Można powiedzieć, że to trudne i kosztowne. Trudne owszem, wymaga doświadczenia i wiedzy zarówno z zakresu zarządzania jak i inżynierii oprogramowania. Per saldo, wliczając w to koszty modyfikacji na etapie wdrażania i odkrywania wymagań (wady specyfikacji nie poddającej się weryfikacji) jest to proces zawsze tańszy (badania kierowników projektów wskazują, że zła jakość wymagań generuje dodatkowe koszty rzędu 60% wartości projektu, koszt takiej analizy nie przekracza zaś 20%). Do tego pojawiają się potencjalne koszty nieujawnione klientowi: prawa autorskie do projektu i aplikacji. Jeżeli firma będąca wykonawca oprogramowania robi analizę swojego klienta i potem mu sprzedaje prawa do jej wyników wraz z dostarczanym oprogramowaniem, to jest to klasyczny przypadek anegdoty o konsultantach, którzy zapytani o to która jest godzina, proszą Cie o Twój zegarek, odpowiadają na pytanie która godzina i wystawiają fakturę za usługę i także za zwracany Ci Twój zegarek.
Model dziedziny nie powinien więc być diagramem słownikowym (diagram klas z gęsto powiązanymi klasami nafaszerowany dziedziczeniem i asocjacjami). Taki diagram to model pojęciowy (pojęcia słownikowe) nie nadający się do implementacji. Wymaga jeszcze wiele pracy. Jeżeli skażemy na nią programistę, osobę która nie zna tej “dziedziny”, to z dużym prawdopodobieństwem powstanie “coś co nie koniecznie jest tym czymś co powinno powstać”, i nie jest to wina tego programisty tylko tego, który mu dał opis tego co ma powstać w takiej właśnie, niezdefiniowanej postaci. […]
Tak więc szanowni klienci: sprawdzajcie co Wam dają analitycy, jeżeli model dziedziny systemu jest dla Was totalnie nie zrozumiały (to co mówi lub referuje analityk), to prawdopodobnie jest to zły model…
Tak więc model dziedziny opisujący sprzedaż, powinien zawierać obiekt biznesowy Faktura ale obiekt ten nie powinien mieć operacji “nowa faktura”, model powinien zawierać odrębny obiekt np. NarzędzieFakturzysty, mający “w sobie” wiedzę o tym jak się wystawia faktury. Powody są dwa: techniczny opisał powyżej kolega programista, drugi powód jest bardzo prozaiczny: bo faktury same się nigdzie nie wystawiają…
Nie będę tu opisywał szczegółów tego projektu, ważne są wnioski a nie ta czy inna firma:
pominięcie któregokolwiek etapu projektu analitycznego, w szczególności pierwszego, powoduje, że całość staje się nieweryfikowalna, ryzyko rośnie,
ukrycie prawdziwego celu projektu przed analitykiem (jest to możliwe, jeżeli dojdzie to tego co powyżej) powoduje, że większość jego czasu pracy nie służy projektowi,
po zanegowaniu efektów pracy analityka, obrona takiego projektu jest niemożliwa bo brak kluczowego narzędzia: śladowanie (przypomnę, że usunięto pierwszy etap – zdefiniowanie celu).
Co było prawdziwym celem projektu? Okazało się, że “nie chcemy by przetarg wygrała firma XXX i jej produkt”. W trakcie pierwszych problemów z “uznaniem” specyfikacji wymagań dostałem listę wad posiadanego oprogramowania. Ku mojemu zaskoczeniu były tam nawet błędy rachunkowe (inne tu pominę, choćby niezgodność programu z prawem). Pytam: jakim cudem to zostało odebrane i zapłacone? Cóż…
Powyższe nasuwa od razu kolejny wniosek: zamawiający najczęściej formułują zapytania w sposób pozwalający dostawcom składać oferty na pierwszy etap, polegający tylko na dostarczeniu i wdrożeniu. Jak widać z zasady wygrywają tu projekty “na żywioł”. Żądanie od dostawców ujęcia kosztów utrzymania (tak zwany “maintenance”) niczego nie zmienia bo to tylko stała oplata administracyjna. Jedynym sposobem na rzetelne porównanie ofert jest operowanie kosztem cyklu życia dostarczonego produktu.
