OPIS PRZEDMIOTU ZAMÓWIENIA

Termin	Objaśnienie
AICC	(ang. Aviation Industry CTB Committee) - to międzynarodowe stowarzyszenie zrzeszające profesjonalistów tworzących systemy treningowe i edukacyjne dla przemysłu lotniczego, które opracowało standard o tej samej nazwie, określający sposób komunikacji między platformą LMS a kursem e-learningowym.
API	Application Programming Interface – interfejs programistyczny aplikacji. API pozwala na komunikowanie się aplikacji między sobą.
BLIK	System płatności mobilnych - umożliwia użytkownikom smartfonów dokonywanie płatności bezgotówkowych, wypłacanie i wpłacanie gotówki w bankomatach oraz dokonywanie przelewów i generowanie czeków z cyfrowym kodem. Kod BLIK to jednorazowy, 6-cyfrowy kod, generowany w aplikacji banku. Kod jest ważny przez 2 minuty.
BPEL	ang. Business Process Execution Language for Web Services – oparty na XML język do definiowania procesów biznesowych opartych o usługi sieciowe
BPMN	ang. Business Process Model and Notation – graficzna notacja służąca do opisywania procesów biznesowych.
BPMS	ang. Business Process Management System - system zarządzania procesami biznesowymi
CAD	ang. Computer-aided design - projektowanie wspomagane komputerowo
CMS	ang. Content Management System (system zarządzania treścią) - oprogramowanie pozwalające na łatwe utworzenie i prowadzenie serwisu www, a także jego późniejszą aktualizację i rozbudowę, również przez redakcyjny personel nietechniczny
CSW	ang. Catalogue Service for the Web - katalog usług sieciowych
e-usługi	Usługi e-administracji świadczone drogą elektroniczną przez sieć Internet o poziomie dojrzałości od i do V.

Termin	Objaśnienie
e-learning	(ang. learning – dosł. uczenie się, w języku polskim wymiennie tłumaczone również jako nauczanie, „e”- w tym wypadku skrót od „elektroniczne”) – nazywane także nauczaniem lub kształceniem na odległość, to wszelkie formy wspomagania i prowadzenia procesu dydaktycznego, które nie wymagają bezpośredniego kontaktu uczącego się z osobą uczącą, wykorzystujące technologie informacyjne i komunikacyjne (ICT).
Ekran (jako jednostka w e- learningu)	Treść szkolenia wyświetlana na ekranie monitora jako jeden „slajd”, którą widzi uczący się.
ESB	ang. Enterprise Service Bus - korporacyjna magistrala usług
ET	Etap Techniczny
EZ	Etap Zarządczy
FAQ	(ang. Frequently Asked Questions) – zbiór najczęściej zadawanych pytań i udzielanych na nie odpowiedzi.
GIS	ang. Geographic Information System (system informacji geograficznej) – system informacyjny służący do wprowadzania, gromadzenia, przetwarzania oraz wizualizacji danych geograficznych
Godzina	Jednostka miary czasu odpowiadająca równym sześćdziesięciu minutom również poza godzinami roboczymi Zamawiającego.
Godzina robocza/Roboczogodzina	Okres trwający godzinę zegarową w ramach Godziny pracy Zamawiającego.
Godziny pracy Zamawiającego	Od 7 do 17, od poniedziałku do piątku, z wyłączeniem dni ustawowo wolnych od pracy.
GUI	ang. Graphical User Interface - graficzny interfejs użytkownika
ISO	Z ang. International Organization for Standardization - Międzynarodowa Organizacja Normalizacyjna.
ISOK	Informatyczny System Osłony Kraju - narzędzie analizy i ostrzegania przed groźnymi zjawiskami, w szczególności

Termin	Objaśnienie
	meteorologicznymi i hydrologicznymi. ISOK stanowi narzędzie zarządzania kryzysowego w całym kraju, jest narzędziem szczególnie dla instytucji odpowiedzialnych za ochronę obszarów zagrożonych powodzią.
IT-GIS OKI	Aplikacja wspomagająca pracę PGW WP w zakresie zarządzania ryzykiem powodziowym.
JSON	JavaScript Object Notation – lekki format wymiany danych komputerowych. JSON jest formatem tekstowym, bazującym na podzbiorze języka JavaScript.
KML	ang. Keyhole Markup Language - język znaczników oparty na XML- u
Kod źródłowy	Słowniki, skrypty, definicje, pliki źródłowe bazy danych, jak również biblioteki, algorytmy oraz jakiekolwiek inne symboliczne lub konwencjonalne przedstawienie zapisu informacji, niezbędne do kompilacji, wykonania i utrzymania, funkcjonowania i utrzymania Systemu, z wyłączeniem Oprogramowania standardowego.
Kurs e-learningowy	Elektroniczny zasób treści wyposażony w elementy nawigacyjne z celowo zorganizowanymi warunkami edukacyjnymi, które umożliwiają osobom uczącym się samodzielne nabycie wiedzy i umiejętności dotyczących określonego zagadnienia czy też obszaru tematycznego.
KZGW	Krajowy Zarząd Gospodarki Wodnej
Layout	Układ graficzny elementów treści na wyświetlanym ekranie. Może to być kompozycja grafiki, tekstu, animacji itd.
Link	Odnośnik umieszczony na ekranie kursu, umożliwiający po kliknięciu przeniesienie do innego miejsca w Internecie.
MTOM	ang. Message Transmission Optimization Method (metoda optymalizacji przekazu informacji) – mechanizm efektywnego przekazywania danych binarnych z wykorzystaniem usług sieciowych (Web services)

Termin	Objaśnienie
NW	Nadzór Wodny
OGC	ang. Open Geospatial Consortium; międzynarodowa organizacja typu non-profit, zrzeszająca ponad 450 firm, agencji rządowych i uniwersytetów, współpracujących nad rozwijaniem i implementacją otwartych standardów dla danych i usług przestrzennych, systemów informacji geograficznej (GIS) do celów przetwarzania danych i ich udostępniania.
Okres trwałości Projektu	Okres 5 lat, w którym należy utrzymać cele, wskaźniki Produktu oraz rezultaty Projektu określone we wniosku o dofinansowanie, liczony od daty zatwierdzenia ostatniego wniosku o płatność, zgodnie z Porozumieniem o dofinansowanie Projektu.
Oprogramowanie dedykowane	Oprogramowanie tworzone ( poprzez zaprojektowanie algorytmu i przygotowanie kodu źródłowego celu dostarczenia określonych funkcjonalności ) przez Wykonawcę lub osoby którymi się posługuje w wykonaniu zobowiązań wynikających z Umowy, w tym rozbudowa lub modyfikacja Oprogramowania Standardowego.
Oprogramowanie standardowe	Oprogramowanie Standardowe - Oprogramowanie dostępne powszechnie na zasadach komercyjnych lub niekomercyjnych gotowe do wykorzystania przed rozpoczęciem prac związanych z realizacją przedmiotu zamówienia. w kontekście niniejszego Zamówienia za oprogramowanie standardowe uznaje się oprogramowanie: wytwarzane seryjnie, gotowe do sprzedaży lub udostępniane na zasadach licencji, o dojrzałej i czytelnej dokumentacji technicznej, o dostępnych usługach szkoleniowych, dostępne na rynku w wersji COTS (commercial off-the-shelf) przynajmniej od 8 lat, a w oferowanej wersji co najmniej rok, posiadające minimum 3 wdrożenia. Oprogramowanie musi być wdrażane i serwisowane w modelu umożliwiającym realizację projektów wdrożeniowych przez co najmniej pięciu partnerów autoryzowanych przez producenta, niezależnych kapitałowo od siebie i od producenta danego oprogramowania.
OPZ	Niniejszy dokument tj. Opis Przedmiotu Zamówienia.

Termin	Objaśnienie
OWASP	ang. Open Web Application Security Project - społeczność internetowa, która tworzy ogólnodostępne artykuły, metodologie, dokumentację, narzędzia i technologie z zakresu bezpieczeństwa aplikacji internetowych
Personel kluczowy	Personel Wykonawcy wskazany do realizacji Umowy w formularzu ofertowym w Załączniku nr 6 do SWZ (Wykaz osób).
Platforma/Infrastruktura teleinformatyczna	Platforma to zarówno infrastruktura sprzętowa (np. serwery fizyczne, routery, przełączniki, macierze dyskowe, repeatery, interfejsy: LAN, WAN i SAN) jak i infrastruktura oprogramowania stanowiąca środowisko uruchomieniowe dla oprogramowania dedykowanego (tj. środowiska wirtualne (np. wirtualny serwer), systemy operacyjne, środowiska uruchomieniowe standardowe np. JVM (Java Virtual Machine) czy silniki bazodanowe, relacyjne (RDBMS), jak i nierelacyjne (NoSQL), szyny usług, serwery kolejek i inne określane mianem oprogramowania standardowego integracyjnego (ang. middleware)). Pojęcie Platformy/Infrastruktury teleinformatycznej nie obejmuje Urządzeń mobilnych.
Platforma e-learningowa	Środowisko informatyczne, w którym realizowany jest kurs e- learningowy. Umożliwia definiowanie i tworzenie zasobów dydaktycznych (zwanych także materiałem dydaktycznym), które przechowywane są w bazach danych i opisywane przez edukacyjne metadane.
POPC	Program Operacyjny Polska Cyfrowa
Produkt	Produkt zarządczy lub specjalistyczny rozumiany w myśl metodyki PRINCE2, który ma być dostarczony przez Wykonawcę w ramach realizacji Przedmiotu Zamówienia zgodnie z SWZ, w szczególności sprzęt, oprogramowanie, dokumentacja powdrożeniowa, a także wszelkie materiały i informacje, w tym nie podlegające ochronie prawa autorskiego, stworzone lub opracowane przez Wykonawcę i dostarczone Zamawiającemu w ramach realizacji Przedmiotu Zamówienia utwory.
Projekt/Projekt WIR	Projekt pn. „Wirtualny Informator Rzeczny (WIR)”

Termin	Objaśnienie
Przedmiot Zamówienia/Przedmiot Umowy/Zamówienie	Zobowiązanie Wykonawcy wynikające z niniejszego OPZ i SWZ
Repozytorium analityczne	Repozytorium, które pozwala na przechowywanie i wersjonowanie zamodelowanych systemów za pomocą różnych notacji, w tym języka UML.
Repozytorium kodu	Repozytorium, które pozwala x.xx. na przechowywanie kodów źródłowych i realizację procesów automatyzacji i wdrażania usług IT.
Repozytorium wersji oprogramowania	System kontroli wersji, oprogramowanie służące do śledzenia zmian w kodzie źródłowym oraz pomocy programistom w łączeniu zmian dokonanych w plikach przez wiele osób w różnym czasie
REST	ang. Representational State Transfer (zmiana stanu poprzez reprezentacje) - styl architektury oprogramowania wywiedziony z doświadczeń przy pisaniu specyfikacji protokołu HTTP dla systemów rozproszonych. REST wykorzystuje x.xx. jednorodny interfejs, bezstanową komunikację, zasoby, reprezentacje, hipermedia, HATEOAS.
RIS	System Informacji Rzecznej - system zarządzania, który służy gromadzeniu, przetwarzaniu i przekazywaniu danych dotyczących x.xx. stanu wód, prognozy pogody oraz statków znajdujących się w obszarze jego działania.
RZGW	Regionalny Zarząd Gospodarki Wodnej
SCORM	(ang. Sharable Content Object Reference Model) – standard (specyfikacja) zapisu danych do e-learningu. Przedstawia sposób komunikacji pomiędzy klientem oraz serwerem. SCORM definiuje również w jaki sposób powinny być skompresowane dane do prezentacji (format ZIP). Wykorzystuje technologię XML.
Serwer	Dedykowane środowisko sprzętowo-programowe.
Serwerownia	(ang. computer room) - pomieszczenie przeznaczone do pracy sprzętu serwerowego (serwery, macierze dyskowe itp.)

Termin	Objaśnienie
	i sieciowego (przełączniki, routery itp.) oraz zapewniającym odpowiednie warunki fizyczne i środowiskowe dla sprzętu.
SIGW	System Informatyczny Gospodarki Wodnej
SWZ	Specyfikacja Warunków Zamówienia
SOAP	ang. Simple Object Access Protocol - protokół komunikacyjny wykorzystujący XML do kodowania wywołań i najczęściej protokół HTTP do ich przenoszenia.
Xxxxxx	Xxxxxxxxxxx oraz Wykonawca
System/System WIR	Budowany w ramach niniejszego Zamówienia System WIR.
Szybki przelew bankowy	Rodzaj przelewu bankowego, nazywany również przelewem natychmiastowym lub ekspresowym, który jest szczególnym przykładem przelewu bankowego, charakteryzującym się krótkim czasem realizacji. w przypadku szybkich przelewów pieniądze docierają na rachunek odbiorcy w maksymalnie kilka czy kilkanaście minut.
TOGAF	ang. The Open Group Architecture Framework – szkielet dla architektury korporacyjnej, który zapewnia kompleksowe podejście do projektowania, planowania, implementacji oraz zarządzania informacyjną architekturą organizacji
UML	ang. Unified Modeling Language (zunifikowany język modelowania) – język pół-formalny wykorzystywany do modelowania różnego rodzaju systemów
Umowa	Umowa pomiędzy Wykonawcą Przedmiotu Zamówienia, a Zamawiającym zawarta w wyniku postępowanie przetargowego.
Urządzenia mobilne (tablety)	Urządzenia przenośne, posiadające wbudowany dotykowy wyświetlacz, nieposiadający fizycznej klawiatury.
Wykonawca	Strona Umowy, Podmiot realizujący Przedmiot Zamówienia

Termin	Objaśnienie
XML	ang. Extensible Markup Language (rozszerzalny język znaczników) – uniwersalny język znaczników przeznaczony do reprezentowania różnych danych w ustrukturalizowany sposób
Zamawiający/ WP/ PGW WP/Wody Polskie	Państwowe Gospodarstwo Wodne Wody Polskie
Zlecenie	Pisemne uzgodnienie warunków wykonania przez Wykonawcę usługi dodatkowych modyfikacji, określające w szczególności zakres czynności do wykonania których zobowiązuje się Wykonawca, wykaz Produktów wytworzonych w ramach Zlecenia, termin wykonania Zlecenia oraz wynagrodzenie Wykonawcy.
ZZ	Zarząd Zlewni

WPROWADZENIE

Niniejszy dokument przedstawia Opis Przedmiotu Zamówienia „Zaprojektowania, budowy, wdrożenia i utrzymania Wirtualnego Informatora Rzecznego” realizowanego w ramach projektu pn. „Wirtualny Informator Rzeczny (WIR)”, jako narzędzia zwiększenia dostępności i jakości e-usług publicznych. Projekt WIR współfinansowany jest przez Unię Europejską ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Polska Cyfrowa.

PRZEDMIOT ZAMÓWIENIA

Przedmiotem Zamówienia jest wykonanie następujących Zadań:

1. Opracowanie Planu Realizacji Umowy zgodnie z rozdziałem 10.1 Organizacja realizacji Umowy

2. Przeprowadzenie analizy dla Systemu WIR, w szczególności:

a. Opracowanie Dokumentacji Analitycznej w zakresie odpowiadającym Etapom Zarządczym,

b. Opracowanie Dokumentacji Technicznej w zakresie odpowiadającym Etapom Zarządczym,

c. Opracowanie Prototypu Graficznego Interfejsu użytkownika,

d. Przeprowadzenie badań preferencji użytkowników.

3. Udostępnienie Zamawiającemu Narzędzia wspomagającego proces wytwórczy,

4. Budowa Systemu WIR spełniającego wymagania funkcjonalne i niefunkcjonalne określone w niniejszym OPZ oraz Załączniku nr 1 do OPZ, przy spełnieniu wymagań dla procesu wytwórczego,

5. Dostarczenie wymaganych elementów Infrastruktury teleinformatycznej zgodnie z OPZoraz

oraz Załącznikiem nr 2 do OPZ,

6. Przeprowadzenie migracji danych niezbędnych do prawidłowego działania Systemu WIR,

w szczególności danych wymienionych w Załączniku nr 3,

7. Uzgodnienie i przeprowadzenie integracji Systemu WIR z systemami zewnętrznymi w zakresie niezbędnym dla prawidłowego działania Systemu WIR zgodnie z wymaganiami określonymi w OPZ oraz Załączniku nr 1 oraz nr 3 do OPZ,

8. Instalacja i konfiguracja Systemu WIR,

9. Przeprowadzenie testów wewnętrznych i akceptacyjnych, w tym przeprowadzenie audytu dostępności oraz uwzględnienie i implementacja uwag z testów bezpieczeństwa przeprowadzonych przez podmiot trzeci,

10. Stabilizacja Systemu WIR,

11. Przeprowadzenie szkoleń,

12. Świadczenie usług dodatkowych modyfikacji w ramach zamówienia podstawowego,

13. Produkcyjne uruchomienie Systemu WIR,

14. Dostarczenie wymaganej w OPZ i Umowie dokumentacji projektowej,

15. Świadczenie usług gwarancyjnych Systemu, Infrastruktury teleinformatycznej oraz Urządzeń

mobilnych,

16. Świadczenie usług utrzymania i administracji Systemu i Infrastruktury teleinformatycznej,

17. Przekazanie utrzymania Systemu i Infrastruktury teleinformatycznej.

Dodatkowo Zamawiający przewiduje prawo opcji co do usług dodatkowych modyfikacji oraz usług gwarancyjnych oraz usług utrzymania i administracji Systemu i Infrastruktury teleinformatycznej.

OGÓLNY OPIS SYSTEMU WIR

System Wirtualny Informator Rzeczny (WIR) stanowi odpowiedź na potrzeby zgłaszane przez obywateli oraz przedsiębiorców w zakresie poprawy jakości i efektywności usług świadczonych przez Państwowe Gospodarstwo Wodne Wody Polskie w obszarze korzystania ze śródlądowych dróg wodnych.

Mając na uwadze zapotrzebowanie użytkowników, System WIR będzie składał się z dwóch narzędzi:

System informatyczny Wirtualny Informator Rzeczny (WIR),

1. stanowiący centralny punkt dostępu do danych oraz procesów związanych ze śródlądowymi drogami wodnymi, który w szczególności:

a. udostępni w ujednoliconej formie aktualne informacje i komunikaty dotyczące wszystkich dróg wodnych w Polsce,

b. udostępni narzędzia ułatwiające planowanie oraz odbywanie rejsu, dostosowane do potrzeb użytkownika,

c. ułatwi rozliczanie opłat za korzystanie z dróg wodnych, śluz i pochylni,

d. podniesie poziom bezpieczeństwa żeglugi oraz bezpieczeństwa publicznego,

e. umożliwi gromadzenie, zarządzanie oraz przetwarzanie danych związanych

z obsługą żeglugi śródlądowej.

2. Aplikacja mobilna Wirtualny Informator Rzeczny (WIR), która umożliwi w szczególności:

a. dostęp do danych systemu WIR,

b. planowanie trasy rejsu,

c. odbieranie powiadomień/ostrzeżeń z Systemu WIR,

d. kanał komunikacji pomiędzy administratorem drogi wodnej a użytkownikami,

e. dokonywanie płatności za śluzowanie lub przejście przez pochylnię,

f. automatyzację procesu zbierania danych na potrzeby uzupełnienia deklaracji, na podstawie której ustala się wysokość należności za korzystanie ze śródlądowych dróg wodnych

g. zgłaszanie nieprawidłowości i niebezpieczeństw napotkanych na drodze wodnej.

System WIR będzie zaprojektowany zgodnie z modelem architektury zorientowanej na usługi (ang. Service-Oriented Architecture) i wykonany będzie w architekturze trójwarstwowej, pozwalającej na odseparowanie warstw danych, logiki biznesowej oraz prezentacji.

System WIR będzie miał budowę modułową a „sercem systemu” będzie komponent integracyjny, zapewniający wymianę danych zarówno pomiędzy modułami dziedzinowymi jak i systemami zewnętrznymi. Moduły i komponenty zbudowane zostaną w oparciu o architekturę mikroserwisową.

Interfejsy zapewniające wymianę danych z systemami zewnętrznymi będą zrealizowane jako usługi

sieciowe (Web service).

Interfejsy użytkownika będą uwzględniać zasady uniwersalnego projektowania oraz międzynarodowy standard w dziedzinie dostępności - Web Content Accessibility Guidelines 2.1 (WCAG 2.1).

System będzie preferował rozwiązania o otwartym kodzie (Open Source), które zapewnią niski poziom kosztów utrzymania systemu.

Potencjalnymi odbiorcami Systemu WIR będą osoby i podmioty gospodarcze korzystające ze śródlądowych dróg wodnych. Do grona odbiorców projektu zaliczyć należy również administratora śródlądowych dróg wodnych, tj. Państwowe Gospodarstwo Wodne Wody Polskie oraz inne instytucje publiczne mogące w przyszłości wykorzystywać dane udostępniane za pośrednictwem Systemu WIR.

TERMINY REALIZACJI PRAC

W niniejszym rozdziale opisano terminy realizacji Przedmiotu Zamówienia wraz z podziałem na etapy zarządcze oraz etapy techniczne, określające ich zakres.

Wymagane terminy realizacji Przedmiotu Zamówienia:

1. Rozpoczęcie prac następuje w chwili zawarcia Umowy pomiędzy Zamawiającym, a Wykonawcą.

2. Przedmiot Zamówienia musi zostać zrealizowany w terminach określonych Umową.

3. Dostarczane w ramach Przedmiotu Zamówienia Produkty muszą zostać odebrane w terminach określonym w poniższej tabeli, w kolumnie „Termin zakończenia” w ramach etapów technicznych w których zakres wchodzą, z uwzględnieniem terminów związanych z procedurami odbiorów produktów.

4. Warunkiem rozpoczęcia prac danego Etapu Zarządczego jest odbiór wszystkich Produktów poprzedniego Etapu Zarządczego, z wyłączeniem Etapu Zarządczego 1, który rozpoczyna się w z chwilą podpisania Umowy.

5. Dostawa Infrastruktury teleinformatycznej oraz uruchomienie środowiska testowego powinno się odbyć przed datą 30.07.2022 (nie dotyczy Urządzeń mobilnych).

6. Ogólny harmonogram realizacji prac zawiera Tabela 1 Terminy realizacji prac.

Tabela 1 Terminy realizacji prac

Etap Techniczny	Zakres Etapu	Termin rozpoczęcia	Termin zakończenia
Etap Zarządczy 1 – Organizacja realizacji Umowy
Etap Techniczny 1	Udostępnienie Narzędzia wspierającego proces wytwórczy. Opracowanie Planu Realizacji Umowy.	Podpisanie Umowy	30 dni od podpisania Umowy
Etap Techniczny 2	Przeprowadzenie wstępnej analizy rozwiązania. Opracowanie Dokumentacji Analitycznej w zakresie odpowiadającym EZ1 (Dokumentacja Analityczna EZ1), określonym w rozdziale 11.2. Opracowanie Prototypu Graficznego Interfejsu. Przeprowadzenie badań użyteczności dla Prototypu Graficznego Interfejsu, określonym w rozdziale 10.2.3.	Podpisanie Umowy	29.01.2022

	Opracowanie Dokumentacji Technicznej w zakresie odpowiadającym EZ1 (Dokumentacja Techniczna EZ1), określonym w rozdziale 11.3. Opracowanie Planu dostawy infrastruktury. Opracowanie Planu Etapu Zarządczego 2.
Etap Zarządczy 2 – Budowa Systemu WIR zgodnie z wymaganiami dla rozwiązania oraz dostarczenie wymaganych elementów Infrastruktury teleinformatycznej
Etap Techniczny 3	Cykliczna praca w sprintach nad budową Systemu WIR. Aktualizacja Dokumentacji Analitycznej i Dokumentacji Technicznej w zakresie odpowiadającym EZ2. Dostawa i odbiór Infrastruktury teleinformatycznej (nie dotyczy Urządzeń mobilnych). Uruchomienie środowiska testowego. Opracowanie Planu Testów Akceptacyjnych. Uruchomienie środowiska produkcyjnego. Przeprowadzenie testów wewnętrznych. Opracowanie Raportu z testów wewnętrznych. Opracowanie Planu Etapu Zarządczego 3.	30.01.2022	29.11.2022
Etap Techniczny 4	Dostawa Urządzeń mobilnych.	01.11.2022	29.11.2022
Etap Zarządczy 3 – Uwzględnienie wyników audytu bezpieczeństwa, przeprowadzenie szkoleń, uruchomienie produkcyjne Systemu WIR
Etap Techniczny 5	Przeprowadzenie testów akceptacyjnych Systemu WIR, w tym testów funkcjonalnych i pozafunkcjonalnych (integracji, bezpieczeństwa, wydajnościowych). Testy bezpieczeństwa.	30.11.2022	31.03.2023


Etap Techniczny 6	Stabilizacja systemu. Opracowanie materiałów szkoleniowych i przeprowadzenie szkoleń. Dostarczenie dokumentacji powykonawczej.	30.11.2022	01.07.2023
Etap Techniczny 7	Wdrożenie produkcyjne i odbiór Systemu WIR. Udostępnienie produkcyjne Systemu WIR.	01.07.2023	01.08.2023
Świadczenie usług w zakresie gwarancji i utrzymania wdrożonych rozwiązań oraz usług dodatkowych modyfikacji (opcja)
n/d	Świadczenie usług gwarancyjnych w okresie 3 lat po odebraniu EZ3. Świadczenie usług utrzymania i administracji Systemu i Infrastruktury teleinformatycznej w okresie 3 lat po odebraniu EZ3. Przekazanie miesięcznych raportów dotyczących interwencji gwarancyjnych oraz świadczenia usług utrzymania i administracji. Udostępnienie narzędzia do monitorowania dostępności Systemu. Rozmieszczenie i konfiguracja środowiska TEST_ROZWOJ. Świadczenie usług dodatkowych modyfikacji (opcja).	Podpisanie protokołu odbioru Wdrożenia Produkcyjne go Systemu i uruchomien ie systemu w wersji produkcyjnej	3 lata od odbioru EZ3 10 000 roboczogodzin w przypadku usług dodatkowych modyfikacji.

PRODUKTY ZAMÓWIENIA

Wykaz wymaganych do dostarczenia Produktów przedstawia Tabela 2 Produkty Zamówienia.

Wykonawca zobowiązany jest do dostarczenia Produktów we wskazanych w Tabeli Etapach

Zarządczych i Technicznych, przy zachowaniu wskazanych zależności pomiędzy produktami.

Przekazanie Produktu do weryfikacji Zamawiającego może nastąpić wyłącznie po odbiorze Produktów, od których jest zależny dany Produkt. Przekazanie do weryfikacji Produktu może nastąpić wyłącznie po odbiorze wszystkich produktów poprzedniego Etapu Zarządczego.

Tabela 2 Produkty Zamówienia

EZ/ET	ID Produktu	Nazwa Produktu	Rodzaj produktu	Zależy od
EZ1/ET1	E1.NWP	Dostęp do Narzędzia wspierającego proces wytwórczy, potwierdzony Raportem z przekazania dostępów	Usługa	n/d
EZ1/ET1	X0.XXX	Plan Realizacji Umowy	Dokumentacja	n/d
EZ1/ET2	E1.DA	Dokumentacja Analityczna EZ1	Dokumentacja	X0.XXX
EZ1/ET2	E1.SBU	Specyfikacja badania użyteczności Prototypu Interfejsu Graficznego wraz z propozycjami Prototypów Interfejsu Graficznego	Dokumentacja	X0.XXX
EZ1/ET2	E1.BU	Badanie użyteczności potwierdzone Raportem z badania Prototypu Interfejsu Graficznego	Usługa/ Dokumentacja	E1.SBU
EZ1/ET2	E1.PIG	Prototyp Interfejsu Graficznego	Dokumentacja	E1.BU
EZ1/ET2	E1.DT	Dokumentacja Techniczna EZ1	Dokumentacja	X0.XXX

EZ1/ET2	E1.PDI	Plan dostawy infrastruktury	Dokumentacja	X0.XXX
EZ1/ET2	E1.PE2	Plan Etapu 2	Dokumentacja	X0.XXX
EZ2/ET3	X0.XX	Infrastruktura teleinformatyczna dla Systemu WIR (nie dotyczy Urządzeń mobilnych)	Sprzęt	E1.PDI
EZ2/ET3	E2.DA(n)	Dokumentacja Analityczna dla n-tego cyklu wytwórczego	Dokumentacja	E1.DA, E2.DA(n-1)
EZ2/ET3	E2.DT(n)	Dokumentacja Techniczna dla n-tego cyklu wytwórczego (opcjonalnie w zależności od zakresu funkcjonalnego danego sprintu)	Dokumentacja	E1.DT, E2.DT(n-1)
EZ2/ET3	E2.PWT	Plan Instalacji Oprogramowania dla środowiska testowego	Dokumentacja	X0.XX
EZ2/ET3	E2.RWT	Raport wdrożenia dla środowiska testowego	Dokumentacja	E2.PWT
EZ2/ET3	E2.PWP	Plan Instalacji Oprogramowania dla środowiska produkcyjnego	Dokumentacja	X0.XX, X0.XXX
EZ2/ET3	E2.RWP	Raport wdrożenia dla środowiska produkcyjnego	Dokumentacja	E2.PWP
EZ2/ET3	E2.PTA	Plan Testów Akceptacyjnych	Dokumentacja	Kompletna Dokumentacja Analityczna oraz Techniczna obejmująca pełen zakres

				funkcjonalny Systemu WIR
EZ2/ET3	E2.RTW	Raport z testów wewnętrznych	Dokumentacja	E2.RWP, E2.PTA
EZ2/ET3	E2.PE3	Plan Etapu 3	Dokumentacja	E2.RTW
EZ2/ET4	X0.XX	Urządzenia mobilne (Tablety)	Sprzęt	E1.PDI X0.XX
EZ3/ET5	X0.XX	Audyt dostępności potwierdzony Raportem z audytu dostępności	Usługa	Pozytywny wynik testów UAT
EZ3/ET6	E3.DUW	Dokumentacja Użytkownika Wewnętrznego	Dokumentacja	Pozytywny wynik testów akceptacyjnych
EZ3/ET6	E3.DUZ	Dokumentacja Użytkownika Zewnętrznego	Dokumentacja	Pozytywny wynik testów akceptacyjnych
EZ3/ET6	E3.DA	Dokumentacja Administratora	Dokumentacja	Pozytywny wynik testów akceptacyjnych
EZ3/ET6	X0.XX	Plan szkoleń wraz z Podręcznikiem szkoleniowym	Dokumentacja	E2.PE3
EZ3/ET6	X0.XX	Kursy e-learningowe wraz z Filmami instruktażowymi	Materiały multimedialne	X0.XX
EZ3/ET6	X0.XX	Szkolenia dot. Systemu WIR potwierdzone Raportem ze szkoleń	Szkolenie	X0.XX


EZ3/ET6	E3.RTA	Raport z testów akceptacyjnych (wydajnościowe, integracyjne, akceptacyjne użytkownika)	Dokumentacja	E2.PTA
EZ3/ET6	X0.XX	Stabilizacja Systemu zakończona potwierdzonym Raportem z wykrytych i naprawionych błędów	Usługa	Pozytywny wynik testów akceptacyjnych
EZ3/ET7	E3.DP	Dokumentacja Powykonawcza	Dokumentacja	E3.DUW, E3.DUZ, E3.DA
EZ3/ET7	n/d	System WIR	Oprogramowa nie	Wszystkie wcześniej wymienione Produkty
EZ3/ET7	n/d	Raport z realizacji wdrożenia	Dokumentacja	Wszystkie wcześniej wymienione Produkty
EZ3/ET7	n/d	Raport końcowy z realizacji umowy	Dokumentacja	Wszystkie wcześniej wymienione Produkty

WARUNKI ORGANIZACYJNE REALIZACJI PRZEDMIOTU ZAMÓWIENIA

Miejsce realizacji Projektu

Projekt realizowany jest na terenie całego kraju, zgodnie z podziałem administracyjnym PGW WP. System WIR będzie gromadził i udostępniał informacje na temat wszystkich dróg wodnych na terenie całego kraju.

Wdrożenie nowych rozwiązań w postaci systemu informatycznego i aplikacji mobilnej Wirtualny Informator Rzeczny, będzie wymagało użycia Infrastruktury teleinformatycznej, na której systemy zostaną zainstalowane, uruchomione i udostępnione użytkownikom. Zamawiający jako podmiot powołany do życia z początkiem 2018 r., w zakresie infrastruktury sprzętowej nie dysponuje wolnymi zasobami, których mógłby użyć do realizacji projektu. Infrastruktura teleinformatyczna zostanie dostarczona w ramach niniejszego Zamówienia. Instalacja Systemu zostanie przeprowadzona w lokalizacjach wskazanych przez Zamawiającego. PGW WP planują wykorzystać dwie lokalizacje serwerowni, w celu umiejscowienia w nich Infrastruktury teleinformatycznej, która będzie obsługiwała system WIR.

Organizacja Umowy

Umowa będzie zarządzana zgodnie z metodyką wytwórczą PRINCE2 Agile. w celu realizacji Projektu

została powołana struktura organizacyjna.

Wykonawca, w ramach realizacji metodyki PRINCE2 Agile, zobowiązany jest do stosowania ram zarządzania realizacją umowy zgodnych z PRINCE2, przy jednoczesnym zastosowaniu zwinnego podejścia do wytwarzania produktów Przedmiotu Zamówienia, w szczególności oprogramowania.

Wykonawca podczas realizacji Przedmiotu Zamówienia zobowiązany będzie do realizacji działań zarządczych, które muszą być zgodne z zapisami niniejszego OPZ. Wykonawca przygotuje produkty zarządcze (opisane w rozdziale 11.1), w tym Plan Realizacji Umowy, który pozwoli zainicjować i zarządzać realizacją Umowy.

Realizacja Umowy jest podzielona na Etapy Zarządcze, które zawierają zbiór działań zmierzających do stworzenia wybranych Produktów, w danym odcinku czasowym. Etapy Zarządcze zostały podzielone na Etapy Techniczne dostosowane do wytwarzanych Produktów.

Przed rozpoczęciem każdego Etapu Zarządczego (z wyjątkiem Etapu Zarządczego nr 1) Wykonawca opracuje Plan Etapu Zarządczego, który będzie uszczegółowiał przygotowany przez niego wcześniej Plan Realizacji Umowy. Plan Etapu będzie zawierał szczegółowe plany prac nad wytworzeniem Produktów w danym Etapie Zarządczym. Każdy z Planów Etapu będzie podlegał akceptacji Zamawiającego.

Sterowanie i kontrola postępów prac realizowana będzie poprzez:

1. weryfikację postępu prac zgodnie z przyjętym harmonogramem,

2. cykliczne przeglądy wytwarzanych przyrostów, mające na celu przedstawienie postępu prac i potwierdzenie przez Zamawiającego, że są one realizowane zgodnie z określonym w trakcie analizy zakresem,

3. testy rozwiązania.

Prace w ramach realizacji Umowy odbywać się będą w ścisłej współpracy zespołów Wykonawcy i Zamawiającego. w szczególności organizowane będą cykliczne spotkania statusowe Wykonawcy z Zamawiającym. Spotkania odbywać się będą w siedzibie Zamawiającego lub zdalnie ( z wykorzystaniem platformy Microsoft Teams) po uprzednim uzgodnieniu formy spotkania. Częstotliwość spotkań statusowych zostanie ustalona w Planie Realizacji Umowy.

Celem spotkań statusowych będzie bieżące informowanie Zamawiającego o postępach lub problemach w projekcie i podejmowanie ustaleń w celu rozwiązywania ewentualnych problemów. Poprzez spotkania statusowe możliwe będzie bieżące monitorowanie postępów realizacji harmonogramu. Możliwe będzie również zgłaszanie i omawianie problemów zidentyfikowanych podczas przeglądów.

Pozostałe kontakty operacyjne Zamawiającego z Wykonawcą będą odbywać się przy użyciu dedykowanych spotkań stacjonarnych lub on – line przy użyciu platformy Microsoft Teams, komunikacji przy użyciu poczty elektronicznej oraz telefonicznej.

Ustalenia ze spotkań bezpośrednich, telekonferencji oraz wideokonferencji będą utrwalane w formie

notatek/podsumowań ze spotkań opracowywanych przez Wykonawcę na wskazanie Zamawiającego.

Budowa oprogramowania będzie realizowana przyrostowo. Szczegółowy sposób realizacji wymagań uzgadniany i potwierdzany będzie z Zamawiającym przy udziale użytkowników końcowych Systemu WIR, przy wykorzystaniu opracowanych przez Wykonawcę makiet Systemu. Całkowity zakres prac zostanie podzielony na następujące po sobie cykle realizacyjne (zwane również „sprintami”) o maksymalnej długości 5 tygodni. Planowany podział prac związanych z budową Systemu WIR na sprinty powinien uwzględniać równomierny przyrost funkcjonalności w poszczególnych cyklach realizacyjnych.

Zarządzanie zakresem Przedmiotu Zamówienia oraz śledzenie postępów prac będzie realizowane przy użyciu Narzędzia wspomagającego proces wytwórczy, które Wykonawca udostępni Zamawiającemu.

Narzędzie wspomagające proces wytwórczy, będzie umożliwiało co najmniej:

1. zarządzanie użytkownikami i rolami,

2. uwierzytelnianie użytkowników w interfejsie graficznym za pomocą loginu i hasła użytkownika,

3. autoryzację użytkowników zgodnie z przyznanymi uprawnieniami,

4. prowadzenie katalogu wymagań dla Systemu WIR, co najmniej w zakresie określonym

w rozdziale 11.2 Dokumentacja Analityczna,

5. dokonywanie analiz na podstawie opisanych atrybutów, w tym w szczególności powadzenie uzgodnień dotyczących sposobu realizacji wymagań,

6. akceptację sposobu realizacji poszczególnych wymagań,

7. zarządzanie statusem realizacji poszczególnych wymagań dla Systemu WIR (np. w trakcie analizy, powtórna weryfikacja, zatwierdzone, zawieszone, anulowane, w procesie wytwórczym, do przeglądu, do testów UAT). Lista statusów oraz szczegółowy workflow zostanie ustalony z Zamawiającym po podpisaniu Umowy,

8. bieżącą współpracę Zamawiającego oraz Wykonawcy, w szczególności w zakresie aktywności

takich jak:

1) informowania Zamawiającego o pojawieniu się inkrementu funkcjonalności gotowego to przeglądu,

2) wymianę informacji niezbędnych do realizacji bieżących prac projektowych poprzez możliwość dodawania komentarzy do zadań, wymagań oraz błędów,

9. przechowywanie pełnej historii wymagań, w tym dokumentowanie historii komunikacji pomiędzy członkami zespołu projektowego (przedstawiciele Zamawiającego oraz Wykonawcy) w ramach dyskusji toczących się podczas realizacji zaplanowanych zadań oraz naprawiania zgłoszonych błędów, a także pełnej historii modyfikacji poszczególnych atrybutów wymagań/zadań/błędów, w tym zmian statusów,

10. zgłaszanie błędów/uwag do Produktów Umowy, w tym także uwag do inkrementu

funkcjonalności Systemu WIR w ramach wykonywanego przeglądu,

11. zarządzanie procesem obsługi zgłoszonych błędów/uwag do Produktów,

12. przeglądania statystyk dotyczących wymagań/ błędów, np. procent wymagań w trakcie

realizacji, procent wymagań zrealizowanych, procent poprawionych błędów,

13. prowadzenie rejestru przekazanych/udostępnionych materiałów (danych/zasobów/ rejestrów/plików i materiałów pomocniczych), pozwalającego na:

1) przechowywanie informacji o przekazanych/udostępnionych materiałach/danych,

w tym:

a. rejestrowanie informacji o dacie udostępnienia/przekazania materiałów,

b. rejestrowanie informacji o ilości i nazwach przekazanych/udostępnionych materiałów,

c. potwierdzanie przez Wykonawcę odbioru przekazanych materiałów,

14. prowadzenie rejestru aktualnego składu osobowego zespołu projektowego, z uwzględnieniem przypisania dla poszczególnych członków zespołu roli w zespole projektowym oraz unikalnego id umożliwiającego identyfikację członka zespołu,

15. prowadzenie repozytorium testów, umożliwiającego zarządzanie przypadkami testowymi (pełny opis przypadków testowych wraz z powiązaniem z wymaganiami), w tym także dla każdego przypadku testowego określenie wyniku przeprowadzonego testu:

a. pozytywny lub

b. negatywny, z możliwością opisu błędów napotkanych przy realizacji testu,

16. generowanie raportów/ zestawień danych, np. wykaz błędów zgłoszonych danego dnia,

17. prowadzenie rejestru zmian, umożliwiającego zarządzanie zmianami ( w tym zmianami zakresu

Systemu), pozwalającego dla każdej zmiany określenia co najmniej:

1) ID zmiany,

2) Daty zgłoszenia zmiany,

3) Statusu zmiany (np. nowa, w trakcie analizy, zatwierdzona, zawieszona, anulowana, w procesie wytwórczym, do przeglądu, do testów UAT, zrealizowana),

4) Osoby zgłaszającej,

5) Osoby odpowiedzialnej za nadzór nad realizacją zmiany,

6) Opisu zmiany,

7) Powiązanych ze zmianą wymagań,

8) Terminu realizacji zmiany.

Narzędzie wspomagające proces wytwórczy musi być konfigurowalne, co najmniej w zakresie:

1. Konfiguracji przebiegu procesu uzgadniania i realizacji wymagań (tzw. workflow wymagań),

2. Konfiguracji przebiegu procesu obsług zmiany (tzw. workflow zmian),

3. Definiowania kolejności następujących po sobie możliwych statusów wymagań/uwag/zmian,

4. Definiowania ról/użytkowników posiadających uprawnienia do nadawania poszczególnych statusów wymagań/uwag/zmian, w tym zwłaszcza definiowania ról/użytkowników posiadających uprawnienia do akceptacji sposobu realizacji wymagań/ akceptacji zmian,

5. Definiowania atrybutów opisujących wymagania/uwagi/zmiany.

Wykonawca musi zapewnić dostęp do Narzędzia wspomagającego proces wytwórczy przez cały okres realizacji Umowy dla 30 użytkowników ze strony Zamawiającego licząc od momentu jego udostepnienia tj. najpóźniej na 30 dni od daty podpisania Umowy. Wykonawca zobowiązany jest do prowadzenia prac z wykorzystaniem Narzędzia.

Po przekazaniu Zamawiającemu dostępów do Narzędzia Wykonawca zorganizuje instruktaż, dla użytkowników wykorzystujących narzędzie ze strony Zamawiającego, na którym zaprezentuje przepływ pracy w narzędziu, funkcjonalności narzędzia oraz zasady organizacji pracy z jego wykorzystaniem+. Udostępnienie Narzędzia zostanie potwierdzone przez strony w postaci Raportu z przekazania dostępów dla narzędzia.

Wykonawca zobowiązany jest do przekazania Zamawiającemu instrukcji/zasad użytkowania narzędzia

w języku polskim.

Zasilenie Narzędzia wspomagającego proces wytwórczy danymi w tym utworzenie oraz prowadzenie katalogu wymagań o zakresie wskazanym w rozdziale 11.2 Dokumentacja Analityczna jest obowiązkiem Wykonawcy.

Narzędzie musi umożliwiać wykonanie, w dowolnym momencie, zrzutu bazy danych Narzędzia wspierającego proces wytwórczy. Na zakończenie realizacji przedmiotu zamówienia, Wykonawca musi przekazać Zamawiającemu pełny zrzut bazy danych Narzędzia wspierającego proces wytwórczy w celu utrwalenia historii kooperacji. Wspomniany zrzut bazy danych musi umożliwiać jego odczyt w narzędziach będących w posiadaniu Zamawiającego. Narzędzie musi umożliwiać zrzut danych minimum do plików w formatach html, doc, csv.

OGÓLNY OPIS ARCHITEKTURY LOGICZNEJ DOCELOWEGO ROZWIĄZANIA (NA PODSTAWIE WYCIĄGU ZE STUDIUM WYKONALNOŚCI PROJEKTU WIR)

Wirtualny Informator Rzeczny

Wirtualny Informator Rzeczny będzie systemem informatycznym, stanowiącym centralny punkt dostępu do danych i informacji z poziomu przeglądarki internetowej oraz aplikacji mobilnej. System zapewni nowe narzędzia, w tym także e-usługi, niezbędne do efektywnego rozliczania korzystania z dróg wodnych, zarówno od strony klienta jak i administratora oraz zarządzania nimi. System będzie integrować, gromadzić, przechowywać i udostępniać w ujednoliconej i spójnej formie szerokie spektrum danych z odniesieniem przestrzennym, w tym w szczególności dane na temat:

1. dróg wodnych i ich infrastruktury,

2. komunikatów nawigacyjnych,

3. obiektów hydrotechnicznych (portów, śluz, pochylni),

4. zagrożeń i zjawisk lodowych,

5. sytuacji hydrologicznej i meteorologicznej,

6. zbiorników wodnych,

7. jednostek PGW WP odpowiedzialnych za dany odcinek drogi wodnej.

Wirtualny Informator Rzeczny (WIR) pozwoli na gromadzenie, wyszukanie, przeglądanie i pobieranie wyżej zdefiniowanych danych i informacji w odniesieniu do ich precyzyjnej lokalizacji z poziomu interaktywnej mapy. System umożliwi włączenie wybranych zbiorów danych do Krajowej Infrastruktury Informacji Przestrzennej. Ich zakres zostanie określony na etapie realizacji projektu.

System WIR będzie składał się z modułów dziedzinowych oraz komponentów logicznych. Zostanie również zintegrowany z obecnie funkcjonującymi systemami Zamawiającego oraz innymi systemami zewnętrznymi serwującymi x.xx. dane geoprzestrzenne.

Do modułów dziedzinowych systemu zaliczamy:

1. Moduł planowania tras,

2. Moduł zbiornikowy,

3. Moduł zjawisk lodowych,

4. Moduł obsługi spraw i rozliczeń,

5. Moduł zdarzeń,

6. Moduł ewidencji obiektów,

7. Moduł analityczno-raportowy.

Dostęp do poszczególnych modułów oraz ich funkcjonalności będzie zarządzany przez administratora

systemu WIR.

Do komponentów logicznych systemu zaliczamy:

1. Portal zewnętrzny,

2. Moduł mapowy,

3. Aplikacja mobilna,

4. Komponent integracyjny,

5. Baza danych.

Projekt będzie preferował rozwiązania o otwartym kodzie (Open Source), które zapewnią niski poziom kosztów utrzymania Systemu WIR.

System będzie zaprojektowany zgodnie z modelem architektury zorientowanej na usługi spełniające określone wymagania użytkowników (ang. Service-Oriented Architecture). Organizacja systemu w postaci usług ma zagwarantować możliwości:

1) poprawnego monitorowania dostarczanych usług,

2) efektywnej wymiany danych pomiędzy elementami systemu oraz systemami zewnętrznymi,

3) ponownego wykorzystania usług, niezależnie od konkretnej platformy czy technologii,

4) wymienialności elementów systemu na inny zgodny z ustalonym interfejsem,

5) łatwości skalowalności rozwiązania w oparciu o SOA,

6) zróżnicowania dostawców poszczególnych komponentów oprogramowania.

System zapewni możliwość, bez konieczności stosowania kluczy dostępowych, integracji z innymi systemami informatycznymi poprzez dostarczenie interfejsów i zbioru usług sieciowych. Biblioteka API umożliwi łatwą integrację i dostęp do metadanych zasobów danych oraz grupujących je zbiorów. System zostanie zbudowany oraz zintegrowany z innymi systemami Zamawiającego tak aby uniknąć redundancji danych oraz powielenia już istniejących elektronicznych rejestrów czy specjalistycznych funkcjonalności. WIR będzie budowany zgodnie z zasadą niezależności technologicznej w konsekwencji umożliwiając przenaszalność, czyli funkcjonowanie na różnych platformach technologicznych.

Komponenty logiczne wchodzące w skład systemu WIR

Portal zewnętrzny - umożliwi przedsiębiorcom i obywatelom oraz pracownikom PGW WP dostęp do zagregowanych danych oraz do poszczególnych modułów dziedzinowych. Ponadto będzie pełnił rolę szkoleniową i informacyjną. Moduł będzie zrealizowany zgodnie z koncepcją CMS. Portal będzie pełnił rolę serwera brzegowego, który będzie osadzony w strefie DMZ. Portal zewnętrzny musi zapewniać komunikację z komponentami wewnętrznymi po protokole HTTP a także zapewniać deszyfracja ruchu HTTPS. Jego zadaniem będzie również przekazywanie żądań do przeglądarki metadanych, modułu klienta mapowego, szyny ESB, rejestru usług, platformy e-learningowej oraz aplikacji CMS. Aplikacja CMS będąca jednym ze składników portalu zewnętrznego powinna umożliwiać pełne zrządzanie strukturą portalu a w tym pozwalać na osadzanie dynamicznych map, kanałów RSS, przypisywania wyznaczonych użytkowników (redaktorów) po poszczególnych części portalu. Ważnym elementem będzie również zaimplementowany mechanizm wyszukiwania. Dodatkowo, serwer WWW musi

udostępniać połączenie z wykorzystaniem protokołu HTTPS, certyfikowanego w ramach infrastruktury klucza publicznego oraz poprawnie generować strony w HTML wersji 5 (zgodnie aktualną wersją publikowaną przez organizację W3C) wraz ze stylami kaskadowymi CSS (Cascading Style Sheets) wersji 3.

Moduł mapowy – będzie narzędziem służącym do przetwarzania danych przestrzennych, będzie wykorzystywał usługi serwujące dane geoprzestrzenne (w tym usługi INSPIRE, WMS, WFS, WMTS itd.). Moduł mapowy powinien zawierać typowe narzędzia nawigacyjne i pomiarowe oraz umożliwiać pełne zarządzanie mapą (obsługa wielu kompozycji, zmiana kolejności warstw, podłączanie i odczyt nowych serwisów OGC, regulacja przezroczystości). Moduł powinien również umożliwiać edycję danych geometrycznych oraz opisowych z zachowaniem topologii oraz z zachowaniem mechanizmów dot. spójności danych opisowych. Ważnym elementem modułu będzie również możliwość rozbudowanego wyszukiwania np. po nazwie, atrybutach opisowych oraz przestrzennych a także wykonywanie analiz wraz z prezentacją wyników. Moduł będzie zawierał także katalog CSW (przeszukiwanie metadanych) oraz możliwość zapisu metadanych zgodnie z dowolnym profilem metadanych bazującym na ogólnie przyjętych normach ISO. Moduł mapowy będzie również umożliwiał drukowanie widoku i kompozycji mapy.

Aplikacja mobilna - będzie dostosowana do współpracy z systemami Android oraz iOS wyposażonych

w ekran dotykowy. Aplikacja będzie umożliwiać między innymi:

a. bezpośredni dostęp do modułów dziedzinowych WIR,

b. pośredni dostęp do danych systemu WIR,

c. planowanie trasy rejsu,

d. odbieranie powiadomień/ostrzeżeń z Systemu WIR,

e. kanał komunikacji pomiędzy administratorem drogi wodnej a użytkownikami,

f. dokonywanie płatności za śluzowanie lub przejście przez pochylnię,

g. zgłaszanie nieprawidłowości i niebezpieczeństw napotkanych na drodze wodnej.

Aplikacja mobilna powinna funkcjonować prawidłowo na smartfonach, tabletach poprzez wykorzystanie rozdzielczości natywnej. Jej głównym elementem administracyjnym powinien być panel administracyjny umożliwiający między innymi: konfigurowanie menu głównego (liczba i kolejność ikon stanowiących kolejne moduły dziedzinowe). Dane powinny być pobierane bezpośrednio z bazy systemu (przy użyciu warstwy pośredniej) i umożliwiać pracę on-line oraz off-line. Aplikacja mobilna powinna również wykorzystywać dostępne w urządzeniach moduły GPS do określania aktualnej pozycji użytkownika oraz informowania o zbliżającym się niebezpieczeństwie.

Komponent integracyjny – będzie odpowiadał za komunikację z modułami dziedzinowymi systemami zewnętrznymi oraz wymianę danych. w skład komponentu wejdą:

a. szyna usług (ESB),

b. silnik procesów biznesowych (BPMS),

c. silnik ETL oraz,

d. rejestr usług.

Szyna usług ESB powinna posiadać wbudowane narzędzia administracyjne, zapewniać możliwość wystawiania usług typu REST i korzystania z nich a repozytorium usług musi udostępniać API do swoich usług oparte na standardzie REST. Dodatkowo zachować interoperacyjność co najmniej w standardzie WS-I Basic Profile 1.1 oraz bezpieczeństwo komunikatów poprzez zastosowanie WS-I Basic Security Profile.

Ważne jest aby:

1. wymagania usług były udostępniane w jednym standardowym dla wszystkich usług formacie

WS Policy,

2. Adresowanie usług odbywało się zgodnie ze specyfikacją WS Addressing,

3. Niezawodne dostarczanie było zgodne ze specyfikacją WS ReliableMessaging,

4. Obsługa transakcji była zgodna ze specyfikacjami: WS Coordination, WS AtomicTransaction oraz WS BusinessActivity,

5. Załączniki komunikatów były zgodne z: Message Transmission Optimization Method (MTOM),

XML-binary Optimized Packaging (XOP),

6. Metadane usług sieciowych były zgodne ze specyfikacją WS MetadataExchange

Szyna usług powinna również umożliwiać filtrowanie komunikatów na podstawie zawartości, realizację procesów integracyjnych i instalacje w trybie wysokiej dostępności umożliwiając klastrowanie i równoważenie obciążenia. Szyna będzie także posiadała możliwość integracji aplikacji J2EE, .Net oraz z silnikiem procesów workflows. Ważne jest aby była zgodna ze standardami bezpieczeństwa:

a. WS-I Basic Security Profile 1.1,

b. WS-SecurityPolicy 1.2,

c. WS-Security Kerberos Token Profile 1.1,

d. WS-Secure Conversation 1.3,

e. WS-Trust 1.3,

f. WS-Security 1.1,

g. Username Token Profile 1.1

h. X.509 Certificate Token Profile 1.1,

i. SAML Version 2.0 assertions, oraz dodatkowo zapewnić:

j. trasowanie komunikatów,

k. transformację i wzbogacanie komunikatów przesyłanych przez usługi,

l. orkiestrację usług.

BPMS powinien posiadać graficzny edytor języka modelowania procesów biznesowych umożliwiający definiowanie szablonów reguł biznesowych, własnych funkcji, bibliotek decyzyjnych oraz testowanie procesów. BMPS powinien również umożliwiać modelowanie procesów w notacji BPMN i BPEL oraz definiowanie przepływów integracyjnych. Podstawową funkcjonalnością BPMS-a powinna być również edycja modelu danych i konfiguracja procesów, aplikacji oraz źródeł danych. Musi również posiadać

system monitorowania procesów biznesowych pozwalający na definiowanie i monitorowanie miar w procesach biznesowych.

Silnik ETL powinien zapewnić wykonywanie operacji na danych CRUD oraz wykonywanie walidacji za pomocą uruchamialnych bibliotek dokonujących kontroli poprawności struktury danych. Dodatkowo silnik ETL powinien zapewnić konwersję formatów za pomocą uruchamialnych bibliotek (konwersja formatów branżowych na struktury bazodanowe).

Rejestr Usług powinien umożliwiać definiowanie i wizualizację powiązań pomiędzy zasobami, definiowanie typów zasobów, własnych metadanych i ich zestawów oraz procesu przepływu informacji.

Baza danych systemu - będzie centralnym komponentem systemu odpowiedzialnym za składowanie,

pobieranie oraz przeglądanie danych produkcyjnych jaki i publikacyjnych.

Baza danych systemu powinna być dostępna na współczesnych 32 i 64 bitowych platformach, z możliwością uruchomienia wielu sesji bazy danych przy wykorzystaniu jednego połączenia z serwera aplikacyjnego do serwera bazy danych. Baza danych powinna także cechować się dostępem aplikacji klienckich do danych w modelu relacyjnym oraz relacyjno-obiektowym. Zarządzanie bazą danych powinno umożliwiać przeniesienia (migracji) struktur bazy danych i danych pomiędzy platformami systemowymi bez konieczności rekompilacji aplikacji bądź migracji środowiska aplikacyjnego. Baza danych powinna współpracować z serwerami danych przestrzennych, a także umożliwiać dostęp do danych przestrzennych za pomocą oprogramowania GIS wykorzystywanego przez Zamawiającego (ArcGIS for Desktop, QGIS). Ważną cechą jest również możliwość wykonywania analiz przestrzennych za pomocą języka SQL. Baza danych systemu powinna wspierać standard JDBC 3.0 i być zgodna ze standardem ANSI/ISO SQL. Musi także posiadać mechanizm uwierzytelniania użytkowników, wymuszać złożoności hasła użytkownika, czasu życia hasła, sprawdzanie historii haseł, blokowanie konta przez administratora np. w przypadku przekroczenia limitu nieudanych logowań. W zakresie zarządzania kopiami baza danych systemu powinna posiadać możliwość integracji z systemem backup, wykonywania kopii bezpieczeństwa w trybie on-line oraz off-line.

Moduły dziedzinowe wchodzące w skład systemu WIR

Moduł Planowania Tras - będzie zawierał dane o drogach wodnych wraz z ich opisem, tworzące system referencyjny oparty na punktach węzłowych i odcinkach międzywęzłowych oraz komunikatach nawigacyjnych.

Moduł będzie umożliwiać planowanie trasy rejsu na podstawie wprowadzonego punktu początkowego oraz końcowego uwzględniając również sytuację hydrologiczną i meteorologiczną a także czasowe zamknięcia obiektów hydrotechnicznych (np. remont śluzy czy pochylni). Planowanie trasy rejsu powinno się odbywać za pomocą scenariuszy (work-flows) gdzie użytkownik będzie prowadzony krok po kroku przez cały proces. w trakcie wprowadzania danych dot. planowania trasy na kolejnych formularzach system powinien:

1. prezentować wartości domyślne,

2. automatycznie uzupełniać atrybuty np. po wskazaniu śluzy (dostępne dane dot. np. nazwy, godzin otwarcia, stanu wód, utrudnień, czasowe zamknięcie),

3. automatycznie uzupełniać do celów analitycznych pola systemowe, takie jak data, użytkownik,

4. informować o braku wypełnionego atrybutu obligatoryjnego (walidacja danych).

Po wprowadzeniu obligatoryjnych danych dot. Planowanej trasy moduł powinien prezentować dostępne warianty tras (maksymalnie 3 najbardziej optymalne pod kątem odległości, czasu, spodziewanych utrudnień), a dla każdej z nich co najmniej:

1. przebieg trasy rejsu w oknie mapowym,

2. całkowitą długość trasy,

3. przybliżony czas planowanego rejsu (bazujący na średniej prędkości, odpowiednich przepisach, średnim czasie śluzowania itp.)

4. informacje o bieżących komunikatach nawigacyjnych dla trasy rejsu,

5. informacje o ostrzeżeniach meteorologicznych obowiązujących na trasie rejsu,

6. informacje o zgłoszonych zdarzeniach,

7. informacje o miejscach newralgicznych i limitujących,

8. nazwę drogi śródlądowej,

9. klasę drogi śródlądowej,

10. głębokość tranzytową,

11. opłaty,

12. liczbę śluzowań, przejść przez pochylnie,

13. informacje o czasowych zamknięciach obiektów.

Algorytm planowania trasy powinien uwzględniać aktualny stan wód na podstawie odczytów z wodowskazów i wodowskazów osłonowych. Lista parametrów prezentowanych dla danej trasy rejsu powinna być zależna od parametrów wprowadzonych podczas planowania rejsu. Szczegółowa lista informacji prezentowanych dla trasy rejsu powinna zostać ustalona na etapie analizy. Po zakończeniu procesu planowania i zatwierdzeniu trasy rejsu system powinien przekierować użytkownika do modułu obsługi spraw i rozliczeń w celu dokonania płatności elektronicznej.

Ważnym elementem modułu planowania tras będzie również możliwość automatycznego przygotowania kart przejazdów na podstawie planowanej trasy, która następnie zostanie wykorzystana do wypełnienia deklaracji i naliczenia należności z tym związanych. Na potrzeby wygenerowania karty przejazdu moduł powinien umożliwiać wprowadzenie dodatkowych informacji dotyczących planowanego rejsu. Zakres atrybutów zostanie określony na etapie analizy.

Moduł planowania tras powinien być dostępny z poziomu aplikacji webowej oraz aplikacji mobilnej oraz być funkcjonalnie zintegrowany z modułem obsługi rozliczeń i płatności umożliwiając zakup biletu dot. śluzowania i przejścia przez pochylnie po wykonaniu procesu planowania trasy rejsu. Moduł planowania powinien być również zintegrowany z modułem zdarzeń tak aby prezentować aktualne zdarzenia/ utrudnienia/ informacje w trakcie planowania trasy jak i podczas rejsu. Moduł powinien być

zasilany danymi pochodzącymi z baz referencyjnych oraz innych modułów systemu WIR. Moduł powinien także gromadzić dane dot. planowania tras tak aby następnie istniała możliwość ich analizy za pomocą modułu analityczno-raportowego a w tym co najmniej:

1. trasy rejsu wraz z punktami początkowymi, końcowymi oraz pośrednimi,

2. użytkowników z podziałem na armatorów oraz turystów,

3. dane jednostek pływających (nazwy i parametry),

4. średnie prędkości.

W przypadku dostępu do modułu z poziomu aplikacji mobilnej powinien umożliwić pracę w trybie on- line oraz off-line (zapis wprowadzonej trasy z możliwością śledzenia pozycji położenia). Moduł planowania powinien być także dostępny dla użytkownika zalogowanego oraz użytkownika niezalogowanego (ograniczony interfejs oraz funkcjonalność).

Centralnym elementem modułu planowania tras powinien być moduł mapowy umożliwiający wyświetlanie danych tematycznych na tle danych podkładowych. Lista warstw stanowiących dane podkładowe zostanie uzgodniona z Zamawiającym na etapie analizy przedwdrożeniowej.

Moduł powinien umożliwiać eksport zaplanowanej trasy co najmniej do formatu KML oraz wydruk mapy z zaplanowaną trasą wraz z informacjami podkładowymi co najmniej do formatu pdf. Wydruk powinien zawierać co najmniej:

1. przebieg trasy wraz z danymi z dostępnymi danymi podkładowymi,

2. informacje dot. obiektów (mosty, śluzy),

3. informacje dot. zdarzeń,

4. dane podkładowe,

5. skalę, podziałkę skalową, kierunek północy, siatkę współrzędnych.

Moduł powinien wspierać użytkownika podczas rejsu poprzez umożliwienie geolokalizacji w czasie rzeczywistym (real-time monitoring system) bazującą co najmniej na sygnale GPS urządzenia mobilnego na którym zostanie uruchomiona aplikacja na tle wyznaczonej trasy a także innych danych podkładowych i referencyjnych jak np. kilometraż.

Moduł planowania będzie gromadził i udostępniał dane dot. komunikatów nawigacyjnych

wprowadzonych przez odpowiedni personel PGW WP:

1. punktowych: zamknięcia / ograniczenia żeglugi z powodu awarii urządzeń hydrotechnicznych, remontów, prac w obrębie cieku, zdarzeń losowych, wiatrołomów, dewastacji, wypadków żeglugowych,

2. liniowych: ograniczenia związane z imprezami na wodzie, wypłyceniem, odłożonym rumowiskiem rzecznym, porostem roślinności rzecznej, przekroczenia WWŻ,

3. obszarowych: ograniczenia spowodowane przeprowadzeniem imprezy na wodzie np. regaty wioślarskie, żeglarskie bądź zamknięcia żeglugi w celu umożliwienia przeprowadzenia np. ćwiczeń wojskowych.

Moduł powinien umożliwiać zarządzanie tymi danymi, czyli wprowadzanie komunikatów

nawigacyjnych ich prezentację i edycję.

Moduł powinien umożliwiać zastosowanie technologii RFID do pełnej automatyzacji procesu śluzowania i przejścia przez pochylnie (weryfikacja przejazdu, weryfikacja płatności).

Moduł Zdarzeń – umożliwiał będzie pełne zarządzanie zgłoszeniami przekazywanymi do systemu zarówno przez zalogowanych, jak i anonimowych użytkowników dróg wodnych. Moduł zdarzeń będzie umożliwiać:

1. zgłaszanie zdarzeń na szlakach wodnych przez użytkowników dróg wodnych,

2. prezentowanie poszczególnych zgłoszeń na mapie oraz przekazywanie informacji nt.

charakteru i miejsca zdarzenia,

Moduł zdarzeń powinien być dostępny z poziomu aplikacji webowej (portal) oraz aplikacji mobilnej oraz zintegrowany z modułem planowania tras oraz analityczno-raportowym poprzez udostępnianie gromadzonych danych dot. zdarzeń (data, kategoria, opis, zdjęcie).

Moduł zdarzeń powinien się składać co najmniej z:

1. Aplikacji do zgłoszeń,

2. Aplikacji (Konsoli) administracyjnej (konfiguracja, zarządzanie zgłoszeniami), która będzie

umożliwiać:

a. definiowanie co najmniej 12 kategorii (np. utrudnienia, przeszkody, niebezpieczne miejsca)

b. definiowanie indywidualnych konfiguracji dla regionów (RZGW),

c. wyświetlanie oraz przeglądanie wszystkich zgłoszeń (aktualne/nieaktualne),

d. definiowanie kategorii zgłoszeń,

e. akceptacje zgłoszeń nadesłanych przez użytkowników

f. usuwanie zgłoszeń (ręczne) oraz automatyczne,

g. przeglądanie i filtrowanie wg wprowadzonych atrybutów,

h. usuwanie / modyfikowanie / wprowadzenie dodatkowego komentarza.

Moduł zdarzeń musi umożliwiać dokonanie zgłoszenia poprzez geo-lokalizacje (bieżące położenie użytkownika) oraz wskazanie na mapie, kilometraż zdarzenia (licząc odległość zdarzenia od początku drogi), oraz pikietaż zdarzenia (licząc odległość od początkowego punktu referencyjnego odcinka, na którym się znajduje dane zdarzenie). Dokonanie zgłoszenia powinno być możliwe zarówno przez zalogowanych, jak i anonimowych użytkowników dróg wodnych. Dodatkowo podczas dokonywania zgłoszenia moduł zdarzeń powinien informować o podobnych istniejących już zdarzeniach w buforze (odległości zdefiniowanej przez administratora systemu) np. 50m. Moduł zdarzeń powinien również umożliwiać dokonanie zgłoszenia poprzez przesłanie zdjęcia obrazującego zdarzenie.

Ważnym elementem modułu zdarzeń powinna być możliwość obsługi procesu weryfikacji zgłoszenia / zdarzenia przez pracownika PGW WP. Moduł powinien umożliwiać przypisanie zgłoszenia do

pracownika wraz z powiadomieniem, natomiast pracownik po weryfikacji powinien mieć możliwość

zmiany statusu zdarzenia wraz z dodatkowym komentarzem.

Moduł zdarzeń powinien także na bieżąco wyświetlać komunikaty o zbliżających się przeszkodach. Prezentowane zdarzenia powinny posiadać również informację o liczbie użytkowników, którzy dokonali tego samego zgłoszenie a użytkownicy powinni posiadać możliwość potwierdzenia stanu zdarzenia. Zdarzenia dodane przez użytkowników i zaakceptowane przez administratora systemu powinny być automatycznie publikowane i dostępne dla innych użytkowników dróg wodnych jeśli ilość osób, które potwierdziły zdarzenie przekroczy wartość minimalną (parametr konfiguracyjny).

Moduł Obsługi spraw i rozliczeń - będzie narzędziem umożliwiającym pełną elektroniczną obsługę spraw i rozliczeń związanych z deklaracjami, podpisywaniem dokumentów (profil zaufany, e-dowód, certyfikat kwalifikowany), wnoszeniem opłat, prowadzeniem rejestrów oraz wystawiania “Informacji w sprawie”.

Moduł obsługi spraw i rozliczeń powinien być dostępny na platformie webowej (portal) oraz aplikacji mobilnej. Dodatkowo powinien zostać zintegrowany z modułem planowania poprzez dostęp do wprowadzonych danych w ramach zaplanowanej trasy (automatyczne uzupełnienie kart przejazdu) a gromadzone dane powinny być udostępniane w celu analizy i raportowania.

Moduł powinien w pełni wspierać proces obsługi spraw i rozliczeń zarówno z poziomu użytkownika jak i zarządcy drogi wodnej. z poziomu użytkownika (armatora) powinien mieć możliwość konfiguracji kont dla pracowników sporządzających karty przejazdu oraz deklaracje. Moduł musi również umożliwiać elektroniczne prowadzenie kart przejazdu dla obiektu pływającego a w tym co najmniej:

1. rodzaj i nazwa obiektu,

2. nr rejestracyjny,

3. nośność,

4. ilość załadowanego towaru,

5. trasa (skąd - dokąd),

6. liczbę pokonanych śluz wraz z godzinami śluzowania,

7. dane kapitana w tym nr patentu.

Moduł musi umożliwiać również wprowadzanie archiwalnych kart przejazdu oraz deklaracji za pomocą dedykowanego interfejsu (ręcznie) oraz poprzez automatyczne/półautomatyczne wczytanie danych ze skanu deklaracji lub karty przejazdu.

Moduł musi umożliwiać podpisywanie dokumentów w tym deklaracji co najmniej:

a. profilem zaufanym,

b. e-dowodem,

c. certyfikatem kwalifikowanym

oraz posiadać mechanizm publikowania danych za pośrednictwem zewnętrznych

platform elektronicznych jak np. ePUAP, eBOK.

Natomiast należy zaznaczyć, że podstawowy dostęp do modułu nie powinien wymagać autoryzacji za

pomocą profilu zaufanego.

W ramach modułu powinny być dostępne 2 e-usługi:

1. Elektroniczne rozliczanie deklaracji, na podstawie której ustala się wysokość należności za korzystanie ze śródlądowych dróg wodnych i ich odcinków oraz śluz i pochylni w danym miesiącu (Typ A2B 5 poziom dojrzałości) zwaną w skrocie „Deklaracja…”,

2. Obsługa żeglugi rekreacyjnej (Typ A2C 4 poziom dojrzałości).

Ważne jest aby moduł wspierał również obsługę procesu reklamacji naliczonej opłaty, zarówno od

strony armatora jaki i PWG WP (możliwość zmiany wysokości naliczonej należności).

Moduł będzie umożliwiać użytkownikom korzystającym z dróg wodnych w celach rekreacyjnych dokonanie opłaty za śluzowanie lub przejście przez pochylnię on-line (bilet elektroniczny). Opłata za śluzowanie lub przejście przez pochylnię powinna być możliwa co najmniej poprzez:

a. przelew bankowy (w tym szybki przelew bankowy),

b. szybkie płatności (np. PayU, Przelewy24, Tpay, Dotpay) ,

c. karta debetowa / kredytowa,

d. BLIK.

Dodatkowo, moduł musi umożliwiać dokonanie opłaty należności z wyprzedzeniem np. podczas planowania trasy rejsu wraz z możliwością opłaty za kilka obiektów i kilka jednostek w ramach jednego biletu (aplikacja Web) lub na miejscu np. podczas oczekiwania na śluzowanie (aplikacja mobilna). Bilet elektroniczny powinien stanowić tzw. e-kod (ciąg łatwych do zapamiętania i przekazania znaków), który będzie jednocześnie potwierdzeniem zapłaty należności - formuła oraz sposób generowania zostanie uzgodniona z Zamawiającym. Należy także uwzględnić możliwość wydruku w celu okazania podczas śluzowania lub przejścia przez pochylnie. Moduł powinien także wspierać opłaty wnoszone w sposób tradycyjny przez użytkowników dróg śródlądowych, w takim przypadku pracownik obsługi powinien mieć możliwość wygenerowania i skasowania biletu elektronicznego. z perspektywy PGW WP, moduł musi umożliwiać weryfikację biletów elektronicznych (e-kodów) przez pracowników obsługi obiektu uwzględniając praktyczne aspekty oraz bezpieczeństwo użytkowników dróg wodnych.

Moduł musi posiadać mechanizm porównywania danych zawartych w „Deklaracji…” z danymi pochodzącymi z rejestru przejazdu obiektów pływających, zestawień śluzowań, zestawień przejść przez pochylnię, w odniesieniu do składającego „Deklarację…” z zawężeniem do zdefiniowanego okresu czasu. Walidacja danych z deklaracji z danymi z rejestru przejazdów powinna obejmować co najmniej:

1. długość trasy,

2. liczbę śluzowań wraz z godzinami

3. liczbę przejść przez pochylnię wraz z godzinami,

4. należność naliczoną na na podstawie deklaracji w odniesieniu do rejestru przejazdów,

5. parametry jednostki pływającej.

Moduł musi automatycznie porównywać dane wprowadzone przez pracownika z danymi zawartymi w deklaracji przesłanej przez przedsiębiorcę i w przypadku ich pełnej zgodności generować

„Informację ustalającą wysokość należności za korzystanie ze śródlądowych dróg wodnych i ich odcinków oraz urządzeń stanowiących własność Skarbu Państwa” generując dane do systemu finansowo- księgowego PGW WP. w przypadku braku ich pełnej zgodności moduł powinien powiadomić pracownika PWGWP i umożliwić wprowadzenie odpowiedniej korekty. Moduł powinien informować o statusach płatności dotyczących poszczególnych deklaracji oraz zaległościach w płatnościach dotyczących poszczególnych deklaracji.

Moduł musi także posiadać komponent do budowania bazy wiedzy dot. zasad korzystania z dróg wodnych, akty prawa polskiego i unijnego które dotyczą przedmiotu platformy, procedur postępowania. Wiązanie tematów poprzez słowa kluczowe, kategorie tematyczne, miejsce (prawo miejscowe).

Moduł Zbiornikowy – będzie umożliwiał prowadzenie bazy danych o zbiornikach a składowane informacje będą stanowiły podstawę dla modułu planowania tras. Moduł będzie przede wszystkim zarządzał dodatkowymi danymi niezbędnymi do prawidłowego funkcjonowania systemu WIR.

Moduł zbiornikowy powinien być dostępny na platformie webowej (portal) oraz aplikacji mobilnej. Jego centralnym punktem dostępowym modułu powinien być moduł mapowy. Dostęp do funkcjonalności i danych modułu powinien być skonfigurowany przez administratora systemu. Podstawowa funkcjonalność modułu będzie się sprowadzać do wyświetlania, przeglądania i wyszukiwania zbiorników wraz z ich prezentacją graficzną oraz zestawem przypisanych atrybutów. Dodatkowo, moduł musi umożliwiać wprowadzanie / edycję / usuwanie dodatkowych atrybutów opisowych dot. zbiorników, poza tymi znajdującymi się w innych rejestrach i systemach Zamawiającego. Informacje niezbędne do prawidłowego funkcjonowania systemu WIR będą dotyczyć lokalizacji (kilometraż), infrastruktury (np. zapora, elektrownia, śluza) oraz poziomów piętrzenia (minPP, NPP, MaxPP, NadPP) wraz z objętością (Vu, Vp) i powierzchnią zbiornika.

W ramach modułu użytkownik powinien mieć możliwość tworzenia i wizualizacji schematów i hydrogramów oraz graficznego generowania schematu rocznego pracy zbiornika /podstawowy obraz oraz dziennego raportu pracy zbiornika z naniesionymi parametrami pracy a także prowadzenia dedykowanego dziennika obiektu hydrotechnicznego wraz z inwentaryzacją danych w terenie (za pomocą aplikacji mobilnej).

Moduł Zjawisk Lodowych – będzie umożliwiał gromadzenie, zarządzanie oraz przetwarzanie danych dotyczących zjawisk lodowych. Moduł będzie umożliwiał także prowadzenie analiz w kontekście zebranych danych, występujących zjawisk, danych hydrologicznych i meteorologicznych. Ważnym elementem modułu będzie również możliwość wyświetlenia pozycji lodołamacza a także śledzenie jego pozycji w czasie rzeczywistym.

Moduł zjawisk lodowych powinien być dostępny na platformie webowej (portal) oraz aplikacji

mobilnej. Centralnym punktem dostępowym modułu powinien stanowić moduł mapowy wraz z możliwością generowania map tematycznych w postaci analiz na żądanie lub wg predefiniowanych zapytań z parametrami. Moduł musi umożliwiać zaawansowaną wizualizację kartograficzną, w tym co najmniej:

1. mapa tematyczna,

2. mapa ciepła (heat mapa) w kontekście natężenia występowania,

3. agregacja danych wraz z prezentacją w postaci wykresów słupkowych.

Ważnym elementem będzie również prowadzenie analiz w kontekście: zebranych danych,

występujących zjawisk, oraz danych hydrologicznych i meteorologicznych.

Podstawowa funkcjonalność modułu powinna sprowadzać się do wprowadzania danych na temat zjawisk, w tym również punktowo wraz z opisem zjawiska oraz jego aktualizację wraz z generowaniem tabel i grafów co najmniej: na żądanie lub na podstawie predefiniowanych szablonów. Wprowadzanie informacji dot. zjawiska lodowego powinno się odbywać za pomocą tzw. dedykowanego scenariusza

„workflow” a w tym co najmniej:

a. pracownik terenowy wprowadza informacje o zjawisku (zasięg, rodzaj, natężenie/nasilenie w %),

b. pracownik wyższego szczebla akceptuje / odrzuca wraz z komentarzem.

Dane dot. zjawisk lodowych widoczne są w systemie jedynie po zatwierdzeniu przez upoważnioną osobę.

Moduł Ewidencji obiektów - będzie służył do gromadzenia danych o infrastrukturze dróg wodnych i prowadzenia szczegółowej ewidencji obiektów inżynieryjnych na potrzeby systemu WIR. Dodatkowym elementem będzie możliwość inwentaryzacji danych dot. obiektów bezpośrednio w terenie.

Moduł ewidencji obiektów powinien być dostępny na platformie webowej (portal) oraz aplikacji mobilnej. Edycja danych geometrycznych powinna odbywać się za pomocą platformy webowej, natomiast danych opisowych także za pomocą aplikacji mobilnej. Centralnym punktem dostępowym modułu powinien stanowić moduł mapowy. Moduł będzie prowadził ewidencje obiektów inżynieryjnych w dowiązaniu do systemu referencyjnego, dlatego zarządzanie (w tym edycja) będzie dotyczyć jedynie dodatkowych atrybutów wymaganych do poprawnego funkcjonowania systemu WIR.

Dodatkowo, moduł musi umożliwiać wyszukiwanie obiektów inżynieryjnych, poprzez:

1. podanie kilometrażu początkowego i końcowego,

2. wskazania na mapie (moduł mapowy),

3. po nazwie obiektu lub oznaczeniu,

4. zaznaczenie obszaru wyszukiwania na mapie.

Moduł powinien służyć do gromadzenia danych o infrastrukturze dróg wodnych, w tym co najmniej:

1. oznakowanie brzegowe i pływające przeszkód żeglugowych,

2. obiekty hydrotechniczne w obrębie drogi wodnej: śluzy, jazy, progi wraz z oznakowaniem oraz z pełną charakterystyką (opis budowli, czas otwarcia śluz, należności za śluzowanie, kontakt bezpośredni z operatorem śluzy),

3. przegrody mostowe z pełnym oznakowaniem,

4. infrastruktura techniczna napowietrzna, podwodna typu linie energetyczne, gazociągi,

teleinformatyka itp.),

5. dane o przystaniach żeglarskich, odpowiednich miejscach cumowniczych, umocnieniach brzegowych umożliwiający bezpieczny postój jednostki pływającej (porty, kotwicowiska itp.), wraz z informacją o możliwości uzupełnienia wody pitnej oraz paliw.

Moduł powinien także umożliwiać podział drogi wodnej na odcinki ograniczone punktami węzłowymi

zlokalizowanymi w miejscach charakterystycznych a w tym co najmniej:

1. punkt przecięcia łączenia dróg wodnych,

2. punkt przecięcia osi drogi wodnej z granicą administracyjną,

3. początek obiektu mostowego,

4. xxxxx,

5. pochylnia.

Moduł powinien również umożliwiać tworzenie obiektów na podstawie źródeł (podkładów) w postaci:

1. danych wektorowych np. shp, kml,

2. danych rastrowych posiadających georeferencję,

3. współrzędnych X, Y punktów załamań linii, zasilanych w postaci plików txt.,

4. ortofotomapy,

5. mapy ewidencyjnej,

6. map dostępnych w postaci usług np. ortofotomapa pochodząca z geoportalu krajowego

Moduł Analityczno-raportowy – będzie umożliwiał pełną analitykę i przetwarzanie danych gromadzonych w systemie WIR wraz z możliwością tworzenia raportów i zestawień graficznych.

Moduł analityczno-raportowy powinien być dostępny na platformie webowej (portal) oraz aplikacji mobilnej i wykorzystywać wszystkie dane gromadzone za pomocą modułów dziedzinowych. Dostęp do modułu powinien być zapewniony z sieci wewnętrznej Zamawiającego jak i z sieci zewnętrznej. Ważną funkcjonalnością modułu będzie możliwość przygotowania spersonalizowanego interfejsu w zależności od grupy odbiorców tzw. dashboardy, które powinny składać się co najmniej z okna mapowego, wykresów statystycznych, narzędzi nawigacyjnych, oraz legendy mapy. Prezentacja wyników analiz powinna być realizowana jednocześnie za pomocą kilku połączonych okien mapowych oraz dynamicznych wykresów. Wykresy oraz tabele muszą być interaktywne i umożliwiające filtrowanie danych przestrzenno-atrybutowych na podstawie wybranych wartości.

Moduł musi umożliwiać tworzenie usług geoprzetwarzania za pomocą graficznego interfejsu użytkownika, pozwalającego na przetwarzanie danych wektorowych w jednym ciągu definicji

przebiegu tzw. geo-procesu.

Moduł będzie umożliwiać wykonanie co najmniej następujących analiz:

1. agregowanie obiektów punktowych w sparametryzowanym zasięgu, wraz ze statystykami, obejmującymi liczbę obiektów, przedstawione w formie punktów zagregowanych oraz wykresów kołowych,

2. filtrowanie obiektów według wybranych pól atrybutowych warstwy z oznaczeniem

dostępności wartości atrybutów obiektów w zależności od wcześniej określonej filtracji,

3. wyszukiwanie obiektów spełniających kryteria atrybutowe,

4. filtrowanie danych w oparciu o dowolnie zdefiniowaną przez użytkownika geometrie powierzchniową

5. filtrowanie danych w oparciu o wybrane przez użytkownika obiekty powierzchniowe udostępniane przez moduł,

6. tworzenie i parametryzowanie map ciepła.

Dla uzyskania odpowiedniej wydajności, moduł powinien wspierać buforowanie map (data caching). Tworzenie i konfiguracja modułu oraz jego elementów (aplikacji) musi się odbywać za pomocą interfejsu graficznego dostępnego z poziomu witryny WWW. Panel konfiguracyjny musi uwzględniać co najmniej:

1. zbiór zasobów,

2. konfigurator aplikacji do przeglądania i raportowania danych,

3. konfigurator aplikacji do przeglądania i analizowania danych,

4. Panel zarządzania użytkownikami i uprawnieniami do poszczególnych aplikacji.

E-usługi i podstawowa funkcjonalność systemu WIR

Projektowany system WIR będzie udostępniał dwie e- usługi:

1) Definicja usługi: Usługa dotyczy sytuacji, w której przedsiębiorcy będący użytkownikami dróg wodnych, posiadający: statki towarowe, zestawy, obiekty pływające dla spławu drewna oraz statki pasażerskie, wycieczkowe i statki niebędące małymi statkami (statki o nośności powyżej 15 ton lub służące do przewozu więcej niż 12 pasażerów), zgodnie z obowiązującymi przepisami prawa, w sprawie należności za korzystanie ze śródlądowych dróg wodnych i ich odcinków oraz śluz i pochylni, zobowiązani są do złożenia deklaracji na podstawie której ustala się wysokość należności za korzystanie ze śródlądowych dróg wodnych i ich odcinków oraz śluz i pochylni w danym miesiącu.

Usługa „Deklaracji…” umożliwi przygotowanie, modyfikację oraz złożenie przez Internet za pomocą jednego prostego i zintegrowanego formularza:

a. „części A” deklaracji, jeśli obiektem pływającym jest statek towarowy, zestaw, obiekt pływający dla spławu drewna

b. „części B” deklaracji, jeśli obiektem pływającym jest statek pasażerski, wycieczkowy lub statek niebędący małym statkiem,

oraz elektroniczne rozliczenie należności z nich wynikających.

Za pomocą usługi możliwe będzie dokonanie co najmniej poniższych operacji:

a. rejestracja nowego podmiotu w systemie,

b. usunięcie podmiotu z systemu,

c. prowadzenie własnej karty przejazdu obiektu pływającego/obiektów pływających,

d. tworzenie deklaracji wypełniając formularz ręcznie lub importując dane do formularza z karty przejazdu obiektu pływającego, arkusza kalkulacyjnego, bazy danych czy swoich wcześniejszych deklaracji,

e. zapis formularza w dowolnym momencie jako numerowaną wersję roboczą,

f. przeglądanie i edytowanie wersji roboczej deklaracji,

g. walidacja deklaracji – weryfikacja kompletności oraz poprawności danych

w deklaracji,

h. podpisanie deklaracji,

i. opłacenie przy udziale systemu uzyskanej zwrotnie „informacji o wysokości należności za korzystanie ze śródlądowych dróg wodnych i ich odcinków oraz śluz i pochylni w danym miesiącu”

j. wgląd we własne konto rozliczeniowe oraz dostępu do danych dotyczących rozliczeń rejestrowanych rejsów

k. składanie reklamacji w zakresie wysokości naliczonych opłat wynikających z „informacji o wysokości należności za korzystanie ze śródlądowych dróg wodnych i ich odcinków oraz śluz i pochylni w danym miesiącu”

2) Obecny poziom usługi: 1

3) Docelowy poziom dojrzałości: 5

4) Podstawa Prawna: Ustawa z dnia 20 lipca 2017 r. Prawo wodne (Dz. U. z 2018 r. poz. 2268, z 2019r. Poz. 125, 534, 1495); Rozporządzenie Ministra Gospodarki Morskiej i Żeglugi Śródlądowej z dnia 22 marca 2018 r. w sprawie należności za korzystanie ze śródlądowych dróg wodnych i ich odcinków oraz śluz i pochylni (Dz. U. z 2018 r. poz. 654)

5) Metoda autoryzacji: Autoryzacja w systemie będzie opierała się o narzędzia integrujące system z Węzłem Krajowym xxxxx.xxx.xx (Profil zaufany, e-dowód) i wykorzystywała dostępne mechanizmy, a także poprzez metody uwierzytelniania dostawców płatności elektronicznych.

6) Odbiorcy: przedsiębiorcy będący użytkownikami dróg wodnych.

2. Obsługa żeglugi rekreacyjnej.

1) Definicja usługi: Usługa dotyczy sytuacji, w której użytkownicy korzystający z śródlądowych dróg wodnych w celach rekreacyjnych, zgodnie z rozporządzeniem Ministra Gospodarki Morskiej i Żeglugi Śródlądowej w sprawie należności za

korzystanie ze śródlądowych dróg wodnych i ich odcinków oraz śluz i pochylni, zobowiązani są do uiszczenia należności za śluzowanie lub korzystanie z pochylni. Usługa „Obsługa żeglugi rekreacyjnej” umożliwi użytkownikom korzystającym z dróg wodnych w celach rekreacyjnych wcześniejsze lub bezpośrednio na obiekcie dokonanie płatności drogą elektroniczną. Wprowadzone narzędzia usprawnią proces płatności oraz ograniczą ilość czynności wykonywanych przez pracowników śluz/pochylni związanych z rozliczaniem i rejestrowaniem rejsów. Dokonując opłaty elektronicznej, użytkownik będzie zobowiązany podać rodzaj/nazwę obiektu, kierunek, w którym płynie oraz datę planowanego skorzystania ze śluzy lub pochylni. Dane te trafią bezpośrednio do raportu w systemie. System zapewni możliwość generowania elektronicznych potwierdzeń uiszczenia opłaty.

2) Obecny poziom dojrzałości: 1

3) Docelowy poziom dojrzałości: 4

4) Podstawa Prawna: Ustawa z dnia 20 lipca 2017 r. Prawo wodne (Dz. U. z 2018 r. poz. 2268, z 2019r. Poz. 125, 534, 1495) Rozporządzenie Ministra Gospodarki Morskiej i Żeglugi Śródlądowej z dnia 22 marca 2018 r. w sprawie należności za korzystanie ze śródlądowych dróg wodnych i ich odcinków oraz śluz i pochylni (Dz. U. z 2018 r. poz. 654)

5) Metoda autoryzacji: w przypadku osób zarejestrowanych w systemie WIR autoryzacja będzie wykorzystywała mechanizmy uwierzytelniania za pomocą loginu i hasła, a także poprzez metody uwierzytelniania dostawców płatności elektronicznych. w przypadku osób chcących korzystać z usługi w sposób anonimowy, nie będzie potrzeby dokonywania autoryzacji.

6) Odbiorcy: Użytkownicy korzystający z dróg wodnych w celach rekreacyjnych Projektowany system WIR będzie udostępniał 2 główne funkcjonalności:

1. Planowanie trasy rejsu

1) Opis funkcjonalności: Funkcjonalność jest odpowiedzią na potrzebę zgłoszoną przez użytkowników korzystający z śródlądowych dróg wodnych w zakresie możliwości planowania lub weryfikowania trasy rejsu. Funkcjonalność dostępna będzie poprzez portal systemu oraz w aplikacji mobilnej. Funkcjonalność umożliwi użytkownikom korzystającym z dróg wodnych planowanie trasy w oparciu x.xx. o:

a. informacje o godzinach pracy śluz, godzinach śluzowania, cenach, ograniczeniach;

b. dane o przystaniach żeglarskich, odpowiednich miejscach cumowniczych, umocnieniach brzegowych umożliwiających bezpieczny postój jednostki pływającej (porty, kotwicowiska itp.);

c. ostrzeżenia/informacje meteorologiczne i hydrologiczne;

d. informacje nawigacyjne;

e. informacje na temat głębokości tranzytowych lub prześwitów pod mostami Użytkownik będzie miał możliwość x.xx.:

a. rejestracji konta w systemie,

b. usunięcie konta z systemu,

c. tworzenia własnych planów rejsów,

d. podglądu szczegółów dotyczących danych i informacji publikowanych w układzie

przestrzennym,

e. zapisu planowanej trasy w dowolnym momencie jako numerowaną wersję roboczą,

f. przeglądania i edytowania wersji roboczej planu rejsu,

x. zawieszenie planu rejsu w oczekiwaniu na odpowiednie warunki hydrologiczne wraz z powiadomieniem o zaistnieniu tych warunków,

h. dokonywanie płatności na podstawie trasy rejsu (powiązanie z usługą Obsługa żeglugi rekreacyjnej).

2) Metoda autoryzacji: w przypadku osób zarejestrowanych w systemie, autoryzacja będzie opierała się o mechanizmy uwierzytelniania za pomocą loginu i hasła. w przypadku osób chcących korzystać z usługi w sposób anonimowy, nie będzie potrzeby dokonywania autoryzacji.

3) Odbiorcy: Użytkownicy korzystający z dróg wodnych w celach rekreacyjnych oraz

przedsiębiorcy będący użytkownikami dróg wodnych

2. Zgłaszania on-line uwag dotyczących drogi wodnej

1) Opis funkcjonalności: Funkcjonalność skierowana jest do wszystkich użytkowników śródlądowych dróg wodnych i stanowić będzie elektroniczny kanał komunikacji z administratorem dróg wodnych, umożliwiający wymianę informacji

o nieprawidłowościach, utrudnieniach, zagrożeniach lub innych zdarzeniach występujących na drogach wodnych lub obiektach infrastruktury technicznej.

Funkcjonalność umożliwia użytkownikom korzystającym z dróg wodnych:

a. rejestracji konta w systemie,

b. usunięcie konta z systemu,

c. dokonywanie zgłoszeń za pośrednictwem aplikacji mobilnej lub platformy WIR,

d. dokonywanie zgłoszeń poprzez opis lub wskazanie na mapie,

e. dodawanie georeferencji do zgłoszeń,

f. załączanie do zgłoszenia zdjęć i opisów,

g. szybkie zgłaszanie skatalogowanych zdarzeń za pomocą piktogramów,

h. podgląd zgłoszeń wg kategorii, lokalizacji, określanie statusów zgłoszeń i ich

uwierzytelniane przez administratorów i użytkowników,

i. potwierdzanie aktualności wcześniejszych zgłoszeń przez administratorów

i użytkowników.

3) Odbiorcy: Użytkownicy korzystający z dróg wodnych w celach rekreacyjnych oraz

przedsiębiorcy

Systemy zewnętrzne współpracujące z Systemem WIR (Otoczenie systemu)

1. Dane i integracja z innymi systemami

Zgodnie z prezentowanym diagramem system WIR powinien zostać zintegrowany

z następującymi systemami:

1) REGON,

2) TERYT,

3) Węzeł Krajowy,

4) PBDS (Polska Baza Danych Statków)

5) ISOK (IMGW, PGW WP – SIGW),

6) Xxxxxxxxx.xxx.xx,

7) RIS;

Integracja powinna obejmować co najmniej udostępnienie danych za pomocą powszechnie dostępnych usług sieciowych OGC, cyklicznego zasilania w postaci kopii danych lub innego dostępnego interfejsu.

System	Dane	Sposób wymiany danych	Typ interfejsu
REGON	Dane podmiotów gospodarki narodowej	Kopiowanie danych	SOAP, REST
TERYT	Dane adresowe	Kopiowanie danych	Usługa sieciowa TERYT
Węzeł Krajowy	Potwierdzenie danych identyfikacyjnych klientów	Tryb odwołań bezpośrednich	SAML
PBDS	Dane identyfikacyjne statków	Tryb odwołań bezpośrednich	Zapytanie SQL
ISOK- (IMGW)	Dane o zagrożeniach hydrologicznych i meteorologicznych	Tryb odwołań bezpośrednich	JSON, SOAP, WMTS

ISOK- SIGW (PGW WP)	Dane z zakresu gospodarki wodnej a w tym infrastruktury hydrotechnicznej	Cykliczne kopiowanie danych	JSON, SOAP.
Xxxxxxxxx.xxx.xx	Dane geo-przestrzenne	Tryb odwołań bezpośrednich	WMS, WMTS.
IT-GIS-OKI	Dane dot. zbiorników, obiektów hydrotechnicznych, zjawisk lodowych.	Kopia bazy danych (zasilenie inicjalne).	Kopia bazy danych (zasilenie inicjalne).
RIS	Słownik RIS INDEX	Kopiowanie danych	SOAP, REST

Użytkownicy Systemu WIR

Użytkownicy systemu WIR zostali podzielni na dwie główne grupy:

1. Odbiorcy wewnętrzni – pracownicy PGW WP na różnych szczeblach organizacyjnych (a w tym kadra zarządzająca i kierownicza, pracownicy poszczególnych departamentów, pracownicy terenowi):

a. KZGW (Krajowy Zarząd Gospodarki Wodnej)

b. RZGW (Regionalny Zarząd Gospodarki Wodnej),

c. ZZ (Zarząd Zlewni),

d. NW (Nadzór Wodny)

e. Obiekty hydrotechniczne.

2. Odbiorcy zewnętrzni - osoby prywatne korzystające z dróg wodnych w celach rekreacyjnych (np. podczas spływów kajakowych) oraz przedsiębiorcy będący użytkownikami dróg wodnych.

Podstawowe założenia architektoniczne

System będzie preferował rozwiązania o otwartym kodzie (Open Source). Zakłada się wykorzystanie elementów Open Source w następujących obszarach:

1. komponent integracyjny (szyna danych/usług systemu)

2. bazy danych systemu

3. Portal Zewnętrzny (w zakresie CMS)

4. serwer GIS

5. serwer aplikacyjny

6. systemy wirtualizacyjne

7. system analityczno-raportowy

W ramach tego typu oprogramowania Wykonawca zobowiązany jest co najmniej do:

a. Wyspecyfikowania dla wskazanych wyżej obszarów nazw i typów planowanego do wykorzystania oprogramowania Open Source już na etapie składania oferty (kryterium oceny ofert),

b. Dostarczenie aktualnej dokumentacji oraz licencji do użytku przez jednostki publiczne dla wszystkich wykorzystanych komponentów Open-Source,

c. Zagwarantowanie, że wykorzystanie oprogramowania Open Source nie będzie ograniczać PGW WP w zakresie rozpowszechniania innego oprogramowania połączonego z tym oprogramowaniem oraz że licencja na oprogramowanie Open Source nie będzie nakładać na PGW WP obowiązku odprowadzania jakichkolwiek opłat lub wynagrodzenia na rzecz podmiotów uprawnionych do takiego oprogramowania.

System zapewni możliwość integracji z innymi systemami informatycznymi poprzez dostarczenie interfejsów i zbioru usług sieciowych. API umożliwi łatwą integrację i dostęp do metadanych zasobów danych oraz grupujących je zbiorów.

System WIR będzie budowany zgodnie z zasadą niezależności technologicznej w konsekwencji

umożliwiając przenaszalność czyli funkcjonowanie na różnych platformach technologicznych. Tworząc platformę zakłada się powszechne i konsekwentne stosowanie standardów otwartych:

a. w zakresie projektowania architektury – metodyka TOGAF,

b. w zakresie modelowania systemów – notację UML,

c. w zakresie wymiany danych – standard XML, JSON,

d. w zakresie warstwy sieciowej – protokół IP,

e. w zakresie bezpieczeństwa – rozwiązania PKI, szyfrowanie danych HTTPS, standard

XML Signature, standard XML Encryption.

System WIR, ze względu na jego złożoność, będzie wykonany w architekturze trójwarstwowej, pozwalającej na odseparowanie warstw danych, logiki biznesowej oraz prezentacji.

Warstwa danych będzie składała się z bazy danych, w której gromadzone będą wszystkie dane potrzebne do działania systemu.

Warstwa logiki biznesowej składać się będzie z dwóch głównych elementów. Pierwszym z nich będzie serwer aplikacyjny, na którym zostanie osadzona główna logika biznesowa. Znajdą się tam zarówno serwer danych przestrzennych jak i wszystkie dedykowane i napisane na poczet systemu usługi.

Tutaj będą osadzone x.xx.:

a. serwisy służące do x.xx. zasilania bazy danych danymi referencyjnymi z obcych

systemów,

b. serwisy wspomagające transformację i ładowanie danych z systemów obcych do systemu WIR (narzędzia ETL),

c. serwisy metadanych,

d. oprogramowanie wspomagające zarządzanie całym systemem (manager serwera webowego, manager serwera danych przestrzennych, moduł administratora pozwalający na łatwe zarządzanie użytkownikami i ich uprawnieniami w systemie, manager bazy danych itp.),

e. serwer danych przestrzennych działający w technologii REST, umożliwiający publikację serwisów mapowych x.xx. w zgodności ze standardami OGC (WMS, WMTS, WFS, WCS),

f. wszystkie pozostałe serwisy, które będą obsługiwały inne, wyspecyfikowane funkcjonalności, dla których zasadnym będzie stworzenie wymaganych usług.

Warstwa prezentacji składać się będzie z szeregu aplikacji dedykowanych, służących do prezentacji danych, obsługi formularzy czy pobierania/wymiany danych w systemie. Zadania obsługiwane przez warstwę prezentacji będą dostępne zarówno dla użytkowników wewnętrznych jak i zewnętrznych.

WYMAGANIA DLA SYSTEMU WIR

Rejestr wymagań z podziałem na komponenty Systemu został zawarty w Załączniku nr 1.

System WIR musi spełniać wszystkie wymagania zawarte w Rejestrze wymagań (Załącznik nr 1 do OPZ).

WYMAGANIA W ZAKRESIE PROCESU WYTWÓRCZEGO

Poniższy opis procesu wytwórczego definiuje zbiór zadań do wykonania przez Wykonawcę celem

zaprojektowania, budowy, wdrożenia i ewentualnych zmian Systemu WIR.

Organizacja Realizacji Umowy

W terminie 30 dni po podpisaniu Umowy Wykonawca opracuje, w uzgodnieniu z Zamawiającym, Plan Realizacji Umowy obejmujący Harmonogram realizacji prac a także udostępni i skonfiguruje Narzędzie wspomagające proces wytwórczy.

Plan Realizacji Umowy powinien zawierać elementy wyszczególnione w rozdziale 11.1.1 Plan Realizacji Umowy. Plan Realizacji Umowy powinien uwzględniać wszystkie założenia dotyczące organizacji Projektu i realizacji Przedmiotu Zamówienia zawarte w niniejszym SOPZ oraz załącznikach.

Wykonawca zobowiązany jest do realizacji prac zgodnie z opracowanym i uzgodnionym przez strony Planem Realizacji Umowy oraz Harmonogramem. Wszelkie zmiany w dokumencie wymagają zgody Zamawiającego.

Przeprowadzenie wstępnej analizy rozwiązania

Opracowanie Dokumentacji Analitycznej

Celem opracowania Dokumentacji Analitycznej (DA) jest stworzenie spójnego projektu przyszłego rozwiązania spełniającego wszystkie wymagania.

W Dokumentacji Analitycznej zaprojektowana musi zostać zarówno część statyczna - architektura komponentów, model danych, jak i część dynamiczna, w tym x.xx. przypadki użycia, ich przebiegi wraz z docelowym interfejsem użytkownika. Wymagany zakres Dokumentacji Analitycznej został określony w rozdziale 11.2 Dokumentacja Analityczna.

Z uwagi na zastosowanie zwinnego podejścia do wytwarzania oprogramowania, prace związane

z opracowaniem Dokumentacji Analitycznej zostaną podzielone na następujące etapy:

1. Opracowanie inicjalnej postaci Dokumentacji Analitycznej (DA EZ1) – realizowane w ramach EZ1;

2. Opracowanie pełnej Dokumentacji Analitycznej, realizowane przyrostowo w ramach

poszczególnych cykli realizacyjnych EZ2 (sprintów) – realizowane w ramach EZ2.

W ramach opracowania inicjalnej postaci Dokumentacji Analitycznej w Etapie Zarządczym 1, Wykonawca wykorzystując Narzędzie wspomagające proces wytwórczy, zrealizuje poniższe kroki:

1. Wykonawca opracuje modele procesów biznesowych realizowanych przy wsparciu Systemu

WIR.

2. Wykonawca opracuje Architekturę Systemu WIR (architekturę fizyczną, logiczną, z podziałem na moduły funkcjonalne).

3. Wykonawca opracuje katalog wymagań Systemu WIR (przy wykorzystaniu Narzędzia wspomagającego proces wytwórczy).

4. Wykonawca zidentyfikuje wszystkie przypadki użycia wynikające z pełnego zakresu realizowanych wymagań stawianych względem Systemu WIR oraz przeprowadzi dekompozycje funkcjonalności (podział na komponenty funkcjonalne całych grup funkcjonalności). Wynikiem realizacji będzie opracowany Model przypadków użycia (bez szczegółowych przebiegów przypadków użycia).

5. Wykonawca opracuje Macierz powiązań wymagań funkcjonalnych z przypadkami użycia

Systemu WIR w podziale na moduły i grupy funkcjonalne

6. Wykonawca zaproponuje szczegółowy podział wymagań (zidentyfikowanych przypadków użycia) na poszczególne cykle przewidziane do realizacji w ramach Budowy Systemu WIR. Łączna liczba cykli oraz ich zakres oraz muszą zostać zaplanowane przez Wykonawcę w sposób, który zagwarantuje implementację wszystkich wymagań stawianych względem Systemu WIR w reżimie czasowym założonym w Harmonogramie Prac.

7. Wykonawca przeprowadzi analizę źródeł danych i opracuje ogólny model danych (który podlegać będzie uszczegółowieniom w poszczególnych sprintach),

8. Wykonawca opracuje założenia dla integracji Systemu WIR z systemami zewnętrznymi.

9. Wykonawca przygotuje i przekaże Zamawiającemu inicjalną postać Dokumentacji Analitycznej wraz z towarzyszącym modelem analitycznym.

W ramach poszczególnych cykli realizacyjnych EZ2 (sprintów), Wykonawca będzie zobowiązany do uzupełnienia Dokumentacji Analitycznej o szczegółowe wyniki analizy przeprowadzonej w ramach danego sprintu przy udziale Zamawiającego, przed rozpoczęciem prac wytwórczych.

W ramach doprecyzowania DA, wykonywanego w trakcie trwania każdego cyklu wytwórczego, muszą zostać zrealizowane poniższe kroki:

1. Wykonawca uszczegółowi opisy funkcjonalności (opisy sposobu realizacji wymagań)

przewidzianych do realizacji w ramach danego sprintu.

2. Wykonawca opracuje model przypadków użycia wraz z przebiegami przypadków użycia dla

wymagań przewidzianych do realizacji w ramach danego sprintu.

3. Wykonawca opracuje makiety ekranów dla funkcjonalności przewidzianych do realizacji

w ramach sprintu.

4. Wykonawca opracuje szczegółowy model danych (wraz ze słownikami) oraz sposób przetwarzania i zarządzania danymi, w tym zasady migracji danych i mapowanie zbiorów danych źródłowych na struktury bazy danych WIR w zakresie przewidzianym do realizacji w ramach sprintu.

5. Wykonawca opracuje matrycę ról i uprawnień systemowych w zakresie funkcjonalności

przewidzianych do realizacji w ramach danego sprintu.

Dokumentacja Analityczna opracowana w ramach pojedynczego cyklu wytwórczego (sprintu) musi odzwierciedlać funkcjonalność Systemu WIR dostarczaną w ramach danego cyklu wytwórczego (przyrost funkcjonalności). Zamawiający oczekuje wykorzystania Narzędzia wspomagającego proces wytwórczy w celu prowadzenia uzgodnień i akceptacji przez Zamawiającego szczegółowego sposobu realizacji funkcjonalności Systemu WIR.

Produktem finalnym, przekazanym na koniec ostatniego zrealizowanego cyklu wytwórczego, będzie kompletna Dokumentacja Analityczna dla Systemu WIR wraz z modelem analitycznym, który umożliwi weryfikację implementacji - jej kompletność, strukturę oraz zgodność z wymaganiami.

Zamawiający oczekuje maksymalnego wykorzystania Narzędzia wspomagającego proces wytwórczy

oraz Repozytorium analitycznego w zakresie automatyzacji procesu tworzenia dokumentacji.

Opracowanie Dokumentacji Technicznej

Celem opracowania Dokumentacji Technicznej jest doprecyzowanie rozwiązania na poziomie PSM (ang. Platform Specific Model), gdzie każdy zawarty w Dokumentacji Analitycznej komponent funkcjonalny musi mieć swoją realizację w formie fizycznych komponentów rozmieszczonych na Platformie. Wykonawca określi technologię implementacji wszystkich komponentów oraz opracuje model Platformy uwzględniający przeznaczoną na Projekt infrastrukturę sprzętową. Na podstawie zbudowanego modelu dla Platformy Wykonawca przygotuje Dokumentację Techniczną wraz z modelem analitycznym zawierającą wszystkie wymagane elementy określone w rozdziale 11.3.

Z uwagi na zastosowanie zwinnego podejścia do wytwarzania oprogramowania, prace związane

z opracowaniem Dokumentacji Technicznej zostaną podzielone na następujące etapy:

1. Opracowanie inicjalnej postaci Dokumentacji Technicznej (DT EZ1) – realizowane w ramach EZ1;

2. Opracowanie pełnej Dokumentacji Technicznej, realizowane przyrostowo w ramach

poszczególnych cykli realizacyjnych EZ2 (sprintów) – realizowane w ramach EZ2.

W ramach inicjalnej postaci Dokumentacji Technicznej w Etapie Zarządczym 1 muszą zostać

opracowane:

1. wizja logiczna architektury systemu,

2. projekt techniczny,

3. metoda opisu architektury technologicznej.

W ramach poszczególnych cykli wytwórczych (sprintów), Wykonawca będzie zobowiązany do uzupełnienia Dokumentacji Technicznej, zgodnie z zakresem cyklu wytwórczego, w zakresie wykonania opisu architektury technologicznej. w przypadku, gdy zakres danego sprintu nie powoduje konieczności aktualizacji/rozbudowy Dokumentacji Technicznej – produkt nie będzie podlegał aktualizacji w ramach danego sprintu.

Produktem finalnym, przekazanym na koniec ostatniego zrealizowanego cyklu wytwórczego, będzie

kompletna Dokumentacja Techniczna.

Opracowanie Prototypu Interfejsu Graficznego Użytkownika Systemu WIR

Wykonawca zobowiązany jest do opracowania Prototypu Interfejsu Graficznego Użytkownika dla

wytwarzanego Systemu WIR.

Prototyp ten musi prezentować spójną, wizualną koncepcję realizacji kluczowych wymagań i powinien mieć postać prototypu w formacie html, przedstawiającego proponowany wygląd ekranów/podstron Systemu WIR lub wybranych elementów interfejsu użytkownika, w szczególności takich jak szata graficzna, standardowe komponenty prezentacji oraz zarządzania treścią (pola tekstowe, listy, tabele, przyciski, linki, itp.) układ elementów oraz przycisków na widokach, przejścia pomiędzy ekranami, komunikaty błędów, itp..

Prototyp Interfejsu Graficznego Użytkownika powinien sprawiać wrażenie w pełni funkcjonalnego Systemu - musi on umożliwiać realizację zadań mających na celu weryfikację użyteczności rozwiązania i z tego powodu powinien zawierać kompleksową prezentację działania prototypowanych funkcjonalności, w szczególności powinien pozwalać użytkownikom końcowym Systemu na poznanie docelowej formy interakcji z poszczególnymi elementami interfejsu, w tym interakcji z mapą.

Prototyp Interfejsu Graficznego Użytkownika Systemu WIR powinien obejmować minimum:

a. Symulację pełnego procesu biznesowego dla wszystkich e-usług wytwarzanych w ramach Projektu WIR, oddzielnie z poziomu aplikacji webowej oraz aplikacji mobilnej;

b. 5 ekranów dla każdego z modułów funkcjonalnych Systemu WIR, prezentujących

zarys podstawowych funkcjonalności danego modułu.

Dla wyżej wymienionego zakresu Prototyp Interfejsu Graficznego musi zostać opracowany w dwóch wersjach, przedstawiających odmienny układ funkcjonalny oraz szatę graficzną, które to wersje zostaną poddane ocenie Użytkowników końcowych w ramach badań preferencji użytkowników opisanych w rozdziale 10.2.4. Opracowane dwie wersje Prototypu Interfejsu Graficznego powinny różnić się co najmniej:

a. Układem elementów interfejsu,

b. Krokami/ścieżką realizacji poszczególnych procesów biznesowych dla e-usług oraz prezentowanych podstawowych funkcjonalności dla modułów funkcjonalnych,

c. Szatą graficzną.

Opracowany Prototyp Interfejsu Graficznego podlegać będzie weryfikacji Zamawiającego w zakresie

zgodności w wymaganiami OPZ, zgodnie z procedurą odbiorową dla dokumentacji.

Biorąc pod uwagę fakt, iż do realizacji oprogramowania, zastosowany będzie zwinny model wytwórczy,

wybrany wariant Prototypu Interfejsu Graficznego Użytkownika zmodyfikowany w zakresie

uwag/sugestii po badaniach użyteczności stanowić będzie punkt wyjścia do dalszych prac w ramach Etapu Zarządczego 2.

Uruchomienie i pełna prezentacja Prototypu Interfejsu Graficznego powinna być możliwa przy użyciu przeglądarki Google Chrome (w najnowszej stabilnej wersji) na dowolnym systemie operacyjnym wspierającym tę przeglądarkę (w najnowszej stabilnej wersji). Pełne uruchomienie się prototypu w przeglądarce nie powinno trwać dłużej niż 15 sekund. Interakcja użytkownika z prototypem powinna skutkować bardzo szybką, sprawiającą wrażenie natychmiastowej reakcją przeglądarki na działania (czas reakcji <30ms).

Prototyp Interfejsu Graficznego nie może wymagać żadnych zewnętrznych zasobów dostępnych za pośrednictwem internetu (należy założyć, że może być uruchomiony na środowisku odciętym od sieci internetowej). Wszystkie składowe projektu prototypu powinny być dostępne lokalnie w strukturze katalogów projektu.

Przeprowadzenie badań preferencji użytkowników

Zadaniem Wykonawcy jest przeprowadzenie badań użyteczności Prototypu Interfejsu Graficznego

Użytkownika Systemu WIR z udziałem Użytkowników.

Badania użyteczności zostaną przeprowadzone z udziałem Użytkowników zaangażowanych przez Zamawiającego, przy czym odpowiedzialność za organizację badań leży po stronie Wykonawcy. Wykonawca powinien uwzględnić przeprowadzenie badań w podziale co najmniej na 4 grupy użytkowników:

1. Uczestnicy żeglugi rekreacyjnej,

2. Przedsiębiorcy będący użytkownikami dróg wodnych,

3. Pracownicy jednostek organizacyjnych PGW WP poziomu regionalnego,

4. Pracownicy jednostek organizacyjnych PGW WP poziomu centralnego.

Badanie użyteczności dla poszczególnych funkcjonalności, powinny być przeprowadzone, z udziałem przedstawicieli grupy Użytkowników, która jest docelowym odbiorcą danej funkcjonalności.

Badanie użyteczności Prototypów Interfejsu Graficznego zoptymalizowanych pod kątem komputerów standardowych musi być przeprowadzone z użyciem komputerów standardowych, natomiast badanie użyteczności dla Prototypów Interfejsu Graficznego aplikacji mobilnej musi być przeprowadzone z użyciem Urządzeń mobilnych. Badania powinny zostać poprowadzone przez moderatora (Badacza UX, zgodnie z rolami projektowymi określonymi w SWZ) przy zachowaniu wszelkich zasad i dobrych praktyk prowadzenia badań UX. Wykonawca zobowiązany jest do uzgodnienia z Zamawiającym formy badania: stacjonarnie/zdalnie.

Badanie użyteczności danej grupy funkcjonalności Systemu WIR, powinno być przeprowadzone,

z udziałem przedstawicieli grupy użytkowników, która jest docelowym odbiorcą funkcjonalności.

W terminie 10 dni roboczych przed planowanym badaniem użyteczności Wykonawca uzgodni z Zamawiającym Specyfikację badania użyteczności. Specyfikacja badania użyteczności powinna:

1. Zawierać opis szczegółów organizacyjnych przeprowadzanego badania w tym listę ekranów/ funkcjonalności podlegających badaniu wraz z przypisaniem do grupy Użytkowników, która będzie uczestniczyć w jego/jej badaniu,

2. Zawierać materiały, które zostaną poddane badaniu (prototypy),

3. Zawierać proponowany formularz, na którym uczestnicy będą zgłaszać problemy użyteczności,

4. Opisywać zakładaną metodykę dojścia do końcowych wniosków - kryteria oceny użyteczności interfejsu użytkownika.

W zależności od wybranej formy badania Wykonawca zobowiązany jest do:

1. w przypadku badania stacjonarnego:

a. przekazania wszystkim uczestnikom badania na 5 dni przed planowanym badaniem uzgodnionej z Zamawiającym specyfikacji badania, umożliwiającej uczestnikom przygotowanie się do badania, w tym w szczególności wskazującej wszystkie elementy niezbędne do przygotowania po stronie uczestników badania,

b. zapewnienia sali, w której odbywać się będą badania,

c. zapewnienia i przygotowania urządzeń dla wszystkich uczestników badania (komputerów standardowych oraz Urządzeń mobilnych).Wielkość pojedynczej grupy uczestników badania nie powinna przekraczać 12 osób.

2. W przypadku organizacji badania w formie zdalnej Wykonawca odpowiedzialny jest za:

a. przekazania wszystkim uczestnikom badania na 5 dni przed planowanym badaniem specyfikacji badania, umożliwiającej uczestnikom przygotowanie się do badania, w tym w szczególności wskazującej wszystkie elementy niezbędne do przygotowania po stronie uczestników badania,

b. zapewnienia odpowiedniego przygotowania uczestników badania do badań, w tym przekazanie dostępu do prototypów funkcjonalnych wraz z instrukcją uruchomienia ich na urządzeniach wykorzystywanych przez uczestników badania, w terminie 3 dni roboczych przed planowanym badaniem,

c. zapewnienia wsparcia telefonicznego dla uczestników badania w przypadku wystąpienia trudności w przygotowaniu do badania, w okresie po przekazaniu specyfikacji badania,

d. zapewnienia narzędzi umożlwiających przeprowadzenie badania w formie zdalnej, w terminie 2 dni przed planowanym badaniem.

Badanie powinno polegać na ocenie użyteczności pod kątem wyszukiwania problemów związanych z użytecznością, które z założenia są naruszeniami jednej z zasad dotyczących badanego interfejsu użytkownika. Zasady te muszą zostać opracowane przez Wykonawcę i przedstawione w specyfikacji badania. Punktem wyjścia dla tych zasad mogą być heurystyki Xxxxxx Xxxxxxxx, które powinny być uzupełnione i dostosowane do specyfiki Systemu WIR. w rezultacie wykonawca opracuje co najmniej

15 ww. zasad, w tym co najmniej 10 z nich będzie miało zastosowanie do funkcjonalności związanych

z interakcyjną mapą.

Każde jednostkowe badanie (sesja z udziałem uczestników) obejmować będzie następujące fazy:

1. Przygotowanie uczestników, w zakresie:

a. sposobu uruchomienia, zasad działania i ograniczeń prototypu,

b. scenariusza lub zadania jakie mają wykonać przy pomocy prototypów,

c. ww. zasad użyteczności, w kontekście których uczestnicy będą oceniać prototyp.

2. Indywidualna ocena prototypu, każdy uczestnik ocenia każdy prototyp indywidualnie i zapisuje stwierdzony problem na specjalnym formularzu.

3. Określenie wagi znalezionych problemów, usystematyzowanie od najbardziej istotnych do

najmniej istotnych.

4. Grupowe podsumowanie wyników, na którym uczestnicy wraz z projektantami prototypu,

określają, co należałoby zmienić w prototypie, aby dany problem wyeliminować.

Badanie użyteczności powinno zostać przeprowadzone w iteracjach, przy czym iteracja składa się

z następujących kroków:

1. Przygotowanie Prototypów Interfejsu Graficznego, które zostaną poddane badaniu (w 2

wersjach)

2. Badanie użyteczności Prototypów Interfejsu Graficznego.

3. Analiza wyników badania, która powinna skutkować:

a. opracowaniem Raportu z Badania użyteczności, zawierającego wytyczne do

poprawy użyteczności Prototypów Interfejsu Graficznego w następnej iteracji lub

b. podjęciem decyzji, że użyteczność Prototypu Interfejsu Graficznego jest

wystarczająca i nie jest potrzebna kolejna iteracja.

Na podstawie przeprowadzonych badań opinii Użytkowników Wykonawca sporządzi Raport z badania,

który zawierał będzie minimum:

1. rekomendację dotyczącą wyboru jednej z wersji graficznej na podstawie opinii użytkowników,

2. listę zidentyfikowanych problemów związanych z użytecznością określającą:

a. na czym polega dany problem,

b. jakiego elementu lub mechanizmu interfejsu użytkownika dotyczy,

c. wagę wpływu na użyteczność interfejsu użytkownika,

d. wytyczne do poprawy użyteczności Prototypu,

Ostateczna decyzja co do wyboru wersji graficznej oraz rekomendacji, które powinny zostać uwzględnione w projekcie graficznym zostanie podjęta przez Zamawiającego. Zamawiający zastrzega sobie możliwość do zgłoszenia uwag do opracowanego przez Wykonawcę Prototypu Graficznego Interfejsu Użytkownika Systemu WIR, które powinny zostać uwzględnione przez Wykonawcę.

Dla wybranej przez Zamawiającego (z uwzględnieniem wyników badania użyteczności) wersji Prototypu Interfejsu Graficznego Użytkownika, Wykonawca zobowiązany jest do opracowania finalnej wersji Prototypu Interfejsu Graficznego Użytkownika uwzględniającej wytyczne do poprawy użyteczności Prototypu i uwagi Zamawiającego.

Budowa Systemu WIR

Wykonawca przeprowadzi budowę Systemu WIR stosując przyrostowe podejście do realizacji prac

opisane w rozdziale 10.3.1.

Realizacja procesu wytwórczego będzie wykonywana z zastosowaniem:

a. Repozytorium analitycznego – narzędzia umożliwiającego przechowywanie i wersjonowanie modeli analitycznych za pomocą różnych notacji, w tym języka UML. Prowadzenie i aktualizacja repozytorium jest obowiązkiem Wykonawcy. Zamawiający nie wymaga dostępu do repozytorium. Przy każdym przekazaniu Dokumentacji Analitycznej Wykonawca przekaże Zamawiającemu kopię repozytorium w formacie możliwym do przeglądania w narzędziu Enterprise Architect oraz dostępnych na rynku narzędziach open source (możliwe do wykorzystania przez jednostki publiczne). Repozytorium analityczne musi być prowadzone i aktualizowane przez cały okres realizacji Umowy, tak aby było spójne z dokumentacją przekazywaną przez Wykonawcę.

b. Repozytorium kodu – narzędzia pozwalającego x.xx. na przechowywanie kodów źródłowych i realizację procesów automatyzacji i wdrażania usług IT. Prowadzenie i aktualizacja repozytorium jest obowiązkiem Wykonawcy. Zamawiający nie wymaga dostępu do repozytorium. Wykonawca na każde żądanie Zamawiającego przekaże Zamawiającemu w terminie 3 dni roboczych kopię repozytorium kodu.

c. Repozytorium wersji oprogramowania – systemu kontroli wersji, oprogramowania służącego do śledzenia zmian w kodzie źródłowym oraz pomocy programistom w łączeniu zmian dokonanych w plikach przez wiele osób w różnym czasie. Prowadzenie i aktualizacja repozytorium jest obowiązkiem Wykonawcy. Zamawiający nie wymaga dostępu do repozytorium. Wykonawca na każde żądanie Zamawiającego przekaże Zamawiającemu w terminie 3 dni roboczych kopię repozytorium wersji oprogramowania.

d. Narzędzia wspomagającego proces wytwórczy – narzędzie wspierające bieżącą współpracę stron, zwłaszcza w zakresie dokonywania uzgodnień co do sposobu realizacji wymagań, planowania i realizowania poszczególnych sprintów, planowania i realizowania testów UAT, śledzenia statusu realizacji prac.

Zwinne podejście do wytwarzania Produktów

Wykonawca zobowiązany jest do dostarczenia wszystkich Produktów Przedmiotu Zamówienia zgodnie

z opracowanym Harmonogramem Prac, przy jednoczesnym zachowaniu wysokiego poziom ich jakości.

w tym celu Wykonawca, w porozumieniu z Zamawiającym zaadaptuje i wdroży w ramach procesu wytwórczego wybrane „zwinne” (ang: agile) praktyki wytwarzania oprogramowania, których celem będzie zapewnienie spełnienia następujących wymogów:

1. Budowa oprogramowania będzie realizowana przyrostowo, szczegółowy sposób realizacji wymagań uzgadniany będzie z Zamawiającym przy udziale użytkowników końcowych Systemu WIR,

2. Celem każdego cyklu wytwórczego będzie dostarczenie inkrementu Systemu WIR w postaci

funkcjonalności podlegającej przeglądowi z udziałem użytkowników końcowych Systemu WIR,

3. Możliwa będzie stała i bezpośrednia komunikacja Zamawiającego z zespołem wytwórczym,

4. Dokumentacja Analityczna oraz Dokumentacja Techniczna będą podlegały doprecyzowaniu w ramach każdego cyklu wytwórczego (w stopniu niezbędnym do pełnego udokumentowania funkcjonalności dostarczonej w ramach danego cyklu wytwórczego),

Zamawiający zakłada udział użytkowników końcowych w procesie wytwarzania oprogramowania w zakresie określonym w poniższej tabeli.

Proces	Uczestnicy	Opis działań
Konsultacje rozwiązań	Wykonawca, Użytkownicy zewnętrzni, PGW WP	Analiza potrzeb użytkowników końcowych.
Projektowanie rozwiązań	Wykonawca, PGW WP	Na podstawie zebranych w ramach konsultacji potrzeb użytkowników końcowych zaprojektowanie wymagań względem docelowego rozwiązania.
Rozwiązywanie problemów wynikających z projektowanych rozwiązań	Wykonawca, PGW WP, Użytkownicy zewnętrzni	W przypadku pojawienia się potencjalnych problemów w projektowanych rozwiązaniach, Wykonawca przygotuje sposób rozwiązania przedmiotowego zagadnienia, sposób rozwiązania zagadnienia zostanie potwierdzony z PGW WP w ramach spotkań/ warsztatów/ konsultacji etc. oraz w szczególnym przypadku z użytkownikami końcowymi projektowanych funkcjonalności. w zależności od omawianego problemu, liczba użytkowników końcowych może się zmieniać,

		jednakże w ramach ustaleń uczestniczyć powinni przynajmniej jeden przedstawiciel docelowej grupy interesariuszy projektu.
Budowa rozwiązań	Wykonawca ,PGW WP	Wykonawca przygotuje rozwiązanie informatyczne na podstawie wszystkich wcześniej określonych procesów w tym opisanych powyżej działań.
Przeglądy sprintów/Testy	Wykonawca, Użytkownicy zewnętrzni, PGW WP	Użytkownicy zewnętrzni, PGW WP i Wykonawca będą zaangażowani do testowania uruchamianych funkcjonalności systemu

Zamawiający oczekuje, iż wybrane przez Wykonawcę oraz zaakceptowane przez Zamawiającego zwinne praktyki wytwarzania oprogramowania będą obejmowały co najmniej następujące czynniki zwinności:

1. Całkowity zakres prac zostanie podzielony na następujące po sobie cykle realizacyjne (zwane

również „sprintami”) o maksymalnej długości 5 tygodni.

1) Celem każdego ze sprintów będzie:

a. przygotowanie przyrostu funkcjonalności Systemu WIR,

b. przedstawienie prezentacji wytworzonej funkcjonalności w odniesieniu do dokumentacji analitycznej oraz weryfikacja poprawności implementacji funkcjonalności w stosunku do założeń analitycznych określonych w zaktualizowanej w ramach sprintu Dokumentacji Analitycznej i Technicznej,

c. aktualizacja dokumentacji odnoszącej się do danego zakresu dostarczonej funkcjonalności (Dokumentacja Analityczna oraz Techniczna) oraz dostarczenie pozostałej dokumentacji wymaganej w toku realizacji prac projektowych ujętej w Planie Realizacji Umowy.

2) Ramy każdego ze sprintów będą uwzględniać:

a. analizę wniosków i uwag zgłoszonych przez Zamawiającego do rezultatów prac poprzedniego sprintu i stosowne uwzględnienie ich w planie prac dla danego sprintu (punkt ten nie będzie realizowany w ramach pierwszego sprintu), z zastrzeżeniem, że dla uwag do oprogramowania zgłoszonych podczas przeglądu sprintu Strony uzgodnią odrębny (wcześniejszy niż przegląd kolejnego sprintu) termin prezentacji poprawionego oprogramowania,

b. analizę wymagań dla zaplanowanego zakresu sprintu, w tym także konsultację rozwiązań z użytkownikami końcowymi, określenie potrzeb użytkowników

końcowych (w tym Zamawiającego) oraz odpowiednie dostosowanie do nich interfejsu rozwiązania,

c. zaprojektowanie stosownych funkcji systemu, w tym przygotowanie i uzgodnienie z Zamawiającym makiet oraz modeli zgodnych z wymogami Dokumentacji Analitycznej i Technicznej,

d. realizację zaplanowanych wymagań w sposób pozwalający na bieżące monitorowanie postępu prac oraz aktywną komunikację pomiędzy Wykonawcą a Zamawiającym,

e. bieżące testowanie dostarczanego przyrostu funkcjonalności Systemu WIR przez

Wykonawcę,

f. przeprowadzenie prezentacji przyrostu funkcjonalności Systemu WIR (przeglądu sprintu), w tym zebranie uwag i spostrzeżeń Zamawiającego oraz zaangażowanych przez Zamawiającego przedstawicieli użytkowników Systemu WIR, mogących mieć wpływ na plan kolejnego sprintu. w ramach przeglądu sprintu Zamawiający dokona oceny zgodności wytworzonej funkcjonalności z uzgodnionymi założeniami realizacyjnymi w zakresie zgodności wytworzonej funkcjonalności z DA, w tym zwłaszcza z uzgodnionym sposobem realizacji wymagania, przebiegami PU oraz makietami. Wykonawca zobowiązany jest do sporządzenia notatki z przeglądu sprintu zawierającej listę ewentualnych uwag Zamawiającego oraz do ich obsłużenia w wyznaczonym terminie.

2. Przedstawiciele Zamawiającego będą włączeni w bieżące prace projektowe realizowane przez Wykonawcę, co najmniej w zakresie:

1) udzielania sugestii na etapie analizy wymagań i projektowania funkcjonalności

realizowanych w ramach sprintu,

2) konsultacji poprawności projektowanych funkcjonalności z wykorzystaniem Narzędzia wspomagającego proces wytwórczy zespół przedstawicieli Zamawiającego i Wykonawcy uzgodni, opisze i zatwierdzi dekompozycję wymagań biznesowych na wymagania rozwiązania, planowany przebiegu przypadków użycia, modele danych oraz planowane do zaimplementowania reguły biznesowe,

3) opiniowania uzupełnionej Dokumentacji analitycznej oraz Dokumentacji Technicznej (DT - opcjonalnie, jeśli konieczne) opracowywanej w ramach danego sprintu,

4) aktywnego uczestnictwa w przeglądach sprintu w celu potwierdzenia poprawności funkcjonalności utworzonych w ramach sprintu z dokumentacją analityczną:

a. Wykonawca, w terminie ustalonym z Zamawiającym (przy czym termin ten musi mieścić się w ramach czasowych danego sprintu), będzie zobowiązany do przeprowadzenia podsumowania rezultatów każdego ze sprintów w postaci prezentacji wyników sprintu, który będzie obejmował:

i. prez`entację wdrożonego na środowisku testowym przyrostu

funkcjonalności Systemu WIR wytworzonego w danym sprincie,

ii. omówienie prezentowanego przyrostu w odniesieniu do przyjętych założeń analitycznych,

iii. weryfikację poprawności realizacji prezentowanego przyrostu w odniesieniu do przyjętych założeń analitycznych (Dokumentacji Analitycznej oraz Dokumentacji Technicznej dla danego sprintu)

iv. określenie w jakim stopniu udało się osiągnąć określone dla danego przyrostu cele,

v. omówienie problemów napotkanych w trakcie realizacji bieżącego sprintu

i ewentualne zaplanowanie działań naprawczych na kolejny sprint,

vi. potwierdzenie zakresu kolejnego sprintu.

3. Zostanie zapewniona możliwość bezpośredniej, bieżącej komunikacji Zamawiającego i Wykonawcy przy użyciu dostępnych form komunikacji elektronicznej / bezpośredniej oraz za pomocą Narzędzia wspomagającego proces wytwórczy opisanego w rozdziale 7.2.

4. Zapewniona zostanie możliwość bieżącego monitorowania postępów prac w ramach danego

sprintu za pomocą Narzędzia wspomagającego proces wytwórczy opisanego w rozdziale 7.2.

W przypadku, gdy w toku prac analitycznych dla kolejnych sprintów, okaże się, że założenia uzgodnione z Wykonawcą podczas realizacji poprzednich sprintów są niepoprawne tzn. uniemożliwiają realizację wymagań w zakresie wynikającym z uzgodnień z Zamawiającym i/lub użytkownikami końcowymi Systemu WIR, Wykonawca zobowiązany jest do modyfikacji przyjętych założeń i dostosowania wszystkich wytworzonych Produktów, w tym Systemu, w zakresie umożliwiającym realizację wymagania zgodnie z uzgodnieniem z Zamawiającym i/lub użytkownikami końcowymi Systemu WIR. Czynności te są obowiązkiem Wykonawcy w ramach realizacji zamówienia podstawowego.

Środowisko testowe

Wykonawca będzie zobowiązany do utworzenia oraz utrzymywania środowiska testowego od momentu jego udostępnienia, przez cały okres trwania realizacji Przedmiotu Zamówienia (również w okresie trwania zamówienia objętego prawem opcji w przypadku jego uruchomienia).

Wykonawca będzie zobowiązany do udostępniania na środowisku testowym nowych wersji oprogramowania Systemu WIR od momentu udostępnienia tego środowiska. Wykonawca będzie zobowiązany do informowania Zamawiającego o każdorazowym graniu nowej wersji Systemu na środowisku testowym.

Wykonawca zapewni, aby środowisko testowe było zasilone danymi wymaganymi do przeprowadzenia testów, zatem jednym z zadań Wykonawcy będzie wykonanie migracji danych zgodnie z założeniami przedstawionymi w rozdziale 10.4.

Na środowisku testowym nie można wykorzystywać rzeczywistych danych osobowych. Wykonawca w ramach przygotowania danych na środowisku testowym musi dokonać ich anonimizacji. Za proces anonimizacji odpowiada Wykonawca. Zamawiający dopuszcza wykorzystanie rzeczywistych danych produkcyjnych, bez anonimizacji tych danych, jedynie w przypadku gdy do przeprowadzenia testów danej funkcjonalności, rzeczywiste dane osobowe są wymagane. w takiej sytuacji, po zakończeniu testów, dane będą niezwłocznie usunięte ze środowiska testowego. Za usunięcie danych ze środowiska testowego odpowiada Wykonawca.

Wykonawca musi zapewnić odpowiednią wydajność środowiska testowego, pozwalającą na sprawną weryfikację dostarczanej funkcjonalności.

Wykonawca zapewni Zamawiającemu dostęp do środowiska testowego.

Środowisko produkcyjne

Wykonawca przed przystąpieniem do testów wewnętrznych rozmieści (zainstaluje, skonfiguruje itp.) oprogramowanie na środowisku preprodukcyjnym (PRE_PROD), zbieżnym ze środowiskiem produkcyjnym, na Infrastrukturze teleinformatycznej dostarczonej w ramach niniejszego Przedmiotu Zamówienia. Na środowisku preprodukcyjnym zostaną przeprowadzone testy wewnętrzne i akceptacyjne (w tym testy integracji, testy wydajnościowe, testy funkcjonalne, bezpieczeństwa Wykonawcy i automatyczne, testy bezpieczeństwa, audyt dostępności). Podpisanie raportu z testów potwierdzającego pozytywny wynik testów akceptacyjnych rozpoczyna okres stabilizacji Systemu.

Po osiągnięciu stabilizacji Systemu Wykonawca odpowiedzialny jest za przeniesienie środowiska preprodukcyjnego (PRE_PROD) na środowisko produkcyjne (PROD) i udostępnienie produkcyjne Systemu.

Wykonawca przygotuje oraz udostępni Zamawiającemu środowisko produkcyjne z wdrożoną, kompletną i gotową do produkcyjnego użytkowana wersją Systemu WIR zgodnie z Harmonogramem Prac. Wykonawca zobowiązany jest do instalacji i konfiguracji Systemu na Infrastrukturze teleinformatycznej dostarczonej w ramach niniejszego Przedmiotu Zamówienia (określonej w rozdziale 12).

W ramach przygotowania środowiska produkcyjnego, Wykonawca przeprowadzi pełną migrację

danych zgodnie z wymogami przedstawionymi w rozdziale 10.4.

Migracja danych

Wykonawca przeprowadzi proces migracji danych z systemów źródłowych do Systemu WIR. W ramach przeprowadzenia migracji zostaną zrealizowane poniższe kroki:

1. Wykonawca opracuje model danych oraz przeprowadzi analizę danych niezbędnych do prawidłowego funkcjonowania wszystkich funkcjonalności Systemu WIR, w szczególności na etapie prac analitycznych uszczegółowi zakres danych podlegających migracji (wskazanych w Załączniku nr 3 do OPZ).

2. W wyniku powyższych czynności Wykonawca określi szczegółowy zakres danych

podlegających migracji oraz stworzy procedurę ich migracji, zawierającą minimum:

a. Wskazanie źródła danych do migracji oraz szczegółowy opis migrowanych danych,

b. Opis zasad weryfikacji migrowanych danych (spójność wewnętrzna, topologia, spójność z innymi danymi będącymi już w Systemie, zgodność z formatem, ilość, wsparcie narzędziowe dla automatycznej i półautomatycznej weryfikacji danych).

Dokumenty będą podlegać akceptacji Zamawiającemu.

3. Wykonawca zobowiązany jest do wskazania i migracji wszystkich danych niezbędnych do prawidłowego funkcjonowania wszystkich usług Systemu WIR. Załącznik nr 3 przedstawia minimalny zakres danych podlegających migracji, przy czym jeśli w ramach analizy zrealizowanej przez Wykonawcę i przy udziale Zamawiającego zostaną zidentyfikowane dodatkowe źródła danych niezbędne do prawidłowego działania funkcjonalności, będą one podlegać migracji danych w ramach niniejszego Przedmiotu Zamówienia.

4. Wykonawca dla migrowanych zbiorów danych przygotuje metody przetworzenia danych i zasili bazę danych WIR. Zasilenie obejmować będzie również słowniki wewnętrzne służące do pracy w systemie oraz uzgodnienie nazw migrowanych zasobów.

5. W przypadku przetworzenia danych źródłowych posiadających metadane, Wykonawca dostosuje metadane do docelowej formy zmigrowanych zbiorów danych.

6. Prace wykonane w ramach tego Zadania zostaną opisane w ramach Raportu z migracji danych.

Wykonawca przeprowadzi migrację danych co najmniej dwukrotnie:

a. przed przystąpieniem do testów wewnętrznych i akceptacyjnych;

b. po zakończeniu testów akceptacyjnych – przed uruchomieniem produkcyjnym Systemu WIR (zasilenie Systemu danymi lub przyrostowa migracja danych), zapewnienie spójności danych z danymi w bazach źródłowych aktualnymi na moment uruchomienia produkcyjnego Systemu.

W ramach realizowanych prac dot. migracji, Wykonawca w uzgodnionym terminie dokona:

1. Weryfikacji jakości danych zbiorów źródłowych,

2. Wyczyszczenia danych oraz standaryzacji (czyszczenie i standaryzacja oznacza dopasowanie wartości atrybutów opisowych do słowników, wyjaśnienie i poprawienie wartości niepasujących do schematów danych),

3. W przypadku stwierdzenia błędów w danych źródłowych, które skutkowałyby na poprawność procesu migracji, Wykonawca jest zobowiązany do przeprowadzenia wspólnie z Zamawiającym procesu poprawy danych w systemach źródłowych, o ile wcześniejsza analiza danych w systemach źródłowych wykaże taką potrzebę. w ramach procesu poprawy danych w systemach źródłowych, Wykonawca będzie wspierał Zamawiającego poprzez tworzenie skryptów i innych narzędzi pozwalających na poprawę danych. Jeżeli na skutek analizy okaże się, że jedyną formą poprawy danych jest ich ręczna edycja wówczas, takiej poprawy dokona Zamawiający w swoich systemach źródłowych,

4. Wykonawca jest zobowiązany do opracowania narzędzi i mechanizmów służących migracji i ich stałej aktualizacji o ile zachodzi taka potrzeba, tj. na skutek prowadzonych analiz, migracji próbnych czy testów,

5. Konwersji danych ze zbiorów źródłowych do docelowych struktur modelu danych,

6. Weryfikacji spójności zmigrowanych danych na poziomie strukturalnym,

7. Ewentualnego podziału danych uwzględniającego zaprojektowane w ramach struktur bazodanowych partycje logiczne lub fizyczne,

8. Anonimizacji danych.

Całkowita odpowiedzialność za poprawność przebiegu procesu inicjalnego zasilenia danych leży po stronie Wykonawcy. w przypadku, kiedy Wykonawca dobierze złe, lub wykorzysta źle narzędzie do migracji danych, w skutek czego powstaną błędy podczas migracji danych, rozwiązanie tego problemu będzie po stronie wykonawcy (np. poprawa danych lub wykonanie powtórnie migracji).

Kontrola danych dotyczy zarówno poprawności technologicznej tj. sposobu zapisu danych, parametrów technicznych np. topologia sieci, zgodności ze standardami wymiany danych jak i poprawności merytorycznej tj. kompletności danych (przeniesienie wszystkich obiektów i wszystkich atrybutów), spełnienia wymogów dokładnościowych i zgodności danych z bazami źródłowymi.

W przypadku stwierdzenia wadliwości i niespójności zbiorów danych stanowiących rejestry urzędowe lub rejestry Zamawiającego Wykonawca jest zobligowany do udokumentowania tego faktu w formie stosownego raportu i przekazania Zamawiającemu.

Na koniec realizacji zadania, Wykonawca w Raporcie z wdrożenia uwzględni elementy związane z wynikiem migracji danych, w tym wyniki przeprowadzonych przez Wykonawcę testów poprawności migracji zgodnie ze scenariuszami zawartymi w Planie migracji, co będzie podstawą odbioru prac związanych z migracją. Zamawiający zastrzega również możliwość przeprowadzenia weryfikacji poprawności przeprowadzonej migracji danych.

Zarządzanie zmianą

W celu zapewnienia sprawnej realizacji wymagań, przewiduje się zastosowanie Procedury zarządzania

zmianą.

Procedura zarządzania zmianą określać będzie proces zarządzania wszelkimi odchyleniami w stosunku

do takich wskaźników jak: czas, koszt, jakość i zakres.

Zdefiniowane w procesie realizacji Umowy zmiany, mogą mieć charakter kosztowy i bezkosztowy. Jako zmiana kosztowa rozumiana jest dodatkowa funkcjonalność zidentyfikowana w toku procesu

wytwórczego, nie wynikająca z wymagań określonych OPZ, Umowie oraz załącznikach do tych dokumentów.

Zmiany bezkosztowe to, x.xx.:

a. wymagania wynikające z dekompozycji wymagań biznesowych na wymagania

rozwiązania,

b. doszczegółowienia wymagań wynikające z uzgodnień z użytkownikami końcowymi Systemu WIR, w tym dotyczących planowanego przebiegu przypadków użycia, modeli danych oraz planowanych do zaimplementowania reguł biznesowych,

c. modyfikacje w zakresie przypisania wymagań z do poszczególnych sprintów, podziału/połączenia wymagań, zmiany wyceny lub kryteriów odbioru wymagań. Realizacja wymienionych wyżej wymagań jest obowiązkiem Wykonawcy w ramach realizacji zamówienia podstawowego.

Zastosowanie procedury zarządzania zmianą może mieć miejsce również w przypadku zaistnienia zmian prawnych wpływających na zakres funkcjonalności Systemu WIR.

Każda zmiana wymagań polegać będzie weryfikacji zakresu oraz szacowaniu wartości proponowanej modyfikacji. w przypadku gdy zmiana zostanie uznana za zasadną do realizacji określony zostanie sposób jej realizacji. Zmiana będzie mogła zostać zrealizowana poprzez zastąpienie inną wskazaną z katalogu wymagań poprzez porównie wartości wymagania pierwotnego oraz docelowego. Zmiana wymagań będzie możliwa jeśli oszacowane rozmiary oprogramowania będą się bilansować. Dopuszcza się różnicę pomiędzy szacowanymi wartościami nie większe niż 10% rozmiaru oprogramowania realizującego wymagania źródłowe.

W przypadku, gdy różnice pomiędzy szacowanymi wartościami są większe należy zastosować zmianę sposobu realizacji wymagania docelowego lub wykorzystać budżet przwidziany na usługi dodatkowych modyfikacji.

Realizacja każdej zmiany wymaga akceptacji zarówno Zamawiającego jak i Wykonawcy.

W przypadku zmiany zakresu Systemu, należy zmodyfikować wytworzoną dotychczas Dokumentację Analityczną, Dokumentacją Techniczną oraz Plan Testów w celu zachowania spójności pomiędzy dokumentacją a Systemem. Uzgodnione zmiany powinny także zostać uwzględnione w Narzędziu wspomagającym proces wytwórczy we wszystkich elementach, w tym w szczególności w katalogu wymagań oraz przeprocedowane w rejestrze zmian. Utrzymywanie spójności dokumentacji jest zobowiązaniem po stronie Wykonawcy.

Stabilizacja Systemu

Celem stabilizacji Systemu WIR jest osiągnięcie pełnej konfiguracji, parametryzacji oraz niezawodności Systemu. Warunkiem rozpoczęcia stabilizacji systemu jest pozytywny wynik testów akceptacyjnych, potwierdzony podpisaniem Raportu z Testów Akceptacyjnych. Wykonawca przed okresem stabilizacji Systemu udostępni środowisko produkcyjne PROD użytkownikom końcowym. w ramach udostępnienia Systemu Wykonawca przekaże wszystkie dostępy do utworzonych kont użytkownikom końcowym. Wraz z przekazaniem dostępów Wykonawca przygotuje i przekaże Zamawiającemu Raport z przekazanych dostępów.

W ramach przedmiotowych prac Wykonawca zobowiązany jest do świadczenia usługi stabilizacji od momentu udostępnienia Systemu użytkownikom końcowym. w okresie stabilizacji Wykonawca nie tylko usuwa zgłoszone Błędy ale również ułatwia użytkownikom wdrożenie się do pracy w Systemie, działania te realizuje poprzez x.xx. udzielanie informacji na temat jego działania. Komunikacja odbywa się z wykorzystaniem kanału uzgodnionego z Zamawiającym (np. konsultacje telefoniczne, kanał na

platformie MS Teams). Osiągnieciem stabilizacji Systemu i jednocześnie zakończeniem świadczenia przez Wykonawcę serwisu stabilizacji będzie moment, w którym przez okres ustalony wspólnie z Zamawiającym (podczas uzgadniania terminów szczegółowego harmonogramu Planu Etapu Zarządczego nr 3), nie wystąpią żadne błędy krytyczne i/lub błędy poważne (zdefiniowane w rozdziale 13.1.1). w razie wystąpienia jakichkolwiek błędów Wykonawca zobowiązany jest do ich naprawy oraz w razie potrzeby aktualizacji dokumentacji. w przypadku wystąpienia błędów krytycznych oraz poważnych w czasie stabilizacji Systemu, okres liczony jest od początku, od chwili naprawy ostatniego błędu. w przypadku przekroczenia w okresie stabilizacji dopuszczalnej liczby Błędów, Zamawiający może, lecz nie musi, uznać System za stabilny, gdy wszystkie stwierdzone Wady zostały usunięte w satysfakcjonujący go sposób i w najkrótszym możliwie terminie. Wykonawca po ustabilizowaniu Systemu i zakończeniu świadczenia serwisu stabilizacji przygotuje i przekaże Zamawiającemu Raport z wykrytych i naprawionych błędów zawierający szczegółowe informacje o błędach, ich stanie, kategorii i sposobie rozwiązania. Osiągnięcie stabilizacji Systemu, potwierdzone podpisanym Raportem z wykrytych i naprawionych błędów, jest warunkiem niezbędnym dla odbioru Etapu Zarządczego nr 3.

Wykonawca po zakończeniu wszystkich działań związanych z poprawkami wynikającymi ze stabilizacji Systemu przekaże zaktualizowaną o zmiany Dokumentację powykonawczą. Dokumentacja musi być zgodna z wymaganiami określonymi w rozdziale 11.12.

Produkcyjne uruchomienie Systemu

Po pomyślnym ustabilizowaniu Systemu Wykonawca udostępni eksploatacyjnie System użytkownikom końcowym na środowisku produkcyjnym PROD.

System wdrożony w wersji produkcyjnej powinien być w pełni przygotowany do wykorzystania przez wszystkich użytkowników i być skonfigurowany i zasilony w taki sposób, aby dowolni użytkownicy wewnętrzni jak i zewnętrzni mogli z niego korzystać w pełnym zakresie wynikającym z ich ról i uprawnień. Dla Zamawiającego oznaczać to będzie możliwość normalnego prowadzenia codziennej pracy.

Ewaluacja i optymalizacja

Po uruchomieniu produkcyjnym Systemu WIR Zamawiający planuje przeprowadzenie badania satysfakcji użytkowników końcowych w postaci ankiety. Wynikiem tych działań będzie raport zawierający ocenę satysfakcji użytkowników oraz dane na temat mocnych i słabych stron e-usług i funkcjonalności Systemu WIR, z punktu widzenia jej odbiorców. Badania odbędą się po miesiącu oraz po upływie 6-ciu miesięcy od uruchomienia produkcyjnego Systemu WIR.

Badanie zostanie przeprowadzone oddzielnie dla każdej e-usługi z uwzględnieniem specyfiki grupy odbiorców. Badania satysfakcji obejmą również wdrożone funkcjonalności systemu oraz aplikację mobilną.

Wynikiem badania będzie raport z badania zawierający listę rekomendacji do optymalizacji usługi

i zwiększenia satysfakcji użytkowników.

Badania satysfakcji zostaną zrealizowane przez Zamawiającego. Wykonawca zobowiązany będzie do analizy wyników raportu oraz przedstawienia rekomendacji w zakresie optymalizacji usług oraz funkcjonalności Systemu WIR.

WYMAGANA DOKUMENTACJA

Niniejszy rozdział określa szczegółowe wymagania w zakresie dokumentacji.

Wykonawca zobowiązany jest do dostarczania dokumentacji wynikającej z niniejszego Przedmiotu Zamówienia zgodnie z wymaganiami Zamawiającego. Poszczególne dokumenty będą tworzone zgodnie z przygotowanymi przez Wykonawcę i zaakceptowanymi przez Zamawiającego szablonami.

Wszystkie dokumenty oraz modele analityczne muszą zostać dostarczone w języku polskim z zachowaniem ogólnie przyjętych zasad poprawności językowej. Dopuszczalne jest przekazanie niektórych elementów dokumentacji w języku angielskim (dotyczy instrukcji obsługi produktów, dla których dokumentacja udostępniana przez producenta występuje tylko w języku angielskim). Dopuszczalne jest również przywołanie w języku angielskim nazw lub tytułów dokumentów opracowanych w języku angielskim z dokładnym podaniem źródła, bez konieczności tłumaczenia.

Zamawiający wymaga, aby wszystkie dokumenty opracowywane w ramach Przedmiotu Zamówienia charakteryzowały się wysoką jakością, na którą będą miały wpływ takie czynniki jak:

a. struktura dokumentu, rozumiana jako podział danego dokumentu, w czytelny i zrozumiały sposób, na rozdziały, podrozdziały i sekcje,

b. kompletność dokumentu, rozumiana jako pełne, bez wyraźnych, ewidentnych braków, przedstawienie omawianego problemu obejmujące całość danego zakresu rozpatrywanego zagadnienia,

c. 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,

d. zachowanie standardów, 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.

W przypadku, gdy przekazana do weryfikacji Zamawiającego dokumentacja charakteryzować się będzie bardzo niską jakością, Zamawiający zastrzega sobie prawo odmówienia weryfikacji dokumentacji. Poprzez dokumentację o bardzo niskiej jakości rozumiana jest:

a. dokumentacja zawierająca minimum 50 błędów na 10% dokumentu, gdzie jako błąd rozumiane jest niespełnienie wyżej wymienionych zaleceń,

lub

b. dokumentacja niekompletna – zawierająca braki w zakresie opracowania rozdziałów lub podrozdziałów wynikających z zaakceptowanego szablonu dokumentu.

W takiej sytuacji Wykonawca zobowiązany jest do poprawy dokumentacji i jej ponownego przekazania do weryfikacji Zamawiającego. Odmówienie weryfikacji dokumentacji nie stanowi pierwszej tury weryfikacji dokumentacji.

Dokumentacja do weryfikacji Zamawiającego może być przekazywana w formie elektronicznej. Dokumentacja w wersji podlegającej odbiorowi powinna być przekazywana Zamawiającemu w formie wskazanej przez Zamawiającego: drukowanej (papierowej) – 1 egzemplarz i/lub elektronicznej. Poprzez dokumentację elektroniczną rozumie się płytę CD/DVD na której wszystkie produkty będą nagrane, (1) w wersji „do czytania” tj. w formacie PDF, oraz (2) w wersji „do edycji” tj. w źródłowych formatach umożliwiających edycję i nawigację, w których określone dokumenty były przygotowywane, np. harmonogramy w formacie zgodnym z MSProject, arkusze kalkulacyjne w formacie zgodnym z MSExcel, pliki edytorów danych w formacie zgodnym z MSWord, projekty UML w formacie zgodnym z Enterprise Architect, umożliwiającym ich edycję w narzędziach open source. Zaakceptowana w ramach odbiorów dokumentacja dostarczona do Zamawiającego staje się jego własnością.

Wykonawca zobowiązany jest do aktualizowania dokumentacji, o ile zachodzi taka konieczność

i przekazania jej Zamawiającemu w uzgodnionym terminie, w trybie zgodnym z procedurą zmian.

Wszystkie przekazywane dokumenty powinny zostać odpowiednio oznakowane. Na stronie tytułowej dokumentu musi znajdować się znak Unii Europejskiej i znak Funduszu Spójności, zgodnie z Podręcznikiem wnioskodawcy i beneficjenta programów polityki spójności 2014-2020 w zakresie informacji i promocji oraz informacja nt. projektu, w ramach którego powstał System WIR.

Dokumentacja zarządcza

W ramach dokumentacji zarządczej Wykonawca zobowiązany jest do opracowania w szczególności:

1. Planu Realizacji Umowy,

2. Planu Etapu – dla każdego Etapu Zarządczego (z wyjątkiem Etapu Zarządczego 1),

3. Raportu Końcowego Realizacji Umowy.

Plan Realizacji Umowy

W terminie 30 dni od podpisania Umowy Wykonawca zobowiązany jest do opracowania i uzgodnienia z Zamawiającym Planu Realizacji Umowy. Plan Realizacji Umowy powinien zawierać najważniejsze informacje związane z zarządzaniem Przedmiotem Umowy w odniesieniu do niniejszego Zamówienia. Plan Realizacji Umowy powinien zawierać co najmniej:

1. Organizację realizacji Umowy (opisująca x.xx strukturę organizacyjną zespołu Wykonawcy

i Zamawiającego),

2. Opis Produktów,

3. Harmonogram prac uwzględniający podział na Etapy Zarządcze i Techniczne,

4. Opracowanie Procedury Zarządzania Jakością, Konfiguracją, Ryzykiem, Komunikacją i Zmianą, (Procedury mające na celu prawidłową realizację zakresu postępowania, zgodne z regulacjami wewnętrznymi),

5. Wzory dokumentów.

Harmonogram uwzględniać powinien zadania zmierzające do dostarczenia konkretnych produktów pogrupowanych w etapy zarządcze. Harmonogram określał będzie planowane podejście Wykonawcy do realizacji wszystkich zadań i Produktów wytwarzanych w ramach niniejszego Przedmiotu Zamówienia.

Wykonawca zobowiązany jest do opracowania Harmonogramu prac w taki sposób, aby minimalizować ilość równolegle przekazywanych do weryfikacji Zamawiającego Produktów. Ilość równolegle przekazywanych do weryfikacji Zamawiającego produktów nie powinna przekraczać maksymalnie dwóch produktów.

Plan Etapu

Dla każdego Etapu Zarządczego (z wyjątkiem Etapu Zarządczego nr 1) Wykonawca zobowiązany jest do opracowania i uzgodnienia z Zamawiającym Planu Etapu. Plan Etapu powinien zostać opracowany i uzgodniony przed rozpoczęciem etapu, którego dotyczy. Plan Etapu powinien zawierać szczegółowe informacje o charakterze zarządczym, które są niezbędne celem wykonania wszystkich zadań zaplanowanych na dany Etap Zarządczy, w tym co najmniej:

1. Opis Produktów, które będą realizowane w danym Etapie Zarządczym – określający konspekt

zawartości produktu

2. Diagram/wykaz następstwa Produktów – diagram/wykaz prezentujący zależności pomiędzy poszczególnymi Produktami wytwarzanymi w ramach danego Etapu Zarządczego, określający kolejność wytwarzania produktów,

3. Harmonogram dla Etapu Zarządczego – prezentujący terminy realizacji zadań zmierzających do dostarczenia Produktów Etapu Zarządczego.

Harmonogram dla Etapu Zarządczego musi zakładać odbiór Produktów najpóźniej w terminach zakończenia Etapów Technicznych opisanych w rozdziale 5. Harmonogram musi uwzględniać dwie iteracje przekazania do weryfikacji przez Zamawiającego wszystkich Produktów (zgodne z terminami na weryfikację poszczególnych Produktów przez Zamawiającego określonych w niniejszym dokumencie). Jeżeli w danym Etapie Technicznym występuje następstwo produktów, Wykonawca musi uwzględnić je w harmonogramie. Dla Etapu Zarządczego 2 Harmonogram musi uwzględniać terminy przeglądów sprintów. w ramach harmonogramu Wykonawca wskaże i uzgodni z Zamawiającym, terminy wymagające zaangażowania pracowników Zamawiającego (np. badania, uzgodnienia, szkolenia, itd.). Harmonogram dla Etapu Zarządczego musi uwzględniać ramy realizacji projektu określne w Planie Realizacji Umowy.

Raport Końcowy Realizacji Umowy

Wykonawca zobowiązany jest do opracowania Raportu Końcowego Realizacji Umowy. Raport Końcowy Realizacji Umowy będzie określał przebieg realizacji Umowy w porównaniu z pierwotną wersją Planu Realizacji Umowy podsumowując wszystkie zrealizowane prace w ramach Przedmiotu Zamówienia. Raport Końcowy Realizacji Umowy musi zawierać co najmniej takie informacje jak:

1. Datę sporządzenia raportu,

2. Sprawozdanie Kierownika Projektu Wykonawcy,

3. Przegląd Produktów,

4. Raport doświadczeń.

Dokumentacja Analityczna

Dokumentacja Analityczna powinna opisywać architekturę biznesową rozwiązania oraz precyzować wymagania rozwiązania z wykorzystaniem adekwatnych modeli analitycznych.

Dokumentacja Analityczna powinna zawierać najmniej następujące elementy:

1. Logiczne modele procesów biznesowych przewidzianych do realizacji przy wsparciu Systemu WIR (element opisu wymagania opracowywany w ramach EZ1),

2. Model Architektury Systemu WIR (element opisu wymagania opracowywany w ramach EZ1):

a. Model komponentów przedstawiających wszystkie moduły Systemu WIR,

b. Model logicznych magazynów danych,

c. Model integracji (wewnętrznej oraz z systemami zewnętrznymi).

3. Katalog wymagań rozwiązania (funkcjonalnych i pozafunkcjonalnych), zawierający dla każdego

wymagania minimum:

a. nazwę wymagania (element opisu wymagania opracowywany w ramach EZ1),

b. opis sposobu realizacji wymagania wraz ze wzorami i zakresem wyjściowym dokumentów i raportów generowanych przez system, jeżeli dane wymaganie ich dotyczy (element opisu wymagania opracowywany w ramach EZ1 i uszczegółowiony w EZ2,

c. przypisany numer sprintu(element opisu wymagania opracowywany w ramach EZ1),

d. kryteria akceptacji (element opisu wymagania opracowywany w ramach EZ1 i uszczegółowiony w EZ2),

e. przypisany obszar (element opisu wymagania opracowywany w ramach EZ1 i uszczegółowiony w EZ2),

f. przypisanego właściciela biznesowego (element opisu wymagania opracowywany w ramach EZ1),

g. przypisanego analityka wykonawcy (element opisu wymagania opracowywany w ramach EZ1),

h. wycenę pracochłonności analityczną (element opisu wymagania opracowywany w ramach EZ1),

i. wycenę pracochłonności developerską(element opisu wymagania opracowywany w ramach EZ1),

Dokumentacja Analityczna musi zawierać podział wymagań na poszczególne cykle realizacyjne (sprinty) planowane do zrealizowania w ramach Budowy Systemu WIR.

4. Model przypadków użycia w notacji UML wraz z katalogiem aktorów (z wyłączeniem diagramów aktywności prezentujących scenariusze przebiegu przypadku użycia które zostaną opracowane w ramach poszczególnych cykli realizacyjnych w EZ2). Specyfikacja każdego przypadku użycia powinna określać:

a. Nazwę oraz unikalny identyfikator przypadku użycia,

b. Cel przypadku użycia,

c. Warunki początkowe,

d. Warunki końcowe,

e. Wskazanie aktorów przypadku użycia,

f. Diagramy aktywności prezentujących scenariusze przebiegu przypadku użycia,

g. Powiązane makiety interfejsu użytkownika prezentujące realizację przypadku

użycia,

5. Macierz powiązań wymagań funkcjonalnych z funkcjami/przypadkami użycia Systemu WIR

w podziale na moduły i grupy funkcjonalne w formacie xls, pdf lub doc,

6. Model danych (wraz ze słownikami i nazwami tabel),

7. Analizę źródeł danych dla Systemu WIR oraz sposobów ich przetwarzania i zarządzania, w tym zasady migracji danych i mapowanie zbiorów danych źródłowych na struktury bazy danych WIR,

8. Opis integracji Systemu WIR z systemami zewnętrznymi,

9. Matrycę ról i uprawnień systemowych,

10. Makiety interfejsu użytkownika (projekty ekranów) muszą zawierać rozmieszczenie poszczególnych elementów interfejsu wraz ze wskazaniem funkcjonalności realizowanych poprzez dany element interfejsu oraz sposoby nawigacji pomiędzy poszczególnymi elementami interfejsu wraz z określeniem przejścia pomiędzy ekranami.

Dokumentacja Analityczna musi być zdefiniowana w postaci modelu analitycznego z wykorzystaniem

notacji UML 2.5 oraz BPMN 2.0 (wyjątek stanowią makiety interfejsu użytkownika).

Dokumentacja Analityczna w zakresie określonym w niniejszym rozdziale będzie podlegała procedurze

odbioru w ramach Etapu Zarządczego 1 oraz Etapu Zarządczego 2.

Wykonawca zobowiązany jest do aktualizowania dokumentacji w ramach EZ3, o ile zachodzi taka

konieczność.

Dokumentacja Techniczna

Dokumentacja Techniczna powinna opisywać architekturę technologiczną rozwiązania, w tym: oprogramowanie aplikacyjne i jego infrastrukturę oraz logiczną architekturę sprzętową.. Dokumentacja Techniczna powinna zostać przygotowana z uwzględnieniem co najmniej poniższych wymogów:

1. Dokumentacja Techniczna musi zawierać opis projektowanych rozwiązań technicznych umożliwiających dostarczenie rozwiązania zgodnie ze wskazanymi funkcjonalnościami.

2. Dokumentacja Techniczna musi zawierać co najmniej:

1) wizję architektury systemu, w tym x.xx.:

a. model komponentów fizycznych systemu wraz z opisem komunikacji pomiędzy poszczególnymi komponentami;

b. założenia i ograniczenia architektoniczne, w tym dotyczące platformy sprzętowo- programowej (Infrastruktury teleinformatycznej), transakcyjności, bezpieczeństwa, w tym: integralności, rozliczalności i autentyczności, niezawodności, dostępności, wydajności i wolumetrii;

c. widoki architektoniczne obejmujące domenę aplikacji, danych oraz infrastruktury sprzętowej;

d. architekturę integracji z systemami/serwisami zewnętrznymi;

e. magazyny danych.

2) projekt techniczny infrastruktury sprzętowej i sieciowej (x.xx. szczegółowe informacje na temat sprzętu i jego umiejscowienia, topologię sieci łącznie z adresacją interfejsów sieciowych komponentów Systemu) wraz z analizą infrastruktury sprzętowej Zamawiającego;

3) opis architektury technologicznej, w tym:

a. metodę opisu;

b. fizyczny model danych w ramach wybranej technologii rozumiany jako opracowanie struktur bazodanowych w określonych technologiach. Model dziedziny musi się mapować na struktury bazodanowe w celu identyfikacji zbiorów danych

c. opis oprogramowania aplikacyjnego, tj. komponenty technologiczne konieczne do dostarczenia, które zawierają funkcjonalności systemu wraz z mapowaniem na elementy infrastruktury oprogramowania (środowisko programowe);

d. opis infrastruktury oprogramowania - środowisk programowych, w ramach

których funkcjonują komponenty aplikacyjne;

e. opis fizycznej infrastruktury sprzętowej w tym warstwy serwerów, warstwy wirtualizacji, warstwy pamięci masowej, warstwy sieciowej, warstwy kopii zapasowych, warstwy bezpieczeństwa;

f. opis logiczny infrastruktury sprzętowej w tym warstwy serwerów, warstwy wirtualizacji, warstwy pamięci masowej, warstwy sieciowej, warstwy kopii zapasowych, warstwy bezpieczeństwa;

g. opis wraz z logiką przełączania się ośrodków przetwarzania danych.

h. Opis wymaganych połączeń (wskazanie który komponent komunikuje się po jakim

adresie IP i porcie TCP/UDP z innym komponentem) podczas eksploatacji Systemu,

i. Opis interfejsów komunikacji z systemami zewnętrznymi (API).

Z uwagi na iteracyjny charakter prac nad Dokumentacją Techniczną, Wykonawca będzie zobowiązany

do:

1. Opracowania Dokumentacji Technicznej w ramach EZ1 w zakresie wykonania:

1) wizji architektury systemu,

2) projektu technicznego,

3) metody opisu architektury technologicznej,

2. Rozbudowy Dokumentacji Technicznej w ramach EZ2 w zakresie wykonania opisu architektury technologicznej na etapie poszczególnych sprintów w zakresie odpowiadającym dostarczanemu inkrementowi funkcjonalności. w przypadku, gdy zakres danego sprintu nie powoduje konieczności aktualizacji/rozbudowy Dokumentacji Technicznej – produkt nie będzie podlegał aktualizacji w ramach danego sprintu.

Architektura systemu musi być zdefiniowana w postaci modelu przy użyciu narzędzia Enterprise

Architect z wykorzystaniem notacji UML 2.5.

Dokumentacja Techniczna w zakresie określonym w niniejszym rozdziale będzie podlegała procedurze

odbioru w ramach Etapu Zarządczego 1 oraz Etapu Zarządczego 2.

Wykonawca zobowiązany jest do aktualizowania dokumentacji w ramach EZ3, o ile zachodzi taka

konieczność.

Specyfikacja badania użyteczności Prototypu Interfejsu Graficznego

W terminie minimum 10 dni roboczych przed rozpoczęciem badania użyteczności Wykonawca uzgodni

z Zamawiającym Specyfikację badania użyteczności Prototypu Interfejsu Graficznego, która powinna:

2. Zawierać materiały, które zostaną poddane badaniu (prototypy),

3. Zawierać proponowany formularz, na którym uczestnicy będą zgłaszać problemy użyteczności,

4. Opisywać zakładaną metodykę dojścia do końcowych wniosków - kryteria oceny użyteczności interfejsu użytkownika.

Opis Wersji Oprogramowania

Do każdej wersji oprogramowania udostępnianej do testów/przeglądów dla użytkowników musi zostać

przygotowany Opis Wersji Oprogramowania zawierający co najmniej:

1. Numer wersji (numeracja wersji musi być uzgodniona i zaakceptowana przez PGW WP przed

rozpoczęciem prac wytwórczych),

2. Czas wydania wersji – data, godzina z minutami,

3. Status wersji:

a. Alfa – prototyp,

b. Beta – wersja testowa,

c. Stabilna – wersja produkcyjna.

4. Wykaz dokumentacji projektowej dotyczącej systemu/oprogramowania,

5. Lista modyfikacji wprowadzonych od poprzedniej wersji.

Dokumentacja testów

Dokumentacja testowa utrzymywana będzie w formie Repozytorium Testów (w dostarczanym Narzędziu wspomagającym proces wytwórczy. Wykonawca będzie zobowiązany do wykonania w tym Narzędziu powiązań pomiędzy wymaganiami, a przypadkami testowymi, tak aby widoczne było pełne pokrycie testami zaplanowanych do realizacji wymagań.

Na potrzeby przeprowadzenia testów akceptacyjnych Systemu WIR powinna zostać opracowana dokumentacja testów uwzględniająca poniższe wymagania.

Plan Testów

Plan Testów musi zawierać co najmniej:

1. Zakres testów,

2. Cele testów,

3. Specyfikację scenariuszy i przypadków testowych, gdzie:

• scenariusz testowy – to opis czynności, których wykonanie jest potrzebne do sprawdzenia poprawności działania określonych funkcjonalności systemu. Scenariusz testowy złożony jest z co najmniej jednego Przypadku testowego.

• przypadek testowy – jest fragmentem Scenariusza testowego opisującym sposób weryfikacji pojedynczego wariantu realizacji procesu biznesowego. Przypadek testowy składa się z co najmniej jednego kroku testowego.

• krok testowy – jest elementem przypadku testowego, opisującym czynności do

wykonania w ramach testowania,

4. Schemat komunikacji w trakcie testów,

5. Harmonogram realizacji testów uwzględniający szacowaną pracochłonność,

6. Dane testowe,

7. Mapowanie pokrycia testami wymagań oraz przypadków użycia,

8. Kryteriach zaliczenia danej fazy testów,

9. Metodę weryfikacji wymagań i przeprowadzenia testów w zakresie wydajności, automatyzacji

procesu testowania (opcjonalnie).

Plan testów powinien obejmować weryfikację wszystkich wymagań funkcjonalnych oraz

pozafunkcjonalnych.

Testy integracyjne, bezpieczeństwa, wydajnościowe oraz automatyczne mogą zostać ujęte w osobnym planie testów lub jako załącznik do planu testów. Sposób opisu takich testów powinien zachować analogiczną strukturę opisu jak dla testów akceptacyjnych.

Weryfikacja wymagań zapisanych w Planie testów nie musi obejmować wymagań spełnianych jednoznacznie w wyniku zastosowania odpowiedniej architektury, technologii lub dopuszczonych przez Zamawiającego rozwiązań organizacyjnych.

Każdy scenariusz testowy powinien być opisany przez następujące atrybuty:

1. identyfikator scenariusza,

2. nazwę scenariusza,

3. spis testowanych w scenariuszu wymagań i przypadków użycia,

4. opis scenariusza - informacje na temat co w ramach scenariusza podlega testowaniu (jaki jest cel testu) oraz informacje o użytkownikach (rolach) uprawnionych do wykonania operacji, rodzaju testu (ręczny/automatyczny) oraz w przypadku testów wydajnościowych planowanego obciążenia tła dla testu i sposobu jego generowania, w tym przebiegi negatywne,

5. wykaz niezbędnych zbiorów danych testowych,

6. lista przypadków testowych podlegającym testom w ramach danego scenariusza testowego wraz z sekwencją ich realizacji,

7. warunki początkowe i dane wejściowe - warunki niezmienne i początkowe dla przypadków użycia właściwych dla scenariusza testowego i ew. dodatkowe warunki. Opisują warunki jakie muszą być spełnione dla przeprowadzenia scenariusza,

8. warunki końcowe i dane wyjściowe - kryteria określające pozytywny rezultat danego

scenariusza testowego.

Opis każdego przypadku testowego powinien zawierać następujące atrybuty:

1. identyfikator przypadku testowego,

2. nazwę przypadku testowego,

3. odwołanie do scenariusza testowego, którego dotyczy przypadek testowy,

4. odwołanie do wymagań i przypadków użycia, których dotyczy przypadek testowy,

5. spis testowanych elementów systemu/oprogramowania,

6. opis przypadku testowego,

7. warunki początkowe,

8. opis wykonywanych operacji – lista kroków, czyli atomowych czynności wykonywanych podczas testów, przedstawiona w uporządkowany sposób. Kroki powinny zostać powiązane z danymi testowymi oraz oczekiwanymi dla danego kroku rezultatami (stanami systemu),

9. warunki końcowe – kryteria określające pozytywny wynik przypadku testowego.

Załącznikiem do Planu testów będzie specyfikacja audytu dostępności zwierająca co najmniej:

1. Listę ekranów/ podstron podlegających audytowi,

2. Wykaz doświadczenia audytora, który odpowiedzialny będzie za przeprowadzenie audytu.

Raport z testów

Po przeprowadzeniu testów systemowych oraz akceptacyjnych Wykonawca odpowiedzialny jest za opracowanie Raportu z testów zawierającego co najmniej:

1. Zestawienie wykonanych testów na podstawie Planu testów ze wskazaniem dni, w których przeprowadzone zostały ostateczne testy.

2. Wykonawca zobowiązany jest do przedstawiania dziennych raportów z testów (generowanych przy wykorzystaniu Narzędzia wspomagającego proces wytwórczy), które stanowić będą załączniki do Raportu z testów. Dzienne raporty z testów powinny zawierać zestawienie z przypadków i scenariuszy testowych wraz z wynikiem testów dla poszczególnych przypadków i scenariuszy testowych oraz wykazem zgłoszonych uwag.

3. Opis ewentualnych dodatkowych testów, które były przeprowadzone w trakcie testów wewnętrznych.

4. Podsumowanie w formie statystyk wykonanych testów, zawierające co najmniej liczbę przetestowanych przypadków testowych, liczbę przypadków zakończonych bez błędów, liczbę przypadków zakończonych z błędami (krytyczne, poważne, drobne).

5. Plan działań następczych związany z wynikami testów.

Raport z testów akceptacyjnych powinien obejmować wyniki wszystkich rodzajów testów: testy integracyjne, wydajnościowe, UAT, bezpieczeństwa (Wykonawcy), bezpieczeństwa (realizowane przez podmiot zewnętrzny).

Załącznikiem do Raportu z testów będzie raport z przeprowadzonego audytu dostępności zawierający tabelę odpowiadającą swoją strukturą Załącznikowi do Ustawy z dnia 4 kwietnia 2019 o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. 2019 poz 848), w której wskaże kryteria sukcesu, które są spełnione, które nie są spełnione, a które nie dotyczą badanego serwisu.

Dokumentacja wdrożenia

Dokumentacja wdrożenia powinna zostać opracowana oddzielnie w zakresie wdrożenia Systemu na środowisku testowym i produkcyjnym.

Plan Instalacji Oprogramowania

Plan Instalacji Oprogramowania zawiera co najmniej:

1. Przedmiot wdrożenia:

x. xxxxx wdrażanego oprogramowania;

b. wykaz maszyn, na których będzie wdrażane oprogramowanie;

2. Zasoby niezbędne do przeprowadzenia wdrożenia (zasoby ludzkie i infrastrukturalne);

3. Plan Instalacji Oprogramowania:

a. Zakres odpowiedzialności poszczególnych zasobów ludzkich niezbędnych do przeprowadzenia wdrożenia po stronie Wykonawcy i Zamawiającego;

b. Harmonogram wdrożenia zawierający informacje o terminach i czynnościach wdrożeniowych;

c. Procedury wdrożenia czyli opis działań, jakie muszą zostać zrealizowane celem wdrożenia;

d. Informacje o infrastrukturze, która musi zostać przygotowana na potrzeby wdrożenia;

4. Plan migracji danych, zawierający:

a. Zakres danych, jakie będą podlegały migracji – opis danych, wolumen danych;

b. Wykaz magazynów danych, których dotyczyć będzie migracja;

c. Metoda przeprowadzenia migracji;

d. Scenariusze testowe w zakresie testów migracji danych.

5. Wariant awaryjny.

Raport z wdrożenia Systemu WIR

Po przeprowadzeniu wdrożenia sporządzony zostaje Raport z wdrożenia zawierający co najmniej:

1. Zakres wdrożenia;

2. Opis przeprowadzonego wdrożenia;

3. Wynik przeprowadzonego wdrożenia;

4. Wynik przeprowadzonej migracji danych;

5. Wykaz napotkanych problemów;

6. Działania następcze wynikające z przeprowadzonego wdrożenia.

W zakresie migracji danych Raport z wdrożenia musi zawierać co najmniej:

1. Informacje na temat zrealizowanych prac związanych z zasileniem systemu danymi (w tym

o napotkanych błędach);

2. Opis źródeł danych inicjalnych, ich wolumen, metody ich zasilenia;

3. Opis konfiguracji środowiska.

Dokumentacja Użytkownika

Wykonawca opracuje Dokumentację Użytkownika w języku polskim, w formie elektronicznej. Wykonawca dostarczy dokumentację użytkownika w formie elektronicznego interaktywnego podręcznika użytkownika. Podręcznik użytkownika musi zawierać opis wszystkich funkcji

oprogramowania dostępnych dla użytkownika, opis sytuacji szczególnych i awaryjnych, opis

elementów znajdujących się na poszczególnych ekranach, opis błędów generowanych przez System. Interaktywny Podręcznik dla Użytkownika musi:

a. być napisany prostym językiem,

b. zostać zamieszczony w Systemie WIR w sposób umożliwiający nawigację po niej,

c. umożliwiać pełnotekstowe wyszukiwanie zagadnień,

d. zostać opublikowany na platformie e-learningowej do użytku kursantów. Na Dokumentację Użytkownika składać się będą:

1. Dokumentacja Użytkownika wewnętrznego,

2. Dokumentacja Użytkownika zewnętrznego.

Z interaktywnego Podręcznika dla użytkownika będzie można skorzystać poprzez stronę www lub pobranie na dysk lokalny użytkownika.

Dokumentacja użytkownika musi obejmować swoim zakresem wszystkie moduły Systemu WIR, w tym

także aplikację mobilną.

Dokumentacja Użytkownika wewnętrznego

Dokumentacja Użytkownika wewnętrznego przeznaczona jest dla użytkownika wewnętrznego (pracowników PGW WP). Dokumentacja Użytkownika wewnętrznego musi opisywać sposób działania wszystkich funkcjonalności systemu przeznaczonych do wykorzystania przez użytkowników wewnętrznych.

Dokumentacja Użytkownika musi zawierać co najmniej następujące elementy:

1. Opis systemu;

2. Minimalne wymagania sprzętowe i systemowe;

3. Opis funkcji systemu przeznaczonych dla użytkowników wewnętrznych oraz opis korzystania z nich;

4. Informacje dotyczące obsługi sytuacji nietypowych.

Wszystkie elementy systemu opisane w Dokumentacji Użytkownika muszą zostać przedstawione na zrzutach ekranowych obrazujących ich umiejscowienie w interfejsach użytkownika oraz sposób ich działania.

Dokumentacja Użytkownika zewnętrznego

Dokumentacja Użytkownika zewnętrznego przeznaczona jest dla użytkownika końcowego korzystającego z systemu. Dokumentacja Użytkownika zewnętrznego musi opisywać sposób działania systemu z perspektywy użytkownika końcowego i musi być napisana językiem zrozumiałym dla osób nieznających systemu.

Dokumentacja Użytkownika zewnętrznego musi zawierać co najmniej następujące elementy:

1. Opis systemu;

2. Minimalne wymagania sprzętowe i systemowe;

3. Opis funkcji systemu przeznaczonych do wykorzystania przez użytkownika zewnętrznego oraz

opis korzystania z nich;

4. Informacje dotyczące obsługi sytuacji nietypowych.

Dokumentacja Administratora

Dokumentacja Administratora przeznaczona jest dla administratorów systemów. Dokumentacja Administratora musi opisywać informacje pozwalające na przeprowadzenie procesu instalacji oraz konfiguracji każdego oprogramowania/systemu dostarczonego w ramach realizacji rozwiązania.

Dokumentacja Administratora musi zawierać co najmniej następujące elementy:

1. Opis sposobu instalacji, konfiguracji i parametryzacji sprzętu i oprogramowania,

2. Szczegółową instrukcję włączenia i wyłączenia Systemu i wszelkich jego komponentów wraz

z ich odpowiednią sekwencją,

3. Opis parametrów konfiguracyjnych sprzętu i oprogramowania,

4. Instrukcję przygotowywania i odtwarzania kopii bezpieczeństwa,

5. Instrukcję postępowania w przypadkach szczególnych wraz z odtwarzaniem Systemu,

6. Procedury sprawdzania prawidłowego działania wszystkich komponentów,

7. Schematy logiczne Systemu, topologii sieci,

8. Instrukcję opisującą proces logowania błędów przez System, przykładowe scenariusze reakcji na zaistniałe problemy, opis i umiejscowienie logów Systemu,

9. Dokumentację okresowej kontroli Systemu (kontrola komponentów, logów, wolnego miejsca,

obciążenia itp.).

Dokumentacja szkoleniowa

Plan szkoleń

Przed rozpoczęciem szkoleń, Wykonawca w porozumieniu z Zamawiającym, przygotuje i potwierdzi

plan szkoleń obejmujący:

1. szczegółowy zakres szkoleń;

2. proponowaną lokalizację szkoleń (dokładny adres/ nazwa miejsca szkolenia);

3. harmonogram szkoleń.

Zakres, lokalizacje i harmonogram szkoleń musi zostać uzgodniony z Zamawiającym na co najmniej dwa tygodnie przed rozpoczęciem szkoleń.

Załącznikiem do Planu szkoleń będzie konspekt materiałów e-learningowych zawierający co najmniej:

1. szczegółowe scenariusze szkoleń/kursów e-learningowych,

2. szczegółowe scenariusze filmów instruktażowych,

3. koncepcję rozmieszczenia materiałów na platformie e-learningowej, uwzględniająca kolejność kursów.

Materiały szkoleniowe

W zakresie dokumentacji szkoleniowej Wykonawca zobowiązany jest do opracowania:

1. Podręcznika szkoleniowego na potrzeby przeprowadzanych przez Wykonawcę szkoleń dla użytkowników i administratorów Systemu WIR,

2. Kursów e-learningowych;

3. Filmów instruktażowych;

4. Ankiety oceniającej zadowolenie użytkowników

Szczegółowe wymagania dla wyżej wymienionych Produktów zostały określone w rozdziale 14.

Raport ze szkoleń

Wykonawca zobowiązany jest w ciągu 5 dni roboczych od zakończenia szkoleń przygotować Raport z przeprowadzonych szkoleń zawierający w szczególności: termin i miejsce przeprowadzenia szkoleń, szczegółowy zakres szkoleń, listy obecności uczestników szkoleń oraz wyników ankiety oceniającej zadowolenie użytkowników.

Plan dostawy infrastruktury

Plan dostawy infrastruktury zawiera co najmniej:

1. wykaz dostarczanej Infrastruktury teleinformatycznej oraz Urządzeń mobilnych (wraz z wykazem licencji),

2. procedury instalacji i konfiguracji Infrastruktury teleinformatycznej,

3. zakres odpowiedzialności Xxxxx w trakcie prac wdrożeniowych,

4. wykaz personelu skierowanego do realizacji zadania,

5. szczegółowego plan realizacji poszczególnych czynności związanych z dostawą, instalacją i konfiguracją Infrastruktury teleinformatycznej (w uwzględnieniem planowanych terminów dostawy).

Załącznikiem do Planu dostawy infrastruktury powinien być wykaz dostarczanej Infrastruktury teleinformatycznej oraz Urządzeń mobilnych, zawierający informacje dotyczące: producenta, modelu,

part numberu, ilości dostarczanych urządzeń dla danego modelu, a także ceny netto, wartości podatku vat i ceny brutto dla kazdego dostarczanego urządzenia/licencji.

Dokumentacja Powykonawcza

W okresie realizacji wszystkich etapów realizacji prac nad systemem Wykonawca zobowiązany jest do aktualizacji zapisów Dokumentacji Analitycznej, Dokumentacji Technicznej i Planu Testów dla budowanego rozwiązania. Po zakończeniu prac nad wdrożeniem Systemu Wykonawca zobligowany jest do dostarczenia dokumentacji powykonawczej, będącej kompletną dokumentacją dostarczanego sprzętu i oprogramowania powstałego w ramach realizacji zamówienia.

Dokumentacja Powykonawcza opisuje wszystkie elementy wdrożonego systemu. w skład Dokumentacji Powykonawczej wchodzą:

1. Zaktualizowana Dokumentacja Analityczna (DA);

2. Zaktualizowana Dokumentacja Techniczna (DT);

3. Zaktualizowana Dokumentacja Użytkownika (DU);

4. Zaktualizowana Dokumentacja Administratora;

5. Zaktualizowany Skomentowany Kod Źródłowy (SKZ);

6. Dokumentacja utrzymaniowa, uwzględniająca co najmniej:

a. Sposób monitorowania systemu;

b. Awarie systemu i sposób ich obsługi, w tym bezpieczne wyłącznie sytemu,

c. bezpieczne włączenie sytemu wraz z kolejnością uruchamiania.

7. Dokumentacja bazy danych, uwzględniająca co najmniej:

a. Model fizyczny bazy danych;

b. Struktura baz danych;

c. Opis tabel i kolumn bazy danych;

d. Relacje zaimplementowane w bazie danych;

e. Opisy zastosowanych wyzwalaczy;

f. Opis procedur, w tym także procedury archiwizacji i odtwarzania danych;

g. Opis operacji wykonywanych cyklicznie;

h. Administrowanie kopiami zapasowymi bazy danych, w tym tworzenie kopii zapasowych bazy danych i przywracanie bazy danych z kopii zapasowej.

8. Dokumentację dostarczonego sprzętu i oprogramowania:

a. Zestawienie dostarczonego sprzętu i oprogramowania wraz z wykazem licencji,

b. Schemat logiczny urządzeń oraz połączeń po między nimi,

c. Opis architektury technologicznej, w tym:

i. Opis fizycznej oraz logicznej infrastruktury sprzętowej serwerów,

macierzy, itd,

ii. Opis logicznej infrastruktury wirtualizacyjnej,

iii. Opis logicznej infrastruktury kopii zapasowych,

iv. Opis logiczny infrastruktury sieciowej,

v. Opis logiczny bezpieczeństwa sieciowego,

vi. Opis dostarczonego oprogramowania,

vii. Procedury przełączania się ośrodków.

9. Licencje oraz sublicencje na oprogramowanie standardowe niezbędne do poprawnego, zgodnego z prawem funkcjonowania systemu (w ilości niezbędnej do spełnienia wymagań), w szczególności na:

a. Systemy operacyjne;

b. Silniki baz danych oraz biblioteki.

10. Dokumentacja instalacji, uwzględniająca co najmniej:

a. Schemat logiczny systemu;

b. Konfigurację systemu;

c. Procedury instalacji i konfiguracji całego Systemu, w tym także opis instalacji baz

danych Systemu, opis konfiguracji stacji roboczych;

d. opisu wymaganych pakietów instalacyjnych i ich wersji;

e. Procedury odinstalowania systemu;

11. Procedury administracyjne związane z bieżącą eksploatacją systemu oraz z przywracaniem systemu po awariach;

12. Dokumentacja opisująca zasady współpracy Stron w ramach świadczenia usług gwarancyjnych zawierającą x.xx.:

a. Zakres, parametry pracy oraz wykaz ekspertów przewidzianych do pracy w okresie

świadczenia usług gwarancyjnych;

b. Procedury obsługi wad i awarii (uwzględniające sposoby ich zgłaszania, usuwania oraz dokumentowania) Procedury te muszą omawiać przynajmniej następujące zagadnienia:

i. Sposób zgłaszania wad i awarii (kontakty telefoniczne i mailowe do Wykonawcy/Gwaranta, na które należy kierować zgłoszenia), wzory dokumentów zgłoszeń zawierające niezbędne z punktu widzenia Wykonawcy/Gwaranta informacje do zlokalizowania oraz usunięcia wad i awarii;

ii. Dodatkowo Wykonawca/Gwarant uzgodni z Zamawiającym system pomiarowy pozwalający kontrolować czasy, jakie upływają na skontaktowanie się z osobą upoważnioną do przyjęcia zgłoszenia (w szczególności zgłoszenie może zostać przesłane drogą mailową), czas reakcji na zgłoszenie oraz czas usunięcia wad i awarii;

iii. Sposób, w jaki wykonywane będą naprawy, (co musi zawierać wgrywana

poprawka, kod, pliki wykonywalne, dokumentacja itp.);

iv. Sposób sporządzania raportów o zgłoszonych wadach i awariach oraz

o sposobach ich rozwiązania.

DOSTAWA INFRASTRUKTURY TELEINFORMATYCZNEJ ORAZ URZĄDZEŃ MOBILNYCH

Wykonawca zobowiązany jest do dostawy Infrastruktury teleinformatycznej zgodnie z wymaganiami

określonymi w poniższych podrozdziałach.

Lokalizacje dla dostawy Infrastruktury teleinformatycznej oraz Urządzeń mobilnych

Poniżej przedstawiono zestawienie lokalizacji, do których dostarczona zostanie Infrastruktura teleinformatyczna będąca przedmiotem niniejszego Zamówienia.

Tabela 3 Zestawienie lokalizacji

ID	Elementy dostarczanej infrastruktury	Lokalizacja
1.	Centrach Przetwarzania Danych (CPD)	Warszawa
2.	Centrach Przetwarzania Danych (CPD)	Piaseczno
3.	Urządzenia mobilne (Tablety)	Dostawa do poszczególnych jednostek RZGW

Dostawa Infrastruktury teleinformatycznej

Opis elementów Infrastruktury teleinformatycznej wymaganej do dostarczenia w ramach niniejszego Zamówienia przedstawiony jest w Załączniku nr 2. Przedstawiony w Załączniku nr 2 opis stanowi minimalne wymagania dla dostawy Infrastruktury teleinformatycznej, w przypadku, gdy Wykonawca uzna, iż powyżej opisane zasoby są niewystarczające do realizacji Przedmiotu Umowy, Wykonawca dostarczy niezbędne elementy dodatkowe, kompatybilne z infrastrukturą Zamawiającego, w ramach Wynagrodzenia za podstawowy przedmiot Umowy.

Dostarczone w ramach postępowania poszczególne elementy Infrastruktury teleinformatycznej muszą spełniać poniższe wymagania:

1. Dostarczony przez Wykonawcę sprzęt musi być fabrycznie nowy, wyprodukowany nie wcześniej niż pół roku przed datą podpisania umowy, pochodzić z autoryzowanego kanału sprzedaży producenta i reprezentować model bieżącej linii produkcyjnej. Nie dopuszcza się urządzeń: odnawianych, demonstracyjnych lub powystawowych.

2. Wszystkie urządzenia, na dzień składania oferty przez Wykonawcę, nie mogą być przeznaczone przez producenta tego sprzętu do wycofania z produkcji lub sprzedaży w okresie minimum 6 miesięcy od dnia składania ofert.

3. Całość dostarczanego sprzętu musi pochodzić z autoryzowanego kanału sprzedaży producentów zaoferowanego sprzętu.

4. Wszystkie oferowane urządzenia muszą być wyprodukowane zgodnie z normą jakości ISO 9001 lub równoważną tj. równoważne inne zaświadczenie niezależnego podmiotu zajmującego się poświadczaniem zgodności działań producentów z normami jakościowymi.

5. Urządzenia i ich komponenty muszą być oznakowane przez producenta w taki sposób, aby możliwa była identyfikacja zarówno produktu jak i producenta.

6. Urządzenia muszą być dostarczone do lokalizacji wskazanych w niniejszym OPZ w oryginalnych opakowaniach fabrycznych, bez śladów ich otwierania.

7. Oferowane urządzenia muszą pochodzić z oficjalnego kanału dystrybucji producenta na terenie Unii Europejskiej z wyłączeniem Urządzeń mobilnych, a gwarancja nie krótsza niż 36 miesięcy musi pochodzić od producenta i być świadczona przez producenta na terenie Polski lub partnera z autoryzacją serwisową. w przypadku kiedy producent urządzenia oferuje gwarancję dłuższą niż 36 miesięcy musi ona być świadczona przez wskazany przez niego czas.

8. Dostarczony przez Wykonawcę sprzęt musi być wzajemnie kompatybilny dla każdej

z lokalizacji.

9. Dla wszystkich dostarczanych urządzeń Wykonawca dostarczy odpowiednią ilość, o odpowiednich parametrach: kabli zasilających, kabli Ethernet, kabli DAC, kabli AOC, kabli optycznych oraz innych akcesoriów, niezbędnych do przeprowadzenia prawidłowej instalacji urządzeń.

10. Wkładki, kable DAC, kable AOC, kable Splitter muszą być na liście kompatybilności oferowanych urządzeń.

11. Dla wyspecyfikowanej Infrastruktury teleinformatycznej, Wykonawca zobowiązany jest do udzielenia niewyłącznej licencji (na oprogramowanie) Zamawiającemu lub przeniesienia na Zamawiającego niewyłącznych uprawnień licencyjnych na czas nieoznaczony, tj. nieograniczony w czasie na korzystanie z dostarczonego oprogramowania.

12. Wszystkie urządzenia muszą współpracować z siecią energetyczną o parametrach: 230 V ± 10%

, 50 Hz., jednofazowo i być wyposażone w przewody zasilające.

13. Wszystkie oferowane urządzenia muszą działać pod kontrolą oprogramowania, które jest publiczną wersją, udostępnianą na rynku przez producenta oferowanych urządzeń. Zamawiający nie dopuszcza stosowania oprogramowania dedykowanego, stworzonego na potrzeby niniejszego zamówienia, dla zaoferowanych urządzeń.

14. Wszystkie oferowane urządzenia muszą być publicznie dostępne. Zamawiający nie dopuszcza stosowania urządzeń dedykowanych, stworzonych na potrzeby niniejszego zamówienia.

15. Infrastruktura sprzętowa stanowiąca przedmiot Zamówienia musi być fabrycznie nowa (t.j. nieregenerowana, nienaprawiana, niefabrykowana, nieużywana we wcześniejszych wdrożeniach), kompletna (w szczególności ze wszystkimi podzespołami, częściami, materiałami niezbędnymi do uruchomienia i użytkowania).

W zakresie dostawy infrastruktury sprzętowej Wykonawca zobowiązany jest do:

a. fizycznej dostawy całości wymaganej Umową infrastruktury sprzętowej wraz z niezbędnym wyposażeniem dodatkowym na koszt Wykonawcy do poszczególnych lokalizacji wskazanych w rozdziale 12.1 Lokalizacje dla dostawy Infrastruktury;

b. dostarczenia instrukcji obsługi i/lub instalacji w formie drukowanej lub na nośniku elektronicznym (trwały zapis na płycie CD/DVD).

W zakresie dostawy oprogramowania Wykonawca zobowiązany jest do dostarczenia kompletu oprogramowania w tym: sterowników, oprogramowania systemowego, oprogramowania dodatkowego, niezbędnego do instalacji, konfiguracji oraz zarządzania dostarczoną Platformą na nośniku elektronicznym (trwały zapis na płycie CD/DVD).

Dostawa sprzętu, montaż i konfiguracja powinny zostać zrealizowane w dni robocze od poniedziałku do piątku w godzinach 9-14. Ze względu na konieczność umówienia wizyty w CPD wizyta musi być umówiona min. 2 dni wcześniej.

Instalacja i konfiguracja dostarczonej Infrastruktury teleinformatycznej

Dla dostarczanej w ramach niniejszego Przedmiotu Zamówienia infrastruktury teleinformatycznej, wyspecyfikowanej w Załączniku nr 2 do niniejszego OPZ, Wykonawca zobowiązany jest x.xx. do:

1. Przygotowania Planu dostawy infrastruktury i uzyskania jego akceptacji przez Zamawiającego

– dokument musi zawierać szczegółowe informacje nt. wykazu dostarczanej infrastruktury oraz oprogramowania (wraz z wykazem licencji), procedur instalacji i konfiguracji infrastruktury i oprogramowania, odpowiedzialności Stron w trakcie prac wdrożeniowych, wykazu personelu skierowanego do realizacji zadania oraz szczegółowego harmonogramu realizacji poszczególnych czynności (z uwzględnieniem planowanych terminów dostawy).

2. Wykonawca przygotuje i przedstawi do akceptacji Zamawiającego Plan dostawy infrastruktury najpóźniej w terminie określonym Tabelą nr 1. Dokument podlegał będzie procedurze odbioru dokumentacji.

3. Wykonawca dopełni wszystkich starań, aby zapewnić realizację usługi instalacji i konfiguracji w jak najkrótszym czasie. Każda planowana niedostępność elementów infrastruktury i usług musi być przedstawiona w Planie dostawy infrastruktury i musi uzyskać akceptację Zamawiającego.

4. Instalacji i konfiguracji infrastruktury zgodnie z zaakceptowanym przez Zamawiającego Planem dostawy infrastruktury. Sprzęt musi zostać zainstalowany we wskazanym przez Zamawiającego miejscu w serwerowni – wskazanym w Planie, w uzgodnionej lokalizacji, tak aby zapewnić ciągłość działania poszczególnych warstw infrastruktury w czasie trwania instalacji.

5. Zakres instalacji i konfiguracji przeprowadzonej przez Wykonawcę musi obejmować

co najmniej:

a. Rozpakowanie i rozmieszczenie sprzętu we wskazanych przez Zamawiającego lokalizacjach, sprawdzenie czy nie wystąpiły uszkodzenia;

b. Montaż sprzętu we wskazanych miejscach; podpięcie wszystkich kabli połączeniowych;

c. Sprawdzenie stanu zabezpieczeń zasilaczy i podłączenie sprzętu do sieci

energetycznej;

d. Uruchomienie sprzętu;

e. Przygotowanie płyt CD/DVD lub innego nośnika do instalacji oprogramowania,

f. Instalację dostarczonego oprogramowania na dostarczonym sprzęcie, wraz z niezbędnymi uaktualnieniami na wskazanych przez Zamawiającego urządzeniach,

g. Konfigurację sprzętu i oprogramowania, w tym:

i. konfiguracja i uruchomienie urządzeń,

ii. konfiguracja sterowników, systemu operacyjnego i oprogramowania dodatkowego,

iii. konfiguracja interfejsów sieciowych,

iv. konfiguracja podsystemu zarządzania,

v. konfiguracja podsystemu dyskowego,

vi. konfiguracja podsystemu tworzenia kopii zapasowych,

h. Przeszkolenie z obsługi sprzętu wskazanych przez Zamawiającego pracowników,

i. Włączenie sprzętu do istniejącej infrastruktury teleinformatycznej Zamawiającego, w tym podłączenie do sieci; po przeprowadzeniu prac instalacyjnych i konfiguracyjnych sprzęt musi działać jako integralna część infrastruktury teleinformatycznej Zamawiającego;

j. Wykonanie testów połączeń i wydajności urządzeń; pozytywny wynik testów będzie podstawą podpisania protokołu odbioru;

k. Zebranie opakowań i dokumentacji i przekazanie ich Zamawiającemu.

6. W przypadku wymagań producenta sprzętu odnośnie posiadania uprawnień lub certyfikatów przez osoby dokonujące instalacji i konfiguracji (np. w celu zachowania gwarancji producenta), Wykonawca jest zobowiązany przedstawić potwierdzenia posiadania ich przez osoby wyznaczone do tego zadania.

7. W przypadku konieczności wykorzystania dodatkowych licencji lub oprogramowania Wykonawca zobowiązany jest do zapewnienia ich na czas trwania Umowy.

8. Sporządzenia kompletu dokumentacji powykonawczych dla poszczególnych elementów

infrastruktury i oprogramowania.

Oznaczenie sprzętu

Wszystkie urządzenia dostarczane w ramach niniejszego Zamówienia muszą zostać oznaczone przez Wykonawcę w sposób wskazujący, że Projekt jest współfinansowany przez Unię Europejską ze środków

Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Polska Cyfrowa, realizowany na podstawie Umowy o dofinansowanie nr POPC.02.01.00-00-0124/19 z dnia 16 października 2020 r.

Wykonawca pozyska od Zamawiającego naklejki promocyjne dostarczone w ramach Zamówienia na przeprowadzenie działań promocyjnych i informacyjnych w Projekcie „Wirtualny Informator Rzeczny (WIR)”.

WYMAGANIA W ZAKRESIE TESTÓW

Niniejszy rozdział określa wymagania w zakresie testów dostarczonego w ramach Przedmiotu

Zamówienia oprogramowania.

Wymagania w zakresie testów

Weryfikacja wytworzonego przez Wykonawcę docelowego oprogramowania Systemu WIR odbywać się będzie podczas testów. Testom podlega całość dostarczanego oprogramowania zarówno w zakresie Oprogramowania dedykowanego jak i Oprogramowania standardowego.

Proces weryfikacji Systemu obejmować będzie następujące rodzaje testów:

1. Weryfikacja i testy platformy sprzętowo-programowej,

2. Testy systemowe (dalej zwane testami SYS lub testami wewnętrznymi) - Wykonawca będzie zobowiązany do wykonania Testów Systemowych wewnętrznie, na etapie konstrukcji Systemu, przed przekazaniem Systemu do weryfikacji Zamawiającego,

3. Testy akceptacyjne, na które składać się będą:

a. Testy Integracyjne (dalej zwane testami INT) - zostanie poddana testom integracja Systemu z systemami zewnętrznymi, jak również integracja pomiędzy różnymi pod względem technologicznym modułami Systemu,

b. Testy Wydajnościowe - sprawdzenie wydajności Systemu w różnych warunkach symulujących rzeczywiste zdarzenia,

c. Testy Akceptacyjne Użytkownika (dalej zwane testami UAT), w tym testy swobodne o ile Zamawiający uzna je za konieczne - jest to ostateczna faza Odbioru Systemu weryfikująca poprawność implementacji wymagań dla Systemu,

d. Testy Bezpieczeństwa (Wykonawcy) – testy bezpieczeństwa zrealizowane przez Wykonawcę Systemu.

4. Testy bezpieczeństwa zrealizowane przez podmiot zewnętrzny zgodnie z zapisami rozdziału

13.2.

5. Audyt dostępności cyfrowej zrealizowany zgodnie z zapisami rozdziału 13.3.

Wykonawca zobowiązany jest do zapewnienia urządzeń niezbędnych do przeprowadzenia testów Systemu, w tym Urządzeń mobilnych niezbędnych do przeprowadzenia testów aplikacji mobilnej. Urządzenia wykorzystane do przeprowadzenia testów muszą umożliwiać weryfikację wszystkich wymagań, w tym weryfikację działania aplikacji mobilnej dla różnych systemów operacyjnych, zgodnie z wymaganiami określonymi w Załączniku nr 1 do OPZ Rejestr Wymagań. Zamawiający musi mieć możliwość wykorzystania ww. urządzeń do przeprowadzenia testów swobodnych Systemu.

Testy realizowane będą z wykorzystaniem Narzędzia wspomagającego proces wytwórczy. Wykonawca musi zaplanować harmonogram testów w taki sposób, aby umożliwiał on przeprowadzenie wszystkich zaplanowanych testów.

Testy platformy sprzętowo - programowej

W ramach weryfikacji i testów Platformy sprzętowo-programowej Wykonawca musi przeprowadzić testy weryfikacyjne, których celem ma być sprawdzenie poprawności działania sprzętu i oprogramowania systemowego i formalne potwierdzenie zgodności z wymaganiami OPZ. W ramach weryfikacji i testów platformy należy przeprowadzić:

1. weryfikację kompletności i zgodności dostaw z wymaganiami,

2. weryfikację rozmieszczenia i poprawności montażu sprzętu,

3. inwentaryzację i weryfikację numerów seryjnych urządzeń,

4. uruchomienie i weryfikację poprawności działania sprzętu i zainstalowanego oprogramowania (w tym weryfikację logów systemowych),

5. weryfikację poprawności konfiguracji urządzeń zgodnie z wymaganiami i wytycznymi Zamawiającego (w zakresie interfejsów sieciowych, podsystemu zarządzania, podsystemu dyskowego, oraz podsystemu tworzenia kopii zapasowych),

6. testy wydajności interfejsów sieciowych, podsystemu dyskowego oraz podsystemu tworzenia kopii zapasowych pod kątem ich planowanego wykorzystania.

Końcowym wynikiem będzie opracowanie raportu z weryfikacji i testów platformy sprzętowo- programowej, w tym opis rozmieszczenia sprzętu i konfiguracji oprogramowania systemowego.

Testy systemowe (SYS/ Testy wewnętrzne)

Testy SYS zostaną przeprowadzone przez Wykonawcę w środowisku preprodukcyjnym. Zamawiający nie będzie brał udziału w Testach systemowych. Wykonawca będzie zobowiązany do wykonania Testów Systemowych wewnętrznie, na etapie konstrukcji Systemu, przed przekazaniem Systemu do weryfikacji Zamawiającego.

Testami systemowymi zostaną objęte wszystkie funkcjonalności Systemu WIR. Testy SYS zostaną

przeprowadzone zgodnie ze scenariuszami testowymi opracowanymi w ramach Planu Testów.

Na podstawie przeprowadzonych Testów Systemowych Wykonawca sporządzi Raport z testów wewnętrznych. Dopuszczalne limity błędów dla testów wewnętrznych zostały przedstawione w rozdziale 13.1.1 Klasyfikacja oraz limity Błędów. Pozytywny wynik testów wewnętrznych stanowi podstawę do rozpoczęcia testów akceptacyjnych.

Testy Integracyjne (INT)

Testy INT zostaną przeprowadzane w środowisku preprodukcyjnym przez Wykonawcę w obecności przedstawicieli Zamawiającego.

Podczas testów INT nie będzie dozwolone używanie zaślepek lub symulatorów innych systemów. Wszystkie scenariusze wykonywane będą na pracujących systemach.

Szczegółowe plany zakresu merytorycznego testów powstaną na etapie opracowania Planu Testów.

W ramach realizacji testów Wykonawca jest również zobowiązany do weryfikacji poprawności przełączania się pomiędzy ośrodkami CPD usług i infrastruktury, pod kątem ich planowanego wykorzystania.

Testy Wydajnościowe

Testy wydajnościowe zostaną przeprowadzane w środowisku preprodukcyjnym przez Wykonawcę

w obecności przedstawicieli Zamawiającego.

Testy wydajnościowe są zestawem operacji mającym na celu weryfikację wymagań Systemu.

Wydajność Systemu zawarta w wymaganiach musi być potwierdzona poprzez wykonanie różnych rodzajów testów wydajnościowych. Rodzaje testów wydajnościowych jakie powinny zostać przeprowadzone w celu wykonania ww. testów:

1. testy wydajnościowe:

a. badanie czasu odpowiedzi krytycznych funkcji Systemu,

b. porównywanie czasu odpowiedzi przejścia pojedynczego lub wielu użytkowników przez aplikację,

c. kryterium testów jest sprawdzenie czy poszczególne akcje wykonywane są przez aplikację w czasach określonych w wymaganiach wydajnościowych dla Systemu WIR w Załączniku nr 1 do OPZ Rejestr wymagań,

2. testy przeciążeniowe:

a. założenie: zbyt wielu użytkowników, danych, czasu oraz malejące zasoby

systemowe,

b. badanie czy System “zawiedzie” w oczekiwany sposób,

c. wyszukiwanie defektów w aplikacji działającej w trybie awaryjnym,

d. sprawdzanie konsekwencji utraty danych po awarii wywołanej nadmiernym obciążeniem,

3. testy obciążeniowe:

a. duża liczba jednocześnie działających użytkowników / przeprowadzanych

transakcji,

b. utrzymanie takiego stanu przez określony w scenariuszu czas,

c. jak wiele zapytań (requests) jest w stanie obsłużyć System w określonym

przedziale czasu.

4. testy stabilności Systemu:

a. przeprowadzanie testów wydajnościowych przez określony czas w celu określenia stabilnego działania funkcjonalności poprzez powtarzalność wyników,

b. weryfikacja czasu wykonywanej kilkukrotnie przez kilku użytkowników akcji mająca na celu sprawdzenie czy czas nie ulega znacząco zmianie przy kolejnych próbach,

c. wykrycie występujących błędów przy kolejnym wykonywaniu testu,

d. analiza zebranych logów Systemu, które wskażą te funkcjonalności i moduły Systemu, które działają niestabilnie.

Szczegółowe plany zakresu merytorycznego testów mają powstać na etapie opracowania Planu Testów.

Na potrzeby oceny właściwego działania Systemu w wersji produkcyjnej przyjmuje się następujące założenia:

Lp.	Opis parametrów	Poziom jakości usług (maksymalny dopuszczalny czas)
1.	Maksymalny czas odpowiedzi na akcję użytkownika	< 1 sekunda
2.	Maksymalny czas wykonania pojedynczej akcji Systemu	< 5 sekund
3.	Maksymalny czas wykonania złożonej akcji Systemu	< 30 sekund
4.	Maksymalny czas dla wygenerowania raportu (do 5 str.)	< 30 sekund
5.	Maksymalny czas dla wygenerowania raportu (do 50 str.)	<2 minut

Przedmiotowe parametry powinny zostać spełnione również w okresie eksploatacji systemu tj. po

podpisaniu Protokołu Odbioru Wdrożenia produkcyjnego Systemu WIR.

Maksymalny czas odpowiedzi Systemu na akcję użytkownika dotyczy: wyświetlenia oraz odświeżenia ekranu Systemu, wyświetlenia oraz odświeżenia ekranu zawierającego formularz, odzwierciedlenia w formularzu ekranowym zmian dokonanych przez użytkownika (np. wyświetlenia znaków wpisywanych w formularzu), dokonania opłaty elektronicznej (wywołania operatora szybkich płatności), wysyłania deklaracji, dokonania zgłoszenia, wyświetlenia informacji o rozpoczęciu wykonywania akcji Systemu, o których mowa poniżej.

Maksymalny czas wykonania pojedynczej akcji Systemu dotyczy: zapisania danych z formularza w Systemie (po stronie serwera), wyszukania danych, w tym wyszukania trasy, dodania nowego obiektu, dodania nowego parametru.

Maksymalny czas wykonania złożonej akcji Systemu dotyczy: wykonania analizy danych, wykonania przetwarzania (modyfikacji) danych.

Maksymalny czas dla wygenerowania raportu dotyczy przygotowania i wyświetlenia raportu.

Czasy, o których mowa powyżej, są mierzone od momentu zatwierdzenia akcji przez użytkownika do

czasu odpowiedzi przez System umożliwiającej prezentację ekranu odpowiadającego na tą akcję.

Wyżej opisane parametry jakościowe są wymagane dla jednoczesnej pracy co najmniej 500 użytkowników przy czym charakterystyka wykorzystania Systemu to 60% użytkowników dokonuje operacji w Systemie związanych z odczytem danych a 40% wykonuje operacje w Systemie związane z zapisem danych.

Testy automatyczne

W celu zapewnienia odpowiedniego poziomu jakości tworzonego kodu, Wykonawca zobowiązany będzie to zaplanowania i wdrożenia odpowiednich mechanizmów testów automatycznych weryfikujących prawidłowość zastosowania co najmniej następujących technik programowania:

a. prawidłowość zastosowania wzorców projektowych (GOF)

b. prawidłowość definiowania oraz wykorzystania wzorców integracyjnych (EAI)

c. prawidłowość zastosowanych wzorców obiektowości.

Wykonawca Systemu będzie zobowiązany do wdrożenia podczas procesu programowania praktyk ciągłej integracji (ang. Continuous Integration). Tworzony kod oprogramowania musi być objęty systemem kontroli wersji poprzez umieszczenie go w zapewniającym to repozytorium np. git oraz musi przechodzić automatyczne testy zgodności składni wykorzystanego języka. Kod, dla którego pozytywnie zakończą się testy zgodności reguł trafi do serwera ciągłej integracji, gdzie zostaną przeprowadzone następujące procesy:

a. kompilacji kodu,

b. testy jednostkowe,

c. testy integracyjne,

d. budowa pakietu w celu wgrania na środowisko testowe.

Zespół programistów Wykonawcy w celu analizy logicznej kodu powinien dokonywać jego regularnego

ręcznego przeglądu.

Repozytoria kodu używane przez Wykonawcę muszą zapewnić system kontroli uprawnień i zabezpieczenia przed nieuprawnionym dostępem, w taki sposób, aby były one (repozytoria) dostępne jedynie dla członków projektu, co zapewni odpowiednią kontrolę wprowadzanych zmian, oraz ich rozliczalność.

Wymagania techniczne dotyczące przygotowania testów automatycznych muszą zostać szczegółowo opisane przez Wykonawcę na etapie wstępnej analizy rozwiązania i powinny stanowić załącznik do Planu Testów.

W przypadku testów automatycznych (w zakresie wydajnościowym) Wykonawca musi zapewnić stosowne narzędzia do testów (oprogramowanie do testowania), jak i specjalistów wspierających Zamawiającego w toku ich przeprowadzania, odnosi się to do:

1. Testów wydajnościowych (ET – Efficiency tests)

2. Testów disaster recovery (DR).

Szczegółowe plany zakresu merytorycznego testów mają powstać na etapie opracowania Planu Testów.

Testy akceptacyjne użytkownika (UAT)

Testy UAT zostaną przeprowadzane przez Zamawiającego w środowisku preprodukcyjnym przy asyście

Wykonawcy.

Przed przystąpieniem do testów UAT Wykonawca zobowiązany jest do pełnej konfiguracji Systemu, w tym także konfiguracji matrycy ról i uprawnień. Weryfikacja poprawności konfiguracji matrycy ról i uprawnień musi stanowić element testów UAT. Błędy w zakresie konfiguracji matrycy ról i uprawnień będą wliczane do ogólnej puli błędów z testów.

Podczas testów będzie wykonywana weryfikacja, czy System wraz z poszczególnymi jego elementami

spełnia potrzeby Zamawiającego oraz realizuje wszystkie wymagane procesy biznesowe.

Testy UAT w związku z charakterem akceptacji zostaną podzielone na:

1. Testy akceptacyjne zaimplementowanych funkcjonalności,

2. Testy zgodności oprogramowania z umową,

3. Testy akceptacyjne zgodności legislacyjnej,

4. Testy zgodności operacyjnej.

Testy UAT zostaną przeprowadzone przez specjalnie powołany w tym celu zespół po stronie Zamawiającego. w testach brać będą również przedstawiciele Wykonawcy.

Szczegółowe plany zakresu merytorycznego testów mają powstać na etapie opracowania Planu Testów.

Testy będą obejmowały od 60 – 100% przypadków testowych opisanych w Planie Testów. Zamawiający określi i poinformuje Wykonawcę o zakresie testów UAT przed rozpoczęciem procesu testowania.

1. W ramach testów Zamawiający zastrzega sobie prawo do przeprowadzenia testów

swobodnych zgodnie z następującymi wymaganiami:

a. Testy swobodne (ad-hoc) będą przeprowadzone przez Zamawiającego (z opcjonalnym udziałem użytkowników końcowych i/lub podmiotu trzeciego), jednakże w szczególnych przypadkach Zamawiający dopuszcza przeprowadzenie ich w obecności Wykonawcy.

b. Wykonawca przekaże dostępy i przygotuje środowisko do przeprowadzenia przez Zamawiającego testów swobodnych. Liczba osób biorących udział w testach swobodnych (wliczając w to Zamawiającego oraz inne strony uczestniczące w Projekcie) nie przekroczy 30 osób.

c. Zamawiający podczas testów swobodnych może wykorzystywać własne próbki

danych testowych.

d. Wykonawca jest zobowiązany do obsługi wszystkich błędów zgłoszonych przez Zamawiającego w ramach testów swobodnych.

e. Poprawa wszystkich błędów wykrytych w ramach testów swobodnych, uzasadnionych treścią OPZ, jest warunkiem niezbędnym do odbioru Systemu WIR.

f. Błędy wykryte w ramach testów swobodnych wliczane są do ogólnego wyniku testów dopuszczeniowych/akceptacyjnych.

g. Otrzymane wyniki realizacji testów ad-hoc są tożsame z wynikami testów

realizowalnych zgodnie z uzgodnionymi Scenariuszami testowymi.

2. Na podstawie przeprowadzonych testów akceptacyjnych Wykonawca przygotuje zbiorczy

Raport z testów akceptacyjnych.

3. Wynik testów akceptacyjnych jest pozytywny w przypadku, gdy liczba błędów wykrytych

w czasie testów akceptacyjnych nie przekracza limitu błędów dla testów akceptacyjnych.

4. Błędy wykryte w trakcie testów ( w tym testów swobodnych) będą obsługiwane zgodnie

z poniższymi wymaganiami:

a. Do rejestracji błędów wykorzystane zostanie Narzędzie wspomagające proces wytwórczy.

b. Sposób klasyfikacji błędów został opisany w rozdziale 13.1.1.

c. Zamawiający odpowiadają za nadawanie kategorii błędu oraz ostateczne zamknięcie obsłużonego błędu.

5. Po pozytywnym przejściu testów akceptacyjnych Wykonawca udostępni System do weryfikacji przez podmiot zewnętrzny w ramach testów bezpieczeństwa opisanych w rozdziale 13.2.

Testy Bezpieczeństwa (Wykonawcy)

Wykonawca zobowiązany jest do przeprowadzenia wewnętrznych testów bezpieczeństwa przed przekazaniem Systemu do testów bezpieczeństwa z udziałem podmiotu zewnętrznego.

Testy bezpieczeństwa Wykonawcy zostaną przeprowadzane w środowisku preprodukcyjnym. Szczegółowe plany zakresu merytorycznego testów mają powstać na etapie opracowania Planu Testów.

Testy bezpieczeństwa powinny być przeprowadzone w oparciu o OWASP Testing Guide, przy uwzględnieniu listy najpopularniejszych zagrożeń OWASP Top 10 oraz CWE/SANS Top 25 Weaknesses. w testach powinny zostać wykorzystane elementy metodyki PTES (Penetration Testing Execution Standard) oraz OSSTMM (Open Source Security Testing Methodology Manual) lub równoważne.

Do testów powinny zostać wykorzystane specjalistyczne narzędzia wspierające proces testowania (testy półautomatyczne). Testy powinny objąć zarówno aplikacje GUI oraz wszystkie usługi REST API udostępniane przez System WIR.

Wykonawca przedstawi Zamawiającemu Raport przedstawiający wynik wewnętrznych testów bezpieczeństwa.

Zamawiający przewiduje zaangażowanie przedstawicieli grup odbiorców Systemu WIR w procesie testowania usług oraz funkcjonalności Systemu, w wymiarze minimum 10 użytkowników z każdej z grup odbiorców, którzy będą tworzyć grupę kontrolną.

Klasyfikacja oraz limity Błędów

W trakcie trwania testów rejestrowane będą Błędy, których kategorie, definicje oraz limity zawarto w poniższej tabeli.

W przypadku, gdy zgłoszone Błędy przekroczą podane limity dla zdefiniowanych kategorii, testy zostaną przerwane, a Wykonawca zobowiązany jest do poprawy oprogramowania i jego ponownej weryfikacji.

Tabela 4 Kategorie Błędów i tolerancje dla testów wewnętrznych i akceptacyjnych

Kategoria

błędu

Definicja kategorii błędu i przykłady błędów

Limit błędów

Testy

wewnętrzne

Testy akceptacyjne

Błąd

krytyczny

- Nieprawidłowości uniemożliwiające działanie przynajmniej jednego z komponentów wytworzonego/dostarczonego przez Wykonawcę Systemu powodujący, że Zamawiający nie może korzystać z Systemu, w tym wykonywać procesów lub funkcji krytycznych obsługiwanych przez System i uzyskanie oczekiwanych efektów nie jest możliwe w inny sposób (poprzez zastosowanie Obejścia);

- Niezgodność działania całości lub części Systemu z wymogami zatwierdzonej (lub następnie zaktualizowanej) Dokumentacji Analitycznej, Dokumentacji Technicznej lub Planu Testów, której wystąpienie uniemożliwia lub istotnie utrudnia realizację przez System podstawowych funkcji biznesowych służących do bieżącej pracy użytkowników, dla której nie istnieje Obejście w ramach innych funkcjonalności Systemu lub

zastosowanie Obejścia wymagałoby nakładów

nieuzasadnionych z ekonomicznego punktu widzenia.

Przykładami błędu krytycznego są:

a. całkowity brak odpowiedzi systemu na sygnały;

b. brak działania lub implementacji istotnej funkcjonalności;

c. błędy innych typów uniemożliwiające korzystanie z systemu lub jego funkcjonalności;

d. brak spełnienia wymagania pozafunkcjonalnego;

e. brak spełnienia zapisu formalnego umowy związanego z cechami pozafunkcjonalnymi, wyglądem lub funkcjonalnością systemu (np. brak logotypów, niezgodność ze standardami i normami przywołanymi w umowie);

f. brak odczytu/zapisu z/do bazy danych,

g. utrata danych lub ich spójności,

h. brak możliwości zalogowania użytkownika,

i. wydajność systemu uniemożliwiająca zrealizowanie scenariuszy testowych w czasie określonym w Planie Testów (trzykrotne przekroczenie czasów realizacji scenariuszy testowych wobec założonych w Planie Testów).

Błąd poważny

Rodzaj nieprawidłowości uniemożliwiający działanie przynajmniej jednego z komponentów wytworzonego/dostarczonego przez Wykonawcę Systemu powodujący, że Zamawiający nie może korzystać z Systemu, w tym wykonywać procesów lub funkcji obsługiwanych przez System, lecz uzyskanie oczekiwanych efektów jest możliwe w inny sposób (poprzez zastosowanie Obejścia).

- Niezgodność działania całości lub części Systemu

z wymogami zatwierdzonej (lub następnie zaktualizowanej) Dokumentacji Analitycznej,

(zaokrąglając

w dół)

przypadków

testowych

Dokumentacji Technicznej lub Planu Testów, której wystąpienie nie uniemożliwia lub nie utrudnia istotnie realizacji przez System podstawowych funkcji biznesowych służących do bieżącej pracy użytkowników, dla której istnieje Obejście w ramach innych funkcjonalności Systemu.

Przykładami błędu poważnego są:

a. brak spełnienia wymagania funkcjonalnego - nieprawidłowe działanie systemu inne niż dotyczące istotnej funkcjonalności systemu;

b. działanie funkcjonalności niezgodne z opisem uzgodnionym i zawartym w DF lub Planie Testów;

c. powtarzające się błędy drobne dotyczące tej samej funkcjonalności;

d. komunikat wprowadzający użytkownika w błąd, co do wykonania istotnej funkcjonalności;

e. niezgodna z wymaganiami konieczność wywołania tej samej funkcji wielokrotnie w celu uzyskania pojedynczego rezultatu;

f. przy wywołaniu funkcjonalności pojawia się komunikat o błędzie, jednak system później realizuje działania związane z funkcjonalnością;

g. przekroczony czas reakcji systemu w stosunku do wymaganej jego wydajności.

Błąd zwykły

Niezgodność działania Systemu z wymogami zatwierdzonego (lub

następnie zaktualizowanego) Dokumentacji Analitycznej, Dokumentacji Technicznej lub Planu Testów polegająca na zakłóceniu pracy Systemu innym niż Błąd Krytyczny lub Błąd Poważny, nie wpływającym na pełne wykonanie określonego procesu w Systemie.

10%

(zaokrąglając

w dół)

przypadków

testowych

(zaokrąglając

w dół)

przypadków

testowych

Document Metadata

Table of Contents

OPIS PRZEDMIOTU ZAMÓWIENIA

Document Metadata