8.1 Charakteristika testování Principy testování Testovatelnost Black-box testování White-box testování

Save this PDF as:
 WORD  PNG  TXT  JPG

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

Download "8.1 Charakteristika testování...80 8.2 Principy testování...80 8.3 Testovatelnost...81 8.4 Black-box testování...82 8.5 White-box testování...84 8."

Transkript

1 Obsah 1 Úvod Co to je softwarové inženýrství? Selhání softwarového inženýrství Životní cyklus softwarového díla Řešení problému Koncepty řízení SW projektů Základní pojmy Zralost organizace Koncepty řízení projektu Plánování a vedení projektu Softwarové mýty Plán projektu Plánování času Softwarové metriky Základní klasifikace metrik Vztahy mezi metrikami Faktory ovlivňující produktivitu tvorby softwaru Metriky kvality softwaru Odhady času, zdrojů a nákladů Popis rozsahu softwaru Schůzky se zákazníkem Plánování zdrojů Odhad ceny a pracnosti Řízení rizik Vysvětlení základních pojmů Kategorie rizik Identifikace rizik Rizika softwarového projektu Rizikové komponenty Kategorie dopadu Ohodnocení rizik Protiriziková opatření Plán řízení rizik Softwarový rizikový management podle [Boehma] Kvalita softwaru Základní pojmy Zabezpečení jakosti kvality Techniky řízení jakosti softwaru Cena za jakost Statistické přístupy k jakosti softwaru Diagram příčin a následků Chybový index Spolehlivost softwaru Benchmarking Normy ISO Techniky testování

2 8.1 Charakteristika testování Principy testování Testovatelnost Black-box testování White-box testování Testování podle základních cest Testování podle řídicí struktury Metody založené na grafu Beizer, B.: Black-Box Testing, Wiley Metoda rozdělení do tříd ekvivalencí (Equivalence Partitioning) Metoda analýzy okrajových hodnot (Boundary Value Analysis) Srovnávací testování (Comparison Testing, back-to-back testing) Testování pro speciální prostředí a aplikace Strategie testování softwaru Verifikace a validace Nesprávné názory na strategii testování Ukončení testování Testování jednotek Integrační testování Validační testování Systémové testování Řízení změn Příčiny změn Srovnávací základna Proces SCM Řízení verzí Řízení změn Audit konfigurací Projektový management Projekt Týmový management projektu Zpětné inženýrství Nástroje pro zpětné inženýrství Meze zpětného inženýrství Nástroje CASE Normy v SI IEEE Standard IEEE standard IEEE Standard IEEE Standard Příloha I Návrh, dokončení a prezentace projektu Příloha II Jazyk UML Příloha III Projekt Evidence HW Příloha IV Projekt Inteligentní domácnost

3 1 Úvod Softwarový inženýr amatér vždy hledá kouzelnou, senzační metodu nebo nástroj, jejíž aplikace slibuje triviální návrh softwaru. Profesionál ví, že takové řešení neexistuje. Grady Booch, in Object Oriented Analysis and Design 1.1 Co to je softwarové inženýrství? Disciplina softwarové inženýrství byla zavedena v roce 1968 jako odpověď na neutěšený stav vývoje softwaru. Softwarové inženýrství je disciplina, která se zabývá problematikou tvorby softwaru, který mál být vytvořen včas, v požadované kvalitě a při dodržení rozpočtu. Důraz je kladen jak na software tak na inženýrství. Můžeme říci, že softwarové inženýrství se snaží o zavedení inženýrských metod do návrhu softwaru. Čím je návrh softwaru specifický? Složitostí, komplexností a změnami. V následující tabulce je znázorněn vývoj hardwaru, softwarových nástrojů a metod softwarového inženýrství v druhé polovině dvacátého století nástroje HW SI techniky strojový kód elektronky 2000 assembler jazyky 3. generace jazyky 4. generace jazyky AI objektové programování tranzistory integrované obvody paralelní procesy VLSI strukturované programování funkcionální dekompozice strukturální analýza datová analýza objektová analýza 6

4 Z tabulky vyplývá, že první představy o systematickém přístupu k tvorbě softwaru přišly se strukturovaným programováním koncem šedesátých let. Softwarové inženýrství je: o Modelování tvorba modelu, kdy se během jeho tvorby soustředíme jen na nejnutnější detaily a ostatní zanedbáváme. V průběhu tvorby softwaru je potřeba vytvořit řadu různých modelů, které odpovídají jednotlivým pohledům na řešený úkol. o Řešení problémů modely jsou použity k hledání akceptovatelného řešení. o Získávání znalostí softwarové inženýrství sbírá data z modelů řešených problémů, ukládá je jako informace a znalosti pro řešení dalších úloh. Tento proces je nelineární a jeden špatný údaj v datech může příslušný model znehodnotit. o Racionálně vedená aktivita při získávání znalostí je nutné postupovat logicky, rozumově, aby získané informace byly přínosné, aby získané modely byly použitelné, umožňovaly změny a pomohly při nových řešeních. Softwarové inženýrství řeší problémy, hledá modely, sbírá znalosti a hledá racionální řešení. Každá z těchto aktivit je však ovlivňována lidmi, časem a rozpočtem, který má k disposici. Mimo to se v každém okamžiku mohou objevit požadavky na změny. 1.2 Selhání softwarového inženýrství Jedním ze zdrojů získávání znalostí v softwarovém inženýrství je analýza počítačových havárií. Proč studovat havárie? o Z havárií se učíme. o Analyzujeme systém v terénu. o Nemusíme havárii simulovat. o O havárii je obvykle více informací. o Při havárii nastanou situace, které se nedají předvídat a obvykle návrháře při testování nenapadnou. Uvedeme si příklady některých typických havárií. Problém typu Y2K V roce 1992 dostala paní Mary z Winona ve státě Minnesota v USA pozvánku k návštěvě mateřské školy. Pani Mary bylo v té době 104 let. Přestupný rok Supermarket dostal dne 29. února 1988 pokutu 1000 $ za to, že prodával maso, které mělo o jeden den prošlou záruční lhůtou. Program, který tiskl dobu trvanlivosti na balíčky s masem nepočítal s tím, že rok je přestupný. 7

5 Nesprávný interface 10 dubna 1990 opustil vlak podzemní dráhy v Londýně stanici bez řidiče. Řidič zmáčkl tlačítko, které startovalo vlak a spoléhal se na automatické zajištění, které neumožňovalo odjezd vlaku s otevřenými dveřmi. Protože se dveře zpříčily a nebylo je možné zavřít automaticky, vystoupil řidič z vlaku aby dveře uvolnil. Jakmile se tak stalo, vlak jednoduše odjel bez řidiče. Bezpečnost 2 listopadu 1988 byl do Internetu vypuštěn virus, který dnes označujeme jako internetový červ. Virus využil zranitelnosti některých síťových služeb jako např. Unixové posílání pošty a začal se nekontrolovaně šířit. Výsledkem bylo napadení asi 10 % procent všech internetových počítačových uzlů, kde zaplnil celou paměť a způsobil výpadek počítače. Trvalo několik dnů než byly problémy odstraněny. Překročení rozpočtu a pozdní dodání V roce 1995 chyba v automatickém systému kontroly zavazadel na novém letišti v Denveru způsobila ničení zavazadel. Letiště bylo uzavřeno a znovu otevřeno až po 16 měsících, kdy rozpočet na dodání systému byl překročen o 3,2 miliardy dolarů a manipulace se zavazadly byly prováděny převážně ručně. Dodání včas Za 18 měsíců a 200 milionů dolarů byl v roce 1984 předán systém pro zdravotní pojišťovnu ve Wisconsinu. Systém však nikdy nepracoval dobře. Bylo zjištěno přeplacení účtů o 60 milionů dolarů a trvalo další tři roky systém opravit. Zbytečná složitost Přepravní letoun C-17 firmy McDonnell Douglas překročil rozpočet o 500 milionů dolarů, protože byly problémy v navigačním systému. Vybavení letounu mělo na palubě 19 počítačů, 80 mikroprocesorů a při jeho implementaci bylo použito 6 různých programovacích jazyků. Havárie záchranné služby v Londýně Ukážeme si podrobnější rozbor jedné počítačové havárie. Londýnský záchranný systém byl navržen počátkem devadesátých let a měl být plně automatický. Základní částí systému byla počítačem podporovaná pomoc, vozidla záchranné služby byly automaticky naváděny, řidiči měli na palubě počítačovou mapu a hlasová komunikace byla založena na radiovém spojení. Dne 26. a 27. října 1992 se systém zhroutil. Řidiči nevěděli kde jsou. K jednomu případu vyjelo několik vozidel. V řídícím centru byl přeplněné kontrolní obrazovky a přetížené telefony. Bylo přetížené radiové spojení. Při zavolání služby byla odpověď až za 10 minut, přičemž pouze 20% volání bylo úspěšných. Vznikla situace, která ohrožovala lidské životy. 8

6 Co způsobilo havárii? o Nesmyslný návrh Zadání projektu bylo , ukončení výběrového řízení , implementace systému konec roku 1991, smlouva s dodavatelem podepsána v srpnu 1991, systém předán o Nezkušenost Celkem se o projekt ucházelo 17 realizátorů. Oborníci, kteří prováděli analýzu zadání doporučovali, aby byl požadován úplný systém za 1,5 milionů s dobou zpracování 18 měsíců. Byl akceptován neúplný systém za , který byl dodán za 5 měsíců. Firma, která získala zakázku použila CASE (Computer Aided Software Engineering) systém, který se učila, nikdy podobný systém nerealizovala a na tvorbu systému měla v době zadání o Mnoho automatizace Lokalizace vozidel byla přímo podle hlášení případů, personál řídícího centra zasahoval až po 11 minutách. Nebyla žádná písemná dokumentace. Předpokládala se stoprocentní spolupráce řidičů záchranných vozidel, přitom řidiči nebyli dostatečné ohodnoceni. o Uživatelské problémy Posádky vozů nebyly při tvorbě systému konzultovány. Uživatelé byli vyškoleni dříve, než byl systém realizován. Systém neakceptoval prioritu operátorů v centru. Špatná lokalizace byl mnohem častější než při předchozí hlasové komunikaci s operátory. o Neadekvátní komunikační systém a softwarové chyby - Na kontrolních obrazovkách bylo mnoho informací, které však nebyly pro nedostatek paměti ukládány. V kritické dny nebyli ve službě žádní záložní operátoři. Systém byl uveden do provozu se dvěma vážnými a 44 malými chybami. Programátoři zapomněli odstranit část ladicích tisků, která způsobila ztrátu informací na serverech. Celý systém byl napsán ve variantě programovacího jazyku Basic. o Špatný uživatelský interface Zprávy rolovaly po obrazovce a nebylo je možné zastavit, posádka vozu mohla velmi snadno na ovládacím panelu zmáčknout špatný knoflík, tiskárny bylo možné vypnout, aniž se zprávy někde ukládaly. o Špatný management projektu Nikdo nechtěl projekt vést, nikdo nepracoval na projektu na plný úvazek, programátoři nezvládli použitý CASE nástroj, softwarové změny se prováděly za pochodu, celý systém nebyl nikdy předem otestován. K uvedenému příkladu není co dodat. Řada chyb při návrhu a realizaci projektu se nám může zdát nepochopitelná, můžeme se domnívat, že nám by se nic podobného nemohlo stát. Praxe ukazuje, že tomu je právě naopak. 9

7 1.3 Životní cyklus softwarového díla V předchozí části jsme specifikovali softwarové inženýrství mimo jiné jako modelování. Základními modely jsou modely životního cyklu SW díla. Všechny modely mají některé společné základní aktivity, kterými jsou: 1. Specifikace. Definujeme především funkce a omezení systému. 2. Návrh a implementace. Snaha o vytvoření systému, který splňuje specifikace. 3. Validace softwaru. Software musí být testován tak, aby se prokázalo, že splňuje požadavky zadavatele. 4. Evoluce softwaru. Software se musí vyvíjet tak, aby byl schopen uspokojit potřeby zákazníka v případě změn. Životní cyklus zahrnuje i další činnosti : o řízení projektu o analýzu o návrh o implementaci o zajištění kvality o údržbu Příklady modelů životního cyklu softwarového díla: o Model vodopád- Jednotlivé aktivity jsou zpracovány jako nezávislé procesy, které na sebe navazují. o Evoluční model Tento přístup prokládá jednotlivé etapy realizace kontrolou se zákazníkem a jejich paralelním zpracováním tak, aby se postupné verze realizovaného systému co nejrychleji blížily požadavkům zákazníka. o Formální návrh Tento přístup je založen na vytvoření formálního matematického modelu specifikace systému, který je převeden do programové podoby.verifikace systému je odvozena z matematického dokazování specifikací. o Znovupoužití vývoje Tento přístup je založen na faktu, že existuje značné množství komponent do nově vytvářeného systému. 1.4 Řešení problému Při řešení problému bychom si měli nejprve odpovědět na základní otázku softwarové inženýrství. 10

8 Ne vždy je potřeba navrhovat a realizovat nový systém. Stále častěji se setkáváme s řešeními, kdy výsledný produkt skládáme z již hotových nebo upravených modulů. Aktivity, spojené s řešením problému můžeme shrnout do pěti kroků: formulace problému analýza problému hledání řešení volba vhodného řešení řešení Koupit? Přebudovat? Znovupoužít? Navrhnout a realizovat? Vazby mezi jednotlivými aktivitami jsou uvedeny v obrázku 1.1 projekt * aktivity produkt systém je vytvořen spotřebovává * * úkol * účastník zdroje model čas dokument vybavení Obr 1.1 Důsledkem uvedených skutečností je, že o průměrně 50% velkých projektů trvá déle než bylo odhadováno, o tři čtvrtiny velkých projektů má provozní chyby, o jedna čtvrtina velkých projektů je zrušena. 11

9 2 Koncepty řízení SW projektů 2.1 Základní pojmy Než si řekneme které jsou nejdůležitější prvky řízení při práci na softwarových projektech, zavedeme si základní pojmy, bez kterých se při výkladu neobejdeme. Projekt je časově ohraničené úsilí vynaložené s cílem vytvořit jedinečný výsledek (produkt). Proces je ucelený sled činností, který má na výstupu měřitelný výsledný produkt. Produkt může být hmotný (výrobek) nebo nehmotný (informace) nebo to může být služba. Softwarové inženýrství je systematický, disciplinovaný a kvalifikovaný přístup k vývoji, provádění a údržbě softwaru. definice IEEE Zralost organizace Organizace, které realizují softwarové projekty, jsou na tuto činnost různě připraveny a vybaveny. Softwarové inženýrství je založeno na předchozích zkušenostech a informacích. Čím více jich organizace má, tím lépe je na realizaci projektu připravena. Z pohledu připravenosti organizace rozeznáváme několik úrovní a mluvíme v této souvislosti o úrovni zralosti organizace. Pět základních úrovní zralosti organizace je: 1. Počáteční - SW proces je prováděn ad hoc, příležitostně až chaoticky. Několik procesů je definováno, případné úspěchy závisí na osobním úsilí. 2. Opakovatelná - Jsou zavedeny základní procesy řízení projektu. Je snaha opakovat procesy úspěšných projektů podobných aplikací. 12

10 3. Definovaná - SW proces jak z hlediska řízení tak i z hlediska SI je dokumentován, standardizován a integrován do ostatních procesů organizace. 4. Řízená - Jsou prováděna podrobná měření kvality SW procesu a produktu. 5. Optimalizovaná - Soustavné zdokonalování procesů využívá kvantitativní zpětnou vazbu z procesů a testů nových myšlenek a technologií. 2.3 Koncepty řízení projektu Při realizaci projektu organizací, je nutné sledovat tři základní oblasti: o Lidé - práce s lidmi. o Problém - pochopení řešeného problému. Špatným pochopením problému může vzniknout sice elegantní řešení, ale pro jiný problém. o Proces - sledování procesu. Proces je nutné připravit, naplánovat, kontrolovat a řídit. Lidé Nejdůležitějším předpokladem pro úspěšný softwarový projekt je výběr vysoce kvalifikovaných odborníků. Role lidí, kteří ovlivňují softwarový proces o vrcholový management o manažer projektu o pracovníci o zákazníci o koncoví uživatelé Úloha manažera projektu : o komunikace se zákazníkem o plánování projektu o řízení rozpočtu o výběr řešitelů o kontrola stavu projektu o prezentace výsledků Schopnosti manažera projektu: o řešení problémů o identifikace o aktivita o vliv a budování týmu 13

11 Organizace týmu Existují tři základní typy organizace týmů pro tvorbu softwaru: 1. n osob je přiřazeno k m různým úkolům, vyskytuje se jen relativně malá společná část, kterou je třeba koordinovat 2. n osob je přiřazeno k m různým úkolům, m<n. Vznikají neformální týmy a ad hoc vedoucí týmu. Koordinaci řídí softwarový manažer. 3. n osob organizovaných do t týmů, každý má jeden či více úkolů, pracují na jednom projektu. Koordinaci provádí projektový manažer. Vhodná struktura týmu závisí na o stylu řízení o počtu pracovníků a jejich dovednostech o složitosti problému Rozeznáváme tři typy týmové struktury: DD - decentralizovaně demokratická Rozhodnutí se provádí na základě skupinového konsensu. Komunikace uvnitř týmu je horizontální. CD - řízeně decentralizovaná Je určen vedoucí týmu (případně vedoucí podskupin), který koordinuje úkoly. Řešení problému se provádí ve skupině. Komunikace mezi podskupinami a individui je horizontální. Vedle toho existuje ještě vertikální komunikace. CC řízeně centralizovaná Problémy se řeší na vrcholové úrovni, vnitřní koordinaci řídí vedoucí týmu. Komunikace mezi vedoucím a týmem je vertikální. 14

12 Dopad charakteristik projektu na organizaci týmu Týmová struktura DD Týmové struktura CD Týmová struktura CC složitost řešeného problému velikost výsledného programu doba trvání týmu (životnost týmu) stupeň modularizace problému požadovaná kvalita a spolehlivost budovaného systému vysoká X nízká X X velká X X malá X krátká X X dlouhá X vysoká X X nízká X vysoká X X nízká X tvrdost předávacích termínů vysoká nízká X X X požadovaný stupeň vnitřní komunikativnosti týmu (sociability) vysoká X nízká X X Jiná klasifikace rozlišuje pro organizaci týmů čtyři různá paradigmata: Uzavřené paradigma Náhodné paradigma Otevřené paradigma Synchronní paradigma struktura s tradiční hierarchií autorit (podobné CC) uvolněná struktura, závislá na individualitách pokus strukturovat tým s určitým řízením jako v uzavřeném paradigmatu, ale s ponecháním volnosti v tvorbě jako v náhodném paradigmatu záleží na přirozeném dělení problému a organizuje členy týmu, aby pracovali na částech bez potřeby velké komunikace mezi sebou. 15

13 Koordinace a komunikace v týmu o Formální, neosobní přístup - dokumentace, zdrojový kód, zprávy, zápisy o Formální, interpersonální procedury - týkají se zajištění kvality SW produktu. Kontrolní schůze, inspekce návrhu a kódu o Neformální, interpersonální procedury - schůze a neformální porady, které slouží k předávání informací v týmu a řešení problémů o Elektronická komunikace o Interpersonální síť - neformální diskuse se zkušenými experty mimo tým, kteří mohou asistovat členům týmu Problém U řešeného projektu je nejdůležitější pochopit o cíle projektu o rozsah projektu o alternativy řešení o technická omezení Při popisu rozsahu (vymezení) softwaru rozlišujeme o kontext o vstupní a výstupní informace o funkce systému, kde nás zajímá jednoznačnost, srozumitelnost a omezenost Pro dekomposici problému používáme princip "Rozděl a panuj". Modely softwarového procesu V úvodní kapitole jsme si uvedli čtyři základní modely životního cyklu SW projektu. V praxi rozeznáváme řadu dalších, kterými jsou: lineární sekvenční model model prototypování rad model přírůstkový model spirálový model model skládání komponent model souběžného vývoje formální metody techniky čtvrté generace 16

14 Lineární sekvenční model (model vodopád) Je to klasický životní cyklus. V 80. letech byl podroben kritice, která dospěla k formulování základních nedostatků, kterými jsou: o reálné projekty zřídka kdy sledují jednotlivé kroky v předepsaném pořadí o pro zákazníka je obtížné vyjádřit předem všechny požadavky o provozuschopná verze bude k disposici až po delší době (může být už zastaralá) o často dochází k prodlevám Přesto však i v současné době je pro řešení řady i velkých projektů model vodopádu používán. Prototypování Slouží k pochopení požadavků na systémy, které nejdou dobře specifikovat předem. Prototypy, na kterých mají být modelovány nějaké vlastnosti systému, mohou být dělány s vědomím, že budou zahozeny. Tento model lze použít pro menší systémy. RAD model Rapid Application Development Je to lineární sekvenční model spočívající v extrémně krátkém vývojovém cyklu - do 3 měsíců. Model je určen pro dobře srozumitelné a dobře vymezené problémy, s malými riziky. Problém je rozdělen na samostatné moduly, které se rozdělí týmům. Při vývoji jsou využívány hotové softwarové komponenty. Přírůstkový model (evoluční model) Kombinuje lineární model s iterativní filosofií. Produkt se vytváří po částech (přírůstcích), které jsou funkční (na rozdíl od prototypu). První přírůstek je označován jako jádro. Model je vhodný pro malý tým a velký úkol, který se dá zvládnout v předem po částech, v domluvených termínech. Spirálový model (evoluční model) Model kombinuje prototypování se systematickým sekvenčním přístupem a opakováním na výším stupni zvládnutí problematiky. Je založen na prioritě tvorby verze s vyšší rizikovostí. Části s větší mírou rizika jsou realizovány dříve. Nevýhodu modelu je, že nelze stanovit přesné termíny (při práci na zakázku), závisí na správnosti rizikové analýzy, náročné na zkušenost pracovníků (je nutné více kontrolních bodů, po každé analýze rizik). Je vhodný pro velké systémy. Model skládání komponent (evoluční model) Spirálový model pro objektové technologie, který využívá skládání hotových komponent z knihovna tříd objektů. 17

15 Model souběžného vývoje (evoluční model) Jednotlivé komponenty jsou vyvíjeny paralelně (vývoj je modelován jako paralelní procesy). Je vhodný např. pro klient/server aplikace. Formální metody Spočívají na formálních specifikacích, podporují formální verifikaci programů. Nevýhody, které zatím brání praktickému nasazení je, že je drahý a časově náročný, je náročný na kvalifikaci vývojářů, je v něm obtížná komunikace s běžným uživatelem. Techniky čtvrté generace Jsou založeny na programování na vysoké úrovni abstrakce. Výhodou je rychlý vývoj a zvýšení produktivity. Nevýhodou je, že některé prostředky jsou stejně složité jako klasické programovací jazyky, výsledný kód nemusí být dostatečně efektivní a údržba velkého systému může být problematická. Za perspektivní metodu vývoje softwaru se považuje spojení CASE nástroje s modelem skládání komponent. Proces Při řešení problematiky procesu realizace softwaru jsou nejdůležitější následující faktory: o výběr modelu o propojení problému a procesu o dekomposice (zjemnění) procesu Závěr Podstatný vliv na management softwarových projektů mají 3P: o Pracovníci musí být organizování do efektivních týmů, motivováni k vysoce kvalitní práci, koordinováni tak, aby dosáhli efektivní komunikace. o Problém musí být definován v komunikaci zákazníka s realizátorem, rozdělen (dekomponován) na části a přidělen softwarovým týmům. o Proces musí být přizpůsoben lidem a problému, vybrán vhodný model 18

16 3 Plánování a vedení projektu Při realizaci softwarového projektu je velmi důležitá komunikace se zákazníkem. Kdy komunikace se zákazníkem je jedna z nejobtížnějších částí projektu, a to i tehdy (často právě tehdy), jedná-li se o zákazníka poučeného. Na počátku má zákazník obvykle velmi jednoduché otázky, na které je velmi obtížné a často nemožné okamžitě odpovědět. Rozumíte mému problému? Umíte navrhnout systém, který bude řešit můj problém? Jak dlouho vám bude trvat vyvinout takový systém? Kolik to bude stát? Zákazník i tvůrce jsou často ovlivňováni softwarovými mýty. 3.1 Softwarové mýty Softwarové mýty se projevují na nejrůznějších úrovní tvorby systému. Uvedeme si zde některé z nich. Mýty o řízení projektu mýtus Existují normy, procedury, kuchařky jak co udělat.. Máme CASE, nejnovější počítače. Jestliže "nestíháme", dodáme více programátorů. skutečnost Jsou nepoužitelné, nejsou kompletní, neřeší naše problémy.. Počítače nejsou rozhodující, i nejnovější CASE neřeší vše Neumí, nejsou seznámeni s problémem, musíme je školit. 19

17 Zákaznické mýty mýtus Obecné zadání stačí, aby se začal psát program Požadavky se průběžně mění, ale SW je přizpůsobivý skutečnost Formální a detailní specifikace je podmínkou dobrého SW Ano, SW se snadno přizpůsobí, ale a jakou cenu? Čím později se požadují změny, tím jsou dražší.. Z následujícího grafu je patrné, jak rostou náklady na změny v programu, vyžadované v různých fázích životního cyklu softwarového díla. náklady na změnu specifíikace vývoj údržba náklady na změnu obr. 3.1 Mýty praktika mýtus Jestliže napíšeme program a ten "chodí", je hotovo Dokud program "neběží" nezjistím jeho kvalitu Jediný produkt úspěšného projektu je funkční program skutečnost Čím dříve začneme psát program, tím později bude hotov. 50% - 70% práce na programu jsou až po předání zákazníkovi Existují metody formální evaluace kvality Je to jen část výsledného produktu. Musíme doplnit dokumentaci, testování, údržbu, zaškolení.. 20

18 Funkční program je jen část výsledného produktu. Na následujícím obrázku je znázorněna úplná konfigurace softwaru, která musí být zdokumentována nejen pro zajištění úspěšného vývoje systému, ale i pro je další údržbu. 3.2 Plán projektu Abychom mohli naplánovat práce na projektu, musíme mimo jiné vědět, co vše bychom měli zákazníkovi předat. Mezi předávané části produkty (deliverables) patří: o dokumentace o předvedení funkce o návrh subsystémů o důkaz přesnosti o prezentace efektivity, bezpečnosti a realizace Během práce na projektu je nutné stanovit jednotlivé aktivity a kontrolní dny, tzv. milníky (milestones). Příklad úkolů a kontrolních milník;u je uveden na obr procedurální návrh kontrola kódování testování test jednotky analýza požadavky návrh dat návrh integrační validační test test test test plánování testů testování vyhodnocení testů milníky Obr

19 Na obrázku 3.5 jsou jednotlivé fáze projektu, které jsou rozčleněny na jednotlivé kroky a těm přiřazeny odpovídající aktivity. Fáze, kroky a aktivity projektu fáze 1 krok 1 aktivita 1.1 krok 2 aktivita projekt fáze 2 krok 1 aktivita 2.1 krok 2 aktivita 2.2 fáze 3 krok 1 krok Obr Plánování času Při plánování (nejen softwarových projektů) platí tzv. pravidlo Pravidlo Je-li odhadováno, že práce je hotová z 90%, pak ve skutečnosti zbývá dokončit ještě 90% práce. Příčiny pozdního dodání softwaru Nejčastější příčiny pozdního dodání softwaru lze shrnout do následujícího seznamu: o nerealistický termín stanovený někým vně softwarové skupiny o změna požadavků zákazníka, se kterou se nepočítalo o podcenění pracnosti a nebo nutných zdrojů o předvídatelná nebo nepředvídatelná rizika, která nebyla uvažována při plánování projektu o technické obtíže, které nebyly předpokládány o lidské problémy, které nebyly předpokládány o nedorozumění a nebo špatná komunikace mezi členy týmu o chyba managementu projektu, že nepoznal, že se projekt zpožďuje a nezahájil opravné akce. 22

20 Zákazník má občas požadavky na dodání softwaru, které neodpovídají realitě. Záleží na vzájemné spolupráci jak jsou tyto situace řešeny. Existují obecné strategie, které je dobré dodržet. Obrana proti nerealistickým termínům zákazníka: 1. Udělej podrobný odhad podle dat z minulosti. Urči odhad pracnosti a trvání projektu. 2. Použij přírůstkový model procesu a sestav plán dodání jádra systému, které bude zahrnovat kritické funkce systému a bude jej možné dodat do plánovaného termínu. S tím, že se zbytek dodá později. Připrav dokumentaci tohoto plánu. 3. Vysvětli zákazníkovi, že jeho termíny jsou nerealistické a proč. 4. Navrhni mu přírůstkovou strategii a dohodni se na řešení. Základní principy plánování času o Rozdělení na zvládnutelné aktivity a úkoly o Stanovení vzájemných závislostí o Alokace času o Zvážení pracnosti o Stanovení odpovědností o Stanovení výstupů o Definování milníků Mýtus Jestliže nestíháme plnit časový plán, přijmeme víc programátorů a doženeme skluz. Vztah mezi počtem lidí a produktivitou není lineární! Pro rozložení pracnosti při práci na projektu platí pravidlo , které říká, že 40% práce je analýza 20 % je kódování 40 % testování 23

21 Při časovém plánování vycházíme s následujícího seznamu aktivit: o odhad pracnosti o dekomposice funkce produktu o výběr vhodného modelu procesu o výběr typu projektu a množiny úkolů Typy softwarových projektů Softwarové projekty můžeme klasifikovat podle nejrůznějších kriterií, následující seznam je člení podle typu aplikace. 1. Projekty pro vývoj nového konceptu 2. Projekty vývoje nové aplikace 3. Projekty pro zdokonalení aplikace 4. Projekty údržby aplikace 5. Projekty pro reinženýrství Stupeň rigoróznosti Při tvorbě softwaru se zajímáme i o to, jaké jsou specifické požadavky na proces tvorby a na produkt. Mluvíme o stupni rigoróznosti. Rozeznáváme tyto stupně rigoróznosti: o neformální - minimální množina úkolů, redukovaná dokumentace o strukturovaný - rámcové aktivity a příslušné úkoly o přísný - úplný proces, potřeba vysoké kvality, robustní dokumentace o rychlá reakce - vzhledem k nouzové situaci jsou aplikovány jen ty aktivity, které zajišťují dobrou kvalitu, úplná dokumentace je dodělána dodatečně po dodání produktu Jak stanovíme stupeň rigoróznosti? Existuje celá řada faktorů, ze kterých jsou nejdůležitější následující: o velikost produktu o počet potenciálních uživatelů o kritičnost mise o délka životnosti aplikace o stabilita požadavků o snadnost komunikace uživatel/zákazník o zralost aplikační technologie o omezující podmínky provedení 24

22 o vložené (embeded)/nevložené charakteristiky o pracovníci projektu o reinženýrské faktory Hodnota každého faktoru je 0-5 přičemž 1- projekt s malou podmnožinou úkolů, metodické a dokumentační požadavky jsou minimální 5 - kompletní množina procesních úkolů a metodické a dokumentační požadavky jsou podstatné Příklad tabulky stupňů rigoróznosti pro úkol Kritéria stupeň váha násobek vstupního bodu součin koncept nová apl. zdokonal. údržba reinženýr. velikost 2 1, ,4 Počet uživatelů 3 1, ,3 kritičnost 4 1, ,4 životnost 3 0, ,7 stabilita požadavků 2 1, ,4 komunikace 2 0, ,8 zralost techniky 2 0, ,8 omezení 3 0, ,4 embedded/non 3 1, ,6 zaměstnanci spolupráce 4 1, ,4 reinženýring 0 1, Výběrová hdnota TSS pro úkol 2,6 Postup výpočtu výběrové hodnoty (TSS - Task set selector value): 1. stanov hodnotu každého kritéria (0-5) 25

14 Úvod do plánování projektu Řízení projektu

14 Úvod do plánování projektu Řízení projektu 14 Úvod do plánování projektu Řízení projektu Plánování projektu Vývoj - rozbor zadání odhad pracnosti, doby řešení, nákladů,... analýza rizik strategie řešení organizace týmu PLÁN PROJEKTU 14.1 Softwarové

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

5 Požadavky a jejich specifikace

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

Více

D8 Plánování projektu

D8 Plánování projektu Projektový manažer 250+ Kariéra projektového manažera začíná u nás! D Útvarové a procesní řízení D8 Plánování projektu Toto téma obsahuje informace o správném postupu plánování projektu tak, aby byl respektován

Více

Školení v rámci zemědělské a lesnické činnosti 2014

Školení v rámci zemědělské a lesnické činnosti 2014 Vindex JIH, s.r.o. Platnéřská 191 110 00 Praha IČO: 25173278 Název projektu: Školení v rámci zemědělské a lesnické činnosti 2014 Číslo projektu: 13/0181310b/131/000199 Financováno z Programu Rozvoje Venkova

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

Obsah přednášky Vstupy výstupy procesu Plánování projektu Základní dokumenty plánu projektu Ostatní dokumentace projektu Ukázky dokumentů

Obsah přednášky Vstupy výstupy procesu Plánování projektu Základní dokumenty plánu projektu Ostatní dokumentace projektu Ukázky dokumentů Návrh a management projektu ČVUT FAKULTA BIOMEDICÍNSKÉHO INŽENÝRSTVÍ strana 1 Ing. Vladimír Jurka 2013 Obsah přednášky Vstupy výstupy procesu Základní dokumenty plánu projektu Ostatní dokumentace projektu

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

Projektové řízení (Projektový cyklus)

Projektové řízení (Projektový cyklus) Projektové řízení (Projektový cyklus) Vzdělávací program v rámci projektu Rekonstrukce učitelů - posílení profesní a kompetenční připravenosti učitelů (CZ.1.07/1.3.10/02.0052) 1 Projektový cyklus Metodické

Více

Bezepečnost IS v organizaci

Bezepečnost IS v organizaci Bezepečnost IS v organizaci analýza rizik Zabezpečení informačního systému je nutné provést tímto postupem: Zjistit zranitelná místa, hlavně to, jak se dají využít a kdo toho může zneužít a pravděpodobnost

Více

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

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

Více

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

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

24.11.2009 Václav Jirchář, ZTGB

24.11.2009 Václav Jirchář, ZTGB 24.11.2009 Václav Jirchář, ZTGB Síťová analýza 50.let V souvislosti s potřebou urychlit vývoj a výrobu raket POLARIS v USA při závodech ve zbrojení za studené války se SSSR V roce 1958 se díky aplikaci

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

kapitola 2 předprojektová fáze 31

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

Více

Popis obsahu a struktury programu

Popis obsahu a struktury programu Popis obsahu a struktury programu (Příloha k Žádosti o akreditaci vzdělávacího programu u Společnosti pro projektové řízení, o. s.) 1 Vzdělávací subjekt: HM PARTNERS s.r.o. Název programu: Projektové řízení

Více

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

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

Více

Agenda. Docházka Odhadování Neohlášený test Vedení projektů Historie projektů

Agenda. Docházka Odhadování Neohlášený test Vedení projektů Historie projektů Odhadování pracnosti a PM Agenda Docházka Odhadování Neohlášený test Vedení projektů Historie projektů PM, odhadování, historie Odhadování Snaha určit rozsah. Důležité pro stanovení ceny a termínu Do nabídek.

Více

Teorie síťových modelů a síťové plánování

Teorie síťových modelů a síťové plánování KSI PEF ČZU Teorie síťových modelů a síťové plánování Část přednášky doc. Jaroslava Švasty z předmětu systémové analýzy a modelování. Zápis obsahuje základní vymezení projektu, časového plánování a popis

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

Management. Rozhodování. Ing. Vlastimil Vala, CSc. Ústav lesnické a dřevařské ekonomiky a politiky

Management. Rozhodování. Ing. Vlastimil Vala, CSc. Ústav lesnické a dřevařské ekonomiky a politiky Management Rozhodování Ing. Vlastimil Vala, CSc. Ústav lesnické a dřevařské ekonomiky a politiky Vytvořeno s podporou projektu Průřezová inovace studijních programů Lesnické a dřevařské fakulty MENDELU

Více

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

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

Více

1. Stavební management

1. Stavební management 1. Stavební management Klíčová slova: Management, podstata managementu, organizační uspořádání podniku, organizační struktura, rozhodování, osobnost manažera, projektové a procesní řízení. Anotace textu:

Více

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

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

Více

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

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

Více

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

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

Více

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

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

Více

Projektové řízení. Ing. Miroslav Žilka, Ph.D.

Projektové řízení. Ing. Miroslav Žilka, Ph.D. Projektové řízení Ing. Miroslav Žilka, Ph.D. Týmová spolupráce Prezentační dovednosti Kreativita Projekt REHP Kalkulace nákladů Přesvědčivost Rozpočet TE hodnocení projektů Diplomacie Zásady projektového

Více

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

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

Více

Podrobná analýza k aktivitě č. 3 - implementace procesního řízení do praxe úřadu

Podrobná analýza k aktivitě č. 3 - implementace procesního řízení do praxe úřadu Příjemce dotace: Město Moravská Třebová Název projektu: Zvýšení kvality řízení a poskytovaných služeb MÚ Moravská Třebová Registrační číslo projektu: CZ.1.04/4.1.01/89.00116 Podrobná analýza k aktivitě

Více

Ing. Jiří Fejfar, Ph.D. Geo-informační systémy

Ing. Jiří Fejfar, Ph.D. Geo-informační systémy Ing. Jiří Fejfar, Ph.D. Geo-informační systémy Definice, budování a život GIS Kapitola 1: Vztahy strana 2 Data, informace, IS, GIS Kapitola 1: Vztahy strana 3 Rozhodnutí Znalosti Znalostní systémy. Informace

Více

Projektové řízení 2. část. Plánování projektu, sledování projektu, integrace projektu, změny v projektu, řešení problémů, projektový tým

Projektové řízení 2. část. Plánování projektu, sledování projektu, integrace projektu, změny v projektu, řešení problémů, projektový tým Projektové řízení 2. část Plánování projektu, sledování projektu, integrace projektu, změny v projektu, řešení problémů, projektový tým Projektové etapy 3. VEDENÍ vedení projektového týmu k včasnému a

Více

InternetovéTechnologie

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

Více

PowerOPTI Řízení účinnosti tepelného cyklu

PowerOPTI Řízení účinnosti tepelného cyklu PowerOPTI Řízení účinnosti tepelného cyklu VIZE Zvýšit konkurenceschopnost provozovatelů elektráren a tepláren. Základní funkce: Spolehlivé hodnocení a řízení účinnosti tepelného cyklu, včasná diagnostika

Více

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. II ZE DNE 16. 6. 2015

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. II ZE DNE 16. 6. 2015 DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. II ZE DNE 16. 6. 2015 ZADAVATEL: Česká republika Ministerstvo práce a sociálních věcí Sídlem: Na Poříčním právu 376/1, 128 01 Praha 2 Zastoupena: Mgr. Petrem

Více

D5 Životní cyklus projektu

D5 Životní cyklus projektu Projektový manažer 250+ Kariéra projektového manažera začíná u nás! D Útvarové a procesní řízení D5 Životní cyklus projektu Toto téma obsahuje informace o vhodné posloupnosti kroků přípravy a realizace

Více

SWI041: Hledáme odpověď na otázku: Jak dlouho a za kolik?

SWI041: Hledáme odpověď na otázku: Jak dlouho a za kolik? SWI041: Plánov nování projektů Hledáme odpověď na otázku: Jak dlouho a za kolik? Produkce software Produkce Produkcesoftware (Software (Software Process) Process) zahrnuje Management Management projektu

Více

Problémové domény a jejich charakteristiky

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

Více

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

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

Více

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

Klasifikace a význam cílů Struktura plánu

Klasifikace a význam cílů Struktura plánu PLÁNOVÁNÍ Co je to plá Klasifikace a význam cílů Struktura plánu Strategické plá Postup při sestavování plánu Metody plá Bariéry plá - definice manažerská aktivita zaměřená na budoucí vývoj firmy, určující

Více

Příloha č. 3: Technické zadání zakázky Instalace a služby pro technologické centrum MÚ Pohořelice

Příloha č. 3: Technické zadání zakázky Instalace a služby pro technologické centrum MÚ Pohořelice Příloha č. 3: Technické zadání zakázky Instalace a služby pro technologické centrum MÚ Pohořelice Účelem veřejné zakázky je vybudování, provoz a údržba infrastruktury pro provozování aplikací a služeb

Více

Michal Oškera (50854)

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.............................

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

KATALOG SLUŽEB NÁSLEDNÉ PODPORY

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

Více

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů.

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů. Modely datové Existují různé úrovně pohledu na data. Nejvyšší úroveň je úroveň, která zachycuje pouze vztahy a struktury dat samotných. Konceptuální model - E-R model. Další úrovní je logická úroveň Databázové

Více

MS Project jako nástroj pro analýzu spolehlivosti

MS Project jako nástroj pro analýzu spolehlivosti MS Project jako nástroj pro analýzu spolehlivosti Petr Kolář 1. Představení aplikace MS Project Manažeři, kteří koordinují plánování, průběh a hodnocení libovolných projektů, jsou nuceni pracovat s velkým

Více

Outcome mapping evaluation - nová možnost pro ČR? Vladimír Sodomka

Outcome mapping evaluation - nová možnost pro ČR? Vladimír Sodomka Outcome mapping evaluation - nová možnost pro ČR? Vladimír Sodomka 2014 1 Obsah prezentace Představení metody Oucome Mapping Evaluation (OME) relativně nová metoda v ČR alternativa ke konvenčním lineárním

Více

Profilová část maturitní zkoušky 2013/2014

Profilová část maturitní zkoušky 2013/2014 Střední průmyslová škola, Přerov, Havlíčkova 2 751 52 Přerov Profilová část maturitní zkoušky 2013/2014 TEMATICKÉ OKRUHY A HODNOTÍCÍ KRITÉRIA Studijní obor: 78-42-M/01 Technické lyceum Předmět: TECHNIKA

Více

BEZPEČNOSTNÍ POLITIKA INFORMACÍ

BEZPEČNOSTNÍ POLITIKA INFORMACÍ BEZPEČNOSTNÍ POLITIKA INFORMACÍ společnosti ČEZ Energetické služby, s.r.o. Stránka 1 z 8 Obsah: 1. Úvodní ustanovení... 3 2. Cíle a zásady bezpečnosti informací... 3 3. Organizace bezpečnosti... 4 4. Klasifikace

Více

ADVANTA / Dokumentace: Přehled funkčních modulů

ADVANTA / Dokumentace: Přehled funkčních modulů ADVANTA / Dokumentace: Přehled funkčních modulů Primárním účelem nástroje ADVANTA je pokrýt aktuální potřeby správy projektového portfolia. Jak postupně roste úroveň akceptace a integrace do prostředí

Více

Balíček vzorové dokumentace pro projektové manažery ve školství v rámci projektu PM 250+

Balíček vzorové dokumentace pro projektové manažery ve školství v rámci projektu PM 250+ Balíček vzorové dokumentace pro projektové manažery ve školství v rámci projektu PM 250+ Co je Balíček a k čemu slouží Jedná se o sadu 23 formulářů pro podporu řízení projektů ve školách a školských zařízeních.

Více

19.11.2013. Projektový management. Projektový management. Další charakteristiky projektu. Projekt

19.11.2013. Projektový management. Projektový management. Další charakteristiky projektu. Projekt Projektový management Lekce: 8 Projektový management Doc. Ing. Alois Kutscherauer, CSc. Projektový management je typ managementu uplatňovaného k zabezpečení realizace jedinečných, neopakovatelných, časově

Více

Odbor informatiky a provozu informačních technologií

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

Více

Zdravotnické laboratoře. MUDr. Marcela Šimečková

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

Více

Program a životní cyklus programu

Program a životní cyklus programu Program a životní cyklus programu Program algoritmus zapsaný formálně, srozumitelně pro počítač program se skládá z elementárních kroků Elementární kroky mohou být: instrukce operačního kódu počítače příkazy

Více

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

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

Více

MUDr. Miloš Suchý, Bc. Petr Suchý, Konference QUIP, Praha 12.2.2008. Měření výkonnosti, zkušenosti ze zdravotnictví a sociální péče

MUDr. Miloš Suchý, Bc. Petr Suchý, Konference QUIP, Praha 12.2.2008. Měření výkonnosti, zkušenosti ze zdravotnictví a sociální péče MUDr. Miloš Suchý, Bc. Petr Suchý, Konference QUIP, Praha 12.2.2008 Měření výkonnosti, zkušenosti ze zdravotnictví a sociální péče Měření výkonnosti Slovo výkonnost je českou obdobou slova performance

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

D9 Realizace projektu

D9 Realizace projektu Projektový manažer 250+ Kariéra projektového manažera začíná u nás! D Útvarové a procesní řízení D9 Realizace projektu Toto téma obsahuje informace o správném postupu realizace projektu tak, aby byl respektován

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

Přehled technických norem z oblasti spolehlivosti

Přehled technických norem z oblasti spolehlivosti Příloha č. 1: Přehled technických norem z oblasti spolehlivosti NÁZVOSLOVNÉ NORMY SPOLEHLIVOSTI IDENTIFIKACE NÁZEV Stručná charakteristika ČSN IEC 50(191): 1993 ČSN IEC 60050-191/ Změna A1:2003 ČSN IEC

Více

Aplikovaná statistika pro učitele a žáky v hodinách zeměpisu aneb jak využít MS Excel v praxi. Geografický seminář 30. března 2011 Pavel Bednář

Aplikovaná statistika pro učitele a žáky v hodinách zeměpisu aneb jak využít MS Excel v praxi. Geografický seminář 30. března 2011 Pavel Bednář Aplikovaná statistika pro učitele a žáky v hodinách zeměpisu aneb jak využít MS Excel v praxi Geografický seminář 30. března 2011 Pavel Bednář Výchozí stav Sebehodnocení práce s MS Excel studujícími oboru

Více

Registr rizik. Dopad kvantifikujeme podle matice níže. 2 Malý dopad. 3 Střední dopad. 4 Vysoký dopad. 5 Velmi vysoký dopad. malý dopad.

Registr rizik. Dopad kvantifikujeme podle matice níže. 2 Malý dopad. 3 Střední dopad. 4 Vysoký dopad. 5 Velmi vysoký dopad. malý dopad. Registr rizik Co je Registr rizik a k čemu slouží S každým projektem jsou spojena určitá rizika, tedy nejisté události, které mohou nastat a ovlivnit (zpravidla negativně) průběh. Analýza rizik je samostatnou

Více

Zpracování náhodného výběru. Ing. Michal Dorda, Ph.D.

Zpracování náhodného výběru. Ing. Michal Dorda, Ph.D. Zpracování náhodného výběru popisná statistika Ing. Michal Dorda, Ph.D. Základní pojmy Úkolem statistiky je na základě vlastností výběrového souboru usuzovat o vlastnostech celé populace. Populace(základní

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

Management projektů. Programová podpora auditu sytému managementu kvality HOT 4IT. Plán projektu

Management projektů. Programová podpora auditu sytému managementu kvality HOT 4IT. Plán projektu Management projektů Programová podpora auditu sytému managementu kvality HOT 4IT Plán projektu Historie Verze Datum Status Kdo Poznámka 0.1 8. 4. 2010 Špaček Petr Vytvoření 0.2 11. 4. 2010 Špaček Petr

Více

Standardní dokumenty

Standardní dokumenty Standardní dokumenty Zadávací dokumentace pro projekty EPC Principy European Energy Service Initiative EESI IEE/08/581/SI2.528408 Duben 2011 Výhradní odpovědnost za obsah tohoto materiálu nesou autoři.

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

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

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

Více

Vysoká škola ekonomická v Praze Fakulta podnikohospodářská

Vysoká škola ekonomická v Praze Fakulta podnikohospodářská Projekt implementace SAP Business Objects Předmět: 3MA382 Manažerská informatika projektové řízení, distanční Období: ZS 2009/2010 Vypracoval/a: Petr Kuchyňka (xkucp27), Klára Jalůvková (xjalk00, FPH N

Více

Software - - - - generické produkty - smluvní, zakázkové produkty - - udržovatelnost spolehlivost efektivita použitelnost - - - - specifikace

Software - - - - generické produkty - smluvní, zakázkové produkty - - udržovatelnost spolehlivost efektivita použitelnost - - - - specifikace 1. Software - software o souhrn počítačových programů, procedur, pravidel a průvodní dokumentace a dat, který náleží k provozu počítačového systému o vyvíjen a řešen inženýrskými pracemi o fyzicky se neopotřebuje

Více

Osnova studie proveditelnosti pro projekt zakládání a rozvoje klastrů

Osnova studie proveditelnosti pro projekt zakládání a rozvoje klastrů Osnova studie proveditelnosti pro projekt zakládání a rozvoje klastrů V rámci tohoto dokumentu se předpokládá využití informací a dat, zjištěných v rámci projektu Vyhledávání vhodných firem pro klastry

Více

Jan Horák. Pilíře řešení

Jan Horák. Pilíře řešení Jan Horák Pilíře řešení Nová generace systémů Důsledek rozvoje a změn informatiky ve zdravotnictví: Nové technologie Výkonnost, mobilita, velikost monitorů, dotykové ovládání, vzdálené přístupy Nové možnosti

Více

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

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

Více

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

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

Více

Řízení vztahů se zákazníky

Řízení vztahů se zákazníky Řízení vztahů se zákazníky Řízení vztahů se zákazníky Vychází z představy, že podnik je řízen zákazníkem Používanými nástroji jsou: Call Centra Customer Relationship Management (CRM) Základní vazby v řízení

Více

Úvodem... 9 O Metodikách... 37 O Metodách... 135

Úvodem... 9 O Metodikách... 37 O Metodách... 135 Obsah A. Úvodem... 9 A. 1. Projektování informačního systému... 10 A. 2. O co jde při vývoji IS... 16 A. 3. Historie vývoje metodik, metod a technik... 33 B. O Metodikách... 37 B. 1. Metody a metodiky...

Více

Obsah ČÁST I JAK SE UCHÁZET O ZÁKAZNÍKY NA WEBU KAPITOLA 1

Obsah ČÁST I JAK SE UCHÁZET O ZÁKAZNÍKY NA WEBU KAPITOLA 1 Obsah O autorech 11 Poděkování 13 Předmluva 15 Úvod 17 Proč byste se měli přečíst tuto knihu 17 Co tato kniha obsahuje 18 Jak používat tuto knihu 19 Zpětná vazba od čtenářů 20 Errata 20 ČÁST I JAK SE UCHÁZET

Více

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

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

Více

Workflow, definice, charakteristika, trendy

Workflow, definice, charakteristika, trendy Workflow, definice, charakteristika, trendy Workflow management je efektivní správa toku informací a řízení v podnikových procesech. Workflow automatizuje procesy. Workflow podporuje tok dokumentů, informací

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

MANAŽERSKÉ ROZHODOVÁNÍ. Zpracoval Ing. Jan Weiser

MANAŽERSKÉ ROZHODOVÁNÍ. Zpracoval Ing. Jan Weiser MANAŽERSKÉ ROZHODOVÁNÍ Zpracoval Ing. Jan Weiser Obsah výkladu Rozhodovací procesy a problémy Dvě stránky rozhodování Klasifikace rozhodovacích procesů Modely rozhodování Nástroje pro podporu rozhodování

Více

Web Design Factory Projektové řízení pro progresivní společnost

Web Design Factory Projektové řízení pro progresivní společnost Web Design Factory Projektové řízení pro progresivní společnost Případová studie Name Description Projektové řízení pro progresivní společnost Implementace systému Atollon Workshop ve společnosti WDF Version

Více

Výzkum trhu. Vzdělávací materiál ke kurzu Zahraniční obchod, tutoriál Mezinárodní podnikání

Výzkum trhu. Vzdělávací materiál ke kurzu Zahraniční obchod, tutoriál Mezinárodní podnikání Výzkum trhu Vzdělávací materiál ke kurzu Zahraniční obchod, tutoriál Mezinárodní podnikání Slezská univerzita v Opavě Okresní hospodářská komora Karviná 2010-2013 Výukový materiál je výstupem projektu

Více

Projektové řízení. 1. část. http://knihy.abz.cz/obchod/projektovy-management http://www.method123.com/free-projectmanagement-book.

Projektové řízení. 1. část. http://knihy.abz.cz/obchod/projektovy-management http://www.method123.com/free-projectmanagement-book. Projektové řízení 1. část http://knihy.abz.cz/obchod/projektovy-management http://www.method123.com/free-projectmanagement-book.php http://www.amazon.com/project-management- Books/lm/R2JSEO2N6WOUEJ Definice

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 60 %) je podhodnocena či zpožděna.

Více

Město Vsetín, Městský úřad Vsetín, Svárov 1080, 755 01 Vsetín, IČ0: 00304450. SMĚRNICE číslo QS 85-03 PROJEKTOVÉ ŘÍZENÍ

Město Vsetín, Městský úřad Vsetín, Svárov 1080, 755 01 Vsetín, IČ0: 00304450. SMĚRNICE číslo QS 85-03 PROJEKTOVÉ ŘÍZENÍ Město Vsetín, Městský úřad Vsetín, Svárov 1080, 755 01 Vsetín, IČ0: 00304450 Výtisk č.: 0 Město Vsetín Městský úřad Vsetín SMĚRNICE číslo QS 85-03 Vydání: 1 Účinnost od: 1. 7. 2005 Přepis: Počet stran:

Více

Systémy pro podporu. rozhodování. 2. Úvod do problematiky systémů pro podporu. rozhodování

Systémy pro podporu. rozhodování. 2. Úvod do problematiky systémů pro podporu. rozhodování 1 Systémy pro podporu rozhodování 2. Úvod do problematiky systémů pro podporu rozhodování 2 Připomenutí obsahu minulé přednášky Rozhodování a jeho počítačová podpora Manažeři a rozhodování K čemu počítačová

Více

4.5 Stanovení hodnoticích kritérií a požadavky na jejich obsah

4.5 Stanovení hodnoticích kritérií a požadavky na jejich obsah nadhodnocením ukazatele výkonu). Současně se objektivností rozumí, že technické podmínky nebyly nastaveny diskriminačně, tedy tak, aby poskytovaly některému uchazeči konkurenční výhodu či mu bránily v

Více

Maturitní témata Školní rok: 2015/2016

Maturitní témata Školní rok: 2015/2016 Maturitní témata Školní rok: 2015/2016 Ředitel školy: Předmětová komise: Předseda předmětové komise: Předmět: PhDr. Karel Goš Informatika a výpočetní technika Mgr. Ivan Studnička Informatika a výpočetní

Více

Systémy pro podporu rozhodování. Modelování a analýza

Systémy pro podporu rozhodování. Modelování a analýza Systémy pro podporu rozhodování Modelování a analýza 1 Připomenutí obsahu minulé přednášky Datové sklady, přístup, analýza a vizualizace Povaha a zdroje dat (data, informace, znalosti a interní, externí,

Více

44 Organizace akcí. Popis modulu. Záložka Seznam akcí

44 Organizace akcí. Popis modulu. Záložka Seznam akcí 44 Organizace akcí Modul Organizace akcí slouží k přípravě a plánování různých společenských, sportovních, kulturních, apod. akcí. Tyto akce je možné dále dělit do částí (ve stromové struktuře) a plánovat

Více

Adresa: Kontaktní osoba: Mgr. Zuzana Chalupová Na poříčním právu 1/ Telefon: 221 922 923 128 01 Praha 2 Fax: E-mail: zuzana.chalupova@mpsv.

Adresa: Kontaktní osoba: Mgr. Zuzana Chalupová Na poříčním právu 1/ Telefon: 221 922 923 128 01 Praha 2 Fax: E-mail: zuzana.chalupova@mpsv. Návrh výzkumné potřeby státní správy pro zadání veřejné zakázky na projekt z programu veřejných zakázek ve výzkumu, experimentálním vývoji a inovacích pro potřeby státní správy BETA Předkladatel - garant

Více

čj. KrÚ 35949/2014 Riziko nerealizace veřejné zakázky:

čj. KrÚ 35949/2014 Riziko nerealizace veřejné zakázky: čj. KrÚ 35949/2014 Odůvodnění účelnosti veřejné zakázky podle 2 vyhlášky č. 232/2012 Sb., o podrobnostech rozsahu odůvodnění účelnosti veřejné zakázky a odůvodnění veřejné zakázky (dále jen vyhláška )

Více

5 INVESTIČNÍ RIZIKO, ČISTÝ PRACOVNÍ KAPITÁL A STRATEGIE FINANCOVÁNÍ, FINANČNĚ-ANALYTICKÁ KRITÉRIA VÝKONNOSTI PODNIKU

5 INVESTIČNÍ RIZIKO, ČISTÝ PRACOVNÍ KAPITÁL A STRATEGIE FINANCOVÁNÍ, FINANČNĚ-ANALYTICKÁ KRITÉRIA VÝKONNOSTI PODNIKU 5 INVESTIČNÍ RIZIKO, ČISTÝ PRACOVNÍ KAPITÁL A STRATEGIE FINANCOVÁNÍ, FINANČNĚ-ANALYTICKÁ KRITÉRIA VÝKONNOSTI PODNIKU 5.1 Investiční riziko (měření a ochrana) 5.1.1 Měření investičního rizika Definovat

Více

WAMS - zdroj kvalitní ch dat pro analý zý stavu sí tí a pro nové éxpértní sýsté mý

WAMS - zdroj kvalitní ch dat pro analý zý stavu sí tí a pro nové éxpértní sýsté mý WAMS - zdroj kvalitní ch dat pro analý zý stavu sí tí a pro nové éxpértní sýsté mý Daniel Juřík, Antonín Popelka, Petr Marvan AIS spol. s r.o. Brno Wide Area Monitoring Systémy (WAMS) umožňují realizovat

Více

Cíl výuky: Cílem předmětu je uvedení studentů do problematiky projektování, seznámit posluchače se zásadami

Cíl výuky: Cílem předmětu je uvedení studentů do problematiky projektování, seznámit posluchače se zásadami PM_prezenční a kombinované bakalářské studium Česky Projektový management Anglicky Project Management Garant Ing. Zdeněk Voznička, CSc. Zakončení Zápočet Anotace: Úvod do projektového managementu, základní

Více

1.05 Informační systémy a technologie

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

Více