SPIS TREŚCI

Opis Przedmiotu Zamówienia na Centralny System Wymiany Informacji

SPIS TREŚCI

SPIS TREŚCI 1

1 DEFINICJE 4

2 OGÓLNY OPIS PRZEDMIOTU ZAMÓWIENIA 10

2.1 Kontekst biznesowy przedsięwzięcia 10

2.2 Zakres zamówienia 11

2.2.1 System CSWI 11

2.2.2 Infrastruktura jako Usługa 11

2.2.3 Usługa Administracji 11

2.2.4 Rozwój 11

2.2.5 Model utrzymania i rozwoju 11

3 OPIS KONCEPCJI ARCHITEKTURY LOGICZNEJ CSWI 12

3.1 Komunikacja 12

3.2 Zarządzanie metadanymi i cyklem życia usług 12

3.3 Adaptery 12

3.4 Administracja i zarządzanie 12

3.5 Mediacja 12

3.6 Monitorowanie 12

3.7 Równoważenie obciążenia i zapewnienie wysokiej dostępności 13

3.8 Transformacje złożone 13

3.9 BPM i orkiestracja 13

3.10 Raportowanie 13

3.11 Aplikacja Serwisowa 13

3.12 Portal 14

3.13 Archiwum Komunikatów 14

3.14 Repozytorium Modelu 14

3.15 Logowanie i audytowanie 14

3.16 Repozytorium Dokumentacji 14

3.17 Symulator UR CSWI (mockup) 14

3.18 Repozytorium Kodu 14

3.19 SZT CSWI 15

4 HARMONOGRAM I PRODUKTY 16

4.1 Wprowadzenie 16

4.2 Wdrożenie CSWI 16

4.2.1 Etap I – Analiza i projekt CSWI 16

4.2.2 Etap II – Implementacja IaaS i B2B CSWI 21

4.2.3 Etap III – Portal CSWI 24

4.2.4 Etap IV – Pilotażowe uruchomienie CSWI 25

4.2.5 Etap V – Uruchomienie Produkcyjne CSWI 27

4.2.6 Etap VI – Okres stabilizacji CSWI 28

5 MIGRACJA DANYCH I INICJALNA KONFIGURACJA CSWI 29

6 TESTY 30

6.1 Testy funkcjonalne 30

6.1.1 Testy fabryczne (FAT) 30

6.1.2 Testy systemowe (SAT) 30

6.1.3 Testy integracyjne 30

6.1.4 Testy akceptacyjne (UAT) 30

6.2 Testy bezpieczeństwa 30

6.3 Testy przełączenia na ośrodek zapasowy 30

6.4 Testy wydajnościowe 30

6.5 Testy przeciążeniowe 30

6.6 Testy wysokiej dostępności 30

7 WYMAGANIA WOLUMETRYCZNE, WYDAJNOŚCIOWE I POJEMNOŚCIOWE 31

7.1 Wydajność i pojemność PRD (praca w ośrodku podstawowym oraz zapasowym przy zachowaniu pełnej funkcjonalności) 31

8 PLANOWANA SKALA WYKORZYSTANIA SYSTEMU 31

9 DOBRE PRAKTYKI I STANDARDY 32

9.1 OWASP Top 10 – 2013 32

9.2 OWASP Testing Project 32

10 LICENCJONOWANIE I PRAWA AUTORSKIE 33

10.1 Wymagania dotyczące licencji (COTS) 33

10.1.1 Licencje na oprogramowanie 33

10.1.2 Termin 33

10.1.3 Zakres uprawnień 33

10.1.4 Open Source 36

10.2 Wymagania dotyczące praw autorskich 37

10.2.1 Elementy autorskie 37

10.2.2 Chwila przejścia praw 37

10.2.3 Brak obciążeń 37

11 DODATKOWE POSTANOWIENIA UMOWNE 38

11.1 Aktualizacje Systemu CSWI 38

11.2 Zakres 38

11.3 Brak obowiązku instalacji 38

11.4 Instalacja 38

11.5 Gwarancja 38

11.6 USŁUGA ADMINISTRACJI 38

11.7 Zakres i czas trwania 38

11.8 RTO 39

11.9 RPO 39

11.10 Zakres 39

11.11 Treść 39

11.12 Weryfikacja 39

12 ZAŁĄCZNIKI 40

12.1 Załącznik nr [1] Wymagania Funkcjonalne i Niefunkcjonalne 40

1 DEFINICJE

Ilekroć dane pojęcie zostanie napisane w OPZ wielką literą, Strony nadają mu znaczenie nadane w poniższej tabeli, przy czym:

1) jeśli dane pojęcie nie zostało zdefiniowane w poniższej tabeli, należy przypisać mu znaczenie nadane w Umowie,

2) jeśli dane pojęcie zostało zdefiniowane w poniższej tabeli oraz w Umowie, należy nadać mu znaczenie przypisane w Umowie.

API	- ang. Application Programming Interface, interfejs programistyczny aplikacji, sposób określający zestaw reguł i ich definicji, w jaki programy się komunikują między sobą.
BAM	ang. Business Activity Monitoring, funkcjonalność raportowania służącego do - monitorowania aktywności biznesowej (występowania i statusów zdarzeń biznesowych) w czasie rzeczywistym.
B2B	ang. Business-to-Business, model relacji pomiędzy przedsiębiorstwem a - przedsiębiorstwem. Tutaj: model korzystania z usług CSWI poprzez własne systemy IT.
BPEL	- ang. Business Process Execution Language, język przeznaczony do definiowania procesów biznesowych opartych o usługi sieciowe.
BPM	ang. Business Process Management, komponent służący do zarządzania zautomatyzowanymi procesami biznesowymi, posiadający własny silnik procesowy, - który zarządza przepływem pracy i dokumentów w organizacji oraz moduł pozwalający na definiowanie i modyfikowanie procesów przez przeszkolonych użytkowników biznesowych.
BPMN	- ang. Business Process Model Notation, niezależna od technologii notacja służąca do graficznego prezentowania procesów biznesowych.
CPD	- Centrum Przetwarzania Danych.
CSV	- ang. Comma Separated Values, format przechowywania danych w plikach tekstowych, gdzie wartości rozdzielone są przecinkami.
DDoS	ang. Distributed Denial of Service, atak, przeprowadzany z wielu komputerów, na - system informatyczny lub jego komponent mający na celu zablokowanie jego działania przez wysycenie wszystkich dostępnych zasobów.
DMZ	- ang. Demilitarized zone, strefa zdemilitaryzowana, obszar sieci komputerowej nienależący ani do sieci wewnętrznej ani do zewnętrznej.
Dokumentacja Administracyjna	element Dokumentacji obejmująca co najmniej następujące obszary: instalacja, konfiguracja, administracja, uruchamianie systemu, zatrzymywanie systemu, - restartowanie systemu, aktualizacja systemu, konta i uprawnienia wraz z procedurą zmiany haseł, Kopia zapasowa, przywracanie systemu po awarii/katastrofie, przełączanie do środowiska zapasowego, archiwizacja, monitoring, obsługa błędów wraz z opisaną listą kodów błędów.
Dokumentacja Oprogramowania COTS	element Dokumentacji powiązany z oprogramowaniem COTS i udostępniany przez - jego producenta.
Dokumentacja Oprogramowania Dedykowanego	element Dokumentacji, który został specjalnie stworzony w celu realizacji wymagań - Zamawiającego.

Dokumentacja Użytkowa	element Dokumentacji opisujący pełną funkcjonalność i działanie CSWI: zasady nawigowania, wprowadzania, modyfikacji i usuwania danych, zasady - parametryzacji (słowniki i katalogi danych), zasady zasilania danymi operacyjnymi, opis realizacji procesów i procedur biznesowych realizowanych przez CSWI, zasady wyszukiwania informacji, zasady bezpiecznej pracy.
ESB	ang. Enterprise Service Bus, korporacyjna szyna usługowa, stanowiąca - infrastrukturę do budowy SOA. Używana do integracji systemów dziedzinowych w przedsiębiorstwie.
FTE	- ang. Full Time Equivalent, odpowiednik pełnego czasu pracy
HA	ang. High Availability, wysoka dostępność – cecha systemu informatycznego - wynikająca z dostosowania jego niezawodności, dostępności i wydajności do ponadstandardowych wymagań.
HTTP/HTTPS	ang. Hypertext Transfer Protocol / Hypertext Transfer Protocol Secure, protokół - przesyłania dokumentów hipertekstowych w sieci WWW (w wersji HTTPS – szyfrowany protokołem SSL lub TLS).
IDS/IPS	ang. Intrusion Detection Systems / Intrusion Prevention Systems, systemy - wykrywania/zapobiegania włamaniom – urządzenia lub ich moduły zabezpieczające sieci komputerowe i ich zasoby poprzez wykrywanie lub wykrywanie i blokowanie ataków w czasie rzeczywistym.
JMS	- ang. Java Message Service, zestaw interfejsów i modeli asynchronicznego przesyłania komunikatów w języku Java.
JNDI	- ang. Java Naming and Directory Interface, interfejs języka Java pozwalający na odkrywanie i wyszukiwanie danych oraz obiektów za pomocą nazw
Kanoniczny Model Danych (KMD)	wzorzec projektowy przedsiębiorstwa, który wprowadza ujednolicone nazewnictwo danych, definicje i wartości w ramach ustandaryzowanej struktury danych.
KPI	- ang. Key Performance Indicators, kluczowe wskaźniki efektywności, wskaźniki stosowane jako mierniki realizacji procesów wspieranych przez CSWI.
LB	ang. Load Balancing, równoważenie obciążenia polegające na jego rozkładaniu na - wiele zasobów (np.. serwerów, procesorów, baz danych, serwerów aplikacji) według zdefiniowanych metod.
Middleware	oprogramowanie umożliwiające współdziałanie niezależnych i niepowiązanych ze sobą składników oprogramowania lub aplikacji biznesowych. Oprogramowanie middleware, zwykle umieszczane w warstwie pomiędzy systemem operacyjnym i aplikacjami, dostarcza usługi zapewniające obsługę współdzielenia zasobów, - zarządzania transakcjami, obsługę wielowątkowości oraz przesyłanie komunikatów. Pojęcie middleware obejmuje x.xx. serwery aplikacji, systemy kolejkowe, serwery integracyjne, systemy baz danych oraz silniki procesowe. Użycie oprogramowania middleware umożliwia aplikacjom współdziałanie z innymi aplikacjami z wykorzystaniem standardowych protokołów bez znajomości ich architektury.
NOSPF	- ang. No Single Point of Failure, architektura zaprojektowana w taki sposób, iż nie występują w niej pojedyncze punkty awarii.
LDAP	- ang. Lightweight Directory Access Protocol, protokół przeznaczony do korzystania z usług katalogowych.
Oprogramowanie jako Usługa	ang. Software as a Service (SaaS) model zdalnego udostępniania oprogramowania - (np. przez Internet), bez konieczności jego instalacji w systemach informatycznych klienta.

PKI	ang. Public Key Infrastructure, Infrastruktura klucza publicznego – ogół środków i mechanizmów technicznych (x.xx. algorytmy, protokoły, sprzęt, programy), organizacyjnych (x.xx urzędy certyfikacyjne (ang. Certification Authority (CA), - urzędy rejestracyjne (ang. Registration Authority (RA)), subskrybenci certyfikatów (użytkownicy) oraz prawnych (np. dyrektywy, ustawy) umożliwiających realizację różnych usług bezpieczeństwa przy zastosowaniu kryptografii klucza publicznego i w oparciu o certyfikaty.
Plan Testów	dokument opisujący przynajmniej następujące aspekty testów: 1.Cel przeprowadzenia testu. 2.Zasady organizacyjne, role uczestników testów, podział zadań. 3.Harmonogram testów, uwzględniający podział ze względu na procesy biznesowe. 4.Scenariusze testów, przygotowane w postaci formularzy zawierających specyfikację wszystkich czynności wchodzących w skład danego testu, uporządkowanych zgodnie z przebiegiem testu i zawierających co najmniej takie informacje jak: a) identyfikator, opis testowanego wymagania funkcjonalnego/pozafunkcjonalnego, b) nr kroku testowego, c) opis czynności do wykonania, - d) dane testowe (opis danych, którymi należy zasilić system, przy czym mogą to być dane, które należy wprowadzić za pomocą formatek edycyjnych, wpisując dane ręczenie lub zmieniając statusy, lub zaczytując dane z zewnątrz), e) użytkownik wykonujący (rola, funkcja), f) oczekiwany rezultat wraz ze szczegółowym opisem jego weryfikacji, g) czynności końcowe (w wypadku konieczności ich wykonania), h) uwagi – wpis „Brak” oznacza pozytywny rezultat kroku testowego, w przypadku, gdy są uwagi, osoba wykonująca testy powinna precyzyjnie wymienić zastrzeżenia, jeżeli to możliwe należy w takich przypadkach wykonać zrzuty ekranów świadczące o niewłaściwym działaniu Systemu i załączyć do raportu, zaś w miejscu sformułowania zastrzeżeń wprowadzić odpowiednie odnośniki do załączonych materiałów.
Procedura Awaryjna	instrukcja, obejmująca zestaw działań organizacyjnych i technicznych stosowany w - przypadku zakłócenia lub awarii, zapewniająca kontynuację procesu biznesowego lub działania nieprocesowego i osiągnięcie określonych dla tego procesu lub działania wyników.

Procedura Zmiany Usługodawcy IaaS	dokument opisujący działania organizacyjne i techniczne wymagane do przeniesienia i produkcyjnego uruchomienia CSWI na platformie IaaS udostępnionej przez Zamawiających. Główne elementy: a) plan migracji i uruchomienia produkcyjnego na platformie IaaS Zamawiających, b) podział zadań i obowiązków pomiędzy Wykonawcę a Zamawiających, - c) wytyczne do instalacji i konfiguracji IaaS, integracji z systemami wykonywania kopii zapasowych, monitorowania i korelacji dostępności i wydajności, monitorowania i korelacji bezpieczeństwa za pomocą SIEM, d) scenariusze testów i metody weryfikacji konfiguracji IaaS, e) metody migracji komponentów CSWI, f) scenariusze testów komponentów CSWI w celu weryfikacji poprawności działania na nowej platformie IaaS.
Profil UR	- konfiguracja CSWI definiująca elementy związane z Uczestnikiem Rynku (m. in. zakres uprawnień, zakres udostępnianych usług, konta UR).
Raport z Wdrożenia Produkcyjnego	dokument opisuje wykryte usterki i niedogodności odnoszące się do przyjętych założeń, wykonanych projektów oraz instalacji produkcyjnej wykryte podczas przeprowadzonych przez Wykonawcę testów wersji produkcyjnej Systemu oraz wyniki działań Wykonawcy podjętych w celu ich usunięcia. W dokumencie znajdują się zalecenia i wnioski w zakresie usprawnień funkcjonalnych i technicznych w produkcyjnej wersji Systemu. Dokument zawiera x.xx. następujące rozdziały: 1. Uwagi do działania systemu 2. Testy techniczne 2.1. Testy monitoringu - 2.2. Testy wydajnościowe 2.3. Testy wykonywania kopii zapasowych i odtwarzania 2.4. Testy przełączania na ośrodek zapasowy 2.5. Testy przeciążeniowe 2.6. Testy wysokiej dostępności 3. Opis działań Wykonawcy i ich rezultatów 4. Zalecenia i wnioski w zakresie usprawnień 4. Lista załączników, tabel i rysunków.
Repozytorium Dokumentacji	- baza całości wytworzonej lub dostarczonej przez Wykonawcę dokumentacji związanej z CSWI.
Repozytorium Kodu	- baza całości wytworzonego przez Wykonawcę kodu źródłowego Oprogramowania Dedykowanego wchodzącego w skład CSWI.
Repozytorium Modelu	baza artefaktów składających się na opis standardu wymiany informacji w - dedykowanym narzędziu IT pozwalającym na tworzenie, modyfikację i utrzymywanie tych artefaktów.
Repozytorium Usług	katalog usług i komponentów z nim powiązanych (WSDL, XSD) oferujący - funkcjonalności związane z obsługą tychże elementów tj.: definiowanie, wersjonowanie, wyszukiwanie, śledzenie i raportowanie zmian oraz import/eksport.
RPO	- ang. Recovery Point Objective, moment w przeszłości, w którym po raz ostatni wykonana została kopia danych i do którego będzie można powrócić działalności.

RTO	ang. Recovery Time Objective, maksymalny czas po awarii lub katastrofie potrzeby - do przywrócenia procesów biznesowych (wznowienia działania systemu informatycznego).
SIEM	ang. Security Information and Event Management, narzędzie z klasy systemów informatycznych służących do analizy w czasie rzeczywistym informacji i zdarzeń bezpieczeństwa informatycznego. Charakteryzuje się ono funkcjonalnościami: a) zbierania logów i agregacji danych pochodzących z różnych elementów CSWI oraz IaaS w sposób zapewniający ich niezmienność (na potrzeby audytów i informatyki śledczej (ang. computer forensics), z parametryzowalnymi okresami ich przechowywania), b) korelacji zdarzeń według zdefiniowanych reguł i analizy przepływów (ang. flows) oraz definiowania akcji dla określonych zdarzeń, - c) generowania raportów, d) automatycznego badania zgodności z politykami (ang. compliance), e) dostęp przez WWW z wykorzystaniem graficznego interfejsu użytkownika do centralnej konsoli, f) zarządzaniem dostępem użytkowników do funkcji i danych z funkcjonalnością tworzenia dla nich dedykowanych pulpitów, g) pozyskiwaniem najnowszych informacji o regułach, podatnościach, wzorcach oraz rekomendacjach dla wykrytych zdarzeń z źródeł o wysokiej reputacji (w tym producentów), h) rejestrowania wykonywanych akcji.
SLA	- ang. Service Level Agreement, umowa porozumienie o gwarantowanym poziomie świadczenia usługi określone przez jej parametry.
SOA	ang. Service Oriented Architecture, architektura zorientowana na usługi. Styl architektury (biznesowej i technicznej), który ma na celu uproszczenie - współdziałania różnych części biznesu poprzez wykorzystanie usług udostępniających logikę biznesową za pomocą dobrze zdefiniowanych interfejsów systemów informatycznych, co pozwala na zapewnienie większej elastyczności we wprowadzaniu zmian.
SOAP	- ang. Simple Object Access Protocol, protokół komunikacyjny korzystający z XML w celu kodowania wywołań oraz HTTP do ich przenoszenia
SOC	ang. Security Operations Center jednostka organizacyjna, w skład której wchodzą operatorzy oraz analitycy, zajmująca się: monitorowaniem, diagnozowaniem oraz - reagowaniem na zagrożenia w zakresie bezpieczeństwa teleinformatycznego w trybie ciągłym (przez całą dobę przez wszystkie dni w roku). Jednym z podstawowych narzędzi wykorzystywanych przez SOC jest system informatyczny klasy SIEM.
Standard ebIX	standard wymiany informacji opracowany przez ebIX mający na celu ustandaryzowanie modelu danych, zgodnie z którym prowadzona jest elektroniczna - wymiany informacji na europejskim rynku energii elektrycznej, z uwzględnieniem wymienianych komunikatów, procesów, w ramach których komunikaty są wymieniane oraz ról uczestniczących w komunikacji.
SVN	- ang. Subversion, system kontroli wersji.
SZT CSWI	- zestaw narzędzi wspierających zarządzanie oraz realizację testów, w szczególności automatyzację testów wydajnościowych oraz testów regresji.

Środowiska Systemu CSWI	a) PRD – produkcyjne (podstawowe oraz zapasowe), b) PPRD – pre-produkcyjne (przeznaczeniem środowiska jest: odtwarzanie błędów z produkcji, podłączanie nowych uczestników rynku, testy z uczestnikami rynku) => kopia środowiska produkcyjnego z danymi z tego środowiska, - c) TST – testowe (przeznaczeniem środowiska jest realizacja wszelkiego rodzaju testów), d) DEV – developerskie (przeznaczeniem środowiska jest rozwój systemu: tworzenie kolejnych wersji, usuwanie błędów).
TCP/IP	- ang. Transmission Control Protocol/ Internet Protocol, model warstwowej struktury protokołów komunikacyjnych.
UML	ang. Unified Modeling Language, Zunifikowany Język Modelowania służący do - zobrazowania, specyfikowania, tworzenia i dokumentowania składników systemów informatycznych.
UN/CEFAC	- organizacja zajmująca się opracowaniem standardów elektronicznej wymiany dokumentów (EDI) opartych o standard XML.
Utwardzanie (systemu informatycznego)	ang. Hardening, zabezpieczania systemów informatycznych przed potencjalnymi zagrożeniami poprzez dokonanie przeglądu i wprowadzenie zmian m. in. w - systemach operacyjnych, bazach danych, serwerach aplikacji oraz innych komponentach w celu podniesienia ich poziomu bezpieczeństwa. Zmiany mogą obejmować x.xx. usunięcie zbędnego oprogramowania, niepotrzebnych kont użytkowników, wyłączenie lub usunięcie zbędnych usług systemowych.
WSDL	- ang. Web Services Description Language, język oparty na XML przeznaczony do opisu usług sieciowych.
XML	- ang. Extensible Markup Language, język znaczników mający na celu prezentowanie danych w ustrukturyzowany sposób.
XPDL	- ang. XML Process Definition Language, format opisu definicji procesów biznesowych oparty o standard XML.
XSD	- ang. XML Schema Definition, rozszerzenie pliku w standardzie XML Schema definiującego strukturę dokumentów w języku XML.
XSLT	- ang. Extensible Stylesheet Language Transformations, język przeznaczony do transformacji pomiędzy różnymi dokumentami XML.
Zapytanie	- pytanie, wniosek o konsultacje merytoryczne dotyczące funkcjonalności CSWI.

2 OGÓLNY OPIS PRZEDMIOTU ZAMÓWIENIA

2.1 Kontekst biznesowy przedsięwzięcia

Zamawiający realizują projekt, którego celem jest wdrożenie w Polsce jednolitego modelu wymiany informacji między operatorami systemów dystrybucyjnych elektroenergetycznych (OSD), sprzedawcami energii oraz podmiotami odpowiedzialnymi za bilansowanie handlowe (POB), opartego o Standard ebIX.

Wdrożenie niniejszego modelu wymaga implementacji dedykowanego rozwiązania informatycznego odpowiadającego za wymianę informacji pomiędzy UR, zgodnie z opracowanymi Standardami CSWI, określającymi w szczególności opis realizacji procesów, zakres komunikatów objętych wymianą poprzez System CSWI, warunki walidacji komunikatów oraz zasady i terminy anulowania procesów. System informatyczny umożliwi jednolitą komunikację ze wszystkimi podmiotami na rynku dzięki wprowadzeniu powyższego standardu oraz skuteczne dostarczenie, monitorowanie i zarządzanie wymienianymi komunikatami.

Rozwiązanie przygotowane w ramach niniejszego projektu powinno być uniwersalne tj. zapewnić gotowość do uwzględnienia nowych ról i związanych z nimi funkcjonalności, w szczególności OIP.

Kluczowe wymagania

Poniżej przedstawiono kluczowe wymagania Zamawiających w stosunku do CSWI oraz jego wdrożenia:

− Komunikacja z wykorzystaniem Web Services,

− Monitoring komunikatów oraz poszczególnych usług, logowanie informacji o przetworzonych komunikatach, archiwizacja komunikatów, powiadomienia o błędach komunikacji, definiowanie KPI, czasów przetwarzania technicznego i biznesowego,

− Wysoka dostępność Systemu CSWI z monitorowaniem parametrów jakości oraz wydajności jego pracy oraz zautomatyzowanym dynamicznym rozkładem ruchu,

− Złożone przetwarzanie, transformacja i walidacja komunikatów,

− Zarządzanie dostępem do usług na poziomie technicznym i biznesowym dla podmiotów zewnętrznych, kanałów dostępów do usług, rozliczaniem/statystyk, badaniem efektywności procesu biznesowego.

− Bezpieczeństwo w zakresie B2C (użytkownik – Portal CSWI) oraz w komunikacji B2B (aplikacja – aplikacja): uwierzytelnienie i szyfrowanie,

− Zarządzanie cyklem życia i wersjami usług,

− Wykorzystanie Repozytorium Modelu, do projektowania komunikatów i usług,

− Wykorzystanie warstwy wirtualizacji, pozwalającej w przyszłości Zamawiającemu w łatwy sposób przenieść całość rozwiązania na inną infrastrukturę sprzętową,

− Wdrożenie w oparciu o model Infrastruktura jako Usługa.

Zamawiający wymaga, aby wdrożony CSWI wspierał realizację procesów biznesowych, zdefiniowanych szczegółowo w Standardach CSWI.

Zamawiający wymaga, aby powyższe procesy biznesowe zostały zaimplementowane w CSWI w ramach dedykowanego komponentu BPM.

Zamawiający wymaga, aby w ramach dedykowanego komponentu Raportowanie Wykonawca dostarczył inicjalny zestaw predefiniowanych raportów dotyczących biznesowych oraz technicznych aspektów działania CSWI.

Zamawiający nie dopuszczają możliwości wdrożenia CSWI w modelu Oprogramowanie jako Usługa.

Zamawiający wymaga, aby wszystkie komponenty CSWI zostały oparte na gotowym Oprogramowaniu COTS, przy czym dopuszczalne jest w ograniczonym zakresie wykonywanie prac programistycznych w celu spełnienia wymagań funkcjonalnych i pozafunkcjonalnych.

Dla: systemów operacyjnych, baz danych i serwerów aplikacyjnych i www Zamawiający wymaga realizacji całości funkcjonalności poprzez Oprogramowanie COTS (bez prac programistycznych).

Zamawiający wymaga, aby Wykonawca wraz z dostarczeniem CSWI, przekazał całość kodu źródłowego CSWI, wytworzonego w ramach realizacji zamówienia, w postaci kompletnego Repozytorium Kodu.

Zamawiający wymaga, aby Wykonawca wraz z dostarczeniem CSWI, przekazał całość wymaganej dokumentacji w postaci kompletnego Repozytorium Dokumentacji.

2.2 Zakres zamówienia

2.2.1 System CSWI

Wdrożenie i uruchomienie kompleksowego rozwiązania informatycznego CSWI bazującego na COTS wraz z gwarancją w sposób zapewniający przeniesienie Systemu CSWI na platformę sprzętowo – systemową udostępnioną przez Zamawiających.

2.2.2 Infrastruktura jako Usługa

Zamawiający wymagają, aby wraz z rozwiązaniem informatycznym, o którym mowa powyżej, Wykonawca dostarczył usługę udostępnienia infrastruktury sprzętowo – systemowej, z połączeniami do sieci Internet, niezbędne do zapewnienia poprawnego funkcjonowania CSWI.

Infrastruktura IaaS oraz wszelkie oprogramowanie do warstwy wirtualizacji włącznie, pozostaje własnością Wykonawcy i jest on zobowiązany do zarządzania wszystkimi elementami infrastruktury, na której uruchomiony jest System CSWI.

2.2.3 Usługa Administracji

Usługa, której celem jest zapewnienie prawidłowości działania, wydajności oraz bezpieczeństwa Systemu CSWI.

2.2.4 Rozwój

Opracowywanie oraz wdrażanie nowych funkcjonalności Systemu CSWI.

2.2.5 Model utrzymania i rozwoju.

Na poniższym rysunku przedstawiono model utrzymania i rozwoju.

3 OPIS KONCEPCJI ARCHITEKTURY LOGICZNEJ CSWI

W niniejszym rozdziale przedstawiono opis koncepcji architektury logicznej CSWI. Zamawiający dopuszcza zmiany w podziale na poszczególne komponenty z zachowaniem spełnienia kompletu określonych dla nich wymagań.

3.1 Komunikacja

Komponent odpowiedzialny za realizację funkcjonalności związanych z prowadzeniem komunikacji i zarządzania nią.

Komponent zapewnia wsparcie zarówno dla komunikacji synchronicznej, jak i asynchronicznej, odbywającej się w oparciu o standardowe protokoły komunikacyjne. Komponent wspiera również tryby gwarantujące dostarczenie komunikatów.

Komponent ponadto umożliwia definiowanie parametrów charakteryzujących sposób obsługi komunikatów przetwarzanych przez CSWI, począwszy od momentu ich odebrania, przez przetwarzanie i przesyłanie w ramach warstw komunikacyjnych CSWI, po dostarczanie do systemów docelowych. Komponent pozwala na zarządzanie jakością i dostępnością usług, w tym priorytetyzację obsługi żądań i przetwarzania wiadomości.

3.2 Zarządzanie metadanymi i cyklem życia usług

Komponent będący Repozytorium Usług na potrzeby zarządzania metadanymi przechowywanymi w tym repozytorium i ich cyklem życia.

Komponent pełni rolę katalogu usług i repozytorium artefaktów z nimi powiązanych (w postaci plików WSDL, XSD). W tym zakresie komponent oferuje funkcjonalności związane z obsługą artefaktów powiązanych z usługami i samych usług, takich jak x.xx. definiowanie usług i artefaktów, wersjonowanie ich, wyszukiwanie, śledzenie i raportowanie zmian w usługach, czy importowanie lub eksportowanie obiektów rejestru usług.

Komponent umożliwia dostęp do danych z Repozytorium Usług poprzez API oraz publikację informacji o usługach.

3.3 Adaptery

Komponent udostępnia gotowe adaptery technologiczne jak również narzędzia ułatwiające tworzenie nowych adapterów i reużywanie istniejących adapterów na potrzeby nowych usług.

3.4 Administracja i zarządzanie

Komponent odpowiedzialny za realizację funkcjonalności związanych z konfigurowaniem, zarządzaniem i monitorowaniem rozproszonych elementów platformy w sposób scentralizowany.

Komponent daje możliwość monitorowania, zarządzania alertami i powiadomieniami w przypadku wystąpienia nieprawidłowości w działaniu aplikacji, usług lub infrastruktury. Ponadto w ramach komponentu udostępniane powinny być narzędzia wspierające analizę błędów, w tym debugowanie na poziomie komunikatów.

Komponent pozwala na zarządzanie usługami, przepływami i transformacjami, w tym wprowadzanie zmian w parametrach w sposób nie przerywający ciągłości funkcjonowania CSWI.

3.5 Mediacja

Komponent odpowiedzialny za realizację funkcjonalności w zakresie routingu komunikatów i ich transformacji.

Komponent pozwala na definiowanie reguł określania ścieżki przekazywania komunikatów w sposób statyczny (tj. w czasie projektowania), jak również dynamiczny (definiowanych w czasie wykonania w oparciu o x.xx. reguły czy zawartość komunikatów).

Komponent zapewnia wsparcie dla wykonywania transformacji na mediowanych komunikatach (transformacja składniowa, m. in.. XSLT), a także wzbogacania przetwarzanych komunikatów o dane pochodzące z innych źródeł (bazy danych, JNDI, http).

3.6 Monitorowanie

Komponent odpowiedzialny za realizację funkcjonalności w zakresie monitorowania odbywającej się komunikacji, komponentów rozwiązania oraz CSWI jako całości.

Komponent pozwala na analizowanie w czasie rzeczywistym stanu komunikatów wymienianych z użyciem systemu w zakresie ich ilości i postępu w ramach przepływów/procesów, analizowanie danych zagregowanych – całościowego „ruchu” na szynie danych, a także zbieranie danych o pracy CSWI (w szczególności jego wydajności). W przypadku identyfikacji odchyleń od poziomów normalnych, komponent jest w stanie w sposób automatyczny dystrybuować powiadomienia do administratora systemu.

3.7 Równoważenie obciążenia i zapewnienie wysokiej dostępności

Komponent odpowiedzialny za realizację funkcjonalności w zakresie wyrównywania obciążenia elementów systemu i zapewniania wysokiej dostępności.

Komponent zapewnia wsparcie dla mechanizmów równoważenia obciążenia między serwerami usług i mechanizmów służących do zapewnienia wysokiej dostępności systemu, takich jak klastrowanie HA/LB.

3.8 Transformacje złożone

Komponent odpowiedzialny za realizację funkcjonalności w zakresie złożonych transformacji komunikatów.

Komponent zapewnia wsparcie dla składniowych i znaczeniowych transformacji danych.

Komponent pozwala na mapowanie pól w sposób bezwzględny i warunkowy, opisywanie interfejsów usług w standardzie WSDL, definiowanie struktury komunikatów i danych w formacie XSD, walidację komunikatów (w oparciu o WSDL i XSD), definiowanie zasad transformacji.

Komponent daje możliwość parsowania, tworzenia, transformacji i walidacji dokumentów XML z wykorzystaniem definicje XSD.

Komponent obsługuje wiele stron kodowych.

3.9 BPM i orkiestracja

Komponent odpowiedzialny za realizację funkcjonalności w zakresie definiowania logiki funkcjonowania rozwiązania w obszarze wspieranych procesów.

Komponent umożliwia definiowanie logiki przetwarzania o charakterze procesu (w tym o relatywnie krótkim czasie życia instancji procesu – orkiestracja), a także definiowanie logiki kompensacji, a następnie ich symulowanie i operacyjne stosowanie.

Komponent pozwala na wykorzystanie standardowych metod definiowania procesów (BPMN) i reprezentacji definicji procesów (BPEL, XPDL i inne).

W ramach komponentu istnieje repozytorium przechowujące modele procesów (wersjonowane), którymi można zarządzać i które mogą zostać eksportowane lub importowane.

Komponent pozwala również na zarządzanie realizowanymi procesami, edycję i prezentację procesów w repozytorium w środowisku graficznym, w oparciu o diagramy.

Zamawiający, w szczególności, wymaga monitorowania procesów określonych w Standardach CSWI za pomocą niniejszego komponentu.

3.10 Raportowanie

Komponent odpowiedzialny za monitorowanie (BAM) oraz raportowanie dotyczące technicznego oraz biznesowego działania CSWI, jak również definiowanie własnych pulpitów i raportów oraz szablonów dostępnych do późniejszej, niewymagającej stosowania i znajomości języków programistycznych parametryzacji przez użytkowników biznesowych.

Komponent pozwala na raportowanie na temat x.xx. KPI, wydajności, dostępności procesów i środowisk, zagadnień związanych z bezpieczeństwem. Monitorowanie i raportowanie powinno być możliwe z wykorzystaniem wielu źródeł danych.

Komponent daje możliwość automatycznego generowania alertów oraz raportów w zdefiniowanych sytuacjach i terminach, a także ich dystrybucji do zdefiniowanych użytkowników z użyciem poczty elektronicznej. Wygenerowane raporty powinny być również możliwe do wyeksportowania do szeregu standardowych formatów (x.xx. XLS, XML, PDF).

3.11 Aplikacja Serwisowa

Komponent odpowiedzialny za rejestrację oraz zarządzanie wszelkiego rodzaju błędami oraz

zgłoszeniami od Użytkowników CSWI (awariami, Zapytaniami oraz standardowymi zleceniami), a także pozwalający na ich procesową obsługę.

3.12 Portal

Komponent odpowiedzialny za umożliwienie użytkownikom, wykorzystywania funkcjonalności CSWI w modelu B2C.

Komponent umożliwia uczestnictwo we wszystkich procesach biznesowych CSWI, poprzez dawanie możliwości wyświetlania zawartości komunikatów, a także ich wymiany (m. in. w formacie XLS, XLSX, CSV i XML) Komponent udostępnia użytkownikom w przystępnej formie (poprzez interfejs graficzny) funkcje oraz dane niezbędne do uczestnictwa w procesach wspieranych przez CSWI, w tym dane pochodzące z komponentów BPM, Raportowanie i Archiwum komunikatów.

Komponent jest kompatybilny z najnowszymi wersjami przeglądarek internetowych

Komponent posiada osobny moduł umożliwiający zarządzanie użytkownikami, przeznaczony dla administratorów po stronie UR.

Komponent nie implementuje osobnej logiki biznesowej, (innej niż związanej z GUI), stanowi jedynie formę interfejsu między UR a CSWI.

Funkcjonalności udostępnione za pośrednictwem komponentu korzystać muszą z tych samych wersji usług które dostępne będą poprzez kanał B2B.

3.13 Archiwum Komunikatów

Komponent odpowiedzialny za przechowywanie komunikatów przetwarzanych z użyciem CSWI, pochodzących z każdego etapu ich przetwarzania.

Komponent pozwala na zaawansowane wyszukiwanie komunikatów w oparciu o wiele kryteriów, dostęp do nich i zarządzanie okresem przechowywania danych.

3.14 Repozytorium Modelu

Komponent umożliwiający projektowanie i dokumentowanie procesów, komunikatów, usług i przypadków użycia.

Komponent pozwala na automatyczne generowanie plików definiujących usługi, komunikaty i artefakty w oparciu o przechowywane w repozytorium informacje, wersjonowanie zdefiniowanych w repozytorium elementów, reużywanie obiektów i definiowanie powiązań między nimi.

3.15 Logowanie i audytowanie

Komponent odpowiedzialny za zapewnienie pełnej audytowalności wszystkich komponentów rozwiązania.

Komponent umożliwia logowanie i pozwala na późniejszą analizę (audyt) danych dotyczących dostępów do CSWI, zdarzeń aplikacji, operacji na obiektach, aktywności użytkowników i administratorów, błędów, naruszeń bezpieczeństwa. Generowane logi są zgodne z standardowymi, dobrze udokumentowanymi formatami i zawierają wszystkie informacje niezbędne do jednoznacznej identyfikacji transakcji i określenia ciągu zdarzeń.

3.16 Repozytorium Dokumentacji

Aplikacja umożliwiająca prowadzenie jednolitego rejestru dowolnych dokumentów elektronicznych wytworzonych na potrzeby CSWI. Zebrane dokumenty umieszczone będą w tematycznie pogrupowanej strukturze hierarchicznej, ułatwiającej dostęp do danych.

Przechowywane dokumenty mogą być w dowolny sposób indeksowane za pomocą słów kluczowych, Aplikacja umożliwi wersjonowanie dokumentów, ich wyszukiwanie oraz pełnotekstowe przeszukiwanie.

3.17 Symulator UR CSWI (mockup)

Komponent do wykonywania testów funkcjonalnych i wydajnościowych CSWI bez systemów UR.

3.18 Repozytorium Kodu

Komponent do zarządzania kodami źródłowymi CSWI.

3.19 SZT CSWI

Komponent do zarządzania testami CSWI.

4 HARMONOGRAM I PRODUKTY

4.1 Wprowadzenie

Niniejszy rozdział przedstawia wymagania Zamawiającego w zakresie: produktów prac w poszczególnych etapach projektu, a także podziału zadań pomiędzy Zamawiającego i Wykonawcę. W zakresie, w jakim niniejszy rozdział odwołuje się do zadań Zamawiającego lub „odpowiedzialności Stron”, należy je interpretować z uwzględnieniem postanowień Umowy dotyczących zakresu współdziałania przy realizacji Zamówienia (w szczególności Załącznika nr 7 do Umowy).

4.2 Wdrożenie CSWI

4.2.1 Etap I – Analiza i projekt CSWI.

4.2.1.1 Zadanie I.1 – Organizacja i ustalenie zasad zarządzania projektem

Celem zadania jest opracowanie wszystkich produktów związanych z zarządzeniem projektem. Zadania Wykonawcy:

1) Utworzenie struktur projektowych po stronie Wykonawcy.

2) Przeprowadzenie warsztatów.

3) Opracowanie produktów. Zadania Zamawiającego:

1) Utworzenie struktur projektowych po stronie Zamawiającego.

2) Zapewnienie udziału osób posiadających odpowiednią wiedzę i kompetencje w warsztatach i spotkaniach organizowanych przez Wykonawcę.

3) Weryfikacja, opiniowanie i akceptacja produktów prac. Produkty prac:

1) Plan wdrożenia i zarządzania wdrożeniem:

a. założenia, uwarunkowania i cele wdrożenia,

b. opis struktury organizacyjnej określający role, osoby, kontakty, zależności organizacyjne oraz zakresy odpowiedzialności Stron,

c. szczegółowy harmonogram wdrożenia, uwzględniający opis zależności między zadaniami i produktami.

2) Procedury projektowe w tym:

a. Plan zarządzania ryzykiem,

b. Plan zarządzania komunikacją,

c. Plan zarządzania zakresem,

d. Plan zarządzania zmianą,

e. Plan zarządzania jakością, w tym opis standardów projektowych m. in. w zakresie modelowania i dokumentowania, nazewnictwa i wewnętrznej struktury dokumentów projektowych,

f. Procedurę zgłaszania problemów,

g. Procedurę śledzenia i raportowania postępów prac,

h. Procedurę odbioru produktów,

i. Zasady prowadzenia prac deweloperskich w tym zasady zapewnienia jakości oprogramowania.

3) Wzory/szablony używanych dokumentów. Instruktaże:

1) Warsztaty z organizacji i zarządzania projektem i przedstawienie produktów prac dla

wskazanych przez Zamawiającego członków zespołu projektowego. Czas trwania: 2 Dni Robocze.

Liczba uczestników: do 30 osób.

Kryteria odbioru:

1) Produkty etapu bez uwag Zamawiającego.

4.2.1.2 Zadanie I.2 – Analiza

Celem zadania jest analiza wymagań funkcjonalnych i pozafunkcjonalnych wobec CSWI, a także stworzenie szczegółowej koncepcji funkcjonalnego ich pokrycia przez docelowe rozwiązanie.

Zadania Wykonawcy:

1) Potwierdzenie i uszczegółowienie wymagań na CSWI w oparciu o bieżącą współpracę z przedstawicielami Zamawiających.

2) Migracja modeli oraz związanych z nimi danych udostępnionych przez Zamawiających określonych w Załączniku nr [3] „EbIX Repository PL” (źródłem dla części danych jest repozytorium stworzone w narzędziu MagicDraw (MD)) do Repozytorium Modelu w skład których wchodzą w szczególności:

a. repozytorium stworzone w narzędziu MagicDraw 18.2 (zbiór plików),

b. pliki XSD wygenerowane za pomocą narzędzia ebIX Transformation Tool na podstawie danych z repozytorium MD,

c. pliki XSD oraz WSDL (Workspace) wygenerowane z narzędzia WebDesignTool (WSDL Editor WTP 1.5.1 działający w środowisku Eclipse Mars Release 4.5.0),

d. katalog i kontrakty usług (pliki .doc i xls.).

3) Weryfikacja i uspójnienie zaimportowanych danych oraz ich ulepszenie i dodanie informacji będących wynikiem analizy w Repozytorium Modelu.

4) Opracowanie produktów. Zadania Zamawiającego:

1) Zapewnienie udziału osób posiadających odpowiednią wiedzę i kompetencje w warsztatach oraz spotkaniach organizowanych przez Wykonawcę.

2) Weryfikacja, opiniowanie i akceptacja produktów prac. Produkty prac:

1) Projekt Funkcjonalny co do zasady stworzony i dostarczony w Repozytorium Modelu:

a. wymagania funkcjonalne,

b. aktorzy (rozdział powinien zawierać specyfikację wszystkich aktorów systemu z ich rolami),

c. procesy biznesowe (rozdział powinien zawierać wszystkie procesy, zamodelowane w BPMN wraz z opisem kroków),

d. przypadki użycia,

e. diagramy sekwencji,

f. logiczny model danych,

g. zakres informacyjny raportów,

h. zakres informacyjny wskaźników (KPI).

2) Zainicjowane Repozytorium Dokumentacji. Instruktaże:

1) Warsztat przedstawiający wyniki analizy. Czas trwania: 1 Dzień Roboczy.

Liczba uczestników: do 20 osób.

Kryteria odbioru:

1) Produkty etapu bez uwag Zamawiającego.

4.2.1.3 Zadanie I.3 – Projekt techniczny

Celem zadania projektu technicznego jest stworzenie szczegółowej technicznej koncepcji budowy, wdrożenia i eksploatacji CSWI.

Zadania Wykonawcy:

1) Opracowanie „Projektu Technicznego”.

2) Stworzenie macierzy pokrycia wymagań funkcjonalnych i pozafunkcjonalnych przez poszczególne elementy dokumentacji projektowej – przykład:

Wymaganie:

„Zapewniony jest czas odtworzenia Rozwiązania po katastrofie (RTO): środowisko produkcyjne: x godzin, środowiska testowe i rozwojowe: odtworzenie na tej samej infrastrukturze z kopii zapasowej po usunięciu awarii tej infrastruktury - y godzin”

Spełnienie wymagania:

„Opisane w Projekcie Technicznym w rozdziale „Zasady odtwarzania po katastrofie” w punkcie p na stronie n.

3) Opracowanie „Makiety Portalu CSWI”.

4) Opracowanie w porozumieniu z Zamawiającym „Zasad zarządzania CSWI„.

5) Opracowanie „Procedury przyłączenia UR do CSWI”.

6) Opracowanie „Wymagań technicznych wobec systemów informatycznych UR korzystających z CSWI”.

Zadania Zamawiającego:

1) Zapewnienie udziału osób posiadających odpowiednią wiedzę i kompetencje w warsztatach i spotkaniach organizowanych przez Wykonawcę.

2) Niezwłoczne udzielanie wyjaśnień dot. technicznych aspektów funkcjonowania CSWI w formie ustnej i/lub pisemnej.

3) Weryfikacja, opiniowanie i akceptacja produktów prac.

4) Udział w przygotowanych przez Wykonawcę instruktażach. Produkty prac:

1) Projekt Techniczny, co do zasady stworzony z wykorzystaniem Repozytorium Modelu, obejmujący w szczególności:

a. projekt procesów w BPEL, na poziomie technicznym, z uwzględnieniem:

a. obsługi błędów wewnątrz CSWI,

b. obsługi błędów pomiędzy CSWI i UR,

c. zależności czasowych dotyczących funkcjonowania procesów,

b. projekt usług komunikacyjnych wraz z ich kontraktami i specyfikacją (WSDL), w tym opisem reguł walidacji danych,

c. szablon implementacji usługi i implementacja jednej wybranej przez Zamawiającego usługi zgodnie z tym szablonem, wykonana w celu weryfikacji poprawności szablonu (ang. „Proof of Concept”),

d. bezpieczeństwo:

a. model bezpieczeństwa CSWI,

b. opis zastosowanych mechanizmów bezpieczeństwa,

c. koncepcja Utwardzenia poszczególnych komponentów CSWI,

d. profile i polityki (m. in. reguły dopuszczania ruchu na poziomie adresów IP, protokołów).

e. model ról i uprawnień.

e. projekty raportów (dane, algorytmy przetwarzania, szata graficzna, formatowanie),

f. projekty wskaźników KPI (definicje, algorytmy obliczeniowe, opis danych wejściowych i ich źródeł pochodzenia sposób obsługi po stronie systemu),

g. projekt środowiska sprzętowo-systemowego w każdej z istniejących warstw systemowych tj.:

a. warstwie infrastruktury fizycznej (serwery fizyczne, macierze dyskowe, biblioteki taśmowe, urządzenia sieci LAN/WAN łącznie z firewall/IDS/IPS/Load balancing oraz połączenia pomiędzy w/w komponentami wraz z adresacją IP),

b. warstwie maszyn wirtualnych (maszyny wirtualne, parametry konfiguracyjne, zależności funkcjonalne w tym HA/DR),

c. warstwie wirtualnych systemów operacyjnych (wersje, parametry konfiguracyjne, składniki systemowe w tym procesy i usługi systemowe),

d. warstwie serwerów aplikacyjnych i baz danych, innych usług systemowych (wersje, parametry konfiguracyjne),

e. diagramy i schematy w formacie uzgodnionego narzędzia modelowania prezentującymi wszystkie występujące komponenty środowisk w każdej z warstw oraz wszystkie powiązania pomiędzy komponentami zarówno w układzie poziomym (pomiędzy komponentami występującymi w danej warstwie) oraz w układzie pionowym (pomiędzy komponentami występującymi w różnych warstwach),

f. projekt wykonywania kopii zapasowych i odtwarzania w ramach Usługi IaaS

g. Projekt wykonywania archiwizacji i zapewnienia dostępu do danych archiwalnych

h. projekt monitorowania dostępności i wydajności systemów operacyjnych, serwerów aplikacyjnych, baz danych za pomocą systemu udostępnionego przez Wykonawcę w ramach usługi IaaS.

i. projekt monitorowania bezpieczeństwa z wykorzystaniem systemu SIEM (m. in. reguły korelacji zdarzeń, raporty, pulpity, okresy przechowywania danych) udostępnionego Zamawiającym przez Wykonawcę w ramach Usługi IaaS,

j. projekt konfiguracji narzędzi (m. in. Repozytorium Modelu, Repozytorium Kodu, Repozytorium Dokumentacji, SZT CSWI), wspierających realizację „Zasad zarządzania CSWI”.

h. Projekt funkcji/funkcjonalności systemu, który w szczególności musi zawierać (dla gotowych oraz stworzonych komponentów):

a. opis architektury – moduły/komponenty aplikacyjne, ich funkcje, przepływ danych i komunikacja z innymi komponentami, parametry biznesowe (parametry sterujące, słowniki) lokalizacji względem komponentów infrastrukturalnych i zależności pomiędzy nimi,

b. interfejs użytkownika (menu i ekrany),

c. specyfikację wymagań warstwy aplikacyjnej w zakresie infrastruktury,

d. specyfikację zastosowanych technologii wraz ze wskazaniem zakresu wykorzystania,

e. fizyczny model danych (z uwzględnieniem modułów).

2) Macierz pokrycia wymagań funkcjonalnych i pozafunkcjonalnych przez poszczególne elementy dokumentacji projektowej.

3) Makieta Portalu CSWI w postaci działającego prototypu interfejsu użytkownika opracowana ze

szczególnym uwzględnieniem:

a. użyteczności (ang. usability),

b. funkcjonalności,

c. estetyki.

4) „Zasady zarządzania CSWI”, obejmujące w szczególności: zasady zarządzania zmianą i zasady zarządzania konfiguracją oraz zasady zapewnienia jakości (procedury przenoszenia danych i komponentów pomiędzy różnymi typami środowisk, procedury budowania plików wykonywalnych na podstawie kodu źródłowego w dostarczonym Repozytorium Kodu, zasady tworzenia/aktualizacji dokumentacji i planów testów w SZT CSWI, zasady oznaczania wersji konfiguracji statusami, zasady oznaczania powiązań pomiędzy wersjami dokumentacji i wersjami komponentów, zasady komunikacji - w szczególności przekazywania informacji o dopuszczeniu wersji do instalacji na środowisku produkcyjnym, zainstalowaniu wersji i w danym środowisku, odrzuceniu wersji). Niniejsze zasady wspierają zarządzanie cyklem życia aplikacji (ang. Application Lifecycle Management).

Dla każdej przekazanej nowej wersji CSWI wymagany jest dokument zawierający x.xx.:

a. opis środowiska, na które została przygotowana wersja,

b. orientacyjny czas jaki zajmie wykonanie aktualizacji wersji na danym

środowisku,

c. zależności między innymi wersjami,

d. obiekty zmieniane w CSWI,

e. instrukcja instalacji,

f. instrukcja wycofania zmian związanych z instalacją wersji,

g. informacja o przeprowadzonej weryfikacji/testach.

5) „Wymagania techniczne wobec systemów informatycznych UR CSWI korzystających z CSWI” obejmujące w szczególności:

a. warunki dostępu (platformy sprzętowo – systemowe, wymaganie sieciowe i bezpieczeństwa),

b. wymagania w zakresie warstwy komunikacyjnej na poziomie Middleware,

c. pozostałe wymagania techniczne,

d. sprawy organizacyjne.

6) „ przyłączenia UR do CSWI” obejmująca w szczególności:

a. obowiązujące regulacje i powiązanie z innymi dokumentami,

b. założenia dla testów dla warstwy komunikacyjnej wraz z kryteriami akceptacji,

c. założenia dla testów dla warstwy aplikacyjnej wraz z kryteriami akceptacji z podziałem na role oraz procesy,

d. sprawy organizacyjne – role oraz zakresy obowiązków i uprawnień,

e. zasady zarządzania zmianą systemów informatycznych UR.

Instruktaże:

1) Warsztaty poświęcone produktom etapu.

Czas trwania: 1 Dzień Roboczy dla każdego z produktów. Liczba uczestników: do 20 osób.

2) Warsztaty techniczne dla przedstawicieli UR oraz Zamawiających w zakresie: „Wymagań technicznych wobec systemów informatycznych UR CSWI korzystających z CSWI” oraz

„Procedura przyłączenia UR do CSWI”.

Czas trwania: 2 Dni Robocze. Liczba uczestników: do 100 osób.

3) Instruktaże architektoniczne, administracyjne, deweloperskie z wykorzystywanych technologii. Czas trwania: 20 dni roboczych.

Liczba uczestników: do 15 osób.

4) Warsztaty poświęcone architekturze rozwiązań usługi IaaS ze szczególnym uwzględnieniem bezpieczeństwa.

Czas trwania: 1 dzień roboczy. Liczba uczestników: do 15 osób.

Kryteria odbioru:

1) Produkty etapu bez uwag Zamawiającego.

4.2.2 Etap II – Implementacja IaaS i B2B CSWI

4.2.2.1 Zadanie II.1 – IaaS i Środowiska Systemu CSWI

Celem zadania jest zapewnienie technicznej infrastruktury IaaS CSWI dla Środowisk Systemu CSWI. Zadania Wykonawcy:

1) Przygotowanie dokumentu „Plan testów IaaS i Środowisk Systemu CSWI”.

2) Przygotowanie Dokumentacji Administracyjnej dla IaaS i Środowisk Systemu CSWI.

3) Przygotowanie komponentu (nie jako usługa IaaS) do wsparcia testów (SZT CSWI) wykonywanych w ramach projektu i podczas eksploatacji CSWI.

4) Przygotowanie Dokumentacji Administracyjnej i Użytkowej SZT CSWI.

5) Dostarczenie i konfiguracja:

a. Usługi IaaS,

b. SZT CSWI,

c. Środowiska Systemu CSWI,

d. narzędzi umożliwiających administrowanie i monitorowanie ww. komponentów,

6) Przygotowanie scenariuszy testowych.

7) Zaimportowanie scenariuszy testowych do SZT CSWI.

8) Wykonanie testów przez Wykonawcę wg. zaakceptowanych przez Zamawiających scenariuszy testowych i przekazanie raportu z ich wykonania Zamawiającym.

Zadania Zamawiającego:

1) Weryfikacja, opiniowanie i akceptacja produktów prac.

2) Udział w przygotowanych przez Wykonawcę instruktażach. Produkty prac:

1) „Procedura Zmiany Usługodawcy IaaS”.

2) Dokument „Plan testów IaaS i środowisk CSWI” ze scenariuszami testowymi dla weryfikacji poprawności:

a. narzędzi do monitorowania Usługi IaaS,

b. narzędzi do monitorowania i administrowania środowisk CSWI i SZT CSWI,

c. wykonywania kopii zapasowych i odtwarzania,

d. Procedury Zmiany Usługodawcy IaaS,

e. dostarczonej usługi IaaS zgodnej z projektem technicznym (w tym mechanizmów wysokiej dostępności dla tej warstwy rozwiązania),

f. środowisk CSWI zgodnych z projektem technicznym (w tym mechanizmów Wysokiej Dostępności dla tej warstwy rozwiązania).

3) Dokumentacja Administracyjna dla IaaS i Środowisk CSWI.

4) Dokumentacja Administracyjna i Użytkownika SZT CSWI.

5) Raport z wykonanych przez Wykonawcę testów.

6) Uruchomiona infrastruktura w ramach Usługi IaaS.

7) SZT CSWI.

8) Środowiska Systemu CSWI – w postaci usługi IaaS wraz ze skonfigurowanymi maszynami wirtualnymi z co najmniej następującymi komponentami:

a. systemem operacyjny wraz z konfiguracją HA/LB,

b. bazy danych wraz z konfiguracją HA/LB,

c. serwery aplikacyjne wraz konfiguracją HA/LB,

d. pozostałe Oprogramowanie COTS,

e. mechanizmy wykonywania i odtwarzania kopii zapasowych,

f. skonfigurowany system SIEM.

Instruktaże:

1) Instruktaże dla osób uczestniczących w testach z wykorzystaniem SZT CSWI i warsztaty ze scenariuszy testowych.

Czas trwania: 2 Dni Robocze. Liczba uczestników: do 20 osób.

2) Warsztaty z przygotowanych produktów.

Czas trwania: 5 Dni Roboczych (wszystkie produkty łącznie). Liczba uczestników: do 15 osób.

Kryteria odbioru:

1) Produkty etapu bez uwag Zamawiającego.

2) Poprawne wykonanie testy przy pomocy SZT CSWI i zgodnie z przygotowanymi scenariuszami testowymi.

4.2.2.2 Zadanie II.2 – B2B CSWI

Celem zadania jest zbudowanie, instalacja, konfiguracja i weryfikacja działania modułu B2B CSWI (w tym wszystkich funkcjonalności wymaganych przez Zamawiającego, a nie związanych z Portalem CSWI) na Środowiskach Systemu CSWI.

Zadania Wykonawcy:

1) Przygotowanie dokumentu „Plan testów B2B CSWI”.

2) Przygotowanie scenariuszy testowych.

3) Przygotowanie danych niezbędnych do przeprowadzenia testów B2B CSWI.

4) Zbudowanie, instalacja i konfiguracja B2B CSWI na środowisku deweloperskim.

5) Zbudowanie, instalacja i konfiguracja Symulatora UR CSWI na środowisku deweloperskim.

6) Przygotowanie Dokumentacji Administracyjnej B2B CSWI.

7) Przygotowanie Dokumentacji Administracyjnej i Użytkownika Symulatora UR CSWI.

8) Instalacja i konfiguracja B2B CSWI zgodnie z Dokumentacją Administracyjną na środowisku testowym, pre-produkcyjnym i produkcyjnym oraz sporządzenie raportu z tej operacji.

9) Instalacja i konfiguracja Symulatora CSWI zgodnie z Dokumentacją Administracyjną na

środowisku testowym, pre-produkcyjnym i produkcyjnym oraz sporządzenie raportu z tej

operacji.

10) Zaimportowanie scenariuszy testowych do SZT CSWI.

11) Wykonanie testów fabrycznych (FAT) B2B CSWI na środowisku deweloperskim z wykorzystaniem Symulatora UR CSWI i przekazanie Zamawiającym raportu z ich wykonania.

12) Wykonaniu testów systemowych (SAT) B2B CSWI i przekazanie Zamawiającym raportu z ich wykonania.

Zadania Zamawiającego:

1) Weryfikacja, opiniowanie i akceptacja produktów prac.

2) Asysta przy instalacji B2B CSWI na środowisku testowym, pre-produkcyjnym i produkcyjnym zgodnie z przekazaną Dokumentacją Administracyjną i paczkami instalacyjnymi B2B CSWI.

3) Asysta przy instalacji Symulatora UR CSWI na środowisku testowym, pre-produkcyjnym oraz produkcyjnym zgodnie z przekazaną Dokumentacją Administracyjną i paczkami instalacyjnymi Symulatora UR CSWI.

4) Asysta przy testach systemowych (SAT) B2B CSWI przy użyciu SZT CSWI i Symulatora UR CSWI zgodnie ze scenariuszami testowymi opracowanymi dla produktów tego zadania.

Produkty prac:

1) Dokument „Plan testów B2B CSWI” ze scenariuszami testowymi dla weryfikacji poprawności:

a. funkcjonalności B2B CSWI,

b. wydajności B2B CSWI,

c. wysokiej dostępności CSWI (testy awarii poszczególnych elementów rozwiązania),

d. bezpieczeństwa CSWI w tym wykorzystania systemu SIEM oraz weryfikacji zrealizowanego Utwardzenia, ,

e. pozostałych wymagań pozafunkcjonalnych B2B,

f. procesu wytwórczego B2B CSWI i przenoszenia zmian między środowiskami w tym roll-out i roll-back,

g. narzędzi do monitorowania i administrowania B2B CSWI (w tym wykonywania kopii zapasowych i odtwarzania oraz „Procedury Zmiany Usługodawcy IaaS”).

2) Dane niezbędne do przeprowadzenia testów.

3) SZT CSWI skonfigurowany do wykonania scenariuszy testowych tego zadania.

4) Raporty z wykonanych przez Wykonawcę testów FAT i SAT.

5) Dokumentacja Administracyjna B2B CSWI.

6) Dokumentacja Administracyjna Symulatora UR CSWI.

7) Dokumentacja Użytkowa Symulatora UR CSWI.

8) Raport z instalacji i konfiguracji systemu.

9) Zainstalowana i skonfigurowana wersja aplikacji B2B CSWI.

10) Zainstalowana i skonfigurowana wersja aplikacji Symulatora UR CSWI.

11) Zaktualizowana w zakresie B2B „Procedura Zmiany Usługodawcy IaaS”.

12) Zaktualizowane „Wymagania techniczne wobec systemów informatycznych UR CSWI korzystających z CSWI”. Zaktualizowana „Procedura przyłączenia UR do CSWI”.

Instruktaże:

1) Prezentacja B2B CSWI.

Czas trwania: 1 Dzień Roboczy. Liczba uczestników: do 20 osób.

2) Warsztat biznesowy poświęcony korzystaniu z CSWI dla UR. Czas trwania: 1 Dzień Roboczy.

Liczba uczestników: do 100 osób.

3) Warsztat techniczny B2B CSWI dla UR. Czas trwania: 1 Dzień Roboczy

Liczba uczestników: do 100 osób.

Kryteria odbioru:

1) Produkty etapu bez uwag Zamawiającego.

2) Poprawne wyniki testów przy pomocy SZT CSWI i Symulator UR CSWI zgodnie z przygotowanymi scenariuszami testowymi.

4.2.3 Etap III – Portal CSWI

Celem etapu jest zbudowanie, instalacja, konfiguracja i weryfikacja działania Portalu CSWI zgodnie z Projektem Funkcjonalnym i Technicznym oraz zgodnie z makietą Portalu CSWI na Środowiskach Systemu CSWI.

Zadania Wykonawcy:

1) Przygotowanie dokumentu „Plan testów Portalu CSWI”.

2) Przygotowanie scenariuszy testowych.

3) Przygotowanie danych niezbędnych do przeprowadzenia testów Portalu CSWI.

4) Zbudowanie, instalacja i konfiguracja Portalu CSWI na środowisku deweloperskim.

5) Przygotowanie Dokumentacji Administracyjnej oraz Użytkownika Portalu CSWI.

6) Instalacja i konfiguracji Portal CSWI zgodnie z Dokumentacją Administracyjną na środowisku testowym, pre-produkcyjnym i produkcyjnym oraz sporządzenie raportu z tej operacji.

7) Przygotowanie konfiguracji Symulatora UR CSWI na potrzeby testów.

8) Zaimportowanie scenariuszy testowych do SZT CSWI.

9) Wykonanie testów fabrycznych (FAT) Portalu CSWI na środowisku deweloperskim z wykorzystaniem Symulatora UR CSWI oraz SZT CSWI i przekazanie Zamawiającym raportu z ich wykonania.

10) Wykonaniu testów systemowych (SAT) Portalu CSWI i przekazanie Zamawiającym raportów z ich wykonania.

Zadania Zamawiającego:

1) Weryfikacja, opiniowanie i akceptacja produktów prac.

2) Asysta przy instalacji i konfiguracji Portal CSWI zgodnie z Dokumentacją Administracyjną na

środowisku testowym, pre-produkcyjnym i produkcyjnym.

3) Asysta przy testach systemowych (SAT) Portalu CSWI przy użyciu SZT CSWI i Symulatora UR CSWI zgodnie ze scenariuszami testowymi opracowanymi dla produktów tego zadania

Produkty prac:

1) Dokument „Plan testów Portalu CSWI” ze scenariuszami testowymi dla weryfikacji poprawności:

a. funkcjonalności Portalu CSWI,

b. wydajności Portalu CSWI,

c. wysokiej dostępności Portalu CSWI (testy awarii poszczególnych elementów rozwiązania)

d. bezpieczeństwa Portalu CSWI w tym wykorzystania systemu SIEM oraz weryfikacji zrealizowanego Utwardzenia,

e. pozostałych wymagań pozafunkcjonalnych Portalu CSWI

f. procesu wytwórczego Portalu CSWI i przenoszenia zmian między

środowiskami w tym roll-out i roll-back,

g. narzędzi do monitorowania i administrowania Portalu CSWI (w tym wykonywania kopii zapasowych i odtwarzania oraz „Procedury Zmiany Usługodawcy IaaS”).

2) Dane niezbędne do przeprowadzenia testów.

3) Skonfigurowana do testów Portalu CSWI wersja Symulatora UR CSWI.

4) SZT CSWI skonfigurowany do wykonania scenariuszy testowych tego zadania.

5) Raporty z wykonanych przez Wykonawcę testów.

6) Dokumentacja Administracyjna Portalu CSWI.

7) Dokumentacja Użytkownika Portalu CSWI.

8) Raporty z instalacji i konfiguracji aplikacji.

9) Zainstalowana i skonfigurowana wersja Portal CSWI.

10) Zaktualizowane w zakresie Portalu CSWI: „Procedura Zmiany Usługodawcy IaaS”, „Procedura przyłączenia UR do CSWI” oraz „Wymagania techniczne wobec systemów informatycznych UR CSWI korzystających z CSWI”.

11) E-learning dla użytkowników Portalu CSWI udostępniony na platformie Wykonawcy w okresie obowiązywania Umowy.

Instruktaże:

1) Prezentacja funkcjonalności Portalu CSWI. Czas trwania: 1 Dzień Roboczy.

Liczba uczestników: do 30 osób.

2) Warsztaty z administracji Portalu CSWI dla UR. Czas trwania: 1 Dzień Roboczy.

Liczba uczestników: do 100 osób.

3) Warsztat biznesowy poświęcony korzystaniu z Portalu CSWI dla UR. Czas trwania: 1 Dzień Roboczy.

Liczba uczestników: do 100 osób.

4) Instruktaż z obsługi platformy E-learning. Czas trwania: 1 Dzień Roboczy.

Liczba uczestników: do 30 osób.

Kryteria odbioru:

1) Produkty etapu bez uwag Zamawiającego.

2) Poprawne wyniki testów przy pomocy SZT CSWI i Symulatora UR CSWI zgodnie z przygotowanymi scenariuszami testowymi.

4.2.4 Etap IV – Pilotażowe uruchomienie CSWI

Celem etapu jest podłączenie:

• dwóch OSD,

• jednego OSDn,

• dwóch SE (w tym co najmniej jednego występującego również w roli POB i jednego korzystającego wyłącznie z Portalu CSWI),

do CSWI (środowisko produkcyjne) i wykonanie testów CSWI z udziałem tych UR.

Zadania Wykonawcy:

1) Przygotowanie dokumentu „Plan testów” dla tego zadania.

2) Przygotowanie scenariuszy testowych dla tego zadania.

3) Przygotowanie danych niezbędnych do przeprowadzenia testów.

4) Zaimportowanie scenariuszy testowych do SZT CSWI.

5) Wykonanie konfiguracji dla podłączenia UR do CSWI.

6) Wsparcie techniczne i organizacyjne Uczestników Rynku podczas podłączania UR oraz przygotowanie dla Zamawiających raportu z jego wykonania.

7) Wykonanie testów integracyjnych Systemu CSWI z udziałem przedstawicieli i systemów UR oraz SZT CSWI i Symulatora UR CSWI.

8) Asysta i wsparcie realizacji testów akceptacyjnych (UAT) Systemu CSWI prowadzonych przez przedstawicieli Zamawiających z wykorzystaniem SZT CSWI, Symulatora UR CSWI.

Zadania Zamawiającego:

1) Współpraca przy opracowywaniu procedur i danych do testów.

2) Koordynacja współpracy z przedstawicielami UR.

3) Weryfikacja, opiniowanie i akceptacja produktów prac.

4) Asysta przy testach integracyjnych Systemu CSWI z udziałem przedstawicieli i systemów UR oraz SZT CSWI i Symulatora UR CSWI.

9) Wykonanie testów akceptacyjnych (UAT) Systemu CSWI z wykorzystaniem SZT CSWI, Symulatora UR CSWI.

Produkty prac:

1) Dokument „Plan testów” w zakresie testów integracyjnych oraz testów akceptacyjnych (UAT).

2) Dane niezbędne do przeprowadzenia testów.

3) Symulator UR CSWI skonfigurowany do wykonania scenariuszy testowych niniejszego etapu.

4) SZT CSWI skonfigurowany do wykonania scenariuszy testowych niniejszego etapu.

5) Aktualizacja wszystkich produktów zmienianych w ramach niniejszego etapu.

6) Raport z testów.

7) Rozwiązanie skonfigurowane do współpracy z UR

8) Podłączenie UR, którzy zgłosili gotowość do przyłączenia, do CSWI. Instruktaże:

1) Prezentacja z podsumowania etapu. Czas trwania: 1 Dzień Roboczy. Liczba uczestników: do 30 osób.

2) Warsztat biznesowy poświęcony korzystaniu z CSWI dla UR. Czas trwania: 1 Dzień Roboczy.

Liczba uczestników: do 100 osób.

3) Warsztat techniczny CSWI dla UR. Czas trwania: 1 Dzień Roboczy. Liczba uczestników: do 100 osób.

Kryteria odbioru:

1) Produkty etapu bez uwag Zamawiającego.

2) Poprawne wyniki testów przy pomocy SZT CSWI i Symulatora UR CSWI zgodnie z

przygotowanymi scenariuszami testowymi.

4.2.5 Etap V – Uruchomienie Produkcyjne CSWI

Celem etapu jest przygotowanie Środowisk Systemu CSWI do startu produkcyjnego oraz podłączenie wszystkich UR gotowych do korzystania z CSWI.

Etap kończy się pełnym uruchomieniem produkcyjnym CSWI.

Podczas tego etapu CSWI następuje podłączenie wszystkich UR, którzy zgłosili taką gotowość, poprzez wykonanie procedury przyłączenia dla każdego z UR.

Zadania Wykonawcy:

1) Przygotowanie konfiguracji dla Środowisk Systemu CSWI w tym wyczyszczenie danych testowych z ww. środowisk po poprzednich etapach.

2) Przygotowanie planu przeprowadzenia integracji z UR.

3) Wsparcie techniczne UR podczas prac przygotowawczych i podczas wykonywania procedur przyłączania UR.

4) Aktualizacja wszystkich produktów zmienianych w ramach tego zadania.

5) Prace przyłączeniowe w zakresie UR po stronie CSWI i administracja rozwiązaniem.

6) Przygotowanie planów testów i scenariuszy testowych.

7) Wykonanie Testów:

a. przełączania na ośrodek zapasowy,

b. wydajnościowych,

c. przeciążeniowych,

d. wysokiej dostępności.

8) Asysta i wsparcie realizacji Testów bezpieczeństwa wykonywanych przez Zamawiających. Zadania Zamawiającego:

1) Współpraca przy opracowywaniu planu podłączania UR.

2) Nadzór nad procesem przyłączania i koordynacja prac z UR.

3) Zarządzanie pracami przyłączeniowymi po stronie CSWI.

4) Koordynacja współpracy z przedstawicielami UR.

5) Weryfikacja, opiniowanie i akceptacja produktów prac.

6) Asysta przy testach wykonywanych przez Wykonawcę.

7) Wykonanie Testów bezpieczeństwa. Produkty prac:

1) System CSWI gotowy do startu produkcyjnego.

2) Plan przyłączeń UR do CSWI.

3) Raporty z przyłączenia UR.

4) Zaktualizowane wszystkie produkty wcześniejszych etapów zgodnie ze stanem na dzień pełnego uruchomienia produkcyjnego CSWI (opracowana dokumentacja powykonawcza).

5) „Model eksploatacji CSWI” zawierający:

a. strukturę organizacyjną oraz macierz odpowiedzialności dla procesu eksploatacji CSWI uwzględniający wszystkich udziałowców procesu,

b. zasady współpracy operacyjnej pomiędzy użytkownikami CSWI, różnej specjalności administratorami/użytkownikami Zamawiających oraz Wykonawcą,

c. Procedury Awaryjne,

d. zasady zgłaszania potrzeb rozwojowych oraz procedowania związanych z tym wniosków.

6) „Raport z Wdrożenia Produkcyjnego”.

7) Poprawne wykonane Testy:

a. przełączania na ośrodek zapasowy,

b. wydajnościowych,

c. przeciążeniowych,

d. wysokiej dostępności.

8) Pozytywny wynik testów bezpieczeństwa. Instruktaże:

1) Prezentacja z podsumowania etapu. Czas trwania: 1 Dzień Roboczy. Liczba uczestników: do 30 osób.

Kryteria odbioru:

1) Produkty etapu bez uwag Zamawiającego.

4.2.6 Etap VI – Okres stabilizacji CSWI

Podczas niniejszego etapu Zamawiający oraz Wykonawca monitorują zgodność działania CSWI z wymaganiami. Zidentyfikowane w tym okresie wady i usterki są usuwane na bieżąco.

Zadania Wykonawcy:

1) Wsparcie techniczne UR podczas prac przygotowawczych i podczas wykonywania procedur przyłączania UR.

2) Świadczenie gwarancji.

3) Podwyższona gotowość do usuwania wad i usterek – członkowie zespołu Wykonawcy są dostępni w lokalizacji wskazanej przez Zamawiającego.

4) Aktualizacja wszystkich produktów zmienianych w ramach tego etapu. Zadania Zamawiającego:

1) Monitorowanie CSWI.

2) Podwyższona gotowość do współpracy z Wykonawcą w zakresie usuwania wad i usterek CSWI.

3) Nadzór i koordynacja prac.

4) Weryfikacja, opiniowanie i akceptacja produktów prac. Produkty prac:

1) Raport z Etapu Stabilizacji. Kryteria odbioru:

1) Produkty etapu bez uwag Zamawiającego.

2) Spełnienie parametrów określonych w § 142. Umowy.

5 MIGRACJA DANYCH I INICJALNA KONFIGURACJA CSWI

W ramach przedmiotu Umowy nie jest przewidywana migracja danych z zewnętrznych rozwiązań informatycznych. Procesy biznesowe (i związane z nimi dokumenty/komunikaty), które będą w trakcie realizacji w momencie przełączania UR na CSWI nie będą przenoszone do tego systemu i zostaną zakończone w sposób w jaki obecnie są realizowane. Konsekwencją tego dla UR jest obsłużenie takich trwających procesów poza CSWI.

6 TESTY

W niniejszym rozdziale przedstawiono opis rodzajów testów do przeprowadzenia przez Wykonawcę (z wyłączeniem Testów akceptacyjnych i bezpieczeństwa.

6.1 Testy funkcjonalne

Za przygotowanie danych testowych odpowiedzialny jest Wykonawca przy wsparciu i udziale Zamawiającego.

W ramach procesu wytwórczego CSWI Zamawiający przewiduje, że proces testów funkcjonalnych dzieli się na zasadnicze elementy:

6.1.1 Testy fabryczne (FAT)

Celem Testów jest potwierdzenie spełnienia wymagań funkcjonalnych i integracyjnych oraz zamknięcie fazy dewelopmentu.

6.1.2 Testy systemowe (SAT)

Celem testów systemowych jest potwierdzenie iż komponenty przeniesiony na środowisko testowe Zamawiającego spełnia wymagania funkcjonalne oraz pozafunkcjonalne.

6.1.3 Testy integracyjne

Testy prowadzone z udziałem wybranych UR dla – wszystkich komponentów CSWI.

Celem Testów jest wstępne potwierdzenie, iż CSWI wraz ze wszystkimi komponentami spełnia wymagania.

6.1.4 Testy akceptacyjne (UAT)

Pełne testy procesowe prowadzone na środowisku testowym.

Celem testów UAT jest potwierdzenie, iż CSWI wraz z otoczeniem spełnia wymagania i jest gotowy do pełnego uruchomienia produkcyjnego (celem tych testów nie jest wykrywanie błędów, albowiem oprogramowanie dostarczone do tej fazy testów powinno być sprawne i stabilne).

6.2 Testy bezpieczeństwa

Testy bezpieczeństwa wykonuje zespół Zamawiającego przy udziale Wykonawcy i obejmują one w szczególności: audytu bezpieczeństwa, testy penetracyjne (łącznie z DDoS) przeprowadzane na wersji CSWI według stanu z końca UAT. Testy prowadzone będą z wykorzystaniem narzędzi automatycznych oraz weryfikacji i monitorowania CSWI i IaaS przez zespół Zamawiającego.

W ramach testów bezpieczeństwa sprawdzane jest spełnienie przez CSWI wymagań bezpieczeństwa.

6.3 Testy przełączenia na ośrodek zapasowy

Testy przełączenia na ośrodek zapasowy polegają na weryfikacji przygotowanych rozwiązań i procedur opisujących działania w przypadku katastrofy (awarii ośrodka podstawowego) związanych z przełączeniem przetwarzania na ośrodek zapasowy.

6.4 Testy wydajnościowe

Testy wydajnościowe realizowane są przez Wykonawcę pod nadzorem Zamawiającego.

W ramach testów wydajnościowych sprawdzane jest spełnienie przez CSWI wymagań wydajności.

Testy wykonywane są z lokalizacji udostępnionej przez Wykonawcę, ale spełniającej wymóg wykorzystywania łącz CPD Wykonawcy z siecią Internet.

6.5 Testy przeciążeniowe

Celem tych testów jest poznanie granicznej wydajności CSWI (poprawna praca całego CSWI z zachowaniem przyjętych parametrów SLA).

6.6 Testy wysokiej dostępności

Celem tych testów jest weryfikacja odporności CSWI na awarie pojedynczych komponentów architektury fizycznej CSWI lub pojedynczych komponentów aplikacyjnych CSWI w ramach jednego ośrodka.

7 WYMAGANIA WOLUMETRYCZNE, WYDAJNOŚCIOWE I POJEMNOŚCIOWE

7.1 Wydajność i pojemność PRD (praca w ośrodku podstawowym oraz zapasowym przy zachowaniu pełnej funkcjonalności)

• Minimalny okres przechowywania komunikatów (tryb on-line) w Archiwum Komunikatów: 16 miesięcy (przyjęto założenie, iż przechowywane są dwie instancje komunikatu biznesowego),

• Maksymalny czas wyświetlenia każdej formatki ekranowej B2C: 2 sekundy,

• Maksymalny czas wygenerowania raportu B2C: 5 sekund.

• Maksymalny czas dodania komunikatu za pomocą B2C: 4 sekundy.

• Liczba komunikatów przesyłanych i przetwarzanych przez CSWI (miesięcznie): 60 000 000,

• Liczba komunikatów przesyłanych i przetwarzanych przez CSWI (dobowo): 5 000 000,

• Liczba komunikatów przesyłanych i przetwarzanych przez CSWI (na sekundę): 100,

• Liczba jednoczesnych użytkowników B2C: 1000:

• Średnia wielkość komunikatu: 1,5 kB

8 PLANOWANA SKALA WYKORZYSTANIA SYSTEMU

Poniżej podano liczby charakteryzujące spodziewaną skalę wykorzystania systemu.

• Liczba UR korzystających z CSWI, integrujących się z CSWI przy wykorzystaniu B2B: 40,

• Liczba UR korzystających z CSWI, integrujących się z CSWI przy wykorzystaniu B2C: 450,

• Liczba Punktów Poboru Energii obsługiwanych przez CSWI: 20 000 000,

• Liczba użytkowników – administratorów technicznych CSWI: 7.

9 DOBRE PRAKTYKI I STANDARDY

9.1 OWASP Top 10 – 2013

System CSWI i Usługa IaaS oraz inne komponenty/usługi będące przedmiotem niniejszej Umowy muszą zostać zaprojektowane i dostarczone z uwzględnieniem wytycznych wynikających z OWASP Top 10 – 2013 xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/Xxxxxxxx:XXXXX_Xxx_Xxx_Xxxxxxx#xxx =OWASP_Top_ 10_for_2013).

9.2 OWASP Testing Project

W ramach testów bezpieczeństwa będą wykorzystywane w szczególności wytyczne wynikające z OWASP Testing Project (xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/Xxxxxxxx:XXXXX_Xxxxxxx_Xxxxxxx) w aktualnej wersji.

10 LICENCJONOWANIE I PRAWA AUTORSKIE

W niniejszym rozdziale przedstawiono wymagania Zamawiającego dotyczące udzielenia licencji i przeniesienia autorskich praw majątkowych na CSWI.

10.1 Wymagania dotyczące licencji (COTS)

10.1.1 Licencje na oprogramowanie.

W ramach Wynagrodzenia, Wykonawca zobowiązuje się do zapewnienia Zamawiającym licencji do korzystania z Oprogramowania COTS oraz Dokumentacji Oprogramowania COTS, poprzez udzielenie licencji przez Wykonawcę lub doprowadzenie do zawarcia umowy licencyjnej bezpośrednio między Zamawiającym a podmiotem uprawnionym do udzielania licencji na Oprogramowanie COTS.

10.1.2 Termin.

Zapewnienie uprawnień do korzystania z Oprogramowania COTS oraz Dokumentacji Oprogramowania COTS musi nastąpić nie później niż z chwilą przekazania Zamawiającemu rezultatu prac wykonawcy, który obejmuje Oprogramowanie COTS lub Dokumentację Oprogramowania COTS (np. środowiska Systemu CSWI, komponentu Systemu CSWI).

10.1.3 Zakres uprawnień.

Wykonawca zapewni, że zakres uprawnień przyznanych Zamawiającym do korzystania z Oprogramowania COTS oraz Dokumentacji Oprogramowania COTS będzie spełniać następujące wymagania:

10.1.3.1 licencja (w tym postanowienia umowy licencyjnej) musi, w ramach Wynagrodzenia, zapewniać Zamawiającym uprawnienia do korzystania z Systemu CSWI zgodnie z jego funkcjonalnością, przeznaczeniem oraz zamierzonym zakresem korzystania z niego wynikającym z Umowy, OPZ i Projektu Technicznego. Warunki licencyjne nie mogą zobowiązywać Zamawiającego do zapłaty kar umownych, podatków, ceł ani podobnych opłat administracyjnych,

10.1.3.2 uprawnienia do korzystania z Systemu CSWI muszą zostać zapewnione wszystkim Zamawiającym, w szczególności zapewnienie uprawnień może polegać na doprowadzeniu do zawarcia przez podmiot uprawniony z tytułu majątkowych praw autorskich umowy licencyjnej przyznającej każdemu z każdym Zamawiających z osobna uprawnienia licencyjne na tych samych warunkach lub na zawarciu jednej umowy licencyjnej z wszystkimi Zamawiającymi. W każdym wypadku Zamawiający musi uzyskać licencję bezpośrednio od podmiotu uprawnionego (nie jest dopuszczalne udzielenie licencji jednemu z Zamawiających, który miałby następnie udzielać sublicencji pozostałym Zamawiającym),

10.1.3.3 licencje nie mogą ograniczać liczby użytkowników korzystających z Systemu CSWI (w szczególności liczby Uczestników Rynku podłączonych do Systemu CSWI, liczby użytkowników uprawnionych do korzystania z Portalu CSWI), ani zawierać ograniczeń w zakresie wolumenu danych przetwarzanych przez System CSWI (w tym liczby komunikatów obsługiwanych przez System CSWI, obsługiwanych procesów wymiany komunikatów), czy też liczby kopii Dokumentacji. Określony w OPZ przewidywany przez Zamawiających wymiar korzystania z Systemu CSWI (np. co do liczby UR, liczby użytkowników, liczby transakcji) ma charakter szacunkowy,

10.1.3.4 licencja musi uprawniać do uruchomienia i korzystania z Systemu CSWI na platformie sprzętowo-systemowej w modelu chmury prywatnej, publicznej lub hybrydowej, w tym w ramach Infrastruktury wykorzystywanej na podstawie Usług IaaS, także w przypadku świadczenia Usług IaaS przez podmiot inny niż Wykonawca. W szczególności:

(a) licencja nie może zawierać ograniczeń powodujących, że korzystanie z Systemu CSWI będzie dopuszczalne jedynie na konkretnych urządzeniach (zakazane są tzw. licencje przypisane do sprzętu),

(b) zmiana podmiotu świadczącego Usługę IaaS albo migracja Systemu CSWI na Infrastrukturę wykorzystywaną na innej podstawie (np. na Infrastrukturę jednego z Zamawiających) nie może powodować dodatkowych kosztów po stronie Zamawiających,

10.1.3.5 licencja musi umożliwiać upoważnienie podmiotów innych niż Wykonawca do

zapewnienia obsługi technicznej Systemu CSWI, w tym poprzez zlecenie im czynności serwisowych lub administracyjnych, z zastrzeżeniem, że taka obsługa będzie miała na celu obsługę procesów Zamawiających i Uczestników Rynku (ang. outsourcing),

10.1.3.6 w odniesieniu do następujących podmiotów:

(a) spółki z grupy kapitałowej (w rozumieniu przepisów o rachunkowości), której członkiem jest dany Zamawiający, działające na terenie Polski,

(b) podmioty który będą pełniły rolę Operatora Informacji Pomiarowych oraz spółki z ich grup kapitałowych (w rozumieniu przepisów o rachunkowości),

(c) Operator Systemu Przesyłowego oraz spółki z jego grupy kapitałowej (w rozumieniu przepisów o rachunkowości),

(d) podmioty określone w Instrukcjach Ruchu i Eksploatacji Sieci

Dystrybucyjnej tj.:

− OSD (w tym OSDn),

− wytwórcy przyłączeni do sieci dystrybucyjnej OSDp,

− odbiorcy przyłączeni do sieci dystrybucyjnej OSDp,

− przedsiębiorstwa obrotu,

− Sprzedawcy,

− podmioty ubiegające się o przyłączenie (przyłączanie) do sieci dystrybucyjnej OSDp,

10.1.3.7 Wykonawca zapewni możliwość korzystania z Systemu CSWI w zakresie wyznaczonym jego funkcjonalnością, postanowieniami OPZ oraz Projektu Technicznego (w szczególności podmioty te muszą być uprawnione do korzystania z Systemu CSWI jako podłączeni do niego Uczestnicy Rynku oraz jako użytkownicy Portalu CSWI). O ile w celu zapewnienia powyższym podmiotom uprawnień w wymaganym zakresie będzie wymagać udzielenia licencji, może ono polegać w szczególności na udzieleniu im licencji bezpośrednio przez podmiot uprawniony z tytułu majątkowych praw autorskich lub zezwoleniu Zamawiającym na udzielanie sublicencji,

10.1.3.8 licencje muszą być przenoszalne pomiędzy następującymi podmiotami:

• Zamawiający,

• spółki z grupy kapitałowej, której członkiem jest dany Zamawiający (w rozumieniu przepisów o rachunkowości),

• podmioty które zgodnie z przepisami prawa będą pełniły rolę Operatora Informacji Pomiarowych oraz spółki z ich grup kapitałowych (w rozumieniu przepisów o rachunkowości),

• Operator Systemu Przesyłowego oraz spółki z jego grupy kapitałowej (w rozumieniu przepisów o rachunkowości).

Przeniesienie może wiązać się z obowiązkiem uprzedniego poinformowania licencjodawcy o jego dokonywaniu.

10.1.3.9 licencja musi umożliwiać rozwijanie Systemu CSWI, tj. np. poprzez przyłączanie nowych Uczestników Rynku do procesów komunikacji realizowanej przy wsparciu Systemu CSWI, integrowanie z zewnętrznymi bazami danych (możliwość rozwoju Systemu CSWI w kierunku modelu szyny wymiany danych z centralną bazą danych), dodawanie nowych funkcjonalności poszczególnych komponentów (przy wykorzystaniu funkcjonalności Oprogramowania COTS oraz przez modyfikację Oprogramowania Dedykowanego),

10.1.3.10 czas trwania licencji nie może być ograniczony,

10.1.3.11 Wykonawca zobowiązuje się, że przez okres 20 lat od udzielenia licencji, podmiot udzielający licencji nie utraci praw niezbędnych do zapewnienia Zamawiającym możliwości korzystania z Systemu CSWI (ewentualnie w razie utraty tych praw zapewni że jego następca prawny lub podmiot, któremu przysługiwać będą autorskie prawa majątkowe będzie honorował licencje udzielone w związku z Umową), nie podejmie jakichkolwiek działań faktycznych zmierzających do pozbawienia Zamawiających uprawnień ani nie wypowie licencji z innych powodów niż istotne naruszenie przez Zamawiającego warunków licencji. Gdyby takie zdarzenie miało miejsce – Wykonawca w ramach dotychczasowego wynagrodzenia dostarczy i wdroży zamienne Oprogramowanie przed upływem okresu wypowiedzenia, W razie naruszenia tego zobowiązania, Zamawiający mogą żądać od Wykonawcy kary umownej w wysokości [10]% Wynagrodzenia za każdy taki przypadek, a ponadto do odstąpienia od Umowy. Prawo odstąpienia może zostać wykonane w terminie do DD-MM-RRRR (data do uzupełnienia przed podpisaniem Umowy).

10.1.3.12 terytorium korzystania z utworów nie może być mniejsze niż terytorium Polski (co nie wyklucza korzystania z funkcjonalności Systemu CSWI udostępnianych zdalnie, takich jak Portal CSWI, przez użytkowników znajdujących się poza Polską),

10.1.3.13 W przypadku jakichkolwiek sprzeczności, postanowienia niniejszego rozdziału mają znaczenie nadrzędne nad odpowiednimi zapisami umowy/ów licencyjnych stanowiących załącznik do Umowy.

10.1.4 Open Source

Zastosowanie licencji Open Source dopuszczalne jest w odniesieniu do Oprogramowania COTS tworzącego poniższe komponenty Systemu CSWI:

10.1.4.1 Monitoring Systemu CSWI,

10.1.4.2 Symulator UR CSWI,

10.1.4.3 SZT CSWI,

10.1.4.4 Aplikacja Serwisowa,

10.1.4.5 Repozytorium Dokumentacji,

10.1.4.6 Repozytorium Kodu,

10.1.4.7 System operacyjny,

10.1.4.8 Serwer aplikacyjny i WWW.

Zastosowanie licencji Open Source nie zwalnia Wykonawcy z pozostałych zobowiązań dotyczących Oprogramowania COTS.

10.2 Wymagania dotyczące praw autorskich

10.2.1 Elementy autorskie

W ramach Wynagrodzenia, Wykonawca przenosi (sprzedaż) na Zamawiających majątkowe prawa autorskie do Elementów Autorskich (poza Oprogramowaniem COTS oraz jego Dokumentacją), bez ograniczeń terytorialnych, na wszystkich znanych polach eksploatacji, w tym polach obejmujących:

10.2.1.1 w zakresie oprogramowania komputerowego (w tym Oprogramowania Dedykowanego):

(a) trwałe lub czasowe zwielokrotnienie programu komputerowego w całości lub w części jakimikolwiek środkami i w jakiejkolwiek formie,

(b) tłumaczenie, przystosowywanie, zmiany układu lub jakiekolwiek inne zmiany w programie komputerowym,

(c) rozpowszechnianie, w tym użyczenie lub najem, programu komputerowego lub jego kopii,

10.2.1.2 w zakresie Dokumentacji (w szczególności Projektu Funkcjonalnego,

Projektu Technicznego oraz innych dokumentów przygotowywanych przez Wykonawcę) i innych utworów niebędących programami komputerowymi, nawet jeśli wchodzą w ich skład (np. grafika, multimedia):

(a) w zakresie utrwalania i zwielokrotniania utworu - wytwarzanie dowolną techniką egzemplarzy utworu, w tym techniką drukarską, reprograficzną, zapisu magnetycznego oraz techniką cyfrową,

(b) w zakresie obrotu oryginałem albo egzemplarzami, na których utwór utrwalono - wprowadzanie do obrotu, użyczenie lub najem oryginału albo egzemplarzy,

(c) w zakresie rozpowszechniania utworu w sposób inny niż określony w punkcie poprzedzającym – publiczne wykonanie, wystawienie, wyświetlenie, odtworzenie oraz nadawanie i reemitowanie, a także publiczne udostępnianie utworu w taki sposób, aby każdy mógł mieć do niego dostęp w miejscu i w czasie przez siebie wybranym.

10.2.1.3 prawo do zezwalania na wykonywanie zależnych praw autorskich do tych

utworów na wszystkich polach eksploatacji opisanych powyżej.

10.2.2 Chwila przejścia praw

Przejście na Zamawiających majątkowych praw autorskich oraz odpowiednich praw do zezwalania na wykonywanie zależnych praw autorskich następuje z chwilą dokonania odbioru świadczenia, którego elementem jest dany utwór. Dla uniknięcia wątpliwości Strony potwierdzają, że do chwili przyjęcia utworu Zamawiający mają prawo korzystania z takiego utworu w związku z realizacją umowy, w tym prowadzenia testów i dokonania odbioru.

10.2.3 Brak obciążeń

Wykonawca zapewnia, że zbywane na rzecz Zamawiających prawa nie będą w chwili zbycia obciążone prawami osób trzecich, w szczególności, że Wykonawca nie zobowiązał się do przeniesienia tych praw w całości lub części na osobę trzecią ani nie udzielił licencji.

11 DODATKOWE POSTANOWIENIA UMOWNE

11.1 Aktualizacje Systemu CSWI

11.2 Zakres

W przypadku, jeżeli w trakcie gwarancji w stosunku do Oprogramowania COTS zostaną opublikowane jakiekolwiek Aktualizacje, Wykonawca dostarczy je Zamawiającym.

11.3 Brak obowiązku instalacji

Dostarczenie Aktualizacji nie oznacza dla Zamawiających obowiązku jej instalacji. Dostarczenie Aktualizacji nie może mieć żadnych negatywnych konsekwencji dla Zamawiających, w szczególności nie wpływa to w żaden sposób na zobowiązania w zakresie pozostałych uprawnień wynikających z gwarancji.

11.4 Instalacja

Aktualizacje będą wprowadzane do Systemu CSWI zgodnie z „Zasadami zarządzania Systemem CSWI” (dokument opracowany w ramach Zadania I.3). Jeżeli w „Zasadach zarządzania Systemem CSWI” nie postanowiono inaczej, przyjmuje się, że:

1. Wykonawca dostarczy lub udostępni Aktualizację niezwłocznie, jednak nie później niż w terminie 5 Dni Roboczych po jej publikacji. Wprowadzenie Aktualizacji do Systemu CSWI wymaga uzgodnienia z Koordynatorem Zamawiających.

2. Obowiązki Wykonawcy obejmują w szczególności:

a) przygotowanie dokumentacji analitycznej,

b) instalację i konfigurację Aktualizacji,

c) dostosowanie Oprogramowania Dedykowanego do Aktualizacji, instalację i konfigurację dostosowanego Oprogramowania Dedykowanego,

d) przeprowadzenie testów,

e) przeprowadzenie uruchomienia produkcyjnego Systemu CSWI po Aktualizacji,

f) aktualizację Dokumentacji w zakresie, w jakim Aktualizacja ma na nią wpływ.

11.5 Gwarancja

System CSWI z Aktualizacją jest objęty gwarancją.

11.6 USŁUGA ADMINISTRACJI

11.7 Zakres i czas trwania

W ramach Wynagrodzenia za Usługę Administracji, Wykonawca zobowiązuje się przez okres 48 miesięcy od Uruchomienia Produkcyjnego świadczyć Usługę Administracji obejmującą:

1. monitorowanie za pomocą narzędzi informatycznych zgodnych z Umową oraz OPZ poprawności działania, wydajności oraz bezpieczeństwa Systemu CSWI w trybie ciągłym (przez całą dobę przez wszystkie dni w roku) w celu niezwłocznego podejmowania działań naprawczych oraz informowania Zamawiających o wykrytych w czasie monitorowania Awariach i innych nieprawidłowościach,

2. wykonywanie oraz odtwarzanie kopii zapasowych w celu zagwarantowania wymaganego RPO oraz RTO (zgodnie z procedurami przyjętymi w Projekcie Technicznym, chyba że Koordynatorzy ustalą inne zasady),

3. prowadzenie bieżących prac konserwacyjnych Systemu CSWI (np. parametryzacja Systemu CSWI) w celu zagwarantowania poprawności działania, wydajności oraz bezpieczeństwa,

4. przeprowadzania szkoleń z aspektów technicznych i biznesowych CSWI w zakresie nieprzekraczającym 80 godzin szkoleniowych w roku kalendarzowym,

5. zarządzaniem dostępem do Systemu CSWI (w szczególności przyłączanie i odłączanie Uczestników Rynku i innych podmiotów uprawnionych do korzystania z Systemu CSWI),

6. udział w testach i audytach Systemu CSWI realizowanych przez Zamawiających lub na ich zlecenie,

7. realizacja okresowych testów Systemu CSWI dotyczących w szczególności: wysokiej dostępności, bezpieczeństwa CSWI, co najmniej raz na 6 miesięcy,

8. zarządzanie Aplikacją Serwisową oraz jej wykorzystanie w postaci pojedynczego punktu kontaktu do realizacji pierwszej linii wsparcia i drugiej linii wsparcia Systemu CSWI,

9. aktualizacja Dokumentacji CSWI.

11.8 RTO

Wykonawca zapewni, że czas odtworzenia Systemu CSWI po katastrofie (RTO) nie przekroczy:

1. dla środowiska produkcyjnego: 4 godzin,

2. dla środowiska testowego i rozwojowego (odtworzenie na tej samej infrastrukturze z kopii zapasowej po usunięciu awarii tej infrastruktury): 48 godzin.

11.9 RPO

Wykonawca zapewni, że okres przed katastrofą, z którego dane mogą nie zostać odtworzone (RPO), nie przekroczy:

1. dla środowiska produkcyjnego: 1 godziny,

2. dla pozostałych środowisk: 48 godzin.

11.10 Zakres

Wykonawca jest zobowiązany do przekazywania Koordynatorowi Zamawiających raportów ze świadczenia Usługi Administracji. Raporty będą obejmowały raporty dzienne, tygodniowe i miesięczne, chyba że Koordynatorzy ustalą inaczej.

11.11 Treść

Każdy raport powinien wskazywać przynajmniej:

1. zdarzenia oraz nieprawidłowości w pracy Systemu CSWI, w tym incydenty bezpieczeństwa, wykryte przez Wykonawcę oraz opis podjętych działań naprawczych i ich rezultatów,

2. wyniki analiz działania Systemu CSWI (np. analizy trendów w zużyciu zasobów),

3. opis zrealizowanych prac w tym w zakresie dostępu do Systemu CSWI,

4. raporty z przeprowadzonych testów.

11.12 Weryfikacja

Strony przewidują następującą procedurę weryfikacji raportów miesięcznych:

1. Koordynator Zamawiających, w terminie 5 Dni Roboczych od dnia otrzymania raportu miesięcznego, dokona jego weryfikacji.

2. W przypadku braku akceptacji raportu miesięcznego Koordynator Zamawiających powiadomi o tym Wykonawcę. Wykonawca będzie miał obowiązek ustosunkować się do uwag i przedstawić wyjaśnienia potwierdzające swoje stanowisko w terminie 3 Dni Roboczych od otrzymania tych uwag.

3. Po otrzymaniu wyjaśnień Wykonawcy, Koordynator Zamawiających w terminie 3 Dni Roboczych podejmie decyzję w przedmiocie ich uwzględnienia. W przypadku niezaakceptowania przez Zamawiających wyjaśnień w całości lub w części, Koordynatorzy przekażą sprawę do rozstrzygnięcia Komitetowi Sterującemu.

12 ZAŁĄCZNIKI

12.1 Załącznik nr [1] Wymagania Funkcjonalne i Niefunkcjonalne