Informační systém pro správu dokumentů. Simona Hejná

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Bakalářská práce Informační systém pro správu dokumentů Simona Hejná Vedoucí práce: Ing. Božena Mannová, Ph.D. Studijní program: Softwarové technologie a management, Bakalářský Obor: Softwarové inženýrství 7. ledna 2010

2 iv

3 v Poděkování Ráda bych poděkovala Ing. Boženě Mannové, Ph.D za odborné vedení této bakalářské práce. Dále bych ráda poděkovala své rodině, za podporu po dobu studia.

4 vi

5 vii Prohlášení Prohlašuji, že jsem práci vypracovala samostatně a použila jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne

6 viii

7 Abstract This thesis deals with a problem of document registration and processing for small-sized enterprises. The objective is to analyze life-cycle of a document in a company from its evidence and processing to the archivation; suggest a working solution for its electronic treatment and finally realize the solution in a user-friendly application. Resulting application is installed and tested as a trial in a Retirement Home Prague 8 where it replaces paper form records. Now the application keeps record of all received, sent and internal correspondence. Abstrakt Bakalářská práce se zabývá problematikou evidence a zpracování písemností menších organizací. Cílem práce je provést analýzu postupu zpracování dokumentů od jejich zaevidování, přes zpracování až po archivaci, navrhnout jednoduché a zároveň dostačující řešení pro jejich elektronické zpracování a tento návrh realizovat vytvořením uživatelsky přístupné aplikace. Výsledný program je zkušebně nainstalován a otestován v Domově pro seniory na Praze 8, kde doposud vedli pouze papírovou evidenci. Nyní se v aplikaci eviduje veškerá příchozí, odchozí ale i interní korespondence. ix

8 x

9 Obsah 1 Úvod 1 2 Popis problému, specifikace cíle Specifikace cílů Požadavky na systém Funkčnost Výkon Spolehlivost systému Podporovatelnost Existující implementace Analýza a návrh řešení Úvod Analýza zpracování dokumentů Návrh řešení Návrh architektury Návrh databáze Funkcionalita Realizace Úvod Použité nástroje Popis aplikace Popis tříd implementovaných v aplikaci Nasazení do provozu Testování Unit testy Akceptační testy Zkušební provoz Závěr 39 Literatura 41 A Seznam použitých zkratek 43 xi

10 xii OBSAH B Instalační a uživatelská příručka 45 B.1 Instalační příručka B.2 Uživatelská příručka C Obsah přiloženého CD 51

11 Seznam obrázků 3.1 Use case diagram: Zpracování dokumentu Architektura klient-server Datový model Základní obrazovka aplikace DMSys Přihlášení do aplikace Sestava: Podací deník Menu: Změna stavu dokumentu Menu: Nový dokument Profil dokumentu: záložka Profil Profil dokumentu: záložka Adresa Profil dokumentu: záložka Soubor Profil spisu Vyhledávací formulář Nastavení organizačních jednotek xiii

12 xiv SEZNAM OBRÁZKŮ

13 Seznam tabulek 5.1 Akceptační test: Přihlášení uživatele do aplikace Akceptační test: Zobrazení seznamu dokumentů výběrem z navigačního stromu Akceptační test: Zobrazení seznamu spisů výběrem z navigačního stromu Akceptační test: Založení nového dokumentu bez spisu Akceptační test: Založení nového dokumentu s vytvořením nového spisu Akceptační test: Založení nového dokumentu s výběrem spisu ze seznamu existujících spisů Akceptační test: Vyhledávání pomocí panelu rychlého vyhledávání Akceptační test: Vyhledávání podle více kritérií současně Akceptační test: Zadání nového uživatele Akceptační test: Oprava údajů u existujícího uživatele Akceptační test: Založení nové organizační jednotky Akceptační test: Úprava organizační jednotky Akceptační test: Tisk podacího deníku Akceptační test: Ukončení aplikace xv

14 xvi SEZNAM TABULEK

15 Kapitola 1 Úvod Ve své bakalářské práci se věnuji návrhu, realizaci a implementaci informačního systému pro správu dokumentů. Každá firma i organizace má množství dokumentů, které by měly být evidovány. Dříve se veškeré dokumenty evidovaly pouze v papírové podobě. Používaly se podací deníky. Jednalo se v podstatě o knihu, do které se každý doručený dokument zapsal, přidělilo se mu pořadové číslo a pod tímto číslem byl nadále dohledatelný například v archivu. To samé platilo také pro dokumenty, které u původce vznikaly a posléze byly vypravovány poštou. Tento systém ale není ideální, životní cyklus každého dokumentu prochází mnoha stádii, od zaevidování, po předání ke zpracování, vyřízení až po předání do archivu. Po celou tuto dobu se dokument pohybuje mezi různými pracovníky a jeho dohledatelnost je velice náročná. Elektronická evidence zajistí kompletní přehled o všech dokumentech organizace. Kdykoliv lze zjistit v jakém stavu se dokument právě nachází a kdo je zodpovědný za její zpracování. Vyhledávání dokumentů v elektronické evidenci je rychlé a přesné. Systém umožňuje také vytvářet různé statistiky ohledně počtu doručených a vypravených dokumentů jak za celou organizaci, tak i za jednotlivá oddělení popřípadě pracovníky. Umožňuje také vedoucím pracovníkům kontrolovat činnost svých podřízených. Rozhodla jsem se navrhnout a vytvořit vlastní aplikaci pro správu dokumentů. Existuje sice již řada komerčních systémů, které tuto problematiku řeší, ale většinou se jedná o finančně i technicky velmi náročné systémy. Proto tyto systémy nejsou přístupné řadě menších organizací a firem, které stále svou evidenci dokumentů vedou pouze v papírové podobě. Navržený systém bude využívat open source technologie, čímž se zajistí nižší náklady na vývoj, ale i nižší náklady na instalaci a provoz systému. 1

16 2 KAPITOLA 1. ÚVOD

17 Kapitola 2 Popis problému, specifikace cíle 2.1 Specifikace cílů Cílem této bakalářské práce je analyzovat postup zpracování písemností. Vytvořit aplikaci, která zajistí odbornou správu dokumentů došlých i vzešlých z činnosti menší organizace, zahrnující jejich řádný příjem, evidenci, rozdělování, oběh, vyřizování, vyhotovování, odesílání, ukládání a vyřazování, a to včetně kontroly těchto činností nadřízeným pracovníkem. Tyto požadavky vyplývají ze zákona o archivnictví a spisové službě [5]. Najít vhodné implementační prostředí a navržený a vytvořený systém zde naimplementovat a otestovat ve zkušebním provozu. Zvolit vývojové i implementační technologie tak, aby náklady na vývoj i samotné nasazení aplikace do provozu byly co nejnižší. Aplikaci navrhnout a vytvořit tak, aby její správu byl schopen zajistit proškolený pracovník. 2.2 Požadavky na systém Funkčnost Elektronická evidence písemností doručených, vypravených i interních. Možnost zakládání písemností s vyplněním základních údajů o dokumentu. Možnost připojení libovolné přílohy v podobě elektronického dokumentu. Možnost editace a rušení písemností. Řízení oběhu zpracování písemností - možnost předávat písemnosti ke zpracování jiným pracovníkům. Řízení stavů jednotlivých písemností - od zaevidování, přes zpracování až po uzavření. 3

18 4 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE Možnost logického řazení písemností do spisů. Přehled všech rozpracovaných písemností každého pracovníka. Řízení přístupu k jednotlivým písemnostem na základě práv. Snadné vyhledání písemností podle různých kritérií. Tiskové výstupy pro jednotlivé pracovníky, popřípadě vedoucí jednotlivých organizačních jednotek. Tisk podacího deníku. Možnost kontroly práce jednotlivých pracovníků. Vedoucí pracovníci by měli mít právo vidět práci svých podřízených. Možnost uživatelského nastavení organizační struktury dané organizace nebo firmy. Možnost správy číselníku uživatelů. Založení uživatele, přidělení organizační jednotky, změna organizační jednotky, zrušení uživatele Výkon Možnost zpracovat až stovky dokumentů denně. Možnost současného provozu desítek uživatelů Spolehlivost systému V případě funkčnosti hardware by měla být aplikace plně funkční. Žádné kritické chyby, které by znemožňovaly použití systému Podporovatelnost Částečné zdokumentování systému ve vlastnictví zákazníka (administrátorská a uživatelská dokumentace). Programátorská dokumentace zůstává vlastnictvím autora. Prostředí běží na serverech zákazníka. Garance řešení chyb dodavatelem (servisní smlouva).

19 2.3. EXISTUJÍCÍ IMPLEMENTACE Existující implementace Ve své praxi jsem se setkala s několika různými systémy pro správu dokumentů. PowerDOC - systém pro správu dokumentů od firmy Exprit. Tento systém byl velice náročný na implementaci i samotný provoz. Nasazení systému vyžadovalo nákup aplikačního a databázového serveru, dále nákup licencí PCDocs pro všechny uživatele systému. Musela se též provést instalace PCDOCS a aplikace na všechny pracovní stanice. Implementace tohoto systému se pohybovala v řádech miliónů, maintenance pak další sta tisíce měsíčně. e-spis - systém pro správu dokumentů od firmy ICZ. Tento systém již využívá třívrstvou architekturu. Nasazení aplikace vyžadovalo nákup aplikačního a databázového serveru. Pro spuštění aplikace není nutná instalace na jednotlivé stanice, čímž se výrazně snížila náročnost implementace a běžného provozu. Cena implementace se také pohybovala v řádech miliónů. GINIS - modul Spisová služba - modul SSL je jedním z modulů komplexního řešení informačního systému organizací. Také se jedná o jednu z větších spisových služeb, které lze na našem trhu pořídit. Na internetu jsem nalezla řadu dalších aplikací pro správu dokumentů i v přístupné cenové relaci. Například: infotex - jedná se o internetovou aplikaci za velmi příznivou cenu bez nutnosti dokupování dalších licencí a také bez nutnosti instalace. Nejlevnější varianta pro 5 uživatelů stojí dokonce necelé 2 tisíce korun ročně. K používání tohoto systému není nutné pořizovat si vlastní databázový server. Dokumenty jsou ukládány v datovém uložišti dodavatele systému. Nevýhodou tohoto systému je, že kapacita diskového prostoru pro ukládání dokumentů je velmi omezená.

20 6 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE

21 Kapitola 3 Analýza a návrh řešení 3.1 Úvod V této části bude provedena podrobná analýza problematiky zpracování dokumentů. Bude upřesněna požadovaná funkčnost budoucí aplikace. Dále bude navrženo řešení informačního systému. 3.2 Analýza zpracování dokumentů Je potřeba evidovat dokumenty doručené, vypravované i interní. Životní cyklus těchto dokumentů je velmi podobný. Prochází zaevidováním doručeného dokumentu do systému, poté přidělením ke zpracování konkrétnímu pracovníkovi, zpracování - například vytvoření odpovědi - vlastního dokumentu, vložení dokumentu do spisu. Zpracovávaný dokument je někdy potřeba předat ke zpracování jinému pracovníkovi, popřípadě vedoucímu ke kontrole. Připravený dokument je možno vypravit a poté uzavřít. Celého procesu zpracování dokumentu se může účastnit více pracovníků. Evidenci doručených dokumentů je možno provádět centrálně na podatelně nebo je možnost, aby si doručené dokumenty evidovali jednotliví pracovníci sami. Záleží pouze na organizaci práce v dané firmě. U zpracování dokumentů je důležité nastavení přístupových práv k jednotlivým dokumentům. Není možné, aby pracovníci rozdílných organizačních jednotek viděli navzájem své dokumenty, pokud jim k tomu zpracovatel písemnosti sám nedá právo. Proto by přístup k dokumentům měl být nastaven tak, aby každý pracovník viděl pouze dokumenty, které sám zpracoval, popřípadě, které mu byly přiděleny ke zpracování někým jiným. Je zde ale nutno zachovat možnost kontroly pracovníků jejich přímými vedoucími. Proto vedoucí organizační jednotky by měl mít možnost vidět práci všech svých podřízených. Model jednání - pro představu jednotlivých funkčností aplikace a aktérů, kteří budou tyto funkčnosti vykonávat, slouží přiložený model jednání (Obrázek 3.1) [1]. 7

22 8 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Obrázek 3.1: Use case diagram: Zpracování dokumentu

23 3.3. NÁVRH ŘEŠENÍ Návrh řešení Návrh architektury Architektura informačního systému bude postavena na dvojvrstvé síťové architektuře klientserver (Obrázek 3.2). Oddělí se tak klientská část s grafickým uživatelským rozhraním od serverové části, s níž klienti komunikují pomocí počítačové sítě. Na klientských stanicích bude nainstalovaná uživatelská část programu, která bude vytvořena pro uživatele v přijatelném grafickém rozhraní. Na serveru bude instalována databáze. Každá stanice může posílat požadavky na data k databázovému serveru, ten požadavek vyhodnotí a zašle zpět požadované informace. Klient je aktivní zasílá požadavky na server zpracovává odpovědi ze serveru komunikuje s koncovými uživateli pomocí GUI Server je pasivní čeká na požadavky vyřizuje požadavky a odesílá zpět klientům požadované informace Obrázek 3.2: Architektura klient-server

24 10 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Výhody architektury klient-server Úkoly a zodpovědnost systému je rozdělena na více počítačů. Komunikace mezi těmito počítači (server a klientské stanice) probíhá pomocí počítačové sítě. V případě nutnosti přesunu, popřípadě výměny serveru, klientů se tato činnost vůbec nedotkne. Tím pádem je snadnější údržba této sítě. Všechna data jsou uložena na serveru. Správu dat a operace s databázemi provádí pouze databázový server. Běžný uživatel tudíž nemá možnost přistupovat přímo k databázi. U systémů s architekturou klient-server je zachována vysoká ochrana dat. V případě napadení klientského počítače virem, to nepředstavuje přímé ohrožení pro databázi uloženou na serveru. Porucha hardwaru na klientské stanici nemůže způsobit ztrátu dat. Na serveru je nutné snížit riziko ztráty dat výkonným hardwarem, připojením záložního zdroje a spolehlivě nastaveným systémem zálohování. U architektury klient-server klientská část posílá na server pouze požadavky a server posílá klientovi zpět výsledky jeho dotazu. Mezi klientem a serverem tedy putují pouze ta data, která klient právě potřebuje. Tímto je zajištěno mnohem nižší zatížení sítě oproti souborovým aplikacím a také rychlejší zpracování požadavků Návrh databáze Pro ukládání dat jsem zvolila relační databázový systém PostgreSQL. Tento databázový systém je možné použít na většině dostupných operačních systémů včetně Windows a Linux. Splňuje podmínky ACID (atomicita, konzistence, izolace, trvanlivost), podporuje cizí klíče. Zároveň se jedná o systém, který se dá pořídit zcela zdarma, neboť je šířen pod BSD licencí, která umožňuje neomezené bezplatné používání pro komerční i nekomerční využití. Databáze bude obsahovat 6 tabulek Dokumenty - tato tabulka bude sloužit pro ukládání informací všech typů dokumentů (doručené, vypravené, interní). Do této tabulky budou ukládány také elektronické přílohy, pokud budou u dokumentů zaevidovány. Spisy - tato tabulka bude sloužit pro ukládání informací o evidovaných spisech. Tabulka Spisy bude propojena s tabulkou Dokumenty. Bude tedy možno dohledat informace o všech dokumentech ve spisu. Oj - tato tabulka bude sloužit jako číselník organizačních jednotek. Jedná se o organizační strukturu firmy, popřípadě organizace. Adresy - tabulka adresy bude sloužit jako číselník subjektů. Subjekty jsou zde míněni odesílatelé u doručených dokumentů a adresáti u vypravených dokumentů. Stavy - číselník stavů dokumentů. Každý dokument prochází v průběhu zpracování několika různými stavy od zaevidování, zpracování až po uzavření. Uzivatele - tato tabulka bude sloužit jako číselník uživatelů systému. Údaje z tabulky uživatelů se budou využívat jak v tabulkách Dokumenty, Spisy, tak i v tabulce organizačních jednotek. Přehled jednotlivých tabulek, jejich položek a vazeb mezi jednotlivými tabulkami nejlépe zobrazuje připojený Datový model (Obrázek 3.3).

25 3.3. NÁVRH ŘEŠENÍ 11 Obrázek 3.3: Datový model Funkcionalita Přihlašování k aplikaci databázi. pomocí uživatelského jména a hesla, které bude ověřováno oproti Nastavení přístupových práv k jednotlivým dokumentům a spisům bude definováno podle práv přihlášeného uživatele. Každý uživatel systému může vidět pouze ty dokumenty a spisy, které sám zpracovává, popřípadě mu byly ke zpracování přiděleny a tudíž se stal jejich držitelem. Vedoucí pracovníci budou mít nastaveno právo vidět všechny dokumenty své organizační jednotky. Správa číselníku organizace Tato funkčnost bude potřeba již na začátku, při samotné konfiguraci systému. Tato část programu musí obsahovat možnost naplnění jména organizace, popřípadě firmy. Dále musí mít možnost zadání jednotlivých organizačních jednotek. V průběhu funkčnosti aplikace může dojít ke změnám ve členění organizace, proto je nutné, aby v číselníku organizace bylo možno přidávat jednotky i po spuštění systému, dále aby bylo možno upravovat již existující jednotky a také aby bylo možné deaktivovat jednotky, které již byly zrušeny. Správa číselníku uživatelů Bude sloužit k naplnění a udržování seznamu pracovníků, kteří budou informační systém využívat. Je nutné, aby aplikace umožnila zadávat nového uživatele. U každého uživatele je možnost evidovat základní údaje jako je jméno, příjmení,

26 12 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ titul, ale také informaci o organizační jednotce, v které bude pracovat. Dále je zde možnost vyplnit roli, jakou bude daný pracovník zastávat. Rolí se myslí funkce, například referent, vedoucí, sekretariát, popřípadě administrátor. Uživatele z databáze nebude možné odstranit, neboť v případě práce se systémem bude uveden jako autor či zpracovatel u již vzniklých dokumentů. Proto uživateli po skončení pracovního poměru bude nastaven pouze příznak zrušení. Jelikož se předpokládá, že při větším počtu uživatelů by práce s číselníkem byla brzy nepřehledná, je nutné v této části vytvořit také vyhledávání uživatele podle zadaných kritérií. Vyhledávacími kritérii může být příjmení, jméno, přihlašovací jméno a role. Založení nového dokumentu Možnost zaevidování tří různých druhů dokumentů - doručených, vypravených a interních. Při zakládání nového dokumentu je nutno evidovat základní údaje daného dokumentu. Věc - krátký popis čeho se dokument týká Číslo dokumentu - toto číslo bude automaticky vygenerováno po uložení dokumentu do databáze. Toto číslo je jednoznačné v celé databázi. Autor a Držitel - při založení dokumentu budou oba tyto údaje nastaveny podle osoby, která je v systému přihlášena. Datum založení - bude automaticky generováno v okamžiku uložení dokumentu do databáze. Spis - každý dokument může, ale také nemusí být vložen do spisu. V případě, že spis ještě nebude existovat, bude možné založit nový spis k tomuto dokumentu. V případě, že chceme dokument vložit do již existujícího spisu, musí aplikace umožnit spis dohledat v databázi spisů a převzít číslo spisu do profilu dokumentu. Adresa - v případě doručených dokumentů je nutno evidovat adresu subjektu, který dokument zaslal. V případě vypravených dokumentů je zase nutné evidovat adresu subjektu, kterému je dokument odesílán. V profilu dokumentu tedy bude muset být možnost uložit informace o subjektu a jeho adrese. Informace o subjektu budou ukládány do samostatné tabulky Adresa. Elektronický dokument - ke každému profilu dokumentu, který vložíme do databáze by měla být možnost připojit elektronickou přílohu. Požadavek je, aby přikládaný soubor mohl být libovolný a neomezoval uživatele ve výběru aplikací k vytváření elektronických příloh. Úprava dokumentu Již zaevidovaný dokument je někdy nutné upravit, proto je nutno, aby aplikace umožnila otevřít profil dokumentu, provést tam změny a tyto změny opět uložit do databáze. Zrušení dokumentu Někdy je nutné zrušit dokument, který byl do systému zadán, ale později bylo zjištěno, že není potřeba evidovat.

27 3.3. NÁVRH ŘEŠENÍ 13 Založení nového spisu Spis bude možno založit pouze z profilu vybraného dokumentu. Tím se zamezí možnosti vzniku prázdných spisů. V případě, že už spis existuje, je nutno umožnit vkládání dalších dokumentů do tohoto spisu. Každý spis může obsahovat jeden nebo více dokumentů. Bude možné zobrazit obsah spisu. Vyhledávání Jednou z nejdůležitějších činností každé aplikace je možnost vyhledávání dat podle zadaných kritérií. V této aplikaci chci klást důraz na možnost vyhledávání podle většiny zadaných údajů. Vyhledávání dokumentů, spisů i subjektů. Tisk podacího deníku Možnost tisku seznamu dokumentů zaevidovaných za organizační jednotku, které byly evidovány ve zvolený datum. Tisk seznamu Možnost tisku seznamu dokumentů, které budou vybrány podle filtračních podmínek zadaných uživatelem. Předávání dokumentů V průběhu zpracování dokumentu je někdy nutno tento dokument předat ke zpracování jinému pracovníkovi. Proto je nutné zajistit možnost změny držitele dokumentu. Změna stavu dokumentů Je nutné evidovat stav dokumentu, v kterém se právě nachází. Dokument může být ve stavu zpracování, vyřízení, uzavření, zrušení. Aplikace musí uživateli umožnit provést změnu stavu dokumentu. Změna stavu spisů Možnost uzavírání spisů - převod spisu do stavu uzavřeno. Seznam dokumentů podle stavu Možnost zobrazit seznam dokumentů za každý stav zvlášť. Umožní snadnější přehled ještě nezpracovaných dokumentů.

28 14 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ

29 Kapitola 4 Realizace 4.1 Úvod Úkolem této části práce je vytvořit funkční aplikaci, která bude sloužit jako informační systém pro správu dokumentů a zároveň bude odpovídat požadavkům specifikovaných v zadávací studii. 4.2 Použité nástroje Programovací jazyk: Java [2] [3] Vývojové prostředí: NetBeans IDE 6.5 Nástroj pro vytváření šablon sestav: ireport Reportovací nástroj k vytváření dokumentů ve formátu PDF: JasperReports Databázový server: relační databázový systém PostgreSQL 8.3. Síťová architektura: klient-server Vývoj aplikace probíhal na platformě Windows Vista 4.3 Popis aplikace Aplikace je vytvořena v grafickém uživatelském rozhraní (GUI), které umožňuje snadné ovládání pomocí grafických prvků. Aplikace je navržena tak, aby byla pro uživatele přehledná a snadno ovladatelná. K vytváření uživatelského rozhraní bylo použito grafické vývojové prostředí NetBeans, které nabízí snadný návrh formulářů i s velkým množstvím ovládacích prvků a zároveň automaticky generuje zdrojový kód. Ke spuštění aplikace DMSys je nutné se přihlásit uživatelským jménem a heslem. Tím je zajištěna ochrana přístupu k datům. Přihlášený uživatel si může zobrazit pouze ty dokumenty, u kterých je uveden jako autor, popřípadě jako držitel písemnosti. 15

30 16 KAPITOLA 4. REALIZACE Veškeré údaje, které se v aplikaci evidují, jsou uloženy v databázi. Ukládají se nejen údaje o dokumentech (tzv. metadata), ale i samotné elektronické dokumenty. V úvodu bylo zvažováno, jakým způsobem ukládat elektronické přílohy k metadatům jednotlivých dokumentů. Elektronickou přílohou může být nejen textový dokument, ale i obrázek, tabulka, prakticky lze připojit libovolný soubor. V případě volby ukládání dokumentů do souborového systému, by nastal problém se zabezpečením přístupu k těmto souborům. Proto byla zvolena druhá možnost, a to ukládat elektronické dokumenty přímo do tabulky databáze. Tyto elektronické přílohy, které jsou uloženy v databázi, lze také znovu otevřít. Skripty, pro vytvoření databáze a jednotlivých tabulek, jsou součástí přiloženého CD. Aplikace je navržena tak, aby splňovala všechny požadavky na funkčnost systému popsané v odstavci Funkcionalita v kapitole 3.3 Návrh řešení. Umožňuje snadnou správu číselníku uživatelů a organizačních jednotek. Nabízí možnost zadávání nových dokumentů a spisů a zároveň umožňuje snadný přehled rozpracovaných dokumentů. Nabízí také vyhledávání dokumentů podle libovolného kritéria a tisk základních sestav. Pro vytváření výstupních sestav byl zvolen reportovací nástroj JasperReports. Tento nástroj umožňuje tvorbu dynamických PDF souborů na základě xml šablony vytvořené v nástroji ireport a dat získaných z databáze. Pro snadnější představu o vytvořené aplikaci přikládám popis tříd dané aplikace: Popis tříd implementovaných v aplikaci DMSApp.java Application. Jedná se o hlavní třídu aplikace, která je zděděná ze třídy SingleFrame- DMSView.java Tato třída je jádrem celé aplikace. Je zde definován její grafický vzhled a základní funkčnost. Základní obrazovka je rozdělena na několik částí, v horní části se nachází menu pro práci s dokumenty. V prostřední části se nachází hlavní panel, který obsahuje v záhlaví panel pro rychlé vyhledávání. Existuje zde možnost vyhledávat podle čísla dokumentu, čísla spisu, věci a osoby. Tento panel rychlého vyhledávání je umístěn přehledně v záhlaví celé aplikace pro snadné použití, nenahrazuje ale plně funkčnost vyhledávání, která je definována níže ve třídě FormHledani a umožňuje vyhledávat podle všech zadaných údajů. V pravé části záhlaví se zobrazuje jméno přihlášeného uživatele V levé části je umístěn navigační strom, který umožňuje výběr přednastavených filtrů pro zobrazení dokumentů, spisů, číselníků. Dále umožňuje přechod na vyhledávací formulář a možnost tisku sestav. V pravé, největší části obrazovky je umístěno okno, které je po spuštění aplikace prázdné, ale při výběru libovolné nabídky z menu, popřípadě z navigačního stromu se v této části zobrazí tabulka s vybranými údaji nebo formulář pro zadání nových údajů. Ve spodní části obrazovky je umístěn status panel (Obrázek 4.1). Tato třída obsahuje tyto metody: DMSView - hlavní metoda třídy, která zobrazí požadované komponenty

31 4.3. POPIS APLIKACE 17 Obrázek 4.1: Základní obrazovka aplikace DMSys vytvoroknousers - metoda, která v pravé části obrazovky otevře nové okno s tabulkou uživatelů systému volané metodou ListUsers. vytvoroknodocs - metoda, která v pravé části obrazovky otevře nové okno s tabulkou dokumentů, volané metodou ListDocs. vytvoroknosp - metoda, která otevře nové okno FormSpisu se seznamem spisů. formdoc - metoda, která volá otevření nového okna s formulářem pro zadání nového dokumentu pomocí třídy FormUser. vytvoroknologin - metoda, která vytvoří logovací okno pro přihlášení do aplikace. hledani - metoda, která otevře okno s vyhledávacím formulářem. addmenu - metoda, která zviditelní menu v horní části aplikace. Toto menu je po spuštění aplikace neaktivní. Aktivuje se v případě úspěšného přihlášení uživatele do aplikace. newwindoc - metoda, která otevře nové okno s formulářem pro zadání nového dokumentu. najdidok - metoda, která získá vyhledávací kritérium z pole pro rychlé vyhledávání a poté vyhledá požadovanou informaci z databáze a zobrazí ji.

32 18 KAPITOLA 4. REALIZACE DBConnection.java Tato třída slouží k navázání a ukončení spojení s databází Postgre- SQL. Obsahuje dvě metody getconnection - pro navázání spojení s databází closeconnection - pro ukončení spojení s databází Login.java Tato třída slouží pro zobrazení úvodního přihlašovacího okna a ověření přihlášeného uživatele. Obsahuje pouze jednu metodu controllogin - slouží ke kontrole zadaných přihlašovacích údajů oproti údajům o uživatelích v databázi. V případě chybně zadaných údajů systém vyzve k opětovnému zadání jména a hesla. V případě, že uživatel 3x zadá nesprávné přihlašovací údaje, aplikace se ukončí. V případě úspěšného přihlášení se nastaví základní proměnné aplikace - jmeno, jmeno id a heslo pro přihlášeného uživatele. Tyto údaje jsou nadále využívány v dalším chodu aplikace k nastavení přístupu k datům. Obrázek 4.2: Přihlášení do aplikace FormMenu.java Tato třída slouží jako pomocné okno s nabídkou menu, které obsahuje řadu metod společných pro další podokna, která se v tomto okně otevírají. newdd - tato metoda nastaví parametr Typ zakládajícího dokumentu na hodnotu 2, což odpovídá doručenému dokumentu a dále zavolá metodu newwindoc, která otevře formulář pro zadání vstupních hodnot nového doručeného dokumentu. newvd - tato metoda nastaví parametr Typ na hodnotu 1, což odpovídá vlastnímu dokumentu a zavolá metodu newwindoc, která otevře formulář pro zadání vstupních hodnot nového vlastního dokumentu. newid - tato metoda nastaví parametr Typ na hodnotu 3, což odpovídá internímu dokumentu a zavolá metodu newwindoc, která otevře formulář pro zadání vstupních hodnot nového interního dokumentu.

33 4.3. POPIS APLIKACE 19 stavvyridit - nastaví hodnotu proměnné nastavstav = 2, což odpovídá stavu Vyřízeno a zavolá metodu zmenastavu. stavuzavrit - nastaví hodnotu proměnné nastavstav = 3, což odpovídá stavu Uzavřeno a zavolá metodu zmenastavu. stavzrusit - nastaví hodnotu proměnné nastavstav = 4, což odpovídá stavu Zrušeno a zavolá metodu zmenastavu. predani - tato metoda pouze otevře nové okno pro předání dokumentu. upravitdok - tato metoda otevře formulářové okno dokumentu do nějž načte hodnoty vybraného dokumentu. Zde je možno provést změny v libovolných položkách a pomocí tlačítka Uložit se upravené hodnoty uloží do databáze. konec - uzavře okno s menu. tiskdeniku - v této metodě je definovaný sql dotaz do databáze, který navrátí resultset obsahující požadované informace o dokumentech, které byly zaevidovány a zavolá se metoda jaspertisk. Obrázek 4.3: Sestava: Podací deník jaspertisk - zde se pomocí předem definované tiskové sestavy report2.jrxml vytvoří sestava do souboru ve formátu pdf a uloží se do pomocného adresáře Reporty. Poté se volá otevření tohoto souboru metodou open. open - je to metoda, které je na vstupu předán soubor, který má být otevřený a tato metoda ho otevře pomocí programu, který je v daném počítači asociován s tímto typem souboru.

34 20 KAPITOLA 4. REALIZACE zmenastavu - tato metoda nastaví sql příkaz pro update pomocí předem zadaných kritérií pro změnu stavu (hodnota proměnné nastavstav) a tento příkaz provede nad databází. Tím dojde k požadované změně stavu dokumentu. Obrázek 4.4: Menu: Změna stavu dokumentu newwindoc - zobrazí nové formulářové okno FormDoc pro zadání nového dokumentu. Obrázek 4.5: Menu: Nový dokument SeznamDok - tato metoda vytiskne seznam dokumentů, které jsou právě zobrazeny na obrazovce. FormDoc.java Tato třída slouží k vytvoření formulářového okna pro zadání nového dokumentu(obrázek 4.6). U každého dokumentu je možné zadat základní údaj jako je Věc, čeho se daný dokument týká, dále je zde automaticky nastaven Autor a Držitel písemnosti. Každý dokument je možno vložit do spisu pomocí tlačítka Výběr spisu, který nabídne všechny přístupné spisy, popřípadě k tomuto dokumentu založit spis nový tlačítkem Nový spis. Dále je možné doplnit adresu subjektu, kterému dopis zasíláme, popřípadě od koho jsme dopis obdrželi, v případě doručeného dokumentu(obrázek 4.7). Tato adresa se přidá do číselníku subjektů. Na poslední záložce je možné připojit libovolný elektronický dokument(obrázek 4.8). Po uložení základních údajů se na formuláři automaticky doplní datum založení dokumentu a číslo dokumentu, které je tvořeno předem definovanou číselnou řadou navýšenou o jedničku oproti poslednímu evidovanému dokumentu.

35 4.3. POPIS APLIKACE 21 Obrázek 4.6: Profil dokumentu: záložka Profil Tato třída obsahuje tyto metody: FormDoc - základní metoda třídy, která inicializuje komponenty formuláře a zobrazí tento formulář. Zároveň předvyplní textové pole Typ dokumentu podle globální proměnné Typ. storno - zavře okno bez uložení údajů. adddoc - spustí metodu readdataform, která přečte údaje z formulářových polí a poté spustí metodu addrow, která nový dokument uloží do databáze. saveadres - získá údaje o subjektu ze záložky Adresa a pomocí sql příkazu insert vloží informace o subjektu do databáze do tabulky adresy a zároveň do tabulky dokumenty k nově vytvořenému dokumentu připojí id subjektu. vyberspis - tato metoda slouží k výběru již existujícího spisu. Otevře nové okno Spisy, kde zobrazí existující spisy. V tomto okně lze spis také vyhledat. savefile - metoda, která umožní vložení elektronického dokumentu do databáze do tabulky dokumenty k nově vytvořenému dokumentu. openfile - metoda pro přípravu elektronického dokumentu z databáze k odeslání do metody open.

36 22 KAPITOLA 4. REALIZACE Obrázek 4.7: Profil dokumentu: záložka Adresa open - je to metoda, které je na vstupu předán soubor, který má být otevřený a tato metoda ho otevře pomocí programu, který je v daném počítači asociován s tímto typem souboru. choosefile - nastavení proměnných jmenosouboru a cestasouboru z vybraného souboru ve formuláři FileChooser. nastavspis - metoda která nastaví číslo vybraného spisu z okna Spisy do textového pole formuláře. newspis - vytvoří nový spis do databáze s číslem odpovídajícím nastavenému formátu a textem převzatým z pole Věc ve formuláři dokumentu. Zároveň předá číslo tohoto spisu do textového pole formuláře nového dokumentu. close - zavře okno bez uložení údajů. zobrazitsoubor - volá metodu openfile readdataform - přečte hodnoty z formuláře a uloží je do proměnných. addrow - založí nový dokument do databáze opravadok - získá opravené údaje z formuláře a opraví záznam v databázi.

37 4.3. POPIS APLIKACE 23 Obrázek 4.8: Profil dokumentu: záložka Soubor FormSpisu.java Tato třída slouží k vytvoření formuláře pro zobrazení spisů(obrázek 4.9). Obsahuje několik metod souvisejících s vyhledáním a načtením spisů do tabulky. FormSpisu - základní metoda třídy, která slouží k vykreslení formuláře. hledani - metoda, která slouží k vyhledání spisu podle zadaných vyhledávacích kritérií. Po nastavení sql dotazu je volána metoda setmodel, která vytvoří model a naplní tabulku daty. vybrat - vybere zvolený řádek a číslo vybraného spisu uloží do proměnné, která se předává třídě FormDoc a uzavírá okno formuláře FormSpisu. NaplnTabulkuSpisu - tato metoda připraví model pro naplnění tabulky spisů. FormUser.java Tato třída slouží k vytvoření formuláře pro zadání nového uživatele systému. Obsahuje pouze jedinou metodu: adduser - tato metoda načte údaje o novém uživateli z formulářových polí a vloží záznam o novém uživateli do databáze do tabulky uzivatele.

38 24 KAPITOLA 4. REALIZACE Obrázek 4.9: Profil spisu FormHledani.java Tato třída slouží k vytvoření formuláře pro vyhledávání dokumentů, spisů a subjektů(obrázek 4.10). Na základě kritérií zadaných ve formuláři umožňuje vyhledat a zobrazit dokumenty a spisy, které odpovídají zadaným požadavkům do tabulky. Třída obsahuje několik metod: FormHledani - základní metoda třídy, která zobrazí formulářové okno s jednotlivými komponentami. hledatspis - z formuláře získá vyhledávací kritéria a vytvoří sql příkaz pro výběr údajů z databáze, poté zavolá metodu NaplnTabulkuSpisu. hledatdok - z formuláře získá vyhledávací kritéria a vytvoří sql příkaz pro výběr údajů z databáze, poté zavolá metodu NastavModel, pro naplnění vyhledaných dokumentů do tabulky. hledatsubjekt - z formuláře získá vyhledávací kritéria pro vyhledání subjektu, vytvoří sql příkaz pro výběr údajů z databáze, poté zavolá metodu NastavModelAdr, pro naplnění vyhledaných subjektů do tabulky. NastavModel - volá metodu ModelDok, která vytvoří model a ten poté nastaví do tabulky dokumentů. NastavModelAdr - volá metodu ModelAdr, která vytvoří model a ten poté nastaví do tabulky subjektů. ModelDok - vytvoří model pro načtení do tabulky dokumentů a tento model předá jako výstupní parametr metody.

39 4.3. POPIS APLIKACE 25 Obrázek 4.10: Vyhledávací formulář ModelAdr - vytvoří model pro načtení do tabulky subjektů a tento model předá jako výstupní parametr metody. NaplnTabulkuSpisu - vytvoří model pro načtení do tabulky spisů a tento model nastaví do tabulky spisů. ListDocs.java Tato třída slouží k vytvoření seznamu dokumentů podle typu dokumentu a jeho stavu. Obsahuje metody: ListDocs - základní metoda třídy, která zobrazí seznam dokumentů do tabulky. ModelDok - připraví model pro načtení do tabulky dokumentů. ListOrgs.java Tato třída slouží k vytvoření formuláře pro zadávání organizační struktury organizace(obrázek 4.11). Umožňuje zadávat nové organizační jednotky, upravovat je a deaktivovat. Obsahuje metody: ListOrgs - základní metoda třídy, která zobrazí formulářové okno pro zadávání organizačních jednotek organizace. neaktivni - nastaví do stromu organizace pouze neaktivní organizační jednotky aktivni - nastaví do stromu organizace pouze aktivní organizační jednotky vse - nastaví do stromu organizace všechny organizační jednotky

40 26 KAPITOLA 4. REALIZACE Obrázek 4.11: Nastavení organizačních jednotek ojok - nastaví příkaz sql podle požadavku na změnu nebo na novou organizační jednotku ojstorno - zavře formulářové okno bez uložení změn addoj - přidá organizační jednotku zadanou do formulářových polí do databáze aktiv - nastaví parametr zrušení na hodnotu false TreeClick - při kliknutí na položku ve stromě se hodnoty dané organizační jednotky přenesou do formulářových polí k opravě. setmodeloj - vytvoří model všech aktivních organizačních jednotek a načte jej do organizačního stromu. setmodelojneaktivni - vytvoří model všech neaktivních organizačních jednotek a načte jej do organizačního stromu. setmodelojvse - vytvoří model všech organizačních jednotek a načte jej do organizačního stromu. setup - získá proměnné z textových polí. setvariables - nastaví proměnné.

41 4.4. NASAZENÍ DO PROVOZU 27 ListUsers.java Tato třída slouží k vytvoření seznamu dokumentů podle typu dokumentu a jeho stavu. Obsahuje metody: ListDocs - základní metoda třídy, která zobrazí seznam dokumentů do tabulky. ModelDok - připraví model pro načtení do tabulky dokumentů. RowAdr.java Pomocná třída pro vytvoření řádku subjektu, který se poté vkládá do zobrazované tabulky. Obsahuje metody SetSl a GetSl pro nastavení obsahu sloupců a získání obsahu sloupců. RowDoc.java Pomocná třída pro vytvoření řádku dokumentu, který se poté vkládá do zobrazované tabulky. Obsahuje metody SetSl a GetSl pro nastavení obsahu sloupců a získání obsahu sloupců. RowSpis.java Pomocná třída pro vytvoření řádku spisu, který se poté vkládá do zobrazované tabulky. Obsahuje metody SetSl a GetSl pro nastavení obsahu sloupců a získání obsahu sloupců. RowUser.java Pomocná třída pro vytvoření řádku uživatele, který se poté vkládá do zobrazované tabulky. Obsahuje metody SetSl a GetSl pro nastavení obsahu sloupců a získání obsahu sloupců. Predani.java Tato třída slouží pro zobrazení okna s možností předat dokument ke zpracování jiné osobě. Spisy.java Tato třída slouží stejně jako třída FormSpisu k vytvoření formuláře pro zobrazení spisů. Liší se pouze tím, že se nejedná o třídu zděděnou z třídy JInternalFrame, ale z třídy JFrame. 4.4 Nasazení do provozu Jako vhodné implementační prostředí byl zvolen Domov pro seniory na Praze 8. Důvodem ke zvolení této organizace bylo, že se jedná o menší organizaci, která doposud zpracovává veškerou korespondenci pouze v papírové podobě a nepoužívá žádný software k její evidenci. Její zaměstnanci byli vstřícní a přijali nabídku k instalaci a odzkoušení tohoto systému v běžném pracovním provozu. Byla provedena instalace databázového serveru PostgreSQL a pomocí předem vytvořených skriptů byla vytvořena databáze DMS i s jejími tabulkami. Poté se aplikace nainstalovala na všechny uživatelské stanice. Po instalaci systému byla spolu se správcem informačních systémů Domova pro seniory přednastavena organizační struktura a do číselníku byli naplněni všichni uživatelé, kteří systém budou používat. Tím proběhlo základní zaškolení administrátora systému, který měl

42 28 KAPITOLA 4. REALIZACE možnost si vyzkoušet základní správu systému. V současnosti je systém nastaven a v případě změn organizačních jednotek, případně uživatelů systému, by měl správce aplikace být schopen tyto změny provést samostatně. Aplikace byla nasazena do pilotního provozu v Domově seniorů na Praze 8 v listopadu roku Pilotní provoz probíhal po dobu jednoho měsíce, kde se ho účastnili vybraní klíčoví pracovníci. Po dobu pilotního provozu nedošlo k větším problémům s chodem aplikace. Pouze bylo nutné upravit původní konfiguraci organizační struktury, která při prvotním naplnění nebyla zadána přesně. Jednalo se o upřesnění názvů některých oddělení. Klíčovým pracovníkům byl rozdán manuál s popisem práce s aplikací, kde se mohli seznámit s detailním postupem při zpracování jednotlivých akcí. Na začátek pilotního provozu byla naplánována také podpora dodavatele u konečného uživatele. Tato podpora probíhala v průběhu dvou dnů, kdy si uživatelé postupně vyzkoušeli všechny části aplikace a poté již byli schopni sami začít aplikaci využívat v rutinním provozu. Po měsíci pilotního provozu byl předán seznam připomínek k samotné aplikaci. Nevyskytl se žádný problém, který by bránil v akceptaci projektu. Připomínky se týkaly drobné úpravy grafického rozhraní a také požadavku na novou funkčnost, kterou aplikace nenabízí. Jelikož se jedná o novou funkčnost, která nebyla zahrnuta do zadávací studie, projekt byl předán i bez těchto úprav. Předané připomínky ale byly věcné a proto budou zapracovány do aplikace v další verzi. Do ostrého provozu byla aplikace nasazena 4.ledna Bližší poznatky z ostrého provozu do data odevzdání této práce nebyly známy.

43 Kapitola 5 Testování 5.1 Unit testy Tyto testy byly prováděny v průběhu celého vývoje aplikace a byly prováděné programátorem. Při přidání každé nové funkčnosti aplikace bylo otestováno, zda tato část je plně funkční a splňuje požadavky zadané v zadávací studii. 5.2 Akceptační testy Tyto testy byly provedeny podle testovacích scénářů nejprve autorem aplikace, kde byly zjištěny ještě jisté nedostatky aplikace, které byly před nasazením aplikace do pilotního provozu u odběratele odstraněny. Potom byla aplikace nainstalovaná u zákazníka a byly provedeny akceptační testy s konečným uživatelem systému. Seznam a popis akceptačních testů je přiložen níže. 5.3 Zkušební provoz Aplikace byla nasazena do pilotního provozu v Domově seniorů na Praze 8 v listopadu roku Pilotní provoz probíhal po dobu jednoho měsíce. Po dobu pilotního provozu nedošlo k větším problémům s chodem aplikace. Pouze bylo nutné upravit původní konfiguraci organizační struktury, která při prvotním naplnění nebyla zadána přesně. Jednalo se o upřesnění názvů některých oddělení. V začátku pilotního provozu probíhala v průběhu dvou dnů podpora na pracovišti, kde bylo uživatelům předvedeny jednotlivé části funkčnosti aplikace od založení dokumentu až po jeho uzavření. Uživatelé si postupně vyzkoušeli všechny části aplikace a poté aplikaci začali samostatně využívat v rutinním provozu. Po měsíci pilotního provozu byl předán seznam připomínek od uživatelů. Nevyskytl se žádný problém, který by bránil v akceptaci projektu. Připomínky se týkaly drobné úpravy grafického rozhraní a taky byl požadavek na novou funkčnost, kterou aplikace nenabízí, neboť nebyla zahrnuta do zadávací studie. Veškeré připomínky budou zahrnuty do dalšího rozvoje aplikace a měly by být zapracovány do příští verze. 29

44 30 KAPITOLA 5. TESTOVÁNÍ Přihlášení uživatele do aplikace Podmínky testu: spuštěný počítač s nainstalovanou aplikací a připraveným zástupcem aplikace na ploše Činnost Očekávaný výsledek činnosti Výsledek testu Spuštění aplikace odkazem Spustí se aplikace a zobrazí se přihlašovací umístěným na ploše okno Vyplnění přihlašovacích údajů Oba údaje lze vyplnit - Login: hejna, Heslo: heslo1 Potvrdit přihlášení tlačítkem Proběhne přihlášení do aplikace, v záhlaví se zobrazí jméno přihlášeného uživatele, nastaví se základní menu a navigační strom Tabulka 5.1: Akceptační test: Přihlášení uživatele do aplikace Zobrazení seznamu dokumentů výběrem z navigačního stromu Podmínky testu: Spuštěná aplikace a přihlášený uživatel Činnost Očekávaný výsledek činnosti Výsledek testu Rozbalení položky Dokumenty Rozbalí se nabídka položky Dokumenty v navigačním stromě dvojklikem myší a zobrazí se položky Ve zpra- cování, Vyřízené, Uzavřené, Zrušené Výběr položky Ve zpracování kliknutím myši na název položky V pravé části obrazovky se zobrazí nové okno s tabulkou dokumentů ve stavu založeno Tabulka 5.2: Akceptační test: Zobrazení seznamu dokumentů výběrem z navigačního stromu Zobrazení seznamu spisů výběrem z navigačního stromu Podmínky testu: Spuštěná aplikace a přihlášený uživatel Činnost Očekávaný výsledek činnosti Výsledek testu Rozbalení položky Spisy v navigačním stromě dvojklikem myší Rozbalí se nabídka položky Spisy a zobrazí se položky Otevřené sp. a Uzavřené sp. Výběr položky Otevřené sp. Respektive Uzavřené sp. kliknutím myši na název položky V pravé části obrazovky se zobrazí nové okno s tabulkou spisů a vyhledávacím formulářem Tabulka 5.3: Akceptační test: Zobrazení seznamu spisů výběrem z navigačního stromu

45 5.3. ZKUŠEBNÍ PROVOZ 31 Založení nového dokumentu bez spisu Podmínky testu: Spuštěná aplikace a přihlášený uživatel Činnost Očekávaný výsledek činnosti Výsledek testu V menu zvolíme položku Nový Otevře se formulářové okno se třemi a vybereme volbu Doručený dokument záložkami pro vyplnění údajů nového dokumentu. Bude předvyplněn typ dokumentu DD a jméno autora a držitele písemnosti podle přihlášeného uživatele Vyplníme pole Věc Pole Věc lze vyplnit Uložíme údaje tlačítkem Uložit Doplní se datum založení písemnosti a číslo dokumentu. Přepneme se na záložku Adresa a vyplníme informace o odesílateli písemnosti Uložíme informace o subjektu pomocí tlačítka Uložit Přepneme se na záložku Soubor, kde vybereme soubor k uložení a potvrdíme tlačítkem Save Uložíme vybraný soubor pomocí tlačítka Uložit Zavřeme okno pro založení dokumentu pomocí křížku v pravém horním rohu Provedeme kontrolu vloženého dokumentu zobrazením seznamu dokumentů pomocí nabídky Dokumenty/Ve zpracování v navigačním stromu Zobrazí se formulářové pole s položkami pro vložení informací o subjektu, položky lze vyplnit. Informace se uloží Vybere se zvolený soubor a jeho název se zobrazí pod formulářem pro výběr souboru. Soubor se uloží Okno se zavře, aplikace zůstane spuštěná. V pravé části se zobrazí seznam dokumentů. Na poslední pozici, s nejvyšším číslem dokumentu bude nově vložený dokument Tabulka 5.4: Akceptační test: Založení nového dokumentu bez spisu

46 32 KAPITOLA 5. TESTOVÁNÍ Založení nového dokumentu s vytvořením nového spisu Podmínky testu: Spuštěná aplikace a přihlášený uživatel Činnost Očekávaný výsledek činnosti Výsledek testu V menu zvolíme položku Nový Otevře se formulářové okno se třemi a vybereme volbu Vlastní dokument záložkami pro vyplnění údajů nového dokumentu. Bude předvyplněn typ dokumentu VD a jméno autora a držitele písemnosti podle přihlášeného uživatele Do pole Věc napíšeme název Pole lze vyplnit spisu (např. Objednávky 2009) Zvolíme tlačítko Nový spis Založí se nový spis s popisem převzatým z pole Věc a číslo tohoto spisu se přenese do profilu nového dokumentu Upravím pole Věc tak, aby odpovídala zakládající písemnosti a uložím údaje tlačítkem Uložit Pole Věc lze upravit a po uložení se doplní datum založení a číslo dokumentu Tabulka 5.5: Akceptační test: Založení nového dokumentu s vytvořením nového spisu

47 5.3. ZKUŠEBNÍ PROVOZ 33 Založení nového dokumentu s výběrem spisu ze seznamu existujících spisů Podmínky testu: Spuštěná aplikace a přihlášený uživatel Činnost Očekávaný výsledek činnosti Výsledek testu V menu zvolíme položku Nový a vybereme volbu Interní dokument Otevře se formulářové okno se třemi záložkami pro vyplnění údajů nového dokumentu. Bude předvyplněn typ dokumentu VD a jméno autora a držitele písemnosti podle přihlášeného uživatele Vyplníme pole Věc a zvolíme tlačítko Výběr spisu Vybereme spis ze seznamu kliknutím na řádek se zvoleným spisem a potvrdíme tlačítkem Vybrat Uložíme vybraný soubor pomocí tlačítka Uložit Zavřeme okno pro založení dokumentu pomocí tlačítka Zavřít Po zvolení tlačítka Výběr spisu se otevře nové okno se seznamem existujících spisů Zavře se okno se seznamem spisů a do formuláře nového dokumentu se do pole Spis přenese číslo vybraného spisu Doplní se datum založení písemnosti a číslo dokumentu. Okno nového dokumentu se zavře, aplikace zůstane spuštěná. Tabulka 5.6: Akceptační test: Založení nového dokumentu s výběrem spisu ze seznamu existujících spisů

48 34 KAPITOLA 5. TESTOVÁNÍ Vyhledávání pomocí panelu rychlého vyhledávání Podmínky testu: Spuštěná aplikace a přihlášený uživatel, v databázi již uložené nějaké dokumenty a spisy. Činnost Očekávaný výsledek činnosti Výsledek testu V panelu rychlého vyhledávání, který se nachází v horní části vedle loga aplikace a je uvedena názvem Vyhledávání podle zvolíme kritérium pro vyhledávání Č.dokumentu. Pole pro výběr vyhledávacího kritéria lze pomocí šipky rozbalit a lze zvolit požadovanou položku Do prázdného pole zapíšeme vyhledávanou hodnotu. Například IP/75/2009, ale stačí zadat i pouze část tohoto řetězce, např. /75/ a potvrdíme tlačítkem Najdi Zvolíme nově vyhledávání podle Č.spisu a zadáme číslo požadovaného spisu (např. /3/) a potvrdíme tlačítkem Najdi Zvolíme nově vyhledávání podle Věci a zadáme část požadovaného názvu (např. Objednávka) a potvrdíme tlačítkem Najdi Zvolíme nově vyhledávání podle Osoby a zadáme část názvu subjektu(např. Novák) a potvrdíme tlačítkem Najdi Zobrazí se tabulka se seznamem dokumentů odpovídajícím požadovaným kritériím. Zobrazí se tabulka se seznamem všech dokumentů, zařazených do požadovaného spisu Zobrazí se tabulka se seznamem dokumentů, které mají v poli Věc slovo Objednávka. Zobrazí se tabulka se seznamem dokumentů, které mají jako subjekt uveden tuto osobu. Tabulka 5.7: Akceptační test: Vyhledávání pomocí panelu rychlého vyhledávání