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

Rozměr: px
Začít zobrazení ze stránky:

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

Transkript

1 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

2 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 Vladimír Šimon

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

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

5 Obsah Úvod Základní principy modelování informačního systému Procesní modelování ve firmě Klasifikace procesů Struktura procesů Popis procesu BPMN Modelování informačních systémů Modelování IS pomocí jazyka UML Úvod do UML Struktura jazyka UML Předměty Relace Diagramy Poţadavky Získávání poţadavků Problém zjištění potřeb zákazníka Specifikace poţadavků na systém Non-funkční poţadavky Funkční poţadavky Analýza informačního systému pro správu výpočetní techniky Popis současného stavu Nákup hardwaru Instalace stanic a předání uţivateli Vyřazení výpočetní techniky z majetku Model procesu Určení poţadavků na navrhovaný systém

6 3.3.1 Poţadavky na vstupní data Poţadavky na přístupová oprávnění Nefunkční poţadavky Funkční poţadavky Návrh implementace vybraného informačního systému Funkční model informačního systému Popis aktérů Popis podpůrných typových úloh Popis primárních typových úloh Logický model informačního systému Uţivatelské rozhraní informačního systému Návrh na platformě Java Návrh pro systém SAP Závěr

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

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

9 Druhou moţností rozdělení procesů: obchodní podpůrné existenční / vývojové: zajišťující rozvoj organizace provozní: zajišťující chod organizace 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

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

11 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

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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

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

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

23 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

24 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

25 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

26 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

27 Jsou to například poţadavky na kvalitu, pouţité technologie, na organizaci projektu, na formu a obsah dokumentace apod 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ý 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

28 Představa zákazníka Pochopení problému Reálné potřeby Obrázek 8: Problém zjištění potřeb zákazníka [10] 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

29 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

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

31 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

32 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 Ltd 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ů: 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 ]. Dostupný z: 32

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

34 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 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 u. 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

35 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 (from Business Objects) Výměna HW zrealizována (from Business Objects) Obrázek 11: Výměna výpočetní techniky 35

36 3.3 Určení požadavků na navrhovaný systém 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

37 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í - vstup po přihlášení uţivatelským jménem a heslem - 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í - vstup po přihlášení uţivatelským jménem a heslem - 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í - vstup po přihlášení uţivatelským jménem a heslem - vkládání nároků na techniku - tisk, prohlíţení a spuštění reportů 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

38 Obrázek 12: Analýza nefunkčních požadavků na systém 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

39 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 Workflows Nalezen HW k výměně Schválení obnovy HW Založení výzvy k nákupu HW Odeslání výzvy nebo objednávky dodavateli Založení objednávky na HW Dodavatel Požadavek na atypický HW «Lane» Oddělení IT 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 «Pool» Firma Příprava seznamu předaného HW Instalace HW a předání uživateli Vystavení předávacího protokolu Čas instalace Odeslání seznamu Výdejka HW «Lane» Oddělení správy majetku Uložení předávacích protokolů do systému SAP Doplnění karet majetku v HW evidenci Konec procesu Čas dodání Dodací list a Faktura «Pool» Dodavatel Příprava HW Vystavení dodacího listu a faktury Odeslání HW Dodavatel Příjem požadavku na HW Obrázek 13: Workflow stávajícího procesu 39

40 4.1 Funkční model informačního systému uc Kompletní diagram typových úloh Založení nov é objednáv ky Založení nové výzvy Spuštění reportů Manažer «include» «include» Objednání nov ého zařízení Ev idence nároků na 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» Technický pracovník Stažení zařízení «include» «include» Ev idence zařízení extension points: Změna informací o stavu zařízení «extend» Změna informací o stavu zařízení «include» Vyřazení zařízení Obrázek 14: Navržený model informačního systému 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

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

42 sd Evidence nároků na zaříz... Manažer Aktér iniciuje Evidenci nároků() Uživatelské rozhraní Třídy::Pracovnik Třídy::Evidence naroku zobrazseznampracovniku() seznampracovniku() vyhledanipracovniku() 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 Systém zobrazí seznam pracovníků Aktér zvolí pracovníka k přiřazení do systému a potvrdí Systém zobrazí formulář pro zadání specifikace práv Aktér zadá přístupová práva a potvrdí Systém zaeviduje nového uţivatele do systému 2.2. Pokud aktér zvolí editaci nového uţivatele Systém zobrazí uţivatele v systému Aktér vybere uţivatele 42

43 Systém zobrazí formulář pro editaci uţivatele, včetně specifikace práv Aktér provede úpravy a změny potvrdí Systém uloţí provedené změny 2.3. Pokud aktér zvolí smazání uţivatele Systém zobrazí uţivatele v systému Aktér vybere uţivatele Systém zobrazí varování a poţádá potvrzení akce Aktér akci potvrdí 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áva uživat... Třídy::Uzivatel Třídy::Pracovnik Administrátor Uživatelské rozhraní Aktér iniciuje Správu uživatelů() zobrazformularspravy() zobrazenyformularspravy() Aktér zadá Založení nového uživatele() zobrazpracovnika() zobrazenypracovnik() vyhledanipracovnika() 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

44 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 Systém zobrazí formulář pro zadání nové smlouvy Aktér vyplní formulář a potvrdí Systém uloţí smlouvu 2.2. Pokud aktér zvolí Editaci smlouvy Systém zobrazí smlouvy v systému Aktér vybere smlouvu k editaci a potvrdí ji Systém zobrazí předvyplněný formulář k editaci Aktér provede poţadované změny a potvrdí 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

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

46 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 Třídy::Sestava Třídy::Pracovnik Aktér 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 Opakuje dokud nejsou vybrána všechna požadovaná 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

47 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í() zobraziseznamzarizeni() vyhledejzarizeni() 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

48 sd Přidání nového zaříz... Třídy::Zarizeni Třídy::ParametryZarizeni Administrativní pracovník Uživatelské rozhraní 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

49 sd Stažení zařízení Třídy::Zarizeni Technický pracovník Uživatelské rozhraní Aktér iniciuje stažení techniky() Include Evidence zařízení() seznamzarizeni() vyhledejzarizeni() 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

50 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

51 sd Evidence 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 Include Zaloţení nové objednávky 2.2. Pokud Aktér zvolí Zaloţení nové výzvy 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

52 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í Objednáv... Třídy::Objednavka Administrativní pracovník Uživatelské rozhraní 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

53 sd Založení Výz... Třídy::Smlouva Třídy::Vyzva Administrativní pracovník Uživatelské rozhraní Aktér iniciuje Založení nové výzvy() zobrazsmlouvu() seznamsmluv() vyhledatsmlouvu() 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

54 class Celkov é chov... «interface» ICelkoveChovani 1/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 «interface» ICelkoveChovani 2/2 + 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 + vyhledanipracovnika() : void + zobrazenipracovniku() : void + zobrazeniformularespravypracovika() : void + ulozeniudajupracovnika() : void + zobrazeniseznamupracovniku() : void «interface» IEvidenceNaroku + zobrazeniformulareevidencenaroku() : void + prirazenityputechniky() : void + prirazenipoctutechniky() : void + ulozeninaroku() : void «interface» ISmlouva + zobrazeniformularezadanismlouvy() : void + prirazenidodavatele() : void + ulozenismlouvy() : void + vyhledanismlouvy() : void + zobrazeniseznamusmluv() : void + zobrazeniformularevyhledanismlouvy() : void «import» «interface» IUzivatel + ulozeniopravneniuzivatele() : void + vyhledaniuzivatelu() : void + zobrazeniformularespravyuzivetelu() : void + zobrazeniuzivatelu() : void «interface» ISestava + vygenerovanicislasestavy() : void + zobrazeniformularezalozenisestavy() : void + prirazenizarizeni() : void + prirazenipracovnika() : void + prirazenitechnika() : void + zobrazenisestavy() : void + ulozenisestavy() : void «interface» ISeznamNakupu «import» «interface» IVyzva + zobrazeniformularevyberusmlouvy() : void + zobrazeniformularezadanivyzvy() : void + nacteniismlouvy() : void + ulozenivyzvy() : void + nactenidatumuzalozenivyzvy() : 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 «import» «interface» IParametryZarizeni + vyhledaniparametru() : void + zobrazeniformularezadaniparametru() : void + ulozeniparametru() : void + vyhledaninakupu() : void + zobrazeniseznamunakupu() : void + tisknakupu() : void + vygenerovanimailunakupu() : void «import» «interface» IObjednavka + zobrazeniformularezadaniobjednavky() : void + prirazenidodavatele() : void + nactenidatumuobjednavky() : void + ulozeniobjednavky() : void Obrázek 29: Analytický model tříd 54

55 class Diagram tříd Třídy::Pracov nik - osobni_cislo: int - jmeno: string - prijmeni: string - cislo_pracovni_pozice: string - pracovni_zarazeni: int + vyhledanipracovnika() : void + zobrazenipracovniku() : void + zobrazeniformularespravypracovika() : void + ulozeniudajupracovnika() : void + zobrazeniseznamupracovniku() : void 0..* Třídy::Uziv atel - Opravneni: boolean - uzivatelskeheslo: string - uzivatelskejmeno: string + ulozeniopravneniuzivatele() : void + vyhledaniuzivatelu() : void + zobrazeniformularespravyuzivetelu() : void + zobrazeniuzivatelu() : void +osobni_cislo +osobni_cislo 1 +cislo_sestavy 1 Třídy::Evidence naroku - typ_vypocetni_techniky: char - pocet: int - osobni_cislo: int + zobrazeniformulareevidencenaroku() : void + prirazenityputechniky() : void + prirazenipoctutechniky() : void + ulozeninaroku() : void Třídy::Sestav a - cislo_sestavy: int - typ_sestavy: int - prideleny_pracovnik: Pracovnik - prideleny_technik: Pracovnik + vygenerovanicislasestavy() : void + zobrazeniformularezalozenisestavy() : void + prirazenizarizeni() : void + prirazenipracovnika() : void + prirazenitechnika() : void + zobrazenisestavy() : void + ulozenisestavy() : void Třídy::Smlouv a - cislo_smlouvy: int - nazev_smlouvy: char - popis_dodavaneho_hw: char - typ_hw: char - cena: int - datum_pocatku_platnosti: date - datum_konce_platnosti: date + zobrazeniformularezadanismlouvy() : void + prirazenidodavatele() : void + ulozenismlouvy() : void + vyhledanismlouvy() : void + zobrazeniseznamusmluv() : void + zobrazeniformularevyhledanismlouvy() : void +cislo_smlouvy 1 +cislo_smlouvy 0..* Třídy::Zarizeni - seriove_cislo: char - inventarní_cislo: int - nazev_zarizeni: char - umisteni: char - stav: char - parametry: ParametryZarizeni - cislo_objednavky_vyzvy: int - typ_zarizeni: char - datum_zivotnosti: date - datum_dodani: date - datum_predani_technikovi: date - datum_vyrazeni: date - poznamka: char - cislo_sestavy: int + zobrazeniformularezadanizarizeni() : void + zobrazeniformularespravyzarizeni() : void + zobrazeniformularepredani() : void + zobrazenizarizeni() : void + vyhledanizarizeni() : void + prirazeni parametruzarizeni() : void + ulozenizarizeni() : void + prirazenicislaobjednavky_vyzvy() : void + prirazenicislaobjednavkyvyzvy() : void + zobrazeniformularevyhledani() : void + ulozenizmenzarizeni() : void +cislo_sestavy 1..* 1 +seriove_cislo 1 1 +seriove_cislo - procesor: string - paměť: int - hard_disk: int Třídy::ParametryZarizeni + vyhledaniparametru() : void + zobrazeniformularezadaniparametru() : void + ulozeniparametru() : void 1 Třídy::Seznam_nakupu - seriove_cislo: char - cislo_objednavky: int - cislo_vyzvy: int + vyhledaninakupu() : void + zobrazeniseznamunakupu() : void + tisknakupu() : void + vygenerovanimailunakupu() : void +cislo_vyzvy 1..* +cislo_objednavky 1..* +cislo_vyzvy +cislo_objednavky cislo_smlouvy: int - cislo_vyzvy: int Třídy::Vyzv a + zobrazeniformularevyberusmlouvy() : void + zobrazeniformularezadanivyzvy() : void + nacteniismlouvy() : void + ulozenivyzvy() : void + nactenidatumuzalozenivyzvy() : void Třídy::Objednav ka - cislo_objednavky: int - dodavatel: char - datum_dodavky: date - misto_dodavky: date - kontaktni_osoba: int + zobrazeniformularezadaniobjednavky() : void + prirazenidodavatele() : void + nactenidatumuobjednavky() : void + ulozeniobjednavky() : void Obrázek 30: Návrhový model informačního systému 55

56 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í 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. Wikipedia [online] 2013 [cit ]. Dostupné z: 56

57 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í 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 ]. Dostupné z 57

Business Process Modeling Notation

Business Process Modeling Notation Business Process Modeling Notation Stephen A. White, IBM Corporation Procesní řízení 1 Co to je BPMN? Standard Business Process Modeling Notation (BPMN) byl vyvinutý skupinou Business Process Management

Více

Základní informace. Modelování. Notace

Základní informace. Modelování. Notace Základní informace BPMS = business process management systems - systémy pro modelování a optimalizace business procesů uvnitř organizace BPMN = business process modeling notation - součást BPMS, notace

Více

Objektová tvorba SW, Analýza požadavků 2006 UOMO 53

Objektová tvorba SW, Analýza požadavků 2006 UOMO 53 Objektová tvorba SW, Analýza požadavků 2006 UOMO 53 Osnova Základní principy tvorby SW Fáze tvorby SW v předmětu UOMO Analýza požadavků Modelování typových úloh 2006 UOMO 54 Tvorba SW Dříve umění vyvolených

Více

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování.

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování. 3 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Business modelling, základní nástroje a metody business modelování.

Více

PV207. Business Process Management

PV207. Business Process Management PV207 Business Process Management Úvod do BPMN 12. 3. 2009 Petr Vašíček 2007 2009 IBA Group FI MU Obsah přednášky Opakování BPMS Úvod do BPMN Přehled grafických elementů Flow objects Connecting objects

Více

Modelování procesů s využitím MS Visio.

Modelování procesů s využitím MS Visio. Modelování procesů s využitím MS Visio jan.matula@autocont.cz Co je to modelování procesů? Kreslení unifikovaných či standardizovaných symbolů, tvarů a grafů, které graficky znázorňují hlavní, řídící nebo

Více

Obsah. Zpracoval:

Obsah. Zpracoval: Zpracoval: houzvjir@fel.cvut.cz 03. Modelem řízený vývoj. Doménový (business), konceptuální (analytický) a logický (návrhový) model. Vize projektu. (A7B36SIN) Obsah Modelem řízený vývoj... 2 Cíl MDD, proč

Více

Informační systémy 2008/2009. Radim Farana. Obsah. UML - charakteristika

Informační systémy 2008/2009. Radim Farana. Obsah. UML - charakteristika 2 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Jazyk UML, základní modely, diagramy aktivit, diagramy entit.

Více

UML. Unified Modeling Language. Součásti UML

UML. Unified Modeling Language. Součásti UML UML Unified Modeling Language 1995 počátek 1997 verze 1.0 leden dnes verze 2.0 (vývoj stále nedokončen) Standardní notace OMG podpora velkých firem (Microsoft, IBM, Oracle, HP ) popisuje struktury popisuje

Více

OBSAH 1. ÚVOD STRUKTURA A ÚROVNĚ PROCESNÍHO MODELU KONVENCE PRO MODELOVÁNÍ PROCESŮ KONVENCE PRO MODELOVÁNÍ ORGANIZAČNÍCH STRUK

OBSAH 1. ÚVOD STRUKTURA A ÚROVNĚ PROCESNÍHO MODELU KONVENCE PRO MODELOVÁNÍ PROCESŮ KONVENCE PRO MODELOVÁNÍ ORGANIZAČNÍCH STRUK Konvence procesního modelování v CENIA výtah z metodiky příloha č. 3 soutěžní dokumentace pro výběrové řízení na Integrovaný systém plnění ohlašovacích povinností OBSAH 1. ÚVOD... 4 2. STRUKTURA A ÚROVNĚ

Více

Unifikovaný modelovací jazyk UML

Unifikovaný modelovací jazyk UML Unifikovaný modelovací jazyk UML Karel Richta katedra počíta tačů FEL ČVUT Praha richta@fel fel.cvut.czcz Motto: Komunikačním m prostředkem informační komunity se postupem času stala angličtina. Chcete-li

Více

Modelování podnikových procesů

Modelování podnikových procesů Modelování podnikových procesů Co je to podnikový proces? Činnost za účelem splnění určitého podnikového cíle (business goal) Provádění časově ohraničeno Vstupní podmínky Při realizaci probíhají vzájemně

Více

TÉMATICKÝ OKRUH Softwarové inženýrství

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 22. Otázka : Úvodní fáze rozpracování softwarového projektu. Postupy při specifikaci byznys modelů. Specifikace požadavků a jejich rozpracování pomocí

Více

TÉMATICKÝ OKRUH Softwarové inženýrství

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 24. Otázka : Implementační fáze. Postupy při specifikaci organizace softwarových komponent pomocí UML. Mapování modelů na struktury programovacího

Více

PŘÍLOHA C Požadavky na Dokumentaci

PŘÍLOHA C Požadavky na Dokumentaci PŘÍLOHA C Požadavky na Dokumentaci Příloha C Požadavky na Dokumentaci Stránka 1 z 5 1. Obecné požadavky Dodavatel dokumentaci zpracuje a bude dokumentaci v celém rozsahu průběžně aktualizovat při každé

Více

Vývoj informačních systémů. Obecně o IS

Vývoj informačních systémů. Obecně o IS Vývoj informačních systémů Obecně o IS Informační systém Informační systém je propojení informačních technologií a lidských aktivit směřující k zajištění podpory procesů v organizaci. V širším slova smyslu

Více

Analýza a modelování dat. Helena Palovská

Analýza a modelování dat. Helena Palovská Analýza a modelování dat Helena Palovská Analýza a modelování pro SW projekt Strukturovaný přístup Dynamická část (procesy, aktivity, funkce) Statická část (data) Objektově orientovaný přístup use case

Více

Principy UML. Clear View Training 2005 v2.2 1

Principy UML. Clear View Training 2005 v2.2 1 Principy UML Clear View Training 2005 v2.2 1 1.2 Co je touml? Unified Modelling Language (UML) je univerzálníjazyk pro vizuální modelování systémů Podporuje všechny životní cykly Mohou jej implementovat

Více

Pokročilé typové úlohy a scénáře 2006 UOMO 71

Pokročilé typové úlohy a scénáře 2006 UOMO 71 Pokročilé typové úlohy a scénáře 2006 UOMO 71 Osnova Interní model typové úlohy Vazby include a extend Provázanost typových úloh na firemní procesy a objekty Nejčastější chyby 2006 UOMO 72 Interní model

Více

Vývoj IS - strukturované paradigma II

Vývoj IS - strukturované paradigma II Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 05 1/18 Vývoj IS - strukturované paradigma II Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta informačních

Více

Objektově orientované technologie Business proces Diagram aktivit. Daniela Szturcová

Objektově orientované technologie Business proces Diagram aktivit. Daniela Szturcová Objektově orientované technologie Business proces Diagram aktivit Daniela Szturcová Osnova Bysnys proces pojmy metody, specifikace pomocí diagramů Modelování pomocí aktivitního diagramu prvky diagramu

Více

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz UML a jeho použití v procesu vývoje Jaroslav Žáček jaroslav.zacek@osu.cz Různé pohledy na modelování Různé pohledy na modelování Unified Modeling Language UML není metodikou ani programovacím jazykem,

Více

Návrh IS - UML. Jaroslav Žáček

Návrh IS - UML. Jaroslav Žáček Návrh IS - UML Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Trochu historie neuškodí Do roku 1994 chaos ve světě objektově orientovaných metod (několik jazyků pro vizuální modelování,

Více

Architektura informačních systémů. - dílčí architektury - strategické řízení taktické řízení. operativní řízení a provozu. Globální architektura

Architektura informačních systémů. - dílčí architektury - strategické řízení taktické řízení. operativní řízení a provozu. Globální architektura Dílčí architektury Informační systémy - dílčí architektury - EIS MIS TPS strategické řízení taktické řízení operativní řízení a provozu 1 Globální Funkční Procesní Datová SW Technologická HW Aplikační

Více

Globální strategie, IT strategie, podnikové procesy. Jaroslav Žáček

Globální strategie, IT strategie, podnikové procesy. Jaroslav Žáček Globální strategie, IT strategie, podnikové procesy Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Globální podniková strategie Co budeme dělat? Jak to budeme dělat? Jak využijeme IT systémy?

Více

UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Co je to UML Evoluce UML Diagram komponent Diagram odbavení Diagram tříd Aktivity diagram Stavový diagram Sekvenční diagram Diagram

Více

Návrh IS - UML. Jaroslav Žáček

Návrh IS - UML. Jaroslav Žáček Návrh IS - UML Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ UML UML není metodikou ani programovacím jazykem, je to pouze vizuální modelovací nastroj pro objektově orientované systémy.

Více

Modelování procesů (1) Procesní řízení 1

Modelování procesů (1) Procesní řízení 1 Modelování procesů (1) Procesní řízení 1 Vizualizace procesů Znázornění procesu ve formě diagramatického modelu, vede k jeho zpřehlednění a snadnějšímu pochopení. Označuje se jako: procesní mapa, procesní

Více

Objektově orientované technologie Diagram komponent Implementační náhled (Diagram rozmístění) Pavel Děrgel, Daniela Szturcová

Objektově orientované technologie Diagram komponent Implementační náhled (Diagram rozmístění) Pavel Děrgel, Daniela Szturcová Objektově orientované technologie Diagram komponent Implementační náhled (Diagram rozmístění) Pavel Děrgel, Daniela Szturcová Osnova K čemu slouží diagram komponent obsah komponent závislosti rozhraní

Více

Metodika analýzy. Příloha č. 1

Metodika analýzy. Příloha č. 1 Metodika analýzy Příloha č. 1 Příloha č. 1 1 Účel dokumentu Dokument popisuje závaznou metodiku systémové analýzy, je upraven na míru pro prostředí Podniku. Dokument je provázán s Podnikovou analýzou,

Více

Jazyk UML - přehled. diagram hierarchie procesů. IS firmy. podpora řízení. evidence zaměstnanců. pokladny. výroba. diagram procesních vláken

Jazyk UML - přehled. diagram hierarchie procesů. IS firmy. podpora řízení. evidence zaměstnanců. pokladny. výroba. diagram procesních vláken Jazyk UML - přehled Unified Modeling Language jazyk pro popis objektově orientované analýzy a návrhu aplikací slouží k vzájemné komunikaci mezi zadavatelem a návrhářem systému má několik částí, není nutné

Více

Problémové domény a jejich charakteristiky

Problémové domény a jejich charakteristiky Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 02 1/16 Problémové domény a jejich charakteristiky Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta

Více

Návrh softwarových systémů - architektura softwarových systémů

Návrh softwarových systémů - architektura softwarových systémů Návrh softwarových systémů - architektura softwarových systémů Martin Tomášek, Jiří Šebek Návrh softwarových systémů (B6B36NSS) Převzato z přednášky X36AAS M. Molhanec Co je to architektura Využívá se

Více

Vývoj informačních systémů. Přehled témat a úkolů

Vývoj informačních systémů. Přehled témat a úkolů Vývoj informačních systémů Přehled témat a úkolů Organizace výuky doc. Mgr. Miloš Kudělka, Ph.D. EA 439, +420 597 325 877 homel.vsb.cz/~kud007 milos.kudelka@vsb.cz Přednáška Teorie Praxe Cvičení Diskuze

Více

Školení vlastníků procesů aplikace Mapa procesů

Školení vlastníků procesů aplikace Mapa procesů Školení vlastníků procesů aplikace Mapa procesů Krajský úřad Karlovarského kraje Název projektu: Aplikace modelu CAF 2006, reg. č.: CZ.1.04/4.1.00/42.00003 Obsah školení Část 1 Vysvětlení pojmů a struktury

Více

7.6 Další diagramy UML

7.6 Další diagramy UML 7.6 Další diagramy UML 7.6.1 Moduly (balíčky - package) a kolaborace (collaboration) Jak rozložit rozsáhlý systém na menší? - seskupování tříd (prvků modelu) do jednotek vyšší úrovně (package v UML). UI

Více

Softwarová podpora v procesním řízení

Softwarová podpora v procesním řízení Softwarová podpora v procesním řízení Zkušenosti z praxe využití software ATTIS Ostrava, 7. října 2010 www.attis.cz ATTN Consulting s.r.o. 1 Obsah Koncepce řízení výkonnosti Koncepce řízení výkonnosti

Více

Vývoj informačních systémů. Přehled témat a úkolů

Vývoj informačních systémů. Přehled témat a úkolů Vývoj informačních systémů Přehled témat a úkolů Organizace výuky doc. Mgr. Miloš Kudělka, Ph.D. EA 439, +420 597 325 877 homel.vsb.cz/~kud007 milos.kudelka@vsb.cz Přednáška Znalosti Schopnosti Cvičení

Více

Smysl metodiky IS/IT. Koncentrovaná zkušenost Checklist na nic nezapomeneme

Smysl metodiky IS/IT. Koncentrovaná zkušenost Checklist na nic nezapomeneme Smysl metodiky IS/IT Koncentrovaná zkušenost Checklist na nic nezapomeneme Přínosy metodik Větší produktivita a kooperace týmů Komunikační standard Specializace projektových týmů Nezávislost na konkrétních

Více

Modelování informačních systémů s využitím jazyka UML. Jaroslav Šmarda

Modelování informačních systémů s využitím jazyka UML. Jaroslav Šmarda Modelování informačních systémů s využitím jazyka UML Jaroslav Šmarda Využití jazyka UML při vývoji IS na příkladu jednoduché aplikace pro evidenci knih Model IS Modelování případů užití Diagram případů

Více

WORKFLOW. Procesní přístup. Základ perspektivního úspěšného podnikového řízení. Funkčnířízení založené na dělbě práce

WORKFLOW. Procesní přístup. Základ perspektivního úspěšného podnikového řízení. Funkčnířízení založené na dělbě práce WORKFLOW Procesní přístup Základ perspektivního úspěšného podnikového řízení Funkčnířízení založené na dělbě práce Procesní řízení princip integrace činností do ucelených procesů 1 Funkční řízení Dělba

Více

Analýza a Návrh. Analýza

Analýza a Návrh. Analýza Analysis & Design Návrh nebo Design? Design = návrh Není vytváření použitelného uživatelského prostředí (pouze malinká podmnožina celého návrhu) Často takto omezeně chápáno studenty nedokáží si představit,

Více

6 Objektově-orientovaný vývoj programového vybavení

6 Objektově-orientovaný vývoj programového vybavení 6 Objektově-orientovaný vývoj programového vybavení 6.1 Co značí objektově-orientovaný - organizace SW jako kolekce diskrétních objektů, které zahrnují jak data tak chování objekt: OMG: Objekt je věc (thing).

Více

7.6 Další diagramy UML

7.6 Další diagramy UML 7.6 Další diagramy UML 7.6.1 Moduly (balíčky - package) a kolaborace (collaboration) Jak rozložit rozsáhlý systém na menší? - seskupování tříd (prvků modelu) do jednotek vyšší úrovně (package v UML). UI

Více

Algoritmizace prostorových úloh

Algoritmizace prostorových úloh INOVACE BAKALÁŘSKÝCH A MAGISTERSKÝCH STUDIJNÍCH OBORŮ NA HORNICKO-GEOLOGICKÉ FAKULTĚ VYSOKÉ ŠKOLY BÁŇSKÉ - TECHNICKÉ UNIVERZITY OSTRAVA Algoritmizace prostorových úloh Vývojové diagramy Daniela Szturcová

Více

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování 1. Teoretické základy modelování na počítačích 1.1 Lambda-kalkul 1.1.1 Formální zápis, beta-redukce, alfa-konverze 1.1.2 Lambda-výraz jako data 1.1.3 Příklad alfa-konverze 1.1.4 Eta-redukce 1.2 Základy

Více

Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace

Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace Pořadové číslo dodatečných informací: 14. ČÁST 1: Přesné znění žádosti dodavatele o dodatečné informace Otázka

Více

3 druhy UML diagramů

3 druhy UML diagramů UML grafický jazyk se pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů zjednodušuje komunikaci mezi zadavatelem a řešitelem projektu UML podporuje objektově orientovaný přístup

Více

Jak správně psát scénáře k případům užití?

Jak správně psát scénáře k případům užití? Jak správně psát scénáře k případům užití? Autor RNDr. Ilja Kraval 2007 http://www.objects.cz K napsání tohoto článku mne inspiroval tento mail: Dobrý den pane Kravale, chci Vás poprosit o radu, která

Více

UML úvod. Zdroje: Kanisová Hana, Müller Miroslav: UML srozumitelně, Computer Press 2007

UML úvod. Zdroje: Kanisová Hana, Müller Miroslav: UML srozumitelně, Computer Press 2007 UML úvod Kapitola má seznámit se základy modelovacího jazyka UML. Klíčové pojmy: UML, CASE nástroje, procesní modelování, případy užití, role, diagram tříd, diagram objektů, sekvenční diagramy, digram

Více

MOŢNOSTI VYUŢITÍ ROLÍ, AKTORŮ A AGENTŮ PŘI DESIGNU BYZNYS PROCESŮ

MOŢNOSTI VYUŢITÍ ROLÍ, AKTORŮ A AGENTŮ PŘI DESIGNU BYZNYS PROCESŮ MOŢNOSTI VYUŢITÍ ROLÍ, AKTORŮ A AGENTŮ PŘI DESIGNU BYZNYS PROCESŮ Ing. Jan Smolík Vysoká škola finanční a správní PROČ JINÝ ZPŮSOB MODELOVÁNÍ PROCESŮ Základní žurnalistické otázky Co, kdo, kdy, kde, jak,

Více

Modelování procesů (2) 23.3.2009 Procesní řízení 1

Modelování procesů (2) 23.3.2009 Procesní řízení 1 Modelování procesů (2) 23.3.2009 Procesní řízení 1 Seznam notací Síťové diagramy Notace WfMC Notace Workflow Together Editor Aktivity diagram (UML) FirsStep Designer Procesní mapa Select Prespective (procesní

Více

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz RUP - Disciplíny Jaroslav Žáček jaroslav.zacek@osu.cz Disciplíny Množství disciplíny v dané iteraci Disciplíny podle RUP Šest základních: Business modeling - pro pochopení problémové domény Requirements

Více

Communist Party of Nepal (Unified Marxist-Leninist) Unified Modeling Language University of Massachusetts Lowell User-mode Linux.

Communist Party of Nepal (Unified Marxist-Leninist) Unified Modeling Language University of Massachusetts Lowell User-mode Linux. Jan Smolík UML UML Communist Party of Nepal (Unified Marxist-Leninist) Unified Modeling Language University of Massachusetts Lowell User-mode Linux Zdroj: Wikipedia Unified modelling language Neproprietární

Více

4 ARCHITEKTURA PODNIKOVÝCH PROCESŮ S ARISEM

4 ARCHITEKTURA PODNIKOVÝCH PROCESŮ S ARISEM 41 4 ARCHITEKTURA PODNIKOVÝCH PROCESŮ S ARISEM V této kapitole vysvětlíme potřebu strukturované architektury podnikových procesů, a seznámíme se s běžnými typy modelů, používaných v ARISu k reprezentaci

Více

komplexní podpora zvyšování výkonnosti strana 1 Využití Referenčního modelu integrovaného systému řízení veřejnoprávní korporace Město Hořovice

komplexní podpora zvyšování výkonnosti strana 1 Využití Referenčního modelu integrovaného systému řízení veřejnoprávní korporace Město Hořovice strana 1 Využití Referenčního modelu integrovaného systému řízení veřejnoprávní korporace Město Hořovice 19.3.2018 Zpracoval: Roman Fišer, strana 2 1. ÚVOD... 3 2. POPIS REFERENČNÍHO MODELU INTEGROVANÉHO

Více

TÉMATICKÝ OKRUH Teorie zpracování dat, Databázové a informační systémy a Teorie informačních systémů

TÉMATICKÝ OKRUH Teorie zpracování dat, Databázové a informační systémy a Teorie informačních systémů TÉMATICKÝ OKRUH Teorie zpracování dat, Databázové a informační systémy a Teorie informačních systémů Číslo otázky : 16. Otázka : Funkční a dynamická analýza informačního systému. Obsah : 1. Úvod 2. Funkční

Více

Řízení projektů. Centrální podpora projektového řízení projektů realizovaných MVČR (CEPR) Praha,

Řízení projektů. Centrální podpora projektového řízení projektů realizovaných MVČR (CEPR) Praha, Řízení projektů Centrální podpora projektového řízení projektů realizovaných MVČR (CEPR) Praha, 6. 12. 2012 Představení Zpracovatel: SOFO Group a.s. Ovocný trh 572/11 Praha 1 Projektový tým zpracovatele:

Více

GIS Libereckého kraje

GIS Libereckého kraje Funkční rámec Zpracoval: Odbor informatiky květen 2004 Obsah 1. ÚVOD...3 1.1. Vztah GIS a IS... 3 2. ANALÝZA SOUČASNÉHO STAVU...3 2.1. Technické zázemí... 3 2.2. Personální zázemí... 3 2.3. Datová základna...

Více

Základy analýzy. autor. Jan Novotný http://blog.novoj.net/ 15. února 2007

Základy analýzy. autor. Jan Novotný http://blog.novoj.net/ 15. února 2007 Základy analýzy autor Jan Novotný http://blog.novoj.net/ 15. února 2007 V prezentaci jsou použity diagramy z: Wikipedia, Sparx UML Tutorial, Argo UML Metodiky vývoje Různé metodiky vývoje vazba na fáze

Více

EXTRAKT z mezinárodní normy

EXTRAKT z mezinárodní normy EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním ICS 03.220.01; 35.240.60 materiálem o normě. Inteligentní dopravní systémy Požadavky na ITS centrální datové

Více

POPIS STANDARDU CEN TC278/WG7. 1 z 5. draft prenv Geografická silniční databáze. Oblast: ZEMĚPISNÁ DATA V SILNIČNÍ DOPRAVĚ ( GRD)

POPIS STANDARDU CEN TC278/WG7. 1 z 5. draft prenv Geografická silniční databáze. Oblast: ZEMĚPISNÁ DATA V SILNIČNÍ DOPRAVĚ ( GRD) POPIS STANDARDU CEN TC278/WG7 Oblast: ZEMĚPISNÁ DATA V SILNIČNÍ DOPRAVĚ ( GRD) Zkrácený název: GEOGRAFICKÁ DATABÁZE Norma číslo: 14825 Norma název (en): GDF GEOGRAPHIC DATA FILES VERSION 4.0 Norma název

Více

8 Přehled OO metodik (metod, metodologií)

8 Přehled OO metodik (metod, metodologií) 8 Přehled OO metodik (metod, metodologií) 8.1 OO metodiky konce 80. a začátku 90.let - všechny populární OO metodiky předpokládají, že: a) zadavatel má jasný názor na svoje požadavky, b) zadavatel a vývojáři

Více

8 Přehled OO metodik (metod, metodologií)

8 Přehled OO metodik (metod, metodologií) 8 Přehled OO metodik (metod, metodologií) 8.1 OO metodiky konce 80. a začátku 90.let - všechny populární OO metodiky předpokládají, že: a) zadavatel jasný názor na svoje požadavky, b) zadavatel a vývojáři

Více

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Architektury Informačních systémů Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Nutné pojmy Co je to informační systém? Jaké oblasti zahrnuje? Jaká je vazba IS na podnikovou strategii?

Více

VYSOKÁ ŠKOLA BÁŇSKÁ TECHNICKÁ UNIVERZITA OSTRAVA FAKULTA STROJNÍ DATABÁZOVÉ SYSTÉMY ARCHITEKTURA DATABÁZOVÝCH SYSTÉMŮ. Ing. Lukáš OTTE, Ph.D.

VYSOKÁ ŠKOLA BÁŇSKÁ TECHNICKÁ UNIVERZITA OSTRAVA FAKULTA STROJNÍ DATABÁZOVÉ SYSTÉMY ARCHITEKTURA DATABÁZOVÝCH SYSTÉMŮ. Ing. Lukáš OTTE, Ph.D. VYSOKÁ ŠKOLA BÁŇSKÁ TECHNICKÁ UNIVERZITA OSTRAVA FAKULTA STROJNÍ DATABÁZOVÉ SYSTÉMY ARCHITEKTURA DATABÁZOVÝCH SYSTÉMŮ Ing. Lukáš OTTE, Ph.D. Ostrava 2013 Tento studijní materiál vznikl za finanční podpory

Více

Použití standardů. v dokumentu Úvodní studie. Použití standardů

Použití standardů. v dokumentu Úvodní studie. Použití standardů Použití standardů Použití standardů v dokumentu Úvodní studie Určeno pro zákazníky společnosti HARPAGON software s.r.o. Příručka vysvětluje význam jednotlivých standardů UP, UML a BPMN v kontextu dokumentu

Více

7.5 Diagram tříd pokročilé techniky

7.5 Diagram tříd pokročilé techniky 7.5 Diagram tříd pokročilé techniky Stereotypy - jeden ze základních prostředků rozšiřitelnosti UML - pro modelovací konstrukce neexistující v UML, ale podobné předdefinované v UML definované uživatelem

Více

7 Jazyk UML (Unified Modeling Language)

7 Jazyk UML (Unified Modeling Language) 7 Jazyk UML (Unified Modeling Language) 7.1 Základní charakteristika jazyka Motivace - vznik řady OO metod a metodologií (konec 80. let a první polovina 90.let) podobné notace vyjadřující totéž, komplikující

Více

OOT Objektově orientované technologie

OOT Objektově orientované technologie OOT Objektově orientované technologie Logická struktura systému (Diagram tříd) Daniela Szturcová Institut geoinformatiky, HGF Osnova Třídy Statický pohled na systém Atributy a operace, řízení přístupu

Více

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů.

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů. Modely datové Existují různé úrovně pohledu na data. Nejvyšší úroveň je úroveň, která zachycuje pouze vztahy a struktury dat samotných. Konceptuální model - E-R model. Další úrovní je logická úroveň Databázové

Více

MANAŽERSKÉ NÁSTROJE ATTIS

MANAŽERSKÉ NÁSTROJE ATTIS MANAŽERSKÉ NÁSTROJE ATTIS PŘEDSTAVENÍ SW Manažerské softwarové nástroje pro podporu řízení výkonnosti firem a organizací, vytvořené pro manažery na všech úrovních řízení. Soubor metodik, technik a postupů

Více

X36SIN: Softwarové inženýrství. Životní cyklus a plánování

X36SIN: Softwarové inženýrství. Životní cyklus a plánování X36SIN: Softwarové inženýrství Životní cyklus a plánování 1 Kontext Minule jsme si řekli, co to je deklarace záměru, odborný článek, katalog požadavků, seznam aktérů a seznam událostí. Seznam aktérů a

Více

MANAGEMENT Procesní přístup k řízení organizace. Ing. Jaromír Pitaš, Ph.D.

MANAGEMENT Procesní přístup k řízení organizace. Ing. Jaromír Pitaš, Ph.D. MANAGEMENT Procesní přístup k řízení organizace Ing. Jaromír Pitaš, Ph.D. Obsah Definice procesního řízení Výhody procesního řízení Klasifikace procesů podle důležitosti Popis kontextu procesů Základní

Více

Přístupy k řešení a zavádění spisové služby

Přístupy k řešení a zavádění spisové služby Přístupy k řešení a zavádění spisové služby Miroslav Kunt Praha, 22. 3. 2016 Výběr SSl důležité okolnosti Je potřeba zájem vedení organizace, kompetentní pracovníci spisové služby, co největší přiblížení

Více

2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena.

2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. 2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. GEOVAP, spol. s r. o. Čechovo nábřeží 1790 530 03 Pardubice Česká republika +420 466 024 618 http://www.geovap.cz V dokumentu použité názvy programových

Více

7 Jazyk UML (Unified Modeling Language)

7 Jazyk UML (Unified Modeling Language) 7 Jazyk UML (Unified Modeling Language) 7.1 Základní charakteristika jazyka Motivace - vznik řady OO metod a metodologií (konec 80. let a první polovina 90.let) podobné notace vyjadřující totéž, komplikující

Více

Business Intelligence

Business Intelligence Business Intelligence Josef Mlnařík ISSS Hradec Králové 7.4.2008 Obsah Co je Oracle Business Intelligence? Definice, Od dat k informacím, Nástroj pro operativní řízení, Integrace informací, Jednotná platforma

Více

1. Dědičnost a polymorfismus

1. Dědičnost a polymorfismus 1. Dědičnost a polymorfismus Cíl látky Cílem této kapitoly je představit klíčové pojmy dědičnosti a polymorfismu. Předtím však je nutné se seznámit se základními pojmy zobecnění neboli generalizace. Komentář

Více

Jiří Mašek BIVŠ V Pra r ha 20 2 08

Jiří Mašek BIVŠ V Pra r ha 20 2 08 Jiří Mašek BIVŠ Praha 2008 Procesvývoje IS Unifiedprocess(UP) Iterace vývoje Rysy CASE nástrojů Podpora metodických přístupů modelování Integrační mechanismy propojení modelů Podpora etap vývoje Generování

Více

Struktura Pre-auditní zprávy

Struktura Pre-auditní zprávy Příloha č. 1 k Smlouvě o Pre-auditu: Struktura Pre-auditní zprávy 1. Manažerské shrnutí Manažerské shrnutí poskytuje nejdůležitější informace vyplývající z Pre-auditní zprávy. 2. Prohlášení o účelu a cílů

Více

Podrobná analýza k aktivitě č. 3 - implementace procesního řízení do praxe úřadu

Podrobná analýza k aktivitě č. 3 - implementace procesního řízení do praxe úřadu Příjemce dotace: Město Moravská Třebová Název projektu: Zvýšení kvality řízení a poskytovaných služeb MÚ Moravská Třebová Registrační číslo projektu: CZ.1.04/4.1.01/89.00116 Podrobná analýza k aktivitě

Více

MANUÁL PRO STUDENTY ŠKOLNÍ INFORMAČNÍ SYSTÉM

MANUÁL PRO STUDENTY ŠKOLNÍ INFORMAČNÍ SYSTÉM MANUÁL PRO STUDENTY ŠKOLNÍ INFORMAČNÍ SYSTÉM Obsah 1. SLOVO NA ÚVOD... 2 2. MANUÁL K JEDNOTLIVÝM ÚKONŮM... 2 A. PRVNÍ PŘIHLÁŠENÍ DO ŠISU... 2 B. UŢIVATELSKÉ JMÉNO A HESLO... 3 C. ÚVODNÍ STRÁNKA (HOME)

Více

1 Strukturované programování

1 Strukturované programování Projekt OP VK Inovace studijních oborů zajišťovaných katedrami PřF UHK Registrační číslo: CZ.1.07/2.2.00/28.0118 1 Cíl Seznámení s principy strukturovaného programování, s blokovou strukturou programů,

Více

Objektově orientované technologie Dynamický náhled Sekvenční diagram (Realizace UC) Daniela Szturcová

Objektově orientované technologie Dynamický náhled Sekvenční diagram (Realizace UC) Daniela Szturcová Objektově orientované technologie Dynamický náhled Sekvenční diagram (Realizace UC) Daniela Szturcová Osnova Modelování interakcí mezi objekty modelování zpráv (mapování zpráv na operace), vytváření a

Více

Jak používat statistiky položkové v systému WinShop Std.

Jak používat statistiky položkové v systému WinShop Std. Jak používat statistiky položkové v systému WinShop Std. Systém WinShop Std. využívá k zápisům jednotlivých realizovaných pohybů (příjem zboží, dodací listy, výdejky, převodky, prodej zboží na pokladně..)

Více

U Úvod do modelování a simulace systémů

U Úvod do modelování a simulace systémů U Úvod do modelování a simulace systémů Vyšetřování rozsáhlých soustav mnohdy nelze provádět analytickým výpočtem.často je nutné zkoumat chování zařízení v mezních situacích, do kterých se skutečné zařízení

Více

Zkouška ITIL Foundation

Zkouška ITIL Foundation Zkouška ITIL Foundation Sample Paper A, version 5.1 Výběr z více možností Pokyny 1. Měli byste se pokusit odpovědět na všech 40 otázek. 2. Všechny svoje odpovědi vyznačte na samostatný formulář, který

Více

Jan Horák. Pilíře řešení

Jan Horák. Pilíře řešení Jan Horák Pilíře řešení Nová generace systémů Důsledek rozvoje a změn informatiky ve zdravotnictví: Nové technologie Výkonnost, mobilita, velikost monitorů, dotykové ovládání, vzdálené přístupy Nové možnosti

Více

Architektury Informačních systémů. Jaroslav Žáček

Architektury Informačních systémů. Jaroslav Žáček Architektury Informačních systémů Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Nutné pojmy Co je to informační systém? Jaké oblasti zahrnuje? Jaká je vazba IS na podnikovou strategii?

Více

Úvod a teoretický vstup do procesního řízení. Procesy Jičín, Bloky B2 B4 / B5 B7

Úvod a teoretický vstup do procesního řízení. Procesy Jičín, Bloky B2 B4 / B5 B7 Úvod a teoretický vstup do procesního řízení Procesy Jičín, 20. - 21. 1. 2011 Bloky B2 B4 / B5 B7 Program 1. Základní zarámování projektu 2. Teoretický vstup do procesního řízení U1 Některé hlavní problémy,

Více

Management projektů. Programová podpora auditu sytému managementu kvality HOT 4IT. Plán projektu

Management projektů. Programová podpora auditu sytému managementu kvality HOT 4IT. Plán projektu Management projektů Programová podpora auditu sytému managementu kvality HOT 4IT Plán projektu Historie Verze Datum Status Kdo Poznámka 0.1 8. 4. 2010 Špaček Petr Vytvoření 0.2 11. 4. 2010 Špaček Petr

Více

Allegro obchodní doklady

Allegro obchodní doklady Allegro obchodní doklady Modul obchodních dokladů nabízí vše, co je zapotřebí pro obchodování menších a středních firem. K dispozici je evidence nákupu a objednávek materiálu, systém pokrývá celý prodejní

Více

Vývojové diagramy 1/7

Vývojové diagramy 1/7 Vývojové diagramy 1/7 2 Vývojové diagramy Vývojový diagram je symbolický algoritmický jazyk, který se používá pro názorné zobrazení algoritmu zpracování informací a případnou stručnou publikaci programů.

Více

Metody popisu systému, základy UML

Metody popisu systému, základy UML Metody popisu systému, základy UML Strukturovaný přístup Klasickou metodou analýzy a návrhu informačních systémů je strukturovaný přístup, navržený v 70. letech (Tom DeMarco, Ken Orr, Larry Constantine,

Více

Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta. Začínáme s BPM. Učební pomůcka. Vypracoval: Ing.

Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta. Začínáme s BPM. Učební pomůcka. Vypracoval: Ing. Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta Začínáme s BPM Učební pomůcka Vypracoval: Ing. Michael Štencl Brno 2007 OBSAH 2 Obsah 1 Jak přistupovat k BPM 3 2 Prvky BPM

Více

Katalog služeb a podmínky poskytování provozu

Katalog služeb a podmínky poskytování provozu Příloha č. 1 Servisní smlouvy Katalog služeb a podmínky poskytování provozu Část P2_1 P2_1_Katalog služeb a podmínky poskytování provozu 1 Obsah 1 OBSAH... 2 2 DEFINICE POJMŮ... 3 3 DEFINICE SLUŽEB, KOMPONENT

Více

Komputerizace problémových domén

Komputerizace problémových domén Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 03 1/19 Komputerizace problémových domén Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta informačních

Více

Analýza publikačního systému. KÚ Zlínského kraje

Analýza publikačního systému. KÚ Zlínského kraje Příloha č. 0806-12-P07 Analýza publikačního systému KÚ Zlínského kraje 2006 AutoCont CZ a.s. Veškerá práva vyhrazena. Tento dokument obsahuje informace důvěrného charakteru a informace v něm obsaţené jsou

Více