opis przedmiotu zamówienia (opz)

Transkrypt

System Informatyczny Wojewódzkich Centrów Powiadamiania Ratunkowego
Załącznik nr 1
OPIS PRZEDMIOTU ZAMÓWIENIA (OPZ)
na zakup i wdrożenie zintegrowanego systemu informatycznego
wojewódzkich centrów powiadamiania ratunkowego,
umożliwiającego przyjęcie i rejestrację zgłoszeń na numer
alarmowy 112 oraz inne numery alarmowe
1
1. Wstęp
Przedsięwzięcie stanowi element projektu pn.: ”System Informatyczny Powiadamiania
Ratunkowego (SI PR)” którego realizacja podyktowana jest koniecznością wdrożenia jednolitych
w skali kraju narzędzi informatycznych wspierających realizację zadań i współdziałanie służb
ustawowo powołanych do przyjęcia i obsługi wywołań alarmowych. System ten będzie stanowił
główny element wyposażenia podmiotów funkcjonujących w ramach systemu powiadamiania
ratunkowego, o których mowa w rozporządzeniu Ministra Spraw Wewnętrznych i Administracji
z dnia 31 lipca 2009 r. w sprawie organizacji i funkcjonowania centrów powiadamiania ratunkowego
i wojewódzkich centrów powiadamiania ratunkowego (Dz. U. z 2009 r. Nr 130, poz. 1073), oraz
komórek organizacyjnych Policji.
W kolejnym etapie realizacji projektu SI PR, System będzie podlegał rozbudowie
o funkcjonalności wskazane przez Zamawiającego.
Rezultatem projektu SI PR będzie:
1.
możliwość obsługi zgłoszeń alarmowych obywateli polskich i cudzoziemców
przebywających na terytorium Rzeczpospolitej Polskiej na jednolity europejski numer 112
oraz inne numery alarmowe;
2. możliwość obsługi zgłoszeń alarmowych osób niepełnosprawnych na numer 112 oraz inne
numery alarmowe;
3. możliwość obsługi zgłoszeń alarmowych osób nie posługujących się językiem polskim na
numer 112 oraz inne numery alarmowe;
4. możliwość obsługi zgłoszeń alarmowych z systemów monitoringu, w tym systemu e-Call;
5. możliwość gromadzenia danych i zapewnienie przepływu informacji niezbędnej do
zarządzania zasobami ratowniczymi PSP, PRM oraz Policji;
6. możliwość natychmiastowej wizualizacji miejsca zgłoszenia, zdarzenia oraz jednostek
ratowniczych na terenie Rzeczpospolitej Polskiej;
7. możliwość określania i monitorowania średniego czasu oczekiwania na przyjęcia
zgłoszenia;
8. możliwość określania i monitorowania średniego czasu reakcji na przyjęte zgłoszenie
(czasu podjęcia czynności przez odpowiednie służby ratownictwa od przyjęcia zgłoszenia);
9. możliwość określenia ilości zgłoszeń oczekujących na odbiór i obsługę z funkcją
powiadomienia o potrzebie wzmocnienia lub zwiększenia ilości stanowisk do odbioru
zgłoszeń;
10. zapewnienie warunków technicznych do współdziałania służb, przekierowywania zgłoszeń
alarmowych do właściwych merytorycznie i miejscowo służb oraz wymiany informacji
w ramach całego systemu obsługi zgłoszeń alarmowych;
11. umożliwienie dystrybucji danych o lokalizacji zgłoszenia, na podstawie informacji
z systemu UKE „Platforma Lokalizacyjno-Informacyjna z Centralną Bazą Danych”,
do podmiotów obsługujących zgłoszenie alarmowe;
W skład Systemu Informatycznego Powiadamiania Ratunkowego (SI PR), docelowo wejdą
następujące moduły systemowe:
1. System Informatyczny Wojewódzkiego Centrum Powiadamiania Ratunkowego (SI WCPR),
2. System Informatyczny Centrum Powiadamiania Ratunkowego (SI CPR),
3. Centralny Punkt Systemu Centrów Powiadamiania Ratunkowego (CP SCPR),
4. System Wspomagania Dowodzenia Państwowego Ratownictwa Medycznego (SWD PRM),
2
5. System Wspomagania Dowodzenia Państwowej Straży Pożarnej (SWD PSP),
6. System Wspomagania Dowodzenia Policji (SWD Policji).
W ramach SI CPR i SI WCPR zapewniony zostanie uniwersalny interfejs, umożliwiający
integrację z systemami podmiotów ratowniczych - systemami klasy SWD.
Przedmiotowe zamówienie dotyczy realizacji modułu Systemu Informatycznego
Wojewódzkich Centrów Powiadamiania Ratunkowego (SI WCPR), którego głównym
zadaniem jest zapewnienie sprawnej obsługi rejestracji wywołań alarmowych, w szczególności na
numery 112, 999, 998, 997 i inne numery alarmowe, a następnie wymiany informacji na temat
zdarzeń i powiązanych z nimi zgłoszeń z systemami informatycznymi służb powołanych ustawowo
do niesienia pomocy. Proces dysponowania siłami i środkami wykorzystywanymi w celach obsługi
zdarzeń będzie wspierany przez systemy wspomagania służb porządku publicznego
i ratownictwa (systemy klasy SWD nie wchodzą w zakres przedmiotowego zamówienia).
Wizualizacja lokalizacji abonenta będzie realizowana w oparciu o aktualnie funkcjonujące
rozwiązanie tymczasowe opierające się o udostępnione przez operatorów telekomunikacyjnych za
pośrednictwem przeglądarki WWW.
Bezpośrednim użytkownikiem SI WCPR będą Wojewódzkie Centra Powiadamiania
Ratunkowego, a pośrednio Centra Powiadamiania Ratunkowego. Ponadto odbiorcą danych
z SI WCPR będą jednostki organizacyjne Policji, Państwowej Straży Pożarnej, Państwowego
Ratownictwa Medycznego oraz inne podmioty ratownicze. Dla potrzeb funkcjonowania SI WCPR
zostanie wykorzystana szkieletowa sieć teleinformatyczna w technologii IP/MPLS, realizowana w
ramach projektu „Ogólnopolska sieć teleinformatyczna na potrzeby obsługi numeru alarmowego
112 (OST112)”.
Przedmiotowe zamówienie jest finansowane w ramach przedsięwzięcia pn. ”Budowa
i wyposażenie Wojewódzkich Centrów Powiadamiania Ratunkowego” realizowanego w Programie
Operacyjnym Infrastruktura i Środowisko (POIŚ) Oś priorytetowa XII.
2. Pojęcia i skróty
Dla potrzeb niniejszego opracowania przyjmuję się następujące definicje skrótów i pojęć:
Skrót/pojęcie
Definicja
Aplikacja SI WCPR
Aplikacja użytkownika Systemu Informatycznego Wojewódzkich Centrów
Powiadamiania Ratunkowego
brak działania środowiska produkcyjnego Systemu, praca nie może być
kontynuowana, operacja krytyczna dla procesu biznesowego jest niemożliwa. Awarie
Krytyczne mają jedną lub więcej z poniższych cech:
a) Dane biznesowe zostały uszkodzone;
b) Funkcjonalność krytyczna („Funkcjonalność Krytyczna”) udokumentowana w
Projekcie Technicznym nie działa;
c) System w zakresie Funkcjonalności Krytycznych przerywa działania i nie daje się
uruchomić pomimo prób;
utrudnia działanie Systemu w środowisku produkcyjnym w zakresie Funkcjonalności
Krytycznej i uniemożliwia działanie Systemu w zakresie pozostałych funkcjonalności.
W tym kontekście „utrudnia” oznacza istnienie sposobu jego obejścia (co może mieć
wpływ na wygodę w użyciu Systemu lub wymagać procedur ręcznych).
„Uniemożliwia” oznacza brak możliwości znalezienia sposobu na jego obejście.
Wszelka awaria nie będąca Awarią Krytyczną lub Awarią Niekrytyczną,
Centrum Powiadamiania Ratunkowego;
Awaria Krytyczna
Awaria Niekrytyczna
Awaria Zwykła
CPR
Dokumentacja
projektowa
Wytworzone przez Wykonawcę zamówienia w ramach realizacji umowy i podlegające
zatwierdzeniu przez Zamawiającego, materiały w formie papierowej, jak również
informacje zapisane na innych nośnikach, w tym nośnikach elektronicznych;
Dyspozytor
Użytkownik Końcowy realizujący obsługę zgłoszeń przyjętych od Operatora w
ramach SWD Policji/ SWD PSP/ SWD PRM;
Funkcjonalność
Cechy funkcjonalne systemu uniemożliwiające realizację operacji krytycznych z
3
Skrót/pojęcie
Definicja
Krytyczna
punktu widzenia przyjęcia i obsługi zgłoszeń alarmowych.
Koordynator
Użytkownik Końcowy realizujący funkcję nadzoru na poziomie WCPR;
PLI CBD
Platforma Lokalizacyjno-Informacyjna z Centralną Bazą Danych, dostarczona przez
Urząd Komunikacji Elektronicznej;
Oprogramowanie
Oprogramowanie Standardowe i Oprogramowanie Aplikacyjne.
Oprogramowanie
Standardowe
oznacza oprogramowanie powszechnie dostępne, będące przedmiotem Dostaw w
ramach realizacji przedmiotu zamówienia, na które producent udziela
Zamawiającemu licencji na warunkach i zasadach określonych w Umowie oraz
umowach licencyjnych Oprogramowania Standardowego, dostarczane przez
Wykonawcę wraz licencją producenta oraz z dokumentacją i aktualizacjami.
Oprogramowanie
Aplikacyjne
oznacza oprogramowanie i skrypty wraz z kompletnymi kodami źródłowymi
wytworzone i dostarczone przez Wykonawcę w ramach przedmiotu zamówienia,
wraz z dokumentacją i aktualizacjami, zgodnie ze Specyfikacją techniczną, opisaną
przez Wykonawcę w złożonej Ofercie, do których Wykonawca przeniesie autorskie
prawa majątkowe na Zamawiającego i MSWiA na warunkach i zasadach określonych
w Umowie.
Ośrodek Krajowy
Centrum serwerowe w oparciu, o które będzie zbudowana architektura systemu SI
WCPR na poziomie centralnym;
Ośrodki Regionalne
Element architektury systemu SI WCPR stanowiący pośredniczącą warstwę serwerów
lokalnych zapewniający krytyczną funkcjonalność w zakresie przyjmowania zgłoszeń
oraz ich obsługi, na potrzeby podsystemów zintegrowanej łączności w obiektach
(ośrodki zostaną zlokalizowane w pomieszczeniach WCPR);
MSWiA
Ministerstwo Spraw Wewnętrznych i Administracji wraz z organami i jednostkami
organizacyjnymi podległymi lub nadzorowanymi przez Ministra Spraw Wewnętrznych
i Administracji
Operator
Użytkownik Końcowy realizujący funkcję przyjęcia zgłoszenia w ramach CPR/WCPR;
PRM
Państwowe Ratownictwo Medyczne;
PSP
Państwowa Straż Pożarna;
SWD
System Wspomagania Dowodzenia klasy dyspozytorskiej „czasu rzeczywistego”
wspomagającego w zakresie przyjęcia i obsługi wywołań alarmowych/zdarzeń;
Podsystem Integracji
Danych
Moduł wymiany danych pomiędzy SI WCPR a innymi systemami zewnętrznymi;
Podsystem
Zintegrowanej Łączności
Moduł komunikacyjny łączności telefonicznej i radiowej zintegrowany z aplikacją SI
WCPR;
Podmiot ratowniczy
Podmiot, o którym mowa w Rozporządzeniu Ministra Spraw Wewnętrznych i
Administracji z dnia 31 lipca 2009 r. w sprawie organizacji i funkcjonowania centrów
powiadamiania ratunkowego oraz wojewódzkich centrów powiadamiania
ratunkowego;
System/SI WCPR
System Informatyczny Wojewódzkich Centrów Powiadamiania Ratunkowego wraz z
zainstalowanym oprogramowaniem standardowym, Aplikacją SI WPCR oraz
infrastrukturą sprzętową. Infrastruktura sprzętowa dzieli się na infrastrukturę
centralną (Ośrodek Krajowy), infrastrukturę regionalną (Ośrodki Regionalne), oraz
sprzęt teleinformatyczny dostarczony w ramach realizacji przedmiotu Zamówienia do
lokalizacji wskazanych przez Zamawiającego;
SI PR
System Informatyczny Powiadamiania Ratunkowego;
Użytkownik końcowy
Użytkownik pełniący w systemie rolę Operatora lub Dyspozytora lub Koordynatora,
wykorzystujący System;
WCPR
Wojewódzkie Centrum Powiadamiania Ratunkowego;
Zgłoszenie
Wywołanie alarmowe przyjmowane przez Operatora w WCPR;
Zdarzenie
Zgłoszenie przekazane przez Operatora do Dyspozytora celem obsługi w SWD;
Zamawiający
Centrum Projektów Informatycznych MSWiA;
Pozostałe pojęcia użyte w dokumencie należy rozumieć zgodnie z ich ogólnie przyjętym
znaczeniem.
3. Przedmiot zamówienia
4
Przedmiotem zamówienia jest zakup i wdrożenie zintegrowanego systemu
informatycznego wojewódzkich centrów powiadamiania ratunkowego (SI WCPR), umożliwiającego
przyjęcie i rejestrację zgłoszeń na numer alarmowy 112 oraz inne numery alarmowe. Przedmiot
zamówienia obejmuje:
1. Przygotowanie projektu technicznego Systemu,
2. Dostawę, instalację i konfigurację infrastruktury sprzętowej, niezbędnej do prawidłowego
funkcjonowania prototypu Systemu wraz z oprogramowaniem standardowym,
3. Udzielenie Zamawiającemu i MSWiA licencji na oprogramowanie standardowe (systemowe,
bazodanowe, pomocnicze) oraz dostarczenie aktualizacji oprogramowania standardowego
wraz z udzieleniem licencji na dostarczone aktualizacje,
4. Wykonanie i wdrożenie prototypu Systemu w lokalizacjach wskazanych przez
Zamawiającego wraz z przeprowadzeniem testów prototypu Systemu,
5. Przeniesienie na Zamawiającego i MSWiA autorskich praw majątkowych do prototypu
Systemu oraz wytworzonej dokumentacji projektowej, z wyłączeniem oprogramowania
standardowego,
6. Przeprowadzenie szkoleń użytkowników-instruktorów oraz administratorów-instruktorów,
w zakresie odpowiednio użytkowania oraz administrowania prototypu Systemu,
7. Pielęgnację prototypu Systemu, polegającą na dostosowaniu prototypu Systemu do potrzeb
Użytkownika końcowego, określonych w trakcie bieżącej eksploatacji prototypu Systemu
oraz na tej podstawie wytworzenie, wdrożenie Systemu w lokalizacjach wskazanych przez
Zamawiającego (20 WCPR oraz Ośrodek Krajowy) wraz z przeprowadzeniem testów
Systemu,
8. Dostawę, instalację i konfigurację infrastruktury sprzętowej, niezbędnej do prawidłowego
funkcjonowania Systemu wraz z oprogramowaniem standardowym, w tym instalację
i konfigurację dostarczanego przez Wykonawcę Oprogramowania na zapewnionych przez
Zamawiającego urządzeniach końcowych o których mowa w rozdz. 5.5 i 5.6.
9. Opracowanie i dostarczenie dokumentacji powykonawczej Systemu,
10. Przeniesienie na Zamawiającego i MSWiA autorskich praw majątkowych do Systemu oraz
wytworzonej dokumentacji, z wyłączeniem oprogramowania standardowego,
11. Przeprowadzenie
szkoleń
dla
użytkowników-instruktorów
oraz
administratorówinstruktorów w zakresie odpowiednio użytkowania oraz administrowania Systemu,
12. Świadczenie usługi gwarancyjnej i serwisu gwarancyjnego w terminie do 31 grudnia 2013
r.,
13. Świadczenie w okresie gwarancyjnym usług nadzoru autorskiego w wymiarze 1500 (tysiąc
pięćset) roboczogodzin, w ramach którego Wykonawca wykonywał będzie prace związane
z modyfikacją Systemu zgodnie z oczekiwaniami Zmawiającego oraz Użytkowników
końcowych.
W zakres zamówienia nie wchodzi zapewnienie infrastruktury teletechnicznej obiektów
WCPR oraz Ośrodków Krajowych i Regionalnych niezbędnych do wdrożenia SI WCPR, co
w szczególności dotyczy zapewnienia po stronie Zamawiającego wymaganej:

infrastruktury LAN i zasilania gwarantowanego.

dostępu do sieci WAN służącej do komunikacji z węzłami OST112 i Ośrodkami Krajowymi,
4. Wymagania wobec przedmiotu zamówienia
Podstawowym celem zamówienia jest wdrożenie systemu teleinformatycznego pod nazwą
System Informatyczny Wojewódzkich Centrów Powiadamiania Ratunkowego (SI WCPR),
wspierającego przyjęcie wywołań alarmowych, co w rezultacie przyczyni się do poprawy
5
bezpieczeństwa obywateli i cudzoziemców przebywających na terenie RP. W celu zapewnienia
pożądanej jakości produktów i ich zgodności z oczekiwaniami użytkownika końcowego, wymagane
jest wykonanie zamówienia z uwzględnieniem podziału na następujące etapy:

Etap I: obejmujący pkt 1 przedmiotu zamówienia - w terminie do 30 dni kalendarzowych
od dnia zawarcia umowy,

Etap
II: obejmujący pkt 2-6 przedmiotu zamówienia - w terminie do 120 dni
kalendarzowych od dnia zawarcia umowy,

Etap III: obejmujący pkt 7-11 przedmiotu zamówienia - w terminie do 180 dni
kalendarzowych od dnia zawarcia umowy,

Etap IV: obejmujący pkt 12-13 przedmiotu zamówienia - w terminie do 31.12.2013 r.
4.1.
Ogólne założenia SI WCPR
W skład Systemu należy zaliczyć następujące produkty:
a) Aplikację SI WCPR;
b) Oprogramowanie standardowe,
c) Infrastrukturę sprzętową niezbędną do prawidłowego działania Systemu.
Zakłada się budowę Aplikacji SI WCPR w oparciu o uniwersalne, dające się wyróżnić komponenty
funkcjonalne (podsystemy):
1. Podsystem przyjęcia zgłoszenia,
2. Podsystem zintegrowanej łączności wraz z systemem rejestracji rozmów,
3. Podsystem baz danych,
4. Podsystem raportowy,
5. Podsystem monitorowania zgłoszeń.
Ogólny opis poszczególnych podsystemów:
Podsystem PRZYJĘCIA ZGŁOSZENIA
Podsystem zapewnia zasadniczą funkcjonalność umożliwiającą Operatorowi rejestrację wywołania
alarmowe w szczególności dla wywołania telefonicznego numeru alarmowego 112, 999, 998, 997
i innych numerów alarmowych (zgłoszenia) przy pomocy uniwersalnego arkusza elektronicznego.
Ponadto, posiada zaimplementowane funkcjonalności wspomagające proces przyjęcia zgłoszenia
poprzez sygnalizację zgłoszeń podobnych, fałszywych. Użytkownik Systemu nie dysponuje siłami
i środkami służb porządku publicznego i ratownictwa, przekazuje jedynie zebrane i dostępne
informacje dotyczące zdarzenia i związanych z nim zgłoszeń (przekazane zdarzenie wraz ze
zgłoszeniami zostają przekazane do6obsługi przez Dyspozytora poszczególnych służb). Podsystem
umożliwia przekazanie procesu przyjęcia zgłoszenia pomiędzy Operatorami zlokalizowanymi
w WCPR (np. dla potrzeb przyjęcia zgłoszeń obcojęzycznych).
Podsystem ZINTEGROWANEJ ŁĄCZNOŚCI
Podsystem zapewnia zintegrowanie aplikacji informatycznej z systemami łączności telefonicznej
i radiotelefonicznej oraz umożliwia wysyłanie i odbiór komunikatów aplikacyjnych (komunikator)
pomiędzy użytkownikami Systemu. W zakresie łączności radiotelefonicznej wymagane jest
dostarczenie rozwiązania posiadającego oczekiwaną funkcjonalność na poziomie aplikacyjnym
(oprogramowanie serwera komunikacyjnego i konsol dyspozytorskich) natomiast wymagane
elementy infrastrukturalne (dodatkowe moduły integracji radiowej – sprzętowe karty interfejsów)
nie są przedmiotem niniejszego zamówienia. W ramach tego podsystemu zostanie
6
zaimplementowany system rejestracji rozmów, rejestrujący połączenia głosowe kierowane na
numer alarmowy 112 oraz inne numery alarmowe.
Podsystem BAZ DANYCH
Podsystem przechowuje dane związane z realizacją zadań poszczególnych modułów Systemu.
Wymiana danych z innym modułami systemu odbywa się za pośrednictwem zewnętrznej szyny
komunikacyjnej (wymiany danych), przy wykorzystaniu architektury opartej o model SOA.
Podsystem RAPORTOWY
Podsystem udostępnia mechanizmy analityczne niezbędne do tworzenia raportów o charakterze
operacyjnym (nt. bieżącego stanu działania danego WCPR) oraz o charakterze statystycznym na
danych historycznych. Głównym zadaniem tego komponentu jest wspomaganie podmiotów
ratowniczych w zakresie planowania i organizacji zadań niezbędnych w zakresie przyjęcia i obsługi
wywołań alarmowych.
Podsystem MONITOROWANIA ZGŁOSZEŃ
Podsystem umożliwia śledzenie procesu przyjęcia zgłoszenia oraz statusu obsługi zdarzeń
niezbędnych z punktu widzenia zadań Koordynatora WCPR. Zakłada się implementację w ramach
niniejszego komponentu m.in. mechanizm automatycznego powiadamiania o przekroczeniu
przyjętego czasu obsługi przyjęcia zgłoszenia (monitorowanie czasu oczekiwania na odbiór
zgłoszenia).
4.2.
Struktura organizacyjna
Dla potrzeb budowy i wdrożenia aplikacji informatycznych funkcjonujących w lokalizacji
WCPR zakłada się implementację w SI WCPR roli Operatora oraz Koordynatora.
uc struktura SI WCPR oraz SWD
SI WCPR
SWD
dane
Koordynator WCPR
Operator WCPR
Dyspozytor
Rys. 1 – Struktura SI WCPR
Zgłoszenia rejestrowane przez Operatora, w ramach elektronicznego formularza, są następnie
przekształcane w zdarzenia (po wcześniejszej analizie wystąpienia zgłoszeń podobnych)
i przekazywane do właściwych służb do obsługi. Po stronie służb jest wyświetlany arkusz zdarzenia
w ramach formatki dostępnej w SI WCPR, bądź formatki SWD służby jeśli służba dostosuje swoje
SWD do udostępnionego w SI WCPR interfejsu API (system z wykorzystaniem mechanizmów Web
Service i komunikacji w formacie XML).
7
Na diagramach poniżej przedstawiono główne role dla SI WCPR.
uc SI WCPR - głów ne role
SI WCPR
Przygotuj decyzj e i
w ytyczne
Wizualizuj sytuacę
Koordynator WCPR
Zarządzaj
komunikatami
Sporządź analizy i
raporty
Operator WCPR
Przyj mij i obsłuż
zgłoszenie
Zgłaszaj ący
Zgłoś zagrożenie
Rys. 2 – Główne role w SI WCPR
Oprócz roli Operatora w ramach SI WCPR zaimplementowana zostanie funkcjonalność
Koordynatora, zapewniająca w szczególności: przegląd bieżącej sytuacji w zakresie przyjęcia
zgłoszeń i statusów obsługi zdarzeń, monitorowanie ilości i typów zgłoszeń na obszarze
województwa, wymiany informacji i dyspozycji z innymi WCPR oraz inicjowanie procedur
reagowania kryzysowego we współpracy z właściwym miejscowo Centrum Zarządzania
Kryzysowego.
8
System Informatyczny Wojewódzkich Centrów Powiadamiania Ratunkowego – etap I
5.
Wymagania szczegółowe
5.1
Wymagania funkcjonalne systemu SI WCPR
Kod
wymagania
Opis funkcjonalności
WF.01
Rejestracja zgłoszeń alarmowych (wypełnienie arkusza przyjęcia zgłoszenia oraz
zapis audio rozmowy telefonicznej) na numer 112 oraz inne numery alarmowe,
w szczególności 999, 998, 997. Zgłoszenie po określeniu jego autentyczności
i analizie pod kątem zgłoszeń podobnych oraz identyfikacji numeru zgłaszającego,
a także lokalizacji miejsca zgłoszenia i miejsca zdarzenia, przyjmuje status
zdarzenia.
WF.02
Kojarzenie dodatkowych zgłoszeń z istniejącym zdarzeniem (zgłoszenie podobne).
WF.03
Przekazanie przyjętego zdarzenia, wraz z nagraniem audio skojarzonych z danym
zdarzeniem zgłoszeń , do właściwych merytorycznie służb (Dyspozytora danej
służby).
WF.04
Rejestracja zgłoszeń alarmowych za pomocą standardowego arkusza przyjęcia
zgłoszenia, w szczególności w zakresie:
a. Numer telefonu,
b. Imię,
c. Nazwisko,
d. Lokalizacja zgłaszającego,
e. Lokalizacja miejsca zdarzenia,
f. Opis zdarzenia,
g. Kategoria zdarzenia.
WF.05
Monitorowanie statusów obsługi wywołań alarmowych, w podziale na co najmniej:
a. Oczekujące,
b. Obsługiwane,
c. Zakończone.
WF.06
Rejestracja czasu obsługi zgłoszenia alarmowego:
a. Oczekiwania na przyjęcie zgłoszenia,
b. Nawiązania połączenia,
c. Przyjęcie zgłoszenia,
d. Całkowity czas.
WF.07
Rejestracja treści zgłoszeń alarmowych, przy czym zapis ma mieć następujące
cechy: ochrona przed niepowołanym dostępem, niemodyfikowalność, możliwość
agregacji i centralnej archiwizacji, dostęp do rejestracji zagregowanych dla osób
uprawnionych (czas przechowywania nagrań – 24 miesiące).
WF.08
Przyjmowanie zgłoszeń od osób niepełnosprawnych. Zgłoszenia mogą
dokonane przy wykorzystaniu wiadomości tekstowych SMS, e-mail, faks.
WF.09
Przekazanie połączenia alarmowego do innego Operatora dowolnego WCPR.
WF.10
Automatyczne przydzielenie połączeń alarmowych
w ramach określonej grupy stanowisk operatorskich.
WF.11
Obsługa IVR (odgrywanie zapowiedzi słownych, przyjmowanie komend metodą
tonową, przyjmowanie danych z klawiatury telefonu metodą tonową).
WF.12
Zestawianie połączeń alarmowych z innymi Operatorami WCPR (np. posługującymi
się danym językiem obcym).
WF.13
Uniwersalny interfejs umożliwiający przekazanie przyjętych danych do systemów
zewnętrznych względem WCPR, w szczególności systemów klasy SWD
poszczególnych służb, w oparciu komunikaty w formacie XML,
WF.14
Dostęp Operatorów do uprzednio zarejestrowanych w ramach WCPR zgłoszeń
wg
zdefiniowanych
być
reguł
Kod
wymagania
(nagrania audio, arkusz przyjęcia zgłoszenia), z uwzględnieniem uprawnień
wynikających z lokalizacji, przynależności organizacyjnej i pełnionej roli.
WF.15
Odsłuch zapisanych rozmów z funkcją: przewijania, pauza, stop.
WF.16
Przeszukiwanie rozmów w oparciu o zadany: okres czasu, identyfikator, „znacznik”.
WF.17
Możliwość aktualizacji arkusza przyjęcia zgłoszenia w czasie obsługi zdarzenia i po
jego zakończeniu (zdarzenie może być aktualizowane zarówno przez Operatora jak
i Dyspozytorów poszczególnych służb).
WF.18
Automatyczna sygnalizacja potencjalnego ponownego przyjęcia zgłoszenia tego
samego zdarzenia (identyfikacja na podstawie wybranych parametrów porównania
w cyklu 24 godzinnym).
WF.19
Automatyczne/ręczne przesyłanie zdarzenia do Dyspozytorów danej służby.
WF.20
Automatycznie przydzielany identyfikator zgłoszenia i zdarzenia.
WF.21
Rejestracja i oznaczanie fałszywych (złośliwych) zgłoszeń
wszystkich zgłoszeń alarmowych przyjętych w ramach WCPR.
WF.22
Automatyczna sygnalizacja nadejścia połączenia potencjalnie fałszywego.
WF.23
Możliwość generowania raportów i statystyk zgłoszeń (w tym np. fałszywych).
WF.24
Możliwość wymiany informacji pomiędzy Operatorami a Dyspozytorami służb
w czasie rzeczywistym z użyciem komunikatów aplikacyjnych.
WF.25
Odbiór i rejestracja potwierdzeń od Dyspozytorów służb o przyjęciu informacji
o zdarzeniu.
WF.26
Podgląd kolejki oczekujących połączeń i możliwość wyboru połączenia poza
kolejnością.
WF.27
Definiowanie czasu, po przekroczeniu
połączenia oczekującego do innego WCPR.
WF.28
Dostęp do książki telefonicznej abonentów, listy konferencyjnej, bazy komunikatów
dla obszaru obsługiwanego przez dany WCPR.
WF.29
Możliwość zestawienia połączenia
(Dyspozytorem właściwej służby).
WF.30
Podręczna baza teleadresowa.
WF.31
Usprawnienia komunikacji poprzez zautomatyzowanie wybierania numerów
telefonów, zestawianie połączeń konferencyjnych, wsparcie przekazywania
połączeń.
WF.32
Możliwość współpracy z bezprzewodowym zestawem mikrofonowo-słuchawkowym.
WF.33
Sygnalizacja przekroczenia czasu przewidzianego do obsługi zgłoszenia.
WF.34
Automatyczne nadawania priorytetów zgłoszeń, na podstawie kategorii zdarzenia.
WF.35
Przekazanie/zamknięcie obsługiwania zgłoszenia w dowolnym momencie jego
obsługi.
WF.36
Możliwość przekazania służby/zmiany przez Operatora.
WF.37
Automatyczna historia obsługi zgłoszenia od momentu przyjęcia do momentu
zamknięcia (z podaniem: dat, znaczników czasu, identyfikatorów osób, podjętych
czynności, statusów jednostek ratowniczych, dokonywania sprawdzeń itp.).
WF.38
Administrowanie uprawnieniami użytkowników.
WF.49
Dodawanie/usuwanie stanowisk dostępowych.
WF.40
Utrzymywanie danych słownikowych/bibliotek.
WF.41
Automatyczna rejestracja czasu pracy użytkowników (kto, kiedy).
WF.42
Zapamiętywanie dla każdej zarejestrowanej korespondencji10zestawu metadanych
obejmujących co najmniej: czas rozpoczęcia i czas zakończenia, numery telefonów
którego
alarmowych
dla
następuje10przekierowanie
telekonferencyjnego
z
właściwą
służbą
10
Kod
wymagania
uczestniczących
w
korespondencji,
identyfikatorów
stacji
bazowych
uczestniczących w korespondencji, kanałów na których była prowadzona
korespondencja.
WF.43
Pełna dokumentacja obsługi zgłoszeń w zakresie rejestracji wszystkich kanałów
komunikacji.
WF.44
Obsługa zgłoszeń obcojęzycznych.
WF.45
Dostęp do bazy danych wszystkich aktualnie pracujących Operatorów z podziałem
na znajomość języków obcych oraz dostępność.
WF.46
Automatyczne generowanie propozycji wyboru podmiotów właściwych do obsługi
zdarzenia.
WF.47
Zastosowanie mechanizmów filtrowania i sortowania danych.
WF.48
Dostęp do zasobów systemu za pomocą specjalizowanych konsol dyspozytorskich
zainstalowanych na stanowiskach pracy (zasobów telefonii przewodowej
i radiowej).
WF.49
Zapamiętywanie przez System indywidualnych ustawień danego użytkownika
końcowego, tak aby mógł on po zalogowaniu się na innym stanowisku dostępowym
(np. w momencie awarii stanowiska dostępowego) mieć swoje indywidualne
ustawienia w niezmienionej formie.
5.2.
Wymagania pozafunkcjonalne
Wymagania ogólne
Kod
wymagania
NFO.01
Sterowanie funkcjami za pomocą skrótów klawiszowych.
NFO.02
W przypadku awarii stacji roboczej obsługa powinna zostać przejęta automatycznie
przez uprzednio określone stanowisko innego Operatora.
NFO.03
Jednolity technologicznie sposób rejestracji wywołań alarmowych na numer 112
oraz inne numery alarmowe, w szczególności 999, 998, 997, w skali kraju.
NFO.04
Możliwość korzystania z szerokiego pakietu usług dostępnych w technologii VoIP.
NFO.05
Wymagania niefunkcjonalne dotyczące z rozmieszczenia infrastruktury sprzętowej
będą wynikały z zaproponowanej przez wykonawcę aplikacji w ramach projektu
technicznego architektury Systemu, uwzględniającej mechanizmy replikacji
danych.
NFO.06
Komunikacja (synchroniczna) pomiędzy WCPR a systemami dziedzinowymi służb
(systemy klasy SWD) zrealizowana w oparciu o technologię Web-Service i
komunikację w formacie XML.
NFO.07
Ergonomia GUI dostosowana do maksymalnego skrócenia procesu wprowadzania
danych.
NFO.08
Architektura rozwiązania oparta o Ośrodki Krajowe i Ośrodki Regionalne.
NFO.09
Część kliencka rozwiązania w technologii grubego klienta.
NFO.10
Interfejs użytkownika w języku polskim.
NFO.11
Komunikacja pomiędzy lokalizacjami Użytkowników Końcowych oraz Ośrodkami
Krajowymi będzie realizowana poprzez infrastrukturę sieci OST 112.
NF0.12
Zapewnienie architektury rozwiązania zapewniającej niezawodność systemu na
11
Kod
wymagania
wymaganym poziomie SLA.
NF0.13
Aplikacja rozwiązania w oparciu o SOA ( Service Oriented Architecture)
Wydzielone moduły funkcjonalne muszą komunikować się miedzy sobą za pomocą
WebService.
NFO.14
Przyjęte rozwiązanie musi pozwalać na wdrożenie logiki biznesowej aplikacji
w oparciu o zewnętrzną szynę komunikacyjną (wymiany informacji).
NFO.15
System musi zapewniać obsługę standardowych sygnalizacji telekomunikacyjnych,
co najmniej CAS, QSIG, ATS QSIG, DSS1, SS7, CAS/R2 MCF, ASS, FXO, FXS, E&M,
SIP, H.323.
NFO.16
Interfejs stanowisk dyspozytorskich SHDSL, E1/G.703 lub IP.
NFO.17
Wykonawca zobowiązany jest do umieszczenia na dostarczonej infrastrukturze
sprzętowej oznaczeń opisanych w „Zasadach promocji projektów dla beneficjentów
Programu Operacyjnego Infrastruktura i Środowisko 2007-2013” tzn. wszelka
dostarczona w ramach realizacji przedmiotu Zamówienia infrastruktura sprzętowa
musi być opatrzona logotypami: Programu Operacyjnego Infrastruktura i
Środowisko, Unia Europejska z odniesieniem słownym do Europejskiego Funduszu
Rozwoju Regionalnego, logo Beneficjenta. Szablony oznaczeń zostaną przekazane
Wykonawcy przez Zamawiającego.
Bezpieczeństwo
Pojęcia Poufność, Integralność, Rozliczalność i Niezaprzeczalność są rozumiane zgodnie z normą
PN-I-02000:2002 Technika Informatyczna – zabezpieczenia w systemach informatycznych.
Poufność
Kod
wymagania
NFP.01
Zaimplementowanie funkcjonalności umożliwiającej przetwarzanie w Systemie
informacji wrażliwych zgodnie z wymaganiami określonymi w odpowiednich aktach
prawnych, w szczególności ustawie z dnia 29 sierpnia 1997 r. o ochronie danych
osobowych (Dz. U. z 2002 r. Nr 101, poz. 926) oraz rozporządzenia Rady
Ministrów z dnia 28 października 2005 r. o minimalnych wymaganiach dla
systemów teleinformatycznych (Dz. U. z 2005 r. Nr 212, poz. 1766).
Zaimplementowanie mechanizmów umożliwiających dostęp do Systemu wyłącznie
po jednoznacznym zidentyfikowaniu użytkownika końcowego przeprowadzonym w
ramach procesu uwierzytelnienia.
Zaimplementowanie mechanizmów zapewniających przechowywanie i przesyłanie
haseł użytkowników wyłącznie w postaci zaszyfrowanej.
Zaimplementowanie mechanizmu kontroli uprawnień opartego na rolach,
umożliwiającego kontrolę poziomu dostępu do Systemu każdego użytkownika
zarówno w zakresie dostępu do danych przetwarzanych w Systemie jak i
korzystania z jego funkcjonalności. System uprawnień musi umożliwić ograniczenie
dostępu wyłącznie do takich danych oraz takiego zakresu funkcji, jaki jest mu
niezbędny do wykonania zadań wynikających z zakresu obowiązków.
W przypadku szyfrowania wymagane jest zaimplementowanie mechanizmów
kryptograficznych
opartych
na
uznanych
standardach
otwartych.
Moc
wykorzystanych mechanizmów nie może być mniejsza od mocy zapewniana przez
3DES, AES-128, RSA-1024, SHA-1.
Zabezpieczenie transmisji danych wrażliwych pomiędzy stacją użytkownika a
serwerami umieszczonymi w węzłach technologicznych oraz pomiędzy
współpracującymi systemami. Poziom zabezpieczenia transmisji nie może być
mniejszy od poziomu zapewnianego przez protokół TLS z kluczem o długości 128
bitów.
NFP.02
NFP.03
NFP.04
NFP.05
NFP.06
12
Integralność
Kod
wymagania
NFI.01
Zaimplementowanie
mechanizmów
zapewniających
integralność
danych
wykorzystywanych przy obsłudze zdarzeń i zgłoszeń w trakcie ich przesyłania
pomiędzy SI WCPR a innymi systemami współpracującymi z nim w ramach SI PR.
Poziom zapewnienia integralności nie może być mniejszy od poziomu
zapewnianego przy użyciu protokołu TSL z kluczem 128 bit.
Zaimplementowanie
mechanizmów
zapewniających
integralność
danych
wykorzystywanych przy obsłudze zdarzeń i zgłoszeń w trakcie ich przesyłania
pomiędzy węzłem technicznym systemu a stacją roboczą użytkownika. Poziom
zapewnienia integralności nie może być mniejszy od poziomu zapewnianego przy
użyciu protokołu TSL z kluczem 128 bit.
NFI.02
Rozliczalność
Kod
wymagania
NFR.01
Zaimplementowanie mechanizmów umożliwiających rozliczalność działań
użytkowników końcowych, które są bezpośrednio związane z obsługą zgłoszeń
i zdarzeń. Wymagane jest rejestrowanie, co najmniej następujących informacji:

data i czas zdarzenia,

rodzaj zdarzenia,

identyfikator użytkownika,

identyfikator stacji użytkownika.
Zaimplementowanie mechanizmów umożliwiających rozliczalność działań
administracyjnych związanych z nadawaniem i odbieraniem uprawnień do tych
usług realizowanych przez system, które są bezpośrednio związane z obsługą
zgłoszeń i zdarzeń.
NFI.02
Niezaprzeczalność
Kod
wymagania
NFN.01
Zaimplementowanie mechanizmów umożliwiających niezaprzeczalność działań
związanych z przyjmowaniem zgłoszeń i obsługą zdarzeń w ramach SI PR.
Ciągłość działania
Kod
wymagania
NFC.01
Zaimplementowanie mechanizmów umożliwiających uruchomienie Systemu
zgodnie z zaakceptowanych przez Zamawiającego projektem technicznym
w oparciu o Ośrodek Krajowy i 20 Ośrodkach Regionalnych.
Optymalizacja architektury Systemu pod kątem maksymalnego wyniesienia
infrastruktury sprzętowo-programowej do Ośrodka Krajowego, z zachowaniem
wymaganych poziomów dostępności Systemu.
NFC.02
Dostępność
Kod
wymagania
NFD.01
Zaimplementowanie mechanizmów umożliwiających zapewnienie dostępności
usług Systemu wykorzystywanych do obsługi zgłoszeń i zdarzeń liczonej
w okresach miesięcznych indywidualnie dla każdego ośrodka: :
13
Kod
wymagania
a) dla Ośrodka Krajowego SLA na poziomie 99,99% (niedostępność
miesięczna 4,38 min. / ośrodek),
b) dla każdego Ośrodka Regionalnego SLA na poziomie 99% (niedostępność
miesięczna 7,3h / WCPR)
SLA ośrodka liczone jest jako suma czasu trwania niedostępności Systemu
spowodowanej Awariami Krytycznymi, przy czym okna serwisowe związane
z konserwacją/rekonfiguracją Systemu nie podlegają uwzględnianiu w obliczeniu
SLA (termin i zakres prac realizowanych w ramach okna serwisowego wymaga
uzyskania przez Wykonawcę uprzedniej akceptacji Zamawiającego).
Zaimplementowanie mechanizmów umożliwiających użytkownikom Systemu
kontynuację pracy w przypadku awarii jednego z węzłów technicznych
z wykorzystaniem usług świadczonych przez inny węzeł.
Zaimplementowanie mechanizmów umożliwiających przejęcie obsługi zgłoszeń
alarmowych przez inny WCPR lub CPR.
NFD.02
NFD.03
Pojemność i Wydajność
Kod
wymagania
NFPW.01
System przystosowany do przyjęcia i obsługi do 5 000 000 zgłoszeń alarmowych
rocznie.
Zaimplementowanie mechanizmów umożliwiających obsługę zwiększonej liczby
zgłoszeń w okresach szczytów, przy założeniu, iż liczba ta nie przekroczy 10-cio
krotności średniej liczby zgłoszeń wyliczonej na podstawie ww. wymagania.
Zaimplementowanie
mechanizmów
umożliwiających
obsługę
do
200
równoczesnych użytkowników.
NFPW.02
NFPW.03
5.3.
Serwer komunikacyjny
wymagania
zintegrowanej łączności
(20 sztuk)
– minimalne
Kod
wymagania
Opis
SK.01
Rozumiany jako oprogramowanie dedykowane
zapewniająca integrację środków korespondencji
systemów informatycznych złożone z:
a. modułu Rejestracji,
b. modułu Telefoniczny,
c. serwera Zarządzania.
SK.02
Możliwość dołączenia do 255 konsol dyspozytorskich
SK.03
Możliwość
SK.04
110 kanałów radiowych dostępnych w jednym czasie na konsoli dyspozytorskiej
z następującym podziałem:
a. 60 kanałów do pracy w trybie Rx/Tx,
b. 50 kanałów do pracy w trybie Rx.
SK.05
Współużytkowanie 1 kanału radiowego w trybie nadawczo-odbiorczym przez 32
operatorów z uwzględnieniem priorytetów. Możliwość definiowania parametru liczby
operatorów.
SK.06
Zapewnienie pracy ciągłej, co oznacza, iż zmiany konfiguracji, nie mogą powodować
restartu sterowników i resynchronizacji połączeń.
dołączenia
radiotelefonów).
do
255
obsługiwanych
oraz platforma sprzętowa
radiowej, telefonicznej oraz
stacji
bazowych
(radiostacji,
14
Kod
wymagania
Opis
SK.07
Obsługa
następujących
typów
radiotelefonów/systemów
(przystosowanych do zdalnego sterowania):
a. Konwencjonalne VHF,
b. TETRA,
c. EDACS,
d. Obsługa sygnalizacji SELECT5 oraz CTCSS.
SK.08
Funkcja systemowej rejestracji korespondencji:
a. telefonicznej
i. Numer abonenta A (abonent inicjujący połączenie),
ii. Numer abonenta B (abonent wywoływany przez abonenta A),
iii. Numer abonenta C (abonent osiągnięty przez abonenta A w przypadku
przekierowania przez abonenta B),
iv. Godzina rozpoczęcia nagrania,
v. Czas trwania nagrania,
vi. Identyfikator nagrania w systemie rejestracji serwera komunikacyjnego,
b. radiowej
i. Identyfikator radiotelefonu,
ii. Numer kanału ustawionego w radiotelefonie i/lub częstotliwość,
iii. Godzina rozpoczęcia nagrania,
iv. Czas trwania nagrania,
v. Identyfikator nagrania w systemie rejestracji serwera komunikacyjnego.
SK.09
Możliwość zdefiniowania tylko jednego serwera zarządzania dla kilku serwerów
komunikacyjnych.
SK.10
Zapewnie w pełni cyfrowe przenoszenie akustyki pomiędzy konsolą dyspozytorską
zintegrowanej łączności a modułem kontrolnym radiotelefonów.
SK.11
Możliwość pracy wszystkich elementów serwera komunikacyjnego bez dostępu do
systemu nadzoru.
SK.12
W przypadku realizacji systemu w oparciu o łącza TDM E1 opóźnienie sygnału PTT
(push-to-talk) wnoszone przez system musi być mniejsze niż 20ms.
SK.13
Możliwość sieciowania serwerów komunikacyjnych rozumiana jako możliwość
dostępu do zasobów radiowych innego serwera komunikacyjnego zarówno
z wykorzystaniem IP jak i E1.
SK.14
Serwer komunikacyjny powinien mieć możliwość współpracy z zewnętrznymi
centralkami PABX używanymi, jak również możliwość zastąpienia istniejących
centralek PABX.
SK.15
Obsługa następujących protokołów telekomunikacyjnych:
a. DSS1 (2B+D, 30B+D),
b. Qsig,
c. SS7,
d. H.323,
e. SIP.
SK.16
Serwer komunikacyjny musi być wyposażony w następujące standardowe interfejsy
telekomunikacyjne:
a. styk A - przeznaczony do współpracy z traktem cyfrowym–PCM30,
b. styk C11 - przeznaczony do współpracy z dwutorowymi, końcowymi
wyposażeniami telefonii nośnej, –styki C21 i C22 - przeznaczone do
współpracy z centralami elektromechanicznymi po jednotorowych
(niewzmacnianych) łączach analogowych,
radiowych
15
Kod
wymagania
Opis
c. styk Z - przeznaczony do współpracy z jednotorowym analogowym
łączem abonenckim,
d. styk V1 - przeznaczony do współpracy z łączem cyfrowym dostępu
podstawowego–(2B+D),
e. styk V3 - przeznaczony do współpracy z traktem dostępu
pierwotnego (–0B+D),
f. styk Stg - przeznaczony do współpracy z siecią taktyczną pracującą
według zaleceń Eurocom D1, STANAG 4206-4210, STANAG 4578
ED.2.
SK.17
Dla kart portów cyfrowych łączy miejskich musi zostać zapewniona możliwość
zmiany sygnalizacji (DSS1 / QSIG) tylko w sposób programowy bez konieczności
wymiany pakietu.
SK.18
Musi zostać zapewniona wysoka niezawodności sprzętu poprzez zdublowanie
krytycznych elementów systemu. Elementy redundantne muszą pracować w trybie
gorącej rezerwy. Awaryjne przełączenie na system rezerwowy nie może powodować
przerw w komunikacji.
SK.19
Interfejsy 2Mbit/s do współpracy z publiczną siecią telekomunikacyjną muszą
spełniać parametry teletransmisyjne zgodne z zaleceniem ITU-T G.703.
SK.20
Serwer komunikacyjny musi udostępniać interfejs do współpracy z zewnętrznymi
aplikacjami typu CTI wymagana jest obsługa protokołu, co najmniej typu TAPI.
SK.21
Serwer komunikacyjny musi gwarantować możliwość wprowadzania zmian
wynikających z rozwoju technologicznego oraz zapewniać możliwość rozbudowy,
zwiększenia pojemności i funkcjonalności w zależności od potrzeb Zamawiającego
zarówno części dotyczącej oprogramowania jak i sprzętu.
SK.22
Konstrukcja serwera komunikacyjnego oraz jego oprogramowania powinna zakładać
możliwość dostosowywania go do indywidualnych potrzeb Zamawiającego.
SK.23
Całość dokumentacji zarówno do serwera komunikacyjnego, jego interfejsów,
wspieranych protokołów i oprogramowania musi być dostarczona w języku polskim.
SK.24
W ramach zsieciowanego systemu
zapewniony wspólny plan numeracji.
SK.25
Serwer komunikacyjny musi zapewniać możliwość tworzenia wielu planów
numeracji, tj. tworzenie wirtualnej centrali PBX. Liczba wirtualnych grup nie mniej
niż 10.
SK.26
Serwer komunikacyjny zintegrowanej łączności musi gwarantować
tworzenia planu numeracji wewnętrznej i zewnętrznej zawierającej:

numery wewnętrzne i zewnętrzne użytkowników wewnętrznych,

numery wewnętrzne i zewnętrzne aparatów systemowych,

kody dostępu do publicznych sieci telekomunikacyjnych.
SK.27
Serwer komunikacyjny musi charakteryzować się strukturą umożliwiającą
wynoszenie modułów funkcjonalnych w inne lokalizacje z wykorzystaniem sieci TDM
oraz sieci IP.
SK.28
Serwer komunikacyjny musi wybierać drogi obejściowe w przypadku uszkodzenia
bądź przepełnienia drogi podstawowej. Wymagany jest dostęp do minimum 4 dróg
obejściowych.
SK.29
Serwer komunikacyjny musi przekazywać do centralnego stanowiska zarządzania,
na bieżąco, informację o wszystkich alarmach w systemie, raporty i inne dane
o charakterze statystycznym.
SK.30
W ramach serwera komunikacyjnego wymagane zapewnienie centralki telefonicznej
serwerów
komunikacyjnych
musi
zostać
możliwość
16
Kod
wymagania
Opis
PABX (100 numerów).
5.4.
System rejestracji rozmów jako funkcjonalność
łączności – minimalne wymagania funkcjonalne
systemu
rejestrację
zintegrowanej
SRR.01
System rejestracji rozmów musi umożliwiać
telefonicznych w postaci zapisu cyfrowego.
treści
rozmów
SRR.02
System rejestracji rozmów powinien umożliwiać rejestrację wszystkich rozmów
obsługiwanych przez serwer komunikacyjny oraz rejestrację rozmów wybranej
grupy abonentów.
SRR.03
System rejestracji rozmów powinien umożliwiać rejestrację rozmowy dowolnego
abonenta oraz zdalny wybór abonenta nagrywanego ze stanowiska nadzoru, bez
konieczności fizycznego krosowania na przełącznicy.
SRR.04
System rejestracji rozmów musi umożliwiać rejestrację rozmowy z portów nie
przechodzących przez centralę (analogowe łącza miejskie i ISDN BRA).
SRR.05
System rejestracji rozmów musi zapewniać ochronę danych oraz kontrolę dostępu
do zapisanych informacji na podstawie systemu haseł i klas uprawnień.
SRR.06
System rejestracji rozmów powinien umożliwiać kontrolny odczyt danych (przez
autoryzowanych użytkowników) w celu sprawdzenia stanu rejestracji.
SRR.07
Łączny czas nagrań na wewnętrznym dysku rejestratora bez „nadpisywania” nie
powinien być krótszy niż 48 godzin.
SRR.08
System rejestracji rozmów musi umożliwić automatyczną i ręczną archiwizację
nagrań na zewnętrznym serwerze nagrań. Dostęp do serwera poprzez sieć
Ethernet.
SRR.09
System rejestracji rozmów musi umożliwiać wykonanie kopii wybranych przez
uprawnionego operatora fragmentów zapisu w postaci pliku audio w formacie .wav
i .pcm.
SRR.10
System rejestracji rozmów musi zapewniać archiwizację i odsłuch zapisanych
danych, na co najmniej 3 wskazanych komputerach PC pracującym w sieci LAN,
WAN.
SRR.11
System rejestracji rozmów musi umożliwiać archiwizację nagrań pochodzących
z różnych lokalizacji w jednym miejscu z wykorzystaniem sieci LAN/WAN.
SRR.12
System rejestracji rozmów powinien umożliwiać odsłuch rozmów poprzez sieć LAN
z użyciem dedykowanej aplikacji.
SRR.13
System rejestracji rozmów musi umożliwiać administrowanie oraz zdalny nadzór
poprzez sieć LAN/WAN.
SRR.14
System rejestracji rozmów powinien opatrywać nagrania głosowe dodatkowymi
informacjami tj.:
1. numer abonenta dzwoniącego (w ruchu przychodzącym),
2. numer wewnętrzny,
3. numer wybrany,
4. data i godzina połączenia,
5. czas trwania połączenia,
6. kierunek rozmowy,
7. numer linii (kanał),
SRR.15
System
rejestracji rozmów musi umożliwić wyszukiwanie nagrań co najmniej
17
według
1.
2.
3.
4.
5.
następujących kryteriów:
data i czas nagrania,
numer linii (kanał),
numer dzwoniący,
numer wewnętrzny,
kierunek połączenia.
SRR.16
Musi zostać zapewniony brak bezpośredniego dostępu do sytemu plików dla
systemu rejestracji rozmów (rejestratora).
SRR.17
Musi być możliwy odsłuch rozmowy niezależnie od jej rejestracji w danym
momencie.
SRR.18
System
rejestracji rozmów musi uniemożliwiać kasowanie plików również
z poziomu uprawnień administratora.
SRR.19
System rejestracji rozmów musi umożliwiać elastyczną rozbudowę, zwiększenie
liczby rejestrowanych kanałów.
SRR.20
System rejestracji rozmów musi zapewniać możliwość natychmiastowego
raportowania o błędach lub awariach urządzeń wchodzących w skład systemu.
SRR.21
W przypadku przerwy w zasilaniu system
rejestracji rozmów po odzyskaniu
zasilania musi samodzielnie powrócić do normalnej bezobsługowej pracy.
SRR.22
System rejestracji rozmów powinien zostać dostarczony w obudowie umożliwiającej
montaż w szafie przemysłowej 19”.
SRR.23
System rejestracji rozmów powinien być zasilany ze źródła gwarantowanego przez
zasilacze (siłownię) centrali.
5.5.
Stanowiska dostępowe
Zaproponowane przez Wykonawcę rozwiązanie musi być kompatybilne z zapewnianymi przez
Zamawiającego stanowiskami dostępowymi (stanowiska dostępowe wyposażone w karty
mikroprocesorowe oraz czytniki kart mikroprocesorowych) o przedstawionych poniżej minimalnych
wymaganiach. Dostawa stanowisk dostępowych nie wchodzi w zakres zamówienia.
5.5.1.
Stanowiska dostępowe– minimalne wymagania
Kod
wymagania
Element
Opis
SD.01
procesor
minimum dwurdzeniowy zgodny z architekturą x86, który umożliwi
uzyskanie przez oferowany komputer wydajności w teście BAPCO
SYSMARK 2007 Preview wyników nie gorszych niż: 150 punktów
(SYSmark 2007 Preview Rating) na podstawie tabeli opublikowanej:
http://www.bapco.com/support/fdrs/SYSmark2007web.html
Uwaga! Jeżeli zaoferowany procesor wraz z proponowaną
konfiguracją sprzętowo-programową nie jest ujęty w wyżej
wymienionej
tabeli,
Wykonawca
zobowiązany
będzie
do
przeprowadzenia testów na własny koszt i udokumentowania
Zamawiającemu, że oferowany procesor osiąga wymagany wynik
punktowy w wymienionych testach.
SD.02
pamięć
operacyjna
DDR2 lub DDR3
SDRAM, min. 2GB, 800MHz (z możliwością
rozbudowy do 4 GB).
SD.03
karta
minimum
256
MB
DDR3,
wyposażona
w
dwa
porty
DVI
18
Kod
wymagania
Element
Opis
grafiki
umożliwiające jednoczesną obsługę dwu monitorów LCD.
Zamawiający nie dopuszcza rozwiązań opartych na kartach
graficznych zintegrowanych z płytą główną. Karty graficzne muszą
posiadać pełne wsparcie dla DirectX 10.
SD.04
karta
dźwiękowa
co najmniej dwukanałowa. Zamawiający dopuszcza zastosowanie
karty dźwiękowej zintegrowanej z płytą główną.
SD.05
karta
sieciowa
LAN 10/100/1000 - złącze RJ-45. Zamawiający dopuszcza
zastosowanie karty sieciowej zintegrowanej z płytą główną.
SD.06
dysk
twardy
SATA, min. 320 GB, 7200rpm, min 8MB cache.
SD.07
napęd
DVD Dual Layer +/- RW wraz z zainstalowanym oprogramowaniem
w języku polskim.
SD.08
mysz
optyczna PS/2 lub USB - 2 przyciski + rolka przewijania, podkładka.
SD.09
klawiatura
USB, w układzie QWERTY.
SD.10
obudowa
Midi lub Mini Tower, ATX. Wolne złącza: 4xUSB 2.0, wejście/wyjście
audio, przednie złącza: 2x USB 2.0.
SD.11
monitor
2 szt. – LCD 19”:
o rozdzielczość - 1440x900
o minimalny kontrast – 8000:1
o monitor musi umożliwiać regulację wysokości, kąta pochylenia
i obrotu
o minimalny kąt widzenia w poziomie: 160
o minimalny kat widzenia w pionie: 160
o złącze DVI
o monitor musi spełniać normy: TCO’03,
ISO 13406-2, EPA
ENERGY STAR, TUV/GS
o dostarczony monitor musi być wyposażony w komplet kabli:
zasilający o długości min. 1,8 m oraz kabel sygnałowy o długości
min. 1,8 m.
SD.12
oprogramo
wanie
Dostarczone stanowiska dostępowe muszą mieć zainstalowany
system operacyjny, pakiet oprogramowania antywirusowego, a także
czytniki o których mowa w pkt. 5.5.3.:
o 64 bitowy system operacyjny w polskiej wersji językowej, jeden
z wymienionych:

MS Windows 7 Ultimate* lub

MS Windows 7 Professional* lub

MS Windows Vista Business plus Service Pack 2*
o program antywirusowy z modułem aktualizacji bazy sygnatur
wirusów przez Internet przez okres co najmniej 2 lat w polskiej
wersji językowej,
o oprogramowanie biurowe – OpenOfficePl
SD.13
Listwa
zasilająca
napięcie 230V, częstotliwość 50 Hz,
o
obciążenie dla jednego gniazda nie mniejsza niż 460 W,
o
liczba gniazd w listwie 5
o
wyłącznik dwubiegunowy – podświetlony
o
zabezpieczenie prądowe – bezpiecznik 10A – 250V
o
zabezpieczenie przepięciowe – impuls 1x130J<10/1000us.
*lub równoważne
19
5.5.2. Karty mikroprocesorowe– minimalne wymagania
Kod
wymagania
Opis
KM.01
zgodne ze standardem ISO w następujących częściach: 7816-1, 7816-2, 7816-3,
7816-4, 7816-5, 7816-6, 7816-8.
KM.02
wyposażone w procesor o pojemności min 72 kB.
KM.03
dostarczony sprzęt musi być fabrycznie nowy/nieużywany. Ponadto Wykonawca
dostarczy, zainstaluje i uruchomi sprzęt na wskazanym stanowisku pracy.
KM.04
zgodne ze Standardem Java Card 2.2.1.
KM.05
napięcie zasilania karty musi mieścić się w zakresie 1,62 – 5,5 V.
KM.06
gwarantowana ilość cykli zapisu/kasowania dostarczonej karty nie może być
mniejsza niż 500,000.
KM.07
karty wspierane przez algorytmy kryptograficzne i szyfrujące:
o 3DES (ECB, CBC),
o AES (128, 192, 256),
o RSA up to 2048bit ,
o SHA-1.
KM.08
Długość generowanych kluczy kryptograficznych Cryptographic algorithms: 3DES
(ECB, CBC), AES (128, 192, 256), RSA up to 2048bit ,SHA-1.
KM.09
wsparcie dla MS terminal Services, Wsparcie dla logowania w domenie, Wsparcie
dla pracy wieloaplikacyjnej.
KM.10
zapewniające wsparcie dla polityki haseł (PINÓW).
KM.11
zapewniające wsparcie dla szyfrowania komunikacji między kartą a komponentami
systemu.
KM.12
zapewniające wsparcie dla różnych kodów PIN, PUK.
KM.13
zapewniające wsparcie dla historii PIN’ów.
KM.14
zapewniające wsparcie dla konfigurowalnej polityki PIN i PUK.
KM.15
zapewniające wsparcie dla PKCS #11 dla:
o Windows:
Windows w wersji językowej polskiej lub angielskiej 2000SP6 / XP Proffesional SP2
lub SP3 / 2003 Server / Vista (Home, Business, Ultimate) –wersje 32b i 64b /
Windows 7 (Starter, Home, Premium, Professional, Ultimate) – wersje 32b i 64b
o Linux z jądrem 2.6:




KM.16
Ubuntu 7.X, 8.10, 9.10,
openSUSE 11.X,
Red Hat Enterprise Linux 5,
Debian Etch 4.0, 5.0.X.
zapewniające wsparcie dla CSP dla systemu operacyjnego Windows:
Windows w wersji językowej polskiej lub angielskiej 2000SP6 / XP Proffesional SP2
lub SP3 / 2003 Server / Vista (Home, Business, Ultimate) –wersje 32b lub 64b /
Windows 7 (Starter, Home, Premium, Professional, Ultimate) – wersje 32b i 64b
5.5.3. Czytniki kart mikroprocesorowych– minimalne wymagania
Kod
wymagania
Opis
CKM.01
czytnik kart mikroprocesorowych jako urządzenie wewnętrzne (wbudowane)
20
Kod
wymagania
Opis
komputera podłączony przez wewnętrzny port USB 2.0.
CKM.02
zgodność z PC/SC.
CKM.03
zgodność z ISO 7816-1, 7816-2, 7816-3, 7816-4, 7816-8 – interfejs stykowy.
CKM.04
sterowniki dla Windows XP, Vista, Windows 7.
CKM.05
sterowniki dla systemu Linux.
CKM.06
czytnik musi gwarantować poprawną pracę dla min. 100 000 cykli włożenia/wyjęcia
karty.
CKM.07
czytnik musi posiadać sygnalizację optyczną (np. dioda) akceptacji karty oraz pracy
z kartą.
CKM.08
Czytnik musi współpracować z oferowanymi kartami mikroprocesorowymi.
5.6.
Konsole dyspozytorskie zintegrowanej łączności – minimalne wymagania
Zaproponowane przez Wykonawcę rozwiązanie musi być kompatybilne z zapewnianymi przez
Zamawiającego konsolami dyspozytorskimi zintegrowanej łączności o przedstawionych poniżej
minimalnych wymaganiach. Dostawa konsol dyspozytorskich zintegrowanej łączności nie wchodzi
w zakres zamówienia.
Kod
wymagania
Opis
KD.01
Ekran dotykowy, o przekątnej min. 19” z regulacją położenia (podnoszenie/
opuszczanie i uchylanie).
KD.02
Łączność z serwerem komunikacyjnym zintegrowanej łączności za pomocą interfejsu
SHDSL, E1/G.703 lub IP.
KD.03
Możliwość współpracy z bezprzewodowym zestawem mikrofonowo-słuchawkowym.
KD.04
Możliwość jednoczesnego prowadzenia rozmowy z wykorzystaniem łącza radiowego,
telefonicznego interkomu oraz prowadzenia podsłuchu radiowego.
KD.05
Funkcje umożliwiające obsługę połączeń radiowych i monitoringu środków
radiowych:
-obserwowanie stanu sygnałów PTT i SQUELCH w danym kanale radiowym,
-rejestracja rozmów,
-wybór kanału pracy radiostacji,
-wybór trybu pracy (nasłuch, nadawanie-odbiór),
-wybór grup w radiotelefonie.
KD.06
Funkcje umożliwiające obsługę środków łączności telefonicznej:
-kolejkowanie zgłoszeń,
-szybkie wybieranie połączenia konferencyjnego,
-szybki dostęp do książki telefonicznej,
-zestawianie połączeń pomiędzy abonentami,
-rejestracja rozmów.
KD.07
Funkcje umożliwiające obsługę Interkomu.
KD.08
Zestaw rejestrujący lokalną korespondencję.
KD.09
Rejestracja rozmów radiowych powinna zawierać co najmniej:
-ID radiotelefonu,
21
Kod
wymagania
Opis
-nr kanału na którym prowadzona jest rozmowa,
-godzinę rozpoczęcia i zakończenia,
-czas rozmowy,
-identyfikator nagrania.
KD.10
Rejestracja rozmów telefonicznych powinna zawierać co najmniej:
-numer abonenta inicjującego,
-numer abonenta wywołanego,
-numer abonenta docelowego (przypadek przekserowania),
-godzinę rozpoczęcia i zakończenia,
-czas rozmowy,
-identyfikator nagrania.
KD.11
Integracja środków łączności radiowej różnych standardów i typów (analogowe,
cyfrowe).
KD.12
Możliwość podsłuchu korespondencji pomiędzy dyspozytorem innej konsoli
prowadzącej nasłuch na tym samym radiotelefonie lub grupie a użytkownikami sieci
radiowej.
KD.13
Podczas zmiany kanału radiowego przez dyspozytora konieczna jest sygnalizacja
(z podaniem nazwy stanowiska dyspozytorskiego, które dokonało zmiany) na
pozostałych konsolach dyspozytorskich posiadających dostęp do ww. radiotelefonu.
KD.14
Konsola musi umożliwić dyspozytorowi dynamiczne tworzenie grupy radiotelefonów,
przypisanie im jednego przycisku, który załączy nadawanie na wszystkich
radiotelefonach w grupie. Utworzenie grupy powinno być sygnalizowane na
pozostałych konsolach mających uprawnienia do korzystania z dowolnego telefonu
w zestawionej grupie.
KD.15
Konsola musi zapewniać regulację głośności sygnalizacji dźwiękowej.
KD.16
Wszystkie komunikaty, ostrzeżenia i opisy wyświetlane na konsoli muszą być
w języku polskim.
KD.17
Administrator systemu musi mieć możliwość nadawania odpowiednich uprawnień
poszczególnym konsolom, grupom dyspozytorów i użytkownikom uprzywilejowanym.
KD.18
Możliwość
konsole.
KD.19
Po konsultacjach z zamawiającym wykonawca zaproponuje organizację i wygląd
interfejsu graficznego konsoli, z zastrzeżeniem modyfikacji wyglądu i funkcjonalności
przez zamawiającego w okresie do 6 miesięcy od uruchomienia WCPR.
KD.20
Zamawiający wymaga, aby całość wymaganej funkcjonalności była realizowana
przez zintegrowaną aplikację działającą na konsoli dyspozytorskiej. Zamawiający nie
dopuszcza rozwiązania, w którym dla realizacji wymagań opisanych w tej tabeli
użytkownik będzie musiał uruchamiać niezależne aplikacje.
KD.21
Obsługa co najmniej 4 kolejek z funkcją ACD (Automatic Call Distribution), obsługa
gorących linii pozwalająca na obserwację stanu łącza abonenta.
KD.22
Obsługa interkomu do szybkiej łączności pomiędzy operatorami.
KD.23
Obsługa lokalnej i globalnej książki telefonicznej.
KD.24
Obsługa konferencji zwykłej i selektorowej również w modelu sieciowym. Łączna
minimalna liczba uczestników konferencji to 48.
KD.25
Obsługa pozwalająca na realizacje połączeń crossconect (połączenie radiostacji
z telefonem) i crossband (połączenie dwóch radiostacji).
KD.26
Obsługa fax-ów, polegającą na zobrazowaniu i archiwizowaniu zgłoszeń.
KD.27
Obsługa historii zdarzeń telefonicznych, radiowych, SMS, statusów i alarmów.
odsłuchu
zarejestrowanej
korespondencji
prowadzonej
przez
daną
22
Kod
wymagania
Opis
Pozwalająca na przeglądanie zdarzeń z co najmniej 7 ostatnich dni oraz ich
archiwizację.
KD.28
Obsługa alarmów urządzeń oddalonych, polegająca na zgłaszaniu zdarzeń typu
otwarcie obudowy, brak napięcia zasilania, brak zasilania czujek ruchu PIR, wzrost
lub zmniejszenie się temperatury w pomieszczeniu powyżej lub poniżej ustalonej
wartości, zadziałanie czujki PPOŻ.
KD.29
Zmiana konfiguracji aplikacji nie może powodować jej restartu, nie jest odczuwalna
z punktu widzenia użytkownika.
KD.30
Obsługa profili operatorskich. Profile operatorskie systemu określają zakres
odpowiedzialności i przywileje jakie posiada operator posługujący się danym
profilem. Profil musi zawierać informacje na temat:
a. kanałów radiowych, dostępnych na stanowisku operatorskim,
b. praw dostępu do kanałów (tryby pracy operatora na danym kanale i priorytety),
c. praw do zmiany częstotliwości i mocy nadawania określonych kanałów,
d. dostępnych zasobów telefonicznych (kolejki, gorące linie),
e. wyglądu interfejsu (rozmieszczenie przycisków, napisy na przyciskach).
KD.31
Obsługa zestawu funkcji umożliwiających powiadamianie telefoniczne zdefiniowanej
grupy osób.
KD.32
Obsługa następujących funkcji dyspozytorskich:
a. Kierowanie wywołań do 4 kolejek
b. Możliwość podjęcia z kolejki dowolnego abonenta
c. Możliwość zawieszenia do 3 wywołań (HOLD)
d. Możliwość szybkiego przekazania połączenia
e. Możliwość grupowania klawiszy gorących linii w zakładki
f. Możliwość przypisywania klawiszom gorących linii kolorów
g. Możliwość definiowania kolorów dla różnych stanów wskazywanych przez klawisze
gorących linii
h. Możliwość przypisania typu dzwonka do klawisza
i. Możliwość przypisania dzwonka do kolejki.
KD.33
Możliwość zaprogramowania grup poszukiwania – tworzenie numeru grupowego po
wybraniu, którego wywoływane będą kolejne terminale wg określonego szyku:
liniowo, cyklicznie, grupowo (równoległa sygnalizacja wywołania na kilku stacjach).
KD.34
Możliwość zdefiniowania grup przechwytujących – w przypadku wywołania na
jednym z terminali abonenckich z grupy możliwość przejęcia tego wywołania na
dowolnym innym terminalu.
KD.35
„Oddzwanianie” przy zajętości – w przypadku zajętości wywoływanego terminala
abonent może zażądać zasygnalizowania faktu, że terminal wywoływany przeszedł
w stan spoczynku, tzn. zakończyła dotychczasowe połączenie.
KD.36
„Oddzwanianie” przy braku odpowiedzi – w przypadku braku odpowiedzi ze strony
wywoływanego terminala abonent może zażądać zasygnalizowania faktu, że pojawiła
się jakakolwiek aktywność ze strony wywoływanego terminala (np. zrealizował
połączenie i przeszedł w stan spoczynku).
KD.37
Zróżnicowany sygnał dzwonienia
specjalnych (połączenia pilne itp.)
KD.38
„Wejście na trzeciego” dla uprzywilejowanego abonenta (pulpitu dyspozytorska, itp.)
możliwość włączenia się w trwającą rozmowę.
KD.39
Ochrona przed „wejściem na trzeciego” - możliwość aktywowania dla wewnętrznego
wybranego abonenta usługi uniemożliwiającej włączenie w prowadzone przez niego
dla
rozmów
wewnętrznych,
zewnętrznych,
23
Kod
wymagania
Opis
rozmowy.
5.7.
Wymagania w zakresie szkoleń
Kod
wymagania
EDU.01
W ramach wdrożenia Systemu Wykonawca przeprowadzi szkolenia w języku polskim
dla
40
oraz
20
administratorów-instruktorów
(wytypowanych przez Zamawiającego) obejmujących wykłady teoretyczne oraz
warsztaty wdrożeniowe w zakresie użytkowania i administrowania wdrożonej wersji
prototypu Systemu.
EDU.02
W ramach wdrożenia Systemu Wykonawca przeprowadzi szkolenia w języku polskim
dla
40
oraz
20
administratorów-instruktorów
wymienionych w pkt EDU.01 obejmujących wykłady teoretyczne oraz warsztaty
wdrożeniowe w zakresie użytkowania i administrowania Systemu obejmujące
zmiany Systemu wynikające z realizacji Etapu III.
EDU.04
Szkolenie dla trenerów oraz administratorów obejmować ma minimum 14h. Czas
trwania szkolenia - min. 2 dni (po maks. 8 godzin/dziennie).
EDU.05
Wykonawca opracuje harmonogram szkoleń zawierający:
 cel i projektowany zakres szkoleń,
 informacje o zakresie tematycznym szkoleń,
 metodzie i formie szkoleń,
 czasie trwania szkoleń,
 pożądanych kwalifikacjach osób skierowanych na szkolenia, ich
jednostkowym oraz miejscu przeprowadzenia poszczególnych szkoleń.
koszcie
EDU.06
Harmonogram, o którym mowa w EDU 5, wykonawca
zamawiającego.
przedstawi do akceptacji
EDU.07
Wykonawca zobowiązany jest do przeprowadzenia szkoleń zgodnie z zatwierdzonym
harmonogramem szkoleń.
EDU.08
Wszystkie szkolenia Wykonawca przeprowadzi w języku polskim, zapewniając
materiały szkoleniowe (w języku polskim) dla uczestników szkoleń oraz przeniesie
prawa autorskie do opracowanych materiałów szkoleniowych.
EDU.09
Wykonawca dostarczy Zamawiającemu multimedialne materiały szkoleniowe
w postaci zapisu na płycie CD-ROM (lub innym równoważnym nośniku).
EDU.10
Wykonawca zapewni prowadzenie szkoleń przez wykwalifikowaną kadrę posiadającą
wiedzę teoretyczną i praktyczną z zakresu przedmiotu zamówienia.
EDU.11
Przeszkoleni administratorzy i instruktorzy otrzymają potwierdzenie ukończenia
szkolenia stwierdzające, że osiągnęli oni wiedzę niezbędną do pełnienia
powierzonych zadań oraz inne dokumenty potwierdzające nabycie określonych
umiejętności (certyfikat).
EDU.12
Przeprowadzenie szkoleń zostanie potwierdzone protokołem sporządzonym w dwóch
jednobrzmiących egzemplarzach, po jednym dla Zamawiającego i Wykonawcy,
zawierającym:
 nazwę i tematykę i czas trwania szkolenia,
 datę i miejsce szkolenia,
 imienną listę osób uczestniczących w szkoleniu,
 imię i nazwisko oraz specjalizację osób prowadzących szkolenie,
24
Kod
wymagania
EDU.13
Protokół z przeprowadzenia
Zamawiającego.
5.8.
szkoleń
podlegać
będzie
zatwierdzeniu
przez
Wymagania w zakresie dokumentacji
Kod
wymagania
DOC.01
Zamawiający wymaga, aby Wykonawca przygotował, zgodnie z ogólnie
akceptowalnymi standardami w dziedzinie dokumentowania, następujące rodzaje
dokumentacji bezpośrednio związanej z przedmiotem zamówienia:
DOC.01.1
Projekt techniczny zawierający, co najmniej następujące informacje:
 Szczegółową specyfikację wymagań dla Systemu zgodnie z przekazanym
przez Zamawiającego szablonem,
 Diagram kontekstowy realizacji przedmiotu zamówienia,
 Procesy kierujące realizacją przedmiotu zamówienia
 Struktura i zawartość planów realizacji przedmiotu zamówienia,
 Techniki zarządzania realizacją przedmiotu zamówienia,
 Zestaw elementów sterujących zarządzaniem i jakością, w tym tworzona
dokumentacja obejmująca również działania zarządcze, tj. planowanie,
monitorowanie i raportowanie prac w ramach realizacjiprzedmiotu Zamówienia,
w sytuacjach normalnych i wyjątkowych, a także działania specjalistyczne
determinowane przez zakres i cele umowy/przedmiotu Zamówienia, opisujące
prace niezbędne do wytworzenia produktów, które mają powstać w ramach
realizacji przedmiotu zamówienia.
DOC.01.2
Dokumentację powykonawczą, zawierającą co najmniej następujące informacje:
 Wprowadzenie opisujące cele i zakres przedmiotu zamówienia,
 Diagram kontekstowy zaproponowanego rozwiązania i model zachowania,
 Ograniczenia rozwiązania, założenia i zależności,
 Ogólna charakterystyka użytkowników,
 Opis wymagań funkcjonalnych i niefunkcjonalnych Systemu,
 Specyfikację wymagań funkcjonalnych,
 Specyfikację wymagań niefunkcjonalnych,
 Opis wymagań sprzętowych i programowych,
 Specyfikację wymagań sprzętowych,
 Specyfikację wymagań programowych,
 Opis i specyfikację interfejsów,
 Opis sposobu realizacji przedmiotu zamówienia zależny od zastosowanych
metod, tj. metod obiektowych lub strukturalnych,
 Program przebiegu testów akceptacyjnych i sposób oszacowania niezawodności
zaproponowanego rozwiązania, w tym propozycję raportów z testów,
 Kody źródłowe.
DOC.02
Zamawiający wymaga, aby wszystkie dokumenty tworzone w ramach realizacji
przedsięwzięcia charakteryzowały się wysoką jakością, na którą będą miały wpływ,
takie czynniki jak:
 Struktura dokumentu, rozumiana jako podział danego dokumentu na rozdziały,
podrozdziały i sekcje, w czytelny i zrozumiały sposób.
 Zachowanie standardów, w tym notacji UML, a także sposób pisania,
25
Kod
wymagania


rozumianych jako zachowanie spójnej struktury, formy i sposobu pisania dla
poszczególnych dokumentów oraz fragmentów tego samego dokumentu
Kompletność dokumentu, rozumiana jako pełne, bez wyraźnych, ewidentnych
braków przedstawienie omawianego problemu obejmujące całość z danego
zakresu rozpatrywanego zagadnienia.
Spójność i niesprzeczność dokumentu, rozumianych jako zapewnienie
wzajemnej zgodności pomiędzy wszystkimi rodzajami informacji umieszczonymi
w dokumencie, jak i brak logicznych sprzeczności pomiędzy informacjami
zawartymi we wszystkich przekazanych dokumentach oraz we fragmentach tego
samego dokumentu.
DOC.03
Zamawiający wymaga, aby cała dokumentacja, o której mowa powyżej, podlegała
jego akceptacji, a także, aby została dostarczona w języku polskim, w wersji
elektronicznej w niezabezpieczonym/edytowalnym formacie Word i PDF (na płycie
CD-ROM lub innym równoważnym nośniku danych) i drukowanej, co najmniej
w 3 egzemplarzach (dopuszcza się inne formaty zapisu dokumentacji np. diagramy
UML lub formaty wektorowe jak DWG,. DXF, należy jednak dołączyć przeglądarkę
obsługującą wykorzystane formaty). Diagramy UML sporządzone za pomocą
narzędzi CASE powinny być dostarczone w formacie EAP. Dostarczone wykresy
Gantta powinny być dostarczone w formacie MPP lub w formacie XLS
umożliwiającym import do MS Project.
DOC.04
Wszelka Dokumentacja projektowa wytworzona w ramach realizacji przedmiotu
Zamówienia musi być zgodna z wytycznymi dot. opracowania dokumentacji
projektowej opisanymi w „Zasadach promocji projektów dla beneficjentów Programu
Operacyjnego Infrastruktura i Środowisko 2007-2013” tzn. musi być opatrzona
logotypami: Programu Operacyjnego Infrastruktura i Środowisko, Unia Europejska
z odniesieniem słownym do Europejskiego Funduszu Rozwoju Regionalnego, logo
Beneficjenta.
Szablony Dokumentacji projektowej zostaną przekazane Wykonawcy przez
Zamawiającego.
5.9.
Kod
wymagania
PR.01
Wymagania w zakresie zgodności Systemu z przepisami prawa
Opis wymagania

System musi być zgodny z niżej wymienionymi aktami prawnym:

Rozporządzenie Rady Ministrów w sprawie minimalnych wymagań dla
systemów teleinformatycznych z dnia 11.10.2005 roku.

Ustawa o ochronie danych osobowych z dnia 29.08.1997 roku.

Ustawa o informatyzacji działalności podmiotów realizujących zadania
publiczne
z dnia 17.02.2005 roku.

Ustawa z dnia 24 sierpnia 1991 r. o ochronie przeciwpożarowej (Dz. U.
z 2009 r. Nr 178, poz. 1380);

Ustawa z dnia 18 kwietnia 2002 r. o stanie klęski żywiołowej (Dz. U. z 2002
r. Nr 62, poz. 558, z późn. zm.);

Ustawa z dnia 16 lipca 2004 r. - Prawo telekomunikacyjne (Dz. U. z 2004 r.
26
Kod
wymagania
Opis wymagania
Nr 171, poz. 1800, z późn. zm.);

Ustawa z dnia 8 września 2006 r. o Państwowym Ratownictwie Medycznym
(Dz. U. z 2006 r. Nr 191, poz. 1410, z późn. zm.);

Ustawa z dnia 26 kwietnia 2007 r. o zarządzaniu kryzysowym (Dz. U.
z 2007 r. Nr 89, poz. 590 z późn. zm.);

Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 31
lipca 2009 r. w sprawie organizacji i funkcjonowania centrów
powiadamiania ratunkowego i wojewódzkich centrów powiadamiania
ratunkowego (Dz. U. z 2009 r. Nr 130, poz. 1073);

Dyrektywa 2002/22/WE Parlamentu Europejskiego i Rady z dnia 7 marca
2002 r. w sprawie usługi powszechnej i związanych z sieciami i usługami
łączności elektronicznej praw użytkowych;
5.10. Wymagania w zakresie gwarancji
Kod
wymagania
Opis wymagania
WG.01
Gwarancja na dostarczone elementy infrastruktury sprzętowej i oprogramowanie
biegnie osobno dla każdej dostawy od daty podpisania przez Zamawiającego
protokołu jakościowego danej dostawy. W przypadku jeżeli świadczenie
gwarancyjne
polegać
będzie
na
wymianie
wadliwego
elementu
lub
oprogramowania na wolne od wad, okres gwarancji dla tego elementu
(oprogramowania) biegł będzie na nowo od daty protokołu stwierdzającego tą
wymianę.
WG.02
Wymagany tryb zgłaszania awarii w trybie 24/7. Zgłoszenie następuje w drodze
pisemnej faksem lub mailem na adres podany przez Wykonawcę:
fax pod numer ..........................................
mail na adres ..........................................
WG.03
Wykonawca dokona usunięcia Awarii Niekrytycznej Systemu w terminie nie
dłuższym niż 24 godzin od momentu zgłoszenia Awarii Niekrytycznej ( usunięcie
Awarii Niekrytycznej rozumiane jest jako przywrócenie funkcjonalności Systemu
sprzed Awarii Niekrytycznej).
WG.04
Wykonawca dokona usunięcia Awarii Zwykłej Systemu w terminie nie dłuższym niż
72 godzin od momentu zgłoszenia Awarii Zwykłej (usunięcie Awarii Zwykłej
rozumiane jest jako przywrócenie funkcjonalności Systemu sprzed Awarii
Zwykłej).
WG.05
Przez usunięcie każdej Awarii rozumie się rozwiązanie problemu lub
zaproponowanie procedury obejścia pozwalającej na funkcjonowanie Systemu bez
rozwiązania problemu.
Wykonawca dokona naprawy (lub wymiany elementu) w lokalizacji wskazanej
przez Zamawiającego; w przypadku konieczności dokonania naprawy poza
lokalizacją Zamawiającego, Wykonawca pokryje koszty transportu i ewentualnego
ubezpieczenia przedmiotu zamówienia do miejsca naprawy oraz jego zwrotu do
lokalizacji wskazanej przez Zamawiającego.
WG.06
27
Kod
wymagania
Opis wymagania
WG.08
Zamawiający dopuszcza realizację świadczenia gwarancyjnego w ten sposób, że
na podstawie informacji diagnostycznych przekazanych przez Zamawiającego
Wykonawcy podczas zgłoszenia awarii, Wykonawca prześle na swój koszt
zamiennik uszkodzonego elementu, natomiast fizycznej wymiany uszkodzonego
elementu dokona odpowiednio przeszkolony przez Wykonawcę pracownik
Zamawiającego, czyniąc to na ryzyko Wykonawcy. Jednakże taki tryb realizacji
naprawy nie zwalnia Wykonawcy z obowiązku zapewnienia przywrócenia
pierwotnego stanu pracy systemu. Jeżeli dla dotrzymania założonego terminu
naprawy systemu konieczne jest dokonanie naprawy w siedzibie Zamawiającego,
Wykonawca jest zobowiązany do samodzielnego dokonania naprawy urządzenia
w siedzibie Zamawiającego.
WG.09
Gwarancja obejmuje również wykonanie przez Wykonawcę wszelkich czynności
związanych z przywróceniem pierwotnego stanu pracy Systemu (sprzed Awarii)
oraz pokrycie przez Wykonawcę kosztów części zamiennych użytych do
przywrócenia Systemu do stanu pierwotnego (sprzed awarii).
WG.10
W okresie gwarancji Wykonawca w ramach otrzymanego wynagrodzenia
udostępni Zamawiającemu możliwość wielokrotnego uaktualniania całego
dostarczonego
oprogramowania
standardowego
do
najnowszych
wersji
oferowanych przez producenta oprogramowania (włączając tzw. firmware),
a także dostęp do usług wsparcia technicznego właściwych dla danego produktu.
W przypadku, gdy dostęp taki wymaga podania nazwy użytkownika, hasła lub
numeru seryjnego Wykonawca dostarczy Zamawiającemu ww. przed podpisaniem
protokołu zdawczo-odbiorczego.
WG.11
Zamawiający zastrzega sobie prawo do dodawania nowych komponentów
dowolnych
producentów
oraz
wymiany
zainstalowanych
komponentów
samodzielnie lub z pomocą Wykonawcy bez utraty gwarancji na zakupiony sprzęt.
Zamawiający będzie dokonywał wymiany podzespołów samodzielnie po
wcześniejszym uzgodnieniu z Wykonawcą. Jeżeli Wykonawca nie udzieli zgody na
samodzielną wymianę lub dodanie podzespołów przez Zamawiającego, wówczas
jest obowiązany sam dokonać takiej wymiany lub dodania komponentów
w terminie 3 dni od zgłoszenia żądania przez Zamawiającego w ramach
wynagrodzenia otrzymanego za dostarczone elementy w ramach danej dostawy.
28
5.11. Wymagania w zakresie zarządzanie projektem
Kod
wymagania
Opis wymagania
MGM.01
Wymaga się od Wykonawcy aby:

organizacja przedsięwzięcia związanego z przedmiotem zamówienia,

procesy kierujące przedsięwzięciem,

struktura i zawartość planów projektu,

techniki zarządzania projektem,

zestaw elementów sterujących zarządzaniem i jakością, w tym cała
tworzona dokumentacja,
zostały oparte o ogólnie znaną metodykę projektową lub własną uwzględniającą
konkretne techniki, narzędzia i notacje, a także zapewniającą osiągnięcie
zamierzonych celów jakościowych przy jednoczesnej minimalizacji możliwości
niepowodzenia przedsięwzięcia.
W przypadku wykorzystywania przez Wykonawcę własnej metodyki zarządzania
przedsięwzięciem, wymaga się, aby uwzględniała ona co najmniej następujące
elementy:

sposób zarządzania projektem, w tym proces kontroli postępu prac
w zakresie kosztów, pracochłonności i zgodności z harmonogramem,
a także częstotliwości punktów kontrolnych, raportowanie o postępach
w realizacji projektu oraz sposób zarządzania problemami w realizacji
projektu,

proces przygotowania planu realizacji przedsięwzięcia w tym planu
zapewnienia jakości przedsięwzięcia

analizę ryzyka przed rozpoczęciem projektu i zarządzanie ryzykiem
w trakcie jego realizacji,

sposób zarządzania konfiguracją, w tym identyfikacja elementów
konfiguracji, kontrola wersji, informowanie o zmianach,

sposób zarządzania zmianami, w tym rodzaje modyfikacji (poprawki,
aktualizacje, rozbudowa, udoskonalenia) oraz procedury kontroli zmian.
MGM.02
29

opis przedmiotu zamówienia (opz)

Transkrypt

Podobne dokumenty

Generuj PDF - KPP Krosno Odrzańskie

plakat + druk 1.cdr

POLICJA ŚWIĘTOKRZYSKA POMOC PRZYJDZIE SZYBCIEJ

Otwórz - Atende SA

Praca w Centrum Powiadamiania Ratunkowego

więcej

oferta pracy

Program konferencji