Vývoj informačních systémů Implementace IS Vývoj informačních systémů

Fáze implementace IS Úvodní studie („studie proveditelnosti“) Globální analýza a návrh Detailní analýza („funkční specifikace“) Vývoj IS a testování Samotná implementace – zavedení, školení, manuály Uvedení do provozu + zkušební doba, testování Provoz – záruční servis Provoz – pozáruční servis, technická podpora

Studie proveditelnosti Cílem úvodní studie je posoudit, zda za peníze, které jsou k dispozici a v daném čase, je vůbec možné požadovanou funkcionalitu zajistit. Tedy, zda se projekt vůbec vyplatí a zda je technicky realizovatelný.

Globální analýza V globální analýze se snažíme postihnout koncepci celého projektu, vytvořit jeho globální architekturu. Součástí této fáze je také návrh technických a softwarových prostředků, technologické architektury, odhad nároků na SW apod.

Funkční specifikace Funkční specifikace (=detailní analýza) se zabývá konkrétním řešením informačního systému V této fázi provádíme analýzu pracovních činností, sběru informací, požadovaných výstupů.

(pokrač.) Součástí bývá návrh datového modelu nebo tzv. funkční specifikace (pokud možno přesný popis funkcí, které by měl systém umět). Někdy je tento dokument rozpracován až do návrhu jednotlivých obrazovek uživatelského interface.

Vývoj IS a testování Vlastní vývoj IS je záležitost pro profesionální týmy Je vhodné vývoj řídit s využitím některé z existujících metodik Podcenění analytické fáze se může projevit právě v této fázi zvýšenou pracností nebo dokonce nemožností úspěšně projekt dokončit

Zbývající fáze Zbývající fáze: se řídí zněním dodavatelské smlouvy Zavedení, školení, manuály Uvedení do provozu + zkušební doba, testování Provoz – záruční servis Provoz – pozáruční servis, technická podpora se řídí zněním dodavatelské smlouvy

Pohled účetního Výdaje na pořízení IS se často strukturují takto: HW SW Pracovníci Servis HW Vývoj aplikačního SW Údržba SW Komunikační služby Zpracování agend Režie (energie, nájmy, platy administrativy, …)

Na kolik vlastně IS přijde? Total Costs of Ownership (TCO) zahrnují: Investice Technická podpora Řízení (administrativa) Činnost koncového uživatele

Vyplatí se IS? ROI znamená návratnost investic a počítá se ze vztahu: ROI = výnosy / investice * 100 [%] Pokud je ROI = 100 %, výnosy plně pokryly investice. Pokud je ROI > 100 %, projekt generuje zisk. Pokud je ROI < 100 %, je projekt ve ztrátě.

Aktuální trendy K aktuálním trendům v oblasti informačních systémů patří: využití technologie cloudu, implementace podpory sociálních sítí (typicky do takzvaných sociálních CRM), Business Intelligence, která má být dostupná co nejširšímu okruhu uživatelů, zajištění mobilního přístupu k informačním systémům.

(pokrač.) V tuzemsku je dalším významným trendem i snaha o větší integraci podnikových informačních systémů s dalšími subsystémy v rámci podnikového IT.

Moderní architektury… …jsou vícevrstvé Důvody: Rozložení výkonu HW Škálovatelnost Tvorbu a údržbu jde snadněji rozdělit mezi tým

Architektura klient/server (1) Jedná se o architekturu, kde je aplikace rozdělena mezi klientskou a serverovou část. Rozložení aplikace na více míst je výhodné kvůli škálovatelnosti. Můžeme rozložit výkon na více serverů. Na serveru se soustředí data a služby centrální pro celou aplikaci. Nevýhodou je síťová komunikace navíc mezi klientem a serverem, která zpomaluje aplikaci.

Architektura klient/server (2) Klient požaduje po serveru služby, které server zpracovává a případně odešle zpět klientovi. Na klientovi může běžet program v grafickém prostředí GUI nebo třeba ve webovém prohlížeči.

Server Server obsluhuje požadavky od klientů a vrací jim případně nějakou odezvu, přistupuje na databázi a další zdroje, provádí aplikační logiku nebo volá služby dalších serverů. Existuje mnoho typů serverů jako například: souborový , mailový , webový , databázový , aplikační a mnoho dalších. Klient i server mohou běžet i na stejném počítači.

Druhy klientů Rozeznáváme dva hlavní druhy klientů: tenký klient - Stará se primárně o zobrazování dat, neprobíhá na něm žádná nebo téměř žádná aplikační logika. Často to bývá webový prohlížeč, i když ten má svá specifika viz dále. tlustý klient - Obsahuje prezentační část a navíc i aplikační logiku a dotazuje se většinou na databázový server nebo jiný server.

Webový prohlížeč Webový prohlížeč je speciálním typem tenkého klienta. Používá pro grafické uživatelské rozhraní (GUI) jazyk HTML a CSS. Nenabízí tak bohaté GUI jako nějaký desktopový klient a také je závislý na bezestavovém HTTP protokolu, tj. pracuje na bázi požadavek/odpověď (request/response) a nemá informaci o historii komunikace. Proto se používají cookies nebo URL přepisování, aby byla uchována informace o uživatelské relaci (session).

Dvouvrstvá architektura (1)

Dvouvrstvá architektura (2) Dnes již koncepčně zastaralá Většina aplikační logiky leží na klientovi Klient se dotazuje na databázi a vytváří sám SQL dotazy. Musí přizpůsobit dotazy dané databázi. V databázi pak bývá aplikační logika schována v ukládaných procedurách nebo triggerech.

Zhodnocení Nevýhodou je omezení na počet klientů, neboť je veliký přenos dat po síti. V jednodušších projektech je tato architektura výhodná pro rychlý a mnohdy jednoduší vývoj aplikace. Pokud se však musíme vyrovnat se změnami v logice aplikace, nastává problém se správou verzí a redistribucí na klienty, neboť aplikační logika aplikace není soustředěna na jednom místě a může docházet k duplicitám kódu.

Třívrstvá architektura (1)

Třívrstvá architektura (2) Přibyla prostřední vrstva, ve které se soustřeďuje aplikační logika aplikace. Klientská vrstva se nedotazuje přímo na datovou vrstvu, ale komunikuje s ní přes vrstvu prostřední. Klient se soustředí hlavně na prezentační část. Pokud klient zavolá prostřední vrstvu, ta provede výpočty business logiky nebo pošle dotaz na datovou vrstvu. Může také jako klient volat další servery prostřední vrstvy.

Třívrstvá architektura (3) Servery mohou být dotazovány i od klientů jiných aplikací a mohou být sdružovány do větších celků (clusterů). Klient nepotřebuje žádnou informaci o datovém zdroji díky odstínění, takže pokud budeme místo přístupu do databáze volat webové služby, klient se nezmění, jelikož bude volat stále stejné služby prostřední vrstvy.

Vícevrstvá architektura (1)

Vícevrstvá architektura (2) Prostřední vrstva se většinou rozděluje na více částí, a proto budeme dále mluvit o těchto aplikacích jako o vícevrstvých. Aplikační logika se může dále dělit. Prezentační vrstva se stará o dynamické vytváření uživatelského rozhraní. Vrstva business logiky obsahuje vlastní logiku aplikace. Může se dále ještě rozdělit na část zpracovávající požadavky z prezentační vrstvy a na vlastní business logiku.

Vícevrstvá architektura (3) Business logika provádí výpočty a transformuje data z datové vrstvy. Integrační vrstva odstiňuje business vrstvu od EIS vrstvy, které se dotazujeme na vlastní data. Integrační vrstva obsahuje většinou DAO objekty (Data Access Objects, objekty pro přístup k datům)

Architektura MVC (1)

Architektura MVC (1) MVC = Model View Controller, obvykle se překládá jako Data-Prezentace-Řadič Je to dost často používaná architektura aplikace Cílem tohoto vzoru je oddělení prezentační části, řídící části aplikace a datového modelu poprvé se objevila v jazyce Smalltalk pro návrh uživatelského rozhraní. Rozhraní Java Swing je postaveno na základě MVC vzoru.

Architektura MVC (2) Rozděluje komponenty pro postavení uživatelského rozhraní do tří skupin, a tím zajišťuje jasné rozdělení působnosti objektů. Model - Data - Reprezentuje aplikační data (stav aplikace) a funkční logiku. View - Prezentace, Pohled - Zajišťuje zobrazování dat modelu na výstup. Je to jediná část, se kterou uživatel přímo komunikuje. Controller - Řadič - Reaguje na uživatelské vstupy a mění data modelu podle těchto vstupů nebo manipuluje s view.

MVC vzor (1) Když uživatel provede nějakou interakci s uživatelským rozhraním ve View, jsou odeslány události řadiči nebo více řadičům. Pokud událost požaduje změnu modelu, řadič manipuluje s daty modelu nebo volá nějaké funkce aplikace. Událost také může požadovat změny uživatelských komponent ve View. Řadič může s těmito uživatelskými komponentami přímo manipulovat, vytvářet nové nebo je mazat (skrývat).

MVC vzor (2) View neprovádí přímo změny v modelu, zato zobrazuje data z modelu a může požadovat po modelu další data pomocí dotazů. Model posílá informace o změnách View a Controlleru, které jsou registrované v Modelu podle návrhového vzoru Observer. Díky mechanismu posílání zpráv jsou View a Controller volně vázané (loosely coupled) a můžeme použít více různých pohledů i v jedné uživatelské relaci.

Zprávy v MVC (1) Existují dvě možnosti přístupu k posílání zpráv v rámci MVC vzoru. Push model znamená, že model "tlačí" (pushes) oznámení o změně posluchačům (listeners), které jsou typicky komponenty View. Jako příklad může posloužit komponenta JList a ListDataListener, který je registrován u ListModel a mění zobrazovaná data po přijetí událostí od modelu.

Zprávy v MVC (2) Druhý model je použit u webových aplikací kvůli tomu, že se stránky generují až na požadavek uživatele a model nemůže posílat žádné notifikace pohledu. Pull model znamená, že komponenty pohledu mají přístup k modelu a vytahují (pulls) data podle potřeby při generování dynamických stránek.

… a to už je opravdu konec.