o modelowaniu procesów i systemów 

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?.

Na jednym ze spotkań z klientem otrzymałem pytanie: Czy przypadki użycia są jedyną formą specyfikacji systemu? Moja odpowiedź była jasna: NIE. Przypadki użycia są niewątpliwie pożyteczne dla specyfikowania systemów, ale nie pozwalają w pełni opisać wymagań. Przypadki użycia stanowią swoiste agregaty dla wymagań, pozwalają dokonać pewnej dekompozycji wymagań na poszczególne funkcje systemu. Niestety ich rola jest ograniczona wskazania roli jakie podejmą aktorzy w systemie a przecież bardzo często  wymagania pochodzą od ludzi, którzy nie zbliżą się do granic systemu. Co więcej wymagania poza funkcjonalnością obejmują aspekty techniczne (np.: interfejsy). Z moich doświadczeń wynika, że często aby w pełni wyspecyfikować funkcjonalność systemu trzeba poznać proces biznesowy czyli zbudować model biznesowych przypadków użycia za pomocą techniki odmiennej, ale zgodnej z modelem przypadków użycia. Oznacza to, że poza modelem przypadków użycia powstają inne artefakty (dokumenty) przede wszystkim takie jak wspomniany model lub inna dokumentacja procesów biznesowych oraz obligatoryjnie specyfikacja wymagań funkcjonalnych i niefunkcjonalnych.

Nigdy się nie zastanawiałem nad etyką w procesie wytwórczym oprogramowania aż do dziś kiedy natrafiłem na artykuł, którego autorami są Maria Ganzha i Stanisław Szejko. Tekst jest dość ciekawy gdyż porusza nowe obszary procesu wytwórczego oprogramowania, które wykraczają poza tradycyjnie stosowaną podejście stosowane w inżynierii  oprogramowania.

Zainteresowanych odsyłam do artykułu: http://www.e-informatyka.pl/article/show/493

Czasami dostaję pytanie: Ile kosztuje modelowanie w UML? Moja odpowiedź brzmi: Dużo, ale koszty się zwracają z zyskiem. Skąd ten zysk skoro modelowanie w UML to czas ludzi, którzy zamiast pisać kod siedzą i modelują a od tego kodu nie przybywa. Moi rozmówcy mają obawy, że to korzystanie z UML wydłuża proces budowy oprogramowania. Pozornie tak i pewnie, można zacząć od razu budować kod (wiele firm działa tak z powodzeniem do dziś), tylko dlaczego jak budujemy dom to najpierw go planujemy? Przecież można włączyć betoniarkę, kupić cegły i do dzieła. Ale my najpierw planujemy dom, może po to by się nie zawalił, może po to by spełniał nasze oczekiwania. Potem jak zatwierdzimy plany to w trakcie budowy są oczywiście pewne zmiany (przestawiamy ścianki, zmieniamy wysokość okna itd. itp.), ale nikt nie burzy wszystkiego i nie zaczyna od nowa. W pisaniu kodu często bywa tak, że albo oddajemy źle napisany komponent (o ile w miarę działa), albo piszemy od nowa (by w miarę działał). Oszczędność o której pisałem na początku to czas jaki tracimy na poprawianie (lub pisanie od nowa) źle funkcjonujących komponentów.  Dziwne jest czasem dla mnie to, że przy budowie domu zatrudnia się obligatoryjnie architekta który go planuje (lub kupuje gotowy projet), a przy budowie oprogramowania, które jest dużo bardziej skomplikowane oszczędza się na projekcie.  Na szczęście moi klienci już dojrzeli korzyści z modelowania i dzięki temu mam co robić bo modelowanie w UML nie musi być ani czasochłonne, ani trudne i kosztowne. 

Panuje powszechna opinia, że modele wyrażone w języku UML są niezrozumiałe i nie wiadomo jak go stosować. Problem czytelności diagramów jest tym bardziej istotny, gdy dokumentacji (jakże pieczołowicie) wykonanej w UML nie umie przeczytać Klient. Tak to problem, z którym czasem się spotykam. Wtedy zanim Klient zobaczy wartość modelowania  pozwalam nazywać poszczególne elementy notacji tak jak je nazwał klient przy zachowaniu odpowiedniego znaczenia tego elementu. I tak przykładowo aktor na początku nazywany jest ludzikiem z czasem jest nazywany systemem lub użytkownikiem by potem gdy klient wdraża już UML?a na stałe nazwać go poprawnie aktorem. Oczywiście pilnuję by znaczenie aktora na diagramach przypadków użycia nie zostało zniekształcone.  Ta metoda sprawdziła mi sie w u większości klientów, którzy nie używali UML. Niestety nie u wszystkich

Na koniec została sprawa jak stosować UML i kiedy? Nie ma jednoznacznej odpowiedzi na ten temat, gdyż użycie języka UML zależy od specyfiki realizowanego projektu, etapu na którym się ten projekt znajduje, czy znajomości języka UML przez różne osoby zaangażowane w dany projekt. Z tego też powodu potrzebne jest pewne doświadczenie. Ale jak zdobyć to doświadczenie, gdy książki mówią o notacji UML a nie o tym jak go stosować a przykłady z Internetu też są banalne? Na początek proponuję konsultacje u doświadczonej osoby, która ma za sobą kilka projektów z wykorzystaniem UML. Byłoby rewelacyjnie gdyby taka osoba nadzorowała nasze prace – była takim Aniołem Stróżem UML. Myślę, że takie spotkania dadzą więcej niż nawet kilkudniowe szkolenie.

Zawsze trzymam kciuki za firmę, która w pewnym momencie swojego rozwoju dostrzega fakt, że złożoność systemów bądź procesów biznesowych jest tak wielka, że trzeba sięgnąć po zestaw innych praktyk. Lubię, gdy zgłaszają się do mnie i mogę zaproponować im jako lekarstwo podejście obiektowe. Bardzo często te firmy chcą zobaczyć czy UML jest zgodny z kulturą organizacji lub sprawdzić czy jest w nim coś dla nich. Tak było i tym razem w dwóch miejscach, które łączy jedno – obie firmy działają w sektorze bankowym.  Pierwszą z nich jest wytwórca oprogramowania dla banków. Na dwudniowych warsztatach modelowany był fragment systemu bankowego – bardzo mały fragment, na których zaprezentowałem w Enterprise Architect, podstawowe techniki modelowania poczynając od diagramów przypadków użycia po przez diagram klas kończąc na modelach zachowania systemu. Po pierwszych opiniach jakie usłyszałem po zakończeniu warsztatów myślę, że firma ta w perspektywie niezadługiego czasu skorzysta z pewnych modeli.  

Drugą firmą był jeden z dużych banków. W banku największy nacisk był położony na dokumentowanie procesów biznesowych za pomocą UML oraz metodykę budowania modeli. W pięciodniowych warsztatach, których celem było sprawdzenie przydatności języka UML do modelowania procesów biznesowych, był wykorzystany IBM Rational Software Modeler oraz IBM RequisitePro oraz autorski proces budowania modeli biznesowych.  Nie mam jeszcze oficjalnej opinii z banku na temat mojej i mojego kolegi pracy w czasie tych 5 dni, ale za dobrą monetę biorę słowa jednego z uczestników warsztatów – przedstawiciela działu IT – „Jeszcze nigdy biznes nie dał nam tak dobrze opisanego procesu…”

Czy warto znać UML? Myślę, że tak tym bardziej, że zdaniem Instytutu Gartner’a w 2006 roku z języka UML korzystało ponad 10 milionów specjalistów z branży IT. Gartner szacuje, że w 2008 r. ok. 70% organizacji związanych z wytwarzaniem oprogramowania korzysta z UML. Więcej na temat przyszłości modelowania można przeczytać w artykule Andrew Watson’a (http://www.uml.org/Visual_Modeling.pdf). Polecam ten tekst.

Niniejszy artykuł napisałem kilka lat temu i w oryginale został wydany w Software Developer’s Journal Extra nr 18, (IBM Software Development Platform  Projektowanie SI, str.  34-38,   ISSN:1734-7661) w 2005 roku. Tekst publikuję, gdyż tego wydania nie ma już na rynku a opisana sposób postępowania jest nadal w miarę aktualny.

W artykule zaprezentowano zestaw kolejnych kroków, które prowadzą od projektu wyrażonego w języku UML do implementacji w języku JAVA aplikacji – książki adresowej, która dane kontaktowe przechowuje w pliku XML. Do budowy oprogramowania wykorzystano IBM Rational Software Architect. W kolejno wykonywanych krokach najpierw zostanie zbudowany model w języku UML 2.0 a następnie na podstawie modelu zostanie zaprezentowana implementacja w języku JAVA fragmentu aplikacji. Tekst z racji swojej obszerności podzieliłem na 3 części:

• Projekt i implementacja aplikacji JAVA w środowisku IBM Rational Software Architect – model przypadków użycia

• Projekt i implementacja aplikacji JAVA w środowisku IBM Rational Software Architect – model analizy

• Projekt i implementacja aplikacji JAVA w środowisku IBM Rational Software Architect – implementacja

miłej lektury

Pierwszym krokiem po włączeniu Rational Software Architect’a jest wybór miejsca, w którym znajdować się będzie nasz projekt (ang. workspace). W tym przypadku zamiast domyślnego katalogu umieścimy nasze rozwiązanie w katalogu Projekt

przeczytaj pozostałą część »

Po zdefiniowaniu wymagań (Projekt i implementacja aplikacji JAVA w środowisku IBM Rational Software Architect – model przypadków użycia ) na system przychodzi kolej na modele, które opiszą nam z jakich elementów jest zbudowany system i jak te elementy ze sobą współpracują. Modele te buduje się w modelu analizy (ang. Analysis Model), który należy dodać do naszego projektu w sposób podobny jak to miało miejsce z modelem przypadków użycia z tym, że wybierany jest szablon Analysis Model. W tym miejscu należy wspomnieć, że model analityczny jest opcjonalnym elementem projektu. W przypadku prostych modeli można od razu budować model projektu. W naszym przypadku dla celów edukacyjnych zbudujemy ten model by następnie uszczegółowić go w modelu projektu.

W zdefiniowanym modelu analitycznym w katalogu Analysis Building Block należy utworzyć realizacje przypadków użycia. Realizacje to są elementy współpracy (ang. Collaboration), które powinny nosić nazwę przypadku użycia, którego są realizacją. Elementy współpracy jest to jeden z elementów języka UML 2.0 i dodaje się go poprzez menu kontekstowe, które jest uruchamiane prawym klawiszem myszy.

przeczytaj pozostałą część »

Po zbudowaniu modelu analitycznego (Projekt i implementacja aplikacji JAVA w środowisku IBM Rational Software Architect – model analizy), który powstał na podstawie modelu przypadków użycia (Projekt i implementacja aplikacji JAVA w środowisku IBM Rational Software Architect – model przypadków użycia) można przejść do budowy modelu projektowego, który w naszym przypadku, będzie podstawa do wygenerowania szkieletu kodu aplikacji. Pierwszym krokiem tego etapu będzie dodanie do naszego projektu pustego szablonu projektowego, który będzie podstawą do zbudowania modelu projektu. Model ten dodaje się w sposób analogiczny jak poprzednie modele.

przeczytaj pozostałą część »

Technika Mind Mapping (MM) zwana też techniką map pamięci powstała w latach sześćdziesiątych. Za jej twórcę uważany jest angielski naukowiec Tony Buzan, który intensywnie pracował nad poznaniem mechanizmów pracy ludzkiego umysłu i technikami zapamiętywania i podnoszenia kreatywności jednostek i zespołów. MM stara się wykorzystać wyniki tych badań tak, aby poprawić procesy uczenia się i zapamiętywania oraz komunikację międzyludzką. Jak wykazały badania MM stymuluje też kreatywność jednostki i zespołu oraz przyspiesza wypracowywanie przez zespoły wspólnych idei.

Technika MM polega na zapisywaniu informacji przy jednoczesnym posługiwaniu się obrazem i tekstem. Kładzie ona zasadniczy nacisk na formę obrazowania myśli.

Powodzenie każdego projektu, w tym projektu informatycznego, zależy w znacznej mierze od umiejętności wykorzystania i zaangażowania potencjału umysłowego wszystkich udziałowców projektu. W szczególności o sukcesie decyduje umiejętność prawidłowego określenia założeń i opracowanie planów zarządzania projektem, jakością, ryzykiem i innych niezbędnych w czasie prowadzenia projektu. Drugim niezmiernie ważnym elementem jest prawidłowa i efektywna komunikacja między udziałowcami projektu. Technika map pamięci (MM) może w znacznym stopniu wspomóc działania zespołu projektowego, a w szczególności kierownika projektu, w zakresie pobudzenia kreatywności całego zespołu i poszczególnych jednostek. Może też być dobrym narzędziem wspomagającym komunikację, w szczególności w fazie definiowania celów projektu i jego planów. 

przeczytaj pozostałą część »