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ść.

Zwinny  model to taki który jest:

• Wystarczający dla Odbiorców czyli w zależności od odbiorców ogólny gdy rozmawiasz z biznesem lub bardziej techniczny gdy rozmawiasz z IT
• Wystarczająco dobry, aby przekazać sens. Model nie musi być dokładny. Gdy pojawia się niezgodność zastanów się co z tym zrobić. Może wystarczy dekompozycja może notka. Zawsze poproś odbiorcę diagramu by przeczytał to co mu zostało przekazane by wyłapać niezgodności.
• Wystarczająco szczegółowy, ale nie ZBYT szczegółowy aby sprostać wymogom Odbiorców względem komunikacji. Unikaj wyszczególniania każdego niuansu oznaczeń modelu.
• Wystarczająco przejrzysty- łatwy do zrozumienia więc nie twórz wielu linii krzyżujących się wzajemnie i powodujących, że ciężko jest się w nich połapać. Modelując użyj logicznych technik organizacyjnych i zastosuj spójny styl.

przeczytaj pozostałą część »

Właściwym podejściem do definiowania przypadków użycia dla tworzenia oprogramowania przy użyciu metody agile to zacząć od definicji zakresu. Definicje zakresu można opisać za pomocą diagramów WPA (Wysokiego Poziomu Abstrakcji)

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.

Co pewien czas warto także dokonywać 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.

Ostatnie kilka wpisów:

• Inżynieria wstecz w projektach JAVA za pomocą Enterprise Architect
• Enterprise Architect i MDG Integration for Eclipse w praktyce
• MDG Integration for Eclipse i generowanie kodu aplikacji z poziomu Enterprise Architect
• Mały sekret reverse i forward engineering w Enterprise Architect
• Pisanie kodu w Enterprise Architect

dotyczyło metod integracji kodu z jej modelem. Przedstawiłem to zagadnienie w różnych wariantach z pluginem (MDG Integration for Eclipse) i bez. Teraz czas na podsumowanie i pytanie czy jest sens synchronizować model z jego implementacją w trakcie kodowania. Moim skromnym zdaniem NIE. Dlaczego?

przeczytaj pozostałą część »

Planowanie w oparciu o kamienie milowe obejmuje określenie pożądanych wyników projektu i planowania progresji wobec nich poprzez serię kamieni milowych. Można określić dwa typy kamieni milowych:

• Kamienie milowe wypuszczenia – punkty, w których są udostępniane główne produkty wypuszczenia
• Wewnętrzne kamienie milowe – punkty, w których dokonuje się istotnego obiektywnie wymiernego postępu wobec zakończenia rozwiązania.

Każdy kamień milowy jest określony w zakresie celów, które muszą być osiągnięte oraz kryteriów oceny dla obiektywnej oceny, czy zostały osiągnięte. Każdy kamień milowy prezentuje:

• istotny punkt kontrolny projektu
• możliwość oceny dokonanego postępu i ponowną ocenę przyszłych planów
• możliwość dostosowywania się do planów.

Korzystając z techniki kamieni milowych pamiętaj aby zidentyfikować główne produkty kamieni milowych. Pamiętaj także, że granice iteracji zapewniają jasno określone wewnętrzne kamienie milowe dla projektów iteracyjnych.

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.

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

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.

Obecnie znajdujemy się w dziwnej sytuacji ? są user stores (zwane w języku polskim historyjkami użytkownika) i scenariusze przypadków użycia z czego te ostatnie można podzielić na przypadki użycia formalne i nieformalne a także streszczenia przypadków użycia. Czym one się różnią, a w czym są takie same?

Przypadki użycia, scenariusze przypadków użycia i user stories dokumentują opis tego jak produkt ma być używany. Różnią się one, w kontinuum, pod względem ilości dodatkowych danych wymaganych dla stworzenia każdego z nich.

• Formalne przypadki użycia wymagają najwięcej wysiłku. Panuje w nich przepych i wiele się w nich dzieje, ale opisują wszelkie kombinacje tego, jak różne osoby wykonują tą samą czynność (lub jej odmianę).
• Nieformalne przypadki użycia są mniej więcej takie same- tyle tylko, że są mniej formalne. Wyzwaniem jest dostarczenie odpowiedniego poziomu szczegółowości, bez elementów prowadzących formalnych przypadków użycia, które mają służyć jako przypomnienie.
• Streszczenia przypadków użycia niemalże nie mają dodatkowych danych, ale zawierają takie sama wyzwania ?na ile jest to jest wystarczająco? co nieformalne przypadki użycia, tyle że w większym stopniu.
• User stories mają najmniej dodatkowych danych i dostarczają najmniejszy kontekst.

Scenariusze przypadków użycia to nieco inny przypadek. Podobnie jak user story, scenariusz przypadku użycia opisuje jedną ścieżkę przez wielościeżkowy przypadek użycia. Warto więc połączyć słabość przypadku użycia (wysoka ilość danych dodatkowych) ze słabością user story (ograniczony kontekst) co w konsekwencji da dość spójny i zwinny oraz pomocny artefakt.

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.