Praca grupowa w Enterprise Architect jest wydajniejsza po zastosowaniu centralnego serwera bazodanowego, na którym znajduje się repozytorium z modelami i dokumentacją projektową. Takie repozytorium może być postawione przykładowo na MySQL. Tu jednak rodzi się problem z polskimi znakami. Każdy polski znak zwłaszcza litra ?ł? są zamieniane na znaki zapytania.
Aby temu zapobiec wystarczy zmienić kodowanie tabel w bazie danych z latin1 na utf-8.
Kilka dni października spędziłem na Śląsku, gdzie miałem okazję wspierać Klienta w zakresie modelowania za pomocą języka UML w Enterprise Architect. Zdarzenie to jest o tyle ciekawe, że po za ?tradycyjnymi modelami? budowaliśmy modele systemów działających w oparciu o architekturę zorientowaną na usługi (SOA). Poniżej diagram-przykład (nie pochodzi z rzeczywistego projektu Klienta) przedstawiający fragment modelu.
Co więcej okazało się, że wersja Corporate Enterprise Architecta w zakresie modelownia SOA z powodzeniem, po małych zabiegach, dogania wersję Ultimate, której używam.
Na koniec chcę się pochwalić, że w przeprowadzonej anonimowej ankiecie, otrzymałem w zakresie kompetencji i umiejętności przekazania wiedzy dobre i bardzo dobre noty.
Pojęcie architektury korporacyjnej (ang. enterprise architecture ) zaczyna funkcjonować w świadomości co raz to większej liczby firm. Firmy te dostrzegły potrzebę opisania struktury i współpracy na poziomie komponentów. Tymi komponentami mogą być pracownicy firmy, działy firm, systemy informatyczne.
Koncepcją, która może pomóc zmienić postrzeganie informatyki w urzędzie ? z roli czysto technicznej, na mającą istotne znaczenie dla funkcjonowania jednostki ? jest architektura korporacyjna (enterprise architecture). W literaturze definiuje się ją jako opis struktury i funkcji komponentów jednostki (komponentami są np. ludzie, procesy biznesowe, struktury organizacyjne jak również systemy informatyczne), wzajemnych powiązań pomiędzy tymi komponentami oraz pryncypiów i wytycznych zarządzających ich tworzeniem i rozwojem w czasie. Czyli mówimy tutaj nie tylko o modelach, ale także o sposobie działania.
Dla mnie architektura korporacyjna jest modelem biznesowym na wysokim poziomie abstrakcji. Znamiennym jest iż budując architekturę korporacyjną można skorzystać z modele koncepcyjnych (EA Framework) takich jak:
Moją ulubioną ?strategią? budowania architektury korporacyjnej jest TOGAF (The Open Group Architecture Framework) nie tylko, ze najlepiej go z nam, ale także dlatego, że jest to podejście rekomendowane przez UE.
Warto wiedzieć, że istnieją na rynku narzędzia CASE, które wspierają inżynierów oprogramowania nie tylko w zarządzaniu wymaganiami, modelowaniu, projektowaniu systemów informatycznych, generowaniu kodu aplikacji, ale również w szacowaniu pracochłonności ich wytworzenia. Jednym z nich jest Enterprise Architect firmy Sparx System, który wspiera estymację pracochłonności wykonania sytemu informatycznego metodą punktów przypadków użycia.
W celu skorzystania z funkcjonalności związanej z szacowaniem pracochłonności, należy podczas tworzenia modelu systemu informatycznego konsekwentnie definiować istotne z punktu widzenia metody punktów przypadków użycia parametry wybranych komponentów, z których składa się model oraz zdefiniowania odpowiednich wartości parametrów dla tej metody.
Rysunek 1. Przeglądarka projektu narzędzia Enterprise Architect i widoczne elementy modelu systemu oceny pracowników: aktorzy systemu i przypadki użycia.
W tekście Szacowanie projektu w Enterprise Architect cz. 1 zdefiniowałem czynniki złożoności technicznej i środowiskowej. Teraz należy doprecyzować pozostałe parametry.
Po pierwsze możemy ustawić wartość dla parametru zwanego współczynnikiem produktywności PF (ang. Productivity Factor). Pamiętamy, współczynnik produktywności przekształca nam jeden punkt przypadku użycia na ilość godzin pracy człowieka, autor metody UCP proponował wartość tego parametru na poziomie 20. W narzędziu Enterprise Architect na zakładce Default Hour Rate okna Estimation factors (patrz rysunek 1) wartość tą wprowadza się do pola nazwanego Duration.
Metoda punktów przypadków użycia (ang. Use Case Points ) w skrócie UCP posiada podobny mechanizm do tego jaki zastosowano w metodzie punktów funkcyjnych (Metoda punktów funkcyjnych), jednak zrezygnowano z wykorzystania ekranów i architektury. Dlaczego pominięto ekrany i architekturę? Otóż wyobraźmy sobie sytuację, w której klient zadaje pytanie o czas realizacji projektu na etapie specyfikowania wymagań. Jak się okazuje w tej sytuacji metoda punktów funkcyjnych jest nieużyteczna, gdyż nie posiadamy jeszcze zdefiniowanej architektury, czy też propozycji ekranów. Należy więc zastanowić się czy wymagania systemu mogą być podstawą do estymacji pracochłonności realizacji systemu informatycznego. Twierdząco na tak postawione pytanie odpowiedział w 1993r. Gustaw Karner – twórca metody punktów przypadków użycia. Wymienił on architekturę i ekrany na specyfikację wymagań zapisaną w postaci specyfikacji przypadków użycia. Ponadto zasugerował, że należy zwrócić uwagę na tak zwane czynniki złożoności środowiska opisujące w dużej mierze organizację, która wytwarza oprogramowanie, czynniki złożoności technicznej opisujące własności produktu oraz przyszłych aktorów systemu.
Początki Use Case Points sięgają innej znanej metody służącej do szacowania rozmiaru oprogramowania, a mianowicie metody punktów funkcyjnych. Metoda ta zaproponowana przez Allana Albrechta (IBM) w 1979 bazowała na projektach ekranów oraz architekturze systemu. Była to próba przezwyciężenia problemów związanych z użyciem liczby linii kodu (która nie jest znana na etapie definicji wymagań a była podstawą do estymacji) jako miary wielkości oprogramowania i jednocześnie próba opracowania metody przewidzenia wysiłku związanego z produkcją oprogramowania. W metodzie tej występowało pięć głównych klas atrybutów produktywności, które charakteryzowały system:
Dla każdej kategorii zdefiniowane były trzy stopnie złożoności: prosty, średni i złożony. Z kolei z każdym stopniem złożoności były związane ustalone wartości wag.
Wszystkie prawa zastrzeżone 
modesto group All rights reserved
