Simulační nástroje: Nejprve vizualizace, vývoj až později (1.)

Vizualizační nástroje mohou ukázat podobu a chování aplikace ještě před jejím vytvořením. To eliminuje případné chyby v návrhu hned na začátku vývoje – a tak ho výrazně zrychlí.


Firemní analytici se mohou před předáním projektu do vývoje ujistit, že správně pochopili požadavky uživatelů. Existuje totiž nástroj, který umožňuje podnikům simulovat a vytvářet obrazy vzhledu softwarových aplikací ještě před zahájením skutečného vývoje. Nejedná se však o žádné funkční prototypy – namísto toho se tyto modely chovají jako aplikace s dokončeným vzhledem a způsobem ovládání, ale bez konkrétního kódu v pozadí.

Když byla Jan Scheetzová požádána o svůj seznam přání, co by chtěla od elektronického lékařského objednacího systému pro pacienty léčebny, nezdráhala se je vyjmenovat. Podle Scheetzové by ideální systém generoval platný elektronický podpis lékaře, který je nutný ke zpracování požadavků pojišťoven a systému zdravotního pojištění, ale je ho často problematické získat.

„Je to něco, o čem jsme dlouho snili,“ uvádí Scheetzová, ambulantní vedoucí v centru MD Anderson Cancer v Houstonu. „Nyní poskytujeme konzultace on-line a výsledkem jsou nepodepsané objednávky,“ takže je k dokončení nutná značná ruční práce. Nový proces však umožní personálu nemocnice doplnit on-line konzultaci platnou podepsanou objednávkou vytvořenou lékařem.

Nejlepší ze všeho však je, že Scheetzová a její kolegové mohli ještě před vytvořením systému vidět, jak by vypadal. Nemocnice totiž použila softwarový nástroj nazývaný iRise, který umožňuje simulovat vzhled softwarových aplikací.

Scheetzová a ostatní v jejím oddělení spolupracovali s firemními analytiky centra MD Anderson. Společně používali zmíněný produkt k vytvoření představy, co by chtěli v objednávkovém lékařském systému mít, a poté, o teprve několik měsíců později, si Scheetzová a její kolegové mohli prohlédnout první verzi programu.

Požadavky jsou důležité
„Problém není nový – je to sdělení vlastních požadavků softwarovým vývojářům,“ poznamenává Melinda-Carol Ballouová, analytička společnosti IDC.

„Se stále vzácnějšími zdroji není prostor na chyby. Pokud nedojde k souladu mezi výtvorem poskytovatele a skutečnou potřebou podnikání, jsou při současné ekonomické situaci finanční následky chyby mnohem větší,“ vysvětluje Ballouová a dodává, že to je příčinou, proč nyní vznikají produkty, které tento problém řeší.

„Při vizualizaci požadavků a jejich kontrole na obrazovce mají uživatelé něco konkrétního,“ takže mohou vidět „realizaci svých námětů“, dodává.

Existuje velká potřeba lepší komunikace mezi zainteresovanými osobami zákazníka a vývojáři.  Výzkumná firma The Standish Group tvrdí, že v letech 2006 až 2008 došlo ke snížení úspěšnosti softwarových projektů. (Skupina Standish provádí své výzkumné studie každé dva roky, přičemž posledním rokem s dostupnými údaji je 2008.) Výsledky nové studie budou k dispozici počátkem příštího roku.

V roce 2008 bylo úspěšných jen 32 % všech projektů, to znamená, že byly dodány včas a podle rozpočtu s požadovanými vlastnostmi a funkcemi, uvádí Standish. Ve srovnání s tím podle výzkumu této společnosti z roku 2006 bylo úspěšných 35 % projektů.

Dále bylo v roce 2008 celkem 44 % projektů zpožděných, mělo navýšený rozpočet nebo postrádalo požadované vlastnosti a funkce. Zbytek tvoří 24 % neúspěšných projektů, které byly zrušeny ještě před dokončením a vlastně nikdy nebyly použity, tvrdí Standish. V roce 2006 bylo takto neúspěšných řešení jen 19 %.

„Vývojářské prostředí se nedávno stalo tak problematickým, protože ekonomika nutila lidi přehodnotit realizované projekty,“ vysvětluje Jim Johnson, ředitel skupiny Standish Group. Některé projekty byly například zahájeny a poté zrušeny, protože bylo zjištěno, že nejsou v souladu s korporátními cíli. „Navíc se domnívám, že došlo k přehnání implementace vládních nařízení a směrnic v projektech, které se staly tak komplikované, že je nebylo možné splnit,“ dodává Johnson. „Tato oblast tedy není vyvážená.“

Tradičně zabere vývoj softwarové aplikace pro betatestování řádově měsíce, a to i s novějšími agilními vývojovými metodami. Vizualizace aplikace však zabere jen hodiny a uživatelé se mohou podívat, jak bude systém vypadat a jak bude pracovat. Umožňuje to také časné zjištění, zda vývojář správně pochopil požadavky uživatelů.

„IT oddělení si velmi jasně uvědomují, že vývoj softwaru musí lépe zvládat,“ prohlašuje Tom Grant, analytik agentury Forrester Research. „Zvyšuje se povědomí, že do této problematiky stojí za to investovat, protože lidé ztrácejí spousty času opakovaným návrhem,“ dodává Grant. „Nástroje k vyřešení této situace však zatím nejsou příliš rozšířeny – nejsou dostupné a těch několik, co na trhu jsou, prostě není využíváno,“ upozorňuje Grant.

Jak Ballouová, tak Grant tvrdí, že vizualizační nástroje jsou jen část širšího trhu nástrojů definujících požadavky. „Trh nástrojů pro definici požadavků začal být jako celek přijímán celkem pozdě,“ poznamenává Grant. Největším problémem dodavatelů jsou kulturní překážky při pokusech odklonit firmy od používání aplikací jako tabulkové kalkulátory nebo PowerPoint a přimět uživatele sdělovat své potřeby. Oba analytici také tvrdí, že je obtížné přesně zjistit velikost trhu nástrojů pro vizualizaci aplikací, protože je v současnosti ve stadiu změn a nástroje pro definici požadavků se pokoušejí řešit mnoho různých problémů.

Trh se softwarem pro správu a definici požadavků zaznamenal v roce 2008 nárůst obratu o 207 milionu dolarů, což je 7 % více než v předchozím roce. Ballouová předpovídá, že ve světle současného finančního klimatu bude tento trh narůstat až na 290,6 milionu dolarů v roce 2013.

„Vzrůstající složitost a důležitost softwarových aplikací a systémů a neustávající obchodní tlak na relevanci a přizpůsobitelnost aplikací, stejně jako na kontrolovatelnost jejich shody s legislativou a rychlejší uvádění na trh, budou nadále posilovat potřebu řešení interaktivních definic požadavků,“ napsala ve zprávě analyzující zmíněný trh.

Hlavním úkolem pro firmu iRise je podle Ballouové zajištění, aby její software dokázal spravovat a opakovaně používat pro podobné projekty všechny artefakty vytvořené během opakovaných společných sezení nad návrhem porovnatelných aplikací. Uvedla však, že očekává vyřešení tohoto problému až v příštích verzích aplikace.

Dokončení článku vám přineseme zítra…











Komentáře