1 / 73

Ž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.

Download Presentation

Životní cyklus aplikací podnikové informatiky

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Ž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

  2. Úč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.

  3. 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.

  4. 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

  5. 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.

  6. Životní cyklus aplikace

  7. 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.

  8. 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.

  9. 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.

  10. 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.

  11. 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.

  12. 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.

  13. 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.

  14. 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.

  15. 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í.

  16. 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

  17. 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. .

  18. 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ů.

  19. 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 po­ptá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.

  20. 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.

  21. 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.

  22. 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.

  23. 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í.

  24. 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.

  25. 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.

  26. 11.2 Analýza a návrh aplikace

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

  28. 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).

  29. 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.

  30. 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ů.

  31. 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.

  32. 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.

  33. 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í.

  34. 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.

  35. 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.

  36. 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.

  37. 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ší.

  38. 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,

  39. 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.

  40. 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.

  41. 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.

  42. 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.

  43. 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ů.

  44. 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í.

  45. 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.

More Related