nav line

Specifika webové integrace z pohledu SW analýzy

SW analýza v rámci webové integrace (u webového integrátora) se dosti liší od toho, co si pod SW analýzou obvykle představíme.

Řada typických postupů a analytických výstupů zde nenalézá uplatnění. Na druhé straně se analytik musí vyrovnat s problémy a činnostmi, na které při práci na klasickém informačním systému typicky nenarazí. Tento článek je jakýmsi úvodem zamýšlené minisérie na dané téma, která bude obsahovat osobní zkušenost a názory autora na tuto problematiku.

Dnes ale ještě nebudu řešit SW analýzu z pohledu webové integrace, místo toho provedu „dělostřeleckou přípravu“ a zamyslím se nad webovou integrací z pohledu klasické SW analýzy.

Klasická SW analýza

Nejprve několik slov o tom, co mám tak na mysli, když mluvím o „klasické SW analýze“.

Vycházím z představy odvozené od metodik jako Unified Process (dále UP) apod. Podstatou práce analytika na obecné úrovni je sběr a analýza požadavků klienta a následný konceptuální návrh a především tvorba logického funkčního modelu tvořeného systému. Konkrétním výstupem je buď model v CASE nástroji, nebo (mnohem častěji) analytické dokumenty, jejichž jádrem je především use case model, popisující (na logické nikoliv technické úrovni) k čemu se systém používá, co dělá a jaké má funkce, a analytický model tříd, popisující (na logické nikoliv technické úrovni) jaké entity, informace (záměrně neříkám data) a vztahy mezi nimi systém eviduje a modeluje tak vztahy mezi věcmi a pojmy z reálného světa. Druhý bod (analytický model tříd) vyplývá především z toho, že tvořeným systémem obvykle je informační systém, jehož podstatou je právě evidence informací.

Např. návrh uživatelského rozhraní pak už není součást aktivity „analýza“, ostatně už samotné pojmenování činnosti obsahuje slovo „návrh“, takže i laikovi je jasné, do jaké aktivity to asi patří :) Nehledě na to ovšem GUI informačního systému (jaká políčka na jaké obrazovce/dialogu) typicky analytik navrhuje, protože je to pořád něco, co je třeba řešit s klientem, a „ten kdo řeší věci s klientem“ je hlavně analytik. Navíc sled obrazovek a jejich obsah přímo vyplývá z případů užití a evidovaných entit, tedy toho, co analytik primárně řeší.

Nechám teď stranou problematiku analýzy a návrhu business procesů, kterou takový SW analytik v obvyklém pojetí také dělá, přestože bychom mohli diskutovat o tom co je SW analýza, co je business analýza, kde je hranice atd.

Metodiky vývoje jako je UP a z nich odvozená představa o SW analýze jsou, řekl bych, stavěné na větší projekty, projektové týmy i větší firmy, kde je zájem či potřeba vývoj formalizovat a více distribuovat role. Větší týmy s distribuovanými rolemi vyžadují vznik více dokumentů a vůbec formálních mezivýstupů různých fází vývoje. Totéž si žádají projekty větší než jaké „dokáže udržet v hlavě“ jeden člověk.

Specifika webové integrace

A teď několik myšlenek o tom, jaké vlastnosti mají webově integrační projekty a weboví integrátoři. Právě z těchto vlastností se pak odvíjí rozdíly oproti „klasické SW analýze“, které budou popsány dále.

Malé firmy

Weboví integrátoři, jak ti, kteří se k tomu oficiálně hlásí, tak ti, kteří to jen prostě de facto dělají, se rekrutují obvykle z webových agentur, které se od „obyčejných webů“ (firemní internetová prezentace) dostali v průběhu práce pro „enterprise klienty“ ke složitějším věcem, zahrnujících netriviální funkčnost a/nebo nějakou tu integraci (najednou jde něco objednávat, implementují se netriviální procesy atd.) Nemyslím to nijak pejorativně, ale obvykle tedy jde v podstatě o „přerostlé garážovky“. To se samozřejmě promítá do jejich fungování. Dobrým i špatným způsobem.

Organizace práce

Jedním z důsledků je jistá neformálnost a flexibilita, kterou můžeme brát jako plus, ale i jako mínus. Schopnost prostě se lidsky domluvit, neohánět se procesy, ale udělat, co je třeba, jistě klienti ocení. Jak ale firma roste, přístup a postupy, které v menším měřítku fungují, fungovat přestávají. Narůstá celková míra chaosu a režie spojené se snahou ho zvládnout. Je třeba interní procesy a postupy nějak řešit, vymezit role, kontrolovat atd. Dle mé osobní zkušenosti firmy, které už vyrostly z dětských bot „běžných webů“ a stali se z nich weboví integrátoři, se právě nacházejí ve více či méně bolestném přerodu vnitřního fungování. Dosáhnout skutečného posunu organizace práce na projektech a v každodenním fungování je dlouhý, těžký a zdaleka ne ještě vyhraný boj.

Agilita

S panujícím chaosem se mnoho IT firem (zdaleka se to netýká jen webových integrátorů) ale např. i IT oddělení jejich klientů vyrovnává ať už pouze deklarovanou nebo skutečnou snahou o agilní vývoj. Bohužel s agilním vývojem je to jako s Yetim. Všichni o něm mluví, každý má představu, jak vypadá, ale kdo ho skutečně v praxi viděl/zažil? Já určitě ne, protože většina lidí zřejmě nepochopila podstatu agilních metodik, ze kterých si odnesli jen to, co se dělat nemá nebo nemusí, ale už ne to, co se místo toho dělat má a musí. Často se tedy prohlášením o agilním vývoji pouze maskuje reálná neschopnost nebo neochota dělat věci jinak než chaoticky a neřízeně a ještě se z toho dělá dobrá vlastnost. Důsledné dodržování jistých pevně daných zásad a pravidel je naopak u agilních metodik (pro někoho možná paradoxně) ještě důležitější, než u těch neagilních. Přesto vydat se tímto směrem jistě dává smysl.

Malé projekty

Webově integrační projekty jsou v zásadě poměrně malé. Jistě, jde o „velké a složité weby“, ale ve srovnání s vývojem třeba SAPu, Windows, nebo i jen takového Wordu to relativně malé projekty obvykle bývají (stovky mandays).

Malé týmy

Dělá-li malá až střední firma malé projekty, je jasné, že na nich budou pracovat malé projektové týmy, typicky do 10 lidí, přičemž ani všichni nepracují najednou. To je velikost, kdy si stále ještě mohou „všichni všechno říct“, řídit to může na nejnižší úrovni detailu jeden člověk, stejně tak může jeden člověk obsáhnout celé řešení z hlediska své role.

Typické projekty

Mezi typické projekty webové integrace patří různé portály, intranety, klientské zóny, ale i extranety sloužící pro sjednání nějaké služby, kde je nutné implementovat složitější workflow a návaznost na interní systémy poskytovatele. Specifickým případem jsou pak eshopy.

SW analýza vs. webová integrace

Kdo dočetl až sem, asi nebude překvapen, že svět webové integrace bude z pohledu SW analytika docela rozdílný od toho „klasického světa“. V čem spočívají tedy konkrétní rozdíly?

Méně formálních výstupů

Kvůli spíše neformálnímu fungování firmy směrem ke klientům i uvnitř, malým projektovým týmům i projektům a snaze o agilitu, klesá reálná potřeba tvorby nějakých analytických modelů a do jisté míry i formálních dokumentů, sloužících jako interní mezivýstupy.

Méně formální výstupy

Formální analytické dokumenty jednak vůbec nemusejí vznikat, a i když vznikají, nekladou se na ně velké nároky. Klienti ani vývojáři např. UML obvykle v podstatě neumějí, nikdo skutečně validní UML diagram od „lidového diagramu“, kde jsou nějak intuitivně použity obrázky, co CASE nástroj nabízí, nerozezná. Takže ve výsledku nemá smysl se s tím moc „piplat“, nemluvě o tom, že menší projekty mají menší rozpočet a není tak na to ani prostor.

Chybí modelování

Když už se CASE nástroj použije, tak jako kreslítko pár digramů, které se vlepí někam „do Wordu“. To je častá realita v IT firmách obecně, s modely se vlastně nepracuje. Specifikum WI je ale v tom, že by často vzniknout ani nemohly z podstaty řešené věci. Tedy, že ani „těch pár diagramů“ se vlastně nedělá a dělat dost dobře nedá. Protože prostě modelovat není moc co.

Připomeňme si dva stěžejní modely klasické analýzy – use case model, a analytický model tříd (nebo doménový model apod.). Klasický webově integrační projekt v nějakém smyslu buď propojuje existující systémy (např. implementuje nějaké workflow, které běží napříč několika systémy), nebo prezentuje data v nich evidovaná.

V rámci dodávky WI většinou nevytváříte nějaké úložiště informací, pouze informace z nějakých úložišť taháte a zobrazujete v nějakém webovém rozhraní. Nevytváříte evidenci dat, tedy nepotřebujete modelovat, jaká data jak evidovat budete, a tedy analytický model tříd neděláte.

Právě jsem tedy škrtnul tak třetinu obvyklé analytické práce.

A co ty případy užití (use case model)? V podstatě je v řadě (a možná většině) případů škrtnout můžu také. Je to tady méně jednoznačné, protože „nějaká funkčnost“ se přeci jen v rámci webové integrace samozřejmě řeší, ale mám pro to následující argumenty.

To, co si představím pod pojmem business logika je z většiny implementována v jiných systémech, těch systémech, nad kterými se vytváří nová prezentační vrstva ať už směrem do firmy, nebo ven. Právě tato prezentační vrstva je podstatou webově integračního projektu. Tato prezentační vrstva tvořená celou jednou aplikací/systémem má sice svoji vlastní „aplikační logiku“, jádro této „aplikační logiky“ ale často leží jinde, než v implementaci business logiky a v tom, co přirozeně popíšete v rámci scénářů případů užití. Naopak je to z velké části o tom, kde se v jaké formě zobrazí jaká data a kde se ta data vezmou, a pak hlavně o detailech fungování GUI, které v případech užití nepopíšete a především byste vůbec popisovat neměli. V té obecné rovině, na GUI nezávislé, ve které by se popis případů užití měl držet, je často poměrně jasné, co se má dít, většina toho, „co je třeba řešit“, je na nižší úrovni abstrakce.

Větší důraz na návrh GUI

Už jsem se o tu myšlenku otřel v předchozím odstavci. Při tvorbě webů (i těch složitých, které přece jen „něco dělají“ a nezobrazují jen nějaký informační obsah) to není ani tak o tom, co systém dělá, nebo co se systémem dělá uživatel, tato oblast nebývá zdaleka tak rozsáhlá jako u „opravdových“ SW systémů. Je to spíš o tom jak přesně se mu něco zobrazuje a jak přesně s tím pracuje. Při návrhu IS nejspíš navrhnete formuláře tak, že použijete standartní komponenty GUI, které nabízí vaše vývojové prostředí, poskládáte je logicky k sobě a aplikujete nějaké obecné standardy a zvyklosti. V zásadě čím víc to bude stejné jako to, co už uživatel zná, čím víc to bude „normální“, tím líp. Při tvorbě webu jsou jednak mnohem větší možnosti, jednak i větší očekávání. Všichni vědí, že webové stránky vypadají a ovládají se jinak než klasická Windows aplikace. Součást zadání (ať už explicitně, či implicitně) bývá také jistá originalita. Zkrátka GUI a UX řešíte mnohem více, než u klasického IS. Netvrdím, že by se to tam dělat nemohlo, nebo nemělo, ale jen to, že se to obvykle v takovém rozsahu nedělá a nepředstavuje to tak velký podíl na celkové práci.

Větší důraz na integraci

Málokterý IS dnes funguje osamoceně, na druhou stranu poměr toho, „co dělá sám“ oproti objemu interakce s jinými systémy je menší, než u WI řešení, které často představuje jen výše zmíněnou prezentační vrstvu nad core systémy klienta, implementujícími celou datovou vrstvu a většinu business logiky.

Marketing místo procesů

Podstata řady WI projektů je jinde, než u IS. IS je nástroj implementující interní firemní procesy. Samozřejmě existují WI projekty zaměřené stejně, např. firemní intranet, který do jednoho procesu bude spojovat několik dílčích, které probíhají v oddělených systémech. Mnoho WI projektů je ale o něčem jiném, o marketingu. Všechny extranety, eshopy apod. se primárně snaží něco prodat. Být odborníkem na oline prodejní kanály, průzkumníkem posledních technických novinek v oblasti mobilních zařízení a trendů jejich využití k tomu či onomu, to vše je něco dost jiného, než „kreslení oválů a krabiček“ v CASE nástroji.

Posun k systémové analýze a návrhu

Jsme tedy ve stavu, kdy

  • analytik nevytváří moc formálních dokumentů,
  • analytik nevytváří abstraktní modely systémů,
  • to „co“ má vzniknout v obecnější rovině je často úkol (také) pro někoho jiného, než (jen) SW analytika,
  • GUI a s tím i většinu aplikační logiky WI řešení navrhuje UX specialista (nezapomeňme, že business logika už je v jiných systémech, takže „aplikační logika“ WI projektu je leckdy skoro jen o chování prezentační vrstvy),
  • významnou část WI projektu představuje integrace na jiné systémy.

Z toho všeho plyne posunutí těžiště práce analytika od té klasické SW analýzy k něčemu, pro co použiju označení systémová analýza. SW analytik se vzdaluje businessu, který je v případě WI projektů často méně o procesech (úkol pro analytika) a více o marketingu (úkol pro jinou roli). Je zde posun do více technické úrovně, analytik méně zkoumá/navrhuje systém z pohledu uživatele, více ho zkoumá z pohledu jiných systémů a jejich napojení. Nechme stranou situaci, kdy to sklouzne přímo k návrhu. Ostatně rozlišit „systémovou analýzu“ od „systémového návrhu“ není jednoduché a při řešení praktických problémů se to strašně prolíná. I pokud ale zůstanete v rámci systémové analýzy pořád na logické úrovni, bude to jiná práce než sběr a analýza (uživatelských) požadavků. Bavíte se s jiným typem lidí o jiných věcech jiným způsobem.

Posun k testování

K roli SW analytika by obecně měla patřit validace výstupů projektu, tedy posouzení z určitého nadhledu, zda vzniklo to, co mělo. Jakákoliv specifikace není nikdy úplná ani zcela jednoznačná. Vždy existuje mnoho způsobů, jak vyrobit něco, co s ní není v rozporu, a přitom to není to, co by klient asi chtěl. Samotnou verifikaci, tj. porovnání výsledku se specifikací, zajišťuje ideálně testovací tým (kromě jiného).

Nechme teď stranou, že zrovna Lundegaard (můj stávající zaměstnavatel) se snaží konkrétně v této oblasti o jiné fungování, ale obecně si troufám říct, že v malé firmě na malém projektu v týmu pár lidí často extra tester chybí, a i když nechybí, ke skutečnému testování nedochází (příprava testovacích plánů, testovacích scénářů, důsledná práce s nějakým bug reportovacím nástrojem…). Tester je jen určená osoba „co to pak prokliká“ o něco víc než vývojář. V této situaci často nezbývá, než aby si soulad se specifikací analytik ohlídal sám. Díky poměrně malým projektům to ale nebývá problém, naopak je to efektivní. I pro samotného analytika je nakonec často jednodušší to vůči své specifikaci (obzvlášť, když jí má v hlavě, a to i s detaily, které na papíře nejsou) porovnat sám, než vysvětlovat testerovi, co že to má přesně vyzkoušet, jak a s jakým výsledkem. Obzvlášť když o daném projektu tester vlastně nic neví, jen za ním někdo chvíli před odevzdáním přišel, „ať to teda otestuje“. Skutečné testování, tj. takové, které zahrnuje opravdové zapojení opravdového testera do projektu dostatečně brzo, 30% podíl testingu na rozpočtu (který ale nefunguje jen jako hezčí název rezervy pro implementaci v projektovém plánu!) a další rysy, klient obvykle stejně nezaplatí.

Závěr

V tomto článku jsem se pokusil nastínit zvláštnosti prostředí, ve kterém pracuje SW analytik na WI projektech. V dalších článcích pak plánuji tyto úvahy dále rozvíjet a zaměřím se na to, jak v takovém prostředí analytik může fungovat a jak by dle mého názoru fungovat měl. Zatímco dnes to tedy v rámci srovnání s postupy/výstupy klasické analýzy bylo dost o tom, co se na WI projektu nedělá a dělat nedá (nebo dá, ale nemá to podle mně valný smysl), příště už se pustím do toho, co se v rámci té pro mnohé těžko uchopitelné činnosti zvané SW analýza na WI projektech podle mě dělat dá a má.

Ohodnoťte článek

Specifika webové integrace z pohledu SW analýzy

Související články

Vyhledávání na blogu

Webová integrace

Webová integrace jako nová oblast pro business „velkých" webových agentur.

o webové integraci

Profily blogujících