Opis Przedmiotu Zamówienia

Podobne dokumenty
ZAŁĄCZNIK NR 3 OPIS PRZEDMIOTU ZAMÓWIENIA DOTYCZĄCY WDROŻENIA PLATFORMY ZAKUPOWEJ

SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA

Szczegółowy opis przedmiotu umowy. 1. Środowisko SharePoint UWMD (wewnętrzne) składa się z następujących grup serwerów:

Minimalne wymagania dla systemu Otwartych Danych Miasta Bielska-Białej i jego wdrożenia.

2. Jakie i ile licencji Oracle 10g posiada zamawiający i czy posiada do tych licencji wsparcie techniczne?

Rozdział 3. ROZWÓJ APLIKACJI CENTRALNEJ

ZAPYTANIE OFERTOWE. Zamawiający. Przedmiot zapytania ofertowego. Wrocław, dnia r.

PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W CSIZS

Szczegółowy opis przedmiotu zamówienia:

WYKONAWCY. Dotyczy: przetargu nieograniczonego na budowę wortalu i systemu poczty elektronicznej PIP

1. Wymagania prawne. Europejskie uwarunkowania prawne:

Referat pracy dyplomowej

Specyfikacja techniczna GoBiz Virtual Office - systemu dostępu do zasobów wirtualnego biura przez Internet

PRZEDMIOT ZAMÓWIENIA 1. Przedmiotem zamówienia jest budowa, dostawa, konfiguracja, wdrożenie i uruchomienie zintegrowanego systemu zarządzania

27/13 ZAŁĄCZNIK NR 4 DO SIWZ. 1 Serwery przetwarzania danych. 1.1 Serwery. dostawa, rozmieszczenie i zainstalowanie 2. serwerów przetwarzania danych.

WZÓR UMOWY. Zawarta w Białymstoku, w dniu.. pomiędzy:

Zakład Gospodarki Komunalnej Czernica Sp. z o.o.

SZCZEGÓŁOWY OPIS SPOSOBU DOSTĘPU DO INFORMACJI I DANYCH ZAWARTYCH W RAPORTACH SKŁADANYCH DO KRAJOWEJ BAZY DLA GIOŚ I WIOŚ

Tomasz Grześ. Systemy zarządzania treścią

GoBiz System platforma współpracy marektingowej

BDG.V PC Warszawa, dnia r.

AE/ZP-27-16/14. Oprogramowanie do wykonywania kopii zapasowych oraz zarządzania maszynami wirtualnymi

Zarządzaj projektami efektywnie i na wysokim poziomie. Enovatio Projects SYSTEM ZARZĄDZANIA PROJEKTAMI

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych

RFP. Wymagania dla projektu. sklepu internetowego B2C dla firmy Oplot

Zakres wymagań dotyczących Dokumentacji Systemu

Zapytanie ofertowe nr 3/B/2013

Instalacja SQL Server Express. Logowanie na stronie Microsoftu

Sprawa numer: BAK.WZP Warszawa, dnia 16 sierpnia 2016 r.

edziennik Ustaw Opis architektury

Zapytanie ofertowe. na wyłonienie dostawcy wartości niematerialnych w zakresie. Wartości Niematerialnych i Prawnych w postaci Systemu Klasy B2B

SYSTEM VILM ZARZĄDZANIE CYKLEM ŻYCIA ŚRODOWISK WIRTUALNYCH. tel: +48 (032)

Galileo - encyklopedia internetowa Plan testów

FORMULARZ OFERTOWY. Termin dostarczenia dokumentu 1

Rozdział I Zagadnienia ogólne

Zadanie nr 3 CAPACITY PLANNING

Zmiana treści Specyfikacji Istotnych Warunków Zamówienia.

Pytanie nr 3: Czy połączenie urządzenie mobilne -> serwer będzie szyfrowane? (protokół HTTPS).

Specyfikacja usług. 1. Zakup usług informatycznych dla realizacji dostępu do systemu dla obsługi relacji B2B.

Aplikacja serwerowa Platformy Prezentacyjnej Opis produktu

Szczegółowy opis przedmiotu zamówienia

Opis wymagań i program szkoleń dla użytkowników i administratorów

A. Specyfikacja wymagań na utworzenie portalu internetowego

Liczba godzin 1,2 Organizacja zajęć Omówienie programu nauczania 2. Tematyka zajęć

1 Postanowienia ogólne

OPIS WYMAGAŃ FUNKCJONALNO-TECHNICZNYCH dla zamówienia: Zaprojektowanie, wykonanie i uruchomienie serwisu do obsługi zgłoszeń dla miasta Torunia

Regulamin korzystania z Usługi INVO24 przez Odbiorcę i Użytkownika Odbiorcy

Strona wizytówka od 400 zł

Administratora CSIZS - OTM

POLITYKA PRYWATNOŚCI STRONY INTERNETOWEJ

Sekcja I: Instytucja zamawiająca/podmiot zamawiający

nr sprawy: BZP ML Wrocław, dn. 20 lutego 2014 r. SPROSTOWANIE DO INFORMACJI DLA WYKONAWCÓW NR 13

Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego. Opis oferowanego przedmiotu zamówienia

Montaż kolektorów słonecznych i pieców na biomasę w Gminie Modliborzyce

REFERAT O PRACY DYPLOMOWEJ

WYJAŚNIENIA NR 2 TREŚCI SIWZ

Dokumentacja techniczna. Młodzieżowe Pośrednictwo Pracy

REGULAMIN KORZYSTANIA Z APLIKACJI SYSTEM SOKRATES- GENERATOR OCENY PRACY NAUCZYCIELA

Polityka prywatności sklepu internetowego

ZASADY KORZYSTANIA Z PLIKÓW COOKIES ORAZ POLITYKA PRYWATNOŚCI W SERWISIE INTERNETOWYM PawłowskiSPORT.pl

Szczegółowy harmonogram rzeczowy realizacji prac systemu B2B

ZAŁĄCZNIK NR 1 DO REGULAMINU SERWISU ZNANEEKSPERTKI.PL POLITYKA OCHRONY PRYWATNOŚCI

Polityka ochrony prywatności

Win Admin Replikator Instrukcja Obsługi

POLITYKA BEZPIECZEŃSTWA w zakresie ochrony danych osobowych w ramach serwisu zgloszenia24.pl

Szczegółowa specyfikacja funkcjonalności zamawianego oprogramowania.

Regulamin korzystania z Systemu Wrota Podlasia

Zapytanie ofertowe. Niespełnienie któregokolwiek wymagania może skutkować odrzuceniem oferty bez jej rozpatrzenia

Planowanie przestrzenne

System Kancelaris. Zdalny dostęp do danych

ZAMAWIAJĄCY. CONCEPTO Sp. z o.o.

POLITYKA PRYWATNOŚCI SERWISU INTERNETOWEGO transportfedorowicz.pl

DYREKTOR GENERALNY URZĘDU ZAMÓWIEŃ PUBLICZNYCH

Win Admin Replikator Instrukcja Obsługi

Zapytanie ofertowe nr 03/05/2014. Zakup licencji na oprogramowanie do wirtualizacji Działanie POIG 8.2

Dodatkowo, w przypadku modułu dotyczącego integracji z systemami partnerów, Wykonawca będzie przeprowadzał testy integracyjne.

DESlock+ szybki start

Świadczenie usługi hurtowej wysyłki wiadomości SMS dla Urzędu Miasta Torunia w latach

7. zainstalowane oprogramowanie zarządzane stacje robocze

PROCEDURA UTRZYMANIA I ROZWOJU KWESTIONARIUSZA ZAINTERESOWAŃ ZAWODOWYCH

Zamek Królewski w Warszawie Muzeum Warszawa, dn. 8 sierpnia 2018 r. Rezydencja Królów i Rzeczypospolitej Warszawa, Plac Zamkowy 4

POLITYKA PRYWATNOŚCI I COOKIES

POLITYKA PRYWATNOŚCI PORTALU INTERNETOWEGO

Załącznik nr 1. Do zapytania ofertowego nr 1/UE/2013

Materiał dystrybuowany na licencji CC-BY-SA

Regulamin określający zasady i warunki techniczne świadczenia usług drogą elektroniczną

Specyfikacja Wymagań. System Obsługi Zgłoszeń Serwisowych Polfa Warszawa S.A. Załącznik nr 1

Instrukcja zarządzania systemem informatycznym STORK Szymon Małachowski

ZAPYTANIE OFERTOWE NA ZAPROJEKTOWANIE, WDROŻENIE, UTRZYMANIE I ADMINISTROWANIA STRONY INTERNETOWEJ W RAMACH REALIZACJI ZADANIA PUBLICZNEGO PN

OGÓLNE ZASADY POSTĘPOWANIA OFERTOWEGO 1. W szczególnie uzasadnionych przypadkach Zamawiający może w każdym czasie, przed upływem terminu składania

SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA

W ramach realizacji zamówienia Wykonawca będzie świadczył usługi w zakresie m.in:

Rozwiązanie GIS dla mniejszego. miasta: model Miasta Stalowa Wola. Janusz JEśAK. Jacek SOBOTKA. Instytut Rozwoju Miast. ESRI Polska Sp. z o. o.

DOTYCZY KLIENTA PKO BIURO OBSŁUGI LEASING ZAPYTANIE O INFORMACJĘ OTYCZY: DOSTAWY PLATFORMY ELEKTRONICZNE DLA PKO

OPIS PRZEDMIOTU ZAMÓWIENIA

Szczegółowy opis przedmiotu zamówienia

Szczegółowy zakres rzeczowy

Projekt Platforma e-zamówienia Wisła, dnia r.

II ETAP (od r. do r.) obejmuje realizację następujących zadań:

SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA

Transkrypt:

Opis Przedmiotu Zamówienia Część I. Cel i przedmiot zamówienia Celem zamówienia jest zaprojektowanie, budowa i wdrożenie wrocławskiego portalu danych otwartych. Na warunkach określonych w umowie Wykonawca zobowiązuje się do będzie realizacji przedmiotu umowy określonego w 2 Umowy i uszczegółowionego poniżej. 1. Analiza Przedwdrożeniowa Wykonawca jest zobowiązany przygotować szczegółowy dokument analizy przedwdrożeniowej. Analiza Przedwdrożeniowa zostanie opracowana w oparciu o analizę procesów biznesowych i zarządczych funkcjonujących w CUI, wymagania określone w umowie i OPZ oraz funkcjonalności będące w standardzie Systemu. Analiza winna być wykonana z wykorzystaniem najlepszych praktyk obowiązujących przy wdrożeniach systemów oraz wykorzystaniem wiedzy i doświadczenia Wykonawcy. Dokument analizy przedwdrożeniowej musi zawierać w szczególności: 1.1. Opis środowiska biznesowego, w tym: celów biznesowych, opis wszystkich procesów biznesowych, w które będzie realizował System, szczegółowy opis wszystkich funkcjonalności dostępnych w Systemie, szczegółowy opis instalacji i konfiguracji niezbędnych do uzyskania wszystkich wymaganych funkcjonalności, wykaz oraz szczegółowy opis i harmonogram wykonania niezbędnych prac programistycznych związanych z dostosowaniem i modyfikacją Systemu oferowanego przez Wykonawcę, Wykaz wszystkich Produktów projektu. 1.2. Projekt Organizacyjno-Techniczny opisujący: koncepcję Systemu, model i opis architektury logicznej Systemu, architekturę fizyczną Systemu z określeniem warstwy prezentacji, reguł biznesowych oraz transakcji na poziomie Systemu, zarządzanie relacyjną bazą danych, koncepcję funkcjonowania wspólnych dla Systemu słowników, podział usług z przypisaniem ich do poszczególnych serwerów logicznych i fizycznych (zależnie od zakresu użytej wirtualizacji zasobów), reguły bezpieczeństwa Systemu ze szczególnym uwzględnieniem danych wrażliwych, opis systemów, podsystemów, modułów, komponentów i funkcji Systemu stanowiących uszczegółowienie wymagań określonych dla Systemu z przypisaniem poszczególnych wymagań do danego systemu, podsystemu, modułu oraz nazwanej funkcji lub grupy funkcji, inne zagadnienia techniczne. 1.3. Harmonogram Szczegółowy prac wdrożeniowych zawierający: podział na Etapy i przypisanie do nich Produktów, 1

Plan szkoleń, Plan testów. 1.4. Opis instalacji i konfiguracji środowiska testowego i produkcyjnego. 1.5. Organizację i metodykę zarządzania Projektem w tym skład Zespołu Wdrożeniowego z podziałem na role i zadania poszczególnych członków zespołu. 1.6. Opis integracji Systemu, w tym: sposób, zakres i częstotliwość integracji Systemu z systemami zewnętrznymi, interfejsy wymiany informacji. 1.7. Opis migracji danych, w tym: zakres i sposób zasilenia Systemu danymi ze źródeł wskazanych przez Zamawiającego, formaty zbiorów danych do zasilenia inicjalnego, określenie mechanizmu dalszej aktualizacji i archiwizacji migrowanych danych. 1.8. Zakres testów Systemu, w tym: opis testów funkcjonalnych, wydajnościowych i bezpieczeństwa Systemu, plan i scenariusze testów. 1.9. Wykaz nowych danych, które w ramach Budowy Systemu zostaną umieszczone na portalu w trakcie wdrożenia wraz z informacją o częstotliwości i mechanizmie ich aktualizacji oraz archiwizacji. 1.10. Analizę ryzyka dotyczącą zabezpieczeń Systemu. Analiza musi uwzględniać również ryzyka organizacyjne po stronie Zamawiającego; informacje o ryzykach organizacyjnych zostaną przekazane Wykonawcy przez Zamawiającego. 1.11. Opis zastosowanych zabezpieczeń Systemu adekwatnych do oszacowanego ryzyka, o którym mowa w poprzednim punkcie. 2. Prototyp 2.1. Wykonawca jest zobowiązany opracować Prototyp stanowiący model przyszłego Systemu Informatycznego. Prototyp umożliwi dostęp do środowiska aplikacyjnego aby usprawnić prace analityczne i prowadzenie uzgodnień na etapie Analizy Przedwdrożeniowej. 2.2. Prototyp będzie zbudowany w Środowisku Testowym Systemu. 2.3. Prototyp będzie miał przygotowaną ustaloną z Zamawiającym strukturę portalu oraz zaimplementowaną docelową grafikę wybraną przez Zamawiającego spośród 3 projektów graficznych interfejsu graficznego Systemu, które Wykonawca opracuje i przedstawi Zamawiającemu. 2.4. Prototyp będzie posiadał bazowe funkcjonalności Systemu oraz będzie częściowo zasilony danymi z Portalu ODW w celu zademonstrowania możliwości zamieszczania danych różnych rodzajów. 2.5. Prototyp będzie miał przygotowany panel administratora z zaimplementowanymi najważniejszymi funkcjonalnościami. 2.6. Dla prototypu nie wymaga się: implementacji e-usług, opracowania mechanizmów automatycznego zasilania portalu danymi, integracji z systemami zewnętrznymi, pełnej migracji danych z portalu ODW. 2.7. Szczegółowe wymagania dotyczące Prototypu będą określone w Analizie Przedwdrożeniowej. 3. Budowa Systemu Informatycznego (wdrożenie) 2

3.1. Budowa Systemu Informatycznego będzie przebiegać zgodnie ze szczegółowymi ustaleniami określonymi w Analizie Przedwdrożeniowej. 3.2. Wykonawca dostarczy standardowe oprogramowanie aplikacyjne, zainstaluje je w Środowisku Testowym, wykona konieczne do prawidłowego działania parametryzacje i konfiguracje. 3.3. Wykonawca przygotuje repozytorium danych Systemu przeznaczone do umieszczania w nim danych, które będą udostępniane zewnętrznym użytkownikom Systemu poprzez API. Repozytorium będzie automatycznie zasilane danymi pochodzącymi z systemów zewnętrznych w ustalony w Analizie Przedwdrożeniowej sposób zapewniając w ten sposób integrację tych systemów z Systemem; Wykonawca jest zobowiązany do opracowania mechanizmów zasilania repozytorium danymi. 3.4. Wykonawca przygotuje repozytorium plików oczekujących na publikację na portalu zasób w którym użytkownicy zewnętrzni Systemu będą umieszczali aktualne pliki z danymi publikowanymi na portalu a System będzie posiadał możliwość ich pobrania w celu udostępnienia na portalu aktualnej wersji danych. 3.5. Wykonawca przeprowadzi prace niezbędne do dostosowania oprogramowania do wszystkich wynikających z Umowy oraz Analizy Przedwdrożeniowej wymagań Zamawiającego, w tym wykona: migrację danych z portalu ODW (http://www.wroclaw.pl/open-data/), integrację z systemami zewnętrznymi, testy. 3.6. Wykonawca przekaże Zamawiającemu System do przeprowadzenia testów. 3.7. Po zakończeniu testów i po akceptacji przygotowanego rozwiązania Wykonawca zainstaluje i uruchomi System w Środowisku Produkcyjnym oraz wykona niezbędne parametryzacje i konfiguracje. 3.8. Wykonawca przygotuje i odda Zamawiającemu do użytkowania zarówno Środowisko Produkcyjne jak i Testowe. Zamawiający zakłada, że : Środowisko Produkcyjne będzie okresowo kopiowane na Środowisko Testowe, Środowisko Testowe będzie dostępne tylko dla Administratorów Systemu. 3.9. Wykonawca jest zobowiązany dostarczyć Zamawiającemu licencje uprawniające do korzystania z oprogramowania zainstalowanego w Środowisku Testowym i Produkcyjnym najpóźniej w dniu jego zainstalowania. 4. Migracja danych z obecnego systemu 4.1. Migracją będą objęte wszystkie dane publikowane na portalu ODW (http://www.wroclaw.pl/open-data/). 4.2. Migracja będzie polegała na przeniesieniu zgromadzonych tam danych do Systemu. 4.3. Dane po zmigrowaniu do Systemu zostaną objęte mechanizmem automatycznej aktualizacji - we wszystkich przypadkach gdzie jest to technicznie wykonalne oraz mechanizmem archiwizacji. 4.4. Zasady aktualizacji i archiwizacji zostaną określone podczas Analizy Przedwdrożeniowej. 4.5. Na wniosek Wykonawcy Zamawiający udostępni mu dokumentację niezbędną do prawidłowego przeprowadzenia migracji. 5. Integracja 3

5.1. System w fazie wdrożenia zostanie zintegrowany z wybranymi zewnętrznymi systemami informatycznymi gromadzącymi dane, które będą udostępniane na portalu. 5.2. Integracja ma zapewniać automatyczne zasilanie portalu danymi z systemów zewnętrznych z wyznaczoną przez Zamawiającego częstotliwością. 5.3. Lista systemów zewnętrznych, dla których Zamawiający planuje zastosować integrację: 5.3.1. ITS firmy WASKO S.A. z Gliwic 5.3.2. Ewidencja Ludności firmy OTAGO Sp. z o.o. 5.3.3. Wrocławski Budżet Obywatelski autorstwa CUI 5.3.4. Jednostki Miejskie autorstwa CUI 5.3.5. Urzędowy Rejestr Umów autorstwa CUI 5.3.6. Studencki System Stypendialny autorstwa CUI 5.3.7. Bank zdjęć promocyjnych autorstwa CUI 5.4. Zamawiający zastrzega sobie prawo do rozszerzenia listy o nie więcej niż kolejne 20 systemów zewnętrznych, które zostaną zintegrowane z Systemem w fazie wdrożenia. 5.5. Zamawiający przewiduje, że integracja z systemami zewnętrznymi będzie polegała na: plikowej wymianie danych, pobieraniu danych z systemu zewnętrznego poprzez usługę, szybkim pobieraniu do repozytorium danych Systemu danych zgromadzonych w źródłowych bazach systemów zewnętrznych w celu udostępniania ich użytkownikom portalu poprzez API dotyczy w szczególności danych, które będą udostępniane na portalu w trybie on-line, w inny, ustalony pomiędzy Zamawiającym a Wykonawcą sposób. 5.6. Sposób przeprowadzenia integracji będzie zależał od specyfiki danych i sposobu ich przechowywania w systemie zewnętrznym. Wykonawca ma obowiązek zaimplementowania optymalnych dla Zamawiającego metod integracji Systemu z systemami zewnętrznymi. 5.7. Szczegółowa lista systemów zewnętrznych, które zostaną zintegrowane z portalem oraz zasady integracji (sposób i zakres) zostaną ustalone w trakcie Analizy Przedwdrożeniowej. 5.8. System musi posiadać narzędzia, które pozwolą w przyszłości na zintegrowanie go z kolejnymi systemami informatycznymi, z których będą pochodziły nowe dane udostępniane na portalu. 6. Testy Systemu 6.1. System przejdzie testy funkcjonalne, wydajnościowe i bezpieczeństwa. 6.2. Wykonawca jest zobowiązany opracować i zrealizować plan testów, scenariusze testowe oraz dane testowe dla każdego obszaru funkcjonowania Systemu. 6.3. Szczegółowy zakres testów oraz plan i scenariusze testów zostaną zawarte uzgodnione w Analizie Przedwdrożeniowej. 6.4. W ramach testów Wykonawca przeprowadzi audyt bezpieczeństwa Systemu na zgodność ze standardem OWASP ASVS 3.0.1 na poziomie 2 i przedstawi Zamawiającemu raport z audytu potwierdzający spełnienie powyższego standardu. Część II. Wymagania dla systemu 4

1. Opis ogólny System będzie służył do prowadzenia wrocławskiego portalu danych otwartych. Jego celem jest ułatwienie wszystkim zainteresowanym osobom dostępu do informacji publicznej oraz ponownego wykorzystania informacji sektora publicznego. Użytkownikiem portalu może być każdy internauta, bez ograniczeń. Dane publikowane na portalu będą pochodziły z różnych jednostek miejskich. Dodatkowo System będzie realizował kilka e-usług publicznych, których interesariuszami będą użytkownicy portalu, tj. osoby fizyczne, przedsiębiorcy, naukowcy i inni. 2. Osoby korzystające z Systemu Osoby korzystające z Systemu dzielą się na grupy: Administratorzy pracownicy Zamawiającego posiadający konto administratora Systemu, odpowiedzialni za wszystkie czynności związane z prowadzeniem portalu i umieszczaniem na nim danych, Użytkownicy wewnętrzni pracownicy Zamawiającego odpowiedzialni za aktualizację danych, za które odpowiadają poprzez umieszczanie we wskazanym miejscu Systemu pliku z aktualnymi danymi. Użytkownicy wewnętrzni będą mieli w Systemie konto użytkownika z uprawnieniami do aktualizacji. Użytkownicy zewnętrzni wszyscy internauci korzystający z portalu, dostęp swobodny bez ograniczeń i logowania. Użytkownicy z kluczem API osoby, które uzyskały odpowiednie konto w Systemie i otrzymały wygenerowany dla nich klucza API do danych. System będzie prowadził rejestr tych użytkowników. 3. Wymagania prawne i standardy 3.1. System będzie zgodny z obowiązującymi oraz tymi przepisami prawa powszechnego, których termin wejścia w życie został już określony - z Ustawą z dnia 6 września 2001 r. o dostępie do informacji publicznej (Dz.U. 2016, poz. 1764 z późn. zm.) oraz Ustawą z dnia 25 lutego 2016 r. o ponownym wykorzystywaniu informacji sektora publicznego (Dz.U. z 2016 r., poz. 352 z późn. zm.), a także przepisami prawa miejscowego (uchwałami Rady Miasta Wrocławia) oraz Decyzjami i Zarządzeniami Prezydenta Miasta Wrocławia dotyczącymi realizacji zadań z zakresu udostępniania informacji sektora publicznego. 3.2. System będzie zgodny z Uchwałą Nr 107/2016 Rady Ministrów z dnia 20 września 2016 r. w sprawie ustanowienia Programu Otwierania Danych Publicznych. Dane na portalu będą udostępniane w standardzie takim jak standard udostępniania danych na portalu danepubliczne.gov.pl określony w Załączniku nr 1 do ww. programu. 3.3. System będzie zgodny 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 2016 r., poz. 113 z późn. zm.), dalej KRI w obszarze zarządzania bezpieczeństwem informacji. 3.4. W szczególności w ramach zgodności z KRI System będzie spełniał Wytyczne dla dostępności treści internetowych 2.0 (WCAG 2.0) zawierające rekomendacje dotyczące tworzenia treści internetowych w taki sposób aby były one dostępne dla szerszego grona użytkowników niepełnosprawnych. 5

3.5. System będzie spełniał wymogi Ustawy z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (t.j. Dz.U. z 2016 r., poz. 922). 3.6. System będzie umożliwiał Zamawiającemu wypełnienie obowiązków wynikających z ROZPORZĄDZENIA PARLAMENTU EUROPEJSKIEGO I RADY (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie danych) z dniem wejścia w życie ww. przepisów. 3.7. System musi działać pozostając w zgodzie z polityką bezpieczeństwa wdrożoną przez Zamawiającego na podstawie Zarządzenia Nr CUI/2/2017 Dyrektora Centrum Usług Informatycznych we Wrocławiu z dnia 2 stycznia 2017 r. w sprawie wprowadzenia w Centrum Usług Informatycznych we Wrocławiu Polityki Bezpieczeństwa Informacji i Instrukcji zarządzania systemami informatycznymi służącymi przetwarzaniu danych osobowych wydanym na podstawie 3 ust. 3 Rozporządzenia Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz.U. z 2004 r., Nr 100, poz. 1024) oraz art. 36 ust. 2 i 3 ustawy z dnia 29 sierpnia 199 7r. o ochronie danych osobowych (t.j. Dz.U. z 2016 r., poz. 922) 3.8. System będzie spełniał wymogi standardu bezpieczeństwa Open Web Application Security Project ASVS 3.0.1 na poziomie 2. 4. Wymagania pozafunkcjonalne Systemu 4.1. System będzie zapewniał ciągły dostęp i będzie działał w trybie on-line 24h, 7 dni w tygodniu. 4.2. System musi pozwalać na jednoczesny dostęp wielu użytkownikom zewnętrznym. Minimalne wymagania: obsługa 2000 sesji użytkowników zewnętrznych pracujących jednocześnie i do 10000 sesji przy zwiększonych jedynie zasobach infrastruktury serwerowej. 4.3. System będzie zainstalowany na infrastrukturze Zamawiającego. 4.4. System musi zapewniać ochronę bazy danych przed utratą spójności lub zniszczeniem ze strony interfejsu użytkownika. 4.5. Lokalna baza danych Systemu (repozytorium danych S ystemu) musi być dostosowana do działania w systemie zarządzania relacyjnymi bazami danych (RDBMS) MySQL w wersji 5.0.15 lub wyższej. Inne konfiguracje muszą zostać zaakceptowane przez Zamawiającego. 4.6. System nie może wymagać do normalnej pracy ani dostępu do kont administracyjnych w instancji bazy danych ani nadania użytkownikom uprawnień administracyjnych w bazie danych. 4.7. Warstwa aplikacyjna Systemu musi być dostosowana do działania na serwerze aplikacji Apache w wersji 2.x lub wyższej. Inne konfiguracje muszą zostać zaakceptowane przez Zamawiającego. 4.8. System musi zapewniać ciągłość sesji użytkowników i umożliwiać ograniczenie jej trwania. 4.9. Systemu musi być zbudowany w oparciu o architekturę wielowarstwową z wydzieloną co najmniej warstwą prezentacji, logiki biznesowej (przetwarzania) i danych (składowania). 4.10. Wszystkie moduły Systemu muszą wykorzystywać takie same oprogramowanie narzędziowe w warstwie logiki biznesowej tj. serwer aplikacji. 4.11. Wszystkie moduły Systemu muszą wykorzystywać takie same oprogramowanie narzędziowe w warstwie danych tj. serwer bazodanowy. 6

4.12. Żadna z funkcjonalności i właściwości Systemu nie może być ograniczona w czasie, zarówno pod względem formalno-prawnym jak i technicznym. 4.13. Konieczne jest zapewnienie środków uniemożliwiających nieautoryzowany dostęp na poziomie baz danych, usług sieciowych i aplikacji. 4.14. Wymagane jest wdrożenie zabezpieczeń informacji w sposób uniemożliwiający nieuprawnionemu jej ujawnienie, modyfikacje, usunięcie lub zniszczenie. 4.15. W przypadku zaistnienia włamania do Systemu Wykonawca jest zobowiązany do analizy przyczyny włamania oraz dostarczenia poprawek oprogramowania eliminujących podatność w ramach świadczonych Usług Utrzymania. 4.16. System musi działać prawidłowo w środowisku zwirtualizowanym VMware vsphere lub Oracle VM Server for x86 i nie może mieć żadnych ograniczeń licencyjnych w związku z umieszczeniem go w środowisku zwirtualizowanym. 4.17. Na potrzeby konfiguracji rozruchowej Systemu Zamawiający może udostępnić zasoby dyskowe w sieci SAN o łącznej pojemności nie przekraczającej 100GB oraz następującą infrastrukturę serwerową: Jedno z dostępnych środowisk wirtualizacji: 4.17.1. VMware vsphere Zasoby klastra VMware vsphere nie przekraczające łącznie: 8 vcpu 12GB RAM z systemami operacyjnymi maszyn wirtualnych: Oracle Enterprise Linux 6/7, albo RedHat Enterprise Linux 6/7, albo Windows Server 2012 R2 4.17.2. Oracle VM Zasoby klastra Oracle VM nie przekraczające łącznie: 8 vcpu 12GB RAM z systemami operacyjnymi maszyn wirtualnych Oracle Enterprise Linux 6/7. System musi zostać rozlokowany na zasobach, które zostaną udostępnione przez Zamawiającego. Inne konfiguracje i większe ilości zasobów muszą zostać zaakceptowane przez Zamawiającego. 4.18. System musi obsługiwać API (REST lub SOAP) na potrzeby integracji z systemami źródłowymi. 4.19. System musi umożliwiać zmianę parametrów połączenia do bazy danych oraz innych źródeł danych zdefiniowanych w Systemie. W szczególności dane połączeniowe nie mogą być zaszyte w kodzie Systemu. 4.20. Dostęp do portalu będzie możliwy dla użytkowników zewnętrznych portalu przy wykorzystywaniu wyłącznie sprzętu komputerowego połączonego z siecią internetową, w tym również urządzeń mobilnych opartych na systemach Android i ios. 4.21. System będzie poprawnie i jednakowo wyświetlany na popularnych przeglądarkach internetowych w wersjach wspieranych przez producenta przeglądarki w dniu zawarcia umowy oraz wyższych bez konieczności instalacji dodatkowych narzędzi; wymagana jest zgodność z (minimum) Firefox, Internet Explorer, Gogle Chrome, Safari, Opera. 7

4.22. System będzie poprawnie wyświetlany na urządzeniach mobilnych opartych na systemach Android i ios; wymagana jest responsywność Systemu. 4.23. System umożliwi integrację portalu z mediami społecznościowymi: Facebook polubienie, udostępnienie, komentarz; Twitter udostępnienie. 4.24. Wykonawca przygotuje narzędzie, które umożliwi Administratorowi Systemu kopiowanie oprogramowania i danych ze Środowiska Produkcyjnego na Środowisko Testowe. 4.25. System będzie korzystał z usługi Google Analitics w celu pozyskiwania statystyk portalu - ilość odwiedzin, sesji itp. 4.26. System będzie monitorowany narzędziem Nagios - monitoring obciążenia serwera, zajętość dysku, RAM, ping. 4.27. System będzie mieć półotwartą strukturę programu (możliwość dokonywania modyfikacji przez Zamawiającego). 4.28. System będzie posiadać Pomoc kontekstową oraz interfejs w języku polskim. 4.29. Struktura Systemu musi umożliwiać w przyszłości wprowadzenie dodatkowych wersji językowych portalu. 4.30. Struktura danych będzie cechować się brakiem redundancji danych za wyjątkiem sytuacji gdzie wymagania wydajności Systemu uzasadniają odstąpienie od tej zasady. W takich wypadkach wszelkie replikacje danych muszą odbywać się w trybie on-line w pełni transakcyjnie. 4.31. Obsługa Systemu musi być intuicyjna. 5. Wymagania funkcjonalne Systemu 5.1. System będzie zbudowany na platformie DKAN lub porównywalnej, przystosowanej do realizacji projektów związanych z udostępnianiem otwartych danych, wyposażonej w takie funkcjonalności jak: wbudowane API, kompatybilność z Data.gov, obsługa google.maps, podgląd danych, generowanie wykresów, zestawień, historia danych, własny CMS. 5.2. Implementacja Systemu zostanie przeprowadzona w sposób, który zapewni kompatybilność Systemu z krajową platformą danych otwartych https://danepubliczne.gov.pl/, w szczególności w zakresie określonych tam kategorii danych i atrybutów danych. 5.3. System będzie przystosowany do udostępniania danych w postaci plików, usług, API. 5.4. Planowane są dwa typy API - powszechne i z kluczem. 5.5. System będzie posiadał moduł Administratora Systemu dostępny dla Zamawiającego. Zamawiający wymaga, aby wszelkie działania administracyjne i redakcyjne były możliwe do przeprowadzenia przez Administratora Zamawiającego, bez pośrednictwa Wykonawcy. Powyższy wymóg dotyczy wszelkich działań służących sprawnemu funkcjonowaniu portalu. W szczególności musi być możliwe: umieszczanie danych na portalu i zarządzanie nimi, tworzenie kategorii danych i zarządzanie nimi, 8

opisywanie danych za pomocą atrybutów, konfigurowanie sposobu prezentacji danych, zarządzanie treścią portalu, publikowanie informacji i komunikatów, konfigurowanie mechanizmów automatycznej aktualizacji danych, konfigurowanie API do danych, budowanie ról i nadawanie uprawnień. 5.6. Dane umieszczane w Systemie będą miały przypisane przynajmniej poniższe atrybuty: Źródło Kategoria Częstotliwość aktualizacji Ostatnia Modyfikacja Utworzono Liczba wyświetleń Liczba pobrań Typ API Stopień otwartości danych wg pięciogwiazdkowej skali Star Open Data 5.7. Dane umieszczane na portalu muszą mieć możliwość przypisywania do nich słów kluczowych. 5.8. System będzie udostępniał narzędzia do prezentacji danych w postaci tabeli, wykresów, map (dla danych geoprzestrzennych), obrazów bez konieczności ich pobierania. 5.9. Dane umieszczane na portalu będą objęte mechanizmem automatycznej archiwizacji System będzie przechowywał historię danych, zapewniał dostęp do wszystkich poprzednich wersji danych oraz pozwalał nimi zarządzać. 5.10. System będzie posiadał zaawansowane narzędzia do importu danych w wielu formatach. 5.11. Elementem Systemu będzie repozytorium plików oczekujących na publikację na portalu. Dostęp do repozytorium będzie możliwy dla użytkowników wewnętrznych, którzy będą posiadać odpowiednie konto dostępu upoważniające do umieszczenia w repozytorium pliku z danymi. Pliki zamieszczane w repozytorium będą publikowane na portalu dopiero po ich akceptacji przez uprawnioną do tego osobę. 5.12. Elementem Systemu będzie repozytorium danych Systemu przeznaczone do przechowywania danych które będą udostępniane poprzez API. 5.13. System będzie dostarczał narzędzia służące do budowy API obydwu typów dla dowolnych danych które będą zamieszczane na portalu. 5.14. System będzie posiadał narzędzia zapewniające wykonywanie szybkich kopii danych z baz danych z systemów zewnętrznych do Systemu w celu udostępniania tych danych na portalu w formie API. 5.15. System będzie monitorował aktualność danych na podstawie atrybutów: ostatnia aktualizacja i częstotliwość aktualizacji. W przypadku wykrycia różnicy pomiędzy deklarowaną a rzeczywistą aktualizacją System będzie wysyłał powiadomienie do Administratora Systemu. 5.16. Każdy Administrator Systemu będzie mieć własny login i hasło. Do każdego konta mają być przypisane następujące informacje: Login, Imię, nazwisko, 9

Daty od / do obowiązywania konta, Uprawnienia do funkcji (role). 5.17. System musi posiadać narzędzie do budowy ról i uprawnień dostępne dla Administratora. Muszą być możliwe do utworzenia odrębne role dla różnych typów użytkowników Systemu zgodne z przydzielonymi im kompetencjami. 5.18. Systemu musi zapisywać i udostępniać historię wszystkich logowań. 5.19. System musi posiadać funkcjonalności wymagane do prawidłowego przetwarzania danych osobowych użytkowników z kluczem API. W szczególności: posiadać wbudowany regulamin korzystania z danych, który opracuje Zamawiający, wymagać akceptacji regulaminu i wyrażenia zgody na przetwarzanie danych osobowych przez użytkownika podczas rejestracji i rejestrować wyrażone zgody, umożliwiać usunięcie konta użytkownika wraz ze wszystkimi zapisanymi informacjami o nim z jednoczesną anonimizacją identyfikatora użytkownika zachowanego w Systemie. 5.20. System będzie umożliwiał wygenerowanie przynajmniej następujących raportów zawierających dane za wskazany dzień lub za podany przedział czasu: Liczba pobrań danych - łącznie, dla zbioru, dla dokumentu, Liczba odtworzeń danych - łącznie, dla zbioru, dla dokumentu, Liczba wejść na stronę z danymi - łącznie, dla zbioru. 5.21. Wykonawca przygotuje narzędzie, które umożliwi Administratorowi Systemu kopiowanie oprogramowania i danych ze Środowiska Produkcyjnego na Środowisko Testowe. 5.22. System musi mieć możliwość tworzenia kanałów RSS ze zdefiniowanych obszarów. 5.23. System musi mieć możliwość prowadzenia newslettera. 5.24. System musi zapewniać jego użytkownikom zewnętrznym możliwość wyszukiwania informacji w treści portalu oraz wg atrybutów i słów kluczowych danych publikowanych na portalu. 5.25. System będzie posiadał natywne wsparcie dla publikacji zasobów w dowolnym formacie. Zamawiający zamierza publikować zbiory danych w formacie RDF. System będzie umożliwiał automatyczne wystawianie punktów dostępowych do tych danych. Dane będą mogły zostać pobrane w jednej z czterech serializacji: RDF/XML, Turtle, Notation3 oraz JSON-LD do których będą konwertowane w locie, w trakcie wykonywania operacji odczytu. 5.26. System będzie udostępniał użytkownikom zewnętrznym portalu przynajmniej trzy e-usługi publiczne: usługa wnioskowania o pozyskanie nowych zbiorów danych oraz ich udostępniania usługa generowania kluczy dla API usługa automatycznego pobierania danych poprzez API 5.26.1. Usługa wnioskowania o pozyskanie nowych zbiorów danych oraz ich udostępniania System będzie pozwalał każdemu użytkownikowi portalu na złożenie wniosku o udostępnienie nowego zbioru danych i prowadził rejestr tych wniosków. Wnioski będą składane za pomocą elektronicznego formularza dostępnego na portalu, 10

Mapa procesu docelowego: 11

5.26.2. Usługa generowania kluczy dla API Aby uzyskać własny klucz API należy posiadać konto w Systemie. Konto jest zakładane na podstawie danych podanych w elektronicznym formularzu rejestracyjnym, po ich weryfikacji. System będzie prowadził rejestr wygenerowanych kluczy API. Usługa generowania kluczy dla API składa się z dwóch sekwencyjnych procesów: procesu rejestracji i procesu generowania kluczy dla API. Mapa procesu rejestracji: Mapa procesu generowania kluczy dla API: 5.26.3. Usługa automatycznego pobierania danych poprzez API. Poprzez API zewnętrzne systemy odbiorców będą mogły automatycznie pobierać dane, które są udostępnione na portalu. Warunkiem uzyskania dostępu do pobierania danych będzie posiadanie klucza API. Mapa procesu docelowego: 12

13