8.1 Charakteristika testování Principy testování Testovatelnost Black-box testování White-box testování
|
|
- Zbyněk Veselý
- před 8 lety
- Počet zobrazení:
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ů 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íceStátnice odborné č. 12
Státnice odborné č. 12 Projekt, správa projektů, správa požadavků. Odhad pracnosti, zdrojů, času a nákladů. SW metriky. Dekompoziční techniky, použití empirických vzorců. Plánování projektů, řízení projektů
Více14 Ú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íce14 Ú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íceSOFTWAROVÉ INŽENÝRSTVÍ
SOFTWAROVÉ INŽENÝRSTVÍ Plán a odhady projeku Ing. Ondřej Macek 2013/14 ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Příprava plánu projektu 3 Motivace k plánování Průběh projektu Bolest Dobré plánování Špatné
Více1 Úvod 1.1 Vlastnosti programového vybavení (SW)
1 Úvod 1.1 Vlastnosti programového vybavení (SW) - dávkové zpracování - omezená distribuce - zakázkový SW - distribuované systémy - vestavěná inteligence - laciný HW - vliv zákazníka 1950 1960 1970 1980
VíceX36SIN: 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
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íceKvalita 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íceNÁSTROJE A TECHNIKY PROJEKTOVÉHO MANAGEMENTU. Projektová dekompozice
NÁSTROJE A TECHNIKY PROJEKTOVÉHO MANAGEMENTU Projektová dekompozice Úvod do vybraných nástrojů projektového managementu METODY A TECHNIKY PROJEKTOVÉHO MANAGEMENTU Tvoří jádro projektového managementu.
VíceVysoká š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íceSemestrální práce z předmětu 4IT421 Téma: CMMI-DEV v.1.3 PA Project Monitoring and Control
VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE náměstí W. Churchilla 4, 130 67 Praha3 Semestrální práce z předmětu 4IT421 Téma: CMMI-DEV v.1.3 PA Project Monitoring and Control Jméno a příjmení: Michal Hendrich Školní
VíceTREND 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íce5 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íceProjektový management
Projektový management Osnova - Metody a techniky plánování projektu - Časové plány a jejich úrovně - Ganttův diagram a síťový graf - Strukturní plán, dokumentace staveb Ing. Jana Nováková Ústav stavební
VíceManagement 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íceP 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íceBezepeč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íceCASE. 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íceNÁ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Ří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íce5 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ícePROBLÉ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Ú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íceManagement. 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íceAnalý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íce24.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íceAnalý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íceTÉ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íceCASE nástroje. Jaroslav Žáček
CASE nástroje Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Co znamená CASE? A CASE tool is a computer-based product aimed at supporting one or more software engineering activities within
VíceManagement 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íceSeznam 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íceANALÝ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íceCobiT. 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íceSysté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íceMULTIMEDIÁ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íceChyby 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Č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íceArchitektury 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íceProjektové ří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íceIng. 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íceD8 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íceWORKFLOW. 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íceObsah. Zpracoval:
Zpracoval: houzvjir@fel.cvut.cz 03. Modelem řízený vývoj. Doménový (business), konceptuální (analytický) a logický (návrhový) model. Vize projektu. (A7B36SIN) Obsah Modelem řízený vývoj... 2 Cíl MDD, proč
VíceHodnocení rizik v resortu Ministerstva obrany
Hodnocení rizik v resortu Ministerstva obrany OBSAH Pojmy používané v procesu řízení rizik v MO Systém řízení rizik Proces řízení rizik Dokumenty systému řízení rizik Pojmy používané v procesu řízení rizik
Více2 Ž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íceAnalytická specifikace a její zpracování
Analytická specifikace a její zpracování Analýza Měla by odpovědět na otázku CO? Musí definovat konceptuální model řešeného problému datový model entity, vztahy, omezení funkční model služby pro záznam,
VíceKlasické 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ícekapitola 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íceDruhy a formy projektového managementu, projektový cyklus a úvod do vybraných nástrojů projektového managementu
Druhy a formy projektového managementu, projektový cyklus a úvod do vybraných nástrojů projektového managementu Druhy projektů Teoretická část Další možné členění projektů: Z pohledu základních rozlišovacích
VíceÚVOD DO SOFTWAROVÉHO INŽENÝRSTVÍ
ÚVOD DO SOFTWAROVÉHO INŽENÝRSTVÍ Předmětem softwarového inženýrství jsou metodiky pro řízení vývoje softwaru. Proč potřebujeme tyto metodiky? Čím je vývoje softwaru specifický oproti jiným odvětvím? SOFTWAROVÉ
VíceSPECIFIKA 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íceCharta 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íceBezpeč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íceMetodika 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íceProjektové ří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íceMichal 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íceZajiš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Č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íceA7B36SI2 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íceProcesní 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íceMATURITNÍ 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íceArchitektury Informačních systémů. Jaroslav Žáček
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íceProblé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íceMetodika analýzy. Příloha č. 1
Metodika analýzy Příloha č. 1 Příloha č. 1 1 Účel dokumentu Dokument popisuje závaznou metodiku systémové analýzy, je upraven na míru pro prostředí Podniku. Dokument je provázán s Podnikovou analýzou,
Více4EK212 Kvantitativní management. 7.Řízení projektů
4EK212 Kvantitativní management 7.Řízení projektů 6.5 Řízení projektů Typická aplikace teorie grafů Projekt = soubor činností Příklady: Vývoj a uvedení nového výrobku Výstavba či rekonstrukce objektu Plán
VícePOŘÍ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íce1. 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íce2. Systémová analýza SA návrhová část projektu = příručka projektu - systémový přístup k analýze problémů, nejdůležitější etapa projektu - podrobné st
1. IŘS, definice, třídění, projekt, životní cyklus IŘS systémy na zpracování získaných (naměřených) informací a jejich využití pro řízení IŘS : a) IS informační systémy systémy sběru a zpracování dat (hromadné),
VíceSOFTWAROVÉ 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íceTeorie 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ícePří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íce1. 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íceMBI - 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ČÁ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ícePří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ícewww.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Ří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ícePřístupy k řešení a zavádění spisové služby
Přístupy k řešení a zavádění spisové služby Miroslav Kunt Praha, 22. 3. 2016 Výběr SSl důležité okolnosti Je potřeba zájem vedení organizace, kompetentní pracovníci spisové služby, co největší přiblížení
VíceA3RIP Ří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íceCharakteristické 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íceObsah 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íceKATALOG 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íceKomunikační strategie a plán rozvoje portálu portal.gov.cz
Příloha č. 2 Výzvy - Detailní popis předmětu VZ Komunikační strategie a plán rozvoje portálu portal.gov.cz V rámci dodávky vznikne dokument s analýzou současného stavu Portálu veřejné správy (PVS), určením
Více19.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íceProcesy, 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ícePopis 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íceArchitektura 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íceProf. 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íceSpecifikace předmětu plnění Datová tržiště
Příloha 1 Specifikace předmětu plnění Datová tržiště Etapa 1 Analýza statistické domény produkčních statistik 1 Obsah ETAPA 1 ANALÝZA STATISTICKÉ DOMÉNY PRODUKČNÍCH STATISTIK... 3 1.1. Koncepční shrnutí...
VíceOSA. maximalizace minimalizace 1/22
OSA Systémová analýza metodika používaná k navrhování a racionalizaci systémů v podmínkách neurčitosti vyšší stupeň operační analýzy Operační analýza (výzkum) soubor metod umožňující řešit rozhodovací,
VíceAUDITY 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íceOutcome 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íceSmysl 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íceCo 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íceImplementace systému ISMS
Implementace systému ISMS Krok 1 Stanovení rozsahu a hranic ISMS Rozsah ISMS Krok 2 Definice politiky ISMS Politika ISMS Krok 3 Definice přístupu k hodnocení rizik Dokumentovaný přístup k hodnocení rizik
VíceZnalostní 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íceGlobální strategie, IT strategie, podnikové procesy. Jaroslav Žáček
Globální strategie, IT strategie, podnikové procesy 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 systémy?
VícePilotní ověření standardizace na agendě živnostenského podnikání. Projekt A121
Projekt A121 Východiska projektu A121 #1 Procesní modelování agend je v širším smyslu součástí programu transformace výkonu veřejné správy založený na procesním přístupu a standardizaci agend. Přináší
VíceImplementace 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