Životní cyklus aplikací podnikové informatiky

Životní cyklus aplikací podnikové informatiky Adaptované z knihy (kap.11) : Pour,J., Gála,L, Šedivá, Z..: Podniková informatika, 2. Vydanie,. Grada, Praha, 2009. ISBN: 978-80-247-2615-1

Účelem této kapitoly je charakterizovat rozvoj aplikací informatiky v jednotlivých fázích, které tvoří spirálu a označuje se jako životní cyklus aplikace.

Rozvoj aplikací podnikové informatiky se řeší na základě různých metod a postupů, které se liší podle toho, zda jde o aplikaci vyvíjenou na zakázku, nebo řešenou na základě typového software, liší se podle typů aplikací, liší se i podle jednotlivých firem a jejich produktů. • Doporučené postupy řešení aplikací nebo celých informačních systémů se označují jako metodiky.

Budeme vycházet z celosvětového de facto standardu prořízení podnikové informatiky ITIL - Information Technology InfrastructureLibrary. • Proces řízení rozvoje aplikací je zde chápán jako životní cyklus aplikací. Ten zahrnuje komplex činností, které by měly být vykonány v rámci jednotlivých fází tohoto procesu

Fáze životního cyklu aplikace se člení takto: • plánování a příprava aplikace, • analýza a návrh aplikace, • implementace aplikace, • zavedení do provozu, migrace, • provoz a užití aplikace, • rozvoj a optimalizace aplikace.

Životní cyklus aplikace

11.1 Plánování a příprava aplikace • Každá nová aplikace v podnikové informatice vychází z informační strategie rozvoje podniku (kapitola 17) a zpožadavkůuživatelů na uvažovanou aplikaci. • Zatímco na začátku fáze je pouhý záměr aplikaci řešit • pak na závěr této fáze musí být jasné, zda se aplikace bude, nebo nebude realizovat, a pokud ano, pak jak, s jakými cíli, s jakou předpokládanou funkcionalitou atd. • Úlohy, které spadají do první fáze (Úlohy fáze plánování a přípravy aplikace), dokumentuje obrázek.

1.1 Vstupní analýza • Smyslem vstupní analýzy je posoudit zamýšlený projekt aplikace : • z pohledu celkové koncepce IS/ICT, resp. informační strategie podniku, • z pohledu aktuálních uživatelských požadavků na aplikaci.

1.1 Z informační strategie by mělo vyplynout : • zhodnocen í, do jaké míry navrhovaná aplikace pokrývá cíle společnosti a jej í informatiky, • jaká je její pozice v aplikační architektuře, • jak se váže na ostatní aplikace, • případně pokud některé nahrazuje, • jak zapadá do celkového harmonogramu rozvoje celého informačního systému.

1.1 • V návaznosti na vyhodnocení aplikace v rámci informační strategie se v dalším kroku provádí analýza konkrétních uživatelských požadavků na aplikaci.

1.1 Analýza uživatelských požadavků • požadavky zjistit, • dokumentovat (pokud již dříve dokumentovány nejsou) • posoudit jejich oprávněnost vzhledem k cílům a možnostem podniku • Posouzení požadavků tak sleduje nejen jejich smysluplnost vzhledem k cílům podniku, ale snaží se i odhalit jejich duplicity.

1.1 Základná technika pro zjišťování uživatelských požadavků - interview • počáteční - seznamovací workshop • jednotlivá interview, která jsou vedena s jednotlivci nebo v malých skupinkách uživatelů, • potom jejich výsledky ověřovat při větších setkáních, resp. oponenturách • Tento postup má své logické opodstatnění v tom, že např. při jednotlivých interview lze zaznamenávat dílčí názory jejich účastníků i různé nekonzistence v chápání podnikové reality • Typickým příkladem jsou nekonzistence v terminologii.

1.1 Závěr interview • Formulace priorit pro řešení projektu, tedy k formulaci, co je pro zúčastněné v řešení nejpodstatnější, resp. kde očekávají nejvýraznější efekty. • Tyto efekty mají mít, pokud je to racionální, kvantifikovatelnou podobu. • Jádrem těchto měřitelných efektů jsou ekonomické a zákaznické efekty.

1.2 Plánování projektu aplikace • Plán projektu zahrnuje všechny podstatné charakteristiky navrhované aplikace : • důvody pro řešení projektu, • cíle • očekávané náklady a efekty projektu • cílové skupiny koncových uživatelů • její základní funkcionalitu a další, • Všechny jsou obsaženy v základním dokumentu - Projektovém záměru.

1.2 Plánování projektu aplikace • Návrh plánu na řešení dané aplikace se posuzuje z několika hledisek : • především z hlediska potřeb podniku • hledisko dostupných finančních a personálních zdrojů • zhodnocení stavu ICT trhu ve vztahu k aplikaci : • to znamená které hotové aplikační software a další technologie jsou k dispozici, • které firmy je implementují, • jaká je finanční a organizační náročnost takových řešení.

1.2 Plánování projektu aplikace • Na základě projektového záměru a zjištěných informací o nabídce na trhu se přijímá rozhodnutí o přijetí, či zamítnutí projektu • V souvislosti s tím se určuje i způsob řešení : • zda bude projekt řešen vlastními kapacitami či dodavatelským způsobem, • zda se předpokládá využití typového aplikačního software nebo seprojektbude řešit individuálně podle specifických potřeb uživatele

1.3 Výběr dodavatele aplikace • V případě, že se předpokládá dodavatelský způsob řešení, pak vedení podniku musí rozhodnout, zda to bude na základě výběrového řízení či jinou formou, např. přímým výběrem dodavatele na základě vlastního průzkumu trhu. • V případě organizací veřejné správy se prakticky vždy jedná o výběrové řízení • Základní postup výběrového řízení na dodávku podnikových aplikací dokumentuje obr. .

1.3 Výběr dodavatele aplikace • Zpracování poptávkového dokumentu vychází zejména z projektového záměru. Smyslem poptávkového dokumentu je relativně přesně vymezit požadavky na aplikaci, definovat postup a organizaci výběrového řízení a současně specifikovat i požadavky na nabídky dodavatelů.

1.3 Výběr dodavatele aplikace • V návaznosti na předchozí bod dodavatelé připravují nabídky ve struktuře stanovené zadavatelem. • V průběhu přípravy nabídek dodavateli je často nezbytné zajistit ze strany zadavatele odborné konzultace k poptávkovému dokumentu a k požadavkům na řešení. • Referenční instalací dodavatele se rozumí již hotový provozovaný projekt aplikace u vybraného zákazníka,který dodavatel již realizoval a je obdobný poptávanému projektu. • Komplexní vyhodnocení zahrnuje konečné posouzení a zhodnocení předložených nabídek, referenčníchinstalací i prezentací dodavatele.

1.4Úvodní studie • Zpracování úvodní studie je účelné v případě dodavatelského způsobu řešení projektu i řešení vlastními kapacitami. Jejím smyslem je stanovit celkovou koncepci řešení v kontextu celkového rozvoje IS/ICT.

1.4Úvodní studie • přesně definovat cíle projektu • promítnout projekt do aplikační architektury IS/ICT, • jasně definovat místo projektu v této architektuře (např. které funkce projekt pokrývá a které nikoli) • definovat nároky projektu na personální, technologické i finanční zdroje.

1.4Úvodní studie • Úvodní studie obsahuje i základní specifikaci organizace projektových činností : • určení řídicího výboru projektu (ŘV), • personálního obsazení analytických, resp. aplikačních týmů, • základních principů plánování a řízení projektu, • určení pravidel komunikace pracovních týmů, • specifikaci dokumentace, • určení přístupových práv jednotlivých členů týmů k aplikacím a dokumentaci • definuje tak i organizační strukturu projektu vid. Obr.

Smlouva na celý projekt • Úvodní studie je oponována většinou ve vedení podniku, a po jejím přijetí je vstupem pro formulaci smlouvy na celý projekt a organizaci jeho řešení. • V některých případech se smlouva na celý projekt uzavírá již po ukončení výběrového řízení.

Smlouva na celý projekt • U větších projektů je však výhodnější zpracovat a uzavírat smlouvu na projekt až po přijetí úvodní studie, neboť teprve na jejím základě je možné reálněji stanovit časovou a finanční náročnost projektu, případně další podmínky řešení. • Kontraktační řízení, tj. příprava a projednání jednotlivých částí smlouvy až po její uzavření a podpis je pracovně i časově náročný proces a v některých situacích trvá i několik měsíců. • Na jeho průběhu se účastní řada specialistů z oblasti informatiky a práva a samozřejmě vedení obou stran - zákazníka i dodavatele.

Poznámky • Na závěr uvedených úloh je třeba zdůraznit, že u všech z nich je nezbytná velmi úzká kooperace uživatelů a informatiků, zejména interních informatiků. • Rozhodovací úlohy a vlastní výběr produktů a služeb jsou většinou logicky v kompetencích managementu a vlastníků firmy. • Z těchto důvodů je podstatné, aby pracovníci působící i v těchto rolích byli připraveni si udělat úplný obrázek o nabízených produktech a službách a systematicky je vyhodnotit.

11.2 Analýza a návrh aplikace

Úlohy fáze Analýza a návrh aplikace

11.2.1 Analýza podnikových procesů • Rozvoj a změny podnikových procesů se realizují buď komplexně v rámci projektu procesního reengineeringuzahrnujícího celý podnik, nebo ve vztahu k právě řešeným aplikacím • Principům procesního rozvoje a modelování je věnována kapitola 13, a proto zde je pouze zasadíme do kontextu životního cyklu aplikace. • Smyslem analýzy podnikových procesů je zjistit, jaký je současný stav řízení podniku v oblastech (prodej, nákup, výroba atd.), které má řešit plánovaná aplikace, kde jsou problémy v řízení a požadavky na jeho další rozvoj. • Rozsah analýzy se podle řešené aplikace liší - od dílčí oblasti např. řízení prodeje nebo řízení vztahu k zákazníkům (CRM) až po analýzu celého podnikového řízení odpovídající zejména celopodnikovým aplikacím (ERP).

11.2.2 Analýza stávajících databází • Analýza existujících databází zahrnuje vyhodnocení jejich obsahu, rozsahu, kvality a způsobu jejich využívání. • Např. v případě řešení ERP, vzhledem k jejich celopodnikovému charakteru, se analyzují prakticky veškeré datové zdroje a databáze. Při nasazení ERP tak dochází k výměně nebo vytvoření prakticky většiny podnikových databází. • Účelem analýzy databází je posoudit jejich stav a kvalitu pro odhad a plánování jejich migrace do nových databázových struktur (viz kapitola 11.4.3). • Migrace dat ze starých do nových databází je totiž pracovně i časově jednou z nejnáročnějších úloh v rámci fáze přípravy zavedení aplikace do provozu.

11.2.2 Analýza stávajících databází • Při řešení aplikací business intelligencemá zcela zásadní význam úloha analýzy stavu a kvality zdrojových databází, tj. databází obsahujících data, která budou pomocí datových pump (ETL) vstupovat do datových skladů, datových tržišť a následně OLAP databází. • Analýza tak zahrnuje předpokládané nároky na transformace dat z těchto aplikací. • V dalším kroku se realizuje detailní analýza kvality, tj. chybovosti, integrity a dostupnosti potřebných datových zdrojů.

11.2.3 Analýza stávajících aplikací • Potřeba zhodnocení stávajících aplikací, které se v podnikové informatice již provozují, je dána tím, že naprostá většina aplikací podnikové informatiky není izolována, ale musí být zasazena do celého informačního systému. • Řešení jejích datových a funkčních vazeb na ostatní aplikace je tedy velmi podstatnou součástí řešení. • Z této analýzy pak vyplývají nároky na integraci řešené aplikace na ostatní části, resp. aplikace v systému a vyhodnocení technologických možností této integrace, kterým se věnujeme v kapitole 16. • Další úlohy spojené s návrhem aplikace vycházejí z výsledků předchozích analýz.

11.2.4 Návrh změn podnikových procesů • Návrh změn podnikových procesů, resp. nově definovaných podnikových procesů, které má aplikace podporovat, vychází z předchozí analýzy. • úlohy procesního reengineerigujsou obvykle realizovány jako celopodnikové projekty bez přímé vazby na některou z řešených aplikací. • Úpravy procesů v souvislosti s určitou aplikací (např. s CRM nebo elektronickým podnikáním) pak mají charakter dílčích a doplňujících řešení nebo nezbytných úprav. • Pro celopodnikové projekty i zmíněné úpravy v souvislosti s jednotlivými aplikacemi se využívá metod procesního modelování, kterým se věnujeme v kapitole 13.

11.2.5 Návrh databází • Návrh dat, datových bází, jejich obsahu a organizace s využitím metod datového modelování (viz kapitola 12) se podstatně liší podle toho, zda jde o aplikace, resp. aplikační software vyvíjený na zakázku, nebo typový aplikační software. • Typový ASW má datové báze již jasně definovány, a ty umožňují většinou pouze dílčí změny např. v definici jednotlivých položek. • To se promítá i do jednotlivých typů aplikací.

11.2.6 Návrh aplikace • Cílové řešení aplikace je třeba rozdělit na dvě základní úrovně - logickou, vymezující její obsah, a fyzickou, představující již její technologické nároky. • Nejprve se zaměříme na logickou úroveň řešení, která zahrnuje zejména tyto činnosti: • Návrh funkcí a funkcionality ve strukturované formě, které má aplikace zajišťovat, a to se všemi podstatnými atributy těchto funkcí, tj. s vymezením jejich obsahu, výpočtů, vstupních a výstupních dat a případných legislativních nároků. • Specifikace obsahu podle jednotlivých programových modulů nebo nároků na kastomizaci v případě modulů typového aplikačního software.

11.2.6 Návrh aplikace • Návrh standardních výstupních informací - tištěných formulářů, jejich grafické formy, standardních textů,tiskových sestav, interních/externích výkazů. • Detailní specifikace interních vazeb i vazeb na ostatní aplikační software, ostatní databáze a technologie, tj.návrh datových rozhraní - mezi moduly ASW i k ostatním aplikačním software. • Definování potřebné technologické architektury pro aplikaci a technických konfigurací - síťové konfiguracea konfigurací jednotlivých technických prostředků. • Specifikace přístupů, přístupových práv k datům podle specifikovaných uživatelských rolí, tzn. kdo (kterárole) může která data číst, kdo zapisovat nebo rušit.

11.3 Implementace aplikace • Termínem implementace se v praxi často chápe: • zmiňovaná fáze technologické realizace aplikace, • celý postup řešení aplikace, de facto v celém jejím životním cyklu. • Implementace zahrnuje přesnou specifikaci jednotlivých programových modulů, tvorbu tzv. prototypů a následně dle konkrétního řešení variantně kastomizacefunkcí typového aplikačního software, nebo vývoj či dovývojspecializovaných, tedy nestandardních programových modulů. • To představuje již technologickou realizaci navržených řešení, kde hlavní úlohy dokumentuje obr.

11.3.1 Detailní specifikace modulů • Specifikace modulů zahrnuje u typového ASW, podle výsledků analýzy, detailní specifikaci požadovaných úprav. Patří sem : • detailní specifikace obsahu a struktury jednotlivých obrazovek, • potlačení některých polí, • změny v jejich uspořádání, • detailní specifikace obsahu a struktury požadovaných reportů, • úpravy standardních číselníků, • požadavky na úpravy kalkulací definováním výpočetních postupů a další. • V případě vývoje a dovývojezahrnuje specifikace běžné součásti zadání programových modulů : • např. strukturu komunikace, • specifikaci vstupních a výstupních datových struktur, • přesné definování jednotlivých funkcí, • výpočtů, testů a další.

11.3.2 Prototypy • Řešení s použitím prototypu se doporučuje jako cesta důkladnějšího prověření skutečných potřeb uživatelů a snížení rizika omylů při formulaci jednotlivých aplikací a funkcionality. Příprava prototypů, tj. zkušebních vzorů řešení, zahrnuje návrh datové základny pro prototyp a určení osob pro testování prototypu,

11.3.2 Prototypy • Realizace a verifikace prototypových řešení zahrnuje zejména tyto dílčí aktivity: • zpracování prototypového řešení na vzorku dat uživatele, případně na vygenerovaných datech, • prezentaci a oponenturu prototypu, • zpracování připomínek k návrhu, • zpracování protokolu k oponentuře prototypu s návrhem řešení připomínek, • promítnutí úprav do projektové dokumentace.

11.3.3 Kastomizace typového software • Kastomizacetypového software představuje již skutečné nastavení parametrů modulů podle podmínek konkrétního typového ASW, testování takto upravených modulů a dokumentaci provedených úprav.

11.3.4 Vývoje a dovývoje • Vývoje nebo dovývoje specializovaných, tedy nestandardních programových modulů zahrnují jejich: • programovou realizaci s pomocí zvolených vývojových prostředků (programovacích jazyků a dalších), • realizaci datových rozhraní k ostatním existujícím aplikacím systémů, • testování vyvíjených modulů a jejich dokumentaci.

11.3.5 Akceptační řízení • Akceptační řízení se mohou vztahovat : • k dílčím projekčním řešením • k projektu aplikace jako celku.

11.3.5 Akceptační řízení • Akceptační procedury znamenají : • přípravu a instalaci testovaných modulů, • přípravu testovacích dat odpovídajících reálné situaci informačního systému zákazníka a kontrolu dokumentace k testované funkcionalitě • adekvátní výběr pracovníků podniku pro testování, tj. pracovníků nejen odborně vybavených, ale vybavených i odpovídajícími kompetencemi pro posouzení a případné schválení testovaných řešení • Na základě průběhu testovacích procedur se zpracovávají protokoly o průběhu a výsledcích testů.

11.3.5 Akceptační řízení • Činnosti této fáze se většinou omezují na práce a kooperace uvnitř implementačních týmů, relativně menší jsou zde nároky na kooperaci s uživateli; ta se vesměs omezuje pouze na dílčí konzultace a verifikace dílčích řešení.

11.4 Příprava na zavedení do provozu, migrace • Na základě odsouhlasených akceptačních protokolů se připravuje nebo upřesňuje tzv. plán migrace, tj. postupu zavedení projektu do provozu. • Migrace a příprava provozu projektu je organizačně a pracovně vysoce náročná činnost a její strukturu dokumentuje obr.

Životní cyklus aplikací podnikové informatiky