o modelowaniu procesów i systemów 

Długość iteracji i jej wielkości pod względem zasobów musi być skorelowana z celami i pracą, które ma być wykonana. Moje wytyczne:

Wielkość zespołu – większe zespoły wprowadzają większe koszty stałe i tym samym prowadzą do dłuższej iteracji. Następujące wytyczne zapewniają przydatny punkt wyjścia:

• 2 – 15 osób: iteracja 2-4 tygodniowa
• 16 – 30 osób: iteracja 4-6 tygodniowa
• 31 – 50 osób: iteracja 6-8 tygodniowa.

Cele iteracji – niektóre cele wymagają więcej czasu na ukończenie niż inne

Wielkość kosztów stałych – im więcej sprawozdawczości oraz innych przeciążeń administracyjnych, które są nakładane na zespół, tym dłuższe będą musiały być iteracje

Podział zespołu – im bardziej podzielony zespół, tym trudniejsza komunikacja oraz tym więcej czasu zajmie uzgodnienie decyzji prowadzących do zwiększonego poziomu planowania i dokumentowania oraz dłuższych iteracji

Dostępność zasobów – Im mniej czasu, który członkowie zespołu  mają przeznaczyć na projekt, tym więcej czasu upłynie na iteracje

Formalność projektu – niektóre projekty mają bardziej surowe wymogi odnośnie przeglądów formalnych i dokumentacji projektowej, wymagając więcej czasu na te czynności

W zeszłym roku pisałem o integracji środowiska Rational z Visual Studio (patrz: IBM Rational Software Modeler i platforma .NET  i Transformacja modelu UML do kodu C# w środowisku IBM Rational Software Modeler ). Wspomniane posty dotyczyły Visual Studio 2005.

Obecnie Rational Modeling Extension for Microsoft .NET, który jest niezbędny do integracji wspomnianych powyżej środowisk wspiera framework .NET w wersji 3.0

Rational Modeling Extension wspiera WCF (Windows Communication Foundation)w zakresie modelowania i generowania kodu:

• modelowanie komponentów WCF
• inżynieria wprzód – transformacja z WCF do C#
• inżynieria wstecz – transformacja WCF z C#

Na koniec przypomnę, że transformacje mogą zachodzić w Rational Software Architect.

Po małej przygodzie związanej z narzędziami z rodziny Visual Paradigm postanowiłem przemigrować z moimi modelami do mojego ulubionego środowiska ? Enterprise Architect. Krótki opis takiej migracji przedstawiam poniżej.

przeczytaj pozostałą część »

W trakcie szkicowania procesów biznesowych należy zdefiniować wspólne słownictwo, przy użyciu najpopularniejszych terminów i wyrażeń w zakresie problemu. Następnie należy konsekwentnie wykorzystywać wspólne słownictwo we wszystkich tekstowych opisach biznesu. W ten sposób, utrzymują Państwo spójne opisy tekstowe i unika się nieporozumień wśród członków projektu dot. stosowania i znaczenia terminów. Słownictwo powinno mieć formę słownika.

Aby znaleźć wspólne terminy w zakresie problemu, należy uwzględnić terminy stosowane w trakcie rozmowy, o co chodzi w biznesie. Warto skupić się na terminach opisujących następujące koncepcje:

• Obiekty biznesowe reprezentujące koncepcje stosowane w codziennej pracy organizacji. W wielu przypadkach, już istnieje wykaz tego rodzaju koncepcji.
• Obiekty świata rzeczywistego, których istnienia przedsiębiorstwo musi być świadome. Te obiekty występują w naturalny sposób i obejmują takie rzeczy jak: samochód, psa, butelkę, samolot, pasażera, rezerwację, bądź fakturę.

Każdym termin jest na ogół opisywany jako rzeczownik wraz z definicją. Terminy powinny być podane w liczbie pojedynczej, "zamówienie" oraz "zadanie", a nie "zamówienia" czy "zadania".

I na koniec oczywiste i najważniejsze: wszystkie zainteresowane strony powinny porozumieć się co do zdefiniowania terminów.

Aby przewidzieć wymogi dla aplikacji biznesowej można rozważyć stworzenie następujących modeli:

• Schemat proceduralny interfejsu użytkownika. Dostarcza on przeglądu ekranów i raportów oraz to, jak w jaki sposób są one wzajemnie powiązane. Na chwilę obecną potrzebujesz jedynie głównych ekranów i raportów. 
• Diagram WPA (Wysokiego Poziomu Abstrakcji). Diagram procesu wysokiego poziomy, plus kilka diagramów dających podgląd kilku krytycznych procesów, są zazwyczaj potrzebne do zrozumienia przepływu biznesowego.
• Diagramy przypadków użycia. Zamiast diagramów procesu wysokiego poziomu (WPA) możesz zrobić diagram przypadków użycia wysokiego poziomu. Jest to kwestia tego preferencji, ja prawdopodobnie nie robiłbym tego diagramu, gdyż WPA jest dla mnie wystarczający.
• Diagram klas. Wskazuje na nim ważne dane, które są przetwarzane w organizacji.
• Diagram procesu. Czyli popularny diagram aktywności.  Warto na nim zamieścić obiekty.
• Definicje słownikowe. Być może będziesz chciał zacząć od zidentyfikowania kluczowych terminów biznesowych. Widziałem zbyt wiele zespołów uziemionych przez ?paraliż analizy? ponieważ próbowali zdefiniować dokładną terminologię przed przejściem do następnych etapów. Nie wpadnij w tę pułapkę.

Podane punkty stanowią składową wielu aplikacji biznesowych, ale w zależności od specyfiki biznesu i procesu niektóre z nich mogą być opcjonalne.

Kolejny raz okazało się, że duży potencjał jest ukryty także poza dużymi ośrodkami takimi jak Warszawa, Kraków czy Gdańsk. O Wrocławiu nie wspominając. Tym razem miałem okazję i przyjemność przekonać się o tym w jednej z podkarpackich miejscowości. W czasie dwóch dni, jakie tam spędziłem wspierając młody i ambitny zespół ludzi, przed którymi stanęło dość ciekawe zadanie (niestety z uwagi na ochronę interesów klienta nie mogę podać więcej szczegółów). Tempo prac było bardzo duże bo i temat nie był banalny. Wydaje się mi, że udało się uzyskać zamierzone cele co potwierdzają ankiety. Moje oceny ze szkolenia były w zakresie przygotowanie konsultanta i ważność poruszanych tematów: otrzymałem same bardzo dobre oceny a w zakresie sposób prezentacji tematu jedna ocena dobry a pozostałe bardzo dobry. 

Każdemu zalecam stosowanie przypadków użycia ? także a może przede wszystkim w projektach Agile.

Poniżej zamieszczam trzy podstawowe zalety, które myślę, że przekonają do używania przypadków użycia w projektach Agile

1. Dzięki przypadkom użycia zyskuje się kontekst

Nawet w projektach Agile przypadki użycia są mechanizmem umożliwiającym firmom osiąganie celów. Podejście, które wykorzystuje ustrukturyzowane wymagania dostarcza ten kontekst. Innymi słowy przypadki użycia pozwalają określić z jakimi systemami lub innymi zasobami będzie współpracował nasz system.

2. Dzięki przypadkom użycia zyskuje się informacje dot. zakresu projektu

Z politycznego punktu widzenia największym problemem z uruchomieniem projektu Agile w organizacjach typu waterfall jest niewłaściwe ustalenie oczekiwań wobec projektu w zakresie jego trwania i kosztów. Ustalenie oczekiwań i w ten sposób zabezpieczenie zarówno finansowania jak i wsparcia dla projektu może być ważniejsze niż samo wykonanie.

Ustalanie zakresu polega przede wszystkim na ustalaniu priorytetów celów osób zamawiających produkt oraz ustaleniu ram czasowych i harmonogramów dostarczania.

Kluczem jest tutaj dokonanie wpierw przeglądu zakresu projektu, a potem jego dokładne zrozumienie poprzez przeprowadzanie iteracji.

3. Dzięki przypadkom użycia zyskuje się naturalną dekompozycję

Właściwym podejściem do definiowania przypadków użycia dla tworzenia oprogramowania przy użyciu metody Agile to zacząć od definicji zakresu. Kiedy już zakres zostanie zdefiniowany należy zdefiniować nazwy przypadków użycia a następnie stopniowo nadawać priorytety i definiować bardziej szczegółowo przypadki użycia podczas gdy są one włączane do harmonogramu projektu. Dokonujesz także refaktoryzacji przypadków użycia, w miarę potrzeb konsolidując i definiując podrzędne przypadki użycia, oraz definiując, jeśli zachodzi taka potrzeba, rozszerzeń przypadków użycia.

W wielu firmach używane są równolegle maszyny z zainstalowanymi: Windowsem i Linuxem. Dość powszechny Enterprise Architect nie pozwala na wydajną pracę w środowisku Linux. W takiej sytuacji polecam produkty Visual Paradigm. Osobiście przetestowałem i uważam, że do większości projektów jest to narzędzie wystarczające i daleko bardziej użyteczne niż open source?owe programy takie jak Umbrello czy Dia.

Jeśli jednak można korzystać ze środowiska Windows to oczywiście polecam Enterprise Architecta