- 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 kursantów i jest używany w wielu firmach) i u niektórych klientów. Pakiet ten jednak nie raz sprawiał pewne kłopoty. Nie znam zbyt dobrze tego narzędzia w obecnej wersji, wiem, że model przechowywany jest w relacyjnej bazie danych, ale niedawno trafiłem na coś, co wyjaśnia mi pewne „przygody z pakietem Enterprise Architect”. Przytaczam cały akapit z tego opisu, bo to w zasadzie jest to lista wad tego pakietu. Problemy z projektem, a konkretnie z jego integralnością mogą pojawić się…
…w następujących sytuacjach:
Z modelu korzysta wielu użytkowników, których połączenia sieciowe mogą być przerywane. Wystarczy, że jest prawdopodobieństwo, że ktoś bez zamykania projektu wypnie z sieci laptop lub zostanie zerwane połączenie VPN.
Model jest skonfigurowany z systemem kontroli wersji. W takim przypadku mamy do czynienia z wieloma operacji importu plików XMI. Zawartość takich plików może pochodzić z innego modelu a połączenie takich danych może skutkować utratą integralności na przykład w zakresie użytych stereotypów, czy relacji do elementów spoza pliku XMI.
Model bywa aktualizowany w oparciu o pliki XMI przy użyciu funkcji Import Package from XMI lub Batch XMI Import. Sytuacja jest analogiczna do powyższej.
Model jest zintegrowany z innymi aplikacjami/systemami, takimi jak HP Quality Center, Mantis itp.
Model jest wykorzystywany przez jednego użytkownika w postaci lokalnego pliku EAP, jednakże podczas wykonywania jakiejś operacji program EA lub system operacyjny uległ awarii.
Z powyższego opisu wynika, że z funkcji tej (kontrola integralności projektu) należy korzystać przede wszystkim w przypadku, gdy mamy do czynienia ze współdzielonym modelem, jak i w przypadku lokalnego projektu opracowywanego przez jedną osobę. Może tylko z tą różnicą, że prawdopodobieństwo wystąpienia niespójności jest wyższe w tym pierwszym przypadku.
(Enterprise Architect Blog: Project Integrity Check od środka).
Wszystkie powyższe sytuacje to efekt tego, że EA do pracy w grupie (samodzielnie także) musi pracować na relacyjnej bazie, na której praca ta odbywa się siła rzeczy on-line. Po drugie nie ma on narzędzia kontroli spójności projektu (danych w tej bazie) „w locie” więc można tworzyć „zły model” nie wiedząc o tym…
Dlaczego o tym pisze? Używam pakietu Visual-Paradigm (więcej o nim na końcu). Pakiet ten nie ma żadnej z tych wad, pracuje zawsze off-line na pliku XML i zniszczenie projektu jest mało prawdopodobne. Jeżeli zdarza się utrata integralności to raczej w sytuacji gdy użytkownik usuwa wybrane elementy modelu i zignoruje ostrzeżenie o powiązaniach tych elementów z innymi usuwają je ręcznie bez wbudowanej kontroli. Pakiet VP ma możliwość pracy z tak zwaną kontrolą składni „w locie” więc w zasadzie nie możliwe jest tworzenie „złego” modelu.
W przypadku pracy grupowej (z serwerem dedykowanym VP Teamwork Server lub Subversion, Perforce, ClearCase czy CVS.) uszkodzenie projektu także jest niemalże niemożliwe, bo tu także praca odbywa się off-line, a update projektu jest nie tylko transakcją, ale jak tylko zostaną wykryte konflikty pomiędzy aktualnym projektem na serwerze a projektem ładowanym na serwer (robi to serwer lub klient VP z dokładnością do obiektu na modelach) pokazywana jest lista konfliktów (nierozstrzygalnych automatycznie) z prośbą o reakcję.
Tak więc jeżeli ktoś z Państwa nie dokonał wyboru narzędzia CASE a planuje taki, warto przetestować dostępne na rynku produkty w warunkach nieco „cięższych” niż kilka diagramów… Poniżej kluczowe korzyści ze stosowania narzędzi CASE:
Make a pie. Estimate the % time you are spending on these five requirements activities: planning, eliciting, analyzing, documenting and reviewing. Does it look like this?
Źródło: Business Analyst | 2 Requirements Tasks You’re Probably Spending Too Much Time On
Nie chciałbym sprawiać wrażania, że tylko się tu czepiam. W większości się zgadzam, nie zawsze piszę gdy się zgadzam 🙂
Tak się ciekawie składa, że właśnie mam problem z modelem EA, ale z powodów innych niż tu opisane.
Z EA(http://sparxsystems.com/) korzystam od wielu lat. Głównie pracując z modelem przechowywanym tylko w bazie, co ma zalety:
– prosta konfiguracja i niska bariera wejścia
– zawsze aktualny model do wglądu
– nie ma problemów z zarezerwowanymi częściami modelu
– kopia bazy nie gubi żadnych informacji (przy eksporcie do XMI czasem psuje się rozkłożenie elementów)
jak i wady:
– słaba kontrola zmian i cofanie do wcześniejszej wersji
Takie rozwiązanie sprawdza się gdy w modelu zmiany są raczej drobne, a głównie zależy nam na tym, żeby deweloperzy mieli wszystko jak najbardziej aktualne i pod ręką.
Oczywiście jest możliwa też praca z modelem w systemie kontroli wersji, przechowywanym jako pliki XMI. Nie zdecydowałem się na to z bardzo prostego powodu: nie mam czasu na dyscyplinowanie ludzi używających modelu, a takie rozwiązanie wymaga pewnej dyscypliny.
W bieżącym projekcie, za namową kolegi, który ma z tym pozytywne doświadczenia, wprowadzamy model hybrydowy, czyli model zarówno w bazie jak i w svn. Na razie pojawiły się problemy z wykonaniem, ale było by to bardzo dobre rozwiązanie pod wieloma względami – łatwy dostęp do odczytu połączony z kontrolą zmian.
od kilku lat pracuje z serwerem SVN (teraz z poszerzonym deddykowanym) i nawet jeżeli pracuje sam to:
– w projektach często oddaję klientowi kolejne iteracje np. najpierw model przypadków użycia, potem model dziedziny, potem modele poszczególnych przypadków użycia, każdy taki etap wykrywa i poprawia nieścisłości poprzedniego albo okazuje się, ze jakiś pomysł się nie sprawdzić i należy wycofywać się do wersji z przed „złego pomysłu”. tagowanie każdej iteracji oraz stosowanie odgałęzień dla ryzykownych pomysłów bywa zbawieniem, w przypadku gdy „stara wersja” się nie sprawdzić lub należy sprawdzić „co klient dostał miesiąc temu”,
– przy pracy grupowej zyskujemy nie tylko kontrole co kto robi ale także kontrole dyscypliny „właścicielstwa” modelu, pakietów czy komponentów.
Bardzo dużą wartość ma możliwość operowania wzorcami projektowymi. Każdy dobry i sprawdzony pomysł można włączyć do projektu, jeżeli mamy taki zestaw wzorców dla grupy to zamiast „odkrywać Amerykę” można takie wzorce włączyć jako „dorobek”, firmomwe know-how.
Niecenioną „dodatkową” korzyścią używania serwera SVN jest backup tego co robimy na bieżąco. Z SVN pracuje się off-line co także niejako chroni projekt przez problemami «wspólnej pracy na otwartych plikach”.. o ile narzędzie do modelowania obsługuje konflikty (nie znam tu EA na tyle)…