Przypadki użycia nie znają swoich realizacji

Tak wiec pisząc “Krowa z silnikiem odrzutowym, jelita na czerwono, jądrowymi kopytami, wyprawiona na buty skóra, zniszczyła metro, wypadek samochodowy, przelatując nad Warszawą, liczba płyt chodnikowych to 1347, a następnie wylądowała w Elektrociepłowni Żerań, załadunek węgla w południe wykonany przez Kowalskiego, i pożywiła się węglem popijając wodę z Wisły” to poprawne gramatycznie, bezbłędnie napisane zdanie w języku polskim, ale nikt nie ma chyba wątpliwości, że kompletnie pozbawione sensu. Tak samo można poprawnie, zgodnie z zasadami notacji, narysować diagram UML …

Czytaj dalej Przypadki użycia nie znają swoich realizacji

Architektura korporacyjna w roku 2015 ? prognoza

Regularnie czytam blog Andrzeja Sobczaka, profesora SGH. Czasami bywa, że mam odmienne zdanie niż tam prezentowane, i tym razem też tak jest. Ostatni wpis na tym blogu zawiera siedmiopunktową prognozę na…

Czytaj dalej Architektura korporacyjna w roku 2015 ? prognoza

Czy system pełni rolę w procesie?

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.

Czytaj dalej Czy system pełni rolę w procesie?

Sekwencje a procesy

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.

Czytaj dalej Sekwencje a procesy

Process for System Architecture and Requirements Engineering

Warto tę książkę przeczytać, by poznać dobrze opisaną, spójną koncepcję analizy i modelowania systemów w rozumieniu organizacji. Dla kogoś mającego przywiązanie do analizy strukturalnej, opisany szkielet będzie zapewne dobrym narzędziem pracy. Przyznam jednak, że kojarzy mi się to z latami 90-tymi i pierwszymi narzędziami typu EJB ([[Enterprise Java Bean]]) i anemicznym modelem dziedziny.

Czytaj dalej Process for System Architecture and Requirements Engineering

Ogarnąć złożoność

Wakacje sprzyjają filozofii. Tym razem kontynuacja opisanej tu niedawno książki Kotarbińskiego: Kurs logiki. Logika bardzo pomaga w analizie. Prawie trzy lata temu pisałem o Trzech zasadach logiki, jedna z nich …

Czytaj dalej Ogarnąć złożoność

Proces to strategia nie taktyka

Jednym z największych błędów popełnianych w projektach związanych z modelowaniem procesów biznesowych jest zapominanie o tym, że model procesu to model organizacji a nie tylko dokument, i o tym, że pomiędzy procesami a procedurami, umiejętnościami, instrukcjami obsługi narzędzi, jest granica. To się nazywa utrata panowania nad złożonością projektu. Kolejny problem to powszechne traktowanie notacji (np. BPMN) jako biblioteki symboli, co jest kluczowym błędem: notacja to model pojęciowy – podstawowe narzędzie analizy i modelowania.

Czytaj dalej Proces to strategia nie taktyka

Visual Paragim Agilian 11.0

Pojawiła się oczekiwana wersja 11 pakietu CASE firmy Visual-Paradigm. Przede wszystkim rozwój produktu idzie w kilku głównych kierunkach: wsparcie dla wizualnego projektowania aplikacji (mock-up'y, kolejne ułatwienia w tworzeniu i integrowaniu…

Czytaj dalej Visual Paragim Agilian 11.0