Aktuální vydání

celé číslo

03

2021

Digitální transformace, chytrá výroba, digitální dvojčata

Komunikační sítě, IIoT, kybernetická bezpečnost

celé číslo

Výkonnost softwaru pro automatické řízení

Branislav Lacko
 
V současné době rostou požadavky na výkonnost programů určených pro řízení v reálném čase. Článek popisuje, jak je charakteristika výkonnosti programu definována v normě ISO 9126, která se využívá jako podklad ke kvalitní specifikaci požadavků na výkon programů. Příspěvek upozorňuje s odvoláním na V-model pro testování programů, že výkonnost programu je třeba testovat v průběhu celého procesu jeho vývoje.
 

1. Požadavky na výkonnost řídicích programů

Velká operační rychlost současných mikroprocesorů svádí k domněnce, že sama o sobě postačí k dosahování výkonnosti programů, které jsou určeny pro řízení složitých soustav v reálném čase. Zapomíná se však často na jiné skutečnosti:
  • řízení současných rychlých dějů klade velké požadavky na krátké doby odezvy,
  • použití umělé inteligence, ale i jiné nové trendy, s sebou přinášejí velmi složité algoritmy s dlouhou dobou výpočtu,
  • řízení je často spojeno se zpracováním velkých objemů dat, ať již z analogových senzorů sledujících řízený proces, nebo z multimediálních zdrojů (zvuk, obraz – často barevný s velkým rozlišením, např. v bezpečnostních kamerových systémech nebo pro řízení robotů),
  • roste počet řízených funkcí, a s tím i rozsah a složitost programů.
Velká operační rychlost procesorů nestačí a je třeba věnovat velkou pozornost vypracování kvalitního návrhu a realizaci softwaru s ohledem na jeho celkovou výkonnost.
 

2. Výkonnost softwarového produktu a norma ISO 9126

Výkonnost softwarového produktu je nedílnou součástí jeho charakteristik jakosti obecně, ne pouze programů pro řízení v reálném čase. Tato myšlenka je zakotvena v normě ISO 9126-1 Software engineering – Product quality – Part 1: Quality model [4] (pozn. red.: v české verzi ČSN ISO/IEC 9126-1 Softwarové inženýrství – Jakost produktu – Část 1: Model jakosti; ČNI, 2001), která definuje charakteristiky jakosti softwaru (obr. 1). S uvedenými charakteristikami počítá i model SQuaRE (Software Produkt Quality Requirement and Evaluation), který tuto normu postupně nahrazuje [8]1). Charakteristiky neobsahují přímo pojmy výkon nebo výkonnost. Výkonnost softwarového produktu je zahrnuta do charakteristiky účinnost (efficiency), která je definována v normě jako: „schopnost softwarového produktu poskytovat potřebný výkon vzhledem k množství použitelných zdrojů, při používání za stanovených podmínek“.
 
Z definice v normě vyplývá, že jde o potřebný výkon, tedy takový, který může uživatel skutečně využít pro svou výpočetní nebo informační potřebu. Výkon, který nepřináší uživateli programu užitečný efekt, je výkon, který nezvyšuje jakost programu. Výkon je zde vztažen k používaným podmínkám v provozu s ohledem na potřebné zdroje, tj. základní operační programové vybavení, potřebu operační i externí paměti, strukturu a organizaci dat apod. Provozní podmínky mohou být chápany jako limitní nebo jako běžné, což je třeba uvést jednak při specifikaci požadavků na vyvíjený software, jednak v pokynech pro používání příslušného softwarového produktu.
 

3. Charakteristika a podcharakteristiky výkonnosti softwarového produktu

Pro měření výkonnosti, a tím i pro hodnocení jakosti z hlediska této charakteristiky doporučuje norma ISO 9126 podcharakteristiky podle obr. 2. Dále je uvedeno vymezení jednotlivých podcharakteristik:
 
Doba odezvy (response time). Česká názvoslovná norma ČSN 36 9001 Počítače a systémy zpracování údajů – Názvosloví [7] definovala tento pojem pod heslem 023 jako časový interval od ukončení požadavku nebo dotazu do začátku odezvy2). Obdobně definují tento pojem i americké národní standardy [5], [6].
 
Propustnost (throughput) je vyjádřena jako množství práce, kterou je počítačový systém schopen vykonat za časovou jednotku (viz [7], heslo 026). Doba obrátky (turnaround time) je chápána jako časový interval, který uplyne od předložení požadavku na zpracování do příjmu všech výsledků (viz [7], heslo 024). Pro tuto veličinu se také někdy používá termín doba průchodu.
 
Nedílnou součástí měření výkonnosti je uvedení počtu, popř. objemu potřebných zdrojů, tj.:
  • kapacity operační paměti potřebné pro práci programu,
  • kapacity externích pamětí potřebných pro práci programu,
  • počtu externích zařízení I/O (např. displeje, grafické karty, komponenty operačního systému apod.).

4. Definice hodnot kritérií charakteristiky účinnosti a jejich měření

V běžné praxi se nejčastěji stanovují očekávané, resp. požadované hodnoty doby odezvy, propustnosti a doby obrátky, a následně se testy zjišťuje, do jaké míry je vytvořený program splňuje.
 
Nejprve je nutné přesně definovat způsob a postup měření příslušné podcharakteristiky, což v některých komplikovanějších případech není jednoduché.
 
Následně se stanovují hodnoty pro jednotlivé metriky příslušných podcharakteristik, kterých je třeba dosáhnout.
 
Nakonec je třeba definovat podmínky, za kterých bude měření probíhat. Není správné stanovovat jednu hodnotu pro testování příslušné podcharakteristiky, např. dobu odezvy jedna sekunda. Požadovaná hodnota by měla být stanovena zadáním požadovaného intervalu. Obvykle se rozlišuje průměrná požadovaná hodnota (v [1] viz odst. 5.7) a limitní hodnota, která nesmí být překročena. Který z obou případů je pro daný produkt vhodnější, je nutné stanovit s ohledem na konkrétní situaci [1]. Půjde-li o zpracování hromadných dat, kdy je důležité sledovat výkon aplikace, je dostačující např. průměrná doba odezvy. Půjde-li o řídicí program, kde při nedodržení doby odezvy může dojít k poškození řízeného systému, bude vhodnější stanovit limitní hodnotu požadované doby odezvy, která v žádném případě nesmí být překročena.
 

5. Zásady pro tvorbu softwaru s ohledem na požadované parametry výkonnosti

Na specifikaci výkonnosti je třeba pamatovat při zadávání charakteristik vyvíjeného softwaru. To se často nedělá a o parametrech výkonnosti se začne diskutovat až při přijímacích testech, nebo někdy až po počátečním období rutinního provozu.
 
Pro ověření výkonnosti softwaru je třeba se dohodnout na měřených parametrech a způsobu jejich měření tak, aby zákazník i dodavatel souhlasili s obojím a ujednotili si svoje představy. Dohoda by měla být písemná a dokument součástí podmínek kontraktu.Výkonnost je třeba testovat průběžně v celém životním cyklu vývoje softwaru, nejen na konci při předávání softwaru k užívání, jak to vyplývá i z koncepce V-modelu (viz dále).
 
Který „výkon“ se získá ze strany hardwaru a který ze strany softwaru, je strategické rozhodnutí, jež musí být učiněno na začátku vývoje aplikace. Je nesprávné spoléhat na to, že v případě, kdy se výkonu nedosáhne programovým řešením, se doporučí zákazníkovi, aby si zakoupil výkonnější technické vybavení.
 
Jedním z modelů testování při tvorbě softwaru je známý V-model [9], [10], [11]. Pro každou úroveň V-modelu je třeba stanovit testy i pro ověření výkonnosti, protože každá z úrovní modelu vyžaduje jiný typ testů a mnohdy i jiný postup měření a z toho vyplývající měřené parametry.
 
Na požadavky výkonu programu je třeba pamatovat již při sestavování jeho algoritmu. Toto tvrzení zároveň ukazuje na potřebu vyhodnotit navrhované algoritmy z hlediska časové a paměťové náročnosti.
 
Pro každý program je zapotřebí nalézt sekci, která rozhodujícím způsobem ovlivňuje jeho výkonnost. To je zejména velmi nutné u programů pracujících v reálném čase a při velkém objemu výpočtů ve vědeckotechnických úlohách nebo úlohách hromadného zpracování dat. Poznamenejme, že požadavky výkonnosti by měly být odvozeny ze skutečné potřeby.
 
Často je požadován výkon, který vyplývá z chybných představ nebo předpokladů. Je nutné si uvědomit, že extrémní požadavky na zvyšování výkonnosti často vedou k prudkému růstu nákladů na vývoj softwaru a prodlužují dobu jeho vývoje. Proto je třeba prověřit přínosy požadované výkonnosti a porovnat je s náklady na vývoj a provoz příslušné aplikace.
 

6. Závěr

Cílem příspěvku bylo ukázat, že problematika výkonnosti programů je obsažena v normě jako významný faktor jejich kvality. Proto musí být zajišťována v celém procesu návrhu a realizace programu. Požadavky na výkonnost vyplývají ze stále rostoucích potřeb zpracovávat velké objemy dat (např. při zpracování obrazu a zvuku), v některých případech i pro mnoho uživatelů současně.
 
Skutečnou výkonnost programu je třeba v průběhu využívání monitorovat, protože při déletrvajícím provozu se mohou měnit některé podmínky, které výkonnost ovlivňují.
 
Odhalený trend zhoršování parametrů dovoluje včas naplánovat a realizovat potřebná opatření. Provést úpravy programu je možné, je-li splněn požadavek snadné modifikovatelnosti programu.
 
Problematika výkonnosti je kritická hlavně u programů pro řízení složitých systémů v reálném čase. Algoritmy, které se v těchto případech používají, mohou při nevhodném návrhu, který nerespektuje např. požadavky na extrémně krátkou dobu odezvy, vést k nesprávnému řízení takových soustav.
 
Literatura:
[1] VANÍČEK, J.: Měření a hodnocení jakosti informačních systémů. ČZU v Praze, Provozně ekonomická fakulta, Praha, 2000.
[2] PETŘVALDSKÝ, D.: Performance Engineering není jen testování. Komix Newsletter. Komix, s. r. o., Praha, 2006, s. 6.
[3] PAVLÍČEK, J.: Odhad složitosti softwarového produktu v etapě specifikace požadavků. In: Sborník Tvorba softwaru 2007. VŠB-TU Ostrava, 2007, s. 113–122.
[4] ISO 9126 Software engineering – Product quality – Part 1: Quality model. International Organization for Standardization, 2001.
[5] Federal Standard 1037C Glossary of Telecommunication Terms. General Services Administration, 1996.
[6] Mil-STD-188 Conformance Test Procedures. Defense Information Systems Agency, 2001.
[7] ČSN 36 9001 Počítače a systémy zpracování údajů – Názvosloví. Část 10 – Způsoby činnosti a prostředky počítače rozšířeného o operační systém. Vydavatelství ÚNM, Praha, 1986.
[8] VANÍČEK, J.: Stav a perspektivy mezinárodní normalizace v oblasti měření a hodnocení jakosti informačních a softwarových produktů. ČZU, Praha, 2004, ISBN 89-213-1129-0.
[9] V-Model (software development). In: Wikipedia. Dostupné na <http://en.wikipedia.org/wiki/V-Model_(software_development)>. Poslední modifikace 21. 4. 2008, cit. 28. 4. 2008.
[10] BEIZER, B.: Software Testing Techniques. Second Edition. International Thomson Computer Press, 1990.
[11] PRESSMAN, R. S.:Software Engineering: A Practitioner‘s Approach. The McGraw-Hill, 1992, ISBN 0-07-707936-1.
 
Tento příspěvek vznikl za podpory výzkumného záměru MSM 0021630529 Inteligentní systémy v automatizaci.
 
doc. Ing. Branislav Lacko, CSc.,
ústav automatizace a informatiky
FSI VUT v Brně
)
 
Lektoroval: Ing. Jan Bezdíček, Ph.D.,
Rockwell Automation, s. r. o.
 
Doc. Ing. Branislav Lacko, CSc., v letech 1967 až 1991 působil ve výpočetním středisku TOS Kuřim. Od roku 1992 pracuje v ústavu automatizace a informatiky Fakulty strojního inženýrství VUT v Brně. Zabývá se problémy navrhování řídicích a informačních systémů, řízení projektů a kvality softwaru. V současné době se podílí na řešení problematiky řízení složitých komplexních soustav v rámci výzkumného záměru Inteligentní systémy v automatizaci. Je dlouholetým členem Českomoravské společnosti pro automatizaci.
 
Obr. 1. Charakteristiky jakosti softwaru
Obr. 2. Podcharakteristiky výkonnosti softwarového produktu
Obr. 3. V-model
 

 
1) viz ISO/IEC 25000 Software Engineering – Software product Quality Requirements and Evaluation (SQuaRE) – Guide to SQuaRE; ISO, 2005 (pozn. red.)
2) ČSN 36 9001 byla v roce 1998 zrušena a nahrazena ČSN ISO/IEC 2382-1 Informační technologie – Slovník – Část 1: Základní termíny (pozn. red.)