Upozornění: Text přílohy byl získán strojově a nemusí přesně odpovídat originálu. Zejména u strojově nečitelných smluv, kde jsme použili OCR. originál smlouvy stáhnete odsud
Strana 1/163
„RUK – ÚDAUK – Archivní informační systém“ –
Smlouva o dílo a o poskytování služeb – Příloha č. 2 – Části
nabídky Dodavatele obsahující popis nabízeného plnění,
kvalifikaci a zkušenosti pracovníků týmu Dodavatele
Strana 2/163
Obsah – Příloha č. 2
Obecný popis nabízeného řešení ………………………………………………….3
Výpis ze seznamu kvalifikovaných dodavatelů …………………………………57
Řádná účetní uzávěrka InQool 2015-2017 ………………………………………63
Smlouva o budoucí spolupráci při realizaci veřejné zakázky ………………….109
Výpisy z rejstříku trestů právnických osob LightComp ……………………….112
Potvrzení o bezdlužnosti FU – LightComp ……………………………………123
Čestné prohlášení pro základní způsobilost – LightComp …………………….124
Potvrzení o bezdlužnosti ČSSZ – LightComp …………………………………126
Výpis z obchodního rejstříku – LightComp …………………………………...127
Seznam Významných služeb …………………………………………………..128
Seznam techniků ……………………………………………………………….132
Systém Helpdesk ………………………………………………………………137
Životopisy techniků ……………………………………………………………140
Strana 3/163
1 OBECNÝ POPIS NABÍZENÉHO ŘEŠENÍ
„Archivní informační systém“ (dále AIS) pro potřeby Archivu Univerzity Karlovy je nástroj, který
umožní výběr, příjem, evidenci, zpracování, uložení a zpřístupnění digitálních a analogových
archiválií (včetně jejich případných digitálních kopií) a informační podporu činností archivu
akreditovaného dle §§ 58 – 61 zákona č. 499/2004 Sb., o archivnictví a spisové službě v platném
znění. Nabízené řešení je modulární systém složený z existujících komponent, upravených
komponent dle zadávací dokumentace a modulů vytvořených jen pro potřeby zadavatele.
Jednotlivé komponenty jsou navrženy tak, aby zcela naplnili všechny funkční a technické
požadavky definované v zadávacích technických podmínkách. Architektura řešení zajistí pokrytí
požadovaných funkcí pro dlouhodobou ochranu a uchovávání uložených archiválií dle normy
ČSN ISO 14721 Systémy pro přenos dat a informací z kosmického prostoru - Otevřený archivační
informační systém - Referenční model. AIS bude komunikovat s interními systémy zadavatele
(zejména s elektronickou spisovou službou – dále jen ESSS, personálním systémem Univerzity
Karlovy WhoIS UK a s Centrální autentizační službou UK – dále jen CAS) a s celostátními
archivními informačními systémy (především s Národním portálem – viz § 18 b, odst. 1 a 3-5
zákona č. 499/2004 Sb.).
Při návrhu způsobu řešení a jeho realizaci vycházíme z principu, kdy se snažíme využívat
existující komponenty a tyto upravovat dle funkčních a technických požadavků. Pokud
neexistuje vhodná komponenta nebo její úprava by nebyla efektivní je proveden vývoj
komponenty zcela nové. Pomocí tohoto principu jsme schopni vytvořit řešení, které je
dlouhodobě udržitelné, kvalitní a má nízké provozní náklady.
Dílčí části, komponenty, jejich interakce a další aspekty nabízeného řešení jsou detailně popsány
v následujících kapitolách. Pro lepší přehlednost a referencování přímo v textu jsou kapitoly
číslovány. V případě, že se v textu referencuje pojem Smlouva myslí se tím Smlouva o dílo a
poskytování služeb jako příloha č. 1 Zadávací dokumentace.
1.1 Preambule koncepce řešení
Komplexní řešení popsané v této nabídce je postaveno na ověřených technologiích společností
InQool a.s. a LightComp v.o.s., které jsou postaveny na dlouhodobém a úspěšném působením
těchto společností na jejich specifických trzích a realizacích náročných projektů pro velké
zákazníky (Národní knihovna Praha, Národní archiv, Knihovna Akademie Věd, Archiv Min.
obrany, atd.), v rámci kterého získali rozsáhlé a hluboké know-how, které vkládájí do vytvoření
poptávaného AIS. Odhadujeme, že cca 70-75% projektu bude postaveno na hotových a praxí
ověřených technologiích/produktech a zbytek bude postaven na míru specifickým potřebám
Zadavatele. Věříme, že tyto skutečnosti budou vnímány v prospěch zadavatele a s cílem
maximalizovat kvalitu dodávek a poskytovaných služeb.
Strana 4/163
2 ARCHITEKTURA NABÍZENÉHO ŘEŠENÍ
Popis architektury je realizován formou logického rozdělení do základních funkčních bloků. Tyto
bloky jsou následně detailněji popsány. Architektura nabízeného řešení plně respektuje
požadavky formulované v zadávací dokumentaci.
2.1 Návrh logického rozdělení funkcionalit do funkčních bloků
Z pohledu logického rozdělení funkcionalit akceptujeme návrh Zadavatele definovaný v kapitole
2 přílohy č. 4 Smlouvy. Jedinou výjimku shledáme v Zadavatelem logicky oddělených modulech
Modul Export a Správa Badatelny, kde tyto zpravidla řešíme jednou komponentou (v kapitole
4.1.3.3 definovanou jako modul Office). Taktéž navrhujeme z pohledu provozní architektury část
Správa badatelny přesunout do interního perimetru Zadavatele, mimo infrastrukturu, která je
dostupná veřejnosti.
Následuje tabulka jednotlivých logických komponent s uvedením informace o plnění a zda je již
jinde využito:
Komponenta Plnění Již použit v jiném řešení
Vstupní portál Bude vyvinuto na míru Zadavateli NE
Modul eSkartace Základem bude obdobný modul z ANO
Národního digitálního archivu, bude
upraven dle požadavků
Modul eVýběr Základem bude obdobný modul z ANO
Národního digitálního archivu, bude
upraven dle požadavků
Modul Příjem Základem bude obdobný modul z ČÁSTEČNĚ
dokumentů Národního digitálního archivu, bude
upraven dle požadavků
Vstupní a pracovní Je součástí modulu Příjem, resp. daných ČÁSTEČNĚ
úložiště (Celek Výběr) částí
Vyhledávání Bude vyvinuto na míru Zadavateli ČÁSTEČNĚ
pomocou standardní technologie
Evidenčně-správní Bude vyvinuto na základě systému PEVA ANO
modul II (IS evidence archiválií Národního
archivu) s funkcemi určenými na míru
Zadavateli.
Strana 5/163
Modul pro archivní Aplikace Elza ANO
zpracování ANO
Modul rejstříky a Aplikace Elza ČÁSTEČNĚ
metadata
Modul zápis Bude vyvinuto na míru Zadavateli s ANO
využitím existujících komponent a ANO
Hlavní úložiště AIS platforem. NE
Modul Export Použitím technologie ARCLib NE
Použitím technologie iQ Discovery a ANO
Administrace modulu Office ANO
Kontejner Bude vyvinuto na míru Zadavateli ANO
Správa badatelny Bude vyvinuto na míru Zadavateli
Použitím technologie iQ Discovery a
Badatelna modulu Office
Použitím technologie iQ Discovery a
Úložiště vnějšího modulu Discovery
zpřístupnění Bude řešeno použitím standardní
databázové technologie v rámci iQ
Discovery
2.2 Návrh business architektury
Jako uchazeč jsme názoru, že business architektura řešení byla již v dostatečné míře definována
Zadavatelem v rámci zadávací dokumentace. Pro jednoznačnost zde tedy uvádíme model
definice AIS tak, jak je uveden v zadávací dokumentaci:
Strana 6/163
Návrh jednotlivých komponent respektuje tuto architekturu. Na základě provedené analýzy a
technického projektu může dojít k drobným upřesněním.
2.3 Návrh technických nástrojů a řešení
V této kapitole přikládáme formou výčtu seznam technologií jednotlivých významných
komponent řešení i s uvedením informací vyžadovaných Zadavatelem. U komponent, které zde
nejsou explicitně uvedeny předpokládáme využití technologií již obsažených u zde uvedených
významných komponent.
2.3.1 Výběr
Název Krátký popis Lze rozvíjet jiným Řádový odhad
Java 1.8 dodavatelem případných
Spring dodavatelů
PostgreSQL
Programovací jazyk ANO Obecně rozšířený
programovací jazyk
Technologie aplikačního ANO Obecně rozšířený
serveru framework
PostgreSQL je objektově- ANO Obecně rozšířená
relační databázový
Strana 7/163
systém. Vydáván je pod databáze
licencí typu MIT a tudíž se Obecně rozšířená
jedná o free a open source knihovna
software.
React JavaScriptová knihovna ANO
pro vytváření
uživatelských rozhraní
pro webové aplikace. Je
open source. O projekt se
stará firma Facebook,
Instagram a komunita
individuálních vývojářů.
2.3.2 Modul pro archivní zpracování - Elza
Název Krátký popis Lze rozvíjet jiným Řádový odhad
Java 1.8 Programovací jazyk
dodavatelem případných
dodavatelů
ANO Obecně rozšířený
programovací jazyk
Spring Technologie aplikačního ANO Obecně rozšířený
serveru framework
PostgreSQL Objektově-relační ANO Obecně rozšířená
databáze
databázový systém.
Vydáván je pod licencí
typu MIT a tudíž se jedná
o free a open source
software.
React JavaScriptová knihovna ANO Obecně rozšířená
JasperReports pro vytváření knihovna
uživatelských rozhraní Obecně rozšířený
pro webové aplikace. Je tiskový reporter
open source. O projekt se
stará firma Facebook,
Instagram a komunita
individuálních vývojářů.
Jedná se o open source ANO
nástroj pro generování
různých typů výstupů jako
jsou PDF, ODT, RTF, XML
apod.
Strana 8/163
2.3.3 Hlavní úložiště AIS
Název Krátký popis Lze rozvíjet Řádový odhad
jiným případných
dodavatelem dodavatelů
Java 1.8 Programovací jazyk ANO Obecně rozšířený
programovací jazyk
Spring Boot Technologie aplikačního ANO Obecně rozšířený
framework
serveru
Camunda BPM Open source procesní engine ANO Obecně rozšířený
framework
Hibernate ORM databázová technologie ANO Obecně rozšířený
framework
Apache ActiveMQ Open source asynchronní ANO Obecně rozšířený
Artemis technologie pro messaging s framework
podporou transakcí.
Apache Solr Open source fulltextový ANO Obecně rozšířený
framework
vyhledávač vycházející z
Apache Lucene.
PostgreSQL Objektově-relační ANO Obecně rozšířená
databáze
databázový systém. Vydáván
je pod licencí typu MIT a
tudíž se jedná o free a open
source software.
React JavaScriptová knihovna pro ANO Obecně rozšířená
vytváření uživatelských knihovna
rozhraní pro webové
aplikace. Je open source. O
projekt se stará firma
Facebook, Instagram a
komunita individuálních
vývojářů.
JasperReports Jedná se o open source ANO Obecně rozšířený
tiskový reporter
nástroj pro generování
různých typů výstupů jako
jsou PDF, ODT, RTF, XML
apod.
Strana 9/163
Quartz Open source knihovna pro ANO Obecně rozšířená
LogBack plánování a správu rutinních knihovna
jobů v Javě. Obecně rozšířená
knihovna
Robustní open-source ANO
logovací nástroj, který má
nativní podporu pro
většinou běžně
používaných aplikačních
serverů. Je pokračovatelem
projektu log4j.
2.3.4 Vyhledávání
Uvádíme zde zejména technologie nad rámec již vyčtených v předchozích komponentách:
Název Krátký popis Lze rozvíjet Řádový odhad
jiným případných
dodavatelem dodavatelů
Elastic Open source fulltext ANO Obecně rozšířená
platforma
indexovací engine s
podporou vysoké
dostupnosti a dalších
komplexních služeb
2.3.5 Technologie webových aplikací a portálů
Sem spadají zejména moduly Evidenčně-správní, Vstupní portál, Badatelna, Správa badatelny a
uživatelské rozhraní Vyhledávání. Uvádíme zde zejména technologie nad rámec již vyčtených v
předchozích komponentách:
Název Krátký popis Lze rozvíjet Řádový odhad
jiným případných
dodavatelem dodavatelů
Material UI Open source fulltext ANO Obecně rozšířená
platforma
indexovací engine s
podporou vysoké
dostupnosti a dalších
komplexních služeb
Recharts Open source knihovna pro ANO Obecně rozšířená
JavaScript pro tvorbu technologie
vizuální grafů a statistik
Strana 10/163
Webpack Open source kompilovací ANO Obecně rozšířená
Redux JS platforma
ECMAScript 6 systém pro jazyk JavaScript Obecně rozšířená
Apache Velocity technologie
Rozšíření jazyka JavaScript o ANO Obecně rozšířená
stavové kontejnery aplikace technologie
Objektově orientované a ANO Obecně rozšířená
typově striktní rozšíření knihovna
jazyka JavaScript
Open source knihovna pro ANO
vytváření exportních šablon,
které přímo referencují
objekty jazyka Java
2.4 Návrh rozhraní, které bude systém užívat pro interní i externí
komunikaci
Celé řešení je postaveno na kombinaci standardních komponent a individuálního vývoje dle
požadavků Zadavatele. Z hlediska typů rozhraní uvažujeme o použití webových služeb a to
formou:
● WSDL rozhraní
● REST rozhraní
Tam, kde existují oborové standardy, tak preferujeme jejich užití nebo, kde jsou komunikační
rozhraní komponent standardizována jiným způsobem. Zvláštní pozornost při návrhu musí být
věnována místům, kde může docházet k přenosu větších objemů dat. Například celek Vstup,
manipulace s AIPy apod. V rámci analýzy budou všechna rozhraní mezi komponentami pevně
definována a budou využívat uvedené typy rozhraní.
2.4.1 Systémy ESSS
Zde bychom navrhovali vyčkat na připravovaný standard webového rozhraní pro skartační
řízení připravovaný Národním archivem v rámci NDA. Tento standard by měl být založen na
rozhraní WSDL v kombinaci přenosovým protokolem FT (viz
http://frnk.lightcomp.cz/download/nacr/ndais/doc/ws/ft.html#ws-fts ). Pokud bude standard
zveřejněn, tak předpokládáme jeho implementaci do komponenty eSkartace. Případně je možná
jeho implementace již na základě předběžného stavu.
Dle informací zadavatele uvažuje/preferuje využití protokolu definovaného v rámci NSESSS.
Implementace takového řešení je možná, pokud bude poskytnuta podrobná technická
specifikace komunikačního protokolu. Bude však nutné dobře zhodnotit technická rizika tohoto
protokolu. Způsob řešení bude stanoven v rámci připravovaného projektu řešení.
Strana 11/163
2.4.2 Systém INTERPI
Rozhraní pro komunikaci se systémem INTERPI je založeno na standardu WSDL. Podrobná
technická dokumentace je dostupná zde: http://www.interpi.cz/projekt/int.vy.do/Technicka-
dokumentace
2.4.3 Interní systémy Zadavatele
Pro komunikaci s interními systémy zadavatele (např. WhoIs) předpokládáme co možná nejvíce
využít již stávající rozhraní, která budou založena na jednom z výše uvedených standardů.
Nepředpokládáme využití jiných komunikačních protokolů.
2.4.4 Komunikace mezi komponentami řešení
Přenos dat mezi částmi celku Výběr je převážně řešen pomocí WSDL v kombinaci s FT.
Předpokládáme rozvoj této technologie dle dodatečných potřeb vyplývající z analýzy.
Komunikace s úložištěm bude založena opět na webových službách. Významným faktorem této
komunikace je formát balíčků (AIP) a jejich velikost. Uživatelské rozhraní bude převážně
komunikovat se serverovými komponentami pomocí HTTP/REST. Data budou přenášena ve
formátu JSON.
2.5 Návrh datových formátů, které budou používány pro správu dat, jejich
ukládání a výměnu
Návrh datových formátů je dán vždy jejich účelností a požadavky na ně kladenými. Principiálně
platí:
● pro transakční zpracování, zajištění konzistence dat je použita vždy relační databáze
● pokud jsou mezi systémy přenášena strukturovaná data, tak jsou ve formátu JSON nebo
XML
● pokud jsou data ve formát XML předávána mezi vzájemně nezávislými komponentami,
tak je XML definováno pomocí XSD schématu. Toto schéma také slouží pro ověření
správnosti předávaných dat
● v kritických místech systému upřednostňujeme explicitní definici datových formátů před
implicitní provedenou v kódu
● pokud jsou k dispozici obecné archivní standardy, tak se je snažíme využívat (METS,
EAD, NSESSS apod.)
V rámci uvažovaného informačního systému považujeme za významné správně navrhnout
formát dat ukládaných do dlouhodobého úložiště. Konkrétně se jedná o podobu AIP balíčků.
Členového našeho týmu mají reálnou zkušenost s návrhem datových formátů pro mnoho
systémů včetně Národního digitálního archivu. Chtěli bychom stavět na těchto zkušenostech a
dále rozvinout již dříve navržená a zaběhnutá řešení.
Dále uvádíme konkrétních příklady datových formátů pro vybrané významné komponenty z
pohledu přenosu a definice dat:
Strana 12/163
2.5.1 Modul rejstříky - import dat
Modul rejstříky bude pro import dat používat XML formát odpovídající schématu definovanému
v rámci projektu Elza. Dokumentace ke schématu: http://frnk.lightcomp.cz/download/elza/edx-
0.16/
2.5.2 Elektronická publikace archivních pomůcek
Archivní pomůcky z modulu Elza do modulu zpřístupnění mohou být předávány v jednom z
formátů:
● PDF
● Nativní XML formát Elza (podrobněji viz dokumentace k XSD schématu
http://frnk.lightcomp.cz/download/elza/edx-0.16/)
● EAD - nyní ve vývoji
Nevidíme jako účelné data mezi interními systémy předávat ve formátu EAD, neboť neumožňuje
zcela přesně zachytit všechny detaily archivního popisu. Z tohoto důvodu preferujeme nativní
XML formát Elza.
2.5.3 Formát AIP balíčku
Formát AIP balíčku navrhujeme definovat s využitím formátů vhodných pro dlouhodobou
archivaci (METS). Pro popis vložených metadat je možné využít i další standardní formáty
(PREMIS, EAD). Balíčkem AIP rozumíme adresář (případně ZIP či jiná zabalená podoba)
obsahující metadata (METS.xml) a vlastní binární data s obsahem balíčku. Pomocí samostatných
XML schémat jsou popsána metadata uložená v souboru METS.xml. Pro uložení archivního
popisu využíváme formát EADv3.
Každý balíček bude definovaného typu. Pro každý typ bude definována pevná struktura, tak jak
je naznačeno výše.
Příklad uvažovaného formátu balíčku (NDA):
http://frnk.lightcomp.cz/download/nacr/ndais/doc/specifikace/aip.html
Balíčky budou umožňovat reprezentaci entit těchto typů:
● archiválie
● archivní soubor
● vnitřní změna
● vnější změna
● archivní pomůcka
V rámci implementační analýzy bude vytvořena přesná technická specifikace formátu AIP tak,
aby umožňoval reprezentaci uvedených typů entit. Součástí technického návrhu bude také
přesné vymezení způsobu používání identifikátorů při respektování požadavků zadavatele na
ně.
Strana 13/163
2.6 Zajištění škálovatelnosti a modulárnosti
Navržené řešení je plně modulární a s definovanými aplikačními rozhraními. Tímto krokem je
zajištěna dostatečná horizontální i vertikální škálovatelnost. Je možné relativně nezávisle na
sobě vyměňovat jednotlivé komponenty a jejich verze. V případě nutnosti výkonového posílení
je možné komponenty přenášet na samostatný hardware, případně provozovat paralelně.
Konkrétně možnosti již záleží na dané komponentě a její funkcionalitě.
Součástí dodávky řešení bude definice a popis všech používaných API. Tato definice je vytvářena
nezávisle na implementaci komponenty a vždy jí předchází. Základní přehled komunikačních
rozhraní a datových formátů je v předcházejících dvou kapitolách.
Strana 14/163
3 BEZPEČNOST NABÍZENÉHO ŘEŠENÍ
InQool a.s. je držitelem certifikátu EN ISO 27001 Information security management. Jde o
mezinárodní standard managementu bezpečnosti informací. Metodiky, směrnice a požadavky
vyplývající z této certifikace budeme aplikovat během plnění předmětné veřejné zakázky s
úmyslem zvýšit kvalitu plnění.
Nabízené řešení bude pracovat s osobními údaji v souladu s legislativou uvedenou v čl. 28,
zejména v odst. 2. a 3. Nařízení Evropského parlamentu a Rady (EU) 2016/679 ze dne 27. dubna
2016 o ochraně fyzických osob. Integrita dat bude zajištěna na úrovni databázové vrstvy.
Logování systémových událostí bude vždy do strojově čitelného formátu a na běžné systémové
výstupy (syslog atd.). Konkrétní podoba a struktura logů bude předmětem implementační
analýzy. Předpokládáme, že každá významná systémová komponenta bude mít svůj separátní
log. V rámci logování předpokládáme i budování specifických auditních záznamů. Detailní
systém logování a auditu bude zachycen v implementační analýze.
Z pohledu oddělení veřejných a neveřejných částí systému předpokládáme oddělení na úrovni
infrastruktury Zákazníka. Doporučujeme, aby byly aplikační i databázové komponenty
veřejného rozhraní odděleny do samostatné části infrastruktury (viz kap. 4.3).
Systém bude připraven tak, aby veškerá interní (mezi jednotlivými komponentami) i externí
(vůči systémům třetích stran a/nebo zákazníka) komunikace mezi jednotlivými komponentami
byla šifrována pomocí protokolu HTTPS. Konkrétní komunikační kanály, přestupy mezi systémy
a specifické parametry zabezpečení (certifikáty, porty, firewally atd.) budou předmětem
implementační analýzy.
3.1 Obnova dat
Během implementace řešení předpokládáme vypracování tzv. disaster recovery plánu, který
bude zachycovat postupy a mechanismy pro obnovu systému a jeho dat v případě havárie.
Obecně v případě obnovy dat počítáme s dvěma hlavními scénáři, které budou následně
rozpracovány a upřesněny v rámci implementační analýzy:
● Běžná obnova
Jedná se o případ, kdy jsou dostupné zálohy dat a je možné úplně nebo alespoň z velké
části obnovit data do bodu poslední zálohy. Předpokládáme dostupnost plných
databázových záloh ve standardní granularitě a rozdílových záloh ve vyšší granularitě.
Ideální je taktéž plná záloha jednotlivých virtuálních strojů. Následná obnova po havárii
tohoto typu probíhá zdola nahoru, tzn. nejprve dojde k obnovení virtuálních strojů
(případně jejich čistých instalací), následně obnova databázových vrstev, následně
aplikačních vrstev a na závěr rekonstrukcne interních struktur (reindex, konfigurační
soubory atd.). Sem spadá taktéž obnova jen z dostupných záloh AIP balíčků, kdy se
infrastruktura obnoví na čistou infrastrukturu a proběhne pokus o import AIPů. Obnova
z AIPů se primárně týká obnovy Evidenčně Správního Modulu. Obnova dalších modulů je
provedena na základě událostí generovaných z ESM (například indexu pro vyhledávání).
Strana 15/163
● Úplná havárie
V případě, že havárie postihne jak hlavní systém, tak zálohy, není možné aplikovat
běžnou obnovu dat. V tomto případě bude navrhnut specifický scénář, kdy se provede
pokus o rekonstrukci dat z externích systémů (Národní archiv) v omezeném množství a
kvalitě.
Strana 16/163
4 PLNĚNÍ POŽADOVANÝCH FUNKCIONALIT A DALŠÍCH POŽADAVKŮ
4.1 Návrh způsobu naplnění technických a funkčních požadavků
zadavatele
V této kapitole jsou jednotlivé technické a funkční požadavky rozděleny dle primární struktury,
kterou Zadavatel popsal v Příloze č. 4 Smlouvy (konkrétně na obrázku v kapitole 2). U
jednotlivých požadavků je věcným způsobem popsán navrhovaný způsob jejich řešení. V
oblastech, kde to Zadávací dokumentace umožňuje a kde je to vhodné, jsou popsány varianty
možných řešení. Jednotlivé použité technologie jsou definovány výčtem v kapitole 2.
4.1.1 Vstupní portál
Vstupní portál předpokládáme realizovat pomocí moderních webových technologií, které jsou
popsány v kapitole 2. Portál bude koncipován jako webová aplikace určená pro provoz v
prostředí webových prohlížečů, a to dle požadavků Zadavatele na kompatibilitu definovanou v
kapitole 3.2 Přílohy č. 5 Smlouvy. Vstupní portál bude v maximální možné míře přizpůsoben
grafické identitě Zadavatele, a to předpokládáme zejména v oblastech barev, stylů, loga a fontů.
Úvodní obrazovka vstupního portálu bude obsahovat minimálně:
1. Záhlaví s názvem portálu a logem
2. Uvítací text, který bude předmětem editace obsahu oprávněnými uživateli přes
WYSIWYG editor
3. Oblast pro přihlášení (samotné přihlášení se bude dít prostřednictvím autentizační
brány CAS UK, na kterou bude odkazováno). V této oblasti máme jako dodavatel
zkušenost se všemi nabízenými možnostmi definovanými v příloze č. 4 Smlouvy, ale
preferujeme autentizaci přes protokol Shibboleth. Tato oblast se bude zobrazovat jen
pro nepřihlášené uživatele
4. Informace o přihlášeném uživatele
5. Vstup do veřejné části badatelny
6. Další texty a obsahové sekce dle analýzy, který můžou být předmětem editace obsahu
oprávněnými uživateli přes WYSIWYG editor
7. Zápatí s odkazy a informacemi dle požadavků Zadavatele
Z pohledu integrace na webové stránky Archivu UK preferujeme formu odkazu a přesměrování
na vstupní portál.
Po přihlášení se uživateli přehledným způsobem zobrazí přehled dostupných agend a
funkcionalit AIS. Předpokládáme, že jednotlivé agendy budou mít svá vlastní uživatelská
rozhraní, a to provozované ve webovém rozhraní. Po kliknutí na danou agendu v rozcestníku se
uživatel přesměruje na danou agendu a může ji začít používat, bez nutnosti dalšího přihlašování.
V rámci každé agendy bude mít uživatel dostupnou aplikační lištu, pomocí které se může
přepnout do libovolného dalšího modulu nebo se dostat zpět na vstupní portál.
Pro úplnost zde přikládáme i tabulku požadavků a způsob jejich naplnění:
Strana 17/163
Přihlašování uživatelů Ano, uvažován jako centrální prvek na úvodní
obrazovce portálu pro nepřihlášené uživatele.
Zakládání nových uživatelů Ano, bude připraven formulář pro nového uživatele a
přes vhodné API předána informace do CAS
Po přihlášení přepínání mezi Ano, pomocí aplikačních lišt v jednotlivých agendách.
hlavními rozhraními jednotlivých
modulů
Přístup k veřejné části webové Ano, dostupné na úvodní obrazovce vstupního
badatelny portálu bez nutnosti přihlášení
Rozhraní (webová služba) pro Ano, bude integrováno v potřebném rozsahu
komunikaci s WhoIS UK
Rozhraní pro komunikaci s CAS Ano, bude integrováno pro potřeby autentizace
Nástroj pro jednoduchou editaci Každá agenda bude mít své vlastní administrační
určeného statického obsahu webové rozhraní (viz. popis v subkapitole Administrace) a z
stránky tvořící portál tohoto pohledu nebude Vstupní výjimka. V rámci
tohoto rozhraní bude zabezpečena zejména editace
vybraných textů, které budou definovány během
analýzy. Editace textů bude zabezpečena editory typu
WYSIWYG.
Rozcestník pro přístup do Ano, rozcestník se zobrazí po přihlášení a nabídne
jednotlivých modulů AIS seznam agend dostupných uživateli.
Na závěr doplňujeme, že zde nabízíme variantní řešení vycházející z naší zkušenosti s
informačními systémy obdobného charakteru, kde by byl vstupní portál oddělen na dvě
samostatné portály. Jeden čistě dedikovaný pro interní uživatele, který by byl dostupný jen v
intranetu Zadavatele, a druhý dedikovaný pro veřejnost, který je technicky možné zcela oddělit
od interních komponent. Tento přístup by přispěl k zvýšení bezpečnosti řešení. Následně by
funkci vstupního portálu pro veřejnost plnila veřejná část badatelny. Tato varianta by měla
dopad i na topologii provozních prostředí, ale v rámci kapitoly 4.3 zatím není uvažována.
4.1.2 Výběr
Celek Výběr navrhujeme postavit na existujících modulech, které jsou vyvíjeny pro analogickou
činnost Národním archivem (Národní digitální archiv). Moduly budou dále upraveny dle
požadavků zadavatele po provedení příslušných analýz. Celek zajišťuje komunikaci s původci i s
jádrem systému, umožňuje zasílání konečných seznamů přijatých dokumentů. Přesná podoba a
množství dokumentů bude upřesněna v rámci analýz.
Strana 18/163
V rámci celku Výběr navrhujeme spojení modulu eSkartace (skartační řízení) a modulu eVýběr
(mimoskartační řízení) do jednoho celku. Důvodem je jednak faktická blízkost obou modulů, ale
také zvýšení komfortu uživatelů, kdy obě řízení probíhají ve stejném modulu. Uživatelé mají
jedno místo, kde spravují všechna probíhající řízení. K náhledu přikládáme návrh rozhraní
modulu:
Přehled (správa) řízení
Detail řízení a zobrazení nahraných SIP balíčků
Strana 19/163
Práce s entitami uvnitř SIPů
4.1.2.1 eSkartace
Pro úplnost zde přikládáme i tabulku požadavků a způsob jejich naplnění:
Administrace skartačního řízení Ano, v rámci modulu bude k dispozici
příslušná administrace.
Nahrávání SIP balíčků dle NSESSS (manuální Ano, bude možné nahrát SIP uvedenými
/archivářem nebo původcem/, nebo cestami. SIP může být nahrán bez komponent
prostřednictvím webové služby) (a ty doplněny v rámci procesu později) nebo
je možné nahrát SIP rovnou včetně
komponent.
Zobrazení seznamu SIP dle struktury Ano, v rámci modulu bude k dispozici
spisového plánu s možností následného příslušné rozhraní (již existuje).
zobrazení struktury jednotlivých SIP
Antivirová kontrola, validace souborů – Ano, pro nahrávání souborů slouží
struktury podle NSESSS samostatná část modulu. Nahrané SIP jsou
podrobeny antivirové kontrole a teprve po
jejím úspěšném dokončení jsou SIP předány
vlastnímu modulu. V opačném případě jsou
SIP odmítnuty rovnou v rámci části pro
nahrávání.
Správa účtů původců – konkrétní řešení Ano, správa účtů bude k dispozici. Lze
včetně umístění nástroje je k jednání. diskutovat také možnost využití
Uživatelské rozhraní správy původců musí jednorázových účtů pro původce. Tyto účty
být dostupné z modulu eSkartace mohou být automaticky zrušeny po
dokončení příslušného řízení.
Strana 20/163
Komunikace s původcem prostřednictvím Ano, pro komunikace s původcem budou
standardizovaných PDF/A a XML dokumentů dokumenty k dispozici v uvedených
a webových služeb, zejména generování formátech a to vždy dle charakteru
žádostí o předložení plného SIPu, generování dokumentu.
seznamu s rozhodnutím, zaslání protokolu o
uložení v archivu
Výběr SIP pomocí označení balíčků Ano, v modulu bude možné v grafickém
(hromadně i jednotlivě) v grafickém rozhraní rozhraní vyznačovat rozhodnutí o výběru.
Rozhodnutí bude možné provádět hromadně
i jednotlivě.
Tvorba dokumentace o skartačním řízení a Ano, v rámci plnění smluvních milníků
její odesílání do ESM
Nástroje navržené zadavatelem: Ano, vkládání souborů bude probíhat v
samostatné části. Tato část také zajistí
Nástroj pro manuální vkládání SIP provedení antivirové kontroly a bude
archivářem nebo původcem uživatele informovat v případě jejího
negativního výsledku.
Rozhraní pro komunikaci s ESSS (umožňuje Je možné akceptovat skartační návrhy dle
dávkové vkládání SIP) prostřednictvím NSESSS příloha 2-4.
webové služby
Grafické rozhraní s možností různého Ano, výběr bude prováděn na obsahem SIPů
zobrazení seznamů SIP, zobrazením tedy nad jednotlivými základními entitami.
vybraných metadat a možností zobrazení
(stáhnutí) dokumentů v SIP a provádění
výběru označováním SIPů a operací
Nástroj pro administraci uživatelských účtů Ano, lze diskutovat i o možnosti
původců jednorázových účtů.
Přehledný log procesů Ano, implicitně v rámci plnění.
Rozhraní pro komunikaci s rejstříkem Ano, implicitně v rámci plnění.
původců
Nástroje z Kontejneru pro práci se SIP Ano, implicitně v rámci plnění.
(volaná služba) – validátor SIP, antivir,
generátor dokumentů
Strana 21/163
Rozhraní pro komunikaci s ESM (celek Ano, implicitně v rámci plnění.
Správa) Nahrání souborů a jejich antivirová kontrola
jsou řešeny v samostatné části. Teprve po
Rozhraní pro komunikaci se ʺvstupním a úspěšné antivirové kontrole jsou data
pracovním úložištěmʺ předána modulu eSkartace.
4.1.2.2 eVýběr
Výstupní SIP z mimoskratačního řízení se bude skládat ze souboru SIP XML, který bude v
případě digitálních či hybridních archiválií doplněn příslušnými soubory. SIP XML, který bude
vytvořen, bude vycházet ze standardu METS. Návrh jeho přesné podoby je popsán v
dokumentaci http://frnk.lightcomp.cz/download/nacr/ndais/doc/specifikace/pruvodka.html.
Pro úplnost zde přikládáme i tabulku požadavků a způsob jejich naplnění:
Nahrávání dokumentů archivářem nebo Ano, vzhledem k návrhu řešitele na sloučení s
původcem (manuální nebo prostřednictvím eSkartací, bude se jednat o obdobu nahrávání
webové služby) SIP
Antivirová kontrola Ano, v principu shodné s eSkartací
Komunikace s původcem prostřednictvím Ano, možnosti použitých formátů dokumentů
PDF dokumentů a webové služby shodné s eSkartací
Výběr dokumentů, vyplňování popisných Ano, v grafickém rozhraní bude možné
metadat, tvorba SIP (včetně SIP bez datového postupně vytvářet, upravovat strukturu
obsahu pro analogové dokumenty) vybraných dat. Následně data budou uložena
ve formě SIP. Pro tvorbu struktury bude
možné využít stávající adresářovou strukturu
nahrávaných dat.
Správa účtů původců. Uživatelské rozhraní Shodné s eSkartací.
správy původců musí být dostupné z modulu
eVýběr
Odesílání vytvořených SIP do celku Správa Shodné s eSkartací.
Administrace mimoskartačního řízení Shodné s eSkartací.
Nástroje navržené zadavatelem: Shodné s eSkartací.
Nástroj pro vkládání dokumentů (manuální
nebo pomocí webové služby)
Strana 22/163
Nástroj umožňující vytváření složek, Ano, nahrané soubory budou zobrazeny v
jednotlivé a hromadné přesouvání souborů samostatné části, ze které budou přesouvány
mezi složkami, přejmenovávání souborů a do výsledné struktury. V rámci výsledné
složek a vyplňování metadat (a celého struktury bude možné vytvářet a upravovat i
popisu) u vytvořených složek, tj. rozhraní příslušná metadata.
vizuálně odpovídající běžnému souborovému
manageru a umožňující kopírování, přesun,
mazání a přejmenování souborů.
Nástroj pro tvorbu SIP z vytvořených složek Ano, výsledná struktura včetně jejího obsahu
(převod vytvořeného popisu do XML (komponenty, metadata) bude
struktury pomocí šablony), datových transformována do podoby SIP
komponent a metadatového popisu
analogových archiválií
Rozhraní pro komunikaci s rejstříkem Shodné s eSkartací.
původců
Přehledný log procesů Shodné s eSkartací.
Nástroje z Kontejneru pro práci se SIP Shodné s eSkartací.
(volaná služba) – antivir, generátor
dokumentů
Nástroj pro administraci uživatelských účtů Shodné s eSkartací.
původců
Rozhraní pro komunikaci se „vstupním a Shodné s eSkartací.
pracovním úložištěmʺ
Rozhraní pro komunikaci s ESM (celek Shodné s eSkartací.
Správa)
4.1.2.3 Vstupní a pracovní úložiště
Nahrávání vstupních souborů bude vyčleněno do samostatné části “Nahrávání dat”, jejíž součástí
bude také zajištění antivirové kontroly. Tato část používá své samostatné úložiště. Teprve po
úspěšném dokončení antivirové kontroly budou nahrané soubory k dispozici ostatním modulům
resp. modulu, který vyvolal nahrávání. V případě zjištění zavirovaných dat nebudou tato data
přijata a uživatel bude informován o jejich odmítnutí již v rámci části Nahrávání dat.
4.1.2.4 Příjem dokumentů mimo skartační a mimoskartační řízení
Zajištění manuálního vstupu dokumentů do AIS bude umožněno formou nahrání nových AIP
balíčků nebo nahráním nových verzí AIP balíčků. Tato část bude vyžadovat podrobnější analýzu
daného procesu. K dispozici máme modul, který bychom zřejmě mohli použít jako základ řešení.
Po provedení řádné analýzy bude toto upřesněno. Předpokládáme, že jednotlivé informační
Strana 23/163
balíčky budou mít vždy uveden svůj typ. V rámci analýzy bude nutné tyto typy přesně popsat a
ke každému z nich definovat jeho formát.
Pro úplnost zde přikládáme i tabulku požadavků a způsob jejich naplnění:
Nahrávání dokumentů k existujícím AIP Ano, bude realizováno editací jednotlivého
Příjem seznamů s identifikátory NDA AIPu
Nahrávání dokumentů k AIP vytvářeným Ano, bude realizováno na základě znalosti
vnitřní změnou dohledání způsobu komunikace s NDA
Předávání nahraných dokumentů do celku Ano, budou nahrávány nové AIPy, obdobné
Správa jako při mimo skartačním řízení jen není
Antivirová kontrola součástí řízení
Ano, bude realizováno
Ano, v principu shodné s eSkartací
4.1.3 Správa
4.1.3.1 Vyhledávání
Jádrem této komponenty předpokládáme využít komplexní vyhledávací index na bázi open-
source technologie Elastic. Konfigurace indexu je v extrémní míře přizpůsobitelná individuálním
požadavkům pro vyhledávání. Jako dodavatel máme zkušenosti s použitím této technologie v
obdobném prostředí k AIS, které je složeno z různých modulů a agend. V prostředí tohoto
charakteru je Elastic nakonfigurován tak, aby přebíral požadované data z okolních systémů a
začlení je do svých indexů. Nad čistě technologickou komponentou je následně publikováno
uživatelské rozhraní, které oprávněným uživatelům umožňuje vyhledávání v tomto indexu.
Vyhledávání podporuje zpravidla fulltextové vyhledávání v textových atributech a definici
komplexní omezující kritérií a jejich kombinace. K náhledu přikládáme screenshot obdobného
vyhledávacího rozhraní:
Omezující kritéria se dále liší dle datového typu daného atributu. Například pro datumové pole
se nabízí možnost definování data od nebo do, pro textové pole je možné využít operátorů
Strana 24/163
“začíné s”, “obsahuje” nebo “končí s” (samozřejmostí je definice datového pole pomocí
vizuálního pomocníku, viditelném na následujícím náhledu).
Samozřejmostí je možnost stránkování výsledků (s možností definice velikosti stránky) a
možnost definice sloupců zobrazených ve vyhledávací tabulce:
Pro úplnost zde přikládáme i tabulku požadavků a způsob jejich naplnění:
Nástroj pro zadávání vyhledávacích dotazů Ano, formou uživatelského rozhraní pro
zadávání strukturovaných dotazů (fulltext v
kombinaci s komplexními omezujícími
kritérii na úrovni agend a/nebo metadat)
Rozhraní pro komunikaci s moduly celků Ano, implicitně v rámci architektury.
Správa a Výběr Zároveň má technologie Elastic standardní,
otevřené a zdokumentované rozhraní pro
případnou integraci s třetími stranami.
Indexační nástroj (umístění tohoto nástroje v Ano, roli indexačního nástroje plní
konkrétním modulu může být upřesněno v technologie Elastic.
technickém
projektu)
Strana 25/163
Nástroj pro zobrazení výsledků vyhledávání Ano, formou uživatelského rozhraní.
Možnost uložení šablon pro vyhledávání Ano, bude vyvinuta podpora pro uložení
vyhledávacích dotazů do profilu uživatele pro
pozdější znovupoužití.
4.1.3.2 Hlavní úložiště AIS
Zde navrhujeme využít technolgii open-source archivního úložiště ARCLib (www.arclib.cz)
dostupného pod open-source licencí GNU General Public License v3.0
(https://github.com/LIBCAS/ARCLib), kterého jsme v spolupráci s pracovní skupinou Knihovny
Akademie věd tvůrcem a s kterým máme jako dodavatel velké zkušenosti. ARCLib poskytne
podporu pro dlouhodobé a bezpečné uložení AIP balíčků a potřebné uživatelské rozhraní pro
správu. Specifikem je, že ARCLib má své vlastní vyhledávací a indexovací komponenty, je zde
používaná technologie Solr. Tato bude integrována na hlavní vyhledávací index na bázi
technologie Elastic. Nicméně nabízíme Zadavateli zde možnost této technologie využít jako
doplňující k hlavnímu vyhledávání a vyhledávat pomocí ní jen v archivním úložišti AIS, pro
demonstraci zde přikládáme screenshoty tohoto vyhledávacího rozhraní:
Výsledky vyhledávání AIP
Strana 26/163
Zadání vyhledávacích kritérií
Strana 27/163
Dále zde pro demonstraci přikládáme několik screenshotů z uživatelského rozhraní ARCLib pro
správce:
Definice SIP profilů
Správa úložiště
Strana 28/163
Definice validačních profilů
Definice zdrojových profilů
Závěrem potvrzujeme, že náš návrh architektury zaručuje, že archivní úložiště bude přístupné
výlučně z celku Správa, jako jádra AIS a podporuje postup zálohování definovaný v kap. 2.2.6
Přílohy č. 4 Smlouvy.
Strana 29/163
4.1.3.3 Modul Export
Pro implementaci modulu Export navrhujeme využit jako základ modulu Office z produktu iQ
Discovery, který je publikován jako open source pod licencí GNU Affero General Public License
v3.0, viz. https://github.com/InQool/IQ-Discovery. Tento modul bude sloužit jako základ a bude
dále rozvíjen pro splnění všech funkčních požadavků. Primárním úkolem exportního modulu
bude zpracování a příprava balíků(DIP) pro vnější zpřístupnění. Proběhne zde i případná úprava
kvality, optimalizace velikostí balíků s ohledem na výkonnostní požadavky portálu veřejné
badatelny a případné nutné konverze formátů. Samotná příprava balíků bude probíhat v rámci
uživatelského rozhraní, které bude dostupné pro oprávněné uživatele. Na následujících
screenshotech jsou k nahlédnutí nabízené komponenty a možnosti jejich realizace:
Seznam dávek k zpřístupnění
Detail dávky k zpřístupnění
Pro úplnost zde přikládáme i tabulku požadavků a způsob jejich naplnění:
Nástroj pro tvorbu DIP umožňující úpravu Ano, pomocí uživatelského rozhraní
veškerého obsahu (může být pomocí volaných Office modulu.
služeb – nástrojů)
Volání konvertorů a případně dalších nástrojů v Ano, v rámci interních mechanismů
Kontejneru Office modulu.
Rozhraní pro komunikaci s ESM a jednotlivými Ano, v rámci interních mechanismů
Strana 30/163
moduly celku Vnější zpřístupnění Správa badatelny, Office modulu.
Webová badatelna a Úložiště zpřístupnění a
Národním digitálním archivem
4.1.3.4 Evidenčně-správní modul (ESM)
Společnost InQool a.s. je dodavatelem informačního systému PEVA II, který je evolučním
nástupcem Zadavatelem odkazovaného systému PEVA I (str. 30 přílohy č. 9 zadávací
dokumentace). Jako uchazeč v tomto výběrovém řízení předpokládáme využít zkušeností,
znalostí, existujících komponent a systémů z PEVA II pro naplnění požadavků Zadavatele v
maximální možné míře a kvalitě.
Pro vyloučení pochybností Zadavatel zde explicitně deklarujeme, že naše nabízená řešení splní
jednotlivé funkcionality a procesy definované v kapitole 1.2 Přílohy č. 4 Smlouvy.
Pro lepší představu zadavatele níže přikládáme náhledy z informačních systému
implementujících obdobné moduly k ESM:
Karta evidenčního předmětu
Strana 31/163
Evidence obrazových příloh s metadaty
Provádění hromadných změn v metadatech entit
Jednotlivé funkce a integrace požadovaných procesů budou následně implementováný
Zadavateli na míru na základě provedení technické analýzy.
Pro úplnost zde přikládáme i tabulku požadavků a způsob jejich naplnění:
Hromadný (dávkový) příjem SIP balíčků a Ano, bude implementováno na míru
řízení tvorby reprezentací archiválií z těchto Zadavateli.
SIP (vnější změny – přírůstek)
Administrace hromadných operací nad Ano, bude implementováno na míru
archiváliemi (vnitřní změny) Zadavateli.
Správa záznamů o archivních pomůckách Ano, bude implementováno na míru
Zadavateli.
Správa metadat archivních entit Ano, bude implementováno na míru
Zadavateli.
Strana 32/163
Zpracování seznamů o uložení v NDA, včetně Ano, bude implementováno na míru
zápisu identifikátorů NDA Zadavateli.
Přidělování interních identifikátorů AIS Ano, implicitní číselnou řadou, konzistence
(včetně udržování přehledu o všech může být řízena přímo na úrovni integritních
přidělených identifikátorech) omezení databáze. Přehled identifikátorů
bude formou přehledových tabulech, kterých
náhled lze shlédnout na připojených
screenshotech v této kapitole.
Dělení a slučování archivních entit archiválií Ano, bude implementováno na míru
Zadavateli.
Řízení tvorby nových archivních entit (jejich Ano, bude implementováno na míru
reprezentací ve formě DB záznam a AIP) Zadavateli.
uvnitř systému
Správa lokace papírového archivu Ano, bude implementováno na míru
Zadavateli.
Kontroly konzistence dat Ano, předpokládáme v maximální možné
míře zabezpečit již na úrovni databázové
vrstvy a jejího návrhu pomocí integritních
omezení a normálních forem.
Vracení změn – popsáno v kapitole 1.2.7 Ano, bude implementováno dle best-practices
Verzování reprezentací archivních entit a v této oblasti a to pomocí specifických
možnosti obnovy předchozích verzí. architektonických návrhových vzorů typu
Command a Memento.
Tvorba standardizovaných a uživatelsky Ano, předpokládáme použití technologie
definovaných výstupů včetně statistik a grafů Apache Velocity, FreeMaker, JasperReports.
(generátor dokumentů) v PDF, XML, CSV a
editovatelných textových a tabulkových
formátech z balíku MS Office nebo Libre
Office
Komunikace se „vstupním a pracovním Ano, předpokladáme na základě datových
úložištěm vstupu“ balíčků, které budou definovány v rámci
technické analýzy.
Zobrazení metadat archivních entit včetně Ano, pomocí grafického výstupu v rámci
přístupu k datovému obsahu těchto entit, uživatelského rozhraní.
možnost stažení plného AIP
Strana 33/163
Vizuální porovnání dvou verzí metadatových Ano, předpokládáme integraci open source
částí (AIP XML) archivních entit, ať už vlastní nástroje třetí strany s liberální open source
funkcionalitou ESM nebo integrací vhodného licencí, která bude dodána Zadavateli v rámci
nástroje třetí strany výběrového řízení a bude splňovat požadavky
Zadávací dokumentace na licence
Vizuální porovnání strukturální mapy dvou Ano, v grafickém uživatelském prostředí
verzí
Realizace procesu verzování – verzování Ano, předpokládáme zapojení technologie
datových komponent (včetně přidávání Hibernate Envers, jako modulu ORM
digitalizátů) technologie Hibernate.
Dále přikládáme tabulku požadovaných nástrojů a jejich naplnění:
Samostatná uživatelská rozhraní pro správu a Ano, předpokládáme rozdělení uživatelského
zobrazení metadat jednotlivých typů rozhraní dle tohoto požadavku.
archivních entit a lokace papírového archivu.
Součástí rozhraní bude strukturovaný
seznam funkčních odkazů na související
archivní entity (dle jejich jednotlivých typů)
Nástroje pro realizaci operací s archivními Ano, bude implementováno na míru
entitami, včetně nástroje pro dělení datového Zadavateli.
obsahu
Nástroj pro zobrazení datového obsahu Ano, bude řešeno přímo na obrazovke detailu
jednotlivých archivních entit s možností dané archivní entity.
zobrazení nebo stažení dokumentů (digitální
komponenty, metadatového AIP XML i SIP
XML a plného AIP)
Nástroje pro údržbu a rekonstrukci databáze Ano, zčásti řešeno technologií LiquiBase pro
(vracení předchozích verzí reprezentací verzování struktury databáze a dále řešeno
archivních entit, výměna číselníků, na úrovní evidování historie změn
reindexace) jednotlivých klíčových položek.
Nástroje pro validaci vyplnění a správnosti Ano, bude implementováno na míru
vyplnění povinných polí záznamu, kontrolu Zadavateli.
konzistence, správnosti přepisu do
souvisejících databázových záznamů či zápisu
do AIP
Rozhraní pro komunikaci s moduly celku Ano, řešeno na úrovni architektury.
Výběr (včetně pracovního úložiště a se všemi
moduly celku Správa, případně s dalšími
Strana 34/163
moduly dle návrhu uchazeče.
Nástroj pro porovnání metadat verzí Ano,předpokládáme využítí stejného
archivních entit – jednoduché grafické mechanismu jako pro porovnání XML
rozhraní s barevným zvýrazněním změn ve struktur. Řešeno formou obrazovky pro
verzích kterou jsou vstupem dvě porovnávané entity
a na výstupu zobrazí dvě paralelní tabulky
metadat se zvýrazněním rozdílů.
Databázový nástroj pro přidělování a správu Ano, implicitní číselnou řadou, konzistence
interních identifikátorů AIS může být řízena přímo na úrovni integritních
omezení databáze.
Vybrané nástroje z modulu Kontejner Ano, realizované a popsané v rámci
(generátor výstupů a statistik, validace komponenty Kontejner.
kontrolních součtů atd.)
4.1.3.5 Modul Zápis
V rámci modulu Zápis předpokládáme využití zejména našeho know-how a zkušeností z oblasti
archivů a evidenčních systémů. Samotná logika zápisu a tvorby AIP budou vyvinuta Zadavateli
na míru dle technické analýzy.
Pro úplnost přikládáme tabulku požadovaných procesů a jejich naplnění:
Tvorba AIP archivních entit na základě Ano, bude implementováno na míru
databázových záznamů a případného Zadavateli s využitím existujícího know-how
datového obsahu (SIP, mateřských AIP, a zkušeností.
digitálních komponent tvořících dohledanou
archiválii a souborů z modulu Archivní
zpracování)
Zápis aktualizovaných metadat existujících Ano, implicitně v rámci logiky modulu.
AIP, včetně identifikátorů NDA (tvorba nové
verze AIP XML)
Ukládání vytvořených AIP v hlavním úložišti Ano, pomocí integračního rozhraní Hlavního
AIS úložiště AIS
A taktéž tabulku požadovaných nástrojů a jejich naplnění:
Nástroj, který bude schopen z databázového Ano, implicitně v rámci logiky modulu.
záznamu a datového obsahu vytvořit AIP,
umožní tedy vytvoření AIP XML, zapsání
všech údajů, vytvoření struktury AIP
Strana 35/163
Rozhraní pro komunikaci s moduly ESM a Ano, implicitně v rámci logiky modulu.
hlavní úložiště AIS Ano, implicitně v rámci logiky modulu.
Rozhraní pro komunikaci s pracovním
úložištěm celku Výběr
4.1.4 Modul pro archivní zpracování
Jako nástroj umožňující archivní zpracování v souladu se Základními pravidly pro zpracování
archiválií, tedy tvorbu archivního popisu jednotlivých archiválií a tvorbu archivních pomůcek,
řešitel použije v souladu s preferencí zadavatele software Elza.
Odkaz na dokumentaci systému Elza: http://elza-doc.lightcomp.cz . Software Elza bude muset
být dále upraven a nakonfigurován pro integraci v rámci AIS.
Pro úplnost přikládáme tabulku požadovaných procesů a jejich naplnění:
Rozhraní pro komunikaci s rejstříky (čtení, Ano, dnes již Elza takovým rozhraním
import a export rejstříkových hesel) disponuje.
Rozhraní pro komunikaci s ESM (import Ano, Elza nabízí rozhraní, avšak některé
vybraných metadat archiválií, přístup k budou muset být dokonfigurovány pro
datovému obsahu, odeslání souborů se potřeby AIS. Přesný rozsah integrace s ESM
zpracovanými pomůckami (a určených předpokládáme, že vyplyne z řádné analýzy.
metadat těchto pomůcek) do ESM)
Rozhraní pro modul vyhledávání (může být Ano, lze řešit formou pravidelného exportu
řešeno pravidelným indexováním databáze dat pro indexování. Při analýze bude nutné
modulu archivního zpracování do indexu pro zohlednit způsob přenosu oprávnění.
vyhledávání)
4.1.5 Modul rejstříky a metadata
Modul je databáze osobních a dalších rejstříků a původcovských metadat. Rozsah uchovávaných
informací je dán Základními pravidly pro zpracování archiválií. Uvažujeme tyto typy/třídy entit
pro účel tvorby rejstříků:
Třída entit osoba/bytost
● fyzická osoba
● fiktivní fyzická osoba
● bytost
● zvíře
Třída entit rod/rodina
● rod, rodina
Strana 36/163
● fiktivní rod, fiktivní rodina
● větev rodu
Třída entit korporace
● administrativně vymezená území s vlastní správou
● orgány, organizační složky a příspěvkové organizace veřejné správy
● sdružení organizací
● vojenské a bezpečnostní jednotky
● organizace založené za účelem podnikání
● politické organizace
● náboženské organizace a instituce
● kulturní, výchovné, výzkumné a zdravotnické organizace a instituce
● nadace a nadační fondy
● profesní a zájmové organizace
● spolky, společenské organizace
Třída entit geografický objekt
● administrativně či jinak lidmi vymezená území
● administrativně vymezené části přírody
● vymezené obvody a správní celky
● geomorfologické útvary na dně moře
● geomorfologické útvary na zemském povrchu
● vodstvo a vodní plocha, vodní tok
● pojmenované útvary
● pojmenované trvalé klimatické jevy
● Vesmír a jeho části
Třída entit událost
● organizované akce a události
● lidové zvyky, významné dny a svátky
● dočasné přírodní jevy
Třída entit dílo/výtvor
● autorská a umělecká díla
● všeobecně známé dokumenty, smlouvy, zákony, předpisy, normy
● vyznamenání, ceny, soutěžní trofeje
● výrobky a jejich typová označení, obchodní značky, odrůdy, plemena vytvořená
člověkem
● názvy společenských, dětských her
● programy, projekty, granty, rozvojové plány, kampaně, nemají-li charakter korporace
● stavby, trasy, zásahy do přírodních útvarů s vlastním jménem nebo jinou identifikací
Třída entit obecný pojem
Strana 37/163
● nepojmenované objekty a jejich fyzické části
● kategorie a skupiny nepojmenovaných osob
● kategorie a skupiny nepojmenovaných korporací
● materiály a techniky
● formy a žánry
● binominální nomenklatura
● abstraktní entity
Rozsah uchovávaných informací vychází ze současných požadavků Základních pravidel, avšak
navrhujeme reflektovat vývoj v oblasti vznikajícího Centrálního archivního modulu. Pro správu
tohoto typu entit navrhujeme využít aplikaci Elza a její modul pro správu Přístupových bodů.
Modul je plně konfigurovatelný a umožňuje uchovávat informace o entitách pocházejících z
jiných systémů, včetně externích identifikátorů těchto entit, vytvářet vazby mezi entitami,
hromadně je importovat. Elza umožňuje přímou integraci s dalšími systémy, v současné době již
realizuje integraci s INTERPI.
Výhoda tohoto přístupu je v tom, že v rámci vývoje aplikace Elza bude připravena struktura
přístupových bodů odpovídající Základním pravidlům a dohodnutým archivním metodikám.
Předpokládáme vznik specializovaného modulu pro integraci se službou Whois.
Termín “extrakce metadat” považujeme za ne zcela přesně zadavatelem definovaný. Moduly pro
výběr archiválií zajistí přípravu jejich metadat a správné zaznamenání v odpovídajících
modulech. Zde konkrétně o předání informací o původcích či jiných významných entitách do
modulu rejstříků. Proces výběru musí zajistit provedení a mapování metadat dle definovaných
požadavků jak do jednotlivých balíčků, tak zajistit jejich správnou indexaci.
Ukázka modulu správy osob / původců
Pro úplnost zde přikládáme i tabulku požadavků a způsob jejich naplnění:
Řízení extrakce metadat Realizováno v modulu výběr, předání do
Strana 38/163
modulu Elza
Kontrola konzistence dat, deduplikace, Stávající aplikace Elza udržuje data
opravy dat konzistentní, je možné provádět vyhledání
míst užití záznamu, jeho nahrazování a
deduplikace.
Přístup do aplikace INTERPI, případně do Elza umožňuje přímé stahování dat z
budoucí externí databáze archivních původců INTERPI. V rámci jejího vývoje bude
(tento přístup zajistí i pro všechny ostatní připraven konektor do modulu CAM. Bude
komponenty AIS), přístup do systému WhoIs realizován konektor do systému WhoIs
Import jednotlivých rejstříkových hesel a Elza umožňuje dávkový i individuální import
dávek rejstříkových hesel pomocí XML formátu.
Vytváření rejstříkových hesel uživateli Elza má uživatelské rozhraní pro plnou
systému, jejich správa správu přístupových bodů / rejstříkových
hesel.
4.1.6 Vnější zpřístupnění
Pro implementaci tohoto modulu navrhujeme využít jako základ produkt iQ Discovery, který je
publikován jako open source pod licencí GNU Affero General Public License v3.0, viz.
https://github.com/InQool/IQ-Discovery. Část webové badatelny obecně předpokládáme
oddělit od zbytku systému, jelikož bude sloužit zejména (ale nikoliv výlučně) pro externí
uživatele. Mezi základní funkce webové badatelny patří možnost registrace a přihlášení pro
veřejné uživatele (badatele), tyto předpokládáme přes standardní nástroje Zadavatele. Následně
je umožněno prohledávání veřejné části archivu (pokud existuje), prohlížení metadatového
obsahu zpřístupněného veřejně nebo adhoc na základě žádosti badatele, případně stáhnutí
digitálních komponent balíků. Samostatnou částí je vyplňování a podávání žádostí o
zpřístupnění ve formě formulářů. Tyto jsou následně zpracovány Modul má svou vlastní
zpřístupňovací databázi a řízení přístupových oprávnění. Zpravidla je i na úrovni infrastruktury
oddělen pro lepší řízení přístupu mimo sítě Zadavatele.
Na následujících screenshotech jsou k nahlédnutí nabízené komponenty a možnosti jejich
realizace:
Strana 39/163
Vstupní portál veřejné části badatelny
Vyhledávání v badatelně se zobrazením faset a metadat
Strana 40/163
Detail obrazové části dokument s možností listování a zoomování
Detail metadatové části dokumentu
Pro úplnost zde přikládáme tabulku požadavků webové badatelny a způsob jejich naplnění:
Vyhledávání v přístupném datového obsahu Ano, přímo v grafickém rozhraní, viz.
celku Vnějšího zpřístupnění přiložené screenshoty.
Zobrazení informací o archivních souborech Ano, přímo v grafickém rozhraní, viz.
přiložené screenshoty.
Zobrazení archivních pomůcek (v textové a Ano, bude implementováno v grafickém
strukturované podobě) rozhraní webové badatelny. Částečně
viditelné v přiložených screenshotech.
Zobrazení a případně stažení zpřístupněných Ano, bude implementováno v grafickém
digitálních a digitalizovaných archiválií rozhraní webové badatelny.
Komunikace se správcem badatelny, tvorba Ano, pomocí žádostí, kterých součástí je
objednávek nezveřejněných archiválií, badatelský formulář. Dále pomocí interních
zobrazení přehledu aktivity na badatelském zpráv mezi badatelem a správcem v rámci
účtu žádosti. Aktivita badatelského účtu je
zobrazena v rámci historie účtu.
Strana 41/163
A taktéž tabulku požadovaných nástrojů a jejich naplnění:
Nástroj pro vyhledávání v přístupném Ano, přímo v grafickém rozhraní, viz.
datovém obsahu celku Vnější zpřístupnění přiložené screenshoty.
Ano, přímo v grafickém rozhraní, viz.
Nástroj pro zobrazení informací o archivních přiložené screenshoty.
souborech, digitálních a digitalizovaných
archiválií a pomůcek. Ano, v rámci účtu badatele s přepojením na
správu badatelny.
Nástroj pro komunikaci se správcem
badatelny
Správa badatelny doporučujeme realizovat v stejné komponentě jako exportní modul, nicméně
je možnost provozu i oddělených komponent, toto specifikum bude zachyceno v implementační
analýze. V rámci tohoto administrátorského rozhraní můžou oprávněný uživatelé spravovat
uživatelské účty, udělovat ad-hoc přístupové oprávnění k balíkům, spravovat žádosti badatelů o
nahlížení a nastavovat parametry/obsah badatelny.
Seznam žádostí o nahlížení
Detail žádostí o nahlížení s možnosti schválení/zamítnutí/vrácení
Strana 42/163
Ad-hoc zpřístupnění dokumentů bez žádosti
Náhled způsobu řešení statistik
Strana 43/163
Seznam a správa badatelů
Potenciální složení karty badatele
Pro úplnost zde přikládáme tabulku požadavků správy badatelny a způsob jejich naplnění:
Správa elektronických badatelských listů a s Ano, bude implementováno v grafickém
nimi propojených badatelských účtů – rozhraní správy badatelny. Předpokládáme
vytvoření, editace, tvorba tiskových výstupů. součástí žádostí o zpřístupnění, částečně
viditelné v přiložených screenshotech.
Evidence objednávek, správa skladu Ano, bude implementováno v grafickém
předkládaných papírových archiválií, rozhraní správy badatelny
evidence jejich předkládání
Vyhledávání v evidenci badatelů a evidenci Ano, bude implementováno v grafickém
individuálně zpřístupněných archiválií rozhraní správy badatelny. Částečně viditelné
v přiložených screenshotech.
Tvorba a správa statistických výstupů o Ano, bude implementováno v grafickém
využívání badatelny rozhraní správy badatelny. Částečně viditelné
v přiložených screenshotech.
Správa zpřístupněných archiválií v digitální Ano, bude implementováno v grafickém
Strana 44/163
podobě a přístupových práv k těmto rozhraní správy badatelny. Částečně viditelné
archiváliím v přiložených screenshotech.
Komunikace badatele se správcem badatelny Ano, bude implementováno v grafickém
a archiváři rozhraní správy badatelny v rámci žádostí a
prostřednictvím zpráv mezi badatelem a
správcem. Částečně viditelné v přiložených
screenshotech.
A taktéž tabulku požadovaných nástrojů a jejich naplnění:
Nástroj pro správu elektronických Ano, součástí správy badatelny.
badatelských listů a s nimi propojených
badatelských účtů – vytvoření, editace.
Nástroj pro tvorbu tiskových výstupů Ano, budou implementovány na míru
(badatelské listy, objednávky, priorační lístky, zadavateli dle dodaných šablon pomocí
statistické výstupy) existujících komponent pro generování
tiskových výstupů.
Nástroj pro evidenci objednávek Ano, bude implementován jako rozšíření
modulu Office.
Nástroj pro správu připravených a Ano, součástí správy badatelny.
zapůjčených analogových archiválií
Nástroj pro správu zpřístupněných digitálních Ano, součástí správy badatelny.
a digitalizovaných archiválií
Nástroj pro komunikaci mezi archivářem Ano, bude implementován jako rozšíření
(správcem badatelny) a badatelem modulu Office.
Rozhraní pro příjem dat z celku Správa Ano, standardně v rámci architektury.
(modulu Export)
4.1.7 Administrace
Administraci navrhujeme řešit formou samostatných administračních rozhraní pro jednotlivé
hlavní komponenty.
Pro úplnost zde přikládáme tabulku požadavků a způsob jejich naplnění:
Konfigurace systému Ano, předpokládáme klíčové konfigurační
atributy prezentovat i v rámci uživatelského
rozhraní. Komplexní konfiguraci
předpokládáme formou konfiguračního
souboru.
Správa přehledu uživatelských účtů (ve Ano, centrální přehled uživatelských účtů a
Strana 45/163
spojení s CAS) a možnost úprava nastavení základní nastavení rolí předpokládáme v
rolí (viz kapitola 3.2 přílohy č. 3 Smlouvy) administraci Vstupního portálu. Připouštíme
a předpokládáme, že na základě konkrétního
řešení požadavků individuálních komponent
můžou být specifické role a dílčí oprávnění
nastavována v administraci odpovídajících
komponent.
Sledování a řízení procesů (možnost pro Ano, jednotlivé procesy bude možné sledovat
správce systému sledovat procesy, jejich v rámci administrace komponent, ke kterým
historii, možnost je zastavit apod.) patří.
Správa a automatické přidělování interních Ano, předpokládáme implementováno jako
identifikátorů (včetně udržování přehledu o součást komponenty ESM.
všech přidělených identifikátorech). Bude
předmětem jednání, může být součástí ESM.
Administrace úložišť celků Výběr, Správa a Ano, implementováno v jednotlivých
Vnější zpřístupnění odpovídajících komponentách.
4.1.8 Kontejner
Tuto komponentu předpokládáme realizovat jako sadu technologických komponent, které
budou dle své povahy dostupné celému systému nebo některým jeho částem.
Pro úplnost zde přikládáme tabulku požadavků a způsob jejich naplnění:
Nástroj pro detekci škodlivého kódu Ano, předpokládáme integraci antivirového
(antivir/antimalware) programu Zadavatele ClamAV.
Validátor SIP dle NSESSS Ano, předpokládáme vlastní implementaci
validátoru.
Validátor PDF/A (Zadavatel doporučuje Ano, akceptuje návrh Zadavatele.
veraPDF)
Nástroj pro formátovou analýzu (Zadavatel Ano, akceptuje návrh Zadavatele.
doporučuje DROID)
Generátor pro tvorbu PDF/A, CSV a XML Ano, předpokládáme použití technologie
dokumentů obsahujících seznamy a další Apache Velocity, FreeMaker, JasperReports.
dokumenty dle předem či uživatelem daných
šablon a filtrů (statistiky, protokoly
jednotlivých řízení, výstupy pro papírovou
evidenci)
Nástroj pro tvorbu a kontrolu kontrolního Ano, předpokládáme využití nativních
Strana 48/163
Aplikace Elza má velmi bohatý konfigurační systém. Pomocí konfigurace je řešena implementace
modulu Základních pravidel i metodiky pro Přístupové body (rejstříky). Konfigurace je uložena v
databázi a je definována pomocí systému Drools (http://www.drools.org ). Jedná se o systém
business pravidel, která definují logiku aplikace. Tento způsob konfigurace je výhodný u
složitějších expertních systémů.
4.3 Návrh požadavků na technické a technologické prostředky zadavatele
Na infrastruktuře Zadavatele určitě navrhujeme zřízení samostatného testovacího a
produkčního prostředí. Doporučujeme, aby testovací prostředí mělo stejnou topologii jako
produkční s rozdílem sníženého výkonu. V rámci infrastruktury předpokládáme zřízení i
školícího prostředí dle požadavku kap. 2.4.6 přílohy č. 9 Zadávací dokumentace, doporučujeme
využití způsobu č. 1 a tedy oddělenou kompletní školící instanci AIS, kterou je možné řízenou
obnovou dat nastavit do čistého stavu připraveného pro školení různých scénářů (technických i
uživatelských).
Z pohledu infrastruktury navrhujeme na konceptuální úrovni topologii a rozložení virtuálních
strojů, která je zachycena na následujícím diagramu. Doplňujeme, že se jedná o definici topologie
bez detailní definování přestupů mezi jednotlivými virtuálními stroji, komunikačních protokolů
a portů. Tato bude předmětem úvodní technické analýzy. Topologie respektuje výchozí
představu Zadavatele o dostupnosti Vstupního portálu jak pro interní uživatele, tak pro
veřejnost. Virtuální stroj č. 7, na kterém je umístěn Vstupní portál, je tedy na hranici extranetu a
intranetu a je dostupný pro interní i externí uživatele. V popise modulu Vstupní portál jsme
definovali variantu k diskuzi se Zadavatel, v rámci které by Vstupní portál byl určen jen pro
interní uživatele a celý virtuální stroj č. 7 by se tedy přesunul do intranetu Zadavatele. Funkci
vstupního portálu pro veřejnost by plnila Badatelna na virtuálním stroji č. 8, který je standardně
součástí extranetu Zadavatele a dostupný veřejnosti. Jednotlivé komponenty logického rozdělení
jsou rozmístěny na odpovídající virtuální stroje. Pro úplnost uvádíme, že komponenta ELZA
umístěna na virtuálním stroji č. 2 obsahuje modul pro archivní zpracování a modul rejstříky a
metadata.
Strana 49/163
Sizing jednotlivých virtuálních strojů v produkčním prostředí navrhujeme s respektování HW
prostředí Zadavatele popsané v kapitole 3.1 Přílohy č. 5 Smlouvy následovně:
Počet vCores Velikost RAM v GB
Virtuální stroj č. 1 4 8
Virtuální stroj č. 2 4 6
Virtuální stroj č. 3 6 18
Virtuální stroj č. 4 4 6
Virtuální stroj č. 5 4 8
Virtuální stroj č. 6 4 6
Strana 50/163
Virtuální stroj č. 7 2 4
Virtuální stroj č. 8 2 4
Pracovní úložiště č. 1 2 12
Pracovní úložiště č. 2 2 8
Pracovní úložiště č. 3 2 8
Pracovní úložiště č. 4 2 8
Pracovní úložiště č. 5 2 8
Index 8 24
Rozdělení na konkrétní fyzické servery necháváme na rozhodnutí Zadavatele. Předpokládáme,
že zde uvedený sizing bude upraven na základě vstupu Zadavatele v rámci vypracování
technické analýzy. Diskový prostor uvedený v kap. 3.1 přílohy zadávací dokumentace je
dostačující pro zde vyčtené virtuální stroje a předpokládáme, že bude přidělován on-demand.
4.4 Dokumentace
Vybrané moduly budou podporovat kontextovou nápovědu, pro zobrazení informací přímo v
grafickém uživatelském rozhraní u jednotlivých ovládacích prvků. Konkrétní umístění
kontextových nápověd bude zachyceno v implementačním projektu a bude se řídit objektivními
technickými možnostmi řešení. Nápověda bude dodána i ve formátu PDF, který bude možné
vyvolat a zobrazit přímo z uživatelského prostředí. Taktéž bude možné dokumentaci v tomto
formátu uložit lokálně.
4.5 Výstupy AIS do tiskových a dalších formátů
Zde deklaruje, že nabízené řešení bude podporovat požadované tiskové sestavy a jejich
vlastnosti zachyceny v kapitole 2.4.6 přílohy č. 9 zadávací dokumentaci.
Strana 51/163
5 PODROBNÝ POPIS VYBRANÝCH ČÁSTÍ NABÍZENÉHO ŘEŠENÍ A POPIS
REALIZACE POŽADOVANÝCH PROCESŮ
5.1 A) Popis realizace archivního zpracování archivního souboru (včetně
přemanipulace a vytvoření archivní pomůcky) v systému
Případová studie bude popsána formou scénáře s rekapitulací stavu po jednotlivém kroku.
Výchozí stav:
Archivní soubor obsahuje celkem 10 archiválií (=evidenčních jednotek = AIP), které náleží do
jednoho archivního souboru: 5 balíků, 5 digitálních datasetů. Všechny archiválie jsou
nezpracované.
Entity v systému ve výchozím stavu (v ESM a jako AIPy v úložišti):
Entita AIP v úložišti Metadata a popis
AS01
EJ01..EJ05 f_00000001_v00001 archivní soubor
EJ06..EJ10 a_00000001_v00001 - typ entity: archiválie, typ EJ: balík, archivní
a_00000005_v00001 soubor: AS01, stav: NEZPRACOVANÁ
a_00000006_v00001 - typ entity: archiválie, typ EJ: digitální dataset,
a_00000010_v00001 archivní soubor: AS01, stav: NEZPRACOVANÁ
Nové entity vzniklé v daném kroku jsou vyznačeny tučně.
Cílový stav:
1 archivní pomůcka typu inventář Archivní soubor obsahuje celkem 20 archiválií (=evidenčních
jednotek = AIP), které náleží do téhož archivního souboru: 5 tisků, 5 analogových neevidovaných
jednotlivostí, 5 úředních knih, 5 digitálních archivních jednotek. Všechny archiválie jsou
inventarizované v nově vytvořeném inventáři.
5.1.1 Krok č. 1 Příprava zpracování
Při přípravě pořádání dojde k identifikaci obsahu balíků (nezpracovaných archiválií). Na základě
provedených zjištění bude v ESM provedena vnitřní změna vedoucí ke vzniku pěti tisků, pěti
úředních knih a pěti analogových neevidovaných archiválií. S ohledem na to, že se jedná o
fyzické archiválie, tak při změně bude odebráno 5 původních balíků, které obsahovaly
identifikované archiválie.
Součástí uvedené vnitřní změny bude změna typu evidenční jednotky u pěti digitálních datasetů
na digitální archivní jednotku.
Strana 52/163
Technický způsob realizace: Změna se provede v ESM, na základě provedené změny dojde k
vytvoření nových AIPů a jejich uložení do hlavního úložiště. Uložení AIPů se provede
prostřednictvím modulu Zápis.
Entity v systému po kroku 1:
Entita AIP v úložišti Metadata a popis
AS01
EJ01..EJ05 f_00000001_v00001 archivní soubor
EJ06..EJ10 a_00000001_v00002 - typ entity: archiválie, typ EJ: balík, archivní soubor:
a_00000005_v00002 AS01, stav: ROZDĚLENY
a_00000006_v00002 - typ entity: archiválie, typ EJ: digitální archivní
a_00000010_v00002 jednotka, archivní soubor: AS01, stav:
ROZPRACOVANÁ
EJ11..EJ15 a_00000011_v00001 -
EJ16..EJ20 a_00000015_v00001 typ entity: archiválie, typ EJ: úřední kniha, archivní
EJ21..EJ25 soubor: AS01, stav: ROZPRACOVANÁ
a_00000016_v00001 -
a_00000020_v00001 typ entity: archiválie, typ EJ: tisk, archivní soubor:
AS01, stav: ROZPRACOVANÁ
a_00000021_v00001 -
a_00000025_v00001 typ entity: archiválie, typ EJ: neevidovaná
jednotlivost, archivní soubor: AS01, stav:
VZ01 i_00000001_v00001 ROZPRACOVANÁ
typ entity: vnitřní změna, výsledek kroku 1,
archivní soubor: AS01
typ změny: přemanipulace
evidenční jednotky: -5 balíků, +5 úřední kniha, +5
tisk, +5 neevidovaná jednotlivost
Poznámka 1: Vnitřní změnu by bylo možné také realizovat jako více parciálních vnitřních změn.
5.1.2 Krok č. 2 Tvorba archivního popisu
Archivní popisu bude vytvořen v modulu Elza. Na vyžádání uživatele dojde k načtení
rozpracovaných EJ/archiválií, resp. jejich balíčků do aplikace. Načtení bude provedeno z ESM
pomocí webových služeb Elza. Načtené EJ budou připojeny k vytvořenému archivnímu popisu.
Entity v systému po kroku 2:
Entity budou beze změny a shodné s výsledkem kroku 1
5.1.3 Krok č. 3 Archivní pomůcka a její schválení
V modulu Elza bude na základě připraveného archivního popisu v kroku 2 vytvořena archivní
pomůcka. Archivní pomůcka bude předložena k oponentuře a proběhne její schválení. Schválená
archivní pomůcka bude z aplikace Elza exportována pro publikaci a vytvoření záznamů o
zpracování do ESM. V ESM bude u zpracovaných archiválií vyznačen odpovídající stav (zde
Strana 53/163
konkrétně “INVENTARIZOVANÁ”). Současně dojde ke vzniku vnitřní změny s informací o
zpracování.
Entity v systému po kroku 3:
Entita AIP v úložišti Metadata a popis
AS01
EJ01..EJ05 f_00000001_v00001 archivní soubor
EJ06..EJ10 a_00000001_v00002 - typ entity: archiválie, typ EJ: balík, archivní soubor:
a_00000005_v00002 AS01, stav: ROZDĚLENY
a_00000006_v00003 - typ entity: archiválie, typ EJ: digitální archivní
a_00000010_v00003 jednotka, archivní soubor: AS01, stav:
INVENTARIZOVANÁ
EJ11..EJ15 a_00000011_v00002 -
EJ16..EJ20 a_00000015_v00002 typ entity: archiválie, typ EJ: úřední kniha, archivní
EJ21..EJ25 soubor: AS01, stav: INVENTARIZOVANÁ
a_00000016_v00002 -
a_00000020_v00002 typ entity: archiválie, typ EJ: tisk, archivní soubor:
AS01, stav: INVENTARIZOVANÁ
a_00000021_v00002 -
a_00000025_v00002 typ entity: archiválie, typ EJ: neevidovaná
jednotlivost, archivní soubor: AS01, stav:
VZ01 i_00000001_v00001 INVENTARIZOVANÁ
AP01 p_00000001_v00001 typ entity: vnitřní změna, výsledek kroku 1
VZ02 i_00000002_v00001 archivní soubor: AS01
typ změny: přemanipulace
evidenční jednotky: -5 balíků, +5 úřední kniha
(nezpracováno), +5 tisk (nezpracováno), +5
neevidovaná jednotlivost (nezpracováno)
typ entity: archivní pomůcka, exportovaná archivní
pomůcka
typ entity: vnitřní změna, výsledek kroku 3
archivní soubor: AS01
typ změny: zpracování archiválií
odkaz na AP: p_00000001_v00001
evidenční jednotky: -5 úřední kniha
(nezpracováno), +5 úřední kniha
(inventarizováno), -5 tisk (nezpracováno), +5 tisk
(inventarizováno), -5 neevidovaná jednotlivost
(nezpracováno), +5 neevidovaná jednotlivost
(inventarizováno)
Strana 54/163
5.2 B) Koncept uživatelského rozhraní (popis nebo grafické schéma)
Koncept uživatelského rozhraní webové badatelny je prezentován v kapitole 4.1.6. Pro
přehlednost uvádíme stejné screenshoty i zde. Dále u jednotlivých screenshotů explicitně
popisujeme významné ovládací prvky.
Vstupní portál veřejné části badatelny
Komponenty uživatelského rozhraní:
● Header s názvem badatelny, customizovatelným textem a polem pro globální fulltext
vyhledávání
● Oblast pro aktuality a novinky, s uživatelskou editaci, možností napojení na RSS
● Publikace článků/obsahu
● Statisticky dopočítávané výstupy (počet předmětů, časová osa atd.)
Strana 55/163
Vyhledávání v badatelně se zobrazením faset a metadat
Komponenty uživatelského rozhraní:
● Detailní definice vyhledávání
● Facetové filtrování (dynamicky dopočítávané počty výsledků ve facetách)
● Detail předmětu s výběrem metadat přímo ve výsledcích
● Stránkování a změna zobrazování (detail vs. seznam)
● Změna řazení
Detail obrazové části dokument s možností listování a zoomování
Komponenty uživatelského rozhraní:
● Samostatný komplexní prohlížeč s fullscreen režimem
● Náhled stránek
● Zoomování
● Umístňování vodoznaku
● Vyhledávání v textové vrstvě fulltext
Strana 56/163
Detail metadatové části dokumentu
Komponenty uživatelského rozhraní:
● Tisk, export
● Přidání do schránky
● Zobrazení struktury metedat
● Náhledový obrázek
V rámci uživatelského účtu budou taktéž dostupny požadované funkce pro komunikaci badatelů
se správci, vyplňování a výměna badatelských listů
Samozřejmostí je úprava badatelny dle požadavků zadávací dokumentace, zde uvedené náhledy
a komponenty slouží pro představu Zadavateli o vlastnostech produktu a budou během
implementace předmětem rozvoje. Závěrem uvádíme, že badatelny postaveny na zde nabízeném
produktu je možné prohlédnout i v produkčním provozu na adresách:
● eBadatelna Zlínskeho kraje - https://ebadatelna.zlkraj.cz/
● eBadatelna Středočeského kraje - https://pkd.kr-stredocesky.cz/
Strana 57/163
Strana 58/163
Strana 59/163
Strana 60/163
Strana 62/163
Doložka konverze do dokumentu obsaženého v datové zprávě
Tento dokument, který vznikl převedením vstupu v listinné podobě do podoby elektronické pod
porǎ dovým cí̌ slem 601022_018681, skládající se z 5 listů, se doslovně shoduje s obsahem vstupu.
Zajišťovací prvek: bez zajišťovacího prvku
Jméno a příjmení osoby, která konverzi provedla: Radka Křižková
Vystavil: Česká pošta, s.p.
Pracoviště: Brno 2
Česká pošta, s.p. dne 17.04.2019
117945839-18341-190417150111
Strana 63/163
Strana 64/163
Strana 65/163
Strana 66/163
Strana 67/163
Strana 68/163
Strana 69/163
Strana 71/163
Doložka konverze do dokumentu obsaženého v datové zprávě
Tento dokument, který vznikl převedením vstupu v listinné podobě do podoby elektronické pod
porǎ dovým cí̌ slem 601022_018705, skládající se z 8 listů, se doslovně shoduje s obsahem vstupu.
Zajišťovací prvek: bez zajišťovacího prvku
Jméno a příjmení osoby, která konverzi provedla: Radka Křižková
Vystavil: Česká pošta, s.p.
Pracoviště: Brno 2
Česká pošta, s.p. dne 17.04.2019
117953619-18341-190417170047
Strana 72/163
Strana 74/163
Doložka konverze do dokumentu obsaženého v datové zprávě
Tento dokument, který vznikl převedením vstupu v listinné podobě do podoby elektronické pod
porǎ dovým cí̌ slem 601022_018707, skládající se z 2 listů, se doslovně shoduje s obsahem vstupu.
Zajišťovací prvek: bez zajišťovacího prvku
Jméno a příjmení osoby, která konverzi provedla: Radka Křižková
Vystavil: Česká pošta, s.p.
Pracoviště: Brno 2
Česká pošta, s.p. dne 17.04.2019
117953947-18341-190417170533
Strana 76/163
Doložka konverze do dokumentu obsaženého v datové zprávě
Tento dokument, který vznikl převedením vstupu v listinné podobě do podoby elektronické pod
porǎ dovým cí̌ slem 601022_018710, skládající se z 1 listů, se doslovně shoduje s obsahem vstupu.
Zajišťovací prvek: bez zajišťovacího prvku
Jméno a příjmení osoby, která konverzi provedla: Radka Křižková
Vystavil: Česká pošta, s.p.
Pracoviště: Brno 2
Česká pošta, s.p. dne 17.04.2019
117954047-18341-190417170828
Strana 77/163
Strana 78/163
Strana 79/163
Strana 80/163
Strana 81/163
Strana 82/163
Strana 83/163
Strana 84/163
Strana 86/163
Doložka konverze do dokumentu obsaženého v datové zprávě
Tento dokument, který vznikl převedením vstupu v listinné podobě do podoby elektronické pod
porǎ dovým cí̌ slem 601022_018711, skládající se z 9 listů, se doslovně shoduje s obsahem vstupu.
Zajišťovací prvek: bez zajišťovacího prvku
Jméno a příjmení osoby, která konverzi provedla: Radka Křižková
Vystavil: Česká pošta, s.p.
Pracoviště: Brno 2
Česká pošta, s.p. dne 17.04.2019
117954104-18341-190417171253
Strana 87/163
Strana 89/163
Doložka konverze do dokumentu obsaženého v datové zprávě
Tento dokument, který vznikl převedením vstupu v listinné podobě do podoby elektronické pod
porǎ dovým cí̌ slem 601022_018712, skládající se z 2 listů, se doslovně shoduje s obsahem vstupu.
Zajišťovací prvek: bez zajišťovacího prvku
Jméno a příjmení osoby, která konverzi provedla: Radka Křižková
Vystavil: Česká pošta, s.p.
Pracoviště: Brno 2
Česká pošta, s.p. dne 17.04.2019
117954231-18341-190417171551
Strana 90/163
Strana 92/163
Doložka konverze do dokumentu obsaženého v datové zprávě
Tento dokument, který vznikl převedením vstupu v listinné podobě do podoby elektronické pod
porǎ dovým cí̌ slem 601022_018713, skládající se z 2 listů, se doslovně shoduje s obsahem vstupu.
Zajišťovací prvek: bez zajišťovacího prvku
Jméno a příjmení osoby, která konverzi provedla: Radka Křižková
Vystavil: Česká pošta, s.p.
Pracoviště: Brno 2
Česká pošta, s.p. dne 17.04.2019
117954298-18341-190417171905
Strana 93/163
Strana 94/163
Strana 95/163
Strana 96/163
Strana 97/163
Strana 98/163
Strana 99/163
Strana 100/163
Strana 102/163
Doložka konverze do dokumentu obsaženého v datové zprávě
Tento dokument, který vznikl převedením vstupu v listinné podobě do podoby elektronické pod
porǎ dovým cí̌ slem 601022_018715, skládající se z 9 listů, se doslovně shoduje s obsahem vstupu.
Zajišťovací prvek: bez zajišťovacího prvku
Jméno a příjmení osoby, která konverzi provedla: Radka Křižková
Vystavil: Česká pošta, s.p.
Pracoviště: Brno 2
Česká pošta, s.p. dne 17.04.2019
117954357-18341-190417172520
Strana 103/163
Strana 105/163
Doložka konverze do dokumentu obsaženého v datové zprávě
Tento dokument, který vznikl převedením vstupu v listinné podobě do podoby elektronické pod
porǎ dovým cí̌ slem 601022_018716, skládající se z 2 listů, se doslovně shoduje s obsahem vstupu.
Zajišťovací prvek: bez zajišťovacího prvku
Jméno a příjmení osoby, která konverzi provedla: Radka Křižková
Vystavil: Česká pošta, s.p.
Pracoviště: Brno 2
Česká pošta, s.p. dne 17.04.2019
117954473-18341-190417172830
Strana 106/163
Strana 108/163
Doložka konverze do dokumentu obsaženého v datové zprávě
Tento dokument, který vznikl převedením vstupu v listinné podobě do podoby elektronické pod
porǎ dovým cí̌ slem 601022_018717, skládající se z 2 listů, se doslovně shoduje s obsahem vstupu.
Zajišťovací prvek: bez zajišťovacího prvku
Jméno a příjmení osoby, která konverzi provedla: Radka Křižková
Vystavil: Česká pošta, s.p.
Pracoviště: Brno 2
Česká pošta, s.p. dne 17.04.2019
117954503-18341-190417173117
Strana 109/163
Strana 111/163
Doložka konverze do dokumentu obsaženého v datové zprávě
Tento dokument, který vznikl převedením vstupu v listinné podobě do podoby elektronické pod
porǎ dovým cí̌ slem 601022_018683, skládající se z 2 listů, se doslovně shoduje s obsahem vstupu.
Zajišťovací prvek: bez zajišťovacího prvku
Jméno a příjmení osoby, která konverzi provedla: Radka Křižková
Vystavil: Česká pošta, s.p.
Pracoviště: Brno 2
Česká pošta, s.p. dne 17.04.2019
117946868-18341-190417151141
Strana 112/163
Strana 118/163
Strana 121/163
Strana 122/163
Doložka konverze do dokumentu obsaženého v datové zprávě
Tento dokument, který vznikl převedením vstupu v listinné podobě do podoby elektronické pod
pořadovým cí̌ slem 410019_004579, skládající se z 10 listů, se doslovně shoduje s obsahem vstupu.
Zajišťovací prvek: bez zajišťovacího prvku
Jméno a příjmení osoby, která konverzi provedla: VLADIMÍRA GABRIELOVÁ
Vystavil: Česká pošta, s.p.
Pracoviště: Teplice 1
Česká pošta, s.p. dne 16.04.2019
117906357-13738-190416181252
Strana 126/163
adresát: LightComp v.o.s.
Drahobejlova 1452/54
190 00 Praha 9
Váš dopis značky/ze dne Naše značka (č.j.) Vyřizuje/ linka V Praze dne
05.11.2018 42413/004/8008/1719/18/Tru Alena Trubáková 08.11.2018
286 002 338
Potvrzení o stavu nedoplatků na pojistném na sociální zabezpečení a příspěvku na státní
politiku zaměstnanosti, penále a přirážce k pojistnému ve smyslu § 22 d zákona č.
589/1992 Sb., v platném znění.
Potvrzujeme, že právnická osoba:
LightComp v.o.s., Drahobejlova 1452/54, 190 00 Praha 9, IČ 25038249
nemá ke dni 8.11.2018 nedoplatek na pojistném a penále na sociální zabezpečení, příspěvku na
státní politiku zaměstnanosti a přirážce na pojistném.
Toto potvrzení se vydává na vlastní žádost právnické osoby.
Ing. Jana Jiroušková
vedoucí územního pracoviště
Strana 127/163
Výpis
z obchodního rejstříku, vedeného
Městským soudem v Praze
oddíl A, vložka 76563
Datum vzniku a zápisu: 16. června 1998
Spisová značka: A 76563 vedená u Městského soudu v Praze
Obchodní firma: LightComp v.o.s.
Sídlo: Drahobejlova 1452/54, Libeň, 190 00 Praha 9
Identifikační číslo: 250 38 249
Právní forma: Veřejná obchodní společnost
Předmět podnikání:
poradenství v oblasti informačních technologií
poskytování software
koupě zboží za účelem dalšího prodeje a prodej vyjma činností
uvedených v příl. č. 1-3 zák. č. 455/91 Sb. ve znění pozdějších
předpisů
Statutární orgán - společník:
Společník:
KAREL ŽÁČEK,
Společník:
PETR PYTELKA,
Společník: TOMÁŠ PYTELKA,
Způsob jednání: Den vzniku funkce: 19. prosince 2013
Společníci: Statutární orgán jedná ve všech věcech společnosti samostatně.
KAREL ŽÁČEK,
PETR PYTELKA,
TOMÁŠ PYTELKA,
Údaje platné ke dni: 27. listopadu 2018 03:39 1/1
Strana 132/163
Strana 133/163
Strana 134/163
Strana 135/163
Strana 137/163
Strana 139/163
Doložka konverze do dokumentu obsaženého v datové zprávě
Tento dokument, který vznikl převedením vstupu v listinné podobě do podoby elektronické pod
pořadovým číslem 601022_018682, skládající se z 11 listů, se doslovně shoduje s obsahem vstupu.
Zajišťovací prvek: bez zajišťovacího prvku
Jméno a příjmení osoby, která konverzi provedla: Radka Křižková
Vystavil: Česká pošta, s.p.
Pracoviště: Brno 2
Česká pošta, s.p. dne 17.04.2019
117946339-18341-190417150808
Strana 140/163
Strana 141/163
Strana 143/163
Doložka konverze do dokumentu obsaženého v datové zprávě
Tento dokument, který vznikl převedením vstupu v listinné podobě do podoby elektronické pod
porǎ dovým cí̌ slem 601022_018688, skládající se z 3 listů, se doslovně shoduje s obsahem vstupu.
Zajišťovací prvek: bez zajišťovacího prvku
Jméno a příjmení osoby, která konverzi provedla: Radka Křižková
Vystavil: Česká pošta, s.p.
Pracoviště: Brno 2
Česká pošta, s.p. dne 17.04.2019
117948233-18341-190417153041
Strana 144/163
Strana 145/163
Strana 147/163
Doložka konverze do dokumentu obsaženého v datové zprávě
Tento dokument, který vznikl převedením vstupu v listinné podobě do podoby elektronické pod
porǎ dovým cí̌ slem 601022_018691, skládající se z 3 listů, se doslovně shoduje s obsahem vstupu.
Zajišťovací prvek: bez zajišťovacího prvku
Jméno a příjmení osoby, která konverzi provedla: Radka Křižková
Vystavil: Česká pošta, s.p.
Pracoviště: Brno 2
Česká pošta, s.p. dne 17.04.2019
117949084-18341-190417154436
Strana 148/163
Strana 150/163
Doložka konverze do dokumentu obsaženého v datové zprávě
Tento dokument, který vznikl převedením vstupu v listinné podobě do podoby elektronické pod
porǎ dovým cí̌ slem 601022_018690, skládající se z 2 listů, se doslovně shoduje s obsahem vstupu.
Zajišťovací prvek: bez zajišťovacího prvku
Jméno a příjmení osoby, která konverzi provedla: Radka Křižková
Vystavil: Česká pošta, s.p.
Pracoviště: Brno 2
Česká pošta, s.p. dne 17.04.2019
117948656-18341-190417154002
Strana 151/163
Strana 153/163
Doložka konverze do dokumentu obsaženého v datové zprávě
Tento dokument, který vznikl převedením vstupu v listinné podobě do podoby elektronické pod
porǎ dovým cí̌ slem 601022_018687, skládající se z 2 listů, se doslovně shoduje s obsahem vstupu.
Zajišťovací prvek: bez zajišťovacího prvku
Jméno a příjmení osoby, která konverzi provedla: Radka Křižková
Vystavil: Česká pošta, s.p.
Pracoviště: Brno 2
Česká pošta, s.p. dne 17.04.2019
117947920-18341-190417152645
Strana 154/163
Strana 156/163
Doložka konverze do dokumentu obsaženého v datové zprávě
Tento dokument, který vznikl převedením vstupu v listinné podobě do podoby elektronické pod
porǎ dovým cí̌ slem 601022_018686, skládající se z 2 listů, se doslovně shoduje s obsahem vstupu.
Zajišťovací prvek: bez zajišťovacího prvku
Jméno a příjmení osoby, která konverzi provedla: Radka Křižková
Vystavil: Česká pošta, s.p.
Pracoviště: Brno 2
Česká pošta, s.p. dne 17.04.2019
117947787-18341-190417152341
Strana 158/163
Strana 160/163
Doložka konverze do dokumentu obsaženého v datové zprávě
Tento dokument, který vznikl převedením vstupu v listinné podobě do podoby elektronické pod
porǎ dovým cí̌ slem 117885323-114381-190416104958, skládající se z 3 listů, se doslovně shoduje s
obsahem vstupu.
Zajišťovací prvek: vodoznak
Jméno a příjmení osoby, která konverzi provedla: Simona Poupě
Vystavil: Městská část Praha 9
Pracoviště: Městská část Praha 9
Vystavil: Městská část Praha 9 dne 16.04.2019
117885323-114381-190416104958
Strana 161/163
Strana 163/163
Doložka konverze do dokumentu obsaženého v datové zprávě
Tento dokument, který vznikl převedením vstupu v listinné podobě do podoby elektronické pod
porǎ dovým cí̌ slem 601022_018689, skládající se z 2 listů, se doslovně shoduje s obsahem vstupu.
Zajišťovací prvek: bez zajišťovacího prvku
Jméno a příjmení osoby, která konverzi provedla: Radka Křižková
Vystavil: Česká pošta, s.p.
Pracoviště: Brno 2
Česká pošta, s.p. dne 17.04.2019
117948442-18341-190417153349