Zadávací dokumentace (ZD) k veřejné zakázce dle zákona č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů (dále jen „zákon“) Název veřejné zakázky: Dodávka SW pro evidenci katalogu kulturního dědictví

Zkratka	Vysvětlení
AIP	Archiv Information Package (archivní informační balík, archivní a technické informace ukládané uvnitř OAIS)
AIS	Aplikační informační systém
CAS	Content Addresable Storage, Content Addressed Storage Paměťové úložiště určené k dlouhodobému a garantovanému ukládání neměnného obsahu
CRR ČR CRR	Centrum pro regionální rozvoj České republiky
ČR	Česká republika
DIP	Dissemination Information Package, informační balík odvozený z AIP posílaný uživatelům (výstup)
DMS	Document Management System
DPH	Daň z přidané hodnoty
EK	Evropská komise
EU	Evropská unie
EX ANTE	Před zahájením (např. procesu)
EX POST	Po ukončení (např. procesu)
GUI	Graphics User Interface
HSM	Hierarchical Storage Management
HW	Hardware
IT	Infomační technologie
ICT	Informační a komunikační technologie
IDM	Identity Management System
IOP	Integrovaný operační program
IPS	Intrusion Prevention Systems – Systémy pro prevenci průniků
IPRM	Integrovaný plán rozvoje měst
IS	Informační systém
ISVS	Informační systémy veřejné správy
ISZR	Informační systém základních registrů
KAU	Krajské archivní úložiště
KDR	Krajské digitální repozitory (krajský digitální repozitář)
KDS	Krajská digitální spisovna
KDÚ	Krajské digitální úložiště
KúSK KUSK	Krajský úřad Středočeského kraje
MF ČR	Ministerstvo financí České republiky
MM Kladno	Magistrát města Kladna
MMR ČR	Ministerstvo pro místní rozvoj České republiky
MV ČR	Ministerstvo vnitra České republiky
OAI-PMH	Open Archives Initiative Protocol for Metadata Harvesting
OAIS	Open Archival Information Systém, základní norma na řešení archivů pro dlouhodobé uložení informací od původců a jejich správu
ORP	Obce s rozšířenou působností
PO	Příspěvková organizace (kraje)
Portál ZDO	Portál pro zpřístupnění digitálního obsahu
RSS	Formát RDF Site Summary
SIP PSP SIP	Podle standardu OAIS jsou tyto balíčky nazývány SIP Submission Information Package (balíčky přijímané od původců)
SK	Středočeský kraj
SOAP	Původně Simple Object Access Protocol, je protokolem pro výměnu zpráv založených na XML přes síť, hlavně pomocí HTTP
SP	Studie proveditelnosti
SVKK	Středočeská vědecká knihovna v Kladně
SW	Software
SZDO	Systém zpřístupnění digitálního obsahu
TC	Technologické centrum
TCK	Technologické centrum kraje
Tier	Kategorie datového úložiště
HTCK	Hlavní technologické centrum (kraje)
ÚSC	Územně samosprávný celek
VPN	Virtual Private Network – Virtuální privátní síť
VŘ	Výběrové řízení
VZ	Veřejná zakázka
WIKI	Informační místo (na portálu ZDO)
WS	Web Services
ZDO	Zpřístupnění digitálního obsahu
ZR	Základní registry
ZRe	Zpřístupňovací repozitář, představuje defakto integrační vazbu mezi KDR a Portálem ZDO
ZŘ	Zadávací řízení
ZTCK	Záložní technologické centrum (kraje)

2Úvod

Předkládaná veřejná zakázka „Dodávka SW pro evidenci katalogu kulturního dědictví“ (dále jen VZ) je součástí projektu „Krajské služby eGovernmentu Středočeského kraje“ financovaného z výzvy č. 19 IOP „Kontinuální výzva pro 6.2.1 Krajské služby eGovernmentu“.

Cílem tohoto projektu je navázat na výsledky realizovaného projektu „Rozvoj eGovernmentu ve Středočeském kraji“ a naplnit prostřednictvím 3 základních projektových aktivit tyto následující cíle:

Standardizace a centralizace služeb v rámci TCK, či zlepšení jejich úrovně již centrálně poskytovaných služeb pro organizace zřizované a zakládané krajem, příp. obce, ORP.
Aktualizovaná bezpečnostní politika TCK a nástroje pro řízení bezpečnosti, tj. výkonnější zabezpečení rozhraní sítí kraje a provozu aplikací včetně filtrace komunikace v sítích včetně možnosti řízení a filtrace na úrovni aplikací.
Rychlý, efektivní a bezpečný aplikační informační systém a vytvoření úložiště pro uložení a evidenci kulturního dědictví kraje včetně poskytování standardizovaných informačních služeb, zejména vytvoření Krajského digitálního repozitáře (KDR) pro ukládání dokumentů a ukládání informací o sbírkách dokládající kulturní dědictví v kraji (např. výstupy z digitalizace knihovny, muzea, galerie apod., fotografie, audio, video, vztahující se k regionu, dokumenty z regionálních webů, regionální periodika, další digitální dokumenty regionálního významu, evidence vybraných památek) a opatřeného potřebnými integracemi. Jedná se o aktivitu rozvoje TCK.

Jak z názvu VZ vyplývá, jejím základním účelem je naplnit cíle třetí aktivity. Pro potřeby kraje je vhodné vést v kraji centrální evidenci a správu sbírek kulturního dědictví a v rámci jednoho hostovaného informačního systému minimálně v rozsahu pro vlastní příspěvkové organizaci. Krajský digitální repozitář je garantované úložiště pro dlouhodobé uložení digitálních dokumentů, které jsou povahy kulturního dědictví a nejsou úředního charakteru. V rámci budování KDR v kraji se počítá zejména s ukládáním digitálních dokumentů mající regionální význam, které vznikly v souvislosti s daným územím. Digitální dokumenty jsou trvale uloženy v repozitáři slouží jako archivní kopie zásadních dokumentů regionálního významu a nepočítá se z jejich periodickou obnovou.

2.1Základní účel realizace VZ

Středočeský kraj v rámci evidence kulturního dědictví využívá především organizace zřízené krajem (příspěvkové organizace) jakožto paměťových instituce (knihovny, muzea, galerie, apod.). Kulturní dědictví mohou mít i obce ve SK. Jejich evidence nejsou v současné době systematicky řešena, způsob jejich zpřístupňování a poskytování laické a odborné veřejnosti je omezený a jednotlivé instituce nemají katalogy navzájem přístupné. Neexistuje jednotné koncepční řešení, které by přispívalo k postupnému naplňování národních strategických cílů v oblasti zpřístupňování digitálních dokumentů kulturního dědictví.

V rámci projektu Výzvy 08 vytvořil SK technologické centrum kraje (TCK) a následující datová úložiště v rámci TCK:

Krajská digitální spisovna (KDS) – určena k archivaci úředních dokumentů a spisů s předpokladem dlouhodobé archivace, implementována jako dlouhodobý archiv podle modelu OIAS a s využitím ukládacího zařízení s certifikací CAS (v TCK zařízení EMC Centera).
Krajské digitální úložiště (KDÚ) – ukládání dat a dokumentů, které pocházejí z činnosti informačních systémů kraje a je třeba je z nejrůznějších důvodů střednědobě až dlouhodobě ochránit proti ztrátě (geodata, záznamy z kamer, údaje z provozů IS apod.).

Jednalo se tedy o takzvanou první etapu ve vytváření „Systému digitálního archivu“ ve SK.

Druhá etapa je realizovaná právě touto zakázkou v rámci projektu Výzvy 19 se zaměřením na řešení a na poptávku SW pro evidenci katalogu kulturního dědictví – Krajský digitální repozitář (KDR).

Krajský digitální repozitář (KDR) – datové úložiště dokumentů a záznamů z oblasti kulturního dědictví regionu, plánovitě tedy zahrnuje vše, co lze považovat za informace s významem zachycení historie regionu.

KDS a KDR budou využívat jedno společné garantované úložiště realizované na technologii vybavení TCK. Pro účely dlouhodobé archivace je používaná v rámci TCK ukládací technologie typu CAS, která může být začleněna pod řízení HSM. Společné dlouhodobé a bezpečné úložiště pro dva archivní systémy KDS a KDR se též společně nazývá Krajské archivní úložiště (KAU).

Krajský digitální repozitář je doplněn v rámci jiné poptávky kraje v projektu Výzvy 19 o jednotný internetový portál pro zpřístupnění digitálního obsahu (Portál ZDO) určený odborné i laické veřejnosti jako prezentační vrstva dat uložených v KDR a skenovací linka pro digitalizaci dokumentových fondů organizací Středočeského kraje. Portál ZDO a skenovací linka není předmětem této zakázky a jejich poptávka a realizace proběhne souběžně s dodávkou SW pro evidenci katalogu kulturního dědictví.

Tato poptávka je tedy výhradně zaměřena na dodávku SW pro evidenci katalogu kulturního dědictví – krajský digitální repozitář (KDR) – SW technologie a aplikace. Součástí dodávky musí být jednoznačně i dodávka a přesná definice integračního rozhraní pro integraci s Portálem ZDO (prezentační vrstvu).

Základní postavení jednotlivých archivů (KDS, KDR, KDU) znázorňuje schematicky následující obrázek s tím, že poptávané úložiště je pouze KDR.

KDR musí podporovat řízení uživatelských oprávnění a to především pro přistupující organizace kraje, tj. musí být integrován se současným Identity Management systémem (IDM) Středočeského kraje. Zpřístupňovaná data z KDR prostřednictví Portálu ZDO bude poskytovat funkce a služby, které:

umožní zpřístupnit odborné i laické veřejnosti jedinečné bohatství fondů paměťových institucí,
přispějí k rozvoji edukace regionální problematiky na základních a středních školách,
poskytnou pedagogům dostatek informačních zdrojů k aplikaci v rámci moderních edukativních metod,
přispějí k rozvoji vědeckého bádání a poznání nejen v rámci ČR, ale celé Evropy (kdy jsou v paměťových institucích uloženy cenné sbírky, o nichž většinou odborná veřejnost nemá dosud povědomí),
podpoří ochranu vzácných a ohrožených dokumentů a zejména kvalitní služby badatelům (minimálně na úrovni snížení manipulačních poplatků, úspory času),
zpřístupní katalogy sbírek paměťových institucí mezi s sebou navzájem,
umožní správu oprávnění přístupu do aplikace napojením na krajský IDM.

Středočeský kraj předpokládá, že v dalších rozvojových aktivitách v oblasti evidence a propagace kulturního dědictví SK zajistí jednotný (pravděpodobně hostovaný jako aplikace v TCK) IS pro centrální evidenci sbírek resp. publikací. Takový informační systém bude vysoce specializovaný a variabilně nastavitelný pro vedení různých typů sbírek a velmi snadno integrovatelný s Portálem ZDO a KDR. Portál ZDO sám o sobě je jenom webová aplikace zaměřená na zpřístupnění přehledů sbírek, památek příp. dokumentů. Současný finanční limit v rámci aktivit Výzvy 19 v oblasti rozvoje kulturního dědictví neumožňuje IS pro centrální evidenci sbírek resp. dokumentů nyní pořídit.

2.2Cíl VZ, její očekávané výstupy, provázanost

Prostředkem pro naplnění výše uvedených cílů je vytvoření KDR (SW řešení pro ukládání informací z oblasti kulturního dědictví) – aplikačně technologické řešení s potřebnými integračními vazbami.

Vlastní zpřístupnění informací z KDR zajistí aplikace:

SW pro zpřístupnění digitálního obsahu archivu KDR – Portál ZDO, v rámci Výzvy 19.
Evidence sbírek a dokumentů nad KDR - v budoucnu zajistí jednotně detailní a specializovaná aplikace zaměřená cíleně pro tyto evidenční účely paměťových institucí kraje a s možností dalšího rozšíření o další organizace (vědecké, školské apod.). Tato aplikace není součástí této VZ ani tohoto projektu, pouze dodávka KDR.

Kromě dodávky KDR zadavatel dále požaduje zajistit před zahájením vlastní realizace implementační analýzu (studii) a po implementaci KDR záruční a pozáruční servis dodaných řešení po dobu udržitelnosti projektu a proškolení pracovníků obsluhující pracoviště skenovací linky a dodaného programového vybavení.

Cílem této zakázky je vytvoření předpokladu pro postupné naplňování KDR (technologie, aplikace, integrace, vytvoření úložiště a jeho nástrojů), nikoliv kompletní naplnění archivu hned od zahájení rutinního provozu. KDR se bude postupně plnit podle možností migrace informací a dat z jednotlivých paměťových institucí. KDR podporuje integraci na webové rozhraní pro zpřístupnění digitálního obsahu z KDR prostřednictvím webových služeb (Portál ZDO). Detailní popis VZ je uveden v kapitole č. 5.

Xxxxxxx realizace veřejné zakázky je vytvoření aplikačního řešení krajského digitálního repozitáře KDR) s cílem vytvořit datové úložiště KDR pro ukládání informací z oblasti kulturního dědictví a s cílem následně tyto informace zpřístupnit širokému spektru uživatelů v oblasti kultury a historie prostřednictvím portálu ZDO.

3Vybavení technologického centra

3.1Základní přehled SW a HW vybavení zadavatele

V této části je uveden přehled základního vybavení zadavatele z hlediska používaných SW a HW technologií používaných zadavatelem v TCK (již vysoutěžená nebo používaná technologie v TCK a na KúSK).

Oblast využití	Platforma	Popis
SW pracovní stanice KúSK	MS Office 2007/2010/2013 Std CZ MS Office 2002/2003 Std CZ	Převládající Dosud používaná (cca 100) Na SVKK a PO lze očekávat kteroukoliv verzi MS Office
Operační systémy – servery	Windows 2008/2012 EN Std/DataCtr/Extconn
Operační systémy – virtualizace	VMware, vSphere 5.x Enterprise plus	Nepožaduje se licenci rozšiřovat, HA cluster nad HTCK a ZTCK
Databáze	MS SQL server 2008/2012 Ent
Integrace	Různé
Portálová řešení Redakční systém	Liferay
Zálohování	Legato Networker	Zálohuje se na zařízení: Data Domain (disky, VTL) Tape Library
Firewall	Fortinet (FortiGate 300B)	Především zabezpečení perimetru a segmentace komunikace (DMZ)
Antivirová ochrana	Symantec Endpoint Protection	Komplexní řešení
Servery	DELL (samostatné + blade) DELL PoverEdge R720 DELL PE M1000e DELL PoverEdge M620 (blade srv)	Blade, samostatné servery racková provedení
Aktivní prvky LAN/WAN	Huawei (šasi, switche, CWDM)	Centrální switche, komunikace mezi lokalitami
SAN	FC Brocade 300	Fibre Channel 8 Gbit/s
Diskové pole	VNX 5300
Disková virtualizace	Falcon Stor
Zálohovací prostor	Data Domain DD620	Disky, VTL, komprimace na cíli
Tape Library	Dell PV 6030	Backup na pásky
Garantované úložiště	EMC Centera	Certifikace CAS
DMS pro KDÚ	DESA
Grafický SW	Adobe Photoshop
Monitoring v TCK	Nagios	Edice Open Source
Všechny uvedené technologie pracují na zdvojené architektuře hlavní a záložní TCK. Zadavatel na výše uvedené technologie předpokládá proškolené pracovníky. V případě dodávky rozdílných technologií vyžadujeme dodávku nové technologie v potřebném rozsahu včetně certifikovaných školení výrobcem zařízení a SW a kompletní aktuální dokumentaci pro administrátory!

3.2Popis vybavení TCK

Zadavatel již provozuje technologické centrum kraje (dále též „TCK“). Jádrem serverového řešení TCK jsou virtualizované ESX servery, které jsou umístěny do primární a vzdálené lokality. Pro potřeby poptávky je možné využít virtuální servery příp. cluster fyzických serverů pro databázové zpracování. Virtualizované prostředí je vytvořeno prostřednictvím OS VMware (verze 5.x), kde HW základ HA clusteru je tvořen 10ti blade servery s tím, že je 6 serverů v primární lokalitě a 4 ve vzdálené lokalitě. Jejich HW konfigurace je:

DELL PowerEdge M620 blade server
CPU Intel Xeon E5-2667 2.9 GHz, 15M Cache, six core
RAM 48 GB
HD 2x 146 GB + využitelný prostor na diskovém poli VNX 5300, Tier 0, Tier 1 (disková virtualizace podporovaná technologií Falcon Stor)
Ethernet 10 Gbit/s
Fibre Channel 8 Gbit/s
Operační prostředí pro virtualizaci: VMware 5.x Ent, load balancing
Operační systém pro klienta nad vrstvou VMware: Windows 2012 Srv DataCtr

Databázový cluster (activ-pasiv) je tvořen blade servery následující konfigurace:

DELL PowerEdge M620 blade server
CPU Intel Xeon E5-2667 2.9 GHz, 15M Cache, six core
RAM 48 GB
HD 2x 146 GB + využitelný prostor na diskovém poli VNX 5300, Tier 0, Tier 1
Ethernet 10 Gbit/s
Fibre Channel 8 Gbit/s
Operační systém: Win 2008 Srv Std EN
SQL: MS SQL 2008/2012 Srv Ent EN

Databázový server: SQL Server 2008/2012 Srv Ent EN (licenčně 2012 downgrade 2008)

Předpokládané poskytnuté zdroje TCK pro aplikační a databázový server.

Zadavatel poskytne v TCK výpočetní výkon na bázi serverové virtualizace s podporou load balancingu a diskovou kapacitu, servery na bázi virtualizace, SQL Server (cluster). S ohledem na předpokládané rozšíření paměti ESX serverů a rozšíření operačního prostředí pro virtuální servery je možné efektivně a škálovatelně nastavit virtuální parametry serverů (CPU, počet core, RAM). Pro ukládání dat má TCK k dispozici dvě identická CAS úložiště EMC Centera, která jsou od sebe geograficky oddělena. Požadavkem je využití obou úložišť s tím, že proces replikace je využíván prostřednictvím nastavení obou zařízení (replikace na úrovni úložišť).

3.3Výběr informací z aplikačního vybavení SVKK

SVKK pro zajištění katalogu knihovního fondu používá knihovní systém ARL a pro zpřístupnění digitálních kopií dokumentů (digitální knihovnu) systém Kramerius.

4Předpokládaná hodnota veřejné zakázky

Předpokládaná hodnota veřejné zakázky je složena z investičních výdajů ve výši

1.652.893,-- Kč bez DPH tj. 2.000.000,-- Kč včetně DPH

a neinvestičních výdajů

1.446.280,-- Kč bez DPH tj. 1.750.000,-- Kč včetně DPH

tedy celkem

3.099.173,-- Kč bez DPH (limit pro nabídkovou cenu) tj. 3.750.000,-- Kč včetně DPH.¹

Cena je stanovena jako limitní hodnota a nejvýše přípustná a nepřekročitelná.

5Vymezení předmětu veřejné zakázky

Předmětem veřejné zakázky je dodávka a zprovoznění následujících aktivit:

SW pro evidenci (uložení) katalogu kulturního dědictví – krajský digitální repozitář (KDR), licence, implementace, uvedení do provozu,
implementační analýza (studie),
integrační vazby, zejména realizace rozhraní pro vybudování webových služeb (na Portál ZDO),
import existujících dat ze stávajících řešení,
vyškolení uživatelů a administrátorů,
zajištění záručního a pozáručního servisu (maintenance), zákaznická podpora,
detailní a kompletní dokumentace.

Zadavatel požaduje zpracovat na úvod implementační analýzu a po implementaci, školeních a akceptaci řešení následně zajistit záruční a pozáruční servis dodaného řešení KDR, zákaznická podpora. Součástí předmětu zakázky je i dodávka a příp. i instalace potřebných certifikátů k provozu dodávaného řešení na dobu udržitelnosti projektu.

5.1SW pro evidenci katalogu kulturního dědictví (KDR)

5.1.1Koncept systému

Zadavatel požaduje vytvoření nového systému pro evidenci katalogu kulturního dědictví – krajský digitální repozitář (KDR). Tento systém bude plně uzpůsoben současným a budoucím požadavkům, jak z pohledu funkcionality, tak z pohledu bezpečnosti a rychlosti. Systém bude zároveň v rámci projektu Výzvy 19 plně integrován s Portálem ZDO (ten reprezentuje tzv. systém zpřístupnění kulturního dědictví – SZDO), jakožto zobrazovací vrstvou pro zpřístupnění dat. Nutností je však vyhrazení nových zdrojů TCK, včetně navazující potřeby správy budoucího řešení. Jedná se o vybudování rychlého a bezpečného datového úložiště (garantovaného úložiště, CAS). Postavení KDR v celkovém konceptu zpracování znázorňuje následující obrázek.

Obrázek 1 – Koncept systému

Z pohledu uživatelů systému lze definovat typy přístupů (rolí) k KDR:

centrální administrátor
lokální administrátor
archivář
uživatel.

Výčet rolí je příp. rozšiřitelný.

Datovou základnu tvoří KDR. Data mohou variantně poskytovat i přímo paměťové instituce (správcovské instituce), jejichž systémy pro správu a evidenci sbírek a fondů umožňují poskytovat data v standardizovaném datovém výměnném formátu – například pro muzejní sbírky LIDO atd.

Sběr a transformaci AIP balíčků pro repozitář budou obstarávat moduly, které upraví originální AIP (knihovní PSP) balíčky a poskytnou je systémovému repozitáři k uložení v definovaném formátu technologie KDR. AIP balíčky se stanou datovou základnou, jíž bude používat aplikační vrstva pro zpracovávání dotazů a generování DIP balíčků na základě dotazů uživatelů. Uživatelská vrstva bude využívat pro vyhledávání a zobrazování v katalogu pouze běžné prostředky webových prohlížečů bez nutnosti instalovat specializované moduly na straně uživatele. Součástí řešení bude administrativní rozhraní pro správu systému a rozhraní pro poskytování a sběr dat.

Schéma možného řešení „Katalogu kulturního dědictví kraje“ odpovídá situaci, kdy zdrojem dat je pouze KDR.

Schéma řešení katalogu kulturního dědictví (příklad)

5.1.2Původci dokumentů, zdrojové systémy

Původci dokumentů budou libovolné subjekty v regionu Středočeského kraje, od nichž bude SK po dohodě s nimi vybírat a trvale uchovávat elektronické či digitalizované dokumenty kulturního dědictví regionálního významu. Zásadními původci jsou především paměťové instituce kulturního dědictví, příspěvkové organizace zřízené SK (knihovny, muzea, galerie, apod.). SK bude z těchto dokumentů vytvářet příslušné fondy či sbírky v rámci KDR.

Jedná se především o následující typy dokumentů:

dokumenty, cenné písemnosti, umělecká díla (historická i nově vznikající),
historické dokumenty a cenné písemnosti vzniklé z činnosti nebo spravované školami a vědeckými institucemi,
vybrané dokumenty z knihovního fondu spravovaného SVKK,
sbírky a sbírkové předměty paměťových institucí; digitalizované sbírky muzeí a galerií,
3D digitalizované vybrané kulturní památky,
historické dokumenty a cenné písemnosti vzniklé z činností náboženských obcí a kongregací,
dokumenty vytvořené soukromými osobami,
dokumenty ve vlastnictví soukromých osob (osobní archivy a sbírky),
historické dokumenty obcí, kroniky, apod.,
další dokumenty, cenné písemnosti, umělecká díla, historické mapy, fotografie, audio, video, časopisy a ostatní publikace vztahující se k regionu.

Do KDR se dostávají dokumenty ve formě vstupních informačních balíčků (SIP), které mohou vytvářet z dodaných datových souborů (popisná data, obrázky) odborní pracovníci KDR nebo tyto balíčky vytvářejí dle dohody příslušní původci přes příslušné uživatelské rozhraní. V případě digitalizace budou balíčky SIP vytvořeny a sestaveny v rámci exportu dat. Skartace je zanedbatelná (pouze např. zrušení chybných záznamů).

5.1.3Identifikace a kategorizace dokumentů, metadata, indexace

Jednoznačnou identifikaci dokumentů – digitálních objektů – zajišťuje po jejich vstupním zpracování systém správy dat KDR, který vygeneruje trvalý jednoznačný identifikátor a uloží jej jak do své databáze, tak současně i s ostatními metadaty a samotným dokumentem do archivního informačního balíčku AIP.

Pro uživatelské vyhledávání dokumentů se využijí popisná metadata, která mohou být koncipována podle následujících standardů či celostátních nebo mezinárodních doporučení:

standard metadat stanovený Národní knihovnou pro digitalizaci knihovních fondů a dlouhodobá uložení dokumentů,
možné vazby na číselníky stanovené Národní knihovnou (např. celostátní databáze, národních autorit vedená národní knihovnou),
základní archivní metadata používaná při budování archivních fondů a sbírek,
standardy využívané v muzejnictví,
specializovaný datový repozitář navrhnutý pro ukládání velkých objemů dat – textových, obrazových i zvukových,
indexační databáze metadat pro optimální vyhledávání.

5.1.4Architektura OAIS

KDR bude řešena na řešení otevřeného archivního informačního systému (OAIS). Model OAIS představuje akceptovaný standard pro dlouhodobé uchovávání dokumentů v oblasti archivace elektronických dokumentů s vyzkoušenými ukládacími politiky a postupy, srozumitelné pro odborné pracovníky a knihovníky (viz podrobně xxxx://xxxxxxxx.xxx.xx/xxxxxxxx00/xxxxxx.xxx ).

Referenční model OAIS je znázorněn na následujícím obrázku:

Systém KDR založený na principech OAIS přistupuje k dokumentům jako k balíčkům, obsahující předmětná data a současně jejich metadata za účelem dlouhodobého uložení. Podle fáze jejich životního cyklu se jedná o vstupní (SIP), archivní (AIP) a výstupní (DIP).

Rozhraní pro přístup k těmto balíčkům je specificky navrženo pro příjem a výdej balíčků v příslušném formátu definovaném na základě standardů. Vzhledem k zajištění bezpečnosti a konzistence uložených dat probíhá příjem dat do úložiště asynchronně v rámci procesu, který se zpravidla skládá z několika kontrolních a transformačních procedur.

5.1.5Softwarová architektura KDR

Systém KDR se skládá z následujících SW komponent:

Část	Popis
Vstupní modul
Příjem dat	Zajišťuje komunikaci s původcem, autentizaci, autorizaci a uložení přijatých balíčků SIP do pracovního úložiště z distribuovaných datových zdrojů.
Příjem dat	Kontrola kvality vstupních dat (formální kontrola dat, kontrola datové struktury, kontrola na obsah škodlivého kódu), kontrola povinných položek popisných dat a přípustných formátů, kontrola jiného škodlivého obsahu balíčků, kontrola číselníkových položek a vazeb mezi dokumenty. V rámci tohoto modulu je zřízena i tzv. karanténní zóna pro zajištění spolehlivosti kontrol. Struktura vstupních SIP balíčků může být doplněna dle příslušné metodiky.
	V KDR se použijí standardy a metadata definovaná Národní knihovnou příp. další, která budou dohodnuta s původci archivních balíčků (knihovní fondy, muzejní sbírky atd.). Volba způsobu uložení CAS.
API	Programové rozhraní API pro příjem dat.
OAI-PMH harvester	Podpora sběru dat z jiných portálů (pro budoucí použití).
Řízení příjmu	Kontrola popisných a technických metadat, kontrola přípustnosti souborových formátů, kontrola struktury balíčku SIP a vzájemného provázání balíčků.
Generování balíčků AIP	Automatické doplnění zejména technických metadat, konverze formátů metadat, možnost manuálního doplnění metadat, vstupní migrace formátů včetně generování náhledů pro prezentaci dat archivu v určeném formátu.
Zpracování balíčků AIP	Funkce pro zpracování originálních AIP balíčků.
Řízení ukládání	Zajišťuje konzistentní uložení metadat a obsahu archivních balíčků současně do archivního systému, systému správy dat a systému pro přístup.
Modul správy dat
Evidence číselníků	Zajišťuje ukládání a přístup k číselníkům používaným v rámci vstupní kontroly a vyhledávání. Jedná se zejména o tyto číselníky - původci, klasifikace, povolené souborové formáty, kategorizace dokumentů podle kritérií přístupnosti, požadavků na zachování důvěryhodnosti, (doby uložení).
Evidence přijímaných a uložených balíčků	Zajišťuje vedení a přístup ke katalogu uložených dokumentů včetně stavu příjmu a uložení.
Evidence periodické obnovy časových razítek	Podpora evidence historie obnovy časových razítek pro jednotlivé balíčky pro trvalé zajištění důvěryhodnosti uloženého obsahu (pouze pro odůvodnitelné případy a alternativní použití). Doporučená funkcionalita.
Evidence kontroly konzistence	Uložení kontrolních součtů jednotlivých uložených balíčků AIP na aplikační úrovni pro účely periodické kontroly konzistence uloženého obsahu nezávisle na vlastnostech použitého archivního úložiště (např. CAS/NAS).
Evidence procesů ukládání	Informace o stavu jednotlivých balíčků AIP zařazených do KDR příp. o stavu skartace.
HSM	Možnost integrace technik HSM
HW úložiště CAS	Využití všech dostupných prostředků a relevantních prostředků HW úložiště EMC Centera.
Modul administrace
Řízení procesu příjmu	Pro administrátora zajišťuje přehled o stavu příjmu balíčků SIP, umožňuje řešení problémů se strukturou a obsahem balíčků při příjmu.
Řízení procesů migrace	Spouštění migrace souborových formátů v uložených balíčcích a přehled o provedených migracích.
Skartační řízení	Příprava návrhu a jeho schvalování, provedení skartace, případně exportu do jiného archivu v definovaném formátu (pouze pro výjimečné případy, např. oprava chybného záznamu nahrazením správné hodnoty.
Správa kontroly konzistence	Přehled o průběhu ověřování kontrolních součtů a o nalezených problémech s uložením balíčků AIP.
Správa číselníků	Zajišťuje pro administrátory původce a archivu aktualizaci a čtení číselníků používaných v rámci vstupní kontroly a vyhledávání.
Ukládání transakčních záznamů	Pro účely auditu zaznamenává veškeré provedené operace nad uloženými balíčky (příjem, kontrola, transformace, ukládání, čtení). Zaznamenané záznamy jsou zároveň ukládány do úložiště ve formě AIP.
Přístup k transakčním záznamům	Zobrazení transakčních záznamů pro účely auditu.
Přístupový modul
Zabezpečení přístupu a autentizace uživatelů	Zajištění přístupu uživatelů k uloženým metadatům a dokumentům.
Autorizace - omezení přístupů na základě klasifikace dokumentu, původce, uživatelských skupin a rolí uživatelů	Modul povolí přístup ke čtení obsahu nebo metadat podle rolí přihlášeného uživatele a oprávnění příslušného balíčku.
Vyhledání uložených balíčků na základě zvolených metadat
Zobrazení náhledů a distribuce uložených dokumentů ve formě DIP	Systém umožní výběr dokumentů a jejich zaslání oprávněnému uživateli (ve standardizované podobě).
Provádění transakčních záznamů o přístupu k jednotlivým uloženým balíčkům
Programové rozhraní API na externí portál pro přístup	Systém eviduje veškeré přístupy k uloženým dokumentům a archivuje je.
Výstupní modul
Prezentace v katalogu	Aplikační vrstva zajišťující zpracování požadavků uživatelů, přípravu metadat a digitálních objektů (DIP balíček) pro prezentaci v katalogu.
OAI-PHM provider	Výstupní datové rozhraní OAI-PMH provider pro poskytování dat jiným portálům a agregátorům dat (Europeana, Apenet, národní autority, české archivy a knihovny, ostatní kraje atd.).

5.1.6Technologická architektura

Systém bude využívat HW a SW vybavení TCK, dosaženého v rámci projektů Výzvy 08/19. V rámci této veřejné zakázky lze využít následující technologické části TCK:

Aplikační servery pro obslužný SW subsystémů KDR, na bázi virtuálních serverů vytvořených nad HA clusterem (VMware, vSphere 5.x Enterprise plus), virtuální stroje předpokládány pod OS Windows 2012 Srv EN DataCtr.
Databázové servery využívané aplikacemi subsystému KDR (MS SQL Server 2008/2012 Ent).
Provozní úložiště, Tier 1/2 – pracovní prostory serverů a databáze subsystémů KDR (disková kapacita diskového pole EMC VNX 5300), disková virtualizace na SW bázi Falcon Stor.
Garantované úložiště, Tier 3 - technologie CAS pro ukládání uzavřených spisů a digitalizovaných dokumentů kulturního dědictví (Centera).
Systém zálohování TCK pro systémy a pracovní prostory serverů a databází (EMC Networker, Data Domain 620 (zatím režim VTL) + pásková knihovna).
Síťová infrastruktura TCK a zabezpečení přístupu z Internetu.
Autentizace uživatelů přes IDM (GINIS.IDM).

K obslužným aplikacím KDR umístěných na aplikačních serverech bude možný vnější přístup pro jednotlivé původce dokumentů, kteří budou komunikovat prostřednictvím zabezpečeného kanálu (https) v rámci klientských aplikací a poskytovaných webových služeb (např. Portál ZDO).

Pro správu obslužných dat a metadat uložených balíčků KDR bude využit databázový server (cluster active – passive) podle potřeb těchto aplikací.

Pro účely důvěryhodného uložení balíčků AIP v KDR, obsahující obsah dokumentů a jejich metadata, bude obslužnou aplikací použito přímo úložiště typu CAS, jehož obsah bude replikován v záložní lokalitě.

5.1.7Funkce KDR

Požadovanou funkcionalitou KDR bude:

Uložení dat digitálního fondu kulturního dědictví uloženého z paměťových institucí do KDR s předem nastavenými uživatelskými rolemi.
Vytvoření možnosti integrace pro poskytování metadatové informace prostřednictvím webové aplikace, Portál ZDO a dále integrace s IDM zadavatele, integrace s úložišti SVKK a Národní digitální knihovny a příprava integrace na budoucí řešení evidence sbírek a dokumentů nad KDR (existence rozhraní).
Vytvoření technologické a aplikační vrstvy pro podporu poskytování služeb a procesů pro uživatele, badatele, studenty, veřejnosti v návaznosti na jejich zájem a požadavky o rekvizitu (digitální podoba) či dokument příslušné paměťové instituce.
Funkcionalita nastavení oprávnění k přístupu s přihlédnutím k autorským právům.
Řešení na bázi standardu interoperability, který je zásadním prvkem technologie repozitářů. Jedná se o nástroje, díky nimž repozitář poskytuje své zdroje formou sdílení služeb, datového materiálu i metadat pomocí rozhraní. V této souvislosti je třeba klást důraz na identifikaci objektů, jejich formátů, nástrojů validace, vyhledávání a zpřístupňování dat.
Soulad se specifikací OAIS a standardů pro budování digitálních repozitářů.
Vytvoření datového a technického plánu (viz též kap. 5.1.9).
Distribuce digitálního obsahu KDR (základní a nejdůležitější výstupní prvek repozitáře) - musí se plně řídit požadavky budoucích uživatelů a dané technologické infrastruktury. Přestože projekt předpokládá distribuci obsahu v co nejširším měřítku, je potřeba zvážit i možná omezení: autorské právo, legislativní rámec šíření obsahu kulturního dědictví a jejich ochrana. Tato skutečnost se musí promítnout již do samotných metadat při jejich transformaci z KDR do zpřístupňovacího repozitáře.

Dokumenty jsou uloženy ve dvou různých kvalitách (MasterCopy, UserCopy), pro zveřejnění se počítá s vytvářením „PublicCopy“.

5.1.8Další požadavky na rozsah předmětu zakázky

Minimální požadavky - Vytvoření a zpřístupnění KDR - obecné požadavky

X.	Xxxxxxxxxx funkce/vlastnost	Splněno
1	Pracovní prostředí uživatele bude v rámci projektu sjednocené. Informace z jednotlivých systémů a aplikací budou uživateli dodávány prostřednictvím rozhraní. Uživatelům tak budou k dispozici již jednou pořízená data nejen z jeho aplikace, ale též z aplikací okolních (v případě, že bude v rámci jednotlivých speciálních požadavků stanoveno). Jednotlivé součásti řešení budou poskytovat uživateli moderní uživatelské rozhraní, jehož ovládání je obdobné s ovládáním kancelářských (např. MS Office, Adobe Acrobat Reader) či webových aplikací. Požadavek na uživatelskou přívětivost a efektivitu.
2	Identita uživatelů a jejich uživatelská oprávnění budou spravovány centrálně. Znamená to, že veškeré dodané části budou spravovány z jednoho místa (Identity Management - IDM). Kromě oprávnění k interním aplikacím jsou centrálně přidělována též oprávnění k přístupu k systému základních registrů.
3	Integrace komunikace a předávání dat mezi jednotlivými součástmi řešení budou realizována on‑line. Výjimku tvoří základní migrace dat do KDR z paměťových institucí.
4	Požadované řešení bude modulární a škálovatelné. Jednotlivé součásti řešení budou schopné fungovat zcela odděleně a při výpadku jedné součásti řešení zůstanou ostatní součásti řešení funkční.
5	Architektura poptávaného řešení a jeho jednotlivých součástí bude vícevrstvá, využívající databázi, aplikační server a klientskou část. Součást řešení poskytují tenkého klienta, který nevyžaduje instalaci a je realizován jako aplikace běžící v internetovém prohlížeči nebo jako win32 aplikace. Řešení bude technologicky postaveno na obecně uznávaných standardech a technologiích – JAVA, .NET, webové služby (SOAP), PDF, Apache Tomcat a dalších.
7	Datové úložiště bude umožňovat ukládání dokumentů včetně definovaných popisných metadat. Specifikace metadat je dána dokumentovým typem nebo typem sbírky historických, uměleckých nebo upomínkových předmětů. Úložiště bude zajišťovat verzování ukládaných dokumentů. V každém uzlu (adresáři) bude možné nastavit uživatelská oprávnění a dokumentový typ.
8	Konfigurovatelnost systému dle nově vzniklých požadavků uživatelů - možnost přidávání dalších obecných agend administrátorem úřadu (max. v řádu dnů). Systém musí umožnit specifické nastavení v závislosti na agendě.
9	Přidělování diferencovaných přístupových práv k záznamům v závislosti na organizační struktuře, tzn. každý uživatel bude mít přesně definováno, které záznamy příp. logické skupiny záznamů může prohlížet, měnit a přidávat (uživatelské role).
10	Systém musí vést záznam o veškerých změnách provedených uživateli v datech (systém aplikačních logů).
11	Systém musí disponovat popsaným aplikačním rozhraním na bázi Web Services (technologie SOAP).
12	Multilicenční pokrytí z hlediska přímých licencí, tak licencí podpůrných, potřebných k provozu nabízeného řešení na koncových stanicích.
13	Provoz beze ztráty funkčnosti a zobrazení v rozlišení 1024×768 px a vyšším minimálně u následujících prohlížečů při zachování kompatibility prohlížečů: - MS Internet Explorer 7 a vyšší - Google Chrome 4 a vyšší - Mozilla FireFox 3.0 a vyšší - Opera 8.0 a vyšší
14	Nabízený systém je kompatibilní s DB MS SQL Server minimální verze 2008 nebo vyšší. Nasazení systému nebude pro zadavatele podmíněn nákupem jiné licence databázového systému.
15	Nabízené řešení bude v případě změny DB provozu schopné i na jiných DB platformách, minimálně ORACLE příp. Informix, DB2.
16	Uživatelské prostředí a desktopový provoz PC je v prostředí MS Windows XT/Vista/Win7/Win 8x.
17	Nabízené řešení garantuje kompatibilitu s nástroji MS OFFICE 2003, 2007, 2010 a 2013 (min. Word, Excel, Outlook).
18	Nabízené řešení bude dodáno v českém jazyce, tzn. veškeré jeho části, dokumentace a jiné podpůrné prostředky.
19	Řešení neobsahuje žádná skrytá omezení pro Zadavatele z pohledu objemu ukládaných dat, počet aktivních a detašovaně uložených dokumentů nebo žádné jiné omezení, které by v budoucnu mělo za následek navýšení investiční a provozní zátěže.
20	Nabízené řešení bude v souladu s platnou legislativou, zejména se zákonem číslo 101/2000 Sb., o ochraně osobních údajů, zákonem č. 365/2002 Sb., o informačních systémech veřejné správy, zákonem č. 111/2009 Sb., o základních registrech.
21	Aplikace poskytne aplikační rozhraní pro přístup ke službám a datům z externích aplikací.
22	K aplikaci bude dodána příručka uživatele pro interní uživatele (uživatelé systému ze stran paměťových institucí), příručka správce a administrátora.
23	Pro interní uživatele je vhodné vytvořit rovněž e-learningový kurz pro používání aplikace. Tyto případné kurzy doporučuje zadavatel umístit na infrastruktuře dodavatele a přístupný permanentně po celou dobu udržitelnosti projektu.
24	Integrace s IS-ZR pomocí integrovaného aplikačního nástroje včetně notifikací a průběžného ověřování údajů (požadavek v případě potřeby integrace se ZR).
25

Minimální požadavky části vybudování datového úložiště portálu – zpřístupňovacího repozitáře

Katalog bude obsahovat záznamy o objektech kulturního významu, které obsahují strukturované informace o objektu a připojené nestrukturované dokumenty. Základní evidenční jednotkou je objekt kulturního významu, kterým můžou být movité předměty, historické dokumenty, mapy, smlouvy apod.

Logická struktura katalogu (popisná část)

Katalog bude mít minimálně dále uvedenou logickou strukturu informací.

X.	Xxxxxxxxxx funkce/vlastnost	Splněno
1	Objekt kulturního významu Jedná se o základní evidenční jednotku se strukturovaným popisem obsahujícím minimálně Identifikátor objektu kulturního významu. Automaticky aplikací generovaný jednoznačný identifikátor objektu. Identifikátor objektu je neměnný. Typ objektu kulturního významu Reprezentuje základní členění objektů. Každý objekt je právě jednoho typu. Typy objektu tvoří číselník, který je možné průběžně rozšiřovat (přidávat hodnoty), a to i po spuštění aplikace do provozu. Název objektu kulturního významu Popis objektu kulturního významu Obsahuje podrobný popis objektu. Správce objektu kulturního významu Identifikace správce objektu – osoby či instituce, které je objekt svěřen do správy. Správce nemusí být vlastníkem objektu. Správce je vybírán z číselníku správců objektů kulturního významu. Vlastník objektu kulturního významu Identifikace vlastníka objektu kulturního významu. Vlastník je veden v číselníku vlastníků. Je možné evidovat více vlastníků jednoho objektu. Standardní umístění objektu kulturního významu Obsahuje informaci o místě, kde je objekt standardně fyzicky umístěn či uložen. Aktuální umístění objektu kulturního významu Obsahuje informaci o aktuálním místě, kde je objekt fyzicky umístěn čí uložen a datu počátku a konce umístění. Datum/ období vzniku Určení data nebo období vzniku objektu, ne-li znám přesný datum. Klíčová slova Klíčová slova charakterizující objekt, zejména pro účely hledání.
2	K objektu kulturního významu zajistit připojení jednoho nebo více dokumentů. Každý dokument může obsahovat další strukturované údaje, které doplňují popis (metadata) a nestrukturované elektronický obsah (obrázek(ky), video, soubor PDF, apod.).
3	Správa číselníků pro podporu zadávaných popisných údajů objektu kulturního významu. Bude zajištěno vedení minimálně následujících číselníků typů objektů kulturního významu (např. kniha, socha, apod.), správců objektů kulturního významu (organizaci, která má objekt ve správě), umístění a skutečné umístění objektů kulturního významu (nemovitostí, kde je objekt dostupný, např. knihovna, zámek apod.), typů dokumentů (kategorizace nestrukturovaných dat).
4	Vytvoření Aplikace pro aktivní evidenci (interní) Aplikace je určena správcům objektů kulturního významu a umožňuje jim aktivní správu informací. Specifickým uživatelem je správce aplikace, který konfiguruje aplikaci včetně automaticky načítaných informací. Aplikace umožní: Ruční vkládání a editaci informací uživatelem přímo z klientského prostředí aplikace. Využijí pro vedení a správu evidence o objektech kulturního významu zejména ty organizace, které nemají vlastní řešení. Automatické načítání a aktualizaci informací z existujících datových zdrojů (aplikací) v definovaném formátu (balíček obsahující strukturované a nestrukturované informace, sada souborů). Předpokládá se, že balíček bude tvořen jedním souborem (např. ve formátu ZIP) obsahujícím uvedené informace. Struktura informací bude vyházet ze struktury katalogu a přesný formát bude určen v analýze. Zadavatel zajistí úpravu stávajících aplikací tak, aby byly schopné poskytovat data v tomto definovaném formátu. Evidenci libovolného množství dokumentů k objektům kulturního významu. Vyhledávání objektů kulturního významu nebo dokumentů pomocí fulltextu a detailního hledání nad daty objektu a metadaty dokumentů. Hledání dle nestrukturovaných dat (obsah dokumentů) není požadováno. Vyhledané objekty jsou zobrazeny formou seznamu. Aplikace podpoří zobrazení seznamu formou karet a tabulky. V tabulkovém zobrazení bude možné prostředky uživatele měnit šířku sloupců, přidávat a ubírat sloupce a řadit informace. Přímo ze seznamu v podobě karet bude možné vyvolat vybrané základní akce nad objektem. Zobrazení detailu vybraného konkrétního objektu kulturního významu. V zobrazení detailu bude možná snadná orientace v datech objektu včetně připojených dokumentů a vazeb (části objektu, sady). Dle uživatelských oprávnění umožní aplikace pouze prohlížet objekty nebo objekty zakládat a editovat. Oprávnění umožní definovat úroveň přístupu (prohlížení, editace) v závislosti na číselnících typů objektů, typů dokumentů a správců. Bude tedy např. možné pomocí oprávnění určit, který uživatel může editovat objekty daného typu, a který uživatel je může pouze prohlížet. Aplikace bude obsahovat nástroj kontrolující možné duplicity při pořízení záznamu objektu. Nástroj umožní provést hromadnou kontrolu na výskyt potenciálně duplicitních objektů. Automatické odstranění duplicit není požadováno. Veškeré změny v datech budou zaznamenány a budou dostupné pro prohlížení oprávněným uživatelem. U změny je zaznamenáno, kdy, kdo a jakou změnu provedl či stav záznamu před a po změně. To platí i pro uložené dokumenty (soubory). Zaznamenání možnosti zpřístupnit informace veřejnosti. Samostatně bude možné označit pro zveřejnění objekt kulturního významu a samostatně dokument s objektem svázaný. Dokument je zveřejněn, jen pokud je zveřejněn objekt i dokument. Veřejnosti jsou dostupné jen zveřejněné objekty a dokumenty. V rámci analýzy bude určen efektivní způsob označení zveřejněných informací (např. princip vše veřejné, není-li stanoveno jinak) a rozsah zveřejňovaných informací pro jednotlivé typy objektů.
5	Jednotlivé objekty kulturního významu mohou být seskupeny do sad. Každý objekt kulturního významu má definované umístění.
6	Aplikace umožní definovat specifické atributy pro jednotlivé typy objektů, přičemž pro každý typ objektu bude možné definovat zcela samostatné atributy bez ohledu na ostatní typy objektů.
7	Aplikace umožní definovat sady objektů kulturního významu. Platí přitom, že jeden objekt může být zařazen do více sad současně. Sada obsahuje minimálně údaje o názvu a popisu sady.
8	Aplikace podpoří členění objektů kulturního významu na části.
9	Práce s dokumenty Dokumenty představují nestrukturované informace. Každý dokument obsahuje nestrukturované elektronický obsah (obrázek, video, soubor PDF, apod.) a strukturované údaje, které ho popisují popis (metadata). Strukturované údaje popisující dokument obsahují minimálně: Typ dokumentu Typ dokumentu reprezentuje základní členění dokumentů. Je dán číselníkem typů dokumentů. Typy dokumentů tvoří číselník, který je možné průběžně rozšiřovat (přidávat hodnoty), a to i po spuštění aplikace do provozu. Název dokumentu Popis dokumentu Datum pořízení dokumentu Obsahuje datum pořízení elektronického dokumentu. Např. v případě skenování jde o datum vytvoření souboru ze skeneru, nikoli o datum vzniku skenované předlohy. Autor dokumentu Formát dokumentu Dokument lze připojit (svázat jej) k objektu kulturního významu, části objektu kulturního významu i k sadě objektů.

V rámci implementační analýzy bude určen efektivní způsob označení zveřejněných informací (např. princip vše veřejné, není-li stanoveno jinak) dle bodu 4 výše uvedené tabulky vč. ostatních parametrů aplikační části, jako např. návrh detailní struktury záznamu a grafický vzhled aplikace.

5.1.9Zpracování datového a technického plánu

Zadavatel požaduje zpracování datového a technického plánu, jehož principy budou závazné pro další části plnění veřejné zakázky.

Datový plán

Datový plán repozitáře specifikuje způsob hierarchického ukládání datových a metadatových objektů, jejich formáty, struktury pro vkládání, způsoby uchovávání, zpřístupňování a související datové transformace.

Plán musí obsahovat:

Určení formátů dat a obsahu metadat uložených digitálních objektů modifikovaných AIP balíčků v zpřístupňovacím repozitáři (dle norem OAI nebo Dublin Core xml).
Určení způsobu transformace uložených AIP balíčků v KDR do zpřístupňovacího repozitáře, to znamená stanovit jasná pravidla pro vytváření a ukládání modifikovaných balíčků AIP v repozitáři.
Určení formátů dat pro digitální objekty distribuované uživatelům (DIP) – zpřístupňovací repozitář musí stanovit vhodné formáty pro distribuci digitálních objektů. Jednotlivé typy balíčků DIP se mohou výrazně lišit v závislosti na typu zpřístupňovaného materiálu (sbírkový předmět, kniha, mapa atd.).

Technický plán

Rozhodujícím prvkem technického plánu je souhrn technických požadavků na využití ICT infrastruktury TCK. Jedná se o dostatečné SW, HW a komunikační nástroje s ohledem na předpokládané množství dat, výkonové a zpřístupňovací ukazatele. Měla by být popsána taková varianta, která zvládne zobrazování velkého množství textových, obrazových a zvukových dat. Dále by mělo být popsáno řešení pro vyhledávání prostřednictvím metadatových struktur.

5.1.10Souhrn bezpečnostních podmínek, které musí aplikace splňovat

Bezpečnost řešení – aplikace musí být chráněna proti bezpečnostním chybám, je vyžadováno splní doporučení OWASP Top 10 2010 (xxxxxxxx00.xxxxxxxxxx.xxx/xxxxx/XXXXX%00Xxx%0000%00-%000000.xxx), kde je popsáno např. XSS (cross site scripting, technika podvržení cizího textu nebo kódu do stránek), SQL injection, (technika napadení databázové vrstvy programu vsunutím kódu přes neošetřený vstup a vykonání vlastního SQL dotazu) atd.

5.1.11Správa aktualizací aplikace

Aplikace musí umožňovat centralizovanou správu aktualizací. Aktualizace budou distribuovány dohodnutým způsobem se zadavatelem dodavatele a na uvolnění nové aktualizace bude určený zaměstnanec zadavatele upozorněný minimálně např. pomocí emailové zprávy zasílané automaticky samotnou aplikací či dodavatelem po jejím vydání. Konkrétní podmínky budou popsány v dokumentaci aplikace.

5.1.12Požadavky na funkčnost aplikace, správa účtů uživatelů

Funkčnost klientské části aplikace musí být ověřena a zaručena na operačním systému Microsoft Windows XP/Vista/7/8 a všech dalších vyšších verzích.

V případě, že aplikace využívá ke své činnosti databázi, bude použito databázové prostředí MS SQL (vybavení TCK).

Aplikace musí přistupovat do databáze jen prostřednictvím jednoho speciálního „společného“ účtu (není možno v databázi používat účty uživatelů). Tento účet musí být odlišný od administrátorského účtu, který bude používán pro správu resp. vzdálenou správu.

Aplikace bude přebírat autentizaci uživatele ze systému MS Windows (prostřednictvím IDM), tzn., že bude umožňovat přihlašování single sign-on.

Aplikace bude umožňovat import uživatelů a organizační struktury z aplikace IDM pomocí webové služby.

Dodavatel musí na požádání zajistit úpravu dodávané aplikace tak, aby pro řízení přístupových oprávnění uživatelů a jejich správu mohlo být použito jiného systému např. IDM systému.

Aplikace musí poskytnout rozhraní, jehož prostřednictvím bude možno zajistit import a export údajů spravovaných systémem ve formě XML struktur. Preferováno je použití WS. Součástí bude technický popis rozhraní v českém jazyce.

V případě, že se jedná o víceuživatelskou aplikaci, systém umožní jednoduchý export všech zavedených uživatelů a výpis jim v aplikaci přidělených práv pro účely auditování.

5.1.13Odkazy na normy a doporučení

Knihovny:

MARCXML - xxxx://xxx.xxx.xxx/xxxxxxxxx/xxxxxxx/

MODS - xxxx://xxx.xxx.xxx/xxxxxxxxx/xxxx/
METS - xxxx://xxx.xxx.xxx/xxxxxxxxx/xxxx/
ALTO xml - xxxx://xxx.xxx.xxx/xxxxxxxxx/xxxx/
MIX - xxxx://xxx.xxx.xxx/xxxxxxxxx/xxx/
PREMIS - xxxx://xxx.xxx.xxx/xxxxxxxxx/xxxxxx/

Muzea:

CIDOC CRM - xxxx://xxx.xxxxx-xxx.xxx/
LIDO - xxxx://xxxxxxx.xxxx.xxxxxx/xxxxx/xxxxxxx-xxxxxx/xxxx-xxxxxxxxxx-xxx-xxxxxxxxxxx/xxxx-xx-xxxx/

Archivy:

Standardy: xxxx://xxx.xxx.xxx/00000/xxxx-xxxxxxxxx/xxxx-xxxxxxxxx.xxxx
apeEAD: xxxx://xxx.xxxx-xxxxxxx.xx/xxxxx.xxx/xxxxxxxx/00-xxxxxx/xxxxx-xxx-xxxxxxx/xxxxxxxx/00-xxxxx-xxx-xxxxxxx
OAI-PMH: xxxx://xxx.xxxxxxxxxxxx.xxx/xxx/
Dublin Core: xxxx://xxxxxxxxxx.xxx/

Řešení musí být v souladu s následujícími standardy:

Norma ISO 14721:2003 – standard OAIS.
Dokumenty, struktura a metadata ukládána v balíčcích AIP dle standardu METS.
Podpora metadat ve formátech METS, MODS, Dublin Core, PREMIS, MIX, ALTO XML a z něj odvozené TXT, případně vše v kódování UTF-8. Řešení bude podporovat i další formáty dle potřeb zadavatele.

5.2Implementační analýza (studie)

Zadavatel požaduje provedení implementační analýzy a zpracování Implementační studie (tj. jako výstupní dokument z analýzy). Zpracování implementační studie je prvním krokem v rámci realizace předmětu plnění. Jedná se o dokument přímo vztažený k projektu a k jeho specifikám. Nejedná se tedy pouze o obecný dokument, který by shrnoval obecně známá fakta.

Cílem tohoto dokumentu je zpracování jasného, úplného a detailního popisu architektury řešení, způsobu nasazení a způsobu práce se systémem po dobu udržitelnosti projektu. Dokument bude obsahovat časový plán prací a činností, které je nutné provést k úspěšné realizaci předmětu plnění této veřejné zakázky a věcný popis všech fází a etap realizace této veřejné zakázky. Vybraný uchazeč může zahájit realizaci implementačních etap této veřejné zakázky až po schválení Implementační studie zadavatelem (netýká se dodávky HW a SW včetně licencí, které lze objednat bezprostředně po podpisu smlouvy).

Implementační studií se rozumí vytvoření popisu (dokumentu), který obsahuje minimálně následující požadavky na něj kladené:

a) věcnou specifikaci ICT nástrojů a zařízení v rámci dodávky, schéma architektury – konkrétní specifikace užívání SW a HW s popisem konkrétních procesů, zapojení a implementace, co se bude v KDR evidovat, jak se bude s KDR pracovat a co bude výstupem integrací pro zpřístupnění dat uživatelům prostřednictvím Portálu SDO v rámci jednotlivých rolí; bezpečnostní rizika;

b) věcnou specifikaci nástrojů ke zpracování dat z PO na krajském úřadě do KDR, popis - včetně procesu, kterým se data do systému dostanou, jak se budou v systému vyhodnocovat, používat a zpřístupňovat. Konkrétní postupy budou doplněny věcnými obrázky, schématy z aplikace, aby bylo možné konkrétně si představit, co se z PO bude ukládat, administrovat a zpřístupňovat, návrh nastavení přístupových práv; zpracování datového a technického plánu. Samotná implementace musí být provedena na základě plánu implementace, který bude věcně a časově popisovat alespoň tyto kroky:

požadavky na rozhraní
konfigurace rozhraní
specifické definice logu
nastavení AIP a DIP balíčků
definice atributů metadatových souborů
popis standardizovaných výměnných formátů
rozpracovaný popis školení uživatelů a administrátorů;

c) časový harmonogram jednotlivých etap implementace ICT a fází projektu – časový rozpis prací a činností, které je nutné provést k úspěšné realizace zbývajících částí veřejné zakázky. Harmonogram může být doplněn technickými a organizačními pomůckami, které usnadní jejich interpretaci koncovému uživateli. Implementační analýza minimálně musí respektovat všechny navržené procesy, postupy, musí zohledňovat a zahrnovat všechny požadavky na technické a organizační záležitosti v zadávací dokumentaci.

Součástí bude i technický popis celkové architektury systému a jeho technické nároky na HW technologického centra kraje. Dále pak popis implementace, testování, výčet předávané dokumentace, výčet a předpokládané termíny školení, požadavky na součinnost, seznam kontaktních osob a členů projektového týmu, projektovou metodiku a všechny další organizační a technické informace potřebné k zahájení a plnění jednotlivých etap a fází projektu k dosažení projektového cíle.

Uchazeč tedy v rámci nabídky bude garantovat nejen provedení předmětu plnění dle specifikace ZD a všech částí ZD, ale také zpracování dalších podnětů, připomínek a funkčních požadavků vzešlých z analýzy.

5.3Integrační vazby a konektivity

5.3.1Propojení KDR s digitalizačním pracovištěm

Skenovací pracoviště bude kompletně umístěno v SVKK. Vlastní připojení do TCK tedy i následně do KDR bude zprostředkováno přes firewall SVKK a optického propojení v rámci topologie sítě na území města Kladna (optická síť kraje příp. využití optické sítě MM Kladno). Prostřednictvím tohoto propojení bude zajištěno spojení pro vstup digitalizovaných materiálů (SIP) do KDR.

5.3.2Integrační vazby

Integrační vazby se týkají především zajištěním vstupu digitalizovaných materiálů (SIP) do KDR a integrace KDR s portálem ZDO. Uchazeč je povinen si na všechny potřebné integrace a přípravy integrace vytvořit dostatečnou finanční položku (krytí) v rozpočtu zakázky. Konkrétní integrace:
Napojení na Portál ZDO – hlavní podstatná integrace na datovém úložišti mezi aplikační vrstvou (KDR) a zobrazovací vrstvou Portálem ZDO. Poptávka po portálu ZDO probíhá samostatně a paralelně s touto zakázkou. Obojí aktivity nelze poptávat společně v jedné veřejné zakázce s ohledem na stavbu projektových aktivit z hlediska projektové metodiky a nastavení finančních limitů aktivit poskytovatelem dotace. Datové rozhraní KDR je primární a určující a je třeba se na něj připojit a respektovat formu integrace.
Napojení na interní příp. externí zdroje dat – hlavní integrací je napojení IS SVKK knihovní systém ARL (katalog knihovny) a systém Kramerius (digitální knihovna). Další integrace představuje vstup zdigitalizovaných dat do KDR (SIP). Integrace může mít i formu replikační s fázovým posunutím (předem přednastavená konsolidace dat mezi katalogy).
Integrace s paměťovými institucemi, především PO – současná on-line integrace se nepředpokládá. Do KDR se data ze sbírek paměťových institucí namigrují jednorázově (konverze dat). Další údržbu informací o sbírkách v centrálním katalogu KDR se zprostředkuje prostřednictvím portálu ZDO nebo může KDR disponovat vlastním aplikačním rozhraním pro údržbu sbírek vzdáleně správci (administrátoři) sbírek. Důvodem je naprosto roztříštěné prostředí aplikací pro vedení sbírek na jednotlivých PO včetně případů, kdy je tato evidence vedena ručně a/nebo v tabulkových procesorech (např. Excel). Středočeský kraj předpokládá, že v dalších rozvojových aktivitách v oblasti evidence a propagace kulturního dědictví SK zajistí jednotný (pravděpodobně hostovaný) IS pro centrální evidenci sbírek. Takový informační systém bude již velmi snadno integrovatelný s KDR a též s Portálem ZDO, protože se jedná o 1 integraci navíc a aplikace budou provozovány v TCK. Současný finanční limit v rámci aktivit Výzvy 19 v oblasti rozvoje kulturního dědictví neumožňuje takový IS nyní pořídit.
Integrace s IDM – zajišťuje centrálně autentizaci uživatelů KDR přes krajské IDM (produkt GINIS.IDM).
Případné další integrační vazby mohou vyplynout z provedené implementační analýzy a budou uvedeny v implementační studii.

5.3.3Realizace rozhraní pro vybudování webových služeb (zpřístupnění KDR)

Zadavatel požaduje poskytnutí takového plnění, které zabezpečí následující vlastnosti:

přístup k datům musí být možný prostřednictvím uživatelského rozhraní, které bude umožňovat vyhledávání podle evidovaných metadat a výdej obsahu ve formě balíčků DIP (Dissemination Information Package). Také musí být umožněno asistované vydání dokumentu,
každý přístup k uloženému balíčku oprávněnými uživateli určeného původce i v případě nahlížení do dokumentu bude zaznamenán a trvale evidován. Přístup k dokumentům uloženým v systému musí být omezen pouze na oprávněné uživatele konkrétního určeného původce na základě klasifikace dokumentu a uživatelské role,
možnost vyžádání a schvalování výdeje balíčků DIP, evidence výdeje balíčků DIP,
postoupení uložených dokumentů ve formě DIP, systém umožní výběr dokumentů a jejich zaslání oprávněnému uživateli ve standardizované podobě,
zabezpečení přístupu a autentizace uživatelů. Zajištění přístupu uživatelů k uloženým metadatům a dokumentům,
splnění norem a referenčního modelu OAIS, kompatibilita řešení a procesů s modelem OAIS
GUI v českém jazyce,
zajištění logicky odděleného prostoru pro každého určeného původce,
zajištění důvěryhodnosti a dlouhodobosti zobrazovaných informací,
přebírání, zpracování, uložení a zpřístupňování dokumentů a jejich metadat,
podpora prohlížečů Internet Explorer, Mozilla Firefox, Google Chrome v aktuálně výrobcem podporovaných verzích,
všechny funkcionality systému musí být zcela jasně a srozumitelně popsány v dokumentaci (administrátorská, uživatelská) v českém jazyce.

6Doba plnění veřejné zakázky

Doba plnění (harmonogram) je z pohledu zadavatele uveden v následující tabulce:

Fáze projektu	Termín plnění, maximální délka procesu
Zahájení projektu	neprodleně po podpisu smlouvy
Analýza, implementační studie	do 15 dní od zahájení projektu
Oponentura, doplnění analýzy, akceptace analýzy a implementační studie	do 15 dnů od předání analýzy
Dodávka, instalace, implementace KDR, optimalizace	max. do 90 dnů od podpisu smlouvy
Testovací (zkušební) provoz	v délce alespoň 15 dní od ukončení implementace
Rutinní provoz s asistencí uchazeče	v dílce alespoň 30 dní od ukončení testovacího provozu
Akceptace	v průběhu rutinního provozu po předání celého dodávaného řešení KDR
Rutinní provoz (následný)	navazující období na rutinní provoz s asistencí uchazeče
Technická podpora a údržba	zahájení technické podpory po předání do rutinního provozu (r. 2015-2020)
Uchazeč naplánuje jednotlivé fáze projektu tak, aby do akceptace projektu nepřekročil nejzazší termín projektu.
Nejzazší a nepřekročitelný termín předání a akceptace projektu je do 31.10.2015.

7Další požadavky na dodávku

7.1Uživatelské role

Uživatele je možné rozdělit do několika hlavních rolí (z pohledu správy KDR):

Administrátor – pracovník zadavatele s technickou znalostí, který má administrátorská oprávnění, může měnit konfiguraci systému, upravovat a definovat serverová nastavení, připojení k datovým zdrojům apod., odhad 2 administrátoři.
Správce aplikace – pracovník zadavatele s technickou znalostí aplikace osoba, která má oprávnění nastavit aplikační nastavení, může též připravovat analýzy a reporty, odhad 2 správci.
Uživatel – osoba, pracovník, vedoucí pracovník, která má oprávnění pracovat s daty a s definovanými výstupy (PO, zadavatel). Uživatel má právo spouštět hotové analýzy a reporty, zobrazovat data v rámci svého organizačního zařazení a prohlížet detaily svých podřízených.

7.2Dokumentace

Součástí dodávky musí být dokumentace k nabízenému řešení (softwarový nástroj), která musí obsahovat systémovou a uživatelskou příručku (manuál) popřípadě školící a učební texty, pokud nejsou součástí uživatelského příručky, vše v českém jazyce. Uživatelská a systémová příručka musí být také dodána v elektronické podobě v některém ze standardních datových formátů (RTF, DOC, PDF). Uchazeč dodá kompletní odbornou dokumentaci k dodávaným SW technologiím (zpravidla administrátorskou dokumentaci) minimálně v elektronické podobě. Dále dodá dokumentaci v rozsahu:

Kompletní popis balíčků SIP/AIP/DIP.
Popis topologie a funkčních vazeb celého řešení.
Podrobný popis konfigurací všech technologických částí aktuálních v době předání.
Plán pravidelné údržby.
Plán zálohování a obnovy.
Kompletní popis všech API rozhraní dodávaných systémů včetně popisu API pro budoucí integraci s dalšími systémy.
Soupis licenčních kódů a instalačních médií nebo balíčků.
Zpracování provozní a bezpečnostní dokumentace.
Další dokumenty nutné k předání díla a k zajištění vyčerpávající informovanosti zadavatele.

7.3Dokumentace zadavatele, upgrade a doplnění směrnic

Součástí dodávky musí být dokumentace k nabízenému řešení (softwarový nástroj), která musí obsahovat systémovou a uživatelskou příručku (manuál) popřípadě školící a učební texty, pokud nejsou součástí uživatelského příručky, vše v českém jazyce. Uživatelská a systémová příručka musí být také dodána v elektronické podobě v některém ze standardních datových formátů (RTF, DOC, PDF). Dále uchazeč dodá kompletní odbornou dokumentaci k dodávaným SW technologiím (zpravidla administrátorskou dokumentaci).

Součástí zakázky je provedení návrhu změn související dokumentace a směrnic zadavatele a pilotně instalovaných PO včetně potřebné metodické dokumentace.

7.4Školení

Uchazeč poskytne školení pro uživatele softwarového nástroje tak, aby všichni uživatelé byli schopni řádně užívat instalované, implementované a customizované nabízené řešení softwarového nástroje. Zadavatel předpokládá školení uživatelů v rozsahu minimálně 50 hodin. V případě, že se ukáže nastavený limit jako nedostačující, dodavatel potřebný počet hodin školení přiměřeně navýší bez nároku na další náklady VZ.

Uchazeč dále poskytne školení pro 3 administrátory softwarového nástroje tak, aby tito administrátoři byli schopni řádně užívat instalované, implementované a customizované nabízené řešení pro účely jeho provozu a údržby.

Zadavatel předpokládá školení administrátorů v rozsahu minimálně 40 hodin.

Školení konkrétních uživatelů a administrátorů musí být provedeno před začátkem testovacího provozu.

Minimální požadovaný časový rozsah školení uživatelů je 1 den. Uchazeč musí zajistit školení uživatelů minimálně pro zadavatelem vybrané pracovníky KúSK a pracovníky PO. Cílem je realizovat základní uživatelské školení tak, aby bylo možné maximálně využít všech možností implementovaných nástrojů z pohledu zaměstnanců/uživatelů, rovněž pak z pohledu vedoucích pracovníků.

7.5Technická podpora a údržba

Technická podpora na celkové řešení ze strany dodavatele musí zahrnovat garanci včasného zásahu v případě vzniku problematické situace. Problémem (závadou) se rozumí takový stav, který neumožňuje provádět určité funkce systému, nebo nejsou splněny podmínky stanovené v dokumentaci.

Během realizace předmětu veřejné zakázky a období udržitelnosti, které trvá 5 let od realizace této veřejné zakázky, musí být dodavatelem zajištěna technická, zákaznická a metodická podpora pro všechny uživatele nabízeného rozhraní.

7.5.1Požadavky na technickou a zákaznickou podporu

Požadavky na technickou a zákaznickou podporu jsou:

Průběžné provádění inovace produktu, jeho jednotlivých technologických částí a příslušného software, zejména update a legislativního update, upgrade a legislativního upgrade.
Pod pojmem update se rozumí taková verze produktu, u které se oproti předcházející verzi produktu mění jeho funkčnost, a to na základě změny jakékoliv skutečnosti, podle které byla celá funkčnost tohoto produktu vytvořena, ale nemění se struktura dat datového fondu, se kterým tato verze produktu pracuje. V případě, že změna funkčnosti tohoto produktu byla provedena pouze na základě legislativních změn, je nová verze tohoto produktu jeho “legislativním updatem”.
Pod pojmem upgrade se rozumí taková verze produktu, u které se oproti předcházející verzi tohoto produktu mění jeho funkčnost, a to na základě změny jakékoliv skutečnosti, podle které byla celá funkčnost produktu vytvořena, a zároveň se mění struktura vět datového fondu, se kterým tato verze produktu pracuje. V případě, že změna funkčnosti tohoto produktu a změna struktury dat datového fondu, se kterým tento produkt pracuje, byla provedena pouze na základě legislativních změn, je nová verze tohoto produktu jeho “legislativním upgradem”.
Poskytování update a upgrade produktu, vzniklé legislativními změnami a požadavky objednatele či samostatnou, nevynucenou, inovační činností zhotovitele.
Provádění obecných změn produktu v důsledku vývoje HW a SW prostředků.
Distribuce nových verzí produktu a bezpečnostních a funkčních oprav (patchů) včetně aktuální dokumentace a popisu změn.
Distribuce informací o nových verzí produktu uživatelům elektronicky.
Distribuce inovovaného produktu za účelem legislativního update nebo legislativního upgrade bude provedena před termínem účinnosti změn příslušných právních předpisů
Aktualizace provozní a bezpečnostní dokumentace.
Poskytování přístupu k databázi známých řešených problémů a přístupu k technické podpoře výrobce.
Služba Hot-line formou telefonické podpory pro zaměstnance zadavatele pro hlášení požadavků na technickou podporu a servis, poradenství a konzultace.
Služba HelpDesk/ServiceDesk pro zaměstnance zadavatele pro hlášení závad a požadavků na technickou podporu, poradenství a konzultace.
Provádění servisních a metodických návštěv na organizaci minimálně 1x za 6 měsíců.
Provádění metodických konzultací na vyžádání.
Provádět servisních zásahu do konfigurace pro plynulý běh aplikace dle požadavku jednotného finančního řízení příspěvkových organizací.

7.5.2Klasifikace technické a zákaznické podpory

Problémy (závady) jsou klasifikovány dle jejich závažnosti a provozních podmínek na tři kategorie důležitosti:

Vysoká = závady vylučující užívání produktu nebo jeho části, tj. problémy zabraňující provozu systému (provoz systému nebo jeho části je zastaven).

Střední = závady způsobující problémy při užívání a provozování produktu nebo jeho části, ale umožňující provoz systému. Provoz systému nebo jeho části je omezen, nicméně činnosti mohou pokračovat určitou dobu náhradním způsobem.

Nízká = provoz systému nebo jeho části je závadou ovlivněn, může však pokračovat jiným způsobem (např. organizačními opatřeními apod.).

Požadavek na servisní zásah může být uplatněn:

systémem ServiceDesk,
poštou,
elektronickou poštou,
xxxxxxx xxxxxxxxx,
faxem.

Dostupnost technické podpory je požadována v pracovních dnech od 8:00 do 17:00 dle dále uvedených priorit jednotlivých požadavků.

Priorita	Reakční doba od převzetí problému	Doba vyřešení požadavku od převzetí problému
Vysoká	2 pracovní hodiny	8 pracovních hodin
Střední	8 pracovních hodin	3 pracovní dny
Nízká	24 pracovních hodin	10 pracovních dnů

Dodávka rovněž musí zahrnovat údržbu produktu po dobu trvání technické podpory. Údržba představuje poskytování všech nových verzí produktu na datovém nosiči nebo elektronicky, včetně příslušné dokumentace a implementaci nových verzí do prostředí zadavatele. Dodavatel bude povinen zajistit, že veškeré funkce popsané v zadávací dokumentaci budou odpovídat platným právním předpisům ČR a budou v souladu s poskytnutou dokumentací k produktu.

7.6Záruční lhůta

Dodavatel odpovídá za vady dodávky po dobu záruční lhůty, které je stanovena v délce 36 měsíců.

1 Ceny jsou zaokrouhleny na celé částky.

Document Metadata

Table of Contents

Zadávací dokumentace (ZD) k veřejné zakázce dle zákona č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů (dále jen „zákon“) Název veřejné zakázky: Dodávka SW pro evidenci katalogu kulturního dědictví

Document Metadata