Semestrální práce ISO/IEC/IEEE 29119
|
|
- Richard Růžička
- před 6 lety
- Počet zobrazení:
Transkript
1 Semestrální práce ISO/IEC/IEEE
2 Semestrální práce ke kurz 4IT421 - Zlepšování procesů budování IS Semestr ZS 2015/2016 Autoři Bc. David Tůma Bc. Šimon Machač Téma ISO/IEC/IEEE Datum odevzdání
3 Abstrakt Tato práce pojednává o normě ISO SO/IEC/IEEE :2013 Software and systems engineering -- Software testing -- Part 3: Test documentation, která se zabývá testováním softwaru. Práce je rozdělena do dvou hlavních částí. První část se věnuje dokumentům, které vznikají při testování organizace. Tyto dokumenty jsou stručně charakterizovány a jsou zde také uvedeny příklady jednotlivých dokumentů. Druhá část se zabývá dokumenty, které vznikají při dynamickém testování softwaru. Dokumenty v této části jsou také charakterizovány a samozřejmostí je představení příkladů dokumentů. Klíčová slova ISO/IEC/IEEE , norma, testování, software, dokumentace, proces 3
4 Obsah Kompletní schéma normy... 7 Dokumentace testovacího procesu organizace... 7 Politika testování... 8 Strategie testování organizace Dokumentace procesů řízení testování Plán testování Dokumentace dynamických testovacích procesů Specifikace návrhu testování Specifikace testovacích případů Specifikace postupů testování Požadavky na testovací data Požadavky na testovací prostředí Zpráva o připravenosti testovacích data a prostředí Skutečné výsledky a Výsledek testování Protokol o provádění testování Podávání zpráv o incidentech testování Zpráva o stavu testování Zpráva o dokončení testování Závěr Zdroje
5 Úvod Normy rodiny ISO/IEC/IEEE jsou poměrně nové normy, které se věnují testování softwaru. Tato práce se zaměřuje na třetí část, která se věnu dokumentaci během testování softwaru, jejíž přesný název zní ISO SO/IEC/IEEE :2013 Software and systems engineering -- Software testing -- Part 3: Test documentation dále jen norma. Během testování se používá mnoho druhý dokumentů a tato norma definuje dokumenty, které vyházejí z tzv. best practices z testování softwaru. Hlavním zdrojem pro tuto práci byl ovšem ne originál normy, ale její český překlad ČSN ISO/IEC/IEEE Softwarové a systémové inženýrství Testování softwaru Dokumentace testování. Cílem této práce je shrnout tuto normu do podoby, která by čtenáři umožnila co nejlépe pochopit podstatu normy a představit a stručně charakterizovat obsah jednotlivých dokumentů, které norma obsahuje. 5
6 Předmět normy ISO/IEC/IEEE je část normy, která se zabývá dokumentací testování, která vzniká při procesu testování. Obsahuje několik druhů příloh, jako například hlavní rysy každého dokumentu, mapování na již existující normy, přehled příkladů, příklady aplikací šablon a další. Podstatné je, že velká část této normy vychází z části předchozí, tedy ISO/IEC/IEEE , jejíž cílem je specifikovat testovací procesy, které mohou být použity ke správě, řízení a implementaci testování softwaru. (ISO, 2015) 6
7 Kompletní schéma normy Obrázek 1 - Hierarchie dokumentace (ISO, 2015) Při pohledu na kompletní schéma celé části normy je patrné, že veškerá dokumentace vznikající při procesu testování se odvíjí od Politiky testování. Od tohoto dokumentu se celé schéma dále rozkládá na jednotlivé strategie testování organizace, což je kvůli překladu trošku zavádějící pojem, jelikož se jedná spíše o strategii testování na úrovni organizace. Taková strategie může být jedna či více. Dále se dostaneme k jednotlivým plánům testování, přičemž každý projekt má svůj specifický plán. Všechny dokumenty zmíněné v této kapitole, budou později podrobněji představeny a věnovat se bude semestrální práce i jejich obsahu, z pohledu agilní korporace i tradiční společnosti, což jsou dva základní příklady, na kterých jsou uváděny příklady použití napříč celou částí normy. Dokumentace testovacího procesu organizace Jak již předešlá kapitola naznačuje, jedná se o dokumenty obsahující informace o testování na úrovni organizace, čili ty, které se neliší v závislosti na jednotlivých projektech a jsou tedy pro tyto projekty shodné. Opět bych chtěl podotknout, na nevhodný překlad z anglické verze této části normy, kdy překladatel nijak nerozlišuje dvě odlišné úrovně testovací dokumentace v obrázku vyjadřující hierarchii a obě tyto úrovně nazývá stejně i přes to, že v původní anglické 7
8 verzi se tyto úrovně názvy liší. Klíčové pro tuto úroveň testovací dokumentace jsou dva dokumenty: Politika testování Strategie testování organizace Dále budou v semestrální práci tyto dokumenty představeny společně s uvedenými příklady. Politika testování Jedná se o výchozí dokument celé hierarchie testovací dokumentace. Důvody pro vznik tohoto dokumentu je definice cílů a principů testování softwaru, které by měly platit v rámci celé organizace. Dokument se zabývá a odpovídá na otázku, čeho se má testováním dosáhnout a poskytuje rámec pro ustavení, posuzování a neustálé zlepšování politiky testování v organizaci. Obrázek 2 - Úroveň dokumentace pro Politiku testování (ISO, 2015) Norma jasně stanovuje, jaké části musí zmíněný dokument obsahovat, ovšem s přihlédnutím k přílohám normy je zjevné, že záleží, o jaký typ organizace se jedná. Pokud bychom chtěli mít dokument kompletní, tak jak norma stanovuje, je zapotřebí doplnit následující údaje: Cíle testování - popisuje účel a celkový rozsah testování v rámci organizace, sděluje čtenáři, proč se testování provádí a čeho se snaží dosáhnout Testovací proces - určí testovací proces, kterým se organizace bude řídit. Tato část úzce souvisí s předchozí částí, tedy ISO/IEC/IEEE , ze které může čerpat Struktura testovacího oddělení - určení jednotlivých rolí při testování a následné určení struktury oddělení. Norma akceptuje použití diagramu či tabulky pro znázornění Školení testerů - informace o požadovaných školení a certifikací pro účastníky testování Etika testerů - stanoví etický kodex, dále při testování dodržovaný Normy - uvádí jaké normy lze aplikovat v testovacím oddělení Další relevantní politiky - v případě potřeby uvede další politiky, mající vliv na testování Měření hodnoty testování - uvádí jak organizace stanoví návratnost investic vložených do testování, dále stanoví cíl takového měření Archivace a opětovné použití aktiv testování - stanoví postoj organizace k archivaci a opětovnému použití Zlepšování testovacího procesu - uvádí metodu pro zajištění neustálého zlepšování 8
9 Pro správné pochopení každé potřebné části dokumentu, uvádí vždy norma dva konkrétní příklady daného dokumentu. Obrázek 3, 4 jsou přímo normou udávané příklady použití. Obrázek 3 - Příklad dokumentu Politika testování (ISO, 2015) 9
10 Obrázek 4 - Příklad dokumentu Politika testování (ISO, 2015) Strategie testování organizace Další dokument z této úrovně testovací dokumentace je Strategie testování organizace. Jedná se o dokument, který poskytuje pokyny, jak by testování v organizaci mělo být prováděno, neboli jak dosáhnout cílů stanovených v dokumentu předchozím, tedy v Politice testování. Dokument Strategie testování organizace není specifický pro jednotlivé projekty, nýbrž se jedná o obecný dokument na úrovni organizace, a jak potvrzuje Obrázek 3, těchto dokumentů může být i více. V závislosti na velikosti organizace. Dokument dále obsahuje identifikaci relevantních testovacích podprocesů a formulace strategie pro každý z nich. 10
11 Obrázek 5 - Úroveň dokumentace pro Strategii testování organizace (ISO, 2015) Na rozdíl od dokumentu Politika testování se dokument Strategie testování organizace dělí na dvě základní části: Formulace strategie testování organizace v rámci celého projektu - norma uvádí, že v této části bychom měli nalézt formulace, které jsou vhodné pro všechny testovací podprocesy prováděné v daném projektu v rámci strategie. V případě potřeby může tato část obsahovat podsekce z politiky. Celou tuto část tvoří následující údaje: Řízení obecných rizik - určuje obecný přístup organizace k řízení rizik Výběr a nastavení priorit testování - sděluje, jak organizace nastaví priority při provádění testování Zprávy o testování a dokumentace testování - identifikuje dokumenty, které vzniknou během testování, a dále popisuje, kdy je každý z nich připraven. Úzce spojeno s testovacím procesem, který je specifikován v politice. Automatizace testování a nástroje - deklaruje organizací zvolený přístup k automatizaci testování. Dále popisuje testovací nástroje využité po celou dobu testování Správa konfigurací pracovních výsledků testování - jde o popis správy konfigurací, která má být prováděna s pracovními výsledky. Dále popisuje, jak pracovní výsledky testování identifikovat, nalézt, uložit a zpřístupnit zúčastněným stranám Správa incidentů - popisuje správu incidentů během testování popřípadě odkazuje na popis nacházející se na jiném místě Testovací podprocesy - identifikuje specifické testovací podprocesy, které jsou součástí testování v rámci strategie Formulace strategie testování organizace specifické pro testovací podprocesy - tato část obsahuje tyto údaje: Vstupní a výstupní kritéria - jde o specifikaci kritérií používaných při určování, kdy by měly testovací aktivity pro daný podproces začít a kdy skončit 11
12 Kritéria dokončení testování - jde o popis, kdy považuje organizace testovací aktivity testovacích podprocesů za dokončené Zprávy o testování a dokumentace testování - určuje dokumentaci testování, včetně zpráv o testování. Zaměřuje se na popis každého dokumentu a informuje, kdy jsou tyto dokumenty připravené Stupeň nezávislosti - stanovuje skupině provádějící testování technickou, manažerskou a finanční nezávislost. Techniky návrhu testování - pojednává o specifických technikách návrhu testování, které mají být použity během návrhu a implementace testování v rámci testovacího podprocesu Testovací prostředí - popisuje testovací prostředí pro testovací podproces, dále definuje skupiny nebo organizace odpovědné za toto prostředí Metriky ke shromažďování - popisuje metriky, ke kterým budou shromažďovány hodnoty během testovacích aktivit testovacího podprocesu Opětovné a regresní testování - identifikuje strategii, podmínky a aktivity opětovného a regresního testování testovacího podprocesu Dokumentace procesů řízení testování Následující kapitola pojednává o další úrovni vzniku testovací dokumentace. Jak je patrné z první kapitoly znázorňující kompletní schéma, vznikat zde budou následující dokumenty: Plán testování Zpráva o stavu testování Zpráva o dokončení testování Cílem kapitoly je opět představit význam jednotlivých dokumentů a poukázat na specifické informace, které by měly obsahovat. Veškerá dokumentace zmíněná v normě totiž obsahuje shodné základní údaje o dokumentu a až poté se jednotlivé dokumenty liší svým obsahem. Plán testování Poskytuje dokument plánování testování a řízení testování, přičemž některé dokumenty mohou mít pouze jediný plán testování, ale není vyloučena ani situace, kdy vzhledem k velikosti projektu, existuje více takových plánů. Obdobně je možné, aby se Plán testování vztahoval na jeden nebo více projektů. Pro nás je důležité zmínit, z čeho se takový Plán testování skládá, jde o následující části: Kontext testování Projekty / testovací podprocesy - stanoví projekty popřípadě testovací podprocesy, pro které je plán psán Testované položky - zde by se měly nacházet všechny testované položky související s tímto plánem a to včetně verzí/revizí nebo odkaz k nalezení takových informací 12
13 Rozsah testování - shrnuje funkce testovaných položek k otestování. Může se jednat o specifické atributy softwaru, funkcí, rozhraní nebo byznys procesů. Zde se uvádí i naopak funkce vyloučené z testování podpořené odůvodněním. Předpoklady a omezení - jde o popis předpokladů a omezení pro testovací snahy pokryté tímto plánem. Roli zde můžou hrát dříve stanovené normy, požadavky v Politice testování a Strategii testování, což jsou dokumenty z předchozí úrovně testovací dokumentace, ale i smluvní požadavky, doba projektu, omezení nákladů a další faktory Zúčastněné strany - za pomoci seznamu uvádí zúčastněné strany a dále popisuje, jak probíhá komunikace s každou z těchto stran Komunikace testování - jde o popis způsobu komunikace mezi testováním, dalšími aktivitami životního cyklu a uvnitř organizace. Norma dále dovoluje znázornit tento způsob komunikace graficky, tedy za pomoci schématu nebo obrázku Registr rizik - uvádí rizika spojená s testováním pokrytá tímto plánem a dále poskytuje míru vystavení pro každé riziko včetně jeho dopadu a pravděpodobnosti. Poskytuje doporučení, jak s riziky zacházet a obdobně jako u jiných částí dokumentu, lze umístit pouze odkaz na samostatný registr rizik. Tato část dokumentu se dále dělí na: Produktová rizika Projektová rizika Strategie testování - stanovuje přístup k testování pro specifikovaný projekt testování nebo testovací podproces. Lze odkazovat na Strategii testování a uvést pouze odlišnosti Testovací aktivity a odhady - uvádí všechny potřebné testovací aktivity vycházející z testovacího procesu, který má být použit. Dále specifikuje odhady pro testovací aktivity, v případě potřeby popisuje přidělený rozpočet a odhad nákladů, popřípadě odkazuje na místo, kde jsou takové informace k nalezení Obsazování pracovních pozic - uvádí požadavky na obsazování pracovních pozic pro testování vystihující tento plán. Údaje o pracovních pozicích se dále dělí na části: Role, aktivity a odpovědnosti - norma rozlišuje dva typy zúčastněných lidí na projektu. Primární, ti kteří jsou vedoucími aktivit a sekundární, kteří vedoucí nejsou, ale poskytují podporu. V této části se i jednotlivým pracovníkům přidělují role a odpovědnosti. Navíc se stanoví, na jak dlouhé časové období je každá z osob vyžadována Potřeby najímaní zaměstnanců - zabývá se určením požadavků na dodatečný personál pro testování, stejně jako u předchozího bodu, je dále stanovena potřebná doba pro takový personál a jejich předpokládané dovednosti. Potřeby školení - shromažďuje informace týkající se potřeby školení v oblasti testování Časový plán - stanoví milníky testování definované v časovém plánu projektu a strategii testování, dále shrnuje celkový časový plán testovacích aktivit a identifikuje, které aktivity vyústí ve zpětnou vazbu pro vývojové, organizační a podpůrné procesy 13
14 Norma opět v příloze dodává dva typy příkladů, jak by měl takový dokument vypadat po vyplnění všech potřebných informací. Obrázek 6 je přímo příklad uváděný v příloze normy a znázorňuje plán testování pro nový předplatitelský systém z pohledu agilní korporace Obrázek 6 - Příklad dokumentu Plán testování (ISO, 2015) Dokumentace dynamických testovacích procesů Tato kapitola normy se zabývá dynamickým testováním. Tento druh testování se používá převážně při závěrečných fázích vývoje software, protože pro průběh testování vyžaduje běh aplikace, tj. aby existovala spustitelná verze aplikace. Definice dynamického testování Dynamické testování vyžaduje existenci spustitelné verze softwaru a probíhá hlavně na základě poskytování různých vstupů a posuzování výstupů testovaného programu. (Borovcová, 2008) Dokumenty v této části jsou rozděleny do třech množin. První množina obsahuje dokumenty, které se týkají Specifikace návrh testování, Specifikace testovacích případů, Specifikace postupů testování. Druhá množina obsahuje různé zprávy a protokoly. Třetí se zabývá požadavky na testovací data a prostředí. 14
15 Následující obrázek demonstruje rozložení množin v rámci celé struktury normy. Obrázek 7 - Úroveň dokumentace pro dynamické testování (ISO, 2015) Specifikace návrhu testování První dokument, který norma definuje během dynamického testování je dokument, který specifikuje návrh testování. Tento dokument definuje funkcionality, které bude mít například nová verze testované aplikace. Tento dokument také později slouží k tvorbě jednotlivých testovacích případů. Náležitosti dokumentu Pro tento dokument je nejdůležitější část ta, která popisuje a definuje právě nové funkcionality, která mají byt otestovány. Může se ale také jednat o celý business proces, který právě obsahuje jednotlivé funkce. Norma dále uvádí, že sady funkcí, které se mají otestovány, mohou být uvedeny například ve formě tabulky, seznamu anebo za použití nějakého specializovaného nástroje. Samozřejmosti je, že dokument obsahuje různé identifikátory a slovníčky pojmů apod. Následující příklad ukazuje, jak by mohla vypadat specifikace testovacích případů v agilní společnosti. Návrh testování 15
16 Máme následující témata: 1. Administrace 2. Nové a rozšířené předplatné 3. Obecný přístup na internetové stránky 4. Stížnosti Pro testování pro účely prezentace by scénáře měly být seřazeny podle témat. Testovací podmínky na zadní straně kartiček se scénáři, které popisují akceptační kritéria scénářů, by měly být pokryty. Verze: 1 (Ursula) Tabulka 1 - Příklad dokumentu pro evidenci nových funkcionalit (ISO, 2015) Kdybychom se chtěli podívat na ten samý dokument v nějaké korporaci, dokument by obsahovat mnohem více údajů a snažil by se popsat veškeré možné detaily, které s novými funkcemi souvisí, ať už se jedná o testovací data, prostředí nebo důležité podmínky pro testování nových funkcí. Specifikace testovacích případů Tato část normy definuje podobu testovacích případů. Ve své podstatě se jedná o pokrytí položek, které je nutné otestovat. Předchozí dokument definoval nové funkce a tyto funkce se mohou skládat z více činností, nebo jak definuje norma položek, které je nutné otestovat. Položky pokrytí testování jsou odvozeny aplikováním techniky návrhu testování na testovací podmínku. Náležitosti dokumentu Pro tento dokument platí jako pro předešlí, že musí obsahovat jednotlivé identifikátory a další nezbytné náležitosti. Vedlo toho, by však měl obsahovat také informace, které jsou nezbytné pro vytvoření správných testovacích případů. Testovací případy by měli pokrývat všechny položky pokrytí testování. Slovní spojení položky pokrytí testování mohou byt pro čtenáře značně matoucí nebo nejednoznačné. Proto bych uvedl příklad, jak si lze položky pokrytí testování představit. Příklad: Máme novou funkcionalitu v naší aplikaci, která umožňuje zákazníkovy se vytvořit vlastní objednávku. Nicméně tato funkcionalita je poměrně komplikovaná a rozsáhlá aby mohla tvořit jeden testovací případ. Proto je právě nutné správně identifikovat položky pokrytí testování. V tomto případě to může být například, že klient se přihlásí do aplikace a vybere jednotlivé zboží a vyplní potřebné údaje. A tato jedná činnost je právě jedna položka pokrytí testování. 16
17 Na následujícím obrázku bude uveden příklad toho, jak může vypadat dokument, který specifikuje jednotlivé testovací případy. Jedná se příklad, který by mohla používat nějaká větší společnost nebo korporát, který využívá tradiční rigorózní metodiky. ID testovacího případu: 17 4 Priorita: Np Sledovatelnost : (FS2).5.2.b Účel: otestovat reakci na hodnotu vzorku, která je na horní hranici platného vzorku. Vstupní podmínky: Vstup: Očekávaný výsledek: Přístroj musí být připraven na analýzu vzorků. Vzorek NCS, který má hodnotu 315, musí být připraven. Vložte vzorek a spusťte analýzu. Na displeji se zobrazí Varování Tabulka 2 - Příklad návrh testovacího případu (ISO, 2015) Specifikace postupů testování Další částí dokumentu definuje podobu toho, jak budou jednotlivé testovací případy vypadat. V přechozích částech normy se definovali jednotlivé testovací případy a v této části se norma stará o to, jaké náležitosti by měli testovací případy splňovat. Jedná se například o různé činnosti a nastavení, které mohou být vyžadovány k nastavení iniciálních vstupních podmínek a jakýchkoliv závěrečných aktivit následujících po provedení testování. Náležitosti dokumentu To jak by měl vypadat testovací případ, řeší norma poměrně stručně. Dokument by měl jako každý obsahovat nějaké formální náležitosti, jako je sledování změn nebo schvalovací autorita. Dokument by tedy měl byt opět veden ve formě nějaké tabulky, seznamu nebo ve specializovaném nástroji. Tato část normy se také zaměřuje na to, jak by měli být testovací případy sestavovány, tak aby reflektovaly sady funkcí, které je potřeba otestovat. Norma se také okrajově zmiňuje, že je možné používat pro lepší orientaci při provádění testovacích případu symboly, které značí například to, jestli krok v testovací případu proběhl správě nebo špatně. Níže uvedený obrázek přestavuje možnou podobu toho, jak by mohl vypadat postup provádění testovacího případu podle normy. Tuto podobu do jisté míry používají i nástroje pro testování softwaru. 17
18 ID testovacíh o postupu Cíl a priorita Odhadovaná doba trvání: I-3 Účelem tohoto postupu testování je otestovat způsob, jakým systém zachází s definovanými měřícími rozsahy pro NCS. Priorita: Np Uvedení do provozu: Připravte přístroj na analýzu vzorků. Umístěte vzorky NCS s následujícími hodnotami do otočné části: 1) Hodnota 1 2) Hodnota 2 3) Hodnota 56 4) Hodnota 315 5) Hodnota 316 Vztah k ostatním postupům: Žádný Protokol testování Datum: Iniciály: Testovaná položka: Ok / Ne OK Komentáře: Postup Krok č. Testov ací případ Aktivity Prohlídka výsledku Skutečné výsledky Výsledek testování 1 Spusťte analýzu vzorků. Vyčkejte, až je analyzován první vzorek Zkontrolujte, že displej ukazuje Neplatný vzorek. 18
19 2 Vyčkejte, až je analyzován druhý vzorek Zkontrolujte, že je vzorek analyzován. 3 Vyčkejte, až je analyzován třetí vzorek Zkontrolujte, že je vzorek analyzován. 4 Vyčkejte, až je analyzován čtvrtý vzorek Zkontrolujte, že je vzorek analyzován. 5 Vyčkejte, až je analyzován pátý vzorek Zkontrolujte, že displej ukazuje Neplatný vzorek. Zastavení a dokončení: Vypněte přístroj, odstraňte vzorky a ukliďte cokoliv rozlitého. Tabulka 3 - Příklad průběhu testovacího případu (ISO, 2015) Požadavky na testovací data Následující dvě kapitoly popisují to, jak by měli být vedeny a znázorněny požadavky v rámci testování softwaru. Tato kapitola se zabývá požadavky na testovací data. Je samozřejmé, že v drtivé většině případu jsou potřeba určitá data k provádění testů. Proto, jaká data by měla být používaná, se specifikuje právě v této části. Náležitosti dokumentu Tento druh dokumenty by měl především obsahovat přesně definované požadavky na testovací data. Většinou se jedná buď o informace, jaká data z databáze se mají používat, nebo například jestli se testy budou provádět na testovacích datech nebo na skutečných 19
20 produkčních datech. Dále se mohou uvádět různá schémata databázových tabulek a diagramy tříd. Norma uvádí, že například v agilní firmě mohou požadavky na testovací data vypadat následovně. Modifikovaná sada živých dat musí být naplněna, ale data nesmí obsahovat důležitá data zákazníků typu: kreditní karta, adresa nebo telefonní číslo. Tato data budou pročištěna testovacím týmem a zákazníkem při uvedení projektu do provozu. Testování bude prováděno na datech použitých během iterací. Požadavky na testovací prostředí Druhou části, která se věnuje požadavkům, jsou požadavky na testovací prostředí. Požadavky na testovací prostředí popisují vlastnosti testovacího prostředí potřebného k provedení postupů testování definovaných ve Specifikaci postupů testování. Náležitosti dokumentu Tato část normy Identifikuje položky prostředí vyžadované k provádění testování definovaných ve Specifikaci postupů testování. To především zahrnuje nastavení před prováděním testování, hardwaru, middlewaru a různých softwarových požadavků potřebných pro testování. Příklad toho jak by mohlo vypadat dokument, který definuje požadavky na testovací prostředí ve společnosti, která aplikuje rigorózní metodiky, by mohl vypadat následovně. Datum vydání a stav Požadavky na testovací prostředí Verze Datum Autoři Posuzovatelé Stav února 2008 Tým testerů Tradiční Vedoucí testování Tradiční, Manažer testování Tradiční, Manažer bezpečnosti Tradiční, Návrh Administrátor testování Tradiční Tabulka 4 - Příklad požadavku na testovací prostřední (ISO, 2015) 1. Hardware Na testování jsou zapotřebí tři počítače s MS Windows. Administrátor testování je odpovědný za získání a konfiguraci těchto počítačů. Tyto počítače budou potřeba od 15. března 2008 a budou používány po dva týdny. 2. Software Na tyto tři počítače s MS Windows je třeba nainstalovat operační systém MS Windows XP. Všechny záplaty a aktualizace pro tyto počítače musí být aktuální. Administrátor 20
21 testování je odpovědný za získání a nainstalování softwaru. Kompletně nainstalovaný software na každém počítači musí být připraven do 15. března, Bezpečnost Bezpečnostní kontroly jsou uvedeny v Protokolu korporátní bezpečnosti. Manažer bezpečnosti a Vedoucí testování jsou odpovědni za bezpečnostní kontroly. 4. Nástroje Viz Plán testování pro příslušné nástroje testování. Zpráva o připravenosti testovacích data a prostředí Tato část normy se věnuje vytváření zpráv, které informují o tom, v jakém stavu se nacházejí požadavky na testovací data a prostředí v předchozích kapitolách. Udávají, jestli jsou splněny všechny požadavky, nebo jenom část. Samozřejmostí je, že zprávy a připravenosti obsahují jednoznačné identifikátory a další nezbytné náležitosti. Pro příklad uvedu zprávu o připravenosti testovacích dat ve velké společnosti aplikující rigorózní metodiky. Zpráva o připravenosti testovacích dat Shrnutí: Testovací data nejsou připravena. Migrace dat do testovacího prostředí bude dokončena do 22. března Stav testovacích dat: Následující tabulka zobrazuje stav každého požadavku na testovací data. Požadavek Stav Komentáře DBR1 Zpožděno Z důvodu údržby databáze bude migrace dat do testovacího prostředí dokončena do 22. března DBRn DBRn+1 Připraveno Připraveno Tabulka 5 - Příklad zprávy o připravenosti testovacích dat (ISO, 2015) 21
22 Omezení: Po dokončení bude databáze obnovena. Databáze je připravena specificky pro toto testování a po testování budou data obsahovat omezení a uchovávat stavy systému, které vyžadují obnovení. Závěry a doporučení: Testovací data nejsou připravena. Jak bylo uvedeno výše, data budou připravena 22. března Skutečné výsledky a Výsledek testování Tyto dva dokumenty informují o tom, jak dopadli jednotlivé testovací případy. Rozdíl spočívá v tom, že Skutečné výsledky testování ukazují, jak dopadli jednotlivé kroky, které byli vytvořeny ve Specifikaci postupů testování, obvykle nějaký symbolem, který ilustruje selhání nebo úspěch kroku v testovacím případu. Oproti tomu Výsledek testování za zaměřuje na to, jak dopadl celý testovací případ. Protože testovací případ se většinou skládá z více testovacích kroků, a právě to jak dopadly. Skutečné výsledky ovlivňuje to, jak bude vypadat Výsledek testování. Obrázek níže přestavuje Skutečné výsledky, tj. jak dopadli jednotlivé kroky v testovacím případě. Nicméně když jsem studoval jednotlivé příklady těchto dvou dokumentů, přišlo mi, že příklady dokumentů přesně nereflektují definici těchto dokumentů. Nejdřív se použilo slovo OK a později symbol. Což je podle mě matoucí. ID postupu testování Cíl a priorita Odhadovaná doba trvání: I-3 Účelem tohoto postupu testování je otestovat způsob, jakým systém zachází s definovanými měřícími rozsahy pro NCS. Priorita: Np Uvedení do provozu: Připravte přístroj na analýzu vzorků. Umístěte vzorky NCS s následujícími hodnotami do otočné části: 1) Hodnota 1 2) Hodnota 2 3) Hodnota 56 4) Hodnota 315 5) Hodnota 316 Vztah k ostatním postupům: Žádný Protokol testování Datum: Iniciály: Testovaná položka: Ok / Ne OK 29. dubna 2011 AMJ Komponenta MSR-ub V.2.3 Komentáře: Postup 22
23 Krok č. Testovac í případ Krok č. Testovací případ Krok č. Testovací případ Krok č. Testovací případ Krok č. Testovací případ 1 Spusťte analýzu vzorků. Vyčkejte, až je analyzován první vzorek Zkontrolujte, že displej ukazuje Neplatný vzorek. Zobrazuje Neplatný vzorek OK Tabulka 6 - Příklad Skutečných výsledků (ISO, 2015) Protokol o provádění testování Tento druh dokumentu uchovává a znamenává události, které nastali během testování. Samozřejmostí jsou formální náležitosti, které jsou povinné pro všechny dokumenty této normy. Jako příklad norma uvádí protokol, která je veden jako tabulka, která zaznamenává události nastalé během testování. Obrázek 8- Příklad protokolu o provedeném testování (ISO, 2015) 23
24 Podávání zpráv o incidentech testování Posledním dokumentem, který se věnuje dynamickému testování, je dokument o Podávání zpráv o incidentech testování. Je jasné, že během testování softwaru se nacházejí chyby. Proto je nezbytné zaznamenávat tyto chyby, nebo jak uvádí norma incidenty, a vést dostatečné informace o incidentech, které později poslouží k nápravě chyby. Toto nezbytně vede ke zvýšení celkové kvality testovaného softwaru. Náležitosti dokumentu Pro tento typ dokumentu je důležité, aby o vzniklých incidentech vedl co možná nejpodstatnější informace. Proto norma definuje určité parametry incidentu, které je nutné zaznamenávat. Jedná se například o popis incidentu, závažnost, které je sním spojena, odkaz na testovací případ nebo symbol nebo popis v jaké stavu se incident nachází, jestli už se jím například vývojáři zabývají, nebo stále čeká na vyřešení. Obrázek níže přestavuje to, jak by mohl tento dokument vypadat v projektu, který implementuje rigorózní metodiky. Formulář registrace incidentu Číslo 278 Krátký název Informace zkráceny Softwarový produkt Projekt PC část produktu UV/TIT-14 33a Verze (n.m) 5.2 Stav = Vytvořený Registraci vytvořil Heather Small Datum & čas 14. května Odchylku pozoroval Heather Small Datum & čas 14. května Úplný popis Text v poli Shrnutí je po 54 znacích ořezán; měl by být schopen zobrazit 75 znaků. 24
25 Pozorováno během Procházení / Revize / Inspekce / Programování & Sestava / Testování / Používání Pozorováno v Požadavek / Návrh / Implementace / Testování / Provoz Příznak Selhání operačního systému / Program neodpovídá / Selhání programu / Vstup / Výstup / Celkové selhání produktu / Systémová chyba / Jiné: Vliv uživatele na Vysoký / Střední / Nízký Uživatelská naléhavost Akutní / Vysoká / Střední / Nízká / Žádná Tabulka 7 - Příklad hlášení o incidentu (ISO, 20152) Zpráva o stavu testování Jak vyplývá z průřezu části normy, veškerá prováděná testování, včetně dynamického, končí zprávou o stavu testování. Jedná se o dokument, který poskytuje informace o stavu testování ve specifickém vykazovaném období. Dokonce i sama norma uvádí, že jedná - li se o agilní projekt, není třeba, aby se jednalo o psaný dokument, nýbrž stačí diskuze na toto téma na iteračních poradách. Kromě nutných informací shodných pro všechny dokument zmíněné v normě, obsahuje tento dokument pouze jednu část nazvanou Stav testování, která se dále dělí na: Vykazované období - slouží k určení časového období pokrytého zprávami o dané činnosti Postup vzhledem k plánu testování - obecný popis postupu, s přihlédnutím k Plánu testování a upozornění na významné odchylky od plánu, s vysvětlením důvodů, popisem nápravných opatření, zprávě o následcích a zvážením dopadů na plánované projektové cíle Faktory bránící postupu - v této části je prostor pro zmínění faktorů, které bránily postupu během vykazovaného období. Obsahuje také odpovídající řešení, která byla implementována za účelem odstranění takových faktorů. Nevyřešené problémy, dále bránící postupu, by měly být zaevidovány a postupně navržena řešení vedoucí k jejich odstranění Měření testování - obsahuje zkompletovaná měření vzhledem ke konci vykazovacího období 25
26 Nová a změněná rizika - uvádí jak seznam nových rizik, tak i těch která byla identifikována jako výsledek monitorování a kontroly testování. Zabývá se i změnou těchto rizik během vykazovacího období Plánované testování - jedná se čistě o popis testování naplánovaných na další vykazovací období Obrázek 9 dokládá, jak si norma, respektive její tvůrci představují, že by taková Zpráva o stavu testování měla či mohla vypadat Obrázek 9 - Příklad dokumentu Zpráva o stavu testování (ISO, 2015) Zpráva o dokončení testování Úplně posledním dokumentem z hierarchie celé normy, který vzniká při testování, je Zpráva o dokončení testování. Tento dokument poskytuje přehled o prováděném testování. Může se jednat o projekt/program jako celek nebo o konkrétní testovací podprocesy. Opět oproti nutným prvkům každého dokumentu obsahuje pouze část Provedené testování, dále se rozpadající na: Přehled provedeného testování - shrnuje provedené testování, poskytuje informace o tom, co se testovalo, a dále zda existovala nějaká omezení při provádění testování Odchylky od plánovaného testování - existují - li nějaké odchylky od plánovaného testování, je jejich popis uveden právě v této sekci Vyhodnocení dokončení testování - zabývá se odpovědí na otázku do jaké míry testování splnilo předpoklady a zda vyhovělo specifikovaným kritériím Faktory, které bránily postupu - viz předchozí zpráva Měření testování Zbytková rizika - uvádí neošetřená rizika, dále setrvající Doručitelné výstupy testování - uvádí výsledky testovacího úsilí a jejich umístění Znovupoužitelná aktiva testování - popis znovupoužitelných aktiv včetně jejich umístění, norma dále údává, že by se mohlo jednat například o testovací data Ponaučení - popisuje výsledky porady nad souhrnem ponaučení 26
27 Obrázek 10 - Příklad dokumentu Zpráva o dokončení systémového testování (ISO, 2015) Obrázek 10 dokládá představu tvůrců normy, jak přibližně by Zpráva o dokončení měla vypadat a co obsahovat. 27
28 Závěr Tato práce se zaměřila na normu ISO SO/IEC/IEEE :2013 Software and systems engineering -- Software testing -- Part 3: Test documentation, která se věnuje dokumentaci testování softwaru. Ovšem celá práce vycházela z českého překladu této normy. Slabinou tohoto překladu je občasné lehce matoucí použití termínů a pojmů. Celkově jsou ale dokumenty charakterizovány zdařile. Musím také vyzdvihnout fakt, že u každého typu dokumentu je uveden konkrétní příklad a to jak při použití v agilní, tak i ve firmě která praktikuje rigorózní metodiky. Jako člověk, který má určité zkušenosti s testováním softwaru, musím konstatovat, že většina dokumentů opravdu přestavuje best practices daného oboru a z některými dokumenty se setkávám i v praxi. Nicméně najdou se i části, které podle mě jsou matoucí. Jako v případě dokumentů Skutečné výsledky a výsledky testování. Norma jako celek podle mě splňuje svůj účel a myslím si, že bude užitečnou pomůckou při testování softwaru. 28
29 Zdroje ISO/IEC/IEEE ISO/IEC/IEEE :2013: Software and systems engineering -- Software testing -- Part 3: Test documentation. [online]. [cit ]. Dostupné z: (Borovcová, 2008) Testování webových aplikací: Část II: Základy testování. Testování softwaru [online] [cit ]. Dostupné z: XMUrK_hQLNmIyNWRjZjgtMWIzYy00M2EyLTk0ZGMtYjlkM2Q3ZjZiMDk0/edit?authkey=CIXp zykb 29
ISO/IEC/IEEE zavedena v ČSN ISO/IEC/IEEE ( ) Softwarové a systémové inženýrství Testování softwaru Část 1: Koncepty a definice
ČESKÁ TECHNICKÁ NORMA ICS 35.080 Listopad 2015 Softwarové a systémové inženýrství Testování softwaru Část 3: Dokumentace testování ČSN ISO/IEC/IEEE 29119-3 36 9002 Software and systems engineering Software
Semestrální práce z předmětu 4IT421 Téma: CMMI-DEV v.1.3 PA Project Monitoring and Control
VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE náměstí W. Churchilla 4, 130 67 Praha3 Semestrální práce z předmětu 4IT421 Téma: CMMI-DEV v.1.3 PA Project Monitoring and Control Jméno a příjmení: Michal Hendrich Školní
Metodika analýzy. Příloha č. 1
Metodika analýzy Příloha č. 1 Příloha č. 1 1 Účel dokumentu Dokument popisuje závaznou metodiku systémové analýzy, je upraven na míru pro prostředí Podniku. Dokument je provázán s Podnikovou analýzou,
ISO/IEC/IEEE zavedena v ČSN ISO/IEC/IEEE ( ) Softwarové a systémové inženýrství Testování softwaru Část 1: Koncepty a definice
ČESKÁ TECHNICKÁ NORMA ICS 35.080 Listopad 2015 Softwarové a systémové inženýrství Testování softwaru Část 2: Testovací procesy ČSN ISO/IEC/IEEE 29119-2 36 9002 Software and systems engineering Software
Zkouška ITIL Foundation
Zkouška ITIL Foundation Sample Paper A, version 5.1 Výběr z více možností Pokyny 1. Měli byste se pokusit odpovědět na všech 40 otázek. 2. Všechny svoje odpovědi vyznačte na samostatný formulář, který
Představení projektu Metodika
Představení projektu Metodika přípravy veřejných strategií Strategické plánování a řízení v obcích metody, zkušenosti, spolupráce Tematická sekce Národní sítě Zdravých měst Praha, 10. května 2012 Obsah
ČESKÁ TECHNICKÁ NORMA
ČESKÁ TECHNICKÁ NORMA ICS 35.020; 35.040 2008 Systém managementu bezpečnosti informací - Směrnice pro management rizik bezpečnosti informací ČSN 36 9790 Červen idt BS 7799-3:2006 Information Security Management
MANAGEMENT KYBERNETICKÉ BEZPEČNOSTI
MANAGEMENT KYBERNETICKÉ BEZPEČNOSTI TÉMA Č. 4 ISO NORMY RODINY 27K pplk. Ing. Petr HRŮZA, Ph.D. Univerzita obrany, Fakulta ekonomiky a managementu Katedra vojenského managementu a taktiky E-mail.: petr.hruza@unob.cz
Návod k požadavkům ISO 9001:2015 na dokumentované informace
International Organization for Standardization BIBC II, Chemin de Blandonnet 8, CP 401, 1214 Vernier, Geneva, Switzerland Tel: +41 22 749 01 11, Web: www.iso.org Návod k požadavkům ISO 9001:2015 na dokumentované
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í
Jak vytvořit správné Zadání IS
Jak vytvořit správné Zadání IS 26. dubna 2013 Jiří Svačina Jiří Svačina Unicorn Systems, Senior Consultant Unicorn, 1993 Vývoj Softwarová architektura Projektové řízení Business analýza Univerzita Hradec
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é
Obsah. Zpracoval:
Zpracoval: houzvjir@fel.cvut.cz 03. Modelem řízený vývoj. Doménový (business), konceptuální (analytický) a logický (návrhový) model. Vize projektu. (A7B36SIN) Obsah Modelem řízený vývoj... 2 Cíl MDD, proč
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é
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
Evidence požadavků uživatelů bytů a nebytových prostor
Evidence požadavků uživatelů bytů a nebytových prostor Úvod Pro zjednodušení a zprůhlednění Vaší komunikace se správní firmou (dále jen SF ), která má na starost objekt, v němž se nachází bytový či nebytový
Bc. Martin Majer, AiP Beroun s.r.o.
REGISTR DIGITALIZACE HISTORICKÝCH FONDŮ (RDHF) A DIGITÁLNÍCH KONKORDANCÍ (DK) Návrh uživatelského rozhraní klientských aplikací verze 1.0 Bc. Martin Majer, AiP Beroun s.r.o. 28.11.2016-1 - Obsah 1 Seznam
Stanovit nezbytná pravidla pro tvorbu dokumentace vytvářenou ve SITRONICS centru využitelnou firmou SITRONICS TS.
Tvorba dokumentace SITRONICS centrum 1. Cíl Usnadnit tvorbu jednotné dokumentace SITRONICS centra. 2. Účel Stanovit nezbytná pravidla pro tvorbu dokumentace vytvářenou ve SITRONICS centru využitelnou firmou
Vzdálená správa v cloudu až pro 250 počítačů
Vzdálená správa v cloudu až pro 250 počítačů S pomocí ESET Cloud Administratoru můžete řídit zabezpečení vaší podnikové sítě bez nutnosti nákupu, instalace nebo údržby dalšího hardwaru. Řešení je poskytováno
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é
10. setkání interních auditorů v oblasti průmyslu
10. setkání interních auditorů v oblasti průmyslu Současné výzvy IT interního auditu 7. Března 2014 Obsah Kontakt: Strana KPMG průzkum stavu interního auditu IT 2 Klíčové výzvy interního auditu IT 3 KPMG
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í?
Fyzická bezpečnost, organizační opatření. RNDr. Igor Čermák, CSc.
Fyzická bezpečnost, organizační opatření RNDr. Igor Čermák, CSc. Katedra počítačových systémů Fakulta informačních technologií České vysoké učení technické v Praze Igor Čermák, 2011 Informační bezpečnost,
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
Implementace systému ISMS
Implementace systému ISMS Krok 1 Stanovení rozsahu a hranic ISMS Rozsah ISMS Krok 2 Definice politiky ISMS Politika ISMS Krok 3 Definice přístupu k hodnocení rizik Dokumentovaný přístup k hodnocení rizik
Expresní analýza PLM. jako efektivní start implementace PLM. www.technodat.cz. jindrich.vitu@technodat.cz
jako efektivní start implementace PLM www.technodat.cz jindrich.vitu@technodat.cz 1 úvod: definice, cíl a výstup analýzy 2 etapy expresní analýzy PLM 3 sběr dat a podkladů a jejich analýza 4 dokument Expresní
Komunikační strategie a plán rozvoje portálu portal.gov.cz
Příloha č. 2 Výzvy - Detailní popis předmětu VZ Komunikační strategie a plán rozvoje portálu portal.gov.cz V rámci dodávky vznikne dokument s analýzou současného stavu Portálu veřejné správy (PVS), určením
UŽIVATELSKÁ PŘÍRUČKA K INTERNETOVÉ VERZI REGISTRU SČÍTACÍCH OBVODŮ A BUDOV (irso 4.x) VERZE 1.0
UŽIVATELSKÁ PŘÍRUČKA K INTERNETOVÉ VERZI REGISTRU SČÍTACÍCH OBVODŮ A BUDOV (irso 4.x) VERZE 1.0 OBSAH 1 ÚVOD... 3 1.1 HOME STRÁNKA... 3 1.2 INFORMACE O GENEROVANÉ STRÁNCE... 4 2 VYHLEDÁVÁNÍ V ÚZEMÍ...
komplexní podpora zvyšování výkonnosti strana 1 Využití Referenčního modelu integrovaného systému řízení veřejnoprávní korporace Město Hořovice
strana 1 Využití Referenčního modelu integrovaného systému řízení veřejnoprávní korporace Město Hořovice 19.3.2018 Zpracoval: Roman Fišer, strana 2 1. ÚVOD... 3 2. POPIS REFERENČNÍHO MODELU INTEGROVANÉHO
ČESKÁ TECHNICKÁ NORMA
ČESKÁ TECHNICKÁ NORMA ICS 35.040 Červenec 2009 Informační technologie Bezpečnostní techniky Řízení rizik bezpečnosti informací ČSN ISO/IEC 27005 36 9790 Information technology Security techniques Information
Praha 15.3.2011 PROJECT INSTINCT
ROZHRANÍ VÝSLEDKOVÉHO IS PRO SYSTÉM CZECH TRIATHLON SERIES Equica, a.s. Praha 15.3.2011 PROJECT INSTINCT Obsah 1. Úvodní informace... 3 1.1. Identifikace dokumentu... 3 1.2. Prohlášení certifikačního střediska
Softwarová podpora v procesním řízení
Softwarová podpora v procesním řízení Zkušenosti z praxe využití software ATTIS Ostrava, 7. října 2010 www.attis.cz ATTN Consulting s.r.o. 1 Obsah Koncepce řízení výkonnosti Koncepce řízení výkonnosti
Management rizika Bc. Ing. Karina Mužáková, Ph.D. BIVŠ,
Management rizika Bc. Ing. Karina Mužáková, Ph.D. BIVŠ, 2015 1 5/ Řízení rizika na úrovni projektu, podniku a v rámci corporate governance. BIVŠ, 2015 2 Definice projektu říká, že se jedná o činnost, která
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
Státní pokladna. Centrum sdílených služeb
Státní pokladna Centrum sdílených služeb Státní pokladna Centrum sdílených služeb Organizační dopady při řešení kybernetické bezpečnosti Ing. Zdeněk Seeman, CISA, CISM Obsah prezentace Podrobnější pohled
Vazba na Cobit 5
Vazba na Cobit 5 Hlavní cíle návodu Návod na to, jak užívat rámec Cobit 5 pro podporu a organizaci auditu/ujištění Strukturovaný přístup pro realizaci auditu podle jednotlivých enablers definovaných v
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
Protokol o atestačním řízení
Atestační středisko: ADA, s. r. o. pověření k výkonu atestací ÚVIS reg. č. 3 rozhodnutím č. j. 3/2001 A ze dne 11.10.2001, se sídlem Čermákova 28, 625 00 Brno adresa pro poštovní styk Sokolská 725, 664
ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE
ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Č.j.: 3/12/51924/Moos PŘÍKAZ REKTORA č. 1/2012 Pravidla pro kompetence a odpovědnosti při správě informačního systému ČVUT Pravidla pro kompetence a odpovědnosti při
Program pro tvorbu technických výpočtů. VIKLAN - Výpočty. Uživatelská příručka. pro seznámení se základními možnostmi programu. Ing.
Program pro tvorbu technických výpočtů VIKLAN - Výpočty Uživatelská příručka pro seznámení se základními možnostmi programu Ing. Josef Spilka VIKLAN - Výpočty Verse 1.10.5.1 Copyright 2010 Ing. Josef Spilka.
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
Interim Project. Pravidla spolupráce pro Interim Project. platná k
Interim Project Pravidla spolupráce pro Interim Project platná k 1. 6. 2015 1 Úvodní ustanovení 1.1 Interim Project Interim Project je platforma na rozhraní akademické a byznys sféry s cílem vytvářet,
Procesní dokumentace Process Management. Pavel Čejka
Procesní dokumentace Process Management Pavel Čejka SAP Solution Manager 7.2 SAP Solution Manager 7.2 nabízí dramatické zlepšení možností dokumentace Solution dokumentace Jednotné webové prostředí Integrovaný
Michal Oškera (50854)
PV098 - Řízení SW projektů semestrální práce Michal Oškera (50854) 19. listopadu 2003 Obsah 1 Úvod 2 2 Plán projektu 3 2.1 Plán CO.............................. 3 2.2 Plán JAK.............................
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
Závěrečná zpráva o výsledcích řešení projektu v rámci rozvojových program MŠMT na rok 2006
Závěrečná zpráva o výsledcích řešení projektu v rámci rozvojových program MŠMT na rok 2006 Fakulta/Ústav: Název projektu: Aplikace novely zákona o veřejných zakázkách do informačního systému VVŠ Číslo
Seznam zkratek PRVNÍ ČÁST. Lidské dovednosti a technické nástroje 1 Úvod k první části 3
Seznam zkratek xi PRVNÍ ČÁST Lidské dovednosti a technické nástroje 1 Úvod k první části 3 Co je to projektové řízení? 3 Proč projektové řízení? 4 Požadavky na technické dovednosti 4 Požadavky na umění
Specifikace softwarového projektu
Specifikace softwarového projektu Objednávkový systém pro lékařská zařízení Jméno projektu: KaNIS (Kliniky a Nemocnice Informační Systém) Předpokládaný vedoucí: RNDr. Michal Kopecký, Ph.D. Předpokládaný
Návod Skupiny pro auditování ISO 9001 (ISO 9001 Auditing Practices Group APG) k:
13. ledna 2016 Návod Skupiny pro auditování ISO 9001 (ISO 9001 Auditing Practices Group APG) k: Zprávy z auditu Úvod Kapitola 1 ISO 9001 říká, že má organizace implementovat QMS v případě, že potřebuje
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
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
1. VYMEZENÍ ODBORNÉ STÁŽE
1. VYMEZENÍ ODBORNÉ STÁŽE Šablona stáže představuje základní rámec odborné stáže pro typovou pozici a obsahuje požadavky na obsah a průběh stáže, na stážistu i na poskytovatele stáže. Bílá pole označují
Uživatelská příručka pro ředitele škol
Národní šetření výsledků žáků v počátečním vzdělávání Uživatelská příručka pro ředitele škol Název souboru: Modul IDM - Uživatelská příručka pro ředitele škol V2.doc Strana 1 Obsah 1 Úvod... 3 2 Přihlášení
Projekt: Koordinační centrum pro zavádění e-gov v územní veřejné správě. Koncepční dokument pro oblast řízení. Procesní model
Koncepční dokument pro oblast řízení a koordinaci e-gov: Procesní model 18. 09. 2013 OBSAH Obsah... 2 Seznam zkratek... 3 Použité pojmy... 4 1 Úvodní informace... 6 2 Procesní model: životní cyklus e-gov...
Jednotný NIS Prezentace k zahájení projektu pro Radu kraje Vysočina. Projektový manažer - Ing. Ivan Sokolov, Ph.D.
Prezentace k zahájení projektu pro Radu kraje Vysočina Projektový manažer - Ing. Ivan Sokolov, Ph.D. Obsah Úvod Cíle projektu Rozsah projektu Projektové řízení základní východiska Základní organizační
Přístupy k řešení a zavádění spisové služby
Přístupy k řešení a zavádění spisové služby Miroslav Kunt Praha, 22. 3. 2016 Výběr SSl důležité okolnosti Je potřeba zájem vedení organizace, kompetentní pracovníci spisové služby, co největší přiblížení
ČSN ISO/IEC 27001:2014 a zákon o kybernetické bezpečnosti
ČSN ISO/IEC 27001:2014 a zákon o kybernetické bezpečnosti Ing. Daniel Kardoš, Ph.D 4.11.2014 ČSN ISO/IEC 27001:2006 ČSN ISO/IEC 27001:2014 Poznámka 0 Úvod 1 Předmět normy 2 Normativní odkazy 3 Termíny
B3 Vazba strategie byznys
Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace B3 Vazba strategie byznys Toto téma vysvětluje vzájemný vztah mezi tzv. byznysem organizace (hlavním
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
Technik pro řízení kvality a hygieny v potravinářství (kód: M)
Technik pro řízení kvality a hygieny v potravinářství (kód: 29-041- M) Autorizující orgán: Ministerstvo zemědělství Skupina oborů: Potravinářství a potravinářská chemie (kód: 29) Týká se povolání: Technik
kapitola 2 předprojektová fáze 31
OBSAH 6 projektové řízení Předmluva 3 Kapitola 1 Základní pojmy a východiska 13 1.1 Úvod do řízení projektů 14 1.1.1 Co je to projektové řízení 14 1.2 Základní pojmy projektového řízení 17 1.2.1 Projekt
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
ISO 9000, 20000, Informační management VIKMA07 Mgr. Jan Matula, PhD. III. blok
ISO 9000, 20000, 27000 Informační management VIKMA07 Mgr. Jan Matula, PhD. jan.matula@fpf.slu.cz III. blok ITSM & Security management standard ISO 9000-1 ISO 9000:2015 Quality management systems Fundamentals
XD39NUR Semestrální práce Zimní semestr 2013/2014
XD39NUR Semestrální práce Zimní semestr 2013/2014 Kamil Darebný darebkam@fel.cvut.cz Obsah Zadání... 1 Deliverable D4... 2 Vytvoření prototypu... 2 Použité technologie... 2 Popis prototypu... 2 Screenshoty
Dokumentace pro plánování a realizaci managementu jakosti dle požadavků
Dokumentace pro plánování a realizaci managementu jakosti dle požadavků Požadavek norem ISO 9001 ISO/TS 16949 : 4.2 na dokumentaci Dokumentace systému managementu jakosti musí zahrnovat: a) dokumentované
DOKUMENTACE K ŽÁDOSTI
1 KAPITOLA IV + PŘÍLOHA I DOKUMENTACE K ŽÁDOSTI MUDr. Alena Trunečková Oddělení klinického hodnocení 2 Článek 25 Údaje předložené v dokumentaci k žádosti Článek 26 Jazykové požadavky Příloha I Dokumentace
Primární klíč, cizí klíč, referenční integrita, pravidla normalizace, relace
Téma 2.2 Primární klíč, cizí klíč, referenční integrita, pravidla normalizace, relace Obecný postup: Každá tabulka databáze by měla obsahovat pole (případně sadu polí), které jednoznačně identifikuje každý
2. setkání interních auditorů ze zdravotních pojišťoven
2. setkání interních auditorů ze zdravotních pojišťoven Současné výzvy IT interního auditu 20. června 2014 Obsah Kontakt: Strana KPMG průzkum stavu interního auditu IT 2 Klíčové výzvy interního auditu
VYUŽITÍ HELPDESKOVÉHO INFORMAČNÍHO SYSTÉMU PŘI ROZVOJI A ZÁKAZNICKÉ PODPOŘE KNIHOVNÍHO SYSTÉMU
VYUŽITÍ HELPDESKOVÉHO INFORMAČNÍHO SYSTÉMU PŘI ROZVOJI A ZÁKAZNICKÉ PODPOŘE KNIHOVNÍHO SYSTÉMU Šárka Frantová, SEFIRA spol. s r. o. Úvod Zprovozněním systému a odjezdem dodavatele od zákazníka komunikace
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ů
Aplikace Elektronická podání Transakční část portálu veřejné správy
Aplikace Elektronická podání Transakční část portálu veřejné správy Vysvětlení pojmů Obsah Občan 3 Organizace 3 Zástupce 3 Uživatel 3 4 Zastupování 5 Služba 6 Transakce 6 Vlastník služby 6 Registrace 6
Zdravotnické laboratoře. MUDr. Marcela Šimečková
Zdravotnické laboratoře MUDr. Marcela Šimečková Český institut pro akreditaci o.p.s. 14.2.2006 Obsah sdělení Zásady uvedené v ISO/TR 22869- připravené technickou komisí ISO/TC 212 Procesní uspořádání normy
Specifikace předmětu plnění Datová tržiště
Příloha 1 Specifikace předmětu plnění Datová tržiště Etapa 1 Analýza statistické domény produkčních statistik 1 Obsah ETAPA 1 ANALÝZA STATISTICKÉ DOMÉNY PRODUKČNÍCH STATISTIK... 3 1.1. Koncepční shrnutí...
Problémové domény a jejich charakteristiky
Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 02 1/16 Problémové domény a jejich charakteristiky Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta
ČSN EN ISO (únor 2012)
ČSN EN ISO 50001 (únor 2012) nahrazuje ČSN EN 16001 z 02/2010 kompatibilní s ISO 9001 a ISO 14001 Seminář: ČSN EN ISO 50001: 2012 Zadavatel: EKIS Délka přednášky: 1 hodina Přednášející: Ing. Vladimír Novotný
Nebojte se přiznat, že potřebujete SQA
Nebojte se přiznat, že potřebujete SQA Internet a technologie 16 Václav Klimeš vaclav.klimes@nic.cz 1. 6. 2016 Osnova Kvalita Koncept kvality Co je a není SQA (Software Quality Assurance) Proč se zajímat
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
Pracovní celky 3.2, 3.3 a 3.4 Sémantická harmonizace - Srovnání a přiřazení datových modelů
Pracovní celky 3.2, 3.3 a 3.4 Sémantická harmonizace - Srovnání a datových modelů Obsah Seznam tabulek... 1 Seznam obrázků... 1 1 Úvod... 2 2 Metody sémantické harmonizace... 2 3 Dvojjazyčné katalogy objektů
CMMI-DEV v.1.3 PA Configuration management
VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE CMMI-DEV v.1.3 PA Configuration management 4IT421 - Zlepšování procesů budování IS Pavel Neuman ZS 2012/2013 Obsah 1. Úvod... 2 2. Configuration Management... 2 2.1. Úvodní
Ú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í
Vstupní analýza absorpční kapacity OPTP. pro programové období 2014 2020
Manažerské shrnutí 1 Výstup zpracovaný k datu: 10. 2. 2014, aktualizace k 7.5. 2014 Zpráva zpracována pro: Ministerstvo pro místní rozvoj ČR Staroměstské náměstí 6 110 15 Praha 1 Dodavatel: HOPE-E.S.,
Národní šetření výsledků žáků v počátečním vzdělávání
Projekt NIQES Národní šetření žáků v počátečním vzdělávání Národní šetření výsledků žáků v počátečním vzdělávání Druhá celoplošná generální zkouška Název souboru: CP2-Procesy_přípravy_a_realizace_V3.doc
ČESKÁ TECHNICKÁ NORMA
ČESKÁ TECHNICKÁ NORMA ICS 01.040.35; 35.040 Říjen 2014 Informační technologie Bezpečnostní techniky Systémy řízení bezpečnosti informací Přehled a slovník ČSN ISO/IEC 27000 36 9790 Information technology
Standardy projektového řízení
Standardy projektového řízení Project Management Body of Knowledge Aktuálně pátá verze Zaštítěn Project Management Institute (PMI) V ČR Česká komora PMI Partner Studentského klub projektového řízení Rozšířen
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.
TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY
Příloha č. 3 k č.j. MV-159754-3/VZ-2013 Počet listů: 7 TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Nové funkcionality Czech POINT 2012 Popis rozhraní egon Service Bus Centrální Místo Služeb 2.0 (dále jen CMS
Národní technické specifikace. služeb nad prostorovými daty a metadaty
Národní technické specifikace služeb nad prostorovými daty a metadaty Jiří Kvapil, CENIA, Nemoforum - seminář, ČÚZK, 26.4.2017 Výstupy 1. Metodika zpracování specifikace datového produktu pro datové zdroje
Obecná příručka IS o ISVS
Obecná příručka IS o ISVS Informační systém o informačních systémech veřejné správy verze 2.02.00 vypracovala společnost ASD Software, s.r.o. dokument ze dne 16. 11. 2016, verze 1.01 Obecná příručka IS
Přípravné činnosti projektu. Mgr. Lenka Svrčinová Ing. Jan Ministr, Ph.D.
Přípravné činnosti projektu Mgr. Lenka Svrčinová Ing. Jan Ministr, Ph.D. Obsah prezentace Seznámení s problematikou Procesy a roviny před implementací projektu Obchodní rovina Implementační rovina Řešení
Obecné nařízení o ochraně osobních údajů
AGORA PLUS, a.s. Ing. Martin Havel, MBA General Data Protection Regulation (zkráceně GDPR) Obecné nařízení o ochraně osobních údajů Jak zvládnout GDPR v 9-ti krocích 22.9.2017, Brno Představení 2012 CISM
Interpretace určená výrobcům pro prokázání shody s EWF certifikačním schématem pro EN 729. Doc.EWF Česká verze
Interpretace určená výrobcům pro prokázání shody s EWF certifikačním schématem pro EN 729 Doc.EWF 487-02 Česká verze 1/11 Interpretace určená výrobcům pro prokázání shody s EWF certifikačním schématem
Metodické postupy tvorby architektury
Metodické postupy tvorby architektury Název Metodické postupy tvorby architektury Datum zhotovení 14. 3. 2016 Zhotovitel KPMG Česká republika, s.r.o. Zpracoval za zhotovitele Tomáš Martinka Verze 2.1 Veřejná
Business Continuity Management jako jeden z nástrojů zvládání rizik. Ing. Martin Tobolka AEC, spol. s r.o.
Business Continuity Management jako jeden z nástrojů zvládání rizik Ing. Martin Tobolka AEC, spol. s r.o. Co je BCM? Mezi časté příčiny přerušení kontinuity činností patří technická selhání (energie, HW,
PRODUKTY. Tovek Tools
jsou desktopovou aplikací určenou k vyhledávání informací, tvorbě různých typů analýz a vytváření přehledů a rešerší. Jsou vhodné pro práci i s velkým objemem textových dat z různorodých informačních zdrojů.
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
VZ20/2009 Modernizace TS se zaměřením na dostupnost a bezpečnost
VZ20/2009 Modernizace TS se zaměřením na dostupnost a bezpečnost Dodatečné informace k ZD Dotaz č. 1 K bodu 5.1.1. SERVER DATOVÉHO CENTRA Můžete potvrdit, že pro dodávku 1 ks nového blade serveru bude
Vnitřní kontrolní systém a jeho audit
Vnitřní kontrolní systém a jeho audit 7. SETKÁNÍ AUDITORŮ PRŮMYSLU 11. 5. 2012 Vlastimil Červený, CIA, CISA Agenda Požadavky na VŘKS dle metodik a standardů Definice VŘKS dle rámce COSO Role interního
1. Úvod. 2. CryptoPlus jak začít. 2.1 HW a SW předpoklady. 2.2 Licenční ujednání a omezení. 2.3 Jazyková podpora. Požadavky na HW.
CryptoPlus KB verze 2.1.2 UŽIVATELSKÁ PŘÍRUČKA říjen 2013 Obsah Obsah 2 1. Úvod 3 2. CryptoPlus jak začít... 3 2.1 HW a SW předpoklady... 3 2.2 Licenční ujednání a omezení... 3 2.3 Jazyková podpora...