SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA

Załącznik nr 1 do umowy nr z dnia. 2014 r. SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA pn Zaprojektowanie i wdrożenie narzędzia informatycznego do zarządzania systemem monitorowania polityk publicznych w województwie lubuskim - portal internetowy wraz z bazą danych regionalnych Spis treści 1. Wstęp... 3 2. Słownik pojęć i akronimów... 3 3. Cel portalu... 5 4. Opis przedmiotu zamówienia... 6 4.1 Opis ogólny... 6 4.2 Koncepcja systemu... 7 4.3 Architektura systemu... 7 4.4 Podstawowe funkcjonalności... 8 4.4.1 Strona główna (startowa)... 8 4.4.2 Aktualności... 8 4.4.3 Archiwum wiadomości... 8 4.4.4 O nas... 9 4.4.5 Formularz kontaktowy... 9 4.4.6 Newsletter... 9 4.4.7 Wyszukiwanie... 9 4.4.8 Obszary monitorowania... 10 4.4.9 Mapa strony... 11 4.4.10 Pomoc... 11 4.5 Funkcjonalności bazy danych regionalnych... 11 4.5.1 Interfejs użytkownika... 11 4.5.2 Wyświetlanie tabel... 12 4.5.3 Wyświetlanie wykresów... 13 4.5.4 Wyświetlanie map... 13 4.5.5 Raport... 13 4.5.6 Wydruk i eksport... 14 4.5.7 Pomoc... 14 4.5.8 Wymagana funkcjonalność... 14 4.6 Podstawowe wymagania techniczne... 15 4.6.1 Część publiczna... 15 4.6.2 Część niepubliczna... 16 4.7 Wymagania w zakresie CMS (Content Management System)... 16 4.7.1 Wymagane cechy systemu CMS... 16 4.7.2 Zarządzanie menu... 17 4.7.3 Zarządzanie artykułami... 18 4.7.4 Bezpieczeństwo i zarządzanie uprawnieniami... 19 4.8 Prezentacja treści... 20 4.9 Nazewnictwo i język... 20 4.10 Nawigacja... 21 4.11 Zgodność i kompatybilność... 21 5. Testy akceptacyjne... 21 6. Prawa autorskie i licencja... 22 1

7. Gwarancja... 22 8. Wymagania dotyczące serwera... 22 9. Planowanie rozszerzenia funkcjonalności... 23 10. Dokumentacja... 23 10.1 Specyfikacja techniczna portalu... 23 10.2 Dokumentacja administratora... 23 10.3 Dokumentacja użytkowników... 24 10.4 Kody źródłowe i ich dokumentacja... 24 11. Szkolenie... 24 12. Wymagane elementy graficzne... 25 13. Harmonogram etapy realizacji przedmiotu zamówienia... 27 2

1. Wstęp Zamówienie dotyczy wykonania i wdrożenia internetowego narzędzia informatycznego w formie portalu internetowego, służącego do zarządzania systemem monitorowania polityk publicznych w województwie lubuskim, oferującego ogólnodostępną bazę danych. Wykonanie systemu wiązać się będzie z jednorazową płatnością (na rzecz Wykonawcy) za wykonanie przedmiotowego zadania i nie będzie wymagało innych wydatków z tytułu opłat licencyjnych lub ilości użytkowników systemu. Zadanie zostanie zrealizowane w ramach projektu pn. Wdrożenie systemu monitorowania polityk publicznych w województwie lubuskim poprzez budowę Lubuskiego Regionalnego Obserwatorium Terytorialnego współfinansowanego ze środków Europejskiego Funduszu Społecznego realizowanego w ramach poddziałania 5.2.1 PO KL. Portal będzie funkcjonował pod nazwą Lubuskie Regionalne Obserwatorium Terytorialne (LROT) - www.obserwuj.lubuskie.pl. 2. Słownik pojęć i akronimów Architektura informacji Błąd krytyczny Błąd systemowy CMS Data wdrożenia systemu Format XXX, plik XXX Interfejs użytkownika Zakres, uporządkowanie i powiązanie informacji w systemie informacyjnym Przez błąd krytyczny rozumie się brak ładowania portalu internetowego (nie można wejść na stronę portalu internetowego). Przez błąd systemowy rozumie się błędy w prezentacji i funkcjonowaniu portalu internetowego. ang. Content Management System (pol. System Zarządzania Treścią). Aplikacja internetowa lub ich zestaw, umożliwiająca utworzenie serwisu WWW. oraz jego późniejszą aktualizację dotyczącą zakresu i organizacji treści, a także rozbudowę przez redakcyjny personel techniczny. Kształtowanie treści i sposobu ich prezentacji w serwisie zarządzanym przez CMS odbywa się za pomocą prostych (niewymagających specjalistycznej wiedzy informatycznej) w obsłudze interfejsów użytkownika, zazwyczaj w postaci stron WWW. zawierających rozbudowane formularze i moduły. 1 Data podpisania przez Zamawiającego i Wykonawcę protokołu odbioru poprawnie zrealizowanego Zamówienia Pojęcia format i plik są tutaj tożsame i oznaczają grupy plików o podobnych właściwościach, np.: XLS to pliki arkusza kalkulacyjnego (MS Office Excel), które mogą mieć rozszerzenia m.in.:.xls,.xlsx,.xlsb,.ods. Analogicznie, DOC to pliki edytora tekstu (MS Office Word) -.doc,.docx,.odt. Część oprogramowania odpowiadająca za interakcję między aplikacją i użytkownikiem: a) interfejs graficzny interfejs użytkownika komunikujący stan programu w postaci graficznej na ekranie (lub wyświetlaczu), który jako wejście wykorzystuje urządzenie wskazujące (myszkę, touchpad, tablet, dżojstik itp.) i klawiaturę, b) interfejs tekstowy interfejs użytkownika komunikujący stan aplikacji w postaci znaków na ekranie (lub wyświetlaczu), wykorzystujący jako urządzenie wejściowe tylko klawiaturę, c) interfejs strony internetowej wejście i wyjście jest realizowane poprzez stronę internetową wyświetlaną w przeglądarce internetowej. 2 1 SOPZ dot. wykonania i wdrożenia internetowego narzędzia informatycznego służącego monitorowaniu realizacji Strategii Województwa Podkarpackiego na lata 2007-2020 oraz zmian społeczno-gospodarczych zachodzących w województwie podkarpackim. 2 http://pl.wikipedia.org/wiki/interfejs_u%c5%bcytkownika, dostęp 2014-03-11 3

Kartodiagram Mapa tematyczna przedstawiająca zmienność wybranych atrybutów obiektów przestrzennych za pomocą umieszczonych na niej diagramów lub wykresów. Ich lokalizacja odpowiada punktom pomiaru lub jednostkom przestrzennym, do których dane się odnoszą (np. gminom, województwom, państwom). 3 Kartogram Wykres przedstawiający terytorialne rozmieszczenie badanych zjawisk lub zbiorowości statystycznych, stosowany przede wszystkim do prezentacji wielkości i natężenia danego zjawiska lub zbiorowości statystycznej w wyodrębnionych jednostkach terytorialnych. Podstawą budowy kartogramu są kontury map. 4 LROT Lubuskie Regionalne Obserwatorium Terytorialne Metadane Zestaw logicznie powiązanych z dokumentem elektronicznym usystematyzowanych informacji opisujących ten dokument, ułatwiających jego wyszukiwanie, kontrolę, zrozumienie i długotrwałe przechowanie oraz zarządzanie. 1 Moduł Newsletter Oprogramowanie standardowe Portal Produkt końcowy Przyjazne adresy internetowe Redaktor Responsive Web Design RSS/Atom SEO SSL Część systemu, która cechuje się wyodrębnionym zestawem funkcjonalności. Wiadomości przesyłane za pomocą określonego kanału komunikacji do zdefiniowanej grupy odbiorców, np.: wiadomości email. Oprogramowanie powszechnie dostępne o charakterze komercyjnym lub dostępne na warunkach licencji publicznych. 1 ang. Website. Rodzaj serwisu informacyjnego, dla którego nośnikiem jest Internet. Serwisy poza treścią statyczną posiadają sekcję wiadomości, możliwość logowania się, a także zapamiętywania preferencji odbiorców w celu dostosowania treści do indywidualnych upodobań. Serwis może posiadać obiekty interaktywne np.: formularze, przyciski. Dla zarejestrowanych użytkowników mogą być dostępne dodatkowe usługi lub usługi o wyższej jakości, niż dla użytkowników niezarejestrowanych. Użytkownik korzystający z portalu ma możliwość skorzystania z ogólnej bazy informacji oraz funkcji, uzyskuje możliwość sprawnego dotarcia do szczegółowych informacji z wąskich dziedzin poprzez wykorzystanie katalogów stron tematycznych. 1 Dostarczony do Zamawiającego produkt, będący wynikiem poprawnie zrealizowanego zamówienia. 1 Adresy internetowe formułowane w sposób jasny i czytelny dzięki eliminacji lub konwersji niezrozumiałych parametrów z odnośników URL. Osoba zarządzająca treścią, posiadająca uprawnienia nadawane mu indywidualnie przez administratora systemu. Technika projektowania strony WWW, tak aby jej wygląd i układ dostosowywał się automatycznie do rozmiaru okna przeglądarki. 5 Umowna rodzina języków znacznikowych do przesyłania nagłówków wiadomości i nowości na wybranych przez użytkownika RSS stronach. 6 ang. Search Engine Optimization. Działania zmierzające do osiągnięcia przez serwis internetowy jak najwyższej pozycji w wynikach wyszukiwania wyszukiwarek internetowych dla wybranych słów i wyrażeń kluczowych. 1 ang. Secure Socket Layer. Protokół (typu klient-serwer) pozwalający na nawiązanie bezpiecznego połączenia poprzez umożliwienie zaszyfrowanego strumienia danych. 1 3 http://pl.wikipedia.org/wiki/kartodiagram, dostęp 2014-03-11 4 http://www.stat.gov.pl/gus/definicje_plk_html.htm?id=poj-7227.htm, dostęp 2014-03-11 5 http://pl.wikipedia.org/wiki/responsive_web_design, dostęp 2014-03-11 6 http://pl.wikipedia.org/wiki/rss, dostęp 2014-03-11 4

System UMWL Wsparcie techniczne WYSIWYG Zamawiający Narzędzie informatyczne służące zarządzaniu systemem monitorowania polityk publicznych w województwie lubuskim i oferujące ogólnodostępną bazę danych. Urząd Marszałkowski Województwa Lubuskiego Gwarantowana pomoc Wykonawcy w zakresie eksploatacji portalu oraz jego obsługi przez administratora. ang. What You See Is What You Get (pol. To Co Widzisz Jest Tym, Co Otrzymasz). Akronim stosowany w informatyce w celu określenia narzędzi programistycznych lub edycyjnych, pozwalających uzyskać wynik publikacji identyczny lub bardzo zbliżony do obrazu na ekranie. 1 Województwo Lubuskie, Urząd Marszałkowski Województwa Lubuskiego w Zielonej Górze, ul. Podgórna 7, 65-057 Zielona Góra, NIP: 973-05-90-332, REGON: 970770089. 3. Cel portalu Rozwój regionu obejmuje szereg polityk publicznych wymagających monitorowania, co wiąże się z pozyskiwaniem i przetwarzaniem dużej ilości danych. Dużą barierą w pozyskiwaniu szerokiej wiedzy o regionie, zarówno jako całości, jak i w poszczególnych dziedzinach rozwoju jest rozproszenie źródeł informacji. Wobec czego podstawowym celem portalu jest funkcja informacyjna, która będzie możliwa dzięki zintegrowaniu rozproszonych źródeł informacji. Portal będzie narzędziem umożliwiającym: gromadzenie, udostępnianie i prezentację wskaźników monitorowania polityk publicznych w województwie, systematyczną obserwację rozwoju województwa, w szczególności zjawisk społecznogospodarczych, odpowiednią prezentację danych przez zastosowanie dynamicznych metod graficznych w sieci Internet. Głównym elementem portalu, służącym do zarządzania systemem monitorowania polityk publicznych w województwie, będzie baza danych regionalnych, gromadząca informacje statystyczne, istotne z punktu widzenia wdrażanych polityk publicznych, zgodnie z obszarami monitorowania określonymi przez Zamawiającego (załącznik nr 1 do SOPZ). Informacje zawarte w bazie danych regionalnych mają za zadanie ułatwić monitoring polityk publicznych w określonych obszarach monitorowania, ze szczególnym uwzględnieniem zmian społeczno-gospodarczych zachodzących w województwie oraz pozwolić na szybką i sprawną diagnozę. W ramach portalu zostaną udostępnione interaktywne mechanizmy, pozwalające na sprawną analizę zgromadzonych danych. Adresatami portalu są wszyscy zainteresowani rozwojem regionu i poszukujący wiedzy o województwie lubuskim, zwłaszcza: zarząd województwa, sejmik, departamenty UMWL i jednostki organizacyjnie podległe, instytucje zewnętrzne (pracownicy administracji publicznej), przedsiębiorcy, sektor nauki, studenci, uczniowie, mieszkańcy regionu, itd. 5

4. Opis przedmiotu zamówienia 4.1 Opis ogólny Głównym przedmiotem zamówienia jest budowa narzędzia informatycznego umożliwiającego zarządzanie systemem monitorowania polityk publicznych. Narzędzie składać się będzie z dostępnego publicznie portalu internetowego zwierającego bazy danych LROT. Oparty on będzie na systemie zarządzania treścią Content Management System (CMS) oraz na aplikacji internetowej pozwalającej na pobieranie i podgląd pewnych danych składowanych w relacyjnej bazie danych w standardzie SQL. Ponadto za przedmiot zamówienia uważa się opracowanie projektu graficznego portalu i wsparcie Zamawiającego w zakresie jego użytkowania w okresie 1 roku (wsparcie techniczne) od daty wdrożenia systemu. W skład usługi wejdzie również przeszkolenie pracowników UMWL do jego obsługi. Zobowiązanie Wykonawcy dotyczy w szczególności: 1) zaprojektowania portalu CMS narzędzia informatycznego do prezentowania informacji z zakresu monitorowania polityk publicznych w województwie lubuskim, 2) zaprojektowanie i zintegrowanie z portalem CMS bazy danych regionalnych umożliwiającej prezentację danych statystycznych za pomocą tabel, wykresów, map opartych na kartogramach, kartodiagramach, wartościach liczbowych, 3) opracowania struktury portalu (topografia stron i podstron) na podstawie zapisów niniejszego dokumentu oraz załącznika nr 1 do SOPZ, 4) zaprezentowania ilości podstron, zaprezentowania układu porządkowego strony i podstron, zaprezentowania układu stron (kolumny, kolumny boczne, banery górne i boczne, menu, treści), 5) przygotowania szablonu graficznego portalu spójnego z obszarem merytorycznym oraz wytycznymi zawartymi w punkcie 12 (Wymagane elementy graficzne) niniejszego dokumentu, 6) wdrożenia zaprojektowanych elementów portalu, 7) przeprowadzenia szkoleń dla zespołu administrującego (2 osoby) oraz dla użytkowników systemu (7 redaktorów CMS), 8) przygotowania instrukcji obsługi dla administratorów i redaktorów CMS, 9) przygotowania dokumentacji instalacji oraz dokumentacji administratora, 10) przygotowanie wszystkich kodów źródłowych wraz z dokumentacją, 11) świadczenia usług gwarancyjnych, wsparcia technicznego oraz serwisu w okresie minimum 1 roku od daty wdrożenia systemu (liczonej od dnia podpisania przez Zamawiającego i Wykonawcę protokołu odbioru poprawnie zrealizowanego Zamówienia), 12) świadczenie usługi udostępniania produktu końcowego na wynajmowanym lub własnym serwerze (hostowanie) przez co najmniej 1 rok od daty wdrożenia systemu. 6

4.2 Koncepcja systemu Zakres merytoryczny systemu zrealizowany zostanie z uwzględnieniem zapisów w załączniku numer 1 do SOPZ. Koncepcja systemu musi zabezpieczać wymagania Zamawiającego tzn.: 1) portal będzie służyć jako centralny punkt składowania i przetwarzania danych statystycznych pochodzących z rożnych źródeł. Dane te będą importowane do systemu za pomocą pliku w formacie XLS. Dokładna specyfikacja formatu zostanie ustalona wspólnie przez Zamawiającego i Wykonawcę; 2) umożliwi przetwarzanie danych przez zastosowanie metod graficznej prezentacji danych; 3) będzie pełnić funkcję informacyjną, treść będzie uzupełniana przez Zamawiającego. Dla potrzeb systemu należy stworzyć elektroniczną bazę danych, składającą się z: 1) części niejawnej, panelu administracyjnego (dostępnego tylko dla Zamawiającego), przeznaczonej do gromadzenia informacji zawierających dane o wskaźnikach statycznych oraz bieżącej aktualizacji tych wskaźników. Zamawiający udostępni Wykonawcy w trakcie realizacji Zamówienia wskaźniki statystyczne w formacie XLS. Podział terytorialny zostanie ograniczony do prezentacji na poziomie kraju (z podziałem na województwa) oraz województwa (z podziałem na podregiony, powiaty i gminy tylko dla województwa lubuskiego), z tym, że Wykonawca zbuduje system w taki sposób, aby poziomy: podregiony, powiaty, gminy były niewidoczne (ukryte) dla odbiorcy portalu do momentu, aż administrator zasili te poziomy odpowiednimi danymi. Dodanie przez administratora zarówno poziomów podregiony, powiaty, jak i gminy będzie możliwe za pomocą systemu CMS bez znajomości języków programowania. Każdy z poziomów będzie mógł być włączony w dowolnym czasie; 2) części publicznej, zawierającej dane dostępne dla zainteresowanych za pośrednictwem strony WWW. Dane będą prezentowane za pomocą tabel, wykresów, kartogramów, kartodiagramów. System umożliwi nawigację pomiędzy latami, jakich dotyczą prezentowane wskaźniki oraz pomiędzy obszarami monitorowania polityk. System umożliwi również eksport danych z tabel do arkusza kalkulacyjnego Microsoft Excel (XLS), generowanie wykresów oraz kartogramów i kartodiagramów (PNG, JPG oraz PDF) oraz tworzenie raportów w formacie PDF. Ponadto należy dostarczyć system CMS umożliwiający zarządzanie treścią w serwisie bez konieczności znajomości języków programowania. System CMS powinien składać się z części niejawnej pozwalającej autoryzowanym użytkownikom na redagowanie i dodawanie treści oraz z części publicznej prezentującej opublikowane treści. Na tej podstawie Wykonawca w uzgodnieniu z Zamawiającym przygotuje szczegółową specyfikację techniczną portalu (patrz punkt 10.1), której jednym z elementów będzie uszczegółowiona koncepcja systemu. 4.3 Architektura systemu System będzie składał się z portalu CMS oraz z bazy danych regionalnych dostępnej poprzez WWW. Zamawiający oczekuje, że portal zostanie zbudowany w oparciu o architekturę trójwarstwową: 1) warstwa danych, 2) warstwa logiki (aplikacji), 3) warstwa prezentacyjna. 7

4.4 Podstawowe funkcjonalności Wykonawca jest zobowiązany do zaprojektowania i wdrożenia funkcjonalności serwisu, o których mowa w kolejnych podpunktach punktu 4.4 oraz w punkcie 4.5, przy zaznaczeniu, iż jest to zakres minimum. Oczekuje się, iż Wykonawca na etapie sporządzania szczegółowej specyfikacji technicznej (o której mowa w punkcie 10.1), zaproponuje zgodnie ze współczesną wiedzą techniczną oraz doświadczeniem niezbędne dodatkowe funkcjonalności, które będą podlegać akceptacji Zamawiającego. Opracowując funkcjonalności portalu Wykonawca może posiłkować się takimi serwisami jak: www.trendyrozwojowemazowsza.pl, http://www.innowacje.lubuskie.pl, www.monitoruj.podkarpackie.pl. Dopuszcza się, aby Wykonawca proponował kolejne funkcjonalności również w późniejszych etapach realizacji zamówienia bez zwiększenia wartości przedmiotu zamówienia. Będą one także podlegać akceptacji Zamawiającego. Oczekuje się, że struktura portalu będzie odzwierciedlać obszary monitorowania polityk publicznych w województwie lubuskim. Istotne jest, aby wszystkie obszary monitorowania były dostępne bezpośrednio z każdej strony portalu CMS. Należy to rozumieć w ten sposób, że wszystkie obszary monitorowania muszą być wymienione na stronie głównej oraz na wszystkich podstronach systemu CMS a kliknięcie na dowolnym z nich musi prowadzić do podstrony jemu dedykowanej. Zakłada się, że portal zawierał będzie 11 obszarów monitorowania, jednakże liczba obszarów może ulegać zmianie, tak więc budowa systemu musi uwzględniać możliwość edytowania, usuwania oraz dodawania obszarów monitorowania przez administratora portalu bez znajomości języków programowania. Portal musi spełniać wszystkie wymagania ustawowe obowiązujące na dzień jego wdrożenia. Analiza i spełnienie tych wymagań należy do Wykonawcy. 4.4.1 Strona główna (startowa) Na stronie głównej portalu powinny znaleźć się wszystkie obszary monitorowania oraz elementy (moduły) opisane w kolejnych podpunktach. System CMS powinien umożliwiać administratorom edycję, usuwanie i dodawanie nowych elementów. 4.4.2 Aktualności Wiadomości powinny być prezentowane na liście zawierającej temat, datę udostępnienia, autora wiadomości oraz wprowadzenie. Po kliknięciu tematu lub wprowadzenia do wiadomości serwis musi prezentować pełną treść wiadomości. Publikacja aktualnych widomości musi być możliwa w dwóch odsłonach: 1) Skrót informacji wraz z fotografią 2) Pełna treść informacji wraz ze zdjęciami, plikami do pobrania, tabelami, filmami, nagraniami dźwiękowymi, galeriami, itp. 4.4.3 Archiwum wiadomości System musi umożliwiać przenoszenie starszych wiadomości do archiwum, dzięki czemu moduł Aktualności będzie przejrzysty i aktualny dla użytkownika. Moduł archiwum będzie zawierał wszystkie publikowane wiadomości. Powinny być one prezentowane w taki sam sposób jak w module Aktualności. 8

4.4.4 O nas Strona zawierająca opis Lubuskiego Regionalnego Obserwatorium Terytorialnego i projektu, w ramach którego tworzony jest portal. 4.4.5 Formularz kontaktowy Istotnym elementem portalu jest m.in. możliwość kontaktu z zespołem obsługującym portal dla użytkowników chcących rozszerzyć zakres uzyskiwanych informacji lub zgłosić uwagi dotyczące samych wskaźników jak również proponowanych usprawnień w działalności portalu. Formularz kontaktowy powinien zawierać: 1) listę tematów (konfigurowaną przez administratora), 2) pole do wprowadzenia adresu email, 3) pole do wprowadzenia tekstu wiadomości, 4) mechanizm zabezpieczający przed spamem. 4.4.6 Newsletter Na potrzeby portalu zostanie zaprojektowany newsletter administrowany przez Zamawiającego umożliwiający powiadamianie zapisanych użytkowników o aktualnościach z życia portalu. Administrator musi mieć możliwość tworzenia wiadomości za pomocą wcześniej zdefiniowanych szablonów. Rejestracja do newslettera przez użytkownika będzie wymagać wpisania adresu e-mail do aktywnego formularza na stronie głównej portalu. Ponadto wysyłane wiadomości muszą zawierać informację oraz link umożliwiający wypisanie się z newslettera Panel administracyjny newslettera umożliwi: 1) wyświetlenie bazy zapisanych użytkowników, 2) edycję adresu e-mail zapisanego użytkownika, 3) usunięcie e-maila zapisanego użytkownika, 4) edycję szablonów, 5) wysyłanie newsletterów. 4.4.7 Wyszukiwanie Serwis musi posiadać wyszukiwarkę, która umożliwi wyszukanie oraz sortowanie (np. po nazwie, po dacie) informacji dostępnych w serwisie według kryteriów podanych przez użytkownika. Wyniki wyszukiwania muszą być prezentowane w formie listy zawierającej: 1) tytuł strony lub artykułu, lub nazwę pliku, 2) fragment tekstu w którym znaleziono dopasowanie lub streszczenie artykułu, lub opis pliku z zaznaczeniem słów dzięki którym znaleziono dopasowanie, 3) link prowadzący do podstrony prezentującej znaleziony wynik. System musi posiadać możliwość optymalizacji każdej strony serwisu pod kątem wyszukiwania (SEO) poprzez przypisywanie indywidualnych słów kluczowych i opisu stron. Wyszukiwarka treści powinna być dostępna w formie: 1) prostej umożliwiającej przeszukiwanie tytułów, streszczeń oraz metadanych dokumentów, 2) prostej pełnotekstowej umożliwiającej przeszukiwanie jak wyżej oraz pełnych tekstów artykułów, zawartości załączników w formacie co najmniej DOC oraz elektroniczny PDF, 9

3) zaawansowanej umożliwiającej określenie dokładnych kryteriów wyszukiwania: a) wyszukiwanie pełnotekstowe lub po tytułach i skrótach, b) przedział czasowy publikowanych treści, c) rodzaj publikowanych treści (np.: artykuły, pliki DOC, PDF, graficzne, etc.), d) dział tematyczny portalu (np.: obszary monitorowania). Ze względu na możliwość wyszukiwania pełnotekstowego w załączonych do artykułów dokumentach, wymaga się, aby system indeksował zawartość tych plików w celu przyspieszenia późniejszego ich przeszukiwania. Działanie takie pozwoli uchronić system przed nadmiernym obciążeniem i długimi czasami wyszukiwania w miarę działania portalu i zwiększania się liczby załączonych dokumentów. 4.4.8 Obszary monitorowania Każdy obszar monitorowania zawierał będzie takie same elementy: Baza Danych Regionalnych, Baza instytucji, Biblioteka monitoringu, Archiwum aktualności. Nowo tworzone obszary monitorowania powinny odzwierciedlać tą strukturę. 1) Aktualności Funkcjonalność taka jak w punkcie 4.4.2, wyświetlane są tylko aktualności powiązane z wybranym obszarem monitorowania. 2) Baza Danych Regionalnych patrz punkt 4.5 3) Biblioteka monitoringu Funkcjonalność ta zawierać będzie pliki do pobrania przez użytkowników - dokumenty strategiczne, opracowania, analizy, raporty, inne. Administrator będzie miał możliwość przypisania zasobów do obszarów monitorowania. Pliki powinny mieć możliwość pogrupowania w katalogi tematycznie z hierarchią co najmniej 5-cio poziomową. Po otwarciu biblioteki pierwszy poziom powinien być rozwinięty, pozostałe zwinięte. Każdy wpis pliku powinien posiadać tytuł, opis oraz adres do pobrania pliku. Biblioteka zawierać będzie dwa typy odnośników: a) linki do dokumentów wewnętrznych (sporządzonych w ramach Urzędu Marszałkowskiego Województwa Lubuskiego) - oznaczone specjalną ikoną i krótkim opisem, b) linki do dokumentów zewnętrznych (materiałów i zasobów bazodanowych publikowanych przez inne podmioty niż Urząd Marszałkowski Województwa Lubuskiego) - oznaczone inną/innymi ikoną/ikonami odpowiednią/odpowiednimi dla podmiotu publikującego lub pewną generyczną ikoną oraz opisem linku wraz ze wskazaniem źródła. 4) Baza instytucji Funkcjonalność ta zawierać będzie zestaw banerów instytucji posiadających zasoby informacyjne lub/i kompetencje w zakresie, jaki stanowią obszary monitorowania. Kliknięcie banera spowoduje przekierowanie użytkownika portalu do strony internetowej odpowiedniej instytucji. Administrator będzie miał możliwość przypisania banerów do obszarów monitorowania. 5) Archiwum wiadomości Funkcjonalność taka jak w punkcie 4.4.3, wyświetlane są tylko artykuły powiązane z wybranym obszarem monitorowania. 10

4.4.9 Mapa strony Podstrona ta powinna pokazywać automatycznie generowaną mapę portalu. 4.4.10 Pomoc Podstrona ta powinna zawierać informacje dla odwiedzających, w jaki sposób mogą korzystać z portalu oraz z bazy danych regionalnych. W tym miejscu powinna być opisana cała funkcjonalność bazy danych regionalnych wraz z zrzutami ekranów i stosownymi objaśnieniami tak, aby użytkownik niezaznajomiony z portalem był w stanie pobrać z systemu dane w dowolnej postaci (eksport do pliku, tabela, wykres, mapa). Pomoc powinna być dostępna za pomocą jednego kliknięcia z każdej strony portalu. Wypełnienie pomocy stosowną treścią oraz zrzutami ekranów jest zadaniem Wykonawcy. Wykonawca przygotuje dodatkową pomoc dla użytkowników regionalnej bazy danych w formie filmów bądź animacji prezentujących krok po kroku następujące funkcjonalności: a) wyświetlenie kilku wskaźników w zestawieniu rocznym w osobnych tabelach (każdy wskaźnik w osobnej tabeli), b) wyświetlenie wskaźnika w zestawieniu rocznym w postaci tabeli oraz wykresu, c) wyświetlenie zestawienia kilku wskaźników w postaci tabeli oraz wykresu, d) wyświetlenie zestawienia kilku wskaźników w zestawieniu rocznym w postaci tabeli, e) wyświetlenie 3 wskaźników w postaci mapy, f) wygenerowanie raportu zawierającego tabelę, wykres, lub mapę oraz metryczkę wskaźnika, g) wyeksportowanie danych do pliku XLS. 4.5 Funkcjonalności bazy danych regionalnych Baza danych regionu obejmująca poszczególne obszary monitorowania wyznaczone na podstawie załącznika nr 1 do SOPZ. Moduł stanowić ma bazę danych zgromadzonych przez LROT i dostępny będzie z poziomu przeglądarki internetowej. Główną cechą bazy danych regionalnych będzie zapewnienie spójnego źródła danych statystycznych do udostępniania, tzn. będzie ona stanowić hurtownię danych zorientowanych tematycznie. Zasilanie danymi oraz ich aktualizacja będzie się odbywać z poziomu administratora systemu poprzez import danych przygotowanych w formacie XLS. 4.5.1 Interfejs użytkownika 1) Okno wskaźników: jego elementy będą miały strukturę drzewa co najmniej dwupoziomowego (obszar monitorowania i należące do niego wskaźniki). Gałąź obecnego obszaru monitorowania ma być rozwinięta, a pozostałe gałęzie zwinięte istotne jest, aby wyróżnić obecnie wybrany obszar monitorowania ale jednocześnie umożliwić dodawanie wskaźników z innych obszarów. Okno musi posiadać funkcję minimalizacji np. zwinięcie do krawędzi ekranu. 2) Użytkownik musi mieć możliwość zaznaczenia dowolnej liczby wskaźników, wszystkich wskaźników dowolnych obszarów monitorowania lub wszystkich dostępnych wskaźników za pomocą pojedynczego kliknięcia myszą. 3) Użytkownik musi mieć możliwość łatwego i szybkiego zobaczenia metryczki wskaźnika. Proponowane jest wyświetlenie podpowiedzi w dymku lub nowym oknie po kliknięciu specjalnej 11

ikony przy nazwie wskaźnika. Użytkownik powinien mieć również możliwość wydruku oraz dodania do raportu wybranej metryczki. 4) Użytkownik musi mieć możliwość zaznaczenia pojedynczego roku, zakresu lat, lub dowolnie wybranych lat w celu prezentacji danych. Okno musi posiadać funkcję minimalizacji np. zwinięcie do krawędzi ekranu. 5) Okno podział administracyjny okno to będzie miało, podobnie jak okno wskaźników, strukturę drzewa. Poziom pierwszy będzie zawierał wszystkie 16 województw. Kolejne poziomy będą dostępne tylko dla województwa lubuskiego i będą prezentować lubuskie podregiony, powiaty i gminy po włączeniu ich przez administratora. Okno musi posiadać funkcję minimalizacji np. zwinięcie do krawędzi ekranu. 6) Użytkownik musi mieć możliwość zaznaczenia dowolnej liczby podregionów i powiatów (gmin, jeśli dostępne) w województwie lubuskim, wszystkich gmin w danym powiecie (jeśli dostępne), wszystkich podregionów i powiatów w województwie lubuskim, dowolnej liczby województw oraz całego kraju. 7) Okno prezentacyjne: umieszczone w centralnej części interfejsu, prezentować będzie w zależności od wybranej opcji: a) tabelę - wyświetlenie wybranych wskaźników w formie tabeli, b) wykres - wyświetlenie wybranych wskaźników w formie wykresu, c) mapę - wyświetlenie wybranych wskaźników w formie mapy, d) raport wyświetlenie w jednym widoku raportu składającego się z elementów dodanych do raportu. Wyżej wymienione elementy będą pojawiać się w oknie prezentacyjnym dynamicznie, tzn.: natychmiast po wybraniu koniecznych atrybutów bez ręcznego odświeżania widoku, każda zmiana będzie automatycznie rejestrowana i wyświetlana. 8) Użytkownik powinien być informowany gdy dla danej konfiguracji atrybutów (wskaźnik + rok + obszar) nie są dostępne żadne dane, lub gdy jeden z atrybutów nie został określony. 9) Interfejs użytkownika powinien być wyposażony w pomoc kontekstową - po wskazaniu myszą okien z atrybutami oraz na wszystkich aktywnych elementach (polach tekstowych, przyciskach, polach wyborów itp.) powinna zostać wyświetlona krótka informacja na temat przeznaczenia i funkcji danego elementu. 10) Obszar z oknem prezentacyjnym oraz oknami pomocniczymi powinien posiadać funkcję pełnego ekranu przynajmniej dla wyświetlania mapy. Funkcja to może być dostępna również dla innych elementów jak raport, wykres czy tabela. Funkcja ta ma pozwolić na wykorzystanie całego ekranu do prezentacji danych ma pominąć elementy przeglądarki oraz inne elementy portalu (menu, stopka) zbędne w przypadku nawigacji tych danych. 4.5.2 Wyświetlanie tabel Widok tabel powinien umożliwiać wyświetlanie tabel pojedynczych oraz zestawieniowych w zależności od wyboru użytkownika. W przypadku tabel pojedynczych, każda tabela powinna przedstawiać jeden wskaźnik na przestrzeni danego roku lub lat w określonych obszarze terytorialnym. 12

W przypadku tabel zestawieniowych użytkownik ma mieć możliwość decydowania o tym, czy dane zestawione są względem wskaźników, lat czy obszarów terytorialnych pod warunkiem, że użytkownik wybrał odpowiednio kilka wskaźników, lat i/lub obszarów. 4.5.3 Wyświetlanie wykresów Widok wykresów powinien umożliwiać wyświetlanie wykresów w formie wykresu kołowego, kolumnowego oraz liniowego. Wykres powinien posiadać objaśniającą legendę. Za pomocą wykresu powinno być możliwe zarówno generowanie zestawień różnych wskaźników, zestawień obszarów terytorialnych jak i zestawień czasowych (patrz 4.5.2). 4.5.4 Wyświetlanie map 1) Nawigacja: powiększanie i pomniejszanie mapy (powiększa widok), pomniejsz (pomniejsza widok), powiększenie i pomniejszenie widoku mapy będzie również możliwe za pomocą rolki (scroll) myszy; przesuń (przesuwa mapę), przesunięcie widoku mapy będzie również możliwe poprzez kliknięcie lewym przyciskiem myszy i przytrzymanie go oraz jednoczesne przesunięcie myszy; informacje (po najechaniu na jednostkę administracyjną wyświetlenie jej nazwy). 2) Legenda wyjaśnienie cech zawartych na mapie. 3) Menu mapy: a) dodaj/zamień/usuń wskaźnik: treść mapy przedstawiać będzie max. 3 wskaźniki jednocześnie wg kolejności zaznaczenia ich w oknie wskaźników, za pomocą tej opcji użytkownik zgodnie z potrzebą będzie mógł dodać (jeśli mapa prezentuje mniej niż 3 wskaźniki), zamienić na inny bądź usunąć wskaźnik, b) pokaż jako kartogram/diagram/wartość liczbową: system w momencie wygenerowania mapy przez użytkownika automatycznie przypisuje wskaźnikom właściwości ich prezentacji, tj. pierwszy wyświetlany jest jako kartogram, drugi jako wykres (zob. kartodiagram), trzeci jako wartość liczbowa; użytkownik będzie miał możliwość zmiany sposobu wyświetlania każdego wskaźnika, z tym, że właściwości prezentacji nie będą mogły się powielać, tzn.: jednocześnie będzie mógł być prezentowany 1 kartogram + 1 diagram + 1 wartość liczbowa w dowolnej konstelacji ustalonej przez użytkownika, c) wyróżnij jednostkę administracyjną (wybranie tej opcji w zależności od poziomu agregacji danych, np. województwo, podregion, powiat czy gmina (jeśli dostępne) pozwoli na wskazanie i wyróżnienie granicy konkretnej jednostki za pomocą zmiany koloru i grubości linii), d) pokaż stolice województwa (opcja ta będzie dostępna tylko dla województwa lubuskiego) stolice będą prezentowane za pomocą konturu z etykietą (tj. nazwą miasta). 4.5.5 Raport Tabele, wykresy, mapy oraz metryczki mają mieć możliwość dodawania do raportu. Dodawanie ma odbywać się bezpośrednio przy wymienionych funkcjonalnościach z zachowaniem kolejności dodawania do raportu. Użytkownik powinien mieć możliwość zarówno drukowania raportu jak i eksportowania go do pliku PDF. 13

Dzięki tej funkcjonalności użytkownik ma mieć możliwość przygotowywania danych zawierających dowolne wskaźniki oraz dowolną metodę prezentacji. własnych zestawień Widok raportu powinien umożliwiać następujące operacje: 1) Czyszczenie raportu - polecenie to usuwa wszystkie elementy dodane do raportu. 2) Usuwanie polecenie to usuwa z raportu wskazany przez użytkownika element (tabelę, wykres, mapę, metryczkę). 3) zmień kolejność polecenie to zmienia kolejność prezentowanych elementów w raporcie. 4.5.6 Wydruk i eksport Wszystkie wygenerowane tabele, wykresy, mapy oraz raporty widoczne w oknie prezentacyjnym a także metryczki będzie można wydrukować. Tabele powinny posiadać funkcję eksportu do formatu XLS. Wykresy oraz mapy powinny posiadać funkcję eksport do obrazu graficznego (JPG/PNG) oraz do formatu PDF. 4.5.7 Pomoc Pomoc powinna kierować do głównej strony pomocy, patrz 4.4.10. 4.5.8 Wymagana funkcjonalność Moduł musi umożliwiać: 1) generowanie zestawień w układzie wieloletnim, co pozwoli na śledzenie trendów (począwszy od 2010 roku), 2) prezentowanie danych w formie tabeli z danymi, wykresów, map, 3) prezentowanie w formie graficznej (mapa) do 3 zjawisk (wskaźników) jednocześnie, np.: kartogram (wskazujący wartość pierwszego wskaźnika) + wartość liczbowa (wskazująca wartość drugiego wskaźnika) + wykres (wskazujący wartość trzeciego wskaźnika), 4) prezentację wskaźników w ujęciu regionalnym (z możliwością porównań z wynikami osiąganymi przez inne polskie województwa), w ujęciu podregionów, powiatów i gmin (z możliwością porównań wyników osiąganych przez podregiony, powiaty i gminy tylko dla województwa lubuskiego) o ile w systemie monitorowania polityk publicznych będą gromadzone dane także na tych poziomach (podregiony, powiaty gminy), 5) uzupełnianie struktury o dodatkowe poziomy agregacji danych, 6) wygenerowanie metryczki wskaźnika (opcja metryczka musi być dostępna z poziomu każdego wskaźnika, np.: poprzez kliknięcie specjalnej ikony przy nazwie wskaźnika), 7) prezentacja dowolnej ilości wskaźników na dowolnym (dostępnym w systemie) poziomie agregacji danych (np.: kraj z podziałem na województwa, województwo z podziałem na podregiony, powiaty, gminy jeśli dostępne); wyjątkiem jest widok mapy, gdzie prezentowane są max. 3 wskaźniki, 8) prezentacja pojedynczego obszaru monitorowania polityk publicznych (wszystkie wskaźniki dla pojedynczego obszaru monitorowania), 9) wyróżnienie w tabeli, na wykresie bądź na mapie dowolnie wskazanej jednostki terytorialnej. Wymagana funkcjonalność administracyjna: 1) dodawanie, usuwanie i edycja wskaźników, 14

2) dodawanie, usuwanie i edycja obszarów monitoringu, 3) dodawanie, usuwanie i edycja metryczek (opisów) wskaźników w postaci tabelarycznej 4) aktualizacja, usuwanie danych, 5) wykonywanie kopii zapasowych danych oznaczonych obecną datą i godziną oraz komentarzem administratora. Przywracanie danych z wybranych kopii zapasowych. 4.6 Podstawowe wymagania techniczne Wymagania techniczne opisane poniżej są wymaganiami minimalnymi. Wykonawca może zastosować rozwiązania o wyższych standardach. 4.6.1 Część publiczna 1) Portal musi być dostępny co najmniej dla najpopularniejszych przeglądarek internetowych wg serwisu www.ranking.pl na dzień złożenia oferty (przekraczających próg 1%). Ponadto serwis musi być dostępny dla przeglądarki Internet Explorer w wersji co najmniej 8.0. W przypadku nieobsługiwanej wersji przeglądarki, portal musi poinformować użytkownika o potencjalnych problemach. 2) Portal powinien być dostępny i prawidłowo wyświetlany na urządzeniach mobilnych wyposażonych w przeglądarkę HTML. Nie ma obowiązku aby baza danych regionalnych funkcjonowała na urządzeniach mobilnych, jednak stosowna informacja powinna zostać wyświetlona użytkownikowi. 3) Portal musi działać z wykorzystaniem tzw. przyjaznych adresów internetowych. 4) Portal musi działać w oparciu o kodowanie UTF-8. 5) Wiadomości e-mail wysyłane przez portal powinny być dostępne w formacie HTML oraz tekstowym (czysty tekst). 6) Każda informacja udostępniona w portalu powinna posiadać informację o autorze oraz dacie upublicznienia. 7) Portal musi posiadać możliwość wydruku artykułów oraz informacji z bazy danych regionalnych. 8) Portal musi mieć możliwość polecenia artykułu w portalu znajomemu za pomocą emaila oraz Facebook a. 9) Adresy e-mail publikowane w portalu powinny posiadać zabezpieczenie antyspamowe przed automatyczną ich ekstrakcją z portalu (tzw. harvesting). 10) Portal powinien posiadać możliwość generowania mapy portalu zgodnej ze standardem Google Site Map (format XML). 11) Portal musi działać płynnie użytkownik nie powinien doświadczać opóźnień dłuższych niż 0.5 1s w dostępie do funkcji portalu. a) Akceptuje się, aby wyszukiwanie pełnotekstowe trwało maksymalnie do 5-10 sekund, z tym że użytkownik musi być informowany o postępie wyszukiwania. Wymaga się aby zawartość dokumentów była indeksowana w celu szybkiego ich przeszukiwania. b) Akceptuje się, aby generowanie wykresów i map trwało maksymalnie do 2 sekund, przy czym użytkownik musi być informowany o postępie ładowania wykresu/mapy. 15

4.6.2 Część niepubliczna 1) Portal musi umożliwiać administratorowi audyt użytkowników. 2) Portal musi wspierać wersjonowanie publikowanych i modyfikowanych artykułów. 3) Repozytorium plików (dowolnych typów) zasilane przez wszystkich redaktorów i pozwalające wykorzystywać pliki w różnych miejscach serwisu. 4) Możliwość podglądu redagowanej strony przed skierowaniem do publikacji. 5) Statystyki Wykonawca umożliwi administratorowi systemu dostęp do statystyk dotyczących parametrów wykorzystania serwisu, jak i zawartych w nim danych. Minimalne informacje, które muszą zawierać statystyki to: liczba wizyt, liczba odsłon, średnia liczba odsłon, żądania, transfer danych, średni czas spędzony na portalu, słowa kluczowe, przegląd źródeł odwiedzin (wyszukiwarki, witryny odsyłające, odwiedziny bezpośrednie). Musi być możliwy eksport do pliku XLS. 6) Edycja szablonów dla newslettera i raportów. 7) Importowanie danych do bazy danych regionalnych z pliku o określonym formacie. 8) Lista dodanych lub zmodyfikowanych artykułów oczekujących na publikację. 4.7 Wymagania w zakresie CMS (Content Management System) Wykonawca dostarczy system CMS umożliwiający zarządzeni treścią w serwisie bez konieczności znajomości języków programowania (do obsługi ma być wystarczająca podstawowa znajomość programów do edycji tekstu, zarówno w panelu administracyjnym, jak i redakcyjnym). Wykorzystana technologia oraz rozwiązania konstrukcyjne muszą zapewniać otwartość w zakresie dalszego rozwoju portalu, tzn. dostarczony system zarządzania treścią musi być aplikacją lub zestawem aplikacji pozwalającym na tworzenie, aktualizację oraz rozbudowę serwisu przez administratora. Struktura systemu CMS musi się opierać na budowie modułowej. CMS musi być zrealizowany w oparciu o relacyjną bazę danych SQL. Portal musi działać w oparciu o CMS obsługiwany za pomocą przeglądarki internetowej. CMS musi funkcjonować prawidłowo w polskiej wersji językowej. Wykonawca zobowiązany jest do przeprowadzenia analizy i weryfikacji wymagań dotyczących zakresu informacji koniecznych do publikacji (patrz zał. nr 1 SOPZ) oraz przedstawienia projektu graficznego strony głównej serwisu zgodnych z zaleceniami Zamawiającego. Wykonawca zobowiązany jest do uwzględnienia uwag Zamawiającego w opracowaniu projektu graficznego serwisu. Wykonawca opracuje architekturę wskaźników i zaproponuje formę ich prezentacji w układach graficznych zależności. 4.7.1 Wymagane cechy systemu CMS 1) CMS musi poprawnie działać z wykorzystaniem protokołu szyfrującego HTTPS. Wymóg ten dotyczy co najmniej procesu autoryzacji użytkownika. Dalsze działanie narzędzia może odbywać się z pominięciem protokołu HTTPS. 2) CMS musi być zbudowany w oparciu o budowę modułową. Oznacza to, że w CMS muszą funkcjonować dedykowane moduły funkcjonalne, przygotowane do obsługi konkretnego rodzaju informacji oraz posiadające specjalne funkcjonalności z możliwością przypisywania uprawnień dostępowych redaktorów do tych modułów m.in.: a) menu, b) artykuły, 16

c) baza danych regionalnych, itd., 3) CMS musi posiadać moduł menadżera plików z możliwością ich późniejszego wykorzystania w określonych modułach funkcjonalnych. Zamawiający oczekuje następujących funkcjonalności: a) automatyczne tworzenie ikony graficznej oznaczającej dany rodzaj pliku na podstawie rozszerzenia (ikony graficzne dla najpopularniejszych rozszerzeń zostaną opracowane przez Wykonawcę na etapie wdrożenia, wymagana jest prezentacji dla min. następujących typów rozszerzeń (PDF, XLS, DOC, ZIP, RAR, TXT, JPG, PNG, GIF), b) podział przechowywanych plików na kategorie tematyczne za pomocą folderów o dowolnej głębokości zagnieżdżenia (w miarę możliwości technologicznych wynikających z ograniczeń systemu plików lub systemu operacyjnego), c) wyszukiwanie plików po fragmentach nazwy, typie, zawartości (dla TXT, elektronicznych PDF oraz DOC), daty utworzenia (data od-do, wiek pliku wyrażony w dniach od-do), metadanych opisowych, d) sortowanie plików wg. daty dodania, nazwy i typu, e) na liście plików powinna być widoczna liczba artykułów powołujących się na dany plik, f) wyświetlanie listy artykułów powołujących się na dany plik z linkami prowadzącymi do tych artykułów, g) dodawanie nowych plików powinno umożliwiać wybór folderu, wprowadzenie nazwy pliku oraz metadanych opisowych tytuł (domyślnie nazwa pliku) oraz wymagane pole opisu zawartości pliku, h) usuwanie plików - jeżeli pliki są wykorzystywane przez artykuły, użytkownik powinien otrzymać listę tych artykułów ze stosowną informacją i operacja powinna zostać przerwana w celu zachowania integralności danych, i) edycja istniejących plików zmiana nazwy, tytułu oraz danych opisowych. Zastąpienie pliku nowym plikiem w takim samym formacie, j) tworzenie nowych folderów (kategorii), k) zmiana nazwy folderów artykuły odwołujące się do plików w tych folderach powinny zostać automatycznie zaktualizowane w celu poprawienia referencji do pliku, l) usuwanie folderów jeżeli pliki w folderze są wykorzystywane przez artykuły, użytkownik powinien otrzymać listę tych artykułów ze stosowną informacją i operacja powinna zostać przerwana w celu zachowania integralności danych. 4.7.2 Zarządzanie menu 1) CMS musi umożliwiać obsługę wszystkich typów menu zdefiniowanych w systemie na podstawie projektu graficznego np. menu główne, górne, dolne, lewe, prawe. 2) CMS musi umożliwiać definiowanie nowych pozycji menu na każdym z poziomów dla każdego z typów menu. 3) CMS musi umożliwiać nadanie uprawnień do poszczególnych pozycji menu. 4) Pozycje menu mogą być dodawane oraz modyfikowane wyłącznie przez uprawnionych redaktorów. 5) CMS musi umożliwiać ustawianie dowolnej kolejności pozycji menu. 6) CMS musi umożliwiać utworzenie 5-o poziomowej struktury menu. 17

7) CMS musi umożliwiać definiowanie tytułu strony dla każdej z pozycji menu (tytuł strony wyświetlany docelowo będzie jako tytuł okna po wybraniu danej pozycji menu w części publicznej). 8) CMS musi umożliwiać kojarzenie pozycji menu z modułami dedykowanymi. 4.7.3 Zarządzanie artykułami 1) CMS musi umożliwiać definiowanie artykułów. 2) CMS musi umożliwiać definiowanie artykułów w formie skrótu lub pełnego widoku artykułu lub linku zawierającego tylko tytuł. 3) Skrót może być dowolnie definiowany przez redaktora w zakresie ilości treści wyświetlonych w skrócie. 4) CMS musi umożliwiać formatowanie treści przez redaktorów bez znajomości technik programowania oraz kodu HTML (edytor WYSIWYG) w zakresie: a) pogrubienie czcionki, b) pochylenie czcionki, c) podkreślenie czcionki, d) zmiana koloru czcionki, e) sposób wyrównania tekstu, f) wprowadzenie listy numerowanej, g) wprowadzenie listy punktowanej, h) wprowadzenie tabeli z podpisem, i) dodanie obrazka z podpisem (po kliknięciu obraz powinien pojawić się w pełnym rozmiarze), j) wprowadzenie linku (hiperłącza) z możliwością przekierowania na inny adres strony WWW, adres e-mail, plik do pobrania z Menadżera plików, k) osadzanie materiałów wideo z portalu YouTube, l) osadzenie filmów (min. avi, mpg, wmv) i plików dźwiękowych (min. mp3, wma) odtwarzanych bezpośrednio ze strony bez konieczności pobierania. Zalecane jest aby edytor WYSIWYG był wzorowany na programie MS Office Word (ikony funkcji, ich kolejność, etc.). 5) CMS musi umożliwiać wyjście z edytora WYSIWYG i przejście bezpośrednie do edytora HTML 6) Artykuł może być dodany do dowolnej pozycji w strukturze menu. 7) Artykuł może być dodany wyłącznie przez użytkowników uprawnionych. 8) Nowo dodany artykuł po zapisaniu otrzymuje status nieopublikowany i nie jest widoczny publicznie. 9) CMS umożliwia podgląd artykułu przed publikacją w układzie graficznym portalu. 10) Dla każdego artykułu możliwe jest przyporządkowanie dowolnej ilości załączników do pobrania w formie plików binarnych z wykorzystaniem Menadżera plików lub poprzez wybór załącznika z dysku lokalnego komputera użytkownika. 11) W przypadku wyboru pliku z dysku lokalnego komputera użytkownika, plik po zapisaniu załącznika wczytywany jest jednocześnie do Menadżera plików i jest dostępny do użycia w innych przypadkach. 12) CMS powinien wspierać przenoszenie artykułów do archiwum: a) Ustawienie daty przejścia artykułu do archiwum przez redaktora, 18

b) Ustawienie parametru przejścia artykułu do archiwum w formie x dni od daty publikacji informacji dla pojedynczego artykułu, c) Ustawienie parametru globalnego przejścia artykułu do archiwum w formie x dni od daty publikacji informacji dla wszystkich artykułów, d) Ustawienie opcji nie przenoś do archiwum dla pojedynczego artykułu. 13) Każdy artykuł powinien posiadać możliwość wydruku oraz pobrania go w formacie PDF. 14) CMS musi wspierać kanały informacyjne RSS, Atom oraz XML zarówno dla aktualności globalnych jak i dla aktualności poszczególnych obszarów monitorowania. 4.7.4 Bezpieczeństwo i zarządzanie uprawnieniami CMS musi posiadać mechanizmy bezpieczeństwa i zarządzania uprawnieniami w zakresie: 1) Nieautoryzowanego dostępu do danych poprzez: a) automatyczne blokowanie loginu użytkownika przy przekroczeniu określonej przez administratora liczbie nieudanych prób logowania, odblokowanie następuje po określonym przez administratora czasie, b) automatyczne wymuszenie zmiany hasła użytkownika po upływie określonej przez administratora liczbie dni, c) administrator musi mieć możliwość zablokowania oraz odblokowania loginu użytkownika, d) administrator musi mieć możliwość zresetowania hasła wybranego użytkownika, e) użytkownicy muszą mieć możliwość automatycznego odzyskiwania hasła, funkcjonalność powinna wymagać adresu e-mail oraz dodatkowego pytania potwierdzającego tożsamość użytkownika. 2) Konfiguracji uprawnień dla redaktorów CMS na poziomie: a) uprawnień do dodawania i edycji artykułów wewnątrz poszczególnych obszarów monitorowania (redaktor może być odpowiedzialny za jeden lub więcej obszarów monitorowania), b) uprawnień do publikowania dodanych i zaktualizowanych artykułów w przypadku gdy redaktor nie posiada nadanego takiego uprawnienia, administratorzy portalu powinni zostać poinformowani e-mailem o konieczności podjęcia akcji. Panel administratora powinien zawierać listę artykułów oczekujących na publikację, za pomocą której administratorzy będą mogli zatwierdzać (publikować) zmiany oraz kontaktować się z osobami które zmian dokonały. 3) CMS musi umożliwiać dowolne tworzenie nowych użytkowników oraz przypisywanie im indywidualnych uprawnień (administratorzy bądź redaktorzy, ci drudzy przypisani do konkretnych obszarów monitorowania). 4) CMS musi posiadać mechanizmy rejestracji działań użytkowników w zakresie: a) Dziennik logowań rejestrujący udane i nieudane próby logowania użytkowników do części administracyjnej wraz z oznaczeniem daty, godziny oraz udanej lub nieudanej próby logowania; b) Rejestr zdarzeń rejestrujący działania użytkowników w systemie administracyjnym CMS w zakresie informacji publicznych. Rejestr zdarzeń powinien rejestrować przede wszystkim takie operacje jak: dodanie, edycja, usunięcie, upublicznienie rekordu 19

informacji publicznej, elementach słownikowych, łączenia załączników oraz rejestracji importu danych. Ponadto Wykonawca musi zagwarantować bezpieczeństwo informacji znajdujących się w systemie. Wykonawca przedstawi dokładny opis proponowanych rozwiązań w zakresie bezpieczeństwa oraz projekt konfiguracji infrastruktury systemu i sposób zabezpieczenia w specyfikacji technicznej portalu (patrz punkt 10.1). System CMS dostarczony przez Wykonawcę musi zapewniać: 1) Poufność ochrona przed ujawnieniem nieuprawnionemu odbiorcy; 2) Integralność - ochrona przed nieuprawnioną modyfikacją lub zniekształceniem; 3) Dostępność dostęp do zasobów informacyjnych; 4) Rozliczalność określenie i weryfikowanie odpowiedzialności za wykorzystanie systemu informacyjnego; 5) Autentyczność weryfikacja tożsamości podmiotów i prawdziwości zasobów; 6) Niezawodność gwarancja oczekiwanego zachowania systemu i otrzymywanych wyników. 4.8 Prezentacja treści 1) Portal musi być zaprojektowany w oparciu o Responsive Web Design. 2) Portal powinien być dostosowany dla użytkowników niepełnosprawnych zgodnie z Rozporządzeniem 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. z 2012 roku, Poz. 526) rozdział III, 19. 3) Strona główna jak i podstrony muszą być uporządkowane, tzn. ich elementy należy podzielić na bloki, kategorie i sekcje. Podział na kategorie musi być logiczny. 4) W całym serwisie wygląd linków musi być spójny (ten sam kolor, podkreślenie oraz sposób reakcji na kursor wyraźna zmiana koloru po najechaniu kursora na link). 5) Pomiędzy kolorem linków a kolorem tekstu musi istnieć wyraźna różnica. 4.9 Nazewnictwo i język Wykonawca musi przygotować serwis w języku polskim. W celu ujednolicenia i zwiększenia czytelności informacji publikowanych w serwisie należy zastosować: 1) jedno- lub dwuwyrazowe etykiety (lub powszechnie obowiązujące skróty) dla odnośników i podstron, 2) wszystkie elementy interfejsu (np. nazwy formatek, pola danych, etykiety, pliki i inne obiekty) muszą być jednoznaczne dla użytkownika, 3) wszystkie elementy graficzne muszą zawierać tzw. tekst alternatywny (wyświetlany w przypadku tekstowego formatu strony lub problemów z załadowaniem grafiki), 4) użytkownik powinien zostać poinformowany, jeśli jego przeglądarka internetowa nie jest wspierana lub jeśli brakuje dodatkowego oprogramowania (wtyczek przeglądarki) co powoduje utrudnienia bądź niemożliwość skorzystania ze wszystkich funkcji portalu. 20