Hledejte v chronologicky řazené databázi studijních materiálů (starší / novější příspěvky).

Seznam událostí

Seznam událostí
- shody a rozdíly v sémantice modelů
- metody strukturované (pracujeme s entitou) X objektově orientované (pracujeme s objektem)

Funkční model
Datový model
Objektový model
Dynamický model
Dynamický model


Funkční model

databázové simulační
systémy modely
- v abstrakci systému a tvorbě konceptuálního modelu před realizací aplikace na požadavku, aby materiály, informace a peníze byly v potřebném množství včas na správném míst

- v metodologickém základu

- dynamické modelování (STD)

- funkční model (informačních, peněžních, energetických, materiálových a jiných toků)

Rozdíly:
- ve sledování objektů z objektivní reality (typické pro DB systémy) se u simulačního modelu rozšiřuje o objekty subjektivní reality

- cíle systémové analýzy a účel modelování systémů

- i DB systémů se sleduje množstevní kvantifikace stavů entit vzhledem k časovému okamžiku (časový snímek) pro účely organizace

- u simulačních modelů se průběžně sledují změny stavu systému jako celku vzhledem k časovému intervalu existence za účelem poznání jeho chování

Atributy datového a objektového modelování

- preference skalárních (statických) atributů ENTIT
- preference dynamických atributů TŘÍD objektů
- obr.: Dekompozice logistického multisystému

Dynamický model
- v souvislosti s IS byl poprvé publikován v r. 1986
- datové modelová bylo záležitostí kybernetiky

základní pojmy:
Stav
- vyjadřuje hodnoty sledovaných atributů systému vztažené k časovému okamžiku

Změny stavu – jak probíhají
- skoková, neboli diskrétní
- spojitá

CASE/4/0

jednoznačné přiřazení

nejednoznačné přiřazení – řeší se vazební entitou (různé číselníky, adresáře)
- objektově orientované modelování
- operace nejsou řešeny v relačních databázích

- generalizace (v objektovém modelování nazýváme dědičností)
- specializace

Ve cvičení máme udělané:
Model prostředí: seznam událostí z hlediska toků, a to
cíl systému materiálových, informační, peněžních,
kontextový diagram v organizaci

Model IS firmy: seznam událostí z hlediska
cíl systému informačních toků
kontextový diagram v rámci subsystému IS

V CASE/4/0 jsou DSD zaznamenány:

datový tok základ pro vytypování

Data Store předmětných oblastí

ER model předmětné oblasti (objednávka, dodací list)

Subsystémy
1.) subsystém obchodních činností
2.) skladové hospodářství
3.) výroba
4.) ekonomika, …


Yourdonův model

Vztah se vyjadřuje slovesně
- v ER modelu – na vztah pravým tlačítkem Create Relation Mode vygeneruje se model klasický, ve kterém provádím normalizaci

Entity na normalizaci:
- objednávka
- dodací listopad
- faktura

DFD – Data Flow Diagram

 ke každé úrovni existuje DFD
 nelze spojit horizontálně, ale v DFD to lze, ale nelze to vertikální
 objevuje se zde interface, a to nám poskytuje data
 data ukládáme do databází
 musí vytvářet systém
 každá funkce musí mít vstup i výstup
 Flow (toky) mohou být:
• informační (šedé) Data Store (sklad)
• materiálové (modré) Material Store
• peněžní (použít materiálový tok)
• událostní Event Store
 mohou být obousměrné nebo bez orientace (nepůsobí jako změna, ale pouze ke čtení)
 nelze: přenos z Interface do Data Store
 lze: přenos z funkce do funkce (ale nebudeme to používat)
 vhodné pro RT systémy (Real Time) – počítačové systémy, které řídí výrobu
 TOP úroveň – má kontextový diagram – ukazuje vazby na okolí

Datové modelování v CASE

- datový model je ve strukturovaných metodách 2. Modelem
- obr.:

- subsystém – část systému
- vyznačuje se tím ,že zahrnuje některou předmětnou oblast
- předmětná oblast – data, která do této oblasti patří
- zahrnujeme zde ta data, ty databáze, které spolu mají nějaký vztah
- základní pojmy datového modelování:
- entita
- abstrakce reálného předmětu, jehož vlastnosti (atributy) eviduje v počítači (v IS)
- pojmenování v jednotném čísle

- data store
- databázové množiny nějakých předmětů
- pojmenování je v množném čísle (např.: Pracovníci)
- relation – tabulka s jednotlivými záznamy

- relationship – vazba mezi objekty
- kardinalita 1 : 1, 1 : n, m : n, kde m, n = 0, 1, 2, …
- parciální vztah – je-li kardinalita n = 0, připouštíme NULL hodnoty

BOTTOM DOWN

 minispecifikace – funkce na nejnižší úrovni, které jsou určeny k programování (jsou programovatelné)
 systém – abstrakce nějaké části reality, která je objektem našeho poznání nebo přetváření
 vlastnosti:
1.) struktura – množina prvků a vazeb mezi nimi
2.) chování
3.) cíl
4.) hierarchická výstavba systému
 subsystémy – vytypujeme podle předmětných oblastí
 mají své funkce
 funkční přístup – přístup, který je založen na tom, že se zabýváme funkcemi
• 70. léta
 Chen, Bachmann, Codd – teorie pro způsob, jak modelovat data  na jejich základě byly vytvořeny relační databáze
 vůdčí postavení má firma IBM – vyvinula metodu HIPO
 metoda HIPO = hierarchy + Input Process Output
• hierarchie – dekompozice na dílčí subsystému, z toho vyplynulo:

• systémový diagram – specifikoval zpracovávaná data

 souběžně s tím vznikly jazyky pro popis (dokumentaci) výsledků systémové analýzy a projektů

• 70./80. léta

– vyvinuty databázové systémy na podporu dokumentace
 v 80. letech – skupina v čele s Yourdonem v r. 1989 publikovali Yourdonovu strukturovanou metodu
 3 typy modelů:
1.) funkční model
• FSD (Function Structured Diagram)
• DFD (Data Flow Diagram)
2.) datový model
• ERD (Entity Relationship Diagram)
• DSD (Data Structured Diagram)
• DDD (Data Dictionary Diagram)
3.) dynamický model
• STD (State Transition Diagram) – diagram přechodu stavů
 poprvé byl publikován v r. 1986
 byl převzat z kybernetiky – systémová věda pro informatiku

Yourdonova strukturovaná metoda

Vývoj metod:
• 60. léta
 Jackson se věnoval metodě strukturovaného programování, kterou metodicky zpracoval
 analytici zjistili, že je tato metoda vhodná i pro účely systémové analýzy
 jednou z vlastností systému je jeho hierarchická výstavba
 každá funkce má nějaký svůj cíl, popis ve Wordu

Diagram hierarchické struktury (FSD)
úrovně

SYSTÉM  TOP
UP TOP D
1. 2. 3. E
subsystém subsystém subsystém nultá a K
s úroveň n O
y 1.1 1.2 a M
n subsystém subsystém 1. úroveň l P
t ý O
é z Z
z 1.2.1 1.2.2 1.2.3 2. úroveň a I
a subsystém subsystém subsystém jeden vstup , C
nebo 1 výstup, E
nebo obojí

6.12 Životní cyklus řešení Data Warehouse

 Vytvoření
 Užití
 Údržba

Obr. č. 4 Životní cyklus DW
6.12.1. fáze vytvoření DW
Navržení a vytvoření kvantitativní a kvalitativní formy dat, která odpovídá potřebám koncových uživatelů dispozitivní úrovně, tj.:
 dobré porozumění obsahu a struktuře operativních dat,
 zahrnutí časového faktoru pro účely komparativní a trendové analýzy,
 respektování úrovní agregací dat (střední management, představenstvo),
 zajištění pružnosti datových pohledů vzhledem k měnícím se potřebám uživatelů.
Produktem této fáze je vytvoření třech typů metadat, které jsou využívány ve fázi Užití nebo modifikovány ve fázi Údržba. Jedná se o:
 popis dat operativního prostředí,
 popis dat DW,
 popis uživatelských profesních pohledů (view).

6.12.2. fáze užití DW

Zajištění přístupu uživatelům k relevantním informacím a podpora výběru prostředí dle individuálních potřeb uživatelů. Zde je kladen důraz na :
 směrování na příslušný zdroj dat operativního prostředí se zajištěním efektivního a pružného přístupu (heterogenní a distribuované prostředí),
 respektování standardů a všeobecného interface s cílem dosažení otevřenosti infrastruktury a integrace produktů.
6.12.3 fáze údržba DW
Přizpůsobení DW měnícím se potřebám řízení. Zpravidla se jedná o:
 nárůst objemu dat (historie, vývoj potřeb různých skupin uživatelů),
 zajištění průchodnosti řešení,
 modifikace získávání informací z operativní úrovně,
 změny načasování dodávky dat,
 změny v uspořádání uživatelských skupin,
 změny v jednotlivých pohledech uživatelských skupin,
 aktualizace zajištění bezpečnosti informací.

Datové sklady jsou charakterizovány těmito technologickými znaky:

 zpracovávají malý počet komplexních dotazů,
 data se načítají dávkově,
 důležitým hlediskem je rychlý přístup k datům pro účely analýz a prezentací,
 integrita dat se zajišťuje při dávkových načítacích procesech,
 datové modely jsou optimalizované pro rychlé zpracování výstupů,
 používá se kombinace datových modelů (normalizované a denormalizované relační modely, sumarizované tabulky, star schema modely, snow flake modely, multidimenzionální modely).
6.11 Kvalitativní vlastnosti OLAP
Abychom mohli určitým způsobem kvalifikovat produkty použitelné pro OLAP, je účelné pro ně definovat určitý konceptuální architektonický rámec. Jedním z autorů, který toto kvalitativní vymezení navrhl, byl E. F. Codd. Tato kriteria je možno vymezit takto:
1. multidimenzionální konceptuální pohled – dovoluje uživateli pohledy na data z různých hledisek. Multidimenzionalita znamená, že data jsou uspořádána alespoň s jedním dalším rozměrem – nejčastěji časem. Navíc je možné rozlišovat dotazy s různým stupněm agregace. Se snižujícím se stupněm agregace (drill-down) je možno tyto detaily zobrazit.

2. transparentnost

– pro uživatele by mělo být lhostejné, kde a jak jsou analytické funkce pro multidimenzionální analýzu umístěny.
3. dostupnost dat – schopnost získat data z heterogenních zdrojů fyzických dat ( i externích zdrojů). DBMS musí pracovat nezávisle na HW a musí pracovat s nezbytným middleware přes standardní rozhraní (např. ODBC). Pro optimalizaci využívání uživatelskými skupinami musí být schopen distribuovat data na různé servery.
4. stabilní výkonnost – výkonnost nezávislá na nárůstu počtu dimenzí pro výběr.
5. architektura klient/server – komponenty musí být dostatečně mocné, aby je bylo možno implementovat s minimálním úsilím.
6. generická dimenzionalita – pro všechny rozměry by měla existovat pouze jedna logická struktura.
7. dynamické manipulace s řídkými maticemi – pro efektivní zpracování nulových či prázdných hodnot.
8. podpora více uživatelů – řešení musí umožňovat souběžný přístup, bezpečnost a integritu pro více uživatelů.
9. neomezené cross – dimenzionální operace – tj.výpočty a jiné činnosti mezi dimenzemi bez zásahu uživatele.
10. intuitivní manipulace s daty

• Data mining (surfing)

– v podstatě „prosévání“ velkých objemů dat pro nalezení vzájemných vztahů v datech, navigování v celém datovém skladu pomocí Drag&Drop operací.
• Drill-down – zobrazení detailních dat, která byla použita pro agregace.
• Drill-up – zobrazení agregovaných hodnot na nejblíže vyšší úrovni.
• Drill-everywhere – rozlišení aktuální analýzy v libovolném smysluplném směru.
• Drill-across – možnost změny pohledu na jiná data beze změny stupně agregace.
• Dicing – rotace nebo převrácení multidimenzionální kostky.
• Slicing – vydělení jedné vrstvy z multidimenzionální kostky.
• Pivoting – rotace dvourozměrné křížové tabulky (záměna sloupců za řádky a naopak).
• Dynamické dotazy – dynamické SQL dotazy obvykle formulované v klientské aplikaci, nejsou předzpracovány, provádějí se v reálném čase.
11. flexibilní výstupy – koncový uživatel musí mít možnost snadné manipulace s výstupními daty v jakékoliv formě.
12. neomezené dimenze a úrovně agregací – nástroje by měly umožňovat práci alespoň s 15-ti, lépe s 20-ti dimenzemi.

6.10 Rozdíly mezi provozními systémy a datovým skladem

Hlavním účelem provozních systémů je automatizace operací a procesů. Naproti tomu za hlavní účel datových skladů je považováno vytváření podmínek pro poskytování optimálních informací pro rozhodování. Kromě hlavního účelu můžeme dále definovat dva druhy rozdílů:
 koncepční rozdíly,
 technologické rozdíly.
6.10.1 Koncepční rozdíly
Provozní systémy jsou charakteristické těmito znaky:
 účelem je dostat data do systému,
 uživatelé mají možnost zadávat data, měnit data, rušit data a číst data,
 zajišťují automatizaci rutinních činností,
 aplikace jsou v podstatě statické (požadavky na funkčnost jsou poměrně stálé),
 podporují každodenní firemní aktivity,
 orientované na výkonnost,
 proces implementace a využívání je poháněn technologií (tj. impulsem k inovaci systému je nové systémové prostředí, nová verze databáze apod.).

Datové sklady jsou naopak charakterizovány následujícími znaky:

 účelem je dostat informace ze systému,
 uživatelé mají možnost pouze číst data,
 umožňují kreativitu uživatelů při práci s daty (analýzy, prezentace dat),
 aplikace jsou dynamické (požadavky na funkčnost aplikace se mění),
 podporují dlouhodobé strategie firmy,
 poskytují konkurenční výhodu,
 proces implementace a využívání je poháněn potřebami organizace (tj. impulsem k inovaci systému jsou nové potřeby uživatelů).
6.10.2 Technologické rozdíly
Provozní systémy se vyznačují těmito technologickými znaky:
 zpracovávají velké objemy malých transakcí,
 transakce neustále přidávají a aktualizují data,
 důležitým hlediskem je omezení redundance dat,
 integrita dat se zajišťuje datovým modelem a aplikacemi,
 datové modely jsou optimalizované pro on-line aktualizace a rychlé zpracování transakcí,
 používají se převážně normalizované relační datové modely.

6.8.3 Multidimenzionální modelování

Pro efektivní využívání dat uložených v databázi datového skladu prostřednictvím OLAP aplikací je nutné uložit data určitým způsobem. OLAP aplikace jsou ve skutečnosti rozšířením či podrobnějším rozpracováním dřívějších typů aplikací, jako jsou systémy na podporu rozhodování (DSS) či exekutivní informační systémy (EIS). Cílem takovýchto aplikací je poskytování souhrnných údajů na vysoké úrovni agregace, na základě kterých se dělají rozhodnutí a díky nimž zůstává vedení firmy informováno. OLAP z tohoto přístupu vychází a dále ho rozšiřuje. Umožňuje prohlížet vybrané údaje ve firmě z různých stran, rozdělovat je, pohlížet na ně s odstupem či naopak vyhledávat podrobnosti. To, co ve skutečnosti odlišuje OLAP od klasických OLTP, je schopnost poskytovat multidimenzionální pohled na transakční data.
6.8.4 Rozdíly mezi relační a vícerozměrnou databází
Typický relační databázový systém poskytuje tradiční dvourozměrný pohled na data (řádky a sloupce). Tato nestrukturovaná reprezentace transakčních dat se příliš nehodí pro složité postupy analýzy dat, které zahrnují vyhledávání kvalitativních dat sečtených přes mnoho různých kategorií.
Na druhou stranu, vícerozměrné databáze jsou schopné poskytovat n-rozměrný pohled na data. Počet rozměrů, které lze zobrazit je teoreticky nekonečný. Jsou zde nicméně jistá praktická omezení na ukládání a výkonnost, kvůli kterým je tento počet omezen.

6.8.5 Multidimenzionální kostka

6.8.5 Multidimenzionální kostka
Základní stavební jednotkou v multidimenzionální databázi je kostka (cube, datová kostka, multidimenzionální kostka, hyperkostka). Kostka v multidimenzionální databázi se skládá ze sady dimenzí a měr.
Dimenze (rozměr) kostky jsou kategorie, vůči kterým chceme data agregovat a analyzovat. Dimenze vznikají z tabulek relačních databází. Typickými dimenzemi v multidimenzionálních databázích jsou čas, poloha, výrobek. Dimenze se může skládat z řady úrovní, které dále zpřesňují údaje.
Míry kostky jsou kvantitativní údaje, které chceme analyzovat. Tak jako dimenze jsou i míry odvozeny z tabulek relačních databází. Běžnými mírami jsou prodeje, výdaje, ceny, ale téměř každý kvantitativní údaj může být mírou multidimenzionální kostky.
6.9 Uložení dat v OLAP databázi
Zdrojová data z relační databáze mohou být uložena jednou ze tří základních metod:
 Multidimenzionální OLAP (MOLAP).
 Relační OLAP (ROLAP).
 Hybridní OLAP (HOLAP).

Při metodě MOLAP ...

Při metodě MOLAP se všechny podrobné údaje z kostky ukládají ve vyhrazené multidimenzionální databázi. To znamená, že relační data uložená v tabulkách dimenzí a v tabulkách faktů jsou zapsána do optimalizované multidimenzionální databáze.
Navíc jsou k podrobným údajům o kostce do multidimenzionální databáze uloženy také všechny agregace. Tato architektura OLAP je optimalizována pro zpracování dotazu ve službách OLAP a poskytuje nejlepší výkon ze všech tří metod ukládání dat.
Metoda ukládání ROLAP vyžaduje uložení jak všech podrobných údajů, tak agregací v relační databázi. To znamená, že všechna detailní data z kostky, která se najdou v tabulkách dimenzí a tabulkách faktů jsou ponechána v jejich přirozené relační databázi. Data se nepřesunují. Při ukládání agregací se vytvoří sumarizační tabulky, do kterých budou relační data ukládána službami OLAP pomocí jednoduchého SQL příkazu INSERT INTO. Služby OLAP vytvoří všechny tabulky a indexy samočinně. Podrobné údaje v kostce zůstávají beze změny.
Tento způsob ukládání nenabízí pro výkon zlepšení porovnatelná s MOLAPem; nicméně jde o velmi rozšířený způsob ukládání, díky kterému může firma využít stávající možnosti uložení dat.
Posledním způsobem ukládání dat je HOLAP. Je to kombinaci MOLAPu a ROLAPu. Jde o ukládání všech podrobných informací z kostek do relační databáze a všech agregovaných údajů do multidimenzionální databáze. Tato metoda se snaží poskytovat to nejlepší z obou světů: výkonnost MOLAPu a rozšiřitelnost ROLAPu.

6.7 Tvorba datového skladu

Mezi základní rozhodnutí při procesu budování datového skladu patří rozhodnutí o použití určitého přístupu. Rozlišujeme dva přístupy:
 Postup zdola nahoru – při tomto postupu pracujeme s menšími, cílenějšími aplikacemi metod datových skladů, což může celý proces zjednodušit. Požadavky na data jsou obvykle menší a rozsah specializovaných dotazů a souhrnů omezenější. Postup zdola nahoru poskytuje rychlejší vývoj na úkor obtížného rozšiřování po celé organizaci. I když tato metoda může přinést nejrychlejší výsledky při zavádění, je nutné se postarat, aby příliš specializované zaměření nebránilo v budoucnosti začlenění do celopodnikových řešení. Efektivitu tohoto přístupu obvykle zvyšuje i neexistence administrativních omezení na vlastnictví údajů.
 Postup shora dolů – používá se pro dosažení nejlepších dlouhodobých výsledků. Nástrahám metody zdola nahoru je možné zabránit včasným určením standardizovaných definic obchodních cílů a požadavků na data. Cena, složitost a potřebný čas jsou mnohem větší, než u předchozího přístupu. Problémem je také zajištění spolupráce jednotlivých oddělení firmy, vlastnictví dat a finanční zajištění. Naopak největší předností je možnost získání obsažného zdroje dat, který je globálně použitelný po celé firmě.

6.8 Dimenzionální modelování

Tradiční E-R model (entita-relace) používá pro návrh databází normalizovaný přístup. Normalizace odstraňuje ze schématu redundance, čímž optimalizuje uložení dat. Naproti tomu datové sklady nekladou takový důraz na šetření místem, záleží jim však na tom, aby se s nimi uživateli snadno a efektivně pracovalo. Z tohoto důvodu je mírná redundace obvykle akceptována. Dimenzionální modelování je pro návrh datových skladů mnohem vhodnější. Navrhujeme v něm schéma tak, že rozdělujeme činnosti do logických událostí a faktů a nastavujeme odpovídající dimenze.
Výslednému schématu se říká hvězdicové schéma (star schema). Používá totiž pár velkých ústředních tabulek faktů a mnoho malých tabulek dimenzí. Příklad hvězdicového schématu je na obr. 2.

Obr. č.3 Star schema
6.8.1 Tabulky faktů
Ústřední tabulky faktů se obvykle skládají z obchodních událostí, které lze zaznamenávat v čase, jako jsou bankovní operace, prodeje, objednávky, obraty, dodávky, návštěvy na Webu atd. Běžně jsou tvořeny cizími klíči do tabulek dimenzí a sadou numerických hodnot. Údaje uložené v tabulkách faktů jsou obvykle neměnné, protože jsou historické. Nejběžnějším příkladem tabulky faktů v hvězdicovém schématu jsou prodeje.

6.8.2 Dimenze

Tabulky dimenzí se skládají hlavně z textových informací, které jsou svázány se záznamy v tabulce faktů, jako jsou jména zákazníků, popisy výrobků, dodavatelé a prodejci. Tyto tabulky obsahují méně záznamů než tabulky faktů.
Ve schématu datového skladu se vždy používají tabulky dimenzí či tabulky, které pracují s úseky času. Tvoří základní prvek pro sledování v čase proměnných informací v tomto typu databází.
Teorie i praxe rozeznává několik variací klasického hvězdicového schématu. Občas jsou tabulky dimenzí podrobeny více normalizovanému přístupu. Běžným postupem je i začlenění souhrnů přes hierarchii dimenzí. Výsledkem jsou schémata označována jako sněhové vločky (snow flake schema) či souhvězdí.
Vločková schémata poskytují nejlepší výkon při použití souhrnů a tím upřednostňují výkonnost na úkor budoucích potíží při správě metadat a transformací potřebných při převodu ze zdrojových systémů.
Dimenzionální model je logickým postupem optimalizovaným pro dotazy a souhrnné výstupy. Je to dnes nejčastěji používaný model pro zavádění datových skladů a tržišť. Poskytuje zjednodušené postupy pro implementaci operací koncových uživatelů, jako je zjemňování (drill-down) podhledu a získávání více podrobností, či naopak shrnování stále vyšších celků (drill-up).

6.3.4 Datový sklad (Data Warehouse)

Datový sklad tvoří vlastní databáze a server, na kterém běží datový sklad. Může se skládat z jednoho centrálního skladu či více specializovaných datových tržišť (Data Marts).
6.3.5 Nástroje pro přístup a dotazy
Mohou to být nástroje pro tvorbu sestav od dalších výrobců či aplikace vyvinuté přímo v podniku, které zajistí přístup k informacím uloženým v datovém skladu.
6.6 Využití datového skladu
Přínosy z realizace datového skladu jsou tím větší, čím větší jsou možnosti pro analýzu a prezentace dat. Nejzákladnějšími metodami využití jsou operativní dotazy (předem nepřipravené) na určité hodnoty a sestavy, které mohou být standardní generované dávkově a operativní vytvářené podle potřeby.
Vyšším stupněm je multidimenzionální analýza OLAP, tj. rychlé prohlížení dat sumarizovaných na různých úrovních z různých pohledů neboli dimenzí. Dále nejrůznější statistické a finanční analýzy – ekonometrické modelování, termínové modely.
Analýzy časových řad a tvorby předpovědí slouží k předpovědi budoucích hodnot a identifikace sezónních výkyvů. Jedním z posledních hitů v této oblasti je dolování dat (Data Mining). Jedná se o specializované techniky pro zpracování velkých objemů dat a hledání skrytých vzorů a souvislostí.
Vizualizace dat nabízí prohlížení dat v dynamicky provázaných grafech pro identifikace neobvyklých a extrémních hodnot a závislostí mezi daty. Mezi důležité aplikace patří i geografické informační systémy, které převádějí hodnoty proměnných na geografickou prezentaci (např. zabarvení okresů podle počtu zákazníků) a manažerské informační systémy (EIS), které kombinují OLAP, reporting, přehledné zobrazení kritických veličin, jednoduché předpovědi a nabízejí podklady pro manažerské rozhodování.

Transformace dat se skládá z těchto dílčích operací:

 Validace – ověření správnosti dat,
 Čištění – odstranění či změna nesprávných dat,
 Integrace – dosažení konzistence dat pocházejících z různých systémů (datové typy, formáty),
 Derivace – vytvoření derivovaných dat na základě vstupních dat,
 Denormalizace – snížení potřeby spojování tabulek při využívání DW,
 Sumarizace – vytvoření požadovaných souhrnů z detailních dat.
Transformace dat z provozních systémů do datového skladu je časově nejnáročnější částí projektů budování datového skladu, u většiny případů tato část zabírá 70-80 % času realizace projektu. Pro snadnější provedení těchto činností se využívají tzv. datové pumpy (ETL – Extraction Transformation and Loading). Transformace je netriviální proces, který se skládá ze dvou typů kroků:
 Přenosových – přenos dat ze zdrojového systému (jako výsledek SQL dotazu) do cíle (tabulka v relační databázi datového skladu).
 Transformačních – obvykle procedurální transformace dat v rámci jedné nebo více tabulek.

V reálném projektu ...

V reálném projektu centralizovaného datového skladu bývají desítky až stovky pumpovacích kroků. Správa kroků v software ETL probíhá obvykle pomocí acyklického orientovaného grafu, kde uzly grafu jsou kroky a spojnice tzv. workflow (pracovní toky). Většinou existují různé typy workflow podle toho, jak dopadl krok ve výchozím uzlu spojnice (úspěch, chyba, nezáleží).
Ukládání dat do datového skladu je možné provádět na základě dvou různých strategií. Buď se pokaždé uloží celý obsah datového skladu znovu, což je použitelné pouze u velmi malých objemů dat a pro úvodní načtení, nebo se ukládají pouze přírůstky a změněná data – v tomto případě musí být k dispozici systém zajišťující rozpoznávání změněných údajů.
6.3.3 Metadata
Metadata obsahují popis dat, která budou uložena do datového skladu. Mohou obsahovat zdroj původní informace a pravidla či transformace, které byly použity při nahrávání dat. Metadata lze rozdělit na dvě skupiny – technická a obchodní:
 Technická metadata definují atributy, které popisují fyzické vlastnosti položek jako: odkud pocházejí, jak byly transformovány, kdo je za to zodpovědný, kdy byly naposledy načteny atd.
 Obchodní metadata jsou důležitá pro uživatele DW, protože obsahují informace jako jsou definice dat, hodnoty atributů a domén, obchodní pravidla, vztahy mezi daty atd.
Ukládání a využívání metadat umožňuje automatické načítání dat a údržbu datového skladu.

6.2 Základní koncepty datového skladu

V současné době existují dva základní koncepty datového skladu: nezávislé Data Marty (datová tržiště) a centralizovaný datový sklad.
6.2.1 Centralizovaný datový sklad
Centralizované Data Warehousy nabízejí výhodu konzistence. Jelikož centralizovaný Data Warehouse definuje jediný datový model, platný v celé organizaci, vynucuje si konzistentnost. Všechna data organizace jsou pak umístěna na jediném místě a při jejich čištění, transformaci a plánování se využívá společný soubor pravidel. Všichni pracovníci provádějící rozhodování mají k dispozici stejná data a Data Warehouse může také být centrálně zabezpečen, udržován a zálohován. Konečným výsledkem je Data Warehouse, poskytující vedoucím pracovníkům a pracovníkům marketingu bohatý a unifikovaný zdroj dat, který podporuje on-line analytické zpracování pomocí snadno použitelných nástrojů a aplikací.
Výhody centralizovaného skladu jsou především v konzistenci jeho obsahu, v menším počtu a jednodušší správě načítacích procesů z provozních systémů a ve snazší tvorbě nových Data Martů. Nevýhodou je naopak složitější realizace, pomalejší implementace (lze eliminovat vhodnou metodologií) a případně sekundární načítací procesy (z centrálního DW do Data Martu). Vzhledem k tomu, že požadavek na konzistentnost obsahu datového skladu je naprosto zásadní, tento přístup v současnosti převládá.

Ačkoliv centralizované Data Warehousy nabízejí mnoho výhod...

Ačkoliv centralizované Data Warehousy nabízejí mnoho výhod, mohou být nepružné, nákladné a pomalé. Jedním z možných řešení těchto problémů je tvorba závislých Data martů pro specifické podnikové jednotky nebo funkce. Závislý Data Mart přebírá již transformovaná a vyčištěná data z centralizovaného Data Warehouse, přičemž vytváří výběr, který má menší objem a který je více zaměřen na určitý podnikový problém. Data Mart může být přizpůsoben uživatelům, takže jim umožní snadnější navigaci, rychlejší využívání a větší pružnost. Závislé Data Marty umožňují větší pružnost a často poskytují vyšší výkonnost.
6.2.2 Nezávislé Data Marty
V případě nezávislých Data Martů se řeší potřeby jednotlivých útvarů či aplikací víceméně odděleně a vytváří se samostatná datová úložiště – tzv. Data Marty, která se někdy označují jako útvarové datové sklady. Výhodou tohoto uspořádání je snazší a rychlejší implementace a z toho vyplývající rychlejší přínosy pro uživatele. Nevýhodou je naopak fakt, že může docházet k nekonzistencím mezi jednotlivými Data Marty a načítací procesy jsou poměrně komplikované. Navíc s rostoucí velikostí datového skladu začínají nevýhody převažovat nad výhodami.

6.3 Součásti datových skladů

Za základní součásti datových skladů se považují:
 zdrojové systémy,
 transformace dat,
 metadata,
 datový sklad
 nástroje pro přístup a dotazy.
6.3.1 Zdrojové systémy
Jedná se o OLTP systémy používané v současnosti organizací. Mohou být rozmístěny po celém podniku a poskytovat specifické služby různým oddělením. Za zdrojové systémy jsou rovněž považovány externí zdroje dat, ze kterých vstupují data do datového skladu.
6.3.2 Transformace dat
Transformace dat je činnost, při které jsou data vyzvednuta z OLTP systémů, upravena, shrnuta a sjednocena do formátu vhodného pro datový sklad. Transformace dat může zahrnovat rozdělení položky (např. se jménem na jméno a příjmení) nebo sjednocení duplikovaných údajů z různorodých systémů do jednoho unifikovaného záznamu.

„Data Warehouse

„Data Warehouse je integrovaná, subjektově orientovaná, stála a časově rozlišitelná sbírka dat uspořádaná pro potřeby managementu“, jejichž charakteristiky lze rozvést jako:
 Subjektová orientace – data jsou kategorizována podle typu a ne podle aplikací (např. údaje o maloobchodních zákaznících jsou v jedné databázi datového skladu (DW), zatímco v operativních systémech mohou být rozptýlena ve více tabulkách nebo databázích, neboť jejich hlavním cílem je použití v konkrétních úlohách).
 Integrita – data jsou definována a ukládána podle potřeb celého podniku a ne jednoho obchodního nebo výrobního procesu. Jsou integrována do homogenních pohledů pro jejich následné vyhodnocení.
 Stálost –read-only databáze, data zde nevznikají, pouze jsou zpracovávána data z aplikačních bází a uloženy do báze dat DW. Data v DW nemohou být smazána nebo modifikována.
 Časová rozlišitelnost – vzhledem k tomu, že data v DW jsou určena pro analýzu v určitých obdobích, je nutné znát i čas jejich vzniku nebo platnost v čase. Proto jsou ukládány v časových řadách.
 Potřeba managementu vyšší úrovně – DW je používán pro podporu rozhodování a nikoli pro zpracování transakcí.
Operativní data Disponibilní data
Obr č.2 Proces získávání informací DW

DWH (Data Warehouse)

– datový sklad – představuje nový prvek v architektuře informačních systémů. Umožňuje efektivně ukládat data za delší časové intervaly a na jejich základě uskutečňovat analýzy časových řad, vývojových trendů, nejrůznějších závislostí a další analýzy. Podporuje vzájemnou provázanost mezi jednotlivými oblastmi informačního systému a hraje v něm významnou integrační roli.
MIS (Management Information System) – podporuje zejména taktickou a operativní úroveň řízení (např. účetnictví, nákup, prodej, sklady,..).
OLTP (On-Line Transaction Processing) – je bezprostředně spojen s typem provozu v rámci dané organizace (např. systémy bezprostředně podporující dílenské, skladovací, transportní operace výrobních podniků, rezervační systémy dopravních společností, zákaznické systémy energetických společností, systémy podporující provoz na přepážkách u bankovních systémů, apod.).
CIS (Customer Information System) – je implementován např. u energetických, teplárenských, servisních organizací zajišťující bezprostřední styk se zákazníkem, např. odečty spotřeby elektřiny, správu a montáž elektroměrů, fakturaci na zákazníka apod.
Obr. č.1 Obecné schéma architektury IS/IT

RIS (Reservation Information System)

– např. rezervační systémy v organizacích dopravního, cestovního ruchu.
GIS (Geographical Information System) – geografické informační systémy – pro podporu kreslení a vyhodnocování map, vytváření územních modelů apod.
CAD (Computer Aided Design) – podporující konstrukční a návrhářské práce v průmyslu, počítačově podporovaný návrh výrobku a jeho konstrukční řešení.
CAM (Computer Aided Manufacturing) – automatizovaná podpora řízení výrobních provozů.
OIS (Office Information System) – zajišťující podporu převážně rutinních kancelářských prací (zpracování a správa dokumentů, elektronická pošta atd.).
EDI (Electronic Data Interchange) – tyto systémy chápeme jako způsob výměny strukturovaných dat (objednávek, faktur) na základě dohodnutých standardů zpráv mezi informačními systémy jednotlivých obchodních partnerů pomocí elektronických prostředků. EDI umožňuje přímé propojení informačního systému daného subjektu s jeho zákazníky, dodavateli, finančními ústavy, dopravními organizacemi atd. a ve svém důsledku vede k tzv. „bezpapírovému“ obchodu. EDI je záležitost historicky spíše starší a proprietární mezi dvěmi firmami, dnes se více začíná mluvit v rámci B2B o standardizovaných řešeních.

FUNKCE OLTP OLAP

FUNKCE OLTP OLAP
OBSAH DAT průběžné hodnoty, detaily archivní, souhrnná, kalkulovaná
USPOŘÁDÁNÍ DAT záznamy n-dimenzionální pole dat
ORGANIZACE DAT liší se dle aplikace přizpůsobená dle potřeb podniku
CHARAKTER DAT dynamický statický, aktualizovaný
ČASOVÝ FAKTOR DAT průběžný historický, průběžný, kombinovaný
STRUKTURA DAT, FORMÁT složitá, vhodná pro operativní výpočty jednoduchá, vhodná pro analýzy
PRAVDĚPODOBNOST PŘÍSTUPU vysoká střední až nízká
TRANSAKČNÍ OBJEM malý velký
ZÁPIS DAT přímým přístupem do polí s přístupem a manipulací, nikoliv přímo
UŽITÍ DAT strukturované, opakované nestrukturované, analytické
ODEZVA DOTAZU menší než 1 až 3 sec. sec. až min.
IMPORT DAT pouze pro obnovu velmi rychlý, dle scénáře nebo na základě události

Tabulka č. 1 Porovnání Přístupu OLTP a OLAP (zdroj: SOFTWARE AG)

Obr. č.1 Porovnání struktur EIS nad OLTP a OLAP

Chaos Struktura
Operativní Dispozitivní Operativní Dispozitivní
prostředí prostředí prostředí prostředí

Provozní Útvary Provozní Útvary
Systémy řízení systémy řízení
Obr. č.1 Porovnání struktur EIS nad OLTP a OLAP
EIS (Executive Information System) – systémy specializované na podporu vedení podniků a institucí (např. strategie podniku, finanční řízení, marketing apod.) byly původně orientovány na podporu nejvyšší úrovně řízení podniků. V současné době jsou však tyto aplikace stále více orientovány i na střední management, který dnes tvoří většinu jejich uživatelů a rovněž na další podnikové specialisty. EIS využívá všech dostupných informačních zdrojů vytvářených na nižších úrovních informačního systému, tj. úlohami transakčního charakteru (OLTP), úlohami pro taktické a operativní řízení (MIS), úlohami pro podporu rozhodování (DSS). EIS v sobě integruje všechny nejdůležitější datové, procedurální a další zdroje systému, významné pro řízení organizace jako celku. S tím jsou spojeny i specifické nároky na prezentace informací a jejich zpřístupnění vedoucím pracovníkům firmy. EIS je tak především analytický a prezentační nástroj založený na využití již existujících dat.

 nejednotnost (diverzita) datových struktur,

 neflexibilní uživatelský přístup,
 malá integrace informačních systémů
 obsahová nedostatečnost dat, která neumožňovala komplexní pohled.
Data Warehouse se koncentruje na požadavky koncových uživatelů manažerské úrovně, které jsou představovány převážně úlohami analytického charakteru na dispozitivní úrovni a jsou realizovány pomocí přístupu OLAP (On-Line-Analitical-Processing).
Koncept DataWarehose byl definován firmou IBM koncem 80. let Billem Inmonem jako strategie přístupu k datům. Požadavky jednotlivých skupin uživatelů manažerské úrovně se vzhledem k datovému přístupu v rámci jedné firmy liší podle horizontální nebo vertikální úrovně jejich řízení. Zde, podle manažerských informačních potřeb, je nutné přizpůsobení datových struktur, tak i implementace přípravných procedur. Tyto požadavky přesahují rámec možností operativní úrovně řízení, která je podporována provozními programovými aplikacemi, jež většinou řeší oborově vymezenou oblast (doprava, personalistika, atd.) a jsou převážně řešeny odděleně podle svého oborového zaměření pomocí přístupu OLTP (On-Line-Transaction-Processing.)

Z hlediska dlouhodobějšího ...

Z hlediska dlouhodobějšího charakteru řízení (čím je vyšší úroveň managementu, tím je dlouhodobější horizont řízení strategie firmy) má management jiná rozhodovací kritéria než na operativní úrovni, potom mluvíme o tzv. dispozitivní úrovni řízení, která je operativní úrovni nadřazena. Před vznikem konceptu Data Warehouse byly aplikace určené pro dispozitivní úroveň řízení řešeny individuálně podle specifických potřeb daného managementu. Tato řešení se vyznačují nekoordinovaným přístupem k datům, což má často za následek zkreslení jednotlivých pohledů uživatelů na dispozitivní úrovni. Příčinou takového stavu byl:
 odlišný výběr sledovaných operativních dat,
 různá míra agregace dat, jejich odlišné filtrování a konsolidace.
S nárůstem potřeb přístupu manažerů k datům operativní úrovně z hlediska jejich dispozitivní úrovně řízení docházelo rovněž často ke zvyšování doby odezvy úloh operativní úrovně.
Koncept Data Warehouse řeší individuální přístup k operativním datům, jež můžeme označit jako „chaotický“, pomocí zavedení speciální infrastruktury dat mezi operativní a dispozitivní úrovní řízení, tzn. zavedením datového skladu. Přístup a zpracování dat pro potřeby dispozitivní úrovně řízení je označováno jako OLAP. V následující tabulce je uvedeno porovnání obou přístupů které jsou realizovány pro operativní (OLTP) a dispozitivní úroveň (OLAP).

obrázek č. 4 objekty procesního modelu v prostředí FirstSTEP

Obrázek 4 znázorňuje rozpad procesního modelu v prostředí FirstSTEP. Hlavní proces je tvořen několika sub-procesy (3 až 7). Každý z těchto sub-procesů je tvořen dalšími sub-procesy, až pokud nedosáhneme atomické úrovně, kde se definují aktivity (úlohy) a jejich popis. Z hlediska cílů organizace a top procesů určených k inovaci, není zcela jednoduché vybrat proces pro modelování.
Rovněž je nutné pro daný model vybrat a nashromáždit vhodné informace, dále rozhodnout jak podrobně a do jaké hloubky budete modelovat. Je nutné, aby projektant po celou dobu prací postupoval v rámci jemu přidělených pravomocí vzhledem k projektu.
Klíčové procesy podniku a jejich cíle, jsou determinovány předmětem podnikání a požadavky zákazníků. Většinou zahrnují náklady, dodávky, kvalitu, produktivitu, úroveň spokojenosti zákazníka atd. Aby tyto zásady byly v průběhu zpracování projektu splněny, je třeba:
­ definovat hlavní procesy a jejich cíle tak aby bylo možné rozhodnout, které procesy se mají modelovat,
­ identifikovat, která část organizace odpovídá za daný proces, nebo participuje na části modelovaného proces, včetně rozhraní.

Prostředí FirstStep ...

Prostředí FirstStep napomáhá udržet linii cílů, úkolů a předpokladů jednotlivých procesů. Při testování vlivu změn na modelu, by se měla zásadně používat kopie modelu. Jinak hrozí, že dojde ke změně poslání, cílů atd.
FirstStep poskytuje možnost modelovat některé procesy s vysokou mírou podrobnosti, jiné pouze na nutné úrovni popisu. Výhodou dekompozice velkých procesů do malých „článků“ nebo sub-procesů , je možnost modelování na jednotlivých částech jednoho modelu odděleně (paralelní vývoj). Jednotlivé kousky (články) mohou být spojeny do jednoho výsledného modelu, který pak může být předmětem testování, simulace a zlepšení. Dalším důvodem dekompozice tímto způsobem je dosažení lepší komunikace a pochopení problematiky. Velké a komplexní modely mohou být representovány několika jednoduchými obdélníky na nejvyšší úrovni se skrytými detaily uvnitř. Pokud má někdo zájem nahlédnout na detaily, jednoduše provede hierarchický rozpad na požadovanou úroveň.

rozpad na požadovanou úroveň.
6.1 Úvod do problematiky koncepce datového skladu (DW)
Koncepce Data Warehouse představuje specifickou strategii přístupu k datům a získávání informací z těchto dat, je určitým řešením problémů minulosti, tj.:
 nekonzistence dat,
 neexistence standardů,

• Definujte procesy

• Definujte procesy a organizační komponenty • Vytvořte mapu procesů nejvyšší úrovně • Pomoci simulace vytvořte podrobný model věcných procesů • Použijte sestavy k analýze a srovnání
• Pro každou komponentu procesu definujte: • Propojte organizaci, zdroje, produkty, procesy a aktivity navzájem • Spusťte model k vyzkoušení dynamického chování během různých časových period
• Úkoly a události • Upřesněte model – určete počáteční a koncové podmínky, náklady a ostatní atributy Animace poskytne vizualizovaný obraz diagramů procesů, front a chování systému
• Zdroje
• Produkty

5.3.2.1 Subkroky tvorby modelu – Definice a sestavení
Klíčovým rysem modelu FirstSTEPu je procesní tok, který je obvykle modelován shora dolů. Začíná na nejvyšší úrovní (top úrovni) konceptuálních objektů. U procesů nejvyšší úrovně (studovaného objektu) může být proveden rozpad na subprocesy dle potřeby. Nejnižší (atomická) úroveň modelu jsou samostatné právě prováděné úlohy.
Nejobtížnější částí tvorby procesního modelu způsob uchopení reality, tj. provedení rozpadu modelu na části (elementy) a rozhodnutí, které části jsou pro model potřebné. To však neznamená, že nemodelované části nejsou důležité (např. podniková kultura nebo pravomoce). Analytik si musí pamatovat tyto ovlivňující faktory pro interpretaci výsledků modelu.

5.3 Cyklus inovace podnikatelského procesu

Cyklus obnovy procesu může být rozdělen do několika různých kroků. Následující obrázek č. 2 zobrazuje typické fáze cyklu inovace podnikatelského procesu.
Fáze (etapy)

Kroky

Obsah jednotlivých kroků

- formulace produktu a vize - sestavení týmu - vytvoření
high-level modelu procesu - brainstorming nových ideí - nastartování pilotního projektu - implementace procesu
- definování záběru BPR/BPI - zaškolení týmu - namodelování řetězce aktivit a přiřazení času, zdrojů a nákladů - what-if analýza nových scénářů - sledování / měření výkonnosti - přemístění zdrojů
- definování cílů - - - detailní analýzy z hlediska času, využití a alokace zdrojů, nákladů a přínosů - úprava proměnných dle prvotních výsledků - zaškolení zdrojů
- sledování nově zavedeného procesu

Komunikace

- předkládání nových idejí vedení
- předkládání nových idejí procesnímu týmu
- předkládání nových idejí zaměstnancům
- předkládání nových idejí zákazníkům jako snahu o dodání vyšší hodnoty
Obr. č. 2 Fáze (etapy) postupu procesního přístupu

5.3.1. Fáze zaměření (plánování)
Obsahuje kroky:
­ Definice vize a rozsahu projektu
­ Budování týmu
V průběhu tvorby modelu je rozhodující zcela porozumět projektu a jeho vymezení. Následuje přehled plánu projektu inovace:
­ Formulace produktu a vize trhu, za účelem úplného pochopení cílů organizace
­ Definice velikosti a rámce projektu a sestavení týmu, který bude projekt řídit.
­ Identifikace cíle a účelu pilotního projektu.
­ Rozhodnutí, které informace jsou třeba tvorbě modelu.

­ Uskutečnění interview ...

­ Uskutečnění interview se zaměstnanci a manažery, jež jsou účastníky procesu, s cílem identifikace:
­ co opravdu dělají,
­ které dokumenty a prostředky (zařízení) používají,
­ dobu vykonání činností,
­ jakou hodnotu vytváří,
­ s kým a jak spolupracují.
­ Stanovení klíčových procesů na top úrovni, které budou modelovány.
­ Identifikace a pochopení funkčních oblastí organizace a jejich podporu modelovaných procesů, určení kontaktních bodů mezi funkčními oblastmi.
Důležitou podmínkou úspěchu je, aby tým byl zplnomocněn ke sběru těchto informací.
5.3.2 Fáze procesní modelování – (krok 3) zmapování stávajícího stavu
Mapovat proces znamená graficky znázornit sérií kroků nebo úloh nutných k dosažení určitého cíle. Zde by se měl projektant - analytik dopředu rozhodnout, na které úrovni podrobnosti ukončit analýzu procesu. Další úrovně podrobnosti mohou být přidány později.
Doporučené kroky tvorby modelu jsou znázorněny na obrázku č. 3, kdy etapa srovnání může být uskutečněna před simulací.
obrázek 3 FirstSTEP – postup tvorby modelu

Každý proces má své zákazníky, jimiž jsou:

• externí zákazník, který využívá výstupy organizace,
• interní zákazník, jež je subjektem uvnitř organizace.
Podle kategorií zákazníků se dělí procesy na
• hlavní procesy
• podpůrné procesy
• sdílené procesy (sdílené služby)
• vedlejší procesy
• řídící procesy.
5. 1 Definice procesů
5.1.1 Řídící procesy
definují strategické cíle a způsoby zajištění realizace těchto cílů v rámci celé organizace.
5.1.2 Hlavní procesy
vytvářejí hodnotu pro externího zákazníka, jejich výsledkem je produkce takových výstupů, které externí zákazník požaduje. Hlavní procesy jsou dány hlavními podnikatelskými činnostmi organizace, jež vedou k naplnění strategické vize a poslání podniku.
5.1.3 Podpůrné procesy
vytvářejí podmínky, které umožňují hlavní funkci procesů. Vyznačují se tvorbou přidané hodnoty pro interního zákazníka.

5.1.4 Sdílené procesy (sdílené služby)

5.1.4 Sdílené procesy (sdílené služby)
vytvářejí podmínky, které umožňují funkci všech podnikových procesů. Zpravidla mají pouze interního zákazníka.
5.1.5 Vedlejší procesy
jsou obdobou hlavních procesů, nejsou však pro organizaci důležité (nepodílí se výrazným způsobem na hlavní činnosti). Mohou být prováděny souběžně s hlavními procesy nebo sdílenými službami, jsou však vykonávány pro externího zákazníka.
5.2. Rámcový model procesů
Mezi jednotlivými procesy existují vazby, které jsou v každé organizaci utvářeny odlišně. Obecně lze definovat lze definovat rámcový procesní model organizace následujícím schématem.


obr. č.1 Rámcový procesní model

­ Řídící procesy řídí činnost všech procesů v rámci celé organizace.
­ V rámci hlavních procesů probíhají procesy klíčové.
­ Podpůrné procesy zajišťují chod hlavních procesů.
­ Sdílené procesy jsou využívány hlavními a vedlejšími procesy.

4.2.3.4 Řízení návaznosti procesů:

Procesní mapa jasně zobrazuje body, ve kterých výsledek činnosti jednoho oddělení poskytuje produkt nebo službu jinému oddělení. V každém z těchto bodů existuje dodavatelsko-odběratelská návaznost. Tyto návaznosti často představují největší příležitosti ke zlepšení výkonu. Procesně orientovaný manažer podrobně sleduje vzájemné návaznosti a snaží se odstraňovat případné bariéry účinnosti a efektivnosti.

Klíčové otázky procesního řízení jsou:

Rozumíte svým procesům?
Jsou vhodně sestaveny subcíle procesů?
Je výkon procesu řízen?
Jsou každému zdroji přiděleny dostatečné zdroje?
Jsou řízeny návaznosti mezi kroky procesu?

5. Metodologie analýzy procesu podnikání pomocí procesního mapování
Tradiční přístupy návrhu, vývoji a redesignu informačního systému organizace předpokládají, že uživatelé informačního systému předem znají a umějí formulovat své požadavky na budoucí informační systém. Tato skutečnost ovšem počítá s tím, že změny uživatelských potřeb v průběhu vývoje informačního systému jsou minimální. Praxe však ukazuje, že právě opak je pravdou, tzn., že nejvíce požadavků na změnu informačního systému vzniká až při samotném vývoji informačního systému.

Jedním ze způsobu jak dosáhnout optimální definice ...

Jedním ze způsobu jak dosáhnout optimální definice požadavků uživatele již na počátku projektu informačního systému, tzn. omezit počet změn v průběhu projektu (každá pozdější změna prodražuje projekt), je důsledné zmapování organizace z pohledu procesního řízení. Na základě provedené procesní analýzy (případně následného redesignu procesů nebo jejich reengineeringu) lze kvalitně definovat uživatelské požadavky na informační systém. Výhodou tohoto přístupu k definování uživatelských požadavků je eliminace významných změn v požadavcích na nově vyvíjený informační systém v průběhu jeho vývoje, což zpravidla projekt informačního systému prodraží.
Metodologie projektu procesní analýzy vychází z procesního pojetí činnosti organizace, jež je postaveno na následující definici procesu.
Proces je logicky nebo chronologicky seřazený soubor činností s definovanými vstupy a výstupy, které vytvářejí ucelenou hodnotu pro zákazníka procesu.
Procesy zpravidla procházejí napříč funkční a organizační strukturou (funkčním uspořádáním organizace) dané organizace, což nezajišťuje jejich optimální řízení. Optimální řízení procesu znamená řízení takovým způsobem, kdy celý proces řízen, monitorován, sledován a vykazován vlastníkem procesu, jež proces řídí s cílem naplnění požadavků zákazníka.

Příklad

Přijetí objednávky je první částí (subprocesem) procesu vyřizování objednávek. Na tomto prvku se podílejí tři útvary:
 Oddělení prodeje, které přijímá telefonické objednávky
 Oddělení financí, které ověřuje zákazníkův úvěr
 Oddělení výrobní kontroly, které sleduje stav zásob, a pokud je to žádoucí, rozhoduje o výrobě dalšího produktu.

4.2.3.2 Řízení výkonu
Po stanovení procesu a seznamu jeho cílů a subcílů, by měli jeho manažeři určit způsoby získávání zpětné vazby na výsledek procesu od interních i externích zákazníků, posuzování výkonu procesu vzhledem k cílům a subcílům, poskytování zpětné vazby na výkonu procesu útvarům, které se na něm podílejí, zavádění mechanizmu řešení případných problémů v procesu a neustálého zdokonalování jeho výkonu, a úpravy cílů tak, aby odpovídaly novým požadavkům zákazníků. V průběhu posledních několika let bylo získáno mnoho nových poznatků o řízení výkonu procesu. Zjistilo se, že pokud jsou procesy řízeny na základě jejich průběhu, potom manageři musí zavést styl řízení, kterou mnoho organizací začíná nazývat procesním managementem Zajistit, aby byl proces vyřizování objednávek řízen kontinuálně lze pomocí procesního řízení.

Příklad:

 Ohodnotit výkon procesu, oznámkovat jej v oblastech jako spokojenost zákazníka, náklady, jasnost a úplnost dokumentace, jakost a množství produktu nebo míra výkonu služeb. Stejně tak by mělo být ohodnoceno každé přispění organizačních jednotek k procesu.
 Určit vlastníka procesu, který bude dohlížet na celý jeho průběh.
 Ustanovit procesní tým, který se bude měsíčně scházet, aby hodnotil a zdokonaloval výkon procesu.
 Provádět měsíční hodnocení operací, ve kterých bude nejprve hodnocen výkon procesu.
 Odměňovat zaměstnance v útvarech na základě splnění cíle procesu a příspěvku útvaru k naplnění procesních cílů.
4.2.3.3 Řízení zdrojů:
Manageři si vždy uvědomovali, že alokace zdrojů je hlavní součástí jejich odpovědnosti. Nicméně procesně orientovaná alokace zdrojů je odlišná od obvyklého útvarově orientovaného přístupu. Ten obvykle vyplývá z řady osobních schůzek mezi řídícím pracovníkem a jeho úsekovým nebo subúsekovým manažerem. Při těchto schůzkách každý manažer usiluje o "větší porci koláče" a nejpřesvědčivější prezentace jsou odměněny největšími příděly zdrojů.
Procesně orientovaná alokace zdrojů je výsledkem určení finančních a lidských nároků požadovaných procesem pro dosažení jeho cílů. Poté je každému oddělení přiřazen podíl zdrojů odpovídající jeho příspěvku k procesu. Je-li v podniku zavedeno procesní řízení, rozpočet každého oddělení je tvořen součtem všech jeho procesních rozpočtů.

4.2.2 Procesní projektování

Když jsou cíle kritických procesů stanoveny, musí manažeři zajistit návrh procesů, které povedou k efektivnímu dosahování těchto cílů. Abychom zjistili, zda je každý proces a podproces správně strukturován, je potřeba vytvořit komplexní tým, který sestrojí mapu procesů. Tato mapa zobrazuje vstupně-výstupní vztahy procesně závislých operací a oddělení. Pomocí posloupnosti procesních kroků dokumentuje aktivity nutné k transformaci vstupů na výstupy. Týmy procesního mapování často zjišťují, že žádné procesy nebyly stanoveny. Prostě se to nějak dělá.
Na obrázku 1 je procesní mapa nynějšího stavu procesu vyřizování objednávek jak ji sestavil tým procesního mapování tvořen zástupci všech útvarů, které k tomuto procesu přispívají, a to včetně zákazníka. Tým procesního mapování sleduje proces transformace vstupu (objednávka) přes všechny mezikroky až k vytvoření požadovaného finálního výstupu (platba). Mapa znázorňuje jak se jednotlivé funkce zapojují do průběhu zpracování objednávky. Tato struktura procesního mapování umožňuje identifikovat kritická rozhraní, časově překrývat provádění různých podprocesů, definovat možnosti simulace procesů, aplikovat metody kalkulace nákladů založené na činnostech a odhalit „slabá místa“ procesů (nelogické, chybějící nebo nadbytečné kroky).

Během dokumentování ...

Během dokumentování a analýzy stávajícího procesu vyřizování objednávek může váš tým odhalit celou řadu „slabých míst“:
 Prodejcům trvá předkládání objednávek příliš dlouho
 Procesních kroků je příliš mnoho
 Dávkové zpracování objednávek zpomaluje proces
 Ověřování úvěru se provádí jak u starých tak u nových zákazníků
 Ověřování úvěru proces zdržuje, protože se provádí před shromažďováním objednávek (a nikoliv souběžně)
Tým pak vytvoří procesní mapu „jak to má být“, která odráží proces vyplňování objednávky. Tato procesní mapa je zobrazena na obrázku 2., která znázorňuje, hlavní změny v mapě „jak to má být“ jsou:
 Přímý vstup objednávek do oddělení prodeje, odstraňující prodejní administrativu
 Paralelní zpracování objednávky a kontroly platební schopnosti
 Odstranění vícenásobného vstupu a kroků zaznamenávání objednávky

 Další možný proces „jak to má být“ by mohl zahrnovat systém just-in-time, kde jsou zásilky sestavovány při objednávce a ne skladovány.
Procesní mapování „jak to je“ a „jak to má být“ jsou základními kroky v projektech optimalizace procesů. Avšak neměli by se v nadměrné míře zabývat detaily „jak to je“; účelem je rázně eliminovat, zjednodušit, nebo zdokonalit vaše „jak to má být“ procesy.

Výsledkem úspěšné snahy ...

Výsledkem úspěšné snahy o zdokonalovaní procesu je kladná odpověď na klíčovou otázku návrhu nebo zdokonalení procesu:
Je to nejvýkonnější a nejefektivnější postup
k dosažení cílů procesu?
Obr. 1 Procesní mapa stávajícího procesu „jak to je“
Obr. 2 Procesní mapa stávajícího procesu „jak to má být“

4.2.3 Procesní řízení
Bohužel ani nejlogičtější procesy, procesy přímo zaměřené na cíl, se neřídí samy. Toto jsou čtyři prvky efektivního řízení procesů:

4.2.3.1 Proces řízení cílů
Cíle procesu by měly sloužit jako základ pro stanovení jeho subcílů. Pokud řídíme stavbu vodovodu, budeme chtít, aby bylo možno měřit tlak a čistotu vody nejen na jeho konci, ale také v různých kritických spojích vodovodu. Jednoduše řečeno, potřebujeme zjistit subcíle procesu po každém kroku, který má zvlášť rozhodující vliv na konečné zákazníkem určené cíle procesu. Jakmile jsou stanoveny subcíle procesu, mohou být určeny cíle organizačních jednotek. Každý cíl činnosti organizační jednotky, který byl stanoven na podnikové úrovni by měl být, je-li to nutné, upraven tak, aby maximálně přispíval k cílům a subcílům procesů. A protože smyslem činnosti organizační jednotky je podpora procesů, měla by být hodnocena podle toho, do jaké míry těmto procesům slouží. Když stanovíme cíle organizační jednotky tak, aby podporovaly procesy, zajistíme tím shodu s potřebami interních i externích zákazníků. Prvním krokem by měla být identifikace všech organizačních jednotek, podílejících se na procesu.

Procesní cíle ...

Procesní cíle se vážou jak na cíle podniku, tak na požadavky zákazníků. Uvědomme si, že se nejedná pouze o cíle oddělení vývoje. Tyto procesní cíle vyjadřují také výkony, které se v procesu vývoje produktu a jeho uvedení na trh očekávají od partnerů oddělení vývoje, včetně marketingu, prodeje, a činností v terénu. Splněním těchto cílů uvedený proces významně přispěje k uskutečňování strategické vize podniku.
Příklad:
Představme si softwarovou společnost, jejímž firemním cílem je do konce příštího roku zkrátit čas odezvy na objednávku na 72 hodin. Pro dosažení tohoto cíle se strategicky významným stává proces vyřizování objednávek. Některé z cílů tohoto procesu jsou:
 Žádný produkt nebude kvůli chybě odeslán na nesprávnou adresu
 Stanovený cíl dosáhneme bez zvýšení nákladů na vyřizování objednávek
 Zákazníkům poskytneme kontaktní místo pro dotazy a reakce na objednávky
Ke splnění těchto firemních cílů by manažeři měli stanovit také cíle vedlejších procesů (procesů služeb zákazníkům). V každém případě hlavním cílem procesního mapování je zajistit návaznost klíčových procesů na požadavky zákazníka a organizace.

4.2.1 Procesní cíle

4.2.1 Procesní cíle
Každý hlavní proces a každý podpůrný proces existuje proto, aby přispíval k naplňování jednoho nebo několika cílů podniku. Tudíž každý proces by měl být poměřován rovněž procesními cíli, které vyjadřují očekávaný přínos tohoto procesu k jednomu nebo několika cílům podniku. Dle většiny zkušeností většina procesů cíle nemá. Zatímco jednotlivé organizační jednotky obvykle mají cíle, většina klíčových procesů překračuje hranice organizačních jednotek. Jestliže pracujeme v organizaci, ve které je fakturace klíčovým procesem a ptáme se na cíle procesu fakturace, odpověď obvykle zní: „Aha, vy myslíte cíle oddělení fakturace.“ Když namítneme, že mluvíme opravdu o procesu fakturace – a to včetně těch kroků, které se provádí mimo oddělení fakturace – často se setkáváme pouze s nechápavými pohledy.
Měření výkonnosti je nejúčinnější, jestliže se provádí s ohledem na strategické záměry nebo taktické cíle podniku. Procesní cíle se odvozují ze tří zdrojů, jimiž jsou:
1. cíle podniku,
2. požadavky zákazníků,
3. benchmarkingové informace.

Na podnikové úrovni ...

Na podnikové úrovni vede zkoumání procesů k lepšímu pochopení vztahů zákazník-dodavatel mezi jednotlivými funkcemi (prvky funkční struktury). Na úrovni výroby a služeb probíhá zkoumání rozkladem procesů na podprocesy, prvky pracovních toků, sdílené procesy (služby) a výrobní procesy.
4.1.1 Příklady firemních procesů
Obecné hlavní procesy
Marketing a prodej, Vývoj výrobku/služby a uvedení na trh, Distribuce, Fakturace, Zpracování objednávek, Služby zákazníkům
Oborově-specifické hlavní procesy
Poskytování půjček (bankovnictví), Přiznávání pojistného nároku (pojišťovnictví), Přidělování dotací (vláda), Vrácení zboží (maloobchod), Příprava jídel (restaurace), Manipulace zavazadly (letecké společnosti), Zpracování rezervací (hotely/letecké společnosti)
Obecné podpůrné procesy
Formální strategické a taktické plánování, Rozpočtování, Školení, Řízení zdrojů, Nákup, Řízení IT

Způsoby zlepšování firemních procesů

Eliminace duplicitních činností Kombinace souvisejících činností
Eliminace mnohonásobných revizí a schvalování Eliminace inspekcí
Zjednodušení procesů Omezení velikosti dávek
Provádění procesů souběžně Uplatnění principu tahu
Provedení outsourcingu neefektivních činností Eliminace změn pracovního tempa
Zřízení multifunkčních týmů Návrh pracovních buněk
Centralizace/decentralizace
4.2 Výhody procesní analýzy
Podnik je pouze natolik efektivní, nakolik jsou efektivní jeho procesy. Cíle firmy lze dosáhnout pouze vývojem logických firemních procesů. Například, jedním z cílů výrobce automobilů může být zkrácení doby dodávky vozu vybaveného doplňky podle přání zákazníka. Jestliže tato společnost používá neefektivní proces objednávání nebo zmatený proces distribuce, sotva může doufat, že uvedený cíl splní.

Pokračujme dál v příkladu výrobce automobilů.

Představme si prodejce důkladně vyplňující objednávkové formuláře, úřednice bezchybně vkládající data do počítače a pracovníky překladiště zdatně nakládající auta na kamiony. Avšak efekt jakéhokoliv zvýšení výkonnosti lidí může být limitována logikou (nebo nelogičností) celého procesu distribuce, který je tvořen podprocesy přijímání objednávek, plánování výroby a transportu.
Procesní úroveň je důležitá, protože efektivnost a účelnost procesů by měla podmiňovat celou řadu podnikatelských rozhodnutí. Kupříkladu, jakékoliv reorganizace nebo zeštíhlování jsou zbytečné, pokud v první řadě nezvýší výkonnost procesů. Mnoho organizací, které provedli re-engineering nebo zeštíhlení, neuspělo, protože vedení rozhodlo snížit náklady o 10% napříč celou organizací místo toho, aby zjednodušilo, eliminovalo, nebo provedlo re-engineering základních procesů. Procesní mapování poskytuje ověřený nástroj umožňující pochopit a změnit procesy a tím pomoci zvýšit zisk a konkurenceschopnost.
Stěžejním spojovacím článkem mezi výkonností podniku a individuální výkonností jsou tři procesní proměnné:
1. procesní cíle,
2. procesní projektování,
3. procesní řízení.

Příklad

Přístup společnosti General Electric k procesnímu mapování umožnil týmům zabývajícím se optimalizací podnikových procesů a jejich re-eingineeringem těmto procesům skutečně porozumět. Aplikace procesního mapování v závodě na výrobu elektrických spotřebičů ve městě Louisville vedla ke zjištění, že i když jedna pětina součástek libovolného modelu elektrického spotřebiče je technologicky velice složitá, pouze 5 procent z nich je drahých natolik, aby podstatně ovlivnily náklady na skladování. V General Electric dospěli k závěru, že mohou zrychlit výrobu a snížit náklady, budou-li udržovat vysoký stav zásob levných komponentů a společně s dodavateli vypracují a zavedou programy just-in-time pro dodávky ostatních součástek podle aktuální potřeby. Největší přínos mělo zavedení řízení pořadí, ve kterém jsou jednotlivé součástky předávány z překladiště na montážní linku.
4.1 Proces
Geary A. Rummler a Alan P. Brache ve své vynikající knize Improving Performance: How to Manage the White Space on the Organization Chart (Zvyšování výkonnosti aneb Jak zvládat bílá místa na organizačním schématu) uvádějí, že procesní úroveň je nejméně pochopenou a nejméně řízenou úrovní podnikatelské činnosti. V organizacích procesy probíhají (často spíše klopýtají) bez ohledu na to, zda se o ně staráme či nikoliv. Máme na výběr dvě možnosti:
• můžeme procesy ignorovat a doufat, že dělají to co si přejeme,
• nebo je můžeme pochopit a řídit. (Dokumentování a zkoumání vazeb vstup-výstup (zákazník-dodavatel) zobrazených na procesní mapě může vést k řadě nových poznatků a zlepšení).

Mezi každým vstupem ...

Mezi každým vstupem a každým výstupem je proces. Podrobný průzkum procesů, kterými se vstupy mění ve výstupy, je pro celkové chápání a zlepšování podnikových procesů zcela nezbytné.
Firemní proces je sled kroků navržených za účelem vytvářet výrobek nebo službu. Některé procesy (např. proces programování) mohou být plně obsaženy v jediné organizační jednotce organizace. Většina procesů ale prochází napříč funkční strukturou organizace a překlenuje tak „bílá místa“ mezi prvky na organizačním schématu.
Některé procesy vytvářejí výrobky nebo služby, jejíchž příjemcem je externí zákazník dané organizace. Tyto procesy nazýváme hlavní procesy.
Jiné procesy vytvářejí výrobky nebo služby neviditelné pro externího zákazníka, avšak nezbytné pro efektivní řízení firmy. Označují se jako podpůrné procesy.
Další kategorie procesů – řídící procesy – zahrnuje opatření, která by měli provádět manažeři na podporu podnikových procesů. Mezi řídící procesy patří stanovování cílů, operativní plánování, zpětná kontrola, odměňování a alokace zdrojů.
Proces lze chápat jako hodnotový řetězec. Každý krok procesu by měl k tvorbě výrobku nebo poskytování služby přidat jistou hodnotu oproti kroku předchozímu. Například jedním z kroků v procesu vývoje nového produktu může být test přijatelnosti na trhu. Tento krok zvýší přidanou hodnotu zajištěním skutečnosti, že produkt vyhoví požadavkům trhu dříve, než je jeho vývoj ukončen.

Analýza přirozeného jazyka

Analýza přirozeného jazyka • nejrozšířenější forma informací • velká pracnost
• vícevýznamovost přirozeného jazyka
• bohatost výrazů přirozeného jazyka
Opakované využití požadavků • snížení pracnosti vývoje informačního systému
• rychlejší vývoj informačního systému
• vytvoření aktuální dokumentace
• snadná přenositelnost informačního systému do jiného prostředí • dodatečné finanční nároky na podpůrné nástroje a jejich údržbu
Analýza úloh • poměrná jednoduchost
• zaměření na komunikaci člověk– počítač
• identifikace nutných znalostí uživatelů • nutnost modifikace uživatelských požadavků vzhledem k novému informačnímu systému
Sociálně - technický přístup • spojení požadavků se sociálním prostředím uživatele
• zreálnění požadavků vzhledem k prostředí • nároky na neformální atmosféru

4. Úvod do procesního mapování

Procesní mapování poskytuje nástroj a ověřenou metodologii k identifikaci stávajících procesů ve firmě („jak to je“) a lze ho použít také jako návod („jak to má být“) pro re-engineering podnikových funkcí zajišťujících výrobu a poskytování služeb. Mapování procesů je rozhodujícím pojítkem, které lze využít k lepšímu pochopení a významnému zlepšení procesů ve firmě a zvýšení její výkonnosti.
Procesní mapování je nástroj managementu, který původně vyvinula a implementovala společnost General Electric jako součást své integrované strategie „Workout, Best Practices and Process Mapping“ („Trénink, nejlepší postupy a procesní mapování“) s cílem výrazného zlepšení své výkonnosti. Koncepce procesního mapování je zde užita k popisu všech zásadních kroků ve firemních procesech, a to pomocí diagramů workflow (pracovních toků) a doplňujících komentářů.
Manažeři se často domnívají, že procesy ve firmě dobře znají, ale ve skutečnosti většina z nich neví, jaké procesy to vlastně jsou a je-li možné je zlepšit, zjednodušit nebo odstranit.
Procesní mapování je ověřený analytický a komunikační nástroj, určený k optimalizaci stávajících procesů a k zavádění nové procesně orientované struktury pro potřeby re-engineeringu firemních procesů. Je to vynikající nástroj procesního řízení, který lze použít k lepšímu pochopení stávajících procesů a k eliminaci nebo zjednodušení těch procesů, které vyžadují změnu.

2.12.13 Analýza úloh

2.12.13 Analýza úloh
Analýza úloh je přístup získávání požadavků, který je zaměřen na komunikaci člověk–počítač. Při této činnosti je analyzován a popisován způsob, jakým uživatelé vykonávají svou práci v následujících pojmech:
• činnosti a jejich struktura,
• identifikace znalostí, které jsou vyžadovány k zajištění těchto činností.
Historicky je analýza úloh zaměřena na popis velice podrobných činností a jejich posloupnosti ve formě diagramů, jejichž nejvyšší rozlišovací úroveň tvoří základní činnosti, které už dále nelze členit. Analýza úloh z hlediska jejich hierarchie je metodou, která vytváří hierarchii úloh a jejich podúloh a také popis, v jakém pořadí tyto úlohy budou provedeny. Výstupem analýzy úloh je zpravidla hierarchicky očíslovaný text nebo stromový diagram, který lze velmi dobře použít v procesu odvození uživatelských požadavků. Nevýhodou je skutečnost, že výstupy analýz úloh neposkytují rozšiřující požadavky na nový systém, protože se tyto výstupy odkazují na systém stávající. Navíc tyto výstupy jsou zatíženy balastem, který nemá být součástí zamýšleného informačního systému.
Analýza úloh může tvořit základ pro určení požadavků na zamýšlený informační systém, které budou následně modifikovány a rozšířeny.

2.12.13. Sociálně technický přístup

Sociálně technický přístup vychází z předpokladu, že odvození uživatelských požadavků není primárně technický problémem, ale procesem, který se uskutečňuje uvnitř sociálního prostředí. Nedostatek ohledu na sociální kontext při vývoji informačního systému způsobuje velkou část neúspěchu, který je zapříčiněn skutečností, že je neúměrné vyhovět uživatelským požadavkům, nebo vyvíjený systém nepodporuje reálné potřeby uživatelů.
Sociálně technické přístupy odvozování uživatelských požadavků předpokládají, že sociální a technické potřeby v rámci problémové oblasti jsou si rovnocenné a vzájemně závislé. Formulované uživatelské požadavky jsou ve většině případů výsledkem interakce analytiků s uživateli více než zhmotněním mentálního modelu požadavků uživatelů. Z toho důvodu by odvození požadavků mělo být prováděno v pracovním prostředí uživatelů v interakci s ostatními zainteresovanými uživateli. Uživatelské požadavky se stávají více důležitými v kontextu s pracovními situacemi, ve kterých jsou nebo mají být požadavky uskutečněny (místo, čas, množství).
V tradičních metodách má uživatel zpravidla pasivní roli, ale sociálně technický přístup klade naopak důraz na jeho aktivitu a snaží se uživatele začlenit do vývojového týmu.

2.12.14. Výhody a nevýhody přístupů odvození uživatelských požadavků

2.12.14. Výhody a nevýhody přístupů odvození uživatelských požadavků
Každý přístup odvození uživatelských požadavků má svá silná a slabá místa, protože obecně existují rozdílné kategorie problémů. Odvození požadavků je nejkritičtější činností vývoje informačního systému, která je spojena s nemalých úsilím analytiků a uživatelů. V tabulce č. 1 jsou uvedeny základní výhody a nevýhody přístupu odvození uživatelských požadavků.

Přístup
Výhody Nevýhody
Přímá komunikace s uživatelem • přímočará, nevyžaduje mezičlánky • pečlivá příprava, pokud má být efektivní
Analýza cílů • dosažení shody mezi rozdílnými uživateli • explicitní definice problému
Tvorba scénářů • vytvoření expertizy zúčastněného uživatele • omezená paměť uživatelů
• někdy malá zkušenost uživatelů s interakcí informačního systému
Analýza formulářů • zdrojem informací není člověk, ale formulář • velká pracnost

2.12.11 Vytváření knihoven požadavků

Knihovny pro opakované využití požadavků poskytují velmi rychle informace, které byly získány na základě zkušeností z předešlých projektů informačních systémů. Tento přístup však vyžaduje:
• samostatný vývoj knihovny požadavků, který je spojen s obtížným naplňováním dané knihovny,
• průběžnou údržbu takto vytvořené knihovny.
Knihovny opakovaného využití požadavků jsou často součástí CASE nástrojů, které podporují řízení procesů, jako je například nástroj „Proces Engineer“ od firmy LBMS.
2.12.12 Reverzní inženýrství
Reverzní inženýrství je procesem analýzy informačního systému na jeho programové úrovni za účelem:
• identifikace komponent informačního systému a jejich vzájemných vztahů,
• vytvoření zobrazení systému v jiné podobě na vyšší úrovni abstrakce.
Přístup k získávání uživatelských požadavků při využití reverzního inženýrství pracuje na rozdíl od ostatních přístupů se zdroji informací, které představují nižší úroveň specifikací ve formě programového kódu.

Výstup naopak tvoří model ...

formě programového kódu.
Výstup naopak tvoří model uživatelských požadavků, který může být použit jako podklad pro specifikaci požadavků zamýšleného informačního systému. Při vývoji informačního systému často nastává situace, že nový systém bude tvořit část stávajícího informačního systému. Proto je nutné vzít v úvahu nově implementované části tak, aby se vzájemně podporovaly v konečném efektu.
V mnoha případech je využíváno reverzní inženýrství k aktualizaci dokumentace stávajícího informačního systému, protože dokumentace buď vůbec neexistuje, nebo už neodpovídá skutečnosti, která je zachycena pouze v programovém kódu. Pomocí reverzního inženýrství lze vyhotovit poměrně rychle dokumentaci informačního systému, jejíž základ tvoří datový model. Na základě vytvořené dokumentace lze snadno přenést celý informační systém nebo jeho část do jiného prostředí. Samozřejmě lze tuto dokumentaci upravit na základě nově požadovaných vlastností uživatelem, a tak rychle vygenerovat upravený informační systém případně i do odlišného programového prostředí.
Možnost využití reverzního inženýrství poskytují některé CASE nástroje. Tato skutečnost umožňuje snadnou údržbu aplikace aplikací modelů specifikace informačního systému místo často velmi nepřehledné údržby programového kódu. Tato výhoda je velmi efektivní u rozsáhlých informačních systémů, vyžaduje však investice do CASE nástroje a personálu, který se bude touto činností zabývat.

• stanovení kritérií výběru ...

• stanovení kritérií výběru „starých“ požadavků, které umožňují otestování, vhodnost a úpravu těchto požadavků vzhledem k zamýšlenému informačnímu systému,
• menší nákladnost aplikace tohoto přístupu, než je tomu u jednoduchého a rychlého odvození požadavků jiným přístupem.
Výše uvedené předpoklady splňují následující techniky opakovaného využití uživatelských požadavků. Jedná se o:
• analýzu problémové oblasti,
• vytváření knihoven požadavků,
• reverzní inženýrství.
2.12.10. Analýza problémové oblasti
Analýza problémové oblasti je charakterizována jako základní podmínka analýzy uživatelských požadavků. Tento přístup umožňuje opakované využití požadavků na základě podobnosti požadovaných vlastností informačního systému v rámci stejné nebo podobné problémové oblasti. Při této činnosti jsou identifikovány v rámci problémové oblasti:
• objekty,
• pravidla,
• omezení,
které jsou obvyklé mezi rozdílnými (ale podobnými ) oblastmi problému a které formalizuje do opakovaně použitelné podoby.

Analýza problémové oblasti ...

Analýza problémové oblasti je způsobem odvození požadavků, který značně sníží úsilí odvození uživatelských požadavků, protože automatizuje činnosti související s ukládáním, vyhledáváním a modifikací požadavků aplikací databázových systémů. Opakované využití výsledků analýzy podobných problémových oblastí je běžnou technikou, která je závislá na zkušenostech analytika využívat nabízených analogií. Proces analýzy problémové oblasti lze rozdělit do následujících fází, a to na:
• identifikaci kategorie problémové oblasti, tj. přiřazení dané aplikace k jí podobným,
• identifikaci a formalizaci vlastností, které jsou podobné mezi rozdílnými aplikacemi v dané problémové oblasti,
• vytvoření knihovny opakovaně použitelných požadavků a jejich zpřístupnění ostatním projektům.
Analýza problémové oblasti ve spojení s CASE nástroji může zásadně změnit vývoj informačního systému. Aplikace tohoto přístupu je však poměrně nákladnou záležitostí, která se zatím vyplatí ve vývoji rozsáhlých, ale podobných projektů.

Manuální přístupy analýzy ...

Manuální přístupy analýzy přirozeného jazyka pro získání uživatelských požadavků jsou pružnější než automatizované, protože spoléhají na lidský intelekt. Takové přístupy analýzy přirozeného jazyka identifikují konstruktory (podstatná jména, přídavná jména, slovesa atd.) modelu podle stanovených pravidel.
Analýza přirozeného jazyka je jako technika získávání uživatelských požadavků upřednostňována objektově orientovanými přístupy tvorby informačních systémů, protože tyto přístupy se soustředí na následující konstruktory, a to na:
• objekty (cokoli, co nás zajímá v problémové oblasti),
• atributy objektů (charakteristické vlastnosti objektů),
• operace (akce prováděné objekty nebo na objektech).
V rámci analýzy přirozeného jazyka vycházejí objektově orientované přístupy ze skutečnosti, že:
• objekty tvoří podstatná jména,
• atributy objektu tvoří přídavná jména nebo přívlastky, které jsou vztaženy k objektu,
• operace jsou určeny slovesy nebo slovesnými vazbami, které vypovídají a vztahují se k danému objektu.

Objektově orientovaný přístup ...

Objektově orientovaný přístup k analýze přirozeného jazyka poskytuje analytikům mechanismus k prezentaci klíčových pojmů z dané problémové oblasti. Tento přístup však aplikuje heuristická pravidla, a tedy jistým způsobem spoléhá na schopnost analytika tato pravidla použít. Daný přístup vyžaduje zpravidla mnoho opakování, než analytik dospěje k ustálenému počátečnímu souboru objektů, atributů objektů a operací. Vzhledem k rostoucímu světovému trendu využívání objektově orientovaného přístupu tvorby informačních systémů se však metoda analýzy přirozeného jazyka zdá být velmi slibnou pro budoucnost. Tato skutečnost je ovšem podmíněna překonáváním problému mnohotvárnosti a bohatosti přirozeného jazyka.
2.12.9. Opakované použití požadavků
Přístup opakovaného využití požadavků vychází z předpokladu, že požadavky, které již jednou byly v nějaké aplikaci informačního systému odvozeny, mohou být opět použity při odvození požadavků v podobné aplikaci. Samotné odvození požadavků představuje nejvíce pracnou část vývoje informačního systému, a proto jakékoliv ušetření zdrojů (času, financí, atd.) může přinést velmi významné zvýšení produktivity při vývoji informačního systému. Obecně existuje velký stupeň podobnosti mezi informačními systémy v rámci stejné problémové oblasti. Literatura uvádí , že pouze 15 procent celkového počtu požadavků uživatelů na zamýšlený informační systém je skutečně unikátních, tj. nových. Opakované využití požadavků předpokládá:
• snadnou dostupnost uživatelských požadavků předešle odvíjených informačních systémů,

2. Pravidlo připojení atributů

Jakákoliv položka, která má malý faktor proximity (blízkosti) k položce, jež byla identifikována jako entita, je pravděpodobně atributem této entity. Faktor proximity položky je definován jako rozdíl mezi postavením dané položky a postavením položky, která byla označena jako atribut entity. Toto pravidlo vyjadřuje skutečnost, že zpravidla jsou atributy entity uvedeny přímo v daném formuláři. Například atribut „daň“ u entity „faktura“ má malý faktor blízkosti k položce „cena bez daně“, a proto je také tato položka atributem entity „faktura“.
3. Pravidlo identifikace relace
Sleduje strukturu klíčových atributů ve zkoumaných entitách. Je-li ve struktuře klíčových atributů obsažen atribut nebo atributy, které jsou primárními klíčí jiné entity, pak jsou tyto entity v relaci.
Aplikací výše uvedených pravidel může analytik vyhotovit E-R model, který lze automatizovaně otestovat na datovou konsistenci. Formuláře jsou velice užitečným zdrojem informací, protože umožňují efektivní odvozování požadavků dané problémové oblasti, ve které je omezené použití řídících databázových systémů.

2.12.8. Analýza přirozeného jazyka

Pro většinu problémových oblastí je nejobyklejším vyjádřením znalostí přirozený jazyk. Potenciál odvozování požadavků z popisu ve formě přirozeného jazyka vychází ze skutečnosti, že vše, co je nutné znát o problémové oblasti, je už někde napsáno nebo vyjádřeno ve formě přirozeného jazyka. Přístupy analýzy přirozeného jazyka lze rozdělit do dvou základních kategorií, a to na:
• přímo působící na uživatele za účelem odvození jeho požadavků
• odvozující požadavky z textů v přirozeném jazyce.
Pro stanovení požadavků daným přístupem jsou rozhodující slovní zásoba, syntaxe a neformální atmosféra. Slovní zásoba obsahující přibližně 1000 výrazů z dané problémové oblasti je účinným komunikačním médiem při popisu jakékoliv představy. Syntaxe ve významu jazykové skladby je užitečná vlastnost přirozeného jazyka, která je běžná v každodenním životě a nevyžaduje zpravidla nároky na samostatnou výuku. Neformální atmosféra má za důsledek, že výpověď uživatele může být nejasná, nepřesná, neúplná a protichůdná. Je však velmi užitečná v počátečních fázích Requirements Engineeringu, kdy usnadňuje složitá jednání s uživateli, neboť dovoluje komunikaci bez nejistoty zacházení do detailu řešeného problému.
Automatizaci tohoto přístupu velmi komplikuje široké bohatství a mnohoznačnost přirozeného jazyka, která je také stále neřešitelným problémem v oblasti umělé inteligence. Automatizované přístupy analýzy přirozeného jazyka omezují vstupy do této činnosti na velmi malou podmnožinu přirozeného jazyka a vytvářejí model požadavků jako málo formalizovaný.

Scénář umožňuje poměrně snadný způsob ...

Scénář umožňuje poměrně snadný způsob získání expertizy od uživatele na velmi podrobné úrovni. Velmi vhodný je postup, kdy analytik používá scénáře, které jsou založeny na:
• obecném průběhu činnosti uživatele (vyúčtování faktury),
• paralelním průběhu činností (vyúčtování více faktur),
• neočekávaném ukončení činnosti (storno faktury).
Záleží tedy na analytikovi, aby vybral vhodný scénář. Je přitom omezen časem, který jemu může uživatel věnovat. Použití scénářů je tedy vhodné k objasnění sporných požadavků, zejména však je velice přínosné pro určení vlastnosti uživatelského rozhraní. Zatím neexistuje lepší způsob pochopení požadavků na interakci, než je konkrétní zkušenost s informačním systémem.
Techniky tvorby scénářů jsou založeny na principu, kdy uživatel snadněji předá své znalosti analytikovi v průběhu aktivního tvoření popisu své práce se zamýšleným informačním systémem než dotazováním nebo strukturovaným rozhovorem. Společně s technikou prototypování technika tvorby scénářů představuje při použití CASE nástrojů velmi slibné řešení komunikace mezi analytikem a uživatelem, které umožňuje vývoj obrazových výstupů, jež zobrazují požadavky na vlastnosti zamýšleného informačního systému.

2.12.7. Analýza formulářů

Na rozdíl od zatím popsaných technik analýza formulářů nepracuje s uživatelem, jako prvotním zdrojem informací o problémové oblasti. Analýza formulářů ze skutečnosti, že formulář tvoří základní komunikační médium ve většině organizací. Formulář představuje strukturovaný výběr proměnných, které jsou vhodně formátovány za účelem sběru a vyhledávání dat. Formulář je vhodný zdroj informací a problémové obblasti, protože:
• formulář představuje určitý formalizovaný model, který je více konzistentní než znalosti vyjádřené pomocí přirozeného jazyka,
• formulář je datovým modelem, který může poskytnout základ pro vývoj komponent funkčního modelu,
• ve formulářích jsou obvykle dostupné důležité informace,
• vytvoření formuláře je poměrně snadné, a proto je nejobvyklejším informačním médiem v organizaci,
• instrukce, které zpravidla doprovázejí formulář, představují dodatečný zdroj znalostí o problémové oblasti,
• analýza formulářů je snadněji automatizovatelná, než je tomu u textů, obrázků a podobně.

Formulář představují nejběžnější vstup ...

Formulář představují nejběžnější vstup do procesu tvorby datového E-R modelu („entity - relationship“), který obsahuje následující komponenty:
• entity jako objekty zájmu v problémové oblasti,
• relace jako významné vazby mezi entitami,
• atributy jako vlastnosti entit.

Analýza formulářů má za úkol zmapovat skryté pojmy ve formulářích a vytvořit E-R model. Obecně neexistují jasná pravidla identifikace entity, relaci a atributu. Tento nedostatek je překonáván použitím:
• manuálních metod odvození a vyhotovení E-R modelu z formuláře, které spoléhají na posouzení a zkušenosti analytika,
• automatizovaného postupu analýzy při použití heuristických pravidel, jak vycházejí z obsahu a konstrukce formulářů.
V praxi jsou samozřejmě žádány automatizované přístupy analýzy formulářů, protože snižují úsilí analytika a počet jeho omylů při konstrukci E-R modelu. Velice oblíbeným postupem analýzy formulářů, který používá tří druhů heuristických pravidel, je postup, který v roce 1988 zveřejnil M. Choobirech. Jedná se o tato pravidla:
1. Pravidlo identifikace entity
Jakákoli položka formuláře, jejímž zdrojem je jiná položka stejného nebo jiného formuláře, je potecinální entitou.

Dekompozice úkolů vzhledem ke kvalitní definici uživatelských požadavků ...

Dekompozice úkolů vzhledem ke kvalitní definici uživatelských požadavků na informační systém by měla sestávat z:
• hierarchie „úkolů–cílů–omezení“, která je přímo relevantní se systémem zpracování informací a která je rozpracována do nižších úrovní,
• prostředků, které povedou k realizaci daných cílů.
Pokud nenastane případ konfliktů cílů, musí být dosaženo shody struktury cílů a jejich předefinování do podcílů na nižších úrovních dané dekompozice. Cílem této činnosti je dosažení shody mezi účastníky procesu vývoje informačního systému, tzn. že musí být ohodnoceny tendence. Pokud například „zvýšení produktivity“ odboru může být dosaženo automatizací úlohy „A“ nebo úlohy „B“, pak musí být méně vhodná alternativa vzhledem k existujícím omezením vyloučena. Výsledkem této činnosti, která vyžaduje časté opakování, je specifikace úplného souboru uživatelských požadavků, který může být přímo validován z hlediska organizačních úkolů, stávajících omezení uvnitř organizace a okolního prostředí. Obecně lze analýzu cílů shrnout do následujících kroků:
• analýza organizace z hlediska jejího okolí v termínech úkolů, cílů a omezení,
• vytvoření dekompozice „úkol–cíl–podíl“, kdy je nutno vzít v úvahu podporu a konflikt vazeb mezi cíli na stejné úrovni včetně jejich omezení,
• validace modelu požadavků s cílem dosažení shody mezi zúčastněnými stranami,
• určení informační části v rámci dané dekompozice,
• vyloučení konfliktů vyplývajících z dekompozice pomocí vyhotovení „dohody“ mezi zúčastněnými stranami,
• výběr úloh, které budou podporovány informační technologií, pomocí vyloučení alternativ.

Analýza cílů je přínosná z následujících důvodů:

• analytici mají jasnou představu o problémové oblasti včetně jasného vymezení informačního systému v rámci hostitelského systému,
• je možno pochopit širší souvislosti uživatelských požadavků s ohledem na jejich význam z hlediska časového trvání,
• lze posoudit širší počet potenciálních řešení, která by se jinak mohla vytratit.
Analýza cílů je spojována s využitím umělé inteligence při modelování uživatelských požadavků vzhledem k jejich omezením. Tato metoda přináší efekt zejména u velmi rizikových projektů velkého rozsahu, ale dá se s úspěchem aplikovat i u menších projektů.
2.12.6 Tvorba scénářů
Scénářem se rozumí forma popisu pracovního postupu. Přístupy této kategorie spoléhají na univerzálnost formy šíření zkušeností v rámci dané organizace. Vlastní scénář ilustruje, jak bude zamýšlený informační systém, který je takto určitým způsobem vnímán uživatelem, uspokojovat jeho potřeby. Scénář je důležitým nástrojem tvorby sociálního názoru a participace uživatele na odvození požadavků, protože umožňuje podrobný popis výskytů interakce „člověk – počítač“.
Scénář může používat různá média (texty, obrázky, diagramy), které mohou být strukturovány do dialogů nebo rozsáhlých popisů. Existuje úzká souvislost mezi scénářem a prototypem. Prototyp napodobuje chování informačního sytému, obecně jako celku, zatímco scénář předpokládá očekávané užití informačního systému.

2.12.3 Strukturovaný rozhovor

Metodického přístupu pomocí strukturovaného rozhovoru je používáno pro získání více podrobných informací. Tato technika získávání požadavků vede uživatele k vytypování problémů z analyzované problémové oblasti. Při této technice analytik řídí rozhovor uvedením tématu, ukončením tématu, dílčími doplňovacími dotazy. Účelem strukturovaného rozhovoru je:
• vyplnění existujících informačních mezer v problémové oblasti,
• odstranění překážek při nedostatku shody mezi uživateli apod.,
• dosažení lepší podpory pro prostředí řešitelů.
Strukturovaný rozhovor je v praxi nutné i několikrát opakovat a velmi zde záleží na schopnosti řídit komunikaci s uživatelem, aby bylo dosaženo výše uvedených účelů.
2.12.4 Kolektivní přijímání rozhodnutí
Technikou, která má pomoci překonat nedostatek shody názoru na požadované řešení, je technika BCDA (Brainstorming Collective - Making Approach), která kombinuje invenci účastníků s kolektivním rozhodnutím pro lepší porozumění problémové oblasti ze strany analytiků. Technika BCDA řeší problém se stanovením uživatelské expertizy, kdy uživatel má určité psychologické zábrany, aby danou expertizu vyhotovil. Zároveň kolektivní rozhodnutí omezuje nedostatek shody vzhledem ke stanovený cílům či prioritám atd. daného projektu informačního systému. V průběhu aplikování techniky BCDA plyne informační tok mezi uživateli a řešiteli, ten pomáhá uživatelům pochopit základy informační technologie a řešitelům potřeby dané organizace.

2.12.5 Analýza cílů

Tato metoda, která se zaměřuje na úvodní etapu projektu, se soustředí na zodpovězení základních otázek, které souvisí s každým projektem informačního systému. Jedná se o otázky této kategorie:
• „Proč organizace potřebuje nový informační systém vzhledem k formulovaným požadavkům?“
• „Skutečně uživatele chtějí to, co požadují?“
Otázky, které jsou podobné uvedeným, posilují pochopení povahy charakteristických vlastností a omezení problémové oblasti, aby mohl následovně analytik přistoupit k formalizaci problému.
Smysl a cíl aplikování tohoto přístupu spočívá v pkusu:
• umístit daný problém do širšího kontextu,
• získat takové požadavky, které jsou skutečně správné.
Obecně každý sociálně technický systém vlastní soubor cílů, které mají být dosaženy. Technický pohled na daný systém, který je v tomto případě konkretizován informačním systémem, se snaží popsat a vysvětlit chování takového systému pomocí stavu. Stav systému je popsán v pojmech hodnot definovaného počtu parametrů. Cíl je určen jako cílový stav, tj. Jako dosažení požadovaných hodnot daného počtu parametrů. Cíle, které jsou konkretizovány velmi neurčitě, jsou označovány jako úkoly.
Měnící se stupeň konkretizace cílů úzce souvisí se stupněm řídící úrovně hostitelského systému, který je znázorněn na obrázku č. 6.

Obecně lze konstatovat...

Obecně lze konstatovat, že s vyšší úrovní řízení se zvyšuje abstrakce cílů, které jsou označovány spíše jako úkoly. Úkoly neurčují přesné termíny („KDY?“), množství („JAK MOC?“) nebo způsob („JAK?“) dosažení cílového stavu. To je úkolem jejich rozpracování na nižších úrovních řízení. Dekompozice úkolů do konkrétních cílů může být provedena dvěma základními způsoby, a to:
• konjuktivní dekompozicí typu „AND“, kdy ke splnění úkolu UK musí být dosaženo všech cílů C1, C2 ..... Cn;
• disjunktivní dekompozicí typu „OR“, kdy ke splnění úkolu UD stačí splnit alespoň jeden z cílů C1, C2 .... Cn.
Dekompozici „úkol–cíl–podcíl“ je třeba provádět s ohledem na úroveň řízení, protože při celkovém posuzování priorit je nutné posoudit případný positivní nebo konfliktní vztah cílů stejné úrovně. Vzájemně positivní jsou ty cíle, které mají positivní vliv na dosažení jednoho či druhého. U konfliktních cílů je tomu naopak. Například úkol „zvýšení automatizace“ je v konfliktu s úkolem „snížení investic“. Další důležitý moment dekompozice úkolů představuje omezení plného dosažení cílů. Tato omezení pramení z nitra dané organizace (personální struktura, finance atd.) nebo problémové oblasti, ve které daná organizace funguje (zákony, konkurence, dosažitelná technologie atd.). Smyslem dekompozice úkolů a určení hierarchie cílů je určení požadavků na informační systém vzhledem k problémové oblasti, protože ne všechny cíle v hierarchii organizace jsou relevantní ke specifikaci uživatelských požadavků.

2.12.1 Přímá komunikace s uživatelem

Získání požadavků od uživatelů, kteří pracují v problémové oblasti, se jeví jako velice intuitivní v případě těch uživatelů, kteří mají jasnou představu „co vyžadují“ od budoucího informačního systému. V praxi ale analytik musí spolupracovat ve většině případů s uživateli, jež je možné charakterizovat následujícími vlastnostmi:
• nemají jasnou představu, co požadují po zamýšleném informačním systému nebo jeho části,
• těžce a nepřesně vytvářejí popis problémové oblasti, jejíž problematiku má budoucí informační systém řešit,
• uživatele používají svůj specifický slovník, který je rozdílný od slovníku analytika, a tím dochází k problémům ve vzájemné komunikaci,
• nemají stimulaci k používání zamýšleného informačního systému, který je pro ně neznámý, a tím i nejsou ochotní poskytovat znalosti analytikovi.
K překonání výše uvedených problémů lze využít některé techniky, které zjednodušují převod znalostí od uživatele k hlavnímu tvůrci informačního systému. Mezi tyto základní techniky patří:
• rozhovor typu „open-end“,
• strukturovaný rozhovor,
• kolektivní přijímání rozhodnutí.

Tyto techniky vyžadují speciální komunikační dovednosti ...

Tyto techniky vyžadují speciální komunikační dovednosti na straně analytiků, protože mají citlivou a delikátní povahu, která může ovlivnit přístup uživatele k budoucímu informačnímu systému na základě jeho osobního vztahu k analytikovi. Nepřímý vliv na tyto techniky má mnoho činitelů, mezi klíčové náleží omezený čas analýzy a psychologické problémy uživatele při stanovení uživatelské expertizy. Dané dovednosti zpravidla analytik získá až na základě delší praxe.
2.12.2 Rozhovor typu „open - end“
K poměrně jednoduché technice, která se klade za cíl zachytit interakci mezi uživatelem a analytikem, patří rozhovor typu „open-end“. Analytik při této metodě získávání požadavků umožní uživateli volně a bez přerušování hovořit o jeho práci. Důraz je kladen na formálně uvolněnou atmosféru, ve které tento rozhovor probíhá a která má za úkol usnadnit tok informací od uživatele k analytikovi. Tato technika rozhovoru typu „open-end“ je vhodná pro získání celkového pohledu na problémovou oblast, ve které má být zamýšlený informační systém umístěn a vytypování klíčových požadavků uživatelů. Nicméně tato technika už není adekvátní při získávání detailní informace, protože „přerušování a připomínání“ v průběhu takového rozhovoru je většinou neúplné a nemá strukturu podporující zamýšlené získání podrobné informace z problémové oblasti.

Výstupem validace požadavků ...

Výstupem validace požadavků by měl být konsistentní model požadavků, který odpovídá očekávání a možnostem uživatelů. To znamená, že validace přináší určitý kompromis mezi tím, co požadují uživatelé, a tím, co je uskutečnitelné v rámci omezení projektu informačního systému.
Proces validace požadavků je aktivně ve všech etapách Reguirements Engineeringu. Potřeba validace nastává:
• s přírůstkem nové informace o problémové oblasti,
• v rámci specifikace modelu požadavků (i jeho části),
• při analýze a syntéze specifikace požadavků, protože analyzované informace musí být zkontrolovány na přesnost a syntetizované požadavky na logickou konzistenci a koherenci.
Validace požadavků uživatelem završuje navíc celkový proces Reguirements Engineeringu a rozhoduje o kvalitě vstupů do následujících etap vývoje informačního systému.
2.12 Přístupy zpracování uživatelských požadavků
Zpracování uživatelských požadavků lze chápat jako podproces vývoje informačního systému, který je velmi náročný na komunikaci mezi analytikem a uživatelem. Získání požadavků představuje shromáždění všech relevantních znalostí, které jsou nutné pro vytvoření modelu požadavků problémové oblasti. Po pochopení povahy, vlastností a omezení problému může analytik přistoupit k formalizaci uživatelských požadavků, která je vyjádřena specifikací požadavků. Následně může být přistoupeno k validaci požadavků uživatelem, která rozhoduje o konečném úspěchu projektu informačního systému.

Tato etapa klade vysoké nároky na dovednosti analytika ...

Tato etapa klade vysoké nároky na dovednosti analytika vzhledem ke komunikaci s uživatelem a často na rychlé získání základních znalostí z problémové oblasti. Paradoxem však je skutečnost, že se dobrý analytik dokonce může rozsahem získaných znalostí stát v rámci řešení projektu expertem v dané problémové oblasti. Hlavní problémy zpracování uživatelských požadavků lze v zásadě definovat následujícím způsobem:
• znalosti nejsou zpravidla ve tvaru, který může být použit analytikem,
• znalostí ze zdrojů informací, které představují lidé „experti“ se získávají velmi obtížně.
Mezi základní přístupy, které pomáhají získat a formalizovat požadavky uživatelů, patří následující přístupy:
• přímá komunikace s uživatelem,
• analýza cílů,
• tvorba scénářů,
• analýza formulářů,
• analýza přirozeného jazyka,
• opakované využití požadavků,
• analýza úkolů,
• sociálně-technický přístup.

Jedná se o modely:

• podnikání,
• funkčních požadavků,
• nefunkčních požadavků.
Při tvorbě modelů se musí brát ohled na druh uživatele, se kterým analytik komunikuje, protože co může být jasné vývojáři, může být nepochopitelné uživatelům.
Specifikace požadavků je ústředním procesem celého Reguirements Engineeringu, protože řídí ostatní procesy získání i validace požadavků. V průběhu specifikace požadavků může být zřejmé, že je nutné získat více informací o problému. Tak se spustí paralelně proces získání požadavků, který by měl potřebné informace dodat. Obdobná situace nastává mezi specifikací a validací. Například dokončení specifikace uživatelského rozhraní informačního systému je schvalováno uživatelem. V případě uživatelova nesouhlasu je nutná další analýza v rámci specifikace požadavků.
2.11 Validace požadavků
Validace požadavků si klade za cíl ověřit, zda je řešení odpovídající problému. Ve většině metod, které se zabývají Reguirements Engineeringem, není proces ověření požadavků vyčleněn jako samostatná činnost, ale je součástí specifikace požadavků. Pro osamostatnění této činnosti hovoří její koncepční význam pro vývoj informačního systému. Samotná validace požadavků je definována jako proces, který přezkoumává, zda model požadavků odpovídá záměrům a možnostem uživatele. Potřeba přezkoumání nastává, je-li nutné:
• na základě nově získané informace přizpůsobit stávající model požadavkům,
• rozdílné informace integrovat do soudržného celku.

Validace požadavků není aplikována pouze na konečném formalizovaném modelu požadavků...

Validace požadavků není aplikována pouze na konečném formalizovaném modelu požadavků, ale na všech přechodně vytvořených modelech včetně nových nezpracovaných informací v rámci získávání požadavků. V tomto smyslu je možno pohlížet na validaci požadavků jako na požadovanou komunikaci mezi ostatními účastníky procesu Reguirements Engineeringu.
Vstupem do procesu validace požadavků je jakýkoli model požadavků (formalizovaný, neformalizovaný). Informace o problémové oblasti musí být ověřeny na přesnost, konsistenci, relevanci k danému projektu informačního systému. Podobně musí být ověřen formalizovaný model požadavků po částech i jako celek.
Proces validace požadavků vyžaduje interakci mezi analytiky a uživateli, kteří pracují v dané problémové oblasti. Tento proces je podobný vědeckému procesu, kdy je formulována nová teorie (specifikace požadavků), která je postupně testována pomocí provedení experimentů (validace požadavků). Analytik se při použití zdravého rozumu nemusí příliš často uchylovat k experimentům. Ve vědeckém pojetí je pojem validace charakterizován pomocí dvou typů činností, a to jako:
• příprava prostředí pro experiment, kdy techniky vývoje informačního systému vyžadují určitou přípravu prostředí, například u prototypování nebo animace je nutné vytvořit určitou napodobeninu informačního systému,
• provedení experimentu a analýza výsledků, kdy techniky spoléhají na velmi obsáhlou interakci mezi analytikem a uživatelem při použití imaginárních scénářů, které simulují provozování informačního systému.

Získávání požadavků lze charakterizovat jako úvodní proces ...

Získávání požadavků lze charakterizovat jako úvodní proces Reguirements Engineeringu, který poskytuje surový materiál procesu specifikace požadavků. Potom však probíhá paralelně s procesy specifikace i validace požadavků v rámci celého životního vývoje informačního systému, protože s každou jeho etapou nastává určité upřesnění řešení vzhledem k měnícím se podmínkám problémové oblasti.
2.10 Specifikace požadavků
Na specifikaci požadavků lze nahlížet jako na dohodu mezi vývojáři a uživateli informačního systému, ve které je definováno funkční chování informačního systému bez popisu, jak bude této funkcionality dosaženo.
Účelem specifikace požadavků je odvození formalizovaného modelu informačního systému, který je pak následně využíván v dalších etapách jeho vývoje. Tento model se pak stává ústředním modelem celého vývoje, protože je kontrolován se všemi následujícími etapami vývoje informačního systému.
Vstupem do procesu specifikace požadavků jsou znalosti o problémové oblasti hostitelského systému, které byly do procesu dodány pomocí procesu získání požadavků. Tyto informace přicházejí na vstup obvykle ve velmi „surovém“ formátu, který musí být přepracován do formalizovaného tvaru modelu specifikace požadavků. Informace, které se týkají záměrů hospodářské organizace, musí být presentovány s ohledem na jejich vliv na informační systém. Další znalosti, které jsou produkovány ověřovacím procesem, mají rovněž vliv na formalizovanou specifikaci. Změny formalizovaného modelu požadavků způsobují informace, jež vypovídají o platnosti požadavku a o jeho prioritě.