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

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

Š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

ÚVOD DO PROBLEMATIKY PROJEKTŮ, KATEGORIE

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

Více

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

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

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

Více

P 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

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

Management. Ing. Jan Pivoňka

Management. Ing. Jan Pivoňka Management Ing. Jan Pivoňka Stanovení osobní vize V souladu s kotvou Konkrétní představa Citový náboj Stimul pro aktivní jednání Krátkodobější cíle motivace Výjimky Jasná vize Pohodoví lidé Úspěch bez

Více

WORKFLOW. Procesní přístup. Základ perspektivního úspěšného podnikového řízení. Funkčnířízení založené na dělbě práce

WORKFLOW. Procesní přístup. Základ perspektivního úspěšného podnikového řízení. Funkčnířízení založené na dělbě práce WORKFLOW Procesní přístup Základ perspektivního úspěšného podnikového řízení Funkčnířízení založené na dělbě práce Procesní řízení princip integrace činností do ucelených procesů 1 Funkční řízení Dělba

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

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

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

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

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

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

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

Více

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

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

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

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

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Architektury Informačních systémů Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Nutné pojmy Co je to informační systém? Jaké oblasti zahrnuje? Jaká je vazba IS na podnikovou strategii?

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

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

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

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

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

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

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ 1) PROGRAM, ZDROJOVÝ KÓD, PŘEKLAD PROGRAMU 3 2) HISTORIE TVORBY PROGRAMŮ 3 3) SYNTAXE A SÉMANTIKA 3 4) SPECIFIKACE

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

Projektové řízení a rizika v projektech

Projektové řízení a rizika v projektech Projektové řízení a rizika v projektech Zainteresované strany Zainteresované strany (tzv. stakeholders) jsou subjekty (organizace, lidé, prostory, jiné projekty), které realizace projektu ovlivňuje. Tyto

Více

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

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

Více

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

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

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

Více

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

Vysoká škola technická a ekonomická v Českých Budějovicích. Institute of Technology And Business In České Budějovice 11. REALIZACE PROJEKTU, SLEDOVÁNÍ STAVU, PŘÍPRAVA PROVOZU, ZKUŠEBNÍ PROVOZ 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

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

www.cdc-monitoring.cz

www.cdc-monitoring.cz Monitoring sítí a serverů Dnešní požadavky na výkon ethernetových, wifi nebo jiných sítí, jejich serverů a aktivních prvků jsou velmi striktně nastaveny. Síť musí být koncipována tak, aby byla zaručena

Více

Kariéra projektového manažera začíná u nás!

Kariéra projektového manažera začíná u nás! CHECK-LIST Auditovaná fáze projektu: Auditor: Název projektu: Zpracoval: Datum: Plánování projektu Návod na vyplnění: Při vyplňování Check-listu posuzujte skutečný obsah auditované dokumentace, vhodně

Více

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování 1. Teoretické základy modelování na počítačích 1.1 Lambda-kalkul 1.1.1 Formální zápis, beta-redukce, alfa-konverze 1.1.2 Lambda-výraz jako data 1.1.3 Příklad alfa-konverze 1.1.4 Eta-redukce 1.2 Základy

Více

Globální strategie, podnikové procesy, IT strategie. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Globální strategie, podnikové procesy, IT strategie. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Globální strategie, podnikové procesy, IT strategie Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Globální podniková strategie Co budeme dělat? Jak to budeme dělat? Jak využijeme IT Co

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

A7B36SI2 Tematický okruh SI08 Revidoval: Martin Kvetko

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

Více

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

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

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

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

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

Příloha č. 3 Smlouvy Součinnost stran při poskytování některých plnění

Příloha č. 3 Smlouvy Součinnost stran při poskytování některých plnění Příloha č. 3 Smlouvy Součinnost stran při poskytování některých plnění Nástroje pro poskytování součinnosti 1.1 Help desk Poskytovatel vytvoří a zajistí službu pro hlášení vad/požadavků/připomínek (dále

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

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

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

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

Obsah. ÚVOD 1 Poděkování 3

Obsah. ÚVOD 1 Poděkování 3 ÚVOD 1 Poděkování 3 Kapitola 1 CO JE TO PROCES? 5 Co všechno musíme vědět o procesním řízení, abychom ho mohli zavést 6 Různá důležitost procesů 13 Strategické plánování 16 Provedení strategické analýzy

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

MBI - technologická realizace modelu

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

Více

Informační systém pro centrální správu lokální sítě a služeb ISP

Informační systém pro centrální správu lokální sítě a služeb ISP MASARYKOVA UNIVERZITA Fakulta informatiky PV098 Řízení implementace IS semestrální práce Informační systém pro centrální správu lokální sítě a služeb ISP Jiří Kratochvíla, učo 207622, semestr 6, ročník

Více

PŘÍLOHA C Požadavky na Dokumentaci

PŘÍLOHA C Požadavky na Dokumentaci PŘÍLOHA C Požadavky na Dokumentaci Příloha C Požadavky na Dokumentaci Stránka 1 z 5 1. Obecné požadavky Dodavatel dokumentaci zpracuje a bude dokumentaci v celém rozsahu průběžně aktualizovat při každé

Více

Cíl vzdělávacích modulů:

Cíl vzdělávacích modulů: PŘÍLOHA č. 9 OBSAH VZDĚLÁVACÍHO PROGRAMU Projekt rozšiřuje nabídku dalšího vzdělávání prostřednictvím vytvoření vzdělávacího programu se speciální SW aplikací a skripty pro personalisty a vedoucí pracovníky,

Více

Prof. Ing. Miloš Konečný, DrSc. Nedostatky ve výzkumu a vývoji. Klíčové problémy. Tyto nedostatky vznikají v následujících podmínkách:

Prof. Ing. Miloš Konečný, DrSc. Nedostatky ve výzkumu a vývoji. Klíčové problémy. Tyto nedostatky vznikají v následujících podmínkách: Podnik je konkurenčně schopný, když může novými výrobky a službami s vysokou hodnotou pro zákazníky dobýt vedoucí pozice v oboru a na trhu. Prof. Ing. Miloš Konečný, DrSc. Brno University of Technology

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

Zákon o kybernetické bezpečnosti základní přehled. Luděk Novák ludekn@email.cz, 603 248 295

Zákon o kybernetické bezpečnosti základní přehled. Luděk Novák ludekn@email.cz, 603 248 295 Zákon o kybernetické bezpečnosti základní přehled Luděk Novák ludekn@email.cz, 603 248 295 Obsah Zákon č. 181/2014 Sb., o kybernetické bezpečnosti Vyhláška č. 316/2014 Sb., vyhláška o kybernetické bezpečnosti

Více

Obsah. 1. část Definice projektových cílů

Obsah. 1. část Definice projektových cílů Předmluva 1 Proč je řízení projektů tak důležité 1 Komu je kniha určena 1 Pojetí výkladu řízení projektů v této knize 2 Užitečné a unikátní rysy knihy 2 Jak je kniha uspořádána 3 Poděkování 4 1. Co je

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

Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace

Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace B5 Program Téma obsahuje informace o programech a programovém řízení a klade si za cíl především vysvětlit

Více

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

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

Více

Zápočtová úloha z předmětu KIV/ZSWI DOKUMENT SPECIFIKACE POŽADAVKŮ

Zápočtová úloha z předmětu KIV/ZSWI DOKUMENT SPECIFIKACE POŽADAVKŮ Zápočtová úloha z předmětu KIV/ZSWI DOKUMENT SPECIFIKACE POŽADAVKŮ 10. 5. 2011 Tým: Simplesoft Členové: Zdeněk Malík Jan Rada Ladislav Račák Václav Král Marta Pechová malikz@students.zcu.cz jrada1@students.zcu.cz

Více

Popisná statistika kvantitativní veličiny

Popisná statistika kvantitativní veličiny StatSoft Popisná statistika kvantitativní veličiny Protože nám surová data obvykle žádnou smysluplnou informaci neposkytnou, je žádoucí vyjádřit tyto ve zhuštěnější formě. V předchozím dílu jsme začali

Více

JRV.CZ s.r.o. Bulharská 4 612 00 Brno www.rosadata.cz. RosaData TM DEVELOPERSKÝ PROJEKT

JRV.CZ s.r.o. Bulharská 4 612 00 Brno www.rosadata.cz. RosaData TM DEVELOPERSKÝ PROJEKT RosaData TM DEVELOPERSKÝ PROJEKT OBSAH Úvod... 4 Developerský projekt... 5 Seznam developerských projektů... 5 Základní údaje... 6 Popis... 7 Technické detaily... 8 Reality... 11 Foto... 13 Obchodní případ...

Více

Představení projektu Metodika

Představení projektu Metodika Představení projektu Metodika přípravy veřejných strategií Strategické plánování a řízení v obcích metody, zkušenosti, spolupráce Tematická sekce Národní sítě Zdravých měst Praha, 10. května 2012 Obsah

Více

B2 Organizace jako systém

B2 Organizace jako systém Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace B2 Organizace jako systém Toto téma obsahuje informace o způsobech a přístupech k řízení organizace jako

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

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

D1 Trvalá organizace

D1 Trvalá organizace Projektový manažer 250+ Kariéra projektového manažera začíná u nás! D Útvarové a procesní řízení D1 Trvalá organizace Toto téma obsahuje informace o trvalé organizaci, jejích základních principech a prostředí.

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

1 Strukturované programování

1 Strukturované programování Projekt OP VK Inovace studijních oborů zajišťovaných katedrami PřF UHK Registrační číslo: CZ.1.07/2.2.00/28.0118 1 Cíl Seznámení s principy strukturovaného programování, s blokovou strukturou programů,

Více

Databázové systémy. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz

Databázové systémy. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Databázové systémy Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Vývoj databázových systémů Ukládání dat Aktualizace dat Vyhledávání dat Třídění dat Výpočty a agregace 60.-70. léta Program Komunikace Výpočty

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

Neuronové časové řady (ANN-TS)

Neuronové časové řady (ANN-TS) Neuronové časové řady (ANN-TS) Menu: QCExpert Prediktivní metody Neuronové časové řady Tento modul (Artificial Neural Network Time Series ANN-TS) využívá modelovacího potenciálu neuronové sítě k predikci

Více

Logický rámec projektu (Logical Framework Matrix LFM)

Logický rámec projektu (Logical Framework Matrix LFM) Logický rámec projektu (Logical Framework Matrix LFM) Při přípravě, realizaci, monitorování a hodnocení programů a projektů se obvykle uplatňuje ve vyspělých zemích i v mezinárodních organizacích (EU,

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

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

Úvodní přednáška. Význam a historie PIS

Úvodní přednáška. Význam a historie PIS Úvodní přednáška Význam a historie PIS Systémy na podporu rozhodování Manažerský informační systém Manažerské rozhodování Srovnávání, vyhodnocování, kontrola INFORMACE ROZHODOVÁNÍ organizace Rozhodovacích

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

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

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

Nabídka seminářů a poradenství v oblasti kvality

Nabídka seminářů a poradenství v oblasti kvality Nabídka seminářů a poradenství v oblasti kvality Trlicova 64 721 164 495 Trlicova 64 2 721 164 495 Zavádíte některou z metod řízení kvality, procesní řízení, potýkáte se strategickým plánováním? Potřebujete

Více

RDF DSPS ROZVOJ PORTÁLU

RDF DSPS ROZVOJ PORTÁLU RDF DSPS ROZVOJ PORTÁLU ČEZ Distribuce, a.s. HSI, spol. s r.o. Zbyněk Businský Miroslav Kaňka ZÁKAZNÍK A DODAVATEL ČEZ DISTRIBUCE, A.S. ČEZ distribuční síť Od r. 2012 implementován GEOPORTÁL (1. ETAPA),

Více

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

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

Více

Přednáška č.13. Organizace firmy při zahraniční činnosti

Přednáška č.13. Organizace firmy při zahraniční činnosti Přednáška č.13 Organizace firmy při zahraniční činnosti Organizační struktura Organizační struktura je vedením určený systém hierarchicky rozčleněných míst, útvarů, skupin (organizačních jednotek). Cílem

Více

Hospodářská informatika

Hospodářská informatika Hospodářská informatika HINFL, HINFK Vytvořeno s podporou projektu Průřezová inovace studijních programů Lesnické a dřevařské fakulty MENDELU v Brně (LDF) s ohledem na disciplíny společného základu reg.

Více

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

Vysoká škola technická a ekonomická v Českých Budějovicích. Institute of Technology And Business In České Budějovice 8. DISPOZICE PROJEKTU, MANAŽER PROJEKTU, ČLENOVÉ PROJEKTOVÉHO TÝMU, PLÁNOVACÍ PROCES Vysoká škola technická a ekonomická v Českých Budějovicích Institute of Technology And Business In České Budějovice

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

RiJ ŘÍZENÍ JAKOSTI L 1 1-2

RiJ ŘÍZENÍ JAKOSTI L 1 1-2 RiJ ŘÍZENÍ JAKOSTI ML 1-2 Normy řady ISO 9000 0 Úvod 1 Předmět QMS podle ISO 9001 2 Citované normativní dokumenty 3 Termíny a definice 4 Systém managementu kvality 5 Odpovědnost managementu 6 Management

Více

TEORIE ZPRACOVÁNÍ DAT

TEORIE ZPRACOVÁNÍ DAT Vysoká škola báňská - Technická univerzita Ostrava Fakulta elektrotechniky a informatiky TEORIE ZPRACOVÁNÍ DAT pro kombinované a distanční studium Jana Šarmanová Ostrava 2003 Jana Šarmanová, 2003 Fakulta

Více

EKONOMICKÝ A LOGISTICKÝ SOFTWARE. Luhačovice 24.10.2013

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

Více

Pracovní celky 3.2, 3.3 a 3.4 Sémantická harmonizace - Srovnání a přiřazení datových modelů

Pracovní celky 3.2, 3.3 a 3.4 Sémantická harmonizace - Srovnání a přiřazení datových modelů Pracovní celky 3.2, 3.3 a 3.4 Sémantická harmonizace - Srovnání a datových modelů Obsah Seznam tabulek... 1 Seznam obrázků... 1 1 Úvod... 2 2 Metody sémantické harmonizace... 2 3 Dvojjazyčné katalogy objektů

Více

VÝUKOVÝ MATERIÁL. Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632 Číslo projektu

VÝUKOVÝ MATERIÁL. Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632 Číslo projektu VÝUKOVÝ MATERIÁL Identifikační údaje školy Vyšší odborná škola a Střední škola, Varnsdorf, příspěvková organizace Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632

Více

Lenka Fialová Martina Procházková Ondřej Soukup Martin Valenta Cyril Vojáček

Lenka Fialová Martina Procházková Ondřej Soukup Martin Valenta Cyril Vojáček Lenka Fialová Martina Procházková Ondřej Soukup Martin Valenta Cyril Vojáček 1 Obsah prezentace Představení produktu Detailnějsí provedení produktem Zhodnocení projektu 2 Projektový management pro inženýrství

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

MAPY POVODŇOVÉHO NEBEZPEČÍ, DOKUMENTACE OBLASTÍ S VÝZNAMNÝM

MAPY POVODŇOVÉHO NEBEZPEČÍ, DOKUMENTACE OBLASTÍ S VÝZNAMNÝM MAPY POVODŇOVÉHO NEBEZPEČÍ, DOKUMENTACE OBLASTÍ S VÝZNAMNÝM POVODŇOVÝM RIZIKEM, PLÁN PRO ZVLÁDÁNÍ POVODŇOVÝCH RIZIK ZKUŠENOSTI ZE ZPRACOVÁNÍ ÚKOLŮ SMĚRNICE 2007/60/ES V ČESKÉ REPUBLICE J. Cihlář, M. Tomek,

Více

ISO 9001 : 2015. Certifikační praxe po velké revizi

ISO 9001 : 2015. Certifikační praxe po velké revizi ISO 9001 : 2015 Certifikační praxe po velké revizi Audit Audit z lat. auditus, slyšení Vzhledem k rozsahu prověřování se audit obvykle zabývá jen vzorky a jeho výsledek tedy neznamená naprostou jistotu,

Více