Jak vykročit správným směrem

Jak vykročit správným směrem

V obecném kontextu řízení projektů [1] se uvádí: „Vykročit správným směrem na cestě k cíli je velmi důležité. Pokud tak neučiníme, můžeme sice svůj omyl později napravit, vždy tím ale ztrácíme čas a peníze.„ O tom, jak v této úvodní fázi správně postupovat konkrétně v oboru tvorby systémů, pojednává tento článek.

Proč číst tento článek?

Informatika, stavebnictví, strojírenství, elektrotechnika, energetika, telekomunikace, logistika atd. Existuje mnoho odvětví lidské činnosti, jimž je jedno společné – vývoj více či méně složitých systémů. Do určité míry lze abstrahovat od toho, zda je vytvářen software, budova, strojírenské zařízení či logistický systém. Praxe ukazuje, že mnoho principů platí obecně pro jakýkoliv systém a že existuje i mnoho společných problémů a těžkostí, se kterými se při vývoji systémů odborníci obecně potýkají. Abstrahujme tedy od specifik jednotlivých odvětví a dále hovořme o obecném systému, jak jej definuje kybernetika.

Často je možné slyšet, že vytvářené systémy nenaplňují očekávání jejich uživatelů a že proces vývoje je komplikovaný a neefektivní. V průběhu vývoje vzniká množství chyb, které mají mnohdy fatální dopad na vlastnosti konečného produktu. Z hlediska možných důsledků je klíčové znát, kde, resp. v čem se nejvíc chybuje. Například ve stavebnictví lze často slyšet, že za špatné výsledky většinou nemohou samotní stavebníci ani projektanti, ale špatně definované požadavky. Ve sféře vývoje softwarových systémů (obor působení autora článku) přinesl pozoruhodné výsledky průzkum uskutečňovaný v posledních několika letech v USA. V jeho rámci byly zdroje chyb cíleně sledovány. Ukázalo se, že zdrojem více než 40 % všech chyb byly chybně určené požadavky (obr. 1). Nejde o náhodu – úvodní fáze vývoje, během které jsou stanovovány požadavky, tj. to, co má budoucí systém dělat, jsou pro úspěch celého snažení kritické.

Jak je to s náklady na opravu zmíněných chyb? Ukazuje se, že tyto náklady v průběhu vývoje zpravidla rostou geometrickou řadou. Například v oblasti vývoje softwarových systémů se uvádí, že rozdíl v nákladech na opravu chyby rozpoznané při úvodním vymezování požadavků a chyby zjištěné až ve fázi provozu může činit až tři řády. Jinak řečeno, je-li chyba odhalena včas, její oprava na papíře nemusí být žádný problém. Je-li však ta samá chyba odhalena až poté, co je systém realizován a provozován, může její náprava být značně nákladná. To neplatí jen o chybách, ale o jakýchkoliv změnách systému (jejichž zdrojem nemusí vždy být chyba, ale např. upřesnění požadavků zadavatele). Při zjednodušení vývoje systémů na fáze specifikace, projektování, realizace, testování a provozu může být průběh křivky nákladů na opravu chyby přibližně podle obr. 2.

Co je tedy nutné dělat? Jak se s úvodními fázemi vývoje vypořádat? Jak se vyvarovat možných těžkostí v závěrečných etapách? Jak udržet náklady na rozumné úrovni? Uvědomění si důležitosti specifikace systému bylo impulsem, který v poslední době vedl k výraznému posílení zájmu o úvodní fáze vývoje, jenž vyústil ve vznik nových metod, produktů, standardů a podpůrných softwarových nástrojů. Tento článek se snaží ukázat, že zrodu mnoha problémů lze předejít vytvořením kvalitní uživatelské specifikace budoucího systému. Článek je určen všem, kteří jsou aktivně zapojeni do procesů vývoje systémů a kterých se dotýkají problémy počínající v důsledku nedostatečného zajištění jejich úvodních fází.

Co je to uživatelská specifikace systému?

Uživatelská specifikace systému je dokument, tedy obykle spousta popsaných stran papíru. Jde o základní nástroj oboru nazývaného requirements engineering (tento termín lze volně přeložit jako správa a definování požadavků). O co jde? Kdysi dávno se přišlo na to, že k vytvoření „dobrého„ systému je nezbytné proces jeho tvorby rozdělit alespoň na dvě etapy. V první etapě – projektování – se na papíře popíše, jak se bude postupovat v etapě druhé – při realizaci. Později však zkušenosti ukázaly, že to nestačí; že nejprve je nezbytné definovat, co vlastně mají projektanti projektovat. A tak došlo k dalšímu oddělení určitých činností, které nyní náležejí do oblasti definování požadavků. Důležité přitom je oddělení rolí – v úvodu musí převažovat pohled uživatele; pohled projektanta (technického specialisty) se uplatňuje teprve později.

Uživatelskou specifikaci systému tedy lze definovat jako dokument, který ve strukturované, a často i standardizované formě sdružuje všechny uživatelské požadavky na systém přijaté od uživatelů. Objevuje se tedy další pojem – uživatelský požadavek. Ten je zde možné považovat za klíčový. Správné pochopení významu tohoto pojmu představuje základní nezbytnou kvalifikační způsobilost dobrého analytika požadavků (jak se nazývá příslušná pracovní pozice). Za jednu z možných definic lze uvést, že se jedná o standardizované vyjádření určité uživatelovy potřeby nebo definici služby, kterou systém poskytuje. Pozor, uživatelské požadavky jsou velmi často směšovány s rozhodnutím o tom, jak zmíněné požadavky realizovat (jakými technickými či programovými prostředky, jakou formou dodávky, v jakém pořadí atd.). Tyto dvě významově velmi odlišné skupiny informací je však bezpodmínečně nutné od sebe oddělovat.

Rozlišení a oddělení uživatelských požadavků od určení způsobu, jakým budou splněny (to by mělo být předmětem až následných etap projektování), je kritickým okamžikem. Jeden požadavek totiž zpravidla lze splnit několika různými způsoby. Ty se však mohou navzájem značně lišit (vhodností volby, technickou a časovou náročností, cenou apod.), a především spolu nemusí být konzistentní. Tyto informace však většinou na začátku prací na projektu nejsou k dispozici a navíc je nezbytné posuzovat je komplexně, jako celek. Proto je třeba nejprve v podobě uživatelských požadavků stanovit vše, co má systém zajišťovat, a teprve později zvolit optimální způsob jeho řešení.

Dalším klíčovým pojmem, již několikrát v textu použitým, je pojem uživatel. Kdo je to v kontextu definování požadavků? Za uživatele je nutné považovat všechny osoby, které budou s dotyčným systémem určitým způsobem v interakci a které očekávají, že systém je podpoří v jejich práci. Co se týče např. vývoje softwarových systémů, jeho uživateli v žádném případě nebudou pouze koncoví operátoři, kteří pracují s formuláři, jež systém poskytuje. Bude-li systémem letadlo, k uživatelům nebudou patřit jen pasažéři, ale i piloti, letušky, pozemní obsluha, úklidová četa, mechanici a také letoví dispečeři v řídicí věži, kteří letadlo navádějí. Při hlubším zamyšlení by bylo třeba přihlédnout např. i k požadavkům ekologů, kteří požadují nízkou úroveň znečišťování prostředí zplodinami z proudových motorů. Kdyby např. letečtí mechanici požadovali letadlo snadno udržovatelné a v projektu by se nepřihlédlo k požadavkům jiných typů uživatelů, s letadlem by se možná velmi obtížně létalo. Proto je nutné brát ohled na všechny požadavky všech uživatelů, přestože třeba některé budou později odmítnuty. Nebudou-li však zaznamenány, ztratí se možnost o jejich zahrnutí do specifikace budoucího systému vůbec rozhodovat, ačkoliv mohou být pro jeho správné fungování důležité.

Uživatelská specifikace systému může mít různou formu. Nejde však o pouhé nakupení všech požadavků na jedno místo. Kvalitní uživatelské specifikace organizují přijaté požadavky do určité struktury tak, aby bylo možné s nimi dále efektivně pracovat. Požadavky mohou být ohodnoceny svými atributy, popř. propojeny vazbami. Přitom tyto údaje mohou výrazně zvětšit informační hodnotu celého dokumentu. Atribut je určitá vlastnost požadavku, která jej blíže specifikuje, a kterou není vhodné zařadit přímo do textu požadavku. Často se používají atributy jako priorita, zdroj, ověřitelnost požadavku atd. Vazbou se nazývá záznam určitého vztahu mezi požadavky. Uvedených vztahů může být velké množství. Nejčastěji se takto zaznamenávají funkční závislosti. Takovéto propojení vazbami pak poskytne např. informaci o tom, které požadavky může ovlivnit změna nebo zrušení určitého požadavku.

Co předchází a co následuje?

Jaký je kontext uživatelské specifikace? Jaká je pozice její tvorby v rámci procesu vývoje systému? Řekli jsme, že její tvorba představuje úvodní etapu vývoje. Je však nutné dodat, že požadavky nejsou stanovovány zcela na „zelené louce„. Vše, co se v podniku děje, musí směřovat k naplnění strategických cílů. Ty by měly být uvedeny ve strategických dokumentech (tj. globální a dílčí strategie). Jde o dokumenty, které dávají smysl všem podnikovým aktivitám a obsahují hlavní podnikové záměry a cesty k jejich dosažení. Těmito cestami mohou být projekty vývoje systémů, práci na nichž je třeba začít právě uživatelskou specifikací.

Strategické cíle jsou tedy pro vymezení uživatelských požadavků jakýmsi východiskem. Jaké etapy na specifikaci systému navazují? Obecně lze říci, že je to projektování (v kontextu vývoje softwaru se hovoří o analýze a návrhu). Zde vyjádřené informace se však od uživatelských požadavků liší svým obsahem, původem a účelem – řeší se technicko-ekonomické otázky, odpovědni za ně nejsou uživatelé, ale projektanti (analytici a návrháři), kteří určují, jak mají realizátoři postupovat. Začít s touto etapou bez předchozího definování uživatelských požadavků je cesta k nezdaru projektu. Je tomu tak proto, že by pak mohlo velmi snadno dojít k chybnému pochopení, popř. opomenutí některých uživatelských potřeb a k následné chybné volbě technického řešení.

K čemu to může být dobré?

Jak ovlivňuje dobrá uživatelská specifikace tři základní charakteristiky projektu, tj. kvalitu, čas a peníze? Nejvýraznější vliv má na kvalitu výsledného systému. Pokud neexistuje definice toho, co má být uděláno, mohou snadno nastat situace, kdy je řešeno to, co není třeba řešit, a nebo naopak není řešeno to, co je nezbytné. Je-li v této definici chyba, je velmi pravděpodobné, že bude přímo promítnuta do konečného produktu. Vyjde-li se z předpokladu, že kvalita výstupu jakékoliv etapy vývoje je vždy zčásti funkcí vstupů této etapy, je zřejmé, že kvalita specifikace systému je kritická pro všechny následující etapy vývoje.

Vliv na dobu vývoje systému je třeba posuzovat v dlouhodobém horizontu. Časová náročnost projektu krátkodobě narůstá. V souvislosti s jinými pozitivními vlivy (existence podkladu pro další etapy vývoje, růst kvality a pokles počtu chyb atd.) však specifikace požadavků v delším období jednoznačně vede ke zkracování celkové doby potřebné k realizaci projektu. Časový náskok uspěchaných projektů, kde je tato etapa zanedbána, bývá uživatelsky specifikovanými projekty velmi brzy vyrovnán.

Téměř vše, co zde bylo řečeno o době realizace projektu, platí i o nákladech na projekt. I do specifikace systému je nutné určitý podíl nákladů investovat. V celkovém souhrnu nákladů na projekt se však tato investice vyplatí. Jestliže se na začátku prací ušetří, může se vše v konečné fázi značně prodražit. Vynaložením určitých prostředků na počátku si tudíž lze „zakoupit„ jakési snížení nákladů v dalších fázích projektu.

Vytvoření kvalitní specifikace systému má mnoho výhod. Může z ní totiž čerpat subjekt, který bude budovaný systém využívat (zadavatel), i jeho dodavatel (realizátor systému).

Přesným vytčením uživatelských požadavků může zadavatel získat zcela nové know-how. Je tomu tak zejména v případech, kdy je specifikován nový, nepromyšlený systém, a je-li tvorba požadavků vedena zkušenými odborníky, lze mnohdy formalizovat zcela nové myšlenky, které do té doby ve firmě nebyly zaznamenány. Uživatelskou specifikaci může zadavatel využít rovněž jako jeden z podkladů pro výběrové řízení, neboť obsahuje popis poptávaného produktu, který řešitel nabízí za svou cenu. Dále může specifikace pomoci při formulaci smlouvy o dodávce systému – předmětem smlouvy se stává realizace všech (popř. vybraných) požadavků v určitém termínu za určitou cenu. Je-li systém hotov, musí si zadavatel ověřit, zda odpovídá jeho potřebám – a uživatelská specifikace systému je pro to opět výchozím dokumentem (uvádí se, že by měla být základním rámcem pro vypracování akceptačních testů).

Realizátor systému využije uživatelskou specifikaci při výběru optimálního řešení jako podklad pro další etapy vývoje (obsahuje odpověď na otázku, co dále projektovat, realizovat, otestovat a později provozovat). Dále je to jeden ze zdrojů procesu řízení kvality, neboť jde o základní ideální model systému, podle kterého je budován reálný systém (kritéria kvality je navíc možné stanovit přímo jako uživatelské požadavky).

Metody a nástroje

Co se týče podpory tvorby uživatelských specifikací systémů, existuje velký počet obecně přijímaných principů a postupů tvořících metodickou základnu již zmíněného oboru definování požadavků (requirements engineering). Jednotlivé společnosti si tyto základní principy zpravidla upravují a doplňují je pro své potřeby.

Uživatelská specifikace systému je dokument, který obvykle obsahuje textový popis jednotlivých požadavků a dále množinu grafických modelů (diagramů) určených pro pochopení věcné oblasti a odvození textových požadavků. Je tedy nutné pracovat s textovou i grafickou podobou informace. Výrazně přitom mohou usnadnit práci podpůrné softwarové nástroje.

V oblasti konstrukce analytických diagramů trh nabízí mnoho různých nástrojů typu CASE (Computer Aided Software Engineering, popř. Computer Aided System Engineering), podporujících různé metody a notace. Nástroje pro definování vlastních textových požadavků již tak početné nejsou. Jde o kategorii tzv. Upper CASE nástrojů, která je označována jako tzv. RCAT (Requirements Collection Analysis Tools). Mezi nejznámější nástroje této skupiny patří např. ReguisitePro, DOORS nebo CaliberRM. O tom, že principy specifikace různých typů systémů jsou společné a že k její tvorbě lze využít také obdobné nástroje, svědčí skutečnost, že např. nástroj DOORS, který je „jedničkou„ v oblasti tvorby požadavků na softwarové systémy, byl původně vyvinut k definování požadavků na vojenské ponorky.

Katalog uživatelských požadavků od Komix s. r. o.

Vytvoření kvalitní uživatelské specifikace systému nelze zlehčovat na jakési „sepsání toho, co vlastně potřebujeme„. Mnoho firem proto raději dává přednost využití znalostí externích odborníků nebo alespoň jejich podpoře. Externí odborníci se na věcnou oblast systému dívají s potřebným nadhledem a redukují nároky na účast uživatelů, kteří bývají značně vytíženi běžnými pracovními úkoly organizace. Společnosti vytvářející uživatelské specifikace mají v této oblasti zpravidla větší zkušenosti; navíc lze očekávat, že budou vládnout i vhodnou metodickou podporou.

Jedním z průkopníků definování uživatelských požadavků v ČR je společnost Komix s. r. o., která se uvedené problematice věnuje již mnoho let. Společnost Komix rovněž patří mezi firmy v ČR, které nejdříve začaly tvorbu uživatelských specifikací systémů koncepčně systematicky podporovat. Její produkt, jenž tuto oblast pokrývá, se nazývá Katalog uživatelských požadavků. Jedná se o strukturovanou standardizovanou uživatelskou specifikaci systému, která je vytvářena podle mnohokrát úspěšně aplikované firemní metodiky.

Metodiku společnosti Komix tvoří několik základních stavebních kamenů. Hlavním východiskem se staly obecně přijímané principy disciplíny definování požadavků (reguirements engineering). Další významnou komponentou, na které je metodika postavena, je soubor objektově orientovaných metod. Je využíváno množství typů analytických modelů statického i dynamického pohledu na systém. Ty jsou formulovány s využitím grafického jazyka UML (Unified Modelling Language), reprezentujícího současný standard v oblasti projektování informačních systémů. Třetí významnou částí základu metodiky je soubor principů řízení projektů, které je vhodné uplatňovat (jde o promyšlený sjednocující rámec postupu, který definuje, co a kdy je nutné zajistit pro to, aby byl projekt tvorby katalogu požadavků úspěšný).

Katalog uživatelských požadavků je tvořen podle metodiky společnosti Komix ve třech hlavních fázích (obr. 3). Jednotlivé fáze se navzájem liší mírou detailu a formou záznamu zpracovávaných informací. V první fázi se na systém pohlíží „z velké výšky„, přičemž cílem je stanovit hranice systému (určit, co do systému patří a co nikoliv). Ve druhé fázi se k systému přistoupí na takovou vzdálenost, aby bylo možné identifikovat všechny důležité detaily. Veškeré údaje zaznamenané v první fázi jsou detailizovány až na úroveň samotných požadavků. Převážná většina údajů se zaznamenává prostřednictvím grafických modelů. V třetí fázi je vytvořen vlastní katalog. Není jej však možné sepsat „od začátku do konce„. Nejprve je vytvořena struktura; až poté jsou z grafických modelů odvozovány jednotlivé požadavky, kterými je struktura naplňována. Jsou-li všechny požadavky definovány a zařazeny do struktury, jsou ohodnoceny rozšiřujícími atributy a popř. propojeny vazbami.

Aby byla uživatelská specifikace systému výstupem, který umožní maximálně rozvinout své přínosy a možnosti využití, musí splňovat určitá kvalitativní kritéria. Existují obecně přijímaná kritéria kvality samotných požadavků (srozumitelnost, unikátnost, ucelenost, jednoznačnost atd.) i dokumentu jako celku (strukturovanost, vyváženost, kompletnost, konzistence apod.). Metodika společnosti Komix je koncipována tak, aby zmíněná kvalitativní kritéria byla naplněna (obr. 4).

Významnou otázkou ohledně specifikace systémů je standardizace. Standardizační procesy v současnosti patří k nejsilnějším hospodářským trendům. O pozitivních přínosech normovaných výstupů není pochyb, zvláště v prostředích, kde se neustále rozvíjejí nové metody a postupy. Proto zásady standardizace respektuje i Komix. Katalogy požadavků vytvořené ve zmíněné společnosti jsou v souladu se standardem Evropské kosmické agentury (European Space Agency – ESA).

Co se týče rysů projektů tvorby specifikace systému, mají mnoho specifik. Vyžadují spíše hodně komunikace a tvořivosti než technické znalosti a dovednosti. Jejich typickým rysem je intenzivní interakce s uživateli (nejintenzivnější v rámci životního cyklu systému). Velkým problémem uvedených projektů může být určitá nechuť, či dokonce strach pracovníků ze změn, které může projekt iniciovat – jediným řešením je opět intenzivní komunikace.

Závěr

Stanovení uživatelských požadavků na systém je nezbytnou podmínkou úspěchu jeho vývoje. Ukazuje se, že určitá zanedbání v této etapě mohou mít velmi negativní až fatální dopad na další etapy i na konečný produkt. Uživatelské požadavky uvedené ve specifikaci systému se zásadně liší od informací popsaných technickými specialisty v etapě jeho projektování. Jsou-li respektována základní kritéria kvality, může být specifikace požadavků na systém přínosem pro zadavatele i řešitele systému. Současně ji lze ve velké šíři využít i mimo užší oblast vlastního vývoje systému.

Tomáš Hrubý,
Komix s. r. o.