Analytické výstupy nemají dostatečnou kvalitu. Analytici nerozumí businessu a pořádně neznají ani stávající funkcionalitu. Analýza je příliš povrchní, nepromyšlená a chybí v ní spousta věcí, které se zjišťují až ve fázi testování. Vývojáři a testeři jsou nespokojeni. Projekt nabírá zpoždění. Máme tady problém. Co s tím?
Několikrát jsem se s tímto problémem setkal na různých projektech. A jaké bylo řešení ze strany vedení projektu?
Častým řešením je nápad na vytvoření analytické šablony - dokumentu se seznamem kapitol, ukázkou a návodem, jak tyto kapitoly správně vyplnit. Vedení projektu obvykle očekává, že taková šablona zajistí jednotný výstup od všech analytiků. Také si myslí, že díky předpřipraveným kapitolám bude analýza kompletní. Návod pak zajistí, že všichni budou mít jasnou představu, co do jednotlivých kapitol vyplnit. Šablonu lze navíc vytvořit velice rychle v rámci několika dnů.
Jaká je realita? Pomůže to ve zlepšení kvality analýzy? Bohužel, analytická šablona může být užitečnou pomůckou, ale kvalitu analýzy nezachrání. Analytik, který nedodává (ať už z jakéhokoliv důvodu) kvalitní výstup, bude velmi pravděpodobně vyplňovat ve stejné kvalitě i dodanou šablonu. Jeho výstup tedy bude stejný, jen bude doplněný do šablony. Šablona tedy není řešením.
Co tedy s tím? Analyzujte příčiny, proč analýza nemá dostatečnou kvalitu. Změřte se na nejprve problémy. Začněte tím, že si vezmete stávající analýzu, ideálně pokud je analyzovaná funkcionalita již dodaná. Zaměřte se na části, kde došlo k problémům tj. nepochopení ze strany vývojáře, nebo daná část nebyla kompletní, případně popis neodpovídal původnímu požadavku. Pak zkuste přijít na to, proč k tomu došlo. Jakmile máte příčinu, je relativně snadné nalézt řešení.
Chcete vědět jaký programovací jazyk je/byl nejvíce rozšířený?
Podívejte se na následující video znázorňující nejpopulárnější programovací jazyky od roku 1965:
https://www.youtube.com/watch?v=Og847HVwRSI
Dlouho vedl Fortran, pak ho předstihl Pascal. Následně poměrně dlouhou dobu vedl jazyk C s poměrně vysokým podílem nad 60%. Zajímavé to začíná být kolem roku 1995, kdy se objevuje Java a Javascript. V roce 2001 už Java vede a v žebříčku se objevuje Python. Python se pak v roce 2014 dostává na 3. místo za Javu a Javascript. Toto pořadí vydrží až do roku 2018, kdy se Python dostává na první místo. Na druhém místě je JavaScript. Na třetím Java. S velkým odstupem je na čtvrtém místě C#.
Nedávno jsem se účastnil zajímavé diskuse o tom, co je a není předmětem činnosti analytika, respektive do jaké hloubky a šířky má analýza jít a co je jejím smyslem.
Začneme od toho nejdůležitějšího, tedy jaký je smysl analýzy. Smyslem analýzy je umožnit vývoj softwarového systému a to přípravou jednoznačného zadání, které je jasně formulované, kompletní a akceptované zainteresovanými stranami. Je důležité si uvědomit, že analýza není dokumentace. Smyslem není popsat jak má zákazník systém používat, udržovat nebo nastavovat, ale zachytit primárně požadavky na systém a přispět k jejich vyřešení.
Šířka může být různá. Analytik může fungovat jako business analytik s větší šíří, která zahrnuje nejen softwarové systémy (zpravidla více softwarových systémů napříč organizací), ale i řešení v rámci nastavení nebo úpravy procesů, návrh změn ve fungování organizace a změn businessu jako celku. Nebo může analytik fungovat jako IT analytik, který je zpravidla zaměřen na řešení požadavků v rámci jednoho konkrétního systému.
Většinou platí, že čím větší je šířka záběru analytika, tím méně jde do hloubky. Hloubkou myslím podrobnost specifikace požadavku od high-level business požadavku k podrobné technické specifikaci úprav v databázi, na rozhraní a v kódu.
Kam až by měl analytik jít? Je specifikace API práce analytika nebo je to věc, kterou by měl nechat na vývojáře? Tady závisí na složení týmu a na schopnostech daného analytika. Upozorňuji, že analytik je role na projektu. Každý člověk na projektu (nebo při agilním vývoji) může mít více rolí. Smysl třeba dává, že jeden člověk specifikuje požadavek v roli analytika, ten samý člověk ho posléze otestuje v roli testera a seznámí s ním na školení budoucí uživatele v roli školitele a jako dokumentarista ho zapracuje do dokumentace systému. Nastavení je v různých organizacích a různých týmech pochopitelně různé. Je proto vhodné seznámit se s konkrétním rozsahem práce už na začátku a také udržovat si schopnost působit ve více rolích.
YAML je další z datových formátů, který se vyplatí znát. Ano, je to "něco jako" JSON. Textový formát s poměrně jednoduchou syntaxí.
Nedávno jsem v tomto blogu vysvětloval formát JSON na tomto příkladu:
A YAML je ještě jednodušší:
Jak vidíte, žádné závorky, jen odsazení pomocí mezer. Dokonce ani textové řetězce nemusí být v uvozovkách. Zkrátka formát vhodný i pro manuální zápis.
XML pro stejný příklad, pak vypadá následovně:
Představte si menší IT firmu, která vyrábí své produkty. Firma má několik analytiků. Analytici analyzují, dodávají své analýzy podle nichž pracují vývojáři. Nějak to funguje. Jak ale poznat, jestli to funguje dobře? Pro posouzení aktuálního stavu stačí znát odpovědi na následující otázky:
Analytický tým
Zpracování požadavků
V minulé kapitole jsem mimo jiné mluvil o API a o formátu JSON (JavaScript Object Notation). Jak takový formát vypadá a jak se v něm zorientovat?
Tak tohle to je text ve formátu JSON:
Začneme jednoduše. "brand" je atribut, "Ford" je hodnota atributu. Atribut může nabývat hodnoty null (tj. hodnota není známá) a může to být také pole hodnot. Příkladem je pole hodnot "equipment". Pole je v hranatých závorkách. složené závorky definují objekt. Takže zde máme objekt "cars", který obsahuje pole car, to obsahuje údaje o třech různých autech.
Pojďme se podívat, jak může vypadat taková moderní webová aplikace. "Webová" proto, že běží v internetovém prohlížeči. Může se jednat jak o aplikaci, která je dostupná jen pro danou firmu a není dostupná pro zákazníky a stejně tak se může jednat o aplikaci, která je určená pro zákazníky a je dostupné z internetu. Výhodou webových aplikací je, že aplikace běží v internetovém prohlížeči (což je dnes ve většině případů Google Chrome nebo Microsoft Edge), není potřeba instalace na lokálním počítači a aplikace je plně multiplatformní (to znamená, že bude fungovat v prohlížeči na operačním systému Microsoft Windows a stejně dobře bude fungovat i v prohlížeči na MacOS nebo ne Linuxu).
Takováto webová aplikace má dnes obvykle část zvanou front-end a část zvanou back-end. Front-end se zabývá prezentační vrstvou a logikou spojenou s prezentací dat. Back-end data zpracovává a ukládá. Front-end a back-end spolu komunikují pomocí API (Application Programming Interface). Existují různé způsoby jak takové propojení mezi front-endem a back-endem vytvořit, ale dnes bude zřejmě nejčastější REST API. To je rozhraní, které využívá HTTP protokol (stejný protokol jaký používá web) a většinou formát JSON (JavaScript Object Notation). Výhodou formátu JSON je, že je snadno čitelný i pro člověka, což se hodí při testování.
Front-end se většinou programuje v JavaScriptu, často používanými frameworky jsou React, Angular a Vue.js. Front-end se dá vyvíjet i v jazyce Python nebo v C# (framework Blazer).
Pro vývoj back-end části lze použít také JavaScript (framework Node.js), velmi často se používá C#, Java. PHP, nebo Python. Back-end obvykle ukládá data do databáze, přičemž rozlišujeme dva základní typy databází - SQL a NoSQL. Příkladem SQL databáze je Microsoft SQL server nebo Oracle database. SQL databáze (označované také jako relační databáze) pracují s databázovými tabulkami. Uložení dat v tabulkách předpokládá dobře strukturovaná data. NoSQL databáze používají jinou strukturu dat než tabulky a jsou mimořádně vhodné pro zpracování nestrukturovaných, rychle se měnících dat.
Zatím tedy máme popsány tyto části - front-end, back-end a databázi pro uložení dat. V praxi to může být ještě složitější, protože naše aplikace může podporovat nějaký složitější proces a potřebuje nějakou logiku, jak realizovat jednotlivé kroky procesu, jak procházet mezi jednotlivými obrazovkami. To by mohlo být řízeno back-endem nebo by to mohl určovat front-end, ale vhodnější je použít nějaký procesní engine. Příkladem takového procesního engine je třeba produkt Camunda. Procesní engine umožní relativně snadno vytvářet a upravovat implementované procesy, umí je zobrazit ve formě BPMN diagramu.
V některých případech může aplikace obsahovat složitou business logiku, která může být hard-coded, ale je vhodnější použít decision engine (tyto systémy se označují také jako business rule management system). Decision engine umí na základě vstupu vrátit výstup, například pokud mu aplikace pošle moje osobní údaje, systém vrátí kolik mě bude stát moje životní pojištění. Tento systém má nakonfigurováno jak se jednotlivé vstupné parametry (věk, váha, místo pobytu, zaměstnání, ...) promítnou do výstupu. Také tento systém umožní provést úpravu a změnit způsob výpočtu aniž by bylo třeba složitě upravovat programový kód.
Business zadavatel má představu, co by měl nový systém dělat a chce ho mít co nejdříve. Ale jak začít? Co třeba začít kreslit obrazovky? Stačí angažovat digitálního specialistu nebo customer journey experta a někoho, kdo ovládá UX tool v kterém lze kreslit obrazovky (setkal jsem se na projektech s Figmou a Axure, ale existuje spousta různých nástrojů). Výsledkem je nakreslená obrazovka, nebo v některých případech prototyp v kterém lze aplikaci procházet. Obrazovky, případně prototyp lze ukázat uživateli a na základě zpětné vazby od uživatele ho snadno upravit. Pak už stačí aplikaci "jen" naprogramovat...
Vytváření obrazovek jako první krok, přináší následující rizika:
Dnes jsem narazil na případ nedostatečné specifikace požadavku. O co šlo? V aplikaci je možné vybrat dokumenty a stiskem ikonky s tiskárnou je hromadně vytisknout. Tisk probíhá tak, že se dokumenty k tisku vygenerují do PDF a výsledný soubor se pošle na tiskárnu.
Co všechno by měl analytik ověřit?
Pojďme se podívat, co je předmětem analýzy, kde končí analýza a co už je design.
Analýza zkoumá uživatelské požadavky na daný systém. Zabývá se primárně tím, co má systém dělat z pohledu uživatele. Může zahrnovat návrh uživatelského rozhraní, může také obsahovat návrh API pro daný systém. Analýza tedy popisuje co má nastat, za jakých podmínek.
Příklad: dejme tomu, že vyvíjíme systém pro půjčování knih v knihovně. Jedním z požadavků je možnost zarezervovat si vybranou knihu pro pozdější vypůjčení. Analýza se bude zabývat tím, kdo může rezervaci provést (jaké uživatelské role), jakým způsobem se rezervace provádí, jestli mají existovat nějaká omezení (například rezervace maximálně 5 knih, doba vyzvednutí do 2 dnů atd.) a co se má stát, když si někdo knihu zarezervuje (např. počet dostupných exemplářů dané knihy se sníží o 1 kus).
Na analýzu by měl navázat design (česky návrh). Design popisuje, jak má být systém vytvořen z hlediska implementace. Design by měl respektovat analýzu a nepřidávat žádnou další funkcionalitu nad rámec analýzy. Měl by definovat, jak bude systém fungovat z technického pohledu. Tj. jaké objekty budou použity, jak budou spolu komunikovat, kdy se co bude ukládat do databáze.
Už delší dobu (od roku 2004) používám Sparx Enterprise Architect, konkrétně Corporate Edition, licenci Standard v ceně 299 dolarů. To je zhruba 6 500 Kč bez DPH. Porovnání jednotlivých edic najdete na následující stránce: https://sparxsystems.com/products/ea/compare-editions.html
Licence je platná 1 rok, po dobu 1 roku můžete program bezplatně aktualizovat, pokud vyjde nová verze. Po uplynutí 1 roku je možné program i nadále používat bez omezení (jen přijdete o zmiňovanou možnost aktualizace a o podporu). Standard licence je pro 1 uživatele, program můžete využívat na více počítačích - tj. pokud používáte notebook a stolní počítač, můžete program nainstalovat na oba počítače.
Variantou k licenci Standard je možnost pořídit licenci Floating. Pokud máte ve firmě například 10 analytiků, ale současně bude pracovat s Enterprise Architektem jen 8 z nich, stačí 8 Floating licencí. Tato licence je o něco dražší, ale zase jich budete potřebovat méně. Nutností je u této licence využívat sdílený klíč.
Enterprise Architect se používá v mnoha IT firmách i IT oddělení velkých bank. Nevýhodou je to, že nemá verzi pro Mac.
Analytik vytváří v průběhu projektu model systému pomocí diagramů. Jaký software použít? V zásadě existují 2 skupiny nástrojů.
První skupinou jsou nástroje, které umožňují vytvářet diagramy, ale jednotlivé elementy diagramu jsou použity právě jen v rámci daného diagramu. Pokud chcete daný element použít v rámci jiného diagramu, pak ho můžete zkopírovat, ale vazba na původní element není uložena.
Druhou skupinou jsou nástroje, které udržují v úložišti (repository) celý model a umožňují vytvářet pohledy na tento model prostřednictvím různých diagramů. Pokud se jedná o stejný element, je uložen v úložišti pouze jednou, ačkoliv může být použit na více diagramech.
Příklad: mám use case digram a v něm use case Založení nového uživatele. V jiném diagramu chci ten to use case propojit s požadavky, které se k němu vztahují. Nástroje z druhé skupiny mi uloží vazby mezi use case a požadavky a use case v use case diagramu bude tyto vazby obsahovat i když je nebude přímo v diagramu zobrazovat.
Nástroje z první skupiny se dají použít v případech, kdy je diagram jen doprovodným obrázkem k textu a jedná se o analýzu menšího rozsahu. Pro profesionální použití v rámci většího projektu je třeba nástroj z druhé skupiny.
Co musí takový nástroj splňovat?
Co by měl znát analytik, kromě své profese, před nástupem na nový projekt? Analytik spolupracuje jednak s vývojovým týmem a jednak s "businessem". Očekává se od něj, že bude mít znalosti z obou oblastí. Tedy z oblasti vývoje software, neboli softwarového inženýrství i z dané business domény.
V tomto příspěvku bych se chtěl zaměřit především na předpokládané znalosti z business domény. Předpokládejme, že cílem projektu je dodat systém pro podporu nějakého finančního produktu. O jaké znalosti se jedná?
