Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod
Řízení kvality softwaru Diplomová práce
Autor:
Bc. Karel Volena Informační technologie a management
Vedoucí práce:
Praha
doc. Ing. Alena Buchalcevová, PhD.
Duben 2015
Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.
V Chebu, dne 20. 4. 2015
Karel Volena
Poděkování Děkuji paní doc. Ing. Aleně Buchalcevové, Ph.D za její cenné rady, trpělivost, pomoc a konzultace během psaní mé diplomové práce. Dále bych chtěl poděkovat generálnímu řediteli firmy Lázně Františkovy Lázně a.s., panu Ing. Josefu Ciglanskému, za jeho důvěru a podporu během celého mého studia.
Anotace Tato diplomová práce se zaměřuje na řízení kvality softwaru, zejména při implementaci informačních systémů budovaných pomocí typového aplikačního softwaru (TASW). Zdůrazňuje důležitost projektového řízení při implementaci a seznamuje čtenáře s nástroji pro řízení kvality softwaru. Výstupem této práce je návrh metodiky pro implementaci typového aplikačního softwaru v podnikovém prostředí z pohledu zákazníka. Klíčová slova: Řízení kvality softwaru, kvalita, software, TASW, typový aplikační software, IS, informační systém, metodika, řízení projektu, implementace, MMDIS
Annotation This thesis focuses on software quality management, especially in the implementation of information systems built using the type application software (TASW). Emphasising the importance of project management in the implementation and acquaints readers with tools for software quality management. The output of this work is a methodology for implement a type application software in an enterprise environment from a customer perspective. Key words: Software quality management, quality, software, TASW, type application software, IS, Information system, methods, project management, implementation, MMDIS
Obsah 1 Úvod ....................................................................................................................... 8 1.1 Cíle diplomové práce........................................................................................ 8 1.2 Východiska pro zpracování diplomové práce .................................................... 9 1.3 Metodika zpracování diplomové práce ........................................................... 10 1.4 Výstupy a přínosy diplomové práce ................................................................ 10 2 Vymezení pojmů v předmětné oblasti .................................................................... 11 3 Problémy IT projektů ............................................................................................. 14 3.1 Studie Chaos Manifesto 2013 ......................................................................... 14 3.2 Důvody neúspěchu při implementaci TASW .................................................. 16 4 Kvalita softwaru .................................................................................................... 19 4.1 Řízení kvality softwaru................................................................................... 19 4.2 Zajištění kvality IS ......................................................................................... 19 4.3 Mezinárodní normy v oblasti řízení kvality softwaru ...................................... 21 4.4 Metodické přístupy k tvorbě IS/ICT ............................................................... 26 4.4.1 Tradiční metodické přístupy ..................................................................... 26 4.4.2 Agilní přístupy k vývoji softwaru ............................................................. 28 4.5 Testování softwaru ......................................................................................... 30 4.5.1 Co je to testování softwaru ....................................................................... 30 4.5.2 Pojmy z oblasti testování softwaru ........................................................... 31 4.5.3 Role při testování softwaru ....................................................................... 33 4.5.4 Typy testů ................................................................................................ 34 4.6 Audit IS ......................................................................................................... 36 5 Podnikový informační systém ................................................................................ 40 5.1.1 Podnikové informační systémy z pohledu funkcí ...................................... 40
5.1.2 Informační systémy z pohledu úrovně řízení organizace ........................... 42 5.1.3 Požadavky na informační systém .............................................................. 43 5.2 Možnosti pořízení a implementace softwaru (IS) v podnikovém prostředí ...... 45 5.2.1 IASW - individuální aplikační software .................................................... 46 5.2.2 TASW typový aplikační software ............................................................. 47 6 Řízení projektu IS/ICT........................................................................................... 50 6.1 Projekt............................................................................................................ 50 6.1.1 Definice projektu...................................................................................... 50 6.1.2 Trojimperativ projektu ............................................................................. 51 6.1.3 Životní cyklus projektu ............................................................................ 52 6.1.4 Předpoklady úspěchu projektu .................................................................. 53 6.2 Specifika projektů IS/ICT ............................................................................... 54 6.2.1 Řízení projektů IS/ICT ............................................................................. 54 7 Metodika MMDIS ................................................................................................. 56 7.1 Popis metodiky MMDIS ................................................................................. 56 7.2 Dimenze MMDIS ........................................................................................... 58 7.2.1 Uživatelské pohledy na IS/ICT ................................................................. 59 7.2.2 Řešitelské pohledy ................................................................................... 59 7.2.3 Životní cyklus aplikace podle MMDIS ..................................................... 61 8 Rozšíření dimenze kvality metodiky MMDIS ........................................................ 67 8.1 Hodnocení připravenosti podniku na implementaci TASW (F0) ..................... 69 8.1.1 Hodnocení kvality informační strategie (F0.1) .......................................... 69 8.1.2 Hodnocení kvality personálního obsazení organizace a projektu (F0.2) .... 70 8.1.3 Hodnocení úrovně podnikových procesů organizace (F0.3) ...................... 71 8.2 Hodnocení předimplementační fáze (F1) ........................................................ 72 8.2.1 Hodnocení kvality projektového záměru (F1.1) ........................................ 72
8.2.2 Hodnocení kvality předimplementační studie (F1.2) ................................. 73 8.2.3 Hodnocení kvality procesu výběru TASW (F1.3) ..................................... 74 8.3 Hodnocení analytických fází (F2) ................................................................... 74 8.3.1 Hodnocení kvality zajištění školícího prostředí a školení projektového týmu zákazníka (F2.1) ....................................................................................... 74 8.3.2 Hodnocení kvality specifikace funkčních požadavků na TASW (F2.2) ..... 75 8.3.3 Hodnocení kvality nefunkčních požadavků na TASW (F2.3) .................... 75 8.3.4 Hodnocení kvality přípravy testovacích scénářů pro akceptační testy ....... 76 8.4 Hodnocení průběhu implementace (F3) .......................................................... 77 8.4.1 Hodnocení kvality zajištění testovacího prostředí ..................................... 77 8.4.2 Hodnocení kvality akceptačního testování ................................................ 77 8.4.3 Hodnocení kvality splnění cílů fáze implementace ................................... 78 8.5 Hodnocení zavedení TASW do provozu (F4) ................................................. 78 8.5.1 Hodnocení kvality provedení školení koncových uživatelů (F4.1) ............ 79 8.5.2 Hodnocení kvality dokumentace projektu implementace TASW (F4.1) .... 79 8.5.3 Hodnocení kvality průběhu a ukončení projektu implementace TASW ..... 80 9 Ověření modelu hodnocení kvality implementace TASW ...................................... 81 Závěr ........................................................................................................................ 82 Seznam použitých zdrojů .......................................................................................... 84 Seznam použitých zkratek ........................................................................................ 87
1 Úvod Předkládaná diplomová práce je zaměřena na problematiku řízení kvality softwaru a to zejména v oblasti implementace typového aplikačního softwaru (TASW) v podnikovém prostředí. Je to velmi aktuální téma, které trápí velkou část komerční sféry využívající informační technologie. Přestože se neustále zdokonalují vývojářské nástroje, metodiky pro vývoj a implementaci softwaru i principy projektového řízení, nedosahuje úspěšnost informatických projektů očekávaných hodnot. Může za to i výrazný nárůst složitosti IT projektů spojený s obrovským nárůstem dat, informačních potřeb a možností, což jsou aspekty, které je nutno vzít při hodnocení v potaz. Přesto je v tomto směru třeba hledat další řešení, která umožní produkovat kvalitnější, dostupnější a levnější softwarové produkty.
1.1 Cíle diplomové práce Pro tuto práci jsou vymezeny následující cíle. Hlavní cíl diplomové práce Hlavním cílem této diplomové práce je návrh metodiky pro řízení kvality implementace typového aplikačního softwaru (TASW) v podnikovém prostředí z pohledu projektového týmu na straně zákazníka. V podstatě se jedná o rozšíření dimenze kvality metodiky MMDIS1 o model hodnocení kvality průběhu implementace typového aplikačního softwaru z pohledu projektového týmu zákazníka. Pro účely této práce je oblast TASW zúžena na oblast podnikových informačních systémů. Dílčí cíle diplomové práce Dílčí cíle této práce jsou zaměřené na podporu hlavního cíle práce. Zahrnují obecné seznámení s problematikou řízení kvality při vývoji a implementaci softwaru a seznamují čtenáře s nejčastějšími chybami při implementaci typového aplikačního softwaru.
1
MMDIS - (Multidimensional Management and Development of Information System) – Metodika pokrývající komplexní řízení výkonu IS/ICT v organizaci. Více v kapitole 7
8
Dílčí cíle práce: vymezení pojmů v oblasti řízení kvality softwaru, seznámení s metodikami a nástroji pro řízení kvality softwaru, definice podnikových informačních systémů a požadavků na ně, identifikace problémů informatických projektů a projektů implementace TASW, zdůraznění potřeby projektového řízení při implementaci softwaru.
1.2 Východiska pro zpracování diplomové práce Autor čerpá z odborné literatury, jejíž seznam je zpracován v seznamu zdrojů, dále pak ze svých odborných zkušeností získaných více než čtrnáctiletou praxí na různých pozicích v podnikové IT sféře a v neposlední řadě ze zkušeností a informací získaných studiem na BIVŠ
v Praze,
obory
Řízení
projektů
informačních
systémů
(2010
–
2013)
a Informační technologie a management (2013 – 2015). Hlavním východiskem pro zpracování této práce jsou zkušenosti autora a jeho spolupracovníků na projektech budování a implementace informačních systémů. Jde především o integrovaný informační systém AC Pramen2 provozovaný jako referenční instalace ve společnosti Lázně Františkovy Lázně a.s., na kterém se jako člen projektu podílí od roku 2008 a od roku 2015 jako hlavní garant projektu. Dále o předešlý informační systém ve stejné společnosti, který má obchodní název GubiSPA 3, a který byl ve společnosti nasazen v letech 2004-2008. Další reference: 2005 – Epos (Elektronický pokladní a odbavovací systém) TASW pro multifunkční sportovní centrum ve společnosti Vitalmed a.s. na pozici projektový manažer 2010 – MS Dynamics NAV CRM – TASW pro řízení vztahu se zákazníky, integrace v rámci IS AC Pramen na pozici člen projektového týmu 2
IS AC Pramen je modulární ERP systém vybudovaný na platformě MS Dynamics NAV firmou AutoCont a.s. Je to oborové řešení (TASW) určené pro podporu lázeňství, hotelnictví a wellness zařízení, jehož předností je provázání provozních, léčebných i ekonomických dat v jednom systému.
3
GubiSPA je komplexní informační systém zaměřený na provoz lázeňských zařízení.
9
2013 – Plantour – TASW dispečerský plánovací systém - integrace v rámci IS AC Pramen na pozici člen projektového týmu
1.3 Metodika zpracování diplomové práce Práce vychází z praktických zkušeností získaných při implementacích, inovacích a správě informačních systémů (uvedených v kapitole 1.2) z pohledu zákazníka, podpory a školení koncových uživatelů a z pohledu spolupráce s IT odborníky dodavatelských firem. Dále pak z textů mezinárodních norem a metodik. Tyto informace jsou, analyzovány, hodnoceny a integrovány.
1.4 Výstupy a přínosy diplomové práce Výstupem této diplomové práce je model hodnocení kvality průběhu implementace typového aplikačního softwaru z pohledu projektového týmu zákazníka, který rozšiřuje dimenzi kvality metodiky MMDIS se zaměřením na implementaci. Hlavním přínosem je zvýšení úspěšnosti projektů implementace informačních systémů (TASW) v podnikovém prostředí.
10
2 Vymezení pojmů v předmětné oblasti Úkolem této kapitoly je seznámit čtenáře s pojmy používanými ve spojení s vývojem informačních systémů a jejich kvalitou. Kvalita Definice dle Mezinárodní normy ČSN EN ISO 9000 [14] zní takto:
Jakost - stupeň splnění požadavků souborem inherentních znaků. Požadavek je potřeba nebo očekávání, které: je stanoveno spotřebitelem (zákazníkem), je stanoveno závazným předpisem, se obvykle předpokládá. Za inherentní znaky jsou považovány vnitřní vlastnosti objektu kvality (produktu, procesu, zdroje, systému), které mu existenčně patří. Tyto, častěji označované jako „znaky jakosti“ můžeme členit na znaky měřitelné a atributy. Atributy nelze popsat číselnou hodnotou, nicméně mohou být pro spokojenost zákazníků rozhodující (např. příjemné vystupování, chuť). Dle mezinárodní normy pro Softwarové inženýrství ČSN 9126-1:2002 – Jakost produktu je kvalita definována takto: Jakost (quality) je celkový souhrn charakteristik entity, které ovlivňují její schopnost uspokojovat stanovené nebo předpokládané potřeby. Entitou je přitom myšlen softwarový produkt. Podle Vaníčka [8] je třeba hodnotit kvalitu u procesu i u produktu. Proces Proces je podle ISO 9000 [14] definován jako soubor vzájemně souvisejících a vzájemně působících činností, který přeměňuje vstupy na výstupy. Produkt Produkt je výsledek procesu. 11
Produkty mohou být těchto čtyř kategorií: služby, software, hardware, zpracované materiály. Konkrétní produkt může být kombinací těchto kategorií Informatický produkt bývá téměř vždy kombinací softwaru a služeb, případně i hardwaru. Informační systém (IS) Informační systém je neoddělitelnou součástí byznys systému, jehož účelem je zajištění správných informací ne správném místě a ve správný čas. [1] Informační a komunikační technologie (ICT) ICT jsou důležité pro plnění účelu informačního systému. Jsou to hardwarové a softwarové prostředky pro sběr, přenos, ukládání, zpracování a distribuci informací a pro vzájemnou komunikaci lidí a technologických komponent IS. [9] Metodiky vývoje softwaru Prostředky ke zvýšení úspěšnosti softwarových projektů. (Více v kapitole 4.4) TASW – typový aplikační software Aplikace vytvořená a dále rozvíjená specializovaným výrobcem. Je zaměřená na určité třídy podniků, dle jejich specializace a je vytvořena na základě generalizace jejich požadavků. (Více v kapitole 5.2.2) IASW - individuální aplikační software Aplikace vytvořená na míru podle potřeb organizace, instalovaná na definované technologické platformě. (Více v kapitole 5.2.1) Softwarové testy Prostředky ke zvýšení a ověření kvality softwarového produktu. (Více v kapitole 4.5)
12
Audit IS Nástroj k ujištění o souladu funkčnosti informačního systému a požadavků zákazníka. (Více v kapitole 4.6)
13
3 Problémy IT projektů Tato kapitola má za cíl seznámit čtenáře s aktuálním stavem úspěšnosti IT projektů dle renomované firmy Standish group4 a její studie Chaos Manifesto 2013. V další části jsou identifikovány hlavní důvody neúspěchu při implementaci TASW v podnikovém prostředí. Jako východisko pro tuto kapitolu je použita výše uvedená studie, odborná literatura a dále vlastní zkušenosti autora získané během spolupráce na IT projektech ve společnostech Lázně Františkovy Lázně a.s., VitalMed a.s., Františkovy Lázně – Aquaforum.
3.1 Studie Chaos Manifesto 2013 Společnost Standish Group se již od roku 1985 zabývá úspěšností a výkonností projektů ze světa informačních technologií. Průzkum je nazván Chaos Manifesto 2013: Thing big, Act small [16] a demonstruje úspěšnost IT projektů v časové rovině. Východiska pro zpracování studie Chaos Manifesto 2013: Thing big, Act small Aktuální databáze projektů5, odpovídající současným požadavků a kritériím pro analýzu obsahuje přibližně 50 000 IT projektů a neustále se rozšiřuje. Výzkum je demograficky zaměřen spíše na oblast USA (60% projektů) a Evropy (25% projektů). Více než 50% podniků účastnících se tohoto výzkumu je zařazeno mezi Fortune 1000 6, 30% podniků je považováno za středně velké podniky a 20% spadá do kategorie malých podniků. Výsledky studie Chaos Manifesto 2013: Thing big, Act small Jak je patrné z grafu č.1, je dlouhodobě úspěšnost IT projektů velmi nízká. Za úspěšný projekt je považován ten, který byl dodán včas, v rámci dohodnutých finančních prostředků a s očekávanou funkcionalitou. V roce 2012 bylo pouze 39% ze všech realizovaných IT projektů považováno za úspěšné. Oproti tomu bylo 18% IT projektů chybných (zrušených,
4
Standish Group - výzkumná a poradenská organizace, která se zaměřuje na výkonnost softwarových projektů (http://www.standishgroup.com). 5
Databáze projektů od roku 2002 do současnosti. Starší data byla eliminována, protože neodpovídala požadavkům pro analýzu 6
Seznam tisíce největších amerických firem podle časopisu Fortune
14
nedodaných nebo nikdy nepoužitých) a celých 43% neúspěšných (pozdě dodaných, mimo rozpočet nebo bez požadovaných vlastností a funkcí). Přesto jsou výsledky z roku 2012 nejlepšími za celou historii výzkumu. Úspěšnost IT projektů (Standish CHAOS study 2013)
100% 80% Chybné
60%
Neúspěšné Úspěšné
40% 20% 0% 2004
2006
2008
2010
2012
Graf č.1: Úspěšnost IT projektů v letech 2004 – 2012 Zdroj: Chaos Manifesto 2013 [16] V tomto srovnání musíme vzít v potaz, že nárůst úspěšně realizovaných projektů je sice malý, za to jejich složitost oproti dobám, z kterých jsou první údaje, je mnohonásobně vyšší a čas na jejich realizaci kratší. To vše díky lepším znalostem v oblasti řízení projektů, lepším nástrojům, technikám a v neposlední řadě metodikám vývoje IS. Důležité faktory nutné ke zvýšení úspěšnosti IT projektů dle Standish Group Podle organizace Standish group je zásadním problémem vysoké neúspěšnosti projektů jejich velký rozsah. Projekty jsou příliš složité na to, aby se daly úspěšně dokončit. Klíčem k úspěchu je rozdělení větších projektů na sekvenci menších, optimalizovaných částí projektu a na nich praktikovat agilní a optimalizační přístup vývoje. Rozdíl mezi úspěšností malých projektů (méně než 1 mil.$) a velkých projektů (více než 10 mil.$) je znázorněn v grafu č.2.
15
Graf č.2: Rozdíl v úspěšnosti malých a velkých IT projektů Zdroj: Chaos Manifesto 2013 [16] Zvýšení úspěšnosti je podle společnosti Standish Group výsledkem několika faktorů, jako
jsou pohled
na projekt
jako
celek,
zlepšení procesů,
metod,
dovedností
a rozhodování. Přímo na zvýšení úspěšnosti se také podílí pochopení důležitosti oblasti projektového řízení a vyškolených projektových manažerů. Dalším vlivem pozitivně ovlivňující výsledky posledního průzkumu, byl nárůst menších IT projektů, projektů řešených pomocí agilních metodik a zároveň pokles projektů řešených vodopádovým modelem (více v kapitole 4.4). To vše se však v konečné fázi odráží na zvýšení projektové režie a nákladů na projekt. Předpoklady úspěšného IT projektu dle Standish Group jsou [16]: podpora projektu výkonným managementem podniku, zapojení koncových uživatelů do projektu v dostatečné míře a včas, optimalizace – menší a včas dodané časti projektu, zkušenosti členů projektového týmu, schopný projektový management, použití agilní metodik vývoje IS, jasně určené cíle projektu – podporující cíle a strategii podniku.
3.2 Důvody neúspěchu při implementaci TASW Výsledky studie Chaos Manifesto 2013 [16] se zaměřují na celou oblast IT projektů, nejen na projekty implementace TASW, což sice snižuje její vypovídající hodnotu pro účely této práce, přesto je však jisté, že se s nízkou úspěšností potýkají i projekty implementace 16
TASW, což může autor z vlastní zkušenosti potvrdit. Nejčastějším důvodem, proč jsou projekty implementace TASW označeny za neúspěšné, je, stejně jako u ostatních IT projektů, překročení rozpočtu na projekt a překročení stanoveného časového plánu. I přes tyto problémy je ve většině případů nakonec předán TASW k užívání. Ne vždy jsou však splněna všechna akceptační kritéria a projekt je zdárně ukončen. To s sebou může přinášet ještě mnoho vícenákladů v oblasti úprav funkcionality produktu. Bohužel existuje mnoho případů, kdy se zákazník stal „rukojmím“ implementátora a v podstatě mu nezbývá, než na tuto situaci přistoupit. Je jen málo organizací, které si mohou dovolit opustit problematický projekt, odepsat investici do něj a začít znovu, byť s novými zkušenostmi, od nuly. Nejčastější rizika projektu IS Podle Voříška [22], Basla [1] a zkušeností autora patří mezi nejčastější rizika projektu IS tyto: Obecná rizika projektu IS jsou: opožďování a překračování plánovaných termínů, překračování plánovaných nákladů, sladění priorit s dalšími činnostmi a projekty v podniku, řízení zdrojů. Rizika projektu IS na straně zákazníka jsou:
nedostatečná pozornost zavádění IS ze strany majitelů a pracovníků vrcholového managementu – odraz v přípravě, průběhu a podpoře projektu IS (nejasně definované očekávané cíle, zajištění projektu je delegováno, nedostatečné seznámení se specifiky projektu),
chybný odhad zdrojů potřebných pro projekt, chybně nastavené globální a informační strategie, chybná specifikace požadavků nebo její změna v průběhu projektu, špatně nastavené motivační systémy pro pracovníky pracují na projektu IS, nasazení nevhodné aplikace, volba nesprávného dodavatele, nedůsledné řízení projektu, nízká úroveň projektového týmu zákazníka nedostatečné vyškolení a příprava uživatelů systému. 17
Rizika projektu IS na straně dodavatele jsou: nedostatečné schopnosti konzultantů, nedostatečné schopnosti programátorů, nízká úroveň školení uživatelů, nekvalitní dokumentace. Cílem autorem navrhovaného modelu hodnocení kvality průběhu implementace typového aplikačního softwaru je předcházet a včas upozorňovat na výše uvedená rizika z pohledu projektového týmu zákazníka.
18
4 Kvalita softwaru Cílem této kapitoly je seznámení s disciplínami, které mají přímý vliv na výslednou kvalitu vyvíjeného softwaru a s důvody pro potřebu řízení kvality softwaru. Dále stručně popisuje současný stav norem týkajících se kvality softwaru a metodiky jeho budování.
4.1 Řízení kvality softwaru Podle Buchalcevové [12] je smyslem řízení kvality dosažení nezbytné a postačující kvality, pro naplnění skutečných potřeb uživatelů. Požadavky definované uživateli ale často neodráží jejich skutečnou potřebu a to především z těchto důvodů:
uživatel si často neuvědomuje své skutečné potřeby,
potřeby se mohou po jejich stanovení změnit,
rozdílní uživatelé mají rozdílné provozní prostředí,
obtížné je zjistit potřeby všech typů uživatelů zvláště u typového aplikačního softwaru.
Proto je obtížné na začátku životního cyklu specifikovat požadavky na jakost v celém rozsahu a je třeba počítat i s jejich změnami.
4.2 Zajištění kvality IS Existují dva pohledy na zabezpečení kvality IS. Prvním je zajištění kvality procesu budování IS a druhým je zajištění kvality samotného produktu. [12] Zajištění kvality procesu budování IS Budování IS v současnosti představuje hlavně implementaci již hotových řešení (TASW) a integraci komponent a služeb, protože úplně nové IS se vytváří zřídka. Pro zajištění kvality v tomto směru slouží řada norem ISO 9000. Základní normou je ČSN ISO 9001:2001 Systémy managementu jakosti – Požadavky na systém, která specifikuje požadavky na systém řízení jakosti. Jeho zavedení umožňuje organizaci trvale poskytovat
19
produkt, který splňuje požadavky zákazníka a příslušné požadavky předpisů, zvyšovat spokojenost zákazníka a zlepšovat podnikové procesy. Velký význam pro organizace budující IS má norma ISO/IEC 90003, resp. ČSN ISO/IEC 90003 Softwarové inženýrství – Směrnice pro použití ISO 9001:2000 na počítačový software. Organizace, která chce získat certifikaci ISO 9000, musí definovat procesy pro vývoj, provoz a údržbu softwaru, jejich posloupnost a vazby. Pro dosažení tohoto cíle se doporučuje použít normu ISO/IEC 12207 – Procesy v životním cyklu softwaru (podrobněji v kapitole 4.4.1). Úroveň kvality procesu budování IS lze ověřit na základě posouzení procesů dle normy ISO/IEC 15504, která se zaměřuje na posuzování procesu a využití posuzování procesu k jeho zlepšování a určování jeho způsobilosti. Další možností je pomocí metody SCAMPISM posuzující dle modelu CMMI (podrobněji v kapitole 4.4.1). Zajištění kvality produktu Tento pohled na kvalitu posuzuje vlastnosti IS z pohledu uživatele. Z tohoto pohledu je však velmi obtížné nalézt společné požadavky na kvalitu IS, někdy může být klíčovým kritériem jednoduchost, jindy spolehlivost [27]. Přesto existuje řada norem, které definují nebo posuzují kvalitu softwaru (viz následující kapitola). Např. norma ISO/IEC 9126-1 přináší model kvality a specifikuje 6 charakteristik jakosti, z nichž každá obsahuje ještě podcharakteristiky a jsou uvedeny níže: I. Funkčnost (Functionality): a. Funkční přiměřenost (Suitability); b. Přesnost (Accuracy); c. Schopnost spolupráce (Interoperability); d. Bezpečnost (Security); e. Shoda ve funkčnosti (Functionality Compliance); II. Bezporuchovost (Reliability): a. Zralost (Maturity); b. Odolnost vůči vadám (Fault Tolerance); c. Schopnost zotavení (Recoverability); d. Shoda v bezporuchovosti (Reliability Compliance); III. Použitelnost (Usability): a. Srozumitelnost (Understandability); b. Naučitelnost (Learnability); c. Provozovatelnost (Operability); 20
d. Atraktivnost (Attractivness); e. Shoda v použitelnosti (Usability Compliance); IV. Účinnost (Efficiency): a. Časové chování (Time Behaviour); b. Využití zdrojů (Resource Utilisation); c. Shoda v účinnosti (Efficiency Compliance); V. Udržovatelnost (Maintainability): a. Analyzovatelnost (Analysability); b. Měnitelnost (Changeability); c. Stabilnost (Stability); d. Testovatelnost (Testability); e. Shoda v udržovatelnosti (Maintainability Compliance); VI. Přenositelnost (Portability): a. Přizpůsobitelnost (Adaptability); b. Instalovatelnost (Installability); c. Slučitelnost (Co-existence); d. Nahraditelnost (Replaceability); e. Shoda v přenositelnosti (Portability Compliance).
4.3 Mezinárodní normy v oblasti řízení kvality softwaru V této podkapitole jsou stručně představeny normy v oblasti řízení kvality softwaru. Popis vychází z [19]. ISO/IEC 9126 se společným názvem Softwarové inženýrství – Jakost produktu
9126-1 Model jakosti
9126-2 Vnější míry jakosti
9126-3 Vnitřní míry jakosti
9126-4 Míry jakosti užití
ISO/IEC 14598 Softwarové inženýrství – Hodnocení softwarového produktu
14598 – 1 Obecný přehled
14958 – 2 Plánování a řízen
14958 – 3 Postup pro řešitele
14958 – 4 Postup pro akvizitéra 21
14958 – 5 Postup pro nezávislého hodnotitele
14958 – 6 Dokumentace vyhodnocovacích postupů Jde o neucelenou a rozsáhlou standardizaci s absencí jednotné metodiky a velkým
množstvím metrik, což vedlo k iniciativě začít práce na nové řadě standardů s uceleným konceptem. V rámci mezinárodního vědeckého normalizačního projektu SQuaRE7 vznikla norma ISO/IEC 25000, která definuje tři modely kvality - model kvality softwarového produktu, model jakosti užití systému a modelu kvality údajů. Společně tyto modely poskytují komplexní sadu vlastností jakosti souvisejících s širokou škálou zainteresovaných stran: vývojáři softwaru, systémoví integrátoři, nákupčí, vlastníci, správci, dodavatelé a koncoví uživatelé. Tyto modely jsou užitečné pro určení požadavků, stanovení opatření a provádění hodnocení jakosti. ISO/IEC 25000 Jako zdroj pro popis sady norem ISO /IEC 25000 je použita semestrální práce skupiny studentů VŠE [26]. 2500n Obecný oddíl kvality softwarového produktu ISO/IEC 25000:2014 Obecný přehled a příručka SQuaRE (Guide to SQuaRE) Poskytuje obecný přehled obsahu metodiky SQuaRE, společných referenčních modelů a definic. Popisuje vzájemný vztah mezi dokumenty. Vysvětluje proces přechodu mezi staršími normami ISO/IEC 9126 a řady 14598 a normou SQuaRE. Nejdůležitější částí této normy jsou tři hlavní modely, pomocí kterých norma mapuje celou metodiku SQuaRE.
SQuaRE obecný referenční model - rozcestník SQuaRE.
Model Životního cyklu měření a vyhodnocování kvality softwarového produktu - se zabývá kvalitou software ve třech hlavních fází softwarového produktu životního cyklu: produkt ve vývoji, výrobek v provozu a produktu v použití.
Model Kvalitní konstrukce - kategorizace kvality softwaru atributy do vlastností, subvlastností a atributů kvality.
ISO/IEC 25001:2014 Plánování a řízení (Planning and management)
7
Software product Quality Requirements and Evaluation - Požadavky na kvalitu a hodnocení softwarového produktu
22
Obsahuje požadavky a doporučení pro organizace pověřené implementací a řízením specifikace požadavků pro kvalitu softwaru a hodnocením softwarové kvality prostřednictvím poskytování technologií, nástrojů, zkušeností a manažerských dovedností. Uživatelé normy ISO/IEC 25001 jsou osoby odpovědné za: řízení technologie používané pro specifikaci požadavků a provádění hodnocení, specifikaci požadavků softwarové kvality produktu, podpora hodnocení softwarové kvalit produktu, řízení softwarového vývoje. 2501n Oddíl modelu kvality Definuje detailní model kvality, interní a externí charakteristiky a charakteristiky užití tohoto modelu pro software a data. Model kvality dat definovaný v této kapitole seznamuje uživatele s možnostmi definování požadavků pro měření kvality dat a nastavení kritérií tak, aby bylo možné budoucí výsledky automatizovaně interpretovat. Modely lze použít např. pro: identifikaci softwarových a systémových požadavků, ověření komplexnosti definice požadavků, identifikaci cílů softwarového a systémového testovaní, identifikaci kritérií kontroly kvality jako části zabezpečovaní jakosti, identifikaci akceptačních kritérií pro softwarový produkt a ustanovení jakostních charakteristik na podporu těchto aktivit. ISO/IEC 25010:2011 Systémové a softwarové modely kvality (System and software quality models) Model jakosti užití: Definuje stupeň míry uspokojení potřeb uživatele. Měří se dosažení stanovených cílů z pohledu účinnosti, efektivnosti, spokojenosti, osvobození od rizika a pokrytí celého tohoto kontextu (všech zmíněných charakteristik). Tyto charakteristiky (podcharakteristiky) jsou v normě specifikovány.
Tento model je použitelný na kompletní systém skládající se z
člověka a počítače, včetně jakosti užití systému a jakosti užití produktu.
23
Model jakosti produktu Skládá se z osmi charakteristik (funkční vhodnost, spolehlivost, efektivita výkonu, použitelnost, bezpečnost, kompatibilita, udržovatelnost a přenositelnost), vztahujících se ke statickým vlastnostem softwaru a dynamickým vlastnostem počítačového systému. Model je použitelný jak pro počítačové systémy, tak pro softwarové produkty. Mnoho charakteristik je aplikovatelných i na hodnocení systémů a služeb. ISO/IEC 25012:2008 Model kvality dat (Data quality model) Definuje obecný model kvality dat, který se vztahuje na data uchovávaná ve strukturované podobě v rámci počítačového systému. Tato norma se zaměřuje na kvalitu dat jako součást počítačového systému a určuje hodnotící charakteristiky pro kvalitu používaných cílových dat. Model kvality dat Model kvality dat definovaný v této normě posuzuje znaky kvality dat dle patnácti charakteristik, dále dělené podle dvou hledisek na vlastní a závislé na systému (přesnost, úplnost, konzistence, důvěryhodnost, aktuálnost, dostupnost, dodržování, důvěrnost, účinnost, preciznost, návaznost, srozumitelnost, dostupnost, přenositelnost, návratnost). 2502n Oddíl metrik kvality Definuje referenční model měření kvality softwarových produktů a poskytuje prakticky orientovaného průvodce pro jejich implementaci. Uvedené postupy lze aplikovat na měření vnitřní a vnější kvality software a na kvalitu vlastního použití. ISO/IEC 25020:2007 Referenční model a příručka k metrikám (Measurement reference model and guide) Popisuje vztah mezi samotným modelem měření kvality a k němu přidruženým charakteristikám, atributy softwarového produktu, měřícími funkcemi a metodami. ISO/IEC 25021:2012 Prvky měření kvality (Quality measure elements) Definuje sadu doporučených základních a odvozených měřících prvků, které by měly být použity během celého životního cyklu vývoje software. ISO/IEC 25022:2007 Měření kvality v praxi (Measurement of quality in use) Popisuje metodiku pro jednotlivá měření a poskytuje návod pro jejich reálné použití. Poskytuje vodítka pro určení prvků měření kvality - Quality Measure Elements (QME). 24
ISO/IEC 25023:2007 Měření kvality systému a softwarového produktu (Measurement of system and software product quality) Definuje měřítka kvality pro kvantitativní měření systému a kvality softwarového produktu z hlediska jejich dílčích vlastností a charakteristik definovaných v ISO/IEC 25010 a je určena k použití společně s ostatními normami z oddílu 2502n z důvodu splnění očekávání uživatelů této metodiky. ISO/IEC 25024:2007 Měření kvality dat (Measurement of data quality) Definuje měřítka kvality pro data a pro kvantitativní měření datové kvality a úzce navazuje na normu ISO/IEC 25012. 2503n Oddíl požadavků na jakost Definuje standardy, jež budoucím uživatelům pomáhají správně definovat metriky pro měření jakosti. ISO/IEC 25030:2007 Požadavky kvality softwaru (Quality requirements) Pomáhá formulovat požadavky, které jsou klíčové při hodnocení jakosti. Požadavky musí být v souladu s požadavky zainteresovaných osob, jasné a přesně definované, správné, kompletní a konzistentní, ověřitelné a měřitelné. Používá se při: specifikaci požadavků (základ pro smlouvu, výběrové řízení), plánování (překlad vnějších požadavků SW do vnitřních), vývoji (možnost včasného zjištění nedostatků SW), vyhodnocení (objektivní posouzení a certifikace kvality SW produktu). 2504n Oddíl vyhodnocování jakosti Definuje standardy, postupy a požadavky na vyhodnocování softwarových produktů. Obsahuje požadavky, doporučení a pokyny pro vyhodnocení softwarového produktu, ať už je provádí akvizitér, nezávislý hodnotitel nebo vývojář. ISO/IEC 25040:2011 - Vyhodnocení procesu (Evaluation process) Referenční model obsahuje obecné požadavky na specifikaci a vyhodnocení kvality software a objasňuje obecné pojmy. Poskytuje popis procesu pro hodnocení kvality softwarových produktů a uvádí požadavky na použití tohoto procesu.
25
ISO/IEC 25041:2012 - Příručka vyhodnocení pro vývojáře, akvizitéry a nezávislé hodnotitele (Evaluation guide for developers, acquirers and independent evaluators) Požadavky, doporučení a pokyny pro hodnocení kvality produktů speciálně pro vývojáře, akvizitéry a nezávislé hodnotitelé. ISO/IEC 25045:2010 - Modul vyhodnocení obnovy (Evaluation module for recoverability) Norma je použitelná pro informační systémy provádějící exekuční transakce, podporující jednoho nebo více souběžných uživatelů, kde je důležité, aby pro vývojáře, akvizitéry a nezávislé hodnotitele byla brzká obnova a snadná správa.
4.4 Metodické přístupy k tvorbě IS/ICT Cílem metodických přístupů k tvorbě IS je zvyšovat kvalitu a úspěšnost softwarových projektů. Jak je patrné z kapitoly 3.1 je na tomto poli stále co zlepšovat. Existují 2 základní přístupy, tradiční a agilní. Každý z nich je postaven na jiných přístupech a předpokladech, které jsou stručně popsány níže. Zdroj pro zpracování této kapitoly je [2].
4.4.1 Tradiční metodické přístupy V rámci tradičních přístupů je tvorba IS definovatelným procesem, který je možno detailně popsat, opakovat a vylepšovat. Typicky sem patří referenční modely procesů, modely životního cyklu, posuzování zralosti procesů a tradiční, rigorózní (těžké) metodiky vývoje IS. Rigorózní metodiky Jsou vhodné pro standardní nebo velké softwarové projekty. Podrobně a přesně definují a popisují procesy, požadavky, činnosti a vytvářené produkty, čímž přispívají ke zlepšení procesu budování IS a jeho výsledné kvality. Zpravidla jsou postaveny na vodopádovém modelu vývoje, ale není to pravidlem. Patří mezi ně metodiky OPEN, RUP, EUP. Referenční model procesů a posuzování procesů Je popsán například v normě ISO/IEC 12207 Procesy v životním cyklu softwaru z roku 2008. Zahrnuje procesy, činnosti a úkoly prováděné ve všech fázích životního cyklu 26
softwaru. Referenční modely nepředepisují ani nedefinují hotové procesy, které by bylo možno převzít, ale vytváří procesní rámec sloužící jako předloha pro tvorbu vlastních procesů, které jsou upraveny dle konkrétních podmínek organizace. Zahrnuje 43 procesů v 7 skupinách. Pro každý je definován účel, výstupy, činnosti a úkoly. Zralost procesů se vyhodnocuje dle modelu CMMI (Capability Maturity Model Integration) – Integrační model zralosti. Slouží k postupnému zlepšování podnikových procesů. Pro reprezentaci úrovně používá dva ukazatele, kontinuální (tab.1) (umožňuje zlepšovat procesy jen v některé procesní oblasti) a stupňovitý (tab.2) (určuje množinu procesních oblastí, která musí být pro každou úroveň zralosti zavedená). Úroveň
Úroveň způsobilosti
Popis
0
Neúplný (Incomplete)
Proces není vykonáván vůbec nebo jen částečně
1
Vykonávaný (Performed)
2
Řízený (Managed)
3
Definovaný (Defined)
Proces je vykonáván, plní cíle, není součástí politik organizace (hrozí jeho ztráta) Proces je vykonáván, plánován, monitorován, vyhodnocován, institucionalizován řízený proces přizpůsobený specifickým podmínkám organizace
Tab. 1: Kontinuální reprezentace úrovně způsobilosti Zdroj: Tvorba informačních systému [2]
Úroveň
Úroveň zralosti
Popis
1
Úvodní (Initial)
Náhodné nebo chaotické SW procesy
2
Řízená (Managed)
3
Definovaná (Defined)
4
Kvantitativně řízená (Quantitatively Managed)
5
Optimalizovaná (Optimizing)
Definovány a zavedeny procesy řízení projektu, jsou součástí politik organizace, prováděny dle popisu, kontrolují a monitorují se Úroveň 2 + proces definován na úrovni organizace, posán ve standardech, procedurách, nástrojích, metodách. Je institucionalizován Úroveň 3 + řízení procesů na úrovni statistických a kvantitativních metod. Možnost předpovídat výkon procesů Úroveň 4 + neustálé zlepšování procesů na základě pochopení příčin jejich změn v průběhu.
Tab. 2: Stupňovitá reprezentace úrovně zralosti Zdroj: Tvorba informačních systému [2] Modely životního cyklu Za životní cyklus systému považujeme dobu, která začíná úmyslem tvorby systému a končí v momentě, kdy se systém přestane používat. Modely životního cyklu pak představují
27
rámec procesů a činností organizovaných do jednotlivých fází. Cílem je kvalitní softwarový produkt odpovídající požadavkům zákazníka. Vodopádový model Vodopádový model je jedním z nevýznamnějších modelů životního cyklu. Projekt je rozdělen do jednotlivých fází, které na sebe sekvenčně navazují. Výstupy předešlé fáze slouží jako vstupy fáze následující. Klade se velký důraz na kvalitu zpracování prvotních fází projektu a kvalitní dokumentaci, čímž se eliminují dodatečné náklady na opravu chyb v pozdějších fázích projektu. Změny požadavků po ukončení jednotlivých fází se řeší obtížně. Není vhodný pro příliš složité projekty, kde nejsou od začátku detailně známy všechny požadavky nebo se mohou v průběhu projektu měnit. V reakci na nedostatky vzniklo mnoho modifikací vodopádového modelu jako např. V-model, v rámci kterého v každé fázi vývoje probíhá testování, na kterém se podílí zákazník. Iterativní modely Iterativní modely pro vývoj systému staví na předpokladu, že člověk lépe řeší více menších problémů. Projekt je proto rozdělen na řadu dílčích projektů – jednotlivých iterací. Každá iterace v sobě zahrnuje všechny vývojové fáze a jejím výsledkem musí být funkční část systému, která je na konci každé iterace otestována a integrována do systému. V roce 1986 definoval Barry Boehm Spirálový model, který odstranil největší nedostatky vodopádového modelu. Hlavní myšlenkou je integrace nových menších částí systému do důkladně prověřeného základu. Probíhá v několika krocích, které se neustále opakují, dokud není produkt hotový. Spirálový model zavádí opakovanou analýzu všech rizik v každé iteraci, na které závisí postup do další fáze. Výhodou spirálového modelu je rychlá zpětná vazba od zákazníka při ukončení každé iterace, kdy má zákazník k otestování funkční část systému, ke které se může vyjádřit. Díky pravidelnému testování dochází k včasnému odhalení chyb a zároveň ke snížení nákladů na jejich odstranění. Zároveň je také díky tomuto přístupu lépe řešený problém změnových požadavků.
4.4.2 Agilní přístupy k vývoji softwaru Díky tomu, že potřeby a nároky uživatelů softwaru jsou velmi specifické a předem nedostatečně definované, vznikly agilní (svižné, hbité) přístupy k programování softwaru. Na rozdíl od klasických rigorózních metodik nelpí na detailně zpracované analýze, složitém 28
a bezchybném návrhu architektury a obsáhlé dokumentaci. Jejich použití je vhodné v případech, kdy nelze přesně popsat softwarové procesy nebo nejsou předem přesně specifikované požadavky. Jejich prioritou je dodat zákazníkům v co nejkratší době funkční aplikaci, která podporuje jejich obchodní cíle a zároveň umožňuje pružně a rychle reagovat na změnové požadavky zákazníka. V průběhu řešení projektu komunikuje tým se zákazníkem a průběžně přehodnocuje a upravuje priority. Na těchto předpokladech jsou založeny všechny agilní metodiky, jejichž základní principy jsou popsány v manifestu agilního programování. Agilní metodiky a jejich základní principy: Jednotlivec a interakce
před
procesy a nástroji
Fungující software
před
vyčerpávající dokumentací
Spolupráce se zákazníkem
před
vyjednáváním o smlouvě
Reagování na změny
před
dodržováním plánu
Extrémní programování (Extreme Programming, XP) – časté dodávky softwaru v krátkých vývojových cyklech, párové programování, jednotkové testování, komunikace mezi zákazníkem a vývojáři. http://xprogramming.com/ SCRUM – každodenní krátké meetingy (provedená, plánovaná činnost, problémy), iterativní vývoj (iterace se nazývá Sprint, trvá 2 – 4 týdny), výstupem každého Sprintu je tzv. release (funkční demo provedených úprav), na základě zpětné vazby zákazníka rychlá reakce na změny v požadavcích. https://www.scrumalliance.org/ Vývoj řízený vlastnostmi (Feature Driven Development, FDD) – tvorba doménového modelu, který se převede na seznam vlastností (funkcionalita, přinášející hodnotu uživateli), 5 fází (3 sekvenční a 2 iterační), iterace cca 2 týdny, výsledkem každé iterace nová verze produktu. http://www.featuredrivendevelopment.com/ Mezi další agilní metodiky patří Lean Development, Dynamic System Develompment Method (DSDM), Test Driven Development (TDD), Adaptive Software Development (ASD), Crystal metodiky, atd. Omezení Agilního vývoje Použití agilní metodiky má také svá rizika, a to[17]: rizika spojená s nepřesným zadáním nebo se složitostí budovaného systému, 29
rizika spojená s fluktuací členů týmu, rizika spojená s tím, že neexistuje dokumentace v obvyklém rozsahu, rizika spojená s nedodržováním termínů a překračováním rozpočtů. Kdy není vhodné používat agilní metodiky: Použití agilních metodik se nedoporučuje pro [17]: kritické systémy, kde je nutné přesně dodržovat dohodnuté (technologie), rozsáhlé systémy, které se nedají dobře dekomponovat, případy, kdy nejsou k dispozici kvalitní řešitelé, případy, kdy není ochota se domlouvat o cíli za pochodu (jak uzavřít smlouvu, jak sankce za neplnění).
4.5 Testování softwaru Tato část má za cíl seznámit čtenáře s pojmy, činnostmi, rolemi a metodami, které se používají při testování softwaru, které má přímý vliv na jeho výslednou kvalitu.
4.5.1 Co je to testování softwaru Testování softwaru je součástí procesu vývoje softwaru, který je popsán v jednotlivých metodikách. Jeho úkolem je zjistit, zda vyvíjený produkt odpovídá definovaným požadavkům. Za tímto účelem prochází různými druhy testů na různých úrovních s cílem odhalení chyb a získání informací o tom, zda daný produkt vyhovuje zamýšlenému účelu [11]. Vlastnosti, které se v rámci testování ověřují, lze rozdělit do dvou skupina a to na vlastnosti funkční a nefunkční [24]: Funkční vlastnosti se týkají samotného účelu testované aplikace a jejich testování má ověřit, že aplikace správně vykonává úkoly, pro které byla vytvořena. Testuje se také schopnost aplikace vypořádat se s nekorektním uživatelským chováním, kdy případný nevalidní vstup vyvolá předem definovaný chybový stav. Nefunkční vlastnosti aplikace jsou ty, které se týkají jejího výkonu, dostupnosti a zabezpečení.
30
Axiomy testování softwaru Axiom - tvrzení, jehož pravdivost není třeba dokazovat. Ron Patton [4] jich ve své knize Testování softwaru definoval celou řadu. Zde jsou některé z nich: Žádný program není možné otestovat kompletně počet možných vstupů a výstupů je příliš velký, počet možných cest, které vedou skrze software je příliš velký, specifikace softwaru je subjektivní. Testování softwaru je postavené na riziku Při vynechání jakéhokoliv myslitelného scénáře testování softwaru, vzniká riziko existence chyby v programu. Testování nikdy nemůže prokázat, že chyby neexistují Testování umožňuje prokázat existenci chyb v softwaru, ale nelze jím prokázat jeho bezchybnost. Čím více chyb najdete, tím více jich v softwaru je Chyby se vyskytují ve skupinách, programátoři často dělají stejné chyby. Pokud je při testování nalezeno více chyb v určité části systému, je pravděpodobné, že se zde nachází ještě další.
4.5.2 Pojmy z oblasti testování softwaru Chyba V našem případě uvažujeme chybu softwarovou, za kterou považujeme jakoukoliv odchylku od specifikace produktu, která je definovaná vývojovým týmem daného softwaru. Nejčastějším původcem chyb v softwaru je samotná specifikace, která buď vůbec neexistuje, není dostatečně podrobná, neustále mění nebo není důkladně prodiskutována celým vývojovým týmem. Dalším důvodem vzniku softwarových chyb je z podobných důvodů návrh a teprve pak samotný programový kód [4].
31
Testovací případ (Test Case) Testovací případ, často se využívá i anglický výraz „test case“, popisuje konkrétní akce prováděné s určitou softwarovou komponentou a jejich očekávané výsledky. Vytváří se jak pro manuální tak pro automatizované testy. Pro účely manuálního testování jsou tvořeny seznamem prováděných kroků a očekávaných výsledků. Automatizované testovací případy se označují jako testovací skript a samy vyhodnocují úspěch či neúspěch. Je to dokument obsahující [25]: identifikátor - jedinečný identifikátor pro odkazování z ostatních dokumentů, účel - k čemu daný testovací případ slouží, podmínky - seznam potřebných dat či vlivů prostředí podstatných pro provedení testovacího případu, specifikace kroků a vstupů - seznam všech kroků a souvisejících vstupních dat, nutných pro úspěšné a opakovatelné provedení testovacího případu, očekávané výsledky - souhrn všech informací, potřebných k určení, zda případ proběhl úspěšně či nikoliv. Testovací scénář (Test script) Sada několika testovacích případů tvoří testovací scénář. Testovací případy na sebe musí navazovat a tvořit tak skupinu logicky navazujících kroků, jejichž účelem je otestovat vybranou funkčnost aplikace. Testovací scénář by měl obsahovat především tyto údaje [25]: oblasti k testování - oblasti, vlastnosti a funkce, které se budou testovat v rámci daného scénáře, kategorie testů - údaj o kategorii testů, do které tento scénář spadá, testovací případy - seznam všech testovacích případů, které tvoří daný scénář, metriky hodnocení - metriky pro určení, zda scénář proběhl úspěšně či nikoliv. Testovací strategie (Plán testování) Nejdůležitější dokument pro celý proces testování. Obsahuje především rozsah postupu testování software, definuje druhy a kategorie testů, stanovuje harmonogram prací. Plán testování musí obsahovat [25]:
32
cíle testování - přesné očekávání od provedení testů nad softwarem, seznam plánovaných oblastí k testování - s přiřazením priority, která bude určovat, v jakém pořadí budou oblasti otestovány, kategorie testů - které budou využity během testovacího cyklu, seznam testovacích případů - seznam unikátních identifikátorů testovacích případů, definice rizik pro testování - definice hlavních rizik, které mohou znemožnit testování, jejich ohodnocení a návrh řešení zpracován v analýze rizik, požadavky na testovací data – definice dat, které jsou nezbytná pro provádění testů, harmonogram testů – návaznost činností.
4.5.3 Role při testování softwaru Jak bylo již dříve řečeno, záleží na jednotlivých metodikách, s jakými rolemi pracují. V ideálním případě se na testování podílí tým pracovníků složený z těchto rolí: Tester Provádí manuální testy softwaru dle předem zpracovaných testovacích scénářů od test analytika. Předpokládá se dobrá znalost aplikace získaná od analytika nebo z funkční specifikace. V průběhu testů zaznamenává tester nalezené chyby. Tester by měl disponovat způsobem myšlení, které mu umožní odhalovat chyby (podezíravý, zvídavý, vynalézavý, pečlivý a důsledný). Dále by měl být komunikativní směrem k analytikům, aby prostřednictvím dotazů pochopil jak se má aplikace chovat [25]. Test analytik a návrhář testů Zabývá se tvorbou test analýzy (test case, test suity a testovací scénáře). Z dostupných zdrojů se snaží pochopit aplikaci, která se bude vyvíjet a následně má za úkol vytvářet testy a testovací postupy, volit vhodné testovací nástroje a rozhodovat o testovacím prostředí a testovacích datech. Testy zároveň vyhodnocuje a prezentuje. Test analytik by měl pečlivý a vytrvalý a v neposlední řadě by měl být obdařen schopností analytického myšlení [25]. Test manažer Tvoří testovací strategii, která zahrnuje požadavky na testování, harmonogramy, etapy testů, typy testů, metriky pro jejich hodnocení, vstupy a výstupy testů. Je odpovědný za 33
zajištění týmu testerů a potřebného hardwaru a softwaru. Tvoří komunikační článek mezi analytiky a vývojáři a reportuje výsledky projektovému manažerovi. Test manažer by měl být rozhodný, schopný plánovat a delegovat práci. Měl by být schopný motivovat tým ke kvalitní a důkladné práci. Vzhledem k nutnosti komunikace s vývojovým týmem je výhodou pokud ovládá nějaký objektově orientovaný programovací jazyk [25].
4.5.4 Typy testů Pro zajištění kvality výsledného softwarového produktu je třeba v jednotlivých fázích projektu provádět testování. Zdrojem informací pro tuto kapitolu je portál testování softwaru [25]. Podle toho v jaké fázi vývoje jsou testy prováděny, se dělí na: testování programátorem (Developer testing), testování jednotek (Unit testing), funkční testy (Factory acceptance tests), integrační testování (Integration testing), systémové testování (System testing), akceptační testování (Acceptance testing). Testování programátorem (Developer testing) Testy ihned po vytvoření kódu, označují se jako „Assembly tests“. Většinou je provádí jiný programátor, než tvůrce. Program se kontroluje na úrovni zdrojového kódu. Protože odstranění chyby v této fázi je nejméně nákladné, je třeba jim věnovat patřičnou pozornost. Testování jednotek (Unit testing) Po ověření kódu programátorem následuje test jednotek. U objektově orientovaného programování se testují jednotlivé třídy a metody. Testovanou jednotku chápeme jako nejmenší funkční celky programu, ideálně bez závislostí na okolních objektech. Testy jsou ve formě programového kódu a z pravidla je tvoří vývojáři. Takto nalezené chyby se relativně snadno a stále ještě levně opravují, protože se vždy hledá jen v rámci testované jednotky.
34
Funkční testy (Factory acceptance tests) Testy prováděné na straně dodavatele. Mají za úkol ověřit, že aplikace správně plní všechny požadované funkce. Mají velký vliv na výslednou funkčnost produktu a z toho důvodu se funkční testy provádí během celého testovacího cyklu, nejčastěji v úrovni integrační, systémové a akceptační. Tato fáze testování odhaluje ve srovnání s ostatními vysoký počet chyb, proto je třeba na ní klást důraz. Do této kategorie spadají i testy nefunkční, ověřující všechny vlastnosti aplikace, které přímo nesouvisí s jejími funkcemi, ale přesto jsou pro její správné fungování podstatné. Patří sem především testování výkonu (Performance testing), zabezpečení či efektivního využívání výpočetních zdrojů. Integrační testování (Integration testing) Integrační testy připravuje testovací tým. Testuje se integrace jednotlivě ověřených částí, které se postupně přidávají. Ověřuje se bezchybná komunikace jak mezi komponentami aplikace, tak mezi komponentami a okolím aplikace (operační systém, hardware, rozhraní ostatních systémů). Integrační testy mohou být jak manuální, tak i automatizované.
Systémové testování (System testing) Po integračních testech následují testy systémové, kdy je již aplikace kontrolována jako funkční celek. Používají se v pozdější fázi vývoje a ověřují aplikaci u pohledu koncového zákazníka. Postupuje se podle připravených testovacích scénářů, kdy se simulují kroky, které mohou v praxi nastat. Probíhají v několika iteracích. Nalezené chyby jsou odstraněny a při dalších průchodu znovu otestovány. Systémové testy zahrnují jak funkční, tak i nefunkční testování. Tato úroveň slouží jako výstupní kontrola softwaru. Akceptační testování (Acceptance testing) Odpovídají testům systémovým, ale probíhají na straně zákazníka a na jeho infrastruktuře. Ten si s vlastním týmem testerů provede akceptační testy podle scénářů, na kterých se podílí zákazník i dodavatel. Nalezené chyby a neshody jsou reportovány zpět dodavatelovu vývojovému týmu k opravě. Cílem těchto testů je akceptace ze strany zákazníka a předání produktu k užívání.
35
Ostatní testy Kromě výše uvedených testů, které se váží k vývojovému cyklu, existují samozřejmě ještě další, některé zde budou jen stručně popsány [25]. Test splněním – vstupní data jsou vždy pro aplikaci akceptovatelná, kontroluje se shoda výstupu s očekáváním. Test nesplněním – vstupem jsou pouze nestandardní data, snaha o ukončení chodu programu, výstupní data neobsahují data z množiny očekávaných výstupních dat. Progresní testy - při kontrole nových funkcí nebo vlastností aplikace. K jejich správnému provedení je nutná dokumentace, která přesně popisuje nově implementované oblasti. Regresní testy - opětovném testování funkcí a vlastností aplikace po změnách. Ověření, že provedené změny či implementace nových vlastností v aplikaci nemělo žádný vliv na stávající funkce a vlastnosti. Smoke testy - v okamžiku, kdy je dokončen vývoj aplikace a lze ji spustit. Zaměřují se pouze na hlavní funkce programu, které nebývají příliš často upravovány. Jedná se o krátký test, který slouží jako rychlé ověření, zda je vyvíjená aplikace připravena pro další fázi testování.
4.6 Audit IS Cílem této části je seznámení s možnostmi ověření souladu funkčnosti dodaného informačního systému s požadavky zákazníka. K tomu slouží nástroj zvaný audit IS. Audit IS můžeme ho chápat jako nezávislou komplexní kontrolu IS. Abychom mohli informační systém prohlásit za kvalitní, je třeba ujištění o tom, že systém funguje v souladu s potřebami a standardy zákazníka, a že slouží účelně a účinně k dosažení definovaných cílů. Bohužel zatím v České republice není zakořeněné povědomí o specifikách a nezbytnostech auditu IS, zahrnující soulad všech potřebných aspektů auditu (ekonomický, informační, motivační, právní a procesní). Následkem toho může být rozpor mezi očekáváním auditu a jeho skutečným výsledkem a přínosem [7]. Podle Svaté [7] je audit informačního systému definován takto: Audit informačního systému je specifický proces, který se zabývá posuzováním a poradenstvím objektů v prostředí, kde se používají informační technologie. Jeho cílem je kvalitativně a/nebo 36
kvantitativně přispět ke správné organizaci informačního systému tak, aby byly splněny požadavky uživatelů, zákonů, smluv či jiných regulací (externích či interních). Objekty mohou být organizace a řízení IS, základní i aplikační software, technické vybavení, telekomunikační systémy, procesy tvorby a údržby systémů, ochrana a bezpečnost systému, data (databáze) apod. Základní vlastnosti auditu jsou: komplexnost – zachycuje všechny aspekty IS, objektivnost – opírá se o existující standardy a zkušenosti, nezávislost – vyloučení střetu zájmů auditora a zadavatele, formalizovanost – řídí se metodikou a existujícími standardy. Druhy auditu Hledisko úrovně aplikace auditu: technický audit – soulad mezi realitou a systémem řízení (existence kvalitních informací pro řízení), profesionální audit – soulad mezi výstupy ze systému řízení a společností (zda organizace plní svůj společenský účel v rámci daných standardů). Hledisko vykonavatele auditu: audit interní – prováděný zaměstnancem/oddělením organizace, audit externí – prováděný externím pracovníkem/oddělením. Hledisko věcného zaměření auditu: audit legálnosti programového vybavení, audit bezpečnosti, audit kontrolního systému, operační audit (efektivnost provozu, výkonnost), audit IS. Existuje mnoho dalších hledisek, podle kterých se dál rozdělují druhy auditů, např. hledisko metodologické, ekonomické, časové atd. Pro účely této práce není nutné se jimi detailněji zajímat.
37
Obsah auditu 1.
etapa hodnocení výsledků zpracování na počítačích (vstupy, zpracování, výstupy IS),
2.
etapa hodnocení rizika a kontrol počítačového zpracování (spolehlivost a průkaznost transakcí),
3.
etapa hodnocení a optimalizace procesů IT i navazujících procesů (hodnocení metrik, přínos IT/IS pro business procesy atd.)
Standardy Auditu Mezinárodní standardy pro audity IS jsou vydávány profesními organizacemi auditorů. Mezi nejdůležitější patří organizace ISACA (Information System Audit and Control Association) a INTOSAI (International Organisation of Supreme Audit Institutions). Mezinárodní profesní asociace ISACA, která je zaměřená na oblast auditu řízení, kontroly a bezpečnosti informačních systémů a to jak pro interní tak pro externí auditory. V České republice působí od roku 1997 a v současné době sdružuje přes 260 odborníků z různých podnikatelských oblastí a státní správy. ISACA zastřešuje program mezinárodně uznávaných certifikací CISA (Certified Information Systems Auditor), CISM (Certified Information Security Manager), CRISC (Certified in Risk and Information Systems Control) a CGEIT (IT Governance Certification), organizuje mezinárodní konference a odborné semináře zaměřené na technická i manažerská témata, vytváří celosvětově platné standardy pro audit a řízení informačních technologií. Z důvodu velkého nárůstu informačních technologií v posledním desetiletí a kritickému zvýšení jejich vlivu na úspěch v podnikání vznikl ve spolupráci s ISACA v roce 1998 IT Governance Institute. Posláním institutu je pomáhat manažerům nalézat rovnováhu mezi řízením IT a řízením podnikatelských cílů. ISACA spolu s IT Governance Institute jsou lídry v oblasti řízení kontroly informačních technologií [23]. INTOSAI sdružuje organizace provádějící externí audity vládních organizací tzv. SAI (Supreme Audit Institutions), u nás je to NKÚ 8. V rámci EU pak funguje jedna ze sedmi regionálních organizací INTOSAI - EUROSAI (Evropská organizace nejvyšších auditních institucí
-
European
Organization
of
Supreme
Audit
Institutions).
Jejím cílem je podpora členských organizací, tvorba odborné auditorské terminologii,
8
NKÚ – nejvyšší kontrolní úřad (http://www.nku.cz/cz/mezinarodni/mezinarodni-vztahy.htm)
38
pořádání kurzů a seminářů a udržování vztahů s institucemi, které se zabývají auditem. Tyto organizace mohou provádět audit finanční, výkonnostní a audit souladu se standardy. Mají rozvětvenou organizační strukturu rozdělenou na pracovní skupiny. Jednou z pracovních skupin EUROSAI je pracovní skupina IT. Cílem této skupiny je usnadnit sdílení znalostí a zkušeností mezi nejvyššími kontrolními institucemi a podporovat provádění společných činností v oblasti informačních technologií.
39
5 Podnikový informační systém Jelikož je tato práce zaměřena hlavně na oblast kvality implementace podnikových informačních systémů typu TASW je potřeba specifikovat a definovat také podnikové informační systémy. Komplexní podnikový informační systém nepředstavuje jen samotné programové vybavení a informační a komunikační technologie. Informační systémy se v podniku nevyskytují pouze v souvislostech s ICT, v širším pojetí mohou být vnímány s ohledem na míru formalizace údajů, podíl lidského faktoru nebo s ohledem na druh „nosičů“ informací [1]. Podnikový informační systém je široký komplex lidí, informací, systému řízení, technických prostředků a systému organizace práce uživatelů v příslušné oblasti. Jeho hlavním úkolem je sběr, přenos, aktualizace, uchování a další zpracování dat. Ty pak mohou být následně využity k práci, prezentaci nebo rozhodování za účelem zlepšení efektivnosti podniku. Účelem IS je zajištění správných informací na správném místě ve správný čas. Realizace takového celku je velice náročná a vyžaduje spolupráci celého týmu lidí zahrnující, analytiky, manažery, zaměstnance a programátory. Na vývoji se podílí buď specializovaná firma, vlastní programátoři firmy nebo uvedené celky spolupracují [18].
5.1.1 Podnikové informační systémy z pohledu funkcí Pro podnikové informační systémy se často nepřesně používá označení ERP systémy. ERP systém (Enterprise Resource Planning – plánování podnikových zdrojů) v původním smyslu označuje jádro současného podnikového informačního systému, které spolu s aplikacemi typu SCM, CRM a BI (vysvětleno níže) tvoří komplexní integrovaný informační systém, tzv. rozšířené ERP, označované také jako ERP II. Na vzniku rozšířeného ERP (Extended Resource Planning) nebo také ERP II má hlavní podíl internet, který umožnil vnější integraci podniku směrem k zákazníkům, dodavatelům a partnerům. Zdrojem pro zpracování této kapitoly je publikace Podnikové informační systémy [1]. Níže jsou popsány pouze hlavní kategorie podnikových aplikací. Existuje samozřejmě velké množství dalších, které jsou podle potřeb podniku integrovány do IS. 40
ERP (Enterprise Resource Planning- plánování podnikových zdrojů) ERP integruje v podniku 2 hlavní funkční oblasti a to finance (finanční, nákladové a investiční účetnictví, podnikový controlling) a logistiku (plánování zdrojů, nákup, skladování, výroba, prodej). ERP zahrnuje tyto hlavní činnosti:
správa kmenových dat – položky, kusovníky, číselníky, sklady, dodavatelé, zákazníci atd.,
dlouhodobé, střednědobé i krátkodobé plánování zdrojů potřebných pro realizaci zakázek,
plánování a sledování nákladů realizace, zejména výroby,
zpracování výsledků všech aktivit do finančního účetnictví a controllingu.
SCM (Supply Chain Management – řízení dodavatelských řetězců) Hlavní význam řízení dodavatelských řetězců je optimalizace řízení a maximální efektivita provozu celého dodavatelského řetězce (dodavatel → výrobce → distributor → prodejce → zákazník) na bázi vzájemného propojení dodavatelů s odběrateli prostřednictvím informačních a komunikačních technologií. CRM (Customer Relationship Management – řízení vztahu se zákazníkem) CRM je databázovou technologií podporovaný proces shromažďování, zpracování a využití informací o zákaznících firmy. Umožňuje tak poznat, pochopit a předvídat potřeby, přání a nákupní zvyklosti zákazníků a podporuje oboustrannou komunikaci mezi firmou a jejími zákazníky. CRM umožňuje i aktivní komunikaci s dodavateli, jejich hodnocení a porovnávání [20]. CRM však není jen programovým vybavením, řízení vztahů se zákazníky je hlavně strategie, která se orientuje na vybudování a podporu dlouhotrvajících vztahů se zákazníky, která vyžaduje změnu filosofie společnosti tak, aby důraz byl kladen na zákazníka. Role informačních technologií pak spočívá v podpoře a automatizaci celého CRM procesu. Operativní CRM - Podpora procesů pro front office (jednání s klienty, prezentaci společnosti a jejích služeb, příprava smluv, vyřizování telefonických hovorů, kontrola obchodů). Analytické CRM – analýza dostupných dat za účelem dosažení určených cílů. 41
BI (Business Inteligence) BI je výraz pro procesy, znalosti, aplikace, platformy, nástroje a technologie, které podporují porozumění datům, jejich vztahům a trendům. Softwarové aplikace typu BI umožňují zpracování veškerých dat uložených v podnikových informačních systémech za účelem podporování rozhodování ve společnosti. Nabízejí agregovaná data v různé míře detailu formou přehledných tabulek a grafů, které zachycují trendy či korelace různých jevů. Jejich hlavním přínosem je zlepšení kvality a výkonnosti podnikového řízení a zvýšení konkurenceschopnosti podniku.
5.1.2 Informační systémy z pohledu úrovně řízení organizace Informační systémy mají za úkol podporovat činnosti organizace a její řízení. Jako nejrozšířenější model struktury IS je používána informační pyramida, která rozděluje a popisuje jednotlivé úrovně IS dle informačních potřeb jednotlivých úrovní organizace (obr.1). Informační systémy dle úrovní řízení organizace [10]: TPS – transaction processing systems (úroveň operativního řízení) - aplikace určené pro podporu provozu organizace na operativní úrovni. Jejich skladba je závislá na charakteru podniku (výrobní podnik, podnik poskytující služby atd.). MIS – management information systems (úroveň taktického řízení) - aplikace orientované na řízení podniku na operačně taktické úrovni zejména v ekonomických, finančních a obchodních oblastech. EIS – executive information systems (úroveň strategického řízení) - systémy, které zpracovávají informace pro potřeby strategického rozhodování prováděného vrcholovým managementem společností. OIS - Office Information System - aplikace pro podporu kancelářské agendy. EDI - Electronic Data Interchange - aplikace pro elektronickou komunikaci s okolím podniku – dodavateli, odběrateli, zákazníky, bankami či státními institucemi.
42
Obr. 1: Model struktury IS, zdroj: [10]
5.1.3 Požadavky na informační systém Abychom mohli IS označit jako kvalitní, musí splňovat základní parametry, které jsou definovány v požadavcích na jeho vlastnosti. Pokrytí požadované funkcionality Pokrytí požadované funkcionality považuje autor za jednu z nejdůležitějších vlastností. Již zde se v mnohých případech naráží na nemalé problémy. Je totiž třeba tuto požadovanou funkcionalitu správně definovat. V ideálním případě by tvůrci IS dostali detailně analyzované a zpracované požadavky na funkcionalitu IS, ale realita bývá většinou úplně odlišná. Málokdy je zákazník schopen tyto požadavky předložit. Jeho představa je taková, že za vynaložené finance dostane plně funkční řešení, které mu usnadní jeho podnikání. Jenže každé řešení je stejně jako každý zákazník specifické a proto si žádá individuální přístup. To platí i pro většinu TASW, který je pak nutno na míru přizpůsobit 43
jednotlivým zákazníkům. Proto vzniká potřeba důkladné analýzy podnikových procesů, diskuzí s koncovými uživateli a prostudování firemních dokumentů (směrnic, norem, organizačních řádů, procesních map atd.) a na jejím základě je třeba požadavky definovat. I to je bohužel ve většině případů ideální stav a ne realita. Zkušenosti autora jsou takové, že firmy mají málokdy kvalitně popsané podnikové procesy, pokud je vůbec popsané mají, uživatelé mají potíže detailně popsat své informační potřeby a výsledkem toho bývá, že se požaduje funkcionalita nadbytečná, chybná nebo neúplná. Tato fáze je pro dodávku kvalitně zpracovaného IS klíčová a je třeba jí věnovat dostatek času a úsilí. Integrita IS Důležitou vlastností je integrita IS. Zjednodušeně si pod tímto termínem můžeme představit provázanost celého systému, jednotlivých agend a poskytovaných informací. Zahrnuje několik úrovní požadavků na IS z pohledu integrity, a to: technologickou integrita – sladění z pohledu technologické platformy, využití dat napříč systémem, sdílení funkcionalit mezi aplikacemi, integritu interních podnikových procesů a funkcí IS – funkcionalita IS odpovídající požadavkům podnikových procesů, integrace podniku s okolím – komunikace mezi IS v dodavatelském řetězci (objednávky, faktury a další firemní doklady), integrace vizí a priorit mezi vrcholovým managementem a řešiteli IS – dosažení shody na prioritních úkolech v rámci změn IS a vymezení potřebného času k jejich dosažení, integrace metodik a nástrojů pro rozvoj a provoz IS – sjednocení metodik a nástrojů ke zjednodušení komunikace mezi řešiteli a uživateli IS [9]. Bezpečnost Zde je třeba zabezpečit jak bezproblémový chod IS a jeho aplikací, tak zajistit patřičnou ochranu dat, zejména proti neoprávněnému přístupu, zcizení nebo ztrátě dat. V praxi to znamená, že musí být dobře analyzován, navržen a realizován koncept přístupových práv k jednotlivým funkcionalitám systému a datům prostřednictvím pracovních rolí. Kromě toho je však také třeba data zabezpečit fyzicky v rámci datového centra, logicky pomocí propracovaného systému záloh a logování transakcí a v neposlední řadě je třeba hardwarové a softwarové ochrany proti útokům z internetu [2].
44
Flexibilita IS Kvalitní IS z pohledu zákazníka musí být také flexibilní. Jeho okolí se neustále vyvíjí a s ním i požadavky na funkcionalitu IS. Těm by měl být IS snadno, rychle a pokud možno levně přizpůsobitelný. Ideální stav je, pokud je toto zákazník (jeho IT tým) schopný řešit vlastními silami změnou parametrizace aplikací a není nutný zásah do kódu aplikace. Do této části bych zařadil i další často požadovanou vlastnost a tou je otevřenost systému, pod kterou si představujeme možnost komunikace s aplikacemi třetí strany [2]. Výkonnost a efektivnost IS Jedním z posledních klíčových nároků na IS je, aby byl dostatečně výkonný a efektivní. Tato vlastnost se posuzuje podle toho, jak IS přispívá k výkonnosti celého podniku. Hlediska mohou být např. zvýšení obratu podniku, počtu zákazníků, zrychlení výrobních procesů, vyřízení objednávek atd. V tomto ohledu je vždy nutné vyvážit přínosy IS oproti nákladům, které se hodnotí pomocí předem definovaných metrik a ne vždy je snadné přímý přínos IS správně vyhodnotit [2]. Další důležité vlastnosti Z ostatních podstatných vlastností, které by měl informační systém splňovat, autor považuje za nutné zmínit uživatelskou přívětivost, správnost prezentovaných informací, jejich včasnost a důvěryhodnost. Měla by existovat možnost ověření správnosti informací, a pokud tomu tak není, měli by o tom být uživatelé informováni. Systém by měl uživateli umožňovat plynulou práci, tudíž by měla být definována požadovaná doba odezvy u vybraných důležitých transakcí. Funkcionalita systému musí být vždy v souladu s legislativou státu, ve kterém je používán a musí i reagovat na její změny.
5.2 Možnosti pořízení a implementace softwaru (IS) v podnikovém prostředí Při pořizování nového IS do podniku bude jedním z prvních rozhodnutí pro jeho management, zda jít cestou vlastního vývoje a vytvořit IS na míru podle potřeb podniku (IASW – individuální aplikační software) nebo zvolit variantu pořízení (typového aplikačního softwaru) a ten upravit dle požadavků podniku [2]. 45
5.2.1 IASW - individuální aplikační software Pokud padne rozhodnutí vydat se cestou individuálního aplikačního software a pokud se podaří kvalitně realizovat projekt, dá se očekávat, že aplikace bude optimálně podporovat podnikové procesy. Předpokladem samozřejmě je, že zadavatel bude mít jasné představy a bude kladen velký důraz na analýzu potřeb a procesů. Nejčastější důvody pro vlastní vývoj jsou [2]: specifičnost oblasti (neexistuje vhodný TASW), nevhodnost dostupných TASW (zastaralost, lokalizace), aplikace je pro organizaci strategickou (odlišení od konkurence, knowhow). Možnosti pořízení IASW: Vlastní vývoj IS Výhodou vlastního vývoje je, že takto vyvinutá aplikace by měla maximálně odpovídat požadavkům zákazníka, je přizpůsobena podnikovým procesům a nabízí očekávanou funkčnost. Celá aplikace je vývojářům detailně známa, a tudíž jsou schopni rychle reagovat na potřeby uživatelů. Nevýhodou pak v tomto případě bývají vysoké náklady, delší doba vývoje, možné problémy s kvalitou způsobené nedostatečnou zkušeností interních programátorů nebo změnami požadavků v průběhu projektu. IASW je plně závislý na svých tvůrcích a pokud neexistuje kvalitní dokumentace, vzniká riziko obtížné údržby, vývoje a správy při fluktuaci zaměstnanců. Vývoj IS externí firmou Při vývoji externí firmou zůstávají stejné výhody jako při vlastním vývoji, navíc odpadá problém s kvalifikací interních programátorů a těsnou závislostí IASW na tvůrcích. Pro budování IS se s nejvyšší pravděpodobností využijí standardy a metodiky a celý vývoj probíhá rychleji. Nevýhodou však jsou ještě vyšší náklady než u vlastního vývoje, potřeba sdílení informací s externí firmou a možnost vzniku komunikačních bariér mezi zúčastněnými. Implementace IASW v podnikovém prostředí Cílem je vývoj, testování a nasazení nové aplikace na základě vstupní analýzy a návrhu systému, příprava produktu pro akceptační řízení a zavedení do provozu a tvorba 46
uživatelské, projektové a provozní dokumentace. K tomu slouží metodiky vývoje softwaru (více v kapitole 4.4).
5.2.2 TASW typový aplikační software V případě TASW je aplikace vytvořena a rozvíjena týmem programátorů specializovaného výrobce softwaru. Je vytvářena na základě generalizace požadavků pro určitý segment podniků (hotely, banky, výrobní podniky). Náklady na vývoj bývají podstatně vyšší než u IASW, ale jejich rozpuštěním mezi více zákazníků je výsledná cena licence obvykle nižší než IASW. Doba potřebná na implementaci TASW je kratší, instaluje se již hotový software a je jen třeba ho pro každého zákazníka [2]: lokalizovat - upravit podle platné legislativy v daném státě, parametrizovat - úprava dle specifických potřeb zákazníka, integrovat - propojit s ostatními komponentami IS podniku. Oproti IASW, který je vyvíjen tak, aby přímo podporoval podnikové procesy, vzniká u TASW potřeba podnikové procesy přizpůsobit možnostem aplikace. V konečném důsledku to může být považováno za výhodu, protože výrobci TASW využívají při tvorbě aplikací „best practises“ v daném oboru, čímž mohou méně vyspělé podniky přebírat zkušenosti a praktiky od lídrů oboru. Možnosti pořízení TASW Nákup všech komponent (včetně TASW) od různých výrobců, integrace vlastními silami V tomto případě platí vše uvedené výše, jen hrozí obtížnější integrace jednotlivých komponent kvůli riziku nekonzistentnosti systémů. Nákup celého IS/IT (TASW) od generálního dodavatele – systémového integrátora Výhodami tohoto řešení je rychlost realizace, profesionální řešení komponent jejich integrace. Naopak problematické může být riziko úniku informací a vznik závislosti na systémovém integrátorovi. Tvorba IS (TASW) generálním dodavatelem – systémovým integrátorem a outsourcing provozu IS/IT
47
Kromě výše uvedených výhod u nákupu od systémového integrátora navíc dochází ke snížení provozních nákladů (za personál a infrastrukturu) a možnost využití nejmodernějších technologií. Problémem může být, že kromě shodných rizik s předchozí variantou, je závislost na dodavateli je ještě větší. Implementace TASW v podnikovém prostředí Pro budování podnikových IS s využitím TASW vznikla potřeba nových nebo modifikovaných implementačních metodik. Ty jsou většinou úzce spojeny s konkrétním TASW a bývají součástí jeho dodávky. Jejich hlavním úkolem je identifikace potřeb organizace a jejich naplnění s minimálními programovými úpravami. Tím často vzniká potřeba přizpůsobit podnikové procesy možnostem aplikace, jak již bylo výše zmíněno v kapitole. Další důležitou oblastí, která je pomocí metodik řešena, je konfigurace a parametrizace TASW dle potřeb organizace a poslední klíčovou oblastí je řízení samotné implementace. [2] Vývojové fáze softwarového produktu (TASW) Hlavními kritérii při výběru TASW pro podnikový IS jsou především funkcionalita, podpora podnikových procesů, podpora ze strany dodavatele, celková cena (licence, implementace, podpora, provoz) a kvalita produktu.
Právě kvalita a s ní zároveň rizika
spojená s instalací TASW jsou významně ovlivněna tím, v jaké vývojové fázi se produkt nachází [2]. Fáze vývoje produktu (Graf č.3): Fáze zahájení – pro výrobce TASW spojena se značnými investicemi do vývoje, marketingu a prvních instalací. Výběr takového produktu je pro podnik velmi rizikové (nejistota udržení produktu na trhu a budoucí podpory). Může však také znamenat náskok před konkurencí. Fáze růstu – další rozvoj TASW (funkce, provozní platformy, služby), roste počet instalací, produkt začíná generovat zisk pro výrobce. Rizikový faktor této fáze je nezvládnutí růstu výrobcem (počet pracovníků, poboček, distribuce atd.) a z toho plynoucí nízká úroveň služeb. Pro koncového zákazníka je však tato fáze daleko méně riziková než fáze předchozí a nákup stále může znamenat náskok před konkurencí. Fáze dospělosti – výrobce se soustřeďuje zejména na údržbu produktu. Počet instalací produktu začíná stagnovat. Rizika při nákupu jsou minimální, ale nelze očekávat zisk 48
konkurenční výhody. Největším rizikem této fáze je, že produkt brzy přejde do fáze ústupu. Fáze ústupu – konkurenční produkty nabízejí lepší funkce a využívají modernějších technilogií. Dochází k poklesu instalací u zákazníků. Investice do produktu v této části je problematická. Do této fáze se produkt může dostat, aniž by prošel fází dospělosti resp. růstu.
Graf 3. Obecné fáze vývoje softwarového produktu (TASW) Zdroj [2]
49
6 Řízení projektu IS/ICT Cílem této kapitoly je přiblížení problematiky projektového řízení a zdůraznění jeho důležitosti nejen pro úspěšnou implementaci TASW, ale obecně pro všechny IT projekty. Zdrojem informací pro tuto kapitolu je odborná literatura a zkušenosti autora při účastech na IT projektech ve společnosti Lázně Františkovy Lázně a.s.
6.1 Projekt V této části je charakterizován projekt, jeho kritéria a jeho životní cyklus.
6.1.1 Definice projektu Obecná definice projektu Pitra [5] definuje projekt takto: Projekt je koordinované úsilí skupiny lidí, které směřuje k vytvoření něčeho nového, dosud neexistujícího - ve stanoveném termínu a s přidělenými prostředky. Management jakéhokoliv projektu tedy spočívá v plánování postupu projekčního řešení, organizačním zabezpečení projektu, vybudování a vedení projektového týmu a v neposlední řadě v kontrole a řízení postupu řešení projektu (včetně průběžného i finálního hodnocení projektu). Dle normy ISO 100069 je projekt definován takto: Projekt je 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.
9
ISO 10006 (směrnice ČSN/ISO 10006 pro management jakosti projektů) je součástí rodiny mezinárodních standardů vydávaných Mezinárodní organizací pro standardizaci (International Organization for Standardization). ISO 10006 je označení standardu pro systém managementu projektů.
50
6.1.2 Trojimperativ projektu Každý projekt je definován tzv. Projektovým trojimperativem, který se skládá ze tří základních podmínek [3]. Těmi jsou:
kvalita výstupu (co a v jaké kvalitě má být realizováno = cíle),
čas (harmonogram projektu),
náklady (na realizaci jednotlivých činností na projektu).
Pokud se podaří splnit všechny současně, lze projekt považovat za úspěšný.
Graf č.4: Trojimperativ projektu Zdroj: ihned.cz10 (převzato, upraveno)
Jak je vidět v grafu č.4, jsou tyto faktory velmi úzce propojené a vzájemně se ovlivňují. Proto je z hlediska úspěšnosti projektu důležité jejich optimální a reálné naplánování již v počátku projektu. Pro plánování a hodnocení kvality projektových výstupů (cílů) existuje metoda zvaná SMART11, podle níž cíle projektu musí být Specific – specifikované, Measurable – měřitelné,
10
11
http://ihned.cz/c1-21113300-faktory-uspechu-projektu-uchazejicich-se-o-dotaci-z-fondu-eu-co-ukazala-leta2004-2006 Doran, George T. "There's a S.M.A.R.T." Management Review, Nov 1981, Volume 70 Issue 11
51
Aligned – akceptovatelné, Realistic – realizovatelné, Timed – termínované, tzn. časově vymezené
Obr. č.2: Metoda SMART Zdroj: SovaNET12
6.1.3 Životní cyklus projektu Projektových cílů se dosahuje v rámci životního cyklu projektu, který se skládá z projektových fází, jejichž postupná realizace vede k úspěšnému projektu. Pro účely této práce není nezbytný detailní popis projektových procesů jednotlivých fází. Ten je dostupný např. v publikaci DVOŘÁK - Řízení projektů: nejlepší praktiky s ukázkami v Microsoft Office [3]. Fáze I – iniciace projektu Jejím cílem je prověřit, zda je záměr projektu smysluplný a proveditelný. Výstupy této fáze jsou popsaný a schválený záměr projektu a definice rozsahu projektu v podobě logického rámce nebo jiného dokumentu. Fáze II – Plánování projektu Vstupem pro tuto fázi jsou výstupy fáze předešlé. Výstupem je projektový plán, který zohledňuje všechny dimenze projektového cíle: výstupy – v plánu jako seznam aktivit vedoucí k jejich dosažení, čas – v podobě trvání jednotlivých aktivit a jejich vzájemných závislostí, 12
https://www.sovanet.cz/definuj-cil-pochop-zpusob-dosazeni/
52
náklady – ocenění práce a ostatních zdrojů. Fáze III – Sledování projektu V této části je sledováno plnění úkolů ve specifikované kvalitě, času a nákladech. Slouží také k získání a udržení si přehledu o chodu projektu. Fáze IV – Řízení projektu Cílem této fáze je projekt řídit a zvláště pak uřídit. Projektové plány se často od reality liší a pak je třeba řešit jak se zachovat při odchýlení od původního plánu. Fáze V – Ukončení projektu S formálním ukončením projektu je spojeno množství úkolů, které jsou však často zanedbávány a podceňovány. Cílem ukončení projektu je eliminace vzniku nových požadavků na projektový tým a vyhodnocení celého projektu, což přispívá ke zvýšení kvalitativní úrovně řízení budoucích projektů.
6.1.4 Předpoklady úspěchu projektu O úspěchu projektů IS nerozhoduje pouze kvalita vlastního systému a jeho implementátora, ale také podmínky vytvořené na straně zákazníka. Z tohoto důvodu je třeba zajistit níže uvedené [21]:
Plánovací a řídící činnosti jsou provázané - Každá činnost je před svým startem naplánována a odsouhlasena. Jsou připraveny podmínky pro její vykonávání (včetně zdrojů) a její průběh je sledován. Odchylky mezi plánovaným a skutečným průběhem vyvolávají řídící akce. Problémy jsou identifikovány v dostatečném předstihu.
Dosahování projektových dodávek, cílů a očekávání je plánováno a sledováno výstupy projektu jsou předem definované, se stanoveným měřitelným akceptačním procesem. Organizace, útvary i jednotliví pracovníci, zahrnutí do projektu, spolupracují na dosažení cílů a výstupů projektu. Projekt je průběžné monitorován, vyhodnocován a průběh je upravován. Průběh projektu je personálně nezávislý.
53
Získané znalosti o plánování a řízení projektů se vícenásobně využívají - pro odhady v dalších projektech aj.
6.2 Specifika projektů IS/ICT Projekty IS jsou specifické tím, že mimo hmotné stránky (hardware) mají i podstatnou část nehmotnou (software, parametrizace, změna způsobu práce, atd.). Pro úspěch projektu IS nestačí jeho dokončení podle plánu. Je třeba zajistit jeho následné správné využívání, které je úzce svázáno s kvalitním proškolením uživatelů, jejich motivováním ke změně pravidel a chování. Při většině implementací podnikových IS dochází ke změnám podnikových procesů, způsobů komunikace a vzniká potřeba do těchto změn aktivně zapojit zaměstnance [1]. Předpoklady úspěchu projektu IS/ICT jsou zmíněny v kapitole 3.1. Další specifika projektů IS/ICT: jsou ovlivněny předchozími zkušenostmi (konzultantů, uživatelů), jsou vysoce proměnlivé, vyžadují sdílení podnikových zdrojů, probíhají současně s dalšími projekty v podniku (např. certifikace ISO, inovace procesů, inovace produktů, výrobních technologií, zlepšování procesů, fúze podniků apod.), zasahují do strategie podniku či celých aliancí, přinášejí do podniku výrazný inovační potenciál s velmi krátkým inovačním cyklem změn, postihují celou organizaci podniku, formují nové výrobky a služby, nové kanály pro řízení vztahu se zákazníky či dodavateli.
6.2.1 Řízení projektů IS/ICT Řízení projektu IS/ICT zahrnuje plánování, organizování a vedení činností a zdrojů za účelem dosažení definovaných cílů. Nejčastěji se potýká s časovými a finančními omezeními a s omezením zdrojů. Mezi hlavní činnosti řízení projektů patří [13]: plánování, 54
organizování, delegování a motivování, řízení času, zdrojů, financí a nákladů, komunikace, kvality, řízení změn, rizik a rezerv, hodnocení a kontrolování. Oddělení řídícího a věcného přístupu projektů IS/ICT Při řízení projektu IS/ICT je nutné odlišit základní skupiny procesů v řízení projektů IS/ICT od procesů životního cyklu informačního systému (softwarového produktu, aplikace, služby) jako výstupu projektu. Při řízení projektu IS/ICT jde hlavně o řídící dimenzi související s projektem [13]. Řídící postup projektu odpovídá např. životnímu cyklu projektu (více v kapitole 6.1.3). Věcný postup projektu IS/ICT např. životnímu cyklu aplikace podle MMDIS (více v kapitole 7.2.3) Oblast řízení projektů je vymezena ještě celou řadou dalších charakteristik. Kromě metodické výbavy a příslušné podpory technikami a nástroji jsou klíčovými faktory úspěchu projektu znalosti a zkušenosti členů projektových týmů.
55
7 Metodika MMDIS Cílem této kapitoly je rámcové seznámení s metodikou MMDIS k níž se váže hlavní cíl práce, kterým je rozšíření její dimenze kvality při implementaci TASW v podnikovém prostředí. Pro účely této práce bude jen stručně charakterizována. Její detailní obsah je k dispozici v publikacích profesora Jiřího Voříška a jeho spolupracovníků z katedry informačních technologií VŠE v Praze [9], [2], [28].
7.1 Popis metodiky MMDIS Metodika MMDIS (Multidimensional Management and Development of Information System) je vyvíjena od počátku 90. let minulého století na katedře informačních technologií VŠE. Zaměřuje se na řízení vývoje a provozu IS. Původně se jmenovala MDIS (Multidimensional Development of Information System) a zaměřovala se na vývoj integrovaného IS podniku [10]. Později byla rozšířena na metodiku pokrývající komplexní řízení výkonu IS/ICT v organizaci [9]. Je to metodika otevřená a vyvíjí se spolu s hospodářským prostředím, informačními technologiemi a metodami řízení. Nejedná se o metodiku rigorózní, tudíž nepředepisuje detailně jednotlivé kroky při řízení IS/ICT, ale je hlavně návodem jak uvažovat při řízení vývoje a provozu IS/ICT. Je založena na principu unikátnosti každého projektu což vylučuje univerzální detailní návod postupu v jednotlivých krocích projektu. Klade důraz na to, co by se mělo řešit v jednotlivých fázích vývoje a provozu IS/ICT a o čem přemýšlet. Detailní pracovní kroky nechává na samotných řešitelích. Z obsahového hlediska se MMDIS zaměřuje na oblast vývoje, údržby a provozu komplexního integrovaného IS podniku, který optimálně využívá potenciálu dostupných informačních technologií a informatických služeb k maximální podpoře podnikových zdrojů [2]. Základní principy MMDIS jsou[2]: Princip multidimenzionality: Dle metodiky MMDIS je základním předpokladem efektivity jak při vývoji, tak při provozu IS/ICT mnohost pohledů (dimenzí) na danou problematiku 56
(více v kapitole 7.2). Problém je třeba analyzovat, hodnotit a řešit z různých úhlů pohledu. Pohledy jsou určeny stranami zainteresovanými na systému. Každé separátní řešení problému je pak nutné integrovat do výsledného řešení. Princip integrace: Řízení vazeb mezi komponentami systému při jeho provozu a vývoji. Princip vrstevnosti: Dekompozice řešení složitého problému do několika úrovní abstrakce, které se řeší odděleně. Každá nižší vrstva řeší problém na větší úrovni podrobnosti. Princip flexibility: Schopnost systému přizpůsobit se snadno a rychle vývoji okolí a změnám požadavků na systém. Princip otevřenosti: Otevřenost systému při vyjímání starých a vkládání nových komponent. Princip standardizace: Využití standardů pro zlevnění řešení. Pro některá řešení jsou standardy závazné (zákony, směrnice, normy). Princip kooperace: Hledání klíčových kompetencí, pro postavení podnikatelského záměru. Ostatní lze většinou získat levněji od obchodních partnerů. Cíle: rychlá reakce, škálovatelnost, kvalita. Princip procesního přístupu: Pro zachycení reakce systému na události je lepší procesní popis než funkčně organizační. Princip učení a růstu: systematické zlepšování procesů a řízení firmy založeno na akumulaci znalostí a nejlepších postupů. Princip lokalizace zdrojů a rozhodnutí: Centralizované nebo decentralizované řešení z pohledu nákladů, rychlosti reakce, rizika. U ICT převažuje centralizace, u rozhodování není trend jasný. Princip měřitelnosti: Řízení ICT služeb, procesů a zdrojů se musí opřít o systém definovaných metrik. Konceptuální modely MMDIS: Konceptuální modely daného systému objasňují jak chápat řízený systém a doporučuje metody pro jeho řízení. Základními konceptuální modely metodiky MMDIS jsou [2]: model řízení podniku založený na procesním řízení, model řízení vztahu mezi byznysem a podnikovou informatikou (SPSPR), model tvorby dalšího rozvoje IS/ICT podniku, 57
model integrace IS/ICT do podniku, referenční model řízení podnikové informatiky, model tvorby informační strategie.
7.2 Dimenze MMDIS Jak je výše uvedeno metodika MMDIS je založena na principu multidimenzionality. Všechny dimenze jsou v různé míře použity v každé fázi vývoje IS/ICT. Obrázek č.3 znázorňuje tři skupiny pohledů na metodiku MMDIS [28]: uživatelský a řešitelský, úroveň abstrakce a časová dimenze, obsahové dimenze IS/ICT. Pohledy na tvorbu IS/ICT reprezentují uživatelská nebo řešitelská hlediska. Při tvorbě řešení IS/ICT je nutné vycházet z uživatelských pohledů (požadavků byznysu) a ty transformovat do pohledů řešitelských. Ty slouží k realizaci uživatelských požadavků na IS a zároveň je prověřují z hlediska reálnosti a konzistence.
Obr. č.3: Princip multidimenzionality a dimenze řešení metodiky MMDIS Zdroj: Studijní materiály VŠE [28] 58
7.2.1 Uživatelské pohledy na IS/ICT Uživatelské pohledy reprezentují požadavky různých typů uživatelů IS na jeho vlastnosti. V tabulce č.3 jsou uvedeny uživatelské pohledy a jejich cíle dle typických uživatelů IS. V různých ICT projektech může vzniknout potřeba analyzovat i další skupiny uživatelů, jako např. obchodní partnery, zákazníky, veřejnost [2]. Úroveň řízení
Vrcholový management
Střední management
Zaměstnanci jednotl. oddělení
Pohled
Strategický
Procesní
Funkční
Cíl
Stanovení podnikových cílů a zajištění zdrojů pro jejich dosažení
Optimální podnikové procesy a správný průběh procesů
Efektivita jednotlivých činností/funkcí
Cíle z hlediska IS
IS podporuje dosažení podnikových cílů s přijatelnými náklady
IS podporuje podnikové procesy s přijatelnými náklady
IS usnadňuje vykonávání jednotlivých činností
Metriky
Jak směřujeme ke stanoveným cílům? Kolik stojí IS?…
Výkonnost procesů, kvalita výstupů, využití zdrojů, náklady na proces
Počet činností za den, kvalita výstupu činnosti,…
Tab.č.3: Uživatelské pohledy a jejich cíle dle typických uživatelů IS Zdroj: Studijní materiály VŠE [28]
7.2.2 Řešitelské pohledy Řešitelské pohledy transformují uživatelské pohledy (funkce, data, atd. definované na konceptuální úrovni) do logického návrhu IS/ICT a následně do fyzického. Postup transformace požadavků se liší v závislosti na tom, zda je použit IASW nebo TASW [2]. Dimenze čas, úroveň abstrakce a úroveň integrace Časová dimenze řešení, úroveň abstrakce při řešení tvorby IS/ICT a úroveň integrace jsou znázorněny na obrázku č.4.
59
Obr.č. 4: Fáze tvorby IS podniku Zdroj: Studijní materiály VŠE [28] Obsahové dimenze Obsahové dimenze reprezentují řešitelské pohledy na obsah řešené části IS. Patří mezi ně [2]: Funkce/procesy (pro) - dimenze zaměřená na podnikové procesy a jejich podporu IS/ICT Data/informace (inf) – dimenze zaměřená na typy informací potřebných při jednotlivých podnikových aktivitách, dále obsahem a strukturou datové základny podniku a jejím fyzickým uložením Organizační a legislativní aspekty (org) – dimenze určující zákony, normy a směrnice, které musí být respektovány při tvorbě IS/ICT. Personální, sociální a etické aspekty (pra) – dimenze zjišťující strukturu zaměstnanců, jejich znalosti, schopnosti a omezení směrem k používání IS/ICT. Aplikační software (asw) – dimenze určující aplikační architekturu IS– typů a vazeb jednotlivých komponent aplikačního programového vybavení Technologická infrastruktura (ti) – dimenze určující komponenty a parametry technologické infrastruktury, na které budou provozovány aplikace IS podniku Uživatelské rozhraní (ur) - dimenze určující komunikační kanály, jejichž prostřednictvím bude uživatel využívat funkcionalitu aplikací
60
Bezpečnost a kvalita (bk) – dimenze zajišťující bezpečnost a další kvalitativní charakteristiky aplikace Ekonomické aspekty (eko) – dimenze pro sledování finančních nákladů tvorby a provozu IS a jeho přínosu Metodicko-organizační dimenze Metodicko-organizační dimenze jsou zaměřeny na metody a nástroje využívané při vývoji a provozu IS. Patří mezi ně [2]: Metody (met) – dimenze určující metody, techniky a nástroje používané v jednotlivých fázích vývoje IS/ICT. Dokumentace (dok) – dimenze určuje dokumenty (jejich obsah a návaznost) vznikající v průběhu vývoje a provozu IS/ICT Řízení prací dané fáze (mng) – dimenze řídící, určuje postup při řešení jednotlivých fází vývoje IS/ICT a dále pravidla a organizaci tvorby a provozu IS/ICT.
7.2.3 Životní cyklus aplikace podle MMDIS Změny IS, odehrávající se podle informační strategie se realizují prostřednictvím projektů. Projekty, jejichž cílem je tvorba nového IS nebo výrazná inovace stávajícího IS se realizují v několika fázích, které se obvykle po určitě době opakují, a proto se nazývají fázemi životního cyklu IS. U jednotlivých fází životního cyklu jsou vždy uvedeny obecné činnosti, týkající se vlastní fáze a dále specifika týkající se pouze TASW. Podobná specifika mají jednotlivé fáze i pro IASW. Pro účely této práce však nejsou podstatná. Zdrojem pro tuto kapitolu je publikace Tvorba informačních systémů [2]. Fáze tvorby a užití IS podle metodiky MMDIS jsou : Globální strategie (GST) Podle Voříška [10]: Globální strategie dává smysl a cíl všem podnikovým aktivitám. Tento dokument formuluje celopodnikové cíle a poslání společnosti, dále definuje dílčí cíle pro dosažení cílů hlavních, jejich priority, okolnosti a zdroje potřebné k jejich dosažení. Je potřeba ho neustále aktualizovat dle potřeb společnosti nebo vzhledem k okolí podniku.
61
Podle metodiky MMDIS vychází GST ze SWOT analýzy, která analyzuje silné (Strengths) a slabé (Weaknesses) stránky, příležitosti (Opportunities) a hrozby (Threats) z pohledu organizace. Na jejím základě se formuluje poslání a smysl existence organizace. Globální strategie by měla vést k tomu, aby podnik maximálně využil svých silných stránek a externích příležitostí a eliminoval své slabé stránky a vyhnul se externím hrozbám. Informační strategie (IST) Jejím cílem je navrhnout celkovou koncepci IS/IT podniku tak, aby byly optimálně podpořeny podnikové cíle definované v globální podnikové strategii a navrhnout jednotlivé kroky realizace IS/IT. Z hlediska strategické důležitosti IST je nutné zapojit do její tvorby nejužší vedení podniku. Je tvořena s výhledem na 2 až 3 roky a v průběhu platnosti vyžaduje pravidelné aktualizace reagující na vnitřní nebo vnější vlivy [2]. Úvodní studie (UST) Jinak též studie proveditelnosti. Zaměřuje se na detailní posouzení realizovatelnosti byznys požadavků na projekt a na variantní návrh koncepce řešení [2]. Nejdůležitější činnosti a výstupy této fáze: Obecně: definice byznys cílů projektu a metrik jejich hodnocení, popis cílového stavu dané části IS, vymezení rozsahu projektu a jeho vazeb na okolí, definice typů uživatelů a jim poskytovaných služeb, návrh koncepce řešení (variantní) a výběr varianty, zasazení aplikace do aplikační architektury IS, popis aktuálního stavu dané části IS a potřeby jeho změny, hrubé vymezení funkcionality a dat, určení zásadních parametrů SLA13 (dostupnost, doba odezvy atd.), určení/odhad zdrojů pro řešení projektu, budoucí provoz a údržbu, organizace projektu – projektové role a jejich obsazení, přínosy projektu, rozpočet projektu, 13
SLA – Service Level Agreement - dohoda o úrovni poskytovaných služeb. SLA představuje formalizovaný popis služby, kterou poskytuje dodavatel zákazníkovi. SLA definuje rozsah, úroveň a kvalitu služeb (dostupnost, rychlost, cenu).
62
rizika projektu, harmonogram projektu. V případě TASW: vytvoření poptávkového dokumentu a jeho zveřejnění, vyhodnocení referenčních instalací, vyhodnocení prezentací produktů a služeb uchazečů, výběr nejlepších uchazečů, kteří zpracují úvodní studii na zavedení TASW (viz bod obecně), na základě úvodních studií výběr nejvhodnějšího TASW a jeho dodavatele, sepsání kontraktu na dodávku TASW. Globální analýza a návrh (GAN) Vychází z koncepce stanovené v úvodní studii. Cílem této fáze je vymezení požadovaných funkcí a dat řešeného softwaru na konceptuální úrovni a formulace požadavků na kvalitu a bezpečnost, což znamená nezávisle na implementační a provozní platformě. Dalším krokem je návrh implementační platformy pro detailní návrh a provozní platformy pro provoz aplikace podle informační strategie [2]. Nejdůležitější činnosti a výstupy této fáze: Obecně: byznys analýza, specifikace požadavků, návrh změn v procesech, návrh logických vazeb budované aplikace na ostatní aplikace v rámci IS, specifikace rozhraní na okolní IS, upřesnění provozního prostředí. V případě TASW: instalace TASW pro školící účely, školení TASW projektového týmu na straně zákazníka, tvorba hrubého modelu podnikových procesů, testování vhodnosti funkcí TASW pro podporu podnikových procesů a případná úprava jak funkcí, tak procesů. 63
Detailní analýza a návrh (DAN) Transformace konceptuálního návrhu na technologický, závislý na zvoleném typu implementační a provozní platformy [2]. Nejdůležitější činnosti a výstupy této fáze: Obecně: návrh způsobu testování, návrh postupu migrace dat (při náhradě staré aplikace), návrh a dimenzování potřebné infrastruktury, návrh přístupových práv jednotlivých typů uživatelů, návrh rozhraní na ostatní aplikace. V případě TASW: úprava modelu podnikových procesů, úprava modelu organizační struktury, návrh customizačních parametrů, návrh úpravy vstupních a výstupních obrazovek (názvy polí, chybové hlášky, help), návrh výstupních sestav. Implementace (IMP) Náplní implementace je naprogramování programových modulů ve zvoleném vývojovém prostředí, realizace fyzického návrhu databáze v konkrétním databázovém prostředí, testování a kompletace dokumentace [2]. Nejdůležitější činnosti a výstupy této fáze: Obecně: vytvoření uživatelské dokumentace a pravidel provozu aplikace, vytvoření provozního prostředí, vytvoření databáze v konkrétním SŘBD, nastavení přístupových práv, funkční testy a opravy chyb, zátěžové testy a optimalizace aplikace a její provozní platformy z hlediska výkonnosti, integrační testy a oprava chyb. 64
V případě TASW: nastavení customizačních parametrů, úpravy obrazovek, realizace výstupních sestav. Zavádění (ZAV) V této fázi se připravuje technologická infrastruktura, instaluje se aplikace na provozní platformu, transformuje se datová základna, školí se uživatelé a realizuje se zkušební provoz aplikace, při němž se odstraňují nalezené nedostatky [2]. Nejdůležitější činnosti a výstupy této fáze: instalace technologické infrastruktury provozního prostředí, instalace aplikace v provozním prostředí, zprovoznění kompletně funkční aplikace v ostrém provozním prostředí, migrace dat do nového systému, školení uživatelů, akceptační testování, tvorba předávacích protokolů. Provoz a údržba (PUR) Aplikace je provozována, podporuje byznys procesy a dosahuje přínosy, pro které byl projekt realizován. Aplikace je také udržována pomocí změn parametrů nebo funkcí dle aktuálních požadavků [2]. Nejdůležitější činnosti a výstupy této fáze:
informace poskytované provozovanou aplikací a související přínosy v byznysu,
zálohování dat a aplikace,
hodnocení nákladů a přínosů aplikace,
požadavky na změnu aplikace,
úpravy aplikace a jejich dokumentace,
výsledky měření plnění dohodnutých SLA.
Vyřazení (VYR) V této fázi dochází k vyřazení aplikace z důvodu nepotřebnosti nebo nerentability. Je nutné vyřešit archivaci dat a ošetřit vazby aplikací a procesů, které byly vyřazením dotčeny. 65
Nejdůležitější činnosti a výstupy této fáze [2]: archivace dat, vyřazení (likvidace, prodej) komponent, změna rozhraní navazujících aplikací, změna navazujících procesů.
66
8 Rozšíření dimenze kvality metodiky MMDIS Tato část diplomové práce je zaměřena na hlavní cíl práce, a to rozšíření dimenze kvality metodiky MMDIS o část zaměřenou na kvalitu implementace TASW, a to hlavně z pohledu projektového týmu na straně zákazníka. Pro tyto účely vytvořil autor model hodnocení kvality implementace TASW, který je založen na jeho zkušenostech při účasti na projektech implementace TASW. Popis modelu hodnocení kvality implementace TASW V současné podobě je dimenze kvality součástí dimenze, která se nazývá bezpečnost a kvalita (více v kapitole 7.2.2) a zaměřuje se hlavně na přiměřenou bezpečnost aplikace, její další kvalitativní charakteristiky vymezené v kapitolách 4.2 (zajištění kvality IS) a 5.1.3 (Požadavky na informační systém) a na související služby, které jsou zákazníkem vyžadovány. V případě TASW se díky vývoji profesionálním týmem analytiků, vývojářů, programátorů a testerů specializovaného výrobce předpokládá, že bezpečnostní předpoklady jsou splněny a díky generalizaci požadavků určitého segmentu podniků je pokryta i většina funkčních a nefunkčních požadavků na aplikaci. Problematickou otázkou pak tedy zůstává samotná implementace TASW, kdy vzniká potřeba software lokalizovat, parametrizovat a integrovat přímo pro potřeby specifické organizace. Jak již bylo uvedeno v kapitole 5.2.2 (TASW), s většinou TASW je úzce spojena také vlastní implementační metodika, která má za cíl identifikovat a naplnit potřeby organizace s minimálními programovými úpravami TASW. A právě splnění tohoto cíle, který přímo závisí na kvalitě projektového týmu zákazníka, je v projektech implementace TASW kritické. Cílem této práce je návrh řešení tohoto problému, a zajištění předpokladů k tomu, aby implementace TASW proběhla správně a aplikace plnila všechny požadavky. Jak je patrné z kapitol 3.2 (Důvody neúspěchu při implementaci TASW) a 6.1.4 (Předpoklady úspěch projektu) jsou pro úspěch projektu implementace TASW klíčové tyto hlavní faktory: řízení projektu na straně zákazníka zkušeným projektovým manažerem a jeho týmem, podpora vedení organizace, včasné a dostatečné zapojení kvalifikovaných a zkušených pracovníků zákazníka.
67
Fungující provázání těchto klíčových faktorů se však u většiny projektů, kterých se autor účastnil, ukázalo jako problematické a proto na ně bude v průběhu jednotlivých fází hodnocení kvality implementace kladen důraz. Dimenze kvality zachovává princip otevřenosti metodiky, neobsahuje žádné referenční modely a nepředepisuje striktně jednotlivé kroky. Je založena na principu unikátnosti projektu a jeho řešení. Ověřuje kvalitu provedení jednotlivých fází implementace aplikace TASW a podněcuje k vlastní aktivitě při řešení problematických otázek projektovým týmem na straně zákazníka. Nenabízí způsob řešení jednotlivých částí, pouze hodnotí úroveň kvality jejich splnění. Struktura modelu hodnocení kvality implementace TASW Pro hodnocení vlastní kvality implementace TASW vytvořil autor model hodnocení kvality implementace TASW, ten je rozdělen do několika fází kopírujících životní cyklus aplikace podle metodiky MMDIS. Jednotlivé fáze neodpovídají přímo fázím životního cyklu aplikace, ale vždy je zmíněna jejich návaznost na ně. Obsahem hodnocení kvality nejsou jen činnosti probíhající v dané fázi, ale také ostatní faktory, které mají přímý vliv na výslednou kvalitu implementace. Každou fázi autor rozdělil na několik dílčích částí, které jsou popsány v příslušných podkapitolách. Vždy je hodnocena kvalita provedení každé z nich. Kvalitu by měl vždy posuzovat manažer kvality a s ním další role, které jsou v příslušné části zainteresovány. Cílem hodnocení jednotlivých částí a fází je ujištění, že během implementace TASW, byly ve správnou dobu řádně zpracovány všechny klíčové kroky vedoucí k úspěšné implementaci. V případě, zjištění jakéhokoliv pochybení, zanedbání nebo nejasností autor doporučuje předmětnou oblast vyřešit dříve, než bude projekt implementace pokračovat. Průběh hodnocení kvality by měl kopírovat postup fází implementace, aby byly příslušné rozpory identifikovány co nejdříve a jejich vyřešení bylo jak časově, tak finančně co nejméně náročné. Metriky modelu hodnocení kvality implementace TASW Metriky pro hodnocení jednotlivých částí fází jsou pouze doporučující a jejich váhu nastavil autor sám na základě svých zkušeností. Jestliže není řečeno jinak, výsledné hodnocení každé fáze je dosaženo zprůměrováním výsledků hodnocení kvality jejích částí. V případě použití „checkboxů“ se hodnotí pouze splnění určitých částí jednotlivých fází, nikoliv úroveň jejich splnění. Je vždy na posouzení osob zainteresovaných na hodnocení 68
kvality, jaká úroveň splnění kvality je v konkrétních případech nutná. Pro účely každého specifického projektu implementace TASW autor doporučuje zvážit důležitost jednotlivých fází a jejich částí pro úspěšné dokončení projektu implementace TASW a dle konkrétních zjištění upravit nastavení metrik. Pro úspěch projektu jsou z pohledu autora všechny fáze klíčové a doporučuje, aby hodnocení kvality všech fází dosáhlo 100%. Fáze modelu hodnocení kvality implementace TASW: Fáze 0 (F0) - Hodnocení připravenosti podniku na implementaci TASW - (GST, IST) Fáze 1 (F1) - Hodnocení předimplementační fáze – (UST) Fáze 2 (F2) – Hodnocení analytických fází – (GAN, DAN) Fáze 3 (F3) - Hodnocení průběhu implementace (IMP) Fáze 4 (F4) - Hodnocení zavedení TASW do provozu (ZAV, PUR)
8.1 Hodnocení připravenosti podniku na implementaci TASW (F0) O úspěchu projektu implementace TASW se rozhoduje daleko dříve, než samotný projekt začne. Tato fáze by měla být odpovědí na to, zda je vůbec organizace připravena projekt implementace TASW spustit a dotáhnout ke zdárnému konci. V jednotlivých částech hodnotí kvalitu strategií podniku, kvalitu jeho personálního obsazení z pohledu schopnosti řízení projektu implementace TASW a úroveň podnikových procesů. Autor považuje splnění kvality této fáze pro úspěšnou implementaci za nezbytnou a dle jeho zkušeností je zároveň její splnění z pohledu podniku velmi často problematické. Návaznost na MMDIS: IST, GST
8.1.1 Hodnocení kvality informační strategie (F0.1) Popis: Základním pilířem fungování a rozvoje IS/ICT je existence IST organizace. Pokud v organizaci IST schází nebo není aktuální je nutné jí definovat na základě globální strategie organizace (více v kapitole 7.2.3 Životní cyklus aplikace podle MMDIS). Cílem IST je navrhnout celkovou koncepci IS/ICT podniku tak, aby byly optimálně podpořeny podnikové cíle definované v GST a navrhnout jednotlivé kroky realizace IS/ICT. 69
Role: CIO (Chief information officer), Top management, Manažer kvality Vstup: Informační strategie podniku (IST) Výstup: Hodnocení kvality IST podniku z pohledu její aktuálnosti a integrace podnikových cílů. Metrika: Metrika udává percentuální splnění požadavků na kvalitu IST Stav IST
Splnění v %
IST neexistuje
0
IST existuje, není aktualizovaná
25
IST je aktualizovaná, neintegruje všechny podnikové cíle z pohledu GST
50
IST je aktualizovaná a integruje všechny podnikové cíle z pohledu GST
100
Váha metriky: 35% Určuje význam hodnoceného bodu ve vztahu k celkovému hodnocení splnění kvalitativních požadavků na danou oblast.
8.1.2 Hodnocení kvality personálního obsazení organizace a projektu (F0.2) Popis: Personální otázka je pro průběh projektu z pohledu kvality klíčovou. Nejedná se pouze o samotné řízení projektu, ale také o členy projektového týmu – garanty, odpovědné za jednotlivé části IS, kteří musí mít patřičné zkušenosti a vlastnosti. Důležité je jejich včasné zapojení do projektu, vymezení odpovědností, nastavení motivačních programů a zamezení fluktuace pracovníků na těchto pozicích. Pokud to situace a vážnost projektu vyžaduje, je vhodné tyto pozice personálně posílit. Role: Personální manažer, Projektový manažer, Manažer kvality Vstup: Organizační struktura organizace Výstup: Hodnocení kvality personálního obsazení organizace
70
Metrika: Úroveň personálního obsazení organizace
Splnění v %
Organizace nemá k dispozici zkušeného projektového manažera Organizace nemá k dispozici zkušené členy do projektového týmu
0
Organizace má k dispozici zkušené členy do projektového týmu
50
Organizace má k dispozici zkušeného projektového manažera Organizace nemá k dispozici zkušené členy do projektového týmu
50
Organizace má k dispozici zkušené členy do projektového týmu
100
Váha metriky: 30%
8.1.3 Hodnocení úrovně podnikových procesů organizace (F0.3) Popis: Hlavním úkolem IS v organizaci je podpora podnikových procesů. Období před implementací nového IS je ideálním časem pro optimalizaci podnikových procesů. Cílem je, aby organizace měla před implementací IS dobře zmapované, popsané a řízené, příp. automatizované podnikové procesy. Role: Vlastníci procesů, Procesní analytik, Manažer kvality Vstup: Procesní mapa organizace, popisy procesů organizace, vnitřní směrnice Výstup: Hodnocení úrovně podnikových procesů Metrika: Popis
Splnění v %
Procesy nejsou popsané
0
Procesy jsou částečně popsané
25
Procesy jsou popsané
50
Procesy jsou popsané a řízené
75
Procesy jsou popsané, řízené a optimalizované Váha metriky: 35%
100
71
8.2 Hodnocení předimplementační fáze (F1) Hodnocení předimplementační fáze má za úkol vyhodnotit úroveň kvality projektového záměru, požadavků na projekt, procesu výběru TASW a zhodnotit kvalitu předimplementační analýzy. Návaznost na MMDIS: UST
8.2.1 Hodnocení kvality projektového záměru (F1.1) Popis: Cílem hodnocení kvality projektového záměru je zjištění, zda je projektový záměr srozumitelně definován, zda odpovídá informační strategii organizace a zda je projekt smysluplný a proveditelný. Role: Zadavatel projektu, Management, Manažer kvality, Projektový manažer Vstup: Projektový záměr Výstup: Hodnocení kvality projektového záměru Metriky: Srozumitelnost: Posuzuje, zda je projekt srozumitelně definován. (CheckBox 3/3=100%) Obsah
Splněno
Odborné zpracování projektu Srozumitelnost projektu Shoda v porozumění cílů projektu
Realizovatelnost: Posuzuje schopnost dosažení projektových cílů a způsoby jejich dosažení z pohledu existence níže vyjmenovaných bodů, které je nutno splnit, aby mohl projekt pokračovat dále. (CheckBox 5/5=100%) Obsah
Splněno
Vize projektu Kritéria dosažení vizí projektu Strategické cíle projektu Kritéria pro dosažení strategických cílů projektu Projekt odpovídá IST podniku 72
Proveditelnost: Posuzuje existenci jednotlivých klíčových bodů z pohledu proveditelnosti. Všechny tyto body je třeba u každého konkrétního projektu reálně odhadnout a zvážit zda v projektu pokračovat či nikoliv. (CheckBox 6/6=100%) Obsah
Splněno
Plán projektu, milníky, termíny Potřebné zdroje pro realizaci projektu Předpokládané náklady projektu Předpokládaná návratnost investic Řízení rizik projektu Projektová organizace (role, odpovědnosti, motivace)
8.2.2 Hodnocení kvality předimplementační studie (F1.2) Popis: Hodnotí kvalitu předimplementační studie dle splnění klíčových bodů Role: Manažer kvality, CIO (Chief Information Officer), Projektový manažer, Management Vstup: Předimplementační studie Výstup: Hodnocení kvality předimplementační studie Metrika: (Checkbox 8/8 = 100%) Obsah
Splněno
Analýza provozního prostředí Popis současného a očekávaného stavu Procesní analýza Návrh procesních a organizačních změn Souhrn požadavků na funkcionalitu systému, jeho další rozvoj a údržbu Posouzení technického, komunikačního a provozního prostředí Návrh na úpravu technického, komunikačního a provozního prostředí Odhadovaná rizika implementace
73
8.2.3 Hodnocení kvality procesu výběru TASW (F1.3) Popis: Výběr TASW je jedním z prvních a nejdůležitějších kroků. Je náročný na podnikové zdroje a úzce na něm závisí úspěch projektu. Proces výběru TASW probíhá na základě vypracovaných nabídek od dodavatelů. Kritéria pro výběr TASW a jejich pořadí je nutno přizpůsobit specifickým podmínkám projektu. Role: Top management Vstupy: Poptávkový dokument na dodavatele TASW, Nabídky dodavatelů, Kritéria hodnocení, Výsledky výběrového řízení na TASW Výstupy: Hodnocení kvality procesu výběru TASW Metrika: Checkbox (4/4 = 100%) Předpoklady
Splněno
Kritéria výběru TASW jsou stanovena v souladu s potřebami organizace Vyhodnocení nabídek bylo provedeno v souladu s určenými kritérii Na vyhodnocení nabídek se podíleli všichni zainteresovaní zaměstnanci Výběrového řízení se zúčastnil minimální požadovaný počet dodavatelů
8.3 Hodnocení analytických fází (F2) Hodnocení analytických fází posuzuje kvalitu činností analytických fází z pohledu zákazníka. Hlavní cíle GAN a DAN jsou popsány v kapitole 7.2.3 (Životní cyklus aplikace podle MMDIS) a ve většině případů jsou řešeny použitím metodik vyvinutých pro vybraný TASW.
8.3.1 Hodnocení kvality zajištění školícího prostředí a školení projektového týmu zákazníka (F2.1) Popis: Pro jasnou představu členů projektového týmu zákazníka o vlastnostech a možnostech TASW je nezbytné vytvořit na straně zákazníka realitě co nejblíže odpovídající školící prostředí a na něm předvést aplikaci a zaškolit členy týmu. Výsledkem by měla být finální specifikace požadavků a případných úprav podnikových procesů, či naopak přizpůsobení aplikace podnikovým procesům. 74
Role: Manager kvality, Projektový manager, IT oddělení Vstupy: Specifikace testovacího prostředí, zápisy z průběhu školení, dotazníky pro hlavní uživatele Výstupy: Hodnocení kvality zajištění Metriky: (CheckBox 7/7 = 100%) Předpoklady
Splněno
Školící prostředí odpovídá provoznímu prostředí Prezentace TASW se zúčastnili všichni zainteresovaní pracovníci Školení TASW se zúčastnili všichni zainteresovaní pracovníci Školení uživatelů splnilo požadované účely
8.3.2 Hodnocení kvality specifikace funkčních požadavků na TASW (F2.2) Popis: Základní předpoklad úspěchu projektu implementace TASW jsou přesně definované, jednoznačné a neměnné funkční požadavky na IS ze strany zákazníka (více v kapitole 5.1.3). Role: Manažer kvality, Garanti modulů, Koncoví uživatelé, Projektový manažer Vstupy: Specifikace funkčních požadavků Výstupy: Hodnocení kvality specifikace funkčních požadavků Metriky: (CheckBox 7/7 = 100%) Předpoklady
Splněno
Požadavky odpovídají procesům organizace Požadavky odpovídají normám kvality Požadavky odpovídají podnikovým směrnicím Požadavky odpovídají možnostem TASW Do tvorby požadavků byli dostatečně a včas zahrnuti koncoví uživatelé Je schválena finální verze požadavků Existuje shoda v porozumění požadavků na straně dodavatele i odběratele
8.3.3 Hodnocení kvality nefunkčních požadavků na TASW (F2.3) Popis: Pro správné splnění požadovaných výkonových vlastností, zabezpečení a ostatních nefunkčních požadavků je potřeba je jednoznačně a přiměřeně definovat. 75
Role: Tester, Koncoví uživatelé, Manažer kvality Vstupy: Specifikace nefunkčních požadavků Výstupy: Hodnocení kvality specifikace nefunkčních požadavků Metriky: (CheckBox 7/7 = 100%) Předpoklady
Splněno
Požadavky odpovídají procesům, normám a směrnicím organizace Požadavky odpovídají možnostem TASW Požadavky odpovídají platné právní úpravě SLA odpovídá požadovaným nefunkčním požadavkům Je schválena finální verze požadavků Existuje shoda v porozumění požadavků na straně dodavatele i odběratele
8.3.4 Hodnocení kvality přípravy testovacích scénářů pro akceptační testy Popis: Hodnocení kvality přípravy scénářů pro akceptační testy, které společně připravují zákazník s dodavatelem. Jejich splnění je podmínkou převzetí TASW zákazníkem do užívání. Role: Testeři, Manažer kvality, Garanti modulů, Test analytik dodavatele Vstupy: Testovací scénáře pro akceptační testy Výstupy: Hodnocení kvality testovacích scénářů pro akceptační testy Metriky: (CheckBox 4/4 = 100%) Předpoklady
Splněno
Na tvorbě testovacích scénářů se podíleli všichni zainteresovaní pracovníci Testovací scénáře pokrývají kompletně funkční požadavky na TASW Testovací scénáře pokrývají kompletně nefunkční požadavky na TASW Akceptační kritéria jsou definovaná a oboustranně odsouhlasena
76
8.4 Hodnocení průběhu implementace (F3) Cílem této fáze je vytvořit, nasadit a otestovat komponenty systému podle schválené specifikace, dále jejich parametrizace a integrace do IS/ICT podniku, nejprve do testovacího prostředí a následně do provozního prostředí. Z pohledu zákazníka se jedná především o zajištění testovacího prostředí, akceptační testování TASW a sledování průběhu projektu. Návaznost na MMDIS: IMP
8.4.1 Hodnocení kvality zajištění testovacího prostředí Popis: Pro dodržení plánovaného průběhu projektu implementace TASW je nutné včas zajistit testovací prostředí co nejvíce odpovídající provoznímu prostředí a v něm vyškolit akceptační tým zákazníka. Role: Manažer kvality, CIO, Garanti modulů Vstupy: Specifikace provozního prostředí Výstupy: Hodnocení kvality zajištění testovacího prostředí Metriky: (CheckBox 5/5 = 100%) Předpoklady
Splněno
Testovací prostředí bylo připraveno dle časového harmonogramu projektu Testovací prostředí odpovídá provoznímu prostředí TASW je nainstalován v testovacím prostředí Migrace dat proběhla úspěšně Akceptační tým vyškolen
8.4.2 Hodnocení kvality akceptačního testování Popis: Hodnocení kvality akceptačního testování akceptačním týmem na straně zákazníka. Splnění všech akceptačních kritérií je podmínkou pro převzetí aplikace k užívání zákazníkem. Role: Testeři, Manažer kvality, Garanti modulů Vstupy: Výstupy akceptačních testů Výstupy: Hodnocení kvality výstupů akceptačních testů 77
Metriky: (CheckBox 4/4 = 100%) Předpoklady
Splněno
Proběhly všechny scénáře akceptačního testování Nalezené chyby byly zdokumentovány předány dodavateli TASW k řešení Na testování se podíleli všichni zainteresovaní uživatelé Akceptační testování bylo ukončeno po splnění všech akceptačních kritérií
8.4.3 Hodnocení kvality splnění cílů fáze implementace Popis: Hodnocení kvality splnění cílů fáze implementace z pohledu souladu s funkčními specifikacemi pro TASW v provozním prostředí. Role: Manažer kvality, Garanti modulů, Vstupy: Funkční specifikace pro aplikaci (parametrizace, funkcionalita, integrace, migrace) Výstupy: Hodnocení kvality splnění cílů fáze implementace Metriky: (CheckBox 8/8 = 100%) Předpoklady
Splněno
Provozní prostředí je nainstalováno a splňuje požadavky TASW je nainstalován v provozním prostředí podniku TASW odpovídá funkční specifikaci pro konfiguraci TASW odpovídá funkční specifikaci pro funkcionalitu TASW odpovídá požadavkům na rozhraní a integraci Migrace dat proběhla dle požadavků funkční specifikace Pracovní role a přístupová práva jsou nastavena Dokumentace k TASW je vytvořena a předána
8.5 Hodnocení zavedení TASW do provozu (F4) Cílem zavedení do provozu je přechod na nově implementovaný TASW a jím podporované upravené podnikové procesy. Splněním všech předchozích bodů modelu hodnocení kvality je vytvořen předpoklad plného využití jeho možností. TASW je nasazen v provozním prostředí, splňuje všechny požadavky a kritéria, která byla definována, obsahuje migrovaná data, je spuštěn zkušební provoz. Z pohledu projektového týmu zákazníka je třeba 78
zajistit školení koncových uživatelů, kompletaci dokumentace a předání TASW do ostrého provozu. Tím končí úkoly projektového týmu na straně zákazníka. Projekt je nutno formálně ukončit, projektový tým rozpustit. Za zajištění následného provozu a údržby TASW přebírá odpovědnost tým garantů jednotlivých modulů TASW ve spolupráci s oddělením IT. Návaznost na metodiku MMDIS: (ZAV, PUR)
8.5.1 Hodnocení kvality provedení školení koncových uživatelů (F4.1) Popis: Hodnocení kvality provedení školení koncových uživatelů z pohledu jejich připravenosti na přechod a ostrý provoz nově implementovaného TASW. Role: Manažer kvality, Garanti modulů Vstupy: Uživatelská dokumentace, evidenční listiny účastníků školení, materiály pro školící účely, výsledky konečného přezkoušení, zpětná vazba při řešení provozních problémů koncových uživatelů ve zkušebním provozu Výstupy: Hodnocení kvality provedení školení koncových uživatelů Metriky: (CheckBox 5/5 = 100%) Předpoklady
Splněno
Školení koncových uživatelů proběhlo dle plánu Školení bylo ukončeno závěrečným přezkoušením Výsledky závěrečného přezkoušení jsou v souladu s očekáváním Průběh zkušebního provozu měl očekávané výsledky Je k dispozici uživatelská dokumentace dle pracovních činností a rolí
8.5.2 Hodnocení kvality dokumentace projektu implementace TASW (F4.1) Popis: Hodnocení kvality dokumentace projektu implementace TASW z pohledu její úplnosti, přehlednosti a aktuálnosti Role: Manažer kvality, projektový manažer, garanti modulů Vstupy: Dokumentace průběhu projektu (GAN, DAN), dokumentace úprav TASW, implementační dokumentace, uživatelská dokumentace, provozní dokumentace Výstupy: Hodnocení kvality dodané dokumentace k projektu implementace TASW 79
Metriky: (CheckBox 5/5 = 100%) Předpoklady
Splněno
Aktuální a úplná dokumentace průběhu projektu (GAN, DAN) Aktuální a úplná dokumentace úprav TASW Aktuální a úplná implementační dokumentace Aktuální a úplná uživatelská dokumentace Aktuální a úplná provozní dokumentace
8.5.3 Hodnocení kvality průběhu a ukončení projektu implementace TASW Popis: Hodnocení kvality průběhu projektu a jeho formálního ukončení z pohledu využití zdrojů a splnění časového harmonogramu a cílů projektu. Role: Manažer kvality, projektový manažer, top management, garanti modulů, Vstupy: Plán projektu, kompletní projektová dokumentace, závěrečná zpráva projektu Výstupy: Hodnocení kvality průběhu a ukončení projektu implementace TASW Metriky: (CheckBox 5/5 = 100%) Předpoklady
Splněno
Projekt byl formálně ukončen Byla zpracována závěrečná zpráva projektu Byl splněn časový harmonogram projektu Zdroje na projekt byly správně odhadnuty a efektivně vyčerpány Byly splněny cíle projektu
80
9 Ověření modelu hodnocení kvality implementace TASW K praktickému ověření modelu došlo při realizaci opakované, původně neúspěšné, implementace CRM systému ve společnosti Lázně Františkovy Lázně a.s., jehož realizace byla naplánována na druhé čtvrtletí roku 2015. Výsledkem hodnocení Fáze 0 (F0) Hodnocení připravenosti podniku na implementaci TASW, však bylo, že podnik není připraven na kvalitní implementaci TASW (viz tab.4) a projekt byl dočasně pozastaven. Na základě výsledků hodnocení F0 vznikly na úrovni top managementu úkoly pro zainteresovaná oddělení s cílem napravení problematických oblastí před opětovným spuštěním projektu.
Hodnocení jednotlivých částí Fáze 0 (F0) Hodnocení kvality informační strategie (F0.1) Hodnocení kvality personálního obsazení organizace a projektu (F0.2) Hodnocení úrovně podnikových procesů organizace (F0.3)
Splnění v % 25
Váha metriky 35
(Váha x Splnění)/100 8,75
50
30
15
0
35
0
Hodnocení připravenosti podniku na implementaci TASW (%)
23,75
Tab. 4 Výsledky hodnocení připravenosti podniku na implementaci TASW (%)
Z pohledu autora v tomto případě model hodnocení kvality implementace TASW splnil svůj účel a na základě jeho výsledků byl projekt přerušen do doby, než budou problematické části napraveny, čímž se vytvoří předpoklady k jeho úspěšné realizaci.
81
Závěr Jako téma této diplomové práce si autor zvolil Řízení kvality softwaru. Až při detailním zamyšlení nad strukturou budoucí práce si autor uvědomil, jak široká je tato problematika a kolik publikací, diplomových a bakalářských prací už na ni bylo zpracováno. Přesto je to téma, které si neustále zaslouží velkou pozornost, protože jak je patrné z kapitoly 3.1, úspěšnost informatických projektů je stále velmi nízká. Vzhledem k objemu finančních prostředků, které jsou do nich investovány a jejich důležitosti pro organizace je potřeba maximalizovat efektivitu jejich využití a všemi dostupnými prostředky zajistit co nejvyšší úspěšnost informatických projektů. Při hledání přínosu této práce se autor zamýšlel nad tím, kterou z oblastí kvality softwaru, vnímá ze svého pohledu jako nejvíce problematickou a nedostatečně řešenou. Z tohoto zamyšlení vznikl po konzultaci s vedoucí práce hlavní cíl diplomové práce a tím je návrh metodiky, která má za cíl zajistit kvalitní implementaci TASW v podnikovém prostředí, a to z pohledu projektového týmu na straně zákazníka. Tento cíl je řešen modelem hodnocení kvality průběhu implementace TASW v podnikovém prostředí, který je popsán v kapitole 8 (Rozšíření dimenze kvality metodiky MMDIS). Dílčí cíle diplomové práce se zaměřují na vymezení pojmů z předmětné oblasti, na seznámení s disciplínami souvisejícími s řízením kvality softwaru, na specifikaci podnikových informačních systémů a požadavků na ně a na důležitost projektového řízení při informatických projektech. Vzhledem k obsáhlosti jednotlivých témat, autor pro účely této práce omezil rozsah jejich popisu. Dílčí cíle práce jsou zpracovány v kapitolách 2,3,4,5,6. Model hodnocení kvality implementace TASW v podnikovém prostředí byl vytvořen na základě předchozích zkušeností autora při účasti na rozsáhlých projektech implementace TASW, které z jeho pohledu neprobíhaly optimálně a podle kritérií hodnocení úspěšnosti projektu by byly označeny jako projekty neúspěšné. Jako hlavní příčinu neúspěšných projektů vnímá autor nedostatečnou připravenost podniku, nízkou odbornou úroveň pracovníků na straně zákazníka a v neposlední řadě nedostatek zkušeností s řízením projektů na straně zákazníka. To jsou také hlavní body, které jsou navrhovaným modelem kvality hodnocení řešeny a na které by měl včas upozornit.
82
Autor předpokládá, že použití modelu hodnocení kvality implementace TASW přispěje ke zvýšení úspěšnosti projektů implementace TASW v podnikovém prostředí tím, že včas upozorní projektový tým zákazníka na problematické oblasti týkající se přímo nebo nepřímo projektu, které je potřeba vyřešit dříve než projekt pokročí dále, tak jako se to stalo při jeho prvním praktickém využití při projektu implementace CRM ve společnosti Lázně Františkovy Lázně a.s. Předpokládá se, že po vyřešení nedostatků, na které model hodnocení kvality poukázal, bude projekt implementace CRM ve společnosti obnoven a vznikne příležitost k dalšímu praktickému ověření jeho přínosu a také k jeho případnému rozvoji.
83
Seznam použitých zdrojů Knižní publikace: [1]
BASL, Josef a Roman BLAŽÍČEK. Podnikové informační systémy: podnik v informační společnosti. Praha: Grada, 2012. ISBN 978-80-247-4307-3.
[2]
BRUCKNER, Tomáš, Jiří VOŘÍŠEK, Alena BUCHALCEVOVÁ. A KOLEKTIV. Tvorba informačních systémů: principy, metodiky, architektury. Praha: Grada, 2012. ISBN 978-80-247-4153-6.
[3]
DVOŘÁK, Drahoslav. Řízení projektů: nejlepší praktiky s ukázkami v Microsoft Office. Brno: Computer Press, 2008. ISBN 978-80-251-1885-6.
[4]
PATTON, Ron. Testování softwaru. Praha: Computer Press, 2002. ISBN 80-7226-636-5.
[5]
PITRA, Zbyněk. Podnikový management. Praha: ASPI, 2008. ISBN 978-80-7357-372-0.
[6]
SODOMKA, Petr a Hana KLČOVÁ. Informační systémy v podnikové praxi: principy, metodiky, architektury. Brno: Computer Press, 2010. ISBN 978-80-251-2878-7.
[7]
SVATÁ, Vlasta. Audit informačního systému. Praha: Professional Publishing, 2012. ISBN 978-807-4311-062.
[8]
VANÍČEK, Jiří. Měření a hodnocení jakosti informačních systémů. Praha: Česká zemědělská univerzita, Provozně ekonomická fakulta, 2004. ISBN 80-213-1206-8.
[9]
VOŘÍŠEK, Jiří. Principy a modely řízení podnikové informatiky. Praha: Oeconomica, 2008. ISBN 978-80-245-1440-6.
[10] VOŘÍŠEK, Jiří. Strategické řízení informačního systému a systémové integrace. Praha: Management Press, 2003. ISBN 80-85943-40-9. Periodika [11] BUCHALCEVOVÁ, Alena, KUČERA, Jan. Hodnocení metodik vývoje informačních systémů z pohledu testování. Systémová integrace, 2008, roč. 15, č. 2, s. 42–54. ISSN 1210-9479
84
[12] BUCHALCEVOVÁ, Alena. Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů. Systémová integrace, 2011, roč. 18, č. 1, s. 109–120. ISSN 1210-9479 [13] CHLAPEK, Dušan. Řízení komplexních projektů IS/ICT. Systémová integrace, 2005, roč. 12, č. 1, s. 117–122. ISSN 1210-9479 Zákony a standardy [14] ČSN EN ISO 9000. Systémy managementu kvality: Základní principy a slovník. Praha: Úřad pro technickou normalizaci, metrologii a státní zkušebnictví, 2006. 64s. Třídící znak 010300 [15] ČSN ISO 10006. Systémy managementu jakosti – Směrnice pro management jakosti projektů. Praha: Úřad pro technickou normalizaci, metrologii a státní zkušebnictví, 2004. 48s. Třídící znak 010333 Odborné studie [16] The Standish Group Report: CHAOS MANIFESTO 2013: Think Big, Act Small. [online]. 2013 [cit. 2015-01-11]. Dostupné z: http://www.versionone.com/assets/ img/files/CHAOSManifesto2013.pdf Elektronické články [17] DANEL, Roman. Agilní metodiky vývoje software. In: [online]. [cit. 2015-03-17]. Dostupné z: http://homel.vsb.cz/~dan11/is_skripta/IS%202011%20-%20Softwarove%20 inzenyrstvi%20-%20agilni%20metodiky.pdf [18] KOCAN, Marek. Co vlastně je informační systém a jak souvisí s řízením?. [online]. [cit. 2015-02-20]. Dostupné z: http://www.zive.cz/clanky/co-vlastne-je-informacni-systemajak-souvisi-s-rizenim/sc-3-a-4436/default.aspx [19] PAPÍK, Martin. Hodnocení jakosti software. In: [online]. [cit. 2015-01-18]. Dostupné z: http://www.kardos.cz/konf/2013/papik_2013.docx [20] Řízení vztahů se zákazníky. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA):
Wikimedia
Foundation,
2001-
[cit.
2015-03-17].
Dostupné
z:
http://cs.wikipedia.org/wiki/%C5%98%C3%ADzen%C3%AD_vztah%C5%AF_se_z%C 3%A1kazn%C3%ADky 85
[21] ŠEBEK,
Václav.
Řízení
projektu.
[online].
[cit.
2015-01-17].
Dostupné
z: https://is.bivs.cz/el/6110/leto2014/B101PLP/um/09_Rizeni.pdf [22] VOŘÍŠEK, Jiří. Kritické faktory úspěchu a rizika informačních systémů. [online]. [cit. 2015-01-17]. Dostupné z: http://nb.vse.cz/~vorisek/FILES/Clanky/1996_Csf_a_rizika_ IS.htm WWW stránky [23] ISACA
Czech
Republic
Chapter [online].
[cit.
2015-02-19].
Dostupné
z:
http://www.isaca.cz/cs/isaca-crc [24] SW testování: Portál zabývající testováním softwaru. [online]. [cit. 2015-02-16]. Dostupné z: http://www.swtestovani.cz [25] Testování softwaru: Portál zabývající se problematikou ověřování kvality software. Manuální i automatizované testování [online].
[cit.
2015-02-17].
Dostupné
z:
http://testovanisoftwaru.cz/ Další [26] BÖHMER, Miroslav, Jiří HUŠEK, Jiří HAVRÁNEK, Daniel MAZANEC, Martin JANKŮ a Kristina KUZNETSOVA. Zlepšování procesů budování IS: Struktura norem Square a základní přehled. Praha, 2014 Dostupné z: http://spicenter.vse.cz/wpcontent/uploads/2015/02/Husek_Jiri-4IT421_final.pdf. [cit. 2015-02-17]. Semestrální práce. VŠE Praha. Vedoucí práce Alena Buchalcevová. [27] Sborník příspěvků z konference Systém řízení kvality a bezpečnosti informačních systémů ve zdravotnictví a ve veřejné správě: Břeclav, 26. listopadu 2007 [online]. 1. vyd. Editor Jiří Vaníček, Daniel Kardoš. Praha: Česká zemědělská univerzita v Praze, 2007, 34 s.[cit. 2015-03-19]. ISBN 978-80-213-1720-8. [28] VOŘÍŠEK, Jiří. VŠE PRAHA. Studijní materiály VŠE: Informační systémy a technologie.
Dostupné
z:
http://nb.vse.cz/~vorisek/FILES/4IT215_materialy_k_
predmetu/05MMDIS-Princip_multidimezionality_a_dimenze_reseni_IS.zip. [cit. 201503-17].
86
Seznam použitých zkratek BI - Business Inteligence CIO - Chief Information Officer - Vedoucí oddělení IT CMMI - Capability Maturity Model Integration - stupňovitý model zralosti CRM - Customer Relationship Management – řízení vztahu se zákazníky ČSN - Česká technická norma ČSN ISO - Převzatá (harmonizovaná) norma EDI - Electronic Data Interchange - elektronická výměna dat EIS - Executive Information Systems - exekutivní informační systémy ERP - Enterprise Resource Planning - řízení podnikových zdrojů GST - Globální strategie IASW - Individuální aplikační software ICT - Information and Communication Technologies - informační a komunikační technologie IEC - International Electrotechnical Commission - mezinárodní elektrotechnická komise IS - Information System - Informační systém IS/ICT - Informační systém podporován informačními a komunikačními technologiemi ISO - International Organization for Standardization - mezinárodní organizace pro normalizaci IST - Informační strategie MIS - Management Information Systems - manažerské informační systémy MMDIS - Multidimensional Management and Development of Information Systems OIS - Office Information Systems - kancelářské informační systémy SCM - Supply Chain Management - řízení dodavatelských řetězců SLA – Service Level Agreement SW - Software 87
SQuaRE
- Software Quality Requirements and Evalution – požadavky na jakost a na
hodnocení jakosti softwaru TASW - Typový aplikační software TPS - Transaction Processing Systems - transakční procesní systémy
88
