Uchwała KS PFP z dn. 20.02.2014r. – Lista wymagań do programu

Transkrypt

Uchwała KS PFP z dn. 20.02.2014r. – Lista wymagań do programu
UCHWAŁA KOLEGIUM SEDZIÓW PFP
LISTA WYMAGAŃ DO PROGRAMU KOMPUTEROWEGO
SŁUŻĄCEGO DO PROWADZENIA TURNIEJÓW PFP
PRZYJĘTA NA POSIEDZENIU KOLEGIUM SĘDZIOWSKIEGO
W DNIU 20.02.2014
Kolegium Sędziów PFP proponuje następującą listę założeń do
systemu komputerowego, mającego służyć do prowadzenia
turniejów w Polsce:
1. Program powinien być uruchamiany pod przeglądarką
internetową. Pozwoli to na wyzwolenie się z obciążenia
różnicami w systemach operacyjnych, a także ułatwi
współpracę przez sieć. Umożliwi to również pracę z
wykorzystaniem urządzeń mobilnych.
Jako punkt odniesienia można by przyjąć kilka
najpopularniejszych przeglądarek, jak Safari (MacOS),
Chrome, IE, Firefox, Opera.
2. Program powinien pozwalać na szybkie sporządzenie
protokołu. Musi również umożliwiać wysyłanie dokumentów
do odpowiednich instancji, a także ich eksport do innych
formatów (np. PDF, RTF, DOC) i wydruk.
3. W wersji online mógłby aktualizować odpowiednio zbudowany
skrypt w sieci, przez co można by tak publikować wyniki i
zestawienia niemalże w czasie rzeczywistym. Powinien on
móc na bieżąco publikować wyniki, zestawienia, a także
uwagi czy kary. Oczywiście byłyby to dane nieoficjalne
(oficjalne wyniki znajdują się tylko i wyłącznie w
podpisanym protokole końcowym), ale pozwalałyby śledzić
rozgrywki za pomocą sieci.
4. Dobrze by było, gdyby program pozwalał na „nieliniowy
dostęp”, tzn. umożliwiał wpisanie wyniku spotkania bez
konieczności uzupełniania innych wyników w tym samym
momencie. Przykład: W turnieju toczy się 15 meczów. Mecz
nr 7 zakończył się bardzo szybko, wynik 13:0. Program
umożliwia wpisanie wyniku meczu nr 7, program zapamiętuje
ten wynik i wyświetla go (na ekranie, w sieci). Na końcu
rundy istnieje jeszcze możliwość edycji wyniku, jeśli
został wprowadzony niewłaściwie, potem prowadzący zawody
zatwierdza wyniki i program ostatecznie zapisuje
rezultaty.
5. Sędziowie i Delegat PFP powinni w każdej chwili mieć
możliwość dopisania uwagi, ostrzeżenia czy wykluczenia.
Również zastrzeżeń zgłaszanych przez samych zawodników.
6. Program powinien działać w sposób ciągły, mierząc również
czas. Oznacza to, że organizator Mógłby uruchamiać start
rundy za pomocą programu, a ten wskazywałby czas, gdy
runda się kończy. Oczywiście musiałaby również istnieć
możliwość zatrzymania rundy czy ponownego wystartowania
po omyłkowym wystartowaniu. Oznacza to również, że
program powinien notować czasy poszczególnych zdarzeń,
np. wpisywanych ostrzeżeń, zakończonych meczów. Te dane
nie musiałyby być widoczne w protokole, ale w razie
jakichś protestów, czy wątpliwości zapis czasowy mógłby
bardzo pomóc w ocenie wydarzeń.
7. Program powinien posiadać kilka gotowych szablonów
prowadzenia turniejów (np. każdy-z-każdym, francuski,
szwajcar, szwajcar z Bucholcem, pucharowa drabinka,
odwrócona drabinka, model MPS, itp.), według których, po
prostym wyborze, organizator mógłby prowadzić turniej lub
z pomocą których mógłby zbudować swój własny system.
Turnieje z wymuszonym systemem powinny być wręcz ujęte w
liście wyboru, tak, by organizator mógł wybrać je niemal
automatycznie.
Ten punkt wymaga dogłębnego zastanowienia się, ponieważ
nasz regulamin rozgrywek czasem się zmienia.
Przykład 1: Organizator II eliminacji MPS chce
zainicjować program. Wybiera więc z listy „turniej MPS”,
dalej „eliminacja”, potem wpisuje liczbę drużyn lub ma
już gotową wcześniej listę startową. Enter – program sam
inicjuje odpowiedni system, rozstawiając drużyny do
meczów w odpowiedniej ilości rund i licząc odpowiednio
punkty.
Przykład 2: Organizator chce zorganizować turniej open,
wybiera z listy „eliminacje + finały”, a potem definiuje
sposób rozegrania eliminacji (np. system szwajcarski z
bucholcem, 5 rund) i finałów (np. play off, 32 drużyny).
Program pomaga prowadzić turniej zgodnie z wytycznymi
wskazując aktualnie kwalifikujących się do rundy
finałowej.
8. Program powinien na pewno zawierać szczegółowe
objaśnienia poszczególnych części składowych, np.
systemów, pojęć itp. Będzie to bardzo ważne w przypadku
mniej doświadczonych kierowników zawodów, będzie to też
rozwiewać wszelkie wątpliwości. Program powinien np.
przypominać o niektórych procedurach.
Przykład: Program przypomina o wpisaniu nazwisk delegata,
kierownika i sędziego, a po tej czynności przypomina
kierownikowi zawodów o podaniu nazwisk tych osób do
wiadomości. Jednocześnie program przypomni delegatowi o
konieczności sprawdzenia przygotowania sędziów do pracy.
9. Program powinien traktować wszystkie punkty jako liczby
całkowite i tylko całkowite, wprowadzanie ułamków to
tylko generowanie chaosu.
10.Po wyborze systemu program powinien dawać możliwość
wydruku „strony informacyjnej”, która zawierałaby opis
systemu zastosowanego na turnieju systemu, przyjętego
sposobu liczenia punktów, nazwiska osób funkcyjnych, itp.
11.Program powinien integrować wszystkie dane. Przykład:
sędzia wpisuje ostrzeżenie, opisuje przypadek, a kiedy
chce wskazać drużynę lub osobę może wskazać go na liście
startowej lub na zestawieniu par meczowych.
12.Można rozważyć ograniczenie dostępu do programu, np.
poprzez hasło/pin. Przykład: każda z osób funkcyjnych na
początku turnieju potwierdza w programie swoją obecność i
wpisuje wybrany przez siebie hasło/pin (np. trzy znaki).
Chcąc później dopisać notatkę lub uwagę do protokołu
wpisuje to hasło, a program rozpoznaje osobę, która to
robi i daje jej dostęp do części przeznaczonej dla niej.
13.Jedną z funkcji programu mogłoby być szacowanie czasu
rozegrania rund. Wybierając system kierownik zawodów
mógłby zadać również długość przerw. Drukując listę
wyników program mógłby podawać również szacowany czas
zakończenia turnieju czy przerwy obiadowej.
14.Rozwijając poprzednią funkcję, program mógłby podawać
informacje o pogodzie. Pobieranie tego typu danych ze
stron internetowych jest banalnie proste, program mógłby
pobierać te dane i drukować w pasku informacyjnym po
każdej rundzie albo na „stronie informacyjnej”. Przykład:
program drukuje rozstawienie par do rundy, szacowany czas
rozpoczęcia i zakończenia oraz prawdopodobieństwo
wystąpienia opadów podczas trwania rundy.
15.Program powinien automatycznie pobierać dane typu numery
licencji zawodników i osób funkcyjnych oraz informacje o
ewentualnych zawieszeniach itp.
16.Pod żadnym pozorem program nie może wymagać stałego ani
nawet inicjującego połączenia z Internetem. Współpraca
online powinna być jedynie możliwością i udogodnieniem, a
nie wymogiem.
17.Razem z programem powinna zostać stworzona witryna
internetowa, która mogłaby współpracować z programem
online. Mogłaby ona funkcjonować jako nieoficjalna
podstrona oficjalnej strony federacji. Wymogiem co do tej
strony byłaby możliwość pracy bez dodatkowej obsługi,
tzn. witryna wymieniałaby dane z programem i publikowała
je automatycznie, bez wymogu akceptacji czy moderacji.
w imieniu Kolegium Sędziów PFP
p.o. Przewodniczącego
Maciej Ziółkowski

Podobne dokumenty