Month: February 2020

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”]

W artykule Ile przypadków użycia opisałem przypadki użycia jako narzędzie definiowania zakresu projektu, czyli sposób dokumentowania wymagań. Takie jego zastosowanie jest zdefiniowane w specyfikacji UML [zotpressInText item=”{5085975:DCYU6XZJ}”].

Tym razem chcę ostrzec przed bezkrytycznym “uczeniem się” ze stron internetowych, nawet tych uznawanych powszechnie za “dobre i popularne”. Sam niektóre z nich polecam, ale coraz częściej, nie całe serwisy jako takie, a tylko określone artykuły. Modernanalyst.com też do nich należy. Dziś będzie to artykuł, którego nie polecam, a opiszę go, bo autor powiela w nim dość powszechne błędy notacyjne, błędy które stały się “kanonem” dla wielu autorów stosujących UML.

Poniżej diagram przypadków użycia ze związkami ‘include’ i ‘extend’.

https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/5465/Generalization-Specialization-Use-Case-Diagrams-and-Scenarios.aspx

W UML zależności ‘include’ i ‘extend’ są reliktem analizy strukturalnej (diagramy przypadków użycia wymyślono w latach 80-tych). Związek ‘include’ służy do wyłączania części wspólnej zachowań (scenariuszy) przypadków użycia, w konsekwencji: (1) muszą być co najmniej dwa bazowe przypadki użycia by można było mówić o części wspólnej, (2) część wspólna jest jedynie fragmentem, więc sama (samodzielnie) jako taka do niczego nie służy, więc nie wolno z nią łączyć żadnego aktora [zotpressInText item=”{5085975:DCYU6XZJ,641}”] . Powyższy rysunek łamie obie te zasady. Zależność ‘extend’, to zawarte w przypadku użycia, warunkowe rozszerzenie określonego zachowania i obligatoryjne jest podanie warunku (zdarzenia) uruchamiającego to dodatkowe zachowanie [zotpressInText item=”{5085975:DCYU6XZJ,640}”]. Tu także tę zasadę złamano.

A gdy projekt jest “obiektowy”? Specyfikacja UML jasno mówi: Use Case define the offered Behaviors of the subject without reference to its internal structure [zotpressInText item=”{5085975:DCYU6XZJ,639}”]. Tak więc tych związków po prostu nie używamy w projektach, o których mówimy, że są obiektowe, bo łamią podstawową zasadę paradygmatu obiektowego jaką jest hermetyzacja.

Kolejne nadużycie to stosowanie generalizacji na diagramie przypadków użycia: nie jest przewidziana dla tego diagramu (a dziedziczenie zostało słusznie z UML usunięte w 2015 roku wraz z opublikowaniem wersji 2.5 UML). Zachowania systemu to określone odrębne (hermetyzacja) elementy, tu także obowiązuje zasada nie stosowania diagramu UML do opisu architektury systemu/kodu. Po drugie, nawet gdyby autor miał na myśli stare “dziedziczenie”, to co do zasady nie łączymy aktorów z elementami abstrakcyjnymi modelu (“wołanie przodka” to dawno temu opisany antywzorzec obiektowy).

https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/5465/Generalization-Specialization-Use-Case-Diagrams-and-Scenarios.aspx

Poniżej diagram profilu UML definiujący pojęcie przypadek użycia (sprawne korzystanie z notacji UML wymaga umiejętności czytania tego diagramu). I cóż my tu mamy? Należy to interpretować tak: związki ‘extend’ i ‘include’ to integralne części ich przypadków użycia, są to związki skierowane, przypadek rozszerzany MUSI mieć punkt rozszerzenia (rozszerzający). Nie ma tu w ogóle możliwości użycia generalizacji między elementami na tym diagramie.

Data publikacji tego artykułu: 5 styczeń 2020, czyli jego autor pisał to pięć lat po publikacji UML v.2.5! Zaś, miejsce publikacji tego tekstu to zacny serwis Modern Analyst:

What can Modern Analyst do for YOU?
Let Modern Analyst help you gain an edge over your competition!Whether you are a training provider, an experienced practitioner, a tool vendor, or a recruiter focusing on business systems analysis, make Modern Analyst work for YOU. (źr.: What can Modern Analyst do for YOU?)

Autor sam o sobie:

Author: Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP?) by the Project Management Institute (PMI?), a Certified Business Analysis Professional (CBAP?) by the International Institute of Business Analysis (IIBA?), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance. He holds an Advanced Master’s Certificate in Project Management and a Business Analyst Certification (CBA?) from George Washington University School of Business. Mark is also a member of the Association for the Advancement of Cost Engineering (AACE) and the International Association of Facilitators (IAF).

Nie rzadko słyszę, że “ale ten diagram ma pokazać jak system działa”. Niestety ten diagram nie służy do “pokazania” (dokumentowania) tego, jak działa aplikacja. Do tego służą inne diagramy (oznaczone na poniższym schemacie blokowym, diagramy aktywności służą obecnie do modelowania kodu wiec nie są używane na etapie analizy i projektowania, lub tylko do dokumentacji algorytmów) [zotpressInText item=”{5085975:TBT7B5D2}”]. Jest to – diagram przypadków użycia – od 2015 roku, diagram pomocniczy, służący wyłącznie do określenia zakresu projektu, czyli wymagań. Autorzy specyfikacji piszą: “Use Case are a means to capture the requirements of systems, i.e. what systems are supposed to do” (Przypadek użycia jest sposobem na uchwycenie wymagań na systemy, tj. tego CO systemy mają zrobić [dla aktora, a nie JAK]).

[zotpressInText item=”{5085975:DCYU6XZJ,14}”]

Często słyszę zarzuty, że “diagramy UML i dokumenty je zawierające, nie pomagają developerom, dlatego nie używamy UML”. No cóż, ale diagramy, jak ten tu opisany, i nie raz jak te na stronach Wikipedii czy Stackoverflow, prezentują podobny poziom, i faktycznie nie są przydatne… A stosowanie diagramów przypadków użycia do opisu “procesów” (łańcuchy ‘extend’ i ‘include’) to wręcz epidemia.. ;). Przypominam także, że logowanie to nie przypadek użycia (use case) aplikacji, a funkcjonalność środowiska aplikacji (są też inne metody uwierzytelniania użytkownika).

Dlatego polecam źródła rzetelnej wiedzy o notacjach, a są to oryginalne specyfikacje, których umiejętność czytania jest podstawową umiejętnością dobrego analityka i projektanta. Tu nie chodzi o “głupie bycie ortodoksem”, chodzi o JEDNOZNACZNOŚĆ dokumentacji, czyli i autor dokumentu i jego adresat, powinni używać tego samego “kodu”, czyli stosować się do specyfikacji używanej notacji. Bez tego mamy wyłącznie nieporozumienia i dodatkowe koszty w projektach.

W rankingach przyczyn porażek projektów, niejednoznaczność dokumentacji zawsze jest w pierwszej trójce.

Źródła

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