Wprowadzenie Bardzo często spotykam się z metodami wymiarowania oprogramowania, czyli mówiąc ludzkim językiem: oceny pracochłonności jego wytworzenia. Typowym argumentem za stosowaniem tych metod jest potrzeba planowania. Nie raz spotykam się…
Ukazują się różne opracowania na temat tytułowej transformacji. Jednym z takich opracowań jest tekst Transformacja Modeli Pana Piotra Carewicza z firmy 300 D&C, opublikowany w periodyku Analiza Biznesowa Lato 2015 firmowanym…
Dzisiaj bardzo krótko. Bardzo lubię termin "inżynieria wymagań" dlaczego? Po kolei. Z wiedzy o semantyce i semiotyce wiemy, że zastąpienie pojęcia jego definicją nie może zmienić (nie może, jeżeli definicje są…
Nie powinniśmy zapominać, że model Kruchtena to połowa lat 90-tych, szczyt rozkwitu metod strukturalnych i raczkujące metody i narzędzia obiektowe. To stare systemy i ich relacyjne bazy danych wymusiły stosowanie [[mapowania ORM]] i takich narzędzi jak [[Hibernate]]. Dzisiaj mamy rok 2015, od tamtej pory minęło 20 lat. Nie musimy się cofać do początków inżynierii oprogramowania w wersji obiektowej. Coś takiego jak perspektywa danych to anachronizm. Podejście to w 100% zostały już dawno zastąpione przez MDA.
SBVR to specyfikacja opisująca tworzenie modeli pojęciowych, słowników pojęć i reguł biznesowych. Aktualną wersje specyfikacji można pobrać tu: Semantics Of Business Vocabulary And Rules (SBVR)The current version is found at…
Pełny tytuł książki to: Enterprise Architecture As Strategy: Creating a Foundation for Business Execution. Bardzo ciekawa książka, autorzy dzielą się wynikami badan jakie prowadzą od 1995 roku a dotyczącymi sposobów opisywania…
Tak więc modele procesów, w których pojawiają się tory reprezentujące jakiekolwiek oprogramowanie gwałcą tę podstawową zasadę: organizacja to celowe działanie ludzi, narzędzia im w tym tylko pomagają, narzędzia nie są istotą działania organizacji. Można to sprawdzić czymś co ja nazywam testem wyłączenia zasilania: czy wyłączenie automatów pozbawi organizację sensu jej istnienia? Jeżeli nie to znaczy, że automaty nie pełnią ról w procesach, a są jedynie narzędziami w rękach ludzi. Narzędzi nie umieszczamy więc w modelach procesów.
Warstwa procesów, usług aplikacyjnych/przypadków użycia i komponentów to odrębne warstwy i perspektywy. Nie mieszamy więc ani poziomów abstrakcji ani perspektyw modeli. W przeciwnym razie, ulegając sugestiom w rodzaju „ale ja chcę zobaczyć to wszystko na jednym diagramie” pchamy projekt w kierunku „utraty panowania nad złożonością”… To prosta droga do klęski projektu.
