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 . 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ę…
Mamy dwa osobne rodzaje dokumentów: mapy/modele procesów biznesowych czyli łańcuchy aktywności i dokumentów (oraz ich treść) opisujące to jak działa firma, procedury czyli opisy realizacji aktywności w procesach, czyli opisy co konkretnie i jak robią ludzie. Nie należy tego mieszać na tych samych diagramach, bo wychodzą potwory sphaghetti :) Wstęp Od 2003 roku normy serii ISO wymagają, by procedury tworzyły razem logiczny ciąg aktywności (procesy biznesowe). Dotyczy to wielu różnych norm i zaleceń. Testem spełnienia tego warunku jest poprawny, analityczny, model procesów biznesowych w organizacji. Jaki to jest poprawny? Taki,…
#1 - a 3d render series showing change and motion
Wstęp Tym razem o kilku powszechnie popełnianych błędach w korzystaniu z UML. Chodzi o pojęcia abstrakcji, metamodeli i zależności oraz o związki między elementami na diagramach. Kluczową, moim zdaniem, przyczyną tworzenia "złych" modeli obiektowych jest używanie notacji UML do tworzenia modeli strukturalnych, nie mających z obiektowym paradygmatem nic wspólnego. Druga to niezrozumienie pojęcia paradygmatu obiektowego. Ogromna ilość diagramów wykonanych z użyciem symboli notacji UML, z UML i paradygmatem obiektowym ma niewiele wspólnego. Najpierw kilka definicji i pojęć. Paradygmat programowania (ang. programming paradigm) ? wzorzec programowania komputerów przedkładany w danym okresie…
Od czasu do czasu pojawiają się w sieci wołania będące czymś co ja nazywam anty referencjami. W większości znanych mi przypadków jest to wina dostawcy, który: zobowiązał się do realizacji wymagań nie testując ich wykonalności,zobowiązał się do wdrożenia oferowanego rozwiązania bez wykonania (posiadania) rzetelnego audytu biznesowego (komputeryzacja bałaganu) u klienta. Tłumaczenia w rodzaju "bo klient nie wie czego chce" są jedynie wyrazem niekompetencji dostawcy w obszarze analizy przed-wdrożeniowej. Oto przykład takiego "wołania" z Lipca 2016 i próba wyjaśnienia tych zgłoszonych problemów (z oczywistych powodów zanonimizowane). Od sierpnia 2014 r. moja firma…
