Otázky k SZZ Projektování IS 2022/2023 PDF
Document Details
Uploaded by Deleted User
2023
Tags
Summary
This document contains a set of questions for a subject called "SZZ Projektování IS" in the academic year 2022/2023, focusing on different aspects of Information Systems (IS) design, including ICT management, models for project development life cycles, analysis and design of IS, and various modeling techniques. It covers topics such as data modeling, functional modeling, and object-oriented approaches, examining crucial aspects like system processes, architecture, integration methods, and related tools.
Full Transcript
Okruhy otázek k SZZ INFON 2022/2023 Projektování IS 1. ICT management, modely životního cyklu vývoje projektu. 2. Analýza a návrh IS, nástroje datového a funkčního modelování. 3. Objektově orientovaná analýza a modelování, diagramy a jejich vzájemné souvisl...
Okruhy otázek k SZZ INFON 2022/2023 Projektování IS 1. ICT management, modely životního cyklu vývoje projektu. 2. Analýza a návrh IS, nástroje datového a funkčního modelování. 3. Objektově orientovaná analýza a modelování, diagramy a jejich vzájemné souvislosti. 4. Standard UML, jeho vznik, vývoj, ISO, vlastnosti, součásti a možnosti využití. 5. Modelování dynamických vlastností systému pomocí UML. 6. Modelování interakcí s využitím UML. 7. Principy činnosti CASE nástrojů. Možnosti modelování požadavků na IS. Podpora implementace IS. Projektová dokumentace. 8. Vývoj přístupů k analýze a modelování procesů, historický kontext, různé techniky, diagramy a notace, standardizace. 9. Modelování procesů s využitím Unified Modeling Language (UML), diagramy, výhody a nevýhody. 10. Modelování procesů s využitím Business Process Model and Notation (BPMN), specifikace, submodely, typy diagramů, základní a rozšířené kategorie elementů v diagramech. 11. Decision Model and Notation (DMN), hlavní části, využití v procesním modelování, vztah k BPMN. 12. Softwarové nástroje podporující BPMN, simulace procesů, optimalizace procesů. 13. Petriho sítě a jejich využití v procesním modelování. 14. Podnikové informační systémy a jejich integrace v podniku. Tradiční architektura informačního systému versus architektura ERP systému. 15. Typy informačních systémů. Globální a informační strategie podniku, kritické faktory úspěchu (CSF). Postup vytvoření informační strategie. 16. Architektura informačních systémů – metody a frameworky, TOGAF. 17. Business architektura – podnikové procesy a implementace požadavků na informační systémy, nástroje pro podporu analýzy. 18. Datová architektura, postupy tvorby datové architektury, interakční analýza – CRUD analýza. Aplikační architektura, technologická architektura. 19. Systémová integrace a její typy, metody systémové integrace. CI/CD procesy – průběžná integrace a průběžné nasazování. 20. Výběr systémového integrátora, softwarové nástroje pro systémovou integraci. Životní cyklus vývoje informačního systému, náklady IS (TCO). Outsourcing informačních systémů. 1. ICT management, modely životního cyklu vývoje projektu ICT managment ICT management = řízení informačních a komunikačních technologií Zahrnuje řízení a koordinaci různých aspektů informačních technologií v organizaci Cílem je zajistit, aby tyto technologie podporovaly obchodní cíle a strategie organizace ICT management je komplexní oblast, která zahrnuje mnoho různých aktivit, procesů a funkcí ICT management obvykle zahrnuje následující činnosti: o Plánování informačních technologií – identifikace potřeb organizace a stanovení strategií pro dosažení obchodních cílů o Nákup a implementace technologií – výběr a implementaci potřebných HW a SW nástrojů o Správa technologií – správa a údržba technologií, aktualizace a opravy o Řízení projektů o Řízení rizik – identifikace a řízení rizik spojených s používáním informačních technologií o Řízení lidí – řízení a vedení týmů Celkově řečeno, ICT management je důležitým procesem, který umožňuje organizacím plně využívat výhod, které poskytují moderní informační a komunikační technologie Modely životního cyklu vývoje projekt Existuje několik modelů životního cyklu vývoje projektu Každý z nich poskytuje různý rámec pro plánování, implementaci a řízení projektu Vodopádový model o Model je založen na předpokladu, že fáze projektu musí být dokončeny postupně a sériově o V modelu jsou jednotlivé fáze projektu odděleny a provádějí se postupně po sobě o Model se často používá v případech, kdy jsou požadavky dobře definovány a kdy je výsledek projektu jasný o Fáze: Požadavky – Návrh – Implementace – Testování – Údržba Model prototypování o Model se používá v případech, kdy jsou požadavky na výsledek projektu nejasné a kdy je třeba získat zpětnou vazbu od uživatelů o V modelu se vytvoří funkční prototyp, který se postupně zdokonaluje až do finální verze Spirálový model o Model umožňuje postupné zlepšování projektu během opakovaných cyklů o V modelu se provádí analýza, návrh, implementace a hodnocení v každém cyklu o Model se používá v případech, kdy jsou požadavky nejasné a kdy je třeba získat zpětnou vazbu od uživatelů o Fáze: Plánování – Analýza rizik – Návrh – Implementace – Testování – Evaluace – Vydání Agilní model o Model se používá v případech, kdy je třeba vyvíjet projekt rychle a flexibilně o V modelu se projekt vyvíjí v krátkých cyklech, které umožňují časté změny požadavků a získání zpětné vazby od uživatelů o Fáze: Plánování – Analýza požadavků – Návrh – Implementace – Testování – Vydání 2. Analýza a návrh IS, nástroje datového a funkčního modelování Analýza a návrh IS Analýza a návrh informačního systému jsou klíčové kroky v procesu vytváření účinného IS Proces zahrnuje sběr a analýzu požadavků uživatelů, návrh IS, vývoj a implementaci IS a nakonec jeho údržbu a aktualizaci Analýza IS o Analýza IS je proces, který zahrnuje sběr informací o organizaci a jejích potřebách a identifikaci požadavků uživatelů o Cílem analýzy IS je vytvořit podrobný a komplexní popis toho, jak organizace funguje a jaké funkce a procesy by měl IS podporovat o Analýza IS je kritickým krokem v procesu vývoje IS, který umožňuje získat podrobné porozumění organizace a jejích potřeb o Během analýzy se sbírají informace o tom, jak organizace provádí své operace, jaké jsou její cíle a priority a jaké jsou potřeby uživatelů o Dochází i k analýze současných procesů a technologií používaných v organizaci o Zjišťuje se, jak by mohl být IS optimalizován, aby lépe podporoval procesy a cíle organizace o Klíčové kroky při analýze IS: ▪ Identifikace uživatelských požadavků ▪ Sběr a analýza dat ▪ Vytvoření procesních diagramů ▪ Definice funkčních a nefunkčních požadavků ▪ Vyhodnocení rizik ▪ Vytvoření dokumentace Návrh IS o Návrh IS je proces, který následuje po analýze IS o Cílem návrhu IS je navrhnout konkrétní řešení, které bude splňovat požadavky definované během analýzy a bude schopné účinně podporovat procesy a cíle organizace o Návrh IS je klíčovým krokem při vývoji IS, který umožňuje vytvořit konkrétní řešení, které bude plně odpovídat potřebám organizace o Návrh IS zahrnuje určení architektury systému, výběr technologií a platforem, vytvoření datových modelů, návrh uživatelského rozhraní, stanovení plánu implementace atd. o Klíčové kroky při návrhu IS: ▪ Návrh architektury IS ▪ Výběr technologií a platforem ▪ Vytvoření datových modelů ▪ Návrh uživatelského rozhraní ▪ Definice funkčnosti IS ▪ Stanovení plánu implementace ▪ Testování a údržba IS Implementace IS o Zahrnuje vytvoření IS na základě navržené architektury a specifikace komponent o Tato fáze zahrnuje testování IS a jeho nasazení do produkčního prostředí o Po implementaci by měla následovat údržba IS, která zahrnuje opravy chyb a aktualizace Nástroje datového a funkčního modelování Datové a funkční modelování jsou dva základní typy modelování v rámci informačních systémů Datové modelování se zaměřuje na popis dat, které jsou v IS uložena a jak jsou propojena mezi sebou Funkční modelování se zaměřuje na procesy a funkcionalitu, které jsou v IS implementovány Oba typy modelování jsou velmi důležité pro úspěšnou implementaci informačního systému Datové modelování o Datové modelování se zaměřuje na identifikaci entit (objektů) v systému, atributů a vztahů mezi entitami ▪ Entita může být něco, co je uloženo v IS, jako například zákazník, produkt, faktura aj. o Datové modelování pomáhá definovat, jaké informace budou uloženy v IS a jaké vztahy mezi entitami existují o Každá entita má určité atributy, což jsou vlastnosti, které lze popsat jako charakteristiky entity o Vztahy mezi entitami popisují způsob, jakým jsou entity propojeny a jak spolu souvisí o Datové modelování lze provádět pomocí různých nástrojů, jako jsou ER diagramy nebo UML diagramy Funkční modelování o Funkční modelování se zaměřuje na procesy a funkcionalitu, které jsou v IS implementovány o Funkční modelování pomáhá definovat, jak bude systém pracovat a jak bude interagovat s uživateli o Procesy jsou kroky, které musí být vykonány, aby byla splněna určitá činnost o Každý proces má určitý vstup a výstup o Funkcionalita se zaměřuje na to, co systém umožňuje uživatelům dělat o Funkční modelování lze provádět pomocí různých nástrojů, jako jsou BPMN diagramy, Use Case diagramy nebo UML diagramy Základní rozdíly o Zaměření ▪ Datové modelování se zaměřuje na popis dat, která jsou v systému uložena a jak jsou propojena mezi sebou ▪ Funkční modelování se zaměřuje na procesy a funkcionalitu, které jsou v IS implementovány o Výstupy ▪ Výstupem datového modelování je datový model, který obsahuje informace o entitách, atributech a vztazích mezi nimi ▪ Výstupem funkčního modelování jsou procesní modely nebo diagramy, které popisují, jak systém funguje a jak se v něm pracuje o Použití ▪ Datové modelování se používá k navrhování databází a organizování dat v IS ▪ Funkční modelování se používá k navrhování procesů a funkcionality systému o Nástroje ▪ Pro datové modelování se používají nástroje jako ER diagramy nebo UML diagramy ▪ Pro funkční modelování se používají nástroje jako BPMN diagramy, Use Case diagramy nebo UML diagramy 3. Objektově orientovaná analýza a modelování, diagramy a jejich vzájemné souvislosti OOA se zaměřuje na analýzu požadavků a funkcionalit systému, kde výsledkem je model systému OOM se zaměřuje na návrh architektury systému a jeho komponent OOA – Objektově orientovaná analýza = proces, který se používá k analýze a modelování požadavků na softwarový systém z objektového pohledu Cílem OOA je definovat funkční a nefunkční požadavky na systém a vytvořit model, který popisuje chování systému, vztahy mezi jeho součástmi a interakce s okolím Celkově umožňuje definovat a analyzovat požadavky na systém z objektového pohledu a vytvořit model, který slouží jako základ pro další fáze vývoje softwaru V OOA se k modelování používají diagramy, které umožňují vizualizaci různých aspektů systému Mezi nejpoužívanější diagramy v OOA patří: o Use Case diagramy – poskytují funkční náhled systému (kdo se systémem pracuje a jak) o Class diagram – diagram tříd poskytuje logický náhled na systém ▪ Znázorňuje datové struktury, operace u objektů a jejich vazby ▪ Diagram tříd se využívá pro tvorbu ERD a při návrhu implementace o Diagram aktivit – grafické znázornění algoritmů ▪ Diagram se používá pro modelování procedurální logiky, procesů a zachycení workflow ▪ Každý proces v diagramu je reprezentován sekvencí kroků, které určují řídící tok Další fází v OOA je analýza chování systému, která se zabývá popisem procesů a interakcí mezi objekty v systému. K tomu se často používají následující diagramy: o Sekvenční diagramy – znázorňuje komunikaci mezi objekty v čase o Stavový diagram – zobrazuje životní cyklus objektů a stavy do kterých se dostávají ▪ Obsahuje 3 základní prvky: stav, událost, přechod Poslední fází OOA je vytvoření modelu systému, který zahrnuje všechny funkční a nefunkční požadavky a vztahy mezi součástmi systému Model systému se dále používá v OOM, zaměřující se na návrh architektury systému a jeho komponent OOM – Objektově orientované modelování = proces, který se používá k návrhu architektury softwarového systému a jeho komponent z objektového pohledu Cílem OOM je vytvořit model, který popisuje strukturu a chování systému a jeho komponent Umožňuje vývojářům efektivněji implementovat a spravovat software Umožňuje vytvořit návrh architektury a struktury softwarového systému OOM odpovídá požadavkům, specifikacím a zároveň je efektivní a snadno udržovatelný V OOM se používají diagramy, které umožňují vizualizaci různých aspektů systému Mezi nejpoužívanější diagramy v OOM patří: o Class diagram – slouží k popisu datových struktur a vztahů mezi těmito strukturami v systému o Objektový diagram – je snímkem objektů a vztahů v systému v určitém časovém okamžiku o Package diagram – slouží k organizaci tříd do logických celků a k popisu vztahů mezi celky Další fází v OOM je analýza chování systému, která se zaměřuje na popis procesů a interakcí mezi objekty v systému. K tomu se často používají následující diagramy: o Stavový diagram – zobrazuje životní cyklus objektů a stavy do kterých se dostávají ▪ Obsahuje 3 základní prvky: stav, událost, přechod o Diagram aktivit – grafické znázornění algoritmů ▪ Diagram se používá pro modelování procedurální logiky, procesů a zachycení workflow ▪ Každý proces v diagramu je reprezentován sekvencí kroků, které určují řídící tok o Sekvenční diagramy – znázorňuje komunikaci mezi objekty v čase Poslední fází v OOM je implementace a správa softwarového systému Model vytvořený v OOM slouží jako základ pro implementaci a testování systému Vzájemné souvislosti a rozdíly OOA a OOM jsou dva různé přístupy k návrhu softwarového systému z objektového pohledu Tyto dva přístupy jsou vzájemně propojeny, ale liší se v několika klíčových aspektech o OOA slouží k identifikaci požadavků a specifikací o OOM se zaměřuje na návrh architektury a komponent systému Souvislosti mezi OOA a OOM: o Oba procesy jsou založeny na objektovém paradigmatu a používají koncepty, jako jsou třídy, objekty, atributy a metody o Oba procesy jsou fázemi v procesu vývoje softwarového systému a slouží k vytvoření kvalitního a efektivního návrhu systému o Oba procesy využívají diagramy, aby vizualizovaly různé aspekty systému Rozdíly mezi OOA a OOM: o OOA se zaměřuje na analýzu požadavků a specifikací systému a slouží k vytvoření konceptuálního modelu systému o OOM se zaměřuje na návrh architektury systému a jeho komponent a slouží k vytvoření technického modelu systému o OOA slouží k identifikaci požadavků a specifikací, které jsou poté použity v OOM k navržení architektury a komponent systému 4. Standard UML, jeho vznik, vývoj, ISO, vlastnosti, součásti a možnosti využití Standard UML (Unified Modeling Language) UML je jednotný jazyk pro tvorbu diagramů Soubor grafických notací, který definuje standardy pro jednotnou strukturu diagramů Slouží jako užitečný nástroj k usnadnění návrhu a vývoje informačního systému Hlavní vlastnosti UML – standardizovaný jazyk, vizuální reprezentace, objektově orientovaný přístup a univerzálnost Umožňuje specifikaci (struktura a model), vizualizaci (grafy), konstrukci (generování kódu např. z Class diagramu) Strukturu UML lze rozdělit na prvky, relace a diagramy o Prvky – jsou samostatné elementy ▪ Strukturální prvky – třída, rozhraní, případ užití, aktivní třída, uzel ▪ Chování – interakce, stav ▪ Seskupení – balíčky používané k seskupování sémanticky souvisejících prvků ▪ Poznámky – anotace, které lze k modelu připojit o Relace – asociace, agregace a kompozice, závislost, zobecnění, realizace Vznik a vývoj UML vzniklo na počátku 90. let 20. století Vychází z předchozích metod modelování, jako jsou například Boochova metoda, OMT nebo OOSE Tři hlavní autoři (Grady Booch, Ivar Jacobson a James Rumbaugh) o Rozhodli se spojit své přístupy a zkušenosti a vytvořit nový jazyk, který by reflektoval objektově orientovaný přístup a byl univerzálně použitelný V roce 1997 byla vydána první verze UML, která byla později upravena a doplněna o další prvky Nejnovější verze je UML 2.5.2, která byla vydána v roce 2020 ISO (International Organization for Standardization) ISO je mezinárodní organizace, která vyvíjí standardy v různých oblastech V případě UML se ISO podílelo na standardizaci jazyka UML, kde vydalo několik standardů UML ISO je mezinárodní standard pro modelování softwarových systémů ISO/IEC 19501 – standard, který specifikuje základní syntaxi a sémantiku UML o Standard definuje, jakým způsobem mají být definovány různé prvky UML a jakým způsobem mohou být tyto prvky použity pro modelování softwarových systémů ISO/IEC 19503 – standard, který specifikuje metamodel UML o Metamodel popisuje strukturu UML jazyka, včetně všech prvků a vztahů mezi nimi ISO/IEC 19505 – standard, který specifikuje XML notaci pro UML o Standard definuje, jakým způsobem lze UML modely uložit v XML formátu a jakým způsobem lze tyto modely přenášet a sdílet mezi různými aplikacemi Součásti UML Funkční náhled o Use Case diagram – diagram poskytuje funkční náhled systému (kdo se systémem pracuje a jak) Logický náhled o Class diagram – diagram tříd poskytuje logický náhled na systém ▪ Znázorňuje datové struktury, operace u objektů a jejich vazby ▪ Diagram tříd se využívá pro tvorbu ERD a při návrhu implementace o Objektový diagram – je snímkem objektů a vztahů v systému v určitém časovém okamžiku Dynamický náhled popisující chování o Stavový diagram – zobrazuje životní cyklus objektů a stavy do kterých se dostávají ▪ Obsahuje 3 základní prvky: stav, událost, přechod o Diagram aktivit – grafické znázornění algoritmů ▪ Diagram se používá pro modelování procedurální logiky, procesů a zachycení workflow ▪ Každý proces v diagramu je reprezentován sekvencí kroků, které určují řídící tok o Sekvenční diagramy – znázorňuje komunikaci mezi objekty v čase o Diagramy spolupráce – dynamický pohled na systém znázorňující chování objektů v systému Implementační náhled o Diagram komponent – ilustruje organizaci a závislosti mezi softwarovými komponentami ▪ Zdrojové komponenty tvoří soubory vytvořené použitým programovacím jazykem o Diagram nasazení – diagram upřesňující rozmístění implementovaných softwarových komponent na jednotlivé technické prostředky reprezentované v PC Možnosti využití UML se používá při návrhu, vývoji a dokumentaci softwarových systémů Lze ho obecně použít třemi způsoby, jako náčrt, plán nebo programovací jazyk UML jako náčrt o Jedná se o ručně kreslené diagramy na tabuli anebo do sešitu o Možnost náčrtu se využívá i v průběhu návrhu systému, když diskutujeme v týmu o Diagramy mají velmi důležitou vlastnost a tou je abstrakce o Každý diagram je pohled na systém z určitého úhlu UML jako plán o Je o mnoho detailnější než náčrt o Diagramy jsou vytvářeny v CAD nástrojích a slouží jako plán implementace pro programátory o Usnadňují komunikaci v týmu a ulehčují implementaci systému o Po dokončení systému slouží diagramy dále jako dokumentace UML jako programovací jazyk o Z detailního UML diagramu lze vygenerovat šablonu kódu, která slouží jako základ pro implementaci o V databázích se běžně tyto modely používají pro vygenerování zakládacích skriptů 5. Modelování dynamických vlastností systému pomocí UML Modelování dynamických vlastností pomocí UML Modelování dynamických vlastností systému pomocí UML se zabývá popisem chování systému a jeho interakcí s prostředím a uživateli Diagramy Diagram aktivit o Diagram aktivit v UML je grafickým nástrojem, který se používá pro modelování dynamických vlastností systému o Tyto vlastnosti mohou zahrnovat procesy, algoritmy, workflow aj. o Diagram aktivit je složen z uzlů a hran, které reprezentují jednotlivé aktivity a vztahy mezi nimi o Hlavní prvky diagramu aktivit: ▪ Aktivita – jednotlivá akce nebo soubor akcí, které jsou prováděny v systému ▪ Role – osoba nebo systém, který provádí danou aktivitu ▪ Uzel – reprezentuje aktivitu a obsahuje informace o aktivitě (podmínky, vstupy, výstupy) ▪ Hrany – propojují uzly a reprezentují tok řízení nebo dat mezi aktivitami o Diagram aktivit umožňuje modelovat sekvenční a paralelní aktivity ▪ Cykly, větvení a další struktury, které se používají k modelování procesů v systému Stavový diagram o Stavové diagramy jsou dalším typem diagramu, který se používá v UML o Tyto diagramy popisují chování systému v závislosti na jeho stavu. o Každý stav systému je reprezentován stavovým elementem ▪ Stavový diagram vyjadřuje životní cyklus instancí dané třídy ▪ Vznik instance indikován počátečním (pseudo)stavem ▪ Zánik instance indikován koncovým (pseudo)stavem o Hlavním prvky stavového diagramu: ▪ Stavový element Tyto elementy reprezentují stavy, ve kterých se systém může nacházet Každý stav může mít svůj název a popis, a může být propojen s dalšími stavy pomocí přechodů ▪ Přechod Tyto prvky reprezentují změnu stavu systému Každý přechod může být aktivován určitým podmíněným vstupním signálem nebo událostí a může mít přidruženou akci, která se má provést v případě, že je přechod proveden ▪ Událost Tyto prvky reprezentují vnější podněty, které mohou vyvolat změnu stavu systému ▪ Akce Tyto prvky reprezentují činnosti, které se mají provést v případě, že je proveden přechod Sekvenční diagramy o Sekvenční diagramy popisují interakce mezi objekty v systému a sled událostí, které vedou k změně stavů objektů o Zobrazují sekvenci zpráv, které se vyměňují mezi objekty v různých časech o Každý objekt je reprezentován vertikálním pruhem a zprávy mezi objekty jsou zobrazeny jako šipky mezi pruhy o Hlavní prvky sekvenčního diagramu: ▪ Účastníci Účastníci diagramu jsou entity, jako například objekty, aktéři nebo subsystémy, které spolu komunikují Účastníci jsou reprezentováni obdélníky s jejich názvem uvnitř ▪ Aktivační a ukončovací události Aktivační a ukončovací události označují začátek a konec aktivity, kterou účastník provádí Aktivační událost se zobrazuje jako malý obdélník, který se nachází na horní straně životního cyklu účastníka Ukončovací událost se zobrazuje jako malý kruh na konci životního cyklu účastníka ▪ Podmínky a smyčky Podmínky a smyčky reprezentují rozhodování a opakování v diagramu Podmínka se zobrazuje jako diamantový tvar s textovou popiskou Smyčka se zobrazuje jako uzavřená křivka ▪ Životní linie Vertikální čára, která reprezentuje život objektu a zobrazuje jeho stavy v čase ▪ Zprávy Zprávy reprezentují komunikaci mezi účastníky Zprávy jsou reprezentovány šipkou mezi účastníky, s popiskem zprávy nad šipkou Zprávy mohou být synchronní, asynchronní nebo odpovědí na jinou zprávu 6. Modelování interakcí s využitím UML Modelování interakcí pomocí UML Modelování interakcí s využitím UML je technika používaná k popisu chování systému z pohledu interakcí mezi jeho částmi Kroky modelování interakcí s využitím UML: o Identifikace objektů – krok zahrnuje identifikaci objektů, které interagují v systému o Identifikace scénářů – krok zahrnuje identifikaci různých scénářů, které se mohou v systému vyskytnout o Vytvoření diagramu Diagramy interakcí Interakční diagramy jsou používány k mnoha účelům, např. dokumentace toku zpráv uvnitř případů užití, nalezení tříd a operací, dokumentace opakovaně se objevujících návrhových vzorů atd. Sekvenční diagram o Ukazuje interakce uspořádané v časové posloupnosti o Ukazuje explicitní sekvenci zpráv => zpráva nese informaci a spouští akci v jiném (nebo stejném) objektu, je reprezentována pomocí šipky volání o Účastníci interakce většinou „žijí“ v průběhu celé interakce o Nejčastější operátory interakcí: ▪ Podmíněné spuštění – operace uvnitř bloku jsou spuštěny jen pokud je splněna podmínka stráže ▪ Volitelné spuštění – blok je rozdělen na více horizontálních podoblastí reprezentujících jednotlivé větve podmínky (každá podoblast má vlastní stráž) ▪ Paralelní spuštění – blok je rozdělen na více horizontálních podoblastí (každá podoblast reprezentuje paralelní spuštění) Diagram spolupráce o Ukazuje interakce organizované podle interagujících objektů o Časová dimenze není znázorněna Komunikační diagram o Ukazuje interakci organizovanou podle interagujících objektů, a jejich propojení mezi sebou o Ukazuje vztahy mezi rolemi objektů o Časová dimenze není ukázána o Bez časové osy => sekvenční čísla jsou použita pro uspořádání zpráv Diagram časování o Zaměřené na modelování časových omezení a závislostí Diagram přehledu interakcí (Interaction Overview diagram) o Kombinuje sekvenční diagramy a diagramy aktivit Use case Případ užití o Případy užití specifikující vzory chování realizované softwarovým systémem o Každý případ užití lze chápat jako posloupnost vzájemně navazujících transakcí vykonaných v dialogu mezi aktérem a vlastním softwarovým systémem Relace mezi případy užití (3 kategorie) o Relace vložení označovaná klíčovým slovem ▪ Vyjadřuje situaci, kdy určitý scénář popsaný jedním případem užití je součástí i jiného případu užití o Relace rozšíření označovaná klíčovým slovem ▪ Vyjadřuje situaci, kdy určitý případ užití rozšiřuje jiný či představuje variantní průchody tímto scénářem o Relace zobecnění/specializace ▪ Vyjadřuje vztah mezi obecnějším případem užití a jeho speciálním případem Relace mezi aktéry o Pouze jediná relace generalizace/specializace o Aktér charakterizovaný obecnější/podrobnější vlastností 7. Principy činnosti CASE nástrojů. Možnosti modelování požadavků na IS. Podpora implementace IS. Projektová dokumentace Principy činnosti CASE nástrojů (CASE = Computer Aided Software Engineering) = Softwarové inženýrství s využitím softwarové podpory Jde o nástroje modelování IT systému pomocí diagramů, protože člověk chápe lépe obrázek než text Jde o různé nástroje, podporující různé fáze vývoje IS (sběr požadavků, analýza a návrh, implementace) Využití: o Usnadnění a zkvalitnění procesu softwarového vývoje o Datové modelování o Refaktoring – provádění změn v systému tak, aby že nemají vliv na vnější chování kódu o Generování zdrojových kódů a dokumentace CASE nástroje: Oracle Designer, MS Visio, Draw.io Integrované CASE nástroje o Jádrem je centrální repositář, datový́ slovník, který obsahuje prvky ze všech modelů o Umožňují automaticky kontrolovat konzistenci jednotlivých modelů, lepší generování kódu a kontrolovat modely na různých úrovních Modelování požadavků na IS Cíle: o Vymezit hranice systému o Umožnit přesnější odhad pracnosti o Vyjasnit si zadání se zákazníkem o Zachytit omezení, která jsou na IS kladena Způsob zachycení: o Strukturovaný text (specifikace) o Grafické zobrazení ▪ Požadavky – Use Case diagram, scénáře ▪ Hranice systému – kontextový diagram (DFD) Základní kategorizace požadavků: o Funkční o Nefunkční – určují omezení kladená na systém, mají zásadní dopad na návrh architektury a určují dodržování standardů Podpora implementace IS Snahou vývoje IS a obecně SW je co nejvíce věcí automatizovat, proto existují CASE nástroje, které dokáží část kódu generovat, a proto jsou součástí některých větších IDE Podpora implementace IS je úkolem CASE nástroje Generování kódu vzniká na základě fyzického modelu, který́ vznikl z logického modelu Výhodou tohoto generování je, že můžeme mít více fyzických modelů a tím pádem nechat CASE nástroj vytvořit určitou šablonu kódu pro každou z platforem MDD (Model Driven Development) o Modelem řízený vývoj o Tvorba software chápána jako sada transformací od výchozího modelu požadavků až po zdrojový kód aplikace, který je vygenerován CASE nástrojem o Obecný postup: ▪ Model požadavků ▪ Logický model ▪ Fyzický model – obsahuje konkrétní implementační prvky ▪ Další použití vygenerovaného kódu Kromě modelem řízeného vývoje (MDD) pomocí CASE nástrojů, lze do podpory implementace IS zařadit také verzovací systémy jako Git Všechny změny se musí nejprve provádět na modelu => z něj se teprve generuje změněný kód Vyžaduje kvalitní CASE integrovaný́ do vývojového prostředí (IDE) Logický model o Nemusí obsahovat konkrétní implementace na konkrétních databázových systémech o Je výchozím modelem pro tvorbu specifického (fyzického) modelu, je přehledný Fyzický model o Je odvozením (zpřesněním) logického modelu o Zpřesňování implementace může probíhat po krocích, takže fyzických modelů může být více Výhody použití více modelů: o Různé úrovně abstrakce modelu o Zachování podstatné části investic – při přechodu na jinou technologii se zahodí jen ty modely, které na dané technologii závisí o Korespondence modelů – specifičtější model může být odvozen z abstraktnějšího o Flexibilita – do procesu odvození se dá kdykoli zasáhnout o Generování kódu o Snadná změna architektury aplikace Projektová dokumentace Soubor dokumentů, které popisují a specifikují různé aspekty projektu Projektová dokumentace je velmi důležitá pro úspěšné dokončení projektu Je to základní zdroj informací pro všechny účastníky projektu a slouží k řízení, plánování a koordinaci projektových aktivit Zachycuje – modely požadavků (CASE diagram, ERD, …), analýzu, návrh (logický i fyzický) Projektová dokumentace obsahuje: o Plán projektu – popisuje cíle projektu, časové rozpětí, rozpočet, zdroje a další klíčové prvky o Analýza požadavků – shrnuje požadavky a očekávání zákazníka a uživatelů projektu o Specifikace návrhu – popisuje návrh projektu a specifikace funkčností, vlastností a rozhraní o Plán testování – plánování a provádění testů pro ověření funkčnosti a kvality projektu o Dokumentace kódu – obsahuje dokumentaci vývoje a struktury kódu projektu o Plán nasazení – popisuje plán nasazení projektu do produkčního prostředí o Zpráva o výsledcích – zpracovává závěrečné hodnocení projektu a výsledky 8. Vývoj přístupů k analýze a modelování procesů, historický kontext, různé techniky, diagramy a notace, standardizace Historický kontext První diagramové techniky se objevily v 50. letech 20. století o Techniky jako Ganttovy diagramy, které se používaly k zobrazení časového průběhu projektů V 60. a 70. letech 20. století se rozšířily další diagramové techniky o Techniky jako jsou PERT a CPM V 80. letech 20. století se začaly používat diagramy toku dat (DFD), které se používaly k zobrazení průběhu dat a informací v procesech V této době se také objevila notace BPMN, která se stala standardem pro modelování procesů v oblasti řízení procesů V posledních letech se objevují nové přístupy k analýze a modelování procesů, jako je proces mining, který využívá datovou analýzu k identifikaci a optimalizaci procesů Techniky Ganttův diagram o Technika používaná pro vizualizaci časového plánování úkolu a jednotlivých plánů projektu o Diagram ukazuje, kdy začínají a končí jednotlivé úkoly nebo fáze projektu (v závislosti na čase) o Ganttův diagram se skládá z: ▪ Horizontální osy – reprezentuje časové rozpětí projektu ▪ Vertikální osy – obsahuje seznam úkolů nebo fází projektu o Úkoly jsou zpravidla zobrazeny jako pravoúhlé bloky, které začínají v okamžiku zahájení a končí v okamžiku dokončení o Délka bloku odpovídá délce trvání daného úkolu o Tyto bloky mohou být také propojeny pomocí závislostí, což ukazuje, že jeden úkol musí být dokončen před zahájením dalšího PERT (Program Evaluation and Review Technique) o Technika projektového řízení, která se používá k plánování, koordinaci a sledování projektů s nejistými časy trvání jednotlivých úkolů o PERT je založena na matematické analýze a statistických modelech a slouží k identifikaci kritických úkolů a k optimalizaci celkového času a nákladů projektu o Jde o techniku přezkoumání a hodnocení projektu používaná k hodnocení úkolů o Stochastická technika => v PERT diagramu jsou do úvahy brány i náhodné vlivy na délku trvání jednotlivých úkolů a fází projektu o Diagram PERT vypočítává optimální časy pro provedení úkolů pomocí algoritmu o Centrem procesu jsou sítě PERT, které pracují s časy vypočítanými na základě pravděpodobností CPM (Critical Path Method) o Projektový řídicí nástroj používaný pro plánování a řízení časových plánů projektů o Umožňuje identifikovat kritické cesty, tj. ty činnosti, které mají největší vliv na celkovou dobu trvání projektu (umožňuje efektivně plánovat a monitorovat pokrok projektu) o Obecně lze tuto metodu aplikovat na plánování jakéhokoli projektu o Je deterministická => jsou brány pevné odhady pro délku trvání jednotlivých úkolů a fází projektu, bez ohledu na náhodné vlivy, které mohou ovlivnit délku trvání o Každý úkol je reprezentován jedním odhadem času, který se používá pro výpočet celkového plánu projektu a určení kritických úkolů Diagramy Diagram tříd (Class Diagram) o Diagram tříd poskytuje logický náhled na systém o Znázorňuje datové struktury, operace u objektů a jejich vazby o Umožňuje grafické znázornění tříd, interakcí a vztahů mezi nimi v systému o Diagram tříd se skládá z následujících prvků: ▪ Třídy – reprezentují entity systému, jako jsou objekty, uživatelé, moduly aj. ▪ Vztahy – reprezentují vztahy mezi třídami a popisují interakce mezi nimi. Typy vztahů mohou zahrnovat dědičnost, agregaci, asociaci nebo závislost ▪ Atributy – reprezentují vlastnosti tříd (proměnné, konstanty nebo datové prvky) ▪ Metody – reprezentují funkce a operace, které mohou být prováděny na třídách o Diagram tříd může být velmi užitečný pro modelování a návrh systémů, protože umožňuje vizualizaci struktury systému a vztahů mezi jeho různými částmi o Také může sloužit jako východisko pro tvorbu kódu nebo dokumentace Diagram datových toků (DFD = Data Flow Diagram) o Grafický nástroj pro popis a modelování procesů a toků dat v IS o DFD se používá pro analýzu a návrh IS o Pomáhá při identifikaci funkcí a procesů, které jsou potřebné pro realizaci určitého úkolu o DFD je často používán v kombinaci s dalšími technikami, jako jsou ER nebo Use Case diagramy o DFD se skládá z následujících prvků: ▪ Procesy – reprezentují aktivity, které transformují vstupní data na výstupní data ▪ Toky dat – reprezentují pohyb dat mezi různými procesy ▪ Datová úložiště – reprezentují místa, kde jsou data uložena a kde jsou získávána pro zpracování procesů ▪ Externí partneři – reprezentují entity mimo systém, které interagují se systémem o ER diagram (ERD = Entity-Relationship Diagram) o Grafický nástroj pro modelování datových struktur v IS o ER diagramy jsou často používány pro analýzu a návrh relačních databázových systémů o Pomáhají při identifikaci entit, které jsou potřebné pro uchování dat v systému, identifikují vztahy mezi entitami a umožňují analýzu efektivity a spolehlivosti databázového systému o ERD se skládá z následujících prvků: ▪ Entita – reprezentuje konkrétní objekt nebo skupinu objektů, o kterých chceme ukládat informace v databázi ▪ Vztah – reprezentuje propojení mezi entitami v databázi (vztahy: 1:1, 1:N, N:M, …) ▪ Atribut – reprezentuje specifickou vlastnost entity, kterou chceme ukládat v databázi Notace BPMN (Business Process Model and Notation) = standardizovaný vizuální jazyk pro popis a modelování firemních procesů BPMN umožňuje vytvořit grafickou reprezentaci procesů, která je srozumitelná pro všechny Díky BPMN mohou organizace lépe porozumět svým procesům a najít způsoby, jak je vylepšit a optimalizovat Specifikace: o BPMN definuje notaci pro diagramy, které popisují procesy o Tato notace vymezuje jasná pravidla, jakým způsobem diagramy konstruovat a jak zobrazovat konkrétní elementy – tím sjednocuje znázornění pro snadnější srozumitelnost 9. Modelování procesů s využitím Unified Modeling Language (UML), diagramy, výhody a nevýhody Modelování procesů s využitím UML Modelování procesů s využitím UML je způsob, jak popsat a vizualizovat různé aspekty procesů v informačních systémech pomocí standardizovaného jazyka a notací UML je široce používaný jazyk pro modelování softwarových systémů a umožňuje modelovat nejen strukturu systému, ale také jeho chování a interakce s jinými systémy Procesy mohou být modelovány pomocí různých diagramů UML, v závislosti na tom, jaké aspekty procesu chceme popsat Výhody: o Univerzálnost – UML je univerzální a standardizovaný jazyk, který umožňuje vytváření modelů procesů nezávisle na oblasti aplikace o Jasná komunikace – diagramy UML jsou snadno srozumitelné a pomáhají vysvětlit procesy o Snadná údržba – umožňují snadnou údržbu aplikací v průběhu času o Lepší přehlednost – diagramy umožňují lépe vizualizovat složité procesy Nevýhody: o Složitost – UML může být velmi složitý a obtížný na naučení a používání o Náklady na nástroje – nástroje pro tvorbu UML diagramů mohou být poměrně drahé o Přizpůsobení – UML není vždy přizpůsoben specifickým potřebám a požadavkům aplikace Diagramy Use Case diagram o Používá se pro popis funkčních požadavků systému z pohledu uživatelů o Use Case diagramy se zaměřují na popis toho, jak se uživatelé budou interagovat se systémem a jaké funkce systém nabízí o Use Case diagramy se skládají ze dvou klíčových prvků: aktéři a use case ▪ Aktéři – uživatelé nebo externí systémy, kteří budou interagovat se systémem a používat jeho funkce ▪ Use casy – popisem funkcionality, kterou systém nabízí a kterou mohou uživatelé využívat Diagram tříd (Class Diagram) Diagram aktivit Stavový diagram Sekvenční diagramy Pozn.: Diagramy jsou podrobněji popsány již v otázkách 5, 6 a 8 => proto není nutné zde opět rozepisovat! 10. Modelování procesů s využitím Business Process Model and Notation (BPMN), specifikace, submodely, typy diagramů, základní a rozšířené kategorie elementů v diagramech Modelování procesů s využitím BPMN BPMN (Business Process Model and Notation) = standardizovaný vizuální jazyk pro popis a modelování firemních procesů BPMN umožňuje vytvořit grafickou reprezentaci procesů, která je srozumitelná pro všechny Díky BPMN mohou organizace lépe porozumět svým procesům a najít způsoby, jak je vylepšit a optimalizovat Specifikace: o BPMN definuje notaci pro diagramy, které popisují procesy o Tato notace vymezuje jasná pravidla, jakým způsobem diagramy konstruovat a jak zobrazovat konkrétní elementy – tím sjednocuje znázornění pro snadnější srozumitelnost o Aktuální verze BPMN je 2.0, oficiální přehled prvků: Submodely BPMN obsahuje několik submodelů, které se používají pro specifikaci různých aspektů procesu Orchestrace o Submodel popisuje, jakým způsobem se provádí jednotlivé aktivity v rámci procesu v rámci jediné organizace o Orchestrace modeluje vnitřní chování procesu uvnitř organizace, kde je prováděn o Zahrnuje pouze aktivity, které jsou řízeny interně o Orchestrace umožňuje specifikovat chování procesu z pohledu vnitřního fungování organizace Choreografie o Submodel se zaměřuje na vzájemnou komunikaci mezi účastníky o Komunikace je zde robustní, může probíhat obousměrně Kolaborace o Submodel se zaměřuje na detailní popis úloh, sekvencí atd. o Komunikace mezi účastníky není tak robustní (musí se znázorňovat složitěji) o Obecně platí, že choreografie se využívá v případě, kdy v procesu dochází k častým a komplexním komunikacím mezi účastníky Typy diagramů Diagram soukromého procesu – popisuje jeden soukromý proces Diagram veřejného procesu – popisuje jeden veřejný proces Diagram choreografie – popisuje interakce a vztahy mezi účastníky procesu Diagram konverzace – popisuje výměnu zpráv mezi účastníky procesu Diagram spolupráce – popisuje vztahy a interakce mezi účastníky procesu v rámci jednoho procesu Základní kategorie elementů Tokové objekty – reprezentují vlastní průchod procesem o Patří sem úlohy (Tasks), události (Events) a brány (Gateways) o Úlohy – značí se obdélníkem se zakulacenými rohy, reprezentují dílčí úkol (úlohu) v procesu o Události – značí se kolečkem, které může dále obsahovat, o jakou událost se jedná ▪ Nejdůležitější je událost značící začátek a konec procesu o Brány – značí se kosočtvercem, reprezentují dělení toku ▪ Nejdůležitější je exklusivní a paralelní brána ▪ Exklusivní brána obsahuje podmínku, která dělí tok právě na jeden z možných ▪ Paralelní brána dělí tok tak, že její větve mohou probíhat současně Spojovací objekty – slouží k propojení prvků v procesu, jako jsou sekvenční tok, tok zpráv a asociace o Sekvenční tok – značí logickou návaznost prvků (jak jdou úlohy za sebou) o Tok zpráv – používá se ke komunikaci mezi bazény či plaveckými dráhami o Asociace – používá se ke spojení s artefakty. Např.: spojení s komentářem či databází Bazény a plavecké dráhy – reprezentují jednotlivé účastníky procesu o Bazény – značí jednotlivé účastníky v procesu (např. firmy, oddělení) o Plavecké dráhy – značí konkrétní entity účastníka, jeden bazén se proto může skládat z více plaveckých drah Rozšířené kategorie elementů Artefakty – slouží k poskytování dalších informací o procesu, jako jsou komentáře, potřebná data 11. Decision Model and Notation (DMN), hlavní části, využití v procesním modelování, vztah k BPMN DMN DMN je formální notace pro modelování a specifikaci rozhodovacích procesů v podnikovém prostředí DMN umožňuje zobrazovat a popisovat procesy rozhodování pomocí grafických diagramů Umožňuje snadnou komunikaci a spolupráci mezi různými zainteresovanými stranami Diagramy v DMN zahrnují několik prvků, jako jsou vstupy a výstupy rozhodování, logická pravidla, podmínky a omezení DMN umožňuje provádět analýzu rozhodovacích procesů, například pomocí simulace a verifikace modelů => umožňuje předvídat a testovat chování rozhodování v různých podmínkách DMN se skládá z několika hlavních částí, které slouží k modelování a specifikaci rozhodovacích procesů: o DRD ▪ Grafický diagram, který zobrazuje vztahy mezi rozhodovacími prvky ▪ DRD se skládá z uzlů a hran ▪ Uzly představují rozhodovací elementy, jako jsou datové vstupy, rozhodnutí a výstupy ▪ Hrany představují vztahy mezi těmito prvky, jako jsou vstupy a výstupy či závislosti o BKM ▪ Logický model znalostí, který popisuje obecné znalosti o podnikovém procesu ▪ BKM se skládá z konceptů, pravidel a omezení, které jsou používány k rozhodování o DLD ▪ Diagram, který zobrazuje logiku a podmínky, které jsou použity k rozhodnutí ▪ DLD se skládá z rozhodovacích tabulek, rozhodovacích stromů a podmínkových grafů o Rozhodovací tabulka ▪ Tabulka, která popisuje logiku a podmínky pro rozhodování ▪ Skládá se ze vstupních podmínek, akcí a pravidel, které určují výstup Využití v procesním modelování DMN se používá v rámci procesního modelování pro specifikaci a modelování rozhodovacích procesů Procesní modelování obecně zahrnuje zobrazení a specifikaci procesů pomocí grafických diagramů, které popisují různé kroky a aktivity v procesu a závislosti mezi nimi V kontextu procesního modelování se DMN používá k definici logiky a pravidel pro rozhodování, které se používají během procesu Použití DMN v rámci procesního modelování umožňuje snadnější a efektivnější specifikaci a implementaci rozhodovacích procesů v podnikovém prostředí DMN modely mohou být integrovány do větších procesních modelů, jako jsou BPMN diagramy, které zahrnují další aspekty podnikového procesu, jako jsou úkoly, aktivity nebo tok dat Vztah mezi DMN a BPMN Integrace DMN do BPMN umožňuje vytvářet podrobné procesní modely, které zahrnují logiku rozhodování a podporují automatizaci rozhodovacích procesů V rámci podnikových procesů lze použít DMN i BPMN společně BPMN diagramy mohou obsahovat odkazy na DMN modely, které specifikují rozhodovací procesy DMN modely pak mohou odkazovat na BPMN diagramy, aby vyjádřily závislosti mezi rozhodovacími procesy a kroky v podnikovém procesu 12. Softwarové nástroje podporující BPMN, simulace procesů, optimalizace procesů SW nástroje podporující BPMN Nejpoužívanější softwarové nástroje pro BPMN: o Draw.io – poskytuje mnoho předdefinovaných šablon pro BPMN diagramy a umožňuje uživatelům snadno vytvářet a vizualizovat BPMN diagramy o Bizagi – umožňuje vytváření, automatizaci a monitorování BPMN procesů s funkcemi jako simulace, analýza a reportování o Camunda – platforma pro BPMN, která umožňuje automatizaci procesů, řízení úkolů a rozhodování o Signavio – nabízí možnost vytváření a vizualizace BPMN diagramů, simulaci procesů, automatizace, monitorování a analýzu výkonu procesů Simulace a optimalizace procesů Simulace a optimalizace procesů jsou důležité nástroje v projektování informačních systémů Tyto nástroje umožňují analyzovat stávající procesy a navrhovat vylepšení, která mohou vést ke zlepšení výkonu IS a snížení nákladů na provoz V kontextu projektování IS se simulace a optimalizace procesů obvykle používají pro identifikaci a analýzu problémů v procesech a návrh nových procesů nebo vylepšení stávajících procesů Tyto nástroje mohou být také použity k testování nových funkcí IS nebo ke snížení nákladů na provoz IS Simulace o Simulace procesů je proces modelování a testování reálných nebo hypotetických procesů pomocí softwarového nástroje o Cílem simulace procesů je poskytnout podrobné informace o procesech, které mohou být použity k identifikaci slabých míst a vylepšení výkonu o Simulace procesů mohou pomoci analyzovat, jak bude IS fungovat v různých scénářích a identifikovat potenciální problémy, které by mohly ovlivnit výkon IS o Simulace procesů se obvykle provádí na základě statistických modelů a umožňuje předpovídat, jak bude proces fungovat v různých scénářích o Proces simulace ▪ Začíná identifikací cíle simulace – co chceme simulací dosáhnout ▪ Poté se vytvoří model procesu, který bude simulován ▪ Následně se definují vstupy do procesu ▪ Po dokončení simulace se získaná data analyzují a vyhodnocují, aby bylo možné identifikovat případné problémy nebo nedostatky v procesu ▪ Na základě těchto poznatků lze poté navrhnout vylepšení nebo změny v procesu, které by mohly vést k lepšímu výkonu IS Optimalizace o Optimalizace procesů je proces hledání nejlepších řešení pro zlepšení výkonu procesu o Proces může být prováděn manuálně nebo pomocí softwarového nástroje pro optimalizaci o Optimalizace procesů může být použita pro nalezení nejefektivnějšího způsobu řešení problému nebo pro zlepšení kvality služeb, které IS poskytuje o Proces optimalizace ▪ Začíná definováním cíle optimalizace a stanovením omezení ▪ Po se použije vhodná metoda optimalizace k nalezení nejlepšího řešení ▪ Po dokončení optimalizace se vyhodnotí nalezené řešení a zkontroluje se, zda splňuje stanovené cíle a omezení ▪ Pokud tomu tak je, může být nalezené řešení implementováno v IS 13. Petriho sítě a jejich využití v procesním modelování Petriho sítě Grafický popis a analýza systémů, ve kterých se vyskytují synchronizační, komunikační a zdroje sdílející procesy Tento model byl poprvé navržen v roce 1962 německým matematikem Carlem Adamem Petrim Popis paralelních jevů a konfliktních závislostí o Jednoduchost, přehlednost, modelování dynamiky procesů Petriho síť je uspořádaná pětice PN = (P, T, I-, I+, Z0) o P je konečná neprázdná množina míst (množina je disjunktivní) o T je konečná neprázdná množina přechodů (množina je disjunktivní) o I-, I+ jsou incidenční funkce o Z0 je počáteční ohodnocení Základní pojmy o Místa – obsahují stavovou informaci ve formě značek (token) o Přechody – vyjadřují možné změny stavů ▪ Každý přechod má vstupní a výstupní místa, tím je určeno, které aspekty podmiňují výskyt události ▪ Přechod může být uskutečněn jen pokud není překročena kapacita výstupních podmínek ▪ Dva současně proveditelné přechody jsou konfliktní, když provedení jednoho způsobí, že druhý přestane být proveditelný o Orientované hrany – určují logické vazby (mohou spojit místo s přechodem a naopak) Petriho síť nazýváme konzervativní, jestliže pro každý její stav platí, že celkový počet značek je konstantní Petriho síť nazýváme živou, jestliže jsou živé všechny její přechody, tj., jestliže ke každému ohodnocení existuje dosažitelné ohodnocení, které aktivuje daný přechod Využití Petriho sítí v procesním modelování V procesním modelování se Petriho sítě často používají pro popis chování systému Petriho sítě mohou být použity k modelování a analýze procesů, které zahrnují: o Řízení toku dat a informací – Petriho sítě mohou pomoci při modelování toku dat o Synchronizace a koordinace procesů – Petriho sítě mohou pomoci při modelování synchronizace a koordinace procesů, což může být klíčové při návrhu systému, vyžadující vzájemnou spolupráci o Analýza výkonnosti a spolehlivosti – Petriho sítě mohou být použity pro analýzu výkonnosti a spolehlivosti systému o Návrh nových procesů – Petriho sítě mohou být použity k návrhu nových procesů nebo optimalizaci stávajících procesů 14. Podnikové informační systémy a jejich integrace v podniku. Tradiční architektura informačního systému versus architektura ERP systému Podnikové informační systémy Softwarové aplikace a technologie, které podporují efektivní správu a využívání informací v podniku Umožňují podnikům integrovat a automatizovat různé podnikové procesy a poskytují způsob, jak spravovat a analyzovat data a informace, které jsou v rámci podnikových operací generovány Lze rozdělit do několika kategorií: o ERP (Enterprise Resource Planning) ▪ Systém, který slouží k integraci a správě všech klíčových procesů a informací v podniku ▪ ERP umožňuje podnikům lépe koordinovat své operace a maximalizovat efektivitu a výkon, což umožňuje snížit náklady a zlepšit výkonnost ▪ Skládá se z několika modulů, které pokrývají různé oblasti podniku, jako jsou finance, lidské zdroje, výroba, skladování a logistika ▪ Tyto moduly komunikují mezi sebou a sdílejí informace, což umožňuje získat celkový přehled o situaci v podniku a usnadnit rozhodování o CRM (Customer Relationship Management) ▪ CRM je systém pro správu vztahů se zákazníky, který umožňuje podnikům sledovat a spravovat vztahy se zákazníky ▪ Umožňuje analyzovat data o prodejích a marketingových kampaních ▪ Klíčový nástroj pro zlepšení vztahů se zákazníky a zvýšení jejich spokojenosti o SRM (Supplier Relationship Management) ▪ SRM je systém pro správu vztahů se dodavateli ▪ Umožňuje podnikům spravovat a koordinovat své vztahy s dodavateli ▪ Umožňuje zvýšit efektivitu svých dodavatelských řetězců a snížit náklady na nákupy o PLM (Product Lifecycle Management) ▪ PLM je systém pro správu životního cyklu produktu ▪ Umožňuje podnikům spravovat a koordinovat procesy spojené s vývojem a výrobou produktů od jejich konceptu až po jejich likvidaci o SCM (Supply Chain Management) ▪ SCM je systém pro řízení dodavatelského řetězce Tradiční architektura IS vs. ERP systémů Tradiční architektura IS se obvykle skládá z oddělených aplikací a databází, které jsou navzájem propojené pomocí rozhraní API nebo jiných technologií pro výměnu dat Každá aplikace se obvykle specializuje na určitou oblast, jako je například správa skladu, řízení výroby aj. Tyto aplikace často běží na různých serverech a jsou propojeny pomocí sítě Tento přístup může být velmi flexibilní, ale také může být velmi složitý a náročný na správu Architektura ERP systému je celkové řešení pro správu podnikových procesů, které integruje všechny funkce do jediného systému ERP systém obvykle zahrnuje moduly pro správu financí, výroby, skladování, distribuce, lidských zdrojů Tyto moduly běží na jedné platformě a sdílí stejnou databázi => snadné a efektivní řízení podniku Hlavní rozdíl spočívá v tom, že tradiční architektura IS se skládá z oddělených aplikací, zatímco ERP systém je integrovaný systém s jednotnou databází (ERP systémy jsou snadněji použitelné a efektivnější) o ERP systémy poskytují celkové řešení pro správu podnikových procesů, zatímco tradiční IS jsou často složené z mnoha specializovaných aplikací 15. Typy informačních systémů. Globální a informační strategie podniku, kritické faktory úspěchu (CSF). Postup vytvoření informační strategie Typy informačních systémů Informační systémy mohou být rozděleny podle úrovně řízení, pro které jsou určeny Existují tři základní typy informačních systémů podle úrovně řízení: EIS – systémy pro podporu strategického řízení o Navrženy pro podporu vrcholového managementu při rozhodování na strategické úrovni o Systémy pro podporu strategického řízení umožňují organizaci sledovat klíčové ukazatele výkonnosti a přizpůsobit se měnícím se podmínkám na trhu o Zahrnují například systémy pro analýzu dat, business intelligence a systémy pro řízení vztahů se zákazníky (CRM) MIS – systémy pro řízení středního managementu o Navrženy pro podporu středního managementu při plánování, koordinaci a řízení organizace o Poskytují informace o výkonnosti organizace, což umožňuje přijímat informovaná rozhodnutí o Zahrnují například systémy pro správu zásob, řízení projektů a správu lidských zdrojů TPS – systémy pro operační řízení o Navrženy pro podporu denních operací v organizaci o Umožňují organizaci efektivně řídit své procesy a zdroje V praxi se mohou jednotlivé systémy prolínat a kombinovat, aby organizace měla k dispozici potřebné informace a podporu pro všechny úrovně řízení Globální a informační strategie podniku Dva základní druhy strategií, které mohou být použity pro řízení podniku Globální a informační strategie mohou být propojeny => informační strategie může hrát důležitou roli při podpoře globální strategie Globální strategie o Globální strategie se zaměřuje na rozvoj podnikání na mezinárodní úrovni o Cílem je maximalizovat výnosy a minimalizovat náklady tím, že se podnik snaží získat konkurenční výhodu v mezinárodním měřítku o Globální strategie vyžaduje úzkou spolupráci mezi různými odděleními podniku, aby bylo možné koordinovat činnosti napříč různými zeměmi Informační strategie o Informační strategie se zaměřuje na efektivní využívání informačních technologií pro podporu podnikových cílů o Cílem je poskytnout podniku potřebné informace a nástroje pro správné rozhodování o Informační strategie se zabývá výběrem a implementací informačních technologií, které jsou potřebné pro dosažení podnikových cílů Kritické faktory úspěchu (CSF) Kritické faktory úspěchu jsou klíčové oblasti, ve kterých musí podnik uspět, aby dosáhl svých cílů Jsou specifické pro každé a odvětví a mohou se v průběhu času měnit v závislosti na různých faktorech Význam kritických faktorů úspěchu spočívá v tom, že pomáhají podnikům identifikovat klíčové oblasti, na které by se měly zaměřit, a plánovat své aktivity tak, aby dosáhly požadovaných výsledků CSF mohou být identifikovány pomocí různých metod (např. SWOT analýza) Kategorie kritérií úspěchu: úspěšnosti řízení projektů, technického úspěchu a podnikového úspěchu Postup vytvoření informační strategie Definování pořadí priorit a omezení => plán Formulování cílů, struktura a omezující podmínky informační strategie Analýza podnikových dokumentů (globální podniková strategie, marketingová strategie aj.) Formulace cílů informačního systému Formulace kritických faktorů úspěchu – faktory důležité pro úspěšné zpracování IS Analýza současného stavu IS / ICT Příprava celkové architektury informačního systému (moduly a vztahy mezi moduly) Definice základní funkční struktury klíčových obchodních procesů Definice hlavních podnikových datových zdrojů Řešení klíčových technických, personálních, ekonomických a legislativních aspektů nového IS / IT Určení jednotlivých projektů (IS) pro implementaci informační strategie 16. Architektura informačních systémů – metody a frameworky, TOGAF Architektura IS Architektura informačního systému popisuje způsob, jakým jsou informace, procesy a technologie organizovány v rámci informačního systému, aby podpořily potřeby uživatelů a cíle organizace Dává budování IS určitý směr a je vhodným komunikačním prostředkem mezi vedením podniku a projektanty IS Celkově je architektura IS důležitá pro to, aby organizace mohla správně plánovat a řídit své informační systémy, a tak dosáhla svých cílů a potřeb Musí být názorná, srozumitelná a jednoduchá Informační systém je podpůrný systém pro systém řízení Architektura IS se obvykle skládá z několika vrstev Každá z těchto vrstev má své specifické funkce a komponenty o Vrstva dat ▪ Zahrnuje způsob, jakým jsou informace uloženy, spravovány a používány v rámci IS ▪ Zahrnuje databáze, datové sklady a další způsoby ukládání a správy dat o Vrstva aplikací ▪ Zabývá se tím, jak jsou informace zpracovávány a jaké aplikace jsou používány k zajištění různých funkcí IS ▪ Obsahuje komponenty jako jsou moduly, workflow procesy a služby o Vrstva prezentace ▪ Zaměřuje se na to, jak jsou informace zobrazovány uživatelům IS ▪ Zahrnuje grafické uživatelské rozhraní (GUI) nebo webové stránky o Vrstva infrastruktury ▪ Zahrnuje HW a SW komponenty, které jsou potřebné k provozu IS ▪ Zahrnuje počítače, servery, sítě a další prvky infrastruktury Metody Existuje mnoho různých metod a postupů pro návrh a implementaci architektury IS Nejčastěji používané metody o Architektonické styly ▪ Tyto styly popisují způsob, jak jsou komponenty architektury IS organizovány a jak spolu komunikují ▪ Každý styl má své výhody a nevýhody, a organizace si vybírá ten nejvhodnější pro její specifické potřeby ▪ Příklad: klient-server nebo třívrstvá architektura o Modelování procesů a dat ▪ Tato metoda se zaměřuje na návrh procesů a dat, které jsou součástí informačního systému ▪ Používá se k identifikaci a popisu procesů a datových toků, které jsou potřebné pro podporu podnikových procesů o Business Process Management (BPM) ▪ Metoda se zaměřuje na návrh a implementaci podnikových procesů a souvisejících IS ▪ BPM používá procesní modelování a automatizaci k dosažení lepší efektivity a efektivity podnikových procesů o Agilní metody ▪ Tyto metody se zaměřují na flexibilní a rychlé návrh a implementaci architektury IS ▪ Agilní přístup umožňuje týmům rychle reagovat na změny požadavků a potřeb uživatelů Frameworky Pro usnadnění procesu modelování a implementace architektury IS existuje několik frameworků, které organizacím pomáhají definovat a řídit architekturu IS Některé z nejznámějších frameworků používaných v architekturách IS: TOGAF (The Open Group Architecture Framework) o TOGAF je komplexní metodika, která poskytuje rámec pro návrh a řízení architektury IS o Poskytuje ucelený pohled na architekturu IS, který zahrnuje jak obchodní, tak i technické aspekty o Definuje procesy, postupy, modely a nástroje, které organizaci umožňují vytvořit a udržovat komplexní architekturu IS o TOGAF je strukturován do 4 základních oblastí: ▪ Architektonický rámec – poskytuje základ pro návrh a implementaci architektury IS ▪ Metody návrhu – popisují procesy a postupy, které organizaci umožňují vytvořit a implementovat architekturu IS ▪ Reference na architekturu – definují jednotlivé komponenty architektury IS, jako jsou procesy, datové modely, technické komponenty nebo aplikační služby ▪ Nástroje a technologie – poskytují organizaci potřebné nástroje a technologie pro návrh, implementaci a řízení architektury IS Zachman Framework o Zachman Framework poskytuje hierarchický pohled na architekturu IS a pomáhá organizaci identifikovat klíčové aspekty architektury IS o Framework definuje šest perspektiv, podle kterých organizace může architekturu IS definovat ▪ Kdo, co, kde, kdy, jak a proč Kdo, co, kde, kdy, jak a proč KDO o Kdo potřebuje tento problém vyřešit? Kdo jsou všichni zúčastnění (interní / externí)? CO o Co jsou obchodní a technické požadavky? Jaká jsou rizika? KDE o Kde budou tyto služby spotřebovány? o Kupující a prodejci mohou žít v jakékoli zemi. Geografická pravidla pro prodej produktů KDY o Kdy jsou tyto služby potřebné? JAK o Jak může organizace tyto služby poskytovat? Jaká je připravenost organizace, zákazníka? PROČ o Proč má být problém řešen? Jaké jsou obchodní cíle a řidiči? 17. Business architektura – podnikové procesy a implementace požadavků na informační systémy, nástroje pro podporu analýzy Business architektura Business architektura se vztahuje k procesu návrhu a plánování informačního systému, který podporuje strategické cíle a podnikové procesy organizace Business architektura je obecně považována za klíčový krok v projektování IS, protože poskytuje komplexní pohled na to, jak organizace funguje a jaké jsou její cíle Zahrnuje mnoho různých oblastí, jako jsou podnikové procesy, datová architektura, informační architektura, technická architektura, organizační struktura a další Všechny tyto oblasti jsou navzájem propojeny a ovlivňují se navzájem Cílem business architektury je zajistit, aby IS byl navržen tak, aby podporoval efektivní provoz podniku Výsledkem business architektury by měl být komplexní plán informačního systému, který je srozumitelný pro všechny zúčastněné strany a který se přesně zaměřuje na potřeby organizace Podnikové procesy Podnikové procesy jsou klíčovými prvky business architektury a představují soubor kroků, které organizace provádí ke splnění svých cílů Tyto procesy se mohou lišit v závislosti na konkrétních potřebách organizace, ale všechny by měly být navrženy tak, aby byly účinné, efektivní a udržitelné Podnikové procesy se dělí na: o Primární procesy – přímo souvisí s poskytováním produktů nebo služeb zákazníkům o Sekundární procesy – podporují primární procesy (například řízení kvality) o Podpůrné procesy – poskytují podporu celé organizaci (například řízení lidských zdrojů) Výsledkem správně navržených a řízených podnikových procesů jsou organizace, které jsou schopny plnit své cíle a efektivněji, zvyšovat hodnotu pro své zákazníky Implementace požadavků na IS Výběr referenčních modelů, pohledů a nástrojů Tvorba popisu výchozí business architektury Tvorba popisu cílové business architektury Analýza rozdílů Definování komponent pro roadmapy Analýza očekávaných dopadů business architektury Konzultace architektury se zúčastněnými stranami Finalizace business architektury Nástroje pro podporu analýzy Jedná se o kvalifikované rozhodování na základě dat – Power BI, dashboard OLAP kostka aj. o Power BI ▪ Nástroj pro vizualizaci dat od společnosti Microsoft ▪ Umožňuje uživatelům vytvářet vizualizace pomocí různých typů datových zdrojů, jako jsou Excel, SQL databáze, cloudové úložiště a další ▪ Power BI umožňuje uživatelům sdílet své vizualizace s ostatními uživateli a interaktivně pracovat s daty 18. Datová architektura, postupy tvorby datové architektury, interakční analýza – CRUD analýza. Aplikační architektura, technologická architektura Datová architektura Datová architektura je oblastí business architektury, která se zaměřuje na organizaci, uspořádání a správu dat v organizaci Cílem je zajistit, aby data byla správně definována, uložena, chráněna a přístupná pro účely, které organizace potřebuje Datová architektura se snaží zajistit, aby data byla konzistentní, kvalitní a byla správně propojena s procesy, aplikacemi a dalšími prvky business architektury Datová architektura zahrnuje několik různých komponent, včetně datových modelů, datových slovníků, databází a datových skladů Tyto komponenty se navzájem propojují a tvoří hierarchickou strukturu Datová architektura se obvykle vyvíjí v rámci celkového procesu business architektury o To znamená, že datová architektura musí být pevně propojena s ostatními oblastmi business architektury, jako jsou procesy, aplikace a technologie Správně navržená a řízená datová architektura může mít řadu výhod pro organizaci, včetně zlepšení kvality a konzistence dat, zvýšení efektivity práce s daty, snížení nákladů na správu dat nebo zvýšení zabezpečení a ochrany datových zdrojů Postup tvorby: o Identifikace potřeb a cílů datové architektury o Sběr a analýza požadavků na data o Návrh datové architektury o Implementace datové architektury o Správa a údržba datové architektury Interakční analýza Proces zkoumání interakcí mezi uživateli a informačními systémy Cílem je identifikovat, jak uživatelé interagují s IS a jaké jsou výsledky těchto interakcí Snaží se pochopit potřeby a cíle uživatelů a jak IS mohou těmto potřebám a cílům nejlépe vyhovět Interakční analýza je důležitá pro design a vývoj IS, protože pomáhá zajistit, že IS jsou navrženy a implementovány tak, aby byly uživatelsky přívětivé a efektivní Také pomáhá snižovat náklady na vývoj a údržbu IS tím, že minimalizuje počet chyb CRUD analýza o Metoda analýzy, která se zaměřuje na funkce informačního systému o CRUD = Create, Read, Update a Delete ▪ Tyto funkce jsou nazývány jako základní operace nebo akce, které se aplikují na data v IS o Cílem CRUD analýzy je identifikovat, jakým způsobem jsou operace implementovány v systému a jak se data při nich chovají o Analýza CRUD se obvykle provádí během návrhu IS, ale může být také aplikována na existující systémy pro účely optimalizace a zlepšení jejich funkčnosti o Konkrétně se při CRUD analýze zkoumají následující otázky: ▪ Create (Vytvořit) – jakým způsobem mohou uživatelé vytvořit nová data v systému? ▪ Read (Číst) – jakým způsobem mohou uživatelé prohlížet a vyhledávat data v systému? ▪ Update (Upravit) – jakým způsobem mohou uživatelé aktualizovat data v systému? ▪ Delete (Odstranit) – jakým způsobem mohou uživatelé odstranit data ze systému? Aplikační a technologická architektura Aplikační a technologická architektura jsou dalšími oblastmi business architektury, které se zabývají technickými aspekty informačních systémů a následnou aplikací v organizaci Aplikační a technologická architektura jsou úzce propojeny a navzájem se ovlivňují o Například změna v aplikační architektuře může vyžadovat změnu v technologické architektuře pro podporu nových funkcí aplikací o Na druhé straně může technologická architektura ovlivnit volbu aplikací a technologií používaných v organizaci Aplikační architektura o Aplikační architektura se zaměřuje na organizaci a uspořádání aplikací v rámci organizace o Zahrnuje definici a popis aplikací, které organizace používá, včetně jejich funkcí, rozhraní, datových struktur a způsobu propojení s ostatními aplikacemi a systémy o Aplikační architektura také stanovuje zásady a standardy pro vývoj, nasazení, správu a údržbu aplikací v organizaci Technologická architektura o Technologická architektura se zaměřuje na technické prostředky a infrastrukturu, které organizace používá pro provoz IS a aplikací o Zahrnuje definici a popis technických prostředků, jako jsou servery, sítě, databáze a další HW a SW prvky, které organizace používá o Technologická architektura také definuje zásady a standardy pro výběr, implementaci, správu a údržbu technických prostředků a infrastruktury v organizaci 19. Systémová integrace a její typy, metody systémové integrace. CI/CD procesy – průběžná integrace a průběžné nasazování Systémová integrace = Proces spojování různých částí a systémů do jednoho celku, aby pracovaly jako koordinovaný celek Zahrnuje koordinaci, testování a přizpůsobení jednotlivých systémů tak, aby fungovaly společně bez problémů Cílem systémové integrace je vytvořit funkční a účinný systém, který plní potřeby uživatele Cílem je, aby tento celek pracoval co možná nejefektivněji Proces může zahrnovat například propojení různých aplikací, databází, serverů a dalších IT infrastruktur Typy systémové integrace Tradiční systémová integrace o Zaměřuje na integraci samostatných aplikací a systémů, které mohou být provozovány na různých platformách a technologiích o Tento přístup se většinou používá pro spojení aplikací a systémů, které jsou provozovány na místě v rámci organizace a jsou spravovány odděleně Podniková systémová integrace o Zaměřuje se na vytvoření integrovaného podnikového systému, který spojuje různé aplikace a systémy pomocí standardů a principů interoperability o Používá se pro propojení aplikací a systémů, které jsou provozovány v různých prostředích, jako jsou cloudové služby, mobilní aplikace a IoT zařízení o Hlavním cílem je vytvořit flexibilní, škálovatelný a bezpečný systém, který umožní společnostem rychle reagovat na nové výzvy a příležitosti na trhu Systémová integrace na bázi služeb (SOA) o Integrace se zaměřuje na vytváření propojení mezi různými aplikacemi a systémy pomocí webových služeb o SOA se zaměřuje na integraci různých systémů prostřednictvím standardizovaných a nezávislých webových služeb Metody systémové integrace Horizontální integrace o Tento typ integrace spojuje různé aplikace nebo systémy, které jsou používány v různých oblastech společnosti, např.: řízení lidských zdrojů, účetnictví, marketing o Cílem horizontální integrace je vytvořit jeden integrovaný systém pro všechny tyto oblasti Vertikální integrace o Tento typ integrace spojuje různé úrovně výrobního procesu, od dodavatelů po zákazníky o Proces integrace subsystémů podle jejich funkcí, vytvářením funkčních entit o Integrace probíhá od spodu (základních funkcí) směrem nahoru Hybridní integrace o Tento typ integrace kombinuje horizontální a vertikální integraci o Hybridní integrace se používá v případech, kdy je potřeba propojit různé aplikace a systémy v celé společnosti, ale také je potřeba spojit různé úrovně výrobního procesu CI / CD procesy CI a CD jsou dva související procesy, které slouží k automatizaci vývojového cyklu softwaru a umožňují rychlou a spolehlivou dodávku softwaru zákazníkům CI proces (Continuous Integration) o Průběžná integrace o Proces CI zahrnuje průběžné integrování kódu od více vývojářů do společného repositáře o Následuje automatické spouštění sady testů a kontrolou kódu, aby se zajistilo, že se nově přidaný kód nepřekrývá s existujícím kódem o CI proces umožňuje detekovat chyby a problémy v kódu co nejdříve v procesu vývoje, což usnadňuje opravu a minimalizuje riziko problémů v pozdějších fázích vývoje a nasazení CD proces (Continuous Delivery/Deployment) o Průběžné nasazování o Proces CD zahrnuje automatizované testování, sestavování a nasazení softwaru do produkčního prostředí o Proces umožňuje rychlé a spolehlivé dodání softwaru zákazníkům, čímž se zkracuje doba získání zpětné vazby a zvyšuje se flexibilita a konkurenceschopnost společnosti o Při použití metody Continuous Delivery je kód nasazen do produkčního prostředí až po ručním schválení zákazníkem o Při použití metody Continuous Deployment je kód automaticky nasazen do produkčního prostředí bez potřeby ručního schválení V kombinaci s CI procesem se CD procesy snaží minimalizovat rizika spojená s manuálními úkoly a zajišťují spolehlivý, opakovatelný a automatizovaný vývoj a dodání softwaru 20. Výběr systémového integrátora, softwarové nástroje pro systémovou integraci. Životní cyklus vývoje informačního systému, náklady IS (TCO). Outsourcing informačních systémů Výběr systémového integrátora Systémový integrátor = specialista na propojování různých systémů a technologií, aby vytvořil komplexní a koherentní systém, který splňuje požadavky zákazníka Jeho hlavním úkolem je zajistit, aby různé komponenty systému fungovaly spolehlivě a v souladu s požadavky zákazníka Úloha systémového integrátora je především v převzetí zodpovědnosti za výsledné řešení Systémový integrátor pracuje s různými technologiemi a systémy, včetně HW, SW a sítí Jeho úkolem je zajistit, aby všechny tyto komponenty fungovaly spolehlivě a komunikovaly mezi sebou Systémový integrátor má klíčovou roli při realizaci projektů, které zahrnují propojení různých systémů a technologií Jeho práce začíná v počátečních fázích projektu, kdy spolupracuje s klientem na definici požadavků a návrhu systému Výběr správného systémového integrátora může být klíčovým faktorem pro úspěšnou implementaci nového systému Při výběru systémového integrátora je třeba brát v úvahu několik faktorů: o Zkušenosti a odbornost – měl by mít dostatečné zkušenosti a odbornost v dané oblasti o Dostupnost zdrojů – měl by mít dostatečný počet kvalifikovaných techniků o Certifikace a akreditace – certifikace a akreditace mohou poskytnout vyšší důvěru o Hodnocení referencí – opět zvyšuje důvěru o Komunikace a spolupráce – měl by být schopen poskytovat pravidelné aktualizace SW nástroje pro systémovou integraci Apache Kafka o Open source platforma pro streamování dat a zpráv o Umožňuje rychlé a spolehlivé doručování zpráv mezi různými aplikacemi a systémy Apache Camel o Open source framework pro integraci systémů o Poskytuje různé základní komponenty pro integraci, jako jsou různé protokoly a formáty zpráv MuleSoft o Proprietární integrační platforma, která umožňuje snadnou integraci různých aplikací a systémů pomocí API a dalších nástrojů IBM Integration Bus o Proprietární integrační platforma, která umožňuje snadnou integraci různých aplikací a systémů pomocí různých protokolů a formátů zpráv Dell Boomi o Proprietární platforma pro cloudovou integraci, která umožňuje snadnou integraci různých aplikací a systémů pomocí API a dalších nástrojů Microsoft BizTalk Server o Proprietární integrační platforma, která umožňuje snadnou integraci různých aplikací a systémů pomocí různých protokolů a formátů zpráv Oracle SOA Suite o Proprietární integrační platforma, která umožňuje snadnou integraci různých aplikací a systémů pomocí různých protokolů a formátů zpráv Životní cyklus vývoje IS Životní cyklus kompletně pokrývá celý vývoj IS, který se skládá z jednotlivých na sebe navazujících fází Fáze vývoje: o Analýza požadavků o Návrh o Implementace o Testování o Nasazení o Udržování Náklady na IS (TCO = Total Cost of Ownership) Metodika kalkulace úplných nákladů na vlastnictví informačního systému Náklady na informační systém zahrnují veškeré náklady spojené s pořízením, provozem a údržbou informačního systému v průběhu celého jeho životního cyklu TCO se často používá k porovnání nákladů mezi různými IS a k rozhodování o tom, zda je nákladově efektivní provozovat nebo nahradit stávající systém Mezi hlavní faktory TCO patří náklady na pořízení HW a SW, licenční poplatky, náklady na implementaci a integraci, náklady na školení a podporu uživatelů, náklady na údržbu a aktualizace systému a další Outsourcing IS Outsourcing informačního systému je proces přenesení části nebo celé správy a provozu IS na externí firmu nebo tým odborníků Tato externí firma bude odpovědná za plánování, nákup, instalaci, provoz, údržbu, podporu a rozvoj IS Výhody: o Snížení nákladů – outsourcing může být levnější než vytváření a udržování interního týmu a infrastruktury pro správu IS o Zlepšení výkonu – specializovaný externí poskytovatel může nabídnout větší znalosti, zkušenosti a prostředky pro řízení a udržování IS, což může vést ke zlepšení jeho výkonu o Zvýšení flexibility – outsourcing umožňuje organizaci rychle reagovat na změny v oblasti IS o Snížení rizik – specializovaný poskytovatel může nabídnout lepší bezpečnost a ochranu dat a může mít záložní plány pro minimalizaci rizik spojených s výpadky IS o Větší zaměření na hlavní aktivity – outsourcing může umožnit organizaci zaměřit se na své hlavní aktivity a strategické cíle Rizika: o Ztráta kontroly nad procesy a službami o Riziko ztráty know-how a důvěrných informací o Náklady na správu kontraktu a zvýšené náklady na komunikaci a koordinaci s externí firmou