Stáhnout prezentaci
Prezentace se nahrává, počkejte prosím
1
Základní pojmy z teorie systému a vývoje IS
Doc. Pančík pre BIVŠ Adaptované z kníh POUR 2006,2009, TVRDÍKOVÁ 2008 a BASL 2008
2
STRUČNÝ PŘEHLED POZNATKŮ TEORIE SYSTÉMŮ
Obecná teorie systémů vznikla jako výsledek formalizace systémového přístupu k řešení složitých komplexních problémů systémového charakteru. Její základy byly položeny koncem 40 – tých let 20. století v pracech L. von Bertalanffyho. Ten se opíral o rozbor netechnických systémů a při uplatňování poznatků speciálních, zvláště biologických vědních disciplín, se poprvé v historii vědy pokusil o odvození obecných zákonitostí, na jejichž základě je možné integrovat postupy jednotlivých vědních disciplín k dosažení komplexního řešení.
3
Pro obecnou teorii systémů je charakteristické, že se nezabývá konkrétními objekty, ale jejím předmětem je abstraktní systém vzniklý zobecněním vlastností různých konkrétních objektů, pojatých jako systémy. Lze řící, že právě univerzalita obecné teorie systémů vytvořila teoretické předpoklady pro postupné uplatnění výpočetní techniky. Díky právě této skutečnosti pronikly pojmy systém a systémový do povědomí široké veřejnosti.
4
Pojem systém je třeba spojovat s vědní disciplínou zvanou Systémové inženýrství.
Systémové inženýrství se zabývá analýzou, projektováním, provozováním a řízením rozsáhlých, složitých systémů, technického i netechnického charakteru.
5
Systémové úlohy a způsoby jejich řešení se týkaly tří základních etap:
Začátky systémového inženýrství byly spojeny s návrhy a realizací tzv. velkých programů (počítače, automatizace, jaderná energetika, výzkum kosmického prostoru, nové chemické materiály apod.) Systémové úlohy a způsoby jejich řešení se týkaly tří základních etap: návrh (výzkum, vývoj, projekt) realizace (výroba, instalace, zavedení) provoz systému
6
V USA a dalších vyspělých zemích se systémové inženýrství v letech 1945 až 1960 soustřeďovalo na tzv. „tvrdé“ (technické) systémy. Jednalo se v podstatě o řízení procesů velkého rozsahu k dosažení daného cíle, přičemž většina z nich byla značně náročná z hlediska materiálů, energií, nákladů i času.
7
„Tvrdé“ systémy vyžadují dané, předem definované cíle a jsou určeny pro provoz v přesně vymezeném prostředí. Mechanistické chápání rovnováhy v systému navozuje jednoduchou představu rovnovážného stavu, který lze popsat přesně vyjádřenými vztahy lineárního řádu. Takový řád pak poskytuje relativně snadnou a jistou schopnost predikce, návrhu a řízení ( ve smyslu kontroly).
8
V případě tvorby či řízení komplexnějších a přirozených systémů, ve kterých záleží na poznání skutečné podstaty systému, není výše uvedený přístup vhodný. Později se těžiště systémového inženýrství přesunulo na řešení „měkkých“ (sociotechnických, socio-ekonomicko-technických) systémů, kdy vedle projektování nabývala na významu úspěšná implementace s ohledem na havarijní situace, lidský faktor apod.
9
Soft System Methodology (SSM)
Metodologie „měkkých“ systémů představuje výrazný posun k prohloubení možnosti aplikace systémových přístupů k systémům s výskytem lidského prvku tj. např. systémům sociálním ekologickým, informačním apod. Soft Systém Methodology (SSM) je spojována se jménem P. Checklanda
10
Soft System Methodology (SSM)
Systémový přístup představuje vnímání problému nikoliv vytrženě z reality, ale v souvislostech, a to jak vnějších, tak i vnitřních. Systémové myšlení se pojí s metodologií tvrdých a měkkých systémů.
11
Soft System Methodology (SSM)
Zásadní přínos metodologie měkkých systémů spočívá v přístupu k samotné systémové abstrakci, tj. k systému samotnému. V důsledku působení člověka jako individuality, předpokládá diferencované pohledy na problém a taktéž odráží různé zájmy. Bere v úvahu i neurčitost spojovanou jednak se subjektivní interpretací informace a vágnost jazyka.
12
Soft System Methodology (SSM)
od rovnováhy k evoluci od stability k nestabilitě od hledání ideálního stavu k posloupnosti přechodných stavů od uzavřených systémů k systémům otevřeným od sociální mechaniky k sociální dynamice od determinismu ke stochastice od skutečnosti k možnosti od bilancování existujícího ke tvorbě potenciálů od analýzy rozdílů k integraci podobného od hierarchického vnějšího řízení k vnitřnímu samořízení a samoorganizaci od lineárního programování k obecnému principu optimality od přesného myšlení k přibližnému usuzování
13
Taxonomie (klasifikace) systémů
Původní naděje, že systémová věda nalezne obecné zákonitosti, podle kterých bude možné alespoň relativně snadno systémy navrhovat a řídit, se ukázala jako nereálná. V současnosti se v systémových disciplínách předpokládá, že existují různé typy (třídy) systémů. Jednu z možných klasifikací navrhl P. Checkland: Přirozené systémy Navrhované (umělé) systémy Systémy lidských aktivit Transcendentální systémy
14
Přirozené systémy jsou základem okolního světa. Příkladem mohou být systémy fyzikální a biologické. Vytvářejí dvě velké podskupiny – systémy neživé a systémy živé. Především živé systémy vykazují účelné chování, a proto se také někdy označují jako účelné systémy. Chováním rozumíme reakci systému nebo jeho prvků na vstupní podněty.
15
Navrhované systémy jsou uměle vytvářeny člověkem, a to s předem daným a většinou zřetelně vymezeným záměrem. Může jít o systémy fyzikální ( vodovodní síť) nebo abstraktní (soustava rovnic) Na rozdíl od účelných systémů bývají označovány jako systémy záměrné. Jedná se tedy o „systémy se záměrem“, který je jim dán z vnějšku.
16
Systémy lidských aktivit
jsou to systémy, ve kterých je rozhodujícím prvkem člověk (přirozené systémy). Vstupují do vzájemných interakcí, jednají s konkrétními záměry a pro jejich činnosti. Příkladem mohou být tzv. sociálně kulturní systémy, ve kterých se různou měrou prolínají vždy systémy přirozené a systémy navrhované.
17
Transcendentální systémy
jedná se o systémy, které přesahují hranice lidského chápání, lidské vědomosti a zkušenosti.
18
Pojetí systému, základní pojmy
Pojetí systému můžeme chápat jako myšlenkovou abstrakci na zkoumaném reálném objektu. Systémem rozumíme účelově definovanou množinu prvků a vazeb mezi nimi, jež vykazují jako celek určité vlastnosti respektive chování. Prvek chápeme jako nedělitelnou část celku, vazbu jako přímé (nezprostředkované) spojení mezi dvěma prvky nebo jejich množinami.
19
Pojetí systému, základní pojmy
Systém je možno definovat také jako Konečnou množinu prvků systému z hlediska účelu dále nedělitelných (vzhledem k rozlišovací úrovni) Konečnou množinu vazeb mezi těmito prvky Konečnou množinu parametrů systému tj. kvantifikovatelných veličin sloužících k ohodnocení prvků a vazeb Konečnou množinu účelových funkcí prvků a vazeb systému tj. důvodů jejich existence v rámci systému Cílovou funkci systému tj. žádoucí stav, cíl, kterého chceme dosáhnout
20
Podstatnou součástí systému je jeho struktura, tj
Podstatnou součástí systému je jeho struktura, tj. skladba nebo uspořádání prvků a vazeb. Strukturu systému je možno zobrazit pomocí orientovaného grafu , jehož vrcholy představují prvky systému, hrany jsou pak vazby systému.
21
Orientovaný graf 2 5 1 7 4 6 3
22
Grafovou strukturu je možno převést do maticové podoby struktury systému tzv. matice sousednosti (obr2). Obr.2 Matice sousednosti
23
Subsystémem rozumíme tu část systému, jejíž prvky vykazují vůči sobě navzájem více interakcí než k ostatním prvkům systému a plní relativně autonomní funkce v systému. Subsystém tvoří uvnitř systému relativně samostatný a uzavřený celek. Vymezení subsystémů závisí na tzv. rozlišovací úrovni.
24
Okolí systému je množina vzájemně se ovlivňujících prvků, které nejsou prvky daného systému a z nichž pouze některé jsou v přímém vztahu se systémem. Tyto prvky tvoří tzv. podstatné okolí systému. Podstatné okolí systému je účelově definovaná množina prvků okolí systému, které jsou prostřednictvím vnějších vazeb systému (vstupů a výstupů) v bezprostřední interakci s hraničními prvky systému. Přitom změna v libovolném prvku podstatného okolí může vyvolat změnu stavu systému.
25
Prvek systému – taková část systému, která tvoří na dané rozlišovací úrovni dále nedělitelný celek, jehož strukturu nechceme nebo nemůžeme rozlišit. Vnitřní prvek systému je spojen vazbou jen s prvky daného systému. Hraniční prvek systému je prvek systému, jehož některá z vazeb zprostředkovává interakci systému s jeho podstatným okolím.
26
Vstup systému je zprostředkován vazbou okolí – systém
Vstup systému je zprostředkován vazbou okolí – systém. Jejím prostřednictvím působí podstatné okolí na systém pomocí vstupních parametrů - podnětů. Výstup systému je zprostředkován vazbou systém – okolí. Jejím prostřednictvím působí systém na podstatné okolí pomocí výstupních parametrů. Jejich souhrn se nazývá reakce nebo odezva systému.
27
Metasystém – abstraktní systém
Metasystém – abstraktní systém. Jeho prvky jsou vlastnosti výchozího zkoumaného systému uspořádané do vzájemných souvislostí. Jedná se o vyšší stupeň abstrakce, tzv. zavedení systému na systému. Uzavřený systém – systém pro který není definováno podstatné okolí tj. nemá definovánu žádnou vnější vazbu (vstup, výstup), realizují se pouze vnitřní vazby. Otevřený systém – má definováno podstatné okolí, má definovány vnější vazby (alespoň jeden vstup a výstup). Ve vztahu tohoto systému k jeho okolí je možno zkoumat chování, vlastnosti a funkce systému.
28
Statický systém – systém, jehož stav se v čase nemění.
Dynamický systém – systém, jehož stav se v čase mění. Systém se vyvíjí vzhledem ke své cílové funkci.
29
Deterministický systém – otevřený systém, jehož chování je jednoznačně určeno stavem systému a podněty působící na vstupech systému. Stochastický systém – otevřený systém, jehož chování může při témže stavu a stejných podnětech na vstupech systému vykazovat více variant chování v závislosti na pravděpodobnostech výskytu těchto variant. Učící se systém – systém, který na základě rozboru opakovaných podnětů a svých dosavadních reakcí se snaží dosáhnout účelnějšího chování. Samoopravující se systém – systém, který má schopnost nahradit některé své už nevyhovující prvky nebo vazby novými buďto z okolí systému nebo z rezerv uvnitř systému.
30
Systém s cílovým chováním – systém, který se chová tak, aby svými reakcemi na podněty směřoval k dosažení požadovaného cíle a požadovaného stavu okolí. Integrovaný systém – systém, u něhož se dosáhlo vysokého stupně konzistence prvků a vazeb, protože byly odstraněny veškeré redundantní prvky (ve smyslu vícekrát se opakující) a vazby respektive byly doplněny chybějící prvky a vazby pro zajištění konzistence systému. Stav systému – množina podmínek respektive vlastností, které je možno v systému v daném časovém okamžiku rozpoznat a jež jsou spolu se znalostí vstupů systému postačující informací pro určení výstupů systému.
31
Trajektorie stavů systému – posloupnost stavů systému, která charakterizuje změny stavu systému v závislosti na čase. (Stavová trajektorie vytváří křivky ve fázovém prostoru). Dynamičnost systému – chování systému závislé na čase. Je reprezentováno stavovou trajektorií, která je závislá na zadání cílové funkce. Přitom se může měnit struktura systému jak co do kvality (změna vlastností stávajících prvků a vazeb) tak i do kvantity (vznik nových a zánik původních vazeb a prvků v systému).
32
Rovnováha systému – stav, kdy struktura systému se už nemění bez ohledu na přijímané vstupy nebo když transformační proces probíhá ve vymezených mezích. Velmi relativní, protože každý systém, který dosáhl rovnovážného stavu, v něm může setrvat pouze po určitou dobu. Jestliže počet vstupů přesáhne únosnou míru, systém je vychýlen z rovnováhy. Může dojít i k jeho zániku anebo se opět stává dynamickým systémem směřujícím k opětovnému dosažení rovnovážného stavu. Stabilita systému – schopnost systému navracet se do rovnovážného stavu respektive pokračovat v trajektorii vymezené svojí cílovou funkcí.
33
ARCHITEKTURA INFORMAČNÍCH SYSTÉMŮ
Informační systém lze definovat jako soubor lidí, metod a technických prostředků, zajišťujících sběr, přenos, uchování, zpracování a prezentaci dat s cílem tvorby a poskytování informací dle potřeb příjemců informací činných v systémech řízení. Tato definice zahrnuje člověka jako součást informačního systému a zmiňuje se o míře potřeby příjemců informací.
34
Informační systém Další definice popisuje informační systém z jiného pohledu a zní: Informační systém je obecně podpůrný systém pro systém řízení.Jestliže chceme projektovat systém řízení jako takový, musíme znát, jaké jsou cíle a řešit informační systém tak, aby tyto cíle podporoval.
35
Komponenty informačního systému
Informační systém se skládá z následujících komponent: Technické prostředky (hardware) – počítačové systémy různého druhu a velikosti, doplněné o potřebné periferní jednotky, které jsou v případě potřeby propojeny prostřednictvím počítačové sítě a napojeny na diskový subsystém pro práci s velkými objemy dat. Programové prostředky (software) – tvořené systémovými programy řídícími chod počítače, efektivní práci s daty a komunikaci počítačového systému s reálným světem a programy aplikačními řešícími určité třídy úloh určitých tříd uživatelů.
36
Komponenty informačního systému
Organizační prostředky (orgware) tvořené souborem nařízení a pravidel definujících provozování a využívání informačního systému a informačních technologií. Lidská složka (peopleware) – řešení otázky adaptace a účinného fungování člověka v počítačovém prostředí, do kterého je vřazen Reálný svět (informační zdroje, legislativa, normy) – kontext informačního systému
37
Integrovaný systém Velmi často se stává, že komplikovaný informační systém v podniku je budován zcela živelně, bez jakékoliv architektonické představy. Do podniku se nakupuje různorodý hardware, základní a aplikační software od různých dodavatelů tak, jak okamžitá potřeba jednotlivých uživatelů ukáže a nikdo se nestará o to, zda všechny komponenty budou navzájem vytvářet integrovaný systém. Pro zajištění integrace, průhlednosti a jednoduchosti IS/IT je třeba, aby architektura IS/IT podporovala následující vlastnosti informačního systému podniku:
38
Vlastnosti informačního systému podniku
Strategická orientace – informační systém (IF) musí být schopen podporovat dosažení strategických cílů podniku Adekvátní funkční spektrum – IF musí pokrývat všechny uživatelské požadavky na funkce IS/IT, které jsou ve shodě se strategickými cíli podniku
39
Vlastnosti informačního systému podniku
Integrovanost – IS/IT musí být integrován z hlediska funkčního, datového, softwarového, hardwarového a z hlediska uživatelského rozhraní: funkce IS se nesmějí překrývat a nesmí být ve vzájemném rozporu jednou uložená data musí být dostupná všem aplikacím, které je vyžadují jednotlivé softwarové komponenty musí být navzájem provázány, musí respektovat tytéž technologické standardy a musí být dostupné všem oprávněným uživatelům hardwarové komponenty musí být navzájem propojitelné v rámci integrované počítačové sítě podniku uživatelský interface aplikací musí být vytvořen na základě shodných standardů
40
Vlastnosti informačního systému podniku
Otevřenost – systém musí být schopen postupně přijímat další nové technické a softwarové komponenty, datové zdroje apod. aniž by se narušila jeho provozuschopnost Jednoduchost – systém musí být relativně snadno pochopitelný a průhledný pro uživatelskou sféru Flexibilita – systém musí v provozu pružně reagovat na nové požadavky ze strany uživatelů a to bez zásahu do programového řešení aplikace (parametričnost)
41
Vlastnosti informačního systému podniku
Udržovatelnost – systém musí být vytvořen pomocí specifického vývojového prostředí a řádně zdokumentován, aby případné ůpravy programů byly relativně snadné a přijatelně nákladné Efektivní provozuschopnost – systém musí zajistit přijatelnou dobu odezvy funkční spolehlivost bezpečnost dat před výpadky systému ochranu dat před neautorizovaným užitím
42
Proč je přikládán architekturám IS/IT takový význam.
Architektura vytváří relativně stabilní rámec řešení IS/IT, do něhož jsou v průběhu vývoje IS postupně začleňovány jednotlivé aplikace a další komponenty podle předem připraveného plánu a podle technologických, ekonomických a dalších možností, ale s už předem definovanými základními vazbami na ostatní části systému. Architektura IS/IT je významným komunikačním prostředkem mezi vedením podniku a projektanty při formulaci základních představ o IS/IT a o prioritách řešení. Architektura zajišťuje vzájemné porozumění investorů, uživatelů a řešitelů ohledně časové implementace jednotlivých aplikací, dat a rozhraní. Pokud je architektura navržena jako dostatečně otevřená, předvídající budoucí změny, zajišťuje stabilitu vývoje IS. (Nevyhovuje-li některá z komponent systému, musí být umožněna její náhrada jinou, vyhovující danému účelu).
43
Globální a dílčí architektury
Metodik pro návrh a vývoj IS/IT je celá řada, ale v zásadě respektují tzv. globální a dílčí architekturu. Za globální architekturu považujeme hrubý návrh celého IS/IT, dílčí architektury jsou pak detailnější návrhy IS/IT z hlediska různých pohledů na systém
44
Funkční architektura – představuje návrh hierarchie funkcí IS/IT
Procesní architektura – představuje návrh procesů probíhajících v podniku tj. souhrn činností, které reagují na určitou událost (datovou, časovou apod.) Datová architektura – je návrhem datové základny podniku (datových objektů a jejich vazeb, databázových tabulek a jejich fyzického uložení atd.) Technologická architektura – popisuje technologické řešení IS/IT (klient – server architektura, tříúrovňová architektura apod., standardy uživatelského rozhraní …) Softwarová architektura – určuje z jakých softwarových modulů bude systém postaven a jaké jsou mezi nimi vzájemné vazby Hardwarová architektura – určuje typy, počty a vzájemné vazby hardwarových komponent
45
Globální architektura IS/IT
Globální architekturu je možno velmi dobře znázornit graficky s doprovodným slovním popisem. Základem grafického schématu jsou jednotlivé stavební bloky IS, z nichž každý představuje jednu aplikaci (resp. skupinu aplikací) IS a reprezentuje současně požadované funkce aplikace, datovou základnu, software, který zajišťuje aplikaci, základní software a hardware, které jsou technologickým prostředím aplikace.
46
Charaketer jednotlivý stavební blok IS:
věcná orientace (nákup, prodej, účetnictví) vztah k úrovni řízení podniku (operativní, taktické, strategické) metody projekce a provozu daných aplikací ( řízení oběhu dokumentu ve firmě, aplikace na podporu řízení a rozhodování apod.) stupeň úrovně automatizovaných řešení (od rozličných individuálních řešení na míru k postupné standardizaci funkcí, dat i technologií)
47
technologický princip, na kterém je řešení příslušného bloku založeno (multidimenzionální tabulky, datové sklady apod.) parametry softwarových produktů na trhu, které danou problematiku řeší
48
Základní stavební bloky architektury IS/IT
49
Základní stavební bloky architektury IS/IT
TPS -Transaction Processing System je blok zaměřený na podporu hlavní činnosti podniku na operativnl úrovni. Tento blok je nejspecifičtějším blokem celkové architektury. Je závislý na charakteru podniku (výrobní, obchodní, dopravní, zemědělský, banka, pojišťovna atd.). U výrobních podniků je dále závislý na tom, zda výroba má charakter kusové výroby, hromadné výroby nebo kontinuální výroby, u obchodních podniků je závislý na typu prodávaných komodit, na teritoriích nákupu a prodeje apod.
50
Základní stavební bloky architektury IS/IT
U výrobních podniků jsou TPS založeny na tzv. CIM (Computer Integrated Manufacturing) koncepci. Základním principem této koncepce je integrace výrobních procesů ve dvou základních Iiniích: výrobkové - návrh výrobku, návrh technologie výroby, návrh NC programů zakázkové - přijetí zakázky, harmonogram realizace zakázky, plánování materiálových.a kapacitních požadavků, uvolnění zakázky do výroby, její realizace, expedice hotových výrobků, nákladové kalkulace atd..
51
Základní stavební bloky architektury IS/IT
MIS -Management Information System je blok orientovaný na řízení podniku na taktické úrovni, která zahrnuje ekonomická, organizační a obchodní hlediska. Struktura bloku je značně standardizovaná a je velmi podobná i pro podniky různých typů. Koncepce MIS je založena na integraci procesů ve třech základních Iiniích obchodně-logistické - nákup, prodej, materiálně-technické zásobování (MTZ), sklady a přeprava. finančně-účetní - hlavní kniha, závazky , pohledávky , controlling (nákladové účetnictví), majetek, pokladna, práce a mzdy (PAM) a finanční řízení průřezové – mají celopodnikový charakter a řadíme mezi ně organizaci a správu, řízení lidských zdrojů (personalistiku), marketing, legislativu a jakost.
52
Základní stavební bloky architektury IS/IT
EIS -Executive Information System je blok orientovaný na strategické řízení podniku. Aplikace vytvořené pro řízení podniku na vrcholové úrovni získávají data z ostatních aplikací podnikového informačního systému (z TPS a z MIS) a dále z extemích informačních zdrojů (bankovní informace, burzovní informace, informace o průzkumech trhu, informace o nových patentech, informace tiskových agentur atd.). Tato data agregují, vytvářejí časové řady a vzájemné vazby. Výstupy z EIS pak slouží jako podklady pro strategická rozhodnutí členů vrcholového managementu.
53
Datové hlediska architektury IS
Z datového hlediska se aplikace EIS od aplikací TPS a MIS dále Iiší tím, že jsou zaměřeny na daleko delší časový úsek, a to jak do minulosti, tak do budoucnosti. Aplikace TPS a MIS udržují především data vypovídající o právě aktuálním stavu intemích a extemích podnikových procesů (aktuální objednávky, aktuální stav skladových zásob apod.). Co se týče historických dat udržují pouze ty, které mohou mít vztah k současnosti. (Například data realizovaného obchodního případu jsou v MIS udržována po dobu záruční doby, která byla v obchodním případu zákazníkovi poskytnuta, aby v případě reklamace bylo možné se k obchodnímu případu vrátit.)
54
Datové hlediska architektury IS
Naproti tomu aplikace EIS udržují v agregovaném stavu historická data i mnoho Iet stará, aby bylo možné vysledovat vývojové tendence. Další odlišností je, že EIS uchovávají i několik údajů o tomtéž objektu vzniklých v různém čase. Tyto údaje umožňují například vrcholovému managementu podniku hodnotit kvalitu plánovací a řídící činnosti ředitele příslušné obchodní skupiny.
55
Datové hlediska architektury IS
Pro tvorbu aplikací EIS se využívají specializované softwarové nástroje, které pracují tzv OLAP technologií (On-Line Analytical Processing). Jejím základem je uložení dat v multidimenzionální tabulce. První dimenzí jsou obvykle sledované ekonomické ukazatele (obrat, zisk, počet pracovníků atd.), druhá dimenze je časová a další dimenze představují další zvolené pohledy managementu na sledovanou realitu (např. organizační struktura, komoditní skladba, teritorium prodeje, typy zákazníků atd.). Management pak může zkoumat např. vývoj zisku podle jednotlivých závodů podniku, podle jednotlivých výrobků, podle teritoria prodeje, podle typů zákazníků, případně podle kombinace těchto hledisek.
56
OIS -Office Information System
OIS -Office Information System je blok orientovaný na podporu kancelářských prací a na podporu týmové práce. Do OIS se obvykle zahrnují následující aplikace: textový editor, elektronické publikování tabulkový procesor prezentační program pro tvorbu obrázků, schémat a prezentací plánovaci kalendář sledování úkolů evidence odešlé a došlé pošty elektronická pošta elektronické diskusní skupiny videokonference tvorba a prohlížení WWW stránek řízení týmové práce na dokumentu archiv dokumentů workflow - řízení toků dokumentů podpora řízení projektů (časový plán projektu, plán a skutečnost čerpání jednotlivých zdrojů atd.).
57
EDI -Electronic Data Interchange -je blok zajišťující komunikace podniku s jeho významným okolím, tj. se zákazníky , dodavateli, bankami, státními institucemi, poskytovateli informačních služeb atd. Role tohoto bloku v rámci globální architektury IS/lT podniku roste spolu se stále větším prosazováním aplikací využívající Intemet a aplikací pro standardizovanou výměnu dat mezi obchodními partnery ( zejména EDIFACT).
58
Příklad stavebních bloků IS/IT výrobního podniku
59
PRÍČINY NEÚSPECHU IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ
Příčinou je jednak různorodost ekonomických subjektů, jednak fakt, že tempo vývoje informačních systémů a informačních technologií (IS/IT) je vysoké a udržet přehled v této oblasti je obtížné. IS firem nepodporují často jejich strategické cíle jako celek, ale orientují se na podporu dílčích zájmů jednotlivých částí firmy, které bývají v rozporu s globální strategii firmy nebo instituce. Dalším důvodem je, že IS se v mnohých firmách rozvíjejí bez dlouhodobé koncepce, což často vede k rozpadu jejich celistvosti (konzistence a integrity) a k jejich neschopnosti reagovat na změny v okolním prostředí. Závažné je také to, že IS se budují na základě okamžitých nároků jednotlivých pracovníků firmy namísto podle předem jasně definovaných cílů této organizace.
60
Strategický význam IS pro budoucnost firmy
Strategické cíle řízení firmy jsou předurčeny podnikovou vizí a jsou specifikovány v dokumentu – globální strategii. Sestavení dokumentu výstižně popisujícího podnikovou strategii není jednoduchá záležitost. Je třeba odhadnout vývoj tržního segmentu, ve kterém firma působí (po stránce technologické, inovační, investiční, prodejní, cenové přiměřenosti, včasnosti, funkčnosti produktů nebo služeb, požadované kvality, nároků na servis, možnosti konkurence, makroekonomického klimatu, legislativní a politické stability apod.). Obtížnější je pak praktická implementace, průběžná realizace a hodnocení naplňování strategických cílů. Často bývá těžké propojit strategické s taktickým a operativním do jednoho integrovaného celku.
61
Specifika zavádění informačních systémů
Prvním výrazným rysem je krátká doba vývoje informačních technologií a velmi rychlý vývoj v tomto oboru ve srovnání s tradičními jako např. strojírenstvím stavebnictvím. Aplikace jsou rok od roku dokonalejší a nutí uživatele měnit styl práce. Kromě informačních technologií se stále rychleji mění i podnikatelské prostředí a tím se mění i požadavky uživatelů. Celé pracovní prostředí je proto velmi nestabilní a vybrat patřičné komponenty IS je velmi nesnadné.
62
Specifika zavádění informačních systémů
Dalším specifikem je úzká návaznost jednotlivých postupových fází návrhu a realizace v projektech informačních systémů s informačními technologiemi. U ostatních odvětví tvoří často návrh a realizace samostatné projekty. Projekty IS jsou většinou velmi složité. Navrhovaný IS je modelem určitého výseku reálného světa s jistými zjednodušujícími omezeními, které však nesmějí být natolik masivní, aby nedošlo ke zkreslení objektivní reality.
63
Specifika zavádění informačních systémů
Projekty IS/IT zahrnují jak vývojové, tak i realizační (programátorské) práce, takže jsou obtížně řiditelné a je na často kladeno množství navzájem protichůdných požadavků. Neustálý prudký vývoj informačních technologií přináší s sebou i nutnost nových pracovních postupů a tím i vyšší požadavky na kvalifikaci vývojářů. Průběžné doškolování těchto pracovníků se stává nezbytností.
64
Softwarové inženýrství.
Požadavek zvýšení efektivity tvorby programového vybavení vedl ke vzniku samostatné vědní disciplíny zvané softwarové inženýrství. Jedná se o aplikování inženýrských přístupů do oblasti tvorby softwaru, systematický přístup k jeho vývoji, implementaci a údržbě. Skládá se z metod, technik a nástrojů, jejichž používání se v praxi ukázalo jako efektivní.
65
Softwarové inženýrství vychází z pěti principů:
Princip modelování (využívání grafických zobrazovacích metod – diagramy toku dat, procesní diagramy, diagramy datových struktur apod.) Princip iterace (postupné zdokonalování systému) Princip strukturování (postupný hierarchický rozklad celého komplexního problému na menší celky, které jsou zvládnutelné v podmínkách omezených technických i lidských zdrojů v rozumném čase). Princip životního cyklu (komplexní zachycení celého procesu vývoje, implementace a provozování IS) Princip automatizace tj. počítačová podpora po celou dobu životního cyklu (projektové databáze, využívání grafických zobrazovacích technik, generátory programů, nástroje CASE apod.)
66
Metodologie vývoje informačních systemu
Metodologie (metodika) je doporučený souhrn etap, přístupů, zásad, postupů, pravidel, dokumentů, řízení, metod, technik a nástrojů pro tvůrce informačních systémů, který pokrývá celý životní cyklus informačních systémů.
67
Metodologie vývoje informačních systemu
Příkladem může být Standard SSADM (Structured Systém Analysis and Design Method) podporovaný britskou vládou Standard SDM (Systém Development Methodology) francouzsko-nizozemské firmy Cap Gemini Pandata Objektově orientovaná metodologie používaná společností General Electric Metodologie System Engineering firmy LBMS Metodologie Euromethod podporovaná evropským společenstvím
68
Metodologie vývoje informačních systemu
Jednotlivé metodiky víceméně shodně pokrývají životní cyklus projektu, navzájem se liší převážně ve větší či menší míře detailnosti.
69
Metodologie vývoje informačních systemu
70
Metodologie vývoje informačních systemu
Princip tří architektur je abstraktní pohled na informační systém jako model reality. Při návrhu informačního systému se používají tři, vzájemně na sebe navazující modely a to v pořadí Konceptuální model Technologický model Implementační model
71
Konceptuální model Konceptuální modelování (neboli konceptuální schéma) představuje nejvyšší míru abstrakce. Popisuje pouze obsah systému, bez ohledu na konkrétní formy jeho realizace. Při vytváření konceptuálního schématu získává analytik informace od budoucího uživatele systému diskusí o potřebných datech systému. Při tomto rozhovoru si vytváří obraz o nutných datech a jejich vazbách a tím vytváří intuitivně konceptuální datové schéma popisované reality.
72
Konceptuální model Konceptuální schéma je implementačně nezávislé a slouží především pro: Lepší pochopení z jakých částí se systém skládá Lepší pochopení vztahů mezi částmi systému Lepší komunikaci mezi analytikem a uživatelem a mezi analytikem a programátorem Je podkladem pro návrh datové základny na technologické a implementační úrovni Je prostředkem pro dokumentaci existující datové základny Důležitou vlastností konceptuálního schématu je jeho vícenásobná použitelnost a dále fakt, že velmi pomalu zastarává.
73
Technologický model vychází z konceptuálního modelu, popisuje způsob realizace systému v termínech jisté třídy technologického prostředí (relační, hierarchické, síťové nebo objektově orientované datové struktury).
74
Implementační model vychází z technologického modelu, jedná se o popis vlastní realizace systému v konkrétním implementačním prostředí (hardware, software, operační systém apod.)
75
Základní etapy analýzy a vývoje informačních systémů
Proces vývoje a provozu informačního systému (IS) je spojen s řadou krizových situací a problémů. Z těchto důvodů se jeví být vhodné jeho rozdělení do etap, aby se lépe řídil, lépe kontroloval, aby se tvůrci systému nezabývali zbytečně podrobnostmi v nesprávný čas apod. Každý projekt vývoje IS lze popsat pomocí jeho životního cyklu, který je tvořen navazujícími fázemi, které popisují celý průběh jeho existence. Přestože je každý IS specifický, je možno vymezit základní etapy, které jsou obecně platné pro libovolný projekt. Počet takto stanovených fází se liší dle pojetí různých autorů.
76
Etapy analýzy a projektování IS odvozené na základě metodiky MDIS
Informační strategie organizace (IST) Úvodní studie systému (ÚST) Globální analýza a návrh (GAN) Detailní analýza a návrh (DAN) Implementace (IMP) Zavedení (ZAV) Provoz, údržba a rozvoj (PUR)
77
Informační strategie organizace
Cíl etapy IST Definovat novou nebo upravit stávající strategii vývoje a fungování IS v organizaci na základě globální strategie a plánů a zjištěných nedostatků v informační podpoře.
78
Informační strategie organizace
Účel etapy IST Nalezení problémových oblastí v činnosti celé organizace a definování IS pro jednotlivé oblasti zájmů Stanovení cílů, záměrů a předpokladů pro vývoj nových (případně úpravy stávajících) informačních systémů Určení priorit vývoje jednotlivých IS, vztahů mezi nimi, stanovení kostry technické infrastruktury, standardů vývoje, metod, technik a nástrojů Plánování jednotlivých projektů, odhady času, zdrojů a přínosů a strategie postupu vývoje IS Časový horizont informační strategie je krátkodobý (1 rok), střednědobý (3-5 let), přímo závisí na časovém horizontu globální strategie a plánů organizace
79
Informační strategie organizace
Kritické faktory etapy Zaangažování vedení a plná podpora z jeho strany Dodržení konzistence informační strategie s primárními cíli organizace Dodržení globálního pohledu Čas – informační strategie a plán dalšího postupu by měla být hotová nejpozději do 6 měsíců od zadání (celkový čas etapy by neměl přesáhnout 1/10 (lépe 1/20) doby, na kterou se informační strategie stanovuje)
80
Úvodní studie systému Cíl etapy ÚST
Posoudit realizovatelnost jednoho vybraného systému. Zjistit, zda lze dosáhnout cíle systému z IST s očekávanými výsledky a bez nevhodných vedlejších účinků. Určit, zda ve vývoji pokračovat nebo ne. Spolu s vedením uživatelské organizace stanovit základní koncept systému, navrhnout alternativy řešení a vybrat nejlepší. Odhadnout náklady a přínosy návrhu systému.
81
Úvodní studie systému Účel etapy ÚST
Diagnóza současného stavu sledovaného informačního systému v organizaci – cíle, hranice systému, výkonnost. Problémy, přání uživatelů, požadavky na změny, priority požadovaných změn, omezení. Kontrakt mezi řešiteli a zákazníkem (uživateli) – upřesnění požadavků na systém (požadavky na informace, na zpracování, na uživatelské rozhraní, na výkonnost, na bezpečnost a utajení, požadavky organizační, ekonomické) Zpracování předběžného návrhu systému (koncept systému) – návrh na konceptuální úrovni – hranice systému, hlavní funkce, vstupy a výstupy, hrubý datový model. Návrh alternativ (možných přístupů) k realizaci (implementaci) navrženého konceptu systému – hrubý návrh technologického řešení a implementace. U každé alternativy uvažovat , organizační, sociální, technologické, politické a ekonomické vlivy. Výběr z alternativ podle stanovených kriterií (bezpečnost, spolehlivost, pružnost, doba odezvy, náklady, nároky na rekvalifikaci, nároky na zdroje a čas, jednoduchost používání, jednoduchost zavedení, vliv na změny organizační struktury, jednoduchost údržby, přenositelnost, technické nároky vývoje, podpora záměrů organizace apod. Dohodnutí principů a kriterií schvalování systému a konceptu schvalovací procedury Rozhodnutí vedení uživatelské organizace, zda ve vývoji pokračovat vzhledem k výsledkům zjištěným v ÚST Vytvoření plánu dalšího vývoje systému (včetně odhadu nákladů a přínosů)
82
Úvodní studie systému Kritické faktory etapy ÚST
Zangažovanost vedení a uživatelů i všech ostatních zúčastněných. Výběr správných spolupracovníků ze strany uživatele resp. zadavatele do projektového týmu Výběr a schválení vhodné alternativy řešení. Včasné vyjasnění, kritické zhodnocení a oprava názorů a očekávání uživatelů i řešitelů a odhalení možných konfliktů v organizaci. Ćas - ÚST by měla být dokončena nejdéle 3 – 4 měsíce od zadání, podle typu projektu, čas etapy by neměl přesáhnout 1/5 – 1/10 celkového plánovaného času
83
Globální analýza a návrh
Cíl etapy GAN Zpodrobnění základních požadavků na systém do úrovně, kdy je možné rozdělení systémů do subsystémů. Vymezení subprojektů (včetně subprojektů speciálních např. pro konverzi dat nebo pro řízení rozhraní mezi subsystémy). Návrh hrubého modelu funkcí (konceptuálního a technologického) a dat jednotlivých subsystémů a podrobný návrh rozhraní systému a okolí a mezi jednotlivými subsystémy navzájem. (U malých systémů odpadá dělení systému do subsystému).
84
Globální analýza a návrh
Účel etapy GAN Analýza a zpodrobnění základních požadavků na systém, zjištěných v ÚST Úplná specifikace všech hlavních funkčních, datových, prováděcích a dalších požadavků a nalezení odvozených požadavků Celkové požadavky na celý systém, jejich priority a struktura systému musí být určeny před zahájením vývoje subsystémů Oddělení konceptuálních požadavků od technologických a implementačních. Jasné oddělení vlivu stávající a budoucí implementace na návrh systému. Návrh hrubého modelu funkcí systému a hrubého modelu dat systému na konceptuální úrovni a ověření jejich úplnosti Podrobnější návrh společných funkcí a dat na rozhraní subsystémů a návrh řízení tohoto rozhraní Zpodrobnění schvalovací procedury (plán testů vyplývající ze znalosti vstupů a výstupů systému)
85
Globální analýza a návrh
Kritické faktory GAN Podpora vedení a aktivní účast uživatelů na vývoji Přesná kontrola úplnosti a kvality (hlavně řízení rozhraní mezi subsystémy Získání přesných a ověřitelných informací nutných pro návrh základních funkcí a dat systému a subsystémů Doba trvání analýzy současného stavu Oddělení konceptuálního návrhu od technologického Dodržení harmonogramu Návrh musí odpovídat cílům vytyčených v IST a ÚST
86
Detailní analýza a návrh
Cíl etapy DAN Analýza systému, definice požadavků a návrh systému (subsystému) až na úroveň, kdy je možné začít navržený systém (subsystém) implementovat. Detailní návrh nové organizační struktury. Tato etapa definuje činnosti, které jsou stejné pro všechny vytvářené subsystémy systému (pokud se systém na subsystémy dělí).
87
Detailní analýza a návrh
Účel etapy DAN Podrobná funkční a datová analýza a návrh funkčního a datového modelu, úprava rozhraní systému na vnější okolí na základě podrobné analýzy událostí Návrh uživatelského rozhraní Koordinace komunikace týmů, které paralelně řeší jednotlivé subsystémy a řízení rozhraní mezi subsystémy Vypracování konečné verze schvalovacích procedur a plánů všech testů. Podrobné prověření návrhu před implementací
88
Detailní analýza a návrh
Kritické faktory DAN Návrh uživatelského rozhraní Interview s uživateli a podpora ze strany uživatelů Úplnost a konzistence návrhu. Odhad nákladů na dokončení systému Koordinace řešitelských týmů zejména z hlediska dodržení termínů a vzájemné komunikace
89
Implementace (IMP) Cíl etapy IMP
Vytvořit fungující systém tak, aby realizoval detailní návrh v daném implementačním prostředí včetně realizace neautomatizovaných částí systémů. Provést testování systému vzhledem ke správnému bezchybnému fungování a otestovat systém z hlediska uživatelských požadavků.
90
Implementace (IMP) Účel etapy IMP
Tvorba a ladění programů nebo úpravy aplikačních programových produktů Školení zástupců uživatelů, kteří se budou podílet na testování Postupné testování jednotlivých modulů, testování zapojení modulů do programového systému a testování programových systémů z hlediska správného fungování a splnění uživatelských požadavků Otestování systému (subsystému) jako celku ( spolu s již fungujícími ostatními subsystémy) a schválení testu systému. Vytváření programové dokumentace. Tvorba úplné verze uživatelské příručky. Příprava konverze dat
91
Implementace (IMP) Cíl etapy IMP
Vytvořit fungující systém tak, aby realizoval detailní návrh v daném implementačním prostředí včetně realizace neautomatizovaných částí systémů. Provést testování systému vzhledem ke správnému bezchybnému fungování a otestovat systém z hlediska uživatelských požadavků. Účel etapy IMP Tvorba a ladění programů nebo úpravy aplikačních programových produktů Školení zástupců uživatelů, kteří se budou podílet na testování Postupné testování jednotlivých modulů, testování zapojení modulů do programového systému a testování programových systémů z hlediska správného fungování a splnění uživatelských požadavků Otestování systému (subsystému) jako celku ( spolu s již fungujícími ostatními subsystémy) a schválení testu systému. Vytváření programové dokumentace. Tvorba úplné verze uživatelské příručky. Příprava konverze dat Kritické faktory etapy IMP Dodržení časového plánu při současném zohlednění všech konkrétních specifik přesně identifikovaných až v této etapě Adekvátní zpracování všech případných změn závěrů a rozhodnutí z předchozích etap za účelem udržení konzistence všech tří úrovní návrhu – konceptuální, technologické a implementační Zohlednění všech specifických a omezujících faktorů systému v programech a fyzickém tvaru databáze Důkladné a úplné odladění a otestování systému, včetně všech omezení a výjimek. Dodržení metodické jednoty a čistoty vytvářených programů
92
Zavedení (ZAV) Kritické faktory etapy ZAV
Podpora ze strany vedení a jeho zaangažovanost Odpovídající a efektivní školení Vyzkoušení a přijetí systému uživateli v reálném prostředí Koordinace činností zavádění Odpovídající dokumentace pro diagnózu a řešení problémů způsobených HW SW Zajištění důsledné koordinace a otestování nového systému s již existujícími systémy, nakupovaným SW, automatizací kanceláře i ostatních provozních charakteristik.
93
Provoz, údržba a rozvoj (PUR)
Cíl etapy PUR Zajistit provoz systému, jeho údržbu a rozvoj vzhledem k vývoji potřeb uživatelů v souladu se záměry a cíli organizace.
94
Provoz, údržba a rozvoj (PUR)
Účel etapy PUR Poskytování informačních služeb uživatelům systému Organizační, personální, technické a materiálové zajištění vlastního provozu systému Poskytování pomocných informací a konzultací spojených s provozem nového systému Údržba programového systému a dat Údržba dokumentace Realizace změn Záznam uživatelských požadavků, které není možno zrealizovat v provozovaném systému
95
Provoz, údržba a rozvoj (PUR)
Kritické faktory etapy PUR Včasná reakce na uživatelské požadavky Údržba datové základny a zajištění její konzistence Zajištění konzistence nových funkcí se současným systémem Zajištění, že se jakákoliv změna jedné části systému nedotkne správné funkce zbytku systému Zajištění požadované výkonnosti provozovaného systému Kvalitní změnové řízení podporované formálnímí pravidly
Podobné prezentace
© 2024 SlidePlayer.cz Inc.
All rights reserved.