PROJEKT OPISU PRZEDMIOTU ZAMÓWIENIA

Strona |1
Załącznik nr 1 do Wniosku
PROJEKT OPISU PRZEDMIOTU ZAMÓWIENIA
Dostawa Urządzeń oraz Oprogramowania, wykonanie usługi instalacji, konfiguracji oraz
uruchomienia pełnej funkcjonalności Systemu Operatora Numerów Alarmowych (SONA)
a także dostawa Urządzeń i Oprogramowania, wykonanie usługi instalacji, konfiguracji w
celu rozbudowy Systemu Wspomagania Dowodzenia Państwowego Ratownictwa
Medycznego (SWD PRM).
Strona |2
Spis treści
1
SŁOWNIKI I SKRÓTY .............................................................................................. 3
2
CEL ZAMÓWIENIA .................................................................................................. 6
3
PRZEDMIOT ZAMÓWIENIA ...................................................................................... 7
4
AKTUALNE ŚRODOWISKO SI WCPR - informacje ........................................................ 9
4.1
Wydajność SI WCPR .................................................................................... 9
4.2
Lista typów oprogramowania standardowego .................................................. 9
4.3
SWD PRM .................................................................................................. 10
4.4
OST112 ..................................................................................................... 10
4.5
Systemy Zewnętrzne .................................................................................. 11
5
PROJEKTOWANA ARCHITEKTURA ROZWIĄZANIA ..................................................... 11
5.1
Wymagania minimalne dla redundancji POK i ZOK. ......................................... 13
5.2
Wymagania minimalne na Dodatkowe Funkcjonalności oraz rozbudowę SWD PRM
16
5.2.1
rozwiązanie tworzenia kopii bezpieczeństwa (tzw. backup) SONA i SWD PRM 16
5.2.2
zwiększenie wydajności SONA ................................................................. 20
5.2.3
system archiwizacji SONA ...................................................................... 21
5.2.4
rozbudowa systemu archiwizacji SWD PRM ............................................... 21
5.2.5
System monitorowania SONA i SWD PRM ................................................. 22
5.2.6
Rozbudowa SONA o środowisko szkoleniowe (SZK SONA) .......................... 25
5.2.7
Budowa oraz rozbudowa interfejsów do Systemów Zewnętrznych ................ 27
5.2.8
Rozbudowa SONA o środowisko pre-produkcyjne (PRE SONA) .................... 27
5.2.9
Rozbudowa SONA o środowisko developerskie (DEV SONA) ........................ 28
6
WYMAGANIA DOTYCZĄCE USŁUGI INSTALACJI URZĄDZEŃ ....................................... 28
7
WYMAGANIA W ZAKRESIE PRODUKCYJNEGO URUCHOMIENIA SYSTEMU..................... 29
8
WYMAGANIA W ZAKRESIE WARSZTATÓW ............................................................... 29
9
WYMAGANIA W ZAKRESIE DOKUMENTACJI ............................................................. 30
10
WYMAGANIA W ZAKRESIE OZNAKOWANIA URZĄDZEŃ i DOKUMENTACJI .................... 34
11
WYMAGANIA W ZAKRESIE DOSTĘPNOŚCI ............................................................... 34
12
WYMAGANIA W ZAKRESIE GWARANCJI .................................................................. 34
13
WYMAGANIA W ZAKRESIE ZGODNOŚCI Z PRZEPISAMI PRAWA ................................. 36
14
WYMAGANIA W ZAKRESIE ZARZĄDZANIA PROJEKTEM ............................................. 37
15
LISTA ZAŁĄCZNIKÓW ........................................................................................... 38
Strona |3
1
SŁOWNIKI I SKRÓTY
Dla potrzeb niniejszego opracowania przyjmuję się następujące definicje skrótów i pojęć:
Skrót/pojęcie
Definicja
Błąd Krytyczny
Oznacza brak działania środowiska Systemu, praca nie może być
kontynuowana, operacja krytyczna dla procesu biznesowego jest
niemożliwa. Błędy Krytyczne mają jedną lub więcej z poniższych cech:
a) dane biznesowe zostały uszkodzone;
b) 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, stosując procedury
przygotowane przez Wykonawcę, tudzież procedury przygotowane
przez Zamawiającego i zaakceptowanych przez Wykonawcę w trakcie
okresu gwarancji ;
Błąd Niekrytyczny
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, stosując przygotowane przez
Wykonawcę procedury tudzież procedury przygotowane przez
Zamawiającego i zaakceptowanych przez Wykonawcę w trakcie okresu
gwarancji (co może mieć wpływ na wygodę w użytkowaniu Systemu
lub wymagać procedur ręcznych). „Uniemożliwia” oznacza brak
możliwości jego obejścia;
Błąd Zwykły
Wszelki błąd nie
Niekrytycznym;
CP SCPR
Infrastruktura tworząca system o którym mowa w Rozporządzeniu
Ministra SWiA z dn. 24 marca 2011 r. w sprawie centralnego punktu
systemu centrów powiadamiania ratunkowego oraz punktów
centralnych służb, dostarczana w ramach oddzielnego postępowania;
Dodatkowe
Funkcjonalności
Określone w pkt. 5.2 niniejszego dokumentu funkcjonalności do SI
WCPR i rozbudowa SWD PRM, realizowane przez Urządzenia i
Oprogramowanie dostarczane w ramach niniejszego zamówienia. W
przypadku przebudowy POK (w tym infrastruktura SI WCPR, SWD
PRM), także te funkcjonalności które podlegają przebudowie;
Dokumentacja
Wytworzone przez Wykonawcę 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, w szczególności Projekt Techniczny,
plan wdrożenia Systemu, Plan Testów Akceptacyjnych (PTA), Plan
Zarządzania
Projektem,
Dokumentacja
Powykonawcza,
Plan
Wdrożenia, Procedury Eksploatacyjne, Raport Wdrożenia;
Funkcjonalność
Krytyczna
Cechy
funkcjonalne
Systemu,
uzupełniające
dotychczasową
infrastrukturę SI WCPR i SWD PRM o funkcjonalności, które nie
występowały w dotychczasowym SI WCPR lub SWD PRM. W przypadku
przebudowy POK (w tym infrastruktura SI WCPR, komponenty
wspólne z SWD PRM), także te funkcjonalności które podlegają
przebudowie;
GUGiK
Główny Urząd Geodezji i Kartografii;
Incydent serwisowy
Oznacza
zgłoszenie
będący
Błędem
Krytycznym
lub
Błędem
do Wykonawcy przez Zamawiającego, bądź
Strona |4
Skrót/pojęcie
Definicja
uprawniony do tego podmiot, wystąpienia błędu, błędu lub usterki
SONA. Wykonawca zobowiązany jest do usuwania wszelkich błędów,
błędu, usterek lub dostarczenia procedur obejścia, powodujących
przywrócenia działania Systemu rozwiązania zgłoszenia;
Lokalizacje
Oznacza wskazane przez Zamawiającego lokalizacje na terenie RP
określone w Projekcie Technicznym, do których Wykonawca dostarczy
wymagane przez Zamawiającego elementy Systemu będące
przedmiotem niniejszego zamówienia;
Modyfikacja
Oznacza wyższe wersje (update/upgrade) patche, programy korekcji
błędów i inne zmiany funkcjonalne ponad określone w opisie
Przedmiotu Umowy –
w odniesieniu do Oprogramowania
Aplikacyjnego, wyższe wersje (update/upgrade) patche i programy
korekcji błędów – w odniesieniu do Oprogramowania Standardowego,
do których wykonania i dostarczenia wraz z odnoszącą się do tego
dokumentacją zobowiązany jest Wykonawca oraz usługi polegające na
wprowadzaniu przez Wykonawcę zmian w konfiguracji sprzętowej,
Oprogramowaniu Standardowym PZŁ wykonywane w ramach zleceń
zgodnie z oczekiwaniami Zamawiającego oraz Użytkowników
końcowych lub zlecenia wykonania usług konsultacyjnych oraz zmian
w Dokumentacji.;
Nadzór Autorski
Czynności Wykonawcy wykonywane w ramach Zleceń polegające na
doradztwie i konsultacjach technicznych, modyfikacji Oprogramowania
Aplikacyjnego, usprawnieniach, rozbudowie, zmianach konfiguracji w
Systemie,;
Operator
Użytkownik pełniący rolę operatora, koordynatora albo dyspozytora
realizujący funkcję przyjęcia i obsługi w wykorzystujący SI WCPR.
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 i MAiC 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 z Projektem Technicznym Systemu, do których Wykonawca
przeniesie autorskie prawa majątkowe na Zamawiającego i MAiC na
warunkach i zasadach określonych w Umowie
OST 112
Ogólnopolska Sieć Teleinformatyczna na potrzeby obsługi numeru
alarmowego 112 ;
Ośrodek Krajowy
POK lub ZOK;
Ośrodki
Regionalne/OR
Element infrastruktury 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 są
zlokalizowane w lokalizacjach WCPR);
Plan Testów
Akceptacyjnych / PTA
Dokument opracowany przez Wykonawcę podlegający akceptacji
Zamawiającego, wytworzony na podstawie szablonu Planu Testów
Akceptacyjnych (PTA), którego wzór stanowi Załącznik nr 1 do OPZ;
Strona |5
Skrót/pojęcie
Definicja
PLI CBD
Platforma Lokalizacyjno-Informacyjna z Centralną
dostarczona przez Urząd Komunikacji Elektronicznej;
POK /Podstawowy
Ośrodek Krajowy
Centrum serwerowe w oparciu o które zbudowana została architektura
systemu SI WCPR na poziomie centralnym. Jest to obecnie istniejąca
infrastruktura SI WCPR wraz z aktualnie wykorzystywanym
oprogramowaniem (w szczególności SI WCPR, PZŁ);
PRM
Państwowe Ratownictwo Medyczne;
Projekt Techniczny
Projekt techniczny Systemu, element Dokumentacji opisujący sposób
wykonania, wdrożenia i właściwości uzupełnień funkcjonalności do
poziomu SONA oraz rozbudowy SWD PRM. Szczegółowe wymagania
dla Projektu Technicznego zostały określone w wymaganiu DOK.1.1;
PZP (Plan Zarządzania
Projektem)
Element Dokumentacji definiujący organizację procesy, narzędzia i
techniki dobrane w celu skutecznej i efektywnej realizacji przedmiotu
Umowy,
zawierający
co
najmniej
szczegółowy
opis
zadań
realizowanych w ramach Etapów, harmonogram, plan komunikacji,
szczegółowe procedury zgłoszeń występowania wszelkich błędów i
błędu oraz obsługi Incydentów serwisowych realizowanych w ramach
serwisu gwarancyjnego;
PZŁ
Podsystem Zintegrowanej Łączności, moduł komunikacyjny łączności
telefonicznej i radiowej zintegrowany z aplikacją SI WCPR;
SI PR
System Informatyczny Powiadamiania Ratunkowego;
SI WCPR
Dostarczony
w
ramach
oddzielnego
postępowania
System
Informatyczny Wojewódzkich Centrów Powiadamiania Ratunkowego
wraz
z
zainstalowanym
oprogramowaniem
standardowym,
aplikacyjnym oraz infrastrukturą sprzętową. Infrastruktura sprzętowa
dzieli się na infrastrukturę centralną (Podstawowy Ośrodek Krajowy),
infrastrukturę
regionalną
(Ośrodki
Regionalne),
oraz
sprzęt
teleinformatyczny;
SK
Serwer Komunikacyjny, infrastruktura w ramach SI WCPR;
SONA
System Operatora Numerów Alarmowych, w skład którego wejdzie
istniejąca infrastruktura SI WCPR, Urządzenia i Oprogramowanie,
Dodatkowe Funkcjonalności (bez rozbudowy SWD PRM) oraz POK i
ZOK, a także zmiany dokonane przez Wykonawcę do SI WCPR, w tym
architektura, Oprogramowanie, Urządzenia, spełniające co najmniej
wymagania SI WCPR.
SWD
System Wspomagania Dowodzenia klasy dyspozytorskiej „czasu
rzeczywistego” wspomagającego obsługę zdarzeń, wykorzystywany
Państwowe Ratownictwo Medyczne, Policję i Państwową Straż Pożarną,
które są dostarczane w ramach oddzielnych postępowań;
SWD PRM
System Wspomagania Dowodzenia klasy dyspozytorskiej „czasu
rzeczywistego” wspomagającego obsługę zdarzeń, wykorzystywany
przez Państwowe Ratownictwo Medyczne, dostarczany w ramach
oddzielnego postępowania;
Systemy Zewnętrzne
Systemy teleinformatyczne biorące udział w obsłudze Zgłoszeń, w tym
m.in.: SWD, System LPR, NFZ, CSIOZ, GUGiK, PLI CBD, eCall.
System
SONA oraz
zamówienia;
SZK WCPR
Środowisko szkoleniowe SI WCPR;
Urządzenia
Sprzęt teleinformatyczny wraz z niezbędnym wyposażeniem, w tym
również okablowanie strukturalne i szafy rackowe, będące
rozbudowa
SWD
PRM
wynikająca
Bazą
z
Danych,
niniejszego
Strona |6
Skrót/pojęcie
Definicja
przedmiotem niniejszego zamówienia;
Użytkownik
Użytkownik WCPR/CPR oraz SWD PRM ;
WCPR
Wojewódzkie Centrum Powiadamiania Ratunkowego, 17 lokalizacji w
Polsce;
Wykonawca/Dostawca
Podmiot realizujący Przedmiot Zamówienia;
Zamawiający
Centrum Projektów Informatycznych;
Zlecenie
Oznacza zamówienie złożone przez Zamawiającego, będące podstawą
realizacji przez Wykonawcę usługi Nadzoru Autorskiego;
Zgłoszenie
Wywołanie alarmowe przyjmowane przez Użytkownika;
ZOK /Zapasowy
Ośrodek Krajowy
Centrum serwerowe, dostarczane w ramach niniejszego zamówienia,
udostępniające funkcjonalność SONA (w tym redundancji).
Pozostałe pojęcia użyte w dokumencie należy rozumieć zgodnie z ich ogólnie przyjętym
znaczeniem.
2
CEL ZAMÓWIENIA
Zadanie
polega
na
doposażeniu
sprzętowo-programowym
istniejącej
infrastruktury
informatycznej Systemu Informatycznego Wojewódzkich Centrów Powiadamiania Ratunkowego (SI
WCPR) celem uruchomienia w tym środowisku pełnej funkcjonalności Systemu Operatora Numerów
Alarmowych (SONA), co najmniej do określonych w dokumencie Studium Wykonalności System
Informatyczny Powiadamiania Ratunkowego, oraz doposażenia Systemu Wspomagania Dowodzenia
Państwowego Ratownictwa Medycznego. SONA powstanie w wyniku rozbudowy funkcjonalności
wdrożonej architektury SI WCPR.
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 stanowi główny
element wyposażenia podmiotów ratowniczych 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 z późn.
zm.), oraz komórek organizacyjnych Policji.
Przedmiotowe zamówienie finansowane jest w ramach 7. osi priorytetowej
Operacyjnego Innowacyjna Gospodarka (PO IG).
Programu
Strona |7
3
PRZEDMIOT ZAMÓWIENIA
Przedmiotem zamówienia jest Dostawa Urządzeń oraz Oprogramowania, wykonanie
usługi
instalacji,
konfiguracji
oraz
uruchomienia
pełnej
funkcjonalności
Systemu
Operatora Numerów Alarmowych (SONA) a także dostawa Urządzeń i Oprogramowania,
wykonanie usługi instalacji, konfiguracji w celu rozbudowy Systemu Wspomagania
Dowodzenia Państwowego Ratownictwa Medycznego (SWD PRM).
Przedmiot zamówienia obejmuje:
Maksymalny czas
Etapy
Przedmiot zamówienia
przeznaczony do realizacji
Etapu:
1) opracowanie i dostarczenie Zamawiającemu
Projektu Technicznego Systemu;
Etap 1
2) przeniesienie na Zamawiającego i MAiC
autorskich praw majątkowych do
Dokumentacji wytworzonej w ramach etapu I
50
dni
od
dnia
podpisania umowy,
w tym 10 dni na odbiór
Etapu
1
przez
Zamawiającego.
3) Dostawę do Lokalizacji infrastruktury
Systemu:
a) Urządzeń i Oprogramowania,
b) Szaf rackowych oraz ich wyposażenia
w ilości umożliwiającej
przeprowadzenie poprawnej instalacji
oraz uruchomienia Urządzeń, a także
montażu przedmiotowych szaf;
4) instalację i konfigurację, zgodnie z Projektem
Technicznym odebranym przez
Zamawiającego, Urządzeń i Oprogramowania
Etap 2
Systemu, wraz z ich uruchomieniem;
5) przeprowadzenie testów akceptacyjnych
Systemu zgodnie z Planem Testów
Akceptacyjnych;
6) Opracowanie i dostarczenie Zamawiającemu
Planu Wdrożenia oraz Dokumentacji
Eksploatacyjnej;
7) przeniesienie na Zamawiającego i MAiC
autorskich praw majątkowych do
Oprogramowania Aplikacyjnego i
Dokumentacji wytworzonej w ramach etapu
2 oraz udzielenie Zamawiającemu i MAiC
130
dni
od
dnia
podpisania umowy,
w tym 30 dni na:

zadanie
nr
5
(20
dni),

odbiór Etapu 2 przez
Zamawiającego
dni).
(10
Strona |8
licencji do Oprogramowania wraz z prawem
udzielania sublicencji;
8) przeprowadzenie warsztatów w zakresie
użytkowania i administrowania Systemu w
świetle przeprowadzonych w ramach
niniejszego zamówienia zmian;
9) przeprowadzenie wdrożenia produkcyjnego
Systemu zgodnie z Projektem Technicznym
oraz Planem Wdrożenia;
10) opracowanie i dostarczenie Zamawiającemu
Raportu Wdrożenia;
11) przeprowadzenie, zgodnie z Projektem
Etap 3
Technicznym i Planem Wdrożenia odebranym
przez Zamawiającego, integracji Urządzeń i
Oprogramowania z istniejącym środowiskiem
SI WCPR;
190
dni
od
dnia
podpisania umowy
(w tym 10 dni na odbiór
Etapu
3
przez
Zamawiającego)
12) Opracowanie i dostarczenie Zamawiającemu
Dokumentacji powykonawczej;
13) przeniesienie na Zamawiającego i MAiC
autorskich praw majątkowych w zakresie
Dokumentacji wytworzonej w ramach etapu
3;
14) świadczenie od dnia zakończenia Etapu I do
dnia 31 grudnia 2013 r. Nadzoru Autorskiego
w wysokości 5000 roboczogodzin, w ramach
którego Wykonawca wykonywał będzie prace
związane z rozbudową oraz zmianą
Nadzór
Autorski
konfiguracyjną Systemu, w tym dokonywanie
od
zmian Oprogramowania Aplikacyjnego lub
Etapu
Dokumentacji zgodnie z oczekiwaniami
grudnia 2013 r.
Zamawiającego oraz Użytkownika wraz
przeniesieniem w ramach wynagrodzenia za
poszczególne Zlecenia majątkowych praw
autorskich do zmienionego Oprogramowania
Aplikacyjnego lub zmienionej Dokumentacji;
dnia
1
zakończenia
do
dnia
31
Strona |9
Gwarancja
15) udzielenie gwarancji i świadczenia usługi
serwisu gwarancyjnego dla Urządzeń oraz
Oprogramowania, dostarczanych w ramach
Etapu 2;
od zakończenia Etapu 2
do
dnia
gwarancji
końca
ustalonej w
umowie (co najmniej 24
miesiące).
Zamawiający wyznacza od dnia podpisania umowy maksymalną łączną ilość 190 dni na
potrzeby realizacji Etapu 1, 2 i 3 przedmiotu zamówienia.
4
AKTUALNE ŚRODOWISKO SI WCPR - informacje
Szczegółowy opis architektury SI WCPR, podlegającej uzupełnieniom do poziomu SONA,
znajduje się w dokumentacji stanowiącej Załącznik nr 1 do OPZ.
4.1
Wydajność SI WCPR
Wydajność systemu SI WCPR przedstawiona została w następującym zestawieniu:
Element
Wartość
Ilość zgłoszeń obsługiwana przez system w
ciągu roku
Procent ilości zgłoszeń przyjmowanych za
pośrednictwem FAX, SMS, e-mail
Ilość zgłoszeń przyjmowanych za
pośrednictwem FAX, SMS, e-mail w ciągu
roku
Wzrost ilości przyjmowanych zgłoszeń w
szczycie w stosunku do średniej ilości
Maksymalna ilość obsługiwanych zgłoszeń w
ciągu doby (10 razy więcej niż średnia ilość)
Ilość użytkowników pracujących
jednocześnie w systemie
5 000 000
10%
500 000
10 razy
140 000
200
Rysunek 1 wydajność SI WCPR
4.2
Lista typów oprogramowania standardowego
Typy oprogramowanie standardowego SI WCPR głównie obejmują:

Systemy operacyjny Microsoft Windows Server 2008 R2 Enterprise 64bit wraz z
komponentami składowymi, w tym komponentami niezbędnymi do stworzenia
ActiveDirectory oraz PKI,

Systemy operacyjny Suse Linux Enterprise Server 64bit,

Systemy operacyjne CentOS

Oprogramowania antywirusowe Symantec Endpoint Protection,

Serwery baz danych Microsoft SQL Server 2008 R2 EE,

Serwery baz danych Microsoft SQL Server 2008 Express,
S t r o n a | 10

Systemy operacyjne z rodziny Microsoft Windows,

Serwery baz danych Firebird,

Serwer bazy danych

Kontenery Apache Tomcat,

Serwery kolejek komunikatów ActiveMQ,

Oprogramowania wirtualizacyjne VMware + vStorageAPI,

Serwery poczty elektronicznej Exim

Serwery pocztowe z obsługą IMAP (Dovecop, UW IMAP, sendmail),

Komunikatory Aplikacyjne WASKO CMax (serwer, klient),

Klastrowe systemy plików tj. OCFS2,

Oprogramowania sterujące pracą PZŁ w OR (oprogramowania wbudowane komponentów
Serwera Komunikacyjnego, oprogramowanie konsoli dyspozytorskiej, aplikacja NetCRR
Centrum, oprogramowanie taryfikacyjne, oprogramowanie serwera radiowego),

Oprogramowania do synchronizacji nagrań rozmów SynchronDGT,

Oprogramowania SZ-DGT zainstalowane w OK,

Oprogramowania SUD (Moduł Statystyki Długości Kolejek) instalowane w OK,

Biblioteki narzędziowe .NET,

Oprogramowania narzędziowe do
urządzeń infrastruktury technicznej,

Oprogramowania do tworzenia raportów Microsoft SQL Server 2008 R2 Report Builder 3.0.
4.3
EnterpriseDB (PostgreSQL),
zarządzania
infrastrukturą
techniczną,
sterowniki
SWD PRM
System Wspomagania Dowodzenia Państwowego Ratownictwa Medycznego (SWD PRM)
stanowi jeden z produktów SI PR. SWD PRM ma za zadanie zoptymalizować proces zarządzania
siłami i środkami ratowniczym na terenie obsługiwanym przez Dyspozytorów. Szczegółowy opis
architektury SWD PRM, znajduje się w dokumentacji stanowiącej Załącznik nr 2 do OPZ. SWD PRM
jest jednocześnie Systemem Zewnętrznym dla SONA.
4.4
OST112
Projekt OST 112 dostarcza platformę komunikacyjną służącą do obsługi wywołań na numer
alarmowy 112 i inne numery alarmowe oraz komunikacji pomiędzy służbami odpowiedzialnymi za
ratownictwo i bezpieczeństwo publiczne. OST 112 stanowi bazę w postaci infrastruktury
teleinformatycznej m.in. dla Systemu Informatycznego Powiadamiania Ratunkowego (SI PR),
realizującego przyjmowanie i obsługę wywołań alarmowych, dla funkcjonowania służb ratownictwa
S t r o n a | 11
oraz porządku publicznego. Sieć telekomunikacyjna OST-112 została dostarczona w ramach
oddzielnego postępowania i nie podlega rozbudowie w ramach tego zamówienia. Zamawiający
wymagana natomiast dostarczenia wszelkich niezbędnych urządzeń sieciowych dla
potrzeb poprawnego funkcjonowania SONA.
4.5
Systemy Zewnętrzne
Inne systemy, z którymi ma za zadanie współpracować SONA w ramach obsługi Zgłoszeń.
5
PROJEKTOWANA ARCHITEKTURA ROZWIĄZANIA
Zamawiający wymaga rozbudowy będącego w jego dyspozycji systemu SI WCPR do
poziomu SONA oraz rozbudowy SWD PRM. Powyższe wiążę się z doposażeniem istniejącej
infrastruktury SI WCPR oraz SWD PRM w Oprogramowanie i Urządzenia. Zamawiający dopuszcza
modernizację lub całkowitą zmianę infrastruktury SI WCPR, w przypadku jeżeli Wykonawca
stwierdzi taką konieczność, tym niemniej wymaga wykorzystania aktualnej architektury SI WCPR w
infrastrukturze Systemu.
Modernizacja nie może przerwać ani negatywnie wpłynąć na aktualnie
świadczone usługi i funkcjonalności SI WCPR oraz SWD PRM. W ramach niniejszego zamówienia
Wykonawca dostarczy Urządzenia oraz Oprogramowanie, przeprowadzi instalację, konfiguracje oraz
uruchomi:
1. ZOK zapewniający redundancję dla POK– W obecnej architekturze SI WCPR istnieje
pojedyncze centrum serwerowe (POK). Zamawiający wymaga dostarczenia oraz
uruchomienia drugiego ośrodka krajowego dla SONA zwanego ZOK, funkcjonującego w
modelu ‘aktywny-aktywny’ w stosunku do POK. Wykonawca musi opracować sposób
funkcjonowania POK i ZOK, tak aby Użytkownicy zostali rozdysponowani pomiędzy te
ośrodki, w sposób optymalnie wykorzystujący dostępne zasoby informatyczne, moc
obliczeniową oraz infrastrukturę komunikacyjną sieci WAN, co zostanie opisane w
ramach Projektu Technicznego.
2. Dodatkowe Funkcjonalności i rozbudowa SWD PRM:
a) rozwiązanie tworzenia kopii zapasowych (backup) SONA i SWD PRM,
b) zwiększenie wydajności SONA,
c) system archiwizacji SONA,
d) rozbudowę systemu archiwizacji SWD PRM,
e) system monitorowania SONA i SWD PRM,
f)
rozbudowa SONA o środowisko szkoleniowe (SZK SONA),
g) budowa oraz rozbudowa interfejsów do systemów zewnętrznych,
h) rozbudowa SONA o środowisko pre-produkcyjne (PREP SONA)
S t r o n a | 12
i)
Rozbudowa SONA o środowisko developerskie (DEV SONA).
Wykonawca dostarczy Urządzenia i Oprogramowanie w ilości umożliwiającej realizację
przedmiotu zamówienia, a także dokona prac integracyjnych, co oznacza przede wszystkim
doposażenie sprzętowo-programowe oraz prace rekonfiguracyjne SI WCPR.
Punkt
L.P.
Opis działania
referencyjny w
Tabela w OPZ
OPZ
1
Redundacja dla POK i ZOK.
5.1
Tabela 1
2
Dodatkowe Funkcjonalności:
5.2
n.d.
a)
rozwiązanie tworzenia kopii
zapasowych (backup) SONA i
SWD PRM,
5.2.1
Tabela 2
b)
zwiększenie wydajności do
poziomu SONA,
5.2.2
Tabela 3
c)
System archiwizacji SONA
5.2.3
Tabela 4
d)
rozbudowa systemu
archiwizacji SWD PRM,
5.2.4
Tabela 5
e)
system monitorowania SONA i
SWD PRM,
5.2.5
Tabela 6
f)
rozbudowa SONA o środowisko
szkoleniowe (SZK SONA).
5.2.6
Tabela 7
g)
budowa
oraz
interfejsów
do
zewnętrznych,
5.2.7
Tabela 8
h)
rozbudowa SONA o środowisko
pre-produkcyjne (PRE SONA),
5.2.8
Tabela 9
i)
Rozbudowa SONA o środowisko
developerskie (DEV SONA).
5.2.9
Tabela 10
Zamawiający ponadto
dyspozycji
Zamawiającego,
rozbudowa
systemów
wymaga
w
tym
maksymalnego wykorzystania zasobów będących w
w
szczególności
infrastruktury
teleinformatycznej,
Oprogramowania, medium transmisyjnych.
Wykonawca dostarczy również niezbędne do realizacji zamówienia szafy rackowe 42U 19”,
wyposażone w dedykowane listwy zasilające oraz miedziane i światłowodowe kable połączeniowe
i inne niezbędne wyposażenie montażowe. Ilość szaf rackowych oraz ich wyposażenie, o których
mowa w zdaniu powyżej, musi umożliwiać przeprowadzenie poprawnej instalacji oraz uruchomienia
Urządzeń będących przedmiotem niniejszego zamówienia, a także musi umożliwiać montaż
przedmiotowych szaf. Określenie liczby sztuk szaf rackowych, o których mowa w zdaniu powyżej,
S t r o n a | 13
zostanie doprecyzowane na etapie Projektu Technicznego. W Lokalizacjach, gdzie jest to możliwe,
Wykonawca wykorzysta miejsce w istniejących szafach rack, wskazanych przez Zamawiającego, nie
dostarczając nowych szaf rackowych.
Zamawiający
zapewni
miejsce
w
serwerowni
o
następujących
parametrach
środowiskowych:

temperatury w zakresie 0-40o C,

oraz wilgotności w zakresie 20-85%.
Zamawiający informuje, że brama dostępowa CSD, CP SCPR, stanowiska oraz konsole
operatorskie, ani też aplikacja AD SWD nie podlegają rozbudowie w ramach Dodatkowych
Funkcjonalności tego zamówienia.
5.1
Wymagania minimalne dla redundancji POK i ZOK.
Wymaganiem Zamawiającego jest dostarczenie rozwiązania zabezpieczającego dla POK
pozwalającego
na
zapewnienie
ciągłej
dostępności
usług
niezbędnych
do
prawidłowego
przyjmowania i obsługi zgłoszeń alarmowych w warunkach błędu Urządzeń, Oprogramowania lub
infrastruktury technicznej POK. Wymagane jest, aby mechanizm zabezpieczał m.in. przed brakiem
dostępności usług POK w przypadku błędu dostępu do sieci OST112 obsługującego węzeł POK oraz
w przypadku błędu pojedynczej trasy w sieci łączącej węzły systemu oraz
łączące SONA z
punktami styku z zewnętrznymi systemami informatycznymi.
Wymagane jest, aby rozwiązanie zabezpieczające posiadało mechanizmy synchronizacji
wszystkich niezbędnych i zalecanych przez Wykonawcę danych i informacji (w tym baz danych w
węzłach
POK
i
ZOK,
Oprogramowania)
w
celu
spełnienia
zdefiniowanych
parametrów
niezawodności, pojemności i wydajności działania, odpowiednio do przedstawionej specyfikacji dla
trybu pracy normalnej i w stanie błędu.
Na potrzebę budowy ZOK Zamawiający, zapewni pomieszczenia serwerowni posiadające
odpowiednie warunki techniczne takie jak metraż, nośność stropów, zasilanie gwarantowane,
klimatyzację oraz dostęp do sieci OST 112, o wymaganych parametrach w zakresie przepustowości
oraz obejściowych dróg komunikacji.
Tabela 1 wymagania na redundantny Ośrodek Regionalny (ZOK)
Kod
wymagania
Opis funkcjonalności
WOKR.1
Wykonawca dostarczy, skonfiguruje i uruchomi Zapasowy Ośrodek Krajowy
(ZOK), w Lokalizacji. Rozwiązanie będzie tworzyć geograficzny klaster
niezawodnościowy dla POK.
WOKR.2
Wykonawca dokona integracji ZOK w środowisku SI WCPR.
WOKR.3
Architektura ZOK musi być zgodna z istniejącym rozwiązaniem architektonicznym
POK, który jest w dyspozycji Zamawiającego, w szczególności w zakresie
platformy sprzętowej, komunikacji sieciowej (dostarczanie usług, interfejsy) oraz
Oprogramowania.
WOKR.3.1
W przypadku braku możliwości zastosowania w ZOK poziomu identyczności
poszczególnych elementów z architektury POK, Wykonawca przedstawi do
akceptacji Zamawiającego zamienniki, charakteryzujące się parametrami nie
S t r o n a | 14
gorszymi, jak pierwowzory zastosowane w POK. W szczególnym przypadku gdy
brak możliwości zastosowania będzie dotyczył Oprogramowania, Wykonawca
przedstawi Zamawiającemu propozycję wdrożenia nowego rozwiązania globalnego
dla SI WCPR, które będzie spełniać w SI WCPR co najmniej tę samą
funkcjonalności co pierwowzór.
WOKR.4
Wykonawca opracuje i wdroży dla SONA rozwiązanie pracy POK i ZOK w trybie
‘aktywny-aktywny’, wraz z synchronizacją wszystkich niezbędnych i zalecanych
przez Wykonawcę danych i informacji (w tym baz danych w węzłach POK i ZOK,
Oprogramowania) w czasie rzeczywistym i z zachowaniem konsystencji całości
rozwiązania dostarczanego w ramach niniejszej Umowy. Ponadto Wykonawca
musi opracować i wdrożyć analogiczny niezależny interfejs asynchroniczny.
WOKR.4.1
Infrastruktura ZOK będzie tworzyć klaster niezawodnościowy względem POK,
zapewniający równoważenie obciążenia usług świadczonych przez Ośrodki
Krajowe. Wykonawca zaproponuje rozwiązanie dla zrównoważenia obciążenia
pomiędzy POK i ZOK.
WOKR.4.2
Dla usług, dla których realizacja w oparciu o infrastrukturę wykorzystującą
równoważenie obciążenia pomiędzy POK i ZOK jest niemożliwa lub nieefektywna,
Wykonawca przedstawi do akceptacji Zamawiającego zaprojektowane przez niego
rozwiązanie, umożliwiające wdrożenie strategii przełączania POK i ZOK.
WOKR.4.3
Musi zostać zastosowany mechanizm umożliwiający zapewnienie ciągłości obsługi
w przypadku niedostępności komponentów sprzętowych i aplikacyjnych w POK i
ZOK, wynikających z błędu lub konieczności przeprowadzenia operacji
administracyjnych. W ramach niniejszego rozumiane jest również manualnie
inicjowane przełączanie między Ośrodkami Krajowymi (w tym wstrzymanie pracy
wybranych komponentów OK oraz wznawianie wybranych funkcjonalności).
WOKR.4.4
Wykonawca wdroży mechanizm umożliwiający samodzielne działanie POK lub ZOK
w przypadku niedostępności części (w tym jednego) OK.
WOKR.4.5
Rozwiązanie redundancji POK i ZOK musi zabezpieczać ciągłość dostępności usług
dla POK SI WCPR w następujących przypadkach:

uszkodzenie komponentu zapewniającego daną usługę w POK przy
sprawnym działaniu analogicznego komponentu w zapasowym ZOK,

całkowite uszkodzenie, zniszczenie lub wyłączenie całej infrastruktury
POK, w warunkach poprawnego działania infrastruktury ZOK,

uszkodzenie komponentu infrastruktury dostępu do sieci OST 112 POK lub
uszkodzenie podstawowej trasy komunikacji w sieci OST112 łączącej ten
POK z Ośrodkami Regionalnymi lub punktami styku systemów
zewnętrznych (PLI CBD, CP SCPR, brzegowy serwer poczty) przy istnieniu
drogi obejściowej z ZOK,

uszkodzenie komponentu infrastruktury węzła dostępowego OST 112 dla
POK lub brak łączności na wszystkich gałęziach sieci łączących POK z
punktami styku z systemami zewnętrznymi w warunkach poprawnego
działania infrastruktury zapasowego ZOK oraz dostępności minimum
jednej trasy sieciowej połączenia dla każdego z punktów styku systemów
zewnętrznych.
WOKR.4.5.1
Analogicznie jak w WOKR.4.5 dla ZOK.
WOKR.4.6
Rozwiązanie, o którym mowa w WOKR.4, musi zapewniać stałą, automatyczną
synchronizację co najmniej następujących zbiorów danych pomiędzy węzłami POK
i ZOK:

dane słownikowe i dane robocze niezbędne w procesach przyjmowania i
S t r o n a | 15
obsługi zgłoszeń,

treść arkuszy przyjęcia zgłoszenia oraz arkuszy obsługi zdarzenia,

historia operacji użytkownika oraz historia zmian w treści zgłoszeń i
zdarzeń (w tym operacji realizowanych przez SWD),

treść zgłoszeń przychodzących i korespondencji wychodzącej (nagrania
rozmów, treść zgłoszeń bezgłosowych, powiadomienia dla zgłaszających),

historia
operacji
telekomunikacyjny,

dane konfiguracyjne systemu,

dane kont użytkowników systemu,

dane centrum certyfikacji (klucze, certyfikaty, listy odwołań certyfikaty).
telekomunikacyjnych
PZŁ,
w
tym
biling
WOKR.4.7
Synchronizacja zbiorów danych musi zapewniać możliwość przełączenia usługi z
POK na ZOK, z ZOK na POK oraz tryb mieszany (w przypadku krzyżowych błędów
komponentów systemu) bez przerwania transakcji biznesowej. W przypadku
operacji dotyczącej obsługi przyjęcia zgłoszenia realizowanej na żądanie
użytkownika SI WCPR konieczne jest zapewnienie informacji o wystąpieniu
przełączenia awaryjnego i możliwości ponowienia operacji. W przypadku działań
automatycznych systemu konieczne jest zapewnienie mechanizmów
kontynuowania transakcji od momentu przerwania na skutek wystąpienia błędu.
WOKR.4.8
Synchronizacja wszystkich niezbędnych i zalecanych przez Wykonawcę danych i
informacji (w tym baz danych w węzłach POK i ZOK, Oprogramowania) w węzłach
POK i ZOK musi być realizowana, w zależności od rodzaju danych, co najmniej z
następującą rozdzielczością:
 transakcji bazy danych dla:
o dane słownikowe, dane robocze niezbędne w procesach
przyjmowania i obsługi zgłoszeń,
o treść arkuszy przyjęcia zgłoszenia oraz arkuszy obsługi zdarzenia,
o historia operacji użytkownika oraz historia zmian w treści zgłoszeń
i zdarzeń (w tym operacji realizowanych przez SWD),
o historia zdarzeń telekomunikacyjnych PZŁ, biling
telekomunikacyjny,
 pojedynczego zrealizowanego zgłoszenia dla:
o treść zgłoszeń przychodzących i korespondencji wychodzącej
(nagrania rozmów, treść zgłoszeń bezgłosowych, powiadomienia
dla zgłaszających),
 pojedynczej operacji konfiguracyjnej dla:
o dane konfiguracyjne systemu,
o dane kont użytkowników systemu,
dane centrum certyfikacji (klucze, certyfikaty, listy odwołań certyfikatu).
WOKR.4.9
Przełączenie dowolnej z usług pomiędzy węzłami POK i ZOK nie może powodować
przerwania lub zakłócenia operacji telekomunikacyjnej, będących w trakcie
realizacji w momencie wystąpienia błędu skutkującej przełączeniem dowolnej z
usług pomiędzy POK i ZOK.
WOKR.4.10
Po przywróceniu działania dowolnego Ośrodka Krajowego,(POK lub ZOK) w
którym wcześniej wystąpił błąd, mechanizm synchronizacji danych i informacji
musi uzupełnić dane i informacje, w szczególności biznesowe oraz konfiguracyjne,
S t r o n a | 16
w Ośrodku Krajowym przywróconym, do stanu aktualnego.
WOKR.4.11
Po przywróceniu synchronizacji danych i informacji pomiędzy POK i ZOK, proces
ten musi wymusić na przywróconym do działania OK (POK lub ZOK) automatyczne
uruchomienie usług świadczonych przez SONA, z możliwością przeprowadzenia tej
procedury również w sposób ręczny.
WOKR.5
Wykonawca przedstawi do akceptacji Zamawiającego dokument ‘Projekt
rozwiązania pracy Ośrodków Krajowych w trybie aktywny-aktywny’, zawierający
co najmniej:

Opis spełnienia wymagań redundancji dla Ośrodków Krajowych,

Niezbędny zakres rekonfiguracji SI WCPR,

Niezbędny zakres prac instalacyjnych oraz konfiguracyjnych ZOK,

Listę dodatkowych urządzeń, podzespołów oraz akcesoriów, zawierających
typ i model oraz opis zastosowania niniejszego elementu,

Opis prac wdrożeniowych,
niezbędnych do wdrożenia i uruchomienia rozwiązania, o którym mowa w
WOKR.04.
WOKR.6
Wykonawca przeprowadzi niezbędne prace po stronie POK i ZOK oraz środowiska
SI WCPR, w celu uruchomienia rozwiązania redundancji Ośrodków Krajowych.
WOKR.7
Wszystkie mechanizmy, procesy oraz funkcjonalności związane z przywróceniem
działania do pełnej funkcjonalności SONA, nie mogą powodować przerw ani
zakłóceń działania w bieżącej pracy SONA (w tym usług i funkcjonalności).
5.2
Wymagania minimalne na Dodatkowe Funkcjonalności oraz rozbudowę
SWD PRM
5.2.1
rozwiązanie tworzenia kopii bezpieczeństwa (tzw. backup) SONA i SWD PRM
Zamawiający wymaga realizacji systemy tworzenia i odtwarzania kopii bezpieczeństwa dla
SONA a także dla SWD PRM. Przedstawione w tym dziale informacje maja wspólną podstawę
funkcjonowania.
Systemy backup’u muszą chronić wszystkie dane niezbędne i zalecane przez Wykonawcę
dane i informacje ( w tym dane i informacje wykorzystywane przez aplikacje użytkowane w SONA a
także SWD PRM). Niniejsze rozwiązanie musi uwzględniać zakup, dostawę i wdrożenie modułu
podsystemu kopii zapasowych dla SONA i SWD PRM, każdy zbudowane w oparciu o dedykowany
serwer backupu oraz bibliotekę taśmową. W ramach rozwiązania dla SONA i SWD PRM biblioteka
taśmowa musi być wyposażona w minimum 2 napędy taśmowe LTO podłączone do serwera
backupu poprzez sieć SAN. Dodatkowo dla serwera backupu musi zostać udostępniona przestrzeń z
macierzy dyskowej, celem wykonywania kopii D2D2T (ang. Disk to Disk to Tape).
Wymagane jest, aby na serwerze backupu zainstalowane zostało oprogramowane do
wykonywania kopii zapasowych, odpowiadające za wykonywanie backupu. Oprogramowanie to
musi wykonywać kopie wszystkich niezbędnych i zalecanych przez Wykonawcę danych i informacji
(w tym systemów operacyjnych, baz danych) online tzn. bez zatrzymywania oprogramowania,
którego kopia jest wykonywana. Dane do serwera backupu muszą być przesyłane po sieci LAN oraz
S t r o n a | 17
SAN. Kopie pełne muszą być składowane w pierwszej kolejności na macierzy dyskowej (pierwszy
poziom), a następnie okresowo przenoszone na bibliotekę taśmową (drugi poziom). Wymagane jest
umożliwienie optymalnego wykonywanie backupu i odtwarzania z wykorzystaniem dysków oraz
przechowywanie starszych danych na tańszych nośnikach taśmowych. Wymagane jest również
optymalne wykorzystanie napędów taśmowych, poprzez wykorzystanie macierzy dyskowej do
przechowywania danych, szczególnie w przypadku małych backupów przyrostowych. Wymagane
jest, aby dostęp do większości danych i rozpoczęcie odtwarzania następowało natychmiast, bez
potrzeby ładowania taśm do napędu oraz przewijania do miejsca, gdzie znajdują się wymagane do
odtworzenia dane. Wymagane jest, aby backup danych składowany był w dwóch kopiach: na
dyskach macierzy dyskowej oraz na taśmach biblioteki taśmowej. W tym celu system backupu
powinien wykonywać kopię danych z macierzy na taśmy w chwili gdy nie będzie wykonywał kopii
zapasowych. Wymagane jest, aby w momencie tworzenia nowej kopii danych, jeśli zabraknie
miejsca na macierzy, oprogramowanie do wykonywania kopii zapasowych będzie archiwizowało
najstarsze dane a następnie je usuwało z dysków zwalniając miejsce na nowe. System backupu
musi zapewniać ochronę danych w obu systemach, SONA i SWD PRM.
Proces backupu musi umożliwiać prowadzenie backupu zarówno w sposób automatyczny
dla całego jak i części środowiska SONA/SWD PRM, z możliwością wyboru poszczególnych
elementów do stworzenia kopii zapasowych z zachowaniem niezbędnych punktów spójności
(konsystencji)
danego
środowiska.
Przywracanie
systemu
z
utworzonych
uprzednio
kopii
zapasowych musi odbywać się w analogiczny sposób – całościowo dla danego środowiska
SONA/SWD PRM, bądź wybiórczo dla poszczególnych elementów składowych.
Projekt systemu backup’u musi umożliwiać rozbudowę środowiska poprzez objęcie ochroną
systemów aplikacyjnych w SONA i SWD PRM.
Poniżej przedstawione wymagania dotyczą rozwiązania tworzenia kopii bezpieczeństwa i
sposobu przywracania na ich podstawie systemu dla SONA oraz SWD PRM.
W
ramach
niniejszego,
Zamawiający
wymaga
dostarczenia
dwóch
niezależnych
funkcjonujących rozwiązań dla środowisk SONA i SWD PRM.
Tabela 2 Wymagania minimalne na rozwiązanie tworzenia kopii bezpieczeństwa (tzw.
backup) SONA i SWD PRM.
Kod
wymagania
Opis funkcjonalności
WB.1
Wykonawca opracuje mechanizm tworzenia automatycznych kopii zapasowych
(Backup) wszystkich niezbędnych i zalecanych przez Wykonawcę danych i
informacji ( w tym serwerów fizycznych, maszyn witualnych oraz baz danych
SONA oraz niezależnie SWD PRM), które mają służyć do odtworzenia
oryginalnych danych w przypadku ich utraty lub uszkodzenia, szczególnie:
WB.1.1

Backup bazy danych online - Oprogramowanie backupowe musi posiadać
mechanizmy np. w postaci agentów do wykonywania kopii baz danych
online. Wykonawca musi uwzględnić, że Zamawiający może posiadać
różne typy bazy danych. Oprogramowanie musi być na tyle elastyczne,
żeby umożliwiać backup bazy nawet w przypadku, gdy Zamawiający
zmieni typ bazy danych. Zamawiający musi mieć możliwość dokupienia
odpowiednich licencji w przyszłości;
S t r o n a | 18
WB.1.2

Backup serwerów fizycznych - Oprogramowanie backupowe musi wspierać
dowolny system operacyjny, będący w dyspozycji Zamawiającego w
ramach SI WCPR z rodziny: MS Windows, Linux, Unix, ESXi;
WB.1.3

Backup maszyn wirtualnych - Backup maszyn wirtualnych musi się
odbywać z wykorzystaniem zestawu bibliotek dla backup VMware –
vStorageAPI. Umożliwia to wykonanie pełnego lub przyrostowego
backupu dowolnej maszyny, z wykorzystaniem mechanizmu kopii
migawkowej na macierzy - tzw. LAN-Free backup bezpośrednio na
bibliotekę taśmową. Backup maszyn musi być w punkcie konsystencji z
odpowiadającym mu systemem wirtualizacyjnym umożliwiającym ich
skuteczne odtworzenie (prawidłowe uruchomienie wszystkich usług);
WB.1.4

Backup archiwum HCP – (zasób WORM) dla SI WCPR rekomendowane jest
postawienie w ZOK drugiego archiwum i uruchomienie replikacji na
zestawionym połączeniu sieciowym między POK i ZOK;
WB.1.5
Wymagane zastosowanie oprogramowanie dedykowanego do backupu urządzeń
typu kontent archive.
WB.1.6
Dostarczone rozwiązanie musi posiadać funkcjonalność inteligentnej selekcji
zasobów kwalifikujących się do wykonania kopii bezpieczeństwa (m.in. na
podstawie daty ostatniej modyfikacji plików, sumy kontrolnej, ilości wykonanych
kopii od ostatniej zmiany).
WB.2.1
Rozwiązanie będzie obsługiwało nośniki dyskowe oraz taśmowe, służące do
przechowywania zapasowych kopii bezpieczeństwa i archiwizacji danych.
WB.2.2
Wykonawca dostarczy stosowane w rozwiązaniu nośniki danych w ilości
umożliwiającej przeprowadzenie trzykrotnego, kompletnego backupu SONA i SWD
PRM (w tym archiwów).
WB.3
Proces tworzenia kopii zapasowych musi być możliwy do uruchomienia oraz
obsługi z dowolnego Ośrodka Krajowego lub OK SWD PRM.
WB.3.1
Rozwiązanie musi umożliwiać automatyczne tworzenie kopii bezpieczeństwa SONA
i SWD PRM o ustalonej porze dnia, a także możliwość inicjowania kopii
bezpieczeństwa poszczególnych elementów SONA i SWD PRM.
WB.4
W ramach SONA możliwość odtwarzania Microsoft Active Directory będącego w
dyspozycji Zamawiającego na poziomie pojedynczych elementów (np. OU czy
pojedynczy atrybut) bez konieczności restartowania kontrolerów domeny, backup
wykonywany będzie jednoprzebiegowo, natomiast odtwarzanie będzie na
podstawie całego Active Directory albo pojedynczych elementów.
WB.4.1
W ramach SWD PRM możliwość odtwarzania Kerberos lub LDAP na poziomie
pojedynczych elementów (pojedynczy atrybut) bez konieczności restartowania
funkcjonalności kontrolerów domeny (SAMBA), backup wykonywany będzie
jednoprzebiegowo, natomiast odtwarzanie będzie na podstawie całego Kerberos
lub LDAP albo pojedynczych elementów.
WB.5
Możliwość tworzenia stopniowych, przyrostowych kopii zapasowych w zadanym
cyklu.
WB.6
Możliwość wykonywania backupu z wykorzystaniem mechanizmów kopii
migawkowych umożliwiających odtworzenie SONA i SWD PRM (w tym jeżeli
zajdzie taka potrzeba również jego poszczególnych komponentów niezależnie od
innych komponentów) do konsystentnego punktu w czasie .
WB.7
Możliwość tworzenia kopii zapasowych baz danych przy pomocy mechanizmów (w
tym agenta), online bez zatrzymywanie bazy dla następujących baz będących w
dyspozycji Zamawiającego.
S t r o n a | 19
WB.9
Możliwość tworzenia oraz odtwarzania kopii zapasowych z wykorzystaniem
struktury sieciowej SAN (Storage Area Network) – dane przesyłane do serwera
backupu z ominięciem sieci LAN.
WB.10
Możliwość odtwarzania wybranych danych w dowolne wskazane miejsce dyskowe.
WB.11
Możliwość multipleksowania zapisów – jednoczesny zapisu na jeden napęd z kilku
klientów/serwerów. Funkcjonalność ta musi być dostępna bez pośrednictwa
dysków oraz za pośrednictwem dysków w formie bufora (np. dla kopii
migawkowych), to znaczy serwer backupowy zapisuje multipleksowane dane
bezpośrednio na napędy taśmowe.
WB.12
Możliwość wykonywania backupu wieloma równoległymi strumieniami –
multistreaming. Funkcjonalność ta musi być dostępna bez pośrednictwa dysków
oraz za pośrednictwem dysków w formie bufora (np. dla kopii migawkowych), to
znaczy serwer backupowy zapisuje dane bezpośrednio na napędy taśmowe
WB.13
Wykonawca przedstawi do akceptacji Zamawiającego dokument ‘Projekt
rozwiązania dla mechanizmu kopii zapasowych SONA, zawierający co najmniej:

Opis
spełnienia
wymagania
dla
rozwiązania
tworzenia
kopii
bezpieczeństwa (tzw. backup) SONA.

Niezbędny zakres rekonfiguracji SI WCPR, SWD PRM,

Niezbędny zakres
Krajowych,

Listę Urządzeń i Oprogramowania, podzespołów
zawierających typ i model oraz opis zastosowania,

Opis prac wdrożeniowych,
prac
instalacyjnych
i
konfiguracyjnych
oraz
Ośrodków
akcesoriów,
niezbędnych do uruchomienia mechanizmu tworzenia kopii zapasowej SONA i
SWD PRM.
WB.14
Wykonawca wdroży i uruchomi niezależne rozwiązania dla mechanizmu kopii
zapasowych SONA i SWD PRM w tych środowiskach.
WB.15
Wykonawca na potrzeby wymagań, o których mowa w tej Tabeli (nr 2):
WB.16

dostarczy rozwiązanie dla SONA i SWD PRM,

rozbuduje istniejące rozwiązanie backupów w SWD PRM, poprzez
maksymalne wykorzystanie będących w dyspozycji Zamawiającego
elementów infrastruktury SWD PRM,

dokona pełnej i zalecanej konfiguracji do wykonania jednego pełnego
backupu SONA i SWD PRM,

dokona pełnego backupu i odtworzenia całości SONA i SWD PRM,
System backupu musi zostać dostarczony wraz z całą niezbędną dla prawidłowej
jego pracy infrastrukturą w tym niezbędne Urządzenia i Oprogramowanie.
Ponadto do systemu backupu muszą zostać dołączone wymagania sprzętowoprogramowe.
S t r o n a | 20
5.2.2
zwiększenie wydajności SONA
Wykonawca zobowiązany jest do doposażenia istniejącej infrastruktury SI WCPR w taki
sposób, aby w ramach SONA stworzone zostało środowisko umożliwiające obsługę minimum 100
milionów Zgłoszeń rocznie, czyli umożliwiającego pokrycie przez każdy WCPR zasięgiem obszaru
całego województwa, które obsługuje oraz funkcjonowanie SONA skali ogólnokrajowej. Określona
w poprzednim zdaniu wydajność musi być do zrealizowania w ramach działającego jednocześnie
POK i ZOK. Natomiast w przypadku pojedynczo działającego ośrodka, POK albo ZOK, będzie on
umożliwiał obsługę minimum 50 mln zgłoszeń w SONA, przy jednoczesnym zachowaniu SLA, który
został wskazany w pkt. 10 tego dokumentu. Każdy z ośrodków, POK i ZOK, musi dysponować
zestawem Urządzeń i Oprogramowania umożliwiającym świadczenie usług niezależnie od pozostałej
lokalizacji oraz dostępności połączeń pomiędzy nimi.
Tabela 3 minimalne wymagania na zwiększenie wydajności SI WCPR do poziomu SONA
Kod
Opis wymagania
wymagania
WYD.01
Wykonawca dokona rozbudowy środowiska SI WCPR do poziomu SONA, w
szczególności dostarczając niezbędne do tego Urządzenia i Oprogramowanie oraz
przeprowadzi prace instalatorskie i konfiguracyjne dostarczanych Urządzeń i
Oprogramowania a także ich adaptację w SI WCPR oraz rekonfigurację tego
środowiska.
WYD.01.1
Rozbudowany SI WCPR do poziomu SONA, będzie udostępniał funkcjonalność
obsługi co najmniej 100 milionów zgłoszeń liczonych jako mediana w skali roku.
WYD.01.2
Każdy z Ośrodków Krajowych, POK i ZOK, pracując pojedynczo będzie dysponował
wydajnością do obsługi minimum 50 milionów zgłoszeń, liczonych jako mediana w
skali roku.
WYD.01.3
Każdy z Ośrodków Krajowych będzie w stanie obsłużyć zgłoszenia przyjmowane za
pośrednictwem FAX, SMS, email w ilości minimum 5 milionów liczonej jako
mediana w skali roku.
WYD.03
Każdy z Ośrodków Krajowych będzie uwzględniał dziesięciokrotny wzrost ilości
przyjmowanych zgłoszeń w szczycie, w stosunku do średniej ilości, czyli będzie
umożliwiał obsługę minimum 1 370 000 zgłoszeń w ciągu doby.
WYD.04
SONA będzie umożliwiał funkcjonowanie 381 jednoczesnych użytkowników tego
systemu obsługujących Zgłoszenia.
WYD.04.1
Zamawiający informuje, iż w wymaganej liczbie użytkowników nie są uwzględnieni
użytkownicy SWD PRM korzystający ze wspólnych komponentów tj. PZŁ.
WYD.05
Zamawiający wymaga aby w ramach SONA, każdy WCPR posiadał infrastrukturę
zdolną do dołączenia łączy telekomunikacyjnych (PRA) w ilości umożliwiającej
przyjęcie oraz obsługę jednocześnie 131 Zgłoszeń.
WYD.06
Każdy z Ośrodków Krajowych będzie dysponował zasobami w postaci 10%
nadwyżki mocy obliczeniowej i wydajności. Wykonawca jest zobowiązany do
wykazania wymaganej nadwyżki mocy (zarówno dla ilości zgłoszeń jak i
jednoczesnych użytkowników) podczas testów wydajnościowych lub
przeciążeniowych.
WYD.07
Całość dostarczonego Oprogramowania w celu realizacji wymagań funkcjonalnych,
w szczególności interfejs GUI Operatora, logika biznesowa, musi być dostarczona
w ramach Oprogramowania Aplikacyjnego. Zamawiający dopuszcza zastosowanie
Oprogramowania Standardowego w poniższych obszarach:
S t r o n a | 21






system operacyjny,
serwer aplikacyjny,
oprogramowanie bazodanowe,
oprogramowanie do tworzenia raportów,
oprogramowanie do tworzenia kopii bezpieczeństwa,
komunikator (np. oparty o protokół XMPP),
Zamawiający dopuszcza zastosowanie Oprogramowania Standardowego również w
innych obszarach , co może zostać ustalone na etapie Projektu Technicznego.
5.2.3
system archiwizacji SONA
W
ramach
istniejącego
rozwiązania
archiwizacji
SI
WCPR,
Zamawiający
wymaga
dostarczenia rozwiązania eksportu archiwizowanych danych na nośniki zewnętrzne.
Tabela 4 minimalne wymagania na system archiwizacji SONA
Kod
Opis wymagania
wymagania
WARCHS.1
Wykonawca ma dostarczyć Urządzenia i Oprogramowanie niezbędne do archiwizacji
wszystkich niezbędnych i zalecanych przez Wykonawcę danych i informacji.
WARCHS.2
Wykonawca musi dostarczyć Oprogramowanie z interfejsem graficznym dla
Użytkownika umożliwiającego konfigurowanie i zarządzanie archiwami.
WARCHS.3
Wykonawca zapewni w rozwiązaniu możliwość eksportu archiwizowanych danych
na nośniki zewnętrzne, poprzez zastosowanie odpowiednich Urządzeń eksportu
danych na te nośniki.
5.2.4
rozbudowa systemu archiwizacji SWD PRM
Tabela 5 minimalne wymagania na rozbudowa systemu archiwizacji SWD PRM
Kod
Opis wymagania
wymagania
WAR.1
Wykonawca dostarczy Lokalizacji niezbędne Urządzenia i Oprogramowanie oraz
dokona rozbudowy zasobów SWD PRM do poziomu umożliwiającego
przechowywanie danych archiwalnych z okresu 20 lat oraz dostęp do tych danych w
trybie online, w zakresie dokumentacji medycznej PRM (aktualnie SWD PRM
zezwala na przechowywanie danych z okresu 5 lat).
Dokumentację medyczną PRM stanowią:
 Książka pracy Pogotowia Ratunkowego (KPPR),
 Karta zlecenia wyjazdu zespołu ratownictwa medycznego
(KZWZRM),
 Karta medycznych czynności ratunkowych (KMCR),
 Karta medyczna dla potrzeb LPR (KMLPR),
 Karta drogowa.
WAR.1.1
Zamawiający wymaga rozbudowania będącego w jego dyspozycji urządzenia
Storage Bridge Bay SuperMicro, o aktualnej pojemności dysków 2TB pracujących z
S t r o n a | 22
prędkością obrotową min. 7,2 tyś. RPM dedykowanych do OK SWD PRM, do
poziomu umożliwiającego obsługę min. 8 TB danych archiwalnych lub postąpi
analogicznie jak z WOKR.3.1.
WAR.2
5.2.5
Wykonawca dostarczy do Lokalizacji niezbędne Urządzenia i Oprogramowanie oraz
dokona
rozbudowy
zasobów
SWD
PRM
do
poziomu
umożliwiającego
przechowywanie danych archiwalnych w zakresie nagrań i pozostałych informacji
gromadzonych w SWD PRM z okresu 1 roku w systemie on-line oraz z okresu 20 lat
w systemie backupu. Wykonawca dostarczy infrastrukturę potrzebną do
przechowywania
danych
dot.
nagrań
oraz
infrastrukturę
serwerów
komunikacyjnych.
System monitorowania SONA i SWD PRM
Wymaganiem
Zamawiającego
jest
dostawa
i
wdrożenie
rozwiązania
posiadającego
funkcjonalność monitorowania opartego na centralnej relacyjnej bazie danych SQL jako np. miejsca
przechowywania próbek, z możliwością dostępu użytkowników poprzez interfejs graficzny. W skład
niniejszego rozwiązania wejdą co najmniej następujące funkcjonalności:
a) zbieranie informacji z całej infrastruktury teleinformatycznej SONA i SWD PRM oraz ich
przedstawianie w trybie czasu rzeczywistego.
b) grupowanie
wartości
parametrów
poprzez
dowolną
funkcję
arytmetyczną
oraz
możliwość zakładania progów alarmowych na wartościach zgrupowanych.
c)
zakładanie
progów
alarmowych
na
wybrane
parametry
infrastruktury
zarówno
liczbowych jak i tekstowych z możliwością powiadamiania o alarmach krytycznych
poprzez SMS , email i inne.
d) świadczenie archiwizacji oraz eksportu danych na nośniki zewnętrzne.
e) definiowanie obszarów podlegających monitorowaniu np. SONA, SWD PRM, Urządzenia
sieciowe, w tym dowolne definiowanie kategorii, trybu pobierania danych oraz ich
wizualizacji .
f)
filtrowanie prezentowanych informacji.
System
monitoringu
musi
dotyczyć
dwóch
zakresów:
funkcjonalnego
oraz
administracyjnego. W ramach monitoringu funkcjonalnego wymagane jest prowadzenie nadzoru
nad danymi użytecznymi z punktu widzenia
Użytkownika. System monitoringu musi umożliwiać
definiowanie filtrów na poziomie pojedynczego Użytkownika, dla co najmniej takich parametrów
jak: typ zdarzenia/zgłoszenia, służba podejmująca działania, status zgłoszenia/zdarzenia, poziom
wykorzystania słownika TERYT/EMUiA, priorytet zgłoszenia/zdarzenia, źródło zgłoszenia, ilość
zgłoszeń w danym regionie itd.
W ramach monitorowania administracyjnego, system monitorowania musi udostępniać
dane użyteczne dla utrzymania oraz wsparcia technicznego SONA i SWD PRM, minimum w zakresie
analizy stanu, wykorzystania zasobów sprzętowo-programowych oraz alarmów systemowych.
Monitoring administracyjny, o którym mowa powyżej, musi być uzupełnieniem do istniejącego
systemu nadzorującego SI WCPR lub SWD PRM.
S t r o n a | 23
Doprecyzowanie
kwestii
monitoringu
na
potrzeby
analiz
jakościowych
w
czasie
rzeczywistym nastąpi na poziomie Projektu Technicznego.
Tabela 6 wymagania minimalne na system monitorowania SONA
Kod
Opis wymagania
wymagania
SMON.1
System musi posiadać GUI umożliwiające prezentację stanu monitorowanych
elementów SONA i SWD PRM.
SMON.2
GUI musi umożliwiać pełną wizualizację zbieranych danych oraz wizualizacji danych
wyliczeniowych (danych będących wartościami wyliczanymi na podstawie innych
parametrów) graficznej, tabelarycznej oraz wykresów.
SMON.3
System
monitorowania
musi
wykonywać
akcje
sterujące
na
obiektach
infrastruktury teleinformatycznej, uruchamianych z poziomu schematu.
SMON.4
W systemie
monitorowania musi
istnieć możliwość prezentacji
i
tworzenia
schematów dowolnie zdefiniowanej i rozbudowanej infrastruktury IT dla całego
obszaru działania instytucji w formie zapewniającej swobodne stosowanie technik
skalowania bez straty jakości (wizualizacja na skalowalnych mapach wektorowych).
SMON.5
W systemie monitorowania musi istnieć możliwość prezentacji na schematach
wielkości charakteryzujących stan pracy obiektów infrastruktury (np.: stan pracy
normalny, stan awaryjny itp.)
SMON.6
W systemie monitorowania musi istnieć możliwość zapamiętywania ustawień jego
użytkownika, umożliwiając odtworzenie środowiska pracy użytkownika po jego
ponownym zalogowaniu do tego systemu;
SMON.7
System monitorowania musi posiadać rozbudowane narzędzia do zarządzania
zdarzeniami zaistniałymi w zarządzanym środowisku (dziennik zdarzeń, filtry
zdarzeń, korelacja zdarzeń)
SMON.8
Wszystkie alarmy i zdarzenia przychodzące z monitorowanych obiektów
muszą
być wizualizowane w dedykowanym module monitorowania w postaci listy
rekordów. Moduł monitorowania będzie zapewniać funkcjonalny podział alarmów i
zdarzeń na: pochodzące z przekroczeń progów ustawionych na poszczególnych
parametrach, pochodzące ze błędu pojawiających się w sposób losowy, tzw. trapy
SNMP.
SMON.9
System monitorowania będzie umożliwiać centralne definiowanie i wizualizacje
widoków/schematów użytkownikom o niższych uprawnieniach, bez możliwości ich
edycji.
SMON.10
System monitorowania musi mieć możliwość przeliczenia (wykonania operacji
arytmetycznej) na wartości odczytanej/ rzeczywistej.
SMON.11
System monitorowania musi zapewniać rozliczalność działań użytkowników modułu
monitorowania (patrz SMON.8) poprzez mechanizm dzienników aktywności.
SMON.12
System monitorowania będzie umożliwiać konfigurowanie parametrów, które będą
odczytywane i przechowywane w bazie. Ze względu na optymalizację przestrzeni
danych nie dopuszcza się rozwiązania pobierania wszystkich parametrów obiektu
S t r o n a | 24
infrastruktury teleinformatycznej a następnie filtrowanie ich w warstwie prezentacji.
SMON.13
System monitorowania będzie posiadać wbudowany protokół SNMP umożliwiający
monitorowanie urządzeń, które obsługują w/w protokół.
SMON.14
System monitorowania musi umożliwić powiadomienie użytkowników o wystąpienie
sytuacji alarmowej za pomocą emaila, komunikatu SMS oraz uruchomienia skryptu
systemowego (konfigurowalnego per zdarzenie) z odpowiednim komunikatem jako
parametr.
SMON.15
System monitorowania musi umożliwiać korzystanie z dedykowanych profili
definiujących konkretne typy urządzeń infrastruktury IT.
SMON.16
System monitorowania musi umożliwiać monitorowanie ciągłe zgodnie z ustalonym
harmonogramem lub na żądanie użytkownika.
SMON.17
System monitorowania musi zostać dostarczony wraz z całą niezbędną dla
prawidłowej
jego
pracy
infrastrukturą
w
tym
niezbędne
Urządzenia
i
Oprogramowanie. Ponadto do systemu monitorowania muszą zostać dołączone
wymagania sprzętowo-programowe.
SMON.18
System monitorowania musi posiadać możliwość docelowej obsługi przez min. 20
jednoczesnych użytkowników.
SMON.19
System monitorowania z uwagi na integralność całego rozwiązania musi pochodzić
od jednego producenta. Nie dopuszcza się oferowania systemu stanowiącego zbiór
zintegrowanych
podsystemów
różnych
producentów,
zarządzających
poszczególnymi elementami infrastruktury. Jedynym dopuszczalnym odstępstwem
są komponenty Oprogramowania Aplikacyjnego dostarczone przez Wykonawcę w
ramach niniejszego zlecenia.
SMON.20
Moduły
komunikacyjne
posadowione
na
węzłach
muszą
realizować
funkcje
zbierania danych z obiektów teleinformatycznych. Dane pobierane przez wszystkie
węzły
trafią
do
centralnej
bazy
danych.
System
monitorowania
będzie
przechowywać dane za okres minimum 3 lat oraz zapewniać możliwość dostępu do
dowolnego zakresu danych (w tym zarchiwizowanych) w zależności od przyznanych
uprawnień.
SMON.21
System
monitorowania
musi
mieć,
graficzny
interfejs
pozwalający
na
konfigurowanie i monitorowanie pracy wszystkich modułów aplikacji i komponentów
wchodzących w skład systemu.
SMON.22
System monitorowania musi
posiadać wbudowane mechanizmy kontroli i
stopniowania dostępu do zasobów i wykonywanych operacji. System ten będzie
umożliwiać tworzenie dowolnych profili dla użytkowników odpowiedzialnych za
wybrane
obszary
w
systemie
zarządzania
oraz
ograniczać,
na
równi
z
mechanizmami systemowymi, dostęp do wybranych zasobów i operacji.
SMON.23
Będzie posiadać możliwość docelowej obsługi minimum 1000 obiektów sieci
teleinformatycznej (routery, aplikacje, serwery, systemy operacyjne).
S t r o n a | 25
SMON.24
Wykonawca przeprowadzi analizę całości SONA oraz SWD PRM (i dostarczy ją w
osobnym dokumencie do akceptacji Zamawiającego) w celu określenia niezbędnych
i zalecanych parametrów, które należy monitorować.
SMON.25
Wykonawca przeprowadzi analizę zależności danych co najmniej z SMON.24 i
dostarczy
ją
w
wypracowanie
osobnym
zależności
dokumencie.
pomiędzy
Efektem
takiej
poszczególnymi
analizy
parametrami,
musi
być
określenie
nowych parametrów, które składają się z ww. zależności.
SMON.26
Wykonawca na podstawie co najmniej danych z SMON.24 i SMON.25 (i dostarczy
ją w osobnym dokumencie) wskaże progi ostrzegawcze oraz opisze w formie
procedur należyte zachowanie dla wystąpienia takiej sytuacji (w podziale na
Operatora
oraz
Administratora),
które
dodatkowo
pozwoli
na
rozwiązanie
incydentu.
SMON.27
W przypadku Oprogramowania Standardowego, Wykonawca dostarczy licencje
pozwalające
na
korzystanie
ze
wszystkich
niezbędnych
i
zalecanych
funkcjonalności. Ponadto dostarczona licencja nie może mieć ograniczeń czasowych
oraz ilościowych (w tym pod względem ilości monitorowanych parametrów,
elementów)
SMON.28
5.2.6
Wykonawca dostarczy, wdroży i uruchomi powyższe wymagania
Rozbudowa SONA o środowisko szkoleniowe (SZK SONA)
Z uwagi na konieczność prowadzenia szkoleń w ramach SONA wymagane jest wykreowanie
odrębnego środowiska szkoleniowego, zwanego dalej SZK SONA, w ramach którego realizowane
będą ćwiczenia Operatorów przygotowujących się do pracy z SONA.
Środowisko SZK SONA będzie dedykowane dla celów szkoleniowych Operatorów SONA. W ramach
środowiska
rozbudowane
zostaną
elementy
Ośrodka
Krajowego,
dedykowane
Serwery
Komunikacyjne z redundancja wewnętrzną (niezależne od SK eksploatowanych w ramach
środowiska produkcyjnego). Rozwiązanie SZK SONA musi rozbudowywać centralną architekturę
SONA o środowisko szkoleniowe, przy czym musi zostać uwzględnione, że stanowiska dostępowe
oraz konsole operatorskie dedykowane pod działania szkoleniowe, będą fizycznie zlokalizowane w
każdym WCPR i zdalnie łączyły się do SZK SONA. W ramach SZK SONA wymagane jest
wytworzenie rozwiązania dla odseparowania grup szkoleniowych, w celu uniknięcia zakłóceń między
WCPR w trakcie realizacji ćwiczeń, np. poprzez stworzenie odseparowanych logicznie grup
szkoleniowych. Szczegółowy opis realizacji przedmiotowej rozbudowy zostanie zawarty ustalony na
etapie Projektu Technicznego.
Zakup i dostawa stanowisk dostępowych i konsol dyspozytorskich na potrzeby SZK SONA
nie wchodzi w zakres zamówienia.
S t r o n a | 26
Tabela
7
minimalne
wymagania
w
celu
rozbudowy
SONA
o
środowisko
szkoleniowe (SZK SONA)
Kod
Opis wymagania
wymagania
WSZK.1
Rozbudowa SONA o środowiska szkoleniowego (SZK SONA).
WSZK.2
Rekonfiguracja szkoleniowych stanowisk operatorskich:
- podłączenie wskazanych przez Zamawiającego stanowisk dostępowych do
środowiska szkoleniowego serwera aplikacji OK;
- podłączenie wskazanych przez Zamawiającego konsol dyspozytorskich do sieci
komunikacji AMQ środowiska szkoleniowego PZŁ.
WSZK.3
Rekonfiguracja Serwera Komunikacyjnego (SK):

wykreowanie
nowej,
niezależnej
bazy
konfiguracji
dla
środowiska
szkoleniowego PZŁ,

wykreowanie nowych profili użytkowników konsol dyspozytorskich dla
środowiska szkoleniowego PZŁ,

WSZK.4
podłączenie traktu Operatora.
Rekonfiguracja w obrębie OK poprzez stworzenie odrębnych nieimiennych kont
szkoleniowych w domenie SZK SONA w liczbie 50 kont, które będą do dyspozycji
dla każdego z 17 WCPR.
WSZK.4.1
Zamawiający
wymaga
rozwiązania
umożliwiającego
prowadzenie
do
5
jednoczesnych instancji szkoleń, pomiędzy którymi Zamawiający będzie mógł w
dowolny dla niego sposób dysponować liczbą 50 kont.
WSZK.4.2
Dysponowanie kontami szkoleniowymi będzie leżało w gestii uprawnionych do tego
administratorów.
WSZK.5
Ze względów bezpieczeństwa i ułatwienia zarządzania, zapewnienie podziału
adresacji na VLAN dedykowanych dla SZK SONA.
WSZK.6
Wymagana jest praca SZK SONA niezależnie od pozostałych środowisk SONA.
WSZK.7
Elementy wspólne infrastruktury Ośrodka Krajowego muszą pracować w oparciu o
niezależną konfigurację zapewniającą pełną separację funkcjonalności, zasobów
danych oraz sieci środowiska SZK SONA.
WSZK.8
Ze względów bezpieczeństwa SZK SONA zostanie zrealizowane całkowicie odrębnie
od środowiska produkcyjnego SONA. Wszystkie usługi składowe każdego z tych
środowisk będą obsługiwane na serwerach wirtualnych pracujących w odrębnej
grupie vSphere lub innego środowiska wirtualizacyjnego, bądź fizycznego.
WSZK.9
W obrębie systemu vSphere lub innego środowiska wirtualizacyjnego, bądź
fizycznego stworzona zostanie odrębna grupa SZK SONA obejmująca wirtualne
serwery pracujące na rzecz tego środowiska.
WSZK.10
Grupa SZK SONA musi mieć własnego administratora z uprawnieniami tylko do
zarządzania serwerami wirtualnymi w obrębie swojej grupy. Wymagane jest
dodatkowo aby administrator grupy serwerów produkcji dodatkowo posiadał
uprawnienia do rozdziału zasobów sprzętowych na poszczególne grupy
(środowiska).
WSZK.11
Przydział przestrzeni dyskowej dla SZK SONA musi uwzględniać wymagania
vSphere lub innego środowiska wirtualizacyjnego, bądź fizycznego, dla nowego
S t r o n a | 27
środowiska oraz dodanie baz danych nowego środowiska.
5.2.7
Budowa oraz rozbudowa interfejsów do Systemów Zewnętrznych
Tabela 8 minimalne wymagania w celu budowy oraz rozbudowy interfejsów do
Systemów Zewnętrznych
Kod
Opis wymagania
wymagania
WINT.1
Wykonawca dokona integracji SONA z Systemami Zewnętrznymi polegającą na:

Aktualizacji
obecnie
używanych
interfejsów
(jeżeli
zaistnieje
taka
konieczność),

Budowie nowych interfejsów
WINT.2
Wykonawca dostarczy i wdroży interfejs aktualizacji danych słownikowych w SONA
z Systemu Zewnętrznego będącego w dyspozycji GUGiK.
WINT.2.1
W ramach WINT.2 Zamawiający wymaga dokonywania aktualizacji słowników w
oparciu o:
5.2.8

Synchroniczne pobieranie danych,

Asynchroniczne pobieranie danych,

Weryfikacja danych,
Rozbudowa SONA o środowisko pre-produkcyjne (PRE SONA)
Tabela 9 minimalne wymagania w celu rozbudowy SONA o środowisko preprodukcyjne (PRE SONA)
Kod
Opis wymagania
wymagania
WSPRE.1
Rozbudowa SONA o środowisko pre-produkcyjne (PRE SONA).
WSPRE.2
Funkcjonalność środowiska PRE musi być identyczna (zarówno dla wymagań
funkcjonalnych i niefunkcjonalnych) ze środowiskiem produkcyjnym.
WSPRE.2.1
Środowisko musi składać się z identycznych Urządzeń i Oprogramowania jak
środowisko produkcyjne.
WSPRE.2.2
Środowisko musi spełniać identyczne wymogi w stosunku do pojemność oraz
wydajność.
WSPRE.3
Środowisko musi mieć funkcjonalność automatycznej oraz ręcznej synchronizacji
danych od środowiska produkcyjnego w trybie:
 synchronicznym;
 asynchronicznym.
WSPRE.3.1
Dostarczane rozwiązanie musi mieć możliwość czasowego
synchronizacji,
synchronizacji
w
określonych
przedziałach
synchronizacji inicjalnej.
wstrzymania
czasowych,
S t r o n a | 28
5.2.9
Rozbudowa SONA o środowisko developerskie (DEV SONA)
Tabela
10
minimalne
wymagania
w
celu
rozbudowy
SONA
o
środowisko
developerskie (DEV SONA)
Kod
Opis wymagania
wymagania
WSDEV.1
Rozbudowa SONA o środowisko developerskie (DEV SONA).
WSDEV.2
Funkcjonalność
produkcyjnym.
6
środowiska
DEV
musi
WYMAGANIA DOTYCZĄCE USŁUGI INSTALACJI
Kod
być
identyczna
z
środowiskiem
URZĄDZEŃ
Opis wymagania
wymagania
WDRU.01
Usługi instalacyjne musza obejmować w szczególności:
- Dostarczenie Urządzeń do wskazanych przez Zamawiającego Lokalizacji
- Rozpakowanie Urządzeń oraz utylizacja opakowań
- Montaż Urządzeń w dostarczonych przez Wykonawcę szafach
- Podłączenie Urządzeń do zapewnianych przez Zamawiającego obwodów
zasilających
- Instalacja Urządzeń zgodnie z Projektem Technicznym Systemu,
- Instalacja Oprogramowania na Urządzeniach
- Konfiguracja Urządzeń
- Uruchomienie Urządzeń
WDRU.02
Usługi konfiguracyjne muszą obejmować w szczególności:
- Konfigurację Urządzeń oraz Oprogramowania zgodnie z Projektem Technicznym,
WDRU.03
Usługi testowe muszą zostać przeprowadzone zgodnie z procedurą określoną w
Planie Testów Akceptacyjnych, dokumencie opracowanym przez Wykonawcę
zgodnie z wymaganiem DOK.1.1.2
WDRU.03.1
Zamawiający wymaga, aby Wykonawca najpóźniej w terminie 32 dni przed
planowanym zakończeniem etapu 2 poinformował Zamawiającego o zakończeniu
prac związanych z Planem Uruchomienia oraz gotowości Systemu do
przeprowadzenia testów akceptacyjnych (PTA).
WDRU.03.2
Zamawiający zastrzega sobie prawo do zlecenia wykonania całości lub części
testów przez wskazany przez niego podmiot zewnętrzny.
WDRU.04
Usługi wdrożeniowe muszą obejmować w szczególności:
- Uruchomienie Systemu będącego przedmiotem zamówienia w celu
przeprowadzenia testów akceptacyjnych zgodnie z Planem Uruchomienia,
- Przekazania rozwiązania produkcyjnego Zamawiającemu,
- Wykonanie Dokumentacji powykonawczej zawierającej szczegółowy opis
wdrożonego rozwiązania oraz zmian w dokumentacji projektowej uwzględniającej
poprawki naniesione w trakcie wdrożeniowa.
S t r o n a | 29
7
WYMAGANIA W ZAKRESIE PRODUKCYJNEGO URUCHOMIENIA SYSTEMU
Kod
Opis wymagania
wymagania
WDRUP.04
8
Usługi wdrożeniowe muszą obejmować w szczególności:
- Uruchomienie Systemu będącego przedmiotem zamówienia w celu
przeprowadzenia testów akceptacyjnych zgodnie z planem wdrożenia,
- Przekazania rozwiązania produkcyjnego Zamawiającemu,
- Wykonanie Dokumentacji powykonawczej zawierającej szczegółowy opis
wdrożonego rozwiązania oraz zmian w dokumentacji projektowej uwzględniającej
poprawki naniesione w trakcie wdrożeniowa.
WYMAGANIA W ZAKRESIE WARSZTATÓW
W ramach realizacji przedmiotu zamówienia Wykonawca przeprowadzi warsztaty
tematyczne w zakresie dostarczanych rozwiązań w niniejszym zamówieniu, zgodnie z poniżej
przedstawionymi wymaganiami:
Kod
Opis funkcjonalności
wymagania
WRT.1
Wykonawca przeprowadzi warsztaty w języku polskim, obejmujące wykłady
teoretyczne oraz warsztaty praktyczne w zakresie użytkowania i administrowania
dostarczonych rozwiązań w niniejszym zamówieniuzamówieniu (w tym wykonanie
wybranych przez ZamawiającegoZamawiającego procedur dostarczanych w ramach
niniejszego zamówienia).
WRT.2
Wykonawca opracuje harmonogram warsztatów zawierający:
 cel i projektowany zakres warsztatów,
 informacje o zakresie tematycznym warsztatów,
 metodę i formę warsztatów,
 czasie trwania warsztatów,
 wykaz pożądanych kwalifikacji osób skierowanych na warsztaty,
 koszt jednostkowy wykonania warsztatów,
 miejsce realizacji.
WRT.3
Harmonogram, o którym mowa w wymaganiu WRT.02, wykonawca przedstawi do
akceptacji Zamawiającego.
WRT.4
Wykonawca zobowiązany jest do przeprowadzenia warsztatów zgodnie z
zatwierdzonym harmonogramem warsztatów, o którym mowa w wymaganiu
WRT.02.
WRT.5
W warsztatach weźmie udział do 20 osób wskazanych przez Zamawiającego.
Zamawiający zastrzega sobie możliwość utworzenia grup warsztatowych.
WRT.6
Wykonawca zapewni materiały warsztatowe (w języku polskim) dla uczestników
warsztatów oraz przeniesie prawa autorskie do opracowanych materiałów
warsztatowych.
WRT.7
Wykonawca dostarczy Zamawiającemu materiały warsztatowe, o których mowa w
WRT.06, w postaci zapisu na płycie CD/DVD (lub innym równoważnym nośniku).
Materiały warsztatowe będą w formie elektronicznej niezabezpieczonej (w formacie
.pdf, .doc, .docx, .pps, PPS)
S t r o n a | 30
WRT.8
Wykonawca zapewni prowadzenie warsztatów przez wykwalifikowaną kadrę
posiadającą wiedzę teoretyczną i praktyczną w zakresie użytkowania i
administrowania rozwiązań dostarczanych w ramach niniejszego zamówienia.
WRT.9
Uczestnicy warsztatów otrzymają zaświadczenie ukończenia warsztatów,
potwierdzające ich udział w warsztatach (certyfikat).
WRT.10
Przeprowadzenie warsztatów 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 warsztatów,

datę i miejsce warsztatów,

imienną listę osób uczestniczących w warsztatach,

imię i nazwisko oraz specjalizację osób prowadzących warsztaty,
WRT.11
Odbiór warsztatów nastąpi na podstawie protokołu z przeprowadzenia warsztatów,
podpisanego przez Zamawiającego bez uwag i zastrzeżeń.
WRT.1414
Czas trwania warsztatów wyniesie 14 dni,po 8 godzin dzienniedziennie.
WRT.1515
Wykonawca zapewni uczestnikomuczestnikom warsztatów materiały warsztatowe
zarówno w formie papierowej jak i elektronicznej formie niezabezpieczonej (w
formacie .pdf, .doc, .docx, .pps, ppsx).
9
WYMAGANIA W ZAKRESIE DOKUMENTACJI
Wykonawca
w
ramach
realizacji
przedmiotu
zamówienia
dostarczy
dokumentację
spełniającą wymagania określone w poniższej tabeli:
Kod
Opis funkcjonalności
wymagania
DOK.1
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:
DOK.1.1
W ramach Projektu Technicznego Wykonawca opracuje i dostarczy następujące
dokumenty:

Plan Uruchomienia Systemu,

Plan Testów Akceptacyjnych (PTA) ,

Szczegółowy opis realizacji wymagań,

Analizę biznesową (zawierającą m.in. identyfikację usług,
choreografię procesów [usługi wywoływane, kolejność wywołań,
przekazywane między usługami dane]).

Opracowanie wysokopoziomowej architektury rozwiązania
(zawierający w szczególności model przypadków użycia wraz z ich
specyfikacją).

Opracowanie niskopoziomowej architektury rozwiązania
(zawierający w szczególności modele konceptualne baz danych,
interfejsów, macierz połączeń, konfigurację sprzętową rozbudowanych
podzespołów [podział zasobów na partycje, podziały pamięci i
procesorów]).

wytworzenie dokumentu opisującego wytyczne do budowy
ośrodka awaryjnego dla Ośrodka Krajowego.

plan migracyjny komponentów obecnie wykorzystywanych do
architektury wynikającej z zamawianej rozbudowy,
S t r o n a | 31

analizę finansową kosztów eksploatacji systemu w ciągu 5 lat.
DOK.1.1.1
Plan wdrożenia Systemu - w ramach tego dokumentu Wykonawca opracuje
niezbędne informacje dla instalacji Urządzeń w Lokalizacjach. Dokument
zawierać będzie informacje odnośnie Urządzeń oraz Oprogramowania a także
każdej Lokalizacji w których instalowane będą Urządzenia dla potrzeb
dostarczenia Systemu, które są przedmiotem tego zamówienia, a także opisze
wszelkie zadania do zrealizowania przez Wykonawcę,
DOK.1.1.2
Plan Testów Akceptacyjnych (PTA) - dokument PTA musi być przygotowany przez
Wykonawcę w oparciu o Załącznik nr 3 do OPZ dla każdej Lokalizacji i podlega
akceptacji Zamawiającego.
DOK.1.1.3
Szczegółowy opis realizacji wymagań – Wykonawca opracuje dokumentację
przedstawiającą szczegółowy sposób spełnienia wszystkich wymagań niniejszego
postępowania. Wykonawca musi również opracować i dostarczyć, w ramach
niniejszej dokumentacji, tabelę opisującą minimalny wzrost zasobów (pamięć,
moc procesorów / ilość procesorów / rdzeni, przestrzeni dyskowych, licencji, BTU
i innych) w przypadku wzrostu wymagań o 20% i 50 % w stosunku do wartości
przedstawionych w pkt 5.2 Tabela 3;
DOK.1.1.4
Plan Uruchomienia Systemu – dostarczony przez Wykonawcę dokument
zawierający zestaw procedur niezbędnych do instalacji, konfiguracji oraz
uruchomienia Urządzeń i Oprogramowania w Lokalizacjach. Dokument ponadto
będzie zawierał harmonogram wdrożenia zależności pomiędzy poszczególnymi
krokami, analizę ryzyka.
DOK.1.2
Plan Zarządzania Projektem – dokument musi zawierać zdefiniowane co
najmniej:
 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.
DOK.1.3
Dokumentację Powykonawczą, zawierającą co najmniej następujące informacje:

Wprowadzenie opisujące cele i zakres przedmiotu zamówienia,

Diagram kontekstowy zaproponowanego rozwiązania,

Opis wymagań funkcjonalnych i niefunkcjonalnych Systemu,

Specyfikację wymagań funkcjonalnych i pozafunkcjonalnych,

Specyfikację wymagań Oprogramowania,

Opis i specyfikację interfejsów Urządzeń,

Opis rozwiązania wydajności, skalowalności i niezawodności Ośrodków
Krajowych.
DOK.1.4
Dokumentację
Eksploatacyjną,
zawierającą,
co
najmniej
procedury:
administracyjne, backupu systemu i danych, awaryjne i użytkownika, przy czym
każda z procedur musi zawierać, co najmniej następujące wyszczególnione
informacje:
– procedury związane z administracją i eksploatacją,
S t r o n a | 32
procedury o charakterze testowym,
procedury działania administratora dla wdrożonego Systemu,
procedury konserwacji wdrożonego Systemu,
procedury awaryjne,
procedury zabezpieczeń (backup’owe),
procedury kontroli bezpieczeństwa Systemu (Audyt),
procedura identyfikacji i kwalifikacji błędu,
procedury kwalifikacji zgłoszeń serwisowych,
procedury eskalacji zgłoszeń serwisowych.
z ww. procedur będzie zawierać minimum następujące informacje:
identyfikator i nazwa procedury,
rodzaj procedury,
data utworzenia i zatwierdzenia oraz wersja procedury,
cel i zakres procedury,
uzasadnienie zastosowania,
warunki uruchomienia procedury i oczekiwany oraz możliwy rezultat jej
wykonania,
– dane osób, które opracowały procedurę, sprawdziły, zaakceptowały i
zatwierdziły,
– wzór formularza zgłoszenia błędu (dla procedur awaryjnych),
– szczegółowy opis rezultatów,
– możliwe niepowodzenia,
– przebiegi alternatywne,
- algorytm działania, jaki należy zastosować, wykonując kolejne czynności,
aby osiągnąć postawiony cel, w tym z informacją o osobie, która powinna
wykonać dane czynności.
–
–
–
–
–
–
–
–
–
Każda
–
–
–
–
–
–
DOK.1.4.1
Procedury muszą zostać zoptymalizowane pod kątem ciągłości działania usług
systemu o wysokim poziomie SLA.
Dopuszczalny jest zbiór procedur, przy czym każdy zbiór procedur musi być
zaakceptowany przez Zamawiającego
DOK.1.5
Raport Wdrożenia – podsumowanie działań wdrożenia produkcyjnego Systemu
wraz z raportem zawierającym szczegółowy opis działania Systemu w okresie 7
dni od zakończenia wdrożenia produkcyjnego.
DOK.2
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,
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.
DOK.3
Cała dokumentacja, o której mowa powyżej, podlega akceptacji Zamawiającego i
zostanie dostarczona w języku polskim, w wersji elektronicznej w
niezabezpieczonym/edytowalnym formacie Word i niezabezpieczonym formacie
S t r o n a | 33
PDF (na płycie CD/DVD lub innym równoważnym nośniku danych) i drukowanej,
co najmniej w 1 egzemplarzu (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 muszą być dostarczone w formacie EAP. Dostarczone
wykresy Gantta muszą być dostarczone w formacie MPP lub w formacie XLS
umożliwiającym import do MS Project.
DOK.3.1
Kody źródłowe Oprogramowania Aplikacyjnego zostaną opisane i dostarczone
przez Wykonawcę w wersji elektronicznej. Dostarczone kody źródłowe
Oprogramowania Aplikacyjnego będą miały dołączoną niezbędną specyfikację
środowiska
programistycznego
(jego
konfigurację),
która
umożliwi
przeprowadzenie ich kompilacji i uruchomienia.
DOK.3.2
Wymagane jest aby w ramach Dokumentacji Wykonawca przekazał
Zamawiającemu pliki źródłowe zastosowanych w niej obrazów, w tym m.in.
schematów, rysunków, topologii oraz wykresów, w formacie niezabezpieczonym i
edytowalnym.
DOK.3.3
Wymagane jest aby w ramach Dokumentacji Wykonawca przekazał
Zamawiającemu wszystkie dokumenty robocze wytworzone w takcie realizacji
niniejszego zamówienia, w szczególności analizy, arkusze kalkulacyjne, materiały
robocze, w formacie elektronicznym, niezabezpieczonym i edytowalnym.
DOK.4
Wykonawca na etapie zawierania umowy dostarczy wykaz ilościowo-cenowy.
Dokument zawierać będzie kosztorys przedmiotu umowy, uwzględniający
szczegółowy wykaz ilościowo-cenowy dla następujących zakresów:
 środki trwałe,
 usługi,

DOK.5
wartości niematerialne i prawne.
Wykonawca przedstawi do akceptacji Zamawiającego dokument ‘Dokumentacja
powdrożeniowa Systemu’ , zawierający co najmniej:

Przebieg (wraz ze szczegółowym opisem)
prac i czynności
wdrożeniowych (w tym napotkanych problemów wraz z opisem ich
rozwiązania),

Szczegółowy opis działania wytworzonych w ramach niniejszego
Zamówienia procedur (w tym napotkanych problemów jako przebiegi
alternatywne wraz z opisem ich rozwiązania),

Szczegółowy opis procedur (wraz z zalecanym harmonogramem) które
należy wykonywać w celu prawidłowej konsekracji przedmiotowego
mechanizmu kopii zapasowych.
DOK.6
Wykonawca dostarczy dokument ‘Szczegółowy Opis Systemu Monitoringu’, który
będzie zawierał informacje jakie parametrów jakie należy monitorować (wraz z
zależnościami i progami ostrzegawczymi) w celu zachowania prawidłowej pracy
Systemu. Dokument musi zawierać także analizy przeprowadzone w wymaganiu
SMON.24-26.
DOK.7
Wykonawca dokona aktualizacji do poziomu Systemu posiadanej przez
Zamawiającego dokumentacji dot. SI WCPR i SWD PRM, w tym dokumentu
Polityki Bezpieczeństwa.
DOK.8
Wykonawca do Dokumentacji dołączy wykaz zawierający szczegółowy spis
Dokumentów wraz z opisem ich przeznaczenia.
S t r o n a | 34
10 WYMAGANIA W ZAKRESIE OZNAKOWANIA
Kod
URZĄDZEŃ i DOKUMENTACJI
Opis wymagania
wymagania
WOZN.01
Wykonawca zobowiązany jest do oznakowania wszelkiej dokumentacji związanej z
projektem oraz infrastruktury (Urządzeń) dostarczanej w ramach realizowanej
umowy zgodnie z : „Przewodnikiem w zakresie promocji projektów finansowanych
w ramach Programu Operacyjnego Innowacyjna Gospodarka, 2007-2013 dla
beneficjentów i instytucji zaangażowanych we wdrażanie programu”. Oznakowanie,
w tym projekt graficzny naklejki, podlega akceptacji Zamawiającego.
11 WYMAGANIA W ZAKRESIE DOSTĘPNOŚCI
Kod
Opis wymagania
wymagania
WDSYS.01
Zapewnienie architektury rozwiązania gwarantującej niezawodność Systemu na
poziomie SLA co najmniej 99.99% (niedostępność w skali miesiąca 4.38 min).
SLA liczone jest jako suma czasu trwania niedostępności Systemu
spowodowanego Błędami 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).
12 WYMAGANIA W ZAKRESIE GWARANCJI
Kod
Opis wymagania
wymagania
WG.1
Gwarancja na dostarczone Urządzenia i Oprogramowanie biegnie osobno dla
każdego z ww., od daty podpisania przez Zamawiającego protokołu jakościowego
danej dostawy. W przypadku jeżeli świadczenie gwarancyjne polegać będzie na
wymianie wadliwego Urządzenia lub Oprogramowania na wolne od wad, okres
gwarancji dla tego Urządzenia lub Oprogramowania biegł będzie na nowo od daty
protokołu stwierdzającego tę wymianę.
WG.2
Wymagany tryb zgłaszania wszelkich błędu 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.3
Zgłoszenie wszelkiej błędu następuje przez Zamawiającego lub przedstawiciela
Zamawiającego.
WG.4
Wykonawca dokona usunięcia Błędu Niekrytycznej w terminie nie dłuższym niż
24 godzin od momentu zgłoszenia Błędu Niekrytycznej (usunięcie Błędu
Niekrytycznej rozumiane jest jako przywrócenie funkcjonalności Systemu sprzed
Błędu Niekrytycznej).
WG.5
Wykonawca dokona usunięcia Błędu Zwykłej w terminie nie dłuższym niż 72
godzin od momentu zgłoszenia Błędu Zwykłej (usunięcie Błędu Zwykłej
S t r o n a | 35
rozumiane
Zwykłej).
jest
jako
przywrócenie
funkcjonalności
Systemu
sprzed
Błędu
WG.6
Wykonawca dokona naprawy (lub wymiany) Urządzenia w Lokalizacji wskazanej
przez Zamawiającego; w przypadku konieczności dokonania naprawy poza
Lokalizacją, w której zainstalowany zostanie System, Wykonawca pokryje koszty
transportu i ewentualnego ubezpieczenia przedmiotu zamówienia do miejsca
naprawy oraz jego zwrotu do Lokalizacji wskazanej przez Zamawiającego.
WG.7
Przez usunięcie wszelkich błędów rozumie się rozwiązanie problemu albo
zaproponowanie procedury obejścia zaistniałej błędów bez rozwiązania problemu,
pod warunkiem że na przedstawioną przez Wykonawcę propozycję Zamawiający
wyrazi zgodę.
WG.8
Wykonawca jest zobowiązany do samodzielnego dokonania naprawy/wymiany
Urządzenia w Lokalizacji. Jednakże, o ile Zamawiający wyrazi uprzednią zgodę,
dopuszcza się realizację świadczenia gwarancyjnego w ten sposób, że na
podstawie informacji diagnostycznych przekazanych przez Zamawiającego do
Wykonawcy podczas zgłoszenia wszelkich błędów, Wykonawca prześle na swój
koszt zamiennik uszkodzonego Urządzenia, natomiast fizycznej wymiany
uszkodzonego Urządzenia 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.
WG.9
Gwarancja obejmuje również wykonanie przez Wykonawcę wszelkich czynności
związanych
z przywróceniem pierwotnego stanu pracy Systemu (sprzed
wszelkiego błędu) oraz pokrycie przez Wykonawcę kosztów części zamiennych
użytych do przywrócenia Systemu do stanu pierwotnego (sprzed wszelkiego
błędu).
WG.10
W okresie udzielenia licencji na Oprogramowanie Standardowe Wykonawca w
ramach otrzymanego wynagrodzenia udostępni Zamawiającemu możliwość
wielokrotnego
uaktualniania
całego
dostarczonego
Oprogramowania
Standardowego do najnowszych wersji oferowanych przez producenta (włączając
tzw. firmware), a także dostęp do usług wsparcia technicznego producenta
danego Urządzenia lub Oprogramowania. 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 modułów dowolnych
producentów oraz wymiany zainstalowanych modułów samodzielnie lub z pomocą
Wykonawcy, w zakresie przewidzianym przez producenta Urządzenia, bez utraty
gwarancji na zakupione Urządzenia. Zamawiający będzie dokonywał wymiany
modułów samodzielnie po wcześniejszym uzgodnieniu z Wykonawcą.
WG.12
Gwarancja obejmuje między innymi:

wady materiałowe i konstrukcyjne, a także nie spełnienie
deklarowanych przez producenta parametrów i/lub funkcji użytkowych
Urządzeń i Oprogramowania;

naprawę wykrytych uszkodzeń, w tym wymianę uszkodzonych
modułów na nowe;
usuwanie wykrytych usterek i błędów funkcjonalnych w działaniu Urządzeń lub
Oprogramowania.
WG.13
W przypadku błędu dysku twardego, powodującej konieczność jego wymiany,
uszkodzony dysk pozostanie u podmiotu, który posiada uprawnienia do
korzystania z Urządzeń i Oprogramowania dostarczonego w ramach realizacji
niniejszej Umowy oraz nie będzie podlegał ekspertyzie poza siedzibą. W
przypadku konieczności jakiejkolwiek naprawy sprzętu poza miejscem jego
S t r o n a | 36
instalacji, dysk twardy zostanie zdemontowany i pozostanie Lokalizacji jego
użytkowania.
WG.14
W przypadku konieczności naprawy Urządzenia
Lokalizacją, Wykonawca organizuje transport do
naprawie do Lokalizacji użytkowania oraz pokrywa
uszkodzenia lub przypadkowej utraty Urządzenia lub
WG.15
Dwukrotne uszkodzenie tego samego Urządzenia lub modułu będącego
wyposażeniem tego Urządzenia w okresie gwarancji obliguje Wykonawcę do jego
wymiany na nowy, wolny od wad, spełniającego te same parametry i zgodnego
funkcjonalnie z naprawianym Urządzeniem, w terminie 14 dni od chwili
ostatniego zgłoszenia o uszkodzeniu. Okres gwarancji na wymienione Urządzenie
będzie zgodny z okresem gwarancji wskazanym w umowie z zastrzeżeniem..
WG.16
Wykonawca do dostarczonego Urządzenia, będącego przedmiotem zamówienia,
dołączy karty gwarancyjne zawierające numer seryjny, termin i warunki ważności
gwarancji, adresy i numery telefonów punktów serwisowych świadczących usługi
gwarancyjne.
WG.17
Wykonawca ponosi odpowiedzialność za poprawne funkcjonowanie Systemu.
lub Oprogramowania poza
miejsca naprawy oraz po
jego koszty i ponosi ryzyko
Oprogramowania.
13 WYMAGANIA W ZAKRESIE ZGODNOŚCI Z PRZEPISAMI PRAWA
Kod
wymagania
Opis wymagania
PR.01
Rozwiązanie dla Systemu musi być zgodne z niżej wymienionymi aktami
prawnym:
 Ustawa o ochronie danych osobowych z dnia 29.08.1997 roku. (tekst
jednolity Dz. U. z 2002 r., Nr 101, poz. 926);
 Rozporządzenie Rady Ministrów w sprawie Krajowych Ram
Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i
wymiany informacji w postaci elektronicznej oraz minimalnych
wymagań dla systemów teleinformatycznych z dnia 12.04.2012 r. (Dz.
U. z 2012 r., poz. 526);
 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 (Dz. U. z 2005 r., Nr 64, poz. 565 z
późn. zm.);
 Ustawa z dnia 24 sierpnia 1991 r. o ochronie przeciwpożarowej (tekst
jednolity Dz. U. z 2009 r. Nr 178, poz. 1380 z późn. zm.);
 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. 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 z późn. zm.);
 Dyrektywa 2002/22/WE Parlamentu Europejskiego i Rady z dnia 7
S t r o n a | 37

marca 2002 r. w sprawie usługi powszechnej i związanych z sieciami i
usługami łączności elektronicznej praw użytkowników (dyrektywa o
usłudze powszechnej) - Dz.U.UE.L.2002.108.51 z późn. zm.;
Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 24
marca 2011 r. w sprawie centralnego punktu systemu centrów
powiadamiani ratunkowego oraz punktów centralnych służb (Dz. U. z
2011 r., Nr 75, poz. 404)
14 WYMAGANIA W ZAKRESIE ZARZĄDZANIA PROJEKTEM
Kod
Opis wymagania
wymagania
WZP.1
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.
WZP.2
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.
S t r o n a | 38
15 LISTA ZAŁĄCZNIKÓW
Załącznik nr 1 – szablon PTA;