Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií
Studijní program: Aplikovaná informatika Obor: Informační systémy a technologie
Návrh realizace procesu zajištění kvality softwaru v malé firmě DIPLOMOVÁ PRÁCE
Student
:
Lukáš Langr
Vedoucí
:
doc. Ing. Alena Buchalcevová, Ph.D.
Oponent :
Ing. Rudolf Pecinovský, CSc.
2012
Prohlášení Prohlašuji, že jsem diplomovou práci zpracoval samostatně a že jsem uvedl všechny použité prameny a literaturu, ze které jsem čerpal.
V Praze dne 26. 6. 2012
................................ Jméno a příjmení studenta
Poděkování
Rád bych poděkoval doc. Ing. Aleně Buchalcevové, Ph.D. za její přínosné rady a náměty, které mi poskytla během vedení této diplomové práce.
Abstrakt Diplomová práce se zabývá problematikou zajištění kvality softwaru vyvíjeného v rámci malé firmy a dále také testováním softwaru jako prostředku pro ověřování kvality softwaru. Cílem diplomové práce je odhalení slabých míst v zajištění kvality v rámci analyzované malé firmy. Druhým cílem je pak na základě analýzy vypracování návrhu procesů a nástrojů pro zajištění kvality softwaru tak, aby tento software představoval kvalitní produkt nejen pro své uživatele ale i pro samotné vývojáře. Abych mohl navrhnout možné řešení zajištění kvality, je nejprve nutné stanovit faktory ovlivňující kvalitu softwaru a příčiny vedoucí k poklesu kvality. Této problematice společně s teoretickými základy zajištění kvality softwaru je věnována první část diplomová práce. Následně, ve druhé polovině diplomové práce, je nejprve analyzován současný stav zajišťování kvality ve firmě. Na základě této analýzy jsou navrženy patřičná opatření a nástroje, které firmě pomohou zvýšit kvalitu software.
Klíčová slova kvalita, software, zajištění kvality softwaru, testování, webové aplikace
Abstract This thesis deals with the quality assurance of software developed within a small business and also it covers software testing as a means for checking the quality of software. The goal of this thesis is to reveal weaknesses in quality assurance of software developed with particular small business and weaknesses in quality of developed software itself. The real benefit of this thesis is to provide solution to discovered weaknesses by defining appropriate activities and tools of software quality assurance. The main purpose of these suggested activities is to improve the product quality to fulfill the expectations of users and developers. At first, it is necessary to determine the factors influencing the quality of the software and the causes leading to a decline in quality. This issue, together with the theoretical bases of software quality assurance is covered in the first part of thesis. The current state of quality assurance in the company is analyzed in the second part of the thesis. Appropriate measures, activities and tools that will help improve the software quality, are recommended based on the results of this analysis in the final section of this thesis.
Keywords quality, software, software quality assurance, testing, web applications
Obsah Obsah....................................................................................................................................................... 6 1
2
3
4
Úvod ................................................................................................................................................ 1 1.1
Vymezení tématu .................................................................................................................... 1
1.2
Cíl práce ................................................................................................................................... 1
1.3
Rešerše .................................................................................................................................... 2
1.4
Předpokládaný přínos.............................................................................................................. 2
1.5
Struktura práce ........................................................................................................................ 3
1.6
Komu je práce určena.............................................................................................................. 3
Kvalita softwarových produktů ....................................................................................................... 4 2.1
Definice kvality ........................................................................................................................ 4
2.2
Dimenze kvality softwaru ........................................................................................................ 7
2.2.1
McCallův model ............................................................................................................... 7
2.2.2
Boehmův model .............................................................................................................. 8
2.2.3
Deutsch-Willisův model a Evans-Marcinakův model ...................................................... 8
2.2.4
FURPS............................................................................................................................... 9
2.2.5
Charakteristika jednotlivých dimenzí .............................................................................. 9
2.3
Softwarové chyby .................................................................................................................. 14
2.4
Příčiny softwarových chyb ..................................................................................................... 14
2.5
Náklady na kvalitu ................................................................................................................. 18
Zajištění kvality .............................................................................................................................. 21 3.1
Softwarové testování ............................................................................................................ 22
3.2
Reportování chyb .................................................................................................................. 24
Analýza současného stavu ve firmě .............................................................................................. 26 4.1
Postup při analýze ................................................................................................................. 26
4.2
Firma a její produkt ............................................................................................................... 26
4.3
Analýza na základě potencionálních příčin chyb ................................................................... 28
4.3.1
Definování požadavků ................................................................................................... 28
4.3.2
Komunikace s klientem.................................................................................................. 29
4.3.3
Úmyslné odchylky od požadavků .................................................................................. 31
4.3.4
Návrh aplikace ............................................................................................................... 32
4.3.5
Zdrojový kód .................................................................................................................. 33
4.3.6
Zásady pro psaní kódu ................................................................................................... 35
4.3.7
Proces testování ............................................................................................................ 36
4.3.8
Procedury v procesu vývoje........................................................................................... 39
4.3.9
Dokumentace ................................................................................................................ 43
4.4
4.4.1
Bezpečnost .................................................................................................................... 45
4.4.2
Přístupnost .................................................................................................................... 48
4.5 5
6
Analýza dimenzí softwarového produktu ............................................................................. 45
Závěr analýzy ......................................................................................................................... 50
Navrhovaná řešení......................................................................................................................... 51 5.1
Omezení................................................................................................................................. 51
5.2
Počáteční fáze........................................................................................................................ 52
5.2.1
Specifikace požadavků................................................................................................... 52
5.2.2
Formální specifikace procesu vývoje ............................................................................. 53
5.2.3
Zdrojový kód a konvence............................................................................................... 54
5.2.4
Dokumentace a báze znalostí ........................................................................................ 55
5.2.5
Nová verze systému....................................................................................................... 56
5.3
Proces zajištění kvality........................................................................................................... 57
5.4
Testování ............................................................................................................................... 58
5.4.1
Doporučené testovací techniky ..................................................................................... 59
5.4.2
Reportování chyb .......................................................................................................... 62
5.4.3
Chyby při provozu systému ........................................................................................... 63
5.5
Metriky vyhodnocování kvality ............................................................................................. 65
5.6
Nástroje ................................................................................................................................. 66
Závěr .............................................................................................................................................. 70
Citovaná literatura................................................................................................................................. 72 Seznam obrázků a tabulek..................................................................................................................... 76
1 Úvod Trh se softwarovými produkty je vysoce konkurenční prostředí, obzvláště v případě webových aplikací. Softwarové firmy si musí vydobýt své místo na trhu a také si jej udržet. Jednou z možných cest je jistě poskytování kvalitních produktů, což však nemusí být tak snadné, jak by se mohlo na první pohled zdát. Problémy s kvalitou produktů nastávají již během definice požadavků zákazníkem, který obvykle nemá přesnou představu o tom, co si od požadovaného softwaru slibuje. Zákazník se také nemusí orientovat v problematice vývoje softwaru, to znamená, že, není například schopen přesně definovat technické parametry poptávaného produktu. A když není softwarový produkt přesně definován, lze jen obtížně měřit jeho kvalitu. V takovém případě totiž není nastavena laťka, vůči které má být kvalita vyhodnocena. Za kvalitu je však také zodpovědný i dodavatel, který by měl udělat vše proto, aby vyvíjený software dosáhl maximálních kvalit. Bohužel se ale setkáme spíš s tím, že dodržení termínů má přednost před zajištěním kvality. Z výše uvedených důvodu jsem se proto rozhodl ve své diplomové práci zaměřit na problematiku zajišťování softwarové kvality a využít teoretické poznatky z této oblasti ke zlepšení kvality konkrétního softwarového produktu vyvíjeného malou firmou.
1.1 Vymezení tématu Práce se věnuje problematice kvality softwaru a kvalitě procesu vývoje softwaru v rámci malé firmy. Jakožto vývojář webových aplikací působící v této firmě si uvědomuji určité nedostatky v oblasti vývoje i v samotné kvalitě vyvíjeného produktu (systém pro správu obsahu). Vzhledem k velikosti firmy je většina procesů prováděna intuitivně a dle mého názoru není přikládán dostatečný význam specifikaci požadavků a ověřování jejich naplnění před nasazením softwaru do ostrého provozu. Mým záměrem je zhodnotit současnou situaci ve firmě z pohledu kvality vyvíjeného produktu a na základě získaných poznatků navrhnout možná doporučení, která by zlepšila kvalitu procesu vývoje a do budoucna zajistila kontinuální zlepšování kvality nastavením aktivit zajišťující kvalitu softwaru.
1.2 Cíl práce Práce je primárně zaměřena na zajištění kvality softwarového produktu vyvíjeného malou firmou. Aby se mi podařilo dosáhnout předpokládaných přínosů, stanovil jsem pro svou diplomovou práci následující cíle: 1.
Odhalení slabých míst, snižující kvalitu softwarového produktu vyvíjeného v malé firmě
Na základě teoretických poznatků z oblasti zajišťování kvality softwaru analyzuji současný stav ve firmě s cílem odhalení slabých míst, která mají negativní vliv na kvalitu vyvíjeného softwarového produktu. Cíle bude dosaženo formou analýzy samotného softwarového produktu, podnikových procesů, používaných nástrojů a dalších faktorů podílejících se na kvalitě výsledného produktu. Výstupem pak bude samotná analýza, která poslouží pro účely druhého cíle.
1
2.
Návrh zajištění kvality softwaru na základě zpracované analýzy
Na základě identifikovaných problémů snižujících kvalitu vyvíjeného softwaru budou navrženy opatření proti odhaleným nedostatkům zahrnující úpravy v softwaru a v samotném procesu jeho vývoje. Zároveň bude poskytnut návrh, jak zajištovat kvalitu softwarového produktu do budoucna.
1.3 Rešerše Diplomová práce se zabývá problematikou zajišťování kvality softwaru v malé firmě, kvalitou softwarových produktů obecně a testováním jako jedním z nástrojů pro zajišťování kvality. Na tato témata jsem se zaměřil při hledání dostupných zdrojů a inspirace pro diplomovou práci. Jako velice přínosnou publikaci shledávám knihu Daniela Galina Software Quality Assurance: From Theory to Implementation [1], ve které je poskytnut přehledný úvod do oblasti zajišťování kvality softwaru. Kniha je založená na zkušenostech autora (konzultace, vyučování), který dlouhodobě působí v oblasti zajišťování kvality. Informace uvedené v knize mi posloužily jako bohatý zdroj inspirace pro teoretickou část diplomové práce i pro samotnou analýzu softwarového produktu. Problematice zajišťování kvality v rámci malého podniku se ve svém diplomové práci Zlepšování softwarových procesů v oblasti testování [2] práci zabýval i Ing. Jakub Libík. Jeho práce vyhodnocuje přínosy normy ISO/IEC 29110 Life-Cycle Profiles for Very Small Entities, která je určena pro posuzování a zlepšování procesu vývoje softwaru a testování ve velmi malých podnicích. Podobnou problematikou se ve své práci zabývá i Ing. Tomáš Fiurášek. Ten ve své diplomové práci Návrh metodiky testování webových aplikací [3] však poukazuje na přínosy metodiky OpenUP a její praktické využití při testování softwaru. Obě výše uvedené metodiky jsou vhodné pro použití v rámci malé firmy. V rámci diplomové práce je analyzována kvalita webová aplikace, její vývoj a způsob testování. Problematiku testování webových aplikací přehledně zachycuje diplomová práce Mgr. Anny Borovcové Testování webových aplikací [4]. V práci je popsáno, na jaké oblasti se při testování webové aplikace zaměřit a jakým způsobem je otestovat. Je zde uveden i přehled nástrojů, které usnadňují testování webových aplikací. Poznatky uvedené v této práci lze využít při navrhování technik pro testování analyzovaného softwarového produktu. V souvislosti s testováním stojí také za pozornost kniha Lessons Learned in Software Testing [5], jejímiž autory jsou přední odborníci v oblasti testování. Kniha je psána formou krátkých lekcí, ve kterých autoři publikace reflektují své zkušenosti získané při testování softwaru. Na příkladech z praxe je názorně vysvětlen dopad různých přístupů k testování. Autoři v knize dále poskytují své tipy a triky, jak učinit testování softwaru efektivnějším.
1.4 Předpokládaný přínos Vlastním přínosem diplomové práce je především analýza současného stavu zajištění kvality konkrétního softwarového produktu vyvíjeného malou firmou. Tato analýza mi poslouží pro odhalení slabých míst v procesu vývoje a zajišťování kvality softwarového produktu. Druhým předpokládaným přínosem by pak měl být návrh realizace procesu zajištění kvality v dané firmě společně s dalšími doporučeními, jak zvýšit kvalitu vyvíjené aplikace. V konečném důsledku pak očekávám samotné zlepšení kvality softwarového produktu.
2
Úvodní část diplomové práce obsahuje teoretický úvod do problematiky kvality software, negativní faktorech ovlivňujících kvalitu softwaru a procesu zajišťování kvality. Předpokládaným přínosem této části je poskytnutí základního přehledu z výše uvedené problematiky.
1.5
Struktura práce
Diplomovou práci jsem rozdělil do tří větších částí. První část je věnována teoretickému úvodu do problematiky softwarové kvality, příčin nízké kvality softwaru, procesu zajišťování kvality a v neposlední řadě problematice testování při vývoji softwaru. Ve druhé části je rozebrána kvalita softwarového produktu vyvíjeného malou firmou, přičemž je kladen důraz především na problémová místa, která mohou snižovat celkovou kvalitu softwaru. V závěru práce jsou poskytnuty návrhy, jak řešit současné problémy odhalené při analýze včetně návrhu procesu zajištění kvality.
1.6 Komu je práce určena Práce je určena především malým podnikům, které se zabývají vývojem softwarových produktů a které usilují o zvýšení kvality svých produktů. Vzhledem k tomu, že jsem pro praktickou část své diplomové práce vybral firmu, jež se zabývá vývojem webových aplikací, jsou některé poznatky a závěry ovlivněny speciálními požadavky plynoucích z vývoje webové aplikace. Přesto však věřím, že většina poznatků je aplikovatelná na libovolný softwarový produkt či je lze zobecnit. Dále se předpokládá, že čtenář této diplomové práce bude člověk znalý problematiky softwarového inženýrství, nebo který se alespoň trochu orientuje v základní terminologii používané při vývoji aplikací.
3
2 Kvalita softwarových produktů Kvalita softwarového produktu může svému tvůrci softwaru přinášet znatelnou konkurenční výhodu nebo také naopak. Je velice snadné rozeznat špatnou kvalitu produktu, protože v takovém případě produkt obvykle nesplňuje naše očekávání, nedělá to, co by dělat měl. Už je však velmi obtížné určit, do jaké míry je produkt kvalitní. Málokdo z nás je schopen vyjádřit svá očekávání a na jejich základě stanovit přesnou kvalitu a to zejména proto, že kvalita se velice obtížně definuje i měří. V kvalitě softwarového produktu se navíc odráží více faktorů, přičemž jejich důležitost je závislá na tom, kdo ji hodnotí. V rámci této části diplomové práce je čtenář uveden do problematiky definice kvality, jejích dimenzí v souvislosti se softwarovým produktem (webovou aplikací) a příčinami, které mohou stát za nižší kvalitou softwaru.
2.1
Definice kvality
Pojem kvalita je hojně využíván, ale málokdy je jednoznačně definován. Každý z nás má o pojmu kvality vlastní představu. Lidé většinou rozlišují kvalitu výrobků na dobrou, špatnou či „něco mezi tím“, čímž vyjadřují svou spokojenost s výrobkem. Může však pro ně být již obtížné vyjádřit, co přesně mají na mysli dobrou či špatnou kvalitou. V odborné literatuře se lze nejčastěji setkat s následujícími definicemi kvality:
Doktor Joseph M. Juran, který stál u zrodu totálního řízení kvality1, definuje kvalitu jako „Fitness for use” [6, s. 32]; tedy jako vlastnost produktu či služby, která určuje, do jaké míry jsou tyto produkty vhodné pro použití.
V britských standardech, konkrétně v British Standard 4778, je uvedena následující definice kvality: „The totality of features and characteristics of a product that bear on its ability to satisfy a given need“ [7, s. 190]. Dle této definice představuje kvalita „souhrn funkcí a vlastností produktu, které se podílejí na jeho schopnosti plnit určitou potřebu“.
Expert na řízení kvality, Philip B. Crosby, považoval kvalitu za známku shody vlastností produktu s požadavky - „Conformance with requirements” [8, s. 26]
Dle Armanda V. Feigenbauma, průkopníka totální kontroly kvality2, lze kvalitu definovat takto: „The total composite product and service characteristics of marketing, engineering, manufacturing and maintenance through which the product and service in use will meet expectations of the customer” [7, s. 190]. Což volně přeloženo znamená: „Celková kombinace charakteristik produktu či služby zahrnující oblasti marketingu, návrhu, výroby a údržby, jejichž prostřednictvím plní produkt či služba očekávání zákazníka.“
1
Total Quality Management – komplexní a strukturovaný přístup řízení organizace, který usiluje o zlepšení kvality produktů a služeb prostřednictvím neustálých úprav a drobných korekcí organizačních procesů. Tyto změny reagují průběžně na zpětnou vazbu plynoucí ze stávající situace. 2 Total Quality Control – zaměřuje se na detailní zkoumání procesů organizace za účelem odhalení slabých míst, která mohou snižovat kvalitu produktu.
4
Gerald M. Weinberg, který se specializuje na kvalitu v oblasti softwarového inženýrství, považuje kvalitu za určitou hodnotu, kterou má produkt pro konkrétní osobu. Tato hodnota je subjektivní a vychází z požadavků, které jsou na produkt kladeny uživatelem. - „Quality is relative; quality is value to some person. Value is what people are willing to pay to have their requirements met.” - Gerald M. Weinberg [9, s. 126]
Před vyvozením obecné definice kvality, je třeba upozornit na častý problém při určování kvality produktu, kdy je kvalita hodnocena oproti specifikaci. Je důležité si uvědomit, že shoda produktu, nejen softwarového, se specifikací nemusí vždy signalizovat kvalitní produkt. Specifikace nemusí zachytit všechny požadavky zákazníků, uživatelů. Či již v samotné specifikaci může být chyba, která se neslučuje s požadavky, ač tato specifikace vznikla na základě konzultace se zákazníkem, případně i budoucími uživateli. V souvislosti s kvalitou softwaru bývá často citována právě poslední ze zmíněných definic. Přesto se ale všechny výše uvedené definice v zásadě od sebe příliš neliší. Shodují se v tom, že kvalita je hodnota plynoucí z vlastností a funkčnosti produktu. Tato hodnota je vždy relativní, protože její výše vyplývá z naplnění očekávání a požadavků konkrétního uživatele produktu. Stručně lze říci, že kvalita představuje hodnotu, kterou má daný produkt pro určitou osobu. Tato osobu je takzvaným stakeholderem kvality neboli zainteresovanou stranu hodnotící kvalitu. Pojem stakeholder byl poprvé v oblasti managementu představen v roce 1963 ve Standfordu (Stanford Research Institute) a označoval „skupinu lidí, bez jejichž podpory by určitá organizace přestala existovat“ [10, s. 89]. Později, v 80. letech, vybudoval R. Edward Freeman kolem pojmu stakeholder celou manažerskou teorii, přičemž upřesnil i jeho samotnou definici. Freemen ve své knize „Strategic Management: A Stakeholder Approach“ uvádí, že „stakeholder je jednotlivec či skupina osob, které ovlivňují nebo jsou ovlivňovány činností organizace" [11, s. 46]. V kontextu softwarové kvality jsou stakeholdeři osoby, které mají požadavky, ať již přímé či nepřímé, na vyvíjený software. Na první pohled by se mohlo zdát, že v případě kvality softwaru je zainteresovanou osobou pouze klient. To on definuje požadavky na systém, na základě kterých je pak hodnocena kvalita jako míra naplnění požadavků. Klient však definuje pouze základní požadavky, které jsou důležité jen pro něho samotného. Při bližším pohledu zjistíme, že na specifikování požadavků na software se přímo i nepřímo podílí více stran. Pří specifikaci požadavků, které budou mít vliv na celkovou kvalitu softwarového produktu, je vhodné vymezit si, kdo je stakeholderem jednotlivých faktorů a jaké jsou přesně jeho požadavky. Na základě mých zkušeností s vývojem aplikací jsem odvodil pět základních typů stakeholderů, kteří jsou nejčastějšími zdroji požadavků na vyvíjený software:
5
Stakeholder
Popis Iniciátor a sponzor vývoje softwarového produktu. Formuluje klíčové požadavky (základní funkcionalitu a vlastnosti) na aplikaci.
Zákazník Od aplikace očekává: Vyřešení problému za přijatelnou cenu Koncový uživatel vyvinuté aplikace. Zde je velice důležité si uvědomit, že ne vždy bývá zákazník i koncovým uživatelem aplikace, což platí dvojnásobně v případě webových aplikací. Uživatel
Od aplikace očekává: Snadné osvojení práce s aplikací Efektivní používání Usnadnění své práce Jako tvůrce aplikace pohlíží na kvalitu aplikace z jiné strany než její uživatel. Zajímají ho použité technologie, struktura aplikace, čitelnost zdrojového kódu, míra abstrakce či modularita, dostupnost dokumentace a podobně.
Vývojář
Od aplikace očekává: Jednoduchý návrh Snadnou údržbu Znovupoužitelnost částí aplikace Přiděluje a řídí příslušné zdroje pro vytvoření aplikace poptávané zákazníkem.
Management
Stát
Od aplikace očekává: Dosažení zisku prodejem aplikace Uspokojení potřeb zákazníků za přijatelné náklady na vývoj a údržbu I samotný stát může klást požadavky na vyvíjenou aplikaci. Při vývoji určitých aplikací můžeme narazit na jistá zákonná omezení, které je aplikace povinna dodržovat. Typickým příkladem je situace, kdy aplikace zpracovává osobní údaje, a proto se musí řídit se zákonem o ochraně osobních údajů. Nebo rozesílá-li aplikace obchodní sdělení, je nutné dodržet zákon č. 480/2004 Sb., o některých službách informační společnosti. Od aplikace očekává: Dodržení stanovených norem a zákonů Tabulka 1 - Stakeholdeři softwarového produktu (zdroj: autor)
Jak je patrné z výše uvedené tabulky, každý ze stakeholderů hodnotí kvalitu produktu ze svého vlastního pohledu. To, co může jedna skupina shledávat důležitým při ocenění kvality, je pro druhé na první pohled nepodstatné. Přesto se ale v konečném důsledku zajištění kvality v jednom z aspektů promítne i do ostatních. Plní-li software očekávání vývojáře, může jej dotyčný vývojář snáze rozšířit. Je-li snazší program upravovat či udržovat, je spokojený i manažer, protože náklady (časové i finanční) se v takových případech drží v rozumné míře. V konečném důsledku je spokojený i uživatel i zákazník, který dostane své požadované rozšíření aplikace včas a za rozumnou cenu.
6
2.2
Dimenze kvality softwaru
V předchozí kapitole jsem definoval na obecné úrovni kvalitu softwarového produktu a její stakeholdery. Je patrné, že kvalitu lze v případě produktu jen obtížně měřit jako celek. Každý ze stakeholderů hodnotí kvalitu v jiných faktorech. Celková kvalita softwaru je v konečném důsledku ovlivněna mnoho faktory. V základu rozdělit kvalitu softwaru na vnější a vnitřní. Vnější kvalitu ocení především koncový uživatel, protože je určena charakteristikami softwaru, které se vztahují k jeho používání. Naopak faktory vnitřní kvality jsou důležité pro vývojáře. Pokud kvalitu chceme skutečně měřit a vyhodnocovat musíme však přistoupit k detailnějšímu dělení charakteristik softwaru. V této podkapitole proto detailněji rozeberu jednotlivé dimenze, které se podílejí na celkové kvalitě softwaru. 2.2.1
McCallův model
V literatuře věnované softwarové kvalitě je uvedeno hned několik modelů, které kvalitu softwarového produktu dělí do různých faktorů. Jeden z prvních významnějších modelů dimenzí softwarové kvality je McCallův model, který byl definován Jimem McCallem v roce 1977. Cílem McCallova modelu bylo překlenout propast mezi uživateli a vývojáři softwaru. Tato propast spočívala především v různých prioritách při určování kvality softwaru. Model dělí faktory kvality do tří perspektiv, ve kterých se nachází celkem 11 faktorů kvality [1, s. 37]:
Činnost produktu – Skupina vlastností, které vypovídají o tom, zda produkt dělá to, co má a zda to dělá ve správnou dobu, bezpečně a efektivně. o Korektnost - do jaké míry aplikace naplňuje požadavky, splňuje specifikaci a uživatelovy záměry. o Spolehlivost – pravděpodobnost, že aplikace bude plnit požadované funkce a neselže při jejich provádění. o Efektivita – jak aplikace využívá přidělené zdroje při provádění operací. Zda neplýtvá zbytečně operačním výkonem, úložným prostorem a nepřetěžuje komunikačních kanály. o Integrita – zajištění softwaru před neoprávněným použitím, zajištění bezpečnosti dat. o Použitelnost – jak snadno se uživatel s programem naučí pracovat a jak snadno se program ovládá.
Revize produktu – Do této skupiny řadí McCall faktory, které ovlivňují údržbu aplikace zahrnující opravu aplikace, její přizpůsobení novým podmínkám bez nutnosti úprav či implementaci nové funkcionality. o Udržovatelnost – vyjadřuje, jak složité je odhalit případnou chybu v aplikaci, opravit ji a ověřit, že tato oprava byla opravdu úspěšná. o Flexibilita – úsilí potřebné k úpravám softwaru. o Testovatelnost – do jaké míry usnadňuje aplikace testerovi její otestování tak, aby byl schopen ověřit, že aplikace plní požadované funkce.
Přemístění produktu – Zahrnuje vlastnosti vypovídající o možnostech provozování aplikace na různých platformách, propojení s jinými aplikacemi a v neposlední řadě také využití částí aplikace v jiných programech.
7
o o o
2.2.2
Přenositelnost – možnosti softwaru přizpůsobit se změnám prostředí, na kterém je provozován (hardware, operační systém, atd.)s Znovupoužitelnost – možnost využití modulů či částí aplikace v jiných projektech. Schopnost spolupráce – jak je aplikace připravena na spolupráci s jinými aplikacemi, disponuje-li aplikačním rozhraním.
Boehmův model
Rok po McCallově modulu přichází Barry W. Boehm s podobným modelem kvality. Podobně jako McCall i Boehm rozděluje charakteristiky softwaru do hierarchické struktury. V nejvyšší úrovni Boehmova modelu jsou definovány tři základní faktory [12, s. 67]:
Užitečnost – do jaké míry může být software použit a jak je užitečný. Do této skupiny řadí Boehm spolehlivost (program pracuje, tak jak má, bez chyb), efektivitu (optimální využití systémových zdrojů během provozu aplikace) a použitelnost (jak snadno se software ovládá)
Udržovatelnost – s jakou snadností lze odhalit, co je potřeba v softwaru upravit a stejně tak, jak lehce lze tuto změnu provést a otestovat. Zde nalezneme testovatelnost (úsilí potřebné k validaci naplnění požadavků), srozumitelnost (do jaké míry je účel software a jeho struktura srozumitelná z pohledu jeho tvůrce) a upravitelnost (jak obtížné je implementovat nové požadavky do již existujícího softwaru).
Přenositelnost – připravenost softwaru na jiné provozní prostředí. To znamená především soběstačnost a nezávislost na hardwaru či jiném softwaru.
2.2.3
Deutsch-Willisův model a Evans-Marcinakův model
Mezi dalšími alternativními modely se řadí například model definovaný M. W. Evansem společně s J. J. Marciniakem (1987) [13] či Deutsch-Willisův model (1988) [14]. Tyto modely jsou opět velice podobné McCallově modelu, oproti kterému ale nezahrnují testovatelnost. Do dělení charakteristik softwaru však vnášejí zároveň několik, do té doby v jiných modelech nezahrnutých specifik:
ověřitelnost (verifiability) – zahrnuje vlastnosti softwaru, které umožňují jeho efektivní verifikaci neboli ověření vůči specifikaci. Ověřitelnost softwaru je ovlivněna jeho strukturou, složitostí anebo také dodržováním dohodnutých konvencí při jeho implementaci či soulad s dokumentací.
rozšiřitelnost (expandability) – reflektuje, jaké úsilí bude v budoucnu potřeba pro rozšíření aplikace a její optimalizaci s cílem zlepšit její použitelnost. Tyto charakteristiky jsou v McCallově modelu do jisté míry zahrnuty ve faktoru flexibility.
bezpečnost (safety) – schopnost softwaru vyrovnat se s neočekávanou událostí, která představuje bezpečnostní riziko (např. různé bezpečnostní mechanismy, pojistky nebo alespoň systém varování).
spravovatelnost (manageability) – odkazuje na podpůrné administrativní aspekty a nástroje softwaru, které usnadňují jeho nasazení a provoz (údržbu). Zahrnuje například monitoring systému a správu konfigurace.
8
2.2.4
odolnost, přežití (survivability) – schopnost systému vyrovnat se neočekávanou situací, chybou aniž by došlo k pádu celé aplikace. Odolný software musí být schopen poskytnout nepřetržitý provoz. Udává se v minimální dovolené době mezi jednotlivými pády systému a v maximálně době určené pro obnovení systému po jeho pádu. Nejblíže k tomuto faktoru má v rámci McCallova modelu spolehlivost (reliability) systému. FURPS
V současné době hojně využívaným modelem je také FURPS. Za jeho vytvořením stojí společnost Hawlett-Packard. Ta potřebovala stanovit, na základě čeho rozpoznat a ověřit kvalitu dodávaného softwaru. V roce 1992 Robert Grady tedy přichází s novým modelem, jehož název je odvozen od prvních písmen pěti hlavních charakteristik softwaru [15]:
Funkčnost (functionality) – hlavní funkce a schopnosti softwaru, zahrnuje také požadavky z oblasti bezpečnosti. Použitelnost (usability) – celkový dojem, kterým aplikace působí na uživatele z pohledu jejího vzhledu, uživatelského ovládání či dostupnosti dokumentace, nápovědy a dalších aspektů, které usnadňují práci s aplikací. Spolehlivost (reliability) – jak spolehlivý je systém. Obvykle uváděno pomocí frekvence výskytu selhání v aplikaci a jejich závažnosti. Do spolehlivosti se promítá také schopnost aplikace obnovit se pádu či přesnost výstupů. Výkonnost (performance) – hodnotí efektivitu operací prováděných aplikací skrze rychlost, odezvu, využití zdrojů, dostupnost, aj. Podpora (Supportability) – zahrnuje vlastnosti vypovídající o možnostech rozšiřitelnosti aplikace, její údržby, testovatelnosti, přizpůsobení se změnám, možnosti konfigurace, kompatibility, jazykové lokalizace, škálovatelnosti a jiných.
Model FURPS byl později rozšířen o několik dalších faktorů, čímž vznikla nová podoba tohoto modelu označovaná jako FURPS+. Přidané faktory ve skutečnosti reprezentují určitá omezení, která mohou být v rámci požadavků na software kladena [16]:
2.2.5
Návrhová omezení (design constraints) – omezení v možnostech návrhu aplikace například ve stanovení požadavku na použití relační databáze pro daný software Implementační omezení (Implementation constraints) – omezení v možnostech implementace. Zahrnuje například dodržování určitých standardů, platforem či konkrétního programovacího jazyka. Omezení rozhraní (Interface constraints) – pokud má aplikace spolupracovat s jiným externím systémem, musí se přizpůsobit jeho komunikačním kanálům a protokolům. Fyzická omezení (Physical constraints) – omezení vztahující se na zařízení, na kterém bude software provozován. Toto omezení se zejména týká softwaru určeného pro speciální případy (armádní technika, letectví, aj.). Zde mohou být například stanoveny maximální rozměry a hmotnost zařízení, které nedovolují použití výkonnějšího procesoru a software musí být optimalizován pro procesor s menším výkonem. Charakteristika jednotlivých dimenzí
Protože jsou klíčové charakteristiky softwaru u jednotlivých modelů podobné, uváděl jsem z důvodu přehlednosti pouze stručný popis těchto faktorů. V této podkapitole se zaměřím na 9
jednotlivé dimenze definované ve výše uvedených modelech a detailněji přiblížím jejich význam ve vztahu ke kvalitě softwarového produktu. Při rozdělení faktorů do ucelenějších skupin jsem vycházel z modelu FURPS. Do skupin jsem zahrnul i faktory z jiných modelů a doplnil jsem několik vlastních, které, dle mého názoru, v případě softwarové kvality stojí za zmínku. Funkcionalita Funkcionalita – Tato dimenze zahrnuje všechny vlastnosti a funkce, které by měla aplikace být schopna provádět. Požadavky na funkcionalitu softwaru definuje objednavatel a případně také budoucí uživatelé aplikace. Bezpečnost - Jsou data zpracovávaná aplikaci zabezpečena před zcizením či úmyslným i neúmyslným znehodnocením? Kdo má k datům přístup a co s nimi provádět? To vše je řešeno v rámci bezpečnostní dimenze. Zabezpečená aplikace kontroluje vstupní parametry, disponuje mechanismy proti známým typům neoprávněným průnikům do aplikace a v neposlední řadě je také schopna vyrovnat se bezpečnostní incidentem (například obnova dat ze zálohy). Použitelnost Použitelnost (Usability) - Použitelnost označuje jednoduchost použití aplikace. Jedná se o obtížně měřitelný faktor kvality vzhledem k jeho subjektivnímu charakteru. Do jednoduchosti používání aplikace se promítá, jak snadno se aplikace ovládá či jak rychle a s jakými obtížemi se uživatele v aplikaci zorientují. Vliv na použitelnost má také dostupnost uživatelské dokumentace a její kvalita. V neposlední řadě je mimo jiné důležité, jak aplikace uživateli prezentuje neočekávané události (srozumitelnost chybových hlášení, řízení výjimek a možnost obnovy po selhání aplikace). Přístupnost (accessibility) – Charakteristika důležitá zejména v oblasti webových aplikací, při jejichž vývoji je nutné si uvědomit, že ne všichni uživatelé budou k aplikaci přistupovat skrze jeden konkrétní internetový prohlížeč. Těchto prohlížečů existuje celá řada a každý z nich může uživateli interpretovat aplikaci rozdílně. Je také rozdíl, zda uživatel pracuje s aplikací v mobilu nebo na desktopu (rozlišení obrazovky, podpora javascrptu, flashe, aj technologií). Mimo tyto technologické rozdílnosti mohou mít na webové aplikace speciální požadavky například uživatelé, kteří trpí nějakým handicapem. Například nevidomí uživatelé obvykle používají speciální čtečku internetových stránek, která jim obsah stránek předčítá. Přístupnost vypovídá o tom, zda je software přístupný jeho uživatelům či jaké existují bariéry jeho použít z pohledu uživatele. Uživatelská dokumentace – Tvrdí se, že z hlediska použitelnosti je nejlepší takový software, jehož uživatel se při jeho provozu obejde bez dokumentace. Pokud lze ovládat software bez nutnosti konzultace s manuálem je to jistě známka dobré kvality. Ovšem je vysoce pravděpodobné, že alespoň jednou se uživatel při používání aplikace dostane do situace, kterou bez návodu nebude schopen vyřešit. Uživatelský manuál může také dobře posloužit jako seznam všech vlastností a funkcí, kterými je aplikace vybavena a na které by sám uživatel nemusel přijít (různé klávesové zkratky, pokročilá nastavení, aj.). Uživatelská dokumentace může zároveň posloužit jako první pomoc v případě, že aplikace nefunguje správně. Může obsahovat řešení nejčastějších problémů, specifikaci minimálních požadavků, optimální nastavení společně s jeho vysvětlením nebo kontakt na technickou podporu atd.
10
Účinnost a výkon softwaru Účinnost (Efficiency) – Jak optimálně využívá software dostupné zdroje. Rychlost, odezva - Jak rychle aplikace reaguje na uživatelovy příkazy. Odezva aplikace je snadno měřitelná. Jedná se o čas, který uplyne mezi inicializací operace uživatelem a doručením výsledků operace uživateli. Odezva aplikace je určena její náročností na výpočetní výkon, diskové operace (rychlost čtení, zápisu na disk) a v případě klient-serverové aplikace i odezvou a propustností sítě mezi klientem a serverem. Rychlost webových aplikací je také závislá na objemu přenášených dat mezi serverem a klientem. Spotřeba paměti - Kolik místa zabírá aplikace v paměti (RAM) a na disku. Důležité jsou především extrémní hodnoty, tzv. špičky, ke kterým dochází při náročnějších operací aplikace. Při diskových operacích by nás měla mimo velikosti dat také zajímat frekvence přístupu k datům na disku. Neoptimalizované procesy při práci s daty se mohou značně promítnout na výkon celé aplikace. Využívání sítě - Jak již bylo zmíněno výše, rychlost klient-serverové aplikace z části závisí na rychlosti přenosu dat po síti. Ta je ovlivněna nejen odezvou a propustností sítě, ale i optimalizací samotné komunikace mezi serverem a klientem. Pokud klient navazuje se serverem zbytečně spojení, ať již z důvodu neoptimalizovaných dotazů na server nebo opakovaného stahování duplicitních dat, dochází zároveň k nežádoucímu snížení rychlosti aplikace a nárůstu objemu přenesených dat. Výší datová náročnost může být v případě mobilní aplikace zásadní problém, neboť uživatel mobilního zařízení bývá mnohdy omezen svým operátorem (zprostředkovatelem mobilního připojení). Optimalizovat komunikaci mezi klientem a serverem lze například pomocí tzv. cachování3. Energetická spotřeba - Tímto faktorem je důležité se zabývat především při vývoji aplikací pro mobilní zařízení, jejichž provoz je přímo závislý na baterii. Do energetické spotřeby aplikace se promítá, jak náročné operace provádí, frekvence využívání bezdrátových komunikačních prostředků, využití displeje či reproduktorů. Optimalizaci energetické náročnosti lze však také řešit i u serverových aplikací z důvodů ušetření nákladů na provoz serverů. Škálovatelnost - Jak je aplikace připravena na změnu parametrů například v podobě náhlého zvýšení počtu uživatelů, nárůstu objemu zpracovávaných dat a podobně. Je to schopnost aplikace pružně reagovat na tyto situace. Spolehlivost Stabilita - Jak často je nutné upravovat aplikaci, aby se vyřešily problémy s jejím používáním. Nestabilní software je pro uživatele znakem špatné kvality a v mnohých případech jej odrazuje od dalšího využívání aplikace. Pro vývojáře nestabilita aplikace poukazuje na nedokonalou implementaci aplikace či na nedostatečné testování aplikace při jejím vývoji a v některých případech i nutnost přepracovat část aplikace znovu od základu. Robustnost - Jak často aplikace přestává reagovat na uživatelovy pokyny či dokonce dochází k pádům celé aplikace. Jak je aplikace schopna zvládat extrémní podmínky například v podobě nedostatku výpočetních prostředků (nedostatek paměti, místa na disku, výpadek sítě), selhání komponent třetích stran a podobně.
3
Z anglického slova cahce, které v oblasti IT označuje vyrovnávací paměť, jejímž úkolem je urychlit přístup k často používaným datům.
11
Determinismus (určitost, předpověditelnost, opakovatelnost) - Software je deterministický, pokud pro stejné vstupní parametry vrací vždy stejné výstupní hodnoty. Různé chování aplikace při stejných operací může být pro uživatele velice matoucí. Nedeterministické chování se také velice špatně odhaluje.
Podpora Udržovatelnost (Maintainability) - Jak snadno lze software rozšířit o novou funkcionalitu či jak rychle lze odhalit příčinu chyb a poskytnou jejich opravu. Jak obtížné je pro nového vývojáře porozumění zdrojovému kódu. Zpětná kompatibilita - Může uživatel použít novou verzi aplikace bez nutnosti složitě migrovat data ze staré verze do nové? Testovatelnost (Testability) - Jak snadno lze otestovat různé části aplikace, jednotlivé funkce či větve zdrojového kódu. Testovatelnost je úzce spjata s architekturou aplikace a strukturou zdrojového kódu. Zahrnuje například diagnostické nástroje vložené přímo v aplikaci, které jsou schopny zjistit, zda aplikace pracuje správně či zda nedošlo k nějaké chybě. Je velice obtížné zvyšovat testovatelnost u již existujícího softwaru, protože optimalizace testovatelnosti by si vyžádala časově i finančně náročné úpravy zdrojového kódu. Proto je důležité věnovat pozornost této problematice již během úvodní fáze vývoje. To znamená zvolit vhodnou softwarovou architekturu a vývojovou metodiku, či nepodcenit návrh aplikace. Pokrytí kódu testy (Test coverage) - Jednotlivé testy aplikace mohou pokrývat její různé části. Ne vždy testy pokryjí veškeré stavy a funkce aplikace. Důvodem, proč testy nepokrývají 100% zdrojového kódu aplikace, bývá obvykle komplexita aplikace a složité větvení kódu na základě různých vstupních parametrů. Pokrytí zdrojového kódu testy vyjadřuje, jak velká část kódu byla při testování skutečně vykonána. Pokrytí lze vyjádřit poměrem celkového počtu řádků zdrojového kódu a počtu provedených řádku při testování, počtem otestovaných funkcí. Programátorská dokumentace - Je dostupná uživatelská či programátorská dokumentace k aplikaci? V jakém rozsahu a kvalitě? Lze se setkat i s názorem, že kvalitní aplikace uživatelskou dokumentaci nepotřebuje, neboť kvalitní aplikace se ovládá intuitivně. Programátorskou dokumentaci může do jisté míry nahradit okomentovaný zdrojový kód a vhodně zvolené názvy metod, funkcí a proměnných. Čitelnost zdrojového kódu - Jak snadná je orientace ve zdrojovém kódu aplikace. Existují pravidla pro psaní zdrojového kódu a jsou dodržována všemi členy vývojového týmu? Vyzná se vývojář v kódu jiného vývojáře. Stručnost zdrojového kódu - Obzvláště při práci na větších projektech v týmu může aplikace obsahovat duplicitní zdrojový kód nebo již nepoužívané zastaralé fragmenty kódu. Čím více zdrojového kódu aplikace obsahuje, tím je nepřehlednější a náchylnější k chybám, obzvláště pokud kód navíc není opodstatněný. Přenositelnost (Portability) – Vypovídá o tom, zda lze aplikaci provozovat na různých platformách, zda ji lze provozovat na 32bitovém i 64bitovém stroji, zda podporuje více operačních systémů či zda se zobrazuje stejně ve všech webových prohlížečích. Pokud aplikaci nelze bez úprav přenést, hodnotí se, jak složitá by byla úprava aplikace, aby ji bylo možné provozovat i jinde.
12
Lokalizovatelnost (localizability) – Jak je software připravený na použití v jiném regionálním prostředí. Lokalizovatelný software umožňuje bez zásahu do zdrojového kódu změnit použitý jazyk (uživatelské prostředí) a zároveň se přizpůsobit i dalším regionálním podmínkám jako například různé formátování čísel (použití tečky nebo čárky pro oddělení desetinného místa). Modularita (Modularity) – Referuje velikost ucelených stavebních jednotek softwaru, na které je možné software rozdělit. Mohou to být třídy, balíčky nebo logické bloky, jež dohromady spojuje stejná funkcionalita. Čím více je systém modulární, tím lépe v něm lze lokalizovat a opravit chybu. Jednotlivé části modulárního systému bývají také často znovupoužitelné (viz další bod). Znovupoužitelnost (Reusability) – Vypovídá o tom, zda lze použít jednotlivé části softwaru samostatně či v rámci jiných projektů. Znovupoužitelný kód usnadňuje vývoj nových aplikací, neboť není nutné znovu programovat to samé, ale stačí převzít již existující kód z jiné aplikace, případně jej lehce upravit pro potřeby aplikace nové.
Chceme-li zvýšit celkovou kvalitu softwaru, musíme nejprve stanovit požadavky na výše uvedené dimenze a následně zajistit, aby došlo k naplnění stanovených požadavků. Jednotlivé dimenze kvality však mohou být ve vzájemném konfliktu. Zaměření se na jednu z dimenzí může znamenat snížení kvality jiné dimenze. Naopak některé z dimenzí se vzájemně doplňují. Zajišťování celkové kvality softwarového produktu je především volení přijatelných kompromisů mezi různými dimenzemi softwaru. Pro představu zde uvedu několik příkladů, kdy stojí jednotlivé dimenze softwarového produktu proti sobě nebo se vzájemně doplňují:
Integrita x výkonnost – režie zajištění integrity aplikace a zpracovávaných dat vyžaduje přidání několika procedur, jejichž provedení vyžaduje dodatečný čas a výpočetní zdroje.
Použitelnost x výkonnost – zlepšení v oblasti uživatelského ovládání aplikace s sebou obvykle přináší větší množství zdrojového kódu a větší nároky na výkon aplikace. Typickým příkladem je užití grafického rozhraní oproti textovému.
Udržovatelnost, testovatelnost x výkonnost – Optimalizace aplikace s cílem zajistit lepší udržovatelnost či testovatelnost si také vyžádá větší množství zdrojového kódu.
Přenositelnost x výkonnost – zdrojový kód optimalizovaný pro určitou platformu bude obtížné převést na platformu jinou.
Flexibilita, znovupoužitelnost x výkonnost – Flexibilní, modulární systém opět obsahuje více zdrojového kódu, který zajištuje jeho flexibilní využití.
Flexibilita, znovupoužitelnost x integrita - Flexibilní datová struktura využívaná ve flexibilních, znovupoužitelných aplikací představuje větší bezpečnostní riziko.
Znovupoužitelnost x spolehlivost – znovupoužitelný software je psán obecně, aby pokryl co možná nejširší spektrum případů, pro které jej lze využít. Širší záběr ovšem také znamená, že je software náchylnější na selhání.
Udržovatelnost a flexibilita – Flexibilní aplikace vyžaduje vhodně zvolenou strukturu, kterou bude pravděpodobněji snazší také udržovat.
13
Udržovatelnost a znovupoužitelnost – dobře strukturovanou a udržovatelnou část aplikace bude mnohem lečí znovu použít i v jiných programech.
Přenositelnost a znovupoužitelnost – zdrojový kód přenositelné aplikace bude obsahovat méně kódu závislého na platformách, na kterých je aplikace provozována.
2.3 Softwarové chyby Pokud software nenaplňuje očekávání, nefunguje správně či neplní některý ze stanovených požadavků, hovoříme o softwarové chybě, vadě, závadě, selhání, anomálii, odchylce a mnoha jiných výrazech. Na první pohled se může zdát, že tyto výrazy reflektují stejný význam a není důležité mezi nimi rozlišovat. Každý z nás ale jistě cítí drobné rozdíly ve významu výše uvedených slov, ale definovat přesně tyto rozdíly již pro nás nemusí být tak snadné. Závada či selhání obvykle představují nějakou závažnou situaci. Zatímco anomálie a odchylka odkazují na drobné odchýlení (proto odchylka) od požadovaného stavu. Z výše uvedených důvodů se proto nejčastěji pro popsání problému se softwarem používá termín softwarová chyba. Ron Patton v knize Testování softwaru definuje softwarovou chybu následovně [17, s. 14]: „O softwarové chybě hovoříme tehdy, pokud je splněna jedna nebo více z následujících podmínek: 1. 2. 3. 4. 5.
Software nedělá něco, co by podle specifikace produktu dělat měl. Software dělá něco, co by podle údajů specifikace dělat neměl. Software dělá něco, o čem se produktová specifikace nezmiňuje. Software nedělá něco, o čem se produktová specifikace nezmiňuje, ale měla by se zmiňovat. Software je obtížně srozumitelný, těžko se s ním pracuje, je pomalý, nebo – podle názoru testera softwaru – jej koncový uživatel nebude považovat za správný.
Z Pattonovy definice vyplývá, že chyba v softwaru nastane tehdy, pokud je produkt v rozporu se specifikací anebo v případě, kdy je specifikace nepokrývá plně požadavky nebo je dokonce s nimi v rozporu. V konečném důsledku lze za softwarovou chybu považovat cokoliv, co snižuje celkovou kvalitu softwarového produktu, protože díky této chybě software nenaplňuje stanovené požadavky. Na problematiku významu různých označení pro softwarové chyby naráží také Daniel Galin, který se snaží rozdělit softwarovou chybu do třech úrovní podle jejich projevu [1, s. 16]. Za softwarovou chybu (error) považuje syntaktickou chybu ve zdrojovém kódu či logickou chyba v návrhu. Softwarová chyba může dále vést k softwarové závadě (fault) neboli k nepatřičnému chování softwaru. Mnohdy však softwarová chyba nemusí funkcionalitu aplikace vůbec ovlivnit a zůstane skryta. Selháním softwaru (failure) pak označuje situaci, kdy dojde k aktivaci softwarové závady, tedy když se uživatel pokusí použít závadnou část aplikace. Uživatel se k selhání softwaru nemusí nikdy dostat ať již pro jeho nezájem o problémovou oblast aplikace nebo jednoduše proto, že se mu při používaní softwaru nepodaří dosáhnout potřebné kombinace podmínek pro aktivaci softwarové závady.
2.4 Příčiny softwarových chyb Jeden z Murphyho zákonů praví, že „libovolný netriviální program obsahuje alespoň jednu chybu“ [18]. To není zrovna povzbudivá citace, bavíme-li se o zajištění kvality softwaru, ovšem z vlastní
14
zkušenosti mohu potvrdit, že je pravdivá. Vytvořit netriviální software, který by byl bez chyb, by při nejmenším znamenalo investovat nepatřičné množství peněž a zejména času do jeho vývoje a především do odhalování všech chyb zanesených do programu. A i tak by software obsahoval pravděpodobně onu jednu zmíněnou chybu. I přesto se ale vyplatí investovat do zajištění kvality aplikace, odhalit její chyby a zejména příčiny těchto chyb, abychom zabránily opakovanému vzniku stejných chyb. Chyby mohou vznikat na základě mnoha příčin. Při nalezení chyby v aplikaci většinu z nás napadne, že programátor něco vynechal, přehlédl nebo omylem zanesl do zdrojového kódu aplikace chybu. Patton, odkazujíc se na řadu studií, však uvádí, že nejčastějším zdrojem chyb je špatná specifikace [17, s. 15], viz Obrázek 1. V řadě případů totiž u softwarových projektů chybí řádně zdokumentovaná specifikace, není dostatečně podrobná či se stále mění i během vývoje. Druhým zdrojem chyb je návrh, který může trpět podobnými problémy jako zmíněná specifikace.
Jiné
Programový kód
Specifikace
Návrh
Obrázek 1 – Příčiny softwarových chyb [17, s. 15]
Třetí pozici drží chyby způsobené ve zdrojovém kódu aplikace. Jejich příčina spočívá nedostatečné programátorské dokumentaci (zejména u složitějších projektů a projektů, které procházejí neustálými úpravami), časové tísni (snaha dokončit práci ve stanoveném termínu) či nesoustředěnost a nepozornost programátora. Některé chyby, které se na první pohled jeví jako chyby ve zdrojovém kódu, však mají příčinu již v návrhu nebo dokonce ve specifikaci. Daniel Galin ve své knize „Software Quality Assurance“ dělí příčiny do podobných skupin jako Patton, ale jeho rozdělení je detailnější. Zahrnuje následujících devět hlavních příčin softwarových chyb [1, s. 19]: 1. Chybně definované požadavky Jednou z hlavních problémů ohrožující konečnou kvalitu softwaru jsou chybně definované požadavky. Obvykle jsou požadavky připravovány klientem, který často nemá jasnou představu o
15
svých požadavcích, nebo se neorientuje dobře v cílové oblasti, pro kterou bude software určen. Seznam požadavků může obsahovat některé z následujících chyb:
Požadavky jsou chybně definovány. Neodrážejí to, co klient ve skutečnosti potřebuje. V seznamu požadavků chybí zásadní požadavky. Klient, na rozdíl od dodavatele, je může předpokládat za samozřejmé, implicitní a proto je v požadavcích neuvede. Nebo je také možné, že na ně při formulování požadavků zcela zapomene. Neúplná definice požadavku. Například klient, který chce svým zákazníkům v e-shopu nabídnout slevu v závislosti na měsíční útratě zákazníka a slevu pro studenty. Ve specifikaci požadavků však opomene uvést, že slevový systém má podporovat i studenty. Uvedení zbytečných požadavků, jejichž realizace se v blízké budoucnosti neočekává
Díky výše uvedeným problémům dochází k tomu, že klient mění průběžně své požadavky i po zahájení vývoje aplikace. To v případě menších zásahů nemusí být na škodu, naopak se tím zvyšuje finální kvalita, protože je klient schopen korigovat směr vývoje. Pokud ale klient mění zásadní požadavky, které ovlivňují logický návrh aplikace, dochází zákonitě k problémům. 2. Selhání komunikace mezi klientem a dodavatelem V úvodních fázích vývoje se také můžeme setkat s problémy způsobenými nedorozuměními, které vznikají při komunikaci mezi klientem a dodavatelem. Dodavatel může chybně interpretovat klientovy požadavky při návrhu aplikace nebo požadavky na změnu aplikace při jejím vývoji. Tento problém je závislý na zvolené formě komunikace. Například osobní konzultace nabízí mnohem více prostoru pro ujasnění si diskutovaného problému než telefonický rozhovor. I písemně formulovaný požadavek klienta nemusí být správně pochopen, obzvláště nemají-li obě strany sjednocené názvosloví. 3. Úmyslné odchylky od požadavků na software Za určitých okolností se může vývojář úmyslně odchýlit od formulovaných požadavků. A i přestože měl vývojář k této odchylce zdánlivě pádný důvod, může dojít k softwarové chybě. Typickým příkladem je znovupoužití softwarové komponenty z jiného projektů bez zjištění nutných adaptačních změn tak, aby funkčnost komponenty odpovídala požadavkům nově vyvíjeného projektu. Při snaze stihnout stanovené termíny dokončení aplikace se můžeme také setkat s tím, že vývojář dobrovolně nerealizuje některé z požadavků s tím, že pro dokončení aplikace nejsou důležité. Naopak příliš aktivní vývojář je schopen do aplikace zahrnout i drobnou funkcionalitu, která nebyla v požadavcích specifikována a kterou s klientem předem nekonzultoval. I přestože to programátor myslel dobře a byl si jistý, že klient přidanou vlastnost aplikace ocení, nemusí být tato změna klientem přijata pozitivně. V horším případě se tato drobná změna může projevit jako softwarová chyba, neboť je v rozporu s některým z požadavků klienta, o kterém vývojář netušil. 4. Logické chyby v návrhu Logické chyby vznikají na základě analýzy požadavků a jejich následného převedení do návrhu systému. Například i přesto, že klient přesně definuje v požadavcích proces, který má být implementován, tak v návrhu je tento proces zachycen odlišně. V návrhu může být vynechán
16
jeden krok procesu nebo se liší jeho vstupní či výstupní parametry. V návrhu mohou být mylně uvedeny i hraniční hodnoty pro jednotlivé vstupy. Není těžké zaměnit výraz „více než 3“ za „minimálně 3“, kde je ve druhém případě i hodnota 3 zahrnuta do limitu. Druhým větším problémem při vytváření návrhu je nezachycení všech možných situací a stavů, na které by měla aplikace reagovat. Měří-li aplikace třeba tlak a teplotu v určitém zařízení a na jejich základě provádí následné operace, bude chybou v návrhu opomenutí některé možné kombinace tlaku a teploty (například není definován stav pro teplotu 120°C a tlak v rozmezí 3 až 5 atmosfér). Stejně tak důležité je i stanovení hraničních hodnot a upřesnění, co se má stát pokud jsou tyto hodnoty překročeny. E-shop si může stanovit, že pouze zákazník s kreditem vyšším než 0 korun může realizovat objednávku. Pokud v návrhu není uvedeno i to, co se má stát, pokud se pokusí klient s nulovým kreditem objednávku realizovat, může běh aplikace skončit chybou, protože vývojář neměl důvod na možnou situaci při implementaci objednávkového procesu reagovat. Pokud jsou chyby v návrhu odhaleny včas, je jejich oprava mnohem snazší a především časově méně náročná než oprava již naimplementované funkcionality, která vzešla z chybného návrhu. 5. Chyby ve zdrojovém kódu Chyby ve zdrojovém kódu zahrnují syntaktické chyby, překlepy v názvech proměnných, neošetření vstupních dat, souběh při průběžném zpracování dat (race condition4) a mnoho jiných. Tyto chyby mohou vznikat nepozorností vývojářů, jejich nesoustředěním se z mnohých důvodu (časový stres, apod.) či použitím automatizovaných nástrojů pro generování kódu, které nebyly řádně otestované a mohou obsahovat chyby. Některé z výše uvedených chyb se projeví již při prvním spuštění aplikace, ale jiné zůstanou bez důkladného otestování skryté. 6. Nedodržení dokumentace a zásad pro psaní kódu Téměř každá skupina vývojářů má svou dokumentaci a zásady pro psaní kódu, které definují obsah zdrojového kódu ve smyslu jeho struktury a formátu. Za tímto účelem májí k dispozici předpřipravené šablony a formálně sepsané zásady. Dodržováním těchto zásad se snižuje riziko vzniku chyb. Týmu, který vyvíjí aplikaci bez definovaných pravidel pro psaní kódu, hrozí, že se v budoucnu setká s větším množstvím chyb. V takovém případě má totiž obvykle každý svůj vlastní styl. Pokud vývojář upravuje část aplikace, kterou vytvořil jiný programátor s rozdílným stylem psaní zdrojového kódu, je pro něj mnohem těžší se v kódu zorientovat a pochopit jej. Pokud navíc autor původního kódu není již členem týmu, je situace o to horší, neboť vývojář s ním nemůže konzultovat konkrétní část aplikace. Zdrojový kód obsahující více programátorských stylů je také více náročné kontrolovat v rámci revize kódu, kdy jeden vývojář kontroluje práci druhého. Ze stejného důvodu se také pravděpodobně zvýší počet neodhalených chyb v rámci testování aplikace, protože testeři budou mít problém se v kódu vyznat a vytvořit pro něj patřičné testy. A v neposlední řadě při opravě 4
Race Condition – Pokud aplikace zpracovává různými úlohami stejná data souběžně, může dojít k situaci, kdy jedna z úloh změní data, která jsou zpracovávána ve stejný okamžik úlohou jinou. V tu chvíli data obsahují jiné údaje, než jaké byly předpokládány a může dojít k softwarové chybě, v tomto případě nazývané race condition.
17
chyby v kódu s jiným stylem se nemusí oprava podařit na 100% nebo je dokonce možné, že vývojář při opravě jedné chyby zanese do aplikace jinou právě z důvodu nepochopení zdrojového kódu. 7. Nedostatky v procesu testování Nedostatečný proces testování není sice primárním zdrojem softwarových chyb, ale jeho podceněním nejsou tyto chyby odhaleny, takže v konečném důsledku má na jejich výskytu v aplikaci také svůj podíl. Nedostatky v procesu testování jsou myšleny například neúplné testovací plány, které nepokrývají všechny části aplikace a ponechávají tak tyto části neotestované. Dalším problémem může být žádná nebo špatná dokumentace objevených chyb. Na základě špatně zdokumentovaných příčin či následků chyby nemusí být vývojář schopen tuto chybu správně opravit. 8. Procedurální chyby Vývoj softwarové aplikace je rozsáhly proces, který obsahuje mnoho procedur. Provádění činnosti v jednotlivých krocích v nesprávném pořadí nebo špatným způsobem může vést k dalším chybám. Příčinou špatně prováděných kroků při vývoji aplikace bývá v případě menších vývojových týmu nejčastěji neformálně definovaný proces vývoje. To znamená, že nikde není přesně uvedeno, co a kdy má být provedeno. Avšak i formálně zdokumentovaný proces neznamená, že jeho jednotlivé kroky nemohou způsobovat na první pohled skryté potíže. Je potřeba tyto postupy čas od času revalidovat a v případě objevení problému adekvátně upravit. 9. Chyby v dokumentaci Vývoj softwarového produktu se neobejde bez dokumentace, ať se již jedná o formální specifikaci produktu, zdokumentovaný návrh aplikace, programátorskou či uživatelskou dokumentaci nebo i jen komentáře ve zdrojovém kódu. Nedostatečná nebo nepřesná dokumentace ve zmíněných oblastech ztěžuje budoucí vývoj a údržbu aplikace a na jejím základě mohou být do aplikace také zanesené nové chyby. Nepřesnosti v uživatelské dokumentaci zachycující instrukce, které nejsou v souladu s aplikací, mohou mást uživatele a vést k neadekvátnímu použití aplikace. Příčinou chyb v uživatelské dokumentaci většinou bývá aktualizace softwaru bez následné úpravy dokumentace vztahující se k patřičné úpravě. Programátorská dokumentace může zase naopak obsahovat popis více funkcí než je ve skutečnosti ve zdrojovém kódu k dispozici například proto, že některé z funkcí byly nahrazeny novými nebo některé z funkcí byly naplánovány v raném vývoji aplikace, ale k jejich implementaci nikdy nedošlo. Problémy tedy nastávají, pokud se skutečný stav aplikace liší se stavem zachyceným v dokumentaci.
2.5 Náklady na kvalitu Jedním z důvodů, proč není ve firmách, obzvláště v těch menších, kladen větší důraz na kvalitu může být problematické prokázání přínosů aktivit zajišťujících zvýšení kvality softwaru. Pozitivní kvalita se odráží ve spokojenosti zákazníků, kterou lze jen velmi obtížně finančně vyjádřit. Zatímco náklady na zajištění dostatečné kvality lze velmi snadno spočítat. Klasický model vytvořený
18
Feigenbaumem na počátku padesátých let minulého století poskytuje rozdělení nákladu na kvalitu z ekonomického pohledu na dvě hlavní skupiny [19]:
Náklady na kontrolu kvality – náklady způsobené preventivní činností za účelem odhalit chyby a ověřit, že software dosahuje požadovaných kvalit. o Preventivní náklady – investice do infrastruktury a aktivit zajišťujících kvalitu na obecné úrovni. Znamená to, že tyto investice nesouvisí s konkrétním projektem, ale jsou vynaloženy v rámci organizace pro zajištění kvality napříč projekty. o Náklady na vyhodnocení – vztahují se ke konkrétnímu projektu a jsou způsobeny činnostmi, jejichž účelem je odhalit softwarové chyby a vyhodnotit kvalitu softwaru.
Náklady způsobené selháním kontroly kvality – zahrnuje náklady, které je nutné vynaložit na pokrytí škod, jež byly způsobeny nedostatečnými preventivními opatřeními v zajištění kvality či neodhalenými chybami. o Interní vady – náklady na opravení chyb, které byly odhaleny během revize návrhu, softwarového testování či akceptačních testů a byly také zároveň opraveny před dodáním softwaru zákazníkovi. o Externí vady – náklady na opravy chyb, jež byly odhaleny zákazníkem nebo při údržbě softwaru po té, co byl software již naistalován u zákazníka.
Daniel Galin si však myslí, že tento model není pro potřeby definování nákladů na kvalitu softwarového produktu dostatečný, neboť nezahrnuje jisté nezanedbatelné položky specifické pro oblast vývoje softwaru [1, s. 454]. Odkazuje při tom na knihu Stephena Flowerse Software failure, management failure [20], ve které se uvádí, že mnohá selhání softwarových projektů má příčinu v jejich řízení, managementu. Proto klasický model Galin rozšiřuje o dvě nová hlediska – viz Obrázek 2.
Prevence
Kontrola kvality
Vyhodnocení Manažerská příprava a kontrola
Náklady na kvalitu
Interní vady
Selhání kontroly kvality
Externí vady
Manažerská selhání
Obrázek 2 - Rozšířený model nákladů na kvalitu [1, s. 456]
19
Rozšířený model nákladů na kvalitu zahrnuje oproti klasickému modelu navíc oblasti související s managementem softwarových projektů [1, s. 455]:
Náklady na manažerskou přípravu a kontrolu – náklady na omezení manažerských selhání či snížení jejich dopadů. Zahrnuje činnost spojené s revizí kontraktů, přípravu projektových plánů včetně plánů kvality a jejich průběžnou aktualizaci, provádění pravidelných kontrol průběhu projektu nebo kontrola externích složek přispívajících do projektu.
Náklady na manažerská selhání – náklady na škody způsobené špatným řízením projektu, které nejčastěji zahrnuje nereálný časový plán projektu či nepřiměřeně odhadnutý rozpočet. Zahrnuje například dodatečné náklady na lidské a jiné zdroje při překročení původních plánů či reparace škod zákazníkům plynoucí z nedodržených termínů.
20
3 Zajištění kvality Zajištění kvality je systematický, naplánovaný soubor aktivit nezbytných k věrohodnému potvrzení, že proces vývoje či údržby softwaru naplňuje stanovené funkční a technické požadavky stejně tak jako požadavky manažerské, jež zahrnují dodržování stanovených termínů a rozpočtu [1, s. 27]. Význam zajištění kvality bývá někdy zaměňován s kontrolou kvality. Kontrola kvality je však zaměřena pouze na vyhodnocení kvality vytvářeného produkt. Jinými slovy kontrola kvality zahrnuje činnosti, které zajištují, že firma nevypustí do oběhu defektní výrobek. Pouhá kontrola kvality není pro dosažení vyšší kvality dostačující. Kontrola kvality má retrospektivní charakter, to znamená, že reaguje pouze na situace, které již nějakým způsobem nastaly. Zatímco zajištění kvality má proaktivní charakter, protože se snaží dopředu předvídat, co se stane a těmto situacím předcházet. Zajištění kvality má na rozdíl od kontroly kvality tedy i preventivní charakter. Jeho cílem je zajistit kvalitu v procesu realizace softwaru a tím i kvalitu samotného výstupu. Dále je jeho úkolem minimalizace nákladů na dosažení požadovaných kvalit produktu prostřednictvím nejrůznějších aktivit vykonávaných během procesu vývoje. Tyto činnosti jsou určeny k preventivnímu předcházení chyb či k jejich včasnému odhalení v raných fázích vývoje. Minimalizace nákladů je dosažena právě preventivními opatřeními, neboť je levnější zabránit vzniku chyby než ji opravovat. Mezi hlavní činnosti a odpovědnost zajištění kvality softwaru patří:
Přezkoumávání dostupných dokumentů vytvořených vývojovým týmem. Mezi dokumenty se řadí specifikace požadavků, funkční specifikace, návrh softwaru, zdrojový kód, dokumentace softwaru aj.
Sledovat dodržování standardů – přesné plnění stanovených procedur, dodržování konvencí pro psaní zdrojového kódu.
Nastavit standardy pro dosažení požadovaných kvalit -
Návrh QA plánů – V rámci zajišťování kvality jsou vytvářeny plány, jakým způsobem dosáhnout požadovaných kvalit a jak tyto kvality u produktu ověřit. Zahrnuje tvorbu testovacích plánů i jednotlivých testovacích případů.
Testování softwaru – významný nástroj zajištění kvality, který slouží k zhodnocení dosažení požadovaných kvalit softwaru.
Revize a audit – analyzování firemních procesu s cílem odhalit problematická místa, která by mohla v konečném důsledku vést ke snížení kvality vyvíjeného softwaru.
Správa chyb – přehledná evidence chyb a zajištění jejich náprav.
21
3.1 Softwarové testování Jedním z hlavních nástrojů zajištění kvality softwaru je softwarové testování. Je to činnost zaměřená na vyhodnocení kvality testovaného programu, jeho současného stavu. Testováním softwarového produktu nám zároveň také pomůže odhalit jeho chyby a nedostatky. Čím dříve jsou tyto chyby odhalené, tím snazší je jejich oprava. Je ale důležité si uvědomit, že testování není pouze prostředek pro hledání chyb či pro potvrzení, že software funguje správně. Jeho hlavním cílem zhodnotit stav vyvíjeného softwaru, respektive jeho kvalitu, během čehož jsou identifikovány chyby v softwaru. Původně bylo testování chápáno pouze jako činnost, zahrnující především spouštění a práci s aplikací, určená k odhalování přítomnosti chyb v softwaru. Myers definoval v roce 1979 testování jako proces, při kterém je program spouštěn se záměrem odhalit chyby [21]. Postupem času se však význam testování rozšířil z pouhého vyhledávání chyb i na zhodnocení celkového stavu softwaru. Testování se už také neomezuje pouze na interakci s naimplementovanými částmi aplikace, ale zahrnuje mnoho dalších činností. Testování je dle IEEE5 [22]:
Proces, při kterém je systém nebo jeho část provozována za zvláštních podmínek, určený k pozorování a záznamu výsledků, a zároveň k posouzení některých aspektů systému nebo součásti. Proces analyzování softwaru s cílem odhalit rozdíly mezi stávajícími vlastnostmi systému a požadavky, jinak řečeno s cílem odhalit chyby, a vyhodnotit vlastnosti softwaru.
Existuje mnoho způsobů, jak otestovat software. Obecně lze testovací techniky rozdělit podle toho, kdy, kým a jak je testování prováděno. Každá technika je vhodná pro otestování určitých aspektů softwaru. Jejich kombinací lze dosáhnout lepšího pokrytí softwaru, respektive odhalení vice chyb. Nicméně s vyšším počtem použitých technik pro testování roste zároveň i čas potřebný k provedení testování a snižuje se přírůstek odhalených defektů. Zde je seznam několika základních technik a typů testování, se kterými se lze v praxi setkat nejčastěji:
Ladění – činnost prováděná programátorem během implementace požadavků a proto ji nelze považovat za testování v pravém slova smyslu. Jak je již z názvu patrné, během ladění vývojář odlaďuje svou práci, respektive se snaží odhalit, zda při implementaci nezanesl do aplikace chybu a zda implementace splňuje stanovené požadavky. Během ladění nejsou objevené chyby nikam reportován, protože jsou obvykle opraveny programátorem ihned po nalezení.
Provádění kontrol – Jednoduché ověření, že byly naplněny předem stanovené body. Výsledky porovnání skutečnosti s předpoklady jsou omezeny pouze na konstatování, zda předpoklad byl či nikoliv nebyl naplněn. Vzhledem k jednoduchému ověření lze provádění kontrol zcela automatizovat.
Průzkumné testování – Během průzkumného testování tester prochází aplikaci dle svého uvážení bez předem stanovených cílů. Tester se s aplikací seznamuje, přičemž zároveň zkouší, jak aplikace reaguje na určité podněty.
5
IEEE - Institute of Electrical and Electronics Engineers (česky „Institut pro elektrotechnické a elektronické inženýrství“) je organizace usilující o vzestup technologie související s elektrotechnikou.
22
Funkční testování – je zaměřeno na otestování funkcionality softwaru. Pomocí funkčních testů se ověřuje, zda aplikace plní veškeré úkoly, pro které je určena, a zda jednotlivé funkce odpovídají požadavkům zákazníka.
Testování dle scénářů – Před zahájením testování je nejprve vytvořen seznam testovacích nápadů, který obsahuje myšlenky a nápady, jak software otestovat. Na základě vybraných nápadů jsou vytvořeny testovací případy, neboli postupy, jak otestovat daný požadavek. Poskládáním několika testovacích příkladu dohromady vznikne testovací scénář. V něm je uveden přesný postup operací, které má tester s aplikací provést. Po jejich provedení tester porovná skutečný výsledek s očekávaným.
Testování vůči specifikaci - Funkcionalita a chování aplikace bývá obvykle definováno v její specifikaci. Testování vůči specifikaci ověřuje, zda aplikace naplňuje jednotlivá tvrzení ve specifikaci. Předpokládáme, že aplikace se chová dle specifikací a tímto testováním prokážeme, že aplikace je skutečně v souladu se specifikací. Formálně definovaná specifikace však mnohdy nepokrývá 100% aplikace. Vlastnosti aplikace, které se předpokládají jako samozřejmé, nemusejí být vždy ve specifikaci uvedeny. Fakta ve specifikaci nemusejí být také vždy jasně a jednoznačně formulována. Testuje se pouze to, co je ve specifikaci.
Jednotkové testy - Úkolem jednotkových testů je otestovat funkcionalitu jednotlivých metod, funkcí či případně ucelených komponent nezávisle na zbytku aplikace. Vhodné pro kontrolu chyb přímo ve zdrojovém kódu. Jednotkové testy lze snadno automatizovat, neboť jsou vytvářeny programově.
Integrační testy – Zkoumá se chování propojení více částí aplikace (metod, tříd) dohromady. Integrační testování odhalí zejména nekompatibilitu rozhraní, neočekávané vstupní parametry či stavy.
Systémové testy – Zaměřují se na aplikaci jako celek. V rámci systémových testů je ověřován soulad reálného chování celé aplikace s očekávaným chováním.
Uživatelské testování – V rámci uživatelského testování je aplikace testována uživateli, kteří nejlépe nemají s aplikací žádné předchozí zkušenosti. Uživatelské testování je vhodné pro ověření, do jaké míry je aplikace srozumitelná pro běžné uživatele a jak rychle se s ní naučí pracovat. Uživatelské testování zahrnuje mnoho různých podmnožin, jak aplikaci otestovat. Uživatelům mohou být například zadány různé úkoly, které mají v rámci aplikace vykonat. Hodnotí se, jak rychle a zde vůbec byl schopen uživatel úkol provést. Dále lze využít třeba A/B testování, kdy jsou dvěma skupinám uživatelů předloženy dvě verze aplikace, a porovnává se, se kterou verzí se uživatelům pracuje lépe.
Zátěžové testování - Zátěžové testování je určeno pro zhodnocení výkonu aplikace během enormní zátěži, v případě webových aplikací je touto zátěží nejčastěji myšlen vysoký počet uživatelů využívající aplikaci současně. Cílem testů je odhalit chování aplikace během zátěže, zda je schopna se se zátěží vyrovnat či případně jaké chyby jsou způsobeny přetížením aplikace.
23
Regresní testování - Založeno na opakovaném provádění testů, kterými již dříve aplikace úspěšně prošla. Hlavním důvodem pro provádění regresních testů je možnost zanesení chyby do již otestovaných částí aplikace během úprav zdrojového kódu aplikace. Tyto testy dále také slouží k potvrzení stability a chování softwaru v jeho jednotlivých fázích vývoje.
3.2 Reportování chyb Jedním z výstupů testování jsou objevené chyby. Samotné objevení chyby však nezajistí její opravu. K tomu je potřeba chybu zdokumentovat a upozornit na ni vývojáře. Jak uvádí Cem Kaner, odborník v oblasti softwarového testování, důvod pro zaznamenání chyby je zajištění její opravy [23, s. 65]. Ani ohlášení chyby samo o sobě však není dostačující. Důležité je především to, aby hlášení o chybě poskytovalo dostatek podkladů k opětovnému nasimulování chyby a zároveň bylo stručné a výstižné. Hlášení o chybách se mohou lišit v závislosti na typu vyvíjeného softwaru a použitých testovacích technikách. Obecně by však všechna hlášení měla obsahovat následující informace [24]:
Reportér – jméno a kontakt na toho, kdo chybu nahlásil Datum – kdy byla chyba objevena/nahlášena Produkt – v jakém produktu byla chyba objevena. Verze – přesná verze produktu, kde byla chyba objevena Komponenta – Pokud je možné produkt rozdělit na menší části, komponenty, je vhodné v hlášení uvést, ve které komponentě se chyba vyskytla (například „správa produktů“) Platforma – Na jaké hardwarové platformě se chyba vyskytla (PC, MAC, HP, SUN, atd.) Operační systém – V kterých operačních systémech se chyba projevuje, uvádět včetně verze. Priorita – Jak moc nutné je, aby byla chyba opravena. Ovlivňuje rychlost opravy chyby, protože chyby s vyšší prioritou jsou zpracovány přednostně. Závažnost – Určuje, jaký závažný je dopad chyby. Rozlišujeme mezi několika stupni: o Blokující – bez odstranění chyby není možné pokračovat v testování z důvodu nefunkčnosti části nebo celé aplikace. o Kritická – Aplikace je velice nestabilní, často padá, dochází ke ztrátě dat. o Závažná – Závažný problém ve funkcionalitě. o Menší – Menší problém ve funkcionalitě. o Triviální – Menší nedostatky zejména v oblasti uživatelského rozhraní. o Drobná úprava – Doladění funkce. Stav – Aktuální stav v rámci životního cyklu chybového hlášení (nová, přijatá, ověřená, opravená, znovu otevřená, nelze opravit a jiné) Přiřazeno – Osoba zodpovědná za opravu chyby, nejčastěji autor komponenty. Případně lze chybu přiřadit manažerovi, který ji následně deleguje na konkrétního programátora. URL - URL adresa stránky, kde se chyba projevila. Shrnutí - Stručné shrnutí chyby – kde a jak se chyba projevuje (ne více než 60 slov). Popis - Detailní popis chyby, v rámci kterého tester popíše minimálně tyto tři informace o chybě: o Postup v krocích – jednoznačně uvedený postup, jak chybu znovu reprodukovat. o Očekávaný výsledek – jak by se aplikace měla správně zachovat při provedení výše uvedených kroků. o Skutečný výsledek – jak se aplikace skutečně zachovala při provedení výše uvedených kroků. 24
Typ reportu – popis typu chyby (chyba ve zdrojovém kódu či v návrhu, problém v dokumentaci, nekompatibilita s hardwarem, doporučení úpravy, atd.) Nepovinná příloha – V některých případech lze přiložením obrázků či jiných souborů vystihnout podstatu chyby mnohem lépe než jejím textovým popisem.
Ve stejném článku, ze kterého jsem čerpal při sepisování položek chybového hlášení, je zároveň uvedeno i několik užitečných doporučení pro testery, které se promítnou do kvality hlášení a usnadní opravu chyby [24]: 1. Oznam problém okamžitě – Pokud je hlášení vytvořeno až po dokončení testování, je velice pravděpodobné, že nebude obsahovat všechny potřebné informace, protože si tester již nevybaví všechny detaily chyby. 2. Před vytvořením hlášení si vyzkoušet chybu třikrát znovu reprodukovat – Pokud je chybu možné vždy reprodukovat, je snazší ji i opravit. Proto je důležité věnovat pozornost podmínkám a postupu pro vytvoření chyby a jednoznačně postup zaznamenat, aby mohl programátor chybu snadněji identifikovat. 3. Otestuj, zda se podobná chyba nenachází i v jiné komponentě – Nezřídka je stejný kód použit ve více komponentách systému. Proto je pravděpodobné, že objevená chyba se může objevit i na jiném podobném místě, kde její přítomnost může mít dokonce závažnější následky. 4. Věnuj pozornost shrnutí – Na základě shrnutí může programátor snadno a rychle rozeznat hlavní podstatu chyby. 5. Přečti si svůj report před jeho uložením do systému – Před potvrzením hlášení je vhodné si po sobě zprávu znovu přečíst a opravit místa, která by mohla vést k nedorozumění. 6. Vyvaruj se urážlivých výrazů – Při psaní popisu chyby by se tester měl vyvarovat skrytému podtextu (ironie, sarkasmus) či přímé kritiky programátorů zodpovědných za přítomnost chyby. V opačném případě může dojít ke zhoršení stavu mezi testery a programátory, což se v konečném důsledku promítne na kvalitě softwaru.
25
4 Analýza současného stavu ve firmě Pro návrh zajištění softwarové kvality v malé firmě jsem si vybral reálnou malou firmu, která se věnuje tvorbě webových aplikací. Před samotným návrhem však bylo potřeba nejprve provést analýzu stávajícího stavu zajištění kvality ve firmě. Vzhledem k veřejné dostupnosti diplomové práce, jsem se rozhodl neuvést název společnosti, aby informace zde uvedené nemohly být snadno zneužity jako materiál pro konkurenční zpravodajství. Pro potřeby této diplomové práce není, dle mého názoru, skutečný název firmy nutný. Mohu však potvrdit, že firma opravdu existuje a informace zde uvedené odpovídají skutečnosti.
4.1 Postup při analýze Při zkoumání současného stavu ve firmě jsem vycházel z vlastních zkušeností jako externí zaměstnanec firmy na pozici programátora. Díky této skutečnosti jsem seznámen s firemními procesy, zejména pak s procesem vývoje softwaru a zajišťování jeho kvality. V rámci analýzy jsem konfrontoval své praktické zkušenosti získané činnosti ve firmě s teoretickými znalostmi z oblasti vývoje softwaru získanými během studia a rozšířenými o poznatky z oblasti zajištění kvality softwaru (viz teoretická část diplomové práce). Jako další zdroj podkladů pro vyhodnocení stavu mi posloužil rozbor dostupných textových dokumentů. Podklady, jež jsem při analýze využil, zahrnovaly programátorskou příručku a jiné návody určené především vývojovému týmu, dostupnou softwarovou dokumentaci včetně zdrojového kódu aplikace a jejího návrhu, záznamy z firemních porad, emailové diskuze mezi programátory, jednotlivá zadání úkolů a ohlášené chyby v systému pro správu projektů. Při hodnocení kvality vyvíjeného redakčního systému jsem se zaměřil především na potencionální slabá místa, která u webových aplikací mohou snižovat kvalitu. Mým záměrem nebyl detailní rozbor jednotlivých chyb aplikace, nýbrž pouhé potvrzení či vyvrácení předpokladu, že je kvalita v mnou zkoumaných oblastech zajištěna. Analýzu jsem rozdělil na dvě oblasti. V té první jsem zkoumal zajištění kvality z pohledu potencionálních příčin chyb v softwarových produktech a ve druhé jsem se pak zaměřil na zajištění kvality ve vybraných dimenzích. V rámci jednotlivých podkapitol jsou sepsány moje poznatky z jednotlivých oblastí a na konci každé podkapitoly jsou zvýrazněna problematická místa, která by mohla mít negativní vliv na celkovou kvalitu vyvíjeného softwaru.
4.2 Firma a její produkt Do roku 2005 působil nynější majitel firmy jako samostatný grafik a kodér. Externě spolupracoval s několika dalšími studii a agenturami, s nimiž se podílel na tvorbě webů pro jejich klienty. Vzhledem k nárůstu poptávky po tvorbě webových stránek se právě v roce 2005 rozhodl založit vlastní webdesignové studio. Ze začátku ve studiu působil sám, ale velice brzy navázal úzkou spolupráci se skupinou nezávislých programátorů. Ti se v oné době věnovali vývoji systému pro správu obsahu internetových prezentací, jednoduchému webovému informačnímu systému a systému pro správu klientů (CRM). Díky této spolupráci bylo webdesignové studio schopno dodat svým klientům nejen kompletní řešení webové prezentace se systémem pro její správu, ale i komplexnější webové aplikace zahrnující například internetový obchod (e-shop).
26
S postupným nárůstem klientů bylo také potřeba přibrat do týmu více lidí. V roce 2006 začal majitel firmy externě spolupracovat s dalšími dvěma grafiky, aby byl schopen pokrýt poptávku. Rozšíření pracovního týmu vyústilo v roce 2008, kdy majitel firmy zakládá společnost s ručením omezeným. V současné době v této firmě pracuje na částečný či plný úvazek cca 15 lidí. Na následujícím obrázku (Obrázek 3) je zachycena organizační struktura firmy. Majitel Studia Projektový manažer
SEO konzultanti
Grafici
Vedoucí programátorského týmu
Programátoři
Obrázek 3 - Organizační struktura firmy (zdroj: autor)
Jak z výše uvedeného obrázku vyplývá, organizační struktura není nikterak složitá a odpovídá velikost firmy. V čele firmy stojí její majitel, který zároveň odpovídá i za jednotlivé projekty. SEO konzultanti zajištují optimalizaci webových stránek klientů pro vyhledávače. Grafici vytváří grafické návrhy vzhledu webových stránek, ze kterých po schválení klientem tvoří šablony pro finální podobu webových stránek. Programátoři pod dohledem vedoucího programátorského týmu mají na starosti vývoj systému pro správu obsahu (CMS), který je hlavním produktem firmy. Programátoři také do CMS implementují specifické požadavky klientů, které se mohou projekt od projektu lišit. Do organizační struktury nejsou zahrnuti externisté, které firma také často využívá pro zajištění dodatečné pracovní kapacity. Firma sídlí ve dvou relativně vzdálených městech, přičemž v jednom z nich je soustředěn vývojový tým a ve druhém majitel studia společně s grafiky, SEO konzultanty a dvěma programátory. Hlavním produktem firmy je redakční systém neboli systém pro správu obsahu webových stránek. S jeho pomocí firma umožňuje svým klientům snadnou úpravu webových stránek. Editace stránek v redakčním systému je velice podobná práci s MS Word. Uživatelé aplikace se tudíž obejdou i bez znalosti HTML či CSS, které tvoří základní stavební kámen webových stránek. Redakční systém umožňuje správu stránek, článků, novinek, diskuzí, anket, soutěží a mnoha dalších typů obsahu, se kterým je možné se na internetu setkat. Do systému je také integrován modul pro správu obsahu elektronického obchodu, což zahrnuje správu zboží, správu objednávek realizovaných prostřednictvím e-shopu i správu samotných zákazníků či dodavatelů. Systém je od základu vyvíjen v rámci firmy, což firmě umožňuje flexibilně reagovat na požadavky zákazníků. Při vývoji vlastního systému firmu svazuje pouze rozpočet a dostupné zdroje. Proto je systém tvořen univerzálně, aby jeho funkcionalita pokryla co nejširší spektrum zákazníků. Tím jsou náklady na vývoj nových funkcí rozloženy mezi více subjektů, což vede i ke snížení konečné ceny pro zákazníky. Univerzálně psané systémy však také mohou být příčinou mnohým problémů. Redakční
27
systém je tvořen s cílem poskytnout univerzální nástroj pro správu obsahu. Jako takový obsahuje mnohá nastavení, která v některých případech mohou způsobovat konfliktní situace. A jak jsem již uvedl při definování kvality, kvalita produktu je subjektivní hodnota pro určitou osobu. Pokud je tedy vaší cílovou skupinou více různých typů uživatelů, je mnohem těžší stanovit si faktory kvality, na které se při vývoji systému zaměřit. Univerzálně psané aplikace také často trpí na nepřehledné uživatelské rozhraní, neboť je nutné v rámci rozhraní pokrýt rozsáhlejší funkcionalitu. V současné době firma svým klientům nabízí již druhou generaci redakčního systému, který se oproti předchozí verzi liší zejména v uživatelském rozhraní administrace. Cílem úprav je přizpůsobení se moderním trendům v podobě sjednocování rozdílů mezi klasickými desktopovými aplikacemi a těmi webovými. Systém je vytvořený v programovacím jazyce PHP a jako databázový systém je použito MySQL. I když je systém ve firmě vyvíjen od základů, využívá několik frameworku6 pro ulehčení práce programátorům.
4.3 Analýza na základě potencionálních příčin chyb Jak jsem již zmínil v teoretické části diplomové práce, za nízkou kvalitou softwarových produktů stojí chyby v nich obsažené. Při analyzování kvality vyvíjeného redakčního systému jsem se rozhodl, zaměřit se na potencionální příčiny softwarových chyb, tak jak je definuje Daniel Galin (viz kapitola 2.4). Zajímalo mě, jak a zda vůbec vývojový tým proti těmto příčinám podniká příslušné kroky. 4.3.1
Definování požadavků
Pro vývoj softwaru existuje mnoho metodik, které se od sebe liší zejména svým průběhem. U všech se však v úvodních fázích nachází sběrem požadavků, respektive komunikací se stakeholdery (viz kapitola 2.1) za účelem získání jejich požadavků na software. Právě zde se objevují první potíže, které mohou v konečném důsledku vést k vytvoření nekvalitního softwaru. Požadavky nemusí být jasně formulovány, mohou postrádat klíčové informace či některé z nich mohou být ve vzájemném konfliktu. Je třeba řádně analyzovat jednotlivé požadavky, odhalit problémová místa a vyřešit veškeré nesrovnalosti. Vyspecifikované požadavky by měly být zdokumentovány písemně či pomocí digramů zachycujících případy užití (use case), aby se předešlo rozporu mezi požadavky a implementací. V teoretické části jsem také uvedl, že požadavky na software nejsou definovány pouze zadavatelem. Požadavky může mít také samotný dodavatel, vývojáři či budoucí uživatelé, kteří se obvykle nepodílejí na úvodním formulování požadavků mezi objednavatelem a dodavatelem. Při sběru požadavků je proto nutné myslet na všechny stakeholdery a formálně zdokumentovat požadavky těchto stran. Ve firmě není specializovaný analytik na sběr a rozbor požadavků. Této role se ve většině případů zastává projektový manažer či vedoucí vývojového týmu. Ti se na osobních schůzkách snaží společně s klienty identifikovat jejich požadavky. Klienti obvykle v úvodních fázích projektu nejsou schopni přesně stanovit své požadavky ať již z důvodů neznalosti problematiky webových aplikací či prostě proto, že mají pouze jistou představu o tom, čeho by realizací projektu chtěli dosáhnout. Ačkoliv se jim zástupci firmy snaží co nejlépe pomoci při určování požadavků, tak se většina projektů potýká s většími či menšími změnami požadavků i během implementace původních požadavků. 6
Framework je softwarová struktura, která slouží jako podpora při programování a vývoji a organizaci jiných softwarových projektů. Může obsahovat podpůrné programy, knihovnu API, návrhové vzory nebo doporučené postupy při vývoji. [38]
28
V minulosti byla u několika větších projektů v úvodu provedena detailní analýza požadavků, jejímž záměrem bylo zabránit změnám požadavků během vývoje. Bohužel se však v konečném důsledku ukázala jako nadměrné plýtvání zdroji a času. Ačkoliv klienti v těchto případech schválili požadavky před implementací, došlo z jejich strany ke změně požadavků na základě výsledků z implementačních fází. Některé ze změn dokonce vedly k nutnosti přepracovat návrh aplikace. Z výše uvedeného důvodu a také proto, že většina realizovaných projektů je spíše menšího rozsahu, jsou požadavky v úvodní fázi projektu obvykle formulovány na obecnější úrovni a jejich zpřesnění je diskutováno až v rámci příslušných iterací. Uvedené řešení nabízí optimální kompromis a zajišťuje spokojenost klientů. Co se dokumentace požadavků týče, tak s těmi se lze setkat pouze v případě větších projektů. Bývají uloženy v datovém úložišti společně se zdrojovými kódy projektu či v dokumentu spravovaném přes Google Dokumenty na firemní doméně. Google dokumenty poskytují snadný nástroj pro sdílení a úpravu dokumentů mezi více lidmi, což usnadňuje rozbor a zpřesnění jednotlivých požadavků přímo v dokumentu. Při analýze jsem prošel několik dokumentů s požadavky. Ve většině případů dokumenty obsahovaly pouze v bodech uvedený seznam základních požadavků bez detailního popisu. Ze struktury dokumentů lze vyvodit, že poskytují hlavně přehled nad tím, co je potřeba v rámci projektu zpracovat a co již bylo naimplementováno. Detailnější popis požadavků je uveden až v rámci zadaní jednotlivých úkolu. Zadáváním úkolů společně s detailností popisu úkolu bude věnován prostor v jedné z následujících kapitol. Při procházení dokumentů s požadavky jsem také neobjevil specifikaci požadavků redakčního systému jako takového. Znamená to, že nikde nejsou přesně stanoveny funkční i nefunkční požadavky na vyvíjený softwarový produkt, což může vést k potížím nejen při testování (není oproti čemu testovat) ale i při samotném vývoji. Odhalená problémová místa
Chybí formálně specifikované požadavky na redakční systém.
Nesjednocené způsoby dokumentování požadavků.
Ve většině případů je kladen důraz pouze na požadavky klienta, ostatní stakeholdeři bývají při definování požadavků opomíjeni. Tabulka 2 - Odhalená problémová místa při definici požadavků [zdroj: autor]
4.3.2
Komunikace s klientem
Komunikaci s klienty má na starosti projektový manažer, popřípadě jej zastupuje vedoucí programátorského týmu. V rámci komunikace jsou nejčastěji řešeny požadavky klienta a průběh realizace zakázky. Při realizaci složitějších projektů je k diskuzi s klientem přibrán i ten člen programátorského týmu, který se na projektu podílí největší měrou. Programátor může s klientem lépe vyřešit záležitosti technického charakteru a zároveň poskytnout klientovi detailnější náhled na již implementované požadavky. Při komunikaci s klientem jsou využívány osobní schůzky pro úvodní sběr požadavků a v závislosti na velikosti projektu jsou schůzky využívány i během vývoje projektu s cílem informovat klienta o stavu projektu po dokončení některé z naplánovaných fází. Pro řešení menších problémů, zahrnující
29
například upřesnění požadavku, je využívána emailová komunikace. Urgentní problémy jsou řešeny telefonickým rozhovorem, což zabraňuje zbytečné časové prodlevě. Aby byl snížen dopad nedorozumění vzniklých během komunikace s klientem, je klient průběžně seznamován s výsledky vývoje. Jedna z výhod webových aplikací spočívá v relativně snadné implementaci ukázkového uživatelského rozhraní či v možnostech doručení ukázky klientovi. Bývá zvykem, že rozpracovaná webová aplikace je neveřejně dostupná na internetu. Klient tudíž může sledovat vývoj aplikace téměř v reálném čase a reagovat na odchylky oproti jeho požadavkům, které v rozpracované verzi objeví. Na jednu stranu může neustálá úprava požadavků znamenat oddálení termínu dokončení projektu, na stranu druhou však bude projekt naimplementován dle představ klienta. Proto je vždy vhodné se před zahájením projektu domluvit, jakým stylem budou měněny požadavky a jaký vliv změna požadavků bude mít na stanovené plánované termíny dokončení projektu. V případě oprav chyb, které klient objeví až při ostrém provozu, komunikuje s klientem vývojář, který má opravu chyby na starosti. Toto řešení může působit z pohledu klienta poněkud nekonzistentně, neboť může komunikovat vždy s někým jiným. Ale je jím eliminováno potencionální zkreslení, které by mohlo vzniknout, kdyby informace o chybě putovaly k vývojáři prostřednictvím třetí strany. Komunikací s klientem získávají vývojáři navíc zkušenosti z oblasti komunikace, které mohou v budoucnu využít v případě, že budou vybráni k vedení většího projektu, což zahrnuje i komunikaci s klientem při rozboru jeho požadavků. V této podkapitole bych rád zmínil problémy v komunikaci plynoucí ze skutečnosti, že firma je rozdělena do dvou měst a také její spolupráci s externisty. Díky tomu totiž firma působí při zpracování některých úkolů jako virtuální tým7 a jako takový se může potýkat s komunikačními problémy, které se při virtuální spolupráci objevují. Mezi nejčastější obtíže při komunikaci v rámci virtuálního týmu řadí Jiří Odcházel v knize Management a moderní organizování firmy následující tři problémy [25, s. 110]:
Nedostatečná viditelnost celého projektu – členové týmu sice znají své úkoly, ale často již nejsou seznámeni s tím, jak část, která jim byla přidělena, zapadá do celého projektu.
Neschopnost někoho zastihnout – v rámci virtuálního týmu je mnohem těžší získat odpověď od adekvátní osoby dle potřeby.
Někdy je také obtížné určit význam textových zpráv – z psaného projevu nemusíme vždy přesně poznat, co chtěl autor zprávy vyjádřit.
Na základě mého pozorování mohou potvrdit, že vývojový tým se s těmito problémy při práci na některých projektech do jisté míry potýká. Pokud na projektu pracuje více lidí, kteří nesdílejí společnou kancelář, je obtížnější udržet si přehled o návaznostech jednotlivých částí. Zejména u menších projektů není často k dispozici žádná dokumentace specifikací či návrhu. U větších projektů, kde již jistá forma dokumentace existuje, zase není vždy známo, kde se jaké části dokumentace přesně nacházejí (dokumenty uložené v online uložišti Google Dokumenty, dokumenty přiložené 7
Virtuální tým – skupina lidí, kteří společně pracují i přes to, že nejsou na stejném geografickém místě. Členové týmu používají mnohem častěji k vzájemné komunikaci technologie jako je internet, e-mail, videokonference, instant messaging a telefon než osobní schůzky. [22, s. 106]
30
k projektu, emailové diskuze, aj.). Vzhledem k tomu někteří zaměstnanci firmy pracují na poloviční úvazek nebo jsou najímáni jako externisté, tak je také obtížnější tyto pracovníky zastihnout v případě potřeby. Nedostatečný přehled o projektu mezi jednotlivými členy vývojového týmu se také projevuje v případech, kdy jeden z programátorů má převzít práci po někom jiném. Pokud se nově vybraný vývojář na projektu nepodílel od začátku, je pro něho velice obtížné získat podklady k projektu a vytvořit si o něm celkový přehled. Odhalená problémová místa
Problematický přehled nad realizovanými projekty Tabulka 3 - Odhalená problémová místa v komunikaci [zdroj: autor]
4.3.3
Úmyslné odchylky od požadavků
Vyvíjený redakční systém je vytvářen s cílem poskytnutí univerzálního nástroje pro správu obsahu na webu. Každý z klientů může mít jinou představu o tom, co by takový systém měl dělat a jak by měl vypadat. Úprava stávajícího řešení dle přesných požadavků každého klienta by byla přinejmenším časově velice náročná. Klienti si jsou vědomi toho, že kupují již existující software a přijali jej s jeho plusy i mínusy ač nemusel přesně naplňovat jejich požadavky. Někdy však systém nemusí pokrývat klíčové požadavky, bez jejichž naplnění ztrácí systém pro klienta hodnotu. Řekneme například, že klient se chystá přes internet prodávat potraviny a to jak na kusy (rohlíky) tak i na kila (brambory). Vývojář při realizaci projektu využije existující kód pro internetový obchod, ale neuvědomí si, že toto řešení umožňuje pouze nákup kusů, respektive množství zadávané v celých číslech. Vše na první pohled funguje správně a zákazník si v obchodě může objednat zboží. Jenže pokud se zákazník rozhodne koupit půl kila brambor, narazí na omezení původního internetového obchodu, který mu nedovolí zadat množství v desetinných číslech. V tomto případě se jedná o úmyslnou odchylku od požadavků. Ač byla požadována možnost nákupu na kila, tak vývojář použil stávající implementaci, aniž by si uvědomil, že ta neumožňuje zadat množství v desetinných číslech. S podobnými chybami se však vývojový tým u dokončeného projektu potýká jen málokdy. Klientovi je prezentován průběh vývoje, během kterého může rozpracovanou aplikaci testovat a odhalit tak odchylky od požadavků ať již vznikly neúmyslně či úmyslně při použití existující komponenty, která však nebyla přesně v souladu s požadavky. Problém bych spíše viděl ve formulaci požadavků na obecnější úrovni (viz kapitola 4.3.1), která svádí pro použití existujících komponent bez patřičných změn. K úmyslným odchylkám od stanovených požadavků se vývojový tým uchyluje také při situacích, kdy se mu nedaří plnit stanovený časový harmonogram. V těchto případech je implementace požadavků s nižší prioritou odložena do budoucna, což umožňuje dokončit včas alespoň kritické požadavky. I termín dodání kompletního produktu však hraje v kvalitě softwarového produktu velkou roli. Pro klienta je irelevantní, zda systém nefunguje v požadovaném rozsahu z důvodu softwarové chyby nebo jen prostě proto, že se nepodařilo naimplementovat požadavek včas. Zároveň při dokončování projektů přes stanovené termíny jsou vývojáři pod vyšším stresem, který se do jisté míry promítne i na kvalitě jejich práce.
31
Odhalená problémová místa
Občasné překračování stanovených termínů či dokončování projektů na poslední chvíli. Tabulka 4 – Úmyslné odchylky od požadavků [zdroj: autor]
4.3.4
Návrh aplikace
Po sběru požadavků přichází na řadu návrh aplikace. Návrh předchází implementaci a snaží se zachytit požadavky a souvislosti mezi nimi na techničtější úrovni. Jeho cílem je předejít potencionálním problémům, které nemusí být z požadavků na první pohled patrné, ale které by se mohly projevit během implementace. Návrh aplikace poskytuje ucelený a srozumitelný pohled na systém a vývojáři se v něm orientují lépe než v textovém seznamu požadavků. Lze jej považovat i za určitý typ dokumentace softwaru. Klasické softwarové metodiky a nástroje se v návrhu zaměřují na datové modely a modelování procesů či datových toků realizovaných v rámci aplikace. Webové aplikace jsou však specifickým typem softwaru, na jehož úspěchu se nemalým dílem podílí ergonomie a funkčnost uživatelského rozhraní. Návrhem rozhraní se však většina klasických metodologií nezabývá. Proto vzniky metodologie specializované pro návrh webových aplikací a jednou z nich je i WebML (Web Modeling Language). WebML je založena na dvou základních modelech – konceptuálním a navigačním. Konceptuální model odpovídá klasickému datovému modelu. Navigační model, často označovaný také jako hypertextový model, slouží k názornému zachycení pohybu uživatele po stránkách webového sídla. Hypertextový model zahrnuje kompoziční model a model navigace. Kompoziční model popisuje, z jakých logických prvků se skládá konkrétní stránka. Navigační model zachycuje navigaci (přechod) mezi jednotlivými stránkami. Při analyzování návrhu jsem se proto zaměřil na oblasti návrhu navigace a datové struktury. Datový model V dokumentaci redakčního systému se nenachází mnoho materiálů spojených s návrhem. Detailnější návrh je tvořen pouze u datové struktury (databázový model) a to zejména proto, aby byl zajištěn přehled nad relacemi v databázi. Databázový model však neodpovídá aktuálnímu stavu poslední verze redakčního systému a z jeho historie lze vyčíst, že je aktualizován nepravidelně. Menší aktualizace databázové struktury nejsou do modelu promítnuty. Pouze větší úpravy jsou před implementací konfrontovány s původním návrhem a následně do něj zaneseny. Návrh vzhledu Vzhledem k tomu, že firma pro své zákazníky převážně upravuje či rozšiřuje svůj redakční systém, nejsou pro jednotlivé projekty tvořeny detailnější návrhy. Administrativní část aplikace se v těchto případech nikterak zásadně nemění. Vzhled části viditelné běžným návštěvníkům webu se odvíjí od grafické návrhu vytvořeného grafikem. Před samotným grafickým návrhem je společně s klientem vytvořen takzvaný wireframe, neboli drátěný model, který na obecné úrovni zachycuje rozložení prvků (menu, sloupce, hlavní obsah, atd.) na webových stránkách. Pro každý projekt je pak na základě wireframu vytvořeno několik návrhů vzhledu. Každý z nich většinou obsahuje ukázku hlavní stránky webu, stránku se seznamem (články, produkty, novinky aj.) a výpis detailu (článku, produktu aj.). Na základě vybraného návrhu vzhledu klientem jsou vytvořeny šablony pro finální podobu webu.
32
Shrnutí Nepřítomnost dokumentace v oblasti návrhu se podílí, dle mého názoru, na chybách, které vznikly přehlédnutím souvislostí mezi jednotlivými částmi aplikace. Zejména při úpravách aplikace se může neexistence návrhu nebo jeho neaktuálnost citelně projevit. Potvrzuje to i záznam opravy jedné chyby, který jsem při analýze objevil. Problém souvisel s úpravou objednávkového procesu v internetovém obchodě. Původně nebylo možné zboží objednat bez registrace. V rámci úprav byla však přidána možnost anonymního nákupu. Z původního návrhu vyplývalo, že za každou objednávkou stojí konkrétní uživatel. Na této skutečnosti byly kriticky závislé další části objednávkového procesu a následné fakturace. V nich se vůbec nepočítalo s tím, že by někdy v budoucnu uživatel nemusel být v objednávce uveden. Po implementaci anonymní objednávky se na několika místech vyskytly potíže, neboť aplikace v těchto bodech očekávala informace o zákazníkovi a nebyla připravena na možnost, že žádné nedostane. Odhalená problémová místa
Dostupný pouze návrh datového modelu a návrh vzhledu FE.
Návrh datového modelu je nekompletní a nepravidelně aktualizovaný. Tabulka 5 - Odhalená problémová místa v návrhu aplikace [zdroj: autor]
4.3.5
Zdrojový kód
Za chybami, jejichž příčiny se ukrývají ve zdrojových kódech, mohou programátoři. Svou nepozorností zanášejí do zdrojového kódu nejrůznější chyby. Syntaktické chyby lze v PHP naštěstí snadno odhalit, neboť zdrojový kód se syntaktickou chybou nelze vůbec spustit. Chyby sémantické (opomenutí předání parametru metodě, předání neočekávaného datového typu, aj.) se v systému objeví při spuštění kritického místa, tzn. ne nutně při každém spuštění aplikace. Tím posledním typem chyb jsou logické chyby. Jsou to chyby nejzávažnější, protože se zpravidla projevují pouze nepřímo, bez zřetelných symptomů. Podstatou logické chyby je rozpor mezi tím, co by aplikace měla dělat, a tím, co bylo naimplementováno. Většina moderních vývojových prostředí pomáhá vývojářům odhalit syntaktické chyby, tím že je ve zdrojovém kódu zvýrazňuje. Některé z těchto nástrojů dokonce umožňují zvýraznit například i nepoužité proměnné, díky čemuž může programátor odhalit překlep v názvu proměnné. Laděním aplikace by zase měl být vývojář schopen objevit sémantické chyby, protože během ladění je obvykle provedena podstatná část naimplementovaného kódu. Pro odhalení chyb ve zdrojovém kódu lze také využít takzvané jednotkové testy, které jsou určeny pro izolované testování dílčích částí softwaru (metody, funkce, třídy). S překlepy nebo vynechání důležitých součástí se také můžeme setkat při vytváření podobných funkcí či tříd. Aby si programátor ulehčil čas, zkopíruje již existující zdrojový kód a pouze přepíše odlišné části. Tuto činnost již po nějaké době provádí automaticky a v takovém případě se zvyšuje riziko překlepů či opomenutí provést určité úpravy zkopírované části. K předcházení těchto situací slouží generátory zdrojového kódu. Jedná se o automatizované nástroje, které na základě vstupů vytvoří příslušný zdrojový kód. Chyby ve zdrojovém kódu Abych mohl posoudit, jakou měrou se chyby ve zdrojovém kódu podílejí na celkovém počtu chyb u analyzovaného systému, by bylo třeba manuálně projít všechny reportované chyby, které již byly
33
opraveny, a u nich určit jejich příčinu. Namátkou jsem vybral několik opravených chyb a i v tomto malém množství bylo několik chyb způsobených nepozorností při psaní zdrojového kódu. Ve vývojovém týmu není zaveden žádný speciální postup pro testování zdrojového kódu (např. výše zmíněné jednotkové testy). Je pouze na vývojáři, zda po sobě svou práci náležitě zkontroluje a prověří veškeré možné stavy naimplementované části aplikace, které by mohly nastat. To však nemusí být vždy dostačující. Problém s opakovaným vytvářením podobných komponent si vývojový tým uvědomuje. Pro generování zdrojového kódu tříd datových objektů má k dispozici vlastní generátor, který je schopen vytvořit datovou třídu na základě příslušné tabulky v databázi. Generátor nejenže programátorům ulehčuje práci, ale také zajišťuje, že datová třída bude vždy obsahovat vše, co systém očekává. Zde je však nutné podotknout, že i generátor kódu je aplikace vytvořená programátorem a jako taková může také obsahovat chyby. Bez důkladného otestování funkcionality generátoru nelze zaručit bezchybnost vygenerovaných tříd. Problematická místa ve zdrojovém kódu Při psaní zdrojového kódu občas vývojáři narazí na problematické místo, které by bylo v kódu potřeba vyřešit. Pokud z nějakého důvodu nemohou vyřešit problém ihned při jeho objevení, bývá zvykem toto místo označit komentářem s některým z klíčových slov. Pro potřebu doimplementovat určitou část softwaru se používá slovo TODO (z anglického „to do“ neboli „k dodělání“) a pro vyznačení místa, kde je chyba ve zdrojovém kódu, je použito FIXME (z anglického „fix me“ neboli „oprav mě“). Při analýze zdrojového kódu jsem se na tato klíčová slova zaměřil. Zkontroloval jsem jejich přítomnost v komentářích v poslední verzi systému a zde jsou výsledky: Klíčové slovo
Okomentované
Bez komentáře
Nejstarší
TODO
110
23
přes 1 rok
FIXME
14
1
11 měsíců
Tabulka 6 - Výskyt klíčových slov TODO a FIXME ve zdrojovém kódu (zdroj: autor)
Z tabulky je patrné, že v kódu je vyznačen relativně vysoký počet problematický míst. TODO se v kódu vyskytuje celkem 133, přičemž některé z komentářů byly do kódu zaneseny více než před rokem. TODO obvykle označují rozpracovanou implementaci některého z požadavků či místa, kde požadavek není jednoznačně specifikován a bez jeho upřesnění jej lze naimplementovat více způsoby s odlišnými výsledky. Vysoký počet komentářů a stáří některých z nich naznačují, že na ně bývá zapomenuto. Poznámky TODO do kódu však byly zaneseny s jistým účelem a jeho nenaplnění může způsobovat nepatřičné chování aplikace. FIXME označuje místa, kde byla objevena závažnější chyba, kterou je potřeba v blízké době opravit. Počet takto označených míst představuje pouze desetinu počtu komentářů TODO. Jejich nevyřešení však může mít dalekosáhlejší následky než nevyřešení problémů označených TODO. I přesto jsou ale ve zdrojovém kódu některé FIXME komentáře staré i několik měsíců. U většiny klíčových slov byl dopsán rozšiřující komentář popisující důvod vyznačení problematického místa. Délka komentářů byla téměř ve všech případech omezena jen na jednu větu či slovní spojení. Krátký komentář má smysl pouze pro jeho autora, kterému připomene, proč místo
34
ve zdrojovém kódu vyznačil. Pokud poznámku objeví někdo jiný, pravděpodobně nebude schopen bez konzultace s autorem poznámky problém patřičně vyřešit. Fragmenty nepoužívaného zdrojového kódu Zdrojový kód softwaru, který prochází dlouhodobým vývojem, se při špatné údržbě postupem času zanáší přebytečným kódem. Některé funkce systému jsou nahrazovány novými, jiné jsou z různých důvodů ze systému naopak úplně vyřazeny. Kvůli zachování zpětné kompatibilitě tyto staré fragmenty zůstávají v kódu i během jejich nahrazování. Po dokončení nové implementace by měly být staré části ze zdrojového kódu odstraněny. Analyzovaný redakční systém je však s různými úpravami nasazen na relativně vysokém počtu projektů. Distribuce zásadních změn ve zdrojovém kódu by si proto vyžádala vysoké náklady a tak jsou v systému ponechány i větve zdrojového kódu, které se stále využívají u starších projektů. Nepoužívané části zdrojového kódu mohou být také pozůstatkem slepé vývoje větve, od jejíhož dokončení se odstoupilo, ale zdrojový kód nebyl navrácen do původního stavu před zahájením vývoje nové funkcionality. Přebytečné fragmenty kódu zhoršují přehlednost zdrojového kódu a matou vývojáře. Ti musí přemýšlet nad tím, k čemu kód slouží a zda je vůbec využíván. A i když zjistí, že kód je pravděpodobně přebytečný, nemohou jej s jistotou odstranit. Jsou si vědomi toho, že jim mohla uniknout jistá souvislost, která přítomnost fragmentu ve zdrojovém kódu vysvětluje. Proto raději fragment ponechají ve zdrojovém kódu či v tom lepším případě problematické místo alespoň označí (TODO, FIXME – viz výše). Odhalená problémová místa
Nejsou prováděny jednotkové testy, které mohou odhalit řadu chyb ve zdrojovém kódu.
Dlouhodobě nevyřešená problematická místa ve zdrojovém kódu (TODO, FIXME)
Fragmenty nepoužívaného zdrojového kódu. Tabulka 7 - Odhalená problémová místa ve zdrojovém kódu [zdroj: autor]
4.3.6
Zásady pro psaní kódu
Prochází-li zdrojový kód aplikace dlouhodobý vývojem, může se postupem času snižovat jeho čitelnost a srozumitelnost, obzvláště podílí-li se na jeho tvorbě více programátorů. Po jisté době si vývojáři mohou všimnout, že realizace úkolů na systému vyžaduje stále více času oproti ranému vývoji. Každá provedená změna ve zdrojovém kódu může způsobit nefunkčnost několika jiných částí. Změny v systému se provádějí obtížněji a kladou na vývojáře stále větší nároky, neboť ti musí pochopit spletitost systému společně s různými kličkami a triky, které byly při implementaci systému použity jinými vývojáři. Zajištění dlouhodobější čitelnosti kódu lze do jisté míry dosáhnout stanovením zásad pro psaní zdrojového kódu a vhodným využitím komentářů v něm. V době, kdy jsem zkoumal zásady pro psaní kódu zavedené ve firmě, byla vývojářům v této oblasti dostupná pouze anglicky psaná programátorská příručka z roku 2005. V té je velice stručně popsáno, jakým způsobem má být tvořen zdrojový kód aplikací vyvíjených týmem. Jsou zde uvedeny pravidla pro pojmenování souborů, tříd, proměnných a funkcí. V závěru příručky se nachází několik poznámek o použití komentářů v kódu. Příručka je velice benevolentní v otázce formátování zdrojového kódu, respektive vývojáře nikterak v této oblasti neomezuje.
35
Při analýze zdrojového kódu jsem se zaměřil na to, zda jsou pravidla popsaná v programátorské příručce dodržována. Již na první pohled bylo ale zřejmé, že příručka nereflektuje aktuální zásady používané při vývoji systému. Od roku 2005, kdy příručka vznikla, došlo ve vývoji k mnoha změnám. Změnil se způsob pojmenování tříd či rozložení zdrojových souborů do odlišných složek než jaké bylo popsáno v příručce. Dostupná příručka je tedy zastaralá a navíc je sepsána velice obecně, což zanechává vývojářům velký prostor při vytváření kódu. Při bližším pohledu jsou ve zdrojovém kódu patrné stopy jednotlivých vývojářů. Odlišují se v zápisu závorek, vytváření podmínek, pojmenování dočasných proměnných, použití komentářů a jiných drobností, které v konečném důsledku mohou vést ke snížení čitelnosti zdrojového kódu pro ostatní vývojáře. Největší nedostatek však spatřuji v nízké informační hodnotě komentářů ve zdrojovém kódu, které by měli popisovat jednotlivé třídy a metody. Ke každé funkci by programátor měl uvést, k čemu funkce slouží, jaké jsou její vstupy a výstupy včetně datových typů, a v případě komplikované funkce popsat i jakým způsobem funguje. Tyto komentáře jsou součástí programátorské dokumentace a zajištují snazší orientaci ve zdrojovém kódu aplikace. Relativně často jsou však komentáře u funkcí omezeny pouze na základní informace zahrnující název a seznam parametrů. U některých funkcí nejsou dokonce komentáře uvedeny vůbec. Dále by dle příručky měly být všechny komentáře psány anglicky, přesto je však možné objevit v kódu i komentáře psané česky. Komentáře v analyzovaném softwaru se nacházejí i přímo v kódu. Vývojáři je používají při popisu složitých zápisů zdrojového kódu, které jsou na první pohled obtížně čitelné. Robert C. Martin v knize s příznačným názvem „Čistý kód“ však uvádí, že jediný skutečně dobrý komentář je ten, u kterého jste našli způsob, jak se bez něj obejít [26, s. 75]. Dle Martina špatný kód nemůže být vyvážen komentářem. Jakmile je zdrojový kód nepřehledný a vývojáře napadne, že bude lepší kód okomentovat, značí to, že je něco spatně. Myšlenku z komentáře lze vyjádřit přímo v kódu. Stačí třeba pro komplikovanou podmínku vytvořit funkci s výstižným názvem, který sdělí totéž, co komentář. Jasný a expresivní kód s několika komentáři je mnohem kvalitnější, než je zmatený a komplikovaný kód s mnoha komentáři [26, s. 75]. Odhalená problémová místa
Nejasně stanovené konvence pro psaní zdrojového kódu.
U některých metod a funkcí chybí povinné komentáře. Tabulka 8 - Odhalená problémová místa v konvencích pro psaní zdrojového kódu [zdroj: autor]
4.3.7
Proces testování
Firma nezaměstnává žádné specializované testery. Této role se ujímají zaměstnanci a externisté, kteří v danou chvíli disponují volným časem. Přesný proces testování není formálně zachycen. Obecně by programátor měl úkol po dokončení označit stavem „k otestování“ a kontaktovat dostupného testera, aby mu vysvětlil, co je třeba otestovat. Způsob otestování naimplementovaného požadavku je ponechán na testerovi. Po úspěšném dokončení testování označí tester úkol jako otestovaný. Objeví-li při testování nějaké chyby, vrátí úkol zpět dotyčnému programátorovi a zároveň jej informuje o zjištěných problémech. Zde je potřeba uvést, že ne všechny úkoly jsou programátory označovány stavem „k otestování“. Pokud si je programátor jist, že provedl implementaci bez chyb ať již proto, že se jednalo o triviální úkol nebo implementaci řádně odladil,
36
označí úkol stavem „dokončeno“. Správná implementace takového úkolu je zběžně ověřena až během závěrečného testování, kdy se systém testuje jako celek. K testování nejsou využity žádné specializované nástroje. Způsob testování ve většině případů odpovídá charakteru průzkumného testování. Tester si sám vybírá oblasti, na které se při testování zaměří. Do jisté míry by se dalo říci, že testuje dle scénářů, přičemž ale tyto scénáře nejsou někde sepsány a tester si je pouze odvozuje z popisu požadavků, jehož implementaci testuje. Testování je zaměřené spíše na pozitivní testy neboli testy splněním. Při nich se používají data, které musí být aplikace schopna zpracovat. Pozitivními testy se kontroluje, zda výstup z aplikace je shodný s očekávaným výstupem. Negativním testů, při kterých se zkoumá chování aplikace v případě použití neočekávaných dat (nevyplněný formulář, hodnoty mimo povolený rozsah aj.), je při testování věnována menší pozornost. Pokud tester shledá implementaci v pořádku, označí úkol v systému jako „otestovaný“ a předá jej zpět programátorovi, aby jej mohl uzavřít. U úkolů jsem nenalezl detailnější zprávu o tom, jak byla implementace testována a s jakými výsledky. Vývojáři ladí svou práci na svých počítačích, respektive na takzvaném lokálním prostředí. Konfigurace lokálního prostředí se může lišit od konfigurace prostředí, kde bude aplikace finálně provozována. Tester také potřebuje aplikaci někde otestovat před tím, než bude nasazena. Z výše uvedených důvodů se při vývoji softwaru využívá dalších prostředí. Ta mohou složit k otestování či prezentaci aktuálního stavu vývoje. Při vývoji projektů se ve firmě používají mimo lokálních prostředí vývojářů také tři další, které jsou přístupné přes internet. Po implementaci úkolu na lokálním prostředí je tato úprava nejprve nahrána na vývojové prostředí. Zde si vývojář může vyzkoušet, jak se systém chová v podmínkách podobných ostrému provozu (stejný server a konfigurace). Dále se zde systém testuje před tím, než jsou výsledky prezentovány klientovi. Po schválení je verze systému z vývojového prostředí nasazena na testovací prostředí, kde probíhá další testování. K systému běžícím v testovacím prostředí má také přístup klient, který si zde může vyzkoušet funkcionalitu aplikace a následně vyjádřit své připomínky před finálním nasazením. Po schválení aplikace v testovacím prostředí je systém nasazen do ostrého provozu. Testování a internetové prohlížeče Jedna z nevýhod webových aplikací oproti desktopovým je jejich závislost na použitém internetovém prohlížeči, které mohou ovlivnit jejich chování. V ideálním případě se aplikace ve všech prohlížečích chová a zobrazuje identicky. Ovšem při vývoji webových aplikací brzy zjistíme, že tomu tak není vždy. Starší verze prohlížečů nemusí podporovat některé HTML specifikace. Prohlížeče mohou rozdílně interpretovat definici vzhledu webové stránky či odlišně zpracovávat javascript8. V rámci testování webové aplikace je proto nutné brát zřetel i na použitý prohlížeč. Testovat veškerou funkcionalitu v každém prohlížeči by si vyžádalo obrovské množství úsilí. Lze však vytipovat oblasti, kde se rozdílnosti mezi prohlížeči mohou projevit (vzhled, javascript, aj.) a na ně se zaměřit. Ve firmě není kladen větší důraz na testování v odlišných internetových prohlížečích. Programátoři si problémy s prohlížeči ale uvědomují a ve zdrojovém kódu se snaží vyhýbat konstrukcím, které by se mohly chovat odlišně v závislosti na prohlížeči. Přesto se v systému občas vyskytne chyba související s použitým internetovým prohlížečem. Bohužel z hlášení o chybách a jejich 8
Javascript – skriptovací jazyk využívaní při vývoji webových aplikací. Příkazy v něm vytvořené se vykonávají na straně klienta (internetový prohlížeč musí podporovat javascript). Nejčastěji je využíván ke zlepšení uživatelského rozhraní aplikace.
37
opravách nelze snadným způsobem vyčíst, jakou měrou jsou zde zastoupeny chyby související s použitím odlišného webového prohlížeče. V hlášeních není ani uvedeno, zda chyba byla objevena při interním ladění aplikace nebo na ní upozornil až koncový uživatel. Bez těchto informací nelze určit, zda by se testování v různých prohlížečích vyplatilo z pohledu odhalených chyb oproti času, jež by si testování v odlišných prohlížečích vyžádalo. Hlášení chyb Chyby objevené během testování jsou reportovány do webové aplikace určené k tomuto účelu (Trac). Přesný formát hlášení chyby opět není stanoven. Je pouze na testerovi, jak detailně chybu popíše a zda dodá veškeré informace potřebné k jejímu odhalení a následné opravě. V teoretické části věnované testování jsem uvedl, co vše by takové hlášení o chybě mělo obsahovat. Z analýzy jednotlivých hlášení je však patrné, že se testeři omezují jen na základní popis chyby. Obvykle je v hlášení pouze uvedeno, kde se chyba nachází a jak se projevuje.
Obrázek 4 - Ukázka hlášení o chybě
Na výše uvedeném obrázku (Obrázek 4) je zachyceno hlášení o nalezené chybě zaevidované do systému. Jedná se o chybu související se špatným zobrazením diakritiky v příchozích objednávkách. Co se týče popisu chyby, tak již na první pohled je patrné, že se jedná o velice strohý popis, který se shoduje s názvem reportu a pouze jej nepatrně upřesňuje. Bez detailnějšího popisu však nelze určit, co je myšleno příchozí objednávkou. Systém odesílá emailem kopii objednávky zákazníkovi i prodejci. Navíc je objednávka uložena v databázi, odkud si ji obchodník či zákazník může zobrazit v administraci. Problém s diakritikou může být v emailu, v administraci nebo dokonce v obou případech zároveň a může se projevit jen v určitém prohlížeči. I pojem „hashování znaků“ může mít více významů, tudíž není jednoznačně určeno, jak se chyba projevuje. V tomto případě by pomohl například snímek obrazovky s chybou přiložený v příloze hlášení. Z něho by se dalo jednoznačně vyčíst, kde a jak se chyba projevila. Také není uvedeno, na jakém textovém řetězci s diakritikou byla chyba objevena. Za určitých okolností mohou být potíže pouze s některými znaky. Při zaznamenávání chyby je vždy vhodné uvést přesný postup krok za krokem, jak chybu nasimulovat. Report o chybě by měl mimo jiné také obsahovat informace o prostředí, kde byla chyba objevena. Tester by měl uvést, jaký webový prohlížeč použil (včetně verze), na jakém testovacím prostředí a databázi se chyba projevila (viz
38
testovací prostředí výše). V opačném případě musí programátor chybu složitě hledat. Pokud chybu jednoznačně neidentifikuje, hrozí situace, že chyba nebude opravena. V hlášení jsem záměrně pozměnil informaci o tom, kdo zprávu vytvořil (tester) a komu bylo přiděleno její vyřešení (programátor). V tomto hlášení se jednalo totiž v obou případech o stejnou osobu. Reportování chyby vývojářem není nic neobvyklého. Obvykle je taková chyba objevena při ladění jiné části aplikace. A protože programátor již na projektu pracuje, přidělí si opravu chyby sám sobě. Tomu, kdo chybu objevil, stačí jen stručný popis, aby si chybu připomněl. Pokud je však oprava chyby se stručným popisem přidělena jiné osobě, pravděpodobně bude muset dotyčný chybu konzultovat s jejím objevitelem. Chyba na uvedeném obrázku je v systému evidována téměř dva měsíce a tudíž ani programátor, který ji objevil, si již nemusí pamatovat všechny detaily. Z těchto důvodů by hlášení o chybě mělo vždy obsahovat všechny potřebné informace bez ohledu na to, kdo ji bude opravovat. V současné době je v systému evidováno 135 chyb, které dosud nebyly vyřešeny, přičemž 75 z nich bylo zaevidováno před třemi a více měsíci. Na první pohled se jedná o relativně vysoké číslo. Je však nutné brát v potaz, že těchto 135 chyb je rozloženo mezi 35 projektů, což v průměru představuje necelé 4 aktivní chyby na jeden projekt. Dále jsem při detailnějším rozboru reportovaných chyb zjistil, že některé starší reporty již nejsou aktuální, i přestože jsou v systému stále evidovány jako aktivní. Některé z chyb byly již vyřešeny v rámci jiných úkolů či přestaly existovat při provedených změnách v systému. Znamená to tedy, že některé chyby jsou reportovány duplicitně a některé nejsou uzavřeny i přesto, že se v systému již nenachází. Odhalená problémová místa
Při testování se využívá pouze průzkumného testování a do jisté míry testování dle scénářů.
Testování zaměřeno více na pozitivní testy.
Chybí reporty z testování.
Více než polovina hlášení o chybách je otevřena dále než 3 měsíce. Většina z těchto chyb se však již v systému nenachází a pouze nebylo uzavřeno hlášení o její přítomnosti. Tabulka 9 - Odhalená problémová místa v procesu testování [zdroj: autor]
4.3.8
Procedury v procesu vývoje
Vývoj netriviálního softwaru není jednoduchou záležitostí. Je to rozsáhlý proces, který může být realizován mnoha způsoby. Nemá-li proces vývoje přesně stanovený průběh či nejsou-li dodržovány alespoň klíčové postupy, zvyšují se šance, že výstupem procesu bude nekvalitní softwarový produkt. Proto se firmy při snaze dosáhnout vyšších kvalit svých produktů zaměřují také na kvalitu procesů. Jako prostředek pro vyhodnocení stavu firemních procesů lze využít několik přístupů. Jednou z možností hodnocení procesů je i stupňovitý model zralosti, CMMI (Capability Maturity Model Integration). Model CMMI byl vyvinut pro hodnocení vyspělosti procesů při vývoji softwaru. Důvodem k jeho vytvoření byla myšlenka, že kvalita softwaru se odvíjí od vyspělosti procesů stojících za jeho vytvořením. Vychází z pěti hierarchických stupňů rozvoje (viz Tabulka 10), které mapují stav jednotlivých procesů. Vyšší stupeň představuje větší schopnost dosažení odpovídající kvality produktu či služby závislé na procesu. V některých modifikacích CMMI se můžeme setkat i s nultým
39
stupněm vyspělosti procesů, který slouží pro označení neexistujícího procesu. Zavádí jej například metodika COBIT9. Následující tabulka zachycuje jednotlivé stupně rozvoje procesu: Stupeň
Proces
Popis
Neexistuje
Naprostý nedostatek rozpoznatelného procesu. V rámci podniku není ani známo, že existuje problém, který by měl tento proces řešit.
Počáteční / účelný
Podnik uznal existenci problému a ví, že je třeba jej řešit. Procesy však nejsou standardizované, ale pouze účelné pro konkrétní případ od případu. Celkový přístup k jejich řízení je neorganizovaný.
Opakovatelný, ale intuitivní
Proces se vyvinul na základě opakování stejné úlohy. Není formálně definován a zodpovědnost za provádění procesu je ponechána na jednotlivci. Vysoce závislý na znalostech těch, kteří ho provádějí, což zvyšuje pravděpodobnost výskytu chyb.
Definovaný
Postupy byly zdokumentovány a prostřednictvím školení sděleny odpovědným osobám. Tyto procesy by se měly dodržovat, nicméně je pravděpodobné, že se vyskytnou různé odchylky. Postupy samy o sobě nejsou propracované, pouze formalizují stávající praktiky.
4
Řízený a měřitelný
Plnění procesů je sledováno a měřeno managementem, který v případě zjištění neefektivnosti procesu podniká kroky za účelem zlepšení procesu. Procesy jsou neustále zlepšovány. Nástroje či automatizace jsou používány v omezené podobě.
5
Optimalizovaný
0
1
2
3
Procesy byly optimalizovány na základě výsledků měření a neustálého zlepšování. Automatizace a zavedení nejlepších dostupných praktik.
Tabulka 10 - Model vyspělosti procesů dle metodiky COBIT [27, s. 26], [28, s. 27]
Většina procesů v analyzované firmě odpovídá definici druhého stupně vyspělosti. Tyto procesy jsou prováděny opakovaně, ale nejsou nikterak zdokumentovány. V malých firmách není neobvyklé, že procesy nejsou formálně definovány. Začíná-li firma pouze s několika málo zaměstnanci, kteří postupně objevují, jak svou práci realizovat, může pro ně písemné zdokumentování procesů pouze představovat „byrokratické papírování“. V této životní fázi firmy se procesy neustále vyvíjejí a dolaďují, což by si vyžádalo také častou aktualizaci dokumentace. Procesy jsou tvořeny v rámci malého kolektivu samotnými zaměstnanci, kteří se s nimi tudíž rychleji sžijí a obejdou se bez jejich písemné podoby. Při růstu firmy je však pro nově příchozí zaměstnance obtížnější se s procesy seznámit. Nový zaměstnanec musí být zaškolen, což není nic neobvyklého. Ovšem v případě, že ve firmě většina procesů není formálně definována, je vysoce pravděpodobné, že ani školící proces nebude zdokumentován. V takovém případě hrozí, že při zaškolení nebude zaměstnanec seznámen se všemi aspekty jednotlivých procesů. Pokud špatně zaškolený pracovník setká se situací, která není
9
COBIT - Control Objectives for Information and related Technology (Kontrolní cíle pro IT a související technologie) je procesně orientovaný nástroj pro budování a rozvoj ICT governance. Řízení IT je zde definováno jako vazba mezi souborem požadavků, IT zdroji a IT procesy. CobiT poskytuje komplexní soubor cílů a metrik IT, který představuje ucelený pohled na řízení podnikové informatiky a je snadno využitelný při provádění auditů.
40
zdokumentována a ani mu nebyla při školení vysvětlena, má v zásadě dvě možnosti – zeptat se zkušenějších zaměstnanců nebo se pokusit vyřešit situaci sám. Zaměstnanec si však ani nemusí uvědomit, že se dostal do situace, ve které je potřeba provést určité důležité kroky. O potřebě dokumentovat komplikovanější procedury ve firmě dokládá i jistá část emailové komunikace mezi zaměstnanci. V rámci emailů jsou upřesňovány některé procedury, se kterými se tým často potýká (například založení nového projektu či vytvoření další vývojové větve systému). Pro uchování těchto informací považuji emailové zprávy jako nevhodný prostředek. Zprávy jsou dostupné pouze adresátům, což znamená, že nově příchozí zaměstnanci k nim nemají přístup. Klíčové informace se v emailových schránkách mohou také ztrácet mezi běžnou komunikací a jejich vyhledání nemusí být vždy snadné. Proces vývoje V každé firmě existuje minimálně několik klíčových procesů. V analýze jsem se však zaměřil pouze na proces vývoje, který bezprostředně ovlivňuje kvalitu vyvíjeného redakčního systému. Při vývoji softwaru se můžeme setkat se několika přístupy. Jedním ze základních přístupů vývoje softwaru je sekvenční vývojový proces, pro svůj kaskádový průběh označovaný též jako vodopád. V rámci vodopádu je projekt rozdělen do fází jdoucích postupně za sebou (viz Obrázek 5), přičemž se některé mohou i překrývat. V sekvenčním přístupu hraje klíčovou roli plánování a důraz na jednotlivé fáze, neboť realizace celého projektu zde probíhá najednou. Jak je z níže uvedeného obrázku patrné, každá z fází zahrnuje kontrolní mechanismy, pomocí kterých se ověřuje naplnění požadovaných cílů jednotlivých fází. Je ověřováno, zda se specifikace shoduje s požadavky, zda návrh pokrývá veškerou specifikaci, zda je systém naimplementován dle návrhu, zda se při nasazování systému neobjevily nějaké chyby. Vodopádovému modelu je nejčastěji vytýkáno, že u netriviálních projektů je velice obtížné, skoro až nemožné, dokončit jednotlivé fáze s dokonalým výsledkem aniž by předtím byly provedeny i následující fáze. Zainteresované strany totiž nemusejí být schopny v úvodních fázích přesně definovat své požadavky nebo je mohou změnit na základě prezentace již naimplementovaných částí systému. Změna požadavků během implementace či dokonce v pozdějších fázích může v sekvenčním vývoji znamenat, že nezanedbatelná část již odvedené práce přijde vniveč. Z výše uvedeného důvodu se při vývoji softwaru používá inkrementální přístup. Cílem inkrementálního přístupu je omezení rizik za pomoci rozdělení projektu na menší části. Tyto části jsou realizovány v jednotlivých iteracích za použití malého vodopádu vztahujícího se ke konkrétní části.
41
Obrázek 5 - Vodopádový přístup dle Adriana Alse [29]
Ve firmě je využívána kombinace sekvenčního a inkrementálního vývoje. V úvodních fázích jsou analyzovány požadavky na obecné úrovni pro celý projekt. Na jejich základě je projekt rozdělen do několika menších částí, jejichž realizace odpovídá vodopádovému přístupu. Na začátku každého vodopádu jsou upřesněny požadavky na konkrétní část projektu a v případě potřeby je aktualizován obecný návrh systému. Po dokončení implementace části, je tato část nasazena na testovací prostředí, kde je otestována testery i samotným zákazníkem. V případě objevených nedostatků jsou v naimplementované části provedeny patřičně změny. Rozdělení projektu na menší části zároveň umožňuje snazší dělbu práce mezi jednotlivé vývojáře, kdy je každý z nich zodpovědný za realizaci jedné z částí. Procedurám při sběru požadavků, jejich specifikací, návrhem aplikace a testování ve firmě byl věnován prostor v předchozích kapitolách. Proto se v této části zaměřím na několik aspektů z oblasti implementace a integrace, které mohou, dle mého názoru, snižovat kvalitu vyvíjeného produktu. Pro zadávání úkolů programátorům je využíván stejný systém jako pro reportování chyb. A i zadání některých úkolů trpí stejným problémem jako zmiňovaná chybová hlášení, jsou popsána velice
42
stručně. Je to dáno tím, že programátor, který má zpracování úkolu na starosti, je s úkolem seznámen odjinud (komunikace se zákazníkem, vedoucím projektu a podobně). Přesným a písemným definování úkolu lze zabránit nedorozuměním vedoucím k implementaci lišící se od požadavků. V rámci integrace je systém zprovozňován na serveru. Tato činnost zahrnuje větší počet kroků, které je potřeba zajistit. Při nasazování systému je potřeba vytvořit novou databázi, naplnit databázi daty (ať již pro testovací účely či ostrý provoz), založit uživatelské účty s patřičným oprávněním, nakonfigurovat doménu či nastavit samotný systém. Programátoři proto mají nově k dispozici kontrolní seznam bodů toho, co je potřeba zajistit při nasazování projektu. Seznam byl však zatím využit pouze u několika málo projektu Pro lepší správu zdrojových kódu softwaru a vzhledem k tomu, že na projektu může pracovat více programátorů najednou, je ve firmě používán systém pro správu a verzování souborů SVN. Jeho použití omezuje možnost přepsání úprav jiného programátora v případě, kdy na projektu pracují dva programátoři zároveň. Nicméně na server, kde je aplikace provozována, jsou zdrojové soubory nahrávány ručně. Několikrát se již stalo, že programátor při nahrávání souborů na server přepsal úpravy vytvořené jiným programátorem, neboť na server nahrál starší verzi systému. Tento problém se objevuje zejména v případě, kdy na projektu pracuje více programátorů současně či pokud některý z programátorů opomene uložit provedené změny do SVN. Shrnutí Výše uvedené příklady jsou pouze ukázkou toho, co se může stát, pokud nejsou dodržovány určité postupy. Největší riziko negativně ovlivňující kvalitu vyvíjeného softwarového produktu ve firmě plyne z intuitivně realizovaných procesů a procedur. Procesy nejsou jednoznačně definovány, a tudíž jejich vykonávání jednotlivými zaměstnanci se může lišit. Ačkoliv ve firmě existují i některé procedury v písemné podobě, nejsou vždy dodržovány. Důvodem může být nevhodné umístění těchto informací (emailová komunikace) či obecně nedostatečná informovanost zaměstnanců. Odhalená problémová místa
Většina procesů je prováděna opakované, ale intuitivně bez přesně stanovených postupů.
Pro upřesňování některých procedur je využívána emailová komunikace, která nemusí být vždy přehledná a snadno dohledatelná. Informace v emailech jsou navíc dostupné pouze adresátům zpráv. Tabulka 11 - Odhalená problémová místa v procedurách procesu vývoje [zdroj: autor]
4.3.9
Dokumentace
Softwarová dokumentace zahrnuje veškeré texty, které doprovázejí softwarový produkt. Je v ní vysvětleno, jak software funguje, k čemu slouží a jak jej lze používat. Do dokumentace řadíme soupis veškerých požadavků na software, materiály související s návrhem systému, popis metod a funkcí určený pro vývojáře (programátorská dokumentace softwaru) a v neposlední řádě manuály, nápovědy a jiné dokumenty usnadňující uživatelům práci se systémem (uživatelské dokumentace). Ve zkoumané firmě se pro evidenci dokumentace k jednotlivým projektům v zásadě využívají čtyři úložiště:
SVN repositář – Některé podklady k projektu lze nalézt ve vyhraněném adresáři v SVN repositáři, kde jsou uloženy i zdrojové kódy aplikace. Zde se nachází databázový model 43
redakčního systému, grafické návrhy vzhledu veřejně dostupné části projektů. U větších projektů jsou zde také přiloženy obvykle seznamy hlavním požadavků klienta.
Trac – Systému pro správu úkolů umožňuje v omezené míře publikaci článků (wiki10). Vývojový tým tuto možnost využívá zejména k evidenci určitých informací o projektech, jako jsou například údaje o webhostingu11, na kterém je projekt provozován. Je zde uvedeno pár návodů pro programátory popisujících použití několika málo komponent softwaru. Trac jako takový slouží k zadávání úkolů a reportování chyb. Popis těchto dvou položek tvoří také jistou formu dokumentace. Popis úkolů u menších projektů ve většině případů dokonce nahrazuje i dokumentaci požadavků, neboť ty nejsou nikde uvedeny a tudíž je lze odvodit pouze z úkolů realizovaných na projektu. Samotné zadání úkolu již však může být v rozporu s požadavky nebo nepřesně vystihující požadavek.
Google Dokumenty – Google dokumenty slouží jako vhodný nástroj pro sdílení dokumentů, které zde mohou být upravovány více lidmi zároveň, což usnadňuje týmovou spolupráci. V rámci Google Dokumentů je řešena sběr a analýza požadavků u složitějších projektů. Nalezneme zde také přehled o rozpracovaných projektech včetně seznamů kontrolních bodů při nasazování redakčního systému pro konkrétní projekt.
Emailová konverzace – V rámci emailové konverzace jsou diskutovány nejrůznější problémy, jejichž závěry lze považovat za jistou formu dokumentace. Jsou zde řešeny procesní záležitost a upřesňovány jednotlivé procedury. Emailem jsou také občas zasílány podklady k projektům (specifikace požadavků, upřesnění úkolu).
Rozložení dokumentace do více míst, ač se na první pohled její dělení jeví logicky, může být nepřehledné. Stěžuje programátorům orientaci v dokumentaci, protože požadavky k projektu se mohou nacházet na více místech zároveň. Navíc v případě Google dokumentů hrozí, že vývojář nebude mít k dokumentaci přístup, neboť k jednotlivým dokumentům zde uloženým mají přístup pouze osoby, které jsou v dokumentu výslovně uvedeny. Podobná situace nastává i u emailové konverzace, která je dostupná pouze odesílatelům a adresátům zprávy. Programátorská dokumentace je omezena pouze na několik návodů uložených v Tracu. Jak již bylo uvedeno v kapitole věnované zásadám při psaní kódu, u některých funkcí chybí ve zdrojovém kódu jejich popis včetně definice vstupů a výstupů. Tyto komentáře jsou považovány za jeden z hlavních pilířů programátorské dokumentace, protože přímo vysvětlují zdrojový kód. Na základě těchto komentářů je také možné vygenerovat referenční dokumentaci, která pokrývá veřejné API12 softwaru. Referenční dokumentace u analyzovaného softwaru však není dostupná. Není vytvořen ani žádný základní popis aplikace, který by přibližoval její základní strukturu, jednotlivé komponenty, použité knihovny a jiné. Neaktuálnost či neexistence programátorské dokumentace stěžuje práci programátorům. Ti musejí pracně z kódu zjišťovat, jak aplikace funguje a jakými funkcemi vůbec disponuje. Bez 10
Wiki – označení pro webovou aplikaci, která uživatelům umožňuje rychlé vytváření textového obsahu a jeho snadnou správu. 11 Webhosting – pronajatý prostor na cizím serveru určený pro provoz webových stránek a aplikací. 12 API - Application Programming Interface, neboli aplikační rozhraní, zastřešuje sbírku funkcí či tříd, které programátor může využívat.
44
dokumentace hrozí tvorba duplicitního kódu, protože si vývojář nemusí být vědom, že podobná funkcionalita je již v systému naimplementována. Samozřejmě čím déle vývojář s aplikací pracuje, tím lépe se v ní vyzná a může se bez dokumentace se obejít. Nicméně pokud je do vývojového týmu přibrán nový člen, je pro něho velice obtížné se ve zdrojovém kódu bez dokumentace zorientovat. Uživatelská dokumentace či jiná nápověda k redakčnímu systému dosud nebyla vytvořena. V minulosti bylo natočeno několik videí, na kterých byly zachyceny některé ze základních funkcionalit redakčního systému. Vznik těchto videí naznačuje, že uživatelé mají někdy problém se v systému zorientovat a nedostupnost uživatelské dokumentace či alespoň nápovědy jim práci se systémem neulehčuje. Použití videí jako formu uživatelské dokumentace nemusí být tou nejvhodnější cestou. Videa jsou na jednu stranu velice názorná, na stranu druhou však jejich vytvoření stojí více času a námahy. Při aktualizaci systému je také mnohem snazší přepsat text v uživatelské dokumentaci než znovu přetočit video kvůli sebemenší odlišnosti. Neaktualizovaná videa, a dokumentace obecně, mohou uživatele spíše mást v případech, kdy odkazují na již neexistující součásti systému. Jak jsem již zmínil v teoretické části diplomové práce, uživatelská dokumentace nemusí obsahovat jen návod, jak používat různé funkce aplikace. V uživatelské dokumentaci mohou být uvedeny odpovědi na nejčastější dotazy uživatelů redakčního systému, dále se zde také uvádějí technické specifikace produktu (podporované prohlížeče) či kontakt na technickou podporu pro řešení neobvyklých událostí (chyby v systému). Ani tyto informace však uživatelům redakčního systému nejsou dostupné v tištěné podobě. S většinou z nich jsou však klienti seznámeni při dodání hotového řešení. Odhalená problémová místa
Jistá nepřehlednost v dokumentaci plynoucí z jejího uložení na více místech.
Minimální programátorská dokumentace, často neaktualizovaná.
Minimální uživatelská dokumentace. Video-návody jen pro staré verze systému.
Užitečné informace uchovávány v emailové konverzaci. Tabulka 12 - Odhalená problémová místa v dokumentaci softwaru [zdroj: autor]
4.4 Analýza dimenzí softwarového produktu Ve druhé části analýzy jsem se zaměřil na kvalitu zkoumaného redakčního systému a projektů na něm postavených z pohledu několika základních dimenzí softwaru, které nebyly zmíněny v rámci předchozí kapitoly. Zajímalo mě především, zda jsou tyto faktory při vývoji zohledňovány, tzn., zda jsou pro tyto oblasti specifikovány požadavky a zda je kontrolováno jejich naplnění. 4.4.1
Bezpečnost
Webové aplikace představují ze své podstaty software náchylný k neoprávněnému použití, zcizení či modifikaci dat. Za toto privilegium vděčí své veřejné dostupnosti na internetu. Kdokoliv má k webové aplikaci přístup a může se tak pokusit odhalit její slabá místa, která mu dovolí převzít kontrolu nad aplikací nebo mu alespoň poskytnout plný přístup k datům aplikace. Klient či uživatel implicitně předpokládá, že aplikace je zabezpečena proti zneužití, proto při definici svých požadavků tento faktor nemusí zmínit. Je na dodavateli, aby zajistil adekvátní zabezpečení svého produktu.
45
Proto je potřeba při vývoji webových aplikací na toto riziko myslet a zajistit aplikaci proti nejčastějším bezpečnostním problémům. Abych mohl u analyzovaného produktu posoudit kvalitu a její zajištění z pohledu bezpečnosti, je třeba nejprve definovat známá bezpečnostní rizika:
Nedostatečné zabezpečení autentizace – Autentizace uživatelů skrze přihlašování pomocí přihlašovacího jména a hesla bývá nejčastějším způsobem, jak ověřit identitu uživatele. Na základě autentizace jsou následně uživateli přidělena různá práva pro využívání aplikace. Mechanismy pro přihlášení se mohou lišit, avšak hesla by měla mít stanovenou minimální délku a neměla by být ukládána v čitelné podobě pro případ jejich zcizení. Samotný proces přihlašování je vhodné ošetřit zejména proti útokům typu brute-force neboli prolomení hrubou silou13.
Nezabezpečené nahrávání souborů na server – Redakční systémy obvykle umožňují svým uživatelům nahrávat do webové aplikace různé soubory (obrázky, dokumenty, aj.). Nezabezpečený nahrávací mechanismus může útočník využít k nahrání vlastních souborů obsahující spustitelný škodlivý kód.
SQL injection – U webových aplikací jsou data obvykle uložena v databázi. Mezi daty se nacházejí informace o uživatelích (přihlašovací údaje, emaily, aj.), záznamy obsahu webové prezentace (články, uživatelské komentáře, položky e-shopu). Aplikace komunikuje s databází skrze dotazy, v rámci kterých načítá či ukládá data z/do databáze. Jako SQL injection je označována technika, kdy se útočníkovi podaří pozměnit databázový dotaz a donutit tak databázi provést jinou operaci. Změnit dotaz může útočník v případě, že aplikace do dotazu předává uživatelské vstupy, aniž by předem ošetřila.
Cross-Site Scripting – označuje typ útoku, při kterém se útočníkovi podaří vložit do html výstupu aplikace svůj vlastní html kód, pomocí kterého je pozměněn výstup aplikace. Útočník může také do html kódu přidat javacriptový kód, pomocí kterého může například získat některé informace o uživateli.
Cross-Site Request Forgery – v překladu znamená podvržený požadavků mezi stránkami. Útok využívá existující funkce aplikace, u kterých není kontrolováno, zda jejich provedení inicializoval skutečně přihlášený uživatel. Náchylné na tento typ útoku jsou především operace inicializované metodou GET, ale ani předávání dat přes POST není 100% bezpečné. Pokud je oběť do systému nezabezpečeného před CSRF přihlášena a navštíví útočníkovu stránku, může útočník například změnit heslo oběti, přenastavit uživatelské nastavení nebo provést libovolnou operaci s aplikací bez vědomí přihlášeného uživatele.
Autentizace a autorizace Analyzovaný redakční systém disponuje mechanismy pro autentizaci a autorizaci uživatelů. Je stanovena minimální délka hesla a zároveň heslo musí obsahovat minimálně jedno písmeno a jednu číslici, čímž se snižuje riziko odhalení uživatelova hesla hrubou silou. Aktivní ochrana proti útoku je v systému implementována pomocí maximálního počtu pokusů pro zadání chybného hesla, kdy po desátém pokusu dojde k zablokování účtu a bez zásahu administrátora již není od tohoto okamžiku 13
Během útoku hrubou silou útočník zkouší použít různé kombinace znaků pro nalezení hesla. Tyto útoky jsou většinou vykonávány automaticky, což útočníkovi dovoluje vyzkoušet mnoho kombinací v relativně krátké době.
46
možné se skrze tento účet přihlásit. Tato ochrana se jeví jako dostačující. Nicméně pro majitele účtu, který se stal cílem útoku, však představuje komplikaci v podobě kontaktování administrátora s žádostí o odblokování účtu. K podobnému útoku však za celou historii provozu redakčního systému mnohokrát nedošlo. Je to dáno zejména proto, že přihlašování je u většiny projektů použito pouze v administraci, kam se bez znalosti URL adresy nelze dostat 14 . V poslední době ale ve firmě přibývá projektů, kde je implementováno přihlašování ve veřejně dostupné části. Zde se již riziko zneužití tohoto typu útoku zvyšuje a v případě vyššího počtu brute-force útoků by mohlo dojít k nespokojenosti uživatelů z důvodu zdánlivě bezdůvodných blokací jejich uživatelských účtů. Nahrávání souborů Redakční systém podporuje nahrávání souborů prostřednictvím administrace (obrázky, dokumenty, aj.) i pro běžné návštěvníky (foto uživatelů). Pro nahrávání souborů je vyhrazena speciální komponenta v rámci aplikace, která při nahrávání souboru kontroluje typ souboru. Pro nahrávání obrázků jsou povoleny pouze tři typy formátů obrázků (jpg, gif, png). Pokusí-li se uživatel nahrát cokoliv jiného než obrázek, je na tuto skutečnost upozorněn. Nicméně v administraci s omezeným přístupem je použit modul, který podporuje nahrání libovolného typu souboru včetně spustitelného kódu, což jsem si prakticky vyzkoušel během mé analýzy systému. Pravděpodobně se při implementaci nahrávání souborů nepočítalo s tím, že útočníkem by mohl být někdo, kdo má přístup do administrace. Pokud se však útočníkovi podaří zcizit heslo do administrace, je díky této bezpečnostní díře schopen způsobit více škod. Hrozí také možnost, že v budoucnu bude modul pro nahrávání souborů bez omezení typu souboru použit pro veřejně dostupnou část aplikace a tudíž by pak mohla být zneužita kýmkoliv. SQL injection Struktura vyvíjeného softwaru disponuje oddělenou vrstvou pro komunikaci s databází. V rámci této vrstvy jsou ošetřeny jednotlivé dotazy do databáze s cílem zabránit SQL injection. U uživatelských vstupů se také před jejich zpracováním kontroluje datový typ. Přesto ale ve zdrojovém kódu najdeme části, kde je databázový dotaz tvořen ručně a s každým takto vytvořeným dotazem se zvyšuje riziko, že programátor opomene ověřit, že vstupy předávané do dotazu nelze zneužít pro SQL injection. Cross-Site Scripting Co se problému Cross-Site Scriptingu (XSS) týče, tak zde narazíme na podobnou situaci jako v případě nahrávání souborů. Uživatel v administraci je v rámci správy článků schopen vložit do textů svůj vlastní html kód, včetně javascriptu. Občas správce webového portálu potřebuje upravit html kód. A protože se opět nepředpokládá, že na aplikaci by útočili samotní správci, nebyly přijaté žádné opatření, které by omezovala správce při vkládání html značek do textu. U ostatních uživatelských vstupů, kde se nepředpokládá přítomnost html značek, je aplikována speciální funkce, která případné html značky zneutralizuje. Vzhledem k tomu, že aplikace není cíleně testována na XSS, existuje riziko, že některé uživatelské vstupy nejsou dostatečně ošetřeny proti zneužití.
14
Redakční systém není volně dostupný, proto znalostmi o jeho administrační části disponují pouze stávající klienti.
47
Cross-Site Request Forgery Při implementaci redakčního systému nebyla hrozba Cross-Site Request Forgery brána v potaz a proto je velice pravděpodobné, že aplikace je po této stránce zranitelná. Do jisté míry aplikaci chrání fakt, že většina potencionálně zneužitelných operací je dostupná pouze v administraci a bez znalosti systému je velice obtížné uhádnou jejich parametry pro vykonání podvrženého dotazu. Shrnutí Je nad rámec této diplomové práce detailněji zkoumat jednotlivá bezpečnostní rizika, zda jsou v aplikaci opravdu kontrolovány všechny vstupy či zda je vždy ověřeno oprávnění inicializovat určité operace. Požadavky na bezpečnost aplikace však nejsou formálně definovány a také se aplikace netestuje cíleně z pohledu zabezpečení. Vývojový tým má jistý přehled v problematice zabezpečení a při implementaci se vždy snaží ošetřit uživatelské vstupy, které jsou nejčastějšími zdroji problémů z hlediska bezpečnosti. Bez kontroly však nelze určit, zda je aplikace opravdu zabezpečená. Odhalená problémová místa
Nejsou formálně specifikované požadavky na zabezpečení aplikace
Bezpečnost systému není cíleně testována
Aktivní ochrana proti útokům hrubou silou může způsobit potíže i běžným uživatelům
Skrze nahrávání souborů v administraci lze nahrát spustitelný, potencionálně škodlivý, kód
Databázové dotazy ručně tvořené přímo v kódu zvyšují riziko SQL injection
Potencionální hrozba Cross-Site Request Forgery Tabulka 13 - Odhalená problémová místa v zabezpečení systému [zdroj: autor]
4.4.2
Přístupnost
K webové aplikaci může být přistupováno prostřednictvím různých internetových prohlížečů. Dnes jsou také webové aplikace často spouštěny na mobilních telefonech, které disponují znatelně menšími displeji než klasické PC. V neposlední řadě návštěvníci webových stránek mohou trpět různým hendikepem a mají proto na podobu webu speciální požadavky. Přístupnost webových aplikací lze shrnout do několika klíčových bodů [30]:
Obsah webových stránek je dostupný všem Práci s webovou stránkou řídí uživatel Informace jsou srozumitelné a přehledné Ovládání webu je jasné a pochopitelné Odkazy jsou zřetelné a návodné Kód je technicky způsobilý a strukturovaný
Z výše uvedených bodů je patrné, že přístupnost může mít subjektivní charakter a není snadné ji tak objektivně měřit. Ovšem existují jistá doporučení, jak zajistit přístupnost webových stránek a tato doporučení jsou založena na ověřitelných aspektech výstupu webové aplikace. Mezi vlastnosti přístupného webu patří například uvádění popisků k netextovým prvkům (obrázky, videa), dostatečně kontrastní barvy textu a pozadí, možnost zvětšit/zmenšit velikost textu, jednoznačně rozpoznatelné hypertextové odkazy, zřetelná navigace či povinné popisky pro formulářové prvky. Při vymezování těchto vlastností se lze inspirovat v české legislativě vyhláškou č. 64/2008 Sb., o formě
48
uveřejňování informací souvisejících s výkonem veřejné správy prostřednictvím webových stránek pro osoby se zdravotním postižením (vyhláška o přístupnosti) [31], ve které jsou stanoveny zásady přístupnosti, které musí být dodrženy na portálech veřejné správy. Při rozboru přístupnosti webových stánek generovaných analyzovaným redakčním systém jsem si náhodně zvolil několik projektů, které byly realizovány v poslední době a u nich jsem se zaměřil na některé z bodů uvedené ve vyhlášce č. 64/2008.
Popisky netextových prvků – většina z mnou navštívených stránek obsahovala popisky týkající se zobrazeného obrázku. V některých případek však popisek obsahoval pouze název souboru (obrazek.jpg) či dokonce ukázkový text (sample image). Za některé chybné popisky mohli správci webu (popisky bylo možné upravit v administraci), jiné však byly generovány přímo redakčním systémem a nebylo je tak možné bez zásahu do zdrojového kódu změnit.
Rozpoznatelné hypertextové odkazy – na zkoumaných stránkách jsem nezaznamenal žádné větší obtíže při rozeznávání odkazů. Jedná se o však můj subjektivní pohled, který nemusí reprezentovat cílovou skupinu uživatelů.
Kontrastní barvy – Nízký kontrast barev mezi pozadí a textem může způsobit nečitelnost obsahu webových stránek. V rámci konsorcia W3C15 byl pro zajištění přístupnost stanoven minimální rozdíl barev a jasu při vyjádření barev pomocí RGB neboli číselně reprezentované kombinace odstínu a jasu. I kontrast barev je možné měřit a hodnotit. Existuje také řada nástrojů specializovaných na vyhodnocení kontrastu barev webových stránek. Jeden z nich je k dispozici na www.accesskeys.org16 a s jeho pomocí jsem také testoval. I v tomto bodě jsem narazil na několik míst, kde kontrast barev pozadí a textů nesplňuje parametry určené W3C. Je nutné si však uvědomit, že W3C definovala kontrast barev tak, aby byla čitelnost byla zajištěna za jakýchkoliv podmínek. Neznamená to tedy, že pokud minimální hodnoty nejsou dodrženy, je text nečitelný.
Validita HTML – Zdrojový kód webové stránky je tvořen pomocí takzvaného značkovacího jazyka, HTML, který je charakterizován množinou značek a jejich atributů. Existuje několik verzí HTML a pro každou z nich jsou definována přesná pravidla, kdy je kterou značku možno použít a jak má vypadat její zápis. Validita zdrojového kódu vypovídá o tom, zda jsou tato pravidla dodržována či nikoliv. Nevalidní zdrojový kód může způsobit potíže při zobrazení webové stránky v prohlížeči (nezobrazení části stránky, rozdílné zobrazení stránky v závislosti na prohlížeči aj.). Většina moderních prohlížečů je však schopna se s nevalidním kódem vypořádat a správně jej zobrazit. Na druhou stranu validní kód nemusí nutně znamenat, že aplikace bude ve všech internetových prohlížečích zobrazena stejně17 a paradoxně může být při zajištění stejného vzhledu napříč prohlížeči použit nevalidní kód. Některé standardy také definují
15
W3C konsorcium – organizace, jejímž hlavním úkolem je určování webových standardů (specifikace html, http, css, aj.) 16 Access Keys – projekt zabývající se přístupností webových stránek. Poskytuje nástroje a rady pro zajištění/ověření přístupnosti. 17 Zejména u starších verzí webových prohlížečů bylo možné se setkat s odlišnými interpretacemi W3C standardů v oblasti html a css, což vedlo k rozdílnému zobrazení stejné webové v závislosti na použitém prohlížeči.
49
pouze formát značek (velikost písma, ukončení značky) a na zobrazení v prohlížeči nemají vliv. Možná právě z těchto důvodů není na validitu kladen takový důraz a 100% validní webová stránka je spíše rarita než pravidlo [32]. Nicméně validní HTML může být chápáno jako jistá známka dobré kvality. Naopak rozdílné chování webové aplikace v závislosti na použitém webovém prohlížeči se na hodnocení kvality promítne negativně. Otestovat validitu lze opět s použitím různých automatizovaných nástrojů, které porovnají zdrojový kód stránek s pravidly stanovenými W3C. Já jsem při hodnocení validity využil online nástroj vytvořený přímo W3C, dostupný na http://validator.w3.org. Všechny mnou testované stránky obsahovaly alespoň jednu chybu z pohledu validity. Ve většině případů se však jednalo pouze menší rozdíly oproti specifikaci, které pro koncového uživatele nepředstavovaly žádné potíže. Některé z objevených chyb byly však zásadní (HTML značky na místech, kde to specifikace nedovoluje, neuzavřené párové značky, aj.). Tyto chyby již mohou způsobovat rozdílné chování v závislosti na prohlížeči a jeho schopnosti si s chybou ve zdrojovém kódu webové stránky poradit. Odhalená problémová místa
Nejsou formálně specifikované požadavky na přístupnost.
Zjištěny nedostatky v popiscích netextových prvků či kontrastu barev.
Není striktně vyžadován/kontrolován validní HTML výstup aplikace. Tabulka 14 - Odhalená problémová místa v oblasti přístupnosti webové aplikace [zdroj: autor]
4.5 Závěr analýzy Analýza odhalila několik problematických oblastí, které by mohly vést k nižší kvalitě vyvíjeného softwarového produktu. Většina odhalených problémových míst souvisí s intuitivním přístupem k vývoji softwaru ve firmě a nižším důrazem na formální dokumentaci projektů. Přesný postup je stanoven pouze u několika klíčových procedur a většinou je zprostředkován prostřednictvím emailové komunikace, což jej činí obtížně dohledatelným. Ověřování kvality pomocí testování je ve firmě omezeno pouze na potvrzení naplnění obecných požadavků a není mu přikládán dostatečný důraz, což dokazuje nesystematický přístup k testování. Formální specifikace vyvíjeného redakčního systému neexistuje stejně tak jako uživatelská či programátorská dokumentace. Formální návrh systému je omezen pouze na databázový model a i ten však není průběžně aktualizován.
50
5 Navrhovaná řešení V rámci analýzy současného stavu vývoje softwaru ve firmě jsem odhalil některá slabá místa, jež mohou snižovat kvalitu finálního produktu. V této kapitole jsou uvedena možná doporučení pro odstranění jednotlivých nedostatků. V úvodu je věnována pozornost překážkám, které firmu mohou omezovat při výběru vhodných metod a nástrojů. Vzhledem k vyššímu počtu nedostatků odhalených při analýze procesu vývoje je v návrhu pozornost věnována především doporučením, jak odstranit současné problémy, které mohou vést k nižší kvalitě vyvíjeného softwaru. Současně je zde uvedeno, jakým způsobem do budoucna vyhodnocovat a zajišťovat kvalitu vyvíjeného softwaru.
5.1 Omezení Při navrhování postupů a nástrojů, kterými by firma mohla dosáhnout zlepšení v oblasti zajištění kvality, musím počítat s určitými omezeními. Ta jsou dána především velikostí firmy, jejím historickým vývojem a současným přístupem k problematice zajištění kvality vyvíjených aplikací. Jako malá firma disponuje omezeným rozpočtem pro nové investice. Zavádění či úprava procesů si vyžaduje čas a náklady, které by firma mohla věnovat k dosažení přímého zisku, tedy realizací projektů pro klienty. Trh s webovými aplikacemi, obzvláště pak se systémy pro správu obsahu na webu, je vysoce konkurenční prostředí. Odlišit se od konkurence může být velice obtížné a nákladné. V případě menších projektů je cena obvykle to první, na co se zákazníci ptají. Přínosy ze zlepšení procesů a zajištění kvality se promítnou převedším v celkové kvalitě softwaru a není snadné dopředu tento rozdíl v kvalitě přesně vyčíslit, zatímco náklady na zajištění kvality ano. Z tohoto pohledu se může zajištění kvality jevit jako další navýšení nákladů na realizaci zakázek klientů, potažmo koncové ceny produktu. Zavádění nových procesů, větší důraz na testování a analýzu příčin chyb s sebou přináší také větší pracovní vytížení. V literatuře zabývající se zajišťováním kvality se uvádí, že by měl být v rámci organizace stanovený samostatný tým, který by dohlížel na jednotlivé činnosti z pohledu jejich vlivu na celkovou kvalitu produktu. Myslím si však, že v rámci takto malé firmy pro začátek postačí, pokud problematice kvality vyvíjeného produktu, bude věnována dostatečná pozornost a čas současných zaměstnanců. Bude však potřeba zaměstnance povzbudit, aby se aktivněji zaměřili na identifikaci možných problematických míst v procesu vývoje. Nízký rozpočet také firmy omezuje v nákupu placeného softwaru pro podporu kvality. Myslím si ale, že pro začátek je možné využít některé programy z řad bezplatných alternativ (freeware, opensource). Na těchto nástrojích si vývojový tým může vyzkoušet jejich přínos a zjistit, jaké výhody či nevýhody jim tyto programy nabízejí při zajišťování kvality softwaru. V budoucnu pak na základě získaných zkušeností budou moci posoudit, zda se jim investice do placené aplikace vyplatí či nikoliv. Zároveň je velice obtížné objektivně porovnat přínosy navrhovaných řešení oproti současnému stavu, neboť v současné době není na vyhodnocování kvality ve firmě kladen dostatečný důraz, čehož je důkazem chybějící podrobná specifikace produktu či vedlejší role testování. Kvalitu lze bez specifikace požadavků jen obtížně vyhodnotit, neboť kvalita je určena mírou naplnění požadavků.
51
Pokud ve firmě není také kladen dostatečný důraz na testování, je velice pravděpodobné, že nově navržené testy odhalí větší počet chyb než v případě nekoordinovaného testování.
5.2 Počáteční fáze Analýza odhalila jisté nedostatky, bez jejichž vyřešení lze jen těžko zavádět aktivity související se zajištěním kvality. V současné době není například vytvořen návrh redakčního systému, nepočítáme-li databázový model, a nelze tudíž u návrhu ověřit, zda naplňuje veškeré stanované požadavky v jejich plném znění. Což je další problém, neboť požadavky jsou aktuálně specifikovány spíše obecně a pro redakční systém jako takový nejsou definovány vůbec. Tyto jednotlivé problémy je potřeba před průběžným zajišťováním kvality odstranit. 5.2.1
Specifikace požadavků
Kvalita softwaru je odvozena od naplnění požadavků všech zainteresovaných stran. Aby bylo možné kvalitu objektivně vyhodnotit, je potřeba mít veškeré požadavky řádně specifikované. A právě formálně nespecifikované požadavky jsou jedním z problémů, které jsem při analýze vyvíjeného softwarového produktu objevil. Snadnou možností jak specifikovat funkční požadavky již existujícího redakčního systému je popsání současné naimplementované funkcionality. Tuto variantu však nelze doporučit z jednoho prostého důvodu. Současná funkcionalita systému byla naimplementována na základě obecné specifikace a může tedy obsahovat větší či menší odchylky od skutečných, nevyjádřených požadavků. Navíc systém prošel dlouhodobým vývojem, během kterého mohlo dojít ke změně celé řady požadavků. Proto doporučuji neopsat funkcionalitu tak, jak byla naimplementována, ale naopak ji znovu specifikovat na základě aktuálních požadavků na systém pro správu obsahu. Vzhledem k tomu, že firma vyvíjí jeden hlavní produkt, je v jejím zájmu věnovat specifikaci více pozornosti a zachytit ji co nejpřesněji. Specifikaci požadavků se doporučuje zachytit nejen prostřednictvím textové dokumentaci, ale také využitím grafické dokumentace (diagramy), zejména pak případy užití (use case18). Specifikace požadavků nezahrnuje pouze funkcionalitu. Je důležité neopomenout také další aspekty systému. Pro inspiraci, které aspekty lze u softwaru specifikovat, lze využít seznam dimenzí kvality softwaru uvedený v kapitole 2.2.5 (Charakteristika jednotlivých dimenzí). U analyzované webové aplikace doporučuji zaměřit se především na následující oblasti:
18
Přístupnost – Analýza přístupnost realizovaných projektů odhalila některé nedostatky jako například nevalidní kód či chybějící popisky obrázků. Ačkoliv jsou dnešní prohlížeče schopné vypořádat se s nevalidním kódem, je validita do jisté míry známkou prestiže a ukázkou toho, že je aplikace tvořena pečlivě. Proto by mělo být ve specifikaci určeno, zda má být validita zohledňována. Dále je v rámci specifikace přístupnosti důležité uvést, jaké zařízení (počítače, mobilní telefony) a prohlížeče včetně verzí má aplikace podporovat. Při specifikaci dalších faktorů přístupnosti doporučuji inspirovat se vyhláškou č. 64/2008 Sb., o formě uveřejňování informací souvisejících s výkonem veřejné správy prostřednictvím webových stránek pro osoby se zdravotním postižením (vyhláška o přístupnosti) [31].
Use case diagram – Grafické zobrazení konkrétní funkcionality systému z pohledu uživatele.
52
Bezpečnost – Bezpečnost webové aplikace je široký pojem. Existuje celá řada potencionálních hrozeb, které mohou ohrozit bezpečnost aplikace (viz kapitola 4.4.1). Ve specifikaci proto může být věnována pozornost ochraně před známými zranitelnostmi webových aplikací, chování aplikace při opakovaném zadání špatného hesla, definici řízení přístupu k datům (uživatelská oprávnění), způsob zálohování a obnovy dat a další opatření pro zvýšení bezpečnosti aplikace.
Dostupnost – Ideálně je aplikace vždy dostupná. Takový stav ale nelze 100% zajistit. Nedostupnost může být způsobena nutnou aktualizací softwaru, náhodným výpadkem serveru nebo jeho zahlcením jako následek vysoké návštěvnosti webové stránky/aplikace. Při specifikaci dostupnosti je obvykle stanoven čas za určité období, po který může být stránka nedostupná (např. 1h měsíčně). Pro zajištění dostupnosti je také vhodné definovat, kolik uživatelů zároveň má být aplikace schopna obsloužit v přijatelné době (např. při užití aplikace 100 uživateli bude odezva stále nižší než 3s) a jakým způsobem bude dostupnost měřena.
5.2.2
Formální specifikace procesu vývoje
Jednou z hlavních možností, jak zvýšit kvalitu softwaru a zefektivnit proces vývoje, je formální specifikace proces vývoje od sběru požadavků po údržbu projektu včetně ověřování naplnění požadavků v jednotlivých fázích vývoje. Některé procedury, jako založení nového projektu čí fázi nasazování, má vývojový tým písemně do jisté míry již zaznamenány. Ovšem jejich necentralizované umístění v emailových konverzacích či Google Dokumentech nelze považovat za dostatečné. Je potřeba vytvořit centralizované místo, kde budou jednotlivé procesy a procedury dostupné pro všechny zaměstnance. Ke správě a distribuci procesů je možné využít například zdarma dostupný Eclipse Process Framework Composer. Více informací o tomto nástroji je uvedeno v kapitole věnované doporučeným nástrojům. Současný proces vývoje, je dle mého názoru, celkem vhodně nastaven a odpovídá charakterů realizovaných projektů. Je v něm stanoven i prostor pro připomínky klientů v průběhu implementace, což zaručuje, že systém bude vyvíjen po celou dobu dle představ klienta. Za slabé místo v procesu vývoje lze považovat nedostatečné ověřování výstupu jednotlivých fází před zahájením fáze následující (viz Obrázek 5 - Vodopádový přístup dle Adriana Alse ), obzvláště pak testování implementace. Otázce ověřování a testování by proto při vytváření formální specifikace procesu vývoje měla být věnována vetší pozornost. Vzhledem k velikosti firmy je možné, aby se na formální specifikaci procedur procesu vývoje, podílela většina zaměstnanců, kteří jsou součástí tohoto procesu. Při definici procesů může firma zároveň odhalit různé odlišnosti při provádění stejných činností různými zaměstnanci. Někteří z nich mohou používat rychlejší postupy, o kterých ostatní zaměstnanci nevědí. Jiní mohou v procedurách opomíjet některé důležité kroky, protože s nimi nebyli seznámeni a neuvědomují si, že bez jejich provedení může dojít k selhání aplikace. Specifikováním procesů dojde ke sjednocení procedur vykonávaných zaměstnanci a zároveň k jejich optimalizaci na základě zkušeností zaměstnanců. Závěrem je nutné podotknout, že ani formální dokumentace procesu nemusí zákonitě znamenat zajištění kvality výstupu procesu. Je-li proces postaven špatně, jeho písemná podoba problémy nevyřeší. Je potřeba pravidelně kontrolovat, zda zaměstnanci plní stanovený proces, zda proces optimálně podporuje stanovené cíle či zda je potřeba jej aktualizovat.
53
5.2.3
Zdrojový kód a konvence
PHP je nejrozšířenější skriptovací jazyk určený pro vytváření dynamických internetových stránek a webových aplikací. Podle měření W3Techs19 je PHP použito téměř u 78% webových projektů [33]. Za rozšířením PHP mohou jeho velmi svobodné licenční podmínky, nízké nároky na programátory (snadné k naučení) a mnoho zdarma dostupných frameworků (Zend, Nette, Symfony, CakePHP) včetně existujících řešení pro správu obsahu či publikačních systémů. Vysoká rozšířenost sebou přináší mnoho odlišností v konvencích užívaných jednotlivými PHP vývojáři. PHP je také velice oblíbené mezi začínajícími programátory webových aplikací a ti si většinou vytvoří vlastní styl psaní zdrojového kódu. Při vývoji aplikace v týmu je důležité, aby byl zdrojový kód pochopitelný a čitelný pro všechny členy týmu bez ohledu na to, kdo je autorem kódu. Tento stav lze zajistit stanovením konvencí pro psaní zdrojového kódu. Při určování konvencí mají programátoři v zásadě dvě možnosti, převzít již existují konvence z jiného projektu nebo si vytvořit vlastní. První možnost je časově méně náročná na ustanovení konvencí a navíc zajištuje, že budou použity obecně uznávané standardy20. Vytvoření vlastních konvencí či přizpůsobení převzatých konvencí vyžaduje více námahy, naopak je ale zaručeno, že si tým bude s konvencemi lépe rozumět. Navíc jsou-li konvence zaváděny až v pozdější fázi vývoje softwaru může být přizpůsobení zdrojového kódu značně odlišným konvencím velice náročná operace. Již během sepisování mé diplomové práce si vývojový tým uvědomil potřebu formálně zachytit konvence používané pro psaní zdrojového kódu a sjednotit styl jednotlivých programátorů. Za tímto účelem byl založen dokument na Google Dokumentech, v rámci kterého byla programátory diskutována budoucí pravidla pro psaní zdrojového kódu. Jako výchozí předloha byly použity konvence stanovené v Zend Frameworku, což je jeden z nejrozšířenějších frameworků pro tvorbu webových aplikací a jeho konvence bývají často přejímány i jinými projekty. Shodou okolností v nedávně době proběhla diskuze v rámci GitHub21 na téma konvence v PHP [34]. Cílem diskuze bylo sjednocení obecných pravidel pro psaní zdrojového kódu v PHP. Na tvorbě obecných pravidel se podílela komunita PHP vývojářů, přičemž hlasovací práva o přijatých pravidlech byla přidělena pouze 23 odborníkům z oboru (vývojáři předních webových aplikací a zástupci velkých firem). Závěry této diskuze zahrnující vypracovaná obecná pravidla pro psaní zdrojového kódu byly též použity při navrhování firemních konvencí. Při přijetí nových konvencí či sjednocení těch stávajících vzniká otázka, co provést s již naimplementovaným kódem, který nesplňuje nové konvence. Úprava stávajícího kódu může být velice náročná a vyžaduje znovu otestovat celou aplikace. Vývojový tým se proto dohodl, že úpravy existujícího kódu budou prováděny po částech v rámci nově zpracovávaných úkolů. To znamená, že pokud programátor bude pracovat na nové implementaci a narazí při tom na kód, který není v souladu s nově stanovenými konvencemi, tak tento kód s konvencemi sjednotí.
19
W3Techs – Internetový projekt zabývající se měřením používaných technologií na webu. Poskytuje statistiky o nejpoužívanějších systémem pro správu obsahu, programovacích jazycích, javascriptových knihovnách, kódování znaků, formátu obrázků a mnoha dalších elementů související s webovými aplikacemi. 20 Například při vývoji open source projektů bývá zvykem, že jsou dodržovány obecně rozšířené konvence. 21 GitHub – webová služba pro správu softwarových projektů, které používají Git jako systém pro správu verzí. GitHub je hojně využíván pro „open source“ projekty (software jehož zdrojové kódy jsou veřejně dostupné)
54
V rámci konvencí je řešeno i psaní komentářů ve zdrojovém kódu, nicméně problematice klíčových slov TODO a FIXME zde není věnována dostatečná pozornost. Při rozboru kódu jsem zjistil, že kód obsahuje vyšší počet komentářů s klíčovými slovy TODO a FIXME. Na jejich vyřešení bývá relativně často zapomenuto. Aby tyto komentáře a především problémy, na které upozorňují, nezůstávaly ve zdrojovém kódu déle, než je nezbytně nutné, doporučuji komentáře označit číslem úkolu22. Pokud se problém vyznačený komentářem netýká žádného úkolu, založí autor komentáře v systému nový úkol, kde popíše vyznačené problematické místo v kódu. Přiřazením čísla úkolu ke komentáři bude zajištěno, že problém je evidován i v systému pro správu projektů a manažer může jeho opravu snadno přidělit konkrétní osobě. 5.2.4
Dokumentace a báze znalostí
Dokumentace je důležitým zdrojem informací v rámci celého životního cyklu softwarového produktu. Ve firmě je třeba vyřešit, kde a jaká dokumentace bude evidována. Například specifikaci požadavků lze u některých projektů nalézt v emailových konverzacích, přímo u projektu, v zadání úkolů či v Google dokumentech. Výše uvedené kanály mohou být vhodné pro sběr požadavků, ale pro získání přehledu o projektu je potřeba, aby veškeré související informace (specifikace požadavků, návrh, aj.) byly dostupné pohromadě. Tím je také zajištěno, že do problematiky konkrétního projektu může být snadno zasvěcen i zaměstnanec, který se na projektu nepodílí od začátku. K vyvíjenému redakčnímu systému není téměř dostupná žádná technická dokumentace určená pro programátory, což může znesnadňovat vývoj systému. V rámci konvencí psaní zdrojového kódu byla vyřešena i otázka okomentování funkcí a metod v aplikaci. Prostřednictvím těchto komentářů je možné alespoň vygenerovat referenční dokumentaci, která poskytne přehled o dostupných třídách a jejich metodách v rámci systému. Referenční dokumentaci lze dále rozšířit o příklady užití jednotlivých metod či celých komponent v závislosti na různých parametrech a nastavení. Na příkladech může programátor neznalý konkrétní implementace získat lepší představu o tom, jak aplikace funguje. Uživatelská dokumentace je určena pro běžné uživatele, proto musí být psána jednodušeji než dokumentace technická, aby bylo čtenáři z popisu jasné, co a jak aplikace umožňuje. Uživatelskou dokumentaci je vhodné doplnit o snímky obrazovky z aplikace, ve kterých se uživatel lépe orientuje na rozdíl od jejich textového popisu. Tvorbu uživatelské dokumentace lze provést tak, že jsou nejprve vytipovány klíčové oblasti a operace aplikace, které budou zdokumentovány. Následně autor dokumentace popíše tyto oblasti tak, že prochází popisovanou aplikaci a přesně dokumentuje, co se v aplikaci nachází a jaké kroky jsou potřeba k určitému úkonu. Díky tomu, že autor při dokumentaci aplikaci prochází a sám si zkouší jednotlivé postupy, může při tom odhalit logické chyby či špatnou použitelnost uživatelského rozhraní. Tento postup sepisování dokumentace lze přirovnat k testování průzkumného charakteru, kdy se tester s aplikací také seznamuje. Vytvořením uživatelské dokumentace lze předejít často opakujícím se otázkám, ze strany uživatelů aplikace. I dokumentaci (uživatelskou i programátorskou) je nutné udržovat aktuální, aby korespondovala s požadavky a implementací. Vyhodnocení, zda dochází k průběžné aktualizaci dokumentace, je další z klíčových aktivit zajišťování kvality.
22
V systému pro správu projektů, který vývojový tým používá, jsou evidovány jednotlivé úkoly s jednoznačným číselným označením.
55
Znalostní báze Jak jsem již několikrát zmínil, členové vývojového týmu si mezi sebou vyměňují zkušenosti a zajímavosti z oblasti vývoje webových aplikací nejčastěji prostřednictvím emailové komunikace. Pro diskuzi nad určitou problematikou se jedná o užitečný kanál. Výsledky těchto diskuzí a zajímavé poznatky však končí na dně emailové schránky. Potýká-li vývojář s nějakým problémem a vzpomene-li si, že podobný problém byl již vyřešen někdy v minulosti v rámci emailové konverzace, může být pro něj obtížné řešení v došlé poště vyhledat. Řešení této situace může nabídnout založení báze znalostí. Znalostní báze je platforma, která umožňuje sdílení znalostí napříč organizací. Pro znalostní báze je charakteristická především kategorizace dat a užití metadat23 vztahující se k uloženým informacím. Metadata umožňují snadné vyhledávání v informacích včetně filtrování nalezených výsledků. Klíčovým prvkem moderních znalostních bázi je i sociální vrstva zahrnující možnost kladení otázek a vést diskuzi k uloženým informacím. Jednoduché znalostní báze jsou podobné wiki systémům 24 . Ty komplexnější jsou dokonce schopny na základě uložených dat zodpovědět uživatelovu otázku. Pro potřeby analyzované firmy pro začátek postačí centralizované místo pro evidenci znalostí podporující snadnou kategorizaci dat a vyhledávání (viz například TeamLab v kapitole věnované doporučeným nástrojům). 5.2.5
Nová verze systému
Při specifikaci požadavků je možné, že vývojovým tým zjistí, že některé nové požadavky mohou být v rozporu se stávající implementací a nelze je snadno naplnit. Jiné nedostatky v softwaru naopak nebude možné odstranit, aniž by nedošlo k narušení zpětné kompatibility (fragmenty nepoužívaného zdrojového kódu). Vývojový tým počítá proto do budoucna s vytvořením nové verze CMS, která s největší pravděpodobností nebude zpětně kompatibilní s těmi stávajícími. Zpětně nekompatibilní verze nelze vytvářet příliš často, proto by se mělo zajistit, že tato nová verze bude opravovat co možná nejvíce problematických míst. Je důležité nepodcenit specifikaci těchto zásadních změn. Pokud budou změny v nové verzi navrženy jednorázově nebo během krátké doby, hrozí možnost, že nebudou zohledněny všechny aspekty, které by mohla nová verze řešit. Navrhuji proto založit nový v systému pro správu projektů nový projekt, do kterého budou průběžně zapisovány současné problémy, které nelze ve stávající verzi systému snadno vyřešit, a návrhy optimalizací, které nejsou svou povahou zpětně kompatibilní. Příkladem úkolů k novému projektu může být:
Zavedení jmenných prostorů a rozdělení zdrojového kódu (tříd) do hierarchických celků Optimalizace vrstvy pro komunikaci s databází (podpora načítání dat napříč více tabulkami, atd.)
Před zahájením realizace nové verze by tyto úkoly posloužily jako cenný zdroj pro specifikaci požadavků na novou verzi systému.
23
Metadata – data o datech. Metadata popisují objekt, ke kterému se vztahují (např. metadata o knize mohou zahrnovat stručný obsah, jméno autora, žánr, kde se kniha v knihovně přesně nachází, aj.) 24 Wiki - označení pro webovou aplikaci, která uživatelům umožňuje rychlé vytváření textového obsahu a jeho snadnou správu.
56
5.3 Proces zajištění kvality Zajišťování kvality softwarového produktu je úzce spjato s procesem vývoje softwaru. Jedná se o podpůrné činnosti zajišťující dosahování požadovaných kvalit v jednotlivých fázích vývoje. V následujících několika podkapitolách jsou uvedeny některé klíčové činnost z oblasti zajištění kvality, které se mohou významně podílet na zvýšení kvality vývojového procesu. Začlenění zajištění kvality do procesu vývoje Úkolem zajištění kvality je předcházení vzniku chyb či je alespoň jejich včasné odhalení. Z tohoto důvodu je třeba průběžně kontrolovat výstupy jednotlivých fází vývoje. V rámci zajištění kvality je během vývoje ověřováno, zda se formálně zaznamenaná specifikace shoduje s požadavky, zda návrh pokrývá veškerou specifikaci, zda je systém naimplementován dle návrhu a zda se při nasazování systému neobjevily nějaké chyby. Většina projektů firmy je postavena na přizpůsobení existujícího řešení novým požadavkům klienta. U projektů tedy není návrh vytvářen od začátků, ale je upravován stejně jako systém samotný. Při provádění úprav je vyšší šance, že nebudou rozeznány všechny odlišnosti mezi již existujícím řešením a novými požadavky. Kontrolou návrhu oproti specifikaci lze toto riziko snížit a zavčas předejít potížím, které by se projevili až v pozdějších fázích vývoje. V rámci každého projektu je třeba jasně definovat, kdo bude zodpovědný za ověření specifikace s požadavky či návrhu se specifikací a jakým způsobem bude ověření probíhat. Další důležitou aktivitou zajišťování kvality v oblasti procesu vývoje je testování. Této problematice je však věnována samostatná kapitola, viz dále. Analýza firemních procesů a pravidel Mezi hlavní činnosti zajištění kvality patří také rozbor stávajících firemních procesů a pravidel stanovených pro dosažení vyšší kvality softwaru. Svým způsobem analýza, kterou jsem provedl, byla ukázkou toho, jak takový rozbor probíhá. Je potřeba aktivně vyhledávat potencionálně slabá místa, která se mohou negativně promítnout na kvalitě vyvíjeného systému. Dále má zajištění kvality na starosti vyhodnocovat dodržování procesů, případně zjistit, proč dochází k obcházení stanovených procedur či pravidel. Na základě získaných poznatků jsou přijata nová opatření. Informace o chybách a jejich opravách mohou mít obrovský přínos pro analýzu. Proces zajištění kvality softwaru je závislý na dostatku potřebných informací, aby bylo možné navrhovat změny vedoucí k vyšší kvalitě softwaru. Při uzavírání reportovaného problému by proto měla být v hlášení uveden typ a příčina chyby, pokud ji lze jednoznačně rozlišit. Uvedení příčiny poskytne důležité informace pro zajištění kvality softwaru, neboť bude možné na základě hlášení oprav identifikovat nejčastější příčiny chyb v systému a přizpůsobit stávající procedury a pravidla tak, aby k podobným chybám v budoucnu již nedocházelo tak často, ideálně vůbec. Opakující se příčiny mohou upozornit na problém v prováděné proceduře či na potřebu zaměřit testování specifickým směrem, aby byly podobné chyby odhaleny dříve. Jak jsem již uvedl v úvodní části návrhu, je v současné době nepravděpodobné, že by v takto malé firmě byl vyhrazen speciální tým určený pouze pro zajišťování kvality. Odpovědnost za tuto aktivitu připadne na stávající zaměstnance, kteří ovšem mohou mít dostatek své vlastní práce. Analýza nemusí být nutně prováděna aktivně. Problematická místa lze odhalit při rutinní činnosti, opravování
57
opakujících se chyb, a podobných problémech při realizaci projektu. Důležité je, aby zaměstnanec, který problém objeví, na něj upozornil ostatní a společnými silami se jej pokusili odstranit. Zajištění dodržování stanovených pravidel a procedur Písemné zpracování konvencí a procedur samo o sobě automaticky nezaručuje zvýšení kvality softwaru. Aby bylo dosaženo požadované kvality, musejí být tyt postupy také řádně dodržovány. Je nutné zaměstnance s postupy seznámit a případně je i zaškolit. Dále je také potřeba, aby veškerá dokumentace byla k dispozici na přístupném místě, kategorizována do logických celků a snadno dohledatelná například dle klíčových slov. Pro zajištění dodržování stanovených pravidel a procedur přišel vedoucí programátorského týmu i s nápadem zavést jistý druh trestů, nebo lépe řečeno pokut. Pokud programátor opomene provést při vývoji některý zásadní krok, jako například nahrání zdrojových souborů na server bez jejich uložení do systému pro správu a verzování zdrojových kódů (SVN), či poruší některou ze zásadních konvencí pro psaní zdrojového kódu, musí zaplatit pokutu. Pokuty by se řídily stanoveným ceníkem a jejich výše by měla spíše symbolický význam. Celkový vybraný obnos by byl použit pro rozvoj firmy například v podobě nákupu licencí nových nástrojů a podobně. Nápad vznikl spíše z recese, ale zaměstnanci jej přijali. Zatím však nebyl uveden ve skutečnost, protože dosud nebyla stanovena pravidla a procedury, na které by se pokuty odkazovaly. Obecně však tento způsob zajišťování dodržování pravidel není nejvhodnější. Chybovat je lidské a trestat zaměstnance za chyby může vést k jejich demotivaci a snížení jejich vlastní iniciativy podle hesla „kdo nic nedělá, nic nezkazí“. Vzhledem k velikosti firmy však předpokládám, že na podrobném popisu jednotlivých procesů se budou podílet všichni členové vývojového týmu. Formálně zachycené procedury by se neměly nějak výrazně lišit od těch současných intuitivně prováděných. Přínos metody „cukru a biče“ ukáže až čas a je také velice možné, že se na pokutách mnoho nevybere, protože zaměstnanci se budou snažit postupy dodržovat z vlastní vůle, obzvláště podíleli-li se na jejich vytvoření. Zpětná vazba Vedoucí vývojového týmu pořádá pravidelně jednou z půl roku osobní ohodnocení programátorů společně s rozborem jejich činnosti. Zaměstnanci naopak poskytují návrhy, co a jak ve firmě optimalizovat, aby bylo dosaženo vyšší kvality vyvíjeného systému či snížení nákladů. Každému ze zaměstnanců je dán prostor pro jeho nápady. Může je vyjádřit před celým týmem nebo při soukromém hodnocení s vedoucím týmu. Návrhy je samozřejmě možné konzultovat během celého roku a vzhledem k velikosti firmy se do diskuze může zapojit každý ze zaměstnanců. Zpětná vazba a diskuze nad činností ve firmě je jedním z vhodných prostředků zajištění kvality. Tým zaměstnanců zde funguje zároveň jako tým zajišťující kvalitu. Zaměstnanci jsou dennodenně ve styku s firemními procesy a pravidly a jsou do jisté míry kompetentní poskytnout názor na jejich přínos. Firemní atmosféra podporující zaměstnance v přicházení s vlastními nápady, které mohou být cenným přínosem při optimalizaci firemních procesů. Je však důležité, aby se přijaté nápady dostaly do podvědomí všech zaměstnanců.
5.4 Testování Testování softwaru vyžaduje specializovaný tým, lidi zabývající se testování, kteří mají zkušenosti. Je obecně známo, že programátoři, kteří aplikaci vytvořili, odhalí při testování méně chyb než 58
specializovaný tester. Testování aplikace programátory, kteří ji vytvořili, povede ke špatným výsledkům, protože je velice nepravděpodobné, že tito programátoři odhalí při testování chyby, které neodhalili při implementaci a ladění aplikace. V praxi se můžeme setkat s různým poměrem počtu testerů k počtu programátorů. Alan Page v knize „Jak testuje software Microsoft“ uvádí, že v Microsoftu je tento poměr dokonce roven jedné, to znamená, že na jednoho programátora připadá jeden tester [35, s. 52]. Průzkum zabývající se problematikou kvality a testování v České republice dochází k podobnému závěru u firem do sta zaměstnanců, kde na 1 testera v průměru připadá 1,1 programátora. U firem s větším počtem zaměstnanců na 1 testera připadá 3,8 programátora [36, s. 103]. V analyzované firmě není vyhrazen specializovaný tester. Zaměstnanci se v testování střídají na základě volného času a složitosti testování. Dle dostupných dat však nedokáži objektivně posoudit, zda je toto řešení dostačující či nikoliv. Je jím alespoň zaručeno, že práce jednoho programátora je překontrolována někým jiným. Je také možné, že po zavedení formalizovaného procesu testování se firmě již vyplatí zaměstnat specializovaného testera. Testování ve firmě má velice neformální charakter, není přesně stanoveno, co, kdy a jak se bude testovat. Testování se zde používá především pro obecné ověření naplnění požadavků. Výstupem testování jsou nově nahlášené chyby nebo potvrzení správnosti implementace bez detailní zprávy, co a jakým způsobem bylo otestováno. Reporty z testování, ať již při něm byly či nebyly objeveny chyby, se mohou jevit jako pouhá formalita. Lze z nich však třeba zpětně vyčíst, proč některé chyby nebyly při testování odhaleny, na základě čehož může být přizpůsoben proces testování do budoucna. Tester si zároveň při psaní reportu lépe uvědomí, které části aplikace nevěnoval dostatečnou pozornost, nebo jej napadne další nápad k otestování, který jej nenapadl při navrhování testovacích případů. Reporty z testování by měly obsahovat minimálně následující informace:
Jaké testy byly provedeny a s jakým výsledkem Jaké chyby byly při testování objeveny Tester může také uvést svůj osobní názor na testovaný software, přičemž lze hodnotit i vlastnosti softwaru, které nebyly předmětem testování.
Pro podrobnější zasvěcení do problematiky testování webových aplikaci a testování obecně doporučuji využít příručku Testování webových aplikací založenou na diplomové práci Mgr. Anny Borovcové. Příručka je volně dostupná ke stažení na adrese www.testovanisoftwaru.blogspot.cz . 5.4.1
Doporučené testovací techniky
Jak jsem již uvedl v teoretické části, testovacích technik existuje celá řada. V rámci této podkapitoly jsem proto vybral několik základních způsobů testování, na které by se firma měla především zaměřit. Jednotkové testy Jednotkové testy jsou určeny k otestování jednotlivých tříd a metod. Tyto části se testují samostatně nezávisle na celém systému. Testy jsou zapisovány ve formě programového kódu, proto jsou zpravidla vytvářeny přímo programátory. Lze je navíc provádět automatizovaně a opakovaně, tudíž jsou vhodné pro použití při regresním testování (viz dále). Výhodou jednotkových testů je včasné odhalení chyby ve zdrojovém kódu, neboť testy jsou prováděny po dokončení implementace
59
metody či jiné jednotky. Jednotkové testy zaručují, že bude otestována převážná část zdrojového kódu. Jednotkové testy jsou silně závislé na architektuře softwaru a implementaci jednotlivých metod (musí být co nejvíce soběstačné, nezávislé na zbytku systému, aj.). Pokud na jednotkové testování není myšleno již od začátku vývoje softwaru, může být velice obtížné provádět jednotkové testy na již existujících projektech, což je i případ analyzované firmy a jejího redakčního systému. Před začleněním jednotkového testování by proto bylo nutné nejprve posoudit implementaci systému z pohledu kompatibility s jednotkovými testy a zvážit možnost refaktoringu25 částí aplikace, které nejsou s jednotkovými testy kompatibilní. V případě, že by se investice do refaktoringu nevyplatila, ať již časově či finančně, doporučuji zvážit možnost jednotkových testů alespoň v budoucnu při návrhu nové verze systému. Revize kódu Při revizi zdrojového kódu je kód kontrolován někým jiným než autorem, obvykle jiným členem programátorského týmu. Cílem revize kódu je snížit počet chyb ve zdrojovém kódu způsobených nepozorností programátora. Hodnotitel může také poskytnout svůj pohled na čitelnost a pochopitelnost kódu a zároveň se přiučit novým implementačním řešením, které jeho kolega ve zdrojovém kódu použil. Při revizi je kontrolováno i dodržování stanovených konvencí. Revizi kódu lze provádět jednak po každém commitu26 nebo po ucelených funkčních částech aplikace [37]. V prvním případě je zajištěno, že je zkontrolována každá změna ve zdrojovém kódu. Nevýhodou je však vyšší pracnost a časové zatížení revizora kódu. Kontrolu každé změny v kódu také není vhodné provádět v počáteční fázi vývoje, kdy se většina zdrojového kódu nachází v rozpracovaném stádiu. Při revizi kódu po funkcionalitách je patrnější logická návaznost jednotlivých částí zdrojového kódu, nicméně při tomto přístupu hrozí, že část kódu revizí neprojde. Nedostatky objevené při revizi kódu lze v závislosti na jejich závažnosti reportovat podobným způsobem jako klasické chyby objevené při testování. Ty drobnější lze označit přímo ve zdrojovém kódu pomocí klíčových slov TODO či FIXME a upozornit na ně autora zdrojového kódu. Otestování funkcionality Funkcionalitu systému lze porovnat přímo vůči specifikaci, pokud je dostupná a dostatečně podrobná, nebo lze vytvořit mezičlánek mezi specifikací a testovanou aplikací v podobě testovacích scénářů. Na základě specifikace jsou navrženy možné situace, scénáře, které by aplikace měla pokrývat. Ve scénáři je definován výchozí stav, ve kterém se aplikace musí nacházet před zahájením provádění postupu ze scénáře, dále je zde uveden v krocích celý postup a na závěr je specifikována očekávaná reakce systému po dokončení uvedených kroků. Testovací scénáře se připravují před zahájením testování a předchází jim tvorba testovacích nápadů. Seznam testovacích nápadů obsahuje návrhy testů, které by stálo za to na aplikaci ověřit. Jednotlivé scénáře lze převést do programového kódu a následně je nechat samostatně vykonat softwarovým nástrojem. Převod testovacích scénářů na testovací skripty je vhodné provádět 25
Refaktoring - změny v softwarovém produktu, které nemají vliv na jeho vnější chování, tzn. optimalizace a jiné úpravy zdrojového kódu, které nikterak neovlivní funkcionalitu a jiné vlastnosti softwaru. 26 Commit – anglický výraz pro potvrzení změn ve zdrojovém kódu a jejich následné uložení do systému pro správu zdrojových souborů
60
v případě, že testy budou spouštěny opakovaně, což je u dlouhodobě vyvíjeného systému velmi pravděpodobné. Ze stejného důvodu je také vhodné jednotlivé scénáře evidovat, aby je bylo možné znovu použít. Při použití existujících scénářů a skriptů je nutné zohlednit dobu, kdy vznikly a zda byly aktualizovány společně se změnami provedenými v softwaru, pro jehož otestování jsou určeny. Ve firmě je také kladen důraz spíše jen na pozitivní testy, tedy ověření, zda aplikace po zadání správných vstupů provede očekáváný výstup. Při testování je však potřeba otestovat všechny možné větve průběhu zpracování dat, tedy i schopnost aplikace vypořádat se s nepředpokládanými vstupy. Rozdíl mezi negativními a pozitivními testy dobře zachycuje následující příklad – Do košíku v internetovém obchodě lze vložit x kusů zboží:
Pozitivní test – Tester otestuje funkcionalitu pro 1 či 2 kusy. Negativní test – tester otestuje chování aplikace při zadání 0 kusů, záporných čísel, extrémně vysokých hodnot, nevyplnění pole, zadáním textového řetězce a podobně.
Při testování funkcionality si je mnoho testů podobných. Webová aplikace jsou založeny především na formulářích a jejich zpracování. Proto je velká pozornost soustředěna na hodnoty zadávané do formuláře a chování aplikace po odeslání formuláře. Testované hodnoty pro různé formulářové prvky se často opakují. Aby tester neopomenul otestovat některou možnost, zakládají se pro testování takzvané katalogy testovacích případů. Jedná se o souhrnný přehled možností, jak otestovat určitý prvek aplikace. Například pro formulářové prvky mohou být v katalogu definovány následující možnosti:
Čísla - hraniční hodnoty (rovno, větší, menší než x), nula, záporná čísla, extrémně vysoká čísla Textové řetězce – přítomnost speciálních znaků (diakritika, různé symboly), html a javascriptový kód, extrémně dlouhý text, prázdný řetězec či pouze mezera Nevyplnění formulářového pole
Vytvoření a používání katalogu usnadňuje testování a zároveň jej dělá účinnějším, protože jsou vždy otestovány všechny problematické hodnoty a možnosti. Podobně jako jiné dokumenty i katalog testovacích nápadů je potřeba přizpůsobovat novým podmínkám danými směrem vývoje softwaru. Testování bezpečnosti Bezpečnost aplikace bývá často podceňována. Při specifikaci požadavků, vývoji i testování se ji nedostává takové pozornosti jako třeba funkcionalitě. Svým způsobem je to i logické, protože správná funkcionalita je to, co uživatelé očekávají. A pokud se již bezpečnost testuje, je pozornost soustředěna pouze na mechanismy autentifikace a autorizace, tzn. přihlašování a uživatelská oprávnění. Ovšem bezpečnost aplikace není radno podceňovat. Zabezpečení dat je uloženo i ze zákona. Zpracovávají-li se v rámci aplikace osobní údaje, je správce a zpracovatel, dle paragrafu 13 zákona o ochraně osobních údajů, povinen přijmout taková opatření, aby nemohlo dojít k neoprávněnému nebo nahodilému přístupu k osobním údajům, k jejich změně, zničení či ztrátě, neoprávněným přenosům, k jejich jinému neoprávněnému zpracování, jakož i k jinému zneužití osobních údajů. Tato povinnost platí i po ukončení zpracování osobních údajů [38]. Za osobní údaje jsou považovány ty informace, podle kterých lze jednoznačně identifikovat konkrétní osobu. Tyto informace (jméno, příjmení a adresa) vyžaduje ke svému provozu většina internetových obchodů.
61
Testovat bezpečnost webové aplikace lze automaticky stejným způsobem, kterým se testuje funkcionalita systému. Při automatizován testování bezpečnosti jsou vyhledávány formulářové prvky, do kterých jsou následně vkládány určité hodnoty. Sleduje se, jak se systém po odeslání formuláře zachová a jaké vrací výstupy. Rozdíl oproti testování funkcionality zde spočívá v tom, že zadané hodnoty obsahují speciální řetězce, které mohou zneužít bezpečnostní díry v aplikaci [39]. Pro správu těchto řetězců lze opět využít katalog testovacích nápadů. Automatické odzkoušení však mnohdy nestačí. Kombinaci možností a vyhodnocené musí provést tester zkušený v problematice bezpečnosti webových aplikací. Automatizovaný nástroj nedokáže myslet jako útočník a není tak schopen pokrýt veškeré potencionální bezpečnostní díry systému. Pro odhalování slabin je určeno takzvané penetrační testování, při kterém se tester snaží proniknout do aplikace nedovoleným způsobem. Při penetračním testování jsou důležité zkušenosti se slabinami webových aplikací a znalost systému včetně zdrojových kódu je velikou výhodou. Jako testery je v tomto případě vhodné ve firmě zvolil přímo programátory. Ti mají oproti ostatním zaměstnancům firmy větší znalosti systému a mohou tak lépe odhadnout, kde se může skrývat potencionální bezpečnostní riziko. Pro testování bezpečnosti jsou také potřeba znalosti z oblasti zranitelnosti webových aplikací. Pokud tyto znalosti nemá nikdo z řad zaměstnanců firmy, je výhodnější, aby byli v této oblasti vzděláni především programátoři. Ti pak nejenže mohou otestovat aplikaci z pohledu jejího zabezpečení, ale nabyté zkušenosti mohou zároveň zužitkovat pro snížení potencionálních bezpečnostních hrozeb implementací vhodných protiopatření. Programátory lze pro testování bezpečnosti motivovat například podpořením soutěživosti mezi nimi ve smyslu, kdo z nich nalezne v systému slabé místo. Při hledání programátoři navíc získají další zkušenosti, jež mohou následně využít. Regresní testování Regresní testy spočívají v otestování dříve již úspěšně otestovaných funkcí a vlastností, které mohly být ovlivněny přidáním nové funkcionality či aktualizací té stávající. Smyslem regresního testování je ověření, že provedené změny nikterak neovlivnily stávající funkce systému. Z povahy regresních testů vyplývá, že jsou prováděny opakovaně (při změnách v systému), proto je velmi vhodné tyto testy automatizovat. Vzhledem k vyššímu počtu chyb souvisejících s nekonzistencí dat v databázi (porušení vazeb cizích klíčů) by právě integrita databáze mohla být jednou z oblastí, která by mohla být opakovaně testována. Automatizovaný nástroj by mohl kontrolovat, zda jsou v databázi nastavena integritní omezení a zda všechna data v jednotlivých tabulkách tyto omezení splňují. Hlavním produktem firmy je redakční systém, který je dlouhodobě vyvíjen a prochází neustálými změnami. Automatizované regresní testy mohou být velice rychlým prostředkem, jak ověřit, zda při úpravách nedošlo k narušení fungujících částí systému. 5.4.2
Reportování chyb
Analýza odhalila, že většina reportovaných chyb neobsahuje veškeré informace ke snazší identifikaci chyby programátorem, což znesnadňuje opravu chyby. Co vše by takové hlášení o chybě mělo obsahovat je uvedeno v kapitole zaměřené na problematice reportování chyb (kapitola 3.2), proto zde jednotlivé položky nebudu znovu opakovat. Současný systém pro správu chyb obsahuje
62
v základu některé z atributů (viz Obrázek 4 - Ukázka hlášení o chybě). Ta jsou však spíše administrativního rázu (kategorizace chyby) a nevztahující se přímo k problému. Doporučuji vytvoření šablony vzorového chybového hlášení, které bude testery využíváno při zakládání nové chyby do systému. Tím bude zajištěno, že zpráva bude vždy obsahovat všechny potřebné náležitosti. Při vytváření šablony bych vycházel ze struktury jednotlivých položek tak, jak jsou uvedené ve výše zmíněné kapitole. Seznam položek bych zároveň rozšířil o následující atributy specifické pro webové aplikace a podmínky stanovené ve firmě:
Použitý webový prohlížeč – Chování webové aplikace je do jisté míry ovlivněno použitým internetovým prohlížečem. Chyba se může projevit pouze v některém z prohlížečů či je dokonce závislá přímo na konkrétní verzi prohlížeče. V hlášení by proto měl být uveden prohlížeč včetně verze. Tester by zároveň měl uvést, zda ověřil přítomnost chyby i v jiných prohlížečích.
Provozní prostředí – Jednotlivé projekty mohou být současně provozovány v několika prostředích (lokální, vývojářské, testovací, ostré). Je třeba specifikovat, na kterém prostředí se chyba projevila, protože objevený problém může souviset se specifickými podmínkami a konfigurací prostředí.
Databáze/data – Z rozboru jednotlivých chybových hlášení je patrné, že nezanedbatelná část problémů se vztahuje k databázi a nekonzistenci dat. Takové chyby se mohou projevit pouze za určité kombinace dat, které bez upřesnění nemusí být programátor schopen nasimulovat. Specifikováním databáze a konkrétních dat, na kterých se chyba projevila, usnadní její lokalizování.
Při zkoumání hlášení chyb jsem také zjistil, že se v systému pro evidenci chyb nachází větší množství dlouhodobě neuzavřených chybových hlášení. Tato hlášení nejenže znepřehlednění výpis seznamu otevřených chyb, ale za jejich vznikem stála chyba v systému a neuzavřený report naznačuje, že tato chyba dosud nebyla opravena. Je potřeba projít jednotlivé reporty a posoudit, zda se chyba v systému stále nachází a na základě toho opravu chyby přiřadit programátorovi k opravě nebo hlášení uzavřít jako vyřešené. Zabránit do budoucna podobné situaci lze určením maximální doby, po kterou může nahlášená chyba zůstat bez opravy. Po překročení této doby bude úkolem programátorů problém neprodleně odstranit bez ohledu na závažnost a prioritu chyby. V ideálním případě by však k takové situaci nemělo docházet a veškeré chyby by měly být opraveny v přijatelné době například vyhrazením určitého množství času k opravení chyb v závislosti na počtu nevyřešených problémů. 5.4.3
Chyby při provozu systému
Ne všechny chyby se podaří objevit během testování. Některé byly přehlédnuty, jiné jsou závisle na speciálních podmínkách, na které nebylo myšleno při vytváření testovacích nápadů, a další se mohou projevit až při dlouhodobějším používání systému. Po dokončení testování a schválení systému je software nasezen do ostrého provozu. Pokud se v té době stále nacházejí v systému chyby, je velice pravděpodobné, že budou objeveny uživateli aplikace. S touto možností je třeba počítat a proto je třeba provozní prostředí nastavit tak, aby se chyby neprojevovaly ve své surové podobě jako například chybová hlášení s výpisem zdrojového kódu včetně označených čísel problematických řádků v kódu. Pro běžné uživatele jsou tyto informace zbytečné a naopak snižují 63
jejich důvěru v aplikaci. Výpis chyb se zdrojovým kódem také prozrazuje informace o aplikaci, které by mohl využít útočník při pokusu o průnik do aplikace. U webových aplikací bývá zvykem, že veškeré výjimky a jiné problémy jsou systémem při běžném používání zachyceny a uživateli prezentovány jako obecné selhání aplikace doplněné o informace, jak postupovat dále (např. kontakt na administrátora). I na takto zamaskované chyby je třeba myslet a opravit je v rámci údržby aplikace. O chybách může být vývojový tým informován jednak od uživatelů, kteří chybu nahlásí, nebo použitím monitoringu či logování jako prostředku pro sledování neočekávaného chování softwaru. Monitoring slouží ke sledování dostupnosti webové aplikace a může včas upozornit správce systému na vyřazení aplikace z provozu. Dostupnost je jednou z dimenzí kvality webové aplikace a jako takovou je potřeba ji také zajistit. Čím déle je aplikace nedostupná, tím více jsou uživatelé nespokojeni. Navíc se nelze se spolehnout na to, že uživatelé upozorní správce systému na výpadek. Při logování je zaznamenávaná činnost systému nebo uživatelů. Aktivita společně s časem je obvykle zapisována do souboru, tzv. logu. Typicky se zaznamenává především výskyt chyb, je však možné logovat libovolnou událost, pokud je k tomu pádný důvod. Záznamy vztahující se k aktivitě uživatelů lze využít pro optimalizaci systému nebo pro zpětné dohledání příčin některých problémů. Logováním chyb je zase zaručeno, že nebudou přehlédnuty. Ovšem pouze v případě, že jsou záznamy kontrolovány. Zaznamenávání událostí bez pravidelné kontroly je stejné, jako kdyby události nebyly vůbec zaznamenávány. Logovací nástroje jsou však schopné v případě výskytu problému informovat správce zasláním emailu. Tím je zajištěno, že se správce aplikace dozví o aplikaci včas, respektive okamžitě po selhání aplikace. Automatizované nástroje lze také využít pro zpětné vyhodnocení logu, kdy jsou v záznamech vyhledávány neobvyklé údaje. Webové aplikace často disponují funkcionalitou, která je prováděna automaticky v pravidelných intervalech bez přičinění uživatele. Tyto automatizované skripty obvykle zajištují synchronizaci aplikace s jinou, provádějí pravidelnou úpravu dat, zálohují a podobně. Vzhledem k tomu, že automatický skript není spuštěn uživatelem ale strojem, který nerozlišuje, zda skript proběhl správně nebo skončil chybovým hlášením, je potřeba kontrolovat, s jakým výsledkem skript proběhl. Kontrolu lze zajistit nejlépe logování běhu skriptu do souboru nebo odesláním informačního emailu správci aplikace po dokončení běhu skriptu. Ne vždy je však chyba ve zdrojovém kódu a logovací nástroj ji proto nemusí zachytit. Nejlepší možností je, pokud součástí implementace aplikace je i logování kritických událostí. Zejména automatizované skripty by měly generovat po svém provedení výstup minimálně s následujícími údaji:
Datum spuštění skriptu – pro ověření zda byl skript opravdu spuštěn v požadovanou dobu.
Celková doba běhu skriptu – automatické skripty obvykle pracují s větším množstvím dat, jejichž zpracování může být časově náročně a nemusí se vejít do vyhrazeného času pro zpracování požadavku. Proto je vhodné vědět, jak dlouho skript data zpracovával a zda má dostatečnou časovou rezervu pro předpokládané potencionální navýšení objemu dat.
Výsledek skriptu - s jakým výsledkem automatická činnost proběhla, včetně detailů o tom, kolik záznamů bylo při zpracování ovlivněno či kolik emailů odesláno, atd.
64
Chybové hlášení - pokud činnost skriptu byla ukončena chybovým hlášení, je vhodné jej zanést do logu pro snazší identifikaci problému.
5.5 Metriky vyhodnocování kvality Pro vyhodnocení přínosů jednotlivých opatření v oblasti zajištění kvality je potřeba definovat metriky, na jejichž základě bude možné porovnávat přijatá opatření. Jednou z možností jak vyhodnotit zajištění kvality je porovnáním kvality produktu před a po zavedení zkoumaného opatření. Anna Borovcová ve své práci Testování webových aplikací dělí metriky pro hodnocení kvality do tří skupin [4, s. 61]:
Metriky založené na chybách – Tyto metriky reflektují skutečnost, že kvalita softwaru je úměrná přítomným chybám, neboť chyby snižují kvalitu softwaru. Samotný celkový počet chyb v softwaru však nelze využít pro přesné hodnocení kvality. Je potřeba zahrnout i další faktor, který poskytne potřebný rozměr pro vyjádření kvality v souvislosti s počtem chyb. Těmito faktory může být například čas, cena či specifický počet chyb. Jejich kombinací lze získat následující metriky [4, s. 63], [40]: o
Míra opravených chyb - poměr počtu opravených chyb k počtu nalezených chyb.
o
Efektivnost testu lze hodnotit poměrem počtem chyb objevených testem k celkovému počtu objevených chyb. Vyhodnocování efektivnosti testů lze zjistit, které testy se prokázaly jako užitečné a které naopak připravují testery o čas a bylo by výhodnější je nahradit testy efektivnějšími.
o
Přínos testů lze také vyjádřit vztahem mezi opravenými chybami, které test nalezl a celkovým počtem nalezených chyb.
o
Rychlost nalezení chyby se uvádí v počtu nalezených chyb za hodinu.
o
Cena nalezení chyby plyne z celkových nákladů investovaných k odhalení chyb.
o
Hustota chyb v aplikaci se uvádí jako počet objevených chyb ve vztahu k počtu řádků kódu, konkrétnímu projektu či za určité časové období (měsíc, rok)
Metriky založené na testech – Pro aplikaci je vytvořena skupina testů, kterými musí aplikace projít, aby byla shledána kvalitní. U softwaru lze sledovat, kolika testy aplikace prošla úspěšně a kolika nikoliv.
Metriky založené na kódu – Během testování aplikace je spouštěny různé části zdrojového kódu. Pokrytím větší části zdrojového kódu je zajištěna vyšší pravděpodobnost odhalení chyb. V rámci metriky založených na kódu je vyhodnocován procentuální poměr otestovaných a neotestovaných částí zdrojového kódu.
Výše uvedené metriky jsou určeny pro měřitelné aspekty softwaru, zejména oblast funkcionality. Některé vlastnosti, jako například použitelnost, je obtížné kvantitativně zachytit a tudíž i objektivně vyhodnotit.
65
5.6 Nástroje Na závěr jsem vybral několik volně dostupných nástrojů, které mohou firmě usnadnit vývoj softwaru a hodnocení jeho kvality. Vybrané nástroje jsou pouze mým doporučením, proto je zde uvádím jen se stručným popisem a odkazem na stránky projektů, kde se lze o vlastnostech a přínosech těchto nástrojů dozvědět více informací. TeamLab TeamLab by mohl být vhodnou alternativou ke stávajícímu systému pro správu projektů. TeamLab je webová aplikace určená pro správu projektů a spolupráci v menších firmách. Její základní funkcionalitu lze rozdělit do několika oblastí:
Projekty – Aplikace umožňuje tvorbu a správu projektů. Je zde možné zakládat milníky k projektům, přiřazovat úkoly zaměstnancům, diskutovat o záležitostech projektu, sledovat časový průběh projektu a vytvářet přehledné reporty o činnosti na projektu.
Komunita a spolupráce – Lze přirovnat k firemnímu intranetu. Nachází se zde přehled o zaměstnancích, firemní blog, novinky či přehled firemních událostí. Zaměstnanci mohou spolu komunikovat prostřednictvím diskuzního fóra či instant messagingu (okamžitá komunikace, chat). Součástí TeamLabu je správa a publikace článků (wiki) vhodná pro vytvoření firemní báze znalostí.
Dokumenty – V rámci TeamLabu je také možné sdílet dokumenty. Služba zahrnuje i nástroje pro jejich zobrazení i editaci přímo v okně prohlížeče. Dokumenty mohou být propojovány s evidovanými projekty. Samozřejmostí je i verzování dokumentů či nastavení, kdo má k jakým dokumentům přístup.
Customer relationship management (CRM) – Aplikace poskytuje i základní nástroje pro správu klientů (kontakty, archiv komunikace s klienty, aj.)
TeamLab lze využívat přímo na adrese projektu nebo pokud se firma obává o soukromí dat spravovaných prostřednictvím TeamLabu, může jej provozovat na vlastním serveru. Drobnou nevýhodou je ovšem nutnost použití serveru s operačním systémem Windows, pro který je TeamLab vytvořen. TeamLab je k dispozici i pro mobilní telefony. Adresa projektu: http://www.teamlab.com Eclipse Process Framework Composer EPF Composer je open source nástroj určený pro vytváření, správu a publikaci metodik a procesů zejména z oblasti vývoje softwarových produktů. Pro EPFC je již přepsáno několik metodik, mezi jinými například i Scrum, o jejímž použití vzhledem k podobnosti se současným způsobem vývoje firma uvažovala. Zároveň je vývoj EPFC doprovázen i vývojem agilní metodiky OpenUP určené pro malé projekty. Při použití EPFC tedy není nutné vytvářet jednotlivé metody a procesy od začátku, ale je možné využít některou z již existujících či přímo metodiku OpenUP, které má v EPFC přímou podporu. Metodiky lze samozřejmě v EPFC snadno přizpůsobovat firemním potřebám. Výhodou EPF Composeru je snadná údržba spravované metodiky. Jednotlivé objekty jsou zde patřičně rozděleny do patřičných kategorií (role, procesy, úkoly, dokumentace) a lze mezi nimi vytvářet logické vazby, což zaručuje značnou přehlednost celé metodiky. Klíčovou schopností je i 66
distribuce metodiky skrze webové stránky. Spravovanou metodiku lze snadno převést do HTML formátu a publikovat na webu. Adresa projektu: http://www.eclipse.org/epf/ Laděnka Laděnka je diagnostický nástroj určený k ladění aplikace, odtud plyne její název. Je součástí Nette Frameworku27, ale lze ji snadno implementovat do libovolného projektu. Lze ji využít k výpisu ladících informací jako je obsah proměnných či detailu chyby včetně výpisu přesného místa ve zdrojovém kódu, kde se chyba nachází (viz Obrázek 7 - Laděnka, ukázka výpisu chyby ). Její součástí je i Debugger Bar, který pro každou webovou stránku aplikace zobrazuje objem přenesených dat či celkovou dobu běhu skriptu (viz Obrázek 6 - Laděnka, Debugger Bar ).
Obrázek 6 - Laděnka, Debugger Bar [41]
Obrázek 7 - Laděnka, ukázka výpisu chyby [41]
Laděnka je schopna automaticky rozlišit mezi testovacím a produkčním režimem. V rámci testovacího prostředí zobrazuje veškeré ladící informace přímo v okně prohlížeče. Zatímco 27
Nette Framework - český Framework určený pro vytváření webových aplikací v PHP (www.nette.org)
67
v produkčním režimu zobrazuje v případě výskytu chyby pouze uživatelsky srozumitelnou zprávu. Veškeré chyby jsou v produkčním režimu logovány. Zároveň lze snadno zaznamenávat i vlastní události či si nechat zaslat na email informaci o novém záznamu v logu, což je užitečné pro okamžité upozornění na chybu v systému. Více informací o možnostech Laděnky je k nalezení v dokumentaci Nette Frameworku, respektive na adrese http://doc.nette.org/cs/debugging Selenium IDE Selenium je nástroj určený k automatizovanému otestování funkcionality webových aplikací. Jednotlivé testy jsou v rámci Selenia prováděny přímo v okně prohlížeče. Testy zahrnují posloupnost příkazů, které simulují chování uživatele na webové stránce (otevření stránky, kliknutí na odkaz, vyplnění formulářového prvku, odeslání formuláře, aj.). V rámci těchto příkazů je také specifikováno, jak má být v testu rozeznáno, zda došlo k očekávané reakci systému či nikoliv (přítomnost určitého řetězce v textu, přesměrování na konkrétní adresu, atd.)
Obrázek 8 - Selenium, plugin pro Firefox
Selenium je mimo jiné dostupné také jako rozšíření pro webový prohlížeč Firefox (Obrázek 8), který umožňuje snadnou tvorbu a spouštění testů. Testy je možné vytvářeč ručně výběrem předefinovaných příkazů doplněných o požadované parametry nebo automaticky. V případě automatického vytváření testu stačí zapnout funkci nahrávání a následně v prohlížeči provést operace, které chceme otestovat. Jenkins Jenkins je nástroj vhodný pro průběžnou integraci, neboť je schopen rychle a snadno ověřit, zda nově provedené změny v systému nezapříčinily jeho rozbití.
68
Jenkins usnadňuje tvorbu a provádění testů. Je schopen ověřit, zda je zdrojový kód v souladu s konvencemi či zda nevykazuje příznaky problematického kódu, označované jako coding smell čili „kouř v kódu, který obvykle značí požár“ (duplicitní kód, dlouhé metody, obsáhlé třídy, aj.). Jenkins dále umožňuje automatizované provádění jednotkových testů či je schopen upozornit na místa ve zdrojovém kódu, která nebyla testováním pokryta. Na výsledky jednotlivých testů je možné navázat vlastní skripty. Pro aplikaci Jenkins existuje celá řad pluginů, jejichž kombinací může vývojový tým zajistit adekvátní průběžné testování vyvíjeného systému. Adresa projektu: http://jenkins-ci.org/ JMeter Při testování výkonnosti webová aplikace je potřeba vytvořit dostatečnou zátěž, které odráží předpokládanou návštěvnost webové aplikace. Webová aplikace jsou dimenzované pro vysoký počet návštěvníků a proto je pro otestování výkonnosti zapotřebí použití specializovaného nástroje, který je schopen nasimulovat reálnou zátěž. Jedním z takových nástrojů je právě JMeter. JMeter je aplikace napsána v jazyce JAVA a disponuje grafickým rozhraním. Je určen pro vytváření zátěžových testů. Testy je možné vytvářet ručně nebo je zaznamenávat při procházení webové aplikace v prohlížeči (podobně jako u Selenia). U každého testu lze nastavit, kolik klientů má JMeter při testování simulovat. Je také možné zvolit postupný nárůst počtu virtuální uživatelů a sledovat tak, jak se systém vypořádává s narůstajícím objemem uživatelů. Adresa projektu: http://jmeter.apache.org RIPS RIPS je webový nástroj vytvořený v PHP určený pro statickou analýzu zdrojového kódu. Jeho specialitou je zaměření se na odhalování zranitelností webových aplikací postavených na PHP. Parsováním, neboli rozkladem, všech zdrojových souborů je RIPS schopen vytvořit model analyzovaného programu a detekovat potencionálně slabá místa, která mohou být zneužita k průniku do aplikace. RIPS je schopen detekovat zranitelnosti typu XSS, SQL injection a mnoho dalších. Zároveň výstupem RIPSu je detailní rozbor zdrojového kódu, který může být využit pro další manuální analýzu. Adresa projektu: http://rips-scanner.sourceforge.net/
69
6 Závěr Prvním cílem diplomové práce bylo odhalení slabých míst, snižující kvalitu softwarového produktu vyvíjeného v malé firmě. Za tímto účelem byla provedena analýza kvality vyvíjeného softwaru a rozbor procesu vývoje. Pozornost v rámci analýzy byla zaměřena na devět nejčastějších příčin softwarových chyb a dvou základních vlastností webových aplikací, bezpečnosti a přístupnosti. Analýza vycházela ze znalosti firemních procesů a vyvíjené aplikace, dostupné dokumentace, rozboru zdrojového kódu a informací ze systému pro správu projektů (hlášení chyb, zadání úkolů). Při rozboru současného stavu ve firmě bylo odhaleno několik problematických oblastí, které mohou být v konečném důsledku odpovědné za nižší kvalitu vyvíjeného systému pro správu obsahu. Ve firmě je k vývoji přistupováno intuitivně na základě dlouhodobých zkušeností s vývojem. Proces vývoje je již relativně ustálen a nedochází v něm k častým změnám. Proces však není formálně zachycen, což ponechává prostor pro jeho odlišnou realizaci. Písemně zachyceny jsou pouze některé procedury, ale ty nejsou dostatečně viditelné. Ověřování kvality pomocí testování je ve firmě omezeno pouze na potvrzení naplnění obecných požadavků a není mu přikládán dostatečný důraz, což dokazuje nesystematický přístup k testování. Zároveň je také přikládán nižší důraz na dokumentaci, návrh a specifikaci požadavků. Druhým cílem práce byl návrh zajištění kvality softwaru na základě zpracované analýzy. Návrh vychází z odhalených problémových míst a soustředí se na jejich vyřešení. Je zde počítáno s omezeními, které plynou z velikosti firmy a současně nastavených procesů. V úvodu návrhu je pozornost zaměřena na oblasti, které je před samotným zavedením procesu zajišťování kvality nutné vyřešit, tzn. především oblast specifikace požadavků a formální zachycení procesu vývoje. Ve druhé části návrhu jsou doporučeny aktivity pro hodnocení kvality softwaru a optimalizaci procesů s cílem zvýšit kvalitu vyvíjeného softwaru. V závěru návrhu je doporučeno několik nástrojů, které usnadňují vývoj a testování webových aplikací. V závěrečné části věnované návrhu řešení došlo z mé strany k odchýlení od původního záměru navrhnout proces zajištění kvality a pozornost byla věnována především doporučením, jak odstranit problematická místa v procesu vývoje, testování a kvality analyzovaného softwaru. Záměrem práce bylo především upozornit na potencionálně slabá místa, která mohou ohrozit kvalitu vyvíjeného softwaru, a zároveň doporučit základní opatření, která by zmiňovaná místa překlenula. Zajišťování kvality softwaru je běh na dlouhou trať. Je potřeba neustále vyhodnocovat jednotlivé firemní procesy, obzvláště samotný proces vývoje softwaru. Uvedený návrh lze považovat za první krok při zajišťování kvality softwaru. V rámci práce se tedy nepodařilo plně naplnit druhý stanovený cíl, respektive navrhnout proces zajištění kvality. V návrhu procesu byly pouze vymezeny aktivity procesu zajištění kvality, které firmě pomohou kontinuálně zlepšovat své procesy a kvalitu jejich výstupů. Pozornost byla soustředěna především na oblast testování, sdílení znalostí mezi zaměstnanci, zpětnou vazbu a vyhodnocování procesů. Současně však věřím, že se podařilo upozornit na většinu aktuálně problematických míst v procesu vývoje a kvality vyvíjeného softwaru a zároveň poskytnout náležitá doporučení, jak tato
70
místa překlenout. Důkazem čehož je i skutečnost, že vývojový tým začal na některých opatřeních již pracovat. Byl vytvořen dokument obsahující konvence pro psaní zdrojového kódu, na jejichž podobě se podílel celý vývojový tým. Do vyvíjené aplikace byla implementována Ladeňka, která vývojářů usnadňuje ladění aplikace a zároveň slouží jako vhodný nástroj pro logování chyb v ostrém provozu webové aplikace. V neposlední řadě je ve firmě zvažován přechod na jiný systém pro správu projektů, přičemž jako o jedné z možností je uvažováno o doporučeném TeamLabu. Práce ponechává některé otázky otevřené. Do budoucna je například třeba přesně specifikovat metriky, dle kterých bude kvalita softwaru ve firmě měřena, aby bylo možné vyhodnocovat opatření přijatá v rámci zajištění kvality. Předmětem dalšího postupu může být také formální specifikace procesu vývoje, který má na kvalitu vyvíjeného softwaru značný vliv.
71
Citovaná literatura 1.
GALIN, D. Software Quality Assurance: From Theory to Implementation. Pearson Education, 2004, 590 s.. ISBN 0201709457.
2.
LIBÍK, J. Zlepšování softwarových procesů v oblasti testování. Praha: 2011. Diplomová práce. Vysoká škola ekonomická v Praze, Fakulta informatiky a statistiky, Katedra informačních technologií. Vedoucí práce Ph.D. doc. Ing. Alena Buchalcevová. 95 s..
3.
FIURÁŠEK, I. T. Návrh metodiky testování webových aplikací. Praha: 2010. Diplomová práce. Vysoká škola ekonomická v Praze, Fakulta informatiky a statistiky, Katedra informačních technologií. Vedoucí práce Ph.D. doc. Ing. Alena Buchalcevová. 78 s..
4.
BOROVCOVÁ, A. Testování webových aplikací. Praha: 2008. Diplomová práce. Univerzita Karlova v Praze, Matematicko-fyzikální fakulta, Katedra teoretické informatiky a matematické logiky. Vedoucí práce Dr. Mgr. Vladan Majerech [cit. 2012-03-08]. Dostupné z: http:// testovanisoftwaru.blogspot.com/p/dptestovanisoftwarupdf.html
5.
KANER, C. J. BACH a B. PETTICHORD. Lessons Learned in Software Testing:A Context-Driven Approach. New York: John Wiley & Sons, 2011, 0471081124 s.. 320.
6.
MUKHERJEE, P.N. Total Quality Management. PHI Learning Pvt. Ltd. 2006, 436 s.. ISBN 8120330560.
7.
MISHRA, R.C. Modern Project Management. New Age International, 2006, 240 s.. ISBN 8122416160.
8.
HUTCHESON, M. L. Software Testing Fundamentals: Methods and Metrics. John Wiley & Sons, 2003, 434 s.. ISBN 0471468444.
9.
WEINBERG, G. M. Quality Software Management: First-order measurement. Dorset House Pub. 1993, 368 s.. ISBN 0932633242.
10. FREEMAN, R. E. Stockholders and Stakeholders: A New Perspective on Corporate Governance. Berkeley: University of California, Walter A. Haas School of Business, 1983, 25 (3). ISSN 00081256. 11. FREEMAN, R. E. Strategic management : a stakeholder approach. Boston: Pitman, 1984, 276 s.. ISBN 0521151740. 12. WANG, S.H. D. SAMADHIYA a D. CHEN. Software Quality: Role and Value of Quality Models. International Journal of Advancements in Computing Technology. Gyeongsang-bukdo: The International Association for Information, Culture, Human and Industry Technology, 2011, 3 (6), 65-74 [cit. 2012-03-10]. ISSN 20058039. Dostupné z: http://search.proquest.com.ezproxy.vse.cz/
72
docview/902801763?accountid=1720 13. EVANS, M. W. a J. J. MARCINIAK. Software Quality Assurance and Management. New York: John Wiley & Sons, 1987, 327 s.. ISBN 0471809306. 14. DEUTSCH, M. S. a R. R. WILLIS. Software quality engineering: a total technical and management approach. Englewood Cliffs (New Jersey): Prentice Hall, 317 s.. ISBN 0138232040. 15. GRADY, R. B. Practical software metrics for project management and process improvement. 2. Englewood Cliffs (New Jersey): Prentice Hall, 1992, 1992 s.. ISBN 0137203845. 16. EELES, P. What, no supplementary specification? IBM [online]. 1. 7. 2004 [cit. 2012-03-15]. Dostupné z: http://www.ibm.com/developerworks/rational/library/3975.html 17. PATTON, R. Testování softwaru. Překlad David KRÁSENSKÝ. Praha: Computer Press, 2002, 313 s.. ISBN 80-7226-636-5. 18. AVIDOR, R. Murphy's computers laws. Murphy Laws Site [online]. [cit. 2012-04-10]. Dostupné z: http://www.murphys-laws.com/murphy/murphy-computer.html 19. FEIGENBAUM, A. V. Total quality control. 3. McGraw-Hill, 1991, 863 s.. ISBN 0070203547. 20. FLOWERS, S. Software failure, management failure:amazing stories and cautionary tales. Wiley, 1996, 197 s.. ISBN 0471951137. 21. MYERS, G. J. The art of software testing. New York: Wiley, 1979, 177 s.. ISBN 0471043281. 22. IEEE. IEEE Std 610.12-1990 – IEEE Standard Glossary of Software. New York: The Institute of Electrical and Electronics Engineers, 1990. 23. CEM KANER, J. L. F. H. Q. N. Testing computer software. 2, přepracované vydání. New York: Wiley, 1999, 480 s.. ISBN 0471358460. 24. VIJAY. How to write a good bug report? Tips and Tricks. Software Testing Help [online]. 2007 [cit. 2012-04-18]. Dostupné z: http://www.softwaretestinghelp.com/how-to-write-good-bug-report/ 25. ODCHÁZEL, J. Management a moderní organizování firmy. Praha: Grada Publishing a.s. 2007, 328 s.. ISBN 978-80-247-2149-1. 26. MARTIN, R. C. Čistý kód. Překlad Jiří BERKA. Brno: Computer Press, 2009, 423 s.. ISBN 8025122859. 27. TEAM, C. P. CMMI for Development, Version 1.3 [online]. Carnegie Mellon University, 2010, 468 s. [cit. 2012-04-18]. Dostupné z: http://www.sei.cmu.edu/reports/10tr033.pdf 28. INSTITUTE, I. G. COBIT Mapping: Mapping of CMMI for Development V1.2 With COBIT. ISACA, 2007, 45 s.. ISBN 1933284803.
73
29. ALS, A. a C. GREENIDGE. The Waterfall Model [online]. 2003 [cit. 2012-03-08]. Dostupné z: http:/ /www.oocities.org/umsurapon/waterfall_model.htm 30. MATĚJÍČEK, V. Jaké jsou podmínky přístupného webu? Bezbariérový web a přístupnost [online]. 2006, verze 2007 [cit. 2012-04-18]. Dostupné z: http://pristupnost.inspirative.cz/podminky.html 31. MVČR. Vyhláška č. 64/2008 Sb. o formě uveřejňování informací souvisejících s výkonem veřejné správy …. Ministerstvo vnitra české republiky [online]. verze 2010 [cit. 2012-04-10]. Dostupné z: http://www.mvcr.cz/clanek/vyhlaska-c-64-2008-sb-o-forme-uverejnovani-informacisouvisejicich-s-vykonem-verejne-spravy-prostrednictvim-webovych-stranek-pro-osoby-sezdravotnim-postizenim-vyhlaska-o-pristupnosti-10.aspx 32. WILSON, B. MAMA: Markup validation report. Dev.Opera [online]. 2008 [cit. 2012-05-11]. Dostupné z: http://dev.opera.com/articles/view/mama-markup-validation-report/ 33. Q-SUCCESS. Usage of server-side programming languages for websites. W3Techs - Web Technology Surveys [online]. 2012, verze 5.5.2012 [cit. 2012-05-05]. Dostupné z: http:// w3techs.com/technologies/overview/programming_language/all 34. PHP FRAMEWORK INTEROPERABILITY GROUP. Proposing a Standards Recommendation. GitHub [online]. 2012 [cit. 2012-05-01]. Dostupné z: https://github.com/php-fig/fig-standards 35. PAGE, A. K. JOHNSTON a B. ROLLISON. Jak testuje software Microsoft. Praha: Computer Press, 2009, 384 s.. ISBN 8025128695. 36. BOROVCOVÁ, A. Kvalita a testování v České republice. Systémová integrace [online]. Praha: Česká společnost pro systémovou integraci, 2011, 18 (1), 93-108 [cit. 2012-04-04]. ISSN 18042716. Dostupné z: www.cssi.cz/cssi/system/files/all/si_2011_01_08_Borovcova.pdf 37. KLOBASA, P. Krátce o Code Review. OxyOnline [online]. 2009, verze 13.1.2009 [cit. 2012-04-19]. Dostupné z: http://vyvojari.oxyonline.cz/kratce-o-code-review 38. HAVIT, S.R.O. Zákon č. 101/2000 Sb. o ochraně osobních údajů. Bussines Center [online]. 2000 [cit. 2012-04-12]. Dostupné z: http://business.center.cz/business/pravo/zakony/oou/ cast1h2.aspx 39. SEJK, V. Jak zajistit bezpečnost webových aplikací. ComputerWorld [online]. 2009, verze 8.8.2009 [cit. 2012-04-15]. Dostupné z: http://computerworld.cz/bezpecnost/bezpecne-webove-aplikace4473 40. HUTCHESON, M. L. Software Testing Fundamentals: Methods and Metrics. New York: ohn Wiley & Sons, 2003, 432 s.. ISBN 0471468444. 41. NETTE F. Debugování a zpracování chyb. Nette Framework [online]. [cit. 2012-05-10]. Dostupné z: http://doc.nette.org/cs/debugging
74
42. ŠKRÁŠEK, J. PHP frameworky. Programujte.com [online]. 21. 2. 2008 [cit. 2012-05-11]. Dostupné z: http://programujte.com/clanek/2008022000-php-frameworky/
75
Seznam obrázků a tabulek Obrázek 1 – Příčiny softwarových chyb [17, s. 15] ................................................................................ 15 Obrázek 2 - Rozšířený model nákladů na kvalitu [1, s. 456] .................................................................. 19 Obrázek 3 - Organizační struktura firmy (zdroj: autor) ......................................................................... 27 Obrázek 4 - Ukázka hlášení o chybě ...................................................................................................... 38 Obrázek 5 - Vodopádový přístup dle Adriana Alse [29] ........................................................................ 42 Obrázek 6 - Laděnka, Debugger Bar [41]............................................................................................... 67 Obrázek 7 - Laděnka, ukázka výpisu chyby [41] .................................................................................... 67 Obrázek 8 - Selenium, plugin pro Firefox .............................................................................................. 68
Tabulka 1 - Stakeholdeři softwarového produktu (zdroj: autor) ............................................................ 6 Tabulka 2 - Odhalená problémová místa při definici požadavků [zdroj: autor] .................................... 29 Tabulka 3 - Odhalená problémová místa v komunikaci [zdroj: autor] .................................................. 31 Tabulka 4 – Úmyslné odchylky od požadavků [zdroj: autor]................................................................. 32 Tabulka 5 - Odhalená problémová místa v návrhu aplikace [zdroj: autor] ........................................... 33 Tabulka 6 - Výskyt klíčových slov TODO a FIXME ve zdrojovém kódu (zdroj: autor) ............................ 34 Tabulka 7 - Odhalená problémová místa ve zdrojovém kódu [zdroj: autor] ........................................ 35 Tabulka 8 - Odhalená problémová místa v konvencích pro psaní zdrojového kódu [zdroj: autor] ...... 36 Tabulka 9 - Odhalená problémová místa v procesu testování [zdroj: autor]........................................ 39 Tabulka 10 - Model vyspělosti procesů dle metodiky COBIT [27, s. 26], [28, s. 27].............................. 40 Tabulka 11 - Odhalená problémová místa v procedurách procesu vývoje [zdroj: autor] ..................... 43 Tabulka 12 - Odhalená problémová místa v dokumentaci softwaru [zdroj: autor] .............................. 45 Tabulka 13 - Odhalená problémová místa v zabezpečení systému [zdroj: autor] ................................ 48 Tabulka 14 - Odhalená problémová místa v oblasti přístupnosti webové aplikace [zdroj: autor] ....... 50
76
