Projektování informačních systémů

Transkript

1 Vyšší odborná škola informačních služeb, Praha 4, Pacovská 350/4 Projektování informačních systémů Sylaby ke kurzu Helena Kučerová 2007

2 Obsah 1. Úvod Systémová teorie a metodologie Systémová analýza a projektování informačních systémů Systémový přístup Modelování (modelová tvorba) Teoretické zázemí projektování informačních systémů Definice systému Atributy systému struktura, funkce Statické pojetí systému (struktura) Dynamické pojetí systému (funkce, chování) Systémová analýza a syntéza Informační systém Obecné metody systémové analýzy Grafy Statický popis systému strukturní diagram Funkční popis systému Vývojový diagram (flowchart) Byznys modelování (model podnikových procesů) Workflow (workflow management) Ganttovy diagramy, síťové grafy CPM/PERT Speciální metody systémové analýzy Základní prvky modelů informačních systémů Typy přístupů v návrhu (projektování) informačních systémů Strukturovaná metodologie Entitně relační model (ERA) Diagram datových toků (DFD) Objektová metodologie UML Unified Modeling Language Use Case diagram Diagram tříd Stavový diagram Diagram aktivit Řízení a plánování projektu informačního systému Projekt Životní cyklus projektu informačního systému Specifikace požadavků na informační systém Osnova dokumentace informačního systému CASE Lidský faktor v informačních systémech Profese řízení a navrhování informačních systémů Hygiena a bezpečnost práce, ergonomie Bezpečnost informačních systémů Anglicko český slovníček Terminologický slovníček Doporučená literatura

3 1. Úvod Definice moderní vědy: 1. Je-li to zelené nebo se to pohybuje, jde o biologii. 2. Smrdí-li to, jde o chemii. 3. Nefunguje-li to, jde o informatiku. Graf, Joachim: Murphyho počítačové zákony Tyto sylaby jsou zpracovány jako doprovodný výukový materiál pro moduly vyučované na Vyšší odborné škole informačních služeb: PRI/1 a PRI/2 Projektování informačních systémů 1 a 2 a VIS Vývoj informačních systémů pro zaměření Podnikové informační systémy, a PRI Projektování informačních systémů pro zaměření Služby knihoven. Moduly shrnují základní znalosti, metodiky a techniky nezbytné pro návrh a inovaci současných informačních systémů. Studenti získají v rámci výuky potřebné minimum vědomostí z oboru systémová analýza, seznámí se s základními pojmy systémové teorie a metodologie a naučí se používat metodu systémového přístupu k řešení problémů. Seznámí se s metodami používanými při analýze a projektování informačních systémů, přičemž v modulech PRI a PRI/1 je pozornost věnována zejména metodám procesní a datové analýzy a v modulech PRI/2 a VIS převažuje zaměření na objektově orientovanou metodiku analýzy a projektování. V praktických cvičeních si studenti osvojí pravidla tvorby strukturních diagramů a organizačních schémat, vývojových diagramů, workflow modelů, síťových grafů a speciálních nástrojů modelování informačních systémů datových modelů (ERA) a diagramů datových toků (DFD). V modulech PRI/2 a VIS se seznámí s tvorbou modelů podle standardu UML (Unified Modeling Language) a zvládnou práci se specializovaným softwarem pro navrhování informačních systémů (CASE). Získají schopnosti a dovednosti potřebné pro specifikaci požadavků na nový informační systém, případně na novelizaci stávajícího informačního systému, pro hodnocení jeho efektivnosti a dále pro výběr softwaru pro konkrétní firmu, knihovnu nebo informační prostředí. Poznají důležitost dokumentace informačního systému a rozvinou schopnosti potřebné pro tvorbu kvalitní dokumentace. Výuka probíhá formou výkladu, na nějž vždy navazuje praktické ověřování prezentovaných poznatků formou řešení případových studií a problémových cvičení v menších pracovních skupinách. Studenti předkládají ke zkoušce samostatně zpracovaný projekt informačního systému na úrovni analytické a návrhové s písemnou dokumentací. 2

4 2. Systémová teorie a metodologie 2.1 Systémová analýza a projektování informačních systémů podstata: řešení problémů 1 problém: odchylka od žádoucího stavu, vyžadující řešení, které hledáme používané metody: systémový přístup modelování inženýrství projektování omezení: nejedná se o metody univerzálně použitelné při řešení jakýchkoli problémů, jsou však účinné v případě návrhu informačních systémů Systémový přístup Obecná metoda vědeckého myšlení, jejíž podstatou je analýza fungování složitých celků v důsledku jejich struktury. klasický newtonský (mechanistický) přístup poznávání celku jeho rozdělením na části a studiem jejich vlastností vztahy mezi částmi se neuvažují mechanistický přístup je konkrétní zajímají nás fyzické komponenty (prvky) systémový přístup poznávání celku prostřednictvím vztahů mezi jeho částmi celek může mít vlastnosti nevyplývající přímo z vlastností jeho částí systémový přístup je abstraktní zajímají nás logické komponenty (prvky) postup: 1. vymezení hlediska zkoumání, stanovení cíle odlišení daného systému od jiných systémů, jež lze na objektu definovat 2. vymezení hranic systému, zahrnutí prvků a procesů odlišení daného systému od okolí určení hranice systému rozhodnutí, které entity zahrnout (či nezahrnout) do systému seznam prvků a procesů systému 3. proces strukturování rozhodnutí, jak uspořádat vlastnosti množiny zvolených entit (prvků systému) definování vztahů prvků a procesů rozlišení podstatných a nepodstatných prvků a vztahů 1 Poznámka: zpravidla se jedná pouze o takové problémy, které lze řešit informačními systémy (a za použití počítačů, resp. informačních a komunikačních technologií) 3

5 Základní kroky při využití systémového přístupu k řešení problémů: 1. rozložte původní problém na sadu menších problémů; pokračujte v procesu dekompozice, až bude každý podproblém dostatečně malý, aby se dal vyřešit 2. zformulujte řešení pro každý jednotlivý podproblém 3. spojte sadu řešení podproblémů v jeden celek 4. aplikujte kompletní řešení na původní problém 5. prověřte, zda řešení je správné (testování navržené struktury a funkce) Řešení problémů prostřednictvím informačních systémů: 1. analýza problému (systémová analýza systems analysis) jaký je problém? jaké je nejlepší řešení problému? výsledek: návrh řešení, jeho časového horizontu, požadavky na finance 2. návrh řešení problému (projekt systému systems design) jak transformovat zvolené řešení do navrhovaného informačního systému? výsledek: volba hardwaru, návrh způsobu reprezentace dat v počítači, volba (nebo vlastní návrh) softwaru, řešení komunikace uživatele se systémem (uživatelské rozhraní) Modelování (modelová tvorba) Vychází z obecných zákonitostí teorie podobnosti, zejména z principu analogie. model obor studující otázky racionální konstrukce modelů, jež odrážejí vlastnosti, vztahy a chování reality nástroj umožňující místo teoretického zkoumání použít empirické metody (např. experiment) tím, že empirické výsledky se přenesou z modelu na zkoumaný objekt nebo navrhovaný artefakt zjednodušené nebo zobecněné zobrazení systému, zavedeného na objektu, které se s tímto objektem shoduje v podstatných vlastnostech analogicky (schéma, struktura, znakový systém) určené části přírodní nebo sociální reality jakožto originálu; tento model (analog) slouží k hlubšímu poznání originálu, jeho konstrukce a organizace, ale i přeměn a jejich podmínek 4

6 Vztah subjekt model originál působení model subjekt analogie využití (funkce) modelu: nahrazuje subjektu pochopení originálu nebo manipulaci s originálem a) poznávací studium struktury původního objektu (např. prostřednictvím verbálního popisu jinak nedostupného objektu) vzor / plán / návrh (budoucího objektu nebo procesu) b) manipulační, ověřovací myšlenkové nebo materiální experimenty simulace ověření vlastností skutečných objektů (např. stability konstrukce) c) komunikační, dokumentační působení originál (objekt) Základní typy modelů a) statický dynamický statický model: zobrazuje zpravidla strukturu (vnitřní uspořádání) jevů a procesů dynamický model: zobrazuje převážně chování, funkci systémů b) konkrétní abstraktní konkrétní model (též názorný model, maketa, prototyp, faksimile): obrazy, reálné modely, prostorové (3D) modely, animace, video (4D je zahrnut i čas) abstraktní model: např. matematický vzorec c) individuálně vytvářený standardizovaný individuálně vytvářený model: umožňuje vystihnout specifika originálu standardizovaný model: je všeobecně srozumitelný d) konceptuální (pojmový, esenciální) technologický konceptuální model: implementačně nezávislý technologický model: návrh systému pro konkrétní implementační prostředí (software, hardware) e) AS-IS TO-BE AS-IS: model současného stavu TO-BE: model cílového stavu (plán, projekt,) 5

7 f) podle formy vyjádření 1. textový (verbální, slovní) hledaná informace se získá pochopením (interpretací) textu používá prostředky přirozeného jazyka může vyjádřit i to, co je slyšet (písmo je modelem řeči, noty jsou modelem hudby) může vyjádřit i abstrakci nebo ideje (myšlenky) je lineární (nestrukturovaný) strukturu popisovaného problému musíme vytvořit ve své mysli 2. matematický (vzorec) hledaná informace se získá výpočtem 3. číselný efektivní vyjádření kvantity (množství) 4. obrazový (názorný, 2D, 3D, 4D) hledaná informace se získá sledováním modelu efektivní vyjádření tvarů a barev jasné znázornění akce nebo scény může ukázat i to, co není vidět (např. mapy) může eliminovat nepodstatné jevy grafická schémata jsou strukturovaná přímo znázorňují strukturu popisovaného problému Požadavky na model úplnost přesnost minimální redundance jednoduchost, čitelnost (7±2) konzistence hierarchie úrovní poměr grafika (většina) text (menšina) 6

8 Systémová metodologie a typy vytvářených modelů technika: popis operací při řešení problému je spíše konkrétní (co dělat, jak to udělat pomůcka, nástroj)) metoda: zaznamenaná zkušenost, oddělená od původního nositele je k dispozici pro opakované použití (reuse) k realizaci metody nepotřebujeme jejího autora možnosti, jak úspěšně realizovat činnost: 1) pozveme si odborníka, který to umí udělat 2) děláme to tak, jako tento odborník (= metoda) metodika: postup, jak zvolit operace vhodné k řešení problému je spíše abstraktní (proč to dělat právě tak, jak to dělat návod) 1. obecné metody 2. speciální metody zajímají nás objekty lze užít pro znázornění libovolné reality zobrazujeme všechny zpozorované objekty a procesy zajímají nás data užíváme výhradně pro navrhování informačních systémů soustředíme se pouze na to, co bude zpracováno v počítači objekty a procesy mimo dosah informačních a komunikačních technologií nepopisujeme 7

9 metody modely 8

10 2.2 Teoretické zázemí projektování informačních systémů Projektování informačních systémů není věda, ale oblast praktické lidské činnosti, která čerpá nezbytné teoretické základy z četných teoretických a aplikovaných vědních disciplín (matematika, logika, systémová věda, kybernetika, teorie řízení, počítačová věda ad.) Cílem projektování pak není další rozvoj příslušných teoretických oborů, ale využití jejich poznatků při řešení reálných problémů. Teorie systémů též systémová teorie (systems theory), obecná teorie systémů (general systems theory), systémová věda (systems science): vědní disciplína v logicko matematické oblasti, která se zabývá formulací a dedukcí obecných systémových zákonů, aplikovatelných na všechny systémy určitého typu bez ohledu na povahu jejich prvků a vztahů obecný teoretický přístup k postižení nejobecnějších rysů a zákonitostí různých typů systémů na základě jejich izomorfie (homomorfie) metodologie teorie systémů představuje spojovací můstek mezi filozofickou metodologií a specifickými metodami jednotlivých věd předmět zkoumání: systém metoda zkoumání: systémový přístup, systémová analýza a syntéza aplikační oblasti: všechny oblasti, v nichž probíhá příprava a zhodnocování rozhodnutí a řešení složitých problémů (kybernetika, operační výzkum, inženýrské disciplíny) Zakladatelé systémových věd Ludwig von Bertalanffy ( ) Teoretický biolog rakouského původu, od 1940 v Kanadě a USA. Jeho práce má filozofický a metodologický dosah, zvláště řešení vztahu celku a částí. Svou původní teorii otevřených systémů, popisující procesy systémů biologického charakteru (vyměňujících s okolím energii i látky) po 2. světové válce rozšířil jako obecnou teorii systému, blízkou kybernetice, které připisoval význam filozofie soudobé vědy. Protože základním znakem živých věcí je jejich organizace, nemůže obvyklé zkoumání jednotlivých částí a procesů poskytnout úplné vysvětlení životních projevů. Toto zkoumání nám nedává žádné informace o koordinaci částí a procesů. Takže hlavním úkolem biologie musí být objevení zákonů biologických systémů (na všech úrovních organizace). Věříme, že pokusy nalézt základ pro teoretickou biologii ukazují na fundamentální změnu v obraze světa. Tento pohled, chápaný jako metoda zkoumání, nazveme biologií organismů, jako pokus o vysvětlení jej nazveme systémovou teorií organismu." (1928) William Ross Ashby ( ) Britský neurolog a kybernetik, ředitel výzkumu na Burdenově neurologickém institutu v Gloucesteru. Zastánce výkladu biologických a psychických procesů kybernetickými modely a metodami. Norbert Wiener ( ) Americký matematik, zakladatel kybernetiky. Zabýval se matematickou analýzou, teorií pravděpodobnosti, matematickou statistikou a výpočetní technikou. Je spoluautorem teorie podobnosti činnosti nervové soustavy a počítače, základu neurokybernetiky. 9

11 Inženýrství (engineering) systematická aplikace vědeckých znalostí při návrhu a tvorbě cenově efektivních řešení praktických problémů vychází z předem určeného cíle, existujících omezení a požadované spolehlivosti uplatňuje se při tvorbě rozsáhlých, složitých a technologicky náročných artefaktů (= objektů vytvořených člověkem) řešení respektuje existující standardy a je dokumentováno inženýrská pravidla hry od konkrétních k obecným podnikové předpisy, best practices (příklady nejlepší praxe) standardy principy a metody dané inženýrské disciplíny obecné inženýrské principy a metody Inženýrské disciplíny uplatňující se při projektování a provozování informačních systémů a oblasti jejich působnosti: analýza, návrh, realizace a provoz: systémové inženýrství (systémová analýza) průmyslové inženýrství operační výzkum (manažerská věda) projektový management informační inženýrství softwarové inženýrství business (organizační) inženýrství webové inženýrství znalostní inženýrství systémů výroby rozhodnutí projektů informačních systémů softwaru organizačních a řídicích struktur webových aplikací expertních systémů Softwarové / informační inženýrství hlavní okruhy činností: 1. analýza problémů byznys (podnikových) procesů informačních potřeb a uživatelských požadavků 2. návrh (softwaru / IS) programování tvorba uživatelského rozhraní tvorba dokumentace testování 3. implementace a integrace (softwaru / IS) 4. provoz, zajištění jakosti, údržba (softwaru / IS) 10

12 2.3 Definice systému Brian Gaines: Systém je to, co považujeme za systém systém: z řečtiny συστ στηµα [sýstéma] složené, seskupené v celek; spojení, skupina, oddělení, složenina; soustava, skladba, celek, systém, státní zřízení uspořádaná rozmanitost nějakých objektů (materiálních nebo ideálních) množina prvků a vazeb mezi nimi s dynamickým, účelovým chováním, jež může být považována za jeden celek jakmile na objektu dokážeme definovat jeho prvky (části) a jejich vztahy, které tvoří celistvost objektu, tedy strukturu a fungování objektu, pak jsme do tohoto objektu zavedli systém 2.4 Atributy systému struktura, funkce systém = jednota struktury a funkce (statického a dynamického pojetí), celku a části Typologie systémů podle vlastností prvků, z nichž jsou složeny podle toho, jakého typu jsou vztahy mezi prvky podle chování A. přirozené umělé rozlišující kritérium: způsob vzniku objektu (s přispěním / bez přispění člověka) B. statické dynamické rozlišující kritérium: stabilita stavu systému v čase C. abstraktní konkrétní rozlišující kritérium: prvky (vlastnosti) a jejich vztah k realitě (pojmy / fyzikální objekty) D. uzavřené otevřené rozlišující kritérium: vstupy výstupy (vztah k okolí) E. jednoduché složité rozlišující kritérium: prvky a vazby (počet) F. deterministické indeterministické (pravděpodobnostní, stochastické) rozlišující kritérium: chování, resp. možnost jeho předvídání G. vertikální horizontální rozlišující kritérium: vazby (existence / neexistence podřízenosti) H. homogenní heterogenní rozlišující kritérium: podobnost atributů (vlastností) prvků I. tvrdé měkké rozlišující kritérium: míra určitosti při definování systému 11

13 2.4.1 Statické pojetí systému (struktura) prvky vlastnosti (atributy) prvků uspořádání prvků (vazby, vztahy) subsystém okolí hranice Statický pohled na systém jej chápe jako celek složený ze dvou tříd: z třídy prvků a z třídy vztahů (relací, vazeb) mezi prvky. Těmto relacím říkáme struktury. V systému jsou prvky spojeny strukturami v celek, v jednotu. struktura: množina vzájemných vztahů, jimiž jsou spjaty prvky uvnitř systému (uspořádané zpravidla podle jednotícího principu) a které umožňují předvídat chování systému skladba či uspořádání prvků a vazeb prvek systému: dále nedělitelná část celku (na dané rozlišovací úrovni tvoří dále nedělitelný celek, jehož strukturu nechceme nebo nemůžeme rozlišit) část systému, v níž probíhá transformační proces atribut (vlastnost, charakteristika) prvku: určuje prvek po kvalitativní nebo kvantitativní stránce typy prvků podle umístění v systému: vnitřní (má vazby jen s prvky stejného systému) hraniční vstupní, výstupní (má alespoň jednu vazbu s prvkem, který není prvkem systému) externí vnější (má alespoň jednu vazbu s prvkem, který je prvkem systému): vstupy a výstupy tranzitivní prvek (transient element): prochází systémem, určitou dobu je jeho součástí (externí vnitřní externí) subsystém: systém, který je částí (prvkem) jiného systému vztah (relationship): spojení mezi prvky nebo jejich množinami okolí systému (prostředí environment): soubor prvků, které nejsou částmi systému, ale jejichž změna může způsobit změnu stavu systému, a těch prvků, jejichž vlastnosti se mohou měnit chováním systému hranice rozhraní systému (boundary interface): množina hraničních prvků systému rozhraní systému, kudy vstupují prvky z okolí a vystupují výstupy ze systému rozhraní = vazba mezi systémy 12

14 2.4.2 Dynamické pojetí systému (funkce, chování) vstupy výstupy proces (zpracování transformace, řízení) chování cíl Dynamický pohled na systém jej chápe jako zpracovatelskou jednotku se vstupy, výstupy, řízením a zpětnou vazbou, vyznačující se cílovým chováním. chování systému: způsob realizace cílů a obecná charakteristika reakce systému na podněty z okolí cíl: budoucí stav, uspořádání nebo chování, ke kterému systém směřuje nebo které jsou systému vytyčeny. Formulaci cíle ovlivňují neuspokojené potřeby všeho druhu. Základní procesy (operace, funkce) probíhající v rámci systému: VSTUP (input) ZPRACOVÁNÍ VÝSTUP (output) ŘÍZENÍ zpětná vazba proces (process): základní dynamická jednotka systému, vymezená svým počátkem a koncem transformuje vstup na výstup nebo upravuje chování systému vstup (input): to, co vstupuje do systému (externí prvky vstupující do systému) výstup (output): to, co vystupuje ze systému (externí prvky vystupující ze systému) výsledek procesu nebo konečný stav systému vazba (relationship), tok (flow): určuje posloupnost procesů, tj. určuje, že výstup některého procesu je současně vstupem jiného určitého procesu) 13

15 typy procesů: 1. základní proces (zpracovatelský proces) transformuje vstup na výstup transformace: pravidlo (předpis), podle něhož se mění vstupy systému na jeho výstupy změna stavu nějakého objektu do jiného, zřetelně odlišeného stavu, např. přetvořením, přidáním nebo odstraněním určitých prvků 2. řídící proces upravuje chování systému řízení (management): vymezování funkce (cíle) systému a působení na systém za účelem dosažení jeho žádoucí funkce, jeho přibližování k vymezenému cíli. Zahrnuje sledování, vyhodnocování zpětné vazby, ovládání a regulaci struktury i chování systému. typy řídících procesů: sledování (monitorování) spojité či nepřetržité získávání relevantních informací o stavu a chování systému ( rozhodnutí, zda systém směřuje k dosažení svého cíle regulační proces pak vykoná případné úpravy vstupů a zpracovatelských procesů) ovládání, regulace (control) působení na systém, jehož smyslem je udržovat systém nebo jeho výstupy v předem stanovených mezích omezení (constraints) proces diktovaný nějakými vnějšími faktory, které nemůžeme ovlivnit (např.legislativa, velikost území, finanční zdroje) cílové chování 2 množina transformací (jednorázových nebo postupných) stavů vedoucích z libovolného daného přípustného výchozího stavu systému do stavu definovaného jako cílový stav (cíl) cílevědomé chování: speciální forma cílového chování, typická pro člověka a společenské skupiny, kdy cíl je vědomě určován a systém se ho snaží dosáhnout a udržet 2 Poznámka: Efekt cílového chování je stejný jako při ovládání a omezení přizpůsobení výsledků systému. Zatímco při ovládání a omezení je dosahováno žádoucího efektu vnějšími vlivy, při cílovém chování se využívají vnitřní vlivy. 14

16 Zpětná vazba Norbert Wiener: Princip zpětné vazby ve své nejjednodušší formě znamená, že chování je testováno prostřednictvím odkazu na jeho výsledek (zprávy o něm) a úspěch nebo neúspěch tohoto výsledku ovlivňuje budoucí chování. (1958) informace o výkonu (výstupu, chování) systému vazba mezi výstupem a vstupem prvku, subsystému nebo systému, která způsobuje to, že vstup je závislý na výstupu užití části výstupu ze systému jako vstupu do systému K zajištění řádného fungování systému je nezbytná nějaká forma řízení (regulace). Podmínkou řízení je fungování zpětné vazby, která poskytuje odpověď na otázku: Je stav a/nebo chování systému v souladu s jeho stanoveným cílem? a) pozitivní zpětná vazba data ze zpětné vazby usnadňují a urychlují transformaci ve stejném směru jako předchozí výstupy efekt je kumulativní exponenciální růst až exploze či exponenciální pokles až zánik b) negativní zpětná vazba data ze zpětné vazby přinášejí výsledek v opačném směru k předchozím výsledkům efekt stabilizuje systém zajištění rovnováhy nebo rovnovážného pohybu, příp. dynamiky v souladu s cíli systému Systémová analýza a syntéza analýza redukcionismus izolování a zjednodušení systému, takže mohou být analyzovány a zlepšeny jeho různé prvky z dané struktury určujeme chování (funkci) syntéza popis vztahů popis vzájemného působení jednotlivých prvků systému z požadované funkce (chování) odvozujeme strukturu analýza a syntéza myšlenkové nebo faktické rozkládání celku na součásti a opětné spojování částí v celek Zásady správné analýzy zachycení celého rozsahu analyzovaného celku jasné ohraničení celku i jeho částí vzájemně se vylučující části nepřekrývající se části stejná úroveň granularity ( velikosti částí) 15

17 2.5 Informační systém systém umožňující komunikaci a transformaci informací časově, prostorově i co do formy tak, aby byly lépe využity než v původním stavu (systém, který přidává hodnotu k zpracovávaným či komunikovaným informacím) speciální typ komunikačního média, jehož cílem je odstranit bariéry v přístupu k informacím účelové uspořádání vztahů a informačních toků mezi informačními zdroji, lidmi a technologickými prostředky spolu s procesy zpracování a komunikace informací model reálného světa, jehož základními prvky jsou informace typické problémy řešené informačními systémy: potřeba informací (pro poznání, pro rozhodování, pro realizaci určité činnosti) složitost znovupoužitelnost automatizace komunikace bezpečnost, spolehlivost, minimalizace rizik Obecný model informačního systému 3 okolí efektor (výstupní prvek) receptor (vstupní prvek) procesor (zpracovatelský prvek) paměť Jednotlivé komponenty modelu umožňují realizovat základní cíle informačního systému: receptor: získávání informací paměť: ukládání informací (jejich fixace v prostoru a čase) procesor: transformace (zpracování) informací efektor: přenos informací, zpřístupnění informací Automatizovaný informační systém Informační systém fungující s podporou informačních a komunikačních technologií. Díky této podpoře mohou být procesy získávání, zpracování, ukládání a komunikace informací realizovány částečně nebo úplně bez přímé účasti člověka; obvykle jsou doprovázeny i digitalizací datové základny. Vzhledem k rychlému pronikání informačních a komunikačních technologií do informační praxe a s tím souvisejícím klesajícím podílem tradičních, manuálních informačních systémů toto označení a vyčleňování automatizovaných informačních systémů do zvláštní kategorie v současné době ztrácí na významu. cíl tvorby automatizovaného informačního systému: definování struktury digitálně uložených dat a vytvoření programu, který bude realizovat požadované činnosti 3 Zdroj: Encyclopaedia Britannica (heslo Information processing) 16

18 Prvky informačního systému subsystém 1 lidé tvůrci (autoři) informací uživatelé informací (klienti) zpracovatelé, správci, zprostředkovatelé informací subsystém 2 informace a) informace jako ekonomický zdroj 2 základní typy zdrojů každého ekonomického subjektu: a) fyzické pracovníci, materiál, stroje, zařízení, peníze b) nehmotné (ideální, abstraktní pojmy) data, informace Na rozdíl od ostatních ekonomických zdrojů má informace určitá specifika je expanzivní (rozpínavá), omezená pouze časem a kapacitou lidského poznání: její povahou je šíření spíše se reprodukuje než spotřebovává používáním může být pouze sdílena, nikoli směňována v transakcích je komprimovatelná syntakticky i sémanticky b) informace jako ekonomická komodita ( zboží ) subsystém 3 prostředky zaznamenávání, uchovávání, zabezpečení, třídění, vyhledávání a šíření informací jazyky informační a komunikační technologie (hardware počítače a periférie, síťové prvky, software) pracovní postupy a metody materiální zabezpečení (budovy...) vstupy (zdroje) data, informace požadavky, dotazy výstupy informační služby (informace, odpovědi na dotazy) informační produkty Funkce informačního systému = konkrétní procesy podporující základní cíle informačního systému procesy (činnosti, zpracování) získávání informací zpracování informací (evidence, organizace pořádání, kategorizace, konverze změna média, třídění, vyhledávání, agregace, odvozování nových informací) uložení informací (zaznamenávání, shromažďování na nosiči) přenos informací zpřístupnění informací (tisk, zobrazení, šíření ) 17

19 18

20 Současné typy (a terminologie) informačních systémů 1. Informační systémy organizací (informace jako ekonomický zdroj) informační systém jako jeden z pomocných subsystémů organizace (instituce, firmy), zaměřený na podporu její činnosti provozovatel: každá obchodní i neobchodní organizace 1.1 Informační systémy podporující řídící a administrativní funkce Slouží vnitřním funkcím organizace. Jejich struktura a funkce často úzce souvisí s používanými metodikami řídící (manažerské) práce, např.: MRP II Manufacturing Resources Planning II plánování výrobních zdrojů (implementace řídících plánů, které vyhodnocují a předpovídají potřebu pro každý prvek ve výrobním procesu v daném čase; základem jsou kusovníky a technologické postupy) ERP Enterprise Resources Planning metoda navazující na MRP II a rozšiřující ji na více podniků a plánování dalších zdrojů (zejména finančních) JIT Just in Time TQM Total Quality Management TOC Theory of Constraint Balanced Scorecards vyvážené ukazatele. Informační systémy orientované na řízení (management oriented) definování strategických cílů, plánování, příprava rozpočtů Informační systémy orientované na administrativu (administration oriented) správa a optimalizace firemních zdrojů zaměstnanců a jejich činností, inventářů materiálu, přístrojů a vybavení, prostor a financí. 1.2 Informační systémy podporující činnosti a služby organizace Podporují účel, kvůli kterému organizace existuje tzv. primární proces (produkce výrobků či služeb), v jehož rámci se realizuje core business podniku. 2. Veřejné informační systémy (informace jako ekonomická komodita) informační systém jako produkční systém organizace (instituce, firmy), jejímž základním produktem či službou jsou informace (v tom případě i tato organizace musí mít vlastní informační systém zaměřený na podporu vlastního řízení) provozovatel: sektor informačních služeb, informační průmysl 3. Státní informační systém informační systémy státní správy a samosprávy, informační systémy veřejné správy (GIS government information system) specifický typ informačního systému organizace (1.) 19

21 podnikové informační systémy (BIS business information system) 4 Systémy, provozované v kontextu konkrétní organizace, jejichž účelem je správa informací a znalostí a jejich integrace do podnikových procesů za podpory informačních a komunikačních technologií. Obsažené informace jsou chápány jako jeden z ekonomických zdrojů (aktiv) organizace. Rozlišují se systémy podporující vlastní činnosti a služby organizace (automatizace podnikových procesů např. CIM, workflow management, elektronický obchod, systémy pro tvorbu a správu dokumentů) a tzv. manažerské systémy, podporující řídící a administrativní funkce. Jako softwarové vybavení se nabízejí zpravidla tzv. typová řešení pro konkrétní odvětví nebo obchodní model. a) provozní, transakční systémy (ERP enterprise resources planning) systémy na podporu provozu (chodu) firmy technologický princip: OLTP, relační databáze b) systémy na podporu rozhodování (MIS management information system, EIS executive information system, DSS decision support system, BI business intelligence) technologický princip: OLAP, datové sklady (data warehouse), dolování dat (data mining) základem není realizace transakcí, ale prohledávání a analýza velkých objemů dat c) systémy na podporu plánování (APS advanced planning and scheduling: systémy na podporu vnitropodnikového (dílenského) plánování, SCM supply chain management: plánování dodavatelských logistických řetězců plánování mimo podnik, HR human resources řízení lidských zdrojů) d) systémy řízení vztahů se zákazníky (CRM customer relationship management) systémy pro tvorbu a správu dokumentů (DTP desktop publishing, DMS document management system) Systémy umožňující efektivní práci s elektronickými dokumenty a jejich obsahem v průběhu celého jejich životního cyklu. Typickými procesy jsou tvorba, schvalování, evidence, digitalizace, prohlížení, editace, publikování, komunikace, sdílení, uložení, vyhledání, archivace, skartace apod. Obvykle je zahrnuta i skupinová spolupráce, workflow management a propojení dokumentů s informacemi v ostatních (např. provozních) informačních systémech. technologický princip: aplikační software, obsahující nástroje pro tvorbu, publikování, fulltextové vyhledávání, řízení přístupu k elektronickým dokumentům, správu verzí, sledování historie použití a změn. automatizace kancelářských prací (kancelářské systémy office automation) technologický princip: komplex aplikací (modulů) textový editor, databáze, tabulkový procesor, grafický program, komunikační program, program pro síťovou spolupráci (networking) zpravidla s jednotným uživatelským rozhraním a s možností vyměňovat a sdílet objekty vytvořené jednotlivými moduly. 4 Přehled podnikových informačních systémů a jejich producentů spolu s odkazy na další informace na Internetu je k dispozici v souboru Dalším zdrojem aktuálních informací o podnikových informačních systémech na českém trhu je server SystemOnLine ( 20

22 automatizovaný knihovní systém technologický princip: aplikační software provozního (transakčního) typu, určený k automatizaci procesů realizovaných v knihovně. Obvykle má modulární strukturu; typické moduly jsou akvizice, katalogizace, OPAC, výpůjčky a MVS, správa seriálů. Zpravidla obsahuje i nástroje pro zapojení do sítě knihoven a pro komunikaci s externími zdroji. CA (computer aided) technologie (CAD, CAM, CIM, CASE...) Podstata: počítačová podpora (automatizace) některých procesů (návrh, výroba ap.) geografické informační systémy (GIS) Prostorově orientované informační systémy, provozované za podpory informačních a komunikačních technologií. Datovou základnu tvoří digitální geografické informace ve formě záznamů nebo objektů (tzv. geoprvky), s nimiž specializovaný software umožňuje provádět manipulaci (zápis a editace údajů, uložení, vyhledávání, propojování, transformace a vizualizace), lokalizaci (určení polohy), geografické analýzy a modelování (např. trojrozměrný model terénu). expertní systémy Počítačové aplikace nebo systémy simulující poznávací a rozhodovací činnost experta při řešení složitých úloh s cílem dosáhnout ve zvolené problémové oblasti kvality rozhodování na úrovni experta. Základní součásti tvoří báze znalostí, báze dat (faktů) k řešeným případům a řídící mechanismus (inferenční neboli odvozovací stroj, rozhodovací jádro), tj. program pro práci s těmito bázemi využívající technik umělé inteligence. Tyto základní součásti obvykle doplňuje modul pro komunikaci s uživatelem a vysvětlovací modul. veřejné informační systémy Informační systémy, které jsou dostupné široké veřejnosti a poskytují veřejné informační služby. V tomto smyslu se jedná o jakékoli informační systémy bez ohledu na jejich provozovatele, obsah, typ, formu a příp. cenu poskytovaných informací a služeb. Opakem jsou tzv. privátní, uzavřené, neveřejné informační systémy (např. podnikové informační systémy, systémy zajišťující obranu státu, osobní informační systémy ad.). provozovatelé: knihovny, informační instituce, databázová centra dokumentografické a plnotextové databáze, periodický tisk, televize, rozhlas, zpravodajské agentury státní informační systém, informační systém veřejné správy Systém, jehož účelem je podporovat činnosti provozované při výkonu veřejné správy, tj. státní správy a samosprávy, a poskytovat veřejné informační služby včetně informací o subjektech veřejné správy. Představuje komplex navzájem propojených subsystémů, členěných z hlediska věcného, resortního a regionálního. Nejdůležitější součást datové základny tvoří evidence (registry) základních skutečností nezbytných pro výkon veřejné správy: evidence obyvatel, evidence ekonomických subjektů, evidence území a územních jednotek. 21

23 3. Obecné metody systémové analýzy 3.1 Grafy graf (diagram): nástroj pro zobrazení výsledků systémové analýzy určitý útvar (rovinný, prostorový), znázorňující vztahy (vazby, relace) mezi prvky systému prostřednictvím množiny uzlů a hran umožňuje i dynamický, funkční pohled na data (orientovaný graf) uzel: při znázorňování grafu v rovině se uzly zobrazují zpravidla jako body této roviny hrana: spojnice dvou uzlů v grafu, popř. čára začínající a končící v témže uzlu (tzv. smyčka); hrany značíme koncovými uzly cesta: posloupnost navazujících hran typy grafů: a) souvislý nesouvislý souvislý graf: mezi každými dvěma uzly existuje alespoň jedno spojení (mezi libovolnou dvojicí uzlů existuje nějaká cesta) b) orientovaný neorientovaný hranám je/není přiřazena orientace (směr) orientovaný graf (usměrněný graf, postupový diagram) c) ohodnocený neohodnocený hranám či uzlům jsou/nejsou přiřazeny hodnoty (vzdálenost, čas, náklady...) ohodnocená hrana či uzel: má přiřazeno jedno nebo více čísel, obvykle nezáporných (např. trvání, nároky na zdroje) d) hranově definovaný uzlově definovaný činnost zobrazují buď hrany nebo uzly hranově definovaný graf: činnost znázorňuje hrana uzel znázorňuje okamžik zahájení nebo ukončení jedné, popř. více činností uzlově definovaný graf: činnost znázorňuje uzel hrana znázorňuje vztah mezi činnostmi 22

24 Logické operace znázorňované v grafech následnost též posloupnost, sekvenční směrování, sekvence, přechod smyčka též opakování procesů, iterace, cyklus, rekurze větvení 1 vstup, více výstupů větvení, rozhodování alternativní sled činností, výběr alternativ, selekce, OR split, xor exclusive OR, buď/nebo paralelní směrování současně probíhající činnosti, AND split, a zároveň spojování více vstupů, 1 výstup spojování sbíhání alternativních větví, OR join synchronizace vyústění paralelních činností do jedné, AND join Síťový graf, diagram (network chart) orientovaný, souvislý, hranově definovaný obvykle ohodnocený graf, obsahující dva speciální uzly vstup a výstup (začátek a konec) grafické zobrazení procesu vyjadřující vztahy a závislosti jeho jednotlivých činností (úloh) uzly v hranově definovaném síťovém grafu označují události začátek nebo konec činnosti v uzlově definovaném síťovém grafu označují činnosti hrany v hranově definovaném síťovém grafu označují vykonání činnosti (šipka znázorňuje směr toku práce) v uzlově definovaném síťovém grafu označují vztah (posloupnost) činností dummy (falešná, fiktivní hrana) následnost událostí za sebou v čase, přičemž se nevykonává žádná činnost a nespotřebovávají žádné zdroje znázorňuje, že následující činnost (za uzlem 2) může být započata až po dokončení předchozí činnosti (před uzlem 1)

25 3.2 Statický popis systému strukturní diagram prvek systému (element) identifikace: název, příp. vlastnosti (atributy) znázornění: čtverec, obdélník nebo kruh, ovál subsystém znázornění: čtverec, obdélník nebo kruh, ovál (stejně jako prvky systému) okolí prostředí systému (environment) znázornění: slovní popis, prvky okolí se znázorňují stejně jako prvky systému hranice rozhraní systému (boundary interface) znázornění: přerušovaná čára vztah (relationship) znázornění: čára spojující prvky vstup (input) znázornění: orientovaná čára (šipka) výstup (output) znázornění: orientovaná čára (šipka) proces (process) znázornění: čtverec, obdélník nebo kruh, ovál (stejně jako prvky systému) Prvek okolí 1 Vstup 1 Okolí systému Systém Výstup 1 Prvek okolí 4 Prvek okolí 2 Vstup 2 Prvek 2 Subsystém Prvek 1 Proces 1 Prvek 3 Prvek okolí 3 Vstup 3 Proces 2 Zpětná vazba Výstup 2 Prvek okolí 5 24

26 Zpracovatelský proces, zpětná vazba a řídící proces obecný pohled SYSTÉM ZDROJ vstup ZPRACOVATELSKÝ PRVEK výstup EFEKT úpravy ŘÍDÍCÍ PRVEK zpětná vazba Příklad: Zpracovatelský proces, zpětná vazba a řídící proces výpůjční systém knihovny ČTENÁŘ půjčené a vrácené knihy, pokuty zaslané upomínky pokyn k zaslání upomínky VÝPŮJČNÍ SYSTÉM KNIHOVNY ZPRACOVÁNÍ VÝPŮJČEK KONTROLA DODRŽOVÁNÍ LHŮT data o výpůjčkách zpráva o délce výpůjční lhůty EVIDENČNÍ SYSTÉM KNIHOVNY 25

27 3.3 Funkční popis systému Využití funkční (procesní) analýzy v současných informačních systémech Návrh informačního systému podniku Byznys modelování Dokumentace procesů v podniku (např. pro certifikát jakosti podle ISO 9000) Operační analýza / výzkum (manažerská věda) hledá optimální řešení složitých problémů rozkladem složitého procesu na dílčí činnosti Síťová analýza grafická metoda operační analýzy (znázornění závislostí dílčích činností pomocí síťového grafu) Příprava podkladů pro počítačový program, který bude procesy podporovat nebo samostatně vykonávat (automatizovat) správa podnikových procesů (BPM, workflow management) Reengineering procesů podniku (BPR business process reengineering) Tvorba znalostní báze podniku implicitní (tacitní) znalosti o procesech (best practices) se převádějí na explicitně vyjádřené znalosti v modelech a dokumentech Vývojový diagram (flowchart) orientovaný, souvislý, uzlově definovaný obvykle neohodnocený síťový graf grafické znázornění definice, analýzy nebo metody řešení problému, ve kterém jsou symboly používány pro znázornění operací, dat, toku, zařízení atd. (ČSN ISO 5807) nástroj pro modelování procesů v systému vyjadřuje logickou strukturu procesu nebo operace, tj. souvislosti (vztahy) jednotlivých činností Využití vývojových diagramů v projektování informačních systémů: definování tzv. algoritmů algoritmus: jednoznačný a vyčerpávající popis, které operace a v jakém pořadí se mají vykonat, aby bylo možné úlohu vyřešit 1. vývojový diagram programu návrh struktury počítačového programu (blokové schéma) zastaralé, pro současný objektově orientovaný přístup nevhodné 2. dynamický model systému zobrazování algoritmů transformačních procesů při modelování systémů; ilustruje části (prvky) a toky informačního systému (např. diagram aktivit, sekvenční diagram a stavový diagram v UML) 3. procesní analýza, workflow management 26

28 základní struktura: vstup zpracování výstup Základní symboly (notace) vývojových diagramů 1. symboly zpracování zpracování (akce, proces) jakákoli operace, jejímž výsledkem je transformace dat rozhodování (větvení) paralelní režim 2. symboly dat vstup/výstup dat (bez určení média) např. žádost o informaci/poskytnutá informace paměť, uložení dat (bez určení média) tištěný vstup/výstup dat (dokument) 3. symboly spojení tok dat nebo řízení 4. zvláštní symboly mezní značka (začátek, konec) spojka 27

29 Zobrazované logické operace ve vývojových diagramech: následnost (posloupnost) smyčka větvení (OR, AND) spojování (OR, AND) 28

30 Příklad vývojového diagramu: Obsluha čtenářů u výpůjčního pultu v knihovně Začátek Výběr aktivity Placení Vracení Půjčování Zaplacení poplatku/pokuty Předložení vracené knihy Předložení vybrané knihy Vyplnění výpůjčního lístku Ne Záznam o vrácení, o zaplacení Je správně vyplněn? Ano Vytištění potvrzení Převzetí knihy Záznam o výpůjčce Konec 29

31 Pokyny pro zpracování vývojových diagramů: chovejte se tak, jako byste připravovali program pro počítač (tj. nespoléhejte na intuitivní rozhodování nebo navyklé postupy) pokud se jedná o složitější problém, vytvořte několik jednodušších diagramů a) postupně řešených na různých úrovních podrobnosti (nejprve obecné blokové schéma, pak detailnější členění jednotlivých bloků) b) rozdělte rozsáhlé detailní schéma do více dílů stránek každý diagram musí mít alespoň jeden začátek a alespoň jeden konec každý proces zobrazujte pouze jednou každý proces musí mít alespoň jeden vstup a alespoň jeden výstup každý rozhodovací proces musí mít pouze jeden vstup a více než jeden výstup každý proces musí směřovat k jasně definovanému ukončení jakmile na proces nic dalšího nenavazuje, je to KONEC snažte se o přehlednost, srozumitelnost, úpravnost a) toky dat zobrazujte: shora dolů a zleva doprava b) nepřekřižujte čáry toků dat c) nespojujte dvě vstupní čáry do jedné výstupní ve stejném bodu validace (potvrzení správnosti) vývojového diagramu: průchod všemi větvemi (každá cesta by měla vést od začátku ke konci), průchod testovacích dat Příklad: Hierarchické členění vývojového diagramu 30

32 3.3.2 Byznys modelování (model podnikových procesů) model podnikových procesů (též mapa procesů, procesní mapa) je: konceptuální (implementačně nezávislý) model všeho, co se v podniku děje obdoba organizačního schématu (organizační schéma je statické, procesní mapa je dynamická) zobrazení procesů a jejich interakcí v systému od počátečního bodu po jeden nebo více koncových bodů. Důraz se klade na zobrazení vztahů procesů a objektů s nimi souvisejících. využití modelu: podklad pro návrh informačního systému podniku podklad pro reengineering procesů podniku podklad pro procesní management (procesní řízení business process management, workflow management) dokumentace procesů v podniku (např. pro certifikát jakosti podle ISO 9000) podnikový (byznys) proces skupina aktivit, jejichž provedením se přidá hodnota pro zákazníka vzájemně propojené dílčí činnosti, které ve své posloupnosti transformují vstupy na požadované výstupy tok práce, postupující od jednoho pracovníka (oddělení) ke druhému typy podnikových procesů: klíčové pomocné manuální automatizované (IT intensive) kolaborativní (assembly line) individuální (once and done) 1. klíčový, primární, realizační ("core") proces produkce výrobků či služeb, kvůli kterým podnik existuje hodnota se poměřuje potřebami zákazníků výstup: hodnota pro zákazníka 2. pomocný, podpůrný (supporting) proces zajišťuje činnosti a zdroje pro klíčové procesy (řízení, prodej a marketing, finanční řízení, personalistika) výstup: hodnota pro klíčový proces atributy podnikových procesů vstupy: výchozí zdroje (suroviny, materiál, kapacity strojů, lidé, kapitál, technologie, data, informace, znalosti), dodavatelé, výstupy z jiných procesů výstupy: konečné výsledky sloužící zákazníkovi (výrobek nebo služba) stakeholder: zainteresovaný subjekt vlastník: osoba zodpovědná za efektivnost daného procesu zákazník (interní, externí): přebírá výstup procesu další: investoři, konkurence, regulátoři, management, zaměstnanci, dodavatelé, partneři, prodejci... 31

33 Základní konstrukty (notace dle modulu Business Process Model PowerDesigneru): začátek konec proces zdroj tok rozhodování synchronizace formát zprávy datový tok podmínka organizační jednotka 32

34 3.3.3 Workflow (workflow management) počítačová podpora podnikových procesů 5 automatizace podnikového procesu, vcelku nebo jeho části, v jejímž průběhu jsou dokumenty, informace nebo úlohy předávány od jednoho účastníka ke druhému v souladu s procedurálními pravidly tak, aby se dosáhlo nebo přispělo k plnění podnikových cílů workflow management system: systém, který podrobně definuje, spravuje a realizuje toky práce prostřednictvím programu, jehož operace jsou řízeny počítačovou reprezentací (modelem) logiky procesu poskytované služby při automatizaci podnikových procesů: administrace směrování informací definování rolí a pravidel monitorování (sledování průběhu jednotlivých kroků procesů) kontrola (např. dodržování stanovených termínů) při přechodu do nového kroku jsou automaticky předávány aktivity dalšímu uživateli (v jeho nepřítomnosti jeho zástupci) generování a dodávání elektronických vyrozumění vyvolávání (spouštění) IT nástrojů a aplikací (např. textový editor, ...) model pro workflow management: speciální aplikace vývojových diagramů spojení vývojového diagramu a organizačního schématu v modelu definujeme: procesy (strukturované nebo částečně strukturované obchodní procesy) ty se dále mohou členit na kroky procesů (worksteps) a aktivity (činnosti, které se provádějí v kroku procesu) následnost (příp. paralelnost) kroků procesu podmínky, za nichž dojde ke správnému kroku lhůty pro realizaci aktivit přiřazení uživatelů (pracovníků) jednotlivým krokům programy, které se spouštějí během jednotlivých kroků data, potřebná pro realizaci jednotlivých kroků data produkovaná jednotlivými kroky 5 Přehled software pro workflow management spolu s odkazy na další informace na Internetu je k dispozici v souboru 33

35 nejčastější uplatnění: modelování oběhu dokumentů (tj. informací o realizovaných nebo plánovaných činnostech) podnikem Příklad: Model procesu vyplňování studijní zprávy potřebnými údaji v průběhu semestru 34

36 3.3.4 Ganttovy diagramy, síťové grafy CPM/PERT užití: návrh časového plánu (harmonogramu) a řízení projektů (informačních systémů) 6 definujeme: úlohy zdroje pro každou úlohu vedoucí k příslušné události (čas, finance, osoby, materiál, přístroje...) události zobrazujeme: časové překrývání úloh návaznost úloh přiřazení disponibilních zdrojů existujícím úlohám zjišťujeme (a případně optimalizujeme): trvání projektu, kritickou cestu Postup: 1. vytvoření seznamu činností, událostí, příp. deliverables 2. stanovení nároků na zdroje časových, příp. finančních a jiných pro každou činnost vedoucí k příslušné události 3. stanovení posloupnosti činností které činnosti na sebe musí navazovat 4. určení, které činnosti mohou probíhat souběžně Ganttovy diagramy sloupcové grafy (bar chart), jež ukazují, kolik práce se musí vykonat na každé úloze projektu každou úlohu znázorňuje čára (bar) o délce odpovídající času požadovanému na úlohu úlohy se umísťují do diagramu v pořadí, v jakém budou vykonány Síťové grafy CPM/PERT metoda kritické cesty (CPM Critical Path Method) základní deterministická metoda pro časový rozbor projektu metoda PERT The Program/Project Evaluation and Review Technique (metoda vyhodnocení a sledování projektu) základní stochastická (pravděpodobnostní) metoda pro časový rozbor projektu 6 Přehled programů pro řízení a plánování projektů a jejich producentů spolu s odkazy na další informace na Internetu je k dispozici v souboru 35

37 Příklad délka a posloupnost procesů: A 1 hodina žádná následnost B 2 hodiny následuje po A C 3 hodiny následuje po A D 1 hodina následuje po B, C E 2 hodiny následuje po C kritická cesta: 6 hodin Ganttův diagram A B C D E CPM/PERT graf B 2 hodiny 3 A 1 hodina dummy E 2 hodiny dummy C 3 hodiny 4 D 1 hodina 5 kritická cesta: 36

38 4. Speciální metody systémové analýzy Společné rysy všech metodik projektování informačních systémů: 1) více oddělených pohledů na IS oddělované oblasti: data procesy celek část (detail) několik úrovní hierarchie konkrétní (realita) abstraktní (obecné / model) architektury (např. princip tří architektur 1. byznys model model reality, 2. model IS, 3. implementovaný IS) 2) modelování (reality i informačního systému) 3) abstrakce reality 4.1 Základní prvky modelů informačních systémů Entity, třídy entita 7 jakýkoli objekt, prvek, který nás zajímá (= reálný objekt) třída sdružuje entity se společnými charakteristikami; popis množiny objektů, jež sdílejí stejné atributy, operace, vztahy a sémantiku instance konkrétní výskyt určité entity (třídy, typu) naplněný hodnotami, jež vyjadřují jeho stav nebo změnu stavu 8 (= objekt v informačním systému) Atributy atribut charakteristika (vlastnost) entity nebo třídy; vymezuje hodnoty, kterých mohou nabývat její instance 7 Terminologická poznámka: Slovo entita označuje něco jsoucího, existujícího. Původně bylo zavedeno jako filozofický termín scholastiky (z latinského ens jsoucí), v současnosti je užíváno k označení blíže neurčeného útvaru, ať už skutečného, nebo pouze domnělého či předpokládaného. 8 Poznámka: V objektově orientovaném přístupu se za instanci třídy označuje objekt. 37

39 Operace, funkce, procesy operace: jakákoli událost, která nás zajímá funkce: sdružuje více operací Vztahy sémantická spojení mezi dvěma nebo více prvky modelu a) hierarchické vztahy generické, rododruhové vztahy dědičnost, též generalizace (abstrakce, zobecnění) specializace vztah, který definuje jednu entitu prostřednictvím jiné entity (např. dětskou třídu prostřednictvím rodičovské třídy), přičemž entita potomek dědí vlastnosti svého předka generalizace, abstrakce, zobecnění b) nehierarchické vztahy předek potomek specializace, taxonomie kauzální (příčina důsledek), partitivní (celek, kontejner část), finální (účel prostředek) asociace obecný sémantický vztah mezi prvky modelu, který specifikuje spojení mezi jejich instancemi agregace (kolektivizace), kompozice forma asociace, jež vyjadřuje vztah celek část; celek pouze sdružuje prvky (komponenty), nedefinuje jejich společné charakteristiky agregace element může přežít svůj kontejner, příp. stát se součástí jiného kontejneru Příklad: Zaměstnanec (část) Oddělení (celek) kompozice silnější vazba zrušením kontejneru automaticky zrušíme i obsažený element; daný element může být součástí právě jednoho kontejneru Příklad: Okno (část) Dům (celek) závislost vztah mezi dvěma elementy modelu, v němž změna jednoho (nezávislého) elementu ovlivní druhý (závislý) element vztah, v němž jeden element využívá služby nebo vybavení jiného elementu zahrnuje i posloupnost, následnost (např. v čase) násobnost (multiplicity) ukazuje počet hodnot (kardinalit), jichž může nabývat příslušná role ve vztahu (role označuje úlohu, kterou má objekt viděný objektem z druhé strany vztahu) 38

40 4.2 Typy přístupů v návrhu (projektování) informačních systémů zdrojový funkční zdrojový přístup: stanovení datového modelu reality a nového systému (zajímají nás uživatelské potřeby) informační (datová) analýza funkční přístup: stanovení cílů, které by měl nový systém splňovat (zajímá nás fungování systému) funkční analýza top-down bottom-up Realita (skutečný svět) Databáze top down (shora dolů) postup od abstraktního ke konkrétnímu Konceptuální model (schéma) Entity bottom up (zdola nahoru) postup od konkrétního k obecnému Technologický model Logický model Fyzická struktura dat Atributy strukturovaný objektově orientovaný strukturovaný přístup: aplikace má podobu hierarchie funkcí, která je realizována strukturovanými programy styl práce: AKCE OBJEKT objektově orientovaný přístup: funkce jsou realizovány pomocí programových fragmentů" nad stabilními strukturami databází styl práce: OBJEKT AKCE rigorózní (striktní) agilní (light) plánovací konstrukční implementační 39

41 Historie standardizace přístupů k návrhu informačních systémů cíl standardizace: určit, co se bude v návrhu popisovat určit termíny a symboly, které se budou používat pro popis 1971 CODASYL síťový model databáze 1975 Zpráva ANSI/SPARC (tříschématový model) 1978 Technická zpráva ISO TR 9007 Pojmy a terminologie pro pojmové schéma a informační základnu konceptuální model 1995 UML Unified Modeling Language objektový model 2001 MDA Model Driven Architecture model jako základ architektury systému standardizace modelů CODASYL zpracovatel: DBTG CODASYL vydáno 1971 návrh síťového modelu databázového systému Zpráva ANSI/X3/SPARC DBSG SPARC Standards Planning and Requirements Committee of American Standards Committee on Computers and Information Processing DBSG Study Group on Data Base Management Systems vydáno 1975, revidovaná verze vydána 1978 víceúrovňová (tříschématová) struktura databázových systémů: externí schéma (systém, tak jak jej vidí uživatel tzv. pohledy) konceptuální schéma interní schéma (systém, tak jak jej vidí správce nebo technik) ČSN ISO TR 9007 ( ) Systémy zpracování informací. Pojmy a terminologie pro pojmové schéma a informační základnu zpracovala Technická komise ISO/TC 97 Zpracování informačních systémů vydáno 1987 shrnutí dosavadních přístupů k definování datové základny návrh pojmů a termínů, které by se měly používat v projektování a popisu informačních systémů: 40

42 Sledovaná část reality je souhrnem objektů entit, jejich vlastností a vazeb mezi těmito objekty. univerzum diskursu obor úvah: všechny entity, o které se zajímáme, které byly, jsou nebo mohou být (též univerzum možných entit) diskurs: rozhovor (který vedeme o realitě) entita: jakákoliv konkrétní nebo abstraktní věc, na niž je soustředěn zájem, včetně vazeb mezi věcmi výrok: stav věcí týkající se entit, o kterém je možné tvrdit nebo popírat, že takový stav pro tyto entity nastal instance nebo výskyt: individuální entita, pro kterou platí konkrétní typ výroku, a které náleží ke konkrétní třídě entit pojmové (konceptuální) schéma: ucelený soubor vět vyjadřujících nutné výroky, které platí pro univerzum diskursu informační báze: objekty vyhovující konceptuálnímu schématu databázový model: množina syntaktických pravidel spolu s metodou, jak je použít při modelování reálného světa Unified Modeling Language 1995 Unified Method 0.8 (metodika) autoři: Rumbaugh, Booch 1996 Unified Modeling Language 0.9 (jazyk notace) autoři: Rumbaugh, Booch, Jacobson 1997 UML 1.0, UML 1.1 autor: konsorcium jazyka UML (Rational, Hewlett-Packard, Oracle, Microsoft ad.) OMG Object Management Group: převzetí dalšího vývoje a standardizace UML 1998 UML UML UML UML 1.5 od 2003 příprava UML ISO/IEC 19501:2005 Information technology Open Distributed Processing Unified Modeling Language (UML). Version s UML (Superstructure / Infrastructure Specification) OMG Object Management Group mezinárodní neziskové softwarové konsorcium zpracovávající firemně nezávislé (otevřené) standardy pro oblast distribuovaných objektových technologií, založené 1989 cca 800 členských organizací projekty: CORBA, UML, XML, MDA Poznámka: EUROMETHOD přes svůj název nepředstavuje metodiku analýzy a návrhu informačního systému, nýbrž metodiku akvizice informačního systému 41

43 Typy schémat při vytváření informačního systému Realita (skutečný svět) Vnější (externí) schéma Konceptuální schéma Vnitřní (interní) schéma Logický model (logická struktura dat) Fyzická struktura dat Stadia modelování a typy modelů postup shora dolů (top-down) Konceptuální model strukturovaný datový informační báze Logický model databáze funkční objektově orientovaný lineární hierarchický síťový relační objektově orientovaný Fyzický model soubory centralizovaný distribuovaný 42

44 1. Konceptuální model reality alternativní názvy: esenciální, pojmový, sémantický, věcný model (schéma, diagram), K- schéma má vyjádřit esenci podstatu systému říká, co musí systém dělat, aby zajistil uživatelovy požadavky implementačně nezávislý jednotný centrální popis různých informačních obsahů, které mohou být v datových základnách věcně orientovaný obsahuje sémantický model dat věcný obsah (sémantika) databáze vymezuje, co budeme v datové základně sledovat, aniž obsahuje údaje o tom, jak budeme tyto předměty v datové základně realizovat slouží jako společný základ pro: chápání světa objektů uživateli, projektanty, správci databáze apod. interpretaci uživatelských pohledů a návrh implementace zobrazení mezi uživatelskými pohledy a fyzickým uložením definici pravidel vývoje a manipulaci v informační bázi využití: údaje potřebné pro specifikaci zadání úlohy nebo pro komunikaci s uživatelem 2. Logický model reality (logická struktura dat) určuje, jak je konceptuální struktura dat implementována v konkrétním technickoprogramovém prostředí logické (databázové) modely: lineární, hierarchický, síťový, relační, objektově orientovaný využití: údaje potřebné pro projektanta při algoritmizaci a programování 3. Fyzická struktura dat model fyzického uspořádání dat (vyjadřuje jejich uložení na konkrétním médiu) MDA Model Driven Architecture architektura řízená modelem autor: OMG (Object Management Group) cíl: standardizovat typy modelů vytvářených v průběhu vývoje softwarové aplikace definovat způsoby mapování mezi jednotlivými typy modelů CIM Computation Independent Model model nezávislý na počítačovém zpracování (model podnikových procesů) PIM Platform Independent Model platformově nezávislý model PSM Platform Specific Model platformově specifický model 43

45 Cíl návrhu informačního systému: mít v systému všechna potřebná data nemít v systému žádná nepotřebná data vyjádřit vztahy mezi daty popsat transformaci dat v systému Nejznámější metodologie strukturované analýzy: YSM Yourdonova strukturovaná metodika (Yourdon Structured Method) IEM HIPO JSD LSDM SADT SDM SSA SSADM Information Engineering Methodology (James Martin) hierarchy plus input proces output Jackson system development systém firmy LSDM structured analysis and design technique systems development methodology structured systems analysis structured systems analysis and design methodology Významné osobnosti strukturované metodologie: Peter P. Chen James Martin Edward Yourdon Tom DeMarco datový přístup (ERA diagramy) funkční přístup (DFD diagramy datových toků) Nejznámější metodologie objektově orientované analýzy: Demeter method Shlaer-Mellor Method Booch Method (Grady Booch) OMT OOATool RUP Object Modeling Technique Object-Oriented Analysis Tool (P. Coad, Edward Yourdon) Rational Unified Process Významné osobnosti objektové metodologie: James Rumbaugh Ivar Jacobson Grady Booch 44

46 4.3 Strukturovaná metodologie Entitně relační model (ERA) alternativní názvy: ERA, ERD, E R, ER model (schéma, diagram) množina pojmů sloužící k statickému popisu aplikace na konceptuální úrovni model popisující objekty, které nás zajímají, jejich vlastnosti a jejich vzájemné vztahy ERA diagram: grafický prostředek pro analýzu a zobrazení datového modelu systému Základní prvky a symboly (notace) entitně relačního modelu 1. typy entit (entitní typy, entity types) 9 množiny objektů stejného typu (např. ČTENÁŘ, KNIHA) entita: rozlišitelný a identifikovatelný objekt světa objektů existuje nezávisle a může být uvažován sám o sobě a) popsatelný objekt (odlišitelný od okolí) b) jednoznačně identifikovatelný objekt (objekty stejného typu musí být odlišitelné navzájem) znázornění: obdélník, název (podstatné jméno v jednotném čísle) 2. typy vztahů (relationship types) vztahy, do kterých mohou entity vstupovat (např. JSOU PŮJČENÉ) vztah: vazba mezi dvěma nebo více entitami znázornění: kosočtverec, čáry spojující související entity a vztahy, název (sloveso) 3. atributy (attributes) funkce přiřazující entitám či vztahům hodnotu, určující některou podstatnou vlastnost entity nebo vztahu (např. DATUM VÝPŮJČKY) atribut: vlastnost entity (taková vlastnost z množiny všech možných vlastností, která je společná co do výskytu každému výskytu entity nebo vztahu) doména: množina možných hodnot atributu znázornění: kružnice (ovál), název (podstatné jméno) 9 V praxi se tato terminologie často zjednodušuje a slovem entita se označuje množina entit (entitní typ). 45

47 4. integritní omezení definování vlastností entit, vztahů a atributů např. identifikační klíč (klíčová položka), datový typ, kardinalita vztahu identifikátor (klíč) entity podtržení názvu atributu Datum výpůjčky Pojmy atribut, entita a vztah jsou relativní jejich užití závisí na účelu, pro který ERA model tvoříme. Příklady: KNIHA AUTOR mohou být dvě entity, entita atribut (autor jako atribut knihy), nebo atribut entita (kniha jako atribut autora) KNIHA AUTOR KNIHA Autor AUTOR Kniha KNIHA VÝPŮJČKA mohou být dvě entity, entita atribut (výpůjčka jako atribut knihy), atribut entita (kniha jako atribut výpůjčky), entita vztah (výpůjčka jako vztah mezi knihou a nějakou další entitou např. ČTENÁŘ) KNIHA VÝPŮJČKA KNIHA Výpůjčka VÝPŮJČKA Kniha KNIHA VÝPŮJČKA ČTENÁŘ 46

48 Nejčastější způsoby vyjádření ERA modelu Příklad: Vladimír Koutecký z Prahy 4 si 2. října 2007 půjčil na tři týdny Tajný deník Laury Palmerové (signatura A1586) a) lineární textový zápis E: ČTENÁŘ (Jméno, Adresa) KNIHA (Signatura, Název) R: VÝPŮJČKA (Datum, Lhůta) b) grafické vyjádření Chenův diagram Jméno Adresa Název Signatura N M ČTENÁŘ SI PŮJČIL KNIHU Kdy Na jak dlouho Metodika Information Engineering Jamese Martina Metodika Merise 47

49 Příklad: ERA diagram pro evidenci praxí a závěrečných prací studentů VOŠIS 48

50 Integritní omezení v ERA modelu identifikační (klíčové) atributy Vlastnosti entit ISA hierarchie funkční závislost jméno Vlastnosti atributů datový typ identifikátor (klíčový) povinný (NOT NULL) unikátní (UNIQUE) vícehodnotový skupinový odvozený rozměr (stupeň) Vlastnosti vztahů kardinalita (mohutnost) členství ve vztahu Vlastnosti entit Každou entitu jednoznačně definujeme v prostoru (tj. rozsahem které objekty do entity patří a které už ne?) a v čase (tj. obdobím či událostí, po které je pro nás objekt součástí entity). Příklad: Entita ZÁKAZNÍK zahrnuje všechny osoby, které si od firmy koupily její výrobek v běžném a v uplynulém kalendářním roce a dále osoby, které mají výrobky firmy objednané (i když je ještě nekoupily). identifikátor (klíčový atribut) atribut nebo množina atributů, jejichž hodnoty umožňují jednoznačně rozlišit jednotlivé entity navzájem 49

51 ISA hierarchie alternativní názvy: nadtyp/podtyp, generalizace/specializace entity nižší úrovně dědí atributy a sdílí identifikátor z entity nadřízené úrovně Příklad: Každý závodník má uvedeno jméno a stát, z nějž pochází. U motoristů se navíc uvádí kubatura motocyklu, u fotbalistů jejich úloha v týmu, u zápasníků hmotnost a u tenistů umístění na žebříčku ATP nebo WTA. ZÁVODNÍK jméno stát ISA MOTORISTA FOTBALISTA ZÁPASNÍK TENISTA kubatura úloha v týmu hmotnost umístění v ATP a WTA Znázornění v PowerDesigneru 50

52 Funkční závislost významová (sémantická) závislost mezi atributy či jejich množinami B A Atribut A je funkčně závislý na atributu B, pokud hodnota atributu B určuje hodnotu atributu A z hodnoty B zjistíme jednu a právě jednu hodnotu A A,B,C D hodnota atributu D závisí na hodnotách atributů A, B a C A B,C,D hodnoty atributů B, C a D závisí na hodnotě atributu A A,B C,D hodnoty atributů C a D závisí na hodnotách atributů A a B Příklad: Funkční závislosti atributů entity STUDENT login jméno STUDENT specializace třída ročník Login Třída Jméno, Specializace, Třída, Ročník Ročník, Specializace Login Jméno Specializace Třída Ročník NOVAKA Novák Podnikové informační systémy I3 3 NOVAKJ Novák Služby knihoven K2 2 PECHOVA Pechová Služby knihoven K2 2 RASKOVA Rašková Podnikové informační systémy B1 1 SOUMAR Soumar Služby muzeí a galerií M2 2 51

53 slabá (popisná) entita: entita existenčně nebo identifikačně závislá na jiné entitě (entitách) silná (regulární, kmenová, základní) entita: entita existující nezávisle na jiných entitách ZBOŽÍ OBJEDNÁVKA ZBOŽÍ: silná entita OBJEDNÁVKA: slabá entita Zboží může existovat bez objednávky, objednávka bez zboží nikoli. Odstraníme-li nějaký výskyt (instanci) entity ZBOŽÍ (např. lednice CALEX 3500), je nutné odstranit i výskyty (instance) entity OBJEDNÁVKY, jež jsou na dané instanci existenčně závislé (tj. všechny objednávky lednice CALEX 3500). Typy funkční závislosti entit: a) existenční závislost Prvky slabé entity závisí existenčně na prvcích jiné entity, tj. zrušíme-li výskyt entity, na níž je slabá entita závislá, zrušíme i existenci závislé entity. Existenční závislost vždy obsahuje povinné členství ve vztahu (entita, která je existenčně nezávislá, se povinně účastní v daném vztahu). b) identifikační závislost (též externí identifikace) Prvky slabé entity závisejí identifikačně na prvcích jiné entity tj. klíč slabé entity definujeme pomocí klíče jiné entity (přebíráme identifikátor/y z jiných entit). Vždy se jedná současně i o existenční závislost (entita, která je identifikačně nezávislá, má vždy povinné členství ve vztahu). Identifikační závislost je zesílením existenční závislosti. Vazební (asociativní) entita realizuje vazbu mezi entitami využití: při dekompozici vztahů N : M na 1 : N 52

54 Vlastnosti atributů Vícehodnotový atribut Příklad: Jedna kniha může být zařazena do více žánrových kategorií. KNIHA (Signatura, Název, Autor1, Autor2, Cena, Místo vydání, Vydavatel, Rok vydání, Žánr:Multi, ISBN) Autor1 Autor2 Cena Místo vydání Vydavatel Rok vydání Název Žánr Signatura KNIHA ISBN Skupinový atribut Příklad: Údaje o knize tvoří skupina evidenčních informací, skupina vydavatelských informací a skupina obsahových informací. KNIHA (EVIDENČNÍ INFORMACE (Signatura, Autor, Cena), VYDAVATELSKÉ INFORMACE (Místo vydání, Vydavatel), OBSAHOVÉ INFORMACE (Název, Žánr)) KNIHA Evidenční informace Vydavatelské informace Obsahové informace Signatura Autor Cena Místo vydání Vydavatel Žánr Název 53

55 Odvozený (derived) atribut Příklad: Délku výpůjčky zjistíme odečtením data půjčení od data vrácení. Datum vrácení Datum půjčení Délka výpůjčky VÝPŮJČKA Vlastnosti vztahů vztahy určujeme mezi identifikátory (klíčovými atributy) entit kombinace rozměru, kardinality a typu členství ve vztahu (navzájem nezávislé) Rozměr (stupeň) vztahu (relationship degree) počet výskytů entit v jednotlivém výskytu vztahu unární (rekurzívní), binární (dvojčlenný, dvojkový, dvourozměrný), ternární (trojčlenný, trojkový, třírozměrný)... n-ární (n-rozměrný) unární (rekurzívní) vztah OSOBA ŽENATÝ/ VDANÁ S 54

56 binární vztah Jméno Název UČITEL N UČÍ N PŘEDMĚT UČÍ UČITEL PŘEDMĚT ZKOUŠÍ ternární vztah Den Hodina Místnost UČITEL N UČÍ N PŘEDMĚT Jméno N Název TŘÍDA Označení 55

57 Kardinalita (mohutnost, funkčnost) vztahu Určení počtu prvků nějakého vztahu kolik výskytů (instancí) jedné entity má vztah k výskytu druhé entity? a) písmena a číslice 1 : 1 1 : N n : 1 N : M N : N b) číslice a symboly 1 : * 1 : * * c) šipky d) vraní stopa (crow s foot) Členství ve vztahu Možnost (ne)existence výskytu partnerské entity (vyžaduje výskyt jedné entity výskyt druhé entity?) Členství (účast) ve vztahu (existenční závislost, úplnost) slovní vyjádření: povinné (obligatorní) nepovinné totální (totalita) parciální (parcialita) úplné částečné mandatory optional grafické vyjádření členství a) úplné b) částečné Kombinované vyjádření kardinality a členství ve vztahu (min, max notace) minimální počet výskytů,.. maximální počet výskytů 1,1 0,1 1,n 0,N 1,7 0,3 N,M 0..* * Příklady: PACIENT CHOROBOPIS oboustranně totální vztah (oboustranně povinné členství) 1 : 1 OBČAN BYT oboustranně parciální vztah (oboustranně nepovinné členství) N : M ZÁKAZNÍK AUTOMOBIL jednostranně parciální vztah 1 : N (nepovinné členství ve směru A Z, povinné členství ve směru Z A: každý evidovaný zákazník prodejny si musel koupit alespoň jeden automobil, každý evidovaný automobil nemusí být prodán) 56

58 Normalizace úprava modelu s cílem omezit redundanci a složitost postup: rozdělení složitých entit, atributů a vztahů na jednodušší celky omezení redundance: každý atribut se má v modelu vyskytovat jen jednou omezení složitosti: každý atribut má být atomický (dále nedělitelný) každý atribut má být skalární (má obsahovat pouze jednu hodnotu) v každé entitě mají být jen atributy, které spolu těsně souvisejí 1. normální forma (1NF) řešený problém: multizávislost každý atribut entity musí obsahovat pouze jeden údaj (hodnotu) jedna entita nesmí obsahovat násobná data (data ve vztahu 1 : N) řešení multizávislostí v entitách, které nejsou v 1NF: vícehodnotový atribut Příklad: Entita ZÁPIS obsahuje údaje o studentech a předmětech, které si zapsali. Jeden student si může zapsat více předmětů. student Řešení: Přidání instancí (řádků). ZÁPIS zapsané předměty Student Zapsané předměty Petr Blažek Angličtina, Matematika, Projekt Student Zapsaný předmět Petr Blažek Angličtina Petr Blažek Matematika Petr Blažek Projekt zapsané předměty 57

59 skupinový atribut Příklad: Údaj o předmětu se skládá z jeho zkratky a z názvu v češtině a v angličtině. Řešení: Přidání atributů (sloupců). Studovaný předmět ANG Angličtina (English) MAT Matematika (Mathematics) PRO Projekt (Project) předmět zkratka název v češtině název v angličtině Zkratka Název v češtině Název v angličtině ANG Angličtina English MAT Matematika Mathematics PRO Projekt Project 2. normální forma (2NF) řešený problém: funkční závislost entity obsahují pouze takové atributy, které jsou funkčně (významově) závislé na celém identifikátoru (primárním klíči) entity Příklad: Evidence předmětů zapsaných jednotlivými studenty. Název ani zkratka předmětu nejsou funkčně závislé na ID studenta. Řešení: Rozdělení dat do více entit. ID studenta Jméno Zkratka Název v češtině 123 Petr Blažek ANG Angličtina 124 Jan Nový MAT Matematika 125 Eva Kotíková MAT Matematika Zkratka ID studenta Název v češtině PŘEDMĚT STUDENT Jméno 3. normální forma (3NF) řešený problém: tranzitivní závislost žádný neklíčový atribut entity nesmí být závislý na jiném neklíčovém atributu 58

60 Metodika tvorby ERA diagramu Zvolte jednu primární entitu ze specifikace požadavků. 2. Určete atributy, jejichž hodnoty se mají pro tuto entitu zaznamenávat. Označte případné klíče (identifikátory) a vytvořte ukázková data. 3. Popište slovně navrženou entitu, její atributy a klíče. 4a. Prověřte funkční vztahy (závislosti) atributů a v případě potřeby entitu normalizujte. 4b. Prověřte atributy navržené entity (pokud možno ve spolupráci s uživatelem) a zjistěte, zda je třeba zaznamenávat informace o jednom či více atributech v nové samostatné entitě. 5. Je-li vhodné vytvořit další entitu, zakreslete ji do diagramu a vraťte se na krok Spojte entity vztahy, pokud tyto existují. Popište slovně vztahy mezi entitami z obou stran. 7a. Prověřte seznam atributů a určete, zda některé z nich potřebují být identifikovány prostřednictvím dvou (či více) entit. Pokud ano, umístěte atribut na příslušný vztah, který spojuje dané entity. 7b. Prověřte, zda v diagramu nemáte smyčky (kružnice), které mohou indikovat nadbytečné (odvozené) vztahy. Pokud je vztah skutečně redundantní, odstraňte ho. 8. Vytvořte ukázková data. 9. Předveďte navržený model (diagram i slovní popis) uživateli. Pokud je to třeba, upřesněte diagram. 10 Zpracováno s použitím: BAGUI, Sigha a EARP, Richard. Database design using entity-relationship diagrams. Boca Raton : Auerbach Publications, s. ISBN

61 Možné přístupy k tvorbě ERA diagramu: 1. zdola nahoru (bottom-up) nejprve sestavíme seznam atributů, pak je seskupíme do entit 2. shora dolů (top-down) nejprve definujeme entity, pak je naplníme atributy Pravidla návrhu správných ERA diagramů Zobrazujeme pouze data a jejich vztahy, žádné procesy Každý atribut zobrazujeme pouze jednou cílem je strukturovat seznam atributů, nikoli např. znázorňovat propojení v relační databázi Zobrazujeme seskupení dat pro účely databáze, nikoli pro účely výstupů (kombinaci atributů z různých entit a případné duplicity realizují až pohledy formuláře nebo sestavy) Zobrazujeme pouze perzistentní (trvalé) datové objekty data, jež hodláme vygenerovat výpočty a agregacemi, nemodelujeme Zobrazujeme pouze nezbytně nutné vztahy, tj. ty, které k něčemu využijeme (např. k propojení v dotazu) nezobrazujeme: odvozené vztahy kruhové závislosti (smyčky) redundantní vztahy Příklad: Redundantní vztah STUDENT UČITEL Entity mají být normalizované (např. atributy, mezi kterými je vztah 1 : N, nepatří do stejné entity) Pozor na tyto entity: entita bez atributů entita, která má pouze identifikátor a žádné další atributy entita, u níž nastane pouze jeden výskyt entita, která obsahuje atributy patřící jiným entitám (tzv. cizí atributy) 60

62 Strukturovaná čeština pro slovní popis ERA diagramů ENTITY Informační systém zaznamenává údaje o [název entity]. Pro každou [název entity] zaznamenáváme v informačním systému [názvy atributů]. Informační systém zaznamenává údaje o knihách. Pro každou knihu zaznamenáváme v informačním systému název, autora, cenu, vydavatelské údaje, čtenáře, kteří si ji půjčili, a data půjčení a vrácení. ATRIBUTY a) Atomické atributy Pro každou [název entity] bude existovat vždy jeden a pouze jeden [název atributu]. Hodnota [název atributu] se nebude dále členit (na dílčí údaje). Pro každou knihu bude vždy jeden a pouze jeden název. Hodnota názvu se nebude dále členit. b) Složené (skupinové) atributy Pro každou [název entity] budeme zaznamenávat [název atributu], který se skládá z x, y, z, (x, y, z) jsou součástmi [název atributu]. Pro každou knihu budeme zaznamenávat vydavatelské údaje, jež se skládají z názvu vydavatele, místa vydání a roku vydání. Název vydavatele, místo vydání a rok vydání jsou součástí vydavatelských údajů. c) Vícehodnotové atributy Pro každou [název entity] budeme zaznamenávat [název atributu]. Může být zaznamenán více než jeden [název atributu] pro každou [název entity]. Pro každou knihu zaznamenáváme autory. Může být zaznamenán více než jeden autor pro každou knihu. d) Odvozené atributy Pro každou [název entity] může existovat [název atributu], který bude odvozen z databáze. Pro každou knihu může existovat lhůta (počet dnů zapůjčení), která bude odvozena z databáze (odečet data výpůjčky od data vrácení). 61

63 KLÍČE a) Jeden kandidát klíče (silná entita) Pro každou [název entity] budeme mít následující primární klíč: [název atributu]. Pro každou knihu budeme mít následující primární klíč: přírůstkové číslo. b) Více než jeden kandidátní klíč (silná entita) Pro každou [název entity] budeme mít následující kandidátní klíče: [názvy atributů]. Pro každou knihu budeme mít následující kandidátní klíče: přírůstkové číslo, signatura, ISBN. c) Žádní kandidáti klíče (slabá entita) Pro žádnou [název entity1] nepředpokládáme, že by kterýkoli z atributů byl dostatečně unikátní, aby identifikoval individuální [název entity1] bez doplňujícího odkazu na [název entity2], vlastnickou silnou entitu. Pro žádnou rezervaci nepředpokládáme, že by kterýkoli z atributů byl natolik unikátní, aby identifikoval individuální rezervaci bez doplňujícího odkazu na knihu, vlastnickou entitu. d) Žádní kandidáti klíče (vazební entita) Pro žádnou [název vztahové entity] nepředpokládáme, že by kterýkoli z atributů byl dostatečně unikátní, aby identifikoval individuální [název vztahové entity] bez doplňujícího odkazu na [název entity2], vlastnickou entitu. Pro žádnou výpůjčku nepředpokládáme, že by kterýkoli z atributů byl natolik unikátní, aby identifikoval individuální výpůjčku bez doplňujícího odkazu na knihu a čtenáře, vlastnické entity. 62

64 VZTAHY [název entity1] [název vztahu aktivum] [název entity2] [název entity2] [název vztahu pasivum] [název entity1] a Čtenáři si půjčují knihy a knihy jsou půjčovány čtenáři. nebo Čtenář si půjčuje knihy a kniha se půjčuje čtenářům. musí existovat jedna a právě jedna instance může existovat jedna nebo žádná instance musí existovat jedna nebo více instancí může existovat jedna, více nebo žádná instance 63

65 Slovní vyjádření kardinality a členství ve vztahu: a) Vztah jedna jedna Čtenář si může půjčit pouze jednu knihu, nemusí si půjčit žádnou knihu. Kniha může být půjčena pouze jednomu čtenáři, nemusí být půjčena žádnému čtenáři. Čtenář si musí půjčit jednu a právě jednu knihu. Kniha může být půjčena pouze jednomu čtenáři, nemusí být půjčena žádnému čtenáři. Čtenář si musí půjčit jednu a právě jednu knihu. Kniha musí být půjčena jednomu a právě jednomu čtenáři. Čtenář si může půjčit pouze jednu knihu, nemusí si půjčit žádnou knihu. Kniha musí být půjčena jednomu a právě jednomu čtenáři. 64

66 b) Vztah jedna více Čtenář si může půjčit více knih, nemusí mít půjčenou žádnou knihu. Kniha může být půjčena pouze jednomu čtenáři, nemusí být půjčena žádnému čtenáři. Čtenář si musí půjčit alespoň jednu knihu, může si půjčit více knih. Kniha musí být půjčena jednomu a právě jednomu čtenáři. Čtenář si musí půjčit alespoň jednu knihu, může si půjčit více knih. Kniha může být půjčena pouze jednomu čtenáři, nemusí být půjčena žádnému čtenáři. Čtenář si může půjčit více knih, nemusí mít půjčenou žádnou knihu. Kniha musí být půjčena jednomu a právě jednomu čtenáři. Čtenář si může půjčit pouze jednu knihu, nemusí si půjčit žádnou knihu. Kniha se nemusí půjčit žádnému čtenáři, může se půjčit jednomu nebo více čtenářům. Čtenář si musí půjčit jednu a právě jednu knihu. Kniha musí být půjčena alespoň jednomu čtenáři, může být půjčena více čtenářům. 65

67 Čtenář si může půjčit pouze jednu knihu, nemusí si půjčit žádnou knihu. Kniha musí být půjčena alespoň jednomu čtenáři, může být půjčena více čtenářům. Čtenář si musí půjčit jednu a právě jednu knihu. Kniha se nemusí půjčit žádnému čtenáři, může se půjčit jednomu nebo více čtenářům. c) Vztah více více Čtenář si může půjčit jednu nebo více knih, nemusí mít půjčenou žádnou knihu. Kniha může být půjčena více čtenářům, nemusí být půjčena žádnému čtenáři. Čtenář si musí půjčit alespoň jednu knihu, může si půjčit více knih. Kniha musí být půjčena alespoň jednomu čtenáři, může být půjčena více čtenářům. Čtenář si musí půjčit alespoň jednu knihu, může si půjčit více knih. Kniha se nemusí půjčit žádnému čtenáři, může se půjčit jednomu nebo více čtenářům. Čtenář si může půjčit jednu nebo více knih, nemusí mít půjčenou žádnou knihu. Kniha musí být půjčena alespoň jednomu čtenáři, může být půjčena více čtenářům. 66

68 4.3.2 Diagram datových toků (DFD) DFD data flow diagram grafický prostředek návrhu a zobrazení funkčního modelu systému funkční model: pohled na realitu jako na souhrn neustále vznikajících různých událostí popis procesů a jejich návazností popis procesů transformace informace a jejich vzájemných vztahů událost stimul reakce událost: to, co nastane a systém na to musí reagovat stimul, který spouští zpracování uvnitř systému typy událostí: příchod dat do systému z okolí (např. zápis nového studenta) událost spojená s časem (např. týdenní kontrola prošlých výpůjčních lhůt) řídící událost (vyžádání reakce řídícím prvkem vně systému např. výkaz práce na daném úkolu) stimul: datový tok sděluje systému, že událost nastala reakce: výstupní datový tok do okolí uložení dat v systému typy reakcí na událost: jedna událost jedna reakce (proces) jedna událost různé reakce (procesy) více událostí stejná reakce (proces) 67

69 Základní prvky a symboly (notace) diagramů datových toků: 1. proces, funkce, transformace (dat), bublina informační procesy (zpracování dat), jimiž je modelováno reálné dění v procesu díky probíhajícím transformacím vznikají nová data 2. terminátor, externí entita počátek datového toku, zdroj dat konec datového toku, místo a účel spotřeby dat 3. data store, zásobník, skladiště dat, datové úložiště data v klidu abstrakce jakékoli formy uložení dat místa k dočasnému uchování dat pro pozdější použití, paměť systému 4. tok dat, datový tok data v pohybu abstrakce jakékoli formy přesunu dat pojmenování dat 68

70 Hierarchický princip tvorby DFD (top-down) kontextový diagram (úroveň -1) úroveň 0 úroveň 1 úroveň specifikace specifikace O specifikace 3 Kontextový diagram: lidé, organizace, systémy, které s modelovaným systémem komunikují data, která systém dostává z okolí a která musí zpracovat data, která systém produkuje datastory sdílené systémem a terminátory (zdroj nebo místo určení dat mimo systém) seznam událostí, na které musí systém reagovat Doporučený postup tvorby DFD: 1. vytvořit kontextový diagram 2. sestavit seznam událostí 3. pro každou událost vytvořit proces (proces = reakce na událost) 4. každý proces pojmenovat podle reakce na událost 5. ke každému procesu doplnit vstupy, výstupy, příp. datastory jaká data proces potřebuje? co je jeho výstupem? 6. kontrola konzistence všechny vstupy a výstupy z kontextového diagramu se musí objevit v DFD 69

71 Kontextový diagram datový tok (externí) DATA STORE 1 datový tok PROCES 1 datový tok TERMINÁTOR 2 TERMINÁTOR 1 Diagram datových toků DATA STORE 2 PROCES 1.1 (externí) DATA STORE 1 Dekomponovaný PROCES 1 PROCES 1.3 PROCES 1.2 PROCES 1.4 TERMINÁTOR 2 TERMINÁTOR 1 70

72 4.4 Objektová metodologie Objekt: termín poprvé použit v programovacím jazyce Simula v 60. letech 20. století Cokoli reálného či abstraktního (věc, entita) s jasně vymezenou rolí v daném kontextu, o čemž uchováváme údaje a metody, které s těmito údaji manipulují. samostatná nedělitelná entita ví o sobě, kdo je zná sám sebe (má atributy naplněné konkrétními hodnotami) dělá něco (má metody) zná možnosti svého použití (přípustné operace) má zodpovědnost umí zpracovávat zprávy a posílat zprávy každý objekt má 3 charakteristiky: stav identita chování (množina povolených přechodů mezi stavy) 71

73 Principy objektově orientovaného přístupu sebeidentifikace objektů objekt sám o sobě ví, kdo je, takže paměť obsahující objekty obsahuje i informace (v objektech) o struktuře jejich obsahu (tj. o atributech a operacích) zapouzdřování objektů (encapsulation) seskupení atributů a operací do struktury objektů, na které se lze dále odkazovat jediným názvem a v nichž operace představují jediný nástroj pro přístup k hodnotám atributů a jejich změnám data jsou chráněna (zapouzdřena zabalena) ve schránce (shell), která obsahuje metody daného objektu. To má za následek omezení možností změn takto chráněných dat. klasifikace (classification) sdružování objektů s podobnými vlastnostmi do tříd dědičnost (inheritance) též označováno jako hierarchie, zobecnění (generalizace) specializace vztah předek (superclass, bázová třída, nadtyp) potomek (subclass, odvozená třída, podtyp) Mechanismus umožňující tvorbu nových objektů (resp. tříd) na základě objektů již existujících. Nově vytvářený objekt dědí všechny vlastnosti objektu již existujícího; nový objekt může navíc přidat vlastnosti nové, nebo může podle potřeby některé z existujících vlastností modifikovat (pozměnit implementaci zděděných metod). polymorfismus (polymorphism) mnohotvárnost různá odezva různých objektů na obdržení stejné zprávy (1 zpráva, 2 různé objekty, 2 různé metody) Postup při objektové analýze 1. identifikace objektů 2. definice atributů a metod objektů 3. identifikace tříd, seskupení objektů do tříd 4. popis vztahů mezi třídami Základní přínosy objektově orientovaného přístupu podpora složitých objektů (complex, composite objects) skládání objektů složitý objekt se skládá z dílčích komponent, což jsou opět objekty možnost opakovaného použití (reuse, reusability) objektů vlastnost, která umožňuje jednou vytvořený objekt použít ve více kontextech (podsystémech, aplikacích apod.) 72

74 4.4.1 UML Unified Modeling Language Standardizovaný jazyk pro tvorbu diagramů v objektově orientovaných modelech (analýze a návrhu) informačních systémů. Není vázán na konkrétní metodiku. Základním účelem UML je umožnit a usnadnit komunikaci (v týmu projektantů, mezi projektantem a zadavatelem). umožňuje modelovat: objekty (entity) třídy atributy operace (funkce) vztahy lexikální elementy (základní prvky jazyka) UML: řetězec ikona (grafický symbol) 2D symbol (ikona s textem) spojka (path) doplňky UML notace package (balíček, balík, svazek, modul, subsystém) logická skupina elementů modulu stereotyp doplnění dalšího významu standardnímu elementu prostřednictvím klíčových slov (keywords) Příklady: závislost (dependency) balíček (package) třída (class) <<include>> <<extend>> <<subsystem>> <<type>> základní součásti UML: UML Notation Guide notace UML (grafická syntaxe) UML Semantics metamodel UML (sémantika) OCL Object Constraint Language textový jazyk pro popis omezení modelů specifikace převodu do výměnných formátů (CORBA IDL, XML DTD) 73

75 Notace UML typy diagramů 1 model lze zobrazit více diagramy, což zajišťuje více pohledů na tentýž systém diagram tříd model statické struktury systému Use Case diagram model funkcionality systému sekvenční diagram model časové dynamiky uvnitř Use Case diagram aktivit model dynamiky jednotlivých Use Case a operací v třídách diagram spolupráce model interakční dynamiky uvnitř Use Case stavový diagram model životního cyklu objektu diagram komponent model komponent a jejich spolupráce diagram nasazení model rozložení komponent při běhu systému Uplatnění principů objektově orientovaného přístupu v UML diagramech 1) skládání objektů agregace / kompozice (objekt MÁ...) extend composite activity package diagram tříd Use Case diagram diagram aktivit všechny modely 2) opakované použití objektů (reuse) include dědičnost (objekt JE...) interface (rozhraní) Use Case diagram diagram tříd diagram tříd 74

76 4.4.2 Use Case diagram Use Case (případ užití, typová činnost, užitná činnost, uživatelský scénář) jeden samostatný prvek funkcionality systému, který je využíván aktorem / poskytuje nějakou hodnotu aktorovi konstrukt popisující, jak se bude systém jevit potenciálním uživatelům popisuje systém z hlediska toho, co s ním uživatelé budou dělat soubor scénářů pro používání systému; každý scénář obsahuje sekvenci (posloupnost) událostí, které v jeho rámci probíhají Actor (aktor, aktér, participant účastník) externí uživatel nebo jiný externí prvek systému (může pouze přijímat informace ze systému nebo dodávat informace do systému) osoba, věc, událost, která je iniciátorem (spouštěčem) pro Use Case nebo z něj má nějaký užitek Asociace Vazba mezi aktorem a Use Case Závislosti «include» vkládání seznam všech dalších případů použití, které zahrnuje ( volá ) daný Use Case umožňuje opakované využití definovaných prvků Příklad: Use Case A zahrnuje Use Case B A <<include>> B «extend» rozšiřování rozšíření Use Case o další kroky (k těm může, ale nemusí pokaždé dojít) Příklad: Use Case B rozšiřuje Use Case A B <<extend>> A 75

77 Příklad: Use Case diagram pro zápis údajů do formuláře 76

78 4.4.3 Diagram tříd zobrazení statické struktury systému prostřednictvím tříd a vztahů mezi nimi využití diagramu tříd: fáze analýzy (konceptuální model) fáze návrhu (návrh atributů a operací) fáze implementace (návrh a tvorba programového kódu) projektovaného systému komponenty: třída, interface (rozhraní), vztah atributy Třída třída (class) sdružuje objekty se společnými vlastnostmi a chováním, lišící se pouze hodnotami svých atributů instancí třídy je objekt operace Vlastnosti správného diagramu tříd je normalizovaný umožňuje flexibilitu umožňuje znovupoužitelnost Konvence UML pro notaci diagramů tříd Název třídy: 1. písmeno velké, vycentrovat, tučné písmo Názvy atributů a operací: 1. písmeno malé, zarovnat doleva Násobnost (multiplicita) vztahů: až více nebo až více právě ,2,3 1 až 3 5,10,20 5, 10 nebo až více 77

79 Typy vztahů mezi třídami asociace obecný sémantický vztah mezi prvky modelu, který specifikuje spojení mezi jejich instancemi asociační (vazební) třída: prvek modelování, který má jak vlastnosti asociace, tak vlastnosti třídy. Může být asociací, která má také vlastnosti třídy, i třídou, která má také vlastnosti asociace. agregace forma asociace, jež vyjadřuje vztah celek část element může přežít svůj kontejner, příp. stát se součástí jiného kontejneru kompozice silnější vazba než agregace zrušením kontejneru automaticky zrušíme i obsažený element (zrušením elementu však nezrušíme celou kompozici); daný element může být součástí právě jednoho kontejneru 78

80 dědičnost (generalizace) hierarchický vztah tříd, v němž třída potomek (subclass, specifický typ) dědí atributy a operace třídy předka (superclass, nadtyp) kromě zděděných charakteristik může mít potomek ještě své specifické vlastnosti zděděné vlastnosti mohou být v potomkovi modifikovány realizace Souhrn všech veřejně přístupných metod dané třídy. Umožňuje vícenásobné využití operací, aniž bychom museli zavádět dědičnost mezi třídami. závislost vztah mezi dvěma elementy modelu, v němž změna jednoho (nezávislého) elementu ovlivní druhý (závislý) element 79

81 Příklad: Diagram tříd pro evidenci studia 80

82 4.4.4 Stavový diagram popis stavů objektu a povolených přechodů mezi těmito stavy popis životního cyklu objektu využití stavového diagramu: popis dynamiky objektu (má-li rozpoznatelné stavy) popis metody (známe-li algoritmus) popis protokolu (včetně protokolu o styku uživatele se systémem) popis systémů pracujících v reálném čase vhodné pro objekty s takovým chováním, které je: o řízené událostmi (event driven) o charakterizováno oddělenými (diskrétními) stavy Na rozdíl od jiných UML diagramů nezobrazuje stavový diagram systém jako celek, ale jen vybrané objekty. stav: hodnota nějakých atributů (tzv. stavové atributy) podmínka nebo situace během existence objektu, při jejímž trvání objekt splňuje nějaké podmínky, provádí nějaké aktivity, nebo čeká na nějakou událost základní konstrukty: začátek konec stav (state) přechod (transition) větvení a spojování (junction) událost (event) podmínka (hlídač) akce (action) event [condition] / action 81

83 4.4.5 Diagram aktivit reprezentace struktury (dynamiky) počítačových a organizačních procesů v systému, zaměřená především na jeho vnitřní chování zobrazení řídících toků (přechodů) mezi akcemi (aktivitami) v systému od počátečního bodu po jeden nebo více koncových bodů; důraz se klade na zobrazení pořadí aktivit. využití diagramu aktivit: modelování průběhu jednotlivých Use Case a operací v třídách modelování podnikových procesů (business process modeling, byznys modelování) workflow základní konstrukty: začátek konec aktivita (činnost, activity, ActionState akční stav) přechod (transition) rozhodování (decision) spojování (merge) větvení (fork) spojování (join, synchronizace) 82

84 5. Řízení a plánování projektu informačního systému 5.1 Projekt a) plán (návrh) rozsáhlé jednorázové operace b) samotná rozsáhlá jednorázová operace (její průběh a řízení) charakteristiky projektu: unikátnost (neopakovatelnost) přesně stanovený cíl stanovená omezení (čas, zdroje, náklady) zpravidla obsahuje riziko neúspěchu projekt (projektování) informačního systému: Řízený proces vyvolaný za účelem pořízení nebo adaptace (změny) informačního systému. Obvykle se člení na etapy (např. analýza požadavků, návrh systému, implementace, dokumentace, zajištění kvality), obvykle končí předáním do rutinního provozu. tzv. trojimperativ řízení projektu (triple constraint) autor: Milton D. Rosenau klíčové projektové cíle, kterých musí být dosaženo současně: 1. CO specifikace provedení co se má udělat 2. KDY časový plán do kdy se to má udělat 3. ZA KOLIK finanční rozpočet za kolik se to má udělat úspěšný projekt je ten, který dosáhl stanoveného cíle v plánovaném čase s plánovanými náklady s přidělenými zdroji bez negativních dopadů Projektování = etapy + kontrolní body + dokumentace etapy (fáze, aktivity, úseky): skládají se z jednotlivých činností (kroků) pro každou etapu definujeme: obsah a cíl (PROČ) produkty (CO) vstupy a výstupy (závislosti) techniky (JAK) metriky (KOLIK, KDY, kvalita) role, odpovědnost (KDO) 83

85 kontrolní body koncové body nějakých aktivit (činností) následují po každé etapě rozhoduje se, zda pokračovat v projektu forma: checkpoints kontrolní body milestones milníky (dílčí cíle) deliverable k předání : zřetelný (hmatatelný) výstup nějaké aktivity (činnosti) dokumentace prostředek vyjádření (prezentace) projektu každá etapa se zahajuje a končí dokumentem typy dokumentace: uživatelská (manuály, návody, help) pro koncového uživatele (k používání IS) pro administrátora (k provozování IS) projekční (technická dokumentace modely, specifikace dat, architektura systému) manažerská (smlouvy, plány projektu, záznamy z porad, kontrol a oponentur) Typy projektů informačních systémů možnost různé kategorizace za použití různých úhlů pohledu na projekt (jaký systém, co, jak, pro koho se projektuje) JAKÝ systém se projektuje? 1. data intensive spíše statické systémy s velkým objemem údajů 2. software intensive spíše dynamické systémy s velkým množstvím procesů (operací), často probíhajících v reálném čase (real-time applications) CO se projektuje? 1. celý informační systém 2. část informačního systému např. HW síťové prvky, SW nový modul aplikačního softwaru 3. služba spojená s informačním systémem, resp. její využití např. outsourcing, ASP Application Service Providing poskytování aplikačních služeb 84

86 JAK se projektuje? 1. návrh zcela nového informačního systému vývoj nového softwaru instalace hotového softwarového produktu ( krabicový software) instalace a uživatelské přizpůsobení (customizace) hotového softwarového produktu (např. ERP, automatizovaný knihovní systém) sestavení nové aplikace z hotových komponent (systémová integrace) 2. změny v již existujícím informačním systému rozšíření systému reengineering, redesign, refaktoring BPR business process reengineering (radikální změna podnikových procesů) Předpokladem úspěchu projektu informačního systému je definování a analýza podnikových procesů, jež mají být informačním systémem podporovány. Výsledkem této analýzy je často zjištění, že některé procesy jsou prováděny neefektivně, redundantně či dokonce nesprávně. Projekt informačního systému může být proto spojen i s projektem úprav reálných firemních procesů. legacy system: funkční systém zděděný po předchůdcích, zpravidla založený na již překonané technologii a již dále nevyvíjený řešené problémy: integrace do stávajícího informačního systému nahrazení novým systémem PRO KOHO se projektuje? (kdo je zákazník, příp. koncový uživatel?) 1. interní projekt výsledek práce je určen pro vlastní firmu 2. projekt na zakázku vztah dodavatel zadavatel 3. projekt pro volný trh zadavatel: vlastní firma 4. projekt jako subdodávka komplexního řešení zadavatel: systémový integrátor 85

87 CHAOS Nejrozsáhlejší výzkumný projekt v historii IT probíhá nepřetržitě od r Zaměření: úspěšnost projektů IT. Realizace projektu: Standish Group International, Inc. poradenská a konzultační firma specializovaná na oblast informačních technologií, zejména na efektivnost investic do tohoto oboru. Rozsah a metodika průzkumu: cca IT projektů realizovaných v USA rozhovory a workshopy s IT manažery a s projektovými manažery (cca 400/rok) Výsledky: Succeeded projekt byl ukončen v plánovaném čase, s plánovanými náklady a byly splněny plánované cíle Challenged projekt byl dokončen s použitelnými výsledky, ale nebyl dodržen časový plán, byly překročeny náklady a nejsou splněny všechny požadované funkcionality Failed projekt byl buď předčasně ukončen nebo jeho výsledky nebyly nikdy implementovány 86