Projektování informačních systémů 6 Implementace projektu Doc. Mgr. Petr Suchánek, Ph.D. Doc. RNDr. Ing. Roman Šperka, Ph.D. Převzato od: Ing. Dominik Vymětal, DrSc. Zpracování cílového konceptu řešení oCíl: nNávrh architektury systému nObsahuje opodrobný popis funkcí systému (např. příklad procesní model) oArchitekturu datové základny oNávrh HW a infrastruktury oNávrh konverze dat oAktualizaci spotřeby času a zdrojů oÚdaje o množství (počty uživatelů, počty dokladů, charakteristika zákazníků, zboží , skladů, dodávek , hospodářských středisek, oBezpečnost systému, systémy oprávnění oVýstup: nSchválení architektury, časových plánů , plánu zdrojů, aktualizace harmonogramů a ceny. 2 Příklady Konica Minolta Přechod k realizaci oBez ohledu na typ metodologie se po zpracování návrhu nového řešení a následné alokaci zdrojů přechází k realizaci IS 3 > Příprava nového řešení (Realizace) oVychází z návrhu řešení vzor sales oObsahuje nNávrh a instalaci HW nInstalaci a konfiguraci standardních modulů SW nProgramování, instalaci, úpravu zákaznických modulů / programů nIterativně oVytvoření prototypů databází, obrazovek oPrověření prototypů nIterativně oVytvoření prototypů funkcí oPrověření prototypů funkcí nVytvoření základní dokumentace oZpravidla přechází do etapy akceptace 4 Architektury IS oPraktická příprava provedení vychází také z celkové architektury systému oRůzné softwarové balíky mají různou architekturu oClient – Server – v současné době základní oSOA –opakované volání služeb oAgenti – nové paradigma 5 > C/S Něco z historie oIBM System Application Architecture – metodika připojení terminálů (PC) k mainframe strojům oPůvodní architektura Mainframe není S/C, uživatel pracuje ze stanice pevně připojené k hlavnímu počítači a zasílá jednotlivé znaky nebo jejich sady přímo. oS rozvojem GUI se tato architektura přežila, ještě nyní doznívá u emulací např. na IBM AS400 oNa počátku 80. let jako označení připojení první PC do sítě oV závěru 80. let se C/S začala prosazovat oMezistav: Sdílení souborů na serverech oV průběhu 90. let v souvislosti s OO přístupem k tvorbě IS byla všeobecně přijata, a to i na velkých počítačích > C/S Definice oObecná: nClient / Server je architektura založená na tom, že klient žádá servis od serveru. oPodrobnější: nJe to síťová architektura, která odděluje procesy serveru a klienta. Každá instance klienta může na server zasílat požadavky. nExistují specifické typy serverů jako: webovské, aplikační, file servery, terminal servery, mile servery. nModerní software prakticky vždy umožňuje provoz dle architektury C/S oDalší aspekty: nC/S obvykle znamená rozdíl mezi procesy a stroji. Zpravidla je to tak, že server a klient jsou rozdílné počítače nNa druhé straně je v této architektuře dáván důraz na procesy více než na hardware. nNěkteré typické C/S aplikace: e-mail, FTP, prohlížeče > C/S definice II oCharakteristiky Serverů: nJsou „pasivní“ – (Slave) nČekají na požadavky nPo obdržení požadavku jej zpracují a zašlou odpověď oCharakteristiky Klientů: nJsou „aktivní“ – (Master) nZasílají požadavky nČekají na to až Server na požadavek odpoví oPeer to Peer Architektura nKaždý uzel nebo běžící program je současně Serverem i Klientem a oba mají stejné úkoly. oVztah k metodikám modelování systému nTato architektura může mít problém s metodikou ERA, lépe se popisuje OO metodikou, vyžaduje specifické přístupy n > Klient a jeho typy oKlient je počítač, který dostává služby od jiného počítače pře síť oKlient je i nadále široce využíván na internetu, u řady aplikací dnes dochází k využití prohlížečů jako standardních klientů oTypy klientů: n„tlustý“ (fat) klient – provádí zpracování převážné části dat sám n„tenký“ (thin) minimalizovaný klient. Má většinou za úkol provádět pouze prezentaci dat dodaných aplikačním serverem, který zajišťuje většinu zpracování. nHybridní, např. provádí zpracování dat, ale vlastní data jsou na serveru. > Tenký klient jako typ aplikace oVolba typu klienta je důležitá pro návrh celé aplikace oTenký klient jako aplikace komunikuje s aplikačním serverem a dostává převážnou část logiky z aplikačního software běžícího na serveru někde v síti. oJiné dělení: kde vlastně běží aplikace – na HW klienta nebo na HW aplikačního serveru oPříklady: nMS Office na serveru a jejich instance na klientech nVirtuální image OS na serveru, data na serveru, vlastní výpočty na mobilních klientech přes VPN nPřístup přes WEB k SAP nebo Navision > Srovnání typu klientů oVýhody tenkých klientů nNižší náklady na administraci IT, jednodušší zabezpečení nNižší náklady na hardware nNižší spotřeba energie nLepší využití zdrojů nMenší nároky na šířku pásma sítě nNepoužitelné pro zloděje nJednodušší upgrade a změny software oVýhody tlustých klientů nMenší nároky na servery, úspora nákladů na pořízení nMenší nároky na síť v případě multimediálních aplikací nVyšší pružnost, v případě Windows značně složité n n > Vrstva v architektuře Client/Server oDvě vrstvy (two-tier) o o oTři vrstvy (Three-tier) Klient 1 ….. Server Klient 1 Klient n ….. Klient n Aplikační Server DB Server > Třívrstvá architektura - důsledky oKlient zajišťuje prezentaci aplikační logiky a dat oAplikační server je oddělen od uživatele i od databáze oAktivity přináležející určitému uživateli mohou být plně „privatizovány“ – důsledky v systému oprávnění oMožnost „předpřípravy“ dat (application pre-processing) oCelá logika aplikace může být oddělena a spravována z jednoho místa (údržba a nové požadavky) oDatabázové servery mohou používat nezávislý software oMůže vzniknout z dvouvrstvé architektury > C/S architektura v případě MS Dynamics NAV > Důsledky C/S architektury oProcesní orientace nHierarchická struktura funkcí nevyhovuje nDialog je řízen člověkem nPráce je vedena stylem objekt - akce nOO přístupy se hodí lépe oModel uživatelských objektů nUO diagram tak jak je chápe uživatel nUživatelské rozhraní: okna a akce nad nimi (tomu odpovídají akce nad databází) nDiagram pohybu mezi okny o3 typy modelů nProcesní (diagram datových toků) nDatový (entity a vazby) nEntity a události ( diagram životního cyklu entit) n > Programátorské důsledky C/S architektury oVysoká závislost na síti a její výkonnosti nLAN – kabeláž min kat5 100Mbit/s (mezi servery min 1Gbit) nWAN – min 2Mbit oNutná změna z procedurálního modelu na model řízený událostmi oZměna způsobu přípravy uživatelského prostředí (na prvky jsou navěšeny triggery, lišty, ikony …) oProgramátor : nNamaluje obrazovky nNastaví triggery a jejich atributy nZorganizuje externí i interní podprogramy nMusí uvažovat s vícenásobnou použitelností (zejména webovské přístupy) > Problematika rozdělení na část klient a část server oKontrola na relačnost a konzistenci datového modelu nMohlo dojít k porušení během specifikace UO oSpecifikace ochrany dat a přístupů nV důsledku vícenásobné použitelností může dojít k problémům nPříklady moduly HR a provizní systém, ceny pro přímý prodej a dealery atd. oProblém více databázových strojů nReplikace, synchronizace, nZvážení účelných duplicit a důsledků v reportingu oRychlost kritických aplikací nRychlost DBMS nRychlost infrastruktury nZpůsob práce s okny (zdroje koncových strojů) nKritické uživatelské úkoly ( filtry, počítaná pole, hledání, třídění) > Některé nevýhody C/S oSystém management (konzistence a aktuálnost ve velké síti) oZávislost na síti – nebezpečí nákladů na duplicitní zařízení oNákladné financování spojení aplikačních serverů s klienty (MS Terminal Server, Citrix) oOptimalizace a doladění DB serverů není jednoduché oSoučasná tendence u aplikačních C/S architektur vede k webovským přístupům (cloudy) nBezpečnost, mobilita, oprávnění, demilitarizované zóny, otázky uvolněných portů, … > Zpět k vlastnímu průběhu projektu oZopakujme si nModel vodopád nModel spirála nPrototypování nAgilní metodiky oVelké projekty stále využívají mix vodopádu, spirály a prototypování 19 > Použití různých metod v různých etapách projektu 20 > Prototypování oPrincip: nvíceúrovňové prototypy, například prototypy GUI a poté prototypy hlavních funkcí reagujících na události v GUI nopakované diskuze s uživateli a úpravy prototypů oVýhody: nvčasné zapojení uživatelů do přípravy systému a získání jejich pozitivní motivace nmožnost dolaďovat systém tím, že se nejdříve testují hlavní funkce a podle připomínek uživatelů se jejich detailní funkce přizpůsobují uživatelským potřebám nvedení projektu má větší přehled o postupu a plnění jednotlivých pracovních kroků nuživatel dostává to co uviděl nmožný rozvoj řešení po etapách a iteracích 21 > Prototypování oNevýhody nnutnost kompetentního vedení projektu (nebezpečí zacyklení a ztráty času) npři nedostatečném naplánování může dojít k neorganizovanému vývoji, kdy se požadavky uživatelů zavádějí bez vazeb na jiné části systému nebo se porušují již odzkoušené funkce ntím mohou stejně jako později v etapě testování vznikat sekundární chyby nuživatel může mylně dojít k závěru, že systém je již téměř hotov a podceňuje fázi testování nčasto dochází k tomu, že je nedoceněna práce na dokumentaci nje zde určité riziko, že uživatelé své připomínky k prototypům mohou považovat za chyby sytému ntím může vzniknout negativní motivace n 22 > Agilní metodiky oHlavní principy: nIterativní vývoj IS. Těchto iterací může být provedeno větší množství v co nejkratším čase. nPředem připravené testy. Při každé iteraci je produkt podroben testování. Příprava testů musí být velice pečlivá, aby se zabránilo sekundárním chybám v již otestované předchozí verzi. nCo nejširší komunikace vývojářů a budoucích uživatelů. 23 > Některé agilní metodiky oRodina Unified metodik: Unified process (též USDP), Rational Unified process (IBM) iterace, OpenUP nInception – elaboration – construction - transition oLean software development process: n„Vše co není k užitku zákazníkovi je odpad“ nCo nejvíce testů – rozhodnutí co nejpozději – dodej co nejrychleji – podporuj tým – zabuduj integritu – pohlížej na celek oSCRUM - mlýn: malé přehledné části, které se realizují ve „sprintech“ oExtrémní programování – dotažení známých metod „do extrému“ 24 > Extrémní programování oAktivní účast zástupce uživatele. Požadavky uživatele se shromažďují do „User stories“. oIterativnost postupu. oNeustálé využívání zpětné vazby, maximální komunikace v projektovém týmu, neustálé testování jednotlivých modulů a vlivu změn na celkový výsledek, komunikace s uživatelem. oMaximální jednoduchost, programuje se jen to co je v daný moment potřebné, neustále se zkoumá, zda by mohla existovat ještě jednodušší varianta řešení. oZačíná se programovat od jednotkových testů. o 25 > Extrémní programování oStejný modul programují dva programátoři, kteří sedí u jednoho počítače. Diskuzí dvojice nad tvořeným programem se vyloučí chyby a dosáhne zjednodušení kódů. oKrátké iterace – provede se jedna změna v programu a ihned se ověřují výsledky. oZdrojové kódy jsou vlastnictvím všech zúčastněných programátorů, všichni jsou společně zodpovědní za výsledek. oNeprovádí se žádná optimalizace, jestli má optimalizace proběhnout, pak se provede na konec. oIntegrace napsaných kódů do existujícího řešení provádí v jeden okamžik pouze jedna dvojice programátorů – tím se vyloučí diskuze, ze kterého kódu vznikla případná chyba. Integrace se provádí co nejčastěji. oNa počátku se nepíše zdrojový kód řešení, ale připravují se jednotkové testy modulů. oJednotliví programátoři ve dvojicích se obměňují. o 26 > Aspektové přístupy oOd poloviny 90.let oV zásadě využívají myšlenky objektového programování, bývají však označovány za „post objektové“ přístupy, což je dáno dobou jejich vzniku. oVznik aspektového programování byl vyvolán potřebou modularizovat často se opakující části programového kódu, které se nacházejí v různých místech aplikací. oTyto části se označují za „záležitosti“- anglicky concerns a jejich „rozptýlený“ výskyt v aplikacích vede k jejich označení „crosscutting concerns“ oOddělení jednotlivých „záležitostí“ do programových bloků (modulů), které lze vícenásobně a nezávisle použít v různých částech aplikací je základem aspektového programování, moduly bývají označovány za „aspekty“. o o 27 > Aspektový přístup oNejdříve se vyhledají nezávislé „crosscutting concerns“ – například opakující se transakce nad databázemi, jejich logování, bezpečnostní procedury apod. oPak se naprogramují kódy jednotlivých aspektů a tyto kódy se připojí k odpovídajícím modulům technikou „weaving“ – spřádání. Teprve poté se provede případná kompilace. oVzniklý modul obsahuje jak obchodní logiku, tak programové kódy aspektů. oNejznámějším programovacím prostředkem pro realizaci aspektů je jazyk AspectJ, který vyvinul Georg Kiczales et al. ve vývojovém středisku firmy Xerox. oTechnika v případě AspectJ je založena na tom, že k běžícímu programu může být v určitém bodě připojena určitá modifikace „advice“ (filtr), která běh programu změní a vyvolá kód aspektu. 28 > Převody dat nZměny struktur stávajících dat do struktur nového systému oJiné struktury tabulek nOdstranění duplicit a chybných dat ze starého systému oŠance získat správná data nDoplnění chybějících polí nebo údajů oZpravidla ručně – velké problémy se zdroji nKdo provádí: oKoncoví uživatelé pod vedením klíčových uživatelů oOddělení IT ( automatizace převodu) nRizika: oDodavatel nového systému nemá jasno o vztazích mezi daty (závažná chyba návrhu systému) oOddělení IT má málo zdrojů oKoncoví uživatelů nemají čas na kontrolu oNejsou jasné vazby na části IS, které nepodléhají změně nDůsledek: oMůže dojít k odložení náběhu 29 Akceptační /Integrační testy oProbíhají za účasti celého týmu oÚčel: nOdzkoušet integritu systému (logistika a účetnictví, …) nAkceptace kritických funkcí a jejich vazeb oZměnová past nZpravidla teď se objeví další požadavky na funkcionalitu (úloha manažéra projektu) nZavedení nových funkcí vyvolá chyby v již odzkoušených modulech nOprava chyb vyvolá sekundární chyby nDodavatel v dobré vůli provádí změny o své újmě nNejsou k dispozici všichni klíčoví uživatelé k odzkoušení integrace oAbsolutní nutnost podrobně dokumentovat změny oNutnost iterativních postupů 30 Školení uživatelů oDva typy školení: nTrain the trainer – jsou zaškoleni klíčoví uživatelé, kteří školí zbytek nPlné školení - provádí dodavatel se svých prostorách nebo u odběratele oZměnová past: nI zde se projeví naplno požadavky konečných uživatelů na změny oNutnost dokonalé komunikace a projektového marketingu oNutnost oslovit pozitivně tvůrce veřejného mínění ve firmě oDokumentace nDodavatelská – zpravidla nestačí, doplňují klíčoví uživatelé nVlastní – dodavatel dodá jen systémovou dokumentaci, zbytek je úkolem odběratele ( cenové dopady) 31 Náběh nového systému oDva typy náběhu: nVše naráz „big bang“ - zpravidla u změn IS, které jsou značně provázané nS duplicitou – vyžaduje značné zdroje, menší riziko problému oRozhodnutí: nS dostatečným předstihem přijímá top management firmy nNutnost stanovení „point of no return“ oTermínová past: nZávažné změny se provádějí na konci finančního období (fixní termín) nRizika: oUživatelé nejsou zaškoleni oData nejsou připravena oNení dostatečně odzkoušena oblast kritických funkcí o 32 Děkuji za pozornost. Otázky?