Od 17-go kwietnia mamy wersje 13.1 pakietu Visual-Paradigm (i pełnej wersji dla analityków i projektantów: ArchiMetric). Twórcy pakietu bardzo silnie współpracują z analitykami w wielu krajach (należę do nich ;) ) , zbierają sugestie ale też filtrują je. Cieszy mnie to, że w przeciwieństwie do (jak obserwuję) firmy SPARX (producent Enterprise Architekta), nie wychodzą poza standardy. W VP odrzucają wszelkie formy niestandardowych pomysłów (np. aktor "czas" w Enterprise Architect to kuriozalna, niestandardowa konstrukcja) ale za to implementują sprawdzone pomysły na ergonomie pracy oraz zarządzanie spójnością projektu. Jeżeli to tego dodać zdrowe podejście…
Niestety i w literaturze i w materiałach szkoleniowych, czy nawet dydaktycznych na uczelniach (o zgrozo) można się spotkać z takimi "antywzorcami" jak wyżej. Jednym z najbardziej kuriozalnych jest obecnie modelowanie danych z użyciem diagramu klas, nanosząc na nie np. jeszcze klucze główne. Niestety bardzo często autorzy tych materiałów, wykładowcy i trenerzy, zamiast korzystać ze źródeł, przepisują jeden od drugiego pogłębiając marazm w tej dziedzinie, a pierwowzorem wielu tych herezji są niestety materiały publikowane przez firmę SPARX (producent oprogramowania Enterprise Architect) jak choćby mój ulubieniec: czas jako Aktor systemu
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 modeli UML), stały rozwój wsparcia dla architektury korporacyjnej (to narzędzie pozwala tworzyć modele powiązane ze sobą, pozwala na prowadzenie analiz wpływu i wielu innych, wspiera także notację ArchiMate) oraz na prawdę bardzo silne wsparcie dla pracy grupowej. Co dzisiaj ogłasza producent: Visual Paradigm International Limited today [16.12.2013] announced the release of Agilian (AG) 11.0, a Visual Modeling tool for Agile…
Tak więc AK jest to ktoś, kto rozumie całość ale nie musi (nawet nie powinien) być tym, kto ją implementuje, gdyż tu także ważne jest rozdzielenie roli projektującego od wdrażającego. Role te mają nie raz sprzeczne interesy: im głębiej w szczegółach tkwi dana rola (np. developer) tym bardziej w jej interesie leży utrzymanie status quo, mniejszą ma skłonność do wprowadzania zmian.
Od jakiegoś czasu śledzę blog WYCIĘTE Z MEJLI (AD ABSURDUM) (gorąco polecam). Dzisiaj przeczytałem to: "Rozumiem, że lubi Pan pracować w photoshopie, ale uważamy że ten program jest za mało uniwersalny. Proszę pracować w MS Paint, będzie nam łatwiej edytować Pana pliki i wstawiać poprawki." (za pomocą WYCIĘTE Z MEJLI (AD ABSURDUM): Rozumiem). Dokładnie miesiąc temu u jednego z klientów usłyszałem analogiczny zarzut, który można by parafrazować: "Rozumiem, że lubi Pan pracować w "modelerze" (mój CASE VP-Agilian), ale uważamy że ten program jest za mało uniwersalny. Proszę pracować w MS…
