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

Ţivotní cyklus IS Vývoj informačních systémů Vývoj infor

Ţivotní cyklus IS Vývoj informačních systémů Vývoj infor Ţivotní cyklus IS Vývoj informačních systémů Motivace Doposud jsme předpokládali, ţe IS někdo vytvořil, ţe perfektně funguje a nijak se v čase nevyvíjí To ovšem naprosto není pravda. Vůbec jsme se nezabývali

Více

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

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

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

Více

Řízení projektů. Konstrukce síťového grafu pro řízení projektů Metoda CPM Metoda PERT

Řízení projektů. Konstrukce síťového grafu pro řízení projektů Metoda CPM Metoda PERT Řízení projektů Konstrukce síťového grafu pro řízení projektů Metoda CPM Metoda PERT 1 Úvod základní pojmy Projekt souhrn činností, které musí být všechny realizovány, aby byl projekt dokončen Činnost

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

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

CASE. Jaroslav Žáček

CASE. Jaroslav Žáček CASE Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Co znamená CASE? Definice dle SEI A CASE tool is a computer-based product aimed at supporting one or more software engineering activities

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

Management projektu III. Fakulta sportovních studií přednáška do předmětu Projektový management ve sportu

Management projektu III. Fakulta sportovních studií přednáška do předmětu Projektový management ve sportu Management projektu III. Fakulta sportovních studií 2016 5. přednáška do předmětu Projektový management ve sportu doc. Ing. Petr Pirožek,Ph.D. Ekonomicko-správní fakulta Lipova 41a 602 00 Brno Email: pirozek@econ.muni.cz

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

PROBLÉMY A SPECIFIKA VÝVOJE SOFTWARE

PROBLÉMY A SPECIFIKA VÝVOJE SOFTWARE PROBLÉMY A SPECIFIKA VÝVOJE SOFTWARE Vývoj prvních programů byl prováděn nadšenci, programy byly šité na míru. Žádná metodika vývoje SW v té době neexistuje. Vývoj SW byl vnímán jako výzkum. Cíl, co bude

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

Seznam zkratek PRVNÍ ČÁST. Lidské dovednosti a technické nástroje 1 Úvod k první části 3

Seznam zkratek PRVNÍ ČÁST. Lidské dovednosti a technické nástroje 1 Úvod k první části 3 Seznam zkratek xi PRVNÍ ČÁST Lidské dovednosti a technické nástroje 1 Úvod k první části 3 Co je to projektové řízení? 3 Proč projektové řízení? 4 Požadavky na technické dovednosti 4 Požadavky na umění

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

NÁSTROJE A TECHNIKY PROJEKTOVÉHO MANAGEMENTU

NÁSTROJE A TECHNIKY PROJEKTOVÉHO MANAGEMENTU NÁSTROJE A TECHNIKY PROJEKTOVÉHO MANAGEMENTU Projektová dekompozice Přednáška Teorie PM č. 2 Úvod do vybraných nástrojů projektového managementu Úvodní etapa projektu je nejdůležitější fáze projektu. Pokud

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

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

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 rizika Bc. Ing. Karina Mužáková, Ph.D. BIVŠ,

Management rizika Bc. Ing. Karina Mužáková, Ph.D. BIVŠ, Management rizika Bc. Ing. Karina Mužáková, Ph.D. BIVŠ, 2015 1 5/ Řízení rizika na úrovni projektu, podniku a v rámci corporate governance. BIVŠ, 2015 2 Definice projektu říká, že se jedná o činnost, která

Více

ANALÝZA A PROJEKTOVÁNÍ SYSTÉMŮ Řízení projektů zavádění IS

ANALÝZA A PROJEKTOVÁNÍ SYSTÉMŮ Řízení projektů zavádění IS ANALÝZA A PROJEKTOVÁNÍ SYSTÉMŮ Řízení projektů zavádění IS Roman Danel VŠB TU Ostrava HGF Institut ekonomiky a systémů řízení Literatura Staníček, Z, - Hajkr, J.: Řízení projektů zavádění IS do organizací.

Více

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

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

Více

Analýza. Roman Danel 1. Metody analýzy

Analýza. Roman Danel 1. Metody analýzy Analýza Analýza je vědecká metoda založená na dekompozici celku na elementární části, je to metoda zkoumání složitějších skutečností rozkladem (dissolution) na jednodušší. Cílem analýzy je tedy identifikovat

Více

Systémy pro podporu rozhodování. Hlubší pohled 2

Systémy pro podporu rozhodování. Hlubší pohled 2 Systémy pro podporu rozhodování Hlubší pohled 2 1 Připomenutí obsahu minulé přednášky Motivační příklad Konfigurace DSS Co to je DSS? definice Charakterizace a možnosti DSS Komponenty DSS Subsystém datového

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

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

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 24. Otázka : Implementační fáze. Postupy při specifikaci organizace softwarových komponent pomocí UML. Mapování modelů na struktury programovacího

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

Časové rezervy. Celková rezerva činnosti

Časové rezervy. Celková rezerva činnosti Časové rezervy Celková rezerva činnosti CR Volná rezerva činnosti VR Nezávislá rezerva činnosti - NR Celková rezerva činnosti Maximální počet časových jednotek, které jsou k dispozici pro provedení činnosti,

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

Chyby software. J. Sochor, J. Ráček 1

Chyby software. J. Sochor, J. Ráček 1 Chyby software J. Sochor, J. Ráček 1 Výsledek projektu Úspěšný: Projekt je dokončen včas, bez překročení rozpočtu, se všemi specifikovanými rysy a funkcemi. S výhradami: Projekt je dokončen a funkční,

Více

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

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

Více

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

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

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

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

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

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

2 Životní cyklus programového díla

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

Více

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

Metodika věcného auditu projektu Příloha č. 06. Kariéra projektového manažera začíná u nás! CHECK-LIST. Celkové zhodnocení projektu

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

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

Časový rozvrh. Agenda. 1 PŘÍPRAVA K CERTIFIKACI IPMA

Časový rozvrh. Agenda.  1 PŘÍPRAVA K CERTIFIKACI IPMA PŘÍPRAVA K CERTIFIKACI IPMA MS Project Časový rozvrh 2 09:00 10:30 blok 1 10:30 10:45 přestávka 10:45 12:00 blok 2 12:00 13:00 oběd 13:00 14:15 blok 3 14:15 14:30 přestávka 14:30 16:00 blok 4 Agenda 3

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

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

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

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

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

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

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

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

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

Více

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

1. VYMEZENÍ ODBORNÉ STÁŽE

1. VYMEZENÍ ODBORNÉ STÁŽE 1. VYMEZENÍ ODBORNÉ STÁŽE Šablona stáže představuje základní rámec odborné stáže pro typovou pozici a obsahuje požadavky na obsah a průběh stáže, na stážistu i na poskytovatele stáže. Bílá pole označují

Více

Charakteristické rysy projektů

Charakteristické rysy projektů Řízení projektů Charakteristické rysy projektů Cíl projektu Trojrozměrný cíl (věcné provedení, časový plán, rozpočtové náklady) = trojimperativ Jedinečnost Každý projekt je jedinečný Zdroje Realizace pomocí

Více

A3RIP Řízení projektů. 6. seminář

A3RIP Řízení projektů. 6. seminář A3RIP Řízení projektů 6. seminář 24. 10. 2012 Obsah 1. od iniciace k plánovaní 2. plánování projektu fáze projektu činnosti (WBS) čas (Ganttův diagram, síťové diagramy) zdroje náklady rizika 3. bonusový

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

1. Integrační koncept

1. Integrační koncept Příloha č. 2: Technický popis integrace 1. Integrační koncept Z hlediska koncepčního budování Smart Administration na Magistrátu města Mostu je možno hovořit o potřebě integrace tří úrovní systémové architektury

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

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

Aplikace modelu CAF 2006 za podpory procesního řízení. Ing. Vlastimil Pecka Ing. Zdeněk Havelka, PhD.

Aplikace modelu CAF 2006 za podpory procesního řízení. Ing. Vlastimil Pecka Ing. Zdeněk Havelka, PhD. Aplikace modelu CAF 2006 za podpory procesního řízení Ing. Vlastimil Pecka Ing. Zdeněk Havelka, PhD. Cíle prezentace 1. Přiblížit důvody zavádění modelu CAF 2009 za podpory procesního řízení. 2. Shrnutí

Více

ČÁST 1. Rozhodující koncepce odhadů. Co je Odhad? 25

ČÁST 1. Rozhodující koncepce odhadů. Co je Odhad? 25 Stručný obsah Část 1: Rozhodující koncepce odhadů 23 Kapitola 1 Co je Odhad? 25 Kapitola 2 Jak dobré odhady děláte? 37 Kapitola 3 Hodnota přesných odhadů 43 Kapitola 4 Odkud se berou chyby v odhadech?

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

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

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

Více

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

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

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

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

Řízení projektů. Centrální podpora projektového řízení projektů realizovaných MVČR (CEPR) Praha,

Řízení projektů. Centrální podpora projektového řízení projektů realizovaných MVČR (CEPR) Praha, Řízení projektů Centrální podpora projektového řízení projektů realizovaných MVČR (CEPR) Praha, 6. 12. 2012 Představení Zpracovatel: SOFO Group a.s. Ovocný trh 572/11 Praha 1 Projektový tým zpracovatele:

Více

CW52 Modelování výrobních procesů PPT #02 Plánování a řízení stavebních procesů pomocí MS Project Ing. Václav Venkrbec

CW52 Modelování výrobních procesů PPT #02 Plánování a řízení stavebních procesů pomocí MS Project Ing. Václav Venkrbec CW52 Modelování výrobních procesů PPT #02 Plánování a řízení stavebních procesů pomocí MS Project Ing. Václav Venkrbec Projektové řízení Co jsou projekty? Na začátku každého projektu dáváme tři sliby (navzájem

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

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

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

Modelování procesů s využitím MS Visio.

Modelování procesů s využitím MS Visio. Modelování procesů s využitím MS Visio jan.matula@autocont.cz Co je to modelování procesů? Kreslení unifikovaných či standardizovaných symbolů, tvarů a grafů, které graficky znázorňují hlavní, řídící nebo

Více

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

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

Více

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

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

Více

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

Vývoj IS - strukturované paradigma II

Vývoj IS - strukturované paradigma II Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 05 1/18 Vývoj IS - strukturované paradigma II Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta informačních

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

Systém managementu jakosti ISO 9001

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

Více

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

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

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

Více

AUDITY Hlavním cílem každého auditu musí být zjišťování faktů, nikoli chyb!

AUDITY Hlavním cílem každého auditu musí být zjišťování faktů, nikoli chyb! AUDITY Audity představují nezávislý zdroj informací a týkají se všech podnikových procesů, které tvoří systém zabezpečování jakosti podniku.audity znamenají tedy systematický, nezávislý a dokumentovaný

Více

Kapitola 1: Úvod. Systém pro správu databáze (Database Management Systém DBMS) Účel databázových systémů

Kapitola 1: Úvod. Systém pro správu databáze (Database Management Systém DBMS) Účel databázových systémů - 1.1 - Kapitola 1: Úvod Účel databázových systémů Pohled na data Modely dat Jazyk pro definici dat (Data Definition Language; DDL) Jazyk pro manipulaci s daty (Data Manipulation Language; DML) Správa

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

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

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

Modely teorie grafů, min.kostra, max.tok, CPM, MPM, PERT

Modely teorie grafů, min.kostra, max.tok, CPM, MPM, PERT PEF ČZU Modely teorie grafů, min.kostra, max.tok, CPM, MPM, PERT Okruhy SZB č. 5 Zdroje: Demel, J., Operační výzkum Jablonský J., Operační výzkum Šubrt, T., Langrová, P., Projektové řízení I. a různá internetová

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é

Více

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

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

Více

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

Informační a znalostní systémy jako podpora rozhodování

Informační a znalostní systémy jako podpora rozhodování Informační systémy a technologie Informační a znalostní systémy jako podpora rozhodování Petr Moos - ČVUT VŠL Přerov listopad 2015 Analýza a syntéza systému Definici systému můžeme zapsat ve tvaru: S =

Více

Implementace informačního systému pro knihovnu Jiřího Mahena v Brně

Implementace informačního systému pro knihovnu Jiřího Mahena v Brně Mendelova univerzita v Brně Provozně ekonomická fakulta Implementace informačního systému pro knihovnu Jiřího Mahena v Brně Informační systémy (projektování) Vypracovali: Jakub Drobný, Jakub Mazal, Monika

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

Katalog služeb a podmínky poskytování provozu

Katalog služeb a podmínky poskytování provozu Příloha č. 1 Servisní smlouvy Katalog služeb a podmínky poskytování provozu Část P2_1 P2_1_Katalog služeb a podmínky poskytování provozu 1 Obsah 1 OBSAH... 2 2 DEFINICE POJMŮ... 3 3 DEFINICE SLUŽEB, KOMPONENT

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

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

Znalostní oblasti průřezové aktivity

Znalostní oblasti průřezové aktivity Znalostní oblasti průřezové aktivity Zajišťuje návaznost na okolí projektu a integraci dílčích komponent řízení projektu Procesy: Vymezení předmětu projektu (Project Charter projektový záměr viz Dokumenty

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

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