Masarykova univerzita Fakulta informatiky
Diplomová práce
Systémy pro správu dokumentů
Brno 2007 Kamil Kočí
Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, kterou jsem při vypracování používal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Je mojí milou povinností poděkovat RNDr. Pavlu Hajnovi za odborné vedení a konzultace při vypracování mé diplomové práce.
1. Shrnutí
Cílem této diplomové práce je prozkoumat oblast tvorby systému pro správu dokumentů. Výsledkem bude popis požadavků a technologií umožňujících tvorbu takového systému. Na základě těchto znalostí bude systém navržen.
2. Klíčová slova
dokument, systém pro správu dokumentů, úložiště dat
1. Úvod...7
1.1. Cíl práce ...7
2. Požadavky na systém správy dokumentů...9
2.1 Problémy správy dokumentů...9
2.2 Požadavky na správu dokumentů...10
3. Související technologie ...13
3.1 XML...13
3.2 JNDI ...14
3.3 LDAP ...14
3.4 Active Directory...14
3.5 OCR, ICR...15
3.6 Elektronický podpis ...16
3.7 Web Service ...17
3.8 WSDL ...20
3.9 UDDI...27
4. Právní normy...28
4.1 Spisová služba...28
4.2 Zákon o archivnictví a spisové službě a o změně některých zákonů 28 4.3 Vyhláška o podrobnostech výkonu spisové služby...29
5. Existující systémy DMS...30
5.1 eFiles ...30
5.2 KnowledgeTree ...30
5.3 DMS řešení společnosti Your System ...30
5.4 FileNet...31
6. Popis systému...32
6.1 Klíčové vlastnosti systému...32
6.2 Životní cyklus dokumentu ...37
6.3 Datový Model systému ...40
6.4 Diagramy datových toků ...43
7. Závěr ...45
7.1 Výhody použití systému...45
7.2 Možné problémy s nasazením systému...45
7.3 Realizace systému ...46
8. Slovník ...47
9. Literatura ...50
1. Úvod
Každá organizace pracuje s větším množstvím dokumentů. Tyto dokumenty mohou vznikat přímo nebo přicházejí z okolního prostředí. Mohou být standardně pouze papírové nebo elektronické, což je stále častější případ.
Různé typy dokumentů si pak vyžadují různé přístupy. Neméně důležitá je také bezpečnost. Neoprávněné přístupy nebo změny dokumentů jsou samozřejmě nežádoucí.
S rozvojem informačních technologií počet dokumentů narůstá a zároveň rostou požadavky na operace s nimi prováděné. Klasickým příkladem je vyhledávání nad dokumenty, kde by vyhledávaný dokument měl být téměř okamžitě dostupný.
Zajistit tyto všechny požadavky bez kvalitního systému pro správu dokumentů (DMS) je jen velmi těžko realizovatelné. Vhodný systém by pak měl pokrývat celý životní cyklus dokumentu, jako jeho pořízení, úpravy, předání ve schvalovacím řízení ostatním uživatelům apod. Životní cyklus končí jeho archivací v datovém úložišti, často i výstupem konečnému příjemci.
Přístup k dokumentům by měl být řízen na základě sdílených uživatelských účtů a práv. Měl by být snadno přizpůsobitelný a snadno ovladatelný, protože bude užíván pracovníky na všech stupních organizace.
1.1. Cíl práce
Cílem mé diplomové práce je seznámit čtenáře s problémy, které se mohou objevit při tvorbě takového informačního systému a pomoci při jejich řešení.
V první časti jsou podrobně rozebrány požadavky na systém pro správu dokumentů. Dále pak jsou blíže popsány technologie a znalosti, které je potřeba při tvorbě takového systému ovládat. Více do hloubky je popsán Web Services, což je velmi zajímavá technologie umožňující komunikaci s ostatními
přiblíženy jednotlivé prvky systému. Následující kapitola je pak věnována některým právním normám, které se úzce dotýkají tvorby správního systému.
Závěrem jsou v poslední části shrnuty výhody nasazení takového systému.
Pevně věřím, že tato diplomová práce pomůže všem, kteří budou podobný systém navrhovat.
2. Požadavky na systém správy dokumentů
Cílem této kapitoly je seznámit čtenáře s problémy při práci s dokumenty v organizacích. Z těchto problémů lze posléze určit požadavky, které systém na správu dokumentů musí splňovat.
2.1 Problémy správy dokumentů
• Velké množství dokumentů – v organizacích vznikají stále nové dokumenty a další verze dokumentů stávajících. To má za následek nárůst množství dokumentů, se kterými systém musí pracovat.
• Různorodost dokumentů – dokumenty v organizaci jsou v mnoha různých typech např. faktury, smlouvy, vnitřní předpisy. Každý typ dokumentu vyžaduje specifický přístup a možnost různých operací nad dokumentem.
• Orientace v dokumentech – časem se v organizaci vyskytuje velké množství dokumentů na různých místech a není snadné najít ten správný a právě aktuální dokument.
• Obtížná dostupnost dokumentů – dokument v papírové podobě je uchováván na jednom místě, což tedy neumožňuje jednoduchý přistup odkudkoli.
• Bezpečnost dokumentů – u papírových dokumentů je obtížné uplatňovat řízení přístupu. Je těžké určit, u koho se nacházejí.
Předávání se málokdy zapisuje, takže nelze snadno dohledat, kde došlo k případnému úniku informací.
• Schvalování a připomínkování dokumentů – předávací cyklus může být vnitřními předpisy dobře definovaný, ale realita bývá často jiná. Lze totiž jen obtížně zjišťovat, zda jsou tyto předpisy důsledně dodržovány.
Zaměstnanci nejsou upozorňováni na termíny, které musí být dodrženy.
Jednoduše nelze zjistit, kde a v jakém stavu se dokument právě nachází a tak bývají tyto procesy dost chaotické.
2.2 Požadavky na správu dokumentů
• Jednoduché a přehledné uživatelské rozhraní - se systémem pracují lidé na všech úrovních organizace. Jedná se o uživatelé, kteří jsou různě zkušení v používání počítačového software. Systém musí být tedy maximálně jednoduchý na používání a velice přehledný. Měl by dodržovat standardy, které jsou v oblasti vývoje. Například struktura menu, ovládání myši, pojmenování apod.
• Přehledná struktura dokumentů - s uživatelským rozhraním úzce souvisí i struktura uložených dokumentů. Struktura by měla být co možná nejvíce přehledná a měnitelná. Snadné by mělo být také vytváření nových struktur nad stejnými daty. Jiný pohled na data totiž bude mít účetní a jiný pohled vrcholový manager.
• Vyhledávání – v systému je většinou uloženo velké množství dokumentů. Je tedy nezbytné, aby systém umožňoval v těchto dokumentech vyhledávat. Pomocí nastavení atributu by mělo být možné definovat co a kde se má vyhledávat.
• Přistup k dokumentům z libovolného místa - k systému lze přistupovat pomocí klienta, který může být nainstalovaný na libovolném počítači, nebo také pomocí webového rozhraní. Díky tomu lze k dokumentům a funkcím systému přistupovat z libovolného místa, které má přístup k internetu. Užitečná funkce je také možnost stáhnout si data na lokální počítač, čímž je možno pracovat offline a při dostupnosti připojení provést aktualizaci dat.
• Automatická tvorba verzí dokumentů - každá změna dokumentu nebo jeho vlastností vyvolá vytvoření nové verze. Tento proces je zcela
automatický a uživatele nezatěžuje. Lze se tedy vrátit k libovolné verzi a zjistit změny, které se udály a kdo je provedl.
• Důsledné uplatňování bezpečnostní politiky – systém musí umět definovat přístupová oprávnění a následně je respektovat.
• Multiuživatelský přístup k dokumentu – jedna z nesporných výhod používaní systému pro správu dokumentů je možnost přístupu několika uživatelů ve stejném okamžiku.
• Flexibilita systému – každá organizace se vyvíjí. Je tedy přirozené, že se mění i požadavky na systémy, které používá. Systémy tedy musí být dostatečně flexibilní, aby těmto změnám v co nejmenším čase a pomocí co nejmenšího úsilí vyhověly.
• Komunikace s ostatními systémy – systém pro správu dokumentů je vždy nasazen do prostředí, kde existuje množství různých systémů a proto musí být schopný s nimi komunikovat.
• Vytváření standardních dokumentů – velké množství dokumentů se vytváří podle určitých šablon. Systém musí umět tuto činnost podporovat.
• Převod papírových dokumentů na elektronickou verzi – aby bylo vůbec možné s dokumenty, které jsou v papírově podobě, v systému pracovat, musíme vytvořit jejich elektronickou verzi. Tento krok by měl mít v systému podporu a maximálně tuto práci zjednodušit.
• Schvalovací a připomínkovací proces – v řadě organizací se jedná o klíčové procesy, proto musí mít v systému podporu. Systém musí umět předdefinovat schvalovací či připomínkovací cykly a následně dohlížet na jejich plnění. U dokumentu musí být vždy jasné, v jakém stavu se právě nachází.
• Archivace dokumentů – dokument musí být možno opatřit skartačními a archivačními znaky, aby na konci životního cyklu bylo možno dokument podle nich zpracovat.
• Vazby dokumentu – dokument se v organizaci většinou váže k některým procesům. Může být dokonce výstupem či začátkem nějakého procesu. Proto je žádoucí, aby tyto vztahy bylo možné k dokumentu evidovat.
3. Související technologie
3.1 XML
XML je metajazyk, což znamená, že slouží k popisu dalších jazyků. Sám neobsahuje žádné předdefinované elementy. K tomu je potřeba použít jiné standardy, jako je například DTD (Dokument Type Definition), XML schéma apod.
Název jazyka vznikl jako zkratka z Extensible Markup Language. Jazyk byl vyvinut konsorciem W3C (World Wide Web Consorcium). Tato organizace dále zabezpečuje jeho vývoj.
XML dokument obsahuje pouze data a značky, které tyto data popisují.
V žádném případě neobsahuje informace o tom, jak se mají tato data zobrazovat.
Zjednodušeně lze říci, že dokument lze rozdělit do pojmenovaných jednotek a podjednotek nazývaných elementy. Každý element může obsahovat atributy, další elementy nebo data. Aby byl XML dokument správně formátovaný (well formed), musí splňovat následující pravidla:
• Každý element musí mít uzavírací tag nebo musí být napsaný ve zkráceném formátu: <element/>. Element napsaný ve zkráceném formátu může obsahovat pouze atributy.
• Elementy se nesmějí křížit.
<elementA><elementB>text</elementA></elementB> - špatný formát
<elementA><elementB>text</elementB></elementA> - správný formát
• V názvech elementů a atributů se rozlišuje malými a velkými písmeny.
• Hodnota atributů musí být ohraničena uvozovkami nebo apostrofy.
• XML dokument musí mít právě jeden kořenový element, který obsahuje všechny ostatní elementy.
• V dokumentu lze také použít komentáře <!-- komentář -->.
Dokument se dále označuje platný (valid), pokud je správně formátovaný a splňuje definici dokumentu.
3.2 JNDI
Rozhraní, pomocí kterého mohou aplikace napsané v programovacím jazyku Java získávat a ukládat objekty různých typů. Dále pak umožňuje vyhledávání objektů pomocí atributů, které je možné měnit. Rozhraní je nezávislé na konkrétní implementaci Naming service nebo Directory service. Pojem Naming service znamená službu, která obsahuje seznam objektů nebo odkazů na objekty. Množina těchto vazeb se nazývá jmenný prostor. Directory service umožňuje přiřazovat jednotlivým vazbám atributy a provádět nad nimi vyhledávání.
3.3 LDAP
Jedná se o protokol určený pro správu adresářů a pro práci s informacemi o uživatelích. Adresářem je myšleno nějaké centrální úložiště, které ukládá data.
V tomto případě data představují informace o uživatelích, aplikacích a jmenných službách. Data mají stromovou strukturu a každý záznam se skládá ze tří částí - unikátní název záznamu, popis záznamu a typ záznamu. Protokol je postavený na dvouvrstvé architektuře klient - server. Komunikace pak může probíhat buď synchronně nebo asynchronně. Ve světě operačního systému Linux se jako implementace LDAP serveru používá např. OpenLDAP a pro operační systémy Windows existuje nativní řešení Active Directory.
3.4 Active Directory
Jedná se o implementaci adresářové služby LDAP. Umožňuje ukládat informace o objektech v síti a poskytuje tyto informace uživatelům. Firma
Microsoft dále poskytuje rozhraní ADSI (Active Directory Service Interface), které umožňuje programátorům vytvářet adresářové programy.
3.5 OCR, ICR
Jedná se o technologii pro převod strojově psaného textu do elektronické podoby. Tato technologie umožňuje rychlý a levný způsob převodu velkého množství dokumentů. Převod je v drtivé většině několikanásobně rychlejší než ruční přepisování.
Důležitou vlastností převodu je jeho přesnost. Velké množství chyb sebou následně nese množství oprav, což může zapříčinit, že ruční přepsání textu by bylo rychlejší. Proto má význam co nejpřesnější naskenování.
Systém funguje tak, že v prvním kroku rozdělí dokument podle naskenované předlohy do jednotlivých řádků. Dále rozděluje jednotlivá slova na řádku podle mezer mezi slovy. V další fázi rozděluje ve slovech jednotlivá písmena. V případě použití neproporciálního písma se jedná o relativně jednoduchou operaci. Problém nastává v případě použití písma proporciálního, kde každý znak má jinou šířku. Ještě obtížněji se převádí text, který je špatně čitelný např. poškozený papír, ze kterého se skenuje, písmena se navzájem dotýkají apod. Nakonec se jednotlivá písmena identifikují a to pomocí určitých charakteristik (čáry, mezery, uzly, úhly, atd.). Tomuto přístupu se říká topologická analýza. Dnes programy OCR procházejí textem několikrát a v posledních průchodech používají tzv. spellchecker, který daná slova kontroluje a popřípadě i doplňuje. Ještě přesnější převod zajišťují metody, kde se OCR software sám učí z již rozpoznaných písmen.
Většina software pro převod umožňuje převod dokumentů do různých formátů například textového souboru, pdf nebo rtf formátu.
Další technologie, která se používá pro převod textů do elektronické podoby je ICR (Intelligent Character Recognition). Jedná se o inteligentní rozpoznávání ručně psaných znaků.
3.6 Elektronický podpis
Princip
Elektronický podpis aplikuje kryptografii s veřejným klíčem, u které se používá asymetrická šifra. Při použití se také několikrát používá tzv. kontrolní vzorek (digest). Ten má následující vlastnosti:
• Pro stejnou zprávu má kontrolní vzorek vždy stejné hodnoty.
• Nelze zajistit, aby dvě různé zprávy měli na výstupu dva stejné kontrolní vzorky.
• Z kontrolního vzorku nelze získat informace o vstupní zprávě.
Vytvoření elektronického podpisu
1. Z dat určených k podpisu se vytvoří kontrolní vzorek.
2. Kontrolní vzorek se zašifruje privátním klíčem tvůrce dokumentu a zašifrovaný kontrolní vzorek, který tvoří elektronický podpis se ke zprávě připojí.
Ověření elektronického podpisu
1. Vypočítá se opět kontrolní vzorek.
2. Dešifruje se daný elektronický podpis a získá další kontrolní vzorek.
3. Pokud se oba vzorky rovnají, je pravost podpisu potvrzena.
Získání elektronického podpisu
Elektotronický podpis lze získat od certifikační autority. V současné době mohou elektronické podpisy nabízet např. První certifikační autorita, a.s., Certifikační autorita Czechia a Česká pošta.
Bezpečnost
Z důvodu dodržení bezpečnostního standardu je potřeba dodržet několik bezpečnostních pravidel. Je potřeba uchránit privátní klíč, za což zodpovídá osoba, která je majitelem privátního klíče. Nesmí být prolomeny algoritmy, které se používají pro šifrování a výpočet kontrolního vzorku. Dále je pak nutné se spolehnout na to, že údaje, které jsou obsažené v certifikátu jsou pravdivé. Tento problém řeší certifikační autorita.
3.7 Web Service
Jedná se o technologii pro vzdálené volání procedur pomocí přenosu zpráv.
Důležité je, že se jedná o komunikaci mezi stroji a nikoliv mezi strojem a člověkem. Proto musí být komunikace strojově zpracovatelná. Zprávy jsou napsány ve formátu XML. Pro vzdálené volání procedur se používá protokol SOAP. Dále je použit standard pro popis webových sužeb WSDL a podpora pro vyhledávání je definována ve standardu UDDI.
Jedná se o technologii, která je platformově nezávislá a není ani vyvíjená jednou nebo několika komerčními organizacemi, ale je založena na standardech konsorcia W3C.
SOAP verze 1.2
SOAP je protokol pro výměnu strukturovaných informací v decentralizovaném a distribuovaném prostředí. Pro výměnu informací se používá formát XML.
Protokol nezávisí na použité síťové vrstvě a ani na použitém programovém prostředí. Při tvorbě protokolu byl důraz kladen na jednoduchost a rozšiřitelnost, proto protokol neřeší ostatní oblasti přenosu zpráv, jako je například bezpečnost a spolehlivost.
SOAP protokol se skládá z následujících částí:
• Model zpracování.
1. Model rozšiřitelnosti.
2. Framework pro propojení s nižšími vrstvami.
3. Definice struktury SOAP zprávy.
Model zpracování
Poskytuje model pro zasílání zpráv mezi uzlem, který odesílá zprávu (SOAP sender) k uzlu, pro který je zpráva určena (SOAP receiver). Zpráva může procházet přes libovolný počet uzlů zvaných prosředníci (SOAP intermediarie).
Navíc při zpracování zprávy může uzel hrát několik rolí. Role je identifikovaná pomocí URI. Role je během zpracování jedné zprávy neměnná.
Model zpracování SOAP definuje tři role, které mají speciální význam:
• next - tuto roli musí hrát každý prostředník a každý příjemce zprávy
• none - žádný uzel nesmí hrát tuto roli
• ultimateReceiver - koncový uzel musí hrát tuto roli
Samozřejmě lze definovat role další. Vlastnost rolí je důležitá proto, že bloky v hlavičce můžou nést informaci, pro jakou roli jsou určené. Tímto můžeme určit, jaké bloky hlavičky mají být zpracované.
Definice struktury SOAP zprávy
Envelope element
Envelope element je kořenový element zprávy. V tomto elementu se definuje
jmenný prostor xmlns:SOAP-ENV a to hodnotu
http://schemas.xmlsoap.org/soap/envelope/. Pokud má jmenný prostor jinou hodnotu, aplikace by měla generovat chybu. Dále zde lze definovat atribut soap:encodingStyle="http://www.w3.org/2003/05/soap-envelope, který definuje způsob kódování přenášených dat do XML. SOAP umožňuje
Header element
Tento element je nepovinný, lze pomocí něho rozšiřovat SOAP zprávy.
Ukládají se zde pomocně informace, které mohou být závislé na aplikaci.
Pokud existuje , musí být prvním potomkem elementu Envelope.
Jeden z atributů tohoto elementu může být mustUnderstand. Tento element určuje, zda příjemce zprávy musí umět zpracovat hlavičku. Defaultní hodnota tohoto elementu je false. Pokud však nastavíme hodnotu na true, musí příjemce zpracovat hlavičku zprávy nebo selhat při zpracování. Tento atribut zajištuje, že aplikace bude plně rozumět zprávě a ne jen tiše ignorovat části hlavičky, kterým nerozumí.
Body element
Element poskytuje sémantiku pro výměnu informací pro koncového příjemce zprávy. Tento element je povinný a musí být správně aplikací zpracován, jinak musí aplikace selhat při zpracování.
V případě, že existuje element Header, musí bezprostředně následovat před tímto elementem. Pokud element Header neexistuje, je element Body prvním potomkem elementu Envelope.
Žádný uzel kromě cílového nesmí během cesty nahlížet ani modifikovat element Body během cesty zprávy.
Body element definuje jednoho potomka, a to element Fault.
Fault element
Nepovinný element, který je potomkem elementu Body. Element se může ve zprávě vyskytnou nejvýše jednou. Obsahuje následující potomky:
• Code element - povinný element identifikující chybu
• Reason element - povinný element obsahující popis chyby
• Node element- nepovinný element určující jaký element je zodpovědný za vyvolání chyby
• Role element - nepovinný element vyjadřující element, ve kterém chyba nastala
• Detail element - nepovinný element popisující chyby, které nastaly Standard SOAP definuje následující chyby:
• VersionMismatch - ve zprávě se vyskytl neznámý element, který není v této verzi SOAP definován
• MustUnderstand - nelze správně zpracovat obsah hlavičky, jak požaduje element mustUnderstand
• DataEncodingUnknown - neznámé kódovaní zprávy
• Sender - zpráva byla špatně vytvořena, příjemce není schopný zprávu zpracovat (např. autentifikace)
• Reciever - zpráva nemůže být korektně zpracována uzlem
3.8 WSDL
WSDL je jazyk pro popis webových služeb. Lokalizuje službu, definuje typy parametru, návratové hodnoty atd. WSDL je dokument XML. Následuje definice WSDL:
<wsdl:definitions name="nmtoken"? targetNamespace="uri"?>
<import namespace="uri" location="uri"/>*
<wsdl:documentation .... /> ? <wsdl:types> ?
<xsd:schema .... />*
<-- extensibility element --> * </wsdl:types>
<wsdl:message name="nmtoken"> * <wsdl:documentation .... />?
<part name="nmtoken" element="qname"? type="qname"?/> * </wsdl:message>
<wsdl:portType name="nmtoken">*
<wsdl:documentation .... />?
<wsdl:operation name="nmtoken">*
<wsdl:documentation .... /> ?
<wsdl:input name="nmtoken"? message="qname">?
<wsdl:documentation .... /> ? </wsdl:input>
<wsdl:output name="nmtoken"? message="qname">?
<wsdl:documentation .... /> ? </wsdl:output>
<wsdl:fault name="nmtoken" message="qname"> * <wsdl:documentation .... /> ?
</wsdl:fault>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="nmtoken" type="qname">*
<wsdl:documentation .... />?
<-- extensibility element --> *
<wsdl:operation name="nmtoken">*
<wsdl:documentation .... /> ? <-- extensibility element --> * <wsdl:input> ?
<wsdl:documentation .... /> ? <-- extensibility element -->
</wsdl:input>
<wsdl:output> ?
<wsdl:documentation .... /> ? <-- extensibility element --> * </wsdl:output>
<wsdl:fault name="nmtoken"> * <wsdl:documentation .... /> ? <-- extensibility element --> * </wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="nmtoken"> * <wsdl:documentation .... />?
<wsdl:port name="nmtoken" binding="qname"> * <wsdl:documentation .... /> ?
<-- extensibility element -->
</wsdl:port>
<-- extensibility element -->
</wsdl:service>
<-- extensibility element --> *
</wsdl:definitions>
Elementy
Type
Element Type definuje datový typ elementu. Pro definici typu používá XML Schema. Díky tomu lze definovat vlastní datové typy:
<wsdl:types> ?
<wsdl:documentation .... />?
<xsd:schema .... />*
<-- extensibility element --> *
</wsdl:types>
Message
Definuje formát předávaných zpráv. Obsahuje jednu nebo několik logických částí. Každá část je definovaná pomocí atributů name, element a type. Atribut name označuje jedinečné jméno elementu. Element type určuje typ elementu a konečně element Element se odkazuje na element určený tímto jedinečným jménem. V programování by se toto dalo přirovnat k definici parametrů:
<wsdl:message name="nmtoken"> * <wsdl:documentation .... />?
<part name="nmtoken" element="qname"? type="qname"?/> * </wsdl:message>
Port Type
Množina operací (operation). Atribut name má hodnotu jedinečného jména a pomocí něho se může volat konkrétní element Port Type:
<wsdl:definitions .... >
<wsdl:portType name="nmtoken">
<wsdl:operation name="nmtoken" .... /> *
</wsdl:portType>
</wsdl:definitions>
WSDL definuje čtyři druhy operací, které by měly koncové uzly podporovat:
• One-way Operation - koncový uzel, přijme zprávu a neopovídá na ni.
<wsdl:definitions .... >
<wsdl:portType .... > *
<wsdl:operation name="nmtoken">
<wsdl:input name="nmtoken"? message="qname"/>
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>
• Request-response - koncový uzel přijme zprávu a odešle odpovídající odpověď. Zpráva má následující formát:
<wsdl:definitions .... >
<wsdl:portType .... > *
<wsdl:operation name="nmtoken"
parameterOrder="nmtokens">
<wsdl:input name="nmtoken"? message="qname"/>
<wsdl:output name="nmtoken"? message="qname"/>
<wsdl:fault name="nmtoken" message="qname"/>*
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>
Elementy input a output definují formát zpráv. Element fault je volitelný element, který určuje chybové zprávy. Ty mohou být výsledkem
operace, kterou uzel po zpracování zprávy provádí. Jedná se o nejrozšířenější typ webové služby.
Solicit-response
Operace velmi podobná předchozímu případu.
<wsdl:definitions .... >
<wsdl:portType .... > *
<wsdl:operation name="nmtoken"
parameterOrder="nmtokens">
<wsdl:output name="nmtoken"? message="qname"/>
<wsdl:input name="nmtoken"? message="qname"/>
<wsdl:fault name="nmtoken" message="qname"/>*
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>
Zde webová služba nejdříve vysílá zprávu a následně obdrží odpověď.
Notification
Webová služba pouze odesílá požadavek.
Definice:
<wsdl:definitions .... >
<wsdl:portType .... > *
<wsdl:operation name="nmtoken">
<wsdl:output name="nmtoken"? message="qname"/>
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>
Binding
Element Binding definuje protokol a formát zpráv pro daný Port Type. Atribut name opět jednoznačně identifikuje tento element. Atribut Type určuje typ portu, ke kterému element Binding náleží. Element definuje pomocí atributu transport právě jednoho protokolu, pomocí kterého jsou zprávy posílány.
Posledním atributem je atribut Style, který nabývá hodnoty 'rcp' v případě vzdáleného volání procedury nebo hodnoty 'document' při zasílání dokumentu.
Port
Definuje koncový bod služby. Spojuje element Binding s konkrétní adresou. Je jednoznačně identifikovaný pomocí atributu name. Binding atribut odkazuje na definovaný element binding. Port nemůže definovat více než jednu adresu a neobsahuje žádné jiné informace o vazbě.
Service
Popisuje jednu webovou službu. Jedná se o kolekci elementů port.
3.9 UDDI
Jedná se o webovou službu, která umožňuje publikovat a vyhledávat informace o těchto službách. Nejnověji se nachází ve verzi 3.0. Funguje jako obrovský adresář obsahující informace o jednotlivých službách a firmách, které tyto služby poskytují. Tento adresář se nazývá registr. Jak již bylo zmíněno, je tento registr také webová služba a proto k němu přistupujeme pomocí SOAP.
4. Právní normy
4.1 Spisová služba
Spisová služba je informační systém sloužící ke sledovaní celého oběhu dokumentů, jak v papírové podobě, tak v podobě elektronické. Slouží k evidování informací o průběhu celého životního cyklu dokumentu od jeho příchodu, zpracování až po jeho archivaci či skartaci. Systém zefektivňuje práci s dokumenty za dodržení standardů pro ochranu osobních údajů.
4.2 Zákon o archivnictví a spisové službě a o změně některých zákonů
Zákon (č. 499/2004 Sb.) upravuje, kdo má za povinnost vykonávat spisovou službu. Jsou to například kraje, obce s pověřeným obecním úřadem a obce se stavebním nebo matričním úřadem, státní příspěvkové organizace, státní podniky, územní samosprávné celky, školy, právnické osoby zřízené zákonem a zdravotnická zařízení.
V zákoně pojem původce vyjadřuje každého, z jehož činnosti dokument vznikl. Původci jsou povinni zajistit řádný příjem dokumentů a za tímto účelem jsou povinni si zřídit podací deník. V něm jsou v číselném a časovém pořadí zadávány příchozí dokumenty, popřípadě ústně podaná podání. Všechny dokumenty, které jsou podány, se opatří razítkem s podacím číslem.
Původci jsou povinni vydat vnitřní předpis pro výkon spisové služby označovaný jako spisový a skartační řád.
Prováděcí právní předpis stanoví podrobnosti výkonu spisové služby, a to:
• příjem dokumentů
• evidenci dokumentů
• vyřizování dokumentů
• vyhotovování dokumentů
• podepisování dokumentů a užívání razítek
• odesílání dokumentů
• ukládání dokumentů
• zvláštnosti výkonu spisové služby za pomoci výpočetní techniky
4.3 Vyhláška o podrobnostech výkonu spisové služby
Vyhláška (č. 646/2004 Sb.) upravuje činnost v těchto oblastech:
• příjem dokumentů
• evidence dokumentů
• rozdělování a oběh dokumentů
• vyřizování dokumentů
Příjem dokumentů
Příjem dokumentů je prováděn podle zákona 496/2004 Sb. o elektronických podatelnách. Dokument se při zaevidování opatří otiskem podacího razítka, nebo v případě digitálního podání identifikátorem elektronické podatelny. Dále se dokument předá k vyřízení.
Evidence dokumentů
Dokumenty se evidují v tzv. podacím deníku. Dokumenty se v podacím deníku evidují v číselném nebo časovém pořadí podle zařazení. Každý dokument je označen číslem jednacím. Číslo jednací obsahuje vždy zkratku označení určeného původce nebo jeho organizační jednotky, pořadové číslo zápisu
dokumentu v podacím deníku a označení kalendářního roku, v němž je dokument evidován.
Rozdělování a oběh dokumentů
Při oběhu dokumentů musí být zabezpečeno sledování jeho předávání a přebírání, zaručena průkaznost předávání a přebírání zachycující jmenovitě a časově veškerou manipulaci s dokumentem.
5. Existující systémy DMS
5.1 eFiles
Jedná se o řešení společnosti RKA SW Systems s.r.o., která působí na trhu od roku 1999. Tato společnost svůj produkt představuje jako srozumitelný, snadno nastavitelný a rozšiřitelný systém pro správu dokumentů. Mezi jeho přednosti patří přístup přes webové rozhraní, snadný převod formulářů z MS Wordu nebo Ms Excelu, ale také možnost systému využít pro vytvoření vlastního redakčního systému, specializovaného systému např. pro evidenci zákaznických požadavků, firemního intranetu nebo elektronického obchodu.
Systém eFiles může také sloužit jako workflow management.
5.2 KnowledgeTree
OpenSource řešení DMS. Oficiálním partnerem tohoto produktu pro Českou republiku je firma blue.point, která se mimo jiné podílí na vývoji. Software je založen na platformě intranetového/extranetového webu. Celá aplikace vyvíjena na PHP a jako svojí databázi používá MySQL. Řešení obsahuje také některé pokročilé funkce jako je například podpora pro OCR, Integrace autentizace a autorizace s LDAP nebo prohledávání obsahu dokumentů ve formátech Microsoft Office, OpenDocument, PDF, XML, HTML, RTF.
5.3 DMS řešení společnosti Your System
Jedná se o českou společnost, která nabízí celou škálu produktů v oblasti informačních technologií. Jeden z produktů je jejich systém pro správu
dokumentů. Jako klient k serveru lze použít WWW prohlížeč Microsoft Internet Explorer nebo klient Lotus Notes. Systém podporuje například práce se skenovanými dokumenty (možnost použití OCR), formuláře vytvořené v produktech MS Office, kde je možno automatické zpracování dat v nich obsažených.
5.4 FileNet
Produkt společnosti sídlící v Kalifornii. V České republice je jeden z distributorů firma AutoCont CZ a.s. Jedná se o produkt pro velké společnosti, kde se cena instalace pohybuje řádově v milionech. Nejedná se pouze o systém pro správu dokumentů, ale zároveň i o systém pro řízení procesů s možností připojení podnikových aplikací. Mezi jeho hlavní přednosti patří tvorba vyhledávacích filtrů, fulltextové vyhledávání a publikování dokumetů ve formátech html nebo pdf.
6. Popis systému
Dokumentový server je nástroj pro správu dokumentů uvnitř organizace.
Systém sleduje celý životní cyklus dokumentů libovolného typu – textové a tabulkové dokumenty, obrázky, prezentace, apod. Cyklus tedy začíná jeho pořízením, pokračuje úpravami, předáváním ve schvalovacím řízení až po archivaci. Systém lze rozdělit pomocí architektury klient-server. Serverová část zajišťuje funkčnost systému a klientská část zajišťuje grafické zobrazení požadovaných dat. Klient je realizovaný pomocí klientské aplikace nebo pomocí webového prohlížeče.
6.1 Klíčové vlastnosti systému
Struktura klient-server
K aplikaci se přistupuje pomocí klienta, který umožňuje přistupovat z libovolného místa připojeného k internetu. Systém svojí architekturou umožňuje přistup více uživatelů v jednom okamžiku, což je jeden ze základních požadavků na systém.
Definování vlastních objektů v systému
Uživatel má právo si definovat v systému vlastní objekty, kterým také může posléze nastavit vlastní atributy. Tyto objekty se pak v systému chovají jako objekty ostatní a lze z nimi tedy provádět standardní operace jako je například ukládání do struktur a vytváření vazeb mezi objekty. Pomocí těchto vazeb lze například k dokumentům přiřazovat informace o procesech, které je vytvořily.
Systém se tedy stává velmi flexibilní a lze ho jednoduše přizpůsobovat podle měnících se požadavků společnosti.
Dokument
Dokument je v systému rozuměn obecněji než bývá obvyklé. Může mít fyzickou nebo elektronickou podobu. V případě existence fyzického dokumentu se vedou v evidenci důležité informace o tomto dokumentu,
jako papírový dokument a jednak jako jeho naskenovaná kopie. Oba tyto výskyty lze v systému evidovat.
Skenování dokumentů
Systém lze napojit na síťový skaner a umožňuje tedy pohodlný převod papírových dokumentů na dokumenty elektronické. Dokument je pak uložen jako obrázkový soubor. Zároveň lze z dokumentu získat textová data, která se mohou k dokumentu připojit a umožnit tak například vyhledávání nad daným dokumentem.
Vyhledávání
Vyhledávání je možné nad všemi objekty, například metadata souborů, kontakty atd. Vyhledávat lze také v archivu.
Integrovaný adresář kontaktů
Kontaktem může být externí firma, zaměstnanci organizace nebo jiné libovolné osoby. Jednou z možností reprezentace adresáře kontaktů je databázová tabulka, kterou lze libovolně rozšiřovat. Adresář lze také integrovat s externí databázovou službou např. centrálním úložištěm organizace, LDAP nebo Active Directory. Kontakty lze seskupovat do skupin, hierarchicky je řadit a přidávat jim libovolné atributy. Je možné evidovat a sledovat návaznosti kontaktu na ostatní objekty systému (adresované úkoly v organizéru, autorství záznamu apod.).
Sledování změn a verzování dokumentů
Systém sleduje a eviduje přístupy k dokumentu - čtení, modifikace obsahu, změna vlastností apod. Každá změna dokumentu vytváří jeho novou verzi.
Každá verze je opatřena informací o tom, kdo a kdy změnu provedl, případně může být doprovázena textovým popisem změn. K dokumentu lze nastavit notifikaci změn pro seznam uživatelů, kteří jsou o změně informováni.
Upozornění o modifikaci dokumentu se objeví na pracovní ploše klienta nebo
je zasláno emailem. Tato vlastnost splňuje požadavek na automatické verzování dokumentů.
Kategorizace dokumentů
Každý objekt lze opatřit nadstandardními poznávacími znaky - kategoriemi.
Kategorie lze uživatelsky definovat, vytvářet jejich hierarchii a vlastnosti.
Příkladem může být typ dokumentu - smlouva, faktura, nabídka apod.
Kategorie lze následně použít ve vyhledávání nad dokumenty, což je jeden z požadavků na systém.
Přístupová práva
Řízení přístupu je založeno na povolení nebo odepření některých ze sady oprávnění, které nabízí systém pro daného uživatele či skupinu. Oprávnění je definováno vůči nějakému objektu systému. Systém neumožňuje provádět uživateli operace, na které nemá oprávnění. Následkem toho si systém vynutí dodržování bezpečností politiky, která je nastavena.
Předávání dokumentů
Jedná se nástroj pro sledování pohybu dokumentů v rámci organizace i mimo ni. Dokument se může nacházet u nějaké osoby (definované pomocí kontaktu) nebo v nějaké lokalitě. Při předání dokumentu lze stanovit účel předání. Účel předání je vlastnost, která může mít jednu z předdefinovaných hodnot nebo dle lze zadat uživatelem. Účelem může být např. Schválení, Nahlédnutí, Archivace (Uzavření), apod.. Součástí předání je i termín vyřízení účelu předání.
Předání dokumentu probíhá na principu předání a převzetí. Osoba, která vlastní dokument je za něj zodpovědná do chvíle, než jej někdo převezme.
Mezi předáním a převzetím dokumentu může nastat určitá prodleva.
Předdefinované předávání dokumentů
Každý dokument lze opatřit předdefinovaným předáváním dokumentů tzv.
vzorem předání dokumentů mezi osobami a pracovištěmi. Dokument má pak
definováno, kde by se měl v konkrétním čase nalézat. Skutečný průběh předávání dokumentu však může být (a většinou i je) jiný. Mohou se zejména změnit některé termíny, dokument může být předán navíc dalším osobám a tak podobně. Proto je předdefinované workflow vedeno jen jako informace o tom, jak by se mělo s dokumentem nakládat. Nekoresponduje tedy se skutečným průběhem předání dokumentu.
Schvalování dokumentů
Dokument lze předávat osobám ke schválení (revizi) a k úpravám. Schvalovat může kdokoliv včetně externích subjektů, kteří k systému přistupují přes webové rozhraní. Systém nabízí jednoduché rozhraní revidujícím osobám, které s jeho pomocí mohou snadno k dokumentu připojit své připomínky a vyjádření. Řízení schvalování zajišťuje organizér.
Správce šablon
Jedná se o specialní složku, kde administrátoři ukládají šablony a vzorové dokumenty. Správce šablon zajišťuje, aby šablona po použití zůstala vždy v původním stavu. Systém se stará o automatickou správu šablon a jejich verzování. Samozřejmostí je vazba mezi dokumentem a šablonou, ze které vznikl. Tato vlastnost systému podporuje vytváření standardních dokumentů.
Práce s nesouborovými dokumenty
Dokumentový server umožňuje evidovat i dokumenty, ke kterým neexistuje datový soubor. Jedná se tedy spíše o informaci, že takový dokument existuje a kde se nachází (např. v archivu).
S nesouborovými dokumenty lze pracovat jako s dokumenty běžnými, jen nejsou dostupné funkce pro práci se samotným obsahem. K těmto dokumentů lze samozřejmě přiřadit klíčová slova a proto nad nimi lze s úspěchem použít vyhledávání.
Správa pracovišť
Pracoviště je nějaká lokalita definovaná uživatelem systému. Například firemní recepce, spisovna nebo fyzické archivy. K pracovišti lze přiřadit zaměstnance, kteří na daném pracovišti pracují. Dále pak atributy, které dané pracoviště popisují.
Modul kontakty a objekt kontakt
Jedná se o modul, který zajišťuje správu kontaktů pro celou aplikaci. Kontakt je objekt s kontaktními a adresními údaji vedenými v databázi kontaktů. Může se jednat o zaměstnance, firmy, organizace apod. Uživatel je kontakt, který má přidělené přihlašovací údaje do systému. Jedná se tedy o speciální podmnožinu kontaktů. S kontakty lze provádět standardní operace jako smazání, editace nebo duplikování. Nad kontakty lze samozřejmě vyhledávat, a to jak pomocí jednoduchého vyhledávání v názvu kontaktu, tak i pomocí upřesnění vyhledávacích parametrů.
Další z vlastností systému je možnost přiřazovat kontakty do skupin a tyto skupiny hierarchicky řadit. Skupiny mohou mít vlastní atributy. Nad skupinami lze vyhledávat.
Kontakty lze samozřejmě importovat z různých zdrojů (například z formátu VCARD), definovat import z textového souboru apod.
Datové úložiště
Jako každý jiný systém musí i dokumentový systém někam ukládat informace, se kterými pracuje. Tyto informace lze rozdělit do dvou částí. První částí jsou informace potřebné pro provoz systému, jako například informace o uživatelích, systémové data apod. Tyto informace jsou uloženy v relační databázi. V databázi jsou uloženy také metadata o dokumentech, které jsou v systému uloženy. Druhou častí je vlastní obsah dokumentů. Tyto data lze uložit do databázového systému nebo na souborový systém. Objem těchto dat může být, a většinou i je, velmi velký. Fyzické umístění těchto dat tedy lze volitelně
změnit. Data tedy mohou být na různých místech. Důvodem je možnost rozložit zátěž na systém mezi různé počítače a různé počítačové sítě. Rozložení dat je pro uživatele zcela transparentní.
6.2 Životní cyklus dokumentu
Životní cyklus dokumentu počíná ve chvíli jeho vzniku. Dokument lze vytvořit v dokumentovém serveru nebo vně systému. Pokud dokument vznikne vně systému, musí se do systému nejdříve zaregistrovat. V dalším kroku lze nastavit schvalovací cyklus, kterým dokument musí projít. Detailní popis schvalovacího cyklu viz. schvalování. Dokument lze v dalším kroku opatřit elektronickými podpisy. Pokud je dokument schválený, postupuje v organizaci dále. Dokument lze předat například na tiskový uzel, exportovat do jiných systémů apod.
V posledním kroku je dokument podstoupen archivačnímu cyklu, který je předem nastavitelný. Dokument lze opatřit archivačními znaky. Dokumenty, které nejsou určeny k archivaci, je možné smazat.
Vznik dokumentu
Dokument může vzniknout uvnitř nebo mimo organizaci. Původ dokumentu není z pohledu dokumentového serveru příliš důležitý, protože se liší pouze v některých vlastnostech např. kdo dokument přijal, jaká externí firma dokument vytvořila a podobně.
Důležitějším hlediskem, podle kterého lze dokumenty při vzniku členit, je jejich podoba. Zde se rozlišuje na dokumenty elektronické a papírové. V případě, že dokument je v elektronické podobě, je možné ho ihned zařadit do dokumentového serveru. V případě, že je v podobě papírové, jsou dvě možnosti, jak dokument zpracovat. Dokument lze naskenovat a následně vložit do systému. Druhou možností je pak vytvoření virtuálního dokumentu, ke kterému jsou pouze přiřazeny vlastnosti papírového dokumentu, ale bez vlastního obsahu. Je vhodné, aby zde také byly informace o fyzickém umístění
jednoznačný identifikátor, který umožňuje papírový dokument jednoznačně identifikovat.
V případě, že je dokument určen ke skenování, lze postupovat podle následujícího scénáře. Je důležité si uvědomit, že při skenování velkého množství dokumentů, které je ve větších organizacích obvyklé, je velmi důležitá rychlost zpracování a zařazení do systému. Nejprve se tedy dokumenty pečlivě připraví ke skenování. Rozdělí se na jednotlivé stránky, určí pořadí a rozčlení do skenovacích dávek. Následně je provedeno vlastní skenování dávek. Důležitá je také kontrola správnosti skenování. Dokument musí být dobře čitelný.
V poslední fázi je dokument uložen do systému založením nového dokumentu a vyplněním jeho atributů. Některé atributy vytváří systém sám, jako například datum vzniku, jméno uživatele, který dokument skenoval apod.
Některé atributy vyplňuje sám uživatel. Příkladem může být název dokumentu, přiřazení schvalovacího cyklu nebo klíčová slova. Poslední množinou jsou atributy, které jsou vyplněny pomocí podpůrných programových prostředků jako je např. aplikování OCR apod. Tímto krokem začíná být dokument zpracováván dokumentovým serverem.
Výběr dokumentového scanneru
Důležité je si uvědomit rozdíly mezi dokumentovým a obyčejným scannerem, který je používán pouze občas. Dokumentový scanner musí být robustní, rychlý a spolehlivý. Nákup takového zařízení není levnou záležitostí, proto je vhodné si ujasnit, co se od scanneru očekává. Velmi důležité hledisko je například podavač dokumentů. Je potřebné, aby byl schopen podat všechny typy dokumentů, které se zpracovávají. S ohledem na potřebnou kvalitu zpracovávaných dokumentů je vybírána i kvalita čtecího zařízení. Další důležitá hlediska pro výběr je rychlost digitalizace stránky a optimální počet stran, které je možno denně zpracovat. Neméně důležitá je také údržba skeneru,
která by měla být co nejjednodušší. Je vhodné, aby nebylo nutné volat dodávající firmu kvůli úkonům, jako je například čištění.
Archivace dokumentu
Způsob archivace lze rozdělit na dvě základní oblasti. Archivování dokumentů, které jsou pouze v elektronické podobě a dokumenty, které mají i svou fyzickou verzi.
Archivace dokumentů, které jsou pouze v elektronické podobě, je podstatně jednodušší. V menších objemech dat stačí u daného dokumentu nastavit příznak pro archivaci. Dokument je pak vyřazen z živých dokumentů a následně z vyhledávacích procesů. Další možností archivace je přesun objemných dat mimo úložiště. Je tak dosáhnuto zvýšení výkonnosti systému, který není zbytečně vytížen. Data lze také uložit na nějaké médium typu zálohovací pásky, DVD apod. Pokud jsou data ukládána na nějaké externí médium, musí být zašifrovány jako prostředek proti neoprávněnému nakládání s těmito daty.
Druhým případem je archivace dokumentů, které navíc existují fyzicky.
Jejich elektronický obraz se archivuje postupu popsaného výše. Vlastní fyzické dokumenty archivuje podle vnitřních předpisů organizace, tato část je však mimo rozsah této diplomové práce.
Systém musí umožňovat alespoň omezený přístup k archivovaným dokumentům. Posledním stádiem archivace některých dokumentů je jejich skartace, v případě elektronických dokumentů dojde k jejich vymazaní ze systému.
6.3 Datový Model systému
Uživatel
Typ Odpovednost
Odpovednost Typ
Uzivatel
Uzivatel
Opravneni
Role Uzivatel
Typ RoleUzivatel
• Odpovednost – Entita definuje vztah, ve kterém mohou vůči sobě být různí uživatelé.
• Opravneni – Entita definuje oprávnění uživatele provádět akce nad systémem.
• RoleUzivatel – Entita definuje roli, kterou konkrétní uživatel hraje vůči konkrétní odpovědnosti.
• Typ Odpovednost – Entita definuje typy, které mohou být entity odpovědnost.
• Typ RoleUzivatel – Entita definuje typy rolí, které mohou mít uživatelé v nějaké odpovědnosti.
• Typ Uzivatel – Entita definuje typy, které může nabývat entita uživatel.
• Uzivatel – Entita definující uživatele, kterého je vhodné evidovat v systému. Uživatelem může být například osoba, která přistupuje do systému, nebo kontakt, který pouze evidujeme, ale také firma apod.
Záznam
Typ Uloziste Typ
Zaznam
Zaznam
Hiearchie Zaznam
Typ Hiearchie
Typ
UzivatelZaznam
Hiearchie Typ
Vlastnost Vlastnost UzivatelZaznam
nebo Uzivatel
Verze Zaznam
• Hierarchie – Entita definuje hierarchické uspořádání záznamů
• HierarchieZaznam – Entita definuje vazbu mezi dvěma uzly a její příslušnost k hierarchii.
• Typ Hierarchie – Entita definuje typy hierarchií.
• Typ Uloziste - Entita definuje typ úložiště, kde jsou uložena data dokumentu.
• Typ UzivatelZaznam – Entita definující typy záznamů v entitě UzivatelZaznam.
• Typ Vlastnost – Entita definuje typy vlastností.
• Typ Zaznam – Entita definující typy záznamů.
• UzivatelZaznam – Entita definující vazby mezi uživatelem a záznamem nebo verzí záznamu.
• Vlastnost – Entita definuje vlastnosti verze dokumentu.
• VerzeZaznam – Entita definující jednotlivé vlastnosti záznamu.
• Zaznam – Entita reprezentující evidovaný záznam v systému.
Záznamem může být dokument, adresář, příloha dokumentu, připomínka apod.
6.4 Diagramy datových toků
Předání dokumentu
Uživatel
Předání
Záznam požadavek na předání
Uživatel
Převzetí
požadavek na
převzetí
Životní cyklus dokumentu
Uživatel
Registrace dokumentu
Záznam požadavek na registraci dokumentu
Schvalování dokumentu
Uživatel
požadavek na schválení či připomínkování
dokumentu
Uživatel Archivace dokumenut
požadavek na
archivaci dokumentu
7. Závěr
7.1 Výhody použití systému
Efektivita
• možnost zpracování a spojení dokumentů do jednotného formátu na různých útvarech firmy
• jednoznačně definované kompetence při tvorbě dokumentů
• nezaměnitelnost jednotlivých verzí dokumentů
• usnadnění práce s dokumenty
• rychlé vyhledávání
• přizpůsobení klientů aplikace na míru konkrétnímu uživateli
Bezpečnost
• centralizace důležitých dat na lokálním serveru
• možnost přístupu pouze autorizovaným osobám
• zajištění bezpečnosti dat
• elektronická archivace
• sdílení dokumentů mezi odděleními a lokalitami
• monitorování
7.2 Možné problémy s nasazením systému
Je potřeba si uvědomit, že nasazení takového systému není samospasitelné a samo o sobě nevyřeší případné problémy ve správě dokumentů. Jako každý informační systém, v případě, že organizace má špatně nastavené vnitřní
ještě více prohloubit. Proto je potřeba před nasazením systému správně popsat probíhající procesy a případně je správně nastavit
7.3 Realizace systému
Navrhovaný systém byl analyzován pro potřeby společnosti STUARE Post s.r.o., ve které jsem v době psaní diplomové práce zaměstnán. V současné době probíhá realizace systému a jeho postupné nasazování do provozu u jednotlivých zákazníků. Díky tomu jsou na systém kladeny další a další specifické požadavky, které následně rozšiřují funkčnost. Z ohlasů zákazníků je znát, že na trhu existuje poptávka po malém až středním řešení, které je nabízeno za rozumnou cenu, je jednoduché na ovládání a nabízí dostatečné funkce. Systém popsaný v této diplomové práci tyto požadavky splňuje a proto si své místo na trhu jistě najde.
8. Slovník
ADSI (Active Directory Service Interface) - objektová rozhraní pro službu Active Directory.
Active Directory - implementace LDAP firmou Microsoft, která se používá v prostředí systému Windows.
API (Application Programmer Interface) - specifikace rozhraní programového balíku, pomocí kterého lze tento balík používat.
CERT (Computer Emergency Response Team) - organizace, která se snaží zvýšit povědomí o problémech bezpečnosti na internetu.
Certifikační autorita - objekt, který vydává digitální certifikáty k použití ostatním zúčastněným stranám.
CR (Bar Code Reading) – technologie určená pro převod čárových kódů do podoby řetězců číslic.
CSV (Comma Separated Values) - standardizovaný soubor, který pro své formátování používá čárku pro oddělení hodnot a znak konce řádku pro oddělení řádku.
DBMS (Database Management System) - systém pro správu databáze.
Software, který umožňuje přístup k databázi. Řídí současný přístup a provádí příkazy dotazujícího se jazyka.
DFD (Data Flow Diagrams) – grafická reprezentace datových toků zkoumané oblasti.
Directory service – v kontextu JNDI síťová služba poskytující informace o jednotlivých síťových entitách.
DMS (Document management system) – systém pro správu dokumentů.
DOM (Document Object Model) - objektový model dokumentu. Softwarové rozhraní ke struktuře dokumentu s metodami, které dovolují manipulovat s elementy.
DPI (Dots Per Inch) - počet bodů na palec. Měřítko rozlišení obrázků nebo textů prezentovaných na obrazovce či na stránce. Čím vyšší je rozlišení, tím je vyšší kvalita.
DTD (Document type definition) - definice typu dokument. Dokument popisující pravidla pro konkrétní typ dokumentu.
ECM (Enterprise content management) – systém pro zpracování veškerého obsahu organizace.
Firewall - software či hardware chránící síť před neautorizovaným přístupem.
ICR (Intelligent Character Recognition) - inteligentní rozpoznávání znaků.
Jedná se o vylepšení OCR. ICR nepoužívá předem definované šablony a pro rozpoznávání analyzuje čáry a křivky.
JAX (Java API XML) - API pro XML implementované v jazyce Java.
JNDI (Java Naming and Directory Interface) - rozhraní pro přístup k Directory service a Naming service pro aplikace napsané v programovacím jazyku Java.
LDAP (Lightweight Directory Access Protocol) - protokol určený pro správu adresářů a pro práci s informacemi o uživatelích.
Naming service – v kontextu JNDI služba přiřazující jména objektům a umožnující vyhledávat objekty na základě jejich jmen.
OCR (Optical Character Recognition) - optické rozpoznávání znaků.
Automatické rozpoznávání znaků založené na porovnání vůči předem definované šabloně.
OMR (Optical Mark Recognition) - technologie pro rozpoznávání zaškrtávacích značek na dokumentech, zejména dotaznících.
RFC (Request For Comments) - návrh standardu souvisejícího s Internetem.
SOAP (Simple Object Access Protocol) – protokol pro výměnu zpráv. Protokol je založený na formátu XML. Jedná se o základní vrstvu webových služeb.
Spisová služba - informační systém sloužící ke sledovaní celého oběhu dokumentů organizací.
UDDI (Universal Description, Discovery and Integration) - mechanismus pro registraci a vyhledávání webových služeb.
URL (Uniform Resource Locator) – řetězec určený ke specifikaci umístění zdrojů informací určitým protokolem.
URN (Uniform Resource Name) – definuje zdroj nezávisle na umístění.
W3C (World Wide Web Consorcium) - konsorcium firem, které pomáhá definovat standardy na Internetu.
WSDL (Web Services Description Language) – popisuje možnosti webové služby a způsob, jakým službu používat. Formát je v jazyce XML.
XML (eXtensible Markup Language) – metajazyk, který slouží k vytváření dalších jazyků. Jedná se hlavně o jazyk pro výměnu dat mezi aplikacemi. Na jeho vývoj dohlíží konsorcium W3C.
XSD (XML Schema Definition) - XML schéma, popisující strukturu XML dokumentu.
9. Literatura
[1] Fleissig, Stanislav DMS: systémy pro správu a oběh dokumentů.
Dostupné z WWW: < http://casopis.systemonline.cz/41-dms- systemy-pro-spravu-a-obeh-dokumentu.htm>.
[2] Kopecký Kamil, Nocar David, Kopecký Roman. OCR technologie v pedagogických disciplínách. Dostupné z WWW:
<http://epedagog.upol.cz/eped3.2003/clanek03.htm>.
[3] Moualla, Hana. Obecná analýza požadavků pro výběr dokumentového skeneru a archivačního softwaru pro firemní dokumentový systém.
Ikaros. 2006, roč. 10, č. 8 [cit. 2007-04-14]. Dostupné z WWW:
<http://www.ikaros.cz/node/3551>. URN-NBN:cz-ik3551. ISSN 1212-5075.
[4] Zákon 227/2000 Sb., o elektronickém podpisu a o změně některých dalších zákonů. 30. června 200. Dostupné z
WWW:<http://www.micr.cz/images/dokumenty/UZ_z_227- 2000_Sb_03__3_.htm>
[5] Zákon 256/1992 Sb., o ochraně osobních údajů v informačních systémech. 29. dubna 1992. Dostupné z
WWW:<http://www.lexdata.cz/web/lexdata.nsf/frameset?openpage
&sb=C12571D20046A0B2C12566D40073D767>
[6] Zákon 499/2004 Sb., o archivnictví a spisové službě a o změně některých zákonů. 30. června 2004. Dostupné z
WWW:<http://www.cesarch.cz/legislat/2004-499.htm>
[7] Vyhláška 117/1974 Sb, kterou se stanoví kritéria pro posuzování písemností jako archiválií a podrobnosti skartačního řízení. 27.
listopadu 1974. Dostupné z WWW:<
http://www.cesarch.cz/legislat/117_74.htm>
[8] Vyhláška 118/1974 Sb, o podnikových archívech. 27. listopadu 1974.
Dostupné z WWW:< http://www.cesarch.cz/legislat/118_74.htm>
[9] Vyhláška 645/2004 Sb., kterou se provádějí některá ustanovení zákona o archivnictví a spisové službě a o změně některých zákonů. 13.
prosince 2004. Dostupné z WWW:<
http://www.cesarch.cz/legislat/2004-645.htm>
[10] Vyhláška 646/2004 Sb., o podrobnostech výkonu spisové služby.
13. prosince 2004. Dostupné z
WWW:<http://www.cesarch.cz/legislat/2004-646.htm>
[11] SOAP Version 1.2. 24. června 2003. Dostupné z WWW:
<http://www.w3.org/TR/soap12-part1>
[12] Web Services Description Language (WSDL) 1.1. 15. březen 2001. Dostupné z WWW: <http://www.w3.org/TR/wsdl>
[13] Webové služby. <http://www.webservices.org/>
[14] Java technology and Web Services.
<http://java.sun.com/webservices/index.jsp>
[15] Digitalizace dat.
<http://medard.soc.cas.cz/digidat/index.htm>.
[16] Virtual ReScan.
<http://www.ness.com/CZ/Solutions+and+Services/VRS.htm>
[17] CERT. <http://cert.org>
[18] Yoursystem. <http://www.yoursystem.cz>
[20] FileNet. <http://www.autocont.cz>
[21] EFiles. <www.sw4people.cz/document-management- system.html>
