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
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