Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Katedra informačních technologií
Student : Pavel Sládek – xslap13
Vedoucí bakalářské práce : Ing. Luboš Pavlíček Recenzent bakalářské práce : Ing. Kateřina Šrámková
TÉMA BAKALÁŘSKÉ PRÁCE
Dokumentace aplikace pro její uvedení do provozu
ROK : 2006/2007
2/34
Prohlášení
Prohlašuji, že jsem bakalářskou práci zpracoval(a) samostatně a že jsem uvedl(a) všechny použité prameny a literaturu, ze kterých jsem čerpal(a).
V Praze dne ... ...
podpis
1. Abstrakt
Tato práce se zabývá tvorbou dokumentace pro její uvedení do provozu. Cílem práce je poskytnout doporučení pro tvorbu dokumentace pro uvedení aplikace do provozu a v tomto doporučení nejenom obsáhnout strukturu vytvářené dokumentace, ale i pravidla pro její tvorbu.
Analyzuje faktory, které tuto dokumentaci ovlivňují, dává doporučení, jakými se řídit pravidly při tvorbě dokumentace tohoto typu. Jako hlavní prostředek pro tvorbu modelů obsažených v této dokumentaci považuje UML 2.0, proto popisuje jednotlivé diagramy a jejich možnosti použití pro tuto dokumentaci. Na základě analýzy metodik pro vývoj software doporučuje sadu dokumentů určenou k obsažení v dokumentaci tohoto typu. Na příkladu ukazuje, jak by taková dokumentace mohla vypadat.
Práce je rozdělena na dvěčásti, část teoretickou a praktickou ukázku dokumentace.
2. Abstract
This document deals with documentation created and used when deploying an application.
Main goal of this document is to give a guideline for creation of deployment documentation and in this guideline include not only structure of documentation created but also rules for its
creation. It analyzes factors that influence this documentation and it gives advice which rules to follow when creating this kind of documentation. It considers UML 2.0 as a main tool for model design contained in this documentation, so it describes diagrams and their possible usage within this documentation. It recommends set of documents based on analysis of software development methodics. It shows an example of documentation of this kind.
This document is divided to two main parts, theoretic part and practical demonstration of deployment documentation.
4/34
3. Obsah
1. Abstrakt... 3
2. Abstract ... 3
3. Obsah ... 4
4. Úvod... 5
5. Dokumentace pro uvedení aplikace do provozu... 5
5.1. Účel dokumentace tohoto typu ... 5
5.2. Uživatelé této dokumentace... 6
5.3. Obsah této dokumentace ... 6
6. Zásady pro tvorbu dokumentace... 6
6.1. Obsah je důležitější než forma... 6
6.2. Dostupnost dokumentace ... 6
6.3. Snaha o srozumitelnost ... 7
7. Faktory ovlivňující dokumentaci pro uvedení aplikace do provozu... 7
7.1. Použití metodiky pro vývoj software... 7
7.2. Určená pravidla a zvyklosti ... 9
7.3. Způsob dodání aplikace zákazníkovi ... 10
8. Součásti dokumentace pro uvedení aplikace do provozu ... 10
8.1. Části dokumentace pro předání aplikace do provozu ... 10
8.2. Popis architektury systému ... 11
8.3. Model začlenění aplikace do stávajícího IS/ICT ... 11
8.4. Implementovaná funkcionalita ... 11
8.5. Procesy a postupy ... 12
8.6. Komponentní model ... 12
8.7. Topologický model aplikace... 12
8.8. Popis bezpečnostního systému... 12
8.9. Popis zálohování ... 12
8.10. Popis auditního subsystému... 13
8.11. Popis instalace... 13
8.12. Popis rizik ohrožujících systém ... 13
8.13. Release Notes... 13
9. UML jako prostředek pro zápis diagramů... 13
9.1. Co je UML? ... 13
9.2. Proč zrovna UML?... 14
9.3. Diagramy UML a jejich použitelnost při tvorbě dokumentace pro uvedení systému do provozu. ... 15
10. BPMN Diagramy ... 17
11. Diagramy tvořené bez specifické notace ... 18
12. Dokumentace pro předání aplikace do provozu, praktická ukázka ... 18
12.1. Krátké představení systému NESA... 18
12.2. Popis architektury systému ... 18
12.3. Model napojení aplikace na stávajícího IS/ICT... 19
12.4. Popis implementované funkcionality... 19
12.5. Popis klíčových procesů implementovaných v rámci aplikace nebo ve kterých se aplikace podílí... 24
12.6. Komponentní model ... 25
12.7. Topologický model ... 26
12.8. Bezpečnostní subsystém ... 26
12.9. Auditní subsystém... 27
12.10. Popis instalace a plán nasazení ... 27
12.11. Popis zálohování ... 29
12.12. Popis rizik ohrožující provoz aplikace... 30
12.13. Poznámky k sestavení aplikace – Release Notes... 31
13. Závěr ... 31
14. Literatura... 32
15. Terminologický slovník ... 33
4. Úvod
Velmi dynamické prostředí současných informačních technologií, kdy je kladen vysoký důraz na rychlost reakce na požadavky zákazníka a kvalitu dodávaného software, stupňuje tlak na dodavatele IS/ICT řešení. V procesu vývoje software tak není takřka žádný prostor pro chybu nebo nějaké opomenutí. Fáze životního cyklu vyvíjené aplikace, během které je uváděná do provozu, je klíčová z hlediska úspěchu celé aplikace. Důležitým nástrojem pro úspěšné nasazení aplikace do provozu je dokumentace, která je potřeba pro toto nasazení. Tato dokumentace slouží jako podklad pro začlenění aplikace do reálného prostředí, kde bude provozovaná.
Tato práce má za cíl určit doporučení pro tvorbu dokumentace k aplikaci pro její uvedení do provozu. V tomto doporučení se zaměřit jednak na strukturu vytvářené dokumentace, tak i na prostředky, pomocí kterých je tato dokumentace vytvářená.
Použitou metodou pro řešení cíle práce je analýza metodik používaných pro vývoj software se zaměřením na fázi nasazení aplikace do provozu a případných artefaktů, které tyto metodiky popisují. Na základě analýzy celkových potřeb popisovaných v těchto metodikách a jednotlivých kroků, které jsou popisované během vývoje software, syntetizovat doporučení pro sadu
dokumentů, které je vhodné vytvářet jako dokumentaci pro aplikaci při jejím uvedení do provozu. Dalším výstupem je doporučení pro pravidla a prostředky použité při tvorbě této dokumentace a praktická ukázka dokumentace vytvořené podle těchto pravidel.
5. Dokumentace pro uvedení aplikace do provozu
Uvedení aplikace do provozu a zahájení jejího provozu je jedna z klíčových fází implementace informačního systému. Je ohrožena celou řadou rizik, ať už ze strany
neakceptování ze strany uživatelů, tak například obtížemi spojenými s instalací a začleněním aplikace do stávající infrastruktury IS/ICT. Dalším ohrožením jsou rizika spojená s nejasnou funkcionalitou poskytovanou aplikací. Dokumentace která je vytvářená pro nasazení aplikace do provozu by měla tyto problémy a rizika do značné míry eliminovat se snahou o podporu
uživatelů všech typů, ať už to jsou administrátoři zodpovědní za udržování aplikace a jejího prostředí v chodu, tak přímo uživatelé aplikace.
5.1. Ú č el dokumentace tohoto typu
Obecně základním posláním dokumentace je zprostředkovat informaci. Provozní
dokumentace by měla předávat informace potřebné pro provoz a servis informačního systému.
Dokumentace pro uvedení aplikace do provozu pomáhá uživatelům a správcům aplikace s - instalací aplikace
- užíváním aplikace - provozováním aplikace - správou aplikace - učením se aplikaci
Dokumentace by měla podporovat jak standardní operace, tak by se měla snažit o podporu a nabízení řešení v rámci scénářůřešících krizové incidenty. Bylo by chybou ztotožnit tuto
dokumentaci s uživatelskou dokumentací. Je potřeba rozlišit mezi provozní dokumentací určenou primárně správcům aplikace a uživatelskou dokumentací určenou všem uživatelům
6/34
aplikace. Uživatelská dokumentace je zaměřená jiným směrem, popisuje zejména rozhraní aplikace a zpřístupnění funkcionality aplikace přes toto rozhraní. Dokumentace určená pro uvedení aplikace do provozu je orientovaná více technicky a pohlíží na systém z komplexnějšího hlediska.
5.2. Uživatelé této dokumentace
Uživatelé dokumentace pro předání - osoby zodpovědné za instalaci systému - osoby mající na starost provoz systému - uživatelé aplikace
- osoby vystupující během fáze ukončení provozování aplikace
Různí uživatelé mají různé požadavky na dokumentaci, kterou potřebují ke své práci.
Administrátoři odpovědní za instalaci systému primárně potřebují popis jednotlivých komponent systému, vazby mezi software a hardware a instalační postupy, administrátoři zodpovědní za provoz systému potřebují zejména informace týkající se rizik ohrožení provozu systému a jejich řešení. Uživatelé potřebují popis implementované funkcionality.
Řečeno jinými slovy, uživatelé této dokumentace jsou osoby zapojené v procesu podpory, provozu a rozvoje informačního systému.
5.3. Obsah této dokumentace
Vytvářené součásti dokumentace lze zhruba rozdělit na dvěčásti. Na dokumentaci spojenou přímo s nasazením aplikace do provozu a dokumentaci používanou k provozování aplikace.
Z hlediska fáze nasazení do provozu bude důraz kladený na části popisujících topologii systému, komponenty a instalační postupy. Z hlediska provozování aplikace bude důraz na případech užití, listu rizik, popisu zálohování, auditního systému apod..
Dokumentace by měla obsahovat i pohled na systém z hlediska jeho začlenění do celkového IS/ICT organizace. Dokumentace pro uvedení aplikace do provozu vzniká v rámci fáze
dokončování aplikace. Slouží jako podklad pro instalaci aplikace, její spuštění a podpora provozování aplikace.
6. Zásady pro tvorbu dokumentace
V rámci tvorby dokumentace používané při nasazení aplikace do provozu by měla být snaha o dodržení některých principů:
- obsah je vždy důležitější než forma - zajištění dostupnosti
- snaha o co největší srozumitelnost
6.1. Obsah je d ů ležit ě jší než forma
Základním posláním dokumentace je zprostředkovat určitou informaci uživateli. Forma je sice důležitá z hlediska jednotnosti prezentace informace uživateli, ale nesmí být
upřednostňovaná před obsahem.
6.2. Dostupnost dokumentace
Dostupnost je potřeba zajistit takovým způsobem, aby oprávněný uživatel mohl
k dokumentaci přistupovat volně bez omezení. Preferovaný způsob je dokumentace přístupná přes www rozhraní s možností vyhledávání. Proto by měly být používané takové nástroje, které tento požadavek splňují a toto umožňují. Dokumentace by měla být přístupná v kompletní podobě z jednoho bodu, protože tak je uživateli k dispozici jako celek bez nutnosti rozhodování, kde má hledat informaci různých typů. Dokumentace by měla být prezentovaná včetně logického
propojení mezi jednotlivými částmi dokumentace tak, aby se uživatel mohl rychle a jednoduše dostat k informaci, kvůli které dokumentaci používá..
Zajímavou alternativou pro uchovávání dokumentace jsou systémy založené na wiki technologiích. Tyto systémy používají myšlenku toho, že uložené dokumenty mohou upravovat samotní uživatelé. Nástroje obsahují mechanizmy jak zabránit úmyslnému degradování
informací některými uživateli. Tyto systémy jsou značně flexibilní a umožňují snížit cenu tvorby dokumentace a tím pádem takto tvořená dokumentace může být kvalitnější a aktuálnější než systém dokumentace který je tvořen jinými způsoby. Dalším přínosem těchto systémů je možnost velice rychlého získání zpětné vazby od uživatelů a zapojení uživatelů do tvorby dokumentace k systému, což může značně zvýšit přínos z používání dokumentace.
6.3. Snaha o srozumitelnost
Forma ve které je dokumentace prezentovaná uživateli by měla být zvolená se snahou o co největší srozumitelnost dokumentů, aby uživatel i bez předchozích zkušeností dokázal využit informace, které jsou v dokumentaci uložené. Tím by se měly řídit i prostředky, které se použijí pro zápis jednotlivých částí provozní dokumentace. Jako de facto standard pro modelování se v současnosti používá UML a jeho přínos z hlediska široké znalosti jeho notace ho určuje jako vhodný prostředek pro modelování a zápis částí provozní dokumentace.
Dokumentace ve formě modelů sice poskytuje přehlednou komunikační formu, ale
v naprosté většině případů nelze vystačit pouze s modely. Nejvhodnější je při tvorbě modelů tyto modely doplňovat textovým popisem, který dále může upřesnit aspekty řešení, které model nemusí zachytit.
UML navíc obsahuje větší počet diagramů používaných pro různé účely. Pro potřeby tvorby provozní dokumentace jsou samozřejmě mezi nimi rozdíly a jsou také různě pro tento úkol vhodné. Bez některých diagramů by se neměla objevit žádná provozní dokumentace a na druhou stranu některé mají takové zaměření, že nejsou reálně použitelné. Tato otázka bude analyzovaná dále.
7. Faktory ovliv ň ující dokumentaci pro uvedení aplikace do provozu
To, jaká dokumentace a v jakém rozsahu je vytvářená pro předání aplikace do provozu je ovlivněno řadou faktorů.
- použití metodiky pro vývoj software - určená pravidla a zvyklosti
- způsob dodání aplikace zákazníkovi
7.1. Použití metodiky pro vývoj software
Existuje celá řada metodik, které se používají pro vývoj software. „Metodika představuje v obecném smyslu souhrn metod a postupů pro realizaci určitého úkolu.“ [Buchalcevová 2005]
Nebo jiná popisnější definice pojmu metodika budování IS/ICT říká, že „metodika je tvořena obecně uznávanými postupy a návody, které popisují činnosti při analýze, návrhu, vývoji, nasazování software stejně jako činnosti spojené s řízením projektu“ [Voříšek 1997]. Použitá metodika může do značné míry předepisovat, jaké artefakty mají vznikat v rámci vývoje software. Metodiky pro vývoj IS/ICT lze kategorizovat z celé řady hledisek, jako je zaměření metodiky, rozsah, váha, typ řešení, doména řešení, přístup k řešení. „V současnosti lze sledovat dva hlavní proudy v metodických přístupech, které jsou označované jako rigorózní a agilní metodiky“ [Buchalcevová 2005]. Příkladem rigorózní metodiky může být například RUP (Rational Unified Process), EUP (Enterprise Unified Process), OPEN (Object-oriented Process, Environment, and Notation) nebo MMDIS (Multidimensional Management and Development of Information System).
8/34
7.1.1. Rigorózní p
řístup
7.1.1.1. RUP
Metodika RUP byla vyvinuta firmou Rational, kterou posléze koupilo IBM. Jedná se o procesní metodiku vývoje softwaru, která je dodávaná jako kompletní produkt zákazníkům. RUP definuje 4 fáze během vývoje software:
- Počáteční fáze (Inception) - Rozpracování (Elaboration) - Konstrukce (Construction) - Nasazení (Transition)
Metodika popisuje účely těchto fází, přechod mezi fázemi, v rámci těchto fází definuje další rozdělení na dílčí kroky procesu, role uživatelů vystupujících v procesech, artefakty které
v procesu tvorby software vznikají i popisuje kdo tyto artefakty dále zpracovává.
7.1.1.2. EUP
EUP rozšiřuje RUP o další dvě fáze spojené s provozováním software a to o fázi provozu a fázi nahrazení. Celkově je EUP vytvářen se snahou o procesní pokrytí celého života aplikace v rámci organizace. Dalo by se říci, že EUP začíná tam, kde RUP končí, protože RUP je
primárně orientovaný na vývoj software a jeho dodání zákazníkovi. EUP toto rozšiřuje o otázku provozu software a jeho případné nahrazení, tedy podporu clého životního cyklu software.
7.1.1.3. OPEN
Metodika OPEN je zajímavá z hlediska svojí architektury. Obsahuje v sobě totiž procesní metamodel ze kterého vzniká metodika jako instance vytvořená pro konkrétní organizaci.
Z hlediska dokumentace tato metodika nepředepisuje vytváření určitých artefaktů, je zaměřena spíše na procesní stránku vývoje aplikací. Obsahuje seznam tříd dokumentů, které mohou být zahrnuty do finální metodiky z ní odvozené.
7.1.1.4. MMDIS
MMDIS je metodika vyvíjená na Katedře informačních technologií na Vysoké škole ekonomické v Praze. Je zaměřena na celou organizaci a zdůrazňuje multidimenzionální pohled na řešení IS/ICT, tedy řešení souběžně ze všech pohledů na dimenze řešení IS/ICT.
7.1.2. Agilní p
řístup
Stále se zrychlující proces tvorby software má za následek, že tradiční rigorózní metodiky přestávají stačit a ukazují se jako málo pružné, aby dokázaly reagovat na časté změny prostředí a vysoký tlak na rychlost dodání software. Jako odpověď na tyto požadavky se objevily agilní metodiky, které jsou vytvořené se zaměřením na co nejvyšší flexibilitu metodiky z hlediska rychlé reakce na požadavky zákazníka.
Základní principy agilních metodik, které se samozřejmě promítají i do dokumentace, která je vytvářená, jsou definované v takzvaném Manifestu vývoje agilního software [Agile Manifesto 2001]:
- včasné a kontinuální dodávání software
- vítání změn požadavků, protože změna může zákazníkovi přinést výhodu - co nejkratší doba mezi funkčními verzemi software, preference krátkých
implementačních cyklů
- spolupráce business uživatelů a vývojářů
- stavění projektů okolo motivovaných osob s vytvořenými podmínkami pro práci - nejlepším způsobem výměny informací je tváří v tvář
- pracující software je primární ukazatel pokroku projektu
- agilní procesy podporují trvale udržitelný rozvoj
- klíčová je jednoduchost, tedy maximalizace práce, která nemusí být vykonána - nejlepší architektura, požadavky a design pochází ze samoorganizujících se týmů - v pravidelných intervalech tým zkoumá, jak být více efektivní a mění své chování
podle toho
Pro dokumentaci, která by měla být vytvářená v rámci projektů vyvíjených pomocí agilních metodik jsou doporučené některé vlastnosti. [Ambler 2006a ]
- dokumentace by měla být stručná
- vytvářet pouze opravdu potřebnou dokumentaci
o pokud dojde ke změně systému, tak je reálná možnost potřeby změnit dokumentaci, proto čím méně je vytvořených artefaktů, tím méně jich bude případně nutno upravit
- dokumentace by měla být vytvořená v ucházející kvalitě
o cokoliv nad úroveň ucházející je u dokumentace považováno za zbytečně vynaložené úsilí
- modely nejsou nutně dokumentace a dokumentace nejsou nutně modely - primární cíl týmu je vývoj software, ne tvorba dokumentace
- výhoda z dokumentace musí být větší než náklady na její tvorbu - provádět změny v dokumentaci pouze pokud je to nutné
- primární je u modelu informace, kterou má vyjádřit, ne jeho forma
Agilní metodika na základě těchto pravidel poskytuje vývojáři značnou volnost pro jeho rozhodnutí, jakou dokumentaci bude vytvářet. Nesmí se ale zapomenout, že často je
dokumentace vyžadovaná a používaná jinými organizačními složkami. Toto je často právě případ dokumentace určené pro předání aplikace do provozu.
Na druhou stranu lze z agilních metodik převzít celou řadu principů, jako je značný důraz na obsah proti formě nebo hledisko na přínos dokumentace proti nákladům na její vytváření. Tento přístup lze pouze doporučit k převzetí.
Agilní metodiky pro vývoj software předpokládají, že informační systém se do značné míry chová jako živý organizmus s neustálými změnami, které jsou do něj zanášené. Tyto změny mají původ jednak v okolí systému a jsou také vyvolávané změnami v rámci systému na základě požadavků zákazníka. Prostředí stávajících technologií považují za proměnlivé s obtížným úkolem udržení vztahu mezi dokumentací a reálným prostředím, což je samozřejmě z hlediska použitelnosti dokumentace klíčový problém. Proto zavádí principy jako omezení dokumentace na pokud možno co nejmenší množství s co největším přínosem pro vývoj systému.
7.1.3. Zhodnocení metodik ve vztahu k dokumentaci
Otázka je, nakolik lze agilní principy použít při tvorbě klasické dokumentace. Optimální se ukazuje cesta uprostřed mezi oběma přístupy. Vytváření předdefinovaných artefaktů za použití principů popsaných v agilních metodikách.
7.2. Ur č ená pravidla a zvyklosti
Pravidla pro části a formu dokumentace určené pro předání aplikace do provozu jsou často předem daná zákazníkem, který bude daný systém provozovat. Většinou už existují v organizaci pravidla, která musí být při tvoření dokumentace dodržovaná. Může se jednat o zapsané
podmínky ve formě směrnic zákazníka případně zvyklosti spojené s předchozími dodávkami software i od jiných dodavatelů. Takovéto podmínky pak často vstupují v určité formě do
smluvního vztahu o dodávce software jako součást smlouvy.Může být určena řada parametrů, od formy, nutné součásti obsahu, uložení dokumentace, proces publikování případných nových verzí dokumentace a další. Jako příklad může sloužit státní správa, která vydala vyhlášku určující požadavky na provozní dokumentaci informačních systémů státní . Řada velkých
10/34
podniků má podobná pravidla pro vlastní dokumentace, aby dokázali zajistit řízení dokumentace skrz své procesy.
7.3. Zp ů sob dodání aplikace zákazníkovi
Typ dokumentace, která by měla být dodávaná s aplikací pro její nasazení do provozu, ovlivňuje i forma, jak je aplikace dodávaná zákazníkovi. Existují tři základní možnosti, jakým způsobem je aplikace daná zákazníkovi.
- instalace na zákazku - krabicové řešení
- software zpřístupněný přes internet
7.3.1. Instalace na zakázku
Tento způsob dodání je nejčastější pro informační systémy a aplikace, které jsou buď vyvíjené na zakázku nebo jsou to řešení, která se značně upravují podle prostředí klienta. Důraz zde je kladen na popis nasazení na jednotlivé systémy a vztah mezi jednotlivými komponentami systému.
7.3.2. Krabicové
řešení
Krabicové řešení je typicky takové, kdy se neprovádějí nebo provádějí pouze v malé míře, úpravy a konfigurace podle prostředí klienta. Typicky je potom dokumentace určená pro nasazení aplikace zaměřená na popis instalačních postupů.
7.3.3. Software zp
řístupn
ěný p
řes internet
V případě software, který je zákazníkovi zpřístupněný jako funkcionalita přes internet je největší důraz z hlediska dokumentace pro předání aplikace do provozu kladený na popis případů užití. Tak získá zákazník informaci o tom, která funkcionalita je mu zpřístupněná a má ji
k dispozici.
8. Sou č ásti dokumentace pro uvedení aplikace do provozu
Při tvorbě provozní dokumentace je zásadní otázka, co přesně má být její součástí. Základní informace pro uživatele by měly být, jaká funkcionalita je v systému implementovaná. Toto nejlépe zobrazují diagramy užití, kde lze jednoduchým způsobem zachytit funkcionalitu poskytovanou pro každou roli vystupující v systému. Další součásti dokumentace by měly popisovat důležité procesy, které jsou v aplikaci implementované nebo je aplikace podporuje, závislost aplikace na okolí a její začlenění do stávajícího prostředí IS/ICT, způsob implementace se zachycením vazby software na hardware, rizika ohrožující provozování aplikace, jejich identifikaci a nástin jejich řešení, způsob instalace a konfigurace jednotlivých komponent.
8.1. Č ásti dokumentace pro p ř edání aplikace do provozu
Tyto části dokumentace jsou navrhované na základě analýzy metodik a postupů
používaných při tvorbě software. Dalším vstupem pro formulaci doporučení je osobní zkušenost z vývoje software. Doporučované dokumenty jsou zvoleny se snahou o jasné určení, co je obsahem daného dokumentu.
- Popis architektury systému
o Celkový způsob, jakým je aplikace navržena a s jakou filozofií byla vyvíjena - Model napojení aplikace na stávajícího IS/ICT
- Popis implementované funkcionality
o nejlépe formou diagramů užití. Je klíčový pro popis systému, protože ukazuje, která funkcionalita je systémem implementovaná a jaké uživatelské role k této funkcionalitě přistupují.
- Popis procesů implementovaných v rámci aplikace nebo ve kterých se aplikace podílí o Nejlépe pomocí aktivity diagramů případně BPMN notace
o Popisuje návaznosti činností v za sebou jdoucích krocích a případné odpovědnosti jednotlivých komponent systému za zpracování těchto kroků
- Komponentní model
o Popisuje rozdělení aplikace na jednotlivé komponenty, tedy prvky s definovaným rozhraním a určitou množinou funkcionality
- Topologický model aplikace
o Popisuje fyzickou vazbu mezi jednotlivými softwarovými komponentami a hardwarovými komponentami systému
- Popis instalace a plán nasazení
o Popisuje způsob instalace jednotlivých částí systému, případně závislosti mezi jednotlivými kroky
- Popis bezpečnostního systému a uživatelských rolí aplikace - Popis zálohování
- Popis auditního systému
- Popis rizik ohrožující provoz aplikace
o Popisuje nejčastější možné příčiny provozních problémů a způsob jejich řešení - Poznámky k sestavení aplikace – Release Notes
8.2. Popis architektury systému
V rámci této části by měl být systém popsán z architektonického hlediska. Jaké části ho tvoří, kde je uložena aplikační logika, na jakých dalších systémech závisí a podobné informace, které jsou pro uživatele, který čte tuto dokumentaci důležité, aby si udělal obrázek o systému jako celku. Není potřeba zacházet do detailů, které spíše budou popsané v rámci topologie nebo komponent, klíčové je představit uživateli systém jako celek a jak je aplikace postavená.
8.3. Model za č len ě ní aplikace do stávajícího IS/ICT
Jeho účel je zobrazit, jakým způsobem aplikace zapadá do celkového prostředí organizace.
Umožňuje zachytit vazby systému na další systémy provozované v organizaci.
8.4. Implementovaná funkcionalita
Popis funkcionality implementované v aplikace je důležitý z hlediska přehledu o tom, jaké služby a komu aplikace poskytuje. Měl by popisovat všechnu funkcionalitu v aplikace včetně její vazby na aktéry, kteří k této funkcionalitě mají přístup a mohou ji využívat. Popis funkcionality na úrovni diagramů užití by měl být vytvořený pro každý systém v rámci IS/ICT prostředí organizace. Poskytuje pohled zvnějšku na to, co daný systém nebo aplikace vykonává za činnost a jaké služby poskytuje. Tato dokumentace je spojená s otázkou „co“ poskytuje aplikace.
Diagramy s případy užití jednak zachycují implementovanou funkcionalitu systémem, tak vazbu této funkcionality na role, které tuto funkcionalitu používají.
Celkový popis implementované funkcionality je potřebný z důvodu komunikace se zákazníkem, kterému má aplikace sloužit. Na jeho základě lze zpětně zkontrolovat, že byla požadovaná funkcionalita opravdu dodaná a že byla dodaná v odpovídajícím rozsahu a dle požadavků v zadání.
Případy užití je vhodné kombinovat v grafické notaci s jejich textovým popisem. Z hlediska komunikace s uživatelem bývá kombinovaná forma vhodnější než prezentace pouze v grafické
12/34
nebo textové formě. Případy užití by měly být základním vstupem pro tvorbu testovacích scénářů, tedy pro testování funkcionality aplikace.
8.5. Procesy a postupy
Dalším základní prvkem dokumentace pro předání aplikace do provozu je popis, jakým způsobem je funkcionalita v aplikaci implementovaná. Na základě tohoto popisu si lze udělat obrázek o tom, jakým způsobem aplikace postupuje k zajištění funkcionality, kterou poskytuje.
Procesy ve kterých aplikace vystupuje lze rozdělit na dvěčásti. Na procesy, kde se aplikace pouze zapojuje a na procesy implementované uvnitř aplikace. V případě vnitřních procesů by měla dokumentace popisovat zejména místa, kde dochází ke vstupu a výstupu do procesu, není až takovým přínosem podrobně popisovat jakým způsobem aplikace funguje uvnitř. Tato část dokumentace je zaměřena na otázku „jak“ spojenou s provozováním aplikace.
Měla by být snaha v rámci této dokumentace o zachycení jednak věcné náplně procesů, tedy jednotlivých kroků a jejich návazností, ale i zachycení vazby na uživatelské role, organizační jednotky a vznik případných artefaktů během procesu.
8.6. Komponentní model
Komponentní model popisuje, jakým způsobem je aplikace implementovaná. Jeho primární snahou je zobrazení závislosti jednotlivých částí aplikace mezi sebou a jakým způsobem tyto části mezi sebou komunikují. Klíčové je zachycení rozhraní, které komponenty mezi sebou používají pro komunikaci. Pomocí stereotypů je vhodné zachytit způsob implementace jednotlivých komponent.
Doplňuje se s topologickým modelem, který je orientovaný zejména na hardwarové
prostředky, komponentní model se zaměřuje na popis rozdělení systému z hlediska rozdělení na jednotlivé komponenty.
8.7. Topologický model aplikace
Tato část dokumentace má za cíl zachytit vazbu mezi software a hardwarovými prostředky, které jsou použity pro zajištění běhu aplikace. V rámci zachycení stavu by měly být zachyceny i rozhraní přes které jednotlivé části systému komunikují a jejich umístění. Tato dokumentace dává odpověď na otázku „kde“ spojenou s provozováním aplikace.
Na základě topologického modelu lze do určité míry odhadnout dopad například výpadku některých HW prostředků na celý systém nebo lze odhadnout práce spojené například s obnovou některých prostředků.
8.8. Popis bezpe č nostního systému
V současné době takřka každá aplikace musí implementovat určitý systém řízení přístupu k informacím, které jsou v ní uložené a funkcionalitě, kterou poskytuje. Dokumentace by měla obsahovat sekci popisující jednak způsob, jakým je proces bezpečnosti zajištěn a řízen, tak uživatelské role, které v systému vystupují a způsob, jakým jsou přístupová práva přidělovaná a revokovaná. Důležitý je popis autentizace a autorizace.
8.9. Popis zálohování
Další částí provozní dokumentace by měl být popis systému zálohování. Zejména jak často a jakým způsobem jsou zálohy prováděné, určení o jaký typ záloh se jedná (plné zálohy nebo inkrementální) a způsob obnovení dat z těchto záloh. Tento popis je důležitý z důvodu potřeby obnovení dat, protože při situacích havarijního typu, kdy není času nazbyt, je potřeba postupovat podle určitého návodu, aby byla zkrácená doba výpadku na pokud možno co nejkratší dobu.
Bohužel často dochází k situacím, kdy se až při řešení nenadálé situace shání zálohy a zjišťuje se, jaká data vůbec byla zálohovaná. Tato část dokumentace by toto měla popisovat a řešit a být
hlavním vodítkem při obnově dat. Při tvorbě tohoto popisu se samozřejmě může zjistit, že v návrhu systému bylo zálohování podceněno a je nedostatečné. To by mělo vyvolat zpětnou vazbu a takovýto případný nedostatek napravit.
8.10. Popis auditního subsystému
Součástí dokumentace by měl být popis auditního subsystému implementovaného
v aplikaci. Zejména jde o to, kde jsou soubory s auditními informacemi uložené, jaká data jsou do nich ukládaná a kdo k nim má přístup. Tyto informace jsou důležité pro obsluhu v případě řešení celé řady incidentů, které mohou nastat během provozování aplikace.
8.11. Popis instalace
Zde by měl být popsaný postup instalace aplikace respektive jednotlivých komponent řešení. Mělo by být i uvedeno pokud aplikace využívá služby poskytované jiným systémem a je potřeba provést přípravné kroky k tomu, aby tyto služby aplikace mohla začít využívat. Je třeba popsat a zachytit pokud některé kroky na sobě závisí.Tento popis je užitečný v případě nutnosti reinstalace některé z komponent systému, ať už z důvodu jejího selhání nebo z důvodu například migrace na jiný hardware. Také může být použitý v případě rozšíření některé z komponent systému, pokud architektura systému toto umožňuje.
8.12. Popis rizik ohrožujících systém
V rámci této sekce by měly být popsaná rizika ohrožující běh systému. Řadu rizik lze odhadnout na základě zkušenosti případně mohly být identifikované v rámci testování. Toto jsou často velice hodnotné znalosti pro samotné provozování aplikace, protože k rizikům by měly být doplněné postupy spojené s identifikací závady, tak postupy, jak danou závadu odstranit nebo alespoň operativně odstranit. Tyto informace umožňují krátce po objevení chyby, pokud je obsažena v tomto dokumentu, odhadnout jak dlouho bude trvat náprava nebo s jakými zdroji lze nápravu provést. Popis řešení by měl být rozdělen na popis operativního řešení a popis trvalého řešení, u takových možností, kde lze tyto dva způsoby řešení identifikovat. Příkladem mohou být ohrožení z hlediska výpadku sítě, výpadku použitých komponent systému, výpadky externích systémů, na které má informační systém vazbu apod. Jednak by měly být obsažené kroky sloužící k identifikaci a lokalizaci problému, tak kroky sloužící k jeho řešení. Okolí
informačního systému na který má vazbu jednak do velké míry určuje spolehlivost, se kterou dokáže informační systém poskytovat svoje služby.
8.13. Release Notes
V tomto dokumentu, svázaném s určitou verzí aplikace, lze popsat věci specifické pro určitou verzi aplikace, která je uváděná do provozu. Může se jednat o informace typu seznamu opravených chyb podle verze, seznam známých chyb nebo omezení, které daná verze obsahuje, důležité připomínky k funkcionalitě, která je v aplikaci implementovaná apod..
9. UML jako prost ř edek pro zápis diagram ů
9.1. Co je UML?
Na tuto otázku lze odpovědět několika způsoby. Modelovací jazyk UML je souhrnem především grafických notací k vyjádření analytických a návrhových modelů [Kanisová 2006]
UML je neproprietární standard obssahující standardní způsoby pro grafické zachycení modelovaných objektů a jejich vztahů. Jeho specifikace vydává organizace OMG (Object Management Group), která standard definuje. Jedním z cílů UML je poskytnout jednoduchý výrazový prostředek pro modelování software. Poskytuje sémantické a syntaktické prostředky
14/34
pro vizualizaci návrhu nejenom aplikací a software ale i systémů a obchodních procesů. Velkou výhodou UML je to, že je to natolik široce akceptovaný standard, že znalost a schopnost číst modely zapsané v UML už dávno není pouze výsadou softwarových vývojářů a vůbec lidí spojených s IT technologiemi. Použití stejné syntaxe pro modelování aplikací nejrůznějších typů vede k možnosti sdílení práce s ostatními návrháři a má další výhody spojené se
znuvupoužitelností návrhu apod.
Nesmíme ale zapomínat, že UML je především nástrojem pro vývoj a jako takový tedy přínos z použití tohoto jazyka není přímo v jeho používání, ale v tom, jak je používán. UML není metodika. Je tedy potřeba se vyhnout používání UML pro UML nebo vizí o zvýšení kvality kódu a aplikace, pokud se bude provádět modelování v UML. Dokonce takovéto případy mohou působit kontraproduktivně. Situace je zde podobná jako s technologiemi spojenými s XML a Web Services. Ty také, pokud jsou použity na správném místě, dokáží usnadnit a zrychlit vývoj aplikací, ale v celé řadě projektů jsou tyto technologie použity bez rozmyslu a jejich použití vede spíše k problémům, než že by bylo přínosem.
9.2. Pro č zrovna UML?
UML slouží jako univerzální prostředek pro komunikaci, představuje v současné době nejrozšířenější jazyk pro modelování.
Výhody
- široce akceptovaný a podporovaný standard
- rozšířená schopnost číst modely v tomto jazyce napsané - rozšiřitelnost přes mechanizmus stereotypů a profilů - pokrytí celého cyklu vývoje software
Nevýhody
- méně prostředků pro fyzický návrh
- nepokrytí některých oblasti modelování svým zaměřením na objektový návrh
9.2.1. Široce akceptovaný a podporovaný standard
Existuje celá řada nástrojů, která dokáže pracovat s diagramy zapsanými v jazyce UML.
Tyto aplikace jsou jak komerční, tak z oblasti Open Source komunity. Ten kdo dokumentaci vytváří si tak může vybrat ze široké nabídky nástrojů, které může použít pro tvorbu
dokumentace.
9.2.2. Rozší
řená schopnost
číst modely v tomto jazyce
UML jako jazyk je v současné době natolik rozšířený, že se mu podařilo prosadit nejenom v rámci IT komunity, ale znalost a schopnost číst modely v něm zapsané je stále častěji i u osob, které se IT primárně nezabývají, případně se zabývají IT spíše okrajově. Tato vlastnost je vysoce důležitá z důvodu použití diagramů zapsaných v UML jako komunikačního nástroje pro
komunikaci například se zástupci businessu nebo běžnými uživateli aplikace. Tento přínos je vysoce důležitý, protože v praxi je tato komunikace často klíčová pro úspěch projektů. A fáze nasazení aplikace do provozu není žádnou výjimkou.
9.2.3. Pokrytí celého cyklu vývoje software
UML je jazyk orientovaný na vývoj software. Obsahuje prostředky pro zachycení informací od požadavků na systém po uvedení systému do provozu. Umožňuje zachytit chování aplikace jak z hlediska statických prvků tak z hlediska jejího dynamického chování. Flexibilita diagramů v UML pomáhá popsat aplikaci jak na konceptuální úrovni, tak na nižší implementační úrovni.
Víceméně jde pouze o určení měřítka, ve kterém budeme modely vytvářet a do jakého detailu se ponoříme.
9.2.4. Mén
ěprost
ředk
ůpro fyzický návrh
Samotné UML neposkytuje příliš široké prostředky pro popsání fyzického návrhu. Obsahuje diagram nasazení a diagram pro zachycení jednotlivých balíčků. Neobsahuje ale například další grafické prvky pro určení fyzických prvků celkového řešení a celkově je orientovaný spíše na objektovou analýzu než na fyzický návrh.
9.2.5. Nepokrytí n
ěkterých oblasti modelování svým zam
ěřením na objektový návrh
Orientace striktně na objektové modelování může být překážkou ve vztahu k možnostem použití UML jako jediného jazyka pro modelování. Ať už to jsou diagramy ukazující na vysoké úrovni architekturu nebo zobrazení datových toků, tyto úlohy jsou v UML obtížněřešitelné.
Často je nakonec lepší použít například MS Visio pro vytvoření takovéhoto modelu.
9.3. Diagramy UML a jejich použitelnost p ř i tvorb ě dokumentace pro uvedení systému do provozu.
V této části budou představené jednotlivé diagramy, které jsou definované v rámci UML a jejich možné použití pro vytvoření dokumentace pro předání aplikace do provozu. UML rozděluje diagramy na dvě hlavní skupiny:
- diagramy struktury
- diagramy chování s podmnožinou diagramů interakce
9.3.1. Diagramy struktury
9.3.1.1.Diagram tříd (class diagram)
- Diagram tříd ukazuje entity, které jsou v rámci aplikace, jejich atributy a vztahy mezi entitami. Jinými slovy lze říci, že popisuje statickou strukturu systému. Diagram tříd lze použít k zachycení logických tříd, jak je často vnímají osoby pracující na business pozicích. Další možností diagramu tříd je jeho použití k zachycení tříd, jak je systém implementuje. Hlavní rozdíl v těchto dvou pohledech budou typy atributů, které jsou s objekty spojeny, kde v „business“ pohledu budou atributy s typy označující obchodní logiku.
- V dokumentaci pro předání aplikace do provozu nemá tento diagram až tak široké využití jako ve fázi vývoje. Na druhou stranu je lze často převzít z fáze vývoje aplikace a popsat vztahy mezi některými třídami jako diagram tříd. Jeho hlavní úloha je ale ve fázi vývoje než během fáze nasazení aplikace.
9.3.1.2.Diagram složené struktury (composite structure diagram)
- Popisuje vnitřní strukturu třídy, rozhraní nebo komponenty a vztahy mezi těmito částmi.
Tento diagram je vhodné vytvářet v případech, kdy se snažíme popsat součást systému, která je vnitřně složitě uspořádaná a jako celek během běhu aplikace poskytuje určitou funkcionalitu. Jinými slovy řečeno, pokud seskupení objektů, komponent poskytuje na základě vazeb mezi sebou určitou funkcionalitu, je možné zvážit vytvoření tohoto diagramu.
- V některých případech je vhodné tento diagram vytvořit, pokud chceme zobrazit například vztah mezi komponentami, kdy jedna komponenta deleguje určitou funkcionalitu na komponentu obsaženou ve vnitřní části apod.
9.3.1.3.Diagram komponent (component diagram)
- Popisuje, jak je systém rozdělen do jednotlivých kusů software a vztahy mezi těmito komponentami. Popisuje na vyšší úrovni než diagram tříd jednotlivé logické celky
16/34
v aplikaci a zachycuje rozhraní mezi nimi. Tento diagram lze koncipovat jako pohled na vyšší úrovni na použité komponenty.
- Může být použitý pro znázornění celkové architektury řešení
- S jeho pomocí může být zobrazeno složení aplikace a její vztah například s jednotlivými knihovnami poskytující určitou funkcionalitu.
9.3.1.4.Diagram nasazení (deployment diagram)
- Diagram nasazení aplikace ukazuje jak bude systém fyzicky nasazen na hardwarových prostředcích. Jeho účel je zobrazit vazbu mezi hardwarovými prostředky a softwarovými komponentami, které na nich budou provozovány a jakým způsobem budou mezi sebou komunikovat. Diagram se vytváří jako obraz stavu během provozování systému.
- Jeho uživatelé jsou zejména osoby spravující systém z hlediska provozního prostředí a osoby zodpovědné za instalaci a v rámci krizových scénářů. Pro účely nasazení aplikace do provozu by měl být vytvářený vždy.
9.3.1.5.Diagram objektů (object diagram)
- Ukazuje systém v určitou chvíli během jeho běhu. Ukazuje instance jednotlivých tříd objektů a vztahy mezi těmito instancemi.
9.3.1.6.Seskupení tříd (package diagram)
- Zachycuje logické skupiny tříd, které v systému vystupují a vztahy mezi těmito skupinami. Většinou se použijí při návrhu většího projektu pro modelování objektů na vyšší úrovni, například pokud budou v jednotlivé skupiny tříd implementovány pomocí oddělených komponent apod. Umožňuje uchopení většího množství objektů, například tříd, a jejich abstrakci na určité úrovni pro zpřehlednění diagramu pro uživatele.
9.3.2. Diagramy chování
9.3.2.1.Diagram případů užití (use case diagram)
- Případ užití ukazuje jednotku funkcionality kterou systém poskytuje. Hlavním úkolem diagramu užití je vizualizace požadavků na funkcionalitu systému, zejména vztahu aktérů a základních procesů společně se zachycením vztahu mezi různými případy užití.
Většinou se diagramy užití tvoří jako skupina užití pro celý systém nebo se seskupují případy užití s obdobnou funkcionalitou, pokud je případů užití příliš mnoho. Seskupení lze provádět podle aktérů a jejích rolí, kteří funkcionalitu využívají nebo podle
podobného typu případu užití, například případy užití spojené s bezpečností.
- Je to základní diagram, který by měl být vytvořený pro každý systém v rámci podnikového IS/ICT. Jeho hlavní přínos je v zachycení kompletní funkcionality poskytované systémem a její vazby na role v rámci systému.
9.3.2.2.Diagram aktivit (activity diagram)
- Popisuje krok za krokem modelovaný tok v rámci procesu. Tyto diagramy se použijí nejčastěji při popisu implementovaných procesů v rámci systému. Poskytují informaci o krocích, které se v rámci procesů vykonávají a jejich návaznostech. Jako takový
poskytuje informace uživateli pro získání představy o tom, jak je daný proces
implementován v rámci aplikace. V případě rozdělení aplikace na logické celky nebo pokud část procesu probíhá v jiném systému, tento diagram disponuje prostředky jak toto zachytit a zobrazit.
- Největší předností diagramu aktivit je možnost modelování paralelních procesů, jejichž části mohou probíhat souběžně. Velkou nevýhodou je jejich slabá vazba pro zachycení
vazby mezi vykonávanými aktivitami a objekty, které v rámci těchto aktivit vystupují.
Diagram aktivit lze použít jak pro modelování obchodních procesů na vyšší úrovni tak pro modelování vnitřního chování činností třídy na nízké úrovni. Dle zkušenosti je lepší používat aktivity diagram pro modelování procesů na vyšší úrovni z důvodu jejich jednoduché notace pro čtení.
9.3.2.3.Sekvenční diagram (sequence diagram) - Popisuje sekvenci zpráv zasílaných mezi více objekty
- Sekvenční diagram ukazuje tok aplikace v rámci určitého případu užití nebo jeho části.
Ukazuje volání mezi různými objekty v rámci procesu a lze pomocí něho zachytit na detailní úrovni zasílání zpráv a volání mezi různými objekty. Vertikální pozice
v diagramu je použitá pro ukázání jednotlivých kroků v rámci času a v pořadí ve kterém se objevují, horizontální rozměr diagramu ukazuje instance jednotlivých objektů mezi kterými jsou zprávy zasílané.
9.3.2.4.Diagram objektové komunikace (communication diagram) - Popisuje vztah mezi dvěma objekty z hlediska výměny zpráv mezi nimi a pořadí
vyměňovaných zpráv. Je to pouze lehce odlišný pohled od sekvenčního diagramu na vyjádření toku aplikace v rámci jednoho případu užití, ale základní informace
zprostředkovávaná je stejná. Komunikační diagram může ale lépe ukázat četnost volání mezi jednotlivými instancemi třídy a tím pádem dát nápovědu pro členění aplikace do jednotlivých balíčků.
9.3.2.5.Diagram přehledu interakce (interaction overview diagram)
- Varianta diagramu aktivity, která je zaměřená na celkový pohled na interakci mezi jednotlivými diagramy popisujícími interakci
- Celkový pohled na interakci v rámci obchodního procesu
9.3.2.6.Timing diagram
- Popisuje komunikaci mezi objekty zaměřenou na časový aspekt této komunikace.
V rámci dokumentace pro předání aplikace do provozu může být s jeho pomocí dobře popsaný například časové rozložení zálohování nebo úlohy, které systém provádí vždy v noci.
9.3.2.7.Stavový diagram (state machine diagram)
- Stavový diagram modeluje různé stavy, které objekt může nabývat a přechody mezi těmito stavy. Tento diagram se většinou vytváří pouze pro třídy, kde je zajímavé zachytit různé stavy z hlediska dokumentace. Jeho výhodou je to, že dokáže zachytit změnu stavů objektu napříč více případy užití.
- Z hlediska provozní dokumentace by mohlo být jeho vytvoření zajímavé pro popis například speciálních zařízení, které se mohou v systému používat a které jsou řízeny na základě stavové logiky nebo některé části systému mohou nabývat různých stavů a na jejich základě měnit své chování.
10. BPMN Diagramy
BPMN (Business Process Modeling Notation) diagramy jsou zaměřeny na popsání
obchodních procesů. Jsou relativně novým prostředkem pro grafické modelování. Jejich síla je v dost široké grafické notaci, která umožňuje jednoduše zobrazit prvky hůře zobrazitelné v jiných diagramech. Jako příklad bych uvedl prvky pro modelování událostí spojených
18/34
s objekty včetně věcí jako je zobrazení způsobu zpracování výjimky nebo storno operace v případě neúspěšného procesu.
Ve spojení s BPMN notací pro zápis obchodních procesů se hovoří o možnosti
transformovat BPMN diagram přímo na BPEL (Business Process Execution Language) jazyk, který je spustitelný v rámci procesních enginů. Tato technologie je prozatím ve vývoji. Samotný jazyk BPMN se ale pravděpodobně dočká široké implementace ve vývojových nástrojích a je to technologie, která se brzo rozšíří mezi uživatele.
11. Diagramy tvo ř ené bez specifické notace
Často je potřeba vytvořit model, který je hlavně o grafické notaci a není řízen specifickou notací. Není potřeba se bránit použití takových nástrojů, pokud je jejich použití na místě. Klasickým případem prostředku, který takovéto modelování umožňuje, je Microsoft Visio.
Někdy jsou diagramy takto tvořené velmi přínosné a přehledné z hlediska zobrazení diagramů jako jsou například síťový diagram nebo tok řízení v aplikaci na vysoké úrovni. Sice často lze použít pro přibližné zobrazení diagram, který je například součástí UML, ale použití volnějších výrazových prostředků umožňuje lepší předání informace, kterou chceme s uživatelem
komunikovat.
12. Dokumentace pro p ř edání aplikace do provozu, praktická ukázka
12.1. Krátké p ř edstavení systému NESA
Systém NESA byl vyvinut jako nástupce systému ESA. Jeho primární cíl byla evidence vydávaných studentských a zaměstnaneckých průkazů. Tato funkcionalita byla časem rozšířena o řadu modulů a systém NESA dnes pokrývá řadu specifické funkcionality v rámci informačního systému VŠE. Funkcionalita poskytovaná systémem je dále popsaná pomocí diagramů užití.
Jako praktický příklad pro dokumentaci k systému pro jeho uvedení do provozu jsem zvolil tento systém, protože jsem se účastnil dlouhodobě na jeho vývoji až do podoby, kdy je jedním z klíčových back-end systémů provozovaných na VŠE
12.2. Popis architektury systému
Jádrem systému je databáze Sybase SQL Anywhere ve verzi 8 (někdy bývá tento produkt také nazýván jako Sybase Adaptive Server Anywhere). Základní aplikační architektura byla postavena na co nejširším využití možnosti mít aplikační logiku implementovanou jako uložené procedury na databázi a použití tlustého klienta pro prezentaci.
V rámci implementace specifických funkcionalit byl systém rozšířen o řadu knihoven podporujících nejrůznější funkcionality
- komunikace s čtečkami karet a specifickými zařízeními zakomponovanými do systému - komunikace se sítí Novell
- komunikace po síti přes HTTPS - komponenta pro XSLT transformace.
Z hlediska hardwarových zařízení, která jsou v systému používaná, jedná se o řadu technologií:
- čipové karty standardu Mifare 1KB - čtečky čipových karet a čárových kódů
- účtovací jednotky pro kopírky, zařízení dodávané na zákázku - inverzní bankomat, zařízení dodávané na zakázku
12.3. Model napojení aplikace na stávajícího IS/ICT
Systém NESA je připojený na celou řadu dalších systémů provozovaných v rámci IS/ICT na VŠE. Do značné míry funguje jako platforma pro integraci dat z celé řady provozovaných
evidencí na VŠE.
NESA
Evidence zaměstnanců
VŠE
Jindřichův Hradec Studijní
Informační
Systém Menza VŠE
Evidence Zahraničních
Studentů Dopravní
podnik Hl. m.
Prahy
Evidence Doktorandů Přístupový
Systém
Telefonní seznam
jarovnet
Kolejní IS Studentské karty
Zaměstnanci
tuS
ed
tin
olaísČ
so b
Studenti JH
Osoby a karty
Studenti
Zahranič ní studenti Studenti
Doktorandi
Seznam osob Osoby a karty
Veverka.vse.cz Uživate
lská jména
studentů Vyvolávací
systém F3
Docházkový systém
Osoby a karty Stu
denti a k arty F3
1 Vazba systému NESA na další systémy
Klíčové pro aplikaci NESA jsou zdroje dat z evidencí spojených s osobami, což jsou:
- studijní informační systém
o data o studentech denního studia - evidence zaměstnanců
o kmenoví zaměstnanci
o pracovníci na dohodu o provedení práce - zahraniční studenti
o různé programy o mimořádní studenti - doktorandi
- studenti z Jindřichova Hradce
12.4. Popis implementované funkcionality
Implementovanou funkcionalitu v systému popisuje následující diagram případů užití.
20/34
uc UseCase Nesa
EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version
Pracov ník centra podpory uživ atelů
Pracov ník CIKS
prezenční v ýpůjčky půjčov ání klíčků od
skříněk
pracov ník v šatně
v ydání nov é karty
zneplatnění karty
statistiky osob v knihov ně zadání uživ atelského
j ména k osobě student
kontrola opráv něnosti při přihlášení do sítě platba tisku
platba kopírov ání
Pracov ník ÚOO
notifikace o přihlášení osoby
ev idence přihlášených osob
na počítači
rezerv ace počítačov ých místností pro v ýuku
tisk rozv rhů učeben
Pracov ník správ y počítačov ých učeben správ a ISIC/ITIC
licencí
Pracov ník správ y lokální sítě
kontrola ev idov aných uživ atelských j men
proti skutečnému stav u na síti Nov ell
administrátor dobití peněženky na
kartě
v ydání rev alidační známky
kontrola při průchodu do knihov ny
ev idence plateb spoj ených s kartami
půjčov ání anonymních čipov ých karet externí čtenář CIKS
založení účtu na síti pro externí čtenáře
import a export dat
získání seznamu karet a osob
pracov ník v menze
«incl ude»
2 Případy užití systému NESA
12.4.1. Popis jednotlivých p
řípad
ůužití
Následuje popis jednotlivých případů užití s funkcionalitou poskytovanou uživatelům systému NESA. Pokud není uvedeno jinak, je funkcionalita implementovaná v rámci NesaKlienta společně s DB Nesa.
12.4.1.1. Evidence plateb spojených s kartami
Systém obsahuje funkcionalitu pro evidenci a provádění plateb spojených s kartami. Jde jednak o platby za vydání nové karty, platby za revalidační známky a platby určené pro dobití elektronické peněženky na kartě. Pracovník centra podpory uživatelů používá tuto funkcionalitu k přehledu o počtu plateb, které provedl, studentovi je tištěna na termotiskárně stvrzenka o provedené platbě.
Evidence plateb implementuje mechanizmus dávek plateb, kdy na každém identifikovaném pracovišti je otevřená dávka plateb, do které se evidují probíhající platby. Obsluha má možnost dávku plateb uzavřít například na základě výměny pracovníka a je poskytovaná funkcionalita sumarizující finanční částky v rámci dané dávky plateb. Obsluha má možnost tisku přehledových sestav za jednotlivé dávky plateb, které dále slouží jako podklad pro účtárnu.
12.4.1.2. Správa ISIC/ITIC licencí
Pracovník centra podpory uživatelů, který má na starosti objednávání ISIC a ITIC licencí od dodavatele těchto licencí pro Českou republiku, má k dispozici funkcionalitu umožňující zjistit stav počtu volných licencí, odhadovaný počet potřebných licencí a možnost vkládat do systému nové licence, pokud dojde k jejich nákupu od dodavatele. Tyto licence jsou následně tištěné na karty ISIC a ITIC.
12.4.1.3. Vydání revalidační známky
V rámci procesu revalidace ISIC a ITIC licence je implementovaný systém objednávání revalidačních známek mimo systém NESA. Seznam uživatelských jmen s informací o objednání revalidační známky je dodán zvenčí a po zahájení distribuce revalidačních známek obsahuje systém NESA funkcionalitu pro evidenci plateb a vydávání revalidačních známek studentům.
12.4.1.4. Vydání nové karty
Systém umožňuje zpracovat požadavek na vydání a vytištění nové karty studentovi. Bližší popis procesu je uvedený v rámci popisu procesů, protože je to základní funkcionalita systému a obsahuje řadu na sebe navázaných kroků. Vydání karty je v prostředí NesaKlient a DB Nesa, samotný tisk probíhá pomocí softwarového nástroje IDWorks.
12.4.1.5. Zneplatnění karty
Je poskytovaná funkcionalita zneplatnění karty na základě vyžádání od studenta. Tímto lze bránit do určité míry zneužití karty, pokud došlo k její možné ztrátě. Tento mechanizmus se používá, pokud student si není jistý, zda kartu někde nenechal.
12.4.1.6. Dobití peněženky na kartě
Obsluha na základě přijmutí platby od studenta navýší částku uloženou v elektronické peněžence na kartě. Tyto prostředky může student použít pro placení tisku a kopírování na zařízeních na VŠE. Druhou možností dobití je použití „inverzního bankomatu“, který na základě přijmutí hotovosti provede stejnou operaci. Inverzní bankomat je jednoúčelové zařízení
instalované v prostorách školy. Tato služba je poskytovaná i například externím čtenářům knihovny, kteří využili možnosti zakoupení čipové karty.
12.4.1.7. Zadání uživatelského jména k osobě
Po zřízení účtu do počítačové sítě školy je potřeba zaevidovat k osobě toto uživatelské jméno. Pracovník má k dispozici funkcionalitu, která toto umožňuje. Jedná se o osoby, jejichž uživatelská jména nelze získat z jiné evidence.
12.4.1.8. Kontrola evidovaných uživatelských jmen proti skutečnému stavu na síti Novell
Administrátor aplikace má k dispozici funkcionalitu, která provede kontrolu shody evidovaných uživatelských jmen uživatelů proti skutečnému stavu na síti Novell. Tato funkcionalita je spouštěná na základě vyžádání od pracovníků Oddělení správy lokální sítě. Umožňuje odhalení například nestandardně zřízených uživatelských účtů a podobně. Tato funkcionalita je implementovaná pomocí externí knihovny integrované do DB Nesa, která provádí kontrolu sítě Novell.
12.4.1.9. Založení účtu na síti pro externí čtenáře
Systém umožňuje založit účet na síti Novell pro externí čtenáře knihovny, kteří jej mohou použít pro přístup na internet z dedikovaných strojů v prostorách knihovny. Funkcionalita je implementovaná pomocí externí knihovny integrované do DB Nesa.
22/34
12.4.1.10. Půjčování anonymních čipových karet
Externí čtenáři, kteří nevyužijí možnosti zakoupit čipový průkaz návštěvníka knihovny, ale přesto chtějí využít možnosti placeného kopírování na zařízení VŠE, mají možnost vypůjčení čipových karet určených pro tento účel.
12.4.1.11. Půjčování klíčků od skříněk
V prostorách CIKS a v prostorách šaten na JM je možnost zapůjčení klíčku od uzamykatelných skříněk. Systém poskytuje funkcionalitu podporující tyto zápůjčky.
12.4.1.12. Kontrola při průchodu do knihovny
Při průchodu do knihovny se vyžaduje protažení karty na vstupu i výstupu. Jednak toto slouží pro pracovníky CIKS pro ověření toho, že procházející student je oprávněn ke vstupu do knihovny, během ověření je provedena i kontrola, zda daná osoba má v pořádku věci jako jsou vrácené klíčky od šatních skříněk nebo prezenční výpůjčky a v neposlední řadě je provedený záznam do auditní tabulky, ze které se následně generují statistiky pro sledování vytíženosti knihoven během časového období.
12.4.1.13. Prezenční výpůjčky
Systém poskytuje funkcionalitu pro evidenci prezenčních výpůjček v rámci knihovny. Tyto výpůjčky jsou materiály, které student smí používat v rámci knihovny, ale nejsou půjčovány z prostor CIKS.
12.4.1.14. Statistiky osob v knihovně
Na základě protažení karty na vstupu a výstupu z knihovny systém generuje statistiky s počtem osob přítomných v knihovně během časového období. Tyto statistiky jsou posléze zpřístupněné ke stažení oprávněnému uživateli. Podklady pro statistiky jsou generované jednou denně z důvodu vysoké časové náročnosti.
12.4.1.15. Notifikace o přihlášení osoby
Je poskytovaná funkcionalita pro upozornění na přihlášení konkrétního uživatele na počítač v síti školy. Tato funkcionalita je používaná Útvarem obrany a ochrany pro umožnění
kontaktování osob, které jsou například podezřelé z kráděží v prostorách školy. Jsou implementované různé kanály pro notifikace, nejčastěji se používá email.
12.4.1.16. Evidence přihlášených osob na počítači
Každý uživatel přihlášený do sítě školy je evidován v rámci systému pro sledování sítě. Tyto informace jsou následně na základě vyžádání ÚOO zpřístupněny pro použití při řešení přestupků proti řádu školy, například krádeže osobních věcí studentů. Tento systém se dost osvědčil pro objasnění krádeží ve spolupráci s kamerovým systémem instalovaným na počítačových studovnách v prostorách školy.
Samotné sledování sítě je implementované oddělenou komponentou NesaSledovaniNovellu přistupující k síti školy a pouze zapisující do DB Nesa, kde jsou tyto záznamy dále
zpracovávané.
12.4.1.17. Platba tisku
Aplikace umožňuje provádění placeného tisk na vyhrazených tiskárnách ve škole. Platby jsou účtované proti elektronické peněžence uložené na čipové kartě studenta. Samotné účtování tisku je implementované pomocí knihovny rozšiřující program Station obsluhující dedikované tiskové fronty. Tato knihovna dokáže komunikovat s čipovou čtečkou, strhávat prostředky
