Interaktivní vývoj eliminuje rizika

Naše manažerka bezpečnosti přemýšlí o změně práce, ale u potenciálního zaměstnavatele naráží na zmatek. Setkal...


Naše manažerka bezpečnosti přemýšlí o změně práce, ale u potenciálního
zaměstnavatele naráží na zmatek. Setkala se s CIO, řediteli pro IT a vývoj
softwaru a s ředitelem pro interní audit. Strana 29
Vertikální ukládání dat Vertikální ukládání dat představuje velmi moderní
technologický koncept, který už v praxi mnohokrát prokázal své přínosy. Nabízí
zejména efektivní hromadné zpracování dat a úsporu nákladů. Strana 30
Jak vybírat webhosting?
Představte si situaci vybíráte webhosting pro svůj vysněný projekt. Jaká si ale
máte stanovit kritéria? Nejvíce protežovanou hodnotou je dnes velikost prostoru
pro váš web. Velikosti v řádech jednotek gigabajtů jsou běžné, ale zpravidla si
za ně náležitě připlatíte. Často úplně zbytečně. Strana 32
Systémy, které se podobnými cestami vyvíjely, byly poměrně jednoduché hned z
několika důvodů. Využíval je obvykle jen malý počet uživatelů, a proto nebyl
problém sjednotit jejich požadavky. Typickým příkladem vývoje tradiční cestou
byly například účetní nebo skladové systémy s naprosto jasnou agendou nebo
starší bankovní systémy, které jsou sice nepoměrně složitější, ale jejich
agenda je jednoznačná a navíc definovaná zákonem. Kromě toho vývojář systému
byl na řešenou problematiku často větší expert než sami zadavatelé. Technické
prostředky v této době nebyly tak dokonalé, takže se nedala vymýšlet spousta
"dobrých" vlastností, které by měl systém mít. Každý se soustředil na to, co je
nejdůležitější. Časy se ovšem změnily, počítače, počítačové sítě a internet se
rozvíjely. Ukázalo se, že je možné od nových systémů požadovat velké množství
různých parametrů že nemusejí plnit jen základní funkce, ale mohou být také
uživatelsky přívětivé. Nový informační systém se ve firmě rovněž týká mnohem
většího počtu uživatelů a ti často dokáží vymyslet daleko víc požadavků, než
kolik se jich dá ve skutečnosti reálně implementovat. Postupně se také
vytratilo skryté povědomí o tom, že používání softwaru je něco složitého tím
padla i zábrana chtít po vývojářích také něco jiného, než jen nejdůležitější
atributy. Jak vzrostly technické možnosti systémů, stoupla i rizika selhání při
jejich vývoji z pohledu příslušného dodavatele.
Zbytečné požadavky
Situace ovšem není ideální ani pro klienty samotné. Cokoli totiž bude systém
dělat, musí někdo navrhnout, vytvořit a otestovat. Každá z těchto činností
stojí peníze. A i pro zákazníka je důležité, aby přínos softwarového řešení
převýšil, anebo alespoň vyvážil náklady na jeho pořízení.
Druhý problém spočívá v prostém faktu: čím větší počet požadavků, tím vyšší
složitost systému. A tak často požadavky, které nejsou ani tak důležité pro
funkční systém, velmi výrazně zvyšují složitost a cenu konečného řešení.
Vzhledem k tomuto vývoji se softwarové společnosti vydaly cestou prioritizace
požadavků a důsledného provázání mezi potřebou, požadavkem a funkčností. Proto
se před sběrem požadavků provádí definice základních potřeb (nebo přínosů),
které má systém zadavateli umožnit. Po sběru požadavků je každému požadavku ve
spolupráci se zadavatelem přidělena odpovídající priorita, což umožní vybrat
skutečně důležité atributy. Určení priorit ovšem není nijak jednoduché. Budoucí
uživatelé často nejsou schopni určit, podle jakých kritérií by měli priority
určovat. Počáteční určení obchodních přínosů a potřeb se zdá být tak
jednoduché, že je obvykle podceněno. Pokud se ale stane chyba hned na začátku,
lze pak očekávat, že další rozhodnutí o vlastnostech vytvářeného systému budou
provedena správně? V tomto případě se mnohdy stává, že v závěru projektu je
instalován systém, který obsahuje funkce, které nejsou nakonec potřeba nebo se
používají jen výjimečně. Čas strávený na vývoji systému se přitom mohl využít
nepoměrně lépe, například k tomu, aby klíčové funkce byly lépe propracovány,
otestovány, a pomohly tak plně naplnit skutečné potřeby zadavatelů.
U skutečně velkých informačních systémů vzniká navíc ještě další problém. Každé
takové řešení je totiž nezbytné měnit. Například produkt sloužící pro správu
personální agendy, který pouze podporuje hlavní výrobní proces, je možné měnit
celkem plánovitě. Ale tam, kde je zavedení nového softwaru spojeno se změnou
celkového systému, což je běžné třeba v bankovnictví nebo v telekomunikacích,
je tempo změn diktováno trhem a konkurencí. Vnitřní struktura systémů proto
musí být jednoduchá, snadno změnitelná a rozšiřitelná. Ovšem s počtem
absorbovaných požadavků roste komplexnost systémů, která zvyšuje riziko
neúspěchu při realizaci změn. Zbytečné požadavky zvyšují složitost, kvůli čemuž
roste riziko selhání a rovněž se prodražuje provoz či další rozvoj. Každý
zbytečný požadavek se tak v podstatě za dobu užívání systému mnohonásobně
prodraží. Podstatné požadavky
Obchodní pohled na výsledné řešení ovšem nepostrádají iterativní metody
softwarového vývoje. Přidávají k otázce potřeb klienta, očekávaných přínosů a
požadavků na systém další stupeň. Říkají totiž, že pro zadavatele i vývojový
tým je jedním ze základních problémů ustavit hned na začátku požadavky na
systém přesně. To je sice možné, ale tak časově náročné, že by to vývoj systémů
vytvářených na míru pro jednoho klienta příliš prodražilo. Odpovědí je tedy
nesnížit kvalitu definice požadavků, ale rozložit jejich tvorbu v čase.
Dnes už klasická metodika iterativního vývoje se jmenuje RUP (Rational Unified
Process). Základem fungování RUP je to, že se snaží většině problémů při
klasických metodách vývoje předejít jde o původní metodiku vývoje softwaru
vytvořenou a používanou společností Rational Software. Iterativní vývoj sice
předchází typickým rizikům, nicméně postup vývoje softwaru je jiný, než na jaký
jsou klienti už tradičně zvyklí. A tak mnoho zákazníků bývá skutečně překvapeno.
V souladu s pravidly inkrementálního a iterativního vývoje se vybere základní
množina funkčností a nad tou je zahájen vývoj, přičemž poměrně brzo je
zákazníkovi předložen jeho výsledek. To klientovi umožní vidět (a rovněž si
vyzkoušet) "první nástřel" řešení a na základě této zkušenosti říci, jakou
cestou se vydat dál. Samozřejmě, i v případě iterativního vývoje je třeba mít
jasnou vizi už na samém začátku. Proto se také první etapa RUP projektu jmenuje
"Tvorba vize". Nicméně i samotnou vizi lze vytvářet iterativně. Zákazník má
možnost se vyjádřit, jestli jsou jeho představy zachyceny správně a zda mu
systém vyhovuje. Vize se přitom soustřeďují jen na hlavní rysy systému, čímž je
zajištěno to, aby se zákazník ani dodavatel neztratili v detailech a
soustředili se pouze na skutečně podstatné rysy řešení. V dalších iteracích pak
klient ve spolupráci s dodavatelem provede rozpracování dalších požadavků a
společně vyhodnotí, zda zůstávají stejné, nebo zda dojde ke změně. Jedním z
pravidel iterativního vývoje je, že projekt se musí řešit tak, aby se největší
riziko odstranilo co nejdříve. Na začátku je totiž riziko neadekvátního zadání
poměrně vysoké. Po získání adekvátní zpětné vazby od klienta se jeho značná
část odbourává.
RUP v současnosti existuje již v řadě mutací pro specifické typy vývoje. Jinak
se vyvíjí software, který je prodáván širokému spektru zákazníků (například
antivirový program, který se každoročně upgraduje), a jinak je třeba vyvíjet
software na zakázku, neboť každý klient vyžaduje zcela jiné řešení.
Komplikace RUP
I metodika Rational Unified Process má ovšem svá úskalí. Z praktického
používání metody totiž vyplynuly dva kritické body. První z nich představuje
pochopení ze strany zákazníka ten byl do této doby zvyklý na to, že si na
začátku popíše požadavky a na konci zkontroluje výsledek. Nyní je od něj
vyžadována mnohem častější spolupráce s dodavatelem, pravidelná revize výstupů
práce, zpětná vazba, spolurozhodování o prioritách požadavků apod. Stejně tak
nezvyklé je pro klienty i stanovení fixní ceny před zahájením projektu.
Řada zákazníků ale požaduje kompromisní přístupy. Například menší počet iterací
nebo první iteraci zaměřenou na zjištění všech faktorů, které by mohly ovlivnit
cenu a dosažitelnost cílů projektu (často se pro to používá termín "studie
proveditelnosti"). Tak lze dosáhnout až 80% přesnosti při stanovení ceny. Pokud
je ale metodika RUP použita správně, vede k dobrému poměru mezi cenou projektu
a přínosem systému pro klienta projektový manažer a zákazník se totiž úplně od
začátku řídí pravidlem nepřipustit investice čehokoli jiného než jen prostředků
skutečně nutných pro cíl projektu. V takovém okamžiku je pravděpodobné, že cena
nevzroste. Zákazníci ovšem občas nechápou význam součinnosti v průběhu tvorby
softwaru. Přitom právě průběžná součinnost ušetří řadu nepříjemných aspektů,
především pak překvapení, když například po čtyřech měsících uvidí systém,
jehož vývoj pravda sice ani nezaznamenali, ale kde je nutné aplikovat významné
množství změn. Alternativní metodiky
Druhé riziko, které se v metodice Rational Unified Process projevilo, je
překvapivým důsledkem toho, jakou formu autoři RUP pro jeho popis zvolili.
Základním konceptem v popisu RUP je totiž také popis rolí, které jednotliví
aktéři vývoje softwaru hrají. Problém pak vzniká ve vývojovém týmu, pokud si
jednotliví členové neuvědomí, že primárním cílem jejich práce není "naplnit
popis role", ale přispět k úspěchu klienta dodávkou fungujícího softwaru. Pokud
se totiž v rámci týmu striktně rozdělí jednotlivé role, reálně pro jednotlivé
členy hrozí ztráta smyslu jejich práce. Každý člen týmu realizuje své výstupy
na základě vstupů od ostatních, aniž by docházelo k řádné komunikaci o
problémech a bez toho, že by si členové týmu vzájemně pomáhali, čímž se téměř
popře smysl týmové práce. Fakt, že výsledky práce vedou ke vzniku softwaru,
ustupuje u jednotlivých aktérů do pozadí.
Často se společnostem, které s RUP teprve začínají, stane, že nedokáží
motivovat jednotlivce v týmu, aby se zajímali o to, co má software dělat. A aby
se mohli správně rozhodovat v situacích, kdy některá fakta nejsou z podkladů
jasná. Díky tomu si problematika RUP našla i celou řadu odpůrců. Ti časem
vyvinuli řadu alternativních metod, souhrnně nazvaných agilní metodiky. Jak se
ukázalo po několika letech, jde jenom o jinou obdobu interaktivního vývoje.
Rozdíl je dnes pouze v tom, že agilní metodiky se nesoustřeďují na popis rolí,
ale na popis smyslu práce způsobu komunikace uvnitř týmu. Důraz je tak kladen
na řízení týmu a týmovou spolupráci.
Došlo k souboji netradičních metod. Jedni trumfovali přesným popisem, druzí
týmem motivovaných lidí. Dnes se obecně uznává platnost obou přístupů. Pokud je
tým pohromadě a zákazník snadno dostupný, pak jsou agilní metodiky určitě na
místě. Avšak v případě dislokovaných týmů či obtížné dostupnosti klienta jsou
vhodnější naopak formálnější metodiky, jako je právě RUP.
Čtyři fáze RUP
Typický interaktivní vývoj podle metodiky RUP se rozděluje do čtyř fází. První
z nich je již zmiňovaná tvorba vize systému. Tam se odhadne zhruba osmdesát
procent potřeb a požadavků. V průběhu iterací se požadavky zpřesňují. Vize
systému říká, k čemu má systém primárně sloužit, jaké jsou potřeby zákazníka a
jaký je přínos z hlediska byznysu klienta. Jasně stanoví základní požadavky ve
smyslu uživatelského komfortu.
Druhá fáze znamená rozpracování řešení jednotlivých požadavků a návrhu
funkčností. Na nejsložitější části odhalené při vzniku vize se vytváří
prototypy, čímž se ověří, že se to, co bylo vnímáno jako požadavky, dá skutečně
naplnit. Současně se pokračuje dál ve sběru detailních požadavků a jejich
dalším zpracování. V tomto okamžiku se realizuje největší objem práce s
požadavky.
Ve třetí fázi probíhá samotný vývoj projektu. Podle metodiky RUP se programuje
a řeší dílčí požadavky zákazníka. Třetí fáze lze s trochou nadsázky přirovnat k
té etapě výstavby rodinného domku, kdy se rozhoduje o umístění kuchyně či
vytápěcích a vodovodních rozvodů, zatímco v předchozí fázi se spíše tvořily
plány a výkresy skeletu domku.
Poslední fáze RUP nasazení a předání do provozu se realizuje ve chvíli, kdy je
software hotový a uvádí se do provozu. I v této fázi bývá zvykem zanášet drobné
změny, ale zpravidla jde jen o výsledky testů a opravy případných chyb. Pokud
si opět vezmeme příměr ke stavbě rodinného domku, jedná se o okamžik, kdy je
pozván bytový architekt a kdy se postaví židle na správná místa v místnosti.
Konečné požadavky by bylo zbytečné zjišťovat předem.
Krátká doba
Statistiky jednoznačně dokazují, že je praktičtější a užitečnější rozdělit
projekt do více menších částí. Právě z pohledu statistiky je jednoznačně
dokázané, že čím je softwarový projekt rozsáhlejší, tím vyšší je
pravděpodobnost neúspěchu. Vzhledem k tomu, že softwarové řešení má primárně
napomáhat byznysu, hrozí při protahování realizace změna konkurenčního
prostředí. Obchodní okolí se prostě změní natolik, že i na začátku správný cíl
softwarového projektu se na konci může zdát úplně chybný.
V prostředích, jako je bankovní sektor nebo telekomunikace, kde je závislost na
informačních systémech velmi vysoká, se ke zkrácení doby projektu využívá
inkrementální přístup. Klient má obvykle jasnou vizi, že chce systém, který
vyřeší všechno: účetnictví, sklady, logistiku, obchod nebo řízení lidí. Ale v
každé fázi života klienta je něco, co je aktuálně nejdůležitější. Inkrementální
postoj říká: soustředit se na to nejvýznamnější, vytvořit jen část systému a
teprve pak se zabývat dalšími potřebami. Nesnažit se hned na začátku navrhnout
systém, který řeší všechno. Inkrementálnímu přístupu napomáhají i moderní
technologie. Zajišťují totiž velkou přenositelnost vyvinutých částí softwaru a
propojitelnost částí vyvinutých různým způsobem. Komunikaci částí, které byly
vyvinuty zcela samostatně, jde zajistit prostřednictvím standardních protokolů,
přes internet či celou řadou jiných způsobů. Části mohou být vyvinuty v různých
firmách a nemusejí být nutně postaveny na stejné technologii.
Hranice se posouvají
Vývoj softwaru na zakázku je samozřejmě vždy otázkou velkých či profesně velmi
specifických firem. Díky tomu, že velkým firmám mohou systémová řešení ať na
úrovni úspor, optimalizace či odbytu být velkým přínosem, uvolňují tyto
organizace na rozvoj svých systémů také větší množství peněz.
Pro malé firmy se naopak vyplatí koupit si už hotové standardizované řešení, a
to i přes to, že jim nebude přesně na míru. Ocení naproti tomu velice nízkou
cenu řešení, jež je koncipované pro široké spektrum klientů. Čím je firma
větší, tím rychleji stávající řešení přestávají vyhovovat nepomohou firmě se
konkurenčně odlišit a vedou k průměrnosti.
S přibývajícími možnostmi informačních technologií ovšem dochází k zajímavému
trendu daří se totiž stále více vyrábět modulární řešení. Jde v podstatě o
střední cestu: ani o standardní řešení, ani o systém na míru, ale o možnost
složit si z prodejných komponent vlastní částečně originální řešení. Díky tomu
se posouvá hranice, kdy je vhodné zvolit systém na zakázku a kdy zvolit
takzvanou zlatou střední cestu. Pro čím dál tím větší počet větších firem je
rovněž vhodným řešením nechat si systém poskládat z požadovaných komponent. Co
se týče vývoje softwaru na zakázku, kupující se dají na základě empirie
rozdělit do tří základních skupin. První si dokáží sami vyvinout software, ale
potřebují k tomu specialisty. V takovém případě je pro dodavatele jediný úkol,
a to pronajmout své vlastní zaměstnance. Cena je dána tím, jak kvalitními
specialisty dodavatel disponuje.
Druhý typ zákazníka chce vyřešit konkrétní funkce ve svém byznysu například
oddělení účetnictví a skladového hospodářství. Pro takovou firmu je nejlepší
tradiční vedení projektu, neboť interaktivní vývoj by zákazníka nejspíše
znechutil. On se totiž vývoje nechce účastnit, chce jen produkt, který si
původně chtěl koupit, ale v nabídce nic vhodného nenašel, a proto si jej nechá
vyvinout. Všechno, co vybočuje z jednoduchosti, není vítané.
Velcí klienti, kteří disponují vlastním IT oddělením a drobné věci si vyvíjejí
sami, jsou k přijetí interaktivních metod nejblíže. Mají navíc ve svém
portfoliu zaměstnance, kteří jsou zvyklí pracovat se softwarovým vývojem a jsou
schopni úkoly zadávat a výsledky vývoje testovat.
Pokud ovšem zákazník jednou přistoupí na inkrementální interaktivní vývoj (ať
už jde o agilní metodiku nebo RUP), musí se připravit na to, že se bude muset
na realizaci projektu mnohem víc účastnit. Měl by dokonce svou účast vyžadovat.
Za realizaci obdobných metodik ale získá řešení, které jeho potřebám lépe
vyhovuje a často může i ušetřit, ať už tím, že nevzniknou zbytečné požadavky,
nebo že je v průběhu vývoje upraví tak, aby mu lépe vyhovovaly. Autor je
ředitelem vývoje ve společnosti Logos.
(pal) 6 0965
Tradiční vývoj softwaru za posledních osm let dostal nový směr. Dříve totiž
byli klienti zvyklí, že dodavatel softwarového řešení přijde, poměrně dlouho s
nimi bude zkoumat jejich požadavky a na jejich základě zpracuje návrh systému.
Pak nechá schválit projekt a za pár měsíců se vrátí s hotovým systémem. V
mezidobí bude interakce se zákazníkem velmi malá, v nejhorším případě bude
třeba několik vyjasňujících workshopů. V kýženém čase pak dodavatel nainstaluje
nový systém do počítačové sítě, odevzdá ho k akceptačnímu testování a uživatelé
si ověří, že software splňuje požadavky. A řešení je hotové. Časy se ale
změnily na scénu přicházejí mnohem sofistikovanější způsoby vývoje softwaru,
jako je třeba RUP (Rational Unified Process).









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.