Blog

Základy UML – diagram případů užití (use case diagram)

Diagram tzv. případů užití (v angličtině USE CASE diagram) znázorňuje vztah aktorů k jednotlivým aktivitám prováděným v konkrétních aplikacích.

Pomocí diagramu zjistíme, který aktor, znázorněný v diagramu figurkou (zákazník, obsluha IT systému, manažer…) provádí jakou činnost (=případ užití), a jaký další případ užití ji rozšiřuje (extend), nebo je v základním případu užití obsažen (include).

Diagram je velmi vhodný pro situace, kdy se vyjasňují základní funkce navrhovaného řešení (my budeme vždy psát o vývoji software). V diagramu je zcela jasně vidět, kdo dělá co.

Ze samotného UML diagramu nicméně není zcela zřetelný postup aktivit aktora a systému –  to je vhodné (nebo spíše nutné) popsat textovou formou. A právě o psaní případů užití připravuji poměrně detailní článek, který zde bude brzy zveřejněn :)

Nástroje pro kreslení UML diagramů, které jsou zadarmo

Ne vždy je nutné pro tvorbu UML diagramů používat nejdražší profesionální nástroje typu Enterprise Architect nebo Magic Draw. V následujícím minipříspěvku nabízím seznam jednoduchých editorů, které jsou skoro, nebo úplně zdarma.

ArgoUML
http://argouml.tigris.org/

UmbrelloUML
http://uml.sourceforge.net/

Violet UML Editor
http://alexdp.free.fr/violetumleditor/page.php

Star UML
http://sourceforge.net/projects/staruml/

Kam nám zmizel business vlastník…?

Často se nemůžu zbavit dojmu, že jsou velké IT projekty řízeny tak nějak všemi a zároveň nikým.

Z poslední doby mám zkušenost, že na počátku projektu ve velké společnosti skupina několika manažerů a specialistů vyžaduje určitou funkci nebo skupinu nových funkcí. Postupnou analýzou se přijde k tomu, že stojí za to vytvořit samostatný projekt. Projektový manažer nelení, vytvoří projekt, a tak nějak potichu počítá s tím, že zadavatelem projektu budou titíž lidé, kteří stáli na počátku celého příběhu. Projekt začne svou první fázi, projektový manažer projekt odstartuje a začne se pracovat na analýze. Vzniká už relativně konkrétní dokumentace. Čas běží, původní zadavatelé mají ale postupně málo času a motivace a jak projekt začíná nabývat pevné obrysy, nadšení pro nové funkce začíná jaksi odpadat. Najednou se projektový manažer dozvídá, že zadavatelé změn nemají čas tu na projektovou schůzku, jindy zase na schvalování hotových analýz, a projekt se začíná ještě před svým startem dostávat do slepé uličky….

A co z toho plyne? Prací analytika je zpravidla především získat požadavky a zpracovat dokumentaci. Protože jsou ale projektoví manažeři zpravidla přetížení … stojí za to občas vyřknout základní otázku, se kterou si PM na počátku možná hlavu příliš nelámal – pro koho je vlastně ten projekt?

Druhé poučení je snad jen takové, že ne vše, co analytik zjistí a třeba sebedetailněji zdokumentuje, se musí dostat byť jen do první fáze / sprintu u programátorů. Je to blbá, avšak ne tak zcela vyjímečná situace.

Mockupy, WireFramy, Prototypy…

Jistě jste to už někde zaslechli. „Viděli jste už ty vajrfrejmy?“, „ty dráty tentokrát vůbec nevypadají špatně“, a podobně.

Tušíte o čem je řeč?

Dotyční zpravidla hovořili o tzv. Wireframech, Mockupech nebo o „klikacích“ prototypech. Podívejme se poněkud detailněji na to, o co vlastně jde.

Wireframy (čteme „vajr-frejm“; česky drátový model, …)

Wireframy jsou obrázky, které zpravidla vytváří analytici, UX konzultanti nebo informační architekti, za účelem zobrazení všech prvků na webové stránce nebo v aplikaci. Cílem je vizualizovat grafické rozhraní stránek a aplikací a umožnit tak nejen návrhářům, ale i zákazníkovi doladit a zpřesnit své představy o aplikaci ještě před tím, než se začne vyvíjet.

Co je psáno, to je dáno, říká se. Nicméně je známým faktem, že lidské bytosti vnímají valnou většinu informací prostřednictvím zraku – vytvořením wireframů, nákresů obsahujících lze porovnat naše představy s představami zákazníka nesrovnatelně rychleji než když mu dodáme například pouze textovou, byť sebedetailnější analýzu.

Wireframy obsahují zejména tyto informace:

  • Druh informací, který bude zobrazen
  • Rozsah funkcí, formulářů a dalších prvků grafického rozhraní (GUI)
  • Představu o prioritách jednotlivých prvků – informací, ovládacích prvků apod.
  • Pravidla pro zobrazování určitých typů informací
  • Různé varianty chování GUI, např. zobrazení negativních scénářů, reakcí formulářů na chyby, apod.

Zpravidla se vytváří jednoduché nákresy, tzv. Mock-upy. Tyto tzv. low-fidelity wireframy obsahují méně detailů, jsou graficky výrazně méně podobné finální grafické úpravě, mají ale zásadní výhodu – jejich výroba je velmi rychlá a efektivní. Jsou ideální na menší projekty, GUI s menším počtem ovládacích prvků, a nepochybně také s více informovanými zadavateli – není nic příjemného, když se zadavatel změny na webu nebo v aplikaci popáté ptá, jaktože to má jiné barvy a proč to vůbec nevypadá jako stávající aplikace. Inu, protože to tak úplně vypadat nemá – wireframy jsou určeny hlavně pro ujasnění chování aplikace, a rozložení jednotlivách prvků. Design neřeší… tedy…

… pokud nejde ovšem o high-fidelity wireframy :-) Ty se zpravidla vytváří ve finále, kdy už jsou funkce a chování aplikace nakreslené v rychlejších mock-upech. Na menších prijektech se často ani nevytváří, v případě větších aplikací je ale vhodné je mít. Obsahují totiž již všechny zásadní prvky stránek, i řadu detailů, a obrázky se již začínají podobat finálnímu designu aplikace. Jejich tvorba je nicméně náročnější, jak časově, tak také finančně.

Nástrojů pro tvorbu wireframů je mnoho, budu se jimi proto detailněji zabývat v dalším postu.

A abych nezapoměl na jednu zásadní věc – na wireframy někdy není vlastně často potřeba ani žádný software, ani žádný počítač… je možné je samozřejmě dělat i obyčejnou tužkou na kus papíru :-)

Prototypy

Výroba klikacího prototypu je někdy vhodná pro definitivní odladění a také otestování „chování“ zejména u rozsáhlejší aplikace, před tím, než fakticky začne vznikat.

Nejde o nic jiného, než sadu webových stránek, mezi sebou provázaných jak odkazy, tak například prostřednictvím formulářů (zadání dat ve formuláři a kliknutí na odesílací tlačítko přesměruje testera na jinou statickou stránku).

Výroba klikacího prototypu se vyplatí zejména v těchto případech:

  • projekt je rozsáhlejší a je těžké si představit jeho rozsah jen za použití promítaných nebo vytištěných obrázků
  • cílem aplikace je umožnit klientovi získat požadované funkce nebo informace co nejrychleji – pak prototyp poslouží pro testování použitelnosti
  • aplikace bude sloužit pro vícekrokové objednávky, je třeba odladit ecommerce proces

Klikací prototypy například poměrně bezbolestně ovládá program Axure RP, známý to nástroj mnoha analytiků a informačních architektů.

Co je UML a k čemu je dobré?

Dnešní post bude takový nějaký zrychlený, nějak nestíhám se s tím moc babrat:-)

Se zkratkou UML se setkává řada profíků i začátečníků v IT oboru, netýká se jen analytiků – ti jej pouze používají k popisu procesů a systémů. Dále s ním pak zpravidla pracují tech leadi, programátoři, a podle potřeby například testeři.

UML je zkratkou anglických slovíček Unified Modeling Language. Jde o grafický jazyk pro softwarové inženýrství, slouží k modelování objektů, tříd, pípadů použití, komunikace s interfacy, a podobně.

Díky UML může analytik velmi jednoduše, a pokud dodrží všechna základní pravidla, tak i velmi srozumitelně popsat všechny základní vlastnosti systému.

O UML se dočtete nejvíce zde na těchto webových stránkách:

Knihy o UML jsou v češtině ideální tyto:

  • Destilované UML, Fowler Martin, ISBN:9788024720623
  • UML srozumitelně, Hana Kanisová, Miroslav Mul, ISBN: 8025110834
  • UML 2 a unifikovaný proces vývoje, ISBN: 9788025115039


3 top nástroje pro analýzu webových stránek a aplikací

Koho by nezajímalo, co se děje na jím vyvinutých nebo provozovaných webových stránkách a aplikacích. Analytické nástroje, které vám představím, zvládnou nejen grafické zobrazení míst, na která uživatelé nejvíce klikají, ale dovedou provádět analýzy formulářů (například objednávek nebo registrací) a dokonce i zobrazit pohyby kurzoru jednotlivých návštěvníků.

Analytických nástrojů je samozřejmě více, tyto jsem vybral čistě subjektivně proto, že se mi s nimi pracovalo vždy nejlépe. A u ClickTale ani o žádném srovnatelném konkurentovi  nevím ;-)

1. Heat-mapy MYX – www.myx.cz

Protože jsem patriot, nemůžu jako první uvést nic jiného, než heatmapy od firmy SiteOne – mYx. Jde o onlinovou aplikaci, jejíž výstupem jsou inteligentní „teplotní“ mapy, zobrazující intenzitu klikání na jednotlivé prvky a místa webů (stránky, formuláře, atd.). Aplikace umožňuje data filtrovat, umožňuje volit průhlednost i barevnost heatmapy, a lze ji napojit na další analytický nástroj Google Analytics.

mYx sleduji několik roků, neustále se vyvíjí a v SiteOne rozhodně nespí na vavřínech – vřele doporučuji.

2. ClickTale – www.clicktale.com

Zatímco Google Analytics poskytne cenné informace o konverzích, o toku uživatelů a zdrojích návštěvnosti, izraelský ClickTale poskytne něco zcela bezkonkurenčního. Pomocí aplikace „Visitor Recordings“ je možné přehrávat jednotlivé přístupy tak, jako byste koukali uživateli pod prsty – vidíte zde, jak hýbe myší, na co kliká, jak dlouho čeká, i když si třeba při čtení popojíždí kurzorem u textu :-) Pro uživatelské testování v ostrém provozu (ale nejen!) geniální nástroj.

ClickTale bych doporučil zejména těm, kdo mají na stránkách jakékoli formuláře – složitější registrační aplikace, eshopy, apod. Jedna z dalších funkcí ClickTale je „Form Analytics„, která obsahuje následující funkce: Conversion Report pro zobrazení konverzního poměru formuláře, Drop Report, který ukáže, jaký element stránky byl ten poslední, kterým se uživatel zabýval, dále pak Time Report – ten nabídne detailní informace opět o jednotlivých položkách formuláře (je velmi zajímavé se dozvědět, že vám 50% potencionálních zákazníků odchází právě jen kvůli problémům s jedním kombo-boxem); Blank Field Report odhalí, která pole uživatelé ignorují a nevyplňují, a konečně Refill Report – zde zjistíte, která pole uživatel po neúspěšném odeslání nejčastěji opravovali (tedy asi jste je nedostatečně informovali, co že mají vyplnit, nebo vám fungují divně validace).

3. Google Analytics – www.google.com/analytics

Kdo by neznal Google Analytics. S novým rozhraním a provázáním služby s Google Webmaster Tools nabral tento, již tak nejpoužívanější systém pro analýzu webů nový dech. Google Analytics, často zkráceně označované jako GA, použávám prakticky na každém webu, který jsem vytvořil. Oč je GA slabší při analýze front-endu oproti dvou předešlým nástrojům, o to je nesrovnatelně silnější při analýzách samotných uživatelů, jejich operačních systémů, dále pak zejména zdrojů návštěvníků a klíčových slov, nebo PPC kampaní, a tak dále. Je to velmi vyspělý nástroj, který oproti dvěma předešlým je zcela zdarma.

Jaká je pracovní náplň business analytika?

Každý, kdo uvažuje o práci business analytika, se při zvažování nové práce sám sebe zeptá, co že to vlastně dělá ten business analytik. Letmým pohledem do inzerátů na Internetu je možné celkem jasně zjistit, že je potřeba být komunikativní, ovládat UML, nějaké ty CASE nástroje, že se to asi bude týkat psaní dokumentace, a …. a dál je to pokaždé jiné, tak nějak v mlze – a je těžké přesně odhadnout, co po vás tedy vlastně budou chtít. Jako by vlastně nešlo přesně napsat, co onou náplní ve finále bude.

Z vlastní zkušenosti mohu potvrdit, že je to opravdu tak :-)

Rozsah práce business analytika je velmi široký, práce je poměrně náročná na mozkovou kapacitu a nároky na znalosti nejsou nejmenší, je ale velmi zajímavá – a dává možnost být u vzniku software prakticky od píky.

Ideální je, pokud je ve firmě pozice business analytika pevně zakotvená ve vývojovém teamu – pak se podílí prakticky na všech fázích vývoje:

Ve počáteční – iniciační – fázi analytik pomáhá identifikovat, v čem je problém. Zjišťuje, co organizaci, pro kterou pracuje, pálí. Z toho vychází návrhy na možná řešení. V této fázi je byznys analytik při ruce konzultantovi či projektovému manažerovi (případně oběma) a aktivně pomáhá s tvorbou nabídky. PM zpravidla požaduje odhady na analýzu (buď v hodinách, častěji ale v MD – Man-days, česky člověkodnech).

Klient vybere jednu z nabízených variant, nebo nevybere žádnou (buď více řešení problému není, nebo jsme zbabrali nabídku), případně jím preferovanou variantu třeba ještě upraví. Projektoví manažeři si s úsměvem vymění informace o zcela jistě zvládnutelných termínech na analýzu a vývoj, a pro analytika začíná boj. Boj s časem, vlastníky různých systémů, s často ne zcela srozumitelnou nebo nekompletní stávající dokumentací, a někdy i se sebou samotným.

Fáze analýzy je zcela klíčovou fází, ve které analytik sbírá detailní informace jednak o požadavcích klienta na nový systém, resp. na požadované úpravy toho stávajícího, a zároveň se snaží získat maximum informací o systémech, se kterými bude třeba komunikovat, získávat z nich data, nebo do nich data dodávat.

Výstupy analytika obsahují prakticky vždy tzv Requirement Specification Document – specifikaci požadavků na systém. K čemu slouží? Předně, obsahuje všechny požadavky klienta na systém – definuje rozsah projektu (často se používá anglický výraz „scope“). To, co je zde popsáno, musí být uděláno, aby byl projekt z pohledu klienta hotov. V praxi se toho ale musí udělat daleko více – design obrazovek, jejich posloupnost jsou zpravidla popsány v dalším dokumentu, často se také vytváří tzv. případy užití (USE CASES), analytik se také málokdy vyhne popisu komunikace s jinými systémy – Interface specification je tak dalším z dokumentů, do nichž analytik vloží v průběhu prací svou duši.

Když je hotovo, je třeba specifikaci schválit. Procesy se různí, někteří klienti mají kvalitní lidské zdroje, a  specifikaci velmi podrobně pročtou a připomínkují. Tyto postupy a procesy si zpravidla nastavují projektoví manažeři a měly by být upraveny také ve smlouvě. Po schválení dokumentace j čas na vývoj…

… a ve vývojové fázi si analytik také moc neodpočine. Ve chvíli, kdy se specifikace zmocní vývojáři, je analytikova dokumentace podrobena další zatěžkávací zkoušce. Vývojáři se na „jejich“ BA obracejí buď sami, nebo jsou nastaveny pravidelné (ideálně s velmi malou periodou) konzultační schůzky. Pro každý projekt se hodí jiná intenzita komunikace, každopádně jí ale prakticky vždy je dostatek. Analytik rozhodně jen nedoplňuje dokumentaci o to, co mu „vypadlo“ při její tvorbě – někdy je třeba svolávat další analytické schůzky, analytik je de facto koordinuje ve snaze získat informace od všech zúčastněných stran, a upravuje svou dokumentaci. Pokud jsou na schůzkách sjednány změny zadání, analytik je zpracovává do dokumentace.

Vývojáři po čase s hrdostí v hlase oznámí, že je aplikace připravená k testu. Testování je momentem, kdy si konečně analytik může trochu oddechnout. Na základě jeho dokumentací a specifikací jsou buď testerem, nebo test analytikem vytvářeny testovací scénáře, a podle nich se poté aplikace testuje. Podle počtu členů vývojového teamu může testovací scénáře také někdy zpracovávat analytik. Také někdy může testovat – a to se také poměrně často děje.

Následné testování u klienta je následně opět momentem, kdy čeká na analytika výrazně více komunikace – klient přebral software k testu a jeho testeři (ať to jsou testeři najatí jen za účelem nalezení chyb v novém software, nebo jiní zástupci klienta) nacházejí chyby. A také „chyby“ – velmi často se totiž stává, že i když byly sepsány stovky stran dokumentace, až po naprogramování se zjistí, že některé funkcionality byly myšleny, ehm… trochu jinak. Na analytika se valí dotazy, proč která či oná část aplikace má takovou a takovou funkci, a také se na něj s žádostí o rozhřešení obrací projektoví manažeři. Jejich cílem je za každou změnu, která nebyla požadována a schválena ve specifikaci, dostat zaplaceno. Bezbožným přáním řady klientů je naopak neplatit za další úpravy nic. Analytik tak musí bránit sebe, své specifikace, potažmo svého zaměstnavatele. V tomto minovém poli pak musí s bezchybným poker-face argumentovat, vyjednávat, analyzovat, a nacházet řešení…

Jednoho dne je pak aplikace hotová, u zákazníka se vymění management, nebo ten stávající prudce trhne kormidlem, a je třeba provést řadu změn v informačních systémech a aplikacích. A kolotoč se roztáčí znovu… :)

A ještě malé doplnění – pro lepší představu, jak vše v IT projektech probíhá :-)

user-reqs

Začínáme

Analytik.cz startuje. Na českém netu mi dlouho chyběl zdroj informací pro business analytiky. Pokusím se tedy mezeru zaplnit – budu rád, když se na tvorbě budete podílet i Vy – svými komentáři, kritikou, a občas, pokud si to zasloužím, i chválou :)