SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA

Transkrypt

1 SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA I. Przedmiot zamówienia PO MODYFIKACJI W DNIU 6 SIERPNIA 2014 r. 1. Plany Kontekst wdrożenia Załącznik nr 1 do SIWZ Prowadzone postępowanie przetargowe jest częścią projektu "Wdrożenie platformy integracji danych i aplikacji MNiSW". Jednym z celów w/w projektu jest uzyskanie interoperacyjności obecnie istniejących systemów, jak również zapewnienie jej względem systemów, które powstaną w przyszłości. Ze względu na złożoność organizacyjną i techniczną zaplanowano wdrożenie powyższego modelu w sposób stopniowy. Celem bieżącego etapu jest uzyskanie interoperacyjności technicznej. W ramach prac nad pozostałymi składowymi projektu opracowano projekty "Program zintegrowanego rozwoju systemów informatycznych oraz przeprowadzono wstępną diagnozę obecnie istniejących systemów za pomocą ankiet. Zebrany materiał będzie podstawą do realizacji następnego etapu wdrożenia systemów użytkowych. Mimo przeprowadzonych prac, opracowanie docelowej architektury systemów informatycznych urzędu jest jeszcze we wczesnym stadium rozwoju. Z tego też względu, poziom zapotrzebowania wydajnościowego platformy wyspecyfikowano za pomocą określenia poziomu wydajności sprzętu. W zawartych poniżej wymaganiach Zamawiający skorzystał z benchmarku SPEC int_rate_base2006. W ramach zamówienia planuje się zakup dwóch serwerów, na których zostaną uruchomione następujące składniki oprogramowania: a) oprogramowanie wirtualizacyjne, b) serwer aplikacyjny, c) baza danych. 2. System operacyjny Elementem Platformy Sprzętowo Programowej będzie system operacyjny Windows 2012 albo SLES 11 sp3; wykonawca wskaże zamawiającemu w ofercie, który z ww. systemów zamierza stosować, a zamawiający dostarczy wykonawcy ten system najpóźniej w dniu rozpoczęcia prac w siedzibie zamawiającego. Strona 1 z 25

2 3. Wymagania 1. Platforma Sprzętowo-Programowa Komponent Minimalne wymagania Instalacja sprzętu i oprogramowania Uruchomienie i konfiguracja Dokumentacja Sprzęt: 1) Serwer AS 2) Serwer BD Oprogramowanie: 1) oprogramowanie wirtualizacyjne, 2) serwer aplikacyjny, 3) baza danych. Dwa środowiska (produkcyjne i testowe): 1) Serwer przeznaczony dla oprogramowania serwera aplikacyjnego: Środowisko produkcyjne serwera aplikacyjnego zainstalowane na oddzielnej maszynie wirtualnej wykorzystujące 6 rdzeni procesora. Środowisko testowe serwera aplikacyjnego zainstalowane na oddzielnej maszynie wirtualnej o minimalnych wymaganiach wydajnościowych. 2) Serwer przeznaczony dla oprogramowania bazy danych: Środowisko produkcyjne bazy danych zainstalowane na oddzielnej maszynie wirtualnej wykorzystujące 1 socket (przez socket rozumiemy jeden procesor fizyczny). Środowisko testowe bazy danych zainstalowane na oddzielnej maszynie wirtualnej o minimalnych wymaganiach wydajnościowych. Dokumentacja powykonawcza: musi zawierać szczegółową konfigurację poszczególnych składowych Oprogramowania, ich wzajemnych relacji i powiązań umożliwiających zainstalowanie, uruchomienie i poprawną pracę Platformy. 1) Wykonawca musi opracować Dokumentację administratora, która zawierać będzie co najmniej: a) procedury administracyjne, b) procedury instalacji i konfiguracji, c) procedury bieżących działań administracyjnych, d) procedury okresowych/planowanych działań administracyjnych, e) procedury aktualizacji standardowych elementów dostarczonego Oprogramowania, f) procedury Distater Recovery ze scenariuszami awarii oraz procedur działań odtworzeniowych i uruchomieniowych mających na celu zminimalizowanie strat danych. 2) Wykonawca zobowiązany jest do przekazania w wersji papierowej 1 egzemplarz oraz wersji elektronicznej po 2 egzemplarze Dokumentacji wymaganej poniższymi wymaganiami na trwałym nośniku (np. CD lub DVD lub pendrive, itp.). Na każdym nośniku dodatkowo poza przekazywaną Strona 2 z 25

3 Dokumentacją musi być dostępny plik zawierający poniższy wykaz: a) nazwa pliku (tożsama nazwie dokumentu) b) wersja pliku (tożsama wersji dokumentu) c) data opracowania pliku d) autorzy dokumentu. Instruktaż Gwarancja Wyjaśnienie procedury instalacji i konfiguracji. Zamawiający wymaga 3-letniej gwarancji obejmującej wsparcie techniczne z możliwością przedłużenia o 12 miesięcy, a następnie o kolejnych 12 miesięcy. 1) Usługi gwarancyjne realizowane będą: a) w siedzibie zamawiającego, przy czym koszty dojazdu ponosi wykonawca, b) zdalnie z zachowaniem zasad określonych w paragrafie 12 ust.24 IPU, 2) W ramach gwarancji zamawiający wymaga: a) zapewnienia funkcjonowania Serwera Bazy Danych, Serwera Aplikacji, Oprogramowania Serwera Aplikacji, Oprogramowania Bazy Danych oraz Oprogramowania wirtualizacyjnego, jak również ich prawidłowej współpracy jako całości określonej terminem Platformy Sprzętowo Programowej, zgodnie z wymaganiami określonymi w niniejszym Opisie Przedmiotu Zamówienia oraz zgodnie z Dokumentacją. b) nieodpłatnego usuwania Wad, c) usuwania luk bezpieczeństwa, d) utrzymania zgodności Platformy z obowiązującym prawem, e) zapewnienia wsparcia technicznego dotyczącego instalacji, konfiguracji i funkcjonowania Platformy, f) zdalnego wspomagania zamawiającego w zakresie czynności związanych z identyfikacją i/lub usuwaniem Wad, między innymi w postaci konsultacji telefonicznych i mailowych. g) zapewnienia, że realizacja prac mających na celu usuwanie Wad nie zakłóci pozostałej funkcjonalności Platformy oraz innych systemów zamawiającego powiązanych z Platformą, h) przekazywania i instalacji uzgodnionych z Administratorem Platformy i przetestowanych Aktualizacji Oprogramowania bezzwłocznie po ich wejściu do obrotu (udostępnienia na rynku) celem zapewnienia poprawnego funkcjonowania Platformy, i) dostarczenia narzędzia pozwalającego na zgłaszanie oraz obsługę zgłoszeń gwarancyjnych. Usuwanie Wad Platformy Sprzętowo Programowej realizowane będzie w następujących terminach: 3) w przypadku Awarii: b) czas reakcji: niezwłocznie, nie później niż 4 godziny od czasu przyjęcia c) rozwiązanie zastępcze: niezwłocznie, nie później niż 8 godzin od czasu przyjęcia Strona 3 z 25

4 d) czas naprawy: niezwłocznie, nie później niż 48 godzin od czasu przyjęcia zgłoszenia; 4) w przypadku Błędu: b) czas reakcji: niezwłocznie, nie później niż 1 dzień od dnia przyjęcia c) czas naprawy: niezwłocznie, nie później niż 7 dni roboczych od dnia przyjęcia zgłoszenia; 5) w przypadku Usterki: 2. Serwer Aplikacji Oprogramowanie b) czas reakcji: niezwłocznie, nie później niż 7 dni od dnia przyjęcia c) czas naprawy: niezwłocznie, nie później niż 25 dni od dnia przyjęcia zgłoszenia. Komponent Licencja Minimalne wymagania Licencje na oprogramowanie serwera aplikacji umożliwiające wykorzystanie oprogramowania: w środowisku produkcyjnym na minimum 6 rdzeniach zaoferowanego serwera aplikacyjnego oraz w środowisku testowym na drugim procesorze ww. serwera na minimum 2 rdzeniach. Standardy 1) Wsparcie dla Java SE wersja 6; 2) Certyfikacja standardu Java EE wersja 5; 3) Możliwość integracji ze Spring Framework,; 4) Wbudowana integracja EJB 3.0; 5) Wbudowane wsparcie dla specyfikacji Commons J Work Manager API i Timer API; 6) Wbudowane wsparcie dla specyfikacji JSR-88 plany wdrożeń (Deployment Plan); 7) Wbudowana obsługa standardu Web services WS-ReliableMessaging 1.1 i WS-ReliableMessaging Policy 1.1; 8) Wbudowana obsługa standardu Web services WS-Trust 1.3; 9) Wbudowana obsługa standardu Web services WS-SecureConversation 1.3; 10) Wbudowana obsługa standardu Web services WS-Security 1.1; 11) Wbudowana obsługa standardu Web services WS-SecurityPolicy 1.2; 12) Wbudowana obsługa standardu Web Service MTOM\XOP SOAP Message Transmission Optimization Mechanism/XML-binary Optimized Packaging. Bezpieczeństwo 1) Możliwość realizacji odpowiedniego poziomu bezpieczeństwa w zakresie: a) uwierzytelniania, b) kontroli dostępu, Strona 4 z 25

5 c) zarządzania użytkownikami, grupami i rolami, d) tworzenia, przechowywania i walidacji certyfikatów, haseł, kluczy, e) audytowania zdarzeń bezpieczeństwa, f) wsparcia dla pojedynczego logowania SSO"; 2) Dostępność mechanizmów uwierzytelniania i szyfrowania usług takich jak: użytkownik/hasło, passphrase, weryfikacja hostów, brak uwierzytelniania, tunelowanie wywołań SSL, certyfikaty X.509; 3) Wbudowana, dostępna poprzez konfigurację, integracja z katalogami użytkowników, grup i ról LDAP, Active Directory, bazy danych, Windows NT, X.509, SAML, własne; 4) Możliwość jednoczesnego podłączenia wielu usług katalogowych, w tym różnego typu (np. równocześnie LDAP, Active Directory, bazy danych, Web service, systemy autentykacji i autoryzacji firm trzecich, własne); 5) Opisana w dokumentacji (wraz z przykładami) możliwość tworzenia własnych implementacji usług security: uwierzytelnienia, autoryzacji, mapowania ról, mapowania uwierzytelnień, baz danych kluczy/certyfikatów, walidacji poprawności kluczy/certyfikatów, audytowania, itd.; 6) Obsługa specyfikacji: a) Java Authentication and Authorization Service (JAAS), b) Java Secure Sockets Extensions (JSSE), c) Java Cryptography Extensions (JCE), d) Java Authorization Contract for Containers (JACC)"; 7) Wbudowana obsługa standardów SAML 1.1, SAML 2.0 lub wyższych; 8) Wbudowana integracja w ramach Single-Sign-On (SSO) z takimi technologiami jak SAML (1.1, 2.0), Kerberos (SPENEGO, Windows 2003 i 2008,.NET), Web service (SAML); 9) Wbudowane API do funkcjonalności przeszukiwania i walidacji certyfikatów X.509; 10) Obsługa mechanizmów autoryzacji i mapowania ról przy użyciu standardu XACML 2.0 lub równoważnego; 11) Możliwość konfiguracji dynamicznego członkostwa ról, np. uwzględniającego datę i czas, zawartość wybranych elementów w komunikatach SOAP (Web services), wartość atrybutów żądań HTTP, wartość atrybutów sesji HTTP, czy parametrów metod EJB; 12) Wbudowana obsługa standardu Common Secure Interoperability Version 2 (CSIv2); 13) Wbudowana obsługa protokołu SNMP v3 wraz z HMAC-MD5-96, HMAC- SHA-96. Architektura (HA - Klastrowanie, Wydajność) 1) Publicznie dostępne raporty (benchmarki) dotyczące wydajności serwera aplikacyjnego (np. Spec Java Application Server). Raporty powinny zawierać szczegółowe informacje o zastosowanej konfiguracji serwera aplikacyjnego, JVM, bazy danych, sprzętu i innych komponentów użytych podczas testowania. Raporty muszą znajdować się na stronach WWW organizacji powołanych do ustanawiania i publikowania standardowych benchmarków wydajnościowych; Strona 5 z 25

6 2) Wbudowane automatyczne samostrojenie się serwera aplikacyjnego (selftuning); 3) Wbudowana możliwość klastrowania połączeń JDBC; 4) Wbudowana możliwość klastrowania JMS (w tym automatyczne przełączanie klientów JMS w momencie failover serwerów JMS); 5) Możliwość klastrowania obiektów typu singelton w aplikacjach; 6) Obsługa klastrowania dla mechanizmu Store-and-Forward; 7) Obsługa klastrowania Web-services zgodnych z WS-ReliableMessaging. Funkcjonalność 1) Wbudowane wsparcie dla współdzielenia kodu (np. bibliotek) pomiędzy wieloma aplikacjami (Web, EJB, Web services). Biblioteki (JAR, WAR, EAR, EJB) powinny być instalowane w serwerze aplikacyjnym jednokrotnie i wiele aplikacji może z nich skorzystać. Możliwość zainstalowania wielu wersji bibliotek równocześnie; 2) Możliwość konfiguracji, która wersja biblioteki będzie wykorzystywana przez aplikację. Konfiguracja powinna odbywać się w sposób deklaratywny (za pomocą deployment deskryptorów) nie poprzez kopiowanie kodu bibliotek do aplikacji. Przykład wiele implementacji JSF działających równocześnie w serwerze aplikacyjnym; 3) Konfiguracja komponentów w aplikacjach webowych (np. servletów, filtrów servletów, web services) za pomocą adnotacji Java 5 (dotyczy także parametrów specyficznych dla danego serwera aplikacyjnego); 4) Wbudowana obsługa żądań HTTP w sposób asynchroniczny (czyli możliwość rozdzielenia obsługi HTTP request i HTTP response na różne wątki); 5) Wbudowane wsparcie dla przechowywania (persistence) sesji webowych i EJB w pliku, bazie danych i pamięci; 6) Możliwość przechowywania istotnych informacji dotyczących sesji użytkownika (w tym sesja http, konteksty usług typu Servlet oraz konteksty usług typu Session EJB) w zewnętrznej pamięci cache poza głównym procesem maszyny wirtualnej Java. Oprogramowanie musi umożliwiać mechanizmy klastrowania aplikacji w powyższy sposób, czyli z wykorzystaniem cache a zewnętrznego; 7) Wsparcie dla replikacji sesji w pamięci pomiędzy wieloma instancjami serwerów aplikacyjnych uruchomionych na wielu fizycznych maszynach. Replikacja sesji powinna zapewniać wysoką wydajność, w tym możliwość replikowania sesji w trybie primary-secondary (czyli zarządzanie maksymalnie dwiema kopiami sesji użytkownika w klastrze), a także wspierać replikację sesji pomiędzy klastrami serwerów aplikacyjnych (intracluster) poprzez sieci LAN/MAN/WAN; 8) Wbudowana możliwość konfiguracji priorytetów obsługi żądań, priorytetów aplikacji i ich komponentów. Możliwość przypisywania reguł SLA do użytkowników, aplikacji i ich komponentów (np. servletów, EJB). Reguły SLA powinny obejmować takie cechy jak: wagi (priorytety np. % czasu procesorów gwarantowany dla aplikacji lub ich komponentów), czasy odpowiedzi, min/max liczba wątków, itp.; 9) Wbudowana obsługa klastrowania (failover/load balancing) na poziomie bazy danych, włącznie z poprawną obsługą transakcji rozproszonych (XA) Strona 6 z 25

7 w takim klastrowaniu; 10) Wbudowana obsługa pul połączeń do baz danych z uwierzytelnieniem połączeń. Tworzenie pul połączeń JDBC, w których jest możliwość zmapowania użytkowników serwera aplikacyjnego na użytkowników zdefiniowanych w bazie danych. Powinna być możliwość wykonania mapowania typu user id per connection ; 11) Wbudowana obsługa wprowadzania zmian w kodzie Java w aplikacjach na serwerze bez konieczności re-deployment u aplikacji ani restartu serwera aplikacyjnego (hot Java class swapping); 12) Możliwość uruchamiania wielu działających równocześnie wersji tej samej aplikacji (side-by-side deployment). Klienci, którzy rozpoczęli pracę z wcześniejszą wersją aplikacji powinni pracować z tą wersją aplikacji. Nowi klienci powinni pracować z nową wersją aplikacji. Serwer powinien zapewnić automatyczne wyłączanie poprzednich wersji aplikacji, w momencie, gdy ich użytkownicy zakończą pracę; 13) Wbudowana obsługa integracji z technologią Microsoft COM. Możliwość wywoływania obiektów COM z poziomu aplikacji Java EE. Możliwość wywoływania kodu aplikacji Java EE z poziomu klientów COM; 14) Wbudowana obsługa optymalizacji transakcji rozproszonych (XA); 15) Wbudowana obsługa zaawansowanych mechanizmów kolejkowych (JMS): grupowanie komunikatów przesyłanych do JMS z gwarancją zachowania kolejności ich przetworzenia (konsumpcji) wynikającą z kolejności ich utworzenia (produkcji); 16) Wbudowana obsługa zaawansowanych mechanizmów kolejkowych (JMS): możliwość łączenia komunikatów JMS w jednostki (grupy), a następnie przetwarzanie jednostek. Klient JMS nie może przetwarzać danej jednostki, dopóki w JMS nie pojawią się wszystkie komunikaty wchodzące w skład danej jednostki. Przetwarzanie różnych jednostek (niezależnych od siebie grup komunikatów) powinno być jednak możliwe; 17) Wbudowany interfejs do JMS dla aplikacji napisanych w C (JMS C API); 18) Wbudowany interfejs do JMS dla aplikacji napisanych w Microsoft.NET C# (JMS C# API); 19) Wbudowana obsługa zawieszania i wznawiania transakcji rozproszonych (XA) w ramach JTA API (suspend/resume); 20) Wbudowany mechanizm współpracy z zewnętrznymi menedżerami transakcji rozproszonych (third-party, foreign transaction managers); 21) Wbudowana obsługa propagacji dodatkowych danych w ramach żądań (content propagation); 22) Obsługa mechanizmu Store-and-Forward, czyli gwarantowanego, niezawodnego przesyłania komunikatów pomiędzy instancjami serwerów aplikacyjnych; 23) Wbudowana obsługa asynchronicznych Web services (klient Web service, po wywołaniu Web service, nie musi zatrzymać się w oczekiwaniu na odpowiedź z Web service. Odpowiedź jest asynchronicznie przekazywana do klienta w późniejszym czasie); 24) Wbudowana obsługa Web services, które mogą wykonywać operacje na kliencie (callback Web service); Strona 7 z 25

8 25) Wbudowane wsparcie dla buforowanego wywoływania Web services; 26) Wbudowane wsparcie dla zewnętrznych dostawców usług kolejkowych (np. MQSeries) wraz z przenoszeniem kontekstów security i transakcyjnego. Administracja 1) Zarządzanie i monitorowanie wieloma serwerami aplikacyjnymi z jednej konsoli; 2) Zarządzanie i monitorowanie wielu aplikacji wdrożonych na różnych instancjach serwera aplikacyjnego; 3) Zarządzanie klastrami serwerów aplikacyjnych; 4) Monitorowanie zasobów serwerów aplikacyjnych takich jak pule połączeń JDBC, kolejki JMS, źródła danych; 5) Monitorowanie w czasie rzeczywistym zdarzeń płynących z wielu serwerów aplikacyjnych z możliwością wyspecyfikowania: a) poziomów zdarzeń krytycznych oraz ostrzeżeń, b) różnych metod notyfikacji o zdarzeniach, c) definiowanie reguł notyfikacyjnych, d) możliwości podpięcia akcji naprawczych pod zdarzenie"; 6) Centralne zarządzanie incydentami i problemami; 7) Raportowanie wydajności systemów z możliwością: a) wyspecyfikowania zakresu czasowego wyświetlanych danych, b) wyświetlania danych z różnych komponentów na jednym raporcie (wykresie), c) zapisania aktualnych danych wydajnościowych jako wzorca do porównywania z przyszłymi danymi"; 8) Dostęp do logów zarządzanych serwerów aplikacyjnych z możliwością: a) filtrowania po czasie wpisu do logów b) filtrowania poziomie zalogowanej informacji (error, warning, etc.) c) pobrania pliku logu lub wyeksportowania wiadomości do pliku" 9) Możliwości monitorowania poziomu dostępności usługi (SLA) względem zdefiniowanych parametrów (mierników); 10) Monitorowanie i diagnostyka JVM: a) bez konieczności wprowadzania specyficznych zmian w kodzie aplikacji, b) bez konieczności restartu serwera, c) pełny wgląd w dane maszyny wirtualnej Java (wątki, stos, etc), d) analiza wpływu działania maszyny wirtualnej Java na bazę danych i odwrotnie; 11) Wbudowana możliwość konfiguracji ochrony serwerów aplikacyjnych (i aplikacji) przed przeciążeniem. Dla przykładu: jeśli liczba żądań do serwera/aplikacji jest zbyt duża, serwer powinien przekierować nowe żądania do innych instancji w klastrze; 12) Automatyczny restart serwera lub aplikacji w sytuacji ich zawieszenia (braku odpowiedzi), pojawienia się błędów o braku pamięci lub zbyt długiego wykonywania się wątków (stuck threads); Strona 8 z 25

9 13) Możliwość ograniczenia liczby sesji HTTP w serwerze tworzonych przez daną aplikację; 14) Możliwość rozdziału ruchu (protokołów) na różne interfejsy sieciowe (lub adresy IP). Np. możliwość rozdzielenia ruchu administracyjny/monitoringu od ruchu aplikacyjnego oraz od ruchu związanego z funkcjonowaniem klastra (replikacja sesji) dane związane z tymi funkcjami mogą być przesyłane poprzez inne karty sieciowe/podsieci, itp.; 15) Możliwość automatycznego i ręcznego restartu (migracji) instancji serwerów aplikacyjnych na innych fizycznych maszynach w razie awarii, wraz z przeniesieniem istotnych dla przetwarzania danych (np. zawartość kolejek JMS, logi transakcji rozproszonych JTA). Automatyczna rekonfiguracja serwerów aplikacyjnych po restarcie (zmiana adresu IP, itp.); 16) Możliwość konfiguracji i zarządzania środowiskiem serwerów aplikacyjnych równocześnie poprzez: konsole webowe, skrypty (np. Jython), programowo (Java API), SNMP; 17) Możliwość łatwego rozszerzania funkcjonalności oferowanych przez konsole administracyjne. Rozszerzenia nie powinny wymagać zmian w kodzie istniejących konsol. Rozszerzenia nie powinny wymagać zmian w przypadku przyszłych aktualizacji (upgrade wersji serwera aplikacyjnego, itp.); 18) Wprowadzanie zmian w konfiguracji środowiska serwerów aplikacyjnych powinno odbywać się w sposób transakcyjny (albo wszystkie zmiany zostaną poprawnie wprowadzone albo żadna zmiana nie będzie wprowadzona); 19) Możliwość automatycznego tworzenia skryptów konfiguracyjnych (rejestrowanie wykonywanych zmian, a następnie ich zapisywanie do pliku, tak, aby później taki plik uruchomić w postaci skryptu); 20) Wbudowany mechanizm automatycznej naprawy transakcji (transaction recovery) podczas restartu serwera aplikacyjnego; 21) Wbudowany moduł do diagnostyki pracy serwera aplikacyjnego i uruchomionych w nim aplikacji. Możliwość dynamicznego dodawania poprzez konfigurację własnego kodu diagnostycznego do określonych miejsc w aplikacji i jej komponentach. Infrastruktura cache 1) Wsparcie podstawowych technologii programistycznych (API pozwalające implementować komunikację aplikacji z infrastrukturą cache), w tym: a) Java, b) technologia.net, c) C/C++. 2) Wsparcie funkcjonalności związanej z przechowywaniem sesji (persystencja sesji http, kontekstu usług typu Servlet oraz kontekstu usług typu Session EJB) dla następujących kontenerów aplikacyjnych: a) Tomcat 6, b) IBM Websphere v7, c) Oracle WebLogic Server 10.x, 3) Możliwość rozproszonego przetwarzania danych w pamięci cache. Oznacza to, że operacje na danych związane z przetwarzaniem odbywają się bezpośrednio w pamięci cache, bez konieczności transportu danych poza obręb pamięci cache; Strona 9 z 25

10 4) Możliwość przechowywania obiektów w strukturze kolekcji (Klucz, Wartość); 5) Wsparcie modelu obiektowego przechowywanych danych; 6) Oprogramowanie infrastruktury cache musi zapewniać mechanizm rozproszonej pamięci operacyjnej (ang. Single System Image); 7) Możliwość śledzenia zmian w danych znajdujących się w pamięci cache; 8) Możliwość równoległego wyszukiwania danych oraz możliwość tworzenia indeksów; 9) Oprogramowanie infrastruktury cache musi zapewniać funkcjonalność zapytań ciągłych, co oznacza możliwość otrzymywania zawsze aktualnych wyników wyszukiwania; 10) Możliwość rozproszonego (równoległego) agregowania danych w oparciu o filtry. Minimalnie muszą występować filtry (MINIMUM, MAXIMUM, AVERAGE, SUM, HAVING, GROUP BY, DISTINCT); 11) Możliwość stosowania / budowania własnych funkcji agregujących; 12) Oprogramowanie infrastruktury cache musi zapewniać mechanizmy wysokiej dostępności i ochrony danych przed awariami; 13) Możliwość klastrowania węzłów cache; 14) Oprogramowanie infrastruktury cache musi zapewniać płynne dodawanie i usuwanie węzłów klastra cache; 15) Oprogramowanie infrastruktury cache musi zapewniać przezroczystą obsługa awarii pojedynczych węzłów; 16) Oprogramowanie infrastruktury cache mimo występowania w konfiguracji wielowęzłowej przechowującej dane, nie może wymagać wspólnej przestrzeni (np. bazy danych, rejestru, itd.); 17) Oprogramowanie infrastruktury cache musi zapewniać mechanizm cache, pomiędzy aplikacją a drugą aplikacją lub bazą danych; 18) Oprogramowanie infrastruktury cache musi zapewniać persystencję przechowywanych danych w bazie danych; 19) Możliwość budowania własnych mechanizmów integrujących cache z dowolnymi repozytoriami danych (bazy danych, katalogi, własne aplikacje udostępniające dane poprzez API); 20) Oprogramowanie infrastruktury cache musi zapewniać mechanizm read through w komunikacji na linii aplikacja <-> cache <-> baza danych; 21) Oprogramowanie infrastruktury cache musi zapewniać mechanizm write through w komunikacji na linii aplikacja <-> cache <-> baza danych; 22) Oprogramowanie infrastruktury cache musi zapewniać mechanizm write behind w komunikacji na linii aplikacja <-> cache <-> baza danych; 23) Mechanizm write behind musi zapewniać możliwość kolejkowania zapisów do bazy danych; 24) Mechanizm kolejkowania żądań związanych z bazą danych musi być odporny na awarie (musi być automatycznie tworzona kopia zapasowa kolejek); 25) Możliwość rozszerzenia cache do pracy w sieci WAN (odporność Strona 10 z 25

11 na mniejsze przepustowości oraz większe opóźnienia); 26) Możliwość integracji z technologią Spring; 27) Możliwość integracji z technologią Hibernate; 28) Oprogramowanie infrastruktury cache musi zapewniać mechanizm wyzwalaczy (ang. triggers); 29) Możliwość usuwania z pamięci kopii danych po zapisaniu ich do persystentnego repozytorium danych (np. bazy danych); Dokumentacja Gwarancja Pełna dokumentacja producenta w języku polskim lub angielskim standardowo dostarczana przez producenta Serwera Aplikacji. 1) Zamawiający wymaga 3-letniej gwarancji obejmującej wsparcie techniczne z możliwością przedłużenia o 12 miesięcy, a następnie o kolejnych 12 miesięcy; 2) Usługi gwarancyjne realizowane będą: a) w siedzibie zamawiającego, przy czym koszty dojazdu ponosi wykonawca, b) zdalnie z zachowaniem zasad określonych w paragrafie 12 ust.24 IPU; 3) W ramach gwarancji zamawiający wymaga: a) zapewnienia funkcjonowania Oprogramowania Serwera Aplikacji, jak również jego prawidłowej współpracy z pozostałymi komponentami Platformy Sprzętowo Programowej, zgodnie z wymaganiami określonymi w niniejszym Opisie Przedmiotu Zamówienia oraz zgodnie z Dokumentacją, b) nieodpłatnego usuwania Wad, c) usuwania luk bezpieczeństwa, d) utrzymania zgodności Oprogramowania Serwera Aplikacji z obowiązującym prawem, e) zapewnienia wsparcia technicznego dotyczącego instalacji, konfiguracji i funkcjonowania Oprogramowania Serwera Aplikacji, f) zdalnego wspomagania zamawiającego w zakresie czynności związanych z identyfikacją i/lub usuwaniem Wad, między innymi w postaci konsultacji telefonicznych i mailowych, g) zapewnienia, że realizacja prac mających na celu usuwanie Wad nie zakłóci pozostałej funkcjonalności Platformy oraz innych systemów zamawiającego powiązanych z Platformą, h) przekazywania i instalacji uzgodnionych z zamawiającym i przetestowanych Aktualizacji Oprogramowania Serwera Aplikacji, bezzwłocznie po ich wejściu do obrotu (udostępnienia na rynku) celem zapewnienia poprawnego funkcjonowania Platformy, i) zapewnienia dostępu poprzez Internet do baz wiedzy producentów Oprogramowania, zawierających m.in. informacje i porady techniczne, wykazy najczęściej spotykanych problemów i sposoby ich rozwiązywania, j) dostarczenia narzędzia pozwalającego na zgłaszanie oraz obsługę zgłoszeń gwarancyjnych. Usuwanie Wad Oprogramowania Serwera Aplikacji realizowane będzie w następujących terminach: Strona 11 z 25

12 1) W przypadku Awarii: b) czas reakcji: niezwłocznie, nie później niż 4 godziny od czasu przyjęcia c) rozwiązanie zastępcze: niezwłocznie, nie później niż 8 godzin od czasu przyjęcia d) czas naprawy: niezwłocznie, nie później niż 48 godzin od czasu przyjęcia zgłoszenia. 2) W przypadku Błędu: w roku b) czas reakcji: niezwłocznie, nie później niż 1 dzień od dnia przyjęcia c) czas naprawy: niezwłocznie, nie później niż 7 dni od dnia przyjęcia zgłoszenia. 3) W przypadku Usterki: 3. Oprogramowanie Baz Danych Komponent w roku b) czas reakcji: niezwłocznie, nie później niż 7 dni od dnia przyjęcia zgłoszenia c) czas naprawy: niezwłocznie, nie później niż 25 dni od dnia przyjęcia zgłoszenia. Minimalne wymagania Licencja Licencje oprogramowania bazy danych ORACLE 12c w wersji Standard Edition (SE) na: 1 procesor bez limitu na liczbę Użytkowników dla środowiska produkcyjnego oraz 1 procesor bez limitu na liczbę Użytkowników dla środowiska testowego, lub równoważne. Gwarancja 1) Zamawiający wymaga 3-letniej gwarancji obejmującej wsparcie techniczne z możliwością przedłużenia o 12 miesięcy, a następnie o kolejnych 12 miesięcy. 2) Usługi gwarancyjne realizowane będą: a) w siedzibie zamawiającego, przy czym koszty dojazdu ponosi wykonawca, b) zdalnie z zachowaniem zasad określonych w paragrafie 12 ust.24 IPU; 3) W ramach gwarancji zamawiający wymaga: a) zapewnienia funkcjonowania Oprogramowania Baz Danych, jak również jego prawidłowej współpracy z pozostałymi komponentami Platformy Sprzętowo Programowej, zgodnie z wymaganiami określonymi w niniejszym Opisie Przedmiotu Zamówienia oraz zgodnie z Dokumentacją, b) nieodpłatnego usuwania Wad, c) usuwania luk bezpieczeństwa, d) utrzymania zgodności Oprogramowania Baz Danych z obowiązującym Strona 12 z 25

13 prawem, e) zapewnienia wsparcia technicznego dotyczącego instalacji, konfiguracji i funkcjonowania Oprogramowania Baz Danych, f) zdalnego wspomagania zamawiającego w zakresie czynności związanych z identyfikacją i/lub usuwaniem Wad, między innymi w postaci konsultacji telefonicznych i mailowych. g) zapewnienia, że realizacja prac mających na celu usuwanie Wad nie zakłóci pozostałej funkcjonalności Platformy oraz innych systemów zamawiającego powiązanych z Platformą, h) przekazywania i instalacji uzgodnionych z zamawiającym i przetestowanych Aktualizacji Oprogramowania Baz Danych, bezzwłocznie po ich wejściu do obrotu (udostępnienia na rynku) celem zapewnienia poprawnego funkcjonowania Platformy. i) zapewnienia dostępu poprzez Internet do baz wiedzy producentów Oprogramowania, zawierających m.in. informacje i porady techniczne, wykazy najczęściej spotykanych problemów i sposoby ich rozwiązywania. j) dostarczenia narzędzia pozwalającego na zgłaszanie oraz obsługę zgłoszeń gwarancyjnych. Usuwanie Wad Oprogramowania Baz Danych realizowane będzie w następujących terminach: W przypadku Awarii: b) czas reakcji: niezwłocznie, nie później niż 4 godziny od czasu przyjęcia c) rozwiązanie zastępcze: niezwłocznie, nie później niż 8 godzin od czasu przyjęcia d) czas naprawy: niezwłocznie, nie później niż 48 godzin od czasu przyjęcia zgłoszenia; W przypadku Błędu: b) czas reakcji: niezwłocznie, nie później niż 1 dzień od dnia przyjęcia c) czas naprawy: niezwłocznie, nie później niż 7 dni od dnia przyjęcia zgłoszenia; W przypadku Usterki: b) czas reakcji: niezwłocznie, nie później niż 7 dni od dnia przyjęcia c) czas naprawy: niezwłocznie, nie później niż 25 dni roboczych od dnia przyjęcia zgłoszenia. 4. Warunki równoważności dla Oprogramowania Baz Danych Dopuszcza się zaoferowanie produktów równoważnych do produktu określonego w punkcie 3, przy Strona 13 z 25

14 czym, przez równoważność należy rozumieć że: Komponent Warunki licencji i asysty technicznej Minimalne wymagania W każdym aspekcie licencjonowania są nie gorsze niż dla produktu określonego w pkt 3. Funkcjonalność Funkcjonalność (w tym poziom bezpieczeństwa) oprogramowania równoważnego nie może być gorsza od funkcjonalności oprogramowania określonego w pkt 3. Cechy 1) Oprogramowanie musi być skalowane dla rozwiązań opartych o architekturę trójwarstwową - możliwość uruchomienia wielu sesji bazy danych przy wykorzystaniu jednego połączenia z serwera aplikacyjnego do serwera bazy danych; 2) Oprogramowanie musi być skalowalne do spełnienia docelowych wymagań jakościowych zakładanych przez Zamawiającego; 3) Oprogramowanie musi być dostępne na popularne, współczesne platformy sprzętowe i systemowe - 64-bitowe platformy Unix (HP-UX dla Itanium, Solaris dla procesorów SPARC/x86-64, IBM AIX), Linux 32-bit i 64-bit (np. SLES 11), MS Windows 32-bit i 64-bit. Oprogramowanie musi mieć identyczne funkcjonalności serwera bazy danych na platformy, o których mowa w niniejszej literze; 4) Oprogramowanie musi charakteryzować się niezależnością platformy systemowej dla oprogramowania klienckiego/serwera aplikacyjnego od platformy systemowej bazy danych; 5) Oprogramowanie musi zapewniać możliwość przeniesienia (migracji) struktur bazy danych i danych pomiędzy platformami określonymi w lit. c, bez konieczności rekompilacji aplikacji bądź migracji środowiska aplikacyjnego; 6) Oprogramowanie musi wspierać przetwarzanie transakcyjne według reguł ACED (Atomicity, Consistency, Independency, Durability) z zachowaniem spójności i maksymalnego możliwego stopnia współbieżności. Mechanizm izolowania transakcji powinien pozwalać na spójny odczyt modyfikowanego obszaru danych bez wprowadzania blokad, z kolei spójny odczyt nie powinien blokować możliwości wykonywania zmian. Oznacza to, że modyfikowanie wierszy nie może blokować ich odczytu, z kolei odczyt wierszy nie może ich blokować do celów modyfikacji. Jednocześnie, spójność odczytu musi gwarantować uzyskanie rezultatów zapytań odzwierciedlających stan danych z chwili jego rozpoczęcia, niezależnie od modyfikacji przeglądanego zbioru danych; 7) Oprogramowanie nie może mieć limitów na ilość przechowywanych danych -zarówno tekstowych, jak i multimedialnych (w zakresie posiadanych zasobów sprzętowych); 8) Oprogramowanie nie może mieć formalnych ograniczeń na liczbę tabel i indeksów w bazie danych oraz na ich rozmiar (liczbę wierszy), 9) Oprogramowanie musi wspierać języki: java oraz xml; 10) Oprogramowanie powinno umożliwiać wymuszanie złożoności hasła użytkownika, wymuszanie czasu życia hasła, sprawdzanie historii haseł, blokowanie konta przez administratora, bądź w przypadku przekroczenia Strona 14 z 25

15 limitu nieudanych logowań; 11) Przywileje użytkowników bazy danych powinny być określane za pomocą przywilejów systemowych (np. prawo do podłączenia się do bazy danych - czyli utworzenia sesji, prawo do tworzenia tabel, itd.) oraz przywilejów dostępu do obiektów aplikacyjnych (np. odczytu/modyfikacji tabel, wykonania procedury). Oprogramowanie musi umożliwiać nadawanie przywilejów systemowych za pośrednictwem mechanizmu grup użytkowników / ról bazodanowych. W danej chwili, użytkownik może mieć aktywny dowolny podzbiór nadanych ról bazodanowych; 12) Oprogramowanie musi mieć możliwość wykonywania i katalogowania kopii bezpieczeństwa bezpośrednio przez serwer bazy danych, możliwość zautomatyzowanego usuwania zbędnych kopii bezpieczeństwa przy zachowaniu odpowiedniej liczby kopii nadmiarowych - stosownie do założonej polityki wykonywania kopii zapasowych (backup'ów), możliwość integracji z powszechnie stosowanymi systemami backupu (np. Symantec Netbackup, EMC, IBM Tivoli, HP Data Protector, itd.). Wykonywanie kopii bezpieczeństwa powinno być możliwe w trybie offline oraz w trybie online pracy bazy danych; 13) Oprogramowanie powinno umożliwiać odzyskanie stanu danych z chwili wystąpienia awarii bądź cofnąć stan bazy danych do punktu w czasie sprzed awarii. W przypadku odtwarzania do stanu z chwili wystąpienia awarii, odtwarzaniu może podlegać cała baza danych bądź pojedyncze pliki danych. 14) oprogramowanie musi posiadać mechanizm umożliwiający klastrowanie - ORACLE RAC lub równoważny. Dokumentacja Pełna dokumentacja producenta w języku polskim lub angielskim standardowo dostarczana przez producenta Oprogramowania Bazy Danych. Gwarancja Nie gorsza niż dla produktu określonego w pkt Oprogramowanie wirtualizacyjne Komponent Licencja Środowiska Serwer Bazodanowy Środowiska Serwer Aplikacyjny Minimalne wymagania Licencja na oprogramowanie wirtualizacyjne umożliwiające w ramach dostarczonych przez wykonawcę licencji na oprogramowanie standardowe, zainstalowanie na dostarczonych serwerach oraz korzystanie z niezależnych środowisk w konfiguracji. 1) Środowisko Produkcyjne wykorzystujące minimalnie 1 procesor; 2) Środowisko Testowe o minimalnych wymaganiach wydajnościowych (korzystające z drugiego procesora). 1) Środowisko Produkcyjne wykorzystujące minimalnie 1 procesor. 2) Środowisko Testowe o minimalnych wymaganiach wydajnościowych. (korzystające w części (min. 2 rdzenie) lub w całości z drugiego procesora). Oświadczenia Wykonawca dostarczy oświadczenie/a producenta / producentów oprogramowania potwierdzające prawo do korzystania z oprogramowania w zaproponowanej konfiguracji w ramach dostarczonych licencji. Strona 15 z 25

16 Dokumentacja Gwarancja Pełna dokumentacja producenta w języku polskim lub angielskim standardowo dostarczana przez producenta Oprogramowania Wirtualizacyjnego. 1) Zamawiający wymaga 3-letniej gwarancji obejmującej wsparcie techniczne z możliwością przedłużenia o 12 miesięcy, a następnie o kolejnych 12 miesięcy; 2) Usługi gwarancyjne realizowane będą: a) w siedzibie zamawiającego, przy czym koszty dojazdu ponosi wykonawca, b) zdalnie z zachowaniem zasad określonych w paragrafie 12 ust.24 IPU; 3) W ramach gwarancji zamawiający wymaga: c) zapewnienia funkcjonowania Oprogramowania Wirtualizacyjnego, jak również jego prawidłowej współpracy z pozostałymi komponentami Platformy Sprzętowo Programowej, zgodnie z wymaganiami określonymi w niniejszym Opisie Przedmiotu Zamówienia oraz zgodnie z Dokumentacją, d) nieodpłatnego usuwania Wad, e) usuwania luk bezpieczeństwa, f) utrzymania zgodności Oprogramowania Wirtualizacyjnego z obowiązującym prawem, g) zapewnienia wsparcia technicznego dotyczącego instalacji, konfiguracji i funkcjonowania Oprogramowania Wirtualizacyjnego, h) zdalnego wspomagania zamawiającego w zakresie czynności związanych z identyfikacją i/lub usuwaniem Wad, między innymi w postaci konsultacji telefonicznych i mailowych, i) zapewnienia, że realizacja prac mających na celu usuwanie Wad nie zakłóci pozostałej funkcjonalności Platformy oraz innych systemów zamawiającego powiązanych z Platformą, j) przekazywania i instalacji uzgodnionych z zamawiającym i przetestowanych Aktualizacji Oprogramowania Wirtualizacyjnego, bezzwłocznie po ich wejściu do obrotu (udostępnienia na rynku) celem zapewnienia poprawnego funkcjonowania Platformy, k) zapewnienia dostępu poprzez Internet do baz wiedzy producentów Oprogramowania, zawierających m.in. informacje i porady techniczne, wykazy najczęściej spotykanych problemów i sposoby ich rozwiązywania, l) dostarczenia narzędzia pozwalającego na zgłaszanie oraz obsługę zgłoszeń gwarancyjnych, Usuwanie Wad Oprogramowania wirtualizacyjnego realizowane będzie w następujących terminach: 1) W przypadku Awarii: b) czas reakcji: niezwłocznie, nie później niż 4 godziny od czasu przyjęcia c) rozwiązanie zastępcze: niezwłocznie, nie później niż 8 godzin od czasu przyjęcia Strona 16 z 25

17 d) czas naprawy: niezwłocznie, nie później niż 48 godzin od czasu przyjęcia zgłoszenia; 2) W przypadku Błędu: b) czas reakcji: niezwłocznie, nie później niż 1 dzień od dnia przyjęcia c) czas naprawy: niezwłocznie, nie później niż 7 dni od dnia przyjęcia zgłoszenia; 3) W przypadku Usterki: b) czas reakcji: niezwłocznie, nie później niż 7 dni od dnia przyjęcia c) czas naprawy: niezwłocznie, nie później niż 25 dni od dnia przyjęcia zgłoszenia. 6. Serwer Bazodanowy Komponent Obudowa Minimalne wymagania Obudowa Rack o wysokości max 1U z możliwością instalacji do 8 dysków HotPlug wraz z kompletem wysuwanych szyn umożliwiających montaż w szafie rack i wysuwanie serwera do celów serwisowych oraz organizację kabli. Płyta główna Procesor Chipset Płyta główna z możliwością zainstalowania minimum dwóch procesorów cztero, sześcio lub ośmiordzeniowych. Płyta główna musi być zaprojektowana przez producenta serwera. Dwa procesory (posiadające max 8 rdzeni każdy) klasy x86 dedykowane do pracy z zaoferowanym serwerem umożliwiające osiągnięcie wyniku min. 659 punktów w teście SPECint_rate_base2006 dostępnym na stronie Dedykowany do pracy z zaoferowanym serwerem 64GB pamięci RAM (4 x 16GB) RDIMM o częstotliwości pracy 1866MHz Pamięć RAM Płyta powinna obsługiwać do min. 768GB, na płycie głównej powinno znajdować się min. 24 sloty przeznaczone dla pamięci Możliwe zabezpieczenia pamięci: Memory Rank Sparing, Memory Mirror, Lockstep Sloty PCI Express Karta graficzna Wbudowane porty Min. 2 x PCI-Express trzeciej generacji Zintegrowana karta graficzna umożliwiająca rozdzielczość min. 1280x1024 Min. 5 portów USB 2.0, min.1 port VGA, min.1 port RS232 Strona 17 z 25

18 Interfejsy sieciowe Wewnętrzny moduł SD Kontroler dysków Wbudowana czteroportowa karta sieciowa posiadająca 2 porty o przepustowości 10 Gigabit Ethernet oraz 2 porty o przepustowości Gigabit Ethernet. Zamawiający dopuszcza dostarczenie dodatkowej karty sieciowej pod warunkiem, że serwer będzie posiadał dodatkowy Slot PCI Express (min. 3) Możliwość zainstalowania wewnętrznego modułu z redundantnymi kartami SD i/lub klucza USB. Zainstalowany sprzętowy kontroler dyskowy, posiadający min. 512MB nie ulotnej pamięci cache, umożliwiającego konfiguracje poziomów RAID : 0, 1, 5, 6, 10, 50, 60 Możliwość instalacji dysków twardych SATA, SAS, NearLine SAS i SSD. Dyski twarde Zainstalowane 8 dysków twardych o pojemności min. 300GB SAS 10k RPM Napęd optyczny System diagnostyczny Zasilacze Wentylatory Bezpieczeństwo Karta zarządzająca Wbudowany napęd DVD Panel LCD lub LED umieszczony na froncie obudowy, umożliwiający wyświetlenie informacji o stanie procesora, pamięci, dysków, BIOS u, zasilaniu. Redundantne zasilacze hot plug o mocy maks. 750W każdy Redundantne wentylatory hot plug Zintegrowany z płytą główną moduł TPM. Wbudowany czujnik otwarcia obudowy współpracujący z BIOS i kartą zarządzającą. Zainstalowana niezależna od zainstalowanego na serwerze systemu operacyjnego karta posiadająca dedykowany port RJ-45 Gigabit Ethernet umożliwiająca: - zdalny dostęp do graficznego interfejsu Web karty zarządzającej - zdalne monitorowanie i informowanie o statusie serwera (m.in. prędkości obrotowej wentylatorów, konfiguracji serwera, ), - szyfrowane połączenie (SSLv3) oraz autentykacje i autoryzację użytkownika, - możliwość podmontowania zdalnych wirtualnych napędów, - wirtualną konsolę z dostępem do myszy, klawiatury, - wsparcie dla IPv6, - wsparcie dla WSMAN (Web Service for Managament); SNMP; IPMI2.0, VLAN tagging, Telnet, SSH, - możliwość zdalnego monitorowania w czasie rzeczywistym poboru prądu przez serwer, - możliwość zdalnego ustawienia limitu poboru prądu przez konkretny serwer, - integracja z Active Directory, - możliwość obsługi przez dwóch administratorów jednocześnie, - wsparcie dla dynamic DNS, - wysyłanie do administratora maila z powiadomieniem o awarii lub zmianie Strona 18 z 25

19 Certyfikaty Dokumentacja Gwarancja konfiguracji sprzętowej, - możliwość podłączenia lokalnego poprzez złącze RS-232, - automatyczne przywracanie ustawień serwera, kart sieciowych, BIOS, wersji firmware w przypadku awarii i wymiany któregoś z komponentów (w tym kontrolera RAID, kart sieciowych, płyty głównej) zapisanych na dedykowanej karcie flash o pojemności min. 16 GB zainstalowanej na karcie zarządzającej, - możliwość partycjonowania dedykowanej karty flash. Serwer musi być wyprodukowany zgodnie z normą ISO-9001 oraz ISO Serwer musi posiadać deklaracja CE. Oferowany serwer musi znajdować się na liście Windows Server Catalog i posiadać status Certified for Windows dla systemów Microsoft Windows Server 2008 R2 x64, x64, x86, Microsoft Windows Server 2012 R2 x64, x64 Zamawiający wymaga dokumentacji w języku polskim lub angielskim. Możliwość telefonicznego sprawdzenia konfiguracji sprzętowej serwera oraz warunków gwarancji po podaniu numeru seryjnego bezpośrednio u producenta lub jego przedstawiciela. 1) Zamawiający wymaga 3-letniej gwarancji obejmującej wsparcie techniczne na serwer z możliwością przedłużenia o 12 miesięcy, a następnie o kolejnych 12 miesięcy. 2) Usługi gwarancyjne realizowane będą: a) w siedzibie zamawiającego, przy czym koszty dojazdu ponosi wykonawca, b) zdalnie z zachowaniem zasad określonych w paragrafie 12 ust.24 IPU, c) w uzasadnionych przypadkach poza siedzibą zamawiającego. W przypadku wystąpienia konieczności naprawy sprzętu poza siedzibą zamawiającego, wykonawca zapewni odbiór na własny koszt wadliwego sprzętu i dostawę na własny koszt naprawionego sprzętu. 3) W ramach gwarancji zamawiający wymaga: a) posiadania przez firmę serwisującą ISO 9001:2000 na świadczenie usług serwisowych oraz autoryzacji producenta serwera dokumenty potwierdzające należy załączyć do oferty, b) zapewnienia funkcjonowania serwera zgodnie z wymaganiami określonymi niniejszym Opisie Przedmiotu Zamówienia oraz zgodnie z Dokumentacją, c) nieodpłatnego usuwania Wad ujawnionych po odbiorze końcowym, d) zapewnienia dostępności części zamiennych do oferowanego Sprzętu przez co najmniej 5 lat po zakończeniu produkcji, e) usuwania luk bezpieczeństwa, f) zapewnienia wsparcia technicznego dotyczącego instalacji, konfiguracji i funkcjonowania serwera, g) zdalnego wspomagania zamawiającego w zakresie czynności związanych z identyfikacją i/lub usuwaniem Wad, między innymi w postaci konsultacji telefonicznych i mailowych, h) zapewnienia, że realizacja prac mających na celu usuwanie Wad nie zakłóci pozostałej funkcjonalności Platformy oraz innych systemów zamawiającego powiązanych z Platformą, Strona 19 z 25

20 i) przekazywania i instalacji uzgodnionych z zamawiającym i przetestowanych Aktualizacji Oprogramowania bezzwłocznie po ich wejściu do obrotu (udostępnienia na rynku) celem zapewnienia poprawnego funkcjonowania Platformy, j) zapewnienia dostępu poprzez Internet do bazy wiedzy producenta serwera BD oraz serwera AS, zawierających m.in. informacje i porady techniczne, wykazy najczęściej spotykanych problemów i sposoby ich rozwiązywania, k) oświadczenia producenta serwera, że w przypadku niewywiązywania się z obowiązków gwarancyjnych oferenta lub firmy serwisującej, przejmie na siebie wszelkie zobowiązania związane z serwisem, l) pozostawienia na własność zamawiającego dysków twardych w razie ich awarii. Usuwanie Wad Serwera Bazodanowego realizowane będzie w następujących terminach: 1) W przypadku Awarii: b) czas reakcji: niezwłocznie, nie później niż 4 godziny od czasu przyjęcia c) rozwiązanie zastępcze: niezwłocznie, nie później niż 8 godzin od czasu przyjęcia d) czas naprawy: niezwłocznie, nie później niż 48 godzin od czasu przyjęcia zgłoszenia; 2) W przypadku Błędu: b) czas reakcji: niezwłocznie, nie później niż 1 dzień od dnia przyjęcia c) czas naprawy: niezwłocznie, nie później niż 7 dni od dnia przyjęcia zgłoszenia; 3) W przypadku Usterki: b) czas reakcji: niezwłocznie, nie później niż 7 dni od dnia przyjęcia c) czas naprawy: niezwłocznie, nie później niż 25 dni od dnia przyjęcia zgłoszenia. 7. Serwer Aplikacji Komponent Obudowa Minimalne wymagania Obudowa Rack o wysokości max 1U z możliwością instalacji do 8 dysków HotPlug wraz z kompletem wysuwanych szyn umożliwiających montaż w szafie rack i wysuwanie serwera do celów serwisowych oraz organizację kabli. Strona 20 z 25