SPIS TREŚCI

TZ/271/11/14

SPECYFIKACJA ISTOTNYCH WARUNKÓW ZAMÓWIENIA

w postępowaniu o udzielenie zamówienia publicznego prowadzonym w trybie przetargu nieograniczonego

„Opiekę serwisową oprogramowania ORACLE (Tuxedo, SALT, eLink), nabycie dodatkowych licencji na oprogramowania: ORACLE Tuxedo (lub równoważych), ORACLE SALT (lub równoważnych), dodatkowych licencji na oprogramowanie serwera aplikacyjnego JEE oraz usługę migracji oprogramowania ORACLE“

Wartość zamówienia przekracza równowartość kwoty

134.000 EURO

Warszawa 2014 r.

SPIS TREŚCI

ROZDZIAŁ I INFORMACJE OGÓLNE

I. INFORMACJA O ZAMAWIAJĄCYM

II. TRYB UDZIELENIA ZAMÓWIENIA I WARTOŚĆ ZAMÓWIENIA

III. OFERTY CZĘŚCIOWE, WARIANTOWE, RÓWNOWAŻNE

IV. FORMA PRZEKAZYWANIA INFORMACJI, OŚWIADCZEŃ I DOKUMENTÓW W POSTĘPOWANIU ORAZ KOPII ODWOŁAŃ

V. OSOBY UPRAWNIONE DO KONTAKTÓW Z WYKONAWCAMI

VI. ZAMÓWIENIE UZUPEŁNIAJĄCE

VII. INFORMACJE DODATKOWE

ROZDZIAŁ II OPIS PRZEDMIOTU ZAMÓWIENIA I TERMIN WYKONANIA

I. PRZEDMIOT ZAMÓWIENIA

II.TERMIN WYKONANIA ZAMÓWIENIA, WARUNKI PŁATNOŚCI

ROZDZIAŁ III WYSOKOŚĆ I ZASADY WNIESIENIA WADIUM

I. WYSOKOŚĆ WADIUM

II. FORMA WADIUM

III. TERMIN I MIEJSCE WNIESIENIA WADIUM

IV. ZWROT WADIUM

V. ZATRZYMANIE WADIUM

ROZDZIAŁ IV WARUNKI UDZIAŁU W POSTĘPOWANIU, OPIS SPEŁNIENIA WARUNKÓW UDZIAŁU W POSTĘPOWANIU, OFERTA ORAZ DOKUMENTY WYMAGANE OD WYKONAWCY

I. WARUNKI UDZIAŁU W POSTĘPOWANIU

II. WYMOGI FORMALNE OFERTY

III. WYMAGANE DOKUMENTY

IV. ZASADY UDZIAŁU W POSTĘPOWANIU WYKONAWCÓW WYSTĘPUJĄCYCH WSPÓLNIE

V. FORMA DOKUMENTÓW

VI. OPAKOWANIE OFERTY

VII. OPIS SPOSOBU DOKONYWANIA OCENY SPEŁNIANIA WARUNKÓW UDZIAŁU W POSTĘPOWANIU

ROZDZIAŁ V OPIS SPOSOBU OBLICZENIA CENY OFERTY

ROZDZIAŁ VI INFORMACJE O MIEJSCU I TERMINIE SKŁADANIA I OTWARCIA OFERT

I.MIEJSCE I TERMIN SKŁADANIA OFERT

II. MIEJSCE I TERMIN OTWARCIA OFERT

III. PUBLICZNE OTWARCIE OFERT

IV.TERMIN ZWIĄZANIA OFERTĄ

V. ZMIANA I WYCOFANIE OFERTY

ROZDZIAŁ VII KRYTERIA I ZASADY OCENY OFERT

I. TRYB OCENY OFERT

II. KRYTERIA WYBORU NAJKORZYSTNIEJSZEJ OFERTY

III.ZASADY OCENY OFERT WEDŁUG USTALONYCH KRYTERIÓW ROZDZIAŁ VIII ZABEZPIECZENIE NALEŻYTEGO WYKONANIA UMOWY ROZDZIAŁ IX WZÓR UMOWY

ROZDZIAŁ X POUCZENIE O ŚRODKACH OCHRONY PRAWNEJ

ROZDZIAŁ XI FORMALNOŚCI PO WYBORZE OFERTY W CELU ZAWARCIA UMOWY

I. OGŁOSZENIE O WYNIKU POSTĘPOWANIA

II. WARUNKI ZAWARCIA UMOWY

ROZDZIAŁ XII ZMIANA UMOWY

Rozdział I INFORMACJE OGÓLNE

I. INFORMACJA O ZAMAWIAJĄCYM

Zamawiającym jest Zakład Ubezpieczeń Społecznych z siedzibą w Warszawie, ul. Szamocka 3, 5, 00 - 000 Xxxxxxxx, tel. 00 000 00 00, faks 00 000 00 00/36.

II. TRYB UDZIELENIA ZAMÓWIENIA I WARTOŚĆ ZAMÓWIENIA

1. Postępowanie o udzielenie zamówienia publicznego prowadzone jest w trybie przetargu nieograniczonego na podstawie przepisów ustawy z dnia 29 stycznia 2004 r. – Prawo zamówień publicznych, zwana dalej „ustawą” (Dz. U. z 2013 r. poz. 907 z późn. zm.).

2. Wartość zamówienia:

Wartość zamówienia przekracza wyrażoną w złotych równowartość kwoty 134.000 euro, o której mowa w przepisach wydanych na podstawie art. 11 ust. 8 ustawy Pzp.

III. OFERTY CZĘŚCIOWE, WARIANTOWE, RÓWNOWAŻNE

1. Każdy Wykonawca ma prawo złożyć tylko jedną ofertę.

2. Oferta musi obejmować całość przedmiotu zamówienia, wskazanego w Rozdziale II SIWZ.

3. Zamawiający nie dopuszcza możliwości składania ofert częściowych.

4. Zamawiający nie dopuszcza możliwości składania ofert wariantowych w rozumieniu art. 2 pkt 7 ustawy.

5. Zamawiający nie dopuszcza składania ofert równoważnych.

IV. FORMA PRZEKAZYWANIA INFORMACJI, OŚWIADCZEŃ I DOKUMENTÓW W POSTĘPOWANIU ORAZ KOPII ODWOŁAŃ

1. Oświadczenia, wnioski, zawiadomienia oraz informacje Zamawiający i Wykonawcy przekazują faksem lub mailem w postaci skanu dokumentu z podpisem z uwzględnieniem ust. 2. Nr faxu Zamawiającego: 22 667 17 33/36. Adres mail Zamawiającego: XxxxxxxxxxxXXX@xxx.xx

2. Forma pisemna zastrzeżona jest dla złożenia oferty wraz z załącznikami (dotyczy również uzupełnienia oferty – art. 26 ust. 3 ustawy), w tym oświadczeń i dokumentów potwierdzających spełnianie warunków udziału w postępowaniu oraz oświadczeń i dokumentów potwierdzających spełnianie przez oferowany przedmiot zamówienia wymagań określonych przez Zamawiającego, a także zmiany lub wycofania oferty.

3. Wykonawca potwierdza niezwłocznie fakt otrzymania oświadczenia, wniosku, zawiadomienia lub informacji poprzez podpisanie pierwszej strony dokumentu i jej odesłanie na faks lub mail Zamawiającego.

4. Jeżeli Wykonawca przekaże oświadczenia, wnioski, zawiadomienia oraz informacje faksem/mailem lub pisemnie za datę ich złożenia przyjmuje się datę wpływu pierwszego dokumentu - dokument uważa się za złożony w terminie jeżeli jego treść dotarła do adresata przed upływem wyznaczonego terminu, z zastrzeżeniem ust. 2.

5. W przypadku wniesienia odwołania, Odwołujący przesyła kopię odwołania Zamawiającemu za pomocą faksu – wyłącznie na nr 22 667 17 33 / 36 lub drogą elektroniczną – wyłącznie na adres: XxxxxxxxxxxXXX@xxx.xx

V. OSOBY UPRAWNIONE DO KONTAKTÓW Z WYKONAWCAMI

Osobą uprawnioną do kontaktu z Wykonawcami jest imię i nazwisko: Xxxxxxx Xxxxxxxx

stanowisko służbowe: Główny Specjalista tel.: 22 667–17–12, fax.: 22 667–17–33/36

godziny urzędowania: od poniedziałku do piątku w godz. 8.00-15.00

VI. ZAMÓWIENIE UZUPEŁNIAJĄCE

Zamawiający nie przewiduje udzielenia zamówienia uzupełniającego na przedmiot zamówienia określony w Rozdziale II niniejszej Specyfikacji.

VII. INFORMACJE DODATKOWE

1. Postępowanie, którego dotyczy niniejszy dokument oznaczone jest znakiem: TZ/370/11/14. Wskazane jest aby Wykonawcy we wszelkich kontaktach z Zamawiającym powoływali się na ten znak.

2. Istnieje możliwość uzyskania załączników do SIWZ niezbędnych do przygotowania oferty (załączniki nr 1, 3 i 4 do SIWZ), w wersji elektronicznej, pod warunkiem przekazania Zamawiającemu prośby wraz z podaniem adresu poczty elektronicznej (e- mail) Wykonawcy.

Rozdział II

OPIS PRZEDMIOTU ZAMÓWIENIA I TERMIN WYKONANIA

I. PRZEDMIOT ZAMÓWIENIA

1. Przedmiotem zamówienia jest:

1) świadczenie usług opieki serwisowej posiadanego przez Zamawiającego oprogramowania Oracle:

a) SALT - Processor Perpetual 16372742 - ilość 4

b) Tuxedo - Processor Perpetual 16372742- ilość 4

c) SALT - Processor Perpetual 17779780 – ilość 1

d) SALT - Processor Perpetual 18336228 – ilość 12

e) BEA eLink Adapter Mainframe Tier 1- Tiered Server Perpetual 15985105 – ilość 1

f) Tuxedo - Processor Perpetual 16668998 – ilość 118

g) SALT - Processor Perpetual OPL-191211-14150-JL - ilość 12,

2) nabycie dodatkowych licencji oprogramowania Oracle Tuxedo lub oprogramowania równoważnego z prawem użytkowania dla 16 rdzeni procesora wraz z świadczeniem usługi opieki serwisowej,

3) nabycie dodatkowych licencji oprogramowania Oracle SALT lub oprogramowania równoważnego z prawem użytkowania dla 8 rdzeni procesora wraz z świadczeniem usługi opieki serwisowej,

4) nabycie dodatkowych licencji na oprogramowanie serwera aplikacyjnego JEE wraz z narzędziami zarządzania i tworzenia usług oraz usługą opieki serwisowej,

5) usługa wsparcia migracji oprogramowania Oracle, której zakres opisano w § 3 ust. 19 Wzoru umowy stanowiącego Załącznik nr 2 do SIWZ. Usługa wsparcia migracji wykonywana będzie w ramach usługi opieki serwisowej.

2. Szczegółowy opis przedmiotu zamówienia został zawarty w Załączniku nr 5 do SIWZ.

3. Celem usługi opieki serwisowej oprogramowania Oracle posiadanego przez Zamawiającego jest zapewnienie najbardziej efektywnego, sprawnego, prawidłowego i profesjonalnego użytkowania oprogramowania objętego przedmiotem umowy przez Zamawiającego oraz systematyczne przekazywanie wiedzy, przeprowadzanie warsztatów, podnoszenie wiedzy wynikającej z utrzymania i przyszłego rozwoju wykorzystywanego przez Xxxxxxxxxxxxx oprogramowania, co pozwoli zbudować wewnętrzne centrum kompetencyjne. Usługi będą świadczone przez wykwalifikowane w zakresie technicznym osoby, które udostępni Wykonawca, zdolne do świadczenia pomocy serwisowej w zakresie oprogramowania Oracle będącego przedmiotem serwisowania, na poziomie zgodnym z wymaganiami umowy.

4. Wykonawca w dniu zawarcia umowy przekaże Zamawiającemu wykaz osób upoważnionych do rozwiązywania problemów i współpracy z Zamawiającym w celu realizacji umowy.

5. Wykonawca gwarantuje świadczenie usługi opieki serwisowej (wsparcia gwarancyjnego) i możliwość zgłaszania problemów drogą faksową lub elektroniczną w trybie ciągłym 24 godziny na dobę 7 dni w tygodniu 365 dni w roku.

6. Zgłoszenia awarii następować będzie z wykorzystaniem systemu obsługi zgłoszeń Zamawiającego (HP Service Manager). Za moment zgłoszenia awarii uznany będzie czas przesłania do Wykonawcy Formularza zgłoszenia awarii.

7. Do czasu integracji systemu obsługi zgłoszeń Zamawiającego z systemem obsługi zgłoszeń Wykonawcy, maksymalnie przez 2 miesiące od daty zawarcia Umowy, oraz w przypadku awarii systemu obsługi zgłoszeń Zamawiającego (HP Service Manager), o czym Zamawiający niezwłocznie poinformuje Wykonawcę lub systemu obsługi zgłoszeń Wykonawcy, Strony będą dokonywać zgłoszeń na Formularzu zgłoszenia awarii oraz wymieniać komunikaty za pośrednictwem poczty elektronicznej na uzgodnione adresy e- mail, z uwzględnieniem ust. 9. Wykonawca zobowiązany jest do niezwłocznego poinformowania Zamawiającego o awarii swojego systemu obsługi zgłoszeń. W przypadku braku takiej informacji, zgłoszenia awarii dokonane przez Zamawiającego przez system HP Service Manager do systemu Wykonawcy będą uznane za dostarczone. O fakcie integracji systemów Wykonawca pisemnie poinformuje Zamawiającego.

8. Adresy e-mail Zamawiającego i Wykonawcy służące do zgłaszania i obsługi awarii w przypadkach opisanych w ust. 7 Strony przekażą sobie wzajemnie w terminie 3 dni od daty zawarcia Umowy.

9. Wykonawca nie później niż w ciągu 30 minut od momentu otrzymania zgłoszenia potwierdzi przyjęcie zgłoszenia w formie takiej jak otrzymał zgłoszenie. W przypadku braku potwierdzenia w tym czasie Zamawiający kontaktuje się z Wykonawcą w celu wyjaśnienia przyczyny braku potwierdzenia oraz ustalenia ewentualnego sposobu rejestracji zgłoszenia u Wykonawcy.

10. Wykonanie zgłoszenia serwisowego zostanie potwierdzone podpisaniem protokołu a następnie przesłaniem potwierdzenia do systemu obsługi zgłoszeń Zamawiającego (HP Service Manager), w którym załączony będzie skan podpisanego Formularz wykonania zgłoszenia serwisowego. Czas otrzymania przez Zamawiającego potwierdzenia w systemie obsługi zgłoszeń Zamawiającego (HP Service Manager) będzie czasem wykonania zgłoszenia. Dopuszcza się opóźnienie w dosłaniu skanu podpisanego Formularza wykonania zgłoszenia serwisowego do systemu obsługi zgłoszeń Zamawiającego (HP Service Manager) do 2 dni roboczych Zamawiającego, jednak opóźnienie to nie zmienia czasu wykonania zgłoszenia.

11. W reakcji na problemy zgłoszone przez Zamawiającego, Wykonawca prześle szczegółowy plan swoich działań w związku z dokonanym zgłoszeniem:

1) problemu krytycznego - w ciągu 12 godzin zegarowych, od zgłoszenia przez Zamawiającego,

2) problemu niekrytycznego - w ciągu 48 godzin zegarowych, od zgłoszenia przez Zamawiającego,

3) status zgłoszenia problemu określa Zamawiający.

12. Wykonawca jest zobowiązany do przedstawienia informacji pisemnej (e-mail lub fax) o stanie zgłoszeń zawierającej co najmniej uszczegółowienie objawów, diagnozę, podjęte i planowane czynności naprawcze, przewidywany czas naprawy. W przypadku zgłoszenia problemu krytycznego, informacja pisemna o stanie zgłoszenia, będzie udzielana nie rzadziej niż raz na 48 godzin od momentu zgłoszenia, a w przypadku innych zgłoszeń nie rzadziej niż raz na 168 godzin od momentu zgłoszenia.

13. Wykonawca zobowiązuje się do dostarczenia poprawek wynikających z błędów oprogramowania (tzw. support pack’ów), aktualizacji oprogramowania (tzw. update’ów) lub nowych jego wersji zmieniających funkcjonalność (tzw. upgrade’ów), oraz zapewni Zamawiającemu wsparcie w trakcie ich instalacji w czasie obowiązywania umowy.

14. Wykonawca w dniu podpisania umowy zapewni ciągły dostęp do:

1) stron internetowych producenta oprogramowania z aktualną bazą wiedzy na temat oprogramowania Oracle będącego przedmiotem serwisowania;

2) inżynierów supportowych zdolnych do dokonywania zmian w kodzie oprogramowania Oracle oraz odbycia wizyt serwisowych w siedzibie Zamawiającego;

3) elektronicznej dystrybucji oprogramowania;

4) dokumentacji produktów.

15. Wykonawca zapewni Zamawiającemu e-mail`owe i telefoniczne konsultacje w zakresie oprogramowania Oracle oraz jego współpracy z platformami, na których jest osadzone, od poniedziałku do piątku z wyłączeniem świąt ustawowych w godzinach w godz. 8.00 – 16.00.

16. Wykonawca będzie sprawdzał i informował na bieżąco Zamawiającego o poprawności zainstalowanego oprogramowania Oracle w zakresie poziomu patchowania, aktualności i kompletności w stosunku do aktualnie obowiązującego najnowszego poziomu dla danej wersji.

17. Wykonawca, w 3, 6, 9 oraz 11 miesiącu od dnia zawarcia umowy - jest zobowiązany do dokonywania przeglądów konserwacyjnych oprogramowania, w szczególności na

następujących zasadach:

1) sprawdzanie poprawności oprogramowania Oracle w zakresie wersji, poziomu patchowania i kompletności,

2) analiza zapisów w logach pod kątem ewentualnych błędów, ostrzeżeń, niestandardowych i nieoptymalnych zachowań oprogramowania ze wskazaniem na częstotliwość ich występowania oraz istotność dla działania oprogramowania Oracle,

3) testowanie diagnostyczne, regulacje, strojenia oraz zabiegi konserwacyjne mające na celu utrzymanie oprogramowania w prawidłowym stanie,

4) wszystkie czynności mają być wykonane w sposób zgodny z zaleceniami producenta oprogramowania oraz niezbędny do zapewnienia jego poprawnej i wydajnej pracy,

5) zakończenie każdego z przeglądów konserwacyjnych zostanie potwierdzone raportem sporządzonym przez Wykonawcę (stanowiącym Załącznik nr 6 do umowy), zawierającym zakres wykonanych prac oraz zalecenia i wnioski końcowe.

18. Wykonawca zobowiązany jest do sporządzania i przekazywania Zamawiającemu raz w miesiącu zbiorczego Miesięcznego raportu z wykonanych usług opieki serwisowej oprogramowania Oracle.

19. Wykonawca dostarczy Miesięczny raport świadczenia usług oraz Raport z wykonania przeglądu konserwacyjnego nie później, niż do 5 dnia następnego miesiąca, po upływie okresu objętego raportem.

20. Zamawiający potwierdzi raport, o którym mowa w ust. 18 lub zgłosi do niego uwagi w terminie 3 dni od daty jego otrzymania.

21. Usługa opieki serwisowej świadczona przez Wykonawcę będzie realizowana w Centralnym Ośrodku Obliczeniowym (COO) i Oddziałach ZUS.

22. Wykonawca zapewni Zamawiającemu wsparcie proaktywne poprzez:

a. inwentaryzację usług Oracle i korzystających z nich aplikacji. Spodziewanym efektem ww. prac jest przygotowanie zestawienia usług Oracle działających w obrębie systemu KSI wraz ze wskazaniem na obsługujące je serwery, domeny Oracle, w których są uruchamiane oraz korzystające z nich aplikacje biznesowe. Inwentaryzacja będzie wykonywana dwa razy w ciągu roku (w piątym i w jedenastym miesiącu trwania umowy) i jej wynik będzie przedstawiany Zamawiającemu w postaci aktualnego zestawienia usług Oracle.

b. wsparcie przy migracji oprogramowania Oracle z obecnie posiadanej platformy (HP- UX dla procesorów Itanium) do platformy wskazanej przez Zamawiającego.

c. wsparcie przy podniesieniu wersji oprogramowania Oracle z obecnie posiadanej wersji do wersji wskazanej przez Zamawiającego.

d. wsparcie przy przeniesieniu wskazanych usług systemu KSI uruchomionych na Oracle na platformie docelowej.

e. kontrole jakości procesu migracji usług uruchamianych na Oracle poprzez kwartalne przeglądy prac i raporty wykonywane przez producenta oprogramowania pod kątem zachowania zgodności z rekomendacjami producenta i wymogami serwisowymi.

f. możliwość wsparcia procesu migracji, uruchomienia i stabilizacji środowiska docelowego przez inżynierów zdolnych do wykonywania czynności serwisowych w siedzibie Zamawiającego i posiadających możliwość diagnozowania kodu Oracle oraz wprowadzania do niego zmian.

g. wsparcie przy udostepnieniu usług działających w środowiskach Oracle dla korporacyjnej architektury SOA podczas przebudowy istniejących aplikacji KSI bądź tworzenia nowych funkcjonalności.

23. Wykonawca w ramach budowania centrum kompetencyjnego po stronie Zamawiającego w trakcie trwania umowy będzie systematycznie, w sposób ciągły - na żądanie Zamawiającego - przekazywał wiedzę dotyczącą wykorzystywanego oprogramowania

Oracle, sposobu rozwiązywania problemów serwisowych oraz metod związanych z jego rozwojem w środowisku informatycznym Zamawiającego.

24. Na zakończenie trwania umowy Wykonawca przeprowadzi zamknięte warsztaty, indywidualnie przygotowane dla maksymalnie 10 osób z uwzględnieniem środowiska informatycznego Zamawiającego, z administracji oprogramowania Oracle. Warsztaty zostaną zakończone imiennymi certyfikatami .

25. Wykonawca, który powołuje się na rozwiązania równoważne, musi podać w Formularzu cenowym pkt V Formularza ofertowego (Załącznik nr 1 do SIWZ) nazwę produktu / jego producenta oraz wykazać, że oferowane przez niego rozwiązania równoważne spełniają wymagania określone przez Zamawiającego, zgodnie z przepisem art. 30 ust. 5 ustawy Prawo zamówień publicznych.

26. Przedmiot zamówienia wg Wspólnego Słownika Zamówień (CPV):

48000000-8 - Pakiety oprogramowania i systemy informatyczne 72267000-4 - Usługi w zakresie konserwacji i napraw oprogramowania 72611000-6 - Usługi w zakresie wsparcia technicznego

II. TERMIN WYKONANIA I WARUNKI REALIZACJI ZAMÓWIENIA, PŁATNOŚĆ

1. Termin realizacji przedmiotu zamówienia:

1) świadczenie usług opieki serwisowej posiadanego przez Zamawiającego oprogramowania Oracle:

a) SALT - Processor Perpetual 16372742 - ilość 4

b) Tuxedo - Processor Perpetual 16372742- ilość 4

c) SALT - Processor Perpetual 17779780 – ilość 1

d) SALT - Processor Perpetual 18336228 – ilość 12

e) BEA eLink Adapter Mainframe Tier 1- Tiered Server Perpetual 15985105 – ilość 1

f) Tuxedo - Processor Perpetual 16668998 – ilość 118 w terminie 12 miesięcy od daty zawarcia umowy,

oraz

g) SALT - Processor Perpetual OPL-191211-14150-JL - ilość 12, w terminie od dnia zawarcia umowy, nie wcześniej jednak niż 28.12.2014 r., do końca świadczenia opieki serwisowej dla oprogramowania wskazanego w pkt. II.1.1) lit. a) - f).

2) nabycie dodatkowych licencji oprogramowania Oracle Tuxedo lub oprogramowania równoważnego z prawem użytkowania dla 16 rdzeni procesora wraz z świadczeniem usługi opieki serwisowej od daty podpisania protokołu odbioru licencji do końca świadczenia opieki serwisowej dla oprogramowania wskazanego w pkt. II.1.1) lit. a) - f),

3) nabycie dodatkowych licencji oprogramowania Oracle SALT lub oprogramowania równoważnego z prawem użytkowania dla 8 rdzeni procesora wraz z świadczeniem usługi opieki serwisowej od daty podpisania protokołu odbioru licencji do końca świadczenia opieki serwisowej dla oprogramowania wskazanego w pkt. II.1.1) lit. a) - f),

4) nabycie dodatkowych licencji na oprogramowanie serwera aplikacyjnego JEE wraz z narzędziami zarządzania i tworzenia usług oraz usługą opieki serwisowej od daty podpisania protokołu odbioru licencji do końca świadczenia opieki serwisowej dla oprogramowania wskazanego w pkt. II.1.1) lit. a) - f),

5) usługa wsparcia migracji oprogramowania Oracle, której zakres opisano w §3 ust. 19 wzoru umowy (Załącznik nr 2 do SIWZ) – wykonywana będzie w ramach usługi opieki serwisowej,

6) przekazanie dodatkowych licencji, o których mowa w pkt II.1.2) – 4), w terminie do 7 dni od daty zawarcia umowy.

2. Płatności:

1) Płatności za świadczenie usługi opieki serwisowej oprogramowania, o której mowa w pkt I.1.1), będą dokonywane z dołu w miesięcznych opłatach w terminie 30 dni od daty otrzymania przez Zamawiającego – Zakład Ubezpieczeń Społecznych – xx. Xxxxxxxx 0, 0, 00-000 Xxxxxxxx, Departament Zarządzania Systemami Informatycznymi (sekretariat) faktury prawidłowo wystawionej na podstawie podpisanego bez uwag Miesięcznego raportu świadczenia usług (Załącznik nr 2 do umowy);

2) Płatność za udzielenie dodatkowych licencji na oprogramowania, o którym mowa w pkt I.1.2) – 4), wraz ze świadczeniem opieki serwisowej od dnia podpisania protokołu odbioru licencji do końca terminu, o którym mowa w pkt I.1.1), będzie dokonana w terminie 30 dni od daty otrzymania przez Zamawiającego – Zakład Ubezpieczeń Społecznych, Departament Zarządzania Systemami Informatycznymi (sekretariat) faktury prawidłowo wystawionej na podstawie podpisanego bez uwag Protokołu odbioru licencji (Załącznik nr 9 do umowy);

3. Szczegółowe warunki realizacji zamówienia zostały zawarte we wzorze umowy, stanowiącym Załącznik nr 2 do niniejszej Specyfikacji.

Rozdział III

WYSOKOŚĆ I ZASADY WNIESIENIA WADIUM

I. WYSOKOŚĆ WADIUM

Zamawiający wymaga wniesienia wadium w kwocie: 503.700,00 zł (słownie złotych: pięćset trzy tysiące siedemset 00/100).

II. FORMA WADIUM

Wadium może być wniesione w jednej lub kilku z poniższych form:

1) pieniądzu,

2) poręczeniach bankowych lub poręczeniach spółdzielczej kasy oszczędnościowo- kredytowej, z tym że poręczenie kasy jest zawsze poręczeniem pieniężnym,

3) gwarancjach bankowych,

4) gwarancjach ubezpieczeniowych,

5) poręczeniach udzielonych przez podmioty, o których mowa w art. 6 b ust. 5 pkt 2 ustawy z dnia 9 listopada 2000 r. o utworzeniu Polskiej Agencji Rozwoju Przedsiębiorczości (tekst jedn. Xx. X. x 0000 x. Xx 00, poz. 275 ze zm.).

III. TERMIN I MIEJSCE WNIESIENIA WADIUM

1. Wadium należy wnieść przed upływem terminu składania ofert określonego w Rozdziale VI, podrozdział I pkt 1.

2. W przypadku wnoszenia wadium w pieniądzu ustaloną kwotę należy wpłacić na rachunek bankowy Zamawiającego w banku: PKO BP S.A. Nr: 81 1020 5590 0000 0602 9000 7017

Zaleca się, aby na przelewie umieścić informację: wadium do postępowania na „Opiekę serwisową oprogramowania ORACLE (Tuxedo, SALT, eLink), nabycie dodatkowych licencji na oprogramowania: ORACLE Tuxedo (lub równoważych), ORACLE SALT (lub równoważnych), dodatkowych licencji na oprogramowanie serwera aplikacyjnego JEE oraz usługę migracji oprogramowania ORACLE” znak: TZ/271/11/14.

3. Wadium winno znaleźć się na rachunku bankowym Zamawiającego przed upływem terminu składania ofert.

4. W przypadku wnoszenia wadium w pozostałych dopuszczalnych formach określonych w podrozdziale II oryginał należy złożyć w siedzibie Zamawiającego w Warszawie ul. Szamocka 3, 5 Departament Zamówień Publicznych, pok. 104 a (I piętro, skrzydło

„C”), a kserokopię dokumentu potwierdzającego wniesienie wadium zaleca się dołączyć do oferty.

5. Z dokumentu wadium wniesionego w formie gwarancji bankowej/ubezpieczeniowej powinno wynikać jednoznacznie gwarantowanie wypłat należności w sposób nieodwołalny, bezwarunkowy i na pierwsze żądanie Zamawiającego zawierające oświadczenie o okolicznościach stanowiących podstawę do żądania wypłaty należności.

6. Nie wniesienie wadium w wymaganym terminie (także na przedłużony okres związania ofertą), wysokości lub formie skutkuje wykluczeniem Wykonawcy z postępowania.

IV. ZWROT WADIUM

1. Zamawiający zwróci wadium wszystkim Wykonawcom niezwłocznie po wyborze oferty najkorzystniejszej lub unieważnieniu postępowania, z wyjątkiem Wykonawcy, którego oferta została wybrana jako najkorzystniejsza, z zastrzeżeniem ust. 2 działu V –

„Zatrzymanie Wadium”.

2. Wykonawcy, którego oferta została wybrana jako najkorzystniejsza, Zamawiający zwróci wadium niezwłocznie po zawarciu umowy w sprawie zamówienia publicznego oraz wniesieniu zabezpieczenia należytego wykonania umowy.

3. Zamawiający zwróci wadium niezwłocznie na pisemny wniosek Wykonawcy, który wycofał ofertę przed upływem terminu składania ofert.

4. Jeżeli wadium wniesiono w pieniądzu, Zamawiający zwraca je wraz z odsetkami wynikającymi z umowy rachunku bankowego, na którym było ono przechowywane, pomniejszonym o koszty prowadzenia rachunku oraz prowizji bankowej za przelew pieniędzy na rachunek Wykonawcy.

V. ZATRZYMANIE WADIUM

1. Wykonawca, którego oferta została wybrana, traci wadium wraz z odsetkami na rzecz Zamawiającego w sytuacjach, gdy:

1) odmówił podpisania umowy na warunkach określonych w ofercie,

2) nie wniósł wymaganego zabezpieczenia należytego wykonania umowy,

3) zawarcie umowy stało się niemożliwe z przyczyn leżących po stronie Wykonawcy.

2. Zamawiający zatrzymuje wadium wraz z odsetkami, jeżeli Wykonawca w odpowiedzi na wezwanie, o którym mowa w art. 26 ust. 3 ustawy, nie złożył dokumentów lub oświadczeń, o których mowa w art. 25 ust. 1 ustawy, lub pełnomocnictw, chyba że udowodni, że wynika to z przyczyn nieleżących po jego stronie.

Rozdział IV

WARUNKI UDZIAŁU W POSTĘPOWANIU, OPIS SPEŁNIENIA WARUNKÓW UDZIAŁU W POSTĘPOWANIU, OFERTA ORAZ DOKUMENTY WYMAGANE OD WYKONAWCY

I. WARUNKI UDZIAŁU W POSTĘPOWANIU

1. O udzielenie zamówienia ubiegać się mogą Wykonawcy, którzy spełniają warunki dotyczące:

1) posiadania uprawnień do wykonywania określonej działalności lub czynności, jeżeli przepisy prawa nakładają obowiązek ich posiadania;

2) posiadania wiedzy i doświadczenia;

3) dysponowania odpowiednim potencjałem technicznym oraz osobami zdolnymi do wykonania zamówienia;

4) sytuacji ekonomicznej i finansowej.

2. O udzielenie zamówienia ubiegać się mogą Wykonawcy, którzy nie podlegają wykluczeniu z postępowania o udzielenie zamówienia.

3. Wykonawcy mogą polegać na wiedzy i doświadczeniu, potencjale technicznym, osobach zdolnych do wykonania zamówienia lub zdolnościach finansowych innych podmiotów, niezależnie od charakteru prawnego łączących go z nimi stosunków.

II. WYMOGI FORMALNE OFERTY

1. Oferta musi spełniać następujące wymogi:

1) treść oferty musi odpowiadać treści Specyfikacji;

2) oferta musi zostać sporządzona w języku polskim w formie pisemnej, na maszynie do pisania, komputerze lub inną trwałą i czytelną techniką;

3) oferta i załączone do niej oświadczenia i dokumenty, wymagane przez Zamawiającego, sporządzone przez Wykonawcę muszą być podpisane; za podpisanie uznaje się własnoręczny podpis złożony (w sposób umożliwiający identyfikację osoby) przez osobę(-y) upoważnioną(-e) do reprezentowania Wykonawcy;

4) poprawki lub zmiany w ofercie, muszą być dokonane w sposób czytelny, parafowane własnoręcznie przez osobę(-y) podpisującą(-e) ofertę,

2. Zaleca się, aby:

1) każda strona oferty była parafowana przez osobę podpisującą ofertę;

2) wszystkie strony oferty wraz z załącznikami były ponumerowane oraz połączone w sposób trwały;

3) materiały nie wymagane przez Zamawiającego, tj. nie stanowiące oferty (druki i foldery reklamowe) były wyraźnie oznaczone i oddzielone od oferty;

4) osoba podpisująca ofertę opatrzyła swój podpis pieczątką imienną.

3. W przypadku, gdy informacje zawarte w ofercie stanowią tajemnicę przedsiębiorstwa w rozumieniu przepisów ustawy z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji (t. jedn. Xx. X. x 0000 x. Xx 000 poz. 1503 ze zm.), Wykonawca powinien to wyraźnie zastrzec w ofercie i odpowiednio oznaczyć zastrzeżone informacje.

Wskazane jest wyodrębnienie dokumentów zawierających zastrzeżone informacje.

Nie podlegają zastrzeżeniu informacje obejmujące: nazwę (firmę) oraz adres Wykonawcy, cenę oferty, termin wykonania zamówienia, okres gwarancji i warunki płatności.

III. WYMAGANE DOKUMENTY

1. Wykonawca składa wraz z ofertą następujące dokumenty i oświadczenia:

1.1. Oświadczenia i dokumenty potwierdzające spełnianie warunków udziału w postępowaniu:

1) oświadczenie potwierdzające spełnianie przez Wykonawcę warunków określonych w art. 22 ust. 1 ustawy, sporządzone wg wzoru stanowiącego Załącznik nr 3 do niniejszej Specyfikacji;

2) jeżeli Wykonawca polega na wiedzy i doświadczeniu, potencjale technicznym, osobach zdolnych do wykonania zamówienia lub zdolnościach finansowych innych podmiotów, niezależnie od charakteru prawnego łączących go z nimi stosunków, zobowiązany jest udowodnić Zamawiającemu, iż będzie dysponował zasobami niezbędnymi do realizacji zamówienia, w szczególności przedstawiając w tym celu pisemne zobowiązanie takich podmiotów do oddania mu do dyspozycji niezbędnych zasobów na okres korzystania z nich przy wykonywaniu zamówienia.

1.2. Oświadczenia i dokumenty o braku podstaw do wykluczenia z postępowania o udzielenie zamówienia:

1) oświadczenie o braku podstaw do wykluczenia, sporządzone wg wzoru stanowiącego załącznik nr 4 do niniejszej Specyfikacji;

2) aktualny odpis z właściwego rejestru lub z centralnej ewidencji i informacji o działalności gospodarczej, jeżeli odrębne przepisy wymagają wpisu do rejestru lub ewidencji, w celu wykazania braku podstaw do wykluczenia w oparciu o art. 24 ust. 1 pkt 2 ustawy, wystawiony nie wcześniej niż 6 miesięcy przed upływem terminu składania ofert;

płatności lub wstrzymanie w całości wykonania decyzji właściwego organu – wystawione nie wcześniej niż 3 miesiące przed upływem terminu składania ofert;

4) aktualne zaświadczenie właściwego oddziału Zakładu Ubezpieczeń Społecznych lub Kasy Rolniczego Ubezpieczenia Społecznego potwierdzające, że Wykonawca nie zalega z opłacaniem składek na ubezpieczenie zdrowotne i społeczne lub potwierdzenie, że uzyskał przewidziane prawem zwolnienie, odroczenie lub rozłożenie na raty zaległych płatności lub wstrzymanie w całości wykonania decyzji właściwego organu – wystawione nie wcześniej niż 3 miesiące przed upływem terminu składania ofert;

5) aktualna informacja z Krajowego Rejestru Karnego w zakresie określonym w art. 24 ust. 1 pkt 4 – 8 oraz 10 i 11 ustawy wystawiona nie wcześniej niż 6 miesięcy przed upływem terminu składania ofert;

6) aktualna informacja z Krajowego Rejestru Karnego w zakresie określonym w art. 24 ust. 1 pkt 9 ustawy wystawiona nie wcześniej niż 6 miesięcy przed upływem terminu składania ofert;

7) lista podmiotów należących do tej samej grupy kapitałowej o której mowa w art. 24 ust. 2 pkt 5 ustawy lub informacja o tym, że Wykonawca nie należy do grupy kapitałowej.

1.3. Inne wymagane oświadczenia i dokumenty:

1) w przypadku, gdy Wykonawcę reprezentuje pełnomocnik - pełnomocnictwo określające jego zakres i podpisane przez osoby uprawnione do reprezentacji Wykonawcy;

2) w przypadku, gdy ofertę składają wykonawcy ubiegający się wspólnie o udzielenie zamówienia wymagane jest załączenie dokumentu pełnomocnictwa określającego zakres umocowania pełnomocnika ustanowionego do reprezentowania ich w postępowaniu, stosownie do art. 23 ust. 2 ustawy;

3) dokument potwierdzający wniesienie wadium, jeżeli zostało wniesione w innej formie niż w pieniądzu (zaleca się dołączyć).

2. Jeżeli, w przypadku Wykonawcy mającego siedzibę na terytorium Rzeczypospolitej Polskiej, osoby, o których mowa w art. 24 ust. 1 pkt 5-8, 10 i 11 ustawy, mają miejsce zamieszkania poza terytorium Rzeczypospolitej Polskiej, Wykonawca składa w odniesieniu do nich zaświadczenie właściwego organu sądowego albo administracyjnego miejsca zamieszkania dotyczące niekaralności tych osób w zakresie określonym w art. 24 ust. 1 pkt 5-8, 10 i 11 ustawy, wystawione nie wcześniej niż 6 miesięcy przed upływem terminu składania ofert, z tym że w przypadku gdy w miejscu zamieszkania tych osób nie wydaje się takich zaświadczeń - zastępuje się je dokumentem zawierającym oświadczenie złożone przed właściwym organem sądowym, administracyjnym albo organem samorządu zawodowego lub gospodarczego miejsca zamieszkania tych osób, lub przed notariuszem.

3. Wykonawca zagraniczny

3.1. Wykonawca zagraniczny (mający siedzibę lub miejsce zamieszkania poza terytorium Rzeczypospolitej Polskiej) zamiast dokumentów wskazanych w pkt 1.2.:

1) ppkt 2), 3), 4), 6) – składa dokument lub dokumenty, wystawione w kraju, w którym ma siedzibę lub miejsce zamieszkania, potwierdzające odpowiednio, że:

a) nie otwarto jego likwidacji ani nie ogłoszono upadłości – wystawione nie wcześniej niż 6 miesięcy przed upływem terminu składania ofert,

b) nie zalega z uiszczaniem podatków, opłat, składek na ubezpieczenie społeczne i zdrowotne albo że uzyskał przewidziane prawem zwolnienie, odroczenie lub rozłożenie na raty zaległych płatności lub wstrzymanie w całości wykonania decyzji właściwego organu – wystawione nie wcześniej niż 3 miesiące przed upływem terminu składania ofert,

c) nie orzeczono wobec niego zakazu ubiegania się o zamówienie – wystawione nie wcześniej niż 6 miesięcy przed upływem terminu składania ofert;

2) pkt 5 - składa zaświadczenie właściwego organu sądowego lub administracyjnego miejsca zamieszkania osoby, której dokumenty dotyczą, w zakresie określonym w art. 24 ust. 1 pkt 4 - 8, 10 i 11 ustawy - wystawione nie wcześniej niż 6 miesięcy przed upływem terminu składania ofert.

3.2. Jeżeli w kraju miejsca zamieszkania osoby lub w kraju, w którym wykonawca ma siedzibę lub miejsce zamieszkania, nie wydaje się dokumentów wskazanych w pkt 3.1. zastępuje się je dokumentem zawierającym oświadczenie, w którym określa się także osoby uprawnione do reprezentacji wykonawcy, złożone przed właściwym organem sądowym, administracyjnym albo organem samorządu zawodowego lub gospodarczego odpowiednio kraju miejsca zamieszkania osoby lub kraju, w którym Wykonawca ma siedzibę lub miejsce zamieszkania, lub notariuszem – wystawione odpowiednio w terminach określonych w pkt 3.1.

IV. ZASADY UDZIAŁU W POSTĘPOWANIU WYKONAWCÓW WYSTĘPUJĄCYCH WSPÓLNIE

1. Wykonawcy ubiegający się wspólnie o udzielenie zamówienia ustanawiają pełnomocnika do reprezentowania ich w postępowaniu albo reprezentowania w postępowaniu i zawarcia umowy w sprawie zamówienia publicznego.

2. Wykonawcy, o których mowa w pkt 1, składają jedną ofertę, przy czym:

a) wymagane oświadczenia i dokumenty wskazane w podrozdziale III pkt 1.2 niniejszego Rozdziału składa każdy z Wykonawców,

b) oświadczenie potwierdzające spełnianie warunków określonych w art. 22 ust.1 ustawy

– wszyscy Wykonawcy wspólnie,

c) pozostałe dokumenty składają wszyscy Wykonawcy wspólnie.

V. FORMA DOKUMENTÓW

1. Wymagane dokumenty powinny być złożone w formie oryginału lub kserokopii potwierdzonej za zgodność z oryginałem przez osobę uprawnioną do reprezentowania Wykonawcy. W przypadku zaistnienia sytuacji, o której mowa w podrozdziale III

„Wymagane dokumenty” ust. 1, pkt 1.1 ppkt. 2. Wykonawca zobowiązany jest przedstawić pisemne zobowiązanie w formie oryginału lub kopii potwierdzonej notarialnie.

2. Za osoby uprawnione do reprezentowania Wykonawcy uznaje się osoby upoważnione do reprezentowania firmy, wskazane we właściwym rejestrze bądź w stosownym

pełnomocnictwie, które należy załączyć do oferty w oryginale lub kopii poświadczonej za zgodność z oryginałem przez osobę udzielającą pełnomocnictwa lub poświadczone notarialnie.

3. W przypadku, gdy załączone do oferty dokumenty zostały sporządzone w języku obcym (w tym dokumenty składane przez Wykonawcę zagranicznego) niezbędne jest przedstawienie ich tłumaczenia na język polski.

4. Jeżeli złożone kserokopie dokumentów będą nieczytelne lub będą budzić wątpliwości co do ich prawdziwości, Zamawiający może żądać przedstawienia oryginału lub notarialnie poświadczonej kopii dokumentu.

5. W przypadku Wykonawców wspólnie ubiegających się o udzielenie zamówienia oraz w przypadku innych podmiotów, na zasobach których Wykonawca polega na zasadach określonych w art. 26 ust. 2b ustawy, kopie dokumentów dotyczących odpowiednio Wykonawcy lub tych podmiotów są poświadczone za zgodność z oryginałem odpowiednio przez Wykonawcę lub te podmioty.

VI. OPAKOWANIE OFERTY

Ofertę należy złożyć w dwóch zamkniętych kopertach. Kopertę zewnętrzną należy oznaczyć w następujący sposób:

Zakład Ubezpieczeń Społecznych Departament Zamówień Publicznych 00-000 Xxxxxxxx

xx. Xxxxxxxx 0, 5

„Oferta przetargowa”

„Opiekę serwisową oprogramowania Oracle (Tuxedo, SALT, eLink) oraz nabycie dodatkowych licencji na oprogramowania Oracle (Tuxedo, SALT, Serwera aplikacyjnego) oraz usługę migracji oprogramowania ORACLE”

Znak sprawy: TZ/271/11/14

Koperta wewnętrzna musi być oznakowana w następujący sposób:

Zakład Ubezpieczeń Społecznych

“Oferta przetargowa”

i zaadresowana na adres Wykonawcy, aby można ją było odesłać bez otwierania w przypadku stwierdzenia jej opóźnienia.

VII. OPIS SPOSOBU DOKONYWANIA OCENY SPEŁNIANIA WARUNKÓW UDZIAŁU W POSTĘPOWANIU

1. Zamawiający oceni, czy Wykonawca spełnia warunki oraz czy nie zachodzą w stosunku do Wykonawcy przesłanki wykluczenia na podstawie złożonych, przez Wykonawcę, wraz z ofertą oświadczeń i dokumentów żądanych przez Zamawiającego i określonych w Rozdziale IV SIWZ.

2. Ocena spełnienia warunków udziału w postępowaniu zostanie dokonana na zasadzie: Wykonawca - spełnia albo Wykonawca - nie spełnia poszczególnych warunków.

Rozdział V

OPIS SPOSOBU OBLICZENIA CENY OFERTY

1. Wykonawca poda cenę oferty w sposób określony w Formularzu ofertowym części II –

„Cena Oferty” oraz w części V „Formularz cenowy” (Załącznik nr 1 do niniejszej Specyfikacji).

2. Stawka podatku VAT jest określana zgodnie z ustawą z dnia 11 marca 2004 r. o podatku od towarów i usług (Dz. U. Nr 54, poz. 535 z późn. zm.).

3. Wszystkie wartości powinny być podane w złotych polskich. Cena oferty powinna być wyrażona cyfrowo i słownie oraz podana z dokładnością do dwóch miejsc po przecinku.

4. Ceny podane w ofercie powinny zawierać wszystkie koszty Wykonawcy związane z realizacją zmówienia oraz uwzględniać inne opłaty i podatki wynikające z realizacji zamówienia, a także ewentualne upusty i rabaty.

Rozdział VI

INFORMACJE O MIEJSCU I TERMINIE SKŁADANIA I OTWARCIA OFERT

I. MIEJSCE I TERMIN SKŁADANIA OFERT

1. Ofertę należy złożyć w siedzibie Zamawiającego w Warszawie, ul. Szamocka 3, 5, Xxxxxxxx „X”, xxx. 000, do dnia 27.05.2014r. do godziny 09.00.

2. Oferty złożone po tym terminie zostaną zwrócone bez otwierania, zgodnie z zasadą określoną w art. 84 ust. 2 ustawy.

3. Każdy Wykonawca składający ofertę otrzyma od Zamawiającego potwierdzenie z numerem wpływu odnotowanym także na kopercie oferty.

4. Oferty przesłane faksem nie będą rozpatrywane.

II. MIEJSCE I TERMIN OTWARCIA OFERT

Otwarcie ofert nastąpi w dniu upływu terminu składania ofert w siedzibie Zamawiającego w Warszawie, ul. Szamocka 3, 5, Departament Zamówień Publicznych, sala C 135, o godzinie 09.30.

III. PUBLICZNE OTWARCIE OFERT

1. Otwarcie ofert jest jawne.

2. Bezpośrednio przed otwarciem ofert Zamawiający poda kwotę, jaką zamierza przeznaczyć na sfinansowanie zamówienia.

3. Dokonując otwarcia ofert Zamawiający poda imię i nazwisko, nazwę (firmę) i adres (siedzibę) Wykonawcy, cenę oferty, a także termin wykonania, okres gwarancji oraz warunki płatności, jeżeli ich podanie w ofercie było wymagane.

IV. TERMIN ZWIĄZANIA OFERTĄ

Wykonawca pozostaje związany złożoną ofertą przez okres 60 dni. Bieg terminu związania ofertą rozpoczyna się wraz z upływem terminu składania ofert.

V. ZMIANA I WYCOFANIE OFERTY

1. Wykonawca może przed upływem terminu do składania ofert zmienić lub wycofać ofertę poprzez złożenie pisemnego powiadomienia przed upływem wyznaczonego terminu składania ofert. Powiadomienie musi być podpisane przez osobę uprawnioną do reprezentowania Wykonawcy.

2. Powiadomienie o wprowadzeniu zmian winno zostać złożone w sposób i formie przewidzianych w Specyfikacji dla złożenia oferty, z zastrzeżeniem, że koperta zewnętrzna będzie zawierała dodatkowe oznaczenie „ZMIANA” i zostanie podany numer wpływu z potwierdzenia, o którym mowa w podrozdziale I pkt 3 niniejszego Rozdziału.

Rozdział VII

KRYTERIA I ZASADY OCENY OFERT

I. TRYB OCENY OFERT

1. Zamawiający poprawia w ofercie:

1) oczywiste omyłki pisarskie,

2) oczywiste omyłki rachunkowe, z uwzględnieniem konsekwencji rachunkowych dokonanych poprawek,

3) inne omyłki polegające na niezgodności oferty ze specyfikacją istotnych warunków zamówienia, nie powodujące istotnych zmian w treści oferty

- niezwłocznie zawiadamiając o tym Wykonawcę, którego oferta została poprawiona.

2. Oferta Wykonawcy, który w terminie 3 dni od dnia doręczenia zawiadomienia nie zgodził się na poprawienie omyłki, o której mowa w ust. 1 pkt 3, będzie podlegała odrzuceniu.

II. KRYTERIA WYBORU NAJKORZYSTNIEJSZEJ OFERTY

Kryterium wyboru	Znaczenie
Cena oferty	100 %

III. ZASADY OCENY OFERT WEDŁUG USTALONYCH KRYTERIÓW

1. Ocena ofert dokonywana będzie w kryterium:

cena brutto (z podatkiem VAT) za realizację zamówienia – według następującego wzoru:

najniższa cena ofertowa brutto

cena oferty badanej brutto

X 100 (waga kryterium)

2. Przyjmuje się, że 1%= 1 pkt i tak zostanie przeliczona liczba punktów ww. kryterium.

3. Za najkorzystniejszą zostanie uznana oferta, która uzyska najwyższą liczbę punktów.

4. Jeżeli złożono ofertę, której wybór prowadziłby do powstania obowiązku podatkowego Zamawiającego zgodnie z przepisami o podatku od towarów i usług w zakresie dotyczącym wewnątrzwspólnotowego nabycia towarów, zamawiający w celu oceny takiej oferty dolicza do przedstawionej w niej ceny podatek od towarów i usług, który miałby obowiązek wpłacić zgodnie z obowiązującymi przepisami.

Rozdział VIII

ZABEZPIECZENIE NALEŻYTEGO WYKONANIA UMOWY

1. Wykonawca zobowiązany jest wnieść przed podpisaniem umowy zabezpieczenie należytego wykonania umowy w wysokości 5% ceny oferty zawierającej podatek VAT.

2. Zabezpieczenie należytego wykonania umowy może być wniesione w jednej lub kilku z następujących form:

1) pieniądzu,

2) poręczeniu bankowym lub poręczeniu spółdzielczej kasy oszczędnościowo- kredytowej, z tym że zobowiązanie kasy jest zawsze zobowiązaniem pieniężnym,

3) gwarancji bankowej,

4) gwarancji ubezpieczeniowej,

5) poręczeniu udzielonym przez podmioty, o których mowa w art. 6 b ust. 5 pkt 2 ustawy z dnia 9 listopada 2000 r. o utworzeniu Polskiej Agencji Rozwoju Przedsiębiorczości (Dz. U. z 2007 r. Nr 42, poz. 275 ze zm.).

3. W przypadku wnoszenia zabezpieczenia należytego wykonania umowy:

1) w pieniądzu – odpowiednią kwotę należy wpłacić na rachunek bankowy Zamawiającego

nr rachunku PKO BP S.A. 81 1020 5590 0000 0602 9000 7017,

a dokument potwierdzający wpłatę (pokwitowanie) należy złożyć w siedzibie Zamawiającego w Warszawie ul. Szamocka 3, 5, Departament Zamówień Publicznych, skrzydło „C”, xxx. 000, najpóźniej przed podpisaniem umowy;

2) w przypadku wniesienia zabezpieczenia w pozostałych dopuszczanych formach dokument zabezpieczenia należy złożyć w siedzibie Zamawiającego w Warszawie ul. Szamocka 3, 5, Departament Zamówień Publicznych, skrzydło „C”, I piętro, xxx. 000 najpóźniej przed podpisaniem umowy.

4. Z dokumentu zabezpieczenia należytego wykonania umowy wniesionego w formie gwarancji bankowej/ubezpieczeniowej powinno wynikać jednoznacznie gwarantowanie wypłat należności w sposób nieodwołalny, bezwarunkowy i na pierwsze żądanie Zamawiającego zawierające oświadczenie o okolicznościach stanowiących podstawę do żądania wypłaty należności.

5. Warunki i termin zwolnienia zabezpieczenia należytego wykonania umowy określone zostały we wzorze umowy.

Rozdział XX WZÓR UMOWY

Wzór umowy określający szczegółowe warunki, na których Zamawiający zawrze umowę w sprawie udzielenia zamówienia publicznego, stanowi Załącznik nr 2 do Specyfikacji.

Rozdział X

POUCZENIE O ŚRODKACH OCHRONY PRAWNEJ

Wykonawcy, uczestnikowi konkursu, a także innemu podmiotowi, jeżeli ma lub miał interes w uzyskaniu danego zamówienia oraz poniósł lub może ponieść szkodę w wyniku naruszenia przez Zamawiającego przepisów ustawy, przysługują środki ochrony prawnej, o których mowa w Dziale VI ustawy Prawo zamówień publicznych– Środki Ochrony Prawnej.

Rozdział XI

FORMALNOŚCI PO WYBORZE OFERTY W CELU ZAWARCIA UMOWY

I. OGŁOSZENIE O WYNIKU POSTĘPOWANIA

Niezwłocznie po wyborze najkorzystniejszej oferty Zamawiający powiadomi Wykonawców, którzy złożyli oferty, o:

1) wyborze najkorzystniejszej oferty podając nazwę (firmę), albo imię i nazwisko, siedzibę albo miejsce zamieszkania i adres Wykonawcy, którego ofertę wybrano, uzasadnienie jej wyboru oraz nazwy (firmy), albo imiona i nazwiska, siedziby albo miejsca zamieszkania i adresy Wykonawców, którzy złożyli oferty, a także punktacje przyznaną ofertom w każdym kryterium oceny ofert i łączną punktację,

2) Wykonawcach, których oferty zostały odrzucone, podając uzasadnienie faktyczne i prawne,

3) Wykonawcach, którzy zostali wykluczeni z postępowania podając uzasadnienie faktyczne i prawne

4) terminie, określonym zgodnie z art. 94 ust. 1 lub ust. 2, po którego upływie umowa w sprawie zamówienia publicznego może być zawarta.

II. WARUNKI ZAWARCIA UMOWY

1. Zamawiający wskaże termin i miejsce podpisania umowy Wykonawcy, którego oferta została wybrana w zawiadomieniu o wyborze oferty.

2. Przed podpisaniem umowy Wykonawca, którego oferta została wybrana, zobowiązany jest do wniesienia zabezpieczenia należytego wykonania umowy na warunkach i w formie określonych w Rozdziale VIII niniejszej Specyfikacji pod rygorem nie zawarcia umowy.

3. Umowa zostanie zawarta w terminach o których mowa w art. 94 ust. 1 ustawy Prawo zamówień publicznych.

4. Zamawiający może zawrzeć umowę w sprawie zamówienia publicznego przed upływem terminów, o których mowa w ust. 3, jeżeli w postępowaniu o udzielenie zamówienia została złożona tylko jedna oferta.

5. W sprawach nieuregulowanych w niniejszej Specyfikacji istotnych warunków zamówienia mają zastosowanie przepisy ustawy – Prawo zamówień publicznych oraz przepisy Kodeksu cywilnego.

Rozdział XII ZMIANA UMOWY

1. Zamawiający dopuszcza możliwość dokonania zmian umowy w zakresie opisu przedmiotu zamówienia i jego cech oraz sposobu i terminu jego realizacji – jeżeli zmiany są korzystne dla Zamawiającego lub wywołane okolicznościami, których nie można było przewidzieć w momencie składania oferty.

2. Zamawiający nie dopuszcza możliwości zmiany umowy w zakresie przeniesienia praw i obowiązków wynikających z umowy na osoby trzecie w zakresie cesji wierzytelności.

3. Zmiana umowy wynika z okoliczności, których nie można było przewidzieć w chwili zawarcia umowy lub zmiany te są korzystne dla Zamawiającego.

4. Zmiana postanowień umowy wymaga formy pisemnego aneksu pod rygorem nieważności.

5. Z wnioskiem o zmianę postanowień umowy może wystąpić zarówno Wykonawca, jak i Zamawiający.

Wymienione poniżej załączniki stanowią integralną część niniejszej Specyfikacji:

1. Załącznik nr 1 – Formularz ofertowy

2. Załącznik nr 2 – Wzór umowy

3. Załącznik nr 3 – Wzór oświadczenia potwierdzającego spełnienie przez Wykonawcę warunków określonych w art. 22 ust. 1 ustawy Prawo zamówień publicznych

4. Załącznik nr 4 – Wzór oświadczenia o braku podstaw do wykluczenia na podstawie art. 24 ust. 1 ustawy Prawo zamówień publicznych

5. Załącznik nr 5 – Opis przedmiotu zamówienia

Załącznik nr 1 do SIWZ TZ/271/11/14

........................................................

(miejscowość, data)

........................................

Nazwa i adres Wykonawcy (e-mail i faks Wykonawcy)

Zakład Ubezpieczeń Społecznych (Zamawiający)

xx. Xxxxxxxx 0, 0

00-000 Xxxxxxxx

OFERTA

I. PRZEDMIOT OFERTY

Oferujemy wykonanie zamówienia obejmującego opiekę serwisową oprogramowania ORACLE (Tuxedo, SALT, eLink), przekazanie dodatkowych licencji na oprogramowania: ORACLE Tuxedo (lub równoważych), ORACLE SALT (lub równoważnych), dodatkowych licencji na oprogramowanie serwera aplikacyjnego JEE oraz usługę migracji oprogramowania ORACLE na warunkach określonych w Rozdziale II Specyfikacji Istotnych Warunków Zamówienia.

II. CENA OFERTY

Oferujemy wykonanie zamówienia za cenę całkowitą z podatkiem VAT zł,

(słownie złotych: )

określoną w Formularzu cenowym w pozycji „Razem”.

Ceny jednostkowe zostały określone w części Oferty – „Formularz cenowy” zgodnie z postanowieniami Rozdziału V Specyfikacji.

III. DEKLAROWANE WARUNKI REALIZACJI ZAMÓWIENIA

Deklarujemy następujące warunki realizacji zamówienia:

1. Termin wykonania zamówienia:

1) świadczenie usług opieki serwisowej posiadanego przez Zamawiającego oprogramowania Oracle:

a) SALT - Processor Perpetual 16372742 - ilość 4

b) Tuxedo - Processor Perpetual 16372742- ilość 4

c) SALT - Processor Perpetual 17779780 – ilość 1

d) SALT - Processor Perpetual 18336228 – ilość 12

e) BEA eLink Adapter Mainframe Tier 1- Tiered Server Perpetual 15985105 – ilość 1

f) Tuxedo - Processor Perpetual 16668998 – ilość 118 w terminie 12 miesięcy od daty zawarcia umowy,

oraz

2) przekazanie dodatkowych licencji oprogramowania Oracle Tuxedo / oprogramowania równoważnego* z prawem użytkowania dla 16 rdzeni procesora wraz z świadczeniem usługi opieki serwisowej od daty podpisania protokołu odbioru licencji do końca świadczenia opieki serwisowej dla oprogramowania wskazanego w pkt. III.1.1) lit. a) - f),

3) przekazanie dodatkowych licencji oprogramowania Oracle SALT / oprogramowania równoważnego* z prawem użytkowania dla 8 rdzeni procesora wraz z świadczeniem usługi opieki serwisowej od daty podpisania protokołu odbioru licencji do końca świadczenia opieki serwisowej dla oprogramowania wskazanego w pkt. III.1.1) lit. a) - f),

4) przekazanie dodatkowych licencji na oprogramowanie serwera aplikacyjnego JEE wraz z narzędziami zarządzania i tworzenia usług oraz usługą opieki serwisowej od daty podpisania protokołu odbioru licencji do końca świadczenia opieki serwisowej dla oprogramowania wskazanego w pkt. III.1.1) lit. a) - f),

5) przekazanie dodatkowych licencji, o których mowa w pkt. III.1.1.2)-4), w terminie do 7 dni od daty zawarcia umowy,

6) usługa wsparcia migracji oprogramowania Oracle, której zakres opisano w § 3 ust. 19 Wzoru umowy stanowiącego Załącznik nr 2 do SIWZ. Usługa wsparcia migracji wykonywana będzie w ramach usługi opieki serwisowej.

* zaznaczyć właściwe w zależności od oferowanego oprogramowania

2. Płatności:

1) Płatności za świadczenie usługi opieki serwisowej oprogramowania, o której mowa w III.1.1), będą dokonywane z dołu w miesięcznych opłatach w terminie 30 dni od daty otrzymania przez Zamawiającego – Zakład Ubezpieczeń Społecznych – xx. Xxxxxxxx 0, 0, 00-000 Xxxxxxxx, Departament Zarządzania Systemami Informatycznymi (sekretariat) faktury prawidłowo wystawionej na podstawie podpisanego bez uwag Miesięcznego raportu świadczenia usług (Załącznik nr 2 do umowy);

2) Płatność za udzielenie dodatkowych licencji na oprogramowania, o którym mowa w III.1.1.2)-4, wraz ze świadczeniem opieki serwisowej od dnia podpisania protokołu odbioru licencji do końca terminu, o którym mowa w III.1.1), będzie dokonana w terminie 30 dni od daty otrzymania przez Zamawiającego – Zakład Ubezpieczeń Społecznych, Departament Zarządzania Systemami Informatycznymi (sekretariat) faktury prawidłowo wystawionej na podstawie podpisanego bez uwag Protokołu odbioru licencji (Załącznik nr 9 do umowy).

3. Wniesienie zabezpieczenia należytego wykonania umowy w wysokości 5% ceny oferty brutto, w formie ...........................................................

4. Podwykonawcom zamierzamy powierzyć wykonanie zamówienia w części dotyczącej

............................................................................................................................... (xxxxxxxx

odpowiedni zakres lub pozostawić bez wypełnienia jeżeli nie dotyczy).

IV. OŚWIADCZENIA

1. Oświadczamy, że zapoznaliśmy się ze Specyfikacją Istotnych Warunków Zamówienia i zobowiązujemy się do stosowania i ścisłego przestrzegania warunków w niej określonych.

2. Oferowany przedmiot zamówienia spełnia wszystkie wymagania Zamawiającego określone w Opisie przedmiotu zamówienia zawartym w Rozdziale II SIWZ.

3. Oświadczamy, że uważamy się za związanych niniejszą ofertą na czas wskazany w Specyfikacji Istotnych Warunków Zamówienia, tj. 60 dni od upływu terminu składania ofert.

4. Oświadczamy, że zawarty w Specyfikacji Istotnych Warunków Zamówienia wzór umowy został przez nas zaakceptowany i zobowiązujemy się w przypadku wyboru naszej oferty do zawarcia umowy na warunkach określonych we wzorze w miejscu i terminie wyznaczonym przez Zamawiającego.

5. Jesteśmy świadomi, że w przypadku nie dojścia do zawarcia umowy z przyczyn leżących po naszej stronie wniesione wadium ulega przepadkowi na rzecz Zamawiającego.

6. Jesteśmy świadomi, że w przypadku nie złożenia dokumentów lub oświadczeń, o których mowa w art. 25 ust. 1 ustawy, lub pełnomocnictw z przyczyn leżących po naszej stronie, w odpowiedzi na wezwanie Zamawiającego, o którym mowa w art. 26 ust. 3 ustawy, wniesione wadium ulega przepadkowi na rzecz Zamawiającego.

7. Oświadczamy, że wnieśliśmy wadium w formie ..............................................., zwrotu wadium należy dokonać na rachunek bankowy Wykonawcy:

.................................................................. (dotyczy Wykonawców, którzy wnieśli wadium w formie pieniądza).

V. FORMULARZ CENOWY

TABELA I
Lp.	Przedmiot zamówienia	Cena brutto, tj. z podatkiem VAT, za 1 miesiąc świadczenia usługi w zł	Liczba miesięcy	Xxxx całkowita brutto w zł (kol. 3 x kol. 4)
1	2	3	4	5
1.	Opieka serwisowa (wraz z usługą wsparcia migracji) oprogramowania Oracle: SALT – Processor Perpetual 16372742 – ilość 4, Tuxedo – Processor Perpetual 16372742– ilość 4, SALT – Processor Perpetual 17779780 – ilość 1, SALT – Processor		12

Perpetual 18336228 –

ilość 12,

BEA eLink Adapter Mainframe Tier 1- Tiered Server Perpetual 15985105 –

ilość 1,

Tuxedo - Processor Perpetual 16668998 –

ilość 118

Opieka serwisowa (wraz z usługą wsparcia migracji) oprogramowania Oracle:

SALT - Processor Perpetual OPL- 191211-14150-JL -

ilość 12

8**

RAZEM OPIEKA SERWISOWA

TABELA II

Przedmiot zamówienia

Oferowane oprogramowanie

Liczba licencji

Jednostkowa cena brutto, tj. z podatkiem

VAT, licencji w zł

Cena całkowita brutto w zł

(kol. 4 x kol. 5)

Nabycie dodatkowych licencji oprogramowania Oracle Tuxedo / oprogramowania równoważnego* z prawem użytkowania dla 16 rdzeni procesora wraz

z świadczeniem usługi opieki serwisowej

……………… (nazwa

/producent)

Nabycie dodatkowych licencji oprogramowania Oracle SALT / oprogramowania równoważnego* z prawem użytkowania dla 8 rdzeni procesora wraz z świadczeniem usługi

opieki serwisowej

……………… (nazwa

/producent)

Nabycie dodatkowych licencji na oprogramowanie serwera aplikacyjnego JEE wraz z narzędziami zarządzania i tworzenia usług oraz

usługą opieki serwisowej

……………… (nazwa

/producent)

RAZEM NABYCIE LICENCJI

RAZEM - CENA CAŁKOWITA OFERTY (Tabela I + Tabela II)

* zaznaczyć właściwe w zależności od oferowanego oprogramowania

**8 miesięcy wskazano celem porównania ofert. Zamawiający będzie dokonywał płatności za okresy, w których usługi są faktycznie realizowane.

Oświadczamy, że podana wyżej cena zawiera w sobie wszystkie koszty wynikające z realizacji umowy, w tym opłaty i podatki, jest ceną ostateczną, niepodlegającą zwiększeniu w okresie trwania umowy.

Łączna wartość dostarczonych licencji nie może być większa niż 20% ceny całkowitej oferty. Jeżeli wartość dostarczonych licencji przekroczy 20% wartości ceny całkowitej oferty, oferta taka, na podstawie art. 89 ust. 1 pkt 2 ustawy Prawo zamówień publicznych podlegać będzie odrzuceniu.

VI. ZAŁĄCZNIKI DO OFERTY

1. Oświadczenia i dokumenty potwierdzające spełnianie warunków udziału w postępowaniu:

1.1. Oświadczenia i dokumenty potwierdzające spełnianie warunków udziału w postępowaniu:

1) oświadczenie potwierdzające spełnianie przez Wykonawcę warunków określonych w art. 22 ust. 1 ustawy, sporządzone wg wzoru stanowiącego Załącznik nr 3 do niniejszej Specyfikacji;

1.2. Oświadczenia i dokumenty o braku podstaw do wykluczenia z postępowania o udzielenie zamówienia:

1) oświadczenie o braku podstaw do wykluczenia, sporządzone wg wzoru stanowiącego załącznik nr 4 do niniejszej Specyfikacji;

3) aktualne zaświadczenie właściwego naczelnika urzędu skarbowego potwierdzające, że Wykonawca nie zalega z opłacaniem podatków lub zaświadczenie, że uzyskał przewidziane prawem zwolnienie, odroczenie lub rozłożenie na raty zaległych płatności lub wstrzymanie w całości wykonania decyzji właściwego organu – wystawione nie wcześniej niż 3 miesiące przed upływem terminu składania ofert;

6) aktualna informacja z Krajowego Rejestru Karnego w zakresie określonym w art. 24 ust. 1 pkt 9 ustawy wystawiona nie wcześniej niż 6 miesięcy przed upływem terminu składania ofert;

7) lista podmiotów należących do tej samej grupy kapitałowej o której mowa w art. 24 ust. 2 pkt 5 ustawy lub informacja o tym, że Wykonawca nie należy do grupy kapitałowej.

2. Inne wymagane oświadczenia i dokumenty:

1) w przypadku, gdy Wykonawcę reprezentuje pełnomocnik - pełnomocnictwo określające jego zakres i podpisane przez osoby uprawnione do reprezentacji Wykonawcy;

3) dokument potwierdzający wniesienie wadium, jeżeli zostało wniesione w innej formie niż w pieniądzu (zaleca się dołączyć).

………………...............................................................................

(podpis osoby upoważnionej do reprezentowania Wykonawcy)

Załącznik nr 2

do SIWZ TZ/271//11/14

WZÓR UMOWY nr ………………….

W dniu .......................2014 roku w Warszawie pomiędzy:

Zakładem Ubezpieczeń Społecznych z siedzibą w Warszawie przy ul. Szamockiej 3, 5, posiadającym NIP nr 000-00-00-000, REGON nr 000017756, który reprezentuje:

1. …

zwanym dalej „ZAMAWIAJĄCYM", a

…………………………….. z siedzibą w ……….…….…ul ,

posiadającą NIP nr ………………..………., Regon nr ……………..…….., działającą w oparciu o: ………...................., pod numerem ……………….. , kapitał zakładowy (jeśli dotyczy) ……………………., którą reprezentują:

1. …

2. …

zwaną dalej „WYKONAWCĄ",

łącznie zwanymi „Stronami”

w wyniku postępowania o zamówienie publiczne, przeprowadzonego w trybie przetargu nieograniczonego na podstawie przepisów ustawy z dnia 29 stycznia 2004 r. – Prawo zamówień publicznych (Dz. U. z 2013 r. poz. 907 z późn. zm.), została zawarta umowa o następującej treści:

§ 1 Przedmiot umowy

1. Przedmiotem umowy jest:

1) świadczenie usług opieki serwisowej posiadanego przez Zamawiającego oprogramowania Oracle:

a) SALT - Processor Perpetual 16372742 - ilość 4

b) Tuxedo - Processor Perpetual 16372742- ilość 4

c) SALT - Processor Perpetual 17779780 – ilość 1

d) SALT - Processor Perpetual 18336228 – ilość 12

e) BEA eLink Adapter Mainframe Tier 1- Tiered Server Perpetual 15985105 – ilość 1

f) Tuxedo - Processor Perpetual 16668998 – ilość 118 w terminie 12 miesięcy od daty zawarcia umowy,

oraz

g) SALT - Processor Perpetual OPL-191211-14150-JL - ilość 12, w terminie od dnia zawarcia umowy, nie wcześniej jednak niż od dnia 28.12.2014 r., do końca świadczenia opieki serwisowej dla oprogramowania wskazanego w pkt 1) lit. a) - f).

2) nabycie dodatkowych licencji na oprogramowanie Oracle Tuxedo lub oprogramowania równoważnego z prawem użytkowania dla 16 rdzeni procesora wraz z świadczeniem usługi opieki serwisowej od daty podpisania protokołu odbioru licencji do końca świadczenia opieki serwisowej dla oprogramowania wskazanego w pkt. 1) lit. a) - f),

3) nabycie dodatkowych licencji na oprogramowanie Oracle SALT lub oprogramowania równoważnego z prawem użytkowania dla 8 rdzeni procesora wraz z świadczeniem usługi opieki serwisowej od daty podpisania protokołu odbioru licencji do końca świadczenia opieki serwisowej dla oprogramowania wskazanego w pkt. 1) lit. a) - f),

5) usługa wsparcia migracji oprogramowania Oracle, której zakres opisano w § 3 ust. 19. Usługa wsparcia migracji wykonywana będzie w ramach usługi opieki serwisowej.

2. Szczegółowy opis przedmiotu umowy stanowi Załącznik nr 10 do umowy.

3. Oprogramowanie określone w ust. 1 pkt 1), 2), 3) i 4) w dalszej części umowy zwane jest

„Oprogramowaniem”.

4. Wykonawca ponosi odpowiedzialność za dotrzymanie deklarowanych w umowie warunków realizacji przedmiotu umowy, wynikających z oferty Wykonawcy.

5. Wymagania Zamawiającego w zakresie poziomu świadczenia usług opieki serwisowej Oprogramowania oraz szczegółowy sposób świadczenia usług opieki serwisowej/wsparcia gwarancyjnego określa § 3 umowy.

6. Wykonawca gwarantuje, że posiada prawo do dysponowania licencjami na oprogramowanie, określone w ust. 1 pkt 2), 3) i 4).

7. Licencje na oprogramowanie, określone w ust. 1 pkt 2), 3) i 4), są udzielone na czas nieokreślony.

8. Wykonawca zapewnia, że oprogramowanie objęte udzielonymi licencjami jest wolne od jakichkolwiek praw osób trzecich, a ponadto, że nie zachodzą jakiekolwiek podstawy do zgłoszenia przez osoby trzecie roszczeń do tych praw w przyszłości.

9. Z dniem podpisania protokołu odbioru licencji (Załącznik nr 9 do umowy) Wykonawca udziela Zamawiającemu nieodwołalnej, niewyłącznej i niezbywalnej licencji na korzystanie z oprogramowania z zastrzeżeniem możliwości wypowiedzenia jedynie w przypadku rażącego naruszania przez Zamawiającego warunków licencyjnych. W ramach licencji na korzystanie z Oprogramowania Zamawiający jest uprawniony do:

1) trwałego lub czasowego zwielokrotnienia programu komputerowego w całości lub w części jakimikolwiek środkami i w jakiejkolwiek formie,

2) instalacji, uruchamiania, przechowywania i korzystania,

3) implementacji w środowisku operacyjnym Zamawiającego,

4) wprowadzania i przechowywania w pamięci komputerów zgodnie z dostarczonym przez Wykonawcę dokumentem licencyjnym (licence agreement),

5) uruchamiania, wyświetlania i stosowania w celach zgodnych z dokumentacją,

6) przystosowywania, wprowadzania w zmian układu lub innych zmian wyłącznie w zakresie, w jakim to przystosowywanie lub zmiany będą niezbędne do korzystania z zgodnie z przeznaczeniem.

10. Pozostałe warunki korzystania z oprogramowania określa dokument licencyjny (licence agreement) producenta oprogramowania, dostarczony Zamawiającemu przez Wykonawcę w terminie, o którym mowa w § 4 ust.2.

11. W przypadku zgłoszenia przez osoby trzecie jakichkolwiek roszczeń z tytułu praw własności intelektualnej objętych powyższymi zapewnieniami Wykonawcy, Wykonawca zobowiązuje się do podjęcia na swój koszt i ryzyko wszelkich kroków prawnych zapewniających należytą ochronę Zamawiającego przed takimi roszczeniami osób trzecich, a także zobowiązuje się zrekompensować Zamawiającemu wszelkie szkody (w tym koszty), jakie może ponieść Zamawiający lub jakie będzie zobowiązany zapłacić osobie trzeciej w związku z roszczeniem lub pozwem sądowym o naruszenie patentu, prawa autorskiego, zastrzeżonego wzoru lub praw ze znaku towarowego, jakie ta osoba zgłosi w związku z tym, że Zamawiający eksploatuje przedmiot licencji w sposób zgodny z umową, posiada lub użytkuje przedmiot licencji, pod warunkiem, że Zamawiający zawiadomi Wykonawcę o naruszeniu prawa własności intelektualnej niezwłocznie po powzięciu wiadomości o takim naruszeniu.

12. Wykonawca zobowiązany jest do dołożenia najwyższej staranności oraz świadczenia usług stanowiących przedmiot Umowy zgodnie z najlepszą wiedzą i posiadanym doświadczeniem.

13. Celem usługi opieki serwisowej oprogramowania Oracle posiadanego przez Zamawiającego jest zapewnienie najbardziej efektywnego, sprawnego, prawidłowego i profesjonalnego użytkowania oprogramowania objętego przedmiotem umowy przez Zamawiającego oraz systematyczne przekazywanie wiedzy, przeprowadzanie warsztatów, podnoszenie wiedzy wynikającej z utrzymania i przyszłego rozwoju wykorzystywanego przez Xxxxxxxxxxxxx oprogramowania, co pozwoli zbudować wewnętrzne centrum kompetencyjne. Usługi będą świadczone przez wykwalifikowane w zakresie technicznym osoby, które udostępni Wykonawca, zdolne do świadczenia pomocy serwisowej w zakresie oprogramowania Oracle będącego przedmiotem serwisowania, na poziomie zgodnym z wymaganiami umowy, określonymi w §3 umowy.

14. Podwykonawcom zostaje powierzone wykonanie zamówienia w części dotyczącej (jeśli dotyczy) …………..

15. Wykonawca ponosi odpowiedzialność za działania podwykonawców jak za działania własne.

§ 2 Cena umowna

1. Łączna cena brutto, tj. z podatkiem VAT, za realizację przedmiotu Umowy, określonego w §1 umowy, nie przekroczy ……………… zł (słownie złotych: ………), zgodnie z Formularzem cenowym (Załącznik nr 1 do umowy).

2. Opłata miesięczna brutto, tj. z podatkiem VAT, za świadczenie usług stanowiących przedmiot umowy, o którym mowa w § 1 ust. 1 pkt. 1) lit. a) - f) umowy wynosi

………… zł (słownie złotych: …………), zgodnie z Formularzem cenowym (Załącznik nr 1 do umowy).

3. Opłata miesięczna brutto, tj. z podatkiem VAT, za świadczenie usług stanowiących przedmiot umowy, o którym mowa w § 1 ust. 1 pkt. 1) lit. g) umowy wynosi …………

zł (słownie złotych: …………), zgodnie z Formularzem cenowym (Załącznik nr 1 do umowy).

4. Jednorazowa opłata z tytułu udzielenia licencji …………………. wraz ze świadczeniem opieki serwisowej, o których mowa w § 1 ust 1 pkt 2 umowy, wynosi brutto, tj. z podatkiem VAT, ………… zł (słownie złotych …………), zgodnie z Formularzem cenowym (Załącznik nr 1 do umowy).

5. Jednorazowa opłata z tytułu udzielenia licencji …………………. wraz ze świadczeniem opieki serwisowej, o których mowa w § 1 ust 1 pkt 3 umowy, wynosi brutto, tj. z podatkiem VAT, ………… zł (słownie złotych …………), zgodnie z Formularzem cenowym (Załącznik nr 1 do umowy).

6. Jednorazowa opłata z tytułu udzielenia licencji …………………. wraz ze świadczeniem opieki serwisowej, o których mowa w § 1 ust 1 pkt 4 umowy, wynosi brutto, tj. z podatkiem VAT, ………… zł (słownie złotych …………), zgodnie z Formularzem cenowym (Załącznik nr 1 do umowy).

7. Opłaty, o których mowa w ust 2 i 3, zawierają wynagrodzenie z tytułu świadczenia usługi wsparcia migracji, o której mowa w §1 ust 1 pkt 5), zgodnie z Formularzem cenowym (Załącznik nr 1 do umowy).

8. Ceny, o których mowa w ust. 1 - 6, zawierają wszelkie koszty Wykonawcy związane z realizacją przedmiotu umowy i nie ulegną zwiększeniu w okresie obowiązywania umowy.

9. Warunki płatności:

1) Płatności za świadczenie usługi opieki serwisowej oprogramowania, o której mowa w § 1 ust. 1 pkt. 1), będą dokonywane z dołu w miesięcznych opłatach w terminie 30 dni od daty otrzymania przez Zamawiającego – Zakład Ubezpieczeń Społecznych – xx. Xxxxxxxx 0, 0, 00-000 Xxxxxxxx, Departament Zarządzania Systemami Informatycznymi (sekretariat) faktury prawidłowo wystawionej na podstawie podpisanego bez uwag Miesięcznego raportu świadczenia usług (Załącznik nr 2 do umowy);

2) Płatność za udzielenie dodatkowych licencji na oprogramowania, o którym mowa w §1 ust 1 pkt 2-4, wraz ze świadczeniem opieki serwisowej od dnia podpisania protokołu odbioru licencji do końca terminu, o którym mowa w §1 ust 1, będzie dokonana w terminie 30 dni od daty otrzymania przez Zamawiającego – Zakład Ubezpieczeń Społecznych, Departament Zarządzania Systemami Informatycznymi (sekretariat) faktury prawidłowo wystawionej na podstawie podpisanego bez uwag Protokołu odbioru licencji (Załącznik nr 9 do umowy).

10. Strony ustalają, że okresem rozliczeniowym za świadczenie usługi opieki serwisowej oprogramowania ORACLE, o której mowa w § 1 ust 1 pkt 1, będzie miesiąc kalendarzowy. Wysokość wynagrodzenia za niepełny miesiąc obowiązywania umowy będzie wyliczona w następujący sposób: łączna opłata miesięczna za 1 miesiąc podzielona przez liczbę dni w danym miesiącu i pomnożona przez liczbę dni wykonywania usługi w danym miesiącu.

11. Zamawiający będzie dokonywał płatności za okresy rozliczeniowe, w których usługi są faktycznie realizowane.

12. Za datę dokonania płatności przyjmuje się datę obciążenia rachunku bankowego Zamawiającego należną Wykonawcy kwotą.

13. W przypadku zwłoki w dokonaniu płatności Wykonawca może obciążyć Zamawiającego ustawowymi odsetkami.

14. Wykonawca nie może dokonywać przeniesienia wierzytelności wynikających z umowy na osoby trzecie, ani regulować ich w drodze kompensaty.

15. Płatności będą dokonywane na rachunek bankowy Wykonawcy nr…………………….

§3 Warunki realizacji przedmiotu umowy

1. Wykonawca w dniu zawarcia umowy przekaże Zamawiającemu wykaz osób upoważnionych do rozwiązywania problemów i współpracy z Zamawiającym (Załącznik nr 7 do umowy) w celu realizacji umowy.

2. Wykonawca gwarantuje świadczenie usługi opieki serwisowej (wsparcia gwarancyjnego) i możliwość zgłaszania problemów drogą, faksową lub elektroniczną w trybie ciągłym 24 godziny na dobę 7 dni w tygodniu 365 dni w roku.

3. Zgłoszenia awarii następować będzie z wykorzystaniem systemu obsługi zgłoszeń Zamawiającego (HP Service Manager). Format oraz struktura komunikatów obsługiwanych przez system obsługi zgłoszeń Zamawiającego (HP Service Manager) jak również zakres informacji przekazywanych przy zgłaszaniu awarii opisany jest w Załączniku nr 8 do umowy. Za moment zgłoszenia awarii uznany będzie czas przesłania do Wykonawcy Formularza zgłoszenia awarii (Załącznik nr 4 do umowy) lub zgłoszenia z systemu HP Service Manager.

4. Do czasu integracji systemu obsługi zgłoszeń Zamawiającego z systemem obsługi zgłoszeń Wykonawcy, maksymalnie przez 2 miesiące od daty zawarcia Umowy, oraz w przypadku awarii systemu obsługi zgłoszeń Zamawiającego (HP Service Manager), o czym Zamawiający niezwłocznie poinformuje Wykonawcę lub systemu obsługi zgłoszeń Wykonawcy, Strony będą dokonywać zgłoszeń na Formularzu zgłoszenia awarii, którego wzór określa Załącznik nr 4 do umowy oraz wymieniać komunikaty za pośrednictwem poczty elektronicznej na uzgodnione adresy e-mail, z uwzględnieniem ust. 6. Wykonawca zobowiązany jest do niezwłocznego poinformowania Zamawiającego o awarii swojego systemu obsługi zgłoszeń. W przypadku braku takiej informacji, zgłoszenia awarii dokonane przez Zamawiającego przez system HP Service Manager do systemu Wykonawcy będą uznane za dostarczone. O fakcie integracji systemów Wykonawca pisemnie poinformuje Zamawiającego.

5. Adresy e-mail Zamawiającego i Wykonawcy służące do zgłaszania i obsługi awarii w przypadkach opisanych w ust 4, Strony przekażą sobie wzajemnie w terminie 3 dni od daty zawarcia umowy.

6. Wykonawca, nie później niż w ciągu 30 minut od momentu otrzymania zgłoszenia, potwierdzi przyjęcie zgłoszenia w formie takiej, jak otrzymał zgłoszenie. W przypadku braku potwierdzenia w tym czasie Zamawiający kontaktuje się z Wykonawcą w celu wyjaśnienia przyczyny braku potwierdzenia oraz ustalenia ewentualnego sposobu rejestracji zgłoszenia u Wykonawcy. Dokonanie wyjaśnień w wyniku zainicjowanego przez Zamawiającego kontaktu nie zwalnia od naliczenia kar umownych z tytułu niedotrzymania czasu potwierdzenia, o których mowa w § 5 ust 3 umowy.

7. Wykonanie zgłoszenia serwisowego zostanie potwierdzone podpisaniem protokołu, którego wzór stanowi Załącznik nr 5 do umowy, a następnie przesłaniem potwierdzenia do systemu obsługi zgłoszeń Zamawiającego (HP Service Manager), w którym załączony będzie skan podpisanego Formularza wykonania zgłoszenia serwisowego. Czas otrzymania przez Zamawiającego potwierdzenia w systemie obsługi zgłoszeń Zamawiającego (HP Service Manager) będzie czasem wykonania zgłoszenia. Dopuszcza się opóźnienie w dosłaniu skanu podpisanego Formularza wykonania zgłoszenia serwisowego do systemu obsługi zgłoszeń Zamawiającego (HP Service Manager) do 2 dni roboczych, jednak opóźnienie to nie zmienia czasu wykonania zgłoszenia.

8. W reakcji na problemy zgłoszone przez Zamawiającego, Wykonawca prześle szczegółowy plan swoich działań w związku z dokonanym zgłoszeniem:

1) problemu krytycznego - w ciągu 12 godzin zegarowych, od zgłoszenia przez Zamawiającego,

2) problemu niekrytycznego - w ciągu 48 godzin zegarowych, od zgłoszenia przez Zamawiającego,

3) status zgłoszenia problemu określa Zamawiający.

9. Wykonawca jest zobowiązany do przedstawienia informacji pisemnej (e-mail lub fax) o stanie zgłoszeń zawierającej co najmniej uszczegółowienie objawów, diagnozę, podjęte i planowane czynności naprawcze, przewidywany czas naprawy. W przypadku zgłoszenia problemu krytycznego, informacja pisemna o stanie zgłoszenia, będzie udzielana nie rzadziej niż raz na 48 godzin od momentu zgłoszenia, a w przypadku innych zgłoszeń nie rzadziej niż raz na 168 godzin od momentu zgłoszenia.

10. Wykonawca zobowiązuje się do dostarczenia poprawek wynikających z błędów oprogramowania (tzw. support pack’ów), aktualizacji oprogramowania (tzw. update’ów) lub nowych jego wersji zmieniających funkcjonalność (tzw. upgrade’ów), oraz zapewni Zamawiającemu wsparcie w trakcie ich instalacji w czasie obowiązywania umowy.

11. Wykonawca w dniu podpisania umowy zapewni ciągły dostęp do:

1) stron internetowych producenta oprogramowania z aktualną bazą wiedzy na temat oprogramowania Oracle będącego przedmiotem serwisowania;

2) inżynierów supportowych zdolnych do dokonywania zmian w kodzie oprogramowania Oracle oraz odbycia wizyt serwisowych w siedzibie Zamawiającego;

3) elektronicznej dystrybucji oprogramowania;

4) dokumentacji produktów.

12. Wykonawca zapewni Zamawiającemu e-mail`owe i telefoniczne konsultacje w zakresie oprogramowania Oracle oraz jego współpracy z platformami, na których jest osadzone, od poniedziałku do piątku, z wyłączeniem świąt i dni ustawowo wolnych od pracy, w godzinach w godz. 8.00 – 16.00.

13. Wykonawca będzie sprawdzał i informował na bieżąco Zamawiającego o poprawności zainstalowanego oprogramowania Oracle w zakresie poziomu patchowania, aktualności i kompletności w stosunku do aktualnie obowiązującego najnowszego poziomu dla danej wersji.

14. Wykonawca - w 3, 6, 9 oraz 11 miesiącu od dnia zawarcia umowy - jest zobowiązany do dokonywania przeglądów konserwacyjnych oprogramowania, w szczególności na następujących zasadach:

1) sprawdzanie poprawności oprogramowania Oracle w zakresie wersji, poziomu patchowania i kompletności,

3) testowanie diagnostyczne, regulacje, strojenia oraz zabiegi konserwacyjne mające na celu utrzymanie oprogramowania w prawidłowym stanie,

4) wszystkie czynności mają być wykonane w sposób zgodny z zaleceniami producenta oprogramowania oraz niezbędny do zapewnienia jego poprawnej i wydajnej pracy,

15. Wykonawca zobowiązany jest do sporządzania i przekazywania Zamawiającemu raz w miesiącu zbiorczego Miesięcznego raportu z wykonanych usług opieki serwisowej

oprogramowania Oracle (Załącznik nr 2 do umowy).

16. Wykonawca dostarczy Miesięczny raport świadczenia usług oraz Raport z wykonania przeglądu konserwacyjnego nie później, niż do 5 dnia następnego miesiąca, po upływie okresu objętego raportem.

17. Zamawiający potwierdzi raport, o którym mowa w ust. 15, lub zgłosi do niego uwagi w terminie 3 dni od daty jego otrzymania.

18. Usługa opieki serwisowej świadczona przez Wykonawcę będzie realizowana w Centralnym Ośrodku Obliczeniowym (COO) i Oddziałach ZUS. Wykaz placówek stanowi załącznik nr 3 do umowy.

19. Wykonawca zapewni Zamawiającemu wsparcie proaktywne poprzez:

1) inwentaryzację usług Oracle i korzystających z nich aplikacji. Spodziewanym efektem ww. prac jest przygotowanie zestawienia usług Oracle działających w obrębie systemu KSI wraz ze wskazaniem na obsługujące je serwery, domeny Oracle, w których są uruchamiane oraz korzystające z nich aplikacje biznesowe. Inwentaryzacja będzie wykonywana dwa razy w ciągu roku (w piątym i jedenastym miesiącu trwania umowy) i jej wynik będzie przedstawiany Zamawiającemu w postaci aktualnego zestawienia usług Oracle;

2) wsparcie przy migracji oprogramowania Oracle z obecnie posiadanej platformy (HP- UX dla procesorów Itanium) do platformy wskazanej przez Zamawiającego;

3) wsparcie przy podniesieniu wersji oprogramowania Oracle z obecnie posiadanej wersji do wersji wskazanej przez Xxxxxxxxxxxxx;

4) wsparcie przy przeniesieniu wskazanych usług systemu KSI uruchomionych na Oracle na platformie docelowej;

5) kontrole jakości procesu migracji usług uruchamianych na Oracle poprzez kwartalne przeglądy prac i raporty wykonywane przez producenta oprogramowania pod kątem zachowania zgodności z rekomendacjami producenta i wymogami serwisowymi;

6) możliwość wsparcia procesu migracji, uruchomienia i stabilizacji środowiska docelowego przez inżynierów zdolnych do wykonywania czynności serwisowych w siedzibie Zamawiającego i posiadających możliwość diagnozowania kodu Oracle oraz wprowadzania do niego zmian;

7) wsparcie przy udostępnieniu usług działających w środowiskach Oracle dla korporacyjnej architektury SOA podczas przebudowy istniejących aplikacji KSI bądź tworzenia nowych funkcjonalności.

20. Wykonawca w ramach budowania centrum kompetencyjnego po stronie Zamawiającego w trakcie trwania umowy będzie systematycznie, w sposób ciągły - na żądanie Zamawiającego - przekazywał wiedzę dotyczącą wykorzystywanego oprogramowania Oracle, sposobu rozwiązywania problemów serwisowych oraz metod związanych z jego rozwojem w środowisku informatycznym Zamawiającego.

21. Na zakończenie trwania umowy Wykonawca przeprowadzi zamknięte warsztaty, indywidualnie przygotowane dla maksymalnie 10 osób z uwzględnieniem środowiska informatycznego Zamawiającego, z administracji oprogramowania Oracle. Warsztaty zostaną zakończone imiennymi certyfikatami.

§ 4 Termin i warunki realizacji przedmiotu Umowy

1. Termin realizacji przedmiotu umowy w zakresie świadczenia usług opieki serwisowej – 12 miesięcy od daty zawarcia umowy, z zastrzeżeniem § 1 ust. 1 pkt 1) lit g) oraz ust 1 pkt 2), 3) i 4) umowy.

2. Dostawa licencji (kart licencyjnych) Oprogramowania – do 7 dni od daty zawarcia Umowy.

3. Wykonawca będzie świadczyć usługi opieki serwisowej dostarczonego oprogramowania na warunkach opisanych w § 3.

4. Okres rękojmi na Oprogramowanie równy jest okresowi opieki serwisowej.

§5 Kary umowne i odstąpienie od umowy

1. W przypadku opóźnienia wykonania czynności objętych przedmiotem umowy, w stosunku do terminu określonego w § 4 ust. 2 umowy, Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 5.000,00 zł (słownie złotych: pięć tysięcy 00/100) za każdą rozpoczętą godzinę opóźnienia.

2. W przypadku opóźnienia wykonania czynności objętych przedmiotem umowy, w stosunku do terminu określonego w § 3 ust. 8 umowy, Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 1.000,00 zł (słownie złotych: jeden tysiąc 00/100) za każdą rozpoczętą godzinę opóźnienia.

3. W przypadku niedotrzymania przez Wykonawcę terminu, o którym mowa w § 3 ust. 6 umowy, Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 500,00 zł (słownie złotych: pięćset 00/100) za każde rozpoczęte 30 minut opóźnienia.

4. W przypadku opóźnienia przez Wykonawcę terminu integracji systemu obsługi zgłoszeń Zamawiającego z systemem obsługi zgłoszeń Wykonawcy, o którym mowa w

§ 3 ust. 4 umowy, Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 500,00 zł (słownie złotych: pięćset 00/100) za każdy rozpoczęty kalendarzowy dzień opóźnienia.

5. W przypadku niedotrzymania przez Wykonawcę terminów, o których mowa w § 3 ust. 9 umowy, Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 1.000,00 zł (słownie złotych: jeden tysiąc 00/100) za każde rozpoczęte 24 godziny opóźnienia.

6. W przypadku niedotrzymania przez Wykonawcę terminów, o których mowa w § 3 ust. 14 umowy, Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 1.000,00 zł (słownie złotych: jeden tysiąc 00/100) za każdy rozpoczęty kalendarzowy dzień opóźnienia.

7. W przypadku przekroczenia terminu przesłania skanu podpisanego Formularza wykonania zgłoszenia serwisowego do systemu obsługi zgłoszeń Zamawiającego, o którym mowa w § 3 ust. 7 umowy, Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 100,00 zł za każdy dzień kalendarzowy opóźnienia.

8. Jeżeli opóźnienie terminu, o którym mowa w § 4 ust. 2, przekroczy 7 dni, Zamawiający jest uprawniony odstąpić od umowy. W takim przypadku Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 20% łącznej ceny brutto, wskazanej w § 2 ust. 1 umowy.

9. W przypadku naruszenia zasad bezpieczeństwa informacji, o których mowa w § 8 Umowy, Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 5 % łącznej ceny brutto, wskazanej w § 2 ust. 1 umowy, za każdy przypadek ujawnienia informacji chronionych.

10. Zamawiający ma prawo do potrącania kar umownych z należnego wynagrodzenia (faktury) lub zabezpieczenia należytego wykonania umowy bez potrzeby uzyskania zgody Wykonawcy.

11. W razie wystąpienia istotnej zmiany okoliczności powodującej, że wykonanie umowy nie leży w interesie publicznym, czego nie można było przewidzieć w chwili zawarcia umowy, Zamawiający może odstąpić od umowy w terminie 30 dni od powzięcia wiadomości o powyższych okolicznościach.

12. W przypadku określonym w ust. 11 Wykonawca może żądać jedynie zapłaty z tytułu zrealizowanej części umowy.

13. Strony zastrzegają sobie prawo do dochodzenia na zasadach ogólnych odszkodowania przenoszącego wysokość kar umownych.

§6 Siła wyższa

1. Strony niniejszej umowy będą zwolnione z odpowiedzialności za niewypełnienie swoich zobowiązań zawartych w umowie w czasie trwania siły wyższej, jeżeli okoliczności zaistnienia siły wyższej będą stanowiły przeszkodę w ich wypełnieniu.

2. Siłą wyższą jest zdarzenie zewnętrzne, nie posiadające swojego źródła wewnątrz przedsiębiorstwa, niemożliwe do przewidzenia oraz niemożliwe do zapobieżenia, przy czym dotyczy to niemożliwości zapobieżenia jego szkodliwym następstwom.

3. Strona może powołać się na zaistnienie siły wyższej tylko wtedy, gdy poinformuje ona o tym pisemnie drugą stronę w ciągu 3 dni od daty jej zaistnienia.

4. Okoliczności zaistnienia siły wyższej muszą zostać udowodnione przez stronę, która się na nie powołuje.

§7 Zabezpieczenie należytego wykonania umowy

1. Wykonawca udzielił Zamawiającemu zabezpieczenia należytego wykonania umowy w formie ……………. w wysokości ………… zł (słownie złotych: …………….), tj. 5% łącznej ceny brutto wskazanej w § 2 ust. 1 umowy, ważnego przez okres obowiązywania umowy przedłużony o 30 dni.

2. Zamawiający zwróci Wykonawcy zabezpieczenie należytego wykonania umowy w terminie 30 dni po upływie okresu obowiązywania umowy lub zatrzyma w całości lub części w przypadku niewykonania lub nienależytego wykonania umowy przez Wykonawcę.

3. Zabezpieczenie należytego wykonania umowy służy do pokrycia roszczeń Zamawiającego wynikających z niewykonania lub nienależytego wykonania umowy przez Wykonawcę bez potrzeby uzyskania zgody Wykonawcy.

4. Wykonawca może zmienić formę zabezpieczenia na inną zgodnie z przepisami art. 149 ustawy Prawo zamówień publicznych. Zmiana taka nie powoduje konieczności zmiany treści umowy.

§8 Poufność danych

1. Wykonawca jest zobowiązany do zachowania w tajemnicy informacji, danych i wiedzy, bez względu na formę ich utrwalenia, stanowiących tajemnicę Zamawiającego, uzyskanych w trakcie wykonywania umowy.

2. W szczególności Wykonawca jest zobowiązany zachować w tajemnicy pozyskane od Zamawiającego informacje dotyczące rozmieszczenia i konfiguracji infrastruktury techniczno-systemowej sieci oraz stosowanych zabezpieczeń.

3. Uzyskane przez Wykonawcę, w związku z wykonywaniem umowy, informacje nie mogą być wykorzystane do innego celu, niż do realizacji umowy.

4. Zobowiązanie do zachowania w tajemnicy nie dotyczy informacji, które:

1) stały się publicznie dostępne bez naruszenia przez Wykonawcę postanowień umowy,

2) były znane przed otrzymaniem ich od Zamawiającego i nie były objęte zobowiązaniem do zachowania w tajemnicy wobec jakiegokolwiek podmiotu,

3) podlegają ujawnieniu na mocy przepisów prawa.

5. W terminie 5 dni roboczych od rozwiązania lub wygaśnięcia umowy Wykonawca zobowiązany jest do zwrotu Zamawiającemu lub zniszczenia wszelkich materiałów zawierających informację stanowiącą tajemnicę Zamawiającego, jakie otrzymał lub wytworzył w związku z wykonywaniem umowy, za wyjątkiem jednej kopii ww. materiałów niezbędnych do ewentualnego dochodzenia roszczeń, które zostaną zniszczone z upływem terminu przedawnienia roszczeń. Wykonawca zapewni tym materiałom ochronę w stopniu co najmniej równym poziomowi ochrony, na jakim chroni własne informacje. Potwierdzenie zwrotu ww. materiałów dokumentuje się w protokole, który podpisują Zamawiający i Wykonawca. Niezwłocznie po upływie terminu przedawnienia potencjalnych roszczeń Wykonawca informuje pisemnie Zamawiającego o zniszczeniu kopii materiałów pozostawionych do ewentualnego dochodzenia roszczeń.

6. Osoby wykonujące zadania w związku z realizacją umowy na terenie budynków, pomieszczeń lub części pomieszczeń użytkowanych przez Zamawiającego są zobowiązane do przestrzegania obowiązujących u Zamawiającego uregulowań wewnętrznych dotyczących bezpieczeństwa informacji. Wszystkie osoby biorące udział w realizacji przedmiotu umowy zostaną poinformowane o poufnym charakterze informacji oraz zobowiązane do zachowania ich w poufności. W takim przypadku Wykonawca odpowiedzialny jest za wszelkie naruszenia dokonane przez takie osoby, włącznie z odpowiedzialnością materialną.

7. Zamawiający zastrzega sobie możliwość dochodzenia roszczeń wobec Wykonawcy, w wypadku wyrządzenia przez niego szkód Zamawiającemu lub osobom trzecim, będących wynikiem naruszenia bezpieczeństwa informacji, na zasadach określonych w kodeksie cywilnym.

§9 Postanowienia końcowe

1. W sprawach nie unormowanych niniejszą umową zastosowanie mają przepisy ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (Dz. U. z 2013r., poz. 907 ze zm.), Kodeksu Cywilnego oraz odpowiednie przepisy mające związek z przedmiotem umowy.

2. Wszelkie spory mogące wyniknąć z zawarcia i wykonania umowy, Strony poddają pod rozstrzygnięcie sądu powszechnego właściwego dla siedziby Zamawiającego.

3. Wszelkie zmiany i uzupełnienia dotyczące niniejszej umowy wymagają formy pisemnego aneksu pod rygorem nieważności, z wyłączeniem danych teleadresowych oraz danych zawartych Załączniku nr 7 do umowy (Wykaz osób upoważnionych).

4. Załączniki do umowy stanowią jej integralną część.

5. Umowa zostaje zawarta z chwilą podpisania jej przez obie Xxxxxx.

6. Umowę sporządzono w czterech jednobrzmiących egzemplarzach, po dwa egzemplarze dla każdej ze Stron.

Załączniki:

Załącznik nr 1 – Formularz cenowy

Załącznik nr 2 – Miesięczny raport świadczenia usług (wzór) Załącznik nr 3 – Wykaz placówek

Załącznik nr 4 – Formularz zgłoszenia awarii (wzór)

Załącznik nr 5 – Formularz wykonania zgłoszenia serwisowego (wzór) Załącznik nr 6 – Raport z wykonania przeglądu konserwacyjnego (wzór) Załącznik nr 7 – Wykaz osób upoważnionych

Załącznik nr 8 – Komunikacja pomiędzy HP SM a systemem obsługi incydentów Wykonawcy Załącznik nr 9 – Protokół odbioru licencji

Załącznik nr 10 – Opis przedmiotu zamówienia

ZAMAWIAJĄCY: WYKONAWCA:

........................................... ….......................................

Załącznik Nr 1 do umowy nr (TZ/271/11/14)

Formularz cenowy

Zostanie dołączony po wyborze oferty najkorzystniejszej

Załącznik Nr 2 do umowy nr (TZ/271/11/14)

Miesięczny raport z wykonanych usług

Raport za miesiąc/rok: /	Miesięczny Raport Wykonanych Usług	Data sporządzenia: . .
Dotyczy Umowy:	Wykonawca raportu: Imię i Nazwisko:
Czynności serwisowe (1)
Liczba Zgłoszeń Serwisowych:
Liczba Rozpoczętych Interwencji Serwisowych:
Liczba Zakończonych Interwencji Serwisowych:
Uwagi: (1) Wszystkie wymienione w raporcie czynności mają swoje potwierdzenie w postaci odpowiednich protokołów, których kopie zostaną dołączone jako załączniki do niniejszego raportu.
Podpis osoby sporządzającej raport:
Uwagi osoby odbierającej raport:
Data otrzymania raportu:		Podpis osoby odbierającej raport:

Załącznik Nr 3 do umowy nr (TZ/271/11/14)

Wykaz placówek

Lp.	Oddział	Adres
1.	Białystok	00-000 Xxxxxxxxx, xx. Xxxxxxx 00
2.	Bielsko-Biała	00-000 Xxxxxxx-Xxxxx, xx. Xxxxxxxxxxxx 00
3.	Biłgoraj	00-000 Xxxxxxxx, xx. Xxxxxxxxxx 000
4.	Bydgoszcz	00-000 Xxxxxxxxx, xx. Xxxxxxx Xxxxxx 00
5.	Chorzów	00-000 Xxxxxxx, xx. Xxxxxxxxxxxx 00
6.	Chrzanów	00-000 Xxxxxxxx, xx. Xxxxxxxxxxx 00
7.	Częstochowa	00-000 Xxxxxxxxxxx, xx. Xxxxxxxxxxxx 00/00
8.	Elbląg	00-000 Xxxxxx, xx. Xxxxxxxxx 0
9.	Gdańsk	00-000 Xxxxxx, xx. Xxxxxxxx 00/00
10.	Xxxxxx Xxxx.	00-000 Xxxxxx Xxxxxxxxxxxx, ul. Sikorskiego 42
11.	Jasło	00-000 Xxxxx, xx. Xxxxx 00 b
12.	Kielce	00-000 Xxxxxx, xx. Xxxxxxxxxxx 00
13.	Koszalin	00-000 Xxxxxxxx, xx. Xxxxxxx Xxxxxx 00
14.	Kraków	00-000 Xxxxxx, xx. Xxxxxxxxx 27
15.	Legnica	00-000 Xxxxxxx, xx. Xx. Xxxxxxxxxx 00
16.	Lublin	00-000 Xxxxxx, xx. X. Xxxx 00-00x
17.	Łódź I	00-000 Xxxx, xx. Xxxxxxxxx 0
18.	Łódź II	00-000 Xxxxxxx Xxxx, xx. Xxxxxxxxxxx 0/00
19.	Nowy Sącz	33-300 Nowy Sącz, xx. Xxxxxxxxxxxx 00
20.	Xxxxxxx	00-000 Xxxxxxx, Xx. Konsulatu Polskiego 4
21.	Opole	00-000 Xxxxx, xx. Xxxxxxxxxx 00
22.	Xxxxxx Xxxx.	00-000 Xxxxxx Xxxxxxxxxxxx, ul. Wysocka 1 b
23.	Piła	00-000 Xxxx, xx. Xx. Xxxxxxx 0
24.	Płock	00-000 Xxxxx, Xx. Xxxxxxxxxx Xxxxxxxxxx 0
25.	Poznań I	00-000 Xxxxxx, xx. Xxxxxxxxxxxx 00
26.	Poznań II	00-000 Xxxxxx, xx. Xxxxxxxxxx 00
27.	Radom	00-000 Xxxxx, xx. Xxxxxxxxxxxxx 00 a
28.	Rybnik	00-000 Xxxxxx, xx. Xxxxxxxx 0
29.	Rzeszów	00-000 Xxxxxxx, Xx. Xxxxxxxxxxxx 00
30.	Siedlce	00-000 Xxxxxxx, xx. Xxxxxxxx 00
31.	Słupsk	00-000 Xxxxxx, Xx. Xxxxxxxxxx 0
32.	Sosnowiec	00-000 Xxxxxxxxx, xx. Xxxxxxxxxxx 0
33.	Szczecin	00-000 Xxxxxxxx, xx. Xxxxxxx 00
34.	Tarnów	00-000 Xxxxxx, xx. Xxxxxxxxxx 00
35.	Xxxxxxxx Xxx.	00-000 Xxxxxxxx Xxxxxxxxxx, xx. Xxxxxxxxxx Xxxxxxxx Xxxxxxxxxxx 00/00
36.	Toruń	00-000 Xxxxx, xx. Xxxxxxxxxxx 00/00
37.	Xxxxxxxxx	00-000 Xxxxxxxxx, Xx. Grunwaldzki 1
38.	Warszawa I	00-000 Xxxxxxxx, xx. Xxxxxxxxxx 0/0
39.	Warszawa II	00-000 Xxxxxxxx, xx. Xxxxxxxxxxxxx 00

40.	Warszawa III	00-000 Xxxxxxxx, xx. Xxxxxxxxxxxxx 00
41.	Wrocław	00-000 Xxxxxxx, xx. Xxxxxxxxx 00
42.	Zabrze	41-800 Zabrze, ul. Szczęść Boże 18
43.	Xxxxxxx Xxxx	00-000 Xxxxxxx Xxxx, ul. Kupiecka 65
44.	Centrala ZUS	00-000 Xxxxxxxx, xx. Xxxxxxxx 0, 5

Załącznik Nr 4 do umowy nr (TZ/271/11/14)

FORMULARZ ZGŁOSZENIA AWARII

Część A. Wypełnia pracownik Zamawiającego i wysyła na adres e-mail firmy serwisującej

Nazwa Wykonawcy ....................................................................................................................................................
Data zgłoszenia			Czas zgłoszenia	(godzina,	minut)
	(dzień miesiąc	rok)
Informacja awarii
Status zgłoszenia problemu…………
Opis awarii, uszkodzenia lub innych nieprawidłowości:
Imię i nazwisko osoby zgłaszającej, telefon, fax.				Podpis osoby zgłaszającej

Część B. Wypełnia przedstawiciel Wykonawcy odsyła do

Zamawiającego na adres poczty elektronicznej - ............

Zgłoszenie przyjął

........................................................................................

Nazwisko i imię

Xxxx

(dzień, miesiąc, rok)

Czas

(godzina, minut)

Uwagi:

Podpis osoby przyjmującej zgłoszenie

................................................................................

Załącznik nr 5 do umowy (TZ/271/11/14)

FORMULARZ WYKONANIA ZGŁOSZENIA SERWISOWEGO

Przyczyna interwencji:

zgłoszenie z dnia: ................, godz. ..........

numer zgłoszenia: ....................................

Data i godzina rozpoczęcia usługi serwisowej:

.............................., godz. ..........

Wykonawca usługi:

imię i nazwisko: ...........................................................................

tel.: ................................. tel. kom.: ..................................

Oświadczenie serwisanta o podjętych czynnościach i skuteczności usługi:

…………………………………………………………………………………...………………………………………

…………………………………………………………...……………………

…………………………………………………………………………………...………………………………………

…………………………………………………………...……………………

…...................................... ……………………………….

data i godz. zakończenia podpis serwisanta

Odbiorca usługi:

imię i nazwisko: ..........................................................................

nazwa jednostki organizacyjnej: .......................................................................

adres: ..............................................................................................................................................

tel.: ............................

Oświadczenie Odbiorcy usługi o skuteczności usługi serwisowej:

...........................................................................................................................................................................................

........................ ……………..........................

data i godzina pieczątka i podpis

podpis odbierającego usługę

Załącznik Nr 6 do umowy nr (TZ/271/11/14)

Raport z przeglądu konserwacyjnego

Raport z przeglądu wykonanego w dniach ……………………

W związku z realizacją umowy nr ………………………………… (TZ/271/11/14) z dnia

……… r. Wykonawca przedstawia raport z przeglądu konserwacyjnego oprogramowania Oracle użytkowanego w Zakładzie Ubezpieczeń Społecznych.

Treść raportu z przeglądu:

…………………………………………………………………………………………………

Zalecenia i wnioski końcowe:

…………………………………………………………………………………………………

……………………………… (podpis i pieczątka upoważnionego przedstawiciela Wykonawcy)

Potwierdzamy, zgodnie z wyżej wymienioną umową, wykonanie przeglądu konserwacyjnego oprogramowania Oracle 1

……………………………… (podpis i pieczątka upoważnionego przedstawiciela Zamawiającego)

Uwagi Zamawiającego do przeglądu lub raportu z przeglądu konserwacyjnego oprogramowania Oracle 2

…………………………………………………………………………………………………

……………………………… (podpis i pieczątka upoważnionego przedstawiciela Zamawiającego)

1 podpisuje się w przypadku braku uwag

2 wypełnia się w przypadku uwag Zamawiającego do przeglądu lub raportu z przeglądu konserwacyjnego oprogramowania Oracle Tuxedo

Załącznik Nr 7 do umowy nr (TZ/271/11/14)

Wykaz osób upoważnionych

(zostanie dołączony w dniu zawarcia umowy)

Załącznik Nr 8 do umowy nr (TZ/271/11/14)

STRUKTURA KOMUNIKATÓW XML WYSYŁANYCH Z HP SM I ODBIERANYCH PRZEZ HP SM W ZUS W RAMACH OBSŁUGI ZGŁOSZEŃ SERWISOWYCH

OPIS FUNKCJONALNOŚCI

System HP Service Manager (ZUS) będzie wysyłał na zdefiniowany adres mailowy wiadomość elektroniczną zawierającą w treści niezbędne dane do utworzenia zgłoszenia Usługi Serwisowej. Treścią emaila będzie wyłącznie dokument XML. Email będzie wysyłany w formacie tekstowej (Plain Text Body) z adresu xx@xxx.xx. Komunikaty zwrotne do HP Service Manager (ZUS) należy przysyłać na adres xxxxxxxxxxxxxx@xxx.xx .

!Tu uwaga: jeżeli Państwo będą implementowali jakieś zasady obsługi maili lepiej zastosować reguły filtrowania wiadomości wg adresu nadawcy – niektóre programy pocztowe zachowują się różnie jeśli chodzi o kodowanie znaków i może zajść możliwość błędnego przefiltrowania po temacie wiadomości. Wszystkie dane dotyczące zgłoszenia są zawarte w treści komunikatu w kodzie XML!

STRUKTURA WIADOMOŚCI

Komunikaty wychodzące z HP Service Manager (ZUS) do systemów dostawców zewnętrznych

Struktura komunikatu przesyłanego z HP SM7 w ZUS do systemu Serwisu Zewnętrznego wygląda przykładowo:

Komunikat otwarcia zgłoszenia serwisowego do serwisu zewnętrznego:

<opis>

</opis>

</parametry>

</zs>

Komunikat aktualizacji ZS do serwisu zewnętrznego po zarejestrowaniu idSC:

<opis>

</opis>

</parametry>

</zs>

Wymagany zakres przekazywanej informacji:

• id – identyfikator Zgłoszenia Serwisowego w HP SM7 w ZUS,

• idSC – zewnętrzny identyfikator Zgłoszenia Serwisowego,

• type – typ komunikatu. Dopuszczalne wartości:

− O – Otwarcie. Rejestracja Zgłoszenia Serwisowego w systemie Serwisu Zewnętrznego, z pustym atrybutem idSC.

− A – Aktualizacja. Powtórne wysłanie ZS z HP SM7 w ZUS do SZ. Wypełnione atrybuty id i idSZ. Obowiązkowy element <opis>, możliwy element <parametry>.

− R – Reklamacja. Wypełnione atrybuty id i idSZ. Obowiązkowy element <opis>.

− ZP – Żądanie zmiany programu serwisowego. Wypełnione atrybuty id i idSC oraz element <usluga>, zawierający bieżący poziom (program serwisowy) w HP SM7 w ZUS.

− Z – Zamknięcie. Informacja o zamknięciu zgłoszenia w SM.

Komunikat typu „O” będzie powodował utworzenie zgłoszenia.

Komunikaty typu „A”, „R” oraz „Z” będą powodowały aktualizację informacji w systemie Serwisu Zewnętrznego. Będą one miały znaczenie wyłącznie informacyjne.

Z komunikatem może zostać przesłany załącznik, który zostanie dołączony odpowiednio do zgłoszenia albo incydentu.

• time – data i czas przesłania komunikatu XML,

• cat – kategoria, wartość stała, zawsze „ZUS”,

• usl – informacje o usłudze:

− id – identyfikator Usługi Dostawcy, której dotyczy zgłoszenie, zawarty w polu elementu konfiguracji Zgłoszenia Serwisowego,

− serw – identyfikator Usługi Serwisowej Dostawcy, odpowiadający umowie w rejestrach dla Zgłoszeń Serwisowych,

− poziom – wybrany poziom Usługi Serwisowej Dostawcy, odpowiadający programowi umowy w rejestrach dla Zgłoszeń Serwisowych,

− priorytet – priorytet dotyczący błędu, tylko dla wybranych Usług Dostawcy.

• contact – xxxx kontaktowe (imię i nazwisko, e-mail, telefon) zgłaszającego,

• opis – opis Zgłoszenia Serwisowego.

Pozostałe wartości (opcjonalnie):

• parametry – dodatkowe wartości przekazywane w zgłoszeniu. Obecnie są to wartości z incydentu, z którego utworzono ZS:

− Element Konfiguracji,

− Podkategoria,

− Typ produktu,

− Typ Problemu.

Komunikaty z systemu serwisu zewnętrznego do HP SM7

Odpowiedź z systemu Serwisu Zewnętrznego do HP SM7 w ZUS składa się jedynie z nagłówka oraz elementu opis:

<opis>

</opis>

</zs>

Przykładowo:

<opis>

</opis>

</zs>

Istotne znaczenie ma atrybut type, który w tym przypadku może zawierać następujące wartości:

• O – rejestracja w SZ i nadanie idSZ. Nie zawiera elementu opis.

• P – pytanie do użytkownika. Element <opis> zawiera treść pytania.

• D – Diagnoza zgłoszenia.

• ZN – Zalecenia naprawcze.

• ZP – Potwierdzenie rejestracji żądania programu serwisowego.

• ZT – Zalecenia tymczasowe.

• Z – Prośba o zamknięcie.

Załącznik nr 9 do umowy numer (TZ/271/11/14)

Warszawa, r.

Zakład Ubezpieczeń Społecznych Xx. Xxxxxxxx 0, 0

00-000 Xxxxxxxx

Protokół odbioru licencji

Niniejszym potwierdzam/nie potwierdzam* odbiór bezterminowych licencji na oprogramowanie:

………………………………………..

……………………………………….

zgodnie z umową umowy nr ………………………………… z dnia r.

Uwagi: …………………………………………………………………………………….

Przedstawiciel Zamawiającego Przedstawiciel Wykonawcy

........................................................ .................................................................

(czytelny podpis imię i nazwisko) (czytelny podpis imię i nazwisko)

Załącznik Nr 10 do umowy nr (TZ/271/11/14)

Opis przedmiotu zamówienia:

Przedmiotem zamówienia jest opieka serwisowa oprogramowania ORACLE (Tuxedo, SALT, eLink), nabycie dodatkowych licencji na oprogramowanie: ORACLE Tuxedo (lub równoważych), ORACLE SALT (lub równoważnych), dodatkowych licencji na oprogramowanie serwera aplikacyjnego JEE oraz usługa wsparcia migracji oprogramowania ORACLE.

I. Nabycie dodatkowych licencji na oprogramowanie ORACLE Tuxedo lub równoważych

Wykonawca dostarczy licencje na oprogramowania Oracle Tuxedo lub równoważne, umożliwiające zainstalowanie i uruchomienie tego oprogramowania na posiadanym przez Zamawiającego serwerach. Zamawiający posiada serwery oparte o architekturę procesora Intel Itanium 2 w ramach którego wydzielona zostanie wirtualna partycja dla której przydzielono moc równą 16 rdzeni tegoż procesora. Oprogramowanie zostanie uruchomione na wydzielonej partycji wirtualnej.

Jako rozwiązanie równoważne dla oprogramowania monitora transakcyjnego Oracle Tuxedo rozumie się oprogramowanie, zapewniające spełnienie następujących warunków:

1. Kompatybilność na poziomie binariów z wykorzystywanymi przez Zamawiającego aplikacjami Tuxedo (tzw. serwery Tuxedo).

2. Wbudowana w oprogramowanie koncepcja budowy oraz udostępniania usług biznesowych jako niezależne, atomowe operacje.

3. Możliwość komunikacji oprogramowania z wykorzystywanym przez Zamawiającego oprogramowaniem Tuxedo za pomocą Tuxedo ATMI.

4. Zgodność z interfejsem programistycznym Tuxedo ATMI.

5. Możliwość implementacji usług za pomocą następujących języków programowania: C, C++, COBOL.

6. Możliwość zarządzania i kontrolowania rozproszonych transakcji (monitor transakcyjny) w tym zgodność ze standardem X/Open XA.

7. Możliwość dynamicznego skalowania – zwiększanie / zmniejszanie liczby procesów systemu operacyjnego obsługujących określoną grupę usług implementowanych na platformie.

8. Możliwość konfiguracji oprogramowania jako domeny umożliwiającej komunikację z innymi i użytkownymi przez Zamawiającego domenami Tuxedo. Komunikacja powinna się odbywać za pomocą „TDomain gateway” i umożliwiać określenie zasad komunikacji pomiędzy nową domeną a istniejącymi domenami za pomocą pliku o strukturze zgodnej z DMCONFIG.

9. Interfejsy implementowanych usług muszą być zdefiniowane jako bufory FML/FML32.

10. Możliwość konfiguracji usług za pomocą pliku o strukturze zgodnej z UBBCONFIG.

II. Nabycie dodatkowych licencji na oprogramowanie ORACLE SALT lub równoważnych

Wykonawca dostarczy licencje na oprogramowanie Oracle Service Architecture Leveraging Tuxedo (SALT) lub równoważne, umożliwiające zainstalowanie i

uruchomienie tego oprogramowania na posiadanych przez Zamawiającego serwerach opartym o architekturę procesora Intel Itanium 2 w ramach którego wydzielona zostanie wirtualna partycja dla której przydzielono moc równą 8 rdzeni tegoż procesora. Oprogramowanie zostanie uruchomione na wydzielonej partycji wirtualnej.

Jako rozwiązanie równoważne dla oprogramowania Oracle SALT rozumie się oprogramowanie, zapewniające spełnienie następujących warunków:

1. Możliwość udostępniania usług systemu Tuxedo za pomocą usług Webservices, wymagana zgodność z protokołem SOAP.

2. Możliwość wywołania zewnętrznej usługi Webservce (opartej o protokół SOAP) z poziomu użytkowanego przez Zamawiającego serwera Tuxedo. W ramach implementacji kodu biznesowego usługi Tuxedo powinna być możliwość wykonania/wywołania zewnętrznej usługi Webservice.

3. Oprogramowanie musi wspierać następujące standardy komunikacyjne:

a. SOAP 1.1 (xxxx://xxx.x0.xxx/XX/0000/XXXX-XXXX-00000000/)

b. SOAP 1.2 (xxxx://xxx.x0.xxx/XX/xxxx00-xxxx0/)

c. SOAP with Attachement (xxxx://xxx.x0.xxx/XX/XXXX-xxxxxxxxxxx )

d. MTOM (xxxx://xxx.x0.xxx/XX/xxxx00-xxxx/)

e. UDDI 2.0 (xxxx://xxxx.xxx/xxxx/XxxxxxxxxxxXXX-X0.00-Xxxxxxxxx- 20020719.htm)

f. WSDL 1.1 (xxxx://xxx.x0.xxx/XX/0000/XXXX-xxxx-00000000 )

g. WS-Policy (xxxx://xxxxx.xxxxxxx.xxx/xx/0000/00/xxxxxx/xx-xxxxxx.xxx oraz xxxx://xxxxx.xxxxxxx.xxx/xx/0000/00/xxxxxx/xx-xxxxxxxxxxxxxxxx.xxx )

h. WS-Addressing (xxxx://xxx.x0.xxx/Xxxxxxxxxx/0000/XXXX-xx-xxxxxxxxxx- 20040810/)

i. WS-ReliableMessaging (xxxx://xxxxx.xxxxxxx.xxx/xx/0000/00/xx/xx- reliablemessaging.pdf xxxx://xxxxx.xxxxxxx.xxx/xx/0000/00/xx/XX- RMPolicy.pdf)

j. WS-Security 1.0 (xxxx://xxxx.xxxxx-xxxx.xxx/xxx/0000/00/xxxxx-000000-xxx- soap-message-security-1.0.pdf oraz xxxx://xxxx.xxxxx- xxxx.xxx/xxx/0000/00/xxxxx-000000-xxx-xxxxxxxx-xxxxx-xxxxxxx-0.0.xxx xxxx://xxxx.xxxxx-xxxx.xxx/xxx/0000/00/xxxxx-000000-xxx-x000-xxxxx-xxxxxxx- 1.0.pdf)

k. WS-Security 1.1 (xxxx://xxx.xxxxx- xxxx.xxx/xxxxxxxxxx/xxxxxxxx.xxx/00000/xxx-x0.0-xxxx-xx- SOAPMessageSecurity.pdf xxxx://xxx.xxxxx- xxxx.xxx/xxxxxxxxxx/xxxxxxxx.xxx/00000/xxx-x0.0-xxxx-xx- UsernameTokenProfile.pdf xxxx://xxx.xxxxx- xxxx.xxx/xxxxxxxxxx/xxxxxxxx.xxx/00000/xxx-x0.0-xxxx-xx- x509TokenProfile.pdf)

l. WS-Coordination 1.0 (xxxx://xxxxxxx.xxxxxxx.xxx/xx/0000/00/xxxxxx/)

m. WS-AtomicTransaction 1.0 (xxxx://xxxxxxx.xxxxxxx.xxx/xx/0000/00/xxxx/)

4. Oprogramowanie musi wspierać następujące standardy architektoniczne:

a. SDO (Service Data Objects) - SDO for C++ Specification V2.1 published December, 2006

b. SCA C++ Client and Implementation V0.95

c. SCA Assembly Model V0.96

d. Wsparcie w implementacji usług (webservices) udostępnianych przez Tuxedo w zakresie generacji plików WSDL opisujących interfejs udostępnianych usług Tuxedo bezpośrednio z plików opisujących interfejs oryginalnej usługi Tuxedo (pliki FML/FML32).

III. Nabycie dodatkowych licencji na oprogramowanie serwera aplikacyjnego JEE

Dostawa licencji umożliwiających uzyskanie poniższej funkcjonalności serwera aplikacyjnego JEE wraz z narzędziami umożliwiającymi tworzenie i zarządzanie usługami w architekturze zorientowanej na usługi.

1. Należy dostarczyć oprogramowanie umożliwiające uruchomienie oraz pracę na serwerze o architekturze procesora x86_64 z co najmniej przydzielonymi 8 rdzeniami.

2. Oprogramowanie musi umożliwiać instalację na serwerach z systemem operacyjnym co najmniej Windows lub Linux (w tym RedHat Enterprise).

3. Wsparcie dla Java SE wersja 6

4. Certyfikacja standardu Java EE wersja 5

5. Certyfikacja Spring Framework

6. Wbudowana integracja EJB 3.0 i Spring

7. Wbudowane wsparcie dla specyfikacji Commons J Work Manager API i Timer API

8. Wbudowane wsparcie dla specyfikacji JSR-88 – plany wdrożeń (Deployment Plan)

9. Wbudowana obsługa standardu Web services WS-ReliableMessaging 1.1 i WS- ReliableMessaging Policy 1.1

10. Wbudowana obsługa standardu Web services WS-Trust 1.3

11. Wbudowana obsługa standardu Web services WS-SecureConversation 1.3

12. Wbudowana obsługa standardu Web services WS-Security 1.1

13. Wbudowana obsługa standardu Web services WS-SecurityPolicy 1.2

14. Wbudowana obsługa standardu Web Service MTOM\XOP – SOAP Message Transmission Optimization Mechanism/XML-binary Optimized Packaging

15. Serwer aplikacyjny powinien mieć możliwość realizacji odpowiedniego poziomu bezpieczeństwa w zakresie:

a. Uwierzytelniania

b. kontroli dostępu

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

16. Serwer aplikacyjny powinien mieć możliwość uwierzytelniania i szyfrowania usług takich jak: użytkownik/hasło, passphrase, weryfikacja hostów, brak uwierzytelniania, tunelowanie wywołań SSL, certyfikaty X.509

17. Wbudowana, dostępna poprzez konfigurację, integracja z katalogami użytkowników, grup i ról – LDAP, Active Directory, bazy danych, Windows XX, X.000, SAML lub tworzenie własnych baz użytkowników

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

19. 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 (CLV/CLR), audytowania, itd.

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

21. Wbudowana obsługa standardów SAML 1.1, SAML 2.0 lub wyższych

22. Wbudowana integracja w ramach Single-Sign-On (SSO) z takimi technologiami jak SAML (1.1, 2.0), Kerberos (SPENEGO, Windows 2000 i 2003, .NET), Web service

(SAML)

23. Wbudowane API do funkcjonalności przeszukiwania i walidacji certyfikatów X.509 (CLV – Certificate Lookup and Validation)

24. Obsługa mechanizmów autoryzacji i mapowania ról przy użyciu standardu XACML 2.0;

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

26. Wbudowana obsługa standardu Common Secure Interoperability Version 2 (CSIv2)

27. Wbudowana obsługa protokołu SNMP v3 wraz z HMAC-MD5-96, HMAC-SHA-96;

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

29. Wbudowane automatyczne samostrojenie się serwera aplikacyjnego (self-tuning)

30. Wbudowana możliwość klastrowania połączeń JDBC

31. Wbudowana możliwość klastrowania JMS (w tym automatyczne przełączanie klientów JMS w momencie failover serwerów JMS)

32. Możliwość klastrowania obiektów typu singelton w aplikacjach

33. Obsługa klastrowania dla mechanizmu Store-and-Forward

34. Obsługa klastrowania Web-services zgodnych z WS-ReliableMessaging

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

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

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

38. Wbudowane wsparcie dla przechowywania (persistence) sesji webowych i EJB w pliku, bazie danych i pamięci

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

40. 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), replikowanie sesji z użyciem trybów IP unicast i multicast, a także wspierać replikację sesji pomiędzy klastrami serwerów aplikacyjnych (intra-cluster) poprzez sieci LAN/MAN/WAN

41. 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 i/lub ich komponentów), czasy odpowiedzi, min/max liczba wątków, itp.

42. 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”;

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

44. Możliwość uruchamiania wielu działających równocześnie wersji tej samej aplikacji. 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ę

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

46. Wbudowana obsługa Logging Last Resource - optymalizacji transakcji rozproszonych (XA)

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

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

49. Wbudowany interfejs do JMS dla aplikacji napisanych w C (JMS C API)

50. Wbudowany interfejs do JMS dla aplikacji napisanych w Microsoft .NET C# (JMS C# API)

51. Wbudowana obsługa zawieszania i wznawiania transakcji rozproszonych (XA) w ramach JTA API (suspend/resume)

52. Wbudowany mechanizm współpracy z zewnętrznymi menedżerami transakcji rozproszonych (third-party, foreign transaction managers)

53. Wbudowana obsługa propagacji dodatkowych danych w ramach żądań (content propagation)

54. Obsługa mechanizmu Store-and-Forward, czyli gwarantowanego, niezawodnego przesyłania komunikatów pomiędzy instancjami serwerów aplikacyjnych

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

56. Wbudowana obsługa Web services, które mogą wykonywać operacje na kliencie (callback Web service)

57. Wbudowane wsparcie dla buforowanego wywoływania Web services

58. Wbudowane wsparcie dla zewnętrznych dostawców usług kolejkowych (np. MQSeries) wraz z przenoszeniem kontekstów security i transakcyjnego

59. Zarządzanie i monitorowanie wielu aplikacji wdrożonych na różnych instancjach serwera aplikacyjnego

60. Zarządzanie klastrami serwerów aplikacyjnych

61. Monitorowanie zasobów serwerów aplikacyjnych takich jak póle połączeń JDBC, kolejki JMS, źródła danych

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

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

64. Możliwości monitorowania poziomu dostępności usługi (SLA) względem zdefiniowanych parametrów (mierników)

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

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

67. Automatyczny restart serwera i/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.

68. Możliwość ograniczenia liczby sesji HTTP w serwerze tworzonych przez daną aplikację

69. 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 do ruchu związanego z funkcjonowaniem klastra (replikacja sesji) – dane związane z tymi funkcjami mogą być przesyłane poprzez inne karty sieciowe/podsieci, itp.

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

71. Możliwość konfiguracji i zarządzania środowiskiem serwerów aplikacyjnych równocześnie poprzez: konsole webowe, skrypty (np. Jython), programowo (Java API), SNMP.

72. 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 (np. upgrade wersji serwera aplikacyjnego).

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

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

75. Wbudowany mechanizm automatycznej naprawy transakcji (transaction recovery) podczas restartu serwera aplikacyjnego.

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

77. Dostarczone licencje nie mogą ograniczać liczby użytkowników końcowych korzystających z oprogramowania ani liczby przetwarzanych dokumentów, plików, żądań, komunikatów. Licencje nie mogą być ograniczone czasowo.

78. Wszystkie komponenty oferowanego oprogramowania powinny być gotowe w momencie złożenia oferty oraz muszą posiadać gotową dokumentację w języku polskim lub angielskim. Dokumentacja powinna być publicznie dostępna lub możliwa do wglądu dla Zamawiającego w momencie złożenia oferty.

79. Wsparcie podstawowych technologii programistycznych (API pozwalające implementować komunikację aplikacji z infrastrukturą cache)., w tym:

a. Java,

b. Technologia .NET

c. C/C++.

80. Wsparcie funkcjonalności związanej z przechowywaniem sesji (persystencja sesji http, kontekstu usług typu Servlet oraz kontekstu usług typu Session EJB) dla co najmniej następujących kontenerów aplikacyjnych:

a. Tomcat 6

b. IBM Websphere v7

c. Oracle WebLogic Server 10.x.

d. Sun One Application Server 9.x / Glassfish

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

82. Możliwość przechowywania obiektów w strukturze kolekcji (Klucz, Wartość)

83. Wsparcie modelu obiektowego przechowywanych danych

84. Oprogramowanie infrastruktury cache musi zapewniać mechanizm rozproszonej pamięci operacyjnej (ang. Single System Image)

85. Możliwość śledzenia zmian w danych znajdujących się w pamięci cache

86. Możliwość równoległego wyszukiwania danych oraz możliwość tworzenia indeksów

87. Oprogramowanie infrastruktury cache musi zapewniać funkcjonalność zapytań ciągłych, co oznacza możliwość otrzymywania zawsze aktualnych wyników wyszukiwania.

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

89. Możliwość stosowania / budowania własnych funkcji agregujących.

90. Oprogramowanie infrastruktury cache musi zapewniać mechanizmy wysokiej dostępności i ochrony danych przed awariami

91. Możliwość klastrowania węzłów cache

92. Oprogramowanie infrastruktury cache musi zapewniać płynne dodawanie i usuwanie węzłów klastra cache

93. Oprogramowanie infrastruktury cache musi zapewniać przezroczystą obsługa awarii pojedynczych węzłów.

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

95. Oprogramowanie infrastruktury cache musi zapewniać mechanizm cache, pomiędzy aplikacją a drugą aplikacją lub bazą danych

96. Oprogramowanie infrastruktury cache musi zapewniać persystencję przechowywanych danych w bazie danych

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

98. Oprogramowanie infrastruktury cache musi zapewniać mechanizm read through w komunikacji na linii aplikacja, cache, baza danych

99. Oprogramowanie infrastruktury cache musi zapewniać mechanizm write through w komunikacji na linii aplikacja, cache, baza danych

100. Oprogramowanie infrastruktury cache musi zapewniać mechanizm write behind w komunikacji na linii aplikacja, cache, baza danych

101. Mechanizm write behind musi zapewniać możliwość kolejkowania zapisów do bazy danych

102. Mechanizm kolejkowania żądań związanych z bazą danych musi być odporny na awarie (musi być automatycznie tworzona kopia zapasowa kolejek)

103. Możliwość rozszerzenia cache do pracy w sieci WAN (odporność na mniejsze przepustowości oraz większe opóźnienia)

104. Oprogramowanie infrastruktury cache musi zapewniać mechanizm wyzwalaczy (ang. triggers)

105. Możliwość usuwania z pamięci kopii danych po zapisaniu ich do persystentnego repozytorium danych (np. bazy danych)

Poprzez narzędzia umożliwiające tworzenie usług w architekturze zorientowanej na usługi rozumie się warstwę fasady usług – aplikacji ESB (ang. Enterprise Service Bus).

1. Należy dostarczyć oprogramowanie umożliwiające uruchomienie oraz pracę na serwerze o architekturze procesora x86_64 z co najmniej przydzielonymi 8 rdzeniami.

2. Oprogramowanie musi umożliwiać instalację na serwerach z systemem operacyjnym co najmniej Windows lub Linux (w tym RedHat Enterprise).

3. Oprogramowanie ESB będzie oparte o serwer aplikacji zgodny ze standardem JEE (Java Enterprise Edition).

4. ESB musi posiadać mechanizmy programowego klastrowania krytycznych elementów architektury ESB.

5. ESB musi posiadać mechanizmy równoważenia obciążenia (load-balancing) wykorzystywane w sytuacjach zwiększonego obciążenia.

6. ESB musi umożliwiać skalowanie, rekonfigurację, osadzanie nowych usług bez zakłócania pracy innych aplikacji czy realizowanych operacji biznesowych.

7. ESB musi być wysoce skalowalne i zapewniać możliwość skalowania pionowego (maszyny wieloprocesorowe) jak i poziomego (farmy serwerów). Dokładanie kolejnych serwerów do grupy nie może wymagać wyłączenia i reinstalacji pracujących serwerów.

8. ESB musi umożliwiać odtworzenie stanu systemu sprzed awarii. Odtworzenie obejmuje całość działań, jakie trzeba wykonać aby system funkcjonował zgodnie z założeniami w szczególności: konfigurację szyny, serwera aplikacyjnego, na którym działa, systemu operacyjnego, powiązanych baz danych oraz wszystkich innych elementów systemu umożliwiających bezawaryjną pracę systemu.

9. ESB zawierać wbudowane wsparcie dla buforowanego wywoływania Web services (buforowanie w Infrastrukturze Cache)

10. Wymagany jest opis proponowanego systemu kolejkowego (komunikacja asynchroniczna), możliwości w zakresie ustanawiania QoS dla: usług, kolejek, komunikatów w kolejkach

11. Szyna ESB musi posiadać mechanizm definiowania, implementacji, wdrażania i zarządzania usługami realizującymi dostęp do integrowanych systemów.

12. Usługi mogą być elementarne, tworzone jako konfiguracja pewnych modułów lub posiadać większą logikę integracyjną (np. sekwencja wywołań kilku usług).

13. Szyna ESB zakłada istnienie usług prywatnych i publicznych. Usługi prywatne są dostępne jedynie w obrębie platformy integracyjnej i nie mogą być bezpośrednio wywoływane przez klientów systemu. Ich zadaniem jest realizowanie atomowych operacji, z których budowane są usługi publiczne.

14. Usługi publiczne są widoczne dla klientów platformy integracyjnej poprzez:

a. punkt dostępu do usługi stanowiący adres sieciowy usług w ramach infrastruktury ESB

b. punkt dostępu do definicji usługi (adres URL) - stanowiący adres sieciowy dokumentu WSDL opisującego usługę.

15. Każda usługa publiczna realizuje konkretny scenariusz (proces) integracyjny. Wspólnym protokołem komunikacyjnym usług publicznych i prywatnych musi być SOAP, a protokołem transportowym HTTP lub HTTPS. W przypadku komunikacji asynchronicznej wspólnym protokołem transportowym musi być transport oparty o kolejki (np. JMS). Funkcjonalność tworzona w ramach szyny usług musi być udostępniana w postaci atomowych usług.

16. Usługi systemu opisane są w Katalogu Usług. Każda pozycja katalogu opisując usługę zawiera:

a. unikalną nazwę;

b. definicję wejścia i wyjścia usługi;

c. implementację logiki realizowanej przez usługę;

x. xxxxxxxx ją opisujące – zgodne ze specyfikacją Web Services Metadata Exchange (WS-MetadataExchange);

e. listę błędów zgłaszanych przez usługę;

f. dokumentację.

17. Oprogramowanie musi być zgodne ze standardami:

a. WSDL 1.1;

b. SOAP 1.2;

c. SOAP with Attachments;

d. UDDI 3.0.

18. ESB musi zapewniać pełne wsparcie obsługi dokumentów XML. W ramach obsługi dokumentów XML, ESB musi wspierać możliwość:

a. tworzenia i parsowania komunikatów XML,

b. walidacji komunikatów na podstawie definicji XMLSchema i DTD,

c. obsługi dużych dokumentów XML (do 100MB),

d. transformacji komunikatów – dokument XML na inny dokument XML oraz pomiędzy dokumentem XML i innym formatem (w obie strony),

e. poprawnej obsługi stron kodowych obsługujących polskie znaki.

19. W ramach obsługi protokołu SOAP i Web Services dla usług konsumowanych jak i udostępnianych ESB musi zapewniać:

a. możliwość konsumowania oraz udostępniania usług w standardzie webservices (WSDL 1.1, SOAP 1.1 i 1.2, SOAP with Attachements);

b. standard WS-Security;

c. standard WS-Policy;

d. pożądane jest, aby platforma wspierała inne standardy WS określone specyfikacjami konsorcjum OASIS (xxxx://xxx.xxxxx-xxxx.xxx);

e. wykorzystanie rejestrów UDDI (rejestr taki należy utworzyć w ramach systemu, ESB ma mieć także możliwość współpracy z zewnętrznymi rejestrami UDDI).

20. ESB musi dostarczać usługi transformacji komunikatów XML w modelach jeden do wielu i wiele do jednego, co najmniej przy wykorzystaniu języka XSLT 1.0 (XSL

Transformations, Extensible Stylesheet Language Transformations).

21. ESB musi dostarczać usługi translacji komunikatów

22. ESB musi dostarczać usługi translacji protokołów pozwalające na podłączanie usług według różnych protokołów. ESB musi zapewniać dowolne łączenie obsługiwanych protokołów między sobą.

23. ESB musi umożliwiać routing komunikatów, oparty na treści dokumentów XML i regułach biznesowych.

24. ESB musi umożliwiać filtrowanie komunikatów na podstawie zawartości, przy wykorzystaniu parametrów definiowanych przez użytkownika.

25. ESB musi umożliwiać trwałe przechowywanie komunikatów pod warunkiem, że nie prowadzi to do zbytniego obciążenia systemu.

26. ESB musi umożliwiać realizację scenariuszy integracyjnych w oparciu o model synchroniczny i asynchroniczny.

27. ESB musi umożliwiać nadawanie priorytetu komunikatom w warstwie transportowej (komunikacja asynchroniczna). W szczególności ESB musi obsługiwać nadawanie priorytetów komunikatom na podstawie treści komunikatu. ESB musi także umożliwiać zmianę wielkości puli wątków (per usługa) obsługujących synchroniczne żądania http.

28. ESB musi umożliwiać integrację relacyjnych baz danych na poziomie danych i wywoływania procedur bazodanowych.

29. ESB musi umożliwiać integrację aplikacji zbudowanych w co najmniej technologiach J2EE, .Net.

30. ESB musi wspierać co najmniej następujące standardy komunikacji: SOAP, JMS, JCA, HTTP, HTTPS, FTP, SFTP.

31. ESB musi zawierać wbudowane wsparcie do udostępniania Web services typu REST

32. Warstwa komunikacyjna ESB musi umożliwiać zachowanie:

a. Integralności

b. niezaprzeczalności,

c. poufności;

d. autentyczności komunikacji.

33. ESB musi umożliwiać raportowanie informacji o incydentach w zakresie bezpieczeństwa w szczególności nieuprawnionego logowania i informowania o incydentach na szynie.

34. Bezpieczeństwo usług zbudowanych w oparciu o technologię Web Services musi bazować na standardzie OASIS WS-S (Web Services Security).

35. ESB musi umożliwiać szyfrowanie i podpisywanie komunikatów XML zgodnie z obowiązującymi przepisami.

36. ESB musi umożliwiać podpisywanie komunikatów XML zgodnie ze standardem Advanced Electronic Signature (XAdES).

37. Minimalna długość klucza szyfrującego w przypadku zastosowania algorytmów symetrycznych musi wynosić 128 bitów, natomiast w przypadku zastosowania algorytmów asymetrycznych – 1024 bity.

38. ESB musi umożliwiać weryfikację statusu unieważnienia certyfikatu poprzez mechanizm CRL.

39. ESB musi umożliwiać weryfikację statusu certyfikatu poprzez mechanizm OCSP.

40. ESB musi umożliwiać ograniczenie wywołań usług, ochronę wydajności adapterów oraz zajętości kolejek

41. ESB musi być wyposażona w narzędzia do monitorowania i zarządzania wytworzonego oprogramowania.

42. Wraz z oprogramowaniem ESB zostaną dostarczone niezbędne skrypty oraz narzędzia wspierające przełączanie aktywności pomiędzy węzłami szyny usług

43. Oprogramowanie ESB zapewni wsparcie w zakresie realizacji testów wydajnościowych

i funkcjonalnych: zaślepki, symulatory, skrypty automatyzujące testy, konsola wywoływania ręcznego usług

44. ESB musi zapewniać możliwość kontroli wprowadzanych zmian oraz ich cofnięcia

45. ESB zapewni możliwość eksportu ustawień konfiguracyjnych, a następnie importu na innej instancji szyny usług

46. Produkt realizujący funkcjonalność ESB musi mieć zagwarantowaną długość życia (wsparcia, uaktualnień) na 5 lat od daty wydania produktu, bez konieczności instalacji nowych wersji produktu.

47. Nowe wersje produktu nie mogą odbierać możliwości korzystania ze wsparcia z poprzednich wersji w okresie długości ich życia.

48. Gwarancja niezmienności (kompatybilności) interfejsów programistycznych produktu przez okres jego życia, tj., uaktualnienia nie sprawią, że sposób użycia niektórych funkcji ulegnie zmianie.

49. Produkt realizujący funkcjonalność ESB musi gwarantować automatyczną dystrybucję aktualizacji oprogramowania, powiadomienia o zagrożeniach.

50. Wsparcie w procesie wytwarzania i eksploatacji produkcyjnej oprogramowania dostępne od producenta lub autoryzowanego partnera producenta. Możliwość korzystania ze wszystkich wersji ESB w ramach wsparcia technicznego.

51. Dostarczone licencje nie mogą ograniczać liczby użytkowników końcowych korzystających z oprogramowania ani liczby przetwarzanych dokumentów, plików, żądań, komunikatów. Licencje nie mogą być ograniczone czasowo.

52. Wszystkie komponenty oferowanego oprogramowania powinny być gotowe w momencie złożenia oferty oraz muszą posiadać gotową dokumentację w języku polskim lub angielskim. Dokumentacja powinna być publicznie dostępna lub możliwa do wglądu dla Zamawiającego w momencie złożenia oferty.

W celu zarządzania cyklem życia usług wymagane jest dostarczenie również dedykowanego narzędzia.

1. Należy dostarczyć oprogramowanie umożliwiające uruchomienie oraz pracę na serwerze o architekturze procesora x86_64 z co najmniej przydzielonymi 4 rdzeniami.

2. Oprogramowanie musi umożliwiać instalację na serwerach z systemem operacyjnym co najmniej Windows lub Linux (w tym RedHat Enterprise).

3. Oprogramowanie musi wspierać zarządzanie cyklem życia usług, procesów, kompozytów i innych artefaktów związanych z architekturą SOA

4. Oprogramowanie musi przechowywać zasoby związane z architekturą usługową oraz powiązania między nimi

5. Oprogramowanie musi umożliwiać automatyczną synchronizację danych w repozytorium ze środowiskami deweloperskimi (IDE) oraz ze środowiskami wykonawczymi (szyna usługowa, silnik procesów biznesowych)

6. Oprogramowanie musi udostępniać elastyczny i rozszerzalny model obiektów, pozwalający na kategoryzację zasobów w architekturze SOA, w szczególności musi istnieć możliwość konfiguracyjnego dodawania nowych typów obiektów oraz rozszerzania definicji typów obiektów o nowe atrybuty.

7. Oprogramowanie musi umożliwiać wgląd zarówno w aktualnie wykorzystywane zasoby SOA, jak i w zasoby dopiero planowane lub znajdujące się w fazie produkcji.

8. Oprogramowanie w oparciu o model relacji pomiędzy obiektami musi umożliwiać analizę wpływu zmian w poszczególnych zasobach SOA na inne obszary/zasoby.

9. Oprogramowanie musi posiadać wbudowany silnik procesów biznesowych, umożliwiający automatyzację powtarzalnych procesów związanych z cyklem życia usług (rejestracja zasobów, zatwierdzenia, zmiana atrybutów, eskalacje)

10. Oprogramowanie musi udostępniać moduł raportowy pozwalający nadzorować jakość usług w SOA (raporty na temat reużywalność, zgodności z pryncypiami architektury, SLA)

11. Oprogramowanie musi działać w architekturze trójwarstwowej, dostęp do interfejsu użytkownika musi być możliwy przez przeglądarkę internetową.

12. Dostęp do repozytorium musi być zrealizowany w oparciu o role. Musi istnieć możliwość konfiguracyjnego dostosowania ról do wymagań zamawiającego, co najmniej w zakresie nazw ról oraz zakresu uprawnień przydzielonych do ról.

13. Oprogramowanie musi umożliwiać uwierzytelnienie użytkowników w zewnętrznym katalogu użytkowników, co najmniej w MS Active Directory lub innym zgodnym z LDAP.

14. Oprogramowanie musi udostępniać wyszukiwanie zasobów SOA poprzez następujące mechanizmy:

a. drzewo zasobów (wymagana możliwość filtrowania)

b. wyszukiwanie tekstowe

c. wyszukiwanie według atrybutów i kategorii

15. Interfejs użytkownika musi udostępniać komponent graficzny prezentujący relacje wybranego obiektu z innymi zasobami w postaci grafu.

16. Oprogramowanie musi umożliwiać eksport danych na temat wybranego obiektu co najmniej w następującej formie: Excel, PDF, ZIP

17. Oprogramowanie musi udostępniać użytkownikom możliwość subskrybcji na zdarzenie zmiany wersji określonego obiektu. Informacja o zdarzeniu dostarczana kanałem email.

18. Oprogramowanie musi udostępniać edytory pozwalające co najmniej:

a. konfigurować obiekty prezentowane w interfejsie użytkownik

b. konfigurować listy wartości

c. konfigurować kategoryzacje obiektów

d. konfigurować relacje pomiędzy obiektami

19. Oprogramowanie musi udostępniać narzędzie import/export pozwalające na wymianę poszczególnych zasobów przechowywanych w repozytorium, jak również synchronizację konfiguracji repozytorium (typy, relacje, kategoryzacje)

20. Oprogramowanie musi posiadać interfejs programistyczny pozwalający na automatyczne rejestrowanie zasobów i zmian w zasobach na poziomie repozytorium oraz wykrywanie z poziomu repozytorium użycia określonego zasobu na poziomie środowisk deweloperskich.

21. Dostarczone licencje nie mogą ograniczać liczby użytkowników końcowych korzystających z oprogramowania ani liczby przetwarzanych dokumentów, plików, żądań, komunikatów. Licencje nie mogą być ograniczone czasowo.

22. Wszystkie komponenty oferowanego oprogramowania powinny być gotowe w momencie złożenia oferty oraz muszą posiadać gotową dokumentację w języku polskim lub angielskim. Dokumentacja powinna być publicznie dostępna lub możliwa do wglądu dla Zamawiającego w momencie złożenia oferty.

IV. Opieka serwisowa oprogramowania ORACLE (Tuxedo, SALT, eLink)

przez wykwalifikowane w zakresie technicznym osoby, które udostępni Wykonawca, zdolne do świadczenia pomocy serwisowej w zakresie oprogramowania Oracle (Tuxedo, SALT, eLink) będącego przedmiotem serwisowania, na poziomie zgodnym z wymaganiami umowy.

2. Wykonawca w dniu zawarcia umowy przekaże Zamawiającemu wykaz osób upoważnionych upoważnionych do rozwiązywania problemów i współpracy z Zamawiającym w celu realizacji umowy.

3. Wykonawca gwarantuje świadczenie usługi opieki serwisowej i możliwość zgłaszania problemów drogą, faksową lub elektroniczną w trybie ciągłym 24 godziny na dobę 7 dni w tygodniu 365 dni w roku.

4. Zgłoszenia awarii następować będzie z wykorzystaniem systemu obsługi zgłoszeń Zamawiającego (HP Service Manager). Za moment zgłoszenia awarii uznany będzie czas przesłania do Wykonawcy Formularza zgłoszenia awarii.

5. Do czasu integracji systemu obsługi zgłoszeń Zamawiającego z systemem obsługi zgłoszeń Wykonawcy, maksymalnie 2 miesięcy od daty zawarcia Umowy, oraz w przypadku awarii systemu obsługi zgłoszeń Zamawiającego (HP Service Manager), o czym Zamawiający niezwłocznie poinformuje Wykonawcę lub systemu obsługi zgłoszeń Wykonawcy, Strony będą dokonywać zgłoszeń na Formularzu zgłoszenia awarii oraz wymieniać komunikaty za pośrednictwem poczty elektronicznej na uzgodnione adresy e-mail, z uwzględnieniem ust. 6. Wykonawca zobowiązany jest do niezwłocznego poinformowania Zamawiającego o awarii swojego systemu obsługi zgłoszeń. W przypadku braku takiej informacji, zgłoszenia awarii dokonane przez Zamawiającego przez system HP Service Manager do systemu Wykonawcy będą uznane za dostarczone. O fakcie integracji systemów Wykonawca pisemnie poinformuje Zamawiającego.

6. Adresy e-mail Zamawiającego i Wykonawcy służące do zgłaszania i obsługi awarii w przypadkach opisanych w ust 5 . Strony przekażą sobie wzajemnie w terminie 3 dni od daty zawarcia Umowy.

7. Wykonawca nie później niż w ciągu 30 minut od momentu otrzymania zgłoszenia potwierdzi przyjęcie zgłoszenia w formie takiej jak otrzymał zgłoszenie. W przypadku braku potwierdzenia w tym czasie Zamawiający kontaktuje się z Wykonawcą w celu wyjaśnienia przyczyny braku potwierdzenia oraz ustalenia ewentualnego sposobu rejestracji zgłoszenia u Wykonawcy.

8. Wykonanie zgłoszenia serwisowego zostanie potwierdzone podpisaniem protokołu a następnie przesłaniem potwierdzenia do systemu obsługi zgłoszeń Zamawiającego (HP Service Manager), w którym załączony będzie skan podpisanego Formularza wykonania zgłoszenia serwisowego. Czas otrzymania przez Zamawiającego potwierdzenia w systemie obsługi zgłoszeń Zamawiającego (HP Service Manager) będzie czasem wykonania zgłoszenia. Dopuszcza się opóźnienie w dosłaniu skanu podpisanego Formularza wykonania zgłoszenia serwisowego do systemu obsługi zgłoszeń Zamawiającego (HP Service Manager) do 2 dni roboczych Zamawiającego, jednak opóźnienie to nie zmienia czasu wykonania zgłoszenia.

9. W reakcji na problemy zgłoszone przez Zamawiającego, Wykonawca prześle szczegółowy plan swoich działań w związku z dokonanym zgłoszeniem:

1) Problemu krytycznego - w ciągu 12 godzin zegarowych, od zgłoszenia przez Zamawiającego

2) Problemu niekrytycznego - w ciągu 48 godzin zegarowych, od zgłoszenia przez Zamawiającego

3) Status zgłoszenia problemu określa Zamawiający.

10. Wykonawca jest zobowiązany do przedstawienia informacji pisemnej (e-mail lub fax) o

stanie zgłoszeń zawierającej co najmniej uszczegółowienie objawów, diagnozę, podjęte i planowane czynności naprawcze, przewidywany czas naprawy. W przypadku zgłoszenia problemu krytycznego, informacja pisemna o stanie zgłoszenia, będzie udzielana nie rzadziej niż raz na 48 godzin od momentu zgłoszenia, a w przypadku innych zgłoszeń nie rzadziej niż raz na 168 godzin od momentu zgłoszenia.

11. Wykonawca zobowiązuje się do dostarczenia poprawek wynikających z błędów oprogramowania (tzw. support pack’ów), aktualizacji oprogramowania (tzw. update’ów) lub nowych jego wersji zmieniających funkcjonalność (tzw. upgrade’ów), oraz zapewni Zamawiającemu wsparcie w trakcie ich instalacji w czasie obowiązywania umowy.

12. Wykonawca w dniu podpisania umowy zapewni ciągły dostęp do:

1) stron internetowych producenta oprogramowania z aktualną bazą wiedzy na temat oprogramowania Oracle będącego przedmiotem serwisowania;

2) inżynierów supportowych zdolnych do dokonywania zmian w kodzie oprogramowania Oracle oraz odbycia wizyt serwisowych w siedzibie Zamawiającego;

3) elektronicznej dystrybucji oprogramowania;

4) dokumentacji produktów.

13. Wykonawca zapewni Zamawiającemu e-mail`owe i telefoniczne konsultacje w zakresie oprogramowania Oracle oraz jego współpracy z platformami, na których jest osadzone, od poniedziałku do piątku z wyłączeniem świąt i dni ustawowo wolnych od pracy, w godzinach w godz. 8.00 – 16.00.

14. Wykonawca będzie sprawdzał i informował na bieżąco Zamawiającego o poprawności zainstalowanego oprogramowania Oracle w zakresie poziomu patchowania, aktualności i kompletności w stosunku do aktualnie obowiązującego najnowszego poziomu dla danej wersji.

15. Wykonawca, w 3, 6, 9 oraz 11 miesiącu od dnia zawarcia umowy, jest zobowiązany do dokonywania przeglądów konserwacyjnych oprogramowania, w szczególności na następujących zasadach:

1) sprawdzanie poprawności oprogramowania Oracle w zakresie wersji, poziomu patchowania i kompletności,

3) testowanie diagnostyczne, regulacje, strojenia oraz zabiegi konserwacyjne mające na celu utrzymanie oprogramowania w prawidłowym stanie,

4) wszystkie czynności mają być wykonane w sposób zgodny z zaleceniami producenta oprogramowania oraz niezbędny do zapewnienia jego poprawnej i wydajnej pracy,

5) zakończenie każdego z przeglądów konserwacyjnych zostanie potwierdzone raportem sporządzonym przez Wykonawcę (stanowiącym załącznik nr 6 do umowy), zawierającym zakres wykonanych prac oraz zalecenia i wnioski końcowe.

16. Wykonawca zobowiązany jest do sporządzania i przekazywania Zamawiającemu raz w miesiącu zbiorczego Miesięcznego raportu z wykonanych usług opieki serwisowej oprogramowania Oracle.

17. Wykonawca dostarczy Miesięczny raport świadczenia usług oraz Raport z wykonania przeglądu konserwacyjnego nie później, niż do 5 dnia następnego miesiąca, po upływie okresu objętego raportem.

18. Zamawiający potwierdzi raport, o którym mowa w ust. 16, lub zgłosi do niego uwagi w terminie 3 dni od daty jego otrzymania.

19. Usługa opieki serwisowej świadczona przez Wykonawcę będzie realizowana w Centralnym Ośrodku Obliczeniowym (COO) i Oddziałach ZUS.

20. Wykonawca zapewni Zamawiającemu wsparcie proaktywne poprzez:

a. inwentaryzację usług Oracle i korzystających z nich aplikacji. Spodziewanym efektem ww. prac jest przygotowanie zestawienia usług Oracle działających w obrębie systemu KSI wraz ze wskazaniem na obsługujące je serwery, domeny Oracle, w których są uruchamiane oraz korzystające z nich aplikacje biznesowe. Inwentaryzacja będzie wykonywana dwa razy w ciągu roku i jej wynik będzie przedstawiany Zamawiającemu w postaci aktualnego zestawienia usług Oracle.

b. wsparcie przy migracji oprogramowania Oracle z obecnie posiadanej platformy (HP-UX dla procesorów Itanium) do platformy wskazanej przez Zamawiającego.

c. wsparcie przy podniesieniu wersji oprogramowania Oracle z obecnie posiadanej wersji do wersji wskazanej przez Zamawiającego.

d. wsparcie przy przeniesieniu wskazanych usług systemu KSI uruchomionych na Oracle na platformie docelowej.

g. wsparcie przy udostepnieniu usług działających w środowiskach Oracle dla korporacyjnej architektury SOA podczas przebudowy istniejących aplikacji KSI bądź tworzenia nowych funkcjonalności.

21. Wykonawca w ramach budowania centrum kompetencyjnego po stronie Zamawiającego w trakcie trwania Umowy będzie systematycznie w sposób ciągły na żądanie Zamawiającego przekazywał wiedzę dotyczącą wykorzystywanego oprogramowania Oracle, sposobu rozwiązywania problemów serwisowych oraz metod związanych z jego rozwojem w środowisku informatycznym Zamawiającego.

22. Na zakończenie trwania Umowy Wykonawca przeprowadzi zamknięte, indywidualnie przygotowane dla maksymalnie 10 osób z uwzględnieniem środowiska informatycznego Zamawiającego warsztaty z administracji oprogramowania Oracle. Warsztaty zostaną zakończone imiennymi certyfikatami .

Załącznik nr 3 do SIWZ

...............................................................

miejscowość, data

OŚWIADCZENIE

Niniejszym oświadczam, że .......................................................................................................................

N a z w a w y k o n a w c y

Spełnia warunki określone w art. 22 ust. 1 pkt 1-4 ustawy z dnia 29 stycznia 2004 r. – Prawo zamówień publicznych (Dz. U. z 2013 r. poz.907 z późn. zm.).

...................................................................

podpis osoby upoważnionej do reprezentowania

Wykonawcy

W załączeniu dowód, w szczególności pisemne zobowiązanie innych podmiotów (art. 22 ust. 1 pkt 2, 3 i 4 ustawy Prawo zamówień publicznych) do oddania wykonawcy do dyspozycji niezbędnych zasobów na okres korzystania z nich przy wykonaniu zamówienia:*

1. ………………………

2. ………………………

3. ………………………

* wypełnia Wykonawca, którego dotyczy określona sytuacja

Załącznik nr 4 do SIWZ

............................................................

miejscowość, data

OŚWIADCZENIE

Niniejszym oświadczam, że ………………………………………………………………………

N a z w a W y k o n a w c y

nie podlega wykluczeniu z postępowania o udzielenie zamówienia publicznego na podstawie art. 24 ust. 1 ustawy z dnia 29 stycznia 2004 r. – Prawo zamówień publicznych (Dz. U. z 2013 r. poz. 907 ze zm.).

...................................................................

podpis osoby upoważnionej do reprezentowania

Wykonawcy

Załącznik nr 5 do SIWZ (TZ/271/11/14) Opis przedmiotu zamówienia

Przedmiotem zamówienia jest opieka serwisowa oprogramowania ORACLE (Tuxedo, SALT, eLink), nabycie dodatkowych licencji ORACLE Tuxedo (lub równoważych), licencji ORACLE SALT (lub równoważnych), licencja na oprogramowanie serwera aplikacyjnego JEE oraz usługa migracji oprogramowania ORACLE.

I. Nabycie dodatkowych licencji na oprogramowanie ORACLE Tuxedo lub równoważych

Jako rozwiązanie równoważne dla oprogramowania monitora transakcyjnego Oracle Tuxedo rozumie się oprogramowanie, zapewniające spełnienie następujących warunków:

1. Kompatybilność na poziomie binariów z wykorzystywanymi przez Zamawiającego aplikacjami Tuxedo (tzw. serwery Tuxedo).

2. Wbudowana w oprogramowanie koncepcja budowy oraz udostępniania usług biznesowych jako niezależne, atomowe operacje.

3. Możliwość komunikacji oprogramowania z wykorzystywanym przez Zamawiającego oprogramowaniem Tuxedo za pomocą Tuxedo ATMI.

4. Zgodność z interfejsem programistycznym Tuxedo ATMI.

5. Możliwość implementacji usług za pomocą następujących języków programowania: C, C++, COBOL.

6. Możliwość zarządzania i kontrolowania rozproszonych transakcji (monitor transakcyjny) w tym zgodność ze standardem X/Open XA.

7. Możliwość dynamicznego skalowania – zwiększanie / zmniejszanie liczby procesów systemu operacyjnego obsługujących określoną grupę usług implementowanych na platformie.

8. Możliwość konfiguracji oprogramowania jako domeny umożliwiającej komunikację z innymi i użytkownymi przez Zamawiającego domenami Tuxedo. Komunikacja powinna się odbywać za pomocą

„TDomain gateway” i umożliwiać określenie zasad komunikacji pomiędzy nową domeną a istniejącymi domenami za pomocą pliku o strukturze zgodnej z DMCONFIG.

9. Interfejsy implementowanych usług muszą być zdefiniowane jako bufory FML/FML32.

10. Możliwość konfiguracji usług za pomocą pliku o strukturze zgodnej z UBBCONFIG.

II. Nabycie dodatkowych licencji na oprogramowanie ORACLE SALT lub równoważnych

Wykonawca dostarczy licencje na oprogramowanie Oracle Service Architecture Leveraging Tuxedo (SALT) lub równoważne, umożliwiające zainstalowanie i uruchomienie tego oprogramowania na posiadanych przez Zamawiającego serwerach opartym o architekturę procesora Intel Itanium 2 w ramach którego wydzielona zostanie wirtualna partycja dla której przydzielono moc równą 8 rdzeni tegoż procesora. Oprogramowanie zostanie uruchomione na wydzielonej partycji wirtualnej.

Jako rozwiązanie równoważne dla oprogramowania Oracle SALT rozumie się oprogramowanie, zapewniające spełnienie następujących warunków:

1. Możliwość udostępniania usług systemu Tuxedo za pomocą usług Webservices, wymagana zgodność z protokołem SOAP.

3. Oprogramowanie musi wspierać następujące standardy komunikacyjne:

a. SOAP 1.1 (xxxx://xxx.x0.xxx/XX/0000/XXXX-XXXX-00000000/)

b. SOAP 1.2 (xxxx://xxx.x0.xxx/XX/xxxx00-xxxx0/)

c. SOAP with Attachement (xxxx://xxx.x0.xxx/XX/XXXX-xxxxxxxxxxx )

d. MTOM (xxxx://xxx.x0.xxx/XX/xxxx00-xxxx/)

e. UDDI 2.0 (xxxx://xxxx.xxx/xxxx/XxxxxxxxxxxXXX-X0.00-Xxxxxxxxx-00000000.xxx )

f. WSDL 1.1 (xxxx://xxx.x0.xxx/XX/0000/XXXX-xxxx-00000000 )

g. WS-Policy (xxxx://xxxxx.xxxxxxx.xxx/xx/0000/00/xxxxxx/xx-xxxxxx.xxx oraz xxxx://xxxxx.xxxxxxx.xxx/xx/0000/00/xxxxxx/xx-xxxxxxxxxxxxxxxx.xxx )

h. WS-Addressing (xxxx://xxx.x0.xxx/Xxxxxxxxxx/0000/XXXX-xx-xxxxxxxxxx-00000000/)

i. WS-ReliableMessaging (xxxx://xxxxx.xxxxxxx.xxx/xx/0000/00/xx/xx-xxxxxxxxxxxxxxxxx.xxx xxxx://xxxxx.xxxxxxx.xxx/xx/0000/00/xx/XX-XXXxxxxx.xxx )

j. WS-Security 1.0 (xxxx://xxxx.xxxxx-xxxx.xxx/xxx/0000/00/xxxxx-000000-xxx-xxxx-xxxxxxx- security-1.0.pdf oraz xxxx://xxxx.xxxxx-xxxx.xxx/xxx/0000/00/xxxxx-000000-xxx-xxxxxxxx- token-profile-1.0.pdf xxxx://xxxx.xxxxx-xxxx.xxx/xxx/0000/00/xxxxx-000000-xxx-x000-xxxxx- profile-1.0.pdf)

k. WS-Security 1.1 (xxxx://xxx.xxxxx-xxxx.xxx/xxxxxxxxxx/xxxxxxxx.xxx/00000/xxx-x0.0-xxxx- os-SOAPMessageSecurity.pdf xxxx://xxx.xxxxx- xxxx.xxx/xxxxxxxxxx/xxxxxxxx.xxx/00000/xxx-x0.0-xxxx-xx-XxxxxxxxXxxxxXxxxxxx.xxx xxxx://xxx.xxxxx-xxxx.xxx/xxxxxxxxxx/xxxxxxxx.xxx/00000/xxx-x0.0-xxxx-xx- x509TokenProfile.pdf)

l. WS-Coordination 1.0 (xxxx://xxxxxxx.xxxxxxx.xxx/xx/0000/00/xxxxxx/)

m. WS-AtomicTransaction 1.0 (xxxx://xxxxxxx.xxxxxxx.xxx/xx/0000/00/xxxx/)

4. Oprogramowanie musi wspierać następujące standardy architektoniczne:

a. SDO (Service Data Objects) - SDO for C++ Specification V2.1 published December, 2006

b. SCA C++ Client and Implementation V0.95

c. SCA Assembly Model V0.96

III. Nabycie dodatkowych licencji na oprogramowanie serwera aplikacyjnego JEE

1. Należy dostarczyć oprogramowanie umożliwiające uruchomienie oraz pracę na serwerze o architekturze procesora x86_64 z co najmniej przydzielonymi 8 rdzeniami.

2. Oprogramowanie musi umożliwiać instalację na serwerach z systemem operacyjnym co najmniej Windows lub Linux (w tym RedHat Enterprise).

3. Wsparcie dla Java SE wersja 6

4. Certyfikacja standardu Java EE wersja 5

5. Certyfikacja Spring Framework

6. Wbudowana integracja EJB 3.0 i Spring

7. Wbudowane wsparcie dla specyfikacji Commons J Work Manager API i Timer API

8. Wbudowane wsparcie dla specyfikacji JSR-88 – plany wdrożeń (Deployment Plan)

9. Wbudowana obsługa standardu Web services WS-ReliableMessaging 1.1 i WS-ReliableMessaging Policy 1.1

10. Wbudowana obsługa standardu Web services WS-Trust 1.3

11. Wbudowana obsługa standardu Web services WS-SecureConversation 1.3

12. Wbudowana obsługa standardu Web services WS-Security 1.1

13. Wbudowana obsługa standardu Web services WS-SecurityPolicy 1.2

14. Wbudowana obsługa standardu Web Service MTOM\XOP – SOAP Message Transmission Optimization Mechanism/XML-binary Optimized Packaging

15. Serwer aplikacyjny powinien mieć możliwość realizacji odpowiedniego poziomu bezpieczeństwa w zakresie:

a. Uwierzytelniania

b. kontroli dostępu

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

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

21. Wbudowana obsługa standardów SAML 1.1, SAML 2.0 lub wyższych

22. Wbudowana integracja w ramach Single-Sign-On (SSO) z takimi technologiami jak SAML (1.1, 2.0), Kerberos (SPENEGO, Windows 2000 i 2003, .NET), Web service (SAML)

23. Wbudowane API do funkcjonalności przeszukiwania i walidacji certyfikatów X.509 (CLV – Certificate Lookup and Validation)

24. Obsługa mechanizmów autoryzacji i mapowania ról przy użyciu standardu XACML 2.0;

26. Wbudowana obsługa standardu Common Secure Interoperability Version 2 (CSIv2)

27. Wbudowana obsługa protokołu SNMP v3 wraz z HMAC-MD5-96, HMAC-SHA-96;

29. Wbudowane automatyczne samostrojenie się serwera aplikacyjnego (self-tuning)

30. Wbudowana możliwość klastrowania połączeń JDBC

31. Wbudowana możliwość klastrowania JMS (w tym automatyczne przełączanie klientów JMS w momencie failover serwerów JMS)

32. Możliwość klastrowania obiektów typu singelton w aplikacjach

33. Obsługa klastrowania dla mechanizmu Store-and-Forward

34. Obsługa klastrowania Web-services zgodnych z WS-ReliableMessaging

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

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

38. Wbudowane wsparcie dla przechowywania (persistence) sesji webowych i EJB w pliku, bazie danych i pamięci

41. 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 i/lub ich komponentów), czasy odpowiedzi, min/max liczba wątków, itp.

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

46. Wbudowana obsługa Logging Last Resource - optymalizacji transakcji rozproszonych (XA)

49. Wbudowany interfejs do JMS dla aplikacji napisanych w C (JMS C API)

50. Wbudowany interfejs do JMS dla aplikacji napisanych w Microsoft .NET C# (JMS C# API)

51. Wbudowana obsługa zawieszania i wznawiania transakcji rozproszonych (XA) w ramach JTA API (suspend/resume)

52. Wbudowany mechanizm współpracy z zewnętrznymi menedżerami transakcji rozproszonych (third-party, foreign transaction managers)

53. Wbudowana obsługa propagacji dodatkowych danych w ramach żądań (content propagation)

54. Obsługa mechanizmu Store-and-Forward, czyli gwarantowanego, niezawodnego przesyłania komunikatów pomiędzy instancjami serwerów aplikacyjnych

56. Wbudowana obsługa Web services, które mogą wykonywać operacje na kliencie (callback Web service)

57. Wbudowane wsparcie dla buforowanego wywoływania Web services

58. Wbudowane wsparcie dla zewnętrznych dostawców usług kolejkowych (np. MQSeries) wraz z przenoszeniem kontekstów security i transakcyjnego

59. Zarządzanie i monitorowanie wielu aplikacji wdrożonych na różnych instancjach serwera aplikacyjnego

60. Zarządzanie klastrami serwerów aplikacyjnych

61. Monitorowanie zasobów serwerów aplikacyjnych takich jak póle połączeń JDBC, kolejki JMS, źródła danych

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

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

64. Możliwości monitorowania poziomu dostępności usługi (SLA) względem zdefiniowanych parametrów (mierników)

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

67. Automatyczny restart serwera i/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.

68. Możliwość ograniczenia liczby sesji HTTP w serwerze tworzonych przez daną aplikację

71. Możliwość konfiguracji i zarządzania środowiskiem serwerów aplikacyjnych równocześnie poprzez: konsole webowe, skrypty (np. Jython), programowo (Java API), SNMP.

75. Wbudowany mechanizm automatycznej naprawy transakcji (transaction recovery) podczas restartu serwera aplikacyjnego.

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

79. Wsparcie podstawowych technologii programistycznych (API pozwalające implementować komunikację aplikacji z infrastrukturą cache)., w tym:

a. Java,

b. Technologia .NET

c. C/C++.

a. Tomcat 6

b. IBM Websphere v7

c. Oracle WebLogic Server 10.x.

d. Sun One Application Server 9.x / Glassfish

82. Możliwość przechowywania obiektów w strukturze kolekcji (Klucz, Wartość)

83. Wsparcie modelu obiektowego przechowywanych danych

84. Oprogramowanie infrastruktury cache musi zapewniać mechanizm rozproszonej pamięci operacyjnej (ang. Single System Image)

85. Możliwość śledzenia zmian w danych znajdujących się w pamięci cache

86. Możliwość równoległego wyszukiwania danych oraz możliwość tworzenia indeksów

87. Oprogramowanie infrastruktury cache musi zapewniać funkcjonalność zapytań ciągłych, co oznacza możliwość otrzymywania zawsze aktualnych wyników wyszukiwania.

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

89. Możliwość stosowania / budowania własnych funkcji agregujących.

90. Oprogramowanie infrastruktury cache musi zapewniać mechanizmy wysokiej dostępności i ochrony danych przed awariami

91. Możliwość klastrowania węzłów cache

92. Oprogramowanie infrastruktury cache musi zapewniać płynne dodawanie i usuwanie węzłów klastra cache

93. Oprogramowanie infrastruktury cache musi zapewniać przezroczystą obsługa awarii pojedynczych węzłów.

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

95. Oprogramowanie infrastruktury cache musi zapewniać mechanizm cache, pomiędzy aplikacją a drugą aplikacją lub bazą danych

96. Oprogramowanie infrastruktury cache musi zapewniać persystencję przechowywanych danych w bazie danych

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

98. Oprogramowanie infrastruktury cache musi zapewniać mechanizm read through w komunikacji na linii aplikacja, cache, baza danych

99. Oprogramowanie infrastruktury cache musi zapewniać mechanizm write through w komunikacji na linii aplikacja, cache, baza danych

100.Oprogramowanie infrastruktury cache musi zapewniać mechanizm write behind w komunikacji na linii aplikacja, cache, baza danych

101.Mechanizm write behind musi zapewniać możliwość kolejkowania zapisów do bazy danych 102.Mechanizm kolejkowania żądań związanych z bazą danych musi być odporny na awarie (musi być

automatycznie tworzona kopia zapasowa kolejek)

103.Możliwość rozszerzenia cache do pracy w sieci WAN (odporność na mniejsze przepustowości oraz większe opóźnienia)

104.Oprogramowanie infrastruktury cache musi zapewniać mechanizm wyzwalaczy (ang. triggers) 105.Możliwość usuwania z pamięci kopii danych po zapisaniu ich do persystentnego repozytorium danych

(np. bazy danych)

Poprzez narzędzia umożliwiające tworzenie usług w architekturze zorientowanej na usługi rozumie się warstwę fasady usług – aplikacji ESB (ang. Enterprise Service Bus).

Wymaganie

1. Należy dostarczyć oprogramowanie umożliwiające uruchomienie oraz pracę na serwerze o architekturze procesora x86_64 z co najmniej przydzielonymi 8 rdzeniami.

2. Oprogramowanie musi umożliwiać instalację na serwerach z systemem operacyjnym co najmniej Windows lub Linux (w tym RedHat Enterprise).

3. Oprogramowanie ESB będzie oparte o serwer aplikacji zgodny ze standardem JEE (Java Enterprise Edition).

4. ESB musi posiadać mechanizmy programowego klastrowania krytycznych elementów architektury ESB.

5. ESB musi posiadać mechanizmy równoważenia obciążenia (load-balancing) wykorzystywane w sytuacjach zwiększonego obciążenia.

6. ESB musi umożliwiać skalowanie, rekonfigurację, osadzanie nowych usług bez zakłócania pracy innych aplikacji czy realizowanych operacji biznesowych.

9. ESB zawierać wbudowane wsparcie dla buforowanego wywoływania Web services (buforowanie w Infrastrukturze Cache)

10. Wymagany jest opis proponowanego systemu kolejkowego (komunikacja asynchroniczna), możliwości w zakresie ustanawiania QoS dla: usług, kolejek, komunikatów w kolejkach

11. Szyna ESB musi posiadać mechanizm definiowania, implementacji, wdrażania i zarządzania usługami realizującymi dostęp do integrowanych systemów.

12. Usługi mogą być elementarne, tworzone jako konfiguracja pewnych modułów lub posiadać większą logikę integracyjną (np. sekwencja wywołań kilku usług).

14. Usługi publiczne są widoczne dla klientów platformy integracyjnej poprzez:

a. punkt dostępu do usługi stanowiący adres sieciowy usług w ramach infrastruktury ESB

b. punkt dostępu do definicji usługi (adres URL) - stanowiący adres sieciowy dokumentu WSDL opisującego usługę.

16. Usługi systemu opisane są w Katalogu Usług. Każda pozycja katalogu opisując usługę zawiera:

a. unikalną nazwę;

b. definicję wejścia i wyjścia usługi;

c. implementację logiki realizowanej przez usługę;

x. xxxxxxxx ją opisujące – zgodne ze specyfikacją Web Services Metadata Exchange (WS- MetadataExchange);

e. listę błędów zgłaszanych przez usługę;

f. dokumentację.

17. Oprogramowanie musi być zgodne ze standardami:

a. WSDL 1.1;

b. SOAP 1.2;

c. SOAP with Attachments;

d. UDDI 3.0.

18. ESB musi zapewniać pełne wsparcie obsługi dokumentów XML. W ramach obsługi dokumentów XML, ESB musi wspierać możliwość:

a. tworzenia i parsowania komunikatów XML,

b. walidacji komunikatów na podstawie definicji XMLSchema i DTD,

c. obsługi dużych dokumentów XML (do 100MB),

d. transformacji komunikatów – dokument XML na inny dokument XML oraz pomiędzy dokumentem XML i innym formatem (w obie strony),

e. poprawnej obsługi stron kodowych obsługujących polskie znaki.

19. W ramach obsługi protokołu SOAP i Web Services dla usług konsumowanych jak i udostępnianych ESB musi zapewniać:

a. możliwość konsumowania oraz udostępniania usług w standardzie webservices (WSDL 1.1, SOAP 1.1 i 1.2, SOAP with Attachements);

b. standard WS-Security;

c. standard WS-Policy;

d. pożądane jest, aby platforma wspierała inne standardy WS określone specyfikacjami konsorcjum OASIS (xxxx://xxx.xxxxx-xxxx.xxx);

e. wykorzystanie rejestrów UDDI (rejestr taki należy utworzyć w ramach systemu, ESB ma mieć także możliwość współpracy z zewnętrznymi rejestrami UDDI).

20. ESB musi dostarczać usługi transformacji komunikatów XML w modelach jeden do wielu i wiele do jednego, co najmniej przy wykorzystaniu języka XSLT 1.0 (XSL Transformations, Extensible Stylesheet Language Transformations).

21. ESB musi dostarczać usługi translacji komunikatów

23. ESB musi umożliwiać routing komunikatów, oparty na treści dokumentów XML i regułach biznesowych.

24. ESB musi umożliwiać filtrowanie komunikatów na podstawie zawartości, przy wykorzystaniu parametrów definiowanych przez użytkownika.

25. ESB musi umożliwiać trwałe przechowywanie komunikatów pod warunkiem, że nie prowadzi to do zbytniego obciążenia systemu.

26. ESB musi umożliwiać realizację scenariuszy integracyjnych w oparciu o model synchroniczny i asynchroniczny.

28. ESB musi umożliwiać integrację relacyjnych baz danych na poziomie danych i wywoływania procedur bazodanowych.

29. ESB musi umożliwiać integrację aplikacji zbudowanych w co najmniej technologiach J2EE, .Net.

30. ESB musi wspierać co najmniej następujące standardy komunikacji: SOAP, JMS, JCA, HTTP, HTTPS, FTP, SFTP.

31. ESB musi zawierać wbudowane wsparcie do udostępniania Web services typu REST

32. Warstwa komunikacyjna ESB musi umożliwiać zachowanie:

a. Integralności

b. niezaprzeczalności,

c. poufności;

d. autentyczności komunikacji.

33. ESB musi umożliwiać raportowanie informacji o incydentach w zakresie bezpieczeństwa w szczególności nieuprawnionego logowania i informowania o incydentach na szynie.

34. Bezpieczeństwo usług zbudowanych w oparciu o technologię Web Services musi bazować na standardzie OASIS WS-S (Web Services Security).

35. ESB musi umożliwiać szyfrowanie i podpisywanie komunikatów XML zgodnie z obowiązującymi przepisami.

36. ESB musi umożliwiać podpisywanie komunikatów XML zgodnie ze standardem Advanced Electronic Signature (XAdES).

37. Minimalna długość klucza szyfrującego w przypadku zastosowania algorytmów symetrycznych musi wynosić 128 bitów, natomiast w przypadku zastosowania algorytmów asymetrycznych – 1024 bity.

38. ESB musi umożliwiać weryfikację statusu unieważnienia certyfikatu poprzez mechanizm CRL.

39. ESB musi umożliwiać weryfikację statusu certyfikatu poprzez mechanizm OCSP.

40. ESB musi umożliwiać ograniczenie wywołań usług, ochronę wydajności adapterów oraz zajętości kolejek

41. ESB musi być wyposażona w narzędzia do monitorowania i zarządzania wytworzonego oprogramowania.

42. Wraz z oprogramowaniem ESB zostaną dostarczone niezbędne skrypty oraz narzędzia wspierające przełączanie aktywności pomiędzy węzłami szyny usług

43. Oprogramowanie ESB zapewni wsparcie w zakresie realizacji testów wydajnościowych i funkcjonalnych: zaślepki, symulatory, skrypty automatyzujące testy, konsola wywoływania ręcznego usług

44. ESB musi zapewniać możliwość kontroli wprowadzanych zmian oraz ich cofnięcia

45. ESB zapewni możliwość eksportu ustawień konfiguracyjnych, a następnie importu na innej instancji szyny usług

47. Nowe wersje produktu nie mogą odbierać możliwości korzystania ze wsparcia z poprzednich wersji w okresie długości ich życia.

48. Gwarancja niezmienności (kompatybilności) interfejsów programistycznych produktu przez okres jego

życia, tj., uaktualnienia nie sprawią, że sposób użycia niektórych funkcji ulegnie zmianie.

49. Produkt realizujący funkcjonalność ESB musi gwarantować automatyczną dystrybucję aktualizacji oprogramowania, powiadomienia o zagrożeniach.

W celu zarządzania cyklem życia usług wymagane jest dostarczenie również dedykowanego narzędzia. Wymaganie

1. Należy dostarczyć oprogramowanie umożliwiające uruchomienie oraz pracę na serwerze o architekturze

procesora x86_64 z co najmniej przydzielonymi 4 rdzeniami.

2. Oprogramowanie musi umożliwiać instalację na serwerach z systemem operacyjnym co najmniej Windows lub Linux (w tym RedHat Enterprise).

3. Oprogramowanie musi wspierać zarządzanie cyklem życia usług, procesów, kompozytów i innych artefaktów związanych z architekturą SOA

4. Oprogramowanie musi przechowywać zasoby związane z architekturą usługową oraz powiązania między nimi

7. Oprogramowanie musi umożliwiać wgląd zarówno w aktualnie wykorzystywane zasoby SOA, jak i w zasoby dopiero planowane lub znajdujące się w fazie produkcji.

8. Oprogramowanie w oparciu o model relacji pomiędzy obiektami musi umożliwiać analizę wpływu zmian w poszczególnych zasobach SOA na inne obszary/zasoby.

10. Oprogramowanie musi udostępniać moduł raportowy pozwalający nadzorować jakość usług w SOA (raporty na temat reużywalność, zgodności z pryncypiami architektury, SLA)

11. Oprogramowanie musi działać w architekturze trójwarstwowej, dostęp do interfejsu użytkownika musi być możliwy przez przeglądarkę internetową.

13. Oprogramowanie musi umożliwiać uwierzytelnienie użytkowników w zewnętrznym katalogu użytkowników, co najmniej w MS Active Directory lub innym zgodnym z LDAP.

14. Oprogramowanie musi udostępniać wyszukiwanie zasobów SOA poprzez następujące mechanizmy:

a. drzewo zasobów (wymagana możliwość filtrowania)

b. wyszukiwanie tekstowe

c. wyszukiwanie według atrybutów i kategorii

15. Interfejs użytkownika musi udostępniać komponent graficzny prezentujący relacje wybranego obiektu z innymi zasobami w postaci grafu.

16. Oprogramowanie musi umożliwiać eksport danych na temat wybranego obiektu co najmniej w następującej formie: Excel, PDF, ZIP

17. Oprogramowanie musi udostępniać użytkownikom możliwość subskrybcji na zdarzenie zmiany wersji określonego obiektu. Informacja o zdarzeniu dostarczana kanałem email.

18. Oprogramowanie musi udostępniać edytory pozwalające co najmniej:

a. konfigurować obiekty prezentowane w interfejsie użytkownik

b. konfigurować listy wartości

c. konfigurować kategoryzacje obiektów

d. konfigurować relacje pomiędzy obiektami

IV. Opieka serwisowa oprogramowania ORACLE (Tuxedo, SALT, eLink)

1. Celem usługi opieki serwisowej jest zapewnienie najbardziej efektywnego, sprawnego, prawidłowego i profesjonalnego użytkowania oprogramowania będącego przedmiotem umowy przez Zamawiającego oraz systematyczne przekazywanie wiedzy, przeprowadzanie warsztatów, podnoszenie wiedzy wynikającej z utrzymania i przyszłego rozwoju wykorzystywanego przez Zamawiającego oprogramowania, co pozwoli zbudować wewnętrzne centrum kompetencyjne. Usługi będą świadczone przez wykwalifikowane w zakresie technicznym osoby, które udostępni Wykonawca, zdolne do świadczenia pomocy serwisowej w zakresie oprogramowania Oracle (Tuxedo, SALT, eLink) będącego przedmiotem serwisowania, na poziomie zgodnym z wymaganiami umowy.

2. Wykonawca w dniu zawarcia umowy przekaże Zamawiającemu wykaz osób upoważnionych do rozwiązywania problemów i współpracy z Zamawiającym w celu realizacji umowy.

6. Adresy e-mail Zamawiającego i Wykonawcy służące do zgłaszania i obsługi awarii w przypadkach opisanych w ust 5 . Strony przekażą sobie wzajemnie w terminie 3 dni od daty zawarcia Umowy.

9. W reakcji na problemy zgłoszone przez Zamawiającego, Wykonawca prześle szczegółowy plan swoich działań w związku z dokonanym zgłoszeniem:

1) problemu krytycznego - w ciągu 12 godzin zegarowych, od zgłoszenia przez Zamawiającego

2) problemu niekrytycznego - w ciągu 48 godzin zegarowych, od zgłoszenia przez Zamawiającego

3) status zgłoszenia problemu określa Zamawiający.

10. Wykonawca jest zobowiązany do przedstawienia informacji pisemnej (e-mail lub fax) o stanie zgłoszeń zawierającej co najmniej uszczegółowienie objawów, diagnozę, podjęte i planowane czynności naprawcze, przewidywany czas naprawy. W przypadku zgłoszenia problemu krytycznego, informacja pisemna o stanie zgłoszenia, będzie udzielana nie rzadziej niż raz na 48 godzin od momentu zgłoszenia, a w przypadku innych zgłoszeń nie rzadziej niż raz na 168 godzin od momentu zgłoszenia.

12. Wykonawca w dniu podpisania umowy zapewni ciągły dostęp do:

1) stron internetowych producenta oprogramowania z aktualną bazą wiedzy na temat oprogramowania Oracle będącego przedmiotem serwisowania;

2) inżynierów supportowych zdolnych do dokonywania zmian w kodzie oprogramowania Oracle oraz odbycia wizyt serwisowych w siedzibie Zamawiającego;

3) elektronicznej dystrybucji oprogramowania;

4) dokumentacji produktów.

15. Wykonawca, w 3, 6, 9 oraz 11 miesiącu od dnia zawarcia umowy, jest zobowiązany do dokonywania przeglądów konserwacyjnych oprogramowania, w szczególności na następujących zasadach:

1) sprawdzanie poprawności oprogramowania Oracle w zakresie wersji, poziomu patchowania i kompletności,

3) testowanie diagnostyczne, regulacje, strojenia oraz zabiegi konserwacyjne mające na celu utrzymanie oprogramowania w prawidłowym stanie,

4) wszystkie czynności mają być wykonane w sposób zgodny z zaleceniami producenta oprogramowania oraz niezbędny do zapewnienia jego poprawnej i wydajnej pracy,

16. Wykonawca zobowiązany jest do sporządzania i przekazywania Zamawiającemu raz w miesiącu zbiorczego Miesięcznego raportu z wykonanych usług opieki serwisowej oprogramowania Oracle,.

18. Zamawiający potwierdzi raport, o którym mowa w ust. 16, lub zgłosi do niego uwagi w terminie 3 dni od daty jego otrzymania.

19. Usługa opieki serwisowej świadczona przez Wykonawcę będzie realizowana w Centralnym Ośrodku Obliczeniowym (COO) i Oddziałach ZUS.

20. Wykonawca zapewni Zamawiającemu wsparcie proaktywne poprzez:

a.inwentaryzację usług Oracle i korzystających z nich aplikacji. Spodziewanym efektem ww. prac jest przygotowanie zestawienia usług Oracle działających w obrębie systemu KSI wraz ze wskazaniem na obsługujące je serwery, domeny Oracle, w których są uruchamiane oraz korzystające z nich aplikacje biznesowe. Inwentaryzacja będzie wykonywana dwa razy w ciągu roku i jej wynik będzie przedstawiany Zamawiającemu w postaci aktualnego zestawienia usług Oracle.

b.wsparcie przy migracji oprogramowania Oracle z obecnie posiadanej platformy (HP-UX dla procesorów Itanium) do platformy wskazanej przez Zamawiającego.

c.wsparcie przy podniesieniu wersji oprogramowania Oracle z obecnie posiadanej wersji do wersji wskazanej przez Zamawiającego.

d.wsparcie przy przeniesieniu wskazanych usług systemu KSI uruchomionych na Oracle na platformie docelowej.

e.kontrole jakości procesu migracji usług uruchamianych na Oracle poprzez kwartalne przeglądy prac i raporty wykonywane przez producenta oprogramowania pod kątem zachowania zgodności z rekomendacjami producenta i wymogami serwisowymi.

g.wsparcie przy udostepnieniu usług działających w środowiskach Oracle dla korporacyjnej architektury SOA podczas przebudowy istniejących aplikacji KSI bądź tworzenia nowych funkcjonalności.

Document Metadata

Table of Contents

SPIS TREŚCI

Document Metadata