Návrh informačního systému pro správu VT pomocí UML

Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií

Návrh informačního systému pro správu VT pomocí UML Diplomová práce

Autor:

Bc. Vladimír Šimon Informační technologie a management

Vedoucí práce:

Doc. Ing. Bohumil Miniberger, CSc.

Odborný konzultant:

Ing. Jan Matyska

Praha

Červenec

2013

Prohlášení Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze

elektronických

vysokoškolských prací.

V Praze, dne 15. 7. 2013

Vladimír Šimon

Poděkování Rád bych zde poděkoval vedoucímu mé práce doc. Ing. Bohumilu Minibergerovi, CSc. za vedení práce, cenné rady a připomínky. Dále bych poděkoval Ing. Janu Matyskovi, jako mému odbornému konzultantovi za projevenou pomoc při řešení modelovaných situací. Děkuji také všem, kteří mi byli oporou v průběhu studia, zejména své rodině za trpělivost.

Anotace Tato diplomová práce se zabývá návrhem informačního systému pro podporu evidenci stavů výpočetní techniky. Stěţejní fází evidence je příprava objednávek či výzev ze smlouvy, následně pak zadání výpočetní techniky do systému a evidence jeho ţivotního cyklu ve firmě. V úvodních kapitolách jsou přiblíţeny principy a specifika návazností na firemní procesy, dále pak základní pojmy a principy modelování informačních systémů pomocí jazyka UML. V následujících kapitolách, práce popisuje samotnou analýzu a návrh informačního systému z funkčního, logického, dynamického pohledu a náhledu uţivatelského rozhraní. Výsledkem práce je model informačního systému, který můţe být podporou nejen při evidenci majetku, ale můţe slouţit i jako nástroj evidence nároků na techniku. Klíčová slova: informační systém, evidence majetku, model, modelování.

Annotation This diploma work describes the design of an information system supporting ICT environment registration. The key stage of recording is preparation of order forms or calls from the contract, subsequently entering bought equipment into computing system and registration of its life cycle in the company. The introductory chapter explains the principles and specifics linked to business processes, as well as basic concepts and principles of information systems modeling using UML. In the following chapters, there is description of the analysis and design of information system from the functional, logical, dynamic view and preview of the user interface. The output is a model of information system that can be used not only as the asset register, but can also serve as a tool for registering technological demands. Keywords: information system, asset management, model, modeling.

Obsah Úvod ........................................................................................................................................... 7 1

Základní principy modelování informačního systému ....................................................... 8 1.1

1.1.1

Klasifikace procesů .............................................................................................. 8

1.1.2

Struktura procesů .................................................................................................. 9

1.1.3

Popis procesu ...................................................................................................... 10

1.1.4

BPMN ................................................................................................................. 12

1.2 2

Modelování informačních systémů ............................................................................ 17

Modelování IS pomocí jazyka UML ................................................................................ 20 2.1

Úvod do UML ............................................................................................................ 20

2.2

Struktura jazyka UML ............................................................................................... 20

2.2.1

Předměty ............................................................................................................. 21

2.2.2

Relace ................................................................................................................. 22

2.2.3

Diagramy ............................................................................................................ 23

2.3

3

Procesní modelování ve firmě ..................................................................................... 8

Poţadavky .................................................................................................................. 26

2.3.1

Získávání poţadavků .......................................................................................... 27

2.3.2

Problém zjištění potřeb zákazníka ...................................................................... 27

2.3.3

Specifikace poţadavků na systém ...................................................................... 28

2.3.4

Non-funkční poţadavky ..................................................................................... 30

2.3.5

Funkční poţadavky ............................................................................................. 30

Analýza informačního systému pro správu výpočetní techniky ....................................... 32 3.1

Popis současného stavu .............................................................................................. 32

3.1.1

Nákup hardwaru ................................................................................................. 32

3.1.2

Instalace stanic a předání uţivateli ..................................................................... 33

3.1.3

Vyřazení výpočetní techniky z majetku ............................................................. 34

3.2

Model procesu............................................................................................................ 34

3.3

Určení poţadavků na navrhovaný systém.................................................................. 36 5

4

3.3.1

Poţadavky na vstupní data ................................................................................. 36

3.3.2

Poţadavky na přístupová oprávnění ................................................................... 37

3.3.3

Nefunkční poţadavky ......................................................................................... 37

3.3.4

Funkční poţadavky ............................................................................................. 38

Návrh implementace vybraného informačního systému .................................................. 39 4.1

Funkční model informačního systému ....................................................................... 40

4.1.1

Popis aktérů ........................................................................................................ 40

4.1.2

Popis podpůrných typových úloh ....................................................................... 41

4.1.3

Popis primárních typových úloh ......................................................................... 45

4.2

Logický model informačního systému....................................................................... 53

4.3

Uţivatelské rozhraní informačního systému .............................................................. 56

4.3.1

Návrh na platformě Java ..................................................................................... 56

4.3.2

Návrh pro systém SAP ....................................................................................... 57

Závěr ......................................................................................................................................... 60

6

Úvod Tato diplomová práce podává komplexním pohled na základní principy tvorby informačního systému pomocí modelovacího jazyka UML. Na toto téma diplomové práce mě přivedla skutečnost potřeby sjednocení a zlepšení evidence majetku ve firmě ČEPS, a.s., pro potřeby převodu výpočetní techniky mezi uţivateli, evidenci této techniky v různých stavech její ţivotnosti a tvorby objednávek. Pro evidenci majetku se vyuţívá ve společnosti software SAP, avšak pro různé tyto stavy techniky se vyuţívají excelovské tabulky, které mají určitou netransparentnost. Smyslem této diplomové práce je odstranit tyto excelovské tabulky a vytvořit přehledný a všem účastníkům dostupný datový zdroj. První dvě kapitoly reprezentují základy, na kterých bude tato práce stavět. V první kapitole diplomové práce bude seznámení s principy modelování informačních systému a základy procesního modelování s návazností na informační systém. Druhá kapitola poukazuje na teoretickou část popisující modelování informačního systému pomocí jazyka UML. V druhé praktické části bude provedena analýza současného stavu s nadefinováním potřeb na informační systém, dle předchozích kapitol a v poslední kapitole bude vytvořen samotný návrh informačního systému s ukázkou praktických výstupů.

7

1 Základní principy modelování informačního systému Cílem této kapitoly je přiblíţení problematiky modelování informačních systémů s návazností na podnikové procesy, které jsou nedílnou součástí jejich tvorby. V první části je stručně charakterizován samotný proces a z něj vycházející procesní řízení, základní principy a pojmy modelování firemních procesů (Business Process Modeling) a zejména základní pojmy a elementy notace Business Process Modeling Notation. V druhé části jsou obdobně přiblíţeny principy, pojmy a prvky modelování informačních systémů, z kterých bude tato práce v návrhové části vycházet.

1.1 Procesní modelování ve firmě Firemní proces je mnoţina na sebe navazujících činností, které z definovaných vstupů vytvářejí poţadovaný výstup, váţí na sebe zdroje (lidi, technologie, materiál, finance a čas) a mají měřitelné charakteristiky. Výsledkem firemního procesu je produkt, který je navrhován, vyráběn, prodáván, předáván. Proces musí být sluţbou, musí ho někdo uţívat a cílem kaţdého procesu je nabídnout zákazníkovi správný produkt nebo sluţbu. Tomuto cíli je nutno podřídit toky informací, práce, materiálu, organizační struktury firmy. [11]

Obrázek 1: Schéma procesu[7]

1.1.1 Klasifikace procesů Příklady moţného rozdělení procesů: hlavní (core process): vytváří přidanou hodnotu, za kterou platí externí zákazník, naplňují strategické cíle podniku podpůrné: poskytují sluţby pro základní procesy řídící: průřezové procesy, koordinující činnost ostatních procesů 8

Druhou moţností rozdělení procesů: obchodní podpůrné existenční / vývojové: zajišťující rozvoj organizace provozní: zajišťující chod organizace

1.1.2 Struktura procesů Firemní proces: komplexní firemní chování mnoţina k cíli vedoucích aktivit organizace, často realizovaných paralelně, bez vzájemné návaznosti Aktivita: jednotka chování firemního procesu soubor aktivit tvoří firemní proces aktivita můţe mít podobu: o sub-procesu o úlohy Sub-proces: část firemního procesu, která je vnitřně dostatečně sloţitá tak, ţe můţe být dále dekomponována soubor aktivit, které jsou zapouzdřeny uvnitř rodičovského prvku tak, ţe mohou být řízeny (vyvolány) jednou společnou událostí sub-proces končí dosaţením některého z definovaných stavů Úloha: elementární, dále nedělitelné firemní chování úkon, prováděný jedním aktérem, na jednom místě, v jednom čase, jako odezva na událost úloha přidává měřitelnou hodnotu a předává data/informace v konzistentním stavu

9

Obrázek 2: Dekompozice firemního chování [7]

Událost: impuls, který spouští firemní proces, aktivitu nebo úlohu události řídí chování celého prostředí Aktér: role nebo soubor rolí, které mají odpovědnost za proces, aktivitu nebo úlohu můţe být reprezentována osobou, skupinou osob, organizací, systémem můţe být externího nebo interního charakteru Workflow: popisuje návaznosti aktivit v rámci firemního procesu, můţe obsahovat jak úkoly, tak sub-procesy, které mohou být dále dekomponovány na další diagramy procesních vláken Procesní vlákno: specifická cesta skrz workflow, kdy workflow můţe být tvořeno i více vlákny

1.1.3 Popis procesu Proces a jeho průběh lze popsat: volným textem strukturovaným textem nebo formalizovanými tabulkami grafickým znázorněním Popis procesu volným textem nemá logickou strukturu, není přehledný a tudíţ ani vhodný pro prezentace, nelze provádět kontroly úplnosti informací a jejich konzistence. Velmi obtíţná je

10

téţ aktualizace popisu a je poplatná1 svému autorovi. Nevýhodou tohoto popisu je obtíţné čtení, porozumění a nesnadná analýza. Popis ve formě tabulky je strukturovaný v rámci jednoho typu tabulky. Tabulky však mívají různou strukturu, špatně se provádí analýza a navíc velké tabulky se stávají nepřehledné a problematicky se aktualizují. Grafické znázornění procesů za pomoci předdefinovaných grafických objektů umoţňuje jednoznačné a jasné znázornění. Průběhy jdou snadno analyzovat a vyhodnocovat, grafické znázornění je přehledné a snadněji porozumitelné. Úroveň popisu procesu závisí na poţadavku dekompozice procesu, co je potřeba s popisovaným procesem dělat a co o něm je potřeba vědět. Kaţdá podrobnější úroveň přebírá informace z vyšší úrovně. Nejniţší úroveň je výkonná a popisuje detailní činnosti a individuální výkonné role. Vyšší úrovně jsou přehledové a slouţící většinou pro potřeby řízení celkového přehledu a souvislostí probíhajících procesů. Příklad úrovní popisu procesu: První úroveň cíle procesu klíčové vstupy Druhá úroveň události aktivující daný proces role, vlastník procesu kvalitativní a kvantitativní metriky procesu omezující podmínky procesu Třetí úroveň výčet činností, které jsou součástí procesu seznam rolí podílejících se na procesu seznam všech externích vstupů a výstupů v průběhu procesu přehled softwarových aplikací Čtvrtá úroveň návaznost činností vstupy a výstupy kaţdé činnosti přiřazení rolí k jednotlivým činnostem Zdroje pro získávání informací pro popis procesu: 1

styl a přesnost popisu a způsob vyjadřování dané osoby

11

interní předpisy, směrnice, pracovní postupy, SLA závazné normy pohovory s výkonnými pracovníky, manaţery, pracovníky navazujících činností, zákazníky procesu cílené dotazníky analýzy výstupů relevantních dřívějších projektů data a informace z IT systémů vlastní šetření a přímá měření kvalifikované odhady benchmarking referenční modely

1.1.4 BPMN BPMN (Business Process Modeling Notation) je moderní soubor principů a pravidel pro modelování firemních procesů pomocí grafického znázornění procesních diagramů (BPD). V současné době existuje několik soupeřících standardů, které vyuţívají nástroje pro modelování podnikových procesů. Rozšiřování jazyka BPMN pomáhá sjednocovat významy základních pojmů pouţívaných v oblasti podnikových procesů (například veřejné B2B a soukromé procesy) a stejně tak pomáhá v rozšiřování pokročilých procesních konceptů. Procesní diagramy vycházejí z konceptu Petriho sítí. Jednotlivé diagramy si lze představit jako spojité grafy, skládající se z aktivit a přechodů. Přechody jsou spojeny s podmínkami a tím je řízen průchod grafem. Notace obsahuje 4 základní skupiny elementů: Flow objects – Tokové objekty Events – Události Activities – Aktivity / Činnosti Gateways – Brány Connecting objects – Spojovací objekty Sequence flow – Sekvenční tok Message flow – Tok zpráv Association – Asociace Swim lanes – Plavecké dráhy Pool – Bazény 12

Lane – Dráhy Artefacts – Artefakty Data object – Datové objekty Group – Skupiny Text annotation – Textové popisy

Obrázek 3: Základní skupiny elementů BPMN [4]

Flow objects – Tokové objekty: Events – Události: Události jsou znázorňovány kruhem představující děj, který má přímý vliv na chod procesu. V kruhu se mohou zobrazovat různé ikony, které představují různé typy událostí. Události lze také charakterizovat jako „Catching”, například přijetí zprávy, která spustí proces nebo je také lze charakterizovat jako „Throwing”, například odeslání zprávy o dokončení, která ukončí proces. Události se rozlišují na počáteční, průběţné a konečné. Počáteční událost: (Start) Představuje spouštěč procesů, je zobrazována kruhem s

Obrázek 4: Příklady událostí [4]

jednoduchým okrajem. Muţe být typu „Catch“ a poté se zobrazuje s vloţenou ikonou. Existují tyto počáteční událostí: none, message, timer, rule, link, signal, multiple. Průběžná událost: (Intermediate) 13

Představuje událost, která se děje mezi počáteční a konečnou událostí. Označuje se kruhem s dvojitým okrajem a můţe být typu „Throw“ nebo „Catch“. Lze rozlišit tyto typy: message, rule, timer, signal, link, multiple, error, compensation, cancel. Konečná událost: (End) Představuje výsledek procesu, je označována kruhem s tučným okrajem. Můţe být typu „Throw“ coţ je znázorněno vloţením tučné ikony. Opět lze rozlišit několik typů: message, error, cancel, compensation, link, multiple, terminate. Message / Timer: nejběţnější spouštěče událostí, které představují výskyt zprávy mezi aktivitami nebo časový okamţik. Error: událost je vyvolána pojmenovanou chybou, v reakci na událost by měla být spuštěna obsluţná aktivita. Cancel: se vyuţívá v transakčních sub-procesech na modelování situace, kdy byla transakce zrušena. Compensation: se vyuţívá v transakcích pro modelování události „undo“ – tj. k návratu k předchozímu stavu vstupních dat aktivity. Rule: událost je vyvolána při splnění určité podmínky. Link: je to mechanismus propojení dvou částí diagramu, namísto „sequence flow“ pokud by byla příliš dlouhá nebo by se musela kříţit s jinou. Vyuţívá se k zpřehlednění diagramu. Signal: je událost, která nemá určeno, kterému procesu je zasílána. Dozví se o ní kaţdá aktivita v hierarchické úrovni procesu. Terminate: událost, která provádí bezpečnostní ukončení všech aktivit uvnitř procesu. Multiple: znamená, ţe existuje více způsobů, jak vyvolat aktivitu, ale pouze jedna z nich je k vyvolání potřeba. Jednotlivé způsoby jsou u události slovně popsány. Activities – Aktivity / Činnosti Tyto prvky představují činnosti, které se odehrávají uvnitř procesu. Zobrazují se pomocí obdélníku se zaoblenými rohy. Rozlišují aktivity podproces a úloha. Sub-process – Podproces Pouţívá se pro skrytí dalších úrovní podnikových procesů, u částí procesu, u kterých nechceme, aby byly v dané úrovni znázorněny. Podproces se označuje znaménkem plus u spodního okraje obdélníku se zaoblenými rohy. Po kliknutí na znaménko plus se zobrazí

14

všechny části skrytého podprocesu. Podproces má vlastní počáteční i konečnou událost a sekvenční toky přicházející z vyšší úrovně procesu. Task – Úlohy Jde o druh podprocesu, ve kterém se nahlíţí na všechny zahrnuté činnosti jako na celek, tudíţ je dále nedělitelný. Aby bylo dosaţeno cíle, musí být všechny zahrnuté činnosti dokončeny,

Obrázek 5: Aktivity a jejich instance [7]

a pokud některá zahrnutá činnost z nějakého důvodu není dokončena, musí být všechny činnosti provedeny znovu. Úlohy se znázorňují na rozdíl od podprocesů pouze obdélníkem se zaoblenými rohy. U obou těchto prvků se můţeme setkat s instancemi loop, multiple, compensation a u subprocesů navíc ještě s instancí ad-hoc. Loop: představuje aktivitu, která se cyklicky opakuje v sekvenčním sledu. Po kaţdém dokončení aktivity se vyhodnotí podmínka opakování a případně se spustí znovu. V daném okamţiku je spuštěn pouze jeden výskyt této aktivity. Multiple: představuje aktivitu, která v daném okamţiku můţe mít více výskytů. Dle definované podmínky se paralelně spustí více výskytů aktivity, coţ je však také moţné pouze je v daný okamţik k dispozici i více zdrojů k realizaci dané aktivity. Compensation: představuje aktivitu, která vrací data do vstupních hodnot v případě zrušení provázané aktivity, nebo také nemusí provést nic, pokud se systém nenachází v nekonzistentním stavu. Ad-hoc: představuje aktivitu, u níţ v okamţiku modelování není jasné pořadí a frekvence opakování vnitřních aktivit. V kaţdém výskytu takovéto aktivity můţe být různé pořadí vnitřních aktivit. Aktivita je ukončena aţ po provedení všech vnitřních aktivit. Gateways – Brány Brány umoţňují větvení a slučování toků nebo procesů v závislosti na uvedených podmínkách. Znázorňují se pomocí kosočtverce. Brány se dají rozdělit na další typy. Níţe jsou uvedeny vybrané typy. Exclusive - Exkluzivní

15

Exkluzivní brána vytváří několik cest toku procesu, ale podmínkou je, ţe tok procesu proběhne pouze jednou z moţných cest. Představuje logický XOR. Inclusive - Inkluzivní Pouţití inkluzivních bran je vhodné tam, kde tok procesu můţe projít přes bránu více neţ jednou cestou. Po projití brány se většinou všechny cesty opět sloučí do jedné. Představuje logický OR. Complex - Komplexní Komplexní brána popisuje najednou více jednoduchých podmínek, které se sloţí do jednoho rozhodovacího bodu. Parallel - Paralelní

Obrázek 6: Typy bran [4]

Tento typ bran se pouţívá v případě, kdy tok procesu proudí více cestami najednou. Představuje logický AND. Connecting objects – Spojovací objekty: Sequence flow – Sekvenční tok Pomocí sekvenčního toku znázorňujeme posloupnost procesních toků. Zdrojem a cílem je vţdy aktivita, událost nebo brána. Sekvenční tok nesmí přesahovat hranice bazénu ani podprocesu. Sekvenční tok je znázorňován plnou čarou, která je zakončena šipkou ve směru běhu procesu. Sekvenční tok můţe mít také na začátku zobrazen kosočtverec, který zobrazuje podmíněný tok z činnosti, pokud je sekvenční tok zobrazen se zpětným lomítkem, označuje to standardní tok, který směřuje od rozhodování nebo od činnosti s podmíněnými toky. Message flow – Tok zpráv Tok zpráv nám říká, jaké zprávy proudí přes hranice bazénů, lze ho vyuţít pro komunikaci v rámci dvou a více bazénů, tudíţ ho nelze pouţít k propojení činností uvnitř jednoho bazénu. Tok zpráv se znázorňuje přerušovanou linií, která má na počátku kruh a na konci šipku ukazující směr běhu procesu. Association – Asociace Asociace má dva významy. Popisuje čtení / zápis dat aktivitou z / do datového objektu, kde směr šipky určuje, zda jde o čtení či zápis. Nebo definuje obecný vztah mezi elementem

16

diagramu a jeho popisem, nebo jiným prvkem, který není přímo součástí toku aktivit. Zde se pouţívá asociace bez určeného směru. [3] Swiming lanes – Plavecké dráhy: Plavecké dráhy slouţí k organizování a kategorizaci činností. Lze rozlišit dva typy bazén a dráhu. Pool - Bazén Bazén je hlavním prvkem procesu a odděluje různé části organizace. Bazén má jednu nebo více drah, jako skutečný bazén a můţe být tzv. otevřený, kdy ukazuje vnitřní detaily a zobrazuje se jako obdélník s dráhami nebo jako tzv. zhroucený, kdy naopak skrývá detaily a zobrazuje se jako prázdný obdélník bez drah. V diagramu můţe být umístěn na šířku nebo na výšku. Lane - Dráha Dráhy se vyuţívají k organizaci a kategorizaci činností uvnitř bazénu na základě funkcí nebo rolí, jde o podmnoţinu bazénu. Jsou zobrazovány jako obdélníky kopírující šířku bazénu. Dráhy obsahují tokové objekty spojené s dalšími objekty a artefakty. Artifacts – Artefakty: Artefakty umoţňují vývojářům přidat další informace do modelu, díky tomu je model čitelnější. Lze vyuţít třech předdefinovaných artefaktů: Data objects – Datové objekty Datové objekty ukazují, která data jsou nezbytná pro vykonání dané činnosti. Group – Skupiny Skupiny se vyuţívají k seskupení různých aktivit, bez vlivu na samotný tok diagramu a mohou překračovat hranice bazénu. Prvek se znázorňuje obdélníkem se zaoblenými rohy a přerušovaným okrajem. Annotation – Anotace Anotace celému diagramu dodávají srozumitelnost a přehlednost a mají charakter textové informace pro čtenáře modelu. [3]

1.2 Modelování informačních systémů Modelování je snaha popsat reálně existující nebo nově vznikající informační systém ve zjednodušené podobě. Je to také vyjádření různých pohledů na informační systém standardizovanými, formalizovanými výrazovými prostředky. 17

Hlavním důvodem projektování informačních systémů představuje analýzu potřeb zákazníka, prostřednictvím poznání jeho firemních procesů a jejich zefektivnění, následný návrh systému, který umoţní účelně organizovat datovou základnu firmy, sledovat, ukládat a interpretovat co nejobjektivnější obraz o stavu a vývoji firmy. Z informací dále získávat znalosti a zpětně působit na chování firmy ţádoucím směrem. Vlivem informačního systému hodnota informací vzrůstá, proto informační systém by měl být vţdy prostředkem k získání nové hodnoty a neměl by být samoúčelný. Významem modelování je moţnost obsáhnout i velmi rozsáhlé systémy díky abstrakci nedůleţitých prvků a snadná změna s nízkými náklady oproti změně jiţ reálného systému. Modelování softwaru je tvorba obrazu budoucího systému, která má za účel jeho úplné pochopení všemi účastníky před samotnou realizací. Usnadnění komunikace v realizačním týmu a se zákazníkem, přehled o aktuálním stavu projektu a generování částí / prototypů výsledného produktu. [9] Principy modelování Abstrakce – umoţní odstínění v danou chvíli nedůleţitých charakteristik reality od charakteristik vznikajícího softwarového systému Formalizace – umoţní efektivní komunikaci v rámci vývojového týmu i komunikaci vzhledem k zákazníkovi Jednoznačnost – díky formalizaci je moţné jednoznačně identifikovat a popsat kaţdý prvek systému (data, funkce…) Zamezení redundancím – modelování by mělo zamezit existenci dvojího, vzájemně rozporného tvrzení Princip tří architektur Je nejobecnější přístup k modelování, zaloţen na logickém oddělení jednotlivých úrovní návrhu do tří fází, ve kterých jsou vyuţívány různé úrovně abstrakce, logiku a hloubku popisu. V první fázi vzniká konceptuální model, který je zaměřen pouze na obsah informačního systému. Není zatíţený technologickými řešeními ani implementačními nároky a je tudíţ nejvyšší mírou abstrakce. Jde o obecný model, který analytickými postupy určuje, co je obsahem systému. Odpovídá na otázku „Co se má řešit“? Ve druhé fázi navazuje technologický popis systému, který zohledňuje technologické řešení implementace obsahu jako je například: zda budou data organizována v souborech, relační 18

databázi, či zda bude vyuţívána architektura klient/server, apod. Odpovídá na otázku „Jak se má řešit“? Ve třetí fázi návrhu systému vzniká fyzický model, který vychází z technologického a musí tedy respektovat jak pouţité obsahové, tak technologické vlastnosti. Definuje implementační specifika návrhu, jaké vývojové prostředí bude pouţito, konkrétní databázový systém, programovací jazyk, tudíţ odpovídá na otázku „Čím se má řešit“? Tak postupně vzniknou tři modely informačního systému, které na sebe navzájem navazují. Ze specifikace obsahu systému vyplývají moţnosti technologického řešení a konkrétní pouţitá technologie určuje implementační moţnosti. Kaţdá ze tří úrovní definuje specifickou architekturu a má svou specifickou logiku a předmět zájmu, proto také vyţaduje vlastní nástroje a pravidla popisu. Informační systém navrhovaný v souladu s principem tří architektur má jisté vlastnosti, kterých lze s výhodou vyuţít. Hlavním důvodem pouţití tohoto přístupu k návrhu IS je nezávislost jednotlivých modelů. Konceptuální model je nezávislý jak na technologické struktuře systému, tak na implementačním prostředí a technologický model je nezávislý na niţší, fyzické úrovni. Tím je dáno, ţe pro jeden konceptuální model můţe existovat řada řešení v různých technologických prostředích a analogicky v rámci jednoho technologického prostředí můţe existovat řada implementací (fyzických modelů). Na druhou stranu jakékoliv změny implementačního prostředí se netýkají ani obsahové ani technologické úrovně a jakékoliv změny technologického modelu se netýkají konceptuálního obsahu systému, ale uţ se musí projevit v implementačním řešení. Stejně tak změny v konceptuálním modelu se musí v plné míře promítnout jak do technologického řešení, tak do implementace. Z toho vyplývá poţadavek na správné identifikování původu změny, zda jde o změnu implementační, technologickou nebo konceptuální, a teprve poté lze přistoupit k její realizaci. Ignorování původu změn a jejich zavádění, můţe velmi rychle vést k nízké udrţovatelnosti informačního systému. [5]

19

2 Modelování IS pomocí jazyka UML Cílem této kapitoly je přiblíţení problematiky modelování pomocí jazyka UML a jeho vyuţití v praxi. Budou zde přiblíţeny základní stavební kameny jazyka UML, včetně diagramů v první části a ve druhé části budou přiblíţeny metody získávání poţadavků na informační systém.

2.1 Úvod do UML Jazyk UML (Unified Modeling Language – unifikovaný modelovací jazyk) je univerzální modelovací jazyk pro vizuální modelování softwarových systémů. Přestoţe je často spojován s objektově orientovaným modelováním, má mnohem širší vyuţití, coţ vyplývá z jeho zabudovaných rozšiřovacích mechanismů. Jazyk byl navrţen tak, aby spojil nejlepší existující postupy modelovacích technik a softwarového inţenýrství. Je navrţen takovým způsobem, aby ho mohly implementovat nejrůznější nástroje CASE (Computer-aided software engineering, počítačem podporované softwarové inţenýrství), včetně návazných programovacích jazyků. Zmíněná koncepce vychází z pochopení skutečnosti, ţe se rozsáhlé softwarové systémy obvykle bez podpory nástrojů CASE neobejdou. Diagramy vytvořené v tomto jazyku jsou jednak srozumitelné pro lidi, ale navíc je mohou snadno interpretovat i programy CASE. Jazyk UML však nenabízí ţádný druh metodiky modelování, i kdyţ určité aspekty metodiky můţeme najít v kaţdém z prvků, z nichţ se model UML skládá. Samotný jazyk UML, však poskytuje pouze vizuální syntaxi, kterou můţeme vyuţít při sestavování modelů. UML nabízí standardní postup pro psaní návrhů systémů, včetně konceptuálních součástí, jako jsou obchodní procesy a systémové funkce, stejně jako konkrétních součástí, jako jsou příkazy programovacího jazyka, schémata databází a znovupouţitelné součásti softwaru. UML je navrţeno natolik rozsáhle, ţe jím lze modelovat či dokumentovat prakticky jakýkoliv informační systém.

2.2 Struktura jazyka UML Struktura jazyka UML obsahuje tyto součásti: Stavební bloky – jsou to základní prvky modelu, relace a diagramy Společné mechanismy – obecné způsoby, jimiţ v jazyku UML je dosaţeno specifických cílů 20

Architektura – pohled v jazyku UML na architekturu navrhovaného systému Podle definice (Pavel Tišňovský, 2005) Celý jazyk UML je založený na třech elementech, které ale nejsou z uživatelského hlediska reprezentovány v textové podobě, ale grafickými značkami v plošném (tj. dvourozměrném) grafu. Tyto tři základní elementy jazyka UML se dle své funkce nazývají:[12] Předměty – jsou samotné prvky modelu Vztahy (Relace) – jsou pojítkem mezi předměty, určují jak spolu dva nebo více předmětů významově souvisí Diagramy – jsou to pohledy na modely UML, ukazují kolekce předmětů a jsou způsobem vizualizace toho, co systém bude dělat a jak to bude dělat

2.2.1 Předměty Předměty jsou elementy zpracovávaného modelu, jeţ jsou následně členěny do několika navzájem rozdílných podkategorií. Prvním typem podkategorií jsou takzvané strukturní abstrakce UML modelu, například programové třídy, aplikační či objektové rozhraní, případy uţití, komponenty či uzly. V diagramu UML jsou strukturní abstrakce zobrazeny jako různé převáţně plošné tvary, které jsou však vţdy uzavřené. Například se jedná o obdélníky, elipsy, kruţnice či jednoduché zdánlivě trojrozměrné tvary, například krychle či kvádry. Kaţdý smysluplný UML diagram by měl obsahovat alespoň dvě strukturní abstrakce, při jedné abstrakci totiţ modelování ztrácí svůj hlavní smysl – popis vztahů mezi jednotlivými objekty. Kromě strukturních abstrakcí patří mezi předměty i takzvaná chování, která v UML diagramu prezentují interakce, tj. vzájemné komunikace mezi jednotlivými objekty. Pomocí chování lze také modelovat stavový stroj, u nějţ se stavy specifikují pomocí přechodů, událostí a aktivit. Chování se v UML diagramu většinou vyznačuje pomocí různým způsobem konstruovaných a různě zakončených šipek či propojovacích čar. Mezi předměty patří i takzvané seskupení, které podle potřeby modelu graficky seskupuje části diagramu na niţší úrovni. Většinou se jedná o takzvané balíčky, jeţ mají tvar stylizované kancelářské sloţky s popisem umístěným v levé horní části obdélníku (zobrazení seskupení se však můţe v různých prostředích odlišovat). Seskupení nejsou v současné době v některých dále popisovaných aplikacích pouţitelná (tj. nelze vytvářet hierarchické diagramy), coţ je pro tvorbu rozsáhlejších grafů velké omezení.

21

Posledním a současně velmi jednoduchým typem předmětů jsou poznámky, které blíţe specifikují vlastnosti a chování dalších elementů UML diagramu. Graficky jsou poznámky na prakticky všech typech UML diagramů většinou vyvedeny ţlutě vyplněným obdélníkem s ohnutým roţkem.

2.2.2 Relace Vzhledem k tomu, ţe v grafech je zapotřebí předměty různým způsobem navzájem propojovat, jsou v jazyku UML specifikovány i relace, tj. vztahy mezi různými předměty. V UML jsou rozeznávány následující podtypy relací (z čistě jazykového hlediska patří relace mezi základní elementy UML): Asociace – pomocí asociací se modeluje obecná souvislost předmětů, která je však v diagramu UML přesným způsobem definovaná. Speciální variantou asociace jsou takzvané kompozice a agregace, které jsou často pouţívány v objektově orientovaných jazycích a návrzích databází. Závislost – pouţije se, pokud změna v jednom předmětu způsobí změnu v předmětu jiném, nebo mu známým způsobem poskytne poţadovanou informaci. Generalizace – pomocí generalizace se modeluje stav, kdy je jeden předmět specializací jiného předmětu. Tato relace je velmi často pouţívána v objektově orientovaných jazycích, implementuje se většinou pomocí dědičnosti (inheritance). Realizace – jedná se o druh vztahu, ve kterém jeden předmět představuje dohodu, za jejíţ splnění je odpovědný jiný předmět. V objektově orientovaných jazycích se realizace vytváří pomocí rozhraní (interface) – samozřejmě za předpokladu, ţe daný OOP jazyk rozhraní podporuje. [12]

Obrázek 7: Typy relací [1]

22

2.2.3 Diagramy Diagramy zachycují různé aspekty modelovaného systému, který nemusí být obecně vyjádřen pouze jedním UML diagramem, protoţe je moţné například pomocí balíčků (packages) sdruţovat více diagramů do jednoho hierarchicky organizovaného celku. Různých typů diagramů existuje velké mnoţství, například diagram případů pouţití, diagram tříd, diagram objektů, diagram komponent, diagram nasazení, diagram aktivit, stavový diagram, diagram spolupráce a sekvenční diagram. Kaţdý z výše vyjmenovaných typů diagramů obsahuje poněkud odlišný repertoár dostupných grafických značek (předmětů a relací). Diagram tříd Diagramy tříd (class diagrams) popisují statickou strukturu systému, znázorňují datový model systému od konceptuální úrovně aţ po implementaci. Diagramy tříd patří bezesporu k nejčastěji pouţívaným nástrojům UML a tvoří vůbec jakýsi základ všech prostředků objektové analýzy a designu. Tyto diagramy jsou většinou vytvářeny jiţ ve fázi analýzy často jako pojmové modely, jejichţ úkolem je formálněji definovat jednotlivé termíny pouţívané ve studované problémové oblasti. Takové modely jsou maximálně přínosné a uţitečné v okamţiku, kdy je nutno zpětně vstřebat terminologii oboru. S postupným přibliţováním k fázi implementace jsou diagramy tříd poměrně zásadně přehodnocovány a v ideálním případě zpracovávány aţ do podoby grafického modelu ekvivalentního zdrojového kódu. Diagramy tříd zobrazují statickou stránku systému, především vztahy mezi třídami. UML explicitně rozlišuje několik druhů tříd, stejně jako rozličné mnoţství vztahů, které jednotlivé třídy navzájem pojí (asociace, agregace, kompozice, specializace/generalizace). Tvorba diagramů tříd patří mezi klíčové problémy a zcela váţně lze prohlásit, ţe zvládnout objektový přístup často znamená správně vyuţívat právě tento typ diagramů pouţívaný průběţně napříč celým ţivotním cyklem tvorby IS. Zvláště při tvorbě těchto diagramů se doporučuje dodrţovat nepsané pravidlo 7 + 2, které říká, ţe v jednom diagramu je vhodné zobrazit 7, maximálně aţ 9 tříd. [6] Diagram případů užití Diagram případů uţití (use case diagram) je určen k vymezení hranic systému dynamickým pohledem, který je znám pod celou řadou dalších názvů jako například diagram typových úloh, jednání atp. Tento diagram, zobrazuje základní vztah systému k jeho okolí, tzv. aktérům. Aktéři jsou nejčastěji samotní uţivatelé systému, nicméně mohou jimi býti obecně libovolní externí činitelé stojící mimo modelovaný systém. Můţe se tedy jednat například o další HW s 23

SW prostředky, jiné IS, se kterými má nový IS spolupracovat. Kaţdý případ uţití pak představuje jeden z moţných způsobů pouţití systému, jednu z moţných cest komunikace aktér - systém. Konkrétním případem uţití můţe být například pouţití systému za účelem zjištění aktuálního stavu skladových zásob nebo zpracování faktury. Jednoduše řečeno, případy uţití simulují pouţití reálného systému externími aktéry. V rámci tvorby těchto diagramů modelujeme vztah systému a jeho okolí, nikoliv vzájemnou interakci, tj. způsob, jakými jsou jednotlivé případy uţití zajištěny interními funkcemi systému. Největší úskalí při pouţívání tohoto prostředku spočívá v odhadnutí "správné úrovně abstrakce". Občas se můţe stát, ţe jsou případy uţití moc obecné a nelze s nimi bez patřičné podrobnosti efektivně pracovat. Na druhou stranu je nutné vyvarovat se druhého extrému, kterým je zneuţívání tohoto nástroje pro funkcionální rozklad, který nemá s „Use Case modelováním“ nic společného! Praxe ukazuje, ţe z hlediska pouţívání UML je zvládnutí tvorby těchto modelů jedním z nejobtíţnějších úkolů, který navíc díky své povaze výraznou měrou ovlivňuje podobu výsledného produktu. Přestoţe je pomocí tohoto prostředku moţné rozdělit systém na dílčí oblasti, není tento prostředek určený na komplexní modelování architektury. Snad více neţ kde jinde je v tomto typu modelu nutno zvolit správný konsenzus mezi úplností a přehledností. Ve spojení s dalšími prostředky pro dynamické modelování je tvorba diagramů případů uţití fundamentálním prostředkem pro nalezení objektů participujících v modelovaném systému. Rozdělení celého systému na jednotlivé případy uţití přináší kromě vymezení hranic systému i moţnost zpracovávat jednotlivé případy uţití odděleně a částečně tak realizovat iterativní přírůstkový ţivotní cyklus. Skrze tvorbu případů uţití jsou samozřejmě definovány i základní uţivatelské poţadavky. [6] Sekvenční diagram Sekvenční diagramy (sequence diagrams) popisují scénář průběhu určité činnosti v systému. Vytvářejí se většinou přímo z diagramů případů uţití. K jednomu případu uţití můţe existovat několik sekvenčních diagramů, které modelují interakci objektů v rámci komunikace aktora se systémem. Jak je docela zřejmé, sekvenční diagramy jsou zaměřeny výhradně na dynamickou stránku systému. Jsou vhodné pro nalezení jednotlivých objektů a zobrazení komunikace mezi nimi.

24

Diagram spolupráce Diagramy spolupráce (collaboration diagrams) zachycují komunikaci spolupracujících objektů. Chceme-li v jednom diagramu znázornit jak strukturu objektů (například skládání objektů) tak i jejich dynamické chování, pouţijeme s výhodou diagramů spolupráce, které jsou vedle sekvenčních diagramů dalším prostředkem, jehoţ těţiště tkví v modelování dynamiky. Na rozdíl od sekvenčních diagramů je však znatelně obtíţnější vysledovat návaznost jednotlivých posílaných zpráv zajišťujících samotnou funkcionalitu systému. Zatímco v sekvenčních diagramech je tato návaznost zřejmá z vertikálního uspořádání celého diagramu, v diagramech spolupráce je následnost zobrazena pořadovým číslem, kterým jsou zprávy uvozeny. Tvorba diagramu spolupráce by měla být v souladu s diagramem tříd. Pro zachování vzájemné konzistence modelů je nezbytné dodrţovat základní pravidla, která mezi těmito modely platí. Komunikace mezi objekty musí být například podmíněna existencí odpovídající vazby mezi jejich třídami, o existenci patřičných tříd nemluvě. Nemusíme asi ani zdůrazňovat, jak nevděčnou prací je "ruční" kontrolování obdobných pravidel. Je jasné, ţe zde mohou opět pomoci CASE nástroje. [6] Stavový diagram Stavové diagramy (state chart diagrams) popisují dynamické chování objektu nebo systému, moţné stavy a přechody mezi nimi. Diagram stavů a přechodů, jak je někdy tento prostředek nazýván, slouţí pro modelování ţivotního cyklu části systému svým rozsahem odpovídající jednomu objektu. Přechod mezi jednotlivými stavy bývá vyvolán podnětem z vnějšího okolí, nejčastěji ve formě zprávy zaslané příslušnému objektu nebo jinou externí událostí. Diagram aktivit Diagramy aktivit (activity diagrams) popisují průběh aktivit procesu či činnosti. Jako jistou obdobu stavových diagramů můţeme chápat i diagramy aktivit, kde jednotlivými stavy rozumíme aktivity, a přechod mezi aktivitami je vyvolán dokončením aktivity stávající. Diagram aktivit se zpravidla vztahuje k jednomu případu uţití, případně k jedné metodě objektu. Pomocí diagramu aktivit modelujeme tentokrát dynamický tok řízený nikoliv vnějšími událostmi ale interními podněty. [6] 25

Diagram komponent Diagramy komponent (component diagrams) popisují rozdělení výsledného systému na funkční celky (komponenty) a definují náplň jednotlivých komponent. Jeho pomocí se vizualizují vztahy mezi jednotlivými SW komponentami, které mohou být ve formě zdrojových souborů, hotových spustitelných částí nebo pouze hlavičkových souborů. Mezi jednotlivými komponentami můţe existovat pouze jeden druh vazby a tou je závislost. Je moţné zobrazovat například návaznost zdrojových a hlavičkových souborů nebo zdrojových souborů tvořící knihovnu tříd. Diagram nasazení Diagramy nasazení (deployment diagrams) popisují umístění funkčních celků (komponent) na výpočetní uzly informačního systému. Diagram nasazení je druhým typem diagramů určených pro implementační fáze. Jeho úkolem je především zobrazit vztahy mezi částmi systému tak, jak vypadají v době samotného vykonávání. Diagramy nasazení zobrazují rozloţení jednotlivých SW komponent na HW zdrojích a jejich spolupráci, rozmístění HW a SW prostředků v lokalitách, topologie pouţívaných sítí, druhy a vyuţití komunikačních prostředků atp.

2.3 Požadavky Inţenýrství poţadavků (requirements engineering) je termín, který je pouţívaný k popisu aktivit zapojených do zjišťování, dokumentování a údrţby mnoţiny poţadavků na softwarový systém. Nedostatečně specifikované poţadavky a nedostatečné zapojení uţivatelů jsou dvěma hlavními příčinami neúspěchu celkového projektu. Jelikoţ je softwarový systém zaloţen na mnoţině poţadavků, je efektivní inţenýrství poţadavků klíčovým faktorem celého vývoje softwarového projektu. Poţadavky je vhodné rozdělit na funkční a nefunkční. Existuje mnoho dalších metod jejich kategorizace, ale v tomto dokumentu se budou pouţívat pouze tyto dvě kategorie. Funkční poţadavky definují CO má budoucí systém nabízet uţivatelům za sluţby, jeho chování. Mohou mít podobu výčtu poţadovaných funkcí nebo cílů, kterých chce zadavatel prostřednictvím IS dosáhnout. Non-funkční poţadavky jsou omezující podmínky uvalené na daný informační systém, které specifikují nebo spíše omezují způsob, jímţ se bude daný informační systém implementovat.

26

Jsou to například poţadavky na kvalitu, pouţité technologie, na organizaci projektu, na formu a obsah dokumentace apod.

2.3.1 Získávání požadavků Základem získávání poţadavků jsou interview s pověřenými zástupci zadavatele jakoţto budoucího uţivatele. Konzultace se všemi zúčastněnými je nejpřímější způsobem shromaţďování poţadavků. Obvykle je lepší vést konzultace a pohovory s jednotlivými zainteresovanými zvlášť. Na toto setkání je nutno si připravit seznam otázek, vše pečlivě poznamenat, nedělat výběr a nechat si podepsat výsledek jednání. Otázky by měli být bez kontextu, takové otázky, které by neměli podsouvat nebo předem předpokládat jakoukoliv odpověď, ale dotazovanou osobu stimulovat, aby se o problému rozpovídala. Příklad správné otázky: Kdo pouţívá tento systém ? – bez kontextu a povzbuzuje k diskuzi Příklad nesprávné otázky: Pouţíváte ten systém ? – jiţ předpokládá odpověď ano/ne a ukončuje diskuzi. Nedílnou součástí je také studium podnikových norem zákazníka pro návaznost na BPM a studium standardů problémové oblasti. Zvlášť důleţité jsou také i zkušenosti projektanta. Rovněţ prostředí, ve kterém je rozhovor veden, můţe mít velký vliv na kvalitu získaných informací. Proto se doporučují neformální rozhovory například v kavárně, jelikoţ toto prostředí navozuje uvolněnou otevřenější atmosféru. Nejlepšími pomůckami pro zachycení informací během rozhovoru jsou papír a pero. Psaní poznámek do notebooku vyrušuje a odvádí pozornost obou zúčastněných osob a v mnoha případech také můţe člověka poskytujícího informace i zastrašit. Po skončení rozhovoru se získané informace zanalyzují a výsledkem by měl být formální dokument oboustranně schválený a podepsaný.

2.3.2 Problém zjištění potřeb zákazníka Hlavním problémem při vytváření poţadavku je ucelit a vyjasnit představu zákazníka s pochopením problému projektantem a reálnými potřebami zákazníka a vytvořit souhrnný soupis poţadavků, který bude zohledňovat prolínání všech těchto pohledů.

27

Představa zákazníka

Pochopení

Reálné

problému

potřeby

projektantem

zákazníka

Obrázek 8: Problém zjištění potřeb zákazníka [10]

2.3.3 Specifikace požadavků na systém Specifikace poţadavků zákazníka (SPZ) je první fází návrhu informačního systému, kde je SPZ nástrojem poznání potřeb budoucího uţivatele systému. Mnohé společnosti nemají ucelenou představu o poţadavcích nebo o modelu poţadavků na systém. Software je specifikován jako jeden nebo několik neformálních dokumentů s poţadavky. Tyto poţadavky bývají často napsány v přirozeném jazyce a mají různé podoby. U všech dokumentů, které obsahují poţadavky se však musí klást otázka: Jaký přínos tyto poţadavky mají ? nebo Pomohou pochopit, co by systém měl dělat a co naopak by dělat neměl ? Proto při analýze poţadavků je nutno zohledňovat řadu faktorů: Zaměření věcných (podnikových) činností Okolí podniku Legislativu Strategické a podnikatelské plány Omezení zdrojů (personál, technické atd.) Technické změny Finanční omezení Termínová omezení Dále pokud ve firmě jiţ funguje nějaký IS, existuje riziko zkreslení nových poţadavků podle moţností starého systému či vyjadřovaní v pojmech tohoto starého IS. Proto je stále nutné 28

zjišťovat, co daný poţadavek umoţní uţivateli udělat, nebo čeho dosáhnout. Pokud lze stejného vyslednu dosáhnout i jiným řešením, je daný poţadavek příliš specifický a je zapotřebí jej zaměnit cílem vyšší úrovně. Původně stanovený poţadavek je ve skutečnosti moţným řešením a tak by měl být i zaznamenán. Mezi hlavní zásady specifikace poţadavků patří: Nepodceňovat ţádný poţadavek Rozlišovat mezi poţadavkem a způsobem řešení V kaţdém poţadavku stručně vyjmenovat vše co se v něm poţaduje Popsat kaţdý poţadavek – nedělat selekci Dát pozor na univerzální kvantifikátory – takové formulace je nutno důkladně prozkoumat: o všichni o kaţdý o vţdy o nikdo o nikdy o ţádný Nepouţívat technologické (uţivatelům nesrozumitelné) pojmy Snaţit se minimalizovat promítání vlastních představ do definic poţadavků Formalizovat výsledky SPZ Výsledkem formalizace musí být formalizovaný dokument se kterým musí být seznámeni všichni zúčastnění a musí být podepsán. Tento dokument poté tvoří „základnu“ celé stavby informačního systému. Zároveň je potřeba připravit mechanismy řízení změn ve specifikaci poţadavků, jelikoţ je téměř vyloučeno na počátku projektu úplně a přesně specifikovat všechny poţadavky. Z hlediska řízení projektu je důleţité vytvořit projektovou taxonomii poţadavků. Rozčlenit poţadavky dle priorit, termínů, typu apod. Po stanovení jednotlivých poţadavků by měla být provedena Analýza kritických požadavů (CRA) a stanovena Hiearchie kritických oblastí výkonnosti (CPA), která ukazuje ty hlavní činnosti, jejichţ výkonnost je rozhodující pro dosaţení cílů projektu podporující podnikatelské cíle společnosti. [10]

29

2.3.4 Non-funkční požadavky Nefunkční poţadavky je třeba zaznamenávat a neustále je promítat do návrhu řešení. Mají formu katalogového záznamu. CASE nástroje umoţňují poţadavky zaznamenávat, dávat je do vzájemných vztahů a zobrazovat způsob jejich realizace. Příklady nefunkčních poţadavků mohou být: Odezva systému do 5 s Provoz na platformách UNIX, LINUX Řídicí systém bude zapsán v jazyce C++ custom Performance R017 - Systém musí mít na oddělených pracovištích odezvu do 5 sec.

R016 - Systém bude distribuován na oddělená pracoviště, propojená prostřednictvím internetu s propustností 2Mbit. (from Transport)

R020 - Systém musí být schopen přijmout požadavky 100 uživatelů za minutu s dodržením požadované odezvy

Obrázek 9: Příklad nefunkčních požadavků [10]

U kaţdého katalogového záznamu poţadavku je moţné uvést: Evidenční číslo Datum vytvoření a poslední změny Kdo ho poţadoval a kdo ho přijímal Prioritu Detailní popis poţadavku Návaznosti na další poţadavky Komplexnost a sloţitost poţadavku (pokud je to moţné určit)

2.3.5 Funkční požadavky Funkční poţadavky na systém se nejčastěji modelují pomocí tzv.Uživatelských cílů a Typových úloh (Use Case). Typová úloha je dohoda o chování budoucího systému. Příklady funkčních poţadavků mohou být: Systém umoţní zarezervovat si vozidlo Systém umoţní evidenci výpůjček 30

Systém umoţní mít přehled o klientech req Uživ atelské cíle R001 Zarezerovat si vozidlo k půjč ce

R002 - Mít přehled o svých půjč kách

Obrázek 10: Příklad funkčních požadavků [10]

Modelování typových úloh je základním nástrojem pro specifikaci funkčních poţadavků. Popis toho k čemu budou uţivatelé daný informační systém pouţívat. Navazuje na poznání firemního prostředí (BPM) a definuje na jeho základě moţné funkční poţadavky na nový informační systém. [10]

31

3 Analýza informačního systému pro správu výpočetní techniky Cílem této kapitoly bude identifikovat aktivity v oblasti přípravy a realizace správy výpočetní techniky s cílem získat tak podrobný přehled o potřebách a návaznostech. Identifikace a zohlednění všech souvisejících aktivit je základním předpokladem pro správnost a úplnost specifikace výsledných poţadavků na navrhovaný systém. Pro analýzu i návrh modelovaných procesů, UML diagramů, diagramů tříd, sekvenčních diagramů i poţadavků na systém je pouţit modelovací nástroj Enterprise Architect od společnosti Sparx Systems Pty Ltd2.

3.1 Popis současného stavu V rámci procesu evidence HW se v současné době evidují tyto typy komodit: počítač, notebook, monitor, dokovací stanice, externí harddisk, projektor a tiskárna. Většina evidovaného HW je realizována za pomocí excelových tabulek a různých podpůrných softwarů. Ţivotní cyklus HW se skládá z několika následujících kroků:

3.1.1 Nákup hardwaru Nákup se provádí dvěma způsoby podle toho, zda se jedná o typizovaný/standardní nebo atypický HW. Typizovaný hardware: firma podepisuje na základě výběrového řízení rámcové smlouvy s dodavateli typizovaného HW. K rozsáhlejší obměně HW dochází ve firmě několikrát do roka. Provádí se na základě vypršení doby ţivostnosti HW, která je definována smlouvou na počítače 4 roky a na notebooky 3 roky. Vytipování konkrétních kusů HW se provádí na základě sestavy vygenerované z modulu Majetku SAP obsahující sériové číslo a jméno uţivatele. K obměně HW dochází i před vypršením doby ţivotnosti. V takovém případě je HW zaevidován na sklad a lze ho přiřadit jinému uţivateli, nebo je vyřazen z majetku dle stavu techniky a důvodu výměny HW. Nákup typizovaného HW je prováděn formou „Výzev“. Jedná se formulář vypracovaný v MS Excel, který je naskenován a poslán dodavateli v elektronické podobě. 2

Společnost Sparx Systems Pty Ltd [online] [cit. 2013-07-15]. Dostupný z: http://www.sparxsystems.com/

32

Atypický hardware: tento hardware je modifikovatelný a není tudíţ objednáván formou „Výzev“ z dané smlouvy, ale je objednáván formou „Objednávky“ u dodavatele. Následně se v systému SAP zaloţí „Poţadavek na objednávku“ a poté „Objednávka“, která je přiřazena k účtu přes SPP prvek. Komodita na objednávkách se zadává formou textu. Do skupiny atypického HW je zahrnuta i evidence „Drobného hmotného investičního majetku“, který není ošetřen smlouvou a objednává se z katalogu kancelářských potřeb. Při současném stavu procesu nákupu není podchycena změna konfigurace PC/notebooků, ke které dojde v průběhu nákupu. Např. zastavení výroby daného typu notebooku. Oddělení Nákupu IT si v tabulce MS Excel vede informace o objednaných kusech HW, včetně jmen koncových uţivatelů a sériových číslech. Postupně se do nich zapisují jména techniků, kteří mají za úkol nainstalovat danou výpočetní techniku a následně inventární čísla, která obdrţí z Majetku. Po dodání objednaného HW, který je objednáván na základě porovnání s tabulkou „Nároků“, je potvrzen dodací list a spolu s fakturou dodán na podatelnu firmy. Faktura je prvním záznamem v systému v rámci celého procesu evidence HW. Na faktuře je uveden počet kusů dle typu HW, popis a sériové číslo. Cena je stanovena na základě smlouvy a nelze ji rozepsat na jednotlivé poloţky. V současnosti se nesleduje počet dní po prodlení dodací lhůty, která je uvedena ve smlouvě.

3.1.2 Instalace stanic a předání uživateli Oddělení Nákupu vytvoří tzv. „Sestavy“ z dodané techniky, kterou následně předají technikům k instalaci. Nákup IT si eviduje u jednotlivých kusů jména techniků, kteří instalaci provedou a jména uţivatelů, kterým má být VT přiřazena. Pověřený pracovník Helpdesku si vede totoţnou evidenci z důvodu přehlednosti a vytíţenosti techniků, která je zanášena do softwaru Helpdesk, jako poţadavek na instalaci. Stav rozpracovanosti instalace se vede v tomto softwaru i termín předání VT koncovému uţivateli. Po dokončení instalace výpočetní techniky se vytváří „Výdejka“, která se předá koncovému uţivateli k podpisu. Výdejka je formulář zhotovený v MS Excel. Potvrzená „Výdejka“ se odevzdává zpět do oddělení Nákupu IT, kde se doplňují nebo případně opravují sériová čísla a inventární čísla. Následně se spustí v aplikaci SAP workflow, kde je výdejka znovu potvrzena předávajícím, přebírajícím a garantem komodity. VT se vyvede do majetku v systému SAP aţ v momentě, kdy jsou kompletně předány všechny poloţky „Výzvy“. 33

V tuto chvíli nejsou správně podchyceny reklamace, kdy je VT nahrazena novou. V systému zůstává původní číslo (datum pořízení) a změní se pouze sériové číslo. Dochází k situacím, kdy je vyřazena z evidence rok stará VT. Převodky majetku jsou spravovány Nákupem IT a vyuţívány při změně vlastníka techniky. Ţádosti o převod VT se vypisují přes Helpdesk a schvalují se pomocí workflow v systému SAP.

3.1.3 Vyřazení výpočetní techniky z majetku Vypršení doby životnosti: VT vyřazena z důvodu ukončení doby ţivotnosti, oddělení Nákupu IT vystaví převodku VT na zodpovědného pracovníka Helpdesku. Výpočetní technika je uloţena ve skladu. Nefunkčnost: pokud je výpočetní technika nefunkční rozhoduje, zda je ještě v záruce, pokud ano, dá se na reklamaci, jestli jiţ v záruce není nebo je v takovém stavu, ţe by reklamace nebyla uznána je VT uskladněna ve skladu a určena k likvidaci. Pověřený pracovník Helpdesku připravuje podklady do „ŠLK“3 ve formátu excelové tabulky, kterou následně předává Nákupu prostřednictvím e-mailu. Po schválení seznamu ŠLK je výpočetní technika vyřazena z majetku a je určena k likvidaci

3.2 Model procesu Celý proces správy výpočetní techniky lze rozdělit do následujících částí: Pořízení hardware o Určení hardware k nahrazení o Objednání hardware o Příjem hardware o Zpracování faktur za objednaný hardware o Předání hardware technikovi a uţivateli Správa hardware o Zařazení hardware do majetku o Přesun hardware mezi jednotlivými uţivateli o Vyřazení hardware Údrţba kmenových dat a reporty

3

Škodní a likvidační komise

34

BPMN Výměna HW

«BusinessProcess» Výměna HW Požadavek na HW

Schválení obnovy HW

Pořízení HW

(from Business Objects)

Termín dodání HW

Instalace HW a předání uživateli

Správ a HW


Výměna HW zrealizována


Obrázek 11: Výměna výpočetní techniky

35

3.3 Určení požadavků na navrhovaný systém 3.3.1 Požadavky na vstupní data Zařízení o Identifikační označení zařízení o Název zařízení o Parametry zařízení o Typ zařízení o Umístění o Stav o Termíny dodání, předání, ţivotnosti a vyřazení Výzva o Identifikační označení výzvy o Poloţky výzvy o Termín dodávky o Kontaktní osoba o Označení smlouvy Objednávka o Identifikační označení objednávky o Poloţky objednávky o Termín dodání o Kontaktní osoba Sestava o Identifikační označení sestavy o Typ sestavy o Uţivatel sestavy Smlouva o Identifikační označení smlouvy o Název smlouvy o Termíny vyplývající ze smlouvy Nárok na HW o Identifikační označení uţivatele HW o Typ výpočetní techniky o Počet 36

3.3.2 Požadavky na přístupová oprávnění Administrativní pracovník: -

základní uţivatelské rozhraní

-

vstup po přihlášení uţivatelským jménem a heslem

-

moţnost zakládání Výzev, Objednávek, Sestav, Smluv, Nového zařízení

-

tisk, prohlíţení a editace

Technický pracovník: -

pokročilé uţivatelské rozhraní

-


-

vkládání záznamů o staţené technice, předané technice a vyřazené technice

-

zobrazení, tisk, editace a správa zařízení.

Správce: -

úplné uţivatelské rozhraní

-


-

přístupné správci aplikace

-

zobrazení, tisk, editace a správa uţivatelů

-

přiřazovaní rolí v aplikaci

Manažer: -

základní uţivatelské rozhraní

-


-

vkládání nároků na techniku

-

tisk, prohlíţení a spuštění reportů

3.3.3 Nefunkční požadavky Na základě kapitoly 3.3 byly získány a popsány následující nefunkční poţadavky na budoucí informační systém. Poţadavky byly vytvořeny v modelovacím nástroji Enterprise Architect, kde jsou rozděleny do několika skupin, obrázek 12.

37

Obrázek 12: Analýza nefunkčních požadavků na systém

3.3.4 Funkční požadavky Informační systém bude umoţňovat: zaloţit novou objednávku výpočetní techniky prostřednictvím výzev nebo objednávek evidenci zaloţených objednávek a výzev, zaloţení nových zařízení evidenci zařízení změnu informací o stavu zařízení zaloţení sestavy pro vyřazení techniky

38

4 Návrh implementace vybraného informačního systému Cílem této kapitoly je přiblíţit postup při návrhu jednotlivých částí modelu informačního systému pro správu výpočetní techniky. Pomocí diagramů modelovacího jazyka UML je vyjádřen funkční, logický a dynamický náhled na modelovaný informační systém. Celý návrh vychází ze stávajícího procesu, ve kterém je několik hlavních úloh, které nelze modifikovat či optimalizovat z důvodu návaznosti na stávající systémy pouţívané ve firmě. analysis Business Workflow s

Nalezen HW k výměně Založení výzvy k nákupu HW Odeslání výzvy nebo objednávky dodavateli

Schválení obnovy HW

Dodavatel

Založení objednávky na HW

«Lane»

Příjem HW a dokladů od dodavatele

Příprava seznamu přijatého HW

Přiřazení technika k instalaci HW

Předání HW technikovi

Firma

«Pool»

Oddělení IT

Požadavek na atypický HW

Příprava seznamu předaného HW

Vystavení předávacího protokolu

Instalace HW a předání uživateli Čas instalace

Odeslání seznamu

Oddělení správy majetku

«Lane»

Výdejka HW

Uložení předávacích protokolů do systému SAP

Doplnění karet majetku v HW evidenci Konec procesu

Čas dodání

«Pool»

Dodavatel

Dodací list a Faktura

Příprava HW

Dodavatel

Odeslání HW

Vystavení dodacího listu a faktury

Příjem požadavku na HW

Obrázek 13: Workflow stávajícího procesu

39

4.1 Funkční model informačního systému uc Kompletní diagram typov ých úloh

Založení nov é obj ednáv ky

Založení nov é v ýzv y

Spuštění reportů Manažer

«include»

«include» Ev idence nároků na zařízení

Obj ednání nov ého zařízení

Ev idence smluv (CRUID) Administrativ ní pracov ník

Správ a uživ atelů (CRUID) Administrátor Přidání nov ého zařízení

Předání zařízení k užív ání

«include»

Ev idence zařízení

«include» Stažení zařízení

«include»

extension points: Změna informací o stav u zařízení

«extend»

Změna informací o stav u zařízení

Technický pracov ník

«include» Vyřazení zařízení

Obrázek 14: Navržený model informačního systému

4.1.1 Popis aktérů uc Actors

Administrativ ní pracov ník

Technický pracov ník

Administrátor

Manažer

Obrázek 15: Aktéři modelového návrhu

Administrativní pracovník Administrativní pracovník je zodpovědný za vytváření nových objednávek jak ze smlouvy, tak mimo ní, zakládání nových zařízení, evidenci smluv, vytváření sestav, přiřazování techniky uţivatelům a technikům k instalaci.

40

Technický pracovník Technický pracovník má moţnost sledovat evidenci zařízení a má moţnost nahlíţet do evidence nároků na techniku. Dále je zodpovědný za evidování staţené techniky, vyřazování techniky a předávání nainstalované techniky uţivatelům. Má moţnost měnit stav informací o technice. Administrátor Administrátor je zodpovědný za správu uţivatelů, kdy přiděluje oprávnění těmto uţivatelům do systému na základě jejich charakteristik práce se systémem. Manažer Manaţer má moţnost sledování reportů a je zodpovědný za evidenci nároků na techniku.

4.1.2 Popis podpůrných typových úloh V následné kapitole jsou popsány typové podpůrné úlohy, včetně sekvenčních diagramů, které vystihují chování a spolupráci jednotlivých objektů v rámci jednoho případu uţití. uc Podpůrné typov é úlo...

Spuštění reportů

Ev idence nároků na zařízení

Správ a uživ atelů (CRUID)

Ev idence smluv (CRUID)

Obrázek 16: Podpůrné typové úlohy

Evidence nároků na zařízení Aktéři: Manaţer, Systém Popis: Typová podpůrná úloha umoţní sledovat nároky jednotlivých uţivatelů na danou výpočetní techniku. Hlavní scénář: 1. Aktér iniciuje Evidenci nároků na zařízení 2. Systém zobrazí seznam uţivatelů v systému 3. Aktér vybere uţivatele a zvolí změnu nároků 4. Systém zobrazí formulář pro zadání parametrů 5. Aktér vyplní formulář a potvrdí 6. Systém uloţí data do systému.

41

sd Ev idence nároků na zaříz... Třídy::Pracovnik Manažer

Třídy::Evidence naroku

Uživatelské rozhraní Aktér iniciuje Evidenci nároků() zobrazSeznamPracovniku()

vyhledaniPracovniku() seznamPracovniku()

Aktér vybere uživatele a zvolí změnu nároků() zobrazFormularNaroku()

Aktér vyplní formulář a potvrdí změny() prirazeniTypuTechniky() prirazeniPoctuTechniky() ulozeniNaroku()

(from Actors)

Obrázek 17: Sekvenční diagram Evidence nároků na zařízení

Správa uživatelů Aktéři: Správce, Systém Popis: Typová úloha umoţňuje kompletní správu uţivatelů včetně přidělení oprávnění. Hlavní scénář: 1. Aktér iniciuje Správu uţivatelů 2. Systém nabídne uţivateli vloţení, editaci nebo smazání uţivatele 2.1. Pokud aktér zvolí Zaloţení nového uţivatele 2.1.1. Systém zobrazí seznam pracovníků 2.1.2. Aktér zvolí pracovníka k přiřazení do systému a potvrdí 2.1.3. Systém zobrazí formulář pro zadání specifikace práv 2.1.4. Aktér zadá přístupová práva a potvrdí 2.1.5. Systém zaeviduje nového uţivatele do systému 2.2. Pokud aktér zvolí editaci nového uţivatele 2.2.1. Systém zobrazí uţivatele v systému 2.2.2. Aktér vybere uţivatele 42

2.2.3. Systém zobrazí formulář pro editaci uţivatele, včetně specifikace práv 2.2.4. Aktér provede úpravy a změny potvrdí 2.2.5. Systém uloţí provedené změny 2.3. Pokud aktér zvolí smazání uţivatele 2.3.1. Systém zobrazí uţivatele v systému 2.3.2. Aktér vybere uţivatele 2.3.3. Systém zobrazí varování a poţádá potvrzení akce 2.3.4. Aktér akci potvrdí 2.3.5. Systém smaţe uţivatele. Alternativní scénář: 2.1.b. Aktér zruší zaloţení uţivatele. Uţivatel není uloţen 2.2.b. Aktér zruší úpravu uţivatele. Změny nejsou uloţeny 2.3.b. Aktér nepotvrdí akci. Uţivatel zůstává v systému sd Správ a uživ at... T řídy::Uzivatel Administrátor

T řídy::Pracovnik

Uživatelské rozhraní Aktér iniciuje Správu uživatelů() zobrazFormularSpravy() zobrazenyFormularSpravy()

Aktér zadá Založení nového uživatele() zobrazPracovnika() vyhledaniPracovnika() zobrazenyPracovnik()

Aktér zvolí pracovníka k přiřazení do systému a potvrdí()

alt Editace stáv aj ících opráv nění uživ atele

zobrazFormularEditaceUzivatele() vyhledatUzivatele() zobrazFormularSpecifikacePrav()

Aktér zadá přístupová práva a potvrdí() ulozeniOpravneniUzivatele() Aktér zvolí smazání uživatele() zobrazUzivatele()

vyhledatUzivatele()

Aktér potvrdí smazání uživatele() smazatUzivatele()

(from Actors)

Obrázek 18: Sekvenční diagram Správy uživatelů

43

Spuštění reportů Aktéři: Manaţer, Systém Popis: Typová podpůrná úloha umoţní spuštění jednotlivých reportů a jejich tisk. Hlavní scénář: 1. Aktér iniciuje spuštění reportů 2. Systém zobrazí seznam reportů 3. Aktér vybere poţadovaný report 4. Systém zobrazí vybraný report a umoţní tisk 5. Aktér potvrdí tisk reportu 6. Systém odešle report na tiskárnu Evidence smluv Aktéři: Administrativní pracovník, Systém Popis: Typová úloha umoţňuje evidenci smluv. Zaloţení smlouvy a její editaci. Hlavní scénář: 1. Aktér iniciuje Evidenci smluv 2. Systém zobrazí výběr Zaloţení smlouvy nebo Editaci smlouvy 2.1. Pokud aktér zvolí Zaloţení nové smlouvy 2.1.1. Systém zobrazí formulář pro zadání nové smlouvy 2.1.2. Aktér vyplní formulář a potvrdí 2.1.3. Systém uloţí smlouvu 2.2. Pokud aktér zvolí Editaci smlouvy 2.2.1. Systém zobrazí smlouvy v systému 2.2.2. Aktér vybere smlouvu k editaci a potvrdí ji 2.2.3. Systém zobrazí předvyplněný formulář k editaci 2.2.4. Aktér provede poţadované změny a potvrdí 2.2.5. Systém uloţí provedené změny Alternativní scénář: Evidence smluv - alternativní 2.1.b. Aktér zruší zaloţení smlouvy. Smlouva není uloţena 2.2.b. Aktér zruší úpravu smlouvy. Změny nejsou uloţeny

44

sd Ev idence sml... Třídy::Smlouva Administrativní pracovník

Uživatelské rozhraní

Aktér iniciuje Evidenci smluv() zobraziMoznosti() Aktér zvolí zadání nové smlouvy () zobrazFormularZadaniSmlouvy()

priradDodavatele() FormularZadani()

alt Editace stáv aj ících údaj ů zobraziFormularEditaceSmlouvy()

FormularEditace()

vyhledatSmlouvu()

Aktér vyplní formulář a potvrdí() ulozSmlouvu()

zobrazSeznamSmluv()

(from Actors)

Obrázek 19: Sekvenční diagram Evidence smluv

4.1.3 Popis primárních typových úloh Předání zařízení k instalaci Aktéři: Administrativní pracovník, Technický pracovník, Systém Popis: Typová úloha umoţní vytvořit sestavy ze zařízení a předat ji k instalaci technikům nebo předat k instalaci jiţ vytvořenou sestavu ze skladu. Hlavní scénář: 1. Aktér iniciuje typovou úlohu Předání zařízení k instalaci 2. Include Evidence zařízení 3. Aktér vybere zařízení a potvrdí zařazení do sestavy 4. Systém zobrazí nabídku přidání dalšího zařízení do sestavy 4.1. Pokud aktér vybere přidání dalšího zařízení, systém se vrací do bodu 2 45

4.2. Jinak systém uloţí sestavu. 5. Systém zobrazí nabídku předání technikovi k instalaci 6. Aktér vybere technika a potvrdí 7. Systém uloţí data do stavu Předáno k instalaci 8. Systém vygeneruje zprávu technikovi Alternativní scénář: 3. b Pokud je jiţ zařízení zařazeno v sestavě, pokračuje od bodu 5 sd Předání zařízení k instalaci Třídy::Zarizeni Aktér

Třídy::Sestava

Třídy::Pracovnik

Uživatelské rozhraní Aktér iniciuje Předání zařízení k instalaci() IncludeEvidenceZarizeni() vyhledaniZarizeni() vyhledaneZarizeni() Aktér vybere zařízení a potvrdí zařazení do sestavy() loop Opakuj e dokud nej sou v ybrána v šechna požadov aná zařízení vyberZarizeni() priradZarizeni()

vygenerujCisloSestavy() ulozeniSestavy()

zobrazTechnika() vyhledaniTechnika() seznamPracovniku()

Aktér vybere technika a potvrdí() priradTechnika()

ulozZmenuStavu()

Obrázek 20: Sekvenční diagram Předání zařízení k instalaci

Předání zařízení k užívání Aktéři: Technický pracovník, Systém Popis: Typová úloha umoţní předání zařízení uţivateli včetně vygenerování protokolu o předání Hlavní scénář: 1. Aktér iniciuje předání techniky 2. Include Evidence zařízení 3. Aktér vybere zařízení k předání 4. Systém zobrazí formulář pro předání 5. Aktér vyplní formulář a potvrdí 46

6. Systém zaznamená zařízení do stavu „Předáno“ 7. Systém vygeneruje převodku zařízení sd Předání zařízení k užív ... Třídy::Zarizeni Technický pracovník

Uživatelské rozhraní Aktér iniciuje předání techniky() Include Evidence zařízení()

vyhledejZarizeni() zobraziSeznamZarizeni()

Aktér vybere zařízení k předání() zobrazFormularPredani()

Aktér vyplní formulář a potvrdí() ulozZmenuStavu() vygenerujPrevodku()

(from Actors)

Obrázek 21: Sekvenční diagram Předání zařízení k užívání

Přidání nového zařízení Aktéři: Administrativní pracovník, Systém Popis: Typová úloha umoţní zadaní nového zařízení do evidence. Hlavní scénář: 1. Aktér iniciuje zadání nového zařízení do systému 2. Systém zobrazí formulář pro zadání parametrů zařízení 3. Aktér vyplní poţadované parametry a potvrdí 4. Systém vygeneruje datum pořízení 5. Systém vygeneruje datum ţivotnosti 6. Systém zaznamená zařízení do stavu „Nové“

47

sd Přidání nov ého zaříz... Třídy::Zarizeni Administrativní pracovník

Třídy::ParametryZarizeni


Aktér iniciuje zadání nového zařízení do systému() zobrazFormularZadaniZarizeni()

zadejParametry()

Aktér vyplní požadované parametry a potvrdí() ulozZmenuUdaju() vygenerujDatumPorizeni() vygenerujDatumZivotnosti()

(from Actors)

Obrázek 22: Sekvenční diagram Přidání nového zařízení

Stažení zařízení Aktéři: Technický pracovník, Systém Popis: Typová úloha umoţní odebrání uţívané techniky uţivateli včetně vygenerování protokolu o staţení. Hlavní scénář: 1. Aktér iniciuje staţení techniky 2. Include Evidence zařízení 3. Aktér vybere zařízení ke staţení 4. Systém zobrazí zprávu o potvrzení ke staţení 5. Aktér potvrdí staţení vybrané techniky 6. Systém zaznamená zařízení do stavu „Na skladě“ 7. Systém vygeneruje protokol o staţení

48

sd Stažení zařízení Třídy::Zarizeni Technický pracovník

Uživatelské rozhraní Aktér iniciuje stažení techniky() Include Evidence zařízení() vyhledejZarizeni() seznamZarizeni()

Aktér vybere zařízení ke stažení() zobrazZmenuZarizeni()

Aktér potvrdí stažení vybrané techniky() ulozZmenyUdaju() vygenerujProtokol()

(from Actors)

Obrázek 23: Sekvenční diagram Stažení zařízení

Vyřazení zařízení Aktéři: Technický pracovník, Systém Popis: Typová úloha umoţní vyřadit zařízení z uţívání z důvodů zastaralosti techniky nebo jejího poškození Hlavní scénář: 1. Aktér iniciuje vyřazení techniky 2. Include Evidence zařízení 3. Aktér vybere zařízení k vyřazení 4. Systém zobrazí potvrzení o vyřazení 5. Aktér potvrdí vyřazení techniky 6. Systém zaznamená zařízení do stavu „ŠLK“

49

sd Vyřazení zařízení Třídy::Zarizeni Technický pracovník

Uživatelské rozhraní Aktér iniciuje vyřazení techniky() Include Evidence zařízení() seznamZarizeni()

vyhledejZarizeni()

Aktér vybere zařízení k vyřazení() zobrazZmenuZarizeni()

Aktér potvrdí vyřazení techniky() ulozZmenuUdaju()

(from Actors)

Obrázek 24: Sekvenční diagram Vyřazení techniky

Změna informací o stavu zařízení Aktéři: Technický pracovník, Systém Popis: Typová úloha umoţní zaznamenat změny informací o zařízení a jeho umístění. Hlavní scénář: 1. Aktér iniciuje Změnu informací o stavu zařízení 2. Systém zobrazí předvyplněný formulář daného zařízení 3. Aktér provede poţadované změny a potvrdí 4. Systém uloţí poţadované změny do systému Evidence zařízení Aktéři: Systém, Technický pracovník, Administrativní pracovník Popis: Typová úloha umoţňuje vyhledávání zařízení v evidenci dle příslušných zadaných parametrů. Hlavní scénář: 1. Systém zobrazí parametry pro vyhledání zařízení 2. Aktér zadá parametry hledání zařízení 3. Systém vyhledá zařízení dle vybraných parametrů 4. Systém zobrazí formulář s vyhledanými zařízeními Systém umoţní Změnu informací o stavu zařízení.

50

sd Ev idence zaříz... Třídy::Zarizeni Aktér

Uživatelské rozhraní zobrazFormularVyhledani() parametrovyFormular()

Aktér zadá parametry hledání zařízení() zobrazZarizeni() vyhledejZarizeni() seznamZarizeni()

Obrázek 25: Sekvenční diagram Evidence zařízení

Objednání nového zařízení Aktéři: Administrativní pracovník, Systém Popis: Typová úloha umoţní provedení objednávky výpočetní techniky pomocí Výzvy nebo Objednávky. Hlavní scénář: 1. Aktér iniciuje Objednání nového zařízení 2. Systém zobrazí nabídku objednání zařízení pomocí Objednávky nebo Výzvy 3. Systém odešle objednávku nebo výzvu Alternativní scénář: 2.1. Pokud Aktér zvolí Zaloţení objednávky 2.1.1 Include Zaloţení nové objednávky 2.2. Pokud Aktér zvolí Zaloţení nové výzvy 2.2.1 Include Zaloţení nové výzvy Založení nové objednávky Aktéři: Administrativní pracovník, Systém Popis: Typová úloha umoţní objednání nestandardní výpočetní techniky pomocí objednávky. Hlavní scénář: 1. Aktér iniciuje Zaloţení nové objednávky 2. Systém zobrazí formulář pro zadání parametrů výpočetní techniky 51

3. Aktér vyplní formulář a potvrdí 4. Systém uloţí parametry do evidence 5. Systém zobrazí výběr dodavatele 6. Aktér zvolí dodavatele a potvrdí 7. Systém uloţí objednávku do systému ; sd Založení Obj ednáv ... Třídy::Objednavka Administrativní pracovník


Aktér iniciuje Založení nové objednávky() zobrazFormularObjednavky() FormularObjednavky() Aktér vyplní formulář a potvrdí() ulozDataObjednavky() priradDodavatele() vygenerujDatumObjednavky()

(from Actors)

Obrázek 26: Sekvenční diagram Založení objednávky

Založení nové výzvy Aktéři: Administrativní pracovník, Systém Popis: Typová úloha umoţní objednání standardního zařízení ze smlouvy. Hlavní scénář: 1. Aktér iniciuje Zaloţení nové výzvy 2. Systém zobrazí výběr smlouvy, ze které se bude VT nakupovat 3. Aktér vybere typ smlouvy a potvrdí 4. Systém načte data ze smlouvy 5. Systém zobrazí formulář pro výběr VT 6. Aktér vyplní formulář a potvrdí 7. Systém uloţí výzvu do evidence

52

sd Založení Výz... Třídy::Smlouva Administrativní pracovník

Třídy::Vyzva


Aktér iniciuje Založení nové výzvy() zobrazSmlouvu() vyhledatSmlouvu()

seznamSmluv()

Aktér vybere typ smlouvy a potvrdí()

nactiSmlouvu()

zobrazFormularVyzvy()

Aktér vyplní formulář a potvrdí() ulozVyzvu() vygenerujDatumZalozeniSmlouvy()

(from Actors)

Obrázek 27: Sekvenční diagram Založení nové Výzvy

4.2 Logický model informačního systému Diagram tříd informačního systému reprezentuje statické uspořádání základních typů objektů v navrhovaném systému a jejich vztahy. K vymezení jednotlivých tříd informačního systému je nejdříve definováno souhrnné chování systému, které vychází z metod definovaných ve scénářích případů uţití systému. Jednotlivé případy chování systému jsou následně roztříděny a seskupeny dle logické příslušnosti k obsluhované funkcionalitě systému do navrţených rozhraní. Navrţená rozhraní identifikují budoucí třídy. Na základě identifikovaných rozhraní jsou definovány třídy systému. Analytický model tříd obsahuje identifikované třídy, analytické asociace a případně i generalizace. V návrhovém model tříd jsou definovány atributy se základními typy a jsou zde rozpracovány analytické asociace do agregací a kompozic.

53

class Celkov é chov ... «interface» ICelkoveChovani 1/2 + + + + + + + + + + + + + + + + + + + + + + + + + +

«interface» ICelkoveChovani 2/2

prirazeniDodavatele() : void vygenerovaniCislaSestavy() : void prirazeniPoctuTechniky() : void tiskNakupu() : void ulozeniOpravneniUzivatele() : void ulozeniParametru() : void ulozeniSmlouvy() : void nacteniiSmlouvy() : void prirazeniDodavatele() : void prirazeniPracovnika() : void ulozeniNaroku() : void ulozeniObjednavky() : void ulozeniUdajuPracovnika() : void ulozeniVyzvy() : void vygenerovaniMailuNakupu() : void nacteniDatumuObjednavky() : void nacteniDatumuZalozeniVyzvy() : void prirazeniTechnika() : void prirazeniZarizeni() : void prirazeni parametruZarizeni() : void prirazeniTypuTechniky() : void ulozeniSestavy() : void ulozeniZarizeni() : void prirazeniCislaObjednavky_Vyzvy() : void prirazeniCislaObjednavkyVyzvy() : void ulozeniZmenZarizeni() : void

+ + + + + + + + + + + + + + + + + + + + + + + + + + +

vyhledaniParametru() : void vyhledaniPracovnika() : void zobrazeniFormulareEvidenceNaroku() : void zobrazeniFormulareVyberuSmlouvy() : void zobrazeniFormulareZadaniObjednavky() : void zobrazeniFormulareZadaniSmlouvy() : void zobrazeniFormulareZadaniZarizeni() : void vyhledaniUzivatelu() : void zobrazeniFormulareSpravyZarizeni() : void zobrazeniFormulareZadaniParametru() : void zobrazeniFormulareZadaniVyzvy() : void zobrazeniFormulareZalozeniSestavy() : void zobrazeniPracovniku() : void zobrazeniSeznamuNakupu() : void vyhledaniNakupu() : void zobrazeniFormularePredani() : void zobrazeniFormulareSpravyPracovika() : void zobrazeniFormulareSpravyUzivetelu() : void vyhledaniSmlouvy() : void zobrazeniUzivatelu() : void zobrazeniZarizeni() : void vyhledaniZarizeni() : void zobrazeniSeznamuPracovniku() : void zobrazeniSeznamuSmluv() : void zobrazeniFormulareVyhledaniSmlouvy() : void zobrazeniSestavy() : void zobrazeniFormulareVyhledani() : void

Obrázek 28: Celkové chování systému class Analytický mo... «interface» IPracovnik + + + + +

«interface» IEvidenceNaroku

vyhledaniPracovnika() : void zobrazeniPracovniku() : void zobrazeniFormulareSpravyPracovika() : void ulozeniUdajuPracovnika() : void zobrazeniSeznamuPracovniku() : void

+ + + +

«interface» ISmlouva

zobrazeniFormulareEvidenceNaroku() : void prirazeniTypuTechniky() : void prirazeniPoctuTechniky() : void ulozeniNaroku() : void

+ + + + + +

zobrazeniFormulareZadaniSmlouvy() : void prirazeniDodavatele() : void ulozeniSmlouvy() : void vyhledaniSmlouvy() : void zobrazeniSeznamuSmluv() : void zobrazeniFormulareVyhledaniSmlouvy() : void

«import» «interface» ISestava

«interface» IUzivatel + + + +

+ + + + + + +

ulozeniOpravneniUzivatele() : void vyhledaniUzivatelu() : void zobrazeniFormulareSpravyUzivetelu() : void zobrazeniUzivatelu() : void

«interface» IZarizeni + + + + + + + + + + +

zobrazeniFormulareZadaniZarizeni() : void zobrazeniFormulareSpravyZarizeni() : void zobrazeniFormularePredani() : void zobrazeniZarizeni() : void vyhledaniZarizeni() : void prirazeni parametruZarizeni() : void ulozeniZarizeni() : void prirazeniCislaObjednavky_Vyzvy() : void prirazeniCislaObjednavkyVyzvy() : void zobrazeniFormulareVyhledani() : void ulozeniZmenZarizeni() : void

«interface» IVyzva

vygenerovaniCislaSestavy() : void zobrazeniFormulareZalozeniSestavy() : void prirazeniZarizeni() : void prirazeniPracovnika() : void prirazeniTechnika() : void zobrazeniSestavy() : void ulozeniSestavy() : void

«interface» ISeznamNakupu + + + +

vyhledaniNakupu() : void zobrazeniSeznamuNakupu() : void tiskNakupu() : void vygenerovaniMailuNakupu() : void

«import»

«import»

+ + + + +

«interface» IObjednavka

«import» + + + +

«interface» IParametryZarizeni + vyhledaniParametru() : void + zobrazeniFormulareZadaniParametru() : void + ulozeniParametru() : void

Obrázek 29: Analytický model tříd

54

zobrazeniFormulareVyberuSmlouvy() : void zobrazeniFormulareZadaniVyzvy() : void nacteniiSmlouvy() : void ulozeniVyzvy() : void nacteniDatumuZalozeniVyzvy() : void

zobrazeniFormulareZadaniObjednavky() : void prirazeniDodavatele() : void nacteniDatumuObjednavky() : void ulozeniObjednavky() : void

class Diagram tříd

Třídy::Pracov nik

Třídy::Ev idence naroku

-

osobni _ci sl o: i nt j m eno: stri ng pri j m eni : stri ng ci sl o_pracovni _pozi ce: stri ng pracovni _zarazeni : i nt

+ + + + +

vyhl edani Pracovni ka() : voi d zobrazeni Pracovni ku() : voi d zobrazeni Form ul areSpravyPracovi ka() : voi d ul ozeni Udaj uPracovni ka() : voi d zobrazeni Seznam uPracovni ku() : voi d

+ + + +

ul ozeni Opravneni Uzi vatel e() : voi d vyhl edani Uzi vatel u() : voi d zobrazeni Form ul areSpravyUzi vetelu() : void zobrazeni Uzi vatel u() : voi d

+ + + +

zobrazeni Form ul areEvi denceNaroku() : voi d pri razeni T ypuT echni ky() : voi d pri razeni PoctuT echni ky() : voi d ul ozeni Naroku() : voi d

-

ci sl o_sestavy: i nt typ_sestavy: i nt pri del eny_pracovni k: Pracovni k pri del eny_techni k: Pracovni k

+ + + + + + +

vygenerovani Ci sl aSestavy() : voi d zobrazeniForm ul areZal ozeni Sestavy() : void pri razeni Zari zeni () : voi d pri razeni Pracovni ka() : voi d pri razeni T echni ka() : voi d zobrazeni Sestavy() : voi d ul ozeni Sestavy() : voi d

0..*

Třídy::Sestav a

Třídy::Uziv atel Opravneni : bool ean uzi vatel skeHesl o: stri ng uzi vatel skeJm eno: stri ng

typ_vypocetni _techni ky: char pocet: i nt osobni _ci sl o: i nt

+osobni _ci+osobni sl o _ci sl o

1

-

-

Třídy::Smlouv a

+ci sl o_sestavy

-

ci sl o_sm l ouvy: i nt nazev_sm l ouvy: char popi s_dodavaneho_HW: char typ_HW: char cena: i nt datum _pocatku_pl atnosti : date datum _konce_pl atnosti : date

+ + + + + +

zobrazeni Form ul areZadani Sm l ouvy() : voi d pri razeni Dodavatel e() : voi d ul ozeni Sm l ouvy() : voi d vyhl edani Sm l ouvy() : voi d zobrazeni Seznam uSm l uv() : voi d zobrazeni Form ul areVyhl edani Sm l ouvy() : void

1

+ci sl o_sm l ouvy

1

+ci sl o_sm l ouvy 0..* Třídy::Zarizeni

+ci sl o_sestavy

-

seri ove_ci sl o: char i nventarní_ci sl o: i nt nazev_zari zeni : char um i steni : char stav: char param etry: Param etryZari zeni ci sl o_obj ednavky_vyzvy: i nt typ_zari zeni : char datum _zi votnosti : date datum _dodani : date datum _predani _techni kovi : date datum _vyrazeni : date poznam ka: char ci sl o_sestavy: i nt

1..*

+ + + + + + + + + + +

zobrazeni Formul areZadani Zari zeni() : void zobrazeni Form ulareSpravyZari zeni () : void zobrazeni Form ul arePredani () : voi d zobrazeni Zari zeni () : voi d vyhl edani Zari zeni () : voi d pri razeni param etruZari zeni () : voi d ul ozeni Zari zeni () : voi d pri razeni Ci sl aObj ednavky_Vyzvy() : voi d pri razeni Ci sl aObj ednavkyVyzvy() : voi d zobrazeni Form ul areVyhl edani () : voi d ul ozeni Zm enZari zeni () : voi d

1

Třídy::Vyzv a Třídy::ParametryZarizeni

1

1

-

procesor: stri ng pam ěť: i nt hard_di sk: i nt

+ + +

vyhl edani Param etru() : voi d zobrazeni Form ul areZadaniParam etru() : void ul ozeni Param etru() : voi d

+ci sl o_vyzvy

-

ci sl o_sm l ouvy: i nt ci sl o_vyzvy: i nt

+ + + + +

zobrazeni Form ul areVyberuSm l ouvy() : void zobrazeni Form ul areZadani Vyzvy() : voi d nacteni i Sm l ouvy() : voi d ul ozeni Vyzvy() : voi d nacteni Datum uZal ozeni Vyzvy() : voi d

1

+seri ove_ci sl o

+seri ove_ci sl o 1

Třídy::Seznam_nakupu -

seri ove_ci sl o: char ci sl o_obj ednavky: i nt ci sl o_vyzvy: i nt

+ + + +

vyhl edani Nakupu() : voi d zobrazeni Seznam uNakupu() : voi d ti skNakupu() : voi d vygenerovani M ai l uNakupu() : voi d

1..* +ci sl o_obj ednavky 1..*

Obrázek 30: Návrhový model informačního systému

55

Třídy::Obj ednav ka

+ci sl o_vyzvy

+ci sl o_obj ednavky 1

-

ci sl o_obj ednavky: i nt dodavatel : char datum _dodavky: date m i sto_dodavky: date kontaktni _osoba: i nt

+ + + +

zobrazeni Form ul areZadani Obj ednavky() : void pri razeni Dodavatel e() : voi d nacteni Datum uObj ednavky() : voi d ul ozeni Obj ednavky() : voi d

4.3 Uživatelské rozhraní informačního systému V této části kapitoly budou přiblíţeny moţné podoby nového informačního systému. Cílem ukázek je grafické vyjádření naplnění z jednoho s poţadavků na systém na intuitivní uţivatelské rozhraní.

4.3.1 Návrh na platformě Java Tento návrh je vytvořen ve vývojovém prostředí NetBeans IDE. NetBeans je projektem s rozsáhlou uţivatelskou základnou, komunitou vývojářů a s více neţ 100 partnery po celém světě4. Vývojové prostředí NetBeans IDE je nástroj, pomocí kterého programátoři mohou psát, překládat, ladit a šířit programy. NetBeans IDE je napsáno v jazyce Java a je postaveno na stejnojmenné platformě. Primárně je určeno pro vývoj aplikací v jazyce Java, ale můţe podporovat i další programovací jazyky (ve verzi 6.0 např. C++, PHP, Ruby). V Javě podporuje všechny 3 hlavní platformy - J2SE, J2EE a J2ME. Zjednodušuje práci s framework a umoţňuje mimo jiné vývoj SOAP aplikací a webových sluţeb i webových aplikací. Obsahuje také RAD nástroje pro tvorbu designu aplikace. Kromě toho také existuje velké mnoţství modulů, které toto vývojové prostředí rozšiřují. Vývojové prostředí NetBeans je bezplatně šířený produkt, který je moţné pouţívat bez jakýchkoliv omezení. Produkty pod open source licencí je moţné bezplatné pouţívat v komerčním i nekomerčním prostředí. Zdrojový kód je dostupný pod licencí Common Development and Distribution License.

Obrázek 31: Návrh obrazovky úvodního menu 4

Vývojová platforma NetBeans. http://cs.wikipedia.org/wiki/NetBeans

Wikipedia

[online]

56

2013

[cit.

2013-07-15].

Dostupné

z:

Na obrázku č. 31 je znázorněno úvodní menu po přihlášení do systému. Je rozděleno do několika záloţek, dle návrhu z modelu případu uţití a dále je rozčleněnéo na podzáloţky týkajících se daných oblastí.

Obrázek 32: Návrh formuláře pro přidání nového zařízení

Na obrázku č. 32 je znázorněn návrh formuláře pro zadávání nového zařízení, kde jsou uvedeny poţadované hodnoty a v rozbalovacím výběru jsou uvedeny všechny typy zadávaného zařízení.

4.3.2 Návrh pro systém SAP Tento návrh je vytvořen firmou NESS Czech s.r.o.5 a vychází z cílového konceptu „Optimalizace procesu evidence HW“, který slouţí pro vytvoření modulu SAP-CMDB. Tento dokument byl vytvořen na základě diskuzí a závěrů z osobních schůzek a obdrţených firemních podkladů, které nejsem oprávněn publikovat. Na obrázku č. 31 je znázorněn návrh obrazovky pro předání VT k instalaci, kde je znázorněna objednaná výpočetní technika pro konkrétního uţivatele s moţností přiřazení technika, kterému bude technika přidělena k instalaci. 5

Profil společnosti NESS Czech s.r.o [online] [cit. 2013-07-15]. Dostupné z http://www.ness.com/cscz/Pages/GlobalSite.aspx

57

Obrázek 33: Návrh obrazovky pro předání VT k instalaci

Na dalších obrázcích jsou uvedené podoby vygenerovaných protokolů převodu majetku a objednání výpočetní techniky.

Obrázek 34: Výdejka zařízení

58

Obrázek 35: Výzva ze smlouvy pro objednání VT

59

Závěr Cílem této práce byl návrh informačního systému, který bude podporou pro evidenci výpočetní techniky v energetické společnosti. Prvním krokem návrhu bylo poznání procesu, který má zamýšlený informační systém podpořit. V potřebném detailu byl také zpracován komplexní pohled na základní principy tvorby informačního systému pomocí modelovacího jazyka UML, který pak práce zohledňuje při návrhu samotného informačního systému pro potřeby sjednocení a zlepšení evidence majetku ve firmě ČEPS, a.s. Informační systém je navrţen tak, aby umoţnoval nejen evidenci majetku ve firmě, ale také i evidenci smluv, nároků na techniku a evidenci uţivatelských oprávnění pro práci se systémem. Umoţňuje rovněţ převod výpočetní techniky mezi uţivateli, evidenci této techniky v různých stavech její ţivotnosti a tvorby objednávek. Pro evidenci majetku se ve společnosti vyuţívá software SAP, avšak pro různé typy stavů techniky se vyuţívají excelovské tabulky, které mají určitou netransparentnost. Proto jedním z důvodů diplomové práce bylo odstranit tyto excelovské tabulky a vytvořit přehledný a všem účastníkům dostupný datový zdroj. Informační systém je navrţen z pohledu funkčního, logického a dynamického. Představu o systému doplňuje návrh uspořádání grafického uţivatelského rozhraní a tiskových sestav, coţ výrazně zjednodušuje pohled uţivatele na aplikaci. Jsem toho názoru, ţe cíl práce byl splněn v potřebném rozsahu, přičemţ jsou tu stále moţné další oblasti rozvoje nebo dalších moţných úprav. Jako příklad rozvoje by mohlo být přidání evidence softwaru.

60

Seznam použité literatury [1] ARLOW, Jim; NEUSTADT, Ila. UML2 : a unifikovaný proces vývoje aplikací. 2. aktualizované a doplněné vydání. Brno: Computer Press, 2007. 568 s. ISBN 978-80-2511503-9. [2] KANISOVÁ, Hana a Miroslav MÜLLER. UML srozumitelně. Vyd. 1. Brno: Computer Press, 2004, 157 s. ISBN 80-251-0231-9. [3] Business Process Model and Notation – Wikipedie. [online]. 6. 6. 2013 [cit. 2013-07-14]. Dostupné z: http://cs.wikipedia.org/wiki/Business_Process_Model_and_Notation [4] OMG OBJECT MANAGEMENT GROUP. BPMN [online]. [cit. 2013-06-29]. Dostupné z: http://www.omg.org/spec/BPMN/2.0/PDF/ [5] KOBLÁSA, Pavel. Princip tří architektur a jeho význam v metodách návrhu systému [online]. 2001 [cit. 2013-06-21]. Dostupné z: http://invent.unas.cz/documents/p3a.php [6] KOMIX s.r.o.: Úvod do jazyka UML. [online]. [cit. 2013-06-22]. Dostupné z: http://www.komix.cz/Tisk/Clanky/Historie/Uvod_UML.aspx [7] SVOBODA, Kamil. Modelování firemních procesů [online]. [cit. 2013-06-21]. Dostupné z: http://edu.uhk.cz/~svoboka1/download/OMO1/01_modelovani_firemnich_procesu.zip [8] SVOBODA, Kamil. Modelování typových úloh [online]. [cit. 2013-06-21]. Dostupné z: http://edu.uhk.cz/~svoboka1/download/OMO1/05_typove_ulohy.zip [9] SVOBODA, Kamil. Projektování informačních systémů [online]. [cit. 2013-06-21]. Dostupné z: http://edu.uhk.cz/~svoboka1/download/OMO1/03_projektovani.zip [10] SVOBODA, Kamil. Specifikace požadavků na systém [online]. [cit. 2013-06-21]. Dostupné z: http://edu.uhk.cz/~svoboka1/download/OMO1/04_pozadavky.zip [11] ŠEBEK, Václav. Modelování procesů [online]. 2012 [cit. 2013-06-21]. Dostupné z: https://is.bivs.cz/auth/el/6110/leto2012/M101RPP/um/6_Modelovani_procesu.ppt [12] TIŠŇOVSKÝ, Pavel. Root.cz [online]. 2005 [cit. 2011-10-30]. Nástroje pro tvorbu UML diagramů.

Dostupné

z

WWW:

diagramu/#k01>.

61

Seznam pojmů a zkratek B2B

Business to Business

BPD

Business Process Diagram

BPM Business Process Modeling BPMN Business Process Modeling Notation CASE Computer aided software engineering ICT

Informační a komunikační technologie

IS

Informační systém

IT

Informační technika

HW

Hardware

OOP Objektově orientované programování SW

Software

SLA

Service level agreement

SPZ

Specifikace poţadavků zákazníka

ŠLK

Škodní a likvidační komise

UML Unified Modeling Language VT

Výpočetní technika

62

Seznam obrázků Obrázek 1: Schéma procesu[7] ................................................................................................... 8 Obrázek 2: Dekompozice firemního chování [7] ..................................................................... 10 Obrázek 3: Základní skupiny elementů BPMN [4] .................................................................. 13 Obrázek 4: Příklady událostí [4]............................................................................................... 13 Obrázek 5: Aktivity a jejich instance [7] .................................................................................. 15 Obrázek 6: Typy bran [4] ......................................................................................................... 16 Obrázek 7: Typy relací [1]........................................................................................................ 22 Obrázek 8: Problém zjištění potřeb zákazníka [10].................................................................. 28 Obrázek 9: Příklad nefunkčních poţadavků [10] ..................................................................... 30 Obrázek 10: Příklad funkčních poţadavků [10] ....................................................................... 31 Obrázek 11: Výměna výpočetní techniky ................................................................................ 35 Obrázek 12: Analýza nefunkčních poţadavků na systém ........................................................ 38 Obrázek 13: Workflow stávajícího procesu ............................................................................. 39 Obrázek 14: Navrţený model informačního systému .............................................................. 40 Obrázek 15: Aktéři modelového návrhu .................................................................................. 40 Obrázek 16: Podpůrné typové úlohy ........................................................................................ 41 Obrázek 17: Sekvenční diagram Evidence nároků na zařízení ................................................ 42 Obrázek 18: Sekvenční diagram Správy uţivatelů ................................................................... 43 Obrázek 19: Sekvenční diagram Evidence smluv .................................................................... 45 Obrázek 20: Sekvenční diagram Předání zařízení k instalaci................................................... 46 Obrázek 21: Sekvenční diagram Předání zařízení k uţívání .................................................... 47 Obrázek 22: Sekvenční diagram Přidání nového zařízení ........................................................ 48 Obrázek 23: Sekvenční diagram Staţení zařízení .................................................................... 49 Obrázek 24: Sekvenční diagram Vyřazení techniky ................................................................ 50 Obrázek 25: Sekvenční diagram Evidence zařízení ................................................................. 51 Obrázek 26: Sekvenční diagram Zaloţení objednávky ............................................................ 52 Obrázek 27: Sekvenční diagram Zaloţení nové Výzvy ........................................................... 53 Obrázek 28: Celkové chování systému .................................................................................... 54 Obrázek 29: Analytický model tříd .......................................................................................... 54 Obrázek 30: Návrhový model informačního systému .............................................................. 55 Obrázek 31: Návrh obrazovky úvodního menu ........................................................................ 56 Obrázek 32: Návrh formuláře pro přidání nového zařízení ...................................................... 57 63

Obrázek 33: Návrh obrazovky pro předání VT k instalaci....................................................... 58 Obrázek 34: Výdejka zařízení .................................................................................................. 58 Obrázek 35: Výzva ze smlouvy pro objednání VT .................................................................. 59

64

Návrh informačního systému pro správu VT pomocí UML

Recommend Documents