załącznik nr 1 do projektu umowy

Załącznik nr 1 do umowy CUI/ZP/PN/......./2015
Załącznik nr 1 do umowy nr CUI/ZP/PN/...../2015
I. Wymagania funkcjonalne:
1. Aplikacja webowa
1.1. Zarządzanie użytkownikami – aplikacja webowa powinna umożliwiać zarządzanie
użytkownikami. Wyróżniono dwa typy kont:
a)
konto wewnętrzne aplikacji – hasło przechowywane w postaci zaszyfrowanej
w bazie danych
b)
konto LDAP – nie przechowuje hasła, uwierzytelnienie następuje poprzez
usługę LDAP będącą w posiadaniu Zamawiającego; aby umożliwić powiązanie
konta z LDAP należy przygotować okno dialogowe z możliwością stronicowanego
przeglądania, sortowania oraz wybory konta w LDAP; wybór konta w LDAP
powoduje, że podstawowe dane użytkownika są automatycznie zaimportowane
Widok zarządzania użytkownikami powinien realizować następujące funkcje:
a)
stronicowane przeglądanie listy użytkowników systemu (z możliwością
sortowania oraz filtrowania po polach kontrolerach)
b)
dodawanie nowego użytkownika
c)
edycja istniejącego użytkownika
Wszystkie dane wprowadzane / modyfikowane powinny być walidowane
uniemożliwiając wpisanie niepoprawnych danych np. „login już istnieje”.
Do każdego konta może być przypisanych od 0...n ról opisanych w punkcie „Moduł
uprawnień” określających uprawnienia danego użytkownika w systemie.
1.2.
Moduł uprawnień
a)
System powinien definiować role, uprawnienia oraz macierz uprawnień tj.
przypisań uprawnień do ról. Jedno uprawnienie może być przypisane do 0...n ról.
b)
Do każdego widoku lub modułu aplikacji webowa powinny być przypisane
następujące uprawnienia:
• Ograniczony dostęp do odczytu – pozwala tylko na podgląd danych
utworzonych przez danego użytkownika
• Ograniczony dostęp do zapisu – pozwala tylko na podgląd oraz modyfikację
danych utworzonych tylko przez danego użytkownika
• Pełny dostęp do odczytu – pozwala na podgląd danych utworzonych przez
dowolnego użytkownika
• Pełny dostęp do zapisu – pozwala na podgląd i modyfikację danych
utworzonych przez dowolnego użytkownika
c) System powinien definiować minimum następujące role z przypisanymi
uprawnieniami:
• Kontrolowanie – uprawnienie 'Ograniczony dostęp do zapisu' dla grup
widoków związanych z kontrolą kursów oraz kontrolą przystanków,
'Ograniczony dostęp do odczytu' dla modułu analityczno-statystycznego oraz
kalendarza zadań kontrolera.
• Raportowanie – 'Pełny dostęp do zapisu' dla modułu raportowego
• Administrowanie do odczytu – posiada uprawnienia 'Pełny dostęp do odczytu'
wszystkich widoków oraz modułów.
• Administrowanie pełne – posiada uprawnienia 'Pełny dostęp do zapisu'
Strona 1 z 17
Załącznik nr 1 do umowy CUI/ZP/PN/......./2015
wszystkich widoków oraz modułów
1.3.
Grupy i parametry kontroli
Użytkownik systemu z odpowiednimi uprawnieniami powinien mieć możliwość
definiowania słownika grup i parametrów kontroli oddzielnie dla (w załączniku 1
przedstawiono początkową konfigurację):
a)
kontrola kursu (kontrola z zewnątrz)
b)
kontrola kursu (kontrola w pojeździe)
c)
kontrola przystanku (słupek)
d)
kontrola przystanku (wiata)
Użytkownik z uprawnieniami administracyjnymi może zmieniać istniejące oraz
dodawać nowe grupy i parametry. Jedna grupa zawiera 0...n parametrów, gdzie każdy
parametr ma oprócz nazwy, opisu, flagi aktywny itp. jeden z następujących typów:
a)
pole tak / nie
b)
pole lista wyboru (słownik z możliwością ustalenia dozwolonych wartości)
Celem tworzenia powyższego słownika jest umożliwienie modyfikowania zakresu
kontroli jakości np. oznakowania czy stanu technicznego bez
potrzeby
wprowadzania zmian programistycznych.
Przykład użycia: Administrator chce rozszerzyć zakres kontroli kursu wewnętrznego.
W grupie 'Obsługa' dodaje nowy parametr 'Zapowiedzi głosowe' z listą wyboru ('Za
ciche', 'Niepoprawne', 'Wyłączone'). Po synchronizacji z poziomu aplikacji mobilnej
– zmiany są od razu widoczne w aplikacji mobilnej oraz umożliwiają kontrolerowi
przy okazji badania kontroli kursu na określenie jakości zapowiedzi głosowych.
Zmiany dokonane w słowniku grup i parametrów powinny być także od razu
widoczne w generowanych raportach.
1.4.
Zarządzanie rozkładami jazdy
a)
stronicowane przeglądanie zaimportowanych rozkładów jazdy
b)
walidacja oraz import nowego rozkładu jazdy w pliku GTFS (ang. General
Transit FeedSpecification) rozszerzonego o następujące dane:
• Plik routes.txt rozszerzony o dwie kolumny: valid_from oraz valid_until
określające odpowiednio: datę ważności rozkładu początkową oraz końcową
• Plik trips.txt rozszerzony o kolumnę brigade_id z numerem brygady
Aktualne pliki GTFS publikowane są na portalu: http://www.wroclaw.pl/opendata/opendata/rozklady/OtwartyWroclaw_rozklad_jazdy_GTFS.zip
1.5. Kontrole kursów – grupa widoków pozwalająca na przeglądanie, dodawanie nowych
oraz modyfikację istniejących kontroli kursów:
a)
Przeglądanie kontroli
Dla każdego rekordu powinna być widoczne informacje:
• zakres kontroli (w pojeździe, z zewnątrz, potoki pasażerskie, punktualność)
• data kontroli
• czy kontrola zawiera dokumentację zdjęciową
Należy zapewnić możliwość sortowania po polach:
• symbol słupka,
• linia,
• nazwa przystanku,
• czas planowanego odjazdu,
• data kontroli
Należy zapewnić możliwość filtrowania po:
• kontrolerach (wybór 1...n kontrolerów lub wszyscy)
Strona 2 z 17
Załącznik nr 1 do umowy CUI/ZP/PN/......./2015
•
symbol słupka (z możliwością odfiltrowania po symbolu słupka lub nazwie
przystanku)
• dacie kontroli (zakres od.. do)
b)
Dodawanie kontroli kursu
• Wyszukanie kursu do kontroli dla zadanego przystanku oraz czasu kontroli na
podstawie aktualnego rozkładu – powinna pokazać się lista kolejnych kursów dla
zadanych parametrów z możliwością wyboru jednego z nich (podlegającego
kontroli)
• Określenie pól tj. data kontroli, numer boczny, kurs niestwierdzony, uwagi
• Określenie punktualności oraz potoków pasażerskich na kolejnych
przystankach danego kursu; na podstawie liczby pasażerów wsiadających oraz
wysiadających oraz pomiaru poprzedniego przystanku następuje automatyczne
zliczanie pasażerów w pojeździe (lub po kliknięciu przycisku 'Oblicz pasażerów')
• Określenie wyników kontroli kursu na podstawie grup / parametrów
zdefiniowanych przez administratora dla kontroli kursu z zewnątrz
• Określenie wyników kontroli kursu na podstawie grup / parametrów
zdefiniowanych przez administratora dla kontroli kursu z pojazdu
c)
Edycja kontroli kursu – możliwość zmiany danych określonych w b) z
wyjątkiem kontrolowanego kursu.
Należy zaimplementować funkcję zarządzania zdjęciami z kontroli tj.: możliwość
wgrania zdjęcia z poziomu aplikacji webowej, możliwość obejrzenia zdjęć wgranych
(za pomocą aplikacji webowej lub w aplikacji mobilnej) a także możliwość
usunięcia zdjęcia.
1.6. Kontrole przystanków – grupa widoków pozwalająca na przeglądanie, dodawanie
nowych oraz modyfikację istniejących kontroli przystanków (oddzielnie dla słupka i
oddzielnie dla wiaty):
a)
Listowanie
• Możliwość sortowania po polach:
•
symbol słupka,
•
linia,
•
nazwa przystanku,
•
data kontroli
• Możliwość filtrowania po:
•
kontrolerach (wybór 1...n kontrolerów lub wszyscy)
•
symbol słupka (z możliwością odfiltrowania po symbolu słupka lub
nazwie węzła)
•
dacie kontroli (opcjonalnie od … opcjonalnie do)
b)
Dodawanie kontroli przystanku
•
Wyszukanie przystanku do kontroli (po jego nazwie lub symbolu
słupka)
•
Określenie pól tj. data kontroli, uwagi
Określenie wyników kontroli słupka na podstawie grup / parametrów
zdefiniowanych przez administratora dla kontroli kursu
c)
Edycja – możliwość zmiany danych określonych w b) z wyjątkiem
kontrolowanego przystanku. Należy zaimplementować funkcję zarządzania
zdjęciami z kontroli tj.: możliwość wgrania zdjęcia z poziomu aplikacji webowej,
możliwość obejrzenia zdjęć wgranych (za pomocą aplikacji webowej lub w aplikacji
mobilnej) a także możliwość usunięcia zdjęcia.
Strona 3 z 17
Załącznik nr 1 do umowy CUI/ZP/PN/......./2015
1.7. Moduł statystyczno-analityczny umożliwiający przedstawienie zagregowanych
danych w postaci interaktywnego wykresu (wykresów):
a)
Statystyka kontrolerów – interaktywny wykres pokazujący liczbę
przeprowadzonych kontroli przystanków (lub kursów – do wyboru) w zadanym
przez użytkownika zakresie dat przez każdego z kontrolerów tj. seriami danych
powinni być kontrolerzy. Po wyświetleniu wykresu powinna istnieć możliwość
wyłączenia wybranego (wybranych) kontrolerów oraz możliwość przybliżenia lub
oddalenia (tzw. zoom).
b)
Statystyka uchybień – interaktywne wykresy pokazujące statystykę uchybień
kursów lub przystanków w zadanym czasie. Użytkownik wybiera czy wykres ma
przedstawiać statystykę kontroli kursów czy przystanków oraz zakres dat kontroli.
Na pierwszym wykresie użytkownik widzi dwie serie:
• liczbę przeprowadzonych kontroli spełniających kryteria
• liczbę dostrzeżonych uchybień (tj. parametrów kontroli wskazanych jako
uchybienie)
Serie są pogrupowane wg grupy. Kliknięcie na wykresie na wybraną grupę powoduje
pojawienie się drugiego wykresu z jedną serią danych przedstawiającą liczbę
parametrów kontroli z wybranej grupy wskazanych jako uchybienie)
1.8. Audyt – zmiany oraz modyfikacje rekordów w aplikacji powinny być audytowane
(tj. rejestrowane) w zakresie :
a)
Kto i kiedy utworzył dany rekord
b)
Kto i kiedy ostatnio modyfikował dany rekord
Ma to zastosowanie do następujących danych:
a)
Użytkownik
b)
Kontrola kursu
c)
Kontrola słupka
d)
Kontrola wiaty
e)
Grupa i parametr kontroli
f)
Raport
g)
Rozkład
1.10. Moduł zadań i harmonogramowania pracy kontrolera
Administrator systemu powinien mieć możliwość tworzenia harmonogramu zadań dla
kontrolerów. W tym celu należy przygotować grupę widoków pozwalającą na:
a)
stronnicowe przeglądanie, tworzenie i modyfikację zadań, gdzie jedno
zadanie określa:
• czego dotyczy kontrola (kontrola przystanku / kontrola kursów)
• nazwa zadania
• opis zadania
b)
kalendarz pozwalający na dodanie oraz modyfikację następujących wpisów:
• czas pracy kontrolera (od... do... )
• praca biurowa (od... do ...)
• praca w terenie (od... do...) - powinno być możliwe przypisane zadania do
realizacji z listy dostępnych zadań
• urlop lub święto (trwające cały dzień)
Kalendarz powinien prezentować harmonogram pracy kontrolera w następujących
układach
• układ dzienny
• układ tygodniowy
Strona 4 z 17
Załącznik nr 1 do umowy CUI/ZP/PN/......./2015
• układ miesięczny
z możliwością przejścia do kolejnych okresów (np. dla układu dziennego możliwość
przejścia do dnia poprzedniego lub następującego) oraz modyfikacji wpisów z
poziomu kalendarza. Należy zapewnić funkcję typu przeciągnij-upuść (and. drag and
drop) wewnątrz komponentu, która pozwoli na:
• przeciągnięcie wybranego wpisu na inny dzień lub inną godzinę
• zmiana "wysokości" wybranego wpisu tj. godzina rozpoczęcia pozostaje bez
zmian a godzina zakończenia zmienia się odpowiednio
W układzie dziennym system powinien umożliwić uprawnionemu użytkownikowi
jednoczesną pracę na kalendarzu kilku kontrolerów, tj. obok siebie powinny
znajdować się wpisy przypisane do wielu kalendarzy.
Dodatkowo system powinien uniemożliwić na przydzielenie tego samego zadania do
realizacji w tym samym czasie przez więcej niż jednego kontrolera tj. jedno zadanie
w danym czasie może być realizowane tylko przez jednego kontrolera(z możliwością
definiowania wyjątków od tej reguły).
Użytkownik z uprawnieniami kontrolera (tj. przypisaną rolą kontrolowanie)
powinien móc podejrzeć swój kalendarz w trybie tylko do odczytu.
1.11. Moduł mapowy
Należy udostępnić stronę lub grupę stron pozwalającą na prezentację danych o
lokalizacji kontrolera na podkładzie mapowym.
Parametry wejściowe:
- data i godzina początkowa
- data i godzina końcowa
- wybrany kontroler (rozwijana lista kontrolerów)
Dla zadanych parametrów należy wyszukać oraz nanieść na mapę tzw. punkty ciepła
miejsc w których kontroler przebywał przeprowadzając kontrole.
1.12. Moduł raportowy – aplikacja webowa powinna pozwolić na tworzenie lub import
szablonu raportu z zewnętrznego narzędzia do tworzenia raportów (zastosowanie
narzędzi umożliwiających tworzenie dowolnych raportów w oparciu o SQL oraz
Business Intelligence). Funkcjonalność powinna pozwolić na używanie nowego raportu
bez zmian programistycznych w aplikacji webowej.
Aplikacja webowa powinna udostępniać dwa osobne widoki:
a)
Zarządzanie raportami:
• stronicowane przeglądanie raportów dostępnych w systemie z możliwością
sortowania po nazwie raportu
• dodawanie oraz modyfikację istniejącego raportu
b)
Raporty:
• podgląd wybranego raportu
• generowanie i eksport wybranego raportu w formacie . xlsx zgodnie z
formatem UTF-8
2. Aplikacja mobilna
2.1. Użytkownik powinien mieć możliwość uruchomienia menu podręcznego na każdym
z ekranów wymienionych w pkt. 2.2 (oprócz ekranu logowania). Menu powinno
umożliwić szybkie przejście do jednego z następujących widoków:
a)
Ekran mapy
b)
Ekran historii kontroli
Strona 5 z 17
Załącznik nr 1 do umowy CUI/ZP/PN/......./2015
c)
Ekran historii synchronizacji
Dodatkowo z poziomu menu powinna być możliwość przeprowadzenia synchronizacji
danych pomiędzy aplikacją webową oraz mobilną tak jak opisano w pkt. 3.
2.2.
Ekrany
a)
Ekran logowania – umożliwia uwierzytelnienie kontrolera za pomocą loginu i
hasła, które są w tle przesyłane do Aplikacji webowej w celu sprawdzenia. Jeżeli
autoryzacja została zakończona sukcesem następuje przejście do ekranu mapy w
przeciwnym przypadku kontroler otrzymuje informacje o błędzie np. błędny login
i/lub hasło, brak połączenia z Internetem.
b)
Ekran mapy - na podkładzie mapowym oraz w panelu bocznym kontroler
powinien widzieć wszystkie słupki przystankowe najbliższego węzła
przystankowego z możliwością ich wyboru zarówno z mapy jak i panelu bocznego.
Odległość służąca do określenia okolicznych słupków powinna być odczytana z
modułu GPS. Alternatywnie kontroler powinien także móc wyszukać przystanek
wpisując część jego nazwy lub symbolu słupka.
Z widoku ekran mapy kontroler może przejść do ekranu kontroli ruchu wybierając 1n okolicznych słupków przystankowych lub przejść do kontroli słupka lub wiaty
wybierając jeden z okolicznych słupków przystankowych. Kontroler powinien mieć
zablokowaną możliwość pracy z systemem w przypadku wyłączenia modułu GPS na
widoku mapy oraz zablokowaną możliwość rozpoczęcia kontroli do czasu ustalenia
lokalizacji GPS.
c)
Ekran kontroli ruchu – powinien umożliwić szybką kontrolę kursów z
poziomu przystanku w zakresie punktualności oraz potoków pasażerskich. Interfejs
powinien być zaprojektowany w sposób ergonomiczny tak, aby możliwa była
jednoczesna kontrola kilku kursów. Kontroler powinien mieć cały czas podgląd do
najbliższych rozkładowych odjazdów z wybranych słupków, posortowanych wg
godziny odjazdu. Kontroler identyfikuje dany kurs na podstawie słupka, linii,
kierunku, numeru brygady oraz rozkładowego czasu odjazdu z danego słupka,
określa numer boczny (obowiązkowo), punktualność (opcjonalnie) oraz potoki
pasażerskie (opcjonalnie). Wyjątkiem obowiązku podania numeru bocznego jest
sytuacji stwierdzenia, że dany kurs nie został zrealizowany. Należy zapewnić
możliwość przeprowadzenia kontroli kursu z zewnątrz w zakresie grup i parametrów
zdefiniowanych dla kontroli kursów z zewnątrz (konfiguracja początkowa w
załączniku 1) bez konieczności opuszczania bieżącego widoku i utraty danych
wprowadzonych a jeszcze nie zapisanych tj. bez zmiany kontekstu.
d)
Ekran kontroli kursu – powinien umożliwiać kontrolę kursu z poziomu
pojazdu w zakresie dostrzeżonych uchybień (konfiguracja początkowa w załączniku
1), godzin przyjazdu oraz godzin odjazdu na kolejnych przystankach (tj. system
powinien pozwolić na przejście do kolejnych przystanków), wykonać dokumentację
zdjęciową, zmierzyć potoki pasażerskie na kolejnych przystankach. Liczba osób w
pojeździe (tj. odjeżdżających) na kolejnych przystankach powinna się zliczać
automatycznie na podstawie danych z poprzednich pomiarów oraz liczby osób
wsiadających oraz wysiadających.
e)
Ekran kontroli słupka – powinien umożliwiać kontrolę słupka w zakresie
dostrzeżonych uchybień, wykonać dokumentację zdjęciową, określić poprawność
wywieszonych rozkładów jazdy. W celu określenia poprawności wywieszonych
Strona 6 z 17
Załącznik nr 1 do umowy CUI/ZP/PN/......./2015
rozkładów system powinien odczytać dane rozkładowe i wyświetlić listę rozkładów
dla danego słupka. Kontroler dla każdego z kontrolowanych rozkładów może
wybrać jedną z opcji słownikowych:
• Tak (rozkład poprawny)
• Nie (rozkład z niepoprawną datą ważności, należy umożliwić kontrolerowi
wpisanie daty)
• Nieczytelny
• Brak miejsca (w przypadku braku miejsca na wywieszenie rozkładu)
• Brak
Administrator powinien mieć możliwość modyfikacji ww. słownika w aplikacji
webowej. UWAGA: Należy uwzględnić fakt, że analogiczna funkcjonalność
powinna być dostępna z poziomu aplikacji webowej tj. umożliwiająca dodanie jak i
korektę danych w tym samym zakresie.
f)
Ekran kontroli wiaty - powinien umożliwiać kontrolę wiaty w zakresie
dostrzeżonych uchybień, wykonać dokumentację zdjęciową, określić poprawność
wywieszonych rozkładów jazdy. W celu określenia poprawności wywieszonych
rozkładów system powinien odczytać dane rozkładowe i wyświetlić listę rozkładów
dla danego słupka. Kontroler dla każdego z kontrolowanych rozkładów może
wybrać jedną z opcji:
• Tak (rozkład poprawny)
• Nie (rozkład z niepoprawną datą ważności, należy umożliwić kontrolerowi
wpisanie daty)
• Nieczytelny
• Brak miejsca (w przypadku braku miejsca na wywieszenie rozkładu)
• Brak
Administrator powinien mieć możliwość modyfikacji ww. słownika w aplikacji
webowej. UWAGA: Należy uwzględnić fakt, że analogiczna funkcjonalność
powinna być dostępna z poziomu aplikacji webowej tj. umożliwiająca dodanie jak i
korektę danych w tym samym zakresie.
g)
Ekran historii kontroli – powinien przedstawiać historię kontroli kursów,
słupków oraz wiat przeprowadzonych przez danego użytkownika na danym
urządzeniu w danym dniu. W panelu bocznym powinna być możliwość wyboru dnia
z kalendarza w celu podglądu historii za inny wybrany dzień. Na urządzeniu
powinna być przechowywana historia kontroli z ostatnich 7 dni.
h)
Ekran harmonogramu – powinien przedstawiać harmonogram pracy
kontrolera na dany dzień (domyślnie aktualny dzień). Podobnie jak w ekranie historii
kontroli powinna być możliwość podejrzenia harmonogramu na dzień inny niż
aktualny tj. wcześniejszy lub późniejszy. W tym celu należy w panelu bocznym
udostępnić kalendarz pozwalający na zmianę aktualnie wybranego dnia.
3. Synchronizacja
Pomiędzy aplikacją mobilną oraz webową powinna następować wymiana danych tj.:
• z aplikacji webowej do aplikacji mobilnej, na żądanie, wysyłane są globalne
ustawienia (np. poziom kompresji JPEG), grupy i parametry kontroli, harmonogram
pracy kontrolera, rozkłady jazdy
• z aplikacji mobilnej do aplikacji webowej, na żądanie, wysyłane są wszystkie dane
zebrane w terenie przez kontrolera oraz dokumentację zdjęciową
W tym celu aplikacja webowa powinna udostępniać usługę lub grupę usług webowych (od
Strona 7 z 17
Załącznik nr 1 do umowy CUI/ZP/PN/......./2015
ang. web service) pozwalających na realizację tego zadania.
Należy uwzględnić 3 rodzaje synchronizacji:
• synchronizacja pełna - tj. synchronizacja wszystkich danych w obie strony
• synchronizacja zdjęć - tj. synchronizacja tylko dokumentacji zdjęciowej
• synchronizacja danych = synchronizacja pełna minus synchronizacja zdjęć (tj.
wymień wszystkie dane bez zdjęć)
Należy uniemożliwić kontrolerowi pracę na nieaktualnym rozkładzie jazdy. W tym celu
jeżeli podczas jakiejkolwiek synchronizacji okaże się, że opublikowano nowy rozkład jazdy,
aplikacja mobilna powinna taki rozkład pobrać, zaimportować do lokalnej bazy danych oraz
uniemożliwić pracę do czasu zakończenia importu.
Strona 8 z 17
Załącznik nr 1 do umowy CUI/ZP/PN/......./2015
II. Wymagania niefunkcjonalne:
1. Aplikacja webowa
1.1. Aplikacja webowa powinna współpracować z bazą danych MS SQL Server 2008 lub
nowszą
1.2. Aplikacja webowa powinna zostać zintegrowana z usługą LDAP będącą w
posiadaniu Zamawiającego w zakresie wyszukiwania użytkowników oraz ich
uwierzytelnienia.
1.3. Aplikacja webowa powinna być poprawnie wyświetlana w następujących
przeglądarkach:
a) Firefox w wersji 40 i nowszych
b) Chrome w wersji 44 i nowszych
c) Internet Explorer w wersji 11 i nowszych
d) Opera w wersji 32 i nowszych
1.4. Aplikacja webowa będzie deployowana na serwer Apache Tomcat 8.x
1.5. Eksport raportu z modułu raportowego w formacie .xlsx i powinien być poprawnie
wyświetlany w programie Microsoft Excel 2007 i nowszych. Moduł raportowy powinien
mieć możliwość rozszerzenia w przyszłości o eksport do formatów PDF oraz Microsoft
Word 2007 i nowszych.
2. Aplikacja mobilna:
2.1. Aplikacja mobilna powinna działać na telefonach oraz tabletach z systemem
operacyjnym Android w wersji co najmniej 4.2 (API 17) o następujących parametrach:
a) telefony:
- pamięć: 3 GB RAM
- procesor: czterordzeniowy, 2.7 GHz+
- rozdzielczość: 1440x2560 lub wyższa
- wielkość wyświetlacza: 5,7''
- wyświetlacz: typu Super AMOLED
- aparat: 16MP lub więcej
- LTE
b) tablety:
- pamięć: 3 GB RAM
- procesor: czterordzeniowy, 1,9 GHz+
- rozdzielczość: 1536x2048 lub wyższa
- wielkość wyświetlacza: 8,0''
- wyświetlacz: typu Super AMOLED
- aparat: 8MP lub więcej
- LTE
Dodatkowo wszystkie urządzania powinny spełniać wymagania techniczne aplikacji
mobilnej wymienione w pkt. 2.1.
2.2. Aplikacja mobilna powinna przechowywać dane w sposób trwały tj. przypadkowe
wyłączenie telefonu lub aplikacji nie może skutkować utratą wyników kontroli
zebranych przez kontrolera.
2.3. Aplikacja mobilna nie powinna przechowywać haseł użytkowników w żadnej formie
2.4. Lokalizacja kontrolera określana jest na podstawie danych z systemu GPS
2.5. Aplikacja Android powinna być dystrybuowana poprzez sklep Google Play w kanale
ograniczonym do użytkowników wskazanych przez Zamawiającego.
2.6. Zdjęcia wykonane w aplikacji powinny być zapisywane w formacie JPG/JPEG z
możliwością globalnego ustawienia poziomu kompresji przez administratora.
3. Wykonawca udzieli licencji na oprogramowanie bez ograniczeń dotyczących liczby
Strona 9 z 17
Załącznik nr 1 do umowy CUI/ZP/PN/......./2015
użytkowników, liczby urządzeń oraz liczby instancji systemu w infrastrukturze
Zamawiającego.
4. Wykonawca w momencie odbioru systemu udostępni kompletną instrukcję obsługi w języku
polskim w zakresie użytkowania oraz administrowania aplikacją webową oraz instrukcję
użytkowania aplikacji mobilnej. Wymagania dotyczące dokumentacji zostały podane w
załączniku nr 3 do Umowy.
5. Wykonawca przeprowadzi szkolenie w zakresie użytkowania oraz administracji aplikacji:
a) dla użytkowników: minimum jedno szkolenie zakończone testem,
b) dla administratorów: minimum jedno szkolenie,
c) na żądanie Zamawiającego w przypadku zmian w programie.
6. Czas reakcji na zgłoszenia w systemie HelpDesk został opisany w załączniku nr 2 do
Umowy.
7. Wykonawca w momencie odbioru systemu dostarczy dokumentację administracyjną
obejmującą konfigurację aplikacji webowej na serwerze Tomcat 8.x
Strona 10 z 17
Załącznik nr 1 do umowy CUI/ZP/PN/......./2015
III. Raporty
Wykonawca powinien przygotować 8 szablonów raportów z czego 6 dotyczących kontroli kursów
oraz 2 dotyczące kontroli przystanków.
Raporty z kontroli kursów:
1. Raport „Dane źródłowe” - lista pomiarów za zadany okres czasu wybranego kontrolera (z
możliwością wyboru kilku lub wszystkich kontrolerów) oraz linii (z możliwością wyboru jednej,
wielu, grupy – zdefiniowanej w GTFSlub wszystkich linii) posortowana wg daty i czasu
przeprowadzenia kontroli i zawierającą następujące elementy:
•
•
•
•
•
•
•
data pomiaru,
czas pomiaru,
kontroler (z opcją możliwości jego ukrycia),
nr słupka przystankowego,
nr linii (1, 2, 3,..., 10, 11, 12,...)
nr boczny pojazdu,
brygada,
oraz listę grupy i parametry kontroli dla kontroli przeprowadzanych z zewnątrz i wewnątrz
pojazdu
2. Raport „Po liniach” - lista pomiarów za dany okres czasu wybranego kontrolera (z możliwością
wyboru kilku lub wszystkich kontrolerów) oraz linii (z możliwością wyboru jednej, wielu, grupy
– zdefiniowanej w GTFS lub wszystkich linii) posortowana według kolejności linii, przystanku,
daty i czasu przeprowadzenia kontroli i zawierająca następujące elementy:
•
•
•
•
•
data pomiaru,
czas pomiaru,
kontroler (z opcją możliwości jego ukrycia),
nr boczny pojazdu,
brygada,
oraz listę grupy i parametry kontroli dla kontroli przeprowadzanych z zewnątrz i wewnątrz
pojazdu
3. Raport „Po kontrolerach” - lista pomiarów za dany okres czasu wybranego kontrolera (z
możliwością wyboru kilku lub wszystkich kontrolerów) oraz linii (z możliwością wyboru jednej,
wielu, grupy– zdefiniowanej w GTFS lub wszystkich linii) posortowaną według kontrolera a
następnie według daty i czasu przeprowadzenia kontroli i zawierającą następujące elementy:
• data pomiaru,
• czas pomiaru,
• nr słupka przystankowego,
• nr linii,
• nr boczny pojazdu,
• brygada,
oraz listę grupy i parametry kontroli dla kontroli przeprowadzanych z zewnątrz i wewnątrz
pojazdu
Strona 11 z 17
Załącznik nr 1 do umowy CUI/ZP/PN/......./2015
4. Raport „Po uchybieniach” - lista pomiarów za dany okres czasu wybranego kontrolera (z
możliwością wyboru kilku lub wszystkich kontrolerów) oraz linii (z możliwością wyboru jednej,
wielu, grupy– zdefiniowanej w GTFS lub wszystkich linii) z posortowaniem na rodzaj
uchybienia zgodnie z listą parametrów kontroli z punktu 1 a następnie według daty i czasu
przeprowadzenia kontroli i zawierającą następujące elementy:
• data pomiaru,
• czas pomiaru,
• nr słupka przystankowego,
• nr boczny pojazdu,
• brygada,
• inne uwagi
oraz opis do listy parametrów kontroli
5. Raport „Statystyka pomiarów” - za dany okres czasu z wyszczególnieniem w danym dniu liczby
uchybień z podziałem na parametry kontroli odnoszące się do punktualności (liczba kursów
punktualnych, opóźnionych, przed czasem, nie stwierdzonych oraz kursów łącznie) oraz jakości
(pozostałe parametry - liczba uchybień w każdej kategorii bez opisów słownych). W
podsumowaniu powinno się uwzględnić procentowy udział danego uchybienia w stosunku do
liczby kursów kontrolowanych.
6. Raport „Statystyka pracy kontrolera” - (wszystkich bądź wybranych) za dany okres czasu: dla
każdego kontrolera - czas pracy w każdym dniu (liczony od czasu rozpoczęcia pierwszej
kontroli do czasu ostatniej kontroli), liczbę stwierdzonych przez niego uchybień z podziałem jak
w punkcie 5 w każdym dniu oraz podsumowaniem liczby poszczególnych uchybień dla
zadanego okresu czasu z procentowym udziałem danego uchybienia w stosunku do liczby
kursów kontrolowanych.
Raporty z kontroli przystanków:
7. Protokół z kontroli przystanków - w raporcie powinny być ujęte następujące pola:
• Lp. – narastająca liczba kontrolowanych słupków przystankowych,
• Numer słupka przystankowego,
• Nazwa słupka,
• Godzina kontroli,
• Numer kontrolowanego rozkładu linii (linia)
• Data ważności rozkładu linii (ważny od)
• Rozkłady z podziałem na słupek i wiata; wartości
o Tak (rozkład poprawny)
o Nie (rozkład z niepoprawną datą ważności, należy wyświetlić datę ważności
rozkładu zapisaną przez kontrolera)
o Nieczytelny
o Brak miejsca (w przypadku braku miejsca na wywieszenie rozkładu)
o Brak
• Stan infrastruktury przystankowej z podziałem na słupek i wiatę (na podstawie grup i
parametrów zdefiniowanych w systemie)
Strona 12 z 17
Załącznik nr 1 do umowy CUI/ZP/PN/......./2015
Przy generowaniu raportu powinna istnieć możliwość opcjonalnego wyłączenia stanu
infrastruktury przystankowej.
8. Raport dla potrzeb oceny infrastruktury przystankowej wykorzystujący pola dla raportu 7.
• Nagłówek - Protokół nr……/…./RRRR z kontroli infrastruktury przystankowej w
dniu…..”, pozostały nagłówek bez zmian,
gdzie RRRR - rok
• należy ująć pola: Lp, numer słupka przystankowego, Nazwa słupka, Godzina
kontroli, Stan infrastruktury przystankowej z podziałem na słupek i wiatę,
• w stopce należy ująć tylko numer kontrolera.
Strona 13 z 17
Załącznik nr 1 do umowy CUI/ZP/PN/......./2015
Załącznik 1. Opis początkowej konfiguracji systemu
Kontrola przystanku (słupek)
Słupek
•
•
•
•
•
•
•
•
•
•
•
•
•
•
brak rozkładu (rozkładów) jazdy
rozkład jazdy nieaktualny
nieprawidłowa kolejność wywieszonych rozkładów jazdy
rozkłady jazdy nieczytelne, zniszczone (zamoknięte, wypłowiałe)
brak informacji pasażerskiej
brak informacji o zmianach trasy
brak informacji teleadresowej (adresy / telefony)
brak cennika biletów
brak zasad korzystania z komunikacji zbiorowej
osłonki foliowe na rozkłady i informacje brudne, wymagają wymiany
osłonki foliowe na rozkłady i informacje pogięte lub uszkodzone, wymagają wymiany
brak kaptura (przystanek nieczynny)
brak numeru (numerów) linii
nieprawidłowa kolejność numerów linii
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Stan techniczny
•
•
•
•
•
•
•
osłona gabloty (poliwęglan) zamalowana lub porysowana
osłona gabloty (poliwęglan) niezamocowana do ramy gabloty
niezamknięta gablota
brak śrub (śruby) zamykających gablotę
pogięta rama zamykająca gablotę
wkład w gablocie uszkodzony (pogięty, zdeformowany), wymaga wymiany
uszkodzona gablota – wymaga naprawy
Strona 14 z 17
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Załącznik nr 1 do umowy CUI/ZP/PN/......./2015
Kontrola przystanku (wiata)
Wiata
•
•
•
•
•
•
•
•
•
•
•
brak rozkładu (rozkładów) jazdy
rozkład jazdy nieaktualny
nieprawidłowa kolejność wywieszonych rozkładów jazdy
rozkłady jazdy nieczytelne, zniszczone (zamoknięte, wypłowiałe)
brak informacji pasażerskiej
brak informacji o zmianach trasy
brak informacji teleadresowej (adresy / telefony)
brak cennika biletów
brak zasad korzystania z komunikacji zbiorowej
osłonki foliowe na rozkłady i informacje brudne, wymagają wymiany
osłonki foliowe na rozkłady i informacje pogięte lub uszkodzone, wymagają wymiany
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Stan techniczny
•
•
•
•
•
•
•
osłona gabloty (poliwęglan) zamalowana lub porysowana
osłona gabloty (poliwęglan) niezamocowana do ramy gabloty
niezamknięta gablota
brak śrub (śruby) zamykających gablotę
pogięta rama zamykająca gablotę
wkład w gablocie uszkodzony (pogięty, zdeformowany), wymaga wymiany
uszkodzona gablota – wymaga naprawy
Strona 15 z 17
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Załącznik nr 1 do umowy CUI/ZP/PN/......./2015
Kontrola kursu (kontrola z zewnątrz)
Oznakowanie linii
• numer linii z przodu
• numer linii z boku
• numer linii z tyłu
• kierunek jazdy z boku (wybór z listy)
• kierunek jazdy z przodu (wybór z listy)
słownik: [...bez zastrzeżeń..., niewłaściwy, brak]
słownik: [...bez zastrzeżeń..., niewłaściwy, brak]
słownik: [...bez zastrzeżeń..., niewłaściwy, brak]
słownik: [...bez zastrzeżeń..., niewłaściwy, brak]
słownik: [...bez zastrzeżeń..., niewłaściwy, brak]
Oznakowanie pojazdu
• brak numeru ewidencyjnego pojazdu z przodu
• brak numeru ewidencyjnego pojazdu z boku
• brak numeru ewidencyjnego pojazdu z tyłu
• numer brygady
• niesprawne tablice świetlne
Tak / Nie
Tak / Nie
Tak / Nie
słownik: [..., niezgodny z rozkładem jazdy, brak]
Tak / Nie
Oznakowanie dodatkowe
• niewłaściwe malowanie autobusu
• brak wymaganych herbów
• brak napisu „wejście” przy drzwiach autobusu
• brak napisu „wyjście” przy drzwiach autobusu
• brak informacji o wsiadaniu tylko przednimi drzwiami
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Czystość zewnętrzna
• brudna szyba przednia
• brudna szyba z prawej strony
• brudna szyba tylnia
• niewłaściwa reklama
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tabor
• tabor starszy niż wymagany
• tabor mniejszy niż wymagany
• tabor wysokopodłgowy
Tak / Nie
Tak / Nie
Tak / Nie
Strona 16 z 17
Załącznik nr 1 do umowy CUI/ZP/PN/......./2015
Kontrola kursu (kontrola w pojeździe)
Oznakowanie wewnętrzne
• numer linii
• kierunek jazdy
• opis trasy przejazdów
• niesprawna tablica świetlna
• brak taryfy przewozowej
• brak regulaminu przewozu osób i bagażu ręcznego
słownik: [...bez zastrzeżeń..., niewłaściwy, brak]
słownik: [...bez zastrzeżeń..., niewłaściwy, brak]
słownik: [ ..bez zastrzeżeń..., niewłaściwy, brak]
Tak / Nie
Tak / Nie
Tak / Nie
Stan techniczny
• kasowniki
• brak monitoringu
• brak kasy fiskalnej
• brak ogrzewania pojazdu
• brak oświetlenia pojazdu
słownik: [...bez zastrzeżeń..., za mało, brak]
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Czystość wewnętrzna
• brudna podłoga
• brudne uchwyty
Tak / Nie
Tak / Nie
Zachowanie kierowcy
• nieuprzejmość wobec pasażerów
• brak biegłości w posługiwaniu się językiem polskim
• brak sprzedaży biletów
• brak zapobiegania przejazdu bez ważnego biletu
• brak zapewnienia pomocy osobom niepełnosprawnym
• palenie tytoniu
• długotrwała rozmowa
• brak wymaganego ubioru
• brak widocznego identyfikatora
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Tak / Nie
Strona 17 z 17