Nemáme business požadavky. Pojďme zkusit Business Driven Development...

Na projektu jsem se setkal s problémem, že nejsou definované business požadavky. Tedy nějaké požadavky analytik získá, ale ne všechny. 

Jak si to představit? Pojďme si dát příklad z vytváření fiktivního eshopu. Víme, že zákazník může zadat objednávku, zaplatit a zobrazit stav objednávky. Nemáme ale nikoho, žádného zástupce "businessu", který by nám řekl, že zde chybí možnost stornovat objednávku. Na projektu máme "experta", který vystupuje zadává požadavky, ale nezná skutečné potřeby zákazníka, takže ho ani nenapadne, že by zákazník mohl chtít stornovat pohledávku a že by bylo dobré mu to za určitých podmínek umožnit.

Problém je, že vyvineme veškeré funkcionality dle specifikace, otestujeme je a ve výsledku se při použití na produkci zjistí, že zákazník nemůže stornovat objednávku, protože o této možnosti nikdo neuvažoval. Analytik o ní nevěděl, nebyla tudíž ve specifikaci. Vývojář s touto možností nepočítal.  Tester tuto možnost netestoval. Takže musíme vymýšlet, jak tam tuto funkcionalitu přidat a ve výsledku je to samozřejmě mnohem větší problém, než kdybychom s touto možností počítali už na začátku.

Nejnovější (a podle mě ne úplně funkční) nápad je, řešit to pomocí Business Driven Developmentu. Pojďme si nadefinovat testovací scénáře a pokud splníme tyto testovací scénáře, pak máme pokrytou veškerou potřebnou funkcionalitu. Kdo bude tyto scénáře definovat? Přece business, tedy reálně náš "expert". A jak to dopadne? Expert definuje testovací scénáře pro zadání objednávky, zaplacení a zobrazení stavu objednávky... 

Principy moderních komunikačních a integračních protokolů při autentizaci, autorizaci a integraci systémů

Při procházení náborových inzerátů na pozici IT analytik jsem nedávno narazil na následující na požadavek, že by měl analytik znát "principy moderních komunikačních a integračních protokolů při autentizaci, autorizaci a integraci systémů". Pojďme se podívat, co se za tím zřejmě skrývá.

Začneme úplně od začátku. Základními pojmy.

• Komunikační protokol je způsob, jakým spolu IT systémy komunikují. Popisuje, jaké informace se předávají a v jakém pořadí.
• Autentizace je ověření identity uživatele. Tedy toho, že daná osoba je opravdu ta, za kterou se vydává. Autentizace může být jednofaktorová nebo vícefaktorová. Jednofaktorová autentizace může být založená na základě znalosti uživatele (heslo, PIN), vlastnictví uživatele (identifikační dokument, klíč, karta) nebo na základě biometrických údajů (např. otisk prstu). Vícefaktorová autentizace kombinuje více nezávislých věcí (např. heslo + kód zaslaný pomocí SMS na mobilní telefon).  
• Autorizace ověřuje práva uživatele. Jde tedy o  ověření, zda daná osoba má právo provést danou akci.

A teď se pojďme podívat na "moderní komunikační a integrační protokoly". Pro integraci se nejčastěji používá REST API a HTTP protokol. Co tento protokol nabízí?

• Základní autentizace - klient odešle v hlavičce požadavku uživatelské jméno a heslo kódované pomocí Base64.
• Heslová autentizace - klient posílá uživatelské jméno a hash hesla, čím se zvyšuje bezpečnost (hash hesla je odvozený z hesla, ale z hashe nelze heslo odvodit)..
• Tokenová autentizace - klient obdrží od serveru unikátní token, který poté předá v hlavičce každého požadavku.
• Autentizace pomocí certifikátů klienta - klient musí disponovat platným certifikátem vydaným certifikační autoritou. Server ověřuje platnost certifikátu klienta.
• OAuth(2.0) - Open Authorization -  autorizace pomocí třetí strany - autorizačního serveru. Uživatel je přesměrován na autorizační server, kde se přihlásí např. uživatelským jménem a heslem a povolí přístup k vybraným datům (např. k emailové adrese, jménu a příjmení).Autorizační server vydá autorizační kód. Na základě tohoto kódu lze získat přístupový token pomocí kterého lze přistupovat k vybraným datům daného uživatele.
• OpenId Connect (OIDC) - rozšíření OAuth 2.0 o autentizaci. Přidává navíc  ID token, což je JSON Web Token (JWT), který obsahuje informace o uživateli a jeho ověření. 

Specifikace požadavků a požadavky na uživatelské rozhraní

Představte si, že jako analytik popisujete požadavek, který specifikuje, jak bude uživatel zadávat do systému například požadovanou výši úvěru a délku splácení. Máte nějakým způsobem ve specifikaci podrobně popisovat uživatelské rozhraní?

"Podrobný návrh rozhraní - například konkrétní podobu dialogů - popište v samostatné specifikaci uživatelského rozhraní, nikoliv ve specifikaci požadavků. Náčrtky obrazovek do specifikace požadavků vložit můžete, protože představují další důležité úhel pohledu na požadavky. Dejte ale jasně najevo, že jsou to nezávazné modely."

Wiegers, Karl E. 2008. Požadavky na software. Od zadání k architektuře aplikace. Brno: Computer Press a.s. 

S uvedeným citátem plně souhlasím. Do specifikace požadavků podrobná a závazná specifikace uživatelského rozhraní rozhodně nepatří. Jako analytika mě zajímá, že se výše úvěru bude zadávat do políčka výše úvěru, že formulář bude obsahovat výběr délky splácení, bude zobrazovat úrokovou míru, počítat výši splátky a umožní uložit zadané a vypočtené hodnoty. 

Následující obrázek tedy do specifikace požadavků patří.

Co do specifikace nepatří je podrobný popis uživatelského rozhraní. Tj. například následující text:

 

"Pro text "Amount" bude použit font Arial, velikost 10. Vstupní pole bude ohraničeno modrou čárou (RoyalBlue) o šířce 2 px."

To by mělo být součástí specifikace uživatelského rozhraní, které by nemělo být popisováno na úrovni jednotlivých políček, ale na úrovni znovupoužitelných komponent.

Srozumitelná komunikace je základ

Máme zadanou chybu. Něco nefunguje tak, jak by to fungovat mělo. Vrací to výsledek A, má to vracet výsledek B.  Chyba je založená v JIRA.

Do komentářů vývojář napíše: "Podle mě to funguje správně."

Osoba 1: Hm, funguje to správně, takže mu to vrací správný výsledek B.

Osoba 2: Vrací mu to zřejmě výsledek A, ale píše, že je to tak správně. Takže někde ve specifikaci je, že by to přece jen mělo vracet A. 

Důležité je komunikovat tak, aby byl sdělení jasné a srozumitelné pro všechny. 

Pro jakou firmu pracovat

Pokud chcete pracovat jako OSVČ (osoba samostatně výdělečně činná) na softwarových projektech pro finanční instituce, budete potřebovat obvykle prostředníka. Tj. firmu, s kterou uzavřete smlouvu a které budete následně provedenou práci fakturovat. Banky a pojišťovny obvykle nenajímají OSVČ napřímo bez tohoto prostředníka. A i když si samozřejmě tento prostředník bere větší či menší provizi, bude to pro Vás i tak výhodnější než se stát zaměstnancem banky, nebo zaměstnancem toho prostředníka.

Na co si dát pozor a co je důležité? Dejme tomu, že Vás zaujal následující inzerát:

Firma TechPro a.s. hledá analytiky na bankovní projekt - vývoj nového internetového bankovnictví pro jednu z největších bank v ČR. 

• MD rate až 9 000 Kč, dle znalostí a zkušeností,
• skvělý kolektiv a spousta teambuildingů,
• kanceláře přímo na metru.

Na co si tedy dát pozor:

• Zjistěte si, kdo je TechPro a.s., možná je to nová firma z holdingu ABC, kam třeba  úplně nechcete.
• Máte zájem o konkrétní projekt zmiňovaný v inzerátu a už se vidíte jako analytik při vývoji nového internetového bankovnictví? Pozor, často slouží zmiňovaný projekt jen k nalákání zájemců. Ano, na tom projektu pracují někteří lidé z  TechPro a.s., ale momentálně je tu k dispozici migrace systému XYZ...
• Stejné lákadlo je MD rate až 9 000 Kč. Pokud máte 20 let praxe, je Vám méně než 30 a vystudoval/vystudovala jste 3 vysoké školy, pak to platí, jinak je to  méně.
• Skvělý kolektiv je rozhodně super, ale Vy budete pracovat na konkrétním projektu v bance a někdy i dlouhodobě několik let. Tento projekt může být namíchán z lidí z různých firem a může se stát, že na něm z firmy TechPro a.s. budete sám. Tím pádem se budete znát z firmy TechPro a.s. jen s omezeným okruhem lidí. Teambuilding může být fajn, ale opravdu chcete trávit víkend s lidmi, které vůbec neznáte?
• Většinou budete pracovat u zákazníka, do firmy TechPro a.s. tak jednou za rok a někdy ani to ne. Takže kde firmy sídlí Vás trápit nemusí.

Co je důležité?

• Dohodněte se na konkrétní částce a práci na konkrétním projektu. Nevěřte slibům typu, že zatím budete pracovat na té migraci systému XYZ za 5 000 Kč/MD, ale jakmile se osvědčíte a jakmile se uvolní místo na tom novém projektu internetového bankovnictví, tak se uvidí. 
• Zkuste více firem. Některé firmy dávají důraz na praxi, jiné na znalosti, někdo ocení Vaše minulé projekty - každá z firem Vám může nabídnout jinou částku.
• V zásadě jsou si uvedené firmy podobné - některé jsou větší a některé menší, ale pokud máte dohodnutou slušnou částku a zajímavý projekt, nemusí Vás příliš rozdíly mezi firmami trápit.

Case nástroj nebo nástroj na kreslení diagramů

 Proč použít case nástroj (například Sparx Enterprise Architect) oproti nástroji na kreslení diagramů? A jak se to vlastně liší? 

Case nástroj má tzv. repository a jednotlivé diagramy jsou jen různé pohledy na danou repository nebo spíše na její část. Jednotlivé elementy se mohou vyskytovat v různých diagramech a mít mezi sebou vazby. 

Oproti tomu v nástroji na kreslení diagramů repository chybí. Takový nástroj umožňuje naskreslit diagram, ale informace o jednotlivých elementech a jejich propojení se neukládá do repository.

Mějme dva diagramy kde se vyskytuje zákazník. Na jednom diagramu je vztah mezi zákazníkem a objednávkou, na druhém mezi zákazníkem a fakturou. V case nástroji je vše uloženo v databázi (repository case nástroje) a u entity zákazník se dá zjistit, ke kterým entitám má vztah (relation). Pokud analytik provede změnu a přejmenuje zákazníka na klienta, přejmenuje se v obou (ve všech) diagramech.

V nástroji na kreslení diagramů jsou výstupem dva diagramy. Pokud přejmenujete zákazníka na klienta v jednom z nich, v druhém se to vůbec neprojeví. Máme tak zákazníka a klienta, jeden má na diagramu vztah k faktuře, druhý k objednávce. 

Závěr:

• Pokud chcete modelovat informační systém, potřebujete case nástroj.
• Pokud chcete nakreslit diagram, použijte nástroj na kreslení diagramů.
• Modelovat informační systém v nástroji na kreslení diagramů lze, ale bude to obtížné a neefektivní.
• Kreslit diagramy v case nástroji lze, ale case nástroj je jako řešení jen pro kreslení diagramů poměrně drahý.

Na námět analýzy

Dnes se chci zabývat situací, kdy se vývojář analýzou jen inspiruje a výsledek je zcela jiný, než je popsáno ve specifikaci. A mám tu konkrétní případ:

Jedná se o výpočet, kde se je očekáván výsledek za celý úvěrový případ. Úvěrový případ může obsahovat více klientů. Je třeba získat pomocí další služby výsledky za každého klienta zvlášť a pak spočítat výsledek za celý úvěrový případ. Služba pro získání výsledku pro daného klienta může selhat.

V analýze bylo toto:

1. Získáme seznam klientů na úvěrovém případu.
2. Pro každého klienta zapíšeme do databáze stav výpočtu NEW.
3. Pro každého klienta zavoláme službu zjišťující výsledky za daného klienta. Stav výpočtu nastavíme na IN_PROGRESS.
4. Pokud získáme výsledek pro klienta, nastavíme stav výpočtu FINISHED. Pokud bude vrácena chyba, nastavíme stav výpočtu ERROR.
5. Počkáme na získání výsledku výpočtu pro všechny klienty pro daný případ. Pokud je stav výpočtu pro všechny klienty FINISHED, spočítáme výsledek za celý úvěrový případ. Pokud je alespoň jeden stav výpočtu ERROR, vracíme chybu.

Implementováno bylo toto:

1. Získáme seznam klientů na úvěrovém případu.
2. Pro každého klienta zapíšeme do databáze stav výpočtu NEW.
3. Pro každého klienta zavoláme službu zjišťující výsledky za daného klienta. 
4. Pokud získáme výsledek pro klienta, nastavíme stav výpočtu FINISHED. Pokud bude vrácena chyba, nastavíme stav výpočtu ERROR.
5. Počkáme na získání výsledku výpočtu pro všechny klienty pro daný případ. Spočítáme výsledek za celý případ pro všechny klienty se stavem výpočtu FINISHED. Pokud žádný takový klient není, vracíme chybu.

Jak je vidět, stav IN_PROGRESS v implementaci chybí. Takže pokud bude potřeba řešit "zaseklé" případy u kterých z nějakého důvodu nedošlo k vrácení výsledku, bude analytik čekat (dle původní analýzy), že tyto případy budou mít stav výpočtu IN_PROGRESS. A bude čekat marně...

Dalším problém je samotný výpočet, který nebere v úvahu, že může existovat část klientů se stavem výpočtu FINISHED a část se stavem výpočtu ERROR. Dle analýzy by měl výpočet skončit chybou, podle implementace se výsledek spočítá pro všechny klienty se stavem výpočtu FINISHED.  

Ve výsledku tedy není implementace dle analýzy, ale spíše "na motivy" analýzy, kdy se analýzou jen volně inspiruje. A to není stav, který by byl žádoucí.

Agilní versus projektový přístup k vytváření software

Pojďme se podívat na porovnání projektového a agilního přístupu k vývoji software:

Projektový přístup

Projektový přístup je založen na tom, že chceme dodat určitou funkcionalitu, kterou je zákazník schopen (s pomocí analytika) předem specifikovat. Máme tedy jasně definovaný cíl, kterého chceme dosáhnout. Začneme vytvořením plánu z hlediska času, zdrojů a závislostí mezi jednotlivými úkoly. 

Následně projekt spustíme a průběžně vyhodnocujeme z hlediska času a spotřeby zdrojů. Případné změny v průběhu projektu jsou obvykle nežádoucí, protože boří předem připravený plán. Výhodou (teoretickou) je, že pokud vše půjde podle plánu, víme na začátku projektu co, kdy a za kolik dostaneme. Jednotlivé fáze projektu - analýza, vývoj, testování - jdou sekvenčně za sebou.

Agilní přístup

Agilní přístup vychází z agilního manifestu, který lze shrnout ve 4 větách:

• Jednotlivci a interakce před procesy a nástroji.
• Fungující software před vyčerpávající dokumentací.
• Spolupráce se zákazníkem před vyjednáváním o smlouvě.
• Reagování na změny před dodržováním plánu.

Při agilním přístupu tedy zkusíme vytvořit část systému a získat zpětnou vazbu uživatelů. Během vývoje počítáme se změnami, takže nakonec se můžeme dostat jinam, než jsme předpokládali na začátku. Agilní přístup znamená rychlou reakci na změnu. Jelikož tyto změny dopředu neznáme, není jasné co a kdy dostaneme jako finální výstup. Práce probíhá postupně, iterativně - analýza, vývoj, testování - se opakují v rámci sprintu. Zkusíme vyvinout životaschopnou část systému v rámci pevně dané doby - sprintu -  a pak pokračujeme dalším sprintem. Náplň sprintu se určí až při zahájení sprintu, není daná dopředu.

Jak poznat, že analytik pracuje efektivně

Jak poznáte, že analytik na projektu pracuje efektivně tj. že posunuje projekt správným směrem dostatečně rychle? 

Manažeři se většinou snaží nalézt nějakou jednoduchou metriku, kterou se dá objem a kvalita práce měřit. U dělníka ve šroubárně to může být počet vyrobených šroubů za den, které úspěšně projdou výstupní kontrolou. Pokud je počet šroubů větší než X, tak je vše v pořádku. Pokud je výrazně menší, je třeba hledat příčinu problému.

Jde něco podobného aplikovat i u analytika? Podle mě nejde. Počet zaznamenaných požadavků, počet schůzek, počet zpracovaných user stories, vytvořených počet diagramů, počet řádků analýzy ani čas strávený editováním analytických dokumentů (ano, i to jsem zažil)  nejsou vypovídající. Práci analytika podle mého názoru nelze měřit takto jednoduchými metrikami.

Takže způsob jak poznat, že analytik pracuje efektivně se dá komplexním posouzením jeho práce. Zkušený team leader analytického týmu je schopen obvykle odhadnout, jak složitá bude analýza dané oblasti. Měl by mít dostatek zkušeností k posouzení analytických výstupů a dobře znát analytiky ve svém týmu a jejich schopnosti a také nedostatky.

Takže chcete-li vědět. kdo v týmu analytiků pracuje efektivně a kdo se možná trochu veze, ptejte se team leadera a nevymýšlejte metriky pro hodnocení analytiků.

Expert a "expert"

Základem dobré analýzy je sběr požadavků. Pro sběr požadavků je potřeba kontakt se "stakeholdery". Takovým stakeholderem bývá zkušený uživatel nebo procesní specialista, prostě někdo, kdo je schopen formulovat, co, jak a proč má daný systém dělat.

Problémem se kterým se můžete setkat je expert, který o sobě tvrdí, že tyto informace má. Velmi často představuje zároveň bariéru pro přímý kontakt s uživateli. Vždyť proč byste měli kontaktovat uživatele, kteří často nevědí co chtějí, nebo mají protichůdné požadavky, když máte k dispozici experta, který je schopen zodpovědět jakoukoliv otázku a přesně ví, co a jak je potřeba. 

Ano, situace, kdy máte k dispozici takového experta je pro analytika velmi pohodlná. Tedy za předpokladu, že je to skutečný expert a ne "expert". Skutečný expert má znalost procesu, ví jak uživatelé pracují, je s nimi v kontaktu. Když uživatelů dostanou funkcionalitu vyvinutou na základě požadavku takového experta, jsou spokojeni, protože vše funguje podle jejich očekávání. A pokud něco funguje trochu jinak, je expert schopen vše vysvětlit a obhájit.

"Expert" je také schopen zadávat požadavky. Problém je, když dojde na jejich realizaci. Většinou se zjistí, že některé důležité funkcionality chybí, spousta jich přebývá a to co jakž takž uživatelům vyhovuje se zase nepoužívá úplně pohodlně. "Expert" pak tvrdí, že uživatelé ve skutečnosti nevědí, co chtějí. Nové řešení je skvělé, jen uživatelé mají odpor ke změnám. Bohužel není schopen řešení obhájit, takže namísto dokončení projektu a doladění chyb řešíte jednu změnu za druhou. Jelikož jsou tyto změny obvykle také nedomyšlené, vyvolávají další změny a projekt se protahuje a prodražuje.