Zakres zadań merytorycznych – opis przedmiotu zamówienia ...€¦ · Web viewZałącznik nr 1 do SIWZ. Szczegółowy opis przedmiotu zamówienia „Wykonanie serwisu internetowego

Wykonanie serwisu internetowego Wielkopolskiego Regionalnego Programu Operacyjnego na lata 2014-2020

Załącznik nr 1 do SIWZ

Szczegółowy opis przedmiotu zamówienia

„Wykonanie serwisu internetowego Wielkopolskiego Regionalnego Programu Operacyjnego na lata 2014-2020 (WRPO 2014-2020) wraz z systemem zarządzania treścią (CMS), mapą, licznikiem, wyszukiwarką dotacji, systemem organizacji szkoleń, przeniesieniem autorskich praw majątkowych, praw pokrewnych do utworów związanych z wykonaniem przedmiotu zamówienia, jego serwisowaniem i doskonaleniem, usługami gwarancyjnymi z uwzględnieniem wymagań wynikających z bieżących oczekiwań użytkowników i konsultantów oraz usługą jego hostowania.”

Strona 1 z 50


Poznań, lipiec 2014 r.

SPIS TREŚCI

1. INFORMACJE OGÓLNE 32. DEFINICJE 43. OGÓLNE WYMAGANIA TECHNICZNE 94. LICENCJONOWANIE 115. OBSŁUGA SERWISU 126. ZGODNOŚĆ Z OBOWIĄZUJĄCYMI AKTAMI PRAWNYMI 137. HARMONOGRAM REALIZACJI 15

a. Odbiory częściowe 15b. Odbiory końcowe 16c. Testy akceptacyjne 16

8. ZAKRES PRAC 17Zadanie 1 – Zapoznanie się z dokumentacją serwisu WRPO 2007-2013 i systemu CMS, mapą, licznikiem, wyszukiwarką dotacji i systemem organizacji szkoleń 17Cel Zadania 1 17

Oczekiwane rezultaty realizacji Zadania 1 17Zadanie 2 – Zaprojektowanie, wykonanie, uruchomienie i wdrożenie nowego serwisu internetowego WRPO 17

Cel Zadania 2 17Oczekiwane rezultaty realizacji Zadania 2 18

Zadanie 3 – Przygotowanie i przekazanie Zamawiającemu Projektu Koncepcyjnego, Projektu Wykonawczego, Dokumentacji Powykonawczej oraz Instrukcji Użytkowania serwisu WRPO 31

Cel Zadania 3 31Oczekiwane rezultaty realizacji Zadania 3 32

Zadanie 4 – Szkolenie dla administratorów i redaktorów serwisu WRPO 32Cel Zadania 4 32Oczekiwane rezultaty realizacji Zadania 4 32

Strona 2 z 50


Zadanie 5 – Serwis, doskonalenie, usługi gwarancyjne i hosting serwisu WRPO 33

Cel Zadania 5 33Gwarancja obejmuje naprawę błędów klasyfikowanych jako: 36Oczekiwane rezultaty realizacji Zadania 5 39

1. INFORMACJE OGÓLNE

Przedmiotem zamówienia jest „Wykonanie serwisu internetowego Wielkopolskiego Regionalnego Programu Operacyjnego na lata 2014-2020 (WRPO 2014-2020) wraz z systemem zarządzania treścią (CMS), mapą, licznikiem, wyszukiwarką dotacji, systemem organizacji szkoleń, przeniesieniem autorskich praw majątkowych, praw pokrewnych do utworów związanych z wykonaniem przedmiotu zamówienia, jego serwisowaniem i doskonaleniem, usługami gwarancyjnymi z uwzględnieniem wymagań wynikających z bieżących oczekiwań użytkowników i konsultantów oraz usługą jego hostowania.”

Serwis internetowy wraz z systemem CMS jest dedykowany dla celów publikowania informacji dotyczących Wielkopolskiego Regionalnego Programu Operacyjnego na lata 2014-2020.

Celem realizacji zamówienia pt. „Wykonanie serwisu internetowego Wielkopolskiego Regionalnego Programu Operacyjnego na lata 2014-2020 (WRPO 2014-2020) wraz z systemem zarządzania treścią (CMS), mapą, licznikiem, wyszukiwarką dotacji, systemem organizacji szkoleń, przeniesieniem autorskich praw majątkowych, praw pokrewnych do utworów związanych z wykonaniem przedmiotu zamówienia, jego serwisowaniem i doskonaleniem, usługami gwarancyjnymi z uwzględnieniem wymagań wynikających z bieżących oczekiwań użytkowników i konsultantów oraz usługą jego hostowania” jest stworzenie serwisu zapewniającego dużą elastyczność w zakresie konfiguracji funkcjonalności oraz prezentacji treści, a także posiadającego duże możliwości dalszego rozwoju.

Celem prawidłowego przygotowania oferty, Wykonawca musi zapoznać się z dotychczas przygotowanymi i opublikowanymi w serwisach www.wrpo.wielkopolskie.pl oraz www.funduszeeuropejskie.wielkopolskie.pl artykułami przygotowanymi przez Urząd Marszałkowski Województwa Wielkopolskiego, Departament Polityki Regionalnej - Oddział Informacji, Promocji i Szkoleń.

Strona 3 z 50

http://www.funduszeeuropejskie.wielkopolskie.pl/

http://www.wrpo.wielkopolskie.pl/


2. DEFINICJE

AI - Architektura Informacji, czyli pokazanie struktury serwisu za pomocą grafu.

ATOM – standard kanałów informacyjnych mających zastąpić RSS

Artykuł – tekst (wraz z opcjonalnymi dodatkami multimedialnymi takimi jak Strona 4 z 50


zdjęcia, wideo, audio itp.) opatrzony tytułem, tekstem zapowiadającym, treścią właściwą oraz podpisem składającym się z daty i godziny utworzenia, opublikowania i modyfikacji, a także imienia i nazwiska autora. Artykuł może zostać podzielony na części (stronicowany), z których każda będzie wyświetlana indywidualnie z możliwością nawigacji pomiędzy tymi częściami. Widok artykułu musi być zgodny z rekomendacjami Ministerstwa Infrastruktury i Rozwoju.

Captcha – ang. Completely Automated Public Turing Test to Tell Computers and Humans Apart – rodzaj techniki stosowanej jako zabezpieczenie w formularzach na stronach WWW. Dla przesłania danych konieczne jest przepisanie treści z pliku graficznego (zazwyczaj losowo dobranych znaków bądź krótkiego wyrazu). Rodzaj stosowanego zabezpieczenia Captcha musi być zgodny z rekomendacjami Ministerstwa Infrastruktury i Rozwoju dot. standardu WCAG 2.0

CMS – ang. Content Management System (CMS) - system zarządzania treścią jest to aplikacja internetowa lub ich zestaw, pozwalająca na łatwe utworzenie serwisu WWW (jednego bądź kilku) oraz jego późniejszą aktualizację i rozbudowę przez redakcyjny personel nietechniczny. Kształtowanie treści i sposobu prezentacji w serwisie zarządzanym przez CMS odbywa się za pomocą prostych w obsłudze interfejsów użytkownika, zazwyczaj w postaci stron WWW zawierających rozbudowane formularze.

CSS – ang. Cascading Style Sheets – język służący do opisu formy prezentacji (wyświetlania) stron WWW. Można nim opisać sposób prezentacji elementów dokumentów internetowych, takich jak rodzina czcionek, kolor tekstu, marginesy, odstęp międzywierszowy lub nawet pozycja danego elementu względem innych elementów bądź okna przeglądarki. Wykorzystanie arkuszy stylów daje znacznie większe możliwości pozycjonowania elementów na stronie niż oferuje sam (X)HTML. CSS został stworzony w celu odseparowania struktury dokumentu od formy jego prezentacji. Separacja ta zwiększa zakres dostępności witryny, zmniejsza zawiłość dokumentu, ułatwia wprowadzanie zmian w strukturze dokumentu. CSS ułatwia także zmiany w renderowaniu strony w zależności od obsługiwanego medium (ekran, palmtop, dokument w druku, czytnik ekranowy). Stosowanie zewnętrznych arkuszy CSS daje możliwość zmiany wyglądu wielu stron naraz bez ingerowania w sam kod (X)HTML, ponieważ arkusze mogą być wspólne dla wielu dokumentów.

Dodatek – w systemie CMS wykonuje pewne dodatkowe działania w tle, np. formatują treść i ukrywają adres e-mail w treści artykułu.

Dział – patrz: Kategoria

Dostęp do zawartości statycznej – funkcjonalność polegająca na wyświetlaniu statycznych tekstów, dokumentów i innego rodzaju zawartości multimedialnej.

Strona 5 z 50


Dostęp do zawartości dynamicznej – funkcjonalność umożliwiająca prezentację zawartości tworzonej na bieżąco poprzez informacje pobierane z baz danych, generowane z każdym ich wywołaniem na podstawie zdefiniowanych reguł.

Dzień roboczy – każdy dzień tygodnia za wyjątkiem niedziel, dni ustawowo wolnych od pracy oraz sobót.

GUI – (ang. Graphical User Interface ) graficzny interfejs użytkownika, widoki graficzne stron, inaczej środowisko graficzne) – ogólne określenie sposobu prezentacji informacji przez komputer oraz interakcji z użytkownikiem/internautą.

Intranet – sieć wewnętrzna Zamawiającego łącząca ośrodek centralny oraz ośrodki lokalne za pośrednictwem sieci rozległej WAN. Z zasobów intranetu może korzystać pracownik mobilny dzięki wykorzystaniu bezpiecznych szyfrowanych połączeń VPN (ang. Virtual Private Network).

Javascript – JavaScript (JS) – obiektowy skryptowy język programowania, stosowany na stronach internetowych. Skrypty służą m.in. do zapewnienia interaktywności poprzez reagowanie na zdarzenia, sprawdzanie poprawności formularzy lub budowania elementów nawigacyjnych, interaktywnych itp.

Kategoria – służy do logicznego grupowania stron w ramach serwisu. Kategoria może zawierać kategorie podrzędne (podkategorie) tworząc w ten sposób hierarchiczną strukturę zawartości serwisu. Kategoria może posiadać swoją stronę opartą o dowolny szablon lub w szczególności o szablon prezentujący listę podkategorii i/lub stron zawartych w danej kategorii.

Komponent – element CMS pozwalający stworzyć treść i dodać zdjęcia oraz opublikować zebrane materiały. Z danych zgromadzonych przez komponenty korzystają moduły.

Moduł – fragment CMS zawierający określony zbiór funkcjonalności, np. moduł zarządzania użytkownikami, uprawnieniami, szablonami, wyszukiwarka, czat, mapa serwisu, forum dyskusyjne, galeria, często zadawane pytania (FAQ), księga gości itp. Moduł może posiadać kategorie i strony oraz może być elementem składowym strony w przypadku np. wyszukiwarki.

Newsletter – elektroniczna forma biuletynu rozsyłanego za pomocą poczty elektronicznej do zarejestrowanych użytkowników lub zdefiniowanej grupy odbiorców.

Personalizacja – dostosowywanie zawartości i wyglądu (sposobu wyświetlania) serwisu do indywidualnych potrzeb użytkownika i/lub pełnionej przez niego roli w systemie.

Serwis internetowy – internetowy serwis informacyjny poszerzony o Strona 6 z 50


różnorodne funkcje internetowe, dostępny z jednego adresu internetowego. Treść serwisu stanowią najczęściej: dział aktualnych wiadomości, prognoza pogody, katalog stron WWW, czat, forum dyskusyjne oraz mechanizmy wyszukiwania informacji w nim samym lub w zewnętrznych zasobach internetu.

Powiadamianie – informacje o nowych treściach na stronie internetowej i/lub zdefiniowanych zdarzeniach przesyłane automatycznie pocztą elektroniczną do zarejestrowanych użytkowników lub zdefiniowanej grupy odbiorców.

Projekt – niniejsze przedsięwzięcie realizowane przez Wykonawcę na rzecz Zamawiającego zgodnie z umową zawartą między nimi oraz wymaganiami zawartymi w SIWZ.

Rejestr zmian – lista modyfikacji funkcjonalności lub wyglądu serwisu zatwierdzonych przez Zamawiającego aktualizowana na bieżąco przez Wykonawcę.

RSS – ang. Really Simple Sindication – oparta na języku XML technika przesyłania nagłówków wiadomości.

RWD – ang. Responsive Web Design. Ideą responsywności jest tworzenie stron internetowych, które nie będą się rozciągać wypełniając okno przeglądarki, a w zależności od rozmiaru urządzenia, będą prezentować użytkownikowi zróżnicowany, najbardziej optymalny dla jego rozdzielczości (oraz urządzenia - smartfonu, tabletu czy też komputera) układ treści.

Serwis internetowy/intranetowy – stworzony za pomocą CMS zbiór powiązanych tematycznie i umieszczonych na serwerze/serwerach stron internetowych.

Serwis WRPO - serwis www.wrpo.wielkopolskie.pl oraz www.funduszeeuropejskie.wielkopolskie.pl

SLA – ang. Service Level Agreement – umowa utrzymania i systematycznego poprawiania ustalonego między klientem a usługodawcą poziomu jakości usług poprzez stały cykl obejmujący: uzgodnienia, monitorowanie usługi, raportowanie, przegląd osiąganych wyników.

SSL – ang. Secure Socket Layer – protokół typu klient-serwer pozwalający na nawiązanie bezpiecznego połączenia z użyciem certyfikatów x509. Umożliwia bezpieczną transmisję zaszyfrowanego strumienia danych.

Strona internetowa/intranetowa – służy do prezentacji artykułów oraz modułów w oparciu o zdefiniowane szablony wyglądu. Pobierana z serwera i interpretowana po stronie użytkownika za pomocą przeglądarki. Może zawierać hipertekst (odnośniki), multimedia, elementy prezentacyjne (wykonane np. w technologii Flash), formularze oraz inne elementy interaktywne. Może być statyczna lub tworzona dynamicznie w momencie

Strona 7 z 50




zażądania jej przez przeglądarkę internetową z serwera. Elementy wykonane w technologii Flash muszą być zgodne z rekomendacjami Ministerstwa Infrastruktury i Rozwoju dot. standardu WCAG 2.0

Szablon – opis wyglądu strony WWW, będący wzorcem wykonania strony na podstawie zdefiniowanych wcześniej schematów, służący do prezentacji artykułów na stronach o identycznym układzie graficznym, ale o innej zawartości.

System – patrz: CMS

Testy UAT – ang. User Acceptance Tests – testy, których celem nie jest wykrycie błędów, a jedynie uzyskanie formalnego potwierdzenia wykonania oprogramowania odpowiedniej jakości.

UIUX – ang. User Interface and User Experience czyli projekt interfejsu, który ma za zadanie wywołać pozytywne doświadczenie użytkownika. Najczęściej przedstawiany w postaci makiety, szkicu, schematu przyszłej strony. Na podstawie UIUX przygotowywane jest GUI.

Strona 8 z 50


Unicode – uniwersalny standard kodowania znaków przypisujący unikalny numer każdemu znakowi, niezależny od używanej platformy, programu czy języka.

URL – ang. Uniform Resource Locator – zunifikowany format odnośników (adresów) wskazujący lokalizację zasobu.

Strona 9 z 50


Utrzymanie serwisu WRPO – obejmuje obsługę administracyjną serwisu (usługi hostingu serwera, usługę backupu, zapewnienie bezpieczeństwa serwera, serwisu WRPO, baz danych oraz danych osobowych), obsługę techniczną serwisu, obsługę redakcyjną serwisu oraz pozostałe usługi dodatkowe spełniające wymagania techniczne Zamawiającego.

W3C – ang. World Wide Web Consortium (W3C) to organizacja, która zajmuje się ustanawianiem standardów pisania i przesyłu stron www.

Walidacja – sprawdzenie poprawności.

WCAG – ang. Web Content Accessibility Guidelines (polskie tłumaczenie: Wytyczne dotyczące dostępności treści internetowych) – zbiór dokumentów opublikowany przez WAI (Web Accessibility Initiative (polskie tłumaczenie: Inicjatywa dostępności do sieci) – inicjatywa W3C mająca na celu zwiększenie szeroko rozumianej dostępności stron www) zawierający zalecenia dotyczące tworzenia dostępnych serwisów internetowych.

Wersja robocza – wersja artykułu w trakcie tworzenia przez redaktorów, przed publikacją w serwisie.

WRPO - Wielkopolski Regionalny Program Operacyjny.

Wsparcie techniczne – patrz: Utrzymanie serwisu WRPO.

WYSIWYG – ang. What You See Is What You Get co znaczy dosłownie To Co Widzisz Jest Tym Co Otrzymasz – akronim stosowany w informatyce dla określenia metod, które pozwalają uzyskać wynik w publikacji identyczny lub bardzo zbliżony do obrazu na ekranie. Programy spełniające założenia WYSIWYG prezentują na monitorze komputera dane (tekstowe, graficzne) w sposób jak najbardziej zbliżony do uzyskanego po ich wydrukowaniu lub innym przeniesieniu do postaci fizycznej.

Wyszukiwarka – funkcjonalność systemu polegająca na możliwości odnalezienia treści zawartej w serwisie lub wielu serwisach obsługiwanych przez system na podstawie słów i ich kombinacji.

Wyszukiwarka lokalna - funkcjonalność systemu zapewniająca funkcjonalność wyszukiwarki dla ograniczonego obszaru strony, kategorii lub serwisu.

XHTML – ang. Extensible HyperText Markup Language – rozszerzalny hipertekstowy język znaczników – język służący do tworzenia stron WWW. XHTML jest następcą języka HTML. Specyfikację języka XHTML przygotowuje organizacja W3C.

Strona 10 z 50


3. OGÓLNE WYMAGANIA TECHNICZNE

Serwis powinien zostać wykonany z zastosowaniem najlepszych praktyk w dziedzinie budowania witryn WWW i w zgodności z najnowszymi standardami, które wyznacza W3C (World Wide Web Consortium).

Architektura informacji serwisu internetowego WRPO 2014-2020, jego funkcjonalności oraz szata graficzna muszą być zgodne z:

aktualnymi rekomendacjami Ministerstwa Infrastruktury i Rozwoju (Załącznik nr 1 do SOPZ - Opis architektury informacji serwisu internetowego Regionalnego Programu Operacyjnego, Wersja elektroniczna dokumentu wraz z załącznikami (folder „SRPO_v11” i dokument „opis_AI_SRPO_1_2_02042014.docx”; folder „Grafika_GUI” i podfoldery: „Czcionki”, „SRPO_ekrany_GUI”, „Zestaw_ikon”).

art. 6 ust. 4 oraz art. 7 Rozporządzenia 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.2004.100.1024 ze zm.)

oraz dostosowane do standardów:

Responsive Web Design (RWD) - zgodnie z zasadami RWD, wygląd graficzny strony internetowej powinien zmieniać swój stan po przekroczeniu pewnych punktów granicznych (breakpoints) w szerokości obszaru przeglądarki, w którym wyświetlana jest strona internetowa. Serwis WRPO 2014-2020 powinien zostać zaprojektowany przy użyciu punktów granicznych:

Desktop: 1024px (szerokość wyjściowa)Tablet: 768pxMobile: 320px

Web Content Accessibility Guidelines (WCAG 2.0) - rozwiązania w zakresie dostępu przez osoby z różnymi rodzajami niepełnosprawności muszą być zgodne z rekomendacjami zawartymi w dokumentach:1. Fundacja Widzialni „Podręcznik dobrych praktyk”:

http://widzialni.org/wcag-20-podrecznik-dobrych-praktyk,m,mg,5,51 Strona 11 z 50

http://widzialni.org/wcag-20-podrecznik-dobrych-praktyk,m,mg,5,51


2. Fundacja Widzialni - metodologia badania stron:http://widzialni.org/container/metodologia-badania-dostepnosci-stron-www.pdf

3. Fundacja Integracja - podręcznik „Dostępność serwisów internetowych” Dobre praktyki w projektowaniu serwisów internetowych dostępnych dla osób z różnymi rodzajami niepełnosprawności http://dostepnestrony.pl/o-projekcie/ii-edycja-projektu/podrecznik-dostepnosc-serwisow-internetowych/

Serwis winien wykorzystywać system zarządzania treścią (CMS) umożliwiający jego dalszy rozwój po wygaśnięciu Umowy z Wykonawcą, a w szczególności zmianę szaty graficznej, nagłówka i stopki oraz układu menu nawigacyjnego i rozmieszczenia poszczególnych elementów serwisu.

Serwis WRPO 2014-2020 wraz z systemem zarządzania treścią winien wykorzystywać wyłącznie:

technologie umożliwiające dalsze wykorzystywanie i rozwój platformy bez konieczności zakupu licencji, bądź

technologie umożliwiające dalsze wykorzystywanie i rozwój platformy przy użyciu oprogramowania, dla którego koszt zakupu licencji jest równy zeru, bądź

pozostałe technologie, z tym, że Wykonawca zobowiązany jest pokryć wszystkie koszty licencji niezbędne do uruchomienia systemu.

Wykonawca wraz z kompletnym kodem źródłowym i pełną kopią bezpieczeństwa serwisu WRPO 2014-2020 musi przekazać Zamawiającemu nieodpłatnie wszystkie licencje niezbędne do prawidłowego działania serwisu WRPO 2014-2020, umożliwiające szybką zmianę dostawcy usług hostingowych oraz uruchomienie serwisu WRPO 2014-2020 z zachowaniem gwarantowanej jakości usług hostingowych. Wykaz wszystkich licencji niezbędnych do prawidłowego działania serwisu WRPO 2014-2020 stanowi Załącznik nr 7 do SIWZ.

Serwis winna cechować: dostępność (obsługa przez najpopularniejsze przeglądarki internetowe:

Firefox 28.x i wyższe, Chrome 34.x i wyższe, MS Internet Explorer 11.x i wyższe, Opera 20.x i wyższe, Safari 7.x i wyższe oraz WebKit Mobile 7.x i wyższe, Chrome Mobile 34.x i wyższe, OperaMini 7.x i wyższe, IEMobile 10.x i wyższe oraz dla trzech wcześniejszych wersji przeglądarek, zgodnie z rekomendacjami Ministerstwa Infrastruktury i Rozwoju);

otwartość, skalowalność, możliwość elastycznego zarządzania modułami funkcjonalnymi;

bezpieczeństwo.

Serwis WRPO 2014-2020 powinien być zbudowany w oparciu o 3-warstwowy model aplikacji (warstwa prezentacji, logiki, danych) z uwzględnieniem zmian w zakresie technologii ICT oraz zapewniać możliwość szybkiej zmiany dostawcy usług hostingowych.

Strona 12 z 50

http://dostepnestrony.pl/o-projekcie/ii-edycja-projektu/podrecznik-dostepnosc-serwisow-internetowych/

http://dostepnestrony.pl/o-projekcie/ii-edycja-projektu/podrecznik-dostepnosc-serwisow-internetowych/

http://widzialni.org/container/metodologia-badania-dostepnosci-stron-www.pdf

http://widzialni.org/container/metodologia-badania-dostepnosci-stron-www.pdf


System CMS powinien opierać się o system zarządzania bazą danych.

Serwis musi zawierać informacje dotyczące polityki prywatności zgodnie ze wzorem określonym w załączniku nr 6 do Umowy.

Serwis musi zapewniać pozyskanie zgody na przetwarzanie danych osobowych od osób tworzących profil dostępowy do niego. Utworzenie profilu logowania się dla użytkownika nie może nastąpić bez uzyskania zgody na przetwarzanie jego danych osobowych.

Wykonawca jest zobowiązany do systematycznych aktualizacji systemu zarządzania treścią pod kątem bezpieczeństwa w ramach gwarancji udzielonej Zamawiającemu.

Nie dopuszcza się przechowywania treści jedynie w postaci statycznych stron internetowych.

Wykonawca zapewni optymalizację kodu strony ułatwiającą pozycjonowanie treści serwisu WRPO 2014-2020 w najpopularniejszych wyszukiwarkach internetowych.

Kod dostarczonego rozwiązania musi być jawny i dostarczony w takiej postaci, aby zamawiający był w stanie prześledzić jego działanie pod kątem bezpieczeństwa. Zabronione jest korzystanie z mechanizmów szyfrujących typu ioncube.

Dostęp do paneli administracyjnych oraz logowania dla użytkowników musi być zabezpieczony poprzez wykorzystanie certyfikatu SSL dostarczonego przez Zamawiającego.

Wykonawca udzieli gwarancji na dostarczony serwis na okres 108 miesięcy od daty podpisania protokołu końcowego.

Wykonawca zobowiązany jest do serwisowania i zapewnienia hostingu serwisu do 31 grudnia 2023 roku (z możliwością przedłużenia na osobnych zasadach).Wykonawca po ustaniu okresu serwisowania i hostingu zobowiązany jest do przekazania Zamawiającemu zarchiwizowanej wersji całego serwisu, łącznie z bazami danych oraz instalacji serwisu w miejscu wskazanym przez Zamawiającego.

Wykonawca nie później niż 7 dni roboczych po podpisaniu protokołu końcowego uruchomi wersję testową serwisu, która cały czas będzie odzwierciedleniem funkcjonalnym wersji produkcyjnej.

Wykonawca musi spełnić wszystkie wymagania określone w SOPZ i SIWZ.

Strona 13 z 50


4. LICENCJONOWANIE

Wykonawca dostarczy Zamawiającemu wykaz wszystkich licencji (Załącznik nr 8 do SIWZ) oraz nieodpłatnie przekaże Zamawiającemu wszystkie licencje (systemowe, narzędziowe, serwerowe, bazodanowe, itp.) niezbędne do prawidłowej pracy i pełnego korzystania z serwisu WRPO 2014-2020.

W przypadku licencji GPL (ang. General Public Licence), zazwyczaj stosowanej w oprogramowaniu typu Open Source, Wykonawca nie ma możliwości przekazania autorskich praw majątkowych, ponieważ nie jest ich właścicielem. Ze względu na fakt, że wykorzystanie komponentów GPL wiąże się z obowiązkiem ich wydania również na licencji GPL, Zamawiający dopuszcza przekazanie licencji GPL lub innej licencji na oprogramowanie autorskie z prawem modyfikacji kodu źródłowego. W przypadku, gdy zdjęcia i materiały są objęte licencjami otwartymi, Wykonawca musi zapewnić szczegółową informację o podstawie i dopuszczalnym zakresie ich wykorzystania.

Wykonawca gwarantuje nabycie autorskich praw majątkowych oraz uzyskanie zgód i zezwoleń (licencji) od osób trzecich w zakresie umożliwiającym pełną realizację funkcjonalności narzędzia informatycznego (systemu).

Wykonawca dostarczy Zamawiającemu wszystkie kody źródłowe oprogramowania wykorzystywanego przez serwis WRPO 2014-2020 i system CMS, które powstaną w wyniku realizacji Umowy. Przekazanie wszystkich kodów źródłowych zapewni Zamawiającemu nieograniczoną technicznie możliwość wprowadzania modyfikacji wyglądu i funkcjonalności serwisu wraz z systemem CMS.

Wykonawca zapewni Zamawiającemu stały dostęp do aktualnej wersji kompletnego kodu źródłowego opracowywanych narzędzi informatycznych poprzez system kontroli wersji SVN, Mercurial lub Visual SourceSafe.

Wraz z serwisem WRPO 2014-202 i systemem CMS musi zostać dostarczone 50 jednoczesnych licencji dostępowych dla administratorów i redaktorów systemu, przy czym w bazie danych systemu CMS może być ich zarejestrowana dowolna ilość. Każda z licencji musi umożliwiać dostęp administracyjny i redakcyjny do wszystkich treści i funkcjonalności systemu.

Każda z instalacji systemu musi umożliwiać jednoczesny dostęp dla nieograniczonej liczby użytkowników końcowych serwisu WRPO 2014-2020, zarówno zarejestrowanych jak i niezarejestrowanych.

Serwis WRPO 2014-2020 wraz z systemem zarządzania treścią winien być udostępniony w sposób określony w licencji publicznej Unii Europejskiej.

Strona 14 z 50


5. OBSŁUGA SERWISU

Serwis wraz z systemem CMS będzie uruchomiony na serwerze wskazanym przez Wykonawcę w domenie www.wielkopolskie.pl. Zamawiający dokona zmiany delegacji domeny na serwer wskazany przez Wykonawcę w terminie do 2 tygodni od daty podpisania protokołu odbioru końcowego końcowej wersji serwisu zawierającej wszystkie wymagane funkcjonalności wraz z w pełni funkcjonalnym systemem CMS i szkoleniami użytkowników.

Wykonawca zobowiązany jest zapewnić obsługę serwisu WRPO 2014-2020, która trwać będzie do dnia 31.12.2023 r.

Wykonawca zobowiązany jest utrzymywać serwis 2014-2020 wraz z systemem CMS poprzez zapewnienie usługi hostingu serwera, która trwać będzie do dnia 31.12.2023 r.

Przed rozpoczęciem świadczenia usług hostingowych na rzecz Zamawiającego, Wykonawca dostarczy Zamawiającemu szczegółową politykę bezpieczeństwa stosowaną przez dostawcę usług hostingowych oraz przez pracowników Wykonawcy w zakresie systemu CMS.

Polityka bezpieczeństwa musi obejmować opis wszystkich zastosowanych metod i środków gwarantujących odpowiedni poziom bezpieczeństwa informacji, zgodnie z Polityką Bezpieczeństwa Informacji UMWW (Załącznik nr 3 do umowy) oraz zapisami umowy stanowiącej Załącznik nr 6 do SIWZ.

W opisie zabezpieczeń muszą znaleźć się ustawienia w systemie CMS oraz konfiguracji serwera WWW oraz pełnione przez nie funkcje zapobiegające atakom i włamaniom, takie jak np. filtrowanie danych wejściowych, pochodzących zarówno od użytkownika, jak i ze źródeł zewnętrznych.

Wykonawca ma obowiązek zapewniać na bieżąco odpowiedni poziom bezpieczeństwa serwera, serwisu WRPO, baz danych oraz danych osobowych. Wykonawca jest zobowiązany podjąć niezbędne działania bez konieczności zlecania ich przez Zamawiającego.

Wykonane audyty bezpieczeństwa oraz testy wydajnościowe powinny zostać przekazane Zamawiającemu w formie szczegółowych raportów.

Wykonawca zobowiązuje się w szczególności do:a) właściwego zabezpieczenie fizycznego i organizacyjnego przetwarzanych zbiorów,b) opracowania procedur/instrukcji postępowania w typowych przypadkach związanych z przetwarzaniem danych osobowych,

Dokumentacja przygotowana przez Wykonawcę powinna obejmować w szczególności:a) instrukcję zarządzania systemem informatycznym służącym do

Strona 15 z 50

http://www.wielkopolskie.pl/


przetwarzania danych osobowych,b) szczegółową politykę bezpieczeństwa zawierającą:

wykaz budynków, pomieszczeń lub części pomieszczeń, tworzących obszar, w którym przetwarzane są dane osobowe,

wykaz zbiorów danych osobowych wraz ze wskazaniem programów zastosowanych do przetwarzania tych danych,

opis struktury zbiorów danych wskazujący zawartość poszczególnych pól informacyjnych i powiązania między nimi,

sposób przepływu danych pomiędzy poszczególnymi systemami, dodatkowe środki techniczne i organizacyjne mające na celu

zapewnienie poufności, integralności przy przetwarzaniu danych,c) treść klauzul spełniających obowiązek informacyjny,d) treść klauzul dotyczącą zgód na przetwarzanie danych osobowych,e) przygotowanie innych dokumentów niezbędnych do prawidłowego funkcjonowania systemu ochrony danych osobowych.

Wykonawca udzieli gwarancji na dostarczony serwis WRPO 2014-2020 wraz z systemem CMS, mapą i licznikiem dotacji, systemem organizacji szkoleń i nowymi funkcjonalnościami na okres 108 miesięcy od daty podpisania protokołu końcowego.

Hosting musi być świadczony z zachowaniem wysokiego bezpieczeństwa i poufności danych. W przypadku, kiedy hosting będzie świadczony przez firmę zewnętrzną, Wykonawca przedstawi odpowiednie dokumenty poświadczające bezpieczeństwo danych (politykę bezpieczeństwa, certyfikaty).

W przypadku, gdy Wykonawca sam będzie świadczył usługi hostingu, także zobowiązany jest do przedstawienia odpowiednich dokumentów poświadczających bezpieczeństwo danych (polityka bezpieczeństwa). Centrum przetwarzania danych, w którym będzie realizowany dedykowany hosting znajdować się musi na terenie Polski.

Obsługa serwisu WRPO 2014-2020 obejmuje co najmniej: obsługę administracyjną serwisu, obsługę techniczną serwisu, obsługę redakcyjną serwisu.

Zadania, wykonywane przez Wykonawcę w ramach obsługi administracyjnej, technicznej i redakcyjnej opisane zostały szczegółowe w Zadaniu 5 – Serwis, doskonalenie, usługi gwarancyjne i hosting serwisu WRPO.

6. ZGODNOŚĆ Z OBOWIĄZUJĄCYMI AKTAMI PRAWNYMI

Dostarczony system musi być zgodny z obowiązującymi aktami prawnymi Strona 16 z 50


mającymi wpływ na jego działanie i realizowaną funkcjonalność na dzień złożenia oferty.

System musi spełniać wymagania określone w poniższych ustawach:

1. Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz. U. 2013.235)

2. Ustawa z 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (Dz. U. 02.144.1204 z późn. zm.) wraz z aktami wykonawczymi

3. Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz. U. 02.101.926 z późn. zm.), oraz wymagania na poziomie wysokim określone w Rozporządzeniu 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.2004.100.1024)

4. Ustawa z dnia 6 września 2001 r. o dostępie do informacji publicznej (Dz. U. 01.112.1198 z późn. zm.)

5. Rozporządzenie Rady Ministrów 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 (Dz.U. z 2012 poz. 526)

6. Obwieszczenie Marszałka Sejmu Rzeczypospolitej Polskiej z dnia 10 stycznia 2014 r. w sprawie ogłoszenia jednolitego tekstu ustawy – Prawo telekomunikacyjne (Dz.U. 2014 nr 0 poz. 243)

7. Standardami W3C (HTML 5 i CSS 3)

8. Standardami WCAG 2.0 dot. dostępności dla osób z niepełnosprawnościami. (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. Załącznik nr 4 – minimalny poziom spełnienia wytycznych).

Strona 17 z 50


Wykonawca zobowiązany jest przez cały okres obowiązywania umowy do dostosowania systemu do zmian aktów prawnych mających wpływ na dostarczony system i realizowane przez niego funkcjonalności w ramach świadczonych usług wsparcia, bez prawa do dodatkowego wynagrodzenia z tego tytułu.

System musi być dostosowany do zmian aktów prawnych przed ich wejściem w życie.

9. HARMONOGRAM REALIZACJI

Przedmiot Zamówienia jako całość zrealizowany zostanie według harmonogramu uwzględniającego przekazanie wersji testowej i wersji końcowej w podanych poniżej terminach.

Przekazanie testowej wersji serwisu wraz z testowym systemem CMS nastąpi do 8 tygodni od daty podpisania umowy.

Przekazanie testowej wersji mapy i licznika dotacji oraz systemu organizacji

Strona 18 z 50


szkoleń nastąpi do 10 tygodni od daty podpisania umowy.

Przekazanie końcowej wersji mapy i licznika dotacji oraz systemu organizacji szkoleń nastąpi do 12 tygodni od daty podpisania umowy.

Wymagania dodatkowe dotyczące harmonogramu:

a. Odbiory częściowe

Odbiory częściowe dotyczą dokumentów lub funkcjonalności, które będą przekazywane Zamawiającemu w ramach wersji testowej i będą podlegać zmianom przed przekazaniem wersji końcowej Przedmiotu Zamówienia. Odbiorów częściowych w formie pisemnego potwierdzenia zgodności z wymaganiami dokona upoważniony przedstawiciel Zamawiającego.

W przypadku przekazywania Zamawiającemu dokumentów lub funkcjonalności cząstkowych systemu do odbioru, należy przewidzieć w harmonogramie czas niezbędny na weryfikację i odbiór przez Zamawiającego (3 dni robocze) oraz wprowadzeniem niezbędnych poprawek i uzupełnień przed ponownym przedstawieniem do odbioru (5 dni roboczych).

Modyfikacje w zakresie funkcjonalności na etapie ich odbioru częściowego i końcowego będą wykonywane w trybie 3 x 3, tj. 3 razy po maksymalnie 3 dni potrzebne Zamawiającemu na weryfikację i testowanie funkcjonalności. Jeżeli po trzeciej turze testów nadal będą występować błędy, Zamawiający przeprowadzi kolejne 3-dniowe tury testów z zastrzeżeniem, iż nie wpłyną one na zmianę uzgodnionego wcześniej harmonogramu.

Wersja testowa dostarczonego serwisu WRPO 2014-2020 musi zostać przetestowana przez firmę audytorską współpracującą z Zamawiającym pod kątem luk w oprogramowaniu. Dostarczony system będzie mógł być uruchomiony produkcyjnie jedynie w wypadku pozytywnej opinii audytora lub poprawieniu luk i błędów wskazanych w raporcie. Po usunięciu luk i wprowadzeniu poprawek nastąpi ponowny test aplikacji wykonywany przez firmę audytorską współpracującą z Zamawiającym.

Odbiór częściowy musi zostać dokonany w terminie przewidzianym w harmonogramie realizacji zadania. Niedotrzymanie terminu przez Wykonawcę będzie uznane za nienależyte wykonanie części Zadania określonej w SOPZ i będzie skutkowało naliczeniem kary umownej w wysokości 20 % Wynagrodzenia.

b. Odbiory końcowe

Odbiory końcowe dotyczą dokumentów lub funkcjonalności, które będą przekazywane Zamawiającemu w ramach wersji końcowej Przedmiotu Zamówienia. Odbiorów końcowych w formie pisemnego potwierdzenia

Strona 19 z 50


zgodności w wymaganiami dokona upoważniony przedstawiciel Zamawiającego.

W przypadku przekazywania Zamawiającemu końcowych wersji dokumentów lub pełnych funkcjonalności systemu do odbioru, należy przewidzieć w harmonogramie czas niezbędny na weryfikację i odbiór przez Zamawiającego (3 dni robocze) oraz wprowadzenie niezbędnych poprawek i uzupełnień przed ponownym przedstawieniem do odbioru (5 dni roboczych).

Modyfikacje w zakresie funkcjonalności na etapie ich odbioru częściowego i końcowego będą wykonywanie w trybie 3 x 3, tj. 3 razy po maksymalnie 3 dni potrzebne Zamawiającemu na weryfikację i testowanie funkcjonalności. Jeżeli po trzeciej turze testów nadal będą występować błędy, Zamawiający przeprowadzi kolejne 3-dniowe tury testów z zastrzeżeniem, iż nie wpłyną one na zmianę uzgodnionego wcześniej harmonogramu.

Odbiór końcowy musi zostać dokonany w terminie przewidzianym w harmonogramie realizacji zadania. Niedotrzymanie terminu przez Wykonawcę będzie uznane za nienależyte wykonanie części Zadania określonej w SOPZ i będzie skutkowało naliczeniem kary umownej w wysokości 20 % Wynagrodzenia.

c. Testy akceptacyjne

Testy akceptacyjne dotyczą wybranych funkcjonalności Przedmiotu Zamówienia, takich jak w szczególności: mapa i licznik dotacji oraz system organizacji szkoleń. Testów akceptacyjnych w formie pisemnego potwierdzenia zgodności z wymaganiami dokona upoważniony przedstawiciel Zamawiającego.

W przypadku testów akceptacyjnych należy przewidzieć czas niezbędny na testy i odbiór przez Zamawiającego (5 dni roboczych) oraz wprowadzenie niezbędnych poprawek i uzupełnień przed ponownym przedstawieniem do odbioru (7 dni roboczych).

Modyfikacje w zakresie funkcjonalności na etapie ich odbioru częściowego i końcowego będą wykonywanie w trybie 3 x 5, tj. 3 razy po maksymalnie 5 dni potrzebnych Zamawiającemu na weryfikację i testowanie funkcjonalności. Jeżeli po trzeciej turze testów nadal będą występować błędy, Zamawiający przeprowadzi kolejne 5-dniowe tury testów z zastrzeżeniem, iż nie wpłyną one na zmianę uzgodnionego wcześniej harmonogramu.

Testy akceptacyjne muszą zostać dokonane w terminie przewidzianym w harmonogramie realizacji zadania. Niedotrzymanie terminu przez Wykonawcę będzie uznane za nienależyte wykonanie części Zadania określonej w SOPZ i będzie skutkowało naliczeniem kary umownej w wysokości 20 % Wynagrodzenia.

Strona 20 z 50


10. ZAKRES PRAC

Zadanie 1 – Zapoznanie się z dokumentacją serwisu WRPO 2007-2013 i systemu CMS, mapą, licznikiem, wyszukiwarką dotacji i systemem organizacji szkoleń

Cel Zadania 1

Celem Zadania 1 jest zaktualizowanie oraz stworzenie dokumentacji technicznej serwisu internetowego WRPO (www.wrpo.wielkopolskie.pl oraz www.funduszeeuropejskie.wielkopolskie.pl) obejmującej wykorzystywane struktury danych i model bazy danych oraz opisanie funkcjonalności, które mają zostać przeniesione i ulepszone w serwisie WRPO 2014-2020, takich jak w szczególności: mapa, licznik, wyszukiwarka dotacji i system organizacji szkoleń.

Oczekiwane rezultaty realizacji Zadania 1W wyniku realizacji Zadania 1 powstanie dokumentacja techniczna służąca do ewidencji architektury oraz funkcjonalności serwisu WRPO 2007-2013, a także do późniejszej weryfikacji zgodności zawartości serwisu WRPO 2014-2020 oraz jego nowych i ulepszonych funkcjonalności.

Dokumentacja techniczna powinna zostać przedstawiona w pliku w formacie Microsoft™ Word (DOC) oraz dodatkowo zapisana w formacie Adobe™ PDF i nie powinna przekraczać 150 stron i zapisana na nośniku DVD. Dokument powinien być przygotowany czcionką Times New Roman, 12 pkt, interlinia 1, wszystkie marginesy 2,5 cm.

Termin realizacji Zadania 1: odbiór częściowy: do 2 tygodni od daty podpisania umowy. odbiór końcowy: do 3 tygodni od daty podpisania umowy.

Zadanie 2 – Zaprojektowanie, wykonanie, uruchomienie i wdrożenie nowego serwisu internetowego WRPO

Cel Zadania 2Celem Zadania 2 jest zaprojektowanie, wykonanie, uruchomienie i wdrożenie nowego serwisu internetowego WRPO zgodnie z wytycznymi przekazanymi przez Zamawiającego dot. nowej szaty graficznej serwisu, nowego układu menu nawigacyjnego oraz nowych funkcjonalności.

Zamawiający przekaże Wykonawcy 5 przykładowych szablonów, zgodnych z rekomendacjami Ministerstwa Infrastruktury i Rozwoju, które pokazują najtrudniejsze strony serwisu oraz wizualizują kształt graficzny całej strony

Strona 21 z 50




WRPO: 1. strona główna (wraz z wariantami), 2. lista naborów (z wariantami: aktywne filtry, brak wyników) i widok

naboru, 3. lista wiadomości (z wariantami: aktywne filtry, brak wyników) i widok

wiadomości, 4. strona punktów informacyjnych i strona formularza z punktu

informacyjnego, 5. lista dokumentów (z wariantami: aktywne filtry, brak wyników) oraz

widok dokumentu.

Oczekiwane rezultaty realizacji Zadania 2W wyniku realizacji Zadania 2 powinny zostać przygotowane szczegółowe dokumenty takie jak:

1. Projekt graficzny serwisu WRPO 2014-2020, zgodnie z wytycznymi przekazanymi przez Zamawiającego i rekomendacjami Ministerstwa Infrastruktury i Rozwoju.

2. Projekt graficzny menu nawigacyjnego zgodnie z wytycznymi przekazanymi przez Zamawiającego i rekomendacjami Ministerstwa Infrastruktury i Rozwoju.

3. Projekt graficzny systemu organizacji szkoleń, zgodnie z wytycznymi przekazanymi przez Zamawiającego.

Projekty graficzne serwisu WRPO 2014-2020, menu nawigacyjnego i systemu organizacji szkoleń podlegają akceptacji i odbiorowi częściowemu oraz końcowemu przez Zamawiającego.

Wygląd projektu graficznego może podlegać aktualizacji w trakcie prac wdrożeniowych. Każda zmiana w projekcie graficznym odnotowana w rejestrze zmian musi zostać zatwierdzona przez Zamawiającego.

Projekty graficzne powinny zostać przedstawione na płycie DVD i opisane w pliku w formacie Microsoft™ Word (DOC) oraz dodatkowo zapisane w formacie Adobe™ PDF i plikach graficznych PNG (ang. Portable Network Graphics), a także jako elementy graficzne w dużej rozdzielczości jako załączniki w formatach Adobe™ Illustrator (AI) i/lub Adobe™ Photoshop (PSD).

Każdy z projektów nie powinien przekraczać 30 stron. Dokument powinien być przygotowany czcionką Times New Roman, 12 pkt, interlinia 1, wszystkie marginesy 2,5 cm.

Termin realizacji Zadania 2:

Przekazanie i odbiór częściowy testowej wersji serwisu wraz z testowym systemem CMS nastąpi do 8 tygodni od daty podpisania umowy.

Przekazanie i odbiór częściowy testowej wersji mapy i licznika dotacji oraz systemu rejestracji uczestników szkoleń nastąpi do 10 tygodni od daty podpisania umowy.

Strona 22 z 50


Przekazanie i odbiór końcowy końcowej wersji mapy i licznika dotacji oraz systemu rejestracji uczestników szkoleń nastąpi do 12 tygodni od daty podpisania umowy.

Przekazanie i odbiór końcowy końcowej wersji serwisu zawierającej wszystkie wymagane funkcjonalności wraz z w pełni funkcjonalnym systemem CMS i szkoleniami użytkowników nastąpi do 30 listopada 2014r.

Serwis WRPO 2014-2020 przedstawiony do odbioru końcowego powinien być zgodny ze standardami:

W3C (World Wide Web Consortium)

Responsive Web Design (RWD)

Web Content Accessibility Guidelines (WCAG 2.0).

aktualnymi rekomendacjami Ministerstwa Infrastruktury i Rozwoju (Opis architektury informacji serwisu RPO wraz z Graficznym Interfejsem Użytkownika, czcionkami, zestawem ikon zostanie przekazany Wykonawcy w dniu podpisania umowy).

art. 6 ust. 4 oraz art. 7 Rozporządzenia 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.2004.100.1024 ze zm.)

a także oraz posiadać poniższe funkcjonalności:

Panel administracyjny

System musi być wyposażony w panel administracyjny dostępny dla administratorów i redaktorów serwisu, zawierający wszystkie funkcje administracyjne i redakcyjne systemu.

Funkcje administracyjne

Administrator merytoryczny musi posiadać pełne uprawnienia do wszelkich kategorii administracyjnych w serwisie, w tym m.in. do:- zarządzania kontami użytkowników systemu, w tym: dodawaniem, usuwaniem, modyfikacją, nadawaniem uprawnień do określonych czynności w serwisie jak tworzenie treści, edycja, usuwanie, publikowanie,- zarządzania profilami uprawnień (rolami),- tworzenia grup użytkowników i nadawania uprawnień grupom,- tworzenia i zarządzania polityką haseł (reguły dot.

Strona 23 z 50


budowy hasła, jego długości i złożoności, wymuszania zmiany przy następnym logowaniu),- definiowania zakresu dostępu do danych i plików gromadzonych w systemie.System musi umożliwiać nadawanie uprawnień redaktorom do określonych wersji językowych i kategorii serwisu. Uprawnienia muszą być dziedziczone kaskadowo.System musi posiadać moduł autoryzacji użytkowników przy pomocy loginu i hasła oraz na tej podstawie identyfikować oraz określać zakres uprawnień użytkownika.

Dostęp do profili administracyjnych oraz logowania dla użytkowników, musi zapewniać: indywidualnie zdefiniowanie loginu i hasła dla

użytkownika, przechowywanie haseł dostępowych w sposób

uniemożliwiający ich przedstawienie w formacie jawnego tekstu,

hasło dostępowe musi składać się z co najmniej 8 znaków oraz zawierać duże i małe litery, cyfry i znaki specjalne,

system musi weryfikować złożoność hasła, hasło powinno wygasać po 30 dniach.

System musi umożliwiać delegowanie uprawnień administracyjnych do wybranych fragmentów serwisu dla wskazanego użytkownika lub grupy użytkowników.

Historia operacji

System musi zapisywać i udostępniać historię wszystkich operacji włącznie z logowaniem.Historia musi być dostępna dla administratora i pozwalać na wyszukiwanie oraz filtrowanie co najmniej takich atrybutów jak: data i czas operacji z dokładnością do minuty, nazwa użytkownika, rodzaj operacji, miejsce wykonania operacji lub nazwa pliku na którym wykonano operację.System musi zapisywać w dzienniku systemowym historię operacji wykonywanych automatycznie przez system, np. kopii bezpieczeństwa, wysyłki newsletterów i powiadomień.System musi raportować błędy w działaniu systemu CMS, w tym także kody błędów HTPP (np. 404) wygenerowane przez system CMS.

Najczęściej zadawane

pytania – FAQ

System musi posiadać funkcjonalność umożliwiającą tworzenie bazy pytań i odpowiedzi na nie wraz z formularzem umożliwiającym zadawanie pytań oraz możliwością ich sortowania, filtrowania i wyszukiwania wg słów kluczowych.

Strona 24 z 50


Użytkownik zadający pytanie musi otrzymać e-mail z informacją o pojawieniu się odpowiedzi na zadane pytanie.

Kodowanie znaków

System musi kodować znaki w standardzie Unicode UTF-8 wersja 3.0Wszelkie treści umieszczane w serwisie powinny być automatycznie konwertowane do tego zestawu znaków.

Optymalizacja dla

wyszukiwarek

CMS musi posiadać możliwość optymalizacji każdej strony serwisu pod kątem wyszukiwania (SEO - Search Engine Optimization), w tym przypisywania indywidualnych słów kluczowych i opisu w ramach pól „Meta”, tytułów strony w znaczniku <Title> i adresu URL strony.System musi umożliwiać indywidualne wypełnianie atrybutów „Alt” grafik używanych w serwisu.

Obsługa błędów

System musi posiadać mechanizm obsługi błędów poprzez możliwość dostosowania stron błędów (np. 404) dla każdego z bloków tematycznych w ramach serwisu.System musi generować prawidłowe kody błędów http (prawidłowo rozpoznawane przez wyszukiwarki internetowe) dla nieistniejących, przeniesionych lub ukrytych elementów serwisu (plików, kategorii, artykułów).

Technologia budowy

interfejsu

Wszystkie strony serwisów muszą być co najmniej zgodne ze standardem HTML 5 i CSS 3.Wymagana jest prawidłowa walidacja tworzonego przez CMS kodu HTML i CSS za pomocą udostępnionego na stronach W3C walidatora (http://validator.w3.org)System oraz udostępniane za jego pomocą serwisy muszą być oparte na stylach CSS do formatowania prezentowanych treści, a struktura dokumentu musi zapewniać poprawność semantyczną oraz oddzielenie wyglądu od treści.

Dostępność w przeglądarkach internetowych

Serwis i system CMS muszą poprawnie realizować założone funkcjonalności co najmniej w następujących przeglądarkach: Firefox 28.x i wyższe, Chrome 34.x i wyższe, MS Internet Explorer 11.x i wyższe, Opera 20.x i wyższe, Safari 7.x i wyższe oraz WebKit Mobile 7.x i wyższe, Chrome Mobile 34.x i wyższe, OperaMini 7.x i wyższe, IEMobile 10.x i wyższe oraz dla trzech wcześniejszych wersji przeglądarek, zgodnie z rekomendacjami Ministerstwa Infrastruktury i Rozwoju.Jeśli wykorzystywany będzie kod JavaScript, on także musi prawidłowo działać w wymienionych wyżej przeglądarkach.

Poczta e-mailCMS musi współpracować z serwerem poczty elektronicznej obsługującym konta w domenie wskazanej przez Zamawiającego, w której będzie działać

Strona 25 z 50

http://validator.w3.org/


serwis.Na potrzeby realizacji zadania, Wykonawca udostępni serwer poczty elektronicznej oraz założy konta i aliasy umożliwiające m.in. rozsyłanie newsletterów, powiadomień oraz wiadomości e-mail.

Zatwierdzanie i publikacja treści

artykułów

System musi zapewniać możliwość ustawienia przez administratora opcji wymagania lub nie wymagania akceptacji nowych artykułów w ramach wybranych kategorii tematycznych.Administrator musi mieć możliwość ustawienia opcji wymagania lub nie wymagania zatwierdzenia treści artykułów redagowanych przez określonych użytkowników systemu.System musi umożliwiać określenie dla poszczególnych kategorii tematycznych administratorów lub redaktorów zatwierdzających treści przed ich publikacją.System musi zapewniać możliwość edycji artykułu przez użytkownika uprawnionego do zatwierdzenia treści artykułu.

Załączanie plików do pobrania

Dla każdego artykułu będzie możliwe zdefiniowanie listy plików do pobrania, znajdujących się w repozytorium systemu. Z poziomu repozytorium musi istnieć możliwość dodania nowego pliku w celu dołączenia do artykułu. Pliki do pobrania muszą być prezentowane w postaci ikon charakterystycznych dla danego formatu, odnośnika, definiowalnej przyjaznej nazwy odnośnika oraz wielkości podanej w kB (kilobajtach) lub MB (megabajtach).

Zawartość artykułu

Sposób prezentacji artykułu musi być zgodny z „Opisem architektury informacji” rekomendowanym przez Ministerstwo Infrastruktury i Rozwoju. Artykuł musi posiadać co najmniej następujące elementy: Tytuł artykułu (wypełnienie wymagane) Część nagłówkowa zawierająca początek artykułu lub

jego skrót z możliwością wstawienia elementu graficznego (wypełnienie opcjonalne) oraz datę publikacji i datę modyfikacji artykułu (wypełnienie wymagane, wyświetlanie opcjonalne)

Część główna artykułu posiadająca możliwość wstawienia treści oraz materiałów multimedialnych (audio, wideo, grafika, itp.) oraz stronicowania artykułu (wypełnienie wymagane, stronicowanie opcjonalne)

Stopka artykułu zawierająca co najmniej informacje takie jak: imię i nazwisko autora, nazwa jednostki organizacyjnej (wypełnienie wymagane, wyświetlanie opcjonalne)

Kategoria, w której powinien zostać opublikowany Strona 26 z 50


artykuł (wypełnienie wymagane) Słowa kluczowe artykułu (wypełnienie wymagane) Przyjazny link (adres URL) do artykułu tworzony

automatycznie na podstawie tytułu z możliwością modyfikacji (wypełnienie wymagane)

Informacja w RSS i/lub powiadomieniach o nowościach: Tak/Nie – domyślnie „Tak” (wypełnienie wymagane)

Odtwarzacz multimedialnyEdycja treści System musi posiadać pracujący w trybie on-line edytor

WYSIWYG pozwalający na pracę z artykułami publikowanymi w serwisie przy założeniu braku znajomości kodu HTML przez redaktorów.Edytor musi zapewniać możliwość edytowania tekstów w sposób typowy dla popularnych pakietów biurowych oraz wklejania tekstów z zachowaniem formatowania przyjętego w edytorze tekstu.Edytor musi posiadać co najmniej takie funkcje jak:a) Pole format zawierające predefiniowane elementy strukturalne treści (P, H1, H2, H3, H4)b)Pole styl – zawierające predefiniowane style CSSc) Możliwość wyboru czcionki i jej rozmiaru oraz predefiniowania domyślnej czcionki Ubuntu, zgodnie z rekomendacjami Ministerstwa Infrastruktury i Rozwojud)Opcje: Wytnij, Kopiuj, Wklej, Wklej jako czysty tekst, Wklej z Wordae) Opcje: Znajdź, Zamień, Zaznacz wszystko, Usuń formatowanief) Opcje: Pogrubienie, Kursywa, Podkreślenie, Przekreślenie, Indeks dolny, Indeks górnyg)Opcje: Wstaw/Usuń numerowanie listy, Wstaw/Usuń wypunktowanie listyh)Opcje: Zmniejsz/Zwiększ wcięcie, Wyrównaj do lewej, środka, prawej, lewej i praweji) Opcje: Wstaw/Edytuj/Usuń załącznik, grafikę, Flash, hiperłącze, kotwicę, embedowanie treści z serwisu YouTubej) Opcje: Wstaw/Edytuj tabelęk) Opcje: Zmień kolor czcionki, Zmień kolor tłal) Opcje: Pokaż/Edytuj kod źródłowym) Podgląd stronyn)Podział strony (stronicowanie), zgodnie z rekomendacjami Ministerstwa Infrastruktury i RozwojuKod wstawiany przez edytor musi być zgodny minimum ze standardami HTML 5 i CSS 3.Praca w edytorze musi odbywać się z poziomu przeglądarki internetowej bez konieczności instalacji

Strona 27 z 50


specjalnego oprogramowania klienckiego.Edytor musi posiadać 3 tryby wyświetlania zawartości: zwykły tryb edycyjny (WYSIWYG), tryb HTML i tryb podglądu strony (preview).Edytowany artykuł będzie mógł być wzbogacony przez pliki pobierane z repozytorium.Elementy graficzne dołączane do tekstów muszą mieć możliwość skalowania do dowolnych rozmiarów, wstawiania tekstu „Alt”, definiowania miejsca położenia, wielkości, sposobu wyrównania tekstu i otwarcia w nowym oknie lub w technice „overlay” (przed tekstem).System musi umożliwiać podgląd strony/artykułu na każdym etapie redakcji w układzie (szablonie) w jakim będzie on prezentowany w serwisu.

Artykuły wielostronicowe

Artykuły mogą mieć nieograniczoną ilość stron wewnętrznych (stronic).System musi posiadać możliwość dzielenia artykułów na pojedyncze wyświetlane stronice, wyświetlając jednocześnie na dole tekstu kolejne numery stronic w formie aktywnych odnośników, zgodnie z rekomendacjami Ministerstwa Infrastruktury i Rozwoju.

Konwersja i drukowanie artykułów

CMS musi posiadać możliwość:- wydrukowania dowolnego artykułu poprzez przygotowanie specjalnej wersji do druku opisanej i zdefiniowanej jako szablon,- konwersji dowolnego artykułu do formatu Adobe™ PDF,- wysłania odnośnika do dowolnego artykułu na podany adres e-mail.Treść wiadomości e-mail z odnośnikiem będzie ustalana przez Administratora w panelu administracyjnym.

Tworzenie menu nawigacyjnego

System musi posiadać narzędzia służące do budowy i zarządzania strukturą serwisu z możliwością samodzielnej budowy wielopoziomowego menu i jego modyfikacji oraz konfiguracji sposobu wyświetlania.Tytuł strony automatycznie staje się częścią odnośnika do tej strony i musi mieć możliwość zmiany nazwy strony bez równoczesnej zmiany tytułu strony. Tak przygotowany odnośnik musi automatycznie po opublikowaniu strony pojawić się w mapie serwisu.System musi zawierać ścieżkę nawigacyjną tak, aby użytkownik w każdym momencie wiedział w jakim miejscu w strukturze serwisu się znajduje i miał możliwość powrotu do wyższych poziomów struktury serwisu.

Mapa serwisuSystem musi automatycznie generować aktualną mapę serwisu umożliwiającą określenie poziomu zagłębienia w hierarchię kategorii i artykułów.

Zarządzanie System musi generować tzw. „czyste” adresy URL, np. Strona 28 z 50


URL-ami

www.wrpo.wielkopolskie.pl/gwiazdy_wielkopolskie/ Adres powinien zawierać informacje o kategorii/dziale strony i możliwą do zidentyfikowania indywidualną nazwę strony domyślnie generowaną na podstawie tytułu artykułu.

Statystyki odwiedzin

CMS musi posiadać zintegrowany moduł statystyk dla każdej kategorii, strony i pobieranego pliku.Statystyki muszą posiadać możliwość prezentacji w układzie zestawień godzinowych, dziennych, tygodniowych, miesięcznych i rocznych.Statystyki muszą zawierać co najmniej takie informacje jak:- liczba wejść na stronę- liczba unikalnych gości- czas trwania odwiedzin- rodzaj używanej przeglądarki- rodzaj używanego systemu operacyjnego- adres IP- najczęściej odwiedzane strony w serwisuSystem musi umożliwiać wykorzystanie zewnętrznych narzędzi do tworzenia statystyk, np. Google Analytics.System musi odfiltrowywać odwiedziny generowane przez roboty wyszukiwarek internetowych.

Wyszukiwanie informacji

System musi posiadać mechanizm wyszukiwania pełnotekstowego.Bezpośrednio dostępne musi być wyszukiwanie proste poprzez pole tekstowe widoczne na stronie głównej serwisu oraz domyślnie we wszystkich działach i stronach. Musi ono umożliwiać szybkie wyszukanie w całym serwisie po wybranym słowie lub kilku słowach domyślnie połączonych spójnikiem „i”.CMS musi udostępniać mechanizm wyszukiwania zaawansowanego umożliwiającego:

a) Szukanie dowolnego słowab) Szukanie wszystkich słówc) Szukanie dokładnego wyrażeniad) Szukanie wg zakresów i date) Szukanie we wskazanej kategorii

Po wpisaniu 3 pierwszych liter w polu tekstowym powinien aktywować się mechanizm livesearch, a wpisana fraza powinna automatycznie oznaczać się wytłuszczeniem w wyświetlanych podpowiedziach.Wyniki wyszukiwania wyświetlane będą wg trafności wyszukiwania.Dla wyszukanych artykułów podana zostanie co najmniej: ilość znalezionych lub brak znalezionych, kategoria, tytuły i data publikacji.Wyniki wyszukiwań muszą umożliwiać zliczanie przez zewnętrzne systemy rejestrowania statystyk serwisu,

Strona 29 z 50

http://www.wrpo.wielkopolskie.pl/gwiazdy_wielkopolskie/


np. przez Google Analytics.

Tworzenie formularzy

ankiet

CMS musi umożliwiać: tworzenie formularzy i pozwalać na ich umieszczenie

w dowolnych miejscach serwisu, przekierowywanie wprowadzanych odpowiedzi do

bazy danych, do plików XML oraz na wskazane konta e-mail w treści wiadomości, w postaci załącznika w formacie XML lub w postaci tekstu,

zabezpieczenia formularza za pomocą „Captcha”Wymagane typy pól, które muszą być dostępne w formularzach:- pole dot. wyrażenia zgody na przetwarzanie danych osobowych- pole tekstowe jednolinijkowe i wielolinijkowe z możliwością określenia długości oraz zestawu dostępnych do wprowadzenia znaków- pole wyboru typu „checkbox”- pole wyboru typu „radio button”- pole typu lista wyboru rozwijana- pole typu lista wyboru wyświetlana w całości z możliwością wyboru wielu pozycji- pole typu data z koniecznością walidacji daty pod względem formatu i poprawności- przyciski „Wyczyść formularz”, „Wyślij formularz, ”Drukuj formularz”System CMS musi: - posiadać możliwość tworzenia grup pól formularza, oznaczonych graficznie i posiadających własny opis,- umożliwiać dowolną zmianę układu i rozmieszczenia pól formularza na stronie,- umożliwiać oznaczenie pola jako wymagalnego i weryfikować jego wypełnienie,- posiadać możliwość walidacji pól typu: NIP, REGON, PESEL,- przypisania do każdego pola wartości domyślnej.Po wypełnieniu formularz system musi posiadać możliwość wyświetlenia wprowadzonych danych w celu ich weryfikacji, ponownej edycji lub wysłania.System musi posiadać możliwość opcjonalnego wysłania na podany adres e-mail potwierdzenia jego wypełnienia.

Warianty graficzne

Dla każdego projektu graficznego musi zostać zdefiniowany dodatkowo wariant żałoby narodowej (kir).Projekty graficzne wraz z arkuszami CSS muszą uwzględniać potrzeby osób słabowidzących i udostępniać takie rozwiązania jak opcja wysokiego kontrastu czy zmiana wielkości czcionki, zgodnie ze standardem WCAG 2.0

Wersja na urządzenia

Projekty graficzne muszą uwzględniać wymagania stawiane wersjom dedykowanym dla telefonów

Strona 30 z 50


mobilne

komórkowych i tabletów.Zgodnie z zasadami RWD (ang. Responsive Web Design), wygląd graficzny strony internetowej powinien zmieniać swój stan po przekroczeniu pewnych punktów granicznych (breakpoints) w szerokości obszaru przeglądarki, w którym wyświetlana jest strona internetowa. Serwis WRPO 2014-2020 powinien zostać zaprojektowany przy użyciu punktów granicznych:• DESKTOP: 1024px (szerokość wyjściowa)• TABLET: 768px• MOBILE: 320px

Szablony i wygląd serwisu

Wygląd serwisu (grafika, rozkład treści, typografia, itp.) musi być zdefiniowany w oparciu o system szablonów.System musi umożliwiać definiowanie indywidualnych szablonów dla poszczególnych kategorii serwisu, dla poszczególnych artykułów, list artykułów i bloków funkcjonalnych przy zachowaniu ogólnie przyjętego stylu dla całości serwisu.Definiowanie szablonów musi być dostępne dla Administratora systemu. System musi umożliwiać zmianę i modyfikację szablonów serwisu (wygląd i nawigacja) bez ingerencji w publikowane treści, tj. zmiana wyglądu nie będzie pociągała za sobą konieczności odtwarzania treści serwisu. Administrator musi mieć możliwość zmiany sposobu prezentacji wszystkich elementów widocznych na stronach internetowych dostępnych dla gości serwisuSystem musi umożliwiać wyłączanie poszczególnych bloków funkcjonalnych (np. wyszukiwarka) zdefiniowanych w ramach szablonu tak, aby nie były one pokazywane w wybranych kategoriach serwisu.W szablonie strony będą definiowane położenie oraz zakres elementów nawigacji (główne menu, submenu, ścieżka nawigacji, itp.). Każdorazowa zmiana zawartości menu z poziomu panelu administracyjnego musi powodować natychmiastową aktualizację elementów nawigacyjnych na stronach serwisu.System musi umożliwiać dowolne przenoszenie pozycji menu (góra/dół) względem siebie w danej kategorii oraz jednej kategorii względem innych kategorii.Szablony muszą być w pełni dostępne dla osób niepełnosprawnych, a w szczególności spełniać następujące zasady: wszystkie strony szablonów powinny mieć

zachowaną prawidłową strukturę hierarchii nagłówków,

przygotowany kod szablonów musi być wolny od błędów oraz poprawny semantycznie,

Strona 31 z 50


wprowadzenie odpowiedniej proporcji kontrastów, zgodnie z dostarczoną przez Zamawiającego dokumentacją,

wszystkie elementy graficzne oraz elementy, które można „kliknąć” muszą mieć zrozumiały tekst alternatywny; dodatkowo elementy klikalne po najechaniu muszą być sygnalizowane zmianą wyglądu kursora na „rękę”,

wymaga się, aby serwis dawał możliwość manipulowania rozmiarem tekstów stron serwisu za pomocą dostępnych skrótów klawiaturowych przeglądarki,

nawigacja powinna być dostępna za pomocą klawiatury.

Mapa, licznik i wyszukiwarka

dotacji

Serwis musi udostępniać funkcjonalności, takie jak mapa, licznik i wyszukiwarka dotacji. Mapa, licznik i wyszukiwarka dotacji muszą zostać udostępnione jako odnośniki do innych serwisów internetowych, rekomendowanych przez Ministerstwo Infrastruktury i Rozwoju.

Repozytorium plików

CMS musi posiadać repozytorium plików: graficznych, multimedialnych, tekstowych, PDF, itp. Musi ono obsługiwać co najmniej formaty wymienione w Rozporządzeniu Rady Ministrów w sprawie minimalnych wymagań dla systemów teleinformatycznych.CMS musi umożliwiać dostęp do repozytorium plików lub jego części, zgodnie z przyznanymi uprawnieniami, w celu dodawania nowych plików, zamiany wersji plików oraz usuwania zbędnych. Pliki gromadzone będą w sposób umożliwiający ich swobodne przeglądanie, katalogowanie i sortowanie.

Repozytorium plików musi umożliwiać co najmniej: tworzenie, kopiowanie, usuwanie katalogów i

podkatalogów przez użytkownika posiadającego odpowiednie uprawnienia,

dodawanie, usuwanie i zmianę nazwy plików, dodawanie opisu do pliku, edytowanie parametru „Alt” dla plików graficznych, sortowanie wg nazwy, typu, wielkości, daty dodania.

System musi umożliwiać dodawanie do repozytorium wielu plików na raz.

Pliki graficzne umieszczane w repozytorium serwisu muszą podlegać normalizacji zgodnie z konfiguracją dot. rozmiaru miniaturki oraz rozmiaru zdjęcia tzn. konwersji do określonego wymiaru i stopnia

Strona 32 z 50


kompresji, zarówno dla miniaturki jak i dla właściwego zdjęcia. System musi umożliwiać opublikowanie zdjęcia w oryginalnym rozmiarze.

Do przeglądania plików w formacie Adobe™ PDF wymagana jest funkcjonalność umożliwiająca: wysłanie maila z linkiem do publikacji udostępnienie publikacji na kilkudziesięciu serwisach społecznościowych skopiowanie i wklejenie linka do publikacji na swojej stronie lub blogu opublikowanie dokumentu w atrakcyjnej formie w treści artykułu wydrukowanie, pobranie, skomentowanie oraz ocenienie.

Dodatkowo wymagane jest umożliwienie wykorzystania przeglądarki dokumentów Google (Google Docs), pozwalającej na osadzanie, przeglądanie i udostępnianie do pobrania dokumentów w formatach jakie można dodać w Dokumentach Google, czyli w formatach programów Microsoft Word i OpenOffice, plików RTF i HTML lub zawierających zwykły tekst.

Odtwarzacz wideo/audio

System musi posiadać dedykowany i zintegrowany odtwarzacz umożliwiający odtworzenie bezpośrednio na stronie internetowej materiałów multimedialnych audio i wideo. Odtwarzacz musi obsługiwać co najmniej formaty FLV i MP3 oraz być zgodny ze standardem WCAG 2.0.System musi pozwalać na ograniczanie możliwości odtwarzania wybranych plików multimedialnych dla wskazanych grup użytkowników, np. nie zarejestrowanych lub zalogowanych.Brak dostępu dla użytkowników nie zalogowanych musi być realizowany poprzez funkcjonalność „Ukryj stronę”, aktywowaną/dezaktywowaną za pomocą opcji „checkbox” we właściwościach danej strony. Po aktywacji opcji ukrycia strony, wybrana strona musi stać się dostępna tylko dla użytkowników zalogowanych. Administrator musi mieć możliwość przypisania wyświetlania wybranej strony do wybranej grupy użytkowników zalogowanych (np.: tylko dla administratorów). Strona ukryta nie może być widoczna w wyszukiwarce serwisu (na stronie wynikowej), ani w strukturze serwisu (list aktualności itp.) ani indeksowana przez wyszukiwarki np.: Google).System musi umożliwiać umieszczanie odtwarzacza plików multimedialnych w wybranych miejscach strony internetowej.

Strona 33 z 50


CMS musi zapewniać możliwość określenia, czy materiał multimedialny jest odtwarzany automatycznie, czy po wybraniu przez użytkownika przycisku „Play” odtwarzacza.Odtwarzacz musi prezentować czas trwania nagrania, stan wczytywania pliku (czas), zatrzymanie i przewinięcie materiału oraz odtwarzanie materiałów wideo w trybie pełnoekranowym.Opcjonalnie musi być dostępna możliwość pobrania materiału multimedialnego i zapisania go na komputerze użytkownika serwisu.Odtwarzacz musi mieć możliwość pobierania listy innych plików multimedialnych i prezentować taką listę w postaci tytułów i miniatur graficznych na zakończenie odtwarzania pliku multimedialnego. System CMS musi pozwalać na przygotowanie takiej listy dla wszystkich materiałów wideo dodanych do serwisu. System musi posiadać możliwość stworzenia bloku funkcjonalnego prezentującego najnowsze materiały wideo w postaci listy zawierającej tytuł materiału, element graficzny oraz odnośnik.

Galerie zdjęć, panoramy

System musi posiadać możliwość prezentowania załączników graficznych w postaci galerii, w tym udostępnienia galerii zdjęć jako wydzielonych stron serwisu oraz w ramach artykułów.Galeria musi być prezentowana w postaci miniatur z możliwością powiększenia ich do ustalonego rozmiaru i pełnego oryginalnego rozmiaru.Otwieranie widoku powiększenia nie może być blokowane przez systemy blokujące okna typu „pop-up” przeglądarek.System musi posiadać możliwość otworzenia pliku powiększenia przy wyłączonej w przeglądarce obsłudze JavaScript.Musi istnieć możliwość zamieszczania podpisów zdjęć przy rozdzieleniu podpisu od atrybutu „Alt” przypisanego do pliku graficznego.Pliki graficzne umieszczane w galerii muszą podlegać normalizacji zgodnie z konfiguracją dot. rozmiaru miniaturki oraz rozmiaru zdjęcia tzn. konwersji do określonego wymiaru i stopnia kompresji, zarówno dla miniaturki jak i dla właściwego zdjęcia.System musi posiadać możliwość prezentowania materiałów takich jak panoramy zewnętrzne i wewnętrzne 360 stopni z funkcją „zoom”, obsługą za pomocą myszy i klawiatury. Panoramy muszą być utworzone na bazie wysokiej jakości zdjęć i podlegać normalizacji zgodnie z konfiguracją dot. konwersji do określonego wymiaru i stopnia kompresji.

Strona 34 z 50


Newsletter

Funkcjonalność newslettera musi być dostępna dla użytkowników, którzy wypełnili formularz rejestracyjny i wyrazili zgodę na przetwarzanie danych osobowych (zgodnie z ustawą z dn. 29.08.97 r. o Ochronie danych Osobowych Dz. Ust. nr 133 poz. 883) będą mieli możliwość dostosowania zawartości newslettera poprzez wybór informacji według wybranych przez subskrybenta kryteriów.System musi posiadać możliwość przesyłania za pośrednictwem poczty elektronicznej powiadomień o nowościach w serwisie oraz newsletterów.Powiadomienia i newslettery muszą być tworzone w oparciu o predefiniowane szablony umożliwiające wysyłanie wiadomości tekstowych lub w formacie HTML.CMS musi umożliwiać:

a) stosowanie wielu szablonów dla różnych zdefiniowanych wersji powiadomień i newslettera

b) automatyczne generowanie listy zawierającej informacje o nowych artykułach z opcją wyłączenia niektórych artykułów z listy przed wysłaniem newslettera

c) konfigurowanie mechanizmu rozsyłania powiadomień, w tym adresu nadawcy, grupy subskrybentów, pory wysyłania, wysyłania na żądanie (ad hoc), wysyłania automatycznego

d) edycji treści newslettera przed wysłanieme) definiowania grup odbiorców

Zarejestrowani użytkownicy na podstawie podanego i zweryfikowanego w zadanym okresie czasu adresu e-mail będą mieli możliwość otrzymywania na podany adres e-mail powiadomienia dot. wybranych kategorii tematycznych serwisu oraz newsletterów.Po zweryfikowaniu adresu e-mail zarejestrowany użytkownik będzie mógł:- zrezygnować z subskrypcji- zmienić adres e-mail, na który przesyłane będą subskrybowane informacje (każdorazowa zmiana adresu e-mail będzie wymagała weryfikacji)- zmienić hasło- zmienić listę kategorii, z których chce otrzymywać powiadomieniaSystem musi posiadać funkcjonalność zarządzania bazą danych osób otrzymujących wiadomości e-mail, tzn.: dodawanie, usuwanie i modyfikację danych.System musi zapisywać historię wysyłanych powiadomień i newsletterów w postaci: odbiorcy, daty i treści.

RSS 2.0, Atom System musi umożliwiać tworzenie kanałów Strona 35 z 50


1.0

informacyjnych w formacie RSS i Atom dla dowolnie zdefiniowanych obszarów serwisu, np. kategorii.System musi pozwalać na nadanie nazwy kanału, określenie ilości treści oraz sposobu udostępniania (cała treść lub tytuł z nagłówkiem).System musi umożliwiać wyświetlenie statystyk wywołań dla poszczególnych kanałów umieszczonych w serwisie.System musi umożliwiać publikowanie informacji o dostępnych w serwisu kanałach informacyjnych, jak np. na oficjalnej stronie miasta Poznania (http://www.poznan.pl/mim/public/feeds/index.html) oraz subskry-bowanie kanałów RSS z wszystkimi wiadomościami lub ograniczonymi do wybranego działu.

Forum dyskusyjne

Musi istnieć możliwość uruchamiania forów dyskusyjnych w ramach serwisów tworzonych w systemie.System musi umożliwiać określenie zasad korzystania z forum (anonimowe lub tylko dla zalogowanych użytkowników).System musi pozwalać na przypisywanie moderatorów treści do wybranych forów.CMS musi pozwalać na umieszczanie odnośników do poszczególnych wątków z forum na podstronach serwisu.

Oceny

System musi umożliwiać uruchamianie opcji oceny w ramach serwisów tworzonych w systemie i wybranych artykułów.System musi umożliwiać określenie zasad korzystania z ocen (anonimowe lub tylko dla zalogowanych użytkowników).System musi pozwalać na wystawienie oceny w skali od 1 do 5. Mechanizm tworzenia ocen musi umożliwiać co najmniej:- publikację listy ocenianych artykułów wraz z uzyskanymi przez nie średnimi ocenami oraz informacją o liczbie oceniających dany artykuł,- sortowanie listy ocenianych artykułów według takich kryteriów jak uzyskany średni wynik, liczba oceniających i czas który upłynął od momentu opublikowania ocenianego artykułu mierzony w godzinach,- eksport wyników oceny do formatu XML lub CSV,- wydruk wyników oceny.System musi rozpoznawać użytkowników i posiadać mechanizm blokujący wielokrotny udział użytkownika w ocenie tego samego artykułu.

Zabezpieczenie systemu

System musi uniemożliwiać dostęp do funkcji i zgromadzonych w nim danych z pominięciem mechanizmów bezpieczeństwa.

System musi być odporny na znane techniki ataku i Strona 36 z 50

http://www.poznan.pl/mim/public/feeds/index.html


włamań, w tym w szczególności podatnościami z aktualnej listy Top 10 wg organizacji OWASP, znajdującymi się w specyfikacji The OWASP Top 10 - 2013: A1 Injection A2 Broken Authentication and Session

Management A3 Cross-Site Scripting (XSS) A4 Insecure Direct Object References A5 Security Misconfiguration A6 Sensitive Data Exposure A7 Missing Function Level Access Control A8 Cross-Site Request Forgery (CSRF) A9 Using Components with Known

Vulnerabilities A10 Unvalidated Redirects and Forwards

W przypadku pojawienia się nowych nie znanych wcześniej technik włamań, Wykonawca jest zobowiązany do ich analizy ora dostarczenia niezbędnych poprawek i uaktualnień eliminujących podatności dostarczonego CMS w ramach świadczonej pomocy technicznej.System musi filtrować i walidować wszystkie dane wejściowe (np. z formularzy) w celu zminimalizowania ryzyka naruszenia integralności systemu bądź danych.

Warstwa kodowa strony internetowej WRPO 2014-2020 oraz systemu zarządzania treścią muszą być jawne i dostarczone w takiej postaci, aby Zamawiający mógł w pełni prześledzić ich działanie, w związku z czym zabronione jest korzystanie z mechanizmów szyfrujących typu ioncube.

Bezpieczny dostęp

Wykonawca pokryje koszty zakupu i przedłużenia ważności certyfikatu bezpieczeństwa w całym okresie obowiązywania umowy. Właścicielem certyfikatu bezpieczeństwa będzie Zamawiający.Dostęp do systemu musi odbywać się za pomocą bezpiecznego połączenia SSL z kluczem o długości co najmniej 128 bitów dla wszystkich administratorów i redaktorów serwisu.Administrator musi mieć możliwość włączenia (z poziomu panelu administracyjnego) bezpiecznego połączenia SSL dla określonych działów i artykułów w serwisie.System musi umożliwiać tworzenie i zmianę reguł dotyczących długości oraz stopnia skomplikowania haseł przechowywanych w bazie danych systemu, a także umożliwiać określenie czasu, po którym konieczna będzie zmiana hasła.

Strona 37 z 50


Hasła użytkowników nie mogą być przechowywane w bazie systemu w postaci jawnej, lecz z wykorzystaniem bezpiecznej funkcji skrótu (np. SHA - Secure Hash Algorithm).System musi umożliwiać ustawienie przez administratora czasu bezczynności, po którym użytkownik zostanie wylogowany z systemu.System musi umożliwiać włączenie mechanizmu blokowania kilkukrotnego jednoczesnego logowania się tego samego użytkownika.System musi czasowo blokować konto przy wielokrotnej próbie zalogowania z niewłaściwym hasłem. Ilość prób musi być możliwa do ustalenia przez administratora, który musi mieć możliwość ręcznego odblokowania konta.

Backup

System musi umożliwiać automatyczne tworzenie kopii bezpieczeństwa wszystkich elementów składających się na serwis (baza danych, aplikacje, pliki) z częstotliwością określoną przez administratora.System musi dawać możliwość ustalenia przez administratora miejsca przechowywania kopii bezpieczeństwa, w tym na innych serwerach.

e-BOK Do celów realizacji obsługi serwisu WRPO Wykonawca uruchomi elektroniczne Biuro Obsługi Klienta (e-BOK), za pośrednictwem którego uprawnieni przedstawiciele Zamawiającego będą mogli przesyłać zlecenia, nadawać im priorytet oraz dołączać do zleceń dodatkowe komentarze i załączniki w postaci plików o różnych formatach.Uprawnieni przedstawiciele Wykonawcy za pośrednictwem e-BOK będą potwierdzali przyjęcie zgłoszenia, nadawali im status realizacji oraz dołączali do zleceń dodatkowe komentarze i załączniki w postaci plików o różnych formatach.Za pośrednictwem e-BOK, Wykonawca będzie przekazywać Zamawiającemu zbiorczy wykaz wszystkich wykonanych, wykonywanych oraz zleconych prac w zakresie obsługi administracyjnej, technicznej i redakcyjnej, w tym niezbędnych prac związanych z bezpieczeństwem serwera, serwisu WRPO, baz danych i danych osobowych. Wykaz prac będzie aktualizował się po każdym zakończeniu realizacji zlecenia od Zamawiającego lub wykonaniu niezbędnych prac zakresie obsługi administracyjnej i technicznej.e-Bok musi dla celów informacyjnych i raportowania umożliwiać eksport wykazu prac do formatu CSV i XLS.Dane dot. liczby godzin zrealizowanych prac w zakresie

Strona 38 z 50


obsługi administracyjnej, technicznej i redakcyjnej będą prezentowane w układzie podsumowującym wybrany: dzień, tydzień, miesiąc, kwartał, rok lub zdefiniowany przedział czasowy i będą miały postać wykresów słupkowych z podaniem wartości liczbowej prezentowanej na wykresie oraz w formie tabelarycznej.

Szkolenia

Serwis musi umożliwiać obsługę szkoleń dla Beneficjentów WRPO i posiadać następujące funkcjonalności:

a) rejestracja nowego użytkownika (walidacja adresu e-mail),

b) ustawienie hasła do profilu użytkownika,c) wybór szkolenia z listy rozwijanej (możliwość

wyboru wielu spośród dostępnych szkoleń),d) dostępność miejsc na wybranym szkoleniu (w

zależności od sali),e) nabór na listę podstawową i rezerwową

(Administrator),f) potwierdzenie przyjęcia zgłoszenia na szkolenie (e-

mail do wybranych uczestników lub grupy uczestników),

g) wydruk biletu z danymi uczestnika oraz dot. szkolenia (format PDF),

h) powiadomienie organizatora o przesłaniu nowego zgłoszenia na szkolenie,

i) wydruk listy wszystkich uczestników szkolenia (Administrator),

j) eksport listy wszystkich uczestników szkolenia do formatu CSV i XLS(Administrator),

k) wysłanie i wyświetlenie komunikatu o zakończeniu naboru (Administrator),

Zadanie 3 – Przygotowanie i przekazanie Zamawiającemu Projektu Koncepcyjnego, Projektu Wykonawczego, Dokumentacji Powykonawczej oraz Instrukcji Użytkowania serwisu WRPO

Cel Zadania 3Celem zadania 3 jest opracowanie i dostarczenie Projektu Koncepcyjnego, Projektu Wykonawczego, Dokumentacji Powykonawczej oraz Instrukcji Użytkowania serwisu WRPO.

Projekt Koncepcyjny - opracowanie i stworzenie dokumentacji zawierającej podstawowe funkcjonalności, zgodnie z SIWZ, SOPZ, umową i załącznikami do umowy, zapewniający operacyjność i efektywność narzędzia informatycznego.

Projekt Wykonawczy - opracowanie i stworzenie technicznego projektu Strona 39 z 50


infrastruktury informatycznej zgodnie z SIWZ, SOPZ, umową i załącznikami do umowy, zapewniającego maksymalną funkcjonalność, operacyjność i efektywność narzędzia informatycznego.

Dokumentacja Powykonawcza - opracowanie i stworzenie dokumentacji technicznej zawierającej wszelkie informacje pozwalające na samodzielne korzystanie i dokonywanie dalszych zmian narzędzia informatycznego oraz dokumentacji dotyczącej obsługi dla narzędzia informatycznego umożliwiającej jego prawidłowe użytkowanie (w szczególności Instrukcji Użytkowania).

Instrukcja Użytkowania serwisu WRPO będzie zawierać: 1. szczegółowe instrukcje dot. systemu zarządzania treścią (CMS) dla

wszystkich kategorii użytkowników serwisu, zawierające opis wszystkich dostępnych funkcji systemu CMS i jego możliwości oraz przewodniki w formie „how-to” w postaci pytań dot. realizacji określonych operacji i szczegółowych odpowiedzi na pytania zawierających zrzuty ekranu,

2. opis funkcjonalności serwisu wraz z instrukcją obsługi modułów, takich jak w szczególności:

a) mapa dotacji, b) licznik dotacji, c) wyszukiwarka dotacji (w serwisie rekomendowanym przez

Ministerstwo Infrastruktury i Rozwoju),d) system obsługi szkoleń.

Oczekiwane rezultaty realizacji Zadania 3

Wykonawca w ramach wynagrodzenia, o którym mowa w umowie, przeniesie na Zamawiającego całość przysługujących mu praw majątkowych do Projektu Koncepcyjnego, Projektu Wykonawczego, do Dokumentacji Powykonawczej, Instrukcji Użytkowania zwanych dalej łącznie Utworami w rozumieniu Ustawy o prawie autorskim i prawach pokrewnych jakie powstaną w wyniku wykonywania niniejszej umowy. W zakresie, w jakim rezultatem wykonania Umowy w powyższym zakresie nie będą Utwory, należy stosować wprost przepisy Kodeksu Cywilnego o Umowie o dzieło. W takiej sytuacji poniższe postanowienia należy stosować odpowiednio, a w miejsce przeniesienia autorskich praw majątkowych nastąpi bezwarunkowe przeniesienie własności dzieła.

System musi być wyposażony w dostępną z poziomu administracyjnego dokumentację on-line w postaci Instrukcji Użytkowania z możliwością jej przeszukiwania.

Zakres informacji zawartych w Instrukcji Użytkowania może podlegać aktualizacji w trakcie prac wdrożeniowych. Każda zmiana funkcjonalności serwisu, odnotowana w rejestrze zmian, musi zostać zatwierdzona przez Zamawiającego.

Strona 40 z 50


Dokumentacja zostanie dostarczona w wersji elektronicznej w postaci plików w formacie Adobe™ PDF bez zabezpieczeń z możliwością wyszukiwania na nośniku danych (płyta DVD) oraz w postaci wydruku w 3 egzemplarzach z prawem do tworzenia dowolnej ilości kopii tej dokumentacji na użytek Zamawiającego.

Termin realizacji Zadania 3: odbiór częściowy dokumentacji testowej wersji systemu CMS, mapy i

licznika dotacji oraz systemu organizacji szkoleń: do 10 tygodni od daty podpisania umowy, (tylko wersja elektroniczna)

odbiór końcowy dokumentacji systemu CMS, mapy i licznika dotacji oraz systemu rejestracji uczestników szkoleń: do 30 listopada 2014r. (wersja elektroniczna i wydruk).

Zadanie 4 – Szkolenie dla administratorów i redaktorów serwisu WRPO

Cel Zadania 4Celem zadania 4 jest przeprowadzenie szkoleń dedykowanych dla użytkowników serwisu i systemu CMS: administratorów i redaktorów.

Oczekiwane rezultaty realizacji Zadania 4W ramach wdrożenia, Wykonawca przeprowadzi szkolenia dla administratorów i redaktorów wdrażanego systemu zarządzania treścią, a także szkolenia dot. funkcjonalności mapy, licznika, wyszukiwarki dotacji i systemu organizacji szkoleń.

Szkolenia dla poszczególnych kategorii użytkowników serwisu i systemu CMS podlegają odbiorowi końcowemu.

Szkolenia zostaną przeprowadzone w siedzibie Zamawiającego lub w uzgodnionych wcześniej z Zamawiającym lokalizacjach i terminach.

Miejsce, program szkolenia, czas realizacji oraz listę uczestników szkolenia Wykonawca ustali w porozumieniu z Zamawiającym. Szkolenia odbędą się w godzinach pracy Zamawiającego, tj. 8:00-15:00 lub w innych godzinach uzgodnionych z Zamawiającym.

Przed rozpoczęciem szkoleń, w terminie min. 7 dni, Wykonawca przedstawi Zamawiającemu do akceptacji zakres szkoleń i materiały przekazujące wiedzę ze szkolenia oraz metody szkoleniowe dla poszczególnych grup użytkowników.

Wykonawca określi niezbędny wymiar szkoleń dla poszczególnych grup użytkowników, przy czym:

maksymalna liczba uczestników szkolenia dla grupy administratorów wyniesie 10 osób, przy czym efektywny czas trwania szkolenia wyniesie łącznie 10 godzin (2 dni x 5 godzin zegarowych), przy założeniu, że czas przerw nie jest wliczany w czas szkolenia,

Strona 41 z 50


maksymalna liczba uczestników szkolenia dla grupy redaktorów wyniesie 40 osób (4 x 10 osób), przy czym minimalny efektywny czas trwania szkolenia wyniesie łącznie 10 godzin (2 dni x 5 godzin zegarowych), przy założeniu, że czas przerw nie jest wliczany w czas szkolenia.

Po każdym zakończonym szkoleniu zostanie przygotowane sprawozdanie zawierające listę obecnych osób, omawiane zagadnienia oraz wnioski zgłaszane przez uczestników szkolenia.

Uczestnicy szkoleń otrzymają certyfikaty uczestnictwa w szkoleniu zawierające, co najmniej następujące informacje:

data i miejsce prowadzenia szkolenia, imię i nazwisko trenera/ów prowadzących szkolenie, wymiar szkolenia (ilość godzin), szczegółowy zakres tematyczny szkolenia.

Wykonawca jest odpowiedzialny za zorganizowanie szkolenia - ponosi koszty ich organizacji tj.:

wynajem sali szkoleniowej, wynajem sprzętu komputerowego oraz audio-wideo, materiały informacyjne i szkoleniowe, zakwaterowanie trenerów.

Termin realizacji Zadania 4: odbiór końcowy: do 30 listopada 2014r.

Zadanie 5 – Serwis, doskonalenie, usługi gwarancyjne i hosting serwisu WRPO

Cel Zadania 5Celem zadania 5 jest realizacja bieżącej obsługi serwisu WRPO obejmującej w skali roku kalendarzowego co najmniej:

obsługę administracyjną serwisu, obsługę techniczną serwisu, obsługę redakcyjną serwisu.

Obsługa administracyjna serwisu obejmuje co najmniej:- usługę backupu w formie codziennych pełnych kopii bezpieczeństwa,- instalowanie poprawek zwiększających bezpieczeństwo serwera, serwisu i systemu CMS,- wykonywanie audytów bezpieczeństwa (co najmniej 1 raz w roku kalendarzowym na poziomie 2 OWASP ASVS oraz co najmniej 1 raz na 6 miesięcy na poziomie 1 OWASP ASVS),- usuwanie wszystkich błędów zgłoszonych przez Zamawiającego lub zidentyfikowanych przez Wykonawcę (w ramach gwarancji),

Strona 42 z 50


- wykonywanie testów wydajnościowych (co najmniej 4 razy w roku kalendarzowym),- zakładanie kont użytkowników,- tworzenie baz danych,- nadawanie uprawnień użytkownikom.

Podczas wykonywania audytów bezpieczeństwa aplikacji internetowej w postaci serwisu WRPO 2014-2020 wraz z systemem zarządzania treścią (CMS), mapą i licznikiem dotacji oraz systemem organizacji szkoleń, Wykonawca powinien posługiwać się metodyką wykorzystującą testy bezpieczeństwa OWASP ASVS.

Wykonawca zobowiązany jest do tego, aby testy bezpieczeństwa, zarówno przed odbiorem częściowym jak i końcowym, były wykonane co najmniej na poziomie 2 OWASP ASVS. (https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project; lista narzędzi: https://www.owasp.org/index.php/Appendix_A:_Testing_Tools).

Testy bezpieczeństwa muszą zostać szczegółowo udokumentowane i przekazane Zamawiającemu w terminie 7 dni kalendarzowych od daty ich przeprowadzenia. Czas wymagany na przeprowadzenie testów OWASP ASVS na poziomach 1 i 2 musi zostać uwzględniony przez Wykonawcę w harmonogramie realizacji zadań.

Wykonawca jest zobowiązany do umożliwienia Zamawiającemu lub podmiotom przez niego upoważnionym do dokonania audytu systemu pod kątem bezpieczeństwa teleinformatycznego, zgodności przetwarzania i ochrony danych osobowych z ustawą o ochronie danych osobowych, zgodności z ustawą o świadczeniu usług drogą teleinformatyczną. Zawiadomienie o zamiarze przeprowadzenia audytu będzie przekazywane Wykonawcy co najmniej 5 dni kalendarzowych przed jego rozpoczęciem.

W ramach obsługi administracyjnej Wykonawca jest zobowiązany do świadczenia dodatkowych prac zleconych przez Zamawiającego w wymiarze:

• w roku 2015 – 20 godzin rocznie,• w roku 2016 – 10 godzin rocznie,• w latach 2017 do 2023 – 5 godzin rocznie.

Zagrożenia i błędy zgłaszane będą poprzez system zgłaszania błędów (e-BOK) zapewniony przez Wykonawcę i umożliwiający przesyłanie załączników. Narzędzie to powinno umożliwiać obsługę zgłoszeń wraz z datą zgłoszenia, datą aktualizacji, konfigurowalnymi statusami, dodawanie opisu, tematu, komentarzy i załączników na zasadach podobnych do tego typu programów (np. www.mantisbt.org, www.bugzilla.org).

W zależności od kategorii zagrożeń (kategoria określona będzie w raporcie z audytu bezpieczeństwa), Wykonawca dokona poprawek odpowiednio:

wysokie – maksymalny czas na poprawę: 24h; Strona 43 z 50

http://www.bugzilla.org/

http://www.mantisbt.org/

https://www.owasp.org/index.php/Appendix_A:_Testing_Tools

https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project


średnie – maksymalny czas na poprawę: 48h; niskie – maksymalny czas na poprawę: 72h;

Zgłoszenie błędu będzie zawierać opis sytuacji, w której błąd się pojawił. Zamawiający będzie określał priorytet błędu (krytyczny, znaczący, błahy).

Wykonawca jest zobowiązany naprawić jakikolwiek błąd w systemie oraz przywrócić działanie systemu w ramach gwarancji bez prawa do dodatkowego wynagrodzenia z tego tytułu.

Wszystkie prace zlecone przez Zamawiającego w ramach obsługi administracyjnej wykonywane będą w terminie 3 dni roboczych od dnia otrzymania zlecenia.

Obsługa techniczna obejmuje: 1) usługi związane z wprowadzaniem modyfikacji w zakresie

funkcjonalności opisanych w niniejszej dokumentacji na etapie ich odbioru częściowego i końcowego,

2) usługi asysty technicznej związane z wprowadzaniem modyfikacji w zakresie nowych funkcjonalności, a także

3) aktualizację dokumentacji związanej z wprowadzonymi modyfikacjami w zakresie opisanych w niniejszej dokumentacji oraz nowych funkcjonalności.

Wykonawca ma obowiązek dokonywania poprawek dostarczonego systemu w oparciu o przedstawione przez Zamawiającego wyniki audytu pod kątem bezpieczeństwa teleinformatycznego w ramach obowiązującej gwarancji - w całym okresie trwania umowy.

Z tytułu wprowadzania poprawek Zamawiający nie będzie ponosił żadnych dodatkowych kosztów.

Wszystkie prace zlecone przez Zamawiającego w ramach obsługi technicznej związanej z usuwaniem wszystkich błędów, wprowadzaniem modyfikacji w zakresie funkcjonalności na etapie ich odbioru częściowego i końcowego, a także modyfikacje związanej z nimi dokumentacji zostaną wykonane w terminie od 1 do 5 dni roboczych od dnia otrzymania zlecenia .

Wszystkie prace zlecone przez Zamawiającego w ramach asysty technicznej związanej z wprowadzaniem modyfikacji w zakresie nowych funkcjonalności serwisu internetowego Wielkopolskiego Regionalnego Programu Operacyjnego na lata 2014-2020 (WRPO 2014-2020) wraz z systemem zarządzania treścią (CMS), funkcjonalności mapy i licznika dotacji, wyszukiwarki dotacji, systemu organizacji szkoleń oraz związanej z nimi dokumentacji, zostaną wykonane w terminie uzgodnionym z Zamawiającym, nie dłuższym niż 14 dni roboczych od dnia otrzymania zlecenia.

W ramach asysty technicznej Wykonawca jest zobowiązany do świadczenia dodatkowych prac zleconych przez Zamawiającego w wymiarze:

Strona 44 z 50



W sytuacji gdy Zamawiający wykorzysta wszystkie godziny pracy Wykonawcy w danym roku, może skorzystać z godzin przysługujących mu w latach następnych.

Zamawiający będzie dokonywał zgłoszeń za pośrednictwem systemu e-BOK ze szczegółowym opisem wymagań dot. nowych funkcjonalności. Następnie Wykonawca w ciągu 72 h będzie przedstawiał Projekt Koncepcyjny wraz ze szczegółowym kosztorysem, w tym liczbą godzin pracy potrzebną na wykonanie zlecenia. Po zatwierdzeniu kosztorysu przez Zamawiającego, Wykonawca rozpocznie realizację zlecenia. W przypadku, kiedy Zamawiający stwierdzi, iż Wykonawca wyliczył zbyt dużą liczbę godzin na realizację zlecenia, Zamawiający ma prawo powołać zewnętrznego eksperta, który wyliczy czasochłonność. Opinia zewnętrznego eksperta dot. czasochłonności zlecenia będzie obligatoryjna dla Wykonawcy.

Wykonawca jak i Zamawiający mają prawo do zorganizowania spotkania roboczego w sprawie nowych zleceń w ramach asysty technicznej w siedzibie Zamawiającego, celem omówienia zasad sporządzania kosztorysu zleceń zgłaszanych i zatwierdzanych w systemie e-BOK.

Obsługa redakcyjna obejmuje wszystkie usługi związane z aktualizacją informacji publikowanych w serwisie WRPO, w tym zawierających załączniki, fotografie oraz materiały multimedialne.

W ramach obsługi redakcyjnej Wykonawca jest zobowiązany do świadczenia dodatkowych prac zleconych przez Zamawiającego w wymiarze:


Wszystkie prace zlecone przez Zamawiającego w ramach obsługi redakcyjnej zostaną wykonane w terminie 1 dnia roboczego od dnia otrzymania zlecenia.

Obsługa serwisu w opisanym wyżej zakresie realizowana będzie w każdym roku kalendarzowym, tj. 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022 i 2023.

Do celów realizacji obsługi serwisu WRPO Wykonawca uruchomi elektroniczne Biuro Obsługi Klienta (e-BOK), za pośrednictwem którego uprawnieni przedstawiciele Zamawiającego będą mogli przesyłać zlecenia, nadawać im priorytet oraz dołączać do zleceń załączniki w postaci plików o różnych formatach.

Usługa hostingu serwera obejmuje co najmniej: dostępność serwisu WRPO 2014-2020 na poziomie nie niższym niż

Strona 45 z 50


99,8% w skali roku (potwierdzane szczegółowymi raportami comiesięcznymi) z zastrzeżeniem, że jednorazowa niedostępność serwisu nie może być dłuższa niż 4 godziny (Gwarancja Dostępności Usług),

nielimitowana powierzchnia dyskowa, nielimitowany transfer danych, nielimitowana liczba użytkowników, nielimitowana liczba kont e-mail, nielimitowana liczba baz danych.

Wykonawca zobowiązany jest świadczyć usługi hostingowe z zapewnieniem dostępu do co najmniej 2 serwerów: jednego udostępniającego wersję testową i jednego udostępniającego wersję produkcyjną. Dopuszcza się korzystanie z dedykowanych maszyn wirtualnych (VPS).

Gwarancja obejmuje naprawę błędów klasyfikowanych jako: 1) błąd krytyczny - błąd uniemożliwiający korzystanie z serwisu WRPO i

systemu CMS oraz systemu organizacji szkoleń: Czas reakcji na zgłoszenie = 15 minutCzas naprawy = 4 godziny

2) błąd znaczący - błąd negatywnie wpływający na wydajność i funkcjonalność Systemu, ale nie uniemożliwiający korzystania z serwisu WRPO i systemu CMS oraz mapy i licznika dotacji oraz systemu organizacji szkoleń:Czas reakcji na zgłoszenie = 30 minutCzas naprawy = 24 godziny

3) błąd błahy – błąd nie wpływający na funkcjonalność i wydajność Systemu, jednak mogący powodować trudne do zdiagnozowania problemy bądź skutkujący pogorszeniem komfortu korzystania z serwisu WRPO 2014-2020.Czas reakcji na zgłoszenie = 1 godzinaCzas naprawy = 48 godzin

Czas naprawy liczony zostaje od momentu zgłoszenia przez Zamawiającego. Administrator, który zgłosił błąd, otrzymuje powiadomienie mailem o zmianach statusu zgłoszenia na adres e-mail. Uwaga: Powyższe opisy kategorii błędów mają charakter poglądowy. Zawsze to Zamawiający określa kategorię błędu, gdyż w zależności od towarzyszących okoliczności mogą wystąpić sytuacje, gdzie np. błąd „błahy” lub „znaczący” może zostać zakwalifikowany jako „krytyczny” (na przykład podczas trwania naboru wniosków o dofinansowanie).

W ramach świadczonych usług serwisowych, Wykonawca zapewnienia 99% odpowiedzi systemu dla standardowych akcji nawigacyjnych w interfejsie użytkownika (wejście do menu, rozwinięcie gałęzi drzewa, podgląd szczegółów itp.) w czasie maksymalnie 2 sekund, a dla pozostałych - 5 sekund (testowane z dowolnej lokalizacji w Polsce; pojedynczy test to co najmniej 100 zapytań wykonywanych w dowolnym czasie; test ma na celu sprawdzenie spełnienia opisanych wymagań wydajnościowych systemu; dopuszczalne jest stosowanie

Strona 46 z 50


zautomatyzowanych skryptów testujących i/lub symulujących założone obciążenie systemu).

W przypadku konieczności oczekiwania przez użytkownika na pobranie lub wyświetlenie dowolnych danych system poinformuje o tym fakcie wyświetlając animowaną ikonę ładowania (np. klepsydra, koło etc.).

Gwarancja Dostępności Usług, które muszą być jednorazowo poświadczone stosownym dokumentem wystawionym przez Wykonawcę zapewnia:1. Maksymalny czas przestoju na rok to 12 godzin (wyłączając czas

zaplanowanych działań serwisowych).2. Maksymalny czas przywrócenia systemu do działania po awarii to 1

godzina. 3. Czas reakcji na zgłoszenie (podjęcia realnych działań mających na celu

zdiagnozowanie oraz usunięcie awarii) nie może przekroczyć 15 minut.4. W przypadku zaplanowanych przerw technicznych Zleceniodawca musi

zostać powiadomiony nie później niż na 24 godziny przed planowanym przestojem.

5. Użytkownicy muszą zostać powiadomieni o przerwie technicznej stosownym komunikatem, wyświetlanym zamiast niedostępnej części systemu lub strony internetowej, a jeżeli czynności serwisowe dotyczą całego systemu - zamiast strony głównej – układ graficzny jak i treść komunikatu ma możliwość zdefiniować w systemie Administrator.

6. Działania serwisowe wymagające zatrzymania działania usługi (np. instalacja nowych wersji sprzętu i oprogramowania) prowadzone muszą być w ramach okienek serwisowych, kiedy działanie usługi nie jest niezbędne (tzn. w nocy pomiędzy godziną 2:00 a 5:00).

Wykonawca zobowiązany jest do zapewnienia ochrony przed włamaniami i nieautoryzowanym wypływem danych na zewnątrz poprzez:

1. regularne aktualizacje (ze szczególnym naciskiem na aktualizacje krytyczne) systemu,

2. zapewnienie bezpiecznego dostępu do powłoki z sieci zewnętrznych, 3. ograniczenie dostępu do powłoki systemu do autoryzowanych osób

zarówno po stronie Wykonawcy jak i Zleceniodawcy (Wykonawca jest zobowiązany przekazać listę osób mających taki dostęp Zleceniodawcy),

4. bezpieczne przechowywanie loginów oraz haseł dostępu, 5. kontrolę dostępu do pomieszczeń z fizycznymi serwerami na których

ulokowane są maszyny wirtualne oraz do pomieszczeń z kopiami zapasowymi danych,

6. zapewnienie bezpiecznego połączenia z systemem poprzez protokół HTTPS (certyfikat kwalifikowany zabezpieczający połączenie HTTPS zapewnia Wykonawca).

7. Redundantny system ścian ogniowych (firewalli) całego centrum przetwarzania danych Wykonawcy. Firewalle muszą kontrolować cały ruch wchodzący i wychodzący z Centrum, przepuszczając wyłącznie pakiety niezbędne dla prawidłowego działania serwisów, chroniąc dostęp do bazy danych z zewnątrz.

Strona 47 z 50


Zabezpieczenia przechowywanych danych muszą spełniać warunki jak dla baz instytucjonalnych z danymi osobowym.

Zapewnienie zabezpieczenia przed spybootami i spamem poprzez:1. za pomocą testu CAPTCHA (reCAPTCHA, keyCAPTCHA) bądź prostych

pytań kontrolnych np.: Przepisz wyraz określający zwierzę (kot) (woda)?,2. blokowanie numerów IP hostów wysyłających spam z wykorzystaniem

powszechnie dostępnych list (zawierających numery IP spamerów),3. uaktualnianie listy blokowanych numerów IP,4. możliwość ręcznego dopisania niepożądanych adresów IP do listy

blokowanych,5. konieczność potwierdzenia czynności wykonywanych przez użytkownika,

wysyłanego mailem (aktywacja konta, zmiana danych osobowych, numeru telefonu, e-maila, itp.)

Wykonawca zapewnia integralność danych w bazie poprzez:1. integralność encji - każda tabela musi mieć klucz główny o wartościach

unikatowych i nie będących NULL (UNIQUE, NOT NULL),2. integralność referencyjną (odwołań),3. stosowanie wyzwalaczy (ang. triggerów) - sprawdzenie logicznych relacji

między tabelami: * uruchamiane przed lub po modyfikacji pola tabeli (ang. update

trigger),* uruchamiane przed lub po wstawieniu nowego wiersza do tabeli (ang.

insert trigger), * uruchamiane przed lub po usunięciu wiersza z tabeli (ang. delete

trigger).

Wykonawca ma obowiązek stałego (24/7/365) monitorowania infrastruktury teleinformatycznej wykorzystywanej przez system. Wykonawca udostępni upoważnionym przez Zamawiającego osobom dostęp poprzez sieć Internet do następujących statystyk pracy systemu:

Serwery fizyczne (jeśli dotyczy)1. wykorzystanie CPU w procentach2. wykorzystanie RAM w procentach3. transfer danych przez interfejsy sieciowe 4. zajętość przestrzeni dyskowej w procentach

Serwery wirtualne1. wykorzystanie CPU w procentach2. wykorzystanie RAM w procentach3. wykorzystanie przestrzeni dyskowej SWAP w MB4. zajętość przestrzeni dyskowej w procentach5. transfer danych przez interfejsy sieciowe serwerów wirtualnych

Łącza1. wysycenie w procentach łącz dostępu do Internetu

Strona 48 z 50


2. wysycenie w procentach łącza pomiędzy Centrum Przetwarzania Danych a siedzibą Zamawiającego

Statystyki muszą być prezentowane w formie odpowiednich wykresów. Okres próbkowania wartości parametrów Systemu nie może być dłuższy niż 90 sek., zaś okres odświeżania danych nie może być dłuższy niż 300 sek. Zamawiający musi posiadać możliwość przeglądania historycznych statystyk pracy Systemu w okresie nie mniejszym niż 180 dni.

Wykonawca w terminie 7 dni roboczych od dnia podpisania umowy przekaże Zamawiającemu instrukcję dostępu przez sieć internet do statystyk pracy Systemu.

Wykonawca ma obowiązek prowadzenia monitoringu integralności plików na serwerach wirtualnych (ang. File Integrity Monitoring). Zdarzenia związane z utratą integralności plików muszą być odnotowywane w dzienniku pracy Systemu z podaniem:

1. daty i godziny stwierdzenia braku integralności2. imienia i nazwiska operatora stwierdzającego brak integralności plików3. opisem zakresu zdarzenia

Wykonawca będzie przekazywał Zamawiającemu raporty ze statystyk pracy systemu, w tym tabelaryczne zestawienie okresów niedostępności systemu.

Administrator uzyska dostęp do statystyk logowań wszystkich użytkowników, umożliwiające m.in. ocenę zasadności protestów użytkowników z powodu braku możliwości złożenia wniosku o dofinansowanie z przyczyn technicznych.

Wykonawca zapewni wykonywanie dziennych przyrostowych oraz pełnych tygodniowych kopii zapasowych bazy danych i systemu oraz tygodniowej kopii zapasowej wirtualnych maszyn.

Kopia zapasowa musi być przechowywana, na co najmniej dwóch niezależnych nośnikach zlokalizowanych w różnych budynkach, zapewniających bezpieczeństwo danych w przypadku katastrof żywiołowych: pożaru, powodzi, trzęsienia ziemi oraz innych niewymienionych.

Proces tworzenia dziennych przyrostowych jak i tygodniowych pełnych kopii zapasowych musi być zautomatyzowany z powiadomieniami w przypadku niepowodzenia akcji backupu.

Zamawiający zastrzega sobie prawo do możliwości odtworzenia dowolnie wskazanej przez niego kopii na serwerze zapasowym w terminie ustalonym z Wykonawcą. Odtworzeni kopii, w ramach obsługi administracyjnej, będzie wykonywał Wykonawca na żądanie Zamawiającego nie rzadziej niż 1 raz w roku.

Strona 49 z 50


Terminy wykonywania kopii zapasowych muszą być uzależnione od obciążenia serwera i wykonywane w czasie najmniejszej aktywności użytkowników.

Oczekiwane rezultaty realizacji Zadania 5Wykonawca przygotuje i przekaże Zamawiającemu na formularzu ofertowym (Załącznik nr 2 do SIWZ), kosztorys obejmujący miesięczny abonament na obsługę administracyjną, techniczną i redakcyjną świadczone w okresie od daty zakończenia realizacji zadania 5 do dnia 31.12.2023 r.

Poprzez elektroniczne Biuro Obsługi Klienta (e-BOK), Wykonawca będzie na bieżąco raportować Zamawiającemu zbiorczy wykaz wszystkich wykonanych, wykonywanych oraz zleconych prac w zakresie obsługi administracyjnej, technicznej i redakcyjnej, w tym niezbędnych prac związanych z bezpieczeństwem serwera, serwisu WRPO, baz danych i danych osobowych, za które Wykonawca będzie ponosić odpowiedzialność na mocy podpisanej umowy z Zamawiającym.

Po przyjęciu raportu przez Zamawiającego i dokonaniu kwartalnych odbiorów częściowych, Wykonawca wystawi w terminie do 15 grudnia roku 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022 i 2023 fakturę VAT na kwotę ustalonego abonamentu.

W przypadku konieczności wykonania prac nie przewidzianych przez obie strony w momencie zawierania umowy, np. związanych ze zmianami prawa lub bezpieczeństwem danych, Zamawiający podpisze Aneks do umowy z Wykonawcą po uprzednim zaakceptowaniu kosztorysu dodatkowych prac niezbędnych do wykonania w zakresie obsługi administracyjnej, technicznej i redakcyjnej.

W okresie serwisowania może zaistnieć potrzeba dokonania dodatkowych szczegółowych uzgodnień lub wyjaśnień. Spotkania robocze odbywać się będą w siedzibie Zamawiającego w godzinach i dniach pracy Zamawiającego, po wcześniejszym uzgodnieniu terminu (minimum 2 dni robocze przed spotkaniem). Wszelkie decyzje i ustalenia ze spotkania będą dokumentowane protokołem ze spotkania. Zamawiający i Wykonawca będą porozumiewali się w języku polskim.

Termin realizacji Zadania 5: odbiór częściowy: na koniec każdego kwartału kalendarzowego do

31.12.2023 r. odbiór końcowy: do 31.12.2015 r., 31.12.2016 r., 31.12.2017 r.,

31.12.2018 r., 31.12.2019 r., 31.12.2020 r., 31.12.2021 r., 31.12.2022 r. i 31.12.2023 r.

Strona 50 z 50

Documents

Zakres zadań merytorycznych – opis przedmiotu zamówienia ...€¦ · Web viewZałącznik nr 1 do SIWZ. Szczegółowy opis przedmiotu zamówienia „Wykonanie serwisu internetowego