Řízení kvality softwaru

Transkript

1 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: doc. Ing. Alena Buchalcevová, PhD. Praha Duben 2015

2 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 Karel Volena

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

4 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

5 Obsah 1 Úvod Cíle diplomové práce Východiska pro zpracování diplomové práce Metodika zpracování diplomové práce Výstupy a přínosy diplomové práce Vymezení pojmů v předmětné oblasti Problémy IT projektů Studie Chaos Manifesto Důvody neúspěchu při implementaci TASW Kvalita softwaru Řízení kvality softwaru Zajištění kvality IS Mezinárodní normy v oblasti řízení kvality softwaru Metodické přístupy k tvorbě IS/ICT Tradiční metodické přístupy Agilní přístupy k vývoji softwaru Testování softwaru Co je to testování softwaru Pojmy z oblasti testování softwaru Role při testování softwaru Typy testů Audit IS Podnikový informační systém Podnikové informační systémy z pohledu funkcí... 40

6 5.1.2 Informační systémy z pohledu úrovně řízení organizace Požadavky na informační systém Možnosti pořízení a implementace softwaru (IS) v podnikovém prostředí IASW - individuální aplikační software TASW typový aplikační software Řízení projektu IS/ICT Projekt Definice projektu Trojimperativ projektu Životní cyklus projektu Předpoklady úspěchu projektu Specifika projektů IS/ICT Řízení projektů IS/ICT Metodika MMDIS Popis metodiky MMDIS Dimenze MMDIS Uživatelské pohledy na IS/ICT Řešitelské pohledy Životní cyklus aplikace podle MMDIS Rozšíření dimenze kvality metodiky MMDIS Hodnocení připravenosti podniku na implementaci TASW (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) Hodnocení předimplementační fáze (F1) Hodnocení kvality projektového záměru (F1.1)... 72

7 8.2.2 Hodnocení kvality předimplementační studie (F1.2) Hodnocení kvality procesu výběru TASW (F1.3) Hodnocení analytických fází (F2) Hodnocení kvality zajištění školícího prostředí a školení projektového týmu zákazníka (F2.1) Hodnocení kvality specifikace funkčních požadavků na TASW (F2.2) Hodnocení kvality nefunkčních požadavků na TASW (F2.3) Hodnocení kvality přípravy testovacích scénářů pro akceptační testy Hodnocení průběhu implementace (F3) Hodnocení kvality zajištění testovacího prostředí Hodnocení kvality akceptačního testování Hodnocení kvality splnění cílů fáze implementace Hodnocení zavedení TASW do provozu (F4) Hodnocení kvality provedení školení koncových uživatelů (F4.1) Hodnocení kvality dokumentace projektu implementace TASW (F4.1) Hodnocení kvality průběhu a ukončení projektu implementace TASW Ověření modelu hodnocení kvality implementace TASW Závěr Seznam použitých zdrojů Seznam použitých zkratek... 87

8 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 MMDIS 1 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

9 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ů ( ) a Informační technologie a management ( ). 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 Pramen 2 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 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

10 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

11 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 :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

12 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

13 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

14 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 group 4 a její studie Chaos Manifesto 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ě 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 , 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ů ( 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

15 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% 60% 40% Chybné Neúspěšné Úspěšné 20% 0% Graf č.1: Úspěšnost IT projektů v letech 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

16 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

17 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

18 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

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

20 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 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 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 SCAMPI SM 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 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

21 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 Model jakosti Vnější míry jakosti Vnitřní míry jakosti Míry jakosti užití ISO/IEC Softwarové inženýrství Hodnocení softwarového produktu Obecný přehled Plánování a řízen Postup pro řešitele Postup pro akvizitéra 21

22 Postup pro nezávislého hodnotitele 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 SQuaRE 7 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 Jako zdroj pro popis sady norem ISO /IEC 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 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

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

24 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

25 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 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 n 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: 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

26 ISO/IEC 25041: 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: 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] 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 Procesy v životním cyklu softwaru z roku Zahrnuje procesy, činnosti a úkoly prováděné ve všech fázích životního cyklu 26

27 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ě Proces je vykonáván, plní cíle, není součástí politik 1 Vykonávaný (Performed) organizace (hrozí jeho ztráta) Proces je vykonáván, plánován, monitorován, 2 Řízený (Managed) vyhodnocován, institucionalizován řízený proces přizpůsobený specifickým podmínkám 3 Definovaný (Defined) 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) 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ě 5 Optimalizovaná (Optimizing) 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

28 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ů 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

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

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

31 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ší 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

32 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

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

34 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] 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

35 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

36 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

37 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

38 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 ( 38

39 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

40 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] 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

41 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

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

43 Obr. 1: Model struktury IS, zdroj: [10] 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

44 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

45 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

46 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

47 uživatelské, projektové a provozní dokumentace. K tomu slouží metodiky vývoje softwaru (více v kapitole 4.4) 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

48 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

49 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