o modelowaniu procesów i systemów 

Mit: Zwinne zespoły nie produkują dokumentacji

Fakt: Dobry zwinny zespół produkuje taką ilość dokumentacji, która jest niezbędna do wspierania, utrzymania i rozwoju oprogramowania. Zwinne zespoły produkują przykładowo dokumentacje wyjaśniającą metafory i pojęcia słownikowe używane w trakcie projektu oraz modele w ograniczonym zakresie.

Mit: Zwinne zespoły nie potrzebują inwestować w wymagania

Fakt: Zwinne zespoły maniakalnie koncentrują się na spotkaniach z klientem związanych z określeniem wymagań. Nie potrzebują zapisywać wszystkiego na przód. Jeśli nie ma na miejscu klienta, zespoły używają bardziej tradycyjnych technik, takich jak przypadki użycia.

Mit: Zwinne zespoły nie tworzą modeli ani architektury systemu

Fakt: Zespoły tworzą wiele modeli (zazwyczaj ręcznie na białych kartach) w celu ułatwienia komunikacji. Badania wykazały, że większość zwinnych zespołów wykonuje modele by pomóc zrozumieć jak oni budują i konstruują system. Brak projektu całości na początku przedsięwzięcia nie oznacza braku projektowania. Najczęściej obok przypadków użycia powstają diagramy klas i aktywności.

Mit: Zwinne zespoły nie maja żadnych planów

Fakt: Zwinne zespołu projektują by nie było jak z Alicją w Kainie Czarów Lewisa Carrolla:

? Czy nie mógłby pan mnie poinformować, którędy powinnam pójść? ? mówiła dalej.
? To zależy w dużej mierze od tego, dokąd pragnęłabyś zajść ? odparł Kot ? Dziwak.
? Właściwie wszystko mi jedno.
? W takim razie również wszystko jedno, którędy pójdziesz.
? Chciałabym tylko dostać się dokądś ? dodała Alicja w formie wyjaśnienia.
? Ach, na pewno tam się dostaniesz, jeśli tylko będziesz szła dość długo.

Mit: Zwinne zespoły szybko przestają być kontrolowane, robią cokolwiek jak lubią i kiedy chcą.

Fakt: Zespół jest właściwie bardzo zdyscyplinowany i bardzo skupiony.Zadania zawsze są wykonywane w ustalonym porządku, z priorytetem określonym przez klienta  przy pomocy przypadków użycia. Mierzenie osiągnięć celów nakreślonych przez przypadki użycia służy do jasnego oszacowania postępu i wydajności.

Mit: Jeśli jesteś zwinny, to nie potrzebujesz żadnych menadżerów

Fakt: Potrzebny jest menadżer by utworzyć dobre środowisko pracy i zaplanować iteracje w oparciu o przypadki użycia. Zwinny zespół dostarcza mierzalnych celów, określonych przez przypadki użycia. Menadżer za pomocą przypadków użycia szacuje ryzyko co umożliwia mu tym samym bardziej efektywne zarządzanie.

Kilka dni temu, w tekście Model Driven Architecture modele PIM a PSM, napisałem dwa słowa o modelach PSM i PIM w architekturze MDA. Teraz chciałbym pokazać jak taką transformację zrobić w Enterprise Architect.

Zrobię to na przykładzie wzorca projektowego Adapter, którego celem jest którego celem jest umożliwienie współpracy dwóm klasom o niekompatybilnych interfejsach.

Zaprezentowany model jest odseparowany od swojej implementacji. Aby wykonać model PSM należy

przeczytaj pozostałą część »

Zazwyczaj sporo mówi się na temat tego, że model musi być odseparowany od swojej implementacji. Oznacza to, że w pierwszej fazie modelowania nie należy zastanawiać się nad tym, jak będzie wyglądała implementacja. Dopiero po zatwierdzeniu projektu można dostosować model już do środowiska implementacji. Sprzyja to reużyciu całych fragmentów projektów. Stosując taka zasadę idealnie działa się zgodnie z MDA czyli Model Driven Architecture. Model-Driven Architecture ? to sposób budowania oprogramowania w oparciu o modele i ich transformacje.

W MDA wyróżnia się 4 poziomy (modele):

• Computation Independent Model (CIM) (albo: domain model; vocabulary) ? model biznesowy, nie precyzujący zakresu odpowiedzialności oprogramowania
• Platform Independent Model (PIM) ? abstrakcyjna specyfikacja systemu
• Platform Specific Model (PSM) ? model odwzorowany na konkretne rozwiązania wybranej platformy
• Implementation Model ? proste przełożenie decyzji z modelu platformowego

Patrząc na ten podział modelem odseparowanym od implementacji będzie model PIM, którego ideą jest zaprezentowanie rozwiązania zgodnego z wymaganiami.

PSM natomiast stanowi  odwzorowanie abstrakcji zamodelowanych w PIM na konkretne rozwiązania charakterystyczne dla danej platformy lub języka programowania. Mówiąc inaczej PSM jest uszczegółowioną formą PIM lub jego konkretnym wystąpieniem.

Narzędzia CASE w różnym stopniu wspierają takie podejście. Czasem jest to wygenerowanie modelu implementacji jak ma to miejsce w narzędziach z rodziny Rational (nawiasem mówiąc w produktach Rational mówi się o Model Driven Development (MDD), który jest rozszerzoną wersją MDA) lub modelu platformy jak ma to miejsce w Enterprise Architect.

Przykład transformacji w EnterpriseArchitect można znaleźć w poście Transformacja PIM-PSM w Enterprise Architect

Na koniec należy wspomnieć, że dwukierunkowość transformacji PIM ?> PSM i PSM ?>PIM nie jest zawsze możliwa.

Konferencja Modelowanie Procesów Biznesowych 2009 to kolejna a już VII edycja seminarium poświęconemu modelowaniu i doskonaleniu procesów biznesowych organizowana przez Software-Konferencje. Po raz drugi miałem przyjemność wziąć udział jako prelegent w tym przedsięwzięciu. Jako jeden z nielicznych reprezentowałem nurt modelowania procesów biznesowych w UML a moja prezentacja na temat zwinnego modelowanie procesów biznesowych w języku UML spotkała się z dobrym przyjęciem o czym świadczą ankiety, w których otrzymałem 94% opinii dobrych i bardzo dobrych.

Dla siebie i dla tych co czasem tak jak ja chcą mieć dostęp do metodyk on-line zamieszczam linki pod którymi są one dostępne.

• Scrum
• OpenUP
• Extreme Programming

Miłego korzystania

Niestety nie działają one pod operą

Szacowanie projektu oraz jego złożoności jest trudne. Istnieją metody, które wspomagają ten proces. Jedną z nich jest metoda  use case points. O samej metodzie nie będę pisał bo wiele jest o niej informacji w Internecie. Natomiast warto wiedzieć, że Enterprise Architect wspomaga to szacowanie. Wystarczy przy każdym przypadku użycia określić parametr Complexity (patrz własności PU) i gotowe. Potem można przystąpić do szacowania?

przeczytaj pozostałą część »

W dniach 7-8  maja prowadziłem w Warszawie szkolenie z projektowania systemów informatycznych. Nikt z uczestników szkolenia nie miał wątpliwości, że modele w UML są przydatne a jednocześnie metodyki z nurtu Agile odrzucają modelowanie. Oczekiwania wobec szkolenia krążyły wobec tematów co i jak dokumentować w UML? Jak obszerną dokumentację wykonywać? Jak połączyć modelowanie w UML z zwinnymi (ang. Agile) metodykami takimi jak XP czy Scrum.  W trakcie szkolenia zaprezentowałem istotę metodyk zwinnych i ciężkich oraz zaprezentowałem klucz -  łącznik pozwalający na połączenie modeli wyrażonych w UML z zwinnym podejściem. Wskazałem także jak zaprezentowane rozwiązanie może dodatkowo pozwolić na lepsze wymiarowanie projektu np.: w zakresie ustalenia zakresu iteracji ? sprintu jak to mówią wyznawcy Scrum.

Wydaje mi się, że szkolenie spełniło oczekiwania jego uczestników o czym świadczą ankiety: w zakresie sposobu prezentacji tematu, przydatności szkolenia  i mojego przygotowania otrzymałem same dobre i bardzo dobre oceny. Dziękuję szczególnie za jedną opinię w punkcie: ?Co się Państwu najbardziej podobało w niniejszych warsztatach??, która brzmi ?Kompetencja prowadzącego i sposób prowadzenia szkolenia?.

Architektura zorientowana na usługi to naturalny krok ewolucyjny od podejść zorientowanych obiektowo (OO), proceduralnych oraz dano-centrycznych stosowanych we wdrażaniu rozwiązań.

Fundamentalnymi zasadami rządzącymi SOA są:

• Wiadomości wymieniane pomiędzy uczestniczącymi systemami muszą być opisowe a nie instruktażowe, ponieważ system informatyczny świadczący usługę odpowiedzialny jest za wszelkie problemy. Komunikaty opisowe podają informacje o usłudze oraz o powiązanych z nią danych wejściowych i wyjściowych. Usługodawcy odpowiedzialni są za wskazówki; stąd też potrzeba na komunikaty instruktażowe nie istnieje.
• Słownik oraz struktura komunikatów muszą być zrozumiałe przez wszystkie strony. To powszechne zrozumienie przez wszystkie strony wymaga ograniczenia słownictwa oraz struktury komunikatów, ale jest koniecznością dla skutecznego komunikowania.
• Struktura komunikatu powinna być rozszerzalna.

przeczytaj pozostałą część »

Pod hasłem WMB gromadzić będę zestawy wskazówek pozwalające na dokumentację procesów biznesowych. Celem WMB nie jest tylko ułatwienie budowy modeli biznesowych, ale także rozszerzenie notacji UML o stereotypy, które pozwalają na budowę bardziej jednoznacznych modeli.

WMB to:

• aktywności ? jako wskazówki do działania ? zestawy czynności warunkujące osiągnięcie poprawnego modelu
• role  – jako zakres kompetencji dla osób wykonujących model biznesowy,
• notacja UML ? jako rozszerzenie notacji UML o stereotypy, które pozwalają na budowę bardziej jednoznacznych modeli,
• rozszerzenia narzędzi CASE -  jako profile pozwalające na budowę modeli biznesowych z wykorzystaniem notacji WMB

przeczytaj pozostałą część »

Enterprise Architect, moim zdaniem, nie jest najszczęśliwszym narzędziem do zarządzania wymaganiami. Nie jest też beznadziejny.

W projektach dla mnie ważne jest to jak wymagania są mapowane na konkretne przypadki użycia (PU). Pozwala to stwierdzić, które PU są bardziej złożone, wymagają większej uwagi i są ważniejsze dla klienta. Aby to stwierdzić trzeba zmapować PU z konkretnymi wymaganiami. W tym celu dodaję wymagania na diagram i łączę asocjacja z PU a jeśli diagram jest nieczytelny to związki dodaje w macierzy. Wygenerowanie macierzy?

przeczytaj pozostałą część »