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

(1)

Projektowanie oprogramowania

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

Tabela 1. Realizowane projekty

Grupa studencka

Sala

Projekt Zespoły

wykonawców

Podgrupy w zespołach

7.30-9.00

L2.6, C-16

Wypożyczalnia sprzętu komputerowego

10 osób

 Jeden student w roli *Scrum Master i Administrator



Podział na dwie równolegle pracujące podgrupy. Każda z podgrup składa się z 5 i 4 osób. Każda cztero- i pięcioosobowa podgrupa:

– 4/5 studentów tworzy Development Team, w tym jeden ze studentów pełni rolę inspektora, a drugi kierownika**

Sprzedaż sprzętu komputerowego

9 osób



Podział na dwie równolegle pracujące podgrupy. Każda z podgrup składa się z 4 osób.

Każda czteroosobowa podgrupa:

– 4 studentów tworzy Development Team, w tym jeden ze studentów pełni rolę**

inspektora, a drugi kierownika

9.15-11.00,

05, C-3

Wypożyczalnia samochodów

10 osób



Podział na dwie równolegle pracujące podgrupy. Każda z podgrup składa się z 5 i 4 osób. Każda cztero- i pięcioosobowa podgrupa:

– 4/5 studentów tworzy Development Team, w tym jeden ze studentów pełni rolę inspektora, a drugi kierownika**

Sprzedaż samochodów

9 osób



Podział na dwie równolegle pracujące podgrupy. Każda z podgrup składa się z 4 osób.

Każda czteroosobowa podgrupa:

– 4 studentów tworzy Development Team, w tym jeden ze studentów pełni rolę**

inspektora, a drugi kierownika

*Scrum Master, **

Development Team – pojęcia wyjaśnione dalej

(2)

Tabela 2. Przebieg realizacji każdego z projektów (tabela 1)

Opis realizacji sprintu dla dwóch podgrup zespołu (2 przypadki użycia)

Nr

tygodnia

Sprint Spotkanie Uwagi dotyczące realizacji zadań przez każdą z dwóch podgrup zespołu

Liczba punktów (do oceny)

Zadania Scrum Master

1 1 Sprint planning

meeting (90 min)

 Zajęcia organizacyjne ( podział na grupy i podgrupy, przydzielenie ról projektowych, uzyskanie dostępu do wymaganych narzędzi)

 User Stories - Opracowanie modelu biznesowego

„świata rezczywistego”systemu– udział wszystkich grup projektowych. Każda grupa projektowa otrzymuje ogólny opis procesów biznesowych, ale opracowuje dokładnie wybrany fragment opisu biznesowego

 Sprint Backlog (formy pośrednie: Product Backlog), Sprint planining) - 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 wykonać za pomocą diagramu aktywności (ewentualnie diagramu sekwencji i diagramu stanów). 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 https://java.net/projects/ i zostaną ocenione oceniane przez prowadzącego zajęcia

3-5 Współdziałanie z wykonawcami z podgrup

2 Daily Scrum of

Scrums (20 min)

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

– diagram klas, – diagramy sekwencji, – diagramy aktywności – diagramy stanów – raport (inspektor)

– wygenerowanie dokumentacji, zawierającej wymienione wyżej elementy identyfikowane na

3-5 – Integrowanie projektów PU opracowanych przez podgrupy projektowe w postaci jednego diagramu przypadków użycia,

– Eliminacja redundancji w projekcie,

– Analiza raportów inspektorów,

(3)

podstawie PU, wykorzystanie wzorców projektowych(zalecane)

Podczas 2-tygodnia wyniki prac umieszczane są w repozytorium https://java.net/projects/ i zostaną oceniane przez prowadzącego zajęcia

– Ocena wpływu zidentyfikowanych problemów na przebieg projektu

Podczas 2-tygodnia wyniki prac umieszczane są w repozytorium

https://java.net/projects/

i muszą być zatwierdzone przez prowadzącego zajęcia

3 Daily Scrum of

Scrums (20 min)

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

– diagram klas, – diagramy sekwencji, – diagramy aktywności – diagramy stanów

– integracja raportów (inspektor)

– 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 https://java.net/projects/ i muszą być zatwierdzone przez prowadzącego zajęcia w celu przekazania wykonanego modelu do implementacji

3-5 – Integrowanie projektów PU opracowanych przez podgrupy 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

– usuwanie błędów

4-10 – Włączenie się do podgrup wykonawców i wspomaganie prac.

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

(4)

– pomiar metryk oprogramowania za pomocą narzędzia CKJM lub

SonarQube

– 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

– raport (inspektor)

Podczas 4-tygodnia wyniki prac umieszczane są w repozytorium https://java.net/projects/ i muszą być zatwierdzone przez prowadzącego 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)

– raport (inspektor)

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

3-5 – Kontrola przyjętego standardu formularzy, – Analiza raportów

inspektorów, – Ocena wpływu

6 2 Scenariusz dla jednej podgrupy Scenariusz dla drugiej

podgrupy integrującej kod dwóch podgrup z 1 sprintu

Ocena

Sprint review meeting &

Sprint planning

 Rozbudowa diagramu PU zs Spintu 1 (Sprint Backlog):

planowanie nowych PU, uwzględnienie wniosków z raportów opracowanych przez Scrum Master z wykonanych PU podczas 1 Spintu

 Definicja PU (przypadku użycia): opis słowny wg

3-5 Włączenie się do prac podgrup wykonawcom

Integracja 2 projektów typu EE jako implementacja dwóch przypadków użycia (wg podanego tutorialu), dostarczonych po

3-5

(5)

meeting (90 min)

standardowego formularza – scenariusz należy wykonać za pomocą diagramu aktywności (ewentualnie diagramu sekwencji i diagramu stanów). Podgrupa opracowuje przypadek użycia jako specyfikację tych wymagań

funkcjonalnych, które opracowała w poprzednich krokach.

 Podczas 6-tygodnia wynik prac umieszczane są w repozytorium https://java.net/projects/ i są oceniane przez prowadzącego zajęcia

zakończeniu 5 tygodnia – etap 1-y

Podczas 6-tygodnia wyniki prac umieszczane są w repozytorium

https://java.net/projects/ i muszą być zatwierdzone przez prowadzącego zajęcia

7 Daily Scrum

of Scrums (20 min)

– diagram klas, – diagramy sekwencji, – diagramy aktywności – diagramy stanó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 https://java.net/projects/ i są oceniane przez prowadzącego zajęcia w celu przekazania wykonanego modelu do implementacji

4-10 – Analiza raportów inspektorów, – Ocena wpływu

– Integracja 2 projektów typu EE jako implementacja dwóch przypadków użycia (wg podanego tutorialu) – etap 2-i

– Testowanie

4-10

8 Daily Scrum

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

SonarQube

– 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 8-tygodnia wyniki prac umieszczane są w

4-9 Włączenie się do podgrupy wykonawców i wspomaganie prac

Wykonanie warstwy integracji opartej na

technologii JPA na podstawie obiektowego modelu danych z pierwszego Sprintu

4-9

(6)

repozytorium https://java.net/projects/. Włączenie się do podgrupy wykonawców i wspomaganie prac.

Wyniki prac muszą być zatwierdzone przez prowadzącego zajęcia w celu przekazania wykonanego oprogramowanie na podstawie modelu wykonanego w 6-8 tygodni

9 Daily Scrum

Implementacja2 PU (warstwa prezentacji i klienta):

– opracowanie wspólnego szablonu tworzonych formularzy, – ujednolicenie funkcjonalności formularzy w zakresie ich

obsługi i walidacji danych

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

Podczas 9-tygodnia wyniki prac umieszczane są w repozytorium https://java.net/projects/ i i muszą być zatwierdzone przez prowadzącego zajęcia w celu

przekazania wykonanej implementacji do integracji przez wydzieloną podgrupę

3-5 Kontrola przyjętego standardu formularzy,

Wykonanie testów projektu Podczas 9-tygodnia wyniki prac umieszczane są w repozytorium

3-5

Scenariusz dla dwóch podgrup

10 3 Sprint

review meeting &

Sprint planning meeting (90 min)

 Rozbudowa diagramu PU (Sprint Backlog): planowanie nowych PU dla dwóch podgrup, uwzględnienie wniosków z raportów opracowanych przez Scrum Master z wykonanych PU.

 Definicja PU (przypadku użycia): opis słowny wg

standardowego formularza – scenariusz należy wykonać za pomocą diagramu aktywności (ewentualnie diagramu sekwencji i diagramu stanów). Każda grupa opracowuje przypadki użycia jako specyfikację tych wymagań

funkcjonalnych, które opracowała w poprzednich krokach.

Podczas 10-tygodnia wynik prac umieszczane są w repozytorium https://java.net/projects/ i są oceniane przez prowadzącego zajęcia

3-5 – Rozwój warstwy integracji opartej na technologii JPA dla obiektowego modelu danych z drugiego Sprintu

– Wykonanie testów Podczas 10-tygodnia wyniki prac

umieszczane są w repozytorium

11 Daily Scrum

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

– diagramy sekwencji,

5-9 – Integrowanie PU opracowanych przez podgrupy projektowe w postaci jednego diagramu PU

(7)

– diagramy aktywności – diagramy stanów

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

Podczas 11-tygodnia wyniki prac umieszczane są w repozytorium https://java.net/projects/ i i muszą być zatwierdzone przez prowadzącego zajęcia w celu przekazania wykonanego modelu do implementacji

– Integrowanie projektów PU opracowanych przez podgrupy projektowe w postaci jednego diagramu klas, – Eliminacja redundancji

w projekcie, – Analiza raportów

inspektorów, – Ocena wpływu

Podczas 11-tygodnia wyniki prac

umieszczane są w repozytorium

https://java.net/projects / i muszą być

zatwierdzone przez prowadzącego zajęcia

12 Daily Scrum

Implementacja1 PU (warstwa biznesowa) rozwój oprogramowania wykonanego w 2-ym sprincie:

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

SonarQube

– 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 12-tygodnia wyniki prac umieszczane są w repozytorium https://java.net/projects/ i muszą być zatwierdzone przez prowadzącego zajęcia w celu

przekazania wykonanego oprogramowanie na podstawie

5-9 Włączenie się do zespołów wykonawców i wspomaganie prac

(8)

modelu wykonanego w 11-12 tygodni

13 Implementacja2 PU (warstwa prezentacji i klienta):

– opracowanie wspólnego szablonu tworzonych formularzy, – ujednolicenie funkcjonalności formularzy w zakresie ich

obsługi i walidacji danych

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

Podczas 13-tygodnia wyniki prac umieszczane są w repozytorium https://java.net/projects/ i muszą być zatwierdzone przez prowadzącego zajęcia w celu

przekazania wykonanej implementacji do integracji przez wydzielony zespół

3-5 Kontrola przyjętego standardu formularzy,

Scenariusz dla jednej podgrupy Scenariusz dla drugiej

podgrupy integrującej kod dwóch podgrup z 3 sprintu

Ocena

14 Daily Scrum

of Scrums (20 min)

– Integracja 2 projektów typu EE jako implementacja dwóch przypadków użycia (wg podanego tutorialu), dostarczonych po zakończeniu 13 tygodnia.

– Wykonanie testów projektu typu EE

Podczas 14-tygodnia wyniki prac umieszczane są w repozytorium https://java.net/projects/ i muszą być zatwierdzone przez prowadzącego zajęcia

2-5 Włączenie się do podgrup wykonawców i

wspomaganie prac

– Rozwój warstwy integracji opartej na technologii JPA dla obiektowego modelu danych z drugiego Sprintu.

– Wykonanie testów Podczas 14-tygodnia wyniki prac umieszczane są w repozytorium

https://java.net/projects/ i muszą być zatwierdzone przez prowadzącego zajęcia.

2-5

15 Sprint review meeting & Sprint retrospective meeting (1.5h)

Podsumowanie

(9)

Stosowany proces wytwarzania oprogramowania - Scrum

Stosowany będzie proces wytwarzania oprogramowania wzorowany na metodyce Scrum.

Z metodyki SCRUM 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 synchronizacja prac wykonywanych przez

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 podgrupom, 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 java.net zadania składające się na realizację danego przypadkiem użycia i poprzydzielał je członkom zespołu.

(10)

Role projektowe

Zespół Scrum zwykle składa się od 3 do 9 osób, reprezentujących różne umiejętności. Jeden projekt będzie realizowany przez połowę grupy studenckiej zapisanej na dany termin, czyli zespół projektowy będzie się składał z około 9 osób.

 Product Owner - rola pełniona przez prowadzącego zajęcia. 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.

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 4-6-osobowej podgrupy.



Scrum Master – ta sama osoba w projekcie, która pełni rolę Administrator. 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 java.net, w szczególności ma uprawnienia do zmieniania osoby przypisanej do błędu.

Jak wybrać kierownika oraz inspektora



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.

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