Tym razem krótki wpis po pewnym spotkaniu projektowym, dla tworzących i czytających diagramy: Semiotyka, ogólna teoria znaku związana z logiką i lingwistyką. Jej współczesna postać pochodzi od Ch. Morrisa, który…
Bardzo często spotykam się z projektami, w których użytkownicy narzekają na dostawcę oprogramowania, uważają że program nie całkiem spełnia ich oczekiwania (wymagania podpisali... ale to nie rozwiązuje tego problemu). Problem polega na często spotykanym podejściu: analiza wymagań tylko w postaci wywiadów i w konsekwencji niepełne zrozumienie specyfiki biznesowej oraz fakt, że developer ma skłonności do uproszczeń i "normalizacji". Innym, moim zdaniem jeszcze gorszym podejściem, jest rozpoczęcie kodowania jeszcze w trakcie trwania wywiadów i tworzenie oprogramowania metodą codziennych, lub co tygodniowych spotkań z użytkownikiem opisującym kolejne aspekty systemu. Zbyt późne odkrywanie (a nie raz nawet niedostrzeganie tego), tego że pewne rzeczy są 'tymi samymi rzeczami" ale w innych kontekstach, prowadzi do bardzo wielu problemów z implementacją. Ale po kolei.
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.
Model zawierający wyżej opisane śladowania (i tylko taki!) pozwala na analizę zalezności, np. chcemy dowiedzieć się na co ma wpływ Proces_2, wtedy powinien powstać np. taki diagram: Jak widać, śladowanie jest tu warunkiem koniecznym dlaczego? Taki model może powstać "automatycznie" (narzędzie do modelowania musi posiadać taka funkcjonalność). jednak to nie jedyny warunek: model musi zachowywać formalna poprawność, czyli nie używamy pojęcia Rola (pas na modelu procesów) do symulowania "systemu" który coś robi, bo oprogramowanie to narzędzie człowieka (rola w procesie), specyfika użycia danego narzędzia to umiejętności aktora (użytkownika) i jest to co najwyżej problem skojarzenia danej czynności (procesu) z dokumentem opisującym procedurę lub instrukcję użytkownika (to także narzędzie powinno umożliwiać). Wszelkie łamanie formalizmów notacji odnosi taki sam skutek jak np. wykorzystywanie pól w bazie danych do przechowywania innych danych niż te z nagłówka np. wpisywanie drugiego imienia do pola Nazwisko czy nazwy dzielnicy w pole Miasto. Z takiej bazy danych żaden sensowny raport już nie powstanie. Jeżeli na modelu procesów użyto symboli w innych znaczeniach niż to wynika z użytej notacji żadnej sensownej informacji też nie uzyskamy... to już nie modele tylko zwykłe obrazki.
To co najczęściej wzbudza brak zaufania to teza, że można przeprowadzić analizę i projektowanie oprogramowania "na papierze". Programiści w większości uważają, że to nie możliwe (rok temu na stronach tego bloga burzliwa dyskusja z jednym z nich...). W większości przypadków podczas spotkań (konferencje, projekty itp.) z zespołami programistów słyszę: "czytamy wymagania, kodujemy od razu i tworzymy kolejne wersje aplikacji; inaczej się nie da". W przypadku szkoleń, ostatniego dnia warsztatów najczęściej słyszę: "ooo, w ciągu jednego dnia [teraz] powstał kompletny projekt dziedziny systemu [chodziło o komponent], przetestowany i oczyszczony z wątpliwości, braku logiki i niespójności, do tego łatwy w dalszym rozbudowywaniu; to co zrobiliśmy teraz na diagramach UML w ciągu dnia, jako zespół tradycyjną metodą robilibyśmy co najmniej tydzień, biorąc pod uwagę kodowanie każdego pomysłu by go dać użytkownikowi do testów". W zasadzie taki proces analizy i projektowania jest znany od lat jako [[Model Driven Architecture]] (MDA). [...] Larman w swojej książce opisuje niemalże identyczne podejście (tabela poniżej). Kluczową różnicą jest jednak źródło informacji pierwotnej. U Larman'a jest to model przypadków użycia i ich scenariusze. W porównaniu z modelem biznesowym, podlegającym testowaniu czy walidacji, całe ryzyko projektu spoczywa na jakości modelu przypadków użycia. Jeżeli powstały one jako efekt np. burzy mózgów, ankietowania pracowników zamawiającego czy tak zwanych sesji JAD (Joint Application Development) to jest bardzo prawdopodobne, że całe ryzyko złej jakości takiego modelu (a jest ono bardzo duże jak pokazuje praktyka) zostanie przeniesione na projekt. To jest właśnie problem nazywany "użytkownik nie wie czego chce". Po to się robi analizy biznesowe by w końcu wiedział. Nie zmienia to faktu, że książkę Larman'a gorąco polecam każdemu projektantowi i programiście z ambicjami na metody obiektowe i wzorce projektowe.