Snatch, serwer brydżowy plan akceptacji systemu

Transkrypt

1 Snatch, serwer brydżowy plan akceptacji systemu Michał Korch Piotr Tomanek Marcin Pilipczuk Piotr Tabor 24 maja 2005 roku Wersja: 1.2 Historia Data Wersja Autor Zmiany Michał Korch Stworzenie pierwszej wersji całości dokumentu Marcin Pilipczuk Uzupełnienie dokumentu Piotr Tomanek Poprawki kontrolera jakości Marcin Pilipczuk Poprawki stosownie do uwag w czasie czytania dokumentu Spis treści 1 Wstęp Cel dokumentu Definicje i skróty Źródła Streszczenie Odpowiedzialność Obowiązki udziałowca Obowiązki zespołu Czynności związane z akceptacją produktu Kryteria akceptacji Lista aspektów, których dotyczy proces akceptacji Sposoby akceptowania funkcjonalności systemu Harmonogram Wymagania Wymagania sprzętowe Wymagania oprogramowania Wymagania dokumentacji Wymagania personelu Rozwiązywanie problemów 9 6 Środowisko testów akceptacyjnych 10 7 Testy akceptacyjne Test pokazowy przy pierwszej iteracji Warunki początkowe Scenariusz Test wydajnościowy przy pierwszej iteracji Warunki początkowe Scenariusz Test czasowy przy pierwszej iteracji Warunki początkowe Scenariusz

2 7.4 Test systemu reklam przy drugiej iteracji Warunki początkowe Scenariusz Test meczu towarzyskiego przy trzeciej iteracji Warunki początkowe Scenariusz Test systemu obrabiania wyników turnieju przy piątej iteracji Warunki początkowe Scenariusz Test personalizacji wyglądu aplikacji klienckiej przy szóstej iteracji Warunki początkowe Scenariusz Test języków oraz historii sławnych rozgrywek przy siódmej iteracji Warunki początkowe Scenariusz Narzędzia i techniki użyte w procesie akceptacji 15 2

3 1 Wstęp 1.1 Cel dokumentu Celem tego dokumentu jest przedstawienie planu akceptacji produktu przez udziałowca, w tym: harmonogramu akceptacji poszczególnych funkcji systemu, sposobów rozwiązywania ewentualnych problemów, planu testów akceptacyjnych, podziału obowiązków w procesie akceptacji. 1.2 Definicje i skróty projekt To, co ten dokument opisuje - projekt rozgrywek brydżowych przez internet. gracz Klient grający w brydża przez działający projekt. widz Klient obserwujący rozgrywki. sędzia Klient mający większe uprawnienia, organizujący turnieje i nadzorujący je. udziałowiec Portal który jest udziałowcem i docelowym właścicielem binarnej wersji projektu. zespół Zespół wykonujący projekt 1.3 Źródła Dokument ten korzysta z Wizji, Biznesowych przypadków użycia, Planu architektury systemu i Technicznych przypadków użycia w kwestiach dotyczących uzgodnionej zawartości projektu, zaś z Planu zarządzania Projektem w kwestii terminów i odpowiedzialności. 1.4 Streszczenie W dokumencie tym przedstawiono kolejno osoby odpowiedzialne za proces akceptacji ze strony zespołu oraz udziałowca, czynności, które zostaną wykonane w ramach akceptacji, reguły rozwiązywania problemów, które w ramach tego procesu mogą powstać i plan testów akceptacyjnych. 3

4 2 Odpowiedzialność Osobą odpowiedzialną ze strony udziałowca jest: Pan Lucjan Pudłokarton, Szef Działu Rozwoju Portalu firma opakowanie bardzofajnyportal.pl tel. do pracy: (44) , wewn. 44 tel. kom.: tel. domowy: (44) Osobą odpowiedzialną ze strony zespołu jest: Marcin Pilipczuk m.pilipczuk zodiac.mimuw.edu.pl 2.1 Obowiązki udziałowca Do obowiązków udziałowca w procesie wdrażania i akceptacji systemu należą: 1. Zapewnienie infrastruktury opisanej w rozdziale czwartym niniejszego dokumentu oraz w Planie Architektury Systemu. 2. Organizacja sali konferencyjnej na czas spotkania i testów. 3. Wydelegowanie dwóch pracowników do szkolenia w zakresie obsługi portalu brydżowego. 4. Zaproszenie na pierwsze testy akceptacyjne sędziego brydżowego oraz kilku graczy. 5. Wydelegowanie kilku sędziów brydżowych do szkolenia w zakresie korzystania z portalu. 6. Zapewnienie swobody dostępu członków zespołu do infrastruktury portalu w celu instalacji systemu. Terminy poszczególnych zadań znajdują się w rozdziale Obowiązki zespołu Do obowiązków zespołu w procesie wdrażania i akceptacji systemu należą: 1. Instalacja kolejnych wersji działającego systemu brydżowego na sprzęcie dostarczonym przez 2. Poprawianie ewentualnych błędów do czasu następnej iteracji instalacji (zgodnie z harmonogramem). 3. Uzgadnianie z udziałowcem zakresu ewentualnych zmian i poprawek. 4. Przygotowywanie scenariuszów testów oraz prezentacji z przebiegu testów wydajnościowych. 5. Przygotowanie narzędzi niezbędnych do testów akceptacyjnych. 6. Przeszkolenie dwóch pracowników w zakresie administrowania systemem. 7. Przeszkolenie kilku sędziów brydżowych delegowanych przez w zakresie korzystania z systemu. 8. Przygotowanie dokumentacji opisującej przebieg testów. Terminy poszczególnych zadań znajdują się w rozdziale

5 3 Czynności związane z akceptacją produktu 3.1 Kryteria akceptacji Podstawowym kryterium akceptacji systemu jest jego zgodność z dokumentami zaakceptowanymi przez udziałowca, czyli: Wizją, Biznesowymi Przypadkami Użycia, Planem Architektury Systemu i Technicznymi Przypadkami Użycia. W zakresie interfejsu oraz zasad i zwyczajów brydżowych brane będą pod uwagę uwagi zgłaszane przez sędziów i graczy biorących udział w testach. W szczególności udziałowiec musi się przekonać, że system: poprawnie przeprowadza rozgrywkę brydżową (w szczególności prawidłowo ją wyświetla), poprawnie przeprowadza turniej, umożliwia rejestrację gracza i reklamodawcy, i edycję ich danych, umożliwia pracownikowi wykonanie czynności opisanych w Biznesowych Przypadkach Użycia, prawidłowo działa system FAQ, poprawnie działają rankingi, prawidłowo działa system reklam, pracownicy potrafią obsługiwać system, system wykazuje zadeklarowaną niezawodność oraz odporność na przeciążenia. 3.2 Lista aspektów, których dotyczy proces akceptacji Z powyższej listy wynikają aspekty systemu, które mają być zaprezentowane udziałowcowi: rozgrywka brydżowa przeprowadzenie, rozgrywka brydżowa obserwowanie jako widz, turniej utworzenie turnieju, turniej przeprowadzenie, system reklam - rejestracja, zgłoszenie, wyświetlanie, statystyki, administracja systemem (archiwizacja, usuwanie danych, nadawanie praw), FAQ, rejestracja i zarządzanie danymi użytkownika. 3.3 Sposoby akceptowania funkcjonalności systemu Po każdej z iteracji systemu zostanie przeprowadzony pokaz dla udziałowca. W czasie pokazów przeprowadzone zostaną testy wymienione w punkcie 7. Poniżej znajduje się lista, w jaki sposób zostają sprawdzone poszczególne elementy systemu wypisane w punkcie 3.2. Instalacja systemu, ze względu na napięte terminy i złożoność systemu, została podzielona na iteracje. W pierwszej iteracji zostaje uruchomiona podstawowa funkcjonalność systemu. W kolejnych iteracjach zostają dołożone kolejne możliwości portalu. 5

6 nr element iteracja sposób przetestowania 1 rozgrywka brydżowa - przeprowadzenie 1 rozgrywka testowa graczy i sędziego obecnych w czasie testów, rozgrywki w czasie testowego turnieju, test wydajnościowy - ogromna liczba rozgrywek towarzyskich (w czasie akceptacji przedstawiony zostanie raport z 2 rozgrywka brydżowa - obserwowanie tego testu). 1 w czasie rozgrywek testowych i turnieju testowego, uczestnicy testów (w tym przedstawiciele będą mogli podchodzić do stolików w celu obserwacji rozgrywki. W czasie testu wydajnościowego oprócz graczy obecne będą boty 1 obserwujące jedynie rozgrywki. 3 turniej - założenie turnieju 1 testowy turniej zostanie skonfigurowany na oczach obecnych reprezentantów udziałowca. 4 turniej - przeprowadzenie 1 zostanie przeprowadzony testowy turniej z udziałem zaproszonych dziewięciu graczy oraz sędziego. 5 system reklam 2 przedstawienie pracownikom mechanizmu zamieszczania reklam oraz danych technicznych wyświetlanych reklam, prezentacja rozgrywki brydżowej od strony aplikacji klienckiej (z wyświetlanymi już reklamami), prezentacja mechanizmu rejestracji reklamodawcy i zamieszczenia reklamy (testowe przeprowadzenie tego procesu), prezentacja możliwości statystycznych programu po pewnej liczbie sztucznych wyświetleń reklam. 6 administracja systemem 4 przejęcie przez pracowników administracji systemem; akceptacja odbywa się na podstawie ich opinii na temat łatwości zarządzania systemem. 7 FAQ 1 prezentacja działania mechanizmu FAQ oraz manuala uczestnikom testów poprzez zadawanie pytań i odpowiadania na nie. 8 rejestracja i zarządzanie danymi użytkownika 1 uczestnicy testów w pierwszej iteracji w pierwszej kolejności rejestrują się do systemu, mogą zmienić swoje dane. 6

7 3.4 Harmonogram Oto kolejne iteracje wdrożenia systemu: nr co ma się pojawić data data zakończenia 1 przeprowadzenie rozgrywki, obserwacja rozgrywki, łatwa organizacja i przeprowadzenie turnieju, nadzorowanie turnieju przez sędziów, atrakcyjny wizualnie wygląd gry, obserwacja turnieju, gra w różnych środowiskach, przetrzymywanie danych o użytkownikach, rejestracja użytkowników. 2 wyświetlanie reklam, statystyki, dodawanie i usuwanie reklam, zarządzanie danymi reklamodawców. 3 przeprowadzenie meczu brydżowego, nadzorowanie meczu, obserwacja meczu. 4 szkolenie pracowników oraz sędziów łatwa obróbka wyników, przeprowadzenie treningów. 6 wybór wyglądu aplikacji klienckich, wybór systemu punktowego. 7 przegląd sławnych brydżowych rozgrywek, wybór języka

8 4 Wymagania 4.1 Wymagania sprzętowe Zgodnie z Projektem Architektury Systemu, do instalacji systemu udziałowiec ma zapewnić: 1. Serwer bazy danych, 2 GB RAM, dyski o przepustowości 100 megabitów na sekundę. 2. Średniej klasy serwer główny. 3. Łącze do internetu: 5 megabitów/s dla transferu wejściowego, 10 megabitów/s dla wyjściowego megabitowa sieć wewnętrzna. 5. Router i firewall. 6. Ewentualne pomocnicze serwery do przeprowadzania turniejów. 7. Serwer www. 8. System podtrzymywania napięcia (UPS). Natomiast do testów akceptacyjnych, dla każdego stanowiska klienckiego, udziałowiec ma zapewnić: 1. Komputer PC z dostępem do internetu. 4.2 Wymagania oprogramowania Zgodnie z Projektem Architektury Systemu, do instalacji systemu udziałowiec ma zapewnić: 1. System Linux na serwerze www i serwerze głównym. 2. Oprogramowanie routera i firewalla (poza zakresem zainteresowania zespołu). 3. Relacyjna baza danych Oracle 10i. 4. Biblioteki do obsługi standardów: SSL, XML. 5. Serwer Apache i JBoss. 6. Poddomena brydz.bardzofajnyportal.pl. 7. Wewnętrzne adresy IP dla serwerów (w sieci Natomiast do testów akceptacyjnych, dla aplikacji klienckich, udziałowiec ma zapewnić: 1. Jeden z systemów operacyjnych: Windows, Linux, Unix, MacOS. 2. Przeglądarka internetowa z obsługą Javy. 4.3 Wymagania dokumentacji Zespół podejmuje się przygotować: 1. Kompletny manual dla graczy, sędziów i pracowników 2. System zadawania pytań i odpowiadania na nie. 3. Plan testów akceptacyjnych wraz z raportem z nich. 4. Raporty z testów wydajnościowych przeprowadzonych w czasie testów systemu. 4.4 Wymagania personelu Udziałowiec zobowiązuje się: 1. Wydelegować dwóch pracowników do szkolenia w zakresie obsługi systemu. 2. Wydelegować kilku sędziów brydżowych do szkolenia w zakresie korzystania z systemu. 3. Zaprosić na testy kilku (9) graczy i sędziego brydżowego. 8

9 5 Rozwiązywanie problemów W sytuacji bezspornych błędów zauważonych w procesie akceptacji, zespół zobowiązuje się do ich poprawienia w jak najkrótszym czasie, nie później niż do terminu wyznaczonego w harmonogramie, którym zazwyczaj jest początek kolejnej iteracji systemu. W kwestiach interfejsu i wygody użytkownika będą brane pod uwagę propozycje graczy i sędziów biorących udział w testach. W kwestiach większych zmian w systemie, nie będących bezspornymi błędami, zespół podejmuje negocjacje w kwestii terminu poprawek i ewentualnego wynagrodzenia. W sytuacjach spornych dotyczących działania systemu, wyznacznikiem jest zgodność rzeczywistego systemu z treścią dokumentów zaakceptowanych przez klienta, w szczególności z Wizją, Biznesowymi Przypadkami Użycia, Planem Architektury Systemu i Technicznymi Przypadkami Użycia. W sytuacjach ostatecznych spory rozstrzyga sąd. 9

10 6 Środowisko testów akceptacyjnych Testy akceptacyjne na koniec pierwszej iteracji zajmą najprawdopodobniej cztery dni robocze, ze względu na dużą ilość elementów do przetestowania. Kolejne testy przewidujemy na około jeden dzień roboczy. Szacunki te zawierają całe spotkanie wraz z spisaniem protokołu oraz dyskusjami na temat poprawek. Wszystkie testy będą odbywać się w siedzibie w sali konferencyjnej. Udziałowiec zobowiązuje się, by w trakcie testów akceptacyjnych dostępne były: 1. Odpowiednia liczba stanowisk do testów - komputer PC z przeglądarką internetową (stosownie do zapisów rozdziału czwartego): po pierwszej i trzeciej iteracji 15 komputerów, po pozostałych 8 komputerów. 2. Podłączenie komputerów do Internetu. 3. Rzutnik oraz laptop do wyświetlania prezentacji. Zespół zobowiązuje się, aby w czasie trwania testów działał sprawnie system brydżowy. Zespół przygotuje protokół z testów wydajnościowych systemu oraz dokumentację. 10

11 7 Testy akceptacyjne Największe testy akceptacyjne zostaną przeprowadzone po pierwszej iteracji, ze względu na jej kluczowość w całym projekcie. Testy akceptacyjne po kolejnych iteracjach będą sprowadzały się do krótkich pokazów dotyczących elementów, które uległy zmianie w systemie. 7.1 Test pokazowy przy pierwszej iteracji Warunki początkowe System został zainstalowany. Ręcznie zarejestrowano pracownika portalu o wszelkich prawach Scenariusz 1. Rejestracja dziewięciu użytkowników. 2. W trakcie rejestracji jeden z użytkowników podaje nieprawidłowe dane (zły itd.). System wykrywa to i nie akceptuje zgłoszenia. 3. Użytkownik pierwszy edytuje swoje dane. Pragnie zostać sędzią. 4. Pracownik edytuje dane użytkownika. Akceptuje prośbę o zostanie sędzią. 5. Użytkownik zakłada stolik. 6. Inny użytkownik zakłada drugi stolik. 7. Użytkownicy dosiadają się do stolików lub są zapraszani przez zakładających stolik. 8. Jeden z użytkowników zamyka cały aplet. Inni są informowani o opuszczeniu gry przez jednego z graczy. Po pewnym czasie ten gracz znów się loguje. 9. Jeden z użytkowników, co założył stolik, zamyka aplet. Inni są poinformowani o tym fakcie i wyrzucani z tego stolika. Po pewnym czasie gracz wraca i znów zakłada stolik. 10. Jeden użytkownik zostaje usunięty ze swojego miejsca, dosiada się do drugiego stolika. 11. Rozgrywane są dwie partyjki towarzyskie. Jedna z nich kończy się sukcesem, w czasie drugiej jeden z graczy nagle przestaje gracz. Założyciel stolika wyrzuca go z gry. 12. Sędzia planuje turniej. W trakcie planowania podaje wstępnie złe dane, a następnie je poprawia. 13. Turniej zostaje zatwierdzony przez pracownika Gracze rejestrują się na turniej. Dodatkowo dwie para graczy rejestrują się podwójnie. 15. Zostaje rozpoczęty turniej. Jedna z dodatkowych par się wogóle nie zgłasza, a z drugiej zgłasza się tylko jeden gracz. Obie pary zostają usunięte. 16. Zostaje przeprowadzony turniej. Gracze zadają sędziemu pytania, na które on odpowiada. 17. Widz obserwuje turniej. 18. Jeden z graczy rezygnuje podczas trwania turnieju. 19. Turniej zostaje doprowadzony do końca. 20. Pracownik zakłada ranking kto wygrał najwięcej rozdań przy kontrakcie pikowym. 21. Widz ogląda przebieg rozdań z zakończonego turnieju oraz jedno z dzisiejszych rozdań towarzyskich. Widz na początku w czasie trwania ściągania rozdań zamyka nagle aplikację. Następnie znów ją otwiera i ponownie przegląda rozdania. 22. Widz przegląda nowy ranking. 11

12 7.2 Test wydajnościowy przy pierwszej iteracji Warunki początkowe System został zainstalowany. Zostało zarejestrowanych wielu komputerowych graczy Scenariusz Zostaje uruchomiony system. Stopniowo uruchamiani są kolejni klienci grający oraz obserwujący. 2 Część klientów grających zakłada nowe stoliki, część próbuje dołączyć się do już istniejących. Obserwowany i zapisywany jest czas oczekiwania na reakcję systemu przy rosnącej liczbie programów grających. W momencie przekroczenia wartości progowej i wysypaniu się systemu, sprawdzane jest, czy system kulturalnie się wysypał. Obie strony uznają, że program wysypał się jeśli czas odpowiedzi na żądania kilka razy z rzędu przekracza pięciokrotnie czas założony w Wizji systemu dla co dziesiętego użytkownika. 7.3 Test czasowy przy pierwszej iteracji Warunki początkowe System został zainstalowany. Zostało zarejestrowanych wielu komputerowych graczy. Został przeprowadzony test wydajnościowy Scenariusz Zostaje uruchomiona taka liczba botów, przy jakiej system normalnie działa (liczba ta jest określona na podstawie testu wydajnościowego). System zostaje pozostawiony na 24h do działania. 7.4 Test systemu reklam przy drugiej iteracji Warunki początkowe System został zainstalowany, zostały przeprowadzone testy pierwszej iteracji Scenariusz 1. Pracownik zakłada konto dwóm reklamodawcom. 2. Dwóch pracowników udając reklamodawców, loguje się i dodaje kilka reklam o różnych liczbach wyświetleń. 3. Pracownik odhacza, że ci reklamodawcy zapłacili za prezentacje reklam i udostępnia je do wyświetlania. Jedna z reklam zostaje uznana za niezapłaconą i wyrzucona. 4. Zostaje przeprowadzone rozdanie towarzyskie z prezentacją wyświetlania się reklam. 5. Na czas kilku minut uruchomione zostaje kilkaset botów grających i obserwujących. 6. Reklamodawcy przeglądają statystyki swoich reklam. Są one pokazane publiczności na dowód działania algorytmu wyboru reklamy do wyświetlenia. 7.5 Test meczu towarzyskiego przy trzeciej iteracji Warunki początkowe System został zainstalowany, zostały przeprowadzone testy poprzednich iteracji. Jest zarejestrowanych kilku graczy i sędzia (z pierwszej iteracji). 2 programy klienkie - boty - są opisane w rozdziale ósmym 12

13 7.5.2 Scenariusz 1. Gracze się logują. 2. Gracz pierwszy proponuje przez czat mecz innym graczom (pokaz działania czatu). 3. Gracz pierwszy zakłada mecz i proponuje pozostałym siedmiu mecz. 4. Jeden z graczy się nie zgadza, mecz zostaje zerwany. 5. Gracz drugi proponuje mecz, tym razem wszyscy się zgadzają. 6. Mecz się rozpoczyna, ale w pewnym momencie założyciel wyciąga wtyczkę sieciową z gniazdka, traci połączenie, mecz jest zerwany. 7. Zostaje założony trzeci mecz, wszyscy się podłączają. 8. Zostaje rozegrany mecz towarzyski. W trakcie jego trwania uczestnicy testów logują się jako widzowie i obserwują rozgrywkę. 9. Zostaje założony ranking punkty w meczach towarzyskich przez pracownika. 7.6 Test systemu obrabiania wyników turnieju przy piątej iteracji Warunki początkowe System działa, zostało przeprowadzone szkolenie sędziów i pracowników, zostały przeprowadzone testy poprzednich iteracji. Został przeprowadzony duży turniej z udziałem botów, turniej został założony przez sędziego Scenariusz 1. Turniej się kończy. 2. Sędzia otrzymuje raport o turnieju. 3. Sędzia postanawia ogłosić wyniki w trzech rankingach: największa liczba PKL-i, najbardziej utopione kontrakty, najbardziej niedolicytowane kontrakty. 4. Sędzia wysyła wyniki do serwera. 5. Sędzia eksportuje wyniki w PKL-ach do formatu respektowanego przez bazę danych Polskiego Związku Brydża Sportowego oraz ranking najbardziej utopione kontrakty do formatu PDF. Uwaga: częściowe testy tej części projektu odbywają się w czasie szkolenia sędziów, którzy na bieżąco zgłaszają swoje uwagi do interfejsu i mechanizmu działania aplikacji sędziowskiej. 7.7 Test personalizacji wyglądu aplikacji klienckiej przy szóstej iteracji Warunki początkowe System działa, zostało przeprowadzone szkolenie sędziów i pracowników, zostały przeprowadzone testy poprzednich iteracji Scenariusz 1. Loguje się czterech graczy. 2. Rozpoczynają partię towarzyską. 3. W czasie trwania partii, każdy z nich co chwilę zmienia jakieś aspekty wyglądu apletu: kolory, ułożenie, styl. 4. Po zakończeniu rozgrywki zachowują zmiany i wylogowują się. 5. Logują się ponownie i zaczynają nową rozgrywkę. Ustawienia wyglądu zachowały się. 13

14 7.8 Test języków oraz historii sławnych rozgrywek przy siódmej iteracji Warunki początkowe System działa, zostało przeprowadzone szkolenie sędziów i pracowników, zostały przeprowadzone testy poprzednich iteracji. Została wprowadzona do systemu pewna (być może jeszcze niekompletna) lista sławnych rozgrywek brydżowych Scenariusz 1. Widz loguje się do systemu. 2. Klika na listę dawnych rozgrywek - zakładka Sławne. 3. Widz przegląda dwie rozgrywki. 4. Widz się wylogowuje. 14

15 8 Narzędzia i techniki użyte w procesie akceptacji W trakcie testów wydajnościowych i czasowych zostaną użyte trzy boty grające w brydża: bot grający Bot, który podłączywszy się do systemu, szuka wolnego stolika towarzyskiego i próbuje podłączyć się do niego, po czym rozpoczyna grę. Po zakończeniu gry opuszcza serwis a następnie ponownie łączy się z nim i próbuje zagrać. bot stolikowy Bot, działający jak powyższy, ale zakładający za każdym razem własny stolik i czekający na partnerów. bot oglądający Bot, który tylko podchodzi do stolików, ogląda rozgrywki i pilnuje, czy wszystkie komunikaty do niego dochodzą. Uruchamiając odpowiednią liczbę wymienionych botów, zostanie przebadana wydajność systemu oraz jego niezawodność. Raport z tego testu w postaci prezentacji, zostanie przedstawiony w czasie testów pierwszej iteracji. Boty służyć będą również, poza akceptacyjnymi testami wydajnościowymi i czasowymi, do nabijania liczników reklam potrzebnych do prezentacji mechanizmu statystyk w czasie drugiej iteracji. Pozostałe testy są przeprowadzane na zasadzie namacalnej, tj. odpowiedni scenariusz jest przeprowadzany przy udziale przedstawicieli 15