Prvky HLA¶

Úvod¶

Nosným prvkem AAF je Use Case 1. druhu. Cílem analýzy je najít všechny prvky Use Case 1. druhu v projektu a držet konzistenci použití systému od okolního podniku s laickou představou product ownera.

Klasický problém vývoje informačního systému je sémantická propast (semantic gap) mezi laickou představou product ownera a strukturní reprezentací analytika a vývojáře. Product owner mluví laicky, vývojář strukturně. Mezi nimi vznikají chyby z neporozumění — produkt nakonec neodpovídá tomu, co zákazník chtěl. AAF řeší (mimo jiné) možná nedorozumění v rozdílu mezi laickým vyprávěním děje a strukturní formou prvků HLA. Tento jev se přemosťuje přes textové artefakty Use Case Story a Use Case Epic. V nich se zachovává vyprávění product ownera jako vstupní text, ze kterého analytik teprve hledá strukturu. Konečné strukturní artefakty drží stejný obraz jako tento vstupní text. AAF se tak důsledně drží axiomu Value Based Management: hodnota užitku zůstává viditelná pro toho, komu se vytváří.

Navíc uvedený postup transformace vstupních textů do strukturních artefaktů modelu umožňuje unifikovaný systémový přístup analytických prací (včetně cíleného nasazení AI).

Poznámka: Další projevy sémantické propasti — například sjednocení doménových pojmů — AAF řeší v dalších částech, viz kapitoly Class Model a další.

Postup vzniku prvků HLA se řídí touto logikou: Use Case Epic je vstupní delší text vyprávění product ownera. Prochází se text věta po větě a hledají se místa, kde okolí volá systém — tato místa se nazývají Cinknutí systému (analogie s výtahem po stisknutí tlačítka). Hledání je iterativní, přes varianty, se slepými uličkami a couváním. Po nalezení Cinknutí systému se hledají hranice mezi rovnovážnými stavy. Text se pak rozparsuje na N kusů — každý kus je jedno Use Case Story. Z Use Case Story se vytkne zavolání UC, pojmenuje se UC a vloží se jeho scénář (LLA). Vznikne tak dvojice (Atomický proces, UC 1. druhu). Plný výklad postupu viz Agilní postup HLA.

Z této logiky postupu vyplývají jednotlivé prvky HLA. Cinknutí systému je výchozí kotva — bod v textu, kde okolí volá UC. Atomický proces a Složený proces jsou strukturní prvky vzniklé strukturací textu (Composite vzor). Use Case Story a Use Case Epic jsou textové artefakty zachycující vyprávění product ownera. Rozklad procesů je strom organizující všechny Procesy projektu. Zlatý klíčový proces je obchodně nosný Chod procesu, kvůli kterému agenda existuje. Pořadí kapitoly odpovídá této kauzalitě — Cinknutí systému jako kotva první, ostatní jako důsledky.

Na rozdíl od toho v obecném BPM (např. chod firmy, logistika, popis podnikových agend bez vazby na informační systém apod.) je rozklad procesu autorsky volný podle povahy zadání. AAF má oproti tomu pevně daný fokus na vývoj informačního systému, takže jeho kotva — rámec a forma — je striktně dána. Atomicita procesu, hranice systému i scope projektu jsou logické důsledky cíle agilní analýzy vývoje IS — analytik tedy nemá autorskou volnost a postupuje podle šablony danou definicemi a postupy AAF.

Cinknutí systému¶

Cinknutí systému je bod v textu děje, ve kterém okolí volá Use Case 1. druhu. Synonymum: bod použití systému (technický výraz). Pojem je zaveden v kapitolách Use Case 1. druhu a Vrstvy HLA a LLA.

Cinknutí systému jako kotva atomicity¶

Cinknutí systému je rozhodovací bod analytika ve spolupráci s product ownerem. Z tohoto bodu vypadne Atomický proces (jeden nedělitelný úsek od rovnováhy do rovnováhy) a tedy i Atomický krok (úsek v posloupnosti Chodu procesu). Bez identifikovaného Cinknutí systému Proces není atomický a Chod procesu není analyticky zpracován.

Nalezení jednoho Cinknutí systému v ději implikuje nalezení jednoho Use Case 1. druhu.

Cinknutí systému jako určení hranice systému¶

Cinknutí systému současně určuje hranici systému. Děj před Cinknutím systému běží v okolí, děj za Cinknutím systému běží v systému. Tímto způsobem Cinknutí systému určuje rozsah projektu — co ještě není předmětem realizace a co už je předmětem a bude se programovat. Špatně umístěné Cinknutí systému zužuje nebo rozšiřuje scope projektu o celé vrstvy (HW, mobilní aplikace, frontendy). Dopad se někdy projeví měsíce po startu projektu, kdy se zjistí, že buď chybí celá vrstva, anebo se naopak vyvíjely komponenty, které měl dodat někdo jiný. V praxi se hranice řeší dotazováním product ownera nad konkrétním dějem — viz Příklady.

Cinknutí systému v textovém vyjádření¶

V Use Case Story a Use Case Epicu se určují Cinknutí systému jako body přímo v textu děje. V dlouhém textu Chodu procesu je Cinknutí systému signál ve smyslu zde okolo bude Use Case Story a tedy následně Atomický proces a jeho UC 1. druhu. Z tohoto signálu se rozparsováním textu identifikují hranice Atomického kroku alias Atomického procesu.

Standardní vzor textové formulace Cinknutí systému: „… použije se UC XY". Tolerovaný vzor: „… zavolá se UC XY" — je vžitý, ale věcně méně přesný (UC není funkce).

Cinknutí systému v BPMN AAF Lite¶

V diagramu BPMN AAF Lite je Atomický proces vizuálně spojen se svým Use Case 1. druhu vzorem proces použije UC. Plný výklad zápisu viz kapitola BPMN AAF Lite Syntaxe.

Procesy a kroky¶

Proces má v AAF dvě důležité vlastnosti interakce — schopnost skládání a schopnost posloupnosti po sobě. Pomocí Generalizace se zavádí obecný pojem Proces a dva jeho potomci, Atomický proces a Složený proces (Composite vzor a LSP — princip Liskovové).

Vlastnost posloupnosti umožňuje řadit Procesy do posloupnosti děje po sobě. Proto se používá pro Proces v posloupnosti Chodu alternativní pojem Krok — pro zdůraznění povahy Procesu jako jedné jednotky v posloupnosti. Product ownerovi je takové vyjadřování mnohdy bližší.

Pro vyjádření formulace v obecné rovině se používá obecnější pojem Proces (resp. Krok) a zahrnuje významem oba konkrétní pojmy Atomický proces nebo Složený proces (resp. Atomický krok nebo Složený krok) — tj. je platný pro oba pojmy.

V konkrétní situaci se musí použít konkrétní pojem Atomický proces nebo Složený proces (resp. Atomický krok nebo Složený krok) podle toho, o který z nich se jedná.

Atomický proces (Atomický krok)¶

Atomický proces je nedělitelný. Obsahuje právě jedno Cinknutí systému, právě jeden Use Case 1. druhu. Nese kontext okolí pro jedno použití — odtud rovnost logiky obsahu s výchozím textovým artefaktem Use Case Story.

Atomicita Atomického procesu je v AAF důsledkem kotvy Cinknutí systému: jeden Use Case 1. druhu od rovnováhy do rovnováhy = jeden nedělitelný úsek děje. Atomicita tedy není autorské rozhodnutí, ale logický důsledek cíle (viz Úvod).

V posloupnosti Chodu procesu se Atomický proces také nazývá Atomický krok — pro zdůraznění, že jde o jednu jednotku v sledu kvantovaném rovnovážnými stavy. Mezi Atomickými kroky je libovolně dlouhá pauza do další události. Flow šipka v BPMN diagramu nereprezentuje časově okamžitou návaznost — reprezentuje, že po dokončení Kroku je systém i okolí v rovnováze a čeká se na další událost.

Složený proces (Složený krok)¶

Složený proces se skládá z dětí. Děti jsou opět Procesy, Atomické nebo Složené.

V posloupnosti Chodu se Složený proces nazývá v AAF také jako Složený krok. Drží řízení toku svých dětí v posloupnosti — sled, větvení podmínek, paralelní procesy, exclusive gateway.

Příklad Složeného kroku ze školicí firmy: ve vyšším Chodu Chod účastníka kurzem se nachází Složený krok Podání přihlášky účastníka, uvnitř kterého je Exclusive Gateway (slovní „switch") se třemi exkluzivními variantami:

a) Účastník podá přihlášku přes web.
b) Účastník pošle přihlášku v PDF, obsluha ji zadá.
c) Účastník pošle strukturovaný soubor do datové schránky.

Každá varianta je Atomický krok s vlastním Cinknutím systému a vlastním Use Case 1. druhu.

Vztah Složený proces × Chod procesu¶

Chod procesu je Složený proces, na jehož úrovni začíná děj — chápaný jako jeden Složený krok, jehož rekurzivní obsah (Composite) tvoří celou posloupnost Chodu.

Ne každý Složený proces je Chod procesu. Složený proces může být použit i jako Oblast řešení — organizační uzel ve stromu rozkladu, na jehož úrovni žádný děj nezačíná. Plný výklad obou specializací viz Rozklad procesů.

Mezi všemi Chody procesu projektu jsou některé pro vývoj stěžejní podle obchodního významu (Zlatý klíčový proces, Vedlejší proces) a další podpůrné (Tanečky okolo). Plný výklad této hierarchie viz Rozklad procesů.

Use Case Story¶

Use Case Story je textový artefakt — kus parsovaného Use Case Epicu odpovídající jednomu Atomickému procesu. Vyjadřuje jeden děj od rovnováhy do rovnováhy obsahující jedno Cinknutí systému a jedno použití Use Case 1. druhu.

Pojem se uvádí vždy plným názvem Use Case Story. Zkrácený zápis UC Story se v AAF nepoužívá kvůli kolizi s pojmem User Story ze Scrumu.

Use Case Story se skládá ze dvou částí: nadpisu (= název procesu) a těla (= text děje obklopující Cinknutí systému). Tělo obsahuje povinně formulaci Cinknutí systému „zavolá se UC XY" nebo „použije se UC XY". V dokumentech AAF se tělo vyznačuje složenými závorkami { … }. Volitelně může text obsahovat krátký orientační náhled na užitek UC; plný scénář UC je zapsán samostatně v LLA.

V postupu analýzy je text první, diagram druhý. Use Case Story se píše v jednání s product ownerem; teprve z odsouhlaseného textu vzniká diagram BPMN AAF Lite. Text se může vynechat tehdy, pokud diagram s poznámkami nese plnou výpovědní hodnotu.

Rozlišující znaky¶

Use Case Story × Atomický proces: obsahově ekvivalentní, formálně různé. Use Case Story je vstupní textový artefakt vznikající v rozhovoru s product ownerem. Atomický proces je strukturní artefakt vznikající strukturací Use Case Story. Mezi nimi se obsahově nic nepřidá ani neztratí — odhalí se jen struktura. Tato ekvivalence drží most přes sémantickou propast (viz Úvod).

Use Case Story × User Story (Scrum): Use Case Story je vázáno na jeden Atomický proces / jedno Cinknutí systému / jeden Use Case 1. druhu. User Story může být cokoli v ději, i malý střípek bez vazby na UC. Plný výklad srovnání viz sekce Vztah ke Scrumu.

Use Case Epic¶

Use Case Epic je vstupní textový artefakt — vyprávění product ownera o ději v okolí systému při používání systému. Skládá se z N Use Case Story po sobě, včetně řízení toku — větvení, paralelní procesy.

Pojem se uvádí vždy plným názvem Use Case Epic. Zkrácený zápis UC Epic se v AAF nepoužívá kvůli kolizi s pojmem Epic ze Scrumu.

V praxi je tok postupu analýzy opačný než definice. Definice říká „Use Case Epic se skládá z Use Case Story". Praxe ale začíná dlouhým nestrukturovaným textem, ve kterém analytik teprve hledá Cinknutí systému. Z nalezených Cinknutí systému se text rozparsuje na N Use Case Story. Zná se dlouhý text a neví se, jak je složen — ví se z definice, že složen je. Určující jsou nalezená Cinknutí systému.

Rozlišující znaky¶

Use Case Epic × Chod procesu: obsahově ekvivalentní, formálně různé. Use Case Epic je textová forma. Chod procesu je strukturní forma (rekurzivní Composite Atomických a Složených procesů, neboli chápáno také jako posloupnost Atomických a Složených Kroků). Mezi nimi se obsahově nic nepřidá ani neztratí.

Use Case Epic × Epic (Scrum): Use Case Epic je vázán na Chod procesu, drží sled UC od rovnováhy do rovnováhy. Epic ve Scrumu je libovolné větší zadání bez vazby na Chod ani na sled UC.

Rozklad procesů¶

Rozklad procesů využívá schopnost skládání uspořádat v celém projektu všechny činnosti vedoucí k použití systému ve formě stromu. Kořen stromu je „top proces" jako celá agenda nebo projekt. Listy stromu jsou Atomické procesy. Vnitřní uzly stromu jsou Složené procesy.

Oblast řešení a Chod procesu¶

Vnitřní uzly stromu (Složené procesy) mají dvě specializace podle role uzlu.

Role uzlu Chod procesu: Složený proces, na jehož úrovni začíná děj. Drží řízení toku svých dětí — posloupnost, větvení, paralelismus. Má textové vyjádření jako Use Case Epic a (nepovinný) diagram v BPMN AAF Lite.

Role uzlu Oblast řešení: Složený proces použitý jako organizační (uspořádací) uzel. Na jeho úrovni žádný děj nezačíná — slouží jen ke grupování dětí pro snížení počtu prvků na jedné úrovni stromu. Děti Oblasti řešení mohou být cokoli — Atomické procesy, Chody procesu i další Oblasti řešení.

Příklad Oblasti řešení s nedějovými dětmi: uzel Administrace číselníků obsahuje řadu nezávislých Procesů (údržba číselníku zboží, údržba ceníku, údržba uživatelských oprávnění). Mezi nimi není dějová vazba.

Příklad Oblasti řešení s dějovými dětmi: uzel Práce s účastníky a s lektory sdružuje Chod účastníka kurzem a Chod životního cyklu lektora. Obě děti jako Procesy mají vlastní děj, ale na úrovni grupujícího uzlu se s nimi pracuje jen jako se skupinou.

Pořadí priorit prvků ve stromu¶

Procesy v projektu nejsou rovnocenné. Mají svoji prioritu podle obchodního významu — důležité pro postup agilního vývoje v AAF.

Zlatý klíčový proces je obchodně nosný Chod procesu, kvůli kterému agenda existuje. Většinou je v názvu agendy. Plný výklad viz vlastní sekce Zlatý klíčový proces.

Vedlejší proces je další Chod, který vznikne při analýze ze Zákona zachování informace (viz kapitola Zákon zachování informace) — data ve Zlatém Chodu se musí odněkud vzít. Příklad: Městská knihovna má kromě Chodu zápůjčky výtisku titulu ještě Chod výtisku titulu (objednání, platba, zařazení do fondu, vyřazení).

Tanečky okolo jsou drobné podpůrné Procesy. Plní evidenci daty pro klíčové Chody Procesů. Jednotlivě jsou jednoduché, ale nezbytné.

Rozklad procesů a agilnost¶

Rozklad procesů se v AAF buduje agilně. Místo úplného předpřipraveného stromu se začíná od klíčových Procesů a jako první Zlatý klíčový proces. V nich se konzumuje informace pro získání hodnoty, a postupně se rozšiřuje do hloubky a šířky podle potřeb projektu. První výsledky pro realizaci jsou rychle k dispozici. Nalezené UC plní Product Backlog — rozklad se tak stává Fabrikou na issue. Plný výklad postupu viz kapitoly Agilní postup HLA, AAF agilní přístup — Increments Widening, Fabrika na issue.

Rozklad procesů a strategické modelování¶

Rozklad procesů má kromě analytického využití i strategické. Pro rychlé zpracování poptávky (řádově dny) se vytváří neúplný rozklad díky časové tísni: Zlatý klíčový proces popsaný nahrubo v bodech, Vedlejší procesy a Tanečky okolo jen stručně, s důrazem na šířku stromu, aby se nějaká větev shora nezapomněla. Tím se snižuje pravděpodobnost katastrofického podcenění rozsahu prací. Plný výklad této techniky viz kapitola Greenfield a Strategické modelování.

Rozlišující znaky¶

Synonyma pro celý strom rozkladu: Rozklad procesů (hlavní termín), Strom procesů, Dekompozice procesů, Mapa procesů.

Vymezení proti rozkladu v obecném BPM: v BPM je rozklad autorsky volný, v AAF je atomicita Atomických procesů (Kroků) dána kotvou Cinknutí systému. Dva rozklady téhož děje provedené různými analytiky se v AAF musejí shodovat na úrovni Atomických procesů; v obecném BPM se mohou lišit.

Zlatý klíčový proces¶

Zlatý klíčový proces je obchodně nosný Chod procesu, kvůli kterému agenda existuje. Většinou je v názvu agendy nebo projektu.

Příklady:

Agenda úvěrů → Zlatý klíčový proces = Chod procesu úvěru.
Lékárna → Zlatý klíčový proces = Chod procesu léku.
Městská knihovna → Zlatý klíčový proces = Chod procesu zápůjčky knihy.
Mobile Ticket Payment → Zlatý klíčový proces = Chod procesu platby diváka za lístek.

Zlatých klíčových procesů je v projektu obecně velice málo. Avšak pokud se nejedná o velmi jednoduchý projekt, jsou většinou velmi složité — drží jádro hodnoty pro zákazníka.

Se Zlatým klíčovým procesem se pracuje jako s každým jiným Chodem procesu, ale s prioritou analýzy. Z této priority plyne potřeba mockupů místo reálné implementace Tanečků okolo. Use Case 1. druhu Zlatého klíčového procesu se vyvíjejí dřív než Tanečky, které je plní daty. Tanečky se v této fázi simulují skripty. Zlatý klíčový proces se tím stává nosným prvkem AAF agilnosti.

Hledání Zlatého klíčového procesu je rychlé — vede ho obchodní logika agendy, viz příklady výše. Plný výklad postupu viz kapitola Hledání zlatého klíčového procesu. Vazba na agilní postup viz Agilní postup HLA, Fabrika na issue.

Rozlišující znaky¶

Zlatý klíčový proces × Vedlejší proces: Zlatý nese hlavní hodnotu užitku. Vedlejší vzniká až při analýze kvůli Zákonu zachování informace (podpůrné a mají svůj Chod procesu).

Zlatý klíčový proces × Tanečky okolo: Zlatý drží jádro hodnoty. Tanečky drží evidenci daty, jsou drobné a podpůrné — nemají vlastní Chod procesu.

Vztah ke Scrumu¶

AAF a Scrum řeší různé roviny. AAF je analytický framework, Scrum je framework řízení zadání prvků pro zpracování. Pojmy Use Case Story a Use Case Epic se názvem podobají scrumovým User Story a Epic, ale podstatou nejsou totéž.

AAF buduje agilně logickou architekturu systému jako celku — okolí + systém — s důrazem na udržení hodnoty užitku pro zákazníka (viz Value Based Management). Scrum je sofistikovanou technikou zadání do vývoje.

Výstupy AAF jsou velmi dobrým agilně budovaným zdrojem podkladů pro tvorbu issue do Scrumu (Kanbanu) při plnění Backlogu.

Dvojice AAF (Use Case Story, Use Case Epic) drží konzistenci děje přes celý Chod procesu — sled UC od rovnováhy do rovnováhy. Tím plní požadavek axiomu Value Based Management: fokus na hodnotu užitku pro zákazníka. Opakem konzistence je střípkování — nepřehledná halda User Stories bez vazby na UC, ze které nejde rekonstruovat dějovou logiku procesu. Po několika měsících práce ztrácí projekt celkový pohled.

Use Case Story × User Story¶

Use Case Story je vázáno na jeden Atomický proces (Krok), jedno Cinknutí systému, jeden Use Case 1. druhu. Hranice Use Case Story je dána dějovou logikou rovnováha–rovnováha.

User Story může být cokoli — i střípek, který nemá vazbu na žádné UC. Hranice User Story ve Scrumu je dána potřebou týmu rozdělit práci na zvládnutelné jednotky.

Use Case Epic × Epic¶

Use Case Epic je textový ekvivalent Chodu procesu. Drží sled Use Case Story od rovnováhy do rovnováhy včetně řízení toku.

Epic ve Scrumu je libovolné větší zadání. Není vázán na Chod procesu ani na sled UC.

Nejčastější chyby¶

Chybějící konstrukce HLA prvků a priorit issue¶

Vývoj se provádí bez úvah nad prvky HLA, tedy bez logických souvislostí konzistence „okolí–systém". Nezkoumá se „co děláte a jak při tom použijete systém", neuvažují se priority mezi prvky z hlediska Value Based Management.

Příklad: Při vývoji IS pro firmu poskytující školení pomocí externích lektorů se při realizaci ve Scrumu nerozlišuje priorita mezi issue typu „v poli telefonního čísla přidat správný formát" a issue „výpočet odměny lektorovi podle evidence hodin v rozvrhu". Nehledá se logika „jak funguje lektor" v pohledu prvků HLA a UC a jaké jsou priority podle VBM — vše v jednom pytli.

Mylné vidění prvků jako už existujících¶

Při studiu definic se Atomický proces, Krok procesu, Use Case Story, Use Case Epic a Cinknutí systému jeví jako prvky, které prostě v procesu jsou a stačí je „najít". Při analýze konkrétního procesu ale tyto prvky neexistují. Analytik je tvoří z čisté vody na čistý papír, není to hledání v pravém slova smyslu „search" mezi existujícími prvky.

Bez důsledného postupu (viz Agilní postup HLA, AAF agilní přístup — Increments Widening) dochází k chybnému vymezení prvků HLA. Atomický proces se zavede tak, že není atomický — lze ho dál dělit, má několik Cinknutí systému. Use Case Story popisuje děj, který nesedí s hranicemi rovnováhy. Cinknutí systému je položeno jinam než tam, kde proces skutečně potřebuje systém.

Důsledek: prvky v dokumentu jsou zavedeny, mají jméno, ale obsahem neodpovídají svým definicím. Dokument vypadá hotový, ale je vnitřně nekonzistentní.

Poznámka. Tento typ chyby je vhodným cílem pro AI asistenta v rámci Vibe Analysing™. Validace zavedených prvků proti jejich definicím je mechanická kontrola sémantiky. AI asistent zvládá tuto kontrolu konzistentně, zatímco autor textu má tendenci si vlastní práci přečíst tak, jak ji chtěl mít. AI asistent vyzbrojený skill souborem s definicemi prvků HLA a kritérii Rozlišujících znaků funguje jako neúnavný druhý pár očí. Plný výklad role AI asistenta v AAF viz kapitola Vibe Analysing™ (TODO).

Střípkování Use Case Story na úroveň User Story¶

Analytik píše Use Case Story tak krátké, že nepokrývá celý děj od rovnováhy do rovnováhy. Vznikají texty typu „Uživatel vybere Osobu ze seznamu Osob" — to je User Story (Scrum), ne Use Case Story (AAF).

Důsledek: text není vázán na žádný Atomický proces (Krok). Není to pohled okolí na Use Case 1. druhu. Logika rovnováha–rovnováha se rozpadá. Rozdíl viz sekce Vztah ke Scrumu.

Je to stejné jako dělat inventuru v porcelánce v obrovském skladu vyrobených kusů z porcelánu (už to samo není jednoduché), ale kusy jsou rozbité a musí se „logicky skládat z haldy střepů".

Diagram bez textu¶

Analytik nakreslí BPMN diagram chodu procesu rovnou, bez textového Use Case Epicu a bez dobrých komentářů či popisů.

Důsledek: chybí jednání s product ownerem (na text se ptá lépe než na diagram), chybí stopa, jak se k diagramu došlo, a častěji vznikají hluchá místa. Standardní postup je text → diagram, případně současně text a ilustrace diagramem, nikoliv nejprve diagram. Text se může vynechat jen tehdy, pokud diagram s poznámkami nese plnou výpovědní hodnotu. Diagram je sice „přehledný", ale většinou nemá vysvětlující hodnotu pro čtenáře a chybí mu důležité povinné detaily. Bývá mnohdy zdrojem nedorozumění.

Chybný rozklad díky ignoraci priorit procesů¶

Analytik staví strom rozkladu nelogicky bez respektování rozlišení vrcholů Zlatého klíčového procesu, Vedlejších procesů a Tanečků okolo.

Důsledek: ztrácí se informace, kde je hodnota užitku. Projekt nemá strategický fokus na VBM. Všechny Procesy dostávají stejnou váhu — ergo všechny se zpracovávají se stejnou prioritou. Zlaté klíčové procesy a Vedlejší procesy mají mít v AAF prioritu zpracování, Tanečky okolo až po nich. Plný výklad viz sekce Zlatý klíčový proces v této kapitole a kapitola Hledání zlatého klíčového procesu.

Vazby¶

TBD

Příklady¶

Loď a satelitní příjem zpráv¶

Kapitán na lodi pracuje se zařízením a postupně zadává zprávu o vyplutí — datum a čas vyplutí, údaje pasažérů, údaje o nákladu. Po dokončení zadání se zpráva odešle přes satelit do našeho systému. Hledá se Cinknutí systému (použití):

Pokud je bod použití našeho systému identifikován v okamžiku, kdy kapitán začíná zadávat zprávu na zařízení — lodní zařízení patří do našeho systému a vyvíjíme i jeho SW (UI pro zadání zprávy, validace polí, lokální stav).
Pokud je bod použití identifikován až v okamžiku příjmu odeslané zprávy ze satelitu na serveru — lodní zařízení je cizí systém a vyvíjíme jen příjem a evidenci zpráv.

Rozdíl mezi těmito dvěma rozhodnutími znamená několikanásobně jiný rozsah projektu.

Skladník a tablet¶

Skladník na rampě postupně odečítá čtečkou kódy balíků z kamionu, dokud není zboží vyskladněno. Hledá se Cinknutí systému (použití):

Pokud je bod použití identifikován v okamžiku odečtení kódu na tabletu — tablet aplikace patří do systému.
Pokud je bod použití identifikován až v okamžiku příjmu zprávy z tabletu na serveru — tablet je cizí systém, vyvíjíme jen serverovou stranu.

Webový formulář registrace uživatele¶

Zákazník vyplňuje pole formuláře v prohlížeči a po dokončení odešle formulář na server. Hledá se Cinknutí systému (použití):

Pokud je bod použití identifikován v okamžiku, kdy zákazník začíná vyplňovat formulář v prohlížeči — frontend (validace polí, UX, stavy) je součást systému.
Pokud je bod použití identifikován až v okamžiku příjmu POST requestu na backendu — frontend je samostatný produkt a vyvíjíme jen API.

Verze a změny¶

Verze	Změny
1.0	První zveřejněná verze kapitoly.