Jednym z moich niedawnych nabytków jest bardzo wartościowa książka, jednak nie jest to podręcznik analizy i modelowania, a opis wieloletnich doświadczeń autorów w tworzeniu i dokumentowaniu architektury oprogramowania. The authors…
Tak więc OK, przemyciłem tu (mam nadzieję) ważne informacje: - sama struktura to nie model, - tworząc jakikolwiek model musimy rozumieć i opisać jego zachowanie, opisać mechanizm działania (zachowanie) każdego elementu tej struktury, - dlatego model dziedziny systemu, czy w ogóle model jakiegokolwiek systemu, to tak na prawdę obiektowy model, który nie może być modelem anemicznym ([[anemiczny model dziedziny]]), - bez zrozumienia mechanizmu działania organizacji, wprowadzając do niej jakiekolwiek zmiany, szczególnie wdrażając oprogramowanie, raczej jej zaszkodzicie niż pomożecie. (dlatego też, diagramy ERD i tak zwane modele danych, pozbawione funkcji, nie są modelami czegokolwiek a jedynie określonym strukturami).
Niestety wiele systemów ERP i i nie tylko, powstało w latach 90'tych, mają one niestety scentralizowaną architekturę strukturalną (jedna baza danych i "nad nią" funkcje przetwarzające te dane). Efekty tego widać przy wdrożeniach, w których dopuszczono tak zwaną kastomizacje systemu, czyli właśnie wprowadzanie, nie raz bardzo wielu, zmian. To bardzo kosztowne projekty o praktycznie nieprzewidywalnym budżecie. Niestety współdzielenie danych wewnątrz takiego systemu jest jego poważną wadą a nie - jak to zachwalają ich dostawcy - zaletą...
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…
Wprowadzenie Całkiem niedawno wpadł mi w oczy artykuł na temat zdalnego prowadzenia analizy, ostatni jego akapit brzmi: Virtual communication and facilitation skills will remain a key competency for BAs for…