Topór Światowida Software Architecture Document

Transkrypt

1 Topór Światowida Software Architecture Document Maciej Pawlisz Łukasz Polak Oskar Skibski Jakub Światły 30 maja 2007r. 1

2 Spis treści 1 Wprowadzenie Cel Zakres Definicje Załączniki Omówienie reszty dokumentu Omówienie projektu Cel, zakres i objectives projektu Założenia i zależności Produkty projektu Organizacja projektu Struktura organizacyjna Kontakty zewnętrzne Role i zadania Punkty funkcyjne Internal Logical File External Interface File External Input External Output External Inquiry Ogólne wymagania Adjusted function point count Zarzadzanie projektem Oszacowania Plan Projektu Plan faz i harmonogram projektu Kamienie milowe Diagramy Gantta- faza projektowa Diagramy Gantta- faza implementacyjna Zasoby Budżet Nadzór i kontrola projektu Plan zarządzania wymaganiami Plan zarządzania harmonogramem Plan kontroli budżetu Plan kontroli jakości Plan zarządzania ryzykiem

3 5.5 Plan zamknięcia projektu Plany procesów technicznych Metody, narzędzia i stosowane technologie Historia zmian 20 3

4 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

5 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 Wizja Model przypadków użycia Model dziedziny Model przypadków użycia z systemowym diagramem przebiegu i kontraktami Warstwy SAD SDP 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

6 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

7 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 a 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

8 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

9 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

10 5.2 Plan Projektu Plan faz i harmonogram projektu 10

11 Nazwa Rozpoczęcie Zakończenie Szczegóły Analiza problemu i sprecyzowanie Wizja, Model przy- wymagań biznesowych padków użycia Projektowanie aplikacji Model dziedziny, SAD Planowanie prac nad projektem SDP, plan testów Implementacja podstawowych podstawowa grafika, modułów komunikacja klient- serwer, poruszanie się, kilka obiektów ze świata gry, Stabilna wersja działające wyżej wymienione moduły Implementacja podstawowych umiejętności, wy- przypadków użycia miana towarów, komunikacja między graczami, obsługa plemion Stabilna wersja ALPHA Zaimplementowane podstawowe, wyżej wymienione przypadki użycia Implementacja pozostałych grafika, pozostałe ważnych modułów przypadki użycia, podstawowy wygląd i przedmioty świata gry Stabilna wersja BETA gry gra z zaimplementowanymi wszystkimi funkcjonalnościami Testy grywalności testy grywalności, testy poprawności, wodotryski, bezpieczeństwo Ukańczanie gry integracja wszystkich modułów, poprawianie błędów Wersja ostateczna gry Gra wpełni działająca Kamienie milowe Prezentacja z analizy i projektowania 11

12 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 Diagramy Gantta- faza projektowa Rozplanowanie zadań 12

13 13

14 Podział prac w zespole Diagramy Gantta- faza implementacyjna Rozplanowanie zadań 14

15 15

16 Podział prac w zespole 16

17 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 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 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

18 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 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 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

19 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

20 7 Historia zmian 28 V 07 r. - template sdp 30 V 07 r. - pierwsza wersja 20