piątek, 28 czerwca 2013

Co to jest GUID?

Pracując z Enterprise Architect w wielu miejscach można się natknąć na pojęcie: GUID. Jest to skrót od nazwy Globally Unique Identifier, czyli globalnie unikalny identyfikator.
GUID to 128-bitowa liczba służąca do jednoznacznego oznaczenia określonych zasobów. Jest on szeroko stosowany w środowisku Microsoft Windows i wcale nie jest charakterystyczny dla EA.
Może przyjmować mniej więcej taką formę:
1CECA3FE-17EB-40ce-BAFA-13B01F5C5EDC
Myślniki są dodawane tylko w celu poprawy czytelności. Formalnie GUID jest liczbą, jednak developerzy często potrzebują traktować go jako String. Zresztą w repozytorium EA jest on przechowywany jako tekst.

Można go porównać do odcisku palca człowieka. Zakłada się, że każdy człowiek posiada niepowtarzalne odciski palców, dzięki którym można go jednoznacznie zidentyfikować. Podobnie w środowisku informatycznym opracowano odpowiedni standard, dzięki któremu można jednoznacznie wskazać dowolne obiekty. Standard ten został szczegółowo opisany w RFC 4122 A Universally Unique IDentifier (UUID) URN Namespace.

czwartek, 27 czerwca 2013

Replikacja repozytorium - jak to zrobić?

W poprzednim artykule o replikacji repozytorium wskazałem, kiedy warto zdecydować się na replikację repozytorium EAP. Podałem wady i zalety takiego rozwiązania oraz opisałem proponowany proces, który powinien moim zdaniem towarzyszyć tego typu pracy grupowej.

W tym miejscu opisuję temat replikacji od strony technicznej.

środa, 26 czerwca 2013

Replikacja repozytorium EAP

Gdy nie jedna osoba, a zespół ludzi pracuje nad projektem wówczas zachodzi potrzeba zorganizowania jednego współdzielonego repozytorium. W przypadku pracy z programem Enterprise Architect mamy wiele możliwości zorganizowania pracy.
Jedną z takich metod jest replikacja.

Kiedy warto stosować replikację?

Replikacja najlepiej sprawdza się, gdy użytkownicy modelu:
  • pochodzą z różnych organizacji - w konsorcjum, podwykonawcy;
  • pracują w różnych lokalizacjach, w różnych sieciach;
  • są mobilni - pracują u klienta, z domu, z biura.

wtorek, 25 czerwca 2013

Oznaczanie zmian pomiędzy wersjami generowanych dokumentów

Dokumentacja projektowa powstaje zazwyczaj iteracyjnie. Czyli najpierw powstaje pierwsza wersja dokumentu, która jest opiniowana. Zgłoszone uwagi do dokumentu są uwzględniane przez autora (autorów) i w odpowiedzi powstaje druga wersja dokumentu i tak dalej... W innym scenariuszu, gdy dokument opisuje działający system informatyczny - zawartość dokumentów zmienia się wraz z wprowadzanymi modyfikacjami do systemu.
Gdy opisywane rozwiązanie jest małe, wówczas adresaci dokumentacji mają szanse się orientować dokładnie w zawartości dokumentów. Jednak, gdy dokumentacja dotyczy dużego i złożonego systemu, wówczas rodzi się potrzeba odpowiedniego oznaczania zmian w dokumentacji. Dzięki takim oznaczeniom osoby, które opiniują dokument mogą ograniczyć się na przykład do opiniowania tylko i wyłącznie treści dodanych lub zmienionych w odniesieniu do ostatniej wersji.

Jeśli dokumentacja projektowa powstaje wprost w MS Office, wówczas najlepszym sposobem na oznaczanie zmian pomiędzy wersjami wydaje się:

  • zastosowanie Trybu Rejestracji Zmian (ang. Track Changes),
  • lub oznaczanie kolorami dodanego tekstu oraz przekreślanie tekstu usuniętego.
Jeśli jednak zespół w trosce o poprawę jakości generowanej dokumentacji i ograniczenie pracochłonności, decyduje się na generowanie dokumentacji projektowej z narzędzia Enterprise Architect - wówczas wykorzystanie Trybu Rejestracji Zmian nie jest możliwe.

Co można zrobić w takiej sytuacji?

poniedziałek, 24 czerwca 2013

MS Office vs. Enterprise Architect

W rozmaitych okolicznościach spotykam się z zespołami projektowymi, które skomplikowane zagadnienia projektowe dokumentują w postaci dokumentów MS Word i MS Excel. Twórcy takiej dokumentacji wkładają mnóstwo wysiłku w jej wytworzenie i są często z niej dumni.
Dla przykładu spotkałem się z arkuszem MS Excel, który opisuje szczegółowo procesy biznesowe w całej organizacji z uwzględnieniem obecnego i przyszłego wsparcia przez poszczególne funkcje systemów informatycznych w dodatku z rozróżnieniem na różnice w poszczególnych jednostkach organizacyjnych. Imponujące, prawda?
Twórcy takiego arkusza szczycą się tym, że w tym jednym dokumencie opisane są najważniejsze aspekty architektury biznesowej i wsparcia jej przez systemy informatyczne. Zdaję sobie sprawę, że wypełnienie treścią tego ogromnego arkusza poprzedzone zostało wieloma godzinami pracy i konsultacji z klientem.
Ja jednak czytając tego typu dokumenty mam problem, bo zdaję sobie sprawę z tego, że autorzy oczekują podziwu dla ogromu wykonanej pracy, ale ja nie mogę przestać zadawać sobie w kółko jednego pytania: "Dlaczego oni tego nie zrobili w EA?".
Myślałem sobie, że to ja mam skrzywione spojrzenie na rzeczywistość. Na szczęście miałem okazję przeczytać ciekawy wpis Jarka Żelinskiego pod tytułem Sabotaż dokumentacyjny.
Autor przytacza w nim między innymi 10 tez dotyczących prowadzenia dokumentacji w postaci dokumentów MS Word i MS Excel. Pisze między innymi, że:
Używanie arkuszy kalkulacyjnych do zarządzania zależnościami pomiędzy wymaganiami przenosi całe ryzyko błędów na Ciebie, jest także bardzo pracochłonne.
Autor argumentuje, dlaczego dokumentacja powinna być prowadzona przy użyciu narzędzi CASE, takich jak Visual Paradigm Agilian, czy Enterprise Architect, zamiast w postaci dokumentów i arkuszy.

Jeśli nawet część członków zespołu projektowego wskazuje na chęć wykorzystania Enterprise Architecta zamiast produkowania wielu dokumentów i ich wersji, to rzadko dochodzi do skutku tego typu zmiana.

Dlaczego tak się dzieje?
Jak zwykle mamy do czynienia z wieloma czynnikami. Ja jednak niedawno natknąłem się na jeden zasadniczy problem.

Otóż, gdy zespół stoi przed decyzją: porzucić pracę w MS Office na rzecz Enterprise Architect, czy nie, wówczas taki zespół powinien umieć sformułować zestaw własnych wymagań odnośnie takiego narzędzia.
Czyli, zespół powinien być w stanie określić, co takie narzędzie powinno być w stanie zrobić, żeby oni mogli go używać. Dopiero wtedy będą w stanie wyobrazić sobie, że z niego korzystają i w jaki sposób.

Niestety osoby tworzące skomplikowane dokumenty i arkusze kalkulacyjne nie znają narzędzi CASE, bo gdyby znali, to by ich użyli. Samo zapoznanie się z dokumentacją programu nie jest również wystarczające. Poza tym, z EA można wyciągnąć o wiele więcej, niż to widać na pierwszy rzut oka poprzez umiejętną kastomizację. Do pomocy potrzebny jest ktoś, kto zna Enterprise Architecta, czy inne narzędzie CASE "od deski do deski".

Gdy członkowie zespołu stwierdzą, że potrzebują arkuszy kalkulacyjnych, bo to jest najwygodniejsza forma komunikacji z klientem, to w odpowiedzi mogą usłyszeć, że z EA można na żądanie wyeksportować dane do arkusza.
Gdy członkowie zespołu stwierdzą, że zatwierdzone ustalenia powinny mieć charakter oficjalnego dokumentu, który powinien być podpisany przez obie strony, to w odpowiedzi mogą usłyszeć, że z EA można generować tego typu dokumenty.
Gdy członkowie zespołu stwierdzą, że wprowadzanie danych do EA jest zbyt skomplikowane i mogą powstawać błędy, to w odpowiedzi mogą usłyszeć, że do wprowadzania specyficznych danych można opracować odpowiedni plugin. A do walidacji wykorzystać skrypty i zapytania SQL, które zwrócą listę elementów nie spełniających reguł projektowych.

W takiej sytuacji dyskusja przenosi się z reguły na inny poziom: Kierownik projektu musi oszacować, czy koszty opracowania szablonów raportów i kastomizacji narzędzia są akceptowalne. Oby jeszcze kierownik projektu zgodziłby się z tezą pochodzącą z wyżej cytowanego artykułu o tym, że:
Dokumenty i arkusze kalkulacyjne sprowadzają Cię do roli biurokraty. Praca z dokumentami tekstowymi i arkuszami to permanentne pisanie, wycinanie, kopiowanie, sprawdzanie spójności, stanowi to nawet 85% czasu całej analizy, pozostała wartościowa praca to 15%.

piątek, 21 czerwca 2013

Przykład zastosowania EA - projekt z Australii

Enterprise Architect jest narzędziem nie tylko do samego modelowania, ale daje możliwość pełnego wsparcia prowadzenia projektów informatycznych. Niedawno natknąłem się na ciekawą prezentację opisującą zastosowanie EA w Australii.
Jedno z tamtejszych ministerstw (Department of Education, Employment and Workplace Relations - DEEWR) zaprezentowało podczas jednego ze spotkań tamtejszej grupy Enterprise Architect User Groups sposób wykorzystania EA do zarządzania wymaganiami i tworzenia dokumentacji projektowej.
Prezentację można znaleźć pod adresem: www.catchsoftware.com/documents/using-enterprise-architect-software-development.pdf.

W dalszej części chciałbym zwrócić uwagę na najważniejsze aspekty tego case study.