4IT216 Zkouškové otázky PDF

4it216 -- zkouškové otázky 10.01.2024 -- pydt00 1 -- Definujte pojmy: byznys, systém, informační systém, informační technologie, aplikační software (aplikace), informatická služba, informatický zdroj, projekt. Jaké jsou vztahy mezi těmito pojmy? - **Byznys** -- organizace, poskytuje produkty, s...

4it216 -- zkouškové otázky 10.01.2024 -- pydt00 1 -- Definujte pojmy: byznys, systém, informační systém, informační technologie, aplikační software (aplikace), informatická služba, informatický zdroj, projekt. Jaké jsou vztahy mezi těmito pojmy? - **Byznys** -- organizace, poskytuje produkty, služby, byznys = podniky + nezisk + verejná správa - **Systém** -- celek s nějakým účelem, souhrn částí a vztahů mezi nimi - **Informační systém** -- systém sloužící k poskytování informací lidem - **Informační technologie** -- hw + sw pro operace s informacemi - **Aplikační SW** -- sw pro použití uživatelem, pro plnění informačních potřeb - **Informatická služba** -- služba poskytující informace uživateli, konzumuje zdroje informací - **Informatický zdroj --** zdroj informací (?) - **Projekt** -- řada činností s účelem dosažení cíle, s vymezeným časem a zdroji 2 - Jaké je místo IS/ICT a jeho řízení při řízení organizace? Jaký je vztah mezi byznys cíli, byznys procesy, informatickými službami, informatickými procesy a informatickými zdroji? Popište model SPSPR. **Jaké je místo IS/ICT a jeho řízení při řízení organizace?** klíčové místo při řízení organizace. [Podporuje obchodní procesy a zjednodušuje a zefektivňuje tím jejich provádění]. Díky nim mohou organizace poskytovat nové služby, které byly předtím nemyslitelné, díky čemuž mohou dosahovat vyšších obratů. **Jaký je vztah mezi byznys cíli, byznys procesy, informatickými službami, informatickými procesy a informatickými zdroji?** [Jsou navzájem provázané], bez nich by nemohl být podnik efektivně řízen. [Podnikové procesy naplnění byznys cílů.] [Informatická služba je zaměřená na podporu jednoho nebo více byznys procesů]. Informatický zdroj je součást nutná k tvorbě a provozu informatické služby. - S - Strategy, P - Business Processes, S -- ICT Services, P - ICT Processes, R -- ICT Resources - **Model SPSPR** - Popisuje ve vrstvách, jak se jednotlivé [ICT zdroje, procesy a služby] **podílí na hlavních procesech firmy** - Rozdělení do vrstev má za účel jasně určit zodpovědnost různých manažerů, specialistů v podniku, zpřehlednit dekompozici cílů 3 - Charakterizujte tyto alternativy, resp. Situace -- vývoj aplikace vers. provoz aplikace, IASW vers. TASW, řešení vlastními zdroji vers. řešení externími zdroji - **Vývoj v. provoz** - **Vývoj** -- vytváření změn v informačním systému podniku, může být realizováno projektem - **Provoz** -- proces zajištění běhu aplikací, dodávaní konečných služeb zákazníkům. Parametry provozu jsou obvykle sjednány předem. - **IASW v. TASW** - **IASW -- Individuální aplikační SW** -- aplikace vytvořená pro byznys na míru, specializovaná - **TASW -- Typový aplikační SW -- aplikace poskytována širšímu segmentu byznysů, generalizace požadavků, specializuje se na odvětví, např. bankovnictví, výroba automobilů. Náklady jsou nižší (obv). Hodí se pro vysoce standardizované činnosti, např. účetnictví.** - **Řešení vlastními v. externími zdroji** []{#ot_4.anchor}4 -- V čem spočívají zásadní odlišnosti vývoje nové aplikace jako TASW, vs. IASW? +-----------------------+-----------------------+-----------------------+ | | Výhody | Nevýhody | +=======================+=======================+=======================+ | IASW | - Nekupujeme nic | - Vyšší náklady | | | navíc, aplikace | | | | na míru | - Delší doba vývoje | | | | -- řešení | | | - Lepší kontrola | | | | nad aplikací -- | - Obvykle nižší | | | opravy chyb, | kvalita řešení | | | znalost | | | | fungování, | | | | expanze | | | | funkcionalit | | +-----------------------+-----------------------+-----------------------+ | TASW | - Rychlejší | - Podnikové procesy | | | nasazení | se musí | | | | přizpůsobit | | | - Nižší náklady | | | | | - Obtížnější | | | - Postaveno na best | integrace s | | | practises | ostatním SW | | | | | | | - Aplikuje nejlepší | | | | zkušenosti | | | | širšího okruhu | | | | uživatelů | | +-----------------------+-----------------------+-----------------------+ 5 - V čem spočívají zásadní odlišnosti vývoje nové aplikace vlastními vs. Cizími zdroji +-----------------------+-----------------------+-----------------------+ | Vývoj aplikace... | Výhody | Nevýhody | +=======================+=======================+=======================+ | Vlastními | - Růst dle potřeb | - Vyšší náklady, | | | | doba řešení | | | - Konkurence nemá | | | | možnost nahlížet | | | | | | | | - Detailní znalost | | | | SW v podniku | | +-----------------------+-----------------------+-----------------------+ | Externími | - Nižší náklady, | - Závislost na | | | rychlejší | dodavateli a jeho | | | realizace | schopnostech, | | | | stabilitě | | | - Využití znalostí | | | | externích | | | | specialistů | | +-----------------------+-----------------------+-----------------------+ 6 - V čem spočívají zásadní odlišnosti provozu aplikace vlastními vs. Cizími zdroji +-----------------------+-----------------------+-----------------------+ | Vývoj aplikace... | Výhody | Nevýhody | +=======================+=======================+=======================+ | Vlastními | - Údržba rychlejší, | - Problémy při | | | přímější | potřebě provozu | | | | vice TASW na | | | - Nezávislost na | jedné platformě, | | | dodavateli | složitá integrace | +-----------------------+-----------------------+-----------------------+ | Externími | - Snížení nákladů | - Závislost na | | | na provozní | dodavateli, | | | personal | obzvláště ve věci | | | | bezpečnostních | | | - Můžeme se lépe | rizik | | | soustředit na | | | | předmět činnosti | | | | | | | | - Snadnější změny | | | | kapacit | | | | | | | | - Obvykle | | | | kvalitnější a | | | | spolehlivější | | | | služby | | +-----------------------+-----------------------+-----------------------+ - U externího provozu mohou být náklady vyšší i nižší, podle úrovně kvality služby. Při stejné kvalitě jako u vlastního bývají nižší u externího provozu. 7 - Principy modelování při analýze a návrhu IS/ICT. Co je to model? K čemu slouží? Jak vypadá? Na základě čeho se vytváří? Jaké modely znáte? Jaké jsou kritické faktory úspěchu modelování? **[Obecně o modelech]** - Model je zjednodušenou reprezentací objektu, jevu, systému apod. Snaží se přehledně popsat důležité aspekty popisované věci, a tím se ji snažit lépe pochopit, popř. sdělit. - Model se skládá z prvků a jejich vazeb -- jako systém - Některé prvky komunikují s okolím, např. okolními systémy -- to jsou tedy hranice systému -- kam až zasahuje - Prvky systému odpovídají prvkům reálného světa, stejně tak jako struktura modelu - Modely se využívají např. k porovnání současného a cílového stavu, k analýze reality na základě modelu - Tvoří se např. jako diagramy, ty bývají popsány standardními notacemi **[Příklady modelů]** - Organizační struktura - Konceptuální, logický, fyzický model database - Modely business procesů **[Faktory úspěchu]** - Vlivy na úspěšnost modelování - Znalost problematiky řešiteli - Dodržování notací []{#ot_8.anchor}8 - Podnikový proces. Co je to proces? Popište principy procesního řízení a možnosti dokumentace procesů. Popište model KBPR. Možnosti optimalizace procesů. **[O procesech]** - **Proces v podniku** -- [řada činností prováděných ke splnění stanoveného cíle] - **Procesní řízení** -- sleduje procesy, používá IT - **Principy procesního řízení** -- vytváří procesy podle strategických potřeb podniku, identifikuje a popíše všechny aspekty procesu, např. Jaké zdroje jsou k realizaci třeba, zda budeme proces outsourcovat, jak bude process podporován IS/ICT, jak proces zorganizujeme.. - **Dokumentace procesů** -- procesy popisujeme diagramy, např. [Diagram návaznosti procesů, procesní mapa]. Procesy jsou zpravidla složeny z činností, obsahují informace o informačních potřebách činností a o tom, kdo činnosti provádí. **[Metoda KBPR]** - **Knowledge-Based process Re-engineering** - Rozlišují se 4 úrovně modelování procesů, liší se především v detailnosti popisu - **1. Úroveň** - **cíle procesu** - aktivující událost (**co se má stát, aby process začal**) - vlastník procesu -- **kdo ho provádí**, zaměstnanec/oddělení - zákazník -- **kdo benefituje** - finanční/časová omezení - jiné metriky... - **2. Úroveň** - **Definice výstupu proces**u - **3. Úroveň** - Seznam činností, rolí, externích vstupů, nástrojů pro činnosti... - **4. Úroveň** - Vstupy, výstupy jednotlivých činností - Návody k činnostem, doby trvání,... - Přirazení rolí k činnostem 9 - Procesní modelování -- cíle, principy, standardy, modely, komponenty - **Cíle** -- Zachycení reality, Popsání podnikových procesů graficky, Simulace chování procesů - **Principy** -- dodržení notace, výstižná pojmenování **[Standardy]** - **ARIS (EPC)** -- základními entitami jsou události a činnosti, jsou logicky spojeny. Dále diagram zachycuje informační vstupy a výstupy a role, které provádí uvedené činnosti. V diagramech lze větvit pomocí logických operátorů. - **BPMN** (Business process modelling notation) -- otevřený standard, široce podporovaný modelery. Procesy typicky modelovány zleva doprava, začíná startovací událostí, končí koncovým stavem. Rozlišuje typy událostí. Pro přehledné rozlišení vlastníků činností se používají swimlanes -- plavecké dráhy. Činnosti jsou pak rozděleny vertikálně do pruhů (drah), každý z nichž reprezentuje nějakého vlastníka procesu - **Erikssonovo a Penkerovo rozšíření UML** -- rozšiřuje UML, aby bylo použitelnější k modelování procesů **Pojmy(Komponenty)** - **Proces** -- [[Viz ot. 8]](#ot_8) - **Činnost** -- základní prvek procesu, jednodušší jednotka, spočívá v [přeměně nějakého vstupu na výstup] - **Událost** -- **externí podnět**, např. Příchod objednávky - **Stav** -- výsledek činnosti 10 - Objektové modelování -- cíle, principy, standardy, modely, komponenty - **Cíl** -- zachytit, popsat realitu - Používají se UML diagramy - **Principy** - objekty se popisují jako systémy -- prvky, které interagují, mají vazby - **Standardy** -- existuje množství standardů pro UML diagramy, základní rozdělení **[CHOV INTER STRUKTUR]** - **Strukturní diagramy** -- popisují strukturu objektů - **Diagramy chování** -- use case diagram, aktivit,... - **Diagram interakce** -- zachycuje vztahy mezi objekty - **Modely** -- např. - **Class** **diagram** -- zachycuje třídy v systému - **Use** **case** **diagram** -- popisuje případy užití - **Stavový** **diagram** -- popisuje změny stavů objektů při různých interakcích - **Komponenty OTAA** - **Objekt** -- prvek - **Třída** -- popis skupiny objektů se stejnými vlastnostmi a chováním - **Atribut** -- vlastnost objektu - **Asociace** -- vztah mezi objekty, např. reference v databázi []{#ot_11.anchor}11 - Datové modelování -- cíle, principy, standardy, modely, komponenty - **Cíl** -- popsat to, o čem chceme uchovávat informace. Především jde o modelování databází, modelování datových toků - **Principy** - Datové toky se znázorňují diagramem d. t. -- **data flow diagram (DFD)** - Tvoří se v modelovacích nástrojích - **Modely - KLF** - **Konceptuální** -- nejjednodušší, nebere v potaz implementační prostředí - **Logický model** -- jsou zde např. [přidány klíče] pro referenční integritu databáze, už se bere v úvahu prostředí - **Fyzický model** -- obsahuje navíc např. [informace o datových typech], už zde referujeme na konkrétní databázový systém - **Komponenty** - **DFD** - **Funkce** -- transformace dat - **Datový tok** -- data flow - **Datové úložiště** -- data store - **Terminátor** -- vnější entita - **K databázím** -- entity, vazby,... **BONUS: ACID vs. BASE** 12 - Funkce IS, hierarchie funkcí, funkcionalita IS. Funkční modelování -- cíle, principy, standardy, modely, komponenty. - **Funkce IS** -- prvek chování -- aplikace, např. vystavení objednávky - **Funkcionalita IS** -- [souhrn funkcí] - **Hierarchie funkcí** -- popis funkčních celků a jejich pod-funkcí -- rozděleno hierarchicky **[Funkční modelování]** - **Cíl** -- popisuje z jakých funkcí, jejich vstupů a výstupů se realita skládá /// funkce a to, jak budou tvořit informační systém s účelem plnit potřeby podniku - **Funkční diagram** -- podrobný popis funkcí systému, a který cíl plní - **Data flow diagram** (DFD) -- znázorňuje výměny informací mezi prvky systému - **Komponenty** -- [[viz ot. 11]](#ot_11) konec 13 - Modelování případů užití -- cíle, principy, standardy, modely, komponenty - **Cíl** -- popsat chování systému z pohledu uživatele - **Standardy** -- use case diagram - **Principy** -- specifikuje se, jaký typ uživatele může vykonávat možné činnosti - **Model** -- uvedení případů užití a jejich popisu, spojení s uživatelem určitého druhu, model může obsahovat dědění -- existují typy uživatelů, které mohou to, co uživatel x, plus něco více - **Komponenty** -- Uživatel se specifikovaným typem, případy užití, vazby mezi předchozími 14 - Metodika MMDIS -- charakteristika, účel, principy a koncepty, jejich popis a vztahy **[MMDIS - Charakteristika]** - Multidimensional Management and Development of Information Systems - Metodika vyvjíjená na katedře informačních technologií VŠE od 90. let. [Snaží se vychovat specialisty, kteří zvýší úspěšnost ICT projektů] - Cílem je vývoj, provoz a údržba komplexních integrovaných podnikových informačních systémů, který optimálně využívá dostupného IT, a služeb v odvětví k maximální podpoře podnikových cílů **[Struktura MMDIS]** - Metodika se skládá z 11 základních principů řízení a pěti propojených konceptuálních modelů řízení podnikové informatiky **[Principy -- 11 základních principů MMDIS \-\-\-\-\-- MIV FOK U ]** - **Multidimenzionalita** - **Vrstevnost** - **Integrace** - **Flexibilita** - **Otevřenost** - **Standardizace** - **Kooperace** - **Procesní pojetí** - **Učení a růst** -- zlepšování procesů - **Lokalizace zdrojů a rozhodnutí** - **Měřitelnost** **[Konceptuální modely]** (Modely řízení systémů) - **Model procesně řízené organizace** - **Integrace strategie, procesů, služeb a zdrojů (model SPSR) SPSR HORE** - **Integrace oblasti řízení** - **Model tvorby a dalšího rozvoje** - **Systém řízení IS** 15 - Princip multidimenzionality. Jaké dimenze MMDIS doporučuje pro řešení IS/ICT? Jejich váha a vztahy. - **Princip -- složité problémy analyzujeme hodnotíme, a řešíme z mnoha různých pohledů -- dimenzí, ty jsou určeny stranami zainteresovanými na systému. Řešení z více pohledů následně integrujeme do celkového** - **Pravidla multidimenzionality** - **1.** Identifikuj všechny pohledy ovlivňující řešení, s nimi související potřeby - **2.** Analyzuj nejdříve z každého pohledu samostatně - **3.** Integruj řešení z pohledů do celkového řešení s uvážením všech potřeb - **Cíl** -- neopomenout žádný faktor, který ovlivňuje úspěšnost tvorby IS - **Pohledy** -- dělíme do 3 skupin - Uživatelský a řešitelský - Úroveň abstrakce a časová dimenze - Obsahová dimenze - **Příklad** -- pokud bychom chtěli postavit dům, můžeme se dívat z následujících pohledů - Životní styl -- *k čemu a jak chci dům užívat?* - Architektonický -- *jak bude dům vypadat, z čeho bude postaven?* - Dodavatelský -- *kdo ho postaví, za jak dlouho, za kolik peněz?* - Finanční -- *jak dům zaplatíme?* 16 - Konceptuální modelování; Princip tří architektur (P3A); Použití abstrakce při řešení IS/ICT. **[Konceptuální modelování]** - Nástroj pro efektivní řízení podnikové informatiky, opět se díváme z více pohledů. Modely popisují systém a jeho řízení, slouží k analýze a optimalizaci IS. **[Architektura P3A]** - Architektura, kdy se užívá rozlišení na konceptuální, logický a fyzický model -- [[viz ot. 11]](#ot_11) - **Použití abstrakce** -- rozdíly mezi architekturami v P3A je právě úroveň abstrakce jednotlivých modelů 17 - Jaké různé role se podílejí na řešení IS/ICT (vrcholové vedení, řešitelé, uživatelé,...)? Jak se liší jejich zájmy a jejich pohledy na IS/ICT v průběhu jeho tvorby? - **Druhy pohledů na IS** - **Uživatelské** -- požadavky - **Řešitelské** -- konstrukce IS, realizovatelnost požadavků - Při konstrukci IS **vycházíme z uživatelských** pohledů **do řešitelských** **[Uživatelské pohledy]** - Ti, kteří definují funkcionalitu IS podle reálných potřeb - Vlastníci, management, zaměstnanci -- uživatelé, zákazníci, veřejnost - **Pohled vrcholového managementu** -- **strategický** -- má největší váhu -- **zameranie, timeline a budget** - Požadavky podpořit nejvyšší cíle podniku, získat konkurenční výhodu, optimalizovat procesy, vhodně prezentovat informace pro účely BI,... - Požadavky jsou konkretizovány -- v účelu, času nasazení, omezení zdrojů - **Pohled koncových uživatelů** - Požadavky především na podporu řešení problémů oddělení firmy, z toho odvozujeme funkce, které budou tuto podporu provádět - Např. sběr dat -- kdy, jak, a co; jakou funkcionalitu pro podporu poskytovat,... - Požadavky na komunikaci s IS - Na základě náplně práce oddělení **[Pohled řešitelů]** - Pochopení situace v podniku, analýza potřeb uživatelů - Poté opět návrh IS, opět konceptuální, logický, fyzický... **[MMDIS]** - Řešitelské pohledy MMDIS nazývá dimenze, dělí je do dvou skupin - 1\. skup -- časová dimenze,... - 2\. skup -- obsahová dimenze, organizační dimenze,... 18 - Charakterizujte fáze vývoje informačního systému dle MMDIS a fáze projektu IS/ICT (cíle, vstupy a výstupy každé fáze). - Každá fáze je charakterizována **cíli, vstupy, výstupy a postupem** - Úvodními fázemi jsou globální a informační strategie společnosti -- k naplnění jejich cílů spěje vývoj IS - **GST** -- globální strategie -- celopodnikové cíle, horizont cca 3 let - **IST** -- informační strategie -- dílčí strategie pod GST, zabývají se koncepcí IS v prospěch GST **[Fáze -- dlouhá verze]** - **Úvodní studie (UST)** - **Cíl** -- posoudit realizovatelnost požadavků, možnost rozdělení na podprojekty - **Výstup** - Popis aktuálního stavu, cílového stavu - Návrh - Hrubé vymezení funkcionality, dat - Proof of concept -- ověření realizovatelnosti na menším příkladu - Odhad zdrojů na vývoj, provoz - **Globální analýza a návrh (GAN)** - **Cíl** -- konceptuální návrh aplikace - **Výstupy** - Návrh funkcionality - Návrh struktury - Návrh změn v procesech - Požadavky na bezpečnost a kvalitu aplikace - Návrh ovládání a použití aplikace - **Detailní analýza a návrh (DAN)** - **Cíl** -- Detailnější konceptuální model, detailnější návrh aplikace - **Výstupy** - Návrh programových modulů - Návrh fyzické struktury, UI - **Implementace (IMP)** - **Cíl** -- přechod z technologické do implementační úrovně -- realizace fyzického návrhu DB v konkrétním DB systému - **Výstupy** - Napsané a otestované programy - Funkční DB - Dokumentace - **Zavádění (ZAV)** - **Cíl** -- uvést IS do provozu, dosahování plánovaných přínosů, doladění programů - **Výstupy** - Upravená aplikace -... - **Provoz a údržba (PU)** - **Cíl** -- řízení provozu aplikace, dosahování předpokládaných přínosů - **Výstupy** - přínosy v oblasti nasazení aplikace - požadavky na změny aplikace - upravená aplikace - **Vyřazení (VYR)** - **Cíl** -- vyřazení aplikace a jejích komponent z provozu - **Výstupy** - Zlikvidované komponenty - Změněné navazující procesy a zodpovědnosti **[Fáze -- TL;DR]** 1. **Úvodní studie** -- posouzení realizovatelnosti, základní návrhy, odhad zdrojů 2. **Globální analýza návrhu** -- konceptuální modely 3. **Detailní analýza návrhu** -- detailnější modely 4. **Implementace** -- programování, fyzický model, dokumentace 5. **Zavádění** -- uvedení do provozu, doladění 6. **Provoz a údržba (PU)** 7. **Vyřazení** -- vyřazení z provozu (např. v prospěch jiného systému) []{#ot_19.anchor}19 - Popište základní charakteristiky informace -- jak se tyto charakteristiky týkají návrhu a provozu IS/ICT? **[Informace]** (v kontextu odvětví) - **Složky** - **Sdělení** -- obsah informace - **Data** -- vyjádření informace v jazyce/určitým způsobem - **Nosič** -- fyzický prostředek přenosu - **Typ informace SSG** - **Signální** -- při výměně informací mezi prvky systému - **Strukturální** -- popisuje strukturu subjektu, např. organizační struktura podniku - **Genetická** -- uložena v systému, předurčuje jeho chování. Může to být třeba paměť zaměstnanců, projevuje se při jejich jednání - **Charakteristiky** - Konkrétní x Abstraktní - Předmět, který se k ní vztahuje - Časové vymezení -- kdy platí -... 20 - Charakterizujte pojmy: třída, objekt, událost, stav, činnost, funkce, proces. V jakých kontextech se používají při tvorbě IS/ICT? Jaké jsou mezi nimi vzájemné souvislosti? **[Pojmy]** - **Třída** -- skupina objektů se stejnými vlastnostmi a chováním, šablona pro instance jí samé - **Objekt** -- datová entita, technicky množství paměti v zařízení na určité adrese, které má definovanou strukturu, a zpravidla se k němu dá přistoupit pomocí zmíněné adresy - **Událost** -- něco co nastane mimo systém, rozlišujeme informační, časovou a mimořádnou - **Činnost** -- konání práce, funkce - **Proces** -- činnost či soubor činností s daným cílem, zpravidla přeměna vstupů na výstupy. Dělí se na hlavní, vedlejší, podpůrné **[Vztahy]** - **Události** mohou mít za následek začátek **Procesu** - **Procesy** se skládají z **Činností** - **Činnosti** často pracují s datovými **Objekty** - **Objekt** je zpravidla instancí **Třídy** Obrázok, na ktorom je rukopis, kresba, náčrt, obrysy Automaticky generovaný popis []{#ot_21.anchor}21 - Událost. Charakterizujte typy událostí, vztah události a procesu a úrovně podrobnosti popisu procesu. **[Typy událostí IČM]** - **Informační** -- spojená s příchodem, odhalením informace, např. příchod objednávky - **Časová** -- dne x se stane y - **Mimořádná** -- spojena s narušením běhu procesu, např. výpadek proudu **[Událost]** - **Vazba událost -- proces** -- na událost může reagovat proces - **Procesní pohled** -- to, jak podnikové procesy reagují na různé události - Informace o procesech, jak na sebe navazují, jak probíhají, a zda jsou konzistentní se zbytkem IS 22 - Charakterizujte souvislosti mezi modely IS/ICT. Je možné, že různé modely IS/ICT budou vzájemně v rozporu? Popište příklady a možnosti, jak takový rozpor řešit. - Modely musí být mezi sebou konzistentní, v cílech, procesech, stavech,... , prostě ve všem - **V rozporu?** -- např. z důvodu různých autorů dvou modelů. Z tohoto důvodu zavádění konvencí, standardizace, analýza všech aspektů - **řešení** 23 - Popište vztah mezi daty, funkcemi a událostmi v informačním systému. - Funkce může být událostí iniciovaná, funkce pak pracuje s daty k provedení transformace na výstup - **Životní historie entity** -- zachycuje všechny možné stavy datového objektu, přechody mezi stavy, přechody mohou být iniciovány událostmi 24 - Co je předmětem řešení funkční a procesní dimenze MMDIS (obecně a v jednotlivých fázích vývoje IS)? - **Definice** všech **procesů** -- aktivující událost, cíl, výstup, vlastník,... - Procesy mohou výt **vykonávány člověkem** bez, nebo s asistencí IS, nebo **plně automatizovány**, ať už jde o **zpracování informací**, nebo **výrobu fyzického produktu** - **Procesy se liší** např. - **Významem** pro podnik -- hlavní, řídící, podpůrné - **Prioritou** -- důležitostí pro podnikové cíle - **Měrou automatizace** -- manuální, automatizovaný (pozn. redakce -- byla tu kopie textu z legislativní dimenze, idk proč. Opraveno podle knihy.) 25 - Co je předmětem řešení datové / informační dimenze MMDIS (obecně a v jednotlivých fázích vývoje IS)? Dimenze se zabývá - typy informací, kterých je třeba při jednotlivých podnikových aktivitách, - Obsahem a strukturou datové základny podniku a jejím fyzickým uložením, - řešením této dimenze je navrhována a realizována datová architektura IS/ICT. **[Pojmy]** - **Data** -- [[viz ot. 19]](#ot_19) - **Informace** -- [[viz ot. 19]](#ot_19) - **Znalost** - Pravidla, podle kterých jsme schopni z informací odvodit nové. Znalosti v podniku jsou často klíčem k dlouhodobé konkurenceschopnosti - Cíle **managementu znalostí** -- opakování ověřených řešení, získání převahy nad konkurencí, využít data nahromaděná v informačních systémech **[Datová/informační dimenze]** - Řeší strukturu datové základny podniku, vychází z ní návrh a realizace datové architektury IS/ICT - **Výstupy** -- Návrhy... - Databází, entit v nich a vazeb mezi nimi - Zabezpečení - Vstupů a výstupů dat v rámci IS - Návrh zabezpečení, migrace dat... 26 - Co je předmětem řešení organizační / legislativní dimenze MMDIS (obecně a v jednotlivých fázích vývoje IS)? - Soulad s **legislativou** - Rešerše zákonů, které jsou k danému IS relevantní - Autorský zákon, daňové z.,... - Soulad se **standardy a normami** - Soulad s **podnikovými směrnicemi a normami** - **Určení charakteru vývoje -- interní/externí,...** - definování pravidel pro vývoj, údržbu a provoz IS - Sepsání pravidel pro průběh relevantních procesů, pro vývoj, údržbu a provoz IS - Určení, rozdělení pracovní náplně zaměstnanců pracujících s IS 27 - Co je předmětem řešení metodicko-organizačních dimenzí MMDIS (obecně a v jednotlivých fázích vývoje IS)? - Cílem je organizovat vývoj v souladu s požadavky na kvalitu, čas nasazení a náklady **[Metody]** - Zabývá se **určením metod**, technik a nástrojů **používaných ve vývoji a provozu IS** **[Dokumenty]** - Definuje, **jaká dokumentace bude vytvořena při vývoji a provozu IS**, její obsah a návaznost - **Dělení dokumentace PPUP** - **Projekční** -- poznatky z úvodní analýzy a návrhů systému - **Programová** -- dokumentace fungování aplikací - **Uživatelská** -- návod pro použití uživatelem - **Provozní** -- návod pro správce **[Manažerská dimenze]** - Určuje postupy při řešení vývoje, pravidla, organizaci tvorby a provozu, odpovědnosti, participace specialistů a vedení podniku 28 - Co je předmětem řešení aplikační dimenze (aplikační sw) MMDIS (obecně a v jednotlivých fázích vývoje IS)? - Určení **aplikační architektury IS** -- určení typů a vzájemných vazeb jednotlivých komponent - Učiněn výběr mezi **externím/interním vývojem** - Určení **nástrojů** použitých **na vývoj** - Zpravidla použití existující, definované architektury []{#ot_29.anchor}29 - Co je předmětem řešení dimenze bezpečnost a kvalita v MMDIS (obecně a v jednotlivých fázích vývoje IS)? - Zajištění kvality a bezpečnosti IS podle požadavků - **Důležité elementy bezpečnosti** - Správné fungování přístupových práv, údajů - Logování transakcí pro kontrolu - Zálohování dat - **Service Level Agreement** -- **SLA** -- smlouva se zákazníkem který využívá naši službu, specifikuje parametry poskytované služby, např. povolený downtime,... - Porušení kvality může pocházet z jedné nebo i více komponent najednou - Probíhá testování jednotkovými a integračními testy, nakonec akceptačními testy 30 - Co je předmětem řešení ekonomické dimenze MMDIS (obecně a v jednotlivých fázích vývoje IS)? - Zaměření se na **ekonomické aspekty vývoje a provozu** - Kolik bude co stát? - Jak budeme náklady krýt? - Co je opravdu potřeba, na co alokovat prostředky? - Jaké ekonomické efekty (přínosy) bude funkcionalita IS mít? - **Náklady** se dají dělit na... - **Pořizovací** -- jednorázové -- vývoj aplikací, nový hardware, licence na SW používaný k vývoji, provozu - **Provozní** -- energie, připojení, API poplatky (poplatky za využívání externích služeb na internetu), údržba, provoz help desku - **Přínosy** - Podpora podnikové strategie, cílů podniku - Zlepšení rozhodovacích procesů - Získání výhody nad konkurencí 31 - Co je předmětem řešení dimenze „technologická infrastruktura" v MMDIS (obecně a v jednotlivých fázích vývoje IS)? - Definice komponent a parametrů technologické infrastruktury, na níž bude provozován IS - **Skládá se z** - HW, SW, služeb - Systémy řízení infrastruktury - **Uvažujeme** - Možnost změn, expanze - Možnost testování -- existence testovacího prostředí -... 32 - Co je třeba uvážit při přizpůsobování metodiky vývoje IS podmínkám konkrétního projektu? - Neexistuje univerzální metodika, proto se metodiky přizpůsobují daným projektům **[Uvážení]** - Rozsah problému, složitost - Velikost týmu - Čas na řešení - Finanční zdroje -... 33 - Globální strategie. Co je předmětem této fáze MMDIS? Jaké má cíle, výstupy a kritické faktory úspěšnosti? - Určuje **poslání firmy, celopodnikové cíle** - Horizont 2-3 let - Zajímá se o předmět podnikání, zákaznické segmenty, nabízené produkty a služby, business model, obchodní partnery, lidské, finanční a technologické zdroje, kontrolu běhu,... - **3 části strategie** - Analýza dosavadního stavu - Model budoucího stavu - Přechod z dosavadního do budoucího 34 - Informační strategie. Co je předmětem této fáze MMDIS? Jaké má cíle, výstupy a kritické faktory úspěšnosti? - **Dílčí strategie** navazující na GST -- globální strategii - Určuje celkovou **koncepci IS**, aby co nejlépe podporovala **cíle podniku** -- z GST - Určuje **kroky koncepce** -- plněny v projektech, podprojektech... 35 - Úvodní studie. Co je předmětem této fáze MMDIS při řešení IASW? Jaké má cíle, výstupy a kritické faktory úspěšnosti? - **Vychází z IST** -- informační strategie **[Výstupy]** - Soupis a definice **požadavků na IS**, posouzení **realizovatelnosti** - Tvoření konceptu aplikace -- **diagramy**,... - Zjištění současného stavu - Odhady nákladů a přínosů systému -... 36 - Globální analýza a návrh. Co je předmětem této fáze MMDIS při řešení IASW? Jaké má cíle, výstupy a kritické faktory úspěšnosti? **[Cíl]** - Transformace **konceptuální úrovně do technologické**, závislé na implementačním a provozním prostředí - Detailnější návrhy **[Obsah]** - Detailní datový model -- entity, atributy, vazby - Detailní funkční model -- popis funkcí, zda jsou automatizované,... - Plán **školení** relevantních pracovníků - Plán **řešení bezpečnosti** 37 - Detailní analýza a návrh. Co je předmětem této fáze MMDIS při řešení IASW? Jaké má cíle, výstupy a kritické faktory úspěšnosti? **[Cíl]** - Dokončení **datové architektury** - Detailní návrh všech aspektů aplikace **[Obsah]** - Návrh databázových souborů -- způsobů ukládání - Návrh **testovacích dat** - **Doladění** návrhu, speciálně co se týče často užívaných funkcí - Revize plánů **školení** - Návrh všeho, co se týče HW, zařízení, spojení, umístění, harmonogram instalace 38 - Implementace. Co je předmětem této fáze MMDIS při řešení IASW? Jaké má cíle, výstupy a kritické faktory úspěšnosti? **[Cíl]** - **Realizace** systému ve vybraném prostředí - **Fyzický návrh DB** v konkrétním DB systému - Programování, testování, vytvoření **dokumentace** **[Obsah]** - Alokace prostorů pro databázové soubory - Uvedení do provozu přístupových práv - **Testování** systému, opravy - Nákupy HW - **Kontroly konzistence** s návrhy 39 - Zavedení do provozu. Co je předmětem této fáze MMDIS při řešení IASW? Jaké má cíle, výstupy a kritické faktory úspěšnosti? - Spočívá v přípravě IS do **plného provozu**, vyškolení zaměstnanců k používání a údržbě - Příprava technologické infrastruktury - Instalace aplikačního SW - Příprava datové základny - Školení - Probíhá **zkušební provoz IS**, dolaďují se nedostatky - Zkompletování potřebné **dokumentace** - Shrnutí **nákladů** na tvorbu IS 40 - Provoz a údržba. Co je předmětem této fáze MMDIS při řešení IASW? Jaké má cíle, výstupy a kritické faktory úspěšnosti? - Cílem je využívat IS k realizování plánovaných přínosů **[Činnosti]** - Kontroly dodržování předpisů - Kontroly fungování v souladu s cíli podniku, v souladu s plánovanými přínosy - Školení nově příchozích zaměstnanců -- uživatelů - V případě změn, dostatečná informace/přeškolení zaměstnanců - Zajištění aktuálnosti dokumentace podle změn v systému 41 - Úvodní studie. Co je předmětem této fáze MMDIS při řešení TASW? Jaké má cíle, výstupy a kritické faktory úspěšnosti? - Definujeme požadavky na výstupní produkt od dodavatele TASW - **Specifikace požadavků** - Popis **nutných změn procesů** jako následků použití TASW řešení - Plán projektu -- uveden např. **rozpočet a harmonogram řešení** - **Projektová rizika** 42 - Globální analýza a návrh. Co je předmětem této fáze MMDIS při řešení TASW? Jaké má cíle, výstupy a kritické faktory úspěšnosti? - **U TASW** se tato fáze vyčleňuje **jen u velkých projektů**, jinak splývá s UST nebo DAN - **Rozšiřuje** požadavky specifikované v **UST např. o** - Jejich priority, typy - Nefunkční požadavky - Změny k UST - Konceptuální model, model případů užití 43 - Detailní analýza a návrh. Co je předmětem této fáze MMDIS při řešení TASW? Jaké má cíle, výstupy a kritické faktory úspěšnosti? - **Detailní specifikace funkcí, návrhů** - **Návrh úprav UI** aplikace - Návrh a plán **testů** - Návrh **integrace** s ostatními aplikacemi 44 - Implementace. Co je předmětem této fáze MMDIS při řešení TASW? Jaké má cíle, výstupy a kritické faktory úspěšnosti? - **Tvorba a testování** všech komponent IS **podle specifikace v DAN** - **Integrace** do celkového prostředí IS/ICT - **Migrace dat** - **Přizpůsobení procesů** funkcím **TASW** - Vytvoření **dokumentace** - Vytvoření **plánu nasazení** 45 - Zavedení do provozu. Co je předmětem této fáze MMDIS při řešení TASW? Jaké má cíle, výstupy a kritické faktory úspěšnosti? - **Cíl** - uvést IS do plného provozu - **Kompletace** potřebné **dokumentace** -- uživatelská, programátorská, provozní - **Školení** uživatelů, správců IS - **Načtení dat** z původního IS - Testování souladu s **SLA** -- [[viz ot. 29]](#ot_29) 46 - Provoz a údržba. Co je předmětem této fáze MMDIS při řešení TASW? Jaké má cíle, výstupy a kritické faktory úspěšnosti? - **Poskytování IS** uživatelům - **Údržba systému** - **Změny** na základě potřeb - **Řešení incidentů** -- figuruje **help-desk** (oddělení s úkolem řešení uživatelských problémů) - Udržování **aktuální dokumentace** 47 - Vyřazení. Co je předmětem této fáze MMDIS? Jaké má cíle, výstupy a kritické faktory úspěšnosti? - **Vyřazení aplikace** a jejích komponent **z provozu** - Tvoření **dokumentace** o tomto procesu - Tvoření **změn v procesech**, odpovědnostech - **Migrace dat** ze systému ven, do jiných systémů 48 - Architektury IS/ICT. Pojem Architektura, význam architektur pro řízení IS/ICT, podstata a účel architektur. Enterprise Architecture. **[Architektura]** - **Grafické a písemné vyjádření celkové koncepce IS/ICT**, zahrnuje informace o - **Struktuře IS** v návaznosti na organizační strukturu podniku - **Funkcích IS** - **Provozu a bezpečnosti IS** - **Vazbách** na okolí - **Význam, podstata** - **Komunikace** mezi tvůrci IS a vedením podniku - Hledání **jednoduchých schémat** pro **vyjádření složité reality** - **Jasný stavební plán** -- snaha o stabilitu vývoje, i při rychlém provedení **[Typy architektur]** - Datová, aplikační, funkční, procesní,... 49 - Disciplína Enterprise architecture, charakteristika, příklady rámců (TOGAF, Zachman,...), vztah k MMDIS **[Enterprise architecture]** - Koncept, popisující vztah mezi podnikem a jeho IS, je v souladu s cíli podniku a pravidly návrhu **[Zachmanův rámec]** -- zachman framework - Poskytuje jednoduchou a logickou stukturu pro popis celkového pohledu na podnik a jeho IS - Vypisuje důležité aspekty podniku, a ke každému uvádí aspekty IS v různých úrovních techničnosti. Tyto informace jsou zapsané do tabulky -- a.k.a. dvourozměrné matice - Určuje vhodné role - **Projektant** -- business process hledisko - **Vlastník** -- definice strategie, konceptuální modelování - **Návrhář -- definuje aplikační architekturu** - **Stavitel -- infrastruktura, fyzické modelování** - **Dodavatel** -- implementace **[TOGAF]** - Postupy, podle kterých lze strategicky a dlouhodobě řídit podnikovou architekturu - **2 architektury** - **Business architektura** -- strategie, procesy - **IS architektura** - **Aplikační** - **Informační** -- struktura a organizace dat - **Technologická** -- HW - Součástí rámce je **ADM** -- architecture development method -- devítifázový proces, trochu podobný MMDIS vývoji. **[Vztah k vývoji podle MMDIS]** - Jsou si podobné, avšak u TOGAFu je problém s přílišnou integrací podnikové a IT architektury, kdy je obtížné vývoj rozdělit a část např. outsourcovat. MMDIS tyto dvě více separuje. 50 - MDA -- Modelem řízená architektura - Další z významných přístupů k vývoji IS - Podstatou je začít vývoj bez jakýchkoliv ohledů na platformu - Použití jazyka UML **[Vývoj]** - Začne se u **platformově nezávislého modelu**, ten se poté mapuje na různých platformách, výstupem je **platformově závislý** model, následně je generován implementační kód **[MOF]** - meta object facility - Další standard, podobně jako UML - Objekty rozděluje na 4 meta-úrovně, M0 - M3 51 - SOA -- architektura orientovaná na služby - = Service-oriented architecture - Služby jako způsob, kterým IT vykonává podnikové procesy, = jsou využívány v procesech - Služby jsou funkcemi s přesně definovaným vstupem, výstupem - Služby jsou na sobě nezávislé **[Principy]** - Byznys procesy řídí služby, služby řídí technologii - Důležitost schopnosti odpovídat na změny požadavků byznysu 52 - Globální architektura IS/ICT - Hrubý návrh budoucího stavu IS/ICT, zachycuje komponenty a vazby mezi nimi - **Dimenze** - **Vertikální** -- podle úrovně vedení - **Horizontální** -- oddělení podniku **[Stavební bloky]** - **TPS** -- transaction processing system -- nejvíce záleží na charakteru podniku. Provádí datové transakce, např. pořizování, aktualizování dat - **Typy** - **CIM** - Computer Integrated manufacturing - **ERP** -- enterprise resource planning - *...* - **MIS** -- management IS -- řízení podniku, obchodně, finančně,... - **EIS** -- Executive IS -- strategické řízení, **Business Intelligence**, **OLAP** - **OIS** -- Office IS -- podpora kancelářských prací, spolupráce v týmu - **EDI** -- podpora výměn obchodních dokumentů, existují standardizace 53 - Aplikační architektura. Způsoby integrace aplikací. Architektura technologické infrastruktury. - **Aplikační architektura** -- **architektura ASW** -- určuje, jakými ASW je pokryta vyžadovaná funkcionalita IS, jaké vazby mezi ASW jsou - Open source SW -- software s volně dostupným zdrojovým kódem - **Způsoby integrace** -- **API** -- application program interface -- rozhraní, přes které aplikace dokáže komunikovat s ostatními standardním způsobem. Tímto je ostatním aplikacím umožněno využívat funkcionalitu dané aplikace. Rovněž je vhodné standardizovat principy komunikace uživatele s aplikací -- uživatel ani nemusí poznat, že pracuje s více aplikacemi - **Technologická architektura** -- rozhoduje o technologickém řešení aplikace -- propojuje SW, HW a datovou architekturu -- podle technologické architektury se řídí např. vnitřní stavba aplikací a UI []{#ot_54.anchor}54 - Softwarová architektura. Architektura klient-server. Monolitická, dvouvrstvá, třívrstvá architektura. Single-tenant/multi-tenant architecture. **[Klient-Server]** - Aplikace rozdělena na dva či více **kooperující programy** -- většinou na více zařízeních. **Server** je zařízení, které **poskytuje službu** klient-programům skrz komunikaci s nimi. - Jeden program může někdy vystupovat jako klient i server, podle využívané funkce - Snazší expanze, složitější vývoj **[Monolitická]** - Typická pro centralizované zpracování, program běží na centrálním zařízení - Bezpečnější -- program nekomunikuje tolik s okolím, snazší ochrana proti výpadkům - Obtížnější údržba, obtížná expanze a změna zařízení **[Dvouvrstvá]** - **Jedna** ze skupin funkcí **je** **oddělena** od ostatních (z prezentační, aplikační a datové vrstvy) - **Lehký** vs. **Těžký klient** -- těžký, když má více funkcionality na své straně oproti serveru, a vice versa **[Třívrstvá]** - Všechny tři skupiny (viz dvouvrstvá) jsou oddělené a komunikují spolu externě - Dynamičtější, flexibilnější aplikace **[Multitenant/Singletenant]** - **Singletenant** -- využívá jen jeden uživatel -- např. notepad - nemá síťové prvky -- neexistuje datová základna ani nic podobného - **Multitenant** -- služba, kterou využívá více klientů -- např. google maps -- všichni přistupují ke stejným datům přes internet 55 - Softwarová architektura -- Lineární / hierarchická / vrstvená / síťová architektura. Architektonické vzory. **[SW architektura]** - Určuje, z jakých SW komponent bude IS postaven, určuje vazby mezi komponentami - **Lineární** -- sekvenční uspořádání funkcí, použití zřídka - **Hierarchická** -- vazby v systému reprezentovány stromovým grafem, nákladnější - **Síťová** -- části si nejsou nadřízeny/podřízeny, flexibilní - **Vrstvená** -- funkce rozděleny do vrstev, které jsou si podřízeny/nadřízeny, každá vrstva může používat - **Silně vrstvená** -- funkce mohou používat jen bezprostředně podřízené - **Slabě vrstvená** -- funkce mohou používat všechny podřízené 56 - Softwarová architektura -- zpracování: dávkové / interaktivní / řízené událostmi / v reálném čase (princip, výhody, nevýhody) - **Dávkové zpracování** - Požadavky se shromažďují, ty pak aplikace při svém běhu vyřeší - Užití u systémů, které nekomunikují s uživatelem v reálném čase - Snadnější vývoj, provoz; Delší, méně pravidelná doba odezvy - **Interaktivní zpracování** - Okamžité zpracování požadavků - Náročnější vývoj, provoz - **Řízené událostmi** - Startovány [[událostmi]](#ot_21), např. pravidelné odesílání údajů - Zvýšení automatizace, efektivity - **V reálném čase** - Řízené událostmi + odezvy přesně odpovídají procesům, které řídí - Řízení provozu výrobní linky 57 - Softwarová architektura -- zpracování: centralizované / decentralizované / distribuované / kooperativní (princip, výhody, nevýhody) - **Centralizované** - Zpracování hlavním počítačem, na jednom umístění, komunikace s [[lehkými kliety]](#ot_54) - Jednodušší vývoj, provoz, řešení konzistence dat - Výpadek je větším rizikem -- vše stojí na jednom zařízení - **Decentralizované** - Více propojených zařízení, zpravidla každé specializované na část SW (mail server, databázový server,...) - Hraje roli klient/server architektura, vícevrstvá architektura - Oddělení částí více odpovídá struktuře podniku, menší vliv výpadků - Horší zajišťování konzistence - **Kooperativní** - V rámci rozsáhlejší sítě - Funkce prováděny jak podnikovými zařízeními, tak zařízeními celosvětově, přes internet 58 - Popište strukturu nákladů na vývoj a provoz IASW a TASW. - Rovněž referováno v [[ot. 4]](#ot_4) **[IASW]** - Vývoj aplikace na míru -- dražší, specializovanost může vést k neflexibilitě SW při potřebách změn, může vést k dalším nákladům na změny - **Náklady** - **Na vývoj** -- práce specialistů, vývojové prostředí, školení - **Na nákup** -- potřebný HW, licence SW - **Na provoz** -- odpisy zařízení, poplatky za služby používané SW, helpdesk, údržba **[TASW]** - Levnější vývoj, program vyvíjený podle šablony, kterou parametrizujeme 59 - Popište možné varianty outsourcingu při vývoji a provozu IS/ICT. **[Outsourcing...]** - **Podnikového procesu** (Business process outsourcing - BPO) - Podpůrný proces převeden na dodavatele -- týká se jak ICT procesů, tak jiných, např. účetnictví - **Komplexního IS/ICT** - Dodavatel zajišťuje všechny ICT procesy, služby - **Částečný pro IS/ICT** - Outsourcing jen něčeho, procesu, služby,... - Např. databáze v cloudu - Důraz na dobrou integraci se zbytkem IS/ICT **[\ ]** 60 - CMMI -- Capability Maturity Model Integration. - Model, návod pro zlepšování aspektů podniku - Z roku 2000, je sjednocením starších modelů - **Obsah** - **CMMI pro nákup** -- návod pro zlepšování procesů nákupu zboží a služeb - **CMMI pro vývoj** -- návod pro zlepšování procesů při vývoji produktů - **2 způsoby zlepšování** -- kontinuální, stupňovitý - **CMMI pro služby** -- poskytuje návod na zlepšování procesů při poskytování služeb 61 - Modely životního cyklu vývoje informačního systému. - **Životní cyklus** -- časový úsek začínající úmyslem vytvořit IS, končící vyřazením IS **[Vodopádový model]** - 70\. -- 80. léta - Přehledně rozdělené fáze životního cyklu, které jdou v sérii po sobě - Fáze se kreslí do „vodopádu" **[Modely pro iterativní vývoj]** - Odstraňování nedostatků předchozího modelu - Rozdělení do dílčích projektů -- iterací -- po první, plánovací/startovací iteraci probíhá iterace, kdy se dále plánuje, vyvíjí, poté testuje a je sbírána zpětná vazba. Tato iterace se může opakovat neomezeně, dokud nejsme spokojeni s produktem. Následuje - **Modely** - **Inkrementální** -- definice požadavků na začátku, vývoj částí zvlášť - **Evoluční** -- definice nových požadavků v každé iteraci 62 - Metodiky budování IS/ICT, kategorizace, příklady metodik (RUP,...), příklady užití metodik pro různé projekty **[Kategorizace]** - Zaměření -- globální, projektová - Rozsah -- celý životní cyklus, dílčí metodika - Váha -- těžké (rigorózní), lehké - Typ řešení -- IASW, TASW,... - Doména -- BI, CRM, ERP,... -... **[\ ]** **[RUP]** - Rational unified process - Pro **OOP** - **Iterativní vývoj** - **Fáze** - **Počáteční** (plánování) - **Rozpracování** (definice arch.) - **Konstrukce** (realizace, testování) - **Nasazení** **[SCRUM]** - Vývoj rozdělen do "sprintů", po nichž jsou organizovány "stand-up meetingy" kde se představuje a kontroluje provedená práce - **Scrum master** -- vedoucí vývojářského týmu 63 - Agilní a rigorózní přístupy k vývoji IS -- principy, rozdíly, možnosti kombinace. **[Rigorózní]** - Podrobné, formální, přesně definované procesy,... - Vodopád, CMMI **[Agilní]** - Menší důraz na popis všech aspektů vývoje - Kontrolování a monitorování vývoje stale velkou součástí - Často kombinovány s jinými []{#ot_64.anchor}64 - Cloud Computing -- principy, charakteristiky aplikace vyvíjené pro cloud. - Zpracování dat prováděno na oddělené platformě, zpravidla poskytované externím dodavatelem, který poskytuje služby mnoha podnikům - Provoz na sjednocené platformě umožňuje lepší optimalizaci využití výkonu, tím snižuje náklady na zpracování dat - **Charakteristiky** - **Samoobslužnost** -- zákazník si nastavuje míru poskytovaných služeb sám - **Přístup k síti** -- služba poskytována přes internet - **Sdružování zdrojů** -- flexibilně využívané zdroje - **Rychlá elasticita** -- možnost jednoduché expanze - **Měřená služba** -- platí se za fakticky spotřebované zdroje, změřené systémem poskytujícím službu - **Typy cloudových ICT služeb** - **IaaS** -- Infrastructure as a service (dále aaS) -- poskytování infrastruktury, např. databází - **PaaS** -- Platform aaS -- poskytování vývojového prostředí, asistuje i integraci aplikace s ostatními - **SaaS** -- Software aaS -- poskytování funkcionality SW provozovaného na cloudu 65 - SaaS (Software as a Service) -- principy, srovnání s modelem „software jako licence" - **Software jako licence** -- software tradičně poskytovaný přes licenci - Ve srovnání, SaaS jednoduše využívá výhod cloud computingu ([[viz ot. 64]](#ot_64)) k zefektivnění používání poskytovaného software -- a tím i snížení nákladů na funkcionalitu - Kromě obecných výhod může být výhodou snazší proces instalace software, co pracuje s cloudem, SaaS může být i jen webovou aplikací dostupnou přes webové prohlížeče -- znamená snížení nákladů na technický personál, školení,... 66 - Požadavky na IS -- specifikace požadavků, její místo v životním cyklu IS, správa požadavků, klasifikace požadavků. - **Specifikace požadavků -- mezi počátečními fázemi vývoje, vyžaduje spolupráci dodavatele i zákazníka. Definují charakter a detaily celého vývoje** - **Správa požadavků** -- především důraz na zaznamenávání a reakci na změny požadavků zákazníka, které vyplynou ze zpětné vazby - **Klasifikace** - **Funkční požadavky** - Co musí systém umět -- funkcionalita - Vychází z procesů, které plánujeme vyvíjeným IS podporovat - **Nefunkční požadavky** - Kvalitativní požadavky -- výkon, odezva, charakter rozhraní IS,... 67 - Projekt IS/ICT -- dokumenty při řízení projektu. Organizace projektu. Metodiky řízení projektu. - **Příklady dokumentů** - **Podnět ke zpracování projektového záměru** -- pro přípravu projektu - **Plán projektu** - **Předávací protokol** - **Akceptační protokol** - **Projektová změna** - **Zpráva o čerpání zdrojů projektu** - **Účastníci** - **Sponzor** -- subjekt, který přiděluje prostředky, očekává výnosy (vedení firmy) - **Uživatel výstupů** -- specifikuje požadavky, je uživatelem IS, používáním IS realizuje výnosy pro sponzora - **Řešitel** -- subjekt, který provádí realizaci projektu - **Metodiky** - **PMBOK** -- 44 procesů v 5 skupinách, 9 znalostních oblastech - **PRINCE 2** 68 - Popište různé varianty řešení přístupových práv k datům a funkcím aplikace. - **Přístupová práva** -- definice práv pro jednotlivé uživatele. Často se používá seskupování do skupin s různými úrovněmi práv - **Účel** -- bezpečnost systémů, bezpečnost dat - **Realizace** -- propouštění uživatelů do daných částí systémů na základě úrovně jejich přístupových práv, limitace manipulace se soubory -- podle přístupových práv mohou mít např. jen právo na čtení apod. - **Autentizace** -- k jednoznačné identifikaci uživatele a nastavení práv podle pravidel. Zpravidla přes jméno, heslo, existují i pokročilejší techniky jako certifikát, ověření biometrických údajů - **Autorizace** -- proces ověření přístupových oprávnění při provádění nějaké akce