UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

Save this PDF as:
 WORD  PNG  TXT  JPG

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

Download "UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE"

Transkript

1 UNICORN COLLEGE Katedra ekonomiky a managementu BAKALÁŘSKÁ PRÁCE Popis procesů business testování a jejich optimalizace Autor BP: Dalibor Pavlíček Vedoucí BP: Mgr. Julius Čunderlík 2012 Praha

2 Čestné prohlášení Prohlašuji, že svou bakalářskou práci na téma Popis procesů business testování a jejich optimalizace jsem vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou též uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení 11 a následujících autorského zákona č. 121/2000 Sb. V Praze dne Dalibor Pavlíček

3 Poděkování Děkuji vedoucímu bakalářské práci Mgr. Juliusovi Čunderlíkovi za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.

4 Popis procesů business testování a jejich optimalizace Description of the business testing processes and its optimization - 5 -

5 ABSTRAKT Tato práce si klade za cíl analyzovat, navrhnout, popsat a vyhodnotit procesy business testování ve velkých společnostech, jako jsou např. banky pojišťovny a obdobné finanční i nefinanční instituce. Hlavním cílem je vysvětlit, jak je takové testování nastaveno, popsat role, které se na něm podílejí a ověřit funkčnost vstupních a výstupních parametrů v jejich vzájemné kombinaci. Jedná se hlavně o optimalizaci a formalizaci samotných procesů business testování. V oblasti business testování jsem čerpal v některých částech této práce ze své osobní zkušenosti, jelikož na takovém projektu působím v roli Business Test analytika. Aplikace, které jsou v rámci business týmu testovány, jsou nejčastěji prodejní kanály a transakční komponenty. Tato práce je zaměřena na testování přímých kanálů a to zejména internetového bankovnictví. Jelikož jsou bankovní domy většinou obrovské společnosti s tisíci zaměstnanci a stovkou systémů, je problematika vývoje a testování velmi složitá. První část mé diplomové práce je zaměřena na vysvětlení základních pojmů v oblasti testování a základních druhů testů, které jsou využívány v rámci vývoje informačních systémů. Na závěr této části jsou popsány typy testů z obecného pohledu. Druhá část analyzuje business testování v bankovní společnosti, popisuje průběh pilotního projektu business testovacího týmu a vyhodnocuje jeho výstupy. V poslední části je popsán návrh testovací strategie a testovacího plánu, který je sestaven na základě vyhodnocení pilotního projektu. Klíčová slova: Business testování, tester, test analytik, testovací strategie, chyba, testovací plán, aplikace - 6 -

6 ABSTRACT This work aims to analyze, describe and evaluate business testing processes in large companies such as banks. The main objective is to explain setting of the testing, describe the roles that work together and verify the functionality of inputs and outputs parameters in their combination. Representation covers mostly the optimization and the formalization of business processes. The field of business testing was also covered by using own experience from real project I've participated in as Business Test analytic. The subjects of testing applications in banks are mainly sales channels and transactional components. This work is focused on testing direct channels, especially internet banking. The banking sector is dependent on its sales channels and recently more clients started using internet banking and the overall demands increased on the product quality. Banks are usually large companies with thousands of employees and hundreds of systems, the issue of development and testing is very complex. The first part focuses on explaining the basic concepts in testing and reveals the basic types of tests that are used in software development. In the end of this section, the types of tests are described from a wider concept. The second part analyzes the testing business in the banking company, describes the implementation of pilot projects and evaluates the outcomes. The last section describes the design of test strategy and test plan, which are compiled based on evaluation of the pilot operation. Keywords: Business testing, tester, test analyst, test strategy, error, test plan, application - 7 -

7 OBSAH 1. Úvod Úvod do problematiky testování Psychologie softwarového testování Základní pojmy Softwarová chyba Kvalita software Verifikace a validace Testovací plán Testovací případ Testovací skript Testovací scénář Typy testů Viditelnost zdrojového kódu Black box Testování černé skříňky White box Testování bílé skříňky Grey box Testování šedé skříňky Rozdělení dle způsobu Statické testování Dynamické testování Automatizované testování Manuální testování Rozdělení dle času Testování jednotek Integrační testování Systémové a integrační testování Akceptační testování Typy testování Testování konfigurace Postup při testování konfigurace Testování kompatibility

8 6.2.1 Postup při testování kompatibility Testování použitelnosti Testování webových aplikací Testování konfigurace a kompatibility Testování použitelnosti Business testování Záměr Business testovací tým Definice kompetencí rolí Pilotní provoz business testovacího týmu Přínosy business testů na projektu Alfa Průběh testů projektu Alfa Zaznamenané problémy v průběhu testů Chyby nalezené v průběhu business testování Vyhodnocení Shrnutí a další postup Test plán a strategie projektu BETA Úvod Harmonogram testů Free testy Další důležité informace Příprava dat Zahájení UAT Příprava dat na UAT Průběh UAT Další důležité informace k UAT Zaznamenávání chyb JIRA nástroj pro evidenci chyb Závažnost chyb Testovací skripty Testovací tým Akceptační kritéria převzetí do UAT testů Akceptace převzetí do technického pilotu

9 8.9 Vyhodnocení a ukončení testů Závěr Conclusion Seznam použité literatury Seznam použitých symbolů a zkratek Seznam obrázků Seznam tabulek

10 1. ÚVOD Téma testování software jsem si vybral proto, že se již pár let pohybuji v této oblasti a nadále bych se chtěl touto disciplínou zabývat. Pracuji pro jeden z nejvýznamnějších bankovních domů v České republice a jsem v každodenním styku s aplikacemi, které využívají tisíce lidí každý den. Vývoj těchto produktů je extrémně náročný, jelikož na projektech participují desítky lidí a řízení takového týmu není jednoduché. Jsem rád, že jsem mohl být u zrodu business testovacího týmu, což pro mě byla obrovská zkušenost a který je i předmětem této práce. První část práce má za úkol seznámit s obecným pohledem na testování a nastínit různé typy testů, které se běžně používají na projektech a které jsou definovány v metodice testování. Nedílnou součástí první poloviny práce je představení základních typů dokumentace, bez které se důkladné a rozsáhlé testování neobejde. Testovací dokumentace je jeden z hlavních parametrů, na nichž závisí úspěch projektu. Tato část je spíše obecným pohledem na problematiku testování software, bez které se však toto odvětví vývoje software neobejde. V druhé části této práce je konkrétní příklad některých dokumentů, o kterých se zmiňuje část první. Tato část se rozděluje na další důležité prvky a to analýzu, popis a vyhodnocení pilotního projektu business testovacího týmu. Projekt Alfa, který je v rámci této studie podroben analýze, byl prvním projektem, který svými testy zastřešil právě tento nově vzniklý tým. Hlavní důvodem vzniku tohoto týmu byla absence řízeného a metodicky správného testování na straně business oddělení. Tato analýza poté slouží jako podklad pro závěrečnou část práce, kterou je návrh testovacího plánu a strategie pro testování Projektu Beta. Celá druhá část pojednává o vzniku a stabilizaci business testovacího týmu. Má za úkol poukázat na rozdíly mezi prvním pilotním projektem, na který nebyl dostatek času a druhým projektem, který se již precizně plánuje dopředu a na kterém můžeme pozorovat vliv zkušeností a znalostí načerpaných během pár let existence tohoto týmu

11 2. ÚVOD DO PROBLEMATIKY TESTOVÁNÍ Je zřejmé, že v jednadvacátém století ovládá IT téměř každou oblast našeho života. Již dnes můžeme říci, že informační a telekomunikační technologie jsou všude kolem náš a těžko bychom si bez nich představili život. Člověk s nimi žije již v takové symbióze, že pomalu ztrácí povědomí o tom, jak jsou informační technologie důležité a pro náš život v podstatě nepostradatelné. Bez těchto technologií by většina činností trvala mnohem více času, těžko bychom si např. vybírali peníze kdekoliv na ulici z bankomatu. Existují však i takové oblasti, které jsou na informačních a telekomunikačních technologiích zcela závislé. A právě na tyto oblasti, vyžadující nespočet aplikací a systémů, které ve své podstatě musí fungovat téměř bezchybně, jsou kladeny velmi vysoké nároky. Zde vzniká první zásadní problém, který se dotýká vývoje a následného fungování různorodých aplikací a systémů, řídících a podporujících životy nás všech. Tím hlavním problémem je ona zmiňovaná bezchybnost. Co si představit pod tímto pojmem, rozebírají jiné kapitoly této práce, ale obecně lze na tento parametr nahlížet z různých úhlů. Nelze srovnávat např. systémy a infrastrukturu obsluhy letištní kontroly s webovými aplikacemi pro volný čas. Není nutné popisovat problematiku těchto dvou systémů, aby bylo jasné, jaký rozdíl je mezi požadavkem na kvalitu každého z nich. Je jasné, že se každá společnost, která se zabývá vývojem systémů, snaží o co nejdokonalejší produkt. Když se na toto tvrzení podíváme pohledem vývojářů tak můžeme tvrdit, že nelze naprogramovat systém bez chyby. Co nám tedy pomůže tento problém eliminovat a vyvarovat se selhání v budoucnosti? Odpovědí je softwarové testování, jehož hlavním cílem je chyby v programu odhalit a nechat následně odstranit. Bez precizního otestování je nasazení určitých systémů velmi rizikové. Chyby, které systém generuje jak při vývoji, tak např. při nasazení do provozu mají určitou hodnotu. Obecně můžeme tvrdit, že čím dříve je chyba odhalena, tím nižší jsou náklady na její odstranění [4]

12 3. PSYCHOLOGIE SOFTWAROVÉHO TESTOVÁNÍ Základním předpokladem pro správné pochopení problematiky testování je pochopení jeho definice. Často se můžeme setkat s následujícím názorem: Testováním demonstrujeme to, že se v programu nevyskytují chyby. 1 Avšak tato definice není zcela správná. Testování programu dává produktu přidanou hodnotu, zvyšuje jeho konkurenceschopnost a možnost jeho využití. Tím, že budeme dokazovat bezchybnost systému, nikdy nebudeme efektivně testovat. Produktu přidáme hodnotu pouze tím, že budeme chyby hledat a následně opravovat a tím a vlastně dokazovat, že program není bezchybný. Testování systému je proces hledání chyb v co největším počtu - Testování je proces procházení programu s úmyslem najít chyby. 2 Lidé se rádi orientují na nějaký cíl a jeho stanovení má pro ně významný psychologický efekt. Je-li naším cílem prokázat, že program nemá žádné chyby, potom budeme podvědomě řízeni ke splnění tohoto cíle a budeme mít tendenci vybrat takové testy funkčností, které mají nízkou pravděpodobnost selhání programu. Jestliže je však naším cílem ukázat, že program má chyby, bude existovat vyšší pravděpodobnost, že chyby nalezneme. Testování je ve své podstatě vlastně destruktivní proces a většina lidí ho proto shledává jako náročnou disciplínu. Většina lidí má spíše konstruktivní, nikoli destruktivní pohled na život. Lidé mají spíše sklony k tvorbě než k rozbíjení nějakých objektů na části a nalézání jejich nedostatků. Dalším psychologickým jevem, kterým můžeme lépe pochopit podstatu testování programu, je správná analýza a použití slov "úspěšný" a "neúspěšný". Zejména jejich použití projektovými manažery při vyhodnocování výsledků exekuce testovacích případů. Většina projektových manažerů nazývá testovací případ, kde nebyla nalezena žádná chyba jako úspěšný test. Zatímco test, který objevil novou chybu, je obvykle nazýván jako neúspěšný. To však není zcela správná definice. Slovo "neúspěšný" označuje něco, co je nežádoucí nebo co nesplnilo svůj účel. Při správném způsobu pochopení testování, správně navržený a provedený test je úspěšný, pokud zjistí chyby, které mohou být opraveny a nebo když zjistíme, že neexistují žádné další chyby. Jediný neúspěšný test je ten, který není správně navrhnut a který neotestuje software tak, jak by měl. 1 Myers, G. J.; The ART of SOFTWARE TESTING, 2.nd ed.; Word Association, Inc.: New Jersey, 2004, s Myers, G. J.; The ART of SOFTWARE TESTING, 2.nd ed.; Word Association, Inc.: New Jersey, 2004, s

13 4. ZÁKLADNÍ POJMY Tato kapitola popisuje základní pojmy v oblasti procesu testování software, jejichž znalost je důležitá, chceme-li se pohybovat v prostředí, které popisuje problematiku programového testování. V této práci jsou použity mnohokrát a bez jejich znalosti může být způsob interpretace chybný. 4.1 Softwarová chyba V obyčejném životě můžeme na něco ukázat a říci, že je to chyba. To samé můžeme aplikovat i v oblasti testování, ale v praxi to samozřejmě není takto jednoduché a proto je potřeba v první řadě správně definovat pojem chyba. Dokument, který může poměrně výrazně změnit pohled na to, co je chyba, nazýváme specifikace produktu. Specifikace je dohoda mezi dodavatelem a zadavatelem, popisuje chování systému, jeho funkčnosti a zejména to, co bude dělat a co dělat nebude. Tato dohoda může mít různé podoby, od ústní až po psaný dokument [5, s. 13]. O softwarové chybě mluvíme tehdy, jestliže: Software nedělá něco, co by podle specifikace produktu dělat měl, Software dělá něco, co by podle specifikace dělat neměl, Software dělá něco, o čem se produktová specifikace nezmiňuje, Software nedělá něco, o čem se produktová specifikace nezmiňuje, ale měla by se zmiňovat, Software je obtížně srozumitelný, těžko se s ním pracuje, je pomalý, nebo podle názoru testera softwaru jej koncový uživatel nebude požadovat za správný. Vysvětlili jsme si pojem softwarová chyba, ale proč vznikají a co jejich příčinou? Jako první se nabízí nejjednodušší možná příčina, která vyplývá z logiky testování chyba je způsobena selháním aplikace. Pravda je však jiná, největší podíl nalezených chyb můžeme přičíst především chybám ve specifikaci [5, s. 14]

14 Obrázek 1: Příčiny vzniku chyb Zdroj:[5] Vlastní zpracování 4.2 Kvalita software Metodika RUP definuje kvalitu jako určitou úroveň uspokojení potřeb uživatelů systému. Protože každý uživatel má jiné požadavky a očekávání a není možné stanovit tuto úroveň jednotně, byl definován rozšířený seznam parametrů dimenze kvality. Někdy bývají dimenze souhrnně označovány FURPS. Jednotlivé dimenze jsou následující [4]: Funkčnost správná funkčnost produktu dle funkční specifikace, Použitelnost jaké úsilí musí uživatel vynaložit při práci s produktem, jestli je uživatelsky přívětivý dobře se s ním pracuje, Spolehlivost definuje chování produktu v různých nestandardních situacích celková robustnost systému Výkon jak se produkt chová při souběžné práci více uživatelů, kolik systémových zdrojů odebírá atd., Podporovatelnost zda lze produkt bez problémů nainstalovat, zda dokáže dobře spolupracovat s novými verzemi určitých komponent atd. [7]

15 Často se můžeme v oblasti testování setkat s názorem, že kvalita je spolehlivost produktu, což je však chybná úvaha. Jestliže program dosáhne úrovně, že je vysoce stabilní, důvěryhodný a spolehlivý, nemůžeme ještě v žádném případě tento produkt označit jako vysoce kvalitní. Tím, že je produkt spolehlivý, jsme ověřili jen jednu část celkového pohledu na kvalitu. Kvalita je tedy souhrnem vlastností a charakteristik výrobku, procesu nebo služby, který ukazuje jeho schopnost splnit určené nebo odvozené potřeby Verifikace a validace Pojmy, které úzce souvisí s kvalitou, jsou mimo jiné také verifikace a validace. Verifikaci můžeme chápat jako činnost, jenž má za cíl potvrdit, že produkt vyhovuje specifikaci. Na druhou stranu validace sleduje, jestli je produkt v souladu s požadavky uživatele. Na první pohled se můžou zdát tyto pojmy velmi podobné, přesto je zde významný rozdíl. Pro lepší pochopení slouží následující příklad: Začátkem roku 1990 byl na oběžnou dráhu vypuštěn Hubbleův zrcadlový teleskop. Testování zrcadla bylo velice obtížné, na zemském povrchu se nedal natočit a nedalo se s jeho pomocí pozorovat. Proto se v rámci testů pečlivě proměřily všechny atributy a výsledky se porovnaly se specifikovaným zadáním. Po těchto testech byl teleskop schválen a vypuštěn do kosmu. Po uvedení do provozu se zjistilo, že teleskop vrací neostré obrázky. Zrcadlo bylo vybroušeno přesně podle specifikace, ale tato specifikace byla nesprávná. Zrcadlo bylo mimořádně přesné, ale nebylo správné. Testování ověřilo, že teleskop vyhovuje specifikaci provedla se jeho verifikace, ale nebylo možné potvrdit, zda vyhovuje původním požadavkům nebyla provedena validace těchto požadavků na výsledném produktu. 4 3 PATTON, Ron. Testování softwaru. s Testování SW [online] [cit ]. Dostupné z WWW: < https://unicornuniverse.eu//>

16 4.4 Testovací plán Testovací plán (občas se používá také pojem Globální testovací plán viz RUP) je dokument, který obsahuje informace o všem, co je potřeba definovat v rámci přípravy testů. Jeho rozsah je široký a měl by popsat všechny subjekty, které do testování zasahují a které by mohly být v rámci procesu řešeny [5, s. 211]. Správný plán testování by měl obsahovat: Zdroje Detailní popis rolí/osob, které budou na projektu pracovat, definice jejich úkolů a specifikace komunikačních kanálů. Nedílnou součástí by mělo být přesné popsání úložiště sdílených dokumentů a dalších nezbytných souborů, které budou na projekty použity. Může se například jednat i o testovací hardware, jeho úložiště, přístupová povolení atd. Obecně lze tuto část využít i jako základní informace pro nové členy týmu, základní overview, které nezbytně potřebují ke své práci [5, s. 214], Definice pojmů Slovník alespoň nejdůležitějších výrazů popisující jejich přesný význam a chápání na daném projektu u daného klienta. Jedna z nejdůležitějších částí dokumentu, jelikož správné a stejné chápaní pojmů je jednou z hlavních podmínek při kooperaci. Musíme si uvědomit, že na projektech bývá zainteresována veliká řada různých rolí, s různými zkušenostmi a jejich výklad může být rozdílný, což může mít fatální následky [5, s. 214], Vzájemné povinnosti mezi skupinami Popisuje povinnosti mezi skupinami, které spolupracují na projektu a mohou mít vliv na testovací práce. Práce samotného testovacího týmu je podřízena mnoha dalším týmům programátorům, analytikům, správcům prostředí atd. Zvláště ve velkých vývojových týmem musí být této části věnována velká pozornost [5, s. 215], Co se bude a nebude testovat Může se stát, že nebude nutné testovat všechny části produktu, jelikož byly např. otestovány dříve, nebo byly otestovány dodavatelskou společností. V procesu plánování je proto potřeba popsat každou komponentu a určit, zda bude testována či nikoliv. Při rozhodnutí, že se daná komponenta nebude vůbec testovat, je nutné definovat z jakého důvodu a kdo je za toto rozhodnutí kompetentní [5, s. 217],

17 Testování v jednotlivých fázích vývoje Při plánování jednotlivých fází vývoje je nezbytné analyzovat navržený model vývoje a určit, jaké typy testů budou v průběhu vývoje probíhat. Tato část je závislá na metodice vývoje, čili nelze obecně určit, jaké typy testů a kdy je vhodné použít. Je nezbytné každý typ testování přesně popsat a ukázat projektovému týmu. Zároveň je nezbytné určit kritéria, za kterých se do jednotlivých fází vstupuje a za kterých se z nich vystupuje (tzv. entry a exit kritéria) [5, s. 217], Strategie testování Popisuje postupy, kterými bude testovací tým software testovat. Musí obsahovat popis celkového plánu testování a zároveň definici testů v jednotlivých fázích vývoje. Jedná se o rozhodnutí, jakým způsobem a jakým typem testů bude software ověřen. Jaké nástroje budou použity atd. Této části plánování by měla být věnována zvláštní pozornost, jelikož je na ni závislý úspěch celého testování. Ve většině případů obzvláště na větších projektech jde o samostatný dokument [2, s. 40], Pověření testerů Jestliže už jsou vyřešeny požadavky na prostředí a je určena strategie testování, můžeme přiřadit oblasti jednotlivým členům projektu, kteří se budou testováním zabývat (Tester) [5, s. 218], Časový plán testů Návrh časového plánu testů vychází z dosud zjištěných informací a je promítnut do celkového plánu postupu prací na projektu. Jedná se zřejmě o nejkritičtější část plánování testů. Důležitým parametrem je rozdělení objemu testovacích prací, jelikož ty nejsou v celém životním cyklu projektu rozděleny rovnoměrně. Toto plánování je důležité i z kapacitních důvodů, jelikož řeší i jednotlivé alokace. Jedná-li se o větší projekt a na testování je potřeba velké množství testerů, je kriticky důležité přesně naplánovat jejich využití [5, s. 219], Testovací případy, skripty a scénáře obsahuje seznam testovacích případů, skriptů a scénářů, podle kterých bude aplikace ověřena vychází z funkční specifikace [5, s. 220], Zprávy o chybách Popisuje způsob, jakým způsobem budou nalezené chyby reportovány. Tato část je velmi variabilní a na každém projektu se můžete setkat s jiným uspořádáním. Základem by měl být nástroj, který slouží k zaznamenávání

18 chyb. Dále je důležité určit způsob, jakým se bude chybám přidělována závažnost [5, s. 221], Metriky a statistiky Jedná se o prostředky k měření a sledování průběhu testování. Během procesu plánování musíme přesně identifikovat všechny parametry, které budeme sledovat a určit rozhodnutí, které budeme na základě jejich vyhodnocení provádět. Mezi testovací metriky patří celkový počet chyb za jeden den testů, seznam otevřených chyb, rozdělení chyb dle závažnosti, počet úspěšně dokončených testovacích skriptů a počet skriptů, které nemohly být dokončeny s určením důvodu [5, s. 221], Rizika a problémy Jedná se o soupis potenciálních problémů a rizik, které by mohly v průběhu testování nastat a které by mohly mít významnější dopad na výsledek testů [5, s. 221]. 4.5 Testovací případ Testovací případ (test case) popisuje, jak postupovat při testování daného požadavku. Podrobně definuje, jak otestovat požadovanou funkčnost, jaké parametry mají být zvoleny na vstupu a jaké by se nám měly vrátit na výstupu. Podle normy ANSI/IEEE 829 dokumentuje testovací případ skutečnou hodnotu vstupů spolu s očekávanými výsledky. Testovací případ by měl také popisovat veškerá omezení v procesu testování, vyplývajících z určitého testovacího případu. Každý testovací případ by měl obsahovat tyto náležitosti [13]: Identifikátor Jedinečný identifikátor odkazující na specifikaci návrhu testů a specifikaci testovacích procedur, Testovaná položka Popis testované funkce. Tento popis by měl být podrobnější, než je uvedeno v testovacím plánu. Dále je zde uveden např. odkaz na specifikaci produktu, či jiné dokumenty spojené s testovacím případem, Specifikace vstupů V této části jsou definované všechny vstupy nebo podmínky, které před provedením testovacího případu do programu vložíme,

19 Specifikace výstupů Zde jsou definované všechny výsledky, které jsou očekávané po provedení testovacího případu, Požadavky na prostředí Tato část popisuje vše, co je k provedení testovacího případu potřeba. Může se jednat o software, hardware, uživatele, služby atd., Zvláštní požadavky V této části jsou uvedeny všechny ostatní neobvyklé parametry, které jsou nutné provádět před nebo při samotném testování. 4.6 Testovací skript Testovací skript je v podstatě postup, jak se bude určitý testovací případ vykonávat. Testovací skript je realizace testovacího případu za použití konkrétních specifikovaných dat. Testovací skript krok za krokem definuje způsob, jakým je testovací případ prováděn. Nedílnou součástí testovacího skriptu jsou následující informace [12]: Identifikátor Jedinečný identifikátor odkazující na testovací případ a návrh testů, Účel Pro jaký účel skript vznikl a k jakému testovacímu případu se váže, Zvláštní požadavky Jiné procedury a postupy, dovednosti nebo zvláštní vybavení, které je při vykonávání skriptu potřeba, Kroky skriptu Detailní popis způsobu provádění testů. Testovací skript může obsahovat následující části, které již nejsou zcela nezbytné: Záznam Definuje, jakou metodou a jakým způsobem se budou výsledky testu zaznamenávat, Příprava Určuje, co je potřeba připravit k testu, Zahájení Popisuje, co všechno je potřeba k zahájení testu, Skript Popis jednotlivých kroků s postupem testování, Měření výsledků Způsob určování výsledků, Předčasné zastavení Popisuje kroky pro přerušení testu z důvodu neočekávané chyby, Obnovení Určuje, jak má tester postupovat při přerušení testu a jak má pokračovat,

20 Ukončení Definuje kroky pro ukončení testu, Úklid Popis kroků pro obnovu prostředí pro další testy, Mimořádná opatření Způsob jak postupovat v případě, kdy testy neprobíhají podle plánu. Podoba testovacích skriptů se v praxi velmi liší. Forma jedné z možnosti, jak sestavit takový skript ukazuje obrázek 2. Obrázek 2: Test skript Systém: Projekt: Funkční oblast: Identifikátor: Název scénáře: Autor: Datum: Délka testu: Datum provedení: Tester: Verze aplikace: Poznámka: Účel 1 2 Zvláštní požadavky 1 2 Testovaný tok: Typ kroku Krok číslo Popis 1 Vstupní data ->TESTER PROVÁDÍ AKCI Očekávané výsledky ->TESTER KONTROLUJE VÝSLEDEK Komentáře Záznam ("P"=OK, "N"=chyba, "X"=nemožno provést) Zdroj: vlastní zpracování 4.7 Testovací scénář Návrh testů nebo testovací scénář je složen z testovacích případů, které na sebe logicky navazují a musí být vykonávány v určitém pořadí. Struktura testovacího scénáře se

21 může podobat struktuře Specifikace požadavků, jelikož cílem by mělo být pokrytí všech požadavků testovacími případy. Struktura návrhu může mít následující podobu [11]: Testované vlastnosti Jedná se o soupis požadavků, které by měly být testy pokryty, Přístup k testování Každý z přístupů vyžaduje jinou dovednost. Mezi tyto přístupy patří zejména způsob testování (black, white nebo grey box) a různé typy testů (Unit testy, integrační atd.), Testovací skripty - určuje testovací skripty, které jsou použity ve scénáři, Kritéria Obecně definuje kritéria, za jakých můžeme prohlásit, že test prošel či nikoliv

22 5. TYPY TESTŮ 5.1 Viditelnost zdrojového kódu Obrázek 3: Rozdělení testů z hlediska zdrojového kódu Zdroj: [11] Vlastní zpracování Black box Testování černé skříňky Testování černé skříňky znamená, že testujeme, aniž bychom v podstatě viděli kód aplikace. Nevíme přesně, jak daná aplikace funguje, jen sledujeme, jak reaguje na naše vstupy. Tento typ testování se také často nazývá testem chování, jelikož ověřujeme, jak se aplikace chová v interakci s uživatelem. Abychom mohli testovat účinně, potřebujeme specifikaci aplikace, abychom věděli, jak se má v určitých momentech chovat. Nepotřebujeme vědět, co se děje uvnitř. Obecně můžeme říct, že tyto testy jsou charakteristické tím, že se chováme jako běžný uživatel [3, s. 50] White box Testování bílé skříňky Testování bílé skříňky se provádí tím způsobem, že vidíme a máme přístup k programovému kódu a můžeme jej kontrolovat. Často se nazývá strukturální testování, jelikož při návrhu a samotné exekuci testů využíváme podkladovou strukturu kódu programu. Tyto informace jsou běžnému uživateli nepřístupné. Výhodou je, že tester může lépe odhalit vznik chyby a může předvídat slabá místa aplikace [6, s.141] Grey box Testování šedé skříňky Později vznikl i další typ testu dle přístupu šedá skříňka. Jedná se o střed mezi černou a bílou skříňkou. Tester sleduje chování aplikace, ale má k dispozici i nějakou část

23 zdrojového kódu. Bývá to např. algoritmus výpočtu funkce, matematické principy využité v aplikaci atd. [4] 5.2 Rozdělení dle způsobu Obrázek 4: Rozdělení testů z hlediska způsobu Zdroj: [10] Vlastní zpracování Statické testování Tento způsob testování je specifický tím, že se jedná o testy produktu, který není spuštěný. Netestujeme jednotlivé funkčnosti za běhu aplikace, ale prohlížíme ji a revidujeme. Můžeme revidovat specifikaci, zdrojový kód atd. Výhodou je, že lze začít testovat ještě před vyvinutím prvního funkčního prototypu [10] Dynamické testování Jedná se o testování aplikace za běhu. To znamená klasické testování funkčností a reakcí na vstupy uživatele [10] Automatizované testování Tam, kde testování aplikace nevyžaduje významný podíl lidského úsudku a funkčnost se nemění na rozdíl od zadávaných vstupních parametrů, lze použít libovolný nástroj, který zvládne automatizovaně otestovat část aplikace. K tomu je potřeba programově napsat, co se má otestovat, s jakými vstupními parametry a spustit test. Automat projíždí aplikaci a výsledkem je předem definovaný report s chybami, které automat odhalil. Je tedy potřeba mít testovací nástroj, vstupní a výstupní data a hlavně testovanou aplikaci, která podporuje skrze své rozhraní automatizaci procesů. Nejběžnější použití automatizovaných testů je

24 v zátěžových testech, ale dají se v zásadě použít i v jiných oblastech [9]. Automatizované nástroje pro testování nemohou v žádném případě testery softwaru nahradit pouze jim pomáhají odvádět jejich práci snáze a lépe. 5 Výhody AT: Velmi nízké náklady na provoz, Absence lidské chyby, Možnost testovat velké množství vstupů a výstupů, Není zde časový limit (může pracovat celý den), Paralelnost. Nevýhody AT: Vysoké vstupní náklady na pořízení, Potřeba zkušených obsluhujících pracovníků, Tvorba testů je časově náročná Manuální testování Standardní testování uživatelem, který využívá svého úsudku zkušeností a intuice. Výhodou je, že uživatel může lépe reagovat na vzniklé situaci, přesněji vyhodnotí slabá místa aplikace a nevyžaduje před testy tolik příprav jako automatizované testy. Na druhou stranu však jeho výsledky mohou být dost subjektivní, není to stroj, takže je možné, že opomene otestovat nějakou funkčnost a v některých případech nemusí zcela porozumět problematice daného testu, čímž může snížit jeho kvalitu [11]. Výhody MT: Obecně jednoduchost, Není potřeba drahých nástrojů, Ve většině případů jsou dostačující méně zkušení pracovníci. 5 PATTON, Ron. Testování softwaru. s

Obsah. Úvod 9 Poděkování 10 Co je obsahem této knihy 10 Pro koho je tato kniha určena 11 Zpětná vazba od čtenářů 11 Errata 11

Obsah. Úvod 9 Poděkování 10 Co je obsahem této knihy 10 Pro koho je tato kniha určena 11 Zpětná vazba od čtenářů 11 Errata 11 Úvod 9 Poděkování 10 Co je obsahem této knihy 10 Pro koho je tato kniha určena 11 Zpětná vazba od čtenářů 11 Errata 11 KAPITOLA 1 Co je třeba znát aneb důležité pojmy 13 Krátce o požadavcích 13 Stakeholdeři

Více

Zátěžové testy aplikací

Zátěžové testy aplikací Zátěžové testy aplikací Obsah Zátěžové testy v životním cyklu vývoje software Kdy a proč provádět zátěžové testy Projekt zátěžového testu Fáze zátěžového testu Software pro zátěžové testy Zátěžové testy

Více

SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE

SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE Václav Šebesta Ústav informatiky Akademie věd ČR, e-mail: vasek@cs.cas.cz Abstrakt Jestliže ještě před

Více

A7B36SI2 Tematický okruh SI11 Revidoval: Martin Kvetko

A7B36SI2 Tematický okruh SI11 Revidoval: Martin Kvetko Obsah Kvalita SW, jak zajistit kvalitu SW a jak ji ověřit Zabezpečení kvality, techniky řízení kvality SW. Potřeba kultivovat kvalitu, Cena za jakost Procesy pro řízení kvality, harmonogram řízení kvality

Více

Indexace pro souborová uložiště a Vyhledávací centrum

Indexace pro souborová uložiště a Vyhledávací centrum Indexace pro souborová uložiště a Vyhledávací centrum Obsah I. Úvod... 2 II. Cíl dokumentu... 2 III. Fáze projektu... 2 IV. Popis jednotlivých fází projektu... 2 1. Fáze 1. - Analýza... 2 2. Fáze 2. -

Více

KATALOG SLUŽEB NÁSLEDNÉ PODPORY

KATALOG SLUŽEB NÁSLEDNÉ PODPORY KATALOG SLUŽEB NÁSLEDNÉ PODPORY Společnost WEBCOM a. s. Vám nabízí kompletní pokrytí Vašich požadavků na zajištění služeb technické podpory Microsoft Dynamics přesně podle Vašich potřeb a v požadovaném

Více

1. Úvod do Ajaxu 11. Jak Ajax funguje? 13

1. Úvod do Ajaxu 11. Jak Ajax funguje? 13 Obsah Úvodem 9 1. Úvod do Ajaxu 11 Jak Ajax funguje? 13 Popis 13 Ukázky 13 Jaké jsou možnosti tvorby interaktivních webových aplikací? 15 Co je třeba znát? 16 Jak fungují technologie Ajaxu 16 Jak funguje

Více

Ročníkový projekt. Jaroslav Žáček jaroslav.zacek@osu.cz

Ročníkový projekt. Jaroslav Žáček jaroslav.zacek@osu.cz Ročníkový projekt Jaroslav Žáček jaroslav.zacek@osu.cz Cíle předmětů Vytvoření fungující aplikace, která splňuje definované požadavky Vyzkoušet si celý životní cyklus projektu - specifikace zadání, formování

Více

Bezpečnostní politika společnosti synlab czech s.r.o.

Bezpečnostní politika společnosti synlab czech s.r.o. Bezpečnostní politika společnosti synlab czech s.r.o. Platnost dokumentu: 14. ledna 2015 Datum vypracování: 8. ledna 2015 Datum schválení: 13. ledna 2015 Vypracoval: Schválil: Bc. Adéla Wosková, Ing. Jaroslav

Více

Příloha č. 2. Charta projektu plné znění (pro MŠMT/ČŠI a příspěvkové organizace zřízené MŠMT)

Příloha č. 2. Charta projektu plné znění (pro MŠMT/ČŠI a příspěvkové organizace zřízené MŠMT) Příloha č. 2. Charta projektu plné znění (pro MŠMT/ČŠI a příspěvkové organizace zřízené MŠMT) Charta projektu má za cíl poskytnout úplné a pevné informační základy pro schválení projektu. Následně je Charta

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

Uživatelská dokumentace

Uživatelská dokumentace Uživatelská dokumentace Konfigurace webového prohlížeče Verze 01-04 2013 e-utilityreport - vyjadřování k existenci sítí OBSAH OBSAH... 2 1. O SLUŽBĚ E-UTILITYREPORT... 2 2. NASTAVENÍ PROSTŘEDÍ... 3 2.1

Více

KAPITOLA 2 - ZÁKLADNÍ POJMY INFORMAČNÍCH A KOMUNIKAČNÍCH TECHNOLOGIÍ

KAPITOLA 2 - ZÁKLADNÍ POJMY INFORMAČNÍCH A KOMUNIKAČNÍCH TECHNOLOGIÍ KAPITOLA 2 - ZÁKLADNÍ POJMY INFORMAČNÍCH A KOMUNIKAČNÍCH TECHNOLOGIÍ KLÍČOVÉ POJMY Internet World Wide Web FTP, fulltext e-mail, IP adresa webový prohlížeč a vyhledávač CÍLE KAPITOLY Pochopit, co je Internet

Více

InternetovéTechnologie

InternetovéTechnologie 8 InternetovéTechnologie webdesign, mobile first Ing. Michal Radecký, Ph.D. www.cs.vsb.cz/radecky Webové stránky a aplikace - Webové stránky - množina vzájemně propojených stránek, které obsahují informace

Více

Virtualizace serverů v ČSOB

Virtualizace serverů v ČSOB 5 Shared Experience Technická řešení Virtualizace serverů v ČSOB ČSOB jsme pomohli vybudovat globální evropské data-centrum, ušetřit náklady a zkrátit dobu dodání serverů pro nové aplikace a to díky virtualizaci

Více

Návrh vyhlášky k zákonu o kybernetické bezpečnosti. Přemysl Pazderka NCKB

Návrh vyhlášky k zákonu o kybernetické bezpečnosti. Přemysl Pazderka NCKB Návrh vyhlášky k zákonu o kybernetické bezpečnosti Přemysl Pazderka NCKB Východiska ISO/IEC 27001:2005 Systémy řízení bezpečnosti informací Požadavky ISO/IEC 27002:2005 Soubor postupů pro management bezpečnosti

Více

PRVNÍ ELASTICKÝ INFORMAČNÍ SYSTÉM : QI

PRVNÍ ELASTICKÝ INFORMAČNÍ SYSTÉM : QI PRVNÍ ELASTICKÝ INFORMAČNÍ SYSTÉM : QI Cyril Klimeš a) Jan Melzer b) a) Ostravská univerzita, katedra informatiky a počítačů, 30. dubna 22, 701 03 Ostrava, ČR E-mail: cyril.klimes@osu.cz b) DC Concept

Více

Úvod do Softwarového inženýrství, trendy IS/ IT. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Úvod do Softwarového inženýrství, trendy IS/ IT. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Úvod do Softwarového inženýrství, trendy IS/ IT Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Vliv IT na změny ve společnosti Vznik nových produktů (platební karty, digitální kamery,

Více

Vrstvy programového vybavení Klasifikace Systémové prostředky, ostatní SW Pořizování Využití

Vrstvy programového vybavení Klasifikace Systémové prostředky, ostatní SW Pořizování Využití Programové prostředky PC - 5 Informatika 2 Přednáší: doc. Ing. Jan Skrbek, Dr. - KIN Přednášky: středa 14 20 15 55 Spojení: e-mail: jan.skrbek@tul.cz 16 10 17 45 tel.: 48 535 2442 Obsah: Vrstvy programového

Více

5 Požadavky a jejich specifikace

5 Požadavky a jejich specifikace 5 Požadavky a jejich specifikace 5.1 Inženýrství (requirements engineering) - proces stanovení služeb, které by měl vyvíjený systém poskytovat a omezení, za nichž musí pracovat - CO má systém dělat, ne

Více

PREMIER E Agent. Jak to funguje?

PREMIER E Agent. Jak to funguje? PREMIER E Agent PREMIER E Agent je samostatná aplikace, která slouží jako doplněk k informačnímu systému PREMIER. Je dostupná jako samostatná instalace a její používání je vázáno na jakoukoli licenci k

Více

TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE

TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE Tel. +420 543426329 TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE Autor: Vít Chvál Verze dokumentu: 1.0 Datum poslední změny: 18.2.2013 Obsah: 1 Pracovník 3 2 Pracovní činnosti (Náplň práce)

Více

AristoTelos Systém pro optimalizaci a řízení lidských zdrojů

AristoTelos Systém pro optimalizaci a řízení lidských zdrojů AristoTelos Systém pro optimalizaci a řízení lidských zdrojů AristoTelos The Workforce Management System Workforce management systém AristoTelos AristoTelos je softwarové řešení pro optimalizaci a řízení

Více

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence

Více

KAPITOLA 1 - ZÁKLADNÍ POJMY INFORMAČNÍCH A KOMUNIKAČNÍCH TECHNOLOGIÍ

KAPITOLA 1 - ZÁKLADNÍ POJMY INFORMAČNÍCH A KOMUNIKAČNÍCH TECHNOLOGIÍ KAPITOLA 1 - ZÁKLADNÍ POJMY INFORMAČNÍCH A KOMUNIKAČNÍCH TECHNOLOGIÍ KLÍČOVÉ POJMY technické vybavení počítače uchování dat vstupní a výstupní zařízení, paměti, data v počítači počítačové sítě sociální

Více

Projekt: Koordinační centrum pro zavádění e-gov v územní veřejné správě. Koncepční dokument pro oblast řízení. Procesní model

Projekt: Koordinační centrum pro zavádění e-gov v územní veřejné správě. Koncepční dokument pro oblast řízení. Procesní model Koncepční dokument pro oblast řízení a koordinaci e-gov: Procesní model 18. 09. 2013 OBSAH Obsah... 2 Seznam zkratek... 3 Použité pojmy... 4 1 Úvodní informace... 6 2 Procesní model: životní cyklus e-gov...

Více

Tvorba webových aplikací s využitím Open Source CMS. Lukáš Dubina. Vedoucí práce. PaedDr. Petr Pexa

Tvorba webových aplikací s využitím Open Source CMS. Lukáš Dubina. Vedoucí práce. PaedDr. Petr Pexa Tvorba webových aplikací s využitím Open Source CMS Lukáš Dubina Vedoucí práce PaedDr. Petr Pexa Školní rok: 2009-2010 Abstrakt Cílem této práce je popsat problematiku tvorby webových stránek s využitím

Více

Jsme firma, která už působí na trhu několik let. Za tu dobu jsme nasbírali

Jsme firma, která už působí na trhu několik let. Za tu dobu jsme nasbírali K.O.D.A. s.r.o Jsme firma, která už působí na trhu několik let. Za tu dobu jsme nasbírali dost zkušeností v našem oboru. Zabýváme se vývojem informačního systému pro výrobní podniky a dále konzultačními

Více

Práce s počítačem: 5. ročník

Práce s počítačem: 5. ročník 5.3 Vzdělávací oblast: Informační a komunikační technologie 5.3.1 Vzdělávací obor: Informační a komunikační technologie 5.3.1.1 Vyučovací předmět: Práce s počítačem Informatika Charakteristika vyučovacího

Více

Struktura e-learningových výukových programù a možnosti jejího využití

Struktura e-learningových výukových programù a možnosti jejího využití Struktura e-learningových výukových programù a možnosti jejího využití Jana Šarmanová Klíčová slova: e-learning, programovaná výuka, režimy učení Abstrakt: Autorská tvorba výukových studijních opor je

Více

Moderní přístup k návrhu produktové nabídky a schvalování úvěrových produktů v reálném čase.

Moderní přístup k návrhu produktové nabídky a schvalování úvěrových produktů v reálném čase. Moderní přístup k návrhu produktové nabídky a schvalování úvěrových produktů v reálném čase. Jan Denemark Konference ARBES FINANCE DAY, 19.6.2014, AUSTRIA TREND HOTEL, Bratislava www.arbes.com Situace

Více

Technologické postupy práce s aktovkou IS MPP

Technologické postupy práce s aktovkou IS MPP Technologické postupy práce s aktovkou IS MPP Modul plánování a přezkoumávání, verze 1.20 vypracovala společnost ASD Software, s.r.o. dokument ze dne 27. 3. 2013, verze 1.01 Technologické postupy práce

Více

Uživatelská dokumentace

Uživatelská dokumentace Uživatelská dokumentace Verze 14-06 2010 Stahování DTMM (v rámci služby Geodata Distribution) OBSAH OBSAH...2 1. O MAPOVÉM SERVERU...3 2. NASTAVENÍ PROSTŘEDÍ...3 2.1 Hardwarové požadavky...3 2.2 Softwarové

Více

Aplikační standard - Dokumentace ICT Standardy MPSV MPSV

Aplikační standard - Dokumentace ICT Standardy MPSV MPSV ICT Standardy MPSV MPSV Vedoucí projektu Objednatele: Milan Hojer Vedoucí projektu Zhotovitele: Michal Čanda HEWLETT-PACKARD s.r.o. Vyskočilova 1/1410 140 21 Praha 4 Tel: 261 307 111 Datum: 7.10.2012 Informace

Více

Technická specifikace předmětu plnění:

Technická specifikace předmětu plnění: Technická specifikace předmětu plnění: Poskytnutí standardní služby Premier Support zahrnující konzultační a implementační podporu, řešení problémů u produktů v nepřetržitém režimu 24x7 v rámci aktuálního

Více

Co je to SCRUM! FRAMEWORK vs METODIKA. Ken Schwaber a Jeff Sutherland ho mají za framework Kde hledat detaily?

Co je to SCRUM! FRAMEWORK vs METODIKA. Ken Schwaber a Jeff Sutherland ho mají za framework Kde hledat detaily? Úvod do SCRUM!! Co je to SCRUM! FRAMEWORK vs METODIKA Ken Schwaber a Jeff Sutherland ho mají za framework Kde hledat detaily? agilemanifesto.org www.mountaingoatsoftware.com/scrum Z čeho to je...! Vychází

Více

Kontrola přístupnosti www stránek

Kontrola přístupnosti www stránek 15 Kontrola přístupnosti www stránek Podle toho, jak znám tvůrce www stránek, můžu myslím směle prohlásit, že mnohem pravděpodobněji vytvoří stránky nepřístupné než přístupné. Není to ale vůbec proto,

Více

SOFTWAROVÉ INŽENÝRSTVÍ 1

SOFTWAROVÉ INŽENÝRSTVÍ 1 Metodický list č. 1 Název tématického celku: Úvod do softwarového inženýrství Základním cílem tohoto tematického celku je vysvětlení smyslu discipliny nazývané softwarové inženýrství. Tematický celek zahrnuje

Více

BIOS. Autor: Bc. Miroslav Světlík

BIOS. Autor: Bc. Miroslav Světlík BIOS Autor: Bc. Miroslav Světlík Škola: Hotelová škola, Obchodní akademie a Střední průmyslová škola Teplice, Benešovo náměstí 1, příspěvková organizace Kód: VY_32_INOVACE_ICT_837 1. 11. 2012 1 1. BIOS

Více

Zadávací dokumentace k výběrovému řízení. E-learning CZ.1.07/3.2.04/04.0040. In Company Education, a.s.

Zadávací dokumentace k výběrovému řízení. E-learning CZ.1.07/3.2.04/04.0040. In Company Education, a.s. Číslo zakázky: VŘ 89/2013 Zadávací dokumentace k výběrovému řízení E-learning Název programu: Registrační číslo projektu: Název projektu: Název zakázky: Datum vyhlášení zakázky: Název zadavatele: Cílová

Více

BEZPEČNÁ SPRÁVA KLÍČŮ POMOCÍ HSM. Petr Dolejší Senior Solution Consultant

BEZPEČNÁ SPRÁVA KLÍČŮ POMOCÍ HSM. Petr Dolejší Senior Solution Consultant BEZPEČNÁ SPRÁVA KLÍČŮ POMOCÍ HSM Petr Dolejší Senior Solution Consultant OCHRANA KLÍČŮ A ZOKB Hlavní termín kryptografické prostředky Vyhláška 316/2014Sb. o kybernetické bezpečnosti zmiňuje: v 17 nástroj

Více

POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ

POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ ŽIVOTNÍ CYKLUS IS Stejně jako stroje a technologické linky, které jsou pořízeny, provozovány a následně, po opotřebování vyřazeny, má i informační systém svůj

Více

Manažer programů a komplexních projektů (kód: 63-008-T) Manažer programů a komplexních projektů

Manažer programů a komplexních projektů (kód: 63-008-T) Manažer programů a komplexních projektů Manažer programů a komplexních projektů (kód: 63-008-T) Autorizující orgán: Ministerstvo pro místní rozvoj Skupina oborů: Ekonomika a administrativa (kód: 63) Povolání: Manažer programů a komplexních projektů

Více

WINCOR NIXDORF. Certifikovaný PCI DSS auditor - QSA

WINCOR NIXDORF. Certifikovaný PCI DSS auditor - QSA WINCOR NIXDORF Certifikovaný PCI DSS auditor - QSA Wincor Nixdorf s.r.o. Evropská 33a 160 00 Praha 6 Tel.: +420 233 034 129 Email: pci@wincor-nixdorf.cz PCI DSS jako norma pro bezpečnost v odvětví platebních

Více

Varovný systém ochrany obyvatel před povodněmi pro město Hrádek nad Nisou- digitální povodňový plán

Varovný systém ochrany obyvatel před povodněmi pro město Hrádek nad Nisou- digitální povodňový plán Příloha č. 3 Zadávací dokumentace: Technické požadavky na zpracování digitálního povodňového plánu v rámci veřejné zakázky: Varovný systém ochrany obyvatel před povodněmi pro město Hrádek nad Nisou- digitální

Více

Bohemia Energy. Případová studie. Uzavírání smluv prostřednictvím tabletů přineslo významné zvýšení výkonu obchodní sítě.

Bohemia Energy. Případová studie. Uzavírání smluv prostřednictvím tabletů přineslo významné zvýšení výkonu obchodní sítě. Bohemia Energy Uzavírání smluv prostřednictvím tabletů přineslo významné zvýšení výkonu obchodní sítě Případová studie Únor 2015 Shrnutí Společnost Bohemia Energy, největší alternativní dodavatel energií

Více

Informatika 5.ročník

Informatika 5.ročník Informatika 5.ročník Období Ročníkový výstup Učivo Kompetence vztahy,průř.témata září umí korektně zapnout a vypnout stanici a přihlásit se do a odhlásit ze sítě, využívá základní standartní funkce počítače

Více

ODBORNÝ VÝCVIK VE 3. TISÍCILETÍ. MEIV - 2.3.1.1 Windows server 2003 (seznámení s nasazením a použitím)

ODBORNÝ VÝCVIK VE 3. TISÍCILETÍ. MEIV - 2.3.1.1 Windows server 2003 (seznámení s nasazením a použitím) Object 12 3 Projekt: ODBORNÝ VÝCVIK VE 3. TISÍCILETÍ Téma: MEIV - 2.3.1.1 Windows server 2003 (seznámení s nasazením a použitím) Obor: Mechanik Elektronik Ročník: 4. Zpracoval(a): Bc. Martin Fojtík Střední

Více

PPM umožňuje: PPM napomáhá: Systém je postaven na čtyřech základních pilířích, vedoucích k efektivnímu vývoji a optimalizaci portfolia:

PPM umožňuje: PPM napomáhá: Systém je postaven na čtyřech základních pilířích, vedoucích k efektivnímu vývoji a optimalizaci portfolia: Solutions s.r.o. PPM umožňuje: Komplexní analýzu vývoje portfolia Strategické řízení Evidenci projektů Evidenci projektových a souvisejících dat Závislost procesů, podpora workflow definovaná událost

Více

Jádrem systému je modul GSFrameWork, který je poskytovatelem zejména těchto služeb:

Jádrem systému je modul GSFrameWork, který je poskytovatelem zejména těchto služeb: Technologie Marushka Základním konceptem technologie Marushka je použití jádra, které poskytuje přístup a jednotnou grafickou prezentaci geografických dat. Jádro je vyvíjeno na komponentním objektovém

Více

OKsmart a správa karet v systému OKbase

OKsmart a správa karet v systému OKbase OKsmart a správa karet v systému OKbase Od personalizace a sledování životního cyklu karet až k bezkontaktní autentizaci a elektronickému podpisu Spojujeme software, technologie a služby Martin Primas

Více

Aplikační Dokumentace Standardy ICT MPSV

Aplikační Dokumentace Standardy ICT MPSV Standardy ICT MPSV Datum: 19.12.2014 Informace o dokumentu Název dokumentu: Aplikační Dokumentace Historie verzí Číslo verze Datum verze Vypracoval Popis Jméno souboru 1.0 31.8.2012 Jan Apfelthaler Doplnění

Více

Business Suite for Notes

Business Suite for Notes Business Suite for Notes Systém BSFN byl vytvořen na základě zkušeností s podporou a řízením procesů v obchodní firmě. Během několika let existence na trhu se osvědčil u mnoha zákazníků. Z nejvýznamnějších

Více

Nová generace podnikových mobilních aplikací od HP

Nová generace podnikových mobilních aplikací od HP Nová generace podnikových mobilních aplikací od HP V době rozmachu chytrých telefonů a tabletů, které se již staly komoditním produktem a ne jen hračkou pro nadšence a profesionály, jsme svědky vzniku

Více

Web je bezesporu nejrychleji měnícím se médiem, do kterého se

Web je bezesporu nejrychleji měnícím se médiem, do kterého se váš nový WEB Vážený zákazníku, velice si vážím vašeho zájmu o moje služby. Každý profesionál se snaží udělat zadanou práci co nejlépe. K tomu používá svoje osvědčené nástroje a získané Know-how. Věřím,

Více

Přehled. Inventurou prošlo téměř 10 000 licencí na software. Země: Česká republika. Odvětví: Bankovnictví a finance.

Přehled. Inventurou prošlo téměř 10 000 licencí na software. Země: Česká republika. Odvětví: Bankovnictví a finance. Případová studie Provident Financial mohl díky SoftwareONE provést účetní inventuru software a zamezit zbytečné investici do nepotřebných licencí na IVR systém Přehled Země: Česká republika Odvětví: Bankovnictví

Více

Informatika 5.ročník

Informatika 5.ročník Informatika 5.ročník vztahy,průř.témata září umí korektně zapnout a vypnout stanici a přihlásit se do a odhlásit ze sítě, využívá základní standartní funkce počítače a jeho nejběžnější periferie Postup

Více

Použití čipových karet v IT úřadu

Použití čipových karet v IT úřadu Použití čipových karet v IT úřadu Software pro personalizaci, správu a použití čipových karet Ing. Ivo Rosol, CSc. Ing. Pavel Rous 9. 10. 6. 2011 1 Použití bezkontaktních čipových karet Přístupové systémy

Více

Cornelius Scipio s.r.o. Scénáře. SBD Vítkovice. Elektronická hlášení závad. Scénář postupu práce. Předseda samosprávy. Autor: Cornelius Scipio s.r.o.

Cornelius Scipio s.r.o. Scénáře. SBD Vítkovice. Elektronická hlášení závad. Scénář postupu práce. Předseda samosprávy. Autor: Cornelius Scipio s.r.o. SBD Vítkovice Elektronická hlášení závad Scénář postupu práce Předseda samosprávy Autor: Cornelius Scipio s.r.o. Obsah: 1. Úvod... 3 2. Postup práce s touto webovou aplikací... 4 2.1. Spuštění a přihlášení

Více

Generování žádosti o certifikát Uživatelská příručka pro prohlížeč Opera

Generování žádosti o certifikát Uživatelská příručka pro prohlížeč Opera Generování žádosti o certifikát Uživatelská příručka pro prohlížeč Opera První certifikační autorita, a.s. Verze 8.15 1 Obsah 1. Úvod... 3 2. Požadavky na software... 3 3. Instalace kořenového certifikátu

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

ODŮVODNĚNÍ VEŘEJNÉ ZAKÁZKY

ODŮVODNĚNÍ VEŘEJNÉ ZAKÁZKY ZADAVATEL Obchodní firma: Výzkumný ústav anorganické chemie, a. s. (dále VÚAnCh) Se sídlem: Revoluční 84, 400 01 Ústí nad Labem Jednající: Ing. Milanem Petrákem, ředitelem ústavu a místopředsedou př. Ing.

Více

Procesní řízení. Hlavní zásady a praxe dodavatele Komix

Procesní řízení. Hlavní zásady a praxe dodavatele Komix Procesní řízení Hlavní zásady a praxe dodavatele Komix 1 Obsah prezentace Teoretická část (menšího objemu) orientace na zákazníka hodnocení procesu podmínky procesního řízení cyklus zlepšování procesu

Více

SOUBOR OTÁZEK PRO INTERNÍ AUDIT (Checklist)

SOUBOR OTÁZEK PRO INTERNÍ AUDIT (Checklist) SOUBOR OTÁZEK PRO INTERNÍ AUDIT (Checklist) Oblast 1. STRATEGICKÉ PLÁNOVÁNÍ Jsou identifikovány procesy v takovém rozsahu, aby byly dostačující pro zajištění systému managementu jakosti v oblasti vzdělávání?

Více

DINOX IP kamery řady: DDC-xxxx DDR-xxxx DDX-xxxx DDB-xxxx

DINOX IP kamery řady: DDC-xxxx DDR-xxxx DDX-xxxx DDB-xxxx DINOX IP kamery řady: DDC-xxxx DDR-xxxx DDX-xxxx DDB-xxxx Rychlá uživatelská příručka Obsah Rychlá uživatelská příručka... 1 1. Systémové požadavky... 3 2. Připojení do sítě... 4 3. Přístup pomocí webového

Více

Je Smart Grid bezpečný?

Je Smart Grid bezpečný? Je Smart Grid bezpečný? Petr Paukner petr.paukner@anect.com - člen představenstva Jen pro vnitřní potřebu ANECT a.s. Kontext Moderní Smart Grids potřebují zajistit: Aktivní participaci producentů i konzumentů

Více

PRODEJ Prodej je pochopitelně základní funkcí pokladního systému. Systému MERCATOR umožňuje prodej realizovat ve 3 režimech:

PRODEJ Prodej je pochopitelně základní funkcí pokladního systému. Systému MERCATOR umožňuje prodej realizovat ve 3 režimech: MERCATOR Moderní pokladní systém od společnosti SICONET a.s. Co je MERCATOR MERCATOR je PC pokladní systém určený především maloobchodním a velkoobchodním prodejnám společností, jejichž podnikovým systémem

Více

Operační systém osobního počítače

Operační systém osobního počítače Operační systém osobního počítače Studijní materiál pro žáky SŠ Začlenění dle RVP G Vzdělávací obsah: Očekávaný výstup: Digitální technologie ovládá, propojuje a aplikuje dostupné prostředky ICT využívá

Více

Dominik Vymětal. Informační technologie pro praxi 2009, Ostrava 1.-2.10.2009 1

Dominik Vymětal. Informační technologie pro praxi 2009, Ostrava 1.-2.10.2009 1 Dominik Vymětal 2009, Ostrava 1.-2.10.2009 1 Procesní model Výhody Orientace na konkrétní činnosti a možnost reengineeringu Nevýhody Malá orientace na průřezové nebo opakované činnosti Modely na základě

Více

Požadavky na parametry SLA

Požadavky na parametry SLA Příloha č.3 Požadavky na parametry SLA 1.1 Základní údaje Režim SLA pro provoz bude začínat od akceptace hlavního díla (nový portál) a je určen pro režim provozu portálu. Předmětem SLA budou následující

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

Návod na instalaci a použití programu

Návod na instalaci a použití programu Návod na instalaci a použití programu Minimální konfigurace: Pro zajištění funkčnosti a správné činnosti SW E-mentor je potřeba software požívat na PC s následujícími minimálními parametry: procesor Core

Více

Plc Calculator. Nástroj pro automatizovaný návrh aplikace s automaty MICROPEL 8.2010

Plc Calculator. Nástroj pro automatizovaný návrh aplikace s automaty MICROPEL 8.2010 Plc Calculator Nástroj pro automatizovaný návrh aplikace s automaty MICROPEL 8.2010 PLC CALCULATOR PlcCalculator představuje programový nástroj pro automatizované rozmístění IO bodů aplikace na automatech

Více

Příloha č. 1 zadávací dokumentace - Technická specifikace

Příloha č. 1 zadávací dokumentace - Technická specifikace Obsah Příloha č. 1 zadávací dokumentace - Technická specifikace Stávající stav... 2 Část č. 1 veřejné zakázky - Tablety posádek... 4 Část č. 2 veřejné zakázky - Tiskárny... 5 Část č. 3 veřejné zakázky

Více

BLINDSHELL ROZHRANÍ PRO OVLÁDÁNÍ DOTYKOVÝCH TELEFONŮ S ANDROIDEM PRO ZRAKOVĚ POSTIŽENÉ UŽIVATELE

BLINDSHELL ROZHRANÍ PRO OVLÁDÁNÍ DOTYKOVÝCH TELEFONŮ S ANDROIDEM PRO ZRAKOVĚ POSTIŽENÉ UŽIVATELE BLINDSHELL ROZHRANÍ PRO OVLÁDÁNÍ DOTYKOVÝCH TELEFONŮ S ANDROIDEM PRO ZRAKOVĚ POSTIŽENÉ UŽIVATELE Petr SVOBODNÍK, Daniel NOVÁK, Michal CERMAN Katedra kybernetiky, Karlovo náměstí 13, 121 35 Praha 2, svobop24@fel.cvut.cz,

Více

Obsah. Úvod 11 Zpětná vazba od čtenářů 13 Errata 14 Poznámka ke kódům 14

Obsah. Úvod 11 Zpětná vazba od čtenářů 13 Errata 14 Poznámka ke kódům 14 Úvod 11 Zpětná vazba od čtenářů 13 Errata 14 Poznámka ke kódům 14 KAPITOLA 1 Nové rysy Windows 8 a 8.1 15 Nové uživatelské rozhraní 15 Rychlý náběh po zapnutí 16 Informace v prvním sledu 16 Nové prezentační

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

HODNOCENÍ VÝKONNOSTI PODNIKU VE SPOJITOSTI SE STRATEGICKÝMI CÍLY

HODNOCENÍ VÝKONNOSTI PODNIKU VE SPOJITOSTI SE STRATEGICKÝMI CÍLY 29 HODNOCENÍ VÝKONNOSTI PODNIKU VE SPOJITOSTI SE STRATEGICKÝMI CÍLY POKORNÝ Karel Abstrakt: Metoda Balanced Scorecard (BSC) její podstata, obsah a principy. Vztah BSC ke strategickému a operativnímu řízení

Více

Mobilní aplikace ve světě ERP. Asseco Solutions, a.s. a Simac Technik ČR, a.s.

Mobilní aplikace ve světě ERP. Asseco Solutions, a.s. a Simac Technik ČR, a.s. Mobilní aplikace ve světě ERP Michal Hanko Petr Kolda Asseco Solutions, a.s. a Simac Technik ČR, a.s. Skupina Asseco Solutions Asseco Solutions je průkopníkem a vizionářem na poli informačních systémů

Více

TC-502L. Tenký klient

TC-502L. Tenký klient TC-502L Tenký klient Popis přístroje Tenký klient s kompletní podporou pro připojení do systémů Windows 7, Vista, Windows 2008, Windows 2003, Windows XP Pro, Linux servery. Disponuje 1x rozhraním LAN 10/100,

Více

ROZDÍLY V NÁVRZÍCH RELAČNÍCH A OBJEKTOVÝCH DATABÁZÍ A JEJICH DŮSLEDKY PRO TRANSFORMACI MODELŮ

ROZDÍLY V NÁVRZÍCH RELAČNÍCH A OBJEKTOVÝCH DATABÁZÍ A JEJICH DŮSLEDKY PRO TRANSFORMACI MODELŮ ROZDÍLY V NÁVRZÍCH RELAČNÍCH A OBJEKTOVÝCH DATABÁZÍ A JEJICH DŮSLEDKY PRO TRANSFORMACI MODELŮ RELATIONAL AND OBJECT DATABASES DESIGN DIFFERENCES AND IT S IMPLICATIONS TO MODEL TRANSFORMATION Vít Holub

Více

Manažerský informační systém na MPSV. Mgr. Karel Lux, vedoucí oddělení koncepce informatiky MPSV

Manažerský informační systém na MPSV. Mgr. Karel Lux, vedoucí oddělení koncepce informatiky MPSV Manažerský informační systém na MPSV Mgr. Karel Lux, vedoucí oddělení koncepce informatiky MPSV Konference ISSS-2009 Hradec Králové Aldis 6. dubna 2009 MIS na MPSV časové údaje projektu Vytvoření MIS MPSV

Více

KSRZIS. Postup kroků nutných pro napojení nemocničního informačního systému s registrem NSHNU v prostředí registrů resortu zdravotnictví

KSRZIS. Postup kroků nutných pro napojení nemocničního informačního systému s registrem NSHNU v prostředí registrů resortu zdravotnictví Koordinační středisko pro resortní zdravotnické informační systémy Budějovická 15/743 140 00 Praha 4 Počet stran: 10 KSRZIS Postup kroků nutných pro napojení nemocničního informačního systému s registrem

Více

Agenda. Smysl teoretických cvičení Klasifikace Obecná pravidla Bugzilla Klasické problémy Poznámky k jednotlivým pojmům Antipatterns Testování testů

Agenda. Smysl teoretických cvičení Klasifikace Obecná pravidla Bugzilla Klasické problémy Poznámky k jednotlivým pojmům Antipatterns Testování testů Testování a QA Agenda Smysl teoretických cvičení Klasifikace Obecná pravidla Bugzilla Klasické problémy Poznámky k jednotlivým pojmům Antipatterns Testování testů Klasifikace Kategorie black box grey box

Více

CHARAKTERISTIKA VEŘEJNÉ ZAKÁZKY

CHARAKTERISTIKA VEŘEJNÉ ZAKÁZKY Příloha č. 1 CHARAKTERISTIKA VEŘEJNÉ ZAKÁZKY Veřejná zakázka Poskytování služeb outsourcingu Zadavatel: Nemocnice Český Krumlov a.s., sídlem: Český Krumlov, Horní Brána 429, PSČ 381 27 IČ: 260 95 149 DIČ:

Více

1.05 Informační systémy a technologie

1.05 Informační systémy a technologie Vypracoval Gestor Schválil Listů Příloh D. Marek(EOS/2) EOS VS 5 Směrnice platí pro všechny závody ŠKODA AUTO. Obsah: 1. Použité pojmy a zkratky 2. Plánování IT 3. Pořízení IT 4. Dodání IT 5. Provoz a

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

Popis produktu IDFU. Řešení součinnosti s oprávněnými osobami verze 2. Aegis s.r.o.

Popis produktu IDFU. Řešení součinnosti s oprávněnými osobami verze 2. Aegis s.r.o. Popis produktu IDFU Řešení součinnosti s oprávněnými osobami verze 2 Obsah Produkt IDFU...3 K čemu slouží...3 Historie IDFU...3 IDFU dnes...3 Generování odpovědí...4 Pozice produktu...5 Hlavní přínosy...5

Více

Olga Rudikova 2. ročník APIN

Olga Rudikova 2. ročník APIN Olga Rudikova 2. ročník APIN Redakční (publikační) systém neboli CMS - content management system (systém pro správu obsahu) je software zajišťující správu dokumentů, nejčastěji webového obsahu. (webová

Více

3. Očekávání a efektivnost aplikací

3. Očekávání a efektivnost aplikací VYUŽÍVANÍ INFORMAČNÍCH SYSTÉMŮ V ŘÍZENÍ FIREM Ota Formánek 1 1. Úvod Informační systémy (IS) jsou v současnosti naprosto nezbytné pro úspěšné řízení firem. Informačním ním systémem rozumíme ucelené softwarové

Více

Elektronické učebnice popis systému, základních funkcí a jejich cena

Elektronické učebnice popis systému, základních funkcí a jejich cena Elektronické učebnice popis systému, základních funkcí a jejich cena Vytvořil TEMEX, spol. s r. o. Obsah 1. Úvod... 2 Formáty... 2 Cena... 2 2. Systémové požadavky... 3 Interaktivní PDF verze... 3 HTML

Více

Stručná instalační příručka SUSE Linux Enterprise Server 11

Stručná instalační příručka SUSE Linux Enterprise Server 11 Stručná instalační příručka SUSE Linux Enterprise Server 11 RYCHLÝ ÚVODNÍ LIST NOVELL Při instalaci nové verze systému SUSE Linux Enterprise 11 postupujte podle následujících pokynů. Tento dokument obsahuje

Více

Specifikace rozhraní. Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů. Martin Falc, SW architekt.

Specifikace rozhraní. Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů. Martin Falc, SW architekt. C E R T I C O N www.certicon.cz V Á C L A V S K Á 1 2 1 2 0 0 0 P R A H A 2 Specifikace rozhraní Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů Martin Falc, SW architekt

Více

BPM Software pro přehledné řízení práce

BPM Software pro přehledné řízení práce www.orinoco.cz BPM Software pro přehledné řízení práce Snížení nákladů zvýšení efektivity Řízení workflow, procesy pod kontrolou Systém, který roste s firmou Co je orinoco? co je orinoco? Orinoco je BPM

Více

Ročník VIII. Informatika. Období Učivo téma Metody a formy práce- kurzívou. Kompetence Očekávané výstupy. Průřezová témata. Mezipřed.

Ročník VIII. Informatika. Období Učivo téma Metody a formy práce- kurzívou. Kompetence Očekávané výstupy. Průřezová témata. Mezipřed. Osobní počítač hardwarová konfigurace IX. /OPAKOVÁNÍ/ /základní jednotka / /externí zařízení počítače / F: hromadná M:samostatná práce žák zná princip činnosti a stavbu osobního počítače /komponenty/ (skříně

Více

Daniela Lišková Solution Specialist Windows Client. daniela.liskova@microsoft.com

Daniela Lišková Solution Specialist Windows Client. daniela.liskova@microsoft.com DESKTOP: Windows Vista Daniela Lišková Solution Specialist Windows Client daniela.liskova@microsoft.com TCO desktopů analýzy spol. Gartner Téměř 80% všech nákladů v IT vzniká po nákupu tj. na správě, opravě,

Více

Informační systémy. Jaroslav Žáček jaroslav.zacek@osu.cz

Informační systémy. Jaroslav Žáček jaroslav.zacek@osu.cz Informační systémy Jaroslav Žáček jaroslav.zacek@osu.cz Úvod - co možná umíte z předmětu SWENG Rozdělení IT Architektura IS Klíčový prvek řízení IS z něj vycházejí detailní analytické i plánovací charakteristiky

Více

Téma 5: Konfigurace počítačů se systémem Windows 7. Téma 5: Konfigurace počítačů se systémem Windows 7

Téma 5: Konfigurace počítačů se systémem Windows 7. Téma 5: Konfigurace počítačů se systémem Windows 7 Téma 5: Konfigurace počítačů se systémem Windows 7 1 Teoretické znalosti V tomto cvičení se dozvíte více o správě počítače se systémem Windows 7. Ukážeme si nové funkce, které má správce k dispozici jako

Více

Odbor informatiky a provozu informačních technologií

Odbor informatiky a provozu informačních technologií POLICEJNÍ PREZIDIUM ČR Odbor informatiky a provozu informačních technologií Příloha č. 1 a) název zakázky, Technická podpora software pro systém NS-VIS a VISMAIL b) předmět a rozsah plnění veřejné zakázky

Více