UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

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

End-to-end testování. 26. dubna Bořek Zelinka

End-to-end testování. 26. dubna Bořek Zelinka End-to-end testování 26. dubna 2013 Bořek Zelinka Bořek Zelinka Unicorn Systems, Test architekt Unicorn, 2004 Testování Quality Assurance ČVUT, Fakulta stavební, 2004 2 Agenda Princip end-to-end testů

Více

A7B36SI2 Tematický okruh SI08 Revidoval: Martin Kvetko

A7B36SI2 Tematický okruh SI08 Revidoval: Martin Kvetko Strategie testování, validace a verifikace. Testování v průběhu životního cyklu SW díla. Testování jednotek, integrační testování, validační testování, systémové testování, ladění. Principy testování,

Více

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

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

Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT)

Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT) Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT) Charta projektu má za cíl poskytnout úplné a pevné informační základy pro schválení projektu. Následně je Charta projektu rozpracována do

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

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

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

Zajištění kvality programového vybavení - testování

Zajištění kvality programového vybavení - testování Zajištění kvality programového vybavení - testování Základy testování Proč se to dělá? Kvalita software 100% testování není možné Různé pohledy: Vývojářské testování (testy komponent, integrační, systémové

Více

ÚVOD DO PROBLEMATIKY PROJEKTŮ, KATEGORIE

ÚVOD DO PROBLEMATIKY PROJEKTŮ, KATEGORIE PROJEKTOVÉ ŘÍZENÍ STAVEB ÚVOD DO PROBLEMATIKY PROJEKTŮ, KATEGORIE Vysoká škola technická a ekonomická v Českých PROJEKTŮ Budějovicích Institute of Technology And Business In České Budějovice Tento učební

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

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

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

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

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

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

Tovek Server. Tovek Server nabízí následující základní a servisní funkce: Bezpečnost Statistiky Locale

Tovek Server. Tovek Server nabízí následující základní a servisní funkce: Bezpečnost Statistiky Locale je serverová aplikace určená pro efektivní zpracování velkého objemu sdílených nestrukturovaných dat. Umožňuje automaticky indexovat data z různých informačních zdrojů, intuitivně vyhledávat informace,

Více

MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ

MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ M. Sysel, I. Pomykacz Univerzita Tomáše Bati ve Zlíně, Fakulta aplikované informatiky Nad Stráněmi 4511, 760 05 Zlín, Česká republika

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

Řešení pro správu logů, shodu a bezpečnost ve státní správě a samosprávě. Ing. Martin Pavlica Corpus Solutions a.s. divize Security Expert

Řešení pro správu logů, shodu a bezpečnost ve státní správě a samosprávě. Ing. Martin Pavlica Corpus Solutions a.s. divize Security Expert Řešení pro správu logů, shodu a bezpečnost ve státní správě a samosprávě Ing. Martin Pavlica Corpus Solutions a.s. divize Security Expert Agenda Úvod do problematiky Seznam problémů Definice požadavků,

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

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

Procesní řízení operačních sálů Mgr. Martin Gažar

Procesní řízení operačních sálů Mgr. Martin Gažar Procesní řízení operačních sálů Mgr. Martin Gažar Procesy Procesy Procesní analýza Procesní mapa Modely procesů Optimalizace procesů Přínosy procesní analýzy Procesy a modely Procesy Abychom mohli úspěšně

Více

Technické podmínky. Interaktivní tabule v počtu 2 ks. Stojan zvedací pro interaktivní tabuli 78 se dvěma křídly v počtu 2ks

Technické podmínky. Interaktivní tabule v počtu 2 ks. Stojan zvedací pro interaktivní tabuli 78 se dvěma křídly v počtu 2ks Technické podmínky Popis zařízení a vybavení Uvedené požadavky na technickou specifikaci jsou chápány jako minimální přípustné. Technická specifikace je nastavena níže uvedeným způsobem z důvodu zajištění

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

Autoevaluace v práci učitele

Autoevaluace v práci učitele Autoevaluace v práci učitele Mgr. Jiří Štěpán 1 e-mail: stepan@zsalsova.cz Mgr. Blanka Kozáková 2 e-mail: blanka.kozakova@kvic.cz 1 Základní škola Kopřivnice, Alšova 1123 okres Nový Jičín 2 Krajské zařízení

Více

Přístupnost webů knihoven příklady dobré a špatné praxe. Radek PAVLÍČEK, TyfloCentrum Brno, o. p. s., projekt Blind Friendly Web

Přístupnost webů knihoven příklady dobré a špatné praxe. Radek PAVLÍČEK, TyfloCentrum Brno, o. p. s., projekt Blind Friendly Web Přístupnost webů knihoven příklady dobré a špatné praxe Radek PAVLÍČEK, TyfloCentrum Brno, o. p. s., projekt Blind Friendly Web Máte rádi CAPTCHA? Líbila by se vám takto prezentovaná stránka vaší knihovny?

Více

NÁVRH EFEKTIVNÍ STRATEGIE MOBILNÍHO BANKOVNICTVÍ: NALEZENÍ SPRÁVNÉHO OBCHODNÍHO MODELU Mobile tech 2014

NÁVRH EFEKTIVNÍ STRATEGIE MOBILNÍHO BANKOVNICTVÍ: NALEZENÍ SPRÁVNÉHO OBCHODNÍHO MODELU Mobile tech 2014 NÁVRH EFEKTIVNÍ STRATEGIE MOBILNÍHO BANKOVNICTVÍ: NALEZENÍ SPRÁVNÉHO OBCHODNÍHO MODELU Mobile tech 2014 Mojmír Prokop, Head of Direct Channels, Komerční banka, a.s. Praha 27.března 2012 Kdo jsme : Silná

Více

Vizualizace v provozech povrchových úprav

Vizualizace v provozech povrchových úprav Vizualizace v provozech povrchových úprav Zdeněk Čabelický, AITEC s.r.o., Ledeč nad Sázavou Aplikace systémů ASŘ v provozech povrchových úprav v současné době nabývá na významu. V podstatě každá větší

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

EKONOMICKÝ A LOGISTICKÝ SOFTWARE. Luhačovice 24.10.2013

EKONOMICKÝ A LOGISTICKÝ SOFTWARE. Luhačovice 24.10.2013 EKONOMICKÝ A LOGISTICKÝ SOFTWARE Luhačovice 24.10.2013 CRM řízení vztahů se zákazníky CRM - je zkratka z anglického Customer Relationship Management a označují se tak systémy pro řízení vztahů se zákazníky.crm

Více

S T R A T E G I C K Ý M A N A G E M E N T

S T R A T E G I C K Ý M A N A G E M E N T S T R A T E G I C K Ý M A N A G E M E N T 3 LS, akad.rok 2014/2015 Strategický management - VŽ 1 Proces strategického managementu LS, akad.rok 2014/2015 Strategický management - VŽ 2 Strategický management

Více

Sísyfos Systém evidence činností

Sísyfos Systém evidence činností Sísyfos Systém evidence Sísyfos : Evidence pracovních Systém Sísyfos je firemní aplikace zaměřená na sledování pracovních úkonů jednotlivých zaměstnanců firmy. Umožňuje sledovat pracovní činnosti na různých

Více

Tematická oblast: Informační a komunikační technologie (VY_32_INOVACE_09_2_IT) Autor: Ing. Jan Roubíček. Vytvořeno: prosinec 2013 až leden 2014

Tematická oblast: Informační a komunikační technologie (VY_32_INOVACE_09_2_IT) Autor: Ing. Jan Roubíček. Vytvořeno: prosinec 2013 až leden 2014 Tematická oblast: (VY_32_INOVACE_09_2_IT) Autor: Ing. Jan Roubíček Vytvořeno: prosinec 2013 až leden 2014 Anotace: Digitální učební materiály slouží k seznámení se základy informačních a komunikačních

Více

CHARAKTERISTIKA VZDĚLÁVACÍ OBLAST VYUČOVACÍ PŘEDMĚT ZODPOVÍDÁ INFORMAČNÍ A KOMUNIKAČNÍ TECHNOLOGIE

CHARAKTERISTIKA VZDĚLÁVACÍ OBLAST VYUČOVACÍ PŘEDMĚT ZODPOVÍDÁ INFORMAČNÍ A KOMUNIKAČNÍ TECHNOLOGIE CHARAKTERISTIKA VZDĚLÁVACÍ OBLAST VYUČOVACÍ PŘEDMĚT ZODPOVÍDÁ INFORMATIKA Ing. Irena Martinovská Vyučovací předmět Informatika je zařazen samostatně ve 4. - 9. ročníku v hodinové dotaci 1 hodina týdně.

Více

MBI - technologická realizace modelu

MBI - technologická realizace modelu MBI - technologická realizace modelu 22.1.2015 MBI, Management byznys informatiky Snímek 1 Agenda Technická realizace portálu MBI. Cíle a principy technického řešení. 1.Obsah portálu - objekty v hierarchiích,

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

Základní informace. Operační systém (OS)

Základní informace. Operační systém (OS) Základní informace Operační systém (OS) OS je základní program, který oživuje technické díly počítače (hardware) a poskytuje prostředí pro práci všech ostatních programů. Operační systém musí být naistalován

Více

icc Next Generation atlantis Copyright 2011, atlantis

icc Next Generation atlantis Copyright 2011, atlantis icc Next Generation atlantis Copyright 2011, atlantis Zaměření icc zdravotnická zařízení výrobní podniky instituce a samospráva jednotky až stovky agentů malé, střední a velké organizace kontextově zaměřený

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

VZDĚLÁVACÍ OBLAST INFORMAČNÍ A KOMUNIKAČNÍ TECHNOLOGIE VYUČOVACÍ PŘEDMĚT: INFORMAČNÍ A KOMUNIKAČNÍ TECHNOLOGIE. Charakteristika vyučovacího předmětu:

VZDĚLÁVACÍ OBLAST INFORMAČNÍ A KOMUNIKAČNÍ TECHNOLOGIE VYUČOVACÍ PŘEDMĚT: INFORMAČNÍ A KOMUNIKAČNÍ TECHNOLOGIE. Charakteristika vyučovacího předmětu: VZDĚLÁVACÍ OBLAST VYUČOVACÍ PŘEDMĚT: Charakteristika vyučovacího předmětu: Vyučovací předmět I/IKTje zařazen samostatně v 6. - 9. ročníku v hodinové dotaci 1 hod. týdně. Svým obsahem navazuje na výuku

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

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

ZŠ a MŠ, Brno, Horníkova 1 - Školní vzdělávací program

ZŠ a MŠ, Brno, Horníkova 1 - Školní vzdělávací program 4.3. Informační a komunikační technologie Charakteristika předmětu Vzdělávací oblast je realizována prostřednictvím vyučovacího předmětu Informatika. Informatika je zařazena do ŠVP jako povinný předmět

Více

Návrh a management projektu. Řízení a koordinace projektu

Návrh a management projektu. Řízení a koordinace projektu Návrh a management projektu Řízení a koordinace projektu ČVUT FAKULTA BIOMEDICÍNSKÉHO INŽENÝRSTVÍ strana 1 Ing. Vladimír Jurka 2013 Program přednášky Komunikační nástroje Dokumenty řízení projektu Řízení

Více

Tvorba kurzu v LMS Moodle

Tvorba kurzu v LMS Moodle Tvorba kurzu v LMS Moodle Před počátkem práce na tvorbě základního kurzu znovu připomínám, že pro vytvoření kurzu musí být profil uživatele nastaven administrátorem systému minimálně na hodnotu tvůrce

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

Příspěvek je věnován základním informacím o způsobu volby vhodné strategie řízení kontinuity činností v organizaci.

Příspěvek je věnován základním informacím o způsobu volby vhodné strategie řízení kontinuity činností v organizaci. Mgr. Monika Johaníková Ochrana & Bezpečnost 2013, ročník II., č. 3 (podzim), ISSN 1805-5656 Stanovení strategie řízení kontinuity činností Anotace Příspěvek je věnován základním informacím o způsobu volby

Více

Nová áplikáce etesty zá te z ove testová ní

Nová áplikáce etesty zá te z ove testová ní Nová áplikáce etesty zá te z ove testová ní Verze 0.4 Datum aktualizace 28. 11. 2014 1 Obsah 1 Úvod... 2 1.1 Podpora - kontakty... 2 1.2 Zdroje... 2 1.3 Zkratky... 2 2 Předpoklady pro testování... 3 2.1

Více

TACHOTel manuál 2015 AURIS CZ

TACHOTel manuál 2015 AURIS CZ TACHOTel manuál 2 TACHOTel Obsah Foreword I Úvod 0 3 1 Popis systému... 3 2 Systémové... požadavky 4 3 Přihlášení... do aplikace 5 II Nastavení aplikace 6 1 Instalace... a konfigurace služby ATR 6 2 Vytvoření...

Více

Dílčí projekt: Systém projektování textilních struktur 1.etapa: tvorba systému projektování vlákno - příze - tkanina

Dílčí projekt: Systém projektování textilních struktur 1.etapa: tvorba systému projektování vlákno - příze - tkanina Program LibTex Uživatelská příručka 1 Obsah Program Textilní Design... 1 Uživatelská příručka... 1 1 Obsah... 2 2 Rejstřík obrázků... 2 3 Technické požadavky... 3 3.1 Hardware... 3 3.1.1 Procesor... 3

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

aneb velice zjednodušené vysvětlení základních funkcí a možností systému Vypracoval: Tomáš Dluhoš E-mail: tomas.d@centrum.cz

aneb velice zjednodušené vysvětlení základních funkcí a možností systému Vypracoval: Tomáš Dluhoš E-mail: tomas.d@centrum.cz aneb velice zjednodušené vysvětlení základních funkcí a možností systému Vypracoval: Tomáš Dluhoš E-mail: tomas.d@centrum.cz Operační systém Windows - první operační systém Windows byl představen v roce

Více

Optimalizaci aplikací. Ing. Martin Pavlica

Optimalizaci aplikací. Ing. Martin Pavlica Optimalizaci aplikací Ing. Martin Pavlica Vize: Aplikace v dnešním světě IT Ze všech částí IT jsou aplikace nejblíže businessu V elektronizovaném světě významným způsobem podporují business, ten se na

Více

CobiT. Control Objectives for Information and related Technology. Teplá u Mariánských Lázní, 6. října 2004

CobiT. Control Objectives for Information and related Technology. Teplá u Mariánských Lázní, 6. října 2004 CobiT Control Objectives for Information and related Technology Teplá u Mariánských Lázní, 6. října 2004 Agenda Základy CobiT Pojem CobiT Domény CobiT Hodnocení a metriky dle CobiT IT Governance Řízení

Více

Dobré UX jako nejlepší marketingový nástroj mobilních aplikací. Vladimír Korbel

Dobré UX jako nejlepší marketingový nástroj mobilních aplikací. Vladimír Korbel Dobré UX jako nejlepší marketingový nástroj mobilních aplikací Vladimír Korbel Osnova Co je to User Experience (UX)? Proč je UX důležitá UX přínosy pro business Dobrý design v kontextu mobilních aplikací

Více

Obsah. 1.1 Práce se záznamy... 3 1.2 Stránka Dnes... 4. 2.1 Kontakt se zákazníkem... 5

Obsah. 1.1 Práce se záznamy... 3 1.2 Stránka Dnes... 4. 2.1 Kontakt se zákazníkem... 5 CRM SYSTÉM KORMORÁN UŽIVATELSKÁ PŘÍRUČKA Obsah 1 Základní práce se systémem 3 1.1 Práce se záznamy................................. 3 1.2 Stránka Dnes.................................... 4 1.3 Kalendář......................................

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

Základní nastavení. Petr Novák (novace@labe.felk.cvut.cz) 13.12.2010

Základní nastavení. Petr Novák (novace@labe.felk.cvut.cz) 13.12.2010 Základní nastavení Petr Novák (novace@labe.felk.cvut.cz) 13.12.2010 Všechny testy / moduly používají určité základní nastavení. Toto základní nastavení se vyvolá stiskem tlačítka Globální / základní konfigurace

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

Webová aplikace Znalostní testy online UŽIVATELSKÁ PŘÍRUČKA

Webová aplikace Znalostní testy online UŽIVATELSKÁ PŘÍRUČKA Webová aplikace Znalostní testy online UŽIVATELSKÁ PŘÍRUČKA 2005 Lukáš Trombik OBSAH ÚVOD... 1 SPUŠTĚNÍ... 1 POPIS OVLÁDÁNÍ INFORMAČNÍHO SYSTÉMU... 1 POPIS KLIENTSKÉ ČÁSTI... 1 POPIS ADMINISTRÁTORSKÉ ČÁSTI...

Více

POČÍTAČOVÉ PRAKTIKUM. 6. 9. ročník Charakteristika vyučovacího předmětu. Obsahové, časové a organizační vymezení

POČÍTAČOVÉ PRAKTIKUM. 6. 9. ročník Charakteristika vyučovacího předmětu. Obsahové, časové a organizační vymezení 6. 9. ročník Charakteristika vyučovacího předmětu Obsahové, časové a organizační vymezení Realizován v 6. až 9. ročníku po jedné hodině týdně. Obsahuje část vzdělávacího obsahu vzdělávacího oboru Informační

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

Příloha č.3 Otázka pro hodnocení manažera

Příloha č.3 Otázka pro hodnocení manažera Příloha č.3 Otázka pro hodnocení manažera 1. Sleduje profesní a technický vývoj? 2. Připravuje a dodržuje realistický rozpočet? 3. Zaměřuje se na podstatné informace a neztrácí se v nedůležitých detailech?

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

Operační systém. Mgr. Renáta Rellová. Výukový materiál zpracován v rámci projektu EU peníze školám

Operační systém. Mgr. Renáta Rellová. Výukový materiál zpracován v rámci projektu EU peníze školám Operační systém Mgr. Renáta Rellová Výukový materiál zpracován v rámci projektu EU peníze školám Autorem materiálu a všech jeho částí, není-li uvedeno jinak, je Mgr. Renáta Rellová. Dostupné z Metodického

Více

schopni vysvětlit, co znamená protokol NFS a k čemu se používá; umět rozpoznat autorské dílo a znát autorská práva;

schopni vysvětlit, co znamená protokol NFS a k čemu se používá; umět rozpoznat autorské dílo a znát autorská práva; POKYNY KE STUDIU 1 Rozšiřující data na Internetu Pracovní materiály Doprovodné obrázky a videa na Internetu Rejstřík pojmů 7 SDÍLENÍ DAT Čas ke studiu: 1,5 hodiny Cíl: Po prostudování této kapitoly budete:

Více

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. 4

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. 4 DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. 4 Zadavatel: Česká republika Ministerstvo životního prostředí Sídlo: Vršovická 1442/65, 100 10 Praha 10 IČO: 00164801 Jednající: Název veřejné zakázky: Ing.

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

Personální audit. Audit informačního systému. Audit SW a HW

Personální audit. Audit informačního systému. Audit SW a HW Personální audit Audit informačního systému Audit SW a HW Jméno: UČO: forma studia: ročník: 2014 Brno Úvodní zpráva Konkretizujte předmět auditovaní. Identifikace objektu pozorování. Účel auditu. Stanovené

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

Operační systémy: funkce

Operační systémy: funkce Operační systémy Software, který zabezpečuje základní chod počítače, je prostředníkem mezi hardwarem a aplikačním softwarem. Nutný základní software v počítači. Vykonává řadu rutinních operací, které by

Více

Nová áplikáce etesty Př í přává PC ž ádátele

Nová áplikáce etesty Př í přává PC ž ádátele Nová áplikáce etesty Př í přává PC ž ádátele Verze 0.6 Datum aktualizace 20. 12. 2014 Obsah 1 Příprava PC žadatele... 2 1.1 Splnění technických požadavků... 2 1.2 Prostředí PC pro žadatele... 2 1.3 Příprava

Více

úvod Historie operačních systémů

úvod Historie operačních systémů Historie operačních systémů úvod Autorem materiálu a všech jeho částí, není-li uvedeno jinak, je Ing. Libor Otáhalík. Dostupné z Metodického portálu www.rvp.cz, ISSN: 1802-4785. Provozuje Národní ústav

Více

Testovací protokol. webový generátor PostSignum. sada PIIX3; 1 GB RAM; harddisk 20 GB IDE OS: Windows Vista Service Pack 2 SW: Internet Explorer 9

Testovací protokol. webový generátor PostSignum. sada PIIX3; 1 GB RAM; harddisk 20 GB IDE OS: Windows Vista Service Pack 2 SW: Internet Explorer 9 Příloha č. 4 1 Informace o testování estovaný generátor: 2 estovací prostředí estovací stroj č. 1: estovací stroj č. 2: estovací stroj č. 3: Certifikáty vydány autoritou: estovací protokol webový generátor

Více

TESTOVÁNÍ UŽIVATELSKÉHO ROZHRANÍ

TESTOVÁNÍ UŽIVATELSKÉHO ROZHRANÍ SEMESTRÁLNÍ PRÁCE TESTOVÁNÍ UŽIVATELSKÉHO ROZHRANÍ Jakub Wagner wagnejak@fel.cvut.cz 1. ÚVOD Cílem práce bude otestovat výukovou aplikaci angličtiny na DVD pro základní školy. Aplikace je cílena pro ovládání

Více

E-mailové kampaně. 2013 Byznys CRM s.r.o.

E-mailové kampaně. 2013 Byznys CRM s.r.o. E-mailové kampaně 2013 Byznys CRM s.r.o. Zákazník: Dne: 31. 5. 2015 Vytvořil: Pavel Šlesingr Schválil: Petr Hampejs Verze: 5.0 Emailové kampaně v CRM 2011 Strana 2 z 15 Obsah Obsah... 3 1. Popis... 4 1.1.

Více

Metodická pomůcka pro specifikaci dočasných opatření. doc. Ing. Pavel Šenovský, Ph.D. Ing. Pavlína Ježková

Metodická pomůcka pro specifikaci dočasných opatření. doc. Ing. Pavel Šenovský, Ph.D. Ing. Pavlína Ježková Metodická pomůcka pro specifikaci dočasných opatření doc. Ing. Pavel Šenovský, Ph.D. Ing. Pavlína Ježková Vysoká škola báňská Technická univerzita Ostrava, Fakulta bezpečnostního inženýrství Ostrava 2013

Více

FIREMNÍ CERTIFIKÁT V APLIKACI PŘÍMÝ KANÁL NÁVOD PRO KLIENTY

FIREMNÍ CERTIFIKÁT V APLIKACI PŘÍMÝ KANÁL NÁVOD PRO KLIENTY FIREMNÍ CERTIFIKÁT V APLIKACI PŘÍMÝ KANÁL NÁVOD PRO KLIENTY 1. POUŽITÍ FIREMNÍHO CERTIFIKÁTU 1.1 Stručný popis Firemní certifikát je nový typ certifikátu, který Vám umožní zrychlit a zjednodušit Vaši práci.

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

Řízení rizik. Ing. Petra Plevová. plevova.petra@klikni.cz http://plevovapetra.wbs.cz

Řízení rizik. Ing. Petra Plevová. plevova.petra@klikni.cz http://plevovapetra.wbs.cz Řízení rizik Ing. Petra Plevová plevova.petra@klikni.cz http://plevovapetra.wbs.cz Procesní řízení a řízení rizik V kontextu současných změn je třeba vnímat řízení jakékoli organizace jako jednoduchý,

Více

SYSTÉM SCREENS SYSTEM SCREENS

SYSTÉM SCREENS SYSTEM SCREENS SYSTÉM SCREENS SYSTEM SCREENS F. Vaněk 1.LF UK Praha, gyn.por.klinika Abstrakt Systém screens je softwarový nástroj na zvýšení kvality výuky, která je vázána na práci s PC. V základní podobě umožňuje vyučujícímu

Více

Jak testovat software v praxi. aneb šetříme svůj vlastní čas

Jak testovat software v praxi. aneb šetříme svůj vlastní čas Jak testovat software v praxi aneb šetříme svůj vlastní čas Proč testy nepíšeme Nemáme na to čas Platí v cca 5% případů Nový projekt Prototyp je třeba mít během pár dní Počítá se s tím, že další verze

Více

1.1 Zátěžové testování

1.1 Zátěžové testování 1.1 Zátěžové testování Předpokladem pro toto stádium testování je ukončení funkčních testů a zamražení systému pro zátěžové testování. Toto stádium testování má podpořit systémové testování a poukázat

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 materiálem o normě ICS: 03.220.01; 35.240.60 Komunikační infrastruktura pro pozemní ISO 24101-2 mobilní

Více

INFORMAČNÍ SYSTÉMY (IS) Ing. Pavel Náplava Katedra počítačů K336, ČVUT FEL Praha 2004/2005

INFORMAČNÍ SYSTÉMY (IS) Ing. Pavel Náplava Katedra počítačů K336, ČVUT FEL Praha 2004/2005 INFORMAČNÍ SYSTÉMY (IS) Ing. Pavel Náplava Katedra počítačů K336, ČVUT FEL Praha 2004/2005 AGENDA definice IS, zavedení pojmů možnosti a rozdělení typická struktura technologie nasazení praktická ukázka

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

Hodnoticí standard. Manažer projektu (kód: 63-007-R) Odborná způsobilost. Platnost standardu. Skupina oborů: Ekonomika a administrativa (kód: 63)

Hodnoticí standard. Manažer projektu (kód: 63-007-R) Odborná způsobilost. Platnost standardu. Skupina oborů: Ekonomika a administrativa (kód: 63) Manažer (kód: 63-007-R) Autorizující orgán: Ministerstvo pro místní rozvoj Skupina oborů: Ekonomika a administrativa (kód: 63) Týká se povolání: Manažer Kvalifikační úroveň NSK - EQF: 6 Odborná způsobilost

Více

INOVACE PŘEDMĚTŮ ICT. MODUL 11: PROGRAMOVÁNÍ WEBOVÝCH APLIKLACÍ Metodika

INOVACE PŘEDMĚTŮ ICT. MODUL 11: PROGRAMOVÁNÍ WEBOVÝCH APLIKLACÍ Metodika Vyšší odborná škola ekonomická a zdravotnická a Střední škola, Boskovice INOVACE PŘEDMĚTŮ ICT MODUL 11: PROGRAMOVÁNÍ WEBOVÝCH APLIKLACÍ Metodika Zpracoval: Jaroslav Kotlán srpen 2009s Úvod Modul Programování

Více

ŠVP Gymnázium Ostrava-Zábřeh. 4.8.16. Úvod do programování

ŠVP Gymnázium Ostrava-Zábřeh. 4.8.16. Úvod do programování 4.8.16. Úvod do programování Vyučovací předmět Úvod do programování je na naší škole nabízen v rámci volitelných předmětů v sextě, septimě nebo v oktávě jako jednoletý dvouhodinový kurz. V případě hlubšího

Více

Obchodní akademie, Náchod, Denisovo nábřeží 673

Obchodní akademie, Náchod, Denisovo nábřeží 673 Název vyučovacího předmětu: GRAFIKA NA PC (GRA Obor vzdělání: 18 20 M/01 Informační technologie Forma vzdělání: denní Celkový počet vyučovacích hodin za studium: 154 (5 hodin týdně) Platnost: 1. 9. 2009

Více

Projektová dokumentace pro tvorbu internetových aplikací

Projektová dokumentace pro tvorbu internetových aplikací Projektová dokumentace pro tvorbu internetových aplikací Tomáš Kuthan PhDr. Milan Novák, Ph.D. Školní rok: 2008-09 Abstrakt Bakalářská práce stanovuje vzor pro vytváření projektové dokumentace internetových

Více

Národní infrastruktura pro elektronické zadávání veřejných zakázek (NIPEZ)

Národní infrastruktura pro elektronické zadávání veřejných zakázek (NIPEZ) Ministerstvo pro místní rozvoj ČR, Odbor veřejného investování, květen 2011 Národní infrastruktura pro elektronické zadávání veřejných zakázek (NIPEZ) Obsah prezentace 1. Základní vymezení NIPEZ... 3-6

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

Software pro analýzu energetických dat W1000

Software pro analýzu energetických dat W1000 Software pro analýzu energetických dat W1000 Data pro snadný život vašich zákazníků Manage energy better Mít správné informace ve správný čas je základem úspěchu každého snažení, tedy i řízení spotřeby

Více

1. Úvod do obsluhy AutoCADu

1. Úvod do obsluhy AutoCADu 1. Úvod do obsluhy AutoCADu Studijní cíl V této lekci se naučíme: Seznámíme se s potřebným zařízením. Způsoby ovládání. Nastavení AutoCADu. Doba nutná k procvičení 1,5 hodiny 1.1 AutoCAD AutoCAD je plnohodnotný

Více

Architektura počítačů

Architektura počítačů Architektura počítačů Studijní materiál pro předmět Architektury počítačů Ing. Petr Olivka katedra informatiky FEI VŠB-TU Ostrava email: petr.olivka@vsb.cz Ostrava, 2010 1 1 Architektura počítačů Pojem

Více

TOGETHER WE CAN projekt interních koučů v UniCredit Bank

TOGETHER WE CAN projekt interních koučů v UniCredit Bank TOGETHER WE CAN projekt interních koučů v UniCredit Bank Firma: UniCredit Bank Czech Republic, a.s. Na Příkopě 858/20 111 21 Praha 1 www.unicreditbank.cz Kontaktní osoba: Lenka Štěpánová Learning & Development

Více