- Informace

VUT v Brně
Fakulta strojního inženýrství
Ústav automatizace a informatiky
Studijní text k předmětu
Navrhování systémů řízení
(kódové označení předmětu v učebním plánu: VNS)
Obsah:
1 Komponenty,funkce, architektura informačních a řídicích systémů.
2 Systémová integrace v dodávkách řídicích systémů.
3 Modely životního cyklu tvorby software.
4 Objektově orientované metody analýzy a návrhu.
5 Funkce a náplň produktů pro počítačovou podporu softwarového inženýrství
6 Jakost software a testování programů.
7 Model CMM a V-model
8 Provozování řídicích systémů
9 Navrhování projektů řídicích systémů
10 Síťová analýza a podrobné plánování projektů řídicích systémů
11 Implementace projektů řídicích systémů
12 Týmová práce a organizace týmů při implementaci řídicích systémů
13 Analýza rizik projektů automatizovaných řídicích systémů
Seznam literatury
Zadání seminární práce
Zpracoval: Doc. Ing. Branislav LACKO, CSc., garant předmětu
BRNO, srpen 2006
1 Komponenty, funkce, architektura informačních a řídicích systémů
1.1 Vymezení automatizovaných informačních a řídicích systémů
Termín „informační systém“ je v současnosti velmi často používán. Dotkněme
problematiky vlastního názvu předmětu našeho zájmu. Západní svět vždy hovořil (a hovoří) o
informačních systémech (Information Systems). Někdy se používá celé řady jiných termínů a
zkratek - MIS (Management Information Systems), BMS (Business Management Systems),
ERP System (Enterprise Resource Planning Systém) a další. Výrazná převaha informačních
funkcí v západních systémech vedla k jednoznačnému termínu používaného dnes
"informační systém".
Informační systém firmy se skládá z neautomatizované a automatizované části.
Neautomatizovaná část představuje činnosti, které se provádějí ručně. Automatizovaný část
informačního systému využívá k automatizaci různých prostředků informačních,
komunikačních a dalších technologií.
Informační systém firmy
Neautomatizovaná část
Automatizovaná část
Na tuto skutečnost je nutno pamatovat ze dvou důvodů:
•
Při návrhu informačního systému je potřeba rozhodnout, které činnosti je vhodné a
efektivní automatizovat a které ponechat, aby se prováděly ručně.
•
Při provozu informačního systému je nutno mít na paměti, že ne všechna data jsou
uložena v databázích, aby se mohla zpracovávat počítačovými programy. Zejména
řadu strategických informací musíme získat mimo provozované databáze a zpracovat
ručně.
Význam složky řízení je zdůrazněn u automatického řízení v angličtině termínem
Control System. Se zdokonalováním informačních technologií dochází k nárůstu počtu
automatizovaných řídicích funkcí, což je jeden ze současných význačných vývojových trendů
v této oblasti. Také řídicí systém firmy má svoji automatizovanou a neautomatizovanou část.
V používané anglosaské terminologii se však termín Automatic Control System používá
výhradně pro takové systémy, které mají řízení plně automatizované.
Proto budeme dále používat zkratku AIS (automatizovaný informační systém)
k označení předmětu našeho zájmu, i když budeme uvažovat, že tento systém má
automatizovánu také celou řadu řídicích funkcí.
Automatizovaným informačním systémem (AIS) rozumíme soubor technických
prostředků (Hardware), programových prostředků (Software) a organizačních prostředků
(Orgware) vzájemně účelně vybraných a propojených pro automatizované získávání
potřebných informací k rozhodování a řízení.
V současné době, kterou je zvykem označovat jako éru informační společnosti
(Information Society), jsou informační systémy budovány ponejvíce jako automatizované,
takže se mnohdy označení „automatizovaný“ vynechává a hovoříme jen o informačním
systému (IS), i když v běžném rozhovoru myslíme automatizovaný informační systém.
Hardware
Software
AIS
Orgware
Technické vybavení počítačů (Hardware) a programové vybavení počítačů (Software)
patří mezi informační a komunikační technologie (ICT – Information and Communication
Technology). Obecně pod pojmem informační a komunikační technologie rozumíme souhrn
všech rozličných technických, programových, organizačních a jiných prostředků, technik a
služeb, které můžeme využívat při jednotlivých operacích s informacemi (zpracování
informace, ukládaní informace, přenášení informace, apod.). Informační technologie
představují podmnožinu technologií, kterými disponuje naše současná společnost
(Information Society – viz portál http://www.europa.eu.int):
Všechny používané technologie
v současné společnosti
Informační
technologie
Účelem automatizovaného informačního systému firmy je poskytovat informace pro
podporu rozhodování a řízení určité instituce, aby mohla dobře plnit svoje funkce.
Poskytované informace proto musí být:
významné - přesné - včasné - dostatečné - úplné - srozumitelné.
Aby AIS poskytoval takové informace musí mít následující vlastnosti:
- Poskytovat komplexně potřebné funkce, nutné pro zajištění všech činností, které se mají
automatizovat.
- Mít vhodné provozní parametry, aby jeho využívání bylo jednoduché, chod spolehlivý,
požadované provozní náklady co nejnižší a rychlost poskytování informací přiměřená
požadavkům.
- Umožňovat relativně jednoduché a rychlé přizpůsobování svých funkcí a vlastností
změněným požadavkům.
- Musí mít dobře vyřešeno zabezpečení proti zneužití a proti poškození a to jak sebe sama,
tak informací, které jsou v něm uloženy.
- Vykazovat parametry vysoké jakosti a to jak v průběhu dodávky, tak návrhu a provozu.
- Jeho cena musí být přijatelná pro uživatele.
- Mělo by být pro něj charakteristické využívání dostupných progresivních informačních
technologií, aby nebyl v krátké době zastaralý a překonaný.
- Jeho koncepce i provedení by měly využívat racionální a objektivně zdůvodněné
principy.
AIS s výše uvedenými vlastnostmi může firma dosáhnout jen za následujících podmínek,
které představují kritické faktory úspěchu (Critical Success Factors):
- Realizace AIS je řízený a cílevědomý proces, který je nedílnou součástí dění v celé firmě.
- Všechny činnosti, které se týkají jeho realizace jsou prováděny jakostně.
- Vrcholové vedení firmy, vedoucí na všech dalších řídicích úrovních a pracovníci firmy
věnují realizaci a provozování AIS systematickou pozornost.
- Při návrhu a realizaci jsou využity progresivní poznatky vědy a techniky z takových oblastí
jako kybernetika, softwarové inženýrství, rizikové inženýrství, projekt management, apod.
Následující Ishikawův diagram schematicky zachycuje podmínky úspěšného zavedení
AIS:
Vhodně
definované
cíle AIS
Správný
postup
realizace
AIS
Dobré
odborné
znalosti
pracovníků
firmy o IT
Úspěšně zavedený
informační systém
Odhodlanost
a nasazení
vedení
Informovanost
pracovníků
firmy
Poznamenejme, že v poslední době do popředí vystupují ty informace, které představují
ZNALOSTI. Proto se často hovoří o skutečnosti, že současná informační společnost přechází
do podoby znalostní společnosti (Knowledge Society).
1.2 Komponenty AIS
Komponenty, které obsahují AIS, můžeme rozdělit do následujících množin a
podmnožin. Pro určitý AIS jsou pak naplněny konkrétními prostředky.
Technické prostředky
Počítače (Osobní počítače, servery, pracovní stanice, specializované
řídicí počítače, apod.) a jejich bezprostřední komponenty (operační
paměti, přídavné procesory, rozhraní, přídavné procesory)
Periferní zařízení (tiskárny, souřadnicové zapisovače, digitizéry,
snímače
čárových kódů a čipových karet, speciální displeje, apod.)
Síťové komunikační prostředky (kabeláž sítě, komunikační počítače,
odbočovače v sítích, síťové karty do osobních počítačů, modemy,
zesilovače signálu, apod.)
Doplňková a podpůrná zařízení (zálohovací zdroje síťového napětí,
filtry před obrazovky, specializovaný nábytek, klimatizační zařízení,
měřící a testovací zařízení)
Provozní materiál (papír do tiskáren, diskety, výměnné optické disky,
náplně do tiskáren)
Dokumentace technického vybavení
Programové prostředky
Operační systémy (základní operační systémy, síťové operační systémy,
operační systémy řízení reálného času) a jejich přídavné části
Systémové programy, které provádějí speciální řídicí a provozní funkce
Vývojové prostředky (programovací jazyky, knihovny programovacích
jazyků, testovací prostředky, vývojová prostředí)
Databázové systémy a jejich součásti
Standardní aplikační programy (tabulkové procesory, textové editory,
presentační programy, elektronická pošta, apod.)
Speciální aplikační programy, zhotovené podle individuálních
požadavků
Organizační prostředky
Pokyny pro obsluhu a návody k obsluze
Provozní pokyny AIS
Směrnice zajišťující dělbu a koordinaci prací kolem AIS
Směrnice stanovující zodpovědnost za správnost vkládaných dat
Směrnice vymezující oprávněnost přístupu k datům a oprávněnost
manipulace s daty
Pokyny pro archivaci dat a pořizování bezpečnostních kopií
Pokyny k provádění antivirové ochrany a k zabezpečení dat
před úmyslným zneužitím, zcizením nebo poškozením.
Pokyny pro vyhodnocování a sledování činnosti AIS včetně
evidence nákladů na AIS
Zásady pro údržbu a inovaci AIS
Pokyny a zásady pro zajišťování bezpečnosti AIS
Ze uvedených množin komponent je často podceňována a přehlížena právě třetí
množina prostředků organizačního zabezpečení.
1.3 Rozdělení AIS
AIS můžeme rozdělovat podle různých hledisek. Rozdělení AIS nám umožňuje přesněji
vymezit potřebné technické, programové a organizační vybavení a stanovit postupy pro návrh
a realizaci AIS.
Rozdělení podle umístění AIS v pyramidě řízení:
EIS
MIS
RTCS
Strategická úroveň řízení
Taktická úroveň řízení
Operační úroveň řízení
EIS (Executives Information System) - automatizovaný informační systém pro vrcholové
strategické řízení podporující automatickou analýzu dat z hlediska dlouhodobých vývojových
trendů (OLAP - On Line Analysing Processing)
MIS (Management Information System) - automatizovaný informační systém pro vedoucí
pracovníky střední úrovně a referenty, podporující transakční zpracování firemních údajů
fakturách, objednávkách, zakázkách, mzdách a platech, skladovaných položkách, apod.).
RTCS (Real Time Control System) - automatizovaný řídicí systém, který na operativní
úrovni v reálném čase řídí provádění jednotlivých výrobních úkonů pro konkrétní operace ve
výrobě.
Rozdělení AIS podle velikosti:
• mikro AIS : jeden až pět isolovaných, samostatných osobních počítačů
• malý AIS: do deseti osobních počítačů propojených vzájemně do počítačové lokální
sítě
• střední AIS: do 100 počítačů propojených do jedné nebo více lokálních sítí, ve kterých
jsou využity servery
• velké AIS: kolem 1000 počítačů s mnoha lokálními počítačovými sítěmi a servery
propojenými na jiné externí sítě
• velmi velké AIS: přes 1000 počítačů propojených do rozsáhlých lokálních i externích
sítí s dálkovým přenosem dat.
Rozdělení AIS podle obsahového zaměření:
• AIS pro průmyslové výrobní podniky s přetržitou výrobou (strojírenství,
elektrotechnika, spotřební zboží, apod.)
• AIS pro kontinuální výrobu (potravinářství, chemická výroba, energetika, apod.)
• AIS pro finanční sektor (banky, pojišťovny, burzy, spořitelny)
• AIS pro státní a jiné administrativní instituce včetně školství
• AIS pro výzkumné firmy, vědecko-technické firmy a vývojové firmy
• AIS pro speciální oblasti (policie, armáda, kosmický výzkum).
Rozdělení AIS podle automatizovaných funkcí:
•
•
•
•
•
statistické AIS (zajišťující jen zpracování evidence a statistických výstupů)
bilančně - plánovací AIS
AIS s doplněnými řídicími funkcemi (alespoň některé funkce jsou realizovány
v uzavřené řídicí smyčce)
AIS systémy s využitím předpovědi a zjišťování následků případných rozhodnutí
(např. simulací)
AIS s využitím umělé inteligence pro podporu rozhodování
Rozdělení AIS podle způsobu dodávky:
• automatizované informační systémy dodávané jako hotový produkt
• automatizované informační systémy vytvářené individuálně na objednávku podle
požadavků zákazníka
• automatizované informační systémy dodávané jako prototyp, tj. dodá se řada
připravených skeletů programů (prototyp), které se pak upravují a dopracovávají
podle požadavků zákazníka např. zadáním hodnot předem připravených parametrů,
apod.
Každý z těchto způsobů dodávky AIS má své výhody a nevýhody.
Hotový produkt
Čas
Téměř ihned
Cena
Jakost
Velmi nízká cena
Viditelná jakost a
malým počtem chyb
Přizpůsobení
Firma se musí
přizpůsobit SW
Malé firmy
Vhodná velikost
firmy
Vývoj podle
požadavků
Velmi dlouhá doba
vývoje
Velmi vysoká cena
Předpokládaná jakost
s velkým počtem
chyb
Software se
přizpůsobuje firmě
Velmi velké firmy
Prototyp
Relativně krátká
doba
Přijatelná cena
Částečně viditelná
jakost a přijatelné
množství chyb
Oboustranné
přizpůsobení
Střední a velké firmy
Aby mohl být softwarový systém prohlášen za prototyp, měl by splňovat následující
požadavky:
• Od začátku musí být vyvíjen jako prototyp
• Přizpůsobování se musí realizovat racionálním způsobem (parametrizace,
makroinstrukce, přizpůsobováním objektů) nikoliv přeprogramováváním
• Koncepce prototypu musí být poměrně dosti blízká cílovým požadavkům.
• Finální dokumentace musí vznikat jako vedlejší efekt procesu přizpůsobování
prototypu požadavkům uživatele a nikoliv jednotlivými zásahy do stávající
dokumentace.
Rozdělení podle využívání databázového systému:
• bez databázového systému
• s využitím lokálních databází (heterogenní nebo homogenní řešení)
• s centralizovanou databází
• s databází architektury client/server (heterogenní nebo homogenní řešení)
•
s decentralizovanou databází
Rozdělení podle způsobu propojení na řízený proces:
• off-line propojení
• on.line propojeni
• smíšené propojení
Z hlediska propojení počítačů s procesem, o kterém má poskytovat automatizovaný systém
informace je potřeba rozlišovat nepřímé (off-line) propojení s procesem
Počítač
Doporučené hodnoty pro ruční řízení
Ruční vstup dat
Uživatel
Pozorování procesu uživatelem
Ruční řízení procesu uživatelem
Proces (výrobní nebo nevýrobní)
a přímé (on-line) propojení procesu s počítačem
Uživatel
Poskytované informace
Počítač
Automatizované propojení
Proces (výrobní nebo nevýrobní)
V případě nepřímého propojení s procesem dochází :
- ke zpožďování vkládaných dat ručním způsobem, který je pomalý a nemusí
být proveden bezprostředně v okamžiku zpozorování potřeby data do počítače vložit
(pracovník nevloží do počítače objednávku, kterou obdržel faxem, protože přerušil práci a je u
zubního lékaře)
- ke zkreslování dat, které může být způsobeno omyly (překlep, přehlédnutí,
opomenutí, apod.) nebo vědomým uváděním nepřesných údajů (pracovník vloží do počítače
větší počet odpracovaných hodin, aby dostal více zaplaceno).
Obojí negativně ovlivňuje jakost řízení. Proto by měl být vždy preferován přímý
vstup do počítače prostřednictvím různých čidel: automatické měření, čipové karty, čárové
kódy, elektronická výměna dat, apod.
1.4 Architektura AIS
Architekturou AIS rozumíme aplikaci různých koncepcí, které charakterizují řešení
základních problémů při návrhu, realizaci a využívání AIS.
Koncepce orientace AIS
Minulé systémy byly orientovány na získávání informací o stavu podniku. Dokonce
často
chyběly i funkce strategického řízení zřejmě jako důsledek skutečnosti, že cíle
v nich
byly direktivně určovány "shora". Dnes však podniky musí požadovat informace o vnějším
trhu, o chování konkurence, o finanční situaci v bankovnictví, o chování a požadavcích svých
zákazníků a atd. To jsou informace z okolního prostředí firmy, které umožňují firmám obstát
v konkurenční soutěži
Koncepce zaměření AIS
Řada zastarale pojatých IS byla a je především zaměřena na hromadné zpracování dat
v dávkách, které řešilo automatizaci administrativních a správních agend. V budoucnu se
bude požadovat především poskytování informací pro řízení jako přímá podpora firemního
managementu. S tím souvisí i jiný pohled na přínosy informačních systémů. V minulosti se
preferovaly přínosy v oblasti různých druhů úspor (snižování počtu pracovníků, snižování
materiálových nákladů apod.). V budoucnosti budou systémy hodnoceny především podle
přínosu v podpoře rozhodovacích procesů firmy tak, jak budou schopny podpořit realizaci
strategických a taktických cílů a pomoci firmě nejlépe zhodnotit vložený kapitál. Tomu
odpovídá i změna v prioritě jednotlivých subsystémů informačního systému. Dříve bylo
těžiště v oblasti výroby, v současnosti je kladena priorita do obchodní oblasti a ekonomické
oblasti. (např. CRM Customer Relationship Management, HRM – Human Resource
Management, apod.).
Koncepce filosofie AIS
První informační systémy se v důsledku možností počítačů zaměřovaly na zpracování
evidenčních dat statistickým zpracováním získaných údajů. Později při dostatečném množství
dat a zlepšeném výkonu počítačů mohly být systémy koncipované jako bilanční, které
zajišťovaly provádění souhrnných bilančních výpočtů. Ty se zdokonalovaly do té míry, že
dosáhly možností výpočtů plánů v různých variantách, které byly předkládány jako podklad k
rozhodování.
Až do tohoto okamžiku můžeme systémy považovat za informační. Jakmile však
počítač dovede vytvořit plán v několika variantách a vybrat optimální variantu k ovládání,
dochází zde ke kvalitativní změně - systém můžeme začít označovat jako řídicí.
V počátcích docházelo spíše k automatizovanému ovládáním, protože chyběla zpětná
vazba nebo ta, která existovala, měla velké časové zpoždění.
Výkon, technické a programové vybavení počítačů však dovoluje skutečné řízení v
reálném čase způsobem, který připomíná automatickou regulaci - t.j. automatické dodržování
předepsaných hodnot.
Probíhající regulační pochody mohou využít predikčních metod simulace pro
zodpovězení otázek typu: "Co se stane, když...?". Takové systémy dovolují vedoucím
pracovníkům prozkoumat následky možných rozhodnutí dříve, než jsou skutečně provedena.
Moderní řídicí systémy můžeme vybavit schopností adaptability tak, aby byly
schopny přizpůsobit se změněným podmínkám trhu nebo stavu firmy. To většinou znamená
využít i metod umělé inteligence a koncipovat systémy tak, aby byly schopny v bázi znalostí
shromažďovat sami určité poznatky a akceptovat jim předkládané zkušenosti. Znamená to
využít poznatků z realizace expertních systémů pro řízení.
Koncepce ve způsobu poskytování informací.
První informační systémy doslova zaplavovaly své uživatele informacemi.
Připomeňme, že počítače byly často nazývány továrnami na potištěný papír. Jako reakci na
tuto kritiku nové systémy, které začaly využívat terminálů, byly navrženy tak, že uživatel
dostal jen ty informace, které si výslovně vyžádal. To se sebou přineslo problém komunikace
uživatelů - neprogramátorů s počítačem. Ještě i dnes není optimálně vyřešen problém, jak
uživatele - neprogramátora informovat jaké informace může od systému požadovat a jakým
způsobem má své konkrétní požadavky specifikovat. Navíc však takový způsob vykazoval
velké množství cenných informací, které nebyly uživateli presentovány prostě proto, že si je
uživatel nevyžádal z neznalosti nebo z nepozornosti či z prostého opomenutí. Budoucí
systémy budou muset nabízet informace metodou sistace uživatele, který odsouhlasí, zda
nabízené informace se mu mají presentovat či nikoliv. Dále systémy budou muset být
vybaveny "informačními filtry", které si uživatel bude moci nastavit pro odstranění informací
pro něj neaktuálních a nevyžadovaných a naopak těch, které považuje v určitém časovém
úseku za důležité. Presentace informací bude muset být prováděna postupně s možností
zásahu od uživatele tak, aby uživatel mohl specifikovat formu informací a jejich rozsah, jak
bezprostředně potřebuje k řízení. Zvlášť důležité informace budou muset mít možnost být
presentovány tak, aby nemohly být přehlédnuty a opomenuty. Často se v této souvislosti
hovoří o tzv. inteligentních informačních filtrech.
V této souvislosti poznamenejme, že presentace informací stále více preferuje
barevnou grafickou formu, před klasickou alfanumerickou tabulkovou formou a do budoucna
je nutno rozhodně počítat s hlasovým výstupem z počítače a zvukovou signalizací.Nadějné
jsou i výsledky vstupu do počítače hlasem a snímání rukou psaných dokumentů.
Informační systémy budou na sebe přebírat stále více komunikačních služeb.
Počítačová síť Internet a lokální počítačové sítě jsou dnes ideálním prostředím pro realizaci
elektronické pošty a zajišťování skupinové a týmové komunikace (groupware, teamware). V
tomto smyslu informační systémy stále více uskutečňují program "bezpapírové výměny
zpráv" (paperless comunnication).
Koncepce dynamiky růstu
Řada podniků, které začínaly v roce 1990 po svém ustavení (založení) se dvěma
mikropočítači typu PC má dnes 50, 80 ba i stovky mikropočítačů PC propojených lokální sítí.
Je zřetelné, že rozvoj jejich informačního systému bude dále pokračovat tímto vysokým
tempem. Tento trend je podporován jednak stále klesající cenou výpočetní techniky jednak
zvyšujícím se tlakem na komplexní pojetí informačních systémů, protože takové pojetí přináší
podnikatelům četné výhody:
- účinnou podporu rozhodovacích procesů
- snižování stavu meziskladů i skladů
- snižování nákladů na administrativní pracovní síly
- zvýšení rychlosti komunikačních procesů
- zvýšení kvality řady činností (kvalita korespondence, kvalita prospektové , nabídkové a
technické dokumentace, kvalita konstrukčních výpočtů a kvalita výkresové dokumentace
atd.).
Stále více se informační technologie propojují s komunikačními technologiemi, jak je to
možno demonstrovat na spojení mezi počítačovou sítí Internet a mobilními telefony (např.
posílání zpráv SMS, používání mobilního telefonu jako terminálu sítě Internet, apod.)
Na druhé straně přináší tento dynamický rozvoj informačních systémů problémy,
pokud se firma neorientuje od začátku cílevědomě na otevřenou, flexibilní koncepci
informačního systému.
Koncepce struktury AIS
Pod pojmem struktura AIS rozumíme rozdělení AIS do určitých částí, propojených
navzájem.
Nejčastěji definujeme strukturu AIS z hlediska jednotlivých funkčních modulů resp.
subsystémů jejich prostým výčtem. Např. možná struktura AIS pro typickou strojírenskou
výrobní firmu může být následující:
Informační systém XYZ
Modul databáze
- řízení databáze
- ukládání a čtení dat
- bezpečnostní kopie a protokolování změn v databázi
- obnova databáze po havárii
- dotazování a poskytování zpráv
- definování hesel a přístupových práv
Modul ekonomický
- vedení účetnictví
- finanční operace
- výplaty mezd a platů
- ekonomické rozbory
- vnitropodnikové hospodaření
- vnitropodniková banka a pokladna
Modul personální evidence
- evidence pracovníků
- plánování osobního rozvoje
- evidence kurzů
- organizační schema
- evidence pracovních smluv
- evidence popisu pracovních funkcí
Modul obchodní
- marketing
- nabídky
- objednávky cizí
- objednávky vlastní
- faktury vlastní
- faktury cizí
- vedení obchodních příkladů
- zásoby a nákup
- řízení skladů
- expedice
Modul řízení jakosti
- podpora příručky jakosti
- podpora směrnic a prováděcích pokynů
- statistické řízení jakosti
- evidence odchylek a opatření
- sledování nejakostní výroby a nákladů na nejakostní výrobu
- vstupní, mezioperační a výstupní kontrola
- evidence a certifikace měřidel
Modul výroby
- lhůtové plánování výroby
- operativní plánování výroby
- evidence zadávané, odváděné a rozpracované výroby
- evidence výkonů a disponibilních kapacit
- evidence meziskladů
- plánování vnitropodnikové dopravy
- přímé řízení výrobních strojů
Modul technické přípravy výroby
- podpora konstrukčních prací
- kusovníky
- technologické postupy
- podpora programování číslicově řízených obráběcích strojů
- technicko-ekonomické rozbory
- plánování technického rozvoje
- podpora normalizace a evidence patentů
- shromažďování vědecko-technických informací
Modul pro evidenci majetku
- evidence investičního majetku
- evidence drobného neinvestičního majetku
- plánování a evidence údržby a oprav
- plánování a evidence investičních akcí
Modul pro podporu vrcholového vedení
- agregované ukazatele stavu firmy
- podpora strategického plánování
- provádění ekonomických rozhorů hospodaření firmy
- zajišťování externích informací pro strategické řízení
Modul pro podporu pomocných činností
- evidence jízd a a vozidel
- podnikový archiv
- ochrana a bezpečnost majetku firmy
- podpora právních informací
atd.
Uvedený příklad má zdůraznit provázanost struktury automatizovaného informačního
systému s funkčními požadavky, kladenými na systém.
2 Systémová integrace v dodávkách automatizovaných systémů
2.1 Všeobecně o systémové integraci
V nadpisu bylo použito obecnějšího výrazu „automatizovaný systém“, aby bylo
zdůrazněno, že principy a postupy systémové integrace lze aplikovat na dodavky jakéhokoliv
automatizovaného systému, nejen AIS.
Nákup, přizpůsobení a kompletaci potřebných komponent pro automatizovaný systém
lze zajistit dvěma způsoby.
Klasický způsob představuje výběr komponent uživatelem a jejich objednání u
různých dodavatelů a jejich následnou kompletaci do potřebné finální podoby.
Dodávky od různých dodavatelů – kompletaci provádí zákazník
Zákazník
D1
D2
D3
D4
D5
síť
hardware
software
OS + DBS
jiné
Takové řešení klade vysoké požadavky na znalosti a zkušenosti pracovníků u
zákazníka, který navíc sám sobě zodpovídá za kvalitu vzájemné kompletace jednotlivých
komponent.
Proto stále více firem objednává dodávku automatizovaného systému u firmy, která je
schopna zajisti funkci „systémového integrátora“.
Forma komplexní dodávky prostřednictvím systémového integrátora
Systémový
Zákazník
integrátor
D1
D2
D3
D4
D5
síť
hardware
software
OS + DBS
jiné
Výhodou takového řešení je skutečnost, že systémový integrátor garantuje svými
znalostmi a zkušenostmi kvalitu vzájemného propojení všech potřebných komponent.
Nevýhodou je, že je potřeba počítat s náklady, které si naúčtuje systémový integrátor za svoji
práci.
Často některé části AIS jsou dodávány formou systémové integrace, některé nikoliv,
takže se jedná o kombinaci obou způsobů. Výhodou je samozřejmě kompletní dodávka celého
AIS formou systémové integrace.
V každém případě je však nutné zvážit různé možnosti realizace AIS např. formou
rozhodovacího stromu.
Stromový diagram volby
informačního systému pro
firmu
A
B
C
..
N
Hotový produkt
Vlastní přizpůsobení
a
Prototyp
b
Hotový produkt
Přizpůsobení externí firmou
..
Výchozí bod
n
VÝVOJ nového modelu
Samostatný vývoj
Decentralizovaný vývoj
Centralizovaný vývoj
Externí firma
1.
2.
3.
..
X.
2.2 Vícekriteriální rozhodovací analýza
Při návrh a realizaci AIS se často vyskytují situace, kdy musíme provést výběr
z několika možných variant volby na základě více různých kritérií.
V takovém přídě je nejlépe provést výběr varianty řešení s pomocí vícekriteriální
rozhodovací analýzy.
Tato metoda patří do skupiny postupů pro podporu rozhodování ( v
záp. zemích označovaných jako Decision Analysis). Tato metoda pomáhá v rozhodování za
situace, kdy se máme rozhodnout mezi několika variantami řešení problému a pro výběr jsme
každou variantu ohodnotili podle několika různých faktorů. Základem je sestavení následující
tabulky:
Kritéria
x
y
y
Výsledné
+Váhy
hodnocení
VARIANTY
A
B
C
D
Např. při výběrovém řízení uchazečů o studijní pobyt v zahraničí vybereme toho, který má
nejlepší prospěch (jednotliví studenti představují varianty řešení, jednotlivé předměty jsou
faktory, které hodnotíme známkami 1-4). Např.:
Matematika
Fyzika
Chemie
Faktory
Varianty
J.Kyslík
F.Dusík
A.Hubatá
1
3
3
3
2
2
3
3
1
Vysl. hod.
7
8
6
Celkové hodnocení jednotlivých variant (studentů) získáme tak, že sečteme hodnoty jejich
faktorů (známek) :
J. Kyslík 7
F. Dusík 8
A. Hubatá 6
Vybereme variantu (studenta), který má nejmenší součet všech faktorů (známek). V našem
případě variantu č. 3 - A. Hubatá.
Vícekriteriální rozhodovací analýzu (MCDA – Multicriteria Decision Analysis) můžeme s
výhodou využít pro vyhodnocení různých situací při vzdělávacích projektech nebo při jiných
životních situacích, kdy dovedeme rozlišit možné varianty a tyto ohodnotit podle různých
faktorů. Tyto faktory však musí být hodnotitelné kvantitativně,tj. musíme jim umět přiřadit
určitou hodnotu, která vyjadřuje stupeň jejich hodnocení. Nestačí hodnotit ano - ne, málo více - nejvíce atd. Pokud máme takový případ, musíme si pomoci např. tak, že málo - budeme
hodnotit 1 bodem, více - 3 body, nejvíce - 5 body apod.
Tato metoda, přestože je velmi jednoduchá, dovoluje zvládnout s úspěchem poměrně složité
rozhodovací problémy. Výhoda použití počítače je v tom, že nám umožní:
- zvládnout velké množství variant a faktorů,
- provést rychlé výpočty, které ohodnotí jednotlivé
varianty,
- seřadit varianty podle celkového hodnocení,
- snadno experimentovat s různým způsobem hodnocení variant
- ukládat údaje o provedené analýze a vracet se podle potřeby k nim v případě nutnosti
přehodnotit původně provedenou analýzu
•
•
•
V projektovém řízení ji využíváme v různých rozhodovacích situacích:
Ve Studii příležitosti potřebujeme vybrat z několika vhodných možností nebo se
vyvarovat nejhorší hrozbě
Ve Studii proveditelnosti potřebujeme vybrat mezi několika možnostmi realizace
projektu
Při návrhu projektu vybíráme nejvhodnější způsob realizace činností, nejlepšího
dodavatele nakupované komponenty nebo služby, apod.
V předchozím odstavci byl uveden příklad situace, na kterou je možno aplikovat
metody vícekriteriální rozhodovací analýzy Povšimněte si, že jsme všem faktorům přiznali
stejný význam - váhu, což můžeme vyjádřit tak, že jsme každé hodnocení faktoru násobili
váhou rovnou jedné. Kdybychom chtěli zdůraznit, že matematika je pro výběr uchazeče
dvakrát důležitější než ostatní předměty, zvolili bychom váhu pro faktor "matematika" rovnou
hodnotě 2. Dostali bychom celkové hodnocení:
J. Kyslík 8
F. Dusík 11
A. Hubatá 19
takže bychom vybrali variantu č. 1 (J: Kyslík).
Někdy se požaduje, aby součet vah byla určitá hodnota. Pokud zadáte volbu předepsaného
součtu vah, pak se zadané váhy upraví v příslušném poměru. Např. Zadané váhy 1 1 1 1 se při
předepsaném součtu vah 1 změní na hodnoty 0,25 0,25 0,25 0,25.
Podobně bychom postupovali, kdybychom např. hodnotili několik programů (varianty) podle
následujících faktorů : úroveň dokumentace, komfort v ovládání, počet funkcí, rozšíření
používání, které bychom bodovali hodnotící stupnicí 1 až 5 (1 - nejhorší hodnocení, 5 nejlepší hodnocení. Museli bychom jen seřadit výsledné hodnocení sestupně, tj. variantu s
nejvyšším celkovým hodnocením zařadit na první místo.
Normalizace hodnot
Jednoduchost doposud uvedených příkladů způsobovala skutečnost, že jsme hodnotili
všechny faktory stejným hodnotícím způsobem. Co však v případě, že budeme vybírat mezi
osobními auty a zvolíme následující faktory :
1. počet přepravovaných osob (ks)
2. objem zavazadlového prostoru (dm3)
3. výkon motoru (kW)
Faktory jsou zde přesně hodnotitelné,ale rozdílnost jednotek může způsobit potíže při
celkovém hodnocení (jednotky u osob,desítky u zavazadlového prostoru,stovky u výkonu).
Prosté sečítání skutečných hodnot připomíná "sečítání jablek s vejci". Je možno ale vždy
vyhledat v zadaných hodnotách největší hodnotu příslušného faktoru, tu považovat za
jednotku a ostatní hodnocení vyjádřit podílem z této části. Např. původní hodnocení
zavaz.
výkon
faktor
přeprav.
auto
osoby
prostor
motoru
───────────────────────────────────────────────────
model 1
model 2
model 3
5
4
4
80
90
75
120
101
136
se změní takto:
faktor
1
2
3
varianta
─────────────────────────────────────────────────────
──
1
2
3
1
0,8
0,8
0,89
1
0,83
0,88
0,74
1
Říkáme, že jsme hodnocení faktorů normalizovali.
Transformace hodnot
Potíž při hodnocení může nastat, když mezi uvedené faktory zařadíme i údaj o spotřebě auta
na 100 km jízdy. Dříve uvedené faktory hodnotíme podle zásady čím více tím lépe - tedy na
maximální hodnotu, zatímco spotřebu budeme požadovat minimální. Jedním z řešení je, že
hodnoty pro spotřebu transformujeme na maximální bázi. Transformace spočívá v tom, že
nejmenší hodnota se vezme jako jednotková a ostatní hodnoty se vypočtou jako převrácené
hodnoty jejího násobku. Pak můžeme i tento faktor hodnotit podle maximálního kritéria.
Např. budou-li hodnoty spotřeby
varianta spotřeba (1/100 km)
1
8,2
2
7,6
3
9,0
bude hodnocení po transformaci na maximální bázi vypočteno
následovně:
varianta spotřeba (TRANS)
1
0,93
2
1
3
0,85
Obdobně můžeme hodnoty určitého faktoru transformovat podle zadaného vzoru tak,
že se vyčíslí absolutní odchylka zastoupené hodnoty od vzoru u jednotlivých variant a
vyhledá se nejmenší. Ta se vezme za jednotku. Ostatní hodnoty se přepočtou jako její
násobky. Z těchto násobků se vypočtou jejich převrácené hodnoty a ty se použijí jako
mocniny exponenciální funkce ex. Tak se zajistí, že čím bližší bude zastoupená hodnota ke
vzoru, tím bude její hodnocení vyšší.
Metodu vícekriteriální analýzy můžeme použít v praxi pro řadu případů kdy se máme
ve vzdělávacích projektech rozhodovat mezi několika variantami: výběr vzdělávací firmy,
výběr pracovníků do vzdělávacího kurzu, výběr zařízení pro konání vzdělávacího kurzu,
některé zařízení didaktické techniky, apod.
Kvalita rozhodovacího postupu v tomto případě záleží na:
•
•
•
•
•
Kvalitě variant, ze kterých provádíme výběr. Proto musíme věnovat celou pozornost
prvotnímu výběru oslovených firem. Oslovíme-li poptávkou jen firmy, které pracují
jen v oblasti otevřených katalogových vzdělávacích kurzů, nemusí být mezi
nabídkami ani jedna firma, která dokáže zorganizovat specializovaný vzdělávací kurz
přesně podle požadavků zákaznické firmy.
Kvalitně stanovené množině kritérií, které mají relevantní význam pro správný výběr.
Zde dochází k řadě chyb, kdy se výběrová kritéria nestanový dostatečně správně a
některá se dokonce opomenou. Rozhodně bychom neměli zapomenou na taková jako:
reference na uskutečněné kurzy, kvalifikace lektorů, délka působení v dané oblasti,
cena kurzu, hodnota možných rizik, svázaných se vzdělávací firmou, apod.
Na objektivně stanovených hodnotách jednotlivých variant podle kritérií
Na správně prováděném postupu. Mnohdy se zapomene na provedení normalizace a
transformace hodnot a výsledkem je matice hodnot, která neumožňuje a správně
přehledně vyhodnotit výběr vzdělávací firmy, protože hodnoty kritérií jsou
nedoměřitelné ( např. cena v Kč, délka působení v oboru, hodnota rizika).
Na rozumně stanovených vahách pro jednotlivá kritéria
Pokud se jedná o výběrové řízení v rámci státních zakázek, je potřeba respektovat Zákon
o veřejných zakázkách, který předepisuje další formální náležitosti průběhu takového
výběrového řízení.
Pokud je výběrové řízení realizováno v rámci soukromé firmy, je možno doporučit
následující postup.
Formulace celkového záměru vývoje AIS
Je většinou zpracovaný ve formě informační strategie podniku, která vychází
z globální strategie a obsahuje v komplexní podobě všechny hlavní charakteristiky a
požadavky na nový IS/IT. Výhodou takového postupu je poměrně jasná formulace
představ o blízkém i budoucím vývoji IS/IT a tedy i nároků na jeho ebeny. dodavatele.
Informační strategie podniku je pak základem pro zpracování poptávkového
dokumentu
Příprava výběrového řízení
Ustanovení komise, které je nutno provést příkazem ředitele, ve kterém by mělo být
stanoveno :
•
poslání komise
•
složení komise s určením předsedy komise
•
termín ukončení výběrového řízení, případně jiné důležité termíny
•
komu a v jaké formě předá komise výsledky své práce
•
zvláštní pravomoce komise
•
případné disponibilní náklady pro práci komise a pro průběh výběrového řízení
•
seznam materiálů, ze kterých má komise vycházet a respektovat
Tato komise musí být reprezentativní (složená z odborníků z více profesí). Složení
komise doporučuje následující:
•
Zástupce vlastníka firmy resp. zástupce vrcholového vedení firmy nebo
majitelů (předseda komise)
•
Vedoucí útvaru informatiky (tajemník komise)
•
Další členové komise (zástupci významných útvarů firmy nebo vedoucí
současně probíhajících projektů (CAD, Systém řízení jakosti, Automatizace
výroby, Investiční akce apod. ).
Celkem by komisy mělo tvořit asi 7 členů větně případných externích poradců. Po
ustanovení komise, řídí průběh řízení sama komise, podle pránu práce a
harmonogramu, který si sestaví.
Sestavení požadavků na informační systém a jeho odsouhlasení vedením firmy
Požadavky na informační systém vyplývají z takových materiálů jakými jsou:
•
zhodnocení současného stavu v poskytování informací pro řízení (analýza silných
a slabých stránek firmy)
•
informační strategie firmy
•
další strategické materiály firmy (Strategie jakosti, finanční strategie,
marketingová strategie apod.)
•
strategie budování informačního systému
•
požadavky vedení firmy na informační systém a požadavky jednotlivých útvarů
firmy na informační systém
•
doporučení konzultačních firem
Sestavení poptávky na informační systém a přihlášení do tendru, vypracování nabídek
dodavateli
Tato fáze předpokládá poskytnutí poptávkového dokumentu přihlášeným účastníkům a ebeny.
další konzultace k jeho obsahu. Zde často dochází k určitým odlišnostem. Například metody
ES předpokládají 1 – 2 společné konzultace, které jsou pro účastníky tendru vedle
poptávkového dokumentu jediným dalším zdrojem informací. jiné metodiky počítají s tím, že
účastníci tendru mohou v průběhu přípravy nabídky individuálně vyžadovat další informace.
Výzva k účasti na výběrovém řízení se provádí dvěma způsoby:
•
adresná (podle seznamu se provede rozeslání poptávky na jednotlivé firmy se
žádostí o zpracování nabídky do požadovaného termínu)
•
neadresná (formou inzerátu v novinách – nevýhodou je malý informační obsah,
proto po projevení zájmu zasíláme ihned podrobnější dokument)
První kolo výběrového řízení.
•
musíme mít k dispozici kritéria pro výběr AIS
•
sestavení těchto kritérií je velmi náročný úkol a představuje jeden z kritických
faktorů úspěchu jakostního výběru. Neexistuje jediný seznam takových kritérií,
který by se hodil pro všechny případy. Kritéria je nutno vždy přizpůsobit
konkrétním požadavkům firmy.
•
nabídky získané od dodavatelů podle přijatých kriterií (sestavení pořadí
výhodnosti nabídek je možno provést s využitím metody vícekriteriální analýzy).
•
stanovení 3-5 nejlepších nabídek pro další kolo výběrového řízení.
•
podle metody vícekriteriální rozhodovací analýzy je nutno sestavit tabulku, kde
sloupce představují jednotlivé nabízené informační systémy a řádky jednotlivá
hodnotící kritéria s uvedením případných vah. Výsledkem je souhrnné ohodnocení
každého informačního systému podle přijatých kritérií a sestavení výhodnosti
nabídek.
Jednotlivé hodnocené produkty
Hodnotící kritéria
Váha kritéria
A
B
C
D
E
Kritérium č. 1
Kritérium č. 2
Kritérium č. N
Celkové hodnocení
•
jestliže jedna nabídka výrazně převyšuje ostatní, další kolo se nedělá
Druhé kolo výběrového řízení
•
před ním se poděkuje dopisem nevybraným firmám za účast
•
připraví se zpřesnění požadavků do druhého kola
•
pro firmy vybrané do druhého kola se připraví prezentace v zákaznické firmě
•
vybereme si referenční podniky (podniky, ve kterých má vybraná firma má svůj
IS) a navštívíme je
•
opět se sestaví pořadí firem, vybereme nejlepší a ostatním poděkujeme dopisem za
účast a informujeme je na jakém místě se umístily
•
firmu, která skončila na druhém místě upozorníme zvlášť, že pokud odpadne firma
z prvního místa, zahájíme jednání s ní.
2.3 Vztah zákazník dodavatel
Moderní softwarové inženýrství a moderní projektový management zakládá realizaci
AIS na principu vzájemné spolupráce mezi zákazníkem a dodavatelem.
V minulosti mnohokrát končil návrh a realizace AIS konfliktem mezi zákazníkem a
dodavatelem, který měl často dozvuky u soudu. Pokud bychom analyzovali zmíněné případy,
odhalili bychom s vysokou pravděpodobností následujících skutečnosti:
· Cílem zákazníka bylo snižovat režijní a nevýrobní náklady - tedy i náklady na získání
informačního systému. Ostatně začínající firmy mnohdy neměly ani potřebné finanční
prostředky pro tyto účely. Zákazník se proto snažil pořídit informační systém co nejlevněji a
byl si přitom vědom svého dominantního postavení, které uplatňoval, často i dost
nevybíravými způsoby.
· Cílem dodavatele bylo vytvořit co nejvyšší zisk dodávkou nejdražšího informačního systému
zákazníkovi, často bez ohledu na jeho skutečné požadavky, potřeby a na kvalitu dodávky.
-
-
-
-
-
Skutečnost, že se jednalo o tentýž informační systém, objasňuje, proč vznikla nutně
konfliktní situace. Ta byla zesílena dalšími protichůdnými zájmy a skutečnostmi:
Zákazník se snažil co možná nejdále odložit termín zaplacení faktury až za zcela hotový
informační systém (pokud možno v několika splátkách až po dodávce informačního systému).
Dodavatel požadoval placení zálohami již v průběhu dodávky informačního systému v co
možná nejvyšších možných hodnotách.
Specifikace informačního systému jako celku i některých jeho jednotlivých komponent není
jednoduchá. Toho využily obě strany: Zákazník se snažil svoji specifikaci sestavit co možná
nejobecněji a nekonkrétně, protože to mu poskytovalo možnost později tvrdit, že nebylo
dodáno to, co si představoval a že dodávka není kompletní. Dodavatel nekonkrétní a obecné
specifikace využíval k tomu, aby za předmět dodávky prohlásit vždy to, co potřeboval
zaplatit.
Nesmírně rychlý vývoj informačních technologií představoval logicky zdroj požadavků na
změny jak ze strany zákazníka, tak dodavatele, a realizace těchto změn byla zdrojem dalších
konfliktů
Pracovníci zákaznické (uživatelské) firmy měli stále dojem, že jejich prioritní činností je
věnovat se svým zákazníkům a finančním problémům vlastní firmy, takže řešení záležitostí
kolem budovaného informačního systému považovali za činnost, která může stát na okraji
jejich pozornosti. Navíc často nerozuměli problematice informačních systémů a informačních
technologií, takže svůj zájem obraceli jinam (to, čemu nerozumíme, se snažíme podvědomě
přehlížet).
Pracovníci dodavatelských firem byli ponejvíce odborníci na specializované otázky
nasazovaných informačních technologií, ale nerozuměli problematice řízení firem a tuto
problematiku považovali za vedlejší a nebyli ochotni se jí zabývat. Přitom jejich odborné
znalosti informačních technologií je stavěli v mnoha případech do určité výhody zejména za
situace, kdy zákazníci této problematice nerozuměli.
Problémy, které se hromadily při realizaci složitého informačního systému, stále
zvyšovaly množství dalších konfliktů a prohlubovaly konflikty stávající. Postupem doby se
pak tyto konflikty stávaly zdrojem rozsáhlých potíží při návrhu a realizaci informačního
systému a živnou půdou pro vzájemné nepřátelství mezi zákazníkem a dodavatelem.
Důvod, proč tomu tak bylo, je možno vysvětlit způsobem uvažování, který je možno
zachytit schematicky takto:
Tvůj zisk = Moje ztráta
Toto schéma vyjadřuje způsob uvažování, podle kterého zákazník a dodavatel hodnotí
výsledky svých vzájemných obchodních kontaktů. Hodnotu, zaplacenou fakturou dodavateli,
považuje zákazník za ztrátu svých finančních prostředků. Hodnotu práce, kterou odevzdal
zákazníkovi, považuje dodavatel naopak za svoji ztrátu, atd. Přitom se každý z nich snaží
maximalizovat svoje zisky a minimalizovat svoje ztráty.
Jak zákazník, tak dodavatel se snaží, aby z konfliktu vyvázli jako vítěz, zatímco
protivník bude poraženým.
Překvapivé rozuzlení spočívá často ve zjištění, že poražení jsou oba! Proto takový
přístup není vhodný pro realizaci AIS.
Správným přístupem je kooperativní řešení realizace AIS.
Pokud by se zákazník a dodavatel na samém počátku kontraktu rozhodli postupovat
společně tak, aby zajistili pro obě strany optimální řešení vzájemnou spoluprací, řada
konfliktů rázem odpadne. Obě strany by si měly uvědomit, že jen v případě cílů, pro které
jsou stanoveny objektivně měřitelné ukazatele, můžeme zjišťovat, zda se k nim přibližujeme
(Management by Objectives). Z tohoto zjištění vyplývá potřeba jednoznačné, úplné a
ověřitelné specifikace informačního systému a promyšleného řízení změn (Change
Management) v průběhu tvorby informačního systému. Takový přístup umožňuje jakostní
plánování a průhledné sledování nákladů i termínů prostřednictvím projektového řízení, jehož
výsledkem je úspěšný projekt, který přinese užitek oběma stranám s vysokou jistotou jeho
dosažení!
Samozřejmě to předpokládá, že se obě strany zřeknou nezasloužených zisků, které
inkasovaly v důsledku různých podrazů a vychytralých úskoků!! Odměnou za to jim bude
vysoká jistota, že se na konci mohou očekávat plánované přínosy. To představuje v současné
turbulentní době velmi cennou jistotu, o kterou stojí za to usilovat. Ve srovnání s nejistým
výsledkem, jak bylo popsáno výše, který visí nad oběma stranami jako příslovečný Damoklův
meč, dodává takový průběh projektu tvorby informačního systému velmi potřebný klid a
pohodu k práci a vytváří předpoklad pro dosažení vysoké jakosti realizovaného informačního
systému.
Poznamenejme, problematikou konfliktních situací a jejich optimálním řešením se
zabývá matematická disciplína „Teorie her“ kterou založili von Neuman a Morgenstern.
Zájemci se mohou s principy a doporučeným postupem řešení takových konfliktních situací
seznámit studiem některé publikace, která o této disciplíně pojednává.
2.4 Informační strategie firmy
Pro správný výběr AIS, jeho realizace a pro výběr firmy v roli systémového
integrátora je potřeba aby firma (resp. daná instituce) měla zpracovanou informační strategii
firmy strategii.
Informační strategie je pomocná strategie pro realizaci poslání a vize firmy. Proto
chce-li firma dobře navrhnout a realizovat svůj automatizovaný informační systém musí být
nejprve zpracována informační strategie firmy (ISF). Tím se rozumí cca 20-ti stránkový
dokument, který stanovuje zásadní směry rozvoje informatiky ve firmě:
- stanovuje priority při realizaci AIS (která oddělení a které rozhodovací problémy
budou podpořeny ihned, a co později, protože zřídka je dostatek finančních prostředků, aby
se vše mohlo realizovat ihned)
- určuje míru automatizace informačního systému (je nutno určit, co zůstane
neautomatizováno -např. rozhodnutí, že zatím nebude automatizováno přímé řízení výroby)
- vyděluje finanční prostředky na informační technologie a zajišťování informačního
systému (je nutno určit částku, kterou firma může v určitém období použít pro nákup
informačních technologií a pro informační systém)
- stanovuje způsob návrhu a realizaci AIS (co si firma zajistí sama, na co si objedná
externí firmu a externí poradce, co bude zajišťovat jako externí informační služby outsourcing)
- na které informace se firma především zaměří, aby účinně podpořila řízení
nejdůležitějších procesů.
Informační strategii je vhodné zpracovat v týmu, ve kterém jsou firemní pracovníci i
externí poradci. Je nutno ji vydat jako oficiální dokument firmy a stanovit, jak bude
kontrolováno její plnění a kdo bude zodpovídat za její realizaci. Zpracovává se na období 4 až
6 let. Aby její účinnost byla co největší, musí navazovat na ostatní strategie podniku
(marketingovou strategii, finanční strategii, strategii rozvoje firmy, apod.) a podporovat
podnikatelský záměr a vizi firmy.
Na kratší období 2 až 3 roky se zpracovává strategie informačního systému (SIS),
která v rozsahu cca 10 stran určuje plán návrhu a realizace informačního systémů podle
informační strategie firmy. Ten určuje cíle a úkoly v plánovaném časovém horizontu.
Před vlastním návrhem informačního systému se provádí analýza současného stavu
informačního systému a analýza potřeb firmy (např. pomocí metody analýza silných a
slabých stránek SWOT). Pokud se zjistí, že některé procesy ve firmě neodpovídají firemním
záměrům a bylo by nehospodárné podporovat je novým informačním systémem, musí se
provést zlepšení neefektivních procesů (Business Process Reengineering).
Jako vzor lze uvést následující doporučenou osnovu
1. Cíl a vymezení vztahu informační strategie k dalším materiálům ve firmě
2. Přehled výchozích požadavků při zpracování informační strategie
3. Přehled použitých podkladových materiálů
4. Analýza silných a slabých stránek firmy z hlediska aplikace ICT
5. Hlavní směry rozvoje informačních služeb a využívání progresivních IT
6. Vymezení strategických informací a konceptu informační bezpečnosti
7. Specifikace požadavků na AIS
8. Výběr strategie postupu návrhu a realizace AIS
9. Vyčleněné finanční prostředky a předpokládané přínosy
10. Stanovení zodpovědnosti za naplňování strategie a postup kontroly její účinnosti.
11. Podpisová část
(Podpisy zpracovatelského týmu, podpisy vedení)
Přílohy
Vrcholové vedení by mělo stanovit pravidelné hodnocení informační strategie firmy
jak z hlediska jejího naplňování, tak z hlediska její aktuálnosti s ohledem na stav firmy a ICT.
2.5 Požadavky na AIS
Správná specifikace požadavků na informační systém je klíčovým faktorem pro
úspěšný návrh a realizaci AIS.
Měl by být sestaven reprezentativní soubor požadavků na AIS. U každého požadavku
musí být jasně uvedeno:
• Co se konkrétně požaduje
• Proč se takový požadavek vznáší a realizace požadavku přinese
• Kdo jej předkládá
• Jaká je jeho priorita
Vzniklý soubor požadavků musí být zkontrolován na úplnost, bezrozspornost, musí
být zamezeno duplicitám a odstraněny zbytečné požadavky.
Je potřeba si uvědomit rozdíly, mezi následujícími pojmy:
POŽADAVEK je přímo vznesená žádost, podložená schopností zákazníka její splnění uhradit
(pokud její plnění nevyplývá z jiného, bezplatného nároku).
PROBLÉM je představován situací, se kterou si zákazník neví rady, a proto se obrací na
dodavatele s prosbou o její řešení (Žádost na řešení problému pak přechází v požadavek).
POTŘEBA je objektivní skutečnost, vyplývající z určitých okolností. Pokud však není
podložena požadavkem, je často na dodavateli, zda se rozhodne ji splnit. (Neřešená, naléhavá
potřeba často přechází v problém).
PŘÁNÍ je projevená představa zákazníka, o které se zákazník domnívá (často mylně), že by
ho její uskutečnění mělo velmi dobře uspokojit.
Evidenci a správě požadavků při tvorbě AIS je v současné době věnována stále větší
pozornost. Tato problematika je označována odborným termínem Software Requirement
Management – SRM. Využívá se specializovaných produktů (např. Requisite Pro) a
zvláštních postupů, protože řada zákazníků nedovede specifikovat své informační požadavky,
ale dovede se vyjádřit např. k nabídnutým vzorům obrazovek.
3 Tvorba software
3.1 Modely životního cyklu tvorby software
Postupy - životní cykly, které popisují základní představu o tvorbě softwaru nazýváme
v softwarovém inženýrství konceptuálními modely tvorby software. Rozeznáváme jich celou řadu:
Vodopádový životní cyklus (The Waterfall Life - cycle):
Obrázek: Vodopádový životní cyklus
Požadavky
Funkční
specifikace
Návrh
Kód
Testování
Vodopádový model neodráží známou skutečnost potřeby „zpětných kroků“ při tvorbě
software a nutnost důkladného prověřování výsledků každé etapy.
V - životní cyklus (The V Life Cycle)
V-model
Plán akceptačních testů
Požadavky
Funkce (návrh)
Systém (návrh)
Akceptační testy
Plán funkčních testů
Funkční testy
Plán integračních testů
Def. programu
Plán testu
pro testování
programu
Integrační testy
Test programu
Program (kód)
Tento model vychází z konceptu potřeby neustálého testování, aby se dosáhla vysoká
jakost software. Ukazuje nutnost plánovat testy současně se vznikem požadavků na ověřování
jednotlivých kroku
Model životního cyklu sestavuje průběh jednotlivých fází do kruhu:
Form. požad avků
Užívání
Testování
Analýza
Programování
Střední cyklus
Malý cyklus
Hlavní cyklus
Tento model velmi dobře vystihuje postup při vytváření jednotlivých verzí softwarových
produktů.
Poznámka. Na obrázku nejsou zakresleny všechny malé cykly (např. Analýza – Form.
Požadavků, Programování –Analýza, Užívání – Testování) ani všechny střední cykly (Testování –
Analýza, Užívání Programování, Užívání – Analýza). Důvodem je udržení přehlednosti modelu.
V poslední době se v důsledku použití prototypovacích nástrojů zdůrazňuje iterační postup při
tvorbě programového vybavení, jehož schématické znázornění je na následujícím obrázku. Chce se
zdůraznit, že vývoj probíhá postupně,stále na kvantitativně širší a kvalitativně vyšší úrovni, a že je
omezen okamžikem, kdy se produkt z různých důvodů (zásadní změna technického vybavení, změna
uživatelského přístupu apod.) vyřadí z používání. V anglosaské literatuře bývá označován pojmem
ITERATION LIFE CYCLE nebo PROTOTYPING LIFE CYCLE. Ten lépe vystihuje okamžik
zahájení tvorby software, tvorbu jednotlivých verzí programového produktu a zachycuje i okamžik
ukončené používání programového produktu. Navíc vyjadřuje skutečnost zvyšování kvalitativní
úrovně v průběhu jednotlivých cyklů.
Iterační životní cyklus (Iteration Life Cycle)
Vyřazení z provozu
Využívání
Koncipování
Ověřování
Specifikace
Navrhování
Zavádění
Testování
Programování
Obrázek: Iterační životní cyklus
Dalším možným typem životního cyklu software, jehož použití bude v budoucnu stále narůstat
na významu je „ Objektově orientovaný životní cyklus“, který odráží objektově orientovaný přístup ke
tvorbě software. Významnou součástí komponent modelu je knihovna tříd, která slouží jako zásobník
programových prvků pro nově vytvářená řešení.
Objektově orientovaný životní cyklus (An Object Oriented Life Cycle)
Knihovna
tříd
Požadavky
Funkční
specifikace
Počet
spuštění
1 2 3
Finální
přijetí
Test
funkcí
Návrh
systému
Návrh
objektů
Test
objektů
Kód
objektů
Obrázek: Objektově orientovaný životní cyklus
Velmi moderním trendem vývoje aplikačního softwaru je vývoj se zvýšenou společnou účastí
budoucích uživatelů a s využitím myšlenky rychlého vytvoření základního jádra aplikace, které se
postupně rozšiřuje se současným využíváním prvotně vytvořených programových funkcí.
Tímto modelem je tzv. Rychlý vývoj aplikace (Rapid Applications Development), který
reaguje na požadavek zkrácení doby vývoje software..
Rychlý vývoj aplikace (Rapid Applications Development)
Start projektu
10 dní
Užití Upper CASE technologií k
vytvoření informační architektury
Přípravné
interview a JAD
Workshopy
Iterativní návrh
a budování
Užití Lower CASE technologií k
výstavbě aplikace
20 dní
60 dní
Přehled,
přestavění a
implementace
Přehled
implementace
30 dní
Obrázek: Rychlý vývoj aplikace - RAD
Ve výše uvedených modelech byly použity takové fáze např. jako: Formulace
požadavků, Analýza, Programování, Testování a Užívání. Norma ISO 12 207 Informační
technologie – Procesy v životním cyklu software doporučuje rozdělit celý proces do
následujících fází:
1. Akvizice SW
2. Vývoj SW
3. Provoz SW
4. Údržba SW
5. Vyřazení SW
Každou z těchto fází rozčleňuje dále do dílčích etap takto:
1. Akvizice
1.1. Zahájení akvizice
1.2. příprava žádosti o nabídku
1.3. Příprava smlouvy a aktualizace
1.4. Monitorování dodavatele
1.5. Akceptace a kompletace
2. Vývoj
2.1. Zahájení vývoje
2.2. Analýza systémových požadavků
2.3. Návrh architektury systému
2.4. Analýza softwarových požadavků
2.5. Návrh architektury softwaru
2.6. Detailní návrh softwaru
2.7. Kódování a testování softwaru
2.8. Integrace softwaru
2.9. Kvalifikační testování softwaru
2.10.
Integrace systému
2.11.
Kvalifikační testování systému
2.12.
Instalace
2.13.
Podpora akceptace systému
3. Provoz
3.1. Zahájení provozu
3.2. Provozní testování
3.3. Provoz systému
3.4. Podpora uživatele
4. Údržba
4.1. Zahájení údržby
4.2. Analýza problémů a modifikace
4.3. Implementace modifikace
4.4. Přezkoumání a akceptace modifikace
4.5. Migrace
5. Vyřazení AIS z používání
3.2. Standardizace metod pro tvorbu software
Pro návrh software se v praxi používají popsané a ověřené metody.
Standardizace metod pro navrhování software a AIS se provádí v praxi na následujících
úrovních:
Podniková úroveň
Metoda je standardizována v rámci určité firmy nebo jiné instituce. Vedení firmy vydává
obvykle za tím účelem oficiální pokyn k používání zvolené metody nebo nařídí používání vybrané
metody v jiném dokumentu (nejčastěji v informační strategii firmy). Všechny přední světové firmy,
zabývající se vývojem software a všechny vyspělé světové firmy ,které presentují využívání
špičkových technologií, mají standardizovánu metodu, jejímž prostřednictvím vyvíjejí firemní IS.
Jedná se o firmy, mající více než 5000 zaměstnanců.
Národní úroveň
Tuto úroveň představuje vydaným národním standardem. Ty země, které patří k vedoucím
zemím v oblasti zavádění a využívání informačních technologií, podporují zavedení jednotné metody
pro vývoj používaných IS (USA, Velká Británie, Francie, Itálie). Ale i řada dalších zemí si
uvědomuje výhodu jednotně používané metody (Holandsko, Španělsko, Německo, Švédsko).
Standardy na úrovni státních norem jsou vydány ve Velké Británii a Švédsku.
Mezinárodní úroveň
Tuto úroveň reprezentuje závazná mezinárodní norma. Dosud nebylo přistoupeno
k mezinárodní úrovni standardizace pro metody analýzy a návrhu. Snaha států Evropského
společenství o zavedení jednotné metody návrhu IS v zemích společenství je zatím první oficiální
snahou o mezinárodní standardizaci v této oblasti.
Je nutno upozornit, že i zde existují standardy de jure viz např. SSADM a standardy de facto,
které představují převážnou většinu případů. Zejména metody šířené některými systémy CASE např.
IEF představují ve Spojených státech nepsaný standard a působením amerických firem v zahraničí se
šíří používání takových metod v ostatních zemích.
Do roku 1995 byly nejrozšířenější metody strukturované analýzy a návrhu (např. SSADM,
IDEF, MERISE, SDM, a další – viz různé www stránky těchto metod.).
V současné době de facto představuje UML – grafický způsob popisu software s využitím
objektově orientovaného přístupu a RUP – postup řízení vývoje objektově orientovaných aplikací.
Jazyk UML a postup RUP budou popsány podrobněji v dalším textu.
Používání standardních metod v oblasti software přináší celou řadu výhod a přínosů, které
potvrdila praxe:
- Zvyšuje se kvalita vyvíjeného produktu v důsledku používání vědecky zdůvodněné
metody a systémového přístupu, který zahrnuje přesně definované kroky pro
zajištění kvality ( QAS - ang. Quality Assurance Steps.)
- Zjednodušuje se plánování a řízení , protože jsou známy dopředu jednotlivé fáze a
kroky při vývoji systému.
- Usnadňuje se komunikace
zákazník - dodavatel
uživatel - analytik
analytik - programátor
řešitel - vedoucí projektu
tím, že jsou používány jednotné prostředky pro komunikaci k přesně definovaným
účelům (grafy, tabulky, terminologie).
- Zvyšuje se produktivita projektových prací v důsledku používání racionálních
postupů , nástrojů a zmenšeného výskytu chyb.
- Zmenšuje se riziko plýtvání nákladů používáním osvědčených a
prověřených postupů.
- Odstraní se závislost na jednotlivých osobách, protože postup je n
na nich nezávislý. To je významné při zvážení důsledků
vysoké migrace v realizačních týmech ( tzv. ego less design).
- Usnadňuje se zapracování nových pracovníků.
- Vytvářejí se předpoklady pro použití počítačové podpory
analytických a návrhářských prací (možnost aplikace produktů CASE)
- Dokumentace systému je vytvářena systematicky , jednotným
a metodicky správným způsobem.
V této souvislosti je potřeba upozornit na několik skutečností a na význam norem pro
současnou praxi.
Po přistoupení ČR do EU se ČR zřekla národní svrchovanosti norem. Proto platí evropské
normy, označované EN. Z technických důvodů (tisk, překlady, apod.), zůstává v platnosti ještě řada
norem, označovaných původně ČSN. Evropské normy bez výjimky akceptují mezinárodní normy ISO.
Zároveň byl zrušen starý normalizační zákon. Technické normy mají, až na výjimky, status
doporučovací. Tím ale jejich význam nepoklesl!
Výjimečná zákonná povinnost respektování některých norem, je obsažena v některých
zákonech, které se týkají takových oblastí jako ochrana zdraví obyvatelstva, bezpečnost práce,
bezpečnost státu a obyvatel, jaderná bezpečnost, apod.
V obchodním kontaktech má znalost a schopnost dodržování norem především význam
konkurenční výhody. V některých oblastech již nelze bez ověřeného doložení souladu dodržování
některých norem vůbec uplatnit výrobky na etablovaném trhu (např. soubor norem ISO 9000:2000 a
automobilový, letecký, zbrojní průmysl, energetika, apod.). Schopnost dodržovat normy je potřeba
v řadě příkazů prokázat příslušným certifikátem pro výrobek, firmu nebo osobu.
Při uzavírání smluv na dodávku AIS by se zákazník a dodavatel měli dohodnout, které normy,
v jakém rozsahu a jakým způsobem se budou v průběhu návrhu a realizace používat!
4 Objektově orientované metody analýzy a návrhu
4.1 Strukturovaný přístup k analýze a návrhu
4.1.1 Principy strukturovaného přístupu
Strukturovaný přístup je historicky starší než objektově orientovaný přístup.
Strukturovaný přístup vznikal v letech 1970 až 1975 a nejvíce se používal v letech
1982 až 1990.
Metody strukturované analýzy a návrhu se v detailech lišily. Vycházely však ze stejných
principů uplatňovaných v systémovém inženýrství, které lze výstižně shrnout takto :
Abstrakce
Strukturalizace
Hierarchie
Modularita
Iterace
Systémový přístup
Princip abstrakce
Abstrakce znamená snížení komplexnosti systému pomocí zanedbání vedlejších
aspektů. Abstrakce je vždy cílově orientována k dosažení určitých cílů. Zajímá nás, které
aspekty a detaily zůstávají. Výsledkem abstrakce je model vyvíjeného systému z jednoho
pohledu. Abstrakce umožňuje na určité úrovni podrobnosti zjednodušit složitý problém
ignorováním jeho nepodstatných aspektů. Princip abstrakce spočívá ve skutečnosti, že
používáme data a funkce jejichž konkrétní implementaci neznáme.
Princip strukturalizace
Strukturalizace znamená nalézt pro komplexní systém redukované znázornění takové, které by
zachovalo charakter celku se specifickými znaky.
V následujícím obrázku se vyskytují dva základní typy užívaných diagramů ( dle topologie ) :
strom : obsahuje kořen, větve, koncové listy
síť :obsahuje spojení typu "každý s každým"
Obrázek: Stromové a síťové struktury
Princip hierarchie
Systém má hierarchii ( je hierarchický ) , když jeho jednotlivé části ( elementy ) jsou
uspořádány dle stupně řádu. Elementy se stejným stupněm řádu ( uspořádání ) zobrazují jednu úroveň
hierarchie. Stupeň uspořádání může být určen označením, vlastností nebo časovými závislostmi
elementů systému.
1
Zakladni
prehledy
Prehledy
konstr.
prvku VCSP
Prehled KP
dle oznaceni
(VCSP,agr.
pol.)
Prehledy
konstr.
prvku SPCM
DTTO dle
nazvu
Prehledy
agregovanych
polozek
Prehled KP
dle oznac.
(SPCM)
Prehled KP
dle nazvu
(SPCM)
DTTO dle
oboru (SPCM)
Aktual. KP
- Novy KP
DTTO dle
rozliseni
DTTO dle
ceniku
DTTO dle
oboru TSKP
Aktualiz. KP
- Novy KP
Prehled
agergovanych
prvku
Vzorove
objekty
Obrázek: Hierarchie struktury systému
Hierarchie se projeví ve víceúrovňové struktuře systému, odpovídající postupnému rozkladu
na části, kde každá úroveň, a tedy i části na této úrovni, odpovídají určité jedné úrovni abstrakce.
Princip modularity
Modularizace znamená : postavení systému ze " stavebních kamenů" , které
moduly a které obsahují pevné funkční spojení a volné datové vazby.
nazýváme
" Stavební kámen " má pevné funkční spojení , když obsahuje jen takové funkce, které spolu
souvisí.
O volných datových vazbách hovoříme tehdy, je-li množství dat , které mezi moduly systému
budou vyměněny, redukováno na minimum.
Modul A
Modul B
nepatrné datové
spojení
vnitřní interní
spojení
Modul C
Obrázek: Modularita systému
Modularita určuje vlastnosti částí, do kterých je systém dekomponován. Tyto části by
měly být vnitřně silně soudržné (tj. na nižší úrovni sdružují vzájemně silně propojené
podčásti) a navzájem slabě spřažené ( tzn. že je mezi nimi co nejméně vazeb).
Typickými vlastnostmi pro modul jsou :
soudržnost funkcí
zásada 1 vstup a 1 výstup
relativní nezávislost
modul může komunikovat pouze přes své parametry
Princip iterace
Princip iterace vychází z předpokladu, že systém nemůže být navržen
přímočarým způsobem. Proto se analýza i návrh provádějí v postupných krocích,
které neustále zpřesňují jak analýzu, tak návrh, přičemž se postupně vždy
přechází od analýzy na nejvyšší úrovni k návrhu na nejvyšší úrovni až postupně
k podrobné analýze a pak k podrobnému návrhu.
Princip systémového přístupu
Prostřednictvím principu systémového přístupu nahlížíme na předmět našeho zájmu
jako na systém a zvažujeme všechny jeho části a děje ve vzájemných souvislostech.
Všechny uvedené principy se uplatňují ze tří hledisek strukturované analýzy a návrhu:
Hledisko funkcí. Sledujeme funkce systému
Hledisko dat. Sledujeme potřebná dat pro zajištění jednotlivých funkcí
systému
Hledisko událostí. Sledujeme události, které aktivují jednotlivé funkce
systému
4.1.2 Metoda SSADM
Metoda SSADM (Systém Analysis and Design Method) může posloužit jako typická
ukázka strukturované metody analýzy a návrhu.
Vznik a vývoj metody SSADM
Metoda SSADM vznikla u firmy LBMS (Learmont & Burchett Management Systém)
v Londýně v roce 1981. Firma LBMS patří mezi vedoucí firmy na poli systémů CASE vedle
takových jakými jsou KNOWLEDWARE, INTERSOLV, SOFTLAB, CADRE, TEXAS
INSTRUMENTS, WESTMOUNT, ANDERSEN a TRANSFORM LOGIC.
Původně neměla tento název a byla firemní metodou LBMS. V roce 1980 vybírala
britská státní agentura CCTA (Central Computer and Telecommunication Agency ) přiměřeně
vhodnou metodu pro navrhování informačních systémů státní správy. Bylo vyhodnoceno 47
metod od 35 firem. Výběrové řízení bylo ukončeno v roce 1981, kdy byla vybrána metoda
firmy LBMS a pojmenována Structured System Analysis and Design Method. Současně byla
zahájena společná práce na jejím zdokonalování, takže v roce 1983 mohla být metoda
doporučena pro oblast britské státní správy. Od roku 1986 spolupracují CCTA a NCC
(National Computing Centre for Information Technology Manchester) na popularizaci, vývoji
a podpoře SSADM. LBMS vyvinula CASE produkt AUTO MATE pro podporu SSADM.
V NCC vznikl další produkt CASE označovaný ASSET. Byla vydána řada publikací o
metodě SSADM a NCC začalo pořádat kursy metody SSADM. Absolventi kursů získávají
certifikát o zvládnutí metody SSADM považovaný za kvalifikační doporučení pro práci
analytika v oblasti navrhování informačních systémů.
V polovině osmdesátých let se metoda SSADM šíří i v zahraničí mimo hranice Velké
Británie.
V roce 1990 byla oficiálně publikována verze 4. A v roce 1991 ohlásila firma LBMS
podporu 4. verze SSADM produkty SYSTEMS ENGINEER a SSADM ON-LINE. Metoda je
doplňována o možnosti propojení na systémy řízení kvality a metody projektového řízení.
V roce 1992 byla metoda SSADM vyhlášena jako britská norma státním úřadem pro
standardizaci.
Cíle metody SSADM
Metoda splňuje jednak obecné cíle, které jsou vlastní všem metodám softwarového
inženýrství a které jsou v ní již implicitně zahrnuty:
1) Návrh informačního systému s těmi funkcemi, které uživateli umožní maximální
podporu informačních a řídících procesů.
2) Návrh báze dat, která s ohledem na požadované funkce obsahuje vhodně
uspořádaná potřebná data.
3) Návrh vhodných programových a technických prostředků pro realizaci
informačního systému.
4) Návrh potřebných personálních, organizačních a finančních zabezpečení pro
vybudování a vlastní provozování informačního systému.
5) Zabezpečení přiměřené kvality všech činností prováděných během návrhu.
6) Zajištění co možná nejmenších nákladů na návrh, realizaci a provozování
informačního systému.
7) Zajištění dokumentace průběhu a výsledků všech činností spojených s návrhem
informačního systému.
Mimo tyto všeobecné cíle definuje SSADM explicitně cíle následující:
1) Poskytnutí požadovaného systému zákazníkovi ve stanoveném termínu a bez
překročení rozpočtu.
2) Dodání systému, který vyhovuje požadavkům zákazníka.
3) Zajištění vysoké flexibility dodávaného systému, který musí reagovat na změnové
řízení v organizaci zákazníka.
4) Zvýšení kvality navrhovaného systému zmenšením počtu chyb.
5) Zvýšení produktivity při projektování systému.
6) Zajištění nezávislosti na dodavateli hardwaru a softwaru.
7) Aplikace technik projektového řízení k účinnějšímu plánování a řízení projektu.
Charakteristika SSADM.
Metodu SSADM je možno charakterizovat jako produktově i činnostně orientovanou.
Obsahuje totiž přesné definice dokumentů na standardizovaných formulářích, které musí být
při návrhu vytvořeny, a též obsahuje i přesné definice činností, které se mají provést a jejichž
výstupem zmíněné dokumenty jsou.
Metoda důsledně odděluje logický a fyzický návrh. Zkoumá systém z hlediska třech
pohledů:
pohled na funkce, které má systém plnit
pohled na data, která mají být v systému uložena
pohled na události, které probíhají v systému v určitých časových okamžicích
Metoda obsahuje přesně definovanou spoluúčast uživatelů na analýze a návrhu tak,
aby se zajistila maximální uživatelská přívětivost systému a aby byly splněny požadavky
zákazníka.
SSADM preferuje přístup TOP DOWN při návrhu jak datových struktur, tak i funkcí.
Vývoj celého systému probíhá podle zásad systémového přístupu a zvažují se všechny
významné souvislosti mající vliv na navrhovaný systém a na proces navrhování systémů.
Řada metod zvažuje pouze technická hlediska při návrhu systému, což je ovšem příčnou nízké
efektivity a užitné hodnoty navrhovaného systému.
Filozofie
vývoje
systémů
Počítačová
podpora
Technické
prostředí
Základní znalosti
SSADM
Programové
prostředí
Předchozí stadia
vývoje projeku
Řízení vývoje systému
Následná stadia
vývoje produktu
Obrázek: Schéma metody SSADM
Metoda SSADM klade důraz na správnost a náročné provedení prvních etap projektu, protože
čím dříve se odhalí chyba, tím menší jsou pak náklady na její odstranění.
Náklady na
odstranění
chyby
Čas objevení chyby
Obrázek: Křivka závislosti nákladů na odstranění chyby na čase, kdy byla chyba objevena.
Architektura SSADM
Metoda vychází z klasického konceptuálního schematu vývoje informačního systému:
Etapy SSADM
Fáze SSADM
Definice problému
Fáze úvodního
projektu
Sestavení projektu
Analýza st. systému
Fáze analýzy
Specif. požadavků
Výběr techn. řešení
Návrh struktury dat
Návrh procesů
Fáze návrhu
Fyzický návrh
Obrázek: Konceptuální schéma metody SSADM
Metoda rozlišuje tři fáze :
Fáze úvodní studie
Fáze analýzy
Fáze návrhu
Jednotlivé fáze obsahují přiřazení etap (STAGES) viz. předchozí obrázek. Etapy se dělí na
jednotlivé kroky (STEPS) a ty dále na jednotlivé úkoly (TASKS), které je potřeba provést pro úspěšný
vývoj dané aplikace. Uvedenou hierarchickou strukturu je možno prezentovat následujícím obrázkem:
STAGE .......... STAGE
STEP ........................ STEP
TASK ....................... TASK
Obrázek: Hierarchická struktura SSADM
Kroky jsou číslovány trojmístným číslem, kde první číslo označuje etapy a další dvě pořadové
číslo kroku. Úkoly jsou číslovány dvojmístným číslem za číslem kroku, do kterého patří. Dvojmístné
číslo je odděleno tečkou, např.:
4. Návrh struktury dat - etapa
410 Provedení relační datové analýzy - krok
410.10 Proveďte výběr objektů, které projdou procesem normalizace a připravte jejich seznam
- úloha
Označování fází se neprovádí. Dekompozice jednotlivých etap do úrovně kroků je následující:
ETAPA 01: Definice problému
Etapa 01 se nazývá definice problémů a jejím úkolem je sestavit základní seznam problémů,
vytvořit časový plán, který se projedná s vedením organizace, sestavení přehledu současného
systému a datové struktury, vytvoření základního logického modelu systému a překontrolování
sestavených problémů.
010 Zahájení úvodní studie
011 Sestavení přehledu současného systému
012 Sestavení přehledu o datových strukturách
013 Vytvoření základního logického modelu systému
014 Zkonsolidování seznamu problémů a požadavků
019 Revize definic problémů
ETAPA 02: Sestavení projektu
Etapa 02 se nazývá identifikace (sestavení) projektu. V tomto kroku by měly být vytvořeny
základní alternativy řešení, pokud existují. Dále pak sestavení zprávy, která je podkladem pro další
etapy.
021 Sestavení základních směrů projektu
022 Sestavení základních specifikací projektu
023 Vyhodnocení alternativ projektu
029 Formalizace zprávy úvodní studie
ETAPA 1: Analýza fungování stávajícího systému a jeho problémů
1. etapa klade důraz na správné pochopení stávajícího systému z hlediska jeho funkcí i z
hlediska používaných údajů, které jsou v něm používány. Významným krokem je identifikace
stávajících problémů fungování systému, problémů uživatelů a námětů na zlepšení.
110 Úvodní analýza
120 Zkoumání stávajícího systému
125 Zkoumání struktury dat systému
140 Sestavení Seznamu problémů a požadavků (PRL)
150 Posouzení výsledků zkoumání
ETAPA 2: Specifikace požadavků
2. etapa provádí specifikaci požadavků na nově navrhovaný informační systém. Kromě
základních funkčních požadavků a požadavků na strukturu dat si návrh všímá i potřeb, ze kterých
plynou požadavky uživatele na ochranu dat, kontrolní funkce a nároky na řídící funkce.
200 Vytvoření logického systému
205 Definování požadavků na bezpečnost
210 Stanovení a unifikace požadavků a uživatelů
220 Sestavení a výběr z alternativních konceptuálních návrhů (BSO)
230 Podrobný popis vybrané alternativy
240 Návrh struktury dat
250 Zkoumání detailní logiky systému
260 Posouzení návrhu požadovaného systému
ETAPA 3: Výběr technického řešení
3. etapa řeší možné způsoby technické realizace systému. Všímá si problému jaké technické
prostředky mohou uspokojivě zajistit splnění specifikovaných požadavků. Výsledkem je návrh
počítačové konfigurace základní jednotky, velikost externích pamětí, periferní zařízení, komunikační
sítě a terminálů, základního programového vybavení a jiných potřebných technických prostředků.
Jak ve druhé, tak ve třetí etapě jsou zařazeny kroky, které umožňují, aby si zákazník vybral z
vypracovaných variant řešení, pokud existují.
310 Příprava alternativ technického řešení
320 Zvolení technické alternativy uživateli
330 Dokončení a přezkoumání návrhu požadovaného systému
340 Stanovení cílů a výkonnosti navrhovaného systému
ETAPA 4: Návrh struktury dat
4. etapa vytváří relační datové struktury. Datový návrh je prováděn zdola nahoru prohlížením
požadavků, které na data kladou vstupní dokumenty, formáty vstupních a výstupních obrazovek,
výstupních zpráv a specifických požadavků na ukládaná data. Kromě toho se však zde provádí
nastavení optimálního datového modelu, který se pro potřeby fyzických datových struktur vytváří ve
třetí etapě.
410 Provedení relační datové analýzy - normalizace
420 Vytvoření detailního logického datového modelu
ETAPA 5: Návrh procesů
Funkční návrh v 5. etapě zahrnuje nejen specifikaci funkcí, které vyplývají z problémového
zaměření systému, ale i funkce, jež potřebuje systém pro zajištění svého správného fungování
(aktualizace, hlášení chyb, zabezpečení před haváriemi atd.).
510 Specifikace Kostry logiky dotazů
520 Specifikace Kostry logiky aktualizačních funkcí
530 Přezkoumání a ověření logického návrhu
ETAPA 6: Fyzický návrh
Závěrečná 6. etapa obsahuje návrh databázových struktur v příslušném definičním jazyku
použitého databázového systému a popis izolovaných souborů, které jsou požadovány. Následuje
specifikace požadovaných transakcí, prováděných v režimu dávkovém i interaktivním. Nakonec jsou
navrhovány programy pro generování zpráv, třídící programy atd. .Tato etapa však obsahuje také
další nezbytné kroky, jako testování, zpracování návodů k používání systému a seznam možných
zásahů do systému.
610 Vytvoření prvotního fyzického datového návrhu
620 Tvorba programových specifikací pro základní transakce
630 Soupis provozních výkonů a zpřesnění návrhu
640 Definování souborů a dat
650 Dokončení specifikace programů
660 Tvorba plánu systémových testů
670 Tvorba operační dokumentace
680 Vytvoření plánu implementace
690 Tvorba uživatelského manuálu
Příklad úkolů, které jsou součástí jednoho kroku:
530 Přezkoumání a ověření logického návrhu
Tento krok ověřuje navržený logický model vzájemnou křížovou kontrolou datového a
funkčního (procesního ) návrhu. Je ukončením logického návrhu a je v něm schválen přechod do fáze
fyzického návrhu. Všechny informace jsou připraveny do podoby, ve které mohou být předloženy jako
zadání poptávkového řízení.
530.10 Ověřte, zda všechny funkce jsou realizovatelné pomocí navrženého Složeného
logického datového návrhu (Composite Logical Data Design - CLDD).
530.20 Proveďte formální revizi následujících dokumentů logického návrhu:
• Složený logický datový návrh (Composite Logical Data Design -CLDD)
• Popis entit (Entity Descriptions)
• Katalog funkcí (Function Catalogue)
• Návrhy kostry logiky aktualizačních a dotazovacích funkcí (LEPO & LUPO)
• Popisy pro ošetření chyby (Eerror Handling Narrative)
• Formáty a Popisy vstupů / výstupů (I/O Descriptions and Formats)
• Životní cykly entit (ELH)
• Nástiny logického dialogu (Logical Dialogue Outlines -LDO)
• Moduly pro ovládání logického dialogu (Logical Dialogue Controls -LDC)
530.30 Proveďte příslušné úpravy vyplývající z připomínek revize provedené v předchozím
bodě.
530.40 Vyžádejte si souhlas s přechodem do etapy 6.
Metoda SSADM obsahuje pouze první tři fáze vývojového cyklu informačního systému.
Nezabývá se tedy implementací, testováním a údržbou systému. Vytváří však předpoklady pro
úspěšný průběh i těchto fází.
Metoda SSADM se stala základem i jiných metod a systémů CASE, které je podporují, a
které patří do skupiny UPPER CASE, tj. věnují se analýze a návrhu systému, nikoliv jeho
programování a testování.
Metoda SSADM z hlediska zajišťování kvality
Metoda SSADM nahlíží na kvalitu jako na souhrn vlastností informačního systému, které
charakterizují a zabezpečují vhodnost jeho použití s ohledem na potřeby uživatelů. Přitom vychází
z předpokladu, že pro zajištění kvality je potřeba po celou dobu vývoje informačního systému
systematicky provádět činnosti, které explicitně kontrolují kvalitu návrhu. Takové kroky jsou
v metodě označovány zkratkou QA (Quality Assurance).
Konkrétně se jedná o tyto kroky:
019 Revize definic problémů
029 Formalizace zprávy Úvodní studie
150 Prověření výsledků zkoumání
210 Stanovení a unifikace požadavků uživatelů
260 Posouzení návrhu požadovaného systému
330 Dokončení a přezkoumání návrhu požadovaného systému
530 Přezkoumání a ověření logického návrhu
660 Tvorba plánu systémových testů
680 Vytvoření plánu implementace
Podrobný popis testovacích činností v každém kroku spolu s účastí uživatele při těchto testech
dává jistotu, že otázka kvality nebude opomenuta.
Otázkám kvality programového vybavení informačních systémů a jejího zajišťování je
věnováno speciální školení analytiků a programátorů v této oblasti (Process Quality Management),
které NCC Manchester pořádá v návaznosti na kurzy SSADM.
Formuláře SSADM
Produktová orientace SSADM vyžaduje, aby na konci každé činnosti byl přesně a závazně
definován výstupní dokument pro danou činnost, který slouží jako vstup pro činnost další.
V metodě SSADM verze 3. Je proto definováno 24 formulářů, které mají přesně definovánu
formu a obsah. V následující verzi 4. Je to už dokonce 47 formulářů.
Pokud se analýza a návrh provádějí ručně, lze si objednat předtištěné formuláře. Při použití
počítačové podpory jsou formuláře zobrazovány na displeji a vyplňovány prostřednictvím klávesnice.
Přehled názvů formulářů verze 3. SSADM ukazuje následující přehled:
05 Dekompozice diagramu toku dat (DFD Decomposition)
10 Seznam problémů a požadavků (Problem/Requirement List)
20 Matice entit (LDST Grid)
30 Popis entit (Entity Description)
40 Kartotéka datových položek (Data Item File)
50 Popis vstupů/výstupů (I/O Description)
60 Seznam datových kroků (Data Flow List)
70 Křížové přiřazení datových objektů a entit (Data Store/Entity Cross Reference)
80 Katalog aktualizací a dotazů (Update and Question Catalogue)
90 Křížové přiřazení datových skupin a procesů (Data Group/Process Cross Reference)
100 Matice entit a událostí (Entity/Event Matrix)
110 Kostra logického dotazovacího procesu (Logical Enquiry Process Outline)
120 Kostra logického aktualizačního procesu (Logical Update Process Outline)
130 Zdroje pro relační analýzu (Input to TNF Data Analysis)
140 Normalizace (Normalization)
150 Konsolidace tabulek ve 3. NF (Consolidated TNF Tables)
160 Objemy logického návrhu (Logical Design Volumes)
170 Kostra logického dialogu (Logical Dialogue Outline)
180 Katalog obecných procesů (Common Processing Catalogue)
190 Popis elementárních funkcí (Elementary Function Description)
200 Katalog událostí (Event Catalogue)
210 Slovní popis ošetření chyb (Error Handling Narrative)
220 Popis fyzických programů (Physical Program Description)
230 Specifikace fyzických procesů (Physical Process Specification)
Používané diagramy v SSADM
Metoda SSADM je velmi úsporná v používání diagramů. Při analýze a návrhu
používáme pouze tři druhy diagramů:
Diagramy toku dat (DFD – Data Flow Diagram) pro popis funkcí.
Diagramy logických datových struktur (LDS - Logical Data Structure) pro popis
logických vazeb mezi datovými entitami
Diagramy životního cyklu dat (ELH - Entity Life History) pro popis vlivu událostí
na stav datových entit systému
DFD – DATA FLOW
DIAGRAM
DFD diagram znázorňuje tok dat
BANKA
Externí entita – z ní a do ní jdou datové toky
1 Obchodní od.
Příprava mark.
plánu
D1 Kusovníky
INFORMACE O ZAKÁZCE
Znak procesu
Datový sklad (M- manuální, T- dočasný
soubor, D- na disku)
Datový tok
LDS diagram
Logical Data Structure
Zachycení vztahu mezi datovými
Název
datové
entity 1
Název
vazby
Označení typu vazby
Název
datové
entity 2
ELH diagram
Entity Life History
Zachycení životního cyklu datové entity
Název datové
entity
Seznam událostí a staré i nové stavy datové entity
Podrobné popisy podob diagramů a způsob jejich kreslení je prezentován na rozličných
stránkách o této metodě řady anglických institucí a univerzit..
4.2 Objektově orientovaný přístup k analýze a návrhu
4.2.1 Koncepce objektově orientovaného přístupu
Objektově orientované programování představuje dnes pojem, na kterém je dnes
založena tvorba software.. V případě objektově orientovaného přístupu totiž výjimečně
softwarové myšlenky předběhly hardwarové možnosti, když ve většině případů technické
prostředky výpočetní techniky jsou hybnou silou vývoje.
Všeobecně se mluví o objektově orientovaném programování jako o moderní
metodě návrhu programů a jejich realizaci. Je to způsobeno tím, že
existence
programovacích jazyků, které využívají myšlenek objektově orientovaných, byla
impulsem k zavádění této nové metody a tím k její prezentaci na veřejnosti.
Je však třeba hned v úvodu zdůraznit, že je správnější hovořit o objektově
orientované technologii, která v sobě zahrnuje celou škálu aplikací objektově orientovaného
přístupu. Objektově orientovaná technologie zahrnuje především objektově orientovanou
analýzu, která provádí analýzu problémů na základ objektově orientovaného přístupu. Dále
objektově orientovaný návrh programů a programových systémů, které jsou pak
realizovány objektově orientovaným programováním prostřednictvím
objektově
orientovaných jazyků. Výsledkem aplikací objektově orientované technologie jsou
objektově orientované produkty, které mají své charakteristické vlastnosti. Obecné
principy objektově orientovaného přístupu lze různým způsobem konkretizovat do
určitých objektově orientovaných
metod,
které
představují
plánovitou
a
systematickou aplikaci těchto principů pro řešení určitých problémů. Rozborem metod,
jejich porovnáváním a hodnocením se zabývá objektově orientovaná metodologie. V
neposlední řadě můžeme hovořit o objektově orientovaných technikách, které představují
určité dílčí vyřešení, ať již implementace programové nebo analytické činnosti, v
rámci objektově orientovaných metod. Uvedený přehled metod by měl postačit čtenářům
k lepší orientaci v objektově orientované technologii a umožnit jim zařadit některá nová
označení programových produktů (např. objektově orientované databáze), případně další
pojmy, do souvislosti s touto technologií.
Cíle objektově orientované technologie
Objektově orientovaná technologie umožňuje návrh a tvorbu programových produktů
tak, aby řešitel se mohl věnovat odborné problematice řešeného problému. Přitom dává
přednost využití již dosud vytvořených produktů před jejich návrhem od samého začátku.
Vytvořené produkty jsou nekomplikované, spolehlivé, snadno srozumitelné a
jednoduše opakovaně použitelné.
Použitím objektově orientované technologie dochází ke zvýšení produktivity při
návrhu a tvorbě programových produktů, a to cestou abstrakce a parametrizace. Zároveň se
redukují náklady na opravy a na provádění změn, tj. na údržbu programových
produktů.
4.2.2 Základní principy a pojmy
Objektově orientovaná technologie vychází z abstrakce reálného světa, ze kterého
vyděluje objekty, které jí slouží k lepšímu pochopení reálného světa a k jeho
modelování. Analogicky k objektům v reálném světě zavádí i vzájemné vztahy mezi
abstraktními objekty.
Základním pojmem objektově orientované technologie je objekt.
Uživatel však musí porozumět i dalším odborným pojmům, na kterých je objektově
orientovaná technologie založena, chce-li tuto technologii úspěšně používat. Je to nutná
podmínka pro pochopení některých netradičních přístupů k programování i analýze a k
překonání prvotního dojmu zdánlivé komplikovanosti.
Objekt (angl. OBJECT) v objektově orientované technologii je chápán, jak už bylo
řečeno, jako prostředek k pochopení reálného světa a k jeho modelování. V počítači je
realizován jako abstraktní datová struktura. Každý objekt má svůj název odlišný od jmen
jiných objektů a atributy, které ho charakterizují (např. objekt PRACOVNÍK může
mít atributy: osobní číslo, příjmení a jméno, datum narození, bydliště, stav, adresa
posledního zaměstnavatele). Atributy objektu nejen charakterizují jeho vlastnosti, ale
vypovídají o stavech objektu, případně popisují historii průběhu jeho aktivity.
Koncepce abstraktních datových struktur je však již delší dobu známa a používána ve
strukturovaném programování a datové modelování s nimi běžně pracuje. Nový přístup
objektově orientované technologie spočívá v tom, že pojem objekt zahrnuje také činnosti,
které jsou s objektem svázány. V praxi je objekt vytvořen strukturou datových položek
různých typů a činnosti jsou realizovány procedurami, resp. funkcemi. Toto spojení
datových struktur s algoritmy nazýváme zapouzdření (angl. ENCAPSULATION) a
činnosti zapouzdřené do objektu označujeme jako metody (angl. METHODS). Například k
již zmíněnému objektu PRACOVNÍK bychom připojili procedury zajišťující jeho evidenci
při nástupu do organizace, provádění změn v osobních údajích zajišťující administrativní
vyřízení při ukončení pracovního poměru atd.
Objekt A
Objekt B
Atributy
Atributy
Zprávy
Metody
Metody
Zapouzdřující rozhraní
Objekty se společnými vlastnostmi sdružujeme do tzv. tříd (angl. CLASSES), což
nám umožňuje přehledně uspořádat všechny objekty do určitých skupin.
Definice objektu, podobně jako definice typu proměnné, pouze popisuje druh
objektu a jeho vlastnosti ve vztahu k jiným objektům. Konkrétní výskyt příslušného druhu
objektu se nazývá instance. Například instance: 85324, Polák Josef, 20.6.1943, Praha,
Nádražní 20, svobodný, GRAFIA Brno, představuje jednu instanci objektu PRACOVNÍK.
Instance mohou mezi sebou spolupracovat tím, že si vyměňují zprávy, kterými si
sdělují různé žádosti na provedení potřebných akcí instancí jiného objektu. Zprávy
figurují jako elementární kroky a zároveň zajišťují návaznost jednotlivých kroků, aby se
dosáhlo požadovaných složitých činností. Například instance objektu VEDOUCÍ určitého
úseku dá pokyn k ukončení pracovního poměru určitého pracovníka. Při ukončování
pracovního poměru požádá instance tohoto pracovníka instanci objektu ÚČETNÍ o
zúčtování zbývající dovolené atp. Sdružování objektů, které mají podobné atributy a chování,
do tříd nám však neslouží pouze k utřídění objektů. Existence tříd nám umožňuje zavést
mechanismus dědictví (angl. INHERITANCE), kdy nový objekt určité třídy dědí
všechny vlastnosti této třídy. Například při definici objektů ÚČETNÍ, VEDOUCÍ nemusíme
znovu definovat, že každý z nich má své osobní číslo, příjmení a jméno atd. Využijeme
objektu PRACOVNÍK a obohatíme ho o atributy a metody, které zde musí být navíc
(označení útvaru, který je vedoucím veden, popisem prováděných činností atd.). Můžeme
tedy hovořit o rodičovském objektu (angl. PARENT) a o odvozeném objektu (angl.
DESCENDANT), který dědí (angl. INHERITS) všechny atributy a metody svého předka
(angl. ANCESTOR). Odvozený potomek přitom může být rodičem pro další vztah.
Takto vybudovaná hierarchie vztahů, která připomíná příbuzenské vztahy v
rodokmenech, nejen šetří výrazové prostředky (co se dědí je nutno znovu uvádět), ale
slouží i jako prostředek postupného poznávání reálného světa a jeho modelování.
Umožňuje od všeobecných vlastností a základních činností
postupně zpřesňovat
charakteristiku a působení jednotlivých objektů a instancí, jak to ostatně skutečně
probíhá v praxi. Tato vlastnost činí objektově orientovanou technologii zvlášť vhodnou
pro budování bází znalostí v expertních systémech.
Mechanismus zděděných
vlastností můžeme i
porušit a určitou instanci
individualizovat. Stane se to tehdy, když jí a pouze jí některé atributy předáme nebo některé
zděděné zrušíme.
Pro objektově orientovanou technologii je důležité, že máme možnost přiřadit jedno
jméno akci, které je sdíleno celou hierarchií objektů, přičemž však každá úroveň má
možnost přizpůsobit konkrétní provedení akce svým specifickým potřebám a podmínkám.
Toto označujeme pojmem mnohotvárnost (POLYMORPHISM) - polymorfismus.
Polymorfismus přináší objektově orientované technologii právě onu možnost
univerzálnosti v používání objektů, která dosud nebyla programátorům k dispozici. Pokud
chtěli vytvořit univerzální proceduru pro široké použití, mohli využít jen myšlenky
parametrizace. Ta však měla svá omezení. Volání procedury muselo respektovat počet,
pořadí a druh formálních a skutečných parametrů. Proto programátor nemohl např. v jazyku
Překrývání
metod, které
objektově orientovaná technologie dovoluje,
je
realizováno dvojím způsobem: statickým a virtuálním.
Rozdíl mezi voláním statických a virtuálních metod je důsledkem mezi
rozhodnutím okamžitým a rozhodnutím odloženým. Pokud použijeme volání statické
metody, říkáme v podstatě překladači:"Víš, kterou metodu chci provést. Zavolej ji!"
Volání virtuální metody však znamená:"Zatím nevíš, kterou metodu chci volat. Až přijde
čas volání, dozvíš se od instance její adresu!".
K programování lze použít hybridní – též hostitelské jazyky, kdy se ke klasickému
programovacími jazyku (Pascal, C, Basic) připojí objektově orientovaná technologie a
vznikne tak jazyk, který umožňuje objektově orientované programování (Turbo Pascal, C++,
Visual Basic). Druhým řešením je vyvinout speciální jazyky pro tuto oblast (Small talk,
Actor, Euclid, Beta, apod.)
Nakladatelství Grada. Computer Press. BEN a další vydala řadu knih, kde jsou
principy objektově orientovaného přístupu popsány daleko podrobněji.
4.2.3 Popis metody OBA
Metoda OBA umožňuje provádět objektově orientovanou analýzu.
Metodický aparát metody OBA (Object Behaviour Analysis) byl vytvořen na základě
objektově orientovaného přístupu. To je základním předpokladem toho, aby výsledky
analýzy mohly být úspěšně použity při objektově orientovaném návrhu programu. Jenom v
takovémto případě pak může mít výsledný program všechny přednosti, které nabízí
objektově orientovaná technologie programování.
┌──────────────┐
│
SYSTÉM
│
└──────┬───────┘
│
┌──────┴───────┐
Prototypové
prostředky
=>
┌
│
Analýza
│
┐
│
│
systému
│
│
│
└──────┬───────┘
│
┤
│
│
│
┌──────┴───────┐
│
│
│
Návrh
│
┤
└
│
systému
│
│
└──────┬───────┘
│
│
│
┌──────┴───────┐
│
│ Programování │
┼─
│
│
│
└──────┬───────┘
│
│
│
┌──────┴───────┐
│
│
Testování
│
│
│
systému
│
┤
└──────┬───────┘
│
│
│
┌──────┴───────┐
│
=>
Zpřesňování
systému
zdokonalování
systému
│
Užívání
│
│
│
systému
│
└──────────────┘
┘
a
U objektově orientované analýzy se požaduje, aby rozpoznala objekty, které v sobě
zahrnují chování i stav. Dále musí určit vztahy mezi objekty a rozdělit objekty podle
společných vlastností do tříd. Objektově orientovaná analýza musí stanovit, jak probíhají
vzájemné interakce mezi objekty.
OBA hledá odpovědi na otázky objektově orientované analýzy v pěti krocích.
Průběh aplikace OBA lze proto vyjádřit následující tabulkou:
Číslo kroku
1.Krok
Prováděná činnost
Pochopení aplikace
2.Krok
Vydělení objektů
3.Krok
Počáteční klasifikace
4.Krok
Identifikace vztahů
5.Krok
Modelování procesů
Výsledek činnosti
Úvodní popis a identifikace
chování systému
Soupis objektů a
charakteristika jejich chování
z hlediska systému
Třídy objektů , jejich chování
a viditelné vlastnosti
Relace mezi objekty a jejich
interakce
Specifikace požadavků na
procesy a doporučení
navržených prototypů
Metoda OBA používá při práci přirozeného jazyka ke snadno pochopitelnému popisu.
Výsledky jednotlivých kroků je vhodné uspořádat do tabulek.
Popis kroků OBA
První krok - Pochopení aplikace a identifikace chování
systému
a) Pochopení aplikace
Tato část prvního kroku slouží k seznámení se s aplikací, pro kterou vytváříme program.
Musíme se seznámit s činností, pro kterou je aplikace určena, jak tuto činnost aplikace
vykonává, jaké zákonitosti v aplikaci platí. Pro pochopení aplikace se také musíme seznámit
s okolím aplikace a s jeho působením na aplikaci. U složitějších aplikací tato část analýzy
zpravidla probíhá formou průzkumu mezi uživateli. K provedení průzkumu můžeme použít
řadu známých metod. Výsledkem této části analýzy je úvodní popis. Tento výsledek není
konečný, ale může být v případě potřeby doplňován. Z této části vychází všechny ostatní
kroky metody OBA. Je podkladem jak pro identifikaci chování systému a definici objektů,
tak pro hledání vztahů mezi objekty a pro modelování procesů.
b) Identifikace chování systému
Na základě výsledků předchozí části rozdělíme zjištěné činnosti probíhající v aplikaci.
Rozdělíme je na činnosti běžně opakované a mimořádné. Hlavním úkolem je získat seznam
nezbytných činností, které v aplikaci probíhají a které musí systém (námi vytvářený program)
zajišťovat. Musí se identifikovat i činnosti, které se pro aplikaci plánují do budoucna. Při
definování jednotlivých komponent námi navrhovaného systému a jeho chování je nutné mít
na zřeteli prioritu požadavků, které jsou na systém kladeny. Systém by měl v nejvyšší možné
míře sloužit lidem, kteří jej budou používat. Musíme zjistit, co uživatelé od systému požadují
a jak předpokládají, že jim systém ušetří práci.
Protože OBA používá jako vyjadřovací prostředek přirozený jazyk, je nutné sjednotit
termíny používané pro popis činnosti systému. Výsledek prvního kroku můžeme přehledně
zachytit následujícím způsobem v tabulce:
SCÉNÁŘ
Nositel
Akce
Příjemce
Výsledek
Množina takovýchto tabulek tvoří výsledek prvního kroku.
Ze souboru tabulek by mělo být pochopitelné, jak se systém chová a jaké zabezpečuje
činnosti.
V případě potřeby může být množina výsledných tabulek doplňována.
Druhý krok - Definování objektů
V tomto kroku definujeme objekty na základě zjištěného chování systému. Vyjdeme z
činností, které musí systém zajišťovat tak, jak byly stanoveny v předchozím kroku, a určíme
základní činnosti, které musí systém vykonávat (většinou odpovídají základním činnostem v
aplikaci). Máme-li definovány základní činnosti (chování) systému, potřebujeme určit, kdo
to provádí. Objekty nalezneme tak, že zjistíme, kdo nebo co odpovídá za určité chování.
Určené objekty zpracujeme pomocí záznamu, který obsahuje:
- název objektu
- odpovědnost
- souvislosti
Objekty jsou v aplikaci vytvořeny z konkrétních objektů, pojmů, procesů a událostí, které
jsou významné pro vyjádření chování. Jako objekt tedy vybereme vše, co je zdrojem nějaké
činnosti.
Výsledek druhého kroku je seznam objektů, jejich skupinový vztah k chování a viditelné
vlastnictví. K popisu objektů použijeme následující tabulky:
Objekt
Chování/odpovědnost
Viditelné vlastnictví
Viditelné vlastnictví říká čím je objekt charakterizován.
V průběhu práce může vzniknout potřeba provést tento krok vícekrát a doplnit seznam
objektů.
Třetí krok - Klasifikace objektů
Klasifikací objektů rozumíme seskupování objektů podle některých podobných prvků jejich
chování (tj. funkcí) a stavů (tj. uspořádání údajů).
Pro určení případných nových abstraktních objektů považuje metoda OBA klasifikaci na
základě chování za primární. Postupujeme tak, že seskupíme objekty na základě podobnosti
jejich chování. Při srovnání jejich chování pak můžeme dojít k závěru, že by mohlo být
vhodné vytvořit nový abstraktní objekt. Důvody, proč metoda OBA upřednostňuje návrh
nových abstraktních objektů na základě klasifikace objektů podle chování, vyplývají z
poznatku, že skutečný význam objektů nezávisí na jejich stavu a vlastnostech, ale na jejich
funkci, tj. na jejich skutečném chování.
Při klasifikaci objektů podle jejich viditelných vlastností můžeme přijít na to, že některé
prvky mají stejné (nebo z větší části stejné) vlastnosti a podobné chování. U takovýchto
objektů je třeba hledat objekt, který by mohl být jejich společným předkem nebo rozhodnout,
zda je možné takový objekt vytvořit. Tímto způsobem seskupujeme objekty do tříd a
budujeme třídní hierarchii.
Vytvoříme-li ve třetím kroku nový objekt, musíme se vrátit do druhého kroku, abychom k
tomuto novému objektu našli jeho chování a viditelné vlastnosti. Po druhém kroku pak
následuje opět klasifikace v třetím kroku s případným návratem zpět do druhého kroku
(vytvoříme-li ve třetím kroku nový objekt). Tento cyklus končí, pokud ve třetím kroku žádný
nový objekt nevytvoříme.
Nový objekt ve třetím kroku může vzniknout také v tom případě, když dojdeme k závěru, že
bude vhodné jej vytvořit na základě určité souvislosti mezi již existujícími objekty. Dokázat
takto vytvořit objekt je důležitou dovedností při aplikaci objektově orientovaného přístupu.
Při práci ve třetím kroku používáme tabulku:
Objekty se
Chování se
společnými rysy
společnými rysy
Viditelné vlastnosti
Nový návrh
Tuto tabulku používáme jak pro klasifikaci podle chování, tak pro klasifikaci podle stavů
(atributů, vlastností).
Do sloupce "Nový návrh" zapisujeme nově navržené abstraktní objekty nebo nově navržené
rodičovské předměty, a to podle toho, zda klasifikujeme podle chování nebo podle stavů
(atributů, vlastností). Jeden nově vytvořený objekt může připadat na dva a více objektů
uvedených ve sloupci "Objekty se společnými rysy". Do sloupce "Nový návrh" dále
zapisujeme objekty, které navrhujeme vytvořit na základě intuice.
Čtvrtý krok - Identifikace vztahů
V předchozích krocích jsme nalezli objekty, určili jejich chování a seskupili jsme je do tříd.
Ve čtvrtém kroku hledáme relace mezi objekty. Vztahy mezi objekty zachytíme tabulkou:
Objekt
Vztah
Propojení na
Ve sloupci "Vztah" uvádíme druh vztahu, ve kterém je objekt uvedený ve sloupci "Objekt",
vůči ostatním objektům. Ty se uvádějí ve sloupci "Propojení na" tak, aby byly ve stejném
řádku jako vztahy, které se k nim vážou.
Vztahy mezi objekty mohou mít řadu různých forem. Dvě základní z nich jsou efekt a
komunikace.
Efekt je událost, která změní stav konkrétního objektu. O komunikaci mluvíme v případě,
kdy objekt žádá jiný objekt o informaci, předává mu informaci, dovídá se o jiné informaci a
pod.
Závislé vztahy jsou takové, kdy na základě jednoho vztahu je vytvořen další vztah (např.
jeden objekt informuje druhý, že určitá činnost proběhla úspěšně).
Protože OBA používá přirozený jazyk, je třeba dodržovat maximálně jasný popis vztahů
mezi objekty.
Pátý krok - Modelování procesů
V tomto posledním kroku zbývá určit, které objekty mají počáteční aktivitu a identifikovat
sekvence aktivit. Používáme k tomu přehledu získaného v prvním kroku. Sekvence aktivit
musíme kontrolovat vzhledem ke čtvrtému kroku, abychom věděli, zda existují vztahy mezi
objekty, které si předávají aktivitu, a jsou-li tyto vztahy takové, jaké předání aktivity
požaduje. Toto srovnávání nám může pomoci odhalit chyby, kterých jsme se dopustili ve
čtvrtém kroku, resp. zmenší počet chyb, kterých se můžeme dopustit v pátém kroku.
Musíme také specifikovat životní cyklus objektů a jejich stav v rozličných fázích tohoto
cyklu. Ze stavu objektů by mělo být zřejmé, jaké aktivity jsou pro objekt v tomto stavu
přípustné.
Například, pokud máme objekt v mezním stavu, nesmí být připuštěna žádná aktivita, která
by vedla k jeho překročení.
Ukončení analýzy
Výsledkem metody OBA jsou požadované specifikace, popsané v pojmech chování, popis
objektů a jak jsou objekty organizovány. Tyto specifikace zahrnují jak superordinální
objekty (tj. objekty odvozené na základě chování skupin objektů, zobrazující často abstraktní
nadtřídy získané během analýzy) a subordinální objekty (tj. objekty získané abstrakcí z
reálného světa, zobrazené do konkrétních podtříd).
Po ukončení analýzy je poznáno základní chování a stav každého objektu, stejně jako vztahy
mezi objekty a posloupnosti aktivit.
Použijeme-li při tvorbě objektově orientovaného systému pro analýzu metodu OBA,
obdržíme materiály, které nám umožní produkovat jasný, pochopitelný návrh objektově
orientované struktury námi navrhovaného systému.
4.2.4 Popis jazyka UML
Metoda OBA se používá pro úvodní analýzu K Záznamu výsledků podrobnější
analýzy a podrobnějšího objektově orientovaného návrhu se používá v poslední době
nejrozšířenější grafický jazyk UML (Unified Modeling Language). V menší míře metoda
OMT (Object Modeling Technology).
Jazyk UML je orientován na grafický popis objektově orientovaných systémů, které
používá při jejich popisu:
Příjmání zák.
objednávek
Obchodní
asistent
Objednávání
zboží ze skladu
Vystavení obj.
dodavateli
Objednávání
služeb
Objednávání
upgrade
Use Case diagram
Conversation < Objednávání zboží >
Actor Action < Kontrola požadavků na zboží >
Actor < Obchodní asistent >
Response < Odeslání objednávky do ISLV >
Response < Vytvoření podkl. pro fakt. zál. >
Diagram typu jednání
OBJEDNÁVKA
PRODUKT
ZÁKAZNÍK
Vytvoření objednávky
Odeslání objednávky na službu
Odeslání objednaného upgrade
Odeslání objednávky na zboží
Vytvoření podkladuk fkt. zálohy
Potvrzení objednávky
DODAVATEL
POŽADAVEK
NA PRODUKT
Zrušení objednávky
Evidence údajů o objednávce
Diagram tříd, zodpovědnosti a spolu pracovníků
Obchodní
asistent
Obchodní
případ
Aktivace obchodního
případu
Požadavek
na produkt
Zákazník
Produkt
Rizikovost
zákazníka
Vytvoření
obchodního
případu
Zadání zákazníka
Ověření zákazníka
Zákazník existuje
Vyhledání pohledávek
Hlášení o neexistenci
zákazníka
Hlášení o solidnosti
zákazníka
Požadavek založení
zákazníka
Založení zákazníka
Kmenové informace
o zákazníkovi
Diagram sekvence událostí
4.2.5 Objektově orientované metody
4.2.5.1 Metoda RUP
IBM Rational Unified Process (RUP) je metodika vývoje softwaru, která zvyšuje
produktivitu vývojového týmu a umožňuje všem jeho členům využívat ty nejlepší
prověřené postupy. Tento on-line návod zavádí téměř dvacetileté zkušenosti společnosti
IBM Rational (dříve Rational Software Corp.) s vývojem softwaru do každodenní práce
vašeho týmu prostřednictvím průvodců, šablon a příkladů všech klíčových aktivit, se
kterými se při vývoji setkáváte. IBM Rational Unified Process zvyšuje efektivitu vaší
práce:
– Přístupem, který sjednocuje tým
– V praxi prověřenými nejlepšími praktikami softwarového vývoje
– Metodologií vývoje, která se jednoduše zavádí
– Snižováním rizika a zvyšováním předvídatelnosti softwarového vývoje
– Poskytováním kontroly nad plány a možnostmi dodání
– Zlepšováním týmové komunikace
Použití je snadno použitelné také díky on-line průvodci, který pomáhá vývojářům (ale
nejen jim) při provádění všech běžných aktivit v průběhu vývojového cyklu od řízení
projektu, modelování business procesů a řízení požadavků až po architekturu vývoje,
vizuální modelování, tvorbu dokumentace, ověřování kvality a řízení změn. IBM RUP je
prezentován ve formátu HTML, což umožňuje platformově nezávislý přístup přes firemní
intranet a grafickou navigaci umožňující uživatelům snadný přístup ke všem průvodcům a
šablonám zvyšujícím produktivitu. Lze si vybrat, zda budeme sledovat informace
vzhledem k dané roli či vzhledem k úkolu.
RUP podporuje šest nejlepších praktik, které umožňují efektivní vývoj vysoce kvalitních
aplikací:
– Iterativní vývoj zmírňující riziko v počátcích projektu
– Efektivní řízení požadavků
– Vizuální modelování pomáhající řídit komplexní vztahy a závislosti
– Na komponentách založené pružné architektury
– Kontrola kvality v průběhu celého cyklu
– Řízení změn v softwaru
RUP vychází z předpokladu, že u současných rozsáhlých systémů není možné na začátku
přesně definovat celý problém, navrhnout řešení, provést implementaci a až na závěr - kdy
je spotřebována většina přidělených finančních prostředků - celý systém otestovat. Proto
RUP používá tzv. iterativní cyklus vývoje aplikace:
Tento přístup je založen na těchto zásadách:
•
•
•
Rozdělení celého projektu na 4 fáze (každá se skládá z několika iterací se životním
cyklem typu “vodopád”)
Výsledkem každé iterace je spustitelná verze
Možnost objektivního posouzení stavu projektu
•
•
•
•
Rovnoměrnější pracovní vytížení vývojářského týmu (co nejdříve přináší konkrétní
výsledky, snazší sledování průběhu projektu a dodržování stanovených termínů pro
jednotlivé iterace)
Možnost testování „meziverzí“
Spolupráce návrhářů s uživateli v průběhu celého projektu
Včasné rozpoznání nesrovnalostí mezi požadavky, návrhem a implementací (možnost
kontrolovat a hodnotit dílčí části systému, omezuje se riziko vysokých nákladů
způsobených úpravami produktu v pozdní fázi vývoje).
RUP poskytuje proces podporující objektově orientované analýzy, plánování vývoje pro
nové J2EE aplikace založené na mezinárodním grafickém standardu popisu objektově
orientované analýzy a návrhu UML (Unified Modeling Language)
Definuje komponenty jako soudržné části kódu, které jsou díky výborně definovanému
rozhraní a chování, jež zaručuje dokonalé zapouzdření, snadno zaměnitelné ve zdrojovém
kódu i v samotném programu
Snaží se snížit efektivní velikost a komplexitu řešení, díky čemuž je toto řešení robustnější
Architektura RUP:
Definice požadavků na vývoj software se opírá o počítačovou podporu produktem
Rational RequisitePro (RRP). RRP je mocný, ale snadno ovladatelný nástroj pro správu
požadavků v průběhu vývojových projektů. Kombinuje jednoduchost produktu Microsoft
Word s obrovskými možnostmi databáze. Jedná se o optimální prostředí pro týmově
orientovanou správu požadavků a jejich seskupování na základě priorit. RRP pomůže
podnikům lépe porozumět dopadům způsobeným změnami jednotlivých požadavků a
analyzovat jejich vliv na ostatní požadavky, což umožní provádět rychlejší a kvalitnější
rozhodnutí. Díky integraci s ostatními Rational nástroji přináší RRP možnost rychlejšího
přístupu k požadavkům, které mají vliv na konkrétní projekt. Mezi klíčové vlastnosti
RequisitePro patří:
– Doplnění oblíbené aplikace MS Word o běžně používané databáze
– Podpora pro definování a sledování vazeb mezi požadavky (pro lepší
pochopení dopadu změn)
– Evidence různých typů požadavků a jejich atributů
– Spolupráce s uživateli v průběhu celého projektu
– Včasné rozpoznání nesrovnalostí mezi požadavky, návrhem a implementací
(možnost kontrolovat a hodnotit dílčí části systému, omezuje se riziko
vysokých nákladů způsobených úpravami produktu v pozdní fázi vývoje
– Snazší zapracování změn požadavků
RUP používá pro znázornění architektury systému pět pohledů. Jednotlivé pohledy řeší
různé aspekty fungování systému, nejsou na sobě však nezávislé a do určité míry se
překrývají. Všechny pohledy a modely nejsou samozřejmě nemusí být aplikovány pro
všechny projekty.
4.2.5.2 Metoda BORM
Jeden z autorů metody doc.V.Merunka (ČZU Praha PeF ) představil tuto metodu na
celostátním semináři Tvorba softwaru 99 v Ostravě takto:
Metoda BORM (Business Object Relation Modeling) byla vyvíjena postupně od roku 1993.
Od počátku byla orientována na podporu tvorby objektově orientovaných softwarových
systémů založených na čistých objektově orientovaných programovacích jazycích a
vývojových prostředích, jakými jsou například prostředí Smalltalku (VisualWorks,
VisualWave, VisualAge, ...) a objektové databáze (Gemstone, Artbase, ...). Během práce na
této metodě bylo zjištěno, že některé její techniky a nástroje je možné využít k reprezentaci
znalostí a modelování business procesů.
Práce na BORMu je od svého počátku součástí grantu VAPPIENS (research project Various
Programming Paradigms in Integrated Environments), který je součástí programu "Know
How Fund of Czech Academic Link Programme" Britské rady (British Council). Od roku
1996 je další vývoj také podporován firmou Deloitte&Touche Czech Republic and Central
Europe, kde je tato metoda také používána.
Metoda BORM a především její možnosti analýzy v počátečních fázích vývoje projektu byla
prakticky použita například v projektech pro pražské zdravotnictví, Ústav pro státní
informační systém ČR, elektroenergetiku, zemědělství, telekomunikace a plynárenství. Ve
všech těchto projektech se ukázalo, že BORM lze dobře využívat jako nástroj pro provádění
business process reengineeringu. Výsledky takové analýzy také velmi dobře slouží pro
podrobnou a úplnou specifikaci zadání softwarového projektu.
Jak se BORM liší od jiných metod ?
BORM byl navrhován jako metoda, která pokrývá všechny fáze vývoje softwaru (obr.1.).
Velká pozornost je na rozdíl od jiných metod věnována úvodním fázím projektu.
Nejpoužívanější metody se spoléhají jen na analýzu textového popisu zadání a odvozování
objektů a jejich operací z podstatných jmen a sloves v jednotlivých větách. Technika "usecase", která je součástí dnes nejpoužívanějších metod OMT a UML, sice pomáhá při
definování interakcí a členění systému, ale poskytuje jen malou podporu pro identifikaci
objektů ze zadání. Z "use-case" diagramů se však přímo vytvářejí diagramy sekvencí a
komunikací mezi objekty a třídní diagramy. U všech těchto následných diagramů se však již
předpokládá, že objekty a třídy jsou již rozpoznány. Stručně řečeno, většina dnes používaných
metodologií začíná nad množinou objektů, pro které se například vytvářejí nejrůznější
softwarově orientované diagramy, ale sofistikovanější postupy, jak tyto objekty v zadaném
problému najít a zkontrolovat jejich správnost, v nich chybějí.
Obr. 1.
Druhou odlišností od jiných metod je skutečnost, že BORM pro každou jednotlivou fází
životního cyklu využívá v diagramech jen omezenou sadu pojmů. Předpokládá se totiž, že
během projektování dochází k postupným přeměnám pojmů na jiné (obr. 2.). Například ve
fází analýzy se nepoužívají pojmy jako agregace, jednoduchá či vícenásobná dědičnost,
protože tyto pojmy jsou relevantní až pro implementaci. Naopak pojmy jako stav, přechod či
asociace jsou používány během analýzy, ale ve fázi implementace, kdy se snažíme model
přizpůsobit cílovému implementačnímu prostředí, se s nimi již nepracuje. Nejde jen o
postupné zvyšování úrovně detailu ve vytvářeném modelu, ale skutečně o řadu transformací
modelu v průběhu životního cyklu. Na rozdíl od přístupu BORMu u metody OMT (a také
UML) lze například do object-class diagramu libovolně vkládat kterýkoliv z pojmů bez
ohledu na to, jestli se daný diagram týká fáze analýzy nebo návrhu.
Obr. 2
Třetí a poslední specifickou vlastností BORMu je skutečnost, že metoda nevyžaduje
oddělování od sebe statických a dynamické pohledů na systém do různých typů diagramů s
rozdílnou notací a dovoluje je dokonce v jednotlivých diagramech kombinovat. V BORMu je
každý pojem reprezentován shodnými symboly bez ohledu na to, jestli se jedná o diagramy
datové struktury nebo komunikací mezi objekty. BORM používá pro znázorňování
konceptuálních a softwarových pojmů většinu symbolů shodně s jazykem UML, ale dovoluje
v jednom diagramu znázornit například posílání zpráv mezi metodami různých objektů v
různých stavech. Tento přístup dovoluje vyjádřit konzistentním způsobem některé žádoucí
detaily softwarové konstrukce, které lze výhodně aplikovat především při návrhu pro čistě
objektově orientované programovací jazyky. Tento způsob je mnohem jednodušší než např.
tvorba více od sebe oddělených třídních, stavových a kolaboračních diagramů a také dovoluje
zobrazit větší množství informací. Na druhou stranu však samozřejmě platí, že samostatné
stavové či iterační diagramy jsou v BORMu také používány.
5 Funkce a náplň produktů pro počítačovou podporu softwarového inženýrství
Systémy CASE (Computer Aided Software Engineering) představují náhradu
klasického využití tužky a papíru při analýze a návrhu informačních systémů počítačem.
Systémy CASE se skládají z jednotlivých prvků, které podporují určité činnosti při
vývoji software. V anglosaské literatuře je zvykem tyto prvky označovat pojmem TOOLS
(nástroje). Řada menších softwarových firem se specializuje jen na výrobu takových
izolovaných nástrojů, které mohou uživatelé použít pro řešení určitého konkrétního problému
při tvorbě software. V tomto případě není podporován celý životní cyklus, ale jen jeho některé
části. Podle toho pak můžeme hovořit o různých druzích nástrojů pro určitou úroveň
počítačové podpory životního cyklu:
PRE CASE – Podpora prací předcházejících vývoji software (analýza požadavků
uživatele, stanovení cílů produktu, naplánování jeho realizace)
UPPER CASE – Podpora počátečních stádií vývoje software (funkční a
analýza, návrh modulové struktury produktu)
datová
MIDDLE CASE – Podpora pokročilých stádií vývoje software (detailní funkční a
datový návrh, specifikace programových funkcí)
LOWER CASE – Podpora implementačních stádií tvorby programového kódu (řešení
na fyzické úrovni technického vybavení, generování popisů databázových schémat,
programování v programovacích jazycích a překlad resp. generování kódu, testování
programů)
POST CASE – Podpora akceptačních testů, řízení verzí a podpora tvorby
dokumentace produktu.
Je potřeba zdůraznit, že přínosy produktů CASE jsou tím větší čím větší, čím větší
část životního cyklu je jimi podporována. Maximálních přínosů se dosahuje při podpoře
celého vývojového cyklu produkty CASE!
Poznamenejme, že určitý problém představují moduly typu Lower CASE pro
generování kódu aplikace, které jsou závislé na typu cílového mikroprocesoru, cílového
operačního prostředí, cílového databázového produktu, apod. Proto často tento modul má
cenu, která odpovídá výši součtu cen všech ostatních částí.
Další způsob dělení systémů CASE vyčleňuje samostatně integrované systémy
CASE, které integrují celou řadu jednotlivých nástrojů CASE ve snaze podporovat kompletně
celý životní cyklus vývoje software.
Integrované systémy CASE bývá zvykem dělit na:
Integrované stavebnice CASE (BRICK BOX CASE) = soustava prvků, které si podle
potřeby zakoupí ( nebo nezakoupí ) uživatel a sestaví si systém CASE podle potřeby a
podle finančních možností (může zakupovat jednotlivé nástroje i postupně).
Uzavřené systémy CASE (CLOSE I-CASE) = jsou dodávány jako uzavřené kompaktní
stejnorodé celky.
Otevřené systémy CASE (OPEN I-CASE) = ve kterých si uživatel může určité nástroje
vyměnit podle potřeby ihned nebo později. Např. může zařadit tu metodu, kterou preferuje.
Důležitou skutečností je způsob, jak jsou v integrovaném systému CASE jednotlivé nástroje
spolu propojovány. Pokud pouhý výstup z jednoho prvku slouží jako vstup do druhého prvku,
hovoříme o funkční integraci. Pokud jsou nástroje propojeny přes společnou databázi projektu,
hovoříme o datové integraci. Datová báze projektu umožňuje úplnou funkční integraci. Navíc
obsahuje pro všechny nástroje data celého projektu. Datová báze projektu bývá v integrovaných
systémech CASE různě nazývána zvláštním jménem: REPOSITORY, DATA DICTIONARY,
ENCYCLOPEDIA aj.
T1
T2
Repository, Data Dictionary Encyclopeadia
T3
T4
Má-li se použít počítače k podpoře navrhování programového vybavení, musíme
zvolit prostředek k jeho popisu tak, abychom mohli v průběhu vývoje programového
vybavení vložit do počítače jeho popis na právě probíhajícím stupni tvorby. Systémy CASE
používají různé prostředky pro popis software:
• Verbální popis
Verbální způsob popisu vychází z myšlenky maximálně se přiblížit vyjadřovacím
prostředkům přirozeného jazyka. Protože navazuje na dosavadní způsob ručního popisu
funkcí a dat, zdá se být nejpřirozenější. Problémem je zde jednoznačné pochopení takového
textu počítačem i přesto, že metody umělé inteligence učinily velké pokroky v porozumění
přirozeného jazyka. Proto se používá různých formalizovaných podmnožin zejména jazyka
anglického. Např. Structured English v metodě De Marco nebo jazyk PSL/PSA v projektu
ISDOS.
• Symbolický popis
Symbolický způsob popisu vychází ponejvíce z formalizovaného symbolického
jazyka matematiky (množiny, funkce, matematická logika). Např. Formální popis složitých
systémů doc. Fuchse nebo Vienna Development Language. Výhodou je stručnost a přesnost.
Nevýhodou je potřebná znalost specifického způsobu symbolického vyjadřování.
• Tabulkový popis
Tabulkový způsob používá určité množiny standardizovaných tabulek. Každá tabulka
má zvolenou strukturu sloupců určitého významu a pomocí řádků se pak zaznamenávají
potřebné vlastnosti software. Protože se dá využít ke zpracování tabulek relačních databází,
je tento způsob v současných systémech CASE velmi rozšířen. Např. Chandor Williamson:
Systémová analýza a syntéza nebo jazyk rozhodovacích tabulek (Decision Table). Při
velkém rozsahu software se však takový popis stává nepřehledným a pracným.
• Grafický popis
Grafický popis používá různých grafů pro názorné vyjádření vlastností software. Pro
svou názornou vypovídací schopnost je grafický popis velmi rozšířen. Jeho rozšíření
umožnila výkonná počítačová grafika na současných osobních počítačích. Např. diagramy
datových toků, diagramy logické struktury dat; vývojové diagramy, nebo diagramy jazyka
UML.
Současné systémy CASE většinou kombinují různé způsoby popisu podle potřeby v
jednotlivých fázích vývoje.
Systémy CASE jsou navrhovány také s přihlédnutím na proměnu priority otázek
kladených při realizaci programového vybavení: PROČ?, CO?, KDY? a JAK?.
Změna v důležitosti kladení otázek při vývoji systému
Obrázek: Změna v důležitosti kladení otázek při vývoji systému
Systémy CASE využívají posledních poznatků z teorie tvorby programového vybavení tím, že
jejich funkce jsou navrženy podle metod strukturované analýzy a strukturovaného návrhu. Tyto
metody se liší :
v rozdělení kroků, ve kterých je software vyvíjen (tj. definují si vlastní životní cyklus)
v používaných technikách (kreslení diagramů a druhy diagramů) ve stupni propracovanosti
(detailní návody nebo jen rámcové cíle)
v různém upřednostňování datové a funkční analýzy resp. datového a funkčního návrhu
v problémové orientaci navrhovaných produktů (informační systémy pro řízení podniků,
systémy řízení technologických procesů atd.)
v orientaci na činnosti nebo na produkty
Na druhé straně mají mnoho vlastností společných. Především jsou všechny založeny na
strukturovaném přístupu, který je prováděn shora dolů (TOP DOWN).
Tvůrci produktů CASE na tuto situaci reagují různě:
zvolí určitou metodu, kterou považují pro svůj podnikatelský záměr za nejlepší a navrhnou
svůj produkt podle principů této metody
vytvoří kompilací stávajících známých metod metodu vlastní, kterou použijí za základ
svého produktu
vytvoří otevřený produkt CASE, který připraví tak, aby si uživatel mohl zvolit určitou
metodu, kterou preferuje
Zatím nejsou rozšířeny produkty, založené na metodách objektově orientovaného přístupu,
který preferuje přístup "zdola nahoru" (BOTTOM UP).
Systémy CASE, které jsou navrženy tak, že si vynucují závazné dodržování postupů, které
metoda vyžaduje, mají tento režim označován názvem "STEP BY STEP MODE" na rozdíl od jiných,
které dovolují podle potřeby skládat návrh produktu volným prokládáním jednotlivě používaných
nástrojů, u nichž se tento režim nazývá "MATRIX MODE". Dokonalejší CASE s mozaikovým
způsobem práce mají možnost vyvolat funkce, které kontrolují konzistenci celého návrhu a upozorňují
na "bílá místa" nebo na nesrovnalosti, které mohou být příčinou chyb a nedostatků v navrhovaném
produktu.
Zajímavé je sledovat průběh nákladů při vývoji produktu, termín předání produktu uživateli a
náklady na údržbu při využívání produktu. Klasický způsob navrhování ad hoc vedl k vysokým
nákladům na údržbu. Špatná kvalita byla následkem podcenění úvodních fází návrhu.
Průběh nákladů ukazuje křivka A na následujícím obrázku:
Náklady
Předání systému do provozu
Ručně
C
S metodou
B
A
S využitím CASE
Čas
Obrázek: Průběh nákladů při vývoji produktu
V důsledku důkladnosti a preciznosti postupů, které jsou obsaženy v metodách, se dosáhne
podstatně vyšší kvality a snížení nákladů na údržbu, ale za cenu zvýšené pracnosti, která se projeví
nejen zvýšenými náklady na vývoj, ale i pozdějším předáním výsledného produktu uživateli. Viz
křivku B na předchozím obrázku.
Teprve realizace automatizace v systémech CASE umožní zkrátit termín předání produktu ve
srovnání s ručním způsobem při využití dokonalých metod. Navíc automatické generování umožní
snížit náklady na programování a automatické testy sníží počet chyb, což se projeví v dalším snížení
nákladů na údržbu. Viz křivku C na předchozím obrázku.
Zkušenosti z realizace mnohých programových produktů ukázaly,že uživatelé nedovedou
správně specifikovat svoje požadavky na software. Jsou však schopni kriticky posoudit konečné
výsledky návrhu z hlediska své práce. Pokud se tak stane až na konci vývoje a jejich kritické
připomínky vedou ke změnám, prudce vzrůstají náklady a prodlužuje se neúměrně termín předání
produktu. Z toho důvodu mají systémy CASE v sobě zabudované prostředky, pomocí kterých lze
vytvořit vzory tiskových zpráv, obrazovek apod. tak, aby se mohly předvést uživateli. Ten může
bezprostředně reagovat a upřesnit svoje požadavky. Tento způsob práce je označován jako
prototypování (PROTOTYPING) a využívá se při něm zejména vizualizačního programování.
Principy práce produktů CASE
1 Princip interaktivní počítačové podpory.
Tím rozumíme, že počítač v interaktivním režimu podporuje člověka v jeho činnostech
a jen některé rutinní činnosti vykonává sám. Tuto skutečnost je potřeba zdůraznit proto, že
nelze automatizovat úplně tvorbu počítačových aplikací. Tzv. vývojový automat zatím nelze
současnými postupy realizovat.
Omezení
Požadavky
Programy
DA
Dokumentace
Odmítnuté požadavky
Development Automat
2 Princip podpory zajišťování vysoké kvality softwaru.
Velkou pozornost věnují systémy CASE zajištění vysoké kvality vyprodukovaného
software. Vyplývá to ze zjištěné závislosti že čím se chyba později odhalí, tím vznikají vyšší
náklady na její odstranění.
Náklady na odstranění chyby
Náklady
Čas
Obrázek: Náklady na odstranění chyby
Proto systémy CASE jsou navrhovány tak, aby systematickými kontrolami automaticky
vyhodnocovaly možná fakta, která by mohla indikovat různé chyby (opomenutí požadavku zákazníka,
nepoužívaná nadbytečná funkce nebo datová struktura apod.). Tyto kroky se nazývají QUALITY
ASSURANCE STEPS. V současné době se při použití produktů CASE dosahuje řádový pokles počtu
chyb – až 1x méně chyb ve srovnání s tvorbou programů bez použití produktů CASE.
3 Počítačová integrace činností a pracovníků
Produkty se snaží propojit a podpořit co nejvíce činností, které je potřeba při tvorbě
softwaru (prostřednictvím jednotné databáze a prostřednictvím mnoha modulů, které je
možno využít, při tvorbě softwaru), včetně integrace jednotlivých členů programovacích
týmů. Počítačová podpora členů vývojového týmu prostřednictvím počítačové sítě, včetně
přístupu na síť Internet, je velmi důležitá, protože dnes jsou aplikace vytvářeny převážně
v pracovních skupinách.
4 Počítačová podpora využívání kombinace různých prostředků k popisu software.
Produkty umožňují využívat různých způsobů popisu v následujícím pořadí:
– Grafický popis (obvykle přednastavený)
– tabulkový způsob
– verbální popis (komentáře)
– symbolický popis
5 Princip podpory zvyšování produktivity.
Systémy CASE nahrazují de facto dosavadní příslovečnou "tužku a papír" při práci analytiků a
programátorů. Automatizují nejen kreslení diagramů, ale i další rutinní práce při vývoji software, které
se dají algoritmizovat. Proto se v důsledku jejich použití zvyšuje produktivita analytické i
programátorské práce. To je zvlášť nutné proto, že obecně produktivita prací na vývoji software klesá
se vzrůstající velikostí produktu.
Produktivita
Při použití prostředku CASE
Bez použití prostředku CASE
Velikost
produktu
Malé
produkty
Střední
produkty
Velké
produkty
Obrázek : Závislost produktivity na použití CASE prostředku a velikosti vyvíjeného
produktu.
Z diagramu vyplývá, že velké softwarové produkty nelze bez využití CASE
dnes realizovat.
6 Princip počítačové podpory využívání znalostí
Tento princip se objevuje u některých progresivních produktů CASE a
umožňuje využívat prvky umělé inteligence pro podporu vývojových pracovníků jednak
- shromažďováním poznatků (Knowledge Management)
- využíváním expertních systémů
- využíváním principů učení (funkce Wizard, Template, Teach –In, apod.).
Funkce produktů CASE
Funkce produktů CASE vycházejí z principů jejich práce a z potřeby tvorby
software:
•
•
•
•
•
•
•
•
•
•
•
Iniciovat produkt
Vytvořit různé diagramy/popisy
Uložit data diagramů/popisů
Přečíst data diagramů/popisů
Modifikovat diagramy/popisy
Kontrola diagramů/popisů
Analýzy diagramů/popisů
Doplňkové funkce (nastavení pracovní plochy, barev, stylů, apod.)
Podpora týmové práce
Zpracování a tisk dokumentace
Statistika a protokolování práce uživatele
Přínosy produktů CASE
Zkušenosti z používání produktů CASE potvrdily, že je možno dosáhnout
následujících přínosů:
•
•
•
•
•
•
•
•
•
Zkrácení doby vývoje ( až na 50 %)
Snížení nákladů ( o 30 %)
Zvýšení kvality ( 10 x méně chyb)
Získání aktuální dokumentace (ihned po ukončení návrhu) s minimálním
úsilím
Snadnější zapracování nových pracovníků
Snížení nákladů na údržbu (na 20 % tj. o 80 %)
Snadnější provádění změn v projektech (3x rychleji a 50 % nákladů)
Zvýšená přenositelnost řešení (jen cena generování kódů pro jiný počítač
nebo DBS)
Snadná opakovanost zpracovaných návrhů
Je nutno poznamenat, že je potřeba odlišit situaci, kdy je používán produkt CASE
vývoj softwaru, a situaci, kdy se z úsporných důvodů používá jen grafických prostředků pro
vytvoření diagramů popisujících software, přičemž se použije takových produktů jako MS
VISIO nebo AutoCAD. Těmito produkty lze získat jen elektronickou verzi grafického popisu
software.
6 Jakost software
6.1 Význam jakosti software
Jakost software představuje v současnosti aktuální problém. Tak, jak se zvyšuje všeobecně
tlak na jakost a zvyšuje počet programových produktů, můžeme určit následující skutečnosti,
které jsou příčinou této zvýšené pozornosti, která je věnována jakosti software:
Ochrana investic do softwaru, protože objem vložených finančních prostředků představuje
celosvětově nesmírně vysoké částky
SW se stal spotřebním zbožím a zákazníci chtějí být chráněni před nekvalitními programy
Zvýšení bezpečnosti aplikací v oblasti řízení , kde chyba v softwaru může mít
katastrofální následky (řídicí systémy jaderných elektráren, automatické řízení letadel a
aut, programové řízení funkcí lékařských přístrojů, apod.).
Přesto je současný stav v oblasti kvality programového vybavení dosti neuspokojivý.
V důsledku chyb v software ztrácí ekonomika USA ročně 59,9 miliardy dolarů, jak ukázala
studie National Institute of Standards and Technology v roce 2002 Studie také konstatovala,
že přestože v současné době při tvorbě software nelze všechny chyby odstranit, více než
třetině by bylo možno se vyhnout při dokonalejším systému zkoušek.
Firma Microsoft přiznala v polovině roku 2003, že kvůli softwarové chybě mohly být
v ohrožení účty 200 miliónů uživatelů , protože potenciální útočník se mohl dostat jak k emailovému účtu, tak k číslům kreditních karet, pokud uživatel použil ve službě Internet
Passport platbu kartami pro virtuální obchodní domy.
V průběhu let 2005 - 2006 se vyskytly chyby v konfiguraci software u programového
vybavení rychlovlaků Pendolino. V důsledku těchto chyb utrpěly České dráhy přímou ztrátu
několika desítek miliónů korun a nepřímou ztrátu v oblasti prestiže dodávky těchto
rychlovlaků.
Uvedené příklady mají dokumentovat význam kvality softwaru. Ve vyjmenovávání
dalších by bylo možno úspěšně pokračovat.
6.2 Znaky jakosti software
Mezinárodní normalizační instituce ve své normě ISO 9126 stanovila následující
charakteristické znaky jakosti software:
Funkčnost, která by měla zajistit realizaci požadovaných funkcí
Bezporuchovost programu
Použitelnost programu s co nejmenším vynaloženým úsilím od uživatele (snadná
ovladatelnost, jednoduché pochopení funkcí a varovných hlášení)
Efektivnost s jakou program vykonává požadované funkce z hlediska času a využívání
paměťové kapacity)
Udržovatelnost v průběhu svého provozování při prováděný požadovaných změn
Přenositelnost, která by měla zajistit minimalizaci práce při vložení programu do jiného
technického a operačního prostředí.
6.3 Testování software
Základním problémem softwarového inženýrství je nalezení efektivního způsobu
prověřování jakosti programů, kterou můžeme ověřit:
Dokazováním správnosti programu provedením exaktního důkazu, že program je správný
prostřednictvím matematické logiky. Tento způsob prokazování jakosti softwaru je však
dnes pro svoji nesmírnou náročnost pro praxi nepoužitelný.
Testováním programu, kdy prokazujeme chyby prostřednictvím testovacích výpočtů.
Tento způsob je dnes nejrozšířenějším, běžně používaným způsobem ověřování správnosti
programů
Testováním rozumíme opakovaný proces provádění a vyhodnocování testovacích
výpočtů, kterým se snažíme odhalit chyby v programu. Testování ukončujeme tehdy, když po
dostatečně velkém počtu reprezentativních testovacích výpočtů usuzujeme, že je vysoká
pravděpodobnost pro bezchybnou práci testovaného programu. Bohužel platí, následující
tvrzení:
Testováním lze prokázat přítomnost chyb v programu.
Nelze však prokázat, že program chyby NEMÁ!!!
Protože, jak bylo výše uvedeno, je testování programů nejrozšířenější způsob ověřování
jejich správnosti, musí mu tvůrci softwaru věnovat mimořádnou pozornost. Jakost testování
závisí na:
množství a kvalitě testovacích dat, která by měla být pro testování speciálně a promyšleně
v potřebném množství připravena
úrovni použitých testovacích prostředků, které by měly být přiměřené složitosti
testovaného programu
použitých metodách testování, aby se postupovalo systematickým způsobem v celém
průběhu vývoje a zkoušení programu
znalostech pracovníků, kteří programy tvoří a testují.
Zodpovědné plánování testů a správná metodika testů jsou základním předpokladem pro
dobrou jakost programového vybavení, které je vytvářeno nebo používáno, a musí být
součástí systému řízení jakosti podle norem ISO 9000:2000.
Testování programů je možno provádět velmi různorodým způsobem. Z této
skutečnosti vyplývá i velká různorodost testovacích prostředků, které je možno rozdělit podle
různých hledisek.
Následující rozdělení vychází z práce doc.J.Hořejše.
Rozdělení z hlediska manipulace s programem při testování:
a) Statické testovací prostředky, které nepředpokládají provádění programu při testování.
Podrobují analýza zdrojový test resp. přeložený kód a snaží se nalézt nepravděpodobné
konstrukce nebo nesprávné posloupnosti příkazů (např. čtení neotevřeného souboru,
použití neiniciované proměnné, apod.).
b) Dynamické tetovací prostředky, které předpokládají provádění programu na počítači buď
přímo nebo interpretačním programem
Dynamické testovací prostředky dělíme z hlediska způsobu podávání zpráv o průběhu
testovacího výpočtu:
a) Sledovací testovací prostředky, které podávají zprávy bezprostředně s průběhem výpočtu
b) Post Mortem prostředky, které podají zprávu o výsledku stavu a uplynulém průběhu
programu po jeho přirozeném, nebo mimořádném ukončení.
Rozdělení z hlediska zásahu do programu:
a) Testovací prostředky bez nutnosti zásahu do programu. Těmto prostředkům stačí jen
zdrojový text nebo strojový kód.
b) Testovací prostředky s pasivními doplňky v programu (příkazy programovacího jazyka
nebo vložené strojové instrukce). Tyto doplňky se nepodílejí na základních funkcích
programu, ale provádějí funkce z hlediska potřeb testovacího výpočtu (indikace průchodu
částí programu, výpis hodnoty určitých proměnných ve stanoveném okamžiku, apod.).
Tyto doplňky se chovají z hlediska kompilátoru jako pouhé komentáře nebo jsou aktivní
jen ve zvláštním režimu HW počítače a v běžném pracovním režimu se chovají jako
prázdné instrukce, takže je není nutno odstraňovat z programu.
c) Testovací prostředky vyžadující modifikaci zdrojového textu programu nebo provedení
zvláštní kompilace, při které se generovaný kód programu doplní o speciální fragmenty
programu, zajišťující podporu testování. Tyto prostředky je nutno po testování z programu
odstranit.
Sledovací testovací prostředky můžeme rozdělit podle předmětu sledování
a) Sledování průběhu výpočtu. Můžeme sledovat buď adresy strojového kódu nebo
symbolická označení ve zdrojovém textu programu, kterými výpočetní proces prochází
(jmény návěští resp. čísla příkazů, čísla řádku zdrojového textu, jména vyvolávaných
podprogramů či objektů, apod.). Sledování můžeme provádět krok za krokem nebo při
skocích v programu. Sledovat lze řízení v celém programu nebo v jeho vybraných částech,
přičemž ohraničení může být zadáno jako statické nebo se může dynamicky měnit
v průběhu programu.
b) Sledování stavu proměnných. Sledovat můžeme obsahy paměťových buněk, které jsou
zadány prostřednictvím adres nebo které jsou zadány symbolickými identifikátory
proměnných. Lze sledovat všechny proměnné v programu nebo vyjmenované vybrané
proměnné. Logickým požadavkem je vázání tisku hodnoty na určitou podmínku:
•
•
•
•
Proměnná změnila svoji hodnotu ke stavu posledního snímku paměti
Vyskytl se určitý předepsaný incident (přerušení, přeplnění, stisknuté
tlačítko na ovládacím pultě nebo určité klávesnice, apod.)
Určitá proměnná nabyla specifikované hodnoty (např. čítač A dosáhl
hodnoty 100)
Bezpodmínečný tisk hodnoty proměnné při prováděném snímku paměti.
Samozřejmě lze způsoby sledování kombinovat.
Rozdělení podle způsobu režimu provádění testovacího výpočtu:
a) Testování prováděné v dávkovém režimu
b) Testování provádění v interaktivním režimu on-line
Podle přítomnosti prostředků při testovacím výpočtu rozeznáváme:
a) Prostředky rezidentní – přítomné trvale po celou dobu testovacího výpočtu v operační
paměti
b) Prostředky přivolávané do operační paměti podle potřeby až na základě předepsaného
incidentu
Podle způsobu umístění v programu dělíme testovací prostředky na:
a) Interní, které jsou nedělitelnou součástí programu
b) Externí, které jsou umístěny mimo strojový kód programu
Rozdělení podle závislosti na programovacích prostředku:
a) Prostředky testování, které jsou součástí programovacího jazyka (kompilátoru)
b) Prostředky testování, které jsou nezávislé na použitém programovacím jazyku.
Rozdělení podle režimu, ve kterých pracují testovací prostředky:
a) Testovací režim, kdy je prováděno testování programu pomocí testovacích prostředků na
testovacích datech
b) Rutinní výpočetní režim, kdy je prováděn běžný výpočet a testovací prostředky nejsou
použity nebo je jejich činnost blokována.
c) Režim latentního testování – kdy testovací prostředky zdánlivě nepůsobí, ale jejich
činnost se projeví v okamžiku určitého incidentu (překročení horní meze indexu určitého
pole, přeplnění, dělení nulou, apod.)
Samostatně se vyčleňují:
a) Generátory testovacích dat, které vygenerují soubory dat pro testovací výpočty
b) Speciální testovací prostředky, které testují jiné vlastnosti programu (dobu odezvy,
čerpání operační paměti, využívání paměťových registrů, reakci na terminálovou zátěž,
apod.)
c) Prostředky automatického testování, které automatizují určité činnosti, související
s testováním (generování skriptů a scénářů, automatické generování požadavků pro
zátěžové testování, apod.).
Rozdělení podle druhu podporovaných testů (nejčastěji z hlediska V modelu):
a) Prostředky pro akceptační testování
b) Prostředky pro integrační testy
c) Prostředky pro tetování vlastností jednotlivých programů nebo jejich částí (unit testy)
Rozdělení prostředků podle funkcí, které při testování zajišťují:
a) Prostředky, podporující provádění testovacích výpočtů
b) Prostředky, podporující organizaci procesu testování (termínové plánování testů,
přidělování testů testerům, sledování nápravy odhalených chyb, apod.).
Kritéria testů bývají dělena podle způsobu jejich přípravy. Lze je rozdělit na dvě
velké skupiny:
I.Skupina: Kritéria závislá na struktuře programu (White Box Testing)
a) Testování cest – testovací data mají zajistit provedení všech realizovatelných cest alespoň
jednou
b) Testování větví – testovací data mají zajistit provedení všech realizovatelných větví
programu
II.Kritéria závislá na problému bez přihlédnutí ke struktuře programu (Black Box Testing)
a) Testování souborem náhodných hodnot ze zvoleného oboru hodnot.
b) Testování reprezentanty stanovených tříd vstupních hodnot (kladné číslo, záporné číslo,
nula, určené číslo)
c) Testování podle tříd výstupních hodnot, kdy soubor testovacích dat musí navodit postupně
pro každou třídu výstupních hodnot alespoň jednoho reprezentanta.
Souhlasně s tímto rozdělením lze dělit i prostředky, podporující jednu nebo druhou
skupinu přístupu k testům a zajistit tak návaznost testovacích prostředků na testovací postupy.
Poznamenejme, že kritéria I. skupiny vycházejí ze struktury navrženého programu,
neumožňují ověřit, zda naprogramovaný algoritmus řeší bezchybně zadaný problém, i když se
prověří důkladně všechny části programu. Jejich předností je prověření všech částí programu.
Naopak kritéria II. skupiny ověřují správnost naprogramování zadaného algoritmu, ale
program může po testech vykázat chybu v důsledku průchodu větví, která nebyla při testech
prověřena.
Častým kritériem bývá i zaměření testovacích výpočtů. Proto se často můžeme setkat
s nástroji, které jsou speciálně určeny pro testování:
a) Web komponent
b) GUI
c) Síťových komunikačních protokolů
d) Atd.
Účelem uvedených klasifikačních kritérií pro rozdělení testovacích SW prostředků bylo
ukázat na jejich mnohotvárnost. Z uvedené klasifikace vyplývá, že jeden a tentýž
prostředek můžeme klasifikovat podle různých kritérií. Skutečnost, že se vezmou v potaz
různá kritéria rozdělení testovacích prostředků a stanoví se jejich přednosti a zápory, aby
se provedl vhodný výběr, má významný vliv na objem a kvalitu testů.
Samozřejmě je možno najít další, zde neuvedená, kritéria pro rozdělení testovacích SW
prostředků. Výše uvedená jsou však nejčastěji používaná.
Testovací prostředky jsou obvykle navrženy tak, že v sobě slučují několik různých
přístupů k testování podle uvedených klasifikačních hledisek.
Při volbě testovacích prostředků nesmíme brát ohled jen na volbu ČÍM se testuje, ale také
na volbu CO se testuje, PROČ se testuje a JAK se testuje.
---------------------------------------------------------------------------------------------------------------Poznámka ke stavu nabídky testovacích prostředků v ČR
V současné době programové testovací prostředky v širším rozsahu dodávají na náš trh
s podporou zejména firmy KOMIX, LBMS, UNICORN a IBM. Rozumí se prostředky
podporující platformu testování produktů především v operačních prostředích firmy
Microsoft. Pro jiná operační prostředí pracovních stanic firem SUN, HP, IBM, apod., pro
operační systém LINUX, UNIX a jiné operační systémy, dodávají specializované programové
prostředky jiné firmy (např. IBM, SUN, apod,).
S ohledem na dynamicky se měnící nabídku těchto prostředků je lépe si prohlédnout
aktuální informace na stránkách těchto firem, jak uvádějí obsahy firemních stránek těchto
firem na mezinárodní síti Internet.
Tato málo početná nabídka je reakcí na velmi malou poptávku po těchto produktech
v ČR. Objem prodaných prostředků, vyjádřený jak počtem prodaných kusů, tak objemem
finančních prostředků je velmi malý. Některé druhy prostředků nejsou na našem trhu
zastoupeny vůbec (např. generátory testovacích dat, prostředky pro testování real-time
aplikací, apod.) Vyplývá to z přístupu českých firem k problematice jakosti programů a tím i
k testování programů.
-----------------------------------------------------------------------------------------------------------------
Pro testování je velmi důležité, jaký metodický přístup zvolíme k přípravě testovacích
dat. Kritéria, podle kterých připravujeme testy, lze rozdělit na na dvě velké skupiny:
I.Skupina: Kritéria závislá na struktuře programu (White Box Testing)
II.Kritéria závislá na problému bez přihlédnutí ke struktuře programu (Black
Box Testing)
Každá skupina má několik podskupin.
White Box - testování cest. Testovací data mají zajistit provedení všech realizovatelných cest
alespoň jednou. Pro naznačený příklad to znamená připravit testy které by zajistily průchod
uvedenými bloky A,B,C,D. Tedy dva testovací výpočty :jeden A,C, druhý B,D. Nebo jiné
dva testovací výpočty A,D a druhý B,C. Postačí vždy jen jedna dvojice.
A
C
B
D
White Box Testing - testování větví, kdy testovací data mají zajistit provedení všech
realizovatelných větví programu. V níže uvedeném příkladu to znamená realizovat testovací
výpočty, pro které připravíme testovací dat tak, abychom prošli postupně větve s bloky A-C,
B-D, A-D, B-C:
A
C
B
D
Toto kritérium je tedy přísnější a i na takovém jednoduchém příkladu požaduje
dvojnásobný počet testovacích dat a výpočtů.
Druhou skupinu tvoří kritéria závislá na problému bez přihlédnutí ke struktuře programu
Black Box Testing, kdy na program pohlížíme jako na „černou skříňku“ . Tento přístup byl
odvozen ze stejnojmenného kybernetického postupu, kdy se systém zkoumá na základě
vstupu a výstupu:
Black Box Testing - Testování souborem náhodných hodnot ze zvoleného oboru hodnot, kdy
generujeme soubor nahodilých testovacích hodnot s respektování jen základních pravidel
např. typy proměnných, rozsah proměnných, určitá prvotní kombinace znaků nebo
hodnot, apod.
Black Box Testing - Testování reprezentanty stanovených tříd vstupních hodnot (kladné číslo,
záporné číslo, nula, určité vybrané číslo)
Black Box Testing - Testování podle tříd výstupních hodnot, kdy soubor testovacích dat musí
navodit postupně pro každou třídu výstupních hodnot alespoň jednoho reprezentanta. Např,
pro test programu kvadratické rovnice pro obor reálných čísel by vstupní konstanty měly
navodit dva reálné různé kořeny, dva stejné kořeny, singulární kořen a případ, kdy rovnice
nemá v oboru reálných čísel řešení.
V souvislosti s testováním programů se často používá veličina „koeficient pokrytí“
Kp. Ten určitým způsobem charakterizuje, jaká část programu byla testy prověřena. Např.
Kp = Počet testovaných cest / Počet možných cest v programu
Nebo
Kp = Počet testovaných větví / Počet všech možných větví v programu
Případně je nutno uvést, co přesně uváděný koeficient charakterizuje.
Mnohdy se koeficient vynásobí 100 a uvádí v procentech (%)
Připomeňme, že problematika kvality softwaru z hlediska testování byla motivací pro
vznik V- modelu (viz konceptuální schémata tvorby software). Ten rozdělil skupiny testů na
akceptační testy, funkční testy, Integrační testy a testy programových jednotek (Unit Tests).
V-model
Plán akceptačních testů
Požadavky
Funkce (návrh)
Systém (návrh)
Akceptační testy
Plán funkčních testů
Plán integračních testů
Def. programu
Plán testu
pro testování
programu
Funkční testy
Integrační testy
Test programu
Program (kód)
6.4 Aplikace Ishikawových diagramů v jakosti software
.Chceme-li dosáhnout jakostního programového vybavení, musíme umět, mimo jiné, stanovit
podmínky, které jsou předpokladem žádaného jakostního software.
Na tento problém se můžeme dívat i z jiného pohledu (backtracking - zpětné sledování).
Známe-li důsledek, např. software je nejakostní, pátráme po příčinách nejakosti.
Nemůžeme úspěšně zajišťovat a řídit proces tvorby jakostního software, jestliže na takové
otázky neumíme dát správnou odpověď.
V procesu zdokonalování jakosti je velmi častým případem, že při analýze spíše objevíme
důsledek (účinek), ze kterého usuzujeme na vznik, či existenci nějakého procesu, přes který se
příčiny transformují na důsledky existencí procesu vyvolané.
Tento proces poznání však mnohdy není nijak jednoduchý a má mnohá úskalí. Upozornil na
ně již starořecký filosof Platón. Platón již ve své starověké filosofické škole učil žáky, jak je
mnohdy těžké získat příslušné poznatky a zvolit správné postupy poznávání, které by nám
umožnily účinně řešit složité problémy. Výsledky jeho úvah vyústily v poznání, že člověk si v
takovém případě musí velmi pečlivě zvolit a stanovit vhodnou metodu, která by mu umožnila,
získat potřebné poznatky.
Jednou z metod, kterou můžeme při řešení problémů jakosti software využít je teorie
kauzality.
Teorie kauzality vychází z přímého vztahu mezi příčinou a účinkem (důsledkem). Odhaluje ,
proč nějaký proces v prostředí vzniká, a zkoumá důsledky (účinky), které jeho existence
vyvolá.
Z různých technik, které kauzální teorie využívá si všimněme P-D diagramů (diagram Příčina
- Důsledek).
Ishikawovy diagramy
V oblasti jakosti se P-D diagramům též říká Ishikawovy diagramy podle prof. Kaoru
Ishikawy, který je používal v procesech zdokonalování systémů řízení jakosti. Někdy se těmto
diagramům říká též diagram typu "rybí kostra".
Klasický vzhled znázorňuje níže uvedený obrázek:
Příčina
Příčina
P1
P2
Příčinný faktor
P21
Příčina
Důsledek
P5
Příčinný faktor
P41
Příčina
Příčina
P3
P4
Klasický P-D diagram může být různým způsobem modifikován:
- zachycujme jen příčiny a důsledek, neuvádíme příčinné faktory
- příčiny můžeme detailněji klasifikovat.
Diagram P-D nám graficky nahrazuje složitější případ implikace, a to případ, kdy implikace
má více konsekventů spojených konjunkcemi:
x1 ^ x2 ^ x3 ^ ....^ xn => y
Připomeňme tabulku jednoduché implikace ve výrokové logice:
(x je atecedenta implikace, y je konsekventa implikace)
x
y
x=>y
-------------------------true
true
true
true
false
false
false true
true
false false
true
abychom upozornili na třetí řádek tabulky, který představuje také pravdivou implikaci.
Sestavování diagramu
Diagram sestavujeme v osmi krocích, jestliže je stanoven důsledek, pro který má být
konstruován:
1. Vyhledáme příčiny, které způsobují analyzovaný důsledek, a rozdělíme je na pozitivní a
negativní.
2. Stanovujeme příčinné faktory k vyhledávaným příčinám
3. Klasifikace (třídění) příčin do vhodných skupin
4. Prioritizace příčin
Stanovení důležitosti příčin je nutné vzhledem ke skutečnosti, že příčin může být velké
množství, ale ty, které výrazně ovlivňují proces, je obvykle malé, spočitatelné množství - cca
4 až 7 (viz Paretova analýza)
5. Analýza nejdůležitějších příčin
6. Zajištění dostupných faktů pro srovnání s reálnými fakty
7. Verifikace získaným poznatků
8. Zajištění posílení positivních faktorů a zeslabení negativních faktorů tak, aby výsledný
efekt byl co největší.
Sestavování diagramu se doporučuje provádět v týmu, který by měl být sestaven ze
specialistů, jenž mohou zajistit co nejlepší sestavení P-D diagramu.
Přínosy a využívání diagramů
- Jsou jednoduše pochopitelné a použitelné
- Umožňují specifikovat příčiny problémů
- Zajišťují systémový přístup k řešení problémů
- Pomáhají dokumentovat myšlenky a závěry
- Jsou velmi názorné
- Jejich tvorbu je možno snadno podporovat počítačem
- Dávají techniku pro řešení kauzálních závislostí
- Umožňují využít metod týmové práce a skupinového
řešení problémů
- Jsou vodítkem pro diskuze a výměnu názorů.
Tyto výhody způsobily, že se P-D diagramy používají i mimo oblast jakosti např. v
komponentě Enterprise Performance Manager produktu BAAN IV Orgware pro stanovení
indikátorů výkonnosti hospodaření firmy.
Ishikawovy diagramy jsou velmi praktickou pomůckou pro hledání podmínek jakosti a příčin
nejakosti software
Na druhé straně je potřeba upozornit na skutečnost, že tento přístup preferuje "statický
pohled na kvalitu". Pokud bychom byly postaveni před problém dynamicky se měnících a
dynamicky se ovlivňujících procesů, měli bychom spíše využít technik modelování systémové
dynamiky
Lidé
Prostředí
Programy
Jakost SW
Postupy
Prostředky
Základní Ishikawův diagram jakosti SW
T esto v á n í
so ftw a re
J a k o st
P r a co v n íc i
v S o ftw a r e
E n g in e erin g
S p e cifik a ce
J a ko st
so ftw a re
so ftw a r e
V ý v o jo v é
M e to d y
p r o stře d ky
návrhu
so ftw a re
O r g a n iz a c e
p r o c esu
tv o rb y so ftw a re
Ish ik aw ů v d ia g ra m p r o ja k o st so ftw a re – r o zšíř en á v er z e
Prostředky pro
Metody a postupy
testování
testování
Programy
Testování
Způsob
Plán
specifikace
testů
software
Způsob
vyhodnocování
testů
Ishikawův diagram pro činitel „Testování“
Specialisté
Analytici
Programátoři
Zákazníci
Pracovníci
Pracovníci
Pomocný
marketingu
personál
Vedoucí
pracovníci
Ishikawův diagram pro činitel „Pracovníci“
Programovací
jazyky
Operační
Kompilátory
systémy
Ostatní
podpůrné
prostředky
Vývojové
prostředky
Sledovací
Knihovní
prostředky
prostředky
Konfigurační
prostředky
Ishikawův diagram pro činitel „Vývojové prostředky“
6.5. Zajišťování jakosti SW metodou FMEA
Metoda FMEA ( z anglického Failrue Mode and Effect Analysis ) - představuje
analýzu projevů, důsledku a kritičnosti poruch. Poruchou je v softwarovém inženýrství
míněno např. jakýkoliv nefunkční projev programovaných softwarových aplikací.
Metoda FMEA byla původně navržena pro oblast strojírenských konstrukcí
v automobilovém a leteckém průmyslu.
Protože problematika návrhu software je v některých skutečnostech odlišná od
klasického strojního konstruování, musíme pokusit načrtnout obecný a rámcový koncept , pro
použití metody FMEA při vývoji, používání, aktualizaci a vůbec při práci v softwarovém
inženýrství, s určitými odlišnostmi
Výsledkem použití metody FMEA -SW ( softwarové inženýrství ) software, by měl
být software, který splňuje požadavky vysoké jakosti podle ISO 9126.
V rozlišují dva základní druhy FMEA:
1 FMEA - P varianta pro již vyvinutý a funkční, konkrétní program (PRODUCT)
2 FMEA - D varianta pro časový úsek vývoje programu (DESIGN)
Obecné výhody metody FMEA:
1. Pomáhá v počáteční fázi projektu s vysokou spolehlivostí a vysokou bezpečností při
výběru různých možností návrhu.
2. Zajišťuje, že budou vzaty v úvahu všechny případné chyby a jejich vliv na správnou
funkci vyvíjeného produktu.
3. Uvádí všechny možné chyby a identifikuje relativní předpokládanou velikost jejich
účinku.
4. Je základem pro testování během vývoje a konečného hodnocené produktu.
5. Vytváří prvotní kritéria pro všechny fáze ( návrh, implementace, testování, přejímání,
provoz, údržba a servis ).
6. Poskytuje dokumentaci pro analýzu chyb v praxi a bere v úvahu možné změny v průběhu
vývoje projektu.
7. Vytváří podklady pro organizaci a pozdější usnadnění změnového řízení
8. Způsobuje, že se uvažuje o prevenci selhání návrhového procesu a produktu, již v
počátečních fázích vývoje produktu.
V podstatě se použitím této metody zjistilo, že funguje velice efektivně a její použití se v
konstrukčních oblastech velice rozšířilo a používáním se při výrobě také jistě ušetří
finanční prostředky. A i když byla původně vyvinuta v rámci kosmického programu pro
kosmický výzkum a osvědčila se natolik, že její rozšíření proběhlo velice rychle (
elektrotechnický průmysl, letectví, automobilový a zbrojní průmysl atd. Např. firma
FORD tuto metodu dodnes používá při návrhu všech modelů automobilů této společnosti).
Jedním ze základních předpokladů FMEA je týmová práce. Tato metoda sama o sobě
velice efektivním způsobem využívá předností týmové práce.
Pro zajištění činností, které tato metoda vyžaduje, je zapotřebí sestavit tým odborníků,
ze všech potřebných oblastí, aby se zajistil komplexní a systémový přístup k řešeným
problémům.
Následující rozdělení se již týká metody FMEA - SW.
Pro modifikaci FMEA -P jsou to: ( specialisté, kteří se vyznají v konkrétních
částech programového produktu )
•
•
•
•
•
•
specialisté, reprezentující požadavky zákazníka
specialisté v oblasti marketingu
specialisté na jednotlivé aplikační moduly
zástupci jednotlivých systémových komponent ( třeba operační systém,databázový
systém, síťový systém,standardní a servisní programy, vývojová prostředí, včetně
použitého kompilátoru prog. jazyka )
reprezentanti dodavatelů jednotlivých komponent ( např. technických )
popřípadě další specialisté, vycházející ze zvláštností a odchylek od standardů již v
konkrétních případech.
Pro modifikaci FMEA - D jsou to: ( Specialisté podílející se na jednotlivých fázích
projektu )
• zástupci marketingu firmy
• zástupci analytiků
• zástupci systémových programátorů
• zástupci aplikačních programátorů
• zástupci dodavatelů jednotlivých technických komponent
• specialisté pro testování
• zástupci instalačního servisu
• další dílčí specialisté dle potřeby
Týmy by měly spolupracovat podle zásad a metod týmové práce. Zde je důležité
upozornit na to, že v České Republice tyto zásady a metody nejsou příliš známy, což
způsobuje, že týmy bývají sestavovány nevhodně, nemají vytvořeny dostačující podmínky pro
svoji práci a nepoužívají také nejlepších metod, které vedou ke správnému řešení co
nejefektivněji.
Proto se doporučuje zvolit další odborníky, kteří budou týmy směrovat správným
směrem, na začátku jim zvolí správnou metodu a během vývoje a testovaní budou činnosti
jednotlivých týmů koordinovat, kontrolovat a hlídat průběhy jednotlivých týmových činností.
V případě FMEA - D je možnost vzniku vad především v oblastech implementací, návrhů a
samotné dodávky. Právě proto je důležité dbát právě na:
• použité vývojové prostředí
• na kompilační a testovací prostředky
• zvolená metoda návrhu softwaru
• správná volba technických prostředků
• jednotliví elementární pracovníci, podílející se na projektu
• atd.
Co se týká FMEA - P, zde se jedná především o jednotlivé části, již hotového projektu a to
včetně jiných k funkčnosti potřebných součástí. Např. jiné nakoupené programy, základní
operační software…..
Na oba dva případy můžeme také použít seznam, který získáme použitím tzv.
Ishikawových ( kauzálních ) diagramů
Každá jednotlivá část má své specifikované zásady a postupy. S každým postupem jsou
spojeny některé specifické pojmy, které jsou předem definovány. Je také potřeba se s nimi
důkladně seznámit.
Zásady a postupy metody FMEA - P
Provádí se v části projektu, kdy samotný programový produkt není ještě hotový, ale je
ve stádiu navržení cílů a určení funkcí, které by měl vykonávat, není zde možnost opřít se o
výsledky a zkušenosti s již hotovým produktem. Proto se snažíme určit všechny potenciální
poruchy, vzniklé vynecháním, nebo selháním nějaké funkční části a jejich důsledky. Dále je
možnost využít zkušeností s poruchami jiných, avšak podobných produktů, od kterých máme
nějaké záznamy o spolehlivosti.
Musíme postupovat následovně:
(a) Každou dílčí část musíme uvažovat jako součást celého kompaktního systému. ( přitom
nestačí, omezíme-li se na první vyšší systém, protože porucha se může projevit v
kterémkoliv jiném )
(b) K analýze jednotlivých systémů postupujeme v pořadí dle důležitosti pro daný
programový produkt. To je od nejdůležitějších k méně důležitým.
Zásady a postupy metody FMEA - D
Zde se orientujeme na rozbor možných poruch v procesu návrhu, které následně
mohou znamenat, že výsledný produkt bude obsahovat chyby.
(a) Vždy se zabýváme pouze jedním souvislým řetězcem činností, jehož výsledkem je určitá
část prog. produktu. Protože každý takový postup je součástí nějakého jiného,
nadřazeného postupu, uvádíme tyto souvislosti s cílem, podrobit analýze i tento proces.
(b) Postupujeme do nejsložitějších postupů a asociací k jednodušším a zároveň zvažujeme i
důležitost a cenu částí produktu, jež jsou výstupem z procesu.
(c) Opět můžeme využít poznatky, které jsme získali z minulosti ze zkušeností s jiným
podobným produktem, nebo procesem.
FMEA D & P
-
Celý postup je dán přesnými a podrobnými popisy jednotlivých
činností, jež je potřeba vykonat. Základem jsou formuláře, do kterých
se zapisuje celý průběh metody FMEA.
Pro tyto formuláře samozřejmě platí také nějaké postupy a pravidla.
Měly by obsahovat:
1) Globální informace a údaje o konkrétním produktu. ( nebo jen nějaké části, nebo jiném
komponentu ), dále zde pak můžou být informace o procesu návrhu, kde jsou popsány
jednotlivé postupy návrhových činností.
2) Charakteristiku, v jakém stádiu se konečný produkt nachází v současné době.
3) Charakteristiku cílového stavu. Stavu, do kterého musíme produkt dostat, aby byl plně
funkční.
4) Popis činností, které je třeba ještě vykonat, abychom produkt do cílového stavu popsaného
v bodu 3 dostali.
5) Rozdělení zodpovědnosti, za tyto jednotlivé dílčí činnosti.
6) Další pomocné údaje. Organizační, koordinační, atd.
Ve formuláři pro software, není možné všechny potřebné prvky formuláře dále
konkretizovat, protože se údaje liší pro každý software a samozřejmě také pro každou firmu
budou formuláře obsahovat nějaké rozdíly ( např. v závislosti na týmových zvyklostech, počtu
zaměstnanců, finančních možnostech….. ).
Proto si každá firma obvykle vytvoří vlastní formulář, s vlastními přizpůsobenými pokyny
a požadavky, podle kterého později postupuje.
7 Modely jakosti procesů tvorby software
7.1 Model EFQM
Problematika dosahování jakosti vyžaduje, aby si firmy vytvořily určitý model, který
charakterizuje jednak způsob hodnocení procesů, které řídí jakost, jednak ukazují, jak se
dosahuje vyšší jakosti.
Aplikace revidované řady norem ISO 9000:2000 u nás zvýšila zájem i o využití
modelu jakosti EFQM, který je u nás již delší dobu znám. Rada ČR pro jakost se Sdružením
pro Cenu ČR za jakost využívá při hodnocení uchazečů právě inovovaný model EFQM,
popsaný u nás prof.J.Nenadálem z VŠB-TU Ostrava
Model má 9 hlavních kritérií a 32 dílčích kritérií.
Evropská organizace pro kvalitu ( www. efqm. org) rozeznává pět stupňů:
Úroveň
Označení
1
Committed to Excellence
2
3
4
5
Recognised Excellence
EQA Finalist
EQA Prizewinner
EQA Winter
V oblasti softwarových firem se zatím model EFQM užívá spíše zřídka. Je to zřejmě
způsobeno skutečností, že softwarové inženýrství již dříve vytvořilo jiné modely jakosti
tvorby software, které se z USA rozšířily i do Evropy.
Přípěvek stručně charakterizuje dva nejrozšířenější modely jakosti tvorby software:
• Software Capability Maturity Model, vytvořený Software Engineering
Institute Carnegie Mellon University of Pitsburg (dále jen CMM)
• Model SPICE definovaný normou ISO 15504 (dále jen SPICE)
Oba modely vycházejí ze stejné filosofie jakosti, kterou je potřeba zajistit firemními procesy. Srovnání
přístupů norem ISO 9000 a modelu CMM z hlediska softwarového inženýrství zpracovala RNDr. Kreslíková
z Fakulty informačních technologií VUT Brno. Vznik modelu CMM a modelu SPICE byl reakcí na
skutečnost, že programové vybavení pro číslicové počítače má některé specifické vlastnosti, které ho odlišují
od běžných výrobků. Na tuto skutečnost reagoval i původní soubor norem ISO 9000, který obsahoval
samostatný titul pro oblast software ISO 9003. Uveďme alespoň nejdůležitější specifické znaky software:
•
•
•
•
•
Software je nehmotné zboží.
Kvalita software je obtížně měřitelná.
Jeho tvorba je velmi komplikovaná..
Software je velmi složitý produkt.
Je velmi obtížné specifikovat požadavky na software z hlediska potřeb
zákazníka ( toto analyzoval ing.Merunka ze ČZU PEF KII )
Je možno říci, že právě tyto a další problémy (např. překotný rozvoj počítačů,
specifický přístup programátorů k otázkám jakosti, neprůhlednost tvorby software z pohledu
nespecializovaných zákazníků, a další) způsobily, že problematika jakosti software se teprve
až nyní stává velmi naléhavou. Proto před softwarovými firmami stojí naléhavý úkol
podstatného zvýšení jakosti tvorby programového vybaveni. Platí to však nejen pro
softwarové firmy. Aplikace norem ISO 9000:2000 proniká i do jiných netradičních oblastí.
Např. první z vysokých škol v ČR získala certifikát jakosti podle norem ISO VŠB-TU
Ostrava, Fakulta elektrotechniky a informatiky.
Komparativní srovnání různých modelů jakosti tvorby software umožní softwarovým
firmám se lépe orientovat v této problematice a vybrat si pro vlastní systémy řízení jakosti
nejvhodnější postupy.
7.2 Model CMM
Model vznikl z potřeby hodnotit pro ministerstvo obrany USA softwarové firmy při
výběrových řízeních na státní zakázky na počátku osmdesátých let. Model byl vytvořen
pracovníky Institutu softwarového inženýrství Carnegie Mellon univerzity v Pitsburgu. Vžil
se pod označením CMM (Capability Maturity Model) nebo také pod označením SW-CMM,
protože později začaly vznikat jeho modifikace pro různé jiné oblasti (PM-CMM pro
projektové řízení a další).
Model rozděluje firemní procesy v softwarových firmách do pěti úrovní:
•
•
•
•
Úroveň 1 – Initial. Na této úrovni dominují nahodilé - ad hoc - procesy.
Software je vytvářen bez firemních pravidel chaoticky, takže se jeho
tvorba často dostává do kritických situací. Dosažený úspěch ve vývoji
software je důsledkem šťastné náhody a závisí na individuálních
schopnostech a znalostech programátorů. Dohodnuté termíny nejsou
většinou dodržovány a ukončení vývoje je dosahováno nesmírným
heroickým úsilím na konci projektu. Celkové náklady na projekt jsou
sečteny po ukončení vývoje a zvažují se jako důsledek vývoje a nutných
výdajů. O kvalitě software se sice hovoří, ale nijak se nezajišťuje. Každý
spoléhá na toho druhého, že on kvalitu zajistí.
Úroveň 2 – Repeatable. Opakovaně se dosahuje dobrých výsledků. Firma
využívá základních postupů projektového řízení, ale z projektu na projekt
se přenášejí jen některé úspěšné prvky řízení. Nicméně intuitivně zaběhané
procesy a povědomí, že je potřeba pracovat kvalitně, vytvářejí dost stabilní
prostředí pro udržení přijatelné úrovně jakosti softwarových produktů.
Úroveň 3 – Defined. Software je vyvíjen podle předem stanoveného
postupu, metodicky a plánovitě s využitím pokročilého projektového
řízení, s cílem dosáhnout vypracování požadovaného software v čase,
s rozpočtovanými náklady a disponibilními zdroji. Provádí se pravidelné
vyhodnocování odchylek od plánu a přijímají se opatření ke krácení
termínů jednotlivých činností, aby software byl dodán v čas. O kvalitu
produktů a služeb se s ohledem na zákazníky explicitně usiluje, proto
kvalita softwaru je dodržována na velmi dobré úrovni a má tendenci
vykazovat určité zlepšování.
Úroveň 4 – Managed. Firma má všechny procesy jasně definovány a
stanoven pro ně postup měření, který vyhodnocuje jejich podíl a
efektivnost při tvorbě software. Zjištěné charakteristiky procesů jsou
postupně upravovány tak, aby se firma přizpůsobila měnícím se
•
podmínkám trhu, aniž by to mělo dopad na jakost vyvíjeného software,
jehož kvalitativní parametry jsou firmou cílevědomě stále zvyšovány a
dosahují vysoké úrovně.
Úroveň 5 – Optimizing. Neustálá zpětná vazba ovlivňuje následné
softwarové projekty tak, aby se firemní procesy neustále zlepšovaly a
dosahovaly předem definovaných, optimálních parametrů. Firma dosahuje
trvale špičkové jakosti aniž by náklady na kvalitu softwaru měly dopad na
hospodaření firmy. Naopak, garantovaná kvalita software usnadňuje jeho
prodej.
Model se poměrně rychle v průběhu osmdesátých let rozšířil a řada dalších univerzit a
firem rozpracovávala a propracovávala jeho dílčí aspekty.
Pro model byly definovány jednotlivé kroky, které umožňují postup na vyšší úroveň:
• Z 1. na 2. úroveň – disciplína, zodpovědnost, pořádek, cílevědomost
• Z 2. na 3. úroveň - standardizace, stálost a provázanost firemních procesů,
monitorování procesů
• Ze 3. na 4. úroveň - kritéria a měření procesů, řízení změn a využívání
predikce vývoje procesů
• Ze 4. na 5. úroveň – neustálé zlepšování procesů, vícekriteriální
optimalizace procesů, adaptabilnost procesů.
Rovněž pro jednotlivé úrovně byly definovány klíčové aspekty úspěchu ( Key Process Areas):
2.úroveň
Řízení požadavků
Řízení projektů
Řízení nákupu
komponent
Využívání metod
3.úroveň
Organizace firmy
Organizace a
definování procesů
Zvyšování znalostí
pracovníků
Integrace software
4.úroveň
Kvantifikace procesů
Řízení jakosti
software
Řízení konfigurace
Produkty CASE
5.úroveň
Prevence chyb
Řízení změn
Optimalizační metody
Business Process
Reengineering
Zajímavé je hodnocení podílu množství rizika, kvality a produktivity v jednotlivých
úrovních modelu:
1.úroveň
2.úroveň
3.úroveň
4.úroveň
5.úroveň
PRODUKTIVITA +
KVALITA
RIZIKO
Principy CMM jsou natolik obecné z hlediska zralosti firemních procesů, že se modelu
začalo používat v procesním inženýrství jako univerzálního modelu pro zdokonalování
firemních procesů. Dále byly vytvářeny další specializované modely pro jiné oblasti než
softwarové inženýrství. Byla již vzpomenuta varianta CMM pro oblast projektového řízení.
Další známou variantou je SW-TMM ( software testing maturity model).
Model CMM je nejvíce rozšířen v USA jak v oblasti státního departmentu, tak i
v soukromých firmách.
Existuje i řada kritických hlasů [4]. Nejčastěji se kritizuje, že model není založen na
teoretické bázi a existuje pro něj pouze vágní empirická podpora.
Na druhé straně řada autorů ukazuje na skutečnost, že mnoho softwarových firem
produkuje nekvalitní software způsobem, který nelze odhodnotit ani příslušností do první
úrovně. Tom Schorsch a jiní (Finkelstein ) definovali proto záporné úrovně modelu CMM,
které jsou komentovány v závěru kapitoly.
7.3 Model SPICE
Model byl vytvořen v rámci organizace ISO a jeho název ukazuje na cíl, který si autoři
stanovili: SPICE - Software Process Improvement and Capability dEtermination. Byl
vytvořen se záměrem poskytnout rámec pro hodnocení softwarových procesů, tedy se stejným
záměrem jako model CMM. Tak jako CMM ani norma ISO 15 504 není metodickým
návodem. Představuje souhrn určitých pohledů, podle kterých hodnotitel může posoudit
zralost organizace při dodávkách software.
Norma definuje referenční model prostřednictvím procesní dimenze a úrovně procesů.
Rozeznává tři kategorie procesů:
•
•
•
Proces vztahu zákazník-dodavatel
Procesy softwarového inženýrství
Podpůrné procesy
Pro každý proces je pak určena jedna z šesti úrovní procesu:
•
•
•
•
•
•
0 Incoplete process
1 Performed process
2 Managed process
3 Established process
4 Predictable process
5 Optimizing process
Norma popisuje také postup, jak provádět hodnocení, a dále definuje potřebné
znalosti a schopnosti asesorů, kteří hodnocení procesů provádějí. V samostatné sedmé části
popisuje norma proces, jak má organizace zlepšovat kvalitu firemních postupů, aby dosáhla
jejich vyšší úrovně.
Při tvorbě modelu SPICE se autoři inspirovali modelem CMM a snažili se zdokonalit
a doplnit to, co mu bylo jeho kritiky vytýkáno.
Na rozdíl od CMM, který byl vytvořen na univerzitní půdě, SPICE je podložen
schválenou oficiální mezinárodní normou, která navazuje na normu ISO 12 207 (životní fáze
tvory software).
Model CMM byl vytvořen dříve a řada firem, zejména v USA, mu dává přednost před
modelem SPICE.
Uvádí se, že hodnocení podle SPICE je pro organizaci nákladnější než podle postupu
CMM.
Určitým problémem použití modelu SPICE také je, že není snadno a běžně dostupný.
Je k dispozici pouze za příslušné poplatky jako ostatní normy ISO. Model CMM je volně
dostupný prostřednictvím mnoha www stránek na síti Internet.
7.4 Závěr
Jak CMM, tak SPICE popisuji procesy v kontextu tvorby software, což je jejich momentální přednost. Oba
modely podporují instituce a firmy, které se zabývají softwarovým inženýrstvím.
CMM i SPICE modely definují dosaženou vyspělost firemních procesů, zatímco EFQM poskytuje souhrnné
bodové hodnocení procesní úrovně firmy.
CMM i SPICE preferují externí hodnocení, Model EFQM využívá interní samohodnocení.
EFQM model je zatím příliš obecný pro softwarové firmy a instituce kolem softwarového inženýrství ho
zatím neakceptovaly.
Čeká se na konkretizaci EFQM do podmínek tvorby software, aby tento model zaujal i softwarové firmy.
Je nutno konstatovat, že v oblasti tvorby software ještě celá řada softwarových firem nepovažuje jakost za
nutnou součást svých firemních procesů. Proto model CMM byl doplněn o další záporné úrovně, které jsou
charakterizovány následovně:
• Úroveň 0 (negligent) - Nedbalost, nepozornost, řada chybně navržených
procesů a špatná až chaotická organizace firmy způsobuje, že vytvořený
software má velký počet chyb, které se ani nestačí identifikovat, natož opravit.
Termíny se nedaří plnit, plánované náklady se překračují, často se žádné
plánování nákladů ani neprovádí. Práce, která je konec konců jaksi provedena,
je nakonec zmařena v důsledku různých jiných nedostatků. Často vedení irmy
i pracovníci spoléhají a očekávají nějaká zázračná řešení, která způsobí
okamžité divy. Produkty se firmě od zákazníků neustále vracejí, aby byly
opraveny a dopracovány, přičemž řada zákazníků žádá slevy na dodané
produkty.
• Úroveň –1 (obstructive) – Řada kontraproduktivních opatření ve firmě a
protichůdných procesů téměř znemožňuje vytvořit kvalitní software. Často se
objevují odmítavá stanoviska k zavádění takových věcí jako: projektové řízení,
řízení jakosti, uznávané metody tvorby software, produkty CASE apod.,
s odůvodněním, že se jedná jen o byrokratická, administrativní opatření, která
komplikují programátorům a dalším zaměstnancům práci. Jedna reorganizace
stíhá druhou, stejně zmatenou jako byla ta předchozí. Kvalita software je tak
špatná, že zákazníci neustále produkty reklamují, firmu penalizují a postupně
přecházejí k jiným firmám.
• Úroveň –2 (contemptuous) – Ve firmě pracovníci přehlížejí jakákoliv
doporučení a zásady softwarového inženýrství. Programování je prohlašováno
za umění, takže jakékoliv snahy o zavádění pořádku a systému do vývoje
software je označováno jako útok na uměleckou tvořivost a svobodu. Nejsou
vedeny žádné údaje o postupu vývoje softwaru, často jsou takové údaje
záměrně ničeny. Zákazníkům není nasloucháno a jsou naopak přesvědčováni,
že produkty, které doslaly jsou ty nejlepší, a jejich nefunkčnost je zapříčiněna
vlastní nízkou úrovní znalostí uživatelů v používání počítačů.
• Úroveň –3 (undermining) – Samorostlé názory pracovníků firmy na tvorbu
software jsou zcela mimo chápání normálních lidí a podkopávají důvěru
veřejnosti v softwarové inženýrství.
Zatím poměrně málo softwarových firem vlastní certifikát podle řady norem ISO 9000:2000 svého systému
řízení jakosti.
Přitom naléhavost problematiky kvality software je dnes v centru pozornosti zejména
ze tří důvodů:
•
•
•
Software se stalo velmi rozšířeným zbožím a zákazníci by měli být chráněni před
nekvalitními produkty.
Do software se investují obrovské finanční částky a z celospolečenského i tržního
hlediska je potřeba zajistit jejich efektivní zhodnocení.
Stále více se používá software v aplikacích pro automatické řízení procesů, kde
chyby v programovém vybavení mohou mít velké, často katastrofální důsledky
(řízení jaderných reaktorů, řízení zdravotnických zařízení, navigace letadel,
apod.).
To vše nutí softwarové firmy zamýšlet se nad tím, jak navrhnout a realizovat ve svých
týmech procesy tvorby software tak, výsledný programový produkt byl dodán zákazníkovi
v požadované kvalitě. Této problematice se věnuje i proces mezinárodní normalizace ISO..
kde má ČR svého zástupce přímo v technické komisi, která tuto problematiku řečí
(prof.J.Vaníček, ČZU Praha – PeF).
Samostatným problémem je objem práce, který je potřeba věnovat na testování a tím
pro zajištění jakosti. Jeho řešení může být spatřováno v možnosti využít automatizace pro
racionalizaci
takových
činností.
Možnost
tohoto
řešení
v podmínkách
objektově
orientovaného paradigmatu programování popsal R.Nagy pracovník německé firmy
MicroTOOL) , který se jakosti software již dlouhodobě věnuje.
Nároky na kvalitu software aplikací, které zajišťují řízení v reálném čase, potvrzuje
také skutečnost, že se tato problematika objevuje v časopisech, které se zabývají automatizací
(AUTOMA, Automatizace), a že Česká společnost pro jakost uspořádala seminář, speciálně
věnovaný problematice jakosti software podle ISO 15 504 v automobilovém průmyslu.
Správná volba modelu pro hodnocení jakosti firemních procesů je jedním ze
základních předpokladů, jak kvalitní tvorby programů dosáhnout.
8 Provozování automatizovaných informačních a řídicích systémů
8.1. Provoz informačních a řídicích systémů
Obecné předpoklady optimálního provozu AIS
Optimální využívání instalovaného informačního systému vyžaduje, aby jeho provoz byl
řádně organizačně připraven, zorganizován a aby přijatá provozní opatření byla v plném
rozsahu dodržována. Samotná existence drahé a výkonné výpočetní techniky, zakoupení
rozsáhlého, drahého a špičkového programového vybavení, to vše vytváří pouze předpoklady
pro bezproblémový provoz.
Základ pro plynulý provoz tvoří:
- Řádné vyškolení obsluhy, tj. pracovníků, kteří budou informační systém ve firmě využívat.
jedná se nejen o vyškolení pracovníků v oblasti obsluhy technických prostředků a v oblasti
používaných programů, ale také ve způsobu moderního chápání a využívání současných
informačních technologií k získávání informací pro řízení.
- Jasné vymezení cílů, které chce vedení firmy prostřednictvím informačního systému ve
vztahu k podpoře rozhodovacích procesů ve firmě dosáhnout. Předpokládá to seznámit
pracovníky s informační strategií firmy a plánem na rozvoj informačního systému firmy.
- Vymezení zodpovědnosti za jakost údajů, které jsou ukládány na paměťová média
- Určení pro jednotlivé pracovníky, které údaje mohou měnit a ke kterým údajům mají
oprávněný přístup.
- Zajištění správné synchronizace jednotlivých činností, které pracovníci vykonávají za
pomocí počítače a využívají k nim společně sdílená data.
- Rozdělení zodpovědnosti za různé činnosti, které se vyskytují při užívání tj. při provozu,
údržbě a inovaci automatizovaného informačního systému (hlášení chyb, evidování nákladů a
plánování nákladů, shromažďování návrhu na zlepšení AIS, apod.).
- Vytvoření vhodných opatření, bezpečnosti AIS, k zamezení úniku a ztráty důležitých údajů.
Příslušné směrnice, prováděcí nařízení a instrukce, musí tvořit dokonale propracovaný
a udržovaný systém. Je výhodou, když podstatná část této provozní dokumentace
informačního systému je realizována v elektronické formě.
Dnes jsou v této oblasti již k dispozici dokonale propracované dokumenty, které řeší
tuto problematiku na velmi dokonalé úrovni - např. ITIL (viz dále).
8.2 Monitorování chodu AIS
Pro zabezpečení správného chodu informačního systému, pro možnost vyhodnocení
jeho stavu a pro možnost optimalizace jeho činnosti je nutné zajistit pravidelné sledování jeho
provozu a pravidelně získané informace vyhodnocovat. Sběr a vyhodnocování informací musí
být prováděno systematicky a systémově. Musí být určeno kdo a jaké informace bude
sledovat, jak, jakým způsobem, kdo je bude vyhodnocovat a kam se budou hlásit výsledky
hodnocení k provedení příslušných opatření. Základem je určení požadovaných provozních
parametrů informačního systémů případně trendů jejich zlepšování.
Jedná se sledování:
- doby odezvy pro jednotlivá pracoviště a pro jednotlivé činnosti (doba odezvy / response
time je doba, která uplyne mezi posledním znakem požadavku a prvním znakem odpovědi
počítače)
- rychlosti zaplňování diskové kapacity a evidence zbývající volné kapacity disků
- statistiky křížových vazeb na disku nebo obsazení oblastí přetečení dat na discích
- propustnosti a vytíženosti komunikačních linek
- způsobilosti výkonu požadovaných funkcí
- detekce podezřelých přístupů k datům, detekce porušování hesel, apod. za účelem zjištění
možného úniku informací
- využívání různých běžných, zejména však unikátních zařízení, informačního systému
- hlášení evidovaných poruch pro vyhodnocení spolehlivosti jednotlivých zařízení
- nákladů na provoz
- podaných návrhů na zlepšení informačního systému.
Zcela zvláštní pozornost vyžaduje zaznamenávání upozornění na možné chyby v
programovém vybavení včetně evidence jejich řešení a dále návrhy na zlepšení nebo rozšíření
funkcí informačního systému.
Pro monitorování chodu informačního systému je potřeba využít specializovaných
programových prostředků, které jsou dodávány firmami pro účely správy sítí, operačních
systémů, správy databází a správy aplikací (CoNet od firmy Compuware, NetMetrix
Enterprise Manager od Hewlett-Packard, Optivity Enterprise od Bay Networks, Polycenter od
DEC, apod.).
8.3 Audit AIS
Provoz informačního systému by měl být vedením firmy v pravidelných intervalech
podroben důkladnému posouzení. Prostředkem k takovému posouzení může být audit.
Účelem auditu je poskytnout zadavateli auditu výsledek posouzení průběhu nebo stavu
určitého procesu. Zadavatel (ředitel firmy, vedoucí odboru, atd.) obvykle vymezuje cíle
auditu, předmět auditu, rozsah auditu a jeho časový rozsah. Zároveň jmenuje i
auditorský tým, který audit provede.
Auditorský tým nejprve zpracuje plán auditu a metodický postup auditu.
Následuje provedení auditu a zpracování auditorské zprávy, která je pak projednána
se zadavatelem.
Auditorský tým, může být tvořen pracovníky firmy, pak hovoříme o vnitřním auditu.
Pokud audit provede tým externích pracovníků specializované auditorské firmy, pak se jedná
o nezávislý audit.
Význam a důležitost auditu závisí od způsobu provedení auditu, zkušenosti a
důvěryhodnosti osob, které audit provádějí. Proto je výhodné se obrátit na specializované
auditorské firmy, které jsou schopni zajisti vysoce profesionální provedení auditu, a jejichž
výsledné zprávy mají vysoký stupeň důvěryhodnosti.
V oblasti informačních systémů bývá běžné provádět:
- audit bezpečnosti informačního systému
- audit jakosti informačního systému
- audit ověřující soulad automatizovaného zpracování účetní agendy s platnými předpisy
- atd.
Pokud v průběhu auditu můžeme některé veličiny přesně změřit a vyhodnotit, může
být výsledkem také zpracování atestu, což je protokol, který uvádí a potvrzuje naměřené
skutečnosti (atest materiálového složení oceli, atest změření vydávaného hluku určitým
strojem, atest o naměření podlimitního množství vypouštěných škodlivin z výfuku
automobilového motoru). je-li pro takové měření vydaný předpis, pak atest obvykle uvádí,
identifikaci takového předpisu, podle nějž bylo postupováno a informaci o tom, že vydavatel
atestu získal speciální oprávnění takový atest vydávat. V souvislosti s informačními systémy
to mohou být atesty jakosti komunikačních linek, atesty nežádoucího záření katodových
displejů, hlučnosti tiskáren, atest, že všechny používané technické prostředky splňují normy
bezpečnosti proti úrazu elektrickým proudem, apod.
apod.
8.4 Údržba AIS
Vymezení pojmu "Údržba AIS"
Údržbou automatizovaného informačního systému rozumíme soubor těch činností,
které mají zajistit provozuschopnost informačního systému a to nejen za běžných
standardních provozních podmínek, ale i za mimořádných situací.
Řada vedoucích pracovníků se chybně domnívá, že předáním automatizovaného
informačního systému do rutinního provozu po jeho návrhu a realizaci, již bude systém
pracovat zcela sám a nebude vyžadovat pozornosti vedení firmy. Takový postoj vedoucích
pracovníků vede k situaci, kdy informační systém postupně degraduje ve svých funkcích, až
systém posléze nepodporuje činnost řídicích pracovníků firmy, ale je firmě jen na obtíž a
způsobuje firmě finanční ztráty.
Do problematiky údržby automatizovaného informačního systému patří:
- provozní údržba technických prostředků AIS
- provozní údržba programových prostředků AIS
- kontrola a doplňování znalosti uživatelů AIS
- opravy a úpravy AIS
- řešení havárií AIS
Pro všechny potřebné činnosti by měl dodavatel informačního systému specifikovat
jejich obsah, rozsah a způsob jejich provádění.
Provozní údržba technických prostředků AIS
Provozní údržbu provádějí řadoví pracovníci - každodenní uživatelé informačního
systému. Je nutno je k tomu instruovat a zařadit údržbu AIS do popisu jejich práce. Instruktáž
k provádění provozní údržby musí být provedena tak, aby pracovníci věděli, co je jejich
povinností, a aby požadované činnosti prováděli v patřičnou dobu a správným,
kvalifikovaným způsobem.
Jedná se o následující činnosti:
- Doplňování provozního materiálu (papíry do tiskáren, zásoby disket a jiných paměťových
médií) resp. výměna provozních prostředků (barvící pásky, tiskové hlavy, náplně inkoustu,
výměnná pera zapisovačů). Důležité je, aby pracovníci věděli přesně typ provozního
materiálu, který konkrétní zařízení vyžaduje a aby příslušné oddělení mělo informace o
průměrné spotřebě a dodacích lhůtách pro včasné objednávání a naplánování potřebných
provozních prostředků. Tuto činnost je nutno koordinovat často v rámci celé firmy, protože
pokud firma zajistí centralizaci požadavků a společný nákup spotřebního materiálu, může
získat významné množstevní slevy a tím dosáhnout úspor provozních nákladů na AIS!
Pracoviště by měla vést operativní evidenci o spotřebě materiálu k usnadnění a podpoře
plánování, a aby se zamezilo odnášení materiálu domů pro soukromou spotřebu zaměstnanců.
Zaměstnanci musí vědět, které úkony mohou provádět sami a které musí svěřit specialistům!
- Odstraňování drobných provozních poruch např. vyjmutí zaseknutého papíru v tiskárně,
apod. I zde musí být zaměstnanci seznámeni se správným postupem při odstraňování závady a
musí jim být vysvětleny situace, kdy zásah již nemohou provádět sami a musí pozvat
příslušného specialistu (např. případy, kdy by mělo dojít k odstranění krytu zařízení a tím k
nebezpečí úrazu elektrickým proudem). Musí být také stanoven jednotný způsob
poskytování servisních služeb a jednotný postup pro jejich aktivizaci (komu a kam volat
telefonem, jak vyplnit žádanku na opravu, jak a kým bude provedení služby potvrzeno a jak
bude služba placena, apod.).
- Pravidelné čištění případně jiné úkony, které vyžadují technické prostředky (čištění hlav
disketových mechanik čistícími disketami, výměny prachových filtrů, výměna baterií, apod.).
Provozní údržba programových prostředků AIS
K těmto činnostem patří zejména:
- Výmaz nepotřebných souborů na diskových médiích a reorganizace uspořádání souborů na
disku
- Aktualizace ochranných hesel
- Provádění bezpečnostních kopií
- Provádění detekce možných virů antivirovými programy
- Případná obnova souborů z bezpečnostních kopií
- Nastavení změněných pracovních parametrů operačních nebo aplikačních programů
- a další podobné činnosti.
Kontrola a doplňování znalostí uživatelů AIS
Před zahájením provozu informačního systému dodavatel obvykle provede školení
všech uživatelů, aby dovedli dobře obsluhovat dodaný informační systém. Mnoho vedoucích
pracovníků se domnívá, že takové školení stačí. Těm je nutno připomenout několik
skutečností:
- Pracovníci ve firmě se mění (fluktuace, odchody do důchodu, výměna pracovníků v
různých funkcích, apod.). To může způsobit, že za určitý čas může jen malá část personálu
patřit mezi pracovníky, vyškolené původní instruktáží. Ti ostatní mohou mít jen znalosti
zprostředkované neúplným ústním podáním předchozích pracovníků nebo získané jen
vlastním experimentováním. Pro ty je nutno zajistit možnost účasti školení u dodavatele.
- První úvodní školení je orientováno na získání základních znalostí, ale s postupem času, jak
se uživatelé stále více seznamují s dodaným informačním systémem, je žádoucí, aby zvládli i
jeho složitější funkce, které se v úvodních kursech neprobírají.
- Věci, které uživatelé nepoužívají každodenně se mohou časem zapomenout a je dobré, když
jsou pracovníkům kvalifikovaně opět připomenuty, případně když jsou časem zodpovězeny
dotazy, postihující komplikovanější případy obsluhy a vysvětleny složitější funkce
informačního systému, které se nedají vysvětlit pracovníkům, kteří se teprve seznamují s
obsluhou jeho základních funkcí., a které naopak požadují zkušení uživatelé.
- Dodavatelé se většinou pochopitelně zaměřují na instruktáž k obsluze jimi dodaného
systému a komponent, ale časem je v rámci systému instalována celá řada jiných programů
(tabulkové procesory, textové editory, presentační programy, specializované aplikační
programy, atd.), jichž se původní školení netýkalo.
Vzdělávání pracovníků by mělo být plánováno a evidováno. Pracovníci by měli být
vysíláni do kurzů od renomovaných, certifikovaných firem, kde se na závěr kurzu skládají
ověřovací testy a výsledky o absolvování kurzu by měli pracovníci po jeho ukončení předložit
vysílající firmě.
8.5 Opravy a úpravy AIS
Mezi opravy a úpravy řadíme ty rozsáhlejší činnosti údržby informačního systému,
které vyžadují účast specializovaných pracovníků dodavatele informačního systému a často
vyžadují přerušení práce informačního systému na určitou dobu.
Jedná se obvykle o následující případy:
- Zásahy do programového vybavení za účelem odstranění zjištěných programových chyb
nebo komplikovaných hromadných úprav datových souborů
- Instalace nových verzí operačního systému, databázového systému, síťového řídicího
systému nebo aplikačních programů
- Rozšiřování nebo rekonfigurace komunikační sítě
- Složitější opravy technických prostředků všeho druhu
- Odstraňování následků po komplikované havárii systému nebo po zásadních chybách
obsluhy
- Začleňování některých nových technických a programových prostředků do informačního
systému, kdy se vyžadují zásahy do stávajících částí systému
- Restrukturalizace základních souborů dat po havárii
- Úpravy informačního systému z hlediska nových legislativních předpisů, zákonů, nařízení,
technických norem, apod.
- a jiné situace.
Ve všech případech je nutno takové akce přesně naplánovat, aby výluka informačního
systémů trvala co možná nejkratší dobu, a aby prováděné zásahy do technických prostředků,
programových prostředků a souborů dat nevyvolaly nežádoucí pozdější vedlejší účinky, které
by prodloužily dobu přerušení normálních funkcí informačního systému a zapříčinily
nežádoucí dodatečné finanční náklady. Je nutno zajistit všeobecnou informovanost ve firmě,
že systém bude po určenou dobu mimo provoz.
Pokud je to možné, je velmi výhodné rozsáhlejší opravy a úpravy informačního
systému provádět v době minimálního provozu (noční směna, sobota, neděle, dovolená,
apod.).
8.6 Řešení havarijních situací AIS
Provozovatel informačního systému musí být připraven i na mimořádné havarijní
situace. Praxe ukazuje, že už čtyřhodinový výpadek informačního systému může zapříčinit ve
firmě celou řadu potíží. A co by znamenala situace, kdy v důsledku nějaké havárie by
informační systém byl mimo provoz několik dní?!
Příčinou havárie může být:
- mimořádná rozsáhlá porucha centrálního počítače (serveru) např. v důsledku elektrického
zkratu
- požár administrativní budovy, který zničí velký počet počítačů a rozvod komunikační sítě
- ztráta všech souborů dat v důsledku jejich výmazu destruktivním virem
- ztráta důležitých nosičů souborů dat v důsledku krádeže nebo jejich poškození v důsledku
neopatrného zacházení od obsluhy nebo v důsledku sabotážní akce
- atd.
Pověřený tým pracovníků firmy s podporou zástupců od dodavatele informačního
systému resp. za účasti odborníků specializované firmy by měl zvážit možná ohrožení a
připravit ochranu proti možným haváriím a postupy, které budou uplatněny, pokud přesto
havarijní situace nastane.
Obvykle bývá zvykem jmenovat řídicí havarijní (někdy též krizový) štáb, který bude
havárii řešit. Štáb je potřeba pro případ havárie vybavit potřebnými pravomocemi a připravit
způsob, jakým se vyhlásí havarijní situace ve firmě, aby se štáb mohl ujmout řešení nastalé
situace.
Je potřeba si položit otázku zajištění náhradního zpracování (např. na externím
serveru) což je nutno zajistit dopředu smluvně a připravit se na takovou situaci i technicky.
(Např. dohodou si zajistíme s dodavatelem informačního systému, že v případě potřeby
umožní využití serveru v své budově dodavatele za určitou částku, pro přenos dat z firmy
uživatele do firmy dodavatele se použije radiového přenosu, přičemž aparaturu zapůjčí místní
specializovaná radiokomunikační firma, která aparaturu za úplatu půjčí včetně okamžité
instalace a deinstalace atd.).
Není možno zapomenout na nutnost zajistit mimořádným opatřením doplnění dat,
která nebyla uložena do paměti náhradního počítače po čas doby převedení celého systému na
náhradní zpracování a po opětovném uvedení původního systému do chodu.
Havarijní situace obvykle vyžaduje mimořádná finanční vydání, na která by si měla
firma vytvořit rezervy, včetně mimořádných pracovních kapacit (smluvně zajištění důchodci
nebo ženy v domácnosti- ti všichni však musí být instruování o svých případných
povinnostech a způsobu prováděné činnosti).
Složitější situace je potřebné si vyzkoušet, aby se odhalily nedostatky zpracovaných
postupů, aby se ověřilo navržené řešení a aby se řídící štáb mohl dobře připravit na
mimořádnou situaci.
Přesto, že dnes je u běžné strojírenské firmy odhadováno, že bez informačního
systému nemůže pracovat déle jak půl směny a u banky ne déle než dvě hodiny, řada firem si
problém řešení mimořádných situací uvědomí až tehdy, kdy jí místní energetická firma
oznámí nutnou výluku elektrického proudu po dobu dopolední směny v důsledku poškození
nebo rekonstrukce rozvodného kabelu.
8.7 Bezpečnost provozu IS
8.7.1 Základní pojmy bezpečnosti informačních systémů
Důvody, které nutí firmy věnovat zvýšenou pozornost bezpečnosti informačních
systémů při jejich provozu, vyplývají z následujících skutečností:
- Investice do informačních technologií, které jsou využívány v rámci informačních systémů
představují vysoké částky, které je třeba účinně chránit.
- Fungování firmy je dnes zcela závislé na fungování informačního systému, takže vyřazení
informačního systému mimo provoz ohrožuje chod firmy.
- Data, která jsou uložena v pamětech informačního systému, mají jednak velkou cenu v
důsledku vynaložených nákladů na jejich získání a údržbu, jednak mohou být zneužita
konkurencí nebo jinými subjekty k získání informací v neprospěch firmy. Proto je potřeba
uložená data a informace účinně chránit.
Technické vybavení, programové vybavení a soubory dat informačního systému musí
současná firma řadit mezi aktiva společnosti. Jejich důležitost si uvědomíme, když
vyjmenujeme následné škody, které by nastaly, jestliže se by se pravděpodobné hrozby staly
skutečností. Škody mohou být přímé nebo nepřímé. Mohou být způsobeny např. zničením
nebo zneužitím informací. Se vzrůstem pravděpodobné škody a pravděpodobnosti uplatnění
hrozby roste riziko ztráty bezpečnosti informačního systému. Aby se snížilo toto riziko, musí
firma navrhnout a realizovat různá opatření resp. protiakce. Souhrn protiopatření ke snížení
rizik informačního systému tvoří bezpečnostní politiku informačního systému, která je
součástí komplexní bezpečnostní politiky firmy.
Hlavním cílem bezpečnostní politiky informačního systému je dosáhnout snížení
zjištěných rizik na přijatelnou úroveň pro zainteresovanou firmu. Důvěra, kterou lze mít v
bezpečnost poskytovanou informačním systémem, je označována jako míra záruky
bezpečnosti informačního systému. Čím je míra záruky větší, tím větší je důvěra, že systém
bude s přijatelnou úrovní zbytkových rizik chránit svá aktiva proti hrozbám.
Význam bezpečnostní politiky informačního systému pro současné firmy zdůraznil
dokument, označovaný jako ITSEM - Information Technology Security Evaluation Manual,
který vypracovaly společně zástupci států Evropské unie, aby vytvořily mezinárodní
harmonizovaná kritéria v této oblasti, která by byla základem pro mezinárodní uznávání
certifikátů bezpečnosti informačních systémů shrnujících výsledky hodnocení jejich
bezpečnosti. Taková harmonizace je nutná jako základ pro spolupráci firem zejména v rámci
Evropské unie. Důsledek tohoto přístupu k bezpečnosti informačních systému si musí
uvědomit české firmy. Pokud bezpečnostní politika jejich informačních systémů nebude
odpovídat standardům Evropské unie, může se nevyhovující bezpečnostní politika
informačního systému stát překážkou spolupráce s firmami Evropské unie. Absence
certifikátu bezpečnosti firemního informačního systému musí firma chápat stejně jako absenci
certifikátu jakosti podle řady norem ISO 9000.
Firma, provozující informační systém proto musí:
- Vypracovat bezpečnostní politiku firmy, zahrnující problematiku bezpečnosti informačního
systému
- Vyžadovat a zajistit, aby hledisko bezpečnosti informačního systému bylo uplatněno již při
návrhu informačního systému a aby provozovaný informační systém splňoval požadavky
firemní bezpečnostní politiky
- Uvést plnění bezpečnostní politiky do každodenní praxe
- Kontrolovat a vyhodnocovat dodržování bezpečnostní politiky jak vnitřními tak i externími
audity
- Zdokonalovat bezpečnostní opatření firmy zlepšováním bezpečnostní politiky a používáním
nových, progresivních technologií a postupů v této oblasti.
Následující schéma zachycuje procesy, které v rámci firemního AIS působí na zvýšení
bezpečnosti dat a informací:
Vývoj
Hodnocení
Cerifikace
Bezpečný provoz
Audit
Je potěšitelné, že i u nás vznikla již řada tuzemských firem, které se specializují na
zvyšování bezpečnosti informačních systémů, které vytvořily Asociaci firem pro ochranu
informací v rámci Hospodářské komory České republiky.
8.7.2 Ohrožení AIS
Tento odstavec nepředstavuje úplný výčet možných ohrožení informačního systému.
Seznam hrozeb pro konkrétní informační systém si musí firma zpracovat podle skutečné
situace sama. Zde uvedené hrozby slouží je jako příklad nečastějších hrozeb, které ohrožují
informační systémy a proti nimž je potřeba najít vhodná opatření:
- Technické havárie (výpadek elektrického proudu, požár, mechanická poškození
pádem zařízení nebo pádem jiných předmětů na zařízení, koroze, porucha zařízení, apod.)
- Teroristické útoky od anarchistů, duševně nemocných osob, gangsterských skupin,
placených záškodníků od konkurence, hackerů (mladíci, kteří si udělali sport z poškozování
dat v počítačích), zaměstnanců, kteří se rozhodli pro pomstu na firmě (dostali výpověď nebo
se jinak cítí firmou poškozeni). Útok může být veden jak proti technickému zařízení
(mechanické poškození), tak proti programům (výmaz programu) nebo údajům (výmaz dat na
disku).
- Omyly obsluhy (např. v jaderné elektrárně Černobyl se domnívali operátoři, že lépe
budou ručně řídit chod atomového reaktoru než automatické řízení a proto řídicí systém
vypnuli).
- Fatální chyby používaných programů (např. očekávaná situace s přechodem na rok
2000 v souvislosti se zkráceným zápisem čísla roku prostřednictvím dvou posledních míst
letopočtu v dosavadních programech).
- Destrukce souborů, programů a technických zařízení v důsledku programových virů,
časovaných bomb, apod.
- Krádež počítače, periférie, programu, disket, výměnných disků a jiných komponent.
- Okopírování datových souborů za účelem předání konkurenci nebo k jinému
zneužití (Poznamenejme, že zcizení počítače poznáme ihned po příchodu do kanceláře, ale že
si někdo okopíroval obsah našeho disku s posledními výkresy nejnovějšího výrobku pro
konkurenci pouhým pohledem nepoznáme!)
- Žaloby v důsledku špatného fungování programů, které nesplňují požadované
náležitosti ( týká se především programů z oblasti účetnictví, fakturace, apod.)
- Žaloby za neoprávněné užívání programů, na které firma nemá potřebnou licenci
(softwarové pirátství), nebo za manipulaci s datovými soubory, ke kterým nemá firma souhlas
k používání nebo je jinak porušen zákon na ochranu osobních dat (č.101/2000 Sb.)
- Právní překážky v používání programů v důsledku nesprávně uzavřených pracovních
smluv o autorských právech programátorů, kteří vyvíjejí aplikační programové vybavení pro
firmu
Ohrožení AIS se vztahuje na tzv. AKTIVA IS, což jsou hodnoty, které je potřeba
chránit (programy, data, technické prostředky, apod.).
8.7.3 Opatření k zvýšení bezpečnosti AIS
Opatření můžeme dělit na technická opatření, která využívají různých technických
prostředků ke zvýšení bezpečnosti, a netechnická opatření, což jsou opatření personální,
procedurální, organizační, a jiná. Uveďme přehled některých opatření, která mohou firmy s
výhodou použít k realizaci zvýšení bezpečnosti informačních systémů.
- Ochranná hesla uváděná pro získání přístupu k různým údajům nebo k provádění
různých operací jsou snad nejznámějším způsobem pro ochranu před neoprávněným
přístupem k datům. Bohužel není nejbezpečnější, pokud získá znalost hesla neoprávněná
osoba. Proto je nutno učinit dodatečná opatření k utajení stanovených hesel a k jejich
pravidelné výměně.
- Čipové karety, magmetické karty, elektronické klíče a pod. jsou velmi vhodné
doplňky, které lze použít v kombinaci s přístupovými hesly k zajištění oprávněného přístupu.
- Identifikace osoby podle jejích konkrétních tělesných atributů - hlas, otisky prstů,
žilky na sítnici oka - představuje zatím relativně nákladnou alternativu a používá se jen ve
velmi kritických případech.
- Šifrování přenášených zpráv a obsahu souborů dat je u nás bohužel málo rozšířená,
ale přitom velmi efektivní forma zabezpečení dat. Současná výpočetní technika a
matematické šifrovací metody dovolují snadnou a přitom velmi účinnou ochranu dat před
jejich neoprávněným použitím.
- Mechanické zajištění přístupu k počítačům, k uschovaným výměnným paměťovým
médiím (diskety, optické disky, kazety s magnetickými páskami) prostřednictvím
mechanických nebo elektronických klíčů a k nim příslušných zámků.
- Elektronický podpis je ekvivalentem manuálního podpisu na digitalizovaných
dokumentech, kdy se využívá kryptografických metod k ověření, zda elektronický dokument
vytvořila určitá osoba a zda nebyl při doručování v průběhu přenosu počítačovou sítí změněn.
- Elektronické zabezpečovací systémy včetně elektronické požární signalizace a
automatických hasicích zařízení, kdy je monitorován prostor, kdy se kritické počítače a
soubory dat nacházejí.
- Antivirové programy pro identifikaci virů a jejich odstranění, které je však nutno
neustále aktualizovat, aby byly schopny identifikovat vzorky nových virů, makrovirů a jejich
mutací.
- Ochranné prostředky pro počítačové sítě (Firewall - specializovaný prostředek
chránící firemní síť před neoprávněným přístupy z vnějších komunikačních linek)
- Výběr a prověření pracovníků, kteří mají přístup k firemním počítačům a k
citlivým údajům v nich uloženým. Často firma realizuje nákladná a složitá opatření,
zabezpečující dat před neoprávněným přístupem z vnějšku, aby pak nejdůležitější soubor dat
vynesl jejich řadový zaměstnanec.
- Pravidelné zhotovování bezpečnostních kopií důležitých dat. Tyto kopie je pak
možno použít k rekonstrukci poškozených nebo zničených souborů. Bezpečnostní kopie musí
být řádně označeny, aby se dal přesně identifikovat jejich obsah, a měly by být uchovávány
odděleně od ostatních nosičů na zvláště chráněných místech. Řada firem ke své škodě
nevyužívá tohoto poměrně jednoduchého způsobu zabezpečení svých dat až do doby, kdy v
důsledku nějaké příčiny přijde o svá data a je jí způsobena velká škoda. Pro rozsáhlé soubory
dat je často neekonomické uchovávat kopie celých souborů. V takovém případě se používá
tzv. přírůstkového (inkrementálního) způsobu archivace dat, kdy se uchovávají aktualizační
zásahy do dat, prostřednictvím kterých lze s použitím uchované kopie obnovit potřebná data
specializovaným programem. Bezpečnostní kopie se uchovávají často systémem několika
generací souborů dat (nejčastěji tří generací: děd - otec syn), aby bylo možno se vrátit i verzi
souboru z dřívějšího časového období.
- Protokolování chodu informačního systému z hlediska bezpečnosti představuje
účinný, i když poměrně náročný prostředek. Z dat, získaných protokolováním činnosti
informačního systému, se snažíme získat informace o opakovaném zadávání hesel ( nemusí se
jednat o omyl, ale o pokus heslo náhodně najít), o poskytování informací na netypická místa v
počítačové síti (jak to, že údaje pro generálního ředitele se zobrazovaly na terminálu
detašovaného pracoviště ve městě, mimo sídlo firmy), apod.
- Sistace poskytnutí dat nebo možnosti provádění operací. Citlivá dat se neposkytnou
žadateli bezprostředně na požádání, ale vyžaduje se souhlas jiných firemních pracovníků
počítačové sítě, kteří mohou poskytnutí dat pozastavit, když vidí nějaké nebezpečí zneužití.
8.7.4 Metoda CRAMM
CRAMM (CCTA Risk Analysis and Management Method) je metodika pro zavádění a
podporu systému řízení bezpečnosti informací (Information Security Management System
nebo ISMS) pro provádění analýzy rizik informačních systémů a sítí, k návrhu
bezpečnostních protiopatření, určování havarijních požadavků na informační systém a k
návrhům na řešení havarijních situací. Metodiku a soubor nástrojů CRAMM je možné:
využít u všech druhů informačních systémů, ve všech fázích jejich životního cyklu, od
studií proveditelnosti přes analýzu požadavků, vývoj a implementaci, provoz, údržbu a
inovaci IS
detailně určit hodnotu dat zpracovávaných v informačním systému, stanovit nejrizikovější
části systému
navrhovat protiopatření snižující zjištěná rizika
plně podporovat proces zavádění ISMS v souladu s normou BS 7799-2:1999, která
využívá normu ISO/IEC 17799:2000 jako nejlepší praktiky pro zavádění a využívání
ISMS.
vytvořit a neustále aktualizovat kompletní bezpečnostní dokumentaci od bezpečnostní
politiky po bezpečnostní provozní směrnice včetně dokumentů nutných pro certifikaci.
Metodu CRAM v ČR implementuje a podporuje firma RAC
Praha (viz www.ra.cz)
8.8 Inovace IS
8.8.1 Vymezení základních pojmů
Každý informační systém byl po návrhu a realizaci předán do užívání v určitém stavu
a velikosti. Od okamžiku předání se může rozvíjet, ustrnout nebo upadat.
Rozvojem informačního systému rozumíme zvyšování jeho kvantitativních a
kvalitativních parametrů v průběhu jeho užívání. Pokud se tyto parametry v průběhu
používání nemění, dochází k ustrnutí - stagnaci. V případě, že se parametry informačního
systému zhoršují, hovoříme o úpadku - degradaci informačního systému.
Kvantitativní parametry popisují určité charakteristické hodnoty informačního
systému , zejména technického, programového , systémového a provozního druhu.
Např.:
- parametry popisující konfiguraci informačního systému:
- počet použitých počítačů resp. procesorů
- výkon použitých počítačů resp. procesorů
- objem disponibilních operačních pamětí
- objem on-line disponibilních externích pamětí
- přenosová kapacita komunikačních linek
- počet periferních zařízení
- počet koncových pracovišť
- a další
- parametry charakterizující provoz informačního systému
- spotřebovaný čas CPU za stanovenou dobu
- průměrná doba odezvy pro jednotlivé požadavky
- počet aktivně používaných programů
- počet provedených transakcí za stanovený čas
- objem přenesených dat za stanovený čas aj.
- parametry charakterizující systémové řešení
- celkový počet údajových položek
- počet typů datových entit
- počet vazeb mezi datovými entitami
- počet automatizovaných funkcí na určené úrovni dekomposice
- a další.
Kvalitativní parametry charakterizují vybrané vlastnosti informačního systému z
hlediska jeho návrhu a využívání. Výčet není vyčerpávající. Pro konkrétní situaci
vyhodnocení informačního systému je nutno stanovit konečnou množinu takovýchto
parametrů a popsat přesně jejich definici (to platí samozřejmě i pro kvantitativní parametry).
Kvalitativní parametry mohou být stanoveny např. takto:
- druh a způsob využívání databázové koncepce
- stupeň automatizace úloh
- úroveň a způsob uspokojování požadavků uživatelů
- typ architektury informačního systému
- atd.
Pro každý z vyjmenovaných parametrů můžeme stanovit tzv. index změny. Ten
ukazuje jak se hodnota parametru mění v jednotlivých časových okamžicích, Obvykle bývá
zvykem zavést tzv. index změny parametru k počátku instalace, který ukazuje změnu proti
původnímu stavu parametru při uvedení informačního systému do používání. Např. při
uvedení informačního systému v lednu 1998 bylo v počítačové síti zapojeno 20 personálních
počítačů, nyní k lednu 1999 je jich v síti zapojeno 45, tj. index změny počtu připojených
osobních počítačů v síti k počátku instalace je 45/20=2,25. Někdy se určuje i tzv. přírůstkový
index změny, který určuje změnu parametru v určitém časovém intervalu. Např. v první
polovině roku 1998 jsme přikoupili 10 osobních počítačů k původním 20 PC a v druhé
polovině zbývajících 15, takže v první polovině roku 1998 byl přírůstkový index změny
30/20=1,5, v druhé polovině roku 1998 byl přírůstkový index změny 45/30=1,5.
Index změny má tedy hodnotu rovnu jedné při stagnaci parametru. Hodnota větší než
jedna indikuje růst parametru, hodnota menší než jedna indikuje pokles parametru.
Pokud rostou výhradně kvalitativní parametry, hovoříme o růstu systému.
Pokud rostou jen kvalitativní parametry, hovoříme i kvalitativní inovaci systému.
Za rozvoj informačního systému označíme situaci, kdy rostou jak kvalitativní, tak
kvantitativní charakteristiky.
Samozřejmě můžeme stanovit i tzv. průměrný index změny rozvoje informačního
systému na základě indexů změn všech parametrů. V takovém případě pak můžeme
nakreslit graf závislosti rozvoje informačního systému v čase prostřednictvím průměrného
indexu rozvoje informačního systému.
Průměrný index změny
rozvoje AIS
čas
Obr. 1. Růst AIS v závislosti na čase
Důvody inovačního rozvoje informačního systému
Důvody rozvoje informačního systému je nutno hledat v požadavcích pracovníků
firmy na informační systém. Ty jsou odvozeny z následujících skutečností:
- zvětšuje se velikost firmy
- zvyšují se zkušenosti s využíváním informačního systému a tím i nároky na informační
systém od jednotlivých pracovníků ve firmě
- zvyšují se požadavky na informace v důsledku narůstající informační bariéry ve společnosti
- rozvíjí se technické a programové prostředky výpočetní techniky
- jsou vyvíjeny nové informační technologie
- rozvíjí se teorie a praxe informačních systémů
- zvyšují se všeobecně požadavky na jakost informačních systémů
- atd.
8.8.2 Růst AIS
Za nejvýznamnější faktor růstu je však nutno označit rozvoj podniku. Pod pojmem rozvoj
podniku budeme rozumět situaci, kdy dochází ke zvětšování velikosti podniku , zvyšování
objemu výroby a zvyšování zisků. Můžeme vyslovit tvrzení:
Jestliže se rozvíjí podnik, pak se rozvíjí informační systém podniku.
Rozvoj podniku zde představuje antecedent implikace , zatímco rozvoj informačního
systému zde představuje konsekvent této implikace ve smyslu výrokové logiky.
Pokusme se komentovat jednotlivé možné kombinace uvedené implikace. Nula v nich
představuje nepravdivost a jednička pravdivost příslušného dílčího výroku.
0⇒0 (Podnik se nerozvíjí - Nerozvíjí se informační systém podniku)
Podnik, který se nerozvíjí či dokonce stagnuje, nemá prostředky na rozvoj informačního
systému. Je zřejmě špatně řízen, a proto jeho management ani nemá zájem rozvíjet informační
systém.
1⇒1 (Podnik se rozvíjí - Informační systém podniku se rozvíjí)
Rozvíjející se podnik musí svůj úspěšný rozvoj podpořit rozvojem informačního systému,
aby uspokojil informační požadavky svých zaměstnanců a zajistil relevantní informace pro
podporu rozhodovacích procesů.
0⇒1 (Podnik se nerozvíjí - Informační systém podniku se rozvíjí)
Tato pravdivá kombinace implikace říká, že neprosperující podnik také může rozvíjet svůj
informační systém. Jedná se o některou z následujících situací:
- Podnik v potížích odhalil jako brzdu svého rozvoje špatné fungování informačního systému
a rozhodl se ho zdokonalit na potřebnou úroveň. Bohužel tato situace zahrnuje i variantu, kdy
se investuje do rozvoje informačního systému jen jako do "zázračné" akce, která má
automaticky zabránit další stagnaci nebo úpadku firmy.
- Stagnující podnik využívá pokroku v informačních technologiích a zdokonaluje svůj systém
různými, zejména intenzifikačními, postupy v důsledku všeobecného pokroku v této oblasti.
- Okolí podniku (státní orgány, státní legislativa, konkurence, požadavky zákazníků, veřejné
mínění atd.) nutí podnik rozvíjet informační systém.
1⇒0 (Podnik se rozvíjí - Informační systém se nerozvíjí)
Nepravdivá kombinace implikace signalizuje situaci, která může negativně ovlivnit
prosperitu a další rozvoj podniku tím, že nerozvíjející se informační systém začne upadat a
nebude poskytovat potřebnou podporu vedoucím a řadovým pracovníkům podniku. Stane se
tak jedním z faktorů, které mohou být nejprve příčinou řady problémů a později dokonce
příčinou úpadku podniku.
Samotný fakt, že se informační systém rozvíjí, nestačí, jestliže chceme, aby opravdu
dobře podporoval rozhodovací činnosti v podniku.
Informační systém se musí rozvíjet tempem, které odpovídá tempu rozvoje podniku.
Podobně, jako pro rozvoj informačního systému, můžeme stanovit průměrný index
růstu podniku R a jeho hodnoty pro určité (nejlépe stejné) časové okamžiky. Přitom by mělo
platit, že pokud byl předán do provozu informační systém vhodné velikosti, podporující
řízení ve firmě v potřebném rozsahu, pak by tempo rozvoje informačního systému mělo být
stejné nebo větší jako tempo hospodářského rozvoje podniku. Pokud je tempo nižší,
dochází k opožďování tempa rozvoje informačního systému za tempem rozvoje podniku a
tím vzniká disproporce, která opět může znamenat problémy, případně později stagnaci a
úpadek podniku při neřešení této situace.
Rozvoj evoluční a revoluční
V předchozích úvahách byl předpokládán postupný růst parametrů jak informačního systému
tak podniku - tedy tzv. evoluční rozvoj. V praxi však často dochází k revolučnímu rozvoji
informačního systému nebo podniku, případně k revolučnímu růstu v obou případech. Např.
výměna dosavadního zastaralého počítače za nový a progresivní počítač (rozvoj AIS),
sloučení dvou firem, zvýšení produkce výroby otevřením nově postavené haly (rozvoj
podniku). V řadě publikací renomovaných ekonomů je vysvětleno, proč je růst podniku
nezbytným předpokladem jeho úspěšné existence. Neznamená to, že by musel trvale růst
počet zaměstnanců, ale že konec konců musí firma vyvíjet stále dokonalejší výrobky, snižovat
náklady, zvyšovat zisk atd. Stagnace firmy přechází v dnešním dynamickém světě tržní
ekonomiky rychle v její zánik. V současné éře všeobecné informatizace je však neméně
důležité víc než kdy jindy, aby se rozvíjel i její informační systém. Sladění rozvoje AIS s
rozvojem podniku však přináší problémy.
Následující graf na obr.2. ukazuje řešení, kdy uživatel koupil nový model s vyšším
výkonem ihned, kdy se vyčerpal výkon starého modelu. Platí za tento přírůstek výkonu
zbytečně po celou dobu B, než skutečně může tento výkon využít s ohledem na rozvoj firmy.
Průměrný index změny rozvoje AIS
B
Obr.2. Předsunutý rozvoj informačního systému
čas
Obr. 3. zobrazuje naopak situaci, kdy uživatel čeká a nepokrývá svoje zvýšené
informační požadavky do té doby, než dosahují možnosti nového plánovaného modelu
počítače.
Průměrný index změny rozvoje AIS
čas
B
Obr. 3. Opožděný rozvoj informačního systému
V obou případech však dochází ke ztrátám. V prvním případě v důsledku nevyužitého
a zaplaceného výkonu. V druhém případě v důsledku nedostatečné podpory řízení a
rozhodování počítačem. Z toho vyplývá nutnost souladu změn v rozvoji firmy a rozvoji
informačního systému a nutnost návrhu flexibilního AIS, který umožňuje pružně se
přizpůsobovat měnícím se požadavkům firmy v průběhu provozu AIS.
Změny v AIS při jeho provozu nejsou mnohdy jednoduchým problémem. Např.
výměna počítače za výkonnější centrální počítač může být komplikovaným problémem, když
nový počítač není kompatibilní s dosud používaným a vyžaduje přeprogramovat stávající
programy, apod. V průběhu změny dochází často k poklesu výkonnosti AIS a tím i k poklesu
přínosů pro firmu, jak ukazuje obr. 4.
8.8.3 Přínosy AIS v průběhu inovace
A
B
C
čas
Obr.4. Průběh přínosů při revoluční změně AIS
Průběh přínosů zachycuje tři období. Období A, kdy přínosy stoupají. Období B, kdy
na konci období A a začátku období B byla zahájena rozsáhlá změna informačního systému.
V důsledku provádění změny však poklesne výkon i přínosy, stoupají náklady na provoz.
Teprve po dokončení změny postupně vzrůstá nejen výkon, ale zlepšený informační systém
představuje postupné zvyšování přínosů pro firmu.
Postupný (evoluční) růst informačního systému nepředstavuje takové problémy, takže
bychom ho měli logicky preferovat. Na druhé straně jen zásadní (revoluční) rozvoj
informačního systému může být často jediným řešením při náhlé změně požadavků v
důsledku prudkého růstu firmy. Proto je důležité navrhnout správně architekturu AIS s
ohledem na možné přizpůsobování informačního systému rozvoji firmy a vypracovat
správnou strategii růstu informačního systému s přihlédnutím k růstu firmy. Klíčovými
problémy je zde volba správné strategie tvorby datové základny, výběru vhodného
počítačového systému a počítačové sítě, správná volba systémového integrátora a dobře
zpracovaná informační strategie firmy. Pozdější vynucený a neplánovaný přechod např. od
souborového zpracování na využívání báze dat, přechod z databázového systému typu
dBASE na databázový systém založený na normě ISO SQL v prostředí operačního systému
UNIX, přechod od malého systému několika propojených ekonomických agend na
integrovaný informační systém a změna dodavatelské softwarové firmy apod., představují
problémy, kterým je lépe se vyhnout a je možno se jim vyhnout, sestavením správné strategie
informačního systému, která uvažuje i dynamiku rozvoje informačního systému a to v jeho
návaznosti na dynamiku rozvoje firmy.
Navíc je nutno zdůraznit, že se často zapomíná na nutnost připravit, navrhnout a
realizovat rozsáhlé změny v informačním systému stejně jakostně, jako návrh nového
informačního systému na začátku jeho zavedení. Stejně je nutno si uvědomit, že neřízené
postupné zásahy, spojené s drobným „vylepšováním“ informačního systému mohou zakrátko
destabilizovat a znehodnotit celý informační systém.
8.9 Organizace služeb IT
8.9.1 Organizační začlenění služeb IT
Na organizační zajištění tvorby a provozu IS lze pohlížet ze dvou hledisek:
Zákaznického, kdy se zabýváme organizací provozu IS uživatelské firmy a
klademe si otázku: „Jak máme organizovat provoz IS, aby poskytoval potřebné
informace?“ V současné době se nejčastěji používá označení HELP DESK pro
oddělení/místo, které zodpovídá za poskytování podpory uživatelům aplikací, jenž
organizace provozuje.
Dodavatelského, kdy se zabýváme problémy – co doporučit zákazníkovi
s ohledem na provozování dodaného IS a jaké služby mu nabídnout v průběhu
provozu. Nejčastější formou okamžité podpory je HOT LINE a oddělení styku se
zákazníky.
Pro zajištění organizace provozu IS musí uživatelská firma zvážit objem práce a možné
náklady, aby se rozhodla, které činnosti bude zajišťovat vlastními silami, a které si objedná
jako službu (outsoursing viz dále). Pro zajištění činností vlastními silami zřizuje podle
okolností:
Jen popisy činností, které musí vykonávat zaměstnanci v rámci své náplně práce
při provozu IS
Referentská pracoviště, kde pověřený pracovník zajišťuje vyjmenované činnosti
na plný úvazek
Oddělení informatiky, kde je soustředěna řada specialistů, kteří se starají o
činnosti, spojené s návrhem a používáním informačních technologií.
Pokud firma přistoupí k využití externích služeb, musí být jasné, které služby budou
zajišťovány externě a jak bude probíhat komunikace s dodavatelem (dodavateli) těchto
služeb.
8.9.2 Mezinárodně doporučované metodiky
Metodika COBITTM
Metodika COBIT (Control Objectives for Information and Related Technology)
představuje dnes jednu z nejkomplexnějších metodik formalizujících řízení a hodnocení IS/IT.
Tato metodika vzniklá asociaci ISACF, definuje řízení IT jako korelační vazbu mezi
souborem požadavků (kritérií), IT zdroji a IT procesy. Struktura IT procesů vytváří smyčku
(viz obrázek), která obsahuje základní prvky životního cyklu IT systémů.
IT procesy dle COBIT jsou popsány v členění na čtyři logické skupiny:
- Plánování & Organizování – obsahuje 11 procesů
- Akvizice & Implementace – obsahuje 6 procesu
- Dodávka & Podpora – obsahuje 13 procesů
- Měření a hodnocení – obsahuje 4 procesy
Pro každý z těchto procesů je popsán rozpad na detailní činnosti, jejich vstupy a
výstupy, rovněž je navržen referenční soubor cílů, výsledkových a výkonnostních metrik.
Dále jsou ke každému z těchto procesů k dispozici konkrétní kritéria a metody hodnocení
celkové kvality procesu. Hodnotící škála má 6 stupňů, od 0 (proces neexistuje) do 5 (proces je
zcela optimalizován) sloužících pro hodnocení kvality procesů.
Právě vysoká komplexnost je hlavní silnou stránkou COBITu. Je dobře uplatnitelná u
velkých podniku, pro malé a střední podniky je však jeho komplexnost a složitost příliš
vysoká.
ITIL je zkratkou pro "Information Technology Infrastructure Library", což přeloženo do
češtiny znamená "knihovna infrastruktury informačních technologií". ITIL skutečně vznikl
jako sada knižních publikací popisujících způsob řízení IT služeb a ICT infrastruktury.
V současné době je však ITIL již zcela samostatným oborem činnosti a podnikání, jenž
zahrnuje:
1. Samotnou knihovnu čítající v současné době 8 svazků
2. Oblast vzdělávání a certifikace odborné způsobilosti
3. Oblast poskytování konzultačních služeb
4. Oblast vývoje a implementace softwarových nástrojů pro podporu procesů ITSM
5. Mezinárodní platformu profesionálů a odborné veřejnosti
U nás je k dispozici specializovaný portál www.itil.cz, odkud byly čerpány i tyto informace.
Obsah ITIL
ITIL prostřednictvím svých publikací popisuje:
•
•
Vydefinování procesů potřebných pro zajištění ITSM:
o
Stanovení cílů, vstupů, výstupů a aktivit každého procesu
o
Stanovení rolí a jejich odpovědností v daném procesu
o
Způsob měření kvality poskytovaných IT služeb a účinnosti ITSM procesů
(Key Performance Indicators + metriky)
o
Vzájemné vazby mezi jednotlivými procesy
o
Postupy auditu a zásady reportingu pro každý proces
Zásady pro implementaci procesů ITSM:
o
Přínosy každého procesu
o
Critical Success Factors, možné problémy a vhodná protiopatření
o
Náklady na implementaci a následný provoz
o
Zásady pro řízení podpůrné ICT infrastruktury
o
Zásady bezpečnosti ICT infrastruktury
ITIL neřeší:
• konkrétní podobu organizační struktury
•
způsob obsazení rolí konkrétními pracovními pozicemi (pouze dává doporučení, které
role by měly / neměly být kumulovány u jedné konkrétní osoby)
•
podobu a obsah pracovních procedur
•
projektovou metodiku implementace
implementačního projektu:
Všechny
tyto
záležitosti
jsou
věcí
Důvody pro implementaci ITIL v podniku
Níže uvedených "Top Ten" důvodů pro implementaci procesů ITSM podle ITIL je výsledkem
průzkumu uskutečněného mezi ICT řediteli firem, které ITIL implementovaly. Pořadí je
uvedeno podle důležitosti, jak ji vnímali samotní respondenti:
1.
Nastavení ICT strategie podle strategie obchodu
2. Dodržování obchodních požadavků a požadavků uživatelů
3. Úspěšné vyrovnávání se s přicházejícími změnami
4. Vyrovnané jednání s ostatním managementem
5. Řízení nákladů, rozpočtu a zdrojů
6. Udržování kroku s vývojem technologií
7. Snadnější přijímání ICT pracovníků a snížení fluktuace
8. Řízení času a zdrojů
9. Řízení infrastruktury
10. Udržování znalostí a dovedností
(zdroj: Art of Technology)
Poradenské firmy uvádějí obvykle jako "TOP FIVE" přínosů implementace ITIL:
•
Úspora nákladů na provoz IT služeb
•
Lepší kvalita a spolehlivost IT služeb
•
Lepší využívání drahých ICT zdrojů
•
Menší počet výpadků ICT systémů
•
Vyšší úroveň komunikace pro lepší porozumění mezi pracovníky úseků ICT a
zákazníky / uživateli
Publikace ITIL:
•
•
Service Support. Publikace popisuje 10 základních procesů ITSM - řízení, dodávka
a podpora IT služeb.
Service Delivery. Kniha navazuje na první publikaci a popisuje procesy pro
zajištění IT služeb.
•
•
•
•
•
•
ICT Infrastructure Management. Kniha pokrývá všechny aspekty řízení ICT
infrastruktury od identifikace obchodních požadavků přes nabídkové řízení až po
testování, instalaci, nasazení a následnou pravidelnou údržbu a podporu ICT
komponent a IT služeb. Kniha popisuje hlavní procesy týkající se řízení všech
oblastí souvisejících s technologiemi,
Application Management. Kniha zahrnuje procesy celého životního cyklu
aplikačního softwaru od prvotní studie proveditelnosti, přes vývoj, testování,
vytváření aplikační dokumentace a školení uživatelů, implementaci do
produkčního prostředí, provoz aplikace, změnová řízení během provozu aplikace
až po stažení aplikace z používání. Obsahuje původní tituly Software Lifecycle
Support and Testing + Testing of IT Services, a navíc rozšiřuje tuto problematiku o
oblast změnových řízení aplikačního softwaru (důraz je položen na jasnou definici
obchodních požadavků kladených na aplikační software)
Business Perspective. Kniha je určena zejména vedoucím pracovníkům
obchodních a provozních úseků podniku. Jsou zde představeny základní prvky a
principy řízení ICT infrastruktury, IT Service Managementu a Application
Managementu, které jsou nezbytné pro podporu obchodních procesů.
Planning to Implement Service Management. Tato kniha popisuje aktivity, úkoly a
problémy související s plánováním, implementací a zlepšováním procesů IT
Service Managementu v podnikovém prostředí. Je určena především členům
implementačních týmů.
Security Management. Popis procesu plánování a řízení definované úrovně
bezpečnosti informací a IT služeb včetně všech aspektů souvisejících s reakcí
na bezpečnostní incidenty.
Software Asset Management. Kniha obsahuje popis procesů řízení, kontroly a
ochrany softwarového majetku ve všech stadiích jeho životního cyklu.
Vztahy mezi příručkami zachycuje následující schéma:
8.10 Definování úrovně služeb -SLA
S poskytováním služeb je dnes svázán pojem SLA – Service Level Agreement. Ten
představuje interní nebo externí dohodu o úrovni poskytovaných služeb a souvisejících
skutečnostech:
- vymezení obsahu a objemu poskytovaných služeb
- forma a způsob předkládaných požadavků na služby
- kritéria pro vyhodnocení kvality služby (doba odezvy, stanovení priorit, případné
ohodnocení služby, apod.)
- zodpovědnost za poskytování služby a sankce za nedodržení požadované úrovně
služeb
- apod.
8.11 Outsorcing při provozování AIS
V současné době je vyvíjen velký tlak na snižování nákladů. Tomu požadavku se nelze
vyhnout ani v případě nákladů na provozování a zajištění IT/IS.
Pojem Total Cost of Ownership (TOC), zavedla společnost Partner Group.
V současnosti je TOC považován za relativně přesný a propracovaný přístup ke sledování
nákladů.
Je to metoda stanovení úplné ceny za vlastnictví informačních technologií v celém
životním cyklu jejich využívání (pro většinu dnešních systémů je morální životnost plánována
v rozmezí 3-7 let), tedy nad rámec pořizovací investice. Finanční náklady tedy nejsou všemi
náklady na IS/IT, i když jsou projektovány přes celý životní cyklus.
Důležitým aspektem při sledování nákladů je zvážení nepřímých nákladů na straně uživatele
zmiňovaných jako ”skryté” náklady. Nepřímé náklady jsou kalkulovány z neproduktivního času uživatelů
vyvolaného jednak nutností zajišťovat svépomocí činnosti související s údržbou a provozem IS/IT a dále pak v
důsledku výpadků systémů IS/IT. Je to obdobné jako při pořízení automobilu. Při jeho koupi se zajímáme
samozřejmě o jeho technické parametry, pořizovací cenu, ale i o takové věci, které zatíží náš rozpočet průběžně:
spotřeba, náhradní díly, cena servisu, pojistky a další doplňky. TCO vychází z obdobného principu. Jde o to
stanovit, kolik nás pořízení a provozování systému bude stát v průběhu let, kdy jej budeme využívat.
Komponenty TCO - v zásadě lze náklady na vlastnictví systému rozdělit na:
• pořizovací náklady
• průběžné náklady na obsluhu systému
• průběžné náklady na úpravy, přizpůsobování a funkční rozšiřování systému
• náklady na rozšiřování (velikosti) systému
TCO se soustřeďuje na 5 kontrolovatelných bodů:
o heterogenitu operačních systémů a kancelářských balíků
o různorodost servisních úrovní
o množství fyzických přesunů personálu
o počet počítačových pracovišť
o frekvenci obměn firemního softwaru.
Pomocí TCO posléze můžeme:
- srovnávat aktuální hodnotu TCO s typickou hodnotou definovanou na základě
výzkumů spol. Gartner Group
- pomocí výsledku tohoto auditu definovat silné a slabé stránky IS/IT tak, aby bylo
možno navrhnout a posléze vytvořit prostředí pro zlepšení TCO
- simulovat náklady a přínosy pro analýzu návratnosti požadovaných investic
ukazatelů výkonnosti a úrovně služeb včetně potřebného počtu lidí
TCO je základem pro hodnocení výhodnosti či nevýhodnosti investic do určitého
systému. Na základě tohoto vyhodnocení nám může TCO ukázat na nejvhodnějšího
efektivní řešení dané oblasti, jakým může být například využití outsourcingu od externího
dodavatele.
Outsourcing je pojem, který vychází ze slov out (=vnější) a source (=zdroj) a znamená
uskutečňování činností pomocí vnějších zdrojů. Outsourcing je takový smluvní vztah s externí
firmou, kdy vstup, který by firma získávala z vlastních zdrojů, koupí od jiného subjektu jako
službu (nebo zboží). Tím odstraní interní činnosti související s obhospodařováním zdroje a
přenese zodpovědnost za tuto oblast na poskytovatele. Podnik takto tedy od sebe zdroj odsune
(out). Outsourcing IT znamená pro vrcholové vedení zadavatele vyjasnění a definici jeho
vlastních podnikových procesů (základních a podpůrných podnikových funkčních oblastí).
Metoda outsourcingu se provozuje již od šedesátých let minulého století. Za zlom
v rozšíření a začátek masového užití (v USA) se stalo v osmdesátých letech jeho užití firmou
Kodak, následovanou mezinárodními koncerny, jako Xerox, GM, apod. V České republice již
na principu poskytování outsourcingu fungují mj. některé závodní jídelny, ostraha objektů,
úklidové služby, které využívají služeb outsour. firem.
Pro outsourcing IT/IS je důležitá role informačního systému pro zadavatele, tzn.
jakým způsobem je ovlivněná podnikatelská činnost podniku provozem IS. Všechny
podpůrné procesy mohou být předmětem outsourcingu, splní-li další kriteria, jako je např.
schopnost naprosto jasné definice rozhraní outsourcovaného procesu.
Často dochází k domněnce, že outsourcing IT je mnohem nákladnější než provoz ve
vlastní režii [viz.20]. Na první pohled se zdá, že z finančního hlediska je výhodnější zajistit
provoz definovaných oblastí pomocí vlastních zdrojů. Proto je zde třeba uvést ty faktory,
které zpravidla nejsou zahrnuty do finanční kalkulace při hodnocení vlastního zajištění
provozu IS a jsou tak často podhodnoceny:
• Náklady na výběr nových technologií
• Skrytí lidé – nejsou zaměstnáni přímo v oddělení IT, pracují v ostatních odděleních
na různých pozicích (většinou fandové, samouci v IT), a při tom v nich ještě
pomáhají se zajištěním bezproblémového provozu IT
• Konzultační služby pro vývoj informačního systému
• Likvidace zastaralých technologií
• Testování nových technologií před implementací
• Podpůrné technologie, které nejsou plně využité
• „Shelfware“ neboli software objednaný, zaplacený a ležící nepoužitý v nějakém
regálu
• Náklady na vzdělávání pracovníků
• Organizační náklady pro pracovníky (pracoviště, personální náklady, pojištění)
• Školení operátorů, administrátorů a programátorů
• Kalkulované, pravidelné a plánované náklady
• Vlastní riziko při výpadku informačního systému
• Energie, nájmy, zajištění ochrany
Hlavní přínosy outsourcingu ovšem nespočívají jenom ve snížení nákladů, ale
především v kvalitě, dostupnosti, flexibilitě a snížení vlastních rizik po vstupu poskytovatele
do firmy.
Oblast IS/IT v podniku můžeme z hlediska outsourcingu vidět několika způsoby:
1. outsourcing jakékoliv funkční oblasti se dotýká IS – při vytěsnění nějaké funkční
oblasti se přesouvají kompetence týkající se též funkcí, procesů, dat, které jsou
zahrnuty v IS podniku. Je tedy nutné řešit vzájemné vztahy a
vymezit
zodpovědnosti mezi zákazníkem a poskytovatelem.
2. je vytěsněna samotná oblast IS/IT nebo její části. Rozlišujeme na:
a) outsourcing vývoje IS/IT – externí dodavatel na základě požadavku
zákaznického podniku vyvine a dodá IS/IT.
b) outsourcing provozu IS/IT – poskytovatel spíše než IS jako takový, dodává
služby, které zákazník od IS očekává. Řízení a zajištění provozu pak není
záležitostí managementu a pracovníků zákazníka a jsou v plném rozsahu
zajišťovány poskytovatelem.
Ve skutečných případech se může outsourcing vývoje a provozu kombinovat a různě
překrývat. Rozsah outsourcingu může být dále posuzován z hlediska toho, zda jsou externě
zajišťované:
-
-
komplexní outsourcing IS/IT (full service) - v péči (a pravděpodobně i v majetku)
poskytovatele celý IS podniku a veškerá informační technologie potřebná pro
zajištění vývoje a provozu podnikového informačního systému + zajišťován celý
životní cyklus IS/IT + další služby (více viz. kap. 5. – 5.6)
jen některé dílčí aplikační oblasti IS podniku jako např. elektronický obchod,
účetnictví, řízení logistických řetězců, apod.
samostatně vytěsnitelné části IS/IT – outsourcing datových center, outsour.
LAN/WAN sítí, telekomunikací
technologický outsourcing - pouze správa a provoz některých IT (např. údržba a
provoz PC, provoz a řízení sítí, správa datových center, zajištění bezpečnosti)
některé etapy životního cyklu IS/IT (např. údržba a rozvoj aplikací ZSW,ASW,
případně jen jejich vývoj)
Dalším hlediskem pro posouzení úrovně outsourcingu je vlastnictví hmotných i
nehmotných statků (aktiv) souvisejících s provozem IS. Na rozdíl od pracovníků –
informatiků, kteří většinou při komplexním outsourcingu. přecházejí k poskytovateli,
budovy a zařízení IT mohou, ale nemusí změnit vlastníka. Z tohoto hlediska rozlišujeme
varianty:
a) poskytovatel má prostory a zařízení od zákazníka v pronájmu, ty mu spravuje a
dodává mu podle smluvního závazku službu
b) prostory a technické vybavení vlastněné před vytěsněním jsou následně
prodány poskytovateli
c) poskytovatel má sám (vlastní) vše, co je potřebné k provozu IS/IT a dodává
informace jako službu. Zákazník omezuje investice do IS/IT (ideálně na 0).
Je také důležité, jaké je vzájemné vlastnické postavení obou partnerů. Může to být:
-
vnitřní outsourcing., kdy poskytovatel služby je součástí organizační struktury
zákazníka, např. samostatná divize (toto je jenom jiná forma sledování nákladů)
závislý outsourcing, kdy zákazník má určitou kapitálovou účast ve společnosti
poskytovatele, která je samostatným právním subjektem, např. dceřiná společnost
nezávislý outsourcing, kdy se jedná o spolupráci dvou samostatných firem, jejichž
vztah je vymezen smlouvou
Pro racionální a efektivní využití outsourcingu je potřeba velmi pečlivě zvážit a
definovat předmět a rozsah externích služeb, uvážlivě provést výběr kvalitního poskytovatele
a provést zavedení externí služby jako promyšlený projekt.
9 Navrhování projektů řídicích systémů
9.1 Projektové řízení
Návrh a zavedení automatizovaného řídicího systému tak, aby bylo dosaženo
předpokládaných přínosů, je velmi komplikovaný a náročný technicko-organizační problém,
pro jehož řešení se v západním světě používá projektové řízení - Project management
Projektové řízení (angl. termín Project Management) slouží k rozplánování a realizaci
složitých, zpravidla jednorázových akcí, které je potřeba uskutečnit v požadovaném termínu s
plánovanými náklady tak, aby se dosáhlo stanovených cílů.. Stručně můžeme projektové
řízení také charakterizovat jako účinné a efektivní dosahování změn.
Předmětem projektového řízení je projekt, který představuje soubor činností, které je
potřeba naplánovat a provést, aby bylo dosaženo požadovaných cílů.
Cílem projektového řízení je zajistit naplánování a realizaci úspěšného projektu,
kterým se rozumí případ, kdy v plánovaném čase a s plánovanými náklady bylo dosaženo cílů
projektu.
Změna je způsobena realizací výstupů projektu. Obvykle nemůžeme změnu realizovat
přímo, ale předpokládáme, že uskutečnění projektu způsobí realizaci změny.
Projektového řízení vychází z poznání, že jakmile rozsah, neobvyklost, složitost,
obtížnost a rizikovost projektu přesáhnou určitou míru, je nutno použít adekvátních metod pro
řízení celé akce.
Kromě toho další dva principy, které využívá projektové řízení jsou:
- princip týmové práce, kdy společnou prací rozličných specialistů lze vyřešit i velmi
složité problémy
- princip systematické práce, která je podložena exaktními metodami.
Projektové řízení důsledně využívá na systémového přístupu k řešení problémům, kdy
se věci a jevy zvažují ve vzájemných souvislostech. Přitom se postupuje od globálních cílů k
detailním činnostem (postup shora dolů - TOP DOWN), systematicky a strukturovaně (velký
problém se rozdělí na řadu menších problémů, které se snadněji řeší - Divide et impera!).
Proto projekt má být vždy komplexní a zachycovat všechny podstatné rysy realizace změny.
Současné projektové řízení používá pro svou podporu specializované programy patřící
do skupiny software CIP (Computer in Projects), které umožňují využít výpočetní mohutnost,
paměťovou kapacitu a komunikační možnosti současných počítačů k usnadnění aplikace
metod projektového řízení.
Pro projektové řízení jsou zvláště vhodné následující problémy, typické pro návrh a
realizaci projektů:
- vývoj nových výrobků
- inovace a rekonstrukce výrobků
- zavádění nových technologií
- zavádění nových výrobků do výroby a na trh
- návrh a realizace investičních akcí
- návrh a realizace stavebních akcí
- návrh a realizace informačních systémů
- tvorba programových produktů
- návrh a realizace automatizovaných systémů
- zavádění systémů řízení jakosti podle ISO 9000
- příprava marketingových akcí
- zpracování podnikatelských záměrů
- generální opravy strojů
- plán a realizace reorganizace firmy
- realizace podnikatelských záměrů
- příprava a realizace zakázek v kusové výrobě
- atd.
Pokud firma takové akce připravuje nebo realizuje a má problémy s dodržováním
jejich TERMÍNŮ, NÁKLADŮ a s čerpáním disponibilních ZDROJŮ při jejich realizaci, nebo
je častým jevem, že se nedosahuje předpokládaných CÍLŮ, pak to může být právě proto, že
nepoužívá projektového řízení.
Kdy naopak není vhodné používat projektového řízení!
Jedná-li se o periodicky opakované činnosti např. operativní plánování výroby,
periodické prohlídky strojů, každodenní kontrolní činnosti apod. je pro tyto případy lépe
použít jiné formy řízení (např. řízení podle odchylek, extremální řízení, programové řízení,
apod.). Projektové řízení se také nehodí na jednoduché, bezrizikové akce, na které stačí rutina
nebo tzv. selský rozum (k ohřátí večeře pro osamělé manžele není potřeba aplikovat
projektové řízení, ale uspořádání svatební hostiny pro 80 účastníků bez základních znalostí
řízení velkých akcí už může přinést řadu komplikací). Projektové řízení není vhodné používat
v mimořádných situacích (technické katastrofy, živelné pohromy, bezprostřední válečné
operace, firemní a jiné krize). Pro takové případy jsou k dispozici jiné specializované postupy
(např. krizový management). Pro aplikace projektového řízení nejsou vhodné příliš
dlouhodobé akce, přesahující období dvou let. Projektové řízení se těžko prosazuje v
podmínkách, kde vládne bezradnost, chaos, emoce a převládá nevzdělanost.
Projektové řízení patří v západních zemích ke standardnímu způsobu práce úspěšných
firem a západní management považuje znalosti projektového řízení za nedílnou součást
dovednosti řídicích i řadových pracovníků.
U nás je bohužel projektové řízení zatím poměrně málo známé. Proto řada důležitých
akcí v našich podnicích probíhá neúspěšně. Navíc mají naše firmy potíže při komunikaci a
spolupráci se západními firmami, kde je projektové řízení velmi rozšířené a běžně používaní.
V České republice působí Společnost pro projektové řízení, která je českým národním
členem mezinárodní společnosti IPMA - INTERNATIONAL PROJECT MANAGEMENT
ASSOCIATION, jenž se svými 25-ti národními organizacemi se snaží podporovat rozvoj a
využívání projektového řízení v Evropě, proto nabízí kurzy, semináře a specializované
instruktáže našim podnikům o projektovém řízení ( www . ipma . ch ).
Cíle aktivit SPR jsou v souladu s působením IPMA následující:
- Vysvětlit základní pojmy a principy projektového řízení
- Vytvořit odborné názvosloví
- Popsat používané metody a techniky projektového řízení
- Specifikovat náplň činnosti profese projektový manager a zajistit certifikaci projektových
managerů
- Presentovat programové produkty pro počítačovou podporu projektového řízení
- Ukázat možnosti a přínosy projektového řízení
- Pomoci při zavádění projektového řízení do praxe našich podniků a institucí
- Poradit při řešení problémů, které se vyskytnou při aplikaci projektového řízení
- Umožnit vzájemnou výměnu zkušeností našich i zahraničních pracovníků
- Zajistit sledování nových světových trendů v oblasti projektového řízení.
Kontaktní adresa Společnosti pro projektové řízení je: Společnost pro projektové řízení,
Příkop, P.O.B. 55 , 604 55 Brno. Společnost má regionální skupiny členů v Brně a Ostravě.
Členství ve Společnosti je jak pro individuální fyzické osoby, tak pro korporativní (určeno
právnickým subjektům).
Přehled znalostí projektového managera podle IPMA
International
Project
Management
Association
ICB
IPMA Competence Baseline
Version 2.0
28 Core Elements
28 Jádro věci
1 Projects and Project Management
2 Project Management Implementation
3 Management by Projects
4 System Approach and Integration
5 Project Context
6 Project Phases and Life Cycle
7 Project Development and Appraisal
8 Project Objectives and Strategies
9 Project Success and Failure Criteria
10 Project Start Up
11 Project Close Out
12 Project Structures
13 Content, Scope
14 Time Schedules
15 Resources
16 Project Cost and Finance
17 Configurations and Changes
18 Project Risks
19 Performance Measurement
20 Project Controlling
21 Information, Documentation, Reporting
22 Project Organisation
23 Teamwork
24 Leadership
25 Communication
26 Conflicts and Crises
27 Procurement, Contracts
28 Project Quality
1 Projekty a řízení projektu
2 Zavádění projektového řízení
3 Řízení prostřednictvím projektů
4 Systémový přístup a integrace
5 Kontext projektu
6 Průběh projektu
7 Zhodnocení projektu
8 Záměry a strategie v rámci projektu
9 Kritéria úspěšnosti projektu
10 Zahájení projektu
11.Ukončení projektu
12 Definování a struktualizace prací
13 Obsah, rozsah
14 Plánování termínů
15 Plánování zdrojů
16 Plánování nákladů a financování
17 Konfigurace a změny
18 Rizika v rámci projektu
19 Kontrola plnění
20 Projektový controlling
21 Informace, dokumentace, zpravy
22 Organizace projektu
23 Týmová práce
24 Vedení
25 Komunikace
26 Řešení sporů a krize
27 Procurement
28 Jakost projektu
14 Additional Elements
29 Informatics in Projects
30 Standards and Regulations
31 Problem Solving
32 Negotiations, Meetings
33 Permanent Organisation
34 Business Processes
35 Personnel Development
36 Organisational Learning
37 Management of Change
38 Marketing, Product Management
39 System Management
cyklus
40 Safety, Health and Environment
41 Legal Aspects
42 Finance and Accounting
29 Informatika v projektech
30 Normy a předpisy
31. Řešení problémů
32 Jednání & Vyjednávání
33 Trvalá organizace
34 Firemní procesy
35 Personální rozvoj
36 Vyúka a profesionální rozvoj
37 Řízení změn
38 Marketing
39 Řízení systému, Životní
40 Bezpečnost, ochrana zdraví a
životního prostředí
41 Zákon a projekty
42 Finance a účetnictví
V současné době IPMA novelizovala ICB a tento dokument je k dispozici ve své
3.verzi, která výše uvedené elementy seskupuje do tří podskupin:
• Kompetence konceptuálního chápání souvislostí v projektu
• Kompetence vztahující se k technikám a postupům v projektu
• Kompetence vztahující se k chování a jednání projektového managera.
Poznamenejme, že státy na americkém kontinentu založily PMI - Project Management
Institute, prostřednictvím kterého jsou organizovány aktivity kolem zavádění a využívání
projektového řízení v tomto regionu (www . pmi . org). Tato instituce vymezila rámec
znalostí pro certifikaci projektových managerů v materiálu, který je označován zkratkou
PMBOK (Project Management Body of Knowledge).
Základním nástrojem pro plánování a řízení projektů je síťová analýza, konkrétně
metody CPM (Critical Path Method), PERT (Program Evaluation and Review Technique) a
MPM (Metra Potential Method). Metody síťové analýzy slouží k plánování času, nákladů a
zdrojů. V poslední době se prosazuje nová metoda kritického řetězce (Critical Chain)
prof.Goldratta, založená ne teorii omezení. Pro zahajování projektů je často používána metoda
logického rámce (Logical Frame Method) a technika řízení podle cílů MBO (Management
by Objectives). Při navrhování, ale hlavně k prezentaci časového průběhu činností projektu se
používají Ganttovy diagramy. Ke zjištění potenciálních překážek úspěšnosti projektu se
aplikují vybrané postupy pro analýzu rizik z rizikového inženýrství (Risk Engineering) např.
RIPRAN(Risk Project Analysis), FRAP (Facility Risk Analysis Process) a pro zjištění
podpory úspěšnosti projektu se aplikuje metoda analýzy kritických faktorů úspěchu CSFA
(Critical Success Factor Analysis) a technika Ishikawových diagramů. Vyhodnocování stavu
projektu a k sestavení predikce jejich vývoje se používá metoda analýzy dosažené hodnoty
(Earned Value Analysis) nebo metoda SSD grafů (Structure-Status-Deviation). Ke snížení
nákladů na projekty se používají různé modifikace hodnotové analýzy (Value Analysis) a
nákladového controllingu. Pro úspěšné zvládnutí týmové práce se používají různé formy
porad (walkthroughs), metody skupinového řešení problémů (brainstorming, Dehphi,
Occam´s Razor). Výčet není a nemůže být úplný, protože projektové týmy používají řadu
speciálních metod pro řešení specifických problémů.
Kromě základních metod projektového řízení je samozřejmě používána celá řada
dalších metod systémové a operační analýzy: metody pro podporu rozhodování, procesní
modelování, počítačová simulace projektů, apod.
Téměř všechny metody jsou dnes podporovány počítačovými programy s vysokým
stupněm uživatelské přívětivosti, s relativně snadnou obsluhou a s rozsáhlými možnostmi
rozličných grafických barevných výstupů pro potřeby pracovníků projektového týmu a
dalších účastníků prací na projektu. Velmi rozšířené jsou takové produkty jako PROJECT
PLANNER od firmy Primavera, MS Project firmy Microsoft , Super Project firmy Computer
Associates, Power Project od firmy Asta Development, TIME LINE od firmy Symantec a
další. Projektové řízení využívá nejen výše uvedených specializovaných produktů, ale i
současných transakčně orientovaných automatizovaných informačních systémů pro podporu
manažerských aplikací.
Současná doba vyžaduje, abychom realizovali mnoho změn a velkých akcí ve velmi
krátkých termínech, s limitovanými náklady a omezenými zdroji. Přitom rychlý běh života
současné společnosti nám nedovoluje dosáhnout cílů mnoha opakovanými pokusy. Metoda
pokusů a chyb (Trials and Errors) je v tržním konkurenčním prostředí téměř nepoužitelná,
protože tržní ekonomika nám většinou neposkytne další příležitost k následnému pokusu, byť
i lepšímu.
Ostrá konkurence nutí firmy snižovat náklady a plánované náklady dodržovat.
podobně to platí i o termínech. V české republice, kde zatím nejsou k dispozici velké
tuzemské disponibilní investice, se ještě stále „šetří“ finančními prostředky s následnými
časovými odklady. Ve vyspělých západních zemích je však čas kritickým faktorem úspěchu.
Firma, která např. přijde první na trh, získá tento trh svým výrobkem a další firmy, které dají
výrobek na trh s časovým odstupem, často těžko prosazují svůj výrobek i při nižší ceně.
Projektové řízení představuje pomoc při překonávání problémů, které dnes přináší
klasická liniová hierarchická organizační struktura, která stále ještě převažuje jak u nás , tak v
zahraničí. Jedná se o překonání takových problémů jako:
- dlouhé komunikační řetězce
- časové ztráty při složité komunikaci
- zkreslování při vnitrofiremní komunikaci
- výskyt ping-pongového efektu (problémy se neřeší, ale přehazují „přes zeď“ jiným
oddělením).
Týmová práce a propracované metody projektového řízení umožňují realizovat rychlý
vývoj i složitých výrobků nebo realizovat složité akce, které jim následně mohou přinést
rozhodující konkurenční výhodu. Mnohé progresivní západní firmy reorganizovaly svoje
dosavadní organizační struktury na projektové struktury nebo maticové struktury a spolu s
definováním firemních projektů přešly na způsob řízení označovaný jako Management by
Project - řízení podle projektů.
Současná turbulentní doba, plná překotných změn, způsobuje, že klasická regulace
firemních procesů podle vzniklých odchylek již nevyhovuje. Cílené dosahování změn
prostřednictvím projektového řízení je právě ta možná alternativa, která tento problém řeší.
Projektové řízení je nástrojem k realizaci moderního způsobu řízení MBO (Management by
Objectives) - řízení podle cílů.
V řadě případů, velké mezinárodní projekty, nákladné státní akce, speciální zakázky
pro kosmický výzkum nebo obranu lze dokonce v mnoha případech (v západních zemích)
získat jen poté, co firma prokáže schopnost kvalitního projektového řízení.
Západní svět považuje znalost projektového řízení za standardní znalost, kterou
potřebuje mít vedoucí pracovníky a používání projektového řízení považuje za osvědčenou
praktiku (Best Practice), kterou úspěšné firmy používají pro zajištění dobré konkurenční
schopnosti. Je to i problém terminologický, t.j. aby naše formy se dokázaly úspěšně zapojit do
nové mezinárodní spolupráce.
Pokud naše firmy chtějí uspět na globálním světovém trhu, ba už i evropském trhu,
musí se naučit dobře používat projektové řízení.
Samozřejmě by mělo být projektové řízení zaváděno ve firmě jako projekt, správně
připravený a dobře řízený.
Velmi důležitá je zde podpora vrcholového vedení firma, přesvědčení vedení firmy o
účelnosti projektového řízení a odhodlání všech vedoucích úspěšně zavést projektové řízení
ve firmě do každodenní praxe.
Měli bychom dát přednost profesionálnímu přístupu k projektovému řízení před
amatérským přístupem. Proto základem by mělo být vyškolení všech zaměstnanců firmy, ať
vedoucích nebo řadových pracovníků, v certifikovaných kurzech, ve kterých by absolventi
získali příslušné vědomosti, ztvrzené certifikátem.
Zavedení projektového řízení je potřeba podpořit po stránce organizační (podniková
směrnice o vyhlašování, navrhování a řízení firemních projektů a jejich dokumentování),
materiální (zřízení místností pro práci týmů), publikační (účelové publikace, odborné
časopisy), účastí na odborných kongresech, apod.
Velmi významným krokem je zakoupení pečlivě vybraného počítačového produktu
pro podporu projektového řízení připojeného do počítačové sítě, pro který je potřeba
zorganizovat vyškolení všech uživatelů v jeho obsluze a zakoupit jej pro každodenní
používání.
Firma by měla účelně využít různých poradenských firem k překonání případných
problémů a úskalí při zavádění a používání projektového řízení včetně spolupráce a akcí
Společnosti pro projektové řízení.
•
•
Aplikace projektového řízení přináší pro praxi našich firem a institucí řadu přínosů:
Zvýšení jistoty v dosahování cílů (Snížení rizika neúspěchu při dosahování cílů)
Snížení nákladů na firemní akce
•
•
•
•
•
Úsporu vynaložené námahy
Možnost lepšího dorozumění se západními firmami
Příležitost podílet se na zahraničních zakázkách a projektech
Zpřístupnění zahraničních půjček
Připravit firmu na certifikaci z hlediska aplikace projektového řízení
• Zkrácení termínů firemních akcí
Projektové řízení je také velmi vhodný nástroj k zavedení systémů řízení jakosti a
k dosažení vysoké jakosti ve firmě. Přechod od stávající jakosti k jakosti ve smyslu
požadavků TQM tak, je jakost definuje a vyžaduje soubor norem ISO 9000 je natolik velkou
změnou pro naše firmy, že bez využití projektového řízení představuje snaha o jakost velké
riziko neúspěchu. Proto ČSN/ISO 10 006 nás nabádá, abychom projektové řízení jako nástroj
k dosažení vysoké jakosti použili. Navíc nám tato norma vymezuje procesy při řízení
projektu, které musíme správně navrhnout a řídit, abychom projektové řízení prováděli
jakostně, a celý průběh projektu tak zajistil jeho úspěšné zakončení. Na uvedenou normu
navazuje norma ČSN/ISO 10 007, která popisuje, jak zajišťovat provádění změn v projektu.
Našim firmám rozhodně nechybí technická invence a dovednost. V jistotě dosahování
naplánovaných cílů však zaostávají za progresivními západními firmami.
Chtějí-li zvýšit svoji konkurenční schopnost před vstupem naší republiky do EU, pak
zvládnutí moderního projektového řízení je nutným předpokladem a dobrým začátkem.
Terminologická poznámka:
Po přečtení výše uvedeného textu by měl čtenář být schopen rozlišit mezi pojmy návrh a
projekt. České slovo projekt má totiž širší význam ve srovnání s anglosaskou terminologií.
Proto v českém regionu používáme často termín projekt tam, kde západní odborníci používají
termín návrh. V řadě našich odvětví se termínem projekt myslí stoh výkresové dokumentace
Pro snadnější orientaci je v příloze uvedeno schéma, ukazující obsah těchto pojmů.
.
Specifikace a výpočet
technicko-ekonomických
parametrů
Nalezení technického řešení
jednotlivých funkcí
NÁVRH (Design)
Specifikace nakupovaných prostředků
Výběr použitých technologií
Konstrukce atypických
prvků a prostředků
Vypracovaní technické dokumentace
(výpočty, výkresy, kusovníky, technické
zprávy, náčrtky, popisy)
Stanovení účelu a cílů
projektu včetně analýzy přínosů
Nalezení činností pro realizaci projektu
Naplánování spotřeby času pro jednotlivé
činnosti a dílčích nákladů na činnosti
PROJEKT (Project)
Stanovení časového průběhu činností
Určení KDO?, KDY?, CO?, JAK? provede
a zjištění, jaké prostředky je potřeba
mít k zajištění jednotlivých činností
Stanovení rizik a nalezení
opatření ke snížení rizika
Realizace a řízení
plánovaných činností
Často (ponejvíce v oblasti stavebnictví ) se pojem projekt, ztotožňuje se složkou
výkresové dokumentace.
9.2 Základní pojmy a principy
Uveďme přehled nejdůležitějších pojmů projektového řízení, jak jsou vymezeny
v normách ISO nebo v ICB.
Projekt ( podle ISO 10 006 ): 3.1 projekt: jedinečný proces sestávající z řady
koordinovaných a řízených činností s daty zahájení a ukončení, prováděný pro dosažení cíle,
který vyhovuje specifickým požadavkům, včetně omezení daných časem, náklady a zdroji
Atributy projektu:
• Jedinečnost v cíli a postupu
• Vymezenost v časem, rozpočtem a zdroji
• Řízení projektovým týmem
• Složitost a komplexnost
• Rizikovost
Akce, které mají tyto znaky by měly být realizovány jako projekt, pokud neexistují
zvláštní důvody, aby jako projekt realizovány nebyly. Akce, které tyto znaky postrádají,
nemají být realizovány jako projekty.
Cíl (cíle) představuje koncový stav po ukončení projektu. Cíl nemůžeme dosáhnout
přímo. Proto realizujeme projekt, abychom postupnou realizací naplánovaných činností
navodili z výchozího stavu stav cílový:
CÍL
Cílový stav
Výchozí (současný) stav PROJEKT
Často si stanovujeme dílčí, postupové cíle: Milníky (Milestones):
Výchozí stav ⇒ 1. milník ⇒ 2. milník ⇒ …..⇒
⇒ Cílový stav
kde symbol ⇒ představuje soubor činností, které vedou k dosažení dílčího, postupového cíle.
Proto milníky v projektu představují vždy významné události v projektu. Poznamenejme, že
výstižně lze cíl označit jako myšlením předjímaný výsledek.(Knössel). Proto se musíme
snažit, abychom v rámci projektu dosáhli společných, shodných představ o cíli projektu u
všech zainteresovaných stran.
Obsah projektu (Content) je představován souhrnem činností, které se váží ke
konkrétnímu výstupu projektu. Je definován procesem k dosažení cílového stavu
Rozsah projektu (Scope) stanovuje, co vše bude do projektu zahrnuto resp. co nebude
součástí projektu.
Zákazník projektu představuje zainteresovanou stranu, které u určen výstup projektu.
Kriteria úspěšnosti projektu jsou kriteria, podle nichž lze posuzovat relativní
úspěšnost či neúspěšnost projektu. Hlavním požadavkem je jejich jasné a jednoznačné
definování. Pro každý projekt a zákazníka se nově stanovují a vyhodnocují kriteria úspěšnosti.
Projekt je formulován, hodnocen, vytvořen a realizován v rámci svého kontextu
(prostředí), kterým je přímo či nepřímo ovlivňován. Veškeré tyto vlivy, jako jsou normy,
trendy apod. působí na koncepci a vývoj projektu. Příkladem externích vlivů jsou
geofyzikální, ekologické, sociální, psychologické, kulturní, politické, ekonomické, finanční,
právní, kontraktační, organizační, technologické a estetické aspekty.
Zainteresovaná osoba jsou osoby nebo skupiny osob, které se podílí na projektu, jsou
zainteresované na provedení projektu, nebo mají nějakou vazbu na projekt. Mají právně
zaručený zájem na úspěšnosti organizace a na prostředí, v němž tato organizace funguje.
Příkladem zainteresovaných osob jsou zákazník, kontraktor, vedoucí týmu, členové týmu,
výsledný uživatel, propagátoři, rezidenti, skupina se společným zájmem, tisk, správní orgány,
banka.
Řízení projektu je plánování, organizování, sledování a kontrola všech aspektů
projektu a motivování veškerého zainteresovaného personálu k dosažení záměrů projektu při
dodržení bezpečnostních hledisek a v dohodnuté lhůtě, za dodržení nákladů a kriterií
z hlediska plnění. Zahrnuje celkový objem úkolů vedení, organizace vedení, postupů vedení a
opatření vedení za účelem realizace projektu.
Činnosti jsou představovány elementárními plánovanými pracemi, jejichž realizace
má zajistit dosažení cílového stavu.
Celkový průběh projektu, který vždy obsahuje velkou řadu činností, můžeme rozdělit
jejich seskupením do jednotlivých fází. Hovoříme že v projektu rozlišujeme na „životní fáze
projektu“.
Fáze projektů dále seskupujeme do tří skupin:
• Předprojektové fáze (Pre-Project Phases): Studie příležitosti (Opportunity Study),
Předběžná studie proveditelnosti ( Pre-Feasibility Study), Studie proveditelnosti
(Feasibility Study), Studie financování a nadějnosti (Investment Study) – pokud není
zahrnuta do studie proveditelnosti. Často jsou tato fáze nahrazeny (většinou z časových
důvodů) tzv. předprojektovými úvahami.
• Projektové fáze (Zahájení projektu, Podrobný plán projektu, Implementace projektu,
Ukončení projektu)
• Vyhodnocovací fáze (Post-Project Phases): Analýza ukončeného projektu (Post
Implementation Analysis) a Zpracování návrhů na zlepšení příštích projektů
9.3 Zahajování projektů
Zahájení projektu je první fází, životního cyklu projektu. V tom je její specifické
postavení. Není možné říci, že by tato fáze byla nejdůležitější. Všechny fáze jsou pro úspěšný
projekt důležité a celková jakost projektu je dána úrovní fáze s nejnižší jakostí podle zásady
nejslabšího článku řetězu.
Cílem zahájení projektu je na odpovídající řídicí úrovni deklarovat (vyhlásit) projekt
definováním základních atributů vymezujících projekt.
Znamená to definovat:
• Formální a organizační náležitosti (název, identifikační číslo, klasifikační znaky)
• Cíl (resp.cíle) projektu s ohledem na účel, potřeby zákazníka a očekávané přínosy
• Plánovaný termín začátku projektu
• Plánovaný termín ukončení projektu, případně také významné plánované milníky
• Plánované celkové náklady na projekt
• Jmenovat projektový tým a jeho vedoucího
Vstupy a výstupy fáze
Vstupem pro zahájení projektu jsou:
• dokumenty, které byly vytvořeny v předpojektových fázích
• dokumenty popisující problematiku, kterou má projekt řešit
• standardy, které má projekt splňovat
• výsledky vyhodnocení minulých projektů
• jiné dokumenty, shrnující požadavky na projekt z hlediska zainteresovaných stran.
•
•
•
•
•
Výstupy z fáze zahájení projektu jsou:
Identifikační listina projektu (též základní listina projektu) dále jen ILP
Logický rámec, dokumentující základní vztahy v projektu a vazby na projekt
Seznam hrozeb (podklad pro následnou celkovou analýzu rizik)
Návrh kritických faktorů úspěchu projektu (CSFA-Critical Success Factor Analysis)
Pracovní průvodní dokumentace, zaznamenávající činnosti při zahájení projektu
Nejdůležitějším dokumentem je IPL. Její forma není přesně stanovena. Všeobecně je
možno říci, že by měla obsahovat všechny významné atributy projektu a další důležité
informace, které mají zásadní význam pro další fáze projektu. Pracovní skupina může
návrh ILP připravit podle nějakého vhodného vzoru , pokud není stanoveno jinak.
Jakostní firmy mají formu a obsah ILP definovánu firemní směrnicí. Pak je nutno
tento dokument vypracovat podle příslušné směrnice.
V případech, kdy se jedná o projekty, které mají být financovány z prostředků
národních nebo mezinárodních programů a grantů, je potřeba IPL zpracovat ve formě
přihlášky resp. žádosti, jejíž forma a obsah jsou přesně stanoveny např. i včetně použitého
jazyka, počtu předkládaných kopií a jiných náležitostí.
Příklad IPL projektu menšího rozsahu uvádí dále.
Zahájení projektu začíná jmenováním pracovní skupiny, která by měla připravit
potřebné dokumenty. Pracovní skupina by měla být jmenována tak, aby tvořila základ
pozdějšího projektového týmu (nebo aby v ní byli účastni alespoň někteří členové
projektového týmu). Zejména je žádoucí, aby v ní byl následně jmenovaný vedoucí projektu
Skupina by měla prostudovat dostupné materiály a připravit návrh ILP nejlépe tak, že
nejprve aplikuje metodu logického rámce a zpracuje logický rámec projektu. Poté vypracuje
další materiály, které předloží ke schválení na příslušné úrovni.
Okamžiku schvalování by měl být přítomen skupinou pověřený zástupce (pokud se
nemůže jednání zúčastnit celá skupina), aby mohl obhájit předložený návrh případně tlumočit
námitky zbývajícím členům skupiny, pokud bude nutno materiály upravit.
Fáze končí schválením IPL a poskytnutím informace všem zainteresovaným stranám o
zahájení projektu.
Doporučené a také nejpoužívanější metody v předprojektových fázích a při zahajování
projektů jsou:
Metoda logického rámce
Analýza silných a slabých stránek (SWOT Analysis)
Technika SMART(i)
SLEPT analýza
Porterova analýza
Analýza stran dotčených projektem
Strom cílů
Strom problémů
V ČR se nejvíce rozšířila metoda logického rámce (Logical Framework Method), která
patří do skupiny kombinovaných metod a prosazuje ji i EU pro návrhy projektů v rámci
programů strukturálních fondů. Metoda vytváří logický rámec ze 16 polí, uspořádaných do
čtyř sloupců a čtyř řádků, kam se vypisují logicky provázané skutečnosti, které mají jakostně
popsat důležitá fakta, použitá jednak pro identifikační listinu projektu, jednak jako vstupní
informace pro další fáze projektu.Metoda popisuje postupné kroky při vytváření logického
rámce i formu týmové práce při jeho sestavování. Metoda používá techniku kontrolních
seznamů (CHECKLISTS) pro zajištění jakosti navrženého logického rámce.
Název projektu
Popis projektu
Objektivně
ověřitelné
ukazatele
Způsob ověření
Předpoklady
Cíle
Účel
Konkrétní
výstupy
Projektu
Klíčové činnosti
Zajištění jakosti fáze zahájení projektu musí být v souladu s celkovým systémem
řízení jakosti projektu, který by měl být zpracován podle ISO 10006 v souladu s normou ISO
9004 Management jakosti a prvky systému jakosti.
Zde budou pouze uvedeny hlavní náměty pro zajištění jakosti:
• Vyškolení pracovní skupiny pro zahajování projektů
• Vyškolení příslušných vedoucích, pro zahajování projektů
• Prověření správnosti, platnosti a úplnosti všech vstupních podkladů, které mají být
použity pro zpracování výsledných dokumentů
• Prověření všech výstupních dokumentů před jejích schválením
•
Definováním postupu při fázi zahajování projektů a jeho dodržování
Poznamenejme, že významným způsoben může zkvalitnit IPL posouzení nezávislými
experty a jakostní průběh schvalovacího řízení (vnitřní oponentura ) IPL.
Hovoříme-li o cíli (resp. cílech) projektu, není od věci připomenout, že existuje
významné paradigma∗ řízení - řízení podle cílů (Management by Objectives, Goal
Management).
Není zde účelem podrobně rozebírat řízení podle cílů (zájemce najde k tomu
dostatek jiné literatury, dnes již i u nás). Má být jen zdůrazněn jeho význam při zahajování
projektů.
Řízení podle cílů řeší zejména takové otázky jako:
- hierarchii cílů, tj. postupnou dekomposici strategického cíle na
taktické a operační cíle
- otázky priority cílů
- problematiku specifikaci cílů
- účelnost cílů
- reálnost cílů
- vyhodnocování dosažených cílů
- vztah cílů k přijatým hodnotám
- formy řízení při dosahování cílů
- apod.
Proto by se vedoucí pracovníci a členové projektových týmů měli seznámit s principy
a zásadami tohoto způsobu řízení a plně ho využít jak při zahajování projektů, tak při řízení
projektů samotných.
Jedno staré rčení říká: „Je často snadnější stanovit si cíl, než pak nalézt cestu k jeho
dosažení“. To ostatně známe z mnohých našich novoročních a jiných předsevzetí.
Při zahajování projektu se zabýváme především CÍLEM. Teprve další fáze životního
cyklu se podrobně zabývají návrhem jednotlivých na sebe navazujících činností, které mají
navodit příslušnou změnu a dosáhnout tak stanovený cíl. Nemáme-li cíl, pak můžeme jen
bloumat jak Alenka v kraji divů. *1
U jednodušších, krátkodobých projektů je možno připustit zjednodušený přístup k
zahajování projektu, že je potřeba stanovit cíl, plánovaný termín a plánované náklady, a že
vše ostatní je záležitost projektového týmu a dalších fází projektu. Obvykle i stanovení všech
těchto zmíněných věcí nedělá zásadní problémy.
V případě složitých, dlouhodobých a nákladných projektů, to však není zřejmě ten
správný přístup k jejich jakostnímu zahajování.
Ten, kdo stanovuje cíl, by neměl zapomenout na skutečnost, že dostat se k cíli cesty je
možno jen z nějakého výchozího stanoviště. Nachází-li se člověk ve vestibulu hlavního
vlakového nádraží v Praze, pak případný cíl - Václavské náměstí - je zcela blízko, dá se
dosáhnout snadno pěšky, v průběhu patnácti minut, vlastně skoro zadarmo. Má-li tentýž cíl
cesty člověk, nacházející se na horské chatě v Krkonoších, musí dotyčný počítat s několika
hodinami, nalézt vhodný dopravní prostředek, jehož použití ho bude v běžné situaci stát
1
„Řekla bys mi, prosím, kudy se dostanu odtud?“ zeptala se Alenka. „Záleží na tom, kam se chceš
dostat,“ řekla kočka. „To je mi jedno kam!“ řekla Alenka. „Pak je jedno, kudy půjdeš,“ řekla kočka. „Jen když
se někam dostanu ,“ vykládala Alenka. „To se jistě dostaneš,“ řekla kočka, „jen když půjdeš dost dlouho.“
kolem dvě stě korun. Oba mají stejný cíl, ale každý má jinou výchozí posici k jeho dosažení.
*2
Při zvažování cílového stavu by proto analýza současného stavu neměla chybět!
Zejména ne u komplexních projektů!
Specifikace současného stavu je samozřejmě důležitá i z hlediska určení cesty k cíli.
Pokud se vás někdo v Brně zeptá: „Jé, vy znáte Prahu! Jak se dostanu v Praze na
Václavské náměstí?“, nezbude Vám nic jiného, než se ho zeptat, jaké předpokládá v Praze
svoje výchozí stanoviště. Zda již zmíněné hlavní vlakové nádraží, autobusové nádraží na
Florenci, letiště v Ruzyni, či nějaké jiné místo.
Známe-li cíl a výchozí posici, můžeme začít diskusi o cestě k cíli.
K cíli však vede velký počet cest! Chybou našich firem je, že často mimoděk
předpokládají jen jednu - nejkratší, nejlacinější a nejsnadnější, aniž by vedoucí pracovníci
uvědomili úskalí takových cest (V pohádkách snadné a lákové cesty vedou obvykle do pekla
nebo k jinému zatracení).
Představa, že se nám podaří pro dosažení cíle nalézt ty nejzdatnější, nejkvalitnější a
nejvýkonnější firmy a pracovníky, kteří budou požadovat za svoji vysoce kvalitně odvedenou
práci ty nejnižší ceny a mzdy je sice možná, ale málo pravděpodobná. Daleko
pravděpodobnější je, že cesta bude muset být kompromisem mezi rychlostí dosažení cíle a
náklady. Dále, jistě každý zná staré české přísloví: Za málo peněz, málo muziky. Přitom na
toto přísloví zapomínají zejména typičtí čeští manažeři, mající hluboko do své podnikatelské
kapsy, ale požadující doslova zázraky za 100 Kč, ještě lépe však za 2 koruny 50 haléřů. Svoje
požadavky zdůvodňují jednou tvrzením, že jsou zákazníci, kterým se musí vyhovět, jindy
zdůrazňováním, že jsou svrchovaní majitelé, kterým se musí vyhovět.
Při zahajování projektu je nutno si uvědomit, že jestliže pro dosažení cíle určuji
náklady a/nebo čas, do jisté míry určuji i strategické rozhodnutí o realizaci cesty.
Jestliže např. podnikatel, který právě založil firmu na výrobu motorových sekaček,
potřebuje na trhu urychleně začít prodávat své výrobky, pak by asi neměl čekat než mu jeho
nově najmutí konstruktéři firemní sekačku vyvinou, ale začít nejprve prodávat nějakou
sekačku, pro jejíž výrobu zakoupí licenci. Nemá-li finanční prostředky na zakoupení licence,
je potřeba pro výrobu získat zakázky na kooperaci při realizaci součástkové základny pro jiné
firmy v regionu a přiměřenou dobu počkat na vývoj vlastního výrobku, jehož konstrukci bude
financovat např. jednak ze zisku výroby součástek, jednak půjčkou ze státního fondu Pharefix
rozvoje nových výrobků. To jsou však strategická rozhodnutí! Ta nemohou být ponechána na
2
Příklad zde uvedený může vyvolat shovívavý úsměv a odkaz na trivialitu závěru.
Autor se však stále setkává s případy, kdy firma na nákup svého informačního systému
naplánuje 5mil. Kč a očekává jeho zavedení za 6 měsíců jen proto, že konkurence ho pořídila
za tyto peníze a čas, a konkurence je firma přeci stejně velká, vyrábějící tytéž výrobky, a my
chceme tentýž informační systém jako oni.. Že „etalonová“ firma má již před několika lety
zaveden informační systém se sálovým počítačem, že za dobu jeho prosazování zavedla v
datech a firemních činnostech potřebný pořádek, že nashromáždila příslušná data pro
rozhodování, atd., zatímco oni mají všude jen papírové doklady a v nich zmatek a nepořádek,
takže výchozí pozice obou firem pro nasazení 50 počítačů PC v síti LAN a jedním
počítačovým serverem IBM je jiná, to zřejmě dotyčným pracovníkům uniká (přitom se rádi
označují jako Decisionmakers, Chief Ececutive Officers, Top Managers, apod.). Autorovi
totéž potvrdila řada pracovníků poradenských firem pracující v oblasti jakosti: Při zavádění
jakosti podle norem ISO 9000 v Německu a u nás, mají naše podniky úplně jinou (bohužel
nevýhodnější) výchozí pozici, a přitom plánují dosažení cíle v kratší době a s daleko nižšími
náklady.
projektovém týmu! Strategická rozhodnutí jsou záležitostí vrcholového vedení! Projekt musí
být zahájen tak, aby na projektovém týmu zůstala jen operační rozhodnutí (to udělá Franta
Kolísko dnes, tamto Jirka Šroubek zítra, apod.) a snad některá, přesně vymezená, taktická
rozhodnutí (rozhodnutí, který z těch 6 nabídnutých motorů se zamontuje do výrobku, jenž
mají v důsledku konkurenční soutěže stejnou cenu a podmínky dodávky, se provede v rámci
projektu podle návrhu konstrukce).
Bohužel česká skutečnost je taková, že podnikatel z výše uvedeného příkladu, zahájí
projekt sekačky tak, že nová sekačka zcela originální konstrukce se špičkovými parametry
lepší než mají konkurenti (aby se dobře prodávala) včetně motoru se vyvine do tří měsíců se
zmíněnými čtyřmi minulý měsíc nastoupivšími mladými konstruktéry (čerstvými absolventy)
přijatými po škole proto, že se jim mohl dát nízký nástupní plat a ten - přesněji 4x3=12
měsíčných platů - vlastně činí jedinou uvažovanou položku v nákladech na projekt kromě
běžné režie na spotřeby kancelářských potřeb (rychlovazače z PVC na vyvázání očekávané
technické dokumentace + náklady na její kopírování). Že projekt dopadne neúspěšně není
potřeba podrobně rozebírat.
Při zahájení projektu je potřeba také posoudit jeho prioritu vůči jiným - nepřijatým
projektům. To při velkém počtu možných projektů a omezených finančních možnostech může
znamenat opět problém, jehož řešení by mělo být objektivizováno např. pomocí exaktních
metod operačního výzkumu .
Z výše uvedeného vyplývá, že rozhodující zodpovědnost za jakostní zahájení projektů
má především vrcholové vedení firmy. To by si měli uvědomit všichni manažeři, kteří
identifikační listiny projektů podepisují, ale zejména ti, kteří projekty lehkomyslně vyhlašují
slovně nebo jen dvouřádkovým zápisem o uložení úkolu zahájení projektu na své poradě.
Současná turbulentní doba, plná mnoha velkých a často protichůdných změn, si
vyžaduje vzít v úvahu existenci možných změn hned na začátku projetu.
Mýlí se ten, kdo předpokládá, že jednou stanovený cíl může fixovat jako neměnný a
jednou stanovenou cestu k němu za jedině možnou. Opak je pravdou! Proto je nutno hned od
počátku zajistit neustálé prověřování, zda stanovený cíl projektu je stále ten, ke kterému má
projekt směřovat. Proto je důležité si od začátku také uvědomovat účel, který se má cílem
dosáhnout, a dále vazbu na strategický cíl, ze kterého byl cíl projektu odvozen. Jinak ztratíme
možnost takové prověřování provádět a dospět k nějakým závěrům.
V souvislosti s dynamikou cíle bude vhodné rozlišovat:
-Pohyb cíle (cíl se nemění, ale mění se jeho umístění v prostoru, který je vymezen časem,
náklady a zdroji), což vyžaduje zajistit sledování pohybujícího se cíle. Jsou to okamžiky. kdy
dochází k vnějším požadavkům na:
- změnu plánovaného termínu
- změnu plánovaných nákladů
- změnu požadavků na zdroje
- drobné, nepodstatné změny ve specifikaci cíle
-Změnu cíle (je potřeba se zaměřit na jiný cíl), což vyžaduje přehodnocení cíle a přenesení
pozornosti na tento jiný cíl. Důsledkem takové situace je:
- změna specifikace cíle
- zásadní přehodnocení projektu.
V souvislosti se změnami je potřeba upozornit na další paradigma v řízení - řízení
změn (Change Management), což je další přístup, který by vedoucí pracovníci a členové
projektových týmů měli zvládnout.
Často se setkáváme dnes s dvěma extrémními přístupy k řešení změn:
Odmítání změn - je pošetilý přístup, který kategoricky odmítá jakoukoliv změnu v projektu a
vyžaduje, aby jednou stanovené skutečnosti zůstaly po celou dobu projektu
neměnné.
Závislost na změnách - je opačný přístup, kdy se necháváme zmítat změnami, takže často v
důsledku jejich velkého počtu se původně řízený proces změní v chaos
ve smyslu přísloví: Kam vítr, tam plášť.
Podobnou dynamiku musíme vidět i v souvislosti se zvolenou cestou.
Cestu, z řady možných cest, vybíráme podle kritérií (čas, náklady, nároky na zdroje) a
podle možností (dostupné finanční možnosti, disponibilní zdroje). Proto se musíme stále ptát:
- Nezměnila se kritéria pro výběr cesty?
- Nezměnily se naše možnosti?
- Pokud ano, neměli bychom přehodnotit postup pro zbývající část cesty?
Zahraniční experti se všimli, že v naší republice zahajování projektů není kvalitní.
Řada z nich se vyjadřuje ještě skeptičtěji, když dodává, že chodíme do předem prohraných
bitev.
Na závěr připomeňme jedno německé přísloví, které říká: Lepší strastiplný začátek s
dobrým koncem, než úsměvný začátek se špatným koncem. To je vždycky nutno připomenout
těm vedoucím pracovníkům a členům týmu, kteří se snaží co nejrychleji zahájit projekt a hýří
neodůvodněným optimismem na jeho začátku, aby to byli právě oni, kdo po vyčerpávajícím
průběhu projektu na jeho konci obviňují kde koho, že je vinen neúspěšným projektem, jen ne
sebe sama.
Příklad Identifikační listiny projektu
Název projektu: Y2000 firmy GAMA
Identifikační číslo projektu: I2036/98
Druh projektu: Interní nákladový projekt s externí účastí
Charakteristika projektu: Projekt řeší ochranu firmy před následky chyb technických a
programových prostředků v souvislosti s výskytem číslice roku 2000 v těch programech, kde
jsou uváděny jen dvě poslední číslice roku.
Určení projektu: Projekt má zabránit, aby problémy spojené s Y2K ohrozily provoz a
hospodaření firmy GAMA
Zahájení projektu: Datem vyhlášení projektu
Ukončení projektu: 31.ledna 2000
Plánované náklady na projekt: 800 000 Kč
Projektový tým:
Ing. Borůvka Petr (technický ředitel) - vedoucí projektu
Mgr. Coufal Jan ( Odd. strategického rozvoje) - tajemník projektového týmu
Ing. Dostál František (Odd. informatiky)
Ing. Ebner Vítěslav (zást. dodavatele informačního systému -firma SUPERINFO)
RNDr. Farkaš Radim, CSc ( pracovník konsultační firmy Risk Engineering Consult)
Gregor Zdeněk (Enegetické odd.)
Hála Ivan (Telefonní ústředna)
JUDr. Chvála Jiří (Právní odd.)
Jančová Adéla (Účtárna)
Tabulka milníků projektu:
Schválený návrh projektu
Určena rizika roku 2000
Odsouhlaseny návrhy protirizikových
opatření
Schváleno zabezpečení protirizikových
Opatření
Všechna protiriziková opatření ralizována
Ukončeno vyhodnocení projektu
30.6.1998
30.11.198
20.4.1999
18.6.1999
30.7.1999
25.4.2000
Specifikace cílů projektu: viz přiložený logický rámec
Jiné související pokyny a informace:
1) Inicializace projektu byla schválena na poradě generálního ředitele dne 12.března 1998.
2) Personální odd. uzavře do 15.4. 1998 smlouvu pro poskytování poradenské činnosti
s dr. Farkašem ( 500 Kč/hod)
3) Finanční ředitel zřídí vnitropodnikové účetní konto na projekt a převede na ně
finanční prostředky z rezervního fondu do 31..3.1998
4. Personální odd . uzavře s ing. K. Zamarovským (Project Consulting Olomouc) dohodu o
provedení práce na zpracování oponentského posudku návrhu projektu (5000 Kč) do
15.4.1998. Termín provedení posudku podle pokynů ved. projektu
Dne 16. března 1998
Judr.Kosinka Alois, v.r.
Generální ředitel
9.4 Metoda logického rámce
Metoda logického rámce (Logical Framework Method) je postup, který nám umožňuje
navrhnout a uspořádat základní charakteristiky projektu ve vzájemných souvislostech.
Rozpracovala ji americká firma Team Technologies Inc. Používá se v první fázi práce na
projektu a je praktickou pomůckou pro:
- Organizaci myšlení pracovní skupiny,která realizuje první fázi práce na projektu
- Stručné a přesné vyjadřování
- Stanovení cílů realizace projektu
- Uvedení činnosti a investic do souvislosti s očekávanými výsledky
- Dokumentaci základních charakteristických atributů projektu
- Kritické posouzení návrhu projektu
Metoda logického rámce je podporována počítačem prostřednictvím programového
projektu TEAM Up firmy TEAM Technologies (www.team.cz )
Název metody je odvozen od skutečnosti, že výsledky návrhu jsou přehledně
uspořádány do předem definovaného "rámce",skládajícího se ze čtyř horizontálních polí.
Rámec byl sestaven na základě zjištění, že čtyři úrovně rozlišení obvykle postačují pro
plánování projektu.
Principy metody logického rámce lze shrnout do následujících bodů:
- Plánování ve skupině, jejímž úkolem je zpracovat logický rámec pro projekt
- Při práci ve skupině využít systémového přístupu,který uvažuje jevy ve všech vzájemných
souvislostech
- Důraz na kvalitu návrhu, zajišťovanou využitím kontrolních vazeb, požadavkem názorového
koncensu skupiny a náročnosti práce ve skupině
- Možnost využití počítačové podpory
Metoda logického rámce vychází z několika předpokladů. Základním předpokladem
je teze, že jestliže manažer projektu resp. projektový tým neuvede písemně své měřitelné cíle
v předstihu před startem projektu, není jasné, zda to co se dělá, vede k cíli.
Další,neméně důležité předpoklady je možno stručně formulovat následovně:
- Síla návrhu spočívá v jeho promyšlenosti
- Práce v týmu zaručuje kvalitu návrhu
- Cíle musí být stanoveny jako měřitelné a musí být řečeno jak a kdy budou měřeny
- Nelze jen stanovit soubor činnosti, ale je nutno uspořádat je do správné posloupnosti a
ohodnotit jak se projeví na stanovených cílech
- Jednoznačné vyjádření vazebních hypotéz zdokonaluje návrh projektu
- Předpoklady,týkající se vnějších vlivů, musí být výslovně uvedeny
- Na každé rozlišovací úrovni projektu je potřeba stanovit nutné a postačující podmínky pro
dosažení cíle na nejvyšší úrovni
- Celková logika projektu je vytvářena přibližovacím postupem
- Co můžeme změřit, můžeme i řídit
- Objektivně měřitelných ukazatelů má být minimální množství,postačující ke změření všeho,
co je důležité
- Předpoklady a rizika musí zahrnovat ty podmínky a faktory, které nebyly vybrány k
přímému řízení v rámci projektu
Základní podoba logického rámce je představována následující tabulkou.
Popis
projektu
Cíl/Cíle
Účel
Objektivně
ověřitelné
ukazatele
Způsob
ověření
Předpoklady
a rizika
Konkrétní
výstupy
projektu
Klíčové
činnosti
Poznamenejme, že v literatuře se můžeme setkat j poněkud jinými názvy sloupců a řádků,
které však konec konců vždy popisují důležité logické souvislosti návrhu projektu.
Účel je zde představován účinkem, který projekt má dosáhnout. Odpovídá na otázku
PROČ projekt vlastně chceme realizovat. Je to očekávaný efekt navozené změny, kterou
projekt přinese. Účel obvykle nelze dosáhnout přímo, ale nepřímo prostřednictvím realizace
cíle projektu
Cíle konkretizují předmět zaměření projektu s ohledem na jeho deklarovaný účel. Je
výhodné, když se projektový tým může koncentrovat na jeden cíl projektu! Může však být
jich být i několik, aby se významného, ambiciózního účelu dosáhlo ( ale ne přespříliš!).
Odpovídají vlastně na otázku CO? je obsahem projektu. Cíl by neměl být zaměněn
s prostředkem resp. způsobem dosažení (viz dále Konkrétní výstupy).
Konkrétní výstupy projektu blíže zodpovídají otázku JAK? plánujeme konkrétními
výstupy dosáhnout našich cílů. Proto každý cíl, pokud je dekomponováno několik cílů, by
měl být podpořen konkrétním výstupem projektu.
Klíčové činnosti zdůrazňují ty činnosti, na které je potřeba se zvláště zaměřit, aby se
podařilo realizovat výstupy projektu. Téměř pro každý konkrétní výstup lze definovat
určitý klíčový problém, na který je potřeba hned o začátku projektu zaměřit pozornost
projektového týmu.
Celý sloupec Popis projektu musí být svázán logicky v posloupnosti příčina –
důsledek (např. neměli bychom uvádět mezi cíli takový, který neváže na účel projektu, apod.)
Účel projektu
Cíle projektu
Konkrétní výstupy projektu
Klíčové činnosti
(Šipky zde představují vztah příčina-důsledek)
Poznamenejme, že tuto posloupnost je nutně chápat dynamicky v kontextu usazení
hierarchie tohoto řetězce v organizační hierarchii firmy. Např. účel projektu bude jiný pro
montážní dílnu a jiný pro výrobní divizi jízdních kol, i když se bude jednat o problém
zvyšování produktivity výroby.
Objektivně ověřitelné ukazatele představují nástroj ke prokazatelnému zjištění, že cíle,
účelu, výstupu nebo činnosti bylo dosaženo. Všeobecně se jeden ukazatel považuje za
nezbytné minimum. Je velmi prospěšné využít několika nezávislých ukazatelů, k
prokazatelnému ověření. Na druhé straně příliš mnoho ukazatelů může představovat zbytečně
vysoké náklady na ověření. Pokud bychom snad nedovedli stanovit vhodné objektivně
ověřitelné ukazatele, pak raději změňme formulaci příslušného předmětu našeho snažení.
Nedovedeme měřit dosažení cíle, nedovedeme asi ani řídit postup jeho dosažení. Je velmi
důležité správně stanovit ukazatele v tom smyslu, aby prokazovaly opravdu skutečně dosažení
cíle. Např. jedná-li se o cíl „Vyškolit 6 pracovníků pro svařování tlakových nádob“,. pak
objektivně ověřitelný ukazatel není doložení 6 přihlášek do příslušného kurzu, ale 6 průkazů
pracovníků o úspěšně složených zkouškách z předepsaného kurzu. Potřebujeme-li pro montáž
výrobků postavit novou halu, není správný ukazatel dosažení cíle milník „všechny stavební
práce ukončeny“ ale fakt „Kolaudační řízení novostavby proběhlo úspěšně a hala je
k dispozici k užívání“.
Způsob ověření představuje soubor prostředků k ověření, dohodnuté metody k ověření,
termín ověření a případně i potřebné náklady na ověření jednotlivých ukazatelů. Důležité je
stanovit, kdy bude ověřitelný ukazatel vyhodnocen.
Předpoklady a rizika vyjmenovávají explicitně skutečnosti, na které je nutno výslovně
upozornit, protože je na nich úspěšná realizace projektu bezprostředně závislá.
Metodu logického rámce je nejlépe realizovat v následujících jedenácti krocích:
1. Stanovte účel projektu
2. Stanovte výstupy projektu pro dosažení účelu
3. Stanovte skupiny klíčových činností pro dosažení každého
z výstupů
4. Stanovte cíl /cíle/
5. Ověřte dodržení vertikální logiky testem: jestliže -pak
6. Stanovte požadované předpoklady na každé úrovni
7. Stanovte objektivně ověřitelné ukazatele na úrovni:
a) účelu
b) výstupů
c) cíle (cílů)
8. Stanovte prostředky ověření
9. Určete náklady na provedení činnosti - rozpočet na
realizaci
10.Proveďte kontrolní test návrhu projektu podle
kontrolního seznamu otázek
11.Přehodnoťte návrh projektu z hlediska zkušenosti
s podobnými projekty
Výhody metody logického rámce spočívají v následujících přednostech:
- Splňuje požadavky na dobrý návrh projektu
- Reaguje na slabé stránky mnoha dřívějších návrhů projektů
- Je snadné se ho naučit a prakticky používat
- Nevyžaduje další takové nároky či úsilí, naopak přináší úspory
- Může být používán i při externím poradenství
-
Může být použit i pro vyhodnocování projektů
Všeobecně přijaté zásady hnutí za vysokou jakost TQM (Total Quality Management)
vyžadují, mimo jiné, aby na závěr každého souboru činností byl proveden krok, testující
jakost výstupu předchozího procesu – QAS (Quality Assurance Step). Proto metoda logického
rámce doporučuje následujícího seznamu kontrolních otázek pro testování /vyhodnocování/
návrhu projektů. Pokud se na otázku odpoví záporně, je potřeba korigovat navržený logický
rámec:
JE PRAVDA, ŽE :
1. Projekt má pouze jeden účel?
2. Účel není pouhým, rozdílným vyjádřením výstupů?
3. Účel je mimo dosah odpovědnosti projektového týmu?
4. Účel je jednoznačně stanoven?
5. Výstupy jsou jednoznačně stanoveny?
6. Dosažení všech výstupů je nutné pro naplnění účelu?
7. Z formulace výstupů je zřejmé, jakých výsledků má být dosaženo?
8. Činnosti určují postup pro dosažení výstupů?
9. Cíl je jednoznačně určen?
10.Vztah příčiny a důsledku mezi účelem a cílem je logický a nejsou vynechány žádné
důležité souvislosti?
11.Předpoklady na úrovni činnosti nezahrnují žádné z těch,
které musejí předcházet zahájení těchto činností.?
(Takové podmínky jsou uvedeny samostatně, vlastně jakoby
o jednu úroveň níže).
12.Výstupy spolu s předpoklady na své úrovni vyjadřují nutné a postačující podmínky pro
splnění účelu?
13.Účel spolu s předpoklady na své úrovni vyjadřuje kritické podmínky pro dosažení cíle?
14.Vztah mezi výstupy a účelem je reálný?
15.Vztah mezi činnostmi a vstupy (zdroji) je reálný?
16.Vertikální logika mezi činnostmi, výstupy, účelem a cílem je reálná jako celek?
17.Ukazatele na úrovni účelu jsou nezávislé na výstupech?
Nejsou souhrnem výstupů,ale ověřují naplnění účelu
18.Ukazatele účelu vypovídají o tom, co je důležité?
19.Ukazatele jsou cílené a je stanoveno množství, jakost, čas?
20.Ukazatele výstupů jsou objektivně ověřitelné z hlediska množství,jakosti a času?
21.Ostatní ukazatelé jsou objektivně ověřitelné z hlediska množství,jakosti a času?
22.Vstupy popsané na úrovni činnosti stanoví zdroje a náklady požadované k naplnění účelu?
23.Ve sloupci prostředků je stanoveno, kde nalezneme informace potřebné pro ověření
každého ukazatele?
24.Mezi činnostmi nalezneme všechny ty, které se vztahují k získání prostředků ověření?
25.Ze způsobů stanovení výstupů je zřejmé rozdělení odpovědností?
26.Z navrženého logického rámce je zřejmé, podle čeho bude projekt hodnocen
27.Ukazatele účelu vypovídají o dopadu projektu, který musí být předem odsouhlasen?
28.Součástí výstupů je i popis způsobu řízení projektu?
Obsáhlý kompletní popis je k dispozici na internetových stránkách firmy Team Praha
včetně demonstrační verze produktu pro počítačovou podporu metody logického rámce
(www.team.cz).
Po zpracování logického rámce projektu musíme provést definici kontextu logického
rámce. Znamená to nalézt a definovat předcházející, souběžné a navazující projekty
v návaznosti na dlouhodobé programy a vizi firmy. Je to důležité proto, že málokterý projekt
je isolovaným případem. Naopak! Ve většině případů souvislosti s jinými projekty ovlivňují
samotný projekt, který zase ovlivňuje ostatní projekty ve firmě. Výsledky předcházejících
projektů jsou obvykle nutnou podmínkou pro start navrhovaného projekty. Souběžně
probíhající projekty často vyžadují vzájemnou koordinaci s navrhovaným projektem a
následné projekty je potřeba brát často v úvahu při stanovování výstupů navrhovaného
projektu. Projekt přitom musí obvykle být součástí nějakého firemního programu (programů)
a přispívat k naplnění firemní vize a poslání firmy.
Pro potřeby strukturálních projektů upravili pracovníci EU strukturu logického rámce
následujícím způsobem (viz Příručka žadatele programu EU SROP – Logický rámec od
MMR ČR).
Sloupec
Intervenční (strom
cílů)
Sloupec –
Objektivně
ověřitelné
ukazatele
Měřitelné indikátory
Hlavní cíl(e)
Důvod realizace na úrovni hlavních
Specifické
cílů (počet, délka,
cíle dané priority
obsah....) Způsoby,
v programovém
kterými lze měřit
dokumentu
splnění cíle.
Účel projektu
Změna,
kterou chceme
dosáhnout
projektem
Jaké jsou
operační cíle
opatření, kterých
bude projektem
dosaženo
Výstupy projektu
Nezbytné
k naplnění účelu
projektu
Co bude
konkrétním
výstupem projektu
(co se postaví,
opraví, nakoupí)
Co bylo
vytvořeno
1.
2.
3.
Aktivity projektu
Ke každému
výstupu
Jednotlivé
činnosti, které
jsou předmětem
předkládaného
projektu (logická a
časová
posloupnost)
Jak bude
projekt realizován
1. 1. ..
Sloupec – Zdroje
informací k
ověření
Kde se dají získat
informace o
objektivně
ověřitelných
ukazatelích (krajské
statistiky,
monitorovací
zprávy, statistiky
ÚP).
Měřitelné indikátory Kde se dají získat
na úrovni výsledků informace o
– konkrétní hodnoty objektivně
ověřitelných
jednotlivých cílů
projektu (počet,
ukazatelích
délka, obsah....)
(monitorovací
Způsoby, kterými
zprávy, statistiky
lze měřit splnění
obce, vlastní
účelu.
projekt)
Měřitelné indikátory
na úrovni výstupů
nezbytné pro
zabezpečení účelu
(počet, délka,
obsah....)
Způsoby, kterými
lze měřit dosažení
výstupů.
Výčet měřitelných
vstupů nezbytných
pro zabezpečení
aktivit projektu
(finanční zdroje,
dokumentace,
povolení, materiál,
energie....)
Jaký typ zdrojů
projekt vyžaduje.
Sloupec – vnější
Předpoklady
/Rizika
Nezbytné vnější
podmínky pro
dosažení hlavního
cíle mimo naši
odpovědnost (zájem
o danou aktivitu,
volné pracovní síly)
Kde se dají získat
informace o
objektivně
ověřitelných
ukazatelích
(monitorovací
zprávy, statistiky
obce, vlastní
projekt)
Předpoklady a rizika
na úrovni výstupů
podmiňující
dosažení účelu
(průběh realizace,
finanční zdroje,
dodavatel)
Časový rámec
aktivit
Předpoklady a rizika
na úrovni vstupů
(zajištění fin. zdrojů,
vybrání kvalitního
dodavatele..)
Ke každé aktivitě
se uvede časový
údaj, kdy daná
aktivita bude
zrealizována.
(10/2003)
2...
3...
2. 1...
2...
3...
Předběžné
podmínky
vnější i vnitřní
předběžné
podmínky
(vyhlášení
programu, vydání
stavebního
povolení, schválení
zastupitelstvem....)
Logický rámec by měl být čten následujícím způsobem (vzestupně ve směru šipek):
Sloupec 1
Celkový cíl
Sloupec 2
(objektivně ověřitelné
ukazatele)
měřený čím
Sloupec 4
(rizika/předpoklady)
vedou ke splnění
Účel /záměr
měřený čím
a předpokládající co
vedou ke splnění
Výstupy
měřené čím
a předpokládající co
vedou ke splnění
Aktivity
Prostředky (vstupy)
za předpokladu, že
Předběžné podmínky
Pokud jsou splněny předběžné podmínky, lze zahájit
realizaci aktivit projektu
10 Síťová analýza a podrobné plánování projektů řídicích systémů
Rozsah tohoto učebního textu samozřejmě nedovoluje uvést vyčerpávající přehled
metod, používaných v průběhu návrhu podrobného plánu projektu. Zejména nelze podrobně
popsat metody síťové analýzy. Zde uvedeme jen přehled nejdůležitějších. Vážnější zájemci
musí použít pro studium doporučenou literaturu. Především je potřeba zdůraznit, že za
standardní postup při návrhu projektu se dnes považuje postup podle určité metody s
podporou počítače. Ručně, intuitivně prováděný návrh detailního plánu projektu je považován
dnes za nestandardní a odporující zásadám jakosti podle norem řady ISO 9000 resp normy
ISO 10 006.
Za standardní jsou považovány metody: CPM, PERT a rozšířené Ganttovy diagramy.
Na nadstandardní metodu je považována metoda Critical Chain
Po seznámení s českou terminologii je možno doporučit text české normy ČSN 01
0111 Názvosloví metod síťové analýzy.
10.1 Ganttovy diagramy
Ganttových diagramy (též úsečkové grafy, čárové harmonogramy) představují
jednoduché znázornění časového průběhu několika činností, které často probíhají i současně.
Jejich tvůrce H.L.Gantt, americký poradce na organizaci, je vymyslel pro plánování
činností a jejich sledování, v amerických loděnicích za I.světové války při dodávkách pro US
NAVY. K řízení složitého průběhu činností při výstavbě námořních lodí již nedostačovaly
jednoduché seznamy kalendářních údajů, které určovaly termíny začátku a konce jednotlivých
činností.
Jednoduchá tabulka, např.:
Činnost
Koncový termín
Příprava zahájení projektu
Zahajovací mítink
do 31.řijna 2005
3. října 2005
nedává dostatečný přehled o termínech při větším počtu činností, zvláště, když je nutno
sledovat i termíny začátku činností (ty jsou ve výše uvedené tabulce implicitně ztotožněny
k koncovým termínem předchozí činnosti).
Termín
činnosti
Činnost
zahájení Termín ukončení
činnosti
Základní princip Ganttových diagramů je dostatečně známý:
Činnost A
Činnost B
Činnost C
Časová osa
V diagramech můžeme použít i speciální značky ♦, která představuje kontrolní bod,
tedy termín, kdy bude např. provedena kontrola (milníky). Můžeme používat místo čar
obdélníky a do nich vepisovat jiné údaje ( např. počet vyrobených kusů):
Dále je možno různými barvami označovat plán a skutečnost, apod.:
-----------------------------------------------------Klasické Ganttovy diagramy měly nevýhodu v tom, že nevyjadřovaly souvislosti mezi
jednotlivými činnostmi. To můžeme odstranit tím, že znázorníme pomocí šipky závislost
jedné činnosti na druhé.
Např.
A
B
Taková situace představuje vyjádření, že činnost A musí být ukončena, aby mohla
začít činnost B. Mohou tedy nastat jen dvě situace:činnost A skončí a po nějaké době bude
zahájena činnost B (viz obrázek výše) nebo činnost A skončí a bezprostředně začne činnost
B. To bychom pak mohli nakreslit na časové ose takto:
A
B
Nemůže nastat situace, že by činnost A neskončila a přesto začala činnost B.
Pokud bychom tuto šipku nenakreslili. Pak by činnosti byly na sobě nezávislé!
Označíme-li takovou závislost, pak z ní vyplývá, že jestliže se prodlouží činnost A
proti plánu, odsune se automaticky i začátek činnosti B.
Takto zdokonalené Gantovy diagramy jsou za určitých podmínek alternativou k
síťovým grafům . V takovém případě jsou používány v Ganttových diagramech i značky pro
milníky, apod.
Ukázku Ganttova diagramu, jak je možno ho vytvořit v programu MS Projekt, ukazuje
obrázek v následujícím odstavci.
10.2 Metody síťové analýzy
Metody síťové analýza tvoří základ metod ¨současného projektového řízení.
Využívají techniku hranově nebo uzlově orientovaných grafů, která vychází
z matematické teorie grafů.. Síťová analýza vznikla v souvislosti s potřebou urychlit vývoj a
výrobu raket POLARIS v USA v padesátých letech při závodech ve zbrojení při studené válce
s SSSR. V roce 1958 se diky aplikaci metody PERT podařilo zkrátit vývoj této rakety o 18
měsíců!
Projektové řízení dnes využívá dvě nejpopulárnější metody:
- deterministický model, presentovaný metodou CPM (Critical Path Method) - je stanovena
jen jedna hodnota odhadu ( doba délka činnosti je odhadnuta např. na 10 dní, a náklady na
25000 Kč)
- stochastický model, presentovaný metodou PERT (Programm Evaluation Review
Technique) - z pesimistického odhadu, normálního odhadu a z optimistického odhadu je
vypočtena pravděpodobná hodnota odhadu ( např. délka činnosti při bezproblémovém řešení
je odhadnuta optimisticky na jeden týden, vyskytnou-li se však potíže, pak pesimistický
odhad je 6 týdnů, přičemž normální odhad jsou 4 týdny, takže náklady se pohybují od 30000
do 200000 Kč přičemž se očekává, že náklady budou zřejmě 100000 Kč)
Obě metody určují kritickou cestu, která je totožná s nekratší možnou délkou trvání
projektu a časové rezervy pro činnosti, které neleží na kritické cestě. Kritická cesta se skládá z
činností, které musí bezprostředně na sebe navazovat bez jakýchkoliv časových rezerv.
prodloužení kterékoliv činnosti na kritické cestě nebo její opožděné zahájení má bezprostřední
vliv na prodloužení doby projektu . Následně, po časové analýze lze provést analýzu nákladů
na projekt a analýzu zdrojů, potřebných k realizaci projektu.
Kromě toho se v některých případech (zejména ve Francii) používá metody MPM
(Metra Potential Metod).
Interpretace hranově orientovaného grafu pro metodu CPM je následující:
- ohodnocené, orientované hrany představují činnosti projektu v definované posloupnosti
(Pozor! Délka hrany není úměrná trvání činnosti, jak je tomu u Ganttova diagramu!)
Pevnostní výpočet skříně - 6 dnů / 5000 Kč / 2 výpočtáři
- uzly (označují se čísly) představují události ukončení a startu činností
24
Kompletní činnost je v grafu zakreslena počátečním uzlem určitého čísla,
ohodnocenou hranou a koncovým uzlem určitého čísla (pořadové číslo počátečního uzlu
musí mít menší hodnotu než pořadové číslo koncového uzlu činnosti:
Kompletace výkresů - 1 den / 500 Kč / 1 archivářka
45
67
Pokud jsou činnosti řazeny za sebou, musí předchozí činnosti nejprve skončit, aby
mohla začít následující činnost.
Interpretace uzlově orientovaného grafu je opačná:
- orientované hrany jsou užity k určení návaznosti činností
- uzly představují činnosti projektu a číslují se pořadovými čísly
Uzel číslo: 248
Pevnostní výpočty
12 dní
60 000 Kč
5 výpočtářů
Z praktických důvodů (sestavování prvního návrhu síťového grafu pomocí lístků firem TIX,
POSIX, PELIKAN nebo TESA) a pro pestřejší možnosti zadávání návaznosti činností se v
poslední době nejvíce používají uzlově orientované grafy, kde je možno zadávat nejen
základní typ návaznosti:
FINISH TO START
- tj.případ, že následující činnost může začít až po ukončení předcházející činnosti:
45
F
45
S
52
52
ale i případy
- FINISH TO FINISH
46
F
F
51
S
5O
F
52O
46
51
- START TO START
41
S
41
50
- START TO FINISH
450
S
450
520
Ganttův diagram v MS Projectu
Síťový graf v MS Project
ale i řadu jiných omezení pro průběh činností např. časovými podmínkami ( Činnost musí
skončit před 30. říjnem).
Uzly je možno spolu propojovat do složitějších sítí. Musíme však při spojování dodržet určitá
pravidla, aby se navržená síť dala skutečně realizovat, a aby představovala použitelnou
pomůcku pro podporu řešení problémů projektového řízení:
a) Síť musí být souvislá, tj. nesmí se v ní vyskytovat izolované uzly a hrany
b) Síť musí být orientovaná, tj. všechny hrany musí být provedeny jako šipky
c) Síť musí být ohodnocená, tj. pro všechny činnosti musí být uvedeny potřebné hodnoty
času, náklady a zdroje
d) Musí se jednat o jednoduchý graf, nikoliv multigraf, tj. mezi dvěma uzly musí být
vždy jen jedna hrana
e) Síť musí být acyklická. V síti se nesmí vyskytovat smyčky, tj. cesty, kdy se z jednoho
uzlu vrátíme do stejného uzlu
f) Síť musí splňovat zásadu „jeden vstup-jeden výstup“ (angl. zkratka 1E1E - one entry
– one exit), tj. že existuje jen jeden vstupní uzel a jeden výstupní uzel.
g) Síť musí mít konečný počet uzlů a hran, tj. nemohou existovat projekty, které neustále
pokračují.
Jako příklad propojení uzlů sítě může sloužit následující graf:
Metody síťové analýzy nám umožňují určit:
- kritickou cestu (nejkratší dobu realizace projetu)
- subkritické cesty, které se kritické cestě velmi blíží
- možné časové rezervy u činností, které neleží na kritické cestě
- rozložení finančních nákladů v průběhu projektu
- potřebu jednotlivých zdrojů v průběhu projektu
K tomu slouží:
• Časová analýza (Time Analysis)
• Nákladová analýza (Cost Analysis)
•
Zdrojová analýza (Ressource Analysis)
Časová analýza
Časová analýza vyžaduje, aby každá činnost byla ohodnocena tak,jí přiřadíme údaj o
délce jejího trvání a analyzujeme výslednou délku trvání projektu
Jak metoda CPM, tak metoda PERT vypočítávají především tzv. kritickou cestu, což je
nejdelší doba trvání projektu.
Zatímco na jiných cestách orientovaným grafem,(tj.posloupnosti hran a uzlů mezi
začátkem a koncem sítě existují časové rezervy, na kritické cestě jsou tyto rezervy nulové.
Jakékoliv zdržení (tj. prodloužení) na některé činnosti, která leží na kritické cestě, znamená
prodloužení termínu dokončení projektu.
Po provedeném výpočtu je možno pro každou činnost stanovit:
- nejdříve možný začátek
- nejdříve možný konec
- nejpozději nutný začátek
- nejpozději nutný konec
Často se také hledají tzv. subkritické cesty, což jsou cesty v grafu takové, které mají
délku velmi blízkou kritické cestě.
Pro každou činnost se vypočítávají také případné časové rezervy (viz příloha)
Nákladová analýza
Nákladová analýza vyžaduje, abychom ke všem činnostem přidali údaj, kolik
vyžaduje finančních nákladů jejich provedení, abychom mohli vypočítat výši potřebných
nákladů v průběhu projektu
Pro správný výpočet průběhu nákladů je potřeba rozlišit, zda se jedná o fixní náklady
nebo náklady závislé na době trvání činnosti. Dále je potřeba určit, jakým způsobem má
být započten náběh nákladů: jednorázově a kdy (na začátku činnosti, na konci činnosti, s
předstihem, se zpožděním apod.), průběžně lineárně, se speciálním modelem průběhu.
Průběh potřebných nákladů graficky vyjadřujeme histogramem čerpání nákladů.
Náklady ve 100 tis.Kč
100
80
60
40
20
0
1. čtvrt.
2. čtvrt.
3. čtvrt.
4. čtvrt.
Zdrojová analýza
Všechny činnosti ohodnotíme podle toho, kolik spotřebovávají různých zdrojů (různé profese
pracovníků, úzkoprofilové stroje a materiály, apod.)
90
80
70
60
50
40
30
20
10
0
1. čtvrt.
2. čtvrt.
3. čtvrt.
4. čtvrt.
Histogram nám umožňuje určit:
•
•
•
Potřebu určitého zdroje v časovém průběhu projektu
Využití určitého zdroje v průběhu projektu
Čerpání disponibilního limitu určitého zdroje (resp. jeho překročení).
Příklad znázornění histogramu zdrojů v MS Project
Relativní a absolutní kalendář
Často se používají termíny absolutní a relativní kalendář, protože současní é programy
počítačové podpory umožňují práci s těmito pojmy..
Relativní kalendář je určen základní jednotkou ohodnocování jednotlivých činností (den,
týden, rok, hodina ...) a stanovením začátku projektu na časové hodnotě jako "nula". Termíny pak jsou
stanovovány jako "čtvrtý den trvání projektu",tj. relativně k počátku.
Absolutní kalendář je orientován na používání běžného reálného kalendáře. Uvažují se tedy
při výpočtu volné dny, svátky apod. Termíny se udávají v kalendářních datech např. 4. října 95.
Určitým problémem jsou přepočítávací vztahy mezi jednotkami hodina – pracovní den –
pracovní týden - pracovní měsíc, apod. Pokud nejsme spokojeny se předdefinovanými hodinami 8
hodin je jeden pracovní den, můžeme vzájemné vztahy stanovit jinak např. 8,5 hod – jeden pracovní
den. Lze také stanovit zvláštní vztahy mezi jednotkami pro určitý zdroj- např. F.Kyslík 4 hod. –jeden
pracovní den (pracuje na zkrácenou pracovní dobu nebo na částečný úvazek).
Je také možno používat několik kalendářů s různými svátky (křesťanské svátky,
muslimské svátky, státní svátky různých zemí)
Síťová analýza představuje dnes standardní, nejvíce rozšířenou a základní techniku
podporující návrh projektu.
Její výhody jsou následující:
• Obsahuje nástroje pro plánování času, nákladů a zdrojů
• Její použití je možné jak pro analýzu, syntézu a optimalizaci (Proto její název „síťová
analýza“ není příliš výstižný a šťastný, nicméně se tradičně používá)
• Umožňuje využití následovně pro sledování plnění činností ve fázi implementace projektu
• Je dostatečně známa, propracována a je relativně jednoduchá
• Dovoluje použít jak deterministické, tak stochastické ohodnocení sítě
• Pro komunikaci s pracovníky, kteří zajišťují provedení jednotlivých činností, lze bez
problémů použít jako výstup techniku Ganttových diagramů.
• Ve srovnání s variantou hranově orientovaných grafů pokrývá dostatečně všechny běžné
varianty návaznosti činností, které současná praxe potřebuje
• Existuje pro její počítačovou podporu velké množství jakostních produktů
V současné době jsou však zjevné i nevýhody klasické síťové analýzy:
Při výpočtu kritické cesty není přihlíženo k rizikům nedodržení termínů
Kritická cesta je vypočtena bez ohledu na disponibilní zdroje
10.3 Metoda kritického řetězce
Snaha po odstranění zmíněných nedostatků síťové analýzy vedla ke vzniku metody
kritického řetězce od prof. Goldratta. Základní informacím o metodě kritického řetězce. je
věnována pozornost českou pobočnou firmy Goldratt (www.goldratt.cz). Tato firma také
vydala český překlad knihy prof. E.Goldratta: Kritický řetěz.
Metoda kritického řetězce vychází z teorie ometení (Theory of Constraints) prof.
Goldratta., která je aplikována na síťovou analýzu v tom smyslu, že kritické jsou také
disponibilní, sdílené zdroje. Navíc je zvažována také situace, že odhadovaný čas je
stanoven s určitými rezervami. Výsledkem analýzy činností za těchto předpokladů je
kritický řetězec (nahrazuje pojem kritická cesta), ten bere v úvahu omezení daná zdroji a
přesun části implicitních rezerv činností do tzv. nárazníkových činnosti (buffers).
Podrobnější popis by přesáhl rámec tohoto materiálu.
10.4 Sestavování síťového grafu
Pro úspěšné sestavení síťového grafu musíme vhodně seskupit a strukturovat činnosti,
které budou tvořit síťový graf.
Především je nutno definovat obsah činností, pracovní cíle, výsledky, odpovědné osoby,
termíny a lhůty, zdroje, odhady a náklady ( v angl. SOW – Stateman of Works). To
představuje tu část smlouvy, v níž se přesně uvádí, co bude dodáno a kdy. U interních
projektů může být obsažena v interním sdělení. Vždy by ale měla obsahovat konkrétní,
měřitelný a dosažitelný cíl. Souvisí to s pojmy obsah a rozsah projektu (contents/ scope of
project).
Někdy se celý projekt rozdělí do tzv. pracovník balíků (work packages) jindy do různých
fyzických objektů nebo časových etap.
Definování a strukturalizace prací projektu představuje procesy pro zajištění toho, aby projekt
zahrnoval všechny požadované práce a právě jen tyto práce tak, aby mohl být úspěšně
dokončen, aby vedl k realizaci požadovaného produktu. Výstupem definování a
strukturalizace prací je „Struktura rozdělení prací“ (WBS – Work Breakdown Structure).
Strukturování projektu je předpokladem zahájení plánování všech tří parametrů projektu kvality, času, nákladů pro jednotlivé činnosti. V průběhu realizace projektu může docházet k
změnám ve struktuře prací. Tyto změny musí být vždy pečlivě koordinovány s ostatními
procesy - s řízením času, nákladů, zdrojů a dalšími.
Pochopitelně struktura prací může být provedena do určité hloubky detailu. Proto hovoříme o
strukturalizaci prací na:
1.úrovni
2.úrovni
3.úrovni
Atd. do potřebné míry podrobností, která záleží na konkrétním projektu, a měla by
korespondovat s rozhodnutím projektového týmu, jaké detailní činnosti chce řídit.
V Programu MS Project je hierarchická struktura činností realizována následujícím
způsobem:
1.
1.1
1.1.1.
1.1.2
1.2.
1.2.1
1.2.2.
Atd.
Grafické znárodnění struktury tak může být vyjádřeno grafem typu strom, jak ukazují
následující obrázky, kde je strukturalizace v obou případech provedena až do druhé úrovně.
Projekt zakázky
Výroba kola
Koncepční fáze
Přípravná fáze
Koncepce
Testy
Optimalizace
Simulace
Konstr. příprava
Předvýr. příprava
Struktura členění prací uspořádaná dle fází projektu
Realizace
Výrob. příprava
Nultá série
Výroba
Výstavba závodu
Hala
Železnice
Správní budova
Přípravné práce
Přípravné práce
Přípravné práce
Zhotovení haly
Stavba železnice
Stavba budovy
Instal. zařízení
Montáž zařízení
Seriózní ohodnocení činností
Struktura členění prací uspořádaná dle výstupů projektu (OBS – Object
Pro jednotlivé činnosti je potřeba uvést, plánovanou spotřebu času, potřebné finanční
náklady a nutné zdroje (počty pracovníků příslušných profesí, počty potřebných pomůcek,
počty dopravních prostředků, objemy surovin, apod.).
Ke stanovení plánovaných hodnot pro ohodnocení činností můžeme použít následující
postupy:
1) Postup založený na normativní metodě. Používá se tam, kde se jedná o poměrně
dostatečně přesně popsané činnosti, realizované pracemi, pro něž jsou prostřednictvím
normování zpracovány normativy a metodika k jejich použití. Např. stavebnictví,
strojírenství, elektrotechnickém průmyslu, chemickém průmyslu, apod. Prováděné
činnosti však musí být minimálně ovlivňovány nahodilými událostmi, aby plánované
hodnoty, stanovené prostřednictvím normativů, se daly
prakticky použít.Proces
normování zahrnuje různá měření výkonů a času, různé výpočty výkonů a časů a návrh
optimální posloupnosti úkonů, ze kterých se normované činnosti skládají, aby se dosáhlo
soustavy objektivních a progresivních normativů Hodnoty, získané pomocí normativů, se
využívají zejména jako podklad především pro deterministickou metodu CPM.
2) Využití porovnávací metody. Porovnávací metoda (někdy nazývaná komparativní metoda
nebo benchmarking) je založena na existenci znalosti hodnot času, nákladů a zdrojů pro
činnost, která je podobná té, pro kterou chceme provést ohodnocení.Takové činnosti, o
které známe všechny potřebné údaje, a používáme ji jako základ porovnání, říkáme
obvykle etalon. Snažíme se porovnat obě činnosti a na základě různých znaků podobnosti
usoudit, jaké by měly být hodnoty u ohodnocované činnosti. Musíme však umět stanovit,
jak odlišnost ve srovnávaných znacích ovlivní určovanou veličinu. Např. Náš případ
prováděného výkopu je dvakrát delší než je etalonová činnost. Ostatní znaky – profil
výkopu, způsob provádění výkopu, druh zeminy, jsou stejné jako u etalonu. Pokud
předpokládáme lineární závislost, a u etalonu trvala délka výkopu 30 dní, můžeme
ohodnotit při stejném počtu pracovníků, že délka ohodnocované činnosti bude 60 dní.
Problémem je nepřehlédnout odlišné znaky a správně určit vzájemnou závislost.
Samozřejmým předpokladem je existence etalonu. Pokud se však porovnávaná činnost liší
v mnoha znacích a vzájemné závislosti a souvislosti jsou komplikované, je obtížné tuto
metodu použít. Vypočtené hodnoty lze použít jak pro metodu CPM, tak PERT.
3) Postup založený na využití statistické analýzy. V případě, že v činnostech se uplatňují
nahodilé vlivy můžeme pomocí faktorové analýzy určit faktory, které významným
způsobem ovlivňují spotřebovaný čas, náklady a potřebné zdroje. Pro vytypované faktory
určíme prostřednictvím korelační analýzy ten, který má největší vliv na odhadovanou
činnost. Pomocí regresní analýzy můžeme pak stanovit průběh vzájemné závislosti.
Předpokladem je dostatečný počet dat pro statistickou analýzu a statisticky stabilní
podmínky (okolnosti se v průběhu zkoumání a pro predikovanou dobu nemění). Obojí,
lze v současném turbulentním prostředí obtížně předpokládat a zajistit. Takto získané
hodnoty se nejčastěji používají pro stochastickou metodu PERT.
4) Využití modelování a simulace. Sestavíme model průběhu činnosti. Obvykle se jedná o
abstraktní matematicko-logický model, který můžeme simulovat s pomocí počítače.
Prostřednictvím experimentování s modelem určíme plánované veličiny. Předpokladem je
schopnost sestavit model a mít k dispozici potřebný software pro počítačovou simulaci.
Protože tento postup může být poměrně nákladný, užívá se ho ke stanovení jen
nejdůležitějších činností a významných hodnot (celková doba projektu, celkové náklady
na projekt, apod.). Vypočtené hodnoty lze použít jak pro metodu CPM, tak PERT.
5) Postup založený na expertních odhadech. Prostřednictvím několika expertů, kterým
položíme otázku, týkající se plánované problematiky, se snažíme stanovit potřebné
veličiny (např. metodou DELPHI). Tento postup používáme obvykle v okamžiku, kdy
nelze využít některého z předchozích postupů. Vypočtené hodnoty lze použít jak pro
metodu CPM, tak PERT.
V souvislosti s odhady projektů pro tvorbu software se používají specializované metody:
1) COCOMO – Constructive Cost Model. Jedná se postup, který byl vyvinut v USA na
základě zkušenosti s SW projekty a jejich analýzou. V současné době je aktuální verze
s označením COCOMO II.
2) UCP – Use Case Points. Tato metoda byla vyvinuta pro projety tvorby softwaru.
objektově orientovanou technologií. Vychází z prvních Use Case diagramů UML a na
jejich základě se snaží stanovit čas, náklady a pracnost plánovaného softwarového
projektu.
V roce 1993 Gustav Karner vyvinul metodu odhadu založenou na use case points. Jednalo
se o diplomovou práci na švédské University of Linköping. Copyright na tuto práci nyní
vlastní Rational Software. Karnerova metoda vychází z teze, že funkcionalita systému z
pohledu uživatele je základem pro odhad velikosti informačního systému. Karnerova metoda
je často citována a rozvíjena, existují práce kombinující function points (FP) a use case points
(UCP), konverze UCP na FP nebo práce o konverzi UCP na řádky zdrojového kódu (LOC).
Při aplikaci UCP musíme nejprve zjistit počet aktorů a počet use case. Use
do
kategorie složitosti (jednoduchý, střední, složitý) podle počtu transakcí (počet
case zařadíte
transakcí může být odvozen z počtu kroků popsaných ve scénáři). Někteří autoři doporučují
vynechat use case typu extends a includes. Podle kategorie složitosti přiřadíte jednotlivým use
case váhu. Metoda UCP používá obdobné modifikační faktory jako metoda analýzy funkčních
bodů.Dále tedy musíte ohodnotit dílčí technické faktory a faktory prostředí stupněm 0 (nemá
vliv) až 5 (silný vliv). Tyto faktory se týkají konkrétního projektu. Dosazením do
Karnerových vzorců získáte počet use case points (UCP). Nakonec počet UCP vynásobte
pracností člověko-hodin na jeden UCP. Karner doporučuje hodnotu 20, jiní autoři rozmezí 15
až 30 hodin na jeden UCP. Doporučuje se kalibrovat tuto hodnotu podle dat z minulých
projektů. Odhad si můžete vyzkoušet pomocí jednoduchého kalkulačního programu a pluginu do CASE nástroje, který si můžete stáhnout z www.komix.cz (sekce Ke stažení). Tam
naleznete i podrobnější návod k jednotlivým krokům odhadu. Existují i softwarové nástroje
podporující tuto metodu, od jednoduchých až po složité, které počet transakcí získávají
automaticky analýzou use case modelu a textu scénáře. Pro odhady v počátečních fázích
vývoje je ale i tabulka v MS Excelu zcela vyhovující (firma KOMIX Praha nabízí volně
použitelný program EstimIX, který podporuje tyto výpočty - viz www. komix. cz).
Uveďme stručně přehled výhod a nevýhod metody UCP.
Metoda Use Case Points stále není standardizována (narozdíl od standardizace výpočtu
functional points). Neexistují formální standardy pro psaní use case, problematická je
především úroveň abstrakce a úroveň podrobnosti popisu UC, která přímo ovlivňuje počet
transakcí popisovaných v UC, což má potom vliv na odhad pracnosti. Metoda UCP není nová,
vznikla před více než deseti lety. Mohou zde být pochybnosti, zda odpovídá současným
způsobům vývoje softwaru. Existují sice studie prokazující vhodnost této metody, ale studie
se týkaly malých projektů (okolo 2500 člověko-hodin) a projektů jedné firmy. Je málo
zkušeností s aplikací na různé projekty v různých firmách. Na druhou stranu, podle e-zinu
The Rational Edge je metoda UCP používána s dobrými výsledky v Sun a v IBM. K výhodám
patří jednoduchost metody, lze se ji snadno naučit a může tak být překonán psychologický
odpor k provádění odhadů komplikovanými metodami. Podle studie byl dokonce odhad
metodou UCP blíže skutečné pracnosti než odhad provedený skupinou expertů. K další
výhodě patří možnost provádět odhady v počátečních fázích vývoje informačního systému,
při sjednávání smlouvy. Součástí žádosti o nabídku bývají specifikace funkčních požadavků v
úrovni podrobnosti Úvodní studie (pokud její vypracování není součástí poptávky). V této fázi
zpravidla ještě neexistuje podrobná textová specifikace jednotlivých kroků scénáře, ze které
by se dal jednoznačně vyčíst počet transakcí. I když se nelze spolehnout na to, že jeden
funkční požadavek odpovídá jednomu use case a pro klasifikaci složitosti use case je nutno
počet transakcí pouze odhadnout, je pro takovéto situace metoda UCP vhodná a dává dobré
výsledky. Přesto by měla být vždy kombinována s jinou metodou, expertním odhadem nebo
analogií s obdobným projektem.
Stanovení správných návazností
Činnosti projektu by neměly být prováděny libovolně nebo v nahodilém pořadí!
Proto je potřeba stanovit jejich návaznosti:
• které činnosti musí konkrétní činnosti předcházet
• které činnosti musí po této konkrétní činnosti následovat
Často je také potřeba definovat tzv. časový odstup činností, tj. že další činnost
(např.odstranění podpěr) může následovat až po určité době (např. po 8 hod., až zatvrdne
lepidlo) nebo naopak předstih činnosti (např. shromáždění pořadatelů a jejich instruktáž musí
proběhnout hodinu před zahájením plesu).
Pro prvotní sestavení síťového grafu se často používá tzv. lístečková metoda. Spočívá
ve využití lístků, které mají ze zadní strany na horním okraji nanesen proužek lepidla. Na
přední stranu se lístků se napíší názvy nebo jiné identifikátory činností. Lístky se pak na
tabuli či jiný podklad nalepují tak, aby vytvářely jednotlivé posloupnosti, ve kterém činnosti
budou prováděny.
Stanovení požadavků na jakost
Nestačí jen specifikovat obsah činnosti, je potřeba stanovit kritéria, která umožní vyhodnotit,
zda činnost přiběhla v pořádku a poskytla výsledek v potřebné kvalitě. Hovoříme o
ukazatelích jakost činnost nebo výsledku činnosti. S tím souvisí i podrobné vymezení testů a
kontrol, které se provedou po skončení činnosti, aby se mohla vyhodnotit odvedená kvalita.
Stanovení osobní zodpovědnosti
Pro každou činnost je potřeba stanovit zodpovědnost za její naplánování, realizaci, kontrolu
výsledků, apod. Často se požívá tzv. matice odpovědnosti. Ta má různé formy. Příklad takové
matice ukazuje následující tabulka:
Matice se může týkat konkrétních osobo (nejčastěji doporučováno), někdy jsou jmenovány
jen firemní funkce (např. auditor Oddělení jakosti, Hlavní technolog, Vedoucí projektového
týmu, apod.)
Zodpovědnost
Fáze, činnost
Osoba 1
Osoba 2 Osoba 3 Osoba 4
…
Stanovení požadavků
Z
Ú
S
M
Věcný návrh
Z
Ú
Dokumentace
S
Z
Ú
Vývoj
P
Z
Ú
Testy
Z
Ú
…
Z – zodpovědný, Ú – účastník, S – musí shlédnout, M – dodá podklady, P – musí podepsat
Příklad matice odpovědností
Využití vhodné počítačové podpory
Jen u síťového grafu do počtu 20 činností je možno provést výpočty ručně. Pro ostatní
případy větších síťových grafů je potřeba použít počítačových programů, které provádějí tyto
výpočty efektivněji s využitím vysokého výpočetního výkonu počítačů a umožňují i kvalitní
provedení různých grafických zobrazení a zpracování různých přehledných tabulek.
Uveďme alespoň přehled základních výpočetních funkcí, které by měl zajišťovat
program pro počítačovou podporu projektového řízení v oblasti síťové analýzy:
- umět pracovat s uzlově i hranově orientovanými grafy
- pracovat s reálným i absolutním kalendářem s různými časovými jednotkami
- umožňovat doplňkové informace k činnostem (zodpovědnost, subdodavatelé,
poznámky)
- provádět aktualizaci síťového grafu a vyhodnocení odchylek od plánovaných
termínů
- kontrolovat správnost síťového grafu (smyčky, izolované uzly)
- umožnit agregaci grafu a vytváření podsítí
- stanovit kritickou, subkritickou cestu dopředným výpočtem,
určit dobu zahájení projektů při stanoveném termínu ukončení, případně stanovit
hyperkritickou cestu se zápornými rezervami protiběžným výpočtem při zadaném
začátku a konci projektu
- kontrolovat čerpání zdrojů (CPM/RESORCE) a umožnit plánování rovnoměrného
čerpání zdrojů
- vypočítat čerpání nákladů v čase (cash flow) případně také
optimalizovat celkové náklady na projekt zkracováním resp. prodlužováním
činností (CPM/COST)
- dovolit transformaci síťového grafu do Ganttových diagramů - provádět grafické
výstupy a řadu variantních tiskových zpráv na vyžádání, setříděných podle
různých hledisek.
Druhy výpočtů:
Dělení podle způsobu fixace zadaného termínu začátku nebo konce grafu:
• Dopředný výpočet. Stanoví se termín pro začátek projektu a postupně
připočítáváme jednotlivém činnosti, až vypočteme termín konce projektu
• Zpětný výpočet. Stanovíme, kdy má projekt končit a propočítáváme, kdy má
být odstartována první činnost (činnosti).
• Protiběžný výpočet. Fixujeme začátek a konec projektu a počítáme začátky a
konce jednotlivých činností. Můžeme často dojít k tzv.hyperkritické cestě se
zápornými rezervami.
Dělení podle způsobu provádění výpočtu:
• Numerický výpočet. Podle určitého algoritmu vyplňujeme jednotlivá pole
matice nebo jednotlivá pole v uzlech
• Grafický výpočet. Používáme tzv. liniového zakreslování činností ve zvoleném
měřítku (obdoba Ganttových diagramů).
Dělení podle použitých pomůcek:
• Ruční výpočet bez pomůcek
• Automatizovaný výpočet pomocí počítače
10.5 Další plány v rámci projektu
Metody síťové plánování pomáhají projektovému týmu sestavit podrobný plán
projektu z hlediska času, nákladů a zdrojů. Projektová praxe ukázala, že tyto plány jsou nutné,
ale nejsou dostačující, Proto současné projektové řízení doporučuje sestavit ve fázi
podrobného plánování další velmi potřebné plány:
• Plán nákupu, který zajistí potřebná vývěrová řízení, vystavení objednávek a případné
přechodné uskladnění všech nakupovaných komponent pro projekt.
• Plán zajišťování jakosti, který definuje odpovědnost za kvalitní průběh návrhu a
realizace všech činností projektu včetně jejich kontroly
• Plán komunikace, zajišťující efektivní komunikaci mezi všemi zainteresovanými
stranami na projektu, včetně zajištění účinného reportingu.
• Plán nasazení a využití prostředků informačních a komunikačních technologií
Ve specifických případech se může ukázat potřebné zpracovat některé další plány např. Plán
ochrany životního prostředí, Plán zajišťování bezpečnosti práce, apod.
11 Implementace projektů řídicích systémů
Cílem tohoto odstavce je vymezit postavení fáze implementace projektu, specifikovat
obsah této fáze a upozornit na techniky, které se používají v jejím průběhu.
Má posloužit jako úvod k dílčím referátům, které si detailně všímají jednotlivých
technik a detailně je popisují.
Zároveň má být podnětem k diskusi o problematice implementace projektů
Pojem implementace projektu zde byl pracovně zvolen, na rozdíl od výše uvedeného
velmi frekventovaného termínu realizace projektu proto, že v širším slova smyslu se všechny
fáze zabývají realizací – naplňováním projektu. V kontextu minulých publikací je cílem
zdůraznit, že v centru pozornosti této fáze je provádění naplánovaných činností (ang. to
implement – vykonávat, provádět)
11.1 Specifikace a dokumentace projektu
Řízení implementace projektu představuje operativní řízení projektu ( nebo jen krátce
řízení projektu) zahrnující procesy, které se vztahují k zajištění naplánovaných činností
projektu.
Jeho základem je dobrá specifikace projektu, která popisuje projekt jako předmět
operativního řízení projektu.
Připomeňme si zásady dobré specifikace projektu:
• Specifikace projektu musí být jednoznačná
• Specifikace projektu musí být úplná
• Splnění specifikace projektu musí být ověřitelné
• Specifikace projektu musí být bezrozporná
• Specifikace projektu musí být snadno modifikovatelná
• Ve specifikaci projektu musí být viditelné vnitřní souvislosti
• Specifikace neobsahuje výrazy typu „bude specifikováno později“.
Základem je definice všech činností, které mají být vykonány. Tyto činnosti musí být
vhodně strukturovány v rámci projektu a mají být pro ně definovány měřitelná kritéria,která
ukazují, zda činnost byla vykonána v potřebném rozsahu a jakosti.
Požadavky na projekt musí být dekomponovány do měřitelných cílů a stanovena
měřitelná kritéria pro jejich vyhodnocení (viz metoda logického rámce ).
Vedoucí projektu musí ovládat obsah a rozsah objemu prací. Musí mít tedy přiděleny
disponibilní zdroje a předány příslušné pravomoci k řízení a kontrole zajišťovaných činností.
Jestliže projektový tým obdrží je nepřesné, všeobecné zadání projektu a má
nepřiměřeně malé a jen nejasně vymezené pravomoce, může to být příčinou neúspěchu celého
projektu. Na začátku projektu by měla být také stanovena kritéria pro hodnocení vedoucího
projektu a celého projektového týmu.
Všechny tyto věci musí být řádně dokumentovány platnými dokumenty, které by měly
být také k dispozici v elektronické podobě. Je-li to vhodné, je potřeba využít specializovaných
programových produktů pro tyto účely (viz DOORS, RequsitePro, apod.).
Na začátku projektu by měly být stanoveny zásady k provádění změn v projektu,
zejména z hlediska postupu jejich schvalování.
Podobně to platí i pro všeobecnou administrativu projektu (podpisová práva, archivace
všech dokumentů, poskytování informací, čerpání rezerv, apod.).
Všechny specifikace musí být řádně dokumentovány.
Pokud nejsou na strukturu dokumentace, obsahující specifikaci projektu, vznesena
zvláštní požadavky, lze doporučit následující osnovu dokumentace, která by měla být
výsledkem předchozích přípravných fází:
1. Poslání projektu systému řízení jakosti
2. Přehled závěrů předprojektových fází
3. Specifikace obsahu projektu
4 Identifikační listina projektu
5. Logický rámec projektu
6. Síťová analýza projektu
6.1. Síťový graf zpracovaný metodou CPM
6.2. Časová analýza grafu
6.3. Nákladová analýza grafu
6.4. Zdrojová analýza grafu.
7. Analýza rizik projektu
8. Kritické faktory úspěchu projektu a případně i plán řízení jakosti
9. Komentář k očekávaným přínosům projektu
10. Zásady a normy platné pro řízení projektu
11. Celkové shrnutí a závěrečná doporučení k řízení implementace projektu
projektu
Různé přílohy k návrhu projektu (zejména kopie již uzavřených smluv na
externí dodávky)
V souvislosti s dokumentací projektu je potřeba zdůraznit, že dnes je potřeba
preferovat dokumentaci v elektronické formě! Nelze taské zapomenout, že kromě tzv.
návrhové dokumentace (viz výše), je potřeba vytvářet a archivovat průběžně s projektem
dokumentaci pracovní: zápisy z porad, zpracované zprávy o projektu, účetní a jiné
dokumenty, protokoly o schválených změnách, apod. (viz dále).
11.2 Kritické faktory úspěchu implementace projektu
Obecně platí, že kritické faktory úspěšného dokončení projektu lze odvodit
z Ishikawova diagramu pro jakostní průběh projektu:
Projektový
tým
Použité
metody
Počítačová
podpora
Jakostní
projekt
Aplikace
filosofie
TQM
Okolí
projektu
Jakostní
návrh
projektu
Pro úspěšný průběh projektu a jeho řízení je však důležité zajistit další postupy,
které se týkají operativního řízení :
•
•
•
•
•
•
•
•
Operativní termínové plánování
Operativní nákladové plánování
Operativní plánování zdrojů
Hlášení a kontrolu zahajovaných a ukončovaných činnostech
Hlášení a kontrolu výkonů, prováděných v činnostech
Hlášení a kontrolu vynaložených nákladů
Kontrolu jakosti všech prováděných činností
Operativní řízení a kontrolu nákupu
K tomu všemu je potřeba vytvořit dobrý informační systém, který zajistí distribuci
všech plánovaných úkolů včetně potřebných informací zodpovědným pracovníkům a sběr
potřebných zpráv o aktuálním stavu projektu. Všechny předávané zprávy ba měly být
protokolovány a ověřovány.
11.3 Řízení změn
Samostatnou zmínku zasluhuje problematika řízení změn (podrobněji viz též norma
ČSN/ISO 10007).
Často se setkáváme dnes s dvěma extrémními přístupy k řešení změn:
Odmítání změn - je pošetilý přístup, který kategoricky odmítá jakoukoliv změnu v projektu a
vyžaduje, aby jednou stanovené skutečnosti zůstaly po celou dobu projektu
neměnné.
Závislost na změnách - je opačný přístup, kdy se necháváme zmítat změnami, takže často v
důsledku jejich velkého počtu se původně řízený proces změní v chaos
ve smyslu přísloví: Kam vítr, tam plášť.
Racionální přístup ke změnám, vyplývající z principů řízení změn (Change
Management), postupuje následovně:
- identifikuje požadavky na změny
- vyhodnocuje dopad požadovaných změn včetně bilance náklady-přínosy
konkrétní změny, analyzuje možnost realizace změny
- rozhodne kompetentně o přijetí nebo odmítnutí změny na základě jejich
vyhodnocení a analýzy situace, případě si vyžádá vyjádření
kompetentních pracovníků
- akceptované změny se snaží kumulovaně promítat do projektu
- celý tento proces průběžně dokumentuje.
Mýlí se ten, kdo předpokládá, že jednou stanovený cíl můžeme fixovat jako neměnný
a jednou stanovenou cestu k němu za jedině možnou. Opak je pravdou! Proto je nutno hned
od počátku zajistit neustálé prověřování, zda stanovený cíl projektu je stále ten, ke kterému
má projekt směřovat. Proto je důležité si také od začátku také uvědomovat účel, který se má
cílem dosáhnout, a dále vazbu na strategický cíl, ze kterého byl cíl projektu odvozen. Jinak
ztratíme možnost takové prověřování provádět a dospět k nějakým závěrům.
V souvislosti s dynamikou cíle bude vhodné rozlišovat:
-Pohyb cíle (cíl se nemění, ale mění se jeho umístění v prostoru, který je vymezen časem,
náklady a zdroji), což vyžaduje zajistit sledování pohybujícího se cíle. Jsou to okamžiky.
kdy dochází k vnějším požadavkům na:
- změnu plánovaného termínu
- změnu plánovaných nákladů
- změnu požadavků na zdroje
- drobné, nepodstatné změny ve specifikaci cíle
-Změnu cíle (je potřeba se zaměřit na jiný cíl), což vyžaduje přehodnocení cíle a přenesení
pozornosti na tento jiný cíl. Důsledkem takové situace je:
- změna specifikace cíle
- zásadní přehodnocení projektu.
11.4 Vyhodnocení stavu projektu
Pro operační řízení implementace projektu je potřeba neustále porovnávat
plánovaný stav projektu se skutečným stavem, zjistit případné odchylky a provést
potřebná opatření k nápravě zjištěných diferencí.
ŘÍDICÍ PROJEKTOVÝ TÝM
PLÁN
PROJEKTU
ZJIŠTĚNÍ
SKUTEČNÝ
ODCHYLKY
ODCHYLEK
STAV PROJEKTU
ZPRACOVÁNÍ
NÁVRHU
OD PLÁNU
NA OPATŘENÍ
ŘÍDICÍ
ZÁSAHY
PROCESY
PROJEKTU
NÁHODNÉ RUŠIVÉ
VLIVY
Většina programových produktů má k dispozici prostředky, aby mohlo být indikováno
procentové plnění plánovaných úkolů, kde se v Ganttově diagramu nebo jen číselně u každé
činnosti zobrazuje procento z vykonané práce.
Činnost A
75%
Časová osa
Poznamenejme, že toto procentuální plnění činností musí být často blíže
specifikováno co do obsahu svého významu, zda představuje procento vykonané práce ze
zadaného úkolu. (Často se totiž vykazuje, procento vyčerpaných nákladů na činnost nebo
objem spotřebovaného času proti plánu, což zkresluje správnou představu plnění projektu).
Pokud jsou takto vyhodnoceny všechny činnosti, lze vypočítat orientační hodnotu - průměrné
plnění plánu projektu. Tato metoda je jednoduchá, ale s malou vypovídací schopností. Proto
se používá jen u projektů s počtem činností do 50. V řadě případů i programové produkty
předpokládají, že se jedné jen o navození přibližné představy o plnění projektu a dovolují
udávat jen plnění v odstupňování např. po 20% (0, 20, 40, 60, 80, 100).
Rozsáhlé projekty (několik stovek činností) využívají metody založené na analýze
dosažené hodnoty projektu (Earned Value Analysis) Dnes se tato metoda také označuje
zkratkou C/SCSC (viz dále). Tato metoda je použita např. u produktu Primavera Project
Planner.
Cílem analýzy dosažené hodnoty je vyhodnotit hodnotu vykonaného úsilí na projektu
v okamžiku kontroly, aby bylo možno posoudit časový postup projektu ve vazbě na
vynaložené náklady.
Vychází se ze souboru definovaných hodnot:
EAC
Estimate at Completion
odhad nákladů při dokončení
ETC
Estimate to Completion
odhad nákladů pro dokončení
BAC
BCWS
Budget at Completion
Budgeted Cost for Work
Scheduled
Budgeted Cost for Work
Performed
Actual Cost for Work
Performed
celkové rozpočtové náklady
rozpočtové náklady plánovaných
prací
rozpočtové náklady provedených
prací
skutečné náklady provedených
prací
BCWP
ACWP
Na základě těchto hodnot jsou definovány další veličiny:
CPI
SPI
CV
SV
AC
CWR
VAC
index plnění nákladů
index plnění plánu
nákladová odchylka ( +CV%)
časová odchylka (+SV%)
účetní odchylka
index rozpracovanosti
odchylka nákladů při dokončení
Pokud hodnoty uspořádáme
charakteristickou S křivku:
do
grafu,
tvoří
v souřadnicích
čas-náklady
EAC
$
BAC
ACWP
BCWS
BCWP
t
čas aktualizace
V bezproblémovém případě by mělo platit:
BCWS = BCWP = ACWP
V praxi, kde dochází k řadě odchylek od původního plánu lze seskupit typických 18
variant odchylek do tří skupin:
- pesimistický vývoj
- mírně optimistický vývoj
- velmi optimistický vývoj
Navyšování nákladů v průběhu projektu je způsobeno:
A) Dodatky k projektu
EV (expenditure variance) odchylka dodatků
Změny jsou nutné - proto je akceptujeme , ale zvyšují nám skutečné náklady ....
B) Inflací
IV (inflation variance) inflační odchylka
DCWP Deflated Cost of Work Performed
velikost skutečných nákladů snížených o nárůst inflace za sledované
období (reálné ceny nákladů přepočtené k termínu zahájení projektu)
S využitím hodnot indexů SPI a CPI je možno vyjádřit takto orientačně stav projektu:
Úspora nákladů
Projekt se zpožďuje
CPI
Úspora nákladů
Projekt je v předstihu
1,5
SPI
0.5
1
1.5
0.5
Náklady jsou překračovány
Projekt se zpožďuje
Náklady jsou překračovány
Projekt je v předstihu
Uvedené hodnoty a indexy včetně grafické reprezentace S křivek zajišťuje program
Primavera Project Planner. Bez počítačové podpory je využití této metody problematické.
Využití analýzy dosažené hodnoty pro rozsáhlé projekty odpovídají i používanému
programovému produktu, který se v takových případech nejčastěji používá.
Poznamenejme, že metoda je v poslední době označována též zkratkou C/SCSC
(Cost/Schedule Control Systém Criteria), protože zkratka EVA se již používá častěji ve
významu Economic Value Added
Pokud máme středně rozsáhlý projekt ( přibližně sto činností), u kterého převládají
spíše kratší činnosti, můžeme využít metody SSD (Structure - Status - Deviation). Základem
je přesně definovaný plán projektu (Structure). Ke dni kontroly vyhodnotíme, jaký má každá
činnost stav (Status):
• činnost dosud nezačala
• činnost právě probíhá
• činnost už skončila
Po té ke dni kontroly porovnáme stav s plánovaným průběhem činnost, abychom
získali případné odchylky. Pokud činnost probíhá podle plánu, má odchylku rovnu nule. V
ostatních případech přiradíme činnosti jednu z následujících hodnot:
• Hodnotu -2. Zpoždění druhého řádu, pokud činnost ještě nezačala, ale podle plánu již
mela skončit
• Hodnotu -1. Zpoždění prvního řádu, pokud činnost dosud nezačala, ale podle plánu již má
probíhat, nebo probíhá, ale podle plánu již měla skončit.
• Hodnotu +1. Předstih prvního řádu, pokud činnost již skončila, ale podle plánu by měla
ještě probíhat, nebo už probíhá, ale podle plánu ještě neměla začít.
• Hodnotu +2. Předstih druhého řádu, pokud činnost již skončila, ale podle plánu ještě ani
neměla začít.
Projektový tím tak získá poměrně názornou představu o dodržování plánu projektu,
zpoždění nebo předstihu činností projektu a může připravit potřebná opatření. Tato metoda
zatím není podporována zatím komerčním programovým produktem.
K velmi rozšířením způsobům vyhodnocování stavu projektu patří tzv milníková
metoda, označovaná též zkratkou MTA – Milestone Trend Analysis (Analýza trendů plnění
milníků). Spočívá v e stanovení většího počtu milníků projektu a v dekompozici kritérií
celkové úspěšnosti projektu postupně do jednotlivých milníků, které se pak postupně
v průběhu projektu vyhodnocují.
.
K problematice vyhodnocení aktuálního stavu projektu patří i zpracování příslušné
zprávy (Situační zpráva, Summary Report, Current Status Report, Progress Report,
apod.).Ten se zpracovává na základě hlášení o průběhu činností a zprávách o případných
problémech při jejich průběhu (ti, kteří zajišťují provádění činností musí však vždy hlásit
zahájení a ukončení činnosti bezprostředně ). Zpráva obvykle obsahuje:
• Konstatování posunu projektu proti poslední kontrole stav ve srovnání s plánem
• Sumární přehled plnění činností
• Výčet hlavních problémů
• Návrhy na opatření a konkrétní úkoly
• Jiné skutečnosti, na které je potřeba upozornit s ohledem na projekt
V praxi západních firem je běžné, že zpráva obsahuje i předpověď dalšího vývoje
projektu spolu s výhledem na ukončení projektu.
Předpověď projektu lze dosáhnout v zásadě následujícími způsoby:
• zjištěný aktuální stav projektu v čase a nákladech + zbývající čas a náklady
• zjištěný aktuální stav projektu v čase a nákladech + (zbývající čas a náklady násobené
indexem, který je vypočten na základě dosavadního a předpokládaného vývoje projektu větší než jedna zpožďování a překračování rozpočtu, menší než jedna při časovém
předstihu a úsporách)
• zjištěný aktuální stav projektu v čase a nákladech + nový plán času a nákladů.
Projektový tým volí variantu zpracování předpovědi podle vyhodnocení stávající
průběhu projektu a předpokládanému stavu disponibilních zdrojů a dalším okolnostem.
Archivovaný soubor podaných zpráv slouží k vyhodnocení průběhu projektu po jeho
ukončení.
Projektový tým musí rozhodnout, jak často žádat detailní zprávy o průběhu činností a
jak často organizovat pracovní schůzky.? Je evidentní, že v krajních případech může být tým
zahlcen zprávami, které nepřinášejí nic nového, nebo trpět nedostatkem informací. Nelze říci
přesné pravidlo. Je však možno doporučit několik zásad:
Zjistěte frekvenci vlivů, které působí na Váš projekt! Kolik odchylek v nákladech se
objevilo za určitou časovou jednotku (den, týden, dekádu, 14 dní, měsíc)?
Zjistěte velikost změn! Jak velké odchylky v nákladech nebo časových skluzech se
průměrně vyskytují?Jaká hodnota odchylek je nejčastější?
Odstraňte časová zpoždění! ( Zpoždění při podávání zpráv zjištění, zpoždění při
identifikaci, opožděné reakce řídicího týmu apod.). Časová zpoždění destabilizují
řízení!!!
Snažte se řízení podle odchylek zlepšit sledováním trendů (sezónní výkyvy v počtu
pracovníků, sezónní chřipkové epidemie, apod.). Předvídejte události!
Problematika podávání zpráv o probíhajících činnostech a vzkazování výkonů/nákladů
v rámci projektu patří do problematiky, která bývá označována jako projektový reporting.
11.5 Řešení krize projektu
Jestliže se projeví mnoho hrozeb současně, případně nastanou další nepředvídané
situace, může se dostat projekt do KRIZE. Taková situace znamená, že projektový tým ve své
kompetenci nemůže běžnými prostředky řídit nadále průběh projektu Jakmile
identifikuje projektový tým nebo vedení firmy krizovou situaci projektu, musí se opustit
způsob projektového řízení a přejít na ŘÍZENÍ KRIZE - krizové řízení. Krize projektu je
tedy situace, kdy je zásadním způsobem ohrožen úspěch projektu a je potřeba realizovat
mimořádné akce pro opětovné zajištění úspěchu projektu.
Krizový management rozeznává:
• Stadium symptomů krize. (Machiavelli:Dobrý vladař pozná rodící se krizi v jejím zárodku)
Jsou identifikovány zprávy, které signalizují možný výskyt takových situací jakými jsou:
mimořádné skluzy v termínech, vysoké překročení nákladů, výpadky disponibilních zdrojů
(obvykle personálních), které ohrožují plánovaný průběh projektu, projektový tým se stává
nefunkčním, je požadována zásadní změna cíle projektu, apod.
• Akutní stadium krize. Při kontrole stavu projektu jsou zjištěny skutečnosti, které ohrožují
úspěch projektu a projektový tým je nedokáže sám odstranit.
• Chronické stadium krize. Trvalá krizová situace v důsledku přetrvávání příčin krize se
nadále prohlubuje Toto stadium by mělo být co nejkratší.
• Vyřešení krize. Ustavený krizový štáb mimořádnými zásahy odstraní zásadní následky
krize a učiní opatření k odstranění příčin krize
Povšimněte si, že při dobře zvládnuté krizi se mohou objevit jen první a poslední
stadium!To by mělo být cílem každé firmy. Samozřejmě je nejlepší se do žádné krize
nedostat.
Po vyřešení krize může projektový tým (v původním nebo pozměněném složení) převzít
opět řízení projektu, který bude nadále řídit podle zásad projektového řízení.
Může se jednat o tentýž projekt, u kterého byly změněny některé plánované hodnoty
(v mnoha případech se jedná především o změny na úrovni identifikační listiny projektu navýšení plánovaných nákladů, posunutí termínu ukončení projektu, přidělení dalších zdrojů,
změna v cílech projektu, výměna vedoucího projektu).
Pokud však došlo k velmi hluboké krizi projektu, bývá někdy lepší ukončit takový
projekt a přepracovat jeho návrh jako nový projekt, navazující na ukončený projekt.
11.6 Informační zabezpečení
Éru, ve které žijeme, označujeme často termínem „Informační společnost - Information
Society“. Chceme tím vyjádřit, že informace představují dnes významný prvek pro fungování
naší společnosti pro všechny její oblasti (sociální, hospodářskou, kulturní a politickou). Platí
to i pro dosažení úspěšného projektu. Zejména u projektů, u nichž se jejich průběh dotýká
mnoha lidí nebo se mnoha lidí dotýká výsledná změna, kterou projekt navodí, představuje
správné zvládnutí poskytování informací všem dotčeným osobám významný faktor úspěchu.
Obecně se jedná o tři aspekty:
1. Zajištění dostatečných informací pro všechny, kteří jsou zainteresovaní na projektu
2. Efektivní využití informačních technologií pro podporu projektu.
3. Poskytování informací pro účinné řízení projektu
Problematikou předávání řídicích zpráv se zabývá kybernetika, ze které můžeme odvodit
potřebná pravidla pro dobře navržený způsob přenosu signálu a zpráv pro řízení.
Přenosový kanál
Zdroj
zpráv
Příjemce
Šum (poruchy )
V prvním případě by projektový tým měl při práci na projektu vyřešit:
- Poskytování informací o projektu jako nabídku těm, kteří vyžadují nebo projeví zájem o
informace, týkajíce se průběhu projektu
- Způsob, jak poskytovat informace o projektu a jeho průběhu projektu na vyžádání.
Znamená to systémově vyřešit následující soubor problémů:
•
•
•
•
•
•
K jakému účelu mají informace sloužit
Komu mají informace být poskytnuty
Jaké informace mají být poskytnuty
Kolik jich má být poskytnuto (v jakém rozsahu)
Kdy mají být informace poskytnuty
Jakým způsobem mají být poskytnuty a presentovány.
Zdroj, který bude zajišťovat nabízení i vyžádaní informace musí samozřejmě garantovat :
•
Správnost poskytovaných informací
•
Srozumitelnost poskytovaných informací
•
Aktuálnost poskytovaných informací
Vyřešení všech těchto informací představuje vlastně zpracovat návrh jakostního
informačního systému pro příslušný projekt. Vždy je potřeba prověřit a rozhodnout, které
informace jsou naopak z hlediska realizace projektu natolik specifické, že je potřeba zajistit
jejich důvěrnost a zabránit, aby je získaly nepovolané osoby, které by je mohly zneužít.
Druhý aspekt vyžaduje, aby projektový tým v potřebném rozsahu využíval počítačové
podpory projektového řízení ve všech fázích návrhu a realizace projektu. Jedná se především
o efektivní využívání:
•
•
•
•
•
•
programů, podporujících využívání síťové analýzy při návrhu a řízení projektu
programů, podporujících různé další využívané metody (tvorba logických rámců
modelování a simulace projektů, statistická analýza, apod.)
programů pro podporu komunikace (Groupware, Teamware, Internet, apod.)
zařízení pro videokonference, počítačovou prezentaci, apod.
údajů, uložených v databázích různých firemních i veřejných informačních systémů.
Třetí aspekt komentován v souvislosti s vyhodnocením stavu projektu.
11.7 Pracovní dokumentace
Kromě výchozí dokumentace musí projektový tým vést též pracovní dokumentaci,
která dokumentuje průběh projektu. Pracovní dokumentaci tvoří zejména záznamy z porad
projektového týmu, záznamy různých situačních zpráv, záznamy o vykazování prováděných
činností, záznamy rozhodnutí apod.
Tato dokumentace v našich týmech často chybí. Absence této pracovní dokumentace nejen
ztěžuje vlastní řízení projektu, ale znemožňuje účinné provádění post implementační analýzy
v poprojektových fázích.
Často slyšíme od pracovníků firem tvrzení, že implementace projektu je ta nejsložitější fáze
ne rozdíl ode všech ostatních fází projektů a většinou je toto tvrzení v našem regionu
přijímáno velmi souhlasně. Z toho vyplývá skutečnost, že u mnoha firem (i v ČR) je této fázi
věnována rozhodující pozornost a to na úkor pozornosti pro ostatní fáze.
Je to v přímém rozporu s tvrzení odborníků z vyspělých západních zemí. Ti považují
tuto fázi za jednu z nejjednodušších. Přou se mezi sebou, zda je důležitější předprojektové
fáze, zahajovací fáze nebo dokonce zda není pro úspěšné řízení projektů rozhodující fáze
vyhodnocování projektů
Rozdíl není jen v přisuzování důležitosti a i v objemu času a prostředků, které jsou
věnovány jednotlivým fázím. V ČR je objem prostředků a zdrojů rozhodně soustřeďován na
fázi implementace projektu, což je ostatně pro některé projekty pochopitelné (např.
výstavbové). Na v západních zemích lze však najít mnoho případů, kdy na předprojektové
úvahy a na plánování projektu bylo vynaloženo mnoho času, financí a úsilí, aby pak rychle a
bez větších problémů proběhla implementace projektu.
Západní odborníci dávají rozhodně přednost důkladné přípravě projektu před
zvýšeným úsilím ve fázi implementace. U nás je tendence vynechávat předprojektové úvahy a
odbývat přípravu projektu a mobilizovat pak všechno úsilí v době implementace projektu.
K naší škodě je nutno poznamenat, že počet úspěšných projektů hovoří ve prospěch přístupu
západních projektových manažerů.
11.8 Ukončení projektu
Ukončení projektu je významná životní fáze projektu. Vyplývá ze základní definice
projektu, neboť projekt je charakterizován daty zahájení a ukončení.
V některých odborných oblastech, např. ve stavebnictví nebo ekologii, bývá
doporučováno zahrnout do projektu i provozování objektu resp. jiného výstupu projektu.
Pokud doba nepřesáhne rozumnou dobu, takže celková délka projektu se pohybuje
v doporučené délce maximálně 2 až 3 roků a je bezprostředně spojena např. s ukončením
životnosti objektu, je takové řešení možné. V jiných případech je lépe tyto věci od sebe
oddělit!
V opačném případě, kdy délku provozování nelze odhadnout a předpokládá se, že
může trvat i desítky let, není vhodné zahrnovat etapu používání resp. etapu provozu do
životního cyklu projektu. Tím nemá být řešeno, že v případě např. fyzické likvidace
stavebního objektu bychom nemohli provést vyhodnocení této etapy a při jejím hodnocení se
vrátit i vyhodnocení projektu, jehož byl výstupem a zpracovat doporučení pro podobné
projekty. Protože v případě automatizačních projektů obvykle nedovedeme odhadnout
plánovaný okamžik inovace řídicího systému, doporučuje se oddělit etapu provozování
řídicího systému, a vyčlenit ji jako samostatnou fázi, oddělenou od vlastního projektu návrhu
a realizace.
V dalším textu příspěvku budeme předpokládat, že „ukončení projektu“ je poslední
fází průběhu projektu, těsně před zahájením provozu, a že je spojeno s takovými pojmy jako
např. ukončení komplexních zkoušek, ukončení zkušebního provozu, předání k rutinnímu
provozu, najetí na ostrý provoz, apod.
Ukončení projektu znamená dokončení prací v rámci projektu jakmile bylo dosaženo
výsledků/cílů. Kombinuje dva procesy: jednak finální dokončení hmotných výstupů projektu
a jejich přijetí objednatelem, jednak zdokumentování a předání veškerých poznatků
získaných v rámci projektu, za účelem následného vyhodnocení.
Předání hmotných výstupů projektu probíhá podle určitého postupu, který by měl být
předem odsouhlasen objednatelem projektu a vedoucím týmu řízení projektu. Hlavním cílem
je:
- předání dokumentace produktu, zkušebních protokolů, inspekčních zpráv
- konečné posouzení finanční situace (poprojektová kalkulace)
- konečná zpráva a dokumentace projektu
- seznam otevřených položek a dokončovacích prací (jestli takové případy jsou)
- dohoda o dalším zaškolení, zárukách a jiných závazcích např. dodávky náhradních
dílů, pozáruční servis, apod.)
- převzetí díla do majetku objednatele.
Nejčastější a rozhodující podmínkou k ukončení projektu je tedy realizace konkrétního
výstupu projektu, který byl specifikován jako cíl projektu. V praxi to znamená, že pokud není
realizován takto stanovený cíl projektu a splněna tato podmínka, pokračuje projekt dále, čímž
dojde k prodloužení projektu a často i navýšení celkových nákladů na projektu proti
původnímu plánu, dokud není cíle dosaženo. Z hlediska projektového řízení je pak takový
projekt na svém konci označen jako neúspěšný projekt, protože cíle bylo dosaženo po
plánovaném termíny a se zvýšenými náklady proto plánovanému rozpočtu.
Je potřeba však upozornit na skutečnost, že existují projekty, u kterých může být
podmínka končení projektu stanovena jinak, a to:
• Vyčerpáním přiděleného rozpočtu. Např. řada humanitárních nebo
charitativních projektů neziskových organizací je končena právě z těchto
příčin, i když nebylo dosaženo plánovaného konkrétního výstupu (počtu
obdarovaných lidí, počtu zakoupených zdravotních pomůcek pro postižené
osoby, aj.)
• Dosažením určitého kalendářního data. Řada projektů rozpočtových
organizací je ukončena ke konci kalendářního roku, ve školství ke konci
školního roku, apod.
• Kombinovaným způsobem, že ukončení projektu nastane buď realizací
plánovaného konkrétního výstupu nebo jakmile dojde k vyčerpání
plánovaného rozpočtu nebo se ukončí k určitému kalendářnímu datu.
Na tuto skutečnost bychom neměli zapomínat, a pokud je ukončení svázáno
s takovouto podmínkou, musí to být zřetelně uvedeno při zahájení projektu v jeho zakládací
listině!
Pokud je projekt ukončen v souladu s podmínkou, která byla na začátku projektu
stanovena, jedná se o řádné ukončení projektu. Projektové řízení však obsahuje i pojem
mimořádné ukončení projektu též také někdy označované jako předčasné ukončení projektu.
Projekt je ukončen, aniž by byla splněna podmínka řádného ukončení projektu. Protože se
jedná o významnou skutečnost v životním cyklu projektu, bude tato problematika rozebrána
v samostatném odstavci.
V projektové praxi může nastat i případ, kdy z určitých důvodů může dojít
k pozastavení projektu. Projekt není ukončen, ale je dočasně přerušeno jeho provádění. Po
určené době nebo při splnění určitých podmínek pak dochází k pokračování projektu. Takové
přerušení projektu může být vyvoláno různými okolnostmi jako např. změna legislativních
podmínek, nevyjasněnosti v plánu projektu, mimořádná událost, řešení požadavku na
mimořádnou změnu, apod. Stav takového projektu bývá obvykle označován jako pozastavený
projekt v některých firmách se hovoří o zmraženém projektu. Pozastavený projekt musí být
opět aktivován, hovoří se o provedení aktivizace pozastaveného projektu, při níž může dojít
často i k úpravám některých skutečností v zakládací listině projektu (posun plánovaného
termínu ukončení, navýšení rozpočtu, přeplánování některých akcí, změny ve složení
projektového týmu, apod.).
Je důležité připomenout, že jak mimořádné ukončení projektu, tak pozastavení a
aktivizaci projektu, je nutno vložit do směrnic, které mají ve firmě stanovit zásady pro průběh
projektů.
S ukončením projektu je svázána potřeba stanovit kritéria, která mají jednoznačně a
objektivně umožnit vyhodnocení, zda cíle projektu bylo dosaženo. Problematika stanovení
kritérií se svázána s fází zahájení projektu a je její řešení je podporováno metodou logického
rámce.
Projektový tým si musí pečlivě připravit předem seznam všech dokumentů, které se
musí vytvořit pro řádné ukončení projektu a kontrolovat, aby se na žádnou listinu
nezapomnělo a aby všechny listiny měly všechny náležitosti a správný obsah. Velkou
pozornost je potřeba věnovat komisionálnímu předávání výsledků, přípravě zkušebního
provozu nebo závěrečným zkouškám.
Projektový tým by měl zahájit fázi zpracování upřesněného harmonogramu ukončení
projektu.
Důležité je připravit vyhodnocení kritérií pro ukončení projektu. Pro ta kritéria, která
byla změněna v průběhu projektu je potřeba připravit podklady, které dokládají proces
projednání a schválen příslušné změny podle zásad normy ISO 10 007.
Vedoucí projektu si musí pečlivě připravit návrh na rozdělení cílové odměny, aby
spravedlivě ohodnotil činnosti jednotlivých členů projektového týmu.
Projektový tým by měl zpracovat zodpovědně zprávu o průběhu projektu, aby
vypovídala objektivně o důležitých skutečnostech v průběhu projektu a byla použitelná pro
závěrečné vyhodnocení projektu.
Projektový tým by neměl zapomenout na sestavení všeobecné informace o dosaženém
výsledku projektu, aby si zajistil propagaci svého snažení v odborném i denním tisku. Pokud
se jedná o úspěšné ukončení projektu, doporučuje se zorganizování vhodného slavnostního
rámce pro závěrečný okamžik (přestříhávaní pásky při vstupu, uvedení do provozu
spouštěcím vypínačem nebo ventilem, přebírání prvního vyrobeného kusu, apod.). Je
zajímavé, že v české kotlině se na těmto věcem nevěnuje příliš pozornost. Výjimkou jsou
firmy stavební nebo pokud je firma v ČR vlastněna západním kapitálem.
Projektové řízení nepoužívá žádnou zvláštní metodu, která byla speciálně určena
pro fázi ukončení projektu. Doporučují se jen obecné techniky, které jsou samostatně
komentovány v odst.5.
Jak již bylo řečeno, projekt může být mimořádně ukončen, aniž by byla splněna
podmínka řádného ukončení projektu. Podnikové a jiné směrnice, týkající se řízení projektů,
by měly na tuto skutečnost pamatovat.
Pravomoc mimořádně ukončit projekt má obvykle vyhlašovatel projektu, který
podepsal listinu, zakládající projekt. Jestliže je projekt předmětem smluvního vztahu, musí
s mimořádným končením projektu souhlasit smluvní strany a musí být dodržena sjednaná
pravidly pro její mimořádné ukončení resp. vypovězení.
Důvody pro mimořádné ukončení projektu mohou být různé:
• Pominul důvod dosáhnout cíl (např. konkurence již takový výrobek
uvedla s předstihem a daleko ambicióznějšími parametry, takže další
vývoj výrobku s nižšími parametry ztratil smysl; změněná situace na trhu
změnila i požadavky zákazníků, takže je jasné, že o vyvíjený výrobek
nebude zájem; náhlá změna ve financování projektu nedovoluje
uspokojovat jeho potřebné náklady; zákazník pozbyl solventnosti, takže
je jasné, že nebude schopen dostát závazkům, apod.).
• Rozhodnutí vedení např. v důsledku změny firemní strategie (nebudeme
modernizovat stávající tuzemskou výrobní linku, výhodnější je postavit
novou v zahraničí, kde je levná pracovní síla a momentálně velká
příležitost získat velmi výhodné podmínky, apod.).
• Bylo zjištěno, že cíl projektu a podmínky jeho realizace byly nesprávně
stanoveny a jsou např. nereálné, apod. (toto může být např. zjištěno i
projektovým týmem při navrhování podrobného plánu projektu).
• Z vyšší moci (vis major) např. rozpoutání válečného konfliktu nebo
závažných náboženských střetů v místě realizace projektu, vyhlášení
embarga na vývoz nebo dovoz v důsledku obchodní blokády, apod.
• Zásadně se změnil cíl nebo podmínky cesty k cíli.
• Příčinou je nějaká katastrofická událost (např. zemětřesení zničilo
dosavadní stavební práce).
• Apod.
Obecně platí, že firma a projektový tým by měly umět mimořádně ukončit projekt
v kterékoliv fázi projektu. V automatizačních projektech se snad nejčastěji vyskytuje důvod,
morálního zastarání návrhu předmětu projektu ještě před dokončením projektu.
Je důležité zdůraznit, že mimořádným ukončením projektu nemusíme definitivně
resignovat nebo odstoupit od dosažení cíle. Jen jsme se rozhodli, mimořádně ukončit tento
projekt, který byl buď špatně nastartován, nebo reagujeme na nějakou mimořádnou událost.
Později můžeme nastartovat projekt s tím samým resp. pozměněným cílem za jiných
(výhodnějších) okolností a s jinými parametry (termín ukončení, náklady, dodané zdroje,
modernější technické řešení s novými automatizačními prostředky, apod.), které lépe reagují
na momentální situaci.
U nás panuje velká obava, že mimořádným ukončením projektu přiznáme, že jsme
některé okolnosti nezvládli, nebo že jsme zjistili závažný nedostatek v projektu. Západní
firmy naopak často velmi vysoce hodnotí svou schopnost mimořádně ukončit projekt a
zastavit tak často nesmyslné vynakládání finančních prostředků či nežádoucí blokování jiných
zdrojů, včetně lidských. Považují to za svůj úspěch! Za velkou chybu a neúspěch by
považovaly situaci, kdy by se vytrvale snažily dokončit projekt, jehož cíl ztratil smysl nebo
byl špatně naplánován.
Problémem mimořádného ukončení projektu je především vlastní průběh ukončení
projektu, který je potřeba vždy specificky připravit. Mnoho firem ukončuje mimořádně
projekt prostřednictvím krizového řízení. Při sestavování průběhu mimořádného ukončení
projektu můžeme vyjít z procesu řádného ukončení projektu a jednotlivé skutečnosti postupně
modifikovat s ohledem na potřeby mimořádného ukončení projektu.
Nepříjemným a složitým problémem je návrh řešení, jak se vypořádat s nevratnými
skutečnostmi. Takovými mohou být např. nedokončené stavby, některé terénní úpravy
krajiny, adaptace staveb nebo nevratné úpravy stromů, apod. Snad nejlepším řešením je najít
pro ně jiné využití nebo jinak maskovat jejich původní účel (viz např. přeměnu betonových
základů nedostavěného hotelového komplexu v horní části Mariánských lázní na visuté
květové terasy s leknínovým jezírky v návaznosti na sousedící park pod lázeňskou
kolonádou).
Po ukončení projektu se provádějí poprojektové fáze:
• Analýza ukončeného projektu.
• Návrhy na zlepšení pro další projekty.
Poprojektové fáze mají velký význam pro zlepšování úrovně projektového řízení a
kvality projektů. Proto je potřeba věnovat jim velkou pozornost.
Poprojektovou analýzu provádíme s využitím systémové postimplementační analýzy.
Můžeme také s výhodou využít Paretovy analýzy (20% příčin má za následek 80% potíží
v projektech) a Ishikawových diagramů.
Poprojektovou analýzu by měl provádět tým, složená nejen z členů projektového
týmu, ale i z pracovníků, kteří se projektu neúčastnili, aby se zajistilo kritické posouzení
průběhu projektu.
12 Týmová práce a organizace týmů při implementaci
řídicích systémů
12.1 Týmová práce
Při vyhodnocování projektu je potřeba analyzovat i práci projektového týmu.
O práci v týmu se v posledních letech hovoří v mnoha souvislostech. V praxi se
s touto oblastí setkáváme zejména při sestavování týmů, při hledání optimální výkonnosti a
efektivního využívání zdrojů, při doporučení vhodného vzdělávání a směru profesního
rozvoje pracovníků, stejně tak jako v řízení a vedení pracovních skupin.
Zaujmeme-li pohled psychologa, můžeme na tým pohlížet jako na skupinu
spolupracovníků, kteří se navzájem doplňují svými schopnostmi, znalostmi a osobnostními
předpoklady, mají společný cíl a jednotný přístup k práci, za svou práci jsou pak odpovědni
jak individuálně, tak i jako celek. Nebo jinak. Tým je pracovní skupina, jejíž členové se
vzájemně doplňují, pracují na bázi vysoké motivace ke splnění pracovního úkolu a řídí svoji
práci především demokratickými metodami.
Hledá-li psycholog ty nejhodnější typy pracovníků do týmu, kterých faktorů si všímá?
Postup je následující:
V prvé řadě důkladně specifikuje skutečné a konkrétní úkoly do daného týmu. Nestačí si říci,
že členové „mají klást na sebe i na druhé vysoké požadavky“. Co to konkrétně znamená ve
studovaném týmu? Má jít o pracovníky, kteří jsou schopni extrémně vysokého, ale spíše
krátkodobého nasazení, jež se periodicky opakuje, nebo raději o pracovníky, kteří se zaučí a
pak dovedou pracovat vytrvale a dlouhodobě v zavedeném tempu? A co konkrétně znamená
vysoké nasazení – patří sem i potřeba pracovat přesčas? (Co potom uděláme s velmi vhodným
typem pracovníka, jehož žena je na mateřské dovolené a opět čekají rodinu? Lze velmi
jednoduše a logicky vyvodit závěr, že v nejbližší době budou naše požadavky odsunuty na
stranou…..) Jindy se dozvíme, že organizace potřebuje lidi „zapálené pro úspěch“. Co je tím
úspěchem? Ekonomický výsledek nebo nastolení dobrých mezilidských vztahů jako základu?
Bude se jednat o projekty dlouhodobé nebo spíše krátkodobé? Nakolik budou moci členové
týmu časový faktor ovlivnit? Podobným způsobem se specifikují všechny obecně nastíněné
požadavky. Vždy se dají najít ty zvláštní a jedinečné právě pro daný kolektiv.
Z konkrétních požadavků pak dedukujeme potřebné vlastnosti (případně dovednosti a
zkušenosti) jednotlivých členů. Z těch pak odvozujeme a hledáme osobnostní a
temperamentové charakteristiky, které jsou základem nebo předpokladem pro hledanou
vlastnost. Můžeme si např. připravit tabulku, kde do jednoho sloupce vypíšeme požadavky na
vlastnosti, do druhého pak hledáme a vyvozujeme osobnostní charakteristiky:
Potřebné vlastnosti
Charakteristiky, kterých si všímáme
Schopnost spojit individuální schopnosti, Emocionalita a obvyklé zvládání emocí a
dovednosti
a
nabyté
zkušenosti
a citů, umístění na škále introverze –
spolupracovat tak s ostatními.
extroverze, rychlost vnitřní a vnější adaptace
na nové prostředí, míra dominance
v komunikaci, způsob komunikace a míra
empatie atd.
Schopnost přijímat řešení,
vlastního návrhu.
které se liší od Tendence riskovat či být konzervativní,
schopnost
přizpůsobit
se,
uznávání
přirozených i oficiálních autorit, míra hledání
kompromisů v mezilidských vztazích.
Vidět skutečné priority.
Tendence k dlouhodobému či operativnímu
plánování, schopnost dodržovat zákony a
stanovená pravidla, míra povrchního vnímání
reality, důkladnost a systematičnost, míra
perfekcionismu.
Tvořivý přístup k úkolům.
Introverze – extroverze, míra průbojnosti a
asertivity, míra netradičního pohledu na
každodenní situace, míra individuality a svým
způsobem i egoismu.
Schopnost pracovat pod sebekontrolou i pod Umění přijímat kritiku a styl jejího vnitřního
kontrolou ostatních členů týmu.
zpracování, schopnost měnit operativně svá
stanoviska (pokud se vyskytnou oprávněné
důvody), začleňovat nové informace do
stávajícího rámce, míra autority v chování a
míra přijímaní autority, schopnost jasné
komunikace, osobní hodnotový žebříček.
Úkolově zaměřené chování.
Zaměření na ekonomické zřetele nebo na
mezilidské vztahy, míra systematického a
nárazového přístupu k práci, způsob vedení
skupiny, míra ovládání emocí.
Zastoupit chybějícího člena (nebo zvládnout Způsob chování v zátěžových situacích,
část jeho povinností).
schopnost a doba odolávání stresu, způsob
komunikace s okolím v těchto situacích.
Podle konkrétní situace pak lze pokračovat podle potřeby. Po zpracování tabulky
zkontrolujme vlastnosti, na které je vhodné se zaměřit (zvlášť věnujeme pozornost těm, které
se často opakují) a určíme si na jednotlivé pracovní pozice potřebnou (nejlépe ideální) míru
těchto vlastností.
Vodítkem mohou být nejznámější klasifikace týmových rolí (Belbin, Margerison a
McCann). Kromě toho, že jsou dobře pochopitelné, může již i laik usoudit, jakou roli jedinec
v týmu plní a jakou pozici by měl zastávat, stejně tak může i předvídat, jaké tendence, styl
chování a nejčastější reakce zřejmě bude mít.
Tak u monitorovače – vyhodnocovače budeme očekávat, že nejlepší výkonnost bude
mít na pozici, kde může hledat detaily, analyzovat problémy, vyhledávat nové informace,
dávat podklady pro rozhodovací procesy. Sám raději rozhodovat nebude – na to je příliš
důkladný a seriózní. Pokud jej do této nevhodné role postavíme, zaniknou jeho přednosti,
neboť se z nich stane brzda. Naopak u tvůrce – inovátora budeme předpokládat, že jeho
rozhodování bude rychlé, často pramenící spíše z intuice než z logického přehodnocování, že
bude spíše extrovertní a tím i společenský. Tyto schopnosti z něj udělají člověka, který se
velmi rychle a efektivně adaptuje i na nezvyklé podmínky a „zapadne do kolektivu“ bez
větších problémů. V nezvyklých situacích bude využívat známé a každodenní informace,
zcela spontánně je použije nějakým – pro nás ostatní – neobvyklým způsobem. Nerad však
bude dlouhodobě plánovat a ještě s menší radostí bude takové plány dodržovat. A přijatá
pravidla jej zavážou podstatně volněji než jeho předchozího kolegu. Kontrolor a dokončovač
má svou silnou stránku ve schopnosti nepřehlédnout chybu, analyzovat skončené a uzavřené
projekty a tak se svým způsobem poučit z minulých chyb. Co však tento zpravidla málo
oblíbený pracovník (ale v každém týmu k nezaplacení) však prožije na pozici vedoucího
pracovníka, si lze velmi živě představit.
Pro vedoucího projektového týmu má popsaný rozbor důležitý význam i v další práci,
nejen při výběru nových pracovníků. Umožní mu ozřejmit si skutečné požadavky týmu, ale
také poukáže na motivaci a možnosti vedení jednotlivých členů. Jinak potřebuje povzbudit
pracovník typu inovátora a jinak typu realizátora. Rozdílný je také způsob jejich motivace,
podávání zpětné vazby, jinak na ně působí kritika. Také oni sami se odlišně prosazují (a tím i
ovlivňují) u svého vedoucího.
21.2 Porady projektových týmů
Porady týmů můžeme rozdělit podle různých hledisek., zde použijeme dělení podle
místa a času porady:
- FACE TO FACE porada
- Distrubuovaně z hlediska místa – synchronní porada
- Distribuovaně z hlediska času i místa- asynchronní porada
- Asynchronní porada.
FACE TO FACE porada
Představuje klasickou poradu, kdy všichni účastníci se vyskytují na jednom místě
ve stejný čas. Počítačovou podporu v takovém případě můžeme využít k prezentaci
myšlenek jednotlivých členů týmu takovými presentačními programy jakým je např.
Power Point od firmy Microsoft, k záznamu diskusních příspěvků jednotlivých členů
týmu a k zapsání konečného řešení diskutovaných problémů různými textovými editory.
Zejména pokroky v přímém převodu mluveného slova do alfanumerického textu
prostřednictvím počítače slibují v blízké budoucnosti rozšířené využití počítačové
podpory k záznamu průběhu porad, když dnes je možno použít již běžně osobního
počítače jako náhradu klasického magnetofonu. Pro převod anglicky mluvené řeči na
alfanumerický text nabízí v současné době pro počítače třídy PENTIUM firma IBM
program Via Voice za necelých 100$.
Distribuované místo -synchronní porada
Případ, kdy v jednom časovém okamžiku zasednou členové týmu k poradě na
různých místech naší planety, je totožný s pojmem videokonference. Pro zajištění
videokonference lze použít specializovaných videokonferenčních zařízení, která většinou
využívají telekomunikačních satelitních družic. Dnes však lze tento způsob porady týmu
realizovat ve firmě prostřednictvím lokální počítačové sítě nebo s využitím některé
počítačové sítě, která využívá dálkového přenosu dat např. INTERNET. Např. americká
firma PICTURETEL nabízí své služby k pořádání videokonferencí jak na síti
INTERNET, tak na sítích typu ATM.
Distribuovaně - asynchronní porada
Elektronická pošta umožňuje realizovat poradu týmu, kdy členové týmu pracují
na svých pracovištích, která jsou od sebe vzdálena a to v časově odlišných okamžicích.
Tento způsob vzájemné komunikace je znám z počítačové sítě INTERNET, kde je tento
druh internetovských konferencí hojně rozšířen.
Asynchronní porada – distribuované místo i čas
Tento typ porady vznikne, pokud členové týmu používají počítač v různých
časových okamžicích, který je propojený s počítačovou sítí. Vzniká typická elektronická
konference.
Groupware a teamware
Má-li být počítačová podpora týmové práce opravdu efektivní, nelze spoléhat , že
všechny potřebné funkce zajistí běžné progamové vybavení, a to přesto, že současné
standardní programové vybavení je navrhováno stále více s ohledem na podporu
týmové práce (viz např. poslední verze produktu Microsoft Office).
Speciálně na podporu týmů jsou zaměřeny produkty označované termínem
groupware a teamware. Obecně můžeme za produkty typu groupware považovat ty,
které umožňují společné sdílení dokumentů jednotlivými členy týmu, a za produkty typu
teamware ty, které umožňují řídit tok dokumentů, které kolují mezi členy týmu
(workflow).
GROUWARE – společný přístup (sdílení ) dokumentů v pracovní skupině
Uživatel 1
Uživatel 2
Centrální DB
Uživatel 3
Uživatel 4
Schéma k fungování forkflow technologie:
WORKFLOW – řízení pracovního oběhu dokumentů
Uživatel 1
Uživatel 4
Uživatel 2
Centrální DB dokumentů
Uživatel 3
Tyto programové systémy využívají služeb elektronické pošty, funkcí systémů
pro tvorbu a správu dokumentů, služeb databázových systémů a doplňují je o specifické
funkce pro práci v týmech (např. schvalování návrhů hlasováním). Pro organizování
práce členů týmů využívají tyto produkty funkcí produktů elektronických kalendářů,
pokud je sami neobsahují ve specializované podobě (Time Management).
12.3 Začlenění týmu do organizační struktury firmy
Projektový tým nemá být příliš početný. Doporučená velikost je 7(+/-2). Pokud počet
členů týmu přesáhne 10, je potřeba provádět zvláštní opatření, aby práce projektového týmu
byla efektivní.
Projektový tým obvykle pracuje mimo organizační strukturu. Proto je nutno, aby jeho
členům, zejména vedoucímu projektu byly předány potřebné pravomoci pro zdárné řízení
projektu. Existují různé možnosti, jak začlenit projektový tým do stávající organizační a je
potřeba vždy podle situace vybrat nejvhodnější variantu
.
.
.
.
Projektový tým mimo stávající funkční organizaci
Projektový tým jako součást organizační struktury
Několik paralelně pracujících projektových týmů v projektově řízení firmě.
Pokud ve firmě existuje jak funkční organizace, tak několik paralelně
pracujících projektových týmů, hovoříme o maticové organizační struktuře.
Maticová organizace
Klasická funkční struktura
Projektové týmy
Maticová organizační struktura
Pro realizaci projektů software vytváříme často specializované týmy. Uveďme dva
nejznámější příklady:
- tým hlavního programátora:
Chief Programmer Team
(Harlan Mills - IBM)
Chief Prog
Co-Prog
Co-Prog
Secr Prog
- chirurgický tým
Surgeon Team
Secr
Admin
INSTR PROG
INSTR PROG
SURGEON
SEC PROG
SEC PROG
INSTR PROG
Spec Prog A
INSTR PROG
Spec Prog B
12.4 Praktická doporučení k práci projektových týmů
•
•
•
•
•
•
Projektový tým by neměl být velký. Optimální velikost bývá doporučována 7 +/- 2. Za
minimální je možno považovat velkost projektového týmu o třech osobách.
Maximální velkost bývá uváděna 15 nebo 20 osob. Pak už je velmi obtížné dosáhnout
demokratického vedení projektového týmu. Ale kdykoliv má projektový tým více
členů než deset, musí vedoucí týmu i členové zajišťovat speciální opatření, aby tým
pracoval efektivně.
Projektový tým musí mít svého vedoucího, který je současně vedoucím projektu.
Vedoucího týmu buď vedení firmy jmenuje a umožní mu vybrat si členy svého
projektového týmu nebo jsou jmenování členové projektového týmu a umožní se jim,
aby si zvolili mezi sebou vedoucího (většinou se to děje takto v charitativních a
sociálních projektech). Vedoucí projektového týmu musí mít nejen potřebné znalosti
projektového řízení, ale i příslušné schopnosti vedení pracovníků (leaderschip).
Při výběru konkrétních členů týmu, je dobře uplatnit tři hlediska: Hledisko aktérů
změny (iniciátor změny, uživatel změny, realizátor změny, investor změny,, apod.. –
zde se uplatní i hledisko specifického profesního zaměření), hledisko týmových rolí
(nejlépe podle amer. psychologa prof. Belbina , který definoval 8 týmových rolí) a
hledisko pozitivních a negativních osobnostních typů (v týmu by měly převažovat
pozitivní typy). Vybraní pracovníci by měli být schopni se nadchnout pro společnou
týmovou práci (teamspirit). Často k tomu může posloužit tzv. sebeidentifikace týmu,
kdy členové týmu se snaží zodpovědět společně na základní otázky kolem své práce.
Projektový tým musí mít vytvořeny dobré organizační i jiné podmínky ke své práci.
Nesmí se zapomenout, že i když sestavíme tým ze sebelepších pracovníků, nebude
pracovat ihned efektivně. Členové týmu se musí nejprve seznámit, zformovat svoje
role v týmu, nastavit pracovní a komunikační standardy, apod.. Pak teprve může dojít
k efektivní práci.
Nesmí se zapomenout na správnou motivaci a stimulaci členů projektového týmu.
Na závěr je potřeba zdůraznit:
Myšlenka kooperativní spolupráce na projektu je pro řízení projektu zásadní
•
•
•
Získejte pro ni všechny účastníky
projektu!
Vytvořte vhodné podmínky pro
spolupráci!
Důsledně ji prosazujte během celého
projektu!
Proto bychom kooperativnímu způsobu realizace projektu měli věnovat velkou pozornost,
protože patří mezi klíčové faktory úspěchu.
13 Analýza rizik projektů automatizovaných řídicích systémů
13.1 Rizikové inženýrství
Rizikové inženýrství (Risk Engineerig) je technicko-ekonomická disciplína, která se
zabývá problematikou rizika. Riziko je v ní chápáno jako možnost utrpět určitou ztrátu.
Využívá statistiky a pravděpodobnosti pro výpočet možné ztráty
Slovo pochází se staré italštiny, kde znamenalo v oblasti námořní dopravy nebezpečí u
pobřeží nebo přístavu, kterému je potřeba se vyhnout.
První známý obraz analýzy nebezpečí z knihy Giorlama Catanea Dell´ Arte Militare
Libri Tre z roku 1567. Ve své době byla kniha bestsellerem. Proto mohl prof.M. Tichý (náš
odborník na rizikové inženýrství z ČVUT Praha FAST) najít ještě po 425 letech u nás její tři
různá vydání.
Negativní působení různých náhodných, nepříznivých vlivů z okolí projektu může
negativně ovlivnit průběh projektu, který pak může skončit neúspěšně.
Rizikové inženýrství vypočítává hodnotu rizika, jako součin pravděpodobnosti
nepříznivé události a hodnoty možné ztráty:
Hodnota rizika = pravděpodobnost x ztráta
Protože pravděpodobnost je bezrozměrné číslo, je hodnota rizika vyjádřena v měnové
jednotce, ve které vyjádříme možnou ztrátu.
V technické praxi (strojírenství, stavebnictví, elektrotechnika) se v některých
případech riziko ohodnocuje jen mírou pravděpodobnosti vzniku určitého stavu nebo
události..
Rizikové inženýrství používá řadu různých metod pro různé případy stanovení rizika
v pojišťovnictví, bankovnictví, v technické praxi, provozní praxi chemických zařízení a
dalších oblastech jako např. metody HACCP, HAZOP, RISK FMEA, CRAMM, IRIS, FRAP
a další. Je proto důležité si vždy uvědomit, jaká rizika chceme analyzovat např. rizika uniku
informací z informačního systému, rizika pracovních úrazů na určitém pracovišti, riziko pádu
kabiny lanovky, a pod., abychom podle potřeby použili odpovídající metodu.
Komplexní analýza rizik zahrnuje v rizikovém inženýrství:
•
•
•
Identifikaci hrozícího nebezpečí
Vyhodnocení rizika
Návrhy opatření ke snížení rizika
Po provedené analýze rizik nesmíme zapomenou v projektu provádět sledování rizika
(též monitorování rizika – Risk Monitoring), kde realizujeme podle potřeby připravená
opatření ke snížení rizika nebo analyzujeme nově se vyskytnuvší nebezpečí. Spojení analýzy
rizika a sledování rizika označujeme v rizikovém inženýrství jako proces řízení rizika (Risk
Managment).
V projektovém řízení se jedná o stanovení rizika, které může negativně ovlivnit
průběh projektu. Často se používá termínu - řízení projektových rizik - Risk Project
Management.
Projekty automatizovaných informačních a řídicích systémů jsou velmi komplexní a
složité záležitosti, takže je s nimi spjato mnoho nebezpečí, která mohou být příčinou
neúspěchu projektu. To platí pro projekty obecně. Proto je potřeba tato nebezpečí
identifikovat a vyhodnotit s ohledem na možnost, jak při jejich poznání můžeme snížit
ohrožení projektu.
Následně jsou stručně popsány dvě metody, vhodné pro aplikaci v projektovém řízení.
Pokud projektový tým nemá dostatek zkušeností s analýzou rizika, je možno doporučit
metodu FRAP, která využívá facilitátora. Ten představuje moderátora, který vede celý proces
analýzy rizika a moderuje rozpravu projektového týmu tak, aby výsledkem byla úspěšně
provedená analýza rizik s využitím znalostí facilitátora a zkušeností členů projektového týmu.
13.2 Metoda RIPRAN
Metoda RIPRAN (RIsk PRoject ANalysis), představuje jednoduchou empirickou
metodu pro analýzu rizika projektů, zvláště pro středně velké firemní projekty.
Vychází důsledně z procesního pojetí analýzy rizika. Chápe analýzu rizika jako proces
(vstupy do procesu-výstupy z procesu-činnosti transformující vstupy na výstup s určitým
cílem).
Metoda akceptuje filosofii jakosti (TQM) a proto obsahuje činnosti, které zajišťují
jakost procesu analýzy rizika, jak to vyžaduje norma ISO 10 006.
Metoda je navržena tak, že respektuje zásady pro Risk Project Management, popsané v
materiálech PMI a IPMA.
Je zaměřena na zpracování analýzy rizika projektu, kterou je nutno provést před
vlastní implementací.
Neznamená to, že bychom neměli s hrozbami pracovat v jiných fázích. Naopak, v
každé fázi životního cyklu projektu musíme provádět činnosti (zejména se to týká
předprojektových fází – Studie příležitosti a Studie proveditelnosti), které jednak shromažďují
podklady pro samostatnou analýzu rizik projektu pro fázi implementace projektu, a které
vyhodnocují případná rizika neúspěchu té fáze, kterou provádíme. Zachycená rizika pak
použijeme pro celkovou analýzu rizik projektu.
Celý proces analýzy rizik se skládá ze následujících činností:
• Příprava analýzy rizika
• Identifikace rizika
• Kvantifikace rizika
• Reakce na riziko
• Celkové zhodnocení rizika
Tyto činnosti jsou koncipovány jako procesy, které na sebe navazují.
13.2.1 Příprava analýzy rizik
Projektový tým
Pracovní materiály
Příprava analýzy
rizika
Podklady
Popis metody RIPRAN
Cíl: Připravit vše k provedení analýzy rizik podle metody RIPRAN
Vstupy:
- Popis metody RIPRAN
- Formuláře metody RIPRAN
- Různé pokyny a informace, vážící se k analýze rizik
Výstupy:
- Časový plán provedení analýzy rizik
- Rozhodnutí o použitých stupnicích, kontrolních seznamech apod.
Činnosti podporující jakost:
- Provedení kontroly připravenosti týmu na provedení analýzy rizik
Vlastní činnosti:
- Sestavení časového plánu postupu
- Sestavení seznamu a zajištění potřebných podkladů
- Dohoda o používaných pomůckách (kontrolní seznamy, tabulky apod.).
13.2.2 Identifikace rizika
Projektový tým
Identifikace
rizika
Popis projektu
Seznam dvojic
Přiřazení hrozba ⇒ scénář
nebo scéná ř⇒ hrozba
Cíl:
Nalezení hrozeb a scénářů
Vstupy:
- Popis projektu
- Historická data o minulých projektech
( Post Implementation Analysis, Trouble List)
- Prognózy možných vnějších vlivů
- Prognózy možných vnitřních vlivů
- Zkušenosti
Výstup: Seznam dvojic
hrozba - scénář
Činnosti podporující jakost:
- Test platnosti a kompletnosti vstupních podkladů
- Test kompletnosti a kompetentnosti týmu
- Test aktuálnosti prognostických podkladů
- Test úplnosti výstupního seznamu dvojic
Vlastní činnosti:
Nejprve je potřeba zkontrolovat, zda předaný popis projektu je platný a kompletní.
Podobný test je potřeba provést pro další dodané vstupní podklady.
Tým by měl prověřit, zda na pracovní poradě jsou všichni, kteří byli vybráni pro
úspěšné provedení identifikace rizika projektu. Všichni přítomní by měli projít školením o
projektovém riziku, aby byli platnými účastníky porady a stali se kompetentními pro
identifikaci rizika.
Poté tým může zahájit vlastní sestavování výstupního seznamu, který je nejlépe
prezentovat jako tabulku, kterou např. vypisujeme v počítači programem MS WORD, kde
přidáváme postupně další řádky:
Pořadové číslo dvojice
Hrozba
Scénář
Řádky do tabulky navrhují jednotliví členové a po diskusi se schválený text hrozby a
scénáře vepíše do tabulky.
Kompletní text řádku můžeme získat buď tak, že hledáme odpověď na otázku:
Co se může přihodit v projektu nepříznivého, když ...?.
Tedy postup, kdy k hrozbě hledáme možné následky:
HROZBA ⇒ SCÉNÁŘ.
Můžeme však také postupovat opačně a získat kompletní text řádku odpovědí na
otázku:
Co může být příčinou, že to a to nepříznivého v projektu nastane?
Tedy postup, kdy ke scénáři hledáme jeho příčinu:
SCÉNÁŘ ⇒ HROZBA
Nesmíme zapomenout prověřit, zda jsme k určité hrozbě přiřadili všechny významné
scénáře. Jako pomůcky můžeme použít stromy rizik (Risk Trees). Např.
S11
S1
S12
H1
S21
S2
S22
Podobně musíme prověřit, zda jsme přiřadili všechny možné hrozby určitému scénáři
(například příčinou požáru může být blesk, samovznícení, žhářství, závada v elektroinstalaci).
Pokud se domníváme, že je seznam hotov, provedeme jeho ověření na úplnost.
Často se ověření seznamu předá jiné, testovací skupině.
Prověřený seznam potvrdíme a fixujeme jako platný dokument identifikace rizika
13.2.3 Kvantifikace rizika
Projektový tým
Seznam dvojic
Kvantifikace
rizika
Doplněný seznam
Stanovení pravděpodobnosti
a ztráty
Cíl: Ohodnotit pravděpodobnost scénářů, velikost škod a vyhodnotit míru rizika
Vstupy:
- Seznam dvojic hrozba-scénář
- Statistická data z minulých projektů a další různé statistické údaje
- Zkušenosti
Výstupy:
- Úplné n-tice (hrozba,scénář,pravděpodobnost,škoda) - mezivýsledek
- Seznam I. pro doplnění návrhu projektu
- Seznam II. pro informaci k možným operativním zásahům
- Seznam III. pro následující proces Snižování rizika
- Předběžná úroveň souhrnného rizika projektu
Činnosti podporující jakost:
- Test kompletnosti a platnosti vstupního seznamu
- Test kompetentnosti a kompletnosti týmu
- Test aktuálnosti statistických dat
- Test kompletnosti výstupního seznamu dvojic
Vlastní činnosti:
Nejprve prověříme, zda náš tým je kompetentní a kompletní k provedení kvantifikace
rizika. Členové týmu by měli mít absolvován potřebný kurz a mít zkušenosti s kvantifikací
rizik.
Dále ne nutno si zajistit aktuální údaje, které můžeme pro kvantifikaci rizika použít.
Tým se dohodne, zda bude moci stanovit přesně hodnoty pravděpodobnosti a ztrát
nebo zda použije nějakých klasifikačních stupnic. Pokud se rozhodne pro stupnice, musí se
dohodnout na jejich podobě.
Pak se doplňují jednotlivé dvojice o hodnotu pravděpodobnosti a velikosti ztráty,
případně i hodnotu rizika. Nejlépe v tabulce s pomocí programu MS WORD, kterou postupně
rozšiřujeme o další řádky, přičemž pořadová čísla necháváme pro kontrolu shodná s minulou
tabulkou.:
Pořadové
číslo
Hrozba
Scénář
Pravděpodobnost
Dopad na
projekt
Hodnota
rizika
Hodnoty pravděpodobnosti a výšku ztráty navrhují jednotliví členové týmu a do
tabulky se zapíší hodnoty, na kterých se všichni členové shodnou.
Před uzavřením výstupního seznamu
zkontrolujeme, zda jsme nezapomněli
kvantifikovat některou dvojici.
Vypracovaný seznam ověříme, nejlépe kontrolou prostřednictvím testovací skupiny.
Prověřený seznam potvrdíme a fixujeme jako pracovní mezivýsledek kvantifikace
rizika.
Takto získaný seznam podrobíme následující analýze, abychom z něho vytvořili tři
dokumenty:
I. Seznam těch případů, kdy vysoká pravděpodobnost scénáře a významná ztráta nás nutí
doplnit tyto případy přímo do plánu projektu, protože je nemůžeme ponechat náhodě,
ale musíme je učinit součástí projektu
II. Seznam těch případů, které pro svoji nízkou pravděpodobnost a zanedbatelnou ztrátu je
možno přenechat na operativní zásahy.
III. Zbývající část, která zůstala pro následné vypracování návrhů na snížení rizika
.
V seznamech ponecháváme pořadová čísla původního úplného seznamu.
Všechny seznamy podrobíme kontrole.
Po kontrole seznamy fixujeme a zařadíme je jako platné doklady o naší práci.
13.2.4 Reakce na rizika
Projektový tým
Seznam III.
Snižování rizika
Návrhy
na snížení
rizika
Typové návrhy
na snížení rizika
+ hodnota akceptovatelného rizika
Cíl:
Na základě informovanosti o nebezpečí připravit opatření, snižující vliv rizik .
Vstup:
Seznam n-tic (hrozba, scénář, pravděpodobnost, škoda), které
je potřeba vzít v úvahu (seznam III.)
Výstup:
- Návrhy na snížení rizika
- Plán opatření na snížení rizika
Činnosti podporující jakost:
- Test platnosti a kompletnosti vstupního seznamu
- Test kompetentnosti a kompletnosti týmu
- Prověření návrhů ke snížení rizika projektu
Vlastní postup:
Zkontrolujeme úplnost a platnost vstupního seznamu.
Prověříme složení týmu a kompetenci týmu s ohledem na snižování rizika.
Pro každou položku seznamu se snažíme v týmu nalézt opatření, které by mohlo snížit
riziko na úroveň akceptovatelného rizika pro jednotlivé případy. Vycházíme z následujících
typových opatření, které jsou metodicky zpracovány tak, že sledují jednotlivé položky, které
jsou tabulce od levé strany ( H-S-P-D). Návrhy zapisujeme do tabulky:
Pořadové číslo
Návrh na opatření
Nová hodnota
sníženého rizika
Po vyčerpání všech položek seznamu III. provedeme kontrolu, zda některý řádek nebyl
vynechán. Po této kontrole prověříme návrhy na opatření z hlediska:
- realizovatelnosti
- potřebných nákladů na realizaci
- potřebných organizačních opatření, které návrh vyžaduje
- účinnosti.
Po prověření fixujeme seznam jako výsledek snižování rizika.
Následující seznam popisuje typová opatření ke snížení rizika.
Alternativní řešení
Likvidace zdroje hrozby
Ochrana před hrozbou
Modifikace scénáře
Snížení pravděpodobnosti výskytu scénáře
Snížení velikosti škody
Mobilizace rezerv
Přenesení rizika
Rozdělení rizika
Na základě typových opatření se tým snaží zformulovat konkrétní opatření ke snížení
rizika pro navrhovaný projekt.
13.2.5 Celkové zhodnocení rizika
Projektový tým
Zhodnocení rizika
Seznam III.
po úpravách
Požadovaná úroveň
akceptovaného rizika
+ kritéria hodnocení celkové úrovně rizika
Celkové
zhodnocení
rizika
Cíl:
Celkově vyhodnotit analyzovaná rizika projektu
Vstup:
Seznam s návrhy na opatření s novými hodnotami rizik
Požadavky na celkovou úroveň rizika
Výstupy:
Celkové zhodnocení úrovně rizika projektu
Závěrečná zpráva o průběhu analýzy.
Činnosti podporující jakost:
-Test platnosti tabulky s kritérii pro hodnocení celkové úrovně rizika
-Test kompetentnosti a kompletnosti týmu
-Test kompletnosti výsledné zprávy a kompletnosti výstupních podkladů analýzy
rizika
Vlastní postup:
Zkontrolujeme, zda jsou všechna dílčí jednotlivá rizika ve stanovené úrovni
akceptovatelného rizika.
Následně vyhodnotíme:
• Počet dílčích rizik
• Celkový součet hodnot rizik
• Časové rozložení hodnot rizik v průběhu trvání projektu
Pak posoudíme, jak se jeví předběžná souhrnná úroveň rizika celého projektu
s ohledem na celkovou plánovanou hodnotu projektu. Tým uvede, zda se mu celková úroveň
rizika jeví jako podle stanovených kritérií:
nízká - nominální - vysoká - katastrofická
V případě, že stále zůstává katastrofická úroveň souhrnného rizika i přes navržená
opatření, je potřeba zvážit návrh na zastavení projektu.
Je potřeba projednat případy střední a vysoké úrovně rizika projektu s grantem
projektu.
13.2.6 Poznámky k metodě RIPRAN
Poznámka 1. Jiná forma výstupu:
Kromě tabulkové formy je možno použít pro menší počet položek následující formu pro
každý případ:
Pořadové číslo:
Hrozba:
Scénář:
Pravděpodobnost:
Dopad:
Návrhy na opatření:
Výsledná snížená hodnota rizika:
Poznámka 2. Verbální hodnocení rizika
Kromě číselného hodnocení např. p = 0.3 a d=340 000 Kč můžeme pro případ, že nejsme
schopni stanovit tyto hodnoty použít verbálního hodnocení s využitím přiložených tabulek:
Matice pro přiřazení třídy hodnoty rizika:
Vysoká
pravděpodob
nost
Střední
pravděpodobnost
Nízká
pravděpodobnost
Velký nepříznivý
dopad na projekt
Vysoká hodnota
rizika VHR
Střední nepříznivý
dopad na projekt
Vysoká hodnota
rizika VHR
Vysoká hodnota
rizika
VHR
Střední hodnota rizika
SHR
Střední hodnota rizika Nízká hodnota rizika
SHR
NHR
Nízká hodnota rizika
NHR
Malý nepříznivý
dopad na projekt
Střední hodnota rizika
SHR
Nízká hodnota rizika
NHR
Třídy pravděpodobnosti:
Nad 66%
Vysoká pravděpodobnost VP
Střední pravděpodobnost
SP
Nízká pravděpodobnost
NP
33 – 66 %
Pod 33 %
Třídy dopadu na projekt:
Velký nepříznivý dopad na projekt
VD
Střední nepříznivý dopad na projekt
SD
Malý nepříznivý dopad na projekt
Ohrožení cíle projektu
Nebo
Ohrožení koncového termínu projektu
Nebo
Možnost překročení celkového rozpočtu
projektu
Nebo škoda přes 20% z hodnoty projektu
Škoda od 0,51 do 19,5% z hodnoty projektu
Nebo
Ohrožení termínu, nákladů resp. zdrojů
některé dílčí činnosti což bude vyžadovat
mimořádné akční zásahy do plánu projektu
Škody do 0,5% z celkové hodnoty projektu
Nebo
Dopady vyžadující určité zásahy do plánu
projektu
MD
Třídy hodnoty rizika:
Vysoká hodnota rizika - VHR
Střední hodnota rizika - SHR
Nízká hodnota rizika - NHR
Třídy úrovně celkového rizika
Celkový součet hodnot rizik
Pod 2% PHP
Nízká úroveň
Od 2 do 5% PHP
nad 5 do 10% PHP
Přesahuje 10 % PHP
Nominální úroveň
Vysoká úroveň
Katastrofická úroveň
Upozornění!
Hodnoty uváděné v tabulkách jsou orientační a je potřeba vždy provést jejich přizpůsobení
pro firemní projekty podle potřeby.
Poznámka 3 Rizikové faktory
Někdy nejsme schopni přesně určit samostatně hrozbu a scénář. V takovém případě se
můžeme pokusit určit rizikový faktor – např. množství nových modulů v programovém
produktu, použití nového programovacího jazyka pro realizaci programového produktu, počet
začínajících programátorů v realizačním týmu, apod. K rizikovým faktorům přiřazujeme jen
třídu hodnoty rizika. V takovém případě vyplňujeme při identifikaci rizika jen sloupec
HROZBA vypsáním rizikového faktoru a při kvantifikaci rizika jen sloupec HODNOTA
RIZIKA uvedením označení příslušné třídy. Níže jsou označeny vyplňované sloupce:
Pořadové
číslo
X
Hrozba
Scénář
X
-
Pravděpodobnost
-
Dopad na
projekt
-
Hodnota
rizika
X
Proškrtnutím se označí, že se jedná o rizikový faktor ne o případ opomenutí uvést scénář,
pravděpodobnost a dopad na projekt.
13.3 Bodovací metoda analýzy rizik
Východiskem při této metodě je seznam různých nebezpečí (technických, finančních,
personálních a obchodních). Pro každé nebezpečí se v bodovací metodě ohodnotí jak
pravděpodobnost nebezpečné události, tak její dopad prostřednictvím desetibodové stupnice.
Doporučuje se, aby každý člen projektového týmu stanovil svůj odhad hodnoty. Výsledné
skóre se vypočte jako aritmetický průměr odhadů jednotlivých členů. Ocenění rizika se
vypočte jako součin skóre pravděpodobnosti a skóre dopadu. Výše ohodnocení je tedy
v rozmezí 1 až 100.
Na závěr se pak sestaví mapa rizik jako dvojrozměrná matice.
Podle potřeby se zpracují návrhy na snížení rizika (např. pro hodnoty kritických rizik)
Níže je uveden příklad tabulky pro případ osmi členů projektového týmu a možná
tabulka pro návrh opatření ke snížení rizika. Dále je prezentován záznam výsledného ocenění
v mapě rizik a je vykreslen příklad mapy rizik pro větší počet ( celkem 10) identifikovaných
nebezpečí.
Tabulka pro bodové ocenění rizika
Poř. číslo a rizikový faktor: Nejasné zadání s chybami od zákazníka
Kvantifikace
rizik 1.
2.
3.
4.
5.
6.
7.
8.
členy
analytického
týmu
Pravděpodobnost
4
4
5
3
4
4
6
(1-min. až 10-max.)
Dopad
7
5
5
7
6
8
4
(1-min. až 10-max.)
Ocenění rizika = Skóre pravděpodobnosti x Skóre dopadu
Tabulka návrhů na opatření ke snížení rizika
Poř. číslo - Rizikový faktor Návrh opatření
2
Skóre
(průměr
né
hodnoty)
4
X
6
6
X
24
Zodpovědnost a termíny
zajištění
Mapa rizik
Dopad
10
Kvadrant
významných
Hodnot rizik
Kvadrant kritických
hodnot rizik
5
Kvadrant
bezvýznamných
hodnot rizik
Kvadrant běžných
hodnot rizik
0
0
5
10
Pravděpodobnost
Dopad
Mapa rizik
10
9
8
7
6
5
4
3
2
1
0
0
1
2
3
4
5
6
7
Pravděpodobnost
8
9
10
Seznam literatury:
1 Arlow,J.-Neustad,I.: UML and Unified Process Practical Object Oriented Analysing and
Design. Pearson Education Ltd, 2002, 387 s.
2 Rosenau,D.: Successful Project Managment. John Wiley and Sons Inc., 1999, 344
3 Král,J.- Demner,J.: Softwarové inženýrství, Academia Praha 1991, 324 s.
4 Voříšek,J.-Strategické řízení informačního systému a systémová informace. Management
Press 1997 Praha, 323 s.
5. Plák, J.-Merunka,V.-Carda,A.: Umění systémového návrhu (metoda BORM). Grada
Publishing 2003 Praha, 196 s.
6 Molnár,Z.: Moderní přístupy řízení informačních systémů. Garada Publishing 2003 Praha
7 Vaníček, J.: Měření a hodnocení jakosti informačních systémů. ČZU v Praze 2000 Praha
8 Patron, R.: Testování softwaru. Computer Press 2002 Praha
9 Tichý, M.: Ovládání rizika – analýza a management.Beckova edice ekonomie 2006 Praha
10 Dostál,P.- Rais,K.-Sojka,Z.: Pokročilé metody manažerského rozhodování. Grada
Publishing 2005 Praha
11 Kališ,J.-Hyndrák,K.-Tesař,V.: Microsoft Project – kompletní průvodce. Computer Press
2003 Brno