Agilní postup HLA

Popis činnosti

Agilní postup HLA je činnost, kterou analytik s product ownerem převádí vyprávění o ději v okolí systému na strukturu HLA. Vstupem je Use Case Epic, tedy text děje, ve kterém okolí používá systém. Výstupem jsou nalezená cinknutí systému, identifikované Use Case 1. druhu a posouzení, zda děj drží pohromadě. Směr je vždy text → struktura; dělení textu řídí kotva cinknutí systému, ne volný úsudek. Postup je iterativní: Use Case Epic přichází ve variantách, slepé uličky a couvání jsou běžnou součástí práce.

První se určí Zlatý klíčový proces (viz stejnojmenná kapitola); jeho Use Case Epic dodá product owner a analytik ho posuzuje jako první. Ostatní Chody procesu následují stejným postupem.

Tato verze kapitoly popisuje první část postupu: hledání cinknutí systému a posouzení jednoho Use Case Epicu. Rozklad procesů do stromu s prioritami a detailizace patří do další verze; pojmy k tomu drží Prvky HLA.

Vstupy

• Use Case Epic od product ownera: vyprávění o ději v okolí, jedna varianta Chodu procesu. Varianty se posuzují postupně, každá zvlášť.
• Výpis požadavků z kapitoly Zadávací dokumentace a její zpracování: Funkční požadavky jako mantinely, kterým děj nesmí odporovat, a stopa, kterých se cinknutí dotýká; Nefunkční a technologické požadavky jako rámec, kterému děj nesmí odporovat; položky Mimo s pokračováním ano jako věci, ke kterým se děj vrací; Neurčeno jako otevřené otázky, které děj nesmí potichu rozhodnout.
• Předmět systému z výpisu požadavků jako hranice toho, co je náš systém.

Kroky

Krok 1. Účastníci Epicu a kde žijí. Analytik nejprve vyjmenuje účastníky Epicu: náš systém a každý prvek z okolí, který v ději jedná (divák, kino, dopravce). U každého účastníka rozhodne jednou za celý Epic, kde žije: uvnitř systému, venku, nebo to neví. Rozhoduje otázkou „budeme to programovat?" (Use Case 1. druhu, test hranice systému); odpověď nevíme je otázka pro product ownera, ne odhad. Jeden účastník má jedno rozhodnutí; když by tentýž název označoval v Epicu dvě různé věci, je to homonymum v zadání, tedy chyba autora Epicu, a hlásí se jako otázka. Seznam účastníků je výcuc z textu, který vzniká před hledáním cinknutí; bez něj se nedá říct, kdo se na koho obrací.

Krok 2. Hledání cinknutí systému a parsování textu na úseky. Analytik projde Use Case Epic větu po větě a u každé se ptá: obrací se tu okolí na náš systém? Spouští se tu něco, co se bude programovat? Když ano, je to cinknutí systému. Cinknutí je binární, v daném bodě děje buď je, nebo není. Analytik ho označí přímo v textu. Cinknutí, které v textu není, se nevymýšlí; kde text mlčí a děj by ho potřeboval, vzniká otázka (krok 5).

Kolem každého cinknutí analytik vymezí úsek textu podle šablony děje Use Case 1. druhu: od věty, ve které událost v okolí naruší rovnováhu, po větu, ve které se rovnováha obnoví. Je to metoda parsování textu: úseky se nepřekrývají, každý úsek má právě jedno cinknutí, a věty mimo jakýkoli úsek jsou děj okolí bez použití systému. V nejjednodušším případě je úsek jedna věta. Co s úseky dál (jejich pojmenování a struktura), patří do další části postupu.

Krok 3. Pojmenování Use Case 1. druhu. Z každého cinknutí plyne právě jeden Use Case 1. druhu. Analytik ho pojmenuje užitkem pro okolí, ne technickou operací, a zapíše, co okolí do systému dává a co od něj dostává, ale jen to, co text říká. Totéž použití systému na dvou místech děje je jeden Use Case, ne dva. Vnitřek Use Case, tedy scénář, se v HLA neotvírá; patří do LLA.

Krok 4. Posouzení korektnosti děje. Posuzuje se každý krok děje kolem cinknutí, na obou stranách hranice.

• Zákon zachování informace. Posuzuje se pro každého účastníka z kroku 1 zvlášť a vždy v kontextu děje: u každé informace, se kterou účastník v dané větě jedná, analytik ověří, že má v ději zdroj nebo kanál. Chybí zdroj účastníkovi z okolí, je v té větě jasnovidný. Chybí zdroj systému, je v té větě jasnovidný systém. Obojí je defekt děje; oprava je doplnění kroku nebo použití systému, ne domyšlení hodnoty. Průchod se dokládá: u každého účastníka je zapsáno, se kterými informacemi ve kterých větách jedná a zda mají zdroj; nález u jednoho účastníka neuzavírá kontrolu ostatních (Zákon zachování informace, posouzení pro každého účastníka zvlášť).
• Anonymita klienta podle Objektového paradigmatu, čtyři cesty, všechny jsou spoléhání na klienta. Cesta 1, nekontrolovaný vstup: co přijde do Use Case z okolí, systém kontroluje (blbovzdornost, ověření vstupů); spoléhání, že přijde jen správné, je defekt. Cesta 2, opomenuté větve mimo šťastný průběh: je popsán jen průběh, kdy vše vyjde, a návrh se spoléhá, že ostatní situace nenastanou: klient zaplatí pozdě, opakovaně, vůbec, spojení se ztratí, uplyne lhůta. Každá taková situace je větev děje, která v Use Case Epicu chybí, a je to nález. Cesta 3, delegace vlastní garance ven: údaj, který má systém garantovat sám (identifikátor, kontrola), nemá přebírat od okolí; je to doporučení s důsledky, ne defekt. Cesta 4, předčasné vynoření: služba rozdělená na kroky, mezi které se dostane okolí, je defekt.
• Soulad s výpisem požadavků. Krok děje, který odporuje Funkčnímu požadavku nebo Nefunkčnímu a technologickému požadavku, je defekt. Funkční požadavek má svůj obraz v analytickém modelu, ale ne nutně na hranici systému: buď v cinknutí a Use Case 1. druhu, nebo uvnitř scénáře (algoritmus, výpočet, pravidlo), nebo ve struktuře Class Modelu, nebo jako omezení, které model všude respektuje. HLA proto pokrytí Funkčních požadavků nerozhoduje; u každého Use Case jen zapíše, kterých Funkčních požadavků se dotýká. Cinknutí, kterého se žádný Funkční požadavek netýká, defekt není, protože výpis není úplný popis chování: má-li cinknutí oporu v položce Mimo s pokračováním ano, je to návrat k této věci a zapíše se odkaz na položku; nemá-li oporu nikde, zapíše se jako nález k potvrzení. Neurčeno děj nesmí rozhodnout mlčky; kde se ho dotkne, je to nález a vzniká otázka.

Posuzuje se po úsecích z kroku 2: nález patří k cinknutí, v jehož úseku leží věta, které se týká.

Krok 5. Zápis toho, co nelze rozhodnout. Varianty, otevřená místa a otázky jdou k product ownerovi. Do textu Use Case Epicu se nic nedoplňuje potichu; oprava se nabízí jako návrh vedle textu, s pravidlem, ze kterého plyne.

Výstupy

• Seznam účastníků Epicu s rozhodnutím, kde žijí, a s doloženým průchodem Zákona (informace, věty, zdroj).
• Use Case Epic s vyznačenými cinknutími systému a s úseky kolem nich.
• Seznam identifikovaných Use Case 1. druhu, každý s názvem podle užitku a s oporou ve výpisu požadavků (Funkční požadavky, kterých se dotýká, položka Mimo s pokračováním ano, nebo bez opory).
• Posouzení korektnosti: defekty s pravidlem, které je určilo, doporučení, nálezy; ke každému návrh opravy jako návrh.
• Otázky a varianty pro product ownera.

Rozklad procesů, priority a Use Case Story jsou výstupy další části postupu.

Indikátory dokončení

• Každý účastník Epicu je vyjmenovaný a má právě jedno rozhodnutí, kde žije; nevíme má otázku.
• Každá věta Use Case Epicu je projitá a každé cinknutí systému má svůj úsek a svůj Use Case 1. druhu pojmenovaný užitkem.
• Nic z Use Case Epicu se neztratilo: každá věta je projitá a u každé je zapsáno, zda nese cinknutí.
• Každé cinknutí má zapsanou oporu ve výpisu požadavků, nebo je zapsané jako nález k potvrzení.
• Zákon zachování informace je ověřený u každého účastníka a každé informace, se kterou v ději jedná, a průchod je zapsaný; anonymita klienta u každého údaje, který přichází z okolí.
• Otázky pro product ownera jsou zapsané a text Use Case Epicu je beze změny.

Diagram Postupu

TBD

Nejčastější chyby

• Skryté cinknutí. Analytik tvrdí, že Use Case je „schovaný uvnitř" věty, která ho neobsahuje. Cinknutí je jen tam, kde se okolí na systém skutečně obrací.
• Tiché doplnění. Analytik opraví děj a vydá opravu za součást vyprávění product ownera. Oprava je vždy návrh vedle textu.
• Střípkování. Use Case vznikne z jednoho kroku scénáře („zadání kódu"). Use Case 1. druhu drží celý úsek od rovnováhy do rovnováhy.
• Nepokrytí Funkčního požadavku hlášené jako díra. Funkční požadavek, kterého se v Epicu nedotkne žádné cinknutí, není nález: může patřit jinému Chodu, může být realizovaný uvnitř scénáře nebo ve struktuře modelu, nebo je to omezení. Z HLA se rozhoduje jen rozpor.
• Jen šťastný průběh. Use Case Epic popisuje jen průběh, kdy vše vyjde, a návrh se spoléhá, že ostatní situace nenastanou (Anonymita klienta, cesta 2). Anonymní klient se ale zachová jakkoli; větve mimo šťastný průběh jsou součást děje.
• Otevírání vnitřku Use Case v HLA. V HLA je jen název a užitek Use Case; scénář je LLA.
• Diagram bez textu. Zdrojem pravdy je text; diagram je jeho projekce.
• Pojem Actor. V AAF se říká prvek z okolí; v textu děje obsluha nebo název prvku.

Vazby

Postup stojí na Use Case 1. druhu (šablona děje od rovnováhy k rovnováze, cinknutí systému) a na Prvky HLA (Use Case Epic, Use Case Story, Atomický proces, Rozklad procesů). První se určuje Zlatý klíčový proces. Vstupem je výpis požadavků z kapitoly Zadávací dokumentace a její zpracování; položka Mimo s pokračováním ano tam má obecné pravidlo, které tento postup naplňuje. Korektnost děje se posuzuje podle Udržení konzistence UCM, Zákon zachování informace a podle Anonymity klienta z Objektového paradigmatu. Architektura, do níž HLA patří, je Architektura BPM-UCM-CLM. Na HLA navazuje LLA (Principy scénáře UC, slovní programování; Scenario Patterns, UC 2. druhu). Druhým agilním postupem, nabalováním řešení, je AAF agilní přístup, Increments Widening.

Verze a změny

• 2.4 — Nový krok 1 Účastníci Epicu a kde žijí: analytik před hledáním cinknutí vyjmenuje účastníky (náš systém a prvky z okolí) a u každého jednou za Epic rozhodne, zda žije uvnitř, venku, nebo to neví; homonymum v zadání je chyba autora Epicu a hlásí se jako otázka. Zákon zachování informace se v kroku 4 posuzuje pro každého účastníka zvlášť, v kontextu věty, a průchod se dokládá ve výstupu. Kroky přečíslovány na pět. Podnětem byl druhý běh varianty 2 na MTP, kde model diváka jako účastníka přeskočil a správný nález z prvního běhu (divák platí kódem, který se neměl jak dozvědět) se neopakoval.
• 2.3 — Krok 1 doplněn o parsování textu na úseky: kolem každého cinknutí se vymezí úsek od narušení rovnováhy po její obnovení podle šablony děje Use Case 1. druhu; úseky se nepřekrývají, každý má právě jedno cinknutí, věty mimo úseky jsou děj okolí. Posouzení v kroku 3 se dělá po úsecích. Dotčené Neurčeno je nález s otázkou. Podnětem byly první tři běhy cinkání na MTP: nález ke kroku děje ležel v sousední větě cinknutí a bez úseku nebylo k čemu ho přiřadit.
• 2.2 — Pokrytí Funkčních požadavků se v HLA nerozhoduje. Funkční požadavek má svůj obraz v analytickém modelu, ale ne nutně na hranici: v cinknutí a Use Case 1. druhu, uvnitř scénáře (algoritmus, výpočet), ve struktuře Class Modelu, nebo jako omezení. HLA u Use Case jen zapisuje, kterých Funkčních požadavků se dotýká, a ověřuje rozpor. Vypuštěn výsledek mezera (nepokrytý Funkční požadavek), který verze 2.0 převzala z červnových skillů a který u jednoho Chodu hlásil jako díru i schopnosti jiných Chodů a omezení. Indikátor dokončení nahrazen: nic z Use Case Epicu se neztratilo.
• 2.1 — Krok 3 sladěn s Objektovým paradigmatem 1.3: čtyři cesty Anonymity klienta (nekontrolovaný vstup, opomenuté větve mimo šťastný průběh, delegace vlastní garance ven, předčasné vynoření); opomenuté větve už nejsou součást nekontrolovaného vstupu.
• 2.0 — Přepis postupu v rozsahu hledání cinknutí a posouzení jednoho Use Case Epicu: vstupy (Use Case Epic, výpis požadavků se všemi čtyřmi výsledky, předmět systému), čtyři kroky (hledání cinknutí, pojmenování Use Case 1. druhu, posouzení korektnosti Zákonem zachování informace, Anonymitou klienta a souladem s výpisem požadavků, zápis toho, co nelze rozhodnout), výstupy, indikátory dokončení. Nové pravidlo pro cinknutí bez Funkčního požadavku: opora v položce Mimo s pokračováním ano je návrat k věci, bez opory je to nález k potvrzení, ne defekt. Kroky jsou psané jako popis činnosti analytika v oznamovacím způsobu; rozkazovací způsob patří skillům. Zkratka PO nahrazena plným názvem product owner; z human doc vypuštěna zmínka o AI u diagramu. Rozklad procesů, priority a detailizace odloženy do další verze. Podnětem byla kapitola HLA na MTP (tři varianty Chodu procesu platby za lístky).
• 1.1 — Pojem Technologický požadavek přejmenován na Nefunkční a technologický požadavek podle kapitoly Zadávací dokumentace a její zpracování ve verzi 4.0; vypuštěno tvrzení, že jeho část je zdrojem větvení, protože co větví, je Funkční požadavek. Postup jinak zastaralý, čeká na přepis HLA.
• 1.0 — Zavedení postupu parsování Use Case Epic → Use Case Stories (kotva cinknutí, iterace, guardraily).