Załącznik nr 1 do umowy.docx · Web view(z ang. Graphical User Interface) – graficzny interfejs...

Załącznik nr 1 do Umowy nr …….. z dnia ..........................

Opis Przedmiotu Zamówienia

do postępowania o udzielenie zamówienia publicznego na: Modyfikację i utrzymanie Portalu

Informacyjnego Sądów Powszechnych realizowanego w ramach projektu „Wdrożenie protokołu

elektronicznego w sądach powszechnych (sprawy cywilne i wykroczeniowe)”

Wersja 1.1

CeDIZ, Kraków, 18 lipca 2017 r.

Projekt współfinansowany przez Unię Europejską ze środków Europejskiego Funduszu Rozwoju Regionalnego

Załącznik nr 1 do Umowy nr …... z dnia ...................... - Opis przedmiotu zamówienia

Spis treściI. DEFINICJE............................................................................................................................3

II. WSTĘP................................................................................................................................5LINIA DEMARKACYJNA Z POZOSTAŁYMI PROJEKTAMI E-PROTOKOŁU...................................................................6

III. OGÓLNY OPIS PRZEDMIOTU ZAMÓWIENIA.........................................................................8

IV. ŚRODOWISKO SYSTEMÓW KONTEKSTOWYCH DLA PORTALU INFORMACYJNEGO..............101. SYSTEM RECOURT........................................................................................................................102. OPROGRAMOWANIE „RECOURT”....................................................................................................123. OPROGRAMOWANIE CENTRALNE RCS (RECOURT SERVICES).................................................................164. MODUŁ TRANSKRYPCJI..................................................................................................................175. CENTRAL RECOURT SERVICES (CRCS)..............................................................................................186. CENTRALNE ARCHIWUM PROTOKOŁÓW ELEKTRONICZNYCH (CAPE)......................................................187. CENTRALNA INFRASTRUKTURA WIDEOKONFERENCYJNA........................................................................208. OPIS INFRASTRUKTURY UDOSTĘPNIANIA NAGRAŃ................................................................................25

V. CHARAKTERYSTYKA OBECNEGO SYSTEMU PORTAL INFORMACYJNY..................................26

VI. WYMAGANIA SZCZEGÓŁOWE............................................................................................361. PRZEPROWADZENIE ANALIZY BIZNESOWEJ I SYSTEMOWEJ.....................................................................362. PROJEKT TECHNICZNY I PROJEKT GRAFICZNY......................................................................................363. OPIS WYMAGAŃ FUNKCJONALNYCH I NIEFUNKCJONALNYCH DLA ROZBUDOWY PI......................................38

3.1 e-Usługa udostępniania protokołu elektronicznego..............................................................383.2 e-Usługa automatycznej transkrypcji mowy na tekst............................................................423.3 e-Usługa przeprowadzenia rozprawy odmiejscowionej.........................................................453.4 Pozostałe wymagania wspierające realizację e-Usług...........................................................473.5 Zakres modyfikacji poszczególnych komponentów systemu..................................................503.6 Wymagania niefunkcjonalne.................................................................................................56

4. DOSTAWA, INSTALACJA I KONFIGURACJA ŚRODOWISKA SPRZĘTOWEGO I SYSTEMOWEGO NIEZBĘDNEGO DLA WDROŻENIA MODYFIKACJI PI...................................................................................................................675. WDROŻENIE SYSTEMU W ORGANIZACJI ZAMAWIAJĄCEGO.....................................................................746. PRZEPROWADZENIE SZKOLEŃ..........................................................................................................807. OPRACOWANIE DOKUMENTACJI......................................................................................................818. SERWIS GWARANCYJNY, UTRZYMANIE I ROZWÓJ.................................................................................90

ZAŁĄCZNIK NR 1 WYKAZ AKTÓW PRAWNYCH..............................................................................104

ZAŁĄCZNIK NR 2 OPIS INTERFEJSÓW............................................................................................107

ZAŁĄCZNIK NR 3 FORMATY PLIKÓW TRANSKRYPCJI.....................................................................111

ZAŁĄCZNIK NR 4 KRYTERIA ODBIORU PRODUKTÓW PROJEKTU I PROCEDURY ODBIOROWE........112

ZAŁĄCZNIK NR 5 WYKORZYSTANA TECHNOLOGIA W OBECNIE DZIAŁAJĄCYM SYSTEMIE..............175

ZAŁĄCZNIK NR 6 WZORY DOKUMENTÓW....................................................................................185


2



3


I. Definicje

Pojęcie/skrót OpisZamawiający; MS Ministerstwo SprawiedliwościOPZ Opis Przedmiotu ZamówieniaPortal Informacyjny Sądów Powszechnych; System, Portal

Portal Informacyjny Sądów Powszechnych stanowiący system umożliwiający dostęp uprawnionym lub upoważnionym podmiotom do informacji o sprawach toczących się przed sądami powszechnymi za pośrednictwem Internetu

System cyfrowej rejestracji rozpraw sądowych

Urządzenia techniczne oraz oprogramowanie niezbędne do realizacji procesu rejestracji rozpraw sądowych, zarzadzania nagraniami, udostępniania i przechowywania nagrań e-protokołu, w tym w szczególności oprogramowanie: RC, RCS, CRCS, PT, PI.

ReCourt Services; RCS Oprogramowanie centralne w ramach pojedynczego sądu, pełniące funkcję oprogramowania dostępowego do zasobów plików nagrań.

Centralne Archiwum Protokołu Elektronicznego; CAPE

Elektroniczne archiwum materiałów audiowizualnych z posiedzeń wraz z danymi towarzyszącymi, odpowiedzialne za przechowywanie danych przez okres przewidziany przepisami prawa. Umożliwia wyszukiwanie, przeglądanie materiałów archiwalnych zgodnie z przepisami prawa za pomocą metadanych zdefiniowanych w systemach źródłowych (ReCourt).

Centralna Infrastruktura Wideokonferencyjna

Infrastruktura umożliwiająca realizację połączeń wideokonferencyjnych poprzez urządzenie typu terminal w sieci teleinformatycznej sądów lub poza nią z urządzeniem typu terminal dowolnego innego producenta

e-protokół; protokół elektroniczny

Utrwalany dźwięk albo obraz i dźwięk z przebiegu posiedzenia w postaci pliku multimedialnego albo pliku dźwiękowego wielokanałowego wraz z plikami metadanych, plikiem z adnotacjami protokolanta, plikiem z adnotacjami sędziego, plikiem protokołu skróconego, plikami zawierającymi podpis elektroniczny.

e-uzasadnienie Uzasadnienie wyroku utrwalone za pomocą urządzenia (CJR) rejestrującego dźwięk lub obraz i dźwięk. E-uzasadnienie jest częścią e-protokołu oraz dodatkowo rejestrowane jest jako odrębny plik przeznaczony do automatycznej transkrypcji w formacie .asr.

Dokument elektroniczny Dokument elektroniczny – stanowiący odrębną całość znaczeniową jako zbiór danych uporządkowanych w określonej strukturze wewnętrznej i zapisany na informatycznym nośniku danych

Formularz elektroniczny Formularz elektroniczny – graficzny interfejs użytkownika wystawiany przez oprogramowanie służący do przygotowania i wygenerowania dokumentu elektronicznego zgodnego z odpowiadającym mu wzorem dokumentu elektronicznego

Profil zaufany ePUAP zestaw informacji identyfikujących i opisujących podmiot lub osobę będącą użytkownikiem konta na ePUAP, który został w wiarygodny sposób potwierdzony przez organ podmiotu określonego w art. 2

XML ang. Extensible Markup Language; rozszerzalny język znaczników – uniwersalny język definiowania (reprezentowania) danych w ustrukturalizowany sposób

Ośrodek Transkrypcji Ośrodek działający na poziomie apelacji wykonujący transkrypcję nagrań


4


Pojęcie/skrót Opisaudio i audio-wideo zarządzany przez Kierownika (OKZT), któremu podlega zespół transkrybentów. Obecnie funkcjonuje 10 takich ośrodków.

Centralny Portal Transkrypcyjny; CPT

Portal służący do zarządzania przepływem plików oraz informacji dotyczących transkrypcji nagrań audio i audio-wideo pomiędzy sądami, a Ośrodkami Transkrypcji oraz do wsparcia procesów automatycznej transkrypcji, a także korekt wyników transkrypcji automatycznej.

RC; ReCourt Oprogramowanie będące własnością Ministerstwa Sprawiedliwości służące do obsługi procesu rejestracji rozprawy sądowej na sali rozpraw. Oprogramowanie do poprawnego działania korzysta z szeregu funkcjonalności udostępnianych przez CJR.Oprogramowanie składa się z komponentu centralnego instalowanego na CJR oraz Aplikacji klienckiej protokolanta i Aplikacji klienckiej sędziego.

Central ReCourt Services; CRCS

Serwer centralny dla serwerów RCS pełniący funkcję pośredniczącą w komunikacji między nimi oraz zarządzający konfiguracją poszczególnych serwerów RCS.

GUI (z ang. Graphical User Interface) – graficzny interfejs użytkownika składający się̨ z takich obiektów ekranowych jak: okna formularzy, okna dialogowe, przyciski, etykietki, pola edycyjne, listy rozwijalne, listwy narzędziowe, obrazki, paski menu, suwaki i inne, zapewniających komunikację użytkownika z Systemem w tym przeglądanie, wyszukiwanie, modyfikację lub wprowadzanie danych do Systemu.

Interfejs Oprogramowanie umożliwiające wymianę danych pomiędzy dwoma systemami informatycznymi

ARM; ASR Automatyczne Rozpoznawanie Mowy ang. Automatic Speech Recognition. Oprogramowanie służące do automatycznej zamiany mowy na tekst – transkrypcji.

Modyfikacje Pod pojęciem Modyfikacji Systemu Zamawiający rozumie zmiany w Systemie inne niż określone w punkcie 8.2 podpunkt 2 niniejszego rozdziału w szczególności dodanie nowych funkcjonalności, zmiany kodu źródłowego inne niż wynikające z usługi wsparcia i serwisu.


5


II. Wstęp

Dnia 16 listopada 2015 r. Ministerstwo Sprawiedliwości (Zamawiający) zawarło umowę z Centrum Projektów Polska Cyfrowa o dofinansowanie projektu „Wdrożenie protokołu elektronicznego w sądach powszechnych (sprawy cywilne i wykroczeniowe)” w ramach działania 2.1 Wysoka dostępność i jakość e-usług publiczny Programu Operacyjnego Polska Cyfrowa. Niniejsze zamówienie jest częścią tego projektu.

Czas realizacji całości projektu „Wdrożenie protokołu elektronicznego w sądach powszechnych (sprawy cywilne i wykroczeniowe)” wyniesie 36 miesięcy od dnia podpisania umowy o dofinansowanie projektu, tj. od dnia 16 listopada 2015 r.Celem projektu „Wdrożenie protokołu elektronicznego w sądach powszechnych (sprawy cywilne i wykroczeniowe)” jest usprawnienie postępowania sądowego przez zastosowanie nowoczesnych technik zapisu przebiegu czynności sądowych, jako jednego z obszarów unowocześniania procedur sądowych.Integralną częścią projektu będą usługi kierowane do obywateli oraz przedsiębiorców, udostępniane w sieci Internet. Planowane do wdrożenia usługi A2B/A2C to w ramach projektu „Wdrożenie protokołu elektronicznego w sądach powszechnych (sprawy cywilne i wykroczeniowe)” to:

Usługa automatycznej transkrypcji mowy na tekst, Usługa przeprowadzania rozprawy odmiejscowionej (rozprawy prowadzane na

odległość), Usługa udostępniania protokołu elektronicznego.

Oprócz usług A2B/A2C w ramach realizacji projektu udostępniona zostanie również jedna usługa A2A:

Usługa wirtualizacji wideokonferencji.

Wdrożenie wspomnianych e-usług będzie przedmiotem szeregu projektów informatycznych. W kolejnym rozdziale opisano linię demarkacyjną zakresu tych projektów.

Usługi wymienione powyżej będą udostępniane poprzez platformę e-usług, w skład której wchodzą następujące systemy teleinformatyczne:

a) System cyfrowej rejestracji rozpraw (ReCourt, RCS, CRCS, ReCourt Player),b) Portal Informacyjny (PI),c) Centralny system wideokonferencyjny,d) Centralne Archiwum Protokołu Elektronicznego (CAPE)

oraz poprzez systemy i rozwiązania wytworzone w ramach niniejszego zamówienia.Niniejszy Opis Przedmiotu Zamówienia reguluje obowiązki i zakres usług Wykonawcy dotyczących modyfikacji i utrzymania Portalu Informacyjnego Sądów Powszechnych.


6


W dalszej części dokumentu przedsięwzięcie to nazwane jest „Zamówieniem”.


7

Linia demarkacyjna z pozostałymi projektami e-protokołuNa rysunku zaprezentowano linię demarkacyjną pomiędzy systemami objętymi zamówieniem, a pozostałymi systemami wchodzącymi w skład Systemu Portal Informacyjny Sadów Powszechnych:


„Modyfikacja i utrzymanie Portalu Informacyjnego Sądów Powszechnych na potrzeby projektu »Wdrożenie protokołu elektronicznego w sądach powszechnych (sprawy cywilne i wykroczeniowe)«”, zapewni mechanizmy:

o wnioskowania o przeprowadzenia rozprawy odmiejscowionej,o wnioskowania o strumieniowania posiedzenia on-line i strumieniowanie

posiedzenia,o wnioskowania o automatyczną transkrypcję nagrań z rozprawy i udostępnianie

transkrypcji,o wnioskowania o udostępnianie protokołu elektronicznego,o wnioskowanie o dostęp do nagrań i akt w czytelni sądu,o składowanie udostępnianych na portalu danych,

Pozostałe postępowania o udzielenie zamówień publicznych wchodzące w zakres projektu to:1. Dostawa, instalacja, konfiguracja i wdrożenie systemu automatycznej transkrypcji

przy wykorzystaniu systemu ARM (automatyczne rozpoznawanie mowy) oraz zarządzania procesem transkrypcji zapisów cyfrowych z przebiegu rozpraw w sądach powszechnych na potrzeby projektu »Wdrożenie protokołu elektronicznego w sądach powszechnych (sprawy cywilne i wykroczeniowe)«”, która zapewni mechanizmy automatycznej transkrypcji e-Protokołu.

2. „Modyfikacje, instalacja, konfiguracja i wdrożenie Systemu Cyfrowej Rejestracji Rozpraw (Recourt, RCS, CRCS) w sądach powszechnych na potrzeby projektu »Wdrożenie protokołu elektronicznego w sądach powszechnych (sprawy cywilne i wykroczeniowe)«”, który zapewni mechanizmy:

o obsługi przepływu zleceń dot. usług automatycznej transkrypcji,o udostępniania plików w zakresie protokołu elektronicznego do publikacji,o przeprowadzenia rozprawy odmiejscowionej,o realizacji streamingu posiedzenia on-line, o obsługa wnioskowania i realizacji wirtualizacji wideokonferencji,o realizacji rezerwacji dostępu do nagrań i akt w czytelni.

Z systemami zmodyfikowanymi w wyniku realizacji tych projektów będzie przeprowadzana integracja bezpośrednia lub pośrednia w zakresie opisanym w niniejszym Opisie Przedmiotu Zamówienia.

Ponadto zamówieniem, którego zadaniem będzie dostawa odpowiedniej infrastruktury sprzętowej dla potrzeb rejestracji rozpraw na salach sądowych jest:

„Dostawa i wdrożenie systemu cyfrowej rejestracji przebiegu rozpraw sądowych w sądach powszechnych”.



III. Ogólny opis przedmiotu zamówieniaZamówienie obejmuje swym zakresem:

1. Przeprowadzenie Analizy Systemowej2. Opracowanie Projektu Technicznego i Projektu Graficznego3. Dostawa, instalacja i konfiguracja modyfikacji PI4. Dostawa, instalacja i konfiguracja środowiska sprzętowego i systemowego

niezbędnego dla wdrożenia modyfikacji PI5. Wdrożenie systemu w organizacji Zamawiającego6. Opracowanie dokumentacji7. Serwis gwarancyjny, utrzymanie i rozwój

Szczegółowe wymagania dla każdego z powyższych punktów opisano w kolejnych rozdziałach OPZ.

Głównym celem modyfikacji Systemu Portal Informacyjny jest udostępnienie dla docelowego odbiorcy trzech e-usług realizowanych w ramach projektu „Wdrożenie protokołu elektronicznego w sądach powszechnych (sprawy cywilne i wykroczeniowe)”, w szczególności:

e-Usługa przeprowadzenia rozprawy odmiejscowionej

E-usługa skierowana do przedsiębiorców i obywateli korzystających bezpośrednio lub pośrednio z usług elektronicznych A2C/A2B. Docelowy poziom dojrzałości 4.Usługa polegająca na umożliwieniu przeprowadzenia posiedzenia sądowego na odległość poprzez system wideokonferencji. Umożliwia ona zdalny udział dla wszystkich stron postępowania. Dzięki wprowadzeniu usługi obniżają̨ się koszty postępowania sądowego, np. poprzez brak potrzeby przyjazdu biegłego z drugiego końca kraju na wyznaczoną rozprawę̨. Dzięki możliwości zapisu obrazu i dźwięku przekazywanego za pomocą ̨ wideokonferencji i utrwaleniu tego zapisu w protokole elektronicznym, strony uzyskują kompletną i rzeczywistą informację o przebiegu procesu dostępną z każdego miejsca na świecie podłączonego do sieci Internet.Dodatkowo planowane jest wprowadzenie funkcjonalności strumieniowania przebiegu posiedzeń jawnych na wniosek uczestnika postępowania.

e-Usługa udostępniania protokołu elektronicznego

E-usługa skierowana do przedsiębiorców i obywateli korzystających bezpośrednio lub pośrednio z usług elektronicznych A2C/A2B. Obecny poziom dojrzałości 3, docelowy 5.Usługa wprowadza możliwość udostępnienia protokołu elektronicznego (w tym zapisu wideo)


10


na Portalu Informacyjnym. Zgodnie z aktualnym stanem prawnym uczestnicy stron postępowania mogą ̨ złożyć wniosek o udostępnienie protokołu elektronicznego w budynku sądu (czytelnia akt) oraz o udostępnienie zapisu protokołu elektronicznego na nośniku zewnętrznym (wydanie odpisu protokołu elektronicznego). Nie dotyczy to sądów, gdzie nie został wdrożony protokół elektroniczny. Rezultatem uruchomienia tej e-usługi będzie możliwość złożenia wniosku o udostępnienie protokołu elektronicznego przez Portal Informacyjny. W przypadkach uregulowanych przez obowiązujące przepisy protokół elektroniczny może być również udostępniony dla wnioskodawcy na Portalu Informacyjnym.

e-Usługa automatycznej transkrypcji mowy na tekst

E-usługa skierowana do przedsiębiorców i obywateli korzystających bezpośrednio lub pośrednio z usług elektronicznych A2C/A2B. Docelowy poziom dojrzałości 4.Dzięki usłudze możliwe jest przełożenie mowy utrwalonej w zapisie dźwięku z rozprawy na tekst zapisany w pliku tekstowym o otwartym formacie. Usługa będzie niewątpliwie bardzo przydatna osobom niesłyszącym, ponadto produkty usługi przyspieszą proces zapoznawania się stron postępowania ze sprawą poprzez możliwość wyszukania pełnotekstowego bezpośrednio z zapisu audio w zakresie przeszukiwania treści dotyczącej przeglądanego w danej chwili nagrania.


11


IV. Środowisko systemów kontekstowych dla Portalu Informacyjnego

1. System ReCourt

System ReCourt ma architekturę rozporoszoną z punktami centralnego zarządzania i monitorowania jednostek rozproszonych, zarządzania konfiguracją, danymi i dostępem do nich.

Rysunek 1 – Uproszczony schemat architektury Systemu ReCourt


12


Dla pełniejszego zobrazowania architektury systemów informatycznych działających w sądach należy zwrócić uwagę na równoległe i zasadnicze procesy, które się tam toczą. Wyróżnić tu możemy przechowywanie i przetwarzanie danych spraw w systemach repertoryjnych, dostarczanie informacji na temat przebiegu sprawy osobom/sądom zainteresowanym, możliwość umówienia i przeprowadzenia wideokonferencji z wykorzystaniem centralnej infrastruktury wideokonferencyjnej, złożenie wniosku o transkrypcję protokołu elektronicznego. Wszystkie te procesy objęte są odpowiednimi systemami informatycznymi, które wspierają ich realizację.

Rysunek 2 - Rozwinięty schemat architektury systemów IT


13


2. Oprogramowanie „ReCourt”Oprogramowanie „ReCourt” pracuje na infrastrukturze sal sądowych, w szczególności centralnej jednostce rejestrującej (CJR), urządzeniu „All-in-one” stacji protokolanta oraz urządzeniu „All-in-one” stacji sędziego wykorzystując szereg natywnych mechanizmów Jednostki centralnej systemu rejestracji, takich jak np.:

Kompresja i rejestracja sygnałów do pliku przy użyciu parametryzowanych kodeków audio/wideo.

Pozyskanie strumieni danych z wszystkich podłączonych do urządzenia sprzętowych źródeł sygnału audio/wideo oraz ze źródeł programowych.

Zmiksowanie sygnału wideo do jednego strumienia i jego rozgłaszanie w postaci nieskompresowanej bitmapy (wideo), bitów dźwięku (każdy kanał audio osobno) oraz znacznika czasu.

Zmiksowanie obrazu zgodnie z zadanymi parametrami wielkości i położenia obrazu każdego kanału.

Odtwarzanie zarejestrowanych plików z zapisem wielokanałowym, także w trakcie rejestracji (bez jej przerywania) oraz ich rozgłaszanie w postaci bitmapy (wideo), bitów dźwięku (każdy strumień audio osobno) wraz ze znacznikiem czasu.

Mechanizm sprzętowej kontroli sprawności mikrofonów.

Oprogramowanie „ReCourt” przez połączenie sieciowe komunikuje się z serwerem ReCourt Services. Dostęp użytkownika do aplikacji oraz jej obsługa odbywa się poprzez GUI na stacji klienckiej. Do jej kluczowych zadań należy:

Zarządzanie procesem rejestracji, Wprowadzanie adnotacji do protokołu, Tworzenie plików protokołu w wymaganym schemacie, Obsługa słowników adnotacji, Sterowanie osprzętem na salach sądowych (wzmacniacz, wideokonferencja,

system nagłośnienia, system przywoływania), Prezentacja dowodów w postaci elektronicznej, Monitoring poprawności działania sprzętu pracującego na sali sądowej

(mikrofonów, kamer), Integracja z innymi aplikacjami działającymi w ramach sądu, m.in. systemami

repertoryjnymi, systemami wideokonferencyjnymi poprzez udostępnione interfejsy,

Wymiana określonych informacji z serwerem ReCourt Services, Transfer plików do lokalnego zasobu dyskowego serwera ReCourt Services.


14


Głównymi grupami funkcji Oprogramowania ReCourt są:

1. Autoryzacja i czynności wstępne Dostęp do systemu możliwy jest tylko dla osób upoważnionych. Po autoryzacji

system umożliwia dokonanie sprawdzenia działania poszczególnych elementów systemu w tym nastaw kamer.

2. Czynności inicjujące proces rejestracji Oprogramowanie umożliwia wpisanie przez użytkownika danych sprawy

w zakresie zgodnym z prawem (np. oznaczenie sądu i wydziału, który prowadzi sprawę, imiona i nazwiska członków składu sędziowskiego i protokolanta, oznaczenia stron wraz z pełnomocnikami oraz nazwiska i imiona świadków, skrótowy opis przedmiotu sprawy, itp.). Możliwe jest też automatyczne uzupełnienia danych z pliku XML lub poprzez automatyczny interfejs z zewnętrznego systemu sądowego.

Proces rejestracji inicjuje w systemie protokolant na polecenie przewodniczącego składu sędziowskiego.

Podstawową lokalizacją pliku nagrania jest dysk twardy Jednostki centralnej systemu rejestracji, na której pracuje Oprogramowanie ReCourt.

3. Zarządzanie procesem rejestracji Uruchomienie, zatrzymanie, wznowienie, zakończenie rejestracji. Po uruchomieniu procesu nagrywania przez protokolanta strumienie obrazu

i dźwięku przesyłane są do urządzenia rejestrującego, gdzie zostają cyfrowo zapisane.

Obsługa procesu dołączania kolejnych źródeł sygnału (np. wideokonferencja, obraz z kamer dokumentowej).

W trakcie rejestracji obrazu i dźwięku możliwe jest przeprowadzenie wideokonferencji połączonego z rejestracją tych czynności.

System umożliwia przywołanie w trakcie rejestracji fragmentu bieżącego lub innego nagrania celem odtworzenia podczas rozprawy.

Interfejs graficzny zapewnia bieżącą kontrolę wielkości dostępnej pamięci dyskowej.

Interfejs graficzny zapewnia bieżącą kontrolę poprawności przebiegu nagrywania, w szczególności zapisu dźwięku.

4. Prowadzenie adnotacji Oprogramowanie umożliwia tworzenie adnotacji publicznych (tworzone przez

operatora systemu (protokolanta) pod kierunkiem przewodniczącego) oraz adnotacji prywatnych (sędziego). Adnotacje stanowią metadane zawierające informacje dotyczące przebiegu posiedzenia jawnego z oznaczeniem dokonania czynności procesowej lub zaistnienia innego zdarzenia. W szczególności mogą zawierać informacje o rozpoczęciu wypowiedzi uczestniczących w posiedzeniu


15


osób oraz o innych istotnych dla postępowania zdarzeniach. Ponadto w adnotacjach umieszczane są również inne istotne okoliczności, w szczególności informacje o stawiennictwie stron, o dopuszczonych dowodach w sprawie, czy dowód został przeprowadzony, odroczeniu rozprawy czy też o wydanych orzeczeniach i zarządzeniach.

Notatki są sporządzane na bieżąco, równolegle z procesem nagrywania przebiegu rozprawy.

Oprogramowanie automatycznie znakuje każdą notatkę licznikiem czasu nagrania.

Automatycznie na podstawie licznika czasu nagrania tworzone jest powiązanie między adnotacją a odpowiadającym jej punktem w ścieżce nagrania. W trakcie późniejszego odtwarzania nagrania możliwe wskazanie odpowiedniej adnotacji i odtworzenie fragmentu nagrania. Po wybraniu adnotacji zdarzenia operator może odtworzyć fragment nagrania, do którego się on odnosi.

Funkcja znakowania czasem i tworzenia adnotacji uruchamiana jest automatycznie wraz z uruchomieniem nagrywania.

5. Kodowanie i kompresja nagrania Poszczególne strumienie danych przesyłane są wielokanałowo. Każdy strumień

audio zapisywany jest jako odrębny strumień danych możliwy do wyodrębnienia z zapisu. Strumienie wideo są miksowane przez Jednostkę centralną systemu rejestracji do jednego strumienia.

Synchronizacja wszystkich ścieżek zapobiega występowaniu rozbieżności szczególnie pomiędzy obrazem i dźwiękiem, ale również z dokonywanymi adnotacjami. System w trakcie rejestracji dokonuje synchronizacji w sposób automatyczny.

Po synchronizacji strumieni danych, system dokonuje kodowania przy pomocy wybranego kodeka obrazu i dźwięku, do formatu umożliwiającego odtwarzanie przy pomocy zewnętrznych urządzeń odtwarzających. W trakcie kodowania dokonuje jednoczesnej kompresji zmniejszając wielkość pliku.

6. Zarządzanie słownikami Oprogramowanie umożliwia m.in. posługiwanie się słownikami oraz

aktualizację ich zawartości poprzez import z Oprogramowania centralnego RCS.7. Zakończenie nagrywania

W wyniku zamknięcia procesu rejestracji następuje utworzenie zapisów przebiegu posiedzenia:

o zapis foniczny w postaci pliku dźwiękowego jednokanałowego;o zapis wideofoniczny w postaci pliku multimedialnego obejmującego

obraz wraz z dźwiękiem wielostrumieniowym;o plik metadanych zarejestrowanej cyfrowo rozprawy;

Oprogramowanie umożliwia podpisanie nagrania podpisem elektronicznym.


16


Tworzony jest równocześnie protokół skrócony, który po wydrukowaniu podpisywany jest przez protokolanta i sędziego.

8. Odtwarzanie nagrania Oprogramowanie zapewniona możliwość wyszukania, wyboru i otworzenia

pliku nagrania. Oprogramowanie zapewnia możliwość zarządzania procesem odtwarzania, np.:

przewijanie, skok w określone miejsce, regulację poziomu głośności odtwarzania nagrania, regulację poziomu głośności odtwarzania poszczególnych ścieżek, regulację szybkości odtwarzania i przewijania, wybór kombinacji ścieżek do odtwarzania.

9. Zabezpieczenie zapisów i przekazanie do sądowego repozytorium nagrań Po dokonaniu kodowania i kompresji nagrania protokolant podpisuje zapis

bezpiecznym podpisem elektronicznym gwarantującym identyfikację osoby protokolanta oraz rozpoznawalność jakiejkolwiek późniejszej zmiany protokołu.

System nie umożliwia przejścia do dalszych czynności bez dokonania czynności związanych z podpisaniem zapisów (wyjątek: wstrzymanie nagrania). Następnie zapis przekazywany jest do sądowego repozytorium nagrań w systemie RCS.

Ze względów bezpieczeństwa system umożliwia bezpośrednio po zakończonej sesji nagraniowej archiwizację utworzonych plików nagrań i metadanych na zewnętrznych nośnikach jednokrotnego zapisu wraz z umieszczeniem na nośniku odtwarzacza (ReCourt Player) umożliwiającego przeglądanie nagrań w oparciu o utworzone adnotacje oraz przeszukiwanie w oparciu o słowa kluczowe. Oprogramowanie ma wbudowane mechanizmy / systemy zabezpieczające przed skasowaniem pliku.

Oprogramowanie zakłada system podkatalogów, ułatwiających segregację plików przekazywanych do archiwum.

Dodatkowym komponentem jest odtwarzacz nagrań Player stand-alone, umożliwiający odtwarzanie zarchiwizowanych nagrań na dowolnym komputerze klasy PC wyposażonym w system operacyjny Windows, Linux lub MacOS. Nagrania w sądzie udostępniane są z sądowego repozytorium nagrań za pośrednictwem sieci teleinformatycznej. Podczas archiwizacji nagrań Player stand-alone jest automatycznie umieszczany na nośniku CD/DVD wraz z plikami nagrań. Odtwarzacz udostępnia szereg funkcjonalności umożliwiających zarządzanie procesem odtwarzania oraz zarządzania plikami adnotacji, w tym również tworzenie własnych adnotacji podczas przeglądu nagrania. Odtwarzacz oferuje możliwość przeszukiwania zapisu w oparciu o utworzone adnotacje oraz przeszukiwanie w oparciu o słowa kluczowe i wybór strumienia zapisu.


17


System do wielokanałowej fonicznej oraz wizyjnej rejestracji rozpraw sądowych umożliwia dodatkowo:

przeprowadzenie dowodu na odległość wraz z jednoczesną rejestracją tych czynności przez system, poprzez zestawienie w trakcie posiedzenia dedykowanego połączenia zdalnego,

z podłączonych do systemu zewnętrznych źródeł danych, prezentację dowodów w postaci elektronicznej wraz z jednoczesną rejestracją tych czynności przez system,

wizualizację przebiegu rejestracji posiedzenia na zewnętrznych urządzeniach wyświetlających obraz wraz z możliwością odtworzenia rejestrowanego zapisu dźwięku.

Oprogramowanie ReCourt pracuje na Jednostce centralnej systemu rejestracji, pod kontrolą systemu operacyjnego Linux Debian/Ubuntu lub Windows.

3. Oprogramowanie centralne RCS (ReCourt Services)

Oprogramowanie centralne RCS (ReCourt Services) przeznaczone jest do pracy na poziomie pojedynczego sądu oraz pełni funkcję oprogramowania dostępowego do zasobów plików nagrań. W ogólnym przypadku, w ramach jednostki organizacyjnej sądu może funkcjonować kilka serwerów RCS – kompetencje i zasięg tych serwerów są określone poprzez konfigurację wyróżników sądowych, sal oraz użytkowników. Głównym zadaniem oprogramowania jest zarządzanie przechowywaniem i udostępnianiem nagrań. Oprogramowanie centralne RCS pracuje pod kontrolą systemu operacyjnego Microsoft Windows 2008/2012 Server oraz wykorzystuje bazę danych Microsoft SQL Server 2008/2012. Oprogramowanie wykonane jest w technologii .NET.

Oprogramowanie posiada budowę modułową, która umożliwia łatwą rozbudowę oraz integrację z infrastrukturą rejestracji nagrań. Serwery Oprogramowania centralnego RCS komunikują się ze sobą, serwery RCS komunikują się również z centralnym serwerem CRCS.

Do głównych zadań modułu RCS należy:1. Zarządzanie kontami użytkowników,2. Autoryzacja użytkowników,3. Zarządzanie dostępem – obsługa tokenów dostępu do nagrań i udostępnianie

nagrań na danym stanowisku w czytelni,4. Zarządzanie dostępem – mechanizmy kontroli dostępu użytkownika do

nagranych spraw, użytkownik widzi tylko te sprawy, które zostały mu przydzielone,

5. Udostępnianie nagrań i zarządzanie nimi,


18


6. Modyfikacja niektórych parametrów sprawy,7. Zarządzanie centralnymi jednostkami rejestracyjnymi w salach rozprawa,

aktualizacja i konfiguracja,8. Kontrola dostępu i rozliczalność akcji,9. Indeksacja nagrań i wyszukiwanie,10. Sprawdzanie spójności danych,11. Transfer plików pomiędzy sądami,12. Obsługa procesów workflow (obieg wszelkiego rodzaju wniosków w systemie),13. Zapis całości lub fragmentu nagrania na nośnik zewnętrzny,14. Przekazanie nagrania do transkrypcji i odbiór transkrypcji,15. Statystyka i raportowanie,16. Integracja z innymi systemami poprzez zdefiniowane API,17. Edycja nagrań/fragmentów nagrań, protokołów skróconych i adnotacji,18. Obsługa listy zadań do wykonania dla użytkowników.

4. Moduł Transkrypcji Modułu Transkrypcji stanowi dodatkowy komponent Oprogramowania centralnego RCS służący do zarządzanie przepływem plików oraz informacji dotyczących przeprowadzania transkrypcji nagrań audio-wideo pomiędzy sądami, a Ośrodkami transkrypcji oraz wsparcie użytkowników w przeprowadzeniu transkrypcji nagrania.

Głównymi celami Modułu transkrypcji są:1. Realizacja procesu transkrypcji zapisów nagrań posiedzeń rejestrowanych w systemie

ReCourt.2. Realizacja procesu zlecenia transkrypcji nagrania przez sąd.3. Centralne zarządzanie przydziałem ośrodków transkrypcyjnych (ośrodki zarządzania

informacją) do wydziałów sądów z poziomu serwera centralnego. 4. Zarządzanie przepływem pracy pomiędzy sądem i ośrodkiem transkrypcji.5. Zarządzanie zadaniami transkrypcji z poziomu klienta transkrypcji.6. Zarządzanie użytkownikami Modułu transkrypcji.7. Zarządzanie transferem nagrań oraz plików transkrypcji pomiędzy sądem, a

ośrodkiem transkrypcyjnym.8. Raportowanie obciążenia ośrodków transkrypcyjnych oraz transkrybentów.


19


5. Central ReCourt Services (CRCS)

Central ReCourt Services jest serwerem centralnym dla serwerów RCS i pełni funkcję pośredniczącą w komunikacji między nimi, utrzymuje generalną konfigurację struktur danych o sądach i o sprawach, które zostały zarejestrowane, monitoruje wersje serwerów RCS i trzyma listę wydziałów, które są obsługiwane przez dany serwer RCS. CRCS realizuje następujące zdania np.:

1. Obsługa rejestracji serwera RCS w rejestrze CRCS,2. Centralne zarzadzanie słownikami, 3. Utrzymanie globalnego słownika wyróżników, sprawdzanie poprawności i spójności

nazw wydziałów na wszystkich zarejestrowanych RCS,4. Pośredniczenie w transferze nagrań pomiędzy RCS.

6. Centralne Archiwum Protokołów Elektronicznych (CAPE)

Centralne Archiwum Protokołów Elektronicznych składa się z komponentów sprzętowych i programowych odpowiedzialnych za zarządzanie archiwum (System Zarządzania Archiwum i Urządzenie Archiwizujące) oraz przechowywanie danych (Macierz Dyskowa i Biblioteka Taśmowa). W celu podniesienia poziomu bezpieczeństwa przechowywanych danych architektura rozwiązania obejmuje również lokalizację zapasową, w której zainstalowana jest Biblioteka Taśmowa przechowująca kopię danych zgromadzonych w lokalizacji podstawowej.

Architektura systemu Centralnego Archiwum Protokołów Elektronicznych została przedstawiona poniżej:


20


Do zbierania danych spraw, pobierania plików z nagraniami rozpraw i obsługi przesyłania/pobierania paczek archiwalnych do/z archiwum CAPE służy moduł RCS Agent Server.

Głównymi usługami świadczonymi przez Centralne Archiwum Protokołów Elektronicznych są:

1. Bezpieczne przechowywanie danych przez okres przewidziany przepisami prawa.

2. Wyszukiwanie, przeglądanie i udostępnianie materiałów archiwalnych w zakresie dopuszczonym przepisami prawa, na podstawie prowadzonego indeksu danych. Indeks umożliwia wyszukiwanie protokołów przy wykorzystaniu zdefiniowanych metadanych (np. data przyjęcia, wielkość danych, podpis elektroniczny).

3. Zarządzanie w systemie kontami użytkowników i podmiotów.4. Generowanie raportów i zestawień według indeksów.

Centralne Archiwum Protokołów Elektronicznych zawiera również szereg narządzi i mechanizmów do monitoringu i zarządzania archiwum, w tym, między innymi:

1. narzędzia i mechanizmy zarządzania urządzeniami w tym nośnikami,2. narzędzia i mechanizmy tworzenia i zarządzania bazą indeksów,3. komponenty programowe instalowane lokalnie (agent) oraz narzędzia i mechanizmy

do zarządzania nimi.


21


7. Centralna infrastruktura wideokonferencyjnaPosiadana przez Zamawiającego Centralna infrastruktura wideokonferencyjnej oparte została o rozwiązania firmy Avaya. Rozwiązanie zostało zbudowane w architekturze rozproszonej. Urządzenia zostały skonfigurowane w klaster z 5 węzłami umiejscowionymi w różnych lokalizacjach geograficznych. Każdy z węzłów składa się z mostków wideokonferencyjnych (MCU), bramy ISDN oraz urządzeń do realizacji połączeń z siecią zewnętrzną (Pathfinder). Dodatkowo jeden z węzłów (węzeł główny zlokalizowany z Sądzie Apelacyjnym we Wrocławiu) wyposażony jest w klaster serwerów sterujących SCOPIA Management oraz gatekeeperów – SCOPIA Gatekeeper (zintegrowany z serwerem SCOPIA Management). W celu zwiększenia niezawodności klaster ten rozdzielony jest dodatkowo pomiędzy dwa budynki.

Infrastruktura ta umożliwia realizację połączeń wideokonferencyjnych poprzez urządzenie typu wideoterminal w sieci teleinformatycznej sądów lub poza nią z urządzeniem typu wideoterminal dowolnego producenta.

Poniżej przedstawiono poglądowy rysunek architektury Centralnej infrastruktury wideokonferencyjnej:

Rysunek 3 - Ogólna architektura Centralnej infrastruktury wideokonferencyjnej


22


Wdrożone rozwiązanie zapewnia możliwość optymalizacji wykorzystania posiadanych zasobów MCU poprzez utylizacje wolnych portów w ramach klastra geograficznego w scenariuszu w ramach jednorodnej logicznie struktury Virtual MCU.

Optymalizacji podlega również wykorzystanie pojemności (zasobów) mostka w ramach prowadzonej konferencji. Optymalizacja polega na wykorzystywaniu dla każdego uczestnika tylko takich zasobów, które są konieczne dla realizacji kanału o zadanej lub możliwej do osiągnięcia dla danego typu urządzenia czy warunków sieciowych. Uwalnianie zasobów przebiega dynamicznie i pozwala oferować dodatkową pojemność konferencyjna dostępną dla innych spotkań.

Kolejnym elementem optymalizacji wykorzystania zasobów jest optymalizacja wykorzystywania zespołu urządzeń dostępowych do Internetu poprzez równoważenie obciążenia w ramach klastra urządzeń dostępu do sieci zewnętrznej (Pathfinder).

Wdrożona platforma cechuje się wysoką niezawodnością, która wyraża się poprzez zabezpieczenie wszystkich istotnych komponentów infrastruktury biorących udział w obsłudze spotkania:

o Redundancja mostków konferencyjnych, umożliwiająca automatyczne odtworzenie konferencji w przypadku awarii pojedynczego serwera i utrzymanie ciągłości kalendarzy i rezerwacji zasobów dla planowanych spotkań.

o Redundancja systemu nadzoru umożliwiająca zachowanie stanu systemu, odtworzenie trwających spotkań oraz zapewnienie ciągłości terminarzy i identyfikacji spotkań.

o Redundancja procesów obsługi terminali – gatekeeper, realizowana w sposób zapewniający maksymalną interoperacyjność względem urządzeń konferencyjnych różnych dostawców i różnych generacji.

o Zapewnienie redundancji urządzeń Pathinder obsługujących dostęp do konferencji dla uczestników zlokalizowanych w sieciach zewnętrznych i prywatnych (poprzez Internet) w ramach klastrów.

Bezpieczeństwo

Szyfrowanie komunikacji w komunikacji urządzeń i klientów softwarowych wideo jak również dostępu do sytemu zarządzania. Możliwość ustanowienia unikalnych identyfikatorów konferencji, jak również możliwość zabezpieczenia dostępu dodatkowym hasłem lub zablokowanie możliwości dostępu do trwającej konferencji.

Obsługa terminali H.323 z Internetu

Wdrożone rozwiązanie obejmuje bezpłatną dystrybucję klienta H.460 pozwalającego na obsługę dostępu dla starszych typów terminali H.323, nie wspierających protokołu H.460. Rozwiązanie nie zawiera ograniczeń ilości obsługiwanych sesji w modelu


23


licencyjnym. Rozwiązanie nie uzależnia również liczby prowadzonych sesji od ich jakości.

Parametry pojemnościowe i wydajnościowe

Wdrożone rozwiązanie pozwala m.in. na: W zakresie realizacji połączeń:

o Realizację do 30 jednoczesnych wideokonferencji w rozdzielczości FullHD (1080p), w których biorą udział trzy strony, które mogą znajdować się w różnych lokalizacjach,

o Realizację do 130 jednoczesnych wideokonferencji w rozdzielczości HD Ready (480p), w których biorą udział trzy strony, które mogą znajdować się w różnych lokalizacjach,

o Realizację tysięcy jednoczesnych wideokonferencji w najczęściej występującym scenariuszu w procesie obsługi rozpraw sądowych, czyli wideokonferencji pomiędzy terminalami dostarczonymi do sal rozpraw, w których biorą udział uczestnicy znajdujący się na sali rozpraw (sędzia i strona) oraz jeden uczestnik zdalny (świadek).

o Kształtowanie strumieni audio/video (kodeka, jakości, przepływności) jak również formatu wyświetlanego obrazu (liczba wyświetlanych obrazów) indywidualnie dla każdego uczestnika, co pozwala zapewnić maksymalną interoperacyjność, optymalizację jakości konferencji w zależności od typu terminal i warunków sieciowych.

W zakresie rejestracji urządzeń znajdujących się w sieci zewnętrznej:o Możliwość rejestracji do 3 000 urządzeń,

W zakresie rejestracji urządzeń znajdujących w sieci wewnętrznej:o Możliwość rejestracji do 4 000 urządzeń,

W zakresie przepustowości bramy ISDN:o do 40 połączeń wideo 768 Kbps lub 100 połączeń wideo 384 Kbps lub 300

połączeń wideo 128 Kbps lub 600 połączeń głosowych.

Wdrożone rozwiązanie cechuje się dużą skalowalnością i możliwością łatwej rozbudowy. Przedstawione wyżej parametry pojemnościowe i wydajnościowe rozwiązania mogą zostać w łatwy sposób rozbudowane, zarówno poprzez zwiększenie ilości poszczególnych typów urządzeń w poszczególnych węzłach, jak i zwiększenie ilości węzłów.

Dostępne kanały

Rozwiązanie pozwala na nawiązywanie połączeń konferencyjnych zarówno poprzez sieć WAN Ministerstwa Sprawiedliwości, łącza ISDN, jak również sieć Internet.


24


Dodatkową zaletą rozwiązania jest dostępne oprogramowanie klienta H.460 pozwalającego na obsługę dostępu dla starszych typów terminali H.323, nie wspierających protokołu H.460. Rozwiązanie nie zawiera ograniczeń ilości obsługiwanych sesji w modelu licencyjnym.

Połączenia mogą być realizowane za pośrednictwem dowolnego terminala wideokonferencyjnego wspierającego protokół H.323 lub SIP, w szczególności terminali dostępnych na salach rozpraw takich producentów jak HUAWEI, COMARCH, CISCO, SONY oraz innych.

Rozwiązanie zawiera również kompletne oprogramowanie środowiska umożliwiające obsługę gości (uczestników), którzy nie dysponują terminalem wideokonferencyjnym za pomocą bezpłatnej i publicznie dostępnej aplikacji konferencyjnej. Aplikacja ta może zostać w łatwy sposób zainstalowana na komputerze gościa. Centralna infrastruktura wideokonferencyjna zapewnia w tym zakresie:

brak jakichkolwiek ograniczeń na ilość nazwanych uczestników korzystających z platformy w ten sposób,

obsługę 400 równoległych sesji dostępowych (audio/video/prezentacja/chat) wraz z oprogramowaniem serwera NAT trawersalu, streamingu (istnieje możliwość rozszerzenia ilości licencji w tym zakresie),

możliwość zdefiniowania 4 000 nazwanych użytkowników, którzy mogą być wyposażeni w konferencje indywidualne z pełnymi prawami moderacji oraz możliwością realizacji streamingu (istnieje możliwość rozszerzenia ilości licencji w tym zakresie).

Opis funkcjonalności

Podstawowym przeznaczeniem centralnej platformy wideokonferencyjnej jest obsługa połączeń realizowanych w ramach procedury postępowań sądowych, w szczególności zdalne przesłuchania świadka znajdującego się w lokalizacji innego sądu. Funkcjonalność ta realizowana jest z wykorzystaniem Systemu rejestracji rozpraw sądowych, którego elementem jest terminal wideokonferencyjny. W połączeniu takim zazwyczaj biorą udział uczestnicy znajdujący się na sali rozpraw (sędzia i strona) oraz jeden uczestnik zdalny (świadek). Rozwiązanie pozwala na realizację tego rodzaju połączeń z udziałem większej liczby uczestników, gdzie ograniczeniem w ilości uczestników jest jedynie wydajność platformy.

Centralna infrastruktura wideokonferencyjna zapewnia również możliwość planowania konferencji, rezerwacji zasobów wraz z wysyłaniem zaproszeń, jak również zestawianie konferencji ad-hoc.

Platforma zapewnia obsługę wideoterminali dowolnego producenta, zapewniając realizację wideokonferencji wielostronnych z pełnym transkodowaniem wideo i audio na każdym porcie wideo, obsługą kodowania H.264, protokołu H.264 SVC oraz formatu HD720p przy


25


odświeżaniu obrazu 30klatek/s. Platforma posiada możliwość jednoczesnej obsługi w ramach sesji wideokonferencyjnej stron z wideo Standard Definition (SD) oraz High Definition (HD), z kodowaniem H.264 (AVC i SVC).

Bezpieczeństwo komunikacji zapewnia szyfrowanie każdego z połączeń z wideoterminalem w trybie audio-wideo-dane, zgodnie ze standardem H.235 AES ze 128-bitowym kluczem symetrycznym wymienianym automatycznie. W ramach jednej wideokonferencji mogą być obsługiwane jednocześnie strony szyfrowane i nie-szyfrowane zgodnie z H.235.

Plan numeracyjny

W ramach wdrożenia zdefiniowany został jednolity plan numeracyjny wszystkich terminali dostarczonych do sal rozpraw. Plan ten bazuje na istniejących wyróżnikach jednostek sądów oraz pozwala na łatwe zidentyfikowanie i nawiązanie połączenia z wybranym terminalem w wybranej lokalizacji.

Centralna książka adresowa

W ramach rozwiązania zbudowana została centralna książka adresowa pozwalająca na łatwe odszukanie danej lokalizacji oraz nawiązanie połączenia z wybranym terminalem. Korzystanie z książki pozwala na łatwe nawiązywanie połączeń bez konieczności wprowadzania numerów ID urządzeń, adresów IP lub adresów SIP.

Centralne zarządzanie

Rozwiązanie pozwala na centralnie zarządzanie zasobami chmury, prowadzonymi wideokonferencjami oraz zarejestrowanymi urządzeniami. Możliwe jest m.in.:

tworzenie i zarządzanie konferencjami (np.: tworzenie konferencji zaplanowanych oraz ad-hoc, zmiana przepustowości przeznaczonej dla danej konferencji itd.),

zarządzanie urządzeniami, mostkami, bramami ISDN, gatekeeperami oraz terminalami i spotkaniami stałymi czy w wirtualnych pokojach indywidualnych,

planowanie i automatyczna organizacje konferencji, rezerwacje zasobów wraz z wysyłaniem zaproszeń,

moderowanie, monitorowanie i zarządzanie przebiegiem spotkań, monitorowanie informacji na temat rodzaju aktualnie prowadzonych konferencji oraz

liczby uczestników biorących w nich udział, zarządzania użytkownikami, grupami np. nadawanie odpowiednich uprawnień, zbieranie raportów i statystyk obejmujących rodzaj konferencji, czas trwania

konferencji, użycia przepustowości, itp.,


26


zarządzanie routingiem połączeń, definiowanie maksymalnej liczby rejestracji oraz maksymalnej liczby połączeń, definiowanie alternatywnego GK, włączanie usługi szyfrowania połączeń,

definiowanie podstref i przypisywanie określonej przepustowości dla połączeń w danej podstrefie.

8. Opis infrastruktury udostępniania nagrańCzytelnie akt są wyposażone w urządzenia typu „All-in-one” (model B). Do każdego

urządzenia typu „All-in-one” podłączone są dwa komplety słuchawek poprzez rozdzielacz sygnału audio.

Udostępnienie nagrania na wskazane stanowisko komputerowe w czytelni akt zarządzane jest z poziomu warstwy centralnej systemu rejestracji.

Poprawna konfiguracja aplikacji centralnej do odtwarzania nagrań w czytelni akt oraz zarządzania nagraniami w czytelni zapewnia:

możliwość otworzenia pliku nagrania. możliwość automatycznego odtworzenia nagrania przy pomocy wprowadzonego

tokena dostępu. możliwość zarządzania procesem odtwarzania, np.: przewijanie, skok w określone

miejsce, regulację poziomu głośności odtwarzania nagrania, regulację poziomu głośności odtwarzania poszczególnych ścieżek, regulację szybkości odtwarzania i przewijania, wybór kombinacji ścieżek do odtwarzania.

możliwość zlecenia z poziomu komputera zarządzającego usunięcie nagrań z udziału z dowolnego komputera udostępniającego.

Słuchawki są również wykorzystywane przez sędziów i asystentów sędziów do odsłuchiwania nagrań wytworzonych w systemie.


27


V. Charakterystyka obecnego Systemu Portal Informacyjny

Portal Informacyjny Sądów Powszechnych (dalej: „Portal Informacyjny”), umożliwia dostęp uprawnionym lub upoważnionym podmiotom do informacji o sprawach toczących się przed sądami powszechnymi za pośrednictwem Internetu. Zarejestrowany w Portalu Informacyjnym użytkownik otrzymuje dostęp do danych o sprawie obejmujących m. in.:

stan sprawy, tzn. na jakim etapie procedowania znajduje się teraz proces sądowy, czynności wykonane przez sąd wraz z określeniem osoby odpowiedzialnej za jej

wykonanie oraz daty (np. przekazanie akt biegłemu celem wydania opinii), wyznaczone terminy posiedzeń, dokumenty w sprawie wygenerowane przez sąd w postaci elektronicznej (pisma

wychodzące, wyroki, postanowienia, uzasadnienia, protokoły z rozpraw), dane dotyczące postępowania w niższej instancji o ile takie istnieją, protokół elektroniczny z możliwością odsłuchania.

Korzyściami jakie płyną z funkcjonowania Portalu jest m. in. oszczędność czasu i pieniędzy stron i pełnomocników oraz przyspieszenie pracy sądu przez odciążenie sekretariatów od obowiązku udzielania informacji i wydawania dokumentów uczestnikom postępowań.

Portal Informacyjny w obecnym kształcie realizuje ideę pojedynczego punktu dostępu do danych o sprawach na poziomie całej apelacji, co oznacza, że istnieje 11 instancji Portalu, z których każdy posiada odrębną bazę danych. Czas dostępności systemu wynosi 24/7 (całą dobę przez 7 dni w tygodniu). Jednym z głównych elementów Portalu Informacyjnego jest importer danych z systemów lokalnych znajdujących się w sądach. Zadaniem oprogramowania służącego do importu danych do Portalu Informacyjnego jest pobieranie danych o sprawach, dokumentów przeznaczonych do publikacji oraz nagrań e-protokołu z sądu do infrastruktury centralnej i zasilanie nimi bazy danych Portalu. Celem jego działania jest kompletność, spójność i aktualność informacji dostępnych za pośrednictwem Portalu Informacyjnego. Źródłem pobieranych danych są bazy danych programów repertoryjno-biurowych zainstalowane w sądach oraz repozytoria e-protokołu. Głównymi komponentami Portalu Informacyjnego są:1. Aplikacja webowa Portal Informacyjny;2. Aplikacja webowa Panel Administracyjny;3. Importer danych z systemów repertoryjno-biurowych oraz usługa aktualizacji danych;4. Moduł importu nagrań elektronicznego protokołu oraz ich udostępniania na potrzeby odtworzenia.


28


Podstawowa funkcjonalność Portalu Informacyjnego:1. Rozwiązanie umożliwia:

a. import danych o sprawach oraz dokumentów;b. wnioskowanie i rozpatrywanie dostępów do spraw;c. obsługę użytkowników systemu o różnych uprawnieniach:

ADMINISTRATOR - administrator systemu, w systemie może być zarejestrowanych wielu administratorów

USER - zwykły użytkownik systemu (np. strona w sprawie) ATTORNEY - użytkownik profesjonalny- pełnomocnik PROSECUTION - prokuratura SUBUSER - użytkownik zależny od innego użytkownika (subkonto) JUDGE - sędzia INFO_POINT_EMPLOYEE - pracownik punktu informacyjnego EMPLOYEE - pracownik wydziału BORDER_GURAD – straż graniczna CIVIL_REGISTRY – urząd stanu cywilnego CUSTOMS_OFFICE – urząd celny GENERAL_ATTORNEY_OF_THE_TREASURY – prokuratoria generalna

skarbu państwa HELPDESK – pracownik typu helpdesk obsługujący zgłoszenia błędów INSPECTORATE_OF_ROAD_TRANSPORT – inspektorat transportu

drogowego INSTITUTION_ZUS – zakład ubezpieczeń społecznych POLICE_STATION – policja SUPER_ADMINISTRATOR – użytkownik posiadający prawo do zarządzania

wszystkimi kontami i wydziałami w danej apelacji TAX_OFFICE – urząd skarbowy KRUS PIP

d. zarządzanie procesami biznesowymi za pomocą panelu administracyjnego;e. logowanie zdarzeń systemowych;f. zarządzanie użytkownikami;g. możliwość przeszukiwania spraw na podstawie określonych kryteriów;h. wyświetlanie graficznego kalendarza posiedzeń sądowych;i. przesyłanie powiadomień e-mail o zdarzeniach w systemie;j. wyświetlanie statystyk ilościowych spraw oraz użytkowników;k. zgłaszanie błędów i uwag za pomocą konfigurowalnego formularza zgłoszeń;

2. Proces importu danych o sprawie zapewnia:

a. import wskazanych danych o sprawach oraz dokumentów;b. harmonogram uruchomienia;


29


c. raportowanie statusu importu i informacji pomocniczych;d. kompresję danych;e. szyfrowanie transferu danych;f. automatyczne aktualizacje oprogramowania importującego.

Aplikacja webowa Portal Informacyjny umożliwia logowanie się użytkowników. W przypadku pierwszego korzystania z portalu należy dokonać rejestracji. Dane użytkownika podane podczas wypełniania „Wniosku o rejestrację” podlegają weryfikacji przeprowadzanej przez pracowników Punktu informacyjnego sądu, albo użytkownik składa „Oświadczenie” zawierające zgodę na przekazanie danych osobowych w celu udostępniania danych , o których mowa w §106 rozporządzenia Ministra Sprawiedliwości z dnia 23 grudnia 2015 i podpisuje go kwalifikowanym podpisem elektronicznym w rozumieniu art. 3 pkt 12 Rozporządzenia Parlamentu Europejskiego i Rady (UE) z dnia 23 lipca 2014 r. w sprawie identyfikacji elektronicznej i usług zaufania w odniesieniu do transakcji elektronicznych na rynku wewnętrznym oraz uchylające dyrektywę 1999/93/WE albo podpisem potwierdzonym profilem zaufanym ePUAP. Po pomyślnie zakończonej weryfikacji podmiotu uprawnionego użytkownik dostaje login i hasło umożliwiające dostęp do konta. Dla osób, które w celu weryfikacji danych zgłosiły się do Punktu informacyjnego sądu dane niezbędne do zalogowania wydawane są w postaci wydruku. Osoby, które rejestrowały i uwierzytelniały się drogą elektroniczną, login do Portalu otrzymują za pomocą poczty elektronicznej.

Aplikacja webowa Portal Informacyjny w celu pogrupowania treści została zaprojektowana w formie Zakładek. W zależności od swego przeznaczenia realizują one różne funkcjonalności tj. w szczególności:1. Zakładka „Start” to miejsce gdzie znajdują się podstawowe informacje dotyczące spraw,

postepowań w jakich bierze udział użytkownik. Mogą to być: Aktualne sprawy, najbliższe posiedzenia oraz ostatnie czynności. W tym miejscu istnieje możliwość skorzystania z graficznego kalendarza w celu wyświetlenia posiedzeń.

2. Zakładka „Sprawy” to sekcja w której znajdują się wszystkie postępowania dotyczące użytkownika

3. Zakładka „Posiedzenia” wyświetla listę posiedzeń, które odbyły się lub odbędą we wszystkich dostępnych sprawach. Możliwe jest przeszukiwanie, filtrowanie oraz sortowanie listy posiedzeń.

4. Zakładka „Czynności” to dostęp do wszystkich czynności wykonywanych w sprawach dostępnych dla użytkownika.

5. Zakładka „Wnioski” jest to formularz składania wniosku o dostęp do sprawy przez użytkownika.

6. Zakładka „Mój profil” jest to miejsce gdzie znajdują się dane osobowe użytkownika. Mogą one być dodawane lub zmieniane poprzez edycję. Dodatkowa funkcją dla


30


użytkowników typu pełnomocnik, sędzia oraz prokuratura jest możliwość tworzenia tzw. subkont.

Panel Administracyjny jest to aplikacja webowa, której przeznaczeniem jest realizacja procesów biznesowych Systemu oraz administracja użytkownikami systemu. Jest to rozbudowana sekcja w skład której wchodzą zakładki:

Konta użytkownika - wyświetla listę użytkowników systemu. Złożone wnioski – tutaj wyświetlane są wnioski o dostęp do sprawy złożonych przez

użytkowników zewnętrznych. Wydziały – informacje widoczne wyłącznie dla konta typu administrator.

Wyświetlane są listy wydziałów sądu z możliwością edycji ich adresu e-mail. Logi – darzenia mające miejsce w systemie. Raporty - wyświetla ilość spraw udostępnionych różnym typom użytkowników.

Portal SMIPI (System Monitorowania Interfejsów Portalu Informacyjnego) jest to aplikacja webowa której przeznaczeniem jest wsparcie grup utrzymaniowych w rozwiazywaniu zgłoszeń użytkowników i zapewnieniu monitoringu ciągłości działania procesów importu w tym usług lokalnych zainstalowanych po stronie sądu.

Importer danych z systemu repertoryjno-biurowego oraz usługa aktualizacji danych

Zadaniem oprogramowania służącego do importu danych do Portalu Informacyjnego jest pobieranie danych o sprawach oraz wskazanych dokumentów z sądu do infrastruktury centralnej i zasilanie nimi bazy danych Portalu. Celem jego działania jest kompletność, spójność i aktualność informacji dostępnych za pośrednictwem Systemu. Źródłem pobieranych danych są bazy danych programów repertoryjno-biurowych zainstalowane w sądach. Program importuje dane z 1354 baz systemu SAWA, 112 baz systemu Sędzia2 oraz 2 baz systemu Peaetor.

Zakres pobieranych danych

Proces importu zakłada synchronizację następujących danych:1. Sprawy – w tym m.in sygnatury, daty wpływu i zakreślenia, przedmioty spraw,

sędziowie referenci. Przedział czasowy, z jakiego importowane są sprawy jest konfigurowalny, w oderwaniu od konfiguracji, zawsze importowane są wszystkie sprawy w toku.

2. Posiedzenia – terminy, sale, w których odbywają się rozprawy, tryby, sędziowie prowadzący itp. Importowane są dane tylko o tych posiedzeniach, które spełniają określone przez sąd warunki jawności.

3. Podmioty – imiona i nazwiska (nazwy) oraz adresy wszystkich podmiotów występujących w sprawie tj. stron, oskarżycieli, pełnomocników, kuratorów, biegłych itp. Importer uwzględnia odpowiednie fakty dotyczące podmiotów np. zwolnienie pełnomocnika, wyłączenie strony z postępowania itp. Dodatkowo,


31


synchronizacja danych bierze pod uwagę decyzje sądów dotyczące nieimportowania części danych np. o świadkach.

4. Czynności – nazwy, daty wykonania i wykonawcy czynności w ramach konkretnych spraw m.in. odnotowanie faktów przyjęcia wniosków czy wysłania pism.

5. Dokumenty – treści i nazwy dokumentów w sprawie w szczególności orzeczeń, protokołów oraz korespondencji. Treści dokumentów importowane są lub nie w zależności wybranej przez sąd strategii publikacji (wszystkie lub oznaczone do publikacji) odrębnie dla orzeczeń i pism. Dokumenty wycofane z publikacji zostają również wycofane w Portalu Informacyjnego. Dokumenty zmienione, ulegają aktualizacji na Portalu Informacyjnym.

Ponadto, program importujący łączy uprawnione lub upoważnione na mocy przepisów szczególnych podmioty w sprawie z użytkownikami portalu, tak by właściciele kont otrzymywali automatycznie dostęp do spraw, w których biorą udział. Łączenie odbywa się to pomocą identyfikatora tj. numeru PESEL, numeru i serii dokumentu tożsamości lub identyfikatora jednostki (w przypadku instytucji). Dostęp do sprawy odbierany jest w przypadku odwiązania identyfikatora oraz zmianie statusu w przypadku pełnomocników.

Zakres pobieranych danych obejmuje w szczególności:1. Nazwa sądu;2. Nazwa wydziału;3. Rok sprawy;4. Numer sprawy;5. Numer wydziału;6. Repertorium;7. Sygnatura sprawy (np. I ACa 1343/12);8. Przedmiot sprawy;9. Wartość przedmiotu sporu (jeżeli niezerowy);10. Rozstrzygnięcie;11. Data wpływu sprawy (data pierwotnego wpływu);12. Data zakończenia (data zakreślenia sprawy);13. Stan sprawy;14. Imię nazwisko sędziego;15. Tytuł sędziego;16. Podmioty (uczestnicy postępowania – osoba fizyczna lub prawna):

Typ podmiotu (np. strona, pełnomocnik, prokuratura, biegły); Imię i nazwisko, nazwa dla osoby prawnej lub instytucji; adres (np. ul. Kochanowskiego 9, 50-345 Wrocław) lub lista adresów

jeżeli wiele;


32


rola w sprawie (np. Oskarżony, obrońca, pełnomocnik, wnioskodawca, …);

id osoby (pesel dla osoby fizycznej, kod jednostki dla instytucji); id reprezentowanej osoby (id podmiotu reprezentowanego, tylko dla

pełnomocników); wybór (z urzędu, z wyboru, tylko dla pełnomocników); status (-, zwolniony, zmarł, wypowiedziane pełnomocnictwo, …, tylko

dla pełnomocników);17. Posiedzenia

tryb (np. posiedzenie, rozprawa); numer sali; data i godzina (np. 2014-01-22 13:00); imię, nazwisko i tytuł sędziego przewodniczącego (jeżeli skład

jednoosobowy i sędzia przewodniczący nieustalony, to sędzia referent); wynik (np. postanowienie);

18. Dokumenty nazwa; typ dokumentu; data sporządzenia; treść (do pobrania w formacie źródłowym i w formacie pdf);

19. Czynności Typ czynności (czynność, dokument, termin, …); nazwa czynności; data wykonania; id dokumentu (jeżeli czynność powiązana z dokumentem); osoby powiązane z czynnością

odpowiedzialny (imię i nazwisko/oznaczenie sekretariat); adresat (jeżeli czynność dotyczy przesyłki); nadawca (jeżeli czynność dotyczy przesyłki);

uwagi;20. Powiązania między sprawami

sygnatura sprawy; nazwa sądu; imię, nazwisko i tytuł sędziego; data wpływu; data orzeczenia; rodzaj powiązania

21. Dodatkowe atrybuty sprawy (planowane do realizacji w 2017 r.)


33


data pierwotnego wpływu data zakończenia (data orzeczenia kończącego) data prawomocności orzeczenia kończącego (prawomocność sprawy) symbol sprawy opis symbolu sprawy ilość tomów akt x 3 (kilka pól) data zawieszenia (multi) data podjęcia (multi) struktura wpływu (id, opis) struktura załatwienia (id, opis) data pierwszego wniosku o uzasadnienie (przyjętego niewycofanego) data uzasadnienia czy uzasadnienie z urzędu czy uzasadnienie wygłoszone czy uzasadnienie sporządził asystent, daty doręczenie pism.

Opis działania programu importującego

Program importujący jest aplikacją działająca w środowisku teleinformatycznym danego sądu i składa się z usługi głównej odpowiedzialnej za uruchomienie właściwego programu importującego i jego aktualizację oraz usługi pomocniczej odpowiedzialnej m.in. za uruchomienie usługi głównej w przypadku jej nagłego zatrzymania oraz monitorowanie. Usługa główna odpytuje w określonym interwale serwer w celu pobrania aktualnego pliku konfiguracji zdalnej. W sytuacji, gdy pojawi się nowa wersja programu importującego, usługa dokonuje aktualizacji. Właściwy program importujący korzysta ze wskazanego w konfiguracji lokalnej katalogu tymczasowego, gdzie składuje pobierane dane oraz ich stan. Po zakończeniu procesu zbierania danych z serwera bazodanowego, tworzona jest paczka skompresowanego archiwum zip i przesyłana do serwera centralnego za pośrednictwem protokołu SFTP (rozszerzenie protokołu SSH-2). Zarówno usługa jak i program importujący generują odpowiednio logi z wykonywanych operacji. Program umożliwia import przyrostowy, tzn., że pobierane są wyłącznie dane nowe lub zmienione od czasu poprzedniego importu oraz pełny, podczas którego pobierane wszystkie dane zaznaczone do importu niezależnie od tego, czy były już wcześniej pobrane. Tryb przyrostowy jest domyślny, tryb pełnego importu używany jest, gdy nowa wersja importera wprowadza zmiany, które wymagają ponownego pobrania wszystkich danych.

Konfiguracje programu importującego


34


Konfiguracja działania programu importującego składa się z dwóch części – konfiguracji lokalnej (modyfikowanej przez dany sąd) oraz konfiguracji zdalnej zarządzanej z infrastruktury centralnej.

Plik lokalnej konfiguracji będący częścią importera zainstalowanego w sądzie określa m.in. takie parametry jak: identyfikator sądu i wydziałów, informacje niezbędne do połączenia z serwerem MS SQL, ścieżka do pliku zdalnej konfiguracji, katalog roboczy oraz lista wydziałów sądu, które znajdują się w danej lokalizacji. Importer przewiduje istnienie wielu lokalizacji baz danych dla jednego sądu.

W pliku konfiguracji zdalnej dla każdego sądu istnieje odpowiednia sekcja dotycząca ustawień importu. Określa on m. in parametry połączenia do serwera w infrastrukturze centralnej, na który mają być przesyłane dane, typ programu repertoryjno-biurowego, model importu dokumentów, zakres dat spraw do importu oraz listę wydziałów, dla których chcemy określić dodatkowe parametry importu. Konfiguracja zawiera również harmonogram uruchomienia programu importującego.

Mechanizm zasilający bazę danych Systemu

Mechanizm zasilający bazę danych systemu jest oprogramowaniem zainstalowanym na serwerze aktualizacji Systemu (serwer update), na który wysyłane są dane przez programy importujące. Jego zadaniem jest zasilenie otrzymanymi danymi relacyjnej bazy danych PostgreSQL 9.3 oraz zasobów dyskowych stanowiących magazyn danych Portali Informacyjnych. Mechanizm odpowiedzialny jest również za rozsyłanie powiadomień e-mail dla użytkowników systemu wyzwalanych określonymi zdarzeniami (np. aktywacja konta, informacja o zmianach w sprawie) oraz zasilanie bazy logów zdarzeniami generowanymi przez użytkowników.

Moduł importu nagrań elektronicznego protokołu oraz ich udostępniania na potrzeby odtwarzania.

Zadaniem oprogramowania służącego do importu oraz prezentacji nagrań e-protokołu jest bezpieczny transport nagrania audio e-protokołu wraz z dodatkowymi plikami z lokalnego repozytorium plików sądu do centralnego repozytorium plików na potrzeby udostępnienia nagrania za pośrednictwem Portalu Informacyjnego w sprawie i posiedzeniu, dla którego nagranie zostało sporządzone. Program importuje nagrania z około 400 lokalizacji sądów powszechnych.

Zakres pobieranych danych na potrzeby publikacji e-protokołu

Program importujący pobiera z lokalnego repozytorium następujące pliki:


35


plik audio w formacie .oga plik protokołu skróconego w formacie .rft plik adnotacji publicznych w formacie .xml plik metadanych posiedzenia w formacie .xml

Opis działania programu importującego e-protokół

Program importujący jest aplikacją działająca w środowisku teleinformatycznym danego sądu i składa się z usługi uruchomionej w tle oraz właściwego programu importującego. Usługa odpowiada za kontrolę uruchamiania procesu importu oraz jego aktualizacje. W tym celu odpytuje w określonym interwale serwer w celu pobrania aktualnego pliku konfiguracji zdalnej. W sytuacji, gdy pojawi się nowa wersja programu importującego, usługa dokonuje aktualizacji. Właściwy program importujący korzysta ze wskazanego w konfiguracji lokalnej katalogu tymczasowego, gdzie składuje pobierane dane. Po zakończeniu procesu zbierania danych z repozytorium plików, tworzona jest paczka skompresowanego archiwum zip i przesyłana do serwera centralnego za pośrednictwem protokołu SFTP (rozszerzenie protokołu SSH-2). Zarówno usługa jak i program importujący generują odpowiednio logi z wykonywanych operacji. Program umożliwia import przyrostowy, tzn., że pobierane są wyłącznie dane nowe lub zmienione od czasu poprzedniego importu oraz pełny, podczas którego pobierane wszystkie dane zaznaczone do importu niezależnie od tego, czy były już wcześniej pobrane. Tryb przyrostowy jest domyślny, tryb pełnego importu używany jest, gdy nowa wersja importera wprowadza zmiany, które wymagają ponownego pobrania wszystkich danych.

Program importuje wyłącznie pliki, które zostały utworzone wcześniej niż 72 godziny przed aktualną datą importu.

Konfiguracja działania programu importującego składa się z dwóch części – konfiguracji lokalnej (modyfikowanej przez dany sąd) oraz konfiguracji zdalnej zarządzanej z infrastruktury centralnej.

Plik lokalnej konfiguracji będący częścią importera zainstalowanego w sądzie określa m.in. takie parametry jak: ścieżka do repozytorium plików, informacje niezbędne do autoryzowania się do repozytorium plików (autoryzacja zintegrowana z systemem operacyjnym lub oparta na loginie i haśle), ścieżka do pliku zdalnej konfiguracji, katalog roboczy oraz lista wydziałów sądu, dla których uruchomiony ma być import. Importer przewiduje istnienie wielu repozytoriów plików w ramach jednego sądu.

W pliku konfiguracji zdalnej dla każdego sądu istnieć musi odpowiednia sekcja dotycząca ustawień importu. Określa on parametry połączenia do serwera w infrastrukturze centralnej, na który mają być przesyłane dane. Konfiguracja zawiera również harmonogram uruchomienia programu importującego.

Program importujący posiada pakiet instalacyjny systemu Windows.


36


Prezentacja nagrań e-protokołu w Portalu Informacyjnym

Wizualizacja e-protokołu w Portalu Informacyjnym odbywa się za pośrednictwem listy posiedzeń w sprawie. Możliwe jest zapoznanie się z nagraniem audio za pomocą webowego odtwarzacza, który posiada pasek postępu załadowania nagrania oraz nawigacji po nagraniu za pomocą myszki. Odtwarzacz powiązany jest z adnotacjami publicznymi, które wyświetlone są poniżej, istnieje powiązanie pomiędzy czasem odtwarzania a odpowiadającą mu adnotacją publiczną. Technologią wykorzystaną przy realizacji odtwarzacza webowego jest Adobe Flash. Nawigacja po nagraniu odbywa się również za pomocą listy adnotacji publicznych. Możliwe jest pełnotekstowe wyszukiwanie tekstu w adnotacjach publicznych.

Drugim sposobem dostępu do zapisu e-protokołu jest możliwość pobrania skompresowanej do formatu .zip paczki zawierającej nagranie, protokół skrócony i adnotacje publiczne. Paczka zip tworzona jest dynamicznie w momencie wywołania pobierania. Dodatkowo w sytuacji, gdy dla danej sprawy dostępne jest co najmniej jedno nagranie e-protokołu, dostępny jest do pobrania odtwarzacz ReCourt Player.

Mechanizmy powiązania i konwersji plików

Mechanizmy powiązania i konwersji plików odpowiedzialne są za dekompresję paczek z elektronicznym protokołem na serwerze aktualizacji a następnie umieszczenie ich we właściwym miejscu w repozytorium plików oraz dowiązanie do istniejącego posiedzenia w sprawie opublikowanej w Portalu Informacyjnym.


37


VI. Wymagania szczegółowe

1. Przeprowadzenie Analizy biznesowej i systemowejWykonawca zrealizuje analizę biznesową i systemową, pełniącą rolę analizy przedwdrożeniowej. W ramach realizacji prac analitycznych Wykonawca przeprowadzi spotkania analityczne z pracownikami Zamawiającego ukierunkowane m.in. na: szczegółową analizę procesową obecnego i docelowego modelu działania Zamawiającego w obszarze wdrożenia. Na podstawie wyników analizy procesowej dokona weryfikacji i uszczegółowienia realizacyjnego wszystkich zdefiniowanych w OPZ wymagań funkcjonalnych i niefunkcjonalnych dla ustalenia oczekiwanego sposobu ich realizacji w procesach Zamawiającego i w systemie Wykonawcy. Analiza obejmuje więc budowę modeli biznesowych działania organizacji i powiązania z nimi konkretnych wymagań z OPZ (patrz wzór dokumentu analizy w Załączniku Nr S.01 do OPZ). Analiza wykonana zostanie w standardzie BPMN, notacji UML lub Archimate 2.0. Wykonawca dostarczy diagramy w formacie akceptowalnym przez narzędzie Enterprise Architect v.13.

Produktem prac będzie analiza w postaci raportu zawierającego koncepcję procesów docelowych Zamawiającego w obszarze planowanego wdrożenia wraz z modelem ich wsparcia projektowanym systemem.

Analiza Systemowa podlega akceptacji Zamawiającego zgodnie z procedurą akceptacji zawartą w OPZ Załącznik nr 4 Sekcja 1.2.6.3

Patrz również wymagania zdefiniowane w Rozdziale VI.7 w sekcji [Dokumentacja systemowa].

2. Projekt Techniczny i Projekt GraficznyProjekt Techniczny zostanie opracowany przez Wykonawcę na postawie zatwierdzonych przez Zamawiającego wyników analizy systemowej (w tym opracowanych modeli procesowych). Obejmować musi kompleksowo wszystkie zagadnienia funkcjonalne i techniczne projektowanego rozwiązania. W Projekcie Technicznym zostanie opisany szczegółowo sposób konfiguracji systemu w organizacji Zamawiającego, określając przy tym sposób realizacji każdego z wymagań zdefiniowanych w OPZ i Analizie biznesowo-systemowej. Wymaganie odnośnie zawartości Projektu Technicznego znajdują się w sekcji Projekt Techniczny w Rozdziale VI.7.

Projekt Techniczny obejmować musi kompletną i szczegółową koncepcję wdrożenia wszystkich elementów składających się na rozwiązanie docelowe, ze szczególnym uwzględnieniem zagadnień międzysystemowej wymiany danych.


38


Wraz z Projektem Technicznym Wykonawca przekaże Zamawiającemu oświadczenie, z treści którego wynikać będzie jednoznacznie możliwość uzyskania na bazie przyjętych w dokumencie rozwiązań, rezultatu końcowego określonego przez Zamawiającego w OPZ.

Interfejs Portalu Informacyjnego zostanie przebudowany w całości z uwzględnieniem nowych funkcjonalności. W zakresie projektu interfejsu www portalu PI i aplikacji mobilnej wymagane jest w szczególności:

zamodelowanie każdego z przypadków użycia systemu (dla każdej z ról) wraz ze stosownymi scenariuszami,

zaprojektowanie makiet każdego z ekranów – muszą one prezentować w szczególności: układ stron, rozmieszczenie poszczególnych pól, danych, treści, formularzy i elementów interaktywnych na stronie,

ustalenie dla każdego z formularzy i pól formularzy stosownych: słowników, mechanizmów walidacji wprowadzanych danych, pomocy itd.

utworzenie na bazie makiet nawigowalnego prototypu portalu (w narzędziach do projektowania prototypów typu Axure lub dowolnych innych) – akceptacja prototypu portalu stanowi podstawę dla podjęcia prac w zakresie projektu graficznego rozwiązania,

opracowanie Projektu graficznego (szaty graficznej) portalu. Dla uzgodnionego z Zamawiającym projektu interfejsu użytkownika (zatwierdzonego prototypu portalu) zostaną ̨ przygotowane przez Wykonawcę trzy istotnie różne warianty koncepcji graficznej portalu do wyboru przez Zamawiającego (oparte na nie więcej niż 2 ustalonych z Zamawiającym makietach). Zamawiający jednocześnie zastrzega możliwość dostarczenia własnego wariantu grafiki do zastosowania na portalu. Wybrany przez Zamawiającego wariant projektu graficznego zostanie stosownie rozwinięty i zastosowany przez Wykonawcę na wszystkich makietach portalu. Na podstawie wybranego wariantu projektu graficznego portalu zostanie również opracowana spójna z portalem koncepcja graficzna interfejsu aplikacji mobilnej,

spełnienie przez projektowane rozwiązanie standardów projektowania interfejsu wskazanych w Sekcji [Wymagane zgodności z normami] i WCAG 2.0 zgodnie z poziomami określonymi w Rozdziale VI.3.6 Wymagania niefunkcjonalne.

Modele zawarte w Projekcie Technicznym opracowane zostaną przez Wykonawcę w notacji UML lub Archimate 2.0.

Projekt Techniczny podlega akceptacji Zamawiającego – stanowi podstawę dla dalszych prac instalacyjnych, konfiguracyjnych oraz implementacyjnych Wykonawcy. Procedura akceptacji została zawarta w OPZ Załącznik nr 4 sekcja 1.2.6.3.

Patrz również wymagania zdefiniowane w Rozdziale VI.7 Opracowanie dokumentacji OPZ w Sekcji [Dokumentacja systemowa].


39


3. Opis wymagań funkcjonalnych i niefunkcjonalnych dla rozbudowy PI

3.1 e-Usługa udostępniania protokołu elektronicznegoW ramach realizacji e-usługi udostępniania protokołu elektronicznego Wykonawca ma zapewnić następujące funkcjonalności:

Rysunek 4 Obsługa wniosku o udostępnienie pliku audio-wideo e-protokołu

1. Udostępnienie protokołu elektronicznego zapisu audio-wideo (e-protokół) oraz ustnego uzasadnienia orzeczenia sądowego (e-uzasadnienia) a. umożliwienie wnioskowania o udostępnienie zapisu audio-wideo z posiedzenia

z poziomu listy posiedzeń w sprawie oraz listy wniosków; (wniosek dostępny dopiero po udostępnieniu zapisu audio e-protokołu na PI)

b. sprawdzenie w Systemie CRCS lokalizacji i dostępności nagrania c. pobranie z Systemu CAPE niezbędnych plików e-protokołu lub e-uzasadnieniad. pobranie pliku z audio-wideo z Systemu CAPE i umieszczenie go we

właściwym miejscu w repozytorium plików oraz dowiązanie do istniejącego posiedzenia w sprawie opublikowanej na Portalu Informacyjnym

e. Przesłanie informacji zwrotnej o realizacji lub odrzuceniu wniosku na adres e-mail użytkownika lub umieszczenie jej w module powiadomień Portalu Informacyjnego w zależności od ustawionych preferencji użytkownika

f. udostępnienie wnioskodawcy w przypadku pozytywnej weryfikacji złożonego uprzednio wniosku, na określony czas (wg. globalnego parametru konfiguracyjnego), nagrania audio-wideo (plik w formacie .ogg albo .webm) wraz z plikiem adnotacji, protokołem skróconym i plikiem z transkrypcji (jeśli


40


była wykonywana); długość czasu udostępnienia zdefiniowana parametrycznie z możliwością zmiany przez administratora Systemu;

g. przeniesienie nagrania po upływie okresu publikacji z zasobów udostępnionych nagrań do zasobu nagrań archiwalnych, z których będzie można skorzystać w przypadku złożenia kolejnego wniosku w terminie późniejszym;

h. zasób archiwalny musi mieć konfigurowalny mechanizm usuwania starych nagrań

i. musi być możliwe zapoznania się z nagraniem audio-wideo w wybrany przez użytkownika sposób:

za pośrednictwem dedykowanego oprogramowania udostępnionego na stronie Portalu Informacyjnego – parz pkt. 2 poniżej.

za pośrednictwem pobranego oprogramowania ReCourt Player odtwarzającego pobrane i zapisane na komputerze użytkownika pliki- patrz pkt. 3 poniżej

– zgodnie szczegółowymi opisami przedstawionymi w kolejnych sekcjach.

2. Zapoznawanie się z nagraniem audio-wideo protokołu elektronicznego za pośrednictwem dedykowanego oprogramowania udostępnionego dla użytkowników Portalu Informacyjnego

musi być możliwe zapoznanie się z nagraniem wideo za pomocą webowego odtwarzacza, który posiada pasek postępu załadowania nagrania oraz nawigacji po nagraniu za pomocą myszki lub klawiatury. Umożliwia takie operacje jak uruchomienie, wstrzymanie, zakończenie odtwarzania, regulację głośności odtwarzania, przewijanie / przeskakiwanie do dowolnego momentu nagrania. Odtwarzacz powiązany jest z adnotacjami publicznymi, które wyświetlone są w oknie aplikacji odtwarzacza, istnieje powiązanie pomiędzy czasem odtwarzania a odpowiadającą mu adnotacją publiczną. Nawigacja po nagraniu odbywa się również za pomocą listy adnotacji publicznych. Możliwe jest wyszukiwanie tekstu w adnotacjach publicznych (istniejąca funkcjonalność).

3. Zapisanie nagrania audio-wideo e-protokołu na komputerze a. musi być możliwe pobranie skompresowanej do formatu .zip paczki

zawierającej nagranie, protokół skrócony i adnotacje publiczne oraz transkrypcję (jeśli była wykonana). Paczka zip tworzona jest dynamicznie w momencie wywołania pobierania

b. musi być możliwe pobrania odtwarzacza ReCourt Player w odpowiedniej wersji

4. Rezerwacja czytelni celem zapoznania się ̨ z aktami sprawy, w tym z zapisem- e-protokołu


41


a. wyświetlenie kalendarza wraz z listą dostępności dni i godzin dla danej czytelni (dane pobierane z Systemu RCS)

b. musi być możliwość wypełnienia wniosku do zdalnej rezerwacji miejsca w czytelni poprzez wskazanie sądu, daty rezerwacji, szacowanego czasu na zapoznanie się̨ z zapisem, danych osoby wnioskującej oraz wielu sygnatur akt wnioskowanych spraw wraz z datami posiedzeń, oznaczeniami wydziałów, ról w sprawie

c. Wykonawca powinien zapewnić mechanizm automatycznego wypełniania wniosków danymi na podstawie kontekstu pracy użytkownika

d. musi być możliwość wyboru przedmiotu udostępnienia (e-protokół lub akta sprawy)

e. przesłanie wstępnej rezerwacji do Systemu RCS, poinformowanie użytkownika, że jest to tylko wstępna rezerwacja, a wniosek dopiero będzie rozpatrzony przez pracowników sądu

f. otrzymanie z Systemu RCS potwierdzenia skutecznego dokonania rezerwacji stanowiska komputerowego

g. przesłanie użytkownikowi potwierdzenia dokonania rezerwacji w wiadomości e-mail lub umieszczenie jej w module powiadomień PI, w zależności od ustawionych preferencji w systemie,

h. funkcjonalność dostępna po wyborze przez użytkownika sprawy do przeglądania

i. Wykonawca powinien zapewnić logowanie zdarzeń systemowych do bazy danych logów za pomocą istniejącego systemu kolejkowania zdarzeń i bazy logów – mongoDB.

Na rysunku poniżej zaprezentowano niezbędne interfejsy do realizacji e-usługi udostępniania protokołu elektronicznego. Wszystkie opisane modele interfejsów zarówno w tym rozdziale jak i kolejnych mogą zostać doprecyzowane przez Zamawiającego w zakresie szczegółowych zasad realizacji na etapie prac projektowych. Patrz również Załącznik nr 2 Opis interfejsów


42


1. Obsługa udostępnienia wideo e-protokołu, e-uzasadnienia – (w ramach procesu obsługi wniosku w RCS musi być sprawdzone w atrybutach rozprawy, czy można udostępnić wideo, czy rozprawa nie odbyła się przy drzwiach zamkniętych, było nagrywane tylko audio, nie jest to sprawa o wykroczenie itp.)

[Pobranie pliku audio-wideo e-protokołu] PI->CRCS: pobranie pliku wideo (sąd, wydział, sygnatura akt sprawy, data posiedzenia,

imię, nazwisko, pesel/identyfikator – dane osoby wnioskującej) – zwrot wartości: ścieżka do pliku wideo lub informacja o błędzie/braku możliwości udostępnienia (po stronie CRCS istnieje stosowny proces weryfikacji poprawności danych we wniosku)

PI->CAPE: pobranie pliku według wskazanej ścieżki (ścieżka)- zwrot: pliki;


43


2. Rezerwacja czytelni

[Aktualizacja kalendarza] PI->RCS: żądanie podania kalendarza zajętości dla danej czytelni (sąd, okres) – zwrot

wartości: kalendarz dla danego okresu

[Wniosek o rezerwację] PI->RCS: Przesłanie wniosku o rezerwację miejsca w czytelni (sąd, data rezerwacji,

szacowany czas na zapoznanie się z zapisem, imię, nazwisko, pesel wnioskodawcy, lista zawierająca wiele instancji składających się z: sygnatury akt sprawy, daty posiedzenia, oznaczenia wydziału, roli w sprawie, oznaczenie czy udostępnić także akta sprawy, oznaczenie czy udostępnić e-protokół) - zwrot wartości: nr. wniosku

RCS->PI: przesłanie potwierdzenia rezerwacji (nr. wniosku, informacja: potwierdzenie/odmowa, uzasadnienie np. dokumentacja papierowa nie jest dostępna w tym czasie) – zwracana wartość: możliwe najbliższe terminy –zwrot wartości: potwierdzenie przyjęcia

[Anulowanie wniosku o rezerwację] PI->RCS: Przesłanie odwołania rezerwacji (numer wniosku, rezygnacja) – zwrot:

potwierdzenie przyjęcia

3.2 e-Usługa automatycznej transkrypcji mowy na tekst

Rysunek 5 Obsługa wniosku o automatyczną transkrypcję

W ramach realizacji e-usługi automatycznej mowy na tekst Wykonawca ma zapewnić następujące funkcjonalności:


44


1. Musi być możliwość wnioskowania o automatyczną transkrypcję dźwięku utrwalonego w postaci cyfrowej na wniosek uczestnika postępowania

a. złożenia wniosku o dokonanie automatycznej transkrypcji zawierającego następujące dane: sąd, wydział, sygnatura akt sprawy, data posiedzenia, dane osoby wnioskującej, przedmiot: e-uzasadnienie/e-protokół

b. możliwość wnioskowania o autotranskrypcję fragmentu e-protokołuc. przesłanie danych do Systemu RCS d. automatyczna weryfikacja wniosku użytkownika przez System;

sprawdzenie w szczególności:i. czy nie jest dostępna wersja manualnej transkrypcji obejmującej

pożądany przedział czasowy (wykonanej przez transkrybentów w ośrodku transkrypcji); w przypadku dostępności pliku transkrypcji manualnej brak możliwości wysłania wniosku o automatyczną transkrypcję do RCS i wskazanie pliku tej transkrypcji;

ii. czy nie jest dostępna wersja automatycznej transkrypcji obejmującej pożądany przedział czasowy (zleconej w terminie wcześniejszym); w przypadku dostępności pliku transkrypcji automatycznej brak możliwości wysłania wniosku o automatyczną transkrypcję do RCS i wskazanie pliku tej transkrypcji;

e. poinformowanie użytkownika o przewidywanym czasie realizacji transkrypcji na bazie informacji przesłanej z Systemu RCS

f. możliwość wygenerowanie ostrzeżeń jakościowych w przypadku informacji o złej jakości pliku

g. musi być możliwość odtwarzania webowego e-protokołu łącznie z wyświetlaniem odpowiednich treści z pliku transkrypcyjnego (na analogicznej zasadzie jak adnotacji publicznych) W czasie odtwarzania podświetlają się wyrazy w znajdujących się poniżej odpowiednich treściach z pliku transkrypcji. Nawigacja po nagraniu odbywa się również za pomocą treści z transkrypcji. Musi być możliwe wyszukiwanie pełnotekstowe w zapisie transkrypcji w zakresie treści dotyczącej odtwarzanego nagrania. W tym celu Wykonawca może wykorzystać istniejący mechanizm wyszukiwania pełnotekstowego w adnotacjach. W ramach synchronizacji odtwarzania pliku audio-wideo i transkrypcji Wykonawca może wykorzystać mechanizm analogiczny jak do synchronizacji odtwarzania audio-wideo z adnotacjami.

h. musi być możliwość pobrania przez użytkownika skompresowanej do formatu .zip paczki zawierającej nagranie, protokół skrócony, adnotacje publiczne oraz transkrypcję i odtworzenie całości w odpowiedniej wersji ReCourt Player.


45


i. wyniki transkrypcji dostarczone będą w postaci dwóch plików .rtf i .xmlj. szczegółowy opis pliku .xml znajduje się w Załączniku nr 3 OPZ.k. przesłanie informacji do użytkownika o udostępnieniu pliku automatycznej

transkrypcji lub odmowie udostępnienia w wiadomości e-mail albo umieszczenie jej w module powiadomień PI– w zależności od ustawionych preferencji w systemie,

Wykonawca powinien zapewnić mechanizm automatycznego wypełniania wniosków danymi na podstawie kontekstu pracy użytkownika a także logowanie zdarzeń systemowych do bazy danych logów za pomocą istniejącego systemu kolejkowania zdarzeń i bazy logów – mongoDB.

Na rysunku poniżej zaprezentowano niezbędne interfejsy do realizacji e-usługi automatycznej transkrypcji mowy na tekst:

[Obsługa wniosku automatycznej transkrypcji]


46


1. PI->RCS: wniosek wykonania automatycznej transkrypcji e-uzasadnienia (sąd, wydział, sygnatura akt sprawy, data posiedzenia, dane osoby wnioskującej) - zwracana wartość: nr wniosku + przewidywany czas oczekiwania/odmowa – powód (może nim być np. informacja o złej jakości pliku, zbyt długa kolejka oczekujących itp.)

2. PI->RCS: wniosek wykonania automatycznej transkrypcji dla e-protokołu (sąd, wydział, sygnatura akt sprawy, data posiedzenia, dane osoby wnioskującej, przedział czasowy) - zwracana wartość: nr wniosku, przewidywany czas oczekiwania/odmowa, powód (może nim być np. informacja o złej jakości pliku, zbyt długa kolejka oczekujących itp.)

3. RCS->PI: przesłanie wyniku automatycznej transkrypcji (nr wniosku, pliki autotranskrypcji, dane o jakości transkrypcji) – zwracana wartość: potwierdzenie przyjęcia

Patrz również Załącznik nr 2 Opis interfejsów

3.3 e-Usługa przeprowadzenia rozprawy odmiejscowionejW ramach realizacji e-usługi przeprowadzania rozprawy odmiejscowionej Wykonawca ma zapewnić następujące funkcjonalności

Rysunek 6 Obsługa wniosku o przeprowadzenie rozprawy odmiejscowionej

1. Obsługa wniosków do rozprawy odmiejscowionej

Usługa rozprawy odmiejscowionej polega na tym, że uczestnicy postępowania, którzy nie są w stanie stawić się na rozprawę w danej miejscowości, mogą wnioskować o możliwość uczestniczenia w postępowaniu w innej, wybranej przez siebie lokalizacji. Po uwzględnieniu wniosku przez sądy, wnioskodawca może uczestniczyć w posiedzeniu sądowym, gdy przebywa w budynku innego sądu i tam dokonywać czynności procesowych. Przebieg


47


czynności procesowych będzie transmitowany z sali sądowej sądu prowadzącego postępowanie do miejsca pobytu uczestników postępowania oraz z miejsca pobytu uczestników postępowania do sali sądowej sądu prowadzącego postępowanie.

a. złożenie wniosku o przeprowadzenie rozprawy odmiejscowionej z podaniem w szczególności sygnatury akt sprawy, terminu posiedzenia, oraz wskazaniem sądu do dokonania czynności procesowych

b. przesłanie wniosku do Systemu RCSc. przesłanie powiadomienia dla użytkownika, czy złożony wniosek

o rozprawę odmiejscowioną został uwzględniony pozytywnie w wiadomości e-mail lub umieszczenie informacji w module powiadomień PI– w zależności od ustawionych preferencji w systemie,

d. Wykonawca zapewni także logowanie zdarzeń systemowych do bazy danych logów za pomocą istniejącego systemu kolejkowania zdarzeń i bazy logów – mongoDB.

2. streaming posiedzenia on – line

Funkcjonalność polegająca na umożliwieniu stronom postępowania (na wniosek) strumieniowania przebiegu posiedzeń jawnych poprzez infrastrukturę wideokonferencyjną bez potrzeby stawienia się w sądzie

a. możliwość wypełnienia wniosku o strumieniowanie posiedzenia jawnego z podaniem niezbędnych danych: daty posiedzenia, terminu, sygnatury akt sprawy, sądu;

b. Wykonawca powinien zapewnić mechanizm wypełniania wniosków dostępnymi danymi na podstawie kontekstu pracy użytkownika

c. przesłanie wniosku do systemu RCSd. akceptacja/odrzucenie wniosku w Systemie RCS -przesłanie do użytkownika na PI

niezbędnych danych do ustawienia wideokonferencji/podanie przyczyn odrzuceniae. musi być możliwość dla użytkownika, po akceptacji wniosku przez sąd,

strumieniowania danych przez system wideokonferencji za pośrednictwem Internetu – link do strumienia

f. przesłanie linku do strumienia lub informacji o odrzuceniu wniosku w wiadomości e-mail lub umieszczenie informacji w module powiadomień PI – w zależności od ustawionych preferencji użytkownika,

g. Wykonawca zapewni logowanie zdarzeń systemowych do bazy danych logów za pomocą istniejącego systemu kolejkowania zdarzeń i bazy logów – mongoDB.


48


Na rysunku poniżej zaprezentowano niezbędne interfejsy do realizacji e-usługi przeprowadzenia rozprawy odmiejscowionej:

[Obsługa wniosków do rozprawy odmiejscowionej]1. PI->RCS: przesłanie wniosku o rozprawę zdalną -odmiejscowioną (wniosek,

ewentualnie podpis elektroniczny wniosku) – zwracana wartość: nr wniosku2. RCS->PI: powiadomienie o decyzji (nr wniosku, informacja o decyzji,

uzasadnienie) (w tym możliwa jest w uzasadnieniu informacja o zmianie terminu rozprawy)- zwracana wartość: potwierdzenie dostarczenia

[Streaming posiedzenia on-line ]1. PI->RCS: Przesłanie wniosku o udostępnienie strumieniowania posiedzenia

(sąd, sygnatura akt sprawy, data posiedzenia, dane osoby) - zwrot wartości: nr. wniosku

2. RCS->PI: przekazanie parametrów potrzebnych do ustawienia odbioru strumienia, nr wniosku-zwrot: potwierdzenie przyjęcia

Patrz również Załącznik nr 2 Opis interfejsów

3.4 Pozostałe wymagania wspierające realizację e-Usług

ePUAP

Wykonawca ma zapewnić następujące funkcjonalności w zakresie ePUAP:

1. musi być możliwość zatwierdzenia profilem zaufanym ePUAP „Wniosku o rejestrację” wypełnianego w celu założenia konta PI


49


2. musi być możliwość weryfikacji poprawności danych wprowadzonych w formularzu rejestracyjnym poprzez porównanie ich z danymi dostępnymi na profilu ePUAP

3. wykorzystanie zgromadzonych danych użytkownika ePUAP na potrzeby realizacji procesów biznesowych Portalu; obejmuje to w szczególności:

imię̨ użytkownika; nazwisko użytkownika; numer PESEL użytkownika identyfikator użytkownika; identyfikator profilu zaufanego ePUAP; czas jego potwierdzenia; termin ważności; określenie sposobu autoryzacji; adres poczty elektronicznej; numer telefonu komórkowego użytkownika;

4. możliwość logowania i autoryzacji użytkowników do Portalu Informacyjnego Sądów Powszechnych przy użyciu profilu zaufanego ePUAP poprzez mechanizmy współdzielenia tożsamości; autoryzacja w portalu ePUAP jest jednorazowa na jedną sesję, co oznacza eliminację wielokrotnych logowań do ePUAP w przypadku podpisywania dokumentów profilem zaufanym

5. ekran logowania będzie pozwalał użytkownikowi na wybór sposobu autoryzacji (dotychczasowy sposób logowania się lub autoryzacja ePUAP)

6. po zalogowaniu za pośrednictwem ePUAP użytkownik ma mieć możliwość wyboru kontekstu portalu oraz kontekstu użytkownika, w szczególności może pracować na koncie indywidualnym lub instytucjonalnym

7. możliwość składania przez użytkowników wniosków oferowanych przez portal e-usług i wniosku o rejestrację podpisanych profilem zaufanym ePUAP, wymagana weryfikacja poprawności składanego podpisu. Wykonawca zapewni mechanizm konfigurowania w Panelu Administracyjnym pozwalający określić administratorom, czy dla danego rodzaju wniosku wymagany jest podpis profilem zaufanym lub podpisem kwalifikowanym.

8. musi być zapewniona weryfikacja ważności podpisów elektronicznych przy wykorzystaniu usługi udostępnianej przez ePUAP, przy czym obowiązuje stan faktyczny usług sieciowych udostępnianych przez platformę ePUAP

Aplikacja mobilna

Wykonawca ma zapewnić następujące wymagania w zakresie aplikacji mobilnej:


50


1. Aplikacja mobilna musi wyświetlać informacje o sprawach przesyłane z Portalu Informacyjnego za pomocą API zalogowanym i uprawnionym użytkownikom systemu PI.

2. Wykonawca przygotuje aplikację mobilną oraz API udostępniające pełną funkcjonalność portalu PI w modelu REST.

3. Aplikacja mobilna musi działać prawidłowo na platformie iOS w wersji co najmniej 7.0 i wyższej, Android 4.4 i wyższej, Windows Mobile 8 i wyższej

4. Aplikacja mobilna musi być zaprojektowana z myślą o ekranach dotykowych5. Aplikacja musi być wykonana natywnie na poszczególne systemy, odpowiednio

wykorzystując natywne interfejsy dla systemu Android, iOS, Windows Mobile lub alternatywnie dopuszcza się wykonanie aplikacji w technologii hybrydowej, która umożliwi wytworzenie i utrzymywanie jednego kodu, który będzie mógł zostać skompilowany na różne platformy.

6. Aplikacja musi składać się z zakładek: Start, Sprawy, Posiedzenia, Czynności, Wnioski, Kalendarz, Profil użytkownika, Wsparcie, Informacja o oprogramowaniu. Użytkownicy powinni mieć możliwość wyłączenia wyświetlania zakładek, które nie są przez nich używane.

7. Aplikacja musi mieć funkcję informowania o nowych zdarzeniach poprzez notyfikacje „push”

8. Aplikacja musi mieć możliwość dodania wydarzenia do zewnętrznego kalendarza w telefonie np. terminu posiedzenia w sprawie

9. Wymagania odnośnie projekt projektu graficznego aplikacji zostały szczegółowo opisane w Rozdziale VI.2

10. Komunikacja aplikacji mobilnej z bazą danych będzie realizowana przy użyciu warstwy pośredniej tak, aby aplikacja nie miała bezpośredniego dostępu do bazy danych.

11. Komunikacja aplikacji mobilnej musi być szyfrowana.12. System nawigacji aplikacji mobilnej powinien być zgodny z zasadami web usability.

Użytkownik powinien mieć zapewniony łatwy dostęp do treści a system komunikacji ma być zrozumiały i przejrzysty. Jednocześnie hierarchia informacji nie powinna być zbyt głęboka.

13. Autorskie prawa majątkowe do aplikacji mają zostać przeniesione na Skarb Państwa Sąd Apelacyjny we Wrocławiu. Wykonawca obsługuje zgłoszenia użytkowników aplikacji mobilnej, np. uwagi, propozycje, błędy.

14. Aplikacja powinna być wyposażona w system podpowiedzi, a wszelkie komunikaty o błędach powinny zawierać propozycję rozwiązania problemu.


51


15. Aplikacja musi działać poprawnie dla natywnych rozdzielczości iOS, Android, Windows Mobile: 240x320px, 320x480px, 480x654px, 549x960px, 720x1280px, 1080x1920px. Pozostałe rozdzielczości powinny być obsługiwane przez skalowanie

16. Linki do aplikacji muszą zostać opublikowane na Portalu i pozwalać na pobranie aplikacji z Appstore, Google Play i sklepu Windows Phone.

17. Aplikacja musi być opublikowana w Appstore, Google Play oraz sklepie Windows Phone przez okres 3 lat od dnia podpisania protokołu końcowego. Koszty związane z publikacją ponosi Wykonawca. Aktualizacje oprogramowania umieszcza na tych platformach Wykonawca.

18. W trakcie analizy zostanie określone, które z modułów będą ̨ pracowały w trybie online/offline oraz reguły dotyczące aktualizacji danych

3.5 Zakres modyfikacji poszczególnych komponentów systemu Następujące komponenty Systemu ulegną modyfikacji:

● Aplikacja webowa Portal Informacyjny;● Aplikacja webowa Panel Administracyjny;● Moduł zasilania i aktualizacji danych z systemów repertoryjno-biurowych;● Moduł importu nagrań elektronicznego protokołu oraz ich udostępniania na potrzeby

odtwarzania.Zamawiający dopuszcza w ramach realizowanej powyższych modyfikacji komponentów Systemu całościową przebudowę komponentów Systemu, jeżeli takie rozwiązanie zostanie uznane przez Wykonawcę za korzystniejsze (np. kosztowo, technologicznie itp.) dla Zamawiającego, niż dokonywanie zmian w dotychczasowym kodzie Systemu.

Dodatkowo powstaną w ramach Zamówienia komponenty:● Aplikacja mobilna;● Moduł obsługi wniosków; ● Moduł powiadomień;● API.

Wykonawca zapewni również budowę wszystkich niezbędnych interfejsów dostarczanych oraz obsługę interfejsów wymaganych. Opis interfejsów zawiera również Załącznik nr 2 Opis interfejsów. Modele interfejsów mogą zostać doprecyzowane w porozumieniu z Zamawiającym w zakresie szczegółowych zasad realizacji na etapie prac projektowych. Na poniższym rysunku przedstawiono ogólny ich zarys:


52


W ramach zmiany komponentu aplikacja webowa Portal Informacyjny Wykonawca zapewni przebudowę całego komponentu. Szczegółowe wymagania odnośnie Projektu graficznego i Projektu technicznego zostały opisane w Rozdziale Projekt techniczny i projekt graficzny, natomiast wszystkie niezbędne wymagania w tym zakresie obejmuje Rozdział VI.3 W szczególności wszystkie strony zostaną dostosowane do wyświetlania przez osoby niedowidzące zgodnie z wymaganiami opisanymi w Rozdziale VI.3.6 Wymagania niefunkcjonalne.

Wykonawca zapewni zmiany zakładki Posiedzenia. Za pomocą Listy posiedzeń w sprawie będzie możliwość składania:

1. wniosku o udostępnienie pliku audio-wideo dla e-protokołu, 2. wniosku rezerwację miejsca w czytelni3. wniosku o automatyczną transkrypcję4. wniosku o streaming posiedzenia on-line

Dodatkowo wszystkie wnioski znajdą się w Zakładce Wnioski. Tam będzie również możliwość wysłania zapytania o stan realizacji wniosku.


53


Zbudowana zostanie webowa wersja odtwarzacza zarówno do odtwarzania audio jak i wideo, w połączeniu z obsługą adnotacji i wyświetlaniu treści z transkrypcji. Szczegóły w tym zakresie zostaną doprecyzowane na etapie projektu technicznego.

Wykonawca zapewni możliwość potwierdzania danych w formularzu rejestracyjnym za pomocą podpisu profilem zaufanym ePUAP.

W celu poprawy bezpieczeństwa Wykonawca dokona modyfikacji procedury odzyskiwania hasła użytkownika portalu. Poza przesyłanym w e-mailu linkiem zawierającym token Wykonawca zapewni możliwość wysyłania SMS, z zastrzeżeniem, że w profilu został podany numer telefonu komórkowego. Zabezpieczenie procedury będzie dwuskładnikowe – typu „coś co masz” (token) i „coś co znasz” (informacja znana tylko zainteresowanej osobie). Użytkownik musi podać numer telefonu, jeżeli jest zgodny z tym zapisanym w profilu, to wysłany zostanie SMS. W przeciwnym wypadku wyświetlony zostanie komunikat i propozycja skorzystanie z metody e-mail. Bramkę SMS udostępni Sąd Apelacyjny we Wrocławiu, interfejs został opisany w Załączniku nr 2 Opis interfejsów.

System zapewni użytkownikom powiadomienia: mailowe, SMS-owe lub umieszczone w module powiadomień użytkownika na stronie Portalu Informacyjnego. W profilu użytkownika zapewniona będzie możliwość personalizacji powiadomień przez użytkownika m.in. w zakresie dotyczącym powiadomień o wybranych sprawach sądowych i czynnościach, wnioskach i innych zdarzeniach, w tym systemowych.

Wykonawca rozbuduje kalendarz, w szczególności będzie możliwość w Systemie zarządzania kalendarzem przez użytkownika np. dodawania do niego własnych wpisów.

W celu ułatwienia zrozumienia pojawiających się w Portalu terminów prawniczych zostanie umieszczony przez Wykonawcę na stronie słownik zawierający ich syntetyczne wyjaśnienie. Wykonawca zapewni dla użytkowników możliwość sortowania wyświetlanych danych wraz z zapamiętaniem ostatnio wybranej opcji oraz drukowania dokumentów jak również treści z Portalu Informacyjnego.

W celu usprawnienia obsługi Wykonawca zapewni pogląd, edytowanie i wyszukiwania danych na kontach zależnych oraz przebudowany zostanie mechanizm składania wniosków przez subkonta. Wniosek powinien być złożony w imieniu użytkownika konta głównego z powiadomieniem użytkownika konta głównego i użytkownika subkonta (wnioskodawcy).

W ramach komponentu aplikacja webowa - Panel Administracyjny ulegną zmianie w szczególności elementy zmienione w ramach komponentu Aplikacja webowa Portal Informacyjny. Panel Administracyjny powinien zawierać wszystkie składowe, które są dostępne dla użytkownika zewnętrznego, z wyjątkiem składania wniosków. Dodatkowo Panel Administracyjny zostanie wzbogacony o obsługę wniosków użytkowników wysyłanych w ramach e-usług.


54


Dla użytkowników wewnętrznych (pracowników sądów) Wykonawca zapewni możliwość uwierzytelniania poprzez integrację Systemu z usługą katalogową sądów powszechnych (domena ad.ms.gov.pl), przez co zostanie zrealizowana w praktyce zasada pojedynczego logowania Single Sign On. Użytkownicy wewnętrzni Systemu posługują się tym samym kontem użytkownika (zarejestrowanym w usłudze katalogowej), które jest używane do logowania się̨ do systemu operacyjnego. System umożliwiać ma automatyczne zalogowanie na użytkownika zalogowanego do domeny ad.ms.gov.pl na komputerze.

Poniżej znajdują się szczegółowe wymagania odnośnie funkcjonalności Modułu obsługi wniosków.

Moduł obsługi wniosków

Wykonawca ma zapewnić następujące funkcjonalności:

1. Przygotowanie formularzy wniosków dla e-usług uwzględnienie redukcji powtarzalności operacji, w szczególności użytkownik

ma możliwość wypełnienia formularza już z częściowo wprowadzonymi danymi

walidacja danych formularza na podstawie wzoru przypisanego do wybranej przez użytkownika usługi, informowanie użytkownika o ewentualnych błędach popełnionych w trakcie wypełniania formularza

zarządzanie wnioskami2. Obsługa wniosków w panelu administracyjnym, powiadomienia dla pracowników

sądów właściwych wydziałów o stanie realizacji wniosków oraz możliwość sprawdzenia dla złożonego wniosku: czy został rozpatrzony ile czasu zostało do jego rozparzenia jeśli rozpatrzono negatywnie to informacja z jakiego powodu w przypadku wniosków o dostęp do dokumentacji wskazanie miejsca

w Systemie (zakładki), gdzie można odnaleźć wnioskowane dokumenty podanie przyczyn odrzucenia wniosku uwagi do wniosków powiadomienia

Na potrzeby obsługi wniosków przewidziano interfejs do Systemu RCS:


55


[Ustalanie statusu obsługi wniosków]1. PI->RCS: podaj status wniosku (nr wniosku) – zwrot wartości: status wniosku (do

wykorzystania w publikowaniu na PI informacji o statusach wniosków w module obsługi wniosków

W zakresie modułu importu nagrań elektronicznego protokołu oraz ich udostępniania na potrzeby streamingu ulegnie zmianie mechanizm pozyskiwania i przesyłania kompletu plików związanych z e-protokołem. Wykonawca ma zapewnić przesyłanie plików analogicznie do scenariusza opisanego dla pozyskiwania pliku audio-wideo obejmującego w szczególności sprawdzenie ścieżki dostępu w Systemie CRCS i pobrania plików z Systemu CAPE za pomocą podanej ścieżki. Poniżej interfejsy między wymienionymi systemami służące do realizacji tej funkcjonalności:


56


[Pobranie kompletu plików związanych z e-protokołem]1. PI->CRCS: pobranie kompletnych plików e-protokołu: audio, protokołu

skróconego, pliku adnotacji, pliku metadanych, pliku transkrypcji (sąd, wydział, sygnatura akt sprawy, data posiedzenia, dane osoby wnioskującej) – zwrot wartości: ścieżka do wnioskowanych plików lub informacja o błędzie/braku możliwości udostępnienia (po stronie CRCS musi być stosowny proces weryfikacji poprawności danych we wniosku)

2. PI->CAPE: pobranie plików według wskazanej ścieżki (ścieżka) – zwrot: pliki;


57


3.6 Wymagania niefunkcjonalne[Wymagania w zakresie bezpieczeństwa]Wdrożone rozwiązanie musi zapewnić co najmniej:

1. kontrolę dostępu do systemu wyłącznie po jednoznacznym zidentyfikowaniu przeprowadzonym w ramach procesu uwierzytelnienia,

2. przechowywanie i przesyłanie haseł użytkowników wyłącznie w postaci zabezpieczonej,

3. kontrolę uprawnień opartą na rolach, umożliwiającą kontrolę poziomu dostępu każdego użytkownika zarówno w zakresie dostępu do danych przetwarzanych jak i korzystania z jego funkcjonalności. System uprawnień musi umożliwić ograniczenie dostępu wyłącznie do takich danych oraz takiego zakresu funkcji, jaki jest niezbędny użytkownikowi,

4. uwierzytelnianie i autoryzację użytkowników wewnętrznych na podstawie informacji przechowywanej w Active Directory oraz zaimplementowanie mechanizmu SSO (single sign on),

5. uwierzytelnianie użytkowników za pomocą unikatowego identyfikatora użytkownika i niejawnego hasła,

6. dostęp do logów zdarzeń systemowych z poziomu interfejsu administracyjnego oraz zapewniać możliwość ich eksportu do formatu TXT,

7. rozliczalność działań użytkowników i administratorów,8. zapewnienie wiarygodności i bezpieczeństwa logów,9. odnotowanie daty wykonania każdej operacji oraz identyfikatora użytkownika

wykonującego operację,10. uniemożliwienie edycji i usuwania plików zawierających logi zdarzeń

systemowych oraz mechanizmy chroniące przed możliwością ich przepełnienia,11. synchronizację zegara systemowego ze źródłami czasu za pomocą protokołu NTP

lub mechanizmów Active Directory,12. korzystanie z protokołu SSL dla zabezpieczenia przesyłanych informacji, 13. zdefiniowanie reguł określających wymaganą siłę stosowanych haseł dla różnych

grup użytkowników w szczególności:a. minimalnej dopuszczalnej długości hasła,b. stosowania znaków alfanumerycznych i specjalnych,c. maksymalnej długość okresu ważności hasła,d. liczby haseł zapamiętywanych w historii haseł (blokowanie możliwości ich

ponownego użycia),e. system musi obsługiwać hasła jednorazowe.

14. monitorowanie prób naruszenia bezpieczeństwa systemu, w tym prób nieuprawnionego dostępu do systemu (tj. próby nieudane, ostrzeżenia systemowe i błędy),


58


15. monitorowanie operacji uprzywilejowanych, tj. wykorzystanie uprawnień administratora,

16. generowanie okresowych (z możliwością dowolnego definiowania okresów) i na żądanie, raportów o wykonanych operacjach i parametrach pojemnościowych i trendach obciążeniowych.

17. usunięcie podatności na ataki XSS poprzez właściwą filtrację wartości parametru sessionID.

18. zaimplementowanie w aplikacji zabezpieczenia przed Cross Site Request Forgery za pomocą tokenów anti-CSRF

19. dodanie atrybutu http-only dla przesyłanych cookies sesyjnych.20. wyłączenie obsługa sesji w żądaniach przez dołączanie parametru GET w URL21. Portal musi być odpowiednio zabezpieczony przed atakami na systemy

informatyczne. Wykonawca zadba o dokładną walidację danych pobieranych przez system z formularzy, danych URL, zabezpieczając system w szczególności przed zagrożeniami ujętymi w zestawieniach OWASP

[Wymagane zgodności z normami] Prace realizowane przez Wykonawcę w projekcie powinny być zgodne z poniższymi

normami projektowania zorientowanego na użytkownika: ISO 9241-210:2010 „Ergonomics of human-system interaction - Part 210: Human-centred design for interactive systems”, ISO/TR 16982:2002 „Ergonomics of human-system interaction - Usability methods supporting human-centered design”, ISO TR 18529:2000 „Human- centered lifecycle process descriptions”, PN-EN ISO 9241-210:2011 „ Ergonomia interakcji człowieka i systemu - Część 210: Projektowanie ukierunkowane na człowieka w przypadku systemów interaktywnych”. W normach tych zdefiniowano projektowanie zorientowane na człowieka (User Centred Design - UCD) jako działanie wielodyscyplinarne z uwzględnieniem wiedzy ergonomicznej. Projektowanie takie powinno być stosowane podczas cyklu życia interaktywnego systemu człowiek–komputer. Zbiór działań UCD obejmuje zaplanowanie procesu, określenie kontekstu użycia, określenie wymagań użytkownika i organizacji, wytworzenie rozwiązań projektowych i ich ocenę w odniesieniu do wymagań użytkownika. Oznacza to m.in., że podczas prac projektowych, a szczególnie w zakresie projektowania warstwy prezentacji, Wykonawca będzie kierował się poniższymi zasadami użyteczności/ergonomii:

o łatwość nawigacji,o zapewnienie poczucia sterowania interakcją przez użytkownika,o spójność – zgodność we wszystkich aspektach interakcji, tzn. w interfejsie

i w sposobie zapewnienia funkcjonalności,o elastyczność – zdolność przystosowania się do zmieniających się zadań i sytuacji,


59


o naturalność odwzorowania – zapewnienie czytelnego związku pomiędzy tym, czego oczekuje użytkownik, a mechanizmem wykonawczym,

o komunikatywność - jasność i zrozumiałość w procesie komunikacji z użytkownikiem,

o informowanie użytkownika o stanie systemu,o zarządzanie błędem – zapewnienie zarządzania błędami przez korektę lub

zapobieganie. Proces zarządzania usługami sieciowymi obejmujący projektowanie, wdrażanie,

eksploatowanie, monitorowanie, przeglądanie, utrzymanie i udoskonalanie zarządzania odbywał się będzie z uwzględnieniem Polskich Norm: PN-ISO/IEC 20000-1:2011 (Technika informatyczna - Zarządzanie usługami - Część 1: Specyfikacja) i PN-ISO/IEC 20000-2:2012 (Technika informatyczna - Zarządzanie usługami - Część 2: Reguły postępowania).

Kodowanie znaków realizowane będzie według standardu Unicode UTF-8 określonego przez normę ISO/IEC 10646.

W zakresie bezpieczeństwa danych w systemach teleinformatycznych oraz w mechanizmach o których mowa powyżej będą obowiązywać klasyfikacje informacji oraz zasady postępowania z informacjami zgodnie ze standardem PN-ISO/IEC 27001:2014-12. Każda grupa (klasa) informacji będzie mieć przyporządkowane wymaganie z zakresu bezpiecznego przetwarzania danych, z uwzględnienie, stopnia wrażliwości z wykorzystaniem odpowiednich wymagań ustawodawczych tj. ustawie o ochronie danych osobowych, ustawie o ochronie informacjach niejawnych oraz wymagań wewnętrznych Beneficjenta.

[Wymagania prawne]

Dostarczony, wdrożony i uruchomiony produkcyjnie przez Wykonawcę system musi w sposób ciągły spełniać wymagania obowiązujących przepisów prawa w zakresie rzeczowym i informacyjnym w poszczególnych obszarach funkcjonalnych/zadaniowych działania systemu w organizacji Zamawiającego. W szczególności powyższe dotyczy przepisów prawa wymienionych w Załączniku nr 1.

[Ogólne wymagania względem kodów źródłowych]

1. Wykonawca opracuje i przedłoży w ramach „Projektu technicznego” do akceptacji Zamawiającego opis konwencji zapisu kodu źródłowego, obejmujący co najmniej: schemat nazewnictwa plików kodu źródłowego, schemat organizacji plików kodu źródłowego, konwencje nazewnicze, konwencję formatowania wyrażeń języka, konwencje deklarowania klas i interfejsów,


60


konwencje dokumentowania kodu.Patrz również wymagania Rozdział VI.2 Projekt Techniczny i Projekt Graficzny

2. Konwencja zapisu kodu źródłowego musi zostać przygotowana dla każdego języka programowania wykorzystywanego przez Wykonawcę w ramach realizacji Umowy.

3. Wykonawca jest zobowiązany do wykonania usługi bazując na kodach źródłowych systemu PI. Wykonawca ponosi pełną odpowiedzialność za poprawne funkcjonowanie systemu PI wraz z zaimplementowanym w ramach usługi wytworem. Odstępstwa od tej reguły są dopuszczalne w celu zapewnienia poprawnej realizacji Umowy oraz gdy są podyktowane względami ekonomicznymi, za zgodą Zamawiającego.

4. Przekazywany Zamawiającemu w postaci elektronicznej kod źródłowy winien być zgodny z przyjętą konwencją zapisu kodu źródłowego.

5. Wraz z przekazywanym kodem źródłowym Wykonawca przekaże zestawienie użytych parametrów konfiguracyjnych środowiska wytwarzania i budowy kodu (środowisko asemblacji) oraz instrukcję umożliwiającą jego przygotowanie i poprawne przeprowadzenie asemblacji.

6. Stopień skomentowania kodu musi być wystarczający do zrozumienia jego logiki przez osobę o podstawowych umiejętnościach programistycznych w danym języku programowania.

Wykonawca jest zobowiązany do stosowania dobrych praktyk i standardów wytwarzania

[Wymagania pozostałe]Wykonawca ma zapewnić realizację następujących wymagań:

1. System musi być otwarty, zapewniać udokumentowane API pozwalające na integrację programistyczną systemu z dowolnymi innymi systemami Zamawiającego, posiadanymi obecnie i w przyszłości.

2. Portal musi być zmodyfikowany z wykorzystaniem technologii i narzędzi zapewniających: stabilność, wydajność, skalowalność oraz bezpieczeństwo. Zamawiający wymaga wykorzystania technologii: znanych, dojrzałych, sprawdzonych, udokumentowanych oraz powszechnie wykorzystywanych do budowy aplikacji internetowych.

3. Portal zapewni prawidłowe wyświetlanie i funkcjonowanie stron portalu w poniższych przeglądarkach internetowych dedykowanych dla urządzeń stacjonarnych w ich najnowszych wersji na dzień podpisania umowy oraz w ostatniej poprzedzającej obecną wersji przeglądarek internetowych: a. Internet Explorer (zgodność tylko z ostatnią wersją),b. Microsoft Edge (zgodność tylko z ostatnią wersją),c. Mozilla Firefox, Opera, Safari, Google Chrome (zgodność z ostatnimi i

przedostatnimi wersjami).


61


4. W przypadku korzystania ze starszej wersji przeglądarki internetowej użytkownikowi wyświetli się komunikat o sposobie poprawnego wyświetlania strony Serwisu oraz wersji przeglądarek internetowych, do których Serwis został zoptymalizowany.

5. Musi być możliwość odtwarzania plików wideo przy wykorzystaniu natywnego wsparcia przeglądarki tj. bez instalacji dodatkowych pluginów.

6. Portal musi być w pełni skonfigurowany, a więc przygotowany do realizacji wszystkich wymaganych funkcjonalności

7. Portal ma działać poprawnie nie tylko w najpopularniejszych przeglądarkach internetowych, ale również na urządzeniach mobilnych (model responsywny stron), w szczególności udostępnianie protokołu elektronicznego będzie możliwe wieloma kanałami komunikacji elektronicznej, w tym za pośrednictwem aplikacji mobilnych.

8. Dostosowanie portalu do używania przez osoby niedowidzące. Portal będzie zapewniał rozwiązania w zakresie dostępu przez osoby niedowidzące i niewidome zgodne z dokumentem "WCAG 2.0 podręcznik dobrych praktyk" dostępnym na stronie www.widzialni.org.

9. Dostosowanie Portalu do wymogów WCAG 2.0, poprzez: zastosowanie zasad dotyczących odpowiedniego rozmieszczenia elementów

strony w sposób umożliwiający korzystanie z niej wyłącznie przy wykorzystaniu klawiatury,

właściwe formatowania tekstu tj. justowania, podziału akapitów, wielkości i kontrastu czcionki, wyróżnieniu linków i słów kluczowych w tekście, wykorzystania nagłówków,

wykorzystanie elementów graficznych tj. rysunków i wykresów do wyjaśnienia trudnych zagadnień oraz zastosowania opisów alternatywnych dla każdej grafiki,

zamieszczenie opisów pól formularzy i wyszukiwarek.Szczegółowy zakres wymagań w zakresie dostosowania portalu do wymogów WCAG przedstawia poniższa tabela. W ostatniej kolumnie „Uwagi do obecnej wersji” zwrócono uwagę na te elementy, które obecnie nie spełniają danej wytycznej i powinny być zmienione w nowej wersji:

Lp. Zasada Wytyczne Pozycja w WCAG 2.0 PoziomUwagi do

obecnej wersji


62

http://www.widzialni.org/


1.

Zasada 1 – Postrzeganie

Wytyczna 1.1 Alternatywa w postaci tekstu: Dla każdej treści nietekstowej należy dostarczyć alternatywną treść w formie tekstu, która może być zamieniona przez użytkownika w inne formy (np. powiększony druk, brajl, mowa syntetyczna, symbole lub język uproszczony)

1.1.1 Treść nietekstowa: Wszelkie treści nietekstowe przedstawione użytkownikowi posiadają swoją tekstową alternatywę, która pełni tę samą funkcję

A

Obecnie istnieją elementy nietekstowe umieszczone na stronie internetowej niewyposażone w tekst alternatywny (np. ikona rozwijania/zwijania teksty w zakładce "Szczegóły" danej sprawy

2.

Wytyczna 1.2 Media zmienne w czasie: Należy dostarczyć alternatywę dla mediów zmiennych w czasie.

1.2.1 Tylko audio lub tylko wideo (nagranie): Dla mediów nagranych w systemie tylko audio lub tylko wideo stosuje się następujące zasady, za wyjątkiem sytuacji, kiedy nagranie audio lub wideo jest alternatywą dla tekstu i w taki sposób jest oznaczone: (Poziom A)

A3.

1.2.2 Napisy rozszerzone (nagranie): Napisy rozszerzone dołączone są do wszystkich nagrań audio w multimediach zsynchronizowanych (dźwięk i obraz), za wyjątkiem sytuacji, kiedy są one alternatywami dla tekstu i w taki sposób są oznaczone. (Poziom A)

4.

1.2.3 Audiodeskrypcja lub alternatywa dla mediów (nagranie): Zapewnia się alternatywę dla mediów zmiennych w czasie lub audiodeskrypcję dla nagrań wideo w multimediach zsynchronizowanych (dźwięk i obraz), za wyjątkiem sytuacji, kiedy są one alternatywami dla tekstu i w taki sposób są oznaczone. (Poziom A)

5.

Wytyczna 1.3 Możliwość adaptacji: Należy tworzyć treści, które mogą być prezentowane na różne sposoby (np. uproszczony układ wizualny), bez utraty informacji czy struktury.

1.3.1 Informacje i relacje: Informacje, struktura oraz relacje pomiędzy treściami przedstawiane w treści mogą być odczytane przez program komputerowy lub są dostępne w postaci tekstu. (Poziom A).

A6.

1.3.2 Zrozumiała kolejność: Jeśli kolejność, w jakiej przedstawiona jest treść, ma znaczenie dla zrozumienia treści — kolejność taka musi być możliwa do odczytania przez program komputerowy. (Poziom A)

7.

1.3.3 Właściwości zmysłowe: Instrukcje co do zrozumienia i operowania treścią nie opierają się wyłącznie na właściwościach zmysłowych, takich, jak kształt, rozmiar, wzrokowa lokalizacja, orientacja w przestrzeni lub dźwięk. (Poziom A)

8. Wytyczna 1.4 Możliwość rozróżnienia: Użytkownik powinien móc dobrze widzieć bądź słyszeć treści — mieć możliwość

1.4.1 Użycie koloru: Kolor nie jest wykorzystywany jako jedyny wizualny sposób przekazywania informacji, wskazywania czynności do wykonania lub oczekiwania na odpowiedź, czy też wyróżniania elementów wizualnych. (Poziom A)

A


63


oddzielenia informacji od tła.

9.

1.4.2 Kontrola odtwarzania dźwięku: Jeśli jakieś nagranie audio włącza się automatycznie na danej stronie i jest odtwarzane przez okres dłuższy niż 3 sekundy, dostępny jest albo mechanizm umożliwiający przerwanie lub wyłączenie nagrania, albo mechanizm kontrolujący poziom głośności niezależnie od poziomu głośności całego systemu. (Poziom A)

10.

1.4.3 Kontrast (minimalny): Wizualne przedstawienie tekstu, lub obrazu tekstu posiada kontrast wynoszący przynajmniej 4,5:1 (Poziom AA)

AA

Obecnie w niektórych miejscach na stronie kontrast między tłem, a tekstem jest zbyt mały (4,4:1).

11.

1.4.4 Zmiana rozmiaru tekstu: Oprócz napisów rozszerzonych oraz tekstu w postaci grafiki, rozmiar tekstu może zostać powiększony do 200% bez użycia technologii wspomagających oraz bez utraty treści lub funkcjonalności. (Poziom AA)

Zaleca się wprowadzić funkcjonalność stopniowego powiększania rozmiaru tekstu

12.

1.4.5 Obrazy tekstu: Jeśli wykorzystywane technologie mogą przedstawiać treść wizualnie, do przekazywania informacji wykorzystuje się tekst, a nie tekst w postaci grafiki,: (Poziom AA)

13.

Zasada 2 – Funkcjonalność

Wytyczna 2.1 Dostępność z klawiatury: Zapewnij dostępność wszystkich funkcjonalności za pomocą klawiatury.

2.1.1 Klawiatura: Cała treść oraz wszystkie zawarte w niej funkcjonalności dostępne są z interfejsu klawiatury, bez wymogu określonego czasu użycia poszczególnych klawiszy, poza tymi przypadkami, kiedy dana funkcja wymaga wprowadzenia informacji przez użytkownika w oparciu o ścieżkę ruchów, a nie w oparciu o punkty końcowe wejścia np. rysunek odręczny (Poziom A)

A Obecne strony nie spełniają tej wytycznej

14.2.1.2 Brak pułapki na klawiaturę: Jeśli fokus klawiatury można przemieścić do danego komponentu strony za pomocą interfejsu klawiatury, to może on być z niego usunięty również za pomocą interfejsu klawiatury, w przypadku gdy wymagane, a jeśli wówczas jest wymagane użycie czegoś więcej niż samych strzałek, tabulatora lub innych standardowych metod wyjścia, użytkownik musi otrzymać odpowiednią podpowiedź, w jaki sposób usunąć fokus z danego komponentu. (Poziom A)

Obecne strony nie spełniają tej wytycznej


64


15.

Wytyczna 2.2 Wystarczająca ilość czasu: Zapewnij użytkownikom wystarczająco dużo czasu na przeczytanie i skorzystanie z treści.

2.2.1 Możliwość dostosowania czasu: Dla każdego limitu czasowego, ustawionego na odbiór treści, spełnione jest przynajmniej jedno z poniższych założeń: (Poziom A)

Wyłączenie: Użytkownik może wyłączyć limit czasowy zanim czas upłynie; lub:

Dostosowanie: Użytkownik może swobodnie dostosować limit czasowy (przynajmniej o wartość 10 razy większą od wartości domyślnej) zanim czas upłynie; lub

Wydłużenie: Użytkownik jest ostrzegany przed upłynięciem limitu czasowego i ma przynajmniej 20 sekund na wydłużenie limitu za pomocą prostej czynności (np. „wciśnij klawisz spacji”) oraz może wydłużyć limit przynajmniej dziesięciokrotnie, lub:

Wyjątek dotyczący czasu rzeczywistego: Limit czasowy jest wymaganym komponentem jakiejś czynności w czasie rzeczywistym (np. aukcji) i nie ma możliwości zmiany limitu, lub:

Wyjątek dotyczący istoty czynności: Limit czasowy jest istotny i wydłużenie go anulowałoby lub zaburzałoby daną czynność, lub:

Wyjątek 20 godzin: Limit czasowy przekracza 20 godzin. A

16.

2.2.2 Wstrzymywanie (pauza), zatrzymywanie, ukrywanie: Wszystkie poniższe zasady obowiązują w przypadku informacji, która przesuwa się, porusza, migota lub automatycznie jest aktualizowana: (Poziom A)

Poruszanie się, przesuwanie, migotanie: Każdą informację, która porusza się, przesuwa lub mruga, a takie działanie (1) włącza się automatycznie, (2) jest widoczne dłużej niż 5 sekund, (3) jest przedstawiane równolegle z inną treścią — użytkownik może wstrzymać, zatrzymać lub ukryć za pomocą dostępnego mechanizmu, chyba, że poruszanie się, przesuwanie lub migotanie jest częścią czynności gdzie takie działanie jest istotne, oraz:

Automatyczna aktualizacja: Każdą automatycznie aktualizującą się informację, która (1) włącza się automatycznie oraz (2) jest przedstawiana równolegle z inną treścią — użytkownik może wstrzymać, zatrzymać lub kontrolować częstotliwość aktualizacji za pomocą dostępnego mechanizmu, chyba, że automatyczna aktualizacja jest częścią takiej czynności, gdzie takie działanie jest niezbędne

17. Wytyczna 2.3 Ataki padaczki: Nie należy projektować treści w taki sposób, aby prowokować ataki padaczki.

2.3.1 Trzy błyski lub wartości poniżej progu: Strony internetowe nie zawierają w swojej treści niczego, co migocze częściej niż trzy razy w ciągu jednej sekundy, lub też błysk nie przekracza wartości granicznych dla błysków ogólnych i czerwonych. (Poziom A)

A


65


18.

Wytyczna 2.4 Możliwość nawigacji: Dostarczenie narzędzi ułatwiających użytkownikowi nawigowanie, znajdowanie treści i ustalanie, gdzie się w danym momencie znajduje.

2.4.1 Możliwość pominięcia bloków: Dostępny jest mechanizm, który umożliwia pominięcie bloków treści powtarzanych na wielu stronach internetowych. (Poziom A)

AA

19.

2.4.2 Tytuły stron: Strony internetowe posiadają tytuły, które opisują ich cel lub przedstawiają ich temat. (Poziom A)

20.

2.4.3 Kolejność fokusu: Jeśli strona internetowa może być nawigowania sekwencyjnie, a kolejność nawigacji wpływa na zrozumienie lub funkcjonalność strony, komponenty przyjmujące fokus zachowują kolejność, dzięki której zachowany jest sens i funkcjonalność treści. (Poziom A)

21.

2.4.4 Cel linku (w kontekście): Cel każdego linku może wynikać z samej treści linku, lub też z treści linku powiązanej z programistycznie określonym kontekstem, poza tymi przypadkami, kiedy cel łącza i tak byłby niejasny dla użytkowników. (Poziom A)

22.

2.4.5 Wiele dróg: Istnieje więcej niż jedna droga umożliwiająca zlokalizowanie strony w danym serwisie internetowym, za wyjątkiem sytuacji, kiedy dana strona jest wynikiem jakiejś procedury lub jednym z jej etapów. (Poziom AA)

Należy dodać mapę serwisu w sekcji <footer>

23.

2.4.6 Nagłówki i etykiety: Nagłówki i etykiety opisują temat lub cel treści. (Poziom AA)

24.

2.4.7 Widoczny fokus: Każdy interfejs możliwy do nawigacji za pomocą klawiatury, posiada widoczny wskaźnik fokusa klawiatury. (Poziom AA)

25.

Zasada 3 – Zrozumiałość

Wytyczna 3.1 Możliwość odczytania: Treść powinna być zrozumiała i możliwa do odczytania.

3.1.1 Język strony: Domyślny język naturalny każdej strony internetowej może zostać odczytany przez program komputerowy. (Poziom A)

A

26.

3.1.2 Język części: Język naturalny każdej części lub frazy zawartej w treści może zostać odczytany przez program komputerowy, za wyjątkiem nazw własnych, wyrażeń technicznych, słów w nieokreślonym języku oraz słów i fraz, które stanowią część żargonu w bezpośrednio otaczającym je tekście. (Poziom AA)

AA

27.Wytyczna 3.2 Przewidywalność: Strony internetowe powinny otwierać się i działać w przewidywalny sposób.

3.2.1 Po oznaczeniu fokusem: Jeśli jakikolwiek komponent jest oznaczony fokusem, nie powoduje to zmiany kontekstu. (Poziom A)

A

28.

3.2.2 Podczas wprowadzania danych: Zmiana ustawień jakiegokolwiek komponentu interfejsu użytkownika nie powoduje automatycznej zmiany kontekstu, chyba, że użytkownik został poinformowany o takim działaniu zanim zaczął korzystać z komponentu. (Poziom A)

29.3.2.3 Konsekwentna nawigacja: Mechanizmy nawigacji, które powtarzają się na wielu stronach w serwisie internetowym, w danym porządku względnym wobec siebie, za każdym razem pojawiają się w tym samym porządku, chyba, że użytkownik sam wprowadzi zmiany.(Poziom AA)

AA


66


30.

3.2.4 Konsekwentna identyfikacja: Komponenty, które posiadają tę samą funkcjonalność w danym serwisie internetowym, są w taki sam sposób zidentyfikowane. (Poziom AA)

31.

Wytyczna 3.3 Pomoc przy wprowadzaniu informacji: Istnieje wsparcie dla użytkownika, by mógł uniknąć błędów lub je skorygować

3.3.1 Identyfikacja błędu: Jeśli przy wpisywaniu informacji, błąd zostanie wykryty automatycznie, system wskazuje błędny element, a użytkownik otrzymuje opis błędu w postaci tekstu. (Poziom A)

A

Wyszukiwarka Sprawy:

- W polach "Sędzia referent" oraz "Strona w sprawie" można wpisać cyfry

Wyszukiwarka Posiedzenia:

- W polu "Sędzia przewodniczący" i "Podmiot w sprawie" można wpisać cyfry

Wyszukiwarka Czynności:

- W polu "Wykonawca" można wpisać cyfry

Należy rozbudować walidację formularza.

32.

3.3.2 Etykiety lub instrukcje: Pojawiają się etykiety lub instrukcje, kiedy w treści wymagane jest wprowadzenie informacji przez użytkownika. (Poziom A)

33.

3.3.3 Sugestie korekty błędów: Jeśli przy wpisywaniu informacji, błąd zostanie wykryty automatycznie i znane są sugestie korekty, wtedy użytkownik otrzymuje takie sugestie, chyba, że stanowiłoby to zagrożenie dla bezpieczeństwa treści lub zmieniłoby to cel treści. (Poziom AA)

AA

34.

3.3.4 Zapobieganie błędom (kontekst prawny, finansowy, związany z podawaniem danych): Dla stron internetowych, na których pojawiają się zobowiązania prawne lub transakcje finansowe, i w których użytkownik modyfikuje lub usuwa dane zawarte w systemach przechowywania danych, lub wprowadza testowe odpowiedzi, zostały zapewnione mechanizmy pozwalające na przywrócenie poprzednich danych, weryfikacje lub potwierdzenie. (Poziom AA)

35.

Zasada

4

– K

ompatybilność

Wymaganie 4.1 Kompatybilność: Zmaksymalizowanie kompatybilności z obecnymi oraz przyszłymi programami użytkowników, w tym z technologiami

4.1.1 Parsowanie: W treści wprowadzonej przy użyciu języka znaczników, elementy posiadają pełne znaczniki początkowe i końcowe, elementy są zagnieżdżane według swoich specyfikacji, elementy nie posiadają zduplikowanych atrybutów oraz wszystkie ID są unikalne, za wyjątkiem przypadków, kiedy specyfikacja zezwala na wyżej wymienione cechy. (Poziom A)

A

Obecne strony nie spełniają tej wytycznej


67


wspomagającymi.36.

4.1.2 Nazwa, rola, wartość: Dla wszystkich komponentów interfejsu użytkownika (włączając w to, ale nie ograniczając jedynie do elementów formularzy, linków oraz komponentów wygenerowanych przez skrypty) nazwa oraz rola (przeznaczenie) mogą być odczytane przez program komputerowy, a stan, właściwości oraz wartości, które mogą być ustawione przez użytkownika, mogą również być ustawione przez program komputerowy; zawiadomienie o zmianach w tych elementach dostępne jest dla programów użytkownika, w tym technologii wspomagających. (Poziom A)

Obecnie dokumenty nie posiadają ikon informujących o ich formacie. Tytuły plików nie zawierają końcówek takich jak: .pdf, .doc dla łatwiejszej identyfikacji.

Znaczenie użytych w powyższej tabeli określeń i wartości – zawarte w opracowaniu dostępnym pod adresem: http://www.w3.org/TR/WCAG20/

a. Portal zapewnia alternatywne wersje wyświetlania interfejsu graficznego takie jak:- przynajmniej 4 rodzaje kontrastów interfejsu różnicujących wyświetlanie treści, możliwe do ustawienia przez użytkownika,- przynajmniej 3 rozmiary czcionki możliwe do ustawienia przez użytkownika

b. Załączniki umieszczane w Portalu Informacyjnym zawierające nagrania audio-wideo mają być opatrzone unikatową nazwą oraz informacją o rozmiarze plików podanym w kilobajtach.

c. Wszelkie elementy portalu będą pozbawione kontrolek i elementów wymagających technologii Flash.

d. Portal umożliwi komunikację z systemami zewnętrznymi poprzez usługi sieciowe e. W zakresie zgodności z KRI:

• Udostepnienie zasobów informacyjnych, którymi są protokoły skrócone z rozprawy sądowej w postaci sformatowanego tekstu w formacie .rtf.

• Do danych zawierających informację dźwiękową zastosowanie ma format .ogg (Ogg Vorbis Audio Format). Format ten jest stosowany do zawartości dźwiękowej treści protokołu elektronicznego.

• Do definiowania układu informacji polegającego na określeniu elementów informacyjnych oraz powiązań między nimi stosuje się format xml (Extensible Markup Language) - Standard uniwersalnego formatu tekstowego służący do zapisu danych w postaci elektronicznej.

• Zapewnienie odpowiedniego poziomu bezpieczeństwa systemu m.in. poprzez: dbałość o aktualizację oprogramowania, minimalizowanie ryzyka utraty informacji w wyniku awarii, poprzez

zastosowanie wykonywanie kopii zapasowych. ochronę przed błędami, utratą, nieuprawnioną modyfikacją, kontrolę zgodności systemów teleinformatycznych z odpowiednimi

normami i politykami bezpieczeństwa;


68

http://www.w3.org/TR/WCAG20/


• Zapewniona zostanie zgodność z określonymi w rozporządzeniu standardami do elektronicznego podpisywania i weryfikacji podpisu dokumentów elektronicznych poprzez zastosowanie oprogramowania do podpisu elektronicznego spełniającego zdefiniowane standardy.

• Zapewnienie bezpieczniej wymiany danych z innymi systemami teleinformatycznymi za pomocą ̨ protokołów komunikacyjnych i szyfrujących określonych w obowiązujących przepisach, normach, standardach lub rekomendacjach ustanowionych przez krajową jednostkę ̨ normalizacyjną lub jednostkę normalizacyjną Unii Europejskiej.


69


4. Dostawa, instalacja i konfiguracja środowiska sprzętowego i systemowego niezbędnego dla wdrożenia modyfikacji PI

W ramach prac projektowych Wykonawca zrealizuje wymianę obecnych systemów bazodanowych wykorzystywanych w PI na systemy bazodanowe działające w modelu in-memory computing. Głównym celem wymiany platformy bazodanowej wykorzystywanej przez PI jest zapewnienie wymaganej efektywności (w tym: skrócenia czasu ładowania danych do interfejsu użytkownika) i niezawodności działania oraz dostępności Portalu Informacyjnego dla użytkowników. System musi być dostosowany do oczekiwanego wzrostu ilości danych związanych ze świadczeniem nowo wdrażanych e-usług oraz zwiększonego poziomu zainteresowania portalem w kontekście wzbogacanych w nim treści i funkcjonalności.

Wykonawca dostarczy, zainstaluje i skonfiguruje dla obsługi wszystkich 11-tu instalacji PI kompletną platformę technologiczną obejmującą:

system bazodanowy in-memory computing, środowisko systemowe (stosownie do potrzeb oferowanego rozwiązania: systemy

operacyjne, oprogramowanie narzędziowe itd.) – kompletny zestaw oprogramowania wymagany dla efektywnego działania rozwiązania Wykonawcy w kontekście zdefiniowanych w OPZ wymagań,

infrastrukturę serwerową dla platformy bazodanowej.

[System bazodanowy in-memory computing]

Wymagane jest dostarczenie w ramach oferty wszystkich niezbędnych licencji platformy bazodanowej działającej w modelu in-memory computing, pozwalających na obsługę 11 instancji PI w modelu opisanym w wymaganiach poniżej, niezbędnych do realizacji następujących środowisk:

środowiska produkcyjnego: umożliwiającego przechowywanie w trybie in-memory co najmniej 448 GB danych, pracującego w poniższych trybach (modele opisane na rysunku na kolejnej stronie):

o active-active w obrębie podstawowego ośrodka przetwarzania danych,o active-passive o obrębie podstawowego i zapasowego ośrodka

przetwarzania danych. środowiska testowego: umożliwiającego przechowywanie w trybie in-memory co

najmniej 64GB danych, środowiska deweloperskiego: umożliwiającego przechowywanie w trybie

in-memory co najmniej 64GB danych.


70


Dostarczany system bazodanowy musi spełniać poniższe wymagania: musi być oprogramowaniem systemu bazodanowego typu in-memory computing, w

czasie pracy w całości rezydujący w pamięci operacyjnej serwera wraz z zestawem narzędzi do obsługi, modelowania danych,

musi pozwalać na wykonywanie w czasie rzeczywistym operacji na danych i analizę danych o dowolnej szczegółowości, stopniu agregacji i liczbie wymiarów,

musi posiadać zaimplementowane w systemie bazodanowym rozwiązania optymalizacyjne w zakresie: uzyskania dużej wydajności przetwarzania/ wyszukiwania/ kompresji danych (zaimplementowane algorytmy determinujące użycie właściwego algorytmu kompresji w zależności od kompresowanych danych), zarządzania danymi opartymi o zapis w układzie kolumnowym jako podstawowy sposób przechowywania informacji (obok możliwości zastosowania zapisu danych w układzie wierszowym), partycjonowania tablic, wykorzystania delty do operacji wstawiania nowych danych,

musi posiadać możliwość tworzenia baz danych w modelu Multitenant dysponującym tzw. kontenerem mogącym pomieścić wiele baz danych działających niezależnie, z możliwością zarządzania wieloma bazami danych jak jedną i przy zachowaniu odrębności poszczególnych baz danych,

musi posiadać zaimplementowane oprogramowanie narzędziowe do tworzenia, modyfikacji, projektowania, itp. systemów baz danych wraz z ich administrowaniem w tym budowania/ modyfikowania aplikacji/ projektu bazy, tabel, widoków, schematów, itp., testowania/ debugowania aplikacji (podgląd kodu źródłowego, monitorowanie/ zmiana wartości zmiennych, ustawianie punktów przerwania realizacji programu), budowania modeli analitycznych, synchronizacji lokalnych plików z repozytoriami, administrowania systemem bazodanowym lokalnie, itp.,

musi posiadać wbudowane narzędzia zarządzania bezpieczeństwem systemu poprzez system backupowania, replikacji danych z pamięci podręcznej do pamięci trwałej,

musi posiadać wbudowane narzędzia do administrowania i monitorowania systemem bazodanowym, w tym: monitorowania statusu baz danych w systemie, przeglądania ostatnio zgłoszonych komunikatów/ błędów itp., monitorowania aktywnych sesji, stopnia użycia zasobów sprzętowych: ilości pamięci wykorzystywanej przez system bazy danych w realizowanych procesach/ zapytaniach, itp., procentowy stopień wykorzystania CPU przez system, całkowitej ilość miejsca wykorzystanego w pamięci masowej/ dyskach przez system bazodanowy w tym przez zbiory bazodanowe, pliki logów, monitorowanie pracy systemu bazodanowego na jednym serwerze oraz w układzie rozproszonym na kilku serwerach, ilości zgłoszonych w systemie plików tzw. crush dump files, posiadać zaimplementowane podsystemy kontroli zbieżności realizowanych zapytań SQL, monitorowanie informacji o restartowaniu systemu, realizowanych procesach, posiadać wbudowane narzędzia do zarządzania użytkownikami, regułami dostępu do baz danych, modyfikacji danych/obiektów i korzystania z zasobów systemu, dozwolonych operacji/ zadań do realizacji przez użytkowników systemu, definiowania ról, wbudowane narzędzia zarządzania zainstalowanymi aplikacjami, aktualizacjami, itp.,


71


musi posiadać możliwość tworzenia puli rezerwowych połączeń z systemem bazodanowym dla administratorów systemu niezależnej od ilości połączeń zdefiniowanych dla pozostałych użytkowników systemu,

musi posiadać możliwość monitorowania i alarmowania o stanie baz danych na podstawie danych statystycznych serwera i uruchomionych serwisów,

musi posiadać możliwość zgłaszania komunikatów drogą mailową po wystąpieniu zdefiniowanych w konfiguracji zdarzeń, błędów w pracy systemu bazodanowego, itp.,

musi posiadać zaimplementowane narzędzia pozwalające na zbieranie i analizę danych mających wpływ na wydajność system bazodanowego, uruchomianych baz danych i zapytań SQL, problemów w systemie bazodanowym wyszukiwania błędów w pracy systemu bazy danych,

musi posiadać wbudowane narzędzia monitorowania uruchomionych wątków, sesji (aktywnych/nieaktywnych sesji, ich powiązania z uruchomionymi aplikacjami, blokowanych sesji, sesje blokujące, sesje zablokowane), zablokowanych transakcji (zablokowane transakcje oraz blokujące sesję, itp.), zbieranie danych statystycznych: częstości wykonania zapytań SQL (średniego czasu wykonania zapytań, ilości odwołań DML i DDL w sesji, itp.), stopień realizacji wykonania czasochłonnych zadań, itp.,

musi posiadać wbudowane narzędzia monitorowania i zbierania informacji o wystąpieniu czasochłonnych i kosztownych (zasobowo) zapytaniach ponad dopuszczalny poziom (czas uruchomienia zapytania, czas wykonania zapytania, nazwa udostępnionych obiektów itp.), z przeznaczeniem do późniejszej analizy i dostrajania zapytania, systemu, itp.,

musi posiadać wbudowane wskaźniki i narzędzia monitorowania użycia pamięci przez system bazodanowy, aplikacje uruchomione serwisy itp. tj. np.: bieżący stan użycia pamięci przez uruchomione bazy/ procesy, szczytowe zapotrzebowania ilości pamięci przez procesy/ uruchomione bazy, wycieki pamięci/ uszkodzenia pamięci, itp.,

musi posiadać wbudowane narzędzia pozwalające na odtwarzania systemu ze zbiorów zarchiwizowanych, zapisanej replikacji, replikowanych systemów,

musi posiadać wbudowane w system narzędzia umożliwiające podział (w poziomie) tabel z danymi przechowywanych w układzie kolumnowym na partycje, zarządzania partycjonowanymi tabelami, łączenia partycjonowanych tabel w większe tabele, przenoszenie partycji tabel do innych lokalizacji/serwera,

musi posiadać możliwość tworzenia bezpiecznych połączeń systemu bazodanowego z użytkownikami końcowymi za pomocą np.: protokołów SSL i certyfikatów,

musi posiadać wbudowaną funkcję watchdog umożliwiającą automatyczne zrestartowanie skonfigurowanej usługi (serwera indeksowego itp.) w przypadku wykrycia jego usterki/ zatrzymania,

musi posiadać wbudowane mechanizmy pozwalające na utrzymania ciągłości pracy systemu i spójności realizowanych transakcji, poprzez logi transakcji, zapisywane punkty przebiegu procesu z informacjami niezbędni do odtworzenie i przywrócenie systemu z minimalnym opóźnieniem bez utraty danych, poprzez dedykowany serwer pracujący


72


w trybie standby przejmujący zadania podstawowego systemu bazodanowego po wystąpieniu awarii zatrzymania systemu podstawowego (stosownie do zdefiniowanej konfiguracji systemu),

musi pozwalać na skalowalność zewnętrzną systemu poprzez dołączanie/ łączenie zewnętrznych serwerów, integrowanych w jeden system bazodanowy (np.: z różnymi tabelami na różnych serwerach, z partycjonowanymi tabelami, itp.).

[Środowisko systemowe]

Wykonawca dostarczy i wdroży wszystkie niezbędne elementy środowiska systemowego wymagane dla pracy oferowanego rozwiązania, dostosowane licencyjnie do modelu architektury rozwiązania opisanej w tym rozdziale, z uwzględnieniem licencji wymaganych dla środowiska: produkcyjnego, testowego i deweloperskiego, co w szczególności obejmuje:

dostawę, instalację i konfigurację niezbędnego oprogramowania systemowego, w tym niezbędnych systemów: operacyjnych, wirtualizacji, integracyjnych i narzędziowych, W razie potrzebny wykorzystania środowiska wirtualizacyjnego dla środowisk testowego i deweloperskiego Zamawiający zapewni w tym zakresie posiadane licencje systemu VMware VSphere 5 i/lub 6 – dostarczane rozwiązanie w obszarze środowisk nieprodukcyjnych powinno być z nimi zgodne. Alternatywnie dopuszczalne jest, że Wykonawca w ramach oferty dostarczy stosowne środowisko wirtualizacyjne zgodne z dostarczanym rozwiązaniem w powyższym zakresie.

dostawę, instalację i konfigurację wszelkiego innego oprogramowania (np. licencji dostępowych, oprogramowania klastrowego zapewaniającego automatyczne przełączanie na wypadek awarii, wsparcia replikacji, warstw pośrednich, systemów plikowych itp.), jakie są konieczne do prawidłowej pracy oferowanego przez Wykonawcę rozwiązania. Zakres dostawy, którego niniejszy punkt dotyczy, wynika wyłącznie ze specyfiki oferowanego przez Wykonawcę rozwiązania.

Należy przyjąć, że każde oprogramowanie jakie jest niezbędne dla realizacji wdrożenia zgodnie z wymaganiami zdefiniowanymi w OPZ, zobowiązany jest zapewnić Wykonawca w ramach złożonej oferty (chyba, że OPZ stanowi inaczej). Wszystkie dostarczone w ramach Zamówienia licencje muszę być bezterminowe.Wszystkie dostarczone oprogramowania będą zgodne z wymaganiami producenta platformy bazodanowej in-memory computing, a jeżeli przewidziana została ich certyfikacja przez producenta platformy bazodanowej, będą taką certyfikację posiadać.

[Infrastruktura serwerowa]

Rozwiązanie w zakresie platformy bazodanowej in-memory computing powinno działać w architekturze podziału na ośrodki przetwarzania zgodnie z zamieszczonym poniżej rysunkiem:


73


Architektura sprzętowa rozwiązania oparta jest na następujących wymaganiach: ośrodek podstawowy i zapasowy zlokalizowane są w obszarze administracyjnym

miasta Wrocławia środowisko produkcyjne oparte jest na trzech identycznych konfiguracyjnie

serwerach, w ośrodku podstawowym pracują dwa serwery w układzie klastra – przy czym na

każdym z nich pracują aktywne instancje (active) PI (rozkład 5-6) dla poszczególnych apelacji oraz na każdym z nich działają w trybie standby (passive) stosowne repliki instancji,

serwer w ośrodku zapasowym działa w trybie standby (passive) stanowiąc zabezpieczenie dla wszystkich instancji PI pracujących w ośrodku podstawowym,

serwer (czwarty, nie umieszczony na diagramie) dedykowany jest dla środowisk testowego i deweloperskiego, jest konfiguracyjnie identyczny z serwerami produkcyjnymi

Infrastruktura serwerowa dostarczana przez Wykonawcę powinna realizować efektywnie opisane powyżej wymagania w zakresie przetwarzania i składowania danych, w tym realizować opisaną powyżej architekturę sprzętową oraz spełniać listę szczegółowych wymagań minimalnych zdefiniowanych poniżej:

Konfiguracja serwerów – 4 szt.:

Cecha Charakterystyka

Obudowa Obudowa umożliwiająca montaż w szafie Rack o maksymalnej wysokości 8U.

Procesor Minimum 4 zainstalowane procesory 24 rdzeniowe o taktowaniu min. 2.2 Ghz wykonane w technologii 14 nm osiągające w testach „SPECint_rate_base2006” wynik


74


nie gorszy niż 3570. TDP nie większe niż 165W.

Serwer musi posiadać możliwość rozbudowy o 4 dodatkowe procesory.

Pamięć operacyjna 512 GB DDR4

Możliwość rozbudowy do 6 TB pamięci RAM bez konieczności wymiany już zainstalowanych modułów pamięci.

Dysk twardy Minimum:4 dyski SSD o pojemności min. 400GB

7 dysków SAS o pojemności min. 1.8TB 10K RPM

2 dyski SAS o pojemności min. 600GB 10K RPM

2 dyski NVMe SSD o pojemności min. 1.6 TB

Karty sieciowe Ethernet Min. 6 portów 10 Gbps SFP+Kontroler RAID Sprzętowy kontroler RAID 0, 1, 10, 5, 6 z pamięcią cache

1GB

Zarządzanie Oprogramowanie do zdalnego zarządzania serwera umożliwiające m.in.:- włączenie/wyłączenie/restart serwera- montowanie obrazów ISO- zarządzanie przez zdalną konsolę serwera

Zasilacz Minimum cztery zasilacze wymieniane podczas pracy urządzenia, zapewniające redundancję zasilania.

Chłodzenie Zestaw wentylatorów zapewniających redundantne chłodzenie serwera, z możliwością wymiany hot swap.

Wspierane systemy operacyjne Microsoft Windows Server, Red Hat Enterprise Linux, Suse Linux Enterprise Edition, Vmware vSphere oraz systemy dostarczane w ramach oferty.

Ponadto dostarczane konfiguracje serwerów muszą spełniać wymagania minimalne zdefiniowane przez producenta platformy bazodanowej in-memory computing, a jeżeli producent platformy bazodanowej realizuje certyfikację konfiguracji serwerowych w zakresie ich zgodności z wymaganiami platformy bazodanowej, będą taką certyfikację posiadać. W przypadku występowania wymogu certyfikacji wymagane jest dostarczenie przez Wykonawcę certyfikatu lub oświadczenia producenta o stosownej zgodności oferowanej konfiguracji. Dostarczona w ramach oferty konfiguracja sprzętowo-systemowa musi spełniać


75


łącznie wszystkie wymagania instalacyjne oferowanej platformy bazodanowej in-memory computing; musi umożliwiać wykonywania backupów na system dyskowy oraz taśmowy.Ponadto dostarczone serwery przeznaczone dla środowisk produkcyjnych muszą zapewniać możliwość uruchomienia innych nieprodukcyjnych środowisk systemu in-memory computing.

Zamawiający na potrzeby realizacji projektu postawi do dyspozycji Wykonawcy posiadaną przez siebie infrastrukturę IT. Zakres sprzętu i oprogramowania udostępnianego przez Zamawiającego na potrzeby wdrożenia opisano w Załącznik nr 5 Wykorzystana technologia w obecnie działającym Systemie. Należy przyjąć, że każde oprogramowanie i sprzęt jakie są niezbędne dla realizacji wdrożenia Systemu, a wykraczają poza listę oprogramowania i sprzętu udostępnianego przez Zamawiającego, zobowiązany jest zapewnić Wykonawca w ramach złożonej oferty.


76


5. Wdrożenie systemu w organizacji Zamawiającego[Lokalizacja wdrożenia]Dostawa i wdrożenie oprogramowania i sprzętu dedykowanego dla instalacji centralnej odbywać będzie się w Sądzie Apelacyjnym we Wrocławiu. Wdrożenie obejmuje 11 identycznych instalacji PI dedykowanych po jednej dla każdej apelacji, zainstalowanych na wspólnej platformie sprzętowo-systemowej we Wrocławiu.

[Prace wdrożeniowe]

Wdrożenie rozwiązania w organizacji Zamawiającego obejmuje w szczególności prace w zakresie:

Inicjalizacji projektu – wymagania opisane w Załączniku nr. 4 do OPZ Sekcja 1.2.1; Analizy biznesowej i systemowej – wymagania opisane w Rozdziale VI.1

Przeprowadzenie Analizy biznesowej i systemowej; Projekt Techniczny – wymagania opisane w Rozdziale VI.2 Projekt Techniczny

i Projekt Graficzny; Dostawa, instalacja i konfiguracja sprzętu i oprogramowania – opisane w sekcjach

poniżej; Migracja danych- opisane w sekcjach poniżej; Testy – opisane w sekcjach poniżej; Szkolenia – wymagania opisane w Rozdziale VI.6 Przeprowadzenie szkoleń; Dokumentacja – wymagania opisane w Rozdziale VI.7 Opracowanie dokumentacji; Uruchomienie systemu – opisane w sekcjach poniżej;

Szczegółowe wymagania dotyczące prowadzenia projektu oraz sposobu odbioru poszczególnych produktów projektu opisane zostały w Załączniku nr. 4 do OPZ.

[Harmonogram prac]

Projekt realizowany będzie zgodnie z harmonogramem prac przedstawionym w Załączniku Nr 2 Umowy Harmonogram etapów realizacji przedmiotu umowy.

[Dostawa, instalacja i konfiguracja sprzętu i oprogramowania]1. Dostarczany w ramach projektu przez Wykonawcę sprzęt i oprogramowanie spełniać

musi w szczególności wymagania opisane w Rozdziale VI.4 OPZ. 2. Wykonawca zobowiązany jest do dostarczenia kompletnego asortymentowo i

ilościowo oprogramowania i sprzętu posiadającego wszelkie wymagane instrukcje, certyfikaty, gwarancje i licencje.

3. Zakres udzielonych licencji musi zapewnić Zamawiającemu użytkowanie produkcyjne oferowanego rozwiązania zgodnie z wymaganiami opisanymi w OPZ, a wszystkie dostarczone w ramach Zamówienia licencje muszę być bezterminowe. Ponadto


77


Zamawiający nie dopuszcza możliwości ujęcia w ofercie oprogramowania (w tym bibliotek), którego wymagania licencyjne nakazujące publikację kodów źródłowych systemu, w którym takie oprogramowanie zostało wykorzystane.Zamawiający jednocześnie nie definiuje ograniczeń w zakresie zastosowanego przez Wykonawcę frameworku dla realizacji Zamówienia (w szczególności nie ogranicza go do rozwiązań stosowanych w obecnie eksploatowanej wersji Portalu Informacyjnego).

4. Wykonawca przeprowadzi w ramach projektu, na bazie zatwierdzonego przez Zamawiającego Projektu Technicznego, wszelkie niezbędne prace, w tym w szczególności prace: instalacyjne, konfiguracyjne, parametryzacyjne, dostosowawcze i programistyczne, w zakresie dostarczanego oprogramowania i sprzętu niezbędne dla zapewnienia Zamawiającemu rozwiązania spełniającego wszystkie wymagania opisane w OPZ. W realizowanych pracach Wykonawca uwzględni zalecenia producentów danego oprogramowania (z uwzględnieniem tzw. modyfikacji („łatek”) na podstawie publikowanej przez danego producenta listy aktualizacji lub listy aktualizacji wskazanej na stronie www.cert.pl).

5. Wykonawca w ramach realizowanych prac m.in. zmodyfikuje Portal Informacyjny w zakresie wymaganym dla jego prawidłowego i efektywnego działania w oparciu o dostarczany w ramach oferty system bazodanowy in-memory computing. W tym zrealizuje instalację i konfigurację replikacji danych i oprogramowania klastrowego.

6. W wyniku zrealizowanych przez Wykonawcę prac wdrożeniowych system musi być w pełni skonfigurowany tj. przygotowany do realizacji produkcyjnej wszystkich wskazanych w OPZ przez Zamawiającego funkcjonalności.

Oprogramowanie:

Zamawiający wymaga w szczególności dostawy przez Wykonawcę oprogramowania spełniającego wymagania:

1. Dostarczone rozwiązanie musi obejmować kompletne oprogramowanie niezbędne dla realizacji funkcji opisanych w OPZ.

2. Wykonawca dostarczy wersję instalacyjną każdego dostarczanego oprogramowania na nośnikach elektronicznych (CD/DVD lub USB).

3. Wszelkie kody źródłowe, które powstaną w toku realizacji niniejszego zamówienia zostaną przekazane przez Wykonawcę Zamawiającemu (na nośnikach elektronicznych CD/DVD lub USB) wraz ze stosowną dokumentacją kodu.

4. Wykonawca przeniesie na Zamawiającego całość majątkowych praw autorskich do oprogramowania wytworzonego w toku realizacji projektu.

5. Oferowane oprogramowanie w dniu składania ofert nie może być przeznaczone przez producenta do wycofania z produkcji, sprzedaży lub wsparcia technicznego.

6. Zamawiający wymaga, by dostarczone oprogramowanie było oprogramowaniem w najwyższej wersji oraz najbardziej aktualnej na dzień składania ofert.


78


Sprzęt1. Oferowany sprzęt musi spełniać wymagania norm CE, tj. musi spełniać wymogi

niezbędne do oznaczenia produktów znakiem CE.2. Wymagane jest zapewnienie przez Wykonawcę w ramach oferty wszystkich

niezbędnych kabli sieciowych (kat. 6) i zasilających wymaganych do prawidłowej pracy urządzeń.

3. Dostarczone urządzenia muszą mieć zainstalowane wszystkie najnowsze zestawy poprawek dotyczące dostarczanego sprzętu (najnowsza wersja firmware na dzień dostawy).

4. Wszystkie oferowane urządzenia muszą być fabrycznie nowe.5. Do każdego urządzenia musi być dostarczony komplet nośników umożliwiających

odtworzenie oprogramowania zainstalowanego w urządzeniu.6. Urządzenia i ich komponenty muszą być oznakowane przez producenta w taki sposób,

aby możliwa była identyfikacja zarówno produktu, jak i producenta.

Instalacja i konfiguracja sprzętu realizowana przez Wykonawcę zgodnie z uzgodnionym z Zamawiającym Projektem technicznym obejmie w szczególności:

1. Uzgodnienie z Zamawiającym rozmieszczenia poszczególnych urządzeń, sposobu ich mocowania, zasilania oraz przebiegu tras kablowych.

2. Zapewnienie jak najwyższej jakości produktu, jak i jakości pracy podczas realizacji projektu.

3. Przydzielenie do realizacji prac specjalistów o odpowiednich dla instalowanych urządzeń kwalifikacjach i doświadczeniu.

4. Konfigurację połączeń sieciowych urządzeń pozwalająca im na współpracę z siecią LAN i WAN oraz z pozostałymi dostarczonymi urządzeniami.

5. Instalację i konfigurację dostarczonych serwerów, utworzenie stosownych maszyn wirtualnych (serwer aplikacyjny, serwer bazodanowy), podłączenie maszyn wirtualnych do domeny Active Directory wskazanej przez Zamawiającego.

6. Instalację i konfigurację oprogramowania systemowego wraz z aktualnymi w czasie dostawy poprawkami, oprogramowaniem diagnostycznym, narzędziowym oraz pozostałego oprogramowania dołączanego do dostarczanych urządzeń.

7. Instalację i konfigurację dostarczonego oprogramowania, w sposób zapewniający prawidłową pracę rozwiązania z wykorzystaniem wszystkich jego funkcjonalności.

[Testy]

W ramach testów rozwiązania w pierwszej kolejności przygotowany zostanie przez Wykonawcę Plan Testów . Szczegółowa jego zawartość została opisana w Rozdziale VI.6 Opracowanie dokumentacji w sekcji Plan Testów i Scenariusze Testowe.


79


Testy poza funkcjonalnościami rozwiązania zweryfikują również mechanizmy migracyjne oraz mechanizmy integracji i wymiany danych. Plan Testów musi obejmować wszystkie rodzaje planowanych w projekcie testów.

Plan testów podlega akceptacji Zamawiającego zgodnie z procedurą odbiorową opisaną w Załączniku nr 4.

Wykonawca jest zobligowany do przygotowania środowiska testowego zgodnie z zatwierdzonym przez Zamawiającego Planem Testów.

Wykonawca zobligowany jest do uczestnictwa w prowadzonych przez Zamawiającego testach i bieżącego wsparcia zespołu Zamawiającego w toku realizowanych testów. Wersja systemu dostarczona przez Wykonawcę Zamawiającemu powinna przejść uprzednio pozytywnie testy wewnętrzne w organizacji Wykonawcy, a przy kolejnej korekcyjnej iteracji testów również stosowne testy regresyjne.

Zamawiający w toku testów, poza weryfikacją systemu na bazie Scenariuszy Testowych przygotowanych przez Wykonawcę, może tworzyć I realizować własne scenariusze testowe oraz dokonywać testów rozwiązania ad-hoc (bez użycia scenariuszy).

Scenariusze testowe powinny być przygotowane przez Wykonawcę dla każdego z objętych projektem rodzajów testów. Scenariusze testowe muszą być możliwe do zaimportowania w oprogramowaniu TestFLO Test Management for JIRA i HP ALM, które są w posiadaniu Zamawiającego.

W projekcie wymagana jest realizacja Testów Akceptacyjnych Zamawiającego (TAZ), w tym:a) testów funkcjonalnych – testy poszczególnych funkcji systemu w ramach obszaru

wdrożenia. b) testów pokrycia- realizowanych dla identyfikacji wszystkich przypadków testowych,c) testów wydajnościowych – testy polegające na określeniu czasu odpowiedzi systemu

w dialogowym trybie pracy dla określonej liczby jednocześnie pracujących użytkowników i czasu realizacji w systemie określonych procesów. Testowane będą różne poziomy obciążenia oraz sytuacja przeciążenia systemu. Zamawiający wymaga sprawnego działania systemu przy obciążeniu na poziomie 3000 równoległych sesji. Wymagany scenariusz testów wydajnościowych został opisany w sekcji poniżej.

d) testów integracyjnych – test realizacji procesów zaimplementowanych w systemie, a wymagających wymiany danych z systemami współpracującymi z projektowanym rozwiązaniem.Uwaga: w sytuacji opóźnienia prac podmiotów trzecich działających na zlecenie Zamawiającego, w ramach realizacji prac dot. budowy interfejsów pomiędzy Systemem i innymi systemami wykorzystywanymi przez Zamawiającego, o których mowa w OPZ, Zamawiający przewiduje możliwość dokonania odbioru danego interfejsu na bazie


80


dedykowanych na taki wypadek scenariuszy testowych, których celem jest potwierdzenie poprawnej konstrukcji interfejsów bez udziału systemu zewnętrznego, dla którego stwierdzony został brak wymaganej gotowości do testów. Pozytywna realizacja powyższych testów będzie warunkiem wystarczającym dla odbioru prac w tym zakresie. Niemniej jednak w przypadku wystąpienia takiej sytuacji Wykonawca będzie zobligowany do realizacji dodatkowych prac sprawdzających poprawność wymiany danych między systemami w późniejszym terminie, w okresie wdrożenia lub w okresie realizacji usług serwisowych, o których mowa w Rozdziale 8.

e) testów jednostkowych – w zakresie testów poszczególnych elementów składających się na rozwiązanie

f) testów migracyjnych – testy weryfikujące czy przygotowane rozwiązania techniczne w zakresie migracji danych z obecnych systemów Zamawiającego do systemu projektowanego są poprawnie skonstruowane zarówno od strony mechanizmów importu danych, jak i poprawności mapowania danych i jakości samych danych.

g) testów bezpieczeństwa – w szczególności w zakresie analiza zgodności konfiguracji i sposobu funkcjonowania urządzeń oraz analiza podatności aplikacji.

h) testów użyteczności – zrealizowane zostaną z zaangażowaniem użytkowników końcowych systemu, obejmują weryfikację interakcji użytkowników z systemem w zakresie badania poprawności budowy interfejsu użytkownika w tym jego intuicyjności i przyjazności oraz zgodności z wymaganymi w tym zakresie standardami.

i) testów akceptacyjnych dot. poprawności konfiguracji infrastruktury serwerowej, w tym testów ciągłości działania, funkcjonowania migracji maszyn wirtualnych, symulacji awarii węzła klastra.

j) testów dostępności systemu- badanie z udziałem osób niepełnosprawnych. Celem testu jest weryfikacja zastosowanych w portalu rozwiązań dostosowania do wymogów WCAG 2.0 bezpośrednio przez samych użytkowników. W celu poprawnego przeprowadzenia testu reprezentatywna grupa testujących osób powinna zawierać osoby z różnymi rodzajami dysfunkcji i korzystające z różnych technologii asystujących w szczególności: osoby niedowidzące korzystające z programu do powiększania treści wyświetlanej na ekranie (np. Zoom Text), osoby cierpiące na niepełnosprawność motoryczną, które nie mogą korzystać z myszy, czy osoby będące w posiadaniu i użytkowaniu na co dzień programu do rozpoznawania mowy. Przeprowadzanie testu polega na wykonaniu przez użytkowników kilku czynności albo dotarciu do określonej informacji. Spostrzeżenia i uwagi są zapisywane.

Testy wydajnościowe powinny zostać zrealizowane z uwzględnieniem poniższych wymagań dot. scenariusza testów:

1. Testy odbędą się w środowisku produkcyjnym z poziomu sieci lokalnej Zamawiającego.


81


2. Przedmiotem testu będą symulowane operacje użytkowników na systemie produkcyjnym.

3. Na test składały się będą skrypty automatyczne odzwierciedlające przejście przez wybrane moduły/podstrony systemu.

4. Zamawiający wskaże reprezentatywne moduły/podstrony wytworzonego systemu, które wejdą w skład testu, przy założeniu, że merytoryczna zawartość informacyjnej treści tekstowej (tzn. zawartość strony poza znacznikami HTML, skryptami, arkuszami stylów, ilustracjami i innymi elementami strony HTML nie stanowiącymi zawartości merytorycznej) serwowanej przez poszczególne podstrony nie przekroczy 500kB.

5. W trakcie testu użytkownicy, po zalogowaniu się, przechodzą między modułami wykonując operacje odczytu i zapisu do bazy.

6. Obciążenie systemu symulowane będzie poprzez inicjację 3000 równoczesnych sesji użytkowników w systemie.

7. Użytkownicy inicjowani będą stopniowo z użyciem losowego czasu reakcji pomiędzy transakcjami, aby warunki testu były jak najbardziej zbliżone do rzeczywistych.

8. Co 5 sekund loguje się kolejnych 10 użytkowników. Łącznie ramp-up zajmuje 25 minut.

9. Czas reakcji użytkownika przyjęto jako wartość losową z zakresu między 10, a 15 sekund.

10. Po przejściu ścieżki scenariusza użytkownicy powtarzają pełną ścieżkę scenariusza.11. Oczekiwany rezultat, którego spełnienie warunkuje spełnienie wymagań

wydajnościowych nałożonych przez Zamawiającego:a. Średni czas załadowania testowanej strony systemu nie może być dłuższy niż 5

sekund.b. Średni czas transakcji zapisu do bazy nie może być dłuższy niż 5 sekund.

[Migracja danych]

Wykonawca na potrzeby migracji przygotuje stosowny Plan migracji – dokument precyzujący organizacyjne i merytoryczne aspekty dot. procesu migracji.

Dokument Planu migracji musi zawierać co najmniej:

a) cel migracji,b) źródła zbiorów danych,c) zakres zbiorów danych, d) metodę migracji dla każdego ze zbiorów,e) zasady organizacyjne, podział zadań,f) oprogramowanie wspomagające migrację,g) harmonogram migracji,h) macierz pokrycia wymagań dotyczących migracji danych.


82


Dokument musi zostać zatwierdzony przez Zamawiającego przed rozpoczęciem dalszych prac.

Wymagany zakres migracji dotyczy danych zgromadzonych w obecnie eksploatowanym Systemie Portal Informacyjny. Zamawiający wymaga pełnego przeniesienia danych z obecnie eksploatowanych 11 PI (baz danych PostgreSQL) do rozwiązania docelowego – dostarczonej w ramach oferty platformy bazodanowej in-memory computing z zachowaniem odrębności logicznej danych 11 portali.

Na potrzeby migracji danych Wykonawca przygotowuje stosowne narzędzia (w tym jeżeli konieczne: arkusze na dane, automaty migracyjne), które przed dokonaniem pełnoskalowej migracji danych zostaną odpowiednio przetestowane w procesie próbnych migracji testowych (patrz testy migracyjne opisane w Sekcji [Testy]). Proces migracji musi zapewnić pełną integralność migrowanych danych, co zweryfikowane zostanie przygotowanymi przez Wykonawcę mechanizmami walidacji danych.

Po zakończeniu migracji Wykonawca przygotuje Raport podsumowujący wyniki migracji. Raport ten podlega zatwierdzeniu Zamawiającego, co jest jednym z elementów bezpośrednio warunkujących możliwość realizacji uruchomienia produkcyjnego systemu.

[Uruchomienie systemu]

Wykonawca zobowiązany jest do przygotowania Planu uruchomienia systemu – obejmuje on wszystkie czynności przygotowawcze (wymagane do realizacji po stronie Wykonawcy i Zamawiającego) do przeprowadzenia startu produkcyjnego systemu, w tym sprawdzenie wszystkich kluczowych dla poprawnego uruchomienia systemu składowych rozwiązania, kompletności i aktualności produktów zadań poprzedzających uruchomienie, a także przygotowanie procedur organizacyjnych dot. przechodzenia użytkowników z obecnych systemów Zamawiającego do rozwiązania docelowego.

Wykonawca zobowiązany jest na tym etapie prac do współdziałania z Zamawiającym i udzielania mu wszelkich niezbędnych wyjaśnień, rozwiązania i przeprowadzenia odbioru wszelkich zagadnień otwartych ważnych dla uruchomienia systemu, jak również wszelkich innych zadań, które wynikają z ustaleń projektowych Stron oraz wypełnienia innych niezrealizowanych dotychczas przez Wykonawcę zobowiązań projektowych.

Dokument Planu uruchomienia systemu musi zawierać co najmniej:

a) cel uruchomienia,

b) założenia organizacyjne uruchomienia,


83


c) listę zadań kluczowych do wykonania przed uruchomieniem,

d) listę zadań kluczowych do wykonania po uruchomieniu,e) zasady organizacyjne uruchomienia i podział zadań,f) procedurę awaryjną na wypadek trudności w uruchomieniu produkcyjnym,g) harmonogram prac uruchomieniowych.

Plan uruchomienie systemu podlega akceptacji Zamawiającego przed rozpoczęciem dalszych prac.

Zadania Wykonawcy na etapie przygotowania do uruchomienia i uruchomienia obejmą w szczególności działania zorientowane na wprowadzenie do systemu ostatecznych danych, usunięcia wszelkich zidentyfikowanych na etapie testów usterek systemu, założenia wymaganych kont i przypisania ról użytkownikom w środowisku produkcyjnym.

Zakończenie realizacji zadań przewidzianych dla etapu uruchomienia produkcyjnego podsumowane zostanie Raportem z uruchomienia systemu.

6. Przeprowadzenie szkoleń

Wykonawca zobowiązany jest do przygotowania Planu Szkoleń. Dokument ten powinien precyzować szczegółowo nie tylko aspekty organizacyjne realizacji szkoleń, harmonogram szkoleń, ale również opisywać merytoryczne aspekty szkoleń jak agendy poszczególnych szkoleń i program szkoleń.

Rozpoczęcie realizacji szkoleń warunkowane jest akceptacją przez Zamawiającego Planu szkoleń przygotowanego przez Wykonawcę.

[Szkolenia e-learningowe]1) Wykonawca przygotuje materiały szkoleniowe do szkoleń e-learningowych obywateli

w platformie SAP LSO (zwane dalej „Materiałami szkoleniowymi”) 2) Zamawiający udostępni do realizacji szkoleń e-learningowych moduł SAP LSO.3) Dla szkoleń e-learningowych Wykonawca zapewni profesjonalne Materiały

szkoleniowe, zawierające część teoretyczną oraz ćwiczenia pozwalające na aktywne zdobywanie wiedzy w zakresie obsługi Portalu Informacyjnego

4) Szkolenia e-learningowe muszą być interaktywne. Nie jest akceptowalna forma prezentacji zawierającej jedynie screeny z ekranu. Uczestnik szkolenia musi mieć możliwość nawigacji. Elementem szkoleń e-learningowych powinny być scenki i filmiki wspomagające przyswajanie wiedzy jak również wypełniane aktywnie formularze ekranowe i egzamin ze zdobytej wiedzy.

5) Materiały szkoleniowe wykonane mają być w języku polskim w postaci elektronicznej.


84


6) Materiały szkoleniowe przygotowane mają być w formacie SCORM 2004, przy wykorzystaniu narzędzia Authoring Environment lub równoważnego.

7) Warunkiem przystąpienia do realizacji Materiałów szkoleniowych jest akceptacja Projektu Szkoleń przez Zamawiającego zgodnie z procedurą opisaną w Załączniku Nr 4

8) Projekt Materiałów szkoleniowych powinien zawierać co najmniej informacje o sposobie przekazania wiedzy, plan szkolenia, podział na bloki tematyczne, informacje o formie sprawdzenia i utrwalenia wiedzy, informacje o wykorzystanych funkcjach i dodatkach (np. zdjęcia, zapisy audio lub audio-wideo), które mają przyczynić się do uatrakcyjnienia szkolenia, formę sprawdzenia nabytej wiedzy, sposób stylizacji slajdów, projekt wizualno-funkcjonalny szkolenia w postaci reprezentatywnych ekranów szkolenia (prototyp szkolenia zawierający do kilkunastu ekranów szkolenia ujmujący wszystkie typy ekranów i formy dydaktyczne zaplanowane w szkoleniu oraz umożliwiające prezentację nawigacji i narracji), wkład merytoryczny (wszelkie treści dydaktyczne, które będą składały się na przygotowane szkolenia w postaci tekstowej gotowe do przetworzenia na postać szkolenia e-learningowego).

9) W ramach projektu Materiałów szkoleniowych Wykonawca przedstawi testowe szkolenie e-learningowe, które Zamawiający zaimplementuje na platformie SAP LSO celem weryfikacji treści merytorycznej i zastosowanej formy graficznej.

[Wymagania ogólne dla szkoleń]1) Szkolenia muszą być zrealizowane w języku polskim.2) Szkolenia obejmować będą wyłącznie zakres funkcjonalności rozwiązania, który

przeszedł pozytywne testy akceptacyjne Zamawiającego. 3) Szkolenie dot. administracji zrealizowane zostanie w zakresie, który zagwarantuje

Zamawiającemu samodzielne zarządzanie wdrożonym systemem.4) Wykonawca zapewni asystę zdalną trenera odpowiadającego na pytania uczestników

szkolenia (drogą elektroniczną) przez okres do 2 tygodni po zakończeniu ostatniego ze szkoleń.

5) Po zakończeniu szkoleń oraz asysty Wykonawca przygotuje raport podsumowujący wyniki szkoleń i asysty.

Zamawiający w zakresie rozwiązań in-memory computing posiada obecnie licencje produktu SAP HANA oraz stosowne kompetencje związane z jego eksploatacją produkcyjną w MS – jeżeli oferowanym rozwiązaniem bazodanowym in-memory computing będzie inna platforma bazodanowa niż SAP HANA Wykonawca zobowiązany jest do zapewnienia w ramach oferty stosownych szkoleń dla administratorów Zamawiającego w lokalizacji centralnej tj. we Wrocławiu (nie mniej niż dla 5 osób i nie więcej niż dla 10 osób) z dostarczanego rozwiązania bazodanowego, w wymiarze nie mniejszym niż 80h szkoleń


85


7. Opracowanie dokumentacji [Wymagania ogólne dot. dokumentacji]

1) Wykonawca przygotuje oraz stosownie zaktualizuje zgodnie z ogólnie akceptowalnymi standardami w dziedzinie dokumentowania, następujące rodzaje dokumentacji bezpośrednio związanej z przedmiotem zamówienia:

Dokumentację projektową, Dokumentację systemową (w tym wydzieloną dokumentację interfejsów

programistycznych), Dokumentację utrzymaniową, Dokumentację w zakresie podręczników użytkownika, Dokumentację bezpieczeństwa, Dokumentację powykonawczą.

2) Wykonawca zobowiązuje się do opracowania każdej z wymienionych wyżej dokumentacji w języku polskim w jednym wydrukowanym egzemplarzu oraz w wersji elektronicznej w formacie doc i formacie PDF na nośniku CD/DVD lub USB.

3) Wszystkie dokumenty tworzone w ramach realizacji przedsięwzięcia charakteryzowały się będą wysoką jakością, na którą będą miały wpływ, takie czynniki jak:

1. czytelna i zrozumiała struktura zarówno poszczególnych dokumentów jak i całej dokumentacji z podziałem na rozdziały, podrozdziały i sekcje,

2. zachowanie standardów, a także sposób pisania, rozumianych jako zachowanie jednolitej i spójnej struktury, formy i sposobu prezentacji treści poszczególnych dokumentów oraz fragmentów tego samego dokumentu, jak również całej dokumentacji,

3. kompletność dokumentu, rozumiana jako pełne, bez wyraźnych, ewidentnych braków przedstawienie omawianego problemu obejmujące całość opisu rozpatrywanego zagadnienia. Oznacza to w szczególności jednoznaczne i wyczerpujące przedstawienie wszystkich zagadnień w odniesieniu do systemu,

4. spójność i niesprzeczność dokumentu, rozumianych jako zapewnienie wzajemnej zgodności pomiędzy wszystkimi rodzajami informacji umieszczonymi w dokumencie, jak i brak logicznych sprzeczności pomiędzy informacjami zawartymi we wszystkich przekazanych dokumentach oraz we fragmentach tego samego dokumentu.

4) W dokumentacji dotyczącej specyfikacji wymagań dla każdego wymagania nadanie unikalnej etykiety, tak aby w pozostałej części dokumentacji jednoznacznie wskazywać sposób realizacji określonych wymagań, gwarantując również kompletność realizacji zdefiniowanych wymagań w projektowanym rozwiązaniu.

5) Cała dokumentacja, o której mowa powyżej, podlegała będzie akceptacji Zamawiającego.


86


6) Wykonawca przeniesie na Zamawiającego całość majątkowych praw autorskich do stworzonej w toku projektu dokumentacji.

7) W zakresie dokumentacji związanej z przedmiotem dostawy oprogramowania, do którego Wykonawca nie posiada autorskich praw majątkowych, Wykonawca jest zobowiązany do dostarczenia dokumentacji zgodnie ze specyfikacją danego produktu, określoną przez producenta/dystrybutora produktu.

8) Zamawiający nie akceptuje użycia do realizacji zamówienia licencji oprogramowania, dla którego nie jest dostępna dokumentacja użytkownika w formie papierowej lub elektronicznej.


87


[Dokumentacja projektowa]Dokumentacja projektowa

1. jest spójna i skoordynowana we wszystkich dziedzinach wiążących się z realizacją przedmiotu zamówienia oraz sporządzona w takiej formie i szczegółowości, aby możliwe było dokonanie jej oceny przez inny niezależny podmiot, co zastrzega sobie Zamawiający, w szczególności musi zawierać:

a) diagram kontekstowy przedsięwzięcia realizowanego w ramach przedmiotu zamówienia,

b) procesy kierujące przedsięwzięciem,c) strukturę i zawartość planu projektu,d) techniki zarządzania projektem,e) zestaw elementów sterujących zarządzaniem i jakością, w tym

dokumentacja definiujące działania zarządcze, tj. planowanie, monitorowanie i raportowanie prac w ramach przedsięwzięcia, w sytuacjach normalnych i wyjątkowych, a także działania specjalistyczne determinowane przez zakres i cele przedsięwzięcia, opisujące prace niezbędne do wytworzenia produktów, które mają powstać w ramach realizacji przedmiotu zamówienia,

2. w pełni odzwierciedla architekturę przedmiotu zamówienia, jego organizację, oraz wszystkie funkcje przewidziane do realizowania przez dostarczone rozwiązanie, a także administratorów i użytkowników,

3. zawiera kompletny i szczegółowy opis przyjętych rozwiązań funkcjonalnych, z wyspecyfikowaniem asortymentowym i ilościowym wszystkich elementów składowych rozwiązania,

4. określa zasady i plany instalacji, konfiguracji i uruchomienia poszczególnych składowych rozwiązania,

5. określa rodzaje i zasady testów akceptacyjnych odbioru przedmiotu zamówienia wraz z kryteriami ich akceptacji, procedury przeprowadzenia testów,

6. wskazuje punkty krytyczne i zagrożenia mające wpływ na niezawodne działanie dostarczonych rozwiązania.

W przekazywanej Zamawiającemu dokumentacji projektowej Wykonawca załącza oświadczenie z treści którego wynikać będzie jednoznacznie możliwość uzyskania na bazie przyjętych w dokumentacji projektowej rozwiązań, rezultatu końcowego określonego przez Zamawiającego.

[Dokumentacja systemowa]Dokumentacja systemowa musi zawierać co najmniej następujące informacje:

1. Wprowadzenie opisujące cele i zakres


88


2. Diagram kontekstowy zaproponowanego rozwiązania i model zachowania3. Ograniczenia rozwiązania 4. Założenia i zależności5. Ogólna charakterystyka użytkowników6. Opis wymagań funkcjonalnych i niefunkcjonalnych7. Specyfikację wymagań funkcjonalnych8. Specyfikację wymagań niefunkcjonalnych9. Opis wymagań sprzętowych i programowych10. Specyfikację wymagań sprzętowych11. Specyfikację wymagań programowych12. Opis i specyfikację interfejsów

Dokumentacja musi zawierać co najmniej szczegółową specyfikację interfejsów programistycznych rozwiązania.

13. Program przebiegu testów i sposób oszacowania niezawodności zastosowanego rozwiązania, w tym propozycję raportów z testów.

14. Opis i specyfikację migracji danych15. Wytworzone kody źródłowe.

[Projekt Techniczny]Projekt techniczny obejmować musi szczegółowe omówienie planowanej architektury rozwiązania realizującej zdefiniowane w OPZ wymagania funkcjonalne i niefunkcjonalne opisane do poziomu szczegółowych parametrów konfiguracyjnych. Projekt Techniczny musi zostać opracowany na poziomie szczegółowości gwarantującym jednoznaczność opisu sposobu działania systemu oraz sposobu jego konfiguracji (w tym fizycznych komponentów rozwiązania np.: konfiguracji sieciowych, planów adresacji, środowiskowych, plików i parametrów konfiguracyjnych, ścieżek, mechanizmów dot. niezawodności i bezpieczeństwa działania, modeli wymiany danych w ramach mechanizmów integracyjnych, opisu działania i wywoływania poszczególnych funkcji, projektów widoków poszczególnych ekranów w systemie, formatów danych wprowadzanych, pól, walidacji, filtracji, sortowania itp.).W Projekcie technicznym ujęte zostaną również zagadnienia dotyczące sposobu realizowania zapytań bazodanowych w modelu in-memory computing oraz mechanizmy replikacji i działania oprogramowania klastrowego.Opisany w Projekcie technicznym projekt infrastruktury i środowiska musi uwzględniać podział środowisk na co najmniej środowisko: produkcyjne, testowe, deweloperskie. W Projekcie Technicznym wymagane jest usystematyzowane opisanie zagadnień m.in. w zakresie:

przedmiotu wdrożenia, celów, założeń, zależności i ograniczeń, funkcjonalności oprogramowania, opisu i specyfikacji wymagań, aktorów, uprawnień i ról,


89


przypadków użycia systemu opisanych stosownymi scenariuszami, opisu sposobu realizacji poszczególnych przypadków użycia w systemie, modeli struktur danych, schematów przepływu danych, interfejsu użytkownika, interfejsów integracyjnych (wewnętrznych i zewnętrznych), uwzględniając

wymagania opisane w Rozdziale VI modelu importu danych, szczegółowego opis konfiguracji poszczególnych komponentów systemu

(sprzętowych i systemowych),

składające się na projekt architektury logicznej i fizycznej tworzonego rozwiązania.

[Plan testów i Scenariusze testowe]

Plan testów obejmuje w szczególności: Scenariusze Testowe oraz dane testowe (w tym stosowne próbki do testów jakościowych ARM oraz dane do testów migracyjnych i obciążeniowych) będące podstawą weryfikacji poprawności działania rozwiązania i jego zgodności z założeniami opisanymi w Projekcie Technicznym. Plan Testów regulował będzie również szczegółowe założenia i procedury realizacji testów – musi zawierać w tym zakresie:

a) cel przeprowadzenia testu,b) metodę̨ przeprowadzenia testów,c) zasady organizacyjne, podział zadań,d) oprogramowanie wspomagające testy,e) harmonogram testów,f) macierz pokrycia wymagań i przypadków użycia scenariuszami testowymi,g) opis i konfigurację środowiska testowego,h) wykaz danych testowych niezbędnych do wykonania testów.

Scenariusze Testowe muszą pokrywać wszystkie zdefiniowane w Projekcie Technicznym przypadki użycia rozwiązania oraz zawierać w każdym teście poza ścieżką podstawową co najmniej jedną ścieżkę alternatywną realizacji pracy. Scenariusze Testów zawierać będą co najmniej dane w zakresie:

a) Nr scenariuszab) Nr kroku testowegoc) Opis czynności do wykonaniad) Dane testowe e) Użytkownik wykonujący (rola w systemie)f) Oczekiwany rezultatg) Odnotowanie uzyskanego w teście rezultatuh) Uwagi


90


Scenariusze testowe powinny być przygotowane przez Wykonawcę dla każdego z objętych projektem rodzajów testów.Scenariusze testowe muszą być możliwe do zaimportowania w oprogramowaniu TestFLO - Test Management for JIRA i HP ALM, które jest w posiadaniu Zamawiającego.Scenariusze Testowe podlegają akceptacji Zamawiającego zgodnie z procedurą opisaną w Załączniku Nr 4.

[Dokumentacja utrzymaniowa]1) Dokumentacja utrzymaniowa, musi zawierać co najmniej:

procedury administracyjne, procedury zabezpieczeń (backup’owe), ) - określające ściśle zakres działań i

odpowiedzialności Wykonawcy oraz i Zamawiającego, procedury awaryjne, procedury użytkownika,

2) Każda z procedur wymienionych w ustępie 1, muszą zawierać, co najmniej następujące informacje:

identyfikator i nazwę procedury, rodzaj procedury, data utworzenia i zatwierdzenia oraz wersja procedury, cel i zakres procedury, warunki uruchomienia procedury i oczekiwany rezultat jej wykonania, dane osób, które opracowały procedurę, sprawdziły, zaakceptowały

i zatwierdziły, działania, które występują jedno po drugim, jakie należy wykonać, aby osiągnąć

postawiony cel, w tym informacja o osobie (zgodnie z zaproponowanymi rolami), która powinna wykonać dane czynności.

[Dokumentacja w zakresie podręczników użytkownika] 1) Podręczniki opracowane zostaną przez Wykonawcę dla każdej z ról przewidzianych

w systemie.2) Podręcznik może zawierać zrzuty ekranów (opatrzone krótkimi opisami tekstowymi)

demonstrujące oczekiwane stany systemu. 3) W szczególności powinny zostać dostarczone podręczniki:

- podręcznik systemu standardowego (jeżeli taki system jest składową oferowanego rozwiązania) tj. systemu w wersji przed aplikacją w nim zmian specyficznych dla wdrożenia w organizacji Zamawiającego,


91


- podręcznik dla użytkowników wewnętrznych zgodny z wypracowaną w toku projektu koncepcją wdrożenia systemu w organizacji Zamawiającego, umożliwiająca samodzielne i sprawne wykonywanie wszelkich operacji w systemie przez użytkowników,

- podręcznik dla użytkowników zewnętrznych zgodny z wypracowaną w toku projektu koncepcją wdrożenia systemu w organizacji Zamawiającego, umożliwiająca samodzielne i sprawne wykonywanie wszelkich operacji w systemie przez użytkowników.

[Instrukcje w postaci prezentacji dla użytkowników]Dokumentacja dostępna na stronach Portalu. Wykonawca opracuje instrukcje wspierające użytkowników Portalu w korzystaniu z funkcjonalności systemu. Instrukcje zawierać będą szczegółowy opis (krok po kroku) sposobu wykonywania poszczególnych czynności w Systemie. Dopuszcza się formę instrukcji wideo. Dla osób niedowidzących instrukcje będą dostępne również w postaci plików audio. Instrukcje powinny zostać osadzone w sposób kontekstowy względem wyświetlanych przez użytkownika treści.Szczegółowy zakres i forma instrukcji zostanie uzgodniona z Zamawiającym w toku projektu. [Instrukcje wewnętrzne dla administratorów Portalu]

Dotyczy administracyjnej części Portalu. W treści instrukcji powinny być zawarte informacje dot. użytkowania Panelu Administracyjnego, ze szczególnym uwzględnieniem nowych funkcjonalności wdrażanych w ramach projektu, w tym zarządzania Modułem obsługi wniosków. Szczegółowy zakres instrukcji zostanie uzgodniony z Zamawiającym w toku projektu.

[Dokumentacja powykonawcza]

Dokumentację powykonawczą systemu stanowić będzie zaktualizowana dokumentacja projektu uzupełniona o opis wykonanych w toku prac instalacji technicznych, opis zainstalowanego sprzętu i oprogramowania wraz z informacjami o parametrach i sposobie konfiguracji, instrukcje techniczno-instalacyjne, instrukcje obsługi sprzętu i oprogramowania oraz inne dokumenty producentów, a także materiały szkoleniowe w zakresie dotyczącym systemu.

W szczególności w ramach dokumentacji powykonawczej wymagana jest aktualizacja:

1) Projektu Technicznego,

2) diagramów ze strukturami danych,

3) dokumentacji interfejsów systemu,

4) kodów źródłowych i dokumentacji tych kodów.


92


[Dokumentacja bezpieczeństwa]Dokumentacja bezpieczeństwa oznacza część Dokumentacji zawierającą co najmniej informacje dotyczące wytycznych, reguł i procedur związanych z ochroną zasobów informacyjnych przedmiotu Umowy. Opisuje sposoby i tryb postępowania w sprawach związanych z bezpieczeństwem informacji przetwarzanych w systemach objętych zamówieniem oraz zakres odpowiedzialności użytkowników systemów i pracowników mających dostęp do tych systemów. Musi zawierać:

1) Opis procesu zarządzania ryzykiem: opis metodyki szacowania ryzyka identyfikację zagrożeń dla poufności integralności oraz dostępności informacji

przetwarzanych w systemach objętych zamówieniem raport z procesu szacowania ryzyka listę wdrożonych zabezpieczeń informacje o ryzyka szczątkowych

2) plany ciągłości działania3) opis bezpieczeństwa fizycznego

środki ochrony fizycznej zasilanie awaryjne zapewnienie warunków środowiskowych alternatywne łącza

4) informacje o zastosowanych urządzeniach i narzędziach kryptograficznych5) ochrona nośników

oznaczanie dostęp transport niszczenie nośników

6) procedury odnoszących się do następujących zagadnień: administrowanie systemem IT administrowanie środkami ochrony bezpieczeństwo urządzeń bezpieczeństwo oprogramowania zarządzanie konfiguracją sprzętową zarządzanie konfiguracją programową zasady serwisowania zasady modernizowania zasady wycofania elementów systemu plany awaryjne monitorowanie systemu IT audyt systemu IT zarządzanie nośnikami zarządzanie materiałami kryptograficznymi


93


incydenty bezpieczeństwa szkolenia użytkowników


94


8. Serwis gwarancyjny, utrzymanie i rozwój

8.1. Usługa gwarancyjnaWykonawca udziela gwarancji na wszystkie produkty i usługi wykonane w ramach realizacji przedmiotu Umowy na okres od daty odbioru danego produktu lub usługi do 48 miesięcy od daty podpisania Protokołu Odbioru Końcowego lub odpowiednio Protokołu Odbioru Serwisu lub protokołu Odbioru Modyfikacji.

1) Usługa gwarancyjna obejmuje wszystkie wykryte podczas eksploatacji Systemu błędy tj. uszkodzenia, wady i nieprawidłowości w funkcjonowaniu Systemu.

2) W zakresie klasyfikacji błędów Systemu, ewidencji zgłoszeń, procedur odbioru, czasu realizacji zgłoszeń, odbioru usług, naliczania kar umownych mają zastosowanie zapisy OPZ i Umowy.

3) Usługa obejmuje wszystkie powstałe w systemie Modyfikacje.4) W przypadku zmian w Systemie wynikających z instalacji nowych wersji na skutek

naprawy błędów lub Modyfikacji, Wykonawca dokona na żądanie Zamawiającego aktualizacji dokumentacji, w tym dokumentacji użytkowej.

8.2. Zasady realizacji usługi wsparcia technicznego i serwisu1. Wykonawca świadczy usługę wsparcia technicznego i serwisu Systemu Portal

Informacyjny dla Zamawiającego. 2. Usługa wsparcia technicznego i serwisu obejmuje:

1) wszystkie komponenty oprogramowania i sprzętu wykorzystywane przez Wykonawcę w ramach Systemu, w tym opisane w Rozdziale VI.3.5 oraz VI.4,

2) systemy operacyjne, w oparciu o które funkcjonuje System w infrastrukturze centralnej,

3) zadania administracji wszystkimi komponentami Systemu w architekturze dwuośrodkowej niezawodnościowo-wydajnościowej, w tym systemami operacyjnymi,

4) obsługa kopii zapasowych baz danych Systemu i ich odtwarzania zgodnie z procedurami zabezpieczeń (backup’owe) dostarczonymi w ramach Dokumentacji utrzymaniowej,

5) usuwanie awarii Systemu oraz skutków awarii Systemu, sprzętu i oprogramowania, a także wszelkich negatywnych skutków spowodowanych korzystaniem z błędnie działających wersji Systemu we wszystkich lokalizacjach funkcjonowania Systemu,

6) usuwanie błędów w oprogramowaniu Systemu,


95


7) dostosowanie Systemu do zmieniających się wersji przeglądarek internetowych zapewniając ciągłą zgodność Systemu z ostatnią i przedostatnią wersją poniższych przeglądarek:a. Internet Explorer,b. Microsoft Edge,c. Mozilla Firefox, d. Opera, e. Safari, f. Google Chrome.

8) realizację konfiguracji Systemu,9) wytworzone Modyfikacje,10) zadania optymalizacji funkcjonowania Systemu w uzgodnieniu z Zamawiającym,

obejmujące optymalizację kodu źródłowego Systemu, systemu baz danych w infrastrukturze centralnej, serwerów aplikacyjnych. Kryterium optymalizacji jest wydajność Systemu (czas dostępu do danych za pośrednictwem usługi po zalogowaniu nie może przekroczyć 3 sekund, logowanie do systemu nie może trwać dłużej niż 7 sekund).

11) odtworzenie Systemu i przywrócenie do pełnej funkcjonalności w tym po katastrofie, pod pojęciem katastrofy Zamawiający rozumie uszkodzenie lub całkowite zniszczenie większości istniejącej infrastruktury systemowej, kiedy do przywrócenia sprawności Systemu niezbędne są działania związane z odtwarzaniem zniszczonych zasobów sprzętowych i danych,

12) monitorowanie i rekomendowanie Zamawiającemu konieczność zainstalowania poprawek i nowych wersji, na poszczególnych elementach Systemu dla środowisk technologicznych w infrastrukturze centralnej, takich jak oprogramowania:

sieciowych systemów operacyjnych, aplikacyjne, bazodanowe, komunikacyjne (o ile system zawiera tego typu oprogramowanie), do prezentacji treści, oraz pozostałego oprogramowania technologicznego i narzędziowego

będącego w posiadaniu Zamawiającego, a niezbędnego do bezpiecznego działania Systemu, a następnie ich wdrożenie na wszystkich środowiskach wskazanych przez Zamawiającego lub na podstawie zgłoszeń instalacji poprawek żądanych do aktualizacji przez Zamawiającego wraz przygotowaniem dokumentacji instalacyjno – konfiguracyjnej (wdrożeniowej) jak i instalacji nowych środowisk na poziomie infrastruktury centralnej we wszystkich środowiskach Zamawiającego (produkcyjnych, testowych) oraz aktualizacji tych instrukcji przy każdej istotnej zmianie.


96


13) monitorowanie infrastruktury w zakresie prawidłowości działania, dostępności i wykorzystania zasobów procesów i usług oraz udostępnienie monitoringu Zamawiającemu,

14) wymiarowanie systemu i przygotowywanie rekomendacji w celu uniknięcia spadku wydajności i błędów i awarii,

15) przeprowadzania testów wydajnościowych systemu, a w razie wystąpienia sytuacji opisanej w Rozdziale 5 w Sekcji [Testy] pkt. d) testy integracyjne, również dodatkowe testy weryfikacyjne w zakresie interfejsów.

16) wykonanie i aktualizowanie dokumentacji utrzymaniowej systemu,17) wsparcie serwisowe zapewniane dla platformy bazodanowej in-memory

computing zgodnie z sekcją Serwis platformy bazodanowej in-memory computing.3. Realizacja usługi wsparcia technicznego i serwisu będzie wykonywana w sposób

niezakłócający normalnego funkcjonowania Użytkownika Końcowego pomiędzy godziną 6:00 a 22:00 w dni robocze. Wszelkie planowe działania ograniczające dostępność, responsywność i funkcjonalność systemu mogą być prowadzone w dni robocze godzinach od 22:00 do 6:00 i w dni wolne od 06:00 do 12:00 po uprzednim wyznaczeniu przez Zamawiającego okna serwisowego. W szczególnych przypadkach Zamawiający może wyznaczyć inne okno serwisowe. Okno serwisowe wyznacza się min. na 14 dni przed planowanymi pracami. W szczególnych przypadkach Zamawiający może zaakceptować skrócenie czasu na wyznaczenie okna serwisowego.

4. Realizacja usługi wsparcia technicznego i serwisu będzie wykonywana z należytą starannością, zgodnie z wytworzoną w ramach realizacji i utrzymania systemu dokumentacją (w szczególności dokumentacją techniczną i eksploatacyjną) oraz zasadami współczesnej wiedzy technicznej.

5. Wykonawca zapewnia obsługę niemożliwych do zdiagnozowania i usunięcia w sposób zdalny (za pośrednictwem łącza VPN lub telefonicznie) błędów na miejscu u Użytkowników Końcowego lub u Zamawiającego przez specjalistę ze strony Wykonawcy.

6. Zamawiający zastrzega sobie prawo do modyfikacji Systemu przez Zamawiającego lub przez podmiot trzeci. Zamawiający każdorazowo po wprowadzeniu modyfikacji poinformuje Wykonawcę o wykonanych zmianach i przekaże aktualny kod źródłowy Systemu do wdrożenia przez Wykonawcę.

7. Rodzaje kwalifikacji zgłoszeń oraz czas ich realizacji

Rodzaj problemu

Opis Priorytet w

systemie zgłoszenio

wym

Czas na usunięcie błędu

Awaria Zatrzymanie eksploatacji Systemu w sieci krytyczny do 4 godzin od


97


Internet, utrata danych lub naruszenie ich spójności, w wyniku której niemożliwej jest prowadzenie bieżącej działalności Systemu. Za awarie uznawane jest również jednoczesne wystąpienie szeregu Błędów Krytycznych w przypadku kiedy można wykazać, że ich wystąpienie ma ten sam skutek.

zgłoszenia przez Zamawiającego lub Użytkownika

Błąd Krytyczny

Błąd uniemożliwiający poprawne wykorzystanie Systemu lub jego istotnej funkcjonalności do realizacji procesów biznesowych. Zakłócenie pracy Systemu polegające na ograniczeniu realizacji lub uciążliwości w realizacji jednej z funkcji Systemu. Działanie Systemu prowadzące do otrzymywania błędnych wyników przetwarzania danych lub praca Systemu, niezgodna z dokumentacją.

Po udostępnieniu rozwiązania czasowego pozwalającego na realizację błędnie działającej usługi (wdrożeniu obejścia) błąd krytyczny staje się Błędem Niekrytycznym.

Jako błąd krytyczny rozumiemy również błąd mogący powodować lub powodujący przełamanie zabezpieczeń związanych z poufnością, integralnością i dostępnością systemu i danych.

wysoki do dwóch dni roboczych od zgłoszenia przez Zamawiającego lub Użytkownika Końcowego

Błąd Niekrytyczny

Zakłócenie pracy Systemu mogące mieć wpływ na jego funkcjonalność, natomiast nieograniczające zdolności operacyjnych Systemu w obrębie obsługi i wspomagania procesów biznesowych, niebędące Awarią, ani Błędem Krytycznym.

Błędy drobne, błędy ergonomiczne lub kosmetyczne błędy (np. format pól, brak walidacji, literówki, błędne nazwy, konieczność zbędnych „kliknięć” w celu uzyskania pożądanego przez użytkownika rezultatu, itp.).

średni do 7 dni roboczych od daty zgłoszenia przez Zamawiającego lub Użytkownika Końcowego

Błąd importu

Brak lub błąd importu danych z systemu źródłowego niewynikający z przyczyn

średni 48 godzin


98


danych źródłowych

leżących po stronie sądu źródłowego lub infrastruktury sieciowej WAN. Brak reakcji na zidentyfikowane problemy importu danych niezależnie od źródła powstania przyczyny

Konfiguracja

1)Dostosowanie Systemu z uwagi na:1. zmiany prawa w szczególności w

dokumentach wymienionych w załączniku nr 1 Wykaz aktów prawnych zmiany organizacyjno - administracyjnych sądów, w tym w szczególności utworzenie nowego sądu, likwidacja sądu, utworzenie nowego wydziału, likwidacja wydziału,

2. zmiany w systemie repertoryjno-biurowym Użytkownika Końcowego lub zmiana systemu repertoryjno-biurowego,

3. zmiany konfiguracji Importera na żądanie Użytkownika Końcowego,

4. zmiany w środowisku teleinformatycznym Użytkownika Końcowego i Zamawiającego,

5. zmiany w konfiguracji sieci WAN w oparciu, o którą funkcjonuje System,

6. aktualizacje przeglądarek internetowych,

7. wdrożenie u Użytkownika Końcowego modułu integracyjnego, przez który należy rozumieć część systemu repertoryjno - biurowego (SAWA/Sędzia2/Praetor) stanowiącą interfejs dostępu do danych będących przedmiotem importu w postaci uporządkowanej o aktualnej zawartości, Wykonawca dostosuje importer, tak, aby funkcjonował w oparciu o moduł integracyjny i wdroży lub zaktualizuje program u Użytkowników Końcowych zgodnie z Wykazem Lokalizacji Systemu Portal Informacyjny (Załącznik nr 6 do Umowy) w terminie 2 miesięcy od dnia wdrożenia modułu integracyjnego u Użytkownika Końcowego,

8. wdrożenie protokołu z posiedzenia

niski w terminie ustalonym przez Zamawiającego w porozumieniu z Wykonawcą, w przypadku braku porozumienia Stron, termin realizacji zostanie ustalony samodzielnie przez Zamawiającego


99


jawnego sporządzanego za pomocą urządzenia rejestrującego dźwięk albo obraz i dźwięk oraz pisemnie zgodnie z art. 157 § 1 w zw. z art. 158 § 1 Ustawy z dnia 17 listopada 1964 r. Kodeks postępowania cywilnego (t. j. Dz. U. z 2014 r., poz. 101 ze zm.) lub art. 37 Ustawy z dnia 24 sierpnia 2001 Kodeks postępowania w sprawach o wykroczenia (t.j. Dz. U. z 2013 r., poz. 395 ze zm.), w tym wypadku Wykonawca jest zobowiązany wdrożyć Moduł importu nagrań elektronicznego protokołu oraz ich udostępniania na potrzeby streamingu.

2) Instalacja poprawek i nowych wersji do środowiska technologicznego Systemu.

3) Analiza i przeciwdziałanie zagrożeniom wynikającym z podatności komponentów Systemu lub systemów operacyjnych w infrastrukturze centralnej na cyberprzestępczość.

4) Optymalizacja funkcjonowania Systemu w uzgodnieniu z Zamawiającym, obejmująca optymalizację kodu źródłowego Systemu, systemu baz danych w infrastrukturze centralnej, serwerów aplikacyjnych.

9. Procedura realizacji zgłoszeń (Awaria, Błąd Krytyczny, Błąd Niekrytyczny, Konfiguracja

a. Zamawiający przewiduje następujące kanały komunikacji za pośrednictwem:i. systemu zgłoszeniowego ServiceDesk HPSM Ministerstwa

Sprawiedliwości udostępnionego przez Zamawiającego (podstawowy). W przypadku zgłoszeń typu Awaria, dodatkowo telefonicznie na całodobowy numer wskazany przez Wykonawcę.

ii. poprze email (dodatkowy,)iii. telefonicznie w tym na całodobowy numer wskazany przez

Wykonawcę (dodatkowy,)iv. za pośrednictwem innego systemu zgłoszeniowego wskazanego przez

Zamawiającego (dodatkowy).


100


Dodatkowe kanały komunikacji wykorzystywane będą po uzgodnieniu z Wykonawcą, w tym w przypadku niedostępności kanału podstawowego. Zgłoszenia wykonane telefonicznie lub mailowo uzupełnione będą w systemie zgłoszeniowym, a obowiązywać będą rzeczywiste czasy zgłoszeń.

b. Zgłoszenie przesłane przez Zamawiającego lub Użytkownika Końcowego po godz. 16.30 w dniu roboczym Wykonawca przyjmuje do realizacji następnego dnia roboczego o godz. 7.30 z wyłączeniem Awarii i Błędów krytycznych, które przyjmuje się do realizacji niezwłocznie po zarejestrowaniu zgłoszenia.

c. Za moment zgłoszenia uznaje się datę i godzinę zarejestrowania zgłoszenia w systemie Service Desk HPSM Ministerstwa Sprawiedliwości lub w innym alternatywnym kanale komunikacji zdefiniowanym w pkt. a.

d. Zamawiający kategoryzuje zgłoszenia na formularzu zgłoszenia zgodnie z kwalifikacją określoną w tabeli zawierającej rodzaje kwalifikacji zgłoszeń.

e. Zamawiający określa które Błędy Niekrytyczne powinny być realizowane w pierwszej kolejności.

f. Prawidłowa realizacja zgłoszenia, musi być odnotowana w systemie zgłoszeniowym ServiceDesk HPSM Ministerstwa Sprawiedliwości lub w innym systemie zgłoszeniowym wskazanym przez Zamawiającego (jeśli w nim było odnotowane zgłoszenie). Zamawiającemu lub Użytkownikowi Końcowemu przysługuje prawo do zgłoszenia reklamacji prawidłowości rozwiązania.. Czas poświęcony na weryfikację zgłoszenia (od zamknięcia zgłoszenia do otwarcia w wyniku reklamacji) nie jest wliczany w czas jego realizacji przez Wykonawcę. Reklamacje w zakresie prawidłowości rozwiązania zgłoszenia mogą być zgłaszane w terminie 14 dni od ostatniego zamknięcia zgłoszenia.

g. W sytuacji kiedy rozwiązanie zgłoszenia wymaga zainstalowania nowej wersji Systemu, Wykonawca wykona aktualizację w środowiskach testowym, deweloperskim lub produkcyjnym zgodnie z opisem w sekcji Procedura instalacji nowej wersji systemu.

h. Uwagi zgłoszone przez Użytkowników Końcowych bezpośrednio do Wykonawcy, dotyczące funkcjonowania i funkcjonalności, a skutkujące Modyfikacjami Systemu będą niezwłocznie, tj. nie później niż w ciągu 2 dni przekazywane do Zamawiającego za pośrednictwem systemu zgłoszeniowego.

10. Procedura zgłaszania Zamawiającemu konieczności zainstalowania poprawek i nowych wersji poszczególnych elementów Systemu dla środowisk technologicznych

a. Wykonawca przedstawia listę poprawek do zainstalowania do każdego środowiska technologicznego w cyklach kwartalnych. Zamawiający zawsze może żądać dodatkowego cyklu wykonania poprawek lecz nie więcej niż dwa razy na kwartał.


101


b. Zamawiający w terminie 7 dni roboczych od dnia dostarczenia listy poprawek do zainstalowania informuje Wykonawcę, które ze zgłoszonych poprawek będą podlegać realizacji.

c. Wykonawca przeprowadza wdrożenie poprawek podlegających realizacji w terminie 14 dni roboczych od dnia przekazania zatwierdzenia ich przez Zamawiającego.

d. Za nieterminowe wdrożenie poprawek podlegających realizacji naliczone zostaną kary umowne jak za Błąd Niekrytyczny.

Wykonawca przekazuje Zamawiającemu każdorazowo nową wersję Systemu za pomocą środków komunikacji elektronicznej zawierającą w szczególności;

i. nazwa podsystemu,ii. numer wersji,

iii. kompletne kody źródłowe,iv. wykaz zmian w stosunku do poprzedniej wersji,v. instrukcję użytkownika jeżeli wymagała aktualizacji ze szczególnym

uwzględnieniem sposobu postępowania w związku z wprowadzonymi zmianami a także skutkami zmian wersji oprogramowania od strony użytkowej;

vi. zaktualizowaną dokumentację 11. Realizacja Modyfikacji Systemu

1) Zamawiający może zlecić Wykonawcy Modyfikacje systemu, których pracochłonność liczona jest w wymiarze 12000 godzin w okresie trwania usługi wsparcia technicznego i serwisu.

2) Procedura zgłaszania zleceń Modyfikacji oraz kanały komunikacjia. Zgłoszenia Modyfikacji wykonywane będą za pośrednictwem za

pośrednictwem: i. systemu zgłoszeniowego ServiceDesk HPSM Ministerstwa

Sprawiedliwości udostępnionego przez Zamawiającego (podstawowy). W przypadku zgłoszeń typu Awaria, dodatkowo telefonicznie na całodobowy numer wskazany przez Wykonawcę.

ii. poprze email (dodatkowy,)iii. telefonicznie w tym na całodobowy numer wskazany przez

Wykonawcę (dodatkowy,)iv. za pośrednictwem innego systemu zgłoszeniowego wskazanego przez


Dodatkowe kanały komunikacji wykorzystywane będą po uzgodnieniu z Wykonawcą, w tym w przypadku niedostępności kanału podstawowego.


102


Zgłoszenia wykonane telefonicznie lub mailowo uzupełnione będą w systemie zgłoszeniowym, a obowiązywać będą rzeczywiste czasy zgłoszeń.

b. Zamawiający określa kryteria jakościowe produktów Modyfikacji w zgłoszeniu zlecenia Modyfikacji.

c. Strony ustalają w drodze porozumienia pracochłonność i termin wykonania Modyfikacji. Od momentu przedstawienia opisu Modyfikacji Wykonawca zobowiązany jest w ciągu nie więcej niż pięciu dni roboczych przedstawić szacowaną wycenę co do pracochłonności realizacji prac oraz terminu wykonania pod rygorem naliczenia kar umownych opisanych szczegółowo w Umowie.

d. Zamawiający potwierdza zlecenie Modyfikacji lub rezygnuje z niego.e. Potwierdzenie zlecenia Modyfikacji Systemu oznacza uzgodnienie przez strony

terminu wykonania Modyfikacji oraz jej pracochłonności. Datą od której jest liczony termin realizacji Modyfikacji jest datą potwierdzenia zlecenia. Zamawiający może wstrzymać wykonanie Modyfikacji ze względu na pojawienie się innych priorytetowych Modyfikacji lub ustanie potrzeby wykonania tej Modyfikacji.

f. Przed przystąpieniem do wykonania Modyfikacji Systemu, Wykonawca przedstawia Zamawiającemu do akceptacji projekt zmian z elementami wskazanymi przez Zamawiającego. Zamawiający dokona akceptacji projektu zmian lub zgłosi uwagi w terminie nie dłuższym niż 2 dni robocze od dnia przedstawienia projektu. W przypadku zgłoszenia uwag, Wykonawca przedstawi ponownie projekt do akceptacji w terminie nie dłuższym niż 2 dni robocze.

g. Wykonawca przystępuje do wykonania Modyfikacji po akceptacji projektu zmian przez Zamawiającego.

h. Po wykonaniu Modyfikacji Wykonawca przedstawia Zamawiającemu nową wersję aplikacji Systemu i/lub środowiska technologicznego Systemu wraz ze stosowną dokumentacją.

i. Zamawiający weryfikuje przekazaną wersję sprawdzając, czy w zmodyfikowanej nowej wersji aplikacji Systemu zostały uwzględnione wymagania określone na formularzu zgłoszenia oraz w zaakceptowanym przez Zamawiającego projekcie zmian, a także czy przekazana wersja nie zawiera błędów i dokumentacja jest kompletna.

j. Wyniki weryfikacji Zamawiający przekazuje Wykonawcy drogą elektroniczną w postaci raportu z testowania wersji.

k. W przypadku zgłoszenia zastrzeżeń przez Zamawiającego względem dostarczonej Modyfikacji, Wykonawca dokona stosownych poprawek. Po ponownym dostarczeniu przez Wykonawcę Modyfikacji zostanie przeprowadzony jej odbiór zgodnie z procedurą opisaną w pkt. h – j. Terminowa


103


realizacja Modyfikacji będzie dochowana pod warunkiem, że bezusterkowy odbiór nastąpi w terminie ustalonym zgodnie z pkt. c

l. W przypadku braku błędów uniemożliwiających poprawną i zgodną z określonymi kryteriami jakościowymi eksploatację zmodyfikowanej aplikacji Zamawiający dokonuje odbioru nowej wersji aplikacji.

m. Prawidłowość wykonania Modyfikacji zostanie potwierdzona podpisanym bez zastrzeżeń przez obie Strony Protokołem odbioru Modyfikacji

12. Procedura instalacji nowej wersji Systemu1) Każdorazowo w przypadku powstania nowej wersji Systemu, jej instalacja na

środowisku produkcyjnym następuje na zlecenie Zamawiającego.2) Wykonawca, przez czas trwania Umowy, będzie prowadził ewidencję dostarczanych

wersji Systemu, zawierającą:a. nazwa podsystemub. numer kolejny,c. numer wersji,d. datę zatwierdzenia wersji przez Zamawiającego / polecenie instalacji wersji,e. datę instalacji wersji,f. skrótowy opis zmian, które wersja uwzględnia,g. ewentualne uwagi.

3) Wykonawca przedstawia ewidencję, o której mowa w ust. 2 w cyklu kwartalnym w ciągu siedmiu dni roboczych po zakończeniu kwartału z pominięciem dni ustawowo wolnych od pracy, lub niezwłocznie na żądanie Zamawiającego, nie później niż w ciągu siedmiu dni roboczych z zaznaczeniem wersji dystrybuowanych w danym kwartale, w postaci elektronicznej i papierowej.

4) Wykonawca przeprowadzi aktualizację kodów źródłowych oprogramowania i ich wersjonowania co najmniej raz na kwartał. Aktualizacja musi zapewnić zgodność wersji oprogramowania zainstalowanego w infrastrukturze centralnej oraz u Użytkownika Końcowego z aktualną wersją kodu źródłowego.

5) Na koniec każdego kwartału oraz na żądanie Zamawiającego Wykonawca przedstawi pakiet obejmujący kody źródłowe programu oraz instrukcję kompilacji i konsolidacji poszczególnych elementów oprogramowania, a także wszystkie elementy dodatkowe służące kompilacji i konsolidacji, z uwzględnieniem wszystkich etapów tworzenia oprogramowania na założonej linii technologicznej.

13. Serwis infrastruktury serwerowejWsparcie serwisowe dla infrastruktury serwerowej, świadczone będzie od daty dostawy serwerów, w okresie świadczenia usługi Wsparcia technicznego i serwisu. Wsparcie serwisowe dla infrastruktury serwerowej obejmuje co najmniej:


104


1) wsparcie techniczne producenta w zakresie oferowanych komponentów infrastruktury serwerowej,

2) zintegrowane wsparcie proaktywne i reaktywne obejmujące sprzęt, system operacyjny,3) zapewnienie portalu obsługującego zgłoszenia serwisowe, 4) pomoc techniczną świadczoną w siedzibie Zamawiającego w trybie 24h/7d, włączając

dni wolne od pracy,5) 48 godzinny gwarantowany czas usunięcia awarii sprzętowej w siedzibie

Zamawiającego od momentu zgłoszenia, 6) nie dłuższą niż 4 godzinną reakcję na problemy z oprogramowaniem systemowym od

momentu zgłoszenia,7) świadczenie serwisu w miejscu instalacji sprzętu w przypadku problemów

technicznych, których nie można usunąć zdalnie,8) rekomendacje w zakresie dostępnych zmian w mikrokodach, sterownikach,

w przypadku oprogramowania oraz rekomendacje odnośnie poprawek i aktualizacji systemu operacyjnego, nowych wersji oprogramowania funkcjonalnego dostarczanego z produktem,

9) cykliczny (min. 2 razy w ciągu roku) audyt konfiguracji w celu optymalizacji wydajności systemu, określenia potencjalnych zagrożeń wynikających z konfiguracji sprzętu i oprogramowania objętego wsparciem,

10) zapewnienie części zamiennych dla sprzętu objętego wsparciem,11) raportowanie incydentów występujących w środowisku,12) procedury eskalacyjne,13) dostęp do aktualizacji oprogramowania i dokumentacji produktu objętego wsparciem,

14) zgłoszenia problemów w zakresie infrastruktury serwerowej wykonywane będą za pośrednictwem:

i. systemu zgłoszeniowego ServiceDesk HPSM Ministerstwa Sprawiedliwości udostępnionego przez Zamawiającego (podstawowy). W przypadku zgłoszeń typu Awaria, dodatkowo telefonicznie na całodobowy numer wskazany przez Wykonawcę.

ii. poprze email (dodatkowy,)iii. telefonicznie w tym na całodobowy numer wskazany przez Wykonawcę

(dodatkowy,)iv. za pośrednictwem innego systemu zgłoszeniowego wskazanego przez


Dodatkowe kanały komunikacji wykorzystywane będą po uzgodnieniu z Wykonawcą, w tym w przypadku niedostępności kanału podstawowego. Zgłoszenia wykonane telefonicznie lub mailowo uzupełnione będą w systemie zgłoszeniowym, a obowiązywać będą rzeczywiste czasy zgłoszeń.


105


14. Serwis platformy bazodanowej in-memory computingWsparcie serwisowe zapewniane dla platformy bazodanowej in-memory computing, świadczone od daty produkcyjnego uruchomienia systemu, musi obejmować co najmniej:

1) wsparcie techniczne producenta platformy w zakresie oferowanych komponentów programowych,

2) nowe wersje oprogramowania oraz narzędzia i procedury umożliwiające upgrade, 3) poprawki, w tym wymagane korekty dostosowujące istniejący zakres funkcji do

zmienionych wymagań prawnych i przepisów oraz narzędzia do instalowania poprawek,

4) aktualizacje technologiczne umożliwiające obsługę systemów operacyjnych podmiotów trzecich,

5) zarządzanie zmianami oprogramowania,6) zdalne usługi pomocy technicznej świadczonych przez programistów Wykonawcy

w wymiarze 40 h w każdym roku kalendarzowym,7) zapewnienie dostępu do bazy wiedzy dot. systemu oraz udostępnianie najlepszych

praktyk administracji systemem oraz korzystania z dostarczonego rozwiązania,8) usługę zdalnej kontroli i analizy planowanych lub istniejących Modyfikacji oraz

identyfikacja możliwych konfliktów między kodem Zamawiającego, a pakietami rozszerzeń i innymi aktualizacjami systemu. Zamawiający wymaga zapewnienia 2 takich usług w każdym roku kalendarzowym,

9) zapewnienie portalu obsługującego zgłoszenia serwisowe,10) obsługę zgłoszeń serwisowych oraz analizę przyczyn zidentyfikowanych problemów

w trybie 24h/7d, włączając dni wolne od pracy, 11) nie dłuższą niż 1 godzinną reakcję od momentu zgłoszenia awarii,12) zapewniony gwarantowany czas usuwania awarii (lub dostarczenia obejścia awarii)

w czasie nie dłuższym niż 4h od momentu zgłoszenia,

13) Zgłoszenia serwisowe platformy bazodanowej in-memory computing wykonywane będą za pośrednictwem:

i. systemu zgłoszeniowego ServiceDesk HPSM Ministerstwa Sprawiedliwości udostępnionego przez Zamawiającego (podstawowy). W przypadku zgłoszeń typu Awaria, dodatkowo telefonicznie na całodobowy numer wskazany przez Wykonawcę.

ii. poprze email (dodatkowy,)iii. telefonicznie w tym na całodobowy numer wskazany przez Wykonawcę

(dodatkowy,)iv. za pośrednictwem innego systemu zgłoszeniowego wskazanego przez

Zamawiającego (dodatkowy).Dodatkowe kanały komunikacji wykorzystywane będą po uzgodnieniu z Wykonawcą, w tym w przypadku niedostępności kanału podstawowego. Zgłoszenia wykonane


106


telefonicznie lub mailowo uzupełnione będą w systemie zgłoszeniowym, a obowiązywać będą rzeczywiste czasy zgłoszeń.

14) okresową kontrolę parametrów jakościowych działania rozwiązania – co najmniej raz w roku kalendarzowym.

15. Informacje o utrzymaniu systemu oraz dane ilościowe dotyczące obsługi zgłoszeń serwisowych

Wykonawca utrzymania systemu odpowiedzialny jest za realizację III linii wsparcia. Analiza zgłoszeń wskazuje, że najczęściej realizowanymi zadaniami są: przywrócenie działania importerów, usuwanie błędów, ustalanie przyczyn braków w publikacjach w zakresie, który nie może zostać zrealizowany przez I i II linię wsparcia.Odnotowywanych jest rocznie ok. 30 000 zgłoszeń serwisowych, z których ok. 10 000 realizowanych jest przez wykonawcę utrzymania systemu (III linia wsparcia). Podane wartości zgłoszeń są wartościami orientacyjnymi na podstawie dotychczasowych działań utrzymaniowych liczonych w okresie 12 m-cy.

8.3 [Dostępność systemu]Wykonawca gwarantuje dostępność Systemu (rozumianą jako czas działania Systemu bez Awarii i Błędu krytycznego na poziomie co najmniej 99,98% w miesiącu kalendarzowym.Kalendarz dostępności Systemu – 24 godziny na dzień, 7 dni w tygodniu, 365 dni w roku, 366 dni w roku przestępnym.Do gwarantowanego poziomu dostępności Systemu nie jest wliczana niedostępność wynikająca uzgodnionych okien serwisowych oraz z przyczyn leżących po stronie Zamawiającego polegająca na zatrzymaniu lub zakłóceniu pracy Systemu, spowodowana awarią infrastruktury technicznej zamawiającego (z wyłączeniem tych elementów infrastruktury, które dostarczył Wykonawca w ramach Umowy), w tym awarią łączy teletransmisyjnych, awarią sprzętu komputerowego, awarią zasilania lub brakiem danych niezbędnych do odtworzenia Systemu w zakresie leżącym po stronie Zamawiającego wynikającym z procedur wykonywania kopii zapasowych projektu technicznego.

Poziom dostępności Systemu obliczany jest wg wzoru:(TD – Σ TN) / TD*100% [%]

Gdzie: TD – określony czas dostępności Systemu w okresie miesiąca kalendarzowego wynikający z Kalendarza dostępności Systemu po odjęciu uzgodnionych ograniczeń dostępności usługi (okien serwisowych) oraz niedostępności wynikających z przyczyn leżących po stronie Zamawiającego, Σ TN – suma czasów niedostępności Systemu w okresie miesiąca, gdzie czasem niedostępności Systemu jest czas, w którym w Systemie występuje Błąd w kategorii: Awaria lub Błąd krytyczny.

15)


107

Załączniki:Załącznik nr 1 Wykaz aktów prawnychZałącznik nr 2 Opis interfejsówZałącznik nr 3 Formaty plików transkrypcjiZałącznik nr 4 Kryteria odbioru produktów i procedury odbioroweZałącznik nr 5 Wykorzystana technologia w obecnie działającym SystemieZałącznik nr 6 Wzory dokumentów


Załącznik nr … do OPZ nr …... z dnia ...................... – „Produkty i kryteria odbioru” (OPZ)

Załącznik nr 1 Wykaz aktów prawnych

Dostarczony, wdrożony i uruchomiony produkcyjnie przez Wykonawcę system musi w sposób ciągły spełniać wymagania obowiązujących przepisów prawa w zakresie rzeczowym i informacyjnym w poszczególnych obszarach funkcjonalnych/zadaniowych działania systemu w organizacji Zamawiającego. W szczególności powyższe dotyczy takich przepisów prawa jak:

Ustawa z dnia 27 sierpnia 2009 r. o finansach publicznych (Dz.U. 2009 nr 157 poz. 1240 z późn. zm.) oraz wydane na podstawie wskazanej ustawy rozporządzenia wykonawcze,

Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne ( Dz.U. 2005 nr 64 poz. 565 z późn. zm.),

Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. 2012 poz. 526 z późn. zm.),

Rozporządzenie Prezesa Rady Ministrów z dnia 14 września 2011 r. w sprawie sporządzania pism w formie dokumentów elektronicznych, doręczania dokumentów elektronicznych oraz udostępniania formularzy, wzorów i kopii dokumentów elektronicznych (Dz.U. 2011 nr 206 poz. 1216 z późn. zm.),

Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r. w sprawie szczegółowego sposobu postępowania z dokumentami elektronicznymi (Dz.U. Nr 206, poz. 1518),

Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 2 listopada 2006 r. w sprawie wymagań technicznych formatów zapisu i informatycznych nośników danych, na których utrwalono materiały archiwalne przekazywane do archiwów państwowych (Dz.U. 2006 nr 206 poz. 1519),

Rozporządzenie Prezesa Rady Ministrów z dnia 18 stycznia 2011 r. w sprawie instrukcji kancelaryjnej, jednolitych rzeczowych wykazów akt oraz instrukcji w sprawie organizacji i zakresu działania archiwów zakładowych (Dz.U. 2011 nr 14 poz. 67),

Rozporządzenie Ministra Nauki i Informatyzacji z dnia 19 października 2005 r w sprawie testów akceptacyjnych oraz badania oprogramowania interfejsowego i weryfikacji tego badania (Dz.U. 2005 nr 217 poz. 1836),

Rozporządzenie Rady Ministrów z dnia 27 września 2005 r. w sprawie sposobu, zakresu i trybu udostępniania danych zgromadzonych w rejestrze publicznym (Dz.U. 2005 nr 205 poz. 1692),

Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r. w sprawie niezbędnych elementów struktury dokumentów elektronicznych (Dz.U. 2006 nr 206 poz. 1517),


109


Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych. (Dz.U. 1997 nr 133 poz. 883 z późn. zm.),

Rozporządzenie 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 (Dz.U. 2004 nr 100 poz. 1024),

Rozporządzenie Ogólne o Ochronie Danych Osobowych (RODO) – obowiązujące od 25 maja 2018 tj. Rozporządzenie 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,

Rozporządzenie Ministra Cyfryzacji z dnia 5 października 2016 r. w sprawie szczegółowych warunków organizacyjnych i technicznych, które powinien spełniać system teleinformatyczny służący do uwierzytelniania użytkowników (Dz.U. 2016 poz. 1627),

Rozporządzenie Ministra Administracji I Cyfryzacji z dnia 11 maja 2015 roku w sprawie sposobu prowadzenia przez administratora bezpieczeństwa informacji rejestru zbiorów danych (Dz. U. 2015, poz. 719),

Ustawa z dnia 17 listopada 1964 r. - Kodeks postępowania cywilnego. (Dz.U. 1964 nr 43 poz. 296 z późn. zm.),

Ustawa z dnia 23 kwietnia 1964 r. – Kodeks postępowania cywilnego (Dz. U. z 2014 r. poz. 121 ze zm.),

Ustawa z dnia 24 sierpnia 2001 r - Kodeks postępowania w sprawach o wykroczenia (Dz.U. z 2013 r. poz. 395 z późn. zm.),

Ustawy z dnia 6 czerwca 1997 r. – Kodeks karny (Dz. U. 88, poz. 553, ze zm.),

Ustawy z dnia 6 czerwca 1997 r. – Kodeks karny wykonawczy (Dz. U. 90, poz. 557, ze zm.),

Ustawy z dnia 26 października 1982 r. o postępowaniu w sprawach nieletnich (Dz. U.z 2014 r. poz.382 ze zm.),

Ustawy z dnia 5 sierpnia 2010r. o ochronie informacji niejawnych (Dz. U. z 2010r. Nr 182, poz. 1228, ze zm.),

Ustawy z dnia 26 czerwca 1974 r. – Kodeks pracy (Dz. U. z 1998 r. Nr 21, poz. 94 ze zm.),

Rozporządzenie Ministra Sprawiedliwości z dnia 23 grudnia 2015 r. w sprawie regulaminu urzędowania sądów powszechnych (Dz. U. z 2015 r. poz. 2316 ze zm.),

Zarządzenie Ministra Sprawiedliwości z dnia 12 grudnia 2003 r. w sprawie organizacji i zakresu działania sekretariatów sądowych oraz innych działów administracji sądowej (Dz. Urz. MS z 2003 r. Nr 5, poz. 22 ze zm.),

Ustawa z dnia 27 lipca 2001 r. Prawo o ustroju sądów powszechnych. (Dz.U. 2001 nr 98 poz. 1070 z późn. zm.) oraz wydane na podstawie art. 41 §1przywoływanej ustawy


110


Rozporzadzenie Ministra Sprawiedliwości z dnia 23 lutego 2007 r. Regulamin urzędowania sądów powszechnych (tj. Dz. U. z 2014 r., poz 289 ze zm.),

Ustawy z dnia 27 lipca 2001 r. o ochronie baz danych (Dz. U. Nr 128, poz 1402, ze zm.),

Rozporządzenie Ministra Sprawiedliwości z dnia 6 listopada 2014 r. w sprawie udostępniania stronom, obrońcom, pełnomocnikom i przedstawicielom ustawowym zapisu dźwięku albo obrazu i dźwięku z rozprawy w postępowaniu w sprawach o wykroczenia oraz wysokości opłaty za wydanie tego zapisu (Dz.U. 2014 poz. 1548),

Rozporządzenie Ministra Sprawiedliwości z dnia 2 marca 2015 r. w sprawie zapisu dźwięku albo obrazu i dźwięku z przebiegu posiedzenia jawnego w postępowaniu cywilnym (Dz.U. 2015 poz. 359),

Ustawa z dnia 5 września 2016 r. o usługach zaufania oraz identyfikacji elektronicznej (Dz.U. 2016 poz. 1579).

Ustawa z dnia 28 listopada 2014 r. o ochronie i pomocy dla pokrzywdzonego i świadka (Dz.U. 2015 poz. 21)


111


Załącznik nr 2 Opis interfejsów

Interfejsy opisane w poniższej tabeli SĄ objęte niniejszym zamówieniem.

Interfejs dostarczany przez PI

ConfirmReadingRoomReservation Potwierdzenie rezerwacji miejsca w czytelni dla użytkownika

RCS -> PI

Numer wniosku (tekst/liczba)

Decyzja (boolean) Uzasadnienie

(tekst) Najbliższe

terminy (data – lista)

Potwierdzenie przyjęcia (boolean)

SendASRTranscription Przesłanie wyniku automatycznej transkrypcji

RCS -> PI


Pliki autotranskrypcji (plik)

Dane o jakości transkrypcji (tekst/liczba)


ConfirmRemoteHearing Powiadomienie o decyzji dot. rozprawy odmiejscowionejRCS -> PI


Decyzja (boolean) Uzasadnienie

(tekst)


SendStreamingParameters Przekazanie parametrów do ustawienia odbioru strumieniaRCS -> PI


Parametry (tekst/xml)



112


Interfejsy opisane w poniższej tabeli NIE są objęte niniejszym zamówieniem – zapewnione zostaną przez Zamawiającego w ramach realizacji innych zamówień dot. zmian wprowadzanych do systemów RCS, CRCS.

Nazwa metody Opis Parametry wejściowe (typ danych)

Parametry wyjściowe (typ danych)

Interfejs dostarczany przez CRCS

GetPathVideo Pobranie ścieżki do pliku wideo

PI -> CRCS

Sąd (tekstowe) Wydział (tekstowe) Sygnatura akt

(tekstowe) Data posiedzenia

(data) Imię (tekst) Nazwisko (tekst) PESEL

/identyfikator(liczba)

Ścieżka do pliku wideo (tekstowe)

Czy błąd (boolean)

Komunikat o błędzie/braku możliwości udostępnienia (tekst)

GetPathProtocol Pobranie ścieżki do plików e-protokołu

PI -> CRCS

Sąd (tekst) Wydział (tekst) Sygnatura akt (tekst) Data posiedzenia



Ścieżka do wnioskowanych plików (tekstowe)

Czy błąd (boolean)

Komunikat o błędzie/braku możliwości udostępnienia (tekst)

Interfejs dostarczany przez CAPE

GetVideo Pobranie pliku wideo według wskazanej ścieżki

PI -> CAPE

Ścieżka (tekst) Plik (plik)

GetProtocol Pobranie plików e-protokołu wg. wskazanej ścieżki

PI -> CAPE

Ścieżka (tekst) Pliki (plik)

Interfejs dostarczany przez RCS

GetReadingRoomCalendar Żądanie podania kalendarza zajętości czytelni

PI -> RCS

Sąd (tekst) Data od (data) Data do (data)

Kalendarz dla danego okresu (xml)

SendReadingRoomApplication Wniosek o Sąd (tekst) Numer wniosku


113


rezerwację miejsca w czytelni

PI -> RCS

Data rezerwacji (data)

Szacowany czas (liczba)

Imię (tekst) Nazwisko (tekst) PESEL/identyfikator

(liczba) Lista zawierająca

wiele instancji:o Sygnatura akt

(tekst)o Data posiedzenia

(data)o Oznaczenie

wydziału (tekst)o Rola w sprawie

(tekst)o Oznaczenie czy

udostępnić akta sprawy (boolean)

o Oznaczenie czy udostępnić e-protokół (boolean)

(tekst/liczba)

CancelReadingRoomReservation Odwołanie rezerwacji miejsca w czytelni

PI -> RCS


Rezygnacja (boolean)


GetApplicationStatus Ustalanie statusu obsługi złożonego uprzednio wniosku

PI -> RCS


Status wniosku (tekst)

SendASRProtocol Wniosek wykonania automatycznej transkrypcji

e-protokołu

PI -> RCS


(data) Imię (tekst) Nazwisko (tekst) PESEL/identyfikator

(liczba) Czas od (liczba) Czas do (liczba)


Czas oczekiwania (liczba)Lub

Odmowa (boolean)

Powód (tekst)

SendASRSentence Wniosek wykonania automatycznej transkrypcji



Czas oczekiwania


114


e-uzasadnienia

PI -> RCS

(data) Imię (tekst) Nazwisko (tekst) PESEL/identyfikator

(liczba)

(liczba)Lub

Odmowa (boolean)

Powód (tekst)

SendRemoteHearingApplication Przesłanie wniosku o rozprawę odmiejscowioną

PI -> RCS

Wniosek (plik xml) Podpis wniosku

(plik)


SendStreamingApplication Przesłanie wniosku o strumieniowanie posiedzenia

PI -> RCS

Sąd (tekst) Sygnatura akt (tekst) Data posiedzenia




API dla bramki SMS dostępne na stronie http://www.smseagle.eu/api/?lang=pl


115


Załącznik nr 3 Formaty plików transkrypcji

xml – musi:o zapewniać wsparcie dla późniejszych procesów korekcyjnych w edytorze,

zawierać informacje dot. pewności rozpoznania, znakować każde słowo/frazę stemplem czasowym, znakować mówców itp.

o być zgodny z obecnym formatem adnotacji przewidzianym dla ReCourt Playera uzupełniając go w szczególności o oznaczenia związane z transkrypcją:

a) czas zmiany osoby mówiącej <Transcript Time=”PTmmMss.msmsS”>b) rola osoby mówiącej np.:

<Role>SEDZIA_PRZEWODNICZACY</Role> lub <Function>POWOD</Function>

c) identyfikacja osoby mówiącej: <Person><Name>Imię</Name><Surname>Nazwisko</Surname></Person>

d) tekst jest podzielony na słowa/frazy <Phrase>słowo/fraza</Phrase>

e) określona jest miara pewności rozpoznania każdego słowa/frazy <Phrase Confidence="liczba"> - możliwe wartości liczby: od 0,00 do 1,00.

f) czas wystąpienia słowa/frazy <Phrase Time=”PTmmMss.msmsS”>

rtf – musi zawierać tekstowy zapis transkrypcji zgodnie z obowiązującym szablonem transkrypcji, zawierającym w szczególności oznaczenia w zakresie: znacznika czasowego, roli, osoby mówiącej i treści wypowiedź, zgodnie z poniższym formatem:Tekst …[Rola Imię Nazwisko hh:mm:ss]Tekst …


116


Załącznik nr 4 Kryteria odbioru produktów projektu i procedury odbiorowe

Spis treści1. PRODUKTY PROJEKTU.........................................................................................................113

1.1 STRUKTURA PRODUKTÓW I KRYTERIA ODBIORU.............................................................113

1.2 ZARZĄDZANIE PROJEKTEM..............................................................................................154

1.2.1 OGÓLNE WYMAGANIA W ZAKRESIE ZARZĄDZANIA PROJEKTEM......................................154

1.2.2 STRUKTURA PROJEKTOWA..............................................................................................156

1.2.3 KOMITET STERUJĄCY.......................................................................................................157

1.2.4 ZARZĄD PROJEKTU..........................................................................................................158

1.2.5 DORADCA TECHNOLOGICZNY..........................................................................................160

1.2.6 PROCEDURY ODBIORCZE.................................................................................................161

1.2.6.1 UPROSZCZONA PROCEDURA ODBIORU...........................................................................161

1.2.6.2 PROCEDURA PRZEKAZANIA PRODUKTÓW.......................................................................163

1.2.6.3 PROCEDURA ODBIORU DOKUMENTACJI..........................................................................164

1.2.6.4 PROCEDURA ODBIORU SZKOLEŃ.....................................................................................166

1.2.6.5 PROCEDURA ODBIORU OPROGRAMOWANIA..................................................................167

1.2.6.6 PROCEDURA ODBIORU SPRZĘTU.....................................................................................170

1.2.6.7 PROCEDURA ODBIORU WDROŻENIA...............................................................................171

1.2.6.8 PROCEDURA ODBIORU ETAPU.........................................................................................172

1.2.6.9 PROCEDURY KONTROLI JAKOŚCI PRAC............................................................................172


117


1. Produkty projektu

1.1 Struktura produktów i kryteria odbioru

Etap Produkt /Procedura odbioru

Kryteria odbioru

Etap I. Inicjacja projektu

Produkty specjalistyczne:Brak Brak

Produkty zarządcze:Dokument „Dokumentacja zarządcza”

Procedura odbioru dokumentacji

Zgodność z wzorem dokumentu „Dokument zarządczy” (Załącznik nr P.03. do OPZ),

Zgodność z wymaganiami opisanymi niniejszym Załączniku w sekcji 1.2.1 „Ogólne wymagania w zakresie zarządzania projektem”,

Zgodność z wymaganiami ogólnymi względem dokumentacji opisanymi w Rozdziale VI.7 OPZ w sekcji „Wymagania ogólne dotyczące dokumentacji”,

Uwzględnienie norm opisanych w Rozdziale VI.3.6. OPZ w sekcji „Wymagane zgodności z normami”,

Zgodność z ostatecznymi ustaleniami zapisanymi w protokołach ze spotkań (o ile w związku z pracami nad dokumentem przeprowadzano spotkania),

Zgodność z zaleceniami zawartymi w przeglądach jakości dokumentu „Dokumentacja Zarządcza”,

Pozytywny wynik ostatniego przeglądu jakości dla dokumentu „Dokumentacja Zarządcza”,


118

Załącznik nr … do OPZ nr …... z dnia ...................... – „Produkty i kryteria odbioru” (OPZ)Etap Produkt /

Procedura odbioruKryteria odbioru

Brak tematów otwartych dla dokumentów „Dokumentacja Zarządcza”.

Dokument „Szczegółowy Harmonogram Prac”


Opracowanie harmonogramu zgodnie z metodyką Gantta, Zgodność z ogólnymi terminami i uregulowaniami wynikającymi z

zawartej umowy, Zgodność z wymaganiami ogólnymi względem dokumentacji

opisanymi w Rozdziale VI.7 OPZ w sekcji „Szczegółowy Harmonogram Prac”,

Szczegółowość pozwalająca na powiązanie zadań z produktami, Zgodność z zaleceniami zawartymi w przeglądach jakości

„Szczegółowego Harmonogramu Prac”, Pozytywny wynik ostatniego przeglądu jakości dla „Szczegółowego

Harmonogramu Prac”, Brak tematów otwartych dla „Szczegółowego Harmonogramu

Prac”.Agendy spotkań Etapu I

Uproszczona procedura odbioru

Zgodność z wzorem dokumentu „Agenda Spotkania” (Załącznik nr P.01. do OPZ),

Opracowanie dokumentów dla wszystkich przeprowadzonych spotkań,

Podpisanie kopii dokumentów przez odpowiednie osoby (weryfikowane w ramach Procedury odbioru Etapu).

Protokoły ze spotkań Etapu I


Zgodność z wzorem dokumentu „Protokół ze Spotkania” (Załącznik nr P.02. do OPZ),




119



Raporty przeglądu jakości dokumentu „Dokumentacja Zarządcza”


Zgodność z wzorem dokumentu „Raport z Przeglądu Jakości” (Załącznik nr K.03. do OPZ),

Opracowanie dokumentów dla wszystkich przeprowadzonych przeglądów jakości,


Raporty przeglądu jakości „Szczegółowego Harmonogramu Prac”


Zgodność z wzorem dokumentu „Raport Przeglądu Jakości” (Załącznik nr K.03. do OPZ),



Protokoły przekazania dokumentów „Dokumentacji Zarządczej” i „Szczegółowego Harmonogramu Prac”


Zgodność z wzorem dokumentu „Protokół przekazania” (Załącznik nr U.02. do Umowy),

Opracowanie protokołu dla dokumentów „Dokumentacja Zarządcza” i „Szczegółowego Harmonogramu Prac”,



120



Protokoły odbioru dokumentów „Dokumentacji Zarządczej” i „Szczegółowego Harmonogramu Prac”


Zgodność z wzorem dokumentu „Protokół odbioru” (Załącznik nr U.01. do Umowy),

Opracowanie protokołu dla dokumentów „Dokumentacja Zarządcza” i „Szczegółowego Harmonogramu Prac”,


Raporty okresowe Etapu


Zgodność z wzorem dokumentu „Raport za okres” (Załącznik nr U.04. do Umowy),

Opracowanie raportów za cały okres etapu, Ujęcie w raportach wszystkich spotkań, Brak zastrzeżeń do przedstawionych dokumentów w wersji

ostatecznej, Podpisanie kopii dokumentów przez odpowiednie osoby

(weryfikowane w ramach Procedury odbioru Etapu).Rejestr wymagań Etapu I


Zgodność z wzorem dokumentu „Rejestr wymagań” (Załącznik nr P.16. do OPZ),

Odniesienie do wszystkich wymagań funkcjonalnych i niefunkcjonalnych zapisanych w OPZ,

Odniesienie do wszystkich zagadnień podniesionych w trakcie spotkań.

Uwaga:


121



Dla poszczególnych wymagań NIE MUSZĄ być wskazane scenariusze testowe.

Rejestr jakości Etapu I


Zgodność z wzorem dokumentu „Rejestr jakości projektu” (Załącznik nr K.04. do OPZ),

Uwzględnienie wszystkich przeprowadzonych przeglądów jakości.

Rejestr konfiguracji Etapu I


Zgodność z wzorem dokumentu „Rejestr Konfiguracji” (Załącznik nr P.12. do OPZ),

Uwzględnienie wszystkich wersji dokumentów „Analiza biznesowa i systemowa” i „Dokumentacja Zarządcza”.

Uwaga: Dla dokumentów NIE MUSZĄ być wskazywane konfiguracje.

Rejestr ryzyk Etapu I


Zgodność z wzorem dokumentu „Rejestr ryzyk” (Załącznik nr P.14. do OPZ),

Uwzględnienie wszystkich ryzyk zgłaszanych w ramach raportów okresowych,

Uwzględnienie wszystkich przeprowadzonych ocen ryzyka.Rejestr tematów otwartych Etapu I


Zgodność z wzorem dokumentu „Rejestr Tematów Otwartych” (Załącznik nr P.15. do OPZ),

Uwzględnienie wszystkich zagadnień zgłaszanych w ramach raportów okresowych (na podstawie raportów okresowych),

Uwzględnienie wszystkich zagadnień zgłaszanych w ramach spotkań (na podstawie protokołów ze spotkań).


122



Rejestr materiałów projektowych Etapu I


Zgodność z wzorem dokumentu „Rejestr Materiałów Projektowych” (Załącznik nr P.13. do OPZ),

Uwzględnienie wszystkich przekazywanych i wnioskowanych dokumentów,

Uwzględnienie wszystkich dokumentów wspomnianych w raportach okresowych (na podstawie raportów okresowych),

Uwzględnienie wszystkich dokumentów wspomnianych w trakcie spotkań (na podstawie protokołów ze spotkań).

Rejestr zmian Etapu I


Zgodność z wzorem dokumentu „Rejestr zmian” (Załącznik nr P.17. do OPZ),

Uwzględnienie wszystkich zmian zgłaszanych w ramach raportów okresowych.

Uwaga: Rejestr zmian może pozostać pusty, jednak w takim wypadku w

historii dokumentu należy w opisie zmian wnieść odpowiednią adnotację.

Etap II. Analiza biznesowa i systemowa

Produkty specjalistyczne:Dokument „Analiza biznesowa i systemowa”


Zgodność z wzorem dokumentu „Analiza biznesowa i systemowa” (Załącznik nr S.01. do OPZ),

Zgodność z wymaganiami ogólnymi względem dokumentacji opisanymi w Rozdziale VI.1 OPZ w punkcie „Przeprowadzenie Analizy Biznesowej i Systemowej”,

Zgodność z wymaganiami ogólnymi względem dokumentacji opisanymi w Rozdziale VI.7 OPZ w punkcie „Wymagania ogólne dot. dokumentacji”,

Uwzględnienie norm opisanych w Rozdziale VI.3.6. OPZ w sekcji


123



„Wymagane zgodności z normami”, Zgodność z wymaganiami ogólnymi względem dokumentacji

opisanymi w Załączniku nr 1 „Wykaz aktów prawnych”, Odniesienie do wszystkich wymagań funkcjonalnych i

niefunkcjonalnych zapisanych w OPZ, Zgodność z ostatecznymi ustaleniami zapisanymi w protokołach ze

spotkań, Zgodność z zaleceniami zawartymi w przeglądach jakości

dokumentu „Analiza biznesowa i systemowa”, Pozytywny wynik ostatniego przeglądu jakości dla dokumentu

„Analiza biznesowa i systemowa”, Brak tematów otwartych dla dokumentu „Analiza biznesowa i

systemowa”.Produkty zarządcze:

Agendy spotkań Etapu I





Protokoły ze spotkań Etapu II






124



Raporty przeglądu jakości dokumentu „Analiza biznesowa i systemowa”





Protokół przekazania dokumentu „Analiza biznesowa i systemowa”


Zgodność z wzorem dokumentu „Protokół Przekazania” (Załącznik nr U.02. do Umowy),

Opracowanie protokołu dla dokumentów „Dokumentu zarządczego” i „Szczegółowego Harmonogramu Prac”,


Protokół odbioru dokumentu „Analiza biznesowa i systemowa”


Zgodność z wzorem dokumentu „Protokół Odbioru” (Załącznik nr U.01. do Umowy),

Opracowanie protokołu dla dokumentu „Analiza biznesowa i systemowa”


Raporty okresowe Etapu II

Zgodność z wzorem dokumentu „Raport za Okres” (Załącznik nr U.04. do Umowy),

Opracowanie raportów za cały okres etapu,


125




Ujęcie w raportach wszystkich spotkań, Brak zastrzeżeń do przedstawionych dokumentów w wersji


(weryfikowane w ramach Procedury odbioru Etapu).Rejestr wymagań Etapu II


Zgodność z wzorem dokumentu „Rejestr Wymagań” (Załącznik nr P.16. do OPZ),



Uwaga: Dla poszczególnych wymagań NIE MUSZĄ być wskazane

scenariusze testowe.Rejestr jakości Etapu II


Zgodność z wzorem dokumentu „Rejestr Jakości Projektu” (Załącznik nr K.04. do OPZ),

Uwzględnienie dla wszystkich przeprowadzonych przeglądów jakości.

Rejestr konfiguracji Etapu II



Uwzględnienie dla wszystkich wersji dokumentu „Analiza biznesowa i systemowa”


126



Uwaga: Dla dokumentów NIE MUSZĄ być wskazywane konfiguracje.

Rejestr ryzyk Etapu II


Zgodność z wzorem dokumentu „Rejestr Ryzyk” (Załącznik nr P.14. do OPZ),


Uwzględnienie dla wszystkich przeprowadzonych ocen ryzyka.Rejestr tematów otwartych Etapu II





Rejestr materiałów projektowych Etapu II






Rejestr zmian Etapu II


Zgodność z wzorem dokumentu „Rejestr Zmian” (Załącznik nr P.17. do OPZ),



127




historii dokumentu należy w opisie zmian wnieść odpowiednią adnotację.

Etap III. Projektowanie systemu

Produkty specjalistyczne:Dokument „Projekt techniczny”


Zgodność z wzorem dokumentu „Projekt Techniczny” (Załącznik nr S.02. do OPZ),,

Zgodność przeprowadzanych prac z wymaganiami opisanymi w Rozdziale VI.2. „Projekt Techniczny i Projekt Graficzny”,

Zgodność z wymaganiami ogólnymi względem dokumentacji opisanymi w Rozdziale VI.7 OPZ w punkcie „Wymagania ogólne dot. dokumentacji”,

Uwzględnienie norm opisanych w Rozdziale VI.3.6. OPZ w sekcji „Wymagane zgodności z normami”,

Zgodność z wymaganiami ogólnymi względem dokumentacji opisanymi w Załącznik nr 1 „Wykaz aktów prawnych”,


Zgodność projektu infrastruktury sprzętowej z wytycznymi opisanymi w Rozdziale VI.4. OPZ

Zgodność z ostatecznymi ustaleniami zapisanymi w protokołach ze spotkań,

Zgodność z zaleceniami zawartymi w przeglądach jakości dokumentu „Projekt techniczny”,

Pozytywny wynik ostatniego przeglądu jakości dla dokumentu „Projekt techniczny”,

Brak tematów otwartych dla dokumentu „Projekt techniczny”.


128



Produkty zarządcze:

Agendy spotkań Etapu III





Protokoły ze spotkań Etapu II





Raporty przeglądu jakości dokumentu „Projekt techniczny”





Protokoły przekazania dokumentu „Projekt techniczny”


Opracowanie protokołu dla dokumentu „Projekt techniczny”, Podpisanie kopii dokumentów przez odpowiednie osoby

(weryfikowane w ramach Procedury odbioru Etapu).


129



Uproszczona procedura odbioruProtokół odbioru dokumentu „Projekt techniczny”



Opracowanie protokołu dla dokumentu „Projekt techniczny”, Podpisanie kopii dokumentów przez odpowiednie osoby


Raporty okresowe Etapu III





(weryfikowane w ramach Procedury odbioru Etapu).Rejestr wymagań Etapu III





Uwaga:


130



Dla poszczególnych wymagań NIE MUSZĄ być wskazane scenariusze testowe.

Analizie podczas odbioru podlegają wymagania będące przedmiotem prac etapu.

Rejestr jakości Etapu III




Rejestr konfiguracji Etapu III



Uwzględnienie dla wszystkich wersji dokumentu „Projekt Techniczny”

Uwaga: Dla dokumentów NIE MUSZĄ być wskazywane konfiguracje, Analizie podczas odbioru podlegają wymagania będące produktem

etapu.Rejestr ryzyk Etapu IIIUproszczona procedura odbioru



Uwzględnienie wszystkich przeprowadzonych ocen ryzyka.Rejestr tematów otwartych Etapu III


Uwzględnienie wszystkich zagadnień zgłaszanych w ramach


131




raportów okresowych (na podstawie raportów okresowych), Uwzględnienie wszystkich zagadnień zgłaszanych w ramach

spotkań (na podstawie protokołów ze spotkań).

Rejestr materiałów projektowych Etapu III






Uwaga: Analizie podczas odbioru podlegają materiały będące przedmiotem

prac etapu.Rejestr zmian Etapu III





historii dokumentu należy w opisie zmian wnieść odpowiednią adnotację,

Analizie podczas odbioru podlegają zmiany będące przedmiotem prac etapu.


132



Etap IV. Dostawa, instalacja i konfiguracja sprzętu

Produkty specjalistyczne:Dostawa i instalacja sprzętu

Procedura odbioru sprzętu

Zgodność z założeniami opisanymi w „Projekcie Technicznym”, Zgodności Infrastruktury z wymaganiami wskazanymi w OPZ, Kompletności sprzętu i dokumentów licencyjnych i technicznych, Zgodność ilościowa i jakościowa dostawy, Prawidłowość działania sprzętu i jego stanu technicznego, w tym

zgodność wyposażenia i konfiguracji, Prawidłowość dokonanego montażu i instalacji sprzętu.

Produkty zarządcze:

Agendy spotkań Etapu IV





Protokoły ze spotkań Etapu IV





Protokoły przekazania sprzętu

Uproszczona




133



procedura odbioruProtokoły odbioru sprzętu


Zgodność z wzorem dokumentu „Protokół Odbioru Sprzętu” (Załącznik nr U.05. do Umowy),


Raporty okresowe Etapu IV





(weryfikowane w ramach Procedury odbioru Etapu).Rejestr wymagań Etapu IV





Uwaga: Dla poszczególnych wymagań MUSZĄ być wskazane scenariusze

testowe. Analizie podczas odbioru podlegają wymagania będące


134



przedmiotem prac etapu.Rejestr jakości Etapu IV




Rejestr konfiguracji Etapu IV




etapu.Rejestr ryzyk Etapu IV




Uwzględnienie wszystkich przeprowadzonych ocen ryzyka.

Rejestr tematów otwartych Etapu IV






135



Rejestr materiałów projektowych Etapu IV






Uwaga: Dla dokumentów NIE MUSZĄ być wskazywane konfiguracje, Analizie podczas odbioru podlegają materiały będące przedmiotem

prac etapu.Rejestr zmian Etapu IV



Uwzględnienie wszystkich zmian zgłaszanych w ramach raportów okresowych,




Etap V. Produkty specjalistyczne:


136



Wytworzenie i modernizacja oprogramowania

Oprogramowanie w wersji testowej

Procedura odbioru dokumentacji1

Zgodność kodów źródłowych oprogramowania z wytycznymi zawartymi w Rozdziale VI. 3.6 OPZ w sekcji „Ogólne wymaganie względem kodów źródłowych”.

Zgodność z ustalonym standardem kodów źródłowych opisanych w „Projekcie technicznym”,

Pozytywny wynik „Raportu z testów wewnętrznych oprogramowania” przeprowadzonych przez Wykonawcę,

Zgodność z zaleceniami zawartymi w przeglądach jakości produktu „Oprogramowanie w wersji testowej”,

Pozytywny wynik ostatniego przeglądu jakości dla produktu „Oprogramowanie w wersji testowej”,

Brak tematów otwartych dla produktu „Oprogramowanie w wersji testowej”.

Produkty zarządcze:Scenariusze testowe


Zgodność z wzorem dokumentu „Scenariusze Testowe” (Załącznik nr K.01. do OPZ),

Uwzględnienie wszystkich wymagań w „Rejestrze wymagań”, Uwzględnienie wszystkich kwestii objętych „Projektem

technicznym”, Zgodność z wymaganiami opisanymi w Rozdziale VI.5 w sekcji

Testy Zgodność z ostatecznymi ustaleniami zapisanymi w protokołach za


1 Uwaga: zgodnie z tą procedurą odbierane są również produkty których odbiór sprowadza się do odbioru odpowiedniego „Raportu…” oraz – w przypadku oprogramowania – kodów źródłowych. Odbiór w tym zakresie nie oznacza potwierdzenia poprawności oprogramowania, a jedynie jego ogólną zgodność z założeniami. W szczególności, gdy na etapie Testów akceptacyjnych okazałoby się, że powtórzenie testów wewnętrznych zadeklarowanych przez Wykonawcę jako pozytywnie przeprowadzone prowadziło do wniosku, że wykazują one błąd – będzie to potraktowane jako wada ukryta.


137



dokumentu „Scenariusze testowe”, Pozytywny wynik ostatniego przeglądu jakości dla dokumentu

„Scenariusze testowe”.Plan testów wewnętrznych oprogramowania


Zgodność z wzorem dokumentu „Plan Testów” (Załącznik nr P.09. do OPZ),

Uwzględnienie przez Wykonawcę wszystkich scenariuszy ze „Scenariuszy testowych” możliwych do przeprowadzenia na obecnym etapie projektu,

Zgodność z ostatecznymi ustaleniami zapisanymi w protokołach za spotkań,

Zgodność z zaleceniami zawartymi w przeglądach jakości dokumentu „Plan testów wewnętrznych”,

Pozytywny wynik ostatniego przeglądu jakości dla dokumentu „Plan testów wewnętrznych”.

Raport z testów wewnętrznych oprogramowania


Zgodność z wzorem dokumentu „Raport z Testów” (Załącznik nr P.08. do OPZ),

Uwzględnienie wszystkich scenariuszy z „Planu testów wewnętrznych oprogramowania”,


Zgodność z zaleceniami zawartymi w przeglądach jakości dokumentu „Raport z testów wewnętrznych oprogramowania”,

Pozytywny wynik ostatniego przeglądu jakości dla dokumentu „Raport z testów wewnętrznych oprogramowania”.

Agendy spotkań Etapu V




138





Protokoły ze spotkań Etapu V





Raporty przeglądu jakości dokumentu „Scenariusze testowe”





Protokoły przekazania dokumentu „Scenariusze testowe”



Opracowanie protokołu dla dokumentów „Scenariusze testowe”, Podpisanie kopii dokumentów przez odpowiednie osoby


Protokół odbioru Zgodność z wzorem dokumentu „Protokół Odbioru” (Załącznik nr U.01. do Umowy),


139



dokumentu „Scenariusze testowe”


Opracowanie protokołu dla dokumentów „Scenariusze testowe” bez zastrzeżeń,


Raporty okresowe Etapu V





(weryfikowane w ramach Procedury odbioru Etapu).Rejestr wymagań Etapu V



Odniesienie do wszystkich wymagań funkcjonalnych i niefunkcjonalnych zapisanych w OPZ ,




przedmiotem prac etapu.


140



Rejestr jakości Etapu V




Rejestr konfiguracji Etapu V



Uwzględnienie dla wszystkich wersji dokumentów „Scenariusze testowe”.


etapu.Rejestr ryzyk Etapu VUproszczona procedura odbioru



Uwzględnienie wszystkich przeprowadzonych ocen ryzyka.Rejestr tematów otwartych Etapu V





Rejestr materiałów Zgodność z wzorem dokumentu „Rejestr Materiałów Projektowych” (Załącznik nr P.13. do OPZ),


141



projektowych Etapu V






prac etapu.Rejestr zmian Etapu V







Etap VI. Uruchomienie oprogramowania

Produkty specjalistyczne:

Oprogramowanie w wersji produkcyjnej

Zgodność kodów źródłowych oprogramowania z wytycznymi zawartymi w sekcji VI.3.6 OPZ w punkcie „Ogólne wymaganie względem kodów źródłowych”.


142



Procedura odbioru oprogramowania

Zgodność z ustalonym standardem kodów źródłowych zawartych w „Projekcie technicznym”,

Pozytywny wynik „Raportu z testów akceptacyjnych” przeprowadzonych przez Zamawiającego,

Zgodność z zaleceniami zawartymi w przeglądach jakości produktu „Oprogramowanie w wersji produkcyjnej”,

Pozytywny wynik ostatniego przeglądu jakości dla produktu „Oprogramowanie w wersji produkcyjnej”,

Brak tematów otwartych dla produktu „Oprogramowanie w wersji produkcyjnej”.

Zmigrowane dane


Pozytywny wynik „Raportu z migracji danych” (Załącznik nr P.05. do OPZ),

Zgodność z ustalonym standardem migracji zawartym w „Planie migracji danych”,

Zgodność z zaleceniami zawartymi w przeglądach jakości produktu „Zmigrowane dane”,

Pozytywny wynik ostatniego przeglądu jakości dla produktu „Zmigrowane dane”,

Brak tematów otwartych dla produktu „Zmigrowane dane”.Uruchomienie oprogramowania

Procedura odbioru wdrożenia

Przekazanie wszystkich niezbędnych do eksploatacji oprogramowania licencji,

Pozytywny wynik „Raportu z uruchomienia systemu”, Zgodność z założeniami opisanymi w „Planie uruchomienia

systemu”, w Rozdziale VI.5 OPZ Zgodność z zaleceniami zawartymi w przeglądach jakości produktu

„Uruchomienie oprogramowania”, Pozytywny wynik ostatniego przeglądu jakości dla produktu

„Uruchomienie oprogramowania”,


143



Brak tematów otwartych dla produktu „Uruchomienie oprogramowania”.

Szkolenia

Procedura odbioru szkoleń

Pozytywny wynik „Raportu z przeprowadzonych szkoleń”, Zgodność z zakresem szkoleń opisanych w „Plan szkoleń”, w

Rozdziale VI.6 Zgodność z zaleceniami zawartymi w przeglądach jakości produktu

„Przeszkolenie administratorów”, Pozytywny wynik ostatniego przeglądu jakości dla produktu

„Przeszkolenie administratorów”.Dokumentacja szkoleniowa


Zgodność z wzorem „Dokumentacja szkoleniowa” (Załącznik nr S.04. do OPZ),

Zgodność z zakresem szkoleń w „Plan szkoleń”, Zgodność z wymaganiami opisanymi w Rozdziale VI.6 oraz VI.7 Zgodność z zaleceniami zawartymi w przeglądach jakości produktu

„Dokumentacja szkoleniowa”, Pozytywny wynik ostatniego przeglądu jakości dla produktu

„Dokumentacja szkoleniowa”.Produkty zarządcze:

Plan testów akceptacyjnych oprogramowania


Zgodność z wzorem dokumentu „Plan Testów” (Załącznik nr P.09. do OPZ),

Uwzględnienie przez Wykonawcę wszystkich scenariuszy ze „Scenariuszy testowych” możliwych do przeprowadzenia na obecnym etapie projektu,

Zgodność z wytycznymi zawartymi w Rozdziale VI.5 OPZ w punkcie „Testy”,



144



Zgodność z zaleceniami zawartymi w przeglądach jakości dokumentu „Plan testów akceptacyjnych oprogramowania”,

Pozytywny wynik ostatniego przeglądu jakości dla dokumentu „Plan testów akceptacyjnych oprogramowania”.

Plan migracji danych


Zgodność z wzorem dokumentu „Plan Migracji Danych” (Załącznik nr P.04. do OPZ),

Zgodność z wytycznymi zawartymi w Rozdziale VI.5 OPZ w punkcie „Migracja danych”,


Zgodność z zaleceniami zawartymi w przeglądach jakości dokumentu „Plan migracji danych”,

Pozytywny wynik ostatniego przeglądu jakości dla dokumentu „Plan migracji danych”.

Plan uruchomienia systemu


Zgodność z wzorem dokumentu „Plan Uruchomienia Systemu” (Załącznik nr P.10. do OPZ),

Zgodność z wytycznymi zawartymi w Rozdziale VI.5 OPZ w punkcie „Uruchomienie systemu”,


Zgodność z zaleceniami zawartymi w przeglądach jakości dokumentu „Plan uruchomienia systemu”,

Pozytywny wynik ostatniego przeglądu jakości dla dokumentu „Plan uruchomienia systemu”.

Plan szkoleń

Procedura odbioru

Zgodność z wzorem dokumentu „Plan Szkoleń” (Załącznik nr P.06. do OPZ),

Zgodność z wytycznymi zawartymi w Rozdziale VI.6, Zgodność z ostatecznymi ustaleniami zapisanymi w protokołach ze


145



dokumentacji spotkań, Zgodność z zaleceniami zawartymi w przeglądach jakości

dokumentu „Plan szkoleń ”, Pozytywny wynik ostatniego przeglądu jakości dla dokumentu

„Plan szkoleń”.Raport z testów akceptacyjnych


Zgodność z wzorem dokumentu „Raport z Testów” (Załącznik nr P.08. do OPZ),

Uwzględnienie wszystkich scenariuszy z „Planu testów akceptacyjnych oprogramowania”,

Zgodność z wytycznymi zawartymi w Rozdziale VI.5 OPZ w punkcie „Testy”,


Zgodność z zaleceniami zawartymi w przeglądach jakości dokumentu „Raport z testów akceptacyjnych oprogramowania”,

Pozytywny wynik ostatniego przeglądu jakości dla dokumentu „Plan testów akceptacyjnych oprogramowania”.

Raport z migracji danych


Zgodność z wzorem dokumentu „Raport migracji danych” (Załącznik nr P.05. do OPZ),

Uwzględnienie wszystkich założeń z „Planu migracji danych”, Zgodność z wytycznymi zawartymi w Rozdziale VI.5 OPZ w punkcie

„Migracja danych”, Zgodność z ostatecznymi ustaleniami zapisanymi w protokołach ze


dokumentu „Raport z migracji danych”, Pozytywny wynik ostatniego przeglądu jakości dla dokumentu

„Raport z migracji danych”.


146



Raport z uruchomienia systemu


Zgodność z wzorem dokumentu „Raport z Uruchomienia Systemu” (Załącznik nr P.11. do OPZ),

Uwzględnienie wszystkich założeń z „Plan uruchomienia systemu”, Zgodność z wytycznymi zawartymi w Rozdziale VI.5 OPZ w punkcie

„Uruchomienie systemu”, Zgodność z ostatecznymi ustaleniami zapisanymi w protokołach ze


dokumentu „Raport z uruchomienia systemu”, Pozytywny wynik ostatniego przeglądu jakości dla dokumentu

„Raport z uruchomienia systemu”.Raport ze szkoleń


Zgodność z wzorem dokumentu „Raport z przeprowadzonych szkoleń” (Załącznik nr P.07. do OPZ),

Uwzględnienie wszystkich założeń z dokumentu „Plan szkoleń”, Zgodność z wytycznymi zawartymi w Rozdziale VI.6, Zgodność z ostatecznymi ustaleniami zapisanymi w protokołach za


dokumentu „Raport ze szkoleń”, Pozytywny wynik ostatniego przeglądu jakości dla dokumentu

„Raport ze szkoleń”.Agendy spotkań Etapu VI






147



Protokoły ze spotkań Etapu VI





Raporty przeglądu jakości dokumentów: „Plan testów akceptacyjnych oprogramowania”,„Plan migracji danych”,„Plan uruchomienia systemu”,„Plan szkoleń”,„Raport z testów akceptacyjnych”,„Raport z migracji danych”,„Raport z uruchomienia systemu”,„Raport ze szkoleń”.


Uwzględnienie wszystkich wersji oprogramowania, Uwzględnienie wszystkich wersji materiałów szkoleniowych, Opracowanie dokumentów dla wszystkich przeprowadzonych

przeglądów jakości dokumentów: o „Plan testów akceptacyjnych oprogramowania”,o „Plan migracji danych”,o „Plan uruchomienia systemu”,o „Plan szkoleń”,o „Raport z testów akceptacyjnych”,o „Raport z migracji danych”,o „Raport z uruchomienia systemu”,o „Raport ze szkoleń”,



148




Protokoły przekazania dokumentów: „Plan testów akceptacyjnych oprogramowania”,„Plan migracji danych”,„Plan uruchomienia systemu”,„Plan szkoleń”,„Raport z testów akceptacyjnych”,„Raport z migracji danych”,„Raport z uruchomienia systemu”,„Raport ze szkoleń”.


Uwzględnienie wszystkich wersji oprogramowania, Uwzględnienie wszystkich wersji materiałów szkoleniowych, Uwzględnienie wszystkich zbiorów danych, Opracowanie protokołu dla dokumentów:

o „Plan testów akceptacyjnych oprogramowania”,o „Plan migracji danych”,o „Plan uruchomienia systemu”,o „Plan szkoleń”,o „Raport z testów akceptacyjnych”,o „Raport z migracji danych”,o „Raport z uruchomienia systemu”,o „Raport ze szkoleń”;



149



Uproszczona procedura odbioruProtokoły odbioru dokumentów: „Plan testów akceptacyjnych oprogramowania”,„Plan migracji danych”,„Plan uruchomienia systemu”,„Plan szkoleń”,„Raport z testów akceptacyjnych”,„Raport z migracji danych”,„Raport z uruchomienia systemu”,„Raport ze szkoleń”.



Uwzględnienie wszystkich wersji oprogramowania, Uwzględnienie wszystkich wersji materiałów szkoleniowych, Uwzględnienie wszystkich zbiorów danych, Opracowanie protokołu dla dokumentów:

o „Plan testów akceptacyjnych oprogramowania”,o „Plan migracji danych”,o „Plan uruchomienia systemu”,o „Plan szkoleń”,o „Raport z testów akceptacyjnych”,o „Raport z migracji danych”,o „Raport z uruchomienia systemu”,o „Raport ze szkoleń”;



150



Raporty okresowe Etapu VI


Zgodność z wzorem dokumentu „Raport za okres” (Załącznik nr U.04. do Umowy),



(weryfikowane w ramach Procedury odbioru Etapu).Rejestr wymagań Etapu VI







przedmiotem prac etapu.Rejestr jakości Etapu VI





151



Rejestr konfiguracji Etapu VI



Uwzględnienie wszystkich wersji oprogramowania, Uwzględnienie wszystkich wersji materiałów szkoleniowych, Uwzględnienie wszystkich zbiorów danych, Uwzględnienie dla wszystkich wersji dokumentów dla

dokumentów: o „Plan testów akceptacyjnych oprogramowania”,o „Plan migracji danych”,o „Plan uruchomienia systemu”,o „Plan szkoleń”,o „Raport z testów akceptacyjnych”,o „Raport z migracji danych”,o „Raport z uruchomienia systemu”,o „Raport ze szkoleń”;


etapu.Rejestr ryzyk Etapu VI




Uwzględnienie wszystkich przeprowadzonych ocen ryzyka.


152



Rejestr tematów otwartych Etapu VI





Rejestr materiałów projektowych Etapu VI







prac etapu.Rejestr zmian Etapu VI





historii dokumentu należy w opisie zmian wnieść odpowiednią


153



adnotację, Analizie podczas odbioru podlegają zmiany będące przedmiotem

prac etapu.

Etap VII. Opracowanie dokumentacji

Produkty specjalistyczne:Dokumentacja powykonawcza


Zgodność z wzorem dokumentu „Dokumentacja Powykonawcza” (Załącznik nr S.03. do OPZ),

Uwzględnienie wszystkich zagadnień opisanych w „Analizie biznesowej i systemowej”,

Uwzględnienie wszystkich zagadnień opisanych w „Projekcie technicznym”,

Zgodność z wymaganiami opisanymi w Rozdziale VI.7 Zgodność z zaleceniami zawartymi w przeglądach jakości

dokumentu „Dokumentacja powykonawcza”, Pozytywny wynik ostatniego przeglądu jakości dla dokumentu

„Dokumentacja powykonawcza”.Podręcznik użytkownika


Zgodność z wzorem dokumentu „Podręcznik użytkownika” (Załącznik nr S.08. do OPZ),



dokumentu „Podręcznik użytkownika”, Pozytywny wynik ostatniego przeglądu jakości dla dokumentu

„Podręcznik użytkownika”.Dokumentacja utrzymaniowa

Zgodność z wzorem dokumentu „Dokumentacja utrzymaniowa” (Załącznik nr S.05. do OPZ),


154






dokumentu „Dokumentacja utrzymaniowa”, Pozytywny wynik ostatniego przeglądu jakości dla dokumentu

„Dokumentacja utrzymaniowa”.Instrukcje stanowiskowe


Zgodność z wzorem dokumentu „Instrukcja stanowiskowa” (Załącznik nr S.06. do OPZ),


Uwzględnienie wszystkich zagadnień opisanych w „Analizie biznesowej i systemowej”,

Zgodność z zaleceniami zawartymi w przeglądach jakości dokumentu „Instrukcje stanowiskowe”,

Pozytywny wynik ostatniego przeglądu jakości dla dokumentu „Instrukcje stanowiskowe”.

Podręcznik administratora


Zgodność z wzorem dokumentu „Podręcznik administratora” (Załącznik nr S.07. do OPZ),



dokumentu „Podręcznik administratora”, Pozytywny wynik ostatniego przeglądu jakości dla dokumentu

„Podręcznik administratora”.Produkty zarządcze:


155



Agendy spotkań Etapu VII





Protokoły ze spotkań Etapu VII





Raporty przeglądu jakości dokumentów: „Dokumentacja powykonawcza”,„Podręcznik użytkownika”,„Dokumentacja utrzymaniowa”,„Instrukcje stanowiskowe”,„Podręcznik administratora”,

Zgodność z wzorem dokumentu „Raport z przeglądu jakości” (Załącznik nr K.03. do OPZ),

Uwzględnienie wszystkich wersji dokumentów, Uwzględnienie wszystkich wersji materiałów szkoleniowych, Opracowanie dokumentów dla wszystkich przeprowadzonych

przeglądów jakości dokumentów: o „Dokumentacja powykonawcza”,o „Podręcznik użytkownika”,o „Dokumentacja utrzymaniowa”,o „Instrukcje stanowiskowe”,o „Podręcznik administratora”,



156



Uproszczona procedura odbioruProtokoły przekazania dokumentów: „Dokumentacja powykonawcza”,„Podręcznik użytkownika”,„Dokumentacja utrzymaniowa”,„Instrukcje stanowiskowe”,„Podręcznik administratora”Uproszczona procedura odbioru

Zgodność z wzorem dokumentu „Protokół przekazania” (Załącznik nr U.02. do Umowy),


przeglądów jakości dokumentów: o „Dokumentacja powykonawcza”,o „Podręcznik użytkownika”,o „Dokumentacja utrzymaniowa”,o „Instrukcje stanowiskowe”,o „Podręcznik administratora”,


Protokoły odbioru dokumentów: „Dokumentacja powykonawcza”,„Podręcznik użytkownika”,


Uwzględnienie końcowej wersji dokumentów, Uwzględnienie końcowej wersji materiałów szkoleniowych, Opracowanie dokumentów dla wszystkich przeprowadzonych

przeglądów jakości dokumentów: o „Dokumentacja powykonawcza”,


157



„Dokumentacja utrzymaniowa”,„Instrukcje stanowiskowe”,„Podręcznik administratora”. „Raport ze szkoleń użytkowników w sądach”,Uproszczona procedura odbioru

o „Podręcznik użytkownika”,o „Dokumentacja utrzymaniowa”,o „Instrukcje stanowiskowe”,o „Podręcznik administratora”,o „Wzory raportów zgłoszeń dla etapu VIII”.


Raporty okresowe Etapu VII





(weryfikowane w ramach Procedury odbioru Etapu).Rejestr wymagań Etapu VII



Odniesienie do wszystkich wymagań funkcjonalnych i niefunkcjonalnych zapisanych w OPZ w rozdziale 3,



158



Uwaga: Analizie podczas odbioru podlegają wymagania będące

przedmiotem prac etapu.Rejestr jakości Etapu VII




Rejestr konfiguracji Etapu VII




przeglądów jakości dokumentów: o „Dokumentacja powykonawcza”,o „Podręcznik użytkownika”,o „Dokumentacja utrzymaniowa”,o „Instrukcje stanowiskowe”,o „Podręcznik administratora”.


etapu.Rejestr ryzyk Etapu Zgodność z wzorem dokumentu „Rejestr Ryzyk” (Załącznik nr P.14.


159



VII


do OPZ), Uwzględnienie wszystkich ryzyk zgłaszanych w ramach raportów

okresowych, Uwzględnienie wszystkich przeprowadzonych ocen ryzyka.

Rejestr tematów otwartych Etapu VII





Rejestr materiałów projektowych Etapu VII







prac etapu.Rejestr zmian Etapu VII

Zgodność z wzorem dokumentu „Rejestr zmian” (Załącznik nr P.17. do OPZ),

Uwzględnienie wszystkich zmian zgłaszanych w ramach raportów Projekt współfinansowany przez Unię Europejską ze środków

Europejskiego Funduszu Rozwoju Regionalnego160




okresowych,




Etap VIII. Serwis gwarancyjny i wsparcie

Serwis oprogramowania w miesiącu …

Uproszczona procedura odbioru z wykorzystaniem systemu zgłoszeniowego

Zgodność kodów źródłowych oprogramowania z wytycznymi zawartymi w Rozdziale VI.3.6 w sekcji Ogólne wymagania względem kodów źródłowych,

Zgodność z ustalonym standardem kodów źródłowych zawartych w „Projekcie technicznym”,

Pozytywny wynik weryfikacji usunięcia błędu na podstawie symptomów opisanych w zgłoszeniu serwisowym,

Utrzymania reżimu czasowego dla poszczególnych kategorii zgłoszeń,

Spełnienie wymagań opisanych w Rozdziale VI.8 OPZ.

Uwaga: Możliwy jest podział produktu na podprodukty i dokonanie odbioru

dla wybranych poprawek.Modyfikacje oprogramowania w miesiącu …

Zgodność kodów źródłowych oprogramowania z wytycznymi zawartymi w Rozdziale VI.3.6 w sekcji Ogólne wymagania względem kodów źródłowych,

Zgodność z ustalonym standardem kodów źródłowych zawartych w


161



Uproszczona procedura odbioru z wykorzystaniem systemu zgłoszeniowego

„Projekcie technicznym”, Zgodność Modyfikacji z kryteriami jakościowymi zlecenia, Spełnienie wymagań opisanych w Rozdziale VI.8 OPZ.

Uwaga: Możliwy jest podział produktu na podprodukty i dokonanie odbioru

dla wybranych Modyfikacji.Aktualizacje dokumentacji w miesiącu …


Wykonanie odpowiednich zmian dokumentów „Dokumentacja powykonawcza”, „Podręcznik użytkownika”, „Dokumentacja utrzymaniowa”, „Instrukcje stanowiskowe”, „Podręcznik administratora” w związku z Modyfikacjami i poprawkami oprogramowania oraz zgłoszeniami potrzeb Modyfikacji,

Zgodność dokumentacji z wymaganiami dla odpowiednich produktów,

Produkty zarządcze:Protokół odbioru serwisu w miesiącu …Uproszczona procedura odbioru

Zgodność ze wzorcem Załącznika nr U.06 do Umowy „Protokół odbioru serwisu”

Zgodność z zapisami systemu zgłoszeniowego.


162

1.2 Zarządzanie projektem

1.2.1 Ogólne wymagania w zakresie zarządzania projektem

Zamawiający wymaga od Wykonawcy dostosowania zarządzania i sposobu realizacji projektu do PRINCE2™ w zakresie koniecznym do realizacji Umowy. W zakresie nie uregulowanym w Umowie i OPZ obowiązuje treść metodyki PRINCE2™ w wersji z roku 2009, polska wersja językowa (ISBN 978-0-11-331224-5).

Wykonawca odpowiedzialny jest za zarządzanie i koordynację prac zespołu wdrożeniowego Wykonawcy oraz koordynację współdziałania swojego zespołu z zespołem Zamawiającego w procesie wdrożenia rozwiązania. Dobór metod i technik pracy właściwych dla efektywnej realizacji przedmiotu zamówienia leży po stronie Wykonawcy, przy czym podlega on akceptacji Zamawiającego. Wykonawca w szczególności zobowiązany jest do realizacji prac inicjujących projekt obejmujących co najmniej:

spotkanie otwierające projekt – zorganizowane zostanie przez Wykonawcę w siedzibie Zamawiającego w terminie nie późniejszym niż 10 dni od podpisania Umowy – celem spotkania jest dokonanie niezbędnych uzgodnień realizacyjnych Stron, w tym ustaleń wymaganych dla opracowania „Dokumentacji zarządczej” i „Szczegółowego Harmonogramu Prac”,

opracowanie „Dokumentacji zarządczej”, opracowanie „Szczegółowego Harmonogramu Prac”.

„Dokumentacja zarządcza” – opisuje zasady organizacji i koordynacji prac przy współpracy projektowej Stron. Dokumentacja zarządcza powinna być przygotowany z zachowaniem kluczowych zasad wynikających z metodyki zarządzania projektami PRINCE2 - powinna zawierać m.in.: opis struktury organizacyjnej zespołu odpowiedzialnego za realizację projektu oraz opis procedur projektowych w zakresie m.in.: komunikacji (dane kontaktowe i procedury komunikacji), zarzadzania zagadnieniami projektowymi, zarządzania zmianą (rejestr zmian), zarządzania ryzykiem (rejestr ryzyk), planowanie jakości (poprzez uszczegółowienie kryteriów jakościowych dla głównych produktów projektu lub ewentualne ich rozbicie na podprodukty).

Patrz również wymagania zdefiniowane w Rozdziale VI.7 OPZ w Sekcji [Dokumentacja projektowa] oraz wzór dokumentu „Dokument zarządczy” (Załącznik nr P.03. do OPZ),.


„Szczegółowy Harmonogram Prac” – opisuje w układzie etapów, zadań i podzadań sposób realizacji projektu, wskazuje zależności czasowe poszczególnych zadań, definiuje ograniczenia realizacyjne, jak również wskazuje osoby/strony odpowiedzialne za realizację poszczególnych prac. Zdefiniowany przez Zamawiającego w niniejszym OPZ podział projektu na etapy i czasy ich trwania jest wiążący dla Wykonawcy. Zamawiający dopuszcza w uzasadnionych przypadkach zmiany zależności realizacyjnych zadań w czasie, a także przesunięcia zadań w czasie. Przesunięcia takie muszą być każdorazowo zaakceptowane przez Zamawiającego i w żadnym razie nie mogą wpływać na zmianę daty zakończenia całości prac projektowych. Szczegółowe zasady zmian i aktualizacji „Szczegółowego Harmonogramu Prac” przez Wykonawcę zostaną zdefiniowane w „Dokumentacji zarządczej” (z uwzględnieniem zapisów Ustawy prawo zamówień publicznych i zapisów Umowy). „Szczegółowy Harmonogram Prac” przygotowany zostanie przez Wykonawcę w postaci diagramu Gantta i w tej postaci będzie aktualizowany w toku projektu. Zamawiający wymaga zastosowania przez Wykonawcę wdrożonego w jego organizacji oprogramowania JIRA w celu zarządzania harmonogramem narzędzi wspomagających zarządzanie harmonogramem prac oraz zagadnieniami projektowymi w sposób, który pozwolą na aktualizację harmonogramu przy jednoczesnym zachowaniu informacji bazowych (harmonogram bazowy) oraz przedstawienie planu oraz stanu jego realizacji w przejrzystej formie uwzględniającej zakres informacyjny zarówno dla osób bezpośrednio zaangażowanych w realizację poszczególnych zadań (np. członkowie zespołu projektowego), jaki i osób odpowiedzialnych za nadzór nad projektem (np. Komitet Sterujący). Wyniki monitorowania postępu prac będą stosownie nanoszone przez Wykonawcę w harmonogramie.

„Dokumentacja zarządcza” oraz „Szczegółowy Harmonogram Prac” podlegają akceptacji Zamawiającego, po której tak przygotowany harmonogram stanowić będzie punkt odniesienia dla monitorowania postępów prac projektowych.

Oba powyższe dokumenty mogą być stosownie aktualizowane w toku realizowanych prac projektowych, jednak każdorazowa ich zmiana wymaga pisemnej akceptacji Zamawiającego. W szczególności Szczegółowy Harmonogram Prac będzie aktualizowany przez Wykonawcę na koniec każdego etapu prac w zakresie prac przewidzianych do realizacji w etapie kolejnym.

Szczegółowe wymagania dotyczące prowadzenia projektu oraz sposobu jego dokumentowania zawierają następujące załączniki do OPZ oraz


164


Umowy:

Wzory umowne (U.xx):1. Protokół Odbioru – Załącznik nr U.01. do Umowy,2. Protokół Przekazania – Załącznik nr U.02. do Umowy,3. Protokół Rozbieżności – Załącznik nr U.03. do Umowy,4. Raport za Okres – Załącznik nr U.04. do Umowy,5. Protokół Odbioru Sprzętu – Załącznik nr U.05 do Umowy.6. Protokół Odbioru Serwisu- Załącznik nr U.06 do Umowy7. Protokół Odbioru Modyfikacji – Załącznik nr U.07 do Umowy

Wzory dotyczące zarządzania projektem (P.xx):1. Agenda Spotkania – Załącznik nr P.01. do OPZ,2. Protokół ze Spotkania – Załącznik nr P.02. do OPZ,3. Dokument Zarządczy – Załącznik nr P.03. do OPZ,4. Plan Migracji Danych – Załącznik nr P.04. do OPZ,5. Raport z migracji danych – Załącznik nr P.05. do OPZ,6. Plan Szkoleń – Załącznik nr P.06. do OPZ,7. Raport z przeprowadzonych szkoleń – Załącznik nr P.07. do OPZ,8. Raport z Testów – Załącznik nr P.08. do OPZ,9. Plan Testów – Załącznik nr P.09. do OPZ,10. Plan Uruchomienia Systemu – Załącznik nr P.10. do OPZ,11. Raport z Uruchomienia Systemu – Załącznik nr P.11. do OPZ,12. Rejestr Konfiguracji – Załącznik nr P.12. do OPZ,13. Rejestr Materiałów Projektowych – Załącznik nr P.13. do OPZ,14. Rejestr Ryzyk – Załącznik nr P.14. do OPZ,15. Rejestr Tematów Otwartych – Załącznik nr P.15. do OPZ,16. Rejestr Wymagań – Załącznik nr P.16. do OPZ,17. Rejestr Zmian – Załącznik nr P.17. do OPZ.

Wzory dotyczące kontroli jakości (K.xx):1. Scenariusze Testowe – Załącznik nr K.01. do OPZ.2. Protokół Testów Akceptacyjnych – Załącznik nr K.02. do OPZ,3. Raport Przeglądu Jakości – Załącznik nr K.03. do OPZ,4. Rejestr Jakości Projektu – Załącznik nr K.04. do OPZ.

Wzory dokumentów specjalistycznych (S.xx):1. Analiza biznesowa i systemowa – Załącznik nr S.01. do OPZ,2. Projekt Techniczny – Załącznik nr S.02. do OPZ,


165


3. Dokumentacja Powykonawcza – Załącznik nr S.03. do OPZ,4. Dokumentacja Szkoleniowa – Załącznik nr S.04. do OPZ,5. Dokumentacja Utrzymaniowa – Załącznik nr S.05. do OPZ,6. Instrukcja stanowiskowa – Załącznik nr S.06. do OPZ,7. Podręcznik Administratora – Załącznik nr S.07. do OPZ,8. Podręcznik Użytkownika – Załącznik nr S.08. do OPZ.

1.2.2 Struktura projektowa

Organizacja prac Wykonawcy zostanie dostosowana do struktury Projektu w Etapie I Umowy.

Zasady funkcjonowania struktury projektu reguluje Zarządzenie Ministra Sprawiedliwości z dnia 4 czerwca 2014 r. w sprawie ustanowienia i zadań Rady Portfela Projektów oraz zasad zarządzania Portfelem Projektów w Ministerstwie Sprawiedliwości.

1.2.3 Doradca technologiczny

Na czas realizacji Projektu przewiduje się skorzystanie z usług specjalistycznego podmiotu – Doradcy technologicznego, który zapewni jak najwyższą jakość w zakresie wdrażanych rozwiązań i zarządzania projektem.

W tym zakresie Zamawiający zawarł umowę nr 54 z dnia 23 listopada 2016 r. z Centrum Doradztwa w Informatyce i Zarządzaniu Sp. o.o. Doradca technologiczny jest w szczególności podmiotem wskazanym w §4 ust. 2 oraz §19 Umowy jako podmiot upoważniony do Audytu projektu.

1.2.4 Procedury odbiorcze

1.2.4.1 Uproszczona procedura odbioru

Uproszczona procedura odbioru dotyczy wskazanych cząstkowych Produktów Zarządczych i ma na celu zmniejszeni nakładu organizacyjnego związanego z zarządzaniem projektem.

Produktem cząstkowym podlegającym odbiorowi w tym wypadku jest:


166


Każda pojedyncza agenda, protokół ze spotkania, raport z przeglądu jakości danego dokumentu, protokół przekazania, protokół odbioru, raport okresowy,

Rejestr wymagań, jakości, konfiguracji, ryzyk, tematów otwartych, materiałów projektowych oraz zmian – po każdej aktualizacji.

Nie przewiduje się odrębnego odbioru dokumentowania poszczególnych produktów poza procedurą opisaną wyżej. Odbiór całościowy prostych produktów odbywa się łącznie z procedurą odbioru etapu. Na tym etapie weryfikowane są m.in. podpisy na dokumentach (o ile są wymagane).

1. Wykonawca przekazuje Produkt w sposób przewidziany w „Dokumencie Zarządczym”, a jeżeli dokument ten jeszcze nie został zatwierdzony – na adres e-mail Kierownika Projektu Zamawiającego, wskazany w Umowie.

2. Zamawiający przeanalizuje przekazany Produkt w terminie 3 Dni Roboczych od daty przekazania i:

2.1 potwierdzi jego poprawność;2.2 zgłosi Wykonawcy usterki

w sposób wskazany w „Dokumencie Zarządczym”, a jeżeli dokument ten jeszcze nie został zatwierdzony – na adres e-mail Kierownika Projektu Wykonawcy, wskazany w Umowie.

3. Wykonawca, uwzględnia zgłoszone uwagi poprzez

3.1 przedstawienie do odbioru poprawionej wersji Produktu lub3.2 pisemne stanowisko w zakresie poszczególnych uwag

w terminie 2 Dni Roboczych od chwili zgłoszenia przez Zamawiającego uwag w sposób wskazany w „Dokumencie Zarządczym”, a jeżeli dokument ten jeszcze nie został zatwierdzony – na adres e-mail Kierownika Projektu Zamawiającego, wskazany w Umowie.

4. Po otrzymaniu przez Zamawiającego poprawionej wersji Produktu, zgodnie z ust. 3, procedura odbioru zostanie powtórzona. Strony mogą odbywać spotkania wyjaśniające i uzgodnieniowe, jednak nie później niż przez 3 Dni Robocze od dnia otrzymania poprawionej


167


wersji Produktu przez Zamawiającego, chyba, że Zarząd Projektu poweźmie inną decyzję.

5. Dopuszcza się trzykrotną iterację zgłoszeń Produktów oraz jej oceny według punktów 1-3 powyżej.

6. W przypadku braku odbioru Produktu w ramach trzech iteracji Zamawiający wyznaczy Wykonawcy dodatkowy, nie krótszy niż 7 dni termin na usunięcie Usterek, w którym powinien on zgłosić do ponownego odbioru Produkt. Termin wyznaczony przez Zamawiającego, może być na wniosek Wykonawcy skrócony, jednakże nie może być on krótszy niż 7 dni.

7. Zamawiający ponawia procedurę odbioru opisaną w punktach 1-6 powyżej dla ponownego zgłoszenia Produktu.

8. Okres od terminu w którym powinien być odebrany produkt w ramach limitu pierwszych trzech iteracji do daty faktycznego odbioru uznaje się za termin opóźnienia uproszczonej procedury odbioru danego Produktu.

1.2.4.2 Procedura przekazania produktów

W przypadku produktów innych niż przewidzianych do odbioru procedurą uproszczoną stosuje się Procedurę przekazania produktu oraz odpowiednią Procedurę odbiorczą.

1. W przypadkua. W przypadku infrastruktury sprzętowej Wykonawca powiadamia

Zamawiającego o terminie dostarczenia (dzień, godzina) Infrastruktury sprzętowej na co najmniej 5 Dni Roboczych przed planowaną datą dostarczenia, informując o: Danych osoby odpowiedzialnej ze strony Wykonawcy za dostawę i upoważnioną do podpisania protokołu ilościowego Infrastruktury Umowy, liczbie paczek wraz z podaniem wagi, liście osób dostarczających Infrastrukturę Umowy. Zamawiający może w ciągu jednego dnia od daty przekazania informacji, wyznaczyć Wykonawcy inny termin niż wskazany przez Wykonawcę, nie późniejszy jednak niż do 3 Dni Robocze od terminu zaproponowanego przez Wykonawcę.

Uwaga:


168


Ustalenie terminu przekazania sprzętu nie oznacza, że w tym samym terminie jest możliwe jego zainstalowanie.

b. pozostałych produktów Wykonawca przekazuje Produkt wraz z oświadczeniem, że Produkt przeszedł wewnętrzny test jakości, w terminie wskazanym w „Szczegółowym Harmonogramem Prac”. W przypadku Oprogramowania obowiązują dodatkowe regulacje opisane w ust. 7.

2. Zamawiający, w dniu przekazania Produktu potwierdzi otrzymanie Produktu podpisując Protokół Przekazania (wg wzoru w Załączniku nr U.02. do Umowy) lub odmówi jego podpisania podając uzasadnienie faktyczne w Protokole Rozbieżności (wg wzoru w Załączniku nr U.03. do Umowy).

3. W przypadku sprzętu przyczyną odmowy (a także przystąpienia do procedury w całości lub części) może być brak uzgodnienia terminu.

4. W przypadku sprzętu Zamawiający dokona weryfikacji ilościowej dostarczonej przez Wykonawcę Infrastruktury Umowy, polegającej na sprawdzeniu ilości dostarczonych paczek z ilością wskazaną przez Wykonawcę przed dostawą. W przypadku rozbieżności Zamawiający wpisuje rozbieżności do protokołu rozbieżności.

5. W przypadku braku odbioru przekazania Produktu Zamawiający wyznaczy Wykonawcy dodatkowy, nie krótszy niż 3 dni termin na usunięcie Usterek, w którym powinien on zgłosić do ponownego odbioru Produkt. Termin wyznaczony przez Zamawiającego, będzie na wniosek Wykonawcy skrócony, jednakże nie może być on krótszy niż 3 dni.

6. Zamawiający ponawia procedurę odbioru opisaną w punktach 1-5 powyżej dla ponownego zgłoszenia Produktu.

7. Przekazanie oprogramowania oznacza: a. przekazanie kodu źródłowego,b. raport z testów wewnętrznych Wykonawcy (wg wzoru w

Załączniku nr K.02. do OPZ), c. zainstalowanie oprogramowania w środowisku.

8. Dzień podpisania Protokołu Przekazania przez Zamawiającego uznaje się za dzień przekazania Produktu.

9. Okres od terminu w którym powinien być przekazany Produkt zgodnie ze „Szczegółowym Harmonogramem Prac” do daty faktycznego odbioru Produktu uznaje się za termin opóźnienia procedury przekazania danego Produktu.


169


Dla uniknięcia wątpliwości należy podkreślić, że przeprowadzenie procedury przekazania Produktu nie oznacza potwierdzenia jakichkolwiek jego cech poza zgodnością ilościową oraz brakiem widocznych wad.

1.2.4.3 Procedura odbioru dokumentacji

Procedura dotyczy produktów typu dokumentacja, w szczególności są to dokumenty wg. wzorów:

Analiza biznesowa i systemowa – Załącznik nr S.01. do OPZ, Projekt Techniczny – Załącznik nr S.02. do OPZ, Dokumentacja Powykonawcza – Załącznik nr S.03. do OPZ, Dokumentacja Szkoleniowa – Załącznik nr S.04. do OPZ, Dokumentacja Utrzymaniowa – Załącznik nr S.05. do OPZ, Instrukcja stanowiskowa – Załącznik nr S.06. do OPZ, Podręcznik Administratora – Załącznik nr S.07. do OPZ, Podręcznik Użytkownika – Załącznik nr S.08. do OPZ. Dokument Zarządczy – Załącznik nr P.03. do OPZ,

Uwaga:

Zgodnie z tą procedurę odbierane są również np. produkty:

Oprogramowanie testowe oraz Zmigrowane dane,

których odbiór sprowadza się do odbioru odpowiedniego „Raportu…” oraz – w przypadku oprogramowania – kodów źródłowych. Odbiór w tym zakresie nie oznacza potwierdzenia poprawności oprogramowania, a jedynie jego ogólną zgodność z założeniami. W szczególności, gdy na etapie Testów akceptacyjnych okazałoby się, że powtórzenie testów wewnętrznych zadeklarowanych przez Wykonawcę jako pozytywnie przeprowadzone prowadziło do wniosku, że wykazują one błąd – będzie to potraktowane jako wada ukryta.

1. Po przekazaniu produktu typu Dokumentacja, zgodnie z procedurą opisaną w punkcie 1.2.6.2, Zamawiający przeanalizuje przekazany Produkt w terminie 7 Dni Roboczych od daty przekazania i:

1) odbierze go w całości bez uwag;


170


2) zgłosi Wykonawcy usterki Dokumentacji, w tym w szczególności wynikające z przyjętych kryteriów odbioru dla danego produktu.


1) przedstawienie do odbioru poprawionej wersji Produktu oraz2) pisemne stanowisko w zakresie poszczególnych uwag

w terminie 5 Dni Roboczych od chwili zgłoszenia przez Zamawiającego usterek Dokumentacji.

3. Po otrzymaniu przez Zamawiającego poprawionej wersji Produktu, zgodnie z ust. 2, procedura odbioru zostanie powtórzona. Strony mogą odbywać spotkania wyjaśniające i uzgodnieniowe, jednak nie później niż przez 3 Dni Robocze od otrzymania poprawionej wersji Produktu przez Zamawiającego, chyba, że Zarząd Projektu poweźmie inną decyzję.

4. Dopuszcza się dwukrotną iterację zgłoszeń Dokumentacji oraz jej oceny według punktów 1-2 powyżej.

5. W przypadku braku odbioru Produktu w ramach dwóch iteracji Zamawiający wyznaczy Wykonawcy dodatkowy, nie krótszy niż 14 dni termin na usunięcie Usterek, w którym powinien on zgłosić do ponownego odbioru Produkt. Termin wyznaczony przez Zamawiającego, będzie na wniosek Wykonawcy skrócony, jednakże nie może być on krótszy niż 14 dni.

6. Zamawiający ponawia procedurę odbioru opisaną w punktach 1-5 powyżej dla ponownego zgłoszenia produktu.

7. Okres od terminu w którym Dokumentacja powinna być odebrana zgodnie ze „Szczegółowym Harmonogramem Prac” do daty faktycznego odbioru uznaje się za termin opóźnienia procedury odbioru danego produktu.

8. Odbiór dokumentacji zostaje potwierdzony podpisaniem przez strony Protokołu Odbioru wg. wzoru U.01 do Umowy.


171


1.2.4.4 Procedura odbioru szkoleń

Procedura dotyczy szkoleń przeprowadzanych zgodnie z odpowiednimi planami tworzonymi zgodnie ze wzorem opisanym w załączniku P.06 do OPZ. W przypadku dokumentacji szkoleniowej (wg. Załącznika nr S.04 do OPZ) stosuje się procedurę odbiorczą w zakresie dokumentacji opisaną w sekcji 1.2.6.3.

Prerekwizytem odbioru Szkoleń jest akceptacja odpowiedniego Planu szkoleń (Załącznik nr P.06. do OPZ).

1. W ciągu 3 dni od przeprowadzonego szkolenia Wykonawca przedstawia:

1) Raport z przeprowadzonych szkoleń (według wzoru nr P.07 do OPZ) oraz

2) Dokumentację szkoleniową (według wzoru nr S.04 do OPZ)

według procedury opisanej w sekcji 1.2.6.3.

2. Zamawiający zweryfikuje Szkolenia w ciągu 5 Dni Roboczych od ich zakończenia i:

1) odbierze je w całości bez uwag w przypadku pozytywnego odbioru Raportu oraz Dokumentacji Szkoleniowej (według procedury opisanej w sekcji 1.2.6.3);

2) zgłosi Wykonawcy usterki Szkoleń, w tym w szczególności wynikające z przyjętych kryteriów odbioru dla danego produktu.

3. Wykonawca, uwzględnia zgłoszone uwagi poprzez powtórzenie szkolenia w zakresie w którym zostały zgłoszone usterki (oraz przedstawienie nowej Dokumentacji Szkoleniowej - według procedury opisanej w sekcji 1.2.6.3 – o ile procedura ta wykazała usterki)

4. Dopuszcza się dwukrotną iterację Szkoleń oraz ich oceny według punktów 1-3 powyżej.

5. W przypadku braku odbioru Szkoleń w ramach dwóch iteracji Zamawiający wyznaczy Wykonawcy dodatkowy, nie krótszy niż 21 dni termin na usunięcie Usterek, w którym powinien on ponownie przeprowadzić Szkolenie. Termin wyznaczony przez Zamawiającego, będzie na wniosek Wykonawcy skrócony, jednakże nie może być on krótszy niż 21 dni.


172



7. Okres od terminu, w którym Szkolenie powinno być odebrane zgodnie ze „Szczegółowym Harmonogramem Prac” do daty faktycznego odbioru uznaje się za termin opóźnienia danego Szkolenia.

8. Odbiór szkoleń zostaje potwierdzony podpisaniem przez Strony Protokołu Odbioru wg. Wzoru U.01 do Umowy i jest równoważny z odbiorem:

1) Raportu z przeprowadzonych szkoleń (według wzoru nr P.07 do OPZ) oraz

2) Dokumentacji szkoleniowej (według wzoru nr S.04 do OPZ).

1.2.4.5 Procedura odbioru oprogramowania

Prerekwizytem odbioru są produkty: Scenariusze testowe oraz Plan testów akceptacyjnych oprogramowania Oprogramowanie testowe.

1. Po przekazaniu do odbioru produktu Oprogramowanie testowe zgodnie z procedurą odbioru zgodnie z procedurą opisaną w punkcie 1.2.6.3 Zamawiający przeprowadza Testy Akceptacyjne Zamawiającego (TAZ)2.

2. Podstawą TAZ są:

1) Plan Testów

2) Scenariusze Testowe (wraz z danymi i skryptami testowymi, którymi zasilenie systemu jest niezbędne dla realizacji procedury odbioru oprogramowania),

które podlegają procedurze odbioru dokumentacji.

3. Zamawiający ma prawo przeprowadzić własne testy, w ramach prowadzonych tur TAZ, za pomocą zdefiniowanych samodzielnie scenariuszy testowych (spoza Produktu „Scenariuszy testowych” podlegających odbiorowi). Testy te przeprowadzane są niezależnie, przy czym wykonywanie przez Zamawiającego testów własnych nie

2 Choć zasadniczo oprogramowanie przekazane do testów powinno być tożsame z oprogramowaniem testowym, wymagane jest w tym wypadku zainstalowanie do na infrastrukturze.


173


zwalnia go z obligatoryjnego wykonania testów na podstawie odebranych scenariuszy testowych.

4. W ramach TAZ przeprowadzone zostaną także testy niefunkcjonalne (w tym opisane w Rozdziale VI.5 OPZ w sekcji „Testy”) zgodnie z poniższym:

1) testy niefunkcjonalne powinny odbywać się automatycznie zgodnie z zaprojektowanymi scenariuszami testowymi;

2) obciążenie i gromadzenie wyników będzie odbywało się automatycznie. Szczegółowe wyniki z pomiarów dla funkcji zdefiniowanych w ramach testów niefunkcjonalnych powinny być udostępnione Zamawiającemu w pliku csv. Na podstawie tych danych generowany będzie raport zbiorczy (średni, maksymalny czas, odchylenie standardowe dla badanej funkcji użytkownika), który Wykonawca dostarcza Zamawiającemu;

3) obciążenie systemu generowane będzie dla wielu użytkowników wraz z pomiarem czasu funkcji dla każdego użytkownika.

5. W trakcie trwania którejkolwiek z tur TAZ Kierownik Projektu Zamawiającego może wyrazić zgodę na wgrywanie poprawek usuwających błędy wykryte podczas testowania, przy czym nie może to wydłużyć czasu trwania tury TAZ, ustalonego w „Szczegółowym Harmonogramie Prac” lub „Planie testów akceptacyjnych oprogramowania”.

6. TAZ prowadzone są przez Zamawiającego. Wykonawca każdorazowo uczestniczy w TAZ wspierając Zamawiającego, w szczególności udzielając mu informacji niezbędnych do przeprowadzenia TAZ.

7. W trakcie wykonywania TAZ wykrywane i zgłaszane są Wady testowanego oprogramowania. Zgłaszanie Wad realizowane jest poprzez ich udokumentowanie w protokole z testów, który jest sporządzany na zakończenie każdego dnia testów i jest przekazywany Wykonawcy. Dla każdej zgłoszonej Wady Kierownik Projektu Zamawiającego lub osoba przez niego wskazana określa jej rodzaj.

8. Dla potrzeb procedury odbioru oprogramowania przyjmuje się następującą klasyfikację Wad (zgodnie z zapisami z Umowy):

1) Awarię,

2) Błąd Krytyczny i

3) Błąd Niekrytyczny.


174


9. Za pozytywny wynik testów uznaje się sytuacje, gdy nie stwierdzono Wad

10. Za pozytywny warunkowo wynik testów uznaje się sytuacje, gdy:

1) Nie stwierdzono Awarii lub Błędów Krytycznych

2) Nie stwierdzono występowania, żadnego z ewentualnych Błędów Niekrytycznych „Oprogramowania w wersji testowej”, które zgłoszone były w uprzednio w Protokole testów wewnętrznych..

Dopuszcza się występowanie Błędów Niekrytycznych, które wykazuje się w protokole.

11. Oprogramowanie, które przejdzie pozytywnie TAZ uznaje się za prawidłowo wykonane i na tej podstawie Zamawiający podpisuje odpowiednio Protokół Odbioru (Załącznik nr U.1. do Umowy).

12. Oprogramowanie, które przejdzie warunkowo pozytywnie TAZ uznaje się za prawidłowo wykonane i na tej podstawie Zamawiający podpisuje odpowiednio Protokół Odbioru (Załącznik nr U.1. do Umowy) wraz z odpowiednimi zastrzeżeniami i wyznacza Zamawiającemu termin nie krótszy niż 30 dni na usunięcie Błędów Niekrytycznych – patrz punkt 18.

13. Jeżeli po przeprowadzeniu testów oprogramowanie nie spełni kryteriów odbioru, Zamawiający odmawia jego odbioru wskazując Wady. Gdy przeprowadzone testy wykażą dodatkowo Błędy oprogramowania w wersji testowej nie wykazane w Protokole testów wewnętrznych – uznawane jest to zawadę ukrytą tego produktu.

14. Jeżeli Zamawiający odmówi odbioru, Wykonawca usunie Wady w terminie 5 Dni Roboczych od dnia otrzymania decyzji Zamawiającego lub w tym samym terminie wskaże i udowodni inną przyczynę jego nieprawidłowego działania, wynikającą z przyczyn za które Wykonawca nie odpowiada, a następnie przedstawi oprogramowanie do ponownego odbioru (kolejna tura TAZ), chyba że wskazane wyjaśnienia nie powodowały wprowadzenia zmian w oprogramowaniu.

15. Procedura odbioru będzie powtarzana w kolejnych – co najwyżej trzech - iteracjach odbioru zgodnie z ust. 1-11 do czasu odebrania oprogramowania.

16. W przypadku braku odbioru Oprogramowania w ramach trzech iteracji Zamawiający wyznaczy Wykonawcy dodatkowy, nie krótszy niż 30 dni termin na usunięcie Wad, w którym powinien on ponownie


175


przekazać Oprogramowanie z uwzględnieniem poprawek. Termin wyznaczony przez Zamawiającego, będzie na wniosek Wykonawcy skrócony, jednakże nie może być on krótszy niż 30 dni.

17. Zamawiający ponawia procedurę odbioru opisaną w punktach 1-16 powyżej dla ponownego zgłoszenia produktu, z zastrzeżeniem, że zgłoszenie musi być poprzedzone ponowną procedurą odbiorczą Planu testów akceptacyjnych oraz Scenariuszy odbiorowych (w szczególności, gdy stwierdzone Wady zostały ujawnione w wyniku scenariuszy własnych Zamawiającego).

18. Zamawiający ponawia procedurę odbioru opisaną w punktach 1-13 powyżej dla ponownego zgłoszenia produktu odebranego warunkowo pozytywnie, z zastrzeżeniem, że zgłoszenie musi być poprzedzone ponowną procedurą odbiorczą Planu testów akceptacyjnych oraz Scenariuszy odbiorowych (mogą one obejmować jedynie Scenariusze związane z ujawnionymi Błędami Niekrytycznymi), z tym, że w tym wypadku dopuszczalny jest jedynie pozytywny wynik testów. W przypadku ponownego ujawnienia Wad zastosowanie ma punkt 16.

19. Okres od terminu, w którym Oprogramowanie powinno być odebrane zgodnie ze „Szczegółowym Harmonogramem Prac” do daty faktycznego odbioru uznaje się za termin opóźnienia procedury odbioru oprogramowania. Za opóźnienie nie uznaje się usunięcia wad niekrytycznych w zakreślonym terminie o ile spowodowało to opóźnienia realizacji całości Projektu.

1.2.4.6 Procedura odbioru sprzętu

1. Po przekazaniu sprzętu zgodnie z procedurą przekazania produktu Wykonawca dokonuje montażu i instalacji sprzętu zgodnie ze „Szczegółowym Harmonogramem Prac” i zgłasza Zamawiającemu Produkt gotowy do odbioru.

2. Zamawiający przeanalizuje przekazany Produkt w terminie 7 Dni Roboczych od daty przekazania i:

2.1. odbierze go w całości bez uwag;2.2. zgłosi Wykonawcy usterki sprzętu, w tym szczególności

wynikające z przyjętych kryteriów odbioru dla danego produktu.


3.1. przedstawienie do odbioru poprawionej wersji Produktu oraz3.2. pisemne stanowisko zakresie poszczególnych uwag


176


w terminie 5 Dni Roboczych od chwili zgłoszenia przez Zamawiającego usterek Produktu.

4. Po otrzymaniu przez Zamawiającego poprawionej wersji Produktu, zgodnie z ust. 3, procedura odbioru zostanie powtórzona. Strony mogą odbywać spotkania wyjaśniające i uzgodnieniowe, jednak nie później niż przez 3 Dni Robocze od otrzymania poprawionej wersji Produktu przez Zamawiającego, chyba, że Zarząd Projektu poweźmie inną decyzję.

5. Dopuszcza się dwukrotną iterację zgłoszeń Produktu oraz jego oceny według punktów 1-4 powyżej.



8. Okres od terminu w którym Produkt powinien być odebrany zgodnie ze „Szczegółowym Harmonogramem Prac” do daty faktycznego odbioru uznaje się za termin opóźnienia odbioru danego produktu.

9. Odbiór Produktu zostaje potwierdzony podpisaniem przez Strony Protokołu Odbioru Sprzętu wg. wzoru U.05 do Umowy.

1.2.4.7 Procedura odbioru wdrożenia

1. Oprogramowanie odebrane procedurą odbioru Oprogramowania podlega wdrożeniu na Środowisku produkcyjnym.

2. Wdrożenie odbywa się na podstawie Planu Uruchomienia Systemu (Załącznik nr P.10 Wdrożenia, zgodnie z Załącznikiem nr 2 do Umowy.

3. Zamawiający dokona w terminie 5 Dni Roboczych weryfikacji Wdrożenia poprzez przeprowadzenie wyrywkowego testu dowolnej funkcjonalności Systemu, zgodnej z odbieranym oprogramowaniem.


177


Dla wyników testów stosuje się definicje Awarii, Błędu Krytycznego i Błędu Niekrytycznego.

4. Po przeprowadzeniu weryfikacji Produktu Zamawiający podpisze Protokół Odbioru (Załącznik nr U.1. do Umowy) lub zgłosi Wykonawcy Wady odmawiając odbioru Produktu (Protokół Rozbieżności – Załącznik nr. U.3.). – w przypadku stwierdzenia Awarii lub Błędu Krytycznego, z zastrzeżeniem ust. 5.

5. Jeżeli Zamawiający odmówi odbioru Produktu, zgodnie z ust. 4, Wykonawca usunie Wady w terminie 3 Dni Roboczych od dnia otrzymania decyzji Zamawiającego lub w tym samym terminie wskaże i udowodni inną przyczynę jego nieprawidłowego działania, wynikającą z przyczyn, za które Wykonawca nie odpowiada, a następnie dokona ponownego Wdrożenia, jeżeli poprzednie Wdrożenie zostało wycofane. Zamawiający podpisze Protokół Odbioru po pozytywnej realizacji Wdrożenia, z zastrzeżeniem ust. 7.

6. Zamawiający może ustalić z Wykonawcą, że Błędy Niekrytyczne zostaną usunięte w ramach Gwarancji.

7. Dopuszcza się dwukrotną iterację zgłoszeń Procedury Odbioru wdrożenia oraz jej oceny według punktów 1-6 powyżej.



10. Okres od terminu w którym Wdrożenie powinno być odebrane zgodnie ze „Szczegółowym Harmonogramem Prac” do daty faktycznego odbioru uznaje się za termin opóźnienia uproszczonej procedury odbioru danego produktu.

11. Odbiór Wdrożenia zostaje potwierdzony podpisaniem przez Strony Protokołu Odbioru wg. wzoru U.01 do Umowy.


178


1.2.4.8 Procedura odbioru etapu

1. Po dokonaniu odbioru Produktów wchodzących w skład danego Etapu Zamawiający dokona, w terminie 3 Dni Roboczych, odbioru Etapu poprzez podpisanie Protokołu Odbioru.

2. Odbiór etapu bazuje na zgromadzonej przy okazji odbioru poszczególnych produktów danego etapu – w tym podpisanych wersjach dokumentów – tam gdzie jest to wymagane.

3. Po dokonaniu odbioru wszystkich Etapów w ramach Zadania Zamawiający dokona odbioru końcowego podpisując Protokół Odbioru Końcowego.

1.2.4.9 Procedury kontroli jakości prac

Podczas trwania Projektu wykonywane będą dwa rodzaje przeglądów jakości:

Rysunek 2. Podział odpowiedzialności w zakresie przeglądów jakości

Innym sposobem na pozyskanie informacji o jakości dostarczonych produktów jest badanie zadowolenia użytkowników, poznawanie ich opinii.

W przypadku przeglądów jakości stosowanych przez Zamawiającego stosowana będzie następująca procedura:

1. Zamawiający wezwie Wykonawcę do przekazania aktualnej wersji wybranego przez Zamawiającego produktu.


Przeglądy wewnętrzne

przeglądy realizowane przez Wykonawcęokresowa wewnętrzna weryfikacja jakości wytwarzanych produktówweryfikacja wszystkich produktów przedstawianych do odbiorupo przeglądzie produkt podlega akceptacji przez Kierownika Projektu ze strony Wykonawcyprodukty, które przeszły pomyślnie wewnętrzne przeglądy jakości mogą zostać przedstawione do odbioru przez Zamawiającego

Przeglądy zewnętrzne

przeglądy realizowane przez Zamawiającego weryfikacja jakości dowolnego produktu projektupo przedstawieniu przez Wykonawcę produktu do odbioru: weryfikacja produktów zgłoszonych do odbioru oraz przeglądy wykonywane w dowolnym czasie na żadanie Zlecającego

179


2. Wykonawca w ciągu 2 Dni Roboczych przekaże produkt w sposób opisany w „Dokumencie Zarządczym” lub też, jeżeli dokument ten nie jest jeszcze przyjęty – na adres e-mail Kierownika Projektu Zamawiającego wskazany w Umowie.

3. Zamawiający w terminie 7 Dni Roboczych dokona przeglądu jakości przekazanego produktu i:

3.1 potwierdzi brak uwag do produktu;3.2 zgłosi Wykonawcy Uwagi do produktu, w tym szczególności

wynikające z przyjętych kryteriów odbioru dla danego produktu.Uwagą może być w szczególności brak odpowiedniego postępu prac nad produktem.


4.1 przedstawienie kolejnej wersji Produktu do przeglądu jakości oraz

4.2 pisemne stanowisko w zakresie poszczególnych uwag

w terminie 5 Dni Roboczych od chwili zgłoszenia przez Zamawiającego uwag do produktu.

5. Po otrzymaniu przez Zamawiającego poprawionej wersji produktu, zgodnie z ust. 3, procedura kontroli jakości zostanie powtórzona. Strony mogą odbywać spotkania wyjaśniające i uzgodnieniowe, jednak nie później niż przez 3 Dni Robocze od otrzymania poprawionej wersji produktu przez Zamawiającego, chyba, że Zarząd Projektu poweźmie inną decyzję.

6. Dopuszcza się dwukrotną iterację dla danej kontroli jakości produktu oraz jego oceny według punktów 1-5 powyżej.

7. W przypadku nieuwzględnienia uwag w ramach dwóch iteracji Zamawiający wyznaczy Wykonawcy dodatkowy, nie krótszy niż 14 dni termin na uwzględnienie uwag, w którym powinien on zgłosić produkt do ponownego przeglądu jakości. Termin wyznaczony przez Zamawiającego, będzie na wniosek Wykonawcy skrócony, jednakże nie może być on krótszy niż 14 dni.

8. Zamawiający ponawia procedurę kontroli jakości opisaną w punktach 1-5 powyżej dla ponownego zgłoszenia produktu.

9. Za opóźnienie procedury kontroli jakości rozumiana jest suma:


180


9.1 Opóźnienia w przekazaniu aktualnej wersji produktu, o której mowa w punkcie 2.

9.2 Różnica pomiędzy terminem w jakim Wykonawca powinien przedstawić wersję produktu z uwzględnieniem zgłoszonych przez Zamawiającego uwag a terminem, w którym taka wersja została przedstawiona do procedury kontroli jakości.

Procedura będzie stosowana wyłącznie dla produktów innych niż odbieranych w drodze procedury uproszczonej. Dla produktów odbieranych w ramach procedury uproszczonej kontroli jakości nie stosuje się.


181


Załącznik nr 5 Wykorzystana technologia w obecnie działającym Systemie

a. Aplikacja webowa Portal Informacyjny oraz Panel Administracyjny

Aplikacja webowa została napisana przy wykorzystaniu języka Java, zawiera elementy HTML 5, CSS 3 oraz JavaScript przy wykorzystaniu JQuery. Wykorzystany system baz danych: PostgreSQL 9.3 oraz systemu plików.

Wykorzystane biblioteki:

Nazwa biblioteki Wersja

tapestry-core 5.3.6

tapestry-yuicompressor 5.3.6

amqp-client 2.8.1

tapestry-spring-security 3.0.2

spring-core 3.1.1

lombok 0.11.2

tapestry5-jquery 3.3.2

testng 5.14.9

easymock 3.0

hsqldb 2.0.0

servlet-api 3.0.1

jtds 1.2.4

guava 12.0

jpwgen 1.2.0

spring-rabbit 1.0.0

simplecaptcha 1.1.1

commons-io 1.3.2

ehcache-core 2.5.2

tapestry-test 5.3.6


182


selenium-java 2.23.1

selenium-server 2.23.1

postgresql 9.2-1000.jdbc4

jetty-server 7.6.7

jetty-servlet 7.6.7

jetty-webapp 7.6.7

joda-time 2.1

commons-net 2.2

mongo-java-driver 2.10.1

graylog2.gelfj 1.0.2

angularjs 1.0.7

soundmanager2 2.97a

b. Aplikacja webowa Statystyka

Aplikacja webowa została napisana przy wykorzystaniu języka Java.



tapestry-core 5.3.7

tapestry-yuicompressor 5.3.7

tapestry-hibernate 5.3.7

tapestry-jquery 3.3.1

servlet-api 3.0.1


jetty-server 7.6.7

jetty-servlet 7.6.7

jetty-webapp 7.6.7

easymock


183


got5

c. Importer danych z systemów repertoryjno-biurowych

Aplikacja wytworzona w oparciu o framework .NET 4 (w języku C#)



Ionic.zip 1.9.1.8

log4net 1.2.11

Renci.SshNet 2013.4.7

Importer dostosowany do systemu repertoryjno-biurowego Praetor wykorzystuje API systemu Praetor opartego o usługę web-service w języku programowania JAVA.



jsr311-api 1.1.1

jersey-core 1.17.1

jersey-client 1.17.1

mail (javax.mail) 1.4.7

jsch 0.1.50

log4j 1.2.16

d. Mechanizm zasilający bazę (serwer update)

Wykorzystane komponenty:

Nazwa komponentu Wersja

Implementacja Java SE 7

Dostęp do bazy danyc Hibernate 4.3.0

Logowanie slf4j, log4j

Wysyłanie maili Java mail


184


Obsługa xml JAXB

Odczyt, zapisa Apache coommon IO

Testy jednostkowe juni4, dbuni, hamcrest, mockito

Konsument zdarzeń:


guava 12.0

commons-lang3 3.1

cglib 2.2.2

spring-core 3.1.0

spring-rabbit 1.1.2

spring-amqp 1.1.2

spring-context 3.1.0

spring-context-support 3.1.0

spring-test 3.1.0

freemarker 2.3.19

testng 6.1.1

slf4j-api 1.6.4

slf4j-log4j12 1.6.4

log4j 1.2.14

javax.mail 1.4.3

commons-dbcp 1.4


spring-retry 1.0.2

mongo-java-driver 2.10.1


185


e. Moduł importu nagrań elektronicznego protokołu

Aplikacja wytworzona w oparciu o framework .NET 4 (w języku C#)



WinSCP 5.5.3

log4net 1.2.11

8. Schemat infrastruktury centralnej

Diagram przedstawia infrastrukturę sprzętową jednego z dwóch lustrzanych ośrodków przetwarzania danych - serwery, stacje robocze oraz połączenia logiczne między poszczególnymi elementami, a nie liczbę fizycznych dostępnych / realizowanych interfejsów przez dane urządzenia.


186



187


Komponenty systemu znajdują się w trzech wyróżnionych strefach: Frontend - część systemu odpowiedzialna za udostępnianie usługi użytkownikom,

dostęp do aplikacji odbywa się za pośrednictwem Internetu, zawiera instancje serwerów aplikacyjnych (frontend).Urządzenie Load balancer nie jest komponentem Systemu.

Backend - część systemu w której aktualizowane i przechowywane są wszystkie dane w systemie oraz realizowane są procesy biznesowe, zawiera instancje serwerów bazodanowych (database), serwer aplikacyjny(back office), serwer aktualizacji (update), repozytorium nagrań elektronicznego protokołu (storage), serwer kopii zapasowych (backup),

Strefa sądów – bazy danych programów repertoryjno-biurowych w liczbie ok. 1500 instancji (w przypadku systemu SAWA każdy wydział posiada osobną bazę danych, w przypadku systemu Sędzia2 jest jedna baza dla sądu, chyba że sąd posiada wydział w innej lokalizacji), repertorium plików zapisów cyfrowych posiedzeń sądowych, użytkownicy wewnętrzni systemu, lokalne repozytorium nagrań elektronicznego protokołu, przeglądarka internetowa użytkownika wewnętrznego (client), program importujący dane z systemów repertoryjno-biurowych oraz nagrania e-protokołu..

Serwery FrontendPrzeznaczenie: Zadaniem serwerów w tej strefie jest udostępnianie usługi webowej użytkownikom sieci Internet.

Zainstalowane oprogramowanie:● Debian GNU/Linux 6.0 amd64● Serwer aplikacji Jetty 8, Oracle Java 7 oraz aplikacja webowa Portal Informacyjny

Serwery DatabasePrzeznaczenie: Zadaniem serwerów jest serwowanie bazy danych na potrzeby działania aplikacji webowej Portal Informacyjny, Panel Administracyjny, serwery tworzą przezroczysty klaster 4 serwerów bazodanowych (2 dla apelacji warszawskiej i 2 dla pozostałych apelacji), dane będą replikowane (dane użytkowników) lub dystrybuowane (dane spraw) pomiędzy węzłami klastra. Z poziomu dowolnego węzła klastra widoczna jest kompletna baza informacji o sprawach. Za synchronizację danych pomiędzy węzłami odpowiedzialne są dwa serwery pgpool.

Zainstalowane oprogramowanie:● Debian GNU/Linux 7.2 amd64● Serwer bazodanowy PostgreSQL 9.3 w trybie HA (Active-Active)


188


Dane ilościowe:

Apelacja Użytkownicy SprawyDokumenty (poza

bazą danych)

Nagrania e-protokołu (poza bazą

danych)Rozmiar

bazy (GB)

warszawska 20583 938941 15633873 445892 36

wrocławska 12854 1079351 13869464 598254 46

szczecińska 6762 343441 3707404 125329 15

rzeszowska 3954 138211 1191786 69315 0,6

poznańska 11670 973503 13696739 110646 29

lubelska 7094 362373 3216993 77614 19

łódzka 8964 581360 7546555 287187 21

krakowska 11783 455279 5490356 570139 19

katowicka 9721 817208 3152024 140567 25

gdańska 10762 566782 3669767 580985 24

białostocka 6840 519450 3346622 230722 23

Suma 97727 5815052 62764218 3236650 261,6

Rozmiar zasobu przechowującego dokumenty oraz nagrania e-protokołu wynosi około 55TB.

Dane na dzień: 23.05.2017.

Serwer UpdatePrzeznaczenie3 serwery odpowiedzialne za zbieranie danych z importów i zasilenie nimi bazy danych oraz repozytorium plików dokumentów w sprawach oraz zapisów cyfrowych posiedzeń sądowych. Zawiera system kolejkowania zdarzeń dla serwera logów oraz wysyłki powiadomień e-mail.

Zainstalowane oprogramowanie:● Debian GNU/Linux 6.0 amd64● Baza danych mongodb 2.4.9● Moduł wypełniający bazy danych na serwerach bazodanowych oraz repozytorium

plików dokumentów w sprawach i zapisów cyfrowych posiedzeń sądowych, program konwertujący nagrania.

Serwer Back OfficePrzeznaczenie: Serwer ten jest odpowiedzialny za udostępnianie usługi webowej Panel Administracyjny. Znajduje się tam również instalacja portalu SMIPI (System Monitorowania


189


Interfejsów Portalu Informacyjnego) - aplikacji webowa monitorująca aplikacje importujące w sądach.

Zainstalowane oprogramowanie:● Debian GNU/Linux 7.3 amd64● Serwer aplikacji Apache 2.2.22 oraz aplikacja webowa Panel Administracyjny,

Statystyki.

Serwer StoragePrzeznaczenie: Serwery/dyski stanowiące repozytorium dokumentów w sprawach publikowanych w portalu oraz repozytorium nagrań protokołu elektronicznego

Serwer SearchPrzeznaczenie: system wyszukiwania pełnotekstowego w adnotacjach publicznych dla modułu prezentacji nagrań elektronicznego protokołu.

Zainstalowane oprogramowanie:● Debian GNU/Linux 7.3 amd64● ElasticSearch

Serwer bazodanowy w strefie sądówSerwer systemu repertoryjno-biurowego, z którym łączy się importer danych w trakcie pracy. Zainstalowane oprogramowanie:

1. Windows Server w wersji 2003 lub wyższej w wersjach 32 i 64 bitowych,2. MS SQL Server w wersji 2000 i lub wyższej.

Użytkownicy wewnętrzni (client)Wykorzystywane przeglądarki internetowe: Microsoft Internet Explorer 6 i wyższe, Mozilla Firefox 17 i wyższe, Chrome w każdej wersji.

Serwer PDFPrzeznaczenie: serwer konwertujący dokumenty tekstowe do formatu pdf na żądanie użytkownika portalu.

Serwer backupów (Backup)Przeznaczenie: backup baz danych Systemu.

Środowisko testowe oraz deweloperskieSystem posiada również środowisko testowe (2 instancje) oraz środowisko deweloperskie.


190


Jeżeli w skład infrastruktury centralnej wchodzi inne oprogramowanie Zamawiający nie jest zobowiązany wyszczególnić go na powyższej liście. Zamawiający zastrzega możliwość, że przedstawione wersje oprogramowania są wersjami najstarszymi w rzeczywistym systemie mogą występować nowsze wersje oprogramowania.

Infrastruktura sieciowa Systemu

Wszystkie serwery, stacje robocze oraz sieciowe elementy aktywne (switche) realizujące funkcjonalności sieci LAN posiadają przepustowość minimum 100 Mbit/s (Ethernet).

Sieć WAN realizowana jest poprzez łącza dedykowane o przepustowości nie mniejszej niż 1 Mbit/s.

Infrastruktura sprzętowa Systemu

Serwery w systemie występują tylko w architekturze x86. Zamawiający posiada serwery typu RACK i BLADE. Infrastruktura sprzętowa zlokalizowana jest w dwóch serwerowniach znajdujących się w obrębie administracyjnym miasta Wrocławia.

Poniższy diagram przedstawia schematyczny zarys architektury systemu internetowego portalu informacyjnego:

Na diagramie przedstawione zostały moduły systemu: Portal Informacyjny - aplikacja internetowa portalu, dostępna poprzez przeglądarkę

internetową Baza Portalu - główna baza danych portalu, źródło danych w którym przechowywane

są informacje o sprawach Broker zdarzeń - podsystem zarządzający routingiem zdarzeń publikowanych przez

Portal Konsument zdarzeń - aplikacja odpowiedzialna za przetwarzanie zdarzeń

pochodzących z dowolnych źródeł


191


Baza Logów - baza danych przechowująca informacje o aktywnościach użytkowników

Szczegółowa dokumentacja techniczna systemu PI zostanie udostępniona przez Zamawiającego na życzenie Wykonawcy po podpisaniu Umowy.


192


Załącznik nr 6 Wzory dokumentówWzory dotyczące zarządzania projektem (P.xx):

18. Agenda Spotkania – Załącznik nr P.01. do OPZ,19. Protokół ze Spotkania – Załącznik nr P.02. do OPZ,20. Dokument Zarządczy – Załącznik nr P.03. do OPZ,21. Plan Migracji Danych – Załącznik nr P.04. do OPZ,22. Raport z migracji danych – Załącznik nr P.05. do OPZ,23. Plan Szkoleń – Załącznik nr P.06. do OPZ,24. Raport z przeprowadzonych szkoleń – Załącznik nr P.07. do

OPZ,25. Raport z Testów – Załącznik nr P.08. do OPZ,26. Plan Testów – Załącznik nr P.09. do OPZ,27. Plan Uruchomienia Systemu – Załącznik nr P.10. do OPZ,28. Raport z Uruchomienia Systemu – Załącznik nr P.11. do OPZ,29. Rejestr Konfiguracji – Załącznik nr P.12. do OPZ,30. Rejestr Materiałów Projektowych – Załącznik nr P.13. do OPZ,31. Rejestr Ryzyk – Załącznik nr P.14. do OPZ,32. Rejestr Tematów Otwartych – Załącznik nr P.15. do OPZ,33. Rejestr Wymagań – Załącznik nr P.16. do OPZ,34. Rejestr Zmian – Załącznik nr P.17. do OPZ.

Wzory dotyczące kontroli jakości (K.xx):5. Scenariusze Testowe – Załącznik nr K.01. do OPZ.6. Protokół Testów Akceptacyjnych – Załącznik nr K.02. do OPZ,7. Raport Przeglądu Jakości – Załącznik nr K.03. do OPZ,8. Rejestr Jakości Projektu – Załącznik nr K.04. do OPZ.

Wzory dokumentów specjalistycznych (S.xx):9. Analiza biznesowa i systemowa – Załącznik nr S.01. do OPZ,10. Projekt Techniczny – Załącznik nr S.02. do OPZ,11. Dokumentacja Powykonawcza – Załącznik nr S.03. do OPZ,12. Dokumentacja Szkoleniowa – Załącznik nr S.04. do OPZ,13. Dokumentacja Utrzymaniowa – Załącznik nr S.05. do OPZ,14. Instrukcja stanowiskowa – Załącznik nr S.06. do OPZ,15. Podręcznik Administratora – Załącznik nr S.07. do OPZ,16. Podręcznik Użytkownika – Załącznik nr S.08. do OPZ.


193

Załącznik nr 1 do umowy.docx · Web view(z ang. Graphical User Interface) – graficzny interfejs...

Documents

Transcript of Załącznik nr 1 do umowy.docx · Web view(z ang. Graphical User Interface) – graficzny interfejs...