Załącznik nr 1 – Zakres Zadań Wykonawcy Założenia

Załącznik nr 1 – Zakres Zadań Wykonawcy
Założenia realizacji:
1.
Rozbudowie/aktualizacji podlega system CMS wykonany w wyniku realizacji następujących
zamówień publicznych:
a.
Zaprojektowanie, wykonanie i wdrożenie portalu wspierającego realizację działań 8.1
i 8.2 Programu Operacyjnego Innowacyjna Gospodarka (PO IG) z wykorzystaniem
systemu
zarządzania
treścią
stron
internetowych
CMS
(http://bip.parp.gov.pl/index/more/5700),
b.
Wykonanie
i
wdrożenie
platformy
promocyjnej
(http://bip.parp.gov.pl/index/more/15085).
2.
Rozbudowa zostanie zrealizowana w celu uzyskania wszystkich funkcjonalności określonych w
dokumencie „Projekt Architektury Informacji - Platforma Wspieramy e-Biznes - Web.gov.pl”
oraz prototypach html docelowego systemu CMS udostępnionych potencjalnym Wykonawcom
wraz z zapytaniem ofertowym.
3.
Rozbudowa/aktualizacja przeprowadzona zostanie zgodnie z dokumentami:
a.
Projekt Techniczny Systemu CMS i PP,
b.
Dokumentacja rozbudowy systemu,
udostępnionymi potencjalnym Wykonawcom.
4.
Zamawiający oczekuje od Wykonawcy szczególnej współpracy w zakresie jakości
i bezpieczeństwa kodu wytwarzanego podczas realizacji zamówienia.
5.
Wykonawca, prowadząc prace programistyczne, będzie zobowiązany stosować się do
minimalnych wymogów Zamawiającego:
a.
wykorzystywanie stabilnych, bezpiecznych, bezpłatnych i wspieranych framework’ów
programistycznych
b.
realizowanie funkcjonalności oprogramowania przede wszystkim za pomocą dostępnych,
bezpłatnych bibliotek,
c.
wykorzystywanie bibliotek stabilnych, bezpiecznych i aktualnych,
d.
niestosowanie polskich znaków diakrytycznych ani innych wykraczających poza standard
ASCII w kodzie aplikacji oraz strukturze bazy danych,
e.
stosowanie się do zaleceń wzorca projektowego MVC,
f.
stosowanie spójnej i przejrzystej struktury kodu, kategoryzowanie obiektów i szablonów,
g.
stosowanie zasady DRY (Don’t Repeat Yourself) – unikanie wykonywania tej samej
pracy w różnych miejscach systemu,
h.
stosowanie technik minimalizujących podatność na ataki typu SQL Injection, XSS,
Command Injection
i.
stosowanie komentarzy w kodzie aplikacji (współczynnik skomentowania kodu nie
mniejszy niż 10%), nie licząc wykomentowanych fragmentów kodu.
6.
Wykonawca zobowiązany jest do wykonywanie prac wdrożeniowych w oparciu o SVN
Zamawiającego.
Wykonawca zrealizuje przedsięwzięcie w dziesięciu kolejnych etapach:
Etap I - Analiza Potrzeb Zamawiającego
1.1.
W ramach realizacji zamówienia Wykonawca przeprowadzi Szczegółową Analizę Potrzeb
Użytkownika. Wymagania zapisane w niniejszym dokumencie powinny być traktowane jako
minimalne wymagania stawiane przed Systemem CMS. Ich zakres może być poszerzony po
analizie dokumentu „Projekt Architektury Informacji - Platforma Wspieramy e-Biznes str. 1
1.2.
1.3.
1.4.
Web.gov.pl” oraz udostępnionych prototypów html docelowego systemu CMS. Wykonawca
zidentyfikuje i usystematyzuje funkcjonalności opisane w ZZW oraz udostępnionych
dokumentach i przedstawione w prototypach oraz sprecyzuje potrzeby Zamawiającego
względem szczegółowych wymagań realizacji poszczególnych funkcjonalności Systemu CMS
(ZZW precyzuje jakie główne funkcje ma System CMS obsługiwać, analiza zidentyfikuje
i usystematyzuje oraz opisze szczegółowo kompletne funkcjonalności - odpowie na pytanie jak
to ma System CMS realizować) stanowiących przedmiot zamówienia. Wykonawca w ramach
etapu przy wykorzystaniu wywiadów indywidualnych lub grup fokusowych w celu
przeprowadzenia pełnej analizy wykorzysta dobre praktyki w tym zakresie oraz wybrane
techniki: persona, scenariusze i przypadki użycia, analiza kontekstu użytkowania, analiza zadań
użytkowników. Zamawiający będzie mógł wnosić wielokrotne uwagi do dokumentu Analizy.
Ostateczny dokument podlega akceptacji i odbiorowi przez Zamawiającego.
Wykonawca zobowiązany jest do przeanalizowania:
1.2.1. Wszystkich elementów i funkcjonalności określonych w dokumencie „Projekt
Architektury Informacji - Platforma Wspieramy e-Biznes - Web.gov.pl”.
1.2.2. Specyfikacji powiązań z LSI/Extranet określonej w dokumencie Usługi implementacji
procesów biznesowych Systemu LSI/Ekstranet dla działań 8.1 i 8.2 PO IG na platformie
EMC Documentum, wraz z usługami integracyjnymi - Projekt Systemu obejmujący Projekt Techniczny.
1.2.3. Księgi Wizualizacji stron internetowych Zamawiającego.
Wykonawca przeprowadzi spotkania analityczne z Zamawiającym mające na celu
uszczegółowienie potrzeb Zamawiającego.
Wynikiem Analizy będzie opracowanie Specyfikacji Funkcjonalnej Systemu z uwzględnieniem
aktualnych aktów prawnych, minimalnych wymagań dla Systemu informatycznych
Zamawiającego, innych normatywnych dokumentów Zamawiającego, zawierającą, co najmniej:
1.4.1. Definicje pojęć używanych w dokumentacji.
1.4.2. Szczegółową specyfikację wszystkich funkcjonalności Systemu.
1.4.3. Rozbudowaną o nowe funkcjonalności Architekturę logiczną Systemu, uwzględniającą
podział na moduły, ich wspólne zależności oraz szczegółowy opis grupowanych przez nie
funkcji oraz funkcjonalności oferowanej użytkownikowi.
1.4.4. Architekturę powiązań pomiędzy Systemem, a innymi częściami składowymi
(LSI/Extranet).
1.4.5. Zakres danych przechowywanych i udostępnianych przez System.
1.4.6. Logiczny model danych.
1.4.7. Opis interfejsu użytkownika.
1.4.8. Wyszczególnienie uprawnień do poszczególnych funkcji Systemu.
1.4.9. Role użytkowników Systemu oraz grupowane przez nie uprawnienia.
1.4.10. Wymagania wydajnościowe stawiane Systemowi.
1.4.11. Wymagania bezpieczeństwa wobec Systemu.
1.4.12. Zakres integracji rozbudowanego Systemu z zewnętrznymi bazami danych
i systemami informatycznymi.
1.4.13. Zakres i sposób importu i exportu danych przechowywanych w innych bazach
i systemach Zamawiającego do realizowanego Systemu.
1.4.14. Szczegółowe scenariusze testowe do wykorzystania przy testach akceptacyjnych.
str. 2
Etap II – Zaktualizowanie techniczne kodu funkcjonalności odpowiadających za integrację
i komunikację z systemem LSI/Extranet
Aktualizacja funkcjonalności powiązań z LSI/Extranet wykonana zostanie na udostępnionym przez
Zamawiającego Systemie Deweloperskim będącym kopią Systemu Produkcyjnego. Aktualizacja
zostanie zrealizowana w oparciu o zaakceptowany przez Zamawiającego dokument będący produktem
Etapu I - Analiza Potrzeb Użytkownika. Przed aktualizacją należy wykonać zadanie określone w pkt.
3.22 zmiana modułu logowania do systemu.
2.1. Wdrożenie i skonfigurowanie funkcjonalności umożliwiających współpracę Systemu
z Extranetem przez co najmniej realizację funkcji:
2.1.1. Zakładanie konta na podstawie danych z Ekstranetu.
2.1.2. Zakładanie konta w Ekstranecie.
2.1.3. Kasowanie konta i resetowanie hasła w CMS na podstawie zmiany w Ekstranecie.
2.1.4. Inne funkcje integracji i komunikacji określone podczas Analizy Potrzeb Użytkownika.
2.2. Rozszerzenie modelu danych użytkownika systemu, tak by przechowywał login (nie tylko
email) użytkownika. Login jest wymagany w procesie logowania do systemu LSI/Ekstranet.
2.3. Zabezpieczenie wszystkich funkcjonalności do zakładania kont i zmiany haseł wykorzystując
basic authentication i protokół https.
2.4. Szczegółowa specyfikacja powiązań z LSI/Extranet zostanie udostępniona Wykonawcy po
podpisaniu Umowy.
Etap III – Aktualizacja istniejących funkcjonalności Systemu
Rozbudowa istniejących funkcjonalności Systemu wykonana zostanie na udostępnionym przez
Zamawiającego Systemie Deweloperskim będącym kopią Systemu Produkcyjnego. Rozbudowa
zostanie zrealizowana w celu uzyskania funkcjonalności określonych w dokumencie „Projekt
Architektury Informacji - Platforma Wspieramy e-Biznes - Web.gov.pl” oraz udostępnionych
prototypach html docelowego systemu. Aktualizacja zrealizowana zostanie po uprzednim
przeprowadzeniu Analizy Potrzeb Użytkownika i ich wynikach zawartych w zaakceptowanym przez
Zamawiającego dokument będący produktem Etapu I - Analiza Potrzeb Użytkownika.
3.1. Aktualizacja struktury Systemu zgodnie z wytycznymi określonymi w dokumencie „Projekt
Architektury Informacji - Platforma Wspieramy e-Biznes - Web.gov.pl” oraz udostępnionych
prototypach html docelowego systemu.
3.2. Aktualizacja istniejących funkcjonalności Systemu.
3.2.1. Zintegrowanie funkcjonalności Baza Wiedzy i Platforma Promocyjna / Bazy Wiedzy.
3.2.2. Aktualizacja funkcjonalności Baza wiedzy:
3.2.2.1. Dodanie elementu wyszukiwania (filtrowania) rekordów.
3.2.2.2. Dodanie funkcjonalności „Exportuj rekordy”. Funkcjonalność uwzględniać
będzie listę będącą wynikiem aktualnie ustawionego filtra.
3.2.2.3. Upoważniony użytkownik (określony w ACL), z poziomu każdej z baz ma
możliwość uruchomienia funkcjonalności „Exportuj rekordy”
3.2.2.4. Użytkownik wybiera podczas wykonywania exportu docelowy format pliku
do którego eksportowane są rekordy bazy tj. co najmniej CSV z możliwością
określenia znaku rozdzielania danych.
3.2.2.5. Dodanie kolumn informacji o dacie dodania i opublikowania rekordu.
str. 3
3.3.
3.4.
3.5.
3.6.
3.7.
3.2.2.6. Dodanie funkcjonalności tworzenia podkategorii w każdej z Baz Wiedzy
przez uprawnionego użytkownika (określonego w ACL).
3.2.2.7. Dodanie funkcjonalności umożliwiającej przenoszenie wybranego rekordu
pomiędzy kategoriami danej bazy przez uprawnionego użytkownika (określony w
ACL).
3.2.2.8. Dodanie opcji umożliwiającej oznaczenie wskazanej kategorii jako ukrytej.
3.2.2.9. Rekordy w kategorii ukrytej są dostępne do edycji przez właściciela rekordu.
Aktualizacja funkcjonalności Eksport użytkowników poprzez:
3.3.1. Dodanie funkcji eksportu użytkowników umożliwiającej
3.3.1.1. Wybór listy użytkowników do eksportu
3.3.1.2. Wybór poszczególnych użytkowników
3.3.1.3. Eksport do formatu pliku co najmniej CSV z możliwością określenia znaku
rozdzielania danych.
Aktualizacja funkcjonalności Robots.txt
3.4.1. Umożliwienie edycji pliku (http://www.web.gov.pl/robots.txt), dla uprawnionego
użytkownika (określonego w ACL).
Aktualizacja funkcjonalności: Poradnik (Artykuły i poradniki).
3.5.1. Możliwość przeniesienia przez uprawnionego użytkownika (określony w ACL),
wprowadzonego przez użytkownika społecznościowego, artykułu do dowolnego miejsca
struktury artykułów.
3.5.2. Dodanie nowego elementu, w formularzu dodawania artykułu – Moduł Poradnik,
umożliwiającego dodawanie załączników do treści.
3.5.3. Aktywowanie w CMS funkcjonalności umożliwiającej uprawnionemu użytkownikowi
(określony w ACL) administrowanie listą formatów oraz wielkości i wagi plików
możliwych do dodania przez użytkownika społecznościowego.
3.5.4. Aktywowanie wszystkich funkcjonalności odpowiadających artykułom, artykułowi
wprowadzonemu przez Moduł Poradnik (z wyjątkiem konfiguracji formularza dodawania
artykułu w Module Poradnik).
Aktualizacja funkcjonalności: obsługa Meta Tagów
3.6.1. Utworzenie we wszystkich szablonach stron Meta Tagu <link rel=”image_scr” (…)>.
3.6.2. Mata Tag w ciele HEAD szablonu winien być skonstruowany w oparciu o poniższy
schemat: <link rel=”image_scr” href=”bezwzględny_adres_miniatury” />.
3.6.3. Wartość zmiennej ”bezwzględny_adres_miniatury” będzie pobierana z określonych
przez Zamawiającego rekordów z Baz Wiedzy oraz miniatur artykułu.
3.6.4. Składnia Meta Tagu winna być edytowalna i aktywowana (dla uprawnionego
użytkownika określonego w ACL) z poziomu CMS.
Aktualizacja funkcjonalności: Newsletter
3.7.1. Dodanie w funkcjonalności Importuj z XML parametru określającego sposób
importowania zdublowanych adresów:
3.7.1.1. Pomijaj zdublowane adresy
3.7.1.2. Importuj zdublowane adresy do różnych kategorii, niezależnie od ilości
kategorii w których występują. Uwaga – dany adres może być zaimportowany
tylko raz w danej kategorii.
3.7.2. Przekonfigurowanie sposobu działania funkcjonalności Usuń grupę.
3.7.2.1. Funkcjonalność kasuje grupę użytkowników wraz z wszystkimi znajdującymi
się w niej adresami.
str. 4
3.8.
3.9.
3.10.
3.11.
3.12.
3.13.
3.7.3. Przekonfigurowanie sposobu działania funkcjonalności Usuń.
3.7.3.1. Funkcjonalność umożliwia zaznaczenie więcej niż jednego adresu email
w danej kategorii i usunięcie ich.
3.7.3.2. Konfiguracja modułu w zależności od poddomeny (niezależne – wskazanie
grupy użytkowników)
Aktualizacja funkcjonalności: Backup
3.8.1. Dodanie opcji umożliwiającej aktywowanie/dezaktywowanie działania funkcji Backup.
Aktualizacja modułu: Rotator HTML
3.9.1. Moduł umożliwi:
3.9.1.1. Tworzenie indywidualnych rotatorów HTML składających się z jednej lub
wielu stron treści.
3.9.1.2. Dodawania i usuwania stron do poszczególnych zdefiniowanych rotatorów;
3.9.1.3. Edycję każdej pojedynczej strony za pomocą edytora WYSWIG
z możliwością przełączenia pomiędzy warstwą wizualną a warstwą kodu html
3.9.1.4. Duplikowanie istniejących stron w pojedynczym rotatorze;
3.9.1.5. Duplikowanie istniejących rotatorów;
3.9.1.6. Kopiowanie i przenoszenie stron pomiędzy rotatorami;
Aktualizacja funkcjonalności: Ścieżka powrotu (breadcrumbs)
3.10.1. Aktywowanie parametrów „alt” każdej pozycji ścieżki (z wyłączeniem ostatniego
elementu).
3.10.2. Dezaktywowanie ostatniego elementu ścieżki jako aktywnego łącza.
3.10.3. Dezaktywowanie wszystkich zdublowanej ścieżki (szablon Forum, Bazy wiedzy
i inne).
Aktualizacja funkcjonalności: Adresy url
3.11.1. Zmiana
składni
adresów,
wg
wzorca:
stary
adres
http://www.web.gov.pl/(kategoria)/(opcjonalny opis)_157_23.html na nowy adres
http://www.web.gov.pl/(kategoria)/(opcjonalny opis)-157-23.html (zmiana znaku
podkreślenia na myślnik).
3.11.2. Przy wprowadzeniu zmian zastosowane zostaną przekierowania 301 (lub inne
rozwiązania zaproponowane przez Wykonawcę i zaakceptowane przez Zamawiającego)
starych adresów na nowe.
Aktualizacja funkcjonalności: Stronicowanie
3.12.1. Zmiana
zgodnie
ze
wzorem.
Aktualny
adres:
http://www.web.gov.pl/(kategoria)/?page=(wartość podziału)& na nowy adres
http://www.web.gov.pl/(kategoria)/page-(wartość podziału) (usunięcie znaków „?” oraz
„&” i zmiana znaku równości na myślnik).
3.12.2. Przekierowanie podstron zawierających oznaczenie pierwszej strony w listingach na
odpowiedniki bez tego oznaczenia.
Aktualizacja funkcjonalności: Meta Tagi.
3.13.1. Zmiana w meta tagach title oraz description zgodnie ze wzorem:
3.13.1.1. Aktualny
meta
tag
title:
dla
przykładowej
podstrony
http://www.web.gov.pl/(kategoria)/?page2& - <title>(opis title)</title> na nowy
meta tag title <title>(opis title) – Strona 2</title>.
3.13.1.2. Aktualny
meta
tag
description:
dla
przykładowej
podstrony
http://www.web.gov.pl/(kategoria)/?page2&
<meta
name="Description"
str. 5
3.14.
3.15.
3.16.
3.17.
3.18.
3.19.
3.20.
3.21.
3.22.
3.23.
content="(opis)”</title> na nowy meta tag title <meta name="Description"
content="(opis) – Strona 2”</title>.
Aktualizacja funkcjonalności: Grafika/miniatura
3.14.1. Aktywowanie przy wszystkich miniaturach grafik dostępnych na listach artykułów lub
rekordów bazy atrybutów alt.
3.14.2. Wartość atrybutu winna być pobierana:
3.14.3. W przypadku artykułów z tytułu artykułu
3.14.4. W przypadku rekordów bazy z nazwy rekordu.
3.14.5. Możliwosc samodzilenej edycji alt
Aktualizacja funkcjonalności: Moduł Baza Wiedzy Przetargi.
3.15.1. Po przekroczeniu zadeklarowanego w zapytaniu terminu składania, element [Wyślij
swoją ofertę] staje się niedostępny/niewidoczny.
Aktualizacja funkcjonalności: Milkbox.
3.16.1. Aktywowanie maski na lewej i prawej połowie wyświetlanej grafiki w postaci strzałek
sterujących przejściem do poprzedniej/następnej dostępnej grafiki
Aktualizacja funkcjonalności: Moduł Podziel się opinią.
3.17.1. Przeniesienie aktualnie wykorzystywanej funkcjonalności do nowego modułu - Moduł
podziel się opinią.
3.17.2. Moduł winien być parametryzowany podczas aktywowania.
3.17.3. Parametrem jest co najmniej adres email na który wysyłane są opinie.
3.17.4. Moduł może być aktywowany niezależnie na różnych szablonach z różnymi
niezależnymi parametrami.
Aktualizacja funkcjonalności: Moduł Baza Wiedzy Wydarzenia
3.18.1. W sekcji [Pozostałe opcje] dodanie pól określających:
3.18.1.1. Godzinę rozpoczęcia wydarzenia
3.18.1.2. Godzinę zakończenia wydarzenia
3.18.2. Wypełnienie pola przez użytkownika winno być opcjonalne.
Aktualizacja funkcjonalności: Menu
3.19.1. Aktywowanie parametru alt w pozycjach menu automatycznie pobieranego z nazwy
kategorii.
Aktualizacja funkcjonalności [Wyloguj].
3.20.1. Po wybraniu funkcjonalności [Wyloguj] użytkownik zostaje wylogowany z systemu
i przeniesiony do odpowiedniej strony:
3.20.1.1. nadrzędnej w zależności od lokalizacji na której się znajdował.
3.20.1.2. pozostaje na tej samej stronie, na której nastąpił wybór funkcjonalności
[Wyloguj] – o ile System upoważnia go do pozostania na tej stronie
Aktualizacja funkcjonalności: Materiały użytkownika (moduły: Galeria zdjęć, Galeria wideo,
Załączniki w: Bazie e-usług, Bazie B2B, Bazie Firm)
3.21.1. Umożliwienie
ręcznego
skonfigurowania
kolejności
wprowadzanych
(i wyświetlanych) materiałów wprowadzonych przez właściciela rekordu.
Aktualizacja funkcjonalności: Logowanie do Systemu
3.22.1. Zmianę algorytmu haszowania hasła z MD5 na SHA256
3.22.2. Wprowadzenie dodatkowego solenia hasła.
Aktualizacja baz systemu:
3.23.1. Zmodyfikowanie modułów wyświetlania baz poprzez dodanie parametru
określającego listę kategorię/ kategorie do wyświetlenia.
str. 6
3.23.2. Funkcjonalność będzie uruchomiona w bazach:
3.23.2.1. Bazie e-usług
3.23.2.2. Bazie B2B
3.23.2.3. Bazie Firm
3.23.2.4. Bazie Wydarzeń
3.23.2.5. Bazie zapytań ofertowych
3.23.2.6. Będzie możliwa edycja rekordu przez właściciela
3.24. Aktualizacja funkcjonalności: Artykuły
3.24.1. Aktywowanie elementu Rell=”canonical”
3.25. Aktualizacja funkcjonalności edycji artykułu.
3.25.1. Upoważniony (określony w ACL) użytkownik po zalogowaniu do systemu, po
wskazaniu konkretnego artykułu ma możliwość jego przemedytowania.
3.25.2. Po dokonaniu edycji i jej zaakceptowaniu bądź wybraniu innej opcji zostaje
przeniesiony do położenia z którego nastąpiła edycja z jednoczesnym przeładowaniem
strony.
3.26. Aktualizacja modułu rejestracji
3.26.1. Aktywowany i konfigurowany niezależnie od wybranej domeny,
3.26.2. Moduł wykorzystuje różne niezależne szablony rejestracji.
3.27. Inne funkcjonalności o zakresie rozbudowy wynikającym z analizy dokumentu „Projekt
Architektury Informacji - Platforma Wspieramy e-Biznes - Web.gov.pl” oraz udostępnionych
prototypów html docelowego systemu.
Etap IV – Wdrożenie nowych funkcjonalności Systemu
Wdrożenie nowych funkcjonalności Systemu wykonane zostanie na udostępnionym przez
Zamawiającego Systemie Deweloperskim będącym kopią Systemu Produkcyjnego. Wdrożenie
zostanie zrealizowane w celu uzyskania funkcjonalności określonych w dokumencie „Projekt
Architektury Informacji - Platforma Wspieramy e-Biznes - Web.gov.pl” oraz udostępnionych
prototypach html docelowego systemu. Wdrożenie zrealizowane zostanie po uprzednim
przeprowadzeniu Analizy Potrzeb Użytkownika i ich wynikach zawartych w zaakceptowanym przez
Zamawiającego dokument będący produktem Etapu I - Analiza Potrzeb Użytkownika.
4.1. Wdrożenie funkcjonalności PageTracker
4.1.1. Utworzenie funkcjonalności automatycznego dodawania parametru PageTracker do
każdego publikowanego dokumentu.
4.1.1.1. Znacznik w ciele tagu <a> winien być skonstruowany w oparciu o poniższy
schemat:
<a
onclick="_gaq.push
(['_trackPageview','względny_adres_pliku.format_pliku’]);"
href="względny_adres_pliku.format_pliku"
(inne parametry)>wyświetlana nazwa</ a>
4.1.1.2. Składnia parametru PageTracker winna być edytowalna dla uprawnionego
użytkownika z poziomu CMS (uprawnienie zgodnie z ACL).
4.1.1.3. Powiadomienie uprawnionego użytkownika o dodaniu nowej treści.
4.2. Wdrożenie funkcjonalność wysyłania informacji o pojawieniu się nowej treści w każdej z Baz
Wiedzy oraz Poradnikach (artykuły i poradniki).
4.2.1. Konfiguracja wysyłania informacji odbywa się dla każdej bazy z osobna.
4.2.2. Informacja wysyłana jest na określony w ustawieniach adres/adresy mail.
str. 7
4.3.
4.4.
4.5.
4.6.
4.7.
4.2.3. Treść informacji:
4.2.3.1. Tytuł: Nowy/przeedytowany rekord w „nazwa bazy”
4.2.3.2. Treść: Nowy/przeedytowany rekord: adres w postaci linku do
opublikowanego rekordu
Wdrożenie funkcjonalności: Artykuł – hiper link
4.3.1. Uruchomienie w artykule funkcjonalności automatycznego dodawania łącza na końcu
artykułu.
4.3.2. Funkcjonalność winna być dostępna jako nowy element checkbox dodany do zakładki
[Atrybuty artykułu]. Funkcjonalność winna być domyślnie aktywowana.
4.3.3. Łącze winno przekierowywać na ten sam artykuł.
4.3.4. Łącze w artykule winno być skonstruowane w oparciu o poniższy schemat:
4.3.5. <a href="względny_adres_artykulu.html" alt=”tytul_artykulu ”>tytul_artykulu</ a>
Wdrożenie funkcjonalności: Artykuł – przekierowanie
4.4.1.
Aktywowanie funkcjonalności umożliwiającej automatyczne przekierowanie lidu
artykułu na dowolną lokalizację. Po wybraniu lidu z aktywną opcją przekierowania
użytkownik przekierowany zostanie na docelową lokalizację.
4.4.2.
Funkcjonalność winna być dostępna jako nowy element „Przekierowanie” dodany
do zakładki [Atrybuty artykułu].
4.4.3.
Funkcjonalność będzie posiadać pole określające adres docelowej lokalizacji.
4.4.4.
Cel będzie posiadał parametr określający sposób jego otwierania:
4.4.4.1. W nowym oknie przeglądarki
4.4.4.2. W tym samym oknie przeglądarki
Wdrożenie funkcjonalności AddThis
4.5.1. Funkcjonalność opisana i udostępniona na zasadach http://www.addthis.com/
4.5.2. Funkcjonalność aktywowana jako moduł (z listy modułów).
Wdrożenie funkcjonalności obsługi wielu domen.
4.6.1. Konta userów (określony w ACL)/ różne grupy (określony w ACL)/ różny formularz
rejestracyjny,
4.6.2. Personalizacja dostępnych funkcjonalności CMS zależnie od wybranej domeny
(określony w ACL),
4.6.3. Różne szablony i CSS/Sprite,
4.6.4. Różne newslettery (wysyłane z wykorzystaniem uzgodnionego z Zamawiającym adresu
e-mail w danej domenie)
Wdrożenie funkcjonalności: Import treści udostępnionych przez źródła zewnętrzne.
4.7.1. Funkcjonalność obsługiwała będzie treści udostępnione co najmniej w formacie XML.
4.7.2. Funkcjonalność administrowana będzie przez uprawnionego (określony w ACL)
użytkownika z poziomu CMS.
4.7.3. Pobierane dane będą zapisywane w Systemie.
4.7.4. Funkcjonalność umożliwiała będzie co najmniej:
4.7.4.1. Tworzenie, aktywowanie, blokowanie i usuwanie instancji.
4.7.4.2. Niezależne administrowanie wieloma instancjami obsługującymi pobierane
treści.
4.7.4.3. Określenie lokalizacji udostępnianych treści
4.7.4.4. Określenie pól pobieranych treści w elemencie.
4.7.4.5. Określenie ilości pobieranych elementów.
4.7.4.6. Określenie czasu, po którym System pobierze kolejną wersję treści.
str. 8
4.7.4.7. Podgląd pobranych treści.
4.7.5. Import treści udostępnionych przez inne źródła będzie implementowana w formie
modułu.
4.7.5.1. Aktywowanego z dostępnej listy modułów, przez uprawnionego (określony w
ACL) użytkownika.
4.7.5.2. Moduł będzie umożliwiał co najmniej:
4.7.5.2.1. Wybór (z listy select) dostępnego, opublikowanego w CMS/
Funkcjonalność obsługi Modułu zewnętrzne treści, źródła,
4.7.5.2.2. Wybór sposobu wyświetlania treści (przykład wyświetlania modułu
opisany w Projekcie Architektury Informacji pod nazwą Informacje
Prasowe).
4.8. Wdrożenie funkcjonalności: Aktualizacja pliku
4.8.1. Aktywowanie
funkcjonalności
umożliwiającej
zaktualizowanie
(podmianę)
opublikowanego pliku.
4.8.2. Funkcjonalność podczas aktualizacji zachowuje zahashowaną/opublikowaną nazwę pliku.
4.8.3. Funkcjonalność umożliwia archiwizowanie poprzednich wersji pliku z możliwością:
4.8.3.1. Aktywowania/opublikowania pliku.
4.8.3.2. Podglądu pliku.
4.9. Wdrożenie funkcjonalności: Przekierowanie adresu
4.9.1. Funkcjonalność umożliwi przekierowanie jednego adresu www na inny adres www.
4.9.2. Administracja funkcjonalnością winna być dostępna dla upoważnionego (określony w
ACL) użytkownika.
4.9.3. Administrowanie przekierowaniami odbywać się będzie na poziomie:
4.9.3.1. Pojedynczego artykułu: adres artykułu > adres nowego artykułu
4.9.3.2. Kategorii artykułów: adres kategorii > adres nowej kategorii.
4.9.3.3.
W przypadku kiedy w danej kategorii znajdują się artykuły, przekierowanie
winno obejmować wszystkie artykuły: adres kategorii/artykul_x > adres nowej
kategorii/artykuł_x.
4.9.4. Funkcjonalność winna dodatkowo umożliwiać:
4.9.4.1. Eksport zestawienia wszystkich aktywnych przekierowań do pliku formatu, co
najmniej CSV z możliwością określenia znaku rozdzielania danych;
4.9.4.2. Import zestawienia przekierowań w formacie, co najmniej CSV z możliwością
określenia znaku rozdzielania danych.
4.9.4.3. Prezentację wszystkich przekierowań w postaci listy.
4.9.4.4. Możliwość administrowania pojedynczym przekierowaniem.
4.10. Wdrożenie funkcjonalności: Moduł tooltip
4.10.1. Utworzenie modułu typu tooltip.
4.10.2. Moduł winien być parametryzowany:
4.10.2.1. Pole edycyjne typu html umożliwiające wprowadzanie treści.
4.10.2.2. Czas pokazywania modułu.
4.10.2.3. Parametr pokaż zawsze/pokaż tylko nowemu użytkownikowi.
4.10.3. Aktywacja modułu winna być oparta o ogólnoprzyjęty sposób aktywowania modułów
w Systemie.
4.10.4. Uprawniony użytkownik (określony w ACL) ma możliwość wskazania zakotwiczenia
aktywowanego modułu w dowolnym miejscu serwisu.
4.10.5. Zamknięcie modułu następuje poprzez:
str. 9
4.10.5.1. Wybranie przez użytkownika krzyżyka zamykającego moduł [x]
4.10.5.2. Upłynięcie zadeklarowanego czasu pokazywania modułu.
4.10.6. Wizualizacja zastosowania.
4.10.7.
Wizualizacja przykładu (profil użytkownika Multibank.pl).
4.11. Wdrożenie elementu - tag <H1>
4.11.1. Aktywowanie funkcjonalności wyróżnienia nagłówka strony znacznikiem <h1> i/lub
<h2> w zależności od konfiguracji.
4.12. Inne funkcjonalności o zakresie wdrożenia wynikającym z analizy dokumentu „Projekt
Architektury Informacji - Platforma Wspieramy e-Biznes - Web.gov.pl” oraz udostępnionych
prototypów html docelowego systemu.
Etap V - Wdrożenie nowego layoutu graficznego
Wdrożenie nowego layoutu serwisu wykonane zostanie na udostępnionym przez Zamawiającego
Systemie Deweloperskim będącym kopią Systemu Produkcyjnego.
5.1. Wdrożenie nastąpi w oparciu o udostępnione przez Zamawiającego:
5.1.1. Księga Wizualizacji stron internetowych Zamawiającego,
5.1.2. Projekty graficzne w postaci plików PSD,
5.1.3. Pliki źródłowe XHTML (szablony wykonane w technologii Responsive Web Design RWD)
Wykonawca wdroży nową wizualizację w całym serwisie Zamawiającego.
str. 10
5.2.
5.3.
Nowy wdrożony layout serwisu winien:
5.2.1. Być zgodny z Księgą Wizualizacji stron internetowych Zamawiającego oraz
dokumenterm „Projekt Architektury Informacji - Platforma Wspieramy e-Biznes Web.gov.pl” oraz udostępnionymi prototypami html docelowego systemu CMS.
5.2.2. Opisywać wszystkie elementy serwisu w tym:
5.2.2.1. Elementy zwizualizowane na udostępnionych projektach graficznych.
5.2.2.2. Elementy nieujęte na udostępnionych projektach graficznych.
5.2.3. Wykorzystywać jeden plik CSS, wybrany dla aktywnej domeny, zawierający style
opisujące warstwę graficzną elementów serwisu, w wersji co najmniej 2.0,
5.2.4. Wykorzystywać technikę CSS Sprites – jako maksymalizację optymalizacji stron www
Systemu.
5.2.5. Być jednolity niezależnie od wykorzystywanych przeglądarek internetowych.
5.2.6. Bazując na udostępnionych szablonach, realizować metodę Responsive Web Design
(RWD).
5.2.7. Być zgodny z wytycznymi dla zachowania standardów E-dostępności i zgodności z
wymogami prawa w Polsce i UE oraz WCAG (Web Content Accessibility Guidelines)
Wygląd elementów, które nie zostały zwizualizowane na udostępnionych projektach
graficznych zostanie dostosowany przez Wykonawcę do ogólno przyjętej nowej linii graficznej
serwisu.
Etap VI – Przeprowadzenie testów prawidłowości działania Systemu
Po zakończeniu zadań I-V Wykonawca przeprowadzi:
6.1. Testy wewnętrzne - przeprowadzane przez zespół Wykonawcy. Testy zostaną przeprowadzone
wg scenariuszy testowych przygotowanych przez Wykonawcę. W ramach testów wewnętrznych
zostaną przeprowadzone testy iteracyjne - organizowane i przygotowywane przez Wykonawcę
testy komponentów oprogramowania (modułów) z udziałem użytkownika końcowego.
Wykonawca jest odpowiedzialny za:
6.1.1. przygotowanie danych testowych,
6.1.2. przygotowanie scenariuszy testów i przekazanie ich Zamawiającemu do akceptacji,
6.1.3. przygotowanie środowiska testowego,
6.1.4. aktywowanie odpowiednich modułów,
6.1.5. ładowanie danych testowych.
6.1.6. Wykonanie testów iteracyjnych ma zapewnić użytkownikom końcowym możliwość
oceny funkcjonalności przygotowanego oprogramowania, wykrycia błędów w
oprogramowaniu na wczesnym etapie realizacji i zgłoszenie uwag, zmian oraz uzupełnień
do założonej funkcjonalności.
6.2. Testy akceptacyjne - przygotowane i przeprowadzone przez Zamawiającego w środowisku
testowym, w obecności przedstawicieli Wykonawcy i/lub audytorów zewnętrznych. Przed
rozpoczęciem testów Wykonawca przeprowadzi szkolenie dla zespołu testowego. Wykonawca
odpowiada za:
6.2.1. przygotowanie planu testów, danych testowych
6.2.2. dostarczenie arkuszy testowych,
6.2.3. ładowanie danych testowych,
6.2.4. przygotowanie scenariuszy testowych zawierających co najmniej następujące pola dla
każdego testowanego przypadku: nazwa przypadku użycia, opis testu, warunki wstępne,
str. 11
6.3.
6.4.
procedura testowa, oczekiwane rezultaty. Scenariusze testowe podlegają akceptacji przez
Zamawiającego.
Wykonanie testów akceptacyjnych ma potwierdzić, że system spełnia założone kryteria jakości,
w tym że jego funkcjonalność jest zgodna z wymaganiami biznesowymi użytkowników
i nie zawiera błędów uniemożliwiających jego użycie. Wynikiem testów akceptacyjnych jest
raport z testów, który jest podstawą sporządzenia Protokołu Akceptacji Produktu lub Usługi.
Testy akceptacyjne będą składały się z następujących typów testów:
6.3.1. Testy funkcjonalne:
6.3.1.1. testy czarnej skrzynki - testy odnoszą się do specyfikacji pracy systemu.
Podczas analizy wyników testów nie jest badany wewnętrzny sposób realizacji
funkcji systemu. Testy weryfikują implementację funkcjonalności z podaną
w specyfikacji. Dane wejściowe i oczekiwane wyniki przygotowywane są na
podstawie specyfikacji. Podczas testów system jest traktowany jak czarna
skrzynka, na wejściu której podajemy przygotowane dane wejściowe sprawdzamy,
czy otrzymane wyniki zgadzają się z oczekiwanymi,
6.3.1.2. testy modułowe - testy funkcjonalnej całości określonego fragmentu systemu
(modułu), które mają na celu sprawdzenie, czy aplikacja działa zgodnie
z uzgodnioną specyfikacją wymagań dla poszczególnych modułów. Upewnienie
się, że każda funkcja umożliwia realizację wszystkich dopuszczalnych akcji
i sytuacji, oraz uniemożliwia realizację każdej akcji i sytuacji zabronionej,
6.3.1.3. testy GUI - sprawdzenie nawigacji w systemie, sprawdzenie poprawności
interfejsu i specyfikacji modułu help ,
6.3.1.4. testy administracji i kontroli procedur administracji,
6.3.2. Testy integracyjne:
6.3.2.1. testy instalacji i uzyskanej konfiguracji – testy polegają na sprawdzeniu
kompletności instalacji, zgodności przebiegu procesu instalacji z instrukcją,
dokumentacją oraz poprawności uzyskanej konfiguracji,
6.3.2.2. testy komunikacji między modułami - testy poprawności powiązań między
modułami. Celem testu jest wykazanie, że poszczególne moduły systemu
prawidłowo ze sobą współpracują i na tej podstawie dalsze testy sprawdzają czy
funkcjonalność systemu wymagająca zaangażowania wielu modułów jest również
realizowana prawidłowo,
6.3.3. Testy bezpieczeństwa – w tym bezpieczeństwo dostępu do danych i zabezpieczenia
danych przed utratą lub nieautoryzowaną zmianą, administracja użytkownikami i bazą
danych, zakres dostępu do funkcji i danych; reakcja na nieoczekiwane dane. Reakcja na
podmianę komponentów, bibliotek systemu, itp.
Po zakończeniu testów zostanie sporządzony raport zawierający wynik testów.
Etap VII – Aktualizacja Dokumentacji Systemu
7.1.
7.2.
Wykonawca w czasie Analizy Potrzeb Użytkownika zapozna się z dotychczasową
dokumentacją systemu i przygotuje opisane poniżej dokumenty (nazywane łącznie
Dokumentacją Systemu) na takim samym poziomie szczegółowości jak dokumentacja
źródłowa.
Przy przygotowywaniu Dokumentacji Systemu Wykonawca wykorzysta posiadaną przez
Zamawiającego Dokumentację Platformy Wspieramy e-Biznes.
str. 12
7.3.
7.4.
7.5.
7.6.
7.7.
7.8.
7.9.
Zaktualizowana Dokumentacja Systemu musi obejmować wszystkie dotychczasowe jak i nowo
wdrożone elementy.
Przy tworzeniu Dokumentacji Systemu celem Wykonawcy będzie to, aby dokumentacja
umożliwiła innym programistom i administratorom - zarówno ze strony Zamawiającego jak
i podmiotu trzeciego - szybkie i bezproblemowe zapoznanie się z architekturą
i rozwiązaniami przyjętymi w Systemie oraz w maksymalnym stopniu ułatwiła
przeprowadzenie rozbudowy lub zmiany Systemu.
Celem dokumentacji użytkowej jest umożliwienie szybkiego i pełnego zapoznania się
z Systemem, sposobem konfiguracji jego działania i realizacji zadań. Dokumentacja podlegać
będzie procesowi odbioru przez Zamawiającego. Zamawiający zwróci szczególną uwagę na
wywiązanie się Wykonawcy z powyższego warunku.
Dostarczy Zamawiającemu całość zaktualizowanej dokumentacji. Zamawiający może wymagać
umieszczenia w Dokumentacji Systemu dodatkowych elementów uzgodnionych z Wykonawcą.
Dokumentacja będzie zawierać co najmniej:
7.6.1. Specyfikację Funkcjonalną Systemu
7.6.2. Projekt Techniczny Systemu
7.6.3. Moduły Systemu, w tym kody źródłowe i ich opis
7.6.4. Administrację Systemem, w tym procedury instalacji Systemu, konfiguracji wszystkich
elementów Systemu, procedury aktywacji i dezaktywacji Modułów wchodzących w skład
Systemu, konfiguracji środowiska bazy danych Systemu, obsługi podstawowych funkcji
bazy danych Systemu i reagowania w typowych sytuacjach awaryjnych.
7.6.5. Rozbudowę Systemu
System ma w przyszłości podlegać ulepszaniu poprzez rozbudowę lub modyfikację, w związku
z tym Wykonawca:
7.7.1. Przedstawi specyfikację i zasady tworzenia dodatkowych funkcjonalności Modułów,
7.7.2. Określi warunki implementacji nowych funkcjonalności w Systemie,
7.7.3. Przygotuje proceduralny opis testów określających poprawność integracji nowo
instalowanych funkcjonalności w Systemie.
Dokumentacja Systemu winna zawierać co najmniej opis:
7.8.1. procedur instalacji Systemu,
7.8.2. konfiguracji wszystkich elementów Systemu,
7.8.3. zarządzania bezpieczeństwem Systemu,
7.8.4. zarządzania użytkownikami Systemu,
7.8.5. procedur aktywacji i dezaktywacji wszystkich modułów wchodzących w skład Systemu,
7.8.6. środowiska bazy danych Systemu,
7.8.7. obsługi podstawowych funkcji bazy danych Systemu,
7.8.8. obsługi funkcji specjalnych (administracyjnych) Systemu,
7.8.9. reagowania w typowych sytuacjach awaryjnych Systemu,
7.8.10. wykonywania kopii zapasowych,
7.8.11. przywracania Systemu po awarii.
Dokumentacja Systemu powinna być dostarczona Zamawiającemu w wersji elektronicznej, na
nośniku CD/DVD (w formacie MS Word lub OpenOffice) oraz w postaci wydrukowanego
dokumentu formatu A4.
Etap VIII – Migracja Systemu do Środowiska Produkcyjnego
str. 13
8.1.
8.2.
8.3.
Po zaakceptowaniu przez Zamawiającego poprawności zrealizowania przez Wykonawcę
Etapów I-VII, Wykonawca pod nadzorem ekspertów ze strony Zamawiającego dokona migracji
Systemu ze Środowiska Deweloperskiego do Środowiska Produkcyjnego.
Przed migracją Wykonawca w porozumieniu z Zamawiającym określi sposób, czas i procedurę
migracji tak aby zminimalizować niedostępność Środowiska Produkcyjnego podczas
wykonywania procedury migracji.
Wykonawca zagwarantuje zachowanie stanu aktualności informacji dostępnych w Systemie
Produkcyjnym w niezmienionej postaci (użytkownicy, artykuły, rekordy baz).
Etap IX - Odbiór przedmiotu zamówienia
9.1.
9.2.
9.3.
Akceptacja i odbiór systemu odbędzie się na podstawie:
9.1.1. Oświadczenia Wykonawcy o przeprowadzeniu testów zgodnie ze specyfikacją załączoną
do oświadczenia. Oświadczenie musi zawierać informacje o wyniku testów.
9.1.2. Oświadczeniu Wykonawcy o zgodności wykonanej aktualizacji funkcjonalności Systemu
zgodnie z uwarunkowaniami jego budowy w tym w szczególności z aktami prawnymi
i uwarunkowaniami technicznymi.
9.1.3. Protokołów z testów akceptacyjnych przeprowadzonych pod nadzorem Zamawiającego
i/lub audytorów zewnętrznych, wg scenariuszy testowych dostarczonych przez
Wykonawcę, a zaakceptowanych przez Zamawiającego.
9.1.4. Specyfikacji funkcjonalnej,
9.1.5. Projektu technicznego,
9.1.6. Rejestru zmian,
9.1.7. Dostarczonego kompletu wymaganej dokumentacji.
Na podstawie dokumentów określonych w punkcie 9.1 sporządzony zostanie protokół odbioru
końcowego przedsięwzięcia.
W ramach wynagrodzenia za wykonanie umowy Wykonawca przeniesie w dniu odbioru
końcowego na Zamawiającego autorskie prawa majątkowe, w tym prawo do zezwalania na
wykonywanie zależnego prawa autorskiego, do wszystkich nowo powstałych pól eksploatacji
systemu.
9.3.1. Wykonawca przekaże Zamawiającemu kody źródłowe oprogramowania wytworzonego w
wyniku realizacji Umowy oraz przeniesie autorskie prawa majątkowe, każdorazowo wraz
z zakończeniem każdego z etapów prac z chwilą podpisania protokołów odbioru oraz
dostawą nowej zaakceptowanej wersji systemu oraz po zakończeniu realizacji Umowy z
chwilą podpisania protokołu odbioru końcowego.
9.3.2. Wykonawca przenosi na Zamawiającego autorskie prawa majątkowe do produktów
wytworzonych w wyniku realizacji Umowy, w tym zwłaszcza oprogramowania,
dokumentacji technicznej i wszystkich dokumentów będących wynikiem realizacji
Umowy oraz prawo do zezwalania na wykonywanie zależnego prawa autorskiego na
zasadach określonych w niniejszym punkcie oraz umowie.
9.3.3. Autorskie prawa majątkowe do produktów powstałych w wyniku realizacji Umowy
przechodzą na Zamawiającego z chwilą dokonania ich protokolarnego odbioru.
Przeniesienie autorskich praw majątkowych na Zamawiającego obejmuje wszelkie pola
eksploatacji wskazane w art. 50 i 74 ust. 4 ustawy z dnia 4 lutego 1994 r. o prawie
autorskim i prawach pokrewnych (Dz. U. z 2006r. Nr 90, poz. 631, z późn. zm.) oraz pola
eksploatacji obejmujące prawo do: wykorzystywania, utrwalania i zwielokrotniania
str. 14
oprogramowania wykonywalnego i kodów źródłowych w całości lub w części środkami
i w formie dysków twardych, tasiemek streamerów, dyskietek, nośników CD-R/RW,
DVD-R/RW, przenośnej pamięci zewnętrznej, poczty elektronicznej, za pomocą internetu
lub intranetu, przesyłania za pomocą sieci bezprzewodowych, na wydrukach
papierowych, tłumaczenia, przystosowywania, rozbudowy, zmiany układu lub innej
zmiany w oprogramowaniu, w tym: uzupełnienia, skracania, przeróbki oraz sporządzania
nowej wersji oprogramowania wykonywalnego i kodów źródłowych, rozpowszechniania
przy pomocy nośników informacji, określonych w pkt. 1, odpłatnego lub nieodpłatnego
udostępniania do korzystania osobom trzecim (licencja), najmu i dzierżawy
oprogramowania lub jego kopii, modyfikowania kodu źródłowego we własnym zakresie
lub przez osoby trzecie.
Etap X - Asysta Techniczna i Serwis Gwarancyjny
10.1. W ramach przedsięwzięcia, po wdrożeniu pełnej funkcjonalności Systemu, do czasu ustania
gwarancji, Wykonawca zapewni usługę asysty technicznej - stałej opieki powdrożeniowej nad
Systemem, która obejmować będzie:
10.1.1. konsultacje i pomoc udzielaną w zakresie funkcjonowania Systemu,
10.1.2. konsultacje telefoniczne w zakresie funkcjonowania Systemu, udzielane dla
pracowników Zamawiającego oraz użytkowników Systemu,
10.1.3. wszelkie zmiany definiowalnych elementów Systemu oraz zmiany wprowadzane do
Systemu, uwzględniające zmiany w obowiązującym prawodawstwie.
10.2. W przypadku zmian w przepisach prawa, które powodują konieczność zmiany funkcjonalności
Systemu, a które nastąpią w trakcie trwania Asysty Technicznej, Wykonawca dokona
aktualizacji Systemu polegającej na dostosowaniu go do zmieniających się przepisów prawa w
terminie najpóźniej do 7 dni przed wejścim w życie nowych przepisów prawa – minimalny
wymagany czas dostępności systemu to 99% w ciągu roku.
10.3. Po końcowym odbiorze Systemu (po wdrożeniu pełnej funkcjonalności Systemu), przez czas
określony w ofercie, Wykonawca będzie zobowiązany do zapewnienia serwisu gwarancyjnego.
10.4. Wykonawca
określi
możliwości
rozbudowy
Systemu
o
nowe
moduły
i funkcjonalności określając kryteria, jakie muszą spełniać nowoprzyłączane elementy, tak aby
zachować poprawność działania Systemu z jednoczesnym zachowaniem gwarancji.
10.5. Wykonawca gwarantuje Zamawiającemu, że wdrożony System jest wolny od wad fizycznych
oraz sprawny w działaniu, a w szczególności:
10.5.1. Zapewnia funkcjonalną zgodność z dokumentacją,
10.5.2. Nie zawiera istotnych wad uniemożliwiających lub ograniczających eksploatację
modułów w całym oprogramowaniu wchodzącym w skład tego Systemu, wykonanym lub
dostarczonym przez Wykonawcę;
10.5.3. Jest kompatybilny z programami i innymi systemami Zamawiającego zgodnie
z założeniami niniejszego przedsięwzięcia i nie powoduje awarii i błędów innych
systemów, z którymi jest sprzężony,
10.5.4. Wszelkie usługi instalacyjno - wdrożeniowe są kompletne, poprawne i wykonane
zgodnie z dokumentacją techniczną
10.6. W ramach Gwarancji nieodpłatnie Usunięte zostaną wady Systemu stwierdzone jeszcze w
okresie trwania zamówienia, których termin usunięcia przypada na okres obowiązywania
Gwarancji.
str. 15
10.7. Okres Gwarancji na cały System liczony jest od dnia podpisania bez zastrzeżeń Protokołu
Odbioru Końcowego.
10.8. Zamawiający ma obowiązek zgłosić wady objęte niniejszą gwarancją niezwłocznie po ich
wystąpieniu do przedstawiciela Wykonawcy.
10.9. Termin gwarancji dla Systemu ulega przedłużeniu o czas, w ciągu którego Zamawiający nie
mógł korzystać z Systemu.
10.10. W przypadku niewywiązywania się Wykonawcy z zobowiązań gwarancyjnych Zamawiający
ma prawo skorzystać, na koszt Wykonawcy, z usług zastępczych bez utraty prawa gwarancji.
10.11. Wykonawca zobowiązuje się do podpisania umowy na serwis pogwarancyjny na żądanie
Zamawiającego. Cena świadczenia serwisu pogwarancyjnego zostanie ustalona
w odrębnej umowie serwisowej.
10.12. Procedury Serwisu Gwarancyjnego:
10.12.1. Interwencja grupy serwisowej na podstawie zgłoszeń e-mail, telefonicznych
(potwierdzonych
e-mail), systemem raportowania błędów (np. Mantis lub równorzędny) lub faksem,
10.12.2. Efektywna reakcja grupy serwisowej w ciągu 12 godzin zegarowych od zgłoszenia
awarii lub innej usterki,
10.12.3. Usunięcie awarii systemu oraz odtworzenie danych w ciągu maksymalnie 24 godzin
zegarowych od chwili rozpoczęcia akcji przez grupę serwisową,
10.12.4. Usunięcie każdego błędu krytycznego w ciągu 24 godzin zegarowych od zgłoszenia
błędu. Usunięcie odbędzie się w dwóch fazach:
10.12.4.1. w ciągu najpóźniej pierwszych 6 godzin zegarowych od zgłoszenia przez
Zamawiającego, Wykonawca określi, w jaki sposób należy eksploatować System
tak aby wyeliminować ryzyko wynikające ze stwierdzonego błędu,
10.12.4.2. w ciągu następnych 18 godzin zegarowych Wykonawca przywróci całkowitą
funkcjonalność Systemu wraz z odzyskanymi danymi.
10.13. Usuwanie błędów niekrytycznych w terminie do 5 dni roboczych od momentu zgłoszenia błędu,
10.14. Uaktualnienie, kopii oprogramowania (wersji instalacyjnej) oraz dokumentacji po usunięciu
błędów krytycznych w systemie.
10.15. Przeprowadzenie testów i/lub innych czynności sprawdzających poprawność działania systemu
po dokonaniu naprawy.
10.16. Sporządzenie protokołu usunięcia błędu przez Wykonawcę, w którym określone zostaną
przyczyny wystąpienia błędu oraz procedurę usunięcia i przywrócenia Systemu.
10.17. Instalowanie usprawnień, łat programowych, aktualizacji i poprawek do Systemu.
10.18. Koszt usługi serwisu gwarancyjnego i asysty technicznej będzie wliczony do oferty cenowej
i nie objęty dodatkowymi opłatami
str. 16