INFORMAČNÍ POTŘEBY A POŽADAVKY NA SYSTÉM INFORMATION NEEDS AND SYSTEM REQUIREMENTS. Jiří Vaníček

Podobné dokumenty
Jak postupovat při hodnocení jakosti softwarových produktů

Aplikace metodiky hodnocení kvality systému elektronické výměny dat mezi podnikem a státní správou

SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE

ČESKÁ TECHNICKÁ NORMA

Vysoká škola báňská TU Ostrava Fakulta elektrotechniky a informatiky Katedra obecné elektrotechniky NORMALIZACE V ČR

8/2.1 POŽADAVKY NA PROCESY MĚŘENÍ A MĚŘICÍ VYBAVENÍ

Procesní přístup k projektům informačních systémů. RNDr. Vladimír Krajčík, Ph.D.

Připravovaná řada norem ISO/IEC pro jakost produktu

K otázkám strategie zpřístupňování elektronických informačních zdrojů pro oblast výzkumu a vývoje

KVALITA SOFTWARE VE SVĚTLE MEZINÁRODNÍCH NOREM

HODNOCENÍ VÝKONNOSTI PODNIKU VE SPOJITOSTI SE STRATEGICKÝMI CÍLY

DOKUMENT IAF. Závazný dokument IAF. Akreditace orgánů posuzování shody působících ve více zemích

Návod k požadavkům ISO 9001:2015 na dokumentované informace

ČESKÁ TECHNICKÁ NORMA

ČESKÁ TECHNICKÁ NORMA

Institucionální rozvojový plán Ostravské univerzity pro rok 2013

Semestrální práce z předmětu 4IT421 Téma: CMMI-DEV v.1.3 PA Project Monitoring and Control

ČSN Část 3: Návod k použití. IEC Oddíl 9: Analýza rizika technologických systémů

ČESKÁ TECHNICKÁ NORMA

ČESKÁ ZEMĚDĚLSKÁ UNIVERZITA

Kvalita SW produktů. Jiří Sochor, Jaroslav Ráček 1

VÝBĚR A HODNOCENÍ PROJEKTOVÝCH A NADPROJEKTOVÝCH UDÁLOSTÍ A RIZIK PRO JADERNÉ ELEKTRÁRNY

SMĚRNICE DĚKANA Č. 4/2013

1.1 Význam a cíl měření

ISO 9000, 20000, Informační management VIKMA07 Mgr. Jan Matula, PhD. III. blok

Procesy, procesní řízení organizace. Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje

Bezpečnost informačních systémů a jejich kvalita

DOKUMENT IAF IAF MD 12: 2013

Efektivní právní služby

Stanovisko odboru veřejné správy, dozoru a kontroly Ministerstva vnitra č. 2/2018

Informační média a služby

ZADÁVACÍ DOKUMENTACE

ČESKÝ INSTITUT PRO AKREDITACI, o.p.s. Dokumenty ILAC. ILAC Mezinárodní spolupráce v akreditaci laboratoří

ČESKÁ TECHNICKÁ NORMA

Obecné pokyny k parametrům specifickým pro pojišťovny nebo zajišťovny

ČESKÁ TECHNICKÁ NORMA

Management rizika Bc. Ing. Karina Mužáková, Ph.D. BIVŠ,

DOKUMENT IAF IAF MD 11:2013. Závazný dokument IAF pro aplikaci ISO/IEC pro audity integrovaných systémů managementu

Projektová dokumentace pro tvorbu internetových aplikací

Nedošlo ke změnám oproti údajům uvedeným v předběžném oznámení.

Spotřebitelský řetězec lesních produktů požadavky

ČESKÁ TECHNICKÁ NORMA

Ing. Jiří Fejfar, Ph.D. Geo-informační systémy

ČESKÁ TECHNICKÁ NORMA

Efektivnost informačních systémů. strategické řízení taktické řízení. operativní řízení a provozu

ISO 9001 : Certifikační praxe po velké revizi

Přehled technických norem z oblasti spolehlivosti

ČESKÁ TECHNICKÁ NORMA

POŽADAVKY NORMY ISO 9001

Softwarová podpora v procesním řízení

Zvyšování výkonnosti firmy na bázi potenciálu zlepšení

Představení metodiky přípravy veřejných strategií

ČESKÁ TECHNICKÁ NORMA

Výzva k podání nabídek na veřejnou zakázku Software (II.) zadávanou v dynamickém nákupním systému Dynamický nákupní systém na software (II.

Směrnice č. 1/2017 ZÁSADY A POSTUPY PŘI ZADÁVÁNI VEŘEJNÝCH ZAKÁZEK MALÉHO ROZSAHU

POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ

Osnovy prezenčního studia předmětu RiJ - ŘÍZENÍ JAKOSTI

Obsah. Zpracoval:

A7B36SI2 Tematický okruh SI11 Revidoval: Martin Kvetko

ČESKÁ TECHNICKÁ NORMA

Normy a systémový přístup k zavádění, provozování a evaluaci ICT systémů pro výuku, vzdělávání a školení. Josef Myslín katedra informatiky VŠMIEP

studijních oborů na MU

ABC s.r.o. Výtisk číslo: PŘÍRUČKA ENVIRONMENTU. Zpracoval: Ověřil: Schválil: Č.revize: Počet příloh: Účinnost od:

HODNOCENÍ KVALITY A EFEKTIVITY E-LEARNINGOVÉHO VZDĚLÁVÁNÍ THE QUALITY AND EFFICIENCY EVALUATION OF E-LEARNING EDUCATION. Tomáš Maier, Ludmila Gallová

Provádění opatření k nápravě

ISO/IEC/IEEE zavedena v ČSN ISO/IEC/IEEE ( ) Softwarové a systémové inženýrství Testování softwaru Část 1: Koncepty a definice

II. METODICKÁ ČÁST 1

GIS Libereckého kraje

Informační systémy ve výuce na PEF Information Systems in teaching at the FEM

PRÁVNÍ STATUS POUŽITÝCH A RENOVOVANÝCH STROJNÍCH ZAŘ ÍZENÍ

Věc: Strategie EZÚ pro přechodné období zavádění změn normy ISO 9001:2008

MASARYKOVA UNIVERZITA PRÁVNICKÁ FAKULTA. SMĚRNICE DĚKANA č. 3/2015 O EDIČNÍ ČINNOSTI

Projektové řízení. Lenka Švecová, Tomáš Říčka. University of Economics, Prague. Project management for SMEs/NGOs - exchange of experience for trainers

ORGANIZAČNÍ SMĚRNICE č. 2/2015. Pravidla pro zadávání veřejných zakázek malého rozsahu Českým svazem včelařů z.s.

Zadavatel nevymezuje míru ovlivnění plnění plánovaného cíle. Zadavatel neuvádí další informace odůvodňující účelnost veřejné zakázky.

Základní principy SJ a jejich zavádění do praxe; normy ISO 9000 a ISO ISO normy

Výukový materiál zpracovaný v rámci projektu Výuka moderně

Výtisk č. : Platnost od: Schválil: Podpis:

Představení projektu Metodika

Bakalářský seminář - 3

Systém managementu jakosti ISO 9001

ROZVOJ ICT A PDA ZAŘÍZENÍ THE DEVELOPMENT OF ICT AND PDA DEVICES Jiří Vaněk

ČESKÁ TECHNICKÁ NORMA

Management rizik v životním cyklu produktu

MODELOVÁNÍ DAT V INFORMAČNÍCH SYSTÉMECH. Jindřich Kaluža Ludmila Kalužová

Projekt výzkumu v graduační práci

Výzva k podání nabídek na veřejnou zakázku Software (II.) zadávanou v dynamickém nákupním systému Dynamický nákupní systém na software (II.

22/1997 Sb. ČR. Technické požadavky na výrobky. Hlava I. Úvodní ustanovení. Předmět úpravy

Zadavatel nepožaduje více než tříčlenný realizační tým, jehož členové budou disponovat kvalifikací a odborností ve vztahu k předmětu veřejné zakázky.

CW01 - Teorie měření a regulace

Protokol o atestačním řízení

Základy marketingu. vní. Ing. Miloslav Vaňák

Risk Management. Překlad a interpretace pro české prostředí

Metodická instrukce. Možnosti využití inspekčních nástrojů ke gramotnostem v práci školy

Analýza. Roman Danel 1. Metody analýzy

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM Č. 18

ZMĚNA ČESKÉHO OBRANNÉHO STANDARDU. AAP-48, Ed. B, version 1

A05 Stanovení způsobů ověření Praktické předvedení praktická neznamená jen manuální nebo ruční

Národní informační středisko pro podporu kvality

3 Inženýrství systémů založených na počítačích (Computer-based System Engineering)

Transkript:

INFORMAČNÍ POTŘEBY A POŽADAVKY NA SYSTÉM INFORMATION NEEDS AND SYSTEM REQUIREMENTS Jiří Vaníček Anotace: Jakost je definována jako souhrn význačných vlastností produktu, směřující k uspokojení potřeb uživatele. Zkušenost z hodnocení jakosti vede k závěru, že jedním z nejslabších míst při snaze o posouzení jakosti je právě skutečnost, že je obtížné potřeby uživatele popsat exaktně a formulovat je ve tvaru objektivně ověřitelných požadavků Příspěvek se zabývá analýzou vztahu mezi reálnými potřebami uživatelů informačních systémů a softwarových produktů a formulací požadavků, které z těchto potřeb vyplývají. Výsledkem analýzy jsou zásady a pravidla, kterými by se měly tyto požadavky řídit, aby byla zajištěna možnost následného použití exaktních postupů pro vyhodnocení jakosti nabízených konfekčních produktů i systémů vytvářených na zakázku pro zamýšlené užití. Výsledné "požadavky na požadavky na jakost jsou navrženy tak, aby umožnily použití mezinárodních norem pro hodnocení jakosti produktu řad ISO/IEC 9126, ISO/IEC 14598 a ISO/IEC 12119 pro hodnocení jakosti produktu a sloužily jako podklad pro normalizaci požadavků na jakost v řadě mezinárodních norem ISO/IEC 250xx připravované v projektu SQuaRE (Software Quality Requirements and Evaluation). Klíčová slova: Jakost. Informační potřeba.. Požadavek na jakost. Požadavek na požadavky. Mezinárodní norma. Projekt SQuaRE. Abstract: Quality is defined, as a set of relevant properties of product, which affects to the satisfaction of user needs. Experiences from the quality evaluation lead to the conclusion, that on of the main weakness during the effort to judge the quality consists in the difficulties with exact formulation of needs, which can be verified objectively. This contribution is addressing to the analysis of the relationship between real needs of information systems and software product stakeholders and the formulation of implied requirements implied, to provide the consecutive application of exact actions for quality evaluation of ready-made products and custom-made products for intended use. The resultant requirements for requirements are proposed in such a way, to allowed the application of international standards of the series ISO/IEC 9126, ISO/IEC 14598 and ISO/IEC 12119 for quality evaluation and to be applicable for the quality requirements standardisation in the international standards set ISO/IEC 250xx, prepared in the project SQuaRE (Software Quality Requirements and Evaluation). Keywords: Quality. Information need. Quality requirement. Requirement for requirements. International standard. Project SQUaRE.

1 ÚVOD Jakost je kromě ceny jedním z nejdůležitějších atributů každého produktu, který má být předmětem směny. V souladu s mezinárodními normami budeme produktem nazývat každý výrobek i každou službu nabízenou na trhu i kombinaci výrobku a služby. U produktů sloužících k uspokojení informačních potřeb jde téměř vždy o kombinaci výrobku a služby, která se k němu poskytuje. Podle mezinárodních norem se jakostí produktu rozumí souhrn jeho význačných vlastností, které směřují k uspokojení daných a stanovených potřeb uživatele, v případě, že je produkt používán v souladu se svým určením. Slova kvalita a jakost se v češtině užívají jako synonyma. Budeme užívat raději prvé, jazykově čistší. Tato obecná definice jakosti si zaslouží několik poznámek a upřesnění. Uživatelem (user) se obvykle myslí jedna konkrétní fyzická či právnická osoba, která je nabyvatelem produktu a očekává z jeho užití prospěch. Je však otázkou, zda se lze při posuzování jakosti omezit pouze na jedinou fyzickou či právnickou osobu. V anglické terminologii se kromě termínu user v souvislostí s jakostí užívá ještě slovo stakeholder, pro které asi není v češtině jednoslovný ekvivalent. Snad je vystihuje termín zainteresovaná strana. Jde o kohokoliv, kdo má vzhledem k užití produktu jakákoliv, byť jen částečná práva či oprávněný zájem a tím i nároky očekávat, že produkt splní jeho potřeby. Je zřejmé, že při hodnocení jakosti nelze zainteresované strany pominout. Zájmy různých zainteresovaných stran samozřejmě nemusí být totožné a často mohou být i protichůdné. Je zřejmé, že u konfekčních produktů je vždy více uživatelů a jejich potřeby se mohou lišit, často i podstatně. Jakost takových produktů tedy nikdy nelze hodnotit absolutně, ale vždy pouze z hlediska určité skupiny uživatelů s podobnými potřebami. Do jaké míry lze či nelze dát odhad jakosti pro širší okruh uživatelů závisí podstatně na tom, do jaké míry lze produkt konkrétním potřebám přizpůsobit. Při hodnocení jakosti je tedy nezbytné vždy brát v úvahu a výslovně uvádět z hlediska které skupiny zainteresovaných stran byla jakost hodnocena. 2 OD INFORMAČNÍCH POTŘEB K POŽADAVKUM NA SYSTÉM Nezbytným předpokladem pro objektivnost jakéhokoliv hodnocení je měření. Při hodnocení jakosti jde o porovnání naměřených hodnot vybraných atributů jakosti s hodnotami požadovanými. Stanovit, které atributy jsou v daném případě pro hodnocení jakosti podstatné a které nikoliv, bývá nesnadné. Ani měření skutečných hodnot atributů, dosažených daným produktem nebývá bez problému. Nejvážnějším problémem však bývá transformovat skutečné potřeby všech zainteresovaných stran do exaktních a objektivně měřitelných požadavků. Koneční uživatelé zpravidla nemají k tomu dostatek znalostí a zkušeností. Nezbývá jim tedy než se v této věci obrátit na specializované firmy. Pokud ovšem takováto firma bude pozdějším dodavatelem systému nebo se bude snažit zakázku na realizaci systému získat, vzniká vážné nebezpečí, že upřednostní své zájmy před zájmy budoucích uživatelů a dalších zainteresovaných stran. Požadavky pak často neodrážejí skutečné potřeby uživatele, ale spíše zájmy dodavatelů. Tento jev je v českých poměrech častý. S trochou nadsázky lze říci, že jak některé informační systémy ve veřejné správě fungují, vědí jen firmy, které je dodaly, ne ti, kteří je podle zákona mají spravovat. Co je automatizovat třeba a jak neurčují ti, kterým má automatizace prospět, ale ti, kteří chtějí maximalizovat zisky při minimální námaze. Uživatel se pak fakticky stává vazalem svého dodavatele. Východiskem z obtížně řešitelné situace samozřejmě nemůže být trvalé zaměstnávání špičkových odborníků v informatice v každé organizaci, která informační systémy hodlá využívat. Lze však naléhavě doporučit, aby formulací požadavků na systém byla pověřena firma, která sama o dodávku ani o systémovou integraci neusiluje a není z žádnou takovouto firmou svázána. Toto řešení nebývá levné. Z dlouhodobého hlediska se však většinou vyplatí. Informační potřeby vycházejí vždy z procesů, které v dané organizaci probíhají nebo

mají probíhat. Lze je tedy formulovat vždy jen ve vztahu k těmto procesům, k organizační struktuře a k strategii organizace, nikoliv ke konkrétním produktům. Úvaha o informatizaci která začíná sloganem je potřeba u nás zavést databázi xyx nebo datový sklad, nemůže vést k ničemu rozumnému. Požadavek nakoupit N osobních počítačů a zapojit je do sítě je ještě větší hloupost. Přesto se s podobnými záměry lze i nyní setkat. Na rozdíl od potřeb je třeba již požadavky formulovat ve vztahu k informačnímu systému, který má naše potřeby zabezpečit. Jde o to přesně formulovat jaké vlastnosti má takový informační sytém mít, aby naše potřeby zajistil na potřebné úrovni. Slovo potřebné je v této souvislosti třeba chápat opatrně. Je třeba si uvědomit, že nic není zadarmo. Každý by jistě rád užíval jen to nejlepší, někdy jen proto, že mu to jako nejlepší bylo presentováno. Situace, kdy někdo požaduje to, co ve skutečnosti nepotřebuje bývá častější, než bychom si na základě prvého pohledu snad mysleli. Jakost není samozřejmě jediným atributem produktu, který je pro jeho výběr a pořízení rozhodující. Stejnou, někdy i větší roli hraje jeho cena a náklady na provoz, někdy se uplatní i další hlediska. Při stanovení požadavků na jakost je třeba postupovat tak, aby splnění či nesplnění těchto požadavků bylo možné nezpochybnitelným způsobem prověřit. K tomu je třeba požadavky formulovat exaktně, měřitelně, aby bylo možné objektivně rozhodnout, zda byly dodrženy či nikoliv. K tomu slouží měření atributů jakosti. Dosažení specifikované úrovně jakosti by samozřejmě mělo být zahrnuto i do smluv na dodávku produktu, včetně ustanovení sankcí a náhrad v případě nedodržení požadované úrovně ze strany dodavatele. Za zmínku stojí, že potřeby uživatele zajišťuje vždy informační systém jako celek. Je tedy možné hovořit jen o jakosti informačního systému, do kterého patří software včetně dat, hardware, organizační opatření i lidé, kteří s informačními prostředky pracují. Zužovat úvahy o jakosti pouze na jakost softwaru nebo dokonce pouze na jakost programu bývá častou chybou. Nicméně čím dříve získáme odhady jakosti systému jako celku, tím lépe. Náprava v ranných stádiích životního cyklu bývá levnější. Když je vše hotovo, náprava bývá velmi drahá, někdy i nereálná. Proto je třeba hodnotit jednotlivé komponenty informačních systémů zvlášť, někdy i dříve, než jsou dokončeny. Mluvíme tak často o vnitřní jakosti jednotlivých komponent. Měli bychom však vždy mít na paměti, že tyto atributy jsou pouze prediktory, na základě kterých lze s větší či menší jistotou jakost výsledného produktu odhadovat, a že konečná jakost je málokdy pouze jednoduchou funkcí hodnot těchto prediktorů. PODPORA JAKOSTI V MEZINÁRODÍCH NORMÁCH V současné době odborná komunita o významu jakosti v informatice nepochybuje. Zřejmé je i to, že pohledy na jakost je třeba sjednotit celosvětově, pokud možno na úrovni mezinárodních norem. Význam norem je značný. Nelze jej však přeceňovat. Dosažení celosvětové shody napříč zájmy dodavatelů, uživatelů a akademických teoretiků nebývá právě snadné. Příprava norem trvá poměrně dlouho. Málokdy se podaří dodržet lhůtu pěti let. Obor se vyvíjí rychle. Stává se tak, že normy někdy konservují již překonaný stav a na rozvoj oboru nereagují tak rychle, jak by bylo zapotřebí. V současnosti jsou k dispozici mezinárodní normy, přebírané i jako evropské a české dvou základních směrů: Normy pro zajištění jakosti v procesu tvorby produktu, tvořené především revidovanou normou ISO 9000:2000 a navazujícími normami, ke kterým mají úzký vztah i některé normy řady ISO 100xx. Tyto normy jsou založeny na nezpochybnitelném poznatku, že pokud je ve firmě pořádek, budou její výstupy jakostní. Tyto normy vycházejí z požadavků na jakost a problému vztahu potřeby požadavky věnují poměrně malou pozornost. Jde o normy, které mají širší záběr než pouze na informatiku, a jsou poměrně dobře známé. V tomto příspěvku se o nich pouze zmiňujeme. Zasvěcený výklad o jejich významu lze nalézt například v [1]. Normy posuzující jakost z hlediska uživatele, bez přímého vztahu k tomu, jak produkt

vznikl. Tyto normy jsou dosud poměrně roztříštěné. Tvoří je šest norem řady ISO/IEC 14598, Norma ISO/IEC 9126-1 a na ní navazující tři technické zprávy a norma ISO/IEC 12119. V současné době probíhají práce na projektu SQuaRE (Software Quality Requirements and Evaluation), jehož cílem má být sjednotit normy pro jakost produktu do jediné řady ISO/IEC 250xx, pokrývající problematiku jakosti informačních produktů. Podrobnější informace o stávajících normách a o stavu a problémech projektu SQuaRE lze nalézt v [2], podrobněji pak v [3] a dalších zde citovaných publikacích autora tohoto příspěvku. Normy na jakost produktu vycházejí z definice jakosti, podle které jde o relativní pojem, závisející na potřebách uživatele. Různí uživatelé mohou mít velmi odlišné potřeby. Proto nelze jakost hodnotit pouze jako nedílný celek, ale je třeba ji rozdělit na jednotlivé pohledy, v kterých se mohou potřeby různých uživatelů lišit. V modelu jakosti, který je popsán v normách pro jakost produktu, bylo stanoveno šest tak zvaných charakteristik jakosti: Funkčnost, jako schopnost produktu zajistit požadované funkce. Bezporuchovost, jako schopnost produktu udržet v průběhu používání požadovanou úroveň výkonu. Použitelnost, jako schopnost produktu zajistit své využívání s mírou úsilí uživatelů, které nepřevýší požadovanou úroveň. Účinnost, jako schopnost produktu pracovat s přiměřenými nároky na čas a zdroje. Udržovatelnost, jako schopnost produktu být měněn při nalezení nedostatků, potřebě rozvoje systému nebo změny okolí v kterém systém pracuje. Přenositelnost, jako schopnost produktu pracovat v jiném prostředí a spolupracovat s jinými systémy. Tyto charakteristiky se dále dělí každá na řadu podcharakteristik. Pro jednotlivé charakteristiky a podcharakteristiky lze hledat měřitelné atributy. Ty se pak měří mírami v různých typech měřicích stupnic. Ze získaných měr pak lze získat hodnocení úrovně jakosti jednotlivých charakteristik a podcharakteristik a porovnat je s požadavky. Z povahy věci je zřejmé, že struktura CHARAKTERISTIKA PODCHARAKTERISTIKA ATRIBUT a jeho MÍRA není a nemůže být stromová. S politováním lze konstatovat, že tuto skutečnost si neuvědomují všichni uživatelé a někdy ani všichni spoluautoři norem. Z úřednického hlediska jde jistě o nepříjemnou komplikaci, Potřebu jednoduchosti však nelze nadřazovat faktickému stavu věci. Ještě vážnější skutečností je však to, že dosud nedošlo ke shodě, které atributy jakosti a jejich míry jsou u kterých typů produktů rozhodující. Návrhy měr jsou zatím obsaženy pouze v nezávazných technických zprávách a tvoří velmi nepřehledný a obtížně použitelný konglomerát. Tyto nedostatky by měl řešit projekt SQuaRE a měly by být odstraněny v řadě norem ISO/IEC 250xx. Autor příspěvku však není přílišným optimistou. Zdá se, že dohoda o tom, které atributy lze považovat za vypovídající a podstatné se neblíží. Nezbytnou podmínkou pro praktickou použitelnost norem pro jakost produktu je možnost dosaženou úroveň jakosti porovnat s požadovanou úrovní, vycházející z potřeb zainteresovaných stran. K tomu je samozřejmě potřeba zajistit, aby požadavky odpovídaly potřebám a aby byly formulovány ve tvaru požadovaných hodnot měr. Absence norem popisujících jak takto exaktně požadavky formulovat je další slabinou současného stavu mezinárodní normalizace, která má být v rámci projektu SQuaRE odstraněna. Ve struktuře připravovaných norem řady ISO/IEC 250xx je pro formulaci požadavků na jakost vyhrazena celá skupina norem ISO/IEC 25030 25039. Zatím je však připravován pouze jediný dokument ISO/IEC 25030 a osobní názor autora příspěvku na jeho úroveň není příliš optimistický. Úvahy zůstávají dosud spíše na povrchu.

4 POŽADAVKY NA POŽADAVKY Formulovat požadavky na produkt je třeba především pro Specifikaci produktu, včetně zahrnutí do smluv na dodávku nebo do podmínek výběrových řízení. Plánování, včetně studií proveditelnosti a transformace těchto vnějších požadavků do vnitřních požadavků na prediktory jakosti. Vývoj produktu, pro rannou identifikaci všech problémů během vývoje, které mohou požadovanou jakost negativně ovlivnit. Hodnocení výsledné jakosti produktu při dodávce, případně pro objektivní certifikaci dosažené úrovně jakosti. Veškeré požadavky musí být korektní, vzájemně konsistentní, úplné, přesné, měřitelné a testovatelné. Tyto požadavky na požadavky se mají týkat všech profilů předpokládaného užití systému. Problémy může samozřejmě způsobit nekonsistence požadavků různých zainteresovaných stran, majících k produktu vztah a oprávnění. Zájmy těchto stran mohou být odlišné. Případné rozpory je však nutné vyřešit mimo proces hodnocení jakosti produktu. Požadavky na jakost je třeba formulovat ve tvaru požadovaných hodnot jednotlivých atributů produktu. Každý požadavek musí být verifikovatelný v rozumném čase a s přiměřenými náklady. Je třeba vzít v úvahu skutečnost, že většina měr, které vyjadřují požadované a dosažené hodnoty atributů jakosti, je složená. Získají se jako hodnoty funkcí, jejichž nezávislými proměnnými jsou tak zvaná měřitelná primitiva, získaná pozorováním produktu nebo jeho funkce. Pro získání hodnot těchto primitiv je třeba produkt sledovat, někdy i v průběhu delších časových intervalů a získaná data shromažďovat a zpřístupňovat. Do nákladů na verifikaci požadavků je samozřejmě nutné zahrnout i náklady na získání, udržování a zpracování těchto vstupních dat pro hodnocení produktu. Požadavky na jakost by měly být formulovány odděleně pro jednotlivé charakteristiky jakosti. Je-li to třeba, mělo by být možné odděleně formulovat požadavky i na významné podcharakteristiky. Typickým případem takovéto podcharakteristiky je bezpečnost. Bezpečnost je považována za podcharakteristiku funkčnosti. Pro některé systémy má však klíčový význam, takže formulovat požadavky na ni odděleně je žádoucí. Bezpečnost je samozřejmě dobrým příkladem toho, že struktura navržená v modelu jakosti není stromová. Její vztah k bezporuchovosti je velmi těsný. Někdy může být účelné oddělit i požadavky na další podcharakteristiky. Potřeba formulovat požadavky na charakteristiky odděleně samozřejmě neznamená, že neexistují potřeby, které lze zajistit produktem, který neslibuje nic, pokud jde o některou charakteristiku. Pro jednorázové užití nepotřebujeme produkt udržovat, někdy nás nezajímá přenositelnost. V každém případě je však užitečné si uvědomit včas absenci požadavků k dané charakteristice explicitně. Ta chvíle zdržení stojí za to, že se nevystavíme nebezpečí, že jsme na něco podstatného zapomenuli. Požadavky k jednotlivým charakteristikám mají samozřejmě různé váhy, pokud jde o jejich významnost. Nikdo jistě nevynechá funkčnost. Produkt bez funkcí zabezpečujících naše potřeby je nesmyslem. Výsadní postavení funkčnosti svádí k tomu, formulovat požadavky na funkce zcela odděleně od (ostatních) požadavků na jakost. V návrzích normu ISO/IEC 25030 se dokonce projevuje snaha odlišovat functional requirements od functionality requirements a prvé z obou požadavků vyčleňovat mimo jakost. Přitom se (pochopitelně) nedaří vymezit, jaký by měl být mezi oběma typy požadavků rozdíl. Žádný totiž ve skutečnosti není. Jde jen o bezobsažnou hru se slovy, se kterou se ke škodě věci často v informatice setkáváme. Tyto tendence považuje autor příspěvku za škodlivé a nebezpečné. Jsou jedním z důvodů proč Česká republika nehlasovala pro přijetí pracovního návrhu normy ISO/IEC 25030 [4]. Funkce produktu jsou určeny k zabezpečení potřeb zainteresovaných stran. K ničemu jinému užitečné nejsou. Jde tedy o nedílnou a neopomenutelnou součást

jakosti produktu. O nic, co stojí někde vedle jakosti. Je patrné, že klíčové pro uplatnění modelu hodnocení jakosti je stanovení požadavků ve formě požadovaných hodnot měr jednotlivých atributů. Pokud nedojde k široké shodě na tom, které atributy jakost charakterizují, nebude tento podstatný vstup pro hodnocení k dispozici a celý model bude na vodě. Podle názoru autora příspěvku je nutné výzkum v rámci projektu SQuaRE zaměřit přednostně na získání zkušeností, které atributy charakterizují jakost pro nejdůležitější typy dnes užívaných informačních systémů a nejdůležitější profily jejich užití. V hodnotách těchto atributů, kterých nesmí být vybráno zbytečně mnoho a jejichž soubor musí být přehledný, pak budou moci zainteresované strany odpovědně stanovit úrovně, které je uspokojí, ale nebudou přitom zbytečně nadsazené, aby nevedly k plýtvání. S politováním lze konstatovat, že normalizační výbory a jejich pracovní skupiny, které projekt SQuaRE připravují, nemají dostatečnou podporu v širokém výzkumu a tuto potřebu podle názoru autora příspěvku podceňují. Absenci teoretických poznatků a zkušeností nemohou nahradit často mnohomluvné traktáty jak postupovat, až budou atributy vybrány a jejich míry někdo definuje. Do té doby půjde jen o bezobsažná slohová cvičení, která nemohou mít praktický dopad a tedy ani kladnou odezvu v odborné veřejnosti. Autor příspěvku je přesvědčen, že řada firem zkušenosti má a konsistentní soubory atributů a měr pro hodnocení jakosti používá. Zpravidla však považuje tyto zkušenosti a postupy za cenné duševní vlastnictví firmy, které chrání před konkurencí i svými zákazníky, a proto se brání je poskytnout odborné a normalizační komunitě. Literatura: [1] LACKO, B.: Systémový přístup k jakosti software. Tvorba softwaru 2004, VŠB-TU Ostrava, Ostravská univerzita, Masarykova univerzita Brno, TANGER, s.r.o a Česká společnost pro systémovou integraci, 2004, s. 129-138, ISBN 80-85988-96-8 [2] VANÍČEK, J.: Kvalita software ve světle mezinárodních norem. Tvorba softwaru 2004, VŠB-TU Ostrava, Ostravská univerzita, Masarykova univerzita Brno, TANGER, s.r.o a Česká společnost pro systémovou integraci, 2004, s. 311-321, ISBN 80-85988-96-8 [3] VANÍČEK, J.: Stav a perspektivy mezinárodní normalizace v oblasti měření a hodnocení jakosti informačních systémů a softwarových produktů. ČZU Praha, 2004, 67 stran, ISBN 80-213-1129-0 [4] ISO/IEC JTC1/SC7 N2981 Second CD Ballot CD 25030.2 Software engineering - Software quality requirements and evaluation (SQuaRE) - Quality requirements. http://www.jtc1-sc7.org/ Documents N2981 Kontaktní adresa autora Prof. RNDr. Jiří Vaníček, CSc., Katedra informačního inženýrství, Provozně ekonomická fakulta, Česká zemědělská univerzita v Praze Kamýcká 129, 16521 Praha 6 telefon 2 2435 2362 e-mail vanicek@pef.czu.cz