o modelowaniu procesów i systemów 

Kilka dni temu w tekście: Zwinne modelowanie w Visual Studio 2010 pisałem o możliwości modelowanie za pomocą UML w VS 2010. Teraz czas na drugą z mojego punktu widzenia ważna zmianę. Otóż w MSF for Agile Software Development v5.0 jaki towarzyszy VS 2010 uwzględniono zwinne modele a proces wytwórczy kodu oparto o SCRUM. Więcej informacji pod adresem:

http://msdn.microsoft.com/en-us/library/dd380647.aspx

Szczególnie polecam rozdział 4.4 Use Models in Agile Development.

Jest rewolucja. I to nie mała. Otóż firma Microsoft w ramach Visual Studio z premedytacją omijała aspekt wizualnego projektowania sytemu przy użyciu UML. Aż do teraz.

W nowej wersji VS 2010 jest VS2010 Visualization and Modeling Feature Pack (http://msdn.microsoft.com/en-gb/vstudio/ff655021.aspx), dzięki któremu można wytwarzać modele na różnym poziomie abstrakcji i w konsekwencji synchronizować je z kodem aplikacji.

Przełom jest tym większy, że Microsoft proponuje tylko te techniki modelowania, które są uważane za składniki zwinnego modelowania (ang. Agile Modeling). 

Iteracyjny model wytwarzania oprogramowania by był bardziej skuteczny wymaga kilku zabiegów. Chodzi oto by w ujęciu agile być rozważnym i skutecznym. Stosuję je podczas zwinnego modelowania. Oto kilka z nich:

1. Krócej znaczy lepiej. Iteracja nie powinna być dłuższa niż 4 tygodnie, w przeciwnym wypadku możesz wpaść w styl tworzenia oprogramowania mini-waterfall. Osobiście preferuję jedno lub dwutygodniowe iteracje. Dzięki temu tempo tworzenia oprogramowania jest stałe, jako że regularne dostarczasz nowe funkcjonalności.
2. Zacznij od niekomfortowego okresu czasu. Kiedy zmieniasz tradycyjną organizację na ewolucyjne (iteracyjne i przyrostowe) podejście do tworzenia oprogramowania spróbuj określić okres czasu, który będzie odpowiedni (np. 8 tygodni) i odejmij tydzień lub dwa (np. zacznij od 6-tygodniowej iteracji) aby zmusić ich do zmniejszenia biurokracji. Zrób kilka takich iteracji, a następnie skracaj długość iteracji dopóki nie dojdziesz do sensownego okresu czasu (np. mniej niż 4 tygodnie).
3. Zignoruj kalendarz. Jeśli Twoja iteracja została zaplanowana na tydzień, zrób ją od środy do wtorku. Iteracje trwające od poniedziałku do piątku zazwyczaj cierpią przez to, że w piątek skupienie i energia dramatycznie zmniejszają się, ponieważ jest to koniec iteracji i koniec tygodnia. Ten zbieg okoliczności zmniejsza produktywność.
4. Stwórz coś użytecznego. Zasadniczo iteracja powinna być na tyle długa, abyś był w stanie zrobić coś pożytecznego w jej trakcie. Niektóre zespoły robią jednodniowe iteracje.
5. Przeprowadź tyle iteracji, ile potrzebujesz. Wymagania zmieniają się, co oznacza, że czas potrzebny na wdrożenie systemu też musi się zmienić, aby to odzwierciedlić.
6. Cały czas możesz mieć stałą datę ukończenia oprogramowania. Jeśli potrzebujesz mieć stałą datę ukończenia oprogramowania, to po prostu ustal tą datę i do tego czasu ukończ tworzenie oprogramowania. Aż do czasu, w którym musisz oddać oprogramowanie, prowadź iteracje dotyczące tworzenia oprogramowania. Jeśli stale wdrażasz wymagania o najwyższym priorytecie,  a wtedy to, co do dostarczysz, będzie miało najwyższą możliwą wartość.

Specyfikacja wymagań na system to trudny moment przede wszystkim dla osób, które muszą je wyspecyfikować. Nie zawsze wiadomo w jaki sposób narzędzia informatyki będą mogły pomóc. Często mówimy tylko o funkcjonalności i o tym w jaki sposób system ma realizować procesy biznesowe.  Powstaje pytanie jak skutecznie uzupełnić wymagania także o takie szczegóły jak rozmieszczenie przycisków, format raportu, pola edycji systemu. Po prostu ludziom trudno jest stworzyć krok po kroku opis systemu, którego nigdy nie widzieli. Z tego też powodu jestem zwolennikiem by przypadki użycia wraz z diagramem klas i aktywności opowiadały o systemie skupiając się przede wszystkim  na jego funkcjach.

Do uszczegółowienia wielu  aspektów system, które do specyfikacji są żmudne i czasochłonne polecam prototyp.

Wytworzenie wczesnego prototypu opartego o przypadki użycia może powołać system do życia, co sprawia, że znacznie łatwiej jest gromadzić informacje zwrotne wymagane do ukończenia specyfikacji przypadków użycia. Takie podejście powoduje iż dokumentacja w UML nie jest zbyt złożona co wpisuje się nurt zwinnego modelowania.

Z racji tego, że publikacja odnośnie zwinnego podejścia w zakresie modelowania procesów biznesowych (WMB) ?pisałem o tym kilka dni temu w tekście pt ?Krajowa Konferencja Inżynierii Oprogramowania?- ukazała się w limitowanej edycji 150 egzemplarzy pozwalam sobie na publikację skanu tego tekstu.

Kilka tygodniu temu (http://www.wolski.waw.pl/2009/07/kkio-2009/) zapowiedziałem swój udział na Krajowej Inżynierii Oprogramowania. Tak tez się stało. 15 września w trakcie sesji pt: ?Modelowanie systemów? miałem okazję zaprezentować zarys metodyki WMB ( http://www.wolski.waw.pl/wmb/).

Moje wystąpienie na temat ?Zwinnego modelowania wymagań biznesowych w wytwarzaniu oprogramowania? spotkało się się z życzliwym przyjęciem uczestników  XI Krajowej Konferencji Inżynierii Oprogramowania, które zaowocowało żywą dyskusją.

Na koniec dodam, że moje wystąpienie było afiliowane i wykonane na rzecz firmy, w której jestem konsultantem, co uczyniło ją jedną z nielicznych firm komercyjnych, które poddały swoje nowatorskie rozwiązania z zakresu inżynierii oprogramowania ocenie niezależnych ekspertów z tej dziedziny.

Publikacja, która ukazała się jako rozdział w książce (okładka poniżej),  świadczy o pozytywnej recenzji i akceptacji drogi rozwoju jaka została obrana w obszarze zwinnego modelowania.

User story to opis celów zorientowanych na użytkownika, jakie jedna lub więcej osób osiągnie za pomocą Twojego produktu. User stories używa się do osiągnięcia celu zawsze wtedy, kiedy jest osoba obsługująca interfejs . User story pisze się w formacie

Jako [osoba odgrywająca daną rolę] chcę [wykonać jakąś czynność] aby [osiągnąć jakiś cel].

W ten sam sposób można pisać scenariusze przypadków użycia, przy których należy uwzględnić, że scenariusz może obejmować kilka user story. Takie podejście pozwala także na zastosowanie modelowania w języku UML w SCRUM i tym samym wpisuje sie w nurt agile modeling ? zwinnego modelowania.

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.

Moim zdaniem wszystkie metodyki zwinne mają tą zaletę, że są tańsze od tradycyjnego ?ciężkiego? podejścia choćby dlatego, że nie traci się czasu na modelowanie. Jest tylko jedno ale. A mianowicie klient musi dokładnie wiedzieć czego chce. Co w sytuacji gdy klient jest grymaśny, zmienia wymagania lub tylko je odrobinę modyfikuje bo jak widzi gotowy produkt to zaczyna rozumieć błędy w swoich wymaganiach, zaczyna rozumieć swój biznes? W takiej sytuacji modelowanie staje się nieodzowne. Budując model klient może zrozumieć i zobaczyć jak będzie działał system i zweryfikować czy jest to to o co dokładnie mu chodziło. Co więcej mając model wytwórcy także lepiej go rozumieją. Pozostaje pytanie: Co z kosztami?

Wbrew pozorom koszty modelowania nie są wysokie i zwracają się z nawiązką.

Skąd te wyniki wyjaśnia to poniższa tabela, w której cyfry stanowią jednostki czasu, którym możemy przypisać dowolną wartość: tydzień, miesiąc.

Otóż ponosi się co prawda koszty modelowania, ale w związku z tym, że zatwierdzony  model pomaga lepiej zrozumieć projektowany system i klientowi, i wykonawcy systemu to jest mniej poprawek kodu i mniej testowania bo testy mogą być wcześniej zaplanowane. Natomiast permanentne zmiany w aplikacji celem dostosowania ich do wymagań klienta, w sytuacji gdy gotowy produkt rozmija się mniej lub bardziej z rzeczywistymi potrzebami klienta to dodatkowe koszty. Ponadto  gdy nie ma modelu programista musi wszystko wymyślić sam a tym samym może się okazać, że gdy popełni błąd w rozumowaniu to prawienie  błędu pociąga za sobą dodatkowe koszty. Mając model można błędy wychwycić wcześniej.

Szacuję, że przy większych projektach oszczędności czasu a tym samym pieniędzy, z tytułu modelowania, sięgają od 20 do 30 procent.

Na koniec należy pamiętać, że podane cyfry to tylko przykład i w każdym projekcie poszczególne fazy mogą wyglądać inaczej a co za tym idzie oszczędności mogą być mniejsze lub większe.

Budowanie modeli ma ogromną wartość. Zastanawia mnie dlaczego budując dom wymagana jest dokumentacja projektowa a do budowy systemu informatycznego to sprawa opcjonalna. Dokumentacja nie zawsze jest wykonywana a jej potrzeba wynika bardziej ze świadomości zamawiającego produkt niż z wymogów prawa. Ciekawe jest to, że koszt budowy domu jest wielokrotnie niższy niż niejednego systemu informatycznego. Co więcej gdy chcemy coś dobudować do naszego domku musimy mieć gotowy plan rozbudowy i kilka zezwoleń od władz. W systemach informatycznych niejednokrotnie zmiany są nanoszone ad hoc ? zwłaszcza w metodykach Agile. A przecież budowa zwinnego modelu nie jest droga a daje sporo korzyści bo pozwala na lepsze zdefiniowanie wymagań. Budowa modeli pozwala na:

• odkrycie wymogów, które w przeciwnym przypadku pozostałyby nieodkryte
• wyłapanie prawidłowych wymogów
• efektywne przekazywanie informacji dotyczące wymogów
• wyznaczenie priorytetowych wymogów

Innymi słowy niezależnie od tego czy budujemy nowy system czy też rozbudowujemy stary mając model jesteśmy wstanie lepiej zarządzać wymaganiami a tym samym całym przedsięwzięciem, gdyż unikamy większej ilości przypadkowych czynności, które mogłyby doprowadzić do porażki.

?Zwinne modelowanie wymagań biznesowych w wytwarzaniu oprogramowania? to temat artykułu, który pozytywnie został oceniony przez recenzentów  XI Krajowej Konferencji Inżynierii Oprogramowania (KKIO’09).

W artykule tym wskazałem, że  zwinne metodyki zwinne unikają budowy modeli a jednocześnie odczuwalna jest potrzeba dokumentowania decyzji projektowych.  Wskazałem na podstawowe czynności związane ze zwinnym modelowaniem wymagań biznesowych w wytwarzaniu oprogramowania. W poszczególnych podrozdziałach zaprezentowałem  rozszerzoną notację UML oraz produkty jakie powstać powinny w ramach tej fazy.