Konektor na Enterprise Architect

Poznámka na úvod: Naši analytici i školitelé mají s Enterprise Architect mnohaleté zkušenosti. Nástroj používáme velmi pravidelně. Ale právě proto víme, že se rozhodně nejedná o nástroj, který bychom chtěli v projektovém týmu učit každého.

Pro koho není Enterprise Architect

Kdo dle našich zkušenosti nebude chtít s Enterprise Architect pracovat:

• Zadavatelé požadavků Lidé, kteří v týmu vytvářejí nápady. Je nezbytné, aby požadavky mohli zadavatelé snadno zapsat, přiložit soubory, revidovat je a spravovat verze. Nechtějí ale modelovat. Chtějí u požadavků diskutovat, vidět souvislosti, rozhodovat, který dělat a který ne. Ale jsou zvyklí přemýšlet nad svými požadavky a to v takové podobě v jaké je sepsali.
• Autoři testů a testeři Enterprise Architect poskytuje sice nástroje pro tvorbu testů, ale jejich používání je nejenom nepohodlné, ale nesplňuje ani nezbytné nároky na řádnou dokumentaci testování.
• Vedoucí projektu Stejně jako pro testování, i pro projektové řízení obsahuje Enterprise Architect nástroje, ale jsou spíše teoretické. Neumožňují efektivní řízení prací, neposkytují dobrý přehled, o stavu plnění úkolů a úkoly není možné integrovat s dalšími činnostmi – např. je zařadit na poradu.
• Manažer bezpečnosti (Safety manager) musí mít perfektní přehled o tom, které požadavky jsou bezpečnostní, jak jsou analyzovány a splněny. Z jeho pohledu nepřichází v úvahu, aby požadavky bylo možné po schválení měnit, nebo jinak upravit, co bylo schváleno. Enterprise Architect na to není připraven a s řešením projektu v souladu s přísnými metodikami jako ISO 26262 se ani nepočítalo.
• Manažer kvality je na tom podobně, jako manažer bezpečnosti. Musí mít možnost řídit revize, kontrolovat spolupráci, schvalování a rozhodování. Nic z toho nesouvisí s modelováním a přehlednost informací, které je možné v Enterprise Architect uchovávat, skutečnou dokumentaci průběhu zpracování nepodporuje.

Ať už musíte dodržovat nějakou metodiku (např. i PMBOK ale zejména standardy jako CMMI, Automotive SPICE apod.), nebo vám prostě záleží na tom, abyste projekt vedli pořádně, potřebujete podporu pro řízení všech informací a činností.

Podpora modelování

Analytické informace o produktech i službách je možné modelovat v Enterprise Architect s využitím:

• SysML jazyka pro modelování systémů. SysML je určen pro systémové modelování a je důležitou součástí metodiky práce podle ISO 26262 nebo Automotive SPICE
• ArchiMate jazyka pro modelování business služeb, procesů. ArchiMate je užíván pro modely enterprise architektury a jeho podpora slouží zejména pro oblast obchodních modelů a návrhu informačních systémů.
  AyMINE podporuje synchronizaci dat, takže modely jsou provázané s dokumentací produktů v SysML i AyMINE. Není proto nutné nic do Enterprise Architect přepisovat ani ručně importovat.

Konfigurační řízení

Konfigurační řízení vyžaduje, abyste mohli vybranou část dokumentace – tedy i části analytického modelu – vzít, vložit do konfiguračního balíku, a zamknout. Současně ale vložené objekty musí zůstat součástí celé dokumentace propojeny vazbami, které při analýze vznikly

Konfigurační řízení je velmi účinným nástrojem kontroly projektu, ale jenom tehdy, když je dobře implementováno a podpořeno systémovým zabezpečením, které kontroluje, že:

• Nikdo nemůže upravit objekty, které jsou v konfiguračním balíku vloženy
• U každého objektu je okamžitě zřejmé, zda je součástí nějakého balíku a zda je zamčený

Změnové řízení

S konfiguračním řízením úzce souvisí i změnové řízení. Musí umožnit řídit změny objektů, které byly zpracovány, a jsou vloženy do nějakého balíku.

Konfigurační řízení musí umožňovat vytvářet nové verze např. uzamčených požadavků, služeb nebo produktů.

Revize

Efektivní revize vyžadují, abyste mohli jakýkoli objekt, který je třeba revidovat – nejenom požadavek, ale třeba i službu, popis rozhraní apod. – s někým projít, nebo poslat k připomínkování. Všechny připomínky se hodí schovávat a mít možnost vést i diskuzi.

Zadávání úkolů v souladu se směrnicí / metodikou projektového řízení

Nestačí vytvářet úkoly lidem. Je třeba kvalitně definovat, co se má skutečně udělat. To nebude nikdo chtít opakovaně popisovat a jedinou správnou cestou proto je, aby úkoly rovnou obsahovaly zadání, které vyplývá z předepsaných postupů. To umí AyMINE, ale nic podobného v Enterprise Architect není.

U většiny z uvedených potřeb je možné nalézt způsob, jak to "nějak udělat". Ale z vlastní zkušenosti víme, že to "nějak" bude nekvalitní, nepohodlné, a tedy také nepoužívané.

Confluence i Jira jsou hojně používány pro správu požadavků a modelování. Přesto ve chvíli, kdy potřebujete spolupracovat na analýze a modelování, nevyhovují potřebám, které projekty vyžadují.

Confulence není nástrojem spolupráce

Conflunce je nástrojem, který řada týmů používá jako cestu, jak analýzy dostat z Enterprise Architect ven. Confluence je využíván na zpřístupnění dokumentace, ale ne jako efektivní nástroje spolupráce a tvorby požadaveků.

Do Confulence firmy exportují hotový popis, AyMINE naproti tomu je typicky prvním místem, kde zadání vzniká. Teprve pak se dostane do Enterprise Architect. Může to být i naopak – návrh z Enterprise Architect se v rámci AyMINE reviduje, spravuje verze a sdílí. Vedle AyMINE s modelem pracuje analytik v Enterprise Architect. Confulence na tokovou integraci není stavěný.

Důležitou možností Confulence je možnost vystavit část analýzy formou dokumentu na stránce. Jedním z důvodů pro to je možnost na dokument odkazovat, druhým jeho zpřístupnění širší skupině osob. AyMINE podporuje obojí. Dokumenty je možné vystavit na nástěnce, která je buď veřejná, nebo dostupná jenom vybraným lidem. Interně v AyMINE je možné dokumentaci dlouhodobě uchovávat a to včetně schémat.

Příkladem dostupné dokumentace exportované z AyMINE je nástěnka o změnách v AyMINE. Druhým příkladem dostupné dokumentace je samotná technická dokumentace
AyMINE.

Jira nepracuje s modelem

Jira je propracovaným nástroje pro správu požadavků, resp. „Stories“. Silná podpora pro agilní vývoj a práci s dashboardem je důvodem, proč ji mají týmy rády. Jira ale nepracuje s komplexním modelem např. v ArchiMAte nebo SysML. Není ani určena pro dlouhodobou archivaci důležitých poznámek z revizí, souvislostí mezi jednotlivými částmi modelu a propojením s konfiguračním řízením. Tyto procesní nástroje agilní vývoj standardně nevyužívá, ale vedení rozsáhlejšího projektu je vyžaduje.
Jira se v projektech často používá ostrůvkovitě, pro část projektu, nejčastěji vývoj softwarové částí. AyMINE
naproti tomu je nástrojem, který projekt vede od okamžiku jeho vzniku a drží dokumentaci nejenom řešení, ale i
celého průběhu zpracování např. pro potřeby auditorů.

Poznámka k ochranným známkám: Confluence i Jira jsou produkty a ochranné známy společnosti Atlassian. S tímto dokumentem nemá společnost Atlassian nic společného. Srovnání zde uvedné vyplývá ze zkušeností firmy PDQM z konzultací a zkušeností, jak týmy produkty Enterprise Architect, Confulence a Jira využívají.