Usługa katalogowa (hierarchiczna baza danych), będąca implementacją protokołu LDAP.

Załącznik nr 1 do Umowy Nr 1 WSTĘP 1.1 Słownik terminów i skrótów - Opis przedmiotu zamówienia Tabela 1. Słownik terminów i skrótów Pojęcie Active Directory (AD) Atrybut Dokument Dokument elektroniczny Dokument papierowy ESOD Interfejs Opis Usługa katalogowa (hierarchiczna baza danych), będąca implementacją protokołu LDAP. Nazwana właściwość wpisu lub rekordu danych. Każda utrwalona informacja, w szczególności na piśmie, mikrofilmach, negatywach i fotografiach, nośnikach do zapisów informacji w postaci cyfrowej i na taśmach elektromagnetycznych, także w formie mapy, wykresu, rysunku, obrazu, grafiki, fotografii, broszury, książki, kopii, odpisu, wypisu, wyciągu i tłumaczenia dokumentu, zbędnego lub wadliwego wydruku, odbitki, kliszy, matrycy i dysku optycznego, kalki, taśmy atramentowej, jak również informacja utrwalona na elektronicznych nośnikach danych Dokument zapisany w postaci elektronicznej jako obraz dokumentu papierowego, albo występujący pierwotnie w formie elektronicznej rozumiany jako stanowiący odrębną całość znaczeniową zbiór danych uporządkowanych w określonej strukturze wewnętrznej i zapisany na informatycznym nośniku danych Dokument występujący w formie papierowej. Elektroniczny System Obiegu Dokumentów Oprogramowanie umożliwiające wymianę danych pomiędzy dwoma systemami informatycznymi. KO, Komórka Organizacyjna Departament, biuro, gabinet lub delegatura Metadane ESB/ ESB-EPL Ustrukturalizowane informacje stosowane do opisu zasobów informacji lub obiektów informacji (np. wpisu w rejestrze lub elementu słownika), dostarczające szczegółowych danych, dotyczących atrybutów zasobów lub obiektów informacji, w celu ułatwienia ich znalezienia, identyfikacji, a także zarządzania tymi zasobami. WSO2 Enterprise Service Bus str. 1

EPL / System EPL Platforma e-usług UKE Moduł EPL Nazwana część Systemu EPL System dziedzinowy Urząd Wykonawca System informatyczny wspomagający realizację zadań Urzędu w określonym obszarze merytorycznym związanym z jego działalnością na potrzeby niniejszego postępowania ESOD, pwid, NetPar2015, ISKRA. Urząd Komunikacji Elektronicznej Podmiot wybrany przez Urząd do wdrożenia ESB. 1.2 Środowisko wdrożenia 1.2.1 Założenia ogólne wdrożenia ESB w UKE Warstwa Integracyjna jest jednym z głównych elementów architektury budowanej platformy e usług UKE. Podstawowym jej przeznaczeniem jest zapewnienie wymiany danych: w obrębie systemu EPL, pomiędzy systemem EPL a systemami dziedzinowymi UKE, Poniższy diagram przedstawia fragment docelowej proponowanej Architektury Systemu EPL uwzględniający Warstwę Integracyjną Systemu oraz systemy biorące udział w wymianie danych: str. 2

Architektura Warstwy Integracyjnej systemu EPL oparta będzie o Szynę Usług WSO2 ESB (Enterprise Service Bus) i ma na celu realizację koncepcji SOA w środowisku korporacyjnym, a co za tym idzie możliwość dynamicznego przyłączania i odłączania usług wchodzących w skład korporacyjnego systemu informacyjnego. Za pośrednictwem Adapterów systemów dziedzinowych, zewnętrznych oraz modułów EPL, ESB ułatwia wymianę danych systemom o niekompatybilnych interfejsach, ukrywa różnice protokołów komunikacyjnych i formatów danych. ESB wraz z Adapterami systemów w momencie wdrożenia systemu EPL zapewni integracje wszystkich systemów Zamawiającego. Jednym z podstawowych założeń dla komponentu ESB jest wdrożenie go bez konieczności przebudowy systemów dziedzinowych. ESB będzie umożliwiać w przyszłości rozszerzanie komunikacji pomiędzy systemem EPL, a innymi systemami (wdrożonymi wcześniej lub nowymi) bez konieczności wprowadzania istotnych zmian w architekturze systemu EPL, poprzez dołączenia do ESB odpowiednich adapterów. Budowa Warstwy Integracyjnej Systemu EPL w oparciu o rozwiązanie klasy WSO2 Enterprise Service Bus ma umożliwić: konfigurację, monitorowanie i kontrolę trasowania komunikatów pomiędzy usługami, dostarczenie wspólnej infrastruktury komunikacyjnej dla poszczególnych systemów rozwiązania, kontrolę wdrożeń oraz wersjonowania usług opartych o zagregowane wywołania innych usług, mediację oraz orkiestrację usług, dostarczenie mechanizmów integracyjnych zgodnych z Enterprise Integration Patterns i innymi ogólnie przyjętymi wzorcami integracyjnymi (walidacja, transformacja, kolejkowanie, obsługa błędów, obsługa protokołów komunikacyjnych). Wymagania wobec warstwy integracyjnej określono w rozdziale 3 załącznika 2 do Umowy. Wszelka komunikacja pomiędzy komponentami rozwiązania oraz innymi systemami (dziedzinowymi, zewnętrznymi), z którymi jest konieczność wymiany informacji poprzez str. 3

komponenty rozwiązania powinna być oparta o Szynę Usług. Wyjątek mogą stanowić wyszczególnione i uzasadnione przypadki (np. procesy ETL zasilające hurtownię danych). Integracja pomiędzy poszczególnymi komponentami Systemu EPL powinna odbywać się za pośrednictwem Szyny Usług Platformy. Takie rozwiązanie zorientowane na usługi i oparte na luźnych połączeniach pomiędzy aplikacjami tworzy architekturę systemu otwartą, rozszerzalną, umożliwiającą łatwą rozbudowę w celu obsługi większej liczby integrowanych systemów i komunikacji. Komponenty Systemu EPL z punktu widzenia integracji występują w dwóch rolach, jako: konsumenci usług dostarczanych przez ESB, dostawcy usług dla dedykowanych Adapterów ESB. Ponieważ nie wszystkie usługi wykorzystywane przez EPL powinny być dostępne dla systemów dziedzinowych lub zewnętrznych, dlatego niezbędne jest wprowadzenie modelu uprawnień do poszczególnych usług udostępnianych na szynie ESB-EPL, w tym spełnienie wymagań bezpieczeństwa określonych w rozdziale 5.2 załącznika 2 do SIWZ. Szyna Usług Platformy (ESB) jest centralnym elementem Systemu EPL dostarczającym usługi komunikacyjne. ESB tworzy warstwę integracyjną systemu, zapewnia przekazywanie informacji pomiędzy stronami komunikacji, podczas gdy inne systemy są odpowiedzialne za realizację specyficznych funkcjonalności. Zastosowania narzędzia klasy WSO 2 Enterprise Service Bus w architekturze systemu daje możliwość stworzenia zunifikowanego portfela usług, z którego potencjalnie mogą korzystać wszystkie strony komunikacji - moduły systemu EPL, systemy dziedzinowe oraz systemy zewnętrzne. ESB jest zatem wykorzystywana przez System EPL celem dostarczania ich własnych usług dla innych systemów (wewnętrznych lub zewnętrznych), czyli usługobiorców. ESB ma umożliwić prostą integrację z nowymi systemami wdrażanymi przez Zamawiającego. Technologicznymi elementami pozwalającymi na elastyczność Szyny Usług oraz możliwości przyszłej integracji są Adaptery. Podłączanie nowych usług, w tym integracja z nowymi systemami nie będzie wymagała przebudowy ESB będzie to uwarunkowane odpowiednią jej konfiguracją. Konstrukcja technologiczna ESB będzie umożliwiała rozszerzanie portfela usług niezależnie od usług istniejących. Głównymi zadaniami Szyny Usług będzie: zdefiniowanie i dostarczenie infrastruktury oraz szkieletu programistycznego do tworzenia i uruchamiania usług, dostarczanie usług (w modelu SOA) dla systemów wewnętrznych, zdefiniowanie kanonicznego modelu danych dla domeny biznesowej obsługiwanej przez platformę, kontrolowanie routingu komunikatów pomiędzy usługami, orkiestracja, mediacja oraz transformacja komunikatów, obsługa protokołów komunikacyjnych oraz różnych formatów danych - poprzez użycie dedykowanych adapterów do każdego z systemów wewnętrznych i zewnętrznych (w tym dziedzinowych). Architektura ESB powinna być przejrzysta i powinna cechować się podziałem komponentów na warstwy o wyspecjalizowanej charakterystyce. ESB składa się co najmniej z trzech warstw: Warstwy Usług Rolą komponentów Warstwy Usług jest dostarczenie usług ich konsumentom, stworzenie komunikacji pomiędzy klientami usług a ESB. Usługi są dostarczane poprzez ustalony standardowy protokół komunikacji, niezależny od protokołu komunikacji wykorzystywanego przez moduł/system realizujący usługę. str. 4

Warstwy Core Routing Zadaniem komponentów tej warstwy jest przede wszystkim realizacja routingu pomiędzy usługami, orkiestracja i mediacja komunikatów. Warstwy Adapterów Warstwa zawierająca szereg Adapterów: EPL, systemów dziedzinowych. Adaptery to komponenty dedykowane do komunikacji z określonym systemem, ukrywające niekompatybilność interfejsów, mnogość protokołów i formatów danych występujące pomiędzy systemami biorącymi udział w wymianie komunikatów. Wymagania wobec architektury szyny ESB-EPL przedstawiono w rozdziale 2 załącznika 2 do SIWZ. 1.2.3 Architektura Zamawiającego 1) Na potrzeby prowadzenia prac wdrożeniowych oraz produkcyjnego uruchomienia ESB Zamawiający udostępni wykonawcy posiadaną platformę sprzętową wraz z posiadanym przez Zamawiającego oprogramowaniem wirtualizacyjnym firmy Vmware. 2) Na potrzeby środowiska produkcyjnego oraz środowiska testowo-rozwojowego Zamawiający udostępni max. 30 procesorów wirtualnych, 64 GB pamięci RAM oraz 2 TB przestrzeni dyskowej na macierzy NETAPP na binaria, konfigurację oraz gromadzone i przetwarzane dane (przestrzeń dyskowa może zostać rozszerzona przez Zamawiającego w przypadku przyrostu danych przechowywanych i przetwarzanych w systemie). Zamawiający na potrzeby konfiguracji ww. środowisk wydzieli niezbędne zasoby sieciowe i umożliwi przyłączenie do ESB-EPL integrowanych systemów. 3) Szyna ESB będzie zintegrowana z usługami technologicznymi wykorzystywanymi przez Zamawiającego. 4) Na potrzeby wdrażanej szyny ESB-EPL Zamawiający udostępni Wykonawcy oprogramowanie poniżej wyspecyfikowanych produktów. Lp Produkt Nazwa produktu 1 Serwer aplikacyjny WSO2 Application Server 2 Serwer usług danych WSO2 Data Services Server 3 Serwer procesów biznesowych WSO2 Business Process Server 4 Serwer analizy danych WSO2 Data Analytics Server 5 Szyna usług WSO2 Enterprise Service Bus 6 Pośrednik usług WSO2 Message Broker 7 Serwer reguł biznesowych WSO2 Business Rules Server 8 Zarządca API WSO2 API Manager 9 Rejestr utrzymania WSO2 Governance Registry 10 Procesor złożonych zdarzeń WSO2 Complex Event Processor 11 Serwer dostawcy tożsamości WSO2 Identity Server 12 Serwer obsługi tablic WSO2 User Engagement Server 13 Serwer zarządzania danymi WSO2 Storage Server 5) Głównymi usługami technologicznymi Zamawiającego są: a) Active Directory. Usługa katalogowa Active Directory uruchomiona w środowisku Microsoft Windows str. 5

jest wykorzystywana do logowania użytkowników do domeny, dostarczania informacji o pracownikach w tym m.in.: informacje podstawowe: imię, nazwisko, stanowisko, informacje kontaktowe: lokalizacja, numery telefonów, adres służbowy, miejsce w strukturze organizacyjnej: firma, jednostka organizacyjna, komórka organizacyjna, przełożony pracownika. W ramach swojej funkcjonalności usługa katalogowa Active Directory udostępnia dane dla książki adresowej Microsoft Exchange (obsługa poczty elektronicznej). b) System wykonywania kopii zapasowych Hitachi Data Protection Suite. Zamawiający posiada scentralizowany system wykonywania kopii zapasowych zbudowany z wykorzystaniem oprogramowania Hitachi Data Protection Suite. 1.2.4 Wymagania prawne, bezpieczeństwo i dostępność systemu 1) Konfiguracja ESB będzie zapewniać spełnienie Wymagania bezpieczeństwa dla systemów teleinformatycznych, określone w przepisach powszechnie obowiązującego prawa, regulacjach wewnętrznych UKE oraz w rozdziale 5.2 załącznika 2 do SIWZ. 2) Sposób wdrożenia szyny ESB-EPL będzie zapewniał dostępność docelowego jej uruchomienia w Podstawowym i Rezerwowym Centrum Przetwarzania Danych UKE. Wymagania w zakresie dostępności określono w rozdziale 5.3 załącznika 2 do SIWZ. 3) Sposób wdrożenia ESB musi gwarantować, że całość transmisji (wszystkie przesyłane dane przez użytkownika do serwera, jak i te przesyłane z serwera do użytkownika) będzie szyfrowana. 4) Sposób wdrożenia ESB musi używać mechanizmów zapisywania historii działań w celu logowania i raportowania. 5) Sposób wdrożenia ESB musi umożliwiać wybór zdarzeń, które mają być rejestrowane w logach systemowych. 6) Sposób wdrożenia ESB musi zapewniać struktury danych (baz danych systemu) odporne na uszkodzenia. 2 PRZEDMIOT ZAMÓWIENIA 2.1 Określenie przedmiotu zamówienia Wykonawca wdroży szynę integracyjną WSO2 ESB wraz z integracją 4 systemów dziedzinowych Zamawiającego (ESOD, pwid, ISKRA, NETPar2015) w szczególności wykona następujące zadania: 1. przeprowadzenie analizy przedwdrożeniowej umożliwiającej wdrożenie szyny integracyjnej WSO2 ESB i integrację ww. systemów dziedzinowych; 2. przygotowanie wytycznych stanowiących podstawę przygotowania adapterów komunikacyjnych dla dostawców systemów dziedzinowych; 3. instalacja, uruchomienie i konfiguracja (wdrożenie) szyny WSO2 ESB na infrastrukturze Zamawiającego; 4. integracja systemów ESOD-pWID, ESOD ISKRA, ESOD-Netpar2015 z wykorzystaniem adapterów dostarczonych przez Wykonawców systemów dziedzinowych; str. 6

5. zapewnienie technicznej możliwości integracji poprzez szynę kolejnych systemów wdrażanych przez Zamawiającego (np. serwisów WEB CMS, rejestrów, itp.); 6. integracja z Active Directory; 7. przygotowanie dokumentacji: a. analiz przedwdrożeniowych, b. technicznej w formie wytycznych dla Wykonawcy adapterów do integrowanych systemów, c. administracyjnej, d. użytkowej, e. powykonawczej, w tym zawierającej informacji o przekazywanych na rzecz Zamawiającego oprogramowaniach dedykowanych i standardowych; 8. przeprowadzenie instruktaży dla administratorów szyny WSO2 ESB; 9. świadczenie usług wsparcia technicznego, w tym wsparcie w integracji poprzez szynę kolejnych systemów wdrożonych przez zamawiającego (intranet, portal usług, www). 2.2 Oprogramowanie Wykonawca dostarczy oprogramowanie niezbędne do realizacji Przedmiotu umowy oraz zapewni możliwość korzystania z wdrożonej szyny WSO2 ESB w pełnej funkcjonalności przez wszystkich użytkowników bez konieczności nabycia jakichkolwiek dodatkowych licencji w nieograniczonym czasie. 2.3 Zakres prac objętych wdrożeniem: 1. Przeprowadzenie analizy przedwdrożeniowej umożliwiającej wdrożenie szyny integracyjnej WSO2 ESB i integrację ww. systemów dziedzinowych. Wykonawca przeprowadzi, w zaproponowanej w ofercie formie, analizę przedwdrożeniową umożliwiającą mu wdrożenie szyny WSO2 ESB oraz integrację systemów dziedzinowych Zamawiającego, a także umożliwiającą rozwój i integrację nowych systemów teleinformatycznych w przyszłości. 2. Przygotowanie wytycznych stanowiących podstawę przygotowania adapterów komunikacyjnych dla dostawców systemów dziedzinowych. Wykonawca przygotuje, uwzględniając wyniki przeprowadzonej analizy przedwdrożeniowej, wytyczne dla Wykonawców systemów dziedzinowych co do sposobu przygotowania projektu technicznego oraz wykonania adapterów integracyjnych dla tych systemów. Wykonawca przedstawi Zamawiającemu ww. wytyczne nie później niż w terminie 8 tygodni od dnia podpisania Umowy. Zamawiający dostarczy adaptery do systemów dziedzinowych, przygotowane wg ww. wytycznych Wykonawcy, które maja posłużyć do integracji nie później niż w terminie 5 tygodni od dnia odbioru w.w. wytycznych. W przypadku braku możliwości dostarczenia adapterów przez Wykonawców systemów dziedzinowych Wykonawca opracuje rozwiązanie umożliwiające przeprowadzenie odbiorów ESB w sposób symulujący ich działanie. Jeśli taka sytuacja będzie miała miejsce, Zamawiający bezzwłocznie powiadomi o niej Wykonawcę, jednak nie później niż w terminie 5 tygodni od dnia odbioru wytycznych przekazanych przez Wykonawcę. 3. Instalacja, uruchomienie i konfiguracja (wdrożenie) szyny WSO2 ESB na infrastrukturze Zamawiającego polegająca w szczególności na: a) instalacji i konfiguracji dostarczonego oprogramowania, str. 7

b) przygotowaniu skryptów i narzędzi umożliwiających zautomatyzowane uruchamianie i poprawne zamykanie szyny ESB-EPL oraz jej monitorowanie i audyt, c) integracji dostarczonego oprogramowania z posiadanym przez Zamawiającego oprogramowaniem do zarządzania ITS w celu monitorowania pracy ESB-EPL, d) integracji dostarczonego oprogramowania z posiadanym przez Zamawiającego systemem wykonywania kopii zapasowych, e) uruchomieniu funkcjonalności szyny, o których mowa w rozdziale 4 załącznika 2 do Umowy. 4. Integracja systemów ESOD-pWID, ESOD ISKRA, ESOD-NetPar2015 z wykorzystaniem adapterów dostarczonych przez Wykonawców systemów dziedzinowych polegająca w szczególności na uruchomieniu przekazywania komunikatów pomiędzy systemami dziedzinowymi zamawiającego w sposób zapewniający współdziałanie ww. systemów dziedzinowych. 5. Integracja z Active Directory W ramach Platformy EPL wykorzystywana będzie usługa katalogowa Active Directory zgodnie z opisem przedstawionym w pkt. 1.2.3. Zarządzanie kontami użytkowników i ich uprawnieniami będzie odbywało się bezpośrednio w systemach dziedzinowych Platformy EPL. Jednak dane uwierzytelniające użytkowników do tych systemów mogą pochodzić zarówno z: AD, LDAP, epuap jak i certyfikatu kwalifikowanego. 6. Przygotowanie dokumentacji administracyjnej, użytkownika oraz powykonawczej w szczególności: a) opisu modeli danych i usług jakie zostały zastosowane do integracji, b) opisu środowiska w każdej z warstw systemowych, c) modelu architektury ESB, d) schematu powiązań pomiędzy aplikacjami/modułami ESB i magazynami danych oraz otoczeniem zewnętrznym, e) opisu warstwy bezpieczeństwa ESB w odniesieniu do Polityki Bezpieczeństwa obowiązującej u Zamawiającego, f) opisu istotnych dla pracy ESB parametrów konfiguracji systemów operacyjnych, g) procedury instalacyjne oprogramowania wdrożonego przez Wykonawcę, określające wszystkie dające wyróżnić się składniki oprogramowania, ich wersje, etykiety nośników instalacyjnych oraz sposób ich instalacji. Wymaga się, aby każdy występujący w procedurze krok instalacyjny był w projekcie zobrazowany fotografią (zdjęciem, zrzutem) ekranu (ang. screeenshot) odpowiadającą procesowi instalacyjnemu u Zamawiającego, h) projektu wykonywania kopii zapasowych przy wykorzystaniu systemu posiadanego przez Zamawiającego Hitachi Data Protection Suite, w tym: str. 8

i. polityka wykonywania kopii zapasowych, ii. procedura odtwarzania systemu z zachowaniem spójności, i) projektu integracji z usługami technologicznymi, procedura kopiowania danych pomiędzy środowiskami: produkcyjnym, testowo-rozwojowym, j) procedury przenoszenia konfiguracji pomiędzy środowiskami, k) podręczników administracji Systemem ESB-EPL l) Opracowanie procedur awaryjnych, w tym procedury uruchomienia systemu po awarii. 7. przeprowadzenie instruktaży dla administratorów szyny WSO2 ESB: a) instruktaż w zakresie parametryzowania i konfigurowania ESB oraz środowiska pracy użytkowników, b) instruktaż w zakresie użytkowania ESB, c) instruktaż w zakresie zarządzania pracą szyny ESB-EPL (w tym jej monitorowania, przeprowadzania audytów i zarządzania logami); 8. świadczenie usług wsparcia technicznego w tym wsparcie w integracji poprzez szynę ESB modułów systemu wdrożonych przez Zamawiającego (np. intranet, portal usług elektronicznych) Wsparcie powinno dotyczyć w szczególności: a) usługi "hot-line" świadczonej w okresie minimum 6 miesięcy od dnia podpisania protokołu odbioru końcowego, b) utrzymania środowiska produkcyjnego i testowo-rozwojowego (w zakresie wymaganych jego aktualizacji); c) dostosowania opracowanych rozwiązań (konfiguracji, skryptów, narzędzi) do zmian wynikających z eksploatacji ESB-EPL, a w tym: a. dostosowanie konfiguracji usług złożonych orkiestrowanych na ESB-EPL do zmieniających się przepisów prawa, b. optymalizację szybkości działania, c. modyfikację ergonomii systemu, d) wsparcia wiedzą w postaci realizacji usługi typu "hot-line" w dni robocze pracy Urzędu w zakresie prowadzonych prac rozwojowych dotyczących osiągania pełnej interoperacyjności systemów w ramach UKE związanej z wykorzystaniem szyny ESB- EPL; 9. W ramach usług gwarancyjnych Wykonawca zapewni: a) serwis gwarancyjny; b) usuwanie Awarii i Błędów; c) usunięcie problemów/incydentów, tj. uszkodzeń, błędów i nieprawidłowości w ESB, w str. 9

terminie zależnym od kategorii błędu, zgodnie z poniższą kategoryzacją: - Awaria - Wykonawca zobowiązuje się określić przyczynę Awarii, usunąć ją i uruchomić ESB w terminie 8 godzin od zgłoszenia; - Błąd poziomu 1 - Wykonawca zobowiązuje się określić przyczynę błędu, usunąć go i uruchomić ESB w terminie 12 godzin od zgłoszenia; - Błąd poziomu 2 - Wykonawca zobowiązuje się określić przyczynę błędu, usunąć go i uruchomić ESB w terminie 24 godzin od zgłoszenia; - Błąd poziomu 3 - Wykonawca zobowiązuje się określić przyczynę błędu, usunąć go w terminie 7 dni kalendarzowych od dnia zgłoszenia; - Błąd poziomu 4 - Wykonawca zobowiązuje się określić przyczynę błędu, usunąć go w terminie 14 dni kalendarzowych od dnia zgłoszenia; Awaria Błąd powodujący nieprawidłowości w funkcjonowaniu ESB niezgodne z dokumentacją lub specyfikacją wymagań, powodujące niemożność lub utrudnienia w eksploatacji Systemu. Błąd Błąd poziomu 1 Skategoryzowany incydent lub problem o określonym priorytecie, który ze względu na ograniczenia w poprawnym działaniu ESB określany jest jako: Awaria, Błąd poziomu 1, Błąd poziomu 2, Błąd poziomu 3, Błąd poziomu 4. Błąd powodujący brak działania całości ESB lub brak funkcjonowania mechanizmów bezpieczeństwa. Błąd poziomu 2 Błąd powodujący brak działania części funkcjonalności ESB, niespełnienie podstawowych wymagań wydajnościowych, niekompletność mechanizmów bezpieczeństwa, działanie kluczowych funkcjonalności w sposób niezgodny z wymaganiami. Błąd poziomu 3 Błąd poziomu 4 2.4 Realizacja przedmiotu zamówienia Niespełnienie mniej istotnych wymagań wydajnościowych, błędy dotyczące ergonomii kluczowych funkcjonalności ESB. Błąd dotyczący ergonomii mniej istotnych funkcjonalności, błędy literowe w tekstach pojawiających się na ekranach i wydrukach, uwagi do wyglądu interfejsu użytkownika nie wpływające bezpośrednio na ergonomię. 1. Zamawiający wymaga, aby wdrożenie i integracja nastąpiły w czasie nie dłuższym niż 22 tygodni od daty podpisania Umowy. 2. Zamawiający wymaga: 1) świadczenia usług gwarancyjnych w okresie 36 miesięcy od daty podpisania str. 10

Protokołu Odbioru Końcowego; 2) świadczenia usług serwisu i wsparcia technicznego w okresie co najmniej 6 miesięcy od daty podpisania Protokołu Odbioru Końcowego. 3. Na potrzeby realizacji Zamówienia Wykonawca zarekomenduje powołanie zespołów specjalistycznych ze strony Zamawiającego niezbędnych dla prawidłowego wdrożenia ESB wskazując ich rekomendowany skład, niezbędne kompetencje. str. 11