Wstęp Modele UML są często postrzegane jako niezrozumiałe diagramy. Do napisania tego artykułu skłonił mnie pewien wpis na LinkedIn, w którym pokazano ciekawy schemat blokowy: źr.: Marcel van Oost, LinkedIn, https://www.linkedin.com/posts/marcelvanoost_fintech-payments-paytech-activity-7085945466286153728-GEgt Nie tylko moim zdaniem jest to bardzo obrazowe pokazanie tego jak działają te systemy płatności, szczególnie, że bardzo dobrze jest dobrany poziom abstrakcji: autorowi udało sią pokazać istotę mechanizmu realizacji tych płatności bez zbędnych detali. Pierwsze moje wrażenie, gdy zobaczyłem ten diagram to: to jest diagram komunikacji UML a obrazowe ikony na tym diagramie to stereotypy. Stereotyp czyli typ…
Wprowadzenie Diagramy UML i sposób ich użycia, od samego początku istnienia tej notacji, budzą emocje i fale sprzecznych komentarzy. Powodem jest wysoki poziom abstrakcji etapu analizy i modelowania jako dyscypliny, oraz dość powszechne niezrozumienie istoty ten notacji. Na to nakłada się ogromna różnica między tym co nazywamy analizą i projektowaniem obiektowym (OOAD) a obiektowo-zorientowanymi językami programowania (OOP). Notacja UML jest przez wielu ludzi błędnie traktowana jako kolejny zestaw symboli do tworzenia ilustracji. Większość znanych mi deweloperów uważa, że te diagramy im w niczym nie pomagają i generalnie mają racje, gdyż…
Myślenie systemowe Najprostsze rzeczy bywają najtrudniejsze w modelowaniu, powodem jest ich "pozorna" prostota. Na wielu uczelniach na świecie zaczęły sie pojawiać studia podyplomowe i szkolenia o wdzięcznym tytule "Myślenie systemowe" (System Thinking, np. to na MIT), ich celem jest kształtowanie myślenia zorientowanego na postrzeganie świata jako systemu czyli mechanizmu złożonego z współpracujących obiektów. Tu pojawia się stosowane w nauce pojęcie "mechanizm" . Po co i kiedy używamy tego pojęcia? "Mechanizmów poszukuje się w celu wyjaśnienia, jak powstaje jakieś zjawisko lub jak działa jakiś istotny proces." . Innymi słowy analizując lub…
Wiele problemów w projektach informatycznych, to skutki źle zbudowanej ontologii lub jej braku w projekcie. Niemal co druga firma (46 proc. badanych przez AIIM, 2022) ocenia, że przeciwdziałanie chaosowi informacyjnemu wewnątrz ich organizacji ?wypada słabo? lub ?wymaga poprawy?. Obecnie większość przetwarzanych w firmach treści to treści częściowo lub nawet całkowicie nieustrukturyzowane. Zarzadzanie nimi wymaga nowych metod . [toc] Czym jest ontologia Ontologia jest często nazywana reprezentacją wiedzy. Pozostaje pytanie co jest tu tą wiedzą? Czy wiedzą jest to co oznacza w określonym języki (tu polskim) słowo "samochód", czy wiedzą jest…
[toc] Wprowadzenie Tym razem artykuł na temat typów związków między elementami w modelach systemów. Modele tego typu to hierarchiczna struktura mająca kilka różnych perspektyw, poziomów abstrakcji i poziomów dekompozycji. Do tego dochodzą fizyczne i logiczne powiązania między elementami oraz fakt, że każdy system to określone "materialne" elementy ułożone w hierarchiczną strukturę. Każdy system składa się ze skończonej liczby elementów o skończonej liczbie typów. Na to wszystko nakłada się struktura wymagań na system, oraz konieczność wykazania zgodności projektu systemu z tymi wymaganiami . Bardzo często jestem pytany o to, jak organizować…
Wprowadzenie Coraz częściej czytamy o środowiskach "chmurowych" (nadal nie mogę się przekonać do pisania tego bez cudzysłowu). Nawet tak zaawansowane jak Amazon WS czy AZURE, są nadal bardzo często wykorzystywane tylko jako hosting aplikacji. Oba te serwisy można wykorzystywać jako sieciowy dysk, środowisko systemowe (Windows, Linux), bazę danych SQL, ale także jako bazy NoSQL. Jednym z najistotniejszych elementów systemów informacyjnych (patrz: information science) jest utrwalanie danych (pamiętajmy, że dane to zapisy, a informacja to to, co rozumie człowiek, który je czyta). Niedawno nawiązywałem do problemu utrwalania danych. Poprawna obiektowa architektura…
(opracowanie: kwiecień 2020 - blog, aktualizacja: grudzień 2020 - Academia.edu) Opracowanie stanowi próbę zbudowania modelu wyjaśniającego aktualną sytuację wywołaną pandemią koronawirusa. Tworząc model autor oparł się na idealizacji mechanizmu rozchodzenia sie choroby. Autor całkowicie zarzucił metody statystyczne prognozowania jako nieskuteczne, w takich przypadkach, co pokazały juz pierwsze miesiące od pojawienia sie wirusa, a potem po pierwszej publikacji tego tekstu w kwietniu 2020. Zdaniem autora opisana w tym opracowaniu droga daje znacznie większe szanse na wyjaśnienia aktualnej sytuacji niż budowanie tak zwanych modeli statystycznych. Już na obecnym etapie model wyjaśnia brak…
[zaktualizowany [last-modified]] Niedawno pisałem na temat "modelu systemu" i "modelu dziedziny systemu". Oba te pojęcia są sobie bliskie, pierwsze jest bardzo ogólne, dotyczy systemu zawężonego do jego dziedzinowej specyfiki. Model dziedziny systemu to także, w inżynierii oprogramowania, nazwa konkretnego komponentu, nazywanego Model, w architekturze opartej na wzoru MVC. Swego czasu pisałem, że (Czym jest a czym nie jest model dziedziny...): Pojęcie system oznacza albo detaliczną strukturę określonej rzeczywistości albo abstrakcję ją reprezentującą (model systemu). Jest to standardowe tłumaczenie tego pojęcia w literaturze z zakresu teorii systemów a także właśnie inżynierii…
W recenzji książki Ogólna Teoria Systemów pisałem między innymi, że: Systemy społeczne spotykane wokół nas to z reguły systemy z pamięcią, kolejne reakcje systemu to efekt bodźca jaki się pojawi i wcześniejszych zapamiętanych reakcji (historii). Jak widać takie same bodźce mogą wywoływać inne reakcje w przypadku systemu z pamięcią. Tak działamy my (uczymy się), tak działa większość aplikacji biznesowych (zbiera dane). Systemów bez pamięci także mamy wokół sobie wiele. Od zegarka czy prostego kalkulatora (wyniki podstawowych operacji matematycznych nie zależą historii obliczeń) do robotów kuchennych i wielu podobnych, nawet nie raz bardzo…
Moim zdaniem ten kto wymyślił ocenę pracy policji poprzez licznie ilości wystawionych mandatów (albo gorzej - ich wartość!) jest w moich oczach kompletnym ignorantem nierozumiejącym opisanego zjawiska. Wytłumaczeniem może być chęć pozyskania zwiększonych środków z mandatów, ale to jest nic innego jak działania na szkodę społeczności, którą się reprezentuje!
Dzisiaj krótki artykuł o wymaganiach dziedzinowych. W jednym z poprzednich artykułów pisałem o wymaganiach, że problem tkwi w ich zrozumieniu i o tym, że przyszły użytkownik nie powinien pisać "jaki ma być ten program", bo popycha projekt w stronę chaotycznych oczekiwań. I tu jest sedno: analiza nie powinna być tylko pasmem wywiadów, którego produktem będę setki stron zapisów z ankiet i przeprowadzonych rozmów. Analiza, to duża praca, której celem powinno być zrozumienie a nie tylko opisanie. (Analiza wymagań na oprogramowanie czyli opisanie czy zrozumienie). Wymagania najczęściej dzielimy na funkcjonalne i…
Bardzo często spotykam, pewnie nie ja jeden, specyfikacje wymagań zawierające zapisy "oczekiwań użytkowników". Bardzo często słyszę także, że to przyszły użytkownik oprogramowania powinien być źródłem wymagań. nic bardziej błędnego.. [...] Więc np. wymaganie "system powinien pozwalać na budowanie dowolnych rabatów sprzedaży do stałych klientów" (także cytat z pewnej specyfikacji systemu CRM) jest pustym stwierdzeniem. Po pierwsze jak te rabaty są naliczane, po drugie czy aby na pewno mechanizm pozwala na "dowolne rabaty"... Jak to opisać? Tu powinny się pojawić np. tablice decyzyjne a nie lakoniczne "dowolne rabaty".
Na zakończenie uwaga: jeżeli planujemy kupić gotowe oprogramowanie, to ono już (gdzieś tam) istnieje, i specyfikowanie szczegółów opisujących dokładnie elementy pracy z interfejsem użytkownika i enigmatyczne opisy tego jak "system liczy", jest bezwartościowe. Raczej wywoła listę tak zwanych kastomizacji (zwanych gdzieniegdzie zabójcami projektów :)). Tak jednak właśnie wyglądają najczęściej specyfikacje pisane rękami przyszłych użytkowników: opiszą oni to z czym się stykają i co znają ale w ogóle nie opiszą wnętrza, którego najczęściej po protu nie rozumieją (i nie muszą bo to nie ich rola), wtedy specyfikacje systemów CRM pisane rękami przyszłych użytkowników - np. sprzedawców - zawierają właśnie bezwartościowe zapisy w rodzaju: "system powinien pozwalać na budowanie dowolnych rabatów sprzedaży do stałych klientów" a nie zawierają opisu jak te rabaty wyliczać.
Odpowiadając na tytułowe pytanie: wymagania (funkcjonalne) realizują się w modelu dziedziny systemu, którego nie zawiera większość znanych specyfikacji wymagań... a warunkiem poprawnego wyboru oprogramowania są oczekiwania co do efektów przetwarzania.
