Při čtení článku na serveru Lupa.cz
Pracovali jsme i na Štědrý den, ale stejně jsme za blbce…
se mi vybavila velmi známá situace: Jak vypadá projekt vývoje IS řízený nedoporučovanou anti-metodikou Tunel.
O tom je tento článek.
Jeden z účastníků školení Čtvrtletní kurz profesního růstu analytika vznesl následující dotaz týkající rozkladu procesů v BPMN alias procesní mapy: “Jde mi o to, jak v EA vyrobit diagram Strom rozkladu procesů tak, aby sdílel elementy s diagramem Chod procesu. Nyní mám problém, že v Project Browseru vzniká resp. zaniká strom dle toho, který z diagramů právě upravuji. Vysvětluji v dalším textu…” Na toto téma je následující článek
Účastnici e-kurzu Čtvrtletní vzdělávací program profesního růstu analytika dostali za úkol vytvořit Use Case Diagram na základě zadání. Ve výsledném diagramu figurovalo vícero prvků typu Actor a některé z nich jako externí systémy. Ze zadání a následně za scénáře případu užití bylo zřejmé, že tyto prvky Actor se v algoritmu scénáře použijí v určitém pořadí.
Jeden z účastníků vznesl dotaz, zda lze nějak toto pořadí použití znázornit v UC Diagramu, když ho známe.
Odpověď zněla: Nebývá to zvykem, protože smysl a poslání prvků typu Actor v UC Diagramu je jiné, než ukázat jejich pořadí použití ve scénáři. Prvky typu Actor pomáhají zejména v tom, abychom nalezli všechny interakce “okolí versus systém”. Jedná se tedy hlavně o dobré analytické vodítko pro nalezení interfaců, které se následně řeší až do technologie komunikace vůči okolí. Pokud ale chcete, dá se v Use Case Diagramu použití prvků typu Actor ve scénáři znázornit i s daným pořadím.
Tento článek pojednává možnosti, jak znázornit pořadí prvků typu Actor (resp. analogicky jak znázornit pořadí interakcí include).
Na podzim 2020 byl spuštěn Čtvrtletní vzdělávací program profesního růstu analytika a setkal se s velice příznivým ohlasem. V tomto článku můžete získat seznam studijních materiálů k tomuto kurzu, které jsou zdarma.
Znáte to: Analytici se hodně snaží, ale nasazený systém se díky dalším změnám postupně vzdaluje od původní analýzy. Každý systém tak z pohledu analýzy stárne a jde jen o to, jak rychle… Realizovaný kód nakonec nemusí odpovídat analytické dokumentaci a díky tomu tým padá zpět do chaotického vývoje, jako by analýza ani nebyla…
Jak tomuto samovolnému posunu „realizovaný kód versus analýza“ co nejvíce zabránit anebo aspoň omezit na přípustnou mez? Možná vám v agilní technice chybí jeden sloupec TODO.
Po webináři Jak tvořit High Level Analýzu v agilních technikách (SCRUM apod.) jeden účastník vznesl tyto dvě zajímavé otázky:
Měl bych dva doplňující dotazy ke vztahu UML a SCRUMu:
Zdravím, L. K.
Tento článek odpovídá na obě otázky.
K tomuto článku mne inspiroval jeden komentář k předešlému článku, evidentně od programátora.
Tento článek navazuje na předešlé 2 články o číselnících a uvedeme si v něm praktické příklady týkající se této agendy.
Poznámka: Tento článek vyšel také jako doprovodný text ke stejnojmennému školení
Pokud řešíte nějaký problém, tak je opravdu velice výhodné, když znáte předem řešení. O tom jsou obecně vzory v návrhu SW. Vzor totiž není nic jiného, než aplikace opětovné použitelnosti na řešení problémů. Obecně lze vzor v návrhu SW (a nejen v návrhu SW) definovat takto:
Vzor je opětovně použitelné řešení na opakující se problém.
V předešlém článku jsme se zabývali možnými řešeními agendy zvané jako „číselníky“ alias „kódovníky“. Ukázali jsme si tři možná řešení s různými variantami posunu meta. V tomto článku navážeme na předešlý článek dalšími úvahami a doufám, že (podobně jako minule) také dalšími příspěvky v diskusi.