Analýza do šuplíku

Nápad ze strany zákazníka - co udělat analýzu bez vývoje. Nejdřív všechno pěkně zanalyzujeme a pak uvidíme. Budeme mít jasno, kolik MD bude třeba. A můžeme si vybrat mezi více dodavateli vývojové části. Jde to takto udělat, nebo je v tom nějaký háček?

• Analýza morálně zastarává, mění se legislativa, procesy i technologie.
• Bez vývoje se analýza nepropojí s architekturou, designem, testy ani konfigurací.
• Bez návazného vývoje nelze posoudit návratnost ani efektivitu navržených řešení, neexistuje zpětná vazba.
• Uživatelům není co předvést.
• Analytik ztrácí motivaci, protože nevidí výsledek své analýzy.

Autorizace - naprosté základy pro analytika

Cílem autorizace je rozhodnout, zda ověřený subjekt má oprávnění vykonat určitou akci. Tj. například zda si uživatel Petr Novák může prohlédnout obsah určitého dokumentu s id b046c6c5-5d6c-479c-8918-ef4038cc1ac4.

Existují 4 základní modely autorizace:

• Role-Based (RBAC)
• Attribute-Based (ABAC)
• Relationship-Based (ReBAC)
• Policy-Based (PBAC)

Pojďme se na ně podrobněji podívat. Všechny tyto modely řeší kdo co může, ale každý jinak.

Role-Based (RBAC)

Oprávnění se řídí pomocí rolí. Takže Petr Novák si může prohlédnout obsah dokumentu, pokud má roli, která to umožňuje.

Attribute-Based (ABAC)

Oprávnění  se řídí atributy. Takže pokud 

user.id = document.creator_id 

OR document.access_list contains user.id

OR (user.role == "Administrator" AND document.confidential == False)

Relationship-Based (ReBAC)

Přístup se odvozuje ze vztahu mezi uživatelem a objektem. 

relation creator: user

relation viewer: user

permission view = creator + viewer

K danému dokumentu se pak definují vztahy

document:doc123#creator@user:jan.kral

document:doc123#viewer@user:petr.novak

user:jan.kral#role@role:administrator

Policy-Based (PBAC)

Přístup se řídí centrální sadou politik.

Dejme tomu, že budeme používat SpicyDB. Jak se do toho pustit z analytického pohledu? Tady je  kuchařka, jak do toho:

1. Začni Use Case scénáři -  cílem je získat úplný přehled oprávnění z pohledu uživatele.
2. Z Use-casů odvoď entity a vztahy. Cílem je vědět, jaké objekty existují a jaké vztahy mezi nimi bude SpiceDB spravovat.
3. Definuj oprávnění – Permission Matrix Cílem je převést business logiku na formální pravidla.
4.  Namapuj existující role (RBAC → ReBAC)
5. Navrhni SpiceDB schema. To už je práce pro developera.
6. Ověř funkčnost – Testovací scénáře. Tady se zapojí tester.
7. Popiš Governance (správa a změny).
8. Připrav migrační/integrační plán.

Externí analytik

Ve středně velkých firmách, které provozují vlastní informační systémy pro interní potřebu i pro zákazníky, je běžné, že vývoj a údržbu zajišťuje interní tým analytiků, vývojářů a testerů.

V určitých situacích však firma potřebuje realizovat rozsáhlejší projekt, který přesahuje kapacitní nebo odborné možnosti interního týmu. V takovém případě bývá přizvána externí firma – a právě zde často vznikají specifické problémy, zejména v oblasti analýzy.

Klíčoví uživatelé jsou zvyklí spolupracovat s interními analytiky, kteří firmu dobře znají – rozumí jejím procesům, historickým souvislostem i interní terminologii.

Externí analytik naopak tyto znalosti obvykle nemá. Přichází zvenčí, a proto se často ptá na věci, které se uživatelům zdají být naprostou samozřejmostí.

Z jejich pohledu pak může působit, že „neví, o čem mluví“, nebo že analýza postupuje pomalu. To vede k frustraci na obou stranách a někdy i ke ztrátě důvěry ve schopnost externího týmu dodat očekávaný výsledek.

Dopady:

• Ztráta času: opakované vysvětlování základních pojmů a procesů.
• Nedorozumění: rozdílné interpretace pojmů, dokumentů či požadavků.
• Snížená efektivita: analytici tráví více času získáváním kontextu než samotnou analýzou.
• Napětí v komunikaci: uživatelé mohou mít pocit, že musí dělat „analýzu za analytiky“.

Aby spolupráce s externími analytiky probíhala efektivně, je vhodné věnovat pozornost úvodní fázi jejich zapojení:

• Zaškolení do firemního prostředí - Představit strukturu firmy, základní procesy a hlavní informační systémy.
• Oborová a legislativní orientace - Vysvětlit klíčové regulatorní požadavky, které se týkají daného projektu nebo sektoru.
• Terminologický slovník / doménový přehled - Předat srozumitelný přehled používaných pojmů a zkratek.
• Mentor z interního týmu - Určit kontaktní osobu z interních analytiků, která externí tým provede kontextem.
• Kontrolní body kvality analýzy - Zavést pravidelné review výstupů, aby se včas zachytily nejasnosti nebo odchylky.