Załącznik nr 1 do Umowy nr …

ZAKRES ZADAŃ WYKONAWCY

ZawartośćSłownik skrótów i pojęć..............................................................................................................21. Informacja ogólna o przedmiocie zamówienia....................................................................32. Zadania do zrealizowania....................................................................................................3

Zadanie I............................................................................................................................................3

Zadanie II...........................................................................................................................................4

Zadanie III........................................................................................................................................12

Zadanie IV........................................................................................................................................14

Zadanie V.........................................................................................................................................16

3. Procedura odbiorów Zadań oraz odbioru końcowego.......................................................164. Wymagania formalno-prawne oraz dobre praktyki...........................................................215. Załączniki..........................................................................................................................22

1

Słownik skrótów i pojęćAdministrator merytoryczny

Użytkownik Systemu o wysokich uprawnieniach odpowiedzialny m.in. za zarządzanie kontami innych użytkowników systemu, tworzenie grup uprawnień, zasilanie Systemu danymi, projektowanie i generowanie raportów. Użytkownik zarządza systemem z poziomu interfejsu aplikacji w oparciu o przydzielone uprawnienia w systemie.

Administrator techniczny

Osoba po stronie Zamawiającego odpowiedzialna za techniczną obsługę Systemu realizuje plan kopii zapasowych, dba o prawidłową pracę środowiska, na którym będzie działał System, monitoruje dostępność i wydajność systemu.

Dokumentacja Ilekroć w niniejszym opracowaniu jest podane pojęcie dokumentacja, należy przez to rozumieć dokument w formie elektronicznej (w formacie możliwym do edycji przez program WORD 2010) oraz papierowej, sporządzony w języku polskim.

Dokumentacjaprojektowa

Dokumentacja zawierająca następujące elementy: zakres przetwarzanych danych; specyfikację wymagań niefunkcjonalnych co najmniej takich jak: dostępność, niezawodność, bezpieczeństwo, użyteczność/ergonomia, wydajność, skalowalność, standardy, opis funkcjonalności, właściwości pól, wygląd interfejsu.

Dzień Dzień kalendarzowy.

Dzień roboczy Każdy dzień kalendarzowy od poniedziałku do piątku za wyjątkiem dni wolnych od pracy zgodnie z ustawą z dnia 18 stycznia 1951 r. o dniach wolnych od pracy (Dz. U. Nr 4 poz. 28 z późn. zm.)..

EFS Europejski Fundusz Społeczny

Ocena Pracochłonności

Ocena ilości czasu przedstawiona w roboczogodzinach potrzebnych na realizację danego Zlecenia przez jedną osobę. W przypadku nakładania się czasu pracy dwóch osób (np. dwóch programistów realizuje zadanie w tym samym czasie) – czas ten sumuje się

Polska Agencja Rozwoju Przedsiębiorczości (PARP)

Agencja utworzona na podstawie przepisów ustawy z dnia 9 listopada 2000r. o utworzeniu Polskiej Agencji Rozwoju Przedsiębiorczości (Dz. U. z 2014r., poz. 1804 z późn. zm.). Zamawiający usługę.

Roboczogodzina godzina pracy specjalisty

SIWZ Specyfikacja Istotnych Warunków Zamówienia.

System lub BKL online

Portal składający się z części informacyjnej (wraz z raportami z badań) oraz z Modułu analizy danych – aplikacji umożliwiającej m.in. import danych źródłowych z SPSS, agregację danych, definiowanie zbioru danych w warstwie prezentacji oraz prezentację danych statystycznych

Użytkownik Systemu

Każda osoba korzystająca z Systemu.

2

ZZW Zakres Zadań Wykonawcy, dokument stanowiący element SIWZ zawierający szczegółowy opis przedmiotu zamówienia.

1. Informacja ogólna o przedmiocie zamówienia1.1. Polska Agencja Rozwoju Przedsiębiorczości (PARP) realizuje projekt Bilans

Kapitału Ludzkiego (BKL) w ramach Programu Operacyjnego Kapitał Ludzki, poddziałanie 2.1.3. Bilans Kapitału Ludzkiego to unikatowy na skalę Polski i Europy monitoring rynku pracy. W ramach kompleksowego projektu badawczego poszukiwane są odpowiedzi na kluczowe pytania, które zadają sobie z myślą o przyszłości uczniowie, studenci, pracownicy, pracodawcy, czy instytucje publiczne, odpowiedzialne za kształtowanie polityki w zakresie kapitału ludzkiego na skalę ogólnopolską, ale i regionalną. Jednym z działań BKL jest portal bkl.parp.gov.pl.Portal składa się z części informacyjnej (wraz z raportami z badań) oraz z Modułu analizy danych – aplikacji umożliwiającej m.in. import danych źródłowych z SPSS, agregację danych, definiowanie zbioru danych w warstwie prezentacji oraz prezentację danych statystycznych w postaci: wykresów, tabelek (z możliwością eksportu danych do csv), mapki województw.Portal projektu Bilans Kapitału Ludzkiego (bkl.parp.gov.pl) został przygotowany przed wejściem w życie Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów informatycznych. W związku z powyższym konieczne jest dostosowanie portalu (w tym m.in.: funkcjonalności, kwestionariusze oraz tzw. moduł analizy danych) do zasad opisanych w ww. Ramach Interoperacyjności.

1.2. Przedmiotem zamówienia jest realizacja przez Wykonawcę na rzecz Zamawiającego następujących działań:

1.2.1. wykonanie i dostarczenie Zamawiającemu dzieła w postaci analizy przedwdrożeniowej oraz przeniesienie na Zamawiającego autorskich praw majątkowych do niej;

1.2.2. przebudowa portalu internetowego projektu Bilans Kapitału Ludzkiego wraz z Modułem Analizy Danych;

1.2.3. wykonanie i dostarczenie Zamawiającemu dokumentacji;1.2.4. Przeszkolenie użytkowników systemu;1.2.5. Świadczenie usług zleconych;1.2.6. Świadczenie usług gwarancyjnych.

2. Zadania do zrealizowaniaWykonawca zrealizuje wszystkie poniżej wskazane zadania:

Zadanie I

Wykonawca w ramach Zadania I:2.1. przeprowadzi analizę przedwdrożeniową portalu (udostępnionego przez

Zamawiającego na czas analizy pod adresem bkl-demo.parp.gov.pl) oraz Modułu Analizy Danych (udostępnionego przez Zamawiającego na czas analizy pod adresem

3

bklonline-demo.parp.gov.pl), na podstawie której opracuje dokumentację projektową Systemu, która obejmie w szczególności:

2.1.1. szczegółowy opis realizacji wymagań określonych w niniejszym Zakresie Zadań Wykonawcy,

2.1.2. szczegółowy harmonogram wykonania i wdrożenia Systemu,2.1.3. projekt techniczny Systemu, zawierający co najmniej projekt architektury

Systemu, projekt optymalnej pod względem wydajności i bezpieczeństwa infrastruktury Systemu, przypadki użycia, opis struktury bazy danych, opis interfejsów i definicje usług, opis mechanizmów bezpieczeństwa i ochrony danych.

2.1.4. scenariusze testowe uwzględniające w szczególności opis przypadków testowych, opis kroków testowych oraz opis kryteriów poprawności danego przypadku testowego. Scenariusze testowe zapewnią pokrycie wszystkich wymagań wskazanych w ZZW oraz wszystkich przypadków użycia.

2.2. zaprojektuje strukturę funkcjonalną i stronę graficzną BKL online. Projekt uwzględniać będzie wymogi, o których mowa w:

2.2.1. Krajowych Ramach Interoperacyjności http://www.dziennikustaw.gov.pl/du/2012/526/1 ;

2.2.2. standardach opracowanych przez World Wide Web Consortium (W3C) i opublikowanych w postaci W3C Recommendation (REC) http://www.w3.org/TR/ ;

2.2.3. Księdze Identyfikacji Wizualnej Kompleksowego Systemu Informatycznego PARP stanowiącej załącznik nr 1 do Zakresu Zadań Wykonawcy.

Zadanie II

Wykonawca w ramach zadania II przebuduje portal internetowy projektu Bilans Kapitału Ludzkiego wraz z Modułem Analizy Danych.

2.3. Przebudowany portal (wraz z Modułem Analizy danych), przy zachowaniu istniejących funkcjonalności będzie spełniał:

2.3.1. wymagania Web Content Accessibility Guidelines (WCAG 2.0), z uwzględnieniem poziomu AA

2.3.2. Standardy budowy oprogramowania w PARP, czyli m.in.:2.3.2.1. Zastosowanie CMS Joomla! (http://www.joomla.org/) w wersji z

gałęzi 3.x. 2.3.2.1.1. Dodatkowe moduły, komponenty, wtyczki i szablony powinny

pochodzić wyłącznie z zasobów http://extensions.joomla.org/ . W przypadku jeśli daną funkcjonalność udostępnia więcej niż jeden dodatek, należy dokonać wyboru kierując się: powszechnością użycia, aktywnością rozwoju, jakością dostępnej dokumentacji oraz warunkami licencji (część dodatków „Joomla!” jest dostępna wyłącznie na zasadach komercyjnych). Preferowane są wersje aktualne i stabilne na czas tworzenia oprogramowania. Zabronione jest dokonywanie jakichkolwiek modyfikacji w kodzie źródłowym CMS i jego dodatków pochodzących z zewnętrznych źródeł.

4

2.3.2.1.2. W przypadku niedostępności pożądanej funkcjonalności w podstawowej aplikacji i jej dodatkach , należy stworzyć nowy element zgodnie z wytycznymi „Joomla!” opisanymi na stronie http://docs.joomla.org/ . Tworzone elementy dodatkowe muszą być łatwo modyfikowalne, przenoszalne oraz w celu aktualizacji muszą wykorzystywać mechanizmy aktualizacyjne wbudowane w „Joomla!”. Przenoszalność rozumiana jest jako możliwość zainstalowania dodatku z tzw. „paczki instalacyjnej” w innym środowisku „ Joomla!” w wersji pochodzącej z tej samej gałęzi;

2.3.2.2. Podstawowym językiem programowania jest PHP (http://www.php.net/). Preferowane jest programowanie w ujęciu zorientowanym obiektowo. Tworzony kod PHP:2.3.2.2.1. Musi być kompatybilny z wersją PHP 5.3.0 i nowszymi.2.3.2.2.2. Musi być zgodny z konwencją PSR-0, PSR-1 i PSR-2

http://www.php-fig.org/;2.3.2.2.3. Powinien zawierać wyczerpujące komentarze w standardzie

PHP Documentor 2 http://www.phpdoc.org/docs/latest/index.html. „Wyczerpujące” komentarze są rozumiane jako umożliwiające kontynuację pracy z danym kodem innym programistom.

2.3.2.3. W przypadku jeśli potrzebne funkcjonalności są dostępne w formie gotowych bibliotek lub klas pochodzących z zewnętrznych źródeł, należy rozważyć ich zastosowanie zamiast pisania własnej implementacji. Wykorzystanie zewnętrznych elementów należy wyraźnie zaznaczyć w komentarzach kodu.

2.3.2.4. O ile nie istnieją wyraźne przeciwskazania należy tworzyć aplikacje PHP w oparciu o platformę programistyczną (ang. framework) „Symfony2” (http://symfony.com/ ). W przypadku użycia „Symfony2” należy konsekwentnie zastosować biblioteki „Doctrine2 ORM” do obsługi komunikacji z bazami danych i SwiftMailer do obsługi poczty e-mail. Obie biblioteki są standardowo zintegrowane z „Symfony2”.

2.3.2.5. W przypadku używania modułów dodatkowych (tzw. bundles) dla „Symfony2”, które nie znajdują się w standardowej dystrybucji należy wybierać stabilne wersje tych, które aktywnie podążają za rozwojem platformy programistycznej.

2.3.2.6. Nie jest dopuszczalne modyfikowanie oryginalnego kodu źródłowego „Symfony2”

2.3.2.7. Warstwę prezentacji należy przygotować wyłącznie w formacie HTML5 z użyciem CSS3. Kod wynikowy strony musi spełniać kryteria: 2.3.2.7.1. Musi mieć możliwie identyczny wygląd na przeglądarkach:2.3.2.7.1.1. Internet Explorer w wersjach wspieranych przez

Microsoft;2.3.2.7.1.2. Mozilla Firefox w wersjach wspieranych przez Mozilla

Foundation;2.3.2.7.1.3. Google Chrome w wersjach wspieranych przez Google;2.3.2.7.1.4. Apple Safari w wersjach wspieranych przez Apple.

5

2.3.2.7.2. Musi uzyskać co najmniej C w teście przeprowadzonym przez narzędzie ySlow1.

2.3.2.7.3. Nie powinien, bez zgody Zamawiającego, zawierać elementów wykonanych w technologii Adobe Flash, Silverlight i podobnych.

2.3.2.7.4. Musi zawierać wersję dla urządzeń mobilnych (lub wygląd strony powinien dobrze skalować się w przypadku otwierania na urządzeniach mobilnych).

2.3.2.7.5. Wszelkie elementy wyglądu strony powinny być zawarte w zewnętrznych arkuszach stylów CSS (pliki *.css). Należy unikać umieszczania definicji stylów bezpośrednio w kodzie HTML.

2.3.2.8. W celu ułatwienia zachowania zgodności z wyżej wymienionymi zaleceniami akceptowalne jest użycie gotowych szkieletów CSS. Zalecanym narzędziem tego typu jest „Bootstrap” (http://getbootstrap.com/). Dla nowych aplikacji preferowana jest wersja pochodząca z gałęzi 3.x. W przypadku użycia zewnętrznych rozszerzeń dla frameworka „Bootstrap” konieczne jest wyraźne zaznaczenie tego w komentarzach kodu oraz podanie źródła (adres strony) pochodzenia kodu.

2.3.2.9. Pliki wynikowe CSS powinny być w postaci pojedynczego, zminimalizowanego pliku CSS.

2.3.2.10. Elementy dynamiczne lub elementy logiki aplikacji powinny zostać napisane w języku JavaScript, gdzie:2.3.2.10.1. wszystkie zmienne muszą być zadeklarowane przy

pomocy var2.3.2.10.2. rozpoznawanie wersji przeglądarki jest niedopuszczalne

- należy rozpoznać dostępność określonej funkcjonalności 2.3.2.10.3. w dostępie do atrybutów metod, należy stosować notację

z nawiasami kwadratowymi (MyObject["value"+i] zamiast MyObject.value+i)

2.3.2.10.4. nie należy używać polecenia eval()2.3.2.10.5. przy odwoływaniu się do elementów formularzy, należy

używać referencji (document.forms["formname"].elements["inputname"] zamiast document.formname.inputname)

2.3.2.10.6. należy używać zdarzenia onClick zamiast JavaScriptu w atrybucie href

2.3.2.10.7. należy unikać polecenia document.all2.3.2.10.8. nie należy umieszczać kodu JavaScript w komentarzach

HTML2.3.2.10.9. nie należy używać atrybutu language w deklaracji

<script> (dopuszczalne jest użycie type="text/javascript”)2.3.2.11. W przypadku korzystania z zewnętrznych plików .js, należy je umieścić

w jednym katalogu (katalog może zawierać podkatalogi).2.3.2.12. Pliki *.js w wersji produkcyjnej aplikacji muszą być używane w formie

skompresowanej i powinny być oznaczone sufiksem *.min.js. Zaleca się

1 wytyczne do narzędzia ySlow oraz optymalizacji strony znajdują się na stronie http://developer.yahoo.com/performance/rules.html

6

pozostawienie w strukturze katalogów aplikacji obu wersji pliku (zwykłej i skompresowanej).

2.3.2.13. W celu optymalizacji czasu tworzenia kodu JavaScript działającego po stronie klienta (przeglądarki) możliwe jest wykorzystanie platformy programistycznej „jQuery”. W nowych aplikacjach należy wykorzystywać wersję co najmniej 1.10. Nie należy aktualnie używać wersji z gałęzi 2.x, gdyż nie wspierają one przeglądarki IE 6/7/8.

2.3.2.14. Dopuszczalne jest umieszczanie linków CDN (Content Delivery Network) wskazujących na bibliotekę jQuery oraz jej dodatki.

2.3.2.15. Pisany kod Java Script powinien być możliwie zgodny z wytycznymi „Principles of Writing Consistent, Idiomatic JavaScript” (https://github.com/rwaldron/idiomatic.js/) lub „JavaScript Style Guide” (http://contribute.jquery.org/style-guide/js/).

2.3.2.16. Wszelkie zastosowane zapytania używane w aplikacjach pisanych w języku PHP z użyciem Symfony powinny realizować komunikację z bazą danych za pośrednictwem Doctrine2/ORM ( http://www.doctrine-project.org/ ) .

2.3.2.17. Składnia zapytań SQL tworzonych ręcznie musi być zgodna ze standardem SQL-92 .

2.3.2.18. Preferowanymi relacyjnymi bazami danych (RDBMS) dla budowanych aplikacji są PostgreSQL i MySQL (lub ich pochodne, np. Percona) dostępne standardowo w aktualnie używanej na serwerach produkcyjnych PARP wersji systemu operacyjnego Debian. W przypadku użycia baz danych typu „no SQL” preferowanym wyborem jest MongoDB.

2.3.2.19. Należy unikać umieszczania krytycznych elementów logiki tworzonego oprogramowania po stronie serwerów baz danych. (Za krytyczne uważane są te elementy, których utrata w przypadku migracji na inny serwer, uniemożliwi działanie oprogramowania.)

2.3.2.20. Kod PHP musi być odporny na podatności wymienione na liście Top10 OWASP.

2.3.2.21. Kody źródłowe muszą być przechowywane w systemie SVN Zamawiającego w postaci umożliwiającej dalsze prace programistyczne. Jeżeli Wykonawca do wytworzenia oprogramowania korzysta z narzędzi programistycznych, które nie są dostępne powszechnie (np. narzędzi autorskich), wraz z kodami źródłowymi, w ramach wynagrodzenia za wykonanie przedmiotu umowy, Wykonawca dostarczy także licencję na te narzędzia.

2.3.2.22. Jakość wytworzonego kodu PHP musi być zgodna ze standardami PSR-0, PSR-1 oraz PSR-2.

2.3.2.23. Nie zaleca się stosowania bibliotek oraz rozszerzeń, które nie są wspierane przez ich autorów oraz nie są aktywnie rozwijane przez ich producentów czy społeczność. Jeśli nie ma oficjalnej informacji o statusie projektu, za pozbawiony wsparcia uznawany jest ten, którego ostatnia wersja pojawiła się dawniej niż 12 miesięcy temu.

2.3.2.24. W bazie danych nie wolno przechowywać haseł w formie jawnej. Hasła muszą być zabezpieczone przy pomocą losowej soli zawierającej co najmniej 32 znaki, zaś całość musi być zapisana przy pomocy skrótu AES-128 z co najmniej jedną iteracją.

7

2.3.2.25. W przypadku jeśli system obsługuje istotne dane, wszelkie zmiany w tych danych muszą być wersjonowane. Należy także unikać usuwania danych z zasobów baz danych. (Preferowane jest tzw. miękkie usuwanie, które polega na oznaczeniu danych jako usunięte.)

2.4. Wykonawca wraz z Systemem zapewni umowy licencyjne na oprogramowanie lub dodatkowe biblioteki komercyjne będące integralną częścią tworzonego systemu, jeżeli takowe zostaną użyte oraz przeprowadzi instalację i konfigurację tego oprogramowania w środowisku wskazanym przez Zamawiającego. Ww. umowy licencyjne dla oprogramowania muszą spełniać warunki określone w Umowie oraz warunki przedstawione poniżej:

2.4.1. Licencja bez dodatkowych opłat powinna uprawniać Zamawiającego przynajmniej do:

2.4.1.1. zainstalowania Systemu na Serwerze/Serwerach Zamawiającego, 2.4.1.2. korzystania z Systemu w celu przetwarzania danych Zamawiającego dla

potrzeb prowadzonej przez niego działalności,2.4.1.3. sporządzania kopii zapasowych Systemu dla potrzeb właściwego

zabezpieczenia danych,2.4.1.4. użytkowania nowych wersji oraz jego aktualizacji,2.4.1.5. modyfikacji wedle potrzeb własnych.

2.4.2. Umowa licencyjna powinna zawierać:2.4.2.1. zapisy gwarantujące, że oprogramowanie jest wolne od wad prawnych,2.4.2.2. zabezpieczenie Zamawiającego przed roszczeniami osób trzecich,2.4.2.3. zapisy zabezpieczające Zamawiającego, w przypadku zakończenia

prowadzenia działalności przez Wykonawcę.2.4.3. W przypadku Sublicencji muszą być spełnione warunki jak dla Licencji.2.4.4. Żadne z postanowień umowy licencyjnej nie może pozostawać

w sprzeczności z postanowieniami umowy.

2.5. Wykonawca jest zobowiązany do opracowania niezbędnych mechanizmów umożliwiających: monitorowanie, automatyczne rejestrowanie, raportowanie:

2.5.1.1. liczby jednoczesnych użytkowników korzystających z usług systemu,2.5.1.2. statystyk, co najmniej w zakresie:

2.5.1.2.1. ilość zarejestrowanych użytkowników,2.5.1.2.2. średni czas spędzony na stronie projektu oraz Modułu Analizy

Danych,2.5.1.2.3. liczba nowych użytkowników z możliwością wyboru przedziału

czasowego,2.5.1.2.4. liczba pobrań poszczególnych wydań raportów BKL.

2.5.1.3. statystyki informujące o zachowaniu użytkowników portalu, w szczególności w zakresie najczęściej wybieranych danych, kryteriów filtrowania, haseł wyszukiwania,

2.5.1.4. wykorzystania łącza do Internetu,2.5.1.5. wykorzystania zasobów sprzętowych,

8

2.5.1.6. liczby użytkowników Systemu narastająco w miesiącu kalendarzowym.

2.5.2. Wykonawca zapewni, poprzez narzędzie do monitorowania on-line parametrów realizacji serwisu gwarancyjnego oraz parametru pracy serwerów, automatyczne rejestrowanie wartości parametrów wskazanych w niniejszym rozdziale w odstępach nie dłuższych niż 10 minut. Po upływie 60 dni od zarejestrowania, wartości parametrów będą dostępne dla odstępów nie dłuższych niż 1 godzina.

2.6. Wykonawca zapewni usługę hostingu środowiska developerskiego Systemu przynajmniej do dnia odbioru końcowego.

2.7. Wykonawca wykona i dostarczy dokumentację użytkową oraz dokumentację techniczną Systemu, które składać się będą co najmniej z następujących dokumentów:

2.7.1. Instrukcje dla administratorów,2.7.2. Zaktualizowany projekt techniczny Systemu,2.7.3. Dokumentację użytkownika - opis systemu przeznaczony dla użytkowników

przypisanych do poszczególnych ról systemowych - zawierającą:2.7.3.1. opis wszystkich funkcji Systemu, sposoby ich wywoływania

i realizacji,2.7.3.2. opis i sposoby odwoływania operacji wykonanych błędnie przez

użytkownika,2.7.3.3. informacje o ograniczeniach dotyczących np. zakresów danych,2.7.3.4. opis sposobu korzystania z systemu pomocy,

2.7.4. Podręcznik instalacji - powinien zawierać opis procedury instalacji oraz dostrojenia systemu do środowiska, w którym będzie pracować, w tym procedury migracji danych z innych systemów, jeżeli takie występują.

2.8. Wykonawca jest zobowiązany do wykonania prac związanych z przekazaniem Systemu Zamawiającemu. Zakres przekazanych elementów Systemu oraz związanych z nim informacji musi zapewniać spójność i prawidłowość działania Systemu w środowisku technicznym zgodnym z wymaganiami określonymi Zakresem Zadań Wykonawcy.

2.9. W ramach przekazania systemu Wykonawca zobowiązuje się do:2.9.1. przekazania aktualnej wersji Systemu wraz z bazą danych na nośniku CD lub

DVD w dwóch egzemplarzach,2.9.2. przekazania wszystkich informacji wymaganych do prawidłowego

funkcjonowania Systemu,2.9.3. przekazania wykazu kont użytkowników zapewniających dostęp do Systemu.

2.10. Wykonawca przekaże również aktualną wersję dokumentacji Systemu.2.11. Wykonawca przekaże wykaz danych osobowych w Systemie, wykaz zbiorów

(plików) danych je zawierających, charakterystykę i strukturę tych zbiorów, opis pól informacyjnych, powiązania między zbiorami i polami oraz zasady przetwarzania danych osobowych w Systemie, przepływ tych danych pomiędzy modułami Systemu (jeśli dotyczy).

9

2.12. Wykonawca zobowiązuje się do zainstalowania kopii produkcyjnej wersji Systemu, na serwerze/serwerach wskazanych przez Zamawiającego

2.13. Obsługa zgłoszeń błędów prowadzona będzie przy użyciu systemu informatycznego Zamawiającego. Wykonawca zobowiązany jest, co najmniej do:

2.13.1. prowadzenia rejestru błędów dotyczących Systemu, w elektronicznym systemie obsługi zgłoszeń;

2.13.2. rejestrację błędów wykrytych przez Wykonawcę oraz zgłoszonych przez użytkowników;

2.13.3. rejestrację aktualnego statusu usuwania błędu; 2.13.4. archiwum opisywania przyczyn zgłoszonych błędów wraz z ich

rozwiązaniami; 2.13.5. odnotowywanie czasu rozwiązania błędu.

2.14. Zgłoszenia serwisowe2.14.1. Wykonawca będzie świadczył usługę obsługi zgłoszeń serwisowych

Zamawiającego oraz użytkowników Systemu przez cały okres gwarancji, w dni robocze w godzinach od 8:00 do 16:00.

2.14.2. Obsługa zgłoszeń serwisowych będzie realizowana za pośrednictwem elektronicznego systemu obsługi zgłoszeń, udostępnionego przez Zamawiającego. Wykonawca, po dokonaniu kwalifikacji problemu, wprowadzi do elektronicznego systemu zgłoszeń, zgłoszenia przesłane za pomocą:

2.14.2.1. poczty elektronicznej,2.14.2.2. telefonu, 2.14.2.3. pożądane jest zgłaszanie ujawnionych błędów Systemu za pomocą

dedykowanej do tego podstrony Systemu.2.14.3. Za moment zgłoszenia przyjmuje się:

2.14.3.1. datę i godzinę zarejestrowania zgłoszenia w systemie zgłoszeń lub za pomocą dedykowanej do tego strony www Wykonawcy,

2.14.3.2. datę i godzinę wysłania wiadomości e-mail,2.14.3.3. datę i godzinę zakończenia rozmowy telefonicznej,

2.14.4. Wykonawca zobowiązany jest potwierdzić zgłoszenie serwisowe niezwłocznie, nie później niż do dwóch godzin od chwili jego otrzymania. Jeżeli zgłoszenie nastąpiło po godzinie 16.00 Wykonawca zobowiązany jest przesłać potwierdzenie nie później niż do godziny 10.00 następnego dnia roboczego. W przypadku rejestracji zgłoszenia za pomocą dedykowanej strony www, potwierdzenia zgłoszenia się nie stosuje.

2.14.5. Potwierdzeniem przyjęcia zgłoszenia serwisowego jest przesłanie do Zamawiającego faksem lub na wskazany w zgłoszeniu adres e-mail, podpisanej przez Wykonawcę kopii zgłoszenia serwisowego. W przypadku braku potwierdzenia przyjęcia zgłoszenia, za moment potwierdzenia przyjmuje się moment upłynięcia terminu wyznaczonego na potwierdzenie przyjęcia zgłoszenia.

2.14.6. Błąd - nieprawidłowe działanie jednego lub więcej z wdrożonych modułów, ograniczające wydajność lub funkcjonalność Systemu lub uniemożliwiające

10

użytkownikom korzystanie z Systemu. Do błędów zalicza się także nieprawidłowe działanie Systemu wynikające z wadliwej współpracy jego elementów z bazą danych, systemem operacyjnym lub sprzętem komputerowym na skutek błędów programistycznych. Błędy Systemu określa się jako następujące:

2.14.6.1. Awaria: brak działania lub nieprawidłowe działanie Systemu. Awarią jest również nieprawidłowe działanie Systemu objawiające się w szczególności poprzez: 2.14.6.1.1. Uzyskiwanie z Systemu informacji niespójnych,

niezgodnych z prawidłowymi danymi wejściowymi lub niewynikających z prawidłowych danych wejściowych (uwzględniając uprawnienia użytkownika).

2.14.6.1.2. Uniemożliwienie pracy w wyniku obciążenia Systemu przez maksymalną, przewidzianą w Zakresie Zadań liczbę użytkowników.

2.14.6.1.3. Nieoczekiwane zamrożenie komunikacji z Systemem podczas wykonywania dowolnej operacji w systemie (np. System wyświetla interfejs graficzny użytkownika, ale nie reaguje na akcje wykonywane przez użytkownika, potocznie nazywane „zawieszaniem się” systemu).

2.14.6.1.4. Utratę lub niedostępność wprowadzonych do Systemu danych.

2.14.6.1.5. Ograniczenie możliwości logowania do Systemu przez jego użytkowników.

2.14.6.1.6. Spadek wydajności narzędzia o 80% i więcej w stosunku do parametrów jakości określonych w punkcie 2.32 zmierzonych w momencie odbioru systemu przez Zamawiającego.

2.14.6.2. Błąd krytyczny: zakłócenie pracy Systemu ograniczające lub utrudniające jego użytkowanie, wymuszające na użytkowniku dodatkowy nakład pracy, powodujący spadek wydajności o co najmniej 30%, ale mniej niż 80% w stosunku do parametrów jakości określonych w punkcie 2.32 zmierzonych w momencie odbioru systemu przez Zamawiającego.

2.14.6.3. Usterkę: to zakłócenie Systemu, wpływające na jego funkcjonalność, ale niepowodujące ograniczeń w działaniu w zakresie realizacji zaimplementowanych procesów – np. błędy interfejsu graficznego lub wydruków (niepowodujące zafałszowania treści), lub niewielki (o mniej niż 30%) spadek wydajności w stosunku do parametrów jakości określonych w punkcie 2.32 zmierzonych w momencie odbioru Systemu przez Zamawiającego. Usterki nie wymuszają na użytkownikach dodatkowych czynności.

2.14.7. Kwalifikacji Błędów dokonuje Zamawiający przed wysłaniem zgłoszenia serwisowego, przy czym Wykonawca zobowiązuje się udzielić pomocy

11

Zamawiającemu w zakresie diagnostyki problemów związanych z działaniem Systemu.

2.14.8. W przypadku wystąpienia awarii Wykonawca podejmie prace niezwłocznie tj. nie później niż w ciągu 2 godzin od potwierdzenia przyjęcia zgłoszenia o wystąpieniu awarii lub, w przypadku zgłoszenia za pomocą dedykowanej strony www, od rejestracji takiego zgłoszenia i zobowiązuje się do jej usunięcia w czasie nie dłuższym niż 24 godziny od ww. podjęcia prac.

2.14.9. W przypadku wystąpienia błędu krytycznego Wykonawca podejmie prace niezwłocznie tj. nie później niż w ciągu 2 godzin od potwierdzenia przyjęcia zgłoszenia o wystąpieniu błędu krytycznego lub, w przypadku zgłoszenia za pomocą dedykowanej strony www, od rejestracji takiego zgłoszenia i zobowiązuje się do ich niezwłocznego usunięcia w czasie nie dłuższym niż 36 godzin od ww. podjęcia prac.

2.14.10. W przypadku ujawnienia usterek Wykonawca podejmie prace niezwłocznie, nie później niż w ciągu 24 godzin od potwierdzenia przyjęcia zgłoszenia o wystąpieniu usterki lub, w przypadku zgłoszenia za pomocą dedykowanej strony www, od rejestracji takiego zgłoszenia i zobowiązuje się do ich niezwłocznego usunięcia, nie później jednak niż w terminie do 3 dni roboczych od jej wystąpienia.

2.14.11. Wszelkie koszty związane z zapewnieniem właściwego poziomu świadczenia usługi ponosić będzie Wykonawca.

2.14.12. W ramach usług serwisowych Wykonawca będzie świadczył usługę asysty polegającą na wsparciu administratorów Systemu. Asysta oznacza świadczenie przez Wykonawcę usługi polegającej na asystowaniu i bieżącym wsparciu osób wskazanych przez Zamawiającego w zakresie administrowania i użytkowania Systemu. Asysta będzie realizowana poprzez telefoniczne, e-mailowe oraz osobiste konsultacje przedstawicieli Wykonawcy. Wykonawca ma obowiązek udzielić konsultacji w terminie nie dłuższym niż 3 dni robocze od dnia przekazania zapytania telefonicznego, lub pocztą elektroniczną. Konsultacji będą udzielać eksperci Wykonawcy za pośrednictwem:

2.14.12.1. telefonu, (Wykonawca przekaże Zamawiającemu dane kontaktowe przed zawarciem Umowy),

2.14.12.2. poczty elektronicznej (Wykonawca przekaże Zamawiającemu dane kontaktowe przed zawarciem Umowy),

2.14.12.3. bezpośrednio w siedzibie Zamawiającego.

Zadanie III

2.15. Wykonawca zaplanuje, przygotuje, zorganizuje i przeprowadzi szkolenia stacjonarne dla osób wskazanych przez Zamawiającego.

2.16. Osoby wskazane przez Zamawiającego zostaną przygotowane przez Wykonawcę co najmniej do pełnienia roli Administratorów merytorycznych oraz

12

Administratorów technicznych zarządzających funkcjonalnościami Systemu, w tym do wykonywania działań związanych z raportami i stroną informacyjną oraz użytkownikami, w tym uprawnieniami użytkowników. Organizacja szkoleń stacjonarnych:

2.16.1. Celem szkoleń jest przekazanie uczestnikom wiedzy dotyczącej funkcjonowania Systemu w zakresie objętym szkoleniem, w tym w szczególności nauczenie uczestników obsługi Systemu w stopniu pozwalającym na samodzielną pracę w Systemie oraz dalsze przekazywanie wiedzy dotyczącej obsługi Systemu innym osobom.

2.16.2. Wykonawca opracuje i przedstawi Zamawiającemu do akceptacji, dokumentację szkoleniową zawierającą harmonogram wraz z zakresem merytorycznym szkoleń, obejmujący terminy realizacji wszystkich szkoleń. Zamawiający uprawniony jest do wniesienia zastrzeżeń do przekazanej dokumentacji szkoleniowej, w terminie 5 dni roboczych od ich otrzymania. Wykonawca zobowiązany jest uwzględnić uwagi Zamawiającego i przekazać dokumentację do ponownej akceptacji Zamawiającego w terminie do 3 dni roboczych od otrzymania ww. uwag.

2.16.3. Wykonawca opracuje i dostarczy materiały szkoleniowe dla uczestników poszczególnych szkoleń. Materiały zostaną opracowane zgodnie z zatwierdzonym przez Zamawiającego zakresem merytorycznym, w języku polskim oraz zostaną dostarczone w formie wydruków oraz w formie elektronicznej. W okresie objętym gwarancją, po każdej zmianie w Systemie, wykonawca będzie zobowiązany do uaktualnienia i dostarczenia nowych wersji materiałów szkoleniowych uwzględniających dokonane zmiany.

2.16.4. Każda grupa szkoleniowa (w szkoleniu stacjonarnym) będzie liczyła nie więcej niż 8 osób. Przewiduje się nie więcej niż 2 grupy szkoleniowe.

2.16.5. Szkolenia dla jednej grupy będą trwały co najmniej jeden dzień i nie dłużej niż 6 godzin zegarowych w ciągu jednego dnia.

2.16.6. Szkolenia będą podzielone, co najmniej na następujące grupy tematów:2.16.6.1. Obsługa Systemu z perspektywy użytkownika o uprawnieniach innych

niż Administrator techniczny2.16.6.2. Obsługa Systemu dla Administratorów technicznych

2.16.7. Wykonawca zapewni zasoby niezbędne do przeprowadzenia szkolenia, w tym w szczególności sale wyposażone w specjalistyczny sprzęt komputerowy (m.in. indywidualne stanowisko komputerowe dla każdego uczestnika, infrastrukturę sieciową, zainstalowane i skonfigurowane do zajęć odpowiednie oprogramowanie) oraz sprzęt prezentacyjny (m.in. projektor, flipchart, tablica).

2.16.8. Wykonawca zorganizuje szkolenia stacjonarne w Warszawie lub zapewni uczestnikom transport z siedziby PARP na miejsce szkolenia oraz nocleg w hotelu o standardzie minimum trzygwiazdkowym.

2.16.9. W ramach organizowanych szkoleń stacjonarnych Wykonawca zapewni wszystkim uczestnikom catering w postaci minimum dwóch przerw kawowych oraz dwudaniowego obiadu każdego dnia szkolenia.

13

Zadanie IV

2.17. Wykonawca zobowiązuje się do świadczenia specjalistycznych prac programistycznych w postaci roboczogodzin. Zakupione usługi służyć będą do modernizacji funkcjonującego portalu projektu Bilans Kapitału Ludzkiego.

2.18. Wykonawca będzie świadczył usługi w ramach umowy na podstawie składanego przez Zamawiającego Zlecenia Prac (Zlecenia). Wzór Formularza Zlecenia stanowi załącznik nr 3 do Zakresu Zadań Wykonawcy. Zlecenia może dokonać jedynie osoba upoważniona przez Zamawiającego w Umowie. Jeżeli zajdzie potrzeba zmiany osoby upoważnionej, Zamawiający powiadomi Wykonawcę o tym w formie pisemnej. Nowa osoba upoważniona przejmuje od poprzedniej osoby upoważnionej całość dokumentacji zleconych prac, w szczególności prace już zakończone i trwające.

2.19. Zamawiający przygotowując Zlecenie dołoży wszelkich starań, aby możliwie dokładnie opisać oczekiwania stawiane wobec Wykonawcy w ramach realizacji Zlecenia. W przypadku wątpliwości, Wykonawca ma prawo żądać od Zamawiającego doprecyzowania opisu Zlecenia, przy czym Wykonawca wskaże w punktach elementy Zlecenia, które budzą jego wątpliwości.

2.20. Wykonawca może stwierdzić brak możliwości realizacji Zlecenia. Brak możliwości realizacji Zlecenia może być spowodowany np.:

2.20.1. brakiem technicznej możliwości integracji z systemem trzecim (powiązanym),2.20.2. brakiem praw autorskich Zamawiającego do systemu trzeciego (powiązanego).W przypadku niemożliwości realizacji Zlecenia, Wykonawca ma obowiązek pisemnego uzasadnienia oraz przedstawienia Zamawiającemu alternatywnego rozwiązania, którego rezultat będzie identyczny lub zbliżony do oczekiwanego przez Zamawiającego. Zamawiający może, lecz nie musi, zaakceptować takie rozwiązanie.

2.21. Wykonawca po otrzymaniu Zlecenia dokona rzetelnej Oceny Pracochłonności wykonania Zlecenia i przedstawi ją Zamawiającemu w terminie nie dłuższym niż 3 dni robocze od dnia otrzymania Zlecenia pracy.

2.22. Przy opracowaniu Oceny Pracochłonności, Wykonawca również wskaże możliwą datę rozpoczęcia prac oraz termin wykonania Zlecenia. Wskazany termin wykonania zlecenia może ulec wydłużeniu w wyniku zaistnienia nieprzewidzianych problemów z realizacją zleconych prac, niemniej jednak zmiana terminu nie może wpływać na ustaloną czasochłonność prac. Ustalenie nowego terminu następuje za obopólną zgodą Wykonawcy i Zamawiającego, potwierdzoną formą pisemną (pismo, e-mail). Zamawiający dokonuje analizy Oceny Pracochłonności przedstawionej przez Wykonawcę. Wynik analizy może być pozytywny lub negatywny. Ocena Pracochłonności, która uzyska wynik pozytywny, stanowi podstawę do rozliczenia Zamawiającego z Wykonawcą.

2.23. W przypadku wyniku pozytywnego, Wykonawca rozpoczyna prace w uzgodnionym terminie. Obowiązującym terminem oddania gotowych prac jest termin

14

zaproponowany przez Wykonawcę. Dopuszcza się możliwość zmiany terminu oddania gotowych prac na późniejszą niż termin wskazany w zaakceptowanym zleceniu pod warunkiem wyrażenia akceptacji nowego terminu przez Zamawiającego. Zmiana terminu musi wynikać z obiektywnych przesłanek.

2.24. W przypadku wyniku negatywnego, Zamawiający może żądać od Wykonawcy szczegółowej pisemnej analizy zasadności Oceny Pracochłonności, w której przedstawione zostaną przynajmniej następujące elementy:

2.24.1. liczba osób potrzebnych do realizacji zlecenia z podziałem na role pełnione w danym Zleceniu,

2.24.2. liczba Roboczogodzin potrzebnych na realizację Zleceń, w podziale na poszczególne osoby biorące udział w realizacji Zleceń,

2.24.3. wykres Gantta przedstawiający zależności czasowe i procesowe pomiędzy działaniami poszczególnych osób biorących udział w realizacji Zleceń,

2.24.4. szczegółowy podział zakresu prac na elementy niezbędne, bez których realizacja Zleceń nie może się odbyć i elementy opcjonalne, które nie mają lub mają niewielki wpływ na końcowy produkt,

2.24.5. pracochłonność przypisaną do poszczególnych elementów niezbędnych i opcjonalnych.

2.25. Zamawiający po analizie przedstawionej Oceny Pracochłonności może dokonać modyfikacji zlecenia. Modyfikacja zlecenia może spowodować wzrost lub zmniejszenie liczby Roboczogodzin potrzebnych na realizację zlecenia.

2.26. Jeżeli w wyniku negocjacji nie dojdzie do porozumienia, Zleceniodawca może wycofać zlecenie z realizacji.

2.27. W trakcie trwania prac nad Zleceniem Zamawiającego, Wykonawca ma obowiązek przedstawić poziom zaawansowania prac na prośbę Zamawiającego.

2.28. W każdym momencie trwania prac, jeżeli wystąpi niebezpieczeństwo przekroczenia oddania prac w uzgodnionym wcześniej terminie, Wykonawca ma obowiązek niezwłocznie powiadomić o tym Zamawiającego.

2.29. Wykonawca wykona dokumentację do każdego Zlecenia. Dokumentacja będzie zawierać co najmniej:

2.29.1. dokumentację analityczną (jeżeli była opracowana w ramach zleconych prac),2.29.2. dokumentację techniczną, 2.29.3. dokumentację powykonawczą,2.29.4. instrukcję użytkownika końcowego (jeżeli wprowadzone zmiany wpływają na

obsługę systemu z perspektywy użytkownika).Dostarczenie Zamawiającemu kompletnej dokumentacji jest warunkiem dokonania odbioru Zlecenia.

Zadanie V

2.30. Wykonawca będzie świadczył usługi serwisu gwarancyjnego na wykonany przedmiot zamówienia i każdą jego część, w okresie od podpisania protokołu

15

zdawczo-odbiorczego danego Zadania lub pracy do upływu okresu przewidzianego w ofercie Wykonawcy na zasadach określonych Umową i ZZW, w szczególności poprzez:

2.30.1. zapewnienie poprawnego działania oprogramowania i usuwania błędów Systemu, w tym napraw błędów w kodzie źródłowym, usterek i awarii,

2.30.2. uaktualnienie (upgrade), w szczególności w zakresie usuwania luk związanych z bezpieczeństwem dostarczonego oprogramowania wchodzącego w skład Systemu, w szczególności oprogramowania aplikacyjnego, oprogramowania bazodanowego, oprogramowania narzędziowego do nowej wersji bez dodatkowych opłat z tego tytułu ze strony Zamawiającego.

2.31. Zakres usług i sposób wykonywania prac serwisowych:2.31.1. Usługi będą świadczone w trybie 8 godzin na dobę w dni robocze.2.31.2. W przypadku konieczności wprowadzania uzgodnionych przez Strony zmian

w Systemie, Strony mogą uzgodnić okna serwisowe. Podczas trwania prac w czasie okna serwisowego Wykonawca zapewni wyświetlanie użytkownikom Systemu komunikatu o trwających pracach serwisowych.

2.32. Parametry jakości świadczenia usługi przy 100 000 unikalnych użytkowników w skali miesiąca oraz 300 jednoczesnych użytkowników (jednoczesnych sesji):

Tabela 1. Ogólne parametry jakościowe

LP Opis parametru Poziom Jakości Usług Okres raportowania

1. Maksymalny czas odpowiedzi Systemu na akcję użytkownika < 1 sekundy Miesiąc

2. Maksymalny czas wykonania pojedynczej akcji Systemu <= 5 sekund Miesiąc

3.Maksymalny czas wykonania złożonej akcji Systemu (proste raporty zdefiniowane)

< = 1 minuty Miesiąc

2.33. Wykonawca przekaże narzędzie do monitorowania on-line parametrów realizacji serwisu gwarancyjnego oraz parametru pracy serwerów.

3. Procedura odbiorów Zadań oraz odbioru końcowego

3. Opis przebiegu odbioru prac będzie zgodny z następującymi założeniami:

3.1. Wykonawca zgłaszać będzie Zamawiającemu w formie pisemnej gotowość do odbioru poszczególnych Zadań, zgodnie ze szczegółowym Harmonogramem określonym w dokumentacji zarządzania projektem,

16

3.2. W przypadku Zadań, w których wykonywane były prace programistyczne, przed zgłoszeniem Zamawiającemu gotowości Zadania lub pojedynczych prac do odbioru, Wykonawca zobowiązuje się do:

3.2.1. przeprowadzenia testów wewnętrznych zgłaszanej do odbioru części oprogramowania. Niedopuszczalne jest zgłaszanie do odbioru prac programistycznych, które nie zostały wcześniej zweryfikowane przez Wykonawcę oraz w przypadku których testy zakończyły się wynikiem negatywnym

3.2.2. przekazania protokołów z przeprowadzonych testów oprogramowania. 3.3. Odbiór poszczególnych etapów prac dokonywany będzie po uzyskaniu przez

Wykonawcę akceptacji Zamawiającego co do zakresu i jakości wykonanych prac oraz produktów. Odbiór każdego Zadania zostanie potwierdzony protokołem zdawczo-odbiorczym Zadania.

3.4. Odbiór Zadania I nastąpi na podstawie poniższej procedury:3.4.1. Wykonawca przekaże opracowaną dokumentację projektową Systemu

w jednym egzemplarzu w formie oprawionego wydruku i na elektronicznym nośniku informacji (w wersji edytowalnej).

3.4.2. Wykonawca przekaże projekt struktury funkcjonalnej i strony graficznej Systemu w jednym egzemplarzu w formie wydruku i na elektronicznym nośniku informacji.

3.4.3. Zamawiający uprawniony jest do wniesienia zastrzeżeń do przekazanych do odbioru dokumentów w terminie 5 dni roboczych od ich otrzymania. Uwagi przekazywane będą faksem lub pisemnie. Wykonawca zobowiązany jest uwzględnić uwagi Zamawiającego i przekazać dokumentację do ponownej akceptacji Zamawiającego w terminie do 3 dni roboczych od otrzymania ww. uwag.

3.4.4. Odbiór opracowanej dokumentacji projektowej Systemu zostanie potwierdzony protokołem zdawczo-odbiorczym, który zawierał będzie co najmniej następujące informacje: nazwę i adres Wykonawcy i Zamawiającego, spis przekazywanych dokumentów, podpisy przedstawicieli obu Stron Umowy.

3.5. Odbiór Zadania II nastąpi na podstawie poniższej procedury:3.5.1. W przypadku, gdy przedmiotem odbioru będzie dokumentacja stosuje się

odpowiednio procedurę określoną w pkt 3.4, z zastrzeżeniem, iż odbiór zostanie potwierdzony właściwymi protokołami zdawczo-odbiorczymi produktów.

3.5.2. Odbiór pozostałych prac przewidzianych dla Zadania II odbędzie się po przeprowadzeniu przez Zamawiającego testów akceptacyjnych Systemu, które zakończyły się wynikiem pozytywnym.

3.5.3. Odbiory funkcjonalne poszczególnych części Systemu dokonywane będą w oparciu o wymagania dla Systemu określone w Umowie, w ZZW oraz w opracowanej przez Wykonawcę i zatwierdzonej przez Zamawiającego dokumentacji projektowej Systemu.

3.5.4. Po zakończeniu prac wdrożeniowych Wykonawca zgłosi pisemnie gotowość do ich odbioru.

17

3.5.5. Zamawiający dokona weryfikacji zgodności Systemu z postawionymi wymaganiami na podstawie testów akceptacyjnych prowadzonych zgodnie z obowiązującą u Zamawiającego Polityką Bezpieczeństwa.

3.5.6. Zamawiający przeprowadzi testy akceptacyjne Systemu w danym obszarze funkcjonalnym, w terminie do 5 dni roboczych od wpływu zgłoszenia Wykonawcy o gotowości wykonanych prac do testów.

3.5.6.1. Wykonawca odpowiada za:3.5.6.1.1. przygotowanie planu testów, danych testowych 3.5.6.1.2. dostarczenie arkuszy testowych,3.5.6.1.3. przygotowanie środowiska testowego,3.5.6.1.4. instalację aplikacji,3.5.6.1.5. ładowanie danych testowych,3.5.6.1.6. przygotowanie scenariuszy testowych zawierających co

najmniej następujące pola dla każdego testowanego przypadku: nazwa przypadku użycia, opis testu, warunki wstępne, procedura testowa, oczekiwane rezultaty. Scenariusze testowe podlegają akceptacji przez Zamawiającego.

3.5.6.2. Testy wykonywane są u Zamawiającego. Wykonawca będzie odpowiedzialny za skonfigurowanie środowiska obciążającego (wykonującego scenariusze testowe) na sprzęcie wskazanym przez Zamawiającego.

3.5.6.3. Wykonawca zapewni oprogramowanie do wykonania testów przez Zamawiającego, o ile będzie ono niezbędne do przeprowadzenia testów.

3.5.6.4. Testy akceptacyjne zostaną przeprowadzone w oparciu o scenariusze testowe opracowane przez Wykonawcę. Wykonawca jest zobowiązany do asysty w czasie testów akceptacyjnych, podczas której będzie w szczególności, na bieżąco instruował uczestników testów o sposobie realizacji poszczególnych scenariuszy testowych oraz przygotowywał raporty z testów. Zamawiający zastrzega możliwość przeprowadzenia testów w oparciu o własne scenariusze.

3.5.6.5. Testy akceptacyjne będą składały się z następujących typów testów:3.5.6.5.1. Testy funkcjonalne:

3.5.6.5.1.1. testy czarnej skrzynki - testy odnoszą się do specyfikacji pracy systemu. Podczas analizy wyników testów nie jest badany wewnętrzny sposób realizacji funkcji systemu. Testy weryfikują implementację funkcjonalności z podaną w specyfikacji. Dane wejściowe i oczekiwane wyniki przygotowywane są na podstawie specyfikacji. Podczas testów system jest traktowany jak czarna skrzynka, na wejściu której podajemy przygotowane dane wejściowe sprawdzamy, czy otrzymane wyniki zgadzają się z oczekiwanymi,

3.5.6.5.1.2. testy modułowe - testy funkcjonalnej całości określonego fragmentu systemu (modułu), które mają na celu sprawdzenie, czy aplikacja działa zgodnie z uzgodnioną specyfikacją wymagań

18

dla poszczególnych modułów. Upewnienie się, że każda funkcja umożliwia realizację wszystkich dopuszczalnych akcji i sytuacji, oraz uniemożliwia realizację każdej akcji i sytuacji zabronionej,

3.5.6.5.1.3. testy GUI - sprawdzenie nawigacji w Systemie, sprawdzenie poprawności interfejsu i specyfikacji modułu help ,

3.5.6.5.1.4. testy administracji i kontroli procedur administracji,3.5.6.5.2. Testy integracyjne:

3.5.6.5.2.1. testy instalacji i uzyskanej konfiguracji – testy polegają na sprawdzeniu kompletności instalacji, zgodności przebiegu procesu instalacji z instrukcją, dokumentacją oraz poprawności uzyskanej konfiguracji,

3.5.6.5.2.2. testy komunikacji między modułami - testy poprawności powiązań między modułami. Celem testu jest wykazanie, że poszczególne moduły systemu prawidłowo ze sobą współpracują i na tej podstawie dalsze testy sprawdzają, czy funkcjonalność systemu wymagająca zaangażowania wielu modułów jest również realizowana prawidłowo,

3.5.6.5.3. Testy wydajnościowe i bezpieczeństwa:3.5.6.5.3.1. testy wydajności - dotyczą wydajności działania systemu

w różnych warunkach jego obciążenia. Testy weryfikują, czy system jest w stanie w oczekiwanym czasie obsłużyć/wykonać oczekiwaną liczbę danych/funkcji. Testy wymagają pomiarów czasu wykonania poszczególnych funkcji i zweryfikowania przepustowości kanałów przeznaczonych do obsługi danych. W celu uzyskania właściwej oceny należy zasymulować w miarę możliwości rzeczywiste warunki pracy systemu w jego rzeczywistym środowisku wraz z symulowanym obciążeniem rzeczywistym kanałów transmisji danych,

3.5.6.5.3.2. testy obciążenia znamionowego - celem testu jest zweryfikowanie zachowania się systemu w typowych warunkach, potwierdzając tym samym prawidłową, stabilną pracę systemu, z wydajnością nie mniejszą od oczekiwanej, zdefiniowaną w dokumentacji technicznej,

3.5.6.5.3.3. testy przeciążenia – celem testu jest zweryfikowanie zachowania się systemu w nietypowych warunkach. Test zazwyczaj ma potwierdzić, że system zachowuje się stabilnie i nie doprowadza do utraty danych (niespójności bazy itp.),

3.5.6.5.3.4. testy stabilności - kontrola stabilnej pracy systemu przez czas minimum 24 godzin,

3.5.6.5.3.5. testy bezpieczeństwa – w tym bezpieczeństwo dostępu do danych i zabezpieczenia danych przed utratą lub nieautoryzowaną zmianą, administracja użytkownikami i bazą danych, zakres dostępu do funkcji i danych, cross site scripting,

19

SQL injection, reakcja na nieoczekiwane dane. Reakcja na podmianę komponentów, bibliotek systemu, itp.

3.5.6.5.3.6. testy regresywne – wykonywane po wprowadzeniu zmian do systemu i mające na celu sprawdzenie, czy nowo wprowadzone poprawki nie mają wpływu na wcześniej zrealizowane funkcje systemu.

3.5.7. W przypadku zastrzeżeń Zamawiającego co do zakresu i jakości wdrażanego Systemu, polegających w szczególności na stwierdzeniu błędów w działaniu Systemu w danym obszarze funkcjonalnym, Zamawiający przekaże Wykonawcy w formie Protokołu Rozbieżności nieprawidłowo działające funkcje oprogramowania wraz z ich opisem.

3.5.8. Wykonawca jest zobowiązany do usunięcia wskazanych przez Zamawiającego Błędów Systemu w terminie 3 dni roboczych.

3.5.9. Po usunięciu Błędów Wykonawca przeprowadzi wewnętrzne testy regresywne i ponownie zgłosi pisemnie gotowość do odbioru Systemu w danym obszarze funkcjonalnym. Postanowienia pkt. 3.5.5-3.5.8 stosuje się odpowiednio.

3.5.10. Odbiór Zadania II jako całości nastąpi po przedstawieniu Zamawiającemu przez Wykonawcę wszystkich przewidzianych dla tego zadania protokołów zdawczo-odbiorczych produktów bez uwag.

3.6. Odbiór Zadania III nastąpi na podstawie poniższej procedury:3.6.1. W przypadku, gdy przedmiotem odbioru będzie wykonanie szkoleń dla

administratorów, o których mowa w pkt 2.16, Wykonawca zobowiązany jest do przedstawienia podpisanych list uczestników szkoleń dla administratorów.

3.6.2. Odbiór pozostałych elementów Zadania III zostanie przeprowadzony zgodnie z procedurą opisaną w punkcie 3.5.

3.7. Odbiór Zadania IV nastąpi na podstawie poniższej procedury dla każdego ze zleceń:3.7.1. W ustalonym terminie oddania zleconych zadań, Wykonawca przedstawia w

środowisku testowym wynik prac zrealizowanych w ramach Zlecenia.3.7.2. Oprogramowanie przekazane przez Wykonawcę poddawane jest testom

przeprowadzanym przez Zamawiającego przy wykorzystaniu scenariuszy testów opracowanych przez Zamawiającego. Zamawiający w zależności od rodzaju zmian przeprowadza testy funkcjonalne, wydajnościowe, bezpieczeństwa, w szczególności przy wykorzystaniu opracowanej przez Wykonawcę dokumentacji.

3.7.3. W przypadku negatywnego wyniku testów, Zamawiający przekaże Wykonawcy protokoły testów oraz określi termin usunięcia błędów. Czas wymagany do usunięcia błędów nie jest wliczany do czasu pracy Wykonawcy. Po usunięciu błędów ponownie przeprowadzane są testy wykonywane przez Wykonawcę i Zamawiającego.

3.7.4. W przypadku pozytywnego wyniku testów, podpisywany jest protokół zdawczo-odbiorczy, który stanowi załącznik nr 4 do ZZW.

3.7.5. W przypadku zgodności zrealizowanych prac z wymaganiami Zamawiającego, Zamawiający wdraża wynik prac w środowisku produkcyjnym.

20

3.8. Odbiór Zadania V nastąpi po spełnieniu łącznie następujących warunków3.8.1. Wykonawca przekaże narzędzie do monitorowania on-line parametrów

realizacji serwisu gwarancyjnego oraz parametru pracy serwerów.

3.8.1.1. Wykonawca zgłosi pisemnie możliwość korzystania przez co najmniej 5 (pięciu) pracowników Zamawiającego z narzędzia zawierającego mechanizmy monitorowania parametrów, wraz z instrukcją obsługi ww. narzędzia.

3.8.1.2. Zamawiający dokona weryfikacji zgodności narzędzia do monitorowania on-line parametrów realizacji serwisu gwarancyjnego oraz parametru pracy serwerów z postawionymi wymaganiami.

3.8.2. Zamawiający dokona weryfikacji zgodności przekazanego Systemu z postawionymi wymaganiami.

3.8.3. W przypadku zastrzeżeń Zamawiającego co do zakresu i jakości wdrażanego Systemu, polegających w szczególności na stwierdzeniu błędów w działaniu Systemu w danym obszarze funkcjonalnym, Zamawiający przekaże Wykonawcy w formie Protokołu Rozbieżności nieprawidłowo działające funkcje oprogramowania wraz z ich opisem.

3.8.4. Wykonawca jest zobowiązany do usunięcia wskazanych przez Zamawiającego Błędów Systemu.

3.8.5. Po usunięciu Błędów Wykonawca ponownie zgłosi pisemnie gotowość do przekazania Systemu w danym obszarze funkcjonalnym. Postanowienia pkt 3-4 stosuje się odpowiednio.

3.9. Odbiór końcowy nastąpi po przedstawieniu Zamawiającemu przez Wykonawcę protokołów zdawczo-odbiorczych Zadań 1 – 4 niniejszej Umowy. Odbiór końcowy zostanie potwierdzony protokołem końcowym.

4. Wymagania formalno-prawne oraz dobre praktyki4.1. Wykonawca zapewni zgodność Systemu z wymogami wynikającymi

z wymienionych poniżej przepisów aktów prawnych oraz dobrych praktyk, według stanu obowiązującego w dniu uruchomienia produkcyjnego Systemu.

4.2. W okresie gwarancji Wykonawca będzie aktualizował System w celu zapewnienia zgodności Systemu ze zmianami w wymienionych poniżej przepisach prawa oraz dobrymi praktykami.

LP Akty prawne

1.Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych ( Dz. U. z 2014 r., poz. 1182, z późn. zm.) wraz z aktami wykonawczymi.

2. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz. U. z 2004 r., Nr 100,

21

LP Akty prawne

poz. 1024z późn. zm.).

3.Ustawa o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz. U. 2014 r., poz. 1114 z późn. zm.) wraz z aktami wykonawczymi.

4.Ustawa z 18 września 2001r. o podpisie elektronicznym (Dz. U. z 2013r., poz. 262 z późn. zm.) wraz z aktami wykonawczymi.

5.Ustawa z dnia 27 lipca 2001 r. o ochronie baz danych (Dz. U. z 2001 r., Nr 128, poz. 1402 z późn. zm.).

6.Ustawa z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (Dz. U. z 2013 r., poz. 1422 z późn. zm.) wraz z aktami wykonawczymi.

7.Ustawa z dnia 16 lipca 2004 r. Prawo telekomunikacyjne (Dz.U. 2014 r., poz. 243, z późn. zm.).

8.

Wytyczne Ministra Rozwoju Regionalnego z dnia 13 sierpnia 2007 r. (po wprowadzeniu zmiany w dniu 5 października 2007 r.) w zakresie informacji i promocji oraz Strategią Komunikacji Funduszy Europejskich w Polsce na lata 2007-2013, określające podstawowe zasady prowadzenia działań informacyjnych i promocyjnych na potrzeby Narodowej Strategii Spójności oraz wszystkich programów operacyjnych w jej ramach.

9.

Wytyczne dotyczące oznaczania projektów w ramach Programu Operacyjnego Kapitał Ludzki, które stanowią załącznik 1, i są integralną częścią obowiązującej wersji Planu komunikacji PO KL.

10.

Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych.

LP Dobre praktyki

1. Rekomendacje WAI (ang. Web Accessibility Initiative) w zakresie WCAG 2.0.

2.Publikacja „WCAG 2.0 podręcznik dobrych praktyk” dotycząca dostępności stron internetowych przez osoby niewidome i niedowidzące (www.widzialni.org).

5. ZałącznikiZałącznik nr 1 Księga Identyfikacji Wizualnej Kompleksowego Systemu Internetowego

PARP dostępna pod adresem: https://www.web.gov.pl/g2/big/2013_11/e3596f3b52a09a0ea3a0fc746b2c7bff.pdf

Załącznik nr 2 Zobowiązanie do zachowania poufności

Załącznik nr 3 Formularz zlecenia

22

Załącznik nr 4 Protokół zdawczo-odbiorczy

23