Projektowanie oprogramowania Termin zajęć: poniedziałek, 18.00

Projektowanie oprogramowania
Termin zajęć: poniedziałek, 18.00-19.45
a podstawie materiału ze strony
http://gromit.iiar.pwr.wroc.pl/p_inf/
Przebieg realizacji projektu (tabela 1)
Nr
tygo
dnia
Sprint
Spotkanie
1
1
Sprint
planning
meeting (90
min)
2
Daily Scrum
of Scrums
(20 min)
3
Daily Scrum
of Scrums
(20 min)
4
Daily Scrum
of Scrums
(20 min)
Uwagi dotyczące realizacji Zespóły składające
się z trzech studentów- przystapienie do
kolejnego Daily Scrum po zaliczeniu
poprzedzajacego
1. Zajęcia organizacyjne ( podział na grupy,
przydzielenie ról projektowych, uzyskanie
dostępu do wymaganych narzędzi)
2. Sprint Backlog - Opracowanie modelu
biznesowego systemu zapisów studentów na
zajęcia w oparciu o znane algorytmy
wpierające proces wyboru najlepszego
rozwiązania – udział wszystkich grup
projektowych
3. Sprint Backlog - zdefiniowanie wymagań
funkcjonalnych i niefunkcjonalnych– udział
wszystkich grup projektowych
Definicja PU (przypadku użycia): opis słowny
wg standardowego formularza – scenariusz
można wykonać za pomocą diagramu
aktywności
Liczba
punktów
(do
oceny)
Zadania kierownika
zespołów (Scrum
Master)
3-5
Integrowanie PU
opracowanych przez
prupy projektowe w
postaci diagramu PU
Projekt PU:
– diagram klas,
– diagram sekwencji,
– diagramy stanów
– raport
– wygenerowanie
dokumentacji, zawierającej wymienione wyżej
elemetny identyfikowane na podstawie PU,
wykorzystanie wzorców projektowych
(zalecane)
4-10
Integrowanie projektów
PU opracowanych
przez prupy projektowe
w postaci jednego
diagramu klas,
eliminacja redundancji
w projekcie,
Implementacja1 PU (warstwa biznesowa):
– kod warstwy biznesowej,
– 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 refakatoryzacji kodu
3-5
Sporządzenie
dokumentacji p.2 i 3
(edytor tekstu itp)
Analiza raportów
inspektorów, ocena
wpływu
zidnetyfikowanych
problemów na przebieg
projektu
Integrowanie kodu
źródłowego: tworzenie
wieloużywalnych
pakietów (bibliotek)
5
6
2
7
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),
– koncepcja i kod testów akceptacyjnych
(Selenium lub recznych),
Sprint
review
meeting &
Sprint
planning
meeting (90
min)
Daily Scrum
of Scrums
(20 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
8
Daily Scrum
of Scrums
(20 min)
9
Daily Scrum
of Scrums
(20 min)
10
3
Sprint
review
meeting &
Sprint
planning
meeting (90
min)
4-10
Kontrola przyjętego
standardu formularzy,
Podobnie jak w sprincie
1
Definicja PU (przypadku użycia): opis słowny
wg standardowego formularza – scenariusz
można wykonać za pomocą diagramu
aktywności
3-5
Projekt PU:
– diagram klas,
– diagram sekwencji,
– diagramy stanów
– raport
– wygenerowanie
dokumentacji, zawierającej wymienione wyżej
elemetny identyfikowane na podstawie PU,
wykorzystanie wzorców projektowych
(zalecane)
Implementacja1 PU (warstwa biznesowa):
kod warstwy biznesowej,
– 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 refakatoryzacji
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),
– koncepcja i kod testów akceptacyjnych
(Selenium lub ręczne),
Podobnie jak w sprincie 2
4-10
3-5
4-10
Podobnie jak w sprincie1
Daily Scrum
of Scrums
(20 min)
Daily Scrum
of Scrums
(20 min)
Daily Scrum
of Scrums
(20 min)
Sprint
review
meeting &
Sprint
retrospective
meeting
(1.5h)
11
12
13
14
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.htm
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 3osobowej 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
o diagram klas do PU
o diagram stanów (jeżeli jest potrzebny) do PU
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
o 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
o diagram PU
o diagramy ilustrujące architekturę całego systemu, np.: diagram klas domenowych, diagram
ilustrujący podział systemu na komponenty
o
•
•
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 8.1 Community Edition (każdy diagram powinien powstawać w
osobnym pliku)
Netbeans 7.0
Maven 2.2.1
Hudson
o Na potrzeby systemu ciaglej integracji został udostepniony serwer:
snow.iiar.pwr.wroc.pl:8080/hudson (156.17.40.149)
Java 1.6, JSF, Java EE 6.0
SVN :http://gromit.iiar.pwr.wroc.pl/p_inf/SVN.html
Redmine (http://snow.iiar.pwr.wroc.pl:4000): http://gromit.iiar.pwr.wroc.pl/p_inf/redmine.html
JUnit 4: http://gromit.iiar.pwr.wroc.pl/p_inf/JUnit.html
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 w Redmine. Liczba punktów
zależy głównie od liczby wykonanych zagadnień i ich znaczenia w projekcie. Waga wykonanych zgadanień
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