Rubik s Manager - SDP

Transkrypt

1 Rubik s Manager - SDP Sebastian Chojniak, Łukasz Krupa, Grzegorz Łuczyna 27 maja

2 Spis treści 1 Wprowadzenie Cel Definicje Załączniki Omówienie reszty dokumentu Omówienie projektu Cel, zakres i objectives projektu Produkty projektu Procedura zmian w planie projektu Organizacja projektu Struktura organizacyjna Kontakty zewnętrzne Role i zadania Analiza punktów funkcyjnych Nieunormowana wartość punktów funkcyjnych Całkowity stopień wpływu Unormowana wartość punktów funkcyjnych Zarzadzanie projektem Plan projektu Iteracje projektu Wydania Harmonogram projektu (dwóch pierwszych iteracji) Zasoby Budżet Nadzór i kontrola projektu Plan zarządzania wymaganiami Plan zarządzania harmonogramem Plan kontroli jakości Plan raportów Plany procesów technicznych Programowanie Metody, narzędzia i stosowane technologie Plan infrastruktury Plan akceptacji produktu

3 7 Plany pomocnicze Plan zarządzania zmianami Plan oceny Plan dokumentacji Plan zapewnienia jakości Plan rozwiązywania problemów Plan ulepszania Historia zmian 17 3

4 1 Wprowadzenie 1.1 Cel Dokument "Plan projektu"ma na celu opisać czasowy i osobowy podział pracy nad projektem Rubik s Magnager. 1.2 Definicje RM - skrót od nazwy produktu, tj. Rubik s Manager, kostka Rubika - łamigłówka logiczna w postaci sześcianu o ruchomych ścianach; także potoczna nazwa na pochodne tej łamigłówki, speedcubing - sport polegający na układaniu kostki Rubika na czas, World Cubing Association - organizacja ustalająca regulamin organizowania zawodów w speedcubingu, PM - project manager. 1.3 Załaczniki Wizja Przypadki użycia SAD 1.4 Omówienie reszty dokumentu Dokument zawiera listę osób biorących udział w projekcie, przydział osób do zadań, częściowy terminarz realizacji zadań, plan nadzoru i kontroli nad projektem, analizę punktów funkcyjnych projektu, wskazania narzędzi, technologii i metodologii wykorzystywanych w projekcie. 4

5 2 Omówienie projektu 2.1 Cel, zakres i objectives projektu Projekt ma na celu stworzenie programu Rubik s Manager umożliwiającego przeprowadzanie treningów w speedcubingu w różnych trybach i wariantach wraz z przechowywaniem rezultatów, generowaniem statystyk. RM będzie zawierał narzędzia pomocne przy doskonaleniu stosowanych metod układania. Pozwoli na przeprowadzanie turniejów między użytkownikami z całego świata, udostępni transmisje i rankingi dla zainteresowanych. Będzie to także kompletny system potrzebny do zorganizowania lokalnych zawodów. Możliwa będzie ponadto obsługa przydatnych urządzeń peryferyjnych wykorzystywanych w speedcubingu. 2.2 Produkty projektu Podczas realizacji projektu wytworzono dokumenty: Wizja Model przypadków użycia Model dziedziny SAD SDP Plan testów Prezentacja projektu Zaimplementowane zostaną programy Rubik s Manager Personal Oprogramowanie serwera Rubik s Manager 2.3 Procedura zmian w planie projektu Wersja SDP Data Komentarz Wersja wstępna 5 II 2007 Początek projektu Wersja robocza 1 III 2007 Modyfikacje dotyczące dziedziny Wersja robocza mk.2 23 III 2007 Zmiany w składzie zespołu Wersja ostateczna 24 V 2007 Zmiany w terminie realizacji projektu 5

6 3 Organizacja projektu 3.1 Struktura organizacyjna Członkowie zepołu. Personalia Sebastian Chojniak Łukasz Krupa Grzegorz Łuczyna Funkcja architekt, programista analityk, programista PM, programista 3.2 Kontakty zewnętrzne Zespół kontaktuje się z Jackiem Sroką, prowadzącym zajęcia z Inżynierii Oprogramowania, który kontroluje projekt i udziela konsultacji w istotnych kwestiach projektowych i technicznych. Ponadto zespół utrzymuje kontakt z przedstawicielem World Cubing Association. Rozmowy dotyczą użyteczności i funkcjonalności programu RM. 3.3 Role i zadania Rola PM Zadania nadzór nad projektem zatwierdzanie zmian w projekcie kontrola terminowości pracy analityk analiza rynku i ryzyka w projekcie uzyskiwanie sugerowanych wymagań od speedcuberów projektowanie dokumentów architekt stworzenie abstrakcyjnego modelu systemu stworzenie projektu systemu 6

7 Rola programista Zadania implementacja projektu według modelu architektów informowanie architektów o problemach w projekcie tester wykrywanie błędów w oprogramowaniu 7

8 4 Analiza punktów funkcyjnych 4.1 Nieunormowana wartość punktów funkcyjnych Internal Logical File trening speedcubera - pomiar czasów (low: 7), trening speedcubera - poprawa techniki (high: 15), organizowanie zawodów internetowych (average: 10). External Logical File uczestniczenie w zawodach internetowych (average: 7), wysyłanie wyników na centralny serwer (low: 5), przeglądanie listy zawodów (low: 5), generowanie algorytmów rozwiązujących (average: 7). External Input obsługa stackmaty (average: 4), wprowadzanie wyników zawodów stacjonarnych (low: 3). External Output przeglądanie bazy wiedzy (low: 4), kibicowanie w zawodach internetowych (average: 5), symulator kostki rubika (average: 5). External Inquiry generowanie algorytmów mieszających (low: 3). UFPC = 80 8

9 4.2 Całkowity stopień wpływu Data Communications: 4 Distributed Data Processing: 3 Performance: 1 Heavily Used Configuration: 1 Transaction Rate: 2 Online Data Entry: 3 End-User Efficiency: 1 Online Update: 1 Complex Processing: 0 Reusability: 0 Installation Ease: 2 Operational Ease: 3 Multiple Sites: 1 Facilitate Change: 1 TDI = Unormowana wartość punktów funkcyjnych VAF = * TDI = 0.88 AFPC = UFPC * VAF =

10 5 Zarzadzanie projektem 5.1 Plan projektu Iteracje projektu Analiza Analiza jest pierwszą fazą projektu i w dużej mierze od niej zależy powodzenie całego projektu. Podstawowym zadaniem jest zebranie od klienta (fizycznie: osób zainteresowanych używaniem wytworzonego systemu) wymagań funkcjonalnych oraz oczekiwań w stosunku do stosowanych rozwiązań. Istotne jest dokładne sprecyzowanie ram systemu. Dodatkowo podczas analizy wnikliwie musi zostać prześledzona demografia rynku odbiorców oraz istniejące już systemy o podobnym zastosowaniu. Projektowanie W tej fazie powinien powstać model dający możliwie najlepszy pogląd o architekturze tworzonego systemu. Podjęte muszą zostać decyzje na temat wykorzystywanych technologii i rozwiązań (które nie będą implementowane przez programistów zaangażowanych w projekt). Iteracja projektu, jaką jest projektowanie zachodzi na fazę analizy - model jest na bieżąco rozwijany i poprawiany po sprecyzowaniu nowych wymagań funkcjonalnych. W każdym momencie tworzenia modelu musi być wyraźnie wskazany podział systemu na warstwy. Po uzyskaniu klarownego modelu tworzony jest wstępny plan testów dla systemu uwzględniający zarówno testy funkcjonalności, jak i wydajności. Implementacja Programiści implementują system zgodnie z uzyskanym w wyniku projektowania modelem. Nadzór nad zgodnością i spójnością modułów sprawuje PM w porozumieniu z architektami. Równocześnie weryfikowana jest spełnialność wymagań stawianych przez klienta. Po zaimplementowaniu spójnego fragmentu systemu dokonywane są wstępne testy tegoż fragmentu. Wymagania stawiane wobec programistów obejmują: pisanie kodu zgodnie z przyjętym standardem oraz dokumentowanie pisanego kodu. Testowanie Oprócz wstępnych i częściowych testów tworzonych modułów planowane jest wykonanie testów całościowych. Ich opis i analiza jest początkowo tworzona w fazie projektowania i rozwijana po zakończeniu fazy implementacji. Testowanie obejmuje ostateczną weryfikację i walidację systemu. Wdrażanie i aktualizacje Po zakończeniu fazy testowania następuje wdrażanie systemu, czyli odbiór finalnego produktu przez klienta. Po tej fazie nie jest planowana przebudowa systemu. Są natomiast planowane regularne aktualizacje mające zapewnić zgodność ze zmianami w regulaminach na których opiera się projekt Rubik s Manager. Planowane jest także rozbudowywanie systemu w miarę rosnących potrzeb użytkowników. 10

11 5.1.2 Wydania Planowane jest regularne udostępnianie wersji beta systemu, nim jeszcze powstanie finalna wersja. Użytkownicy tychże wersji uzyskają możliwość zgłaszania błędów i sugestii dotyczących funkcjonowania. Po wdrożeniu finalnej wersji projektu udostępniane będą wspomniane wcześniej aktualizacje. 11

12 5.1.3 Harmonogram projektu (dwóch pierwszych iteracji) 12

13 5.1.4 Zasoby Plan zatrudniania pracowników Nie przewiduje się zatrudniania pracowników innych niż wymienieni w składzie zespołu we wcześniejszej części tegoż dokumentu. Plan szkoleń Plan szkoleń Projekt Data zakończenia Latex-podstawy 12 II 2007 SVN - użytkowanie 26 II 2007 UML - podstawowe diagramy 14 III 2007 Podstawowe wzorce projektowe 7 V Budżet Środki budżetowe w całości pochodzą z własnych wkładów członków zespołu realizującego projekt Rubik s Manager. 13

14 5.2 Nadzór i kontrola projektu Plan zarzadzania wymaganiami Wymagania projektu zostały sprecyzowane na etapie analizy systemu i są opisane w stosownych dokumentach. Nad zgodnością tworzonych fragmentów systemu z wymaganiami czuwa PM i architekci. Wszelkie zmiany wymagań (nie zwiększające zakresu projektu) są konsultowane z analitykami i architektami. Po spisaniu stosownego dokumentu o zmianach jest on udostępniany (w trybie: do obowiązkowego zapoznania się) wszystkim osobom zaangażowanym w projekt Plan zarzadzania harmonogramem Nad czasowym rozłożeniem projektu czuwa PM. W szczególności jest on odpowiedzialny za wykonywanie zaplanowanych elementów na czas. Wprowadza ponadto korekty w harmonogramie w przypadku opóźnionego lub przyspieszonego zakończenia niektórych etapów. Aktualnie obowiązująca wersja harmonogramu jest stale dostępna dla wszystkich osób zaangażowanych w realizację projektu Plan kontroli jakości Regularne prezentacje zaimplementowanych elementów systemu reprezentantom środowiska speedcuberów. Dostosowanie projektu do uwag speedcuberów, o ile nie zmienia to jego zakresu. Testowanie komponentów systemu, zgodnie z dokumentem "Plan testów". Weryfikowanie zachowania standardów kodowania i prowadzonej dokumentacji Plan raportów Wszelkie zmiany w projekcie dokumentowane są w formie raportów, które dokładnie uwzględniają ich zakres. Osoby zaangażowane w realizację projektu, dla pracy których zmiany te mają znaczenie, pisemnie potwierdzają zapoznanie się z raportem. Dodatkowo cały zespół odpowiedzialny za realizację projektu Rubik s Manager spotyka się regularnie - co tydzień. Podjęte na spotkaniu decyzje zostają spisane również w formie raportu. Wszystkie raporty dostępne są przez cały okres realizacji projektu do wglądu dla wszystkich członków zespołu. Nie dotyczy to jednak raportów dotyczących budżetu, które dostępne są wyłącznie dla osób odpowiedzialnych za zarządzanie projektem. 14

15 6 Plany procesów technicznych 6.1 Programowanie System podzielony jest na moduły, których programowanie przebiega niezależnie. Zespół programistów ustala sposób komunikacji między modułami, wybrane ustalenia są dokumentowane. Programiści dzielą miedzy sobą zadania, które wykonywać będą samodzielnie. 6.2 Metody, narzędzia i stosowane technologie Metody: RUP (Rational Unified Process) UML (Unified Modeling Language) Narzędzia: SVN - system kontroli wersji Violet - narzędzie od modelowania UML Umlet - narzędzie do modelowania UML Umbrello - narzędzie do modelowania UML JMeter - program do przeprowadzania testów GCC - kompilator języka C++ GDB - debugger Gimp - narzędzie do tworzenia szaty graficznej Technologie: PostgreSQL - baza danych Open GL J2EE Sopcast - narzędzie do transmisji video Adobe Flex 2 15

16 6.3 Plan infrastruktury Osoby biorące udział w projekcie korzystają z własnego sprzętu komputerowego. Tworzenie oprogramowania przebiega w warunkach domowych. Niezbędne informacje przekazywane są miedzy członkami zespołu za pomocą komunikatorów internetowych. Na cele projektu przewidziany jest zakup licencji na niezbędne narzędzia. Co tygodniowo zespół spotyka się by omówić co zrobił i jakie są plany na następne działania. Miejsce spotkania ustalane jest na dwa dni przed spotkaniem i nie jest statycznie określone. 6.4 Plan akceptacji produktu Ukończona pierwsza kompletna wersja systemu przechodzi przygotowane testy. Produkt udostępniany jest kilku wybranym zainteresowanym osobom, w celu otrzymania opinii na temat systemu. W przypadku braku krytycznych niedociągnięć uznaje się produkt za gotowy do dystrybucji. 16

17 7 Plany pomocnicze 7.1 Plan zarzadzania zmianami Wszelkie zmiany w projekcie będą odnotowywane w specjalnym rejestrze. Wraz z wprowadzona zmianą podany będzie powód jej wprowadzenia. 7.2 Plan oceny Gotowe komponenty przejdą szereg testów, na ich podstawie ustalona zostanie ocena ich jakości. W przypadku wystąpienia błędów uniemożliwiających poprawna prace całości komponent dostaje ocenę negatywną i wraca do fazy implementacji. 7.3 Plan dokumentacji Równolegle do tworzenia systemu wykonywana będzie dokumentacja wykonanych prac. Główny nacisk kładziony będzie na opisanie sposobu realizacji poszczególnych komponentow, a także wybranego sposobu komunikacji z innymi komponentami. 7.4 Plan zapewnienia jakości Jeśli istnieje taka możliwość korzystamy tylko ze sprawdzonych standardów. Ustalamy jednolity styl pisanego kodu. Każda funkcja poszczególnego komponentu jest testowana. Nieoczywiste fragmenty kodu zawierają stosowny komentarz umożliwiający szybkie zrozumienie zasady działania (łatwość wychwycenia błędu i modyfikacji kodu). 7.5 Plan rozwiazywania problemów W razie wystąpienia problemu praca nad danym zagadnieniem jest wstrzymywana, osoba przechodzi do innych zadań, problem przedstawiany jest na najbliższym spotkaniu zespołu i wspólnie dyskutowany. Po przedstawieniu potencjalnych zalet i wad wybierane jest rozwiązanie w sposób demokratyczny. 7.6 Plan ulepszania Poszczególne moduły systemu przedstawiane potencjalnym użytkownikom. Zbierane są opinie na temat działających funkcjonalności. Użytkownicy proponują nowe funkcjonalności, których ich brakuje. Po wydaniu pierwszej oficjalnej wersji systemu planowane są wersje kolejne w postaci kompletnych systemów, wraz z uaktualnieniami wersji poprzednich (w skrajnych przypadkach uaktualnienie instaluje cały system zostawiając ustawienia i dane personalne użytkowników). 17

18 8 Historia zmian Data Osoba Opis zmian Łukasz Krupa Utworzono dokument Łukasz Krupa Rozwinięto podpunkty Grzegorz Łuczyna Wykonano analizę punktów funkcyjnych Sebastian Chojniak Wprowadzono plany procesów technicznych Łukasz Krupa Wstawiono diagram Gantta Grzegorz Łuczyna Wprowadzono zarządzanie projektem Sebastian Chojniak Wprowadzono plany pomocnicze Grzegorz Łuczyna Poprawiono diagram Gantta Sebastian Chojniak, Złożono dokument Łukasz Krupa, Grzegorz Łuczyna 18