Navrhování systémů řízení

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ávrhy. 5 Funkce a náplň produktů pro počítačovou podporu softwarového inženýrství 6 Jakost software a testování programů. 7 Modely jakosti procesů tvorby software 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 Z uvedených množin komponent je často podceňována a množina prostředků organizačního zabezpečení.

přehlížena právě třetí

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 izolovaný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, makroinstukce, 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 klient/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č

Ruční vstup dat

Doporučené hodnoty pro ruční řízení 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 v nich často chyběly i funkce strategického řízení zřejmě jako důsledek skutečnosti, že cíle 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í schéma - 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 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 dodávky 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

D1 D2 D3 D4 D5

Systémový Zákazník integrátor

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 .. Vlastní přizpůsobení

N

Hotový produkt a Hotový produkt

Prototyp

b

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.

..

Uživatel se musí umět orientovat v nabídce současného hardware a software, zhodnotit jednotlivé produkty a vybrat takové, které optimálně vyhovují jeho potřebám. Mnoho uživatelů na takovou situaci není připraveno,nezná vhodné metody výběru software a postupuje nesystematicky. Není divu, že v řadě případů pak je vybráno programové vybavení, které uživateli nevyhovuje. Jedním ze základních předpokladů úspěšného rozhodovacího procesu v takovém případě je stanovit reprezentativní množinu variant, ze které má být vybráno optimální řešení. Právě zde řada uživatelů dělá hned na počátku chybu, když zvažuje jen omezený počet variant, často dokonce jen jednu krajní variantu. Např. dříve to bylo jen řešení vlastního vývoje software, dnes naopak jen koupě hotového produktu. Následující příspěvek chce pomoci těm uživatelům, kteří stojí před problémem získat programový produkt pro svou aplikaci počítače a chtějí to udělat kvalifikovaným, systematickým postupem, aby dosáhli optimálního výsledku své volby. Z různých metod rozhodovací analýzy lze pro stanovení množiny vhodných variant aplikovat metodu rozhodovacích stromů. Rozhodovací strom se skládá z rozhodovacích uzlů, ze kterých vycházejí hrany, označující jednotlivá možná řešení příslušného problému. Po několika úrovních se dostaneme vždy až ke konkrétním cílovým variantám. Rozhodovací stromy (Decision Trees) popisují názorně dynamiku rozhodovacího procesu. Navíc umožňují ohodnotit jednotlivé hrany z hlediska např. nákladů, času atd. Výše uvedené schéma ukazuje vzorový rozhodovací strom pro výběr software. Vzorový proto, že v konkrétním případě by bylo nutno v rozhodovacích uzlech 1.1.1., 1.1.2 a 1.2.1 doplnit příslušné počty konkrétních variant - konkrétní počet uvažovaných prototypů z aktuální nabídky na trhu, konkrétní počet uvažovaných produktů z aktuální nabídky trhu a počet dostupných softwarových firem, které nabídly své kapacity pro vývoj software na zakázku. Také otázka přizpůsobení prototypu na zakázku je řešena jen vzorově, jak bude uvedeno v diskusi u rozhodovacího bodu 1.1.1.1. Konkrétní rozhodovací strom si pak sestaví uživatel podle uvedeného vzoru sám. Uveďme komentáře k jednotlivým uzlům rozhodovacího stromu, aby byl lépe pochopen celý rozhodovací proces. Uzel 1. obsahuje základní varianty rozhodnutí: KOUPIT software nebo VYVINOUT software. Je potřeba si uvědomit, že vývoj software je vždy nákladný a trvá dlouhou dobu. Je obtížné odhadnout očekávané náklady na tento vývoj a dobu vývoje předem. Koupě je realizována rychleji, vychází se ze stanovené ceny. Problém aplikace koupeného software spočívá v tom, zda nabízený software splňuje požadavky, které uživatel na něj klade. Obecně lze doporučit, že pro vývoj software by se měl uživatel rozhodnout tehdy, když je přesvědčen, že neexistuje software na trhu, který by mu vyhověl. Koupě software představuje dvě možné zásadní realizace takového rozhodnutí, jak ukazuje uzel 1.1.: jednak je lze koupit HOTOVÝ PRODUKT nebo PROTOTYP, kdy koupíme jen podstatnou část programového produktu a dodatečně ji přizpůsobíme konkrétním požadavkům. V obou případech musí následovat kompletace možných hotových produktů (viz uzel 1.1.2.) a kompletace možných prototypů, které jsou na trhu a spadají v úvahu pro aplikaci (viz uzel 1.1.1.). S koupí prototypu je spojena potřeba jeho přizpůsobení (viz uzel 1.1.1.1.). To je možno provést buď ÚPRAVOU PROTOTYPU VLASTNÍMI SILAMI, pokud má firma vlastní specialisty, nebo lze UPRAVIT PROTOTYP DODAVATELEM. Zde jsou vzorově zvažovány tyto dvě varianty, které představují nejčastěji používaná řešení. Někdy je možno úpravu nechat provést různým firmám, v takovém případě by bylo nutno doplnit další rozhodovací uzel a varianty, podle počtu softwarových firem.

Vraťme se do uzlu 1.2. Poté, co jsme se rozhodli získat potřebný software vývojem, se v něm musíme rozhodnout, zda budeme vyvíjet uvnitř firmy vlastními odborníky nebo zda svěříme vývoj specializované softwarové firmě. Pokud chceme svěřit vývoj některé SW firmě, budeme muset v uzlu 1.2.1. vybrat mezi těmi, které nám na bídnou své služby. Při interním vývoji se musíme rozhodnout, zda budeme celý vývoj centrálně zajišťovat nebo ho svěříme jednotlivým decentralizovaným útvarům při celkové firemní koordinaci (viz uzel 1.2.2.). Rozhodovací strom je vzorový i z toho důvodu, že nepředpokládá různé kombinace řešení např. při realizaci informačního systému velké firmy se určité subsystémy koupí a jiné vyvinou apod. Při řešení konkrétního problému takové kombinované situace často nastávají. Vytvořením cílových variant nekončí možnosti využití metody rozhodovacích stromů. Jestliže se rozhodneme koupit software znamená to, že bude potřeba provést průzkum nabídky na trhu. Bude nutno zajistit katalogy nabízeného software, adresy dodávajících firem, prospekty jednotlivých produktů atd. To si vyžádá jednak ČAS a jednak určité NÁKLADY. Podobná situace nastane budeme-li chtít vyhodnotit určitý počet nabízených prototypů atd. Tyto hodnoty si můžeme připsat k jednotlivým uzlům. Nezapomeňme hned na první uzel! Zde je nutno počítat s časem, který nám zabere sestavení požadavků na software, což bude dokument, který budeme potřebovat v průběhu celého rozhodovacího procesu. Samozřejmě nás to bude stát i určité peníze. Můžeme však od určitého údaje i upustit. Např. při hodnocení cílových variant, kdy můžeme mít hotový produkt hned, lze zvažovat jen cenu produktu jako náklady určité varianty a neuvažovat časové hodnocení. Naopak např. u cílových variant se můžeme pokusit ohodnotit jejich očekávaný přínos pro firmu, což je hodnocení, které nebylo nutné uvažovat v předchozích rozhodovacích uzlech. Na konci (v cílových variantách) můžeme sečíst vždy stejné hodnoty (čas, náklady) z předchozích uzlů na příslušné cestě od kořene ke konci, abychom dostali celkové náklady pro dosažení určité cílové varianty a celkový čas určité konkrétní varianty. Tyto součty pak použijeme pro celkové vyhodnocení a výběr optimální varianty, když uvážíme ještě předpokládané přínosy jednotlivých cílových variant. Metoda rozhodovacích stromů předpokládá, že vytvoříme úplný rozhodovací strom a provedeme jeho ohodnocení, abychom tak získali podklady pro výběr optimální varianty. Můžeme však postupovat i jinak. V uzlu 1. se rozhodneme pro koupi a vývoj software nebudeme dále analyzovat. V uzlu 1.1. se rozhodneme pro koupi hotového produktu a nebudeme analyzovat dále možnosti různých prototypů. Provedeme jen hodnocení a výběr z určitého počtu nabídnutých produktů. Vytvoříme tak neúplný (též degenerovaný) rozhodovací strom. Takový postup je výhodný v tom případě, když zamítnuté varianty jsou jasně horší než vybraná varianta, a bylo by zbytečným zdržováním a utrácením finančních prostředků, kdybychom důsledně analyzovali i zamítnuté varianty. V uzlech jakými jsou 1.1.1., 1.1.2. nebo 1.2.1. je nutno věnovat jednak pozornost zajištění přiměřeného počtu variant, které stojí za zvážení. Nejedná se o to, aby byly analyzovány všechny možné a dostupné hotové produkty na trhu (např. uzel 1.1.2.), ale takové, které se jeví při předběžném hodnocení jako možná řešení. Jen pro úplnost se i jasně zamítnuté produkty uvedou (např. jen pouhým výčtem), nikoliv zakreslením do stromu, aby bylo dokumentováno, že se o produktu uvažovalo. Prohlédneme-li popsaný rozhodovací strom vidíme, že celý proces není jednoduchý a stojí určité prostředky a čas. Řada uživatelů to podvědomě vycítila i bez zhlédnutí takového stromu. Místo co by si však na základě svého pocitu uvědomila o to větší potřebu dobré metody, která by zajistila optimální výběr, rozhodla se ušetřit čas i náklady tím, že rychle a

bez nějakého složitého uvažování zvolila určité konkrétní řešení, které se až později ukázalo jako nevhodné. Prostředky a čas, vynaložený na dobře provedenou rozhodovací analýzu, se nám několikanásobně vrátí ušetřením zbytečně vynaložených finančních prostředků a času na nevhodná řešení a na jejich nápravu.

2.2 Vicekriteriá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 +Váhy

VARIANTY A B C D

x

y

y

Výsledné hodnocení

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

Výsl. 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á 9 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í faktor přeprav. zavaz. výkon 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

Říkáme, že jsme hodnocení faktorů normalizovali.

0,88 0,74 1

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 velkou 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 pracnost u 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 plá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 možnosti další konzultace k jeho obsahu. Zde často dochází k určitým odlišnostem. Například metody 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, bezrospornost, 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 na základě oboustranné dohody 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. 2.5 Návrh AISŘ Pod pojmem návrh AISŘ se obvykle zahrnuje: • • • • • •

Analýza současného stavu informačních a firemních procesů ve vymezené předmětné oblasti příslušné firmy/instituce Rozbor požadavků uživatele na požadovaný AIŘS Specifikace potřebných technických prostředků Specifikace potřebných programových komponent s návrhem, které je potřeba zakoupit a které je potřeba vyvinout Doporučení příslušných organizačních změn Doporučení pro fázi provozu AIŘS včetně návrhu potřebného organizačního zajištění AIŘS a školení obslužného personálu a školení uživatelů

• • •

Specifikace vyvolaných investic Doporučení pro postup realizace navrhovaného AIŘS Jiné (řešení problematiky záruk, poskytování poradenství, návrh způsobu servisu apod.)

Rozhodně bychom neměli přistupovat k návrhu dříve, než jsme analyzovali stávající stav (Current Status Analysis) a důkladnou analýzu požadavků na požadovaný informační systém. Velmi často se také hovoří o IS ANYLYSIS a MUST ANALYSIS, kdy z porovnaní výsledků závěrů obou analýz vyplyne, co má být vyřešeno a navrženo. Obsah výsledného návrhu bývá často podrobně vymezen v různých státních a mezinárodních doporučovaných standardizovaných metodách. Přesný obsah návrhu musí být rovněž vymezen v předmětu smlouvy na dodávku návrhu AIŘS.

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 Požadavky Funkce (návrh) Systém (návrh)

Plán akceptačních testů

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 kroků 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)

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

Užití Lower CASE technologií k výstavbě aplikace

Iterativní návrh a budování

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 Instalace 2.12. 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 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ě propojené ( 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 schématu 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:

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 proceu (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ů 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 (Smalltalk, 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 Aktivace obchodního případu

Obchodní případ

Požadavek na produkt

Zákazník

Produkt

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 Kmenové informace o zákazníkovi

Diagram sekvence událostí

Založení zákazníka

Rizikovost zákazníka

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í metody RUP je snadné 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. 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ší čá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?, které jsou kladeny v tomto pořadí. 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í, který byl založen na nahodilém, intuitivním postupu, 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é využívání znalostí podpory 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ýze 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 testová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 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 Požadavky Funkce (návrh) Systém (návrh)

Plán akceptačních testů

Plán funkčních testů

Plán integračních testů

Def. programu

Plán testu pro testování programu

Akceptační testy 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. Stanovení priorit důležitosti jednotlivých 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 r e J a ko st

P ra co v n íci

v S o ftw a re E n gin eerin g

S p ecifik a ce

J a k o st

so ftw a re

so ftw a r e

V ý v o jo v é

M eto d y

p ro střed k y

n á v rh u so ftw a re O rg a n iza ce p ro cesu tv o rb y so ftw a r e

Ish ik aw ů v d ia g ra m p ro ja k o st so ftw a re – ro zšířen á v er ze

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 se 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 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 • zvolenou metodu návrhu softwaru • správnou volbu technických prostředků • jednotlivé elementární pracovníky, 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 od 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 2 3 4 5

Committed to Excellence 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. V dalším textu jsou stručně charakterizovány 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ů, adaptibilnost 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

5.úroveň Prevence chyb Řízení změn

Produkty CASE

Business Process Reengineering

Optimalizační metody

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 +

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 ohodnotit 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í firmy 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 o 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í jeho 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 v průběhu 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í

Certifikace

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ží jen 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, magnetické 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 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

čas

Obr.2. Předsunutý rozvoj informačního systému 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

B

čas

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.

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 bylo dosaženo 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é ří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á systémového přístupu k řešení problé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 dohodnutých TERMÍNŮ, NÁKLADŮ a s čerpáním disponibilních ZDROJŮ při 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

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 Information, Documentation, Reporting 22 Project Organisation 23 Teamwork 24 Leadership 25 Communication 26 Conflicts and Crises 27 Procurement, Contracts 28 Project Quality

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 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í cyklus 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á na 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ů 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 se naše firmy 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 na evropském trhu, musí se naučit dobře používat projektové řízení. Řada našich firem už projektové řízení dobře zvládla o čemž svědčí takové úspěšné projekty jako přestavba Kongresového centra v Praze, Hala Sazka Aréna, apod.

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 a přesvědčení vrcholového vedení firmy o účelnosti projektového řízení a odhodlání všech vedoucích pracovníků ú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 Zkrácení termínů firemních akcí Ú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í

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 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 nás ČSN/ISO 10 006 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

Výchozí (současný) stav

PROJEKT

Cílový stav

Č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 dále 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ě, a v neposlední řadě 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í. Nazýváme je „ž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ředprojektový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íl Úč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 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 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ů! 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.“ 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.

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í pozici, 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 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: 25.4.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í realizová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

Objektivně ověřitelné ukazatele

Způsob ověření

Předpoklady a rizika

Cíl/Cíle Účel Konkrétní výstupy projektu Klíčové činnosti Poznamenejme, že v literatuře se můžeme setkat s 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í logiky projektu

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í,

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ě jednotlivých cílů ověřitelných 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) Kde se dají získat Měřitelné indikátory informace o na úrovni výstupů objektivně nezbytné pro ověřitelných zabezpečení účelu ukazatelích (počet, délka, (monitorovací obsah....) zprávy, statistiky Způsoby, kterými obce, vlastní

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)

Předpoklady a rizika na úrovni výstupů podmiňující dosažení účelu (průběh realizace, finanční zdroje, dodavatel)

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. .. 2... 3... 2. 1... 2... 3...

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.

projekt)

Předpoklady a rizika na úrovni vstupů (zajištění fin. zdrojů, Ke každé aktivitě se vybrání kvalitního uvede časový údaj, dodavatele..) kdy daná aktivita bude zrealizována. (10/2003) Časový rámec aktivit

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....)

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).

Činnost

Termín zahájení činnosti

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ů):

40 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

S

52

45

52

ale i případy - FINISH TO FINISH

46

F

F

46

51

51

- START TO START

41

S

S

5O

F

52O

41

50

- START TO FINISH

450

S

450

520 ale i řadu jiných omezení pro průběh činností např. časovými podmínkami ( Činnost musí skončit před 30. říjnem).

Ganttův diagram v MS Projectu

Síťový graf v MS Project

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 činností (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í

Struktura členění prací uspořádaná dle výstupů projektu (OBS – Object Breakdown Structure)

Seriózní ohodnocení činností

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 case zařadíte do kategorie složitosti (jednoduchý, střední, složitý) podle počtu transakcí (počet 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 osob (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 Osoba 2 Osoba 3 Osoba 4 Ú S M Ú Z Ú Z Ú Z Ú

Fáze, činnost Osoba 1 … Stanovení požadavků Z Věcný návrh Z Dokumentace S Vývoj P Testy … 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ýbě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, RequisitePro, 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 také 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 by 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

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 ETC

BAC BCWS BCWP ACWP

odhad nákladů při dokončení

Estimate to Completion

Budget at Completion Budgeted Cost for Work Scheduled Budgeted Cost for Work Performed Actual Cost for Work Performed

odhad nákladů pro dokončení

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í

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

Náklady jsou překračovány Projekt se zpožďuje

1

0.5

1.5

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á ve 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í porady. 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 videkonference, 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 na 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é). 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.). 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). 11.9 Poprojektové fáze Po ukončení projektu se provádějí poprojektové fáze: • Analýza ukončeného projektu. Snažíme se analyzovat dobré i špatné situace, které v průběhu projektu nastaly a zjistit jejich příčiny. • Návrhy na zlepšení pro další projekty, aby se zlepšilo řízení dalších projektů. • Monitorování výsledků projektu a zajišťování zhodnocení jeho výsledků, které je potřeba zajistit v těch případech, kdy to charakter projektu vyžaduje. 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. Poprojektové fáze umožňují postupně zvyšovat kvalitu projektů ve firmě nebo jiné instituci. Zajišťování kvality projektů blíže popisuje norma ČSN/ISO 10 006 – Směrnice managementu jakosti projektu, která navazuje na soustavu norem ISO 9000:2000. Kvalitou projektu rozumíme skutečnost, jak projekt uspokojuje požadavky „zákazníka projektu“( zainteresované strany ) , kterému je projekt určen. Norma ISO 10006 vyjmenovává následující skupiny procesů managementu projektu, které jsou rozhodující pro zajištění jeho kvality: ƒ

Strategický proces

ƒ

Procesy vztahující se ke zdrojům

ƒ

Procesy vztahující se k zaměstnancům

ƒ

Procesy vztahující se k vzájemné závislosti

ƒ

Procesy vztahující se k předmětu projektu

ƒ

Procesy vztahující se k nákladům

ƒ

Procesy vztahující se k komunikaci

ƒ

Procesy vztahující se k riziku

ƒ

Procesy vztahující se nakupování

ƒ

Procesy vztahující se ke zlepšování projektu

Firma, která se snaží zajistit kvalitní provádění svých projektů by měla mít zpracovanou firemní směrnici, která by popisovala a definoval průběh těchto procesů.

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ědní 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 sledované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 charakteristiky osobnostní a temperamentu, 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 Schopnost spojit individuální schopnosti, dovednosti a nabyté zkušenosti a spolupracovat tak s ostatními.

Charakteristiky, kterých si všímáme Emocionalita a obvyklé zvládání emocí a citů, umístění na škále introverze – 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í, které se liší od Tendence riskovat či být konzervativní, vlastního návrhu. 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é programové 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).

GROUPWARE– 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í workflow technologie:

WORKFLOW – řízení pracovního oběhu dokumentů Uživatel 1

Uživatel 4

Uživatel 2

Uživatel 3

Centrální DB dokumentů

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í struktury a je potřeba vždy podle situace vybrat nejvhodnější variantu

Mimo organizační strukturu

Projektový tým 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

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

Celkové zhodnocení rizika

Požadovaná úroveň akceptovaného rizika + kritéria hodnocení celkové úrovně 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: Vysoká pravděpodobnost VP Střední pravděpodobnost Nízká pravděpodobnost

Nad 66%

SP NP

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 MD

33 – 66 % Pod 33 %

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

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

Nízká úroveň

Pod 2% PHP

Nominální úroveň Vysoká úroveň Katastrofická úroveň

Od 2 do 5% PHP nad 5 do 10% PHP Přesahuje 10 % PHP

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

2

Skóre (průměr né hodnoty) 4

X

6

6

X 24

Poř. číslo - Rizikový faktor

Návrh opatření

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 0 0

Pravděpodobnost

Kvadrant běžných hodnot rizik

5

10

Dopad

Mapa rizik 10 9 8 7 6 5 4 3 2 1 0 0

1

2

3

4

5

6

7

8

9

10

Pravděpodobnost

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

Zadání seminární práce z předmětu „Navrhování systémů řízení“ Zpracujte v určeném týmu studii návrhu informačního systému (Feasibility Study) pro reálnou nebo fiktivní firmu. Doporučený obsah seminární práce: 1. Popis reálné/fiktivní firmy s uvedením relevantních údajů pro návrh systému (Velikost firmy, předmět a rozsah činnosti, organizační struktura, současný stav využívání výpočetní technik, kritické zhodnocení současného IS, podmínky dodávky a jiná omezení pro stávající záměr, apod.) 2. Stručná charakteristika navrženého systému ( Cíle a základní funkce požadované zákazníkem, koncepce řešení, základní požadované provozní charakteristiky, kontextový diagram, architektura programového vybavení) 3. Návrh technických prostředků (Specifikace jednotlivých prostředků, možné varianty řešené, výběr z variant, počty technických prostředků a zdůvodnění jejich potřeby, jiné důležité údaje - např. kapacity pamětí, apod. ) 4. Návrh programových prostředků (Nakupovaný základní software a jeho specifikace, variantní řešení a výběr variant případná specifikace vyvíjeného SW, rozpracované UML diagramy pro vybrané části AIŘS) 5. Ekonomická analýza (Rekapitulace nákladů, rozbor předpokládaných přínosů, srovnání s očekávanými náklady, výpočet doby návratnosti investovaných prostředků, výpočet očekávaného zisku z hlediska zákazníka, apod.) 6.. Návrh projektu realizace (Základní listina projektu, logický rámec, WBS 1.a 2. úrovně, síťový diagram základních činností, odhad nákladů na činnosti v síťovém diagramu, rozbor zdrojů, analýza rizik, kritické faktory úspěchu projektu) 7 Stručná zpráva týmu o realizaci seminární práce (Jak bylo postupováno, jaká byla dělba práce, kdo co zpracoval – doložit maticí zodpovědnosti, jak probíhaly porady, jaké se

vyskytly problémy nebo konflikty a jak byly řešeny, hodnocení efektivity práce týmu, plnění úkolů jednotlivými členy apod.) Přílohy -pokud nejsou v textu – např.: Diagramy UML podle dohody s učitelem Logický rámec Základní listina projektu Uzlově orientovaný síťový graf pro 2. Úroveň WBS (např. v MS Project) s provedením časové, nákladové a zdrojové analýzy. Ostatní přílohy – např. prospekty Celý dokument semestrální práce 1x vytištěný, svázaný např. v rychlovazači, a na CD-ROM Pro analýzu rizik použijte následující kvalitativní hodnocení: Matice pro přiřazení třídy hodnoty rizika:

Vysoká pravděpodobn ost Střední pravděpodobnost Malá pravděpodobnost

Velký nepříznivý dopad na projekt Vysoká hodnota rizika VHR

Střední nepříznivý dopad na projekt Vysoká hodnota rizika VHR

Malý nepříznivý dopad na projekt Střední hodnota rizika SHR

Vysoká hodnota rizika Střední hodnota rizika SHR

Střední hodnota rizika SHR Nízká hodnota rizika NHR

Nízká hodnota rizika NHR Nízká hodnota rizika NHR

Akceptujeme jen nízké hodnoty rizika!

Třídy pravděpodobnosti:

Vysoká pravděpodobnost Střední pravděpodobnost Malá pravděpodobnost

VP SP MP

Třídy dopadu na projekt: Velký nepříznivý dopad projektu

VD

Střední nepříznivý dopad na projekt

Nad 66% 33 – 66 % Pod 33 %

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% hodnoty projektu

SD Malý nepříznivý dopad na projekt MD

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% celkové hodnoty projektu Nebo Dopady vyžadující určité zásahy do plánu projektu

Třídy hodnoty rizika:

Vysoká hodnota rizika - VHR Střední hodnota rizika - SHR Nízká hodnota rizika - NHR

Výsledky analýzu rizik formulujte např. takto: Poř. číslo: Hrozba: Scénář: Pravděpodobnost: Dopad na projekt: Hodnota rizika: Návrh na opatření: Poznámka: Hodnotu pravděpodobnosti a dopadu stručně zdůvodněte. Na závěr uveďte celkové zhodnocení projektu z hlediska analýzy rizik.

Výsledky analýzy kritických faktorů úspěch formulujte např. takto: Poř.číslo faktoru: Formulace kritického faktoru úspěchu: Opatření vedoucí k zajištění tohoto faktoru: