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

Transkrypt

1 Załącznik nr 2 do Ogłoszenia o dialogu technicznym (INF ) Minimalne wymagania dla systemu Otwartych Danych Miasta Bielska-Białej i jego wdrożenia. Spis treści 1. Koncepcja i cel Analiza przedwdrożeniowa Prototyp Budowa systemu informatycznego (wdrożenie) Rejestry źródłowe Wymagania ogólne Otoczenie prawne Moduły Centralnego Systemu Rejestrów Panel administracyjny Moduł kreatora rejestru Panel użytkownika wewnętrznego Panel publiczny Pozostałe wymagania funkcjonalne Wymaganie pozafunkcjonalne Integracja Testy systemu Bezpieczeństwo Szkolenia Dokumentacja Uwagi i wymagania ogólne Opis systemu Infrastruktura przetwarzania i składowania danych Dokumentacja administratora Opis konfiguracji systemu oraz parametrów systemu w warstwie aplikacyjnej Opis zarządzania użytkownikami i uprawnieniami w systemie w warstwie aplikacyjnej

2 Opis słowników wykorzystywanych w systemie Opis konfiguracji stacji roboczej lub urządzenia klienckiego dla użytkownika systemu Opis wymagań dla systemów teleinformatycznych w odniesieniu do rozporządzenia w sprawie Krajowych Ram Interoperacyjności (KRI) Licencje i gwarancje Licencje Gwarancje i Serwis Procedury Procedury eksploatacyjne Procedury awaryjne i odtworzeniowe Procedura wykonania kopii danych i konfiguracji z systemu produkcyjnego na testowy Dokumentacja użytkownika Wymogi dokumentacji w odniesieniu do danych osobowych Wymagania dotyczące kodów źródłowych Utrzymanie systemu

3 1. Koncepcja i cel Głównym celem projektu Otwartych Danych Miasta Bielska-Białej jest udostępnienie informacji tworzonych przez organy administracji samorządowej miasta Bielska-Białej przeznaczonych do powszechnego, automatycznego udostępniania tj. do przeszukiwania i wykorzystania przez każdego, kto takimi informacjami byłby zainteresowany. Projekt Otwartych Danych Miasta Bielska-Białej rozumiany jest jako przedsięwzięcie składające się z rozwiązań organizacyjnych, sprzętu informatycznego i oprogramowania. Oprogramowanie w dalszej części nazywane będzie systemem Open Data lub OPEN DATA. Realizacja projektu Otwartych Danych Miasta Bielska-Białej ma również na celu: wprowadzenie wykazu rejestrów i zbiorów danych w Urzędzie, z klasyfikacją zakresu danych przeznaczonych do powszechnego udostępniania, wprowadzenie standardu prowadzenia rejestrów i zbiorów danych, wdrożenie rozwiązań informatycznych za pomocą których: o prowadzone i udostępniane będą istniejące rejestry i ewidencje dotychczas utrzymywane poza systemami dziedzinowymi, w postaci tabel w aplikacji Word lub Excel, o udostępniane będą wybrane dane z systemów dziedzinowych, usprawnienie pracy jednostek administracyjnych poprzez eliminację większości rejestrów papierowych, eliminację podwójnych rejestrów (wprowadzenie jednego rejestru z możliwością przechowywania załączników, określania statusu i możliwością uzupełniania przez różne wydziały merytoryczne), eliminację problemu aktualizacji udostępnionych danych (zbiory danych udostępniane online bezpośrednio z rejestru przez generator raportów), zmniejszenie zapytań kierowanych do jednostek administracji samorządowej o dane publiczne. 2. Analiza przedwdrożeniowa Wykonawca jest zobowiązany przygotować szczegółowy dokument analizy przedwdrożeniowej. Analiza przedwdrożeniowa zostanie opracowana w oparciu o: Inwentaryzację i analizę wskazanych źródeł danych (Zamawiający określi na etapie udzielania zamówienia źródła danych w załączniku nr 1 Specyfikacja rejestrów do implementacji) w celu udostępniania rejestrów i publikacji danych za pomocą OPEN DATA, wymagania określone w umowie i OPZ. Analiza winna być wykonana z wykorzystaniem najlepszych praktyk w analogicznych projektach otwierania danych publicznych oraz z wykorzystaniem wiedzy i doświadczenia Wykonawcy. Dokument analizy przedwdrożeniowej musi zawierać w szczególności: 1) Opis środowiska biznesowego, w tym: celów biznesowych, opis wszystkich procesów biznesowych, przypadków użycia które będzie realizował system, szczegółowy opis wszystkich funkcji dostępnych w systemie rozpisanych na role i zakres odpowiedzialności, 3

4 szczegółowy opis instalacji i konfiguracji niezbędnych do uzyskania wszystkich wymaganych przez Zamawiającego funkcji, 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. 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, aktualizacji wspólnych dla systemu słowników wraz z przypisaniem ról i odpowiedzialności, 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, uwzględniających wymagania RODO, opis systemów jego komponentów, powiązań oraz schematów przepływu danych, z przypisaniem poszczególnych wymagań Zamawiającego do poszczególnych elementów systemu oraz opis wymagań dla środowiska wirtualnego, inne zagadnienia techniczne. 3) Harmonogram szczegółowy prac wdrożeniowych zawierający: podział na Etapy i przypisanie do nich Produktów, plan szkoleń, plan testów akceptacyjnych. 4) Opis instalacji i konfiguracji środowiska testowego i produkcyjnego. 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 oraz dane kontaktowe. 6) Opis integracji Systemu, w tym: sposób, zakres i częstotliwość integracji Systemu z systemami zewnętrznymi wykorzystywanymi przez Zamawiającego, interfejsy wymiany informacji gromadzenia i prezentacji danych. 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, 8) Zakres testów Systemu, w tym: opis testów funkcjonalnych, wydajnościowych i bezpieczeństwa Systemu, plan i scenariusze testów akceptacyjnych. 9) Analizę ryzyka dotyczącą zabezpieczeń OPEN DATA z uwzględnieniem wymagań RODO. 10) Opis zastosowanych zabezpieczeń Systemu adekwatnych do oszacowanego ryzyka, o którym mowa w poprzednim punkcie. 3. Prototyp 1) Wykonawca jest zobowiązany opracować Prototyp stanowiący model przyszłego systemu OPEN DATA. 2) Prototyp będzie zbudowany we wstępnie przygotowanym środowisku testowym systemu. 4

5 3) Prototyp będzie miał przygotowaną wstępną strukturę portalu www oraz zaimplementowaną grafikę wybraną przez Zamawiającego spośród 3 projektów graficznych interfejsu graficznego systemu, które Wykonawca opracuje i przedstawi Zamawiającemu. Wizualizacje mają być zgodne z projektem i założeniami nowej strony Urzędu Miejskiego. 4) Prototyp będzie posiadał bazowe funkcje systemu oraz będzie częściowo zasilony danymi ze wskazanych rejestrów w celu zademonstrowania możliwości zamieszczania danych różnych rodzajów. 5) Prototyp będzie miał przygotowany panel administratora z zaimplementowanymi najważniejszymi funkcjami. 4. Budowa systemu informatycznego (wdrożenie) 1) Budowa OPEN DATA będzie przebiegać zgodnie ze szczegółowymi ustaleniami określonymi w Analizie Przedwdrożeniowej. 2) Wykonawca dostarczy standardowe oprogramowanie aplikacyjne, zainstaluje je we własnym środowisku testowym i udostępni Zamawiającemu. 3) Wykonawca przygotuje rejestry, zmigruje dane (z rejestrów wskazanych na etapie udzielania zamówienia). 4) Wykonawca jest zobowiązany do opracowania mechanizmów zasilania rejestrów danymi z plików zewnętrznych (txt, xls, csv). 5) Wykonawca udostępni Zamawiającemu system do przeprowadzenia testów. 6) 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. 7) Wykonawca przygotuje i odda Zamawiającemu do użytkowania zarówno środowisko produkcyjne jak i testowe. Zamawiający zakłada, że: Środowisko Testowe będzie dostępne tylko dla Administratorów systemu. 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. Jeżeli w okresie testowania wymagana jest licencja dla Zamawiającego, Wykonawca udostępni mu niezbędne licencje. 5. Rejestry źródłowe Wykonawca przygotuje w systemie OPEN DATA rejestry wskazane w załączniku nr 1 (Zamawiający wskazany załącznik doda na etapie udzielania zamówienia) oraz dokona z nich migracji danych. 1) Dane umieszczane w Systemie będą miały przypisane przynajmniej poniższe atrybuty: Źródło (źródłem jest rejestr - nazwa rejestru) Kategoria Częstotliwość aktualizacji Ostatnia modyfikacja Utworzono Liczba wyświetleń Liczba pobrań Typ API 5

6 Stopień otwartości danych wg pięciogwiazdkowej skali Star Open Data. Dane umieszczane na portalu muszą mieć możliwość przypisywania do nich słów kluczowych. 6. Wymagania ogólne System będzie służył do prowadzenia 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. System OPEN DATA powinien być nowoczesnym narzędziem, zapewniającym interfejs z użytkownikiem przez dynamiczne strony WWW umożliwiającym: logowanie z poziomu strony WWW przez podanie loginu i hasła (opcjonalnie uwierzytelnianie za pomocą certyfikatów), dostęp do systemu z dowolnego miejsca z dostępem do Internetu, dowolne tworzenie i modyfikacje tabel rejestrów przez uprawnione osoby, wprowadzanie danych do utworzonych tabel, edycję danych w tabelach wg przyznanych uprawnień dla użytkownika, wprowadzanie do prowadzonych rejestrów załączników w postaci dowolnego formatu dokumentu elektronicznego, archiwizację danych poprzez tworzenie kopii archiwalnych rejestrów, dostęp do portalu na poziomach użytkownika i administratora, interfejs publikacji i prezentacji danych zapisywanych w rejestrach, system powinien zapewniać ochronę danych osobowych zgodnie z obowiązującym prawem, w tym rozwiązania techniczne wskazane w Wymogach dokumentacji w odniesieniu do danych osobowych (pkt 15.8 ). System powinien spełniać wymagania rozporządzenia w sprawie Krajowych Ram Interoperacyjności, tzn. powinien zapewnić spełnienie minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych. Wykonawca w ramach wykonania przedmiotu zamówienia dostarczy kod źródłowy systemu OPEN DATA. Wykonawca przedstawi propozycję regulaminu świadczenia usług dla użytkowników zewnętrznych, zarówno w zakresie udostępniania, jak i wykorzystania danych poprzez witrynę i mechanizmy integracyjne. Zamawiający nie dopuszcza prezentacji na portalu WWW (zarówno w widoku wewnętrznym, jak i zewnętrznym) żadnych informacji dot. Wykonawcy oraz żadnych nazw produktów, technologii, oznaczeń graficznych (np. loga), chyba, że wcześniej wyrazi zgody na umieszczenie takich obiektów. Zamawiający wymaga, aby wszelkie dostarczone i wymagane do obsługi systemu licencje były nieograniczone, wieczyste. 7. Otoczenie prawne 1) System będzie zgodny z obowiązującymi oraz tymi przepisami prawa, 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 oraz Ustawą z dnia 25 lutego 2016 r. o ponownym wykorzystywaniu informacji 6

7 sektora publicznego, a także przepisami prawa miejscowego (uchwałami Rady Miasta Bielska-Białej) oraz Decyzjami i Zarządzeniami Prezydenta Miasta Bielska-Białej dotyczącymi realizacji zadań z zakresu udostępniania informacji sektora publicznego. 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) 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 dalej KRI. 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. 4) System będzie spełniał wymogi Ustawy z dnia 29 sierpnia 1997 r. o ochronie danych osobowych. 5) 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. 6) System musi działać pozostając w zgodzie z polityką bezpieczeństwa wdrożoną przez Zamawiającego i Instrukcją 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 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych oraz art. 36 ust. 2 ustawy z dnia 29 sierpnia 1997 r. o ochronie danych osobowych. 7) System będzie spełniał wymogi standardu bezpieczeństwa Open Web Application Security Project ASVS na poziomie 2. 8) Jeżeli w trakcie udzielania zamówienia lub realizacji Umowy na budowę systemu OPEN DATA nastąpią zmiany w ww. aktach prawnych lub zostaną zastąpione przez inne akty, rozwiązanie implementowane przez Wykonawcę musi być zgodne z aktualnym stanem prawnym. Wykonawca musi na dzień odbioru systemu dostosować go do obowiązującego prawa. 9) System OPEN DATA nie może prowadzić do działania Zamawiającego niezgodnego z prawem obowiązującym Zamawiającego. 8. Moduły Centralnego Systemu Rejestrów. 8.1 Panel administracyjny 1) 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 i zarządzaniu treścią portalu. 2) Poziom administracyjny zastrzeżony dostęp dla administratorów, umożliwiający tworzenie wielopoziomowego systemu uprawnień: a. tworzenie użytkowników systemu, b. tworzenie grup użytkowników, c. przypisywanie użytkowników do grup, d. budowanie ról i nadawanie uprawnień, 7

8 e. przypisywanie poszczególnym grupom wybranych uprawnień funkcjonalnych typu minimum: tworzenie rejestrów, tworzenie i edycja słowników, edycja danych w rejestrach, dostęp do konkretnych rejestrów, uprawnienia dla wskazanych kolumn (pól) utworzonych tabel, dodawania załączników, publikowania części/całości rejestru. f. tworzenie kategorii danych i zarządzanie nimi, g. konfigurowanie sposobu prezentacji danych, h. zarządzanie treścią portalu, i. publikowanie informacji i komunikatów do użytkowników, j. konfigurowanie API do danych. 3) Wymaga się skonfigurowania w systemie ról: Administratorzy pracownicy Zamawiającego posiadający konto administratora systemu, odpowiedzialni za wszystkie czynności związane z prowadzeniem i parametryzacją systemu. Użytkownicy wewnętrzni pracownicy Zamawiającego odpowiedzialni za prowadzenie rejestru i wprowadzanie danych. Użytkownicy wewnętrzni będą mieli w systemie konto użytkownika z uprawnieniami nadanymi przez Administratora Systemu. Wykonawca skonfiguruje role użytkowników wewnętrznych minimum wg następujących kategorii i możliwości: 1. Użytkownik podstawowy edytuje i wprowadza dane, nie ma możliwości publikacji wprowadzonych danych w widoku publicznym. 2. Użytkownik podstawowy z publikacją dziedziczy uprawnienia z pkt 1, ma możliwość publikacji danych w widoku publicznym. 3. Użytkownik zaawansowany kreator struktury rejestrów, dziedziczy uprawnienia z pkt 1-2, ma możliwość tworzenia i edycji stworzonych lub przypisanych rejestrów. 4. Supervisor dziedziczy uprawnienia 1-3, ma dostęp do rejestrów utworzonych w systemie wraz z możliwością parametryzacji systemu, z wyłączeniem nadawania uprawnień i tworzenia użytkowników. 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. 4) Moduł raportowy dostępny dla uprawnionych osób: statystyki dotyczące obsługi utworzonych rejestrów (ilość, czas obsługi, typ czynności edycja rekordu rejestru, dodanie nowego rekordu rejestru, usuwanie rekordu rejestru), statystyki użytkowników, system będzie umożliwiał wygenerowanie następujących raportów zawierających dane za wskazany dzień lub za podany przedział czasu: a. liczba odtworzeń danych - łącznie, dla zbioru, dla dokumentu, b. liczba wejść na stronę z danymi - łącznie, dla zbioru, c. ilość pobrań z udostępnionych rejestrów (łącznie, dla zbioru, dla dokumentu) z wyszczególnieniem: nazwy rejestru, formatu pliku eksportowanego, nazwy użytkownika w przypadku użytkownika wewnętrznego. 8.2 Moduł kreatora rejestru 1) Moduł kreatora rejestru dostępny w panelu administracyjnym, jak również w panelu użytkownika wewnętrznego, jeżeli zostaną mu przyznane uprawnienia do tworzenia rejestrów: 8

9 system umożliwia tworzenie dowolnej ilości rejestrów w postaci kreatora tabel, system umożliwia tworzenie kategorii do których przypisywane będą rejestry, system umożliwia przypisanie użytkownika do utworzonego rejestru, system umożliwia określenie ilości kolumn (pól) w tworzonej tabeli wraz z określeniem formatu (walidacji) danych jakie będą przechowywane w rejestrze, w tym: pole tekstowe, pole liczbowe, pole daty, pole godziny, pole waluty (zł, euro, dolar), pole umożliwiające dodawanie załączników, pole automatycznie sczytujące bieżącą datę, pole automatycznie sczytujące nazwę użytkownika edytującego na podstawie loginu, pole słownika z możliwością podpięcia dostępnego słownika, pole listy rozwijanej powiązanej ze słownikiem, pole numeru NIP, pole numeru PESEL, pole numeru REGON, pola związane z danymi osobowymi muszą być automatycznie znakowane w celu wyodrębnienia z bazy, system umożliwia zamykanie rejestru za dany okres, tworzenie nowego rejestru na podstawie już utworzonego z możliwością zaciągnięcia z istniejącego rejestru danych, archiwizacje w zadanym okresie z określeniem daty przeniesienia do archiwum, cykliczności zamykania i tworzenia nowego rejestru (np. co rok, kwartał, miesiąc), formaty daty, godziny, liczby ma być definiowany z poziomu administratora dla całego systemu OPEN DATA. system umożliwia określenie nazw nagłówka dla pól tworzonej tabeli, system umożliwia tworzenie słowników wykorzystywanych w rejestrach, system umożliwia określenie, który rejestr będzie udostępniany w panelu publicznym, system umożliwia określenie m.in., które kolumny rejestru będą udostępniane w panelu publicznym, a które będą dostępne tylko dla użytkownika wewnętrznego, system umożliwia nadanie wierszom/polom statusu niejawności, który spowoduje ukrycie w widoku publicznym oznaczonego pola/wiersza, system zapewnia również prosty mechanizm (checkbox) publikacji danych w panelu publicznym, system umożliwia tworzenie funkcji dla zawartości rejestrów m.in. sumowanie, różnice, mnożenie, dzielenie, zliczanie pozycji, system umożliwia określenie rejestru jako aktywny/nieaktywny, gdzie rejestr oznaczony jako nieaktywny jest niedostępny dla użytkowników, system umożliwia stworzenie rejestru za pomocą kreatora poprzez import danych z pliku zewnętrznego w formacie.xls,.csv,.txt, system umożliwia import danych z zewnętrznych systemów poprzez API lub/i szynę danych Biztalk, system umożliwia porównywanie danych z założonych rejestrów i tworzenie nowych rejestrów na podstawie wyniku porównania, system udostępnia możliwość wydruku: widoku rejestru poprzez przycisk Drukuj oraz rejestru poprzez Drukuj cały rejestr. 8.3 Panel użytkownika wewnętrznego 1) Po zalogowaniu do systemu otwiera się widok z minimum następującymi zakładkami (opcjami wyboru): Moje rejestry - lista(z uprawnieniami do edycji/publikacji) Wszystkie rejestry - lista (podgląd) Tworzenie rejestrów (wg nadanych uprawnień) 9

10 2) Zakładka z listą wszystkich rejestrów ma być z podziałem na utworzone kategorie. Wybierając dedykowany rejestr z listy otwiera się widok z rejestrem do obsługi, np.: Rejestry Urzędu Miejskiego w Bielsku-Białej Kategoria1 Centralna ewidencja udostępniania informacji publicznej Rejestr uchwał Rejestr zarządzeń.. Kategoria2 Centralny rejestr umów. 3) Panel użytkownika umożliwia przeszukiwanie rejestrów wg dowolnego ciągu znaków. Użytkownik posiada możliwość wyszukiwania, filtrowania danych z kolumny według dowolnego rekordu w niej zawartego i sortowania danych (rosnąco, malejąco) w rejestrze wg dowolnej kolumny z danymi. Użytkownik, wg posiadanych uprawnień, może przeglądać dane lub dokonywać zmian w tabeli rejestru przez dodanie nowego rekordu w tabeli, edycję istniejących rekordów tabeli, dodawanie/usuwanie załączników. 4) Edycja danych w rejestrze odbywa się w widoku tabeli przez uprawnionych użytkowników (np. po wyborze przycisku akcji Edycja przechodzi w tryb edycji danych). 5) Wprowadzone zmiany w tabelach są zapisywane po potwierdzeniu zapisu danych przez użytkownika, co powoduje automatyczne zapisanie danych użytkownika dokonującego zmian, wygenerowanie wersji archiwalnej rejestru bez publikacji. 6) Publikacja następuje po zapisie i potwierdzeniu osobnym przyciskiem Publikuj w widoku publicznym. 7) System prowadzi automatyczny rejestr zmian rekordów i rejestrów zgodnie z zapisami KRI. 8) System umożliwia eksport danych jak dla panelu publicznego. 10

11 9) Moduł raportowy związany z rejestrem możliwość określenia statystyk dla powtarzających się rekordów za pomocą działań: zliczanie, sumowanie, różnice. 8.4 Panel publiczny Panel publiczny jest udostępniony każdemu pod określonym linkiem i nie wymaga żadnego uwierzytelniania. 1) Panel publiczny zawiera listę udostępnionych rejestrów z podziałem na utworzone instytucje, kategorie, np.: Rejestry Urzędu Miejskiego w Bielsku-Białej Centralna ewidencja udostępniania informacji publicznej Rejestr uchwał Rejestr zarządzeń Rejestr umów.. Rejestry Miejskiego Zarządu Dróg Rejestr zarządzeń Rejestr umów.. 2) Po wybraniu jednostki wyświetlona jest lista rejestrów przeznaczona do widoku publicznego. 3) Każda jednostka ma być na odrębnej stronie/podstronie portalu, której adres będzie możliwy do podlinkowania na stronie np. BIP i przekieruje bezpośrednio do strony OPEN DATA z widokiem publicznym rejestrów jednostki. 4) System umożliwia wyszukiwanie rejestrów według zadanego ciągu znaków. Wynik wyszukiwania jest ograniczony do zawężonej listy znalezionych rejestrów. 5) Po wybraniu określonego rejestru z listy otwiera się widok prezentujący dane zawarte w rejestrze. Widok z danymi prezentowany jest wyłącznie w trybie podglądu danych wraz z możliwością pobrania udostępnionych w rejestrze załączników. 6) Każdy rejestr powinien mieć swoją podstronę, której adres po dodaniu na stronę (np. BIP) będzie przekierowywał do konkretnego rejestru w widoku publicznym OPEN DATA. Adresy stron/podstron poszczególnych jednostek i rejestrów będą prezentowane w osobnej tabeli w panelu administracyjnym. 7) W udostępnionym widoku istnieje możliwość pobrania całego zakresu rejestru lub widoku według założonych filtrów w formacie.xls,.csv,.pdf, gdzie w przypadku załączników 11

12 umieszczonych w rejestrze, do pliku zapisywany jest ciąg znaków sczytywany z nazwy pliku załącznika. Nazwa pliku zawiera czas pobrania rejestru. 8) System udostępnia możliwość wydruku: widoku rejestru poprzez przycisk Drukuj oraz rejestru poprzez Drukuj cały rejestr. 9) System umożliwia pobieranie załączników umieszczonych w rejestrze. 10) Użytkownik posiada możliwość wyszukiwania rekordów w rejestrze wg dowolnego ciągu znaków, filtrowania i sortowania danych w rejestrze wg dowolnej kolumny z danymi. Wynik wyszukiwania, filtrowania, sortowania w rejestrze jest zawężony do znalezionych rekordów według zadanych parametrów. 11) Publikowane rejestry muszą zawierać rejestr zmian - informację z datą utworzenia rekordu, informację o aktualności danych w rejestrach, jak również informację identyfikującą osoby publikujące. 12) Panel publiczny musi zapewnić dostęp do wersji archiwalnych rejestrów. 9. Pozostałe wymagania funkcjonalne 1) System będzie zbudowany na platformie przystosowanej do realizacji projektów związanych z udostępnianiem otwartych danych, wyposażonej w takie funkcje jak: wbudowane API, obsługa google.maps, podgląd danych, generowanie wykresów, zestawień, historia danych, własny CMS. 2) Implementacja Systemu zostanie przeprowadzona w sposób, który zapewni kompatybilność Systemu z krajową platformą danych otwartych w szczególności w zakresie określonych tam kategorii danych i atrybutów danych. 3) System będzie przystosowany do udostępniania danych w postaci plików, usług, API. 4) Planowane są dwa typy API - powszechne i z kluczem. 5) System będzie udostępniał narzędzia do prezentacji danych w postaci tabeli, wykresów, dokumentów, obrazów bez konieczności ich pobierania. 6) Dane umieszczane na portalu będą objęte mechanizmem automatycznej archiwizacji. System będzie przechowywał historię danych, zapewniał dostęp do poprzednich wersji danych umieszczonych w systemie oraz pozwalał nimi zarządzać. 7) System będzie posiadał zaawansowane narzędzia do importu danych w formatach wymaganych w KRI. 8) Elementem Systemu będzie repozytorium danych Systemu przeznaczone do przechowywania danych, które będą udostępniane poprzez API funkcjonalność na potrzeby przyszłych integracji z systemami dziedzinowymi wymagane będą interfejsy umożliwiające integrację. 9) 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. 10) System będzie posiadał narzędzia zapewniające wykonywanie kopii danych z baz danych z systemów zewnętrznych do Systemu w celu udostępniania tych danych na portalu w formie API funkcjonalność na potrzeby przyszłych integracji z systemami dziedzinowymi. 11) 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 funkcjonalność na potrzeby przyszłych integracji z systemami dziedzinowymi. 12) 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, 12

13 imię, nazwisko, daty od/do obowiązywania konta, uprawnienia do funkcji (role). 13) System musi zapisywać i udostępniać historię wszystkich logowań. 14) System musi posiadać funkcje wymagane do prawidłowego przetwarzania danych osobowych użytkowników z kluczem API zgodnie z wymaganiami RODO. W szczególności: posiadać wbudowany regulamin korzystania z danych, 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. 15) System będzie posiadał natywne wsparcie dla publikacji zasobów w formacie wymaganym w KRI. 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. 16) 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. 10. Wymaganie pozafunkcjonalne. 1) System będzie zapewniał ciągły dostęp i będzie działał w trybie on-line 24h, 7 dni w tygodniu z wyłączeniem okien serwisowych. 2) System będzie zainstalowany na infrastrukturze Zamawiającego. 3) 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 sesji przy zwiększonych jedynie zasobach infrastruktury serwerowej. 4) System musi zapewniać ciągłość sesji użytkowników i umożliwiać ograniczenie jej trwania. 5) System musi zapewniać ochronę bazy danych przed utratą spójności lub zniszczeniem ze strony interfejsu użytkownika. 6) Lokalna baza danych Systemu (repozytorium danych Systemu) musi być dostosowana do działania w systemie zarządzania relacyjnymi bazami danych (RDBMS). 7) 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. 8) Systemu musi być zbudowany w oparciu o architekturę wielowarstwową z wydzieloną co najmniej warstwą prezentacji, logiki biznesowej (przetwarzania) i danych (składowania). 9) Żadna z funkcji i właściwości Systemu nie może być ograniczona w czasie, zarówno pod względem formalno-prawnym, jak i technicznym. 10) Konieczne jest zapewnienie środków uniemożliwiających nieautoryzowany dostęp na poziomie baz danych, usług sieciowych i aplikacji. 11) Wymagane jest wdrożenie zabezpieczeń informacji w sposób uniemożliwiający nieuprawnionemu jej ujawnienie, modyfikacje, usunięcie lub zniszczenie. 12) 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. 13

14 13) System musi działać prawidłowo w środowisku zwirtualizowanym VMware vsphere (ze względu na istniejącą infrastrukturę Zamawiającego) i nie może mieć żadnych ograniczeń licencyjnych w związku z umieszczeniem go w środowisku zwirtualizowanym (Zamawiający wymaga licencji nieograniczonej, wieczystej). 14) 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 zasoby klastra VMware vsphere nie przekraczające łącznie: 2 procesory 2 rdzeniowe, 12GB RAM, Wykonawca przekaże wszelkie niezbędne licencje Zamawiającemu, w tym na system operacyjny maszyny wirtualnej, z której korzystać będzie OPEN DATA. Serwer będzie w DMZ Zamawiającego, który jest oparty na fizycznych komputerach, na których zainstalowany jest System ESX wersja 6 (technologia VMWare). Stanowią one platformę sprzętową dla Vcenter. 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. 15) System musi obsługiwać API (REST lub SOAP) na potrzeby przyszłej integracji z systemami źródłowymi. 16) 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. Dane muszą być przechowywane bezpiecznie w formie zewnętrznego pliku danych. 17) 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. 18) 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. 19) System będzie poprawnie wyświetlany na urządzeniach mobilnych opartych na systemach Android i ios Wymagana jest responsywność Systemu. 20) System będzie korzystał z usługi Google Analitics w celu pozyskiwania statystyk portalu ilość odwiedzin, sesji itp. 21) System będzie posiadał Pomoc kontekstową oraz interfejs w języku polskim. 22) Struktura Systemu musi umożliwiać w przyszłości wprowadzenie dodatkowych wersji językowych portalu. 23) 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. 24) Obsługa Systemu musi być intuicyjna. 11. Integracja. 1) Zamawiający przewiduje, że system OPEN DATA powinien umożliwiać integrację z systemami zewnętrznymi, która docelowo będzie polegała na: plikowej wymianie danych, pobieraniu danych z systemu zewnętrznego poprzez usługę sieciową np. Webservices, z portalu poprzez API dotyczy w szczególności danych, które będą udostępniane na portalu w trybie on-line, 14

15 szyna danych Biztalk (opcjonalnie), w inny, ustalony pomiędzy Zamawiającym a Wykonawcą, sposób. 2) System musi posiadać możliwość utworzenia interfejsów, które pozwolą w przyszłości na zintegrowanie go z zewnętrznymi systemami informatycznymi, z których będą pochodziły nowe dane udostępniane na portalu. 3) Integracje z poszczególnymi systemami dziedzinowymi będą się odbywały na podstawie odrębnych zamówień od niniejszego. 12. Testy systemu 1) System przejdzie akceptacyjne testy funkcjonalne, wydajnościowe i bezpieczeństwa. 2) Wykonawca jest zobowiązany opracować i zrealizować plan testów, scenariusze testowe oraz dane testowe dla każdego obszaru funkcjonowania systemu. 3) Szczegółowy zakres testów oraz plan i scenariusze testów zostaną zawarte i uzgodnione w Analizie Przedwdrożeniowej. 4) W ramach testów Wykonawca przeprowadzi audyt bezpieczeństwa Systemu na zgodność ze standardem OWASP ASVS na poziomie 2 i przedstawi Zamawiającemu raport z audytu potwierdzający spełnienie powyższego standardu. 13. Bezpieczeństwo 1) System musi zapewniać ochronę bazy danych przed utratą spójności lub zniszczeniem ze strony interfejsu użytkownika. 2) Konieczne jest zapewnienie środków uniemożliwiających nieautoryzowany dostęp na poziomie baz danych, usług sieciowych i aplikacji. 3) Wymagane jest wdrożenie zabezpieczeń informacji w sposób uniemożliwiający nieuprawnionemu jej ujawnienie, modyfikacje, usunięcie lub zniszczenie. 4) 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. 14. Szkolenia Wymagane jest przeprowadzenie szkoleń: 1) Szkolenie z zakresu obsługi i funkcji utworzonego systemu OPEN DATA, 2) Szkolenie dla 4 administratorów w siedzibie Zamawiającego. 3) Szkolenie certyfikowane dla 4 osób dotyczące rodzaju bazy danych systemu, obejmujące podstawy obsługi bazy danych oraz jej administrowanie, z uwzględnieniem ścieżki certyfikacyjnej jeżeli dostawca bazy taką posiada. 4) Uczestnicy szkolenia otrzymają certyfikaty ze szkoleń o których mowa w pkt 1 i 2. 5) Wykonawca przygotuje materiały na szkolenie w formie prezentacji multimedialnej oraz w formie wydruku dla każdego z uczestników szkolenia. 15. Dokumentacja Szczegółowe wymogi dotyczące dokumentacji 15

16 15.1 Uwagi i wymagania ogólne 1) Dokumentacja powinna zostać dostarczona w wersji elektronicznej edytowalnej i dodatkowo w wersji papierowej. W związku z powyższym wersja elektroniczna powinna być dostarczona dla: a) dokumentów tekstowych w formacie PDF z możliwością przeszukiwania, również wyrazów z polskimi znakami i możliwością zaznaczania kopiowania treści, b) dokumentów tekstowych w formacie DOC (lub innym ogólnie dostępnym formacie edytowalnym). 2) W przypadku diagramów, schematów dostarczonych w ramach dokumentacji powinny one być zgodne z notacjami UML, BPMN lub Archimate i zapisane w formacie umożliwiającym ich przeglądanie z możliwością przeszukiwania w dostępnych publicznie i darmowych narzędziach, wraz ze wskazaniem źródła ich pobrania lub poprzez dostarczenie niezbędnego do przeglądania oprogramowania w ramach projektu. 3) Dokumentacja powinna uwzględniać wszystkie dostarczone środowiska systemu, takie jak środowisko produkcyjne, testowe/szkoleniowe czy deweloperskie. 4) Zawartość dokumentacji powinna być czytelna i spójna (dotyczy grafik, wykresów, diagramów). 5) W odniesieniu do wymagań edytorskich: a) szablon dokumentu z wymaganymi elementami dostarczy Zamawiający, b) preferowany format dokumentacji (wielkość strony) A4, c) czcionka o kroju Verdana, d) wersjonowanie dokumentacji format wersji n.xx, gdzie n oznacza numer kolejnej zatwierdzonej wersji dokumentu, xx numer kolejnej wersji opiniowanej, roboczej. 6) W ramach dokumentacji dostarczone powinny być: a) zestawienie wszystkich uzgodnień i protokołów podpisanych na etapie realizacji, b) globalny rejestr zmian dotyczący dokumentacji powykonawczej. 7) Dokumentacja ma być napisana w języku polskim Opis systemu Opis techniczny systemu powinien obejmować: 1) Schemat blokowy systemu wraz z opisem jego składowych oraz przepływu i przetwarzania danych w systemie. 2) Diagram wdrożenia (deployment diagram) obejmujący wszystkie składowe systemu (w nomenklaturze UML: węzły, środowiska wykonawcze, komponenty/artefakty), wraz ze ścieżkami komunikacji pomiędzy składowymi oraz systemami zewnętrznymi z opisem wykorzystywanych protokołów i portów wszystkich uruchomionych w systemie usług Infrastruktura przetwarzania i składowania danych Szczegółowy techniczny opis systemu w warstwie transmisji, przetwarzania i składowania danych zawierający w szczególności następujące informacje: 1) Zestawienie serwerów fizycznych i wirtualnych, które są wykorzystywane przez system, obejmujące: nazwę serwera (HOSTNAME), adres sieciowy (IP), specyfikację/konfigurację sprzętową, funkcję serwera w architekturze systemu (np. serwer bazodanowy, aplikacyjny, komunikacyjny, webowy itp.). 2) Opis konfiguracji składowych systemu na serwerach obejmujący: a) opis wykonanej lub wymaganej organizacji zasobów na serwerach, w szczególności konfigurację przydziału zasobów takich jak: procesory, pamięć, dyski, systemy plików, urządzenia I/O, 16

17 b) zrzut zainstalowanego oprogramowania na poszczególnych serwerach, w tym wersji i włączonych opcji, c) opis konfiguracji, w tym rozlokowania składowych oprogramowania, sposobu logowania błędów, mechanizmów bezpieczeństwa i niezawodnościowych, d) włączone/skonfigurowane niedomyślne parametry i funkcje urządzeń i oprogramowania, e) zestawienie kont i uprawnień niezbędnych do prawidłowego działania systemu, f) zrzut plików/rejestrów konfiguracyjnych wraz z opisem. 3) Opis konfiguracji podsystemu składowania danych obejmujący: a) opis topologii i konfiguracji infrastruktury SAN, b) opis organizacji i konfiguracji zasobów na macierzach i bibliotekach taśm, c) zrzut konfiguracji urządzeń podsystemu składowania danych. 4) Opis konfiguracji podsystemu bazodanowego obejmujący: a) listę instancji baz danych wykorzystywanych przez system, b) zestawienie kont i schematów bazodanowych wraz z wymaganymi uprawnieniami niezbędnymi do prawidłowego działania systemu, c) opis włączonych opcji i konfiguracji oprogramowania silnika bazodanowego, d) zrzut konfiguracji uruchomieniowej poszczególnych instancji baz danych oraz powiązanych procesów i usług (np. nasłuchu, monitorowania, archiwizacji, klastrów). 5) Zestawienie portów i protokołów komunikacyjnych wykorzystywanych w komunikacji pomiędzy wszystkimi składowymi systemu i systemami zewnętrznymi. 6) Zrzut inicjalnego stanu systemu, w szczególności: wykorzystanie/zajętość zasobów dyskowych w warstwie sprzętowej (macierzy, serwerów), systemów plików oraz wewnętrznie baz danych, uruchomione procesy/usługi, obciążenie systemów i kanałów transmisji danych Dokumentacja administratora Opis konfiguracji systemu oraz parametrów systemu w warstwie aplikacyjnej W ramach opisu powinny zostać umieszczone informacje dotyczące parametryzacji systemu w jego warstwie aplikacyjnej, w tym: 1) Specyfikacja parametrów systemu wraz z ich opisem. 2) Opis wpływu parametrów na działanie systemu. 3) Procedura restartu umożliwiająca bezpieczne wyłączenie (zablokowanie) i włączenie (odblokowanie) systemu wraz z informacją o wpływie restartu na pozostałe elementy/moduły systemu. 4) Opis dotyczący diagnozowania błędów programowych, sposoby śledzenia działania systemu. 5) Opis logów powstających podczas pracy, wskazanie sposobu interpretacji informacji zawartej w zapisach. 6) Wykaz komunikatów błędów, ostrzeżeń oraz ich opisy. 7) Opis konfiguracji systemu w warstwie aplikacji. 8) Sposób umieszczania komunikatów na stronie głównej www systemu (dla aplikacji webowych). 9) Opis integracji z innymi systemami, szczegółowy opis powiązań pomiędzy systemami wraz ze schematem, specyfikacja interfejsów, opis konfiguracji w systemie, opis parametrów w systemie itp.. 10) Opis tworzenia kopii zapasowych, backupów, potencjalnych przyrostów (spójne z procedurami ). 17

18 Opis zarządzania użytkownikami i uprawnieniami w systemie w warstwie aplikacyjnej Opis dotyczący zarządzania użytkownikami i uprawnieniami w warstwie aplikacyjnej powinien ujmować: 1) Proces tworzenia i usuwania użytkowników oraz modyfikacji i odbierania uprawnień (w formie instrukcji) w warstwie oprogramowania funkcjonalnego systemu. 2) Opis sposobu zmiany haseł użytkowników (lub identyfikacja za pomocą certyfikatów) wraz z uwzględnieniem wymagań co do ilości znaków oraz dozwolonych znaków dla haseł użytkowników systemu. 3) Wykaz ról, profili użytkownika i uprawnień zdefiniowanych w systemie wraz z opisem. 4) Raportowanie uprawnień użytkowników. 5) Opis dotyczący implementacji audytu historii aktywności użytkownika. 6) Wykaz wszystkich modułów w systemie wraz z opisem. 7) Wykaz wszystkich modyfikowalnych i niemodyfikowalnych parametrów w modułach wraz z opisem (o ile istnieją). 8) Wykaz funkcji i czynności administratora w modułach (w tym nadawanie specyficznych, niestandardowych uprawnień użytkownikom do poszczególnych funkcji w modułach, raportowanie, modyfikacje parametrów, zarządzanie sesjami, tworzenie formularzy itp.) wraz z opisem. 9) Wykaz powiązań pomiędzy modułami, w tym wykaz powiązań pomiędzy modułami w zakresie nadawania uprawnień (zależności pomiędzy modułami) wraz z opisem Opis słowników wykorzystywanych w systemie Opis słowników powinien zawierać: 1) Listę wszystkich słowników. 2) Opis zarządzania danymi słownikowymi. 3) Opis procedury aktualizacji danych słownikowych Opis konfiguracji stacji roboczej lub urządzenia klienckiego dla użytkownika systemu Opis powinien zawierać proces przygotowania i konfiguracji stacji roboczej lub urządzenia klienckiego dla użytkownika pracującego w systemie. Opis przygotowania i konfiguracji stacji roboczej przeznaczonej do pracy w systemie powinien zawierać: 1) Listę oprogramowania, zawierającą nazwę oprogramowania, producenta, wersję, źródło pakietów instalacyjnych. 2) Wymagania sprzętowe. 3) Wymagania dotyczące systemu operacyjnego oraz dodatkowego oprogramowania ze wskazaniem wersji minimalnej i producenta oprogramowania. 4) Instrukcję instalacji oprogramowania Opis wymagań dla systemów teleinformatycznych w odniesieniu do rozporządzenia w sprawie Krajowych Ram Interoperacyjności (KRI) Opis powinien uwzględniać wymagania zawarte w Rozporządzeniu Rady Ministrów z dn. 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów 18

19 publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych. Dokumentacja systemu teleinformatycznego powinna zawierać m.in.: 1) Opis kodowania znaków w dokumentach wysyłanych z systemów teleinformatycznych podmiotów realizujących zadania publiczne lub odbieranych przez takie systemy, także w odniesieniu do informacji wymienianej przez te systemy z innymi systemami na drodze teletransmisji, o ile wymiana ta ma charakter wymiany znaków. 2) Opis formatów danych w jakim udostępniane są zasoby informacyjne zgodnie z załącznikiem nr 2 do ww. rozporządzenia. 3) Opis spełnienia wymagań Web Content Accessibility Guidelines (WCAG 2.0), z uwzględnieniem poziomu AA, określonych w załączniku nr 4 do ww. rozporządzenia. 4) Opis logów, dzienników systemów zawierających odnotowanie działań użytkowników lub obiektów systemowych polegających na dostępie do: a) systemu z uprawnieniami administracyjnymi, b) konfiguracji systemu, w tym konfiguracji zabezpieczeń, c) przetwarzanych w systemach danych podlegających prawnej ochronie w zakresie wymaganym przepisami prawa. 5) Opis logów, dzienników systemów zawierający działania użytkowników lub obiektów systemowych, a także inne zdarzenia związane z eksploatacją systemu w postaci: a) działań użytkowników nieposiadających uprawnień administracyjnych, b) zdarzeń systemowych nieposiadających krytycznego znaczenia dla funkcjonowania systemu, c) zdarzeń i parametrów środowiska, w którym eksploatowany jest system teleinformatyczny Licencje i gwarancje Licencje W dokumentacji Wykonawca zobowiązany jest przedstawić listę wszystkich licencji na dostarczone oprogramowanie wraz z opisem sposobu licencjonowania. Opis powinien dotyczyć wszystkich aplikacji wymagających licencjonowania (aplikacje, systemy operacyjne, bazy danych, urządzenia i inne). Lista licencji na oprogramowanie powinna zawierać: 1) Nazwę oprogramowania. 2) Sposób licencjonowania, a w szczególności informacje o metryce (np. procesor, użytkownik), uprawnieniach i ograniczeniach. 3) Ilości, rodzaje licencji (np. enterprise, standard) oraz poziom licencji. 4) Numer licencji Gwarancje i Serwis W ramach dokumentacji, Wykonawca powinien umieścić informacje dotyczące zasad gwarancyjnych na dostarczany sprzęt/urządzenia i oprogramowanie. Dokumentacja powinna zawierać informacje dotyczące udzielanego wsparcia producenta w tym: terminy obowiązywania gwarancji, numer asysty technicznej, sposób korzystania z asysty technicznej. Dokumentacja powykonawcza powinna zawierać opis usługi serwisowej, któryobejmuje: 1) Definicję, klasyfikację, kategoryzację błędów i awarii. 2) Opis procesu zgłaszania błędów i awarii. 3) Parametry świadczenia usługi serwisowej: a) okres dostępności serwisu gwarancyjnego, b) czas reakcji serwisu w odniesieniu do poszczególnych kategorii błędów i awarii, c) czas realizacji/usunięcia błędu (dla awarii czas przywrócenia funkcji oraz czas przywrócenia stanu z przed awarii). 19

20 15.6 Procedury Procedury eksploatacyjne Procedury mające na celu zabezpieczenie, bieżące utrzymanie i zapewnienie wysokiej niezawodności działania systemu. 1) Przekazanie inicjalnych haseł do kont administracyjnych systemu jako załącznik do wersji papierowej dokumentacji oraz procedurę bezpiecznej zmiany haseł (bez wpływu na funkcjonowanie systemu). 2) Procedura odstawienia systemu do konserwacji i ponownego włączenia do pracy produkcyjnej, zawierająca wytyczne odnośnie kolejności wyłączania poszczególnych składowych systemu oraz sposobie weryfikacji poprawności wykonania procedury, wykaz usług, które należy uruchomić po ponownym włączeniu systemu do pracy produkcyjnej. 3) Procedura aktualizacji systemu zawierająca wytyczne jak bezpiecznie przeprowadzić aktualizację składowych systemu w warstwie infrastruktury i aplikacji oraz opis zawierający zweryfikowanie poprawności jego działania po aktualizacji. 4) Procedura monitorowania systemu zawierająca wytyczne, które elementy systemu i w jaki sposób powinny być monitorowane w celu zapewnienia wysokiej niezawodności systemu. 5) Procedura testowa dotycząca elementów systemu łączności. 6) Procedura administracyjna zawierająca informację o okresowych zadaniach, które muszą być wykonane przez administratora, np. weryfikacja zajętości przestrzeni tabel, konieczność wykonywania analizy tabel, czyszczenia logów itp. wraz ze ścieżkami czynności i opisem ich realizacji Procedury awaryjne i odtworzeniowe Szczegółowe procedury tworzenia kopii zapasowych oraz sposób odtwarzania systemu w przypadku awarii, a także diagnozy systemu w przypadku jego awarii. 1) Procedura tworzenia kopii zapasowych systemu zawierająca informacje o: a) przyjętych harmonogramach, wymaganej częstotliwości i okresie przechowywania kopii, b) miejscu przechowywania lokalnych kopii składowych systemu (jeżeli są tworzone), c) opisie konfiguracji i sposobu uruchamiania specyficznych narzędzi i skryptów wykonywania kopii zapasowych, d) sposobie testowania poprawności wykonania kopii zapasowej, e) szacowany rozmiar danych do archiwizacji, f) szacowany przyrost tygodniowy danych, g) częstotliwość wykonywania kopii (np. codziennie) oraz wskazanie okresu (np. 5 dni w tygodniu). 2) Procedura odtwarzania wszystkich składowych systemu po awarii wraz z informacją o sekwencji wykonywania poszczególnych kroków w celu odtworzenia całego systemu wraz z opisem sposobu testowania systemu po wykonaniu odtworzenia. 3) Procedura diagnostyki awarii zawierająca wytyczne odnośnie kolejności oraz sposobu sprawdzania poszczególnych składowych systemu. 4) Procedura awaryjna dotycząca systemu łączności (uwzględniająca wpływ awarii poszczególnych urządzeń, łączy danych, infrastruktury pasywnej na poszczególne usługi biznesowe świadczone w ramach projektu/systemu) Procedura wykonania kopii danych i konfiguracji z systemu produkcyjnego na testowy Szczegółowy opis ukazujący utworzenie instancji testowej systemu powinienzawierać: 20