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

Testování softwaru. 10. dubna Bořek Zelinka

Testování softwaru. 10. dubna Bořek Zelinka Testování softwaru 10. dubna 2013 Bořek Zelinka Agenda Definice testování Testování v rámci vývoje softwaru Základní rozdělení testů Představení testovacích technik Testovací strategie Copyright Unicorn

Více

Náklady na odstranění chyby stoupají, v čím pozdější fázi životního cyklu aplikace je chyba nalezena.

Náklady na odstranění chyby stoupají, v čím pozdější fázi životního cyklu aplikace je chyba nalezena. Testování software Testování SW má podstatný vliv na kvalitu dodaného produktu. Náklady na odstranění chyby stoupají, v čím pozdější fázi životního cyklu aplikace je chyba nalezena. Na druhé straně, vytvořit

Více

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

Testování software. Jaroslav Žáček

Testování software. Jaroslav Žáček Testování software Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Testování Obsáhlá disciplína, existuje spoustu pohledů Problém při nastavení míry kvality Kvalita: Schopnost objektu být

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

Studie webů automobilek

Studie webů automobilek Studie webů automobilek červen 2006 [manažerské shrnutí] Obsah Obsah... 1 Manažerské shrnutí... 2 Kvalita obsahu a použitelnost webu... 3 Základní nedostatky negativně ovlivňují použitelnost většiny webů...

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

TECHNICKÉ POŽADAVKY NA NÁVRH, IMPLEMENTACI, PROVOZ, ÚDRŽBU A ROZVOJ INFORMAČNÍHO SYSTÉMU

TECHNICKÉ POŽADAVKY NA NÁVRH, IMPLEMENTACI, PROVOZ, ÚDRŽBU A ROZVOJ INFORMAČNÍHO SYSTÉMU zadávací dokumentace TECHNICKÉ POŽADAVKY NA NÁVRH, IMPLEMENTACI, PROVOZ, ÚDRŽBU A ROZVOJ INFORMAČNÍHO SYSTÉMU Stránka 1 z 6 Obsah 1. Specifikace požadavků webové stránky... 4 2. Specifikace technických

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

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

14. května 2012, Brno

14. května 2012, Brno 14. května 2012, Brno Připravil: Tomáš Koubek Testování Cvičení z předmětu Pokročilá uživatelská rozhraní Testování Strana 2 / 12 Testování aplikací Testování návrhu Cílem je vylepšit produkt během vývoje.

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

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

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

Testování Java EE aplikací Petr Adámek

Testování Java EE aplikací Petr Adámek Testování Java EE aplikací Petr Adámek Testování aplikací Testování aplikací Ověřuje soulad implementace se specifikací a s očekáváním zákazníka. Je důležitou součástí procesu řízení kvality vývoje software

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

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

Bohuslav Mach, Správce úkolů. pro informační systém firmy s-cape.cz 1/6

Bohuslav Mach, Správce úkolů. pro informační systém firmy s-cape.cz 1/6 Správce úkolů pro informační systém firmy s-cape.cz 1/6 Popis aplikace - D1 Aplikace umožňující uživateli s vytvořeným účtem v informačním systému firmy s-cape.cz prohlížet a editovat s nim spojené úkoly.

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

ešení pro správu klientských počítač a mobilní tisk Číslo dokumentu:

ešení pro správu klientských počítač a mobilní tisk Číslo dokumentu: ešení pro správu klientských počítač a mobilní tisk Číslo dokumentu: 410173-221 Leden 2006 Obsah 1 ešení pro správu klientských počítač Konfigurace a nasazení....................... 1 2 Správa a aktualizace

Více

Charta projektu úplné znění pro MŠMT a jeho příspěvkové organizace a Českou školní inspekci

Charta projektu úplné znění pro MŠMT a jeho příspěvkové organizace a Českou školní inspekci Charta projektu úplné znění pro MŠMT a jeho příspěvkové organizace a Českou školní inspekci 1 Obsah Manažerské Shrnutí... 3 Definice projektu rámcová část... 3 Stručný kontext realizace projektu... 3 Cíle

Více

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

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

Více

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

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

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

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

Testing as a Service. Přístupné, flexibilní a cenově výhodné řešení pro ověření kvality softwaru. Kompletní portfolio služeb testování softwaru

Testing as a Service. Přístupné, flexibilní a cenově výhodné řešení pro ověření kvality softwaru. Kompletní portfolio služeb testování softwaru Testing as a Service Přístupné, flexibilní a cenově výhodné řešení pro ověření kvality softwaru Kompletní portfolio služeb testování softwaru Předem známé náklady na testování, umožňující efektivní tvorbu

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

Proces vývoje HRIS Vema (Human Resources Information System) Jaroslav Šmarda

Proces vývoje HRIS Vema (Human Resources Information System) Jaroslav Šmarda Proces vývoje HRIS Vema (Human Resources Information System) Jaroslav Šmarda Proces vývoje HRIS Vema Vlastnosti HRIS (Human Resources Information System) HRIS Vema Proces vývoje HRIS Vema Vema, a. s. Přední

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

K datu je k dispozici vylepšená verze aplikace AirKey. Následující nové funkce a vylepšení jsou dostupné s novou verzí:

K datu je k dispozici vylepšená verze aplikace AirKey. Následující nové funkce a vylepšení jsou dostupné s novou verzí: Poznámky k verzi 24.03.2016 systému AirKey K datu 24.03.2016 je k dispozici vylepšená verze aplikace AirKey. Následující nové funkce a vylepšení jsou dostupné s novou verzí: Optimalizovaná komunikace mezi

Více

Úvod. Klíčové vlastnosti. Jednoduchá obsluha

Úvod. Klíčové vlastnosti. Jednoduchá obsluha REQUESTOR DATASHEET Úvod Requestor Service Desk poskytuje kompletní řešení pro správu interních i externích požadavků, které přicházejí do organizace libovolnou cestou. Produkt je zaměřen na vytvoření

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

Procesní přístup k projektům informačních systémů. RNDr. Vladimír Krajčík, Ph.D.

Procesní přístup k projektům informačních systémů. RNDr. Vladimír Krajčík, Ph.D. Procesní přístup k projektům informačních systémů RNDr. Vladimír Krajčík, Ph.D. Jaká byla moje cesta k zavedení a užití procesních prvků při řízení projektů veřejných informačních systémů se zaměřením

Více

Provozní pokyny Aplikační stránky

Provozní pokyny Aplikační stránky Před použitím tohoto zařízení si důkladně přečtěte tento manuál a mějte jej po ruce pro budoucí použití. Provozní pokyny Aplikační stránky OBSAH Jak číst tuto příručku...2 Použité symboly...2 Vyloučení

Více

Hodnoticí standard. Programátor (kód: M) Odborná způsobilost. Platnost standardu. Skupina oborů: Informatické obory (kód: 18)

Hodnoticí standard. Programátor (kód: M) Odborná způsobilost. Platnost standardu. Skupina oborů: Informatické obory (kód: 18) Programátor (kód: 18-003-M) Autorizující orgán: Ministerstvo vnitra Skupina oborů: Informatické obory (kód: 18) Týká se povolání: Programátor Kvalifikační úroveň NSK - EQF: 4 Odborná způsobilost Název

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

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

Význam měřm. Mgr. Anna Borovcová doc. Ing. Alena Buchalcevová, Ph.D. VŠE Praha

Význam měřm. Mgr. Anna Borovcová doc. Ing. Alena Buchalcevová, Ph.D. VŠE Praha Význam měřm ěření v testování softwaru Mgr. Anna Borovcová doc. Ing. Alena Buchalcevová, Ph.D VŠE Praha Motivace The Standish Group reporty za roky 1994 2009 1994 1996 1998 2000 2002 2004 2006 2009 Úspěšných

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

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

Ú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

IS pro managment flotily vozidel. Project overview statement

IS pro managment flotily vozidel. Project overview statement IS pro managment flotily vozidel palubní jednotka Project overview statement Jméno projektu IS pro managment flotily vozidel Oblast dokumenut Palubní jednotka Zkratka projektu Metrocar Editováno 11.11.2011

Více

Manažerská informatika - projektové řízení

Manažerská informatika - projektové řízení VŠE, fakulta Podnikohospodářská Manažerská informatika - projektové řízení Projekt implementace informačního systému Jiří Mikloš 2009 Obsah Obsah Obsah... 2 Úvod... 3 Zadání... 4 Projektový postup... 5

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

Role zákona č. 219/ 2000 Sb. o majetku ČR a zákona č. 218/2000 Sb. o rozpočtových pravidlech v procesu zadávání veřejných zakázek

Role zákona č. 219/ 2000 Sb. o majetku ČR a zákona č. 218/2000 Sb. o rozpočtových pravidlech v procesu zadávání veřejných zakázek Role zákona č. 219/ 2000 Sb. o majetku ČR a zákona č. 218/2000 Sb. o Příloha č. A2 Dokumentu Jak zohledňovat principy 3E (hospodárnost, efektivnost a účelnost) v postupech Vydal: Ministerstvo pro místní

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

Poznámky k verzi systému AirKey

Poznámky k verzi systému AirKey Poznámky k verzi 11.08.2016 systému AirKey Abychom vám mohli nabízet co nejlepší služby a velmi kvalitní výrobek, snažíme se nepřetržitě rozšiřovat systém AirKey o nové funkce a zlepšovat jeho stávající

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

Seminární práce Vývoj informačního systému. Manažerská informatika 2 Ing. Miroslav Lorenc

Seminární práce Vývoj informačního systému. Manažerská informatika 2 Ing. Miroslav Lorenc Seminární práce Vývoj informačního systému Manažerská informatika 2 Ing. Miroslav Lorenc Vypracoval: Jan Vít (xvitj17) LS 2007/2008 1. ÚVOD...3 1.1. POPIS PROJEKTU...3 2. OBSAH PROJEKTU...3 2.1. SEZNAM

Více

Metodiky pro automatické testování webové aplikace. Ondřej Melkes, Martin Komenda

Metodiky pro automatické testování webové aplikace. Ondřej Melkes, Martin Komenda Metodiky pro automatické testování webové aplikace Ondřej Melkes, Martin Komenda Obsah Testování sw obecně Unit testy Integrační testy Testování UI Nesprávné testování sw Neznalost testovacího procesu

Více

Ing. Pavel Rosenlacher

Ing. Pavel Rosenlacher Marketing v sociálních sítích Webová analytika Ing. Pavel Rosenlacher pavel.rosenlacher@vsfs.cz Krátké shrnutí SEO spočívá v lepším zobrazování stránek ve výsledcích vyhledávání na vyhledávačích Souhrnně

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

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

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

Přehledový manuál aplikace GABVAR (verze )

Přehledový manuál aplikace GABVAR (verze ) Základní informace: Vývojová skupina Gabvar byla založena v roce 2007. Náplní skupiny je vývoj aplikací pro podporu procesů v oblasti managmentu, údržby a logistiky. Jsme skupinou pracovníků s praxí na

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

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

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

Více

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

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

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

Vysoká škola technická a ekonomická v Českých Budějovicích. Institute of Technology And Business In České Budějovice

Vysoká škola technická a ekonomická v Českých Budějovicích. Institute of Technology And Business In České Budějovice 10. PLÁN RIZIK, PROJEKTOVÁ DOKUMENTACE, VÝBĚROVÉ ŘÍZENÍ A NÁKUPY Vysoká škola technická a ekonomická v Českých Budějovicích Institute of Technology And Business In České Budějovice Tento učební materiál

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

Kvalita SW produktů. Jiří Sochor, Jaroslav Ráček 1

Kvalita SW produktů. Jiří Sochor, Jaroslav Ráček 1 Kvalita SW produktů Jiří Sochor, Jaroslav Ráček 1 Klasický pohled na kvalitu SW Každý program dělá něco správně; nemusí však dělat to, co chceme, aby dělal. Kvalita: Dodržení explicitně stanovených funkčních

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

ú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

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

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

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

Poznámky k verzi systému AirKey

Poznámky k verzi systému AirKey Poznámky k verzi 11.2.2016 systému AirKey Abychom vám mohli nabízet co nejlepší služby a velmi kvalitní výrobek, snažíme se nepřetržitě rozšiřovat systém AirKey o nové druhy funkcí a zlepšovat ty stávající.

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

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

Obsah. 1) Rozšířené zadání 2) Teorie zásuvných modulů a) Druhy aplikací používajících zásuvné moduly b) Knihovny c) Architektura aplikace d) Výhody

Obsah. 1) Rozšířené zadání 2) Teorie zásuvných modulů a) Druhy aplikací používajících zásuvné moduly b) Knihovny c) Architektura aplikace d) Výhody Obsah 1) Rozšířené zadání 2) Teorie zásuvných modulů a) Druhy aplikací používajících zásuvné moduly b) Knihovny c) Architektura aplikace d) Výhody 3) 4) Mantichora Mantichora je moderní aplikace, který

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

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

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

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

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

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

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

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

Více

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

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

MULTIMEDIÁLNÍ A HYPERMEDIÁLNÍ SYSTÉMY

MULTIMEDIÁLNÍ A HYPERMEDIÁLNÍ SYSTÉMY MULTIMEDIÁLNÍ A HYPERMEDIÁLNÍ SYSTÉMY 1) Úvod do problematiky Petr Lobaz, 18. 2. 2004 ORGANIZACE PŘ EDMĚ TU POŽADAVKY KE ZKOUŠCE vypracování semestrální práce (max. 70 bodů) napsání testu (max. 30 bodů)

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

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

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

1 Uživatelská dokumentace

1 Uživatelská dokumentace 1 Uživatelská dokumentace Systém pro závodění aut řízených umělou inteligencí je zaměřen na závodění aut v prostředí internetu. Kromě toho umožňuje testovat jednotlivé řidiče bez nutnosti vytvářet závod

Více

Projekt Velryba Ozdravné pobyty pro děti. Semestrální projekt

Projekt Velryba Ozdravné pobyty pro děti. Semestrální projekt Předmět AD7B36SI2 Informační systém ozdravných pobytů ČVUT FEL, obor STM Softwarové inženýrství 5. semestr, zima 2011/2012 Zpracovala: Radoslava Jandová Username: jandora1 e-mail: jandora1@fel.cvut.cz

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

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

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

Hardening ICT platforem: teorie nebo praxe. Pavel Hejduk ČEZ ICT Services, a. s.

Hardening ICT platforem: teorie nebo praxe. Pavel Hejduk ČEZ ICT Services, a. s. Hardening ICT platforem: teorie nebo praxe Pavel Hejduk ČEZ ICT Services, a. s. Agenda ICT prostředí ČEZ ICT Services a. s. Hardening ICT platforem - definice Obvyklý přístup a jeho omezení zhodnocení

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

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

Klíčové kompetence. Jako jeden z nosných prvků reformy

Klíčové kompetence. Jako jeden z nosných prvků reformy Klíčové kompetence Jako jeden z nosných prvků reformy Klíčové kompetence Podle Rámcového vzdělávacího programu pro základní vzdělávání má základní vzdělávání žákům pomoci utvářet a postupně rozvíjet klíčové

Více

Testování mobilní navigace NACESTY

Testování mobilní navigace NACESTY České vysoké učení technické v Praze Fakulta elektrotechnická A7B39TUR 2015/2016, A2 Testování mobilní navigace NACESTY Kognitivní průchod a heuristická evaluace Jakub Berka berkajak@fel.cvut.cz Obsah

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

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

DISTRIBUCE GNU/LINUXU

DISTRIBUCE GNU/LINUXU DISTRIBUCE GNU/LINUXU Název školy Obchodní akademie, Vyšší odborná škola a Jazyková škola s právem státní jazykové zkoušky Uherské Hradiště Název DUMu Distribuce GNU/Linuxu Autor Martin Šimůnek Datum 14.

Více