Opis przedmiotu zamówienia

Transkrypt

1 S t r o n a 1 Opis przedmiotu zamówienia Modyfikacja Systemu Wspomagania Dowodzenia Państwowego Ratownictwa Medycznego w celu integracji z modułami GSM/GPS model Teltonika FM3300

2 S t r o n a 2 Spis treści 1 SŁOWNIKI I SKRÓTY CEL ZAMÓWIENIA PRZEDMIOT ZAMÓWIENIA AKTUALNE ŚRODOWISKO Wymagania ogólne Wymagania w zakresie usług wdrożeniowych i testów Świadczenie Usługi Serwisu Gwarancyjnego i gwarancji WYMAGANIA W ZAKRESIE DOKUMENTACJI WYMAGANIA W ZAKRESIE DOSTĘPNOŚCI WYMAGANIA W ZAKRESIE ZGODNOŚCI Z PRZEPISAMI PRAWA LISTA ZAŁĄCZNIKÓW... 15

3 S t r o n a 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 AVL (ang. Automatic VehicleLocation) Automatyczna Lokalizacja Pojazdów Aplikacja Dyspozytora Moduł Systemu używany przez Dyspozytorów medycznych w celu obsługi przyjmowania zgłoszeń i komunikacji z ZRM. Aplikacja mobilna ZRM Moduł Systemu zainstalowany i uruchomiony na TM, wykorzystywany przez ZRM do pracy poza miejscem stacjonowania w celu odbierania Zleceń Wyjazdu ze wskazaniem miejsca Zdarzenia i powodu wezwania, prowadzenia do miejsca Zdarzenia (mapa) oraz rejestrowania aktualnych statusów ZRM i danych Zdarzenia (w szczególności w zakresie dokumentacji medycznej Zdarzenia). APN (ang. Access Point Name) urządzenia umożliwiające Użytkownikom TM zalogowanym do sieci komórkowych korzystanie z transmisji danych przesyłanych do/z zewnętrznych sieci (np. sieci pakietowych); Błąd Oznacza Błąd Krytyczny i/lub Błąd Niekrytyczny i/lub Błąd Zwykły; Błąd Krytyczny Oznacza brak działania Modyfikacji, 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) Modyfikacja Systemu 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 zaakceptowane przez Wykonawcę w trakcie okresu gwarancji; d) wszelkie błędy związane z bezpieczeństwem przechowywania i przetwarzania danych, które mogą wpłynąć na: a. uwierzytelnianie, b. niezaprzeczalność, c. poufność, d. integralność, e. dostępność, f. rozliczalność, Błąd Niekrytyczny Utrudnia działanie Modyfikacji Systemu w środowisku produkcyjnym w zakresie funkcjonalności krytycznej i uniemożliwia działanie Modyfikacji 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 zaakceptowane przez

4 S t r o n a 4 Skrót/pojęcie Definicja Wykonawcę w trakcie okresu gwarancji. Uniemożliwia oznacza brak możliwości jego obejścia; Błąd Zwykły Wszelki błąd niebędący Błędem Krytycznym lub Błędem Niekrytycznym; Dni Robocze Oznacza każdy dzień tygodnia od poniedziałku do piątku, za wyjątkiem dni ustawowo wolnych od pracy, w godz. od 8.15 do 16.15; Dokumentacja oznacza 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,, Dokumentacja Powykonawcza, dokumentacja powstała w wyniku Modyfikacji, w tym zmiany Oprogramowania Aplikacyjnego i kodów źródłowych Oprogramowania Aplikacyjnego, dokumentacja powstała w wyniku realizacji wymagań odbioru produktów, dokumenty robocze wytworzone przez Wykonawcę w ramach realizacji Umowy; za Dokumentację uznaje się także wytworzenie i aktualizację Dokumentacji w okresie gwarancji i świadczenia Usługi serwisu gwarancyjnego; Dyspozytor medyczny Pracownik medyczny odbierający informację o Zdarzeniu i decydujący na podstawie przeprowadzonego wywiadu o przyjęciu zdarzenia do obsługi albo odmowie jego obsługi przez ZRM, lub pracownik medyczny wskazujący właściwy ZRM do obsługi przyjętego do realizacji Zdarzenia i przekazujący do tego ZRM Zlecenie wyjazdu wraz ze wszystkimi danymi potrzebnymi do jego realizacji w momencie Zlecenia i w trakcie jego realizacji. Możliwe jest rozdzielenie funkcji dyspozytora medycznego na dyspozytora przyjmującego (decydującego o przyjęciu/odmowie realizacji) i dyspozytora wysyłającego (wskazującego ZRM i wspierającego realizację Zlecenia) albo pełnienie obu tych funkcji równocześnie przez tę samą osobę. GPS (ang. Global Positioning System) system nawigacji satelitarnej; Incydent serwisowy Oznacza zgłoszenie do Wykonawcy przez Zamawiającego lub osoby wskazane przez Zamawiającego, w trybie 24/7, nieprawidłowości w działaniu Modyfikacji Systemu. Wykonawca zobowiązany jest do rejestracji zgłoszenia oraz usuwania Błędów i usterek lub dostarczenia procedur obejścia, powodujących przywrócenie działania Modyfikacji Systemu i rozwiązania zgłoszenia. Incydenty niestanowiące Błędu lub usterki Wykonawca przekazuje do podmiotu wskazanego przez Zamawiającego Informacje Należy przez to rozumieć informacje, o których mowa w art. 78 ust. 3 ustawy z dnia 16 lipca 2004 r. Prawo telekomunikacyjne; Modyfikacja oznacza zmianę lub rozbudowę Oprogramowania Aplikacyjnego (w tym kody źródłowe Modyfikacji) oraz ich udostępnienie i zainstalowanie przez Wykonawcę w Systemie SWD PRM MSWiA Minister Spraw Wewnętrznych i Administracji wraz z organami i

5 S t r o n a 5 Skrót/pojęcie Definicja jednostkami organizacyjnymi podległymi oraz nadzorowanymi przez Ministra Spraw Wewnętrznych i Administracji Oprogramowanie Aplikacyjne oznacza dedykowane oprogramowanie, które zostało wytworzone na potrzeby i zlecenie Zamawiającego (w tym kody źródłowe), które jest częścią Systemu, Plan Testów Akceptacyjnych / PTA Dokument będący elementem Projektu Technicznego 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 6 do OPZ; POK Podstawowy Ośrodek Krajowy; Projekt Techniczny Projekt Techniczny, element Dokumentacji opisujący sposób wykonania, wdrożenia i właściwości Modyfikacji Systemu.; SI PR System Informatyczny Powiadamiania Ratunkowego SLA Service Level Agreement, poziom dostępności usług SWD PRM System Wspomagania Dowodzenia Państwowego Ratownictwa Medycznego wraz z urządzeniami i infrastrukturą sprzętową oraz zainstalowanym oprogramowaniem standardowym oraz Oprogramowaniem Aplikacyjnym, będący w posiadaniu Zamawiającego, umożliwiający przyjęcie z centrum powiadamiania ratunkowego, o którym mowa w ustawie z dnia 22 listopada 2013 r. o systemie powiadamiania ratunkowego (Dz. U. poz. 1635), zgłoszeń alarmowych, dysponowanie zespołów ratownictwa medycznego, rejestrowanie zdarzeń medycznych, prezentację miejsca geograficznego zdarzenia alarmowego, pozycjonowanie zespołów ratownictwa medycznego, przesyłanie niezbędnych danych o zdarzeniu (w tym danych zlecenia wyjazdu i danych medycznych) pomiędzy Dyspozytorami Medycznymi i właściwym ZRM w obu kierunkach oraz rejestrowanie danych o zdarzeniu zebranych przez ZRM w bazach danych Systemu. System System SWD PRM TM Terminal Mobilny urządzenie mobilne posiadające możliwość bezpiecznego zamocowania w pojeździe ZRM, na którym jest uruchomiony System w zakresie Aplikacji Mobilnej ZRM. Obecnie, jako TM wykorzystywane są tablety. Umowa Umowa zawarta pomiędzy Wykonawcą a Zamawiającym na potrzeby realizacji niniejszego przedmiotu zamówienia; Usługa Serwisu Gwarancyjnego Usługa świadczona w ramach gwarancji udzielonej przez Wykonawcę, polegająca na zapewnieniu przez Wykonawcę poprawności i ciągłości prawidłowego działania Modyfikacji oraz jej poszczególnych komponentów, w szczególności usuwanie Błędów; Wykonawca Podmiot realizujący zamówienie; Zamawiający Centrum Cyfrowej Administracji w Likwidacji ZOK Zapasowy Ośrodek Krajowy ZRM Zespół Ratownictwa Medycznego działająca w terenie jednostka wchodząca w skład systemu Państwowego Ratownictwa Medycznego, realizująca zlecenia wyjazdów przyjętych przez Dyspozytora medycznego

6 S t r o n a 6 Skrót/pojęcie Definicja w celu udzielenia pomocy pacjentom. znaczeniem. Pozostałe pojęcia użyte w dokumencie należy rozumieć zgodnie z ich ogólnie przyjętym 2 CEL ZAMÓWIENIA Przedmiotem zamówienia jest realizacja usługi integracji modułów GSM/GPS (model Teltonika FM3300) będących na wyposażeniu karetek z ogólnokrajowym Systemem Wspomagania Dowodzenia Państwowego Ratownictwa Medycznego (SWD PRM). W ramach Modyfikacji Zamawiający oczekuje dostosowania Serwera AVL, będącego elementem SWD PRM tak by uzyskać kompatybilność z posiadanymi modułami GPS FM3300. Jednocześnie Zamawiający oczekuje utrzymania obecnej kompatybilności Serwerów AVL z GPS AWIA LC 3G którego charakterystyka pracy jest opisana w załączniku nr 2 do OPZ. Zamawiający dysponuje kodami źródłowymi Oprogramowania Aplikacyjnego SWD PRM oraz jego dokumentacją powykonawczą (załącznik nr 4 do OPZ). Zamawiający jest właścicielem kodów źródłowych oprogramowania aplikacyjnego SWD PRM i dopuszcza ich modyfikację przez Wykonawcę, jeśli będzie to niezbędne do realizacji niniejszego Zamówienia.

7 S t r o n a 7 3 PRZEDMIOT ZAMÓWIENIA Przedmiotem zamówienia jest Modyfikacja SWD PRM Przedmiot zamówienia Maksymalny termin wyznaczony do realizacji Umowy 1) opracowanie i dostarczenie Zamawiającemu Dokumentacji, w szczególności: a) Projektu Technicznego b) Dokumentacji Powykonawczej. 2) przeniesienie na Zamawiającego i MSWiA autorskich praw majątkowych do Dokumentacji wraz z prawem zezwalania na wykonywanie praw zależnych; 3) Modyfikacje Oprogramowania Aplikacyjnego; 4) przeprowadzenie testów akceptacyjnych Modyfikacji, zgodnie z zatwierdzonym przez Zamawiającego Planem Testów Akceptacyjnych; 5) przeprowadzenie wdrożenia produkcyjnego Modyfikacji zgodnie z zatwierdzonym przez Zamawiającego Projektem Technicznym; 6) przeniesienie na Zamawiającego i MSWiA autorskich praw majątkowych do Modyfikacji w ramach Umowy wraz z prawem zezwalania na wykonywanie praw zależnych; 7) udzielenie gwarancji i świadczenie usługi serwisu gwarancyjnego dla Modyfikacji, w okresie 36 miesięcy od podpisania Protokołu Odbioru Końcowego; 40 dni kalendarzowych od dnia podpisania umowy, Gwarancja na Modyfikację Systemu w okresie 36 miesięcy od podpisania Protokołu Odbioru Końcowego

8 S t r o n a 8 4 AKTUALNE ŚRODOWISKO dodatkowe informacje Kod wymagania Opis funkcjonalności INF.1 Komunikacja mobilna dla urządzeń GPS zainstalowanych w karetkach zrealizowana jest z wykorzystaniem APN zapewnianym przez Zamawiającego, za pośrednictwem centralnego punktu styku OST112 INF.2 Dane dotyczące położenia geograficznego karetek oraz dane dotyczące parametrów pojazdu moduł GPS przesyła do serwera AVL. Moduł GPS przesyła także dane dotyczące położenia karetki do standardowej nawigacji samochodowej (Automapa) zainstalowanej na tablecie za pomocą kabla USB podłączonego do stacji dokującej tabletu. Dane dotyczące położenia pojazdu oraz dane z komputera pokładowego pojazdu przekazywane są w postaci ramek do serwera AVL transformującego dane i zapisującego je w bazie. Szczegółowy format danych protokołu komunikacji pomiędzy modułem GPS, a serwerem AVL został opisany w Załączniku nr 2 do OPZ INF.3 Serwer AVL jest oparty na Oprogramowaniu Aplikacyjnym którego Właścicielem jest Zamawiający INF.4 Do zaimplementowania Systemu Wspomagania Dowodzenia Państwowego Ratownictwa Medycznego wykorzystano język programowania Java 7 Update 76 32b INF.5 Dostarczane przez Zamawiającego urządzenia GPS instalowane w karetkach posiadają możliwość konfiguracji wyłącznie jednego ośrodka krajowego (POK lub ZOK) w celu przekazywania informacji o lokalizacji pojazdu. W przypadku wyłączenia ośrodka dane lokalizacyjne karetek skonfigurowanych na wyłączony ośrodek nie są dostępne dla systemu. Możliwa jest rekonfiguracja urządzenia poprzez dołączone do urządzenia oprogramowanie lub zdalnie za pomocą SMS/GPRS INF.6 System Wspomagania Dowodzenia Państwowego Ratownictwa Medycznego w chwili obecnej jest zintegrowany z Modułem GPS/GSM AWIA LC 3G, który komunikuje się z serwerem AVL za pośrednictwem protokołu komunikacji opisanym w Załącznik nr 2 do OPZ INF.7 Model fizyczny oraz logiczny bazy danych Systemu Wspomagania Dowodzenia Państwowego Ratownictwa Medycznego został opisany w dokumencie pt. SWDPRM_Baza_Danych_Model_Danych. Dokument został opisany zgodnie z notacją UML i stanowi Załącznik nr 5 do OPZ

9 S t r o n a 9 5 Wymagania ogólne Minimalne wymagania ogólne. Kod wymagania WODF.1 Opis funkcjonalności Po Modyfikacji w Systemie muszą być zapewnione funkcjonalności przewidziane w Projekcie Technicznym SWD PRM (Załącznik nr 3 do OPZ) oraz w Dokumentacji Powykonawczej SWD PRM (Załącznik nr 4 do OPZ), a w szczególności: - przekazywanie lokalizacji ZRM (Przypadek użycia: UC Monitorowanie i zarządzanie siłami i środkami; Przypadek użycia: UC Zarządzanie zgłoszeniami i zdarzeniami. SWDPRM Dokumentacja Powykonawcza) - Gromadzenie informacji o trasie przejazdu danego pojazdu, łącznie z prędkością, postojami, statusami i stanem czujników pojazdu. Czas odświeżania lokalizacji karetek konfigurowalny z poziomu administratora (domyślnie 30 sek.), zaś dane muszą być przechowywane w ramach Systemu przez okres 24-mc. (Przypadek użycia: UC.04. Raporty; Przypadek użycia: UC.05. Biznesowe administrowanie siłami i środkami SWDPRM Dokumentacja Powykonawcza) - Możliwość odtwarzania tras wybranych pojazdów, łącznie z prędkościami, WODF.2 WODF.3 postojami, statusami i stanem czujników pojazdu (dla wybranego pojazdu/kierowcy w zadanym czasie z możliwością wizualizacji na mapach UMM wybranej lokalizacji chwilowej ZRM). (Przypadek użycia: UC Odtwórz / ukryj trasę przejazdu pojazdu;; Scenariusz testowy: swd- 293:ST.DYS.26.Monitorowanie ZRM Dysponenta Koordynator; Scenariusz testowy: swd-294:st.dys.26.alt01.monitorowanie ZRM na terenie całego kraju- SWDPRM Dokumentacja Powykonawcza) - Automatyczna wizualizacja na mapie własnej pozycji pojazdu i pozycji przyjętego Zgłoszenia, oraz wyznaczenia trasy przejazdu z wykorzystaniem dostarczanego przez Wykonawcę ogólnie dostępnego, Standardowego Oprogramowania do nawigacji samochodowej. (Przypadek użycia: UC Czynności operacyjne;- SWDPRM Dokumentacja Powykonawcza) Zamawiający oczekuje dostosowanie Serwera AVL tak by uzyskać kompatybilność z posiadanymi modułami GPS, Jednocześnie Zamawiający oczekuje utrzymania obecnej kompatybilności protokołu GPS _ Serwer AVL z modułami innych producentów stosowanych w rozwiązaniu Zamawiający nie dopuszcza możliwości przeprowadzenia zmian po stronie modułu GPS/GSM, rozumianych jako ingerencję w samo urządzenie

10 S t r o n a 10 6 Wymagania w zakresie usług wdrożeniowych i testów Minimalne wymagania ogólne. Kod wymagania WT.1 Opis funkcjonalności W ramach przygotowania do testów Wykonawca wykona Usługi instalacyjne obejmujące w szczególności: -montaż i konfigurację co najmniej 2 modułów GPS/GSM Teltonika FM3300 w karetkach na potrzeby testów. Pojazdy, pozwalające na wykonanie prac instalacyjnych w jednej lokalizacji, zostaną wskazane przez Zamawiającego w terminie 10 dni od podpisania Umowy. WT.2 Usługi testowe muszą zostać przeprowadzone zgodnie z procedurą określoną w Planie Testów Akceptacyjnych, dokumencie opracowanym przez Wykonawcę i zaakceptowanym przez Zleceniodawcę. WT.3 Wszystkie mechanizmy, procesy związane z wdrożeniem nie mogą powodować przerw ani zakłóceń działania w bieżącej pracy środowiska produkcyjnego systemu SWD PRM. WT.4 Wszystkie funkcjonalności, mechanizmy, procesy objęte lub związane z wdrożeniem nie mogą powodować ograniczenia jakiejkolwiek funkcjonalności Systemu Wspomagania Dowodzenia Państwowego Ratownictwa Medycznego. WT.5 Plan Testów Akceptacyjnych musi uwzględniać weryfikację Modyfikacji w oparciu o działającą funkcjonalność Systemu wymienioną w wymaganiu WODF.1.w szczególności w zakresie: - zgodności zakresu informacji o ZRM przekazywanych przez moduł GPS dostępnych dla użytkownika Aplikacji Dyspozytora (w GUI aplikacji i mapach oraz dostępnych dla algorytmów wewnętrznych) z aktualnym zakresem danych. - spójności zakresu informacji dostępnego dla użytkownika Aplikacji Dyspozytora udostępnianych dla pojazdów wyposażonych w GPS/GSM Teltonika FM3300 i pojazdów wyposażonych w GPS/GSM AWIA LC 3G - wskazania dla modułu GPS/GSM jednego z dwóch dostępnych sposobu komunikowania się z serwerem AVL - poprawnego przekazywania lokalizacji pojazdu do aplikacji nawigacji samochodowej w TM (dostępności poprawnej lokalizacji z GPS w aplikacji mapy).

11 S t r o n a Świadczenie Usługi Serwisu Gwarancyjnego i gwarancji Minimalne wymagania na Usługi Serwisu Gwarancyjnego i gwarancji. Kod Opis funkcjonalności wymagania WUS.1 Wykonawca będzie przyjmował zgłoszenia o Incydentach serwisowych w trybie 24 godziny na dobę 7 dni w tygodniu. WUS.2 W celu zarządzania Incydentami serwisowymi Wykonawca zapewni system do obsługi Incydentów serwisowych, za pomocą którego dokonywane będą zgłoszenia Incydentów serwisowych, obsługa i monitorowanie Incydentów serwisowych (np. system oparty na komunikacji za pomocą poczty elektronicznej ze zgłaszającym Incydent serwisowy lub zakładający interakcję ze zgłaszającym Incydent serwisowy, za pomocą graficznego interfejsu użytkownika lub stanowiący połączenie obydwu ww. form). WUS.2.1 Wykonawca umożliwi także przyjęcie obsługę Incydentów serwisowych kierowanych faksem lub mailem na adres podany przez Wykonawcę. WUS.3 Wykonawca najpóźniej w 1 Dzień Roboczy, po rozwiązaniu Incydentu serwisowego przedstawi raport z tego Incydentu serwisowego (prezentujący, co najmniej czasy przyjęcia zgłoszenia o Incydencie serwisowym, czasie zaproponowania obejścia, jeśli takie zastosowano, oraz rozwiązania Incydentu serwisowego, a także przyczyny, sposoby rozwiązania i działania zapobiegające występowaniu Incydentu serwisowego). WUS.4 W przypadku zgłoszeń serwisowych niemieszczących się w zakresie świadczonych usług wynikających z niniejszego zamówienia, Wykonawca zobowiązany jest do przekierowania zgłoszenia serwisowego do odpowiedniego podmiotu na zasadach określonych przez Zamawiającego. WUS.5 Gwarancja na Modyfikacje biegnie od dnia podpisania Protokołu Odbioru Końcowego. WUS.6 Wykonawca dokona usunięcia Błędu Niekrytycznego w terminie nie dłuższym niż 24 godziny od momentu zgłoszenia Błędu Niekrytycznego (usunięcie Błędu Niekrytycznego rozumiane jest, jako przywrócenie funkcjonalności Modyfikacji Systemu sprzed Błędu Niekrytycznego). WUS.7 Wykonawca dokona usunięcia Błędu Zwykłego w terminie nie dłuższym niż 72 godziny od momentu zgłoszenia Błędu Zwykłego (usunięcie Błędu Zwykłego rozumiane jest, jako przywrócenie funkcjonalności Modyfikacji Systemu sprzed Błędu Zwykłego). WUS.8 Gwarancja obejmuje również wykonanie przez Wykonawcę wszelkich czynności związanych z przywróceniem pierwotnego stanu pracy Modyfikacji (sprzed Błędu) WUS.9 Wykonawca ponosi odpowiedzialność za poprawne funkcjonowanie Modyfikacji oraz funkcjonalności SWD PRM bezpośrednio od niej zależnych, w szczególności za zgodność działania wywołań funkcji objętych modyfikacją oraz zwracanych wyników i błędów ze stanem obecnym. 7 WYMAGANIA W ZAKRESIE DOKUMENTACJI Wykonawca w ramach realizacji przedmiotu zamówienia dostarczy dokumentację spełniającą wymagania określone w poniższej tabeli.

12 S t r o n a 12 Minimalne wymagania dla Dokumentacji. 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: Szczegółowy opis realizacji wymagań, Plan Testów Akceptacyjnych DOK Szczegółowy opis realizacji wymagań Wykonawca opracuje dokumentację przedstawiającą szczegółowy sposób spełnienia wszystkich wymagań niniejszego postępowania (w tym wykorzystywanych technologii do spełnienia wymagania). DOK.1.2 Dokumentację Powykonawczą, wytworzoną na podstawie dokumentacji powykonawczej SWD PRM dostarczonej przez Zamawiającego po podpisaniu Umowy i stanowiącą jego aktualizację. Dokumentacja Powykonawcza będzie zawierać, 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, Opis wymagań funkcjonalnych i pozafunkcjonalnych Modyfikacji Systemu, Specyfikację wymagań funkcjonalnych i pozafunkcjonalnych, Opis i specyfikację interfejsów Modyfikacji Systemu, Opis rozwiązania wydajności, skalowalności i niezawodności, Program przebiegu testów akceptacyjnych i sposób oszacowania niezawodności zaproponowanego rozwiązania, w tym propozycję raportów z testów, 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łowego utrzymania Modyfikacji Systemu, Dokumentację Użytkownika, jako modyfikację aktualnie dostępnych instrukcji użytkownika w zakresie wymaganym dla opisania

13 S t r o n a 13 użytkownikowi końcowemu działania Modyfikacji Systemu i właściwego postępowania w granicach objętych Modyfikacją, jeżeli Modyfikacja będzie miała wpływ na funkcjonalność Systemu widoczną dla użytkowników aplikacji, w szczególności należy uwzględnić zmiany w interfejsie użytkownika. 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, Zachowanie standardów Zamawiającego w zakresie oznaczeń dokumentów wersjonowania, metryk, 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 rozumiane, 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, podlega akceptacji Zamawiającego i zostanie dostarczona w języku polskim, w wersji elektronicznej w niezabezpieczonym/edytowalnym formacie MS Word i niezabezpieczonym formacie 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 Modyfikacji zostaną opisane i dostarczone przez Wykonawcę w wersji elektronicznej. Dostarczone kody źródłowe Modyfikacji 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. schematy, rysunki, topologie oraz wykresy, w formacie niezabezpieczonym i edytowalnym. DOK.3.3 Wymagane jest, aby w ramach Dokumentacji Wykonawca przekazał Zamawiającemu wszystkie dokumenty robocze wytworzone w trakcie realizacji niniejszego zamówienia, w szczególności analizy, arkusze kalkulacyjne, materiały

14 S t r o n a 14 robocze, w formacie elektronicznym, niezabezpieczonym i edytowalnym. DOK.3.4 DOK.3.5 Wszystkie Dokumenty przekazane w formie elektronicznej (pliki) muszą: być posegregowane w folderach odpowiadających nazwom produktów oraz nazwom, wersjom i podwersjom przekazywanego modułu (dotyczy kodów źródłowych), być posegregowane w folderach zgodnie ze strukturą Dokumentacji, posiadać nazwy plików (razem ze ścieżką) krótsze niż 200 znaków, W przypadku kolejnych wersji Dokumentacji wymagane jest, aby Wykonawca dostarczył elektroniczne wersje Dokumentacji, które zawierają wyróżnione różnice pomiędzy kolejnymi wersjami Dokumentacji (w trybie rejestracji zmian na zaakceptowanej treści wersji poprzedniej). 8 WYMAGANIA W ZAKRESIE DOSTĘPNOŚCI minimalne wymagania w zakresie dostępności. Kod wymagania WDSYS.1 Opis wymagania Zapewnienie architektury rozwiązania gwarantującej niezawodność Modyfikacji Systemu na poziomie SLA, nie mniej niż 99.9% (niedostępność w skali miesiąca 43m 49.7s) SLA liczone jest jako suma czasu trwania niedostępności Modyfikacji spowodowanej Błędami Krytycznymi, przy czym okna serwisowe związane z konserwacją/rekonfiguracją Modyfikacji 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). 9 WYMAGANIA W ZAKRESIE ZGODNOŚCI Z PRZEPISAMI PRAWA Minimalne wymagania w zakresie zgodności z przepisami prawa. Kod wymagania PR.1 Opis wymagania Rozwiązanie dla Modyfikacji Systemu musi być zgodne z niżej wymienionymi aktami prawnym: 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 r. (Dz. U. z 2016 r., poz. 113); Ustawa o informatyzacji działalności podmiotów realizujących zadania publiczne z dnia roku (tekst jednolity Dz. U. z 2014 r., poz. 1114); Ustawa z dnia 24 sierpnia 1991 r. o ochronie przeciwpożarowej (tekst jednolity Dz. U. z 2016 poz. 191);

15 S t r o n a 15 Ustawa z dnia 18 kwietnia 2002 r. o stanie klęski żywiołowej (jednolity tekst Dz. U. z 2014 r. poz. 333, z późn. zm.); Ustawa z dnia 16 lipca 2004 r. - Prawo telekomunikacyjne (tekst jednolity Dz. U. z 2014 r., poz. 243); Ustawa z dnia 8 września 2006 r. o Państwowym Ratownictwie Medycznym (tekst jednolity Dz. U. z 2013 r., poz. 757, z późn. zm.); Ustawa z dnia 26 kwietnia 2007 r. o zarządzaniu kryzysowym (tekst jednolity Dz. U.z 2013 r., poz. 1166); Ustawa z dnia 22 listopada 2013 r. o systemie powiadamiania ratunkowego (Dz. U. z 2013 poz.1635); 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żytkowników (dyrektywa o usłudze powszechnej) - Dz.U.UE.L 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 powiadamiania ratunkowego oraz punktów centralnych służb (Dz. U. z 2015 r. poz. 2356) 10 LISTA ZAŁĄCZNIKÓW Załącznik nr 1 Protokół transmisji danych GPS firmy Teltonika Załącznik nr 2 Protokół transmisji danych GPS firmy ENTE Załącznik nr 3 - Projekt Techniczny SWD PRM Załącznik nr 4 - Dokumentacja Powykonawcza SWD PRM Załącznik nr 5 - Baza Danych Model Danych SWD PRM Załącznik nr 6 Wzór PTA