Swego czasu pisałem:
Hipoteza ? osąd, teoria, która nie znalazła jeszcze potwierdzenia w faktach, lub w przypadku hipotez matematycznych nie została jeszcze poprawnie udowodniona.Stawianie i testowanie hipotez to jeden z podstawowych procesów twórczego myślenia oraz fundamentalny element procesu tworzenia nauki. (Źródło: Metoda naukowa w analizie wymagań | Jarosław Żeliński IT-Consulting)
Nie raz w toku projektów mówię, że moja praca przebiega w taki – naukowy – własnie sposób: zbieram pewną niewielką partię danych, np. dwa, może trzy komplety dokumentów danego procesu biznesowego, i tworzę model tego procesu. Ten model to hipoteza: “Ten proces tak przebiega”. Kolejny “ruch” to testowanie modelu czyli próba jest falsyfikacji, szukania w analizowanej organizacji faktów przeczących tej tezie. Polega na wysłaniu do recenzji lub prezentacji opracowanego modelu procesu. Jeżeli uda się znaleźć zdarzenie lub dokument, którego model procesu nie tłumaczy (nie opisuje go), to znaczy, że model jest zły (został podważony) i należy go poprawić. Jeżeli w toku recenzji, żaden recenzent (recenzentem jest tu ekspert dziedzinowy z obszaru danego procesu biznesowego w analizowanej organizacji) nie podważy modelu, znaczy to, że model jest poprawny czyli odwzorowuje to co się dzieje w organizacji. To procedura zwana metodą naukową (model ten musi także spełniać wymogi formalne czyli zgodność z daną notacją, np. BPMN i ustalona pragmatyką tworzenia tych modeli).
Nie raz miewam “prośby” o dodanie do modelu procesu (jest nim diagram np. w notacji BPMN) czegoś niepotrzebnego albo wręcz kolidującego z zadeklarowaną notacją lub pragmatyką. Z reguły są to jakieś “a my czasem jest robimy to tak i tak” albo “proszę pokazać jeszcze to”. Praktycznie zawsze są to nadmiarowe szczegóły, opisujące pewne wybrane detaliczne czynności, które nie mają pływu na modelowany proces, stanowią jego naturę lub detal zawarty w dokumentach. Elementy, które na etapie modelowania procesów z zasady pomijamy bo są udokumentowane w procedurach, zakresach obowiązków, instrukcjach obsługi urządzeń, wzorach dokumentów itp. Drugi element często psujący modele to dodawanie na diagramach ikon i symboli z poza notacji. Zdarza się to w sytuacji, gdy poprosi o to któryś z recenzentów lub zrobi to sam analityk, który nie poradził sobie ze zrozumieniem danego “zjawiska”.
Takie zbyt szczegółowe lub przekłamane diagramy z reguły kończą życie na “śmietniku projektu” czyli na nieużywanej półce z dokumentami po ich zafakturowaniu.
W modelach systemów (wykonanych z użyciem notacji UML) najczęściej widuję złe (niezgodne z ich znaczeniem) użycie symboli UML. Dotyczy to głównie diagramów klas i diagramów przypadków użycia. Na diagramach klas są to najczęściej błędy wynikające z mylenia modeli pojęciowych i modeli struktury na jednym diagramie klas. Na diagramach przypadków użycia nie raz obserwuję całkowite odejście od reguł UML, do stosowania UML tak jak np. Power Pointa czyli “symbol jest fajny to go użyjemy do czego nam tylko pasuje”. Ma nie raz miejsce wprowadzanie kuriozalnych pojęć, z poza notacji UML typu “aktor czas”, “systemowy przypadek użycia” i inne dziwolągi prowadzące do ich mnożenia, tylko dopełniają bałaganu.
Nie raz przywoływałem tak zwaną “[[Brzytwę Ockhama]]”, jest to metafora, mówiąca, ze w nauce tworzenie nowych bytów musi mieć uzasadnienie, be tego wszelkie “nowe byty” stanowią tylko obraz niewiedzy i niezrozumienia, ideologicznego ukrycia braku możliwości dowiedzenia istnienia czegoś. Tu zacytuję fragment pewnego bloga (polecam lekturę całego cytowanego artykułu):
Nie będziesz mnożył bytów ponad miarę [treść tzw. Brzytwy Ockhama, przyp mój J.Ż.]. Tak jak nie należy bez przyczyny wybierać rozwiązania nadmiernie skomplikowanego, tak też nie wolno dowolnie dokooptowywać do swojego rozumowania dodatkowych bytów. Nie stosując się do tego zakazu, dla przywołanego wcześniej przykładu, moglibyśmy ukuć niezliczoną ilość kolejnych wyjaśnień. Katedry i piramidy mogli przecież wznieść przybysze z kosmosu, czarodzieje, duchy, demony, skrzaty? Byty można mnożyć bez końca, tłumacząc nimi każde obserwowane zjawisko. A jednak nie dajemy wiary zapewnieniom brzdąca twierdzącego, że cenny wazon w salonie uległ destrukcji w skutek działalności złośliwego poltergeista. W każdym razie, znaleziona opodal miejsca zdarzenia piłka, podsuwa nam znacznie prawdopodobniejsze wyjaśnienia. Dopuszczając do procesu naukowego krasnoludki, dżiny, wróżki i co tam chcecie, dochodzimy do nieuchronnego acz bezwartościowego wniosku, iż każda z dowolnie zmyślonych odpowiedzi jest równie dobra i równie (nie)prawdopodobna. (Źródło: Metodologiczny dekalog naukowca | Kwantowo.pl – astronomia, fizyka, nauka!)
Tak więc czytając czyjekolwiek opracowania, w szczególności analizy biznesowe i modele systemów, sprawdzajcie, czy ktoś nie umieścił tam analitycznych krasnoludków, kosmitów, dżinów itp. Takie byty na diagramach jak “aktor czas” czy “systemowy przypadek użycia“, świadczą wyłącznie o tym, że autor po prostu nie poradził sobie z analizą, nie do końca odkrył istotę tego co analizował i opisał, nie zrozumiał tego co modeluje. Dodawanie nowych bytów do notacji jak najbardziej jest możliwe, ale po pierwsze należy to robić poprawienie ale potrzeba taka jest bardzo rzadka. W obszarze analizy i modelowania obecna postać BPMN wystarczy aż nadto, do modelowanie oprogramowania zorientowanego obiektowo UML tym bardziej wystarczy. Takie upstrzone “wynalazkami” dokumenty być może są atrakcyjne ale kompletnie nieprzydatne.
