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