Opis realizacji dla czterech zespołów (4 przypadki użycia) Nr tygodnia Sprint Spotkanie

Projektowanie oprogramowania

Termin zajęć: czwartek, sala L2.6, C16 7.30-9.00,

9.15-10.45

Na podstawie materiału ze strony http://gromit.iiar.pwr.wroc.pl/p_inf/

Przebieg realizacji projektu (tabela 1)

Opis realizacji dla czterech zespołów (4 przypadki użycia)

Nr tygodnia

Sprint Spotkanie Uwagi dotyczące realizacji Zespoły składające się z 4- 6 studentów studentów- przystąpienie do kolejnego Daily Scrum po zaliczeniu poprzedzającego

Liczba punktów (do oceny)

Zadania kierownika zespołów (Scrum Master)

1 1 Sprint

planning meeting (90 min)

 Zajęcia organizacyjne ( podział na grupy,

przydzielenie ról projektowych, uzyskanie dostępu do wymaganych narzędzi)

 Sprint Backlog - Opracowanie modelu biznesowego systemu Wypożyczalni sprzętu sportowego (grupa 7.30-9.00) oraz systemu ProjectPortfolio (grupa 9.15-10.45) – udział wszystkich grup projektowych.

Każda grupa projektowa otrzymuje ogólny opis procesów biznesowych, ale opracowuje dokladnie wybrany fragment opisu biznesowego

 Sprint Backlog - zdefiniowanie wymagań funkcjonalnych i niefunkcjonalnych– udział wszystkich grup projektowych. Każda grupa dokładnie opracuje część wymagań funkcjonalnych wynikających z otrzymanego fragmentu opisu

„świata rzeczywistego”

 Definicja PU (przypadku użycia): opis słowny wg standardowego formularza – scenariusz należy

3-5

wykonać za pomocą diagramu aktywności. Każda grupa opracowuje przypadki użycia jako

specyfikację tych wymagań funkcjonalnych, które opracowała w poprzednich krokach.

Podczas 1-tygodnia wynik prac umieszczane są w repozytorium java,net i są być oceniane przez prowadzących zajęcia

2 Daily Scrum

of Scrums (20 min)

Przedstawienie wyników prac z 1 tygodnia Projekt PU (wersja początkowa):

– diagram klas, – diagram sekwencji, – diagramy stanów – raport

– wygenerowanie dokumentacji, zawierającej wymienione wyżej elementy identyfikowane na podstawie PU, wykorzystanie wzorców projektowych(zalecane)

Podczas 2-tygodnia wyniki prac umieszczane są w repozytorium java,net i są być oceniane przez prowadzących zajęcia

3-5 Integrowanie projektów

PU opracowanych przez grupy projektowe w postaci jednego diagramu przypadków użycia, eliminacja redundancji w projekcie, Analiza raportów inspektorów, ocena wpływu

zidentyfikowanych problemów na przebieg projektu

3 Daily Scrum

of Scrums (20 min)

Przedstawienie wyników prac z 2 tygodnia Projekt PU (wersja końcowa):

– diagram klas, – diagram sekwencji, – diagramy stanów – integracja raportów

– wygenerowanie dokumentacji zawierającej wymienione wyżej elementy identyfikowane na podstawie PU, wykorzystanie wzorców projektowych (zalecane).

Podczas 3-tygodnia wyniki prac umieszczane są w repozytorium java,net i i muszą być zatwierdzone przez prowadzących zajęcia w celu przekazania wykonanego modelu do implementacji

4-10 Integrowanie projektów PU opracowanych przez grupy projektowe w postaci jednego

diagramu klas, eliminacja redundancji w projekcie, Analiza raportów inspektorów, ocena wpływu

zidentyfikowanych problemów na przebieg projektu

4 Daily Scrum

of Scrums (20 min)

Implementacja1 PU (warstwa biznesowa):

– kod warstwy biznesowej na podstawie modelu wykonanego w tygodniach 1-3,

– koncepcja i kod testów jednostkowych i integracyjnych wykonanych za pomocą JUnit

3-5 Włączenie się do

zespołów wykonawców i wspomaganie prac.

– usuwanie błędów

– pomiar metryk oprogramowania za pomocą narzędzia CKJM

– ewentualna refaktoryzacja kodu w celu poprawy nieprawidłowych wartości metryk (w szczególności RFC, LCOM3)

– powtórzenie testów jednostkowych w przypadku refaktoryzacji kodu

Podczas 4-tygodnia wyniki prac umieszczane są w repozytorium java,net i i muszą być zatwierdzone przez prowadzących zajęcia w celu przekazania wykonanego oprogramowanie na podstawie modelu wykonanego w 1-3 tygodniach

5 Daily Scrum

of Scrums (20 min)

Implementacja2 PU (warstwa prezentacji i klienta):

– opracowanie wspólnego szablonu tworzonych formularzy,

– ujednolicenie funkcjonalności formularzy w zakresie ich obsługi i walidacji danych

– kod warstwy prezentacji i klienta (technologia JSF lub/i Enterprise Application Client),

– koncepcja i kod testów akceptacyjnych (Selenium lub ręcznych)

Podczas 5-tygodnia wyniki prac umieszczane są w repozytorium java,net i i muszą być zatwierdzone przez prowadzących zajęcia w celu przekazania wykonanej implementacji do integracji przez wydzielony zespół

4-10 Kontrola przyjętego standardu formularzy,

6 2

Scenariusz dla trzech zespołów Scenariusz dla

jednego zespołu Ocena

Sprint review meeting &

Sprint planning meeting (90 min)

Wszystkie grupy

 Rozbudowa diagramu PU (Sprint Backlog):

planowanie nowych PU, uwzględnienie wniosków z raportów opracowanych przez Scrum Master z wykonanych PU. Rozdział nowych PU do 3 grup wykonawców

 Definicja PU (przypadku użycia): opis słowny wg standardowego formularza – scenariusz należy wykonać za pomocą diagramu aktywności. Każda grupa opracowuje przypadki użycia jako

3-5 Integracja 4 projektów

typu EE (wg podanego tutorialu), dostarczonych po zakończeniu 5 tygodnia – etap 1-y

3-5

specyfikację tych wymagań funkcjonalnych, które opracowała w poprzednich krokach.

 Podczas 6-tygodnia wynik prac umieszczane są w repozytorium java,net i są oceniane przez prowadzących zajęcia

7 Daily Scrum

of Scrums (20 min)

Przedstawienie wyników prac z 6 tygodnia Projekt PU (wersja końcowa):

– diagram klas, – diagram sekwencji, – diagramy stanów – integracja raportów

– wygenerowanie dokumentacji zawierającej wymienione wyżej elementy identyfikowane na podstawie PU, wykorzystanie wzorców projektowych (zalecane).

Podczas 7-tygodnia wyniki prac umieszczane są w repozytorium java,net i mogą być oceniane przez prowadzących zajęcia

3-5 Integrowanie PU

opracowanych przez grupy projektowe w postaci jednego diagramu PU

Integracja 4 projektów typu EE (wg podanego tutorialu) – etap 2-i

3-5

8 Przedstawienie wyników prac z 7 tygodnia

Projekt PU (wersja końcowa):

– diagram klas (integracja przez Scrum Master diagramów klas z 7 tygodnia)

– diagram sekwencji, – diagramy stanów – integracja raportów

– wygenerowanie dokumentacji zawierającej wymienione wyżej elementy identyfikowane na podstawie PU, wykorzystanie wzorców projektowych (zalecane).

Podczas 8-tygodnia wyniki prac umieszczane są w repozytorium java,net i i muszą być zatwierdzone przez prowadzących zajęcia w celu przekazania wykonanego modelu do implementacji

4-10 Integrowanie projektów

PU opracowanych przez grupy projektowe w postaci jednego diagramu klas,

eliminacja redundancji w projekcie,

Analiza raportów inspektorów, ocena wpływu

zidentyfikowanych problemów na przebieg projektu

Wykonanie warstwy integracji opartej na technologii JPA – etap 1-y

4-10

9 Daily Scrum

of Scrums (20 min)

Implementacja1 PU (warstwa biznesowa) rozwój oprogramowania wykonanego w 1-ym sprincie i zintegrowanego przez zespół czwarty w tygodniu 7:

– kod warstwy biznesowej na podstawie modelu z 6-8 tygodnia

– koncepcja i kod testów jednostkowych i integracyjnych wykonanych za pomocą JUnit – usuwanie błędów

3-5 Włączenie się do

zespołów wykonawców i wspomaganie prac

Wykonanie warstwy integracji opartej na technologii JPA – etap 2-i

3-5

– pomiar metryk oprogramowania za pomocą narzędzia CKJM

– ewentualna refaktoryzacja kodu w celu poprawy nieprawidłowych wartości metryk (w szczególności RFC, LCOM3)

– powtórzenie testów jednostkowych w przypadku refakatoryzacji

Podczas 9-tygodnia wyniki prac umieszczane są w Włączenie się do zespołów wykonawców i

wspomaganie prac.repozytorium java,net i i muszą być zatwierdzone przez prowadzących zajęcia w celu przekazania wykonanego oprogramowanie na podstawie modelu wykonanego w 6-8 tygodni

10 Daily Scrum

of Scrums (20 min)

Implementacja2 PU (warstwa prezentacji i klienta):

– opracowanie wspólnego szablonu tworzonych formularzy,

– ujednolicenie funkcjonalności formularzy w zakresie ich obsługi i walidacji danych

– kod warstwy prezentacji i klienta (technologia JSF lub/i Enterprise Application Client),

– koncepcja i kod testów akceptacyjnych (Selenium lub ręczne),

Podczas 10-tygodnia wyniki prac umieszczane są w repozytorium java,net i i muszą być zatwierdzone przez prowadzących zajęcia w celu przekazania wykonanej implementacji do integracji przez wydzielony zespół

.4-10 Kontrola przyjętego standardu formularzy,

Wykonanie testów projektu typu EE

4-10

Scenariusz dla trzech zespołów Scenariusz dla

jednego zespołu

Ocena

11 3 Sprint

review meeting &

Sprint planning meeting (90 min)

Wszystkie grupy

 Rozbudowa diagramu PU (Sprint Backlog):

planowanie nowych PU, uwzględnienie wniosków z raportów opracowanych przez Scrum Master z wykonanych PU. Rozdział nowych PU do 3 grup wykonawcow

 Definicja PU (przypadku użycia): opis słowny wg standardowego formularza – scenariusz należy wykonać za pomocą diagramu aktywności. Każda grupa opracowuje przypadki użycia jako

5-10 Integracja 3 projektów,

typu EE (wg podanego tutorialu) dostarczonych w 10 tygodniu,– etap 1-y

5-10

specyfikację tych wymagań funkcjonalnych, które opracowała w poprzednich krokach.

Podczas 11-tygodnia wynik prac umieszczane są w repozytorium java,net i są oceniane przez

prowadzących zajęcia

12 Daily Scrum

of Scrums (20 min)

Przedstawienie wyników prac z 11 tygodnia Projekt PU (wersja końcowa):

– diagram klas (integracja przez Scrum Master diagramów klas z 7 tygodnia)

– diagram sekwencji, – diagramy stanów – integracja raportów

– wygenerowanie dokumentacji zawierającej wymienione wyżej elementy identyfikowane na podstawie PU, wykorzystanie wzorców projektowych (zalecane).

Podczas 12-tygodnia wyniki prac umieszczane są w repozytorium java,net i i muszą być zatwierdzone przez prowadzących zajęcia w celu przekazania wykonanego modelu do implementacji

3-5 Integrowanie PU

opracowanych przez grupy projektowe w postaci jednego diagramu PU

Integrowanie projektów PU opracowanych przez grupy projektowe w postaci jednego diagramu klas,

eliminacja redundancji w projekcie,

Analiza raportów inspektorów, ocena wpływu

zidentyfikowanych problemów na przebieg projektu

Integracja 4 projektów typu EE (wg podanego tutorialu) – etap 2-i

3-5

13 Daily Scrum

of Scrums (20 min)

Implementacja1 PU (warstwa biznesowa) rozwój oprogramowania wykonanego w 2-ym sprincie i zintegrowanego przez zespół czwarty w tygodniu 12:

– kod warstwy biznesowej na podstawie modelu z 11- 12 tygodnia

– koncepcja i kod testów jednostkowych i integracyjnych wykonanych za pomocą JUnit – usuwanie błędów

– pomiar metryk oprogramowania za pomocą narzędzia CKJM

– ewentualna refaktoryzacja kodu w celu poprawy nieprawidłowych wartości metryk (w szczególności RFC, LCOM3)

– powtórzenie testów jednostkowych w przypadku

2-5 Włączenie się do

zespołów wykonawców i wspomaganie prac

Rozwój warstwy integracji opartej na technologii JPA

2-5

refakatoryzacji

Podczas 13-tygodnia wyniki prac umieszczane są w repozytorium java,net i i muszą być zatwierdzone przez prowadzących zajęcia w celu przekazania wykonanego oprogramowanie na podstawie modelu wykonanego w 11-12 tygodni

14 Daily Scrum

of Scrums (20 min)

Implementacja2 PU (warstwa prezentacji i klienta):

– opracowanie wspólnego szablonu tworzonych formularzy,

– ujednolicenie funkcjonalności formularzy w zakresie ich obsługi i walidacji danych

– kod warstwy prezentacji i klienta (technologia JSF lub/i Enterprise Application Client),

– koncepcja i kod testów akceptacyjnych (Selenium lub ręczne),

Podczas 14-tygodnia wyniki prac umieszczane są w repozytorium java,net i i muszą być zatwierdzone przez prowadzących zajęcia w celu przekazania wykonanej implementacji do integracji przez wydzielony zespół

4-10 Kontrola przyjętego standardu formularzy,

Wykonanie testów projektu typu EE

4-10

15 Sprint

review meeting &

Sprint retrospective meeting (1.5h)

Podsumowanie

Stosowany proces wytwarzania oprogramowania - Scrum

Stosowany będzie proces wytwarzania oprogramowania wzorowany na metodyce Scrum. Z metodyki tej zaczerpnięte zostały następujące elementy:



Daily Scrum of Scrums - krótkie spotkanie dotyczące aktualnego statusu projektu, w trakcie którego następuje synchornizacja prac wykonywanych przez poszczególne zespoły. W spotkaniu bierze udział prowadzący, Scrum Master i dokładnie jeden przedstawiciel każdej grupy projektowej, pozostali członkowie grup projektowych mogą brać udział w spotkaniu tylko jako obserwatorzy. W trakcie spotkania przedstawiciel zespołu powinien udzielić odpowiedzi na następujące trzy pytania:

o

Co zespół zrobił od poprzedniego Daily Scrum of Scrums?

o

Co zespół planuje zrobić do następnego Daily Scrum of Scrums?

o

Co przeszkadza zespołowi w realizowaniu zaplanowanych zadań?



Product Owner - rola pełniona przez prowadzącego. Product Owner decyduje o priorytetach poszczególnych zadań, tym samym do niego należy rozstrzygający głos odnośnie zestawu zagadnień wybieranych do Sprint Backlog w trakcie Sprint planning meeting. Product Owner decyduje również o tym, czy dane

zagadnienie zostało zrealizowane w wystarczającym stopniu i z wystarczającą jakości, aby mogło zostać uznane za zaliczone.



Scrum Master - rola pełniona przez 3 studentów – każdy przez okres jednego sprintu. Powinni oni w miarę możliwości rozwiązywać problemy zagrażające sukcesowi sprintu. Administrują systemem Redmine. Pewne zdadania zostały wyspecyfikowane w tabeli 1.



Sprint - ograniczona czasowo do 4 tygodni iteracja (patrz Tab. Przebieg realizacji projektu) w trakcie której zespóły pracują nad przekształceniem przydzielonych przypadków użycia w nadającą się do przekazania klientowi funkcjonalność.



Sprint Backlog - lista błędów, zadań i przypadków użycia z przypisanymi punktami odzwierciedlającymi ich trudność, które mają zostać zrealizowane w trakcie sprintu. Powstaje w systemie Redmine w trakcie Sprint planning meeting.



Sprint planning meeting - 70 minutowe spotkanie rozpoczynające każdy sprint. W trakcie spotkania definiuje się Sprint Backlog. W spotkaniu biorą udział Product Owner, Scrum Master, administrator i przynajmniej jeden przedstawiciel każdej grupy projektowej.



Sprint retrospective meeting - spotkanie podsumowujące projekt. W trakcie spotkania powinna odbyć się dyskusja dotycząca możliwości usprawnienia stosowanego procesu wytwarzania oprogramowania.



Sprint review meeting - 20 minutowe spotkanie podsumowujące sprint. W trakcie spotkania prezentowane oraz omawiane są funkcjonalności zrealizowane w trakcie kończącego się sprintu.

Przepływ pracy

Przepływ pracy w projekcie wynika bezpośrednio z przedstawionego harmonogramu w tabeli 1: Przebieg realizacji projektu.

Cały projekt jest podzielony na 3 sprinty. Każdy sprint składa się z takich samych elementów. Zaczyna się spotkaniem Sprint planning meeting, w trakcie którego wybierana są zagadnienia do zrealizowania w trakcie sprintu, a kończy się spotkaniem Sprint review meeting, w trakcie którego prezentowane są uzyskane wyniki. W trakcie sprintu, raz w tygodniu odbywają się spotkania Daily Scrum of Scrums, na których raportowany jest aktualny status. Najważniejszym zadaniem w trakcie sprintu

jest rozwiązywanie zaplanowanych na sprint zagadnień, czyli błędów, zadań i przypadków użycia.

Każdy wynik prezentowany podczas Daily Scrum of Scrums jest oceniane za pomocą przydzielanych punktów, podanych w tabeli 1, zarówno zespołowi, jak i kierownikowi (Scrum Master)

Realizacja przypadku użycia może być stosunkowo zawiła i obejmuje zazwyczaj wiele różnych aktywności. W związku z tym zaleca się aby kierownik zespołu wprowadził w systemie Redmine zadania składające się na realizację danego przypadkiem użycia i poprzydzielał je członkom zespołu.

Role projektowe

Jeden projekt będzie realizowany przez wszystkich studentów zapisanych na dany termin, czyli zespół projektowy będzie się składał z około 16 osób.



Podział na 3-osobowe podgrupy

o

Programista / modelarz – 2-3 osoby w podgrupie, odpowiedzialne za specyfikowanie wymagań, projektowanie aplikacji, programowanie i testowanie na

poziomie testów jednostkowych

o

Kierownik - 1 osoba w podgrupie, odpowiedzialna za koordynowanie prac wewnątrz podgrupy (np. definiowanie niepunktowanych podzadadań w Redmine), osoba kontaktowa w komunikacji między podgrupami, równocześnie pełni rolę programisty / modelarza

o

Inspektor / tester – 1-2 osoby w podgrupie, odpowiedzialne za przeglądanie i weryfikowanie wymagań oraz modelu (przygotowują raport inspektora) oraz za testy akceptacyjne. Listy kontrolne dla inspektora:



Lista kontrolna diagramów hierarchii okien

http://gromit.iiar.pwr.wroc.pl/p_inf/Lista_kontrolna_diagramu_hierarchii_okien.html



Lista kontrolna opisów PU

http://gromit.iiar.pwr.wroc.pl/p_inf/pliki/lista_kontrolna_opis_PU.pdf



Lista kontrolna diagramów klas

http://gromit.iiar.pwr.wroc.pl/p_inf/pliki/lista_kontrolna_diagram_klas.pdf



Lista kontrolna diagramów sekwencji

http://gromit.iiar.pwr.wroc.pl/p_inf/pliki/lista_kontrolna_diagram_sekwencji.pdf



Lista kontrolna diagramów stanów

http://gromit.iiar.pwr.wroc.pl/p_inf/pliki/lista_kontrolna_stany.pdf



Szablon raportu inspektora

http://gromit.iiar.pwr.wroc.pl/p_inf/RaportInspektora.html



Administrator – 1 osoba w całym projekcie, odpowiedzialne za przygotowywanie i konserwowanie środowiska programistycznego ze szczególnym

uwzględnieniem systemu ciągłej integracji oraz za raportowanie i przypisywanie błędów znalezionych przy pomocy systemu ciągłej integracji. Funkcja cykliczna, kadencja trwa 1 sprint, każdy kolejny administrator powinien pochodzić z innej 3-osobowej podgrupy.



Scrum Master. Funkcja cykliczna, kadencja trwa 4 tygodnie, jedna osoba w projekcie. Każdy kolejny Scrum Master powinien pochodzić z innej 3-osobowej podgrupy. Scrum Master oprócz swojej funkcji powinien wykonywać zadania związane z implementacją realizowanego przez jego grupę przypadku użycia.

Administruje systemem Redmine, w szczegolnosci ma uprawnienia do zmieniania osoby przypisanej do błędu.

Jak wybrać kierownika oraz inspektora

http://gromit.iiar.pwr.wroc.pl/p_inf/pliki/KIEROWANIE.PDF Przygotowywane artefakty



Faza modelowania

o

scenariusz PU, najlepiej w postaci diagramu aktywności, czas życia dokumentu - czas trwania całego projekt

o

specyfikacja testów akceptacyjne do PU, czas życia dokumentu - czas trwania całego projekt albo do momentu zautomatyzowania w postaci wykonywalnej w systemie ciągłej integracji

o

diagram sekwencji do PU

diagram klas do PU

o

diagram stanów (jeżeli jest potrzebny) do PU

o

raport inspektora (można generowac z Redmine albo przygotowywać ręcznie na podstawie wspomnianego powyżej szablonu)



Faza implementacji

o

kod (działająca aplikacja) – obowiązkowa separacja kodu warstwy biznesowej od warstwy prezentacji

zautomatyzowane testy jednostkowe (JUnit)

o

uruchomione manualnie lub zautomatyzowane w wybranym narzędziu testy akceptacyjne



Dokumenty wytwarzane poza fazami, czas życia dokumentu - czas trwania całego projekt

diagram PU

o

diagramy ilustrujące architekturę całego systemu, np.: diagram klas domenowych, diagram ilustrujący podział systemu na komponenty

Czas życia dokumentu wynosi 1 sprint (kodu i zautomatyzowanych testów nie zaliczamy do dokumentów), chyba że napisano w opisie dokumentu inaczej. Dokumenty o czasie życia wynoszącym 1 sprint nie muszą być aktualizowane po zakończeniu sprintu, w którym żyły. Pozostałe dokumenty muszą być aktualizowane aż do końca projektu. Odpowiedzialna za aktualizację dokumentu jest grupa, która wprowadziła zmianę w efekcie której, dokument musi zostać zaktualizowany.

Zalecane narzędzia



UML 2.1 - Visual Paradigm 12.0 Community Edition (każdy diagram powinien powstawać w osobnym pliku)



Netbeans 8.02, Java SE 8, Java EE 7



Hudson - na potrzeby systemu ciaglej integracji został udostępniony serwer: http://snow.iiar.pwr.wroc.pl:8080/hudson/



SonarQube – do oceny jakości oprogramowania: http://snow.iiar.pwr.wroc.pl:8081/



Maven 4.27.1



SVN : https://www.java.net



JUnit 4:



FitNesse, Selenium lub inne narzędzie do testów funkcjonalnych: http://gromit.iiar.pwr.wroc.pl/p_inf/FitNesse.html

Warunki zaliczania i metoda oceniania

Ocena końcowa będzie zależeć od liczby zrealizowanych i zaliczonych zagadnień (zagadnienie może być przypadkiem użycia, zadaniem albo błędem), które wcześniej zostały zgłoszone na www.java.net. Liczba punktów zależy głównie od liczby wykonanych zagadnień i ich znaczenia w projekcie. Waga wykonanych zagadnień będzie omawiana podczas poszczególnych spotkań w ramach każdego sprintu.

Warunkiem uzyskania danej oceny jest zdobycie odpowiedniej liczby punktów, wg tabeli 2:

Tabela 2

Ocena Punkty

3,0 42-49

3,5 50-59

4,0 60-69

4,5 70-79

5,0 80-90

Temat projektu

Registration for classes at the university - Wykonanie systemu zapisów studentów na zajęcia w oparciu o znane algorytmy wpierające proces wyboru najlepszego rozwiązania – wykonanie warstwy integracji z bazą danych jest opcjonalne.

Literatura: http://gromit.iiar.pwr.wroc.pl/p_inf/literatura.html