Co nowego w Visual Paradigm 12.1

Od 2005 roku jestem użytkownikiem pakietu CASE Visual-Paradigm (poprzednia nazwa Agilian). Od tamtej pory nie zmieniłem narzędzia mimo, że na warsztatach, które prowadzę, mam przegląd chyba wszystkiego co mamy na rynku, a co przynoszą ze sobą na notebookach uczestnicy tych warsztatów. Whats new in 12.1 - strona o tym tytule powitała mnie dzisiaj z rana gdy sprawdzałem pocztę. Rozszerzony generator raportów. Nowy typ raportu generujący dokumenty wynikowe z szablonów word.Nowa wersja narzędzia to tworzenia mock-up'ów, dodano także możliwość korzystania z istniejących WWW przy dokumentowaniu zmian.Ulepszona Postmania (strony dla recenzentów diagramów).Integracja Vpository z…

Czytaj dalejCo nowego w Visual Paradigm 12.1

Visual Paradigm 12.0

Dzisiaj niespodzianka pod choinkę :) czyli VP wersja 12.00. Zaczynam prace a tu taki email: Dear Jarek Zelinski,We are thrilled to introduce to you the brand new Visual Paradigm - Visual Paradigm 12.0 with a new user interface and suite of new tools which improves your modeling efficiency. One of the highlighted improvements is the increase in diagram editing space, which means you have more room for editing your design and can be more focused on modeling. Click here to watch the introduction video of the Sleek UI, the official…

Czytaj dalejVisual Paradigm 12.0

Visual-Paradigm czyli pokaż czym pracujesz a powiem Ci kim jesteś…

Pakiet którego używam (Visual-Paradigm) po ostatnich zmianach ma szanse stać się w moich oczach ideałem :).  O jego nowej wersji pisałem tu: Visual-Paradigm v.11.1. Pisałem tez, że jest w 100% zgodny ze specyfikacjami notacji zarządzanych przez OMG, co jest bardzo ważne. Tu zwrócę uwagę na kilka przydatnych cech. Moim zdaniem cechą dobrego projektu jest nie tylko dobra metodyka ale także to czy dysponujemy narzędziami, które ją wspierają. Tymi narzędziami są nie tylko notacje i systemy pojęciowe ale także oprogramowanie CASE, które powinno spełniać trzy kluczowe warunki: wspierać (a przynajmniej nie ograniczać) metodykę,…

Czytaj dalejVisual-Paradigm czyli pokaż czym pracujesz a powiem Ci kim jesteś…

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 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…

Czytaj dalejVisual Paragim Agilian 11.0

CASE czyli komputerowe wspomagania analizy i projektowania systemów

I teraz sedno czyli co nam daje dobre narzędzie CASE? otóż powyższe macierze (takie i każdą inną) oraz model analizy wpływu, są generowane i aktualizowane automatycznie. Wystarczy opracować standardowe modele w BPMN i UML jak powyżej, wskazać związki pomiędzy elementami jako ich parametry (nie trzeba do tego celu tworzyć sztucznych diagramów) i skorzystać z możliwości automatyczne dokumentowania tych związków.

Czytaj dalejCASE czyli komputerowe wspomagania analizy i projektowania systemów

O narzędziach CASE – rzadko ale jednak piszę

Prawdę mówiąc "zabraniam" przynoszenia komputerów na moje szkolenia, wymagam papieru i ołówka. Powody są dwa: Narzędzia CASE pomagają tylko wtedy gdy diagramów jest wiele i model jest złożony, na szkoleniach takich modeli się nie robi. Narzędzia, w szczególności niektóre, płatają figle i szkolenie np. z zakresu analizy biznesowej ewoluuje w stronę szkolenia z obsługi narzędzia.... do czego nie dopuszczam :). Napisze tu kilka słów jednak o narzędziach, bo dobrze jest jednak znać dobre i złe cechy swojego narzędzia. Spotykam się nie raz z bardzo popularnym pakietem CASE (SPARX Enteprise Architect) na szkoleniach (ma go wielu…

Czytaj dalejO narzędziach CASE – rzadko ale jednak piszę

Projekt wykonany – co było robione

Powyższe jest zgodne z zaleceniami OMG.org (https://www.omg.org/mda), audyt to etap CIM a projektowanie przypadków użyci i modelu dziedziny to etap PIM. Wykonanie takiej analizy jest pracochłonne i wymaga dużego doświadczenia, umiejętności analiz procesów biznesowych, projektowania obiektowego i dobrego narzędzia CASE, jednak modele te pozwalają także przeprowadzić analizy wpływu (zależności pomiędzy procesami, skutki i podatność na awarie oprogramowania itp.) oraz zredukować do minimum prawdopodobieństwo przekroczenia terminu i kosztów (statystyki wskazują na średnie przekroczenie kosztów o 60% i terminów o 200% projektów z niskiej jakości specyfikacji wymagań). Praktyka autora wskazuje, że warto taką analizę przeprowadzić dla projektów, których budżet przekracza 50-70 tys, zł i większych.

Czytaj dalejProjekt wykonany – co było robione

UML MDA czyli od biznesu do projektu logiki systemu

To co najczęściej wzbudza brak zaufania to teza, że można przeprowadzić analizę i projektowanie oprogramowania "na papierze". Programiści w większości uważają, że to nie możliwe (rok temu na stronach tego bloga burzliwa dyskusja z jednym z nich...). W większości przypadków podczas spotkań (konferencje, projekty itp.) z zespołami programistów słyszę: "czytamy wymagania, kodujemy od razu i tworzymy kolejne wersje aplikacji; inaczej się nie da". W przypadku szkoleń, ostatniego dnia warsztatów najczęściej słyszę: "ooo, w ciągu jednego dnia [teraz] powstał kompletny projekt dziedziny systemu [chodziło o komponent], przetestowany i oczyszczony z wątpliwości, braku logiki i niespójności, do tego łatwy w dalszym rozbudowywaniu; to co zrobiliśmy teraz na diagramach UML w ciągu dnia, jako zespół tradycyjną metodą robilibyśmy co najmniej tydzień, biorąc pod uwagę kodowanie każdego pomysłu by go dać użytkownikowi do testów". W zasadzie taki proces analizy i projektowania jest znany od lat jako [[Model Driven Architecture]] (MDA). [...] Larman w swojej książce opisuje niemalże identyczne podejście (tabela poniżej). Kluczową różnicą jest jednak źródło informacji pierwotnej. U Larman'a jest to model przypadków użycia i ich scenariusze. W porównaniu z modelem biznesowym, podlegającym testowaniu czy walidacji, całe ryzyko projektu spoczywa na jakości modelu przypadków użycia. Jeżeli powstały one jako efekt np. burzy mózgów, ankietowania pracowników zamawiającego czy tak zwanych sesji JAD (Joint Application Development) to jest bardzo prawdopodobne, że całe ryzyko złej jakości takiego modelu (a jest ono bardzo duże jak pokazuje praktyka) zostanie przeniesione na projekt. To jest właśnie problem nazywany "użytkownik nie wie czego chce". Po to się robi analizy biznesowe by w końcu wiedział. Nie zmienia to faktu, że książkę Larman'a gorąco polecam każdemu projektantowi i programiście z ambicjami na metody obiektowe i wzorce projektowe.

Czytaj dalejUML MDA czyli od biznesu do projektu logiki systemu

Zarządzanie zmianą w projekcie analitycznym

No cóż, temat się w rozmowach powtarza, jest nie łatwy więc kilka słów. Pomijając narzędzie, którym się tu posłużę, chodzi o "pryncypia" :): bezpieczeństwo projektu oraz zarządzaniem wersjami, zmianą, w tym wymaganiami. Zarządzanie zmianą Po pierwsze wydaje mi się, że chyba najlepszym sposobem na zarządzanie wersjami, zmianami, śledzeniem projektu itp. są wypracowane mechanizmy znane każdemu kto korzysta(ł) z takich narzędzi do zarządzania projektami jak SVN ([[Subversion]]) czy [[CVS]]. Chodzi o coś co się nazywa: znaczniki, gałęzie, wersje. Projekt ma tak zwaną linie główną (baseline, trunk). Jednak w trakcie prac nad projektem warto czasem stworzyć "odnogę" projektu. Pozwala…

Czytaj dalejZarządzanie zmianą w projekcie analitycznym

Jolt Award: Visual Paradigm for UML

[singlepic id=228 w=320 h=240 float=right] Nie tylko ja jestem zdania, że używanie zaawansowanych systemów wspomagających prowadzenie analiz jest cechą analityków (firm), którzy przekroczyli pewien próg profesjonalizmu. Zapewne pojawią się tu zarzuty o zarozumiałość albo "wydziwianie", ale rozejrzyjmy się. Analityk to osoba wspierająca np. wdrażanie złożonych systemów ERP lub innych, nie mniej złożonych dedykowanych systemów (oprogramowania). Skoro ktoś poleca swoim klientom zaawansowane oprogramowanie wspomagające zarządzanie złożoną firmą czy organizacją, to jak prezentuje się na tym tle on sam, używający prostych i pracochłonnych narzędzi by to złożone oprogramowanie projektować? Można powiedzieć: "po narzędziach go…

Czytaj dalejJolt Award: Visual Paradigm for UML

Koniec treści

Nie ma więcej stron do załadowania