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

Transkrypt

1 Projektowanie oprogramowania Termin zajęć: czwartek, sala L2.6, C , Na podstawie materiału ze strony Przebieg realizacji projektu (tabela 1) Nr tygodnia Opis realizacji dla czterech zespołów (4 przypadki użycia) 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 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 ) oraz systemu ProjectPortfolio (grupa ) 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 - 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 Liczba punktów (do oceny) 3-5 Zadania kierownika zespołów (Scrum Master)

2 2 Daily Scrum 3 Daily Scrum 4 Daily Scrum 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 Przedstawienie wyników prac z 1 tygodnia Projekt PU (wersja początkowa): diagram klas, diagramy sekwencji, diagramy aktywności 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 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 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 wykonanego modelu do implementacji 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 3-5 Integrowanie projektów PU opracowanych przez diagramu przypadków użycia, eliminacja redundancji w projekcie, Analiza raportów inspektorów, ocena wpływu zidentyfikowanych problemów na przebieg projektu 4-10 Integrowanie projektów PU opracowanych przez diagramu klas, eliminacja redundancji w projekcie, Analiza raportów inspektorów, ocena wpływu zidentyfikowanych problemów na przebieg projektu 3-5 Włączenie się do zespołów wykonawców i wspomaganie prac.

3 5 Daily Scrum 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 wykonanego oprogramowanie na podstawie modelu wykonanego w 1-3 tygodniach 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 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 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 (ewentualnie diagramu sekwencji i diagramu stanów). Każda grupa opracowuje przypadki użycia 3-5 Integracja 4 projektów typu EE (wg podanego tutorialu), dostarczonych po zakończeniu 5 tygodnia etap 1-y Ocena 3-5

4 7 Daily Scrum jako 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 Przedstawienie wyników prac z 6 tygodnia Projekt PU (wersja końcowa): diagram klas, diagramy sekwencji, diagramy aktywności 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 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) diagramy sekwencji, diagramy aktywności 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 wykonanego modelu do implementacji 9 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 koncepcja i kod testów jednostkowych i 3-5 Integrowanie PU opracowanych przez diagramu PU 4-10 Integrowanie projektów PU opracowanych przez diagramu klas, eliminacja redundancji w projekcie, Analiza raportów inspektorów, ocena wpływu zidentyfikowanych problemów na przebieg projektu 3-5 Włączenie się do zespołów wykonawców i wspomaganie prac Integracja 4 projektów typu EE (wg podanego tutorialu) etap 2-i Wykonanie warstwy integracji opartej na technologii JPA etap 1-y Wykonanie warstwy integracji opartej na technologii JPA etap 2-i

5 10 Daily Scrum 11 3 Sprint review meeting & Sprint planning meeting (90 min) 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 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 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 wykonanej implementacji do integracji przez wydzielony zespół Scenariusz dla trzech zespołów 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.4-10 Kontrola przyjętego standardu formularzy, Wykonanie testów projektu typu EE Scenariusz dla jednego zespołu 5-10 Integracja 3 projektów, typu EE (wg podanego tutorialu) dostarczonych w 10 tygodniu, etap 1-y 4-10 Ocena 5-10

6 12 Daily Scrum 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 11-tygodnia wynik prac umieszczane są w repozytorium java,net i są oceniane przez prowadzących zajęcia Przedstawienie wyników prac z 11 tygodnia Projekt PU (wersja końcowa): diagram klas (integracja przez Scrum Master diagramów klas z 11 tygodnia) diagramy sekwencji, diagramy aktywności 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 wykonanego modelu do implementacji 3-5 Integrowanie PU opracowanych przez diagramu PU Integrowanie projektów PU opracowanych przez 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 Daily Scrum 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 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 2-5 Włączenie się do zespołów wykonawców i wspomaganie prac Rozwój warstwy integracji opartej na technologii JPA 2-5

7 14 Daily Scrum 15 Sprint review meeting & Sprint retrospective meeting (1.5h) nieprawidłowych wartości metryk (w szczególności RFC, LCOM3) powtórzenie testów jednostkowych w przypadku refakatoryzacji Podczas 13-tygodnia wyniki prac umieszczane są w wykonanego oprogramowanie na podstawie modelu wykonanego w tygodni 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 wykonanej implementacji do integracji przez wydzielony zespół Podsumowanie 4-10 Kontrola przyjętego standardu formularzy, Wykonanie testów projektu typu EE 4-10 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 - krótkie spotkanie dotyczące aktualnego statusu projektu, w trakcie którego następuje synchronizacja 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? o Co zespół planuje zrobić do następnego Daily Scrum?

8 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 java.net. Pewne zadania zostały wyspecyfikowane w tabeli 1. Sprint - ograniczona czasowo do 4-5 tygodni iteracja (patrz Tab. Przebieg realizacji projektu) w trakcie której zespoł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 java.net 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, 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 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 java.net 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 osoby. Podział na 4-6-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 podzadań w java.net), osoba kontaktowa w komunikacji między podgrupami, równocześnie pełni rolę programisty / modelarza

9 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 Lista kontrolna opisów PU Lista kontrolna diagramów klas Lista kontrolna diagramów sekwencji Lista kontrolna diagramów stanów Szablon raportu inspektora 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. Funkcja cykliczna, kadencja trwa 4-5 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 java.net, w szczególności ma uprawnienia do zmieniania osoby przypisanej do błędu. Jak wybrać kierownika oraz inspektora 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 o raport inspektora (można generowac z Java.net 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

10 o o diagram PU 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 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: SonarQube do oceny jakości oprogramowania: Maven SVN : JUnit 4: FitNesse, Selenium lub inne narzędzie do testów funkcjonalnych: 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 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, , , , , Literatura: