Topór Światowida Software Architecture Document Maciej Pawlisz Łukasz Polak Oskar Skibski Jakub Światły 30 maja 2007r. 1
Spis treści 1 Wprowadzenie 4 1.1 Cel.......................................... 4 1.2 Zakres........................................ 4 1.3 Definicje....................................... 4 1.4 Załączniki...................................... 4 1.5 Omówienie reszty dokumentu........................... 4 2 Omówienie projektu 5 2.1 Cel, zakres i objectives projektu......................... 5 2.2 Założenia i zależności................................ 5 2.3 Produkty projektu.................................. 5 3 Organizacja projektu 5 3.1 Struktura organizacyjna............................... 5 3.2 Kontakty zewnętrzne................................ 6 3.3 Role i zadania.................................... 6 4 Punkty funkcyjne 6 4.1 Internal Logical File................................ 6 4.2 External Interface File............................... 7 4.3 External Input.................................... 7 4.4 External Output................................... 8 4.5 External Inquiry................................... 8 4.6 Ogólne wymagania................................. 8 4.7 Adjusted function point count........................... 9 5 Zarzadzanie projektem 9 5.1 Oszacowania.................................... 9 5.2 Plan Projektu.................................... 10 5.2.1 Plan faz i harmonogram projektu...................... 10 5.2.2 Kamienie milowe.............................. 11 5.2.3 Diagramy Gantta- faza projektowa..................... 12 5.2.4 Diagramy Gantta- faza implementacyjna................. 14 5.2.5 Zasoby................................... 17 5.2.6 Budżet................................... 17 5.3 Nadzór i kontrola projektu............................. 17 5.3.1 Plan zarządzania wymaganiami...................... 17 5.3.2 Plan zarządzania harmonogramem..................... 18 5.3.3 Plan kontroli budżetu............................ 18 5.3.4 Plan kontroli jakości............................ 18 5.4 Plan zarządzania ryzykiem............................. 18 2
5.5 Plan zamknięcia projektu.............................. 19 6 Plany procesów technicznych 19 6.1 Metody, narzędzia i stosowane technologie.................... 19 7 Historia zmian 20 3
1 Wprowadzenie 1.1 Cel Celem tego dokumentu jest przedstawienie planu organizacji prac przy rozwoju gry "Topór Światowida" 1.2 Zakres W dokumencie tym opisano poszczególne etapy przeprowadzania prac nad projektem, wraz z czasami ich wykonania, ludźmi odpowiedzialnymi za nie, a także dodatkowymi środkami potrzebnymi do wykonania prac nad nimi. Są w nim również informacje istotne inne istotne informacje potrzebne do pracy nad Toporem Światowida 1.3 Definicje NPC (Non-Player Character) - postać w grze sterowana przez komputer, mogą to być zarówno wrogowie automatycznie atakujący gracza jak i kupcy oferujący swoje towary. MG (Mistrz Gry) - postać opiekująca się grą, graczami. Ma możliwość tworzenia nowych elementów świata, modyfikację starych, karanie graczy. 1.4 Załaczniki Wizja Model przypadków użycia Software Architecture Document 1.5 Omówienie reszty dokumentu Dalsza część dokumentu podzielona jest na następujące części: omówienie projektu punkty funkcyjne oszacowania - w skład których wchodzą plany projektu, wykorzystania zasobów, kontroli ryzyka oraz zamknięcia projektu plany procesów technicznych - w skład których wchodzi plan zastosowanych technologii 4
2 Omówienie projektu 2.1 Cel, zakres i objectives projektu Celem projektu jest stworzenie aplikacji klienckiej umożliwiającej grę w Topór Światowida oraz aplikacji która po stronie serwera będzie obsługiwać komunikację między graczami. Gra ma głównie dostarczać rozrywki, jednak w mniejszym stopniu realizowane mają być także cele edukacyjne. 2.2 Założenia i zależności Jedynymi wykonawcami projektu jest 4 studentów II roku Uniwersytetu Warszawskiego (więcej punkt 3. tego dokumentu) Sprzęt oraz oprogramowanie każdy z programistów zapewni sobie we własnym zakresie. Budżet przedsięwzięcia jest zerowy. Aplikacja będzie wykonana od początku do końca przez programistów pracujących nad nią, nie zostaną użyte np. gotowe silniki do gier RPG jakie można spotkać na rynku. 2.3 Produkty projektu 12.03.07 - Wizja 19.03.07 - Model przypadków użycia 03.04.07 - Model dziedziny 17.04.07 - Model przypadków użycia z systemowym diagramem przebiegu i kontraktami 08.05.07 - Warstwy 22.05.07 - SAD 29.05.07 - SDP 05.06.07 - Plan testów 3 Organizacja projektu 3.1 Struktura organizacyjna Cały zespół pracujący nad projektem tworzy grupa 4 studentów: Maciej Pawlisz, Łukasz Polak, Oskar Skibski, Jakub Światły. 5
3.2 Kontakty zewnętrzne Osobą nadzorującą projekt jest mgr Jacek Sroka. Ponadto możliwe są ewentualne kontakty z historykami z Uniwersytetu Warszawskiego w celu zapewnienia dokładności historycznej. 3.3 Role i zadania Kierownik: Oskar Skibski Zadania: nadzór nad projektem, rozdzielanie pracy oraz odpowiedzialność za projekt Członkowie grupy programistycznej: Maciej Pawlisz, Łukasz Polak, Oskar Skibski oraz Jakub Światły Zadania: tworzenie aplikacji Historyk: Jakub Światły Zadania: kontakty zewnętrzne, dopilnowanie dokładności historycznej Główny projektant: Łukasz Polak Zadania: stworzenie projektu aplikacji Kierownik testów: Maciej Pawlisz Zadania: nadzór nad przeprowadzanymi testami, wyeliminowanie błedów z aplikacji 4 Punkty funkcyjne 4.1 Internal Logical File Gracze (Low) - informacje o koncie gracza, login, hasło, przypisane mu postacie. Postacie (Average) - szczegółowe informacje o postaci - jakie umiejętności i statystyki posiada, przedmioty, gdzie znajduje się obecnie na mapie Elementy świata gry (Average) - informacje o nieożywionych częściach świata gry, takich jak surowce, budynki, drzewa, meble, itp. Mapa (Low) - jak kształtuje się teren w świecie gry, gdzie jest trawa, gdzie kamień, itp. NPC (Average) - informacje o NPC, statystyki, umiejętności, przedmioty, sposób zachowania, miejsce na mapie Przedmioty (Average) - statystyki bazowe wszystkich przedmiotów, a także możliwe modyfikatory które mogą posiadać, zmieniające ich atrybuty Umiejętności (Low) - zbiór umiejętności wraz z ich działaniem, statystykami 6
Plemiona (Low) - informacje o poszczególnych plemionach - członkowie, stosunek do innych plemion Drużyny (Low) - informacje o poszczególnych drużynach - członkowie, dla kogo są wrodzy 4.2 External Interface File Brak 4.3 External Input Poruszanie postaci (Low) - zmiana miejsce na mapie danej postaci Użycie umiejętności (Low) - użycie przez postać danej umiejętności której jest wyuczona Manipulacja przedmiotami (Low) - użycie przedmiotu, schowanie do plecaka, wyrzucenie Zmiana ustawień konta gracza (Low) - zmiana e-maila powiązanego z kontem, hasła Zmiana przynależności postaci do plemienia (Low) - odejście lub przyłączenie się do danego plemienia Dołączanie do/opuszczanie drużyny (Low) - odejście lub przyłączenie się do danej drużyny Modyfikacja współczynników postaci (Low) - po zdobyciu poziomu, modyfikacja statystyk bądź dodanie umiejętności/modyfikacja poziomu już istniejącej Modyfikacja bazy przedmiotów (Low) - umiejętność MG, dodawanie lub modyfikacja już istniejących przedmiotów bądź ich modyfikatorów Modyfikacja elementów świata (Low) - umiejętność MG i w mniejszym stopniu ludzi, dodawanie lub modyfikacja już istniejących elementów świata gry, podchodzi pod to również budowa budynków przez graczy Modyfikacja mapy świata (Low) - umiejętność MG, dodawanie lub modyfikacja obecnej mapy świata Modyfikacja bazy umiejętności (Low) - umiejętność MG, dodawanie lub modyfikacja danej umiejętności dostępnej w grze 7
4.4 External Output Wyświetlanie ekwipunku postaci (Low) - wyświetlenie zawartości plecaka oraz rzeczy które postać ma założone/używa Wyświetlanie statystyk danego przedmiotu (Low) - wyświetlenie informacji o danym przedmiocie po aplikacji wszystkich modyfikatorów jakie posiada Wyświetlanie statystyk postaci (Low) - wyświetlenie informacji o danej postaci, statystyk, umiejętności, wziąwszy pod uwagę wszystkie możliwe modyfikatory, dawane przez otoczenie gracza, przedmioty, itp. Informacje o danym NPC (Low) - analogicznie do wyświetlania statystyk postaci Obliczanie skuteczności użycia umiejętności (Low) - na podstawie statystyk postaci oraz umiejętności, podanie jaki skutek przyniosło użycie danej umiejętności, w jakim stopniu się ono powiodło Wyświetlenie położenia postaci (High) - wyświetlenie gracza oraz jego otoczenia - innych graczy będących w pobliżu, elementów świata gry, mapy, itp. 4.5 External Inquiry Informacje o graczu (Low) - informacje o graczu o danym loginie Informacje o umiejętności (Low) - informacje o umiejętności o danej nazwie Informacje o typie przedmiotu (Low) - informacje o przedmiocie bez modyfikatorów Informacje o plemieniu (Low) - informacje o danym plemieniu o podanej nazwie Informacje o drużynie (Low) - informacje o drużynie której której przewodzi dana postać 4.6 Ogólne wymagania Data communications (4) - ponieważ cała gra odbywa się przez internet komunikacja danych jest bardzo ważnym aspektem Distributed data processing (4) - w większoście przypadków wymagana jest komunikacja poszczególnych komponentów programu Performance (4) - ważne jest, aby gra przebiegała sprawnie i bez żadnych spowolnień, stąd konieczna będzie analiza wydajności w celu jej zmaksymalizowania Heavily used configuration (0) - serwer aplikacji będzie postawiony na odrębnym serwerze, przeznaczonym tylko dla niego 8
Transaction rate (5) - ponieważ w grze będzie brać udział do tysiąca graczy, z których każdy będzie cały czas wykonywać jakieś akcje wymagające komunikacji z serwerem, stąd punkt ten jest bardzo ważny dla całego systemu On-Line data entry (5) - praktycznie cała wymiana danych będzie odbywać się w interakcji z użytkownikiem End-user efficiency (3) - chcemy, aby system był jak najprostszy w użyciu i dający użytkownikowi jak największe możliwości, lecz bez żadnych założeń potrzebnych podczas projektowania On-Line update (4) - w zasadzie cała treść gry będzie uaktualniana on-line, oraz będą potrzebne pewne mechanizmy do tworzenia kopii zapasowych tej treści Complex processing (0) - nie potrzebne będzie wykonywanie skomplikowane przetwarzanie danych Reusability (0) - tworzona aplikacja nie będzie nigdzie wykorzystywana ponownie Installation ease (1) - będziemy starać się aby instalacja była możliwie najprostsza, lecz nie robimy żadnych szczególnych założeń w tym kierunku Operational ease (2) - serwer powinien działać przy jak najmniejszym udziale człowieka, jednak do operacji uruchamiania i odtwarzania danych będzie potrzebna jego interwencja, tworzenie kopii zapasowych będzie zautomatyzowane Multiple sites (0) - aplikacja tworzona dla pojedynczej instalacji i korzystania Facilitate change (0) - nie robimy żadnych założeń co do tego jak łatwo będzie modyfikować strukturę logiczną projektu 4.7 Adjusted function point count Miara adjusted function point count dla projektu wynosi 150 * 0,97 czyli 145,5. 5 Zarzadzanie projektem 5.1 Oszacowania planowany czas ukończenia prac nad dokumantacją - początek czerwca 2007 planowany czas ukończenia prac nad projektem - początek czerwca 2008 9
5.2 Plan Projektu 5.2.1 Plan faz i harmonogram projektu 10
Nazwa Rozpoczęcie Zakończenie Szczegóły Analiza problemu i sprecyzowanie 26.02.2007 28.03.2007 Wizja, Model przy- wymagań biznesowych padków użycia Projektowanie aplikacji 28.03.2007 25.05.2007 Model dziedziny, SAD Planowanie prac nad projektem 25.05.2007 14.06.2007 SDP, plan testów Implementacja podstawowych 1.10.2007 27.12.2007 podstawowa grafika, modułów komunikacja klient- serwer, poruszanie się, kilka obiektów ze świata gry, Stabilna wersja 27.12.2007 8.01.2008 działające wyżej wymienione moduły Implementacja podstawowych 13.11.2007 8.02.2008 umiejętności, wy- przypadków użycia miana towarów, komunikacja między graczami, obsługa plemion Stabilna wersja ALPHA 8.02.2008 19.02.2008 Zaimplementowane podstawowe, wyżej wymienione przypadki użycia Implementacja pozostałych 8.02.2008 1.04.2008 grafika, pozostałe ważnych modułów przypadki użycia, podstawowy wygląd i przedmioty świata gry Stabilna wersja BETA gry 1.04.2008 2.04.2008 gra z zaimplementowanymi wszystkimi funkcjonalnościami Testy grywalności 1.04.2008 19.05.2008 testy grywalności, testy poprawności, wodotryski, bezpieczeństwo Ukańczanie gry 19.05.2008 09.06.2008 integracja wszystkich modułów, poprawianie błędów Wersja ostateczna gry 09.06.2008 Gra wpełni działająca 5.2.2 Kamienie milowe Prezentacja z analizy i projektowania 11
Prezentacja z planowania i projektowania Stabilna wersja ukazująca podstawowy wygląd Wersja ALPHA umożliwiająca interakcje między graczami Wersja BETA zapewniająca wszystkie funkcjonalności Wersja ostateczna gry 5.2.3 Diagramy Gantta- faza projektowa Rozplanowanie zadań 12
13
Podział prac w zespole 5.2.4 Diagramy Gantta- faza implementacyjna Rozplanowanie zadań 14
15
Podział prac w zespole 16
5.2.5 Zasoby Plan zatrudnienia Przez wzgląd na charakter projektu (realizacja w ramach zajęć z Inżynierii Oprogramowania oraz Zespołowego Projektu Programistycznego) i wynikającej z niego zasady samodzielności w realizacji, bez względu na faktyczne zapotrzebowanie, będzie brało udział czterech studentów drugiego/trzeciego roku informatyki. Aby zapewnić powodzenie projektu będą oni musieli posiąść wiedzę i umiejętności takie jak: tworzenie aplikacji pod platformą Microsoft.NET w języku C# umiejętność projektowania baz danych i znajmość SQL podstawy protokołu UDP biegła znajomość języka C++ znajomość zaawansowanych technik programowania w systemach uniksowych umiejętność tworzenia grafiki w grach komputerowych z wykorzystaniem technologii Microsoft DirectX Plan zatrudniania pracowników Z powodów wymienionych w punkcie Planie zatrudnienia, zespół realizujący projekt jest już zebrany i nie jest planowane poddawanie jego składu wymianie, redukcji bądź rozszerzeniu. Plan szkoleń Członkowie zespołu będą podnosić swoje kompetencje we własnym zakresie, w okresie od X 07 do II 08. Główny nacisk zostanie położony na technologię Microsoft.NET oraz Microsoft DirectX. 5.2.6 Budżet Projekt nie posiada żadnego budżetu, wszystkie wykorzystywane narzędzia są darmowe, sprzęt własny, a jedynym wynagrodzeniem pracowników jest pozytywna ocena z projektu. 5.3 Nadzór i kontrola projektu 5.3.1 Plan zarzadzania wymaganiami Ramy projektu są bardzo elastyczne, co wynika ze specyfiki gier komputerowych. Krytyczne wymagania dotyczą szkieletu architektury (klient-serwer) i nie mogą być zmienione. Dodawanie nowych funkcjonalności należy podejmować ostrożnie, przez wzgląd na nieprzekraczalny termin oddania projektu i tylko w razie wyraźnego wyprzedzenia harmonogramu. Ewentualna rezygnacja z wymagań funkcjonalnych nie będzie nastręczała żadnych trudności. Dynamiczne dodawanie oraz rezygnacja z elementów świata gry będzie możliwe dzieki zastosowanym technikom obiektowym. 17
5.3.2 Plan zarzadzania harmonogramem Harmonogram został oszacowany bardzo surowo. Jednak wszystkie zadania realizowane w ramach projektu zostanną opatrzone czasowym marginesem, który złoży się na margines błędu dla całego projektu. Monitorując zużycie tego marginesu będziemy w stanie podejmować stosowne decyzje projektowe, i tak: zużycie równomierne, proporcjonalne do postępu prac - skutek zbyt ostrego oszacowania harmonogramu, nie są podejmowane żadne akcje zapobiegawcze. zużycie przekraczające postęp o 20-30% - analiza problemu, przygotowanie stosownych akcji (patrz Plan zarządzania ryzykiem). zużycie przekraczające postęp o 30% - wdrożenie działań zaplanowanych w punkcie powyżej. 5.3.3 Plan kontroli budżetu Jedyną przeszkodą może być awaria sprzętu. W takim wypadku będziemy posiłkować się laboratorium komputerowym dostępnym nieodpładnie na Wydziale Matematyki, Informatyki i Mechaniki UW. 5.3.4 Plan kontroli jakości Zostaną podjęte następujące działania: Sprawdzanie spójności własnych fragmentów dokumentacji z resztą - po wprowadzeniu każdej zmiany. W razie braku spójności należy zwołać zebranie i rozstrzygnąć sporne kwestie. Wzajemne testowanie fragmentów kodu napisanego przez innych członków zespołu - raz na 4 tygodnie. W razie złej jakości kodu produkowanego przez jednego z członków należy zastosować upomnienie słowne. Możliwa również jest korekta harmonogramu, jeśli niedokładność programisty wyniknie z natłoku obowiązków w projekcie. Walidacja - po pierwszej działającej wersji. W razie niezgodności napisanego kodu ze wstępną wizją należy zaprojektować poprawki oraz maksymalnie zmobilizować zespół do ich wprowadzenia, aby nie nadwyrężyć harmonogramu. 5.4 Plan zarzadzania ryzykiem 18
Rodzaj Skutki Stopień Zapobieganie Zwalczanie problemy ze opóźnienie średni systematyczna pomoc reszty studiami nauka zespołu w nauce, przesunięcie zadań na innego członka problemy z nieukończenie niski odpowiednio zamiana zadań opanowaniem lub słaba jakość wczesne z osobą technologii projektu rozpoczecie bardziej za- nauki awansowaną, zmiana technologii problemy z brak lub gorsza średni wczesne proto- uproszczenie tworzeniem grafika typowanie gra- grafiki do pro- grafiki fiki stego widoku z góry lenistwo, niezdyscyplinowanie zespołu opóźnienia, słaba jakość wysoki surowy harmonogram napomnienia i inne metody motywacyjne 5.5 Plan zamknięcia projektu Projekt kończy się przygotowaniem prezentacji, w której należy pokazać pełną dokumentację oraz zaprezentować działający system. Źródła zostaną umieszczone w sieci na licencji GNU GPL. 6 Plany procesów technicznych 6.1 Metody, narzędzia i stosowane technologie Cały projekt stworzony w oparciu o RUP Dokumentacja tworzona w systemie składu tekstu LaTeX Standard UML stosowany przy tworzeniu dokumentacji Aplikacja tworzona w środowisku Microsoft Visual Studio Express Serwer tworzony przy pomocy standardowych narzędzi uniksowych 19
7 Historia zmian 28 V 07 r. - template sdp 30 V 07 r. - pierwsza wersja 20