%& --translate-file latin2pl
\documentclass[a4paper,10pt]{article}

\usepackage{polski}
\usepackage[latin2]{inputenc}



% Marginesy
\textwidth17cm \textheight24.5cm \topmargin-40pt
\oddsidemargin-0.04cm

%%%%%%%%%%%%%%%
% To zmieniac %
%%%%%%%%%%%%%%%
% Nazwa, wersja
\newcommand{\nazwaprojektu}{Snatch, serwer brydżowy}
\newcommand{\nazwadokumentu}{plan akceptacji systemu}
\newcommand{\wersjadokumentu}{1.2}

\title{\nazwaprojektu \ --- \nazwadokumentu}
\author{Michał Korch \and Piotr Tomanek \and Marcin Pilipczuk \and Piotr Tabor}

\begin{document}

% Definicja naglowka posrodku strony
\newcommand{\nagl}[1]{\par\begin{center}{\bf{#1}}\end{center}\par}
% Definicja tego na poczatku
\newcommand{\pocz}{\par {\bf{\nazwaprojektu}}\par {\bf{\nazwadokumentu}}\par {\bf{Wersja: \wersjadokumentu}}\par}
\maketitle
\par
{\bf{Wersja: \wersjadokumentu}}
\par

%% Historia
% environment
\newenvironment{historia}{\nagl{Historia}\begin{tabular*}{17cm}{c|c|c|l} {\bf{Data}} & {\bf{Wersja}} & {\bf{Autor}} & {\bf{Zmiany}} \\}{\end{tabular*}}
% item
\newcommand{\hist}[4]{#1 & #2 & #3 & \parbox[t]{9cm}{#4} \\ }

%% Spis tresci
\newcommand{\spistresci}{\tableofcontents}
\newcommand{\wfp}{www.bardzofajnyportal.pl}

\begin{historia}

\hist{2005-05-16}{0.1}{Michał Korch}{Stworzenie pierwszej wersji cało\'{s}ci dokumentu}
\hist{2005-05-19}{1.0}{Marcin Pilipczuk}{Uzupełnienie dokumentu}
\hist{2005-05-23}{1.1}{Piotr Tomanek}{Poprawki kontrolera jakości}
\hist{2005-05-24}{1.2}{Marcin Pilipczuk}{Poprawki stosownie do uwag w czasie czytania dokumentu}
\end{historia}

\spistresci
\newpage

\section{Wstęp}

\subsection{Cel dokumentu}
Celem tego dokumentu jest przedstawienie planu akceptacji produktu przez udziałowca, w tym:

\begin{itemize}
\item harmonogramu akceptacji poszczególnych funkcji systemu,
\item sposobów rozwiązywania ewentualnych problemów,
\item planu testów akceptacyjnych,
\item podziału obowiązków w procesie akceptacji.
\end{itemize}

\subsection{Definicje i skróty}
\begin{description}

\item[projekt] To, co ten dokument opisuje - projekt rozgrywek brydżowych przez internet.
\item[gracz] Klient grający w brydża przez działający projekt.
\item[widz] Klient obserwujący rozgrywki.
\item[sędzia] Klient mający większe uprawnienia, organizujący turnieje i nadzorujący je.
\item[udziałowiec] Portal www.bardzofajnyportal.pl, który jest udziałowcem i docelowym właścicielem binarnej wersji projektu.
\item[zespół] Zespół wykonujący projekt

\end{description}

\subsection{Ź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.

\subsection{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.

\newpage
\section{Odpowiedzialność}

Osobą odpowiedzialną ze strony udziałowca jest:
\begin{quote}
Pan Lucjan Pudłokarton,\\
Szef Działu Rozwoju Portalu\\
firma www.bardzofajnyportal.pl\\
e-mail: opakowanie \@ bardzofajnyportal.pl\\
tel. do pracy: (44)4404444, wewn. 44\\
tel. kom.: 644044044\\
tel. domowy: (44)4400044.
\end{quote}

Osobą odpowiedzialną ze strony zespołu jest:
\begin{quote}
Marcin Pilipczuk\\
e-mail: m.pilipczuk\@ zodiac.mimuw.edu.pl
\end{quote}

\subsection{Obowiązki udziałowca}

Do obowiązków udziałowca w procesie wdrażania i akceptacji systemu należą:

\begin{enumerate}
\item Zapewnienie infrastruktury opisanej w rozdziale czwartym niniejszego dokumentu oraz w Planie Architektury Systemu.
\item Organizacja sali konferencyjnej na czas spotkania i testów.
\item Wydelegowanie dwóch pracowników do szkolenia w zakresie obsługi portalu brydżowego.
\item Zaproszenie na pierwsze testy akceptacyjne sędziego brydżowego oraz kilku graczy.
\item Wydelegowanie kilku sędziów brydżowych do szkolenia w zakresie korzystania z portalu.
\item Zapewnienie swobody dostępu członków zespołu do infrastruktury portalu w celu instalacji systemu.
\end{enumerate}

Terminy poszczególnych zadań znajdują się w rozdziale 3.4.

\subsection{Obowiązki zespołu}

Do obowiązków zespołu w procesie wdrażania i akceptacji systemu należą:

\begin{enumerate}
\item Instalacja kolejnych wersji działającego systemu brydżowego na sprzęcie dostarczonym przez \wfp.
\item Poprawianie ewentualnych błędów do czasu następnej iteracji instalacji (zgodnie z harmonogramem).
\item Uzgadnianie z udziałowcem zakresu ewentualnych zmian i poprawek.
\item Przygotowywanie scenariuszów testów oraz prezentacji z przebiegu testów wydajnościowych.
\item Przygotowanie narzędzi niezbędnych do testów akceptacyjnych.
\item Przeszkolenie dwóch pracowników \wfp \ w zakresie administrowania systemem.
\item Przeszkolenie kilku sędziów brydżowych delegowanych przez \wfp \ w zakresie korzystania z systemu.
\item Przygotowanie dokumentacji opisującej przebieg testów.
\end{enumerate}

Terminy poszczególnych zadań znajdują się w rozdziale 3.4.

\newpage
\section{Czynności związane z akceptacją produktu}
\subsection{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:
\begin{itemize}
\item
poprawnie przeprowadza rozgrywkę brydżową (w szczególności prawidłowo ją wyświetla),
\item
poprawnie przeprowadza turniej,
\item
umożliwia rejestrację gracza i reklamodawcy, i edycję ich danych,
\item
umożliwia pracownikowi wykonanie czynności opisanych w Biznesowych Przypadkach Użycia,
\item
prawidłowo działa system FAQ,
\item
poprawnie działają rankingi,
\item
prawidłowo działa system reklam,
\item 
pracownicy \wfp \ potrafią obsługiwać system,
\item
system wykazuje zadeklarowaną niezawodność oraz odporność na przeciążenia.
\end{itemize}

\subsection{Lista aspektów, których dotyczy proces akceptacji}
Z powyższej listy wynikają aspekty systemu, które mają być zaprezentowane udziałowcowi:
\begin{itemize}
\item
rozgrywka brydżowa -- przeprowadzenie,
\item
rozgrywka brydżowa -- obserwowanie jako widz,
\item
turniej -- utworzenie turnieju,
\item
turniej -- przeprowadzenie,
\item
system reklam - rejestracja, zgłoszenie, wyświetlanie, statystyki,
\item
administracja systemem (archiwizacja, usuwanie danych, nadawanie praw),
\item
FAQ,
\item
rejestracja i zarządzanie danymi użytkownika.
\end{itemize}

\subsection{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.

\newcommand{\celik}[4]{#1 & \parbox[t]{5cm}{#2} & #3 & \parbox[t]{9cm}{#4}\\ \hline}
\begin{center}
\begin{tabular}{|c|c|c|c|} \hline
\celik{nr}{element}{iteracja}{sposób przetestowania}
\celik{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 tego testu).}
\celik{2}{rozgrywka brydżowa - obserwowanie}{1}{w czasie rozgrywek testowych i turnieju testowego, uczestnicy testów (w tym przedstawiciele
  \wfp) będą mogli podchodzić do stolików w celu obserwacji rozgrywki.\\
W czasie testu wydajnościowego oprócz graczy obecne będą ,,boty''\footnote{działanie ,,botów'' jest opisane w rozdziale ósmym} obserwujące jedynie rozgrywki.}
\celik{3}{turniej - założenie turnieju}{1}{testowy turniej zostanie skonfigurowany na oczach obecnych reprezentantów udziałowca.}
\celik{4}{turniej - przeprowadzenie}{1}{zostanie przeprowadzony testowy turniej z udziałem zaproszonych dziewięciu graczy oraz sędziego.}
\celik{5}{system reklam}{2}{przedstawienie pracownikom \wfp \ 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.}
\celik{6}{administracja systemem}{4}{przejęcie przez pracowników \wfp \ administracji systemem; akceptacja odbywa się na podstawie
ich opinii na temat łatwości zarządzania systemem.}
\celik{7}{FAQ}{1}{prezentacja działania mechanizmu FAQ oraz manuala uczestnikom testów poprzez zadawanie pytań i odpowiadania na nie.}
\celik{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.}
\end{tabular}
\end{center}
\newpage
\subsection{Harmonogram}
Oto kolejne iteracje wdrożenia systemu:
\newcommand{\iteracja}[4]{#1 & \parbox[t]{9cm}{#2} & #3 & #4\\ \hline}
\begin{center}
\begin{tabular}{|c|c|c|c|} \hline
\iteracja{nr}{co ma się pojawi\'{c}}{data}{data zakończenia}
\iteracja{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.}{1.08}{20.08}
\iteracja{2}{wyświetlanie reklam,\\
  statystyki, dodawanie i usuwanie reklam,\\
    zarządzanie danymi reklamodawców.}{20.08}{1.09}
\iteracja{3}{przeprowadzenie meczu brydżowego,\\
nadzorowanie meczu,\\
obserwacja meczu.}{1.09}{10.09}
\iteracja{4}{szkolenie pracowników \wfp \ oraz sędziów.}{1.09}{10.09}
\iteracja{5}{łatwa ,,obróbka'' wyników, \\ 
przeprowadzenie treningów.}{10.09}{20.09}
\iteracja{6}{wybór wyglądu aplikacji klienckich, \\
wybór systemu punktowego.}{20.09}{1.10}
\iteracja{7}{przegląd sławnych brydżowych rozgrywek, \\
wybór języka.}{1.10}{10.10}
\end{tabular}
\end{center}

\newpage
\section{Wymagania}

\subsection{Wymagania sprzętowe}

Zgodnie z Projektem Architektury Systemu, do instalacji systemu udziałowiec ma zapewnić:

\begin{enumerate}
\item Serwer bazy danych, 2 GB RAM, dyski o przepustowości 100 megabitów na sekundę.
\item Średniej klasy serwer główny.
\item Łącze do internetu: 5 megabitów/s dla transferu wejściowego, 10 megabitów/s dla wyjściowego.
\item 100 megabitowa sieć wewnętrzna.
\item Router i firewall.
\item Ewentualne pomocnicze serwery do przeprowadzania turniejów.
\item Serwer www.
\item System podtrzymywania napięcia (UPS).
\end{enumerate}

Natomiast do testów akceptacyjnych, dla każdego stanowiska klienckiego, udziałowiec ma zapewnić:

\begin{enumerate}
\item Komputer PC z dostępem do internetu. 
\end{enumerate}

\subsection{Wymagania oprogramowania}

Zgodnie z Projektem Architektury Systemu, do instalacji systemu udziałowiec ma zapewnić:

\begin{enumerate}
\item System Linux na serwerze www i serwerze głównym.
\item Oprogramowanie routera i firewalla (poza zakresem zainteresowania zespołu).
\item Relacyjna baza danych Oracle 10i.
\item Biblioteki do obsługi standardów: SSL, XML.
\item Serwer Apache i JBoss.
\item Poddomena brydz.bardzofajnyportal.pl.
\item Wewnętrzne adresy IP dla serwerów (w sieci \wfp).
\end{enumerate}

Natomiast do testów akceptacyjnych, dla aplikacji klienckich, udziałowiec ma zapewnić:

\begin{enumerate}
\item Jeden z systemów operacyjnych: Windows, Linux, Unix, MacOS.
\item Przeglądarka internetowa z obsługą Javy.
\end{enumerate}

\subsection{Wymagania dokumentacji}

Zespół podejmuje się przygotować:

\begin{enumerate}
\item Kompletny manual dla graczy, sędziów i pracowników \wfp.
\item System zadawania pytań i odpowiadania na nie.
\item Plan testów akceptacyjnych wraz z raportem z nich.
\item Raporty z testów wydajnościowych przeprowadzonych w czasie testów systemu.
\end{enumerate}

\subsection{Wymagania personelu}

Udziałowiec zobowiązuje się:

\begin{enumerate}
\item Wydelegować dwóch pracowników do szkolenia w zakresie obsługi systemu.
\item Wydelegować kilku sędziów brydżowych do szkolenia w zakresie korzystania z systemu.
\item Zaprosić na testy kilku (9) graczy i sędziego brydżowego.
\end{enumerate}

\newpage
\section{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.

\newpage

\section{Ś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 \wfp, w sali konferencyjnej. Udziałowiec zobowiązuje się, by w trakcie testów akceptacyjnych dostępne były:

\begin{enumerate}
\item 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.
\item Podłączenie komputerów do Internetu.
\item Rzutnik oraz laptop do wyświetlania prezentacji.
\end{enumerate}

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ę.

\newpage

\section{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.

\subsection{Test pokazowy przy pierwszej iteracji}
\subsubsection{Warunki początkowe}
System został zainstalowany. Ręcznie zarejestrowano pracownika portalu o wszelkich prawach.

\subsubsection{Scenariusz}
\begin{enumerate}
\item Rejestracja dziewięciu użytkowników.
\item W trakcie rejestracji jeden z użytkowników podaje nieprawidłowe dane (zły email itd.). System wykrywa to i nie akceptuje zgłoszenia.
\item Użytkownik pierwszy edytuje swoje dane. Pragnie zostać sędzią.
\item Pracownik edytuje dane użytkownika. Akceptuje prośbę o zostanie sędzią.
\item Użytkownik zakłada stolik.
\item Inny użytkownik zakłada drugi stolik.
\item Użytkownicy dosiadają się do stolików lub są zapraszani przez zakładających stolik.
\item 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.
\item 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.
\item Jeden użytkownik zostaje usunięty ze swojego miejsca, dosiada się do drugiego stolika.
\item 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.
\item Sędzia planuje turniej. W trakcie planowania podaje wstępnie złe dane, a następnie je poprawia.
\item Turniej zostaje zatwierdzony przez pracownika \wfp.
\item Gracze rejestrują się na turniej. Dodatkowo dwie para graczy rejestrują się podwójnie.
\item 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.
\item Zostaje przeprowadzony turniej. Gracze zadają sędziemu pytania, na które on odpowiada.
\item Widz obserwuje turniej.
\item Jeden z graczy rezygnuje podczas trwania turnieju.
\item Turniej zostaje doprowadzony do końca.
\item Pracownik zakłada ranking ,,kto wygrał najwięcej rozdań przy kontrakcie pikowym''.
\item 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.
\item Widz przegląda nowy ranking.
\end{enumerate}

\subsection{Test wydajnościowy przy pierwszej iteracji}
\subsubsection{Warunki początkowe}
System został zainstalowany. Zostało zarejestrowanych wielu komputerowych graczy. 

\subsubsection{Scenariusz}
Zostaje uruchomiony system. Stopniowo uruchamiani są kolejni klienci grający oraz obserwujący.\footnote{programy klienkie - ,,boty'' - 
  są opisane w rozdziale ósmym} 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.

\subsection{Test czasowy przy pierwszej iteracji}
\subsubsection{Warunki początkowe}
System został zainstalowany. Zostało zarejestrowanych wielu komputerowych graczy. Został przeprowadzony test wydajnościowy.

\subsubsection{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.

\subsection{Test systemu reklam przy drugiej iteracji}

\subsubsection{Warunki początkowe}
System został zainstalowany, zostały przeprowadzone testy pierwszej iteracji. 

\subsubsection{Scenariusz}

\begin{enumerate}
\item Pracownik \wfp \ zakłada konto dwóm reklamodawcom.
\item Dwóch pracowników \wfp, ,,udając'' reklamodawców, loguje się i dodaje kilka reklam o różnych liczbach wyświetleń.
\item Pracownik \wfp \ 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.
\item Zostaje przeprowadzone rozdanie towarzyskie z prezentacją wyświetlania się reklam.
\item Na czas kilku minut uruchomione zostaje kilkaset botów grających i obserwujących.
\item Reklamodawcy przeglądają statystyki swoich reklam. Są one pokazane publiczności na dowód działania algorytmu wyboru reklamy do wyświetlenia.
\end{enumerate}

\subsection{Test meczu towarzyskiego przy trzeciej iteracji}

\subsubsection{Warunki początkowe}
System został zainstalowany, zostały przeprowadzone testy poprzednich iteracji. Jest zarejestrowanych kilku graczy i sędzia (z pierwszej iteracji).

\subsubsection{Scenariusz}
\begin{enumerate}
\item Gracze się logują.
\item Gracz pierwszy proponuje przez czat mecz innym graczom (pokaz działania czatu).
\item Gracz pierwszy zakłada mecz i proponuje pozostałym siedmiu mecz.
\item Jeden z graczy się nie zgadza, mecz zostaje zerwany.
\item Gracz drugi proponuje mecz, tym razem wszyscy się zgadzają.
\item Mecz się rozpoczyna, ale w pewnym momencie założyciel wyciąga wtyczkę sieciową z gniazdka, traci połączenie, mecz jest zerwany.
\item Zostaje założony trzeci mecz, wszyscy się podłączają.
\item Zostaje rozegrany mecz towarzyski. W trakcie jego trwania uczestnicy testów logują się jako widzowie i obserwują rozgrywkę.
\item Zostaje założony ranking ,,punkty w meczach towarzyskich'' przez pracownika.
\end{enumerate}

\subsection{Test systemu ,,obrabiania'' wyników turnieju przy piątej iteracji}

\subsubsection{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.

\subsubsection{Scenariusz}
\begin{enumerate}
\item Turniej się kończy.
\item Sędzia otrzymuje raport o turnieju.
\item Sędzia postanawia ogłosić wyniki w trzech rankingach: największa liczba PKL-i, najbardziej ,,utopione'' kontrakty, najbardziej niedolicytowane kontrakty.
\item Sędzia wysyła wyniki do serwera.
\item 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.
\end{enumerate}

{\bf{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.

\subsection{Test personalizacji wyglądu aplikacji klienckiej przy szóstej iteracji}

\subsubsection{Warunki początkowe}
System działa, zostało przeprowadzone szkolenie sędziów i pracowników, zostały przeprowadzone testy poprzednich iteracji. 

\subsubsection{Scenariusz}
\begin{enumerate}
\item Loguje się czterech graczy.
\item Rozpoczynają partię towarzyską.
\item W czasie trwania partii, każdy z nich co chwilę zmienia jakieś aspekty wyglądu apletu: kolory, ułożenie, styl.
\item Po zakończeniu rozgrywki zachowują zmiany i wylogowują się.
\item Logują się ponownie i zaczynają nową rozgrywkę. Ustawienia wyglądu zachowały się.
\end{enumerate}

\subsection{Test języków oraz historii sławnych rozgrywek przy siódmej iteracji}

\subsubsection{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.

\subsubsection{Scenariusz}
\begin{enumerate}
\item Widz loguje się do systemu.
\item Klika na listę dawnych rozgrywek - zakładka ,,Sławne''.
\item Widz przegląda dwie rozgrywki.
\item Widz się wylogowuje.
\end{enumerate}


\newpage
\section{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:
\begin{description}
\item[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ć.
\item[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.
\item[bot oglądający] Bot, który tylko podchodzi do stolików, ogląda rozgrywki i pilnuje, czy wszystkie komunikaty do niego dochodzą.
\end{description}

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 \wfp.
\end{document}

