Projektowanie oprogramowania. Termin zajęć: poniedziałek, a podstawie materiału ze strony.

Transkrypt

1 Projektowanie oprogramowania Termin zajęć: poniedziałek, a podstawie materiału ze strony Przebieg realizacji projektu (tabela 1) Nr tygo dnia Spotkanie Uwagi dotyczące realizacji Zespóły składające się z trzech studentów- przystapienie do kolejnego Daily Scrum po zaliczeniu poprzedzajacego Daily Scrum 3 Daily Scrum 4 Daily Scrum 1. Zajęcia organizacyjne ( podział na grupy, przydzielenie ról projektowych, uzyskanie dostępu do wymaganych narzędzi) 2. 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. 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 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 kodu Liczba punktów (do oceny) Zadania kierownika zespołów (Scrum Master) Sporządzenie dokumentacji p.2 i 3 (edytor tekstu itp) 3-5 Integrowanie PU opracowanych przez prupy projektowe w postaci diagramu PU 4-10 Integrowanie projektów PU opracowanych przez prupy projektowe w postaci jednego diagramu klas, eliminacja redundancji w projekcie, Analiza raportów inspektorów, ocena wpływu zidnetyfikowanych problemów na przebieg projektu 3-5 Integrowanie kodu źródłowego: tworzenie wieloużywalnych pakietów (bibliotek)

2 5 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 kod warstwy prezentacji i klienta (technologia JSF), koncepcja i kod testów akceptacyjnych (Selenium lub recznych), 4-10 Kontrola przyjętego standardu formularzy, Daily Scrum Wszystkie grupy Rozbudowa diagramu PU ( Backlog): planowanie nowych PU, 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 można wykonać za pomocą diagramu aktywności 3-5 Podobnie jak w sprincie 1 8 Daily Scrum 9 Daily Scrum 10 3 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 Podobnie jak w sprincie1

3 11 Daily Scrum 12 Daily Scrum 13 Daily Scrum 14 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 - 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? o Co zespół planuje zrobić do następnego Daily Scrum? 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 Backlog w trakcie 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. - 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ść. 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 meeting. meeting - 70 minutowe spotkanie rozpoczynające każdy sprint. W trakcie spotkania definiuje się Backlog. W spotkaniu biorą udział Product Owner, Scrum Master, administrator i przynajmniej jeden przedstawiciel każdej grupy projektowej. retrospective meeting - spotkanie podsumowujące projekt. W trakcie spotkania powinna odbyć się dyskusja dotycząca możliwości usprawnienia stosowanego procesu wytwarzania oprogramowania. 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 meeting, w trakcie którego wybierana są zagadnienia do zrealizowania w

4 trakcie sprintu, a kończy się spotkaniem 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 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 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 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 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

5 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 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 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 8.1 Community Edition (każdy diagram powinien powstawać w osobnym pliku) Netbeans 7.0 Maven Hudson o Na potrzeby systemu ciaglej integracji został udostepniony serwer: snow.iiar.pwr.wroc.pl:8080/hudson ( ) Java 1.6, JSF, Java EE 6.0 SVN : Redmine ( 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 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, , , , , 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: