Załącznik nr 1 Zakres Zadań Wykonawcy 1. Cel zadania: Celem jest utworzenie z wykorzystaniem systemu CMS Joomla nowych stron internetowych: 1.1. Startup.gov.pl wersja polska i angielska, zawierająca m.in.: 1.1.1. funkcjonalność katalog polskiego ekosystemu startupowego w wersji polskiej i angielskiej, 1.1.2. stronę konferencji Startup Summit (w wersji angielskiej), 1.2. Platformystartowe.gov.pl wersja polska i angielska, zawierająca elementy określone w dalszej części ZZW wraz z wyodrębnionymi podstronami animatorów platform startowych (wersja polska i angielska). W obydwu stronach (startup.gov.pl i platformystartowe.gov.pl) Wykonawca zaimplementuje komponent społecznościowy w oparciu o element Jomsocial (wersja polska i angielska). 1.3. www.e-punkt.gov.pl w wersji polsko i angielskojęzycznej, 2. Założenia ogólne: 2.1. Systemem CMS, który musi wykorzystać Wykonawca jest Joomla, system zarządzania treścią napisany w języku PHP, wykorzystujący bazę danych MySQL, rozprowadzany na zasadach wolnego oprogramowania, w wersji zgodnej z aktualnie wskazaną przez Biuro Informatyki PARP (co najmniej 3.4.1). Efektem będzie kompletna instancja systemu CMS Joomla wraz ze zmigrowanymi danymi, spełniająca wszystkie wymagania opisane w niniejszym dokumencie, zwana dalej Systemem; 2.2. Serwer na, którym będzie utrzymywana witryna dostarczy Biuro Informatyki PARP. System zostanie zainstalowany na serwerze Zamawiającego, który wykorzystuje następujące elementy: Linux Debian 6, Apache 2.2, MySQL 5.1, PHP 5.3 2.3. Wykonawca zobowiązany jest do wykonywania prac wdrożeniowych w oparciu o SVN Zamawiającego. Wykonawca po podpisaniu umowy otrzyma dostęp do instancji narzędzia informatycznego Zamawiającego. Wykonawca zobowiązany jest do przedstawienia pełnej listy osób uczestniczących w projekcie, celem nadania dostępów do w/w narzędzia; 2.4. Strony zostaną zaprojektowane z wykorzystaniem obsługi wielu wersji językowych dostępnych w CMS Joomla; System powinien umożliwiać dodawanie i obsługę kolejnych domen; Wszelkie wykonane prace należy tak prowadzić by możliwe było ich zastosowanie do wszystkich subdomen systemu nie naruszając występujących w nich struktur danych i funkcjonalności modułów/komponentów; 2.5. W trakcie realizacji niniejszego zamówienia Wykonawca jest zobowiązany do: 2.5.1. Przeprowadzenia pierwszego spotkania otwierającego projekt z Zamawiającym (w siedzibie Zamawiającego) na którym zostaną omówione główne cele zamówienia i doprecyzowane założenia wszystkich Zadań realizowanych w ramach zamówienia; 2.5.2. Ścisłej współpracy z Zamawiającym na każdym etapie realizacji przedsięwzięcia, w tym do aktywnego uczestniczenia w zwołanych przez Zamawiającego spotkaniach (w tym ad Strona 1 z 14
hoc kiedy zajdzie istotna potrzeba w trakcie realizacji projektu, nie więcej niż 5 w ciągu trwania całego projektu) lub zaplanowanych przez Wykonawcę; 2.6. Zamawiający oczekuje od Wykonawcy szczególnej współpracy w zakresie jakości i bezpieczeństwa kodu wytwarzanego podczas realizacji zamówienia. Wykonawca, prowadząc prace programistyczne, będzie zobowiązany stosować się do minimalnych wymogów Zamawiającego: 2.6.1. wykorzystywanie stabilnych, bezpiecznych, bezpłatnych i wspieranych przez Joomla framework ów programistycznych 2.6.2. realizowanie funkcjonalności portalu przede wszystkim za pomocą dostępnych, bezpłatnych modułów i komponentów, 2.6.3. wykorzystywanie bibliotek, modułów i komponentów stabilnych, bezpiecznych i aktualnych, 2.6.4. stosowanie spójnej i przejrzystej struktury kodu, kategoryzowanie obiektów i szablonów, 2.6.5. stosowanie komentarzy w wytwarzanym kodzie aplikacji (współczynnik skomentowania kodu nie mniejszy niż 10%), nie licząc wykomentowanych fragmentów kodu, 2.7. Zamawiający oczekuje od Wykonawcy zachowania najwyższej staranności i działania zgodnie z obowiązującym stanem prawnym; 2.8. Oprogramowanie Joomla! nie może być dostarczone w postaci zmodyfikowanej przez Wykonawcę w sposób niezgodny z dokumentacją Joomla!, tj. m.in. nie mogą być dokonywane modyfikacje bezpośrednio w kodzie CMS. 2.9. Zastosowane rozszerzenia przez Wykonawcę nie mogą być w wersji demonstracyjnej. Preferowane są rozszerzenia bezpłatne, stabilne, bezpieczne, aktualne i posiadające wsparcie producenta. Zastosowanie rozszerzeń musi być zgodne z dostarczoną do nich licencją, tj. jeżeli wymaga tego licencja muszą one być opłacone z góry, z okresem ważności licencji na korzystanie i aktualizację danego rozszerzenia równoważnym okresowi świadczenia usługi gwarancyjnej przez Wykonawcę. Wszelkie opłaty licencyjne będą wliczone do oferty cenowej i nieobjęte dodatkowymi opłatami ze strony Zamawiającego. 2.10. Zamawiający wymaga od Wykonawcy by działania wykonywane przez Wykonawcę podczas prac, nie miały wpływu na stabilności funkcjonowania systemów Zamawiającego. 2.11. Zamawiający wykona prace z uwzględnieniem Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz. U. 2012 poz. 526 z p. zm.), oraz wytycznych W3C. 2.12. Zamawiający wskazuje, że każdorazowo w tym dokumencie używając pojęcia dni robocze rozumie dni od poniedziałku do piątku z wyłączeniem dni ustawowo wolnych od pracy w Polsce. 2.13. Wykonawca przekaże Zamawiającemu dokumentację Systemu w wersji elektronicznej w zakresie opisanym w pkt. 7 Strona 2 z 14
2.14. Wykonawca będzie świadczyć usługę gwarancji zgodnie z pkt 9. 3. Etap I Spotkanie otwierające projekt w siedzibie Zamawiającego 3.1. Wykonawca zobowiązany jest do przeprowadzenia pierwszego spotkania otwierającego projekt z Zamawiającym (w siedzibie Zamawiającego) na którym zostaną omówione główne cele zamówienia i doprecyzowane założenia wszystkich Zadań realizowanych w ramach zamówienia; 3.2. W ramach spotkania Wykonawca przeprowadzi doprecyzowanie założeń wszystkich Zadań realizowanych w ramach zamówienia. Wymagania zapisane w niniejszym dokumencie powinny być traktowane jako minimalne wymagania stawiane przed Systemem CMS. Wykonawca zidentyfikuje i usystematyzuje funkcjonalności opisane w ZZW, w innych udostępnionych dokumentach oraz sprecyzuje i spisze uzgodnione szczegółowe wymagania oraz funkcjonalności Systemu CMS. Wynikiem Analizy będzie spis Funkcjonalności Systemu. 3.3. Podczas spotkania omówione zostaną i ostatecznie uzgodnione następujące obszary: Specyfikacja użytych funkcjonalności Systemu; architektura powiązań pomiędzy Systemem, a zastosowanymi subdomenami; Zakres danych przechowywanych i udostępnianych przez System; Role użytkowników Systemu oraz grupowane przez nie uprawnienia. Wymagania wydajnościowe stawiane Systemowi. Wymagania bezpieczeństwa wobec Systemu. Sposób przeprowadzenia testów akceptacyjnych. 4. Etap II Przygotowanie projektów graficznych i opracowanie szablonów dla tworzonych stron 4.1. W ramach zadania Wykonawca przygotuje projekty graficzne dla następujących stron:. 4.1.1. Dla domeny startup.gov.pl wraz z wersją anglojęzyczną (projekt zgodny z systemem identyfikacji wizualnej PARP http://www.parp.gov.pl/files/74/325/17638.pdf) 4.1.2. Dla domeny startup.gov.pl podstrona konferencji Startup Summit (projekt zgodny z systemem identyfikacji wizualnej Platform Startowych http://www.web.gov.pl/g2/big/2015_11/63b8e70eb1ce3a325aa10f35bca0ae8a.pdf) 4.1.3. Dla domeny startup.gov.pl podstrony katalogu polskiego ekosystemu startupowego (projekt zgodny z systemem identyfikacji wizualnej PARP http://www.parp.gov.pl/files/74/325/17638.pdf) 4.1.4. Dla domeny platformystartowe.gov.pl wraz z wersją anglojęzyczną startupplatforms.gov.pl, w tym skonfigurowane trzy podstrony dla animatorów platform startowych, (zgodnie z księgą identyfikacji wizualnej Platform Startowych http://www.web.gov.pl/g2/big/2015_11/63b8e70eb1ce3a325aa10f35bca0ae8a.pdf) 4.1.5. Dla modułu społeczności Jomsocial, dostępnego na domenach platformystartowe.gov.pl oraz startup.gov.pl zgodnie z wypracowaną koncepcją graficzną podczas spotkania otwierającego. 4.1.6. Dla strony e-punkt.gov.pl Wykonawca wdroży nową wersję kolorystyczną w przekazanym przez zamawiającego szablonie i wdroży szablon. Strona 3 z 14
4.2. Po opracowaniu projektów graficznych stron Wykonawca przedstawi je do oceny Zamawiającego. Po zatwierdzeniu przez Zamawiającego projektów graficznych stron Wykonawca przystąpi do programowania szablonów graficznych stron a po wykonaniu kolejnych etapów niniejszego zamówienia dokona ich wdrożenia na instancji CMS Joomla. 4.3. Wymagania techniczne szablonu graficznego: 4.3.1. Szablon wykonany zostanie w metodzie Responsive Web Design (RWD), 4.3.2. Wykonawca wdroży responsywność przy użyciu metod CSS (@media) oraz biblioteki PHP umożliwiającej rozpoznanie urządzenia mobilnego (np. http://mobiledetect.net/) celem wyświetlenia adekwatnego widoku menu. 4.3.3. Zastosowany zostanie jeden plik.css zawierający style opisujące warstwę graficzną elementów serwisu, w wersji co najmniej 3.0, 4.3.4. Wykorzystana zostanie technika CSS Sprite do powtarzających się elementów graficznych. 4.3.5. Zamawiający wykona prace z uwzględnieniem Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz. U. 2012 poz. 526 z p. zm.), oraz wytycznych W3C. 5. Etap III Stworzenie nowych instancji Joomla dla stron W ramach etapu III Wykonawca przygotuje 4 odrębne strony internetowe: startup.gov.pl, Startup summit, platformystartowe.gov.pl, e-punkt.gov.pl. 5.1. Startup.gov.pl będzie marką parasolową prezentującą działania polskiej administracji publicznej na rzecz rozwoju przedsiębiorczości startupowej. Portal ma służyć promocji polskiego środowiska startupowego. Jego anglojęzyczna wersja ma za zadanie prezentację i promocję wśród zagranicznych interesariuszy pozytywnego wizerunku polskiego ekosystemu startupowego. Strona wykorzystywać będzie standardową instalację systemu Joomla oraz dodatkowe zaproponowane przez Wykonawcę komponenty umożliwiające realizację: 5.1.1. Strony konferencji Startup Summit (w ramach strony startup.gov.pl), drugiej edycji największej konferencji startupowej organizowanej przesz polską administrację 5.1.2. Strony Katalogu Polskiego Ekosystemu Startupowego (w ramach strony startup.gov.pl), prezentującą bazą podmiotów uczestniczących w ekosystemie startupowym. Wykonawca zaprojektuje lub zaproponuje gotowy komponent, który spełni wymagania dotyczące migracji danych (dopasowanie pól rekordu do przeprowadzenia migracji wskazanych katalogów) opisanych w etapie IV oraz: 5.1.2.1. Będzie umożliwiał tworzenie, odczyt, edycję, kasowanie (CRUD): 5.1.2.1.1. kategorii podmiotów, 5.1.2.1.2. rekordów podmiotu, 5.1.2.1.3. dodatkowych pól (np. lista rozwijalna, radiobutto, checkbox, pole tekstowe itp.) dla rekordu podmiotu z uwzględnieniem kategorii podmiotu, Strona 4 z 14
5.1.2.2. Wprowadzanie i edycje rekordów od frontu w zależności od nadanych uprawnień, 5.1.2.3. Publikowanie i odpublikowanie rekordu, kategorii, 5.1.2.4. Rekord podmiotu składać się powinien z następujących pól: nazwa podmiotu, kategoria podmiotu, województwo, miasto, kod pocztowy, ulica, numer lokalu, strona internetowa, adres e-mail, telefon, profil działalności firmy, rok założenia/rozpoczęcia działalności, opis firmy, kluczowe osoby/osoby zaangażowane. 5.1.2.5. Wykonawca zaproponuje i wdroży mechanizm implementacji tagów, tak by wpisy w katalogu można było powiązać ze sobą, 5.1.2.6. Komponent powinien umożliwiać wyszukiwanie i filtrowanie z pól określonych podczas analizy. 5.1.2.7. Zaprojektowany komponent powinien uwzględniać pełne zarządzanie wpisami od strony panelu administracyjnego, 5.1.2.8. Komponent powinien posiadać co najmniej dwie wersje językowe; polską i angielską w zależności od wyboru języka, wszystkie elementy komponentu powinny być w pełni przetłumaczone, 5.1.3. Newslettera z następującymi funkcjonalnościami: 5.1.3.1. Tworzenie grup/kategorii i umożliwienie wysyłki newslettera do wskazanych grup/kategorii, 5.1.3.2. Przenoszenie subskrybentów pomiędzy grupami, 5.1.3.3. Usuwanie, dodawanie subskrybentów 5.1.3.4. Identyfikowanie subskrybentów nieaktywnych adresy mail z których przychodzą zwrotne odpowiedzi powinny zawierać identyfikację przesłanej odpowiedzi z serwera subskrybenta (itp. nieznany użytkownik, przekroczona quota, host lub domena nieznana itp.), listowanie subskrybentów w podziale na otrzymaną odpowiedź z serwera, możliwość ich usuwania przez administratora w podziale na otrzymaną odpowiedź z serwera. 5.1.3.5. Tworzenie i zarządzanie wysyłanymi newsletterami 5.1.3.6. Eksport i import do i z formatów plików uzgodnionych przez strony subskrybentów poprzez wskazanie grupy/subskrybentów do eksportu, wskazanie grupy do której mają być importowani subskrybenci. 5.1.3.7. Powiązanie z modułem umożliwiającym zbieranie od frontu adresów od użytkowników (w tym możliwość wypisania się użytkownika z newslettera) 5.2. Modułu społeczności, wdrożony na stronach Startup.gov.pl i Platformystartowe.gov.pl w obu wersjach językowych (http://www.jomsocial.com/). Celem funkcjonowania komponentu na stronie jest zintegrowanie środowiska start-upowego, stworzenie społeczności. Komponent został również pomyślany jako miejsce umieszczania wydarzeń, szybkich informacji z odwołaniem do pozostałych elementów witryny, w tym artykułów. Ma umożliwić Strona 5 z 14
prowadzenie dyskusji, dodawanie zdjęć, tworzenie grup dyskusyjnych, tworzenie listy znajomych. 5.2.1. Wykonawca opłaci (koszt nabycia wliczony do oferty) i zintegruje komponent z CMS Joomla, 5.2.2. Dostosuje wygląd komponentu do opracowanej identyfikacji wizualnej, 5.2.3. Logowanie uczestnika do systemu Joomla powinno być jednoznaczne z zalogowaniem się do komponentu społecznościowego, 5.2.4. Społeczność powinna posiadać dwie wersje językowe; polską i angielską, w zależności od wyboru języka, wszystkie elementy komponentu powinny być w pełni przetłumaczone, 5.2.5. Zarządzanie komponentem społeczności odbywać się będzie od strony zaplecza (panel administracyjny CMS Joomla), 5.3. Portalu PlatformyStartowe.gov.pl, skupiającego Pomysłodawców i edukującego ich przed formalnym zgłoszeniem pomysłu w ramach Platform. Aplikowanie do Platform będzie odbywać się w ramach portalu w trzech krokach: Jak to działa (zasady działania Platform Startowych); Wybierz Animatora (dokonanie wyboru Animatora przez Pomysłodawcę); Aplikuj (przesłanie do Animatora wypełnionych danych z formularza dostępnego na stronie). System powinien umożliwiać pozostawienie następujących danych: nazwa Pomysłodawcy oraz wizja i cechy produktu). 5.3.1. Portal jest podzielony na dwie części. 5.3.1.1. Część ogólnodostępna dla zalogowanych i niezalogowanych użytkowników, zarządzana przez Zamawiajacego (strona główna i inne elementy menu, poza podstronami Animatorów) oraz Animatorów (podstrony Animatorów Platform Startowych). W ramach części ogólnodostępnej dostępna będzie społeczność w oparciu o moduł jomsocial w zakresie dostępnym dla wszystkich użytkowników. Użytkownicy zalogowani będą mieli dodatkowo możliwość dostępu do dodawania wpisów w komponencie społecznościowym jomsocial. 5.3.1.2. Część dostępna tylko dla Animatorów platform startowych (podstrony Animatorów: wydzielona część serwisu od frontu, z osobnym menu i dostępem do wydzielonych komponentów/modułów). Animatorzy będą mieli ponadto możliwość tworzenia i zarządzania zamkniętymi grupami dyskusyjnymi w ramach społeczności (np. przyjmowanie uczestników partnerstwa w ramach Platformy Startowej) 5.3.1.3. Portal Platform Startowych opis funkcjonalności 5.3.1.3.1. System CMS oraz układ szablonu powinien umożliwiać swobodne tworzenie kolejnych elementów menu, wraz z możliwością tworzenia kolejnych pozycji submenu, 5.3.1.3.2. Menu w szablonie strony powinno być utworzone za pomocą stosownego modułu, system powinien umożliwiać zastosowanie różnych Strona 6 z 14
menu, na różnych podstronach, w tym zwłaszcza na podstronach stron platform startowych 5.3.1.3.3. Zarządzanie menu strony powinno się odbywać za pomocą stosownych funkcjonalności systemu CMS Joomla, dostępnych w panelu administracyjnym, 5.3.1.3.4. Artykuły opis funkcjonalności: możliwość tworzenia nieograniczonej liczby artykułów przypisanych do menu oraz wskazanych kategorii; możliwość tworzenia listy artykułów, wraz ze systemem stronicowania, widok listy artykułów powinien zawierać lead - wstęp, możliwość dodania obrazka wiodącego oraz przycisk więcej, którego kliknięcie przenosi do artkułu; każdy artykuł powinien zawierać tytuł, wstęp i rozwinięcie treści, autora artykułu; Administrator powinien mieć możliwość: dowolnego definiowania dat początku i końca publikacji artykułu; artykuł powinien zawierać datę utworzenia i datę edycji - tworzone automatycznie; tagowania, tworzenia metaopisów; pokazania w aktualnościach na stronie głównej; każdy artykuł powinien umożliwiać dodawanie obrazków w treści oraz galerii, 5.3.1.3.5. Kategorie: Wykonawca zmodyfikuje CMS Joomla, zastępując dotychczasowy sposób wyświetlania drzewa kategorii na widok, który będzie umożliwiał zwijanie i rozwijanie podkategorii (za pomocą klikniecia w plus/minus). Dotychczasowa funkcjonalność wyszukiwania całości lub części nazwy kategorii po nazwie zostanie utrzymana. 5.3.1.3.6. Wyszukiwarka na stronie. Wykonawca wykona moduł wyszukiwarki w sposób umożliwiający: podpowiadanie fraz wpisywanych w polu wyszukiwarki, wyświetlanie wyników wyszukiwania w formie: filtrowania wyników po: tagu, kategorii artykułu, stron animatorów platform startowych, bazy mentorów, określeniu z poziomu panelu zarządzania sposobu wyszukiwana w poszczególnych wersjach językowych lub we wszystkich wersjach językowych. 5.3.1.3.7. Podstrona Baza Mentorów. 5.3.1.3.7.1. Bazę Mentorów nieaktywne profile społecznościowe mentorów, tworzy Administrator. 5.3.1.3.7.2. Z założenia dostęp do danych mentorów ma być ograniczony. Pełny dostęp posiadać mają tylko osoby pełniące rolę animatorów (administratorów podstron platform startowych). Wykonawca zaprojektuje lub zaproponuje gotowy komponent, spełniający poniższe wymagania: 5.3.1.3.7.2.1. Administrator ma możliwość wyboru, jakie dane będą widoczne dla wszystkich odwiedzających witrynę oraz animatorów, Strona 7 z 14
5.3.1.3.7.2.2. Baza zawierać będzie następujące dane (pola): zdjęcie, imię, nazwisko, stanowisko, dane kontaktowe: telefon, adres (ulica, miejscowość, kod pocztowy, województwo), e-mail, doświadczenie, opis mentora, lista podmiotów z którymi współpracuje mentor (tagi-słowa kluczowe), 5.3.1.3.7.2.3. Baza będzie umożliwiać wyszukiwanie po następujących polach: nazwisko, stanowisko, doświadczenie, opis mentora, lista podmiotów z którymi mentor współpracuje, telefon, e-mail, miejscowość, 5.3.1.3.7.2.4. Baza będzie umożliwiać filtrowanie po następujących polach: przypisanie do Animatora, 5.3.1.3.7.2.5. Administrator powinien mieć możliwość zdefiniowania, które elementy wyszukiwania i filtrowania będą dostępne dla osób przeglądających stronę oraz dla animatorów, 5.3.1.3.7.2.6. Zaprojektowany komponent powinien uwzględniać pełne zarządzanie wpisami od strony panelu administracyjnego, 5.3.1.4. Strony Animatorów Platform Startowych Zgodnie z przyjętym założeniem częścią portalu platformystartowe.gov.pl mają być, zarządzane przez animatorów, strony konkretnych platform. Strona taka, ma się wyróżniać od pozostałej części strony (inny szablon) oraz ma być zarządzana/uzupełniana informacjami przez specjalnych użytkowników animatorów. Wykonawca zaprojektuje takie rozwiązanie, spełniający poniższe wymagania: 5.3.1.4.1. Dane, które mają się znaleźć na stronie są następujące: logotyp, nazwa, opis, adres, telefon, mail, strona internetowa partnerstwa, uczestnicy partnerstwa: mentorzy współpracujący, jednostki samorządu terytorialnego, sektor edukacyjny, IOB, Startupy objęte programem. Wymienieni uczestnicy partnerstwa to jednocześnie linki, umożliwiające wyświetlenie wszystkich informacji na stronie o danym podmiocie. 5.3.1.4.2. Widok od frontu powinien uwzględniać wszystkie wskazane w podpunkcie 5.3.1.4.1 elementy. 5.3.1.4.3. Animator powinien mieć możliwość dodania powyższych elementów lub też ich dodania z Bazy mentorów. 5.3.1.4.4. Animatorzy powinien mieć możliwość: edycji swojej strony Platform Startowych, dostępu do pełnych danych kontaktowych z Bazy mentorów i ich uzupełnienia, 5.4. Portalu e-punkt.gov.pl utworzenie i przygotowanie oddzielnej instancji Joomli do migracji danych opisanych w etapie IV. Strona 8 z 14
6. Etap III Skonfigurowanie i wdrożenie nowej wizualizacji dla portali Startup.gov.pl, Platformystartowe.gov.pl i e-punkt.gov.pl 6.1. Przygotowanie portalu startup.gov.pl, zawierającego podstrony Katalogu Polskiego Ekosystemu Startupowego i konferencji Startup Summit 6.2. Przygotowanie portalu Platform Startowych, 6.3. Przygotowanie portalu Społeczności, dostępnego na stronach startup.gov.pl i platformystartowe.gov.pl 6.4. Wdrożenie nowej wizualizacji dla portalu e-punkt.gov.pl 7. Etap IV Migracja treści oraz użytkowników web.gov.pl na wskazane przez Wykonawcę strony wraz z dostosowaniem lub utworzeniem komponentów umożliwiających przetwarzanie i przedstawianie migrowanych danych. Celem tego etapu jest migracja treści portalu web.gov.pl do systemu CMS Joomla. Migracja obejmie następujące elementy dotychczasowej strony www: Treści z web.gov.pl Platformy startowe.gov.pl Startupplatforms. gov.pl Startup.gov.pl Startup.gov.pl/ENG Katalog ekosystemu Artykuły anglojęzyczne: web.gov.pl/eng Artykuły polskie o tematyce startupowej web.gov.pl/aktualnos ci, web.gov.pl/wiedza/ wywiady_biznes Artykuły polskie o tematyce poradnikowej web.gov.pl/wiedza/ rozwoj/, web.gov.pl/wiedza/ finansowanie Katalog e-usług web.gov.pl/firmy-iuslugi/katalogeuslug/ Artykuły z Biblioteka web.gov.pl/wiedza/ biblioteka Newsletter+ subksrybenci web.gov.pl do modułu newsletter w Joomla Strona 9 z 14
Treści z web.gov.pl Platformy startowe.gov.pl Startupplatforms. gov.pl Startup.gov.pl Startup.gov.pl/ENG Katalog ekosystemu Inkubatory i startupy ze strony web.gov.pl/startup Katalog firm web.gov.pl/firmy-iuslugi/katalog-firm Katalog B2B web.gov.pl/firmy-iuslugi/katalog-b2b Baza wydarzeń z Kalendarium web.gov.pl/aktualnos ci/wydarzenia/ do modułu wydarzeń jomsocial 7.1. Migracja obejmie dotychczasowych użytkowników portalu web.gov.pl z uwzględnieniem następujących zagadnień: 7.1.1. Zachowania identyfikatora logowania użytkownika 7.1.2. Zachowania hasła użytkownika 7.1.3. Zachowania adresu e-mail użytkownika 7.1.4. Zachowanie grupy i uprawnień użytkownika 7.2. Wskazane przez Zamawiającego artykuły z uwzględnieniem zachowania ich przypisania do kategorii obecnego systemu CMS, z zachowaniem wszystkich danych. 7.3. Migrację katalogu: 7.3.1. firm wraz z wszystkimi danymi 7.3.2. e-usług wraz z wszystkimi danymi 7.3.3. B2B wraz z wszystkimi danymi 7.4. Migracja katalogów musi uwzględnić powiązania rekordu z właścicielem rekordu, prawami dostępu do danego rekordu, oraz publikacji na stronie. Wykonawca w Etapie III dostosuje funkcjonalność Katalogu Polskiego Ekosystemu w sposób umożliwiający przeprowadzenie migracji. 7.5. Migracja Newsletter a z uwzględnieniem zachowania dotychczasowego podziału grup użytkowników. 7.6. Migrację wydarzeń/kalendarium. Wykonawca dostosuje funkcjonalność wydarzeń komponentu jomsocial w sposób umożliwiający migracje wszystkich danych oraz spełniający co najmniej te same funkcjonalności obecnego kalendarium. 7.7. Wykonawca opracuje mechanizm zapewniający zachowanie dotychczasowych (funkcjonujących na web.gov.pl) adresów URL, jako aliasów do nowopowstałych adresów Strona 10 z 14
URL Systemu, dostosowanych do zasad SEO oraz mechanizmów wyszukiwania oraz pozycjonowania Google, 8. Etap V Przeprowadzenie testów i odbiór systemu 8.1. Po zakończeniu Etapów I-IV Wykonawca przystąpi do realizacji Etapu V. 8.2. Wykonawca zastosuje system kontroli wersji Subversion (SVN) przy udostępnianiu Zamawiającemu wersji wdrażanego w ramach zamówienia Systemu, uwzględniając następujące zasady: 8.2.1. Wykonawca posługiwał się będzie otrzymanym od Zamawiającego elektronicznym certyfikatem, nazwą użytkownika oraz hasłem do repozytorium SVN, 8.2.2. Wykonawca jest zobowiązany do aktualizacji w repozytorium SVN Zamawiającego kodów źródłowych oraz wszelkich instrukcji SQL tworzonych i aktualizujących strukturę bazy danych, 8.2.3. Wykonawca w trakcie aktualizacji jest zobowiązany do umieszczenia komentarza opisującego powód dokonania aktualizacji i sposób rozwiązania, 8.2.4. Wszelkie umieszczone przez Wykonawcę kody w repozytorium SVN stają się własnością Zamawiającego, 8.2.5. Aktualizację środowiska produkcyjnego dokonuje Zamawiający na podstawie kodów znajdujących się w repozytorium SVN. 8.3. 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żytkownika i nie zawiera błędów uniemożliwiających jego użycie. Wynikiem testów akceptacyjnych jest Protokół Akceptacji Usługi. 8.4. 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: 8.4.1. Przygotowanie planu testów, danych testowych, 8.4.2. Przygotowanie scenariuszy testowych zawierających co najmniej następujące pola dla każdego testowanego przypadku: nazwa przypadku użycia, opis testu, warunki wstępne, procedura testowa, oczekiwane rezultaty. Zamawiający w terminie 2 dni roboczych zaakceptuje lub odrzuci scenariusze testowe. W przypadku odrzucenia Wykonawca zobowiązany jest w przeciągu 2 dni roboczych wprowadzić wszystkie zgłoszone poprawki i ponownie przedstawić scenariusze testów do akceptacji Zamawiającemu. 8.4.3. Dostarczenie arkuszy testowych, 8.4.4. Ładowanie danych testowych zgodnie z zasadami pkt. 6.1, 8.5. Testy akceptacyjne będą składały się z następujących typów testów: 8.5.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 Strona 11 z 14
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, 8.5.2. Testy GUI - sprawdzenie nawigacji w systemie, sprawdzenie poprawności interfejsu względem makiet i widoków stron zatwierdzonych w Etapie I. 8.6. Wykonawca przekaże Zamawiającemu do instalacji System zgodnie z pkt 6.1. 8.7. System zostanie zainstalowany na serwerze testowym Zamawiającego, przy asyście Wykonawcy, gdzie przeprowadzone będą testy akceptacyjne przez obie strony zgodnie z pkt.6.3. Po zakończeniu testów zostanie sporządzony przez Wykonawcę raport zawierający wynik testów. Po zaakceptowaniu Systemu przez Zamawiającego, System zostanie przy asyście Wykonawcy przeniesiony na serwer produkcyjny Zamawiającego. Odbiór Systemu zostanie potwierdzony protokołem odbioru Systemu. 8.8. Wykonawca jest zobowiązany do przekazania dokumentacji Specyfikacji Funkcjonalnej Systemu, w której będą zawarte informacje dotyczące przeprowadzonych prac, zgodnie z pkt. 2.2, uzupełnione o ewentualne poprawki i uzupełnienia powstałe po zakończeniu Etapu V. 8.9. W terminie 2 dni roboczych od zakończenia zadania Wykonawca przedstawi Zamawiającemu raport z realizacji Etapu V. zawierający zgodnie z powyższymi wytycznymi - co najmniej: 8.9.1. Oświadczenie Wykonawcy o przeprowadzeniu testów wewnętrznych zgodnie ze specyfikacją załączoną do oświadczenia. Oświadczenie musi zawierać informacje o wyniku testów; 8.9.2. 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; 8.10. Akceptacja wykonania etapu zostanie potwierdzona protokołem. 9. Etap VI Przygotowanie Dokumentacji Systemu 9.1. Wykonawca jest zobowiązany do dostarczania Zamawiającemu aktualnych źródeł oprogramowania Systemu oraz aktualnej Dokumentacji Systemu przy odbiorze końcowym oraz po każdej modyfikacji Systemu wykonanej przez Wykonawcę w ramach serwisu gwarancyjnego. Dokumentacja Systemu powinna być dostarczona Zamawiającemu w wersji elektronicznej. 9.2. Dokumentacja powinna zawierać co najmniej poniższe obszary: 9.2.1. Kody źródłowe i opis komponentów stworzonych przez Wykonawcę. 9.2.2. Dokumentacja instalacji i konfiguracji Systemu, w szczególności wszystkich użytych komponentów nie wchodzących w skład rdzenia CMS Joomla!. 9.2.3. Instrukcje administracyjne i instrukcje użytkowania wszystkich komponentów stworzonych przez Wykonawcę. 9.3. Zamawiający dopuszcza, w przypadku braku wersji polskojęzycznej, dostarczenie dokumentacji w języku angielskim. Strona 12 z 14
10. Odbiór poszczególnych zadań i przedmiotu zamówienia 10.1. Każdorazowo po zakończeniu prac nad etapem Zamawiający w ciągu 2 dni roboczych zatwierdzi lub odrzuci raport z realizacji, wskazując na przyczyny odrzucenia. 10.2. W sytuacji odrzucenia raportu z etapu Wykonawca zobowiązany jest poprawić wszystkie zgłoszone błędy w raportach i przekazywanych do odbioru produktach umowy wskazane w uwagach Zamawiającego i przedłożyć w ciągu 2 dni roboczych od momentu odrzucenia raportu przez Zamawiającego prawidłowo skonstruowany raport z realizacji etapu. 10.3. Zamawiający zastrzega sobie prawo do wnoszenia kolejnych uwag i zastrzeżeń w terminach wskazanych powyżej w sytuacji, gdy Wykonawca nie uwzględni wszystkich jego uwag i zastrzeżeń zgłoszonych uprzednio. Po zaakceptowaniu raportu przez Zamawiającego obie strony podpiszą protokół wykonania etapu. 10.4. Akceptacja i odbiór przedmiotu umowy odbędzie się poprzez podpisanie przez Strony protokołów wszystkich wskazanych powyżej etapów zamówienia. 10.5. Podstawą do wystawienia faktury będzie Raport Końcowy z wykonania zamówienia, 11. Serwis gwarancyjny Po końcowym odbiorze Systemu, przez okres określony w ofercie, liczony od dnia podpisania raportu końcowego przez Zamawiającego, Wykonawca będzie zobowiązany do zapewnienia serwisu gwarancyjnego. Po końcowym odbiorze Systemu, zostanie wykonana kompletna kopia Systemu, zawierająca pliki konfiguracyjne, kody źródłowe i zrzut bazy danych. 11.1. Specyfikacja serwisu gwarancyjnego: 11.1.1. Przez Wadę należy rozumieć uszkodzenie lub błędne działanie komponentu opracowanego przez Wykonawcę ograniczające wydajność lub funkcjonalność Systemu lub uniemożliwiające Zamawiającemu korzystanie z Systemu oraz niespójność Systemu z Dokumentacją Systemu zgłoszoną Wykonawcy przez Zamawiającego. 11.1.2. Wykonawca gwarantuje Zamawiającemu, że wdrożony do eksploatacji System jest wolny od wad fizycznych oraz sprawny w działaniu, a w szczególności: 11.1.2.1. Zapewnia funkcjonalną zgodność Systemu z dokumentacją, 11.1.2.2. Nie zawiera Wad uniemożliwiających lub ograniczających eksploatację całego oprogramowania wchodzącego w jego skład, wykonanego lub dostarczonego przez Wykonawcę lub posiadanego przez Zamawiającego, 11.1.2.3. Wszelkie usługi instalacyjno-wdrożeniowe zrealizowane przez Wykonawcę są kompletne, poprawne i wykonane zgodnie z dokumentacją techniczną. 11.1.3. W ramach gwarancji Wykonawca zobowiązuje się do nieodpłatnego usuwania Wad w funkcjonowaniu Systemu, zgodnie z procedurami serwisu gwarancyjnego określonymi w punkcie 9.2 niniejszego dokumentu. Strona 13 z 14
11.1.4. Zamawiający ma obowiązek zgłosić Wady objęte gwarancją niezwłocznie po ich wykryciu, do przedstawiciela Wykonawcy. 11.1.5. Termin gwarancji dla Systemu ulega przedłużeniu o czas, w ciągu którego Zamawiający nie mógł korzystać z Systemu. 11.1.6. W wypadku niewywiązywania się Wykonawcy z zobowiązań gwarancyjnych przez czas dłuższy niż 6 dni, Zamawiający ma prawo skorzystać, na koszt Wykonawcy, z usług zastępczych bez utraty prawa gwarancji. 11.2. Procedury serwisu gwarancyjnego: 11.2.1. Interwencja grupy serwisowej następuje na podstawie zgłoszeń Zamawiającego: pocztą e-mail, telefonicznych (potwierdzonych e-mail) lub systemem raportowania błędów Zamawiającego. Zamawiający zastrzega sobie możliwość wskazania oraz wykorzystania w procesie testowania i przekazywania Wykonawcy informacji o błędach własnego systemu do zarządzania testami a także systemu zgłaszania i śledzenia błędów. 11.2.2. Usunięcie Wady wraz z odtworzeniem danych nastąpi zgodnie z zasadami opisanymi w pkt. 6.1. 11.2.3. Usunięcie Wady nastąpi w ciągu 3 dni roboczych od zgłoszenia przez Zamawiającego. 11.2.4. Przeprowadzenie testów i/lub innych czynności sprawdzających poprawność działania Systemu po dokonaniu naprawy, zgodnie z pkt. 6.5 i 6.6. 11.2.5. Wykonawca niezwłocznie po usunięciu Wady sporządzi protokół usunięcia Wady, w którym określi przyczyny wystąpienia oraz procedurę usunięcia Wady i przywrócenia prawidłowego stanu Systemu. 11.2.6. Uaktualnianie Dokumentacji Systemu po interwencji serwisowej w terminie do 5 dni roboczych od zakończenia interwencji, w sytuacjach w których potrzeba aktualizacji dokumentacji została zgłoszona przez Zamawiającego. 11.2.7. Aktualizowanie kodu Systemu (za pośrednictwem SVN) o usprawnienia, aktualizacje i poprawki oraz przekazanie o tym informacji do Zamawiającego. 11.3. Koszt usługi serwisu gwarancyjnego będzie wliczony do oferty cenowej i nieobjęty dodatkowymi opłatami ze strony Zamawiającego. Strona 14 z 14