Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů

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

Download "Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů"

Transkript

1 Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů Alena Buchalcevová Vysoká škola ekonomická v Praze, Fakulta informatiky a statistiky, katedra informačních technologií nám. W. Churchilla 4, Praha 3 Abstrakt: Hlavním cílem článku je poukázat na význam kvality softwarového produktu, přiblížit mezinárodní a národní normy, které se kvalitou softwarových produktů zabývají, a analyzovat, jak je posuzování kvality adresováno ve vybraných metodikách budování informačních systémů. Klíčová slova: informační systém, kvalita, jakost, normy kvality, řízení kvality, metodiky vývoje softwaru Abstract: The main goal of this paper is to mention the importance of software product quality, describe international and national quality standards and analyze how these standards are used in software development methodologies. Keywords: information system, quality, quality standards, quality management, software development methodologies 1. Úvod V současné informační společnosti stále roste význam informačních systémů a informačních a komunikačních technologií (IS/ICT), které pomáhají podnikům uspět v tržních podmínkách, využít nabízených možností a čelit potencionálním hrozbám. Spolu s tím ale roste i význam kvality informačního systému, neboť potenciální chyba může způsobit finanční škody, ovlivnit samu existenci firmy či zdraví a životy lidí. Proto se kvalita informačního systému a zejména její ověření dostává do popředí zájmu nejen softwarových firem, ale i zákazníků. Kvalita je definována různě, s ohledem na zaměření tohoto článku vyjdu z definice kvality tak, jak je uvedena v národních normách. V té souvislosti je třeba uvést, že národní normy používají pro překlad anglického termínu quality pojem jakost tak, aby to bylo v souladu s překladem používaným dříve (např. u norem řady ISO 9000). Jakost (quality) je celkový souhrn charakteristik entity, které ovlivňují její schopnost uspokojovat stanovené nebo předpokládané potřeby. [ČSN , 2002] Entitou je přitom myšlen softwarový produkt. Pojmy kvalita a jakost budu používat jako synonymum. Na zajištění kvality informačního systému se můžeme dívat ze dvou pohledů. Jednak jde o zajištění kvality procesu budování informačního systému a jednak zajištění kvality produktu tedy informačního systému. Nejprve objasním pojem budování informačního systému, který používám proto, že v dnešní době se úplně nový software respektive informační systém vytváří v menší míře. Častěji jde o implementaci již hotových řešení, integraci různých komponent a SYSTÉMOVÁ INTEGRACE 1/

2 Alena Buchalcevová služeb. Pro zajištění kvality procesu budování informačních systémů slouží zejména řada norem ISO které patří u nás k nejznámějším a nejčastěji zaváděným. Základní normou je ČSN EN ISO 9001:2001 Systémy managementu jakosti Požadavky na systém, ve které jsou specifikovány požadavky na systém řízení jakosti, jehož zavedení umožňuje organizaci prokázat schopnost trvale poskytovat výrobek, který splňuje požadavky zákazníka a příslušné požadavky předpisů, zvyšovat spokojenost zákazníka a neustále zlepšovat své procesy. Pro organizace, které se zabývají budováním IS, má význam zejména norma ISO/IEC 90003, respektive ČSN ISO/IEC Softwarové inženýrství Směrnice pro použití ISO 9001:2000 na počítačový software. Pro získání certifikace na ISO 9000, musí organizace definovat procesy pro vývoj, provoz a údržbu softwaru, posloupnost těchto procesů a jejich vzájemné vazby. Doporučuje se využít normy ISO/IEC Procesy v životním cyklu softwaru, která obsahuje Referenční model procesů. Kromě mezinárodních a národních norem se na zlepšování procesů budování IS zaměřuje také model CMMI Integrační model zralosti (Capability Maturity Model Integration) a četné metodiky budování IS, kterým je věnována kapitola 3. Úroveň kvality procesu budování IS se zjišťuje na základě posouzení procesů, které se provádí buď na základě normy ISO/IEC anebo metodou SCAMPISM posuzující podle modelu CMMI. Druhý pohled, pohled na kvalitu produktu, posuzuje vlastnosti produktu z pohledu uživatele. Produktem je software resp. informační systém, nebo poskytovaná služba. Jak uvádí [Vaníček, 2007], normalizace v oblasti kvality produktů naráží na problém, že normy pro jednotlivé typy produktů se musí od sebe podstatně lišit, a tak je obtížné nalézt společné požadavky na kvalitu produktů podobně jako u norem procesů řízení jakosti. Přesto existuje celá řada norem, které se zabývají definování kvality jakosti softwaru a jejím posuzováním (viz následující kapitola). Tyto normy jsou však obecně méně známé a používané než normy řady ISO U nás je malá známost těchto norem podpořena ještě tím, že trh informačních produktů je stále v našich podmínkách spíše než trhem zákazníka trhem dodavatelů informatických produktů a to především velkých světových firem. [Vaníček, 2007] 2. Normy v oblasti kvality softwaru Řada norem ISO/IEC 9126 Softwarové inženýrství Jakost produktu je představována normou ISO/IEC Model jakosti (podrobněji v 2.1) a třemi technickými zprávami, které obsahují příklady měr jakosti Vnější míry jakosti , Vnitřní míry jakosti a Míry jakosti užití Řada ISO/IEC Softwarové inženýrství Hodnocení softwarového produktu obsahuje šest částí. Norma Obecný přehled je úvodním dokumentem, který definuje terminologii a postupy při hodnocení. Vlastní postupy při hodnocení jsou popsány v částech: Postup vývojáře, Postup opatřovatele a Postup (nezávislého) hodnotitele. Poslední norma této řady Dokumentace hodnotících postupů sjednocuje způsoby, jak hodnocení dokumentovat. [Vaníček, 2007] Vzájemné vztahy mezi normami ISO/IEC 9126 a ISO/IEC zachycuje obrázek 1. V současnosti se v rámci ISO/IEC JTC1 SC7 připravuje nová řada norem ISO/IEC pod názvem SQuaRE - Software Quality Requirements and 110 SYSTÉMOVÁ INTEGRACE 1/2011

3 Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů Evaluation. Popis aktuálního stavu projektu SQuaRE a zejména problémů s ním spojených lze nalézt v [Vaníček, 2007]. Obrázek 1. Vzájemné vztahy mezi normami ISO/IEC 9126 a ISO/IEC 14598, zdroj:[čsn , 2002] 2.1 Model jakosti Vzhledem k tomu, že klíčové normy projektu SQuaRE ještě nebyly vydány a ty již vydané nejsou zatím uvažovány pro převzetí jako ČSN, budu vycházet při posuzování podpory kvality softwaru v metodikách budování informačních systémů z normy ČSN ISO/IEC Softwarové inženýrství Jakost produktu Část 1: Model jakosti. Tato norma popisuje model jakosti, který má dvě části: vnitřní a vnější jakost a jakost při používání. Jak ukazuje obrázek 2, kvalitu můžeme posuzovat na úrovni procesu vytváření produktu, produktu samotném a účinku používání produktu. Proces vytváření softwaru je popsán například v normě ISO/IEC Procesy v životním cyklu softwaru. Jedním z procesů definovaných v této normě je proces Ověřování kvality softwaru (Software Quality Assurance). Ověření se provádí na základě měření vnitřních atributů (obvykle statické míry meziproduktů) nebo měřením vnějších atributů (obvykle měření chování softwaru při běhu) nebo měřením atributů jakosti při používání. Cílem je, aby produkt měl požadovaný účinek v určitém kontextu použití. Normalizace v oblasti kvality je založena na přesvědčení, že zlepšování procesu vývoje softwaru je prostředkem pro zlepšování jakosti produktu a hodnocení a zlepšování jakosti produktu je prostředkem pro zlepšování jakosti při používání. Na druhou stranu hodnocení jakosti při používání poskytuje zpětnou vazbu pro zlepšování produktu a hodnocení produktu poskytuje zpětnou vazbu pro zlepšování procesu. Vhodné vnitřní atributy softwaru jsou nezbytným předpokladem pro dosažení požadovaného SYSTÉMOVÁ INTEGRACE 1/

4 Alena Buchalcevová vnějšího chování a vhodné vnější chování je nezbytným předpokladem pro dosažení jakosti při používání. Obrázek 2. Přístupy k jakosti, zdroj:[čsn , 2002] Pohled na vnitřní jakost, vnější jakost a jakost při používání se v průběhu životního cyklu softwaru mění. Na obrázku 3 jsou zachyceny vzájemné vztahy mezi druhy jakosti a požadavky na ně v průběhu životního cyklu softwaru. Obrázek 3. Jakost v životním cyklu softwaru, zdroj:[čsn , 2002] 112 SYSTÉMOVÁ INTEGRACE 1/2011

5 Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů Potřeby uživatele týkající se jakosti mohou být specifikovány jako požadavky na jakost pomocí měr jakosti při používání, vnější jakosti a vnitřní jakosti. Tyto míry mají být používány jako kritéria při validaci produktu a akceptační kritéria. Požadavky na vnější jakost specifikují požadovanou úroveň jakosti z vnějšího pohledu pohledu uživatele a mají být specifikovány pro všechny charakteristiky jakosti s použitím měr vnější jakosti. Požadavky na vnější jakost se transformují na požadavky na vnitřní jakost, které specifikují úroveň požadované jakosti z vnitřního pohledu produktu (meziproduktů), a slouží jako kritéria při hodnocení produktu. Tato jakost je chápána z pohledu vývojářů. Jakost při používání představuje pohled uživatele na jakost softwarového produktu, který je používán v konkrétním prostředí a v konkrétním kontextu, a měří splnění cílů. Jak uvádí [ČSN , 2002], smyslem řízení jakosti je dosáhnout nezbytné a postačující jakosti, aby se naplnily skutečné potřeby uživatelů. Problémem ale je, jak poznat a definovat skutečné potřeby uživatelů. Potřeby stanovené uživatelem totiž vždy neodráží skutečné potřeby uživatele, protože: uživatel si často neuvědomuje své skutečné potřeby, potřeby se mohou po jejich stanovení změnit, rozdílní uživatelé mají rozdílné provozní prostředí, obtížné je zjistit potřeby všech typů uživatelů zvláště u typového aplikačního softwaru. Proto je obtížné na začátku životního cyklu specifikovat požadavky na jakost v celém rozsahu a je třeba počítat i s jejich změnami. Na obrázku 4 jsou zachyceny charakteristiky vnější a vnitřní jakosti: funkčnost, bezporuchovost, použitelnost, účinnost, udržovatelnost a přenositelnost. Obrázek 4. Model jakosti pro vnější a vnitřní jakost, zdroj:[čsn , 2002] SYSTÉMOVÁ INTEGRACE 1/

6 Alena Buchalcevová Funkčnost je způsobilost softwarového produktu poskytovat funkce, které uspokojují stanovené a předpokládané potřeby, pokud je software používán za specifikovaných podmínek. Bezporuchovost je způsobilost softwarového produktu udržovat specifikovanou úroveň výkonu, pokud je používán za specifikovaných podmínek. Použitelnost je způsobilost softwarového produktu být srozumitelný, zvládnutelný, používaný a atraktivní pro uživatele, pokud je používán za specifikovaných podmínek. Účinnost je způsobilost softwarového produktu poskytovat vhodný výkon s ohledem na množství použitých zdrojů a za stanovených podmínek. Udržovatelnost je způsobilost softwarového produktu být modifikován. Modifikace mohou zahrnovat nápravy, zlepšování nebo adaptace softwaru na změny v prostředí, v požadavcích a ve specifikaci funkcí. Přenositelnost je způsobilost softwarového produktu být přenesen z jednoho prostředí do jiného prostředí. [ČSN , 2002] Každá z těchto charakteristik by měla být hodnocena zvlášť. Pro hodnocení jsou charakteristiky dále dekomponovány na podcharakteristiky, pro které jsou stanoveny jejich měřitelné vlastnosti atributy. Hodnoty atributů měřené v definované stupnici míry se porovnávají s hodnotami stanovenými v požadavcích indikátory kvality. Seznam atributů a měr měl být určen částmi 2 až 4 normy Zde se však rozumný seznam sestavit nezdařilo. [Vaníček, 2007] Na obrázku 5 jsou uvedeny charakteristiky jakosti při používání: efektivnost, produktivita, bezpečnost a uspokojení. Efektivnost je způsobilost softwarového produktu umožnit, aby uživatelé dosáhli specifikovaných cílů s přesností a kompletností ve specifikovaném kontextu použití. Produktivita je způsobilost softwarového produktu umožnit, aby uživatelé vynaložili ve vztahu k dosažené efektivnosti a ve specifikovaném kontextu použití vhodné množství zdrojů. Bezpečnost je způsobilost softwarového produktu dosáhnout akceptovatelné úrovně rizika škod na lidech, byznysu, softwaru, vlastnictví nebo prostředí ve specifikovaném kontextu použití. Uspokojení je způsobilost softwarového produktu uspokojovat uživatele ve specifikovaném kontextu použití. [ČSN , 2002] Obrázek 5. Model jakosti pro jakost při používání, zdroj:[čsn , 2002] 114 SYSTÉMOVÁ INTEGRACE 1/2011

7 Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů Použití modelu jakosti Model jakosti definovaný v normě ČSN ISO/IEC je použitelný pro různé typy softwaru. Poskytuje terminologii, a to i českou, v oblasti kvality softwarového produktu. Jeho využití je v oblasti správy požadavků pro identifikaci požadavků na software, strukturování požadavků na kvalitu softwaru, validaci úplnosti specifikace požadavků. Může být použit pro identifikaci cílů návrhu a testování softwaru, identifikaci kritérií zabezpečování jakosti a identifikaci akceptačních kritérií pro dokončený softwarový produkt. Norma ČSN ISO/IEC může být použita jako doplňková v rámci použití dalších norem, zejména: při posuzování procesů dle ISO/IEC 15504, protože poskytuje strukturu pro specifikaci jakosti, podporu pro procesy verifikace a validace a podporu pro specifikaci cílů jakosti organizace, normy ISO/IEC 12207, kde poskytuje strukturu pro specifikaci požadavků na jakost softwarového produktu a podporu pro procesy verifikace a validace, společně s ISO 9001 a poskytuje podporu pro nastavení cílů jakosti a podporu pro přezkoumání návrhu, verifikaci a validaci. 3. Analýza podpory hodnocení kvality ve vybraných metodikách budování informačních systémů V České republice se pro zlepšování procesů při budování informačních systémů daleko více využívá metodik než mezinárodních norem (ISO/IEC 12207, 15504) a standardů (model CMMI ). Metodika budování IS/ICT definuje principy, procesy, praktiky, role, techniky, nástroje a produkty používané při vývoji, údržbě a provozu informačního systému, a to jak z hlediska softwarově inženýrského, tak z hlediska řízení. [Buchalcevová, 2009] V praxi se dnes setkáme se dvěma hlavními kategoriemi metodik, kterými jsou tradiční (rigorózní) metodiky a agilní metodiky. Rigorózní metodiky vycházejí z přesvědčení, že procesy při budování IS/ICT lze popsat, plánovat, řídit a měřit, a proto je podrobně a přesně definují. Podle agilních metodik vývoj softwaru není definovaný proces, ale empirický proces, který vyžaduje monitorování a adaptaci. Vývoj probíhá ve velmi krátkých iteracích, které končí dodáním funkční verze systému. Každá z agilních metodik je svým způsobem specifická, ale všechny jsou postaveny na stejných principech a hodnotách, které byly v roce 2001 definovány v Manifestu agilního vývoje softwaru. [Beck, 2001] Mezi agilní metodiky byly od počátku řazeny následující metodiky a přístupy: Dynamic Systems Development Method (DSDM), Adaptive Software Development ( ASD), Feature Driven Development (FDD), Extrémní programování (Extreme Programming, XP), Lean Development, Scrum, Crystal metodiky, Agilní modelování (Agile Modeling). Později vznikly nové agilní metodiky jako například Microsoft Solutions Framework (MSF) for Agile Software Development a metodika OpenUP. Aby bylo možné agilní metodiky efektivně použít, musí být splněny určité předpoklady. Nejdůležitějším předpokladem použití agilních metodik je požadavek, aby zákazník byl součástí týmu a byl k dispozici podle potřeby. Dalším klíčovým předpokladem je velikost týmu. Ideální agilní tým má maximálně 8 vývojářů, kteří pracují v jedné SYSTÉMOVÁ INTEGRACE 1/

8 Alena Buchalcevová místnosti a mohou tak plně využívat výhod osobní komunikace. Třetím klíčovým požadavkem jsou vysoké znalosti, zkušenosti a morální hodnoty vývojářů. [Mullaney, 2008] uvádí omezené použití agilních metodik pro distribuovaný vývoj, vývoj se subdodavateli, pro vytváření znovupoužitelných artefaktů, pro vývoj ve velkém týmu, pro vývoj kritických aplikací a pro vývoj velkého komplexního softwaru. V poslední době jsme svědky stále častějšího používání agilních přístupů, ale také vzájemného ovlivňování obou skupin metodik. Ukazuje se, že rigorózní metodiky je možné odlehčit a aplikovat v jejich rámci některý z agilních přístupů. Na druhé straně, pokud potřebujeme použít agilní metodiky na větší projekty, projekty vyvíjené distribuovanými týmy či projekty větší důležitosti, je třeba je více formalizovat a obohatit o nové praktiky. Analýzu podpory hodnocení kvality jsem provedla na vybraných metodikách budování IS/ICT, jak rigorózních, tak agilních. Při výběru metodik jsem vycházela z průzkumů používání metodik ve světě [Ambler, 2006] a vybrala pro hodnocení metodiky, které se nejvíce používají. Mezi hodnocené metodiky jsem zařadila také novou a perspektivní metodiku OpenUP. 3.1 Rational Unified Process Metodika Rational Unified Process (RUP) je v současnosti de facto standardem mezi metodikami. Původně byla zařazována mezi rigorózní metodiky zejména z důvodu velké podrobnosti metodiky, ale od roku 2003 je doplňována o agilní praktiky a v současné době představuje rámec, ve kterém je možné vytvořit metodiky pro všechny typy projektů od velmi formální metodiky až po velmi lehkou, agilní metodiku. Metodika RUP je založena na nejlepších praktikách softwarového vývoje: iterativní vývoj, řízení požadavků, použití komponentové architektury, vizuální modelování, kontrola kvality softwaru a řízení změn. Životní cyklus softwaru je rozdělen do 4 po sobě jdoucích fází. V rámci fáze Zahájení se definují cíle projektu, požadavky, vytváří se harmonogram projektu, odhadují se náklady projektu a definují rizika. Cílem fáze Rozpracování je definovat architekturu systému a ověřit ji. Předmětem Konstrukční fáze je návrh a realizace systému včetně testování. Cílem fáze Zavedení je zajistit, aby uživatelé mohli systém používat. Součástí této fáze je školení uživatelů, předání dokumentace, vytvoření help-desku atd. Každá fáze je uzavřena milníkem, ve kterém se posuzuje, zda byly splněny cíle fáze a rozhoduje se o dalším postupu. Metodika RUP se vyznačuje velmi výraznou podporou zajištění kvality. Tuto podporu explicitně deklaruje tím, že jednou z 6 nejlepších praktik, na kterých je postavena, je praktika Kontinuální ověřování kvality. RUP je postaven na iterativním životním cyklu a ověřování kvality je integrální součástí každé iterace. Na konci iterace se hodnotí, zda byly splněny cíle iterace, adresována rizika, dodána plánovaná funkčnost a splněny atributy kvality. Kvalita je v metodice RUP definována v rámci dimenzí, které odpovídají modelu FURPS F (functionality), U (usability), R (reliability, P (performace), S (supportability), který byl poprvé publikován v [Grady, 1987]. V poslední době se model FURPS rozšířil o další dílčí prvky a používá se pro něj označení FURPS+. Dimenze kvality modelu FURPS v podstatě odpovídají charakteristikám vnější a vnitřní jakosti modelu jakosti dle ČSN ISO/IEC , které jsou zachyceny na obrázku 4. Model jakosti navíc jako charakteristiku uvádí přenositelnost, která je ovšem v modelu 116 SYSTÉMOVÁ INTEGRACE 1/2011

9 Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů FURPS součástí dimenze supportability. RUP používá tyto dimenze kvality pro definování struktury dokumentu Supplementary specification, který je součástí specifikace požadavků. Na základě dimenzí kvality se definují jednotlivé typy testů. RUP poskytuje poměrně komplexní sadu postupů pro zajištění kvality. V rámci disciplíny Testování jsou definovány 4 role manažer testů, analytik testů, návrhář testů a tester. Pro každou roli jsou definovány činnosti, které provádí, a artefakty, za které zodpovídá. 3.2 OpenUP Metodika OpenUP je nová agilní metodika dostupná pod Eclipse Public License. OpenUP je minimálně dostatečná, kompletní metodika pro vývoj softwaru, která je snadno přizpůsobitelná a rozšiřitelná. Vznikla zeštíhlením metodiky Unified Process, je tedy založena na iterativním a inkrementálním modelu životního cyklu, případech užití, řízení rizik a architektuře. Celý životní cyklus projektu je opět rozdělen do 4 fází Zahájení, Rozpracování, Konstrukce a Zavedení. Metodika OpenUP je určena pro menší týmy. Ve snaze být agilní metodikou je oproti metodice Unified Process zredukován jak počet disciplín, tak počet rolí. Metodika OpenUP definuje disciplíny Řízení projektu, Požadavky, Architektura, Vývoj a Testování a role zainteresovaná strana, analytik, architekt, vývojář, tester, vedoucí projektu a kdokoli. Metodika také využívá modelu FURPS+ pro definování dimenzí kvality. V oblasti správy požadavků jsou dimenze kvality opět použity pro definování kvalitativních požadavků zde jsou součástí dokumentu System Wide Requirements, pro který je poskytována šablona určující jeho strukturu a také kontrolní seznam ověřující kvalitu tohoto dokumentu. Funkční požadavky jsou specifikovány ve formě případů užití a kvalitativní požadavky ve struktuře U (usability), R (reliability), P (performace), S (supportability). Odlehčení metodiky OpenUP se dle mého názoru nepříznivě projevuje v nedostatečné podpoře zajištění kvality. Jediná role Tester není dostatečná1 a jsou pro ni definovány pouze činnosti Vytvoření testovacích případů, Implementace testů a Spuštění testů. Metodika se zaměřuje v podstatě jen na funkční testy, vůbec neřeší ostatní typy testů, které by ověřovaly ostatní dimenze kvality. 3.3 Feature driven development Metodika Feature driven development (FDD) se řadí mezi agilní metodiky, ale definuje procesy, byť odlehčené, a zdůrazňuje nutnost modelování předem. Je formálnější než ostatní agilní metodiky, a tak ji lze úspěšně použít i na větší projekty. Metodika FDD je založena na iterativním vývoji, který je řízen užitnými vlastnostmi produktu. Užitná vlastnost (feature) je malý výsledek užitečný z pohledu zákazníka, který je srozumitelný, měřitelný a realizovatelný v rámci dvoutýdenní iterace. Základem pro zajištění kvality v metodice FDD jsou zejména praktiky doménové objektové modelování a inspekce. Praktika doménové objektové modelování spočívá ve vytvoření konceptuálního modelu tříd a definování vlastníků tříd na začátku životního cyklu, čímž pomáhá držet konceptuální integritu systému. FDD spoléhá na inspekce, které zajišťují vysokou kvalitu návrhu a kódu. Inspekce mohou podstatně snížit počet chyb jejich včasnou detekcí. Primárním účelem inspekcí v metodice FDD 1 jednotkové testy provádí role Vývojář SYSTÉMOVÁ INTEGRACE 1/

10 Alena Buchalcevová je odhalení defektů, ale pokud se inspekce provádějí dobře, můžeme získat ještě dodatečné přínosy jako přenos znalostí a dodržování standardů. Inspekce se vhodně doplňují s praktikou malých týmů pro užitné vlastnosti. Pokud vývoj užitné vlastnosti neovlivňuje jiné týmy, probíhají inspekce pouze v rámci jednoho týmu. Metodika FDD se věnuje zejména charakteristikám vnitřní jakosti. Vnější jakost a jakost při používání je řešena podobně jako u ostatních agilních metodik zapojením zákazníka do projektu, čímž se získává rychlá zpětná vazba. 3.4 Metodika Scrum Podle výsledků průzkumů [Ambler, 2006] patří Scrum spolu s metodikou Extrémní programování mezi nejpoužívanější agilní metodiky. Metodika Scrum je zaměřena hlavně na řízení projektu. Vývoj probíhá v 30denních iteracích nazývaných Sprint, ve kterých se dodává vybraná množina užitných vlastností. Klíčovou praktikou jsou denní porady (Scrum Meetings), které slouží pro koordinaci prací. Metodika Scrum definuje jen 3 role Product Owner, Team a ScrumMaster. Product Owner spravuje seznam požadavků (Product Backlog) tak, aby maximalizoval hodnotu projektu. Team je skupina lidí s různou specializací, kteří se sami řídí tak, aby v každém Sprintu dodali fungující software. Scrum Master zodpovídá za metodiku, její správnou implementaci a maximalizaci užitku. Řízení kvality v metodice Scrum explicitně adresováno není, a to zejména ze dvou důvodů. První důvod spočívá v tom, že je metodika Scrum zaměřena na řízení projektu a jen v malé míře se zabývá softwarovým inženýrstvím. Druhý důvod pak spočívá v podstatě agilních metodik, které definují jen principy a praktiky, nikoli přesné a podrobné postupy. Metodika tedy nijak nepracuje s charakteristikami kvality softwaru, přesto tu základ pro zajištění kvality produktu nalezneme. Spočívá zejména v plném zapojení zástupce uživatelů role Product Owner, do práce na projektu a v jeho zodpovědnosti za požadavky. Dalším nástrojem zajištění kvality produktu je vývoj v krátkých iteracích sprintech a díky tomu časná zpětná vazba, která se realizuje v rámci praktik Sprint Review Meeting, na kterém se uživateli předvádí výsledek iterace, a Sprint Retrospective Meeting, který slouží k hodnocení průběhu iterace. 3.5 Metodika Extrémní programování Extrémní programování (XP) je velmi lehká, ale disciplinovaná metodika, která zavádí specifické praktiky jako párové programování, refaktorizace, testy před kódováním a další. Extrémní programování je typická agilní metodika, jejíž praktiky mají za cíl vyvinout produkt, který uspokojí aktuální potřeby zákazníka. Řízení kvality metodika neřeší explicitně, ale spíše implicitně. Důležitým aspektem dodání kvalitního softwaru je opět zákazník, který je součástí týmu a odpovídá za požadavky. Požadavky se v XP definují ve formě uživatelských příběhů (user story), které píší sami zákazníci a vyjadřují v nich své potřeby, které má systém podpořit. Pro každý požadavek specifikuje zákazník akceptační test, který ověří, zda byl požadavek implementován úspěšně. Extrémní programování se hodně věnuje také vnitřní jakosti, tedy kvalitě z pohledu vývojářů. Ta je zajišťována jednak požadavkem na vysokou kvalifikaci vývojářů, velmi dobře definovanými standardy a konvencemi a zejména využíváním techniky testy řízený vývoj (Test driven development), kdy vývojáři musí 118 SYSTÉMOVÁ INTEGRACE 1/2011

11 Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů nejprve napsat testy, až poté kód. Testy řízený vývoj spolu s refaktorizací zajišťuje stálou kvalitu kódu. Praktika párové programování pak představuje kontinuální ověřování kvality. 3.6 Metodika Microsoft Solutions Framework Microsoft Solutions Framework je rámec pro vývoj softwaru, ve kterém je možné definovat metodiku pro konkrétní organizaci, či konkrétní projekt. Součástí MSF 4.0 jsou dvě definované metodiky. MSF for Agile Software Development je agilní metodika, která je vhodná pro menší projekty s rychlou dodávkou. MSF for CMMI Process Improvement má formálnější plánování, více dokumentace, podrobnější sledování času, složitější workflow a je navržena tak, aby odpovídala úrovni zralosti 3 podle modelu CMMI. Metodika MSF se vyznačuje výraznou podporou řízení kvality, která je vyjádřena definováním principu Investice do kvality jako jednoho z 8 základních principů metodiky MSF. Investice do kvality je investicí do lidí, procesů a nástrojů. Tým musí být přesvědčen, že vyrábí dostatečně kvalitní produkt. Úspěšné řízení kvality předpokládá, že se kvalita stává součástí firemní kultury. Zároveň je třeba zajistit, aby byl dodáván kvalitní produkt i při změnách požadavků. MSF definuje 2 modely týmový model a Governance model. Týmový model definuje 7 skupin uživatelských rolí: Řízení produktu (Product Management), Řízení programu (Program Management), Architektura (Architecture), Vývoj (Development), Testování (Test), Provoz (Release/Operations) a Zkušenosti uživatelů (User Experience). Řízení kvality se promítá do činností všech skupin rolí. Role Řízení produktu má na starosti definování požadavků, jejich pochopení a sledování jejich naplnění. Součástí Řízení programu je realizace procesu Řízení kvality (Project Quality Managament). Testování je nutné pro splnění kvalitativních požadavků zákazníka. Testy předvídají, hledají a reportují jakékoliv problémy, které mohou snížit kvalitu řešení. Probíhá zde také monitoring, měření a vyhodnocování kvality řešení. Na rozdíl od skupiny Vývoj, která má na starosti jednotkové testování, předmětem role Testování je funkční testování a systémové testování. Kvalita při používání je předmětem zájmu role Zkušenosti uživatelů (User Experience). Tato skupina reprezentuje pohled ze strany zákazníka. Řešení musí vycházet ze znalostí a zkušeností uživatelů a přizpůsobit se jim pro zajištění maximální efektivity jejich práce. Skupina musí chápat prostředí uživatelů jako celek, rozpoznat všechny potřeby a požadavky koncových uživatelů a zajistit, aby si celý tým uvědomil význam použitelnosti z pohledu koncových uživatelů Governance model pak představuje celý životní cyklus vývoje a zaměřuje se na kvalitu procesu. Mezi jednotlivými fázemi jsou definovány kontrolní body, kdy je vytvořené řešení porovnáváno s kvalitativními kritérii stanovenými na začátku projektu. Hlavním kontrolním bodem je převzetí řešení zákazníkem, které spočívá především v hodnocení produktu podle předem definovaných akceptačních kritérií. Na zvyšování kvality se podílí i MSF Readiness Management Discipline, která se stará o optimální zastoupení schopností a dovedností v týmu. 4. Závěr Článek ukázal rostoucí potřebu zajistit dodávku kvalitních softwarových produktů a přiblížil cesty k jejímu dosažení. Mezinárodní a národní normy, podobně jako tradiční SYSTÉMOVÁ INTEGRACE 1/

12 Alena Buchalcevová metodiky budování informačních systémů, vycházejí z předpokladu, že čím bude kvalitnější proces budování IS, tím kvalitnější bude i výsledný produkt. Současně se zlepšováním procesů při budování IS se ale věnují také měření kvality produktu s pomocí vnitřních a vnějších charakteristik jakosti a jakosti při používání. Agilní metodiky, které jsou proti podrobnému popisu procesů a formálním měřením a hodnocením, prosazují takové praktiky, které implicitně vedou k vysoké vnitřní jakosti produktu. Vnější jakost, zejména splnění měnících se požadavků zákazníka, je zajištěna vtažením zákazníka do procesu vývoje a přenesením odpovědnosti za definování požadavků, určení jejich priorit a akceptační testy na něj. Příspěvek vznikl v rámci řešení grantu IG Zavedení procesu řízení kvality jako integrální součásti metodiky vývoje informačního systému 5. Použité zdroje AMBLER, S. W.: Agile software development methods and techniques are gaining traction. In Dr. Dobb Portal, srpen [online]. Think Services, c2007 [cit ]. Dostupný z WWW: < BECK K. et al. Manifesto for Agile Software Development [cit ]. Dostupný z WWW <http://agilemanifesto.org/>. BUCHALCEVOVÁ, A.: Metodiky budování informačních systémů. 1. vyd. Praha : Oeconomica, s. ISBN GRADY, R.; CASWELL, D.: Software Metrics: Establishing a Company-wide Program. Prentice Hall pp. p ISBN ČSN ISO/IEC Softwarové inženýrství Jakost produktu Část 1: Model jakosti VANÍČEK, J.: Kvalita informačních systémů z pohledu mezinárodní normalizace (aktuální informace), Sborník příspěvků z konference Systém řízení kvality a bezpečnosti informačních systémů ve zdravotnictví, ČZU, Praha, 2007, 2007, s Dostupný z WWW <http://czu.vasekk.cz/ing/04_desaty%20semestr/jakost_is/08_square.pdf 120 SYSTÉMOVÁ INTEGRACE 1/2011

Jakou metodiku použít pro

Jakou metodiku použít pro Jakou metodiku použít pro konkrétní projekt? Hodnocení a výběr vhodné metodiky pro budování IS Alena Buchalcevová Katedra informačních č technologií, VŠE Praha Agenda metodika jako nástroj zvýšení úspěšnosti

Více

Zuzana Šochová 30.10.2008. MFF Modelování a realizace softwarových projektů

Zuzana Šochová 30.10.2008. MFF Modelování a realizace softwarových projektů Zuzana Šochová 30.10.2008 1 Metody řízení projektů Týmová spolupráce Agilní metody Scrum proces Backlog úloh a odhady Jak plánovat Tým a zákazník 2 Executive support User involvement Experienced project

Více

Agile Software Development

Agile Software Development Agile Software Development Agile Software Development Jiri Fabian www.jirifabian.net O čem to bude O metodologiích RUP Agile XP Scrum Co je softwarový vývoj Umění? Manufaktura? Modelování? Co je softwarový

Více

METODIKA FEATURE-DRIVEN DEVELOPMENT NEOPOUŠTÍ MODELOVÁNÍ A PROCESY, A PŘESTO PŘINÁŠÍ VÝHODY AGILNÍHO VÝVOJE ing. Alena Buchalcevová, Ph.

METODIKA FEATURE-DRIVEN DEVELOPMENT NEOPOUŠTÍ MODELOVÁNÍ A PROCESY, A PŘESTO PŘINÁŠÍ VÝHODY AGILNÍHO VÝVOJE ing. Alena Buchalcevová, Ph. METODIKA FEATURE-DRIVEN DEVELOPMENT NEOPOUŠTÍ MODELOVÁNÍ A PROCESY, A PŘESTO PŘINÁŠÍ VÝHODY AGILNÍHO VÝVOJE ing. Alena Buchalcevová, Ph.D Katedra informačních technologií VŠE Praha nám. W.Churchilla 4,

Více

Metodický rámec budování IS/ICT

Metodický rámec budování IS/ICT Metodický rámec budování IS/ICT Alena Buchalcevová Katedra informačních technologií VŠE Praha nám. W. Churchilla 4, 30 00 Praha 3 email: buchalc@vse.cz Abstrakt Článek popisuje metodický rámec pro budování

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

Systém managementu jakosti ISO 9001

Systém managementu jakosti ISO 9001 Systém managementu jakosti ISO 9001 Požadavky na QMS Organizace potřebují prokázat: schopnost trvale poskytovat produkt produkt splňuje požadavky zákazníka a příslušné předpisy zvyšování spokojenosti zákazníka

Více

Katedra informačních technologií VŠE Praha nám. W. Churchilla 4, Praha 3 E-mail: buchalc@vse.cz PODNICÍCH. 1. Úvod

Katedra informačních technologií VŠE Praha nám. W. Churchilla 4, Praha 3 E-mail: buchalc@vse.cz PODNICÍCH. 1. Úvod Citace: BUCHALCEVOVÁ, Alena. Zlepšování softwarových procesů ve velmi malých podnicích. Liberec 06.11.2008 07.11.2008. In: Liberecké informatické fórum. Liberec : TU, 2008, s. 12 19. ISBN 978-80-7372-408-5.

Více

AGILNÍ METODIKY A SPRÁVA POŽADAVKŮ

AGILNÍ METODIKY A SPRÁVA POŽADAVKŮ Citace: BUCHALCEVOVÁ, Alena. Agilní metodiky a správa požadavků. Ostrava 04.06.2007 06.06.2007. In: Tvorba softwaru 2007. Ostrava : Ekonomická fakulta VŠB TU, 2007, s. 16 23. ISBN 978-80-248-1427-8. AGILNÍ

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

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

ČÍM MOHOU PŘISPĚT NEJZÁMĚJŠÍ AGILNÍ METODIKY KE ZLEPŠENÍ VÝVOJOVÉHO PROCESU?

ČÍM MOHOU PŘISPĚT NEJZÁMĚJŠÍ AGILNÍ METODIKY KE ZLEPŠENÍ VÝVOJOVÉHO PROCESU? ČÍM MOHOU PŘISPĚT NEJZÁMĚJŠÍ AGILNÍ METODIKY KE ZLEPŠENÍ VÝVOJOVÉHO PROCESU? HOW WELL-KNOWN AGILE METHODOLOGIES CAN CONTRIBUTE TO A SOFTWARE DEVELOPMENT PROCESS? Robert Pergl, Zdeněk Struska Abstrakt:

Více

Jak postupovat při hodnocení jakosti softwarových produktů

Jak postupovat při hodnocení jakosti softwarových produktů Jak postupovat při hodnocení jakosti softwarových produktů Jiří Vaníček Česká zemědělská univerzita v Praze, Provozně ekonomická fakulta, Katedra informačního inženýrství Tento příspěvek byl zpracován

Více

Citace článku. Alena Buchalcevová, Jan Kučera. Katedra informačních technologií VŠE Praha nám. W.Churchilla 4, Praha 3

Citace článku. Alena Buchalcevová, Jan Kučera. Katedra informačních technologií VŠE Praha nám. W.Churchilla 4, Praha 3 Citace článku BUCHALCEVOVÁ, Alena, KUČERA, Jan. Hodnocení metodik vývoje informačních systémů z pohledu testování. Systémová integrace, 2008, roč. 15, č. 2, s. 42 54. ISSN 1210-9479 Hodnocení metodik vývoje

Více

ČESKÁ TECHNICKÁ NORMA

Č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

Více

Agilní metodiky vývoje softwaru

Agilní metodiky vývoje softwaru vývoje softwaru : důraz na průběžnou komunikaci mezi vývojovým týmem a zákazníkem důraz na tvorbu kvalitního kódu a funkcí, které mají přímou obchodní hodnotu pro zákazníka týmovou spolupráci a samoorganizaci

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

ČESKÁ TECHNICKÁ NORMA

Č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

Více

Vývoj IS. Vladimíra Zádová, KIN, EF TUL- ISN3

Vývoj IS. Vladimíra Zádová, KIN, EF TUL- ISN3 Vývoj IS Metodika Metoda Nástroje Technika Životní cyklus Etapy Přístupy k vývoji Základní alternativy vývoje a provozu Integrace Doporučený souhrn etap, přístupů, zásad, postupů, pravidel, metod, technik,

Více

Analýza a Návrh. Analýza

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

Více

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

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

Více

WS PŘÍKLADY DOBRÉ PRAXE

WS PŘÍKLADY DOBRÉ PRAXE WS PŘÍKLADY DOBRÉ PRAXE ISO 9001 revize normy a její dopady na veřejnou správu Ing. Pavel Charvát, člen Rady pro akreditaci Českého institutu pro akreditaci 22.9.2016 1 ISO 9001 revize normy a její dopady

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

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

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 21. Otázka : Softwarový process. Jeho definice, modely a vyspělostní úrovně. Standardizovaný přístup pomocí RUP (Rational Unified Process). Obsah :

Více

EXIN Agile Scrum Foundation Příručka ke zkoušce. Vydání

EXIN Agile Scrum Foundation Příručka ke zkoušce. Vydání EXIN Agile Scrum Foundation Příručka ke zkoušce Vydání 201608 Copyright 2016 EXIN Všechna práva vyhrazena. Žádná část této publikace nesmí být zveřejněna, reprodukována, kopírována nebo uložena v systému

Více

Procesy, procesní řízení organizace. Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje

Procesy, procesní řízení organizace. Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje Procesy, procesní řízení organizace Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje Co nového přináší ISO 9001:2008? Vnímání jednotlivých procesů organizace jako prostředku a nástroje

Více

Co musí zahrnovat dokumentace systému managementu kvality? 1 / 5

Co musí zahrnovat dokumentace systému managementu kvality? 1 / 5 ISO 9000:2005 definuje třídu jako 1) kategorie nebo pořadí dané různým požadavkem na kvalitu produktů, procesů nebo systémů, které mají stejné funkční použití 2) kategorie nebo pořadí dané různým požadavkům

Více

Přehled rolí v jednotlivých metodikách

Přehled rolí v jednotlivých metodikách 4IT421 Zlepšování procesů budování informačních systémů Přehled rolí v jednotlivých metodikách RUP pro velké projekty, RUP pro malé projekty, OpenUP, MMSP, Scrum, XP Bc. Kamila Langrová (xlank10) ZS 2013/2014

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

XINF1. Jaroslav Žáček jaroslav.zacek@osu.cz

XINF1. Jaroslav Žáček jaroslav.zacek@osu.cz XINF1 Jaroslav Žáček jaroslav.zacek@osu.cz Tutoriály 24.10. - 3h 6.11. - 2,2h 27.11. - 1,5h Tutoriály budeme věnovat nejen teorii, ale také cvičení a workshopům. Přečtěte si skripta dříve, než týden před

Více

A7B36SI2 Tematický okruh SI11 Revidoval: Martin Kvetko

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

Více

2 Životní cyklus programového díla

2 Životní cyklus programového díla 2 Životní cyklus programového díla Typické etapy: 1. Specifikace požadavků - specifikace problému - analýza požadavků 2. Vývoj programu - návrh - kódování (programování) 3. Verifikace a validace 4. Provoz

Více

Systémy řízení EMS/QMS/SMS

Systémy řízení EMS/QMS/SMS Systémy řízení EMS/QMS/SMS Ústí nad Labem 10/2014 Ing. Jaromír Vachta Systém řízení EMS Systém environmentálního managementu Systém řízení podle ČSN EN ISO 14001:2004 Podstata EMS - detailní informace

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

Výběr vhodné metodiky vývoje softwaru pro společnost HOUR, spol. s r.o.

Výběr vhodné metodiky vývoje softwaru pro společnost HOUR, spol. s r.o. Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze Simona Dlugošová Výběr vhodné metodiky vývoje softwaru pro společnost HOUR, spol. s r.o.

Více

Systémy řízení QMS, EMS, SMS, SLP

Systémy řízení QMS, EMS, SMS, SLP Systémy řízení QMS, EMS, SMS, SLP Ústí nad Labem 11/2013 Ing. Jaromír Vachta Systém řízení QMS Systém managementu kvality Systém řízení podle ČSN EN ISO 9001:2009 - stanovení, pochopení a zajištění plnění

Více

Předmluva 11. Poděkování 11 O autorech 12 Úvodem 12 Komu je tato kniha určena 13 Jak byste měli tuto knihu číst 13 Web 14

Předmluva 11. Poděkování 11 O autorech 12 Úvodem 12 Komu je tato kniha určena 13 Jak byste měli tuto knihu číst 13 Web 14 Obsah Předmluva 11 Poděkování 11 O autorech 12 Úvodem 12 Komu je tato kniha určena 13 Jak byste měli tuto knihu číst 13 Web 14 KAPITOLA 1 Úvod do architektury softwaru 15 Použití procesu 16 Stručný popis

Více

MANAŽER KVALITY PŘEHLED POŽADOVANÝCH ZNALOSTÍ K HODNOCENÍ ZPŮSOBILOSTI CO 4.4/2007

MANAŽER KVALITY PŘEHLED POŽADOVANÝCH ZNALOSTÍ K HODNOCENÍ ZPŮSOBILOSTI CO 4.4/2007 Gradua-CEGOS, s.r.o., Certifikační orgán pro certifikaci osob č. 3005 akreditovaný Českým institutem pro akreditaci, o.p.s. podle ČSN EN ISO/IEC 17024 MANAŽER KVALITY PŘEHLED POŽADOVANÝCH ZNALOSTÍ K HODNOCENÍ

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

[ 1 ] Ing. František Chuchma, CSc. Seminář SVP/SDP, Státní ústav kontrolu léčiv

[ 1 ] Ing. František Chuchma, CSc. Seminář SVP/SDP, Státní ústav kontrolu léčiv [ 1 ] [ 2 ] VYR-32 verze 4 kapitola 1 Farmaceutický systém jakosti The Rules Governing Medicinal Products in EU, EU Guidelines to GMP, Chapter 1 Platnost od 31.1.2013 Právní základ: čl.47 Směrnice Evropského

Více

Problematikou logistiky v oblasti řízení jakosti se zabývají normy ISO řady Dotýká se oblastí: Manipulace, uskladnění, označování, balení,

Problematikou logistiky v oblasti řízení jakosti se zabývají normy ISO řady Dotýká se oblastí: Manipulace, uskladnění, označování, balení, Problematikou logistiky v oblasti řízení jakosti se zabývají normy ISO řady 9000. Dotýká se oblastí: Manipulace, uskladnění, označování, balení, uvedení do provozu a dodání, servis po prodeji... a dále

Více

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Osnova přednášky Co to je softwarové inženýrství Softwarový proces Metodika a metoda Evoluce softwarových

Více

Agilní metodiky Agilní Jan Smolík

Agilní metodiky Agilní Jan Smolík Agilní metodiky Jan Smolík Kritéria pro členění metodik Zaměření metodiky Rozsah metodiky Váha metodiky Typ řešení Doména Zaměření metodiky Globální metodiky (Enterprise Methodologies) Zaměřené na komplexní

Více

Agile. nejžádanější způsob vývoje software. Tomáš Tureček. Business consultant, Lean&Agile coach Tieto tomas.t.turecek@tieto.com

Agile. nejžádanější způsob vývoje software. Tomáš Tureček. Business consultant, Lean&Agile coach Tieto tomas.t.turecek@tieto.com 2010 Tieto Corporation Agile nejžádanější způsob vývoje software Tomáš Tureček Business consultant, Lean&Agile coach Tieto tomas.t.turecek@tieto.com 2012 Tieto Corporation Tieto Aktivity ve více než 20

Více

Česká letecká servisní a. s.

Česká letecká servisní a. s. Česká letecká servisní a. s. 1/20 Česká letecká servisní a. s. Your integrator of the avionics Česká letecká servisní a. s. Úvod do RTCA-DO178B Česká letecká servisní a. s. 2/20 Co je RTCA-DO178B RTCA-DO178B,

Více

Stav používání agilních metodik v ČR

Stav používání agilních metodik v ČR Alena Buchalcevová Katedra informačních technologií Vysoká škola ekonomická v Praze buchalc@vse.cz Abstrakt: Tradiční rigorózní metodiky vývoje softwaru přestávají v prostředí neustálých změn vyhovovat

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

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

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

Jan Hřídel Regional Sales Manager - Public Administration

Jan Hřídel Regional Sales Manager - Public Administration Podpora kvality ICT ve veřejné správě pohledem Telefónica O2 4. Národní konference kvality Karlovy Vary Jan Hřídel Regional Sales Manager - Public Administration Obsah 1. Strategie v ICT využití metody

Více

1. VYMEZENÍ ODBORNÉ STÁŽE

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í

Více

Hodnocení železničních systémů podle Evropských standardů. Doc. Dr. Ing. Tomáš Brandejský Ing. Martin Leso, PhD Fakulta dopravní ČVUT v Praze

Hodnocení železničních systémů podle Evropských standardů. Doc. Dr. Ing. Tomáš Brandejský Ing. Martin Leso, PhD Fakulta dopravní ČVUT v Praze Hodnocení železničních systémů podle Evropských standardů Doc. Dr. Ing. Tomáš Brandejský Ing. Martin Leso, PhD Fakulta dopravní ČVUT v Praze Obecné požadavky Přechod do bezpečnějšího stavu při poruše Náhodné

Více

Praktické zkušenosti s nasazením agilní metodiky SCRUM při vývoji středně rozsáhlého softwarového projektu. Dušan Juhás

Praktické zkušenosti s nasazením agilní metodiky SCRUM při vývoji středně rozsáhlého softwarového projektu. Dušan Juhás Praktické zkušenosti s nasazením agilní metodiky SCRUM při vývoji středně rozsáhlého softwarového projektu. Dušan Juhás Motivace Vybrali jsme nový webový framework a potřebovali ho ověřit na reálné aplikaci

Více

Association for the advancement of Cost Engineering International (AACE) Australian Institute of Project Management (AIPM) English Association of

Association for the advancement of Cost Engineering International (AACE) Australian Institute of Project Management (AIPM) English Association of Association for the advancement of Cost Engineering International (AACE) Australian Institute of Project Management (AIPM) English Association of Project Managers (APM) Association for Project Management

Více

Řízení reálných projektů, agilní metodiky

Řízení reálných projektů, agilní metodiky Agent Technology Group Katedra kybernetiky Fakulta elektrotechnická - České vysoké učení technické Praha, 2009 Osnova Lze vyvíjet software bez metodiky? - bohužel ano menší komerční firmy (zejména vývoj

Více

Úvod. Projektový záměr

Úvod. Projektový záměr Vzdělávací program Řízení jakosti a management kvality Realizátor projektu: Okresní hospodářská komora Karviná Kontakt: Svatováclavská 97/6 733 01 KARVINÁ +420 596 311 707 hkok@hkok.cz www.akademieok.cz

Více

Projektové řízení. Lenka Švecová, Tomáš Říčka. University of Economics, Prague. Project management for SMEs/NGOs - exchange of experience for trainers

Projektové řízení. Lenka Švecová, Tomáš Říčka. University of Economics, Prague. Project management for SMEs/NGOs - exchange of experience for trainers Project management for SMEs/NGOs - exchange of experience for trainers LLP Grundtvig Learning Partnership Projektové řízení Lenka Švecová, Tomáš Říčka University of Economics, Prague This project has been

Více

KIV/ASWI 2007/2008 Pokročilé softwarové inženýrství. Cíle předmětu Organizační informace Opakování

KIV/ASWI 2007/2008 Pokročilé softwarové inženýrství. Cíle předmětu Organizační informace Opakování KIV/ASWI 2007/2008 Pokročilé softwarové inženýrství Přemysl Brada Cíle předmětu Organizační informace Opakování Cíl předmětu Praktické zkušenosti sw proces a iterativní vývoj jaksi mimochodem

Více

Vazba na Cobit 5

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

Více

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

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

Více

VŠEOBECNÉ NÁKUPNÍ PODMÍNKY - DOHODA O ZAJIŠTĚNÍ JAKOSTI

VŠEOBECNÉ NÁKUPNÍ PODMÍNKY - DOHODA O ZAJIŠTĚNÍ JAKOSTI VŠEOBECNÉ NÁKUPNÍ PODMÍNKY - DOHODA O ZAJIŠTĚNÍ JAKOSTI 1 - Rozsah platnosti Tyto všeobecné nákupní podmínky (dále jen podmínky ) platí pro veškeré kupní smlouvy, v nichž společnost TOMATEX Otrokovice,

Více

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

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

Více

Aplikace metodiky hodnocení kvality systému elektronické výměny dat mezi podnikem a státní správou

Aplikace metodiky hodnocení kvality systému elektronické výměny dat mezi podnikem a státní správou Aplikace metodiky hodnocení kvality systému elektronické výměny dat mezi podnikem Miloš Ulman 1, Zdeněk Havlíček 2, Pavel Šimek 3 Česká zemědělská univerzita, Provozně ekonomická fakulta Katedra informačních

Více

Vážení zákazníci, odběratelé, obchodní přátelé, občané, akcionáři, kolegové

Vážení zákazníci, odběratelé, obchodní přátelé, občané, akcionáři, kolegové Vážení zákazníci, odběratelé, obchodní přátelé, občané, akcionáři, kolegové Společnost Vodovody a kanalizace Hodonín, a.s. zaměřuje svou hlavní pozornost na maximální uspokojování potřeb svých zákazníků

Více

SMĚRNICE DĚKANA Č. 4/2013

SMĚRNICE DĚKANA Č. 4/2013 Vysoké učení technické v Brně Datum vydání: 11. 10. 2013 Čj.: 076/17900/2013/Sd Za věcnou stránku odpovídá: Hlavní metodik kvality Za oblast právní odpovídá: --- Závaznost: Fakulta podnikatelská (FP) Vydává:

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

Hodnotocentrické metodiky

Hodnotocentrické metodiky 2 Hodnotocentrické metodiky Vyšší management Projektový manažer Jedna metodika těžko bude tou jedinou správnou,... pro každý projekt a realizační tým existuje jiný správný způsob práce. 1 Alistair Cockburn

Více

Gradua-CEGOS, s.r.o. člen skupiny Cegos MANAŽER KVALITY PŘEHLED POŽADOVANÝCH ZNALOSTÍ K HODNOCENÍ ZPŮSOBILOSTI

Gradua-CEGOS, s.r.o. člen skupiny Cegos MANAŽER KVALITY PŘEHLED POŽADOVANÝCH ZNALOSTÍ K HODNOCENÍ ZPŮSOBILOSTI Gradua-CEGOS, s.r.o. člen skupiny Cegos Gradua-CEGOS, s.r.o., Certifikační orgán pro certifikaci osob č. 3005 akreditovaný Českým institutem pro akreditaci, o.p.s. podle ČSN EN ISO/IEC 17024 MANAŽER KVALITY

Více

Kvalita procesu vývoje SW. Jaroslav Žáček jaroslav.zacek@osu.cz

Kvalita procesu vývoje SW. Jaroslav Žáček jaroslav.zacek@osu.cz Kvalita procesu vývoje SW Jaroslav Žáček jaroslav.zacek@osu.cz Vývoj software a jeho kvalita Samotný vývoj je rozsáhlá a složitá disciplína. Většina SW projektů (v průměru 70 %) je podhodnocena či zpožděna.

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

PROCESY CO ZÍSKÁTE: Předpoklad pro certifikace ISO. Lean Six Sigma Fast Track

PROCESY CO ZÍSKÁTE: Předpoklad pro certifikace ISO. Lean Six Sigma Fast Track PROCESY CO ZÍSKÁTE: Jasná pravidla pro provádění činností, uložení know-how Jasně definované zodpovědnosti za celý proces i jednotlivé kroky Zprůhlednění organizace plynoucí z jasně definovaných vstupů,

Více

Cobit 5: Struktura dokumentů

Cobit 5: Struktura dokumentů Cobit 5: Struktura dokumentů Cobit 5 Framework; popisuje základní rámec (principy, předpoklady, vazby na jiné rámce), Cobit 5 Enabler Guides; jde o dokumenty, které jsou obecným návodem na vytváření předpokladů

Více

AUDITOR KVALITY PŘEHLED POŽADOVANÝCH ZNALOSTÍ K HODNOCENÍ ZPŮSOBILOSTI CO 4.5/2007

AUDITOR KVALITY PŘEHLED POŽADOVANÝCH ZNALOSTÍ K HODNOCENÍ ZPŮSOBILOSTI CO 4.5/2007 Gradua-CEGOS, s.r.o., Certifikační orgán pro certifikaci osob č. 3005 akreditovaný Českým institutem pro akreditaci, o.p.s. podle ČSN EN ISO/IEC 17024 AUDITOR KVALITY PŘEHLED POŽADOVANÝCH ZNALOSTÍ K HODNOCENÍ

Více

Projektová dokumentace pro tvorbu internetových aplikací

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

Více

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

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

Více

Výukový materiál zpracovaný v rámci projektu Výuka moderně

Výukový materiál zpracovaný v rámci projektu Výuka moderně Střední průmyslová škola strojnická Olomouc, tř. 17. listopadu 49 Výukový materiál zpracovaný v rámci projektu Výuka moderně Registrační číslo projektu: CZ.1.07/1.5.00/34.0205 Šablona: III/2Management

Více

Design systému. Komponentová versus procesní architektura

Design systému. Komponentová versus procesní architektura Design systému Komponentová versus procesní architektura Architektura : třídy statické aspekty propojení logický pohled struktura popisu systému Architektura procesů: objekty dynamické aspekty koordinace

Více

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

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

Více

SOUBOR OTÁZEK PRO INTERNÍ AUDIT (Checklist)

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

Více

Otázky kurzu 4IT417 Řízení podnikové informatiky verze z 1/2/2009. 1.Podniková informatika pojmy a komponenty

Otázky kurzu 4IT417 Řízení podnikové informatiky verze z 1/2/2009. 1.Podniková informatika pojmy a komponenty Otázky kurzu 4IT417 Řízení podnikové informatiky verze z 1/2/2009 1.Podniková informatika pojmy a komponenty (1) Objasněte pojmy: IS, ICT, ICT služba, ICT proces, ICT zdroj. Jakou dokumentaci k ICT službám,

Více

ČESKÁ TECHNICKÁ NORMA

Č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

Více

Systém kvality ve společnosti STAVITELSTVÍ KAREL VÁCHA A SYN s.r.o.

Systém kvality ve společnosti STAVITELSTVÍ KAREL VÁCHA A SYN s.r.o. Systém kvality ve společnosti STAVITELSTVÍ KAREL VÁCHA A SYN s.r.o. Stavba : KAPITANÁT REALIZACE STAVBY PROVOZNÍ INFRASTRUKTURY SPORTOVNÍHO PŘÍSTAVU HLUBOKÁ NAD VLTAVOU 1. Organizace uplatňuje integrovaný

Více

Výtisk č. : Platnost od: Schválil: Podpis:

Výtisk č. : Platnost od: Schválil: Podpis: SM-05 INTERNÍ AUDITY Výtisk č. : Platnost od: Schválil: Podpis: 1 OBSAH Číslo kapitola strana 1 OBSAH... 2 2 PŘEHLED ZMĚN A REVIZÍ... 2 3 ÚČEL... 2 3.1 ROZSAH PLATNOSTI... 3 3.2 DEFINICE... 3 3.3 POUŽITÉ

Více

ČESKÁ TECHNICKÁ NORMA

ČESKÁ TECHNICKÁ NORMA ČESKÁ TECHNICKÁ NORMA ICS 35.240.70 2003 Geografická informace - Časové schéma ČSN ISO 19108 97 9827 Prosinec Geographic information - Temporal schema Information géographique - Schéma temporel Tato norma

Více

8/2.1 POŽADAVKY NA PROCESY MĚŘENÍ A MĚŘICÍ VYBAVENÍ

8/2.1 POŽADAVKY NA PROCESY MĚŘENÍ A MĚŘICÍ VYBAVENÍ MANAGEMENT PROCESŮ Systémy managementu měření se obecně v podnicích používají ke kontrole vlastní produkce, ať už ve fázi vstupní, mezioperační nebo výstupní. Procesy měření v sobě zahrnují nemalé úsilí

Více

Vnitřní kontrolní systém a jeho audit

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

Více

POŽADADAVKY NA ORGANIZACI SYSTÉMU SPOLEČENSKÉ ODPOVĚDNOSTI (ZÁKLADNÍ INFORMACE)

POŽADADAVKY NA ORGANIZACI SYSTÉMU SPOLEČENSKÉ ODPOVĚDNOSTI (ZÁKLADNÍ INFORMACE) Příloha A (Informativní) POŽADADAVKY NA ORGANIZACI SYSTÉMU SPOLEČENSKÉ ODPOVĚDNOSTI (ZÁKLADNÍ INFORMACE) 1. MODEL SYSTÉMU MANAGEMENTU SPOLEČENSKÉ ODPOVĚDNOSTI FIRMY Současný pohled na problematiku společenské

Více

ČSN ISO/IEC 27001:2014 a zákon o kybernetické bezpečnosti

Č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

Více

Nebojte se přiznat, že potřebujete SQA

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

Více

Manažerská ekonomika

Manažerská ekonomika PODNIKOVÝ MANAGEMENT (zkouška č. 12) Cíl předmětu Získat znalosti zákonitostí úspěšného řízení organizace a přehled o současné teorii a praxi managementu. Seznámit se s moderními manažerskými metodami

Více

Řízení kvality softwaru

Řízení kvality softwaru Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod Řízení kvality softwaru Diplomová práce Autor: Bc. Karel Volena Informační technologie a management Vedoucí práce: doc.

Více

Metodiky vývoje software, MDA

Metodiky vývoje software, MDA Metodiky vývoje software, MDA Karel Richta Katedra softwarového inženýrství Fakulta informačních technologií České vysoké učení technické v Praze richta@fel.cvut.cz, 2011 Softwarové inženýrství I., BI-SI1

Více

Věc: Strategie EZÚ pro přechodné období zavádění změn normy ISO 9001:2008

Věc: Strategie EZÚ pro přechodné období zavádění změn normy ISO 9001:2008 Váš dopis značky / ze dne Naše značka Vyřizuje/linka Praha Věc: Strategie EZÚ pro přechodné období zavádění změn normy ISO 9001:2008 Vážení přátelé, ISO (Mezinárodní organizace pro normalizaci) a IAF (Mezinárodní

Více

ZÁSADY A POSTUPY PROJEKTOVÁNÍ, FÁZE PROJEKTOVÁNÍ

ZÁSADY A POSTUPY PROJEKTOVÁNÍ, FÁZE PROJEKTOVÁNÍ PROJEKTOVÉ ŘÍZENÍ STAVEB ZÁSADY A POSTUPY PROJEKTOVÁNÍ, FÁZE PROJEKTOVÁNÍ Vysoká škola technická a ekonomická v Českých Budějovicích Institute of Technology And Business In České Budějovice Tento učební

Více

Obsah: Základní pojmy, definice Informační systémy IT architektura Typické aplikační komponenty Implementace aplikací

Obsah: Základní pojmy, definice Informační systémy IT architektura Typické aplikační komponenty Implementace aplikací Monitorovací indikátor: 06.43.10 Počet nově vytvořených/inovovaných produktů Akce: Přednáška, KA 5 Číslo přednášky: 30 Téma: INFORMAČNÍ SYSTÉMY A ARCHITEKTURA IT V PODNIKU Lektor: Ing. Michal Beránek Třída/y:

Více

Management rizik v životním cyklu produktu

Management rizik v životním cyklu produktu Management rizik v životním cyklu produktu ČSJ Praha Milan Trčka Cyklus rizik produktu Nové ISO 9001:2015 a požadavky na management rizik Definice Riziko (3.09, Pozn. 3,4) Riziko - účinek nejistoty Riziko

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

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

P R O J E K T O V É Ř Í Z E N Í A M A R K E T I N G 1. Akad. rok 2015/2016, LS Projektové řízení a marketing - VŽ 1

P R O J E K T O V É Ř Í Z E N Í A M A R K E T I N G 1. Akad. rok 2015/2016, LS Projektové řízení a marketing - VŽ 1 P R O J E K T O V É Ř Í Z E N Í A M A R K E T I N G 1 Akad. rok 2015/2016, LS Projektové řízení a marketing - VŽ 1 Vznik a historie projektového řízení Akad. rok 2015/2016, LS Projektové řízení a marketing

Více

Bezpečnost informačních systémů a jejich kvalita

Bezpečnost informačních systémů a jejich kvalita Bezpečnost informačních systémů a jejich kvalita Marek Čandík Policejní akademie České republiky v Praze Vlastnosti informačního systému je možné charakterizovat jeho charakteristikami jakosti (quality

Více