wroclaw.sa.gov.pl · Web viewUtrwalenie przebiegu posiedzenia sądowego za pomocą urządzenia...

Załącznik nr Z.01 do Umowy nr …... z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)

Opis Przedmiotu Zamówienia na realizację projektu: „Modyfikacje oraz utrzymanie Centralnego Archiwum

Protokołów Elektronicznych na potrzeby projektu »Wdrożenie protokołu elektronicznego w sądach powszechnych (sprawy cywilne i wykroczeniowe)«”

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

1


Spis treści1. Definicje............................................................................................................................ 52. Wprowadzenie................................................................................................................102.1 Tło projektu.................................................................................................................102.2 Linia demarkacyjna z pozostałymi projektami e-protokołu.........................................123. Opis stanu obecnego działania Cyfrowej Rejestracji Rozpraw........................................153.1 Tło prawne rejestracji rozpraw.......................................................................................153.2 Ogólny model obecnej cyfrowej rejestracji rozpraw.......................................................163.3 Oprogramowanie „RECourt”...........................................................................................203.4 Oprogramowanie RECourt Services (RCS).......................................................................253.5 Moduł Transkrypcji.........................................................................................................263.6 Central RECourt Services – CRCS.....................................................................................263.7 Centralne Archiwum Protokołów Elektronicznych (CAPE)..............................................273.7.1 Architektura logiczna Systemu............................................................................293.7.2 Agent...................................................................................................................323.7.3 Podsystem Przechowywania Danych..................................................................343.7.4 Podsystem Uwierzytelnienia i Autoryzacji...........................................................363.7.5 Portal...................................................................................................................383.7.6 System Zarządzania Archiwum............................................................................403.8 Portal Informacyjny(PI)...................................................................................................423.9 Szczegółowe informacje na temat rejestracji rozpraw na sali sądowej..........................514. Kontekstowy model wymiany danych w ramach systemu rejestracji rozpraw w docelowym modelu działania.................................................................................................555. Produkty projektu...........................................................................................................675.1 Struktura produktów i kryteria odbioru......................................................................675.2 Zarządzanie projektem................................................................................................915.2.1 Ogólne wymagania w zakresie zarządzania projektem...............................................915.2.2 Struktura projektowa..................................................................................................935.2.3 Komitet sterujący........................................................................................................935.2.4 Zarząd Projektu...........................................................................................................955.2.5 Procedury odbiorcze...................................................................................................965.2.5.1 Uproszczona procedura odbioru.............................................................................965.2.5.2 Procedura przekazania produktów.........................................................................975.2.5.3 Procedura odbioru dokumentacji...........................................................................985.2.5.4 Procedura odbioru szkoleń...................................................................................1005.2.5.5 Procedura odbioru oprogramowania....................................................................1015.2.5.6 Procedura odbioru wdrożenia...............................................................................1045.2.5.7 Procedura odbioru etapu......................................................................................1055.2.6 Procedury kontroli jakości prac.................................................................................1065.2.7 Ogólne wymagania względem dokumentacji............................................................1075.2.8 Zgodność z normami.................................................................................................1095.2.9 Zgodność z przepisami prawa...................................................................................1105.2.10 Ogólne wymagania względem kodów źródłowych................................................1125.2.11 Ogólne wymagania względem uruchomienia oprogramowania...........................1135.2.12 Ogólne wymagania w zakresie bezpieczeństwa....................................................115


2


6. Szczegółowe wymagania względem produktów...........................................................1176.1 Analiza biznesowa i systemowa................................................................................1176.2 Projekt techniczny.....................................................................................................1176.3 Modyfikacja oprogramowania agentów...................................................................1186.3.1 Modyfikacja oprogramowania RCS Agent Server......................................................1186.3.2 Utworzenie agenta eksportu PI.................................................................................1196.3.3 Utworzenie agenta eksportu CPT..............................................................................1196.3.4 Modyfikacja portalu CAPE.........................................................................................1206.3.5 Modyfikacja Podsystemu Uprawnień i Autoryzacji...................................................1206.3.6 Modyfikacja SZA........................................................................................................1216.4 Modyfikacja metadanych..........................................................................................1226.5 Modyfikacja paczki archiwalnej.................................................................................1226.6 Modyfikacja raportów...............................................................................................1226.7 Wymagania wspólne wobec agenta eksportu PI i agenta eksportu CPT...................1236.8 Testowanie oprogramowania...................................................................................1246.8.1 Scenariusze testowe..................................................................................................1246.8.2 Plan testów...............................................................................................................1246.8.3 Wykonawstwo testów...............................................................................................1256.9 Migracja danych........................................................................................................1266.10 Szkolenia................................................................................................................... 1276.10.1 Plan szkoleń...........................................................................................................1296.10.2 Szkolenia administratorów....................................................................................1306.11 Uruchomienie systemu.............................................................................................1316.12 Dokumentacja...........................................................................................................1326.12.1 Dokumentacja projektowa....................................................................................1326.12.2 Dokumentacja systemowa....................................................................................1336.12.3 Dokumentacja utrzymaniowa...............................................................................1346.12.4 Podręczniki użytkownika oraz dokumentacja szkoleniowa...................................1346.12.5 Dokumentacja bezpieczeństwa.............................................................................1346.12.6 Dokumentacja powykonawcza..............................................................................1367. Rozwiązanie równoważne.............................................................................................1367.1 Wymagania dotyczące wdrożenia rozwiązania równoważnego................................136Załączniki do OPZ:.................................................................................................................154

Załącznik nr 1 do OPZ „Dokumentacja Techniczna Centralne Archiwum Protokołów Elektronicznych”...............................................................................................................154Załącznik nr P.01. do OPZ „Agenda Spotkania”.................................................................154Załącznik nr P.02. do OPZ „Protokół ze Spotkania”...........................................................154Załącznik nr P.03. do OPZ „Dokument Zarządczy”............................................................154Załącznik nr P.04. do OPZ „Plan Migracji Danych”............................................................154Załącznik nr P.05. do OPZ „Raport z Migracji Danych”......................................................154Załącznik nr P.06. do OPZ „Plan Szkoleń”..........................................................................154Załącznik nr P.07. do OPZ „Raport z Przeprowadzonych Szkoleń”....................................154Załącznik nr P.08. do OPZ „Raport z Testów”....................................................................155Załącznik nr P.09. do OPZ „Plan Testów”..........................................................................155Załącznik nr P.10. do OPZ „Plan Uruchomienia Systemu”.................................................155Załącznik nr P.11. do OPZ „Raport z Uruchomienia Systemu”..........................................155


3


Załącznik nr P.14. do OPZ „Rejestr Ryzyk”.........................................................................155Załącznik nr P.15. do OPZ „Rejestr Tematów Otwartych”.................................................155Załącznik nr P.16. do OPZ „Rejestr Wymagań”.................................................................155Załącznik nr K.01. do OPZ „Scenariusze Testowe”............................................................156Załącznik nr K.02. do OPZ „Protokół Testów Akceptacyjnych”..........................................156Załącznik nr S.01. do OPZ „Analiza Biznesowa i Systemowa”............................................156Załącznik nr S.02. do OPZ „Projekt Techniczny”................................................................156Załącznik nr I.01 do OPZ „Specyfikacja interfejsów”.........................................................157Specyfikacja interfejsów w zakresie PI..............................................................................157Specyfikacja interfejsów w zakresie ARM.........................................................................161


4


1. DefinicjePojęcie / skrót Definicja

Agent

oprogramowanie, będące częścią Archiwum Centralnego, rezydujące na serwerach ReCourt (i/lub systemie repertoryjnym). Agent musi działać z uprawnieniami nadanymi w lokalnym AD (Active Directory) niezbędnymi dla uzyskania dostępu do zasobu sieciowego na którym przechowywane są zapisy posiedzeń

API Interfejs programistyczny (ang. Application Programming Interface)

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

CAPE Centralne Archiwum Protokołów Elektronicznych

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.

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.

Uwaga:1. Stworzenie Centralnego Portalu

Transkrypcyjnego będzie przedmiotem prac w ramach projektu „Wdrożenie protokołu elektronicznego w sądach powszechnych (sprawy cywilne i wykroczeniowe)”. Jest to więc pojęcie odnoszące się do przyszłej architektury systemów.

2. Stworzenie CPT nie jest przedmiotem niniejszego postępowania, natomiast oprogramowanie tworzone w ramach niniejszego projektu będzie z nim wymieniać dane.

CJR Centralna Jednostka Rejestrująca – specjalizowany


5


Pojęcie / skrót Definicjakomputer na sali rozpraw przeznaczony do rejestracji protokołu elektronicznego.

Dane źródłowepliki nagrań i związane z nimi metadane tworzone lokalnie, przechowywane przez system ReCourt. Dane Źródłowe mają postać katalogu z plikami.

e-protokół lub 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, którego podstawą są Art. 157. § 1 i Art. 158 KPC oraz wydane na podstawie art. 158 § 5 KPC 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).

Uwaga:Pojęcie to nie występuje w KPC – opisane wyżej pojęcie nazywane jest „protokołem”.

ePUAPPlatforma teleinformatyczna służąca do komunikacji obywateli z jednostkami administracji publicznej w ujednolicony, standardowy sposób.

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 – plik .asr nie jest składowany długoterminowo, jedynie do czasu dokonania na nim przetworzenia ARM.

KPA Kodeks Postepowania AdministracyjnegoKPC Kodeks Postepowania CywilnegoModuł Transkrypcji Pilotażowy komponent Oprogramowania

Centralnego RCS służący do zarządzania 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.


6


Pojęcie / skrót DefinicjaUwaga:Pojęcie to odnosi to stanu sprzed rozpoczęcia projektu. Docelowo funkcje w tym zakresie będzie pełnił Centralny Portal Transkrypcyjny (CPT)

Nagranie audio

Utrwalenie dźwięku z rozprawy z wszystkich czynnych urządzeń utrwalających dźwięk, o którym mowa w § 2. Ust 3) lit b. Rozporządzenia 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).

Nagranie audio-wideo

Utrwalenie obrazu i dźwięku z rozprawy z wszystkich czynnych urządzeń utrwalających obraz i dźwięk, o którym mowa w § 2. Ust 3) lit a. Rozporządzenia 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).

Oprogramowanie „RECourt” (RC)

Oprogramowanie będące własnością Ministerstwa Sprawiedliwości, które posiada pełnię praw autorskich do tego oprogramowania 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 Centralne Jednostki Rejestrujące. Dostęp udostępnianych przez Jednostkę centralną systemu rejestracji funkcji odbywa się poprzez zdefiniowane API.Oprogramowanie składa się z komponentu centralnego instalowanego na Centralnej Jednostce Rejestrującej oraz Aplikacji klienckiej protokolanta i Aplikacji klienckiej sędziego.

RECourt Services (RCS)

Oprogramowanie centralne w ramach pojedynczego sądu, pełniącym funkcje oprogramowania dostępowego do zasobów plików nagrań. Oprogramowanie RCS pozwala m.in. na:

Udostępnianie nagrań i zarządzanie nimi, Zarządzanie kontami użytkowników, Autoryzacja użytkowników, Zarządzanie Centralnymi Jednostkami

Rejestrującymi, aktualizacja i konfiguracja, Kontrola dostępu i rozliczalność akcji, Indeksacja nagrań i wyszukiwanie, Transfer plików pomiędzy sądami,


7


Pojęcie / skrót Definicja Obieg wniosków o dostęp do plików.

RR Rozwiązanie równoważneOPZ Opis Przedmiotu Zamówienia w niniejszym

postępowaniu

RECourt Player (RCP)

Przeglądarka plików nagrań udostępniana w Internecie oraz nagrywana na zewnętrznych nośnikach danych wraz z nagraniami, umożliwiającą takie operacje, jak np.:

uruchomienie, wstrzymanie, zakończenie odtwarzania,

regulacja głośności odtwarzania, przewijanie / przeskakiwanie do dowolnego

momentu nagrania, nazwy angielskie stosowane w dokumencie, Play – odtwarzaj, Record – rejestruj, REW (Rewind) – przewiń do tyłu, FF (Fast Forward) – przewiń do przodu.

Portal Informacyjny (PI)

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.

Portal Transkrypcji; PT

Portal działający na poziomie apelacji, za pomocą którego udostępniane są transkrybentom przez sądy w ramach danej apelacji nagrania audio i audio-wideo przeznaczone do manualnej transkrypcji w OT. Obecnie funkcjonuje 10 takich portali.

Uwaga:Pojęcie to odnosi to stanu sprzed rozpoczęcia projektu. Docelowo funkcje w tym zakresie będzie pełnił Centralny Portal Transkrypcyjny (CPT)

Protokół sądowy Protokół, o którym mowa w art. 157 § 1 KPC, w przypadku, o którym mowa w art. 157 § 1 KPC tj. jeżeli przebiegu posiedzenia nie utrwala się za pomocą urządzenia rejestrującego dźwięk albo obraz i dźwięk.

Uwaga:Pojęcie to nie występuje w KPC – opisane wyżej pojęcie nazywane jest „protokołem”, bez


8


Pojęcie / skrót Definicjarozróżnienia, czy zawiera on nagranie.

Protokół skrócony

Generowany na podstawie przygotowanego szablonu dokument zawierający dane rozprawy oraz adnotacje protokolanta (z wyjątkiem adnotacji wskazanych przez protokolanta, jako adnotacji nieumieszczanych w protokole skróconym). Jest to część pisemna e-protokołu

PUiAPodsystem Uwierzytelniania i Autoryzacji będący częścią Archiwum Centralnego. Komponent odpowiedzialny za zarządzanie użytkownikami systemu i ich uprawnieniami.

Paczka archiwalnaobiekt złożony z Danych Źródłowych opisany metadanymi Archiwum, gotowy do zapisu w Archiwum Centralnym

Portal CAPE

część Centralnego Systemu Zarządzania Archiwum, strona informacyjna, dostępna w środowisku Internet/Intranet. Zawiera informacje dostępne przez standardową przeglądarkę. Może zostać wyposażony w dodatkowe funkcje przetwarzania danych. Pośredniczy między użytkownikiem a mechanizmem wyszukiwania informacji w Archiwum Centralnym

Strumień audioWydzielony strumień dźwiękowy, który w sposób niezależny pozyskuje, rejestruje i odtwarza sygnał audio.

System cyfrowej rejestracji rozpraw sądowych (System)

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 „RECourt”, Oprogramowanie RECourt ServicesRCS, Central RECourt Services (CRCS), RECourt Player, Moduł Transkrypcji, Centralne Archiwum Protokołów

Elektronicznych (CAPE), Portal Informacyjny (PI).

System Zarządzania Archiwum

komponent sprzętowo-programowy, zainstalowany w środowisku infrastruktury centralnej. Zarządzający pracą agentów zainstalowanych w poszczególnych lokalizacjach oraz infrastrukturą złożoną z macierzy dyskowej i biblioteki taśmowej.


9


Pojęcie / skrót DefinicjaSystem przechowujący informacje o wszystkich zarchiwizowanych obiektach (paczkach archiwalnych) tworzący relacje pomiędzy paczkami a sprawami, gromadzący informacje o statusach spraw i na tej podstawie zarządzający politykami retencji. System komunikujący się z innymi systemami poprzez zdefiniowane usługi sieciowe, umożliwiający wyszukiwanie i udostępnianie zgromadzonych zapisów zgodnie ze zdefiniowanymi politykami bezpieczeństwa. System centralny musi być przystosowany do współpracy z innymi systemami informatycznymi w modelu SOA. Usługi sieciowe systemu centralnego muszą być zgodne z aktualną specyfikacją e-PUAP pozwalając w przyszłości na integracje z innymi systemami działającymi w administracji publicznej.

System Rozwiązanie informatyczne objęte przedmiotem Zamówienia

TAW Testy Akceptacyjne WykonawcyTAZ Testy Akceptacyjne Zamawiającego

Użytkownik końcowy

Jednostki sądów powszechnych zgodnie z ustawą z dnia 27 lipca 2001 r. Prawo o ustroju sądów powszechnych (tekst jednolity Dz. U. z 2013 r., poz. 427).

Zamawiający (MS) Ministerstwo Sprawiedliwości


10


2. Wprowadzenie2.1 Tło projektu

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.Szacowany 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.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

prowadzone 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),


11


c) Centralny system wideokonferencyjny,d) Centralne Archiwum Protokołów Elektronicznych (CAPE) – które

podlega modyfikacjom w ramach niniejszego zamówienia,e) Centralny Portal Transkrypcyjny wraz z ARM.

Niniejszy Opis Przedmiotu Zamówienia reguluje obowiązki i zakres usług Wykonawcy dotyczących postępowania „Modyfikacje oraz utrzymanie Centralnego Archiwum Protokołów Elektronicznych na potrzeby projektu »Wdrożenie protokołu elektronicznego w sądach powszechnych (sprawy cywilne i wykroczeniowe)«”.W dalszej części dokumentu przedsięwzięcie to nazwane jest „Zamówieniem”.


12


2.2 Linia demarkacyjna z pozostałymi projektami e-protokołuNa kolejnym rysunku zaprezentowano linię demarkacyjną pomiędzy systemem objętym zamówieniem, a pozostałymi systemami wchodzącymi w skład Systemu cyfrowej rejestracji rozpraw sądowych:

Rysunek 1. Zakres systemu objęty zamówieniem.


13

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)

Spośród e-usług przewidzianych do wdrożenia w ramach projektu, Zamówienie wspiera realizację poniższych e-usług:

przeprowadzenia rozprawy odmiejscowionej, udostępniania protokołu elektronicznego, automatycznej transkrypcji mowy na tekst, wirtualizacji wideokonferencji.

Pozostałe postępowania wchodzące w zakres projektu to:1. „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)«”, który zapewni mechanizmy:

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

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

udostępnianie transkrypcji, wnioskowania o udostępnianie i udostępniania protokołu

elektronicznego, wnioskowanie o dostęp do nagrań i akt w czytelni sądu, składowania udostępnianych na portalu danych.

2. „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óry zapewni mechanizmy:

zarządzania zleceniami dot. usług automatycznej transkrypcji, automatycznej transkrypcji e-protokołu z wykorzystaniem ARM, wspomagania dyktowania pism z wykorzystaniem ARM, dostawa, instalacja i konfiguracja systemu Centralnego Portalu

Transkrypcyjnego, korekty dla transkrybentów.

3 „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:

obsługi przepływu zleceń dot. usług automatycznej transkrypcji,


14


udostępniania plików w zakresie protokołu elektronicznego do publikacji,

przeprowadzenia rozprawy odmiejscowionej, realizacji streamingu posiedzenia on-line, obsługa wnioskowania i realizacji wirtualizacji wideokonferencji, realizacji rezerwacji dostępu do nagrań i akt w czytelni.

Z systemami opracowanymi i modyfikowanymi w wyniku realizacji powyższych postępowań będzie przeprowadzana integracja bezpośrednia lub pośrednia w zakresie jaki został opisany 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”.

Postępowanie w tym zakresie zostało opublikowane w dniu 31 marca 2017 pod numerem spraw: BA-F-II-3710-13/17.


15


3. Opis stanu obecnego działania Cyfrowej Rejestracji Rozpraw

3.1 Tło prawne rejestracji rozpraw

Utrwalenie przebiegu posiedzenia sądowego za pomocą urządzenia rejestrującego dźwięk albo obraz i dźwięk zostało wprowadzone przez polskiego ustawodawcę ustawą z dnia 29 kwietnia 2010 r. o zmianie ustawy – Kodeks postępowania cywilnego (Dz. U. Nr 108, poz. 684), która weszła w życie dnia 1 lipca 2010 r. Ta rewolucyjna zmiana wprowadziła zasadę, zgodnie z którą przebieg posiedzenia jawnego utrwala się za pomocą urządzeń i środków technicznych umożliwiających rejestrację dźwięku albo obrazu i dźwięku (e-potocznie protokół sądowy sporządzony w ten sposób w doktrynie nazywany jest „e-protokołem” lub „protokołem elektronicznym”). Ze względu na profity, jakie niesie za sobą sporządzanie e-protokołu, ustawodawca postanowił wprowadzić analogiczne rozwiązanie w postępowaniu w sprawach o wykroczenia, co nastąpiło ustawą z dnia 4 kwietnia 2014 r. o zmianie ustawy – Kodeks postępowania w sprawach o wykroczenia (Dz. U poz. 579), która weszła w życie z dniem 9 listopada 2014 r.

W przepisach polskiego prawa procesowego pojawiły się wraz z e-protokołem nowe instytucje prawne w postaci transkrypcji w postępowaniu cywilnym i przekładu w postępowaniu karnym. W postępowaniu cywilnym na podstawie przepisu art. 158 § 4 k.p.c. przewodniczący, o ile jest to niezbędne dla prawidłowego orzekania w sprawie, ma możliwość zarządzenia sporządzenia transkrypcji odpowiedniej części e--protokołu. Ustawodawca w postępowaniu w sprawach o wykroczenia transkrypcję nazwał „przekładem”.


16


3.2 Ogólny model obecnej cyfrowej rejestracji rozpraw

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


17


Rysunek 2. Schemat współpracy systemów RECourt, RCS oraz CRCS.

Na poziomie sądów podstawową jednostką są instalacje na poziomie sal sądowych, które są w dużej mierze autonomiczne (znajduje się tam Centralna Jednostka Rejestrująca, oraz stacje sędziego i protokolanta). Oprogramowanie wspomagające ten proces scharakteryzowano w sekcji 3.3, a szczegóły w zakresie sposobu rejestracji rozpraw – w sekcji 3.9.

Instalacje na poziomie sądów są zarządzane z wykorzystaniem oprogramowania RECourt Services opisane w sekcji 3.4. Oprogramowanie to posiada również wersje klienckie pozwalające na wykorzystywanie systemu przez:

sekretariaty (np. w celu wprowadzenia szczegółów planowanych rozpraw),

czytelnie (w celu udostępnienia plików e-protokołu – np. w przypadkach, gdy zapisu ze względów prawnych nie wydaje się) oraz

administratorów lokalnych systemu.

Na poziomie centralnym (CKIS we Wrocławiu) funkcjonowanie instalacji w poszczególnych sądach jest nadzorowane przeze oprogramowanie CRCS scharakteryzowane w sekcji 3.6.

Poza tym schematem funkcjonuje oprogramowanie RECourt Player, które jest możliwe do ściągnięcia przez każdego użytkownika w celu samodzielnego przesłuchania lub obejrzenia e-protokołu. Oprogramowanie to zostało scharakteryzowane w sekcji 3.3

Na kolejnym schemacie (Rysunek 3) przedstawiono współpracę oprogramowania RC / RCS /CRS z pozostałymi elementami Systemu tj.:

Centralnym Archiwum Protokołów Elektronicznych (sekcja 3.7) Modułem Transkrypcji (sekcja 3.5), Portalem Informacyjnym (sekcja 3.8) oraz Centralna Infrastrukturą Wideokonferencyjną (sekcja 3.9).

W tym zakresie wskazać należy na następujące procesy realizowane w systemie:

1. Gromadzenie e - protokołów w CAPE


18

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)Ze względu na ograniczone możliwości przechowywania e-protokołów w Sądach, przesyłane są one do CAPE, gdzie są przechowywane długoterminowo co uwidoczniono na schemacie „e-protokół{x}, źródło Sąd{y}”. Oprogramowanie to pozwala na przesyłanie informacji o e-protokołach (na rysunku: „Wnioski Cape Info”) i – w razie potrzeby przesyłania pomiędzy sądami, a także udostępniania w ramach Portalu Informacyjnego z wykorzystaniem Agenta Importu CAPE, Importera nagrań do Portalu oraz Importera PI). Wnioski transferu danych między sądami są koordynowane przez oprogramowanie CRCS.

2. Wnioskowanie o transkrypcje e - protokołu

W przypadku konieczności dokonania transkrypcji fragmentu e-protokołu, stosowny wniosek (na rysunku: Wnioski (…) Transcript) jest przesyłany do Modułu Transkrypcji i zarządzany przez oprogramowanie CRCS (na rysunku: Wnioski transkrypcji).

3. Udostępnianie e - protokołu i danych spraw w Portalu Informacyjnym W przypadku, gdy Użytkownik Portalu Informacyjnego zawnioskuje o udostępnienie sprawy na portalu (na rysunku Info need po lewej stronie) stosowne dane oraz e-protokół są przesyłane do portalu przez uwidoczniony na schemacie Importer PI korzystający z Repertorium oraz importujący e-protokół (na rysunku: Importer nagrań do portalu).

4. Udostępnianie e - protokołu w postaci nagrania na nośniku zewnętrznym

W określonych sytuacjach udostępnienie protokołu odbywa się na wniosek użytkownika (na rysunku „Info need” na dole, obok sekretariatu), poprzez nagranie z wykorzystaniem Klienta RCS płyty, która jest przekazywana lub wysyłana pocztą.

5. Wykorzystanie Centralnej Infrastruktury Telekonferencyjnej W przypadku przeprowadzania dowodu na odległość, a także innych przpadkach przewidzianych w procedurze system wykorzystuje Centralną infrastrukturę wideokonferencyjną do przeprowadzania Wideokonferencji (na rysunku „Wideokonferencja”).


19


Rysunek 3. Rozwinięty schemat architektury.


20


3.3 Oprogramowanie „RECourt”

Oprogramowanie „RECourt” funkcjonuje w salach sądowych i jest zainstalowane na:

Centralnej Jednostce Rejestrującej (CJR), stacji protokolanta oraz stacji sędziego.

Instalacja na CJR wykorzystuje szereg natywnych mechanizmów tego urządzenia, 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” komunikuje się przez połączenie sieciowe 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 – przywoływania), Prezentacja dowodów w postaci elektronicznej,


21


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.

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 dokonanie 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).


22


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 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.


23


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. 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ę


24


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. Następnie zapis przekazywany jest do sądowego repozytorium nagrań. Wyjątkiem jest wstrzymanie nagrania.

Ze względów bezpieczeństwa System umożliwia bezpośrednio po zakończonej sesji nagraniowej wybranie archiwizacji 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.

10. Udostępnianie nagrania w sądzie W ramach oprogramowanie RECourt zbudowana została centralna książka adresowa pozwalająca na łatwe odszukanie danej lokalizacji oraz nawiązanie połączenia wideokonferencyjnego z wybranym wideoterminalem. 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.

Dodatkowym komponentem jest odtwarzacz nagrań RECourt Player, 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ń RECourt Player 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


25

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)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.

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 RC pracuje na CJR, pod kontrolą systemu operacyjnego Linux. Oprogramowanie wykorzystuje szereg natywnych mechanizmów urządzenia, 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 strumień audio osobno) oraz znacznika czasu.

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

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

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


26


3.4 Oprogramowanie RECourt Services (RCS)

Oprogramowanie 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, 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 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,6. Modyfikacja niektórych parametrów sprawy,7. Zarządzanie centralnymi jednostkami rejestracyjnymi,

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. Przekazania nagrania do transkrypcji i odbiór transkrypcji,15. Statystyka i raportowania,16. Integracja z innymi systemami poprzez zdefiniowane API,17. Edycja nagrań/fragmentów nagrań, protokołów skróconych i

adnotacji,


27


18. Obsługa listy zadań do wykonania dla użytkowników.

3.5 Moduł Transkrypcji

Moduł Transkrypcji stanowi dodatkowy, prototypowy komponent Oprogramowania CRCS służący do zarządzania 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.

3.6 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.

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.


28


deployment Architektura RC

CRCS

RCS w Sądzie 1

RCS w Sądzie 2

RCS w Sądzie 3 RCS w Sądzie ...

RCS w Sądzie nr 380

Wymiana danych między Sądami

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.

Nadzór

«zarządza»

Rysunek 4. Współpraca RCS i CRCS.


29


3.7 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 projekt obejmuje również lokalizację zapasową, w której zainstalowana została Biblioteka Taśmowa przechowująca kopię danych zgromadzonych w lokalizacji podstawowej.

Szczegółowy opis architektury CAPE, został zawarty w Załączniku nr 1 do OPZ „Dokumentacja Techniczna Centralne Archiwum Protokołów Elektronicznych”.

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 indeksu.

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

(dalej indeks),3. komponenty programowe instalowane lokalnie (Agent) oraz

narzędzia i mechanizmy służące do ich zarządzania.


30

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)3.7.1 Architektura logiczna Systemu

cmp DCO-001 Architektura systemu

Infrastruktura Archiwum CentralnegoInfrastruktura lokalna sądu

Centralne AD

Name: DCO-001 Architektura systemuAuthor: Piotr FusVersion: 1.0Created: 2015-08-11 17:17:24Updated: 2015-11-05 13:52:34

Stacje robocze

Podsystem Przechowywania Danych


Podsystem Uwierzytelniania i Autoryzacj i

Zarządzanie retencją

Portal

UwierzytelnienieAutoryzacjaRejestr zdarzeńSłowniki

REST

RCSCRCS

Web Manager

RCS Agent Server SCP Storage

SCP

SCPPobieranie danych spraw i plików nagrań

Zarządzanie

Zarządzanie

Zarządzanie agentami

Zasób lokalny

WAN

Rysunek 5. Architektura systemu CAPE


31


CRCSJest to system nadzorujący pracę lokalnych systemów RCS.

Centralne AD

RCSJest to system źródłowy z danymi spraw oraz z plikami nagrań rozpraw sądowych.

RCS Agent ServerModuł agenta do zbierania danych spraw, pobierania plików z nagraniami rozpraw sądowych i obsługi przesyłania/pobierania paczek archiwalnych do/z archiwum CAPE.

SCP StorageCentralny zasób dyskowym służący udostępnianiu paczek archiwalnych w ramach przesyłania/pobierania paczek do/z archiwum CAPE.W zasobie tym będą odpowiednie podkatalogi określające kierunek przesyłania paczek.

Stacje robocze Zasób lokalny

Web ManagerRealizowane funkcje to:

Podgląd działających agentów (wersji, stanu, typu) Zarządzanie działaniem agentów (włączenie, wyłączenie) Możliwość aktualizacji agenta wg typu.

Podsystem Przechowywania Danych (PPD) Urządzenia archiwizującego; Macierzy dyskowej; Biblioteki taśmowej;

Podsystem Uwierzytelniania i Autoryzacji

Portal

System Zarządzania Archiwum (SZA)


32

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)3.7.2 Agent

cmp DCO-012 Komunikacja Agenta z CAPE

Name: DCO-012 Komunikacja Agenta z CAPEAuthor: Mirosław GurbaVersion: 1.0Created: 2015-08-26 11:48:06Updated: 2015-11-05 16:41:03


(from Architektura systemu)

Architektura systemu::SCP

Storage

Architektura systemu::Web

Manager

Portal

(from Architektura systemu)

Architektura systemu::RCS Agent Serv er

Rysunek 6. Komunikacja Agenta z CAPE


33


Komunikacja i sposób pobierania danych oparta jest na przesyłaniu plików poprzez zasób centralny SCP. Do zasobu tego wgrywane są przez RCS Agent Server pliki z paczkami archiwalnymi w trakcie wysyłania ich do archiwum CAPE. Do zasobu tego wgrywane są przez SZA pliki z paczkami archiwalnymi, a następnie pobrania przez RCS Agent Server w celu udostępnienia na zasobie lokalnym. Potwierdzenia w ramach komunikacji RCS Agent Server <-> CAPE realizowane są poprzez wgrywanie na ten zasób plików XML.

Dodatkowo z Portalu realizowane jest przekierowanie do aplikacji Web Manager realizującej zarządzanie i monitowanie instancji RCS Agent Server.

RCS Agent ServerModuł agenta do zbierania danych spraw, pobierania plików z nagraniami rozpraw sądowych i obsługi przesyłania/pobierania paczek archiwalnych do/z archiwum CAPE.

SCP StorageElement systemu będący zasobem dyskowym służącym udostępnianiu paczek archiwalnych w ramach przesyłania/pobierania paczek do/z archiwum CAPE.W zasobie tym będą odpowiednie podkatalogi określające kierunek przesyłania paczek.


34

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)3.7.3 Podsystem Przechowywania Danych

cmp DCO-003 Podsystem Przechowywania Danych

System Zarządzania Środowiskiem TaśmowymObject Storage

Swift Proxy

memcached

account container object

TSM

System Zarządzania Archiwum::Job

Manager

System Zarządzania Archiwum::Tape

Manager

Macierz dyskowa Biblioteka taśmowa

Name: DCO-003 Podsystem Przechowywania DanychAuthor: Krzysztof RączkiewiczVersion: 1.0Created: 2015-08-13 00:00:00Updated: 2015-08-27 14:35:27

Rysunek 7. Podsystem Przechowywania Danych


35

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)PPD przechowuje i zarządza danymi w systemie CAPE.

Biblioteka taśmowa

Macierz dyskowa

Swift Proxy

TSM

Account

Container

Memcached

Object

Urządzenie archiwizujące Comarch iBard Archive Manager.Urządzenie archiwizujące zbudowane jest w oparciu o otwarty system obiektowego przechowywania plików Openstack Swift. Oprogramowanie to zbudowane jest na bazie języka programowania Python. Do uwierzytelnienia żądań w ramach rozwiązania Swift wykorzystywany jest komponent Openstack Keystone. Jako pamięć podręczna wykorzystywana jest aplikacja memcached.W celu rozłożenia ruchu pomiędzy węzłami wykorzystywany jest serwer HAProxy.Do pracy z biblioteką taśmową wykorzystano narzędzia aplikacji IBM TSM.


36

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)3.7.4 Podsystem Uwierzytelnienia i Autoryzacji

cmp DCO-006 Podsystem Uwierzytelniania i Autoryzacj i

PUiA

CSUiA CAS

ER

Name: DCO-006 Podsystem Uwierzytelniania i AutoryzacjiAuthor: Piotr FusVersion: 1.0Created: 2015-08-12 09:40:21Updated: 2015-08-21 11:29:18

Architektura systemu::Centralne AD

Import użytkowników

Rejestr zdarzeń zbiera zdarzenia biznesowe z całego systemu

Delegacja uwierzytelnienia

DM

Autoryzacja

Słowniki

Rysunek 8. Podsystem Uwierzytelniania i Autoryzacji


37


CASCAS nie dokonuje uwierzytelnienia samodzielnie, lecz deleguje je do centralnego AD.

CSUiA

DM

ER

W ramach podsystemu PUiA wdrożony został gotowy produkt Comarch CSUiA. CSUiA jest produktem opartym o stos Java EE 7. W szczególności, warstwa dostępu do danych zrealizowana jest przy użyciu standardu odwzorowania obiektowo-relacyjnego JPA 2. Do zarządzania transakcjami oraz realizacji logiki biznesowej używane są komponenty EJB w wersji 3.2. Jako warstwa prezentacji używana jest biblioteka JSF 2 z szablonami tworzonymi w technologii Facelets. Jeden z komponentów, CAS, jest oparty na stosie Spring Framework. Całość uruchamiana jest na serwerze aplikacyjnym WildFly 8 działającym pod kontrolą wirtualnej maszyny Javy implementowanej przez Oracle (HotSpot) w wersji 8.Warstwa trwałości opiera się o dwie bazy danych. Pierwszą z nich jest relacyjna baza danych PostgreSQL, służąca do przechowywania danych komponentu CAS oraz transakcyjnych, statycznych danych komponentu CSUiA, czyli użytkowników, ról i uprawnień. Drugą bazą danych jest dokumentowa baza MongoDB, służąca jako cache uprawnień użytkowników, w celu szybszego dostępu. Ponadto baza ta jest wykorzystywana jako warstwa danych dla nietransakcyjnych danych: rejestru zdarzeń oraz słowników.Dokumentacja:https://docs.oracle.com/javaee/7/index.htmlhttp://www.postgresql.org/docs/http://docs.mongodb.org/manual/


38

http://docs.mongodb.org/manual/

http://www.postgresql.org/docs/

https://docs.oracle.com/javaee/7/index.html


3.7.5 Portal

Rysunek 9. Rysunek 1: Portal

Core

RiS

Web

Podsystem Portalu opiera się na stosie technologicznym opartym o dwa podstawowe komponenty. Pierwszym jest stos Spring Framework, na który składają się liczne biblioteki odpowiadające za transakcyjność, kontrolę dostępu oraz obsługę błędów. Po stronie interfejsu użytkownika kluczową rolę pełni DHTML, oparty o bibliotekę AngularJS i HTML5. Technologie takie


39

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)pozwalają na zwiększenie szybkości i ergonomii działania, przy jednoczesnym zmniejszeniu obciążenia zasobów serwera.Serwer aplikacyjny na którym stoi Portal to WildFly, natomiast wykorzystywana baza danych to PostgreSQL.http://spring.io/docshttps://angularjs.org/http://www.w3schools.com/html/html5_intro.asp


40

http://www.w3schools.com/html/html5_intro.asp

https://angularjs.org/

http://spring.io/docs

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)3.7.6 System Zarządzania Archiwum

cmp DCO-004 System Zarządzania Archiwum


Interfejs REST API

Interfejs Administratora

Rzdzeń aplikacj i

Job ManagerZarządzanie metadanymi

Tape Manager Podsystem Przechowywania

Danych::TSM

Zarządzanie retencją, wczytywanie i odczytywaniem objektów.

Podsystem Przechow ywania

Danych::Swift Proxy

Name: DCO-004 System Zarządzania ArchiwumAuthor: Krzysztof RączkiewiczVersion: 1.0Created: 2015-08-13 00:00:00Updated: 2015-08-27 14:34:03

Rysunek 10. System Zarządzania Archiwum


41


Interfejs Administratora

Interfejs REST API

Job Manager

Rdzeń aplikacji

Tape Manager

Zarządzanie metadanymi

Rozwiązanie działa w oparciu o oprogramowanie zainstalowane na systemie operacyjnym Redhat w wersji 7. Pomijając część z systemem zarządzania środowiskiem taśmowym, który to zainstalowany jest bezpośrednio na fizycznym serwerze, systemy operacyjne Redhat 7 zainstalowane są na wirutalnych maszynach. Wykorzystanym wirtualizatorem jest Red Hat Enterprise Virtualization (RHEV) w wersji 3.5.

Rdzeniem Systemu Zarządzania Archiwum jest aplikacja zbudowana na bazie platformy programistycznej Django w wersji 1.8, w oparciu o język Python w wersji trzeciej. Wykorzystane zostały wbudowane mechanizmy dostępu do danych (Django ORM), system szablonów (DTL) oraz bibliotekę umożliwiającą budowę API w stylu REST.Aplikacja uruchomiona jest z wykorzystanie serwera aplikacyjnego wsgi Gunicorn w wersji 19.3 oraz serwera HTTP Nginx.SZA wykorzystuje do przetwarzania zadań w tle system zadań Celery w wersji 3, który wykorzystuje aplikację RabbitMQ jako pośrednika komunikatów (message broker).Dla przechowywania danych wykorzystano relacyjną bazę danych PostgreSQL oraz Elasticsearch - dokumentową bazę wyposażoną w silnik wyszukiwania oparty o Apache Lucene.

3.8 Portal Informacyjny(PI)

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.:


42


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.

Podstawowa funkcjonalność Portalu Informacyjnego:


43

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)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;


44


b. harmonogram uruchomienia;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” (Załącznik nr 2 do Regulaminu) 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 składały „Oświadczenie” i podpis kwalifikowany 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.


45

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)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 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 danychZadaniem 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.Zakres pobieranych danychProces 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


46


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, 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);


47


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; 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ść;

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ą


48


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 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ącegoProgram 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


49

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)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ącegoKonfiguracja 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 SystemuMechanizm 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 PosgreSQL 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).


50


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.

Zakres pobieranych danych na potrzeby publikacji e-protokołuProgram importujący pobiera z lokalnego repozytorium następujące pliki:

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.


51

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)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.

Prezentacja nagrań e-protokołu w Portalu InformacyjnymWizualizacja 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ówMechanizmy 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.


52


3.9 Szczegółowe informacje na temat rejestracji rozpraw na sali sądowej

Poniższy rysunek przedstawia przykład wymaganego rozmieszczenia mikrofonów na salach rozpraw. Rozmieszczenie mikrofonów zostało przedstawione w podziale na Strefy rejestracji dźwięku oraz wymagane obszary rejestracji obrazu.

Rysunek 11. Przykład wymaganego rozmieszczenia mikrofonów na salach rozpraw.

System rejestruje sygnał z każdego z mikrofonów stacjonarnych, jako oddzielny kanał audio dla każdej z czterech stref. System rejestruje również sygnał gniazda mikrofonu mobilnego (dodatkowego) oraz jako oddzielny kanał audio. Rejestracja oddzielnego kanału audio możliwa jest również dla odtwarzanego podczas rozprawy fragmentu bieżącej lub archiwalnej rozprawy, sygnału audio pochodzącego z połączenia


53

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)wideokonferencyjnego oraz sygnału audio z prezentacji dowodu elektronicznego.

W każdej sali zamontowanych musi być od 8 do 16 mikrofonów stacjonarnych oraz gniazdo do podłączenia mikrofonów ruchomych.

Ilości zamontowanych mikrofonów stacjonarnych na sali rozpraw (od 8 do 16) są uzależnione od decyzji Użytkowników końcowych, które zostają zobrazowane w Projekcie Technicznym. Instalacja mikrofonów w części sal może obejmować dla Strefy III i Strefy IV również dodatkowe rzędy stołów. W każdej ze stref III i IV musi zostać zamontowane od 2 do 6 mikrofonów stacjonarnych.

Sygnał z poszczególnych stref musi być rejestrowany w następującej liczbie osobnych kanałów audio:

Strefa

Ilość mikrofonów stacjonarnych

Ilość gniazd mikrofonów ruchomych

Wymagana liczba osobnych kanałów audio

Przypisanie mikrofonów do osobnych kanałów

Stre

fa I

od 1 do 3 0 3

Nie dopuszcza się łączenia sygnału z mikrofonów stacjonarnych w ramach dostępnych dla strefy kanałów audio.Sygnał z każdego mikrofonu musi być rejestrowany jako osobny kanał audio.

Stre

fa II

1 1 2

Mikrofon stacjonarny oraz gniazdo mikrofonu ruchomego muszą być rejestrowane jako osobne kanały audio.


54


Stre

fa II

I

od 2 do 6 0

2 w konfiguracji domyślnej

6 w konfiguracji rozszerzonej


Stre

fa IV

od 2 do 6 0

2 dlakonfiguracji domyślnej

6 dla konfiguracji rozszerzonej


Dodatkowa jako osobne kanały audio powinien być również rejestrowane:

sygnał audio z połączenia wideokonferencyjnego, sygnał audio z dodatkowego urządzenia stanowiącego źródło

prezentacji dowodu elektronicznego (np. laptop, kamera cyfrowa, rejestrator DVR)

sygnał audio pochodzący z odtworzenia podczas fragmentu bieżącej rozprawy lub nagrania archiwalnego.

Łączna liczba rejestrowanych jednocześnie osobnych kanałów audio w konfiguracji domyślnej – 12.

Łączna liczba rejestrowanych jednocześnie osobnych kanałów audio w konfiguracji rozszerzonej – 20.

Do rejestracji obrazu sala musi być wyposażona w dwie kamery rejestrujące obraz w następujący sposób:

obraz widoku ogólnego sali z pozycji przewodniczącego, ze szczególnym uwzględnieniem widoku wszystkich pozostałych


55


osób uczestniczących w posiedzeniu jawnym oraz jeśli pozwalają na to względy techniczne – publiczności;

obraz osoby wypowiadającej się z miejsca przeznaczonego dla świadka, obejmujący polem widzenia górną połowę ciała w sposób umożliwiający utrwalenie gestów oraz uzyskanie widoku twarzy za wyjątkiem składu orzekającego.

Źródła obrazu z kamer są miksowane przez Jednostkę centralną systemu rejestracji do jednego kanału obrazu. Dołączenie dodatkowych strumieni obrazu, tj:

wideokonferencja, prezentacja dowodu elektronicznego z zewnętrznego

urządzenia podłączonego do złącza D-SUB lub HDMI (np. laptop, kamera cyfrowa, rejestrator DVR),

odtworzenie bieżącego lub archiwalnego nagrania podczas rejestracji,

powoduje automatyczną zmianę trybu ekranowego w podziale, co najmniej na tyle części ile jest aktywnych źródeł obrazu.

Wymagany podział ekranu dla 2 źródeł sygnału musi stanowić taki układ ekranowy, aby obraz osoby wypowiadającej się z miejsca dla świadka stanowił okno w obrazie widoku ogólnego sali.

Przykładowy szkic poniżej:


56


Rysunek 12. Przykładowy szkic układu ekranu.

Dodatkowo Jednostka centralna systemu rejestracji musi umożliwiać zmianę układu obrazu co najmniej w zakresie:

Ustawienia wielkości okna widoku z kamery na świadka; Ustawienia wielkości okna prezentacji dowodu

elektronicznego; Ustawienia wielkości okna wideokonferencji; Ustawienia wielkości okna odtworzenia bieżącego lub

archiwalnego nagrania podczas rejestracji; Ustawienie pozycji na ekranie, w jakiej wyświetlane są okna:

widoku z kamery na świadka, prezentacji dowodu elektronicznego, wideokonferencji, odtworzenia bieżącego lub archiwalnego nagrania podczas rejestracji.


57


4. Kontekstowy model wymiany danych w ramach systemu rejestracji rozpraw w docelowym modelu działania

4.1.1 Wymiana danych w zakresie automatycznej transkrypcji e-uzasadnienia

Obsługa e-uzasadnienia:1) Automatyczna transkrypcja ARM wszystkich e-uzasadnień:

a) CRCS→CPT: zlecenie wykonania ARM dla pliku e-uzasadnienia (pliki e-uzasadnienia w formacie .asr, parametry zlecenia - lista) – zwrot wartości: numer przydzielony do zleceniaParametry zlecenia – lista:

o rodzaj zlecenia (automatyczna transkrypcja),o zleceniodawca (sąd; wydział),o osoba składająca wniosek (imię i nazwisko; numer telefonu),o wymagany termin realizacji zlecenia,o sygnatura akt,o rodzaj nagrania (e-uzasadnienie),o przedziały czasowe nagrania do przetworzenia (pełen zakres).

b) CPT→CRCS: przekazanie produktów automatycznej transkrypcji e-uzasadnienia (nr zlecenia, pliki transkrypcji e-uzasadnienia w formatach xml i rtf) – zwrot wartości: informacja potwierdzająca przyjęcie plików.

2) Korekta plików automatycznej transkrypcji ARM e-uzasadnienia:a) CRCS→CPT: zlecenie wykonania korekty dla pliku ARM

e-uzasadnienia (pliki ARM e-uzasadnienia w formacie xml, rtf; ścieżka w CAPE do pliku nagrania e-uzasadnienia; protokół skrócony; metadane nagrania wraz ze słownikiem uczestników; parametry zlecenia - lista) – zwrot wartości: informacja potwierdzająca przyjęcie do realizacji i numer przydzielony do zleceniaParametry zlecenia – lista:

o rodzaj zlecenia (korekta),o zleceniodawca (sąd; wydział),o osoba składająca wniosek (imię i nazwisko; numer telefonu),o wymagany termin realizacji zlecenia,o sygnatura akt,o informacja o przekazaniu dla zlecenia wniosku o zmianę

terminu realizacji,o rodzaj nagrania (e-uzasadnienie),


58


o przedziały czasowe nagrania do przetworzenia (od-do).b) CPT→CAPE: pobranie pliku nagrania e-uzasadnienia (ścieżka do

pliku nagrania e-uzasadnienia) – zwrot wartości: plik nagrania e-uzasadnienia

c) CPT→CRCS: przekazanie produktów procesu korekcyjnego e-uzasadnienia (nr zlecenia, pliki pełnej transkrypcji e-uzasadnienia w formatach xml i rtf; komentarze OKZT) – zwrot wartości: informacja potwierdzająca przyjęcie plików

d) CRCS→CPT: potwierdzenie poprawności jakości produktów przez sąd (nr zlecenia, status jakości) – zwrot wartości: informacja potwierdzająca przyjęcie statusu.Jeżeli status jest pozytywny CPT odnotowanie zakończenie procesu obsługi zlecenia i dokonuje kasacji plików źródłowych zlecenia. Jeżeli status jest negatywny (niska jakość transkrypcji) – pliki zlecenia w CPT nie są kasowane.


59

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)Powyższe powiązania przedstawiono na diagramie:

Rysunek 13. Model wymiany danych dot. obsługi transkrypcji e-uzasadnienia.


60


4.1.2 Wymiana danych w zakresie udostępniania protokołu elektronicznego

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.

Niniejsze Zamówienie obejmuje jedynie realizację tych interfejsów, które wskazane zostały jako dostarczane przez CAPE. Pozostałe interfejsy zostały zobrazowane tu wyłącznie w celu przedstawienia kontekstu przepływu informacji między systemami w realizowanych procesach biznesowych Zamawiającego, których interfejsy CAPE są integralną częścią.


61


Rysunek 14. Model wymiany danych w zakresie udostępniania e-protokołu i e-uzasadnienia oraz rezerwacji czytelni

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]


62

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)1) 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)

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

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


63


4.1.3 Wymiana danych w zakresie udostępniania protokołu elektronicznego na potrzeby streamingu

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 modyfikacji portalu PI 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:

Rysunek 15. Model wymiany danych w zakresie importu nagrań

[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)Projekt współfinansowany przez Unię Europejską ze środków

Europejskiego Funduszu Rozwoju Regionalnego64


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


65


4.1.4 Wymiana danych w zakresie automatycznej transkrypcji e-protokołu

Obsługa e-protokołu:1) Zlecenie pełnego procesu transkrypcji e-protokołu tj. realizowana w

jednym zleceniu automatyczna transkrypcja ARM wraz z realizowaną od razu korektą wyników automatycznej transkrypcji e-protokołu:a) CRCS→CPT: zlecenie wykonania pełnej transkrypcji dla pliku

e-protokołu (ścieżka w CAPE do pliku nagrania e-protokołu; protokół skrócony; metadane nagrania wraz ze słownikiem uczestników; parametry zlecenia - lista) – zwrot wartości: numer przydzielony do zleceniaParametry zlecenia – lista:

o rodzaj zlecenia (pełna transkrypcja),o zleceniodawca (sąd; wydział),o osoba składająca wniosek (imię i nazwisko; numer telefonu),o wymagany termin realizacji zlecenia,o sygnatura akt,o informacja o przekazaniu dla zlecenia wniosku o zmianę

terminu realizacji,o rodzaj nagrania (e-protokół),o przedziały czasowe nagrania do przetworzenia (od-do).

b) CPT→CAPE: pobranie pliku nagrania e-protokołu (ścieżka do pliku nagrania e-protokołu) – zwrot wartości: plik nagrania e-protokołu

c) CPT→CRCS: przekazanie produktów procesu korekcyjnego e-protokołu (nr zlecenia, pliki pełnej transkrypcji e-protokołu w formatach xml i rtf, komentarze OKZT) – zwrot wartości: informacja potwierdzająca przyjęcie plików

d) CRCS→CPT: potwierdzenie poprawności jakości produktów przez sąd (nr zlecenia, status jakości) – zwrot wartości: informacja potwierdzająca przyjęcie statusu.Jeżeli status jest pozytywny CPT odnotowanie zakończenie procesu obsługi zlecenia i dokonuje kasacji plików źródłowych zlecenia. Jeżeli status jest negatywny (niska jakość transkrypcji) – pliki zlecenia w CPT nie są kasowane.

2) Automatyczna transkrypcja ARM e-protokołu (na zlecenie sądu/strony postępowania):a) CRCS→CPT: zlecenie wykonania ARM dla pliku e-protokołu (ścieżka

w CAPE do pliku nagrania e-protokołu; parametry zlecenia - lista) – zwrot wartości: informacja potwierdzająca przyjęcie do realizacji i numer przydzielony do zleceniaParametry zlecenia – lista:


66


o rodzaj zlecenia (automatyczna transkrypcja),o zleceniodawca (sąd; wydział),o osoba składająca wniosek (imię i nazwisko; numer telefonu),o wymagany termin realizacji zlecenia,o sygnatura akt,o rodzaj nagrania (e-protokół),o przedziały czasowe nagrania do przetworzenia (od-do).

b) CPT→CAPE: pobranie pliku nagrania e-protokołu (ścieżka do pliku nagrania e-protokołu) – zwrot wartości: plik nagrania e-protokołu

c) CPT→CRCS: przekazanie produktów automatycznej transkrypcji e-protokołu (nr zlecenia, pliki transkrypcji e-protokołu w formatach xml i rtf) – zwrot wartości: informacja potwierdzająca przyjęcie plików.


67

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)Powyższe powiązania przedstawiono na diagramie:

Rysunek 16. Model wymiany danych dot. obsługi transkrypcji e-protokołu.

Poprawa transkrypcji w OT na wniosek sądu:1) Poprawa plików wynikowych z procesu korekt w OT – może dotyczyć

zarówno e-protokołu, jak i e-uzasadnienia:a) CRCS→CPT: zlecenie wykonania poprawy dla plików transkrypcji (nr

zlecenia poprawianego, uwagi sądu, parametry zlecenia - lista) –


68


zwrot wartości: informacja potwierdzająca przyjęcie do realizacji i numer przydzielony do zleceniaParametry zlecenia – lista:

o rodzaj zlecenia (poprawa),o osoba składająca wniosek (imię i nazwisko; numer telefonu),o wymagany termin realizacji zlecenia,o przedziały czasowe nagrania do poprawy (od-do) – jeżeli inny

niż poprzednio.

b) CPT→CRCS: przekazanie produktów procesu poprawy (nr zlecenia, pliki pełnej transkrypcji w formatach xml i rtf; komentarze OKZT) – zwrot wartości: informacja potwierdzająca przyjęcie plików

c) CRCS→CPT: potwierdzenie poprawności jakości produktów przez sąd (nr zlecenia, status jakości) – zwrot wartości: informacja potwierdzająca przyjęcie statusu.Jeżeli status jest pozytywny CPT odnotowanie zakończenie procesu obsługi zlecenia i dokonuje kasacji plików źródłowych zlecenia. Jeżeli status jest negatywny (niska jakość transkrypcji) – pliki zlecenia w CPT nie są kasowane – procedura poprawy może zostać powtórzona.

Powyższe powiązania przedstawiono na diagramie:

Rysunek 17. Model wymiany danych dot. obsługi procesu poprawy błędnie zrealizowanej transkrypcji.

Pozostałe interakcje systemów CRCS i CPT:


69

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)6) Wysyłka ponaglenia przez sąd – realizowana w sytuacji wystąpienie przeterminowania zlecenia, może dotyczyć zarówno zlecenia dot. e-protokołu, jak i e-uzasadnienia – przekazywane jest w systemie CPT do OKZT:

a) CRCS→CPT: ponaglenie (nr zlecenia) – zwrot wartości: informacja potwierdzająca przyjęcie informacji

7) Wniosek OKZT do sądu o zmianę terminu realizacji zlecenia korekty – może dotyczyć zarówno zlecenia dot. e-protokołu, jak i e-uzasadnienia:

a) CPT→CRCS: wniosek o zmianę terminu (nr zlecenia) – zwrot wartości: informacja potwierdzająca przyjęcie informacji

b) CRCS→CPT: odpowiedź na wniosek (nr zlecenie, stanowisko sądu) – zwrot wartości: informacja potwierdzająca przyjęcie informacjiOdnotowanie wyniku wniosku w CPT i ewentualna stosowna zmiana terminu zlecenia w CPT.

8) Anulowanie zlecenia przez sąd – może dotyczyć każdego typu zlecenia (poprawa/korekta/transkrypcja itd.), zarówno zlecenia dot. e-protokołu, jak i e-uzasadnienia:

a) CRCS→CPT: anulowanie zlecenia (nr zlecenia) – zwrot wartości: potwierdzenie anulowania zleceniaW CPT usunięcie zlecenia z kolejek i kasacja plików źródłowych zlecenia.

9) Informacja przekazywana do sądu o stwierdzonej słabej jakości nagrania – może dotyczyć zarówno zlecenia dot. e-protokołu, jak i e-uzasadnienia:

a) CTP→CRCS: zgłoszenie słabej jakości nagrania (nr zlecenia, informacja o poziomie jakości) – zwrot wartości: informacja potwierdzająca przyjęcie informacjiOdnotowanie niskiej jakości nagrania w RCS.

10) Informacja o stanie zlecenia przekazywana do sądu – system CPT okresowo i na żądanie przesyła dane o kluczowych zmianach statusu zlecenia do sądu (dane wymagane w RCS między innymi do udostępnienia Stronom postępowania na PI dla zleceń dotyczących automatycznej transkrypcji) – może dotyczyć każdego typu zlecenia (poprawa/korekta/transkrypcja itd.), zarówno zlecenia dot. e-protokołu, jak i e-uzasadnienia:

a) CPT→CRCS: bieżący statusu zlecenia (nr zlecenia; status zlecenia; oczekiwany czas realizacji zlecenia) – zwrot wartości: informacja potwierdzająca przyjęcie informacji


70


b) CRCS→CPT: ustalenie bieżącego czasu oczekiwania (nr zlecenia) – zwrot wartości: oczekiwany bieżący czas realizacji zlecenia.

Powyższe powiązania przedstawiono na diagramie:

Rysunek 18. Model wymiany danych w pozostałych wymaganych interakcjach systemów.


71


Wszystkie opisane tu modele interfejsów mogą zostać doprecyzowane przez Zamawiającego w zakresie szczegółowych zasad realizacji na etapie prac projektowych.Szczegółowa specyfikacja interfejsów znajduje się w sekcji I.01.


72


5. Produkty projektu5.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 w sekcji 5.2.1 „Ogólne wymagania w zakresie zarządzania projektem”,

Zgodność z wymaganiami ogólnymi względem dokumentacji opisanymi w sekcji 5.3 „Ogólne wymagania względem dokumentacji”,

Uwzględnienie norm opisanych w sekcji 5.4. „Zgodność z normami”,

Zgodność z ostatecznymi ustaleniami zapisanymi w protokołach za spotkań (o ile w związku z pracami nad dokumentem przeprowadzano spotkania),

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, Szczegółowość pozwalająca na powiązanie zadań z

produktami, Zgodność z wymaganiami opisanymi w sekcji 5.2.1 „Ogólne

wymagania w zakresie zarządzania projektem”,


73

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)Etap Produkt /

Procedura odbioruKryteria odbioru

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),



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”,


Protokoły odbioru dokumentów „Dokumentacji Zarządczej” i „Szczegółowego

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”,

Podpisanie kopii dokumentów przez odpowiednie osoby


74



Harmonogramu Prac”


(weryfikowane w ramach Procedury odbioru Etapu).

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 wersji

ostatecznej, Podpisanie kopii dokumentów przez odpowiednie osoby

(weryfikowane w ramach Procedury odbioru Etapu).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ń).

Etap II. Analiza

Produkty specjalistyczne:Dokument „Analiza Zgodność z wzorem dokumentu „Analiza Biznesowa i


75



biznesowa i systemowa

Biznesowa i Systemowa”


Systemowa” (Załącznik nr S.01. do OPZ), Zgodność przeprowadzanych prac z wymaganiami opisanymi w

sekcji 6.1. „Analiza Biznesowa i Systemowa”, Zgodność z wymaganiami ogólnymi względem dokumentacji

opisanymi w sekcji 5.3 „Ogólne wymagania względem dokumentacji”,

Uwzględnienie norm opisanych w sekcji 5.4. „Zgodność z normami”,

Uwzględnienie wymagań prawnych opisanych w sekcji 5.5 „Zgodność z przepisami prawa”,

Odniesienie do wszystkich wymagań funkcjonalnych i niefunkcjonalnych zapisanych w OPZ,

Zgodność z ostatecznymi ustaleniami zapisanymi w protokołach za spotkań,

Brak tematów otwartych dla dokumentu „Analiza Biznesowa i Systemowa”.

Produkty zarządcze:Agendy spotkań Etapu I





Protokoły ze spotkań Etapu II




76





Protokół Przekazania dokumentu „Analiza Biznesowa i Systemowa”



Opracowanie protokołu dokumentu „Analiza Biznesowa i Systemowa”,


Protokół Odbioru dokumentu „Analiza Biznesowa i Systemowa”



Opracowanie protokołu dla dokumentu „Analiza Biznesowa i Systemowa”,


Raporty okresowe Etapu II





(weryfikowane w ramach Procedury odbioru Etapu).Rejestr ryzyk Etapu II




Uwzględnienie wszystkich przeprowadzonych ocen ryzyka.


77



Rejestr tematów otwartych Etapu II





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 sekcji „Projekt Techniczny”,

Zgodność z wymaganiami ogólnymi względem dokumentacji opisanymi w sekcji „Ogólne wymagania względem dokumentacji”,

Uwzględnienie norm opisanych w sekcji „Zgodność z normami”,

Uwzględnienie wymagań prawnych opisanych w sekcji „Zgodność z przepisami prawa”,

Odniesienie do wszystkich wymagań funkcjonalnych i niefunkcjonalnych zapisanych w OPZ,


Brak tematów otwartych dla dokumentu „Projekt Techniczny”.Produkty zarządcze:

Agendy spotkań Etapu III




Podpisanie kopii dokumentów przez odpowiednie osoby


78



(weryfikowane w ramach Procedury odbioru Etapu).Protokoły ze spotkań Etapu II





Protokoły przekazania dokumentu „Projekt Techniczny”



Opracowanie protokołu dla dokumentów „Projekt Techniczny”, Podpisanie kopii dokumentów przez odpowiednie osoby


Protokół Odbioru dokumentu „Projekt Techniczny”



Opracowanie protokołu dla dokumentu „Projekt Techniczny” bez zastrzeżeń,


Raporty okresowe Etapu III





(weryfikowane w ramach Procedury odbioru Etapu).Rejestr ryzyk Etapu III Zgodność z wzorem dokumentu „Rejestr Ryzyk” (Załącznik nr

P.14. do OPZ),


79





Uwzględnienie wszystkich przeprowadzonych ocen ryzyka.Rejestr tematów otwartych Etapu III





Etap IV. Wytworzenie i modernizacja oprogramowania

Produkty specjalistyczne:Oprogramowanie w wersji testowej

Procedura odbioru dokumentacji1

Zgodność z ustalonym standardem kodów źródłowych zawartych w „Projekcie technicznym”,

Pozytywny wynik „Raportu z testów wewnętrznych oprogramowania” przeprowadzonych przez Wykonawcę,

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 6.8 OPZ, Zgodność z ostatecznymi ustaleniami zapisanymi w

protokołach za spotkań,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.


80



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,


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”,


Agendy spotkań Etapu IV





Protokoły ze spotkań Etapu III





Protokoły przekazania Zgodność z wzorem dokumentu „Protokół przekazania”


81



dokumentu „Scenariusze Testowe”


(Załącznik nr U.02. do Umowy), Opracowanie protokołu dla dokumentu „Scenariusze Testowe”, Podpisanie kopii dokumentów przez odpowiednie osoby


Protokół Odbioru dokumentu „Scenariusze Testowe”



Opracowanie protokołu dla dokumentów „Scenariusze Testowe”,


Raporty okresowe Etapu IV



Opracowanie raportów za cały okres etapu, Ujęcie w raportach wszystkich spotkań, Brak zastrzeżeń do przedstawionych dokumentów w wersji


(weryfikowane w ramach Procedury odbioru Etapu).Rejestr konfiguracji Etapu IV


Zgodność z wzorem dokumentu „Rejestr Konfiguracji” (Załącznik nr P.12. do OPZ),

Uwzględnienie wszystkich wersji dokumentów „Scenariusze Testowe”.

Uwaga: Dla dokumentów NIE MUSZĄ być wskazywane konfiguracje, Analizie podczas odbioru podlegają wymagania będące

produktem etapu.Rejestr ryzyk Etapu IV Zgodność z wzorem dokumentu „Rejestr Ryzyk” (Załącznik nr


82




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 IV





Etap V. Uruchomienie oprogramowania

Produkty specjalistyczne:Oprogramowanie w wersji produkcyjnej

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,

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”,

Uruchomienie oprogramowania w centrali

Procedura odbioru wdrożenia

Przekazanie wszystkich niezbędnych do eksploatacji oprogramowania licencji,

Pozytywny wynik „Raportu z uruchomienia systemu w centrali”,

Zgodność z założeniami w „Planie uruchomienia systemu w centrali”,

Brak tematów otwartych dla produktu „Uruchomienie


83



oprogramowania w centrali”.Przeszkolenie administratorów w centrali

Procedura odbioru szkoleń

Pozytywny wynik „Raport ze szkoleń pracowników w centrali”, Zgodność z zakresem szkoleń w „Plan szkoleń dla pracowników

centrali”, Zgodność z wymaganiami opisanymi w rozdziale 6.10 OPZ, Zgodność z zaleceniami zawartymi w przeglądach jakości

produktu „Przeszkolenie administratorów w centrali”, Pozytywny wynik ostatniego przeglądu jakości dla produktu

„Przeszkolenie administratorów w centrali”.Dokumentacja szkoleniowa administratorów w centrali


Dokument stanowi aktualizacja dotychczasowej dokumentacji szkoleniowej „Dokumentacja Szkoleniowa”,

Zgodność z zakresem szkoleń w „Plan szkoleń dla pracowników centrali”,

Zgodność z wymaganiami opisanymi w rozdziale 6.10 OPZ,

Produkty zarządcze:Plan testów akceptacyjnych oprogramowania



Uwzględnienie przez Wykonawcę wszystkich scenariuszy ze „Scenariuszach testowych” możliwych do przeprowadzenia na obecnym etapie projektu,

Zgodność z wytycznymi zawartymi w rozdziale 6.8, Zgodność z ostatecznymi ustaleniami zapisanymi w

protokołach za spotkań,

Plan migracji danych

Procedura odbioru

Zgodność z wzorem dokumentu „Plan Migracji Danych” (Załącznik nr P.04. do OPZ),

Zgodność z wytycznymi zawartymi w rozdziale 6.9,


84



dokumentacji Zgodność z ostatecznymi ustaleniami zapisanymi w protokołach za spotkań,

Plan uruchomienia systemu w centrali


Zgodność z wzorem dokumentu „Plan Uruchomienia Systemu” (Załącznik nr P.10. do OPZ),



Plan szkoleń dla pracowników centrali


Zgodność z wzorem dokumentu „Plan Szkoleń” (Załącznik nr P.06. do OPZ),



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”,



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 6.9, Zgodność z ostatecznymi ustaleniami zapisanymi w



85



Raport z uruchomienia systemu w centrali


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 w centrali”,



Raport ze szkoleń pracowników w centrali


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ń dla pracowników centrali”,



Agendy spotkań Etapu V





Protokoły ze spotkań Etapu V






86



Protokoły przekazania dokumentów:„Plan testów akceptacyjnych oprogramowania”,„Plan Migracji Danych”,„Plan uruchomienia systemu w centrali”,„Plan szkoleń dla pracowników centrali”,„Raport z testów akceptacyjnych”,„Raport z Migracji Danych”,„Raport z uruchomienia systemu w centrali”,„Raport ze szkoleń pracowników w centrali”,„Szkolenia elearningowe administratorów w sądach”.



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 w centrali”,o „Plan szkoleń dla pracowników centrali”,o „Raport z testów akceptacyjnych”,o „Raport z Migracji Danych”,o „Raport z uruchomienia systemu w centrali”,o „Raport ze szkoleń pracowników w centrali”,o „Szkolenia elearningowe administratorów w sądach”;


Protokoły odbioru dokumentów:„Plan testów akceptacyjnych oprogramowania”,


Uwzględnienie wszystkich wersji oprogramowania, Uwzględnienie wszystkich wersji materiałów szkoleniowych, Uwzględnienie wszystkich zbiorów danych,


87



„Plan Migracji Danych”,„Plan uruchomienia systemu w centrali”,„Plan szkoleń dla pracowników centrali”,„Raport z testów akceptacyjnych”,„Raport z Migracji Danych”,„Raport z uruchomienia systemu w centrali”,„Raport ze szkoleń pracowników w centrali”,„Szkolenia elearningowe administratorów w sądach”.


Opracowanie protokołu dla dokumentów:o „Plan testów akceptacyjnych oprogramowania”,o „Plan Migracji Danych”,o „Plan uruchomienia systemu w centrali”,o „Plan szkoleń dla pracowników centrali”,o „Raport z testów akceptacyjnych”,o „Raport z Migracji Danych”,o „Raport z uruchomienia systemu w centrali”,o „Raport ze szkoleń pracowników w centrali”,o „Szkolenia elearningowe administratorów w sądach”;


Raporty okresowe Etapu V





(weryfikowane w ramach Procedury odbioru Etapu).Rejestr ryzyk Etapu V Zgodność z wzorem dokumentu „Rejestr Ryzyk” (Załącznik nr


88




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 V





Rejestr materiałów projektowych Etapu V


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ń).

Uwaga: Dla dokumentów NIE MUSZĄ być wskazywane konfiguracje, Analizie podczas odbioru podlegają materiały będące

przedmiotem prac etapu.

Rejestr zmian Etapu V


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:


89



Rejestr zmian może pozostać pusty, jednak w takim wypadku w historii dokumentu należy w opisie zmian wnieść odpowiednią adnotację,

Analizie podczas odbioru podlegają zmiany będące przedmiotem prac etapu.

Etap VI. Wdrożenie oprogramowania

Produkty specjalistyczne:Uruchomiona wymiana danych z CPT


Pozytywny wynik „Raportu z testów integracyjnych w zakresie CPT” przeprowadzonych przez Zamawiającego,

Pozytywny wynik „Raportu z uruchomienia wymiany danych z CPT”,

Brak tematów otwartych dla produktu „Uruchomiona wymiana danych z CPT”.

Uruchomiona wymiana danych z PI


Pozytywny wynik „Raportu z testów integracyjnych w zakresie PI” przeprowadzonych przez Zamawiającego,

Pozytywny wynik „Raportu z uruchomienia wymiany danych z PI”,

Brak tematów otwartych dla produktu „Uruchomiona wymiana danych z PI”.

Produkty zarządcze:Plan testów integracyjnych w zakresie CPT



Uwzględnienie przez Wykonawcę wszystkich scenariuszy ze „Scenariuszach testowych” związanych z CPT,



Plan testów Zgodność z wzorem dokumentu „Plan Testów” (Załącznik nr


90



integracyjnych w zakresie PI


P.09. do OPZ), Uwzględnienie przez Wykonawcę wszystkich scenariuszy ze

„Scenariuszach testowych” związanych z PI, Zgodność z wytycznymi zawartymi w rozdziale 6.8, Zgodność z ostatecznymi ustaleniami zapisanymi w


Plan uruchomienia wymiany danych z CPT





Plan uruchomienia wymiany danych z PI





Raport z uruchomienia wymiany danych z PI



Uwzględnienie wszystkich założeń z „Plan uruchomienia wymiany danych z PI”,



Raport z uruchomienia wymiany danych z CPT



91




Uwzględnienie wszystkich założeń z „Plan uruchomienia wymiany danych z CPT”,



Agendy spotkań Etapu VI





Protokoły ze spotkań Etapu VI





Protokoły przekazania dokumentów:„Plan testów integracyjnych w zakresie CPT”,„Plan testów integracyjnych w zakresie PI”,„Plan uruchomienia wymiany danych z CPT”,„Plan uruchomienia


Uwzględnienie wszystkich wersji dokumentów, Podpisanie kopii dokumentów przez odpowiednie osoby



92



wymiany danych z PI”, „Raport z uruchomienia wymiany danych z PI”,„Raport z uruchomienia wymiany danych z CPT”,

Uproszczona procedura odbioru.Protokoły odbioru dokumentów:„Plan testów integracyjnych w zakresie CPT”,„Plan testów integracyjnych w zakresie PI”,„Plan uruchomienia wymiany danych z CPT”,„Plan uruchomienia wymiany danych z PI”,„Raport z uruchomienia wymiany danych z PI”,„Raport z uruchomienia wymiany danych z CPT”,



Uwzględnienie końcowej wersji dokumentów, Uwzględnienie końcowej wersji materiałów szkoleniowych, Podpisanie kopii dokumentów przez odpowiednie osoby


Raporty okresowe Etapu VI



93






(weryfikowane w ramach Procedury odbioru Etapu).Rejestr ryzyk Etapu VI




Uwzględnienie wszystkich przeprowadzonych ocen ryzyka.Rejestr tematów otwartych Etapu VI





Rejestr materiałów projektowych Etapu VI








94



przedmiotem prac etapu.Rejestr zmian Etapu VI




Uwaga: Rejestr zmian może pozostać pusty, jednak w takim wypadku

w historii dokumentu należy w opisie zmian wnieść odpowiednią adnotację,


Etap VII. Zaktualizowanie dokumentacji

Produkty specjalistyczne:Dokumentacja powykonawcza


Dokument stanowi aktualizację dokumentów:o „CENTRALNE ARCHIWUM PROTOKOŁÓW

ELEKTRONICZNYCH Dokumentacja Techniczna” wraz załącznikami oraz

o „CENTRALNE ARCHIWUM PROTOKOŁÓW ELEKTRONICZNYCH – Dokumentacja bezpieczeństwa” wraz załącznikami,

Uwzględnienie wszystkich zagadnień opisanych w „Analizie biznesowej i systemowej”,

Uwzględnienie wszystkich zagadnień opisanych w „Projekcie technicznym”,

Zgodność z wymaganiami opisanymi w rozdziale 6.12 OPZ,

Produkty zarządcze:Agendy spotkań Etapu VII



95






Protokoły ze spotkań Etapu VII





Protokoły przekazania dokumentów:„Dokumentacja Powykonawcza”,„Podręcznik Użytkownika”,Uproszczona procedura odbioru


Uwzględnienie wszystkich wersji dokumentów, Uwzględnienie wszystkich wersji materiałów szkoleniowych, Podpisanie kopii dokumentów przez odpowiednie osoby


Protokoły odbioru dokumentów:„Dokumentacja Powykonawcza”,„Podręcznik Użytkownika”,Uproszczona procedura odbioru


Uwzględnienie końcowej wersji dokumentów, Uwzględnienie końcowej wersji materiałów szkoleniowych, Podpisanie kopii dokumentów przez odpowiednie osoby


Raporty okresowe Etapu VII


Opracowanie raportów za cały okres etapu,


96




Ujęcie w raportach wszystkich spotkań, Brak zastrzeżeń do przedstawionych dokumentów wersji


(weryfikowane w ramach Procedury odbioru Etapu).Rejestr ryzyk Etapu VII




Uwzględnienie wszystkich przeprowadzonych ocen ryzyka.Rejestr tematów otwartych Etapu VII





Rejestr materiałów projektowych Etapu VII







przedmiotem prac etapu.


97



Rejestr zmian Etapu VII




Uwaga: Rejestr zmian może pozostać pusty, jednak w takim wypadku

w historii dokumentu należy w opisie zmian wnieść odpowiednią adnotację,


Etap VIII. Serwis gwarancyjny i wsparcie

Serwis Systemu w miesiącu …

Uproszczona procedura odbioru z wykorzystaniem systemu zgłoszeniowego

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ń,

Uwaga: Możliwy jest podział produktu na podprodukty i dokonanie

odbioru dla wybranych poprawek.Modernizacje Systemu w miesiącu …

Uproszczona procedura odbioru z wykorzystaniem systemu zgłoszeniowego

Zgodność modernizacji z kryteriami jakościowymi zlecenia, Spełnienie wymagań opisanych w Rozdziale 8 OPZ.

Uwaga: Możliwy jest podział produktu na podprodukty i dokonanie

odbioru dla wybranych modernizacji.Aktualizacje dokumentacji w miesiącu …

Wykonanie odpowiednich modyfikacji dokumentów „Dokumentacja powykonawcza”, „Podręcznik użytkownika”, w związku z modernizacjami i poprawkami oprogramowania oraz


98




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.

Protokół odbioru modyfikacji w miesiącu …


Zgodność ze wzorcem Załącznika nr U.07 do Umowy „Protokół Modyfikacji Systemu”,

Uwzględnienie wszystkich zatwierdzonych modyfikacji, Zgodność z zapisami systemu zgłoszeniowego.


99


5.2 Zarządzanie projektem5.2.1 Ogólne wymagania w zakresie zarządzania

projektemZamawiają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).


100

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)Patrz również wymagania zdefiniowane w Rozdziale 6.12 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 umożliwi zastosowanie przez Wykonawcę oprogramowania JIRA, wdrożonego w organizacji Zamawiającego, w celu zarządzania harmonogramem prac oraz zagadnieniami projektowymi w sposób, który pozwoli na ich aktualizację oraz przedstawianie stanu ich realizacji w przejrzystej formie.

„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 Umowy:

Wzory umowne (U.xx):


101


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.

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 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,

5.2.2 Struktura projektowaOrganizacja prac Wykonawcy zostanie dostosowana do struktury Projektu w Etapie I Umowy.

Wszystkie osoby powołane do pełnienia określonych funkcji wskazane będą przez każdą ze na Etapie inicjacji projektu. O wszelkich zmianach w zakresie wskazanych osób należy informować drugą Stronę w formie pisemnej na 3 dni robocze przed dokonaniem zmiany.

Każda ze wskazanych osób będzie posiadać kompetencje i uprawnienia do realizacji zadań jej powierzonych zgodnie z treścią Umowy.


102

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)Strony powołają swoich przedstawicieli, którzy pełnić będą funkcje zgodnie z opisaną w następnych podrozdziałach strukturą.

5.2.3 Komitet sterującyKomitet Sterujący to organ, który jest upoważniony do nadzoru nad realizacją zadań wykonywanych w ramach Umowy oraz do podejmowania bieżących decyzji w czasie trwania prac projektowych.

Główne zadania Komitetu Sterującego:

1) rozstrzyganie spraw dotyczących zmian w harmonogramie oraz istotnych zmian, które zostały wskazane w Umowie);

2) rozwiązywanie problemów, których nie udało się rozstrzygnąć na niższym poziomie decyzyjnym (m.in. problemy dotyczące odbioru/akceptacji);

3) ustosunkowanie się do innych spraw, które okażą się istotne w procesie zarządzania projektem.

Rysunek 19. Skład Komitetu Sterującego

W posiedzeniach Komitetu Sterującego mogą brać udział również Kierownicy Projektu Stron, jednak nie mają oni prawa do podejmowania decyzji. W charakterze doradczym mogą wystąpić też inne osoby zaproszone przez jedną ze Stron za zgodą drugiej Strony.


KOMITET STERUJĄCY

minimum dwaj przedstawiciele Zamawiającego

(jeden z nich pełni funkcję Przewodniczącego Komitetu Sterującego)

minimum dwaj przedstawiciele Wykonawcy (Główni Dostawcy)

103

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)Posiedzeniom przewodniczy Przewodniczący Komitetu Sterującego lub inna upoważniona przez Przewodniczącego osoba ze składu Komitetu Sterującego.

Z własnej inicjatywy lub na wniosek każdego z członków Komitetu Sterującego, przewodniczący zwołuje posiedzenie Komitetu Sterującego (o ile nie zostało ono wcześniej zaplanowane). W nagłych przypadkach posiedzenie Komitetu Sterującego zwołuje się w terminie nie później niż następnego dnia roboczego od otrzymania odpowiedniego wniosku.

Wszelkie ustalenia, decyzje członków Komitetu Sterującego są podejmowane jednomyślnie i muszą być zdefiniowane na piśmie w terminie 5 dni roboczych od przedstawienia danego problemu do rozstrzygnięcia. Decyzje te są ważne z chwilą podpisania przez członków Komitetu Sterującego (obecnych na posiedzeniu) protokołu z posiedzenia Komitetu Sterującego.

W przypadku nieobecności któregoś z członków Komitetu Sterującego nie zostaje wyznaczana inna osoba – posiedzenie odbywa się w niepełnym składzie, pod warunkiem obecności co najmniej jednego z członków Zamawiającego i Wykonawcy. Komitet Sterujący podejmuje decyzję w ten sam sposób.

Posiedzenie Komitetu Sterującego musi odbywać się nie rzadziej niż raz na miesiąc.

5.2.4 Zarząd ProjektuKierownicy Projektu (po stronie Zamawiającego i Wykonawcy) odpowiadają za bieżący nadzór realizacyjny i koordynację zadań wykonywanych w ramach Umowy.

Kierownicy Projektu mogą powoływać Zastępców Kierowników Projektu (przynajmniej trzech po każdej ze Stron), którzy będą odpowiadać za dany obszar i zastępować Kierownika Projektu w trakcie jego nieobecności.

Kierownik Projektu może zastąpić swoich Zastępców w dowolnym czasie.

Kierownik projektu ze strony Zamawiającego zarządza działaniami w projekcie, w tym zasobami po stronie Zamawiającego lub Użytkownika końcowego, dba o udostępnienie wymaganych informacji oraz bezpośrednio współpracuje z Kierownikiem projektu ze strony Wykonawcy, którego jednym z głównych zadań jest bezzwłoczne współdziałanie z Kierownikiem projektu ze strony Zamawiającego i bieżące dostosowanie


104

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)działań projektowych Wykonawcy realizowanych w ramach niniejszej Umowy do wymagań Zamawiającego przekazywanych przez Kierownika Projektu Zamawiającego.

Kierownik Projektu Wykonawcy zobowiązany jest do przygotowania Raportu o stanie projektu (opracowywany wg. wzoru Raportu Okresowego opisanego w Załączniku nr. U04. do Umowy), który przedstawi na spotkaniu Kierowników Projektu.

ZADANIA KIEROWNIKÓW PROJEKTUKierownik Projektu po stronie Zamawiającego

Kontakt z Wykonawcą w sprawach dotyczących realizacji UmowySprawowanie kontroli nad terminowością i zakresem realizowanych prac po stronie

ZamawiającegoOrganizacja i uczestnictwo w cotygodniowych spotkaniach projektowych

Podpisywanie Raport o stanie projektuPrzedstawienie na Komitecie Sterującym raportu z postępu prac w formie pisemnej

Zgłaszanie problemów/wątpliwości, których nie jest w stanie rozstrzygnąć na własnym poziomie decyzyjnym

Rozpoznanie problemów, opóźnień i zagrożeń w realizacji Umowy i podejmowanie działań w celu ich wykluczenia

Ustalenia z Wykonawcą niezbędne do prawidłowej realizacji UmowyInne czynności, które wynikają wprost z Umowy, a zostaną określone przez

Zamawiającego w czasie trwania UmowyKierownik Projektu po stronie Wykonawcy

Informowanie o aktualnych działaniach i stanie prac związanych z realizacją UmowyNadzór prac i kontrola nad wywiązywaniem się Wykonawcy ze wszystkich zobowiązań

wynikających z UmowyOpracowywanie Raportów o stanie projektu dla Zamawiającego, które są podstawą

analizy podczas cotygodniowych spotkań Kontrola stanu zaawansowania prac w ramach realizacji Umowy

Wewnętrzna kontrola jakości wyników pracUczestnictwo w cotygodniowych spotkaniach dotyczących zaawansowania prac

projektowych, zidentyfikowanych problemówPodpisywanie Raportów o stanie projektu

Przedstawienie na Komitecie Sterującym raportu z postępu prac w formie pisemnejZgłaszanie problemów/wątpliwości, których nie jest w stanie rozstrzygnąć na własnym

poziomie decyzyjnymRozpoznanie problemów, opóźnień i zagrożeń w realizacji Umowy i podejmowanie

działań w celu ich wykluczeniaUstalenia z Zamawiającym niezbędne do prawidłowej realizacji Umowy


105


Informowanie Zamawiającego o nieprawidłowościach (w tym niezgodnościach ze stanem prawnym), które mogą mieć wpływ na wykonanie Umowy, a co za tym idzie na

osiągnięcie celu ProjektuInne czynności, które wynikają wprost z Umowy, a zostaną określone przez

Zamawiającego w czasie trwania Umowy

Rysunek 20. Zadania Zarządu Projektu.

5.2.5 Procedury odbiorcze5.2.5.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: Każda pojedyncza agenda, Protokół ze Spotkania, Raport z Przeglądu

Jakości danego dokumentu, protokół przekazania, protokół odbioru, raport okresowy,

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


106


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 otrzymania poprawionej 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.

5.2.5.2 Procedura przekazania produktówW przypadku produktów innych niż przewidzianych do odbioru procedurą uproszczoną stosuje się Procedurę przekazania produktu oraz odpowiednią procedurę odbiorczą.

1. Wykonawca przekazuje Produkt wraz z oświadczeniem, że Produkt przeszedł wewnętrzny test jakości, w terminie wskazanym w


107


„Szczegółowym Harmonogramem Prac”. W przypadku Oprogramowania obowiązują dodatkowe regulacje opisane w ust. 4.

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 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.

4. Zamawiający ponawia procedurę odbioru opisaną w punktach 1-3 powyżej dla ponownego zgłoszenia produktu.

5. 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.

6. Dzień podpisania Protokołu Przekazania przez Zamawiającego uznaje się za dzień przekazania Produktu.

7. 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.

5.2.5.3 Procedura odbioru dokumentacjiProcedura 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, Dokumentacja Szkoleniowa, Dokument Zarządczy – Załącznik nr P.03. do OPZ,

Uwaga:

Zgodnie z tą procedurę odbierane są również np. produkty:


108

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ) 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 5.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;2) zgłosi Wykonawcy usterki Dokumentacji, w tym szczególności

wynikające z przyjętych kryteriów odbioru dla danego produktu.

2. Wykonawca, uwzględnia zgłoszone uwagi poprzez

1) przedstawienie do odbioru poprawionej wersji Produktu oraz2) pisemne stanowisko 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


109


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.


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.

5.2.5.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 stosuje się procedurę odbiorczą w zakresie dokumentacji opisaną w sekcji 5.2.6.2.

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 procedury opisanej w sekcji 5.2.6.1.

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 5.2.6.2);


110


2) zgłosi Wykonawcy usterki Szkoleń, w tym 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 5.2.6.2 – o ile procedura ta wykazała usterki)

4. Dopuszcza się dwukrotną iterację Szkoleń oraz ich oceny według punktów 1-2 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.


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.

5.2.5.5 Procedura odbioru oprogramowaniaPrerekwizytem odbioru są produkty:

Scenariusze testowe Plan testów akceptacyjnych oprogramowania Oprogramowanie testowe oraz Pozytywny wynik testów przeprowadzonych przez Wykonawcę w

odniesieniu do wszystkich scenariuszy testowych, podlegających odbiorowi.


111


1. Po przekazaniu do odbioru produktu Oprogramowanie testowe zgodnie z procedurą odbioru zgodnie z procedurą opisaną w punkcie 5.2.6.2 Zamawiający przeprowadza Testy Akceptacyjne Zamawiającego (TAZ)2.

2. Podstawą TAZ są:

1) Plan Testów i

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 zwalnia go z obligatoryjnego wykonania testów na podstawie odebranych scenariuszy testowych.

4. 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”.

5. 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.

6. 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

2 Choć zasadniczo oprogramowanie przekazane do testów powinno być tożsame z oprogramowaniem testowym, wymagane jest w tym wypadku zainstalowanie go na infrastrukturze Zamawiającego – środowisko testowe.


112


Projektu Zamawiającego lub osoba przez niego wskazana określa jej rodzaj.

7. Dla potrzeb procedury odbioru oprogramowania przyjmuje się następującą klasyfikację Wad (zgodnie z zapisami Umowy):

1) Awarię,

2) Błąd Krytyczny i

3) Błąd Niekrytyczny.

8. Za pozytywny wynik testów uznaje się sytuacje, gdy nie stwierdzono Wad

9. 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 uprzednio w Protokole testów wewnętrznych.

Dopuszcza się występowanie Błędów Niekrytycznych, które wykazuje się w protokole.

10. 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).

11. 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.

12. 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.


113


13. 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.

14. Procedura odbioru będzie powtarzana w kolejnych – co najwyżej trzech - iteracjach odbioru zgodnie z ust. 1-11 do czasu odebrania oprogramowania.

15. 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 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.

16. 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).

17. 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.

18. 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 nie spowodowało to opóźnienia realizacji całości Projektu.


114


Pozytywny wynik testów TAZ jest podstawą przeprowadzenia niefunkcjonalnych testów wydajnościowych TAW spełniających następujące wymagania:

1. obciążenie i gromadzenie wyników testów funkcjonalnych będzie odbywało się automatycznie, zaprojektowanymi scenariuszami testowymi;

2. szczegółowe wyniki z pomiarów dla funkcji zdefiniowanych w ramach testów niefunkcjonalnych powinny być udostępnione Zamawiającemu w pliku csv, wraz z raportem zbiorczym obejmującym średni, maksymalny czas, odchylenie standardowe dla badanej funkcji użytkownika,

3. obciążenie systemu generowane będzie dla wielu Użytkowników wraz z pomiarem czasu funkcji dla każdego użytkownika.

Wykonawca sporządzi raport testów niefunkcjonalnych TAW i przekaże Zamawiającemu. Zamawiający zastrzega sobie prawo do udziału w testach niefunkcjonalnych TAW.

5.2.5.6 Procedura odbioru wdrożenia1. Oprogramowanie odebrane procedurą odbioru Oprogramowania

podlega wdrożeniu:

1) na Środowisku produkcyjnym w centrali,

2) na środowiskach produkcyjnych w sądach – każde wdrożenie w danym sądzie stanowi odrębny produkt.

2. Wdrożenie odbywa się na podstawie Planów Uruchomienia Systemu (Załącznik nr P.11 Wdrożenia, zgodnie z Załącznikiem nr 2 do Umowy.

3. Zamawiający dokona w terminie:

1) 5 Dni Roboczych weryfikacji Wdrożenia w centrali

2) 7 Dni Roboczych weryfikacji Wdrożenia w danym Sądzie

poprzez przeprowadzenie wyrywkowego testu dowolnej funkcjonalności Systemu, zgodnej z odbieranym oprogramowaniem. Dla wyników testów stosuje się definicje Awarii, Błędu Krytycznego i Błędu Niekrytycznego.


115


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. do Umowy). – 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.

8. 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.


10. Okres od terminu w którym Wdrożenie powinna być odebrana zgodnie ze „Szczegółowym Harmonogramem Prac” do daty faktycznego odbioru uznaje się za termin opóźnienia procedury odbioru danego produktu.

11. Odbiór Wdrożenia zostaje potwierdzony podpisaniem przez Strony Protokołu Odbioru wg. wzoru U.01 do Umowy.


116


5.2.5.7 Procedura odbioru etapu1. 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.

5.2.6 Procedury kontroli jakości pracPodczas trwania Projektu wykonywane będą dwa rodzaje przeglądów jakości:

Rysunek 21. 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 przez Zamawiającego stosowana będzie następująca procedura:


Przeglądy w ew nętrzne

przeglądy realizow ane przez W ykonawcęokresowa wew nętrzna weryfikacja jakości wytwarzanych produktówweryfikacja wszystkich produktów przedstaw ianych do odbiorupo przeglądzie produkt podlega akceptacji przez K ierow nika Projektu ze strony W ykonawcyprodukty, które przeszły pom yśln ie wew nętrzne przeglądy jakości m ogą zostać przedstaw ione do odbioru przez Zam aw iającego

Przeglądy zew nętrzne

przeglądy realizow ane przez Zam aw iającego weryfikacja jakości dow olnego produktu pro jektupo przedstaw ieniu przez W ykonawcę produktu do odbioru: w eryfikacja produktów zgłoszonych do odbioru oraz przeglądy wykonywane w dow olnym czasie na żadanie Z lecającego

117


1. Zamawiający wezwie Wykonawcę do przekazania aktualnej wersji wybranego przez Zamawiającego produktu.

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 w 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. Wykonawca, uwzględnia zgłoszone Uwagi poprzez:

4.1 przedstawienie kolejnej wersji produktu do przeglądu jakości4.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.


118


9. Za opóźnienie procedury kontroli jakości rozumiana jest suma:

9.1 Opóźnienia w przekazaniu aktualnej wersji produktu, o której mowa w punkcie 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ę.

5.2.7 Ogólne wymagania względem dokumentacji1) 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:

a) Dokumentację projektową,b) Dokumentację systemową (w tym wydzieloną dokumentację

interfejsów programistycznych),c) Dokumentację eksploatacyjną,d) Dokumentację w zakresie instrukcji użytkownika i szkoleniowa,e) Dokumentację bezpieczeństwa,f) 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.

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:

a) 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,

b) zachowanie standardów, a także sposób pisania, rozumianych jako zachowanie jednolitej i spójnej struktury, formy i sposobu


119


prezentacji treści poszczególnych dokumentów oraz fragmentów tego samego dokumentu, jak również całej dokumentacji,

c) 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,

d) 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) Dokumentacja Systemu będzie aktualizowana przez Wykonawcę odpowiednio do zmian lub modyfikacji wprowadzanych według zaleceń Zamawiającego w terminie do 14 dni od wdrożenia zmian w ramach realizacji usługi rozwoju Systemu. Oznacza to, że Zamawiający wymaga, by zmiany wprowadzane w poszczególnych dokumentach były analizowane przez Wykonawcę przez pryzmat ich wpływu na zapisy innych dokumentów, a w razie ich zidentyfikowania - Wykonawca zobowiązany jest do wprowadzenia wymaganych zmian we wszystkich dokumentach powiązanych.

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

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

5.2.8 Zgodność z normami1) 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


120


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,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.

2) 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).

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


121

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)4) 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.

5.2.9 Zgodność z przepisami prawaDostarczony, 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.1) 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,

2) 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.),

3) 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.),

4) 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.),

5) 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),

6) Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 2 listopada 2006 r. w sprawie wymagań technicznych formatów zapisu i


122


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),

7) 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),

8) 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),

9) 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),

10) 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),

11) Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych. (Dz.U. 1997 nr 133 poz. 883 z późn. zm.),

12) 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),

13) 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),

14) 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),

15) Ustawa z dnia 17 listopada 1964 r. - Kodeks postępowania cywilnego. (Dz.U. 1964 nr 43 poz. 296 z późn. zm.),

16) Ustawa z dnia 23 kwietnia 1964 r. – Kodeks postępowania cywilnego (Dz. U. z 2014 r. poz. 121 ze zm.),


123

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)17) 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.),18) Ustawy z dnia 6 czerwca 1997 r. – Kodeks karny (Dz. U. 88, poz. 553,

ze zm.),19) Ustawy z dnia 6 czerwca 1997 r. – Kodeks karny wykonawczy (Dz. U.

90, poz. 557, ze zm.),20) Ustawy z dnia 26 października 1982 r. o postępowaniu w sprawach

nieletnich (Dz. U.z 2014 r. poz.382 ze zm.),21) Ustawy z dnia 5 sierpnia 2010r. o ochronie informacji niejawnych

(Dz. U. z 2010r. Nr 182, poz. 1228, ze zm.),22) Ustawy z dnia 26 czerwca 1974 r. – Kodeks pracy (Dz. U. z 1998 r. Nr

21, poz. 94 ze zm.),23) 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.),

24) 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.),

25) 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 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.),

26) Ustawy z dnia 27 lipca 2001 r. o ochronie baz danych (Dz. U. Nr 128, poz 1402, ze zm.),

27) 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),

28) 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),

29) Ustawa z dnia 5 września 2016 r. o usługach zaufania oraz identyfikacji elektronicznej (Dz.U. 2016 poz. 1579),


124

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)30) Ustawa z dnia 28 listopada 2014 r. o ochronie i pomocy dla

pokrzywdzonego i świadka (Dz.U. 2015 poz. 21).,31) Ustawa z dnia 14 lipca 1983 r. o narodowym zasobie archiwalnym i

archiwach (t.j. Dz. U. z 2011 r. Nr 123, poz. 698 z późn. zm.); 32) Rozporządzenie Ministra Kultury z dnia 16 września 2002 r. w

sprawie postępowania z dokumentacją, zasad jej klasyfikowania i kwalifikowania oraz zasad i trybu przekazywania materiałów archiwalnych do archiwów państwowych (Dz. U. Nr 167, poz. 1375);

33) Rozporządzenie Ministra Kultury i Dziedzictwa Narodowego z dnia 29 lipca 2008 r. w sprawie określenia szczególnych wypadków i trybu wcześniejszego udostępniania materiałów archiwalnych (Dz. U. Nr 156, poz. 960 z późn. zm.);

5.2.10Ogó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:a) schemat nazewnictwa plików kodu źródłowego,b) schemat organizacji plików kodu źródłowego,c) konwencje nazewnicze,d) konwencję formatowania wyrażeń języka,e) konwencje deklarowania klas i interfejsów,f) konwencje dokumentowania kodu.

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 CAPE. Wykonawca ponosi pełną odpowiedzialność za poprawne funkcjonowanie systemu CAPE 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.


125

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)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.

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

5.2.11Ogólne wymagania względem uruchomienia oprogramowania

1. Dostarczane w ramach projektu przez Wykonawcę oprogramowanie spełniać musi w szczególności wymagania opisane w Rozdziałach 6.3-6.7.

2. Wykonawca zobowiązany jest do dostarczenia kompletnego asortymentowo i ilościowo oprogramowania 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.

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 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. W wyniku zrealizowanych przez Wykonawcę prac wdrożeniowych system musi być w pełni skonfigurowany tj. przygotowany do realizacji


126

http://www.cert.pl/


produkcyjnej wszystkich wskazanych w OPZ przez Zamawiającego funkcjonalności.

6. Wszystkie licencje są nieograniczone czasowo i nie są limitowane w zakresie ilości użyć.

7. Licencje obejmują wykorzystanie przez Zamawiającego oraz pomioty działające na zlecenie Zamawiającego bez ograniczeń API do wszystkich dostarczonych systemów w wersjach desktop i serwerowych (wraz ze stosowną dokumentacją).

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

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

10. 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.

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

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

13. Zamawiający wymaga, by dostarczone oprogramowanie było oprogramowaniem w wersji najbardziej aktualnej na dzień składania ofert.

14. Zakres udzielonych licencji musi zapewnić Zamawiającemu użytkowanie produkcyjne oferowanego rozwiązania zgodnie z wymaganiami opisanymi w OPZ.

5.2.12Ogólne wymagania w zakresie bezpieczeństwaWdrożone rozwiązanie musi zapewnić co najmniej:


127


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

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

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,

uwierzytelnianie i autoryzację użytkowników na podstawie informacji przechowywanej w Active Directory,

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

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

rozliczalność działań użytkowników i administratorów,

zapewnienie wiarygodności i bezpieczeństwa logów,

odnotowanie daty wykonania każdej operacji oraz identyfikatora użytkownika wykonującego operację,

uniemożliwienie edycji i usuwania plików zawierających logi zdarzeń systemowych oraz mechanizmy chroniące przed możliwością ich przepełnienia,

synchronizację zegara systemowego ze źródłami czasu za pomocą protokołu NTP lub mechanizmów Active Directory,

korzystanie z protokołu SSL dla zabezpieczenia przesyłanych informacji lub w inny sposób zapewniać szyfrowanie przesyłania danych,

zdefiniowanie reguł określających wymaganą siłę stosowanych haseł dla różnych grup użytkowników w szczególności:

o minimalnej dopuszczalnej długości hasła,


128


o stosowania znaków alfanumerycznych i specjalnych,o maksymalnej długość okresu ważności hasła,o liczby haseł zapamiętywanych w historii haseł (blokowanie

możliwości ich ponownego użycia),o system musi obsługiwać hasła jednorazowe.

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),

monitorowanie operacji uprzywilejowanych, tj. wykorzystanie uprawnień administratora,

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.


129


6. Szczegółowe wymagania względem produktów6.1 Analiza biznesowa i systemowa

Wykonawca zrealizuje analizę biznesową i systemową pełniącą rolę analizy przedwdrożeniowej/biznesowej. 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.

Produktem prac będzie dokument „Analiza biznesowa i systemowa” w postaci raportu zawierającego koncepcję procesów docelowych Zamawiającego w obszarze planowanego wdrożenia wraz z modelem ich wsparcia projektowanym systemem.

6.2 Projekt technicznyProjekt Techniczny zostanie opracowany przez Wykonawcę na postawie zatwierdzonych przez Zamawiającego wyników analizy biznesowej i 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 biznesowej i systemowej.

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,


130

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)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 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, przypadków użycia systemu opisanych stosownymi scenariuszami

podstawowymi i alternatywnymi, 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), modelu importu danych, szczegółowego opis konfiguracji poszczególnych komponentów

systemu

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

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.

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.

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


131

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)Projekt Techniczny podlega akceptacji Zamawiającego – stanowi podstawę dla dalszych prac instalacyjnych, konfiguracyjnych oraz implementacyjnych Wykonawcy.

6.3 Modyfikacja oprogramowania agentów6.3.1 Modyfikacja oprogramowania RCS Agent

Server1. Należy uzupełnić funkcjonalność oprogramowania RCS Agent Server

w zakresie przesyłania paczek do archiwum na podstawie monitorowania zawartości lokalnego archiwum. W zależności od konfiguracji wybranej przez administratora może uznawać za modyfikację (lub nie uznawać za modyfikację) powodującą konieczność przesłania pliku do archiwum: Paczka archiwalna zawiera / nie zawiera wyodrębnionego e-

uzasadnienia, Dokonanie transkrypcji automatycznej e-uzasadnienia, Dokonanie transkrypcji automatycznej e-protokołu, Dokonanie korekty transkrypcji e-uzasadnienia, Dokonanie pełnej transkrypcji e-protokołu.

2. Modyfikacja oprogramowania nie może prowadzić do zmiany dotychczasowych założeń w zakresie przyjętej technologii oraz modelu logicznego oprogramowania z wyjątkiem zmian wynikających z wymogów realizacji zamówienia.

6.3.2 Utworzenie agenta eksportu PI1. Należy utworzyć oprogramowanie agenta eksportu PI

funkcjonującego według następującej specyfikacji.

GetVideo Pobranie pliku wideo według wskazanej ścieżkiPI → CAPE

Ścieżka (tekst) Plik (plik)

GetProtocol

Pobranie plików e-protokołu wg. wskazanej ścieżkiPI → CAPE

Ścieżka (tekst) Pliki (plik)


132


2. Implementacja agenta eksportu PI musi uwzględniać wymagania opisane w sekcji 6.7.

3. Rozwiązania technologiczne agenta eksportu PI muszą bazować na dotychczasowych założeniach w zakresie przyjętej technologii oraz modelu logicznego oprogramowania z wyjątkiem zmian wynikających z wymogów realizacji zamówienia.

6.3.3 Utworzenie agenta eksportu CPT1. Należy utworzyć oprogramowanie agenta eksportu PI

funkcjonującego według następującej specyfikacji.

GetSentence

Pobranie pliku nagrania e-uzasadnieniaCPT→CAPE

Ścieżka do pliku nagrania e-uzasadniania (tekst)

Plik nagrania e-uzasadnienia (plik)

GetProtocol

Pobranie pliku nagrania e-protokołuCPT→CAPE

Ścieżka do pliku nagrania e-protokołu (tekst)

Plik nagrania e-protokołu (plik)

2. Implementacja agenta eksportu CPT musi uwzględniać wymagania opisane w sekcji 6.3.4.

3. Rozwiązania technologiczne agenta eksportu CPT muszą bazować na dotychczasowych założeniach w zakresie przyjętej technologii oraz modelu logicznego oprogramowania z wyjątkiem zmian wynikających z wymogów realizacji zamówienia.

6.3.4 Modyfikacja portalu CAPE1. Należy uzupełnić wyszukiwarkę paczek archiwalnych również po

atrybutach:• Paczka archiwalna zawiera / nie zawiera wyodrębnionego e-

uzasadnienia,• Dokonano/ nie dokonano transkrypcji automatycznej e-

uzasadnienia,• Dokonano/ nie dokonano transkrypcji automatycznej e-protokołu,• Dokonano/ nie dokonano korekty transkrypcji e-uzasadnienia,• Dokonano/ nie dokonano pełnej transkrypcji e-protokołu.2. Portal musi zapewniać możliwość wykonywania operacji grupowych

na zaznaczonych elementach listy na podstawie atrybutów:


133


• Paczka archiwalna zawiera / nie zawiera wyodrębnionego e-uzasadnienia,

• Dokonano/ nie dokonano transkrypcji automatycznej e-uzasadnienia,

• Dokonano/ nie dokonano transkrypcji automatycznej e-protokołu,• Dokonano/ nie dokonano korekty transkrypcji e-uzasadnienia,• Dokonano/ nie dokonano pełnej transkrypcji e-protokołu.3. Portal zapewni prawidłowe wyświetlanie i funkcjonowanie stron

portalu w przeglądarkach internetowych (które będą zgodne z najnowszymi - na dzień podpisania umowy wersjami przeglądarek internetowych: Internet Explorer, Mozilla Firefox, Opera, Safari, Google Chrome oraz Microsoft Edge) na urządzeniach stacjonarnych. System musi poprawnie realizować założone funkcjonalności co najmniej w następujących wersjach przeglądarek: Internet Explorer 11 i nowszych, Mozilla Firefox 4.0 i nowszych, Opera 10 i nowszych, Safari 5 i nowszych oraz Google Chrome 10 i nowszych.

6.3.5 Modyfikacja Podsystemu Uprawnień i Autoryzacji

Należy uzupełnić funkcjonalność generowania 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 – włącznie z operacjami: Dokonanie transkrypcji automatycznej e-uzasadnienia, Dokonanie transkrypcji automatycznej e-protokołu, Dokonanie korekty transkrypcji e-uzasadnienia, Dokonanie pełnej transkrypcji e-protokołu.

6.3.6 Modyfikacja SZA1. Należy uzupełnić funkcjonalność definiowania polityk dotyczących

przechowywanych zasobów (w tym: okres przechowywania, zasady migracji z medium dyskowego na taśmowe, definiowanie ilości kopii przechowywanych obiektów) o operacje: Paczka archiwalna zawiera / nie zawiera wyodrębnionego e-

uzasadnienia, Dokonano/ nie dokonano transkrypcji automatycznej e-

uzasadnienia, Dokonano/ nie dokonano transkrypcji automatycznej e-protokołu,


134


Dokonano/ nie dokonano korekty transkrypcji e-uzasadnienia, Dokonano/ nie dokonano pełnej transkrypcji e-protokołu.

2. Należy uzupełnić funkcjonalność automatyzacji procesu „odświeżania” i zarządzania przechowywanymi danymi z uwzględnieniem atrybutów: Paczka archiwalna zawiera / nie zawiera wyodrębnionego e-


uzasadnienia, Dokonano/ nie dokonano transkrypcji automatycznej e-protokołu, Dokonano/ nie dokonano korekty transkrypcji e-uzasadnienia, Dokonano/ nie dokonano pełnej transkrypcji e-protokołu.

3. W zakresie zarządzania agentami podsystem musi umożliwiać monitorowanie stanu agentów i łączy pomiędzy lokalizacją archiwum centralnego a lokalizacją agenta włącznie z agentami eksportu PI oraz agentem eksportu CPT.

4. W zakresie zarządzania agentami podsystem musi umożliwiać monitorowanie stanu zasobów lokalnych i centralnych niezbędnych dla funkcjonowania archiwum włącznie z agentami eksportu PI oraz agentem eksportu CPT.

5. W zakresie zarządzania agentami podsystem musi umożliwiać zarządzanie harmonogramami archiwizacji z możliwością ustanowienia indywidualnych harmonogramów dla każdego agenta oraz tworzenia grup agentów w celu wspólnego nimi zarządzania.

6. W zakresie przechowywania danych podsystem musi zapewniać generowanie raportów dotyczących przechowywanych paczek i zdeklarowanych okresów ich przechowywania.

7. Podczas implementacji wykorzystywać należy otwarte standardy wymiany informacji takie jak: WSDL, SOAP, XML, XML Schema. Wymiana danych pomiędzy CAPE a systemami zewnętrznymi będzie się odbywała za pomocą plików w formacie XML.

6.4 Modyfikacja metadanychNależy uzupełnić metadane sprawy o następujące informacje:

Nazwa pliku zawierającego e-uzasadanienie, Początek e-uzasadnienia gg:mm:ss, Koniec e-uzasadnienia gg:mm:ss, Paczka archiwalna zawiera / nie zawiera wyodrębnionego e-

uzasadnienia,


135


Dokonano/ nie dokonano transkrypcji automatycznej e-uzasadnienia,

Dokonano/ nie dokonano transkrypcji automatycznej e-protokołu, Dokonano/ nie dokonano korekty transkrypcji e-uzasadnienia, Dokonano/ nie dokonano pełnej transkrypcji e-protokołu.

6.5 Modyfikacja paczki archiwalnejW ramach dotychczasowej folderu „dokumenty” należy umożliwić dodanie:

Wyniku transkrypcji automatycznej, Wyniku transkrypcji pełnej.

6.6 Modyfikacja raportówIstniejące raporty:RPT.002

Wykaz zamówień Zestawienie zamówień składanych do CAPE w danym okresie

RPT.005

Wykaz spraw wpływających do zarchiwizowania w danym czasie

Zestawienie spraw wpływających do zarchiwizowania w CAPE w danym okresie

RPT.011

Liczba przechowywanych dokumentów / spraw

Łączna liczba przechowywanych dokumentów / spraw na dzień generowania raportu

Należy uzupełnić o analitykę w zakresie atrybutów: Paczka archiwalna zawiera / nie zawiera wyodrębnionego e-


uzasadnienia, Dokonano/ nie dokonano transkrypcji automatycznej e-protokołu, Dokonano/ nie dokonano korekty transkrypcji e-uzasadnienia, Dokonano/ nie dokonano pełnej transkrypcji e-protokołu.

6.7 Wymagania wspólne wobec agenta eksportu PI i agenta eksportu CPT

1. Agent musi mieć możliwość przesyłania informacji o swojej aktywności (w szczególności informowania o problemach z


136


przesłaniem paczki archiwalnej, statusie paczek, błędach przetwarzania, niedostępności wymaganych zasobów dyskowych itp.) lokalnemu administratorowi za pośrednictwem poczty elektronicznej.

2. Agent musi zapisywać informacje dotyczące wszystkich realizowanych czynności oraz wykrytych błędów w systemie logów serwera na którym zostanie zainstalowany.

3. Agent musi zapewnić weryfikację pojemności zasobów lokalnych potrzebnych dla odtworzenia paczek z archiwum centralnego

4. Agent w zakresie odbierania paczek z archiwum musi umożliwić kopiowanie odtworzonych w archiwum centralnym paczek do dedykowanej przestrzeni na macierzy lokalnej.

5. Agent w zakresie odbierania paczek z archiwum musi zapewnić weryfikację poprawności odtworzonych danych

6. Agent musi zapewnić komunikację z systemem centralnym w celu potwierdzenia poprawności odtworzenia paczek archiwalnych.

7. Agent musi zapewnić poufność, integralność i niezaprzeczalność transmisji w zakresie odbierania paczek do/z archiwum.

8. Wymiana danych musi opierać się na mechanizmie SCP Storage zastosowanym w RCS Agent Server.

9. Podczas implementacji wykorzystywać należy otwarte standardy wymiany informacji takie jak: WSDL, SOAP, XML, XML Schema. Wymiana danych pomiędzy CAPE a systemami zewnętrznymi będzie się odbywała za pomocą plików w formacie XML.


137


6.8 Testowanie oprogramowania6.8.1 Scenariusze testowe

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:

Nr scenariusza Nr kroku testowego Opis czynności do wykonania Dane testowe Użytkownik wykonujący (rola w systemie) Oczekiwany rezultat Odnotowanie uzyskanego w teście rezultatu Uwagi

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.

Scenariusze Testowe podlegają akceptacji Zamawiającego.

6.8.2 Plan testówW ramach testów rozwiązania w pierwszej kolejności przygotowany zostanie przez Wykonawcę Plan Testów obejmujący w szczególności: Scenariusze Testowe oraz dane testowe (w tym 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:

cel przeprowadzenia testu, metodę̨ przeprowadzenia testów, zasady organizacyjne, podział zadań, oprogramowanie wspomagające testy, harmonogram testów, macierz pokrycia wymagań i przypadków użycia scenariuszami

testowymi, opis i konfigurację środowiska testowego,


138


wykaz danych testowych niezbędnych do wykonania testów.Testy poza funkcjonalnościami rozwiązania zweryfikują również mechanizmy migracyjne oraz mechanizmy integracji i wymiany danych. Testów musi obejmować wszystkie rodzaje planowanych w projekcie testów.

Plan testów podlega akceptacji Zamawiającego.

Wykonawca jest zobowiązany do przygotowania środowiska testowego zgodnie z zatwierdzonym przez Zamawiającego Planem testów.

6.8.3 Wykonawstwo testówWykonawca 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ący powinna przejść uprzednio pozytywnie testy wewnętrzne 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ć własne scenariusze testowe oraz dokonywać testów rozwiązania ad-hoc (bez użycia scenariuszy).

W projekcie wymagana jest realizacja poniższych rodzajów testów:

testów funkcjonalnych – testy użytkownika (UAT) poszczególnych funkcji systemu w ramach obszaru wdrożenia.

testów pokrycia – realizowanych dla identyfikacji wszystkich przypadków testowych.

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.

testów integracyjnych – test realizacji procesów zaimplementowanych w systemie, a wymagających wymiany danych z systemami współpracującymi z projektowanym rozwiązaniem.

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


139

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ) 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.

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

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 (patrz sekcja 5.2.6).

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.

Po zakończeniu testów w ciągu 5 dni roboczych Wykonawca przygotuje Raport z testów akceptacyjnych. W razie zidentyfikowania w toku testów błędów w działaniu rozwiązania Wykonawca zobligowany jest do wprowadzenia w systemie wymaganych korekt w terminie wyznaczonym przez Zamawiającego, nie krótszym niż 7 dni roboczych, po którego upływie testy zostaną powtórzone (w modelu testów pełnych lub testów regresji stosownie do potrzeb).Zakończenie pozytywne testów (tj. zgodnie z wymaganiami zdefiniowanymi w tym zakresie w Planie Testów) stanowi podstawę do bezwarunkowego lub ewentualnie warunkowego odbioru testów.

6.9 Migracja danychWykonawca na potrzeby migracji przygotuje stosowny Plan migracji – dokument precyzujący organizacyjne i merytoryczne aspekty dot. procesu migracji.Dokument Planu migracji musi zawierać co najmniej:

cel migracji, źródła zbiorów danych, zakres zbiorów danych, metodę migracji dla każdego ze zbiorów, zasady organizacyjne, podział zadań,


140


oprogramowanie wspomagające migrację, harmonogram migracji, macierz pokrycia wymagań dotyczących migracji danych.

Dokument musi zostać zatwierdzony przez Zamawiającego.Na potrzeby migracji danych Wykonawca przygotowuje stosowne narzędzia (w tym: 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 6.8). 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.

6.10 Szkolenia1) 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) Każde szkolenie zakończone będzie egzaminem/testem znajomości systemu przez użytkownika.

5) 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ń.

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

7) Po każdym dniu szkoleniowym Szkolenia zostanie sporządzona przez Wykonawcę lista obecności z podpisem każdego obecnego uczestnika Szkolenia. Wzór listy obecności zostanie opracowany przez Wykonawcę


141


i przekazany do zatwierdzenia przez Zamawiającego w terminie 60 dni od zawarcia Umowy.

8) Wykonawca obowiązany jest do przedłożenia Zamawiającemu imiennych list obecności obejmujących co najmniej imiona i nazwiska osób uczestniczących, datę i miejsce szkolenia, Sąd, do którego należą uczestnicy oraz podpis uczestników.

9) Lista obecności podpisana przez wszystkich obecnych na szkoleniu uczestników szkolenia jest jednym z warunków pozytywnego odbioru szkolenia przez Zamawiającego.

10) Po zakończeniu każdego Szkolenia Wykonawca przygotuje i następnie rozda uczestnikom do wypełnienia imienne ankiety ewaluacyjne. Ankieta powinna zawierać minimum następujące elementy:

a. imię i nazwisko,b. program szkolenia,c. ocenę zastosowanych metod szkoleniowych,d. ocenę wiedzy zdobytej przez uczestnika,e. ocenę przydatności szkolenia,f. ocenę kompetencji Wykładowcy/Trenera,g. ocenę stopnia realizacji programu,h. inne elementy wpływające na jakość szkolenia,i. uwagi dotyczące szkolenia.

Wszystkie oceny w skali szkolnej od 1 do 6, przy czym 1 – ocena niedostateczna, 6 – ocena celująca.

Wzór ankiety zostanie opracowany przez Wykonawcę i przekazany do zatwierdzenia przez Zamawiającego przed rozpoczęciem szkoleń (nie później niż na 14 dni roboczych przed pierwszym Szkoleniem). W terminie 7 dni roboczych od dnia przedstawienia, Zamawiający zgłosi uwagi lub dokona akceptacji. Wykonawca przedstawi także raport ewaluacyjny zawierający pełną analizę ocen przeprowadzonego Szkolenia przez uczestników nie później niż 10 dni roboczych po przeprowadzeniu Szkolenia. Raport ewaluacyjny ze średnią ocen ze wszystkich ankiet równą lub wyższą od 4.0 (liczone następującym sposobem:

A = suma punktów z pytań punktowych dla każdej ankiety;B = suma liczby punktów z wszystkich ankiet;C = liczba ankiet;


142


D = średnia ocen ze wszystkich ankiet liczona zgodnie z równaniem B/C=D)

jest jednym z warunków odbioru pozytywnego każdego Szkolenia. Załącznikiem do raportu ewaluacyjnego są oryginały ankiet ewaluacyjnych wypełnione przez uczestników każdego Szkolenia.

11) Przedmiot zamówienia obejmuje także wyposażenie uczestników Szkolenia w odpowiednie materiały szkoleniowe, które po zakończeniu danego Szkolenia przejdą na ich własność. Na materiały szkoleniowe składają się co najmniej: drukowane materiały edukacyjne obejmujące tematykę szkolenia, długopisy i notesy po jednym dla każdego uczestnika Szkolenia.

12) Wszystkie materiały przygotowane przez Wykonawcę (w tym: listy obecności, protokoły odbiorów, programy, zaświadczenia, prezentacje multimedialne, drukowane materiały szkoleniowe) będą oznaczone co najmniej w sposób odpowiedni dla Programu Operacyjnego Polska Cyfrowa.

13) Wykonawca zapewni także osobę do koordynacji Szkoleń odpowiadającą za ich przygotowanie, która będzie pozostawała w kontakcie telefonicznym i e-mailowym co najmniej na 14 dni roboczych przed każdym ze Szkoleniem, w trakcie trwania i do momentu odbioru usługi Szkolenia. Zamawiający nie zapewnia Trenerowi jak i innym osobom ze strony Wykonawcy noclegu i wyżywienia w miejscu szkolenia.

14) Wykonawca jest zobowiązany do przygotowania, powielenia i dystrybucji pomiędzy uczestników akredytowanych materiałów szkoleniowych wraz z przyborami biurowymi (długopis, notes). Wykonawca będzie również zobowiązany do dystrybucji materiałów promocyjnych dostarczonych przez Zamawiającego wśród uczestników Szkoleń.

15) W przypadku nieuzyskania w raporcie ewaluacyjnym średniej co najmniej 4.0 ze wszystkich ankiet ewaluacyjnych, niedostarczenia lub dostarczeniem nieprawidłowo wypełnionych dokumentów, tj. listy obecności, Protokołu odbioru materiałów szkoleniowych lub Protokołu odbioru zaświadczeń, o ile takie w ramach danego Szkolenia było wymagane, oraz oryginałów ankiet ewaluacyjnych Szkolenie nie zostanie odebrane przez Zamawiającego, a Wykonawca jest zobowiązany do powtórzenia Szkolenia na swój koszt. Wykonawca z tego tytułu nie będzie sobie rościł praw do dodatkowego wynagrodzenia. Termin powtórnego szkolenia zostanie ustalony z


143


Zamawiającym. W razie wątpliwości stanowisko Zamawiającego w zakresie terminu powtórnego szkolenia jest dla Wykonawcy wiążące.

16) Odbiór zaświadczenia (o ile w danym Szkoleniu było wymagane) oraz materiałów szkoleniowych zostanie potwierdzony przez uczestników Szkoleń na protokole odbioru materiałów szkoleniowych i protokole odbioru zaświadczenia. Oba protokoły będą zawierały minimum: imię i nazwisko uczestnika, datę szkolenia, miejsce i tytuł szkolenia oraz własnoręczne podpisy uczestników szkolenia potwierdzające odbiór poszczególnych produktów. Oryginały obu Protokołów odbioru Wykonawca przekaże Zamawiającemu wraz z raportem ewaluacyjnym.

6.10.1Plan szkoleńWykonawca zobowiązany jest do przygotowania Planu Szkoleń. Dokument ten powinien precyzować szczegółowo nie tylko aspekty organizacyjne realizacji szkoleń, harmonogram szkoleń, poddział na grupy, wymagania dotyczące przygotowania sal szkoleniowych, model testów sprawdzających itp., ale również opisywać merytoryczne aspekty szkoleń jak agendy poszczególnych szkoleń, program szkoleń.Rozpoczęcie realizacji szkoleń warunkowane jest akceptacją przez Zamawiającego Planu szkoleń przygotowanego przez Wykonawcę. Wykonawca przygotuje i przeprowadzi szkolenia dla Administratorów centrali – w formie szkoleń stacjonarnych dla 5pracowników.

6.10.2Szkolenia administratorów1) Minimalna ilość godzin szkolenia: 4 h na każdą osobę przy czym 1h

godzina szkolenia to 60 min. Szkolenie rozpocznie się nie wcześniej niż o godz. 900 i zakończy się nie później niż o godz. 1730

2) Maksymalny rozmiar grupy szkoleniowej: 5 osób

3) Szkolenie polegać ma na przeprowadzeniu wykładów oraz warsztatów dla Administratorów, uzupełnionych prezentacjami multimedialnymi, odpowiedziami na pytania uczestników sesji szkoleniowych. Szkolenie ma obejmować w szczególności przeprowadzenie wykładów teoretycznego dla Administratorów uzupełnionych prezentacjami multimedialnymi oraz przeprowadzeniu warsztatów praktycznych. Wykonawca zapewnieni każdemu uczestnikowi wyłączny dostępu do komputera z dostępem do konfiguracji takiej jak u Zamawiającego.


144


4) Środowisko szkolenia będzie identyczne do wersji produkcyjnej.

5) Wykonawca odpowiada za przygotowanie środowiska szkoleniowego i danych wymaganych dla przeprowadzenia szkolenia (stosownych kolejek zleceniowych, zadaniowych itp.)

6) Szkolenie będzie uwzględniać role pełnione przez użytkowników.

7) Wykonawca zobowiązany jest do zapewnienia na potrzeby Szkolenia:

i. jedna sala warsztatową na co najmniej 10 osób, posiadająca działającą klimatyzację lub otwierane okna, wyposażona w łącze internetowe, zamykana na klucz pozostający do dyspozycji organizatora w dniach i godzinach korzystania (znajdująca się w obiekcie hotelowym);

ii. sala musi posiadać ekrany, rzutniki, stojaki pod rzutniki, stolik i krzesło z miękkim siedzeniem dla Wykładowcy;

iii. stoły dla osób szkolonych muszą być ustawione w układzie szkolnym albo teatralnym;

iv. podczas przerw kawowych dodatkowe czyste szkło donoszone na żądanie organizatora;

v. sala restauracyjna w obiekcie hotelowym na potrzeby spożycia śniadania, obiadu i kolacji na co najmniej 10 osób.

vi. wyżywienie, w tym przerwy kawowe (podawane przed salą konferencyjną) o następującym składzie: 1 śniadanie drugiego dnia Szkolenia, w formie bufetu, w sali

restauracyjnej (z miejscami siedzącymi przy stołach), o zawartości: 3 rodzaje pieczywa – biały chleb, bułki i pieczywo ciemne, masło, nabiał, biały ser, serki topione, ser żółty, wędliny, pasztet drobiowy, pasta rybna, zimne przystawki np. śledzie, posiłek gorący: np. jajecznica, kiełbaski, napoje: sok owocowy – 2 rodzaje, kawa, herbata – co najmniej 2 rodzaje, woda mineralna gazowana i niegazowana, cytryna

przerwy kawowe – łącznie 4 – (skład: kawa, herbata, woda mineralna gazowana i niegazowana bez limitu, mleko do kawy, cukier, cytryna, sok owocowy – dwa rodzaje, dwa rodzaje ciastek) donoszone i uzupełniane na żądanie Zamawiającego,

obiad (pierwszego i drugiego dnia Szkolenia), podany w wyodrębnionej sali restauracyjnej (z miejscami siedzącymi przy stołach), (skład: dwie zupy do wyboru, drugie danie składające się z 2 rodzajów mięs do wyboru, dodatków skrobiowych i dodatków warzywnych (w tym bukiet warzyw) oraz wersji jarskiej drugiego dania, deser, sok owocowy, kawa, herbata, woda mineralna gazowana i niegazowana, mleko do kawy, cukier, cytryna),

kolacja w formie bufetu (pierwszego dnia Szkolenia, w sali restauracyjnej (z miejscami siedzącymi przy stołach), o


145


zawartości: dwie zupy do wyboru, 1 rodzaj mięsa oraz ryba na ciepło + dodatki skrobiowe + dodatki warzywne, pieczywo różnorodne, wędlina różnorodna (min. 3 rodzaje), sery różnorodne (min. 2 rodzaje), świeże warzywa (pomidory, ogórek zielony), masło, kawa, herbata, cytryna, cukier, mleko, woda gazowana i niegazowana, sok – 2 rodzaje.

vii. zapewnienie bezpłatnych miejsc parkingowych dla uczestników szkoleń, na terenie hotelu, ośrodka, dla minimalnie 10 samochodów osobowych.

viii. Wykonawca zapewni obsługę techniczną spotkania w postaci przedstawiciela Wykonawcy lub osobę zatrudnioną w hotelu, która będzie sprawowała nadzór nad realizacją zamówienia zgodnego z Umową.

8) Uczestnicy otrzymają po zakończeniu Szkolenia imienne zaświadczenie o ukończeniu szkolenia. Zaświadczenie będzie obejmowało: imię i nazwisko, nazwę szkolenia, datę szkolenia i miejsce szkolenia. Projekt zaświadczenia zostanie opracowany przez Wykonawcę i przekazany do zatwierdzenia przez Zamawiającego przed rozpoczęciem Szkolenia (nie później niż na 14 dni roboczych przed datą Szkolenia). W terminie 7 dni roboczych od dnia przedstawienia, Zamawiający zgłosi uwagi lub dokona akceptacji. W razie wątpliwości dotyczących ustalenia kwestii, o których mowa powyżej, za wiążące uznaje się stanowisko Zamawiającego.

6.11 Uruchomienie systemuWykonawca 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.


146

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)Dokument Planu uruchomienia systemu musi zawierać co najmniej:

cel uruchomienia, założenia organizacyjne uruchomienia, listę zadań kluczowych do wykonania przed uruchomieniem, listę zadań kluczowych do wykonania po uruchomieniu, zasady organizacyjne uruchomienia i podział zadań, procedurę awaryjną na wypadek trudności w uruchomieniu

produkcyjnym, harmonogram prac uruchomieniowych.

Plan uruchomienie systemu podlega akceptacji Zamawiającego.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, aktywacji kont oraz pomocy użytkownikom podczas pierwszego tygodnia pracy w nowym systemie.

6.12 Dokumentacja6.12.1Dokumentacja projektowa

1) Dokumentacja projektowaa) 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ć:

i. diagram kontekstowy przedsięwzięcia realizowanego w ramach przedmiotu zamówienia,

ii. procesy kierujące przedsięwzięciem,iii. strukturę i zawartość planu projektu,iv. techniki zarządzania projektem,v. 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,


147


b) 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,

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

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

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

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

2) 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.

6.12.2Dokumentacja systemowa1) Dokumentacja systemowa musi zawierać co najmniej następujące

informacje:a. Wprowadzenie opisujące cele i zakres,b. Diagram kontekstowy zaproponowanego rozwiązania i model

zachowania,c. Ograniczenia rozwiązania,d. Założenia i zależności,e. Ogólna charakterystyka użytkowników,f. Opis wymagań funkcjonalnych i niefunkcjonalnych,g. Specyfikację wymagań funkcjonalnych,h. Specyfikację wymagań niefunkcjonalnych,i. Opis wymagań sprzętowych i programowych,j. Specyfikację wymagań sprzętowych,k. Specyfikację wymagań programowych,l. Opis i specyfikację interfejsów,

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

m. Program przebiegu testów i sposób oszacowania niezawodności zastosowanego rozwiązania, w tym propozycję raportów z testów,Projekt współfinansowany przez Unię Europejską ze środków

Europejskiego Funduszu Rozwoju Regionalnego148


n. Opis i specyfikację migracji danych,o. Wytworzone kody źródłowe.

6.12.3Dokumentacja utrzymaniowa1) Dokumentacja utrzymaniowa, musi zawierać co najmniej:

a) procedury administracyjne,b) procedury zabezpieczeń (backup’owe),c) procedury awaryjne,d) procedury użytkownika.

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

a) identyfikator i nazwę procedury,b) rodzaj procedury,c) data utworzenia i zatwierdzenia oraz wersja procedury,d) cel i zakres procedury,e) warunki uruchomienia procedury i oczekiwany rezultat jej

wykonania,f) dane osób, które opracowały procedurę, sprawdziły,

zaakceptowały i zatwierdziły,g) 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.

6.12.4Podręczniki użytkownika oraz dokumentacja szkoleniowa

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,


149


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

6.12.5Dokumentacja bezpieczeństwaDokumentacja 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:1.1. opis metodyki szacowania ryzyka,1.2. identyfikację zagrożeń dla poufności integralności oraz

dostępności informacji przetwarzanych w systemach objętych zamówieniem,

1.3. raport z procesu szacowania ryzyka,1.4. listę wdrożonych zabezpieczeń,1.5. informacje o ryzyka szczątkowych;

2. plany ciągłości działania;3. opis bezpieczeństwa fizycznego:

3.1. środki ochrony fizycznej,3.2. zasilanie awaryjne,3.3. zapewnienie warunków środowiskowych,3.4. alternatywne łącza;

4. informacje o zastosowanych urządzeniach i narzędziach kryptograficznych;

5. ochrona nośników:5.1. oznaczanie,5.2. dostęp,5.3. transport,5.4. niszczenie nośników;

6. procedury odnoszących się do następujących zagadnień:6.1. administrowanie systemem IT,6.2. administrowanie środkami ochrony,6.3. bezpieczeństwo urządzeń,6.4. bezpieczeństwo oprogramowania,6.5. zarządzanie konfiguracją programową,


150


6.6. zasady serwisowania,6.7. zasady modernizowania,6.8. zasady wycofania elementów systemu,6.9. plany awaryjne,6.10. monitorowanie systemu IT,6.11. audyt systemu IT,6.12. zarządzanie nośnikami,6.13. zarządzanie materiałami kryptograficznymi,6.14. incydenty bezpieczeństwa,6.15. szkolenia użytkowników.

6.12.6Dokumentacja powykonawczaDokumentację powykonawczą systemu stanowić będzie zaktualizowana dokumentacja techniczna CAPE uzupełniona o opis wykonanych w toku prac wraz z informacjami o parametrach i sposobie konfiguracji, instrukcje techniczno-instalacyjne, instrukcje obsługi oprogramowania oraz inne dokumenty producentów, o ile zostaną one dostarczone przez Wykonawcę, a także materiały szkoleniowe w zakresie dotyczącym systemu.

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

Projektu Technicznego, diagramów ze strukturami danych, dokumentacji interfejsów systemu, kodów źródłowych i dokumentacji tych kodów.

7. Rozwiązanie równoważneZamawiający dopuszcza wdrożenie Rozwiązania Równoważnego w odniesieniu do systemu CAPE, opisanego w rozdziale 3.7.

Rozwiązanie równoważne powinno spełniać wymagania: zgodnie z OPZ oraz opisane w Załączniku nr 1 do OPZ ”Dokumentacja Techniczna

Centralne Archiwum Protokołów Elektronicznych”, z wyłączeniem dostawy platformy sprzętowej.

7.1 Wymagania dotyczące wdrożenia rozwiązania równoważnego

Wdrożenie Rozwiązania Równoważnego systemu Centrum Archiwizacji Protokołów Elektronicznych (CAPE) zrealizowane zostanie z


151

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)wykorzystaniem platformy sprzętowej będącej w posiadaniu Zamawiającego i opisanej szczegółowo w Załączniku nr 1 do OPZ ”Dokumentacja Techniczna Centralne Archiwum Protokołów Elektronicznych”.

Do czasu produkcyjnego wdrożenia Rozwiązania Równoważnego obowiązek zapewnienia infrastruktury sprzętowej i programowej spoczywa na Wykonawcy. Migracja Rozwiązania Równoważnego ze środowiska sprzętowego Wykonawcy na platformę sprzętową Zamawiającego, powinna uwzględniać migrację danych - przetwarzanych produkcyjnie przez Zamawiającego w systemie CAPE. Testy Rozwiązania Równoważnego Cape powinny obejmować zakres i wymagania zgodne z Rozdziałem 6.8 OPZ oraz obejmować dodatkowo wdrożenie pilotażowe oraz wdrożenie produkcyjne Rozwiązania Równoważnego CAPE.

Wdrożenie pilotażowe Rozwiązania Równoważnego CAPE obejmuje swoim zakresem:

1. Przygotowanie dokumentacji instalacyjnej wraz z oprogramowaniem dla sądów objętych pilotażem.

2. Przygotowanie planu migracji Rozwiązania Równoważnego z platformy sprzętowej Wykonawcy na platformę sprzętową Zamawiającego,

3. Konfiguracja infrastruktury na potrzeby migracji Rozwiązania Równoważnego z platformy sprzętowej Wykonawcy na platformę sprzętową Zamawiającego, z zachowaniem ciągłości działania systemu CAPE, produkcyjnie wykorzystywanego przez Zamawiającego,

4. Przeprowadzenie migracji 5. Przeprowadzenie procesu instalacji agentów.6. Weryfikacja poprawności komunikacji Agentów z systemem centralnym.7. Zasilenie CAPE danymi z poszczególnych lokalizacji.8. Uruchomienie harmonogramów archiwizacji w poszczególnych

lokalizacjach.9. Przeprowadzenie testów obejmujących wszystkie zdefiniowanie

funkcjonalności systemu.10. Zebranie doświadczeń – w formie dokumentu – dotyczących

możliwych problemów, znanych błędów i sposobów ich omijania, rekomendacji dotyczących procesu wdrażania.

11. W oparciu o doświadczenia z tego etapu należy przygotować plan produkcyjnego wdrożenia systemu.


152

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)Na zakończenie procesu testów wdrożenia pilotażowego Rozwiązania Równoważnego CAPE gotowe są:1. Rozwiązanie Równoważne zmigrowane na platformę sprzętową

Zamawiającego, 2. Przetestowane procedury instalacyjne agentów systemu3. Przetestowane procedury zasilania CAPE danymi.4. Zweryfikowana dokumentacja dla użytkowników i administratorów

systemu.5. Zebrane doświadczenia zawierające: możliwe problemy, znane błędy,

scenariusze diagnostyczne. 6. Zweryfikowana procedura testów – odbiorów dla poszczególnych

lokalizacji.7. Protokół z realizacji testów,8. Przygotowany harmonogram wdrożenia systemu w na terenie

wszystkich apelacji

Wdrożenie produkcyjne Rozwiązania Równoważnego CAPE obejmuje:

1. Instalacje agentów w poszczególnych lokalizacjach.2. Zasilenie CAPE danymi z poszczególnych lokalizacji.3. Założenie kont użytkowników.4. Przeprowadzenie testów akceptacyjnych w poszczególnych

lokalizacjach.

Na zakończenie procesu testów wdrożenia produkcyjnego Rozwiązania Równoważnego CAPE gotowe są:1. System zainstalowany i skonfigurowany we wszystkich lokalizacjach

Zamawiającego to jest we wszystkich Sądach Powszechnych. 2. Skonfigurowane i działające harmonogramy archiwizacji.3. Założone i zweryfikowane konta użytkowników systemu.4. Dokumentacja techniczna zaktualizowana.5. Protokół z realizacji testów wdrożenia produkcyjnego

Datą zakończenia realizacji etapu 4 „Wdrożenie produkcyjne CAPE” jest 31. XII.2018 r.

8. Harmonogram realizacji przedmiotu zamówienia


153


Nr etapu Nazwa etapu Termin realizacji

Etap I Inicjacja projektu Inicjacja projektu Do 3 tygodni od zawarcia Umowy

Etap II Analiza biznesowa i systemowa

Analiza biznesowa i systemowa

Do 5 tygodni od zawarcia Umowy

Etap III Projektowanie systemu Projektowanie systemu Do 8 tygodni od zawarcia

UmowyEtap IV Wytworzenie i modernizacja oprogramowania

Wytworzenie i modernizacja

oprogramowaniaDo 12 tygodni od zawarcia

UmowyEtap V Uruchomienie oprogramowania

Uruchomienie oprogramowania


Etap VI Wdrożenie oprogramowania

Wdrożenie oprogr3amowania


Etap VII Zaktualizowanie dokumentacji

Zaktualizowanie dokumentacji


Etap VIII Przeniesienie praw autorskich do systemu CAPE

Przeniesienie praw autorskich do systemu

CAPE

Data do uzupełnienia zgodnie z wnioskami z dialogu technicznego

Etap IX serwis gwarancyjny i wsparcie

Serwis gwarancyjny i wsparcie

Do 48 miesięcy od daty podpisania Protokołu Odbioru Końcowego

(ilość miesięcy będzie określona na podstawie

oferty)

9. Prawa autorskieW ramach realizacji przedmiotu przedsięwzięcia Wykonawca systemu zapewni przekazanie praw autorskich do systemu CAPE.

7.3.1. Prawa autorskie w przypadku dostawy licencji iBARD

W przypadku, gdy Wykonawca będzie świadczyć usługę Modyfikacji oraz utrzymania Centralnego Archiwum Protokołów Elektronicznych na potrzeby projektu »Wdrożenie protokołu elektronicznego w sądach powszechnych” w oparciu o licencje iBARD, wyspecyfikowane i opisane w Załączniku nr 1 do OPZ „Dokumentacja Techniczna Centralne Archiwum


154

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)Protokołów Elektronicznych”, zobowiązany jest on do dostarczenia Zamawiającemu autorskich praw majątkowych do tego oprogramowania.

Dostawa nastąpi nie później niż …………………z datą określoną w harmonogramie

7.3. Prawa autorskie w przypadku dostawy rozwiązania równoważnego

W przypadku, gdy Wykonawca będzie świadczyć usługę „Modyfikacji oraz utrzymania Centralnego Archiwum Protokołów Elektronicznych na potrzeby projektu »Wdrożenie protokołu elektronicznego w sądach powszechnych” w oparciu o Rozwiązanie Równoważne, o którym mowa w pkt 7 OPZ, zobowiązany jest on do dostarczenia Zamawiającemu autorskich praw majątkowych do tego oprogramowania.

Dostawa nastąpi nie później niż …………………z datą określoną w harmonogramie

10. Serwis gwarancyjny, utrzymanie i rozwój10.1.1Usługa gwarancyjna

Zakres usługi gwarancyjnej oraz udzielanego wsparcia technicznego obejmuje wszystkie wykryte podczas eksploatacji Systemu błędy tj. uszkodzenia, wady i nieprawidłowości w funkcjonowaniu Systemu, objętego przedmiotem zamówienia, rozumianego jako:

System CAPE i jego komponenty funkcjonalne lub dostarczone Rozwiązanie Równoważne,

Produkty projektu, wyspecyfikowane w rozdziale nr 5 OPZ oraz Platforma sprzętowa CAPE w zakresie opisanym w rozdziale nr 15. 1

Załącznika nr 1 do OPZ „ Dokumentacja techniczne Centralne Archiwum Protokołów Elektronicznych” to jest w rozdziale „Sprzęt i licencje dostarczane przez Wykonawcę” przy czym w przypadku dostarczenia Rozwiązania Równoważnego, począwszy od dnia pozytywnego jego odbioru przez Zamawiającego, gwarancja i utrzymanie nie będą obejmowały komponentów sprzętowych IBARD oraz licencji IBARD.

Wykonawca udzieli gwarancji na przedmiot zamówienia, na okres wskazany w ofercie, niemniej jednak niż 48 miesięcy licząc od dnia podpisania bez zastrzeżeń Protokołu Odbioru Końcowego.


155

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)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. 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.

10.1.2Zasady realizacji usługi gwarancji, wsparcia technicznego i serwisu

1) Wykonawca świadczy usługę wsparcia technicznego i serwisu dla Zamawiającego oraz dla wszystkich Użytkowników końcowych Systemu we wszystkich lokalizacjach objętych wdrożeniem Systemu dla Zamawiającego.

2) Usługa wsparcia technicznego i serwisu obejmuje:a) zadania administracji wszystkimi komponentami Systemu w

infrastrukturze centralnej,b) obsługę kopii zapasowych baz danych Systemu i ich odtwarzania

zgodnie z procedurami zabezpieczeń (backup’owe) dostarczonymi w ramach Dokumentacji utrzymaniowej w infrastrukturze centralnej,

c) usuwanie awarii Systemu oraz skutków awarii Systemu, oprogramowania, a także wszelkich negatywnych skutków spowodowanych korzystaniem z błędnie działających wersji Systemu we wszystkich lokalizacjach funkcjonowania Systemu,

d) usuwanie błędów w oprogramowaniu Systemu,e) realizację konfiguracji Systemu we wszystkich lokalizacjach

funkcjonowania Systemu,f) wytworzone Modyfikacje,g) 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 – w zakresie związanym z Systemem,

h) monitorowanie i rekomendowanie Zamawiającemu konieczności zainstalowania poprawek i nowych wersji, na poszczególnych elementach Systemu dla środowisk technologicznych w infrastrukturze centralnej, takich jak oprogramowania:i) sieciowych systemów operacyjnych,


156


ii) aplikacyjnych,iii) bazodanowych,iv) komunikacyjnych (o ile system zawiera tego typu

oprogramowanie),v) do prezentacji treści,vi) 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.

i) 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,

j) wymiarowanie systemu i przygotowywanie rekomendacji w celu uniknięcia spadku wydajności i błędów i awarii,

k) przeprowadzania testów wydajnościowych systemu,l) wykonanie i aktualizowanie dokumentacji utrzymaniowej systemu.

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ą 600 a 2200 w dni robocze. Wszelkie planowe działania ograniczające dostępność, responsywność i funkcjonalność systemu mogą być prowadzone w dni robocze godzinach od 2200 do 600 i w dni wolne od 600 do 1200 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


157


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ę.


158

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)7) Rodzaje kwalifikacji zgłoszeń oraz czas ich realizacji;

Rodzaj problemu

Opis Priorytet w systemie

zgłoszeniowym

Czas na usunięcie błędu

Awaria Zatrzymanie eksploatacji Systemu, 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.

krytyczny do 4 godzin od zgłoszenia przez Zamawiającego lub Użytkownika Końcowego

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

średni do 7 dni roboczych od daty zgłoszenia przez


159

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)Rodzaj

problemuOpis Priorytet w

systemie zgłoszeniowy

m


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.).

Zamawiającego lub Użytkownika Końcowego

Błąd importu danych źródłowych

Brak lub błąd importu danych z systemu źródłowego niewynikający z przyczyn 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

średni 48 godzin

Konfiguracja 1) Dostosowanie Systemu z uwagi na:

a) zmiany prawa w szczególności w dokumentach wymienionych w sekcji 5.2.9, 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,

b) zmiany w systemie repertoryjno-biurowym Użytkownika Końcowego lub zmiana systemu repertoryjno-biurowego,

c) zmiany konfiguracji importu danych na żądanie Użytkownika Końcowego,

d) zmiany w środowisku teleinformatycznym Użytkownika Końcowego i Zamawiającego,

e) zmiany w konfiguracji sieci WAN w oparciu, o którą

niski W terminie ustalonym przez Zamawiającego w porozumieniu z Wykonawcą, w przypadku braku porozumienia Stron, termin realizacji zostanie ustalony samodzielnie przez Zamawiającego.Nowa wersja Systemu jest przekazywana przez Zamawiającego do


160

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)Rodzaj

problemuOpis Priorytet w

systemie zgłoszeniowy

m


funkcjonuje System,f) aktualizacje przeglądarek internetowych,g) 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 import danych, tak, aby funkcjonował w oparciu o moduł integracyjny i wdroży lub zaktualizuje program u Użytkowników Końcowych w terminie 2 miesięcy od dnia wdrożenia modułu integracyjnego u Użytkownika Końcowego.

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.

Wykonawcy. Po wykonaniu testów przez Wykonawcę nowa wersja Systemu jest zatwierdzana do dystrybucji przez Zamawiającego, a jej instalacja na środowisku produkcyjnym realizuje Wykonawca na zlecenie Zamawiającego.


161


10.1.3Procedura realizacji zgłoszeń (Awaria, Błąd Krytyczny, Błąd Niekrytyczny, Konfiguracja)

1) Zamawiający przewiduje następujące kanały komunikacji za pośrednictwem:a) 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ę;

b) poprzez email (dodatkowy),c) telefonicznie w tym na całodobowy numer wskazany przez

Wykonawcę (dodatkowy,)d) 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 telefonicznie lub mailowo uzupełnione będą w systemie zgłoszeniowym, a obowiązywać będą rzeczywiste czasy zgłoszeń.

2) Zgłoszenie przesłane przez Zamawiającego lub Użytkownika Końcowego po godz. 1630 w dniu roboczym Wykonawca przyjmuje do realizacji następnego dnia roboczego o godz. 730 z wyłączeniem Awarii i Błędów Krytycznych, które przyjmuje się do realizacji niezwłocznie po zarejestrowaniu zgłoszenia.

3) 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. 1).

4) Zamawiający kategoryzuje zgłoszenia na formularzu zgłoszenia zgodnie z kwalifikacją określoną w tabeli zawierającej rodzaje kwalifikacji zgłoszeń.

5) Zamawiający określa które Błędy Niekrytyczne powinny być realizowane w pierwszej kolejności.

6) 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


162


(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.

7) W sytuacji kiedy rozwiązanie zgłoszenia wymaga zainstalowania modyfikacji systemu Systemu, Wykonawca wykona aktualizację w środowiskach testowym, deweloperskim lub produkcyjnym zgodnie z opisem w sekcji Procedura instalacji modyfikacji systemu.

8) 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.1.4Procedura zgłaszania Zamawiającemu konieczności zainstalowania poprawek i nowych wersji poszczególnych elementów Systemu dla środowisk technologicznych

1) 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ł.

2) 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.

3) Wykonawca przeprowadza wdrożenie poprawek podlegających realizacji w terminie 14 dni roboczych od dnia przekazania zatwierdzenia ich przez Zamawiającego.

4) Za nieterminowe wdrożenie poprawek podlegających realizacji naliczone zostaną kary umowne jak za Błąd Niekrytyczny.


163

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)5) Wykonawca przekazuje Zamawiającemu każdorazowo nową wersję

Systemu za pomocą środków komunikacji elektronicznej zawierającą w szczególności;a. nazwa podsystemu,b. numer wersji,c. kompletne kody źródłowe,d. wykaz zmian w stosunku do poprzedniej wersji,e. 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;

f. zaktualizowaną dokumentację.

10.1.5Realizacja Modyfikacji Systemu1) Pod pojęciem Modyfikacji Systemu Zamawiający rozumie zmiany w

Systemie inne niż określone w punkcie 6.13.1 podpunkt 2, w szczególności dodanie nowych funkcjonalności, zmiany kodu źródłowego inne niż wynikające z usługi wsparcia i serwisu.

2) Zamawiający może zlecić Wykonawcy Modyfikacje systemu, których pracochłonność liczona jest w wymiarze 6 000 godzin w okresie trwania usługi wsparcia technicznego i serwisu.

3) Procedura zgłaszania zleceń Modyfikacji oraz kanały komunikacji:a. 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 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 telefonicznie lub mailowo uzupełnione będą w systemie zgłoszeniowym, a obowiązywać będą rzeczywiste czasy zgłoszeń.


164


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


165


zgodnie z procedurą opisaną w pkt. h – j. Terminowa 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.

10.1.6Procedura instalacji Modyfikacji 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


166


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.

6) Dystrybucja nowych wersji Systemu następuje według następującej procedury:a) Wykonawca przekazuje Zamawiającemu nową wersję Systemu na

nośniku (CD, DVD oraz za pomocą środków komunikacji elektronicznej) zawierającą w szczególności;- numer wersji,- szczegółową procedurę instalacji oprogramowania;- wykaz zmian w stosunku do poprzedniej wersji;- instrukcję użytkownika ze szczególnym uwzględnieniem sposobu

postępowania w związku z wprowadzonymi zmianami a także skutki zmian wersji oprogramowania od strony użytkowej;

- 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.

b) Zamawiający dokonuje odbioru wersji (Załącznik nr 10 do umowy).c) Sposób dystrybucji wersji określa Zamawiający.d) W przypadku podjęcia decyzji o wykonaniu instalacji Systemu na

salach rozpraw, Wykonawca dokona instalacji we uzgodnionych lokalizacjach w terminie do 4 tygodni od daty zatwierdzenia wersji do wdrożenia.

e) Na żądanie Zamawiającego Wykonawca zapewnia wsparcie dla Użytkownika końcowego przy instalacji nowych wersji Systemu.

f) W szczególnych przypadkach, gdy konieczne jest pilne wykonanie niewielkiej zmiany w oprogramowaniu, dopuszcza się przesłanie aktualizacji bez dostarczania kompletnej nowej wersji. Punkty a) i b) stosuje się odpowiednio.

7) Wraz z nową wersją Wykonawca zobowiązany jest dostarczyć dokumentację techniczną oraz użytkową, obejmującą wykonane zmiany w Systemie. Dokumentacja musi zawierać opis scenariuszy testowych zaprojektowanych dla każdej wykonanej zmiany. W przypadku, gdy zmiany nie nastąpiły, nowa wersja dokumentacji nie musi być dostarczana.


167

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)8) W wypadku, gdy nowa wersja Systemu powstała na skutek

wprowadzenia zmian w Systemie przez podmiot inny niż Wykonawca, Wykonawca na polecenie Zamawiającego dokonuje dystrybucji wersji zgodnie z ust. 6 pkt. c) – e).

10.1.7Dostępność systemu1) 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.

2) Kalendarz dostępności Systemu – 24 godziny na dzień, 7 dni w tygodniu, 365 dni w roku, 366 dni w roku przestępnym.

3) 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.


168


Załączniki do OPZ:

Załącznik nr 1 do OPZ „Dokumentacja Techniczna Centralne Archiwum Protokołów Elektronicznych”.

Załącznik nr P.01. do OPZ „Agenda Spotkania”---- w odrębnym dokumencie ----

Załącznik nr P.02. do OPZ „Protokół ze Spotkania”---- w odrębnym dokumencie ----

Załącznik nr P.03. do OPZ „Dokument Zarządczy”---- w odrębnym dokumencie ----

Załącznik nr P.04. do OPZ „Plan Migracji Danych”---- w odrębnym dokumencie ----

Załącznik nr P.05. do OPZ „Raport z Migracji Danych”---- w odrębnym dokumencie ----

Załącznik nr P.06. do OPZ „Plan Szkoleń”---- w odrębnym dokumencie ----

Załącznik nr P.07. do OPZ „Raport z Przeprowadzonych Szkoleń”---- w odrębnym dokumencie ----


169


Załącznik nr P.08. do OPZ „Raport z Testów”---- w odrębnym dokumencie ----

Załącznik nr P.09. do OPZ „Plan Testów”---- w odrębnym dokumencie ----

Załącznik nr P.10. do OPZ „Plan Uruchomienia Systemu”---- w odrębnym dokumencie ----

Załącznik nr P.11. do OPZ „Raport z Uruchomienia Systemu”---- w odrębnym dokumencie ----

Załącznik nr P.14. do OPZ „Rejestr Ryzyk”---- w odrębnym dokumencie ----

Załącznik nr P.15. do OPZ „Rejestr Tematów Otwartych”---- w odrębnym dokumencie ----

Załącznik nr P.16. do OPZ „Rejestr Wymagań”---- w odrębnym dokumencie ----


170

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)Załącznik nr K.01. do OPZ „Scenariusze Testowe”---- w odrębnym dokumencie ----

Załącznik nr K.02. do OPZ „Protokół Testów Akceptacyjnych”---- w odrębnym dokumencie ----

Załącznik nr S.01. do OPZ „Analiza Biznesowa i Systemowa”---- w odrębnym dokumencie ----

Załącznik nr S.02. do OPZ „Projekt Techniczny”---- w odrębnym dokumencie ----


171

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)Załącznik nr I.01 do OPZ „Specyfikacja interfejsów”

Specyfikacja interfejsów w zakresie PI

Nazwa metody Opis Parametry wejściowe (typ danych)

Parametry wyjściowe (typ danych)

Interfejs dostarczany przez CRCSGetPathVideo Pobranie ścieżki do

pliku wideoPI → 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łuPI → CRCS

Sąd (tekst) Wydział (tekst) Sygnatura akt (tekst) Data posiedzenia

(data) Imię (tekst) Nazwisko (tekst) PESEL

/identyfikator(liczba)

Ś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 RCS


172

Załącznik nr Z.01 do Umowy nr …. z dnia ...................... – „Opis przedmiotu zamówienia” (OPZ)Nazwa metody Opis Parametry wejściowe

(typ danych)Parametry wyjściowe (typ danych)

GetReadingRoomCalendar

Żądanie podania kalendarza zajętości czytelniPI → RCS

Sąd (tekst) Data od (data) Data do (data)

Kalendarz dla danego okresu (xml)

SendReadingRoomApplication

Wniosek o rezerwację miejsca w czytelniPI → RCS

Sąd (tekst) 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

Numer wniosku (tekst/liczba)


173



udostępnić e-protokół (boolean)

CancelReadingRoomReservation

Odwołanie rezerwacji miejsca w czytelniPI → RCS


Rezygnacja (boolean)

Potwierdzenie przyjęcia (boolean)

GetApplicationStatus Ustalanie statusu obsługi złożonego uprzednio wnioskuPI → RCS


Status wniosku (tekst)

SendASRProtocol Wniosek wykonania automatycznej transkrypcjie-protokołuPI → RCS


(data) Imię (tekst) Nazwisko (tekst) PESEL/identyfikator

(liczba) Czas od Czas do

Numer wniosku (tekst/liczba) Czas oczekiwania (liczba)

Lub Odmowa (boolean) Powód (tekst)

SendASRSentence Wniosek wykonania automatycznej transkrypcjie-uzasadnieniaPI → RCS


(data)

Numer wniosku (tekst/liczba) Czas oczekiwania (liczba)

Lub Odmowa (boolean) Powód (tekst)


174



Imię (tekst) Nazwisko (tekst) PESEL/identyfikator

(liczba)SendRemoteHearingApplication

Przesłanie wniosku o rozprawę odmiejscowionąPI → RCS

Wniosek (plik xml) Podpis wniosku (plik)



Parametry wyjściowe (typ danych)

Interfejs dostarczany przez PIConfirmReadingRoomReservation

Potwierdzenie rezerwacji miejsca w czytelni dla użytkownikaRCS → PI


Decyzja (boolean) Uzasadnienie (tekst) Najbliższe terminy

(data – lista)


SendASRTranscription Przesłanie wyniku automatycznej transkrypcjiRCS → PI


Pliki autotranskrypcji (plik)

Dane o jakości transkrypcji



175



(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)


Interfejs dostarczany przez CAPEGetVideo Pobranie pliku wideo

według wskazanej ścieżkiPI → CAPE

Ścieżka (tekst) Plik (plik)

GetProtocol Pobranie plików e-protokołu wg. wskazanej ścieżkiPI → CAPE

Ścieżka (tekst) Pliki (plik)

Specyfikacja interfejsów w zakresie ARMNazwa metody Opis Parametry wejściowe

(typ danych)Parametry Wyjściowe (typ danych)

Interfejs dostarczany przez CRCSSendASRSentence Przekazanie Numer zlecenia (liczba) Informacja potwierdzająca


176



produktów automatycznej transkrypcji e-uzasadnieniaCPT→CRCS

Pliki transkrypcji e-uzasadnienia w formatach .xml i .rtf (plik)

przyjęcie plików (boolean)

SendCorrectedSentence

Przekazanie produktów procesu korekcyjnego e-uzasadnieniaCPT→CRCS

Numer zlecenia Pliki pełnej transkrypcji

e-uzasadnienia w formatach .xml i .rtf (plik)

Komentarze OKZT (tekst)

Informacja potwierdzająca przyjęcie plików (boolean)

SendCorrectedProtocol Przekazanie produktów procesu korekcyjnego e-protokołuCPT→CRCS

Numer zlecenia (liczba) Pliki pełnej transkrypcji

e-protokołu w formatach .xml i .rtf (plik)

Komentarze OKZT (tekst)


SendASRProtocol Przekazanie produktów automatycznej transkrypcji e-protokołuCPT→CRCS

Numer zlecenia (liczba) Pliki transkrypcji

e-protokołu w formatach .xml i .rtf (plik)



177



SendImprovedTranscription

Przekazanie produktów procesu poprawyCPT→CRCS

Numer zlecenia Pliki pełnej transkrypcji

w formatach .xml I .rtf Komentarze OKZT


ChangeOrderDate Wniosek o zmianę terminu realizacji zleceniaCPT→CRCS

Numer zlecenia (liczba) Informacja potwierdzające przyjęcie informacji (boolean)

SetQualityStatus Zgłoszenie słabej jakości nagraniaCTP→CRCS

Numer zlecenia (liczba) Informacja o poziomie

jakości (tekst)

Informacja potwierdzająca przyjęcie informacji (boolean)

SetOrderStatus Bieżący status zleceniaCPT→CRCS

Numer zlecenia (liczba) Status zlecenia (tekst) Oczekiwany czas

realizacji zlecenia (tekst)



Parametry Wyjściowe (typ danych)

Interfejs dostarczany przez CAPEGetSentence Pobranie pliku

nagrania e-uzasadnieniaCPT→CAPE

Ścieżka do pliku nagrania e-uzasadniania (tekst)

Plik nagrania e-uzasadnienia (plik)


178



GetProtocol Pobranie pliku nagrania e-protokołuCPT→CAPE

Ścieżka do pliku nagrania e-protokołu (tekst)

Plik nagrania e-protokołu (plik)

Interfejs dostarczany przez CPTMakeASRSentence Zlecenie wykonania

ARM dla pliku e-uzasadnieniaCRCS→CPT

Pliki e-uzasadnienia w formacie .asr (plik)

Lista zawierająca parametry zlecenia:

o Rodzaj zlecenia (tekst)

o Zleceniodawca (tekst)

o Osoba składająca wniosek (tekst)

o Termin realizacji zlecenia (data)

o Sygnatura akt (tekst)

o Rodzaj nagrania (tekst)

o Przedziały czasowe nagrania do przetworzenia

Numer przydzielony do zlecenia (liczba)

CorrectASRSentence Zlecenia wykonania Pliki ARM Informacja o przyjęciu do


179



korekty dla pliku ARM e-uzasadnieniaCRCS→CPT

e-uzasadnienia w formacie xml, rtf (plik)

Ścieżka CAPE do pliku nagrania e-uzasadnienia (tekst)

Protokół skrócony (tekst)

Metadane nagrania ze słownikiem uczestników (tekst)








o Przedziały

realizacji (tekst) Numer przydzielony do

zlecenia (liczba)


180



czasowe nagrania do przetworzenia

TranscriptProtocol Zlecenie wykonania pełnej transkrypcji dla pliku e-protokołuCRCS→CPT

Ścieżka w CAPE do pliku nagrania e-protokołu (tekst)

Protokół skrócony (tekst)

Metadane nagrania ze słownikiem uczestników (tekst)







o Informacja o przekazaniu dla



181



zlecenia wniosku o zmianę terminu realizacji (boolean)



ConfirmQuality Potwierdzenie poprawności jakości produktów przez sądCRCS→CPT

Numer zlecenia (liczba) Status jakości (tekst)

Informacja potwierdzająca przyjęcie statusu (boolean)

MakeASRProtocol Zlecenie wykonania ARM dla pliku e-protokołuCRCS→CPT

Ścieżka w CAPE do pliku nagrania e-protokołu





Informacja potwierdzająca przyjęcie do realizacji (boolean)



182







ImproveTranscription Zlecenie wykonania poprawy dla plików transkrypcjiCRCS→CPT

Numer zlecenia poprawianego (liczba)

Uwagi sądu (tekst) Lista zawierająca

parametry zlecenia:o Rodzaj zlecenia

(tekst)o Osoba składająca

wniosek (tekst)o Wymagany

termin realizacji zadania (data)

o Przedziały czasowe nagrania do

Informacja potwierdzająca przyjęcie do realizacji (boolean)

Numer przydzielony do zadania (liczba)


183



poprawySendReminder Wysyłka ponaglenia

przez sąd (dla e-protokołu i e-uzasadnienia)CRCS→CPT

Numer zlecenia (liczba) Informacja potwierdzająca przyjęcie informacji (boolean)

SendRequestAnswer Odpowiedź na wniosek dot. zmiany terminu zleceniaCRCS→CPT

Numer zlecenia (liczba) Stanowisko sądu

(tekst)


CancelOrder Anulowanie zleceniaCRCS→CPT

Numer zlecenia (liczba) Potwierdzenie anulowania zlecenia (boolean)

GetExpectedTime Ustalenie bieżącego czasu oczekiwania na zakończenie realizacji zleceniaCRCS→CPT

Numer zlecenia (liczba) Oczekiwany bieżacy czas realizacji zadania (teskt)


184

wroclaw.sa.gov.pl · Web viewUtrwalenie przebiegu posiedzenia sądowego za pomocą urządzenia...

Documents

Transcript of wroclaw.sa.gov.pl · Web viewUtrwalenie przebiegu posiedzenia sądowego za pomocą urządzenia...