wroclaw.sa.gov.pl · Web viewPliki zawierające logi zdarzeń systemowych będą podpisywane, co...

DOKUMENTACJA TECHNICZNACENTRALNE ARCHIWUM PROTOKOŁÓW

ELEKTRONICZNYCH

CENTRALNE ARCHIWUM PROTOKOŁÓW ELEKTRONICZNYCH – Dokumentacja Techniczna

METRYCZKA:L.p.

Nazwa Wartość

1. Kto utworzył

2. Data utworzenia 2015-11-10

3. Numer umowy DIRS nr 42/2015

HISTORIA ZMIAN:L.p.

Imię i nazwisko Data zmiany Opis zmiany

1. Zespół Wykonawcy 2015-11-10 Utworzenie pierwszej wersji na podstawie dokumentu Projekt Techniczny

2.

3.

4.

5.

6.

ZATWIERDZENIE DOKUMENTU:

Rola Imię i nazwisko Data Podpis

CENTRALNE ARCHIWUM PROTOKOŁÓW ELEKTRONICZNYCHDokumentacja Techniczna Strona 2 z 135

SPIS TREŚCI

METRYCZKA:................................................................................................................2HISTORIA ZMIAN:.........................................................................................................21 Wprowadzenie...................................................................................................6

1.1 Cel dokumentu.............................................................................................................61.2 Struktura dokumentu...................................................................................................61.3 Wymagania OPZ dotyczące Projektu Technicznego.....................................................71.4 Opis notacji...................................................................................................................81.5 Słownik skrótów i pojęć..............................................................................................11

2 Dokumenty powiązane.....................................................................................142.1 Dokumenty.................................................................................................................142.2 Przepisy prawa...........................................................................................................14

3 Założenia i ograniczenia..................................................................................173.1 Założenia....................................................................................................................17

4 Ogólna koncepcja systemu...............................................................................194.1 Procesy biznesowe.....................................................................................................19

4.1.1 Brakowanie akt sprawy..............................................................................................194.1.2 Przekazanie materiałów archiwalnych do Archiwum Państwowego...........................214.1.3 Wprowadzanie danych do CAPE i tworzenie spisów zdawczo-odbiorczych.................234.1.4 Wycofanie akt sprawy................................................................................................264.1.5 Wyszukiwanie i przeglądanie spraw...........................................................................274.1.6 Zamawianie dokumentów..........................................................................................27

4.2 Opis systemu i podsystemów.....................................................................................284.3 Analiza otoczenia systemu.........................................................................................28

4.3.1 Active Directory Ministerstwa Sprawiedliwości...........................................................294.3.2 Systemy repertoryjno-biurowe sądów........................................................................294.3.3 System ReCourt..........................................................................................................29

5 Specyfikacja i opis wymagań............................................................................315.1 Wymagania funkcjonalne...........................................................................................31

5.1.1 Agent..........................................................................................................................315.1.2 Portal..........................................................................................................................355.1.3 Podsystem Uwierzytelniania i Autoryzacji..................................................................395.1.4 System Zarządzania Archiwum..................................................................................445.1.5 Podsystem Przechowywania Danych..........................................................................515.1.6 Ogólne........................................................................................................................52

5.2 Wymagania pozafunkcjonalne....................................................................................526 Model wykorzystania systemu..........................................................................58

6.1 Specyfikacja aktorów..................................................................................................596.2 Przypadki użycia – Administracja SZA........................................................................60


6.3 Przypadki użycia – Portal............................................................................................626.3.1 Diagram stanów dla brakowania/przekazania do AP..................................................746.3.2 Diagram stanów dla sprawy.......................................................................................756.3.3 Diagram stanów dla zamówienia................................................................................76

6.4 Przypadki użycia – PUiA..............................................................................................776.5 Przypadki użycia – PPD...............................................................................................92

7 Architektura logiczna Systemu.........................................................................947.1 Architektura Systemu.................................................................................................947.2 Agent..........................................................................................................................967.3 Podsystem Przechowywania Danych..........................................................................977.4 Podsystem Uwierzytelnienia i Autoryzacji..................................................................997.5 Portal........................................................................................................................1007.6 System Zarządzania Archiwum................................................................................1017.7 Interfejsy zewnętrzne...............................................................................................1027.7.1 Integracja z systemem ePUAP..............................................................................1027.7.2 Komunikacja Agent – SZA.....................................................................................1037.8 CAPE w kontekście systemów zewnętrznych............................................................110

8 Lista uprawnień i ról......................................................................................1139 Specyfikacja raportów....................................................................................11610 Specyfikacja ekranów Portalu.........................................................................11711 Technologia wykonania..................................................................................119

11.1 Podsystem PUiA....................................................................................................11911.2 Podsystem Portalu................................................................................................11911.3 System Zarządzania Archiwum.............................................................................12011.4 Podsystem Przechowywania Danych....................................................................120

12 Opis metadanych...........................................................................................12113 Architektura fizyczna.....................................................................................122

13.1 Diagram wdrożenia...............................................................................................12213.2 Topologia sieci......................................................................................................12213.3 Sieć SAN...............................................................................................................12613.1 Konfiguracja biblioteki taśmowej..........................................................................13213.2 Konfiguracja macierzy..........................................................................................13313.3 Wdrożenie agentów..............................................................................................137

14 Lista procedur utrzymaniowych......................................................................13815 Sprzęt i licencje.............................................................................................139

15.1 Dostarczane przez Wykonawcę............................................................................13915.1.1 Sprzęt i licencje........................................................................................................13915.1.2 Opis wymagań programowych.................................................................................143

15.2 Udostępniane przez Zamawiającego....................................................................144


15.2.1 Sprzęt.......................................................................................................................14415.2.2 Licencje....................................................................................................................14415.2.3 Opis wymagań programowych.................................................................................144

16 Testy.............................................................................................................14616.1 Program przebiegu testów....................................................................................14616.2 Raport z przebiegu testów....................................................................................146

SPIS RYSUNKÓW......................................................................................................147SPIS TABEL..............................................................................................................147SPIS ZAŁĄCZNIKÓW..................................................................................................148


1 WprowadzenieDokumentacja Techniczna wraz z załącznikami jest jednym z produktów umowy DIRS nr 42/2015 z dnia 23.07.2015 r. dotyczącej dostawy i wdrożenia systemu Centralnego Archiwum Protokołów Elektronicznych (CAPE). Dokument jest wynikiem prac analitycznych i projektowych prowadzonych w kolejnych etapach realizacji.

1.1 Cel dokumentuNiniejszy dokument opisuje aspekty techniczne Systemu CAPE. Jego podstawowymi celami są:

Przedstawienie ogólnej koncepcji Systemu CAPE

Udokumentowanie wyników prac analitycznych w zakresie budowy Portalu

Udokumentowanie sposobu realizacji wymagań

Opisanie wykorzystywanej technologii oraz wykorzystywanych produktów

Zaprezentowanie architektury systemu

Dokumentacja wdrożeniowa

1.2 Struktura dokumentuRozdział 1. Zawiera wprowadzenie do dokumentu Dokumentacja Techniczna.

Rozdział 2. Stanowi spis dokumentów i przepisów prawa powiązanych z dokumentem Dokumentacja Techniczna.

Rozdział 3. Stanowi spis wszystkich założeń i ograniczeń podjętych na etapie projektu.

Rozdział 4. Zawiera ogólną koncepcję Systemu CAPE

Rozdział 5. Zawiera specyfikację i opis wymagań na realizację Centralnego Archiwum Protokołów Elektronicznych. Wymagania zostały podzielone na funkcjonalne z przypisaniem do poszczególnych modułów oraz pozafunkcjonalne realizowane w ramach całego systemu.

Rozdział 6. Zawiera model wykorzystania systemu w postaci przypadków użycia dla funkcji, które są wywoływane przez człowieka.

Rozdział 7. Zawiera diagram i opis architektury logicznej całego Systemu oraz odrębne diagramy dla poszczególnych podsystemów.

Rozdział 8. Zawiera listę ról i uprawnień wykorzystywanych w systemie

Rozdział 9. Zawiera specyfikę raportów

Rozdział 10. Zawiera specyfikę ekranów Portalu

Rozdział 11. Zawiera opis technologii wykonania i wykorzystania produktów

Rozdział 12. Zawiera specyfikę metadanych paczki archiwalnej/pliku oraz specyfikę parametrów wyszukiwania

Rozdział 13. Zawiera opis architektury fizycznej

Rozdział 14. Zawiera listę procedur utrzymaniowych


Rozdział 15. Zawiera zestawienie sprzętu i licencji dostarczanych przez Wykonawcę oraz zestawienie sprzętu i licencji udostępnianych przez Zamawiającego.

1.3 Wymagania OPZ dotyczące Projektu TechnicznegoZgodnie z Opisem Przedmiotu Zamówienia Projekt Techniczny powinien zawierać, co najmniej:

1. Opis architektury w pełni redundantnej sieci SAN pomiędzy serwerami, Przełącznikami FC, macierzami dyskowymi oraz Biblioteką Taśmową: opisane w rozdziale - 13.3 Sieć SAN

2. Uwzględnienie Biblioteki Taśmowe zgodnie z jej funkcjonalnością: opisane w rozdziale - Konfiguracja biblioteki taśmowej

3. Wszystkie elementy konfiguracji fizycznej i logicznej w tym co najmniej:3.1. Topologię sieci: opisane w rozdziale - 13.2 Topologia sieci3.2. Opis modułowej budowy CAPE: opisane w rozdziale - 7 Architektura logiczna Systemu3.3. Opis redundancji na poziomie macierzy i biblioteki taśmowej: opisane w rozdziale -

Konfiguracja biblioteki taśmowej oraz 13.2 Konfiguracja macierzy3.4. Propozycję auto-rekonfiguracji w razie awarii pojedynczego elementu oraz w przypadku

awarii wielu elementów bazując na wymaganej i zaproponowanej redundancji3.5. Plan LUN maskingu (zoning): opisane w rozdziale - 13.2 Konfiguracja macierzy3.6. Ilościowe przedstawienie portów i ich zajętości na urządzeniach w sieci SAN (Przełączniki

FC, macierz, Biblioteki taśmowe) : opisane w rozdziale - 13.3 Sieć SAN3.7. Przykładową propozycję adresacji dla urządzeń i usług pracujących w konfiguracji

klastrowej: opisane w rozdziale - 13.2 Topologia sieci3.8. Opis zestawu metadanych pliku na podstawie których będzie on mógł zostać wyszukiwany

w CAPE: opisane w rozdziale - 12 Opis metadanych3.9. Propozycję procedur utrzymaniowych: opisane w rozdziale - 14 Lista procedur

utrzymaniowych4. Relacje pomiędzy wszystkimi elementami infrastruktury: opisane w rozdziale - 7 Architektura

logiczna Systemu5. Listę wszystkich elementów sprzętowych oraz licencji: opisane w rozdziale - 15 Sprzęt i licencje

W zakresie prac analitycznych dla Portalu:

1. Prace analityczne mające na celu przygotowanie szczegółowych wymagań w zakresie portalu dostępu do Centralnego Archiwum Protokołów Elektronicznych. Prace powinny obejmować:1.1. definicję procesów biznesowych wykorzystujących CAPE: opisane w rozdziale - 4.1 Procesy

biznesowe 1.2. definicję ról użytkowników Portalu: opisane w rozdziale - 8 Lista uprawnień1.3. analizę przypadków użycia: opisane w rozdziale - 6.3 Przypadki użycia – Portal1.4. szczegółowy opis wymaganych raportów: opisane w rozdziale - 9 Specyfikacja raportów1.5. szczegółowy opis zawartości ekranów i formatek systemu: opisane w rozdziale - 10

Specyfikacja ekranów Portalu1.6. określenie wymagań wydajnościowych systemu (czasy generowania raportów,

odświetlania ekranów): opisane w rozdziale - 5.2 Wymagania pozafunkcjonalne


1.7. określenie wymagań obciążeniowych – ilość jednocześnie pracujących użytkowników, wykonywanych operacji: opisane w rozdziale - 5.2 Wymagania pozafunkcjonalne

1.4 Opis notacjiProcesy biznesowe wykorzystujące funkcje CAPE zostały opisane zgodnie z notacją BPMN 2.0. Dla opisu analitycznego systemu CAPE zastosowano notację zgodną z UML 2.0. Poniżej przedstawiono wyjaśnienia notacji z wykorzystaniem diagramu procesu, diagramu przypadków użycia, diagramu stanu oraz diagramu komponentów.

Rysunek 1: Opis notacji dla procesów biznesowych

BPMN Opis notacj i

«Pool» B«Pool» A

Aktywność 1

Aktywność 2 Aktywność 3

Aktywność 4 Aktywność 5

Aktywność 6Aktywność 7

Aktywność 8

Przepływ komunikatu - używany do pokazania wymiany komunikatów pomiędzy odrębnymi uczestnikami procesu

Przepływ sterowania - używany do pokazania kolejności, w jakiej zadania będą wykonywane w ramach procesu

Basen - ogranizacja, rola, system (podsystem) odpowiedzialna za wykonanie czynności w procesie

Zadanie - czynność wykonywana w trakcie procesu; ogólne pojęcie określające pracę, którą wykonuje uczestnik procesu

Zdarzenie początkowe -punkt początku procesu

Zdarzenie końcowe - osiągniecie końca procesu

Obiekt danych - informacja przepływająca przez proces, np. pismo, e-mail, dokument. Kierunek strzałki oznacza kierunek przepływu danych.

Zdarzenie komunikat - oznaczenie wysłania komunikatu

Zdarzenie komunikat - oznaczenie otrzymania komunikatu

Bramka ALBO (XOR) - bramka rozłączna, tylko jedna z gałęzi spełnia warunek bramki (aktywne jest tylko jedno łącze bramki). Warunek, jaki powinien byc spełniony na danej gałęzi, jest zamieszczony przy tej gałęzi.

Bramka I (OR) - bramka rozdzielenia procesu na gałęzie, które będą wykonywane równolegle. Podczas łączenia bramka tego typu oczekuje na wykonanie się wszystkich ścieżek aby umożliwić dalszy przepływ.

warunek 2warunek 1

Diagram BPMN służy do graficznego przedstawienia procesów biznesowych zachodzących w ramach danej organizacji lub pomiędzy organizacjami.


Rysunek 2: Opis notacji dla diagramów przypadków użyciauc Opis notacj i

Use Case1

Use Case2

Use Case3

Aktor1

Aktor: użytkownik systemu, podsystem (moduł) systemu LCI lub system zewnętrzny, który inicjuje (wykonuje) pewne czynności w systemie, opisane przypadkiem użycia.

Use Case (przypadek użycia): określa sekwencję czynności i ich wariantów, które system (lub inna jednostka) może wykonać poprzez interakcję z aktorami tego systemu. Use Case jest inicjowany przez konkretnego, pojedynczego aktora. Najczęściej przypadkowi użycia odpowiada pojedyncza funkcja systemu.

Relacja typu 'extend' świadczy o rozszerzeniu czynności opisanych przypadkiem Use Case1 poprzez przypadek Use Case3. Rozszerzany (bazowy) przypadek użycia (Use Case1) może wystąpić samodzielnie, ale przy spełnieniu określonych warunków jego zachowanie może być rozszerzone poprzez zachowanie (funkcjonalność) innego przypadku użycia (Use Case3).

Relacja typu 'include' świadczy o zawieraniu się czynności opisanych przypadkiem Use Case2 w czynnościach opisanych przypadkiem Use Case1. Zawierany przypadek użycia (Use Case2) nie występuje samodzielnie, lecz wyłącznie przy odwołaniu się do większego, zawierającego (bazowego) przypadku użycia (Use Case1).

Asocjacja: relacja (powiązanie) aktora i przypadku użycia (Aktor1 inicjuje/wykonuje Use Case1). Relacja może mieć wskazanie kierunku.

Aktor2

General izacja (inaczej uogólnienie) jest to relacja 'typ-podtyp' pomiędzy obiektami tego samego rodzaju (np. aktor - aktor). Stosując uogólnienia można definiować ogólne rodzaje aktorów (Aktor1) i ich uszczegółowienia (Aktor2). Powoduje to, że niektórzy aktorzy (Aktor2) mogą stanowić formy specjalizacji innych aktorów (Aktor1) a funkcja aktora ogólnego (Aktor1) może wchodzić w zakres obowiązków aktora uszczegółowionego (Aktor2).

«extend»

«include»

Diagram przypadków użycia służy do modelowania funkcjonalności systemu i jest tworzony w początkowych fazach modelowania. Diagram ten stanowi tylko przegląd możliwych działań w systemie, szczegóły ich przebiegu są modelowane za pomocą innych technik (np. diagramów stanu lub aktywności). Diagram przypadków użycia przedstawia usługi, które system świadczy aktorom, lecz bez wskazywania konkretnych rozwiązań technicznych1.

1 Wikipedia, https://pl.wikipedia.org/wiki/Diagram_przypadk%C3%B3w_u%C5%BCycia, 08.09.2015.


https://pl.wikipedia.org/wiki/Diagram_przypadk%C3%B3w_u%C5%BCycia

Rysunek 3: Opis notacji dla diagramów stanustm Diagramy stanów

Stan 1

Stan 2

Stan początkowy: oznaczenie początku istnienia obiektu w systemie

Stan końcowy: oznaczenie końca istnienia obiektu w systemie

Stan: okol iczność lub sytuacja, w jakiej znajduje się obiekt w cyklu swojego życia

Przejście: relacja między dwoma stanami, wskazująca, że obiekt pod wpływem określonego zdarzenia przejdzie ze Stanu 1 do Stanu 2. Przejście może być opisane przez trzy elementy: zdarzenie, warunek, akcja (każdy z tych elementów jest opcjonalny)

Stan 3 Stan 4

Decyzja: wybór jednego z możliwych przejść dla stanu na podstawie określonego warunku. Każda ścieżka wyjściowa jest etykietowana przez warunek decydujący o jej wyborze. Warunki umieszczane są w nawiasach kwadratowych.

[warunek A][warunek B]

zdarzenie, akcja

Diagram stanów przedstawia cykl życia obiektu, tj. pokazuje możliwe stany obiektu oraz przejścia, które powodują zmianę tego stanu. Można też z niego odczytać, jakie zdarzenia powodują przejście obiektu w dany stan, a także jakie akcje są podejmowane w odpowiedzi na pojawienie się określonych stanów2.

2 Wikipedia, https://pl.wikipedia.org/wiki/Diagram_stan%C3%B3w, 08.09.2015


https://pl.wikipedia.org/wiki/Diagram_stan%C3%B3w

Rysunek 4: Opis notacji dla diagramu komponentówcmp Diagram komponentów

Komponent1

Komponent2 Komponent3

Komponent4

Interfejs udostępniający: zestaw operacji, poprzez które komponent oferuje swoje usługi

Interfejs pozyskujący: zestaw operacji, które pozwalają komponentom na korzystanie z usług innych komponentów

Konektor składany: powiązanie dwóch komponentów, z których jeden udostępnia poprzez interfejs usługę pozyskiwaną przez drugi komponent

Komponent: element oprogramowania - fizyczna, wymienna część systemu (np. tabela, plik, biblioteka), która wykorzystuje i realizuje pewien zbiór interfejsów

Diagram komponentów to rodzaj diagramu wdrożeniowego, który pozwala na zamodelowanie elementów oprogramowania (komponentów) wchodzących w skład systemu oraz połączeń między nimi3.

1.5 Słownik skrótów i pojęćPoniższy słownik ma na celu rozszerzenie pojęć umieszczonych w dokumencie, które nastąpiło w wyniku analizy. W słowniku uwzględniono również skróty i symbole używane w dokumencie.

Definicje użytych pojęć:

Active Directory – usługa katalogowa (hierarchiczna baza danych) umożliwiająca zarządzanie kontami, konfigurowanie ustawień systemowych użytkownika oraz praw dostępu, konfigurowanie uprawnień aplikacji a także zarządzanie nimi.

AD – patrz: Active Directory

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

CAPE – Centralne Archiwum Protokołów Elektronicznych.

CWDM – technika zwielokrotniania połączeń w technice światłowodowej.

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

LAN – Local Area Network, sieć lokalna wykorzystująca połączenia Ethernet.

3 Wikipedia, https://pl.wikipedia.org/wiki/Diagram_komponent%C3%B3w, 08.09.2015


https://pl.wikipedia.org/wiki/Diagram_komponent%C3%B3w

LTO – Linear Tape-Open, standard zapisu danych na taśmach. Obecnie wykorzystywany standard LTO-6 ma pojemność 2,5TB nieskompresowanych danych na pojedynczej tasiemce.

Materiały archiwalne – materiały o szczególnym znaczeniu dla państwa, oznaczane symbolem 'A' lub materiały kat. 'B', przechowywane w Archiwum zakładowym lub w CAPE.. Po upływie okresu przechowywania w archiwach zakładowych materiały kategorii ‘A’ są przechowywane wieczyście przez Archiwum Państwowe.

MQ – ang. Message Queue, Kolejka komunikatów. System używany do wymiany komunikatów pomiędzy systemami, komponentami i procesami.

OP – Ośrodek podstawowy przetwarzania danych.

OZ – Ośrodek zapasowy przetwarzania danych.

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

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

Podsystem Przechowywania Danych – komponent sprzętowo-programowy, zainstalowany w środowisku infrastruktury centralnej. Realizujący przechowywanie danych zgodnie z wymaganiami. Ponadto, komponent realizujący migrację danych pomiędzy nośnikami dyskowymi a taśmami magnetycznymi.

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

PPD – patrz: Podsystem Przechowywania Danych

Protokół elektroniczny – nagranie obrazu i dźwięku albo samego dźwięku wszystkich czynności, które dzieją się na sali sądowej w czasie trwania rozprawy.

RC – ReCourt.

RCS – system ReCourt Services.

SAN – Storage Area Network, sieć pamięci masowej

SFP, SFP+ – standard modułów rozbudowy urządzeń sieciowych

SRB – patrz: System repertoryjno-biurowy.

Sprawa zamknięta – postępowanie zamknięte decyzją organu sądu, właściwego do prowadzenia sprawy. W systemie repertoryjnym (lub adekwatnym) status sprawy oznaczający jej zamknięcie (np. w przypadku programu Sędzia2 jest to status „Przekazana do archiwum”).

SWITCH LAN – przełącznik sieci LAN

SWITCH SAN – przełącznik sieci SAN

System repertoryjno-biurowy – oprogramowanie służące m.in. do ewidencjonowania i obsługi postępowań toczących się w sądach.

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.


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

SZA – patrz: System Zarządzania Archiwum

VLAN – wirtualna sieć lokalna, logicznie wydzielona z większej sieci fizycznej.


2 Dokumenty powiązaneRozdział zawiera wykaz dokumentów i obowiązujących przepisów prawa powiązanych z niniejszym dokumentem.

2.1 Dokumenty1 Umowa DIRS nr 42/2015

2 Opis Przedmiotu Zamówienia stanowiący załącznik nr 1 do Umowy DIRS nr 42/2015

2.2 Przepisy prawaLista aktów prawnych określających wymogi dla systemu archiwizacji dokumentów elektronicznych w sądach powszechnych:

1 ustawa z dnia 17 listopada 1964 r. – Kodeks postępowania cywilnego (t.j. Dz. U. z 2014 r., poz. 101 ze zm.);

2 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. z 2015 r., poz. 359)

3 rozporządzenie Ministra Sprawiedliwości z dnia 24 lutego 2010 r. w sprawie urządzeń i środków technicznych umożliwiających przeprowadzenie dowodu na odległość w postępowaniu cywilnym (Dz. U. z 2010 Nr 34, poz. 185)

4 ustawa z dnia 6 czerwca 1997 r. – Kodeks postępowania karnego (Dz. U. Nr 89, poz. 555 ze zm.)

5 rozporządzenie Ministra Sprawiedliwości z dnia 14 września 2012 r. w sprawie rodzaju urządzeń i środków technicznych służących do utrwalania obrazu lub dźwięku dla celów procesowych oraz sposobu przechowywania, odtwarzania i kopiowania zapisów (Dz. U. z 2012, poz. 1090)

6 ustawa z dnia 24 sierpnia 2001 r. – Kodeks postępowania w sprawach o wykroczenia (t.j. Dz. U. z 2013 r., poz. 395 ze zm.)

7 rozporządzenie ministra sprawiedliwości z dnia 6 listopada 2014 r. w sprawie środków technicznych służących do utrwalania dźwięku albo obrazu i dźwięku w postępowaniu w sprawach o wykroczenia (Dz. U. z 2014 r., poz. 1549)

8 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. z 2014 r., poz. 1548)


9 ustawa z dnia 27 lipca 2001 r. – Prawo o ustroju sądów powszechnych (t.j. Dz. U. z 2015 r., poz. 133) oraz akty wykonawcze do niej.

10 rozporządzenie Ministra Sprawiedliwości z 25 czerwca 2015 r. - Regulamin urzędowania sądów powszechnych (Dz.U. z 2015 r., poz. 925)

11 rozporządzenie Ministra Sprawiedliwości z dnia 5 marca 2004 r. w sprawie przechowywania akt spraw sądowych oraz ich przekazywania do archiwów państwowych lub do zniszczenia (t.j. Dz. U. z 2014 r., poz. 991);

12 ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (t.j. Dz. U. z 2014 r., poz. 1114);

13 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. z 2012 roku, poz. 526),

14 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. Nr 217, poz. 1836),

15 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.Nr 205, poz. 1692).

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

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

18 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. Nr 206 poz. 1517);

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

20 rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 2 listopada 2006 r. w sprawie wymagań technicznych formatów zapisu i informatycznych nośników danych, na których utrwalono materiały archiwalne przekazywane do archiwów państwowych (Dz. U. Nr 206 poz. 1518);

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


22 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 Nr 5, poz. 22 z późn. zm.);

23 zarządzenie Ministra Sprawiedliwości z dnia 30 grudnia 1985 r. w sprawie archiwów zakładowych w jednostkach organizacyjnych resortu sprawiedliwości (Dz. Urz. MS Nr 8, poz. 55);

24 Ustawa z 12 maja 2011 roku o Krajowej Radzie Sądownictwa (Dz.U. z 2011 roku, Nr 126, poz. 714 z późn. zm.) oraz akty wykonawcze do niej.

25 Ustawa z dnia 18 września 2001 r. o podpisie elektronicznym (Dz. U. z 2013 roku, poz. 262).

26 Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz. U. z 2002 r. Nr 101, poz. 926 z późn. zm.)

27 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. Nr 100, poz. 1024)

28 Ustawa z dnia 27 lipca 2001 r. o ochronie baz danych (Dz. U. Nr 128, poz. 1402 z późn. zm.)

29 Ustawa z 27 sierpnia 2009 r. o finansach publicznych(Dz.U. z 2009 r., Nr 157, poz. 1240 z późn. zm.)

30 Rozporządzenie Ministra Finansów z 5 lipca 2010 r. w sprawie szczególnych zasad rachunkowości oraz planów kont dla budżetu państwa, budżetów jednostek samorządu terytorialnego, jednostek budżetowych, samorządowych zakładów budżetowych, państwowych funduszy celowych oraz państwowych jednostek budżetowych mających siedzibę poza granicami Rzeczypospolitej Polskiej (Dz. U. z 2013 roku, poz. 289).

31 Ustawa z dnia 29 września 1994 r. o rachunkowości (t.j. Dz. U. z 2009 r. Nr 152, poz. 1223 ze zm.).

32 Rozporządzenie Ministra Sprawiedliwości z 19 grudnia 2012 roku w sprawie szczegółowych zasad prowadzenia gospodarki finansowej i działalności inwestycyjnej sądów powszechnych (Dz. U. z 2012 roku, poz. 1476)


3 Założenia i ograniczenia

3.1 ZałożeniaWORM – Zakładamy zastosowanie rozwiązania w oparciu o oprogramowanie i politykę dostępu do danych. W przypadku biblioteki taśmowej istnieje możliwość zastosowania taśm WORM, które jednak uniemożliwiałyby spełnienia wymagania usunięcia paczki i zwolnienia miejsca. W przypadku macierzy również, nie ma możliwości całkowitego ograniczenia możliwości wielokrotnego zapisu czy też usunięcia danych, np. przez uprzywilejowanego użytkownika systemu operacyjnego (np. root), czy też administratora macierzy danych. Zaprojektowane rozwiązanie ograniczać będzie możliwość modyfikacji zapisanej paczki lub jej nieuprawnionego usunięcia.

Shredding – W przypadku biblioteki taśmowej zakładamy wykorzystania mechanizmów systemu zarządzania biblioteką taśmową, która zapisuje informację o rozmieszczeniu danych na taśmach w bazie danych. W przypadku usunięcia wpisu w bazie danych dotyczącego danej paczki, dane z taśm są niemożliwe do odzyskania. W przypadku macierzy dyskowej zakładamy wykorzystanie wbudowanej funkcjonalności systemu plików systemu operacyjnego, który po skasowaniu zasobu praktycznie uniemożliwia odzyskanie go z dysku.

Przechowywania danych w kilku kopiach – Takie rozwiązanie zapewnia wymaganą przez zamawiającego odporność na awarię. System będzie zapisywał każdą z paczek minimum w trzech kopiach. Jednej na macierzy dyskowej, oraz dwóch na bibliotekach taśmowych, każda w innym ośrodku przetwarzania danych.

Wielostopniowa weryfikacja składowanych danych – W przypadku biblioteki taśmowej wykorzystujemy wbudowane mechanizmy systemu zarządzania biblioteką taśmową, które cyklicznie przepisują dane z jednej tasiemki na drugą, podczas tej operacji sprawdzana jest poprawność zapisanych danych i w przypadku problemów z odczytem obiekt odtwarzany jest z jego kopii. W przypadku macierzy dyskowej wykorzystujemy mechanizmy ochrony wbudowane w macierz dyskową. Rozwiązanie ma możliwość takiej konfiguracji by dane na dyskach były składowane w więcej niż jednej kopii (kosztem ilości dostępnej przestrzeni).

Sumaryczna wydajność wszystkich macierzy – macierze udostępnione przez Zamawiającego mogą być wykorzystane przez inne rozwiązania. Zwracamy uwagę, że może to wpłynąć zarówno na wydajność zaproponowanego rozwiązania jak i bezpieczeństwo danych (administracja zasobów dyskowych obu rozwiązań).

Tylko kopia zapasowa w ośrodku zapasowym – obecna architektura rozwiązania zakłada w ośrodku zapasowym jedynie bibliotekę taśmową, na której wykonywane będą kopie zapasowe.

Pojedynczy ośrodek wykonujący wszystkie kluczowe operacje – obecna architektura rozwiązania zakłada, że wszystkie kluczowe operacje wykonywane będą na urządzeniach znajdujących się w jednej lokalizacji.

Operacje offline – Przewidywane są takie procedury serwisowe, które mogą wymagać wyłączenia części funkcjonalności środowiska.

Jedna droga do OZ – Awaria połączenia do ośrodka zapasowego może czasowo ograniczyć spełnienia warunku o przechowywania wszystkich paczek w dwóch ośrodkach.

System umożliwia składanie wniosków o udostępnienie akt archiwalnych z wykorzystaniem platformy ePUAP. Formularz obsługujący wniosek pozwala na wybór z listy sadu i wydziału. Wykaz sadów i wydziałów jest zapisany wewnątrz formularza i nie jest automatycznie aktualizowany. W


przypadku zmiany sądów lub wydziałów należy umieścić nowa listę wewnątrz formularza. Wymaga to znajomości działania platformy ePUAP w zakresie publikacji usług, która pozwoli w prawidłowy sposób opublikować usługę z aktualną listą. Plik formularza jest zapisany w formacie XML, aby umieścić w nim zaktualizowana listę jest wymagana podstawowa wiedza na temat struktury pliku XML. W przypadku edycji należy wzorować się na istniejącym pliku formularza.


4 Ogólna koncepcja systemuW niniejszym rozdziale przedstawiona jest perspektywa biznesowa dla realizacji systemu CAPE. Opisane zostały procesy biznesowe realizowane w CAPE a także poszczególne podsystemy realizowanego systemu. Zamieszczona została również analiza otoczenia systemu.

Głównym celem realizacji systemu jest stworzenie centralnego archiwum służącego do przechowywania i udostępniania protokołów elektronicznych z postępowań sądowych. Dokumenty będą bezpiecznie przechowywane w archiwum zgodnie z okresami przewidzianymi przepisami prawa a następnie trwale usuwane po upływie czasu archiwizowania. Usuwanie dokumentów będzie odbywało się zgodnie z zasadami przekazywania dokumentacji archiwalnej do archiwów państwowych lub brakowania. Wyszukiwanie, przeglądanie i udostępnianie zgromadzonych w archiwum materiałów będzie prowadzone w zakresie dopuszczonym przepisami prawa, na podstawie prowadzonego indeksu danych.

4.1 Procesy biznesowe

W rozdziale zaprezentowano i opisano procesy biznesowe wykorzystujące funkcjonalności CAPE. W ramach przeprowadzonej analizy zidentyfikowano sześć takich procesów. Diagramy dla tych procesów wraz z opisem są przedstawione w poszczególnych podrozdziałach. Dla opisu procesów systemu CAPE zastosowano notację zgodną z BPMN 2.0.

4.1.1 Brakowanie akt sprawyW przypadku brakowania spraw, które podlegały procesowi wycofania i dla których w systemie istnieją wcześniejsze wersje, brakowane będą również te wersje. Nie będą one jednak specyfikowane w ramach protokołu brakowania – w protokole tym będzie wyświetlana wyłącznie jedna (ostatnia) wersja danej sprawy.


Rysunek 5: Proces brakowania akt sprawy BPMN Brakow anie akt sprawy

Wybór spraw

Wybór wydziału

Utworzenie protokołubrakowania

«Pool» System Zarządzania Archiw um«Pool» Portal

Wybórprzewodniczącego i

członków komisji

Akceptacja protokołuprzez członków

komisji

Wydruk protokołubrakowania

Ostatecznezatwierdzenie

protokołu

Brakowanie akt

Name: Brakowanie akt sprawyAuthor: Ewa.MiazgaVersion: 1.0Created: 2015-08-14 08:35:52Updated: 2015-09-29 15:27:13

Przekazanie protokołu do Archiwum Państwowego

Decyzja z Archiwum Państwowego Usunięcie plików z macierzy

i napędów taśmowych. Pozostawienie metadanych w bazie danych.

Weryfikacjaprotokołu

Modyfikacjaprotokołu

uwagi do protokołu

protokół niepoprawny protokół poprawny

brak uwag do protokołu


4.1.2 Przekazanie materiałów archiwalnych do Archiwum Państwowego


Rysunek 6: Proces przekazania danych archiwalnych do Archiwum Państwowego BPMN Przekazanie materiałów do AP

«Pool» System Zarządzania Archiwum«Pool» Portal

Utworzenie spisuzdawczo-odbiorczegoakt przekazywanych

do AP

Wybór wydziału

Wybór spraw

Zatwierdzenie spisu Odebraniezamówienia

Utworzenie paczkido przekazania

Zapis danych namacierzy

Odebraniezamówienia

Potwierdzenieprzekazania akt do

AP

Usunięcie akt

Name: Przekazanie materiałów do APAuthor: Ewa.MiazgaVersion: 1.0Created: 2015-08-24 17:27:13Updated: 2015-09-25 15:04:05

Usunięcie plików z macierzy i napędów taśmowych. Pozostawienie metadanych w bazie danych.

Wydruk spisu

Przekazaniemateriałów do AP

Decyzja z Archiwum Państwowego


4.1.3 Wprowadzanie danych do CAPE i tworzenie spisów zdawczo-odbiorczych

Diagram przedstawia proces biznesowy wprowadzania paczek z danymi do CAPE. System jest zasilany cyklicznie danymi pobieranymi z systemów RCS. Po odebraniu paczki jest ona zapisywana na macierzy, system przeprowadza jej weryfikację pod kątem zgodności podpisu z paczką. Weryfikowane są także sygnatury i statusy spraw. Jeżeli wynik weryfikacji będzie negatywny, tj. podpis pod paczką nie będzie z nią zgodny, lub też dana sygnatura będzie oznaczona w systemie statusem 'Zbrakowana' lub 'Przekazana do AP', paczka będzie odrzucana przez system. Po pozytywnym zweryfikowaniu paczki przez system, paczka będzie rozpakowywana i jej zawartość zapisywana na macierzy.

Rysunek 7: Proces wprowadzania danych do CAPE BPMN Wprowadzanie danych do CAPE

«Pool» Agent«Pool» System Zarządzania Archiwum

Pobranie plików zRCS

Przygotowaniepaczek ze sprawami

Odebranie paczekze sprawami

Weryfikacja

Odrzucenie paczki Rozpakowaniepaczki


Name: Wprowadzanie danych do CAPEAuthor: Ewa.MiazgaVersion: 1.0Created: 2015-09-14 11:58:38Updated: 2015-09-14 15:58:03

negatywna pozytywna


W przypadku pozytywnej weryfikacji zgodności danych w pliku csv z informacją o przekazanych paczkach, system w przypadku istnienia duplikatów danej sprawy (ta sama sygnatura sprawy i ten sam wytwórca akt w różnych wydziałach) będzie wyświetlał listę wydziałów, w których ta sprawa była rozpatrywana. Archiwista będzie decydował, który z wydziałów zawiera najbardziej aktualne dane sprawy i tym samym wskazana kopia dla danego wydziału zostanie zarchiwizowana na skutek zatwierdzenia spisu zdawczo odbiorczego. Pozostałe kopie danej sprawy w momencie zatwierdzania spisu zdawczo będą usuwane z macierzy

Zatwierdzenie spisu uruchomi proces zmiany statusu danych w CAPE na 'Zarchiwizowana'.


Rysunek 8: Tworzenie spisu zdawczo-odbiorczego BPMN Tworzenie spisu zdawczo-odbiorczego

«Pool» System Zarządzania Archiwum«Pool» Portal

Utworzenie spisuzdawczo -

odbiorczego

Wczytanie pliku csv

Wyświetlenie listyspraw ( w tymduplikatów)

Sprawdzeniesygnatur paczek i

wydziałów, w którychbyła rozpatrywana

dana sprawa

Zatwierdzenie spisuzdawczo-odbiorczego

Zmiana statusudanych

Czy wynik weryfikacj i jest poprawny?

Usunięcieniepoprawnychpozycji z l isty

Name: Tworzenie spisu zdawczo-odbiorczegoAuthor: Ewa.MiazgaVersion: 1.0Created: 2015-09-14 10:56:12Updated: 2015-09-25 14:18:09

Czy usunąć cały spis?

Usunięcie spisuzdawczo -

odbiorczego

Czy są dupl ikaty?Wybierz wydział, z

którego sprawapowinna być

zarchiwizowana

Usunięcieduplikatów z

macierzy

Weryfikacja

Pozasystemowa modyfikacja pliku csv

Czy zatwierdzić spis z-o?

NIE

TAKNIE

TAK

NIE

TAK

NIE

TAK

NIE

4.1.4 Wycofanie akt sprawy


Rysunek 9: Proces wycofania akt sprawy BPMN Wycofanie

«Pool» Agent«Pool» System Zarządzania Archiwum«Pool» Portal

Dodanie zgłoszeniana wycofanie akt

sprawy

Wybranie sprawy

Weryfikacjazgłoszenia

Przekazaniezgłoszenia do

archiwum

Odrzuceniezgłoszenia



Zapisanie paczki domacierzy lokalnej

Odebranie paczki zarchiwum

Oznaczenie sprawyjako wycofanej

Aktualizacja stanuzgłoszenia

Weryfikacja

Name: WycofanieAuthor: Ewa.MiazgaVersion: 1.0Created: 2015-08-24 14:47:41Updated: 2015-09-29 15:18:01

Wybranie kanałudostarczenia

odrzucone

pozytywna

przyjęte

negatywna

4.1.5 Wyszukiwanie i przeglądanie spraw


Rysunek 10: Proces wyszukiwania i przeglądania sprawyBPMN Wyszukiwanie i przeglądanie

«Pool» Portal

Name: Wyszukiwanie i przeglądanieAuthor: adebeckaVersion: 1.0Created: 2015-08-14 13:41:36Updated: 2015-08-14 20:42:54

Wprowadzeniekryteriów

wyszukiwania

Wyszukanie danych

Przeglądaniedanych

4.1.6 Zamawianie dokumentów


Rysunek 11: Proces zamawiania akt sprawy BPMN Zamawianie

«Pool» System Zarządzania Archiw

um«Pool» Portal

«Pool» Użytkownik ePUAP

Name: ZamawianieAuthor: adebeckaVersion: 1.0Created: 2015-08-14 14:45:52Updated: 2015-09-29 14:42:18

Wybranie spraw

Wybraniedokumentów wramach sprawy

WeryfikacjaZamównienia

poprawne

Złożeniezamówienia przez

ePUAP

poprawne

Wysłanie informacjio odrzuceniuzamówienia

Przekazaniezamówienia do

archiwum


Odebraniezamównienia



Wysłaniezamówienia


zamówienie zsystemu zewnętrznego

Wysłanie informacji

Wysłanie informacji

zamówienie z ePUAP

Utworzeniezamówienia Wybranie kanału

dostarczenia

TAK

NIE

TAK

NIE

NIE

TAK

NIE

TAK

4.2 Opis systemu i podsystemów

Centralne Archiwum Protokołów Elektronicznych to system, którego głównym celem jest przechowywanie i udostępnianie akt spraw sądowych. System zbudowany jest z kilku komponentów:

1 Podsystem Przechowywania Danych (PPD) - odpowiedzialny za bezpieczne przechowywanie danych,

2 System Zarządzania Archiwum (SZA) – zapewnia narzędzia i mechanizmy do monitoringu i zarządzania urządzeniami

3 Portal – zapewnia dostęp do Centralnego Archiwum Protokołów Elektronicznych

4 Podsystem PKI – zapewnia bezpieczne podpisywanie dokumentów przekazywanych do Podsystemu Przechowywania Danych (PPD)

4.3 Analiza otoczenia systemuJednym z elementów i efektów prac związanych z realizacją systemu CAPE jest jego współpraca z systemami zewnętrznymi. Realizowany w ramach CAPE komponent Agenta będzie instalowany lokalnie w infrastrukturze poszczególnych sądów i będzie wykorzystywał dane przechowywane w lokalnych systemach sądowych. Systemy te oraz zakres ich współpracy z CAPE na poziomie biznesowym zostały opisane w kolejnych podrozdziałach. Dodatkowo, CAPE będzie zintegrowane z centralnym Active Directory Ministerstwa Sprawiedliwości.

Wydajność macierzy – W udostępnionej macierzy zainstalowane są dyski NLSAS o charakterystyce 7200 rpm. Zwracamy uwagę, że wydajność macierzy w przypadku zmniejszenia ilość udostępnionych macierzy (z 5 do 3), oraz współdzielenia macierzy z innym rozwiązaniem (o nieznanej charakterystyce utylizacji IOPS) może być zmniejszona.


Zapasowa droga dla połączenia pomiędzy ośrodkami przetwarzania danych – Brak zapasowej drogi połączenia pomiędzy ośrodkami przetwarzania danych spowoduje przerwę w zapisie danych na zapasowej bibliotece taśmowej w przypadku przerwania drogi podstawowej. Rozwiązanie skonfigurowane będzie w taki sposób aby po odzyskaniu połączenia pomiędzy ośrodkami zachować spójność danych i zastosować politykę retencji, a więc przetrzymywanie minimum trzech kopii danych, w tym po jednej na każdej bibliotece taśmowej (w lokalizacji podstawowej i zapasowej). Obie biblioteki taśmowe skonfigurowane będą z pomocą „copy pool”, dzięki czemu zapis kopii danych na bibliotekę taśmową spowoduje synchroniczny zapis na jedną, a następnie drugą bibliotekę taśmową. System TSM będzie monitorować ilość kopii na obu bibliotekach i w razie potrzeby wykona zapis brakującej kopii.

4.3.1 Active Directory Ministerstwa SprawiedliwościActive Directory jest usługą katalogową (hierarchiczną bazą danych), pozwalającą na zarządzanie kontami użytkowników i relacjami między użytkownikami, urządzeniami sieciowymi, informacjami itd. w sieci organizacji. W ten sposób usługa zapewnia kontrolę nad całą siecią i poprawia jej bezpieczeństwo. Usługi Active Directory (AD) poszczególnych sądów są oparte o usługę Active Directory Ministerstwa Sprawiedliwości, co oznacza, że każdy sąd może administrować swoją częścią AD. Każdy typ sądu posiada swoje własne OU (Organization Unit – jednostka organizacyjna), a poszczególne sądy posiadają swoje OU w ramach OU dla danego typu sądu. Integracja systemu CAPE z Active Directory będzie polegać na pobieraniu ustalonych danych o użytkownikach i przetwarzaniu ich w CAPE. Pobierane i wykorzystywane będą następujące dane:

nazwa użytkownika, imię użytkownika, nazwisko użytkownika, email użytkownika, jednostka organizacyjna, stanowisko.

Na podstawie tych danych Administrator CAPE będzie zakładał konta użytkowników systemu CAPE w Podsystemie Uwierzytelniania i Autoryzacji. Ponadto, system CAPE będzie zintegrowany z Active Directory Ministerstwa Sprawiedliwości w zakresie uwierzytelniania użytkowników.

4.3.2 Systemy repertoryjno-biurowe sądówSystemy repertoryjno-biurowe funkcjonujące w sądach są aplikacjami służącymi m.in. do ewidencjonowania i obsługi postępowań toczących się w sądach. Do przykładowych rozwiązań należą systemy: SAWA, Praetor czy też Sędzia 2. Mimo, że oprogramowanie repertoryjno-biurowe stosowane w sądach nie jest jednolite, to wszystkie rozwiązania są oparte o relacyjne bądź dokumentowe bazy danych (np. MS SQL). W bazach systemów repertoryjnych są zapisywane m.in. metadane przechowywanej dokumentacji elektronicznej spraw sądowych. W systemach repertoryjnych będą generowane spisy zdawczo-odbiorcze, na podstawie których będą z kolei tworzone spisy w CAPE. Powiązanie informacji z systemów repertoryjnych z zapisami pobranymi z systemu ReCourt będzie następować poprzez sygnatury spraw oraz dane sądu i wydziału.

4.3.3 System ReCourtSystem ReCourt jest oprogramowaniem wspomagającym tworzenie i zarządzanie protokołem elektronicznym. System umożliwia prowadzenie oraz kontrolę przebiegu procesu rejestracji przez protokolanta i sędziego jak również zarządza przechowywaniem i udostępnianiem nagrań. Oprogramowanie ReCourt składa się z dwóch głównych komponentów:

1. aplikacji lokalnej do obsługi protokołu elektronicznego na salach rozpraw,2. aplikacji centralnej do zarządzania przechowywaniem i udostępnianiem nagrań.


Pliki nagrań wraz z opisującymi je metadanymi tworzonymi przez system ReCourt przechowywane są w systemie plików a ich struktura nie jest zależna od statusu sprawy.

Na podstawie danych otrzymanych z systemów repertoryjnych, System CAPE będzie pobierał z systemu ReCourt pliki nagrań. Pliki te będą wchodziły w skład budowanych przez Agenta CAPE paczek archiwalnych.


5 Specyfikacja i opis wymagańNiniejszy rozdział zawiera zbiór wszystkich wymagań, zarówno funkcjonalnych jak i pozafunkcjonalnych, jakie powinien spełniać system CAPE. Zawarte w nim wymagania zostały zdefiniowane na podstawie OPZ. Powstałe w ten sposób zestawienie stanowiło punkt wyjścia do analizy Systemu. Kolejnym krokiem w trakcie analizy było uszczegółowienie tych wymagań, które potrzebowały doprecyzowania oraz przyporządkowanie poszczególnych wymagań do realizacji w danym podsystemie CAPE.

5.1 Wymagania funkcjonalne

W podrozdziale przedstawione są wymagania funkcjonalne w podziale na poszczególne podsystemy zgodnie ze standardem opisanym poniżej.

Nazwa każdego wymagania składa się z identyfikatora i treści tego wymagania. Identyfikator wymagania funkcjonalnego zawiera stały przedrostek WF, przedrostek podsystemu do którego należy (A – Agent, P – Portal, PPD – Podsystem Przechowywania Danych, PUiA – Podsystem Uwierzytelniania i Autoryzacji, SZA – System Zarządzania Archiwum) oraz unikalny numer wymagania. Poza identyfikatorem i nazwą opisową, wymagania funkcjonalne opisywane są również poprzez elementy.

Poza identyfikatorem i nazwą opisową, wymagania funkcjonalne opisywane są również poprzez elementy:

Pełna treść wymagania – element opcjonalny, wykorzystywany w przypadku gdy treść wymagania jest zbyt obszerna by była wprowadzona jako nazwa wymagania;

Opis realizacji wymagania – poszerzony opis realizacji danego wymagania;

5.1.1 Agent

WF.A.001 Agent musi mieć możliwość przesyłania informacji o swojej aktywności lokalnemuadministratorowi za pośrednictwem poczty elektronicznej [pkt 2, str. 29]

Agent musi mieć możliwość przesyłania informacji o swojej aktywności (w szczególności informowania o problemach z dostarczeniem paczki archiwalnej, statusie zamówionych paczek, błędach przetwarzania, niedostępności wymaganych zasobów dyskowych itp.) lokalnemu administratorowi za pośrednictwem poczty elektronicznej.

Opis realizacji wymagania:

Informacje o aktywności RCS Agent Server będą zarówno zapisywane do logów jak i wysyłane za pośrednictwem poczty elektronicznej do lokalnego administratora. Będzie to realizowane przy użyciu mechanizmów serwera CRCS/Web manager.

WF.A.002 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. [pkt 3, str. 29]

RCS Agent Server posiada własny system logowania, w którym zapisywane będą informacje dotyczące wszystkich realizowanych czynności oraz wykrytych błędów.


W przypadku błędów krytycznych istnieje możliwość informowania o nich CRCS, który będzie prezentował zestawienia (powiadomienia).

WF.A.003 Agent w zakresie przesyłania paczek do archiwum musi zapewnić monitorowanie zawartości lokalnego archiwum

[pkt 1, str. 29]

Raz dziennie RCS Agent Server o zadanej godzinie będzie pobierał listę spraw z systemu RCS. Do archiwum przesyłana będzie każda sprawa, która:

Nie była jeszcze wcześniej przesyłana do archiwum lub przesłanie zakończyło się błędem.

Upłynął parametryzowany czas karencji, licząc od daty zakończenia sprawy.

Została zmodyfikowana od czasu ostatniego przesłania jej do archiwum. Przykładem może być sytuacja, gdy zarejestrowano nagrania z kolejnej rozprawy – w takim przypadku paczka dla danej sprawy będzie zawierać nagrania ze wszystkich rozpraw, które odbyły się w danej sprawie, w tym również te nagrania, które były już wcześniej wysyłane do archiwum.

Standardowo mechanizm pierwszego zasilenia danymi systemu będzie przebiegał poprzez RCS Agent Server, który zbiorczo skopiuje paczki na dysk przenośny. Następnie dysk zostanie fizycznie wpięty bezpośrednio do infrastruktury centralnej CAPE, aby dane mogły zostać odczytane. W pierwszym zasileniu danymi musi uczestniczyć RCS Agent Server, który będzie przechowywał kopie danych oraz informacje, jaka sprawa z jakim zakresem danych została zarchiwizowana. W przypadku, gdyby w momencie uruchomienia archiwizacji spraw w którymś sądzie ilość nagrań z rozpraw była jeszcze niewielka, możliwe jest pierwsze zasilenie danymi archiwum CAPE poprzez sieć, a więc poprzez standardową sesję pracy RCS Agent Server.

WF.A.004 Agent w zakresie przesyłania paczek do archiwum musi zapewnić przygotowywanie paczek archiwalnych [pkt 2, str. 29]

W pojedynczej paczce będą się znajdowały dane dotyczące jednej sprawy. Paczka archiwalna będzie zbudowana z danych sprawy pobranych z systemu RCS oraz plików nagrań rozpraw sądowych pobranych z systemu RCS.

Metadane z opisem sprawy i plików danych będą wypełniane przez agenta danymi znajdującymi się w RCS. Uzupełnienie ich danymi, których nie ma w RCS, będzie się odbywało w SZA.

WF.A.005 Agent w zakresie przesyłania paczek do archiwum musi zapewnić utrzymywanie niezależnej od lokalnego systemu

plików informacji o zasobach zarchiwizowanych [pkt 3, str. 29]

RCS Agent Server będzie zapisywać stan importu w swojej bazie (SQL Server), z którą porównuje sprawy, które należy wysłać.


RCS Agent Server będzie posiadał kopię danych spraw wysłanych przez niego do archiwum. Konieczne to jest, aby możliwe było porównanie, czy jakieś dane się nie zmieniły i paczka dla danej sprawy nie powinna zostać ponownie wysłana. Kopia danych będzie realizowana poprzez przechowywanie kopii danych spraw i sum kontrolnych plików nagrania lub alternatywnie poprzez przechowywanie sum kontrolnych dla wszystkich danych sprawy.

WF.A.006 Agent musi zapewnić przesyłanie paczek archiwalnych do archiwum centralnego [pkt 4, str. 29]

Wysłanie paczki do archiwum centralnego następuje przy użyciu protokołu SCP. Paczka z danymi sprawy oraz z plikami protokołu elektronicznego jest wysyłana na zasób centralny. Do paczki dołączany jest plik zawierający sumę kontrolną paczki, aby możliwe było sprawdzenie jej integralności. Paczki będą przesyłane w postaci plików zip z odpowiednią nazwą. Podczas kopiowania będzie miała dodatkowy dopisek .part aby rozróżnić paczki gotowe do procesowania dalszego. SZA będzie przeglądał katalog i procesował paczki, których przesyłanie się zakończyło.

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

centralnego [pkt 1, str. 29]

W celu weryfikacji pojemności zasobów lokalnych potrzebnych dla odtworzenia paczek z archiwum centralnego zostanie wprowadzony mechanizm monitorowania, czy ilość wolnej pamięci w tym zasobie nie spadła poniżej wartości progowej.

Wartość progowa będzie parametrem systemu.

Gdy ilość wolnej pamięci spadnie poniżej wartości progowej, wówczas poza zapisem tej informacji w logach będzie wysyłany monit do lokalnego administratora za pośrednictwem poczty elektronicznej.

WF.A.008 Agent w zakresie odbierania paczek z archiwum musi umożliwić kopiowanie odtworzonych w archiwum

centralnym paczek do dedykowanej przestrzeni na macierzy lokalnej [pkt 2, str. 29]

Proces pobrania sprawy z archiwum CAPE będzie się kończył umieszczeniem paczki archiwalnej w dedykowanej przestrzeni na macierzy lokalnej. Jednocześnie zostanie wysłane powiadomienie do archiwisty/administratora z informacją, że paczka archiwalna została odebrana.

Udostępnienie tej paczki w kolejnym kroku procesu leży poza systemem. Uprawniony pracownik będzie mógł ją przykładowo udostępnić w przestrzeni dyskowej lub zgrać na dowolny nośnik pamięci (dysk twardy, optyczny itp.).

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


[pkt 3, str. 29]

Weryfikacja poprawności odtworzenia paczek archiwalnych będzie polegała na sprawdzeniu przez RCS Agent Server sumy kontrolnej paczki wygenerowanej na czas przesyłania paczki z archiwum CAPE do zasobu SCP Storage.

WF.A.010 Agent musi zapewnić komunikację z systemem centralnym w celu potwierdzenia poprawności odtworzenia paczek

archiwalnych [pkt 4, str. 29]

Komunikacja RCS Agent Server z systemem centralnym w celu potwierdzenia poprawności odtworzenia paczek archiwalnych będzie oparta o zasób SCP Storage. Weryfikacja poprawności paczki archiwalnej będzie się sprowadzać do sprawdzenia zgodności sumy kontrolnej dołączonej do paczki. Wynik weryfikacji poprawności paczki archiwalnej RCS Agent Server umieści w odpowiednim folderze zasobu SCP Storage. Będzie to sygnałem dla systemu centralnego, czy odtworzenie paczki się powiodło. W razie niepowodzenia system centralny będzie musiał ponowić wysłanie paczki do zasobu SCP Storage.

WF.A.011 Agent musi zapewnić poufność, integralność i niezaprzeczalność transmisji w zakresie przekazywania i odbierania

paczek do/z archiwum [pkt 5, str. 29]

Paczka z danymi sprawy oraz z plikami protokołu elektronicznego wysyłana jest na centralny zasób SCP wraz z załączonym plikiem z sumą kontrolną, która umożliwia weryfikację integralności paczki.

W celu zapewnienia poufności przekazywanie i odbieranie paczek do/z archiwum CAPE odbywa się przy użyciu protokołu SCP zapewniającego bezpieczny transfer plików (używając protokołu Secure Shell - SSH).

Przebieg wysłania paczki (*.zip) jest realizowany poprzez kopiowanie pliku na serwer ze zmienioną nazwą (która mówi o trwającej transmisji) na *.part, która jest zamieniana na poprawną dopiero w momencie poprawnego wysłania pliku na zasób. W celu zapewnienia integralności transmisji mechanizm odczytu paczki w trakcie przekazywania i odbierania paczek do/z archiwum nie bierze pod uwagę paczek częściowo przekopiowanych.

Po przetworzeniu paczki przekazanej przez RCS Agent Server SZA przekazuje RCS Agent Server za pośrednictwem zasobu SCP Storage rezultat przetworzenia paczki.

Po odebraniu przez RCS Agent Server paczki z archiwum CAPE RCS Agent Server przekazuje SZA za pośrednictwem zasobu SCP Storage rezultat weryfikacji paczki.

5.1.2 PortalWF.P.001 Portal musi udostępniać historię wykonywanych operacji [pkt 1, str. 32]

Portal musi udostępniać funkcje: historię wykonywanych operacji – lista wszystkich wykonanych


przez użytkownika operacji. Dla uprzywilejowanych użytkowników możliwość przeglądania historii operacji wykonanych również przez innych użytkowników.


W systemie będzie zapewniony rejestr zdarzeń.

WF.P.002 Portal musi udostępniać wyszukawarkę paczek archiwalnych [pkt 2, str. 32]

Portal musi udostępniać wyszukiwarkę paczek archiwalnych – funkcja musi generować listę paczek archiwalnych przechowywanych w archiwum centralnym spełniających zadane przez użytkownika kryteria wyszukiwania z jednoczesnym uwzględnieniem ograniczeń wynikających z posiadanych przez użytkownika uprawnień ( np. tylko sprawy z danego wydziału, rejonu, okręgu, apelacji). Możliwości wyszukiwania pełno tekstowego z wykorzystaniem wyrażeń regularnych po dowolnej kombinacji pól opisujących paczki archiwalne. Użytkownicy powinni mieć możliwość zapisywania zdefiniowanych zapytań w celu ponownego ich wykorzystania.


System będzie udostępniał wyszukiwarkę pełnotekstową oraz wyszukiwarkę zaawansowaną. Dodatkowo będzie istniała możliwość zapisywania własnych zdefiniowanych zapytań.

WF.P.003 Portal musi udostępniać funkcję zmiany kategorii archiwalnej oraz deklarowanego okresu archiwizacji sprawy [pkt 3, str. 32]

System będzie umożliwiał zmianę kategorii archiwalnej przez uprawnionego użytkownika. Zmiana kategorii będzie możliwa z poziomu sprawy oraz protokołu brakowania. Dla każdej zmiany kategorii archiwalnej będzie rejestrowana informacja o jej przyczynie.

WF.P.004 Portal musi udostępniać funkcję żądania odtworzenia paczki/paczek archiwlanych [pkt 4, str. 32]

Portal musi udostępniać funkcję żądania odtworzenia paczki / paczek archiwalnych – funkcja musi pozwalać na złożenie żądania odtworzenia wybranych paczek z archiwum centralnego, użytkownik musi być informowany o wielkości wolumenu danych, przewidywanym czasie odtworzenia. System musi zapewnić możliwość wyboru sposobu dostarczenia danych (WAN inne nośniki). Użytkownik musi móc śledzić etapy realizacji zamówienia.


System będzie zapewniał mechanizm składania zamówienia na odtworzenie paczki/paczek z archiwum centralnego. W ramach zamówienia definiowany będzie sposób dostarczenia danych. Śledzenie etapów realizacji zamówienia będzie odbywało się poprzez mechanizm automatycznego nadawania statusów dla każdego z etapów.

WF.P.005 Oznaczenie brakowania akt sprawy [str. 32]

Oznaczenie brakowania akt sprawy – co oznacza możliwość oznaczenia akt sprawy jako zniszczonych. Skutkiem ustawienia takiej flagi musi być trwałe usunięcie wszystkich powiązanych z daną sprawą,


przechowywanych w CAPE zapisów.


Zatwierdzenie do brakowania spraw będzie uruchamiało funkcję usuwania wszystkich powiązanych z danymi sprawami plików z macierzy i napędów taśmowych. Metadane tych spraw będą przechowywane w bazie danych.

WF.P.006 Proces brakowania dokumentów musi być w pełni audytowany, autoryzowany i spójny z procesem brakowania akt

realizowanym w poszczególnych sądach. [str. 33]

W celu uniknięcia przypadkowego usunięcia danych z CAPE proces brakowania dokumentów musi być w pełni audytowany, autoryzowany i spójny z procesem brakowania akt realizowanym w poszczególnych sądach. System musi wspierać proces który może być realizowany w następujących krokach: (szczegółowe opisy w wymaganiach podrzędnych)

WF.P.006.01 Brakowanie akt musi być zdarzeniem rejestrowanym w systemie archiwum centralnego. Np. archiwista rejestruje

fakt przeprowadzenia procesu brakowania akt w sadzie. [pkt 1, str. 33]

Portal będzie udostępniał możliwość tworzenia protokołów brakowania, w których definiowana będzie lista spraw do brakowania z możliwością wyłączenia spraw reprezentacyjnych. Ostateczne zatwierdzenie protokołu będzie skutkowało uruchomieniem procesu brakowania akt (usunięcie plików z macierzy i napędów taśmowych, metadane brakowanych spraw pozostaną w module SZA). Dodatkowo zdarzenie brakowania będzie odpisane w rejestrze zdarzeń

WF.P.006.02 Opis zdarzenia musi obejmować w szczególności dane wszystkich członków komisji ds. brakowania akt

powołanej przez prezesa sądu. Te dane mogą być wprowadzone przez np. archiwistę ale powinny być autoryzowane przez

prezesa sądu. [pkt 2, str. 33]

Dodanie członków komisji ds. brakowania dla wybranego protokołu brakowania będzie wymagało potwierdzenia przez uprawnionego użytkownika. Potwierdzenie składu komisji ds. brakowania będzie warunkiem dalszego procedowania protokołu brakowania.

WF.P.006.03 Każdy członek komisji musi mieć nadane uprawnienia w systemie centralnym do potwierdzenia brakowania akt

[pkt 3, str. 33]

Każdy członek komisji musi mieć nadane uprawnienia w systemie centralnym do potwierdzenia brakowania akt (uprawnienia w tym zakresie powinny być nadawane w kontekście jednego konkretnego zdarzenia brakowania, nie powinny pozwalać na wielokrotne autoryzowanie faktów brakowania)


Uprawnienia dla członków komisji ds. brakowania będą nadawane ad hoc w momencie przypisania danego członka do danego protokołu brakowania.


WF.P.006.04 System musi pozwalać na wyszukanie spraw, których okres archiwizacji skończył się – z możliwością zawężenia

wyszukiwania do spraw, których okres archiwizacji zakończył się np. dwa lata temu, rok temu. [pkt 4, str. 33]

System zapewni mechanizm wyszukiwania spraw o przekroczonym czasie retencji. Będzie istniała możliwość zawężenia wyników wyszukiwania do spraw, których okres archiwizacji zakończył się np. dwa lata temu, rok temu.

WF.P.006.05 Oznaczenie wybranych spraw (możliwość ręcznego zaznaczenia niektórych spraw) jako przeznaczonych do

brakowania. System nie może umożliwiać oznaczenia jako sprawy przeznaczonej do brakowania sprawy, której okres

archiwizacji jeszcze trwa. [pkt 5, str. 33]

W ramach tworzonego protokołu brakowania dostępne będą tylko sprawy z przekroczonym czasem retencji.

WF.P.006.06 Możliwość wydruku spisu spraw przeznaczonego do brakowania – dokument musi być dołączony do

dokumentacji komisji ds. brakowania dokumentów powołanej przez prezesa sądu. [pkt 6, str. 33]

W systemie będzie istniała możliwość wydruku protokołu brakowania

WF.P.006.07 Potwierdzenie (w systemie) decyzji o brakowaniu przez wszystkich członków komisji. [pkt 7, str. 33]

Po skompletowaniu protokołu brakowania członkowie komisji będą w systemie indywidualnie akceptować dany protokół. Akceptacja protokołu przez wszystkich członków będzie warunkiem akceptacji całego protokołu.

WF.P.006.08 Z chwilą potwierdzenia brakowania akt przez wszystkich członków komisji system musi uniemożliwić pobieranie

paczek archiwalnych dotyczących brakowanych spraw a następnie rozpocząć proces ich trwałego niszczenia. [pkt 8, str. 33]

W systemie sprawy, które uzyskają akceptację członków komisji ds. brakowania do usunięcia, będą wyłączone z listy spraw, na które można złożyć zamówienie na odtworzenie/wycofanie.

5.1.3 Podsystem Uwierzytelniania i AutoryzacjiWF.PUiA.001 Podsystem musi umożliwiać kontrolę dostępu do systemu wyłącznie po jednoznacznym zidentyfikowaniu

przeprowadzonym w ramach procesu uwierzytelnienia [pkt 5.1, str. 30]

Użytkownicy chcący zdobyć dostęp do systemu będą musieli się uwierzytelnić podając na stronie login (identyfikacja) i hasło (uwierzytelnienie). W systemie będą 2 typy kont:

- konta pobrane z AD (dla użytkowników, którzy mają konta w AD), inaczej konta domenowe - w takim przypadku CAPE będzie przekazywać wpisane przez użytkownika na stronie logowania login i hasło do AD gdzie są one weryfikowane. Po pozytywnej weryfikacji użytkownik jest uwierzytelniony w CAPE.


Hasła są przechowywane w AD (AD decyduje również o polityce haseł).

- konta lokalne (dla użytkowników nieposiadających kont w AD), konto rejestrowane jest w CAPE. Hasło przechowywane jest w CAPE i podlega polityce haseł zarządzanej przez CAPE.

Oba typy kont tworzone są przez administratora (użytkownika o odpowiednich uprawnieniach).

Mechanizmy uwierzytelniania i autoryzacji zaimplementowane w systemie będą oparte na protokole CAS. System zapewni mechanizmy pojedynczego zalogowania się (SSO) do wszystkich elementów Systemu.

WF.PUiA.002 Podsystem musi umożliwiać przechowywanie i przesyłanie haseł użytkowników wyłącznie w postaci

zabezpieczonej [pkt 5.2, str. 30]

Hasła użytkowników lokalnych CAPE będą przechowywane w systemie w sposób uniemożliwiający ich odczytanie (hasła nie będą w postaci jawnej, będą zakodowane). W przypadku kont użytkowników domenowych, system nie będzie przechowywał haseł. Będą one przechowywane w Active Directory, z którym system będzie zintegrowany. Hasła będą przekazywane w bezpiecznym kanale SSL/TLS.

WF.PUiA.003 Podsystem musi umożliwiać 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. [pkt 5.3, str. 31]

Podsystem musi umożliwiać 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.


W systemie zostanie zaimplementowany system uprawnień oparty na uprawnieniach grupowanych w role. Zarządzanie uprawnieniami będzie odbywać się poprzez role z możliwością ich łączenia z użytkownikami lub grupami użytkowników. Po założeniu konta użytkownikowi będzie nadawana automatycznie rola domyślna, dająca mu uprawnienia do podstawowych funkcjonalności systemu. Dalsze rozszerzanie uprawnień będzie się odbywało na skutek przyznania kolejnych ról przez administratora systemu lub zmiany uprawnień przypisanych do roli użytkownika. Dostęp do danych systemu będzie realizowany na dwóch poziomach:

- dostęp wynikający z przydzielonych ról systemowych, określających działania jakie może wykonać w Systemie użytkownik przypisany do danej roli,

- dostęp wynikający z metadanych dokumentu określających miejsce wytworzenia dokumentu.

WF.PUiA.004 Podsystem musi umożliwiać uwierzytelnianie i autoryzację użytkowników na podstawie informacji

przechowywanej w Active Directory [pkt 5.4, str. 31]

W systemie będą 2 typy kont:

- konta pobrane z AD (dla użytkowników, którzy mają konta w AD), inaczej konta domenowe - w takim przypadku CAPE będzie przekazywać wpisane przez użytkownika na stronie logowania login i hasło do


AD gdzie będą one weryfikowane. Po pozytywnej weryfikacji użytkownik będzie uwierzytelniany w CAPE. Hasła kont domenowych są przechowywane w AD (AD decyduje również o polityce haseł).

- konta lokalne (dla użytkowników nieposiadających kont w AD), czyli konta rejestrowane w CAPE. Hasła kont lokalnych przechowywane są w CAPE i podlegają polityce haseł zarządzanej przez CAPE.

WF.PUiA.005 Podsystem musi umożliwiać uwierzytelnianie użytkowników za pomocą unikatowego identyfikatora

użytkownika i niejawnego hasła [pkt 5.5, str. 31]

Każdy użytkownik systemu będzie posiadał unikatowy identyfikator (login). Użytkownik chcący zdobyć dostęp do zasobów systemu będzie musiał uwierzytelnić się poprzez podanie na stronie logowania swojego loginu i hasła. Hasła kont lokalnych będą przechowywane w systemie w postaci zaszyfrowanej. Hasła kont domenowych będą przechowywane w Active Directory, z którym system będzie zintegrowany.

WF.PUiA.006 Podsystem musi umożliwiać dostęp do logów zdarzeń systemowych z poziomu interfejsu administracyjnego

oraz zapewniać możliwość ich eksportu do formatu TXT [pkt 5.6, str. 31]

Logi zdarzeń systemowych będą zapisywane do plików TXT. Pliki te będą podpisywane i przetrzymywane na dysku.

WF.PUiA.007 Podsystem musi umożliwiać rozliczalność działań użytkowników i administratorów [pkt 5.7, str. 31]

Rozliczalność działań użytkowników i administratorów będzie zapewniona poprzez wprowadzenie systemu rejestru zdarzeń na bazie danych. W rejestrze będą odnotowywane informacje dotyczące operacji systemu, w tym identyfikator użytkownika wykonującego daną operację.

WF.PUiA.008 Podsystem musi umożliwiać zapewnienie wiarygodność i bezpieczeństwo logów [pkt 5.8, str. 31]

Wiarygodność i bezpieczeństwo logów zdarzeń systemowych będzie zapewniona poprzez podpisywanie plików TXT, do których te logi będą zapisywane.

WF.PUiA.009 Podsystem musi umożliwiać odnotowanie daty wykonania każdej operacji oraz identyfikatora użytkownika

wykonującego operację [pkt 5.9, str. 31]

Każda operacja systemu będzie odnotowywana w ramach wdrożonych mechanizmów zdarzeń aplikacji. Dla każdego zdarzenia będą odnotowane takie informacje jak data jego wykonania, identyfikator użytkownika lub programu/procesu wykonującego operację, kwalifikacja zdarzenia.

WF.PUiA.010 Podsystem musi uniemożliwiać edycję i usuwanie plików zawierających logi zdarzeń systemowych oraz


Pliki zawierające logi zdarzeń systemowych będą podpisywane, co uniemożliwi ich edycję. Dostęp do przestrzeni, w której będą przechowywane pliki będzie ograniczony. Logi będą zapisywane w trybie cyklicznym. Zajętość serwera, na którym będą przechowywane pliki logów będzie monitorowana. W Rozwiązaniu CAPE zastosujemy centralny system logów systemowych. Oznacza to, że każdy element rozwiązania, który będzie logował swoją pracę (serwer www, serwera aplikacyjny, baza danych itd) będzie wysyłał logi systemowe poza serwer, na którym jest zainstalowany. W przypadku problemów z danym elementem rozwiązania logi będą znajdować się na innej maszynie. Dostęp do tej maszyny również będzie ograniczony tylko dla administratora odpowiedzialnego za system logów. W ramach centralnego systemu logów wykorzystany będzie zestaw narzędzi: syslog (system obsługi logów), Logstash (zbieranie, parsowanie logów), elasticsearch (baza dokuemntowa, wyszukiwanie), Kibana (prezentacja GUI). W przypadku monitoringu zastosowane będzie sprawdzone rozwiązanie Nagios, które pozwoli na monitorowanie zajętości przestrzeni dysków, wykorzystania procesorów, pamięci itp.

WF.PUiA.011 Podsystem musi umożliwiać synchronizację zegara systemowego ze źródłami czasu za pomocą protokołu NTP

lub mechanizmów Active Directory [pkt 5.11, str. 31]

W ramach systemu operacyjnego każdego z elementów rozwiązania wykorzystane zostaną wbudowane mechanizmy synchornizacji zegara systemowego w oparciu o Centralne AD udostępnione przez Zamawiającego.

WF.PUiA.012 Podsystem musi umożliwiać korzystanie z protokołu SSL dla zabezpieczenia przesyłanych informacji lub w

inny sposób zapewniać szyfrowanie przesyłania danych [pkt 5.12, str. 31]

Komunikacja użytkownika z Systemem będzie odbywać się za pomocą połączenia szyfrowanego w kanale SSL/TLS. Komunikacja wychodząca poza wewnętrzną sieć lokalną odbywa się z pomocą protokołów szyfrowanych, zarówno dotyczy to komunikacji przeglądarka-portal jak i komunikacja agentów z CAPE. Wykorzystanie zostany protokół SSL/TLS (HTTPS, SCP).

WF.PUiA.013 Podsystem musi umożliwiać zdefiniowanie reguł określających wymaganą siłę stosowanych haseł dla różnych

grup użytkowników [pkt 5.13, str. 31]

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

1. minimalnej dopuszczalnej długości hasła,

2. stosowania znaków alfanumerycznych i specjalnych,

3. maksymalnej długości okresu ważności hasła,

4. liczby haseł zapamiętywanych w historii haseł (blokowanie możliwości ich ponownego użycia),

5. system musi obsługiwać hasła jednorazowe.


W systemie będzie udostępniona strona do zarządzania polityką haseł dla kont lokalnych, na której administrator będzie miał możliwość określenia minimalnej liczby znaków dla hasła, maksymalnej długości okresu ważności hasła, czy też liczby haseł do zapamiętania w historii haseł. Administrator


będzie także miał możliwość wskazania czy hasło wymaga stosowania znaków specjalnych. Dodatkowo, dla kont lokalnych zostanie w systemie udostępniona funkcja resetu hasła, w ramach której generowane będą hasła jednorazowe, przesyłane na adres e-mail skojarzony z kontem użytkownika wykonującego operację resetu. Polityki haseł dla kont domenowych będą definiowane i zarządzane w poziomu Active Directory, z którym system będzie zintegrowany.

WF.PUiA.014 Podsystem musi umożliwiać 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) [pkt 5.14, str. 31]

Zdarzenia nieudanych logowań będą odnotowywane w ramach mechanizmów rejestru zdarzeń.

WF.PUiA.015 Podsystem musi umożliwiać monitorowanie operacji uprzywilejowanych, tj. wykorzystanie uprawnień

administratora [pkt 5.15, str. 31]

W systemie rejestru zdarzeń będą odnotowywane operacje wszystkich użytkowników, w tym także operacje, które będą wymagały wykorzystania uprawnień związanych z administrowaniem systemem.

WF.PUiA.016 Podsystem musi umożliwiać 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 [pkt 5.16, str. 31]

Komponenty rozwiązania będą zapisywać zdarzenia biznesowe w ramach jednego wspólnego rejestru zdarzeń.

Komponent monitorowania rozwiązania pozwoli na raportowanie parametrów pojemnościowych i wykonywane wykresów w oparciu o historyczne wykorzystanie systemu.

WF.PUiA.017 Podsystem musi umożliwiać zarządzanie uprawnieniami [pkt 6.2, str. 31]

W systemie zostanie zaimplementowany system uprawnień oparty na uprawnieniach grupowanych w role. System umożliwi tworzenie nowych oraz redefiniowanie istniejących uprawnień i ról w systemie. System udostępni również mechanizmy definiowania grup użytkowników oraz przyłączania i odłączania użytkowników do/od grup. Zarządzanie uprawnieniami będzie odbywać się poprzez role z możliwością ich łączenia z użytkownikami lub grupami użytkowników.

WF.PUiA.018 Podsystem musi umożliwiać zarządzania politykami haseł [pkt 6.4, str. 31]

W systemie będzie udostępniona strona do zarządzania polityką haseł dla kont lokalnych, na której administrator będzie miał możliwość określenia minimalnej liczby znaków dla hasła, maksymalnej długości okresu ważności hasła, czy też liczby haseł do zapamiętania w historii haseł. Administrator będzie także miał możliwość wskazania czy hasło wymaga stosowania znaków specjalnych. Polityki haseł dla kont domenowych będą definiowane i zarządzane z poziomu Active Directory, z którym system będzie zintegrowany.


5.1.4 System Zarządzania ArchiwumWF.SZA.001 Podsystem będzie umożliwiał definiowanie 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)

[pkt 1, str. 28]

SZA przechowywał będzie parametry związane z polityką retencji i przechowywanie zasobów w PPD. Takimi parametrami będzie ilość kopii na bibliotece taśmowej (domyślnie po 1 kopii dla każdej z bibliotek),czas przechowywania zasobu na macierzy dyskowej (domyślnie 2 lata) oraz parametr związany z procentową ilością dostępnego wolnego miejsca. W przypadku osiągnięcia ustalonej wartości polityka retencji obejmować będzie wszystkie zasoby zaczynając od najstarszych.

W przypadku zapisu danych do PPD sprawdzana jest polityka przechowywania zasobów (ilość kopii).

Komponent JobManager cyklicznie sprawdza przechowywane zasoby pod kątem polityki retencji i usuwa z macierzy lokalnej kopię paczki.

WF.SZA.002 Podsystem będzie zapewniał integrację z Active Directory (użytkownicy, grupy, uprawnienia) [pkt 2, str. 28]

SZA będzie wykorzystywał PUiA w celu integracji z AD.

WF.SZA.003 Podsystem będzie umożliwiał definiowanie sposobu zabezpieczania dostępu do danych (kontrola uprawnień

dostępu do poziomu poszczególnego obiektu) [pkt 3, str. 28]

SZA będzie wykorzystywał PUiA w celu pobrania użytkowników, ról i uprawnień

WF.SZA.004 Podsystem zapewni automatyzację procesu „odświeżania” i zarządzania przechowywanymi danymi [pkt 4, str. 28]

Podsystem zapewni automatyzację procesu „odświeżania” i zarządzania przechowywanymi danymi – zarówno dla danych przechowywanych na dyskach magnetycznych (automatyczna weryfikacja poprawności danych poprzez porównywanie z funkcją skrótu – hash), jak i dla danych przechowywanych na taśmach (weryfikacja stanu taśm magnetycznych, przewijanie, kopiowanie danych na nowe nośniki).


W ramach PPD, w zakresie urządzenia archiwizującego wykorzystującego macierz dyskową system umożliwia konfigurację przechowywania paczki w wielu kopiach. Oprogramowanie Swift, umożliwia cykliczne (proces działający w tle) sprawdzanie kopii danych, porównanie spójności danych na podstawie funkcji skrótu oraz w przypadku wykrycia błędu podmianę uszodzonego objektu z jego kopii.

Początkowa konfiguracja w celu oszczędności wykorzystania miejsca na macierzy dyskowej, będzie skonfigurowana z 1 kopią. System wykorzysta wewnętrzne mechanizmy kontrolii błędów macierzy.

W przypadku biblioteki taśmowej, system zarządzania środowiskiem taśm w momencie przepisywania danych z jednej tasiemki na drugą sprawdza poprawność zapisanych danych i w przypadku błędu odtwarza zasób z kopii (druga biblioteka taśmowa). Przepisywanie taśm związane jest z procesem


reklamacji w ramach biblioteki taśmowej. Proces ten jest konfigurowalny. Parametrem jest procent zajętości taśmy. Po osiągnięciu zadanej wartości (np. 80%) następuje proces reklamacji taśm. Proces przepisywania można wywołać także ręcznie. Domyślną polityka jest wykorzystanie procesu reklamacji (na użytek kontroli błędów, zwalniania przestrzeni itp).

WF.SZA.005 Podsystem będzie zapewniał poufność, integralność i niezaprzeczalność transmisji [pkt 5, str. 28]

SZA w momencie przyjęcia paczki do Archiwum zweryfikuje poprawność transmisji z pomocą podpisu paczki, wykorzystywanego na czas transportu paczki do archiwum.

WF.SZA.006 W zakresie zarządzania agentami podsystem musi umożliwiać monitorowanie stanu agentów i łączy pomiędzy

lokalizacją archiwum centralnego a lokalizacją agenta [pkt 1.1, str. 29]

W Portalu dostępny będzie podgląd działających agentów (wersji, stanu, typu) jak również monitoring łącz pomiędzy agentami a zasobem SCP Storage.

WF.SZA.007 W zakresie zarządzania agentami podsystem musi umożliwiać monitorowanie stanu zasobów lokalnych i

centralnych niezbędnych dla funkcjonowania archiwum [pkt 1.2, str. 29]

W Portalu w zakresie zarządzania agentami dostępny będzie monitoring stanu zasobu centralnego SCP Storage oraz stanu zasobu lokalnego.

WF.SZA.008 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 [pkt 1.3, str. 30]

W Portalu dostępne będzie zarządzanie harmonogramami archiwizacji (oknami transferowymi). W szczególności możliwe będzie ustanowienie indywidualnych harmonogramów dla każdego agenta.

WF.SZA.009 W zakresie zarządzania agentami podsystem musi umożliwiać potwierdzanie poprawności zarchiwizowania

danych, ponawianie transmisji [pkt 1.4, str. 30]

SZA po przetworzeniu paczki udostępnionej w SCP Storage poinformuje o tym RCS Agent Server za pośrednictwem SCP Storage, a jednocześnie paczka zostanie usunięta z SCP Storage.

W przypadku problemów z przetworzeniem paczki (np. czasowy brak dostępu) SZA będzie ponawiał próby, a paczka nie zostanie usunięta z SCP Storage do czasu jej przetworzenie przez SZA.

WF.SZA.010 W zakresie przechowywania danych podsystem musi przechowywać informację o wszystkich zarchiwizowanych


[pkt 2.1, str. 30]

SZA po przyjęciu paczki zapisuje informację o paczce, sprawach i plikach wchodzących w skład paczki w dokumentowej bazie indeksującej. Dokumentowa baza indeksująca jest to bez schematowa, dokumentowa baza Elasticsearch zbudowana w oparciu o silnik wyszukiwania Lucene. Zapewnia on rozproszony, wielodostępowy system do wyszukiwania pełnotekstowego. Przechowywane są w tej bazie metadane, dzięki czemu możliwy jest szybki dostęp do metadanych każdego z dokumentu przechowywanego w CAPE.

Podstawowym elementem w ramach rozwiązania CAPE jest dokument. Granulacja przy procesach wyszukiwania, udostępniania, brakowania itd jest na poziomie pojedynczego dokumentu. Przy przyjmowaniu paczki transportowej do systemu CAPE następuje proces przetwarzania plików z paczki. Każdy z plików opisywany jest metadanymi w bazie indeksującej oddzielnie. Natomiast wewnętrznie powiązane dokumenty przechowywane są razem w ramach jednej paczki dla łatwości przechowywania, udostępniania i bezpieczeństwa.

WF.SZA.011 System Zarządzania Archiwum musi zarządzać retencją paczek archiwalnych zgodnie z przyjętą polityką retencji

[pkt 2.2, str. 30]

System przechowuje informację o obowiązującej polityce retencji, jako czas, po którym paczka archiwalna przechowywana jest tylko w kopiach na bibiotekach taśmowych. Po zadanym okresie czasu, paczka jest usuwana z urządzenia archiwizującego i macierzy dyskowej. Informacja o tej zmianie zapisywana jest w bazie indeksowej.

System posiada menedżera zadań cyklicznie wyszukującego sprawy podlegające retencji zgodnie z przyjętą polityką retencji. Po wyszukaniu, wrzuca listę paczek do usunięcia do kolejki. Nazwy paczek z kolejki przekazywane są do PPD do usunięcia.

WF.SZA.012 W zakresie przechowywania danych podsystem musi zapewniać przenoszenie danych z macierzy dyskowej do

biblioteki taśmowej zgodnie z przyjętą polityką [pkt 2.3, str. 30]

Paczka z danymi spraw trafia początkowo do przechowali, jest weryfikowana i zostaje zapisana na macierz dyskową, a metadane zostają zapisane w bazie dokumentowej. Sprawa z takiej paczki dostępna jest tylko do wyszukiwania na potrzeby spisu zdawczo-odbiorczego. SZA w momencie przyjęcia paczki do archiwum i po jej weryfikacji zapisuje dane dodatkowo na bibliotece taśmowej (w lokalizacji podstawowej i zapasowej). Zmieniany jest status przechowania sprawy na zarchiwizowaną.

WF.SZA.013 W zakresie przechowywania danych podsystem musi zapewniać generowanie raportów dotyczących

przechowywanych paczek i zdeklarowanych okresów ich przechowywania [pkt 2.4, str. 30]

W ramach Systemu będzie możliwość wygenerowania określonych raportów i statystyk, w tym także zestawienie spraw przechowywanych w CAPE, z uwzględnieniem dat zakończenia tych spraw i ich kategorii.

WF.SZA.014 Podsystem umożliwi przyjmowanie i rejestrowanie żądań dostępu do zarchiwizowanych danych [pkt 3.1, str. 30]


Użytkownik systemu będzie miał możliwość złożenia zamówienia na dokumenty przechowywane w ramach CAPE. Po zaakceptowaniu zamówienia z poziomu Portalu, zamówienie będzie przekazywane do SZA i odnotowywane w rejestrze zdarzeń.

WF.SZA.015 SZA musi odtwarzać dane z archiwum i przygotować do przesłania do systemu lokalnego [pkt 3.2, str. 30]

SZA po otrzymaniu żądania odtworzenia danych z archiwum sprawdza lokalizację danych. W przypadku gdy dane ciągle przechowywane są w urządzeniu archiwizującym, pobierane są stamtąd. W przypadku gdy dane przechowywane są na bibliotece taśmowej przekazywane jest żądanie pobrania paczki do PPD, systemu zarządzania środowiskiem testowym. Po pobraniu danych, SZA przygotowuje paczkę do udostępnienia (buduje w razie potrzeby paczkę powiązanych spraw). SZA kopiuje gotową paczkę z danymi do wydzielonego zasobu dyskowego. Następnie SZA wysyła informację o gotowości do pobrania danych. W przypadku zamówienia lokalnego paczka trafia do odpowiedniego katalogu, z którego pobrana zostanie przez agenta. W przypadku zamówienia centralnego, paczka trafia do dedykowanego katalogu (domyślnie „central”) skąd administrator może przekopiować dane.

WF.SZA.016 Podsystem umożliwi przygotowanie i udostępnienie danych archiwalnych (np. odtworzenie i przeniesienie

danych na dedykowany obszar macierzy) [pkt 3.3, str. 30]

SZA sprawdzi lokalizację paczki zawierającej dane archiwalne na które zostało złożone zamówienie. W przypadku gdy paczka dostępna jest w urządzeniu archiwizującym, paczka pobierana jest stamtąd do tymczasowego buforu. W przypadku gdy dane archiwalne są dostępne tylko na bibliotece taśmowej SZA pobiera dane, wykorzystując komponent TapeManager, do tymczasowego buforu na macierzy dyskowej. Paczka następnie jest przygotowywana do wysyłki (usuwane są zasoby, które zostały wyłączone przez archiwistę).

Dane gotowe są do odbioru na dedykowanym obszarze macierzy zgodnie z wybranym sposobem transportu.

WF.SZA.017 W zakresie udostępniania danych podsystem musi zapewnić możliwość pobrania jednocześnie wszystkich

danych dotyczących jednej sprawy [pkt 3.4, str. 30]

SZA przechowywać będzie powiązania pomiędzy plikami należącymi do jednej sprawy, oraz dodatkowo przechowywał będzie wszystkie pliki danej sprawy w jednej paczce. Udostępnianie danych będzie wykonywane zgodnie z WF.SZA.016

WF.SZA.018 W zakresie udostępniania danych podsystem umożliwi wybór medium jakim dane zostaną dostarczone do zasobu

lokalnego (WAN, taśma, płyta, itp) [pkt 3.5, str. 30]

Przy składaniu zamówienia na materiały z archiwum, użytkownik będzie miał możliwość określenia, w jaki sposób dane powinny być dostarczone do zasobu lokalnego. SZA przygotuje zamówione dane do udostepnienia zgodnie ze wskazanym przez użytkownika lokalizacją. W przypadku zamówienia lokalnego paczka trafia do odpowiedniego katalogu, z którego pobrana zostanie przez agenta. W przypadku zamówienia centralnego, paczka trafia do dedykowanego katalogu (domyślnie „central”) skąd administrator może przekopiować dane.


WF.SZA.019 W zakresie udostępniania danych podsystem zapewni informowanie o statusie żądania i przewidywanym czasie

wykonania [pkt 3.6, str. 30]

Po złożeniu przez użytkownika zamówienia na materiały z archiwum, System wyświetli użytkownikowi informację o stanie jego zamówienia oraz o szacowanym czasie jego zrealizowania.

WF.SZA.020 W zakresie udostępniania danych podsystem zapewni rejestrowanie pobrania danych [pkt 3.7, str. 30]

Każde złożone do systemu zamówienie na dokumenty sprawy będzie rejestrowane. W ramach informacji o danym zamówieniu będzie odnotowywana data utworzenia paczki z zamówionymi dokumentami (data zrealizowania zamówienia).

WF.SZA.021 Podsystem musi zarządzać przestrzenią dyskową przeznaczoną na wymianę (pobieranie) danych archiwalnych w

szczególności system musi zwalniać przestrzeń po potwierdzeniu pobrania paczki, zarządzać uprawnieniami do pobierania

[pkt 3.8, str. 30]

SZA wykorzystuje PUiA w celu zarządzania uprawnieniami. SZA w momencie potwierdzenia pobrania paczki skasuje paczkę. Dodatkowo paczki przygotowane do pobrania, a nie potwierdzono ich odbioru, po zadanym okresie czasu będą również kasowane.

WF.SZA.022 Podsystem umożliwi zarządzanie harmonogramami tworzenia kopii archiwalnych [pkt 6.3, str. 31]

SZA po przyjęciu paczki do archiwum oraz jej weryfikacji system zapisuje metadane opisujące paczkę oraz samą paczkę.

Początkowo paczki spraw trafiają do przechowalni – dane zostają zapisane na macierzy dyskowej, a metadane w bazie dokumentowej.

Archiwista z pomocą spisu zdawczo-odbiorczego archiwizuje sprawę. Paczka zapisywana jest dodatkowo na bibliotece taśmowej (w lokalizacji podstawowej i zapasowej).

System sprawdza poprawność przesłanych danych, weryfikuje poprawność budowy paczki transportowej i możliwość przetwarzania plików opisujących metadane. W przypadku wykrycia błędu, system ustawia odpowiedni kod błędu, który umożliwia agentowi podjęcie odpowiednich kroków (przesłanie paczki ponownie, informacja do administratora a błędzie).

WF.SZA.023 Podsystem umożliwi zarządzanie politykami retencji obejmującymi czas przechowywania danych oraz zasady ich

przenoszenia z macierzy dyskowej do biblioteki taśmowej [pkt 6.5, str. 31]

SZA przechowuje zmienne opisujące czas przechowywania danych na macierzy dyskowej (domyślnie 2 lata) oraz parametr określający stopień zajętości przestrzeni w Urządzeniu Archiwizującym po którym dane mają być przenoszone na bibliotekę taśmową. System monitoruje te dane w Urządzeniu Archiwizującym w oparciu o te dwa parametry. Dane z archiwum (tylko sprawy zarchiwizowane, a nie w przechowalni) są przenoszone na bibliotekę taśmową, zgodnie z polityką retencji to jest, starsze niż 2 lata, lub w przypadku przekroczenia zajętości przestrzeni dyskowej wszystkie dane zaczynając od


najstarszych, aż do zwolnienia miejsca.

Administrator może zarządzać obiema wartościami.

WF.SZA.024 Podsystem zapewni możliwość monitorowania parametrów pojemnościowych i wydajnościowych elementów

infrastruktury archiwum centralnego [pkt 6.6, str. 31]

SZA wykorzystuje komponent Monitoring, zbudowany w oparciu o system Nagios (wersja Icinga) do monitorowania parametrów pojemnościowych i wydajnościowych archiwum. Komponent będzie monitorował między innymi wykorzystanie procesora, pamięci RAM, zajętość dysku, wykorzystanie sieci, a także monitorował dostępność i osiągalność serwisów.

WF.SZA.025 Podsystem zapewni dostęp do logów systemowych [pkt 6.7, str. 31]

SZA wysyła informację o biznesowych zdarzeniach do wspólnego repozytorium zdarzeń.

Dodatkowo, wszystkie logi systemowe wysyłane są na wspólny serwer logów, odzielny od pozostałych części infrastruktury, umożliwiając przegląd logów z wszystkich elementów infrastruktury w jednym miejscu.

Wykorzystano zestaw ELK – Baza dokumentowa elasticsearch umożliwiająca pełno-tekstowe wyszukiwanie, Logstash zbierający dane z wszystkich serwerów oraz Kibana będąca interfejsem użytkownika.

5.1.5 Podsystem Przechowywania DanychWF.PPD.001 Podsystem musi zapewnić utrzymanie wiarygodności przekazanych dokumentów [pkt 1, str. 27]

Do przekazanych do podsystemu paczek z dokumentami dołączany będzie plik z skrótem md5 w celu weryfikacji poprawności przekazywanych dokumentów.

WF.PPD.002 Podsystem zapewni bezpieczeństwo przekazywania a następnie przechowywania i udostępniania dokumentów

przez archiwum [pkt 2, str. 27]

Podsystem zapewni bezpieczeństwo przekazywania a następnie przechowywania i udostępniania dokumentów przez archiwum – poprzez chronienie danych przed utratą, modyfikacją i nieupoważnionym dostępem.


PPD w celu zabezpieczenia przed utratą danych zapewni zapis w minimum trzech kopiach (macierz dyskowa, oraz dwie biblioteki taśmowe, każda w oddzielnej lokalizacji). System umożliwiać będzie dostęp tylko przez określone interfejsy, do których dostęp jest zabezpieczony poprzez system uwierzytelnienia. Dostęp do samego oprogramowania nie będzie możliwy dla użytkowników systemu, a jedynie administratorów.


WF.PPD.003 PPD musi gwarantować niemodyfikowalność danych i brak możliwości ich usunięcia przez cały okres

przechowywania [pkt 3, str. 27]

PPD będzie gwarantować niemodyfikowalność danych w oparciu o rozwiązanie programowe i kontrolę dostępu do zasobów. Takie rozwiązanie zostanie zastosowane w związku ze specyfiką macierzy dyskowej i biblioteki taśmowej (możliwość wykorzystania uprawnień administratora) oraz koniecznością zapewnienia funkcjonalności shreddingu.

WF.PPD.004 PPD musi zapewnić redundancje przechowywania danych gwarantującą odporność na awarię i katastrofy. [pkt 4, str. 27]

PPD będzie zapisywać dane w minimum trzech kopiach. W jednej kopii na urządzeniu archiwizującym (możliwość konfiguracji większej ilości kopii, kosztem wolnej przestrzeni) oraz w dwóch kopiach na bibliotece taśmowej. Każda z kopii zapisywana jest na bibliotece taśmowej w różnych ośrodkach przetwarzania.

WF.PPD.005 Podsystem będzie posiadał wbudowane mechanizmy raportowania według indeksu [pkt 7, str. 27]

Metadane opisujące dane przechowywane w PPD przechowywane są w dokumentowej bazie indeksującej, która pozwala na wyszukiwanie i pobranie szczegółowych danych przechowywanej paczki oraz jej zawartości.

WF.PPD.006 Podsystem będzie gwarantował ścisłą kontrolę dostępu do przechowywanych danych, na poziomie Active

Directory do poziomu obiektu lub pojedynczego pliku [pkt 9, str. 27]

PPD będzie realizował dostęp do przechowywanych danych na podstawie zdefiniowanych ról i uprawnień w systemie PUiA. Dostęp do obiektów będzie dwupoziomowy:

- dostęp na poziomie roli systemowej (np. Archiwista, Administrator), określającej działania jakie może wykonać w Systemie użytkownik przypisany do danej roli- dostęp do obiektów wynikający z metadanych dokumentu, określających miejsce wytworzenia dokumentu (czyli ktoś z rolą archiwista ma dostęp do dokumentów, które w metadanych miejsca wytworzenia mają ‘jego’ sąd).

5.1.6 Ogólne[Specyfikacja wymagań tych, które mają być spełnione albo przez wszystkie podsystemy albo takie których nie można powiązać z konkretnym podsystemem]

5.2 Wymagania pozafunkcjonalne

Niniejszy podrozdział przedstawia wszystkie zebrane wymagania pozafunkcjonalne. Nazwa każdego wymagania składa się z identyfikatora i treści tego wymagania. Identyfikator wymagania pozafunkcjonalnego zawiera stały przedrostek WNF oraz unikalny numer wymagania. Poza identyfikatorem i nazwą opisową, wymagania pozafunkcjonalne opisywane są również poprzez elementy:


Pełna treść wymagania – element opcjonalny, wykorzystywany w przypadku gdy treść wymagania jest zbyt obszerna by była wprowadzona jako nazwa wymagania;

Opis realizacji wymagania – poszerzony opis realizacji danego wymagania;

Historia – historia modyfikacji wymagania zawierająca datę oraz krótki opis wprowadzonych zmian wraz z ich identyfikatorem i autorem.

WNF.001 Portal musi być dostępny za pomocą przeglądarki internetowej, w szczególności Internet Explorer w wersjach 8.0 i nowszych oraz Mozilla Firefox w wersjach 3.0 i nowszych. [pkt 1, str. 32]

Został zgłoszony wniosek o zmianę, który zmienia treść wymagania na:

WNF.001 Portal musi być dostępny za pomocą przeglądarki internetowej, w szczególności InternetExplorer w wersjach 9.0 i nowszych, Chrome w wersjach 43 i nowszych oraz Mozilla Firefox wwersjach 31 i nowszych

Portal zostanie wykonany przy użyciu technologii internetowych opartych na Java EE oraz DHTML, które pozwolą na korzystanie z Portalu przy użyciu wyżej wymienionych przeglądarek internetowych

WNF.002 Portal musi umożliwiać automatyczne zamykanie sesji dostępu użytkownika po upływie określonego w konfiguracji

systemu czasu od momentu przerwania pracy z systemem (np. zamknięcia przeglądarki). [pkt 2, str. 32]

Wykorzystany zostanie standardowy mechanizm sesji HTTP, która jest ograniczona czasowo. Wygaśnięcie sesji spowoduje utratę wszystkich niezapisanych danych w ramach sesji.

WNF.003 Portal musi generować spersonalizowane środowisko pracy dla każdego zalogowanego użytkownika udostępniające

zestaw funkcji zgodny z nadanymi uprawnieniami, [pkt 3, str. 32]

Po zalogowaniu użytkownik ma dostęp do spersonalizowanych opcji w zależności od przyznanych mu uprawnień. System nie pozwoli na realizację operacji, do których użytkownik nie ma dostępu.

WNF.004 Portal musi zapewniać mechanizmy minimalizujące degradację wydajność systemu przy przeglądaniu bardzo długich

list, [pkt 4, str. 32]

W miejscach, w których pojawić się mogą dane w dużych ilościach zostanie zastosowany komponent grid, pozwalający na efektywne przeglądanie oraz ograniczający wykorzystanie zasobów systemu. W zależności od typu i ilości prezentowanych danych grid będzie pozwalał na stronicowanie, filtrowanie oraz sortowanie danych w nim zawartych.

WNF.005 Portal musi zapewniać możliwość wykonywania operacji grupowych na zaznaczonych elementach listy [pkt 5, str. 32]

W miejsach do tego zasadnych wspomniany w wymaganiu WNF.004 grid będzie dostarczał mechanizmu zaznaczania wybranych wierszy oraz operacji grupowych na wszystkich zaznaczonych elementach.


WNF.006 Podsystem przechowywania danych udostępni sprawy zamknięte w czasie do dwóch godzin [pkt 5, str. 27]

Zakładany czas przekazania dokumentacji archiwalnej z Podsystemu Przechowywania Danych na bufor dyskowy / wskazany zasób sieciowy w obrębie infrastruktury centralnej będzie mniejszy niż 2 godziny.

WNF.007 PPD będzie gwarantował kilkudziesięcioletni czas życia systemu informatycznego, odporność na zmiany

technologiczne w całym cyklu życia [pkt 6, str. 27]

W ramach PPD Urządzenie archiwizujące oparte jest na dwóch głównych komponentach oprogramowaniu firmy IBM oraz oprogramowaniu Openstack w wersji ze wsparciem firmy Redhat. Produkt firmy IBM istnieje na rynku od wielu lat i jest jednym z najpopularniejszych rozwiązań w zakresie zarządzania bibliotekami taśmowaymi. W przypadku oprogramowania Openstack, jest to rozwiązanie o otwartym kodzie, a wsparcie najwiekszych twórców oprogramowania na świecie (IBM, HP, Oracle itd), ogromna społeczność oraz cykl półrocznych wydań zapewnia odporności na zmiany technologiczne.

WNF.008 Dostęp do PPD będzie możliwy za pomocą otwartych, standardowych interfejsów: HTTP/S, WebDAV, NFS, CIFS

[pkt 8, str. 27]

Głównym interfejsem dostępu do PPD będzie REST API dostępny poprzez protokół HTTP/S. Rozwiązanie udostępni także protokoły WebDAV, NFS, CIFS w celu udostępnienia punktu dostarczania paczek archiwalnych. W celu zapewnienia spójności danych, itegralności, wersjonowania, bezpieczeństwa poprzez pozostałe protokoły nie będzie możliwy dostęp do odczytu i pobrania. Rozwiązanie umożliwia także wykonanie kopii zapasowej dysków macierzy NetApp z pomocą protokołu NDMP poprzez komponent zarządzania TSM systemu zarządzania środowiskiem taśmowym (w ramach PPD).

WNF.009 PPD będzie wykorzystywał gotowe komponenty teleinformatyczne, zmniejszając w ten sposób czas trwania budowy

archiwum oraz zmniejszając ryzyko niepowodzenia projektu [pkt 10, str. 27]

PPD w zakresie Urządzenia archiwizującego wykorzystuje gotowe komponenty firmy IBM oraz otwartego oprogramowania Openstack ze wsparciem firmy Redhat.

WNF.010 PPD będzie się charakteryzował otwartą architekturą, która umożliwia migrację do nowych wersji oprogramowania i

sprzętu bez przerywania pracy archiwum (przy zachowaniu ciągłego dostępu do danych) [str. 28]

PPD w zakresie urządzenia archiwizującego charakteryzuje się otwartą architekturą, a redundancja poszczególnych elementów zapewni w większości przypadków migrację oprogramowania i sprzętu bez przerywania pracy. Istnieje stały zestaw procedur, które wstrzymają pełen dostęp do danych. Np. rozbudowa jednej z bibliotek spowoduje konieczność jej wyłączenia. Pozostaje dostęp do danych z drugiej biblioteki, jednak uniemożliwia to zapis na tej z bibliotek, która została zatrzymana w celu rozbudowy.


WNF.011 SZA umożliwi komunikację z systemami zewnętrznymi za pośrednictwem usług w modelu SOA [pkt 4.1, str. 30]

System zostanie przygotowany za pomocą narzędzi i technologii obsługujących takie usługi jak Web Services, REST itp. Podczas pracy nad Systemem wykorzystywane będą otwarte standardy wymiany informacji takie jak: WSDL, SOAP, XML, XML Schema.

WNF.012 SZA do opisu usług będzie wykorzystywać standard WSDL [pkt 4.2, str. 30]

Przy wykorzystaniu standardu WSDL opisana zostanie usługa sieciowa w stylu SOAP dotycząca wyszukiwania. WSDL opisze możliwe parametry wyszukiwania (m. in. Identyfikator wydziały, typ dokumentu czy wyszukiwana fraza) oraz zwróci listę pasujących obiektów – spraw lub dokumentów. WSDL zdefiniuje format żądania i odpowiedzi typu XML przy użyciu XML Schema.

WNF.013 SZA zapewni możliwość zarejestrowania usługi w rejestrze usług zgodnym ze standardem UDDI [pkt 4.3, str. 30]

Podczas pracy nad Systemem wykorzystywane będą otwarte standardy wymiany informacji takie jak: WSDL, SOAP, XML, XML Schema. Dzięki temu usługi Systemu CAPE będą mogły być opublikowane i wyszukiwane w rejestrach usług. Docelowo umożliwi to również współpracę systemu CAPE z innymi rejestrami administracji publicznej.

WNF.014 SZA do opisu struktury komunikatów będzie wykorzystywać standard XSD [pkt 4.4, str. 30]

Podczas pracy nad Systemem wykorzystywane będą otwarte standardy wymiany informacji takie jak: WSDL, SOAP, XML, XML Schema. Struktura komunikatów będzie opisywana za pomocą standardu XML Schema.

WNF.015 Struktura plików wymiany danych z systemami zewnętrznymi będzie zgodna ze specyfikacją XML [pkt 4.5, str. 30]

Podczas pracy nad Systemem wykorzystywane będą 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.

WNF.016 SZA zapewni zgodność szczegółów zastosowanych ww. standardów z aktualnymi wymaganiami dla platformy e-

PUAP [pkt 4.6, str. 30]


Podczas pracy nad Systemem wykorzystywane będą otwarte standardy wymiany informacji takie jak: WSDL, SOAP, XML, XML Schema. Wykorzystywane w Systemie standardy zapewnią możliwość integracji Systemu z ePUAP, dzięki czemu będzie możliwe złożenie do CAPE zamówienia na udostępnienie materiałów za pomocą wniosku udostępnionego na platformie ePUAP. W tym celu wykorzystana zostanie usługa Skrytka dostępna pod adresem:

http://epuap.gov.pl/pk_external_ws/services/skrytka (adres WSDL: http://epuap.gov.pl/pk_external_ws/services/skrytka/wsdl/skrytka.wsdl).

WNF.017 SZA musi zapewniać komunikację z systemami zewnętrznymi w zakresie całej opisanej funkcjonalności [pkt 4.7, str. 30]

Podczas pracy nad Systemem wykorzystywane będą otwarte standardy wymiany informacji takie jak: WSDL, SOAP, XML, XML Schema. Funkcje Systemu dostępne z poziomu GUI będą również dostępne w postaci zaimplementowanych usług sieciowych.

WNF.018 Graficzny interfejs administracyjny SZA będzie zrealizowany w postaci aplikacji działającej pod kontrolą systemu

Windows7, Windows8, lub dostępnego przez przeglądarkę internetową [pkt 6.1, str. 31]

Graficzny interfejs administracyjny SZA będzie zrealizowany w postaci aplikacji działającej pod kontrolą systemu Windows7, Windows8, lub dostępnego przez przeglądarkę internetową. Interfejs graficzny może wykorzystywać inną platformę systemową niż Windows, jednakże musi, np. poprzez mechanizm emulacji, być kompatybilny z posiadanymi już przez Zamawiającego systemami Windows7/8.


Interfejs administracyjny dostępny będzie poprzez przeglądarkę WWW. System będzie generował widoki, formatki administracyjne, które będą dołączane(ramka – Iframe) do głównego wzorca (template) aplikacji Portal w celu zapewnienia spójności prezentacji.


6 Model wykorzystania systemuDokument zawiera dokumentację modelu wykorzystania systemu w projekcie dostawy i wdrożenia systemu Centralnego Archiwum Protokołów Elektronicznych (CAPE). Do prezentacji modeli analitycznych wykorzystywana jest notacja UML 2.0. Wszystkie diagramy zawarte wewnątrz niniejszego dokumentu są artefaktami i są odrębnie identyfikowane i wersjonowane.

Nazwa każdego przypadku użycia składa się z identyfikatora i nazwy opisowej. Identyfikator przypadku użycia zawiera stały przedrostek UC, przedrostek modułu do którego należy (P – Portal, PPD – Podsystem Przechowywania Danych, PUiA – Podsystem Uwierzytelniania i Autoryzacji, SZA – System Zarządzania Archiwum) oraz unikalny numer przypadku użycia.

Poza identyfikatorem i nazwą opisową, dla każdego przypadku użycia zdefiniowane zostały następujące elementy:

Opis – krótki opis biznesowy danego przypadku użycia;

Warunki początkowe – określenie danych będących parametrami początkowymi dla danego przypadku użycia;

Wynik końcowy – określenie danych będących ostatecznym wynikiem operacji wynikających z przypadku użycia;

Reguły – określenie stałych i niezmiennych założeń niezbędnych do realizacji przypadku użycia;

Przebieg podstawowy (PG) – przebieg główny, opisujący optymalną ścieżkę realizacji przypadku użycia;

Przebiegi alternatywne (PA) i wyjątkowe (PW) – scenariusze poboczne, opisujące sytuacje, w których nie zachodzi ścieżka optymalna; przebiegi alternatywne i wyjątkowe są numerowane kolejnymi numerami w ramach danego przypadku użycia.


6.1 Specyfikacja aktorów

Rysunek 12: Aktorzy – role systemu CAPE

uc DUC-001 Aktorzy-role systemu CAPE

A.02 Pracownik sekretariatu A.03 Archiwista A.04 Członek

komisj i ds. brakowania

A.01 Użytkownik systemu

A.05 Administrator

A.06 JobManager


A.02 Pracownik sekretariatu

A.03 Archiwista

A.04 Członek komisji ds. brakowania

A.05 Administrator

A.06 JobManager

Aktor Systemowy odpowiedzialny za cykliczne wykonywanie określonych zadań w Systemie Zarządzania Archiwum i Podsystemie Przechowywania Danych.


6.2 Przypadki użycia – Administracja SZA

Rysunek 13: Administracja Systemem Zarządzania Archiwum

uc Administracja SZA

System Zarządzania Archiwum

A.05 Administrator

(from Aktorzy)

UC.SZA.001 Zarządzanie polityka

retencj i

UC.SZA.002 Zarządzanie liczbą kopii paczki na bibliotece taśmowej

UC.SZA.001 Zarządzanie polityką retencji

Administrator systemu ma możliwość ustawienia czasu przechowywania paczki na macierzy dyskowej.

Warunki początkowe:

Zalogowany do systemu Administrator dysponujący odpowiednimi uprawnieniami.

Wynik końcowy:

Ustawiony czas przechowywania paczki na macierzy dyskowej.

PG:

3. Administrator potwierdza zmianę czasu przechowywania paczki.

3 System zapisuje zmienną.

UC.SZA.002 Zarządzanie liczbą kopii paczki na bibliotece taśmowej


Administrator systemu ma możliwość ustawienia liczby kopii przechowywanej paczki na bibliotece taśmowej.



Wynik końcowy:

Ustawienie liczby przechowywanej nowo przychodzącej paczki na bibliotece taśmowej.

PG:

4. Administrator potwierdza zmianę wartości;

3 System zapisuje wartość.


6.3 Przypadki użycia – Portal

Rysunek 14: Diagram przypadków użycia – Portal

uc DUC-003 Portal_2

Portal


A.02 Pracownik sekretariatu

A.03 Archiwista

A.04 Członek komisj i ds. brakowania

Name: DUC-003 Portal_2Author: Katarzyna.KaczynskaVersion: 1.0Created: 2015-09-21 14:07:11Updated: 2015-09-25 15:45:14

UC.P.001 Dodanie zamówienia

UC.P.002 Przyjęcie danych do archiwum

UC.P.003 Utworzenie protokołu brakowania

UC.P.004 Decyzja w sprawie protokołu

brakowania

UC.P.005 Zatwierdzenie

protokołu brakowania

UC.P.006 Generowanie raportu

UC.P.007 Wyszukanie sprawy

UC.P.008 Przeglądanie sprawy

UC.P.010 Zatwierdzenie protokołu przekazania

do AP

UC.P.009 Utworzenie protokołu przekazania

do AP

«extend»


UC.P.001 Dodanie zamówienia

Dodanie zamówienia na dostęp do akt danej sprawy/spraw. W ramach zamówienia można wnioskować o dostęp do wybranych lub wszystkich dokumentów z danej sprawy/spraw. W przypadku alternatywnym 1 zamówienie dotyczy wycofania spraw z systemu.

Warunek początkowy:

Zalogowany do systemu Pracownik Sekretariatu dysponujący odpowiednimi uprawnieniami

Wynik końcowy:

Złożone zamówienie na odtworzenie wybranych paczek/paczki z archiwum centralnego.

Dla przypadku PA1: Złożenie zamówienia na wycofanie spraw/y

Dla przypadku PA2: Złożenie zamówienia na materiały archiwalne za pośrednictwem ePUAP

Dla przypadku PA3: Odrzucenie zamówienia na materiały archiwalne

PG - złożenie zamówienia:

2. Użytkownik wybiera typ zamówienia: wniosek o pobranie

3. Użytkownik wybiera sprawę/sprawy, w ramach, których chce uzyskać dostęp do akt.

4. Użytkownik dla wybranej sprawy wybiera dokument/y, do których chce uzyskać dostęp.

5. Użytkownik wybiera z listy formę przekazania dokumentów.

6. Użytkownik zapisuje zamówienie.

7. Użytkownik sprawdza poprawność zamówienia i wysyła zamówienie do realizacji.

8. System wyświetla komunikat z prośbą o potwierdzenie wysłania zamówienia.

9. Użytkownik potwierdza chęć wysłania zamówienia.

10. System wysyła zamówienie do realizacji.

PA 1 złożenie zamówienia na wycofanie spraw/y:

3a. Użytkownik wybiera sprawę/sprawy, które chce wycofać z systemu

4a. Użytkownik podaje powód wycofania

5a. Użytkownik wybiera Sąd/Wydział, do którego następuje wycofanie spraw

6a. Użytkownik zapisuje wniosek o wycofanie.

7a. Użytkownik sprawdza poprawność zamówienie (na wycofanie) i wysyła zamówienie do realizacji.

8a. System wyświetla komunikat z prośbą o potwierdzenie wysłania zamówienia.


9a. Użytkownik potwierdza chęć wysłania zamówienia.

10a. System wysyła zamówienie do realizacji.

11a. Użytkownik otrzymuje informacje o odebraniu paczki (z wycofywanymi sprawami)

12a. System zmienia status spraw/y na ‘Wycofana’. Sprawa/y są wyłączone z wyników wyszukiwania

Reguły:

R2. Użytkownik ma możliwość edytowania zamówienia tylko w statusie „W przygotowaniu”.

R3. Zamówienie można składać tylko na sprawy w statusie: zarchiwizowana

R4. Dla zamówienia pochodzącego z ePUAP nadawany jest automatycznie typ zamówienia (udostępnienie – ePUAP)

PA 2 złożenie zamówienia (na udostepnienie) z ePUAP

1. Użytkownik na stronie z listą zamównień filtruje zamówienia po typie: udostępnienie – ePUAP

2. Użytkownik wybiera zamówienie w statusie ‘W przygotowaniu’

3. Użytkownik wybiera sprawę (na podstawie informacji w polu opisowym)

4. Użytkownik dla wybranej sprawy (na podstawie informacji w polu opisowym) wybiera dokument/y, które chce zamówić wnioskodawca

5. Użytkownik wybiera z listy formę przekazania dokumentów.

6. Użytkownik zapisuje zamówienie.

7. Użytkownik sprawdza poprawność zamówienia i wysyła zamówienie do realizacji.

8. System wyświetla komunikat z prośbą o potwierdzenie wysłania zamówienia.

9. Użytkownik potwierdza chęć wysłania zamówienia.

10. System wysyła zamówienie do realizacji.

PA 3 odrzucenie zamównienia z ePUAP

1. Użytkownik na stronie z listą zamównień filtruje zamówienia po typie: udostępnienie – ePUAP

2. Użytkownik wybiera zamówienie w statusie ‘W przygotowaniu’

3. Użytkownik przegląda szczegóły zamówienia, w tym opis i uzasadnienie

4. Użytkownik odrzuca zamówienie i podaje powód odrzucenia

5. System wysyła informację zwrotną dla wnioskującego do ePUAP

UC.P.002 Przyjęcie danych do archiwum


Przypadek opisuje wczytywanie spisu zdawczo-odbiorczego z pliku csv W przypadku wystąpienia błędów istnieje możłiwośc usunięcia błędnych rekordów lub ponownego wczytania poprawionego poza systemem pliku csv i nadpisania błędych danych, a następnie zatwierdzenia spisu zdawczo – odbiorczego.

Przypadek alternatywny 2 opisuje sytuację, w której do systemu wprowadzana jest nowa wersja sprawy zarejestrowanej już w systemie CAPE.


Istnieje plik csv spisu zdawczo odbiorczego.

Wynik końcowy:

Utworzony i zatwierdzony spis zdawczo-odbiorczy dla danego wydziału.

Dla przypadku alternatywnego 2:

W systemie została dodana nowa wersja dla sprawy pobranej z tą samą sygnaturą.

Reguły:

R1: Odnosi się do przypadku PA 1: Nowa wersja sprawy jest nadawana w przypadku pobierania sprawy, która jest już zarejestrowana w systemie z tą samą sygnaturą. Dodatkowo sprawa ta ma status Wycofana

R2. Do momentu zatwierdzenia spisu użytkownik ma możliwość jego usunięcia.

PG - zatwierdzenie spisu zdawczo - odbiorczego:

1. Użytkownik wchodzi na stronę z listą spisów zdawczo – odbiorczych

2. Użytkownik dodaje nowy spis zdawczo – odbiorczy

3. Użytkownik uruchamia akcję wczytania pliku ze spisem zdawczo – odbiorczym

4. System wyświetla listę spraw dla danego spisu zdawczo – odbiorczego

5. W przypadku wystąpienia błędów, system wyświetla dla danej sprawy informację o rodzaju błędu np. nie znaleziono sprawy

6. Użytkownik zaznacza do usunięcia ‘sprawy’ z błędem

7. Użytkownik uruchamia funkcję usuwania błędnych spraw ze spisu

8. W przypadku braku błędów użytkownik zatwierdza spis zdawczo-odbiorczy

PA 1 - zatwierdzenie spisu zdawczo odbiorczego zawierającego nową wersję sprawy:


6a. Użytkownik ponownie uruchamia akcję wczytania (poprawionego pozasystemowo) pliku csv.

7a. System wyświetla listę spraw dla danego spisu zdawczo odbiorczego

8a. W przypadku braku błędów użytkownik zatwierdza spis zdawczo-odbiorczy

PA 2 – zatwierdzanie spisu zdawczo – odbiorczego (po usunięciu całego spisu, a następnie ponownym wczytaniu poprawnego pliku csv)

6a. Użytkownik na liście spisów zdawczo – odbiorczych usuwa spis zdawczo –odbiorczy w statusie roboczym

7a. Użytkownik dodaje nowy spis zdawczo – odbiorczy

8a. Użytkownik uruchamia akcję wczytania poprawionego pliku ze spisem zdawczo – odbiorczym (plik poprawiony poza systemem CAPE)

9a. System wyświetla listę spraw dla danego spisu zdawczo odbiorczego

10a. W przypadku braku błędów użytkownik zatwierdza spis zdawczo-odbiorczy

PA 3 – zatwierdzenie spisu zdawczo odbiorczego zawierającego nową wersję sprawy

9a System zapisuje sprawę (pobraną z taką samą sygnaturą) w wyższej wersji.

UC.P.003 Utworzenie protokołu brakowania

Przypadek użycia dla funkcjonalności tworzenia protokołu brakowania.


Zalogowany do systemu Archiwista dysponujący odpowiednimi uprawnieniami

Wynik końcowy:

Utworzony protokół brakowania

Reguły:

PG - utworzenie protokołu brakowania:

2. Użytkownik wybiera opcję tworzenia protokołu brakowania

3. Użytkownik wybiera wydział

4. Użytkownik wprowadza numer zarządzenia Prezesa Sądu dot. brakowania spraw5. System wyświetla listę spraw danego wydziału, które mają przekroczony czas retencji

6. Użytkownik określa przekroczenie czasu archiwizacji


7. Użytkownik wybiera sprawy do brakowania

8. Użytkownik dodaje przewodniczącego i członków komisji ds. brakowania.

PA1 - zmiana członków komisji brakowania:

2-7a1. Użytkownik dodaje/usuwa członka komisji ds. brakowania.

2-7a2. Użytkownik zapisuje zmiany.

UC.P.004 Decyzja w sprawie protokołu brakowania

Przypadek użycia dla funkcjonalności akceptacji protokołu brakowania przez członka komisji ds. brakowania.


Zalogowany Członek komisji ds. brakowania, który w ramach sprawy uzyskał uprawnienie do akceptacji protokołu

Wynik końcowy:

Zaakceptowany protokół brakowania.

Reguły:

R2. Zaakceptowanie protokołu brakowania przez wszystkich członków komisji powoduje zmianę jego statusu na „Zaakceptowany”.

R3. Na etapie akceptowania protokołu przez członków komisji możliwa jest zmiana kategorii akt sprawy.

R3.1. Reguła nie dotyczy akt kategorii A.

PG - akceptacja protokołu brakowania:

2. Użytkownik przegląda listę spraw do brakowania

3. Użytkownik akceptuje listę brakowania

UC.P.005 Zatwierdzenie protokołu brakowania


Po zaakceptowaniu protokołu brakowania przez członków komisji ds. brakowania użytkownik ma możliwość ostatecznego zatwierdzenia tego protokołu i uruchomienia tym samym procesu brakowania spraw.


Uzyskanie poza systemowej zgody z Archiwum Państwowego na brakowanie akt.

Zalogowany do systemu Archiwista posiadający uprawnienia do zatwierdzania protokołu brakowania

Wynik końcowy:

Zatwierdzony protokół brakowania

Reguły:

R2. Aby zatwierdzić protokół brakowania, protokół musi:

R2.1. Być w statusie ‘Zaakceptowany’,

R2.2. Mieć uzupełnione pola dotyczące zgody AP.

PG - zatwierdzenie protokołu brakowania:

2. Użytkownik wybiera opcję zatwierdzenia protokołu.

3. System prosi użytkownika o potwierdzenie chęci brakowania spraw.

4. Użytkownik potwierdza chęć brakowania spraw.

5. System uruchamia proces brakowania spraw, pliki są trwale usuwane z systemu.

UC.P.006 Generowanie raportu

Generowanie raportów i statystyk dot. udostępniania danych, brakowania oraz przechowywania akt spraw.


Zalogowany do systemu Archiwista posiadający uprawnienia do generowania poszczególnych raportów

Wynik końcowy:

Wygenerowany raport

PG - generowanie raportu:


2. Użytkownik wybiera raport, który chce wygenerować

3. Użytkownik określa parametry raportu

4. Użytkownik uruchamia funkcję generowania raportu

5. System generuje raport

UC.P.007 Wyszukanie sprawy

Wyszukiwanie będzie odbywało się na poziomie sprawy.

W ramach wyszukiwania będzie dostęp do metadanych sprawy jak i metadanych dokumentów wybranych spraw.


Zalogowany użytkownik systemu posiadający uprawnienia do wyszukiwania wybranych spraw

Wynik końcowy:

Wyszukana sprawa spełniająca kryteria wyszukiwania z uwzględnieniem uprawnień użytkownika do zasobu.

Reguły:

R1.1. Wyszukiwanie podstawowe odbywa się dla pola Sygnatura

R2. Dla opcji wyszukiwania zaawansowanego możliwe to wyboru parametry wyszukiwania to:

Sygnatura – identyfikator sprawy Oznaczenie teczki – oznaczenie stron sprawy, kto przeciw komu Sąd – nazwa sądu (wytwórcy akt) Wydział – nazwa wydziału (wytwórcy akt) Kategoria akt – kategoria archiwalna dokumentów ewidencjonowanych ze względu na długość

ich przechowywania Data rozpoczęcia sprawy Data zakończenia sprawy Numer spisu zdawczo – odbiorczego Czy akta reprezentacyjne Status: Zarchiwizowana, Zaakceptowana do brakowania, Zaakceptowana do przekazania do AP,

Zbrakowana, Przekazana do AP, Wycofana

PG - wyszukanie sprawy:

2. Użytkownik w oknie wyszukiwania wprowadza szukaną frazę.


3. Użytkownik uruchamia funkcję wyszukiwania.

4. System zwraca wyniki spełniające zadane kryterium wyszukiwania.

PA1 - zaawansowane wyszukanie sprawy:

2a1. Użytkownik określa parametry wyszukiwania:

2a2. Powrót do kroku 3 PG.

PA2 - dodanie zapytania do listy swoich zapytań:

3-6a1. System dodaje zapytanie do listy zapytań danego użytkownika.

PA3 - wyszukanie sprawy z wykorzystaniem listy zapytań:

2-3a1. Użytkownik wybiera z listy zapytanie i uruchamia funkcję wyszukiwania.

2-3a2. Powrót do kroku 4 PG.

PA4 – usunięcie zapytania z listy ulubionych zapytań

2a. Użytkownik rozwija liste ulubionych zapytań

3a. Użytkownik usuwa wybrane zapytanie z listy ulubionych

UC.P.008 Przeglądanie sprawy

Przypadek opisuje przeglądanie szczegółów sprawy oraz dokumentów w sprawie. Przypadek alternatywny opisuje edycję sprawy w zakresie zmiany kategorii sprawy i oznazcenia akt jako reprezentacyjne.


Zalogowany użytkownik systemu posiadający uprawnienia do przeglądania wybranych spraw

Wynik końcowy:

Obejrzane szczegóły oraz dokumenty sprawy. Dla przypadku alternatywnego zmieniona kategoria akt i oznaczenie akt sprawy jako reprezentacyjne.

Reguły:


R1. Przeglądanie sprawy będzie dotyczyło tylko metadanych sprawy i metadanych jej dokumentów.R2. Dla użytkownika posiadającego odpowiednie uprawnienia pola: kategoria i akta reprezentacyjne są edytowalne..

R2.1. Reguła nie dotyczy akt kategorii A.

PG - przeglądanie sprawy:

2. System wyświetla ekran ze szczegółami sprawy.

PA1 – edycja sprawy

3a. Użytkownik uruchamia tryb edycji dla pól które może edytować (kategoria sprawy, oznaczenie akt reprezentacyjnych)

4a. Użytkownik zmienia wartości w polach: kategoria sprawy, akta reprezentacyjne

5a. Użytkownik zapisuje zmiany

UC.P.009 Utworzenie protokołu przekazania do AP

Przypadek użycia dla funkcjonalności tworzenia protokołu przekazania akt do AP.


Zalogowany do systemu Archiwista dysponujący odpowiednimi uprawnieniami

Wynik końcowy:

Utworzony protokół

Reguły:

PG - utworzenie protokołu przekazania do AP:

2. Użytkownik wybiera opcję tworzenia protokołu przekazania do AP

3. Użytkownik wybiera wydział

6. Użytkownik wybiera sprawy do przekazania do AP

7. Użytkownik zatwierdza protokół

8. System automatycznie tworzy zamówienie na sprawy do przekazania do AP


UC.P.010 Zatwierdzenie protokołu przekazania do AP

Przypadek użycia dla funkcjonalności przekazania akt do AP.


Uzyskanie poza systemowej zgody z Archiwum Państwowego na przekazanie akt.

Zalogowany do systemu Archiwista posiadający uprawnienia do zatwierdzania protokołu przekazania

Wynik końcowy:

Zatwierdzony protokół przekazania

Reguły:

R2. Aby zatwierdzić protokół przekazania do AP, protokół musi:

R2.1. Być w statusie ‘Zaakceptowany’,

R2.2. Mieć uzupełnione pola dotyczące zgody AP.

PG - zatwierdzenie protokołu przekazania do AP:

2. Użytkownik wybiera opcję zatwierdzenia protokołu.

3. System prosi użytkownika o potwierdzenie.

4. Użytkownik potwierdza chęć zatwierdzenia protokołu przekazania.

5. System uruchamia proces usuwania spraw, pliki są trwale usuwane z systemu.


6.3.1 Diagram stanów dla brakowania/przekazania do APRysunek 15: Diagram stanów dla brakowania/przekazania do AP

stm Diagramy stanów dla brakowania/przekazania do AP

Roboczy Zaakceptowany Zatwierdzony

Zakończony

Przejście "na żądanie" oznacza zmianę statusu protokołu, dokonaną przez Archiwistę.

pozasystemowa akceptacja Archiwum Państwowego

Akceptacja wszystkich członków komisji ds. brakowania (w przypadku protokołu brakowania)Zatwierdzenie protokołu i automatyczne utworzenie paczki przekazania do AP (w przypadku protokołu przekazania do AP)

po usunięciu paczek z systemu następuje automatyczna zmiana statusu protokołu na 'Zakończony'

Protokół wraca z uwagami z AP

[na żądanie]

[automatycznie]

[na żądanie]


6.3.2 Diagram stanów dla sprawyRysunek 16: Diagram stanów dla sprawy

stm Diagramy stanów dla sprawy

Start Stop

Zarchiwizowana Zbrakowana

Przekazana do AP

Wycofana

Po akceptacji przez członków ds. brakowania, ale przed uzyskaniem potwierdzenia z AP. Sprawy w tym statusie nie podlegają procesowi zamównień.

Stopzmiana stanu na skutek pobrania do systemu CAPE nowej wersji sprawy z tą samą sygnaturą, co sprawa zarejestrowana w systemie ze statusem 'Wycofana'

Zaakceptowana do brakowania

Status zmieniany na skutek zakończenia procesu brakowania danej sprawy

Zaakceptowana do przekazania do AP

Status zmieniany na skutek zakończenia procesu przekazania danej sprawy do AP

[automatycznie][automatycznie]

[automatycznie]


6.3.3 Diagram stanów dla zamówieniaRysunek 17: Diagram stanów dla zamówienia

stm Diagramy stanów dla zamównienia

Zamównie akt lubzamównie akt dowycofania

Stop

W przygotowaniu

W realizacj i

Zrealizowane

Przejście "na żądanie" oznacza zmianę statusu zamównienia, dokonaną przez Pracownika Sekretariatu. Przejście "automatycznie" oznacza zmianę statusu bez ingerencji użytkownika.

automatyczna zmiana statusu zamównienia w momencie wysłania informacji do zamawiającego

Wysłanie zamównienia przez Pracownika Sekretariatu do realizacji. W pzypadku automatyczne utworzenia zamówienie (w procesie przekazania do AP) zmiana stanu jest automatyczna.

Odrzucone

Stop

dotyczy tylko zamówieńpochodzących z ePUAP

[automatycznie]

[na żądanie]

[na żądanie]


6.4 Przypadki użycia – PUiA

Rysunek 18: Podsystem Uwierzytelniania i Autoryzacjiuc DUC-002 Podsystem Uwierzytelniania i Autoryzacj i

Podsystem Uwierzytelniania i Autoryzacji

Name: DUC-002 Podsystem Uwierzytelniania i AutoryzacjiAuthor: Ewa.MiazgaVersion: 1.0Created: 2015-08-17 09:17:34Updated: 2015-09-09 15:44:09

UC.PUiA.001 Założenie konta

domenowego

UC.PUiA.002 Logow anie

użytkow nika do systemu

A.05 Administrator

(from Aktorzy)


(from Aktorzy)

UC.PUiA.004 Zarządzanie rolami

UC.PUiA.005 Zarządzanie grupami

użytkow ników

UC.PUiA.007 Edytowanie konta

UC.PUiA.003 Zarządzanie

uprawnieniami

UC.PUiA.006 Zarządzanie

przypisaniami użytkownika

UC.PUiA.008 Zarządzanie słownikami

UC.PUiA.009 Przeglądanie historii

operacj i

UC.PUiA.010 Zarządzanie polityką

haseł

UC.PUiA.011 Zmiana hasła

UC.PUiA.012 Resetowanie hasła

UC.PUiA.013 Założenie konta

lokalnego

«extend»

UC.PUiA.001 Założenie konta domenowego

Administrator systemu ma możliwość utworzenia w Systemie nowego konta dla użytkownika posiadającego konto w Active Directory.




Wynik końcowy:

Utworzone nowe konto domenowe użytkownika w systemie.

PG - założenie konta domenowego:

2. System wyświetla formularz rejestracji użytkownika.

3. Administrator systemu wprowadza wymagane dane użytkownika i zatwierdza.

4. System stwierdza, że wszystkie obowiązkowe pola są uzupełnione.

5. System stwierdza, że użytkownik ma konto w Active Directory

6. System stwierdza, że użytkownik nie ma jeszcze konta w systemie

7. System importuje dane z Active Directory i wyświetla je na formularzu

8. Administrator uzupełnia pola do wprowadzenia danych dodatkowych użytkownika

9. Administrator potwierdza wprowadzone dane

10. System tworzy nowe konto użytkownika.

11. System nadaje użytkownikowi rolę domyślną.

PA1 - brak uzupełnienia pól obowiązkowych:

4a1. System wyświetla informację o konieczności uzupełnienia wszystkich wymaganych pól

4a2. Powrót do kroku 3 PG

PW1 – brak konta użytkownika w Active Directory:

5-11a1. System wyświetla informację o braku możliwości założenia konta użytkownika

PW2 – konto użytkownika już istnieje w systemie:

6-11a1. System wyświetla informację, że użytkownik już posiada konto w systemie

UC.PUiA.002 Logowanie użytkownika do systemu


System umożliwia użytkownikowi zalogowanie się do systemu. Po zalogowaniu, użytkownik ma dostęp do funkcjonalności systemu


Użytkownik posiada aktualne konto w systemie CAPE.

Wynik końcowy:

Użytkownik został zalogowany do systemu.

PG - logowanie do systemu:

2. System wyświetla okno logowania

3. Użytkownik podaje login, hasło i potwierdza wprowadzenie danych.

4. System stwierdza, że wprowadzone dane są poprawne.

5. System loguje użytkownika.

PA1 - brak dostępu do systemu:

4a1. System wyświetla informację o braku dostępu do systemu.


PA2 - żądanie zmiany hasła przez System:

4-5a1. Wywołanie przebiegu alternatywnego PA1 dla przypadku UC.PUiA.011 Zmiana hasła.

PW1- czasowa blokada konta:

Użytkownik powtarza dwukrotnie kroki 1-5b

4-5b1. System wyświetla informację o braku dostępu do systemu i czasowym (określone parametrem) zablokowaniu konta użytkownika.

UC.PUiA.003 Zarządzanie uprawnieniami

Administrator systemu ma możliwość zarządzania uprawnieniami w systemie. W ramach zarządzania uprawnieniami Administrator może dodawać, modyfikować i usuwać uprawnienia.




Wynik końcowy:

Zostało zdefiniowane nowe uprawnienie lub istniejące już uprawnienie zostało zmodyfikowane lub usunięte.

Reguły:

PG - dodanie nowego uprawnienia:

2. Administrator systemu wybiera opcję dodania uprawnienia.

3. System wyświetla ekran do zdefiniowania uprawnienia.

4. Administrator systemu podaje nazwę i opis nowego uprawnienia.

5. Administrator systemu zapisuje uprawnienie.

PA1 - edycja uprawnienia:

2-4a1. System wyświetla ekran do modyfikacji uprawnienia.

2-4a2. Administrator systemu edytuje nazwę i opis uprawnienia.

PA2 - usunięcie uprawnienia:

2-5a1. System wyświetla komunikat z prośbą o potwierdzenie chęci usunięcia uprawnienia.

2-5a2. Administrator systemu potwierdza chęć usunięcia uprawnienia.

2-5a3. System usuwa uprawnienie.

UC.PUiA.004 Zarządzanie rolami

Administrator systemu ma możliwość zarządzania rolami w systemie. W ramach zarządzania rolami Administrator może dodawać, modyfikować i usuwać role.



Wynik końcowy:

Została zdefiniowana nowa rola lub istniejąca już rola została zmodyfikowana lub usunięta. Przypisano lub odłączono uprawnienia do/od roli.

Reguły:

PG - dodanie nowej roli:

2. Administrator systemu wybiera opcję dodania roli.


3. System wyświetla ekran do zdefiniowania roli.

4. Administrator systemu podaje nazwę i opis nowej roli.

5. Administrator systemu zapisuje rolę.

PA1 - zmiana zakresu uprawnień dla roli:

2-4a1. System wyświetla ekran do zmodyfikowania roli.

2-4a2. Administrator systemu przechodzi do listy dostępnych uprawnień.

2-4a3. Administrator systemu przyłącza lub odłącza uprawnienia.

PA2 - przypisanie grupy użytkowników do roli:


2-4a2. Administrator systemu przechodzi do listy dostępnych grup użytkowników.

2-4a3. Administrator systemu przyłącza lub odłącza grupę użytkowników.

PA3 - edycja roli:


2-4a2. Administrator systemu edytuje nazwę i opis nowej roli.

PA4 - usunięcie roli:

2-5a1. System wyświetla komunikat z prośbą o potwierdzenie chęci usunięcia roli.

2-5a2. Administrator systemu potwierdza chęć usunięcia roli.

2-5a3. System usuwa rolę.

UC.PUiA.005 Zarządzanie grupami użytkowników

Administrator systemu ma możliwość zarządzania grupami użytkowników w systemie. W ramach zarządzania grupami użytkowników Administrator może dodawać, modyfikować i usuwać grupy.


Zalogowany Administrator dysponujący odpowiednimi uprawnieniami.

Wynik końcowy:


Powstała nowa grupa użytkowników lub istniejąca już grupa użytkowników została zmodyfikowana lub usunięta. Nadano lub odebrano role grupie. Przypisano lub odłączono użytkownika do/od istniejącej grupy.

Reguły:

PG - dodanie nowej grupy użytkowników:

2. Administrator systemu wybiera opcję dodania grupy użytkowników.

3. System wyświetla ekran do zdefiniowania grupy użytkowników

4. Administrator systemu podaje nazwę i opis nowej grupy.

5. Administrator systemu zapisuje grupę.

PA1 - przypisanie użytkowników do grupy:

2-6a1. System wyświetla ekran do modyfikacji grupy użytkowników.

2-6a2. Administrator systemu przechodzi do listy użytkowników.

2-6a3. Administrator systemu przypisuje lub odłącza użytkowników od grupy.

PA2 - przypisanie ról do grupy:

2-6a1. System wyświetla ekran do modyfikacji grupy użytkowników.

2-6a2. Administrator systemu przechodzi do listy ról.

2-6a3. Administrator systemu przypisuje lub odłącza role od grupy.

PA3 - edycja grupy użytkowników:

2-4a1. System wyświetla ekran do modyfikacji grupy.

2-4a2. Administrator systemu edytuje nazwę i opis grupy.

PA4 - usunięcie grupy użytkowników:

2-5b1. System wyświetla komunikat z prośbą o potwierdzenie chęci usunięcia grupy.


2-5b2. Administrator systemu potwierdza chęć usunięcia grupy.

2-5b3. System usuwa grupę użytkowników.

UC.PUiA.006 Zarządzanie przypisaniami użytkownika

Administrator systemu ma możliwość przypisania roli lub grupy użytkowników do danego użytkownika systemu.



Wynik końcowy:

Użytkownikowi zostały nadane lub odebrane role. Użytkownik został przypisany lub odłączony do/od grupy użytkowników.

PG - przeglądanie szczegółów przypisań użytkownika:

2. Administrator przechodzi do szczegółów danego użytkownika.

3. Administrator przechodzi do listy ról użytkownika

4. Administrator przechodzi do listy grup użytkownika.

PA1 - przydzielenie roli do użytkownika:

3a1. System wyświetla listę dostępnych ról.

3a2. Administrator systemu wskazuje role, które chce przydzielić użytkownikowi.

3a3. Administrator systemu potwierdza przydzielenie ról użytkownikowi.

3a4. System wyświetla wybrane role na liście ról przydzielonych użytkownikowi.

PA2 - odłączenie roli od użytkownika:

3a1. Administrator systemu potwierdza odłączenie roli od użytkownika.

PA3 - przypisanie użytkownika do grupy:

4a1. System wyświetla listę dostępnych grup.

4a2. Administrator systemu wskazuje grupy, do których chce przypisać użytkownika.

4a3. Administrator systemu potwierdza przypisanie użytkownika do grup.

4a4. System wyświetla wybrane grupy na liście grup użytkownika.


PA4 - odłączenie grupy od użytkownika:

3a1. Administrator systemu potwierdza odłączenie użytkownika od grupy użytkowników.

UC.PUiA.007 Edytowanie konta

Użytkownik systemu ma możliwość zmiany danych w koncie.


Użytkownik zalogowany do systemu.

Wynik końcowy:

Dane w koncie użytkownika zostały zmienione.

PG - edycja danych w koncie:

2. System wyświetla ekran edycji danych użytkownika.

3. Użytkownik modyfikuje dostępne dane.

4. Użytkownik potwierdza zmianę danych.

UC.PUiA.008 Zarządzanie słownikami

W ramach zarządzania słownikami istnieje możliwość dodawania, edycji i usuwania pozycji słownikowych dla zdefiniowanych słowników.


Użytkownik posiada uprawnienia do zarządzania słownikami

Wynik końcowy:

Dodana/zmodyfikowana/usunięta pozycja słownikowa

PG - dodawanie pozycji słownikowej:

2. Użytkownik wybiera słownik, w ramach którego chce dodać pozycję słownikową.

3. System wyświetla ekran do dodania pozycji słownikowej

4. Użytkownik dodaje pozycję słownikową (adekwatnie do właściwości danego słownika)

5. Użytkownik zapisuje nową pozycję słownikową

PA1 - edycja pozycji słownikowej:


2. Użytkownik wybiera słownik, w ramach którego chce zmodyfikować pozycję słownikową

3. Użytkownik wybiera pozycję słownikową, którą chce zmodyfikować

4. Użytkownik uruchamia tryb edycji

5. Użytkownik modyfikuje pozycję słownikową

6. Użytkownik zapisuje zmiany

PA2 - usuwanie pozycji słownikowej:

2. Użytkownik wybiera słownik, w ramach którego chce usunąć pozycję słownikową

3. Użytkownik wybiera pozycję słownikową, którą chce ałącz

4. Użytkownik uruchamia funkcję usuwania

5. System wyświetla komunikat z prośba o potwierdzenie usunięcia pozycji słownikowej

6. Użytkownik potwierdza chęć usunięcia pozycji słownikowej

7. System bezpowrotnie usuwa pozycję słownikową

UC.PUiA.009 Przeglądanie historii operacji

Użytkownik systemu ma możliwość przeglądania historii wszystkich wykonanych przez siebie operacji.


Użytkownik zalogowany do systemu.

Wynik końcowy:

Widoczna lista operacji użytkownika

Reguły:

R2. Użytkownik posiadający stosowne uprawnienia będzie miał możliwość przeglądania operacji innych użytkowników.

PG - przeglądanie historii operacji:

5. System wyświetla ekran prezentujący zarejestrowane operacje wykonane przez użytkownika.

UC.PUiA.010 Zarządzanie polityką haseł


Administrator ma możliwość określenia dla kont lokalnych minimalnej długości hasła liczonej w znakach oraz może wymusić, aby hasło zawierało znaki specjalne.



Wynik końcowy:

Ustawiono nowe parametry dla siły hasła.

Reguły:

R2. Jeżeli siła hasła jest niewystarczająca w momencie logowania system wymusza zmianę hasła.

R3. Znaki specjalne to: ! @ # $ % ^ & * ( ) _ + = - [ ] ; : ” ’ < > \ | ?

R4. Polityka haseł definiowana w CAPE dotyczy wyłącznie kont lokalnych.

PG - definiowanie polityki haseł :

2. Administrator podaje minimalną długość znaków, jaka ma obowiązywać dla hasła.

3. Opcjonalnie administrator zaznacza parametr wymuszający umieszczenie znaków specjalnych w haśle.

4. Opcjonalnie administrator zaznacza parametr wymuszający umieszczenie cyfr w haśle.

5. Opcjonalnie administrator podaje czas życia hasła (czas ważności hasła) w dniach.

6. Opcjonalnie administrator podaje liczbę haseł do zapamiętania w historii haseł

7. Administrator zapisuje zmiany.

UC.PUiA.011 Zmiana hasła

System umożliwia użytkownikowi konta lokalnego zmianę hasła na nowe. System wymusi przeprowadzenie takiej zmiany w przypadku, gdy: upłynął termin ważności hasła, hasło nie spełnia wymogów na siłę hasła, hasło zostało zresetowane lub użytkownik dokonuje pierwszego logowania na konto lokalne.


Użytkownik wywołał opcję zmiany hasła. Upłynął termin ważności hasła. Hasło nie spełnia wymogów na siłę hasła. Użytkownik zalogował się za pomocą hasła jednorazowego.

Wynik końcowy:

Hasło użytkownika zostało zmienione. Użytkownik może się zalogować do systemu przy użyciu nowego hasła.


Reguły:

- wygasł termin ważności hasła,

- hasło nie spełnia wymogów na siłę hasła,

- hasło zostało zresetowane,

- użytkownik dokonuje pierwszego logowania na konto lokalne.

R2. Użytkownik musi dwukrotnie podać nowe hasło.

R3. System sprawdza zgodność nowego hasła z regułami dla siły hasła.

R4. System prosi użytkownika o ustanowienie nowego hasła do momentu, kiedy zostaną spełnione warunki na siłę hasła. Jedynie prawidłowa zmiana hasła daje użytkownikowi dostęp do systemu.

R5. Przypadek dotyczy wyłącznie kont lokalnych CAPE.

PG - zmiana hasła przez użytkownika :

2. System wyświetla formularz do wprowadzenia nowego hasła (dwukrotnie).

3. Użytkownik wprowadza nowe hasło i zatwierdza.

4. System stwierdza, że wprowadzone dwa hasła są zgodne.

5. System stwierdza, że hasło spełnia wymogi dla siły hasła.

6. System ustawia nowe hasło dla użytkownika i zalogowuje użytkownika.

PA1 – żądanie zmiany hasła przez system :


PA2 - niezgodność haseł :

4a1. System wyświetla informację o niezgodności wprowadzonych haseł.


PA3 - niewystarczająca siła hasła :

5a1. System wyświetla informację o niewystarczającej sile hasła.



UC.PUiA.012 Resetowanie hasła

System daje użytkownikom kont lokalnych możliwość ustanowienia nowego hasła w przypadku potrzeby dokonania zmiany.


Użytkownik nie pamięta hasła lub zaistniały przesłanki do zmiany hasła.

Wynik końcowy:

Utworzone nowe hasło dla użytkownika konta lokalnego.

Reguły:

R2. Przypadek dotyczy wyłącznie kont lokalnych CAPE.

PG - zresetowanie hasła użytkownika :

2. System wyświetla formularz do wprowadzenia loginu użytkownika oraz adresu e-mail.

3. System stwierdza, że wprowadzone dane są poprawne.

4. System zmienia użytkownikowi dotychczasowe hasło na wygenerowane hasło jednorazowe.

5. System wysyła na podany adres e-mail wiadomość z hasłem jednorazowym.

PW1 - brak możliwości zresetowania hasła :

3a1. System informuje użytkownika o braku możliwości zresetowania hasła.


UC.PUiA.013 Założenie konta lokalnego

Opis:

Administrator systemu ma możliwość utworzenia w CAPE nowego konta lokalnego dla użytkownika, który nie posiada konta w Active Directory.



Wynik końcowy:


Utworzone nowe konto użytkownika w systemie.

PG - założenie konta lokalnego :

2. System wyświetla formularz rejestracji użytkownika.

3. Administrator systemu wprowadza wymagane dane użytkownika.

4. Administrator uzupełnia pola do wprowadzenia danych dodatkowych użytkownika

5. Administrator potwierdza wprowadzone dane

6. System stwierdza, że wszystkie obowiązkowe pola są uzupełnione.

7. System stwierdza, że użytkownik nie ma jeszcze konta w systemie

8. System tworzy nowe konto użytkownika.

9. System nadaje użytkownikowi rolę domyślną.

10. System na podany przy rejestracji adres e-mail wysyła wiadomość informującą o założeniu konta.

PA1 - brak uzupełnienia pól obowiązkowych :

6a1. System wyświetla informację o konieczności uzupełnienia wszystkich wymaganych pól


PW1 – konto użytkownika już istnieje w systemie :

7-10a1. System wyświetla informację, że użytkownik już posiada konto w systemie


6.5 Przypadki użycia – PPD

Rysunek 19: Retencja danychuc Retencja Danych

PPD

A.06 JobManager

(from Aktorzy)

UC.PPD.001 Wskazanie paczek

podlegających retencj i

UC.PPD.002 Usunięcie paczek

podlegających retencj i

«include»

UC.PPD.001 Wskazanie paczek podlegających retencji

Proces systemowy JobManager cyklicznie wyszukuje sprawy podlegające retencji zgodnie z ustawionym czasem przechowywania paczki na macierzy dyskowej.


Uruchomiony proces JobManager.

Wynik końcowy:

Lista paczek z macierzy dyskowej, które podlegają retencji.

PG:

2. JobManager wyszukuje paczki podlegające retencji

3. Realizacja włączanego przypadku użycia UC.PPD.002 Usunięcie paczek podlegających retencji

UC.PPD.002 Usunięcie paczek podlegających retencji

Proces usuwa wskazane paczki z macierzy dyskowej.


Lista paczek podlegające retencji.

Wynik końcowy:

Usunięcie paczek, które podlegają retencji.


PG:

6. Proces zapisuje w rejestrze zdarzeń listę usuniętych paczek wraz z informacjami o czasie wykonania, dacie dodania paczki i wartości czasu retencji.


7 Architektura logiczna Systemu

7.1 Architektura Systemu

Rysunek 20: Architektura systemucmp 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

CRCS

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

Centralne AD

RCS

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

RCS Agent Server

Moduł 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 Storage


Centralny 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 Manager

Realizowane 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

Urządzenia archiwizującego;

Macierzy dyskowej;

Biblioteki taśmowej;

Podsystem Uwierzytelniania i Autoryzacji

Portal



7.2 Agent Rysunek 21: Komunikacja Agenta z CAPE

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

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 Server

Moduł 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 Storage

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


7.3 Podsystem Przechowywania Danych Rysunek 22: 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 Archiw um::Job

Manager

System Zarządzania Archiw um::Tape

Manager

Macierz dyskow a Biblioteka taśmow a

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

PPD przechowuje i zarządza danymi w systemie CAPE.

Biblioteka taśmowa

Macierz dyskowa

Swift Proxy

TSM

account

container

memcached

object


7.4 Podsystem Uwierzytelnienia i Autoryzacji Rysunek 23: Podsystem Uwierzytelniania 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

CAS

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

CSUiA

DM

ER

7.5 Portal Rysunek 24: Portal

Core

RiS

Web


7.6 System Zarządzania Archiwum Rysunek 25: System Zarządzania Archiwum

cmp DCO-004 System Zarządzania Archiwum


Interfejs REST API

Interfej s Administratora

Rzdzeń aplikacj i

Job ManagerZarządzanie metadanymi

Tape Manager Podsystem Przechow yw ania

Danych::TSM

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

Podsystem Przechow yw ania

Danych::Sw ift 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

Interfejs Administratora

Interfejs REST API

Job Manager

Rdzeń aplikacji

Tape Manager

Zarządzanie metadanymi


7.7 Interfejsy zewnętrzne

7.7.1 Integracja z systemem ePUAPCAPE umożliwia zamawianie elementów spraw poprzez system ePUAP. Komunikacja z systemem ePUAP odbywa się poprzez webserwisy WS-Skrytka (nadawanie dokumentów do ePUAP) oraz WS-Odbiorca (odbieranie dokumentów z ePUAP)

Opis interfejsu WS-Skrytka znajduje i się pod linkiem:

http://epuap.gov.pl/wps/wcm/connect/9d225db4-3ddf-4653-a52b-20ed2de40259/Dokumentacja+us%C5%82ug+%28wersja+beta%29.pdf?MOD=AJPERES

Służy do przesyłania dokumentów na skrytkę. Usługa zawiera dwie operacje: nadaj oraz nadajAny. W systemie CAPE wykorzystywana jest operacja nadaj, która umożliwia wysłanie o systemu ePUAP odpowiedzi w przypadkach: skompletowania, akceptacji oraz odrzucenia zamówienia złożonego poprzez system ePUAP.

Odbieranie dokumentów z systemu ePUAP odbywa się poprzez interfejs WS-Odbiorca. Usługa znajduje się pod adresem: http://cape.wroclaw.sa.gov.pl/epuap-external-ws/OdbiorcaImpl, natomiast adres wsdl: http://cape.wroclaw.sa.gov.pl/epuap-external-ws/OdbiorcaImpl?wsdl

INTERFEJS WS-ODBIORCA

Umożliwia odebranie dokumentu, wysłanego z systemu ePUAP.

Operacja wyslij – służy do odbierania dokumentu xml z systemu ePUAP.O Parametry operacji wyślij:

danePodmoitu – dane podmiotu nadawcy daneNadawcy – dane użytkownika który wysyła dokument. dataNadania – data nadania dokumentu przez system ePUAP nazwaSkrytki – nazwa skrytki która wysłała dokument adresSkrytki – adres skrytki z którego został nadany dokument adresOdpowiedzi – adres odpowiedzi dla odebranego dokumentu czyTestowe – parametr określa czy jest to test wysłania. daneDodatkowe – dane dodatkowe w formacie XML dokument – wysłany dokument

Operacja wyslijAny – operacja nie jest obsługiwana w CAPE. Proba nadania przy użyciu tej operacji, zakończy się wyjątkiem usługi.

Parametry odpowiedzi usługi WS-Odbiorca:

status – kod i komunikat opisujący wynik działania usługi. załącznik – ewentualny załącznik do odpowiedzi – nie używany w CAPE.

7.7.2 Komunikacja Agent – SZAZałożenia do sposobu komunikacji Agent <-> CAPE:


http://cape.wroclaw.sa.gov.pl/epuap-external-ws/OdbiorcaImpl?wsdl

http://cape.wroclaw.sa.gov.pl/epuap-external-ws/OdbiorcaImpl

http://epuap.gov.pl/wps/wcm/connect/9d225db4-3ddf-4653-a52b-20ed2de40259/Dokumentacja+us%C5%82ug+(wersja+beta).pdf?MOD=AJPERES

http://epuap.gov.pl/wps/wcm/connect/9d225db4-3ddf-4653-a52b-20ed2de40259/Dokumentacja+us%C5%82ug+(wersja+beta).pdf?MOD=AJPERES

1. Cała komunikacja będzie się odbywała wyłącznie poprzez zasób SCP Storage. Strukturę tego zasobu zaprezentowano poniżej:

W zasobie tym będą odpowiednie podkatalogi określające kierunek przesyłania paczek. Dodatkowo każda apelacja zostanie oddzielona odpowiednim podkatalogiem określającym jej kod.

Kod Nazwa sądu, jednostki zamiejscowej, komórki

15 05 00 00 Sąd Apelacyjny w Białymstoku

15 10 00 00 Sąd Apelacyjny w Gdańsku

15 15 00 00 Sąd Apelacyjny w Katowicach

15 20 00 00 Sąd Apelacyjny w Krakowie

15 25 00 00 Sąd Apelacyjny w Łodzi

15 35 00 00 Sąd Apelacyjny w Poznaniu

15 30 00 00 Sąd Apelacyjny w Lublinie

15 40 00 00 Sąd Apelacyjny w Rzeszowie

15 50 00 00 Sąd Apelacyjny we Wrocławiu

15 45 00 00 Sąd Apelacyjny w Warszawie

15 55 00 00 Sąd Apelacyjny w Szczecinie

Agenty będą się łączyć przez SCP. Autoryzacja poprzez jedno wspólne konto dla wszystkich agentów.

1. Sesje przetwarzania Agenta realizowane są cyklicznie zgodnie z harmonogramem okien transferowych. Można założyć, że okno transferowego odbywa się raz dziennie w godzinach nocnych. Możliwy do rozważenia jest również wariant, w którym wybrane fazy sesji Agenta (np. te opisane w punktach 4a i 4b) odbywałyby się z większą częstotliwością.

2. Pojedyncza sesja Agenta składa się z następujących faz:a) Pobranie z SCP Storage/outgoing i przetworzenie potwierdzeń przetworzenia przez

CAPE paczki archiwalnej. Potwierdzenie jest plikiem XML zawierającym informacje identyfikujące paczkę, która została pobrana przez CAPE, oraz rezultat tego


przetworzenia: SUCCESS lub FAILURE. W przypadku FAILURE również informacja o przyczynach błędów, które wystąpiły przy weryfikacji bądź przetworzeniu paczki. Nazwa pliku z potwierdzeniem będzie postaci: nazwa_paczki_processed.xml.

b) Pobranie z SCP Storage/outgoing i przetworzenie potwierdzeń archiwizacji przez CAPE paczki archiwalnej. Potwierdzenie jest plikiem XML zawierającym informacje identyfikujące paczkę, która została pobrana przez CAPE. Nazwa pliku z potwierdzeniem będzie postaci: nazwa_paczki_archived.xml.

c) Wgranie do SCP Storage/incoming paczek archiwalnych dla nowych bądź zmienionych spraw. Dodatkowo ponownie wgrywane są paczki archiwalne spraw, dla których w fazie a) stwierdzono rezultat FAILURE. Wraz z paczką wgrywany jest plik skrótu MD5 o nazwie postaci: nazwa_paczki.zip.md5. Plik zawiera sam MD5 hash.

d) Pobranie z SCP Storage/outgoing, weryfikacja i przekopiowanie do zasobu lokalnego paczek wystawionych przez CAPE w ramach pobierania z archiwum. Plik archiwum z paczką archiwalną powinien mieć taką samą nazwę jak paczka archiwalna, która została wysłana przez Agenta do CAPE. Wraz z paczką musi zostać wgrany przez CAPE plik skrótu MD5 o nazwie postaci: nazwa_paczki.zip.md5. Plik zawiera sam MD5 hash.

e) Wgranie do SCP Storage/incoming potwierdzeń pobrania paczki archiwalnej przez Agenta. Potwierdzenie jest plikiem XML zawierającym informacje identyfikujące paczkę, która została pobrana przez Agenta, oraz rezultat jej pobrania(weryfikacji): SUCCESS lub FAILURE. W przypadku FAILURE również informacja o przyczynach błędów, które wystąpiły przy pobieraniu(weryfikacji) paczki. Nazwa pliku z potwierdzeniem będzie postaci: nazwa_paczki_processed.xml.

3. Pojedyncza instancja Agenta będzie wgrywała dane wyłącznie do katalogu SCP Storage/incoming/wyróżnik_apelacji oznaczonego wyróżnikiem swojej apelacji, a ściślej rzecz ujmując – apelacji nadrzędnej w stosunku do sądu, w którym instancja Agenta jest uruchomiona. Pojedyncza instancja Agenta będzie pobierała dane wyłącznie z katalogu SCP Storage/outgoing/wyróżnik_apelacji oznaczonego wyróżnikiem swojej apelacji, a ściślej rzecz ujmując – apelacji nadrzędnej w stosunku do sądu, w którym instancja Agenta jest uruchomiona.

4. CAPE będzie pobierać dane ze wszystkich podkatalogów SCP Storage/incoming. CAPE będzie wrzucać paczkę lub plik z potwierdzeniem do odpowiedniego podkatalogu SCP Storage/outgoing/wyróżnik_apelacji, gdzie wyróżnik_apelacji jest prefiksem nazwy pliku archiwum zawierającego paczkę.


Poniżej przedstawiono proces przekazania do archiwum CAPE archiwalnej paczki sprawy. Proces jest inicjowany przez umieszczenie paczki przez Agenta w SCP Storage. Dalsza część procesu zawiera 2 fazy. W pierwszym etapie CAPE umieszcza w SCP Storage plik XML z potwierdzeniem (rezultatem) przetworzenia paczki. W drugim kroku CAPE umieszcza w SCP Storage plik XML z potwierdzeniem archiwizacji paczki.

sd Agent - Przebieg zasilenia CAPE

Pobranie z SCP Storage i przetworzenie potwierdzeń archiwizacji przez CAPE paczki archiwalnej

Pobranie z SCP Storage i przetworzenie potwierdzeń pobrania przez CAPE paczki archiwalnej

Wgranie do SCP Storage paczek archiwalnych

RCS Server RCS Agent Server SCP Storage CAPE

Collect case data()

<<return case data>>()

Create package(case data)

Put package & signature()

<<return>>()

Final ize(change name)

<<return>>()

Get package & MD5()

<<return & signature>>()

Process package & verify MD5()

Put process result()

<<return>>()

Remove package & MD5()

<<return>>()

Get process result()

<<return xml>>()

Remove process resul t()

<<return>>()

Extract data from process result(xml)

Archive package(package)

Put archiving resul t()

<<return>>()

Get archiving resul t()

<<return xml>>()

Remove archiving result()

<<return>>()

Extract data from archiving result(<<xml>>)


Poniżej przedstawiono proces pobrania z archiwum CAPE archiwalnej paczki sprawy. Proces jest inicjowany przez umieszczenie paczki przez CAPE w SCP Storage(co jest poprzedzone złożeniem zamówienia za pośrednictwem Portalu). Proces kończy się tym, że Agent umieszcza w SCP Storage plik XML z potwierdzeniem (rezultatem) pobrania paczki.

sd Agent - Pobranie sprawy z archiwum

Pobranie z SCP Storage, weryfikacja i przekopiowanie do zasobu lokalnego paczek wystawionych przez CAPE w ramach pobierania z archiwum

Wgranie do SCP Storage potwierdzeń pobrania paczki archiwalnej przez Agenta

Local Storage RCS Agent Server SCP Storage CAPEPortal

Request case()

Put package & MD5()

<<return>>()

Finalize(change name)

<<return>>()

Get package & MD5()

<<return package & MD5>>()

Verify MD5()

Send package()

<<return>>()

Put process result()

<<return>>()

Remove package()

<<return>>()

Get process result()

<<return xml>>()

Remove process result()

<<return>>()


Poniżej przedstawiono XML schema formalizujący budowę plików XML z potwierdzeniami przekazywanymi pomiędzy Agentem i CAPE.

<?xml version=”1.0” encoding=”UTF-8”?>

<xs:schema xmlns:xs=”http://www.w3.org/2001/XMLSchema” xmlns=”http://comarch.com/recourt/agent-types” targetNamespace=”http://comarch.com/recourt/agent-types” elementFormDefault=”qualified”>

<xs:annotation>

<xs:documentation>

Model definiuje struktury danych wykorzystywane przez Agenta

</xs:documentation>

</xs:annotation>

<xs:element name=”packageProcessingConfirmation”>

<xs:annotation>

<xs:documentation>Potwierdzenie przetworzenia paczki archiwalnej</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>

<xs:element name=”packageName” type=”xs:string” minOccurs=”1” maxOccurs=”1”>

<xs:annotation>

<xs:documentation>Nazwa paczki archiwalnej w formacie: CourtDiscriminant_CaseSignature_date_time</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name=”result” type=”ResultType” minOccurs=”1” maxOccurs=”1”>

<xs:annotation>

<xs:documentation>Wynik przetworzenia paczki archiwalnej</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name=”processingTime” type=”DateTime” minOccurs=”1” maxOccurs=”1”>

<xs:annotation>

<xs:documentation>Data i czas przetworzenia paczki</xs:documentation>

</xs:annotation>


</xs:element>

<xs:element name=”failureDescription” type=”xs:string” minOccurs=”0” maxOccurs=”1”>

<xs:annotation>

<xs:documentation>Opis błędów przetworzenia paczki archiwalnej</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name=”packageArchivingConfirmation”>

<xs:annotation>

<xs:documentation>Potwierdzenie archiwizacji paczki archiwalnej</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>

<xs:element name=”packageName” type=”xs:string” minOccurs=”1” maxOccurs=”1”>

<xs:annotation>

<xs:documentation>Nazwa paczki archiwalnej w formacie: CourtDiscriminant_CaseSignature_date_time</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name=”archivingTime” type=”DateTime” minOccurs=”1” maxOccurs=”1”>

<xs:annotation>

<xs:documentation>Data i czas archiwizacji sprawy</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>


<xs:simpleType name=”ResultType”>

<xs:restriction base=”xs:string”>

<xs:enumeration value=”SUCCESS”>

<xs:annotation>

<xs:documentation>Przetworzenie zakończone powodzeniem</xs:documentation>

</xs:annotation>

</xs:enumeration>

<xs:enumeration value=”FAILURE”>

<xs:annotation>

<xs:documentation>Przetworzenie zakończone powodzeniem</xs:documentation>

</xs:annotation>

</xs:enumeration>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name=”DateTime”>

<xs:union memberTypes=”xs:gYear xs:gYearMonth xs:date xs:dateTime”/>

</xs:simpleType>

</xs:schema>

7.8 CAPE w kontekście systemów zewnętrznych

Na poniższym diagramie zaprezentowano system CAPE w kontekście systemów zewnętrznych. Systemy i aplikacje, z którymi współpracuje CAPE to:

CRCS / RCS Systemy repertoryno – biurowe Active Directory ePUAP


Rysunek 26 Diagram kontekstowy systemu CAPE

cmp DCO-002 Diagram kontekstowy

Name: DCO-002 Diagram kontekstowyAuthor: radekVersion: 1.0Created: 2015-11-20 09:06:03Updated: 2015-11-20 11:10:51

CAPE ePUAPSystemy repertoryjno-biurowe

Wspomaganie tworzenia spisu zdawczo-odbiorczego. Na podstawie tych informacji tworzone są pliki CVS importowane w systemie CAPE

Zamówienia na poszczególne elementy spraw składane w systemie ePUAP. System CAPE informuje ePUAP o realizacji zamówienia.

CRCS / RCS

Przekazywanie paczek spraw za pośrednictwem agenta (RCS Agent) działającego w infrastruktufrze lokalnej sądów. Zarządzanie pracą agentów przez centralny komponent WebManager.

Active Directory

Uwierzytelnienie użytkowników CAPE w centralnym Active Directory

«flow»

«flow»«flow»

«flow»

Active Directory

CAPE

CRCS / RCS

Systemy repertoryjno-biurowe

ePUAP


8 Lista uprawnień i rólTabela 1 Lista ról

L.p.

Nazwa roli Opis roli

1. Administrator Administrator to rola, która w systemie CAPE ma uprawnienia do zarządzania uprawnieniami i użytkownikami systemu. Użytkownik ten ma uprawnienia do grupowania uprawnień w role, jak również do przypisywania użytkowników do grup. Dodatkowo, administrator ma uprawnienia do zarządzania słownikami systemu CAPE.

2. Pracownik Sekretariatu Pracownik sekretariatu to rola, która zawiera uprawnienie do składania zamówień na odtworzenie wybranych paczek/paczki z archiwum centralnego.

3. Archiwista Archiwista to rola, która zawiera uprawnienie do tworzenia protokołów brakowania oraz do ich zatwierdzania (po uprzedniej akceptacji protokołu przez wszystkich członków komisji oraz poza systemowej zgody z Archiwum Państwowego)

4. Użytkownik systemu Rola domyślnie nadawana wszystkim użytkownikom

5. Administrator systemu Administrator systemu to użytkownik, który odpowiedzialny jest za instalację, konfigurację oraz bieżące prace utrzymaniowe systemu CAPE.

6. Administrator – Agent Zbiór uprawnień związanych z zarządzaniem Agentami w aplikacji Web Manager

Tabela 2 Lista uprawnień

L.p.

Kod moduł

u

Nazwa uprawnienia Opis uprawnienia Przypisanie do roli

1. PUiA CSUiA_Administracja użytkownikami

wymagane do tworzenia i edycji użytkowników oraz resetowania hasła wybranym użytkownikom.

Administrator

2. PUiA CSUiA_Administracja uprawnieniami

wymagane do tworzenia, edycji i kasowania uprawnień.

Administrator

3. PUiA CSUiA_Administracja rolami wymagane do tworzenia, edycji i kasowania ról, a także do przypinania uprawnień i użytkowników do ról.

Administrator

4. PUiA CSUiA_Administracja grupami wymagane do tworzenia, edycji i kasowania grup, a także przypinania ról i użytkowników do grup.

Administrator

5. PUiA CSUiA_Zarządzanie słownikami wymagane do edycji pozycji słownikowych

Administrator

6. PUiA CSUiA_Przeglądanie własnego rejestru

wymagane do przeglądania rejestru własnych zdarzeń biznesowych.

Użytkownik systemu

7. PUiA CSUiA_Przeglądanie całego rejestru

wymagane do przeglądania rejestru wszystkich zdarzeń biznesowych.

Administrator

8. PUiA CSUiA__Polityka hasła wymagane do edycji polityki hasła Administrator


9. P P_Przeglądanie zamówień wymagane do przeglądania zamówień

Pracownik sekretariatu

10. P P_Tworzenie zamówienia wymagane do utworzenia oraz edycji zamówienia


11. P P_Akceptacja zamówienia wymagane do wysłania zamówienia na udostępnienie do realizacji


12. P P_Akceptacja zamówienia na wycofanie

wymagane do akceptacji zamówienia na wycofanie spraw z CAPE

Archiwista

13. P P_Odrzucenie zamówienia wymagane do odrzucenia zamówienia


14. P P_Wyszukiwanie spraw wymagane, aby mieć dostęp do wyszukiwania oraz przeglądania znalezionych spraw

Użytkownik systemu

15. P P_Edycja sprawy wymagane, aby móc zmienić kategorię archiwalną oraz oznaczyć sprawę jako reprezentacyjną

Archiwista

16. P P_Przeglądanie spisów zdawczo-odbiorczych

wymagane do przeglądania listy oraz szczegółów spisów zdawczo-odbiorczych.

Archiwista

17. P P_Tworzenie spisu zdawczo-odbiorczego

wymagane do utworzenia i edycji spisu zdawczo-odbiorczego

Archiwista

18. P P_Akceptacja spisu zdawczo-odbiorczego

wymagane, aby móc wygenerować i zaakceptować spis zdawczo-odbiorczy

Archiwista

19. P P_Przeglądanie protokołów brakowania

wymagane, aby móc przeglądać listę oraz szczegóły protokołów brakowania

Archiwista

20. P P_Tworzenie protokołu brakowania

wymagane, aby móc rozpocząć proces brakowania: utworzyć protokół, dodać członków komisji, edytować protokół

Archiwista

21. P P_Zatwierdzenie protokołu brakowania

wymagane, aby móc zatwierdzić i wydrukować dany protokół brakowania

Archiwista

22. P P_Przeglądanie protokołów przekazania do AP

wymagane, aby móc przeglądać listę oraz szczegóły protokołów przekazania do AP

Archiwista

23. P P_Tworzenie protokołu przekazania do AP

wymagane, aby móc utworzyć oraz edytować protokół przekazania do AP

Archiwista

24. P P_Zatwierdzenie protokołu przekazania do AP

wymagane, aby móc zatwierdzić i wydrukować dany protokół przekazania do AP.

Archiwista

25. P P_Raporty wymagane do dostępu do modułu raportów

Administrator, Archiwista

26. A A_Administracja agentami wymagane do zarządzania agentami Administrator


27. SZA SZA_Konfiguracja archiwum wymagane do zmiany ustawień czasu retencji obiektów oraz liczby kopii zapisywanych w archiwum

Administrator

28. A WEB_MANAGER_ACCESS Dostęp do Web Managera Administrator – Agent

29. A WEB_MANAGER_STATISTICS_ACCESS

Dostęp do statystyk poprzez Web Managera

Administrator – Agent

30. A WEB_MANAGER_AGENT_LOG_ACCESS

Dostęp do logów agenta poprzez Web Managera


31. A WEB_MANAGER_UPDATE_ACCESS

Możliwość aktualizacji agenta Administrator – Agent

32. A WEB_MANAGER_PING_ACCESS Możliwość pingowania agenta Administrator – Agent

33. A WEB_MANAGER_CAPE_IMPORTER_ACCESS

Dostęp funkcji importera CAPE Administrator – Agent

34. A WEB_MANAGER_CAPE_IMPORTER_ADDITIONAL_FUNCTION_ACCESS

Dostęp do dodatkowych funkcji importera CAPE


35. A WEB_MANAGER_AGENT_RESTART_ACCESS

Dostęp do operacji restartu RCS Server Agent


36. A WEB_MANAGER_AGENT_CONFIG_EDIT_ACCESS

Dostęp do edycji konfiguracji RCS Server Agent



9 Specyfikacja raportówSpecyfikacja raportów zawarta jest w załączniku Zał_specyfikacja_raportow.xlsx

Tabela 3 Lista raportów

Id raportu

Nazwa raportu Opis raportu

RPT.001 Wykaz protokołów zdawczo-odbiorczych

Zestawienie protokołów zdawczo-odbiorczych z przyjęcia dokumentów do CAPE za dany okres

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

RPT.003 Wykaz protokołów brakowania

Zestawienie protokołów brakowania w CAPE za dany okres

RPT.004 Wykaz spisów zdawczo-odbiorczych z przekazania dokumentów do AP

Zestawienie spisów zdawczo-odbiorczych z przekazania dokumentów do AP za dany okres

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.006 Statystyka udostępniania wg zamawiających

Statystyka udostępnień wg zamawiających w danym okresie

RPT.007 Statystyka udostępniania wg udostępniających

Statystyka udostępnień wg udostępniających (wytwórców akt) w danym okresie

RPT.008 Ewidencja brakowania Zestawienie spraw zbrakowanych w CAPE w danym okresie

RPT.009 Ewidencja przekazania do AP

Zestawienie spraw przekazanych do AP w danym okresie

RPT.010 Liczba udostępnionych plików w czasie

Łączna liczba spraw / dokumentów / plików udostępnionych w danym okresie

RPT.011 Liczba przechowywanych dokumentów / spraw

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

RPT.012 Wielkość przechowywanych dokumentów / spraw

Łączna wielkość przechowywanych dokumentów / spraw na dzień generowania raportu


10Specyfikacja ekranów PortaluSpecyfikacja ekranów Portalu zawarta jest w załączniku Zał_specyfikacja_ekranow.zip

Tabela 4 Lista ekranów – Podsystem Uwierzytelniania i Autoryzacji

Lp. Nazwa ekranu Nazwa pliku png

1 Logowanie 1_logowanie.png

2 Administracja 2_administracja.png

3 Zakładanie konta – konto domenowe 3_załóż_konto_domena.png

4 Edycja konta – konto domenowe 4_edytuj_konto_domena.png

5 Lista uprawnień 5_lista_uprawnień.png

6 Edycja uprawnienia 6_edycja_uprawnienia.png

7 Lista ról 7_lista_ról.png

8 Edycja roli 1 8_edycja_roli1.png



11 Lista grup 11_lista_grup.png

12 Edycja grupy 1 12_edycja_grupy1.png





17 Lista użytkowników 17_lista_użytkowników.png

18 Szczegóły użytkownika 1 18_szczegóły_użytkownika1.png






23 Historia operacji 23_historia_operacji.png

24 Zarządzanie polityką haseł 24_polityka_haseł.png

25 Zakładanie konta – konto lokalne 25_załóż_konto_lokalne.png

26 Edycja konta – konto lokalne 26_edytuj_konto_lokalne.png

Tabela 5 Lista ekranów – Portal

Lp. Nazwa ekranu Nazwa pliku png

1 Lista spraw 1_sprawy.png

2 Szczegóły sprawy 1a_sprawa_szczegoly.png

3 Dokumenty w sprawie 1b_sprawa_dokumenty.png

4 Lista zamówień 2_lista_zamowien.png

5 Nowe zamówienie 2a_nowe_zamowienie.png

6 Zamówienie – wybór sprawy 2b_nowe_zamownienie_sprawy.png

7 Zamówienie – wybór dokumentów 2c_nowe_zamowienie_dokumenty.png

8 Zamówienie z listą spraw 2d_nowe_zamownienie2.png

9 Lista spisów zdawczo - odbiorczych 3_spisy_zdawczo_odbiorcze.png

10 Szczegóły spisu zdawczo – odbiorczego 1 3a_spisy_zdawczo_odbiorcze2.png

11 Szczegóły spisu zdawczo – odbiorczego 3 3b_spis_zd_odb_zatwierdzone.png

12 Lista protokołów brakowania 4_protokoly_brakowania.png

13 Nowy protokół brakowania 4a_nowy_protokol_brakowania.png

14 Protokół brakowania – wybór sprawy 4b_nowy_protokol_brak_sprawy.png

15 Protokół brakowania - szczegóły 4c_nowy_prot_brak_szczegoly.png

16 Wybór Komisji ds. brakowania 4d_dodanie_komisji.png

17 Protokół brakowania – szczegóły 2 4e_nowy_prot_brak_szczegoly.png

18 Protokół brakowania – szczegóły 3 4f_nowy_prot_brak_szczegoly2.png

19 Lista raportów 5_raporty.png


11Technologia wykonaniaRozwią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.

11.1 Podsystem PUiA

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

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

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

11.2 Podsystem PortaluPodsystem 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 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 również WildFly, natomiast wykorzystywana baza danych to również PostgreSQL.

http://spring.io/docs

https://angularjs.org/

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

11.3 System Zarządzania ArchiwumRdzeniem System 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


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

https://angularjs.org/

http://spring.io/docs

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

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

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

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.

11.4 Podsystem Przechowywania Danych.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.


12Opis metadanychSpecyfikacja metadanych wymaganych dla opisu sprawy i pliku:

1. identyfikator – jednoznaczny znacznik sprawy, który umożliwia jej identyfikację;1. twórca – podmiot odpowiedzialny za treść dokumentu, z podaniem jego roli w procesie

tworzenia lub akceptacji dokumentu;2. tytuł – nazwa nadana dokumentowi;3. data – data zdarzenia związanego z tworzeniem dokumentu;4. format – nazwa formatu danych zastosowanego przy tworzeniu dokumentu;5. dostęp – określenie komu, na jakich zasadach i w jakim zakresie można udostępnić dokument;6. typ – określenie podstawowego typu dokumentu (np. tekst, dźwięk, obraz, obraz ruchomy,

kolekcja) w oparciu o listę typów Dublin Core Metadata Initiative i jego ewentualne dookreślenie (np. prezentacja, faktura, ustawa, notatka, rozporządzenie, pismo);

7. relacja – określenie bezpośredniego powiązania z innym dokumentem i rodzaju tego powiązania;

8. odbiorca – podmiot, do którego dokument jest adresowany;9. grupowanie – wskazanie przynależności do zbioru dokumentów;10. kwalifikacja – kategoria archiwalna dokumentu;11. język – kod języka naturalnego zgodnie z normą ISO-639-2 lub inne określenie języka, o ile nie

występuje w normie;12. opis – streszczenie, spis treści lub krótki opis treści dokumentu;13. uprawnienia – wskazanie podmiotu uprawnionego do dysponowania dokumentem

Specyfikacja parametrów wyszukiwania sprawy:

1. Sygnatura – identyfikator sprawy 2. Oznaczenie teczki – oznaczenie stron sprawy, kto przeciw komu3. Sąd – nazwa sądu (wytwórcy akt)4. Wydział – nazwa wydziału (wytwórcy akt)5. Kategoria akt – kategoria archiwalna dokumentów ewidencjonowanych ze względu na długość

ich przechowywania6. Data rozpoczęcia sprawy7. Data zakończenia sprawy8. Numer spisu zdawczo - odbiorczego9. Liczba dokumentów w sprawie10. Wolumen – łączny rozmiar plików11. Czy akta reprezentacyjne12. Status: Zarchiwizowana, Zaakceptowana do brakowania, Zaakceptowania do przekazania do

AP, Zbrakowana, Przekazana do AP, Wycofana


13Architektura fizyczna

13.1 Diagram wdrożenia

Rysunek 27 Diagram wdrożenia CAPEdeployment DDE-001 Architektura fizyczna systemu

RCS Database Server

Infrastruktura lokalna sądu

test

ua

tape

MQ

sza db

sza core

web

WAN

globalne

web

kli ent db

puia portal

Name: DDE-001 Architektura fizyczna systemuAuthor: Piotr FusVersion: 1.0Created: 2015-08-13 08:44:08Updated: 2015-11-24 12:56:50

«device»portal1

tagsdysk = 40GBliczba rdzeni = 4OS = RHRAM = 16GB

«executionEnvironment»WildFly portal1

Portal : DCO-005 Portal

«device»portal2


«executionEnvironment»WildFly portal2

Portal : DCO-005 Portal

«device»puia1


«executionEnvironment»WildFly puia1

«device»puia2

tagsdysk = 40GBli czba rdzeni = 4OS = RHRAM = 16GB

«executionEnvironment»WildFly puia2

PUiA: DCO-006 PUiA: DCO-006

«device»db2


«device»db1


«executionEnvironment»PostgreSQL

«executionEnvironment»MongoDB

«device»web1


Architektura systemu::Centralne AD

Monitoring

Logi

Dostęp z/do całego środowiska

Architektura systemu::Stacje robocze

«device»szaw eb1


«device»szacore1

{1..*}


«device»szasqldb1


«executionEnvironment»PostgreSQL

«device»szaidxdb1

{1..*}


«executionEnvironment»Metadane Index DB

«device»szamq1


«executionEnvironment»Message Queue

«device»szatape1

{2}


«device»uaweb1


«device»uakontroler


«device»uasw iftproxy1

{1..*}


«device»uasn

{1..*}


test

Środowisko testowe

«executionEnvironment»Serwer aplikacyjny SZA

System Zarządzania Archiwum : DCO-004 System Zarządzania Archiwum

Web Manager

«device»agentweb

tagsdysk = 40GBli czba rdzeni = 8OS = Windows Server 2012RAM = 4GB

«executionEnvironment»Serwer IIS

RCS Agent Server

«device»agentsrv

{1..*}


Architektura systemu::CRCS

Architektura systemu::RCS

«device»agentdb

{1..*}


«executionEnvironment»Microsoft SQL Serv er

«executionEnvironment»LDAP

«executionEnvironment»WildFly naster - domain controller

«executionEnvironment»Apache HTTP Serv er

Puppet

Architektura systemu::SCP

Storage

636

80, 443, 9000

5432

27017, 10389

8080, 443

80,443,9000,9990

808080,443,9000,9990

5432

80

8080

808841, 8843

1433

8831, 8833

888, 8821, 8823

22

8835

Diagram wdrożenia dla systemu CAPE w większej rozdzielczości zawarty jest w załączniku Zał_diagram_wdrożenia.gif

13.2 Topologia sieciSchemat połączeń sieci LAN w ośrodku podstawowym przedstawiony został na rysunku 1

Schemat połączeń sieci LAN w ośrodku zapasowym przedstawiony został na rysunku 2



Rysunek 28: Schemat połączeń sieci LAN w ośrodku podstawowym.


Rysunek 29: Schemat połączeń sieci LAN w ośrodku zapasowym

Adresacja sieci LAN:

Przykładowy plan adresacji VLAN ID AdresacjaV1264-NET-MGMT 1264 10.11.233.0/25V1265-SRV-MGMT 1265 10.11.233.128/25V1250-PUB-FRONT 1250 10.11.224.0/25V1363-RHEV 1363 10.11.232.0/25V1256-BACKOFFICE 1256 10.11.228.0/25V1364-RHEV-H 1364 10.11.232.128/28

Adresacja:

Urządzenie /serwer

Interface publiczny

Interface wewnętrzny 1 (środowisko wirtualizatora)

Interface wewnętrzny 2 (środowisko wirtualnych maszyn)

Interface wewnętrzny 3 (środowisko wymiany danych urządzenia archiwizującego)

Interface zarządzający 1

Interface zarządzający 1

szaweb1 10.11.224.10 10.11.232.10 szacore1 10.11.232.11 szacore2 10.11.232.12 szacore3 10.11.232.13 szatape1 10.11.232.20 ibm-tsm01 10.11.232.19 ibm-tsm02 10.11.232.20 szamq1 10.11.232.15 szasqldb1 10.11.232.16 szaidxdb1 10.11.232.17 szaidxdb2 10.11.232.18 uaweb1 10.11.232.21 uaswiftproxy1 10.11.232.22 uaswiftproxy2 10.11.232.23 uaswiftproxy3 10.11.232.24 uakontroler1 10.11.232.25 uasn1 10.11.232.26 10.11.228.10 uasn2 10.11.232.27 10.11.228.11 uasn3 10.11.232.28 10.11.228.12 uasn4 10.11.232.29 10.11.228.13 uasn5 10.11.232.30 10.11.228.14 uasn6 10.11.232.31 10.11.228.15 uasn7 10.11.232.32 10.11.228.16 uasn8 10.11.232.33 10.11.228.17 uasn9 10.11.232.34 10.11.228.18 uasn10 10.11.232.35 10.11.228.19 web1 10.11.224.40 10.11.232.36


portal1 10.11.232.37 portal2 10.11.232.38 puia1 10.11.232.39 puia2 10.11.232.40 db1 10.11.232.41 db2 10.11.232.42 log1 10.11.232.44 mon1 10.11.232.45 nfs1 10.11.232.46 szadeploy1 10.11.232.47 szaload1 10.11.232.48 rh7 10.11.232.100 cape-nfs-portal 10.11.232.46 cape-nfs-sza 10.11.232.20 cape-agent 10.11.232.50 cape-cifs 10.11.232.51 cape-nfs 10.11.232.52 cape-webdav 10.11.232.53

13.3 Sieć SANSchemat połączeń dla sieci SAN w Ośrodku Podstawowym przedstawiony został na Rysunku 1

Schemat połączeń dla sieci SAN w Ośrodku Zapasowym przedstawiony został na Rysunku 2

Zasady kreowania połączeń w sieci SAN bazują na zaleceniach producenta macierzy zawartych w dokumencie „Data_ONTAP_81_SAN_Configuration_Guide_for_7Mode” gdzie do połączeń używane będzie 2 lub 4 porty z każdego kontrolera połączone do 2 różnych fabric. Takie rozwiązanie zapewnia właściwy poziom niezawodności rozwiązania oraz możliwość zrównoważenia obciążenia portów SAN macierzy.

Przykład:

Srv_1 – alias serwera w sieci SAN

FAS01_c10c – alias macierzy FAS01 wskazujący na 1 kontroler i jego port 3

Przykład stref dla fabric A i fabric B i użycie 2 portów na każdym z kontrolerów:

Fabric A:

Zone Srv_1_FAS01; „Srv_1, FAS01_c10c, FAS01_c20c”

Fabric B:

Zone Srv_1_FAS01; „Srv_1, FAS01_c10d, FAS01_c20d”

Przykład stref dla fabric A i fabric B i użycie 4 portów na każdym z kontrolerów:

FabricA:


Zone Srv_1_FAS01; „Srv_1, FAS01_c10a, FAS01_c10c, FAS01_c20a, FAS01_c20c”

FabricB:

Zone Srv_1_FAS01; „Srv_1, FAS01_c10b ,FAS01_c10d, FAS01_c20b, FAS01_c20d”

Przykładowy schemat połączeń dla sieci SAN przedstawiony został na rysunku 3


Rysunek 30: Schemat połączeń sieci SAN w ośrodku podstawowym


Rysunek 31: Schemat połączeń sieci SAN w ośrodku podstawowym


Rysunek 32: Przykładowy schemat połączeń macierzy NetApp

Zajętość portów w urządzeniach sieci SAN

Poniższa tabela zawiera zestawienie zajętości portów w urządzeniach sieci SAN.

Tabela 6 Zestawienie zajętości portów w urządzeniach sieci SAN.

SAN A (OP) SAN B (OP) SAN A (OZ) SAN B (OZ)

v3700-1-1 1 0

v3700-1-2 0 1

v3700-2-1 1 0

v3700-2-2 0 1

tape1-1 1 0

tape1-2 0 1

tape1-3 1 0


tape1-4 0 1

tape1-5 1 0

tape1-6 0 1

tape2-1 1 0

tape2-2 0 1

tape2-3 1 0

tape2-4 0 1

tape2-5 1 0

tape2-6 0 1

rhev1 1 1

rhev2 1 1

rhev3 1 1

rhev4 1 1

rhev5 1 1

rhev6 1 1

rhev7 1 1

rhev8 1 1

rhev9 1 1

rhev10 1 1

rhtsm1 1 1

rhtsm2 1 1

cwdm1 1 1

cwdm2 1 1

netapp1-1-1 1 0

netapp1-1-2 0 1

netapp1-2-1 1 0

netapp1-2-2 0 1


netapp2-1-1 1 0

netapp2-1-2 0 1

netapp2-2-1 1 0

netapp2-2-2 0 1

netapp3-1-1 1 0

netapp3-1-2 0 1

netapp3-2-1 1 0

netapp3-2-2 0 1

Szczegółowa konfiguracja przełączników sieci SAN, wraz z topologią znajduje się w załącznikach: cape_san_151118_0738_SA_Wroclaw.xls oraz cape_san_151118_0738_SA_Wroclaw.vsd.Konfiguracja biblioteki taśmowej

13.1 Konfiguracja biblioteki taśmowej

Biblioteka taśmowa TS3500 jest modułową bibliotekę taśm, która skaluje się do 15 szaf rozszerzeń.

Zaproponowane rozwiązanie składa się z 4 modułów, w których znajdują się napędy taśmowe oraz składowane są taśmy LTO. Wyposażona ona będzie w 6 napędów w standardzie LTO6.

Elementem zwiększającym niezawodność rozwiązania jest moduł HA1 który umożliwia dalszą, bezprzerwową pracę pomimo awarii podstawowego robota.

Na rysunku poniżej znajduje się schemat budowy urządzenia:


Cała konfiguracja obejmować będzie 2 takie urządzenia, pierwsze w Ośrodku Podstawowym oraz drugie w Ośrodku Zapasowym.

13.2 Konfiguracja macierzyNiezawodność używanych posiadanych już przez zamawiającego urządzeń NetApp FAS V3220 oparta jest o nadmiarowość komponentów oraz funkcje przejmowania dalszej pracy urządzenia przez nieuszkodzony komponent. Dodatkowo, w trybie Cluster Mode wprowadzono warstwę wirtualizacji zasobów, co podnosi możliwości migracyjne oraz rozbudowy poprzez płynną i bezprzerwową migrację zasobów na inne urządzenia fizyczne.

Rysunek 33: Zasady połączeń redundantnych dla NetApp FAS– źródło: Clustered Data ONTAP® 8.2 High-Availability Configuration Guide

Warstwa nadmiarowości obejmuje dyski twarde – tzw. dyski hot spare oraz komponenty toru zasilania (zasilacze).

Funcie niezawodności na poziome kontrolerów realizowane są przez rozwiązanie HA gdzie oba kontrolory działają w klastrze niezawodnościowym, monitorują wzajemnie swoją pracę i w razie


awarii jednego z nich, drugi przejmuje jego zasoby i rozpoczyna ich dalsze udostępnianie w sposób automatyczny.

Szczegóły realizacji tych funkcjonalności opisane są w dokumencie producenta „Clustered Data ONTAP® 8.2 High-Availability Configuration Guide”.

Macierze NetApp będą wykorzystane w projekcie CAPE jako nośnik danych dla urządzenia archiwizującego. W skład urządzenia archiwizującego wchodzą Storage Node, których zadaniem jest przechowywanie danych. Do tych właśnie węzłów podpięte będą dyski wystawione z macierzy NetApp. Wystawiony dysk nie może przekraczać maksymalnej wielkości, w tym przypadku ograniczonej do 16TB w przypadku wersji ONTAP 8.x. Na dyskach założony będzie system plików XFS, którego ograniczenia to 500TB dla systemu plików.

Dla urządzenia archiwizującego utworzone zostały 3 wirtualne maszyny storge'owe (SVM : CAPE_SAN1/2/3) w taki sposób iż każda z nich dysponuje pełnymi zasobami jednej pary HA:

Na każdej SVM skonfigurowano protokół fcp ; Każda SVM posiada 2 agregaty przeznaczone na dane hostów - po jednej z każdego węzła

pary HA; Każda SVM posiada 4 wirtualne interfejsy (LIF) skonfigurowane na fizycznych portach pary HA

- po dwie karty fc z każdego węzła pary, przy czym karty z pojedynczego węzła wystawione są do różnych switch'y każda, co zapewnia dostępność LUNów nawet w przypadku jednoczesnej awarii jednego węzła (failover) oraz pojedynczego switch'a SAN'owego;

Każda SVM otrzymała unikalny adres WWNN, który reprezentuję wszystkie LIF'y danej maszyny i jest elementem konfiguracji na switch'ach SAN'owych;

Każda SVM otrzymała jedną igroup'ę definiującą hosty RH005-008 Switch'e SAN (SAN_1 i SAN_2:

Utworzono aliasy dla adresów WWNN każdej SVM (Po 3 na każdym switch'u - w sumie 6); Na każdym switch'u utworzono po 12 zon (w sumie 24) łączących hosty RH005-008 z każdą z

utworzonych SVMTesty:

Przeprowadzono również udany test failover'u pierwszej pary HA (01+02)

Konfiguracje SVM : CAPE_SAN1/2/3

SVM Name cluster nodes Ports LIFs LIF WWPNCAPE_SAN1 netapp-cape-01 2a CAPE_SAN1_01_lif1 20:13:00:a0:98:3c:d5:3e 2b CAPE_SAN1_01_lif2 20:14:00:a0:98:3c:d5:3e netapp-cape-02 2a CAPE_SAN1_02_lif3 20:15:00:a0:98:3c:d5:3e 2b CAPE_SAN1_02_lif4 20:1a:00:a0:98:3c:d5:3e igroup ig_IBM_RH005-008 WWNN 20:12:00:a0:98:3c:d5:3e Brocade alias

A_CAPE_SAN1

Zones: Z_CAPE_SAN_1_IBM_RH005 Z_CAPE_SAN_1_IBM_RH006 Z_CAPE_SAN_1_IBM_RH007 Z_CAPE_SAN_1_IBM_RH008 vadmin: Disabled mgmt IP: N/A


SVM Name cluster nodes Ports LIFs LIF WWPN

CAPE_SAN2 netapp-cape-03 2a CAPE_SAN2_03_lif1 20:17:00:a0:98:3c:d5:3e

2b CAPE_SAN2_03_lif2 20:1e:00:a0:98:3c:d5:3e

netapp-cape-04 2a CAPE_SAN2_04_lif3 20:1f:00:a0:98:3c:d5:3e

2b CAPE_SAN2_04_lif4 20:20:00:a0:98:3c:d5:3e

igroup ig_IBM_RH005-008

WWNN 20:16:00:a0:98:3c:d5:3e

Brocade alias A_CAPE_SAN2

Zones: Z_CAPE_SAN_2_IBM_RH005

Z_CAPE_SAN_2_IBM_RH006



vadmin: Disabled

mgmt IP: N/A

SVM Name cluster nodes Ports LIFs LIF WWPN

CAPE_SAN2 netapp-cape-05 2a CAPE_SAN3_05_lif1 20:22:00:a0:98:3c:d5:3e


netapp-cape-06 2a CAPE_SAN3_06_lif3 20:24:00:a0:98:3c:d5:3e


igroup ig_IBM_RH005-008

WWNN 20:21:00:a0:98:3c:d5:3e

Brocade alias A_CAPE_SAN3


Zones: Z_CAPE_SAN_3_IBM_RH005




vadmin: Disabled

mgmt IP: N/A

13.3 Wdrożenie agentówWdrożenie agentów zostało opisane w osobnym załączniku Zał_wdrożenie_agentow.docx


14Lista procedur utrzymaniowych Procedura utrzymania serwerów aplikacji podsystemów PUiA oraz Portalu.

Procedura opisuje czynności mające na celu utrzymanie serwerów WildFly, takie jak restarty serwerów, monitorowanie logów i uruchamianie aplikacji.

Procedura utrzymania serwera proxy wraz z aktualizacją publicznych certyfikatów.Procedura opisuje monitorowanie, restartowanie serwera proxy jak również konfigurację certyfikatów wykorzystywanych przez proxy do zapewnienia bezpiecznej komunikacji z przeglądarką.

Procedura zarządzania konfiguracją podsystemów PUiA oraz Portalu.Procedura opisuje w jaki sposób konfigurować aplikacje, czyli najważniejsze wpisy konfiguracyjne czy definicję połączeń do innych elementów (bazy danych, AD).

Procedura utrzymania baz danych podsystemów PUiA oraz Portalu.Procedura opisuje w jaki sposób utrzymywać bazę danych - monitorować jej stan, miejsce przechowywania plików, uruchomienie i zatrzymanie serwerów.

Procedury administracyjne OpenStack/SWIFTProcedury związane z utrzymaniem klastra systemu Swift (object storage), sprawdzanie dostępności wolnego miejsca, procedury związane z zarządzaniem węzłami proxy i storage node. Procedury opisujące dołączanie nowego węzła do klastra i zarządzaniem usługą Keystone (uwierzytelnienie i autoryzacja)

Procedury administracyjne RHELProcedury związane z administracją i utrzymaniem systemu RHEL, sprawdzanie usług i ich restart. Procedury związane z rozbudową elementów rozwiązania, tj. dołączanie nowych węzłów (konfiguracja usług sieciowych – adresacja, hostname itp.)

Procedury administracyjne RHEVProcedury związane z utrzymanie wirtualizatora RHEV, zarządzanie klastrem, procedury związane z podłączeniem nowych urządzeń, multipath, przydział VLAN dla maszyn gościa

Procedury administracyjne Storwize V3700Procedury związane z utrzymaniem macierzy używanej przez aplikację w ramach rozwiązania CAPE. Kontrola poprawności działania urządzenia, wystawianie nowych dysków (LUN)

Procedury administracyjne IBM TSMProcedury związane z utrzymaniem i konfiguracja środowiska TSM. Procedury związane z tworzeniem kopii zapasowej i odtworzeniem kopii zapasowej bazy danych TSM

Procedury administracyjne IBM TS3500Procedury utrzymaniowe Biblioteki taśmowej IBM TS3500

Procedury administracyjne IBM/Lenovo x3550Procedury związane z administracja serwerami x3650, sprawdzanie statusu w konsoli IBM

Plan testów DRP dla środowiskaPlan działań odtworzeniowych związanych z wznowieniem pracy środowiska CAPE w przypadku katastrofy


15Sprzęt i licencje

15.1 Dostarczane przez Wykonawcę

15.1.1 Sprzęt i licencjeNa potrzeby realizacji zamówienia Wykonawca dostarczy następujący sprzęt:

Tabela 7 Infrastruktura sprzętowa

Lp. Nazwa dostarczonego Sprzętu i Oprogramowania

PN Serial Numer Ilość

Uwagi

1. Biblioteka Taśmowa

n/d n/d

2

Biblioteka do ośrodka podstawowego i zapasowego

1.1 Biblioteka taśmowa - moduł S54 (ośrodek podstawowy)

3584-S54 78T2217 1

1.2 Biblioteka taśmowa - moduł D53 (ośrodek podstawowy)

3584-D53 7849909 1

1.3 Biblioteka taśmowa - moduł HA1 (ośrodek podstawowy)

3584-HA1 78F2729 1

1.4 Biblioteka taśmowa - moduł L53 (ośrodek podstawowy)

3584-L53 7827758 1

1.5 Biblioteka taśmowa - moduł S54 (ośrodek podstawowy)

3584-S54 78T2218 1

1.6 Biblioteka taśmowa - moduł D53 (ośrodek podstawowy)

3584-D53 7849911 1

1.7 Napęd LTO6 (ośrodek podstawowy) 3588-F6A n/d 6

1.8 Biblioteka taśmowa - moduł D53 (ośrodek zapasowy)

3584-D53 7849910 1

1.9 Biblioteka taśmowa - moduł D53 (ośrodek zapasowy)

3584-D53 7849914 1

1.10 Biblioteka taśmowa - moduł HA1 (ośrodek zapasowy)

3584-HA1 78F2734 1

1.11 Biblioteka taśmowa - moduł S54 (ośrodek zapasowy)

3584-S54 78T2211 1

1.12 Biblioteka taśmowa - moduł S54 (ośrodek zapasowy)

3584-S54 78T2190 1

1.13 Biblioteka taśmowa - moduł L53 (ośrodek zapasowy)

3584-L53 7827749 1

1.14 Napęd LTO6 (ośrodek zapasowy) 3588-F6A n/d 6

2.1 IBM Total Storage LTO Ultrium 2.5TB

n/d n/d 1600

2.2 IBM Total Storage LTO Ultrium 2.5TB

n/d n/d 1600

3. IBM System Storage SAN48B-5 99Y1755 10426KX 1


4. IBM System Storage SAN48B-5 99Y1755 10426KV 15. IBM System Storage SAN48B-5 99Y1755 10426ME 16. IBM System Storage SAN48B-5 99Y1755 10425VD 1

7. Urządzenie archwizujące – iBardDataStore

n/d n/d 1

7.1 Juniper EX2200-48T-4G 232-EX2200

CU0215150250

1

7.2 Intel x520 Dual Port 10GbE 49Y7960 n/d 207.3 Systmx550WHghEffcncyPltnACPwS

y00FK930 n/d 2

7.4 IXPE5 – 2630v3 8C2.4G20m 00FK643 n/d 10

7.5 IBM 0U 24 C13 Switched and Monitored 32A PDU

46M4119 n/d 2

7.6 SFP+ 10GBASE-SR Fiber Optic Transceiver Module

46C3447 n/d 40

7.7 Storwize PUBS License – Easy Tier 00MJ123 n/d 1

7.8 Storwize HARD DRIVE 900GB HD ASM

00MJ147 n/d 20

7.9 Storwize FC CARD 8Gb FC Card 00MJ095 n/d 27.10 Storwize FIBEROPTC AOP 00MJ103 n/d 27.11 120GBSATA2.5MLCG3HSEnValSSD 00AJ396 n/d 4

7.12 Juniper EX2200-48T-4G 232-EX2200

CU0215150149

1

7.13 Juniper EX4550-VC1-128G 750-039073

n/d 2

7.14 Juniper EX-SPF-1GE-SX 210-EX OPTICS

n/d 4

7.15 Juniper EX-CBL-VCP-3M 211-EX MISC

n/d 2

7.16 Juniper EX-SPF-10GE-SR 210-EX OPTICS

n/d 32

7.17 Systmx750WHghEffcncyPltnACPwSy

00FK932 n/d 8

7.18 QLogic 8Gb FC Single – port HBA 42D0501 n/d 207.19 120GBSATA3.5MLCHSEntalueSSD 00AJ436 n/d 16

7.2016GB TruDDR4 Memory (2Rx4, 1.2V) PC4-17000 CL15 2133MHz LP RDIMM

46W0796 n/d 194

7.21 Storwize SS FILE 200GB HD ASM 00MJ154 n/d 4

7.22 St3650M5PCIR9 2x8FHFL + 1x8FHHLS

00KA498 n/d 10

7.23 IBM Integrated Management Module Advanced Upgrade

90Y3901 n/d 10

7.24 IBM Virtual Media Conversion Option Gen2 (VCO2)

46M5383 n/d 10

7.25 IBM Local 2x16 Console Manager (LCM16)

1754A2X n/d 1

7.26 1U 17.5in Standard Console 17238BX n/d 17.27 Storwize MEMORY 4GB CACHE MEM 00MJ101 n/d 2

7.28 Storwize V3700 2.5-inch Storage Controller Unit

6099S2C 7889669 1

7.29 SERWER X3650 M5 XEON 8C E5- 5462AC1 06GKEAG 1


2637.30 SERWER X3650 M5 XEON 8C E5-

2635462AC1 06GKEAW 1

7.31 SERWER X3650 M5 XEON 8C E5-263

5462AC1 06GKEAN 1


5462AC1 06GKEAE 1


5462AC1 06GKEAF 1


5462AC1 06GKEAT 1


5462AC1 06GKEAH 1


5462AC1 06GKEAV 1

7.37 SERWER X3650 M5 XEON 8 CORE 5462AC1 06GKEAD 17.38 SERWER X3650 M5 XEON 8 CORE 5462AC1 06GKEAC 1

7.39 NetBAY S2 42U Standard Rack Cabinet

93074RX n/d 1

7.40 Ultrslm9.5mmSATAMltBrnr 00AM067 n/d 27.41 System x3650 M5 ODD Cable Kit 00AL956 n/d 2

7.42 Przełącznik EX4550 EX4550 LX0215337066

1

7.43 Przełącznik EX4550 EX4550 LX0215337130

1

8. Portal n/d n/d 18.1 SERWER X3650 M5 XEON 8 CORE 5462AC1 06GKEAL 18.2 SERWER X3650 M5 XEON 8 CORE 5462AC1 06GKEAK 18.3 IXPE5 – 2630v3 8C2.4G20m 00FK643 n/d 2

8.416GB TruDDR4 Memory (2Rx4, 1.2V) PC4-17000 CL15 2133MHz LP RDIMM

46W0796 n/d 6

8.5 120GBSATA2.5MLCG3HSEnValSSD 00AJ396 n/d 48.6 QLogic 8Gb FC Single – port HBA 42D0501 n/d 4

8.7 St3650M5PCIR9 2x8FHFL + 1x8FHHLS

00KA498 n/d 2

8.8 Intel x520 Dual Port 10GbE 49Y7960 n/d 48.9 Systmx550WHghEffcncyPltnACPwS

y00FK930 n/d 2

8.10 IBM Integrated Management Module Advanced Upgrade

90Y3901 n/d 2

8.11 SFP+ 10GBASE-SR Fiber Optic Transceiver Module

46C3447 n/d 8

8.12 European 10A C13 to CEE 7/7 2.8M Power Cord Option

39Y7917 n/d 4

8.13 IBM Virtual Media Conversion Option Gen2 (VCO2)

46M5383 n/d 2

LicencjeNa potrzeby realizacji zamówienia Wykonawca zapewni następujące licencje:


Tabela 8 Licencje

Red Hat Enterprise Linux Server, Standard (Physical or Virtual Nodes)

10770642 n/d 4

Red Hat Enterprise Virtualization (2-sockets), Standard

10781623 n/d 2

iBard Portal – licencja

n/d n/d 1 Licencja na dostarczane rozwiązanie

iBard Client


Red Hat Cloud Infrastructure, Standard (2-sockets)

10770642 n/d 8

Red Hat High Availability 10781623 n/d 2Red Hat Enterprise Linux Server, Standard (Physical or Virtual Nodes)

10770642 n/d 2

IBM Tivoli Storage Manager Extended Edition 10Processor Value Units (PVUs) Annual SW Subscription &Support Renewal (31-Aug-2015 - 31-Aug-2016)

E029ELL n/d 424

IBM Tivoli Storage Manager Extended Edition 10Processor Value Units (PVUs) Annual SW Subscription &Support Renewal (01-Sep-2016 - 31-Aug-2017)

E029ELL n/d 424

IBM Tivoli Storage Manager Extended Edition 10Processor Value Units (PVUs) Annual SW Subscription &Support Renewal (01-Sep-2017 - 31-Aug-2018)

E029ELL n/d 424

IBM Tivoli Storage Manager Extended Edition 10Processor Value Units (PVUs) Annual SW Subscription &Support Renewal (01-Sep-2018 - 31-Mar-2019)

E029ELL n/d 424

System Zarządzania Archiwum – iBard Archive Manager



Zakres funkcjonalny realizowany przez poszczególne produkty:

COMARCH iBard Archive Manager:

a) Wszystkie wymagania w zakresie Podsystemu Przechowywania Danych

b) Wszystkie wymagania w zakresie Podsystemu Uwierzytelniania i Autoryzacji

c) Wszystkie wymagania w zakresie Systemu Zarządzania Archiwum, za wyjątkiem wymagania:

WF.SZA.013 W zakresie przechowywania danych podsystem musi zapewniaćgenerowanie raportów dotyczących przechowywanych paczek i zdeklarowanychokresów ich przechowywania [pkt 2.4, str. 30],

w zakresie którego Wykonawca przekaże Zamawiającemu prawa autorskie

COMARCH iBard Client:

WF.A.013 Centralne zarządzanie konfiguracją i aktualizacją agenta

Dla oprogramowania realizującego pozostałą część wymagań podsystemu Agenta (oprogramowania Agenta instalowane lokalnie) Wykonawca przekaże Zamawiającemu prawa autorskie.

COMARCH iBard Portal: wszystkie wymagania dla podsystemu Portal w zakresie oprogramowania w części narzędziowej (serwer aplikacyjny, baza danych, framework). W zakresie wyprodukowanych na potrzeby projektu ekranów (stron), grafik, plików CSS, kodu w zakresie obsługi dedykowanych dla Projektów procesów biznesowych Wykonawca przekaże Zamawiającemu prawa autorskie.

15.1.2 Opis wymagań programowych

Serwer Nazwa Wersja RAM Liczba rdzeni

OS Dysk

web1Apache HTTP

Server2.4

64 bit4 GB 2 Red Hat

7.140 GB

web1 WildFly 8.2.1.Final

64 bit512 MB 2 Red Hat

7.140 GB

puia1 WildFly8.2.1.Final


7.140 GB

puia2 WildFly8.2.1.Final


7.140 GB

portal1 WildFly8.2.1.Final


7.140 GB

portal2 WildFly8.2.1.Final


7.140 GB

db1 MongoDB3.0.6 64 bit

8 GB 8 Red Hat 7.1

500 GB

db1 LDAP2.0.0–M20


7.1500 GB

db2 PosdgreSQL9.4.464 bit

20 GB 8 Red Hat 7.1

500 GB

Szaweb1 Nginx1.6


7.140 GB


Szacore1 Ibard1.0


7.140 GB

Szamq1 RabbitMQ3.5.664 bit

16 GB 4 Red Hat 7.1

80 GB

Szasqldb1 PostgreSQL9.2


7.1500 GB

Szaidx1 Elasticsearch1.7.364 bit

32 GB 8 Red Hat 7.1

500 GB

Uaweb1 HAProxy1.5


7.140 GB

Uakontroler1Openstack Keystone

7.064 bit

8 GB 4 Red Hat 7.1

40 GB

Uaswiftproxy1

Openstack Swiftproxy

7.064

8 GB 4 Red Hat 7.1

40 GB

Uasn1Openstack

Swift7.064

16 GB 8 Red Hat 7.1

40 GB

15.2 Udostępniane przez Zamawiającego

15.2.1 SprzętW celu realizacji projektu Zamawiający udostępni zasoby pięciu macierzy NetApp V3220HA gwarantujących wymaganą przestrzeń dyskową. Zamawiający nie ogranicza Wykonawców i dopuszcza dostawę macierzy dyskowej w przypadku, gdy zaoferowane przez Wykonawcę rozwiązanie wymaga dostawy takiej macierzy wraz ze wszystkimi niezbędnymi licencjami.

15.2.2 LicencjeZamawiający nie dostarcza żadnych licencji.

15.2.3 Opis wymagań programowychSerwer Nazwa

oprogramowaniaWersja

oprogramowaniaRAM Liczb

a rdzeni

OS Dysk

Web Manager

Internet Information Services (IIS)

8.0 4GB 1

Microsoft Windows Server 2008 64 bit po aktualizacji (z SP 2 lub dla wersji R2 z SP 1) lub wyższy

1GB

RCS Agent Server

4GB 1


20GB

RCS Database Server

Microsoft SQL Server

2008 lub wyższa 64 bit 4GB 1


100GB


16Testy

16.1 Program przebiegu testów

Program przebiegu testów zawarty jest w załączniku Zał_PTA_15-10-05_CAPE_01-01_CA382_Plan Testów - Etapy III i IV.docx

16.2 Raport z przebiegu testów

Raport z przebiegu testów zawarty jest w załączniku Zał_CAPE_Raport_wyników_testów_TuraI_CA.xlsx


SPIS RYSUNKÓWRysunek 1: Opis notacji dla procesów biznesowych..............................................................................8

Rysunek 2: Opis notacji dla diagramów przypadków użycia..................................................................9

Rysunek 3: Opis notacji dla diagramów stanu......................................................................................10

Rysunek 4: Opis notacji dla diagramu komponentów...........................................................................11

Rysunek 5: Proces brakowania akt sprawy..........................................................................................20

Rysunek 6: Proces przekazania danych archiwalnych do Archiwum Państwowego............................22

Rysunek 7: Proces wprowadzania danych do CAPE...........................................................................23

Rysunek 8: Tworzenie spisu zdawczo-odbiorczego.............................................................................25

Rysunek 9: Proces wycofania akt sprawy............................................................................................26

Rysunek 10: Proces wyszukiwania i przeglądania sprawy...................................................................27

Rysunek 11: Proces zamawiania akt sprawy........................................................................................28

Rysunek 12: Aktorzy – role systemu CAPE..........................................................................................59

Rysunek 13: Administracja Systemem Zarządzania Archiwum............................................................60

Rysunek 14: Diagram przypadków użycia – Portal...............................................................................62

Rysunek 15: Diagram stanów dla brakowania/przekazania do AP.......................................................74

Rysunek 16: Diagram stanów dla sprawy.............................................................................................75

Rysunek 17: Diagram stanów dla zamówienia.....................................................................................76

Rysunek 18: Podsystem Uwierzytelniania i Autoryzacji........................................................................77

Rysunek 19: Retencja danych..............................................................................................................92

Rysunek 20: Architektura systemu.......................................................................................................94

Rysunek 21: Komunikacja Agenta z CAPE..........................................................................................96

Rysunek 22: Podsystem Przechowywania Danych..............................................................................97

Rysunek 23: Podsystem Uwierzytelniania i Autoryzacji........................................................................99

Rysunek 24: Portal............................................................................................................................. 100

Rysunek 25: System Zarządzania Archiwum.....................................................................................101

Rysunek 26 Diagram kontekstowy systemu CAPE............................................................................111

Rysunek 27 Diagram wdrożenia CAPE..............................................................................................122

Rysunek 28: Schemat połączeń sieci LAN w ośrodku podstawowym................................................123

Rysunek 29: Schemat połączeń sieci LAN w ośrodku zapasowym....................................................124

Rysunek 30: Schemat połączeń sieci SAN w ośrodku podstawowym................................................128

Rysunek 31: Schemat połączeń sieci SAN w ośrodku podstawowym................................................129

Rysunek 32: Przykładowy schemat połączeń macierzy NetApp.........................................................130

Rysunek 33: Zasady połączeń redundantnych dla NetApp FAS– źródło: Clustered Data ONTAP® 8.2

High-Availability Configuration Guide.................................................................................................134

SPIS TABELTabela 1 Lista ról................................................................................................................................ 113

Tabela 2 Lista uprawnień................................................................................................................... 113


Tabela 3 Lista raportów...................................................................................................................... 116

Tabela 4 Lista ekranów – Podsystem Uwierzytelniania i Autoryzacji..................................................117

Tabela 5 Lista ekranów – Portal.........................................................................................................118

Tabela 6 Zestawienie zajętości portów w urządzeniach sieci SAN.....................................................130

Tabela 7 Infrastruktura sprzętowa......................................................................................................139

Tabela 8 Licencje............................................................................................................................... 142

SPIS ZAŁĄCZNIKÓWNr Nazwa załącznika Nazwa pliku

1. Specyfikacja raportów Zał_specyfikacja_raportow.xlsx

2. Specyfikacja ekranów Portalu

Zał_specyfikacja_ekranow.zip

3. Diagram wdrożenia Zał_diagram_wdrozenia.gif

4. Opis paczki archiwalnej Zał_opis_paczki_archiwalnej.doc

5. Program przebiegu testów Zał_PTA_15-10-05_CAPE_01-01_CA382_Plan Testów - Etapy III i IV.docx

6. Raport z testów Zał_CAPE_Raport_wyników_testów_TuraI_CA.xlsx

7. Wdrożenie agentów Zał_wdrozenie_agentow.docx

8. Procedury eksploatacyjne Zał_procedury.zip

9. Konfiguracja przełączników sieci SAN

Zał_cape_san_151118_0738_SA_Wroclaw.vsd

10. Konfiguracja przełączników sieci SAN

Zał_cape_san_151118_0738_SA_Wroclaw.xls


wroclaw.sa.gov.pl · Web viewPliki zawierające logi zdarzeń systemowych będą podpisywane, co...

Documents

Transcript of wroclaw.sa.gov.pl · Web viewPliki zawierające logi zdarzeń systemowych będą podpisywane, co...