Vývoj informačních systémů Procesy při vývoji SW Metodiky

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

Download "Vývoj informačních systémů Procesy při vývoji SW Metodiky"

Transkript

1 Vývoj IS 4.blok Vývoj informačních systémů Procesy při vývoji SW Metodiky doc. Ing. Alena Buchalcevová, Ph.D

2 Agenda 2 So :00 11: procesy při vývoji SW referenční model procesů podle ISO/IEC Integrační model zralosti(cmmi) norma ISO/IEC pro velmi malé podniky metodiky pro vývoj SW, definice, prvky metodiky kategorizace metodik rigorózní metodiky charakteristika metodika RUP - best practices, fáze metodiky, možnosti přizpůsobení metodiky metodika MMDIS agilní metodiky - charakteristika, principy metodika OpenUP metodika MMSP

3 Proces vývoje softwaru definuje kdo, co, kdy a jak transformuje požadavky do hotového SW řešení vize a požadavky software 3

4 Proces vývoje softwaru dvě stránky jazyková UML procesní KatalogZajezdu Zajezd TerminZajezdu AdresaPrechodBydliste Adresa uliceacislo mesto psc stat AdresaTrvBydliste procesy životního cyklu softwaru metodiky např. Unified process Rational Unified Process (RUP) MMDIS, agilní metodiky a další 4

5 Prvky v oblasti SW procesů Jak zavést procesy? modely životního cyklu procesů Co? referenční modely procesů ISO/IEC ISO/IEC CMMI Jak dobře to děláme? posouzení procesů/organizace CMMI ISO/IEC návody na zavedení standardů zlepšování procesů CMMI ISO/IEC metodiky 5

6 MODEL ZRALOSTI CAPABILITY MATURITY MODEL 6

7 Model zralosti Capability Maturity Model je referenční model vyspělých postupů, který ve vymezených disciplínách posuzuje schopnost vykonávat činnosti, které jsou pro tyto disciplíny stanoveny původně několik zralostních modelů vyvinuty v Software Engineering Institute SEI History of CMMs CMM for Software v1.1 (1993) INCOSE SECAM (1996) Systems Engineering CMM v1.1 (1995) Software CMM EIA 731 SECM Integrated Product v2, draft C (1997) (1998) Development CMM (1997) v1.02 (2000) v1.1 (2002) 7 CMMI for Acquisition v1.2 (2007) CMMI for Development v1.2 (2006) CMMI for Development v 1.3 CMMI for Services v1.2 (2007)

8 CMMI for Development 8

9 CMMI for Development (CMMI DEV) v 1.3 je referenční model procesů, které pokrývají celý životní cyklus softwarového produktu (od návrhu, přes vývoj a následnou údržbu) Proces je v CMMI modelu definován jako sada vzájemně provázaných činností, které transformují vstupy na výstupy pro dosažení definovaného účelu. Model CMMI-DEV definuje 22 procesních oblastí. Procesní oblast (process area) je skupina navzájem spojených praktik, které pokud implementujeme kolektivně, naplní množinu cílů, jež jsou podstatné pro zlepšení dané oblasti. 9

10 10 zdroj: Extreme Programming, Six Sigma, CMMI How they work together A JPMorgan Case study

11 Dvě reprezentace - dva způsoby zlepšování procesů kontinuální stupňovitý Pro kontinuální zlepšování se používá úroveň způsobilosti (capability level), která je definována jako dosažení zlepšení procesů v určité procesní oblasti. Stupňovitá reprezentace pracuje s úrovní zralosti (maturity level), která představuje stupeň zlepšení procesů v rámci předdefinované množiny procesních oblastí, v nichž jsou dosaženy všechny definované cíle. 11

12 Dvě reprezentace v CMMI - DEV v. 1.2 zdroj: Mulač. CMMI, Cesta ke zlepšení zralosti organizace IT při budování IS 12 využívá předdefinované množiny procesních oblastí, která definuje cestu organizace ke zlepšení úrovně zralosti maturity level (1-5) umožňuje organizaci vybrat si oblast procesů nebo několik oblastí procesů a zlepšovat procesy v této oblasti úrovně způsobilosti capability level (0-5)

13 Přehled úrovní způsobilosti a zralosti v CMMI-DEV v 1.3 úroveň kontinuální reprezentace úrovně způsobilosti (capability levels) stupňovitá reprezentace úrovně zralosti (maturity levels) 0 neúplný (Incomplete) 1 vykonávaný (Performed ) úvodní (Initial ) 2 řízený (Managed ) řízená (Managed) 3 definovaný (Defined) definovaná (Defined ) 4 kvantitativně řízená (Quantitatively Managed ) 5 optimalizovaná (Optimizing) 13

14 Kontinuální reprezentace 14

15 Kontinuální reprezentace Proces na úrovni způsobilosti 0 - neúplný proces není vykonáván vůbec nebo jen částečně. Na této úrovni nejsou naplněny některé specifické cíle procesu. Proces na úrovni způsobilosti 1 - vykonávaný proces je takový proces, který vytváří pracovní produkty, specifické cíle procesní oblasti jsou splněny, ale proces není institucionalizován. Řízený proces je vykonávaný proces, který je plánován a realizován na základě politik, proces je monitorován, řízen, kontrolován a vyhodnocován na shodu s popisem. Definovaný proces je řízený proces, který je přizpůsobován specifickým podmínkám na základě postupů definovaných v organizaci. 15

16 Stupňovitá reprezentace 16

17 Stupňovitá reprezentace Organizational Performance Management úroveň zralosti 5 Causal Analysis and Resolution Organizational Process Performance úroveň zralosti 4 Quantitative Project Management Requirements Development Technical Solution Product Integration Verification Validation Decision Analysis and Resolution úroveň zralosti 3 Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Management Risk Management Project Planning Project Monitoring and Control 17 Supplier Agreement Management Requirements Management úroveň zralosti 2 Measurement and Analysis Process and Product Quality Assurance Configuration Management engineering project management process management support

18 Úrovně zralosti 18 úrovně zralosti 1 úvodní Initial 2 řízená Managed 3 definovaná Defined 4 kvantitativně řízená Quantitatively Managed 5 optimalizovaná Optimizing charakteristika softwarové procesy jsou náhodné a chaotické organizace nemají stabilní prostředí pro podporu procesů, reagují pouze na vzniklé problémy. organizace mají definovány a zavedeny postupy řízení projektu, procesy jsou disciplinované a i v případě stresu jsou vykonávány podle popisu procesy jsou dobře definovány a chápány a jsou popsány ve standardech, procedurách, nástrojích a metodách jsou definovány i standardy pro přizpůsobování procesů podle typu projektu procesy jsou řízeny s využitím kvantitativních technik jsou definovány metriky pro vybrané podprocesy, ty jsou měřeny a vyhodnocovány na základě toho je možné předpovídat výkon procesů procesy se neustále zlepšují na základě chápání příčin změn v průběhu procesů

19 Charakteristiky úrovní 19

20 Volba reprezentace 20 je možné zvolit jednu z reprezentací, ale i obě kontinuální reprezentace je flexibilnější pokud se CMMI používá pro zlepšení procesů umožňuje zlepšovat různé procesy na různé úrovni umožňuje zaměřit se na pro organizaci nejdůležitější procesy je to novější přístup, nejsou údaje o návratnosti stupňovitá reprezentace představuje systematický, strukturovaný přístup pro zlepšení procesů na bázi referenčního modelu krok po kroku po jednotlivých úrovních dosažení určité úrovně zralosti je východiskem pro další úroveň je vhodnější, pokud nevíte, kde začít a pokud organizace má méně zkušeností se zlepšováním procesů umožňuje zaměřit se na ty procesy, které jsou nutné pro danou úroveň zralosti je to prověřený přístup, řada případových studií demonstrujících návratnost investic

21 Přínosy CMMI 21 zdroj: Diane L. Gibson, Dennis R. Goldenson, Keith Kost: Performance Results of CMMI - Based Process Improvement

22 Výsledky zavedení CMMI 22 zdroj: Diane L. Gibson, Dennis R. Goldenson, Keith Kost: Performance Results of CMMI - Based Process Improvement

23 Výsledky zavedení CMMI 23

24 24

25 25

26 26

27 27

28 28

29 Souhrn CMMI Od roku 2006 bylo hlášeno 4846 posouzení Nejrychleji roste počet posouzení v Číně, Španělsku, Brazílii, Argentině, Indii Více než 66% posouzených organizací má méně než 100 zaměstnanců Většina posouzení je na stupni zralosti 2 a 3 Počet posouzení v USA a Číně představuje více než 55% všech posouzení Čína nyní hlásí více posouzení než USA 29

30 MEZINÁRODNÍ NORMY V OBLASTI PROCESŮ ŽIVOTNÍHO CYKLU 30

31 Norma ISO/IEC Procesy v životním cyklu softwaru Systems and software engineering Software life cycle processes definuje procesy, činnosti a úkoly, které je třeba provádět při dodávce, vývoji, provozu, údržbě a odstranění softwarového produktu (služby) a také procesy pro definování, řízení a zlepšování procesů životního cyklu softwaru nepředepisuje žádný specifický model životního cyklu softwaru, metodiku vývoje, metody ani techniky norma ISO/IEC byla vydána v roce 1995, v letech 2002 a 2004 prošla revizemi. V roce 2008 byla vydána revize, která harmonizuje procesy v životním cyklu softwaru s procesy v životním cyklu systému, tedy s normou ISO/IEC 15288:2002 Norma ISO/IEC 12207:2008 definuje 43 procesů v 7 procesních skupinách 31

32 ISO/IEC 12207:2008 Smluvní procesy Akvizice Dodávka Procesy podporující projekty na úrovni organizace Řízení modelu životního cyklu Procesy v kontextu systému Projektové procesy Plánování projektu Hodnocení a řízení projektu Řízení rozhodování Technické procesy Definice požadavků zainteresovaných Analýza požadavků systému Návrh architektury systému Implementace Softwarově specifické procesy Procesy implementace SW Implementace SW Analýza SW požadavků Návrh SW architektury Detailní návrh SW Procesy podpory SW Řízení dokumentace SW Řízení SW konfigurací Ověřování kvality SW Verifikace SW 32 Řízení infrastruktury Řízení portfolia projektů Řízení lidských zdrojů Řízení kvality Řízení rizik Řízení konfigurací Řízení informací Měření zdroj: ISO/IEC 12207: Systems and software engineering Software life cycle processes, 2008 Integrace systému Testování systému Instalace SW Podpora akceptace SW Provoz SW Údržba SW Odstranění SW Konstrukce SW Integrace SW Testování SW Doménové inženýrství Řízení znovupoužití aktiv Validace SW Review SW Audit SW Řešení problémů Procesy znovupoužití SW Řízení programu znovupoužití

33 Posuzování zralosti procesů Integrační model zralosti Capability Maturity Model Integration CMMI norma ISO/IEC definuje Model pro posouzení procesů (Process Assesment Model) 33

34 ISO/IEC CL 5 PA 5.1 PA 5.2 Optimalizovaný Inovace procesu Optimalizace procesu CL 4 PA 4.1 PA 4.2 Předvídatelný Měření procesu Kontrola procesu CL 3 PA 3.1 PA 3.2 Zavedený Vymezení procesu Zavedení procesu CL 2 PA 2.1 PA 2.2 Řízený Řízení výkonnosti Řízení pracovních produktů 34 CL 1 PA 1.1 Vykonávaný Výkonnost procesu CL 0 Nekompletní

35 POSUZOVÁNÍ SW PROCESŮ V MALÝCH PODNICÍCH 35

36 Malé a střední podniky (MSP) Small-and Medium Sized Enterprise (SME) v USA podnik s méně než 500 zaměstnanci v Evropě podnik s méně než 250 zaměstnanci anebo obratem menším než 50 miliónů euro OECD dělí MSP na mikro podniky (do 10 zaměstnanců), malé podniky (do 50 zaměstnanců), střední podniky (50 až 250 zaměstnanců). v Evropě tvoří mikro podniky 93% všech organizací v USA 56%. 36 A. Buchalcevová,

37 Vymezení kategorie velmi malých podniků v Evropě 85 % všech SW firem má méně než 10 zaměstnanců, v Kanadě (oblast Montrealu) 80% SW firem má méně než 25 zaměstnanců a více než 50% SW firem méně než 10 zaměstnanců, v Brazílii 70% všech SW firem má méně než 10 zaměstnanců. Na základě těchto průzkumů pracovní skupina WG24 v rámci ISO/IEC JTC1/SC7 definovala kategorii velmi malé podniky jako podniky s méně než 25 zaměstnanci. 37 A. Buchalcevová,

38 Specifika velmi malých podniků specifické byznys modely a byznys cíle malý podíl na trhu limitované finanční a lidské zdroje odlišná organizační struktura Proto vyžadují odlišný přístup k zavádění a posuzování softwarových procesů. 38 A. Buchalcevová,

39 Průzkum využívání norem a standardů v malých podnicích realizován pracovní skupinou WG24 v rámci ISO/IEC JTC1/SC7 v roce 2006 cílem bylo získat informace o využívání mezinárodních norem a dalších de facto standardů v malých podnicích a identifikovat problémy, které s jejich aplikací mají průzkumu se účastnilo 392 respondentů z 29 zemí včetně České republiky 228 respondentů, tj. 58% všech respondentů, byly podniky s méně než 25 zaměstnanci tedy VMP 39 A. Buchalcevová

40 Výsledky průzkumu využívání norem a standardů v malých podnicích více než 70% VMP uvedlo, že vyvíjí životně důležité systémy, systémy kritické pro poslání organizace anebo systémy pro státní správu v kategorii velmi malých podniků bylo certifikováno méně než 18% firem u firem s více než 25 zaměstnanci bylo certifikováno 53% firem 55% používá ISO normy 47% používá modely CMM, CMMI 40 A. Buchalcevová 40

41 Výsledky průzkumu využívání norem a standardů v malých podnicích/2 otázka proč firma standardy a normy nepoužívá nedostatek zdrojů (28%) standardy nejsou vyžadovány (24%) standardy jsou příliš byrokratické a nejsou k dispozici návody na jejich aplikaci(15%) 74% podniků uvedlo, že je pro ně velmi důležité získat certifikaci 40% podniků má zájem získat ISO certifikaci přes 62% malých podniků by ocenilo návody a příklady, jak zavést standardy a normy 55% vyjádřilo potřebu lehkých a snadno pochopitelných norem doplněných šablonami a vzory 41 A. Buchalcevová 41

42 Pracovní skupina WG24 v rámci ISO/IEC JTC1/SC7 - cíle pomoci malým organizacím vytvářet kvalitní software, vytvořit množinu profilů, které umožní postupně zlepšovat SW procesy, adresovat specifické potřeby trhu malých organizací vytvořením doménově specifických profilů, poskytnout příklady a snadno pochopitelné návody, poskytnout základnu pro spolupráci malých organizací, vyvinout škálovatelné profily a návody, které umožní velmi malým podnikům dosáhnout shody s normami: ISO/IEC ISO 9001:2000 posuzovat procesy dle ISO/IEC A. Buchalcevová 42

43 43 O Connor, R. Introduction to ISO/IEC software engineering standards

44 Zdroje pro normu ISO/IEC Systems and software engineering Software life cycle processes ISO/IEC Process Assesment ISO/IEC Guidelines for the application of ISO 9001:2000 to computer software 44 A. Buchalcevová

45 Mezinárodní norma Life-Cycle Profiles for Very Small Entities 45 A. Buchalcevová

46 Generic Profile Group Four profiles within the Generic Profile Group Profile Group Generic Generic Generic Generic Profile Advanced Intermediate Basic Entry Advanced Intermediate Basic Entry ISO/IEC 29110

47 Life-Cycle Profiles for Very Small Entities TR Basic Profile 47 A. Buchalcevová

48 Balíčky nasazení Deployment packages část 5.1 obsahuje návod, jak implementovat softwarové procesy ten je doplněn o tzv. balíčky nasazení pro každý proces obsažený v základním profilu je vytvořen balíček, který vysvětluje: smysl procesu cíl jeho zavedení způsob jeho zavedení doporučuje techniky a metody, které slouží k realizaci procesu obsahuje šablony dokumentů, které je třeba při realizaci procesu vytvářet balíčky budou volně dostupné ke stažení na internetu 48 A. Buchalcevová 48

49 Současný stav normy Current version: ISO/IEC and ISO/IEC , published in January Current version: ISO/IEC TR , ISO/IEC TR and ISO/IEC TR , published in 2011 and available from ISO/ITTF as a free download Current version: ISO/IEC TR : Management and engineering guide for the Entry profile has been published in English and French in September 2012 and are available from ISO/ITTF as a free download 49 Deployment packages A. Buchalcevová

50 Zdroje k normě ISO/IEC

51 Prvky v oblasti SW procesů Jak zavést procesy? modely životního cyklu procesů Co? referenční modely procesů ISO/IEC ISO/IEC CMMI Jak dobře to děláme? posouzení procesů/organizace CMMI ISO/IEC návody na zavedení standardů zlepšování procesů CMMI ISO/IEC metodiky 51

52 METODIKY BUDOVÁNÍ IS 52

53 Vymezení pojmu metodika Metodika vývoje softwaru Software Development Methodology Metodika vývoje IS IS Development Methodology je definována jako rámec používaný pro strukturalizaci, plánování a řízení procesu vývoje informačního systému. Metodika budování IS/ICT definuje principy, procesy, praktiky, role, techniky, nástroje a produkty používané při vývoji, údržbě a provozu informačního systému, a to jak z hlediska softwarově inženýrského, tak z hlediska řízení. 53 zdroj: VOŘÍŠEK, J. a kol. Principy a modely řízení podnikové informatiky. 1.vyd. Praha: Oeconomica, ISBN

54 Prvky metodiky dimenze fáze role principy činnosti vzory standardy praktiky techniky produkty procesy nástroje metriky 54 prostředí hodnoty - postoje

55 Stručná historie metodik 70. léta Rozvoj strukturovaných metodik Coad/Yourdon 80. léta Rozvoj komplexních metodik SSADM, Information Engineering 90. léta Rozvoj objektových metodik OMT, Booch, OOSE, Fusion Sjednocování objektových metodik, sjednocování notací UML, RUP Odlehčování metodik - agilní metodiky FDD, ASD, XP, Crystal, SCRUM Konvergence tradičních a agilních metodik tradiční metodiky obohacovány o agilní metody agilní metodiky škálovány na větší a distribuované projekty 55

56 Metodiky budování IS/ICT metodik je velké množství důvody různé technologie vyžadují různé techniky organizace se liší firemní kulturou každý jedinec je jedinečný každý tým je jedinečný projekty se liší velikostí projekty se liší důležitostí snaha prezentovat se komerční důvody 56

57 Kritéria pro kategorizaci metodik celý systém versus projekt rozsah metodiky váha metodiky přístup k vývoji způsob vývoje doména 57

58 Kritérium Celý systém versus projekt většina metodik vývoje SW se týká jednoho projektu například RUP projektové metodiky je třeba řídit vývoj informačního systému v rámci celé organizace globální metodiky - např. MMDIS, Enterprise Unified Process (EUP) rozšíření RUP na úroveň celé organizace 58

59 Kritérium Rozsah metodiky některé metodiky se zabývají jen návrhem a implementací SW jiné zahrnují i zavedení a údržbu datová organizační funkční/procesní technologická... sponzor vedoucí projektu koncový uživatel analytik návrhář tester dokumentátor 59 expert na doménu UST GAN DAN IMP ZAV PUR fáze životního cyklu projektu

60 Kritérium Váha metodiky methodology weight velikost metodiky x hustota metodiky velikost metodiky methodology size počet kontrolních prvků obsažených v metodice hustota metodiky methodology specific density míra podrobnosti a těsnost tolerance v metodice, vyžadovaná detailnost a konzistence prvků Podle tohoto kritéria rozlišujeme těžké metodiky lehké metodiky 60

61 Kritérium Přístup k vývoji a Způsob vývoje Přístup k vývoji strukturované metodiky RAD metodiky objektově orientované metodiky metodiky pro komponentový vývoj metodiky pro vývoj orientovaný na služby Způsob vývoje tradiční metodiky s vodopádovým životním cyklem metodiky pro iterativní a přírůstkový vývoj 61

62 Kritérium domény EAI BIN SCM ERP CRM ECO OIS CTM WKF ELE Enterprise Application Integration Business Intelligence Supply Chain Management Enterprise Resource Planning Customer Relationship Management e-commerce kancelářské systémy Content Management wokflow e-learning 62

63 Kritéria pro kategorizaci metodik celý systém versus projekt globální metodiky - v rámci celé organizace - např. MMDIS, Enterprise Unified Process (EUP), projektové metodiky - zabývají se vývojem části IS jeden projekt většina metodik například RUP rozsah metodiky pokrývající celý životní cyklus vývoje - např. MMDIS dílčí metodiky zabývají se jen částí životního cyklu IS - např. jen návrh a implementace podrobnost metodiky těžké metodiky - podrobný popis, rigorózní lehké metodiky - minimálně dostatečná metodika přístup k vývoji strukturované metodiky RAD metodiky objektově orientované metodiky metodiky pro komponentový vývoj metodiky pro vývoj orientovaný na služby 63 způsob vývoje tradiční metodiky s vodopádovým životním cyklem metodiky pro iterativní a přírůstkový vývoj doména

64 Do jaké míry je možné proces vývoje SW popsat? přesné a podrobné postupy jen principy 64 tradiční metodiky (rigorózní metodiky) agilní metodiky

65 Tradiční přístupy Agilní přístupy referenční modely procesů modely životního cyklu procesů iterativní a inkrementální model tradiční (rigorózní) metodiky agilní metodiky posouzení procesů/organizace 65

66 Tradiční - rigorózní metodiky vycházejí z předpokladů : požadavky je možné specifikovat předem, změnám se snažíme zabránit, jsou náročné velké množství meziproduktů ztrácí se cíl vývoje vytvořit fungující SW odpovídající potřebám uživatelů 66

67 Agilní metodiky lehké metodiky, nepopisují procesy, ale principy, málo dokumentace, dávají přednost osobní komunikaci zaměřeny na ty činnosti, které vytvářejí hodnotu, eliminují činnosti, které hodnotu nepřinášejí inovace a kreativita se rozvíjejí v chaosu, proto málo procesů, spíše praktiky 67

68 Rational Unified Process RUP dříve řazena mezi rigorózní metodiky, od roku 2003 se do ní vkládají agilní principy a praktiky dnes jde o rámec metodik, který lze škálovat a vytvořit jak těžkou metodiku, tak agilní metodiku RUP je komerční produkt, ale existuje volně dostupná metodika Unified Process dobře definovaný a strukturovaný SW inženýrský proces 68

69 Klíčové praktiky a principy Best Practices iterativní a inkrementální vývoj správa požadavků použití komponentové architektury vizuální modelování (UML) kontrola a ověřování kvality řízení změn vytvářejte jen to, co je nezbytné Lean procesy, agilita minimalizujte papírovou dokumentaci buďte flexibilní poučte se z chyb prověřujte rizika definujte cíle a metriky pokroku podpořte proces nástroji na vývoj SW 69

70 Vývoj řízený případy užití (Use Case) případ užití popisuje kompletní a smysluplné služby, které systém poskytuje uživatelům a jiným systémům případy užití řídí práci v průběhu iterace plánování iterace vytvoření a prověření architektury definice testovacích případů a procedur návrh uživatelského rozhraní a vytvoření uživatelské dokumentace Requirements Analysis & Design Use-Case Model Analysis & Design Model realized by Implementation Implementation Model implemented by 70 Test Test Model verified by

71 Praktika 1: iterativní a inkrementální vývoj Best Practices iterativní a inkrementální vývoj správa požadavků použití komponentové architektury vizuální modelování (UML) kontrola a ověřování kvality řízení změn 71

72 Problémy vodopádového modelu model předpokládá, že se všechny požadavky specifikují na začátku projektu, iterace jsou možné jen v rámci jedné fáze, případně je možné se vrátit k předchozí fázi, nemáme zpětnou vazbu od zákazníka, pozdní integrace systému, ke které dochází až po naprogramování všech modulů 72

73 Iterativní vývoj Požadavky Plánování Řízení projektu Analýza a návrh Implementace Testování 73 Ověřování výsledkem každé iterace je spustitelný produkt. Nasazení

74 Praktika 2: správa požadavků Best Practices iterativní a inkrementální vývoj správa požadavků použití komponentové architektury vizuální modelování (UML) kontrola a ověřování kvality řízení změn 74

75 Správa požadavků znamená ujistit se že řešíme správný problém vytváříme správný systém systematickým přístupem k získávání organizaci dokumentaci a řízení měnících se požadavků na SW Needs Features SW requirements Aspekty správy požadavků analýza problému pochopení uživatelských potřeb definice systému řízení rozsahu zpřesnění definice systému řízení měnících se požadavků 75

76 Požadavky Needs Features Problem Space Solution Space Software Requirements 76 Test Scripts Design User Docs

77 Praktika 3: použití komponentové architektury Best Practices iterativní a inkrementální vývoj správa požadavků použití komponentové architektury vizuální modelování (UML) kontrola a ověřování kvality řízení změn 77

78 Důvod použití komponentové architektury základ znovupoužitelnosti komponenty architektury základ řízení projektu plánování přidělování lidí dodávka řízení složitosti a integrity vrstvená komponentová architektura Applicationspecific Businessspecific Middleware 78 Systemsoftware

79 Praktika 4: vizuální modelování Best Practices iterativní a inkrementální vývoj správa požadavků použití komponentové architektury vizuální modelování (UML) kontrola a ověřování kvality řízení změn 79

80 Proč modelovat vizuálně? zachycuje strukturu i chování ukazuje, jak jednotlivé prvky spolupracují udržuje návrh a implementaci konzistentní skrývá detaily umožňuje přesnou komunikaci 80

81 Æ Á ¹ ¼ ëçñ º ±â»ç ëàú äã»çñ Ù. ÈÀÏ ü ÀÚ Â Àоî  ¹ ¼ÀÇ Á º ÇØ ç ¹ ¼ ü ¼³Á À» äã»çñ Ù. È é ü  ÀоîµéÀΠüµé ëçø ÀÌ º Î Á ÄÀ» ½ÃÄÑ È é º ÁØ Ù. 1: Doc view request ( ) 9: sortbyname ( ) L 2: fetchdoc( ) 3: create ( ) 6: filldocument ( ) 4: create ( ) 8: fillfile ( ) 5: readdoc ( ) 7: readfile ( ) Window95 ¹ ¼ ü Å óàì¾ðæ.exe Windows NT Windows NT ¹ ¼ ü Áø.EXE Windows95 IBM Mainframe µ ÀÌÅ º À̽º¼¹ö Solaris ÀÀ ë¼¹ö.exe Windows95 ¹ ¼ ü ¾ÖÇà Alpha UNIX Vizuální modelování v UML Use-Case Diagram Class Diagram Statechart Diagram umožňuje více pohledů poskytuje přesnou syntaxi a sémantiku add file Use Case 1 FileMgr DocumentList Document Actor A Use Case 2 Actor B fetchdoc( ) sortbyname( ) add( ) delete( ) FileList flist add( ) delete( ) 1 name : int docid : int numfield : int get( ) open( ) close( ) read( ) sortfilelist( ) create( ) filldocument( ) read() fill the code.. Openning add file [ numberoffile= =MAX ] / flag OFF close file Writing Use Case 3 Reading close file Closing Collaboration 9: sortbyname ( ) Diagram mainwnd : MainWnd 1: Doc view request ( ) rep Repository (from Persistence) name : char * = 0 readdoc( ) readfile( ) read( ) File GrpFile read( ) open( ) create( ) fillfile( ) FileManager Repository DocumentList Deployment Diagram 2: fetchdoc( ) 4: create ( ) gfile : GrpFile Document 8: fillfile ( ) user : Clerk filemgr : FileMgr 3: create ( ) 6: filldocument ( ) GraphicFile File FileList 7: readfile ( ) repository : Repository 5: readdoc ( ) document : Document 81 user mainwnd filemgr : FileMgr document : Document Sequence Diagram gfile repository Component Diagram Forward and Reverse Engineering Target System

82 Praktika 5: kontrola a ověřování kvality Best Practices iterativní a inkrementální vývoj správa požadavků použití komponentové architektury vizuální modelování (UML) kontrola a ověřování kvality řízení změn 82

83 Chápejte kvalitu jako základ vývoje, ne až zpětně náklady na opravu SW náklady ztracených příležitostí náklady ztracených zákazníků Oprava softwarových chyb stojí 100 až 1000 krát více, pokud se odhalí a opraví až po nasazení náklady 83 Inception Elaboration Construction Transition

84 Testujte každou iteraci Iteration 1 Iteration 2 Iteration 3 Iteration 4 modely a implementace Test Suite 1 Test Suite 2 Test Suite 3 Test Suite 4 testy 84 Často bývá levnější najít chybu pomocí testů implementace než kompletní kontrolou návrhu.

85 Praktika 6: řízení změn Best Practices iterativní a inkrementální vývoj správa požadavků použití komponentové architektury vizuální modelování (UML) kontrola a ověřování kvality řízení změn 85

86 Co řídíme? bezpečné pracoviště (workspace) pro každého vývojáře automatizované řízení integrace a sestavení (integration/build management paralelní vývoj Workspace Management Parallel Development Řízení změn je víc než check-in a check-out Process Integration REPORT ALERT Build Management 86 Aspekty řízení změn Change Request Management Configuration Status Reporting Configuration Management Change Tracking Version Selection Software Manufacture

87 Fáze a disciplíny RUP Horizontální osa - dynamický pohled na proces vývoje SW cykly, fáze, Fázeiterace a milníky Disciplíny Obchodní modelování Požadavky Analýza a návrh Implementace Testování Zavedení Konfigurační management Řízení proj ektu 87 Prostředí Vertikální osa - statické hledisko procesu, popis činností, artefaktů, pracovníků a pracovních toků 9 oblastí procesů, které představují logické seskupení činností definovaných v RUP

88 Iterace je definovaná posloupnost činností, která má stanovený plán a hodnotící kritéria a končí uvolněním (release) produktu plán iterace definuje artefakty, role a činnosti. iterace je měřitelná. iterace je časově omezená iterace je řízena riziky 88

89 Fáze iterativního vývoje hlavní milníky Inception Elaboration Construction Transition 89 Time cíl Inception: pochopit, co vytvářet vize, high-level požadavky, business case ne detailní požadavky Elaboration: pochopit, jak vytvářet architektura, detailizace většiny požadavků ne detailní design Construction: vytváření produktu fungující produkt, kompletní systémové testy Transition: prověření řešení akceptace

90 struktura obsahu Životní cyklus v RUP v jedné iteraci, se prochází všechny disciplíny 90 čas

91 Při plánování se používají různé úrovně podrobnosti Plán projektu hrubý jeden pro celý projekt Plán iterace podrobný příští iterace fáze a milníky co a kdy v rámci každé fáze iterace počet iterací předmět, délka aktuální iterace 91

92 Délka iterace typicky 2-8 týdnů Co vede k delším iteracím složité vztahy mezi zainteresovanými, zákonná a jiná omezení nezralé nástroje (správa verzí, IDE, testovací nástroje ) velký tým, málo zkušení členové týmu složitá technologie a architektura dlouhý projekt Příklady délky iterací 5 lidí, 1-2 týdny 20 lidí, 3-4 týdny 80 lidí, 8 týdnů 92

93 Metodika MMDIS principy a koncepty pro řízení informatiky

94 MMDIS Multidimensional Management and Development of Information System MMDIS metodika od roku 1992 vyvíjena na KIT VŠE návodem na způsob uvažování při vývoji IS/ICT z hlediska kategorizace MDIS 1992 metodika globální spíše lehká bez rozlišení domény pro různé přístupy k vývoji základem - multidimenzionalita, tj. řešení IS/ICT souběžně z různých pohledů MMDIS 1999 MeFIS MBI 2012

95 Cíl MMDIS cílem je vývoj a provoz integrovaného informačního systému, který optimálně využívá potenciálu dostupných informačních technologií (IT) k maximální podpoře podnikových cílů zajištění efektivní podpory podnikových cílů a podnikových procesů pomocí integrovaných informatických služeb, procesů a zdrojů 95 zdroj Alena prof. Voříšek Buchalcevová

96 Zásady MMDIS požadované služby a související funkcionalita IS jsou odvozeny od podnikových cílů a od potřeb podnikových procesů IS je realizován jako: komplexní integrovaný systém vytvořený z řady různých komponent a služeb různých dodavatelů, otevřený systém na bázi mezinárodních i podnikových standardů, IS je řízen, rozvíjen a provozován na základě jednotné metodiky a jednotné soustavy pravidel, 96 zdroj Alena prof. Voříšek Buchalcevová

97 MMDIS - charakteristika, struktura MMDIS skládá se z: 8 základních principů řízení 5 navzájem propojených konceptuálních modelů (konceptů) řízení metodika je otevřená - principy i koncepty se vyvíjejí spolu s vývojem: hospodářského prostředí informačních technologií metod řízení 97 zdroj Alena prof. Voříšek Buchalcevová

98 Principy MMDIS princip myšlenkový přístup k chápání a analýze problému a s ním spojené zásady (pravidla) řešení problému principy MMDIS jsou aplikovány v konceptech MMDIS principy jsou základem pro metody, techniky a nástroje řízení 8 základních principů metodiky MMDIS: multidimenzionalita integrace vrstvenost flexibilita otevřenost standardizace kooperace měřitelnost (metriky) 98 zdroj Alena prof. Voříšek Buchalcevová

99 Konceptuální modely MMDIS konceptuální model (koncept) objasňuje, jak chápat řízený systém souvisejí s ním metody, které jsou doporučením, jak daný systém řídit každý z modelů akcentuje jiné dimenze problematiky řízení 5 základních konceptuálních modelů metodiky MMDIS: architektura řízení firmy (model řízení podnikových procesů) integrace strategie, procesů, služeb a zdrojů (model SPSR) integrace oblastí řízení (model systémové integrace) rozvoj integrovaného IS (model tvorby a dalšího rozvoje IS) systém řízení IS (model řízení informatických procesů ve firmě) 99 zdroj Alena prof. Voříšek Buchalcevová

100 1. Princip: Multidimenzionalita Každý složitý problém je nutné analyzovat, hodnotit, navrhovat řešení a řídit z mnoha různých dimenzí (pohledů) Pravidla multidimenzionality: 1) identifikuj všechny dimenze, které významně ovlivňují řešení problému 2) vyřeš problém nejdříve v rámci každé dimenze 3) integruj dílčí řešení do výsledného řešení 100 zdroj Alena prof. Voříšek Buchalcevová

101 Dvě základní skupiny dimenzí 101 dimenze, které definují fáze vývoje IS/ICT úroveň integrace IS/ICT, použitá úroveň abstrakce časová dimenze řešení dimenze, které se aplikují v každé fázi vývoje - obsahové dimenze IS/ICT informační/datová (inf), procesní/funkční (pro), ekonomická/finanční (eko), organizační/legislativní (org), pracovní/sociální/etická (pra), softwarová (sw), hardwarová (hw), metodická (met), dokumentační (dok) manažerská (mng). zdroj Alena prof. Voříšek Buchalcevová

102 P2 P2 provozovaný IS GST IST MtS US GAN n PROJEKTU (některé z nich v provozu) DAN IM ZA PU mng dok P1... Pn... P1 met Pn hw 102 inf sw pro eko org pra zdroj Alena prof. Voříšek Buchalcevová

103 2. Princip: Integrace Každý složitý systém má mnoho komponent a mnoho vazeb mezi těmito komponentami. Provoz a vývoj systému je spojen s řízením těchto vazeb. Pravidla integrace: 1) identifikuj všechny vazby mezi komponentami, které jsou významné pro řešení problému 2) urči optimální charakteristiky každé vazby 3) uveď vazbu do optimálního stavu a neustále ji v tomto stavu udržuj 103 Příklad: IS se skládá minimálně z komponent - HW, SW, data a lidé. Vazba HW - SW určuje - na kterých počítačích je instalován který software, vazba SW- lidé určuje přístupová práva uživatelů k jednotlivým aplikacím,... zdroj Alena prof. Voříšek Buchalcevová

104 3. Princip: Vrstvenost Základem řešení problému je opakované použití abstrakce tak, že na každé nižší úrovni abstrakce řešíme zadaný problém pomocí podrobnější rozlišovací úrovně. Vrstva je tvořena objekty vzniklé aplikací stejné úrovně abstrakce. A A V (j+ 1 ) B C D A V (j) A V (j-1 ) 104 zdroj Alena prof. Voříšek Buchalcevová

105 4. Princip: Flexibilita Požadavky na chování systému a okolí systému se neustále vyvíjejí. Systém proto musí být schopen se těmto změnám přizpůsobovat, a to pokud možno snadno. Pravidla flexibility: 1) identifikuj oblasti očekávaných změn 2) komponenty a vazby systému dotčené očekávanými změnami navrhni jako parametrické 3) sleduj vývoj změn a dle nich upravuj hodnoty parametrů Příklady: možnost definovat účetní osnovu v účetním SW, personifikace uživatelského rozhraní, třídění došlé pošty dle různých kritérií, zdroj Alena prof. Voříšek Buchalcevová

106 5. Princip: Otevřenost Rozsáhlejší změny systému nejsou realizovatelné jen změnou parametrů, ale je třeba je řešit novou komponentou. Systém musí být otevřený ve smyslu snadného vyjímání starých a zabudovávání nových komponent od různých výrobců. Pravidla budování otevřeného systému: 1) Architekturu systému navrhni tak, aby se systém skládal z relativně nezávislých komponent 2) Využívej zejména standardizované komponenty, tzn. - při vývoji systému pokud možno nepoužívej komponenty, které díky svému nestandardizovanému rozhraní výrazně zmenšují možnost volby navazujících komponent 106 zdroj Alena prof. Voříšek Buchalcevová

107 6. Princip: Standardizace ISO9000 ISO Opakované řešení problému se zjednoduší a zlevní, použijeme-li standardy. Na některá řešení se vztahují závazné standardy - zákony, směrnice, normy. Pravidla standardizace: 1) identifikuj mezi komponentami a jejich vazbami ty, které podléhají závazným standardům 2) aplikuj závazné standardy 3) identifikuj mezi komponentami a jejich vazbami ty, které je vhodné dále standardizovat 4) navrhni a aplikuj standardy pro tyto případy 107 Příklad: finanční SW musí respektovat daňové zákony, je vhodné standardizovat uživatelské rozhraní všech aplikací IS,... zdroj Alena prof. Voříšek Buchalcevová

108 7. Princip: Kooperace Klíčem úspěchu v globální ekonomice je určit vlastní unikátní znalosti a kompetence, o které se opře podnikatelský záměr a ostatní potřebné znalosti a kompetence získat od obchodních partnerů. Pravidla kooperace: 1) identifikuj svoje unikátní znalosti, kompetence a zdroje 2) identifikuj ostatní potřebné znalosti, služby, zdroje,... 3) integruj interní a externí znalosti, služby a zdroje 4) sdílej znalosti, služby a zdroje se svými partnery Příklad: outsourcing podnikového stravování, outsourcing vývoje, resp. provozu IS/ICT, ASP, zdroj Alena prof. Voříšek Buchalcevová

109 8. Princip: Měřitelnost (metriky) Co nelze měřit nelze ani řídit Pravidla měření: 1) identifikuj, co je třeba měřit 2) urči vhodné metriky, způsob získávání a optimální hodnoty 3) měř a vyhodnocuj naměřené hodnoty metrik 4) je-li hodnota mimo určený interval - proveď zásah Příklad: zisk za uplynulý rok, objem služeb realizovaných na trhu v ČR, dostupnost funkcí IS, zákaznická spokojenost, počet koncových stanic, zdroj Alena prof. Voříšek Buchalcevová

110 Konceptuální modely MMDIS 1. architektura řízení firmy (model řízení podnikových procesů) 2. integrace strategie, procesů, služeb a zdrojů (model SPSR) 3. integrace oblastí řízení (model systémové integrace) 4. rozvoj integrovaného IS (model tvorby a dalšího rozvoje IS) 5. systém řízení IS (model řízení informatických procesů ve firmě) 110 zdroj Alena prof. Voříšek Buchalcevová

111 Agilní metodiky lehké metodiky, nepopisují procesy, ale principy, málo dokumentace, dávají přednost osobní komunikaci zaměřeny na ty činnosti, které vytvářejí hodnotu, eliminují činnosti, které hodnotu nepřinášejí inovace a kreativita se rozvíjejí v chaosu, proto málo procesů, spíše praktiky 111

112 Formy komunikace osobní komunikace písemná dokumentace 112 telefon videonahrávka

113 Manifest pro agilní vývoj SW podepsán v únoru 2001 Odhalili jsme lepší způsob vývoje SW, sami jej používáme a chceme pomoci i ostatním, aby jej používali. Z toho pohledu dáváme přednost: individualitám a komunikaci před procesy a nástroji provozuschopnému software před obsažnou dokumentací spolupráci se zákazníkem před sjednáváním kontraktu reakci na změnu před plněním plánu 113

114 Které metodiky řadíme mezi agilní? Adaptive Software Development (ASD), Dynamic Systems Development Method (DSDM), Feature-Driven Development (FDD), Extreme Programming (XP), Lean Development, SCRUM, Crystal metodiky, Agile Modeling nové metodiky OpenUP MSF for Agile SW development 114

115 Charakteristika agilních metodik lehké metodiky - minimálně dostatečná metodika nepopisují procesy, ale principy a praktiky zdroj: Alpine Ascents International Inc. obsahují málo dokumentace, dávají přednost osobní komunikaci soustředí se na činnosti, které vytvářejí hodnotu, eliminují činnosti, které hodnotu nepřinášejí přesouvají zodpovědnost za definování požadavků na zákazníka jsou založeny na spolupráci zákazníků a vývojářů 115 využívají individualit a silných stránek lidí

116 10 hlavních principů agilních metodik 1. Nejvyšší prioritou je včas a kontinuálně dodávat software, který zákazníkům přináší hodnotu. zákazníka zajímá, zda dostane fungující software v každé iteraci a zda poskytovaná funkcionalita uspokojí jeho potřeby, ty je však nutné neustále prověřovat, protože jsou předmětem změny 2. Změnu požadavků je možné provést i v pozdějších fázích vývoje, protože tím může zákazník získat konkurenční výhodu. je třeba realizovat krátké iterace (od dvou týdnů do dvou měsíců) a na jejich konci dodávat fungující software 116

117 10 hlavních principů agilních metodik 3. Uživatelé a vývojáři spolupracují denně na projektu. koncept specifikace požadavků - na začátku jen hrubé požadavky, které se potom na základě každodenních jednání s uživateli zpodrobňují a mění, přenesení odpovědnosti za projekt na uživatele. 4. Motivovaní jedinci, kteří mají vytvořeny podmínky pro práci a mají podporu vedení, jsou klíčovým faktorem úspěchu projektu. 5. Nejefektivnějším způsobem přenosu informací v rámci vývojového týmu je osobní komunikace. Agilním metodikám bývá vytýkána nedostatečná dokumentace. Dokumentace ale není cílem projektu. Smyslem dokumentace je pochopení problému, kterého se mnohem lépe, rychleji a s menšími náklady dosáhne používáním přímých technik komunikace. 117

118 10 hlavních principů agilních metodik 6. Primární mírou úspěchu je fungující software. 7. Agilní procesy předpokládají zdravý vývoj. Vývojáři běžně pracují přesčas a o víkendech, což zákonitě snižuje jejich produktivitu. Je třeba vymezit pracovní prostor (cca 40 hodin týdně), v jehož rámci zůstane tým v dobré kondici. 8. Perfektní technické řešení i návrh. Agilní přístupy zdůrazňují kvalitu návrhu, která je nezbytná pro realizaci změn. Návrh není samostatnou etapou, která je plně dokončena před zahájením implementace, ale je to iterativní činnost prováděná v průběhu projektu. 9. Zásadním požadavkem je jednoduchost řešení, tj. umění maximalizovat množství neudělané práce Nejlepší architektury, požadavky a návrhy vznikají ze samoorganizujících se týmů. Tento princip zdůrazňuje kreativitu lidí, častou komunikaci a přizpůsobování metodiky

119 předpoklady Porovnání rigorózních a agilních metodik rigorózní metodiky agilní metodiky SW procesy lze popsat požadavky je možné definovat předem SW procesy nelze popsat předem jen hrubé požadavky 119 přesně definované procesy, činnosti, artefakty standardní projekty, velké projekty jen generativní pravidla, praktiky a principy výzkumné projekty time-to-market menší týmy

120 OpenUP nová agilní metodika dostupná pod Eclipse Public License v1.0 minimálně dostatečná, kompletní metodika pro vývoj softwaru, která je snadno přizpůsobitelná a rozšiřitelná vznikla zeštíhlením metodiky Unified Process je založena na: iterativním a inkrementálním modelu životního cyklu případech užití řízení rizik architektuře 120

121 Stažení metodiky OpenUP Eclipse Process Framework Project (EPF) stažení publikované metodiky OpenUP stáhnout a uložit zip soubor rozbalit otevřít index.htm 121

122 V metodice je oddělen znovupoužitelný metodický obsah od jeho aplikace v procesu metodický obsah definuje produkty (work products), role (roles), úlohy (tasks) a návody (guidance) procesní obsah vyjadřuje časové hledisko a představuje životní cyklus projektu 122

123 3 úrovně metodického obsahu 123

124 Role zainteresovaná strana (stakeholder) analytik (analyst) architekt (architect) vývojář (developer) tester (tester) vedoucí projektu (project manager) kdokoli (any role) 124

125 Disciplína představuje skupinu úloh (tasks), které se týkají určité oblasti zájmu seskupení úloh do samostatných disciplín představuje efektivní způsob organizování obsahu, který usnadňuje pochopení disciplíny v OpenUP Požadavky Architektura Vývoj Testování Řízení projektu 125

126 Úlohy, pracovní produkty Úloha je jednotka práce vykonávaná určitou rolí (rolemi) OpenUP definuje 19 úloh v rámci úloh se vytvářejí, modifikují nebo používají pracovní produkty za vytvoření a změnu produktu je odpovědná určitá role produkty jsou předmětem verzování OpenUP definuje 17 produktů, které by se měly v projektu používat 126

127 Praktiky Open Source Practices for Agile Projects řídící praktiky technické praktiky (softwarově inženýrské) 127

128 Výsledný proces představuje kompletní a integrovanou procesní šablonu pro specifický typ projektu OpenUP definuje výsledný proces pro iterativní vývoj v rámci 4 fází 128

129 Metodika OpenUP pokrytí procesů referenčního modelu ISO/IEC

130 Metodika OpenUP - grafické vyjádření hodnot kritérií skupiny Produkt a Lidé minimální a maximální hodnoty kritérií optimální hodnoty kritérií 130

131 Metodika OpenUP - grafické vyjádření hodnot kritérií skupiny Proces a Podpora 131

132 Fáze Inception hlavní cíl - pochopit, co máme vytvářet Cílem je definice cílů projektu, požadavků, sestavení harmonogramu projektu (plán iterací), odhad nákladů projektu a definice rizik. Počáteční fáze končí rozhodnutím, zda je projekt za daných požadavků, dostupných technologií, zdrojů a rozpočtu možné realizovat Inception Elaboration Construction Transition zdroj IBM Academic Initiative

133 Fáze Inception cíle 1. pochopit, co máme vytvářet vize, pro koho je systém a jakou má hodnotu, rozsah systému, úvodní use-case model Identify and Refine Requirements identifikovat klíčové požadavky důležité případy užití a nefunkční požadavky Initiate Project Identify and Refine Requirements 3. určit minimálně jedno možné řešení - identifikovat kandidáty na architekturu Agree on Technical Approach 4. definovat náklady, harmonogram, rizika Initiate Project Plan and Manage Iteration

134 Fáze Inception workflow 134

135 Fáze Elaboration hlavní cíl - pochopit, jak vytvářet Cílem fáze je definovat architekturu systému. V této fázi by měl být vytvořen prototyp, který ověří všechny architektonické principy a umožní zpřesnění plánu realizace systému. Měly by být definovány komponenty pro opakované použití, které je třeba vyvinout zpodrobnění požadavků podle potřeby (~80%) navrhnout stabilní architekturu definovat, implementovat a otestovat rozhraní hlavních komponent identifikovat závislosti na externích komponentách a systémech implementovat klíčové komponenty cca 10% kódu je implementováno architektura je řízena klíčovými případy užití 20% případů užití řídí 80% architektury navrhnout, implementovat a otestovat klíčové scénáře případů užití Inception Elaboration Construction Transition zdroj IBM Academic Initiative

136 Fáze Construction hlavní cíl - vytvořit produkt dokončení požadavků a designového modelu design, implementace a testování každé komponenty prototyp systému a zpětná vazba od uživatelů rozvoj architektury denní nebo týdenní buildy pomocí automatizovaného procesu testování každého buildu automatizované regresní testy zátěžové testy pro prověření architektury dodání plně funkčního softwaru (beta release) včetně dokumentace Inception Elaboration Construction Transition zdroj IBM Academic Initiative

137 Fáze Transition hlavní cíl dodání uživatelům Cílem fáze je zajistit, aby uživatelé mohli systém používat. Součástí této fáze je školení uživatelů, předání dokumentace, vytvoření help desk atd. dodávky bug-fix uvolnění (release) úprava dokumentace úprava popisu uvolnění (release) Inception Elaboration Construction Transition zdroj IBM Academic Initiative

138 Plán iterace popisuje. vytvářené produkty práci, která má být vykonána délku iterace adresovaná rizika The iteration Plan 138 co kdo dělá metriky zdroj IBM Academic Initiative

139 Burndown chart 139

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

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

Více

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

Co je to COBIT? metodika

Co je to COBIT? metodika COBIT Houška, Kunc Co je to COBIT? COBIT (Control OBjectives for Information and related Technology) soubor těch nejlepších praktik pro řízení informatiky (IT Governance) metodika určena především pro

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

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

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

Více

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

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

Více

Vývoj informačních systémů. Obecně o IS

Vývoj informačních systémů. Obecně o IS Vývoj informačních systémů Obecně o IS Informační systém Informační systém je propojení informačních technologií a lidských aktivit směřující k zajištění podpory procesů v organizaci. V širším slova smyslu

Více

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

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

Více

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

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

Více

Jakou metodiku použít pro

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

Více

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

METODICKÝ RÁMEC IS/ICT

METODICKÝ RÁMEC IS/ICT METODICKÝ RÁMEC IS/ICT Alena Buchalcevová Katedra informačních technologií, VŠE Praha Abstrakt Příspěvek popisuje metodický rámec pro budování informačního systému firmy, tedy metametodiku, která zahrnuje

Více

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz UML a jeho použití v procesu vývoje Jaroslav Žáček jaroslav.zacek@osu.cz Různé pohledy na modelování Různé pohledy na modelování Unified Modeling Language UML není metodikou ani programovacím jazykem,

Více

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

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

Více

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

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

Více

Informační systémy ve strojírenství

Informační systémy ve strojírenství 3 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení Informační systémy ve strojírenství Radim Farana 1 Obsah Životní cyklus vývoje SW. Informační

Více

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

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

Více

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

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

Více

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

Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů Alena Buchalcevová Vysoká škola ekonomická v Praze, Fakulta informatiky a statistiky, katedra informačních technologií

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

Životní cyklus vývoje SW. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Životní cyklus vývoje SW. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Životní cyklus vývoje SW Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Proč potřebujeme definovat proces vývoje Při vývoji SW nemáme tvrdá fakta, jako v jiných vědách (fyzika, chemie,

Více

UML - opakování 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

UML - opakování 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 UML - opakování 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 Co je to UML Evoluce UML Diagram komponent Diagram odbavení Diagram tříd Aktivity diagram Stavový diagram Sekvenční diagram Diagram

Více

Základy analýzy. autor. Jan Novotný http://blog.novoj.net/ 15. února 2007

Základy analýzy. autor. Jan Novotný http://blog.novoj.net/ 15. února 2007 Základy analýzy autor Jan Novotný http://blog.novoj.net/ 15. února 2007 V prezentaci jsou použity diagramy z: Wikipedia, Sparx UML Tutorial, Argo UML Metodiky vývoje Různé metodiky vývoje vazba na fáze

Více

Ročníkový projekt. Jaroslav Žáček jaroslav.zacek@osu.cz

Ročníkový projekt. Jaroslav Žáček jaroslav.zacek@osu.cz Ročníkový projekt Jaroslav Žáček jaroslav.zacek@osu.cz Cíle předmětů Vytvoření fungující aplikace, která splňuje definované požadavky Vyzkoušet si celý životní cyklus projektu - specifikace zadání, formování

Více

Project management. Příprava projektu Zahájení High level plánování. Vykonávání Detailní plánování Vykonávání Řízení a monitorování

Project management. Příprava projektu Zahájení High level plánování. Vykonávání Detailní plánování Vykonávání Řízení a monitorování Project management Project management Příprava projektu Zahájení High level plánování Vykonávání Detailní plánování Vykonávání Řízení a monitorování Uzavření a zhodnocení (iterace, projektu) Projekt Projekt

Více

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

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

Více

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

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

Výhody a rizika outsourcingu formou cloud computingu

Výhody a rizika outsourcingu formou cloud computingu Výhody a rizika outsourcingu formou cloud computingu Jiří Voříšek katedra informačních technologií Vysoká škola ekonomická v Praze vorisek@vse.cz 1 Výchozí model MMDIS pro identifikaci možností outsourcingu

Více

INFORMAČNÍ SYSTÉMY. 03. 01. 2006, Ing. Jiří Mráz

INFORMAČNÍ SYSTÉMY. 03. 01. 2006, Ing. Jiří Mráz INFORMAČNÍ SYSTÉMY 03. 01. 2006, Ing. Jiří Mráz PŘEDNÁŠEJÍCÍ Jiří Mráz Production Coordinator UNICORN jiri.mraz@unicorn.cz AGENDA Informační a komunikační technologie (ICT) podniku Informační systémy Zakázkový

Více

End-to-end testování. 26. dubna Bořek Zelinka

End-to-end testování. 26. dubna Bořek Zelinka End-to-end testování 26. dubna 2013 Bořek Zelinka Bořek Zelinka Unicorn Systems, Test architekt Unicorn, 2004 Testování Quality Assurance ČVUT, Fakulta stavební, 2004 2 Agenda Princip end-to-end testů

Více

Jak na jakost v podnikovém IT Evropský týden kvality Praha 10.11.2004

Jak na jakost v podnikovém IT Evropský týden kvality Praha 10.11.2004 Jak na jakost v podnikovém IT Evropský týden kvality Praha 10.11.2004 Jiří Sedláček AIT s.r.o, Sinkulova 83, 140 00 Praha 4 tel. 261 225 072 www.ait.cz AIT, 2004 1 Program Současné postavení IT v podniku

Více

Cobit 5: Struktura dokumentů

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

Více

Agile Software Development

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

Více

Softwarová podpora v procesním řízení

Softwarová podpora v procesním řízení Softwarová podpora v procesním řízení Zkušenosti z praxe využití software ATTIS Ostrava, 7. října 2010 www.attis.cz ATTN Consulting s.r.o. 1 Obsah Koncepce řízení výkonnosti Koncepce řízení výkonnosti

Více

Využití SysML pro tvorbu modelů v systémovém inženýrství

Využití SysML pro tvorbu modelů v systémovém inženýrství Využití SysML pro tvorbu modelů v systémovém inženýrství Antonín Srna, Ústav informatiky, Provozně ekonomická fakulta, Mendelova univerzita v Brně, xsrna2@mendelu.cz Abstrakt Článek se zaobírá univerzálním

Více

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

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

Více

7 Jazyk UML (Unified Modeling Language)

7 Jazyk UML (Unified Modeling Language) 7 Jazyk UML (Unified Modeling Language) 7.1 Základní charakteristika jazyka Motivace - vznik řady OO metod a metodologií (konec 80. let a první polovina 90.let) podobné notace vyjadřující totéž, komplikující

Více

Cíle a metodika průzkumu

Cíle a metodika průzkumu Cíle a metodika průzkumu Prof. Ing. Jiří Voříšek, CSc. Ing. Ota Novotný, Ph.D. Seminář ČSSI SPIS CACIO 15.5.2007 Konkurenceschopnost absolventů IT oborů VŠ a VOŠ na trhu práce v ČR Společný projekt ČSSI,

Více

Standardy projektového řízení

Standardy projektového řízení Standardy projektového řízení Project Management Body of Knowledge Aktuálně pátá verze Zaštítěn Project Management Institute (PMI) V ČR Česká komora PMI Partner Studentského klub projektového řízení Rozšířen

Více

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

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

Více

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

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

Více

Realizace klientsky orientovaných služeb veřejné správy

Realizace klientsky orientovaných služeb veřejné správy Realizace klientsky orientovaných služeb veřejné správy Agenda Představení společnosti Capgemini Aktuální stav implementace služeb veřejné správy Přínosy rozvoje služeb veřejné správy Trendy dalšího vývoje

Více

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

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

Více

Projektové řízení jako základ řízení organizace

Projektové řízení jako základ řízení organizace Projektové řízení jako základ řízení organizace Aleš Chudý, ředitel divize IW ales.chudy@microsoft.com Technický seminář Bratislava 6.10.2008 Obsah Potřeby byznysu a IT Řešení EPM Microsoft EPM Optimalizační

Více

Standardy/praktiky pro řízení služeb informační bezpečnosti. Doc. Ing. Vlasta Svatá, CSc. Vysoká škola ekonomická Praha

Standardy/praktiky pro řízení služeb informační bezpečnosti. Doc. Ing. Vlasta Svatá, CSc. Vysoká škola ekonomická Praha Standardy/praktiky pro řízení služeb informační bezpečnosti Doc. Ing. Vlasta Svatá, CSc. Vysoká škola ekonomická Praha Služby informační bezpečnosti Nemožnost oddělit informační bezpečnost od IT služeb

Více

SYLABUS MODUL BUSINESS MODELOVÁNÍ. Doc. RNDr. Vladimír Krajčík, Ph.D.

SYLABUS MODUL BUSINESS MODELOVÁNÍ. Doc. RNDr. Vladimír Krajčík, Ph.D. SYLABUS MODUL BUSINESS MODELOVÁNÍ Doc. RNDr. Vladimír Krajčík, Ph.D. Ostrava 20 : Business modelování Autoři: Doc. RNDr. Vladimír Krajčík, Ph.D. Vydání: první, 20 Počet stran: Tisk: Vysoká škola podnikání,

Více

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

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

Více

Agilní metodiky Agilní Jan Smolík

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

Více

Manažerská ekonomika

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

Více

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

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

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

Více

Zkouška ITIL Foundation

Zkouška ITIL Foundation Zkouška ITIL Foundation Sample Paper A, version 5.1 Výběr z více možností Pokyny 1. Měli byste se pokusit odpovědět na všech 40 otázek. 2. Všechny svoje odpovědi vyznačte na samostatný formulář, který

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

Aplikace IS, outsourcing, systémová integrace. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Aplikace IS, outsourcing, systémová integrace. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Aplikace IS, outsourcing, systémová integrace Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Kontext Dodavatelé Strategická Zákazníci ERP Taktická Operativní Kategorie ERP - zaměřeno na

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

Komputerizace problémových domén

Komputerizace problémových domén Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 03 1/19 Komputerizace problémových domén Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta informačních

Více

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER váš partner na cestě od dat k informacím globtech spol. s r.o. karlovo náměstí 17 c, praha 2 tel.: +420 221 986 390 info@globtech.cz

Více

Honeywell & Masarykova univerzita v Brně

Honeywell & Masarykova univerzita v Brně Honeywell & Masarykova univerzita v Brně Představení projektu ifest a dosavadních výsledků jeho řešení Ing. Jan Beran, Ph.D., Advanced Technology Europe (Platform Systems), Honeywell International Představení

Více

ing. Alena Buchalcevová, Ph.D Katedra informačních technologií VŠE Praha buchalc@vse.cz

ing. Alena Buchalcevová, Ph.D Katedra informačních technologií VŠE Praha buchalc@vse.cz Citace: BUCHALCEVOVÁ, Alena. Metodický vzor pro servisně orientovaný vývoj. Praha 23.11.2006 24.11.2006. In: Objekty 2006. Praha : PEF ČZU, 2006, s. 153 161. ISBN 80-213-1568-7. Metodický vzor pro servisně

Více

Řízení ICT služeb na bázi katalogu služeb

Řízení ICT služeb na bázi katalogu služeb Řízení ICT služeb na bázi katalogu služeb Jiří Voř katedra IT, IT, VŠE vorisek@vse.cz nb.vse.cz/~vorisek 1 Služby fenomén současné etapy rozvoje společnosti 2 Vlastnosti služeb služby se od produktů liší

Více

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

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

Více

Enterprise Architecture na MPSV 23.9.2015

Enterprise Architecture na MPSV 23.9.2015 Enterprise Architecture na MPSV 23.9.2015 Mgr. Bc. et Bc. Robert Baxa, náměstek ministryně Mgr. Jiří Károly, ředitel odboru rozvoje a bezpečnosti ICT Enterprise Architecture (EA) na MPSV Východiska pro

Více

Principy UML. Clear View Training 2005 v2.2 1

Principy UML. Clear View Training 2005 v2.2 1 Principy UML Clear View Training 2005 v2.2 1 1.2 Co je touml? Unified Modelling Language (UML) je univerzálníjazyk pro vizuální modelování systémů Podporuje všechny životní cykly Mohou jej implementovat

Více

Management IS. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz 22/ 1

Management IS. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz 22/ 1 Management IS Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz 22/ 1 Učitelé Přednášející: Cvičící: Doc.Ing.Miloš Koch,CSc. Ing.Aleš Klusák Kontakt: koch@fbm.vutbr.cz 22/ 2 Literatura Skripta: Koch,M. Dovrtěl,J.:

Více

Stav řešení Enterprise Architektury na Moravskoslezském kraji

Stav řešení Enterprise Architektury na Moravskoslezském kraji Stav řešení Enterprise Architektury na Moravskoslezském kraji Zpracoval(a): Ing. Tomáš Vašica Datum: 23. 9. 2015 Obsah prezentace 1. Představení projektového záměru 2. Co očekává Moravskoslezský kraj od

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

Metodiky budování informačních systémů kategorizace, agilní metodiky, vzory pro návrh metodiky

Metodiky budování informačních systémů kategorizace, agilní metodiky, vzory pro návrh metodiky Tento text je určen pro studijní účely a je částí knihy Metodiky budování informačních systémů kategorizace, agilní metodiky, vzory pro návrh metodiky autor Alena Buchalcevová citace BUCHALCEVOVÁ, Alena.

Více

Bezpečnostní normy a standardy KS - 6

Bezpečnostní normy a standardy KS - 6 VŠFS; Aplikovaná informatika; SW systémy 2005/2006 1 Bezpečnost informací BI Ing. Jindřich Kodl, CSc. Bezpečnostní normy a standardy KS - 6 VŠFS; Aplikovaná informatika; SW systémy 2005/2006 2 Osnova historický

Více

v praxi Rizika a přínosy zavádění BI jako nástroje pro řízení podnikání

v praxi Rizika a přínosy zavádění BI jako nástroje pro řízení podnikání Podpora rozhodování v praxi Rizika a přínosy zavádění BI jako nástroje pro řízení podnikání HanušRais Business DevelopmentManager SAS Institute ČR s.r.o. Agenda Úvod - Profil SAS Institute Pojem Business

Více

Outsourcing v podmínkách Statutárního města Ostravy

Outsourcing v podmínkách Statutárního města Ostravy Outsourcing v podmínkách Statutárního města Ostravy Říjen 2009 Ing. Stanislav Richtar Ředitel společnosti 1 OBSAH PREZENTACE 1. Outsourcing - obecně 2. Výchozí stav projektu 3. Model poskytovaných služeb

Více

Efektívne projektové riadenie v zohratom tíme

Efektívne projektové riadenie v zohratom tíme Efektívne projektové riadenie v zohratom tíme Zdeněk Borůvka Rational Brand Technical Leader, IBM CEE Úvod Dodať biznisu viac s menšími prostriedkami a v čo najkratšom čase. Túto základnú požiadavku kladie

Více

Agilní metodiky vývoje softwaru

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

Více

Obsah Úvod 11 Jak být úspěšný Základy IT

Obsah Úvod 11 Jak být úspěšný Základy IT Obsah Úvod 11 Jak být úspěšný 13 Krok 0: Než začneme 13 Krok 1: Vybrat si dobře placenou oblast 14 Krok 2: Vytvořit si plán osobního rozvoje 15 Krok 3: Naplnit osobní rozvoj 16 Krok 4: Osvojit si důležité

Více

Seminář VŠE, ČSSI a ICT UNIE 26.10.2011

Seminář VŠE, ČSSI a ICT UNIE 26.10.2011 Výsledky průzkumu nabídky a poptávky po IT profesích v ČR Seminář VŠE, ČSSI a ICT UNIE 26.10.2011 Výzkum Lidské zdroje v ICT vznikl za finanční podpory MŠMT ČR v rámci projektu Sociální síť v regionech

Více

Procesní řízení IT. Ing. Hana Neničková, MBA

Procesní řízení IT. Ing. Hana Neničková, MBA Procesní řízení IT Ing. Hana Neničková, MBA Hewlett-Packard 11.místo v žebříčku časopisu Fortune Za fiskální rok 2007 jsme dosáhli organického růstu ve výší 7 miliard dolarů CEO HP je Mark Hurd, sídlo

Více

Management kvality cesta k udržitelnému rozvoji cestovního ruchu. Ing. Jiří Sysel Citellus, s.r.o.

Management kvality cesta k udržitelnému rozvoji cestovního ruchu. Ing. Jiří Sysel Citellus, s.r.o. Management kvality cesta k udržitelnému rozvoji cestovního ruchu Ing. Jiří Sysel Citellus, s.r.o. Pojetí kvality Kvalita patří mezi základní filosofické kategorie, ale v současném ekonomickém a manažerském

Více

ČESKÁ TECHNICKÁ NORMA

ČESKÁ TECHNICKÁ NORMA ČESKÁ TECHNICKÁ NORMA ICS 01.040.35; 35.040 Říjen 2014 Informační technologie Bezpečnostní techniky Systémy řízení bezpečnosti informací Přehled a slovník ČSN ISO/IEC 27000 36 9790 Information technology

Více

Aplikace IS, outsourcing, systémová integrace. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Aplikace IS, outsourcing, systémová integrace. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Aplikace IS, outsourcing, systémová integrace Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Kontext Dodavatelé Strategická Zákazníci ERP Taktická Operativní Kategorie ERP - zaměřeno na

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

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

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

Více

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

KIV/SI. Přednáška č.2. Jan Valdman, Ph.D. jvaldman@dns.cz

KIV/SI. Přednáška č.2. Jan Valdman, Ph.D. jvaldman@dns.cz KIV/SI Přednáška č.2 Jan Valdman, Ph.D. jvaldman@dns.cz 8.3.2011 ITIL Information Technology Infrastructure Library ITIL v současnosti zahrnuje: Samotnou knihovnu Oblast vzdělávání a certifikace odborné

Více

Česká letecká servisní a. s.

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

Více

Workflow, definice, charakteristika, trendy

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

Více

PŘÍLOHA C Požadavky na Dokumentaci

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

Více

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

Strategie, architektury a projekty jako nástroj řízení IT ve veřejné správě

Strategie, architektury a projekty jako nástroj řízení IT ve veřejné správě Strategie, architektury a projekty jako nástroj řízení IT ve veřejné správě Tomáš Hrabík ICZ a.s. Konference Řízení informatiky v soukromém a veřejném sektoru 1 Otázky 1. Je egovernment o elektronizaci

Více

Unifikovaný modelovací jazyk UML

Unifikovaný modelovací jazyk UML Unifikovaný modelovací jazyk UML Karel Richta katedra počíta tačů FEL ČVUT Praha richta@fel fel.cvut.czcz Motto: Komunikačním m prostředkem informační komunity se postupem času stala angličtina. Chcete-li

Více

Softwarové inženýrství 01. doc. Ing. František Huňka, CSc.

Softwarové inženýrství 01. doc. Ing. František Huňka, CSc. Softwarové inženýrství 01 doc. Ing. František Huňka, CSc. Obsah kurzu Softwarové inženýrství obecně vodopádová model spirálový model RUP agilní metodiky vývoj řízený vlastnostmi (Feature Development Design)

Více

MANAGEMENT Přístupy k řízení organizace

MANAGEMENT Přístupy k řízení organizace MANAGEMENT Přístupy k řízení organizace doc. Ing. Monika MOTYČKOVÁ (Grasseová), Ph.D. Univerzita obrany Fakulta ekonomika a managementu Katedra vojenského managementu a taktiky Kounicova 44/1. patro/kancelář

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

RDF DSPS ROZVOJ PORTÁLU

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

Více

6INF2. RNDr. Jaroslav Žáček, Ph.D. jaroslav.zacek@osu.cz

6INF2. RNDr. Jaroslav Žáček, Ph.D. jaroslav.zacek@osu.cz 6INF2 RNDr. Jaroslav Žáček, Ph.D. jaroslav.zacek@osu.cz Vliv IT na změny ve společnosti Vznik nových produktů (platební karty, digitální kamery, ) Vznik ucelených řešení na bázi IS bez přítomnosti lidí

Více

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

Vnitřní kontrolní systém a jeho audit Vnitřní kontrolní systém a jeho audit 7. SETKÁNÍ AUDITORŮ PRŮMYSLU 11. 5. 2012 Vlastimil Červený, CIA, CISA Agenda Požadavky na VŘKS dle metodik a standardů Definice VŘKS dle rámce COSO Role interního

Více

Přístupy k efektivnímu využití modelu MBI

Přístupy k efektivnímu využití modelu MBI MBI, Management byznys informatiky Přístupy k efektivnímu využití modelu MBI Jan Dohnal Katedra softwarového inženýrství, F, ČVUT Jan Pour Katedra, FIS, VŠE MBI, Management byznys Snímek informatiky 1

Více

HR controlling. Ing. Jan Duba HRDA 26.9.2014

HR controlling. Ing. Jan Duba HRDA 26.9.2014 HR controlling Ing. Jan Duba HRDA 26.9.2014 Anotace Zkušenosti s nastavováním systému měření výkonu pracovních skupin a jednotlivců Jak zavést živý controlling pro řízení firmy? Anotace Interim HR manažer

Více

egovernment ready úřad

egovernment ready úřad egovernment ready úřad Ing. Václav Koudele Strategy architect Tel.: +420 602 191 122 Vaclav.koudele@microsoft.com Ing. Zdeněk Dutý Ředitel pro egovernment Tel.: +420 910 972 131 zdenek.duty@autocont.cz

Více

InternetovéTechnologie

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

Více

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