Profesor Łukaszewski swego czasu opublikował bardzo ciekawy tekst: “Psychologia podzielona” [zotpressInText item=”{5085975:PQUM29RB}”]. Publikacja ta to porównanie metod, autor pisze we wstępie:

W historii psychologii, choć jest to historia krótka, wiele było szkół, systemów teoretycznych, zwalczających się orientacji, piewców jedynej słusznej drogi. Nie o przeszłości jednak zamierzam pisać, tylko o funkcjonujących współcześnie, w pewnej izolacji od siebie, ale w jakiś sposób na siebie wpływających trzech odmian psychologii. Pierwsza, to psychologia rozumiana jako praktyka społeczna, druga ? to psychologia potoczna (ludowa, domowa, zdroworozsądkowa, bo wiele nosi ona nazw) i wreszcie trzecia, to psychologia naukowa.

Po lekturze tego tekstu zauważyłem, że autor poruszył problem każdej dziedziny nauki, nie tylko psychologii. Pomijając kwestie specyficzne dla psychologii, moim zdaniem można by zastąpić słowo psychologia nazwą innej dziedziny wiedzy i artykuł nadal byłby “prawdziwy” (np. analiza systemowa organizacji). Poniżej kilka wybranych zjawisk, trapiących niejedną naukę oraz to czym się zajmujemy: analiza systemowa i projektowanie (inżynieria programowania i systemy informacyjne to także nauka).

Praktyka społeczna:

Interesującą cechą psychologii jako praktyki społecznej jest postulowana zbędność wszelkiej teorii, zbędność syntez, uogólnień, a nawet argumentów natury statystycznej. Wystarczy prosta obserwacja. […] Jeśli wiemy, że ?zdarta płyta?, czyli powtarzanie w kółko tych samych argumentów zamęczy każdego, to żadna koncepcja psychologiczna nie jest już potrzebna do męczenia swoich oponentów ? głoszą przedstawiciele tej psychologii.

Wstawmy tu pojęcie “metody agile”, “wywiady z użytkownikiem”, “user story” (bazy danych jako model dziedziny systemu…) itp. a odnajdziemy się natychmiast w naszej branży. Regularnie słyszę od wielu developerów argumenty typu “my (ja) tak od wielu lat i działa, mam więc ogromne doświadczenie” czy też “tak mnie nauczono i nie tylko mnie”.

Innymi słowy, podstawową właściwością tej psychologii jest odwoływanie się do osobistego doświadczenia (?sam to wypróbowałem z powodzeniem?) lub zaufanie do doświadczenia cudzego (?on to wypróbował, a ja mu wierzę?). Niektóre z rekomendacji bywają dość powszechnie podzielane, choć niekoniecznie bywają zasadne. Niektóre w świetle wyników badań są dobitnymi przykładami złudnej skuteczności.

Powyższe brzmi jak wpisy na StackOverflow… Do tego warto dodać, że:

Doniosła rola przekonań potocznych bierze się także z tego, że spełniają one dwie bardzo ważne funkcje. Najważniejsza jest funkcja tożsamościowa ? przekonania te są częścią kolektywnego systemu znaczeń czy też podzielanego światopoglądu (?wszyscy wiemy to samo i tak samo rozumiemy świat?). Jest też funkcja afektywna, bowiem proste narzędzia rozumienia świata (niezależnie od jakości czy głębokości tego rozumienia) są zazwyczaj źródłem poczucia osobistego bezpieczeństwa.

Wielu ludzi uważa, że postępowanie wg. zasad starych i do najczęściej spotykanych jest bezpieczne (konformizm). Argument “nikt tak nie robi” należy czytać “nie spotkałem sie z tym, by ktoś tak robił”. To cecha większości projektów grupowych (realizowanych w grupie). A jeżeli będzie porażka?

Z tego punktu widzenia niezastąpiony wydaje się scenariusz ?Bóg tak chciał? lub ?taka jest wola Boga?.

Metody naukowe (pisałem o nich nie raz) mają pewną cechę:

Słowem, psychologia jako nauka oferuje (a w każdym razie czyni takie wysiłki) teorie, co do których znane są warunki ich obalalności. […] Właściwością psychologii naukowej, która wyraźnie odróżnia ją od psychologii potocznej czy też praktyki psychologicznej jest sposób dochodzenia do twierdzeń naukowych. O ile psychologia potoczna (jeśli czyni to w ogóle) oraz psychologia praktyczna odwołują się głównie do strategii konfirmacyjnych, a więc poszukują potwierdzenia formułowanych hipotez, to psychologia naukowa, nie rezygnując ze strategii konfirmacyjnych, nie poprzestaje jednak na nich. Korzysta także ze strategii falsyfikacyjnych (Brzeziński, 1996). W ten sposób zabezpiecza się (choć nie zawsze skutecznie, czego przykładem może być psychologia ewolucyjna, zob. Buss, 2001) przed tworzeniem koncepcji nieobalalnych.

To znaczy, że nasz opis analizowanej organizacji powinien mieć cechę sprawdzalności, polegającą na zrozumieniu, że potencjalnie istnieje możliwość podważenia efektu naszej pracy. Bez tego nasze analizy (czyli opis tego jak działa to co analizowano), stają się dogmatem, a powinny być teorią wyjaśniającą.

Wynika z tego dość oczywista, ale nadal ważna prawda, że zgodność ze zdrowym rozsądkiem nie może być kryterium wartości badań naukowych.

I to jest sedno tego co chciałem tu napisać: opieranie się tylko na tym, co mówią pracownicy analizowanej organizacji, ich intuicja i ich wiedza, oraz zdrowy rozsądek, jest bardzo kiepskim pomysłem.

Dodać jednak muszę, że krytykowana przeze mnie nie raz praca grupowa, jako narzędzie poprawy jakości zupełnie nie znajduje potwierdzenia w faktach:

Badania nad tak zwanym próżniactwem społecznym odwołują się do teoretycznych założeń na temat rozproszenia odpowiedzialności. Z zebranych danych wynika, że im większa jest grupa wykonująca wspólne zadanie, tym mniejszy jest średni wkład pracy każdego z uczestników (Doliński, 2000; Latane, Wiliams, i Harkis, 1979). Co więcej, działania grupowe są mniej wytrwałe niż indywidualne (Łukaszewski i Marszał-Wiśniewska, 2006).

Praktyka pokazuje, że w projekcie zawsze skuteczniejszy jest jeden, ale dobry, analityk, niż “armia” ludzi zaangażowana w projekt “bo nie ma czasu” (inny argument: klient musi widzieć dlaczego tak drogo).

Zaryzykuje tezę, że większość znanych mi dokumentów tytułowanych jako Wymagania na oprogramowanie albo Analiza Biznesowa, także przyjęte metody pracy (dotyczy także publikacji w sieci internet np. niedawno opisana Generalizacja/Specjalizacja Przypadków Użycia), to niestety “wiedza ludowa” i “praktyka społeczna”…

Na zakończenie gorąco namawiam adeptów sztuki analizowania, ale także “starych wyjadaczy”, do lektury całej cytowanej publikacji (mam nadzieję, że profesor wybaczy mi obszerność cytatów). Ten wpis miał na celu zachęcić Was do tego, a nie zastąpić lekturę oryginału. Mam nadzieję, że wielu z Was ten tekst (oryginał) nauczy pokory…

Źródła

[zotpressInTextBib style=”harvard1″ sort=”ASC”]

Nieco ponad rok temu opisywałem sytuację, w której pewien doświadczony analityk narzekał, że pracownicy jego klientów nie potrafią mu powiedzieć czego chcą i jak ma działać ich przyszły system. Odpowiedź moja jest w takich sytuacjach zawsze taka sama:

…analiza nie polega na słuchaniu! (wyobrażacie sobie leczenie, w którym diagnozy stawiają pacjenci?). Nie raz tu pisałem i kolejny raz powtórzę:
Analiza oparta na zeznaniach i życzeniach jej [firmy zamawiającego] pracowników jest bardzo narażona na fiasko, gdyż subiektywna wiedza pracowników oraz ich spekulacje, mogą nie mieć wiele wspólnego z rzeczywistością lub pożądanym stanem (co nie musi być ich złą wolą). Analiza organizacji nie może więc polegać tylko na zapisanych subiektywnych przekonaniach jej pracowników. Powinna w być 100% oparta na faktach oraz na kontekście jaki tworzy strategia budowana przez Zarząd. (źr. : Strategia? w przypadku 90% małych i średnich firm w Polsce bazowałby Pan na niczym | | Jarosław Żeliński IT-Consulting)

Na stronie opisującej metodykę prowadzenia analiz, napisałem:

Analiza systemowa to proces, oparty na analizie faktów, stosowany w projektach o podwyższonym ryzyku (a projekty informatyczne do takich należą,  ponad 70% tych projektów to niestety projekty nieudane).Podstawowe pytania w analizie systemowej to: ?jak jest i dlaczego jest tak jak jest? oraz ?jak powinno być i co należy uczynić, aby było tak jak być powinno?, modelowanie zaś to narzędzie a nie cel. Podejście systemowe wymusza logiczną analizę realizowanych przez przedsiębiorstwo działań, proponując oparte na modelach podejście, pozwala zrozumieć stan obecny i jego przyczyny. Dzięki temu wyniki analiz systemowych są obiektywne. (źr.: Analiza systemowa organizacji – audyt organizacji | Jarosław Żeliński IT-Consulting)

Dzisiaj artykuł dla zainteresowanych teorią…

Czym jest analiza systemowa?

Analiza systemowa to realizowanie pewnej procedury, która – jak pisze Koźmiński [zotpressInText item=”{5085975:NHWMP6KJ}”] – wygląda tak:

Kluczowym elementem analizy systemowej jest modelowanie, czyli stworzenie abstrakcji badanego zjawiska (organizacji, procesów, itp.), analiza zaś jest procesem iteracyjnym. W obecnych czasach, gdy mówimy o analizie systemowej organizacji,  są to z reguły modele procesów biznesowych, modele informacyjne, modele logiki biznesowej. Na etapie analizy i badania, model taki stanowi hipotezę mówiącą: tak działa dana organizacja. Jeżeli model zostanie uwiarygodniony faktami, stanowi teorię opisującą tę organizację, czyli możliwe są – z użyciem tego modelu – przewidywania skutków wprowadzanych zmian w organizacji. Jest to proces praktycznie identyczny a tym, jaki stosuje się w nauce:

Zgodnie ze słowami samego Alberta Einsteina punktem wyjścia każdej teorii naukowej muszą być fakty i one też muszą być punktem docelowym. Nie ma nauk empirycznych bez faktów. Jak widać na powyższym schemacie każdy naukowiec ? badacz musi umieć poruszać się w dwu ?światach” ? jako teoretyk, znawca dorobku danej dziedziny z którego musi korzystać (i w związku z tym znać go) aby umieć sformułować założenia teoretyczne wyjaśniające zaobserwowane fakty oraz jako ?empiryk” ? musi znać metody sprawdzania wysnutych przez siebie hipotez i koncepcji wyjaśniających świat faktów. Teoria (hipoteza), która nie daje się sprawdzić empirycznie, nie można jej poddać próbie falsyfikacji jest dla nauk empirycznych zupełnie bezużyteczna i jako taka nie jest naukowa.

Tak zwana Analiza Biznesowa organizacji, to proces analizy systemowej, powinna być traktowana jak nauka empiryczna: należy zebrać partię dokumentów operacyjnych, które są niczym innym jak zapisem faktów z życia organizacji. Na ich podstawie powstają modele, które są testowane z użyciem kolejnej partii dokumentów. Wygląda to tak:

A wymagania?

Mam nadzieję, że opisując metodyką  prowadzenia analizy systemowej organizacji metodami zwanymi naukowymi, pomogę zrozumieć potrzebę rzetelnego modelowania. Często o tym pisze i mówię na konferencjach: podstawą dobrej analizy jest rzetelne stosowanie formalizmów użytych notacji oraz metodyka prowadzenia i dokumentowania wyników analizy.

A gdzie wymagania? Otóż  zgodnie z MDA/MDE [zotpressInText item=”{5085975:TBT7B5D2}”] wymaganiem jest projekt systemu (a nie jego wyimaginowane cechy). Związek między analizą systemową a projektowaniem rozwiązania opisał Koźmiński [zotpressInText item=”{5085975:NHWMP6KJ}”]:

Tak więc poszukiwanie rozwiązania problemu polega na zrozumieniu mechanizmu działania organizacji, podjęciu decyzji o optymalnej metodzie rozwiązania problemu i opracowaniu rozwiązania, rozumianego jako rozbudowa lub zakup nowych, zasobów organizacji np. o nowe oprogramowanie, które staje się częścią systemu jakim jest ta organizacja.

Wszelkie metody oparte na burzach mózgów przyszłych użytkowników prawie zawsze skazują projekt na porażkę, intuicyjne opisywanie przyszłości to tylko niesprawdzalne projekcje dotychczasowych doświadczeń. Sam fakt, że projekt wdrożeniowy udało się doprowadzić do końca nie jest żadnym sukcesem, sukcesem jest zrobienie tego i to możliwie najefektywniej, także myśląc o tym, że po zakończeniu wdrożenia ciągiem dalszym są koszty utrzymania i rozwoju, o czym wielu zapomina.

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

W 2013 roku, artykuł o tym czym jest model dziedziny, zakończyłem słowami:

Metody obiektowe polegają na modelowania świata rzeczywistego (domeny systemu), w efekcie nie tracimy żadnej wiedzy modelując (zapisując) ?świat? w postaci modelu dziedziny. Tu warto zwrócić uwagę, że wiedzę o tym jak wygląda faktura jako dokument, musi jakiś obiekt posiadać: to obiekt faktura. (Źródło: Czym jest a czym nie jest tak zwany model dziedziny systemu | | Jarosław Żeliński IT-Consulting).

Mamy rok 2017, więc cztery lata czekało 😉 … 

(more…)

Znakomita większość programów zawiera ponad 10 krotnie więcej kodu niż mogła by mieć, bo programiści często implementują warianty zachowań a nie ich mechanizmy (co powoduje, że systemy te są tyleż razy droższe niż mogły by być).

Prawie za każdym razem, gdy mówię (ale nie robię tego jednak zbyt często 😉 ), że stosuję metody naukowe w analizie, spotykam się z zarzutem, że przesadzam. Zapewne nie ma sensu epatowanie w projektach biznesowych akademickim słownictwem, nie ma znaczenia dobór słownictwa w nazwaniu metody pracy, bo znaczenie ma skuteczność.

Wprowadzenie

Ludzie i ich praca to informacje i ich wymiana. Komputer i oprogramowanie to mechanizm przetwarzania danych reprezentujących te informacje. Projektowanie oprogramowania polega na zrozumieniu i opisaniu tego mechanizmu, tego jakie to dane i jak są (analiza) lub powinny być (projektowanie) przetwarzane. Aby to zrobić analizujemy dokumenty, nie robimy wywiadów.

Jeżeli ktoś tego nie potrafi i nie rozumie, zaczyna organizować wywiady i kodować to, co ludzie postrzegają ze swojej perspektywy. Tak powstaje najgorsze oprogramowanie.

Można to zobrazować jak poniżej:

Dlatego do opracowania projektu przyszłego ‘systemu informatycznego’ należy najpierw zrozumieć ‘system informacyjny’ firmy (organizacji, branży). W tym momencie możesz kontynuować lekturę tego wątku w artykule System informacyjny a informatyczny.

Poniżej po lewej udokumentowany efekt obserwacji z Ziemi, oprogramowanie powstające na bazie wywiadów i obserwacji ma potem podobna strukturę. Po prawej stronie, efekt zrozumienia obserwacji: model, którego wykorzystanie do napisania oprogramowania zaowocuje oprogramowaniem o znacznie mniejszej złożoności i jednocześnie lepsze, bo wierniej odwzorowujące “sytuację biznesową”: powstanie szybciej, będzie tańsze w wytworzeniu i w późniejszym utrzymaniu i rozwoju.

Dlatego napisałem też artykuł: User Story to wymaganie biznesowe, to opis problemu do rozwiązania, a nie funkcjonalność do implementacji! Poniżej po lewej oprogramowanie, które powstało jako efekt implementacji kolejnych wywiadów z użytkownikami (user story), po prawej efekt przemyślanego projektowania.

Dalsza część artykułu to opis tego czym są metody i teorie naukowe. Czytelników, których metodologiczne detale nie interesują zachęcam do lektury wyżej cytowanych artykułów.

Twierdzenie naukowe

Poniżej definicja tego czym jest twierdzenie naukowe:

Twierdzenie naukowe ? zdanie oznajmiające spełniające następujące warunki [zotpressInText item=”{5085975:UYSPURWG}”]:

1. można wobec niego sformułować kryteria pozwalające na eksperymentalne, obserwacyjne lub logiczne ich obalenie (falsyfikowalne według zasad Karla R. Poppera),
2. istnieją reguły jego odczytania, które ograniczają do skończoności liczbę ich interpretacji (kryterium precyzji Józefa Bocheńskiego),
3. odnosi się do empirycznie doświadczalnej lub logicznie definiowanej rzeczywistości (tzw. widły Hume?a),
4. jest elementem zbioru twierdzeń paradygmatu wyjaśniającego rzeczywistość i pozwalającego na przewidywanie jej przyszłych stanów (koncepcja nauki normalnej T. S. Kuhna),
5. twierdzenie będące najprostszym z możliwych opisów świata (tzw. Brzytwa Ockhama).

Graficznie sam proces odkrycia naukowego można pokazać tak [zotpressInText item=”{5085975:5BB35MDU},{5085975:7T7S2GZL},{5085975:MG2IRJC4}”]:

Celowo cytuję tu literaturę z obszaru inżynierii oprogramowania, by pokazać, że nie jestem odosobniony w tym podejściu. Dla porządku podaje także definicje pojęcia model:

model: system założeń, pojęć i zależności między nimi pozwalający opisać (modelować) w przybliżony sposób jakiś aspekt rzeczywistości

Więcej o modelach w nauce: [zotpressInText item=”{5085975:ZUM2B6ZF}”].

Inżynieria oprogramowania

Jeżeli uznamy, że wynik zarówno analizy jak i projektowania, to także modele (przyjmujemy metodę pracy opartą na tworzeniu modeli: MDD/MDA czyli “model driven development”, MDA czyli “model driven architecture”, itp.), to w związku z tym

model, jako wynik analizy, można potraktować jako twierdzenie naukowe opisujące badaną (analizowaną) organizację, jest on zarazem wymaganiem wobec oprogramowania (ma zostać zaimplementowany).

Wyjaśnienie: odniosę się do powyższej definicji twierdzenia naukowego (zgodnie z powyższym pod pojęciem model rozumiemy komplet dokumentacji zawierającej modele, powstałej jako produkt analizy):

1. kryterium falsyfikacji: dopiero wskazanie w badanej organizacji faktu, którego nie opisuje opracowany model, pozwala uznać model (wynik analizy) za zły,
2. istnieją reguły jego (modelu) odczytania, czyli do stworzenia modelu użyto sformalizowanych notacji i systemów pojęciowych (np. BPMN, UML, BMM, SBVR itp),
3. model powstał na bazie, i odnosi się wyłącznie do, zebranych w toku analizy faktów (w szczególności dokumentów, które powstają w toku pracy analizowanej organizacji – dokumenty opisują fakty np. faktura to opis faktu dokonania sprzedaży),
4. model pozwala na przewidywanie tego co zajdzie w odpowiedzi na określone bodźce (paradygmat procesowy opisujący zachowania i paradygmat obiektowy opisujący struktury), mając model procesów biznesowych można przewidzieć produkt procesu, mając model aplikacji można przewidzieć produkt każdego przypadku użycia,
5. opracowany model jest najprostszy (minimalny) z możliwych, czyli nie da się już z niego usunąć nic bez spowodowania jego zniszczenia (uczynienia nieprawdziwym).

Tu, dla dopełnienia,  warto dodać powszechnie uznawaną w świecie nauki definicję prawdy (A.Tarski): twierdzenie prawdziwe to twierdzenie korespondujące z faktami.

Tak więc mamy to co chcemy czyli kryterium odbioru dokumentacji analitycznej i projektowej: nie jest to liczba stron a “to, że mówi prawdę”. 

Z drugiej strony, niestety nie istnieje możliwość wykazania poprawności dokumentacji powstałej w wyniku ankiet, wywiadów czy burzy mózgów spisanej językiem naturalnym … [zotpressInText item=”{5085975:LXK8VA68}”].

Tę “ciężką artylerię”, jak ta tu opisana, wytaczamy głównie dla projektów ryzykownych i kosztownych… 😉 oraz wszędzie tam gdzie ważna jest ochrona know-how.

Dodatek

(dwa dni po publikacji)

Właśnie podesłano mi link do ciekawego tekstu:

One of the most important elements of every Business Analyst?s toolkit is process modeling, which is also significant activity for Business Process Management professionals. For BPM market B? (Źródło: BPMN for Business Analysts ? why, when and how)

Przejrzałem treśc i wszystkie wypowiedzi one “kręcą się” wokół dokumentowania, prezentacji w celu zatwierdzenia lub zgłaszania uwag oraz niektórzy wskazują na możliwość “rysowania zamiast kodowania w celu wykonania”, albo przeoczyłem albo nikt nie zwrócił uwagi na bardzo – mim zdaniem ważny element – tworzenie modelu organizacji czyli tworzenie hipotezy “tak działacie” jako organizacja.

Problem w tym, że chyba większość “użytkowników” tej (BPMN) – i nie tylko – notacji, stosuje indukcyjne metody uwiarygadniania tych modeli, rozumianych raczej jako schematy blokowe. Podejście bazujące na “dowodzie z ilości” (indukcja): model procesów jest dobry bo bardzo dużo osób (osób akceptujących, recenzentów) tak uznało, jest chyba najgorsze.

To błąd logiczny: nie da się wykazać poprawności metodą indukcyjną. Model owszem powinien być jako diagram zrozumiały dla czytelnika, to nie ulega wątpliwości, jednak jego testy powinny polegać na wskazywaniu (szukaniu) ewentualnych faktów typu “a tu mówi nieprawdę”. Innymi słowy model procesu nie jest “dobry” (odzwierciedla prawdziwy mechanizm działania organizacji) dlatego, że wszyscy go zaakceptowali, jest dobry dlatego, że nikt nie znalazł (nie wskazał) jego wady (nie podważono go).

Projektów zakończonych klęską, w których “wszyscy zaakceptowali dokumentację” znamy chyba wszyscy masę….

Tak więc analityk, który podchodzi systemowo do analizy powinien tworzyć hipotezy “tak to działa” i nie dowodzić ich poprawności, a czekać na wskazanie wad. Notacje (BPMN, UML, BMM, …) oraz modele tworzone z ich pomocą, są doskonałym narzędziem do dokumentowania tych teorii.

Na zakończenie polecam to 🙂

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

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.