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
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.
V předešlém článku bylo vysvětleno, jak se mají správně chápat případy užití prvního druhu. V definici těchto případů užití sehrává svou velmi důležitou roli stav nečinnosti, který jsme nazvali jako IDLE stav. V této části si vysvětlíme, k jakým základním až fatálním chybám dochází, pokud se tento stav opomíjí a když se hledání případů užití neprovádí korektním způsobem (i s příkladem).
Je vcelku zřejmé, že pokud mají vývojáři odevzdat dobrý a pokud možno bezchybně fungující informační systém, tak se soustředí v prvé řadě na to, co má tento systém dělat. Věnují se tomu, jak mají vypadat algoritmy programu, jak se má program chovat, co má dělat – a to na začátku na logické a analytické úrovni a poté až po návrh výsledného kódu. Vývojáři jsou tedy vcelku pochopitelně zaměřeni na systém v jeho činnosti, tedy na to, co se děje, když program běží
“Programátoři programují systém a uživatel jej pak použije…” To se může jevit jako úplná samozřejmost (od toho přece programátoři v týmu jsou), takže otázka zní: Proč se tím vlastně zabýváme?
V předešlém článku (viz zde) byl popsán rozdíl mezi prvky typu User Story (zavedené v agilních technikách vývoje) a prvky typu Use Case (zavedené v UML). Současně byl také vysvětlen jejich přímý vztah v souvislosti s vývojem IS.
Následující článek má za cíl ukázat, jak lze rychle a efektivně vyhledávat případy užití procesní školou (BPMN 2.0). Navíc poslouží také jako dobrý příklad na použití prvku v BPMN 2.0 zvaného Parallel Gateway.