|
Kvalita softwaru
Jakost softwaru se v současné době stává limitujícím faktorem kvality mnoha výrobků, které používají pro zajištění svých funkcí mikroprocesorové řízení. Růst požadavků na kvalitu softwaru jde ruku v ruce s růstem počtu úloh, v nichž mikroprocesor řídí systémy, jejichž havárie by ohrozily zdraví a bezpečnost obyvatel (jaderná energetika, zdravotní technika, řízení letadel apod.). Příspěvek upozorňuje na mezinárodní normy, které je potřeba respektovat při vývoji, má-li software vykazovat potřebnou kvalitu.
1. Úvod
Nástup mikroelektroniky v 70. letech dvacátého století významně ovlivnil i rozvoj automatizačních prostředků. V porovnání s tehdejšími automatizačními prostředky, které byly založeny především na využití mechanických, hydraulických, pneumatických nebo elektrických komponent a soustav, přinesla mikroelektronika především výraznou miniaturizaci a radikální pokles potřebných příkonů energie. Současně výrazně vzrostly funkční schopnosti automatizačních zařízení, zejména v oblasti logického řízení, protože klasickými prostředky nebylo možné realizovat tak rozsáhlé logické sítě, jak to naopak umožnily již první mikroelektronické obvody.
Následující růst hustoty spínacích prvků na ploše vedl k integrovaným obvodům kategorie VLSI, a tím k rozvoji mikroprocesorové techniky, která okamžitě našla uplatnění v automatizovaných řídicích systémech všeho druhu. Mikroprocesory umožnily vložit do automatizačních prostředků prvky umělé inteligence a zejména jim poskytly, prostřednictvím svého programového vybavení, potřebnou provozní pružnost, nezbytnou z hlediska potřeby reagovat na velké množství různorodých požadavků jak při projektování řídicích systémů, tak i při jejich údržbě a modernizaci. Příznivý dopad trvalého poklesu cen integrovaných obvodů zhruba od 90. let umožňuje jejich širší používání v dalších a dalších oblastech a výrobcích [3].
V současné době, na začátku nového století, jsou progresivní mikroprocesorové prvky běžnou součástí převážné většiny automatizačních prostředků, vyjma těch snad zcela nejjednodušších. Charakteristické je, že:
většina elektrických, hydraulických, pneumatických i hybridních automatizačních prostředků je navrhována v kombinaci s využitím mikroelektronických prvků,
klasické analogové prvky jsou nahrazovány číslicovými prvky (např. přechod od operačních zesilovačů zapojených jako analogové regulátory k mikroprocesorovým PSD regulátorům),
požadavek na propojování automatizačních prvků do počítačových sítí vyžaduje od téměř každého automatizačního prvku schopnost připojení k průmyslové komunikační síti, k čemuž je nejčastěji voleno zabudování integrovaného obvodu s komunikačním mikroprocesorem, který takovou funkci zajistí.
Výhodné vlastnosti, které automatizační prostředky získaly prostřednictvím využívání mikroprocesorové techniky, jsou však v současné době často znehodnocovány chybami do nich vloženého softwaru. Dochází k paradoxnímu jevu, kdy velmi kvalitně navržené a vyrobené technické prostředky ztrácejí hodnotu vlivem chyb v programovém vybavení a automatizační prostředky se stávají neprovozuschopnými, protože v důsledku chyb v softwaru spolehlivě nevykonávají požadované funkce. Tato skutečnost zasluhuje zvláštní pozornost z hlediska dalšího rozvoje automatizačních (a nejen automatizačních!) prostředků.
2. Jakost softwaru pro řízení
Chyby v softwaru jsou následkem nesprávně realizovaného procesu jeho tvorby. Je totiž nutné si uvědomit, že zatímco spolehlivost vyrobeného integrovaného čipu mikroprocesoru je v současné době v důsledku kvalitní automatické výroby extrémně velká a dosahuje milionů garantovaných provozních hodin bez poruchy, jsou jakost a spolehlivost programu mikroprocesoru velmi nízké. Pravděpodobnost, že v řídicím programu mikroprocesoru je chyba, bývá často větší než 90 %.
Uvedená skutečnost je o to významnější, že mikroprocesory se nyní používají v mnoha úlohách např. v jaderné energetice, při řízení letadel a letového provozu, v automobilech [3], lékařských přístrojích apod., kde chyby v softwaru mohou mít katastrofální následky. Dopad této skutečnosti v praxi ukazuje např. situace okolo rychlovlaku Pendolino, kdy mnohamilionový výrobek byl odstaven v důsledku nesprávně zkonfigurovaného řídicího softwaru měničů [2]; to Českým drahám způsobilo milionové ztráty. Naštěstí zatím nedošlo k ohrožení či dokonce ztrátě lidských životů.
Potřeba garantovat jakost softwaru je tedy nyní velmi aktuální, až kategorická. S tímto požadavkem však ostře kontrastuje skutečnost, že lidé, kteří v roli zákazníků nejsou ochotni tolerovat drobné chybičky a nedostatky např. v souvislosti s takovými výrobky, jako jsou předměty osobní spotřeby jako auta, nábytek apod., ale i výrobní stroje a zařízení, jsou naopak zatím ochotni tolerovat poměrně značné chyby v nejméně stejně draze kupovaném softwaru!
Výsledkem je, že mnoho softwarových firem nevěnuje kvalitě jimi vyvíjeného softwaru potřebnou pozornost, dokonce ignorují potřebu jeho kvalitního testování a přenášejí ho na dobu provozu u zákazníků, přičemž zjištěné chyby v používaném softwaru následně nesystematicky a liknavě napravují. Lehkomyslně přitom přehlížejí a nerespektují množství norem, metod a nástrojů, které kvalitu softwaru řeší (ISO 9126, V-model, SW CMM, model SPICE podle ISO 15 504, produkty typu CASE apod.) Taková situace se už nyní nevyskytuje u žádného běžného výrobku na spotřebním nebo průmyslovém trhu.
Jestliže se bude chtít lidská společnost, která o sobě v současnosti sama prohlašuje, že směřuje k tomu stát se informační společností (information society), dále bez problémů rozvíjet, bude muset problém jakosti softwaru urychleně a intenzivně začít řešit. Jakost softwaru proto musí být v centru pozornosti vedoucích pracovníků na všech úrovních jak softwarových firem jako tvůrců a dodavatelů softwaru, tak ostatních firem, které programové vybavení používají. Chyby v softwaru mohou při současném hromadném využívání počítačů vést ke značným ztrátám ve finančním hospodaření firem a v určitých případech zcela ochromit řízení i samotnou existenci firem. Průzkumy a zkušenosti ukazují, že dnes středně velká firma již nemůže být plnohodnotně provozována, trvá-li výpadek jejího informačního systému déle než asi čtyři hodiny.
Software má mnoho vlastností, které komplikují měření, a tím i dosahování potřebné úrovně jeho jakosti, a vyvolávají potřebu intenzivního řešení problémů spojených s kvalitou programů. Přesto současné hnutí směrem k dokumentování systémů řízení jakosti podle norem řady ISO 9000 se těchto problémů dotklo jen okrajově a v praxi nijak nepřispělo ke skutečnému zlepšení jakosti softwaru. Za specifické vlastnosti programového vybavení z hlediska jakosti jsou považovány:
- nehmotná, abstraktní povaha programů,
- velká složitost programů,
- potřeba vysoké úrovně speciálních znalostí, bez nichž nelze jen trochu složitější program vytvořit,
- složitost procesu tvorby programů,
- nemožnost jednoduše stanovit a měřit charakteristiky určující jakost programů,
- absence v praxi použitelného postupu prokazujícího, že je program bez chyb (testováním zatím lze jen prokázat, že program určité chyby má).
Uvedené vlastnosti platí pro software obecně. Z hlediska využití mikroprocesorových prostředků v automatizační technice je vhodné zdůraznit ještě dvě další vlastnosti, a to:
velký počet paralelně probíhajících výpočtů, které je třeba složitě synchronizovat prostřednictvím tzv. kritických sekcí,
potřeba deterministického chování nezbytného při řízení technologických procesů v reálném čase (real time control) s často i extrémními požadavky na rychlost odezvy (např. při řízení velmi rychlých mechanických pohybů).
Při tvorbě softwaru, tak jako v jiných oblastech, je vyžadována certifikace systému řízení jakosti podle souboru norem ISO 9000:2000. Zásady a náležitosti tohoto souboru norem a certifikace systémů jakosti jsou obecně známy, a proto je není třeba zde rozvádět. Důležitou skutečností ohledně certifikátu pro softwarovou firmu musí být konkretizace obecných zásad řízení jakosti v oblasti softwaru. K tomu došlo vydáním normy ISO 9126 a norem na ni navazujících. Šlo o nutný krok proto, že software má své specifické vlastnosti (nehmotnost, extrémní složitost, obtížná měřitelnost, náročná tvorba – viz shora), pro které nelze použít běžné zásady známé a osvědčené pro hmotné výrobky strojírenského, elektrotechnického a stavebního průmyslu a dalších výrob.
Norma ISO 9126-1 Software Quality Model stanovuje těchto šest charakteristik jakosti softwarového produktu:
funkceschopnost: schopnost obsahovat funkce, které zajišťují předpokládané nebo stanovené požadavky uživatele za stanovených podmínek používání,
bezporuchovost: schopnost zachovat specifikovanou úroveň výkonu při používání produktu za stanovených podmínek,
použitelnost: srozumitelnost produktu a jeho snadná obsluha určenými uživateli za stanovených podmínek,
účinnost: schopnost poskytovat potřebný výkon vzhledem k množství použitých zdrojů za stanovených podmínek,
udržovatelnost: schopnost produktu být modifikován s cílem nápravy nedostatků, vylepšování, adaptace a změn,
přenositelnost: schopnost být přenesen do jiného prostředí s minimalizovanou námahou a obtížemi.
Následující další části normy označené ISO 9126-2, 9126-3, 9126-4 stanovují metriky pro měření uvedených charakteristik prostřednictvím navržených dílčích charakteristik. Tento komplexní přístup k pojetí jakosti softwaru musí být akceptován i v oblasti programového vybavení pro řízení, kde se často dosud přihlíží pouze k prvním dvěma uvedeným hlediskům (charakteristikám)!
3. Návrhy a doporučení
3.1 Potřeba celostního přístupu
Situace panující v současnosti kolem kvality softwaru vyžaduje reakci nejen od softwarových firem, které vytvářejí řídicí programy, ale i od ostatních dodavatelů automatizačních prostředků a také od vysokých škol.
Pro zjednodušení jsou návrhy a doporučení v dalším textu formulovány v členění podle životního cyklu návrhu a zavádění automatizovaných řídicích systémů.
3.2 Fáze návrhu a vývoje softwaru
V současné době je při vývoji automatizačních prostředků a procesu automatizace nutné vždy explicitně plánovat činnosti týkající se vývoje řídicích programů a tyto činnosti považovat za kritické z hlediska řízení příslušného projektu. Zejména je třeba důkladně plánovat testování. Vypracovávané programy je nutné testovat v průběhu celého jejich vývoje. V žádném případě nelze ponechávat testování jen až na dobu finálního předání programů u zákazníka. Z toho vyplývá, že při návrhu a řízení softwarových projektů je nutné využívat moderní metody projektového řízení (např. PRINCE 2). Na možnosti projektového řízení a nutnost využívat jeho metody upozorňují odborníci již delší dobu [1]. Z hlediska definice jakosti podle souboru norem ISO 9000 („jakost je schopnost produktu uspokojit vznesené i předpokládané požadavky uživatele„) je třeba se zaměřit na zpracování kvalitní specifikace požadovaného softwaru a na monitorování změn požadavků uživatele na software, který je vyvíjen.
Při tvorbě řídicích programů je třeba využívat současné propracované metody tvorby programů (UML, RUP, BORAM [4]), důsledně využívat nástroje typu CASE [5] a produkty pro testování programů.
V celém procesu návrhu a vývoje řídicích programů je nutné využívat mezinárodní normy, které se týkají této oblasti, jinak se náš stát stane provinčním regionem, který nerespektuje (a často ani nezná) obecně uznávané mezinárodní standardy. Vedle již zmíněných norem patří k nejdůležitějším tyto normy (v abecedním pořadí):
- ANSI/IEEE 829-1983 Standard for Software Test Documentation,
- IEEE 730 Standard for software quality plans,
- IEEE 1008 Standard for unit testing,
- IEEE 1012 Standard for software verification and validation,
- IEEE 1028 Standard for software inspections,
- IEEE 1044 Standard for the clasification of software anomalies,
- IEEE 1044-1 Guide to the clasification of software anomalies,
- IEEE 1233 Guide for developing system requirements specifications,
- ISO 10 006 Guidelines for Project Management,
- ISO 10 007 Guidelines for Configuration Management,
- ISO 14 598 Software Product Evaluation,
- ISO 15 504 Software Process Improvement and Capability Determination (SPICE),
- ISO 15 939 Software Measurement Process.
Obr. 1. V-model standardního procesu vývoje počítačových programů
Stále důležitější bude přesně identifikovat potřeby, problémy a požadavky zákazníka. Vyplývá to z již uvedeného vymezení jakosti v souboru norem ISO 9000 jako „… schopnosti produktu uspokojit požadované a předpokládané požadavky zákazníka„. Právě specifikace požadavků zákazníků na řídicí software jsou velmi často nejednoznačné, neúplné, rozporné a nepřesné. Přitom je velmi důležité, aby všechny požadavky byly zároveň doprovázeny plánem, jak je možné ověřit jejich splnění (viz úrovně testů V-modelu – obr. 1). Tato oblast je v ČR, na rozdíl např. od praxe v USA, dosud velmi často přehlížena.
3.3 Fáze zavádění softwaru
Od začátku vývoje jakéhokoliv softwaru je třeba plánovat a připravovat akceptační testy, jejichž prostřednictvím se na konci vývoje ověří, že výsledný produkt splňuje požadavky uživatele. Cílem akceptačního testu je ověřit, zda je výsledný software v takovém stavu, aby mohl být použit koncovými uživateli pro rutinní práci v souladu s požadovanými provozními podmínkami a parametry.
Pro realizaci akceptačního testu je třeba vyškolit a instruovat testovací tým u zákazníka, připravit testovací prostředí, scénáře testů a zkušební údaje.
Akceptační testy jsou formálně zakončeny podpisem akceptačního protokolu, který potvrzuje, že funkční schopnosti dodaného softwaru odpovídají jeho výchozí specifikaci (zadání), a popř. obsahuje seznam otevřených problémů, které se během testů objevily.
Při akceptačních testech je také třeba prověřit, zda skutečné provozní podmínky a režimy řídicího softwaru odpovídají těm, které byly specifikovány a navrženy.
3.4 Fáze používání softwaru
V průběhu používání softwaru je třeba kontrolovat dodržování předepsaných provozních podmínek a režimů a zajistit sledování charakteristik jakosti příslušného programu. Dále je zapotřebí zajišťovat běžnou údržbu a případně opravovat a měnit software, a to vždy jednoznačně definovaným a dokumentovaným způsobem, odpovídajícím postupu při celkovém návrhu softwaru.
3.5 Oblast výuky
Při výuce odborníků v oboru automatického řízení je třeba studenty seznámit s problematikou kvality softwaru. Seznámení by mělo obsahovat:
vymezení pojmů a problematiky kvality softwaru ve vztahu k problematice řídicích programů pro automatizaci průmyslových procesů,
přehled relevantních mezinárodních norem, které je třeba respektovat při tvorbě programů pro řízení,
seznámení s principy a prostředky, které umožňují zajistit kvalitu řídicích programů, včetně seznámení s progresivními metodami tvorby softwaru (např. [8], [9]),
prezentaci správných postojů k zajišťování potřebné kvality řídicích programů, pro které by měli být studenti získáni,
formou seminární práce by si studenti měli při vlastním návrhu a tvorbě zadaného programového produktu ověřit, že v praxi dovedou kvalitu softwaru zajistit.
Důležité je, aby si studenti nejen osvojili nezbytné znalosti, ale aby byli získáni i pro kladný postoj k zajišťování kvality softwaru.
4. Závěr
Pracovníci firem zajišťujících vývoj, výrobu a dodávku automatizačních prostředků i uživatelé si musí uvědomit, že problematika jakosti softwaru musí být středem pozornosti všech zúčastněných.
Kvalitní software nelze vytvořit bez uplatnění systémového přístupu [7] a bez použití metod procesního řízení [6] všech podnikových a technologických procesů. Dosáhnout potřebné kvality softwaru přitom není snadné. Je k tomu třeba řešit otázky nejen z oblasti softwarového inženýrství, ale i z oblastí podnikové ekonomiky, procesního řízení firmy, personální práce apod.
Evropská unie má program zvyšování jakosti obecně, a tudíž i softwaru, za jednu z priorit pro udržení vysoké konkurenční schopnosti svých členských zemní i EU jako celku. Proto v jednotlivých členských zemích iniciovala Národní programy jakosti (viz http://www.npj.cz).
Nezbytnou podmínkou toho, aby se domácí firmy uplatnily i na globalizovaném trhu, je respektovat platné mezinárodní normy.
Do budoucna je zapotřebí počítat se skutečností, že tlak na kvalitu bude vyvíjen i v oblasti softwaru, a to jak z pozic centrálních unijních i státních orgánů, tak i zákazníky. Proto by se automatizační firmy, pokud tak ještě neučinily, měly na problematiku jakosti softwaru zaměřit ihned a s plným nasazením.
Poděkování
Touto cestou vznikl za podpory výzkumného záměru MSM 00216305 18 Simulační modelování mechatronických soustav.
Literatura:
[1] MARSINA, Š.: Projektový management – výzva pre najbližšiu budúcnosť. In: Zpravodaj Společnosti pro projektové řízení, 1999.
[2] BLAŽEK, A.: Na co stonalo Pendolino. Automatizace, 2006, roč. 49, č. 4, s. 269.
[3] PŘEUČIL, P.: Diagnostika na přání – Počet elektronických součástek v automobilech stoupá. IT Systems, 2006, roč. 8, č. 5, s. 44.
[4] POLÁK, J. – MERUNKA, V. – CARDA, A.: Umění systémového návrhu. Grada Publishing, Praha, 2003.
[5] MERUNKA, V.: První zkušenosti s modelovacím nástrojem Draft Case. In: Sborník ze semináře Tvorba softwaru 2005. VŠB-TU Ostrava, Ostrava, 2005.
[6] SVOBODA, V. – PASTOR, O.: Základy řízení technologických procesů dopravy. Vydavatelství ČVUT, Praha, 2005.
[7] LACKO, B.: Systémový přístup k jakosti softwaru. In: Sborník z konference Tvorba softwaru 2004. VŠB-TU Ostrava, Ostrava, 2004.
[8] BUCHALCEVOVÁ, A.: Metodika Feature-Driven Development. In: Sborník konference Tvorba softwaru 2005. VŠB-TU Ostrava, Ostrava, 2005.
[9] BUCHALCEVOVÁ, A.: Metodický rámec IS/ICT. In: Sborník konference Tvorba softwaru 2004. VŠB-TU Ostrava, Ostrava, 2004.
Branislav Lacko,
ústav automatizace a informatiky,
Fakulta strojního inženýrství,
VUT v Brně
(lacko@fme.vutbr.cz)
Doc. Ing. Branislav Lacko, CSc., pracoval od roku 1967 ve výpočetním středisku TOS Kuřim jako systémový analytik a programátor. Na VUT v Brně působí od roku 1991, nyní v ústavu automatizace a informatiky Fakulty strojního inženýrství, kde vede výuku v předmětu navrhování řídicích systémů. Je členem České společnosti pro jakost a publikoval mnoho článků z oblasti kvality softwaru. Jako člen International Project Management Association se věnuje použití exaktních metod v oboru projektového řízení.
|