4IT216
🇨🇿
In Czech
In Czech
Practice Known Questions
Stay up to date with your due questions
Complete 5 questions to enable practice
Exams
Exam: Test your skills
Test your skills in exam mode
Learn New Questions
Manual Mode [BETA]
Select your own question and answer types
Specific modes
Learn with flashcards
Listening & SpellingSpelling: Type what you hear
multiple choiceMultiple choice mode
SpeakingAnswer with voice
Speaking & ListeningPractice pronunciation
TypingTyping only mode
4IT216 - Leaderboard
4IT216 - Details
Levels:
Questions:
406 questions
| 🇨🇿 | 🇨🇿 |
| Byznys | Organizace, která poskytuje produkty nebo služby zákazníkům, na rozdíl od podniku zahrnuje i neziskové organizace a organizace veřejné správy. |
| Systém | Celek tvořený svou jednak celistvostí (danou obvykle cílem či účelem) a jednak souhrnem částí (komponent, prvků) a jejich vzájemných, často dynamických vztahů (interakcí). |
| Informační systém | = je systém, jehož účelem je zajištění správných informací na správné místě ve správný čas. Tyto informace jsou dodávané zpravidla lidem, kteří jsou součástí byznys systému. |
| Informační technologie | Hardware + software pro sběr, přenos, ukládání a distribuci informací. |
| Aplikační software | Software (programové vybavení), určený pro použití uživatelem (v tomto případě se jedná o uživatele, kteří řeší informační potřebu v byznysu) |
| Informatická služba | ICT služba jsou koherentní (spojité) aktivity a/nebo informace dodávané poskytovatelem ICT služby příjemci služby. Tato služby je vytvářena ICT procesy, které při svém průběhu konzumují ICT zdroje. |
| Informatický zdroj | Komponenta (HW, SW, data-informace-znalost) nutná k tvorbě a provozu informatické aplikace / služby. |
| Projekt | Je jedinečný proces sestávající z řady koordinovaných a řízených činností s daty zahájení a ukončení, prováděný pro dosažení cíle, vyhovuje specifickým požadavkům, včetně omezení daných časem, náklady a zdroji. |
| Jaké je místo IS/ICT a jeho řízení při řízení organizace? | IS/IC dnes zabírá 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 směřují k 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. |
| Byznys cíl | To, čeho chce podnik dosáhnout na základě své globální strategie. Podnikové cíle by měly být tzv. SMART. (konkrétní, měřitelné, dosažitelné, realistické, správně načasované) |
| Byznys proces | Je proces, kterým byznys zajišťuje naplnění byznys cílů, reaguje na významné události a zajišťuje produkci plánovaných výstupů (produktů, služeb apod.) Pojmem proces rozumíme skupinu navazujících činností, které jako celek přinášejí hodnotu zákazníkovi (procesu). |
| Informatická služba | ICT služba jsou koherentní (spojité) aktivity a/nebo informace dodávané poskytovatelem ICT služby příjemci služby. Tato služby je vytvářena ICT procesy, které při svém průběhu konzumují ICT zdroje. |
| Informatický zdroj | Komponenta (HW, SW, data-informace-znalost) nutná k tvorbě a provozu informatické aplikace / služby. |
| Informatický proces | Informatický proces chápeme jako množinu logicky navazujících činností, které spotřebovávají zdroje IS/IT (pracovníci, HW, SW, data, finance…). Proces, který je definován svými vstupy a výstupy, je aktivován událostí, která leží mimo útvar informatiky (u interního, resp. externího zákazníka, tedy u uživatele služeb IS/IT). Proces je ukončen událostí, která se rovněž nalézá vně informatické infrastruktury. |
| Popište model SPSPR | Tento model využívá ICT služby jako základního nástroje pro komunikaci mezi byznysem a ICT útvarem. Model definuje zodpovědnosti byznys a ICT manažerů při řízení vztahu byznys- podniková informatika. Základem modelu je řízení vztahu byznys-informatika v pěti vzájemně provázaných vrstvách (S-Strategy, P- Business Processes, S -ICT Services, P -ICT Processes, R -ICT Resources). ICT služby jsou v modelu chápány jako rozhraní mezi byznysem a informatikou, přes které poskytovateli ICT služeb podporuje jednotlivé byznys procesy podniku či jejich dílčí aktivity. ICT službu lze buď nakoupit na ICT trhu, nebo ji dodávat interně. V druhém případě musí ICT útvar podniku zajistit ICT procesy, které službu dodají, a ICT zdroje (HW, SW, data, lidé ... ), jež jsou pro průběh ICT procesů nezbytné. |
| ĚCílem rozdělení řídicích aktivit do pěti vrstev je: | • jasné určení zodpovědností různých typů manažerů/specialistů v podniku, • zprůhlednění způsobu dekompozice podnikových cílů až na úroveň řízení ICT, • vytvoření schématu, ze kterého je možné odvodit vhodné metriky úspěšnosti jednotlivých typů procesů a za ně odpovědných manažerů |
| Vývoj aplikace | Vývoj aplikace je proces, jehož cílem je dosažení plánované změny informačního systému podniku (aplikace). Změna se může týkat kterékoliv komponenty IS (nová aplikace, změna technologické infrastruktury apod.). Podstatné změny se realizují projektem. Ukončením projektu vzniká nová verze IS podniku (aplikace). |
| Provoz aplikace | Provoz IS (aplikace) je procesem, který zajišťuje běh jednotlivých aplikací a dodávání ICT služeb koncovým uživatelům. Služby musejí být provozem IS zajištěny tak, aby dosahovaly vlastností (například dostupnost, doba odezvy, bezpečnost), které byly mezi provozovatelem služby a jejím zákazníkem dohodnuty. |
| Individuální aplikační software (IASW) | Při použití IASW je aplikace vytvořena na míru podle potřeb podniku, instalována na definované technologické platformě a poté pro uživatele daného podniku provozována. Funkcionalita aplikace je navržena tak, aby optimálně podporovala činnosti podnikového procesu, pro který je určena. Výhodou této alternativy je, že podnik může aplikací podpořit svoje specifické procesy a dosažení specifických cílů na trhu. |
| Typový aplikační software (TASW). | Aplikace je vytvořena a dále rozvíjena specializovaným výrobcem generalizací požadavků určité třídy podniků například bank, výrobců automobilů apod. I když celkové náklady vývoje TASW jsou výrazně vyšší než v případě IASW, cena licence TASW je pro zákazníka obvykle nižší, protože celkové náklady vývoje se rozpustí mezi více zákazníků. Další výhodou je, že celková doba nasazení aplikace je kratší, protože se instaluje již hotový produkt. Nevýhodou ale je, že podporovaný podnikový proces se musí přizpůsobit logice a možnostem TASW. Na druhé straně přední výrobci TASW zabudovávají do funkcionality svých produktů nejlepší praktiky, které jsou v daném odvětví známy. Instalací TASW a přizpůsobením svých podnikových procesů tak může méně vyspělý podnik aplikovat zkušenosti a nejlepší praktiky lídrů na trhu. Další nevýhodou TASW je, že podnik obvykle nevyužije veškerou funkcionalitu TASW, tzn., že de facto kupuje i to, co nepotřebuje. Z charakteristiky vyplývá, že TASW je výhodné volit především pro vysoce standardizované aplikace jako účetnictví, zpracování mezd, správa řízení dokumentů apod. |
| Řešení vlastními zdroji vs řešení externími zdroji | Kritéria, která v tomto rozhodování hrají nejdůležitější roli, jsou: náklady, spolehlivost, bezpečnost dat a míra závislosti podniku na externích dodavatelích. V současnosti většina podniků řeší vývoj aplikací outsourcingem nebo nákupem TASW, neboť vlastní vývoj softwaru bývá časově i cenově nákladnější varianta. Provoz IS naopak většina podniků v současnosti řeší vlastními zdroji. Důvodem je, že zatím tuto alternativu vyhodnocují jako nákladově výhodnější a zejména méně rizikovou z hlediska bezpečnosti dat. Nicméně počet firem, které přecházejí na outsourcing provozu celého IS, resp. některé z aplikací IS, neustále roste a dá se předpokládat, že do konce druhého desetiletí 21 . století bude outsourcing provozu a zejména jeho varianta SaaS převažující formou provozu podnikových IS. |
| Vývoj řešen jako IASW Výhody | • IS šitý na míru potřebám podniku (funkce IS přesně odpovídají požadavkům podnikových procesů) • inkrementální růst IS dle potřeb podniku • detailní znalost provozovaného IS/ICT je přímo v podniku • konkurence nezná silné a slabé stránky podnikového IS/ICT • snadná reakce |
| Vývoj řešen jako IASW Nevýhody | • vysoké náklady • do IASW nejsou obvykle zabudovány celosvětově osvědčené pracovní postupy • dlouhá doba řešení • obvykle nižší kvalita IASW a obtíže s integrací celého IS/ICT zapříčiněné relativně nízkou kvalifikací domácích řešitelů • nízká parametričnost IASW - jestliže vývoj IASW je odvozen od okamžitých požadavků uživatelů a požadavky nejsou dostatečně zobecněny, není řešení realizováno jako parametrické a tím se prodlužuje a prodražuje budoucí údržba • při fluktuaci řešitelů značná rizika nekonzistencí |
| Vývoj řešen jako TASW Výhody | • rychlá realizace • nízké náklady • lze vybrat osvědčená řešení pro každou část IS • TASW obsahuje tzv. “nejlepší zkušenosti” širokého okruhu uživatelů • TASW je parametrické a tím je možné řešit řadu nových požadavků pouze jiným nastavením parametrů místo reprogramováním |
| Vývoj řešen jako TASW Nevýhody | • procesy v podniku se musejí přizpůsobit možnostem TASW • jestliže jsou nakoupeny jednotlivé SW komponenty od různých dodavatelů, pak obtížná integrace různých aplikací do jednoho IS - vysoké nároky na řešitelský tým • obtíže s údržbou vazeb mezi aplikacemi a tím i relativně nízká stabilita celého IS |
| Vývoj řešen pomocí vlastních zdrojů Výhody | • inkrementální růst dle potřeb podniku • konkurence nezná silné a slabé stránky podnikového IS/ICT • detailní znalost provozovaného IS/ICT je přímo v podniku • snadná reakce na okamžité potřeby uživatelů |
| Vývoj řešen pomocí vlastních zdrojů Nevýhody | • většinou vysoké náklady a dlouhá doba řešení • aplikovatelné jen pro některý ASW (téměř vyloučené pro HW a ZSW) • při fluktuaci řešitelů značná rizika nekonzistencí v systému |
| Vývoj řešen pomocí externích zdrojů (Nákup celého IS/ICT od generálního dodavatele) Výhody | • rychlá realizace, nízké náklady • optimálně využity znalosti interních i externích specialistů • profesionální řešení každé komponenty i celého IS/ICT • lze vybrat osvědčená řešení pro každou část IS • integrace všech komponent je garantována dodavatelem • dodavatelem může být garantována i stabilita vývoje IS/ICT |
| Vývoj řešen pomocí externích zdrojů (Nákup celého IS/ICT od generálního dodavatele) Neýhody | • rizika úniku konfidentních informací mimo podnik • závislost na dodavateli a jeho: • schopnostech • serióznosti • stabilitě |
| Provoz pomocí vlastních zdrojů Výhody | • rychlá realizace (údržby) • nezávislost na externím dodavateli |
| Provoz pomocí vlastních zdrojů Nevýhody | • při nákupu TASW po jednotlivých komponentách od různých dodavatelů a provozu vlastními zdroji jsou kladeny vysoké nároky na interní řešitelský tým, čímž vzniká nestabilita IS spojená s obtížnou údržbou vazeb mezi jednotlivými aplikacemi |
| Provoz pomocí externích zdrojů Výhody | • snížení nároků na provozní personál • podnik se může lépe soustředit na svůj hlavní předmět činnosti, • snadnější přizpůsobování kapacit IT dle potřeb podniku, • jedná-li se o velmi silného systémového integrátora (dodavatele) provozujícího IS/ICT pro několik zákazníků, mohou být náklady jednotlivých zákazníků ještě nižší • dodavatelem může být garantována i stabilita vývoje IS/ICT, • možnost využívání nejprogresivnějších technologií (systémový integrátor může rychleji obměňovat svůj technologický park), • rozložení rizik mezi podnik a systémového integrátora, • rychlé dosažení požadovaných služeb, • vysoká flexibilita služeb – služby lze aktivovat a deaktivovat dle potřeb podniku • obvyklá vyšší úroveň kvality služeb a spolehlivosti |
| Provoz pomocí externích zdrojů Nevýhody | • vyšší náklady (ale obvykle při vyšší kvalitě služeb a při vyšší spolehlivosti) • při stejné úrovni služeb jako při interním provozu bývají náklady nižší • roste závislost na systémovém integrátorovi a jeho: - schopnostech - serióznosti - stabilitě - velká bezpečnostní rizika |
| Principy modelování při analýze a návrhu IS/ICT Model | Modelem rozumíme obecně reprezentaci něčeho jiného, která má některé podobné vlastnosti jako to původní, takže pomocí této reprezentace lze to původní poznat. Model je obvykle zjednodušující, tedy volí jen některé podobné vlastnosti toho původního, podle zvoleného hlediska. Příkladem modelu může být model auta jako hračka napodobující skutečný automobil, může to být maketa stavby, může jít o matematický model nějakého jevu a podobně. Dále se podíváme na možnosti modelování byznys systémů. |
| Obecná charakteristika modelu | • Model je formulován jako systém, tedy souhrn prvků a jejich vazeb. Konkrétní povaha prvků i vazeb je dána použitým hlediskem (data/operace) • Zvláštní význam v modelu zaujímají jeho hraniční prvky, tedy prvky, které mají vazby s okolím systému (modelu). Těmito prvky je definována hranice systému, tedy jeho kontext. • Obsah modelu (souhrn jeho prvků a vazeb) je vždy objektivní, tedy každý prvek modelu musí odpovídat některému objektu reálného světa. • Vnitřní struktura systému (uspořádání prvků) je vždy poplatná struktuře světa. Modelování – princip tří „architektur“ |
| Modelování slouží pro možnost: | • prozkoumat možnosti změn bez vlivu na reálné činnosti • vystopovat příležitosti vylepšení • odhadnout a měřit účinky zamýšlených změn • demonstrovat a sledovat průběh analýzy • předávat nápady efektivně a jednoznačně mezi členy projektového týmu |
| Využití | • model aktuálního stavu X cílového stavu • analýza vlastností reality na základě modelu • řízení reality na základě modelu Není tedy často účelné vytvářet matematický model, ale obvykle se tvoří model pomocí diagramu nebo sady diagramů tvořených sjednanou notací. Modely se pak většinou snaží zahrnout celý systém z nějakého zvoleného hlediska (například procesní model, datový model, funkční model a další). |
| Jak vypadá? | Může vypadat např. jako diagram. Tvorba diagramů pro modelování systému bývá obvykle svázána sadou pravidel, tzv. notací. Pro zachycení okamžitého byznys nápadu podnikatele může být vhodné použít obrázek jako náčrt bez striktní notace, která by autora omezovala, takže má svobodu v komunikačním nástroji. Při preciznější analýze a návrhu s následnou automatizací je naopak nutné použít model s konkrétní striktní notací (v různých případech různou). |
| Jaké modely znáte? | • konceptuální • procesní • organizační |
| Kritické faktory úspěchu modelování | Jsou takové faktory, které mohou zapříčinit neúspěšnost modelování, patří mezi ně např.: • jednotliví řešitelé musí být dostatečně seznámeni s problematikou projektu – komunikace s klientem • musí dodržovat předem domluvenou jednotnou techniku modelování (notace UML, BPMN) • dobré rozvržení práce: např. přiřazení procesů jako je fakturace – specialistovi na finanční procesy (kryje se s klíčovými faktory úspěchu) • Je nutná kontrola konzistence – při použití více typů modelů – aby každý z nich nevypovídal něco jiného (více typů a pohledů pomáhá k většímu pochopení požadavků na IS/ICT, a proto při nekonzistenci modelů může dojít v budoucím vývoji k problémům) • snaha o zachycení všech aspektů, které jsou pro zkoumání systému podstatné a eliminace aspektů nepodstatných |
| Proces | = Pojmem proces rozumíme skupinu navazujících činností, které jako celek přinášejí hodnotu zákazníkovi (procesu). Další definicí může být: proces je sada logicky spojených úloh prováděných tak, aby přinášely definovaný výstup byznysu. |
| Procesní řízení | = sleduje na sebe navazující činnosti podle logiky jejich návazností a podle hodnoty, kterou společně vytvářejí pro zákazníka, a to za podpory informačních technologií. Tyto skupiny činností procházející přes různé funkční oblasti podniku se nazývají procesy. |
| Principy procesního řízení | Procesní řízení podniku je v současné době převládajícím stylem podnikového řízení. Proto je mu věnován další výklad. Aby analytik mohl byznys analýzu dobře provést, musí vědět, jaké jsou principy procesního řízení, jaká jsou klíčová rozhodnutí při tomto stylu řízení a v jakém pořadí se obvykle provádějí. |
| Základní fáze řízení | • Strategické cíle... čeho cheme dosáhnout v dlouhodobém horizontu • Byznys model/produtky/služby... čím toho dosáhneme • Procesy... jak produkt/službu vytvoříme • Zdroje... jaké zdroje procesy potřebují •Kooperace/outsourcing... které procesy a které zdroje nakoupíme od partnerů • IS/ICT... jak procesy a komunikaci s partnery podpoříme pomocí IS/ICT • Organizace/zodpovědnosti... jaká je nejvhodnější organizace pro naše aktivity |
| Dokumentace procesů | Po prozkoumání jednotlivých procesů je možné modelovat procesní architekturu systému pomocí diagramů nazývaných diagram návaznosti procesů, procesní dům nebo procesní mapa. V těchto diagramech jsou zobrazeny všechny procesy probíhající v systému a jsou nějakým způsobem logicky seskupeny. Často takový diagram vypadá jako dům, proto se mu říká procesní dům (process house). |
| Metoda KBPR (Knowledge Based Process Reengineering) | Východiskem metody je kritika "mechanických" přístupů k mapování a reengineeringu podnikových procesů, které jsou příliš technicky zaměřené, málo respektují znalosti lidí podílejících se na procesech a nedostatečně zohledňují nutnou míru kreativity člověka v příslušném procesu. Metoda rozlišuje čtyři úrovně modelování a návrhu procesu. Úrovně se liší zejména v tom, jaká úroveň znalostí a zkušeností se předpokládá jednak na straně pracovníků navrhujících proces a jednak na straně pracovníků podílejících se na realizaci procesu. Je věcí tvůrců definice procesu, aby pro každý z procesů vybrali optimální úroveň. Jednotlivé úrovně popisu jsou charakterizovány následovně. |
| Metoda KBPR (Knowledge Based Process Reengineering) 1. Úroveň | • cíle procesu (například produkt/služba a jejich charakteristiky), • událost aktivující daný proces, • role, resp. funkční místo zodpovědné za celý proces (vlastník procesu), • zákazník procesu, • kvalitativní a kvantitativní metriky procesu, • omezující podmínky procesu (například finanční nebo časový limit pro průběh procesu). |
| Metoda KBPR (Knowledge Based Process Reengineering) 2. Úroveň | V druhé úrovni je navíc definován výstup procesu (například požadovaná struktura výsledného dokumentu, model výrobku, výkres produktu apod.). |
| Metoda KBPR (Knowledge Based Process Reengineering) 3. Úroveň | • seznam činností, které jsou součástí procesu (není však definována návaznost činnosti, • seznam rolí, resp. funkčních míst, podílejících se na realizaci procesu (role ale nejsou přiřazeny k činnostem), • seznam všech externích vstupů do procesu (ale vstupy nejsou přiřazeny k činnostem), • seznam vhodných informatických nástrojů pro podporu procesu. |
| Metoda KBPR (Knowledge Based Process Reengineering) 4. Úroveň | • vstupy a výstupy každé činnosti, • návod (algoritmus) každé činnosti, • návaznost činností, • přiřazení zodpovědných rolí k jednotlivým činnostem, • doba trvání každé činnosti, • náklady činností, resp. náklady celého procesu. |
| Metoda KBPR (Knowledge Based Process Reengineering) úrovně | První úroveň popisu procesu se využívá v případě, když akumulovaná firemní znalost je nedostatečná, resp. když každý průběh procesu je velmi odlišný vlivem měnících se podmínek a externích faktorů. Taková situace nastává zejména u procesů strategického řízení. První úroveň tak předpokládá vysoce kvalifikované a kreativní pracovníky, kteří při průběhu procesu budou schopni naplánovat a realizovat všechny dosud nedefinované charakteristiky procesu. Naopak čtvrtá úroveň popisu procesu předpokládá vysokou kvalifikaci a rozsáhlé zkušenosti pracovníků definujících proces. V praxi se často pro definici procesu na této úrovni využívají znalosti pracovníků konzultačních firem, kteří znají nejlepší praktiky používané v dané oblasti podnikání. Čtvrtá úroveň současně představuje nejvyšší stupeň standardizace průběhu procesu. |
| Cíle procesního modelování | • Simulace reálných procesů, které probíhají v organizaci • Zachytit chování reality podnikových procesů • Grafické znázornění procesů (diagramy procesů) |
| Principy | • Vhodné pojmenování • Dodržení grafické notace |
| ARIS (EPC diagram) | V diagramu jsou vertikálně shora dolů modelovány střídavě objekty znázorňující události a činnosti (objekt pro událost a stav procesu je totožný). Šipka mezi těmito objekty zobrazuje následnost (logickou nebo časovou) . Vedle činností se dále zobrazují jejich informační vstupy a výstupy (obvykle pomocí objektů dokument, cluster, dokumentovaná znalost apod.), a to vlevo shora vstupy (šipkou směrem k činnosti) a vlevo dolů výstupy (šipkou směrem od činnosti) . Vpravo vedle činnosti se zobrazují aktéři procesu pomocí procesních rolí, funkčních míst, organizačních jednotek či týmů , a dále například aplikace použité při výkonu činnosti. Vztah aktéra a činnosti může být různého typu (například provádí, spolupracuje apod.). Větvení a spojování větví procesů se modeluje pomoci logických operátorů |
| BPMN | Business Process Model and Notation- BPMN je otevřený standard, jehož aktuální verze je dostupná na stránkách http://www.bpmn.org. Standard BPMN je podporován většinou společností, které se zabývají tvorbou nástrojů pro podporu procesního modelování. BPMN je chápán jako komplexní přístup, který kombinuje služby, činnosti, data, procesy, choreografie a konverzace do souvisejícího systému, který umožňuje automatizaci. Proces se typicky zobrazuje (modeluje) zleva doprava, začíná startovací událostí, následuje sekvence činností a končí koncovým stavem. Notace pro modelování procesů rozlišuje množství typů událostí a interních stavů procesů zvaných triggery, a také typů šipek pro rozlišení normálního toku, podmíněného toku, toku zprávy apod. Celkově je modelování v BPMN primárně určeno pro zobrazení logiky toku procesu a pro sladění toku procesu mezi různými účastníky procesu. Proto se pro aktéry procesu používá přístup plaveckých drah, zde rozlišený na bazén (pool)- účastník procesu a dráha (lane) pro skupinu souvisejících činností. |
| Erikssonovo a Penkerovo rozšíření UML | Erikssonovo a Penkerovo rozšíření UML se pokouší vyřešit nevhodnost standardu UML pro procesní modelování. Diagram aktivit se hodí pro základní modelování návaznosti činností čili workflow, neumožňuje však vhodně modelovat některé byznys aspekty procesů , například kvantitativní cíle procesu. Eriksson a Penker navrhují modelovat proces jako celek a sledovat u něj vstupní a výstupní objekty, kontrolní a podpůrné zdroje a hlavně cíl procesu. Tento přístup pak lze kombinovat se standardním diagramem aktivit UML pro zobrazení toku činností v rámci procesu, případně pro předávání událostí mezi procesy. |
| Komponenty: | O Proces o Činnost o Podnět - Událost - Stav |
| Proces | „Účelně naplánovaná a realizovaná posloupnost činností, ve kterých za pomoci odpovídajících zdrojů probíhá transformace vstupů na výstupy.“ „Soubor činností, který vyžaduje jeden nebo více vstupů a tvoří výstup, který má nějakou hodnotu pro zákazníka.“ - Je iniciován událostí. - Výstupem je událost signalizující dosažení jednoho z koncových stavů procesu. - Cílem procesu je „hodnota pro zákazníka“ |
| Činnost | Základní prvek procesu, zpracování vstupu na výstupy. Činnost může být komplexní nebo primitivní (elementární) prováděna - pouze člověkem („zkoušení studenta“) - strojem („vylisování nárazníku auta“) - člověkem za podpory stroje („přišití knoflíku“) - člověkem za podpory ASW („zaevidování známky ze zkoušky“) - ASW („hlídání poklesu zásoby pod limit“) |
| Událost | Externí podnět procesu/činnosti. Reprezentuje požadavek libovolného zákazníka/aktéra procesu. Například: příchod objednávky zákazníka |
| Stav | Výsledek činnosti v systému. Například: faktura zkontrolována |
| Cíl | • zachytit strukturu reality • používá se k tomu jazyka UML (obecný a univerzální objektově orientovaný modelovací jazyk, • sloučení několika populárních OO přístupů), složitost je redukována rozdělením do subsystémů a • delegováním „odpovědnosti“ na jednotlivé objekty. |
| Principy | Rozložení reality na jednotlivé prvky (objekty), které spolu interagují, každý objekt (věc, prvek, jev, pojem v reálném světě) je něčím jedinečný. |
| Standardy | Diagram tříd - použití: • Prozkoumání problémové domény (typy objektů reality) • Analýza požadavků IS => ASW (konceptuální => logický model) • Zachycení detailního návrhu objektově orientovaného SW |
| Komponenty | Objekt = prvek, jev, věc, pojem v reálném světě • třída = Kategorie, skupina věcí se stejnými vlastnostmi a stejným chováním (nebo podobným), tj. ve smyslu množina objektů stejného typu • atribut = podstatná charakteristika/vlastnost třídy/asociace • asociace = vztah mezi dvěma objekty • operace = metoda, funkce, kterou může objekt vykonávat |
| Cíl | Zobrazuje funkce jako transformace vstupních datových toků na výstupní, zároveň umožňuje znázornit kontext systému (vstupy z okolí a výstupy do okolí) a uchovávaná data |
| Princip | Zobrazuje funkce, jako transformace vstupních datových toků na výstupní, znázorňuje se diagramem datových toků (DFD, ten je spojován se strukturovanými metodami) |
| Standardy | K zachycení datového modelu na konceptuální úrovni se používá řada různých modelovacích nástrojů. Mezi nejznámější patří různé modifikace tzv. ER(A) diagramů. |
| Modely | Při tvorbě datových modelů se dají rozlišovat (podobně jako u modelu tříd) následující úrovně popisu datových struktur: • Konceptuální model = popis obsahu dat systému na úrovni, která je nezávislá na vlastním implementačním a technologickém prostředí. • Technologický (logický) model = popis způsobu realizace dat systému v termínech jisté kategorie technologického prostředí (lineární, relační, hierarchické nebo síťové logické datové struktury). Například pro relační databázový model jsou na této úrovni do relačních tabulek doplňovány cizí klíče realizující vazby mezi entitami z konceptuálního modelu. • Implementační (fyzický) model= popis vlastní realizace databáze v konkrétním implementačním prostředí, například doplnění údajů o typech indexů, velikostech a rozmístění pracovních prostorů v konkrétním databázovém systému a využitím jeho jazyka (specificky například pro relační databázové systémy MS SQL s jazykem T-SQL, Oracle a jeho PUSQL, nebo pro objektové prostředí Cashé apod.). |
| Komponenty | • symboly • terminátor (v obdélníkovém rámečku), • datový tok (musí mít směr), • funkce (v kolečku), • data store (ohraničené čárami), |
| Funkce IS | = prvek chování informačního systému, resp. aplikace. » Příklady: založení nového zákazníka, vystavení objednávky, vložení obrázku do textu. |
| Funkcionalita IS | = souhrn funkcí IS » je-li funkce zpracovávána transakčním zpracováním nazývá se transakcí |
| Hierarchie funkcí IS | » Statický pohled - popisuje hierarchický rozpad funkcí informačního systému » Nejnižší úroveň funkční hierarchie, která je ještě viditelná uživatelům, popisuje elementární funkce, které mají uživatelé informačního systému k dispozici » Funkce vyšší úrovně jsou vždy pojmenováním určité množiny logicky souvisejících funkcí bezprostředně podřízené úrovně každá funkce musí mít stručný popis, popis funkce na nejnižší úrovni hierarchie musí výstižně definovat „co má systém zajistit“ (jaké jsou na něj kladeny požadavky). IS/ICT > Funkční oblas řízení (logictika, finance, výroba,...) > Funkční modul (prodej, nákup, hlavní kniha,...) > Skupina funkcí (dle typu - transakční, analytické,...) > Funkce (zpracování, faktury,...) > Další dílčí funkce (pouze v případě potřeby) |
| Principy | Při funkčním pohledu členíme podnik jako celek na několik dílčích funkčních oblastí. Každou takovou jednotlivou funkční oblast opět můžeme rozčlenit na dílčí funkční oblasti a tak dále, až k jednotlivým dílčím funkcím, resp. činnostem. |
| Funkční model Cíl | Funkční model popisuje, z jakých funkcí, jejich vstupů a výstupů se realita skládá a potažmo i jaké funkce budou tvořit informační systém, má-li být věrným modelem této reality. |
| DFD - Data Flow Diagram | (diagram datových toků) slouží jako grafický prostředek návrhu a zobrazení funkčního modelu systému- je základním nástrojem pro vyjádření konceptuálního funkčního modelu ve strukturovaných metodách. |
| Komponenty | V DFD se používají základní prvky: • Funkce (v DFD označované ne úplně správně jako "proces"56, proto je v níže uvedeném obrázku nahrazen oproti původnímu zdroji správnějším označením "funkce", tedy "co systém dělá", jaké vstupy transformuje na výstupy, bez ohledu na pořadí; v dalším textu věnovaném DFM jsou však pojmy "funkce" a "proces" používány jako synonyma, nejedná se však o byznys proces, ale o pouze o transformaci dat). • Datový tok (Data Flow). • Datové úložiště (Data Store). • Terminátor (Terminator, externí entita). |
| Cíl | Diagram případů užití (Use Case Diagram) umožňuje popsat chování systému z hlediska uživatele. |
| Standardy | Use Case Diagram (diagram případů užití) |
| Principy | V diagramu případů užití se specifikuje, jaké typy uživatelů (lidé i jiné systémy) používají systém a jaké činnosti vykonávají. |
| Model | Model případů užití se skládá z diagramů případů užití a specifikací (slovních popisů) jednotlivých případů užití. Případy užití představují funkční požadavky na vyvíjený systém. |
| Komponenty | Prvky diagramu případů užití jsou aktér (Actor), případ užití (Use case) a vztah (Relation). Aktér (Actor) reprezentuje prvek okolí systému, který komunikuje se systémem. Aktérem nemusí být pouze role reprezentovaná živou osobou, ale také externí systém, se kterým modelovaný systém komunikuje. Aktér se v UML označuje symbolem panáčka a názvem (obrázek 12.1 ). Aktérem může být například Správce objednávek, Student, Učitel či Bankovní systém. Aktér reprezentuje roli, kterou hraje člověk, hardwarové zařízení nebo externí systém ve vztahu k modelovanému systému. Jeden člověk může plnit více rolí a jednu roli může vykonávat více lidí. Název aktéra by měl tuto roli vyjadřovat. Pro název aktéra by se mělo používat podstatné jméno v jednotném čísle , pro vyjádření aktéra, který je systémem, je vhodné použít stereotyp «system». |
| MMDIS | = Multidimensional Management and Development of Information System |
| Charakteristika | • Metodika je vyvíjena na katedře informačních technologií VŠE od počátku 90. let. Metodika si klade za cíl přispívat k výchově ICT specialistů, kteří zvýší úspěšnost ICT projektů (čili je určená pro učební účely). Zahrnuje rigorózní i agilní přístupy a tím pomáhá budoucímu vývojáři osahat si jednotlivé metody a techniky. Metodika je otevřená, metody i koncepty se vyvíjejí spolu s vývojem hospodářského prostředí, informačních technologií a metod řízení. |
| Cíl | • Cílem MMDIS je vývoj, údržba a provoz komplexního a integrovaného informačního systému podniku, který optimálně využívá potenciálu dostupných informačních technologií a informatických služeb k maximální podpoře podnikových cílů. = zajištění efektivní podpory podnikových cílů a podnikových procesů pomocí integrovaných informatických služeb, procesů a zdrojů a zdrojů. • Komplexní IS je takový, který podporuje všechny činnosti podniku, pro něž je možné nalézt efektivní informatickou podporu. • Integrovaný IS znamená, že informační systém je tvořen z celé řady hardwarových, softwarových a datových komponent, které jsou navzájem propojeny (integrovány) do jednoho systému. |
| Struktura MMDIS | Metodika se skládá z jedenácti základních principů řízení a pěti navzájem propojených konceptuálních modelů řízení podnikové informatiky |
| Princip | Myšlenkový přístup k chápání a analýze problému a s ním spojené zásady (pravidla) řešení problému. Principy MMDIS jsou aplikovány v konceptech MMDIS. Principy jsou základem pro metody, techniky a nástroje řízení. |
| 11 základních principů metodiky MMDIS | 1. multidimenzionalita 2. vrstvenost 3. integrace 4. flexibilita 5. otevřenost 6. standardizace 7. kooperace 8. procesní pojetí 9. učení a růstu (postupné zlepšování procesů) 10. lokalizace zdrojů a rozhodnutí 11. měřitelnost (metriky) |
| Konceptuální model (koncept) | = model řízení daného systému (firmy, IS,…) Nástroj podporující efektivní řízení podnikové informatiky. Objasňuje jak chápat řízený systém. Souvisejí s ním metody, které jsou doporučením, jak daný systém řídit. Každý z modelů akcentuje jiné dimenze problematiky řízení. |
| 5 základních konceptuálních modelů metodiky MMDIS | 1. model procesně řízené organizace 2. integrace strategie, procesů, služeb a zdrojů (model SPSR) 3. integrace oblastí řízení (model systémové integrace) 4. model tvorby a dalšího rozvoje IS 5. systém řízení IS (model řízení informatických procesů ve firmě) |
| Princip | Každý složitý problém je nutné analyzovat, hodnotit a jeho řešení navrhovat a řídit z mnoha různých dimenzí (pohledů). Pohledy jsou určeny stranami zainteresovanými na systému. Separátní řešení dle jednotlivých pohledů je pak nutné integrovat do jednoho výsledného řešení. |
| Pravidla multidimenzionality: | 1) Identifikuj všechny pohledy/dimenze významně ovlivňující řešení problému a s nimi související klíčové požadavky a priority. 2) Analyzuj problém nejdříve z každého pohledu/dimenze samostatně. 3) Ve finálním řešení integruj jednotlivé pohledy a uvažuj přitom stanovené požadavky a priority. |
| Cíl | • Cílem multidimenzionality při řešení IS/ICT je neopomenout žádný faktor, který ovlivňuje úspěšnost tvorby, zavedení, provozování a dalšího rozvoje IS/ICT, a neopomenout ani vzájemné ovlivňování, resp. vzájemné vazby těchto faktorů. • Příklad: Jestliže jsme například vytvořili technologicky dokonalý IS, ale funkcionalita jeho aplikací není v souladu s platnou legislativou, je IS hrozbou pro podnik. Jestliže IS respektuje platnou legislativu, ale jeho uživatelé nebyli dobře vyškoleni, užití i jinak dokonalého IS nemůže přinášet plánované efekty. |
| 3 skupiny pohledů (dimenzí) | Pro řešení informačního systému MMDIS doporučuje použít pohledy zařazené do 3 skupin: 1. uživatelský a řešitelský pohled 2. úroveň abstrakce a časová dimenze 3. obsahové dimenze IS/ICT Nesmí být opomenuta ani jedna z těchto dimenzí. Všechny mají stejnou váhu a jsou navzájem provázané. |
| Příklad ze stavebnictví: | Chceme-li vyřešit stavbu domu, je užitečné použít tyto samostatné pohledy řešení: - životního stylu - k čemu a jak chci dům užívat? - architektonický - jak bude vypadat a z čeho bude postaven? - dodavatelský - kdo ho postaví, za kolik a jak rychle? - finanční - jak dům zaplatíme? |
| Konceptuální modely | Konceptuální modely jsou metodickým nástrojem podporujícím efektivní řízení podnikové informatiky. Každý z modelů: • akcentuje jiné dimenze (pohledy) problematiky řízení, • objasňuje, jak chápat a řídit systém z daných pohledů, • slouží k analýze a návrhu modelovaného systému a k optimalizaci chování systému z daných pohledů, • používá specifické metody a nástroje řízení. = Předpokládáme, že v konečné fázi vývoje modelu budeme chtít se získanými daty určitým způsobem manipulovat – např. uchovávat je v databázi. = A právě k popisu procesu vývoje tohoto modelu nám může do určité míry pomoci tvz. princip tří architektur (P3A). V souvislosti s architekturou P3A se také často hovoří o třech úrovních návrhu informačního systému. |
| Architektura P3A | • definuje způsob použití abstrakce, což znamená, že nám umožňuje rozčlenit právě zkoumanou problematiku návrhu datové základny (DZ) na mentálně zvládnutelné části. Jak již název vypovídá, skládá se P3A ze třech vrstev (úrovní) - konceptuální, technologické (logické) a implementační (fyzické).Viz předmět 4IT218 (Databáze). |
| Konceptuální úroveň | • Na této úrovni se snažíme popsat předmětnou oblast (obsah) datové základny. V žádném případě nebereme v úvahu jakékoli pozdější způsoby implementace. Konceptuální návrh určuje co je obsahem systému. Viz příklad na obrázku, můžete ukázat např. notaci při tom používané |
| Technologická úroveň | • Na této úrovni se v relačních databázích používá tzv. relační schéma. Toto relační schéma obsahuje tabulky, a to včetně jejích sloupců (názvům sloupců odpovídají názvy atributů každé entity). Jsou zde vyznačeny primární a cizí klíče. Technologický model stále nesmí být zatížen implementačními specifiky řešení. Technologický návrh určuje, jak je obsah systémů v dané technologii realizován. |