Metodika analýzy Příloha č. 1
Příloha č. 1 1 Účel dokumentu Dokument popisuje závaznou metodiku systémové analýzy, je upraven na míru pro prostředí Podniku. Dokument je provázán s Podnikovou analýzou, z které vychází. Dokument je závazný pro pracovní pozici IT analytik, příp. IT architekt. Popisuje závazná pravidla při systémové analýze informačního systému s důrazem na: potřeby podniku / zaměstnanců realizovatelnost projektu úspěšnost projektu komunikaci informovanost veřejnou správu 1.1 Aplikovatelnost dokumentu Cílem dokumentu je standardizovat obecné přístupy k systémové analýze tak, aby bylo dosaženo: maximálního uživatelského komfortu naplnění veškerých požadované funkcionalit IS zabezpečení podnikových procesů provozovatelnosti IS budoucího rozvoje IS optimálního využití lidských a finančních zdrojů Dokument je považován za živý a může být během realizace projektu kdykoliv změněn. Měl by vždy odrážet aktuální potřeby Podniku a možnosti organizační struktury IT části Podniku. 1.2 Návaznost na IT architekturu Podniku Metodika respektuje stávající business, aplikační, datovou i technologickou architekturu zavedenou v Podniku. Současně je provázána s aktuálními technologickými standardy v oblasti Podnikové architektury. Jednotlivé uživatelské požadavky projektu musí vždy korespondovat s Podnikovou IT architekturou a musí být schválené IT architektem. Nesmí docházet k realizaci uživatelských požadavků bez přímé účasti IT architekta. 1
1.3 Návaznost na business analýzu Jednotlivé funkcionality systému musí vycházet z uživatelských požadavků schválených business analytikem. Ve větších projektech je nutné vycházet přímo z mandatorního dokumentu analýza požadavků. Bez podpory business analytika může být systémová analýza nekompletní. To samé platí naopak. Bez podpory IT architekta/analytika nelze dodávat vhodné IT služby. 2 Typy Podnikové analýzy V Podniku lze identifikovat tři druhy analýzy informačních systémů. První a nejdůležitější typ analýzy je určen pro velké projekty. Jedná se o předprojektovou analýzu pro zadávací dokumentaci výběrového řízení. Druhý typ analýzy je spojen s RAD vývojem. Tento přístup je vhodný pro malé projekty a analýza je spojena částečně s agilním přístupem. Poslední typ analýzy slouží pro tvorbu aktuální dokumentace k informačním systémům. Obrázek č. 1 - typy podnikové analýzy Větvení jednotlivých analytických směrů určuje dle typu Podnikových požadavků vedení IT, spolu s IT architektem. Obecně lze konstatovat, že většina požadavků, které nemají dopady na okolí podniku s pracností do 30MD (analýza a vývoj) je realizována agilním přístupem (malý projekt). Analýza stávajících systému se provádí při provozním problémech, případně při volné pracovní kapacitě IT analytika. Zbývá oficiální projekt schvalovaný ŘaMV. Postup při oficiálním podnikovém projektu je definován a popsán interními pravidly Podniku. Níže jsou popsány jednotlivé druhy podnikové analýzy a zvýrazněné úkoly a povinná témata pro IT analytika / IT architekta. Uvedené bodu musí být povinnou součástí zmíněných analytických artefaktů. 2
3 Analýza pro výběrové řízení První typ analýzy vychází z potřeby specifikace zadání pro veřejné výběrové řízení. Analýza má charakter plně vodopádového přístupu k vývoji SW. Mimo rozsah ZD nelze specifikovat žádné další požadavky. Nelze použít inkrementální přístup vývoje softwarového řešení. Metodika pro popisovaný průběh analýzy vychází z interních pravidel Podniku pro řízení projektů. 3.1 Vize Obrázek č. 2 - předprojektová analýza Specifikace předběžného návrh systému je nutné popsat v dokumentu Vize. IT analytik/architekt by měl v krátkosti doplnit do dokumentu předběžný návrh systému. Pokud to jde, je potřeba představit několik možných variant řešením včetně nulové varianty. Především vizi koncepce systému, seznam použitých platforem a komponent systému, tedy nastínění aplikační architektury. Dále musí být zmíněn výčet hlavních vstupních a výstupních kanálů systému. Pokud budou migrovány data, tak informace o migraci dat. Dokument by měl končit odhadem pracnosti v MD, případně požadavky na SW licence a autorská práva. Výše uvedené požadavky jsou mandatorní. IT analytik může dále spolupracovat na popisu stávajícího stavu, předběžné analýze uživatelských požadavků a manažerském shrnutí. 3.2 Studie proveditelnosti Studie proveditelnosti je hlavní podklad pro rozhodnutí zdali projekt realizovat, či ne. Dokument musí, na rozdíl na dokumentu vize jasně vyjadřovat přesné a měřitelné fakta. Vstupem pro tento dokument je dokument vize zmíněný v předešlé kapitole. IT analytik/architekt přispívá do dokumentu hlavně v sekci architektura systému. Popisuje varianty řešení, pokut má smysl tyto varianty uvádět. U vybraných řešení popisuje konkrétní podobu architektury systému. Velký důraz je potřeba věnovat nefunkčním požadavkům. Především požadavky na potřebné alokace HW prostředků a SW licencí. Nutno definuje způsob využití integrační platformy pro požadované integrace. Jednotlivé integrace musí být popsané v plném rozsahu, hlavně z pohledu dopadu na integrované systémy. Musí být zmíněn 3
dopad projektu na jednotlivé části podniky a okolí podniku. Jednotlivé varianty obchodních případů by měly být porovnatelné z hlediska financí a jiných požadavků na zdroje. Během tvorby dokumenty by měl být kladen důraz na vysokou míru vizuálních prvků, např. UML diagramy v nejjednodušší podobě. IT analytik/architekt může spolupracovat na popisu stávajícího stavu, funkčních požadavcích, harmonogramu projektu, rizicích projektu, přínosech projektu, nárocích na IT lidské zdroje a podílet se na tvorbě prezentace pro ŘaMV. 4 Interní vývoj Druhý typ analýzy je určen pro interní vývoj v RAD nástrojích. Tento přístup a je určen především pro malé projekty. Metodika interního vývoje je založena z na agilním a RAD přístupu k vývoji a analýze. Tento přístup byl zvolen vzhledem k častým požadavkům na dodání výstupů v krátkých termínech. Dalším rozhodujícím faktorem pro volbu agilního přístupu bývají nepřesné, či nekompletní požadavky na informační systém v úvodních fázích projektu. Výstupní artefakty vycházejí z definic agilního modelování. Obrázek č. 3 analýza pro interní vývoj Analýza je založena na komunikace všech zúčastněných stran. Na úvodní schůzce s uživateli je účastníkem také programátor. Uživatelé se snaží předložit první verzi požadavků. Tyto požadavku se na schůzce mezi IT analytikem a programátorem transformují do konkrétní podoby aplikace, kterou programátor realizuje. Pokud jednotlivé dodatečné požadavky nejsou složité na implementaci, tak pokračuje v dalších iteracích programátor sám. Předpokladem pro tuto činnosti jsou alespoň průměrné komunikační schopnosti programátora a schopnost samostatné činnosti. 4.1 Analytické artefakty v RAD vývoji Většina analytických artefaktů je v agilním přístupu využívána pouze pro komunikaci. Výjimku tvoří artefakty požadované v Podniku interním auditem, ty jsou povinné. Finální dokumentace celé aplikace je dynamicky zachycena pomocí metasystému. Systém je schopen 4
automaticky evidovat změny v aplikacích, jelikož je napojen přímo na metadata jednotlivých aplikací. Typ artefaktu Povinnost Zadání Dokument ANO Class/ER Diagram Tabule NE DFD diagram Tabule NE UI prototyp Tabule NE UI Storyboards Tabule NE Scénáře užití Tabule/Dokument NE Finální dokumentace Metasystém ANO Uživatelská dokumentace Součástí aplikace ANO 4.2 Zadání Dokument zadání popisuje první verzi požadavků a návrh řešení. Zadání musí obsahovat popis problematiky, seznam aktérů, popis funkcionalit aplikace, případně pracovní toky pokud jsou požadovány. 4.3 Další povinnosti IT analytika IT analytik se dále podílí na návrhu datového modelu, návrhu jednotlivých reportů a formulářů. Dohlíží na tvorbu uživatelské dokumentace a vložení evidenci aplikační dokumentaci v metasystému. Udržuje zásobník práce programátora. Prezentuje průběžně zásobník práce u vedoucích pracovníků. Podílí se na řízení programátorů a zohledňuje jejich požadavky. 5 Stávající systémy Analýzu stávajícího systému děláme často z důvodu inovace IS, jako vstupní podklad pro přestavbu systému. Dalším důvod pro analýzu systému je tvorba aktuální dokumentace, jelikož dokumentace často k systému neexistuje, nebo je neaktuální. Pokud se během analyzování zjistí nové požadavku nebo nedostatky, tak vzniká dokument Návrh optimalizace. 5
Obrázek č. 3 - Analýza stávajícího systému Popis stávajícího systému je společná práce IT analytika a business analytika. Business analytik analyzuje podnikové procesy zakomponované v systému. IT analytik popisuje aplikační architekturu systému. Jejich vzájemná interakce přinese popis propojení í business architektury systému a aplikační architektury. 5.1 Specifikace systému IT analytik v dokumentu Specifikace systému vyplňuje následující bloky: obecný popis systému o Kontext systému o Přehled funkcí systému architektura systému o Aplikační architektura systému o Dekompozice systému o Datová architektura systému o Technologická architektura systému popis rozhraní systému nefunkční specifikace provozní parametry systému IT analytik může spolupracovat s business analytikem na identifikaci aktérů, jejich odpovědnosti a rolí. Spolupráci může IT analytik také navázat při popisu funkční specifikace, nebo popisu obchodních procesů. 5.2 Návrh optimalizace Pokud během kompletace dokumentace vzniknou nové uživatelské, nebo technické požadavky na optimalizaci systému, tak vzniká dokument Návrh optimalizace. IT analytik předkládá technické požadavky a spolupracuje na návrhu řešení krátkodobých optimalizací. Požadavky směřující do kategorie střednědobého plánování jsou v gesci IT architekta, případně vedení IT. 6
6 Glosář Zkratka VZ ZD SS ŘaMV Vize SP RAD IS Význam Veřejné výběrové řízení Zadávací dokumentace Systémová specifikace Řídící a monitorovací výbor Dokument Vize projektu Dokument Studie proveditelnosti Rapid application development Informační systém 7