projektowanie systemów informatycznych

Projekty

Kategorie

Linki

Polecam


tagi

archiwum

Czy warto stosować mechanizmy inżynierii wprzód i wstecz w zwinnym modelowaniu?

piątek 13 lis 2009

Ostatnie kilka wpisów:

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ęść »


Pisanie user story i scenariuszy przypadków użycia

czwartek 3 wrz 2009

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.


Wielkość i długość iteracji

poniedziałek 31 sie 2009

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


Trzy korzyści z przypadków użycia

piątek 7 sie 2009

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.


Historyjki użytkownika a przypadki użycia

wtorek 28 lip 2009

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.


Lipcowe zwinne modelowanie procesów biznesowych

poniedziałek 27 lip 2009

Największym kapitałem każdej organizacji są zachodzące w niej procesy. Aby procesy te mogły być efektywnie doskonalone należy je w odpowiedni sposób odwzorować w systemie informatycznym. Zanim przystąpi się do budowy systemu informatycznego warto dobrze poznać te procesy budując ich modele. Dziś przyszłość stanowią metodyki zwinne (Agile) w tym także te, które wykorzystują modele. Właśnie tej tematyce  – zwinnemu modelowaniu procesów biznesowych poświęcone było dwudniowe szkolenie, jakie miałem przyjemność poprowadzić 23-24 lipca w Warszawie.

Jedna z warszawskich firm w tym nurcie będzie modelować procesy biznesowe celem dostarczania klientom dedykowanych rozwiązań, które opierają się na otwartym kodzie tworzonej aplikacji. Pozwala to by aplikacja ta była w przyszłości rozwijana i modyfikowana przez dowolny podmiot, nie wyłączając oczywiście samego użytkownika.

Szkolenie przebiegło w bardzo dobrej, twórczej atmosferze. Otrzymałem tylko dobre i bardzo dobre noty a w komentarzach w pozycji Co najbardziej podobało Ci się na szkoleniu można przeczytać między innymi: “skupienie się prowadzącego na sednie sprawy”, “praktyczne przedstawienie złożonego tematu…”. Dziękuję :)


SCRUM a SCRUM z modelowaniem – koszty

czwartek 9 lip 2009

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

image

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.

Działanie

SCRUM z modelowaniem

SCRUM

Wymagania

1

1

Modelowanie

3

0

Kodowanie

9

10

Poprawianie kodu

1

6

Testowanie

1

3

Suma

15

20

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.


Wartość modelowania

wtorek 7 lip 2009

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


KKIO 2009

poniedziałek 6 lip 2009

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


Agile w krzywym zwierciadle

czwartek 2 lip 2009

image


Specyfikacja oparta na scenariuszu

czwartek 2 lip 2009

Zwinne modelowanie polega miedzy innymi na tym, że budowana dokumentacja do projektu nie jest nadwymiarowa. Innymi słowy jest jej tyle ile potrzeba i nie mniej ani nie więcej. Jak na tym zapanować. Ja osobiście lubię stosować scenariusze (w SCRUM opowiadania klienta), które pozwalają mi na zbudowanie zwinnych przypadków użycia. Natomiast przypadki użycia pomagają mi efektywnie:

  • planować iteracje
  • szacować złożoność projektu
  • komunikować się z klientem
  • weryfikować wymagania klienta
  • planować testy
  • lepiej integrować systemy

Czym jest więc przypadek użycia? W moim rozumieniu przypadek użycia to agregat scenariuszy dostarczający konkretnych wartości. Dlatego też w moich modelach scenariusze odgrywają ważną rolę, a modele opierają się o przypadki użycia.

image


Zwinne modelowanie w SCRUM

poniedziałek 22 cze 2009

Scrum to jedna ze zwinnych metodyk w nurcie Agile, stosowaną w procesie wytwórczym oprogramowania. SCRUM jest ukierunkowany na budowę gotowego kodu. Powstaje jednak pytanie co zrobić, gdy potrzebny jest model, lub specyfikacja projektu?

Jest na to sposób. Można budować modele zgodnie z  metodyką SCRUM. Na stronie: Modelowanie w SCRUM opisałem zarys SCRUM wraz z kilkoma wskazówkami wykorzystania języka UML w tej metodyce.

przeczytaj pozostałą część »