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.

Organizacja pracy


W projekcie jest wykorzystywanych wiele narzędzi, które wymieniają dane z repozytorium EA. W projekt jest zaangażowanych ponad 200 osób z różnych działów, pracujących w wielu lokalizacjach. Trudno powiedzieć, czy wszyscy członkowie zespołu projektowego korzystają z EA, ale mimo wszystko ta liczba dobrze świadczy o skalowalności zastosowania EA.
Enterprise Architect jest spięty z Borland Caliber RM (do zarządzania wymaganiami), HP Quality Center (do zarządzania testami), AllFusion(R) Gen (narzędzie CASE), Visual Studio (programowanie) oraz z bazami danych SQL Server i DB2.

Zawartość repozytorium


W EA przechowywane są modele reprezentujące trzy perspektywy:
  • Business Model,
  • Logical Model,
  • Technical Model.
Taki podział jest dość naturalny i jest zgodny zarówno z metodykami modelowania, jak również ramami architektonicznymi. Można jedynie dyskutować o tym, czy prawidłowo przyporządkowano poszczególne elementy modelu. Na przykład, czy prawidłowym krokiem jest zakwalifikowanie przypadków użycia do modelu biznesowego. Skrót BDO oznacza business data object, czyli klasy z modelu encji biznesowych, które są wykorzystywane w przypadkach użycia zgodnie z regułami biznesowymi (Business Rules) poprzez odpowiednie formatki interfejsu użytkownika (User Interface) wyświetlane zgodnie z regułami (Display Rules). Projekt interfejsu użytkownika zawiera wygląd formatek (screen layout). Ponadto przebiegi przypadków użycia są wzbogacone o diagramy aktywności. 

Zarządzanie wymaganiami

Projekt był realizowany w modelu iteracyjnym, gdzie dla każdego release'u definiowane były odpowiednie artefakty. Artefakty te dostarczane były w postaci odpowiednich dokumentów (deliverables).

W projekcie ustalono klasyfikację wymagań dostosowaną do specyfiki przedsięwzięcia.
Zakres każdego z wydań (release) był określony w postaci zestawu wysokopoziomowych wymagań (High Level Requirements).
Do każdego wymagania wysokopoziomowego przyporządkowano zestaw wymagań szczegółowych (Master Functional Areas).


Na taki główny obszar funkcjonalny składają się następujące typy wymagań:

  • Actors - Aktorzy (wykorzystani w Modelu Użycia),
  • Use Cases - Przypadki użycia,
  • Diagrams (Optional) - Diagramy (np. diagramy aktywności, procesów biznesowych, diagramy stanów i inne),
  • Business Objects - model encji biznesowych i reguł biznesowych,
  • User Interface Objects - model interfejsu użytkownika,
  • Process Entities - przyznam, że nie wiem, czym to się różni od Business Objects,
  • Warehouse Reports - specyfikacje raportów.

Struktura pakietowa w kontekście organizacji projektu

Jak wspomniałem wyżej, produkty były dostarczane w postaci wielu tzw. release. W takim przypadku należy odpowiednio zaplanować strukturę pakietową repozytorium. Z jednej strony mamy potrzebę zorganizowania treści w taki sposób, aby opisać tworzone rozwiązanie. Wymusza to potrzebę chociażby trzymania w jednym miejscu wszystkich obszarów funkcjonalnych (Master Functional Area). Z drugiej strony wybrane artefakty z obszarów funkcjonalnych składają się na poszczególne wydania (release). Aby to osiągnąć należałoby wybrane artefakty z niektórych obszarów funkcjonalnych przechowywać w strukturze danego wydania.
Rozwiązanie tego problemu prezentuje poniższy slajd.

Otóż każde wydanie projektu opatrzone jest unikalnym identyfikatorem i stanowi oddzielną gałąź w modelu. Każda gałąź ma taką samą strukturę.
Zawartość stanowią tylko same diagramy (wyjątek stanowią elementy typu <<document>>, które przechowują treści potrzebne do umieszczenia w generowanych dokumentach, takich jak Requirements Specification, czy User Interface Specification).
Na diagramach umieszczonych w tych pakietach znajdują się elementy (wymagania opisane powyżej jako High Level Requirements oraz Master Functional Areas). W ten sposób z katalogów wymagań opisujących system wybierane są tylko te, które są implementowane w określonym wydaniu.
A zatem struktura pakietowa została tak opracowana, aby mogła się przełożyć na rozdziały i podrozdziały w generowanym dokumencie. Zaś zawartość rozdziału stanowią nazwy i opisy elementów umieszczonych na diagramach w określonych pakietach.
Dodatkowo, dzięki opcjom takim jak Include/Exlude Diagrams from RTF Documents (opcje diagramu) oraz Document / not document elements on diagrams (opcje szablonu) można sterować zakresem treści dokumentu.

Pluginy

Sparx Enterprise Architect jest narzędziem, które posiada duże możliwości konfiguracji i "kastomizacji". Jednym ze sposobów na takie dopasowanie jest zastosowanie pluginów.

W tym projekcie wytworzono i zastosowano wiele dodatków, których nie ma w standardowej instalacji EA.

  • CaliberRM Load - służący do importu i aktualizacji wymagań wprowadzonych w Caliber RM.
  • Requirements Validator - przeprowadzający walidację wymagań zgodnie z zestawem projektowych reguł.
  • Structured Scenario Creator - dzięki niemu możliwe w bardziej wygodny sposób możliwe jest stworzenie przebiegów przypadków użycia z plików tekstowych.
  • UI MDG - MDG Technology rozszerzający możliwości standardowego UI MDG Technology zgodnie z wymaganiami projektowymi.
  • Project Tracker Linker - narzędzie, które tworzy automatycznie relacje nowych elementów do wydania projektu.
  • Grid Editor - umożliwia tworzenie tabel w EA (zapewne w projekcie interfejsu użytkownika).
  • Push to Quality Center - eksport wymagań do Quality Center (na rynku istnieje tego typu konektor, w tym wypadku nie skorzystano z niego).
  • Generate Business Reports - mechanizmy raportowania, korzystające między innymi z zapytań SQL wybierających elementy do raportów spełniające określone kryteria.
  • Tagged Value Editor - dodatek umożliwiający edytowanie Tagged Values jednocześnie dla wielu elementów.
  • Package Copier - mechanizm do kopiowania pakietów. W EA można łatwo skopiować wybraną gałąź, jednak ten dodatek odpowiednio traktuje wartości Tagged Values, aby ograniczyć ryzyko wystąpienia błędów "Kopiego Pejsta".
  • Project Setup - mechanizm do struktury pakietowej nowego wydania (release) projektu.
  • Manage User Groups - ułatwienie dla administratora modelu dotyczące zarządzania uprawnieniami użytkowników
  • ESG Custom Search - ułatwienie w korzystaniu z mechanizmu audytu EA. Służy wyszukaniu poprzednich wartości atrybutów elementów, które zostały zmienione przez użytkowników.
  • ESG Floating Toolbar - umożliwiający łatwy dostęp do wyżej wymienionych dodatków.

Reguły walidacji wymagań

Zastosowane w tym projekcie reguły walidacji wymagań są godne uwagi, gdyż są potencjalnie re-używalne.
  • Check for duplicates - sprawdza unikalność nazw elementów.
  • Check missing suffixes - sprawdza, czy element posiada identyfikator w określonym formacie.
  • Check for unnambered display rules - sprawdza, czy reguły są ponumerowane.
  • Check for unnambered business/process rules - sprawdza, czy reguły są ponumerowane.
  • Check names and stereotypes - sprawdza poprawność nazw i zastosowanych stereotypów.
  • Check use cases - sprawdza przypadki użycia, np. czy posiada scenariusze.
  • Check package contents - sprawdza poprawność zawartości pakietu, np. czy występują tylko elementy określonego typu.
Nazwy elementów, które nie są zgodne z regułami prezentowane są w postaci listy. Bezpośrednio z tego miejsca można przejść do edycji takiego elementu w celu np. dodania identyfikatora.

Podsumowanie

Opisany tu projekt jest unikalny, ale tylko ze względu na to, że zdecydowano się publikację w internecie wielu szczegółów od kuchni. Wiem, że istnieje wiele projektów realizowanych w różnych organizacjach, również w Polsce, które wykorzystują wiele cennych dodatków. Wymiana doświadczeń i pomysłów na kastomizację EA mogłaby być przydatna dla innych. 
Mam nadzieję, że ten artykuł będzie inspiracją do opracowania własnych autorskich rozwiązań na wzór tego australijskiego projektu.

Brak komentarzy:

Prześlij komentarz