załącznik nr 2 do regulaminu dialogu technicznego (pdf)

Załącznik nr 2

do Regulaminu prowadzenia dialogu

technicznego (CSWI/DT/2015)

Informacje dotyczące planowanego postępowania

13 lipca 2015 r.

1

1 Spis tre ści

1 Spis treści 1

2 Wprowadzenie 3

3 Słownik pojęć 5

4 Ogólny Opis Przedmiotu Zamówienia 9

4.1 Kontekst biznesowy przedsięwzięcia 9

4.2 Kluczowe wymagania 9

4.3 Zakres zamówienia 10

5 Opis koncepcji architektury logicznej CSWI 11

5.1 Komunikacja 11

5.2 Zarządzanie metadanymi i cyklem życia 12

5.3 Adaptery 12

5.4 Administracja i zarządzanie 12

5.5 Mediacja 12

5.6 Monitorowanie 12

5.7 Integracja danych (ETL) 13

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

5.9 Transformacje złożone 13

5.10 BPM i orkiestracja 13

5.11 Raportowanie 13

5.12 Obsługa błędów oraz zgłoszeń od Użytkowników CSWI 14

5.13 Portal 14

5.14 Archiwum komunikatów 14

5.15 Repozytorium Modelu 14

5.16 Logowanie i audytowanie 15

5.17 Symulator UR CSWI (mockup) 15

6 Koncepcja integracji CSWI 16

6.1 Korzystanie z CSWI poprzez wymianę komunikatów (B2B) 16

6.2 Korzystanie z CSWI poprzez Portal (B2C) 16

7 Harmonogram i produkty 17

7.1 Wprowadzenie 17

7.2 Etapy wdrożenia 17

8 Migracja danych i inicjalna konfiguracja CSWI 27

9 Testy 28

9.1 Testy funkcjonalne 28

9.2 Testy bezpieczeństwa 29

9.3 Testy przełączenia na ośrodek zapasowy 29

9.4 Testy wydajnościowe 29

9.5 Testy przeciążeniowe 29

9.6 Testy wysokiej dostępności 29

10 Licencjonowanie i prawa autorskie 30

10.1 Wymagania dotyczące licencji (COTS) 30

2

10.2 Wymagania dotyczące praw autorskich 30

10.3 Wymagania wolumetryczne 31

11 Gwarancja 32

12 Usługi utrzymania i rozwoju 33

12.1 Utrzymanie CSWI 33

12.2 Rozwój CSWI 33

3

2 Wprowadzenie

Niniejszy dokument obejmuje swoim zakresem wyniki prac przeprowadzonych w celu opracowania wsadu merytorycznego do Zapytania Ofertowego (RFP) dla rozwiązania informatycznego odpowiadającego za pośredniczenie w komunikacji pomiędzy UR, zgodnej z opracowanym biznesowym modelem wymiany informacji, odpowiedzialnego za zapewnienie jakości i poprawności wymienianych komunikatów oraz skuteczne dostarczenie, monitorowanie i zarządzanie wymienianymi komunikatami do podmiotów uczestniczących w komunikacji – CSWI (Centralny System Wymiany Informacji). Dokument składa się z następujących części:

− Rozdział 2 – Wprowadzenie

w którym przedstawiono kontekst zrealizowanych prac oraz zawartość dokumentu;

− Rozdział 3 – Słownik poj ęć

w którym przedstawiono definicje kluczowych pojęć stosowanych w dokumencie;

− Rozdział 4 – Ogólny Opis Przedmiotu Zamówienia

w którym przedstawiono opis kontekstu biznesowego przedsięwzięcia, kluczowe założenia dotyczące przedmiotu zamówienia oraz zakres zamówienia;

− Rozdział 5 – Opis koncepcji architektury logicznej CSWI

w którym przedstawiono koncepcję architektury logicznej CSWI – systemu informatycznego odpowiadającego za pośredniczenie w komunikacji pomiędzy uczestnikami detalicznego rynku energii elektrycznej w Polsce;

− Rozdział 6 – Koncepcja integracji CSWI

w którym przedstawiono koncepcję integracji CSWI z podmiotami uczestniczącymi w komunikacji na detalicznym rynku energii w Polsce;

− Rozdział 7 – Harmonogram i produkty

w którym przedstawiono założenia Zamawiającego odnośnie ramowego harmonogramu realizacji przedmiotu zamówienia;

− Rozdział 8 – Migracja danych i inicjalna konfigurac ja CSWI

w którym przedstawiono założenia Zamawiającego dotyczące migracji danych i inicjalnej konfiguracji;

− Rozdział 9 – Testy

w którym przedstawiono założenia Zamawiającego dotyczące organizacji procesu testowego;

4

− Rozdział 10 – Licencjonowanie i prawa autorskie

w którym przedstawiono wymagania Zamawiającego dotyczące udzielenia licencji i przeniesienia praw autorskich na CSWI;

− Rozdział 11 – Gwarancja

w którym przedstawiono wymagania Zamawiającego dotyczące gwarancji;

− Rozdział 12 – Usługi utrzymania i rozwoju

w którym przedstawiono wymagania Zamawiającego dotyczące utrzymania i rozwoju;

5

3 Słownik poj ęć

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

B2C – ang. Business-to-Customer, model relacji pomiędzy przedsiębiorstwem a klientem końcowym, w którym inicjatorem relacji jest przedsiębiorstwo. Tutaj: model korzystania z usług CSWI poprzez dedykowany portal WWW

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

COTS – ang. Commercial off-the-shelf oprogramowanie ogólnodostępne, dostarczane w formie gotowego, zamkniętego produktu wytworzonego dla klientów w identycznej postaci jednoznacznie określane przez nazwę producenta, nazwę handlową oraz numer wersji.

CSWI – Centralny System Wymiany Informacji, kompleksowe rozwiązanie informatyczne odpowiadające za pośredniczenie w komunikacji pomiędzy UR energii elektrycznej w Polsce

CSV – ang. Comma Separated Values, format przechowywania danych w plikach tekstowych, gdzie wartości rozdzielone są przecinkami

DMZ – ang. Demilitarized zone, strefa zdemilitaryzowana, obszar sieci komputerowej nienależący ani do sieci wewnętrznej ani do zewnętrznej.

Dokumentacja Administracyjna – dokumentacja obejmująca co najmniej następujące obszary: Instalacja, Konfiguracja, Administracja, Uruchamianie systemu, Zatrzymywanie systemu, Restartowanie systemu, Aktualizacja systemu, Konta i uprawnienia, Kopia zapasowa, Przywracanie po awarii systemu, Przełączanie do środowiska zapasowego, Archiwizacja, Monitoring, Obsługa błędów, Sposób zgłaszania błędów do wsparcia/dostawcy

Dokumentacja COTS – dokumentacja powiązana z oprogramowaniem COTS i udostępniana przez jego producenta.

Dokumentacja CSWI – całość dokumentacji jaka została dostarczona (Dokumentacja COTS) lub stworzona (Dokumentacja Dedykowana) w trakcie budowy, wdrożenia i okresu gwarancji CSWI.

Dokumentacja Dedykowana – dokumentacja, która została specjalnie stworzona w celu realizacji wymagań konkretnego klienta (Zamawiającego).

ebIX – ang. European forum for energy Business Information eXchange, europejska organizacja zajmująca się rozwijaniem i standaryzacją wykorzystania elektronicznej wymiany informacji na europejskim rynku energii elektrycznej

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.

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)

6

Incydent Krytyczny – incydent uniemożliwiający działanie CSWI lub jego poszczególnych funkcjonalności, powodujący brak realizacji części lub całości procesów wspieranych przez CSWI.

Incydent o Wysokim Priorytecie – incydent ograniczający wydajność działania lub funkcjonalność CSWI, ale nie powodujący braku realizacji procesów wspieranych przez CSWI.

Incydent o Niskim Priorytecie – incydent nie będący Incydentem Krytycznym lub Incydentem o Wysokim Priorytecie.

Infrastruktura jako Usługa – ang. Infrastructure-as-a-Service, IaaS, usługa polegająca na dostarczeniu przez Wykonawcę całości wymaganej infrastruktury technicznej na potrzeby funkcjonowania CSWI w postaci usługi zewnętrznej ze współdzielonego zbioru zasobów

JMS – ang. Java Message Service, zestaw interfejsów i modeli asynchronicznego przesyłania komunikatów w języku JavaJNDI – ang. Java Naming and Directory Interface, interfejs języka Java pozwalający na odkrywanie i wyszukiwanie danych oraz obiektów za pomocą nazw

Koncepcja Modelu Wymiany Informacji – dokument „Koncepcja Modelu Wymiany Informacji pomiędzy uczestnikami detalicznego rynku energii elektrycznej w Polsce (oparta o Standard ebIX)”

KPI – ang. Key Performance Indicators, Kluczowe wskaźniki efektywności, wskaźniki stosowane jako mierniki realizacji procesów wspieranych przez CSWI

MD – ang. Man-Day,roboczodzień.

NOSPF – ang. No Single Point of Failure, architektura zaprojektowana w 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 Dedykowane – komponent oprogramowania, który został specjalnie stworzony w celu realizacji wymagań konkretnego klienta (nie COTS).

OSD – Operator Systemu Dystrybucyjnego (elektroenergetycznego)

Personel Wykonawcy – osoby fizyczne zatrudnione przez Wykonawcę lub jego podwykonawców na dowolnej podstawie prawnej (np. pracownicy Wykonawcy oraz osoby fizyczne prowadzące indywidualną działalność gospodarczą zatrudnione przez Wykonawcę lub jego podwykonawców na podstawie umowy cywilnoprawnej), oddelegowane przez Wykonawcę do czynności związanych z realizacją przedmiotu zamówienia

POB – Podmiot Odpowiedzialny za Bilansowanie handlowe

Profil UR CSWI – Konfiguracja CSWI definiująca elementy związane z Uczestnikiem Rynku (np. zakres uprawnień, zakres udostępnianych usług, konta UR)

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. Rozwiązanie Zast ępcze – ang. workaround, obejście rozpoznanego problemu (np. w oprogramowaniu) stosowane do momentu jego usunięcia.

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 momentu działalności będzie można powrócić.

RTO – ang. Recovery Time Objective, maksymalny czas po awarii potrzeby do przywrócenia działania systemu

SE – Sprzedawca Energii Elektrycznej

SIEM – ang. Security Information and Event Management, klasa systemów informatycznych służących do zarządzania informacjami i zdarzeniami bezpieczeństwa informatycznego

SIWZ – Specyfikacja Istotnych Warunków Zamówienia

7

SLA – ang. Service Level Agreement, umowa o gwarantowanym poziomie świadczenia usług

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

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

SVN – ang. Subversion, system kontroli wersji

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/CEFACT – organizacja zajmująca się opracowaniem standardów elektronicznej wymiany dokumentów (EDI) opartych o standard XML.

UR – Uczestnik Rynku – podmiot funkcjonujący na detalicznym rynku energii elektrycznej w Polsce, uczestniczący w komunikacji przy wykorzystaniu CSWI: OSD, POB, SE

Strony – Zamawiający i Wykonawca łącznie

Użytkownik CSWI – Uczestnik Rynku korzystający z CSWI oraz pozostałe osoby i podmioty korzystające z wybranego obszaru funkcjonalnego CSWI

WSDL – ang. Web Services Description Language, język oparty na XML przeznaczony do opisu usług sieciowych

Wykonawca – osoba fizyczna, osoba prawna lub jednostka organizacyjna nieposiadająca osobowości prawnej, która ubiega się o udzielenie zmówienia, złożyła ofertę lub zawarła umowę w sprawie zamówienia

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.

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. nr kroku testowego b. opis czynności do wykonania c. 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)

8

d. użytkownik wykonujący (rola, funkcja) e. oczekiwany rezultat f. uwagi

Raport Testów Wewn ętrznych – Raport z wykonanych przez Wykonawcę testów opisujący:

1. Przebieg procesu testowania zgodnie z przyjętym dokumentem „Plan testów”. 2. Imiona i nazwiska osób wykonujących testy przyporządkowane do poszczególnych

czynności/kroków testowych. 3. Podpisy osób wykonujących testy. 4. Wypełnione pole uwagi, w przypadku braku uwag 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.

Raport z Wdro żenia Produkcyjnego – Dokument opisuje wykryte błędy, 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. W dokumencie znajdują się zalecenia i wnioski w zakresie usprawnień funkcjonalnych i technicznych oraz plan dalszych działań związany z usunięciem błędów i usterek oraz wdrożeniem usprawnień w produkcyjnej wersji Systemu. Dokument zawiera m.in. 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 backupu 2.4. Testy administracyjne

3. Zalecenia i wnioski w zakresie usprawnień 4. Lista załączników, tabel i rysunków

UAT – User Acceptance Test – testy akceptacyjne.

Umowa – umowa, której przedmiotem jest budowa i wdrożenie CSWI.

Zamawiaj ący – organizator niniejszego postępowania, pięciu OSD.

9

4 Ogólny Opis Przedmiotu Zamówienia

4.1 Kontekst biznesowy przedsięwzięcia

Pięciu operatorów systemów dystrybucyjnych realizuje 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. Polskie Towarzystwo Przesyłu i Rozdziału Energii Elektrycznej jako pełnomocnik pięciu OSD przeprowadza Dialog Techniczny.

Wdrożenie niniejszego modelu wymaga implementacji dedykowanego rozwiązania informatycznego odpowiadającego za wymianę informacji pomiędzy UR, zgodnie z opracowaną „Koncepcją Modelu Wymiany Informacji pomiędzy uczestnikami detalicznego rynku energii elektrycznej w Polsce (oparta o standard ebIX)” (dalej „Koncepcja Modelu Wymiany Informacji”) oraz Standardami Wymiany Informacji. System informatyczny zapewni jakości i poprawności wymienianych komunikatów oraz skuteczne dostarczenie, monitorowanie i zarządzanie wymienianymi komunikatami.

W związku z powyższym Zamawiający oczekuje przedstawienia oferty na dostarczenie, wdrożenie i uruchomienie kompleksowego rozwiązania informatycznego – Centralnego Systemu Wymiany Informacji.

4.2 Kluczowe wymagania

Poniżej przedstawiono kluczowe wymagania Zamawiającego w stosunku do CSWI.

a) Zakłada się, że CSWI powinien charakteryzować się co najmniej:

− Komunikacją z wykorzystaniem Web Services,

− Funkcjonalnościami w zakresie monitoringu komunikatów oraz poszczególnych usług, logowania informacji o przetworzonych komunikatach, archiwizacji komunikatów, powiadomień o błędach komunikacji, definiowania KPI, czasów przetwarzania technicznego i biznesowego,

− Zapewnieniem wysokiej dostępności systemu z możliwością monitorowania parametrów jakości pracy systemu oraz zautomatyzowanego dynamicznego rozkładania ruchu,

− Możliwością złożonego przetwarzania, transformacji i walidacji komunikatów

− Zapewnieniem możliwości zarządzania 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.

− Zapewnieniem bezpieczeństwa w zakresie interakcji użytkownik – Portal CSWI oraz w komunikacji B2B: aplikacja – aplikacja (autentykacja, szyfrowanie, certyfikaty)

− Zarządzaniem cyklem życia i wersjami usług

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

− Wykorzystaniem 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żeniem w oparciu o model Infrastruktura jako usługa

b) Zamawiający wymaga, aby wdrożony CSWI wspierał realizację procesów biznesowych, zdefiniowanych szczegółowo w Koncepcji Modelu Wymiany Informacji.

c) Zamawiający wymaga, aby powyższe procesy biznesowe zostały zaimplementowane w CSWI w ramach dedykowanego komponentu BPM (patrz: Rozdział dotyczący koncepcji architektury logicznej CSWI),

d) Zamawiający wymaga, aby w ramach dedykowanego komponentu Raportowanie (patrz: Rozdział dotyczący koncepcji architektury logicznej CSWI) Wykonawca dostarczył inicjalny zestaw predefiniowanych raportów dotyczących biznesowych oraz technicznych aspektów działania CSWI.

e) Zamawiający nie dopuszcza możliwości wdrożenia CSWI w modelu Software-as-a-Service,

10

f) Zamawiający wymaga, aby wszystkie komponenty logiczne CSWI zostały dostarczone poprzez sparametryzowane gotowe komponenty (COTS), z ograniczoną koniecznością programowania w zakresie pozwalającym na spełnienie wymagań funkcjonalnych i pozafunkcjonalnych na CSWI,

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

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

i) Zamawiający zastrzega sobie prawo do przeprowadzenia audytu bezpieczeństwa i jakości na każdym etapie realizowanych prac, w tym np. analiza dokumentacji, testy penetracyjne, analiza jakości kodu wytworzonego oprogramowania. Zamawiający przeprowadzi maksymalnie jeden audyt w każdym etapie (z możliwością powtarzania go w przypadku wykrycia nieprawidłowości w weryfikowanych produktach).

4.3 Zakres zamówienia

Przedmiotem zamówienia jest dostarczenie, wdrożenie i uruchomienie kompleksowego rozwiązania informatycznego CSWI wraz z gwarancją i usługami utrzymania i rozwoju w okresie 4 lat od zakończenia wdrożenia, w sposób umożliwiający przeniesienie po tym okresie systemu do centrum przetwarzania danych Zamawiającego.

Zamawiający zastrzega sobie prawo do zmiany (m. in. parametrów, dostawcy) usługi IaaS dla CSWI w dowolnym momencie trwania umowy.

Zadania i produkty zamówienia zostały opisane w Rozdziale 7 niniejszego dokumentu.

Zamawiający wymaga, aby wraz z rozwiązaniem informatycznym, o którym mowa powyżej, Wykonawca dostarczył usługę udostępnienia infrastruktury techniczno-systemowej, niezbędnej do zapewnienia poprawnego funkcjonowania CSWI w postaci modelu „Infrastruktura jako usługa”. Poprzez infrastrukturę techniczno-systemową należy rozumieć:

− przestrzeń serwerową − serwery fizyczne − macierze dyskowe − systemy wirtualizacji − infrastrukturę sieciową − niezbędny pozostały sprzęt i oprogramowanie

Ponadto Zamawiający wymaga (w zakresie IaaS) dostarczenia następujących usług i niezbędnej dla nich infrastruktury techniczno-systemowej:

− wykonywanie, utrzymywanie i odtwarzanie kopii zapasowych CSWI (backup) − SIEM

11

5 Opis koncepcji architektury logicznej CSWI

W niniejszym rozdziale przedstawiono opis koncepcji architektury logicznej CSWI. Poniżej zamieszczono schemat przedstawiający koncepcję architektury logicznej CSWI (z perspektywy realizowanych obszarów funkcjonalnych). Następnie opisano każdy z komponentów w zakresie realizowanych przez nie funkcjonalności. Szczegółowa lista funkcjonalności CSWI została zamieszczona w Załączniku nr 1.

Rysunek 1 - Schemat komponentów logicznych CSWI

5.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.

Komponent pozwala na zarządzanie Profilami UR CSWI.

12

5.2 Zarządzanie metadanymi i cyklem życia

Komponent odpowiedzialny za obsługę Repozytorium Modelu, Repozytorium Kodu, Repozytorium Usług na potrzeby zarządzania metadanymi przechowywanymi w tych repozytoriach 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 m.in. 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 Rejestru Usług poprzez API oraz publikację informacji o usługach.

5.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.

5.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.

5.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 m.in. reguły czy zawartość komunikatów).

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

5.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.

Dodatkowo komponent oferuje funkcjonalności monitorowania aktywności biznesowej.

13

5.7 Integracja danych (ETL)

Komponent odpowiedzialny za realizację funkcjonalności w zakresie integracji danych poprzez wsparcie dla mechanizmów dostępu do źródeł danych, zarządzania dostępem do nich i przeprowadzania na nich operacji w oparciu o architekturę usługową.

Komponent umożliwia w szczególności definiowanie i uruchamianie usług ekstrakcji, modyfikacji i ładowania danych z dedykowanych źródeł (ang. data manipulation services), definiowanie i uruchamianie usług konsolidujących dostęp do danych wielu różnych źródeł, buforowanie danych pozyskanych ze źródeł oraz zarządzanie połączeniami ze źródłami.

5.8 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/FT i mechanizmy failover.

5.9 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, w oparciu o m.in. wbudowane funkcje konwersji (takie jak np. suma, średnia, konkatenacja) oraz zdefiniowane reguły konwersji.

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 w oparciu o definicje XSD.

Komponent obsługuje wiele stron kodowych.

5.10 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 obecnie realizowanymi procesami, edycję i prezentację procesów w repozytorium w środowisku graficznym, w oparciu o diagramy.

5.11 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.

14

Komponent pozwala na raportowanie na temat m.in. 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 (m.in. XLS, XML, PDF).

5.12 Obsługa błędów oraz zgłoszeń od Użytkowników CSWI

Komponent odpowiedzialny za rejestrację oraz zarządzanie wszelkiego rodzaju błędami oraz zgłoszeniami od Użytkowników CSWI (incydentami oraz standardowymi zleceniami), a także pozwalający na ich procesową obsługę.

5.13 Portal

Komponent odpowiedzialny za umożliwienie użytkownikom, wykorzystywanie 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.

5.14 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.

5.15 Repozytorium Modelu

Komponent odpowiedzialny za 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 przechowywaną w repozytorium dokumentację, wersjonowanie zdefiniowanych w repozytorium elementów, reużywanie obiektów i definiowanie powiązań między nimi.

Zamawiający wymaga, iż Wykonawca zbuduje opis standardu wymiany informacji w postaci kompletnego Repozytorium Modelu zawierającego zbiór artefaktów (diagramy procesów, diagramy komunikatów, diagramy przypadków użycia, model ról) oparty o Standard ebIX i publikowane repozytorium Standardu ebiX. Niniejszy komponent stanowi zakres architektury logicznej CSWI oraz prac po stronie Wykonawcy.

15

5.16 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 / bytach / rekordach, 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ślenie ciągu zdarzeń.

5.17 Symulator UR CSWI (mockup)

Komponent do wykonywania testów CSWI bez systemów UR.

Rolą komponentu jest:

1. Automatyczne symulowanie działania systemów UR, umożliwiające wykonanie testów ‘End-to-End’ CSWI bez konieczności angażowania UR.

2. Automatyczne symulowanie działania UR w sposób umożliwiający weryfikację spełnienia wymagań wydajnościowych CSWI (generacja ruchu zgodnie z wymaganiami wydajnościowymi).

16

6 Koncepcja integracji CSWI

W niniejszej sekcji przedstawiono założenia dotyczące sposobu korzystania z CSWI przez poszczególnych uczestników detalicznego rynku energii elektrycznej w Polsce.

Informacje dotyczące biznesowej koncepcji integracji Rozwiązania zostały opisane w dokumencie Koncepcja Modelu Wymiany Informacji w zakresie:

• Założeń informatycznych dotyczących CSWI, • Ról (UR) uczestniczących w prowadzeniu komunikacji i wymagających integracji z CSWI, • Przebiegu procesów komunikacji pomiędzy UR z uwzględnieniem wymienianych

komunikatów.

6.1 Korzystanie z CSWI poprzez wymianę komunikatów (B2B)

Korzystanie z CSWI poprzez wymianę komunikatów (B2B) będzie realizowane poprzez wykorzystanie usług udostępnianych przez CSWI dla systemów IT UR

Komunikacja z podmiotami powinna być realizowana poprzez funkcjonalności udostępniane przez komponent „Komunikacja” opisany w Rozdziale 5 niniejszego dokumentu.

6.2 Korzystanie z CSWI poprzez Portal (B2C)

Korzystanie z CSWI poprzez portal będzie realizowane poprzez wykorzystanie dedykowanego Portalu WWW pozwalającego na manuale publikowanie oraz pobieranie danych przez UR.

Komponent „Portal” opisany jest w Rozdziale 5 niniejszego dokumentu.

17

7 Harmonogram i produkty

7.1 Wprowadzenie

W niniejszym rozdziale przedstawiono ramowy harmonogram dostarczenia, wdrożenia i uruchomienia CSWI.

Harmonogram przedstawia wymaganie Zamawiającego w zakresie terminów realizacji poszczególnych etapów projektu, jak i projektu jako całości, oczekiwanych produktów prac w poszczególnych etapach projektu, a także podziału zadań i odpowiedzialności pomiędzy Zamawiającego i Wykonawcę w ramach realizacji projektu.

7.2 Etapy wdrożenia

7.2.1 Etap I – Analiza i projekt CSWI.

Czas trwania : 24 tygodnie od podpisania Umowy

7.2.1.1 Organizacja i ustalenie zasad zarządzania projektem

Czas trwania : 4 tygodnie od podpisania Umowy

Celem zadania jest opracowanie wszystkich produktów zw. z procesem zarządzenia projektem.

Zadania Wykonawcy

1. Przygotowanie planów dla zadań składających się na zarządzanie zespołem projektowym oraz inne aspekty z zakresu zarządzania projektem zgodnie z rozdziałem 13. „Wymagania dotyczące organizacji projektu”. Plany te dotyczą: m. in.:

a. Zarządzania ryzykiem, b. Zarządzania komunikacją, c. Zarządzani zakresem d. Zarządzania zmianą, e. Zarządzania jakością.

W ramach ww. prac nastąpi: a. Utworzenie struktur projektowych po stronie Wykonawcy b. Przygotowanie „Planu wdrożenia i zarządzania wdrożeniem”

zawierających m.in. ustalony we współpracy z Zamawiającym szczegółowy harmonogram i opis zadań i produktów.

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ń dotyczących biznesowych aspektów funkcjonowania CSWI w formie ustnej i/lub pisemnej.

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ą,

18

e. Plan zarządzania jakością, w tym opis standardów projektowych m. in. w zakresie 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.

Szkolenia:

1. Warsztaty z organizacji i zarządzania projektem i przedstawienie produktów prac dla zespołu projektowego Zamawiającego.

Kryteria odbioru:

1. Produkty etapu bez uwag Zamawiającego.

7.2.1.2 Analiza

Czas trwania : 12 tygodni

Celem etapu 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. Uszczegółowienie wymagań na CSWI w oparciu o bieżącą współpracę z przedstawicielami Zamawiającego.

2. Opracowanie Projektu funkcjonalnego CSWI, opisującego szczegółowo w jednoznaczny sposób realizację każdego z wymagań (w tym funkcjonalności oferowanych przez Portal CSWI).

3. Opracowanie Makiety Portalu CSWI. 4. Opracowanie „Macierzy pokrycia wymagań”.



2. Niezwłoczne udzielanie wyjaśnień dotyczących biznesowych aspektów funkcjonowania CSWI w formie ustnej i/lub pisemnej.


Produkty prac :

1. Projekt funkcjonalny CSWI stworzony i dostarczony z wykorzystaniem Repozytorium Modelu w narzędziu Sparx Enterprise Architect v.10 lub wyższa.

a. Wymagania funkcjonalne b. Aktorzy (Rozdział powinien zawierać 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. Makieta Portalu CSWI w postaci diagramów wszystkich ekranów lub działającego prototypu.

3. Macierz pokrycia wymagań zawierająca przypisanie wymagań funkcjonalnych i pozafunkcjonalnych do opisu sposobu ich realizacji przez CSWI.

4. Repozytorium Dokumentacji.

Kryteria odbioru:

1. Produkty etapu bez uwag Zamawiającego.

19

7.2.1.3 Projekt techniczny

Celem etapu 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 np. Wymaganie: „Zapewniony jest czas odtworzenia Rozwiązania po katastrofie (RTO): - środowisko produkcyjne: 2 godziny, - środowiska testowe i rozwojowe: 24 godziny” Spełnienie wymagania: „Opisane w projekcie technicznym w rozdziale „Zasady odtwarzania po katastrofie” na stronie Nn.

3. Wypracowanie w porozumieniu z Zamawiającym zasad zarządzania eksploatacją CSWI w warstwie technicznej.

4. Opracowanie Procedury przyłączenia UR do CSWI. 5. Opracowanie wymagań technicznych wobec systemów informatycznych UR CSWI

korzystających z B2B CSWI.



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


Produkty prac :

1. Projekt techniczny obejmujący w szczególności: a. Projekt procesów na poziomie technicznym z uwzględnieniem:

i. Obsługi błędów wewnątrz CSWI ii. Obsługi błędów pomiędzy CSWI i UR, iii. 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 („Proof of Concept”).

d. Opis zastosowanych mechanizmów bezpieczeństwa. e. Projekty raportów (dane, algorytmy przetwarzania, szata graficzna, formatowanie). f. Projekty wskaźników KPI (definicje, algorytmy obliczeniowe, opis danych

wejściowe i źródeł pochodzenia danych, sposób obsługi po stronie systemu). g. Projekt środowiska sprzętowo-systemowego w każdej z istniejących warstw

systemowych tj.: i. warstwie infrastruktury fizycznej (serwery fizyczne, macierze dyskowe,

biblioteki taśmowe, urządzenia sieci LAN/WAN łącznie z Firewall/IPS/Load balancing oraz połączenia pomiędzy w/w komponentami wraz z adresacją IP),

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

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

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

v. Projekt powinien być zilustrowany diagramami i schematami w formacie Sparx Enterprise Architect 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

20

występującymi w danej warstwie) oraz w układzie pionowym (pomiędzy komponentami występującymi w różnych warstwach).

vi. Projekt wykonywania kopii zapasowych i odtwarzania w ramach usługi IaaS. vii. Projekt wykonywania archiwizacji i zapewnienia dostępu do danych

archiwalnych. viii. 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.

ix. Projekt monitorowania bezpieczeństwa z wykorzystaniem systememu SIEM udostępnionego przez Wykonawcę w ramach usługi IaaS.

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

i. Opis architektury rozumiany jako wskazanie zasadniczych komponentów aplikacyjnych, ich funkcji, lokalizacji względem komponentów infrastrukturalnych i zależności pomiędzy nimi,

ii. Specyfikację wymagań warstwy aplikacyjnej w zakresie infrastruktury. iii. Specyfikację zastosowanych technologii wraz ze wskazaniem zakresu

wykorzystania. iv. Fizyczny model danych.

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

3. Zasady zarządzania eksploatacją CSWI w warstwie technicznej, obejmujące w szczególności zasady zarządzania zmianą, zasady zapewnienia jakości i zasady zarządzania konfiguracją w czasie eksploatacji produkcyjnej CSWI.

4. Dokument opisujący wymagania techniczne wobec systemów informatycznych UR CSWI korzystających z B2B CSWI.

5. Procedura przyłączenia UR do CSWI.

Szkolenia:

1. Warsztaty poświęcone produktom etapu. 2. Szkolenia architektoniczne, administracyjne, developerskie z wykorzystywanych technologii

(po odebraniu pozostałych produktów etapu). 3. Szkolenia z usługi IaaS (po odebraniu pozostałych produktów etapu).

Kryteria odbioru:

1. Produkty etapu bez uwag Zamawiającego. 2. Pozytywny wynik audytu bezpieczeństwa.

7.2.2 Etap II – Implementacja IaaS i B2B CSWI


7.2.2.1 IaaS i środowiska CSWI


Celem etapu jest zapewnienie technicznej infrastruktury IaaS CSWI oraz wszystkich środowisk CSWI:

− produkcyjne wraz z zapasowym, − pre-produkcyjne (odtwarzanie błędów z produkcji, podłączanie nowych uczestników rynku,

testy z uczestnikami rynku) => kopia środowiska produkcyjnego z danymi z tego środowiska

− testowe (testy funkcjonalne nowych wersji i testy wydajnościowe, testy regresji, testy akceptacyjne),

− developerskie (rozwój systemu – tworzenie kolejnych wersji, usuwanie błędów).

Zadania Wykonawcy :

1. Przygotowanie dokumentu „Plan testów IaaS i środowisk CSWI” 2. Przygotowanie dokumentacji administracyjnej dla IaaS i wszystkich środowisk CSWI

21

3. Przygotowanie komponentu (nie jako usługa IaaS) do wsparcia testów (Bugtracker CSWI) wykonywanych w ramach projektu i podczas eksploatacji CSWI typu Jira, Redmine, HP ALM.

4. Przygotowanie dokumentacji administracyjnej i użytkownika Bugtracker CSWI. 5. Dostarczenie i konfiguracja:

a. usługi IaaS b. Bugtracker CSWI c. wszystkich środowisk CSWI d. narzędzi umożliwiających administrowanie i monitorowanie ww. komponentów

6. Przygotowanie scenariuszy testowych. 7. Zaimportowanie scenariuszy testowych do Bugtracker CSWI 8. Wykonanie testów wewnętrznych przez Dostawcę wg. zaakceptowanych scenariuszy

testowych i przekazanie raportu z ich wykonania Zamawiającemu. 9. Asysta przy wykonaniu testów UAT przez Zamawiającego.


1. Weryfikacja, opiniowanie i akceptacja produktów prac. 2. Wykonanie testów akceptacyjnych dostarczonej infrastruktury technicznej i środowisk

CSWI

Produkty prac :

1. 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 Bugtracker 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). 2. Dokumentacja administracyjna dla IaaS i wszystkich środowisk CSWI. 3. Dokumentacja administracyjna i użytkownika Bugtracker CSWI. 4. Raport z wykonanych przez Wykonawcę testów wewnętrznych. 5. Usługa IaaS. 6. Bugtracker CSWI. 7. Środowiska CSWI – w postaci skonfigurowanych maszyn wirtualnych z 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 Backup i Archiwizacji, f. Usługa SIEM.

Szkolenia:

1. Szkolenia dla osób testujących z Bugtracker CSWI. 2. Warsztaty z przygotowanych scenariuszy testowych.

Kryteria odbioru:

1. Produkty etapu bez uwag Zamawiającego 2. Pozytywny wynik audytu bezpieczeństwa 3. Poprawne wykonanie UAT przy pomocy Bugtracker CSWI i zgodnie z przygotowanymi

scenariuszami testowymi.

7.2.2.2 B2B CSWI

Celem zadania jest 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 poszczególnych środowiskach CSWI.

22

Czas trwania : 24 tygodnie

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. Instalacja i konfiguracja B2B CSWI na środowisku developerskim. 5. Instalacja i konfiguracja Symulatora UR CSWI na środowisku developerskim. 6. Przygotowanie dokumentacji administracyjnej B2B CSWI. 7. Przygotowanie dokumentacji administracyjnej i użytkownika Symulatora UR CSWI. 8. Przygotowanie paczek instalacyjnych B2B CSWI do zainstalowania na środowisku

testowym i produkcyjnym. 9. Przygotowanie paczek instalacyjnych Symulatora UR CSWI do zainstalowania na

środowisku testowym i produkcyjnym. 10. Asysta przy instalacji i konfiguracji B2B CSWI wykonanej przez Zamawiającego zgodnie z

dokumentacją administracyjną na środowisku testowym i produkcyjnym i sporządzenie raportu z tej operacji.

11. Asysta przy instalacji i konfiguracji Symulatora CSWI wykonanej przez Zamawiającego zgodnie z dokumentacją administracyjną na środowisku testowym i sporządzenie raportu z tej operacji.

12. Zaimportowanie scenariuszy testowych do Bugtracker CSWI. 13. Wykonanie testów wewnętrznych B2B CSWI na środowisku developerskim z

wykorzystaniem Symulatora UR CSWI i przekazanie Zamawiającemu Raportu z ich wykonania.

14. Asysta przy wykonaniu testów UAT B2B CSWI przez Zamawiającego.


1. Weryfikacja, opiniowanie i akceptacja produktów prac. 2. Instalacja B2B CSWI na środowisku testowym i produkcyjnym zgodnie z przekazaną

dokumentacją administracyjną i paczkami instalacyjnymi B2B CSWI. 3. Instalacja Symulatora UR CSWI na środowisku testowym zgodnie z przekazaną

dokumentacją administracyjną i paczkami instalacyjnymi Symulatora UR CSWI. 4. Wykonanie testów akceptacyjnych (UAT) B2B CSWI przy użyciu Bugtracker CSWI i

zgodnie ze Scenariuszami Testowymi opracowanymi dla produktów tego zadania. 5. Audyt produktów pod kątem bezpieczeństwa.

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, 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. Bugtracker CSWI skonfigurowany do wykonania scenariuszy testowych tego zadania. 4. Raport z wykonanych przez Wykonawcę testów wewnętrznych. 5. Dokumentacja administracyjna B2B CSWI 6. Dokumentacja użytkownika B2B CSWI dla UR 7. Dokumentacja administracyjna Symulatora UR CSWI 8. Dokumentacja użytkownika Symulatora UR CSWI 9. Raport z instalacji i konfiguracji systemu. 10. Gotowa do instalacji na środowisku testowym i produkcyjnym wersja aplikacji B2B CSWI. 11. Gotowa do instalacji na środowisku testowym wersja aplikacji Symulatora UR CSWI. 12. Zaktualizowany Dokument opisujący wymagania techniczne wobec systemów

informatycznych UR CSWI korzystających z B2B CSWI

23

13. Zaktualizowana Procedura przyłączenia UR do CSWI.

Szkolenia:

1. Prezentacja B2B CSWI. 2. Warsztat biznesowy poświęcony korzystaniu z CSWI dla UR. 3. Warsztat techniczny B2B CSWI dla UR.

Kryteria odbioru:

1. Produkty etapu bez uwag Zamawiającego. 2. Pozytywny wynik audytu bezpieczeństwa. 3. Poprawne wykonanie UAT przy pomocy Bugtracker CSWI i zgodnie z przygotowanymi


7.2.3 Etap III - Portal CSWI

Celem etapu jest zbudowanie i uruchomienie Portalu CSWI zgodnie z projektem funkcjonalnym i technicznym oraz zgodnie z makietą Portalu CSWI.

Czas trwania : 24 tygodnie

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. Instalacja i konfiguracja Portalu CSWI na środowisku developerskim. 5. Konfiguracja Symulatora UR CSWI na środowisku developerskim na potrzeby Portalu. 6. Przygotowanie dokumentacji administracyjnej Portalu CSWI. 7. Przygotowanie paczek instalacyjnych Portalu CSWI do zainstalowania na środowisku

testowym i produkcyjnym. 8. Asysta przy instalacji i konfiguracji Portal CSWI wykonanej przez Zamawiającego zgodnie z

dokumentacją administracyjną na środowisku testowym i produkcyjnym i sporządzenie raportu z tej operacji.

9. Asysta przy konfiguracji Symulatora CSWI wykonanej przez Zamawiającego zgodnie z dokumentacją administracyjną na środowisku testowym i sporządzenie raportu z tej operacji.

10. Zaimportowanie scenariuszy testowych do Bugtracker CSWI. 11. Wykonanie testów wewnętrznych Portalu CSWI na środowisku developerskim z

wykorzystaniem Symulatora UR CSWI i przekazanie Zamawiającemu Raportu z ich wykonania.

12. Asysta przy wykonaniu testów UAT Portalu CSWI przez Zamawiającego.


1. Weryfikacja, opiniowanie i akceptacja produktów prac. 2. Instalacja Portalu CSWI na środowisku testowym i produkcyjnym zgodnie z przekazaną

dokumentacją administracyjną i paczkami instalacyjnymi Portalu CSWI. 3. Wykonanie testów akceptacyjnych (UAT) Portalu CSWI przy użyciu Bugtracker CSWI i

zgodnie ze Scenariuszami Testowymi opracowanymi dla produktów tego zadania. 4. Audyt produktów pod kątem bezpieczeństwa.

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

24

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 B2B CSWI. 4. Bugtracker CSWI skonfigurowany do wykonania scenariuszy testowych tego zadania. 5. Raport z wykonanych przez Dostawcę testów wewnętrznych. 6. Dokumentacja administracyjna Portalu CSWI. 7. Dokumentacja użytkownika Portalu CSWI dla UR. 8. Raport z instalacji i konfiguracji aplikacji. 9. Gotowa do instalacji na środowisku testowym i produkcyjnym wersja aplikacji Portal CSWI. 10. e-learning dla użytkowników Portalu CSWI.

Szkolenia:

1. Prezentacja funkcjonalności Portalu CSWI 2. Warsztaty z administracji Portalu CSWI. 3. Warsztat biznesowy poświęcony korzystaniu z Portalu CSWI dla UR

Kryteria odbioru:

1. Produkty etapu bez uwag Zamawiającego 2. Pozytywny wynik audytu bezpieczeństwa 3. Poprawne wykonanie UAT przy pomocy Bugtracker CSWI i zgodnie z przygotowanymi


7.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 i wykonanie testów CSWI z udziałem tych UR.

Pełna możliwość wykorzystania systemu CSWI dla Detalicznego Rynku EE zostanie uzyskana po przyłączeniu pozostałych OSD.

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 Bugtracker CSWI. 5. Wsparcie techniczne i organizacyjne Uczestników Rynku podczas podłączania UR i testów

oraz przygotowanie dla Zamawiającego Raportu z ich wykonania.


1. Współpraca przy opracowywaniu procedur i danych do testów. 2. Koordynacja współpracy z przedstawicielami UR. 3. Wykonanie konfiguracji dla podłączenia UR do CSWI. 4. Weryfikacja, opiniowanie i akceptacja produktów prac. 5. Administracja rozwiązaniem.

Produkty prac :

1. Dokument „Plan testów” ze scenariuszami testowymi ze szczególnym uwzględnieniem testów End-to-end dla każdego procesu biznesowego.

2. Dane niezbędne do przeprowadzenia testów. 3. Bugtracker CSWI skonfigurowany do wykonania scenariuszy testowych tego zadania. 4. Aktualizacja wszystkich produktów zmienianych w ramach tego zadania.

25

5. Raport z testów. 6. Rozwiązanie skonfigurowane do współpracy z wybranymi UR.

Szkolenia:

1. Prezentacja z podsumowania etapu. 2. Warsztat biznesowy poświęcony korzystaniu z CSWI dla UR. 3. Warsztat techniczny CSWI dla UR.

Kryteria odbioru:

1. Produkty etapu bez uwag Zamawiającego. 2. Pozytywny wynik audytu bezpieczeństwa. 3. Poprawne wykonanie UAT przy pomocy Bugtracker CSWI i zgodnie z przygotowanymi


7.2.5 Etap V – Uruchomienie Produkcyjne CSWI.

Celem etapu jest podłączenie wszystkich UR gotowych do korzystania z CSWI.

Etap rozpoczyna uruchomienie usługi Utrzymania 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 inicjalnej konfiguracji dla środowiska pre-produkcyjnego i produkcyjnego 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 po stronie CSWI i administracja rozwiązaniem.


1. Współpraca przy opracowywaniu planu podłączania UR. 2. Nadzór nad procesem przyłączania i koordynacja prac z UR. 3. Prace przyłączeniowe po stronie CSWI i administracja rozwiązaniem. 4. Koordynacja współpracy z przedstawicielami UR. 5. Weryfikacja, opiniowanie i akceptacja produktów prac.

Produkty prac :

1. Plan przyłączeń UR do CSWI. 2. Raporty z przyłączenia UR. 3. Zaktualizowane wszystkie produkty wcześniejszych etapów. 4. Model eksploatacji CSWI zawierający:

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

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

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

5. Licencje na wszystkie komponenty CSWI. 6. Raport z Wdrożenia Produkcyjnego.

Szkolenia:

1. Prezentacja z podsumowania etapu

Kryteria odbioru:

26

1. Produkty etapu bez uwag Zamawiającego. 2. Pozytywny wynik audytu bezpieczeństwa.

7.2.6 Etap VI – Utrzymanie CSWI i podłączanie kolejnych UR.

Czas trwania etapu : do końca świadczenia usługi utrzymania i gwarancji.

Podczas tego etapu CSWI jest uruchomione produkcyjnie i jest utrzymywane przez Dostawcę zgodnie z wymaganiami dla tej usługi. Jednocześnie następuje, normalne dla tego trybu działania CSWI, podłączanie kolejnych uczestników rynku do platformy i prace rozwojowe.

Zadania Wykonawcy :

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

2. Świadczenie usług utrzymania systemu. 3. Prace przyłączeniowe po stronie CSWI i administracja CSWI. 4. Świadczenie usług gwarancji. 5. Rozwój systemu w ramach zaplanowanej puli godzin na to zadanie.


1. Przyłączanie UR i koordynacja prac. 2. Weryfikacja, opiniowanie i akceptacja produktów prac.

Produkty prac :

1. Raporty okresowe z usługi utrzymania i gwarancji. 2. Wyniki prac rozwojowych.

27

8 Migracja danych i inicjalna konfiguracja CSWI

W ramach Przedmiotu Zamówienia 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.

Wymagane jest przygotowanie inicjalnej konfiguracji CSWI w tym Profili UR.

28

9 Testy

W niniejszym rozdziale przedstawiono ramowe założenia Zamawiającego dotyczące rodzajów testów do przeprowadzenia przez Wykonawcę wraz z podziałem odpowiedzialności za realizację poszczególnych testów.

Zamawiający wymaga, aby Wykonawca, w przypadku identyfikacji innych typów i poziomów testów niezbędnych do przeprowadzenia w celu zapewnienia jakości dostarczanych produktów objętych zakresem zamówienia, przedstawił w ramach oferty informacje w tym zakresie.

Zamawiający wymaga aby Wykonawca dostarczył niezbędne do realizacji testów oprogramowanie narzędziowe, w tym oprogramowanie do automatyzacji testów wydajnościowych oraz testów regresji.

9.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 pięć zasadniczych elementów:

9.1.1 Testy wewnętrzne Wykonawcy (pre – FAT)

Celem Testów jest wykrycie błędów i ich usunięcie. Testy te przeprowadza samodzielnie Wykonawca.

Przeprowadzone Testy powinny zostać potwierdzane raportem z Testów wewnętrznych zawierającym scenariusze testowe z zaznaczonymi wynikami, listę wykrytych Błędów oraz informacje o skorygowaniu bądź nie wykrytych Błędów.

9.1.2 Testy fabryczne (FAT)

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

Przypadki testowe oraz scenariusze testowe przygotowuje Wykonawca przy udziale Zamawiającego. Przygotowane przez Wykonawcę scenariusze testowe podlegają zatwierdzeniu przez Zamawiającego.

9.1.3 Testy systemowe (SAT)

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

Testy prowadzone przez Wykonawcę na środowisku testowym.

Przypadki testowe oraz scenariusze testowe przygotowuje Wykonawca przy udziale Zamawiającego. Przygotowane przez Wykonawcę scenariusze testowe podlegają zatwierdzeniu przez Zamawiającego.

9.1.4 Testy integracyjne

Testy prowadzone przez Zamawiającego na zintegrowanym środowisku testowym z udziałem wybranych UR dla – wszystkich komponentów CSWI.

Przypadki testowe oraz scenariusze testowe przygotowuje Wykonawca przy udziale Zamawiającego. Przygotowane przez Wykonawcę scenariusze testowe podlegają zatwierdzeniu przez Zamawiającego. Celem Testów jest wstępne potwierdzenie, iż CSWI wraz ze wszystkimi komponentami spełnia wymagania (celem tych testów jest wykrywanie błędów).

29

9.1.5 Testy akceptacyjne (UAT)

Pełne testy procesowe prowadzone przez Zamawiającego na zintegrowanym środowisku testowym. Pozytywne zakończenie testów potwierdza gotowość CSWI do startu produkcyjnego.

Przypadki testowe oraz scenariusze testowe przygotowuje Wykonawca przy udziale Zamawiającego. Celem testów UAT jest potwierdzenie, iż CSWI wraz z otoczeniem spełnia wymagania (celem tych testów nie jest wykrywanie błędów, albowiem oprogramowanie dostarczone do tej fazy testów powinno być sprawne i stabilne).

9.2 Testy bezpieczeństwa

Testy bezpieczeństwa wykonuje zespół Zamawiającego przy udziale Wykonawcy i mają one charakter audytu bezpieczeństwa przeprowadzanego na wersji CSWI według stanu z końca UAT. Audyt prowadzony jest z wykorzystaniem narzędzi automatycznych oraz manualnej weryfikacji przez zespół Zamawiającego.

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

9.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 awarii ośrodka podstawowego związanych z przełączeniem przetwarzania na ośrodek zapasowy.

Testy wykonuje zespół Wykonawcy ze wsparciem ze strony Zamawiającego.

9.4 Testy wydajnościowe

Testy wydajnościowe realizowane są przez Wykonawcę pod nadzorem Zamawiającego na wersji CSWI zgodnej ze stanem po zakończeniu testów UAT.

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

Testy wykonuje zespół Wykonawcy ze wsparciem ze strony Zamawiającego

9.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).


9.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.


30

10 Licencjonowanie i prawa autorskie

W niniejszym rozdziale przedstawiono wymagania Zamawiającego dotyczące udzielenia licencji i przeniesienia autorskich praw majątkowych na CSWI. Zamawiający wymaga, aby Wykonawca w swojej ofercie przedstawił szczegółowe informacje na temat modelu licencjonowania i zakresu udzielonych licencji na CSWI wraz z określeniem szczegółowych warunków cenowych dotyczących zakupu wymaganych licencji oraz ich utrzymania w skali jednego roku, w rozbiciu na wszystkie środowiska CSWI (produkcyjne, preprodukcyjne, testowe i deweloperskie).

Zamawiający wymaga ponadto, aby Wykonawca w ramach opisu modelu licencjonowania, przedstawił szczegółowe informacje dotyczące możliwości skalowania CSWI (m. in. w zakresie zwiększenia liczby użytkowników CSWI, zwiększenia liczby wymienianych komunikatów) oraz ich wpływ na liczbę wymaganych licencji i ich koszty.

10.1 Wymagania dotyczące licencji (COTS)

• Wykonawca uzyska i dostarczy Zamawiającemu wszystkie niezbędne do wdrożenia i korzystania z CSWI licencje w ramach wynagrodzenia określonego w Umowie. Licencje zostaną udzielone na czas nieokreślony.

• Zamawiający wymaga, aby licencje udzielone na CSWI umożliwiała Zamawiającemu rozwijanie CSWI w dowolnym jego obszarze, tj. np. poprzez dodawanie nowych funkcjonalności poszczególnych komponentów, przyłączanie nowych uczestników komunikacji realizowanej przy wsparciu CSWI, integrowanie z zewnętrznymi bazami danych (możliwość rozwoju CSWI w kierunku modelu szyny wymiany danych z centralną bazą danych pomiarowych / PPE), zwiększanie liczb:

o wymienianych komunikatów, o obsługiwanych procesów wymiany komunikatów, o użytkowników CSWI.

• Zamawiający wymaga aby udzielona licencja zezwalała na uruchomienie CSWI na platformie sprzętowo – systemowej w modelu chmury prywatnej, publicznej lub hybrydowej.

• Licencje będą zawierały prawo do korzystania z CSWI przez pracowników Zamawiającego, pracowników UR oraz pracowników innych podmiotów w wypadku udostępnienia im CSWI na podstawie stosownych umów.

• Wszystkie licencje dostarczone przez Wykonawcę będą udzielone przez oficjalny kanał dystrybucji licencjodawcy.

10.2 Wymagania dotyczące praw autorskich

• Wykonawca, stosownie do ustawy z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (t. j. Dz. U. z 2006r. Nr 90. poz. 631 z późn. zm.), zobowiązuje się do przeniesienia na rzecz Zamawiającego, w dniu protokolarnego odbioru końcowego, autorskich praw majątkowych do wykonanego w ramach realizacji Umowy Oprogramowania Dedykowanego wraz z kodami źródłowymi na wszystkich polach eksploatacji wymienionych w art. 74 ust. 4 powyższej ustawy.

• W zakresie dotyczącym Dokumentacji Dedykowanej, w tym dokumentacji powstającej w trakcie prac projektowych i realizacji CSWI, Wykonawca zobowiązuje się do przeniesienia na Zamawiającego w dniu protokolarnego odbioru końcowego autorskich praw majątkowych do rozporządzania ww. dokumentacją na wszystkich polach eksploatacji określonych w art. 50 ustawy powołanej w tiret 1, a w szczególności do:

o korzystania z pracy na własny użytek, o wielokrotnego publikowania pracy, o rozpowszechniania, o wielokrotnej modyfikacji wedle potrzeb własnych, o wielokrotnego udostępniania i przekazywania osobom trzecim, o wielokrotnego wprowadzania do pamięci komputera.

31

• Zamawiający nabywa prawo do przeniesienia ww. autorskich praw majątkowych na rzecz osób trzecich.

• Zamawiający nabywa również prawo do korzystania i rozporządzania zależnym prawem autorskim w zakresie wymienionym w tiret: 1, 2 i 3.

• Zamawiający nabywa prawo do korzystania i rozporządzania prawem wymienionym w tiret: 1, 2, 3 i 4 nie tylko w kraju, ale również zagranicą.

• Zapłata wynagrodzenia określonego Umowie zawiera wynagrodzenie Wykonawcy za przeniesienie autorskich praw majątkowych, zgodnie z postanowieniami niniejszego rozdziału.

• Wykonawca oświadcza, że osoby trzecie nie uzyskały, ani nie uzyskają autorskich praw majątkowych do prac określonych w tiret: 1 i 2 niniejszego rozdziału.

10.3 Wymagania wolumetryczne

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

dedykowanego Portalu WWW: 200, • Liczba wymienianych komunikatów przy wykorzystaniu CSWI (miesięcznie): 50 000 000, • Liczba Punktów Poboru Energii obsługiwanych przez CSWI: 20 000 000, • Liczba użytkowników – administratorów technicznych CSWI: 7, • Liczba użytkowników – administratorów biznesowych CSWI: 30,

32

11 Gwarancja

Zamawiający wymaga udzielenia gwarancji na CSWI jako całość, w tym dostarczone oprogramowanie COTS i Oprogramowanie Dedykowane oraz Dokumentację CSWI, na okres 48 miesięcy. Okres gwarancji będzie liczony od daty protokolarnego odbioru końcowego przedmiotu Umowy.

W ramach gwarancji Zamawiający wymaga:

• Funkcjonowanie CSWI jako całości zgodnie z niniejszą specyfikacją oraz zgodnie z Dokumentacją CSWI.

• Wydajność CSWI zgodnie z niniejszą specyfikacją. • Udostępnianiu kolejnych wersji oprogramowania COTS (ang. upgrade) lub jego

uzupełnień/poprawek (ang. service pack, fix, patch) bezzwłocznie po ich opublikowaniu. • Udzielania informacji dotyczących: instalacji, konfiguracji, funkcjonowania, rozwijania

funkcjonalności CSWI. • Dostęp do systemu serwisowego i bazy wiedzy producenta oprogramowania COTS. • Usuwanie Incydentów Krytycznych w czasie nie dłuższym niż 4 godzin. • Usuwanie Incydentów o Wysokim Priorytecie w czasie nie dłuższym niż 48 godzin. • Usuwanie Incydentów o Niskim Priorytecie w czasie nie dłuższym niż 7 dni. • W przypadku wystąpienia wady, będącej przyczyną Incydentu Krytycznego lub Incydentu

o Wysokim Priorytecie, niemożliwej do usunięcia w wymaganym dla niego terminie, Strony uzgodnią wdrożenie Rozwiązania Zastępczego oraz czas usunięcie wady.

33

12 Usługi utrzymania i rozwoju

W niniejszym rozdziale przedstawiono wymagania Zamawiającego dotyczące zakresu usług utrzymania i rozwoju CSWI, które będą realizowane w okresie obowiązywania gwarancji na CSWI.

12.1 Utrzymanie CSWI

Zapewnienie dostępności funkcjonalności CSWI: 24 godziny na dobę / 7 dni w tygodniu / 365 dni w roku, z wyłączeniem planowych okien serwisowych.

12.1.1 Świadczenie usługi IaaS dla CSWI.

12.1.2 Monitorowanie przez Wykonawcę poprawności działania, wydajności oraz bezpieczeństwa CSWI 24 godziny na dobę / 7 dni w tygodniu / 365 dni w roku.

12.1.3 Niezwłoczne podejmowanie działań naprawczych oraz informowanie Zamawiającego o wykrytych w czasie monitorowania incydentach i anomaliach.

12.1.4 Wykonywanie kopi zapasowych zgodnie z przyjętą polityką oraz ich odtwarzanie w celu zagwarantowania uzgodnionego RPO.

12.1.5 Wykonywanie konserwacji CSWI w celu zagwarantowania jego poprawności działania, wydajności oraz bezpieczeństwa polegającej m. in. na parametryzacji CSWI oraz instalacji kolejnych wersji oprogramowania COTS oraz Oprogramowania Dedykowanego.

12.1.6 Przeprowadzanie szkoleń z aspektów technicznych i biznesowych CSWI.

12.1.7 Realizacja zadań związanych z administracją CSWI (m. in. wprowadzanie/usuwanie użytkowników).

12.1.8 Udział w audytach CSWI realizowanych przez Zamawiającego.

12.1.9 Realizacja okresowych testów dotyczących m. in. bezpieczeństwa CSWI w celu zagwarantowania uzgodnionego RTO.

12.1.10 Aktualizacja Dokumentacji CSWI.

12.1.11 Dostarczanie raportów dotyczących utrzymania w trybie dziennym, tygodniowym oraz miesięcznym.

12.2 Rozwój CSWI

Realizacja prac rozwojowych, dotyczących każdego obszaru CSWI, z wykorzystaniem puli 1000. MD w okresie trwania umowy.

12.2.1 Obsługa pełnego projektu (analiza, projektowanie, wytworzenie, testy oraz przekazanie do eksploatacji) zgodnie z przyjętymi harmonogramem i pracochłonnością.

12.2.2 Aktualizacja Dokumentacji CSWI.

12.2.3 Dostarczanie raportów dotyczących zrealizowanych prac rozwojowych w trybie miesięcznym.

załącznik nr 2 do regulaminu dialogu technicznego (pdf)

Documents