Statnice

Testování softwaru

10. Testování softwaru Podotázky: Charakterizujte disciplínu testování a popište její místo při řízení projektu. Uveďte jednotlivé druhy testů a podrobně popište jUnit testování. „Žádný software není bezchybný" • Čím později je chyba objevena, tím dražší je její odstranění • Náklady na odstranění chyb v průběhu životního cyklu projektu stoupají 100x až 1000x Testování Softwaru • Je provádění funkcí programu v definovaném okolí a porovnání dosažených výsledků s těmi očekávanými, aby bylo zjištěno, jak dalece se program chová, tak, jak vyžaduje jeho specifikace. • Cílem testování softwaru je nalézt chyby ve zkoumaném softwaru, a tak vytvořit předpoklady pro jejich odstranění, což vede ke zvýšení kvality softwaru. • Dalším cílem je dosažení spolehlivosti. • Testy, i rozsáhlé, nemohou zpravidla zaručit bezchybnost softwaru. • Oblast použití: software, jehož kvalita má být dokázána. • Jen výjimečně postačují samotné testy k důkazu bezpečnosti. • Soudobý trend - Vývoj řízený testy (TDD - Test Driven Development) • Definice: o Proces získání důvěry v to, že program nebo systém dělá, co se od něj očekává. (Hetzel 1973) o Provozování programu nebo systému za účelem hledání chyb. (Myers 1979) o Jakákoliv aktivita zaměřená na vyhodnocení vlastností a schopností programu nebo systému a určení, zda odpovídají očekávaným výsledkům. (Hetzel 1983) Testování - fakta • testování pokrývá 50% času projektu • v tomto je zahrnuto i ladění a všechny typy testování, • vývojářské testování - 10 až 25% času projektu, • 80% chyb je ve 20 % kódu, • většinu chyb (> 95%) vytvoří programátoři aplikace, tj. nejsou v OS, databázi, knihovnách, ... • třetina chyb jsou obyčejné překlepy a pravopisné chyby. Testování jako projekt K testování SW je vhodné přistoupit jako k jakémukoliv jinému projektu. Celý projekt lze rozdělit do 4 hlavních částí: • Příprava na testování - v této fázi vznikají obvykle tyto dokumenty: testovací plán, testovací scénáře a testovací případy. • Provedení testů - v souladu s testovacím plánem pak probíhají vlastní testy podle testovacích scénářů. • Vyhodnocení testů - pokud by se vyhodnocování neprovádělo, tak by testování ani nemělo smysl. • Rozhodnutí o dalším postupu - zopakování některých testů apod. Axiomy testování • Žádný program nelze otestovat komplexně (množství různých vstupů do aplikace). • Testování je postaveno na riziku (co když bude chyba zrovna v tom, co neotestujeme). • Testování nikdy neprokáže, že chyby neexistují. • Čím víc chyb najdete, tím víc jich tam je. • Ne všechny chyby se odstraní. • Cíl testování je v rozporu s cíli ostatních aktivit - zde je cílem nalézt chybu. Místo testování při řízení projektu • pokud testujeme v počátečních fázích vývoje, snižuje testování náklady na pozdější odstraňování chy. • Důležitým faktorem ovlivňujícím cenu je část životního cyklu, v jaké se software při objevení problému nachází. Čím později je chyba odhalena, tím větší množství peněz stojí její odstranění. Kategorizace testů • z hlediska předmětu - rozlišujeme úrovně testů • z hlediska cíle - rozlišujeme typy testů Z hlediska předmětu - Úrovně testů • Jednotkové testování - testování nejmenších vymezených částí systému (jednotek), provádějí vývojáři • Integrační testování - testování zaměřené na vzájemné vazby a propojení částí systému, ověřuje, že jednotky dodané vývojovým týmem lze integrovat, tj. vytvořit funkční build. • Smoke test - ověřuje stabilitu buildu, provádí se před systémovým testem - eliminuje situaci, kdy po zapojení většího počtu testerů systém selže a není možné v testech pokračovat. • Systémové testování - testování systému jako celku, od vstupu po výstup. Systémový test představuje hloubkový test systému, při kterém se zpravidla provádějí téměř všechny typy testů. • Akceptační testování - testování za účelem prokázání splnění definovaných akceptačních kritérií, testy provádí koncový uživatel na vlastním testovacím prostředí, tím je zaručena reálnost testovaných situací. Z hlediska cíle - Typy testů podle základních atributů kvality FURPS (/FURPS+) • Functionality = testy funkčnosti (testování funkčních požadavků) • Usability = testy použitelnosti (test uživatelského rozhraní, nápovědy, školících materiálů, dokumentace) • Reliability = testy spolehlivosti (frekvence selhání, možnosti obnovitelnosti, nestandartní podmínky) • Performance = testy výkonu (časová odezva, propustnost, přesnost, dostupnost) • Supportability = testy podpory (adaptabilita, udržovatelnost, internacionalizace, konfigurovatelnost) Další dělení testů Podle způsobu provedení • Manuální - testy provádí člověk (obvykle tester) podle předem stanovených testovacích směrnic, vlastních zkušeností, atd. • Automatické - spouštění předem naprogramovaných testů ve speciálním programu. Podle potřeby spouštět program • Statické - provádí se bez nutnosti spuštění programového kódu. Testování probíhá analýzou kódu (code review). Analýza může být provedena buď ručně, nebo pomocí speciálních nástrojů. • Dynamické - provádí se spouštěním programu a kontrolou jeho funkčnosti. Testování probíhá prováděním ručních testů, nebo spouštěním předem připravených automatických testů. Funkční/nefunkční/testy spojené se změnami • Funkční testy - založené na funkcích, vlastnostech a možnostech interakce programu s jinými systémy; např. testy funkcionality, bezpečnostní testy a další. • Nefunkční testy - komplexní testování toho, jak systém funguje; např. zátěžové, stresové testy, testy stability, použitelnosti, atd. • Testy spojené se změnami - po provádění nezbytných změn, například oprav chyb nebo defektů, musí být software znovu otestován, aby se zjistilo, zda došlo k odstranění problému; např. regresní testování. Podle znalosti kódu • Testování „černé skříňky" (black box testing) - tester má přístup k programu pouze přes stejné rozhraní jako zákazník nebo uživatel. Zadává vstupy, postupuje připravených scénářů a na konci porovnává výsledek, zda se shoduje s očekáváním. • Testování „bílé skříňky" (white box testing) - tester má přístup ke zdrojovému kódu programu a zná vnitřní datové a programové struktury. Při testování tuto znalost využívá. • Testování „šedé skříňky" (grey box testing) - tester má přístup ke zdrojovému kódu, ale obvykle při spouštění testu nepotřebuje ke kódu přistupovat. Regresní testování • Takový test systému, při kterém jsou kromě nově přidaných funkčností testovány i všechny funkčnosti z dřívějších buildů. • Cíl: zabránit regresním chybám (rozbije se to, co dříve fungovalo; případně navrácení již odstraněných chyb). Závislé x nezávislé testování • Závislé testování provádějí role, které mají jinou specializaci než testování (testují produkty vlastní práce), příklad vývojářské testování. • Nezávislé testování provádějí role, které testují výsledek práce jiných rolí, například testeři, zástupci zákazníka podílející se například na akceptačním testování nebo beta testování. Vývoj řízený testy (TDD - Test Driven Development) Myšlenka: definovat nejprve sadu testů a teprve pak psát testovaný program. Při psaní programu se pak stačí soustředit pouze na to, aby výsledný program prošel napsanými testy. Jakmile program těmito testy projde, programátor se zamyslí, jak by jej měl dále vylepšit, zase napíše testy a opět se snaží upravit program tak, aby testy prošel. Refaktorování je nedílnou součástí vývoje řízeného testy - jedná se o proces provádění změn v softwarovém systému takovým způsobem, že nemají vliv na vnější chování kódu, ale vylepšují jeho vnitřní strukturu. Je to disciplinovaný způsob pročišťování kódu s minimálním rizikem vnášení chyb. Zlepšování návrhu kódu poté, co byl napsán. Výhody TDD: • Při psaní programu může programátor kdykoliv spustit předpřipravenou sadu testů a průběžně na nich kontrolovat, kolik jich už proběhlo a kolik práce mu ještě zbývá. • Ve chvíli, kdy proběhnou všechny testy, je programátor s prací hotov a nemusí již přemýšlet nad tím, jestli v jeho programu nejsou chyby. JUnit testování Open-source nástroj (framework) pro testování tříd napsaných v Javě • Testovací rámec pro tvorbu a spouštění automatizovaných jednotkových testů • Pro každou třídu se vytvoří soubor testů, které kontrolují, zda jednotlivé veřejné metody vracejí k zadaným vstupům očekávané hodnoty. • Použití např. v metodice TDD (Test-Driven Development) - testy píšeme před zápisem samotného kódu • TestCase = nejčastěji užívaná třída frameworku JUnit - za pomoci dědičnosti jsou z ní vytvářeny odvozené třídy, které obsahují samotný testovací kód. • Každý z testů ve třídách odvozených od TestCase má 3 části (metody): • setUp() o metoda, která vytváří tzv. „přípravek" = sada objektů, které se vytvoří před spuštěním každého testu, doplněná případně o nastavení nějakých okrajových podmínek. V této metodě je realizována tvorba a uložení instancí do atributů, nastavení vstupních hodnot atd. • testNazevTestu() o tato metoda zkoumá a vyhodnocuje chování testovaných prvků. Jméno testovací metody musí vždy začínat prefixem test. Framework díky tomuto předpokladu automaticky pozná, že se jedná o testovací metodu. • tearDown() o = úklid po testu - uvolnění zdrojů • Uvnitř testovací metody se nachází tzv. potvrzovací metody (nazývány také testovací konstrukce): o v testovacích metodách se používají pro ověřování, zda je předpokládaný výsledek rovný výsledku skutečnému o Základními potvrzovacími metodami jsou metody assertEquals(x1,x2), kterých je celá řada a liší se pouze tím, jakého typu jsou jejich parametry. Těmto metodám předáme v prvním parametru očekávanou hodnotu a ve druhém hodnotu, ke které dospěl program. Pokud se tyto hodnoty liší, metody vypíší v testovacím okně očekávanou a obdrženou hodnotu a daný test ukončí. o Dále např.: assertTrue, assertNull, fail a další.

Objekty a jejich vlastnosti

7. Objekty a jejich vlastnosti Podotázky: Třída, instance, zapouzdření (uveďte příklady, kdy zapouzdření neplatí), předávání zpráv, polymorfismus. Objekty Jedná se o abstrakci z reality, každý objekt představuje spojení dat (údajů, proměnných, datových atributů) a činností s těmito daty (metod). Tato abstrakce je vždy účelová, o každém reálném objektu se sledují ty údaje, které jsou relevantní pro aplikaci. Pokud chceme pracovat s objekty, je nutné vědět, jaké jsou obecné vlastnosti objektů. Obecné objektové vlastnosti: • používání abstrakce • definování tříd objektů • existence objektů (instancí) • komunikace objektů (posílání zpráv, volání metod) • zapouzdření a ukrývání implementace • dědičnost • polymorfismus Abstrakce Abstrakce je základní objektovou vlastností. Skutečnost, kterou chceme do programu promítnout, musíme vždy zjednodušit, pracovat jen s těmi daty, která jsou pro nás důležitá. První příklad: Když chceme udělat počítačovou evidenci knih, které jsou k dispozici v obchodě, bude základem abstrakce knihy. V knihkupectví nás bude pravděpodobně u každé knihy zajímat: autor, název, ISBN, vydavatel, žánr, cena, počet kusů na skladě. S knihou budeme provádět např. tyto činnosti: založení nové knihy, změna množství na skladě, změna ceny. Druhý příklad: Chceme napsat aplikaci pro kreslení. Tvary (čtverce, obdélníky, kruhy, trojúhelníky atd.), které budou nakresleny, jsou objekty. U každého nakresleného tvaru musíme sledovat např. tato data: souřadnice umístění, rozměry tvaru, barvu čáry, barvu výplně. Metody neboli činnosti, které bude možno v takové aplikaci provádět s jednotlivými tvary, budou například tyto: nakreslení, zvětšení, zmenšení, změna barvy, posun, vymazání. Třída a instance Třída je obecný popis, ve kterém se deklarují (určí) data (datové atributy), která budou popisovat stav objektu, a metody, které definují činnosti, jaké je možné s objekty provádět. Programátor definuje, které údaje se budou o objektech sledovat a jaké činnosti bude s těmi daty možno provádět a jak se to bude dělat. V programu se poté vytvoří několik instancí této třídy. Instance je tedy vytvořena v paměti počítače a vytváří jakýsi obraz reálného objektu (např. účet Josefa Nováka). Data, která budeme o každé instanci sledovat, označujeme jako datové atributy instance. Činnosti, které je možné s danými instancemi provádět, označujeme jako metody (metody instance). Volání metod (posílání zpráv) Každá aplikace je tvořena několika třídami, v rámci běhu aplikace jsou vytvářeny instance těchto tříd a volány jejich metody. Volání metod se podobá posílání SMS z mobilního telefonu. Můžeme poslat SMS jen tomu, na koho máme číslo. Ucet mujUcet; - identifikátor použitý na uložení odkazu musí být typu Ucet mujUcet = new Ucet (1,"Pepa"); - vytvoření nové instance třídy Volání metod ze třídy Ucet: mujUcet.vloz(100); double stavMehoUctu = mujUcet.getStav(); V případě volání metod stejné instance používáme klíčové slovo this. Zapouzdření Zapouzření (encapsulation) popisuje princip umisťování dat a souvisejících metod k sobě - do jednoho objektu, do jedné metody, atd. Zapouzdření musí být podporováno vhodnou jazykovou konstrukcí, v Javě i ostatních objektových jazycích se realizuje pomocí tříd a vytváření instancí. Při zapouzdřování objektů je vhodné dodržovat tato pravidla: • Snažit se umístit data a operace pracující s daty (metody) do stejné třídy. • Třída by neměla obsahovat jen část dat či část metod, ani by neměla obsahovat více dat či metod, než je nutné pro činnost, za kterou třída odpovídá. Častější chybou je, že třída obsahuje více dat, než kolik potřebuje. • Jednotlivé zprávy posílané instanci by pokud možno měly být na sobě nezávislé, metody by měly požadovat jen nezbytně nutné parametry. Ukrývání implementace Možnost používat metody objektů bez znalosti jejich implementace se nazývá ukrývání implementace. Každý objekt poskytuje svému okolí metody, které je možné zavolat. Seznam těchto metod (a dostupných datových atributů) je označován jako veřejné rozhraní třídy. V tomto rozhraní by neměly být zahrnuty datové atributy, ty by měly být schovány uvnitř instance a měly by být přístupné pouze pomocí metod. Předpokladem pro ukrývání implementace je, že programovací jazyk podporuje zapouzdření. Oba pojmy spolu úzce souvisí, což někdy vede k jejich nepřesnému používání či vzájemnému zaměňování. Následující modifikátory uvádějí možnost přístupu k datovému atributu nebo metodě: • private • (nic neuvedeno) • protected • public Označíme-li nějaký datový atribut nebo metodu jako private, znamená to, že je přístupná pouze z metod instance. Jako druhý modifikátor vlastně není nic uvedeno, ale znamená to, že pokud neuvedeme žádný modifikátor přístupu, použije se přátelský přístup. Datové atributy a metody jsou v tomto případě přístupné v rámci balíčku. Datové atributy a metody, které mají označení přístupu protected, jsou přístupné v rámci balíčku a také z potomků v rámci dědičné hierarchie. Označení přístupu public znamená, že daný datový atribut nebo metoda jsou přístupné z jakékoliv jiné třídy. Dědičnost Dědičnost je jednou z forem znovupoužitelnosti - vytvářená třída (potomek) do sebe absorbuje datové atributy a dědí metody z jiné třídy (předek) a dále je rozšiřuje a upravuje. V diagramu tříd se dědičnost vyznačuje pomocí šipky, u které trojúhelník na konci směřuje k předkovi. Dědičnost není pouze jednoúrovňová - potomek nějaké třídy může mít dále své potomky. Tito potomci dědí metody od všech tříd na vyšší úrovni. Takto vzniká hierarchie tříd, ve které není omezen počet úrovní. Java podporuje jednonásobnou dědičnost - každá třída může a musí mít právě jednoho předka. Stromová hierarchie tříd začíná třídou Object (tato jediná třída nemá předka), všechny třídy jsou přímým či nepřímým potomkem této třídy. Dědičnost by se měla používat v situacích, kdy potomek je podtypem svého předka, tj. existuje mezi nimi vztah. Pokud má být nějaká třída B potomkem třídy A, měli bychom si kladně odpovědět na tyto otázky: „B je A?" či „Je každý B také A?". Nemůžeme-li na takou otázku odpovědět kladně, neměli bychom používat dědičnost. Jsou vztahy, které lze vyjádřit pomocí „je částí" („part-of") a „má" („has-a"). Pokud jsou mezi třídami tyto vztahy, nepoužívá se dědičnost, ale většinou kompozice. Důležité je též si uvědomit, že dědičnost vyjadřuje vztah tříd, ne vztah instancí. Pro objektový jazyk C++ s vícenásobnou dědičností se obvykle doporučuje, aby základem nějaké dědičné hierarchie byla abstraktní třída. Toto neplatí plně pro jazyky s rozhraními, jako je např. Java, kde se jako základ dědičné hierarchie obvykle používá rozhraní. Důvody použití dědičnosti Dědičnost se využívá v různých situacích, za různými účely. V praxi lze důvody pro použití dědičnosti obtížně odlišit. 1. Specializace Jedním z nejčastějších důvodů pro použití dědičnosti je specializace existujících tříd a objektů. Při specializaci získává třída nové datové atributy a chování proti původní třídě. Příklad: specializace s bankovním účtem a žirovým účtem 2. Překrývání metod a polymorfismus Častým důvodem k dědičnosti je možnost využití překrývání metod a následně polymorfismu - různí potomci mají rozdílně implementována některá chování (některé metody). Při volání takové metody programátor nemusí uvažovat o tom, které konkrétní instanci posílá zprávu, neboť každá instance má k sobě přiřazen svůj specifický kód. 3. Znovupoužití kódu Jednou z prvních motivací pro dědičnost bylo umožnit nové třídě znovu použít kód, který již existoval v jiné třídě. Pokud vede k dědičnosti pouze tento motiv, vznikne hierarchie, kdy věcně nelze přetypovat potomka na předka. Polymorfismus Pojem pochází z řečtiny a znamená mnohotvarost. V OOP vyjadřuje situaci, kdy při stejném volání provádí různý kód. Která konkrétní metoda se provede, závisí na předávaných parametrech a objektu, kterému je zpráva předána. • přetěžování metod (overloading), též ad-hoc polymorphism (metoda má více než jednu definici ve stejném „scope" (stejné jméno, různé parametry)) • překrývání metod (overriding), též subtype polymorphism (u potomka je stejná deklarace metody, ale jiná implementace) • parametrický polymorfismus - např. šablony v C++, nemá pevně stanovený typ argumentu

Vzory při vývoji softwaru

8. Vzory při vývoji softwaru Softwarové vzory Každý vzor vyjadřuje vztah mezi problémem a řešením. Jako součást světa má každý vzor vazbu na určitý kontext, určitý systém sil, který se opakovaně objevuje v daném kontextu a na určité prostorové uspořádání, jež umožňuje těmto silám rozhodovat se. Typy softwarových vzorů: architektonické, analytické, návrhové, vzory kódu, vzory pro UI a další Návrhové vzory • návrhové vzory (design patterns) jsou doporučené postupy řešení často se vyskytujících úloh • lze je přirovnat k matematickým vzorečkům, nedosazujeme však čísla, ale třídy, rozhraní a objekty • snižují pravděpodobnost chyb • vštěpují zásady správného programování • zestručňují a zkvalitňují komunikaci • velké SW firmy jejich znalost vyžadují • existují katalogy návrhových vzorů = nejznámější je GoF (zkratka Gang of Five - skupina 5 významných programátorů, popisuje 23 základních, obecně použitelných návrhových vzorů) • v zápisu návrhových vzorů se používá zakreslení vztahů a postupů pomocí UML diagramů a současně také slovní popis, který dané diagramy doprovází Definují ověřená řešení určitých problémů návrhu. Obrázky a více info na http://objekty.vse.cz/Objekty/Vzory Důvod vzniku - potřeba elegantního, jednoduchého a znovupoužitelného řešení. Je třeba najít vhodné objekty, definovat rozhraní tříd, definovat hierarchii dědičnosti, definovat vztahy mezi třídami. Cíl: • sepsat katalog obecných interakcí, které byly vícekrát použity • chceme získat nezávislost tříd - volné vazby • u dědičnosti má potomek přístup k metodám a nesoukromým proměnným předka, když je na vrcholu hierarchie třída s definovanou implementací, tak potomci jí mají také. Formát vzoru (jednoduchý): • název problému • problém (kdy se má vzor používat) • řešení (prvky řešení) • důsledky (důsledky použití vzoru) • související vzory Návrhové vzory podle Pecinovského (které nejsou součástí GoF): • Jednoduchá tovární metoda - metoda, která umí vracet instanci deklarovaného typu (buď jí vytvoří, nebo najde nějakou již existující). Normální konstruktor umí instanci jen vytvořit, a navíc umí vytvářet jen instance své třídy + má další omezení. • Přepravka (Messenger) - pokud potřebuji, aby metoda vracela více hodnot najednou, tak je můžu dát do přepravky - to je třída, jejíž instance přenáší požadované hodnoty ve svých atributech. Tyto atributy bývají veřejné, aby bylo možné přistupovat k hodnotám přímo. Samozřejmě ale mohou být privátní, a tedy přístupné jen přes příslušné metody. Přepravka tedy může mít i metody. Každá přepravka má předem připravené atributy, které se jen naplňují - pro každý typ přenášených hodnot tedy musí existovat zvláštní přepravka (např. přepravka na rozměry má atributy x a y). • Knihovní třída (Utility) - třída, která slouží jako úložiště (knihovna) často používaných metod - je to lepší než mít v každé třídě tu samou implementaci těchto metod. Metody v této třídě bývají statické. Obvykle nemá smysl vytvářet instanci této třídy, proto její konstruktor bývá privátní, bezparametrický a s prázdným tělem. • A další - kontejner, výčtový typ, neměnné objekty, služebník (servant), prázdný objekt (null object) ... Členění podle GoF: • Structural Patterns (strukturální vzory) - zaměřujících se na možnosti uspořádání jednotlivých tříd nebo komponent v systému • Creational Patterns (vzory pro vytváření objektů) - řeší problémy související s vytvářením objektů v systému • Behavioral Patterns (vzory chování) - zajímají se o chování systému 1. Strukturální vzory • Adapter (adaptér) o Potřebujeme existující rozhraní objektu přetransformovat na rozhraní, které v danou chvíli potřebujeme. o Může se implementovat třemi různými způsoby. Vždy jde ale o to, že adaptér tvoří prostředníka mezi klientem volajícím určitou metodu a třídami, které tuto metodu implementují, a přesměrovává volání od klienta na některou z těchto tříd. o Příklady: 1. Obalové třídy primitivních datových typů v Javě - abychom mohli používat metody, které se dotazují na jejich hodnoty, musí být primitivní datové typy obalené adaptérem. 2. Zajištění zpětné kompatibility systému - požadavky se musí zpracovávat podle toho, jaké rozhraní klient očekává. • Bridge (most) o zavádí rozhraní, které odděluje abstrakci zprostředkovávající nějakou službu od její implementace, takže lze obojí měnit nezávisle na sobě o příklad: okno v GUI - abstrakce okna a její funkcionalita x specifická implementace na konkrétním OS • Composite (skladba) o slouží pro jednotné vyjádření hierarchií typu celek-část o příklad - stromová struktura • Decorator (dekorátor) o dynamicky připojuje další funkcionalitu k objektu - pokud chci, aby více objektů získalo určitou funkcionalitu, a nechci jí v každém implementovat zvlášť, tak je zabalím do určité třídy. Obalující třída má na starosti jen požadovanou funkcionalitu a zbytek deleguje na obalený objekt. o flexibilní alternativa dědění o někdy potřebujeme přidat odpovědnosti jen jednotlivým objektům, nikoli celé třídě o často se používá v Javě v GUI - např. při návrhu GUI potřebujete přidat ohraničení nebo rolování k určité komponentě. Řešení je, že vložíte komponentu do dekorátoru. o Implementace - mám několik tříd, kterým potřebuji dodat určitou funkcionalitu. Tak jim vytvořím společné rozhraní, které implementují nejen tyto třídy, ale i dekorátory. Stejně tak to můžu udělat s pomocí abstraktní třídy, která bude předkem těchto tříd a tak může implementovat nějakou funkcionalitu, která je pro všechny dceřiné třídy společná. • Facade (fasáda) o cílem je zjednodušit (sjednotit) rozhraní o snižuje počet tříd, se kterými musí uživatel komunikovat • Flyweight (muší váha) o vzor vhodný pro situace, kdy vzniká mnoho malých objektů, u kterých je možné podstatnou část jejich stavu sdílet nebo ho nahradit výpočtem • Proxy (zástupce) o zavádí zástupce, který odstiňuje objekt od jeho uživatelů a sám řídí přístup uživatelů k danému objektu 2. Vzory pro vytváření objektů Řeší problémy související s vytvářením objektů v systému: • snaží se oddělit vytváření objektů do samostatné třídy/tříd • konkrétní třída, od níž se vytváří instance, se určuje až za běhu programu • třeba zajistit správný počet objektů • Tovární metoda (Factory Method) o několik tříd, které mají obvykle společného předka a poskytují různé služby o dovoluje za běhu programu vytvořit instanci některé z těchto tříd o definuje rozhraní pro vytváření objektu; přenechává rozhodnutí, od které třídy vytvořit objekt, na své podtřídy • Abstraktní továrna (Abstract Factory) o při vytváření více objektů, které spolu souvisí o poskytuje rozhraní pro vytváření rodiny příbuzných objektů bez nutnosti specifikovat konkrétní třídy o složená třída obsahující stejné složky vytvářené různě v závislosti na aplikaci o abstraktní továrna je založena na myšlence, že se jako parametr do konstruktoru předá třída (továrna) se standardním rozhraním - to je pak použito konstruktorem, ale jeho metody jsou implementovány odlišně pro každý typ továrny • Stavitel (Builder) - podobný abstract Factory. Máme různé objekty s podobným procesem konstrukce. • Prototype - vytvoření kopie existující objektu namísto vytváření nové třídy (v Javě rozhraní Cloneable). • Jedináček (Singleton) o cílem je zabránit vícenásobnému spouštění konstruktoru - chceme, aby třída měla pouze jedinou instanci o řešení: 1. použít statickou proměnnou třídy, která bude obsahovat informaci o tom, zda již byla vytvořena instance třídy 2. definovat privátní konstruktor třídy 3. definovat statickou metodu getInstance(), která bude vracet instanci třídy o příklady - jediné připojení k databázi, správce tiskových úloh 3. Vzory chování • Mediator (=prostředník) o Definujeme objekt prostředníka, který zprostředkovává veškerou komunikaci objektů o Vzájemné závislosti objektů se tak omezí na závislost na prostředníku o u telefonů - obdobné řešení - telefony také nejsou spojeny každý s každým, ale spojují se prostřednictvím ústředny o většinou implementován pomocí vzoru Observer • Observer (=pozorovatel) o Problém: na stavu jednoho objektu závisí jiné objekty. Při změně stavu jednoho objektu je třeba informovat objekty na něm závislé. Tyto objekty jsou volně vázané - objekt měnící svůj stav informuje ostatní, ale je nezávislý na jejich vnitřním uspořádání. o řešení - objekt měnící stav = subjekt - informuje objekty u něj zaregistrované jako pozorovatele/posluchače = observer 1. pozorovaný objekt (subjekt) udělám potomkem třídy Observable a zařídím, aby ve správnou chvíli informoval pozorovatele. 2. pozorovatele nechám implementovat rozhraní Observer a definuji v nich metodu update (aktualizuj), kterou subjekt při dané změně stavu zavolá. o příklad: 1. změní se zaškrtnutý RadioButton 2. v adventuře byly na změně místnosti závislé věci v dané místnosti Přínos návrhových vzorů popisují opakující se problém spojený s návrhem softwaru a poskytují jeho řešení, zachycují a dokumentují již existující a praxí ověřený návrh, umožňují pracovat na vyšší úrovni abstrakce, definují jazyk pro popis návrhu, dokumentují architekturu, stavební prvky, z nichž se dají stavět komplexní návrhy, zajišťují vyšší kvalitu SW Výhody používání vzorů zvýšení znovupoužitelnosti a produktivity řízení znalostí rychlejší a efektivnější vývoj - vývojáři se zaměřují na to co, vytvářet a ne, jak to vytvářet automatizované generování kódu pro vzory zvýšení kvality kódu Architektonické vzory • jsou softwarové vzory, které představují řešení architektonických problémů v softwarovém inženýrství • představují základní strukturu softwarového systému, která se skládá ze subsystémů, jejich odpovědností a vzájemných vztahů • představují koncept, který obsahuje podstatné prvky SW architektury • důležitou vlastností je, že obsahují různé atributy kvality • některé vzory představují řešení problémů výkonu, jiné řeší problém vysoké dostupnosti Kategorizace architektonických vzorů 1. vrstvy - dekompozice systému na části. Agregátová vrstva, Filtrující vrstva, Indirection layer. 2. tok dat - Pipes and Filters 3. centralizace dat - přístup k datům - Shared repository 4. adaptace 5. rozšíření jazyka 6. interakce s uživatelem - Model-View-Controller 7. interakce komponent - Client-Server, Peer to peer 8. distribuce Vrstvy Systém má několik úrovní komponent, kde komponenty vyšší úrovně závisí na komponentách nižší úrovně. Cílem oddělení komponent do vrstev je modifikovatelnost, přenositelnost a znovupoužitelnost. • Agregátová vrstva o technologická vrstva vytvářející mocnější agregované funkce z funkcí elementárnějších o vytvoření množiny funkcí, s jejichž pomocí je možné daný problém vyřešit nejrychleji a nejefektivněji o Z agregace nižších funkcí do funkcí vyššího řádu: na vyšší vrstvě se redukuje množina úloh, které lze pomocí funkcí vyšší vrstvy řešit, na vyšší vrstvě se redukuje počet možných cest řešení úloh realizovatelných jak funkcemi vyšší vrstvy, tak funkcemi nižší vrstvy, ty úlohy, na jejichž řešení je vyšší vrstva orientovaná se na této vrstvě řeší rychleji a efektivněji. o příklad: tabulkový procesor; integrace dílčích služeb do komplexní služby při prodeji aut přes Internet o na vyšší vrstvě nelze realizovat ty úlohy, které jsou z hlediska cíle vrstvy irelevantní = redukce • Filtrující vrstva o technologická vrstva odstíněná od nepodstatných nebo nežádoucích specifik vrstev na nižší úrovni hierarchie o Použití odstínění rozdílů v uživatelském rozhraní několika HW nebo SW komponent stejného typu - zajištění portability, odstínění změn rozhraní v čase, vytváření virtuálních zařízení, která odstiňují navazujícím vrstvám pro ně nepodstatné charakteristiky těchto zařízení (př. virtuální paměť, virtuální terminál). • Indirection layer o subsystém má být přístupný z jedné nebo více komponent, ale přímý přístup je problematický o k přístupu se používají speciální komponenty - wrappery o nepřímá vrstva zapouzdřuje všechny wrappery Tok dat Pipes and Filters • filter - komplexní úloha je rozdělena na řadu menších úloh, které jsou navzájem nezávislé • proudy dat se transformují ze vstupních na výstupní • filter může mít více vstupů a více výstupů • filtry jsou propojeny pomocí pipes • filter se nestará o to, kdo je následujícím • pipes fungují jako datové buffery mezi filtry • variantou je pipeline - nelze rozdvojení ani smyčky Centralizace dat - přístup k datům Shared repository • data musí být sdílena mezi komponentami • jedna komponenta slouží jako centrální datové úložiště, ke kterému přistupují ostatní komponenty Interakce s uživatelem Model-View-Controller - MVC • původně v jazyce SmallTalk • UI se mění častěji než business logika, v UI se zobrazují stejná data různými způsoby (tabulka, graf), je třeba měnit zobrazení za chodu. Změna rozhraní se však nesmí dotknout zdrojového kódu. UI kód je závislý na zařízeních. • odděluje modelování problémové oblasti, prezentace a akcí uživatelského vstupu do tříd • příklad: spinner skládající se z textového pole a dvou tlačítek. Každé tlačítko má přiřazen ActionListener (controller), po stisknutí tlačítka se změní model a podle modelu (protože je sdílený) se změní zobrazení na textovém poli • princip o Model zapouzdřuje data a logiku o jeden nebo několik views zobrazuje data uživateli o Controller je spojen s každým view zpracovává vstupy a překládá je do požadavků na model Interakce komponent Client-Server • dvě komponenty potřebují komunikovat a jsou navzájem nezávislé (běží v různých procesech nebo na různých strojích) • nemají stejnou roli - ale jedna iniciuje komunikaci tím, že požaduje službu, kterou druhá poskytuje • komponenta musí umět poskytovat službu více klientům současně Peer to peer • každá komponenta má stejné odpovědnosti, tj. může fungovat jako klient i jako server peer-to-peer síť se skládá z dynamických komponent

Transakce

=dohoda, komunikace, přenos nebo výměna čehokoliv mezi dvěma samostatnými entitami nebo objekty -transakce též znamená proces změny stavu (původní stav → cílový stav) -buď proběhne úspěšně jako taková, nebo - v případě nějakých problémů a komplikací - se vrátí do původního stavu; tedy, nestane se, že by se proces „zadrhnul" někde uprostřed -vlastnost, která dokonání transakce v celku nebo bezpečný návrat do původního stavu dokáže zajistit, se nazývá transakční bezpečnost -typy: • finanční transakce - převod peněžních prostředků, typicky z jednoho účtu na druhý • obchodní transakce - koupě či prodej firem, jejich dceřiných společností, jejich provozů, technologií, služeb, akciových podílů nebo kapitálu obecně; či změna vlastnických práv mezi obchodními subjekty • realitní transakce - převod nemovitosti mezi zprostředkovatelem prodeje (typicky realitní kanceláří) a jejím původním či novým vlastníkem • souborová/disková transakce - transakčně bezpečná disková operace (kopírování, přejmenování/přesun, mazání, ...) • databázová transakce - transakčně bezpečné přidání, smazání či změna dat v databázi -teoretický koncept transakce pochází z oblasti databázových systémů -pojem transakce vychází z oblasti smluvního práva, kde strany nějakou dobu jednají a poté uzavřou smlouvu -smlouva může být uzavřena písemně - podepsáním, nebo prostě stisknutím ruky -pokud si strany nedůvěřují, může na uzavření smlouvy dohlížet třetí strana -př. křesťanská svatba - připravována několik dní, manželství uzavřeno poté co si řeknou své vyznání během obřadu DEFINICE (kniha)= transformace stavu, která má vlastnosti atomicity, konzistence, izolovanosti a trvanlivosti (izolovanost přidána později - vše podle Jamese Nicholase Graye) -> zkratka ACID (Atomicity, Consistency, Isolation, Durabillity) (A) Atomicita - transakce vždy buď proběhne jako celek, anebo jako celek neproběhne vůbec, buď jsou jí vázáni všichni, anebo nikdo (C) Konzistence - transakce proběhne podle daných pravidel (I) Izolovanost - transakce nezasahuje do ostatních transakcí ani ostatní transakce do ní (D) Trvanlivost - jakmile je transakce potvrzena, nemůže být zrušena -v rámci byznys procesů jsou prováděny byznys transakce - mění se tedy stavy byznysu -stavy byznysu se mění během činností - procesů -procesní analýza zkoumá procesy jako sled činností a stavů byznysu -pro automatizaci byznys procesů - předávání informací a dokumentů od jednoho aktéra ke druhému - workflow TPS - transakčně procesní systém, aplikační software, který zajištuje informace pro běžnou operativní činnost byznysu =systém, který zpracovává transakce -podnikové činnosti na operativní úrovni obvykle vysoce strukturované a prováděny s nízkou úrovní dohledu -tvoří základ informačního systému podniku, protože vytvářejí vstupy do IS pro rozhodování a vykazování -transakční systémy často pokrývají procesy probíhající skrze různé podnikové oblasti -analýza, návrh a řízení transakčně procesních systémů tvoří nejnáročnější a nejrizikovější problematiku tvorby IS Alternativou k ACID je BASE: -Basic Availability, Soft-state, Eventual consistency Transakce = logická posloupnost operací, která se promítá do DB jako celek. Je to přechod z konzistentního stavu přes nekonzistentní ke konzistentnímu. ACID (vlastnosti transakcí) A....atomacity - transakce se tváří jako celek, musí proběhnout celá nebo vůbec ne C... consistency - transakce transformuje DB z jednoho konzist. stavu do jinehé konsistentního stavu I.... independence - T jsou nezávislé, dílčí efekty nejsou viditelné jiným transakcím D...durability - potvrzené T jsou uloženy do DB Obnova databáze - transakce je promítájna do db jako celek. Obsahuje-li např 5 operací a skončí-li pátá chybou není do db zapsána žádná z operací této transakce. Pokud skončí úspěšně změny se zapíší. Důvody neúspěšného ukončení transakce - SW, HW, vliv uživatele. Databázový systém musí při havárii systému zajistit • zotavení všech dokončených T • eliminace nedokončených T Nejčastěji používané příkazy: BEGIN TRANSACTION ROLLBACK TRANSACTION COMMIT WORK END TRANSACTION Zajištění obnovy poskytuje žurnálový soubor - log file žurnálování - záznam všech prováděných změn v DB kontrolní bod - časový snímek DB původní a nové objekty databáze měněné operacemi transakce). BEFORE IMAGE AFTER IMAGE vycouvání - UNDO, ROLLBACK- odstranění změn nedokončených transakcí obnova databáze - (zotavení REDO, ROLLFORWARD) Víceuživatelské zpracování Data zpracovávána jednou transakcí jsou chráněna před zásahem jiných transakcí Základní typy problémů 1. aktualizace stejné položky dvěma transakcemi 2. T1 aktualizuje data, která už jiná T změnila ale ještě nodošlo k přenesení změny (existuje možnost ROLLBACK 3. T1 vyhledává údaje, které jiná transakce současně aktualizuje Řešení: zamykání. zamykání - zajištění, že v průběhu zpracování dat nedojde k jejich změně - ve většině systémů insert a delete zamyká celou tabulku Typy zamykání: výlučné - exclusive - insert, update, delete sdílené - share- select Uvorně zamykání: celá relační tabulka databázová stránka řádek relace DeadLock - zablokování - stav v němž 2 nebo více T čekají na situaci která nikdy nenastane. Řešení - prevencí (způsob uspořádání) - řešení bez zamykání - detekcí (časový limit) zahnízděné transakce - transakce, které vyvolávají jiné transakce

Hlavní funkční oblasti CRM aplikací

Co je CRM? - Customer Relationship Management = řízení vztahů se zákazníky. CRM - soubor metodik pro řízení a zlepšování vztahů se zákazníky za využití informačních technologií. Jako takové se stává součástí firemní strategie i kultury. Informační systémy se dnes zaměřují na podporu podniku prodat svoje výrobky či služby. Vznikají nové komunikační kanály se zákazníkem. Podniky se pomocí IS snaží být v kontaktu se zákazníkem (klasická pošta, elektronická pošta, diskuse a konference na webu, call centra...). CRM je rozšiřující komponentou ERP II, ale samozřejmě je možné koupit ji i samotnou. Podstata CRM: udržování a rozvíjení komunikace se zákazníky, snaha vytvářet dojem individuální komunikace. S příchodem SCRM zapojení zákazníka do procesů firmy (reakce na jeho podněty atp). CRM je komplex technologií (aplikačního a základního software, technických prostředků), podnikových procesů a personálních zdrojů určených pro řízení a průběžné zjišťování vztahů se zákazníky podniku, a to v oblastech podpory obchodních činností, zejména prodeje, marketingu a podpory zákazníka i zákaznických služeb. Přínosy CRM: • zlepšení organizace obchodní činnosti firmy, vztahů se zákazníky, zprůhlednění obchodních procesů, jejich přesná evidence, aktualizace a archivace historie • zdokonalení sledování obchodních příležitostí, sledování a řízení prodejního cyklu u stávajících i nových zákazníků, • upřesnění odhadů budoucích tržeb, kvalitním a jednoduchým nástrojem na řízení a analýzu obchodu. • podpora řízení kampaní • sledování a analýzy chování zákazníků (trhu) Funkcionalita CRM. Poskytuje čtyři základní způsoby uplatnění, které v podniku mohou být nasazovány i samostatně: 1. Aktivní (active) CRM (pozn.: tohle členění uvádí jen (BASL‚ 2008)) 2. Operativní (operational) CRM 3. Kooperační (collaborative) CRM 4. Analytické (analytical) CRM Aktivní (active) CRM. pozn.: Aktivní CRM uvádí jen Basl (BASL‚ 2008) • Základem CRM je aktivní centralizovaná databáze, která podobně jako ERP podporuje automatizaci procesů. Operativní (operational) CRM - operační CRM • Cíl - zefektivnění klíčových procesů kolem zákazníka, zejména front office • Poskytuje podporu podnikovým procesům, tzv. „front office", a zahrnuje prodej, marketing a služby. Každá interakce se zákazníkem je přidána do historie komunikace a každý pracovník může z této databáze čerpat v případě potřeby vhodné informace. • Do operativní části se řadí všechny aplikace, které řeší operativní záležitosti a kontakty v kooperaci se zákazníkem. Dle Gartner Group se člení na tyto dílčí aplikace: Automatizace prodeje (SFA - Sales Force Automation) - monitoruje a zaznamenává všechny úrovně prodeje, včetně kontaktu se zákazníky i potřebného budoucího kontaktu. Obsahuje systém sledování prodeje, který automaticky vyhledává potenciální zákazníky pro dané produkty a kontaktuje je. Je schopna předvídat prodeje a řídit zakázky. Modernější SFA systémy umožňují zákazníkům vyjádřit svoje aktuální potřeby přímo za pomoci programů, ve kterých si zákazník sám upraví, v rámci výrobcem daných možností produkt, o který má zájem. Tento model se velmi prosazuje v automobilovém průmyslu, ale i v custom shopech specializovaných výrobců. Navrhuje a později se podílí na realizaci automatizace obchodních procesů. Automatizace podnikového marketingu (EMA - Enterprise Marketing Automation) - podporuje a využívá analýzy vedoucí k rozdělení zákaznického spektra firmy. Vytváření marketingových plánů a kampaní, sledování konkurence, významných obchodních případů atd. Využívá dat z datových skladů i datových kanálů, a to především z internetu. Nejvyspělejší aplikace jsou schopny téměř okamžitě reagovat na změny zákaznických preferencí a upravovat tak svojí nabídku v reálném čase. Zákaznická podpora a servis (CSS - Customer Service and Support) - nástroje pro specifikaci požadavků na servis, objednávky přes web, e-mail apod. Využívá kontaktních center, která jsou prostředkem pro komunikaci se zákazníky. Jejich předchůdcem byla call centra a helpdesky. Multikanálová komunikace. Centra musí splňovat - rychlost, přístup operátora k datům o zákazníkovi, ukládání informací o hovoru, dobré osobní komunikační schopnosti operátora. Kooperační (collaborative) CRM • Cíl - optimalizace interakcí se zákazníkem, vícekanálová komunikace • Zahrnuje přímou interakci se zákazníkem, používají se různé komunikační kanály: - Ke dříve používaným způsobům kontaktu se zákazníkem (pošta, faxy, telefonické kontakty a osobní schůzky) se přidávají internet, elektronická pošta a zejména interaktivní aplikace na webu - to vše je řízeno pomocí kontaktních center Kontaktní centra: Kontaktní centra pracují v přímé vazbě k centrální zákaznické databázi - jsou to aplikace založené na centrálním přístupu firmy k zákazníkovi Zajišťují komunikaci se zákazníkem a poskytují zaměstnancům podporu při komunikaci se zákazníkem tím, že mu dodávají dříve nashromážděná data, zaznamenávají informace o právě probíhající komunikaci a umožňují aktualizovat data o zákazníkovi. Uchovávají se informace o kontaktu se zákazníkem (vyřizování stížností, informace o předání a druhu nabídky, odesílaní marketingových materiálů, informace o podpisu kontraktu) Analytické CRM • využívá informace získané v operativní části. Data uložená v datových skladech analyzuje s cílem co nejlépe reagovat na zákazníkovo chování a požadavky. • nachází mj. uplatnění při segmentaci zákazníků, kdy na základě společných znaků dělí zákaznickou základnu na různými znaky spojené skupiny. Důvodem takového dělení je fakt, že firma není schopna se každému zákazníku věnovat individuálně. Cílem pak to, aby měl zákazník pocit, že s ním firma individuálně jedná. • na aplikaci segmentace zákazníků částečně navazuje i analýza chování zákazníků. Predikuje chování zákazníka či skupin zákazníků na základě statistických metod a historie komunikace se zákazníkem. Dokáže rozlišit kupní potenciál zákazníka nejen na základě jeho určitých znaků, ale také např. informací o jeho současné rodinné, finanční a životní situaci. • Cíl - analýza zákaznických dat z různých pohledů, například k účelu: - Navrhování a realizace cílených marketingových kampaní vedoucí k jejich vyšší efektivnosti - Analýza zákaznického chování sloužící k podpoře rozhodování o produktech a službách (např. stanovaní vhodných cen, vývoj nových produktů apod.) - Manažerského rozhodnutí, jako například finanční předpovědi a analýzy profitability zákazníků • Analytická část CRM se obvykle využívá data z operativního a kooperačního CRM (lze použít i jiné aplikace ERP, e-Business) - pro zpracování využívá technologií Business Inteligence. - Kombinace CRM a BI se označuje jako Customer Intelligence (CI) - Customer Intelligence - většinou se bere jako synonymum pro analytické CRM Customer Intelligence (CI) - představuje komplex aplikací, zaměřených na poznání zákazníka, jeho hodnoty, preferencí, rizikovosti nebo pravděpodobnosti odchodu ke konkurenci. Jde o predikci chování zákazníků. Za účelem splnění tohoto cíle využívají řešení CI spojení systémů BI a CRM.

Modelování při analýze a návrhu IS/ICT

Co je modelování - výhody/nevýhody. Podrobněji popište a srovnejte procesní, objektové a datové modelování. Kritické faktory modelování. Notace UML a BPMN. Modelování • popis přesně vymezené části reality, která nás zajímá a která bude obsahem aplikace • je možné používat slovní popisy i grafické diagramy • podporuje lepší pochopení požadavků, čisté návrhy a lépe udržovatelný systém Modelování slouží k: • prozkoumat možnosti změn bez vlivu na reálné činnosti • vystopovat příležitosti vylepšení • odhadnout a měřit účinky zamýšlených změn • demonstrovat a sledovat průběh analýzy • předávat nápady jasně a efektivně mezi členy projektového týmu • model aktuálního stavu x cílového stavu • analýza vlastností reality na základě modelu • řízení reality na základě modelu Vizuální modelování • způsob přemýšlení o problémech a jejich znázornění pomocí obrázků, efektivní technika Model • je konkrétní forma popisu informačního systému • jedná se o zjednodušení reality • obvykle nejsme schopni plně pochopit komplexní systém jako celek nebo ani není záměrem modelovat celou realitu • tvorba modelu pomáhá lépe porozumět systému tím, že ukáže shrnutá pozorování v přehledné formě • široká škála modelů [umožňují zachycení business procesů, věcné problematiky i architektury systému] • Model je formulován jako systém, tedy souhrn prvků a jejich vazeb. Konkrétní povaha prvků i vazeb je dána použitým hlediskem (data/operace) • Zvláštní význam v modelu zaujímají jeho hraniční prvky, tedy prvky, které mají vazby s okolím systému (modelu). Těmito prvky je definována hranice systému, tedy jeho kontext. • Obsah modelu (souhrn jeho prvků a vazeb) je vždy objektový, tedy každý prvek modelu musí odpovídat některému objektu reálného světa. • Vnitřní struktura systému (uspořádání prvků) je vždy poplatná struktuře světa. Model slouží k: • (grafické) znázornění stávajícího nebo vytvářeného systému, • specifikace struktury nebo chování systému, • základ pro (re)konstrukci systému, • k pochopení problémů, • komunikace s ostatními zúčastněnými na projektu (uživatel, analytik, programátor atd.) Kritické faktory úspěchu modelování • Řešitelé musí být dostatečně seznámeni s problematikou projektu - velmi důležitá je komunikace s klientem • Musí dodržovat předem domluvenou jednotnou techniku modelování (notace UML, BPMN) • Dobré rozvržení práce - např. proces jako je fakturace musí být přiřazen specialistovi na finanční procesy (kryje se s klíčovými faktory úspěchu) • Je nutná kontrola konzistence - při použití více typů modelů - aby každý z nich nevypovídal něco jiného (více typů a pohledů pomáhá k většímu pochopení požadavků na IS/ICT, a proto při nekonzistenci modelů může dojít při budoucím vývoji k problémům) • Snaha o zachycení všech aspektů, které jsou pro zkoumání systému podstatné a eliminace aspektů nepodstatných Výhody a nevýhody • Výhody viz předchozí část. • Nevýhody: o Modelování složitých procesů a zachycení všech podstatných věcí a při tom zachování dostatečné čitelnosti modelu o Modelování je vždy zatíženo nějakým přístupem, který určuje co má a nemá být ve výsledném modelu a proč. Procesní modelování K modelování procesu existuje řada různých přístupů a norem, vzniklých různými způsoby a zdůrazňujících různé aspekty procesu, jakož i různé aspekty ignorujících. Základní prvky modelu: • Proces - posloupnost činností jako reakce na událost • Činnost - základní prvek procesu, má vstupy a výstupy • Událost - externí podnět procesu/činnosti • Stav - výsledek nějaké činnosti v systému Proces „Účelně naplánovaná a realizovaná posloupnost činností, ve kterých za pomoci odpovídajících zdrojů probíhá transformace vstupů na výstupy." „Soubor činností, který vyžaduje jeden nebo více vstupů a tvoří výstup, který má nějakou hodnotu pro zákazníka." Další komponenty • Seznam procesů (tabulka v textovém editoru nebo tabulkovém procesoru) • Model návaznosti procesů (model obsahující symboly činností, které znázorňují jednotlivé procesy, a spojnice [jednoduché čáry] vyjadřující návaznosti mezi procesy) • Základní popisná tabulka (jedna tabulka pro každý proces, která popisuje základní charakteristiky procesu) • Model průběhu procesu (model znázorňující návaznosti jednotlivých činností procesů na potřebné úrovni podrobnosti popisu procesu, obsahuje činnost, událost, stav procesu, problém atd.) • Tabulka pro popis konzistencí (zachycuje konzistence [návaznosti] na další dimenze modelování systému) Procesní model Strukturovaně uspořádané informace o všem, co se týká fungování společnosti, tzn. o procesech, zdrojích lidských i technických, produktech a službách, o dokumentaci, cílech společnosti atd. Účel: podporovat procesní řízení společnosti, v rámci něhož umožňuje všem skupinám zaměstnanců společnosti (od managementu až po řadové pracovníky) čerpat a využívat tyto informace v jakýchkoliv souvislostech pro různé účely. Cíle procesního modelování • Simulace reálných procesů, které probíhají v organizaci • Zachytit chování reality podnikových procesů • Grafické znázornění procesů (diagramy procesů) Účel procesního modelování • Optimalizace podnikových procesů • Integrace aplikací a obchodní procesů • Proklad pro analýzy dopadu • Dokumentace systému jakosti - ISO certifikace • Oddělení know-how od lidí • Dokumentace pracovních postupů • Nalezení úzkých míst organizace • Podpora při návrhu IS a ASW • Popis podnikového Workflow • Zjednodušení školení nových pracovníků Principy procesního modelování • Vhodné pojmenování, dodržení grafické notace Objektové modelování Cíl objektového modelování • zachytit strukturu reality • používá se k tomu jazyk UML (obecný a univerzální objektově orientovaný modelovací jazyk, • sloučení několika populárních OO přístupů), složitost je redukována rozdělením do subsystémů a delegováním „odpovědnosti" na jednotlivé objekty Komponenty objektového modelování • objekt - prvek, jev, věc, pojem v reálném světě • třída - kategorie, skupina věcí se stejnými vlastnostmi a stejným chováním (nebo podobným), tj. ve smyslu množina objektů stejného typu • atribut - podstatná charakteristika/vlastnost třídy/asociace • asociace - vztah mezi dvěma objekty • operace - metoda, funkce, kterou může objekt vykonávat Principy • rozložení reality na jednotlivé prvky (objekty), které spolu interagují • každý objekt (věc, prvek, jev, pojem v reálném světě) je něčím jedinečný Diagram tříd • Prozkoumání problémové domény (typy objektů reality) • Analýza požadavků IS => ASW (konceptuální => logický model) • Zachycení detailního návrhu objektově orientovaného SW Doporučené kroky při objektovém modelování: • identifikovat objekty a třídy • připravit slovník dat • určit asociace a agregace • určit atributy objektů a linků • vytvořit hierarchii tříd • verifikace přístupových cest pro dotazy (ověření úplnosti modelu) • iterace a upřesňování modelu • seskupení tříd do modulů Datové modelování Při datovém modelování na základě znalostí o realitě navrhujeme struktury dat, do kterých se budou o této realitě ukládat záznamy. Je to činnost, která vyžaduje důkladnou analýzu skutečnosti, a schopnost převést získané představy do databázových struktur. V souhrnu se této činnosti říká návrh databáze. Analýza informací o skutečnosti - je náročná, a vyžaduje zkušenosti, jasný rozum, někdy dovednost obratně se ptát lidí, kteří danou skutečnost znají. Principy datového modelování První část - analýza informací o skutečnosti • je náročná, a vyžaduje zkušenosti, jasný rozum, někdy dovednost obratně se ptát lidí, kteří danou skutečnost znají • v první fázi se vytváří konceptuální schéma a poté konceptuální datový model • viz otázka 32. Konceptuální modelování obsahu databáze Druhá část - převod do databázových struktur • následuje převod na fyzický datový model pro konkrétní databázový systém • rozložení složených atributů, přiřazení datových typů, výběr Primary Key, rozhodnutí o realizaci dědičnosti, vyřešení vztahů 1:1, vztahy m:n do samostatné tabulky, samostatné entitní typy do samostatné tabulky • normalizace (normální formy) Komponenty • K zachycení datového modelu na konceptuální úrovni se používá řada různých modelovacích nástrojů. Mezi nejznámější patří různé modifikace tzv. ER(A) diagramů. Entita • Rozlišitelný a identifikovatelné objekt reality. Entitou je např. Karel Novák, katedra informačních technologií, motor Š-135-12333. • Entity se slučují do entitních množin (typů). Každá množina musí mít uveden identifikátor (tj. minimální množinu atributů, které zajišťují jednoznačnou identifikaci entit v této množině) • Rozlišují se následující typy entit: o Obecná o Silná/kmenová/základní/regulární (existují nezávisle na jiných entitách) o Slabá/popisná o Vazební/asociativní (realizuje vazbu mezi entitami) o Generalizace/nadtyp (vytvoření entity vyšší úrovně z dvou a více entit nižší úrovně) o Specializace/podtyp Notace • hraje důležitou roli v každém modelu • způsob interpretace obrázků/modelů a nástroj, který zaručuje konzistentní proces vývoje Trojúhelník úspěšnosti • Pro úspěšný projekt je třeba mít tři předpoklady - notaci, proces a nástroj. • Máme-li notaci, ale nevíme, jak ji použít (proces), budeme neúspěšní. Máme-li silný proces, který ale neumí komunikovat s notací, budeme neúspěšní. A jestliže nemáme možnost dokumentovat výsledek naší práce (nástroj), pravděpodobně budeme opět neúspěšní. UML • Více o UML viz otázku 14. Modelovací jazyk UML BPMN • Zkratka od Business Process Modeling Notation. Jedná se o grafickou notaci (soubor grafických objektů a pravidel pro jejich spojování) určenou pro modelování procesů. Definuje pouze jediný diagram - BPD (Business Process Diagram).

Hlavní důvody prosazení parametrizovatelných řešení aplikačního softwaru

Co je to parametr - definice. Co je parametrem v řešení ASW - navrhněte si jejich klasifikaci do skupin a v každé skupině definujte parametry. Pokuste se pro každý typ parametru uvést příklad. Jaký je vztah ke customizaci? Ve kterých fázích životního cyklu ASW o parametrizaci uvažujeme? Parametrizace = konfigurace nebo nastavení ASW za účelem pokrytí potřeb podniku Customizace = nadřazený pojem, customizace buď formou přeprogramování nebo parametrizace Z pohledu podniku: chci mít raději parametrizovatelný ASW, mám větší jistotu. Z pohledu vývojáře: raději budu vyvíjet parametrizovatelný ASW, mám větší šanci to víckrát prodat. Co to je parametrizovaný aplikační SW Aplikační software zakoupený „jako krabice" - jedná se o software prodávaný na trhu, nikoliv o individuální záležitost. Souhrnně se nazývá jako typový aplikační software (TASW). Nabízí skupiny parametrů, které si může podnik nechat na míru nastavit tak, aby pokryly jeho potřeby. Jedná se např. o parametry ve skupinách: • Organizační struktura podniku • Způsob vedení financí • Výběr požadovaných modulů • Informace o hierarchii produktů • Přizpůsobení legislativě daného státu (TASW je obvykle prodáván nadnárodně) • Obrazovky a styl TASW pro potřebu uživatelů a respektování firemní kultury/identity Parametry mohou být buď nastavitelné, nebo fixní. O parametrizaci ASW podnik uvažuje vícekrát. Nejdříve definuje požadavky na parametry, poté hledá odpovídající ASW. Nakonec při jeho implementaci provádí nastavení všech požadovaných parametrů. a Hlavní výhody TASW • rychlost implementace - kupuje se prakticky hotový produkt, který se jen nastaví • nižší cena pořízení - náklady na vývoj softwaru jsou rozloženy mezi více zákazníků • profesionální řešení každé komponenty i celého IS/IT • best practices - nejlepší zkušenosti širokého okruhu uživatelů • možné řešit řadu nových požadavků pouze jiným nastavením parametrů místo přeprogramováním • větší šance na garanci kvality a stabilitu rozvoje Odlišnosti řešení TASW od IASW IASW - individuální aplikační software = software vytvářený „na zelené louce" podle potřeb zadavatele, respektuje přesně jeho potřeby a jeho funkčnost vychází z konzultace se zadavatelem (koncovými uživateli). TASW - typový aplikační software - software vytvářený a standardizovaný pro určitou homogenní skupinu zákazníků, v podstatě krabicový systém. Vlastnosti: • nižší nároky na přesnost specifikace požadavků • vyšší pravděpodobnost konfliktu s podnikovými normami a standardy • větší standardizace procesů • větší specializace pracovníků dodavatele, ale vyšší nároky na komunikaci a řízení • snadnější dimenzování technologické infrastruktury • širší výběr provozních prostředí • nižší nároky na testování (prověřená funkcionalita) • vyšší flexibilita na změnu předvídatelných požadavků (díky parametrizaci), ale nižší flexibilita na ostatní požadavky • standardní realizace upgrade - průběžný vývoj dodavatelem.

Databázové systémy - charakteristika

Databáze je definovaná pomocí jistého schématu (který umožňuje porozumět datům v databázi) a existuje nezávisle na aplikačních programech. Centrální správa databáze je organizována prostřednictvím programového vybavení - systému řízení bází dat (SŘBD či anglická zkratka DBMS). Ten systém spolu s databází tvoří databázový systém (DBS). Kvůli volnému používání výše uvedené terminologie, pod pojmem databáze může být myšlen jak SŘBD, tak DBS. („Databázové systémy" Jaroslav Pokorný a Michal Valenta) Databáze = integrovaná počítačově zpracovávaná množina persistentních dat Systém řízení bází dat (SŘBD / DBMS) = množina programových prostředků, který umožňuje: • vytvoření databáze • použití databáze (manipulaci s daty v databází -S,I,U,D) • údržbu a správu databáze Databázový systém (DBS) = SŘBD + Databáze Důvody pro vznik databázových systémů: • Vyšší datová abstrakce - SŘDB zahrnují manipulační jazyky pro práci s datovými strukturami vyšší úrovně. • Nezávislost aplikačních programů na změnách ve fyzickém uložení dat - při změnách ve fyzické struktuře báze dat není třeba měnit aplikační programy, protože se na data obracejí na logické úrovni. • Ochrana dat před neoprávněným přístupem a poruchami - SŘDB kontroluje, zda uživatel je oprávněn používat příslušná data příslušným způsobem, a obsahuje mechanismy pro znovuvytvoření báze dat po selhání systému nebo poškození vnějších médií. • Odstranění redundance - každý údaj, i když se vyskytuje několikrát v různém kontextu, je v bázi dat ve většině případů uložen pouze jedenkrát. • Sdílení dat - na rozdíl od situace, kdy každý aplikační program vytváří své vlastní datové struktury, při využití SŘDB mohou být taktéž data používána několika uživateli; důležitou funkcí SŘDB je zajištění paralelního přístupu ke stejným datům z několika programů. • Podpora transakčního zpracování • Údržba integrity databáze Výše uvedené problémy klasických metod hromadného zpracování dat vedly ke vzniku a rozvoji databázových systémů. Mají následující vlastnosti: • Struktury datových souborů jsou odděleny od aplikačních (uživatelských) programů. • Přístup k datům je možný jen prostřednictvím programů databázového systému. • Data je možné vyhodnotit jakýmkoliv způsobem. • Je umožněn přístup více uživatelů současně a vyřešena ochrana dat před zneužitím. Důležitost databází • Vzrůstající velikost ukládaných dat • Internetová úložiště (FB) • Rostoucí složitost a různorodost dat • Rostoucí požadavky na výkon a dostupnost • Rostoucí závislost na přesné a včasné informace Požadavky na databáze • Vyšší level abstrakce • Management pro komplexní objekty (GIS, mapy atd.) • Management polo-strukturovaných dat • Management nestrukturovaných dat • Management složených (sloučených) dat např. dvojice - manžel + manželka Nezávislost dat Nezávislostí dat se v databázových systémech rozumí možnost změnit definice dat na nižší úrovni abstrakce, aniž by se tím ovlivnila definice na vyšší úrovni abstrakce. Mluvíme o dvou úrovních nezávislosti dat: 1. Fyzická nezávislost dat umožňuje změnit fyzické schéma a přitom nedojde ke změně logického schématu ani uživatelských aplikačních programů. 2. Logická nezávislost dat umožňuje změnit konceptuální úroveň popisu dat, aniž by bylo třeba přepisovat aplikační programy. Na externí úrovni se přitom nemění pohled těch uživatelů, jichž se změna logického schématu přímo netýká. Sdílení dat Skutečnost, že se data sdílejí všemi aplikačními programy má kromě snížení redundance také příznivý vliv i na celkovou integrovanost informačního systému. Centralizací dat do sdílené databáze se odpovědnost za správu dat přenesla z jednotlivých agend na databázový systém. V rámci uživatelské organizace se předpokládá, že jeho provoz má na starosti pověřená osoba, tzv. administrátor (správce) databáze. Do jeho kompetence patří vytváření schémat na všech úrovních a definice a popis vazeb mezi jednotlivými úrovněmi. Externí schémata vytváří přitom podle požadavků uživatelů. Transakční zpracování Transakce slouží k zajištění konzistence a řízení víceuživatelského přístupu. Vlastnosti transakce - ACID: • A (atomicity) = transakce je jako celek, musí proběhnout celá nebo žádná • C (consistency) = transformuje DB z jednoho konzistentního stavu do jiného konzistentního • I (indepedency) = transakce jsou nezávislé, změny prováděné jsou neviditelné pro ostatní tr. • D (durability) = efekty potvrzené transakce jsou uložené do databáze OLAP = zpracování vícedimenzionálních dotazů (datové sklady) OLTP = zpracování velkého množství relativně malých transakcí Integrita Konzistence databáze= data v databázi zachycují stavy, které jsou v popisovaném světě MOŽNÉ Integrita databáze= databáze je v konzistentním stavu. Integritní omezení =pravidla pro zajištění správnosti a konzistence uložených dat: • ENTITNÍ - Výskyt každé entity musí být jednoznačně identifikovatelný. Musí existovat primární klíč! (unique) • REFERENČNÍ - Cizí klíč obsahuje pouze hodnoty, které existují v jemu odpovídajícím primárním klíči! • DOMÉNOVÁ - Atribut může obsahovat pouze přípustné hodnoty omezené integritním pravidlem! (check, trigger) Integrita (celistvost) databáze je stav, v němž jsou data v plném rozsahu přípustná a využitelná v aplikačních programech a mezi hodnotami položek souborů databáze platí vztahy, které jsou stanoveny k zaručení sémantické korektnosti databáze. Jinak se dá také říci, že je to stav, kdy hodnoty dat jsou správné, konzistentní a aktuální. K narušení integrity může dojít chybami technického i základního programového vybavení, chybami v aplikačních programech a v datech apod. Příkladem integritního omezení je požadavek, aby věk oprávněného voliče bylo celé kladné číslo větší nebo rovné 18. Procedury ukládání dat musí být takové, aby systém řízení báze dat v případě vzniku chyby mohl obnovit data beze ztrát. Z tohoto důvodu je SŘBD vybaven funkcemi kopírování celé databáze anebo jejich částí na záložní paměťové médium. V případě, že došlo ke ztrátě integrity, použije se kopie databáze k její obnově. Vzhledem k většinou velkým rozsahům databáze a z toho vyplývající časové náročnosti kopírování nelze jej provádět příliš často, což způsobuje ztrátu dat, která byla získána v době od posledního kopírování po poruchu. Pokud je riziko ztráty velké anebo má značné důsledky, používají se jemnější kopírovací procedury. Jednou z nich je použití tzv. žurnálové záložní paměti (redo logy), kam se při každé změně dat v databázi zaznamená stav menších oblastí (záznamu, bloku) před změnou a po změně. Náhodný přístup • Agendové zpracování je zaměřené jednoúčelově a předpokládá, že všechny požadavky na výstupní informace jsou specifikovány předem • Při používání programu se velmi často objeví dodatečné požadavky na jeho funkci, jejichž realizace si může vyžádat značné programátorské úsilí • V databázovém systému vzhledem k nezávislosti dat na aplikačních programech je snadné napsat nový aplikační program, který zabezpečí provedení požadované akce • V mnoha případech jde o požadavek na výběr dat podle zadaného kritéria • Většina SŘBD je vybavena speciálními uživatelskými jazyky neprocedurálního charakteru, které jsou orientovány na využití ne-programátory. • Možnost realizace náhodného přístupu k databázi výrazně zlepšuje využití dat v informačním systému a je často jedním z hlavních důvodů přechodu na databázovou technologii zpracování dat. Kritéria pro výběr databázového systému Základní funkční a technologická kritéria o Architektura - jaký typ (relační, objektově relační, síťový, stromový, lineární) - jakou podporuje architektury - client/server - jaká data podporuje - jestli lze používat SQL o Rozhraní k HW a SW Výkonnost Zabezpečení a utajení dat - jestli je možné utajení, kódování dat, dešifrování, jaký katalog Rozšířenost Podpora od dodavatele - tuzemské firmy, školení, ceny, možnost ukládat, vyhledávat a třídit česká data, problém s tříděním „ch" Cena Další rozvoj

Řešení dimenze "Bezpečnost a kvalita IS/ICT"

Dimenze bezpečnost a kvalita Dimenze zahrnuje otázky bezpečnostní politiky, předcházení rizikům a zajištění kvality IS/ICT. Cíl • Analýza rizik, řešení prevence nebo nápravy incidentu • Zajištění dodávky ICT aby nebyla narušena kontinuita byznysu • Minimalizovat chyby v ICT (90 % incidentů je kvůli chybě v SW) • Zajištění bezpečnosti ICT a dat proti o Neoprávněnému přístupu - realizace přidělení přístupových práv o Odcizení - ochrana dat i fyzického IT o Zničení - pomocí zálohování a obnovení Kvalita • Není-li možné zajistit kvalitu produktu ex-post, je nutné zajistit, aby do testování přicházel už kvalitní produkt - tzn., že bzp a mng dimenze musí zajistit, aby každá fáze poskytla kvalitní výstup • Východiska o Kvalitní motivovaný tým a přesné zadání o Kvalitní metodika tvorby a akceptace o Kvalitní managment tvorby a akceptace • Problémy obvykle způsobují následující příčiny, viz obr. Hrozby a problémy • 78 % hrozeb pro firemní IT ze strany zaměstnanců • 18 % hrozeb ze strany virů a škodlivého SW • 3 % firem aktualizuje bezpečnostní politiku v reakci na novou hrozbu Metodiky • COBIT - informační bezpečnost je jedna z oblastí této metodiky, měření výkonnosti, určení kritických faktorů a porovnání • ITIL - neustálé měření a zlepšování kvality Certifikace IS/ICT V České republice jsou na klíčová IS/ICT řešení pracující např. s utajovanými informaci kladeny zákonné požadavky. Zákon o ochraně utajovaných skutečností vyžaduje (opakovanou) certifikaci těchto řešení. Certifikaci provádí NBÚ. Mezi důvody k certifikaci patří ochrana citlivých údajů, posílení důvěryhodnosti, zákonná povinnost nebo bezpečnostní standardy (např. mezinárodní ISO/EIC). Zákon č. 148/1998 Sb., o ochraně utajovaných skutečností a o změně některých zákonů ukládá v § 51 povinnost certifikace informačního systému používaného k nakládání s utajovanými skutečnostmi. Norma ISO/IEC 17799 - zavádění a certifikaci systémů řízení organizace (tj. kvalita, prostředí, informace). Předmětem certifikace je zavedený a dokumentovaný systém řízení bezpečnosti informací (ISMS) v organizaci. Prakticky to znamená, že pokrývá všechny aspekty získávání, zpracovávání a ukládání informací prostřednictvím (a nejenom) informačních systémů a technologií organizace. Norma ISO/IEC 13335 - Předkládá základní pojetí a modely managementu, podstatné pro úvod do řízení bezpečnosti IT. Bezpečnostní IT norma - rozumí se všechny aspekty souvisící s definováním, dosažením a udržováním: důvěrnosti, integrity, dostupnosti, individuální zodpovědnosti, autenticity a spolehlivosti. BS7799-2:2002 - Specifikace s návodem pro použití - ISMS, viz otázka 84. Systém řízení bezpečnosti informací (ISMS)

Druhy zpracování SW aplikace

Dávkové zpracování, interaktivní zpracování, distribuované, řízené událostmi, v reálném čase, centralizované, decentralizované. Provoz a návrh. Způsob zpracování určuje, jakými podněty jsou jednotlivé funkce aplikace startovány, jaká je doba odezvy funkcí a jaký vztah má zpracování funkcí aplikace k procesům reálného světa. Aplikace může kombinovat více způsobů zpracování. Dávkové zpracování Požadavky na zpracování a související vstupní data jsou shromážděny v dávce a zpracovány najednou bez účasti uživatele. Použito u technologií, které jsou náročné na dobu zpracování a nevyžadují v průběhu zpracování nároky na komunikaci s uživatelem. Výhody • sdílení zdrojů počítače mezi mnoha uživateli a programy • odložení zpracování dávek do doby, kdy je počítač méně vytížen • odstranění prodlev způsobeným čekáním na vstup od uživatele • maximalizace využití počítače zlepšuje využití investic Nevýhody • dlouhá a nezaručená doba odezvy • nemožnost zásahu v průběhu zpracování dávky Dávkové zpracování je přes svoji historii velmi populární jak v prostředí unixových systémů prostřednictvím služby at a cron, tak v prostředí MS Windows prostřednictvím Plánování úloh. Unixové systémy využívají pro psaní dávek skriptovací jazyky (různé shelly, Perl, Python, ...). Systémy Windows NT obsahují mírně pokročilejší cmd.exe, v současnosti pak Windows Script Host a pokročilý Windows PowerShell. Příkladem dávkového zpracování je např. tisk. Interaktivní zpracování Uživatel je v přímém kontaktu s počítačem a jeho požadavky jsou zpracovány okamžitě a s garantovanou dobou odezvy. Jeden požadavek je zpracován jednou transakcí, která je dále dekomponována na jednotlivé transakční kroky. Transakčním krokem je úsek algoritmu od přečtení jednoho vstupu z terminálu uživatele po výstup výsledku zpět na terminál uživatele. • doba trvání jednoho transakčního kroku by neměla překročit 1 sec., aby se zajistila plynulá komunikace mezi uživatelem a počítačem, př. vyřizování telegramu na poště • v současné době nejrozšířenější metoda zpracování sociálně-ekonomických aplikací, př. tvorba dopisu pomocí textového editoru, tvorba obchodních dokumentů pomocí ekonomických aplikací • výhody - uživatelsky příjemnější • nevýhody - náročné na tvorbu, náročné na potřebu počítačových zdrojů, aktivita musí vyjít od uživatele - mohou být i ignorovány významné události Distribuované zpracování Využívá několik navzájem propojených počítačů (serverů), obvykle specializovaných - mail server, datový server; umístěných v různých lokalitách, na kterých jsou napojeny inteligentní i neinteligentní koncové stanice • distribuovaná aplikace má rozděleny jednotlivé části a umístěny na jednotlivých počítačích a vzájemně spolu komunikují - viz. klient/server architektura a vícevrstvá architektura • výhoda - přizpůsobení aplikace podnikovým procesům, výpadky nemají takový dopad jako při centralizované architektuře, kratší doba odezvy z lokálních DZ presentační systém, umožňuje efektivně využívat kapacity počítačů zapojených do počítačové sítě • nevýhoda - vyšší nároky na koordinaci zpracování aplikace, komplikace při zajišťování konzistence DZ, komplikovaná ochrana a zabezpečení aplikace Zpracování řízené událostmi Typické svým startováním událostmi, které nastávají v reálném světě (datové, časové, mimořádné). Zvyšují automatizaci, a tím i efektivnost podnikových procesů. Jedná se vlastně o typ interaktivně zpracované aplikace. • Výhody - zvyšují automatizaci a tím obvykle i efektivnost podnikových procesů, zajišťují, že na každou definovanou událost bude reagováno Zpracování řízené v reálném čase K dosažení maximální možné efektivity práce je nutné pracovat v reálném čase. Aplikace, pracující v reálném čase, jsou globálně nazývány „on-line aplikace". On-line aplikace se principiálně od off-line aplikací liší tím, že okamžitě komunikují s nadřazeným serverem a pracují s centrální databází na serveru. Tím pádem není zapotřebí pravidelně synchronizovat data, protože ta jsou stále aktuální. Aplikace vyvíjíme tak, aby byly co možná nejpřehlednější a jejich ovládání bylo intuitivní. Protože jsme výrobci, neseme plnou odpovědnost za kompatibilitu a funkčnost s hardwarem, který v rámci řešení dodáváme... Centralizované zpracování Využívá jednoho hlavního počítače, na který jsou napojeny inteligentní koncové stanice. Veškerá data i programy jsou umístěny na hlavním počítači, resp. na několika serverech umístěných v jedné lokalitě. Na koncových stanicích jen lehký klient • výhoda - relativně jednoduchá tvorba aplikace a jednoduché řízení provozu aplikace, nízké náklady provozu, jednoduché řešení konzistence DZ • nevýhoda - přetížení hlavního počítače, který nemůže být specializován, ale musí realizovat všechny části algoritmů všech aplikací včetně zpracování grafického rozhraní pro všechny komunikující uživatele, výpadek postihne všechny uživatele systému Decentralizované zpracování Založeno na samostatných počítačích, mezi kterými není žádný komunikační kaná. Komunikace mezi počítači nemůže být řízena propojením přes off-line přenášená data • Výhoda - umožňuje práci v oddělených lokalitách, které nejsou na sobě závislé • Nevýhoda - značná nekonzistence v datové základně podniku, narušení plynulosti podnikových procesů, použitelné pouze jako přechodová varianta v případě, kdy mezi vzdálenou lokalitou podniku a centrem neexistuje vhodná přímá komunikační cesta S výběrem (rozhodnutím) druhu zpracování aplikací souvisí i rozhodnutí o návrhu a provozu dané aplikace. Toto rozhodování souvisí s výhodami a nevýhodami jednotlivých zpracování, a s principy jejich fungování (činnosti).

Konceptuální modelování obsahu databáze

ER (Entity Relationship) modelování se používá pro abstraktní a konceptuální znázornění dat. Spočívá ve využití základních konstruktů jazyka pro tvorbu diagramů a v metodice tvorby těchto diagramů - základní myšlenkou je, že databáze uchovává fakta o entitách a o vztazích mezi entitami. Výsledkem je ERD (Entity Relationship Diagram, ER diagram). Zásady • Minimalizace redundance (normalizace) • Maximalizovat znovupoužitelnost (dědičnost) • Maximalizovat výkonnost (de-normalizace, metody, database tuning) • Minimalizovat nároky na uložení dat (compression) P3A - princip tří architektur Smyslem P3A je postupně upřesňovat datový model tak, aby zcela odpovídal požadavkům využívané databázové technologie. Stejně tak je naopak žádoucí, aby model v první vrstvě byl, pokud možno, abstraktní a tech. nezávislý. Konceptuální - model reality • Model obsahu datové základny na konceptuální úrovni (tj. nezatížený jakýmikoliv implementačními a technologickými implementacemi) o KSR - model obsahující základní entitní množiny, vztahy a jejich atributy. Jedná se o hrubý model vytvořený za účelem poznání zkoumané reality. o KSD - popis obsahu datové základny za účelem přesné specifikace obsahu datové základny. Předběžný návrh datové základny Logický - Popis způsobu realizace systému v termínech jisté třídy technologického prostředí (lineární, relační, hierarchické, síťové datové struktury) Např. u RDM - doplnění cizích klíčů. Při transformaci do relační se řídí pravidly: • Každá entitní množina je transformována do jedné relační tabulky. Identifikátory entitní množiny se stanou atributy tvořícími primární klíč relační tabulky. • Vztah z konceptuálního modelu je v relačním modelu vyjádřen cizím klíčem • Vztah M:N z konceptuálního modelu je v relačním modelu vyjádřen vazební relační tabulkou a dvěma cizími klíči. • Generalizace / specializace je transformována do relačního modelu dat několika variantami: o jednou relační tabulkou na úrovni celé hierarchie, o relačními tabulkami na úrovni specializovaných entitních množin, o relačními tabulkami na úrovni generalizující entitní množiny i na úrovni specializovaných entitních množin. • Využívá se taktéž metoda normalizace dat o Cíle: vytvořit co nejvěrnější obraz v modelovaném světě existujících entitních množin zajistit interní konzistenci datového modelu, resp. databáze, minimalizovat redundance maximalizovat stabilitu datových struktur o Sada normálních forem (první, druhá, třetí, boyce/codd, čtvrtá, pátá). Fyzický - Popis vlastní realizace systému v konkrétním implementačním prostředí (doplnění i typu indexu, velikosti, rozmístění pracovního prostoru apod.). Je dán • Způsobem uložení dat o Sekvenční = Sekvenční způsob uložení dat není využíván pro uložení dat v databázových systémech. Bývá používán pro zálohování databázových souborů. o Přímé = hodnotě primárního klíče jednotlivých záznamů je přiřazena (vypočtena) určitým algoritmem (hashing algorithm) adresa uložení záznamu na paměťovém médiu • Způsobem přístupu k datům o Sekvenční o Přímé o S využitím dalších mechanismů (řetězení, indexy)

Informační etika

Etika se zabývá rozhodováním a jednáním jednotlivce ve vztahu k ostatním (z řečtiny se jedná o morální povinnost). Informační etika je „oblast morálky uplatňované při vzniku, šíření, transformací, ukládání, vyhledávání, využívání a organizaci informací." Jako jeden z oborů etiky vytváří kritický rámec pro posuzování morálních hledisek práce s informacemi, dopadu moderních informačních technologií na společnost. Informační etika se bezprostředně týká knihovnictví, informatiky, publikační činnosti a žurnalistiky. Ze širšího hlediska se však informační etika dotýká všech činností souvisejících s informacemi, tedy i například politiky, učitelství atd. Informační etika bývá často zaměňována s počítačovou etikou, která se věnuje společenským dopadům moderních počítačových technologií. Pod informační etiku zároveň spadají konkrétní oblasti spojené s praxí, například: • kyberetika a netiketa, zejména s ohledem na sítě a Internet; • knihovnická etika; • novinářská etika; • mediální etika, aj. Ve většině těchto oblastí je etické chování kodifikováno v podobě morálních kodexů. Čtyři oblasti informační etiky podle Richarda O. Masona (z knihy od Radvákové) Soukromí (privacy) Týká se toho, jaké informace si lidé mohou ponechat pro sebe a jaké musí sdílet dalším subjektům a za jakých podmínek ICT technologie tak zvyšují potenciál pro sledování, sdílení, ukládání informací Přesnost informací (accuracy) Týká se autenticity, přenosti a věrnosti informací o skutečnosti Vlastnictví informací (property) Řeší, kdo vlastní informace, kdo vlastní informační kanály. Problémy s duševním vlastnictvím jsou dnes hodně aktuální. Vytvořit informaci nemusí být těžké, ale je těžké zjistit, kdo informace používá Tento problém se snaží řešit: audotrská práva, patenty, obchodní tajemství Dostupnost informací (accessibility) Týká se toho, k jakým informacím má osoba přístup a za jakých podmínek. S přístupností souvisí vzdělanost. V informační společnosti musí občan zvládat 3 dovednosti: 1. Musí mít intelektuální dovednosti k pochopení informace (číst, psát, počítat) 2. Musí mít přístup k informačním technologiím - telefony, počítače, televize 3. Musí mít přístup k informacím samotným V různých oblastech světa, však dochází k rozdílům - vznik digitálních propastí Digitální propast = rozdíl mezi temi, kteří disponují přístupem k technologiím a těmi, kterí tento přístup nemají Záměry informační etiky Karel Janoš uvádí mezi jinými tyto cíle, zaměřené především na význam informační etiky pro informační pracovníky: • Poukázat na potřebu a význam informační etiky pro profesionální i neprofesionální pracovníky pohybující se ve sféře informací. • Zvýšit úroveň a profesionalitu informační práce. • Zabezpečit, aby se informační pracovníci (včetně knihovníků) nepropůjčovali k činnostem neslučitelným se zásadami informační etiky. • Prevence nesprávného zacházení s informacemi. • Přispět k pozitivnímu působení informací na morální rozvoj společnosti. Rafael Capurro pojímá informační etiku mnohem šířeji, jako „deskriptivní teorii, vysvětlující mocenské struktury ovlivňující přístup k informacím a tradicím v různých kulturách a epochách" - a zároveň hodnotí morální přístupy a tradice v informačním sektoru z hlediska jednotlivce i společnosti. Informační etika podle Capurra hodnotí a vysvětluje: • Vývoj morálních hodnot v informační oblasti. • Vytváření nových mocenských struktur v informační oblasti. • Informační mýty. • Skryté rozpory a záměry v informačních teoriích a praxi. • Vývoj etických konfliktů v informační oblasti. Vývoj informační etiky • Základní podmínkou etiky je svoboda; právo na svobodu informací bylo kodifikováno pro oblast sdělovacích prostředků v roce 1948 na zasedání OSN - dokument mj. uvádí tyto zásady: • říkat pravdu a šířit znalosti bez zlého úmyslu, • usnadnit řešení ekonomických, sociálních, lidských problémů volnou výměnou informací, • omezit falešné a tendenční informace, • určit práva a povinnosti médií, • eliminovat cenzuru a nelze-li, určit podmínky jejího fungování. V témže roce byla přijata Všeobecná deklarace lidských práv, která v článku 19 uvádí:„Každý má právo na svobodu přesvědčení a projevu (...) a zahrnuje právo vyhledávat, přijímat a rozšiřovat informace a myšlenky jakýmikoli prostředky a bez ohledu na hranice.". Ve 40. letech formuloval Norbert Wiener myšlenky kybernetiky; předvídal, že kybernetika s nástupem počítačů přinese nové společenské a etické problémy. Wiener sice nepojmenoval informační etiku, popsal však základní principy spravedlnosti jako fundamentální pravidla na kterých by měla stát informační společnost. Ve druhé polovině 70. let Walter Maner začal vyučovat nové odvětví etiky: počítačovou etiku. Maner tvrdil, že „počítače přináší zcela nové etické problémy, které by neexistovaly, pokud by počítače nebyly vynalezené." Informační etika jako samostatný obor se začala formovat během 80. let. V roce 1980 publikovali Kostrewski a Oppenheim článek Ethics in Information Science, kde se věnují etice v kontextu informační vědy, především s ohledem na vědeckou práci. (ibid.) Na téma navázal Rafael Capurro řadou dalších článků. V roce 1985 v Moral issues in information ethics shrnuje dosavadní debatu a blíže se věnuje rozdělení na mikroetické a makroetické problémy. Ve stejném roce James Moor publikoval článek What is computer ethics?. Podle Moora moderní technologie vedou k situacím, kde není nastavená politika používání, vzniká tak „politické vákuum" (policy vacuum) které vytváří „konceptuální zmatky" (conceptual muddle). Počítačová etika by měla poskytnout teoretický základ pro odstranění konceptuálních zmatků a nastavení pravidel, která vyřeší etické problémy. V roce 1995 přišla Krystyna Górniak-Kocikowska s radikálním názorem, že počítačová etika se stane globální etikou, která nahradí dosavadní etické systémy (někdy se tato teze označuje jako Górniak hypothesis). V roce 1999 nabídl Luciano Floridi novou teorii informační etiky, která zahrnuje nejenom lidské bytosti, ale chápe vše jako „informační objekty a procesy" které dohromady utváří infosféru. Poškození infosféry označuje Floridi jako entropie, což je „zlo, kterému je nutné se vyhnout." Morální problémy v informační etice Informační etika se zabývá jak praktickými aspekty práce s informacemi, tak globálním vývojem a vlivy působícími na informační společnost. John Ladd proto navrhuje rozdělení na mikro- a makro-etické problémy. Mikroetické problémy Mikroetické problémy se týkají především chování jednotlivců v rámci informačního procesu. Zpravidla se jedná o konkrétní správné a nesprávné způsoby práce s informacemi.Doporučený způsob práce bývá kodifikován do etických kodexů, nicméně jak zdůrazňuje Capurro, etická praxe a kodexy chování by neměly být zaměňovány se samotnou diskuzí o etických problémech. American Society for Information Science v roce 1984 identifikovala mezi jinými tyto problémy: • downloading, • soukromí (úmyslné či nechtěné zveřejnění dat), • copyright (duševní vlastnictví, sdílení software atp.), • stanovení cen (v konkurenčním prostředí), • počítačová kriminalita, • zabezpečení (ochrana hesel atd.), • intelektuální a akademická svoboda, • tok dat napříč zeměmi, • tajení a falšování informací. Makroetické problémy Problémy na makroetické úrovni jsou často předmětem samotné informační vědy. Makroetika se zabývá dopadem informačních technologií na společnost (což úzce souvisí s počítačová etika). Ladd (1997) nabízí obecnější vymezení: „předmětem makroetiky [je] morální posuzování norem, praktik, institucí a zákonů, které jsou budovány na bázi mikroetiky."

Služby IS/ICT

ICT služba • koherentní aktivity a/nebo informace dodávané poskytovatelem ICT služby příjemci služby • je vytvářena ICT procesy, které při svém průběhu konzumují ICT zdroje (HW, SW, data, lidé) • je dodávána na základě dohodnutých obchodních a technických podmínek, jsou součástí smlouvy o poskytované službě = SLA (Service Level Agreement), upřesňují: o komu je dodávána (oprávnění příjemci) o kde, kdy a kým je poskytována o předmět služby (např. funkcionalita aplikace CRM) o jak je poskytována (on-line atd.) o objem poskytované služby (počet oprávněných uživatelů, objem předávaných/zpracovávaných dat atd.) o cena o jaké technologie jsou potřeba na její provoz, jak zajistit její kontinuitu v případě havárie, bezpečnostní pravidla a mechanismy apod. • operace definované nad službou = životní cyklus ICT služby o identifikace, popis a definice potřeby o služba: návrh/design -> vytvoření/sestavení -> testování -> customizace -> nákup/prodej -> instalace/nasazení -> zahájení provozu -> provoz a dodávání služby včetně podpůrných služeb ke službě se vázajících -> monitoring a řízení kvality -> škálování objemu služby -> údržba/modifikace/kontinuální zlepšování -> zpoplatnění -> ukončení provozu • realizace těchto operací nad ICT službami o strategie o architektura o sourcing o integrace o standardizace služeb Typy ICT služeb Informační služba • poskytovatel dodává příjemci požadovanou informaci (např. stav kurzů na burze cenných papírů, předpověď počasí, mapu, knihu, fotografii atd.) • informace dodána v požadované struktuře, formátu a čase • může být využívána v informačních a rozhodovacích procesech příjemce • funkcionalita aplikace produkující tyto informace je důležitá pro poskytovatele, ne příjemce • poskytovatel služby odpovídá za správnost a aktuálnost dodaných informací • na některé z nich se vztahuje autorský zákon (omezuje příjemce v nakládání s informací) • snadná replikace informací s nízkými náklady • poskytovatel např. Google Aplikační služba • předmět: funkcionalita byznys aplikace (např. účetnictví, CRM, e-mail, objednávka letenky atd.) • poskytovatel službu provozuje na vhodné ICT infrastruktuře • data zpracovávaná aplikací jsou buď výhradně zákazníka (účetnictví, CRM) nebo poskytovatele (vyhledávač Google), případně kombinace (objednávka letenky, Google Earth s objekty označenými zákazníkem) • poskytovatel odpovídá za správnost transformace dat, majitel dat (ten, kdo je vkládá) za jejich správnost • služba může podporovat vybrané aktivity podniku (fakturace, objednávka) nebo celý podnikový proces (internetové bankovnictví) • často dodávána s podpůrnými službami (školení uživatelů, help desk, customizace) • významný představitel: SaaS (Software as a Service) o externí poskytovatel poskytuje velkému počtu zákazníků funkcionalitu přes internet o běží na jeho technologické infrastruktuře o SalesForce s aplikací CRM, Google a jeho Google Apps apod. • aplikační služba NENÍ aplikace ICT (jedna služba může využívat víc aplikací) Infrastrukturní služba • předmět: vybudování a provoz ICT infrastruktury (servery, koncové stanice, sítě LAN a WAN, operační systémy, databázové systémy, monitorovací systémy atd.) potřebné pro bezchybný chod aplikací • příklady služeb o služby správy technologických zdrojů o služby komunikačních kanálů (řízení a integrace všech elektronických komunikačních kanálů, které organizaci propojují se zákazníky a partnery - Web, ICQ, e-mail, telefon, naskenovaná pošta, fax atd.) o služby správy dat (uchovávat, zpřístupňovat, archivovat, replikovat a obnovovat data) o služby spojené s řízením rizik a bezpečnosti ICT (důvěrnost, integrita, dostupnost, prokazatelnost, spolehlivost, nepopiratelnost) • nástup cloud computingu -> jiný přístup k členění o IaaS - Infrastructure as a Service (služby bez vývojového prostředí a integračních nástrojů) o PaaS - Platform as a Service (včetně vývojového prostředí a integračních nástrojů) Podpůrné služby • služby potřebné/vhodné pro zajištění služeb informačních, aplikačních a infrastrukturních • školení, implementace, customizace a integrace aplikací, help desk, pomocné služby poradců při návrhu služby, tvorbě kontraktu apod. • v praxi bývají všechny výše uvedené služby úzce provázány - vznikají smíšené služby (např. e-learning - aplikační i informační i infrastrukturní, nakonec i podpůrné pro vyškolení uživatelů)

Architektury IS/ICT

Jeden z klíčových nástrojů tvůrců podnikového IS Význam architektur IS/ICT • podobnost s architekturou domu (stejně jako u stavby domu je potřeba použít vhodné materiály, stroje k vybudování domu či mít předem přesné náčrtky budoucí budovy) • při absenci architektonické představy mohou vznikat různé problémy (zakoupený a nainstalovaný SW nikdo nevyužívá, HW komponenty jsou mezi sebou nekompatibilní, nemožnost realizace některých požadavků uživatelů, tvorba IS bez vhodných CASE nástrojů, různé UI aplikací apod.) -> jedním z možných řešení problémů je právě kvalitní architektura IS Podstata a účel architektur IS • vytváří relativně stabilní rámec řešení IS/ICT (další komponenty se do něj dle plánu postupně začleňují) • významný komunikační prostředek mezi vedením podniku, business analytiky a vývojáři • zajišťuje stabilitu vývoje IS/ICT • umožňuje zohlednit hlavní požadavky na vlastnosti IS/ICT • minimalizuje náklady na chybně zadané projekty nebo na rekonstrukce již neudržitelných IS Architektura je fundamentální uspořádání systému, které tvoří komponenty a vztahy mezi nimi, včetně vztahu k prostředí, a principy, které řídí jeho návrh a rozvoj. • je dokumentovaná pomocí popisu architektury, ten je složen z architektonických pohledů (zájmy zainteresovaných stran na vlastnostech systému) • ten je reprezentován modely • postup: definujeme systém (prvky a vazby mezi nimi), definujeme zainteresované strany a jejich zájmy -> tím jsou určeny pohledy, pro každý pohled definujeme hledisko, vytvoříme modely, souhrn pohledů tvoří popis architektury Kritéria při posuzování: efektivita; nástroj komunikace; náklady tvorby, údržby a provozu; čas; kvalita a bezpečnost; flexibilita; škálovatelnost; rizika; soulad se standardy Přístupy k tvorbě architektur Podniková architektura (EA) • od 80. let, snaha o zvládnutí stále rostoucí komplexity IS a využití rostoucího potenciálu ICT pro byznys • přístup, koncept, prostředek a nástroj, kterým vyjadřujeme fundamentální uspořádání vztahu mezi byznysem a jeho IS, jež vede k naplnění poslání organizace, přičemž respektuje okolní prostředí a konzistentně dodržuje formulované principy návrhu a rozvoje systému) Architektonické rámce • množina zájmů, zainteresovaných stran, předdefinovaných hledisek a pravidel definujících vazby hledisek, které byly definovány pro popis architektury ve specifické oblasti • nástroj pomáhající řešitelům v návrhu a budování EA - zjednodušení a urychlení procesu tvorby architektury, snížení rizika opomenutí důležitého prvku architektury • jejich obsah se liší podle přístupu k tvorbě EA; vhodným řešením je kombinace různých rámců • v současnosti nejpoužívanějšími jsou ITIL a TOGAF (v budoucnu se možná budou vzájemně integrovat) • dalším zajímavým je Zachmanův rámec (dvourozměrná matice, řádky definují role: projektant, vlastník, návrhář, stavitel a dodavatel; sloupce obsahové dimenze: data, funkce, síť, lidé, čas a motivace) -> různé pohledy, různé detaily popsání a analýzy podniku; dnes již na ústupu TOGAF • manuál pro strategické a dlouhodobé řízení a plánování podnikové architektury • je založen na definici 4 základních architektur a jejich vztahů o byznys architektura (byznys strategie, byznys procesy a organizační struktura) o architektura IS: aplikační architektura (aplikace, vazby mezi nimi a vztah aplikací k byznys procesům) informační architektura (struktura a organizace dat v podniku) technologická architektura (HW a SW nutné pro běh aplikací a pro jejich vzájemnou komunikaci) • součást: metoda vývoje podnikové architektury ADM (Architecture development method) o rozděluje řízení podnikové architektury do 8 fází: příprava; vize architektury; byznys architektura; architektura IS; technologická architektura; příležitosti a řešení; plánování migrace; zavedení governance; řízení změn architektury Modelem řízená architektura (MDA) • není založena na žádných nových myšlenkách • s postupem na vyšší úrovně abstrakce množství změn v systému klesá • dopady neustálých změn technologií je možné omezit na část modelu - jeho nižší vrstvy • nejprve tvorba platformově nezávislého modelu (PIM) - věcná funkcionalita a chování systému • mapování PIM na zvolenou platformu (Corba, Java/EJB, XML/SOAP) -> platformově specifický model (PSM) -> pak se generuje implementační kód pro příslušnou technologii • zpětné inženýrství - je možné vytvořit modely již existujících systémů např. pro účely integrace aplikací • MDA generátory aplikují současně i návrhové a architektonické vzory • základem modelovací jazyk UML Architektura orientovaná na služby (SOA) • snaha o zefektivnění ICT a důraz na přínosy v podnikových procesech vede k prosazování konceptu služeb = spojovací článek mezi ICT a podnikovými procesy • hlavní zájem - aplikační služby = poskytování funkcionality SW aplikací byznys procesům o příklady služeb: „založ účet", „rezervuj letenku", „zjisti stav materiálu M na skladu" apod. o spojen zejména s technologií webových služeb a architekturou orientovanou na služby • funkcionalita aplikace je definována jako množina služeb, jež mají přesně definovaný interface (vstupy a výstupy) • podstata SOA - jednotlivé na sobě nezávislé služby založené na standardech • klíčové principy: byznys procesy řídí služby a služby řídí technologii; služby fungují jako abstraktní vrstva mezi podnikovými procesy a technologií; schopnost odpovídat na změny požadavků byznysu je klíčovým požadavkem, který musí respektovat celá architektura • atraktivnost: zvýšení produktivity IS/ICT řešení, snížení nákladů vývoje a nasazení a zkrácení času uvedení na trh Architektury podle MMDIS • určují pro daný systém (podnik, IS podniku, SW aplikace apod.) z jakých konkrétních komponent se bude skládat a jaké budou jejich vzájemné vazby • dále určuje principy vývoje a provozu IS, jejichž cílem je dosáhnout požadovaných vlastností systému (pokrytí požadované funkcionality, dostupnost, včasnost, správnost a důvěryhodnost informací, shoda s legislativou, integrita, standardizace apod.) Byznys architektura • systémem, na kterém architekturu definujeme, je celý podnik a jeho významné okolí (zákazníci, dodavatelé, instituce státní správy) • hlavní komponenty: podnikové funkce, podnikové procesy a podnikové útvary • navazuje na globální podnikovou strategii, kterou rozpracovává tak, že definuje architektonické pohledy a s nimi související architektonické modely: o model významného okolí podniku o funkční model podniku o procesní model podniku o model organizační struktury a model rozmístění útvarů v lokalitách podniku • součástí je návrh vazeb mezi modely (vazby funkčního/procesního modelu na model organizační struktury) - definuje zodpovědnosti a pravomoci jednotlivých útvarů a funkčních míst za podnikové funkce a podnikové procesy (ty jsou centrální = jeden útvar či distribuované = dislokace zodpovědnosti do nižších organizačních úrovní) Globální architektura IS/ICT • systémem, na kterém architekturu definujeme, je IS podniku a jeho významné okolí (IS zákazníků, dodavatelů, institucí státní správy); definice zahrnuje model ICT služeb a katalog ICT služeb • hlavní komponenty: ICT služby -> model ICT služeb a jejich vztahů: o k typům uživatelů (zaměstnancům, zákazníkům atd.) o k funkčním oblastem podniku o k podnikovým procesům, jež služba podporuje o k aplikacím, které zajišťují funkcionalitu služby o k poskytovatelům ICT služeb (určuje, kdo je dodává) • kritéria: je poskytována veškerá funkcionalita a informace, objem a kvalita služeb, cena, přiměřený počet • Více o službách viz okruh č. 21 • dílčí architektury: aplikační, softwarová, datová/informační, technologické infrastruktury (některé či všechny mohou být outsourcované, tudíž se nenavrhují přímo v podniku) Aplikační architektura • definována na IS podniku • hlavní komponenty: SW aplikace, které mohou být pořízený třemi způsoby: IASW, TASW a OSS (viz okruh č. 25) • určuje, jakými aplikacemi (aplikačním SW) je pokryta celková funkcionalita IS a jaké vazby jsou mezi nimi • mezi ICT službami a aplikacemi je obecně vztah M:N • integrace aplikací - ideální situace: technologie a aplikace automaticky spolupracují • špagetová integrace = vazby aplikací 1:1 narůstají a stávají se těžko udržitelné; po vzniku strukturované analýzy a myšlenky jednotné datové základny -> relační databáze • další integrační myšlenka: použít pro řízení podnikových zdrojů jednotný dodavatelský typový SW systém ERP Softwarová architektura • definována na jednom SW produktu, tedy jedná SW aplikaci • hlavní komponenty: programové moduly aplikace • určuje počet programových modulů, ze kterých se bude aplikace skládat, jejich uspořádání a specializaci, vstupní a výstupní data pro každou funkci, vývojové prostředí modulu (programovací jazyk, CASE atd.), provozní prostředí modulu (operační systém, middleware, databáze atd.) a další • kritéria: správné dimenzování aplikace, snadnost údržby a dalšího rozvoje, náklady atd. • různé varianty řešení: o jednouživatelská a víceuživatelská aplikace (single-tenant, multi-tenant architecture) o klient/server architektura (monolitická, dvouvrstvá a třívrstvá) o lineární, hierarchická, vrstvená a síťová architektura Datová/informační architektura • definována na datové základně IS podniku • hlavní komponenty: datové objekty • vychází z analýzy potřebných typů datových objektů a jejich vazeb, na jejichž základě se vytváří konceptuální a následně logický návrh datové základny (entity, vazby, atributy) • finalizace: fyzický návrh (návrh databázových souborů a jejich fyzického uložení) Architektura technologické infrastruktury • definována na provozní platformě aplikací IS podniku • hlavní komponenty: HW komponenty (servery, koncové stanice, počítačové sítě atd.) a komponenty základního programového vybavení (OS, databázové systémy, komunikační systémy, integrační SW atd.) • snaha o jednotnou technologickou architekturu pro všechny aplikace (snižuje provozní náklady)

Rozšiřující moduly podnikových IS a jejich funkcionalita

Jedná se o moduly rozšiřující funkcionalitu ERP na ERP II (Entrprice resource planning) Tyto moduly jsou: • ERP (Enterprise Resource Planning) - Podnikový IS • SCM (Suply Chain Management) - Řízení dodavatelského řetězce • CRM (Customer Relationship Management) - Řízení vztahu se zákazníkem • BI (Business Intelligence) - Manažerský IS Dodatečná specifická funkcionalita modulů • PDM (Product Data Management) - Správa dat vztahující se k výrobku • PLM (Product Lifecycle Management) - Řízení průběhu celého životního cyklu výrobku • SRM (Suplier Relationship Management) - Řízení vztahu s dodavateli • ERM (Employee Relationship Management) - Řízení vztahu se zaměstnanci ERP (Enterprise Resource Planning) ERP představuje balíkový podnikový systém, který umožňuje automatizovat a integrovat většinu vnitropodnikových procesů a sdílet společná data v rámci celého podniku. Do ERP patří kompletní data o výrobku, logistika, finance a lidské zdroje. V ERP vzniká nejvíce dat o podniku, která potom ostatní moduly ERP II využívají. Je primárně určeno pro pořizování a aktualizaci dat. ERP je jádrem aplikační architektury podniku, pokrývá největší rozsah funkcí a procesů podniku. SCM (Suply Chain Management) Aplikace podporující vazby podniku a jeho okolí. Zajišťuje řízení dodavatelských řetězců. Představuje soubor nástrojů a procesů, které slouží k optimalizaci a zefektivnění všech prvků dodavatelského řetězce. Propojuje komunikaci dodavatele a odběratele, a to pomocí ICT. CRM (Customer Relationship Management) CRM je komplex technologií, podnikových procesů a personálních zdrojů určených pro řízení a průběžné zajišťování vztahu se zákazníky podniku. Vztah se zákazníky je řízen v oblastech podpory obchodních činností, zejména prodeje, marketingu a podpory zákazníka nebo zákaznických služeb. BI (Business Intelligence) Manažerské systémy jsou využívány pro podporu strategického rozhodování. Data pro BI jsou získávána z celé databáze ERP II (především tedy SCM a CRM). Nad těmito daty je třeba uvažovat multidimenzionálně (z více úhlů pohledu). Na základě těchto modelů jsou sestavovány statistické ukazatele, které pomáhají při samotném rozhodování. PDM (Product Data Management) Jedná se o technickou část IS využívanou inženýry, která většinou spadá pod PLM. Data se týkají technické specifikace výrobku a to především materiálu potřebného na výrobu výrobku s důrazem na cenu. PLM (Product Lifecycle Management) Životní cyklus produktu se pohybuje po tzv. S inovační křivce, která se skládá ze čtyř fází: Investování, Vstup na trh, Růst, Zralost. Cílem je posun této křivky a její prodloužení pro dosažení nižších ztrát na začátku cyklu a udržení produktu déle při životě. Pomáhá výrobci lépe komunikovat a sdílet informace se zainteresovanými osobami pro dosažení dosažení podpory inovačních procesů a zlepšení konkurenceschopnosti. SRM (Suplier Relationship Management) Řízení vztahu s dodavateli funguje prakticky na stejném principu jako CRM (řízení vztahu se zákazníkem). ERM (Employee Relationship Management) Zajišťuje podporu vztahů mezi podnikem a jeho zaměstnanci. Dále slouží k motivaci zaměstnanců (benefity), pomáhat řídit osobní rozvoj a budovat podnikovou kulturu.

Databázové systémy - srovnání a trendy

Modely dat a databázové systémy Z hlediska způsobu ukládání dat a vazeb mezi nimi dělíme databáze do základních typů: 1. Hierarchický - stromový model dat Data jsou organizována do stromové struktury. Každý záznam představuje uzel ve stromové struktuře, vzájemný vztah mezi záznamy je typu rodič/potomek. Nalezení dat v hierarchické databázi vyžaduje navigaci přes záznamy směrem na potomka, zpět na rodiče nebo do strany na dalšího potomka. Největšími nevýhodami hierarchického uspořádání je složitá operace vkládání a rušení záznamů a v některých případech i nepřirozená organizace dat. 2. Síťový model dat Síťový model dat je v podstatě zobecněním hierarchického modelu, který doplňuje o mnohonásobné vztahy (sety). Tyto sety propojují záznamy různého či stejného typu, přičemž spojení může být realizováno na jeden nebo více záznamů. Přístup k propojeným záznamům je přímý bez dalšího vyhledávání, k dispozici jsou operace: nalezení záznamu podle klíče, posun na prvního potomka v dílčím setu, posun stranou na dalšího potomka v setu, posun nahoru z potomka na jeho rodiče v jiném setu. Nevýhodou síťové databáze je zejména nepružnost a obtížná změna její struktury. 3. Relační model dat Relační databázový model je z uvedených nejmladší a zároveň nejpoužívanější. V roce 1970 byl popsán Dr. Coddem. V současnosti je nejčastěji využíván u komerčních SŘBD. Model má jednoduchou strukturu, data jsou organizována v tabulkách, které se skládají z řádků a sloupců. V těchto tabulkách jsou prováděny všechny databázové operace. Databáze dle relačního modelu musí splňovat tyto dvě vlastnosti: • Databáze je chápana uživatelem jako množina relací a nic jiného. • V relačním SŘBD jsou k dispozici minimálně operace selekce, projekce a spojení, aniž by se vyžadovaly explicitně předdefinované přístupové cesty pro realizaci těchto operací. 4. Objektově-orientované DBS Data v OODBS jsou chápána jako objekty odpovídající přímo entitám reálného světa. Objekty zahrnují data i chování, tj. funkčnost ve stávajících RDBS zajištěnou aplikačními programy. Vlastnosti: • komplexní objekty (kromě relačních tabulek i další typy objektů, např. seznamy, pole. Komplexní objekty možno navzájem skládat, mohou být hodnotou atributu nebo mohou existovat jako samostatné objekty v DB) • identita objektů (DBS zajišťuje unikání identifikaci objektu v rámci celé DB - OID), • logická datová nezávislost (zapouzdření, skrývání dat + zveřejnění rozhraní, tj. hodnoty atributů nejsou přístupné přímo, ale přes definované rozhraní), • třídy a typy (možnost definice typu, resp. třídy, jako popisu společné struktury množiny objektů se stejnými vlastnostmi), • dědičnost (odvozování nových tříd z existujících, nové třídy dědí všechny atributy a chování existující třídy, vícenásobná dědičnost), • polymorfismus (schopnost operací fungovat na objektech více než jednoho typu) Srovnání • Stromové struktury podporují vyjádření vztahů 1:N zatímco síťové a relační i vztahy M:N. • U stromových a síťových struktur je závislost mezi programy a daty. • Relační databáze podporují logickou datovou nezávislost. • Relační databáze mají oproti stromovým a síťovým 2 výhody: 1. data nezávislá na programech 2. neprocedurální manipulace s daty. • Nevýhodou relačních DB systémů je nutnost ukládat pouze jednoduchá data ve formě tabulek (tj. s pevnou délkou). Trendy Hlavní záměr: jednodušení Analytické aplikace nad databázemi se ve stále větší míře musejí umět vypořádat i s daty nestrukturovanými (NoSQL databáze). Důležité přitom je, že sofistikované analýzy potřebují dnes často provádět i manažeři bez speciálních technických dovedností, takže prostředí by mělo umožnit co nejjednodušší zadávání i komplexních dotazů. Požaduje se maximální dostupnost dat a analytických výstupů i při zpracování velkých objemů dat, což podnikům umožní rychlost rozhodování (agilitu). Nezbytností je zajištění integrity dat. Snaha o cenově efektivní provoz celého IT prostředí pak dodavatele databázových systémů nutí podporovat maximální využití hardwaru (konsolidace, práce s různými typy úložišť a pamětí, komprese dat, hardware navržený přímo na míru) i snížení nákladů na administraci celého prostředí. DaaS (database as a service) • Služba by měla být k dispozici zákazníkovi on-demand (na vyžádání), tedy bez nutnosti instalovat a konfigurovat hardware nebo softwar. • Služba by neměla zákazníka zavazovat dlouhodobými smlouvami ani dopředu placenými zálohami. Příkladem mohou být měsíční platby za transakce, skladování atd. • Poskytovatel je odpovědný za správu služby, zákazník nemusí systém upgradovat nebo spravovat. Výhody • Škálovatelnost - schopnost změny výkonu poskytovaného řešení; při nízkém zatížení využívá pouze část serveru, při vysokém je může využít více; klientovi je pak služba vyúčtována podle využitých zdrojů • Snadné používání - není nutné zřizovat si vlastní servery a ani se starat o redundantní systémy, zabývat se nákupem, instalací a údržbou hardwaru pro databázi. • Výkon - databáze není hostovaná lokálně, v závislosti na dodavateli lze získat vlastní ověřování dat, což zajistí přesnost informací. Databáze lze snadno vytvářet a spravovat. • Integrace - databázi lze propojit s dalšími službami (například s kalendářem nebo s e-mailem) • Správa - při velkých databázích je nutná pravidelná optimalizace a čištění, což je zpravidla velmi nákladné. U některých dodavatelích DaaS může být správa součástí služby, za finančně výhodných podmínek. • Virtuální rozdělení a repliky - při cloudových databázích se automaticky vytvářejí repliky dat na více serverech, což zajišťuje vysokou bezpečnost dat. Nevýhody • Bezpečnost - mezi základní bezpečnostní opatření, které musí být dodrženy v poskytování služeb v cloudu, je řízení přístupu, ochrana komunikace mezi zákazníkem a poskytovatelem, bezpečnostní opatření, šifrování uloženého obsahu, separace systémů v rámci cloudu, důsledný monitoring. Prakticky všechna tato opatření by měla být zajištěny bezpečnostními technologiemi, které musí správce takové služby důkladně ovládat. Rizikem je, že mnohým z nich chybí znalosti o možnostech ochrany dat, které jsou uloženy mimo "jejich" lokalitu nebo zprávu organizace. Mezi největší rizika podle ENISA patří: ztráta ovládání bezpečnosti, závislost na poskytovateli, nebezpečné rozhraní a API, interní útoky, ochrana, ztráta a únik dat, nedostatečné a neúplné mazání dat. • Spolehlivé internetové připojení - další nevýhodou může být závislost databází v cloudu na připojení k internetu, protože všechny cloudové služby jsou přes něj poskytovány. V současnosti se tento problém stále více a více eliminuje zkvalitňováním služeb poskytovatelů internetu. • Vlastnictví dat, vázanost na poskytovatele - přenesením dat do cloudu je jejich majitel vázán na poskytovatele, a to i v případě, že dojde k poruše. Mnozí poskytovatelé se před tímto chrání replikováním dat, přesto je zde stále určitá míra rizika. Data nemá majitel na svém serveru, pod svou úplnou kontrolou, ale na serveru někoho jiného a pod jeho kontrolou. Další trendy Stále nová aplikační prostředí vyžadující integrovat data a programy • Rozvoj OR DBS • Zahnízděné databáze v aplikačních programech (Progress) • Rozšíření databázových serverů o aplikační služby Pokroky v HW • Velikost vnitřní paměti umožňuje umístit tabulky a objekty do vnitřní paměti a radikálně mění vyhodnocování dotazů a jejich optimalizaci • Možnost současné práce až desetitisíců uživatelů - nároky na škálovatelnost DBS a dostupnost dat • Zvyšování počtů transakcí - milióny transakcí za minutu Velikost databází • Dosavadní velikost databází v GB a TB • S rozvojem nových typů aplikací (multimediální data, archivy, lidský genom, ..) zvětšení do řádů petabajtů, exabajtů a zetabajtů (10*21) Heterogennost databází • Přístup k více informačním zdrojům, které se vyvíjely samostatně a jsou nyní dostupné prostřednictvím internetu pro uživatele SŘBD typu „Plug and Play" • Zlepšení administrace DBS • „auto" ladění DBS na základě „zkušeností" Federace milionů databázových systémů • volný přístup k integraci - obdoba politických systémů • neexistuje centrální řídící autorita, komponenty federace žijí autonomně, přesto jsou • schopny se chovat jako vyšší celek • řízení globálních transakcí a globální integrity • různé typy federací - nejvolnější založené na schématech importu a exportu: o privátní schéma o exportní schéma (data, ke kterým mohou přistupovat jiné systémy) o importní schéma (data přijímaná od jiných systémů) 172 Přehodnocení tradičních databázových architektur • mobilní databáze • paralelismy • databáze ve vnitřní paměti Unifikace procesů a dat v DBS • zahrnutí aplikační logiky do databází (např. propojení triggerů s pracovními toky - workflows) Integrace strukturovaných a semistrukturovaných dat • výměna různorodých dat (např. dat ze systémů GIS, systémů pro návrh CAD, strukturovaných dat) • využití XML • datové sklady (pumpování dat z OLTP databází, jejích čištění a uložení do speciálních - OLAP databází) • požadavek integrovat netriviální objekty (text, audio, video,...) • nové typy dotazů (např. nelezení souseda v určitém prostoru, nalezení podobného dokumentu atd.) Nepřesné dotazování • v internetu jediné možné • integrace dosud oddělených technologií o strukturované databáze založené na databázovém modelu o textové databáze založené na modelech textu (Booleovské, vektorové,...) • rozvoj univerzálních serverů přináší potřebu Booleovského přístupu o zadání dotazu pomocí množiny termů a logických spojek o odlišnost od přístupu SQL - výsledky dotazu (hity) pouze obsahují dané termy. Přístup je zatížen jistou nepřesností oproti dotazu v SQL, kde data získáme v logické souvislosti dané klauzulí WHERE. • Míry relevance odpovědi o Koeficient přesnosti (podíl počtu vybraných relevantních k počtu všech vybraných objektů) o Koeficient úplnosti (podíl počtu vybraných relevantních k počtu všech relevantních objektů v informačním zdroji) • Současné technologie dostupné na webu poskytují vyhledávání s nízkým koeficientem přesnosti při poměrně vysokém koeficientu úplnosti Další rozvoj OR SŘBD • Uživatelsky definované typy a funkce umožňující zpracování multimediálních dat • Integrace semistrukturovaných dat na bázi XML Vznik nových typů databázových systémů • které budou obsahovat přímo semistrukturovaná data ve formátu XML - databázové systémy řízené obsahem (Content Management Systems) 173 • umožnění manipulací fragmentů textu, řízení verzí, publikace, oddělení obsahu a stylu, integraci se strukturovanými daty atd. Integrace v prostředí internetu • soustředění na vyhledávací systémy • zprostředkující dotazovací systémy (Mediated Query Systems) - rozdělení do tří vrstev o nejnižší - datové zdroje (legacy systems, databáze, aplikace produkující data) o střední - integrační (sw pro transformace, integraci či přidání hodnoty) o nejvyšší - uživatelské rozhraní o datové zdroje jsou začleněny do systému pomocí obálek, které exportují funkcionalitu a data způsobem, který zdroje unifikuje o obálky jsou implementovány na základě dotazovacích možností zdrojů (SQL, fulltextové vyhledávání, dotazovací jazyk nad XML apod) o součástí architektury jsou ontologie, tj. organizované množiny pojmů, prostřednictvím kterých se uživatel může domluvit s databází speciální případ metadat

Databázové systémy a jejich optimalizace

Optimalizace v databázových systémech Důvodem optimalizace je nedostatečná výkonnost systému vzhledem k stanoveným výkonnostním požadavkům IS/ICT. Cíle optimalizace: • optimalizovat výkonnost dbs • optimalizovat náklady (strojový čas, kapacita paměti, čas přenosu, práce programátorů, čas uživatelů,...) • nalezení optimálního poměru mezi kapacitou paměti, časem potřebným pro výběr dat, časem potřebným pro aktualizaci dat Výkonnost je charakterizována: • dobou odezvy (čas mezi odesláním požadavku a získáním výsledku) • počtem transakcí zpracovaných za minutu • dostupností (po jakou dobu je systém dostupný a plní své funkce) • škálovatelností (možnost přizpůsobit výkon vzhledem ke změně nároků požadavků) Kvalitu datové základny ovlivňují • tvůrci základního programového vybavení (operační systémy, databázové systémy,...), • analytici a návrháři IS/ICT, • tvůrci aplikačního programového vybavení, • správce databáze. Výkonnost dbs je ovlivňována činnostmi ve všech etapách životního cyklu IS/ICT dle MMDIS (od informační strategie až po provoz a údržbu IS/ICT). Způsoby zvýšení výkonnosti dbs • konfigurace a úprava struktury dbs s cílem snížení spotřeby zdrojů (např. snížení počtu I/O operací, zátěže pevných disků, přenosů dat po síti) • navýšení kapacit (většinou hw komponent) • úprava požadavků na dbs (např. jejich rozložení s cílem dosáhnout nižší zatížení systému, či využití paralelního zpracování) • Normalizace vs Denormalizace o Normalizace - redukuje množství dat v db odstraňováním redundancí o Denormalizace - proces porušování pravidel daných normalizací dat (vzdalování se od modelu světa v db) s cílem zvýšení výkonnosti systému - nevýhody musí být převáženy přínosy takovéhoto řešení výhodou je např. snižování potřeby spojování tabulek, uchování aktuálních hodnot odvozených atributů nevýhodou je např. snížení rychlosti aktualizačních operací (I, U, D), často komplikovanější aplikační řešení, obtížnější zajištění integrity databáze • Umístění dat do vnitřní paměti • Vhodný výběr datových typů (číselné typy oproti CHAR, zvážení nezbytnosti použití UNICODE a BLOB; použití neurčené hodnoty (NULL), v některých dbs je vymezen prostor pro typ CHAR, i když žádná hodnota není vložena.) • Rozmístění dat na databázových stránkách, tabulkových prostorech • Využití indexů (množství, druh a způsob organizace indexů - zrychlení výběru, zpomalení aktualizace. Čas na uložení řádku tabulky se skládá z času na uložení dat (relativně konstantní doba) a z času na záznam indexu (doba závislá na nutnosti reorganizovat - vyvážit indexní struktury) • Využití shlukování dat (cluster) - více tabulek (často propojovaných) sdílí stejné databázové stránky. Cluster (datový shluk) je objekt, který obsahuje skupinu tabulek, které spolu sdílí jeden nebo více společných sloupců (klíč clusteru) a jsou uloženy ve stejném datovém bloku • Optimalizace dotazů (cílem vybrat plán provedení operací nad relačními tabulkami tak, aby vyhodnocení bylo co nejefektivnější), Typy optimalizátorů • optimalizace založená na indexech a velikostech relací • optimalizace založená na relativní selektivitě relačních operátorů (pro daný operátor se určuje v procentech velikost selekcí z původní relace) - např. předpoklad že operátor = má menší selektivitu než operátor >. • optimalizace řízená syntaxí - podobná, ale optimum zajišťuje programátor - podmínka s největší selektivitou je umístěna jako první, záleží na tom, jak se napíše dotaz - nevýhody - znovu dělat po změně, není v čase trvanlivá • statisticky řízená optimalizace - využívá informace z katalogu dat a nad těmito statistickými údaji provádí optimalizaci. Kroky optimalizace příkazu 1. Kontrola syntaxe a sémantiky příkazu 2. Převedení dotazu do interní reprezentace (např. operací relační algebry). 3. Optimalizace použitých operací na základě obecných pravidel pro možné úpravy posloupnosti operací, např.: (A join B) where (restrikce B) => (A join (B where restrikce B) 4. Výběr vhodných způsobů realizace příkazů (výběr manipulačních procedur s fyzickými datovými strukturami. Pozn.: Teprve v tomto kroku jsou zohledněny přístupové mechanismy, aktuální hodnoty dat a způsoby uložení. 5. Vytvoření variant, ohodnocení a výběr nejvhodnější varianty realizace příkazu - hledání "nejlevnějšího" plánu provedení příkazu. 6. Generování kódu. Nástroje Oracle pro ladění výkonu DBS a jejich možnosti Zástupci nástrojů: • Analyze Wizard (umožňuje vytváření statistik objektů databáze, identifikovat zřetězení tabulek či shluků) • Explain Plan (zobrazuje plán provedení - jednotlivé kroky určené optimalizátorem SQL příkazu) • Advanced Events (sleduje systémem či uživatelem definované události, např. překročení počtu zámků, obsazení určitých fyzických prostorů) • Oracle SQL Analyze (umožňuje ladit příkazy SQL nejvíce náročné na zdroje) • Virtual Index Wizard (testuje dopady změn konfigurace indexů na výkonnost systému, na optimalizátor SQL příkazů) Možnosti nástroju ORACLE pro ladění Parametr DB_BLOCK_BUFFERS • určuje, kolik paměti si bude pro čtení dat z databáze instance alokovat jako vyrovnávací paměť. • paměťová oblast obsahuje více údajů než jen aktuální data navrácená z dotazu. Jsou zde uložena i další data, np. informace z pohledů systémového katalogu (datového slovníku). Počet vstupně-výstupních operací se dá snížít zvýšením tohoto parametru (tj čím více informací dbs načítá během jednoho přístupu k disku do vyrovnávací paměti, tím je lepší výkon) Parametr SHARED_POOL_SIZE • určuje, kolik paměti si bude instance alokovat pro uložení příkazů jazyka SQL po syntaktickém rozboru. • při prvním provádění příkazu jazyka SQL je proveden jeho syntaktický rozbor a je uložen do této paměti. Je-li poté prováděn stejný příkaz jazyka SQL, dbs z této oblasti paměti načte již "rozebranou" verzi příkazu - sníží se tak zatížení CPU. • je založený na váhovém ohodnocení (hledání nejmenších cen). • je-li hodnota parametru OPTIMIZER_MODE nastavena na CHOOSE, vezme optimalizátor do úvahy velikost tabulky, hodnoty indexů, rozsah zřetězení a další faktory. Následně optimalizátor určí, jaký prováděcí plán při max. výkonu nejméně zatíží CPU a vstupně- výstupní zařízení. Parametr OPTIMIZER_MODE • určuje optimalizátoru dbs, kterou metodu či způsob má použít při vyhodnocování příkazů jazyka SQL. • v implicitním nastavení CHOOSE optimalizátor volí optimalizační pravidla na základě statistik vytvořených pro tabulky použité v příkazu jazyka SQL. Nejčastější chyby při použití dbs Oracle - příklady: • Nevyvážená architektura - silný výpočetní výkon, ale poddimenzované I/O systémy • Špatná správa spojení - časté připojování a odpojování aplikace od databáze. • Chyby při nasazení a migraci - při migraci z vývojového prostředí nebo starší implementace se může stát, že schéma vlastnící tabulky nebylo úspěšně zmigrováno. Příkladem jsou chybějící indexy nebo chybné statistiky. Dochází pak k přetěžování databáze. • Nevyužití komprese tabulek - tj. zejména zbytečné místo na disku, zatěžování I/O systémů, nároky na zálohování.

Modelovací jazyk UML

Podotázky: Charakteristika UML. Význam modelování v jednotlivých fázích projektu. Podrobně popište diagram tříd, případů užití a sekvenční diagram. Charakteristika UML UML (Unified Modeling Language) je grafický jazyk pro vizualizaci, specifikaci, návrh a dokumentaci programových systémů. Jeho vývoj započal v roce 1994, současná verze 2.5. Spolu s první verzí jazyka UML vznikla i rigorózní metodika RUP (která UML využívá pro grafické znázornění systému a jeho chování). UML popisuje 14 typů diagramů rozdělených do 3 skupin: • Statická struktura aplikace • Dynamické chování • Organizace a správa aplikačních modulů UML nabízí standardní způsob zápisu jak návrhů systému včetně konceptuálních prvků (business procesy a systémové funkce), tak konkrétních prvků (příkazy programovacího jazyka, databázová schémata a znovupoužitelné programové komponenty). UML podporuje objektově orientovaný přístup k analýze, návrhu a popisu programových systémů. UML definuje diagram tříd, objektový diagram, diagram balíčků, diagram komponent, diagram vnitřní struktury, diagram nasazení, diagram případů užití, diagram aktivit, stavový diagram, sekvenční diagram, diagram komunikace, diagram přehledu interakcí a diagram časování. Význam modelování v jednotlivých fázích projektu Význam modelování klesá s pokročilostí fáze vývoje. Ve fázi specifikace požadavků lze kromě slovního popisu použít hrubý diagram případů užití. Ve fázi analýzy je přínos modelování velmi významný. S výhodou je zde možno použít diagram případů užití, diagram tříd a sekvenční diagram. V obou uvedených fázích je model platformě nezávislý. Ve fázi návrhu jsou již existující diagramy doplněny o platformě závislé prvky. Fáze testování může být s pomocí modelů zjednodušena, zejména vzhledem ke snadnější identifikaci kritických míst projektu apod. Modelování po zavedení projektu lze využít v případě rozšiřování projektu, což je však lépe označit za nový projekt a začít opět fází specifikace požadavků. Diagram tříd (Class diagram) Diagram tříd (Class Diagram) představuje „statický pohled na modelovaný systém" a jeho úkolem je znázornit typy objektů v systému a jejich vztahy. Návrh tříd, jejich odpovědností a následné vytvoření tohoto diagramu je jedním z prvních a základních kroků analýzy navrhovaného programového systému. Díky tomu, že diagram tříd zachycuje pravidla modelovaného systému, je nejdůležitějším podkladem jak pro forward engineering, tak pro reverse engineering. Při tvorbě diagramu tříd je nutné vzít v úvahu jeho účel a rozlišit, zda potřebujeme vyjádřit požadavky na modelovaný software nebo získat podrobný popis designu atd. Z tohoto důvodu se rozeznávají tři úrovně modelu tříd - konceptuální, designová a implementační. Konceptuální (doménový, analytický) model Vytvářen za účelem analýzy požadavků na software. Obsahuje pouze tzv. byznys třídy (business classes). U jednotlivých tříd se uvádí obvykle jen názvy klíčových atributů a některých klíčových metod. Pokud je diagram vytvářen pouze za účelem znázornění relací mezi třídami, je možné atributy i metody vynechat. Designový model (model návrhu) Vychází z modelu konceptuálního, který rozšiřuje a zpřesňuje například viditelnost atributů a metod, datové typy apod. Dále do modelu přidává třídy uživatelského rozhraní (presentation classes) a třídy obsluhující systémové události (control classes). Z jedné třídy v analytickém modelu se tedy může stát v designovém modelu více návrhových tříd. Implementační model Zaměřuje se na „grafické zobrazení implementovaného kódu". Mezi prvky používané v diagramu tříd lze zařadit: • třídy (classes) • asociace (associations) • rozhraní (interfaces) • balíčky (packages) Třída je „abstrakcí objektů se stejnými vlastnostmi, stejným chováním a stejnými vztahy k ostatním objektům." Každá třída má popsány vlastnosti a operace (souhrnně označovány jako features), které může provádět, a omezení definující, jak mohou být jednotlivé třídy propojeny. Vlastnosti tříd jsou v UML označovány jako atributy, operace ve fázi návrhu jako metody (v rámci analýzy se používá označení operace). Třídy jsou vzájemně propojeny pomocí asociací. Diagram případů užití Diagram případů užití se používá k popisu chování systému z hlediska uživatele a zachycuje typy uživatelů, kteří se systémem pracují a jaké činnosti v rámci systému vykonávají. Umožňuje znázornit funkční požadavky na systém tím, že popisuje interakci mezi ním a uživateli. Prvním krokem procesu tvorby softwaru je specifikace softwarových požadavků. Existují dvě skupiny požadavků - funkční požadavky a nefunkční požadavky. Případy užití jsou schopny postihnout pouze funkční požadavky, tedy požadavky určující, jaké chování by měl navrhovaný systém nabízet (co by měl systém dělat). Nefunkční požadavky, které představují omezení či vlastnosti systému, zachytit nedokážou. Proto je nutné doplňovat model případů užití i například modelem požadavků, který ale není součástí UML. V rámci analýzy se vytváří model případů užití, který je tvořen nejen diagramy případů užití, ale měl by obsahovat i specifikaci případů užití a definici aktérů. Modelování případů užití spočívá v následujících krocích: • Nalezení hranic systému • Vyhledání aktérů • Nalezení případů užití • Specifikace případů užití • Určení alternativních scénářů • Opakování předchozích bodů, dokud nedojde k ustálení případů užití, aktérů a hranic systému Aktér popisuje uživatele vně systému, který je s ním v interakci. Tímto uživatelem nemusí být pouze fyzická osoba, ale například i jiný systém či hardwarové zařízení. Jeho název pak vyjadřuje jeho roli v systému. Aktéry můžeme rozlišovat na primární a pomocné. Pro vyjádření rolí, které jsou určeny osobám, se obvykle používá figurka, zatímco obdélník zobrazuje roli, kterou hrají jiné systémy. Pokud je figurka použita pro roli systému, je doplněna o stereotyp <<system>>. Případ užití specifikuje část funkcionality systému, kterou využívá aktér a která plní určitý cíl. Je charakterizován množinou scénářů případů užití prováděných za stejným cílem, tedy sekvencí kroků popisující interakci uživatele se systémem. Vztahy mezi aktéry a případy užití jsou nazývány komunikační asociace či relace (stereotyp <<communication>>) a znázorňují mezi nimi plynoucí tok informací. Mezi případy užití mohou být použity tři typy vztahů: • include: při opakování stejného případu užití na více místech • extend: nadstandardní případ užití při splnění dané podmínky • generalizace/specializace: tento poslední typ vztahu je používán také mezi aktéry, kdy umožňuje znázornit předky či potomky aktéra Hranice systému (v UML 2.0 označovány jako subjekt) jsou v modelu znázorněny rámečkem kolem případů užití a názvem modelovaného systému. Sekvenční diagram (Sequence diagram) Sekvenční diagram je nejvíce používaným diagramem interakcí. Zachycuje grafický průběh zpracování v systému v podobě zasílání zpráv. Sekvenční diagram nejčastěji zobrazuje chování a spolupráci jednotlivých objektů v rámci jednoho případu užití. Pro popis chování jednoho objektu napříč více případy užití se používá stavový diagram. Zprávy mohou být v sekvenčním diagramu posílány jak mezi jednotlivými objekty, tak i třídami či dokonce aktéry. Proto se prvky, které mezi sebou v diagramu komunikují, nazývají souhrnně klasifikátory (classifiers). Z každého klasifikátoru vede tzv. čára života (lifeline), která reprezentuje, jakým způsoben se instance určitého klasifikátoru účastní interakce. Diagram komponent Diagram komponent zobrazuje komponenty, které tvoří aplikaci, systém nebo podnik. Komponenty (v UML 1.x označovány jako fyzické struktury) reprezentují modulární součásti systému se zapouzdřeným obsahem, které je možné samostatně prodávat i aktualizovat. Diagram komponent znázorňuje komponenty (components) a závislosti (dependencies) mezi nimi, popřípadě i rozhraní. Komponenty mohou obsahovat atributy a metody a být vnitřně strukturovány. Diagram aktivit Diagram aktivit (Activity Diagram) je typem diagramu interakcí, který se používá pro popis procedurální logiky, byznys procesů či pracovních postupů. Umožňuje také graficky modelovat jednotlivé případy užití jako posloupnost akcí. Diagram aktivit prodělal od svého vzniku mnoho úprav a i s novou verzí UML 2.0 došlo k jeho změnám. Zatímco v UML 1.x byl chápan jako speciální případ stavového diagramu, UML 2.0 už tyto dva diagramy nijak nespojuje. [Fow2003] Diagram získal novou sémantiku založenou na formálním grafickém modelovacím jazyce Petri Nets (Petriho sítě). Stavový diagram Stavový diagram zachycuje jednotlivé stavy objektu a přechody mezi nimi. Stavové diagramy se používají především pro popis chování určitého objektu napříč více případy užití a jejich vznik je spojen už s prvními objektově orientovanými technikami. Základními prvky stavového diagramu jsou stavy, přechody a události. Pokud to CASE nástroj umožňuje, může být diagram ohraničen rámem s názvem objektu. V případě, že se stavy nepohybují v cyklu, měl by diagram obsahovat počáteční (initial state) a koncový stav (final state). Stav (state) je dle situace v životě objektu, během níž objekt splňuje nějakou podmínku, provádí nějakou operaci nebo čeká na událost. Přechody (transitions) představují podmínky pro přechod objektu z jednoho stavu do druhého. V diagramu jsou značeny linií vedoucí od jednoho stavu k druhému. Jejich popis se skládá ze tří základních částí: událost [podmínka]/ akce. K vykonání uvedené akce a přechodu do dalšího stavu může dojít pouze v případě, pokud je při vzniku události uvedená podmínka (guard) pravdivá. Událost (trigger signature) je „specifikací určitého výskytu něčeho v čase a prostoru." Pokud není v diagramu uvedena, znamená to, že přechod do dalšího stavu probíhá automaticky. Rozdělení diagramů dle skupin

Řešení funkční/procesní dimenze IS/ICT

Podotázky: Nástroje k modelování procesů, úroveň zralosti procesu, druhy událostí, související modely v MMDIS, co je KBPR (Knowledge based process reengineering), jaký je vztah události a procesu, jaký je vztah funkcionality aplikace a podnikového procesu Funkční a procesní dimenze je zaměřena na procesy probíhající v podniku a možnost jejich podpory funkcemi IS. Cíl: návrh a realizace procesní a funkční architektury IS. Zvýšení efektivnosti podnikových procesů (rychlost, kvalita, náklady) Funkční pohled Funkční pohled (na hierarchii funkcí) je statický, popisuje hierarchický rozklad funkcí IS. Nejnižší úroveň popisuje elementární funkce (transakce), které mají uživatelé IS/IT k dispozici. • struktura funkcí/činností podniku a jejich přiřazení k jednotlivým útvarům • struktura funkcí IS a jejich přiřazení k jednotlivým typům uživatelů • Z hlediska zvolené úrovně podrobnosti je funkce dále nedělitelnou jednotkou procesu. Elementární funkce je dána: • svými vstupy (vstupní data a vstupní události, na které je funkce citlivá), • výstupy (výstupní data a události, které zpracování funkce vyvolává) • řídícími daty (nejsou předmětem zpracování, ale popisují pravidla, která musí být dodržena při transformaci) • a algoritmem, který transformuje data vstupní na data výstupní. Příklad: výpočet měsíční mzdy pracovníka: a) vstupní data - počet odpracovaných hodin, hodinová sazba, počet dnů dovolené atd. b) vstupní události - dny, kdy musí být stanovena mzda pracovníka c) výstupní data - hrubá mzda, daň ze mzdy, sociální a zdravotní pojištění d) řídící data - zákon o dani z příjmů, o sociálním pojištění a další předpisy Procesní pohled Dynamika chování podniku při výskytu různých událostí (např. objednávka nového automobilu, žádost zaměstnance o dovolenou). Na událost reaguje podnik procesem, který je reprezentován sítí činností a funkcí IS/IT. Proces = Účelně naplánovaná a realizovaná posloupnost činností, ve kterých za pomoci odpovídajících zdrojů probíhá transformace vstupů na výstupy. Charakteristika procesu • Využívá zdroje - lidi, finance, materiál, technologie, energie ... • Iniciován událostí, končí dosažením jednoho z možných stavů • Zpracovává vstupy a produkuje výstupy • Lze měřit • Má prioritu vzhledem k ostatním procesům. Priorita určuje jeho význam pro dosažení podnikových cílů • Činnost může být prováděna: - pouze člověkem („zkoušení studenta"), - strojem („vylisování nárazníku auta"), - člověkem za podpory stroje („přišití knoflíku") - člověkem za podpory ASW („zaevidování známky ze zkoušky") - ASW („hlídání poklesu zásoby pod limit") • Funkce = požívána často jako synonymum činnosti - Funkce IS = činnost prováděná informačním systémem Co je předmětem řešení funkční a procesní dimenze MMDIS? • Procesy probíhající v podniku a možnost jejich podpory informačním systémem. Řešením této dimenze v jednotlivých fázích vývoje IS/ICT je navrhována a realizována funkční a procesní architektura IS/ICT • Zaměřeno na procesy probíhající v podniku a jejich podporu přes IS. • Z hlediska významu pro výkonnost podniku jsou funkční/procesní dimenze spolu s datovou/informační dimenzí nejvýznamnějšími řešitelskými dimenzemi Proces (MMDIS) • Zajímá nás dynamika chování podniku při výskytu různých událostí a efektivita tohoto chování. Jsou tyto procesy efektivní? Můžeme najít lepší řešení? • Procesy se dají graficky znázornit a modelovat v orientované rovině. • Pro podnik je to významné, když potřebujeme odlišit typy procesů - hlavní, řídící a podpůrné. • Mají i určitou prioritu (do jaké míry přispívají organizaci). • Rozlišujeme dále vnitropodnikové nebo mezipodnikové procesy. • Mají úrovně vyspělosti Úrovně procesního pohledu (MMDIS) 1) Úroveň návrhu procesu 2) Úroveň taktického řízení procesu 3) Úroveň operativního řízení procesu 4) Zpracovatelská úroveň procesu + neustálé zlepšování a optimalizace procesu Události dle MMDIS: • informační - spojena se vznikem (příchodem) určité informace, • časovou - spojena s určitým časem, • mimořádnou (chyba) - spojena s narušením normálního průběhu procesů. Procesy se liší: • významem pro podnik: hlavní (core business), podpůrné (jednou skupinou podpůrných procesů jsou řídící) • prioritou - do jaké míry přispívají k naplnění cílů organizace • vnitropodnikové (privátní), mezipodnikové (veřejné-SCM, CRM) • Vyspělostí • detailností svého popisu a mírou využití kreativity pracovníků (viz KBPR) Řízení podnikových procesů Nejprve se určí cíle procesů, požadované výstupy procesů (kdy, kde, s kým), poté následuje podrobnější definice a optimalizace procesů a souvisejících metrik. Následně se musí procesy naplánovat (včetně jejich kapacit). Po celou dobu řízení podnikových procesů se musí tyto procesy monitorovat, kontrolovat a zároveň se musí analyzovat hodnoty metrik. Nakonec nastává realizace procesů. Zlepšování procesů • eliminace zbytečných činností (netvořících přidanou hodnotu) • spojování činností • paralelizace činností • standardizace průběhu a standardizace výstupů • delegace pravomoci - rozhodování na nižší úrovni hierarchie • zvýšení důvěry - snížení počtu kontrol • zvýšení úrovně znalostí pracovníků a jejich motivace • jediné kontaktní místo pro zákazníka procesu • centralizace vs. decentralizace (např. centra sdílených služeb) • automatizace Pozor na pouze technické přístupy neuvažující dimenzi „lidé" (změna stylu myšlení, motivace, kvalifikace) Úrovně zralosti procesů - CMM (Capability Maturity Model) Dle COBIT: • 0 - neexistující proces - podnik si není vědom toho, že existuje situace, kterou je nutné řešit, při výskytu události reaguje spontánně • 1 - ad-hoc proces - podnik si je vědom situace k řešení, je však volen ad-hoc přístup, který je závislý na přístupu jednotlivce nebo konkrétní situaci. • 2 - opakovaný, ale intuitivně prováděný proces - proces je prováděn různými jedinci podobným způsobem, neexistují však formální postupy jak situaci řešit - řešení je závislé na schopnostech jedinců a je náchylné k chybám • 3 - definovaný proces - proces je standardizován, zdokumentován a jeho dodržení je zajištěno pomocí odborné přípravy jedinců. Postup však není příliš propracovaný, vychází z existující praxe a je nepravděpodobné, že budou odhaleny případné odchylky a chyby • 4 - řízený a kontrolovaný proces - management monitoruje naplňování cílů a dodržování stanovených procedur, podniká nápravné kroky, kde je to nutné. V omezené míře jsou využívány nástroje a automatizace • 5 - optimalizovaný proces - proces je doveden do souladu s nejlepšími praktikami. IT je integrováno za účelem automatizace, postupné zlepšování kvality a efektivnosti umožňuje podniku reagovat na změny Model zralosti procesů CMMI (Capability Maturity Model for Integration) - souvisí spíše s oblastí softwarového inženýrství a s procesem vývoje SW - Integrovaný a účinný funkční model řízení - podporuje dva postupy zlepšování -průběžný a postupný. Soubor pravidel, požadavků a doporučení, které mají splňovat firemní procesy, aby byly efektivní, účinné a spolehlivé. Zaměření na procesy vývoje. - CMMI staví na principech TQM (Total Quality Managementu). - Model definován jako „cesta pomáhající neustálému zlepšování úrovně řízení a vývoje". Firmy jsou na této cestě vedeny doporučeními organizovanými obvykle do 5 úrovní („maturity level"), v rámci kterých se postupně zavádí jakostní cíle, nebo do tzv. kontinuálního modelu, ve kterém se sledují cíle, které si firma zvolí a postupně zlepšuje jejich plnění: • Počáteční úroveň (initial) - softwarové procesy jsou náhodné a chaotické - organizace nemají stabilní prostředí pro vývoj a údržbu software, reagují pouze na vzniklé problémy. • Opakovatelná úroveň (repeatable) - organizace mají definovány a zavedeny postupy řízení projektu. - softwarový proces je disciplinovaný • Definovaná úroveň (defined) - organizace má definovány, dokumentovány a standardizovány procesy pro řízení i softwarově inženýrské činnosti, které jsou navzájem integrovány v rámci celé organizace - softwarový proces je standardní a konzistentní • Řízená úroveň (managed) - organizace má stanoveny detailní metriky softwarových procesů i kvality produktu - softwarový proces je predikovatelný • Optimalizovaná úroveň (optimizing) - organizace má vytvořeny podmínky pro kontinuální zlepšování procesů. Nástroje k modelování procesů a funkcí • Notace modelování procesů BPMN • Nástroj pro modelování od Sybase - PowerDesigner • Univerzální OO modelovací jazyk - UML - např. diagram případů užití, diagram aktivit • Modelování fcí pomocí DFD - Data Flow Diagram Funkční X Procesní řízení • Pro funkční řízení jsou primárními organizační útvary a jejich zodpovědnosti (hierarchické řízení - ten kdo řídí, nevykonává => malá pružnost a motivace) • Pro procesní řízení je primárním řízení činností při reakci podniku na významné události (orientace na výsledek, týmová práce, kreativita) Výhody procesního zlepšování: -Zlepšování plánování, -Vyšší předvídatelnost rozpočtu, -Zkrácení vývojového cyklu, -Zlepšení kvality, menší množství chyb, -Zvýšení spokojenosti klienta, -Zvýšení návratonosti investic -Snížení ceny za dosažení požadovaného stupně kvality

Agilní metodiky vývoje SW

Podotázky: Principy a popis agilních metodik. Rozdíly mezi agilními a rigorózními metodikami. Příklady agilních metodik. Agilní metodiky Agilní metodiky začaly vznikat v druhé polovině 90. let jako reakce na nedostatky tradičních rigorózních metodik. Umožňují vytvořit řešení velmi rychle a pružně jej přizpůsobovat měnícím se požadavkům. Tyto „lehké" metodiky vývoje SW vychází z myšlenky, že jedinou cestou, jak otestovat software, je co nejrychleji ho vyvinout (nebo jeho část), předložit zákazníkovi a na základě zpětné vazby jej upravit. Jednotlivé agilní metodiky používají rozdílné techniky, ale jsou založeny na společných principech a hodnotách. V únoru 2001 byl podepsán „Manifest agilního vývoje softwaru" a byla vytvořena „Aliance pro agilní vývoj softwaru". Největší použitelnost se předpokládá u: • výzkumných projektů • time-to-market • menších týmů Principy agilních metodik Výše zmíněný „Manifest agilního vývoje softwaru deklaruje čtyři hodnoty, přičemž tučně vyznačené prvky mají větší relativní význam než prvky vedle nich. „Odhalili jsme lepší způsob vývoje softwaru, sami jej používáme a chceme pomoci i ostatním, aby jej používali. Z tohoto pohledu dáváme přednost: • individualitám a komunikaci před procesy a nástroji • provozuschopnému softwaru před obsažnou dokumentací • reakci na změnu před plněním plánu • spolupráci se zákazníkem před sjednáváním kontraktu. Na základě tohoto manifestu bylo definováno 10 hlavních principů agilních metodik: • včasná a kontinuální dodávka softwaru s hodnotou pro zákazníka • změna požadavků i v průběhu vývoje • každodenní spolupráce uživatelů a vývojářů • podpora motivovaných jedinců • osobní komunikace • fungující software • „zdravý vývoj" • perfektní technické řešení i návrh • jednoduchost řešení, maximalizace množství neudělané práce • samoorganizující se týmy Charakteristika agilních metodik společné principy: • iterativní vývoj s velmi krátkými iteracemi, • zaměření na fungující SW, který má hodnotu pro zákazníka, • lidé jsou prvořadým faktorem - důraz na spolupráci a komunikaci, • tolerantní ke změnám, • automatizované testování. místo procesů praktiky: • Proces - je popisován v manuálech, pohlíží na lidi jako na sekundární, zaměřuje se na explicitní (popsanou) znalost • Praktika - vychází ze zkušenosti, soustředí se primárně na lidi, soustředí se na interní „tacit" znalosti přesun zodpovědnosti za požadavky na zákazníka: • zákazník určuje a mění priority funkcí spolupráce zákazníků a vývojářů (rigorózní metodiky x agilní metodiky): • Rigorózní metodiky o Nevěřím ti, že uděláš práci správně, tak tě musím neustále sledovat a kontrolovat. o standardizují lidi v organizaci o snaží se vykázat lidi do role zaměnitelné součástky • Agilní metodiky o Věřím ti, že uděláš práci dobře, a tak budeme spolupracovat, abychom dosáhli výsledku. o využívají individualit a silných stránek lidí Rozdíl mezi metodikami Rigorózní metodiky: • požadavky, procesy je třeba specifikovat předem a změnám se snažíme zabránit • hodně formalit, dokumentace, direktivní řízení • založeno na nedůvěře - na všechno musí být papíry, všechno podloženo smlouvami atd. • příklady: OPEN, RUP, EUP Agilní metodiky: • individualita, pozitivní přístup ke změnám • důležitější než dokumentace je provozuschopný software • klade důraz na přidanou hodnotu pro zákazníka • spolupráce se zákazníkem - častá komunikace Porovnání rigorózních a agilních metodik hledisko Rigorózní metodiky Agilní metodiky náplň metodiky procesy, zaměřují se na explicitní znalost a pohlíží na lidi jako na sekundární faktor praktiky, zaměřují se na „tacit" znalosti, chápou lidi jako klíčové faktory úspěchu Podrobnost metodiky procesy a činnosti jsou popsány velmi podrobně definována tzv. sotva dostatečná metodika, která se zaměřuje na činnosti, které vytvářejí hodnotu, a eliminuje činnosti, které hodnotu nepřinášejí kvalita zaměření na kvalitu procesů a předpoklad, že kvalitní procesy povedou ke kvalitnímu výsledku zaměření na hodnotu pro zákazníka a vysokou kvalitu produktu předvídatelnost předpokládá předvídatelnost budoucnosti, důraz na anticipaci (sběr požadavků předem, plánování předem) předpokládá nepředvídatelnost budoucnosti, důraz na adaptaci na změny (přírůstkové shromažďování požadavků, plánování pro iteraci) změny změny podléhají řízení změn a je snaha změny minimalizovat snaha změny umožnit a využít je, umožňují zákazníkům přehodnotit své požadavky s ohledem na nové znalosti Definovatelnost procesu vývoje software vývoj software je definovaný proces, je možné jej bez problémů opakovat vývoj software je empirický proces, nemůže být konzistentně opakován, ale vyžaduje konstantní monitorování a adaptaci hodnota pro zákazníka předpoklad, že dobré procesy vedou k dobrým výsledkům, je příliš zaměřen na vlastní procesy, ne na výsledky pro zákazníka. nejvyšší prioritou je uspokojovat zákazníka Participace zákazníka na projektu jen v počátečních a koncových fázích, po podpisu dokumentu specifikace požadavků řízení přebírá tým technologických pracovníků přesun nositele řízení z týmu na zákazníka, zákazník je řídícím subjektem během celého projektu, při každé iteraci zákazník může měnit priority funkcí rozsah řešení vývojáři se snaží do systému zabudovat všechny funkce, které by mohl zákazník v budoucnu potřebovat. pouze požadované funkce, požadavek minimalizace vztah zákazník - vývojář zajištěn smluvně, nedůvěra důvěra a spolupráce lidský faktor sekundární, dokumentačně zaměřené procesy se snaží vykázat lidi do role zaměnitelné součástky primární, využívá individualit a silných stránek lidí kvalifikace lidí stačí standardní jedinci důraz na schopnosti, znalosti a dovednosti lidí specialisté x generalisté požadavek úzké specializace lidí požadavek integrace znalostí a stálé kooperace, sdílení znalostí v týmu, týmové řešení problému, spíše generalisté než specialisté způsob řízení tradiční způsob řízení je formován na základě nedůvěry, direktivní řízení, kontroly vůdcovství a spolupráce, je formováno na důvěře a respektu Význam programování při vývoji SW důraz a hodnota jsou kladeny na architekturu, požadavky a návrh, kódování a testování jsou chápány jako činnosti s nízkou „konstrukční" hodnotou. důraz na programování jako činnost přinášející hodnotu jednoduchost spíše složité řešení, které se snaží obsáhnout i budoucí požadavky důraz na jednoduché řešení žádné zabudovávání budoucích požadavků jednoduchá x složitá pravidla metodiky se snaží popsat vše, s čím se může vývojový tým setkat. obsahují generativní pravidla - minimální množinu věcí, které musíte dělat ve všech situacích. modelování velký důraz na modelování, zejména modelování předem - big design in front of , potom se zmrazí požadavky agilní modelování, při modelování nejde o model jako takový, ale o akt modelování, smyslem modelování je komunikace forma komunikace převážně písemná důraz na komunikaci tváří v tvář dokumentace rozsáhlá dokumentace podstatná není dokumentace, ale pochopení způsob vývoje spíše vodopádový, případně iterativní a přírůstkový s dlouhými iteracemi přírůstkový vývoj s velmi krátkými iteracemi ekonomika zdroje bývají proměnnou veličinou, která zpravidla roste snaha vždy realizovat nejvyšší hodnotu z daných peněz, cílem je hodnota pro zákazníka, ne perfektní systém, hodnota je kombinací funkcí produktu, které odpovídají potřebám zákazníka v určitý čas a za určitou cenu Agilní modelování Agilní modelování je založené na praktikách, principech a hodnotách, které jsou odvozeny z hodnot extrémního programování. Je to „lehká" metodika, která vychází z prověřených modelovacích technik, ale přizpůsobuje je agilním přístupům. Přínosem metodiky Agilní modelování nejsou techniky modelování jako takové, ale to, jakým způsobem jsou aplikovány. Příklady metodik Dynamic Systems Development Method (DSDM) DSDM kombinuje přístup rychlého vývoje aplikací (RAD) s objektově orientovaným vývojem. Klade velký důraz na kvalitu řešení. Metodika je velmi dobře dokumentována a řízeným způsobem rozšiřována. Je to projektová metodika, zaměřená zejména na softwarově-inženýrskou oblast, méně se zabývá oblastí řízení. Je zaměřena pouze na vývoj nového řešení. Základní technikou používanou při analýze a návrhu je prototypování. Přínosem metodiky je řízení jejího rozvoje, propagace, školení a implementace. Metodika DSDM je postavena na 9 principech: • aktivní zapojení uživatele • tým s rozhodovací pravomocí • časté dodávky produktů • klíčovým kritériem pro přijetí dodávky je podpora podnikových cílů • iterativní a inkrementální vývoj jako nástroj postupného přibližování k žádoucímu řešení • změny v průběhu vývoje • definice požadavků na hrubé úrovni • testování v průběhu celého životního cyklu Metodika DSDM rozděluje proces vývoje do třech hlavních fází - Funkční model (Functional Model), Návrh (Design and Build) a Implementace (Implementation), kterým předchází Studie proveditelnosti (Feasibility Study) a Byznys studie (Business Study). Hlavní fáze probíhají iterativně. Obsahem fáze Funkční model je sběr a prototypování funkčních požadavků. Většina požadavků je dokumentována jako prototypy. Ve fázi Návrh jsou prototypy zpodrobňovány, tak aby podporovaly všechny požadavky (i nefunkční) a je navrhováno řešení. Náplní fáze Implementace je realizace navrženého řešení, zhodnocení projektu, školení uživatelů a další činnosti. Adaptive Software Development (ASD) ASD je „lehkou" metodikou, která se zabývá jak oblastí softwarově inženýrskou, tak oblastí řízení. Metodika ASD představuje tzv. „filozofické zázemí" pro agilní metodiky. Nahrazuje statický životní cyklus „Plánování-Návrh-Realizace" (Plan-Design-Build) dynamickým „Spekulace-Spolupráce-Učení" (Speculate-Collaborate-Learn), kde naučení klade největší důraz. Je vhodná pro projekty vyznačující se vysokou rychlostí, změnami, neurčitostí Základem dynamického cyklu je kontinuální učení • Hybnou silou jsou neustále změny • V klasickém cyklu je problematická oblast plánování (odchylky jsou chyby) - spekulace proto dává více prostoru pro změny Lean Development (LD) Metodika je podobně jako Scrum zaměřena zejména na řízení vývoje softwaru a na řízení rizik. Méně se pak zabývá softwarově inženýrskou oblastí. Zaměřuje se spíše na strategickou úroveň s vazbou na podnikouvou strategii. LN je nástrojem přechodu na podnikání tolerantní ke změnám (change tolerant business) a rizikové podnikání (risk entrepreneurship). Znaky: • celulární programování - programátoři jsou rozděleni do týmů, které řeší jednotlivé problémy odděleně • tlačení rozvrhem - důraz na rozvržení prací a dodržení termínů • total quality management - souvislý proces řízení kvality, filosofie stálého zlepšování všech činností • rapid setup - co nejrychlejší příprava k samotné práci • týmový vývoj Feature Driven Development (FDD) Vývoj začíná vytvořením celkového modelu a pokračuje posloupností dvoutýdenních iterací, ve kterých se provádí návrh i realizace pro jednotlivé užitné vlastnosti. Užitná vlastnost (feature) je malý výsledek užitečný pohledu zákazníka. FDD je projektová metodika zaměřená na objektově orientovaný vývoj nového softwaru. Do určité míry podporuje procesy, modelování a používání CASE nástrojů. Výše zmíněná užitná vlastnost neboli feature se skládá z 5 procesů: • vytvoření celkového objektového modelu (Develop an Overall Model) • sestavení seznamu užitných vlastností (Build a Features List) • plánování pro užitnou vlastnost (Plan by Feature) • návrh pro užitnou vlastnost (Design by Feature) • realizace pro užitnou vlastnost (Build by Feature) Crystal metodiky Crystal je soubor metodik pro různé druhy projektů, které se liší důležitostí a velikostí týmu a tím, na co je projekt optimalizován. Všechny metodiky mají společné hodnoty a principy, liší se použitými technikami, rolemi, nástroji a standardy. Jsou zaměřeny na objektově orientovaný vývoj nového řešení. Scrum Metodika Scrum je jazykem vzorů (pattern language) a je zaměřena hlavně na oblast řízení projektu. Název je odvozen ze skrumáže neboli mlýna v ragby, aby byla zdůrazněna adaptibilita, rychlost a schopnost samoorganizace této metodiky. Vývoj probíhá ve Sprintech (30denních iteracích), ve kterých je dodávána vybraná množina užitných vlastností. Sprintů bývá 3-8. Klíčovou praktikou je používání tzv. Scrum Meetings. Jak probíhá Sprint: • všechna práce se dělá uvnitř sprintu, Sprint je 30denní iterace • na začátku sprintu se koná Sprint Planning Meeting: trvá max. 8 hodin, cíl - definovat Sprint Backlog o každý den se koná Scrum Meeting - 15-30 min, probírá se: co se dokončilo nové úkoly omezení a překážky pro plnění úkolů • na konci sprintu se koná Sprint review meeting , trvá 4 hodiny - zhodnocení • Role: o Scrum master: zodpovídá za Scrum proces, jeho správnou implementaci a maximalizaci užitku, vede scrum meetingy, je členem týmu. o Product owner: spravuje seznam požadavků tak, aby maximalizoval hodnotu projektu) o Tým: skupina lidí, kteří se sami řídí tak, aby dodali v každém sprintu fungující SW Extrémní programování (XP) XP je velmi „lehkou" metodikou pro malé až středně velké týmy (2-10 programátorů), které se musí vyrovnat s rychle se měnícím či nejasným zadáním při vývoji softwaru. Zaměřuje se na oblast softwarově-inženýrskou, řízení a organizaci. Jednoduchý návrh redukuje testovací práci. Neustálé testování redukuje čas dodávky. Prokládání kódování a testování dává vývojářům a testerům lepší porozumění kódu. Automatizované testy dovolují vývojářům provádět refaktorizaci. XP používá známé principy a postupy, které dotahuje do extrémů: • párové programování - neustálé revidování kódu, • testování funkcionality • refaktorizace

Metodiky vývoje a provozu IS/ICT

Podotázky: Význam metodik při vývoji a provozu IS/ICT. Jednotlivé metodiky a jejich kategorizace. Metodika - obecně Metodika představuje v obecném smyslu souhrn metod a postupů pro realizaci určitého úkolu KDO?KDY?CO?JAK?PROČ? • Metodiky zabývající se údržbou a vývojem IS bývají označovány jako metodiky vývoje IS/ICT. • Kromě vývoje je rovněž důležité také nasazení hotového řešení, rozšíření řešení a integrace stávajících řešení, jsou tyto metodiky označovány jako metodiky budování IS/ICT. • Metodiky budování IS/ICT = metodiky vývoje IS/ICT + metodiky provozu IS/ICT Vývoj a provoz informačního systému je obtížné oddělit, neboť některé části IS (subsystémy, moduly, komponenty, služby aj.) jsou v daném okamžiku v provozu, některé jsou rozvíjeny, některé jsou vytvářeny nově a všechny musí být dohromady integrovány. Proto metodiky budování IS/ICT pokrývají jak oblast vývoje, tak oblast provozu IS/ICT. Problematikou provozu IS/ICT se však nezabývají v celé šíři, neboť je tato oblast řešena v rámci metodik pro řízení informatiky (například COBIT, ITIL). Termín metodika budování IS/ICT je vymezen následovně: Metodika budování IS/ICT definuje principy, procesy, praktiky, role, techniky, nástroje a produkty používané při vývoji, údržbě a provozu informačního systému, a to jak z hlediska softwarově inženýrského, tak z hlediska řízení. Určuje kdo, kdy, co, jak a proč dělat během vývoje a provozu IS. Metodika napomáhá • k tomu, aby IS byl přínosem pro uživatele (organizaci, zákazníka, ...) • k tomu, aby byly provedeny všechny potřebné činnosti tvorby IS, a to ve správné časové posloupnosti • k tomu, aby IS byl srozumitelně dokumentován • k dobré organizaci práce na projektu • k optimalizaci spotřeby zdrojů při tvorbě a provozu IS. Základní požadavky efektivní využitelnosti metodik: • musí jasně deklarovat soubor hodnot, na kterých je založena, • musí určovat postup řešení, aby bylo možné celý proces vývoje IS/ICT plánovat, • musí se zabývat všemi faktory (dimenzemi), které tvorbu a provoz IS ovlivňují • musí určovat priority řešení (co a kdy je důležité), • měla by doporučovat metody, techniky a nástroje, které je vhodné využít v jednotlivých fázích řešení. Kritérium Kategorie/ vysvětlení Zaměření metodiky • Globální - zaměřují se na budování celopodnikového IS/ICT • Projektové - pouze dílčí oblast (výroba, finance...) - sem patří většina metodik Rozsah metodiky • Fáze životního cyklu IS/ICT - globální strategie, informační strategie, úvodní studie, globální analýza a návrh, detailní analýza a návrh, implementace, zavádění, provoz a údržba • Role - sponzor, vedoucí projektu, koncový uživatel, analytik, návrhář, tester, dokumentátor, expert na doménu • Dimenze - hardware, technologie, data-informace, funkce-procesy, uživatelské rozhraní, pracovní dimenze, organizační/legislativní, ekonomická Váha metodiky • podrobnost - do jaké hloubky se daným tématem zabývá • přesnost - jak je dané téma zpracováno • relevance - zda se zabývá určitým tématem • tolerance - tolerance odchylek • měřítko - míra zaostření (několik položek může být shrnuto do jednoho celku) Typ řešení • vývoj nového řešení • rozvoj a rozšíření stávajícího řešení • integrace řešení • customizace a implementace typového řešení • užití řešení například formou ASP Doména • Předmětná oblast - ERP, CRM, SCM, BI, EAI... Přístup k řešení • Strukturovaný vývoj • Objektově orientovaný vývoj • Rychlý vývoj aplikací - Rapid Application Development (RAD) Rigorózní metodiky V současnosti můžeme sledovat dva hlavní proudy v metodických přístupech, které jsou označovány jako rigorózní metodiky a agilní metodiky (popsány v otázce č. 9). Hlavním kritériem, které tyto dva proudy odlišuje, je „Váha metodiky", ale liší se i dalšími hledisky. V této kapitole jsou charakterizovány rigorózní metodiky, které vycházejí z přesvědčení, že procesy při budování IS/ICT lze popsat, plánovat, řídit a měřit. Snaží se podrobně a přesně definovat procesy, činnosti a vytvářené produkty, a proto bývají často velmi objemné. Rigorózní metodiky jsou zpravidla založeny na sériovém (vodopádovém) vývoji. Existují ale také rigorózní metodiky založené na iterativním a inkrementálním vývoji. Příkladem těchto metodik jsou OPEN, Rational Unified Process (RUP), Enterprise Unified Process (EUP). V rámci rigorózních metodik tvoří samostatnou kategorii metodiky pro hodnocení softwarových procesů (Software Process Assesment). Metodiky hodnocení softwarových procesů jsou založeny na přesvědčení, že kvalita procesu určuje kvalitu produktu, a proto popisují postupy, které umožňují hodnotit úroveň zralosti procesů při vývoji software. Nejznámější z těchto metodik je Model zralosti (Capability Maturity Model for Software). Charakteristika rigorózních metodik • těžké metodiky - podrobné, hodně formalit, direktivní řízení • předpokládají opakovatelnost procesů, možnost definovat všechny požadavky na řešení předem • příklady - OPEN, RUP, EUP, OOSP • metodiky pro hodnocení SW procesů (Software Process Assesment) - Capability Maturity Model (CMM) Metodika OPEN = Object-oriented Process, Environment and Notation OPEN je veřejně přístupná metodika podporující celý životní cyklus vývoje IS/ICT. Je zaměřena zejména na vývoj objektově orientovaných a komponentových aplikací. Metodika OPEN definuje procesní rámec, známý pod názvem OPEN Process Framework (OPF). Jde o procesní metamodel, ze kterého mohou být generovány instance specifické pro organizaci. OPEN je flexibilní, může se přizpůsobit jak doméně, tak konkrétnímu projektu, a zohlednit dovednosti členů týmu, kulturu organizace, požadavky specifické pro každou doménu. OPEN může být použit pro malé projekty, stejně jako pro velké, klíčové projekty. Metodika RUP = Rational Unified Process Metodika Rational Unified Process je založena na tzv. nejlepších praktikách softwarového vývoje: • iterativní vývoj • řízení požadavků • použití komponentové architektury • vizuální modelování (UML, CASE nástroje...) • kontrola kvality software • řízení změn Životní cyklus software je rozdělen na cykly. Předmětem každého cyklu je nová verze produktu. Jeden vývojový cyklus je v RUP rozdělen do 4 po sobě jdoucích fází: • Počáteční fáze (Inception) • Elaborační fáze (Elaboration) • Konstrukční fáze (Construction) • fáze Nasazení (Transition) 1. Počáteční fáze = Definice cílů projektu, požadavků, sestavení harmonogramu projektu (plán iterací), odhad nákladů projektu a definice rizik. 2. Elaborační fáze = Má za cíl definovat architekturu systému. V této fázi by měl být vytvořen prototyp. 3. Konstrukční fáze = Návrh a realizace systému včetně testování. 4. Fáze nasazení = Zajišťuje, aby uživatelé mohli systém používat. Součástí této fáze je školení uživatelů, předání dokumentace, vytvoření help-desk atd. Každá fáze je uzavřena milníkem - časovým okamžikem, ve kterém musí být splněny cíle fáze a dochází k rozhodování. Podstatným nedostatkem metodiky RUP je: zaměřuje pouze na vývoj řešení, ne na jeho provoz a údržbu. Model zralosti SW - Capability Maturity Model for Software (SW-CMM) Nejznámějším příkladem hodnocení softwarových procesů je Model zralosti SW (Capability Maturity Model for Software). Zralost softwarového procesu (Software Process Maturity) je dosažena, pokud je určitý proces explicitně definován, řízen, měřen, kontrolován a je efektivní. Zralost softwarových procesů vede ke zvýšení produktivity a kvality a zvyšuje se výkon procesu. • označovaný zkratkou SW-CMM. • vyvinut v Institutu pro softwarové inženýrství (Software Engineering Institute - SEI) za • účelem hodnocení dodavatelů softwarových řešení pro ministerstvo obrany USA - v r. 1995 • Integrační model zralosti (Capability Maturity Model Integration, CMMI) od r. 2000 (1) Počáteční úroveň (initial) • softwarové procesy jsou náhodné a chaotické • organizace nemají stabilní prostředí pro vývoj a údržbu software, reagují pouze na vzniklé problémy. (2) Opakovatelná úroveň (repeatable) • organizace mají definovány a zavedeny postupy řízení projektu. • softwarový proces je disciplinovaný (3) Definovaná úroveň (defined) • organizace má definovány, dokumentovány a standardizovány procesy pro řízení i softwarově inženýrské činnosti, které jsou navzájem integrovány v rámci celé organizace • softwarový proces je standardní a konzistentní (4) Řízená úroveň (managed) • organizace má stanoveny detailní metriky softwarových procesů i kvality produktu • softwarový proces je predikovatelný (5) Optimalizovaná úroveň (optimizing) • organizace má vytvořeny podmínky pro kontinuální zlepšování procesů. Agilní metodiky • Důraz na častou komunikaci se zákazníkem, čímž je možné přesunout zodpovědnost za požadavky na zákazníka - zákazník určuje a mění priority funkcí • Důraz na přidanou hodnotu pro zákazníka • Založeno na důvěře a individualitě • Pozitivní přístup ke změnám Více o agilních metodikách viz otázka č.9 Metodiky provozu IS/ICT ITIL (Knihovna infrastruktury IT) Soubor best practices pro řízení IT služeb - mezinárodně akceptovaný standard pro řízení IT služeb. Jsou to postupy popisující, co se má udělat. Jakým způsobem to podnik udělá, to už je na něm. Vedle těchto návodů poskytuje širokou škálu dalších produktů v oblasti školení, profesionální kvalifikace, konzultací, softwarových prostředků či výměny zkušeností. COBIT COBIT je komplexní systém cílů a metrik podnikové informatiky. Tato metodika je oproti ITIL mnohem strukturovanější. Je to všeobecně přijímaný rámec pro zavádění a provoz IT Governance nad IT ve firmě. Významně pomáhá strategii firmy. Dále zavádí postupy měření a vyhodnocuje výkon IT. PIS je v tomto ohledu rozdělena do funkčních domén (plánování, implementace, provoz, monitoring), které obsahují konkrétní procesy. Ty jsou poměřovány 7 kritérii (efektivnost, výkonnost, důvěra, integrita, dostupnost, soulad, spolehlivost). Výsledná zjištění pak přisuzuje 5 zdrojům (personál, aplikace, technologie, vybavenost, data). Obsahuje také systém měkkých metrik, díky kterým je možné měřit úroveň zralosti IS - maturity model.

Správa konfigurací, integrace (sestavení) a distribuce aplikací

Software Configuration Management • SCM - Software Configuration Management = řízení vývoje softwarových systémů. • Jde především o sledování a řízení změn v SW. • Standardy v oblasti SCM: ITIL, IEEE, ISO 9001... Základní aspekty SCM: o identifikace a dokumentace funkčních a fyzických charakteristik jednotlivých prvků systému, o řízení změn prvků a jejich charakteristik, o řízení verzí, o zaznamenávání a zpracování požadavků na změnu systému a stavu implementace o ověřování kompletnosti a validity systému, o řízení dlouhodobé konzistentnosti systému Konfigurace SW konfigurace = souhrn prvků konfigurace reprezentující určitou podobu daného SW systému Cíle konfiguračního řízení o Určení a správa konfigurací: o určení (identifikace) prvků systému, přiřazení odpovědnosti, o identifikace jednotlivých verzí prvků, o kontrolované uvolňování (release) produktu, o řízení změn produktu během jeho vývoje, o Správa sestavení a koordinace prací o určování postupů a nástrojů pro tvorbu spustitelné verze o ověřování úplnosti, konzistence a správnosti produktu o koordinace spolupráce vývojářů o Zjišťování stavu systému o udržení informovanosti o změnách a stavu prvků, o zaznamenávání stavu prvků konfigurace a požadavků na změny o poskytování informací o stavech o statistiky a analýzy SCM - komponenty o správa verzí (version control), o řízení sestavení (system building), o distribuce aplikace (release management), o správa rozhraní (interface control) o řízení subdodavatelů (subcontractor control) Integrace/ Sestavení Činnosti spojené se sestavením modulu či celé aplikace. Cílem je vytvořit systematický a automatizovaný postup. Build (sestavení) - postup při vytvoření aplikace, často se používá i pro označení výsledku, jednoznačný identifikátor, opakovatelný, konzistentní, úplný Postupné fázové sestavení: 1. Návrh, kód, testování a ladění jednotlivých tříd - vývoj jednotek (unit development), 2. Spojování tříd do velkého systému (systémová integrace, „velký třesk"), 3. Testování a ladění celého systému (systémová dezintegrace") Přírůstkové sestavení: 1. Vytvořte malou funkční část systému. Tu důkladně otestujte. Vytvoříte kostru. 2. Navrhněte, naprogramujte, otestujte a odlaďte další třídu. 3. Integrujte novou třídu s již hotovou kostrou. o výhody: rychlejší odhalení chyb, lze dodávat zákazníkovi po částech, lepší sledování postupu Nástroje pro podporu sestavení: 1. správa sestavení o luntbuild, CruiseControl, AntHill, Hudson, 2. vytváření skriptů o make, ant, maven, 3. testování o jednotkové testování - xUnit, o systémové testy, o funkční (akceptační) testy, - např. Selenium, 4. kontrola kódu o metriky - CCN o detekce chybných konstrukcí - PMD, FindBugs o pokrytí kódu testy - EMMA, Cobertura, 5. integrace databáze o database sandbox, SQLUnit, 6. zpětná vazba o správné informace, správným lidem, ve správný čas, správným způsobem - mail, SMS, zvukové, speciální aplikace na liště, Distribuce aplikací = SD =všechny aktivity spojené s uvedením programu (softwarového systému) do používání Problémy při distribuci aplikací: • změny nainstalovaných a běžících aplikací, • závislosti mezi komponentami a aplikacemi, • koordinace při distribuci ve velkých sítích (klient server aplikace), • správa heterogenních platforem, • bezpečnost: soukromí, autorizace, kontrola integrity, Činnosti SD • uvolnění (release) - činnosti spojené se zabalením aplikace a přípravou k distribuci zákazníkům. Navazuje na vývoj aplikace. Je potřeba též shromáždit všechny informace potřebné pro navazující kroky. Má obvykle dvě části: o balení aplikace, o informování zákazníků o vlastnostech a požadavcích aplikace, • instalace (install) - počáteční nahrání aplikace k zákazníkovi. Obvykle je to nejnáročnější část distribuce aplikace. Má dvě části: o distribuce aplikace na počítač, o konfigurace aplikace, • aktivace (activate) - činnosti ke spuštění aplikace. Může to být jednoduchý příkaz či složitý proces spouštění jednotlivých procesů. • deaktivace (deactivate) - opak aktivace, ukončení/zastavení běžících částí aplikace. Provádí se před aktualizací, odinstalováním či částí údržby (zálohování). • aktualizace (update) - instalace nové verze aplikace - speciální případ instalace. Obvyklý postup: deaktivace - aktualizace - aktivace. • přizpůsobování (adapt) - úprava již instalované aplikace na místní podmínky či změny místních podmínek. • odinstalování (deinstall) - aplikace bude odinstalována z počítače. Vhodná podpora systému pro distribuci sw. Je třeba správně vyřešit závislosti (co nechat a co zrušit). • vyřazení (derelease, retire) - aplikace již dále nebude vyvíjena/distribuována/podporována. Je potřeba informovat zákazníky.

Empirický výzkum

V empirickém výzkumu se na základě sběru a analýzy dat směřuje k formulaci zákonitostí empirického charakteru. Východiskem každého empirického výzkumu je získání určitého množství dat z cílového výzkumného pole, které má 3 základní oblasti lišící se mírou bezprostřednosti přístupu k faktům: Přímé - výzkumník je přítomen v situaci (např. akční výzkum, zúčastněné pozorování) Mediální - výzkumník získává komplexní výběrový obraz reality, výběr ale neovlivňuje (např. videozáznam) Subjektivně zprostředkované - výzkumník získává údaje prostřednictvím výpovědi o zkušenosti jiné osoby (např. dotazník) Empirický výzkum vždy znamená systematické zkoumání. Má nás přiblížit k objevení hledané podstaty, k nalezení kvalitativních stránek zkoumaného jevu apod. Musí však být založen na přesném metodickém a metodologickém postupu a na objektivním teoretickém podkladu. Před začátkem výzkumu si musíme odpovědět na tyto otázky: Co - přesně zformulovat předmět či téma výzkumu, jímž je z velké části i cíl. co nejvíce specifikovat. Zároveň se formuluje vědecká hypotéza výzkumu. Kdy - souvisí s časem a s časem se mění. Nutné stanovit časový úsek, ve kterém bude výzkum proveden. Kde - nutné stanovit kde bude výzkum proveden a jak velkého celku se budou týkat jeho závěry Proč - účel výzkumu (může pomáhat teorii daného oboru, aplikace ve vědním oboru, pomáhat praxi..) Účel nemusí být totožný s předmětem výzkumu.) Jak - jde o metodickou a technickou stránku výzkumu. Metodika - formálně zdokumentovaný souhrn standardů, postupů, modelů, nástroje, doporučení a jednotlivých pracovních kroků, které jsou k dispozici před zahájením projektu. Na počátku každého výzkumu stojí také informace, které je nutné porozumět. Do výzkumu si autor přináší znalosti pocházející z odborné literatury. Odborné texty jsou pro vědecký výzkum základní pramen neboli zdroj, ve kterém jsou obsažena data a informace. Základní typy empirického výzkumu podle přístupu či paradigmatu: Výzkum kvalitativní Výzkum, jehož výsledků se nedosahuje pomocí statistických procedur nebo jiných způsobů kvantifikace. Cíle je vytvoření nových hypotéz, nového porozumění, nové teorie. Logika Kval. Výzkumu je tedy induktivní. Na začátku může být pozorování a sběr dat, potom pátráme po pravidelnosti existujících v těchto datech, významu těchto dat, formulujeme předběžné závěry a výstupem mohou být formulované hypotézy. Nízká standardizace tohoto typu výzkumu způsobuje poměrně nízkou reliabilitu. Což ale spolu s volnou formou otázek a odpovědí vede k možné vysoké validitě (platnost získaných výsledků vzhledem ke skutečnosti). Výzkum kvantitativní Kvantitativní výzkum spočívá především v analýze dat. Zkoumaná data mohou být kvantitativní i kvalitativní. Někdy je obtížné získat kvantitativní údaj přesně, a proto dotazovaní respondenti vybírají z nabízených intervalů. Tyto intervaly se obvykle označují pořadovými čísly a proměnná která je obsahuje se nazývá pořadová neboli ordinální. Ty nemůže sčítat nelze počítat průměr apod., ale můžeme na něj použít kvantitativní metody: lze zjišťovat četnost, závislost apod. Logika výzkumu je deduktivní. Na začátku existuje problém buď v teorii nebo v realitě, následně je problém přeložen do hypotéz. Ty jsou pak základem pro výběr proměnných, výstupem je soubor přijatých a zamítnutých hypotéz. Silná standardizace tohoto typu výzkumu zajišťuje vysokou reliabilitu. Standardizace a kategorizace otázek a odpovědí vede k nízké validitě. Setkáváme se ještě s dělením na: Experimentální výzkum - typ kvantitativního výzkumu, v němž výzkumník se něčím manipuluje a pak zjišťuje, jaké to mělo dopady. Neexperimentální výzkum - výzkum, který nezahrnuje zmíněnou manipulaci. Může být kvantitativní i kvalitativní typem výzkumu Základní metody empirického výzkumu: Metody statistické Vychází z vědecké zkušenosti, že vše, co existuje, existuje v nějakém množství. Obecně každá skutečnost obsahuje v sobě nejen možnosti, ale i míru těchto možnosti, svoji pravděpodobnost. 3 etapy: získání statistických údajů, zpracování stat. Údajů, statistický rozbor Metody historické -zachycuje procesy vývoje, vnitřní zákonitosti jeho změn v minulosti i současnosti. Poznává historii zkoumaného jevu. Každá historie jevu obsahuje 2 stránky: obsah, který minulost vepsala danému jevu a současnou proměnlivost, která se rozvijí. Metody Experimentální Míří vždy k odhalení podstaty jevů, předpokladem je znalost podmínek, které mohou na jev působit. Při experimentu zjišťuje, zda změna jedné či více podmínek působí změny v ostatních podmínkách. Metody srovnávací Často bývá základem empirického výzkumu. Vědecké myšlení de facto nepřipouští zkoumat jevy či fakta izolovaně, nutné je zkoumat ve vztazích, zkoumat vývojové tendence. Metody monografické Výzkum se uskutečňuje na jednom nebo jen na několika případech. - poskytuje především podněty pro teoretické úvahy. Hypotézy platné pouze pro stejné případy. Jiné dělení: Empirické metody Pozorování Měření Experimentování Logické metody Abstrakce (zaměření se na hlavní rysy) - konkretizace (charakteristiky jednotlivých tříd, částí) Analýza (rozdělení celku na části) - syntéza (od částí k celku) Indukce (od zvláštních případů k obecnostem) - dedukce (od obecných závěru k zvláštním případům) Dále ještě můžeme rozdělit metody na: Experimentální - používají je v technických a přírodních vědách Neexperimentální - používají je ve společenských a humanitních vědách Výzkumné techniky: Pozorování Dotazník Rozhovor Anketa Testy Analýza dokumentů

Webové služby a architektura orientovaná na služby

Web Service (webová služba) Jedná se o technologii, která umožňuje integrovat libovolné aplikace provozované na různých platformách a ovládat je prostřednictvím webového rozhraní, tj. z běžného internetového prohlížeče. • Základní stavební blok distribuovaných aplikací v prostředí internetu • Platforma pro integraci aplikací • Aplikace využívají webové služby z různých zdrojů bez ohledu na to, kde jsou umístěny nebo jak byly implementovány • Programová aplikační logika přístupná pomocí standardních web protokolů Proč název webové služby? • Termín „služba" (service) - funkcionalita sdílené aplikace je označována za službu jiným aplikacím (místo klient a server se proto používá žadatel o službu a poskytovatel služby) • Označení „webová" - komunikace mezi žadatelem a poskytovatelem využívá osvědčených protokolů sítě internet Charakteristika • Užívají XML - pro popis svého rozhraní, formulaci požadavků i odpovědí i mechanismus vzájemné komunikace (nejsou vázány na proprietární licencované technologie) • Umožňují synchronní a asynchronní komunikaci • znovupoužitelné softwarové komponenty - webové služby pokračují v objektově orientovaném návrhu SW • volně spojené - detaily implementace WS a technologické platformy, které užívá, nejsou pro službu volající program důležité • sémanticky zapouzdřují oddělenou funkcionalitu • programově přístupné - na rozdíl od webových stránek, nejsou WS určeny přímo pro člověka, ale jsou určeny jiným programům • přístupné přes standardní internetové protokoly - HTTP, ale i SMTP, FTP apod. Definice webové služby • Webové služby XML poskytují webovým uživatelům užitečné funkce prostřednictvím standardního webového protokolu (většinou protokol HTTP, formát komunikace - SOAP) • Webové služby XML poskytují způsob, jak dostatečně podrobně popsat své rozhraní - obvykle ve formě dokumentu XML -Web Services Description Language (WSDL). • Webové služby XML jsou registrované, takže potenciální uživatelé je mohou snadno nalézt. To zajišťuje specifikace Universal Discovery Description and Integration (UDDI). Hlavní výhody WS • programy mohou být napsány v různých jazycích a na různých platformách a navzájem spolu komunikují standardním způsobem. o to už slibovaly komponentové architektury o rozdíl je v tom, že SOAP je podstatně jednodušší než dřívější přístupy, takže se snáze implementuje • pracují se standardními webovými protokoly—XML, HTTP a TCP/IP o firmy již mají vybudovanou webovou infrastrukturu a lidi se znalostmi, a tak jsou náklady na zavedení WS nižší než u předcházejících technologií K čemu WS slouží • první WS jen jako informační zdroj, který lze snadno začlenit do aplikace —ceny akcií, předpověď počasí, sportovní výsledky o tyto informace na webu jsou, ale WS k nim zajistí snadnější a spolehlivější programový přístup o Pokud to je WS jen pro zjišťování takovýchto dat, tak nemusí ani být přes SAOP • nyní kompozitní aplikace o např. elektronický obchod, který poskytne informace o cenách od různých prodejců. Uživatel si může vybrat prodejce, předat objednávku, aplikace může použít WS ke kontrole úvěru zákazníka, provádět příjem peněz z účtu zákazníka a zajistit dodávku zboží přes dodávkovou službu. SOAP SOAP je protokol pro posílání zpráv XML a je základem webových služeb. Ostatní standardy jako WSDL a UDDI vznikly až později po uvedení SOAPu a jen dále rozšiřují jeho možnosti a snadnost použití. SOAP umožňuje zaslání XML zprávy mezi dvěma aplikacemi a pracuje tedy na principu peer-to-peer. Zpráva je jednosměrný přenos informace od odesílatele k příjemci, ale díky kombinování několika zpráv můžeme pomocí SOAPu snadno implementovat běžné komunikační scénáře. Nejčastěji se SOAP používá jako náhrada vzdáleného volání procedur (RPC), tedy v modelu požadavek/odpověď. Jedna aplikace pošle v XML zprávě požadavek druhé aplikaci, tak požadavek obslouží a výsledek zašle jako druhou zprávu zpět původnímu iniciátorovi komunikace. V tomto případě bývá webová služba vyvolána webovým serverem, který čeká na požadavky klientů a v okamžiku, kdy přes HTTP přijde soapová zpráva, spustí webovou službu a předá jí požadavek. Výsledek služby je pak předán zpět klientovi jako odpověď. WSDL Jazyk WSDL slouží k popisu síťových služeb jako množiny koncových bodů zpracovávajících zprávy. V praxi WSDL popisy nejčastěji popisují služby, které si posílají zprávy pomocí formátu SOAP a protokolu HTTP. • Jak se služba nazývá, na jaké adrese je dostupná, jaké operace poskytuje • Jaký mechanismus komunikace předpokládají UDDI Nabízí mechanismy pro registrování, kategorizování a vyhledávání webových služeb. UDDI funguje jako velký adresář, který obsahuje informace o subjektech (firmách) a jimi poskytovaných službách. Samotný registr pracuje rovněž jako webová služba a komunikace s ní tedy opět probíhá pomocí SOAPu. Webová služba představuje aktuální technologii implementace služeb nebo e-služeb, která je však koncovému uživateli skryta. V souvislosti s distribuovaným zpracováním a distribuovaným systémem se využívá klient/server architektura. V souvislosti so SW a softwarovým inženýrstvím se využívá softwarová architektura. Architektura orientovaná na služby SOA lze chápat jako praktiky a rámce, které umožňují, aby funkcionalita aplikací byla poskytovaná a spotřebovaná jako množina služeb, a to v takové úrovni funkcionality, kterou potřebuje příjemce služby. Ten je oddělen od implementace služby a používá pouze jednoduché na standardech založené rozhraní. Cílem je nabídnout funkcionalitu IS stejným způsobem, jako to dělá byznys vůči svým zákazníkům, tedy formou služby, včetně poskytnutí vhodného přístupu, kterým lze při užití již existujících služeb vytvářet služby nové. Je postavena na 3 hlavních principech: 1. Byznys procesy řídí služby a služby řídí technologie = služby tvoří abstraktní vrstvu, která umožňuje vytvářet vztah mezi podnikovými procesy a aplikacemi technologií. 2. Byznys agilita = schopnost rychle odpovídat na změny požadavků byznysu. 3. SOA se neustále mění a je plně zvládnutelná (SOA governance) Architektura je založená na předávání zpráv mezi autonomními službami - Loosecoupling • Služby jsou přístupné přes standardizovaná a publikovaná rozhraní a lze je snadno lokalizovat • je to koncept architektury, její realizací mohou být XML webové služby • představuje další úroveň znovupoužití kódu • aplikace využívají služeb, při nahrazení služby není třeba aplikaci modifikovat • nabízí jasný a čistý model pro integraci systémů • uvnitř organizace • mezi organizacemi • poskytuje základ pro globální propojování systémů

Podnikatelská etika

Za základní definici můžeme pokládat: „Podnikatelská etika je profesní aplikovaná normativní etika." „Podnikatelská etika = normativní etika" • Normativní etika stanovuje normy, jak by se člověk měl chovat a jak by měl žít. • Etiku většinou chápeme jako nauku o lidských záměrech, jednáních a vztazích z hlediska jejich dobrých nebo zlých důsledků pro člověka jako jedinečnou osobnost, pro společnost jako celek i pro veškerou skutečnost, s níž je člověk v kontaktu. • Etika podnikání je častým předmětem diskusí ekonomů, filozofů, manažerů, podnikatelů a dokonce i politiků. Ekonomické jednání je součástí společnosti od jejich pilířů • Základním předpokladem etického podnikání by měla být tzv. fair play. • Podnikatelská etika se stala velmi aktuálním tématem koncem 90. let nejen v postsocialistických zemích ale celosvětově. Nejen na našem území se v této době vytváří podmínky pro korupční jednání. • -> Bez respektování základních etických principů nelze vytvářet zdravý a dynamický rozvoj • Podnikatelská etika řeší konflikt mezi vlastním sebezájmem a zájmy ostatních lidí, konflikt odedávna spojovaný s obchodní činností. Je to však nova disciplína, která hledá teoretické koncepty a modely chování firem. • Je to snaha o aplikaci etických zásad do podnikání, s cílem zlepšit podnikatelskou praxi ve veškerých podnikatelských aktivitách • Zabývá se rozhodováním morální povahy • Odmítá překrucování skutečnosti • Není v rozporu s ekonomií a nelze ji redukovat na respektování práva Podnikatelská etika zohledňuje 4 úrovně: o individuální etika - týká se jednotlivce o Podniková etika - etické normy na úrovni institucí a organizací o Etika hospodářství - týká se společnosti jako ceku o Etika nadnárodních společností - souvisí s globalizací mezinárodního podnikání Oblastni podnikatelské etiky jsou: Individuální, osobní etika, Práva zaměstnanců, Ochrana spotřebitelů, Diskriminace, Kodexy chování, Využívání energie, Využívání utajených informací pro obchodní jednání, Výhody poskytované organizací, Globalizace podnikání, Odpovědnost organizace, Odpovědnost zaměstnanců, Vztahy s odbory, Reakce zaměstnanců na neetické jednání, Počítačová data o ochrana osobních údajů, Ochrana prostředí, Ochrana zvířat a výzkum, Průmyslová špionáž, Korupce, Odměny pro manažery (zejména na vrcholové úrovni), Hladomor a země třetího světa Historie vývoje názorů na podnikatelskou etiku • Za základní dílo je považovaná proslulá stať Maxe Webera „Duch kapitalismu a protestantská etika". • Významnost osobnosti podnikatele v ekonomickém rozvoji rozpracoval Joseph Schumpeter, který analyzoval hodnoty, které motivují podnikatele, jako hlavní motor ekonomického růstu. • Studium souvislostí mezi ekonomickým a etickým chováním se dostalo do popředí zájmů ekonomů a filosofů v 80s Současné pojetí podnikatelské etiky Ekonomické chování nelze chápat jako mravně neutrální a vyhýbat se hodnocení postojů a rozhodnutí, která byla na úrovni firmy učiněna. Lze rozeznávat dva zásadní přístupy k ekonomickým aktivitám: • Etický - bere v úvahu etické souvislosti. • Inženýrský (technický) - se zrodil až s rozvojem průmyslové éry. V současných neliberálních ekonomikách převládá pojetí maximalizace vlastního zájmu, které souvisejí s nedoceněním role etiky v reálném rozhodování. Současná doba nutí firmy přijímat normy své doby. Důvody etického chování firmy Mravnost je obecným zájmem celé společnosti. Morální společnost je méně nákladná, snižuje společenské výdaje na donucovací aparát. Každý podnikatelský subjekt očekává etické chování ostatních účastníků ekonomických aktivit: Toto očekávání je výchozím principem jakékoli legální podnikatelské. Je společensky mravně neúnosné se proklamativně přihlásit k dodržování etických pravidel a skrytě je porušovat. Jakékoli porušování morálních pravidel podnikatelskými subjekty destruuje prostředí nezbytné pro podnikání. Je-li zásada „fair play" nedodržována stále větším počtem ekonomických subjektů, ztrácí podnikatelské prostředí pravidla a tím i svoji kvalitu. Manažerská etika • Za manažerskou etiku považujeme takové úsilí, které promítá zásady etiky do všech fází rozhodování a řídící práce. • Etická technologie managementu zdokonaluje algoritmy a postupy ve všech jeho sférách. • Pojem „manažerská etika" není zaváděn jenom pro oblast podnikání a veřejné správy. Má smysl ve všech oblastech, kde se uplatňuje management. • ovlivňujících vývoj a chování objektu řízení • Manažer svou činností a svými postoji usměrňuje chování svých podřízených a na základě stimulování jejich motivovanosti a ztotožnění se s vymezenými cíli pak celou strukturu řízeného objektu. Manažer má jenom dvě možnosti, buď manažerskou etiku přijmout za svou pracovní metodu, tedy jít cestou obtížnější, ale jistější - vypořádat se s projektem strategického rozvoje specifických podmínek řízeného objektu a etiky jeho efektivnosti. Tou druhou možností je hledat jiné cesty, které by mohly být sice jednodušší a rychlejší, ale určitě mnohem riskantnější a nejistější. Manažerská etika vychází ze tří pilířů (subsystémů). Které reprezentují tři na sobě závislé a vzájemně se doplňující oblasti: morálka, erudice a schopnost aplikace v praxi. Nedodržovat morálku je svůdné, protože to zdánlivě usnadňuje a urychluje naplňování našich cílů a ambicí. je nutné vnitřní postoje upevňovat, zdokonalovat, abychom si vytvořili vnitřní systém mantinelů, které nebudeme chtít nikdy překročit. Etika začala být v devadesátých letech 20. století pociťována jako potřebná k ovlivnění managementu a tím zmírnění tvrdé a často nelegální představy o podnikání, spojené s nezákonným chováním některých „podnikatelů" a i nežádoucími dopady na společnost a na „daňové poplatníky". Stala se módním slovem. Důvody úspěšnosti firem: • Podniková kultura • Styl vedení • Organizační struktura • Nepřetržitá transformace a změna • Budování globální organizace Etika ve veřejné správě • Nezištnost • Integrita • Objektivnost • Odpovědnost • Otevřenost • Čestnost • Vedení

Databázové jazyky

Základní pojmy • data: formalizované a fyzicky zaznamenané znalosti, poznatky, zkušenosti, výsledky pozorování • informace: smysluplná interpretace dat • databáze: integrovaná počítačově zpracovaná množina persistentních dat • relační model dat: založený na predikátové logice prvního řádu, k manipulaci s daty možno použít relační kalkul nebo operace relační algebry • dotazovací jazyk: slouží pro získání dat z databáze; v relační databázi je odpovědí relace, jejíž n-tice splňují nadefinované podmínky • systém řízení bází dat (SŘBD): množina programovým prostředků, která umožňuje: o vytvoření databáze o použití databáze (manipulace s daty - výběr, vkládání, update, mazání) o údržbu a správu databáze • databázový systém (DBS): SŘBD + databáze Význam a užití • Prostředek komunikace člověka s databázovým systémem • Pravidlo komplexního datového jazyka: Relační systémy mohou podporovat více jazyků a režimů přístupů, ale musí existovat minimálně jeden jazyk, jehož příkazy jsou vyjádřitelné dobře definovanou syntaxí jako řetězce znaků, který podporuje definici dat, manipulaci s daty, ochranu dat a omezení integrity (lze považovat za standard) Základní dělení jazyků podle nejčastěji identifikovaných částí • DDL (Data Definition Language): definice databázových objektů; příkazy create, alter, drop • DML (Data Manipulation Language): manipulace s daty; příkazy select, insert, update, delete • DCL (Data Control Language): řízení přístupu k datům; příkazy grant, revoke • TCL (Transaction Control Language): řízení transakcí; příkazy commit, rollback, savepoint Příklady využití • Databáze jako samostatný prvek - využití pro evidenci a správu dat • Databáze jako podpora aplikace - uložení dat do databázové struktury, ze které aplikace čerpá Příklady dotazovacích databázových jazyků 4. generace Databázové jazyky 4. generace (4GL: 4th Generation Language; pokročilé programovací jazyky, které dovolí laikům (neprogramátorům) psát krátké programy extrahující data z databází a vytvářet reporty). • FOCUS • Informix-4GL • Quel • Progress 4GL • SQL (v současné době nejrozšířenější) Databázový jazyk SQL Standardizovaný dotazovací jazyk používaný pro práci s daty v relačních databázích. SQL je zkratka anglických slov Structured Query Language (strukturovaný dotazovací jazyk). V 70. letech 20. století probíhal ve firmě IBM výzkum relačních databází. Bylo nutné vytvořit sadu příkazů pro ovládání těchto databází. Vznikl tak jazyk SEQUEL (Structured English Query Language). Cílem bylo vytvořit jazyk, ve kterém by se příkazy tvořily syntakticky co nejblíže přirozenému jazyku (angličtině). Relační databáze byly stále významnější, a bylo nutné jejich jazyk standardizovat. Americký institut ANSI původně chtěl vydat jako standard zcela nový jazyk RDL. SQL se však prosadil jako de facto standard a ANSI založil nový standard na tomto jazyku. Tento standard bývá označován jako SQL-86 podle roku, kdy byl přijat. Standardy podporuje prakticky každá relační databáze, ale obvykle nejsou implementovány vždy všechny požadavky normy. A naopak, každá z nich obsahuje prvky a konstrukce, které nejsou ve standardech obsaženy. Přenositelnost SQL dotazů mezi jednotlivými databázemi je proto omezená. Postupně standardizován organizacemi: • ISO: Mezinárodní organizace pro normalizaci (International Organization for Standardization) • IEC: Mezinárodní elektrotechnická komise (International Electrotechnical Commision) • ANSI: Americká standardizační organizace (American National Standards Institute) Vývoj standardů: Rok Označení Charakteristika 1986 SQL-86 První verze (ANSI / ISO 1987) 1989 SQL-89 Oprava a mírné rozšíření normy jazyka SQL-86 1992 SQL-92 Označení SQL2, komplexní pohled na jazyk, tři úrovně 1999 SQL:1999 Nepřesně označováno jako SQL3. Výrazné rozšíření jazyka, regulární výrazy, rekurzivní dotazy, triggery, objektově orientované vlastnosti 2003 SQL:2003 Podpora XML, GUI funkce, multimédia 2006 SQL:2006 Import, export a způsob použití XML dat, vazba na XML Query Language (W3C) 2008 SQL:2008 Kompletní přepracování všech hlavních částí jazyka SQL Minimální požadavky dle platných standardů databázového jazyka SQL: ISO/IEC 9075-1:2008 Information technology - Database languages - SQL - Part 1: Framework (SQL/Framework) ISO/IEC 9075-2:2008 Information technology - Database languages - SQL - Part 2: Foundation (SQL/Foundation) ISO/IEC 9075-11:2008 Information technology - Database languages - SQL - Part 11: Information and Definition Schemas (SQL/Schemata) I přes přesný popis standardů přežívá (z důvodu zpětné kompatibility) řada odchylek - dialektů - implementací jazyka SQL výrobci jednotlivých databázových systémů. Příklady použití SQL Vytvoření tabulky CREATE TABLE název tabulky (atribut, typ, PK, NOT NULL...); CREATE TABLE zamestnanci (ID_zam int primary key, jmeno_zam varchar (20) NOT NULL...); Smazání tabulky DROP TABLE název tabulky DROP TABLE zamestnanci Vložení dat INSERT INTO název tabulky (název atributu) VALUES (hodnota atributu); INSERT INTO zamestnanci (ID_zam, jmeno_zam) VALUES (1, 'Novák'); Výběr dat SELECT * FROM název tabulky; SELECT * FROM zamestnanci; Aktualizace dat UPDATE název tabulky SET název atributu = nová hodnota WHERE podmínka; UPDATE zamestanci SET jmeno_zam = Nováková WHERE ID_zam = 1; Mazání dat DELETE FROM název tabulky WHERE podmínka; DELETE FROM zamestnanci WHERE jmeno_zam='Novák'; PL/SQL Procedural Language / Structured Query Language je procedurální nadstavba jazyka SQL od firmy Oracle založená na programovacím jazyku Ada. Pomocí PL/SQL je možno vytvářet: • Uložené procedury a funkce • Programové balíky • Triggery • Uživatelsky definované datové typy Tato nadstavba se rozšířila a její deriváty převzaly i jiné relační databáze. OQL Object Query Language (OQL) je standardizovaný dotazovací jazyk pro objektově-orientované databáze vytvořený podle SQL. OQL byl vyvinut Object Data Management Group (ODMG). Kvůli jeho komplexitě zatím žádný výrobce neimplementoval OQL v úplnosti. OQL ovlivnil návrh některých novějších dotazovacích jazyků jako JDOQL a EJB QL. Jazyk OQL je záměrně navržen tak, aby byl velmi podobný jazyku SQL-92. Dokonce platí, že část syntaxe SQL, která se týká manipulace s daty, je kompletně obsažena v OQL. Proto je například řada dotazů konstrukce select-from-where zcela shodná v SQL i OQL. Na druhou stranu se jazyk OQL nezabývá tvorbou datových struktur. To znamená, že příkazy SQL týkající se definice dat (např. create-table, create-index atd.) nemají v OQL žádný ekvivalent. K definici tříd, kolekcí a metod jazyk OQL nejde použít. Počítá se zde buď s nějakým běžným objektovým programovacím jazykem jako např. Java, C#, C++, Smalltalk Databázovým dotazem je nejen konstrukce select-from-where, ale každý výraz, který reprezentuje nějaká data. Proto například prostý výraz v OQL zaměstanci se v SQL musí napsat jako select * from zaměstnanci JPQL Java Persistence Query Language je platformě nezávislý objektově-orientovaný dotazovací jazyk definovaný jako součást specifikace Java Persistence API (JPA). JPQL se používá k dotazování se na entity uložené v relační databázi. Je silně inspirován SQL a má podobnou syntaxi. JPQL odstiňuje programátora od specifik konkrétního datového úložiště. Jinými slovy, programátor se nestará o to, zda jsou v konečném důsledku dotazy prováděny nad Oracle nebo MySQL databází. Stále píše stejné dotazy. Tato vlastnost je velice pohodlná, může však mít i jistá omezení. Každý výrobce databází přináší do svého produktu jinou funkcionalitu, kterou se odlišuje od ostatních. Používáním standardních „univerzálních" dotazů pomocí JQPL o tyto výhody přichází. Někdy se v této souvislosti hovoří o zákonu netěsných abstrakcí. Ten ve zkratce říká, že jakákoli abstrakce vede k zúžení funkcionality nebo k neefektivnímu využívání zdrojů. Jako příklad se často uvádí tato abstrakce SQL: • WHERE a=b AND b=c • WHERE a=b AND b=c AND a=c Matematicky jsou tyto zápisy totožné. Může však u některých databází docházet v případě použití druhého zápisu k výraznému zlepšení výkonnosti zpracování. XQuery XQuery je dotazovací a funkcionální programovací jazyk navržený pro dotazování na kolekce dat v XML. XQuery poskytuje prostředky pro extrahování a manipulaci dat z XML dokumentů nebo jakéhokoli datového zdroje, který může být jako XML zobrazen, například relační databáze nebo některé dokumenty (např. OpenOffice, MS Office 2007,...). XQuery používá syntax jazyka XPath pro adresování konkrétních částí XML dokumentů. To je doplněno SQL-podobnými „FLWOR výrazy" pro provádění Joinů. FLWOR výraz je sestaven z pěti klauzulí, po kterých je pojmenován: FOR, LET, WHERE, ORDER BY, RETURN.

Řešení ekonomické dimenze IS/ICT

Co je předmětem řešení ekonomické dimenze IS/ICT, jaké jsou náklady v rámci řešení IS, jaké mohou být přínosy pramenící z IS, jaké znáte metody a způsoby sledování přínosů IS + stručný popis metodiky MMDIS Ekonomická dimenze Ekonomická dimenze zahrnuje finanční náklady tvorby a provozu IS/ICT a přínosy podniku z užití IS/ICT. Cíle stanovené v rámci této dimenze • Určení, které podnikové aktivity mají být prioritně podpořeny funkcemi IS, aby se dosáhlo maximálních ekonomických efektů; a naopak které tuto podporu nevyžadují • Finanční náklady tvorby a provozu IS a přínosy plynoucí podniku z užívání IS (v čase) • Určení zdrojů k pokrytí nákladů Činnosti vykonávané v rámci této dimenze • Účtování poskytnutých služeb a plateb - pomocí účetních operací • Analýza nákladů na IS - pomocí nákladových analýz (ABC, TCO, benchmarking) • Analýza plánovaných a realizovaných efektů IS - složité, protože nelze měřit mimoekonomické efekty, je spíš vyjádřena pomocí odhadů, důležitá vazba na cíle podniku • Hodnocení návratnosti z investic do IS o Statické - ROI, ROA, procento z výnosu, roční cashflow o Dynamické - index ziskovosti PI, metoda doby splácení, čistá současná hodnota (NPV), vnitřní výnosové % • Příprava investičních plánů v informatice Metriky mohou být měkké (slouží k měření a hodnocení úrovně podpory procesů) nebo tvrdé (objektivně měřitelné ukazatele nebo indikátory). • Náklady na informatiku - investiční a provozní náklady, náklady na provoz a údržbu • Podíl nákladů na informatiku v rámci všech nákladů • Náklady na útvar informatiky • Objem efektů informatiky - měřitelných a finančně vyjádřitelných • Ukazatelé návratnosti investic (ROI etc.) • Podíl objemu úspěšných investic v informatice v rámci všech; nebo podíl neúspěšných Fáze zahrnující tuto dimenzi • Úvodní studie a analýzy o odhad všech nákladů (tvorba, nákup, provoz, údržba) o prokázání přínosů (podpora strategie, získání informací známých rychleji nebo nových vůbec, snížení administrativy, realizace náročných úkonů, získání výhody) o určení odpovědných osob za dosažení jednotlivých přínosů • Zavádění - shrnutí nákladů tvorby, vyhodnocení očekávaných přínosů, smlouvy o užití • Provoz a údržba - náklady a účtování, vyhodnocení přínosů, fakturace služeb

Hlavní vývojové etapy podnikových informačních systémů a zásady jejich členění

Existuje více možností, jak pracovat s pojmem vývojová etapa. Buď z pohledu historického vývoje, z pohledu technických možností, nebo z pohledu životního cyklu vývoje software. Je také důležité si uvědomit, že informační systém nemusí nutně představovat počítače, ale i dokumenty v papírové podobě. Jedná se tedy o komplexní sociotechnický informační systém podniku. a) Historický vývoj • 70. léta - vznik MRP (materiál requirement planning) o Tvoří plán výroby o Vstupy: kusovníky, objednávky, skladové zásoby • 80. léta - vznik MRP II (manufacturing resource planning) o Tvoří plán výroby zohledňující kapacitu linky (stroje, čas, peníze) o Spojení MRP a CRP (capacity resource planning) o Současně vznikaly samostatné aplikace pro podporu konkrétních procesů, souhrnně označované jako automatizované systémy řízení (ASŘ). Následně z nich vzniklo CIM (computer integrated manufacturing) CAD (computer aided design) CAPP (copmuter aided process planning) CAM (computer aided manufacturing) • 90. léta - vznik ERP (enterprise resource planning) o Trend integrace dílčích aplikací do celku na jednotné datové bázi a procesním modelu o Podpora i nevýrobních podniků o Automatizace a integrace klíčových procesů, funkcí a dat o Pokrytí většiny řízení (zejm. taktické + operativní) • 00. léta - vznik ERP II (enterprise resource planning integrované s dalšími ASW) o ERP + SCM + CRM + BI + rozšířující moduly PLM, PDM, SRM ERM b) Technické možnosti Postupem času šel vpřed vývoj rychlosti zpracování, velikost úložišť a rozvoj sítí. Rozvíjely se programovací jazyky, zařízení a zjednodušovala se manipulace s HW i SW. Proti tomu se snižovala cena • Nezávisle pracující programy a samostatné aplikace • Integrovatelné aplikace s pomocí middleware • Integrovaný systém se společnou databází • Integrace mezipodnikových aplikací v rámci dodavatelského řetězce • SOA, SaaS • 1970s - sálové počítače, provázanost na konkrétní HW, dávkové zpracování • 1980s - klient/server architektura, dialogové zpracování, textový režim • 1990s - rozvoj internetu, uživatelské obrazovky, multimedia • 2000s - architektura orientovaná na služby, mobilní sítě • 2010s - cloud, umělá inteligence, IoT c) Životní cyklus SW Je vhodné zmínit spíše okrajově. Analýza > návrh > vývoj > testování > nasazení > provoz a údržba > vyřazení. Blíže popsáno v jiné otázce.

Hlavní funkcionalita finanční části ERP

Finanční část ERP musí poskytovat komplexní pohled na finanční data v celé organizaci a efektivní provádění finančních operací Poskytuje komplexní přehled o finančních operacích v podniku, hodnocení ekonomické výkonnosti podniku i jeho jednotlivých obchodních jednotek a průběžné zajištění shody informačního systému s platnou legislativou. Jedná se o vedení všech finančních operací a sleduje se především účetnictví, a to zejména hlavní kniha, saldokonta dodavatelů a odběratelů, správa investičního majetku a finanční konsolidaci. Data jsou do systému zapisována ze zdrojů, kterými jsou účetní doklady. Výsledkem jsou veškeré účty, rozvahy, výkazy zisků a ztrát. Vše bývá spojeno s ostatními daty ERP, takže máme vše dostupné v reálném čase a synchronizováno. Dodavatelé ERP často zaručují soulad s legislativou, a to i účetní, takže máme jistotu, že účtujeme dle zákona. Jsou implementovány i všeobecně uznávané postupy jako GAAP (Generally Accepted Accounting Principles). Rozsah funkcionalit • Finanční účetnictví Hlavní kniha, pohledávky, závazky, konsolidace (spojení více závazků v jediný), pokladna, elektronický bankovní styk... • Nákladové účetnictví Účetnictví nákladových středisek, účetnictví ziskových středisek, nákladové účetnictví zakázek a projektů, zúčtování výkonů, procesní řízení, podpora ABC (Acitivity Based Costing). • Controlling Řízení nákladů, výnosů, zdrojů a termínů. Podrobné analýzy plánu a skutečnosti. Jedná se o klíčový nástroj pro strategické plánování. • Investiční majetek Správa a účtování investičního majetku, plánování a sledování nedokončených investic a investičních akcí - hospodaření s investicemi provází celý životní cyklus investičního majetku. • Hotovost Řízení hotovosti, předpověď likvidity, předpovědi cash-flow, finanční plánování a rozpočty, řízení rizik, peněžní obchody, měnové transakce a transakce s cennými papíry. • Výpočet a účtování mezd • Normy Výkaznictví dle různých účetních norem (např. IAS - mezinárodní účetní standardy, IFRS - mezinárodní standardy účetního výkaznictví, GAAP - Generally Accepted Accounting Principles). • Účtování v cizích měnách a kurzové rozdíly

Hlavní funkcionalita logistické části ERP

Hlavní FUNKCE této části jsou: • Nákup • Prodej • Skladování • Expedice Cyklus logistiky se skládá z: 1. Přijetí obchodního případu 2. Vytvoření objednávky, její obsahová, termínová a cenová specifikace na základě kmenových dat, případně konfigurátorů produktů 3. Plánování potřebných materiálových požadavků včetně zpracování návrhů na nákup, výrobu a kooperaci 4. Objednání a nákup zboží a služeb od dodavatelů 5. Zajištění skladového hospodářství a řízení zásob včetně správy obalů, kontejnerů a nebezpečných odpadů 6. Výroba - o tu se stará výrobní modul ERP 7. Expedice hotových výrobků 8. Archivace zakázek a dalších souvisejících dat Vlastnosti logistické části ERP Pro výrobní a distribuční podniky je důležitá podpora nákupu a odbytu. Logistické procesy se spojují do celku a zjednodušují a urychlují činnosti logistiky. Zlepšují tok informací a tím i rozhodování při plánování. Integrují se i systémy pro správu, plánování a řízení údržby. Dále je pak významná podpora projektového řízení Integrují systémy pro plánování, správu a řízení údržby Podpora projektového řízení (tendence k individualizace zakázek pro jednotlivé zákazníky-stvá se projektem) Řízení nákupů a skladů • řízení dodavatelů - evidence a analýzy dodavatelů, analýzy dodavatelských cen • řízení nákupu - evidence požadavků na materiál jednotlivých výrobních a dalších středisek • akumulace požadavků na nákup, blokace materiálu, zpracování poptávek, evidence nabídek, • zpracování objednávek, evidence dodacích listů, vytvoření příjemky materiálu na sklad • řízení skladových zásob - evidence zásob, příjem a výdej ze skladu, inventury, měsíční uzávěrky skladu, výkazy skladu, obrazové soupisky zásob, likvidace nepotřebných zásob. Sice to není součástí otázky, ale nebylo by od věci okrajově zmínit také: Výrobní modul ERP Plánování výroby, výrobních zakázek, sledování jejich stavu, sledování a vyhodnocování skladových zásob, řízení výroby na úrovni operativního a dílenského řízení. Výrobní modul poskytuje nástroje jako: • kusovníky - evidence a správa kusovníkových položek a jejich charakteristik, přiřazení kusovníku k výrobní zakázce • konfigurátor výrobku - možnost konfigurace vybraných výrobků, stanovení cenových údajů podle proměnných v modelech jednotlivých výrobků, stanovení dodacích termínů • správa výrobních zakázek - zobrazení a sledování prodejních objednávek, zakládání výrobních zakázek, řízení nákupu od subdodavatelů, plánování jednotlivých výrobních zakázek • prognózy a plánování výroby - optimalizace plánování výroby, plánování s respektováním omezených kapacit a dostupnosti materiálů, stanovení nejdříve možného dodání • operativní plánování a řízení výroby

Význam a principy multidimenzionálního přístupu k řešení IS/ICT

Podotázky: dimenze MMDIS, váhy dimenzí a jejich vzájemná návaznost Metodika MMDIS MMDIS (Multidimensional Management and Development of Information System) metodika si klade za cíl přispívat k výchově ICT specialistů, kteří zvýší úspěšnost ICT projektů. Cílem je vývoj, údržba a provoz komplexního a integrovaného informačního systému, který optimálně využívá potenciálu dostupných informačních a komunikačních technologií (ICT) k maximální podpoře podnikových cílů Komplexní IS je takový, který podporuje všechny činnosti podniku, pro které je možné nalézt efektivní informatickou podporu. Integrovaný IS znamená, že IS je tvořen z celé řady HW, SW a datových komponent, které jsou navzájem propojeny do jediného systému. To, že optimálně využívá potencionálu dostupných ICT, znamená, že není nutně postaven na nejnovějších technologických ICT službách, ale vybírá z nich ty, které mají pro daný podnikový IS ekonomický smysl. MMDIS zajišťuje efektivní podporu podnikových cílů a podnikových procesů pomocí integrovaných informatických služeb, procesů a zdrojů a zdrojů MMDIS je globální metodika. Skládá se z 11 základních principů řízení a 5 navzájem propojených konceptuálních modelů (konceptů) řízení. Charakteristika • Fáze: GST, IST, US, GAN, DAN, IM, ZA, PU a VY • Dimenze: HW, SW, INF, PRO, UI, PRA, ORG, BZP, EKO • Role: top manažer, vlastník business procesu, uživatel, analytik, architekt, vývojář, implementátor Principy • myšlenkový přístup k chápání a analýze problému a s ním spojené zásady (pravidla) řešení problému • principy MMDIS jsou aplikovány v konceptech MMDIS • principy jsou základem pro metody, techniky a nástroje řízení Pravidla multidimenzionality každý složitý problém je nutné analyzovat, hodnotit a jeho řešení navrhovat z mnoha dimenzí (pohledů). Pravidla: 1. identifikuj všechny dimenze ovlivňující řešení problému 2. vyřeš problém nejdříve z pohledu každé definované dimenze 3. integruj separátní řešení do výsledného řešení (kombinace dimenzí a optimalizace) 11 základních principů metodiky MMDIS 1. multidimenzionalita 2. vrstvenost 3. integrace 4. flexibilita 5. otevřenost 6. standardizace 7. kooperace 8. procesní pojetí 9. učení a růstu (postupné zlepšování procesů) 10. lokalizace zdrojů a rozhodnutí 11. měřitelnost (metriky) 5 základních konceptuálních modelů metodiky MMDIS 1. model procesně řízené organizace 2. integrace strategie, procesů, služeb a zdrojů (model SPSR) 3. integrace oblastí řízení (model systémové integrace) 4. model tvorby a dalšího rozvoje IS 5. systém řízení IS (model řízení informatických procesů ve firmě) 3 skupiny pohledů Pro řešení informačního systému MMDIS doporučuje použít pohledy zařazené do 3 skupin: 1. První skupina pohledů Je reprezentována dvěma pohledy: • uživatelským - odpoví na otázku, komu je IS určen a jaké ICT služby bude nabízet jednotlivým skupinám uživatelů • řešitelským - odpoví na otázku, jak požadované systém vytvoříme, jak ho budeme provozovat a jak budeme ICT služby dodávat 2. Druhá skupina pohledů Reprezentuje úrovně integrace IS/ICT, použitou úroveň abstrakce a časovou dimenzi řešení. Tato skupina dimenzí se v MMDIS promítá do jednotlivých procesů a fází vývoje IS/ICT. 3. Třetí skupina pohledů Zahrnuje ty dimenze IS/ICT, které se aplikují v každé fázi vývoje IS/ICT. Jedná se o tyto „obsahové dimenze IS/ICT": (inf) informační/datová, (pro) procesní/funkční, (eko) ekonomická/finanční, (org) organizační/legislativní, (pra) pracovní/sociální/etická, (ui) uživatelský interface, (bzp) bezpečnost a kvalita, (sw) softwarová, (hw) hardwarová, (met) metodická, (dok) dokumentační, (mng) manažerská Fáze • Globální podniková strategie (GST) • Informační strategie (IST) • Úvodní studie (US) • Globální analýza a návrh (GAN) • Detailní analýza a návrh (DAN) • Implementace (IM) • Zavádění systému (ZA) • Provoz a údržba (PU) • Vyřazení systému (VY) Role • Top manažer • Vlastník business procesu • Uživatel • Analytik • Architekt • Vývojář • Implementátor • Manažer IS/ICT (CIO) • Správce • Konzultant Dimenze 1. Data/informace (inf) Typy informací, které jsou zapotřebí při jednotlivých podnikových aktivitách, obsah a struktura datové základy podniku a její fyzická realizace. Řešením této dimenze v jednotlivých fázích vývoje IS/ICT je navrhována a realizována datová architektura IS/ICT. Vazba na dimenzi pro, jelikož jednotlivá data reprezentují mimo jiné i vstupy a výstupy ve specifických procesech. 2. Funkce/procesy (pro) Procesy probíhající v podniku a možnost jejich podpory informačním systémem. Řešením této dimenze v jednotlivých fázích vývoje IS/ICT je navrhována a realizována funkční a procesní architektura IS/ICT 3. Organizační a legislativní aspekty (org) Platná legislativa země, ve které podnik působí, podnikové směrnice a normy, platné obecné standardy a normy (např. ISO, ČSN), vliv zavedení nového IS/ICT na organizaci podniku. Náplní je také definování pravidel pro vývoj, údržbu a provoz IS/CIT. Definují se útvary zaměřené na zpracování dat, zodpovědnosti a pravomoci jejich pracovníků, postupy prevence proti mimořádným událostem atd. Vazba na inf i pro - data musí nějak vypadat a musí se s nimi pracovat konkrétním způsobem tj. s určitým omezením. 4. Pracovní, sociální a etické aspekty (pra) Potřebná struktura pracovníků podniku (počet, kvalifikace, věk, pohlaví) pro stav po zavedení nové verze IS/ICT, možné sociální a etické dopady přechodu na novou verzi IS/ICT, potřebná opatření (nábor, resp. propouštění pracovníků, rekvalifikace a školení pracovníků) zavedení nové verze IS/ICT. Vazba např. na pro - jakým způsobem bude probíhat proces školení či přijímání nového zaměstnance. 5. Software (sw) Určení architektury programového systému, tj. určení typů, parametrů a vzájemných vazeb jednotlivých komponent základního a aplikačního programového vybavení a jednotlivých programových modulů. Určení, zda bude daná softwarová komponenta nakoupena, resp. vyvinuta vlastními silami. Vazba je možná na cokoliv, jen to dobře odůvodnit. Např. vztah k eko - řešení přínosu dalšího SW vzhledem k jeho nákladům. 6. Hardware (hw) Hardwarová architektura IS/ICT, tj. typy, parametry a počty počítačů, periferních zařízení, komunikačních sítí a dalších technických prostředků. Vazba je možná na cokoliv, jen to dobře odůvodnit. Např. vztah k eko - řešení přínosu dalšího HW vzhledem k jeho nákladům. 7. Ekonomické a finanční aspekty (eko) Finanční náklady tvorby a provozu IS/ICT a přínosy podniku z užití IS/ICT. V jakém období a z jakých zdrojů budou náklady na IS/ICT kryty. 8. Metody (met) Metody a s nimi související techniky a nástroje používané v jednotlivých fázích vývoje IS/ICT pro analýzu, návrh, implementaci a provoz IS/ICT. 9. Dokumenty (dok) Jaké dokumenty vznikají v průběhu řešení a provozu IS, jaký mají obsah a jak na sebe navzájem navazují. 10. Řízení prací dané fáze (mng) Podklady k optimalizaci spotřeby lidských, finančních, materiálových a dalších zdrojů tak, aby se s minimálními nároky na kapacitu těchto zdrojů dosáhlo v plánovaném čase požadovaných cílů IS/ICT. Váhy dimenzí Váha, resp. významnost téže dimenze se v jednotlivých fázích mění. Např. organizační a ekonomická dimenze mají podstatně větší váhu v úvodních fázích (GST, IST, US), kdežto SW a HW dimenze mají naopak větší váhu v závěrečných fázích (GAN, DAN, IM) řešení IS/ICT. Vazby mezi obsahovými dimenzemi Konzistentní řešení => potřeba řešit jednotlivé dimenze ve vzájemné závislosti => nutná analýza a návrh všech vztahů

Fáze životního cyklu informačního systému

Podtázky: Životní cyklus projektu. Konceptuální a implementační fáze, analýza systému a návrh systému, výstupy každé fáze informatického projektu. Fáze řešení inf. projektu a jejich obsah, inkrementální vývoj, prototypování, problémy při vývoji a návrhu, rozdíly v postupu při jednotlivých typech řešení projektu (TASW/IASW) Účelem této otázky je charakterizovat rozvoj aplikací informatiky v jednotlivých fázích, které tvoří spirálu a označuje se jako životní cyklus aplikace. Vyhází se z celosvětového standardu pro řízení podnikové informatiky (ITIL - Information Technology Infrastrucure Library). Rozvoj aplikací podnikové informatiky seřeší na základě metod a postupů, které se liší, dle toho, zda jde o aplikaci vyvíjenou na zakázku, nebo řešenou na základě typového software, liší se podle typu aplikací, jednotlivých firem a jejich produktů. Doporučené postupy řešení aplikací se označují jako metodiky. Kromě firemních (Sure Step (implementace produktů MS Dinamycs) existují i univerzitní (např. MMDIS). Proces řízení rozvoje aplikací je chápán jako životní cyklus apliací, které zahrnují komplex činností, které jsou vykonány v rámci jednotlivých částí procesu: 1. Plánování a příprava aplikace 2. Analýza a návrh aplikace 3. Implementace aplikace 4. Zavedení do provozu, migrace 5. Provoz a užití aplikace 6. Rozvoj a optimalizace aplikace Životní cyklus - aplikace od svého počátku prochází svými vývojovými fázemi, po určité době svého provozu a rozvoje se vrací na začátek, kdy se připravuje vyšší úroveň aplikace pro danou oblast užití. Řešení jednotlivých aplikací je vždy součástí řízení rozvoje a provozu celého informačního systému a pro každou z dalších fází je uveden základní obsah a principy. 1 Plánování a příprava aplikace Na začátku fáze je pouhý záměr aplikaci řešit, na návěř musí být jasné, zda se aplikace bude nebo nebude realizovat, pokud ano, tak s jakými cíli, fuknkcionalitou apod. 1.1 Vstupní analýza • Posouzení zamýšeného projektu aplikace z celkové koncepce IS/ICT (informační strategie podniky, z pohledu aktuálních uživatelských požadavků na aplikaci - zjistit a posoudit oprávněnost požadavků např. skrze interview) • Z nformační strategie podniku vyplývá zhodnocení, do jaké míry aplikace pokrývá cíle společnosti a její informatiky a jak se váže na ostatní aplikace 1.2 Plánování projektu aplikace • Plán zahrnuje podstatné charakteristiky navrhované aplikace (důvody pro řešení, cíle a očekávané náklady a efekty projektu, cílové skupiny uživatelů) • Návrh plánu je posouzen z hlediska potřeb podniku a dostupných finančních a personálních zdrojů • N základě projektového záměru a zjištěných informací o nabídce trhu se přijimá rozhodnutí o přijetí nebo zamítnutí 1.3 Výběr dodavatele aplikace • Předpokládá se dodavatelský způsob řešení, vedení podniku rozhoduje, zda probíhá na základě výběrového řízení nebo jinou formou (přímý výběr, vlastí průzkum) • U výběrového řízení - zpracování poptávkového dokumentu (přesně vymezit požadavky na aplikaci, definovat postup), dodavatelé připraví nabídku • Referenční instance dodavatele - hotovový realizovaný projekt, který je obdobný poptávanému • Komplexní vyhodnocení - zahrnuje konečné posouzení a zhodnocení předložených nabídek 1.4 Úvodní studie • Účelné v případě dodavatelského způsobu řešení projektu i řešení vlastními kapacitami • Smyslem je stanovat celkovou koncepci řešení, přesně definovat cíle a promítnout projekt do aplikační architektury 2 Analýza a návrh aplikace • Komplex činností spojených s analýzou potřeb osučasného stavu podniku a na tu navazující návrh řešení aplikace 2.2 Analýza podnikových procesů • Rozvoj a změny podnikových procesů jsou realizovány komplexně v rámci projektu procesního reingineeringu zahrnující celý podnik nebo ve vztahu k právě řešeným aplikacím • Rozsah analýzy se liší podle řešení aplikace - od dílčí oblasti (CRM), až poanalýzu celopodnikového řízení (ERP) 2.3 Analýza stávajících databází • Zahrnuje vyhodnocení obsahu, rozsahu, kvality a způsobu jejich využívání • Při ERP se vzhledem k celopodnikévému charakteru analyzují prakticky veškeré datové zdroje a databáze • Účelem je posouzení stavu a kvality pro odhad a plánování jejich migrace do nových databázových struktur 2.4 Analýza stávajících aplikací • Zhodnocení stávajících aplikací je nutné, protože naprostá většina aplikací podnikové informatiky není izolována, ale musí být zasazena do informačního systému. 2.5 Návrh změn podnikových procesů • Vychází z předchozí analýzy, úlohy procesního reenginneringu jsou realizovány jako celopodnikové projekty, využívá metod procesního modelování 2.6 Návrh databází • Návrh dat, datových bází, jejich obsahu a organizace s využitím metod datového modelování • Liší se, zda se jedná o aplikační software na zakázku (datové báze jasně definovány, umožněny pouze dílčí změny) nebo typový aplikační software 2.7 Návrh aplikace • Logická část - vymezuje obsah • Technologická část - technologické nároky 3 Implementace aplikace (technologická realizace aplikace a celý postup řešení aplikace v celém životním cyklu) 3.1 Detailní specifikace modulů • U typového ASW - 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ů atd. • V případě vývoje a dovývoje zahrnuje specifikace běžné součásti zadání programových modulů např. struktura komunikace, specifikace vstupních a výstupních datovch struktur 3.2 Prototypy • Doporučeno 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ů zahrnuje návrh datové základny pro prototyp a určení osob pro testování prototypů 3.3 Kastomizace typového software • Skutečné nastavení parametrů modolů podle podmínek konkrétního typového ASW, testování takto upravených modulů a dokumentaci provedených úprav 3.4 Vývoj a dovývoj • Programová realizace s pomocí zvolených vývojových prostředk (programovacích jazyků), realizace datových rozhraní k ostatním existujícím aplikacím systémů 3.5 Akceptační řízení • Vztaženo jak k díčím projekčním řešením, tak k aplikaci jako k celku • Jedná se o přípravu a instalaci testovaných modulů, přípravu testovacích dat odpovídající reálné situaci • Patří sem také adekvátní výběr pracovníků podniku pro testování • Jsou zde menší nároky na kooperaci s uživateli 4 Příprava na zavedení do provozu, migrace • Po odsouhlasení akceptačních protokolů se připravuje nebo upřesňuje plán migrace (plán postupu zavedení projektu do provozu). Migrace je organizačně a pracovně vysoce náročná činnost. 4.2 Detailní specifikace plánu a harmonogramu migrace • Vychází ze stanovené strategie migrace 4.3 Instalace aplikačního software a dalších technologií • Příprava realizace potřebných technologií a infrastruktury pro aplikaci (instlace aplikačního softwaru na servery, klientské stanice, instalace nebo upgrade potřebných technických zařízení a základního softwaru) 4.4 Migrace dat • Vytvoření všech prvnotních databází konverzeni z původních databází, v některých případech s ohledem na kvalitu se jedná o velmi časově a pracovně náročný problém • Efektivnost této části ovlivňuje provedená analýza stávajících databází 4.5 Organizační příprava provozu aplikace • Organizační opatření spojená se zahájením provozu nové aplikace, úpravy popisu funkčních míst, předpisů, standartních podnikových dokumentů apod. 4.6 Předávací řízení • Předávací procedury - potvrzení, vzájemně zákazníkem a dodavatelem se odsouhlasí požadovaná funkcionalita a provozní charakteristika aplikace • Předávací protokol je formálním ukončením projektu a od té doby se jeho další rozvoj a úpravy zakládají na změnových řízeních 5 Provoz a užití aplikace • Běžné údržbové operace, provozní sevis a permanentní konzultační služby (helpdesk) • Provoz aplikace je zahájen jejím jednorázovým předáním do provozu, následné úlohy se již realizují průběžně a musí bý průběžně zajištťovány 5.2 Předání aplikace do provozu • Vytvoření potřebných provozních kapacit a organizačních opatření, nezbytných pro provozování aplikace • Patří sem například: vytvoření tzv. pofilů jednotlivých uživatelů, nastavení přístupových práv uživatelů i informatiků, stanovení zodpovědností a kompetencí za její provoz 5.3 Správa infrastruktury • Představuje technologické zajišťování provozu aplikace (správa celé počítačové sítě, monitorování jejího provozu, řešení výpadků a poruch) • Podstatnou součástí provozu aplikací je zajištění bezpečnosti provozu, oprávněných přístupů k datům a funkcím aplikace, vyhodnocování a řešení bezpečnostních rizik 5.4 Podpora uživatelů • Zajištění průběžných konzultačních a dalších služeb uživatelům v průběhu provozu a využívání aplikace (help desk), v širším kontextu (service desk) • Kontaktní místo vybavené komunikačními kanály, to, co na základní úrovni nelze řešit, pracovníci help desku předávají na vyšší úroveň podpory 5.5 Monitorování provozu aplikace • Monitorováním provozu aplikací sledujeme jejich vytížení, charakter vzniklých chyb a způsobu jejich řešení, poruchy a provozní chyby technologií, na níž je aplikace provozována • Monitorování poskytuje provozní statistiky 5.6 Návrhy na změny aplikace • Evidence help desku, provozní statistiky i průběžně specifikované požadavky uživatelů mimo standardní evidence jsou základem pro formulace a vyhodnocování nových požadavků na aplikaci a provádění dílčích úprav ASW (na základě změnových řízení) 6 Další rozvoj a optimalizace aplikace • Rozvoj aplikace a její optimalizace má charakter průběžných úprav nebo naopak zásadní změny celého řešení 6.2 Změnové řízení • Vyhodnocení nových požadavků uživatelů vzhledem ke strategickým záměrům rozvoje podnikvé informatiky je realizováno na základě změnových řízení • Změnové řízení se převážně vztahuje k úpravám funkcionality aplikace, pro změnové řízení jsou stanovena základní pravidla: • Určení, kdo je oprávněn formuovat požadavky na změny, kteří uživatelů je mohou formulovat a s jakými kompetencemi • Jaké jsou formální nároky na návrh změn • Kde a jak se požadavky na změny evidují a analyzují (zda je to na straně vlastního útvaru informatiky, na straně dodavatele aplikace, na straně systémového integrátora apod). • Kdo posuzuje požadavky na změny, jaký je postup posuzování požadavků na změny, na základě, čeho se posuzují (vzhledem k projektovému plánu, případně k informační strategii, vzhledem k SLA - Service Level Agreement) nebo ke smlouvě s dodavatelem • Jaké jsou ceny za realizaci změn v projektu, jakýjm způsobem je řešení změn finančně ohodnoceno a vyrovnáno a do jaké míry lze vycházet ze smluv SLA • Jak je informován navrhovatel (uživatel) přijetí, či nepřijetí změny a způsobu termínu jejích řešení 6.3 Návrhy a realizace dílčích úprav aplikace • Na základě posouzení požadavků v rámci změnového řízení se nejprve určí, zda půjde o dílčí změnu aplikace realizovanou v rámci běžné údržby nebo o změnu zásadní, vyžadující specifikaci nového projektu 6.4 Zadání nového projektu • Pokud vedení informatiky v rámci změnového řízení dojde k tomu, že rozsah požadovaných změn případně nové koncepční záměry rozvoje aplikace přesahují úroveň běžné údržby, pak se připrau'vuje zadání nového projektu, příprava dokumentace, jako je projektový záměr • Tím se vracíme na začátek, do fáze 1 celého životního cyklu aplikace • Je tedy zřejmé, že celý cyklus se uzavírá a podle definovaných fází se bude opakovat • K zadání nových projektů dochází nejen v situaci rozsáhlých požadavků, jak jsme uvedli, ale i když počet již provedených úprav a změn v aplikaci dosáhl takového rozshahu, že aplikace je dále neudržitelná - každá další změna přináší značné riziko chyb v celé aplikaci • Dalším důvodem pro nový projekt může být zásadní vývojový posun v provozovaných technologiích, dále to můžou být důvody organizační nebo strategické • Podrobněji k fázím MMDIS v otázce 15. ve starých materiálech

Obecné principy pro tvorbu studie

Studie může být: odborná písemná práce, obvykle kratší vědecký článek, odborné pojednání sborník studií (literárněvědných, o životním prostředí apod.) Vědecké zkoumání = činnost, která je založena především na zjišťování a třídění faktů, získávání dat, ověřování experimentů a to vše při snaze o logičnost a systematičnost Hlavním úkolem vědecké a odborné práce je získávání nových poznatků, znalostí a vědomostí za využití systematického a kritického myšlení. Ať už se autor rozhodne jakkoliv (v jakékoliv formě bude odbornou práci prezentovat), musí vždy dodržet obecně platná pravidla o jazykové normě, struktuře a formální úpravě. Podle Umberta Ecca má práce vědecký charakter pokud splňuje: Předmětem výzkumu musí být nějaký identifikovatelný předmět, který musí být definován tak, aby byl poznatelný a identifikovatelný i pro ostatní. Výstup výzkumu musí být takový, aby námi zvolený předmět zkoumání sdělil nové věci (věci, které nebyly vyřčeny) Výzkum musí být užitečný a prospěšný pro ostatní Výzkumná práce musí poskytnout předpoklady pro potvrzení nebo vyvrácení Druhy a žánry odborného textu Vědecký č odborný text = stylistický útvar, jehož cílem je zaujímat stanoviska, vysvětlovat myšlenky, informovat, komunikovat o teoriích různých vědních oborů s odbornou veřejností. Autor již k známým publikovaným faktům přidává vlastní pohled a poznatky vědeckého charakteru získané vlastním výzkumem nebo odvozené z dřívějších prací. Celkově by měl daný odborný text směřovat k úplnosti a vnitřní uspořádanosti předávané informace. Druhy Odborné texty se tak dělí na 4 druhy: Vědecké - texty určené odborníkům v daném oboru, autoři zpracovávají teorii jednotlivých vědních oborů a usilují o jednoznačnost vyjadřování Populárně-naučné - texty, které zpřístupňují výsledky vědy široké veřejnosti (ta se o problematiku zajímá ale ne na profesionální úrovni) Učební - didaktické texty - učebnice, skripta Esejistické - texty na pomezí odborného, publicistického a někdy uměleckého stylu Z uvedených druhů pak vyplývají funkce odborného stylu: Odborně sdělná - základní funkce všech odborných textů, autor musí zachovávat objektivní přístup ke sdělované skutečnosti (bez emocí a předsudků) Poznávací, systematická, vědecká - souvisí s funkcí odborně sdělnou, tvůrce i příjemce textu jsou vědci (odborníci) Vzdělávací a řídicí - text vede čtenáře tak, aby porozuměl problému a naučil se něco. (učebnice, skripta) Odborně kritická - zhodnocení textu (odborný posudek, recenze) Kvalifikační - jedná se o závěrečné práce, které vedou k získání titulu Bc.; Mgr. a Ing.; PhDr.; JUDr.; RNDr.; doc. Odborné texty se ještě dělí podle původu obsahu na: Práce původní - zdroj nových informací a závěrů Práce přehledové - rekapitulují současné dostupné informace Práce komparativní - srovnávají současně dostupné informace Žánry Vedle druhů odborných textů rozlišujeme i žánry Žánr = zvláštními specifickými znaky odlišený typ kompozičního uspořádání vědecké práce Typy žánrů Abstrakt - nejkratší odborný text, shrnutí celé knihy či práce, zhruba 150 - 250 slov, vždy v českém a anglickém jazyce Resumé - delší shrnutí práce Recenze - zhodnocení vědecké práce, měla by být subjektivní, ne delší jak 7 stran Rešerše - soupis subjektivně nejdůležitějších bodů a myšlenek odborného textu, slouží k rychlému pochopení a orientaci v tématu Konspekt - písemný záznam obsahu a podstatných myšlenek odborného díla, je to prostě výpisek z odborné práce, často obsahuje i komentář autora Anotace - na několika řádcích autor vysvětlí, co se za názvem tématu skrývá. Teze - zhuštěný výklad hlavních (základních) myšlenek teprve připravované publikace. Cca 10 stran Odborný esej - slohově vybroušená úvaha, má za cíl navrhnout řešení nějaké odborné otázky. Poměrně svobodný jazykový útvar, který klade vysoké nároky na odbornost Polemika - vědecký spor, jedná se o vyargumentované hájení vlastního názoru Referát - zpráva o odborném problému a jejich výsledcích Koreferát - je zaměřen pouze na jeden aspekt problému z přechozího referátu Vědecká stať - odborný žánr, ve kterém autor koncipuje vlastní, nové řešení problému či tématu Teoretická - výsledek náročné intelektuální práce, autor předkládá vždy nové řešení daného tématu Empirická - shrnutím výzkumného problému a jeho vyvrcholením, odpovídá na hypotézy, které buď potvrdí, nebo vyvrátí Přehledová - přehled o jednom problému nebo o jedné problematice ze všech úhlů pohledu Odborný a vědecký článek - jedná se o kratší stať, které pojednává o nějakém problému Příspěvek do sborníku - určen k tomu, že hlavní myšlenky a závěry budou autorem předneseny na vědecké konferenci Monografie - vědecká kniha, ve které se autor (odborník) věnuje ohraničenému tématu Učebnice - odborné texty určené ke vzdělávání čtenářů Seminární popř. ročníková práce - zadává se studentům středních i vysokých škol, cílem je aby studen získal zkušenosti a dovednosti Závěrečná písemná práce Bakalářská Diplomová Rigorózní - po tom co uděláš magistra, můžeš složit rigorózní zkoušku Disertační práce Uspořádání odborné práce (principy?) Norma pro strukturu odborné práce - IMRaD (Introduction, Methods, Results, Discussion) Téma a název práce Na začátku každé práce je myšlenka, kterou chceme zpracovat - téma práce. Téma práce musí korespondovat s cílem a přínosem práce. Mělo by odpovídat schopnostem a zájmům autora. Téma musí být konkrétní a nesmí sklouznout k obecnostem. Název práce pak musí odpovídat jak obsahu, tak i zvolenému tématu. Cíl práce Měl by být definován v úvodu práce. Vhodné je zasadit cíl do širších souvislostí a stanovit tak, co s prací souvisí a co ne. Potřeba též odůvodnit, proč jsme stanovili daný cíl. Cíl musí jasně a přesně charakterizovat předmět řešení. V závěru pak musí autor napsat jeho dosažení. Po stanovení cíle je možné přejít ke zpracování osnovy textu Osnova hlavního textu Hlavní text práce je vždy ohraničen úvodem a závěrem. Autor by měl stanovit osnovu práce před tím, než se pustí do psaní. Čím lépe je promyšlené schéma osnovy, tím lépe se práce bude psát. Zásady pro osnovu: Přehlednost - jednotlivé části by měly být sdruženy ve skupinách, aby se dalo práci snadněji členit Jasnost - osnova musí být dostatečně podrobná a pochopitelná Shoda s tématem - obsah práce se nesmí odchýlit od tématu Proporcionalita - každá kapitola i podkapitoly musí být úměrné svému významu Souvislost - mezi jednotlivými kapitolami musí být návaznost a logická souvislost Ucelenost - všechny části jsou nezbytné k vytvoření vyváženého díla Úplnost - téma by mělo být zpracováno komplexně, vyčerpávajícím způsobem Současný stav sledované problematiky Autor by měl uvést dostupné poznatky, které jsou spojené s tématem. Jedná se o autorovo východisko, rešerši Výsledky a interpretace Nejvýznamnější část práce. Výsledky autor musí logicky uspořádat a poznatky dostatečně zhodnotit. Měl by odpovědět na otázky položené v úvodu práce, vysvětlit výsledky a jak k nim dospěl. Závěr a doporučení Obsahuje stručné výsledky celé práce v souladu se stanoveným cílem. Měla by sumarizovat celou práci. Základní členění práce Společné prvky všech vědeckých prací: Název - musí vystihovat práci jako celek, krátký, jednoduchý a výstižný Autor - uvádí se bez titulů, ten se zaznamenává až na konci textu Abstrakt - souhrn odborného textu, kolem 150 - 250 slov max., měl by zahrnovat cíle, metody, zpracování Klíčová slova - termíny, kterými autor charakterizuje obsah odborné práce Obsah Úvod - uvedení do tématu či problematiky Text - člení se do kapitol a podkapitol, začátek nové kapitoly na nové stránce Závěr - nejdůležitější část práce. Odpovídá, zda byl cíl splněn nebo ne. Seznam zdrojů - nachází se na konci, souhrn údajů o citované publikaci Přílohy - vkládají se až za seznam použité literatury, doplňující tabulky, grafy. Při větším počtu příloh je nutné uvést jejich seznam.

Dokumentace IS/ICT

Typy dokumentace, vztah dokumentace k životnímu cyklu systému, metody a nástroje, opatření (metodická, organizační, programová, technická), která vedou ke zkvalitnění dokumentace, úloha dokumentace při řízení projektu Typy dokumentace • Analyticko-projekční - výstupní analýzy, požadavky, omezení, metodika, architektura • Programátorská - neveřejná, popisuje datový model, zdrojové kódy • Provozně-administrátorská - zpřístupnění postupů a informací nutných ke správě, zálohování, reinstalaci IS... • Uživatelská - popisuje fungování systému, použití jednotlivých funkcí a obrazovek (=manuál) • Manažerská - smlouvy, plány projektu, evidence průběhu Úloha dokumentace při řízení projektu • Pomáhá řídit projekt • Sjednocuje pohled na projekt • Pomáhá při aktualizaci SW a řešení krizových scénářů • Je důležitá z důvodu zastupitelnosti (umře zaměstnanec, který všechno měl v hlavě, a jsme v koncích) • Zjednodušuje použitelnost - snižuje riziko chyb a nevhodné manipulace Vztah k životnímu cyklu (MMDIS) • Úvodní studie o Dokumenty: datový model, diagram systému a okolí, funkční model, procesní model, předpisy, finance... o Metody a nástroje: DFD (data-flow-diagram), ERD (entity-relationship-model) • Globální návrh o Dokumenty: výstupy analýz, datový model, funkční model, role uživatelů, org. požadavky, plán školení, přehled vybraného TASW, nároky na HW o Metody a nástroje: ERD, DFD, vztahové matice, UML • Detailní návrh o Dokumenty: návrhy databázových tabulek, obrazovek a reportů, testovací data, detailní specifikace transakcí, návrh algoritmů, plán testování, podrobný plán školení, harmonogram o Metody a nástroje: ERD, DFD, UML • Implementace o Dokumenty: dokumentace zdrojového kódu, výsledky testování, návrh akceptace, plán a kalkulace zavedení, provozní a uživatelské příručky o Metody a nástroje: programování, hypertextové a tabulkové procesory, grafy, • Zavádění o Dokumenty: uživatelská a manažerská dokumentace, zápis zkušebního provozu, postup řešení reklamací, předpisy, shrnutí nákladů, smlouvy o užití o Metody a nástroje: hypertextové a tabulkové procesory • Provoz a údržba o Dokumenty: úpravy v dokumentacích a příručkách, výsledky vyhodnocování, návrhy změn o Metody a nástroje: hypertextové a tabulkové procesory Opatření ke zkvalitnění dokumentace • Metodická opatření - předem určené konvence tvorby dokumentace (např- standardy ISO, metodiky..), určení způsobu tvorby a doplňování dokumentů a konvencí pro tvorbu modelů i samotného programového kódu • Organizační opatření - náležitosti dokumentů (účel, autor, datum, určení, zodpovědná osoba) + místo uložení • Programová opatření - konvence psaní zdrojových kódů a komentářů, způsob využívání knihoven, úložiště (db) • Technická opatření - způsob dokumentace informací (modely, grafy), nástroje pro tvorbu dokumentace

Práce s informacemi a s textovými dokumenty

V rámci přípravy vědecké práce se musíme zabývat otázkou dostupnosti pramenů pro naše zkoumání. O tom, zda přijmeme téma, spolurozhoduje i skutečnost, jsou-li zdroje informací dostupné. K tomu je vždy nutné ověřit: • kde se příslušné informace nacházejí (knihovna, internet, vědecké časopisy, přednášky...) • přístupnost zdrojů (archivy - čas dodání, prezenční studium materiálů, informační agentury, média...) • naši schopnost pracovat se zdroji (jazyk, písmo...) Prameny vědeckých informací Dvě základní skupiny: • primární prameny • sekundární prameny Při hledání informací je vhodné začít orientací v sekundárních pramenech. Sekundární prameny samy o sobě nepřinášejí nové odborné informace, ale ukrývají v sobě odpověď, kde se nacházejí primární informace. Také slouží k rychlé orientaci v základních pojmech nebo k vyhledávání informací o daném problému (slovníky, lexikony, encyklopedie...) Primární prameny jsou důležitými zdroji informací ke zpracování daného tématu (monografie, učební texty, odborné časopisy, právní literatura...; vše v písemné i elektronické podobě) Prvním zdrojem informací bývá internet. Informace z internetu je však nutné si pečlivě ověřovat. Také pomocí následujících otázek: • Je u textu uveden autor, nebo je možné autora textu zjistit? • Známe jméno autora, nebo lze autora přiřadit k nějaké konkrétní instituci či organizaci? • Jedná se o seriózní nabídku například vysoké školy, úřadu, vědecké instituce...? • Jak aktuální je internetová stránka? • Je interpretace tématu kompetentní a ověřitelná? • Není téma zpracováno příliš subjektivně a jednostranně, jsou uvedena i jiná mínění? • Jsou součástí textu údaje o zdrojích a dalších informacích? Lze je ověřit? Bibliografické citace Pro citace existují jak pragmatické, tak právní důvody. K právním patří Zákon č. 121/2007 Sb. o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). Pragmatickým důvodem je možnost ověření uvedených tezí, uvedení tvrzení autora do širšího kontextu a dokázání tak vlastní znalosti tématu, informační a autorská etika.... Způsob citování a bibliografické odkazy určují mezinárodní normy ISO 690. Citování u nás upravuje norma ČSN ISO 690 a ISO 690-2. Prvky citace se dělí na povinné a nepovinné. Povinné prvky jsou autor, název díla, místo a nakladatelství, rok vydání, ISBN (monografická publikace) nebo ISSN (seriálová publikace). Nepovinné prvky jsou jména překladatelů, pořadí vydání, údaje o rozsahu díla, název edice, náklad... Pojmy: Bibliografický záznam je souhrn údajů o citované publikaci nebo její části umožňující její identifikaci. Bibliografická citace je převzetí textu jiného autora do naší odborné publikace. Může se jednat o doslovnou citaci nebo parafrázovanou citaci. Odkaz na citaci je odvolání se v textu na citaci uvedenou na jiném místě. Odkaz je identifikace dokumentu, ze kterého autor cituje. Bibliografie je uspořádaný seznam záznamů o dokumentech, které se týkají předmětu práce, ale nebyly bezprostředně použity k jejímu napsání. Citační etika vyžaduje, aby autor zveřejnil veškeré infromační prameny, které použil. Příklady nejčastějších citací: Citace knihy, monografie: Toman, P. Informatika. Praha: Professional Publishing, 2011. ISBN 978-80-7421. ISBN je mezinárodní standardní číslo knihy, které je v současné době třináctimístné. Podle tohoto čísla lze získat základní informace o původu knihy. Citace příspěvku ve sborníku (monografické i seriálové publikace): Krahulcová, B. (2009) Nové paradigma vysokoškolské pedagogiky. In Vysokoškolské poradenství versus vysokoškolská pedagogika. Praha: CZU. s. 7-12 Citace odborného článku v časopise: Lawrence, S.; Giles, C. L. Accessibility of information. In Economics and Business, roč. 29, č. 2, 2012. ISSN 0009-0789. ISSN je mezinárodní standardní číslo seriálových dokumentů, které se přiděluje za účelem jejich jednoznačné mezinárodní identifikace. Je to osmimístné číslo tvořené arabskými číslicemi od 0 do 9, posledním kontrolním znakem může být také římská číslice X. Citace elektronických zdrojů: Aujezdský, J. Jsou internetové vyhledávače nelegální? Lupa (online). 11. 3. 2008 (cit. 13. 3. 2008). Dostupný z WWW: http://www.lupa.cz/clanky/jsou-internetove-vyhledavace-nelegalni/ Citování elektronických dokumentů je upraveno normou ČSN ISO 690-2. Tato norma rozlišuje citování: • elektronických monografií, databází a počítačových programů • elektronických seriálových publikací • elektronických nástěnek, diskusních fór a elektronických zpráv Odkaz na citaci Odkaz slouží k identifikaci publikace, která byla citována nebo parafrázována. Propojení odkazu s bibliografickou citací lze provést třemi způsoby: • citování podle prvního údaje a roku vydání (tzv. Harvardský styl), vše je uvedeno v závorce bezprostředně za citací. Příklad: (Toman, 2011). • citování pomocí průběžnýh poznámek, zdroje jsou uvedeny ve zkrácené verzi za číslem pod čarou na konci stránky. Příklad: 8) Toman, P. Informatika. Praha, 2011, s. 23. • citování pomocí číselných odkazů - číslice v závorce odkazují na dokumenty v pořadí, jak byly poprvé odkázany Po sobě následujícím odkazům ke stejnému dokumentu je přiřazeno stejné číslo. Pod tímto pořadovým číslem je uveden zdroj v seznamu literatury. Příklad: citace (31) Citační manažery Citační manažery jsou elektronické nástroje pro vytváření, správu, ukládání a sdílení vytvořené či nalezené citace. Existují manažery placené i naplacené. Zotero Volně dostupný manažer, který je nadstavbou prohlížeče Firefox. Umožňuje ukládat a spravovat dokumenty z webu i odjinud. Spousta citačních stylů i možnost vlastních. Export do bibliografických citací v různých formátech. Možnost sdílení mezi ostatní uživatele. Od verze 3.0 k dispozici jako samostatná aplikace propojitelná s Google Chrome a Safari. Citace.com Jednoduchý nástroj s generátorem citací. Není třeba registrace ani přihlášení. V případě využití jako citační manažer registrace nutná je. Také komerční verze Citace Pro určená pro instituce (lepší možosti a funkce). ReferenceManager Umožňuje hledat bibliografické záznamy či plné texty na internetu i ve vědeckých databázích ISI Web of Science, PubMed... Kladem je možnost sdílení databází citací. Vhodný zejména pro knihovny, laboratoře a velké výzkumné ústavy. Plná verze je placená. EndNote Plná verze je placená. Nabízí 38 šablon pro vytvoření citací dle typu dokumentu (starověké texty, umělecká díla, zákony, kapitoly z knih, online články, encyklopedie, tištěné články v časopisech...). Umožňuje ukládání až stovek online zdrojů i plných textů a nabízí až tisícovku citačních stylů. Jazyk odborné práce V odborných textech se nejčastěji uplatňují tři slohové postupy: • popisný • výkladový • úvahový Lingvistické prostředky útvarů odborného stylu Termíny jsou nejcharakterističtějším lexikálním rysem odborného stylu. Představují základní prvky výstavby odborného textu. Lexikální prostředky: • Vyšší frekvence slov přejatých - slova neterminologická (struktury, analýza, báze, diference, absolutní...). V rámci morfologie je dobré se soustředit na skloňování přejatých podstatných jmen (téma, schéma, typ, konzilium...) • Zkratky - užívají se často jak běžné zkratky (apod., atd., aj...), tak oborové (fee, subst...). • Značky - kg, m, MFF... • Vysoká frekvence podstatných jmen Syntaktické prostředky: • Složitá větná stavba • Větná kondenzace - častý výskyt konstrukcí s podstatnými jmény slovesnými, polovětných konstrukcí s příčestími, vět jednoduchých na úkor souvětí • Heslovité vyjadřování • Vsuvky a citáty • Odkazy na informace • Kompozice - organizování jazykových prostředků a tematických složek textu do vhodného sledu o tektonický - kompozice přehledná, uspořádaná, vnitřně soudružná o kauzální - kompozice respektuje vztah příčiny a důsledku o chronologické členění o systematické členění o hierarchické členění... Autor odborného textu se musí rozhodnout, v jaké osobě bude psát. Existují tři základní možnosti: • Neosobní vyjadřování - pasivní forma, autor v pozadí, poznatky s obecnou platností (je věnována pozornost, je nutné, lze si představit...) • Autorský plurál - 1. osoba mn. čísla, sepětí autora a čtenáře (věnujeme pozornost, ukážeme si...) • Autorský singulár - 1. osoba j. čísla (pokusím se odpovědět, zjistil jsem, myslím...) Formální úprava Pro úpravu odborných textů platí norma ČSN 016910 Úprava odborných písemností zpracovaných textovým editory. Norma stanovuje 60 znaků na řádek a 30 řádků na jedné stránce formátu A4, tzv. normostrana obsahuje cca 1800 znaků. Velikost písma 10-12 bodů a řádkování 1,15-1,5 řádku. Nadpisy kapitol velikost 14-16 bodů, poznámky pod čarou 10 bodů. Text zarovnán do bloku. Doporučuje se patkové písmo (př. Times New Roman). Nepatkové vhodné v tabulkách. Zásada max. 3 druhů písma. Meziodstavcová mezera odpovídá cca jednomu volnému řádku. Norma ČSN ISO 2145 Dokumentace číslování oddílů a pododdílů psaných dokumentů doporučuje desetinné třídění ve třech úrovních (př. 1.1.2). Tabulky Ke shrnutí číselných dat nebo pro přehled různých charakteristik. Každá tabulka má nadpis (číslo tabulky a název). Pod tabulkou zdroj. Grafy Ilustrace vysvětlení v textu. Popis os a legenda. Graf musí mít číslo, název a zdroj. Vzorce a rovnice Specializované, kvantitativní a stylizovaný sdělovací prostředek. Jednoznačné, stručné, přehledné, úsporné. Pozor na podobné symboly jako l a číslo 1 nebo O a číslo 0. Vyžadují dodržování normy ČSN 01 1001: Matermatické značky. Obrázky a náčrty Jednoduché a srozumitelné. Do textu pouze, pokud dokumentují výklad problematiky, jinak do příloh. Označují se zkratkou obr. a jsou číslovány. Fotografie Dostatečně syté, nejlépe formátu A5. Mají dokumentační funkci. Zásady jako pro obrázky.

Návrh databáze

Vysvětlit pojmy (entita, objekt, atribut, vztah). Nástroje pro modelování, konverze z konceptuálního do logického modelu, rozdíl mezi logickým a fyzickým modelem, rozdíl mezi objektovými a relačními databázemi, celkově k čemu je prostě konceptuální model dobrý Návrh databáze vždy vychází z modelu, resp. datového modelu, kteří říká, jaká data budeme uchovávat, jaké mají vlastnosti a vzájemné vazby. Modelování (viz 33. Konceptuální modelování obsahu databáze) ER (Entity Relationship) modelování se používá pro abstraktní a konceptuální znázornění dat. Spočívá ve využití základních konstruktů jazyka pro tvorbu diagramů a v metodice tvorby těchto diagramů - základní myšlenkou je, že databáze uchovává fakta o entitách a o vztazích mezi entitami. Výsledkem je ERD (Entity Relationship Diagram, ER diagram). Zásady • Minimalizace redundance (normalizace) • Maximalizovat znovupoužitelnost (dědičnost) • Maximalizovat výkonnost (de-normalizace, metody, database tuning) • Minimalizovat nároky na uložení dat (compression) Využívá se přitom princpy tří architektur. Smyslem P3A je postupně upřesňovat datový model tak, aby zcela odpovídal požadavkům využívané databázové technologie. Stejně tak je naopak žádoucí, aby model v první vrstvě byl, pokud možno, abstraktní a tech. nezávislý. Konceptuální - model reality Logický - Popis způsobu realizace systému v termínech jisté třídy technologického prostředí (lineární, relační, hierarchické, síťové datové struktury) Např. u RDM - doplnění cizích klíčů. Fyzický - Popis vlastní realizace systému v konkrétním implementačním prostředí (doplnění i typu indexu, velikosti, rozmístění pracovního prostoru apod.). Využívá se taktéž metoda normalizace dat Návrh databáze Spočívá v určení entit (tabulek), klíčů (referenční integrita), vztahů (relace), dodržení normálních forem, indexů. Entita • tabulka (ale až v DB), která vykazuje stejné společné znaky • něco, co je natolik důležité, že nám stojí zato to pojmenovat ⇒ v ER modelech modelujeme entitní typy, příklad: • entitní typ: STUDENT, entita: Ondřej Horák • výskyty entit musí být identifikovatelné na základě jejich atributů nebo vztahů s jinými entitami Vztahy = Pojmenované spojitosti mezi entitami Řádek = Kombinace sloupcových hodnot v tabulce. Obsahuje data vztahující se k jednomu objektu. Sloupec = množina dat jednoho typu (jeden atribut) • atribut je modelovaná vlastnost entit nebo vztahů zahrnutých do modelu • každá vlastnost zjistitelná pro nějakou entitu (atribut) je v modelu zakreslena nejvýše jedenkrát • existují také odvozené atributy, které se dají odvodit z vlastností jiných entit • je několik typů atributu / sloupce o povinný o Volitelný - může nemít hodnotu o Vícehodnotový - má hodnoty definované v dané doméně (např. JménoOsoby― u SmluvníPartner) o Skupinový / složený- vnitřní struktura např. u adresy (ulice, město, psč) - obvykle se normalizuje o Atomický - není vícehodnotový ani skupiný Vztahy • mezi entitami lze popsat vztah větou, ve které vztah vyjádříme přísudkovou částí. Např. „Zákazník vytváří Objednávku" • mohou být binární (vztahy dvou entit), ternární (vztah tří entit) i více-ární • u vztahu zjišťujeme a do diagramu zakreslujeme tzv. kardinalitu vztahu o kardinalita vztahu říká, kolik výskytů entit jednoho typu může být v daném vztahu s jedinou entitou druhého typu - říkáme, že vztah je buď 1:1, nebo 1:N nebo N:1 nebo M:N • dále zjišťujeme tzv. povinnost členství ve vztahu o říká, zda všechny výskyty entitního typu, jenž je určen pro danou roli v tomto vztahu, musí do tohoto vztahu skutečně vstupovat - například ne všichni učitelé musí v konkrétním semestru učit nějaký předmět • někdy do konceptuálního modelu zahrnujeme i informaci o tom, zda je vztah přenositelný o například „Učitel učí Předmět" může být přenositelný vztah, kdy se učitelé ve výuce daného předmětu střídají semestr po semestru. • Zpracování vztahů o 1:1 - záznam obsahuje sloupec pro zapsání právě jednoho primárního klíče jiného záznamu o 1:M - záznam obsahuje sloupec pro zapsání právě jednoho primárního klíče jiného záznamu - na onen jiný záznam se může odkazovat více různých záznamů o M:N - může existovat více vzájemných odkazů - realizovano pomocí samostatné vazební tabulky (=dekompozice, neboli rozdělení na dvojici vztahů 1:M) Integrita = pravidla pro zajištění správnosti a konzistence • Entitní = nutnost existence primárního klíče pro každý záznam • Referenční = odkazování pouze na exitující záznamy v povolené kardinalitě • Doménová = stanovení povolených hodnot ve sloupci Indexy = databázový objekt, sloužící ke zrychlení vyhledávacích a dotazovacích procesů v databázi, definování unikátní hodnoty sloupce tabulky nebo optimalizaci fulltextového vyhledávání. • Každý index zabírá v paměti vyhrazené pro databázi nezanedbatelné množství místa (vzhledem k paměti vyhrazené pro tabulku). Při existenci mnoha indexů se může stát, že paměť zabraná pro jejich chod je skoro stejně velká, jako paměť zabraná jejími daty - zvláště u rozsáhlých tabulek (typu faktových tabulek v datovém skladu) může něco takového být nepřijatelné. • Každý index zpomaluje operace, které mění obsah indexovaných sloupců (INSERT, UPDATE). To je dáno tím, že databáze se v případě takové operace nad indexovaným sloupcem musí postarat nejen o změny v datech tabulky, ale i o změny v datech indexu. • Pro správné zvolení indexů by ten, kdo databázi navrhuje, měl vědět, jak často se vybírané záznamy z dané tabulky třídí podle zamýšleného sloupce (a kandidáta na index) a nakolik je důležité, aby vyhledávání a třídění podle něj bylo rychlé. U některých tabulek, které jsou např. číselníky o stálém počtu položek, řekněme max. několika desítkách, nemusí být třeba index definován vůbec.

Organizační, právní, pracovní a sociální dimenze řešení IS/ICT

Vztah organizační struktury, zodpovědností, pravomocí funkčních míst a IS/ICT. Vliv legislativy a norem na řešení IS/ICT. Vliv úrovně znalostí zaměstnanců, partnerů a zákazníků na řešení IS/ICT Organizačně-právní dimenze Cíle: určit zákony, normy a směrnice, které musí IS/ICT respektovat • Soulad s legislativou země • Respektování norem a standardů (ČSN, ISO) • Soulad s podnikovými normami • Přístupová práva zaměstnanců k IS a datům musí být v souladu s jejich kompetencemi Náplň • Právní o Určení zákonů, norem a směrnic, které je nutné v IS respektovat o Autorský zákon, daňové zákony, pracovní zákoník • Organizační o Popis organizační struktury Primární - hlavní org. struktura podniku, tvar stromu, určuje podřízenost a nadřízenost Sekundární - větší množství a jsou vytvářeny ad hoc pro řešení specifických problému o Popis pracovní náplně o Popis podnikových pravidel pro jednotlivé procesy (zvyky, pravidla) o Pravidla pro vývoj, údržbu a provoz IS Dimenze figuruje v těchto fázích metodiky MMDIS • Úvodní studie - identifikace zákonů a norem, stanovení konfliktů, výběr vzorových řešení • Globální návrh - Vymezení kategorií uživatelů, vliv na obsazení útvarů, návrh kontrolní činnosti, koncept práv • Detailní návrh - promítnutí nových funkcí do organizačních a pracovních předpisů; přístupová práva • Implementace - kontrola konzistence předpisů s funkcemi • Zavádění - nové předpisy, zřízení přístupových účtů a přístupových práv Sociálně-pracovní dimenze Cíle: určit potřebné znalosti, přenos informace mezi podnikem a pracovníkem, školení, motivace • Znalosti zaměstnanců, partnerů i zákazníků nutných pro produkci, distribuci a užití ICT • Přenesení genetickou a strukturální informace podniku na pracovníka • Řešení problémů o Školení, jak zadat informace z IS a jak je získat o Využití znalostí a kontaktů nového pracovníka o Určení požadované struktury pracovníků (kvalifikace, věk, vlastnosti) o Zjištění meziútvarové spolupráce a komunikace o Analyzovat sociální a etické důsledky zavedení IS Dimenze figuruje v těchto fázích metodiky MMDIS • Úvodní studie - zjištění žádoucích změn podnikové kultury, vliv IS na složení a charakter zaměstnanců • Globální návrh - plán školení a rekvalifikace • Detailní návrh - revize plánu • Implementace - plán prosazení změn - vyvolat potřebu změny, provedení změny, stabilizace • Zavádění - realizace školení • Provoz a údržba - školení nových uživatelů, podpora, seznamování se změnami

Varianty řešení IS/ICT podniku, jejich výhody a nevýhody

Z pohledu typu aplikačního software IASW = individuálně vyvinutý aplikační software; aplikace vytvořena na míru dle potřeb podniku, funkcionalita aplikace je navržena tak, aby optimálně podporovala činnosti podnikového procesu, pro který je určena • Software přesně odpovídá požadavkům podniku • Inkrementální růst dle potřeb podniku • Vysoké náklady (čas, peníze) • Náročný vývoj • Omezená konfigurovatelnost • Horší integrace v rámci okolního SW TASW = typový aplikační software; aplikace je vytvořena a dále rozvíjena specializovaným výrobcem generalizací požadavků určité třídy podniků - např. bank, výrobců automobilů apod. Může být i opensource, který je přizpůsoben • Rychlá realizace • Levnější kvůli rozpuštění nákladů mezi více zákazníků • Best praktice • Možnost parametrizace • Nedokonale kopíruje podnikové procesy • Lepší integrace s okolním SW (za předpokladů, že okolní není individuální) Z pohledu zdrojů Vlastní síly = realizace všech nebo vybraných činností pomocí vlastních zaměstnanců • Udržení obchodního tajemství • Nutnost živit zaměstnance • Nutnost vytvoření a vyškolení odborného týmu • Nezávislost • Rychlejší reakční doba Outsourcing = realizace všech nebo vybraných činností pomocí externího dodavatele za úplatu • Využití know-how dodavatele • Platím jen co spotřebuji • Přebírá záruky a odpovědnost • Nejnovější technologie • Nutnost zasmluvnění a alokace času dodavatele Z pohledu komplexity Komponenty • Nejlepší funkcionalita pro každou část • Rozložení závislosti mezi dodavatele • Vysoké nároky na integraci komponent • Není garantována funkcionalita celku jako takového Integrovaný balík • Garance funkčnosti řešení jako celku • Zákazník neřeší integraci komponent • Nelze vybrat ideální funkcionalitu pro jednotlivé oblasti • Závislost na jednom dodavateli

Kvalitativní a kvantitativní výzkumné šetření

výzkum = co dělají vědci s použitím svých vědeckých metod Kvalitativní výzkum -cílem kvalitativního výzkumu je vytváření nových hypotéz, nového porozumění, nové teorie -logika kvalitativního výzkumu je induktivní* -kvalitativní výzkum je proces hledání „Kvalitativní výzkum je proces hledání porozumění založený na různých metodologických tradicích zkoumání daného sociálního nebo lidského problému. Výzkumník vytváří komplexní (holistický) obraz, analyzuje různé typy textů, informuje o názorech účastníků výzkumu a provádí zkoumání v přirozených podmínkách" -na začátku výzkumného procesu je pozorování, sběr dat -poté výzkumník pátrá po pravidelnostech existujících v těchto datech, pátrá po významu těchto dat, formuluje předběžné závěry a výstupem mohou být nově formulované hypotézy -také vyhledává a analyzuje jakékoliv informace, které přispívají k osvětlení výzkumných otázek (ty vznikají v průběhu výzkumu) -charakteristiky (Hendl, 2005): • kvalitativní výzkum se provádí pomocí delšího intensivního kontaktu s terénem nebo situací jedince či skupiny jedinců • výzkumník se snaží získat integrovaný pohled na předmět studie, na jeho kontextovou logiku, na explicitní a implicitní pravidla jeho fungování • používají se relativně málo standardizované metody získávání dat, které zahrnují přepisy terénních poznámek z pozorování a rozhovorů, fotografie, audio a videozáznamy, deníky apod. • hlavním úkolem je objasnit, jak se lidé v daném prostředí a situaci dobírají pochopení toho co se děje, proč jednají určitým způsobem a jak organizují své všednodenní aktivity a interakce • data se induktivně* analyzují a interpretují *Induktivní přístup vychází z konstruktivismu a pracuje především z kvalitativních dat. Sběru dat se využívá k získání několika různých pohledů na daný problém. Na základě zjištěných poznatků se vytváří hypotézy, které se následně testují za účelem zobecnění a tím i vzniku „nové" teorie. Induktivním přístupem bývají spojovány případové studie pro řešení otázek „proč" a „jak" a vyžaduje hlubší pochopení daní problematiky. -standardizace (normalizace) v kvalitativním výzkumu je slabá a proto má poměrně nízkou reliabilitu (volná forma otázek a odpovědí nevynucuje taková omezení jako kvantitativní výzkum) - proto potenciálně může mít vysokou validitu (platnost) Kvantitativní výzkum -spočívá v analýze dat, která mohou být získána buď přímým pozorováním nebo dotazováním • pozorování = technika sběru informací založená na zaměřeném, systematickém a organizovaném sledování aspektů, fenoménů, které jsou předmětem zkoumání (př. zjišťování cen výrobků v prodejnách, měření času potřebného pro vyhledání relevantních webových stránek odpovídajících zadanému dotazu) • dotazování = uskutečňuje se pomocí nástrojů (záznamový arch, dotazník - strukturovaný (s uzavřenými otázkami) a nestrukturovaný (s otevřenými otázkami) a vhodně zvolené komunikace výzkumníka s nositelem informací, díky nimž řešitel výzkumného projektu získá žádoucí primární údaje -zjištěná data jsou hodnoty proměnných veličin (proměnných) -> kvantitativní proměnná (cena výrobku, zjištěný čas) -v některých případech je obtížné zjistit kvantitativní údaj přesně (odhad ročních výdajů domácnosti na potraviny), proto dotazovaní respondenti vybírají z nabízených intervalů takový, v nichž by se zjišťovaná hodnota měla nacházet -> ty se obvykle označují pořadovými čísly -> proměnná, která je obsahuje, se nazývá ordinální (pořadová) - nemůžeme je sčítat, na rozdíl od kvantitativních (nelze počítat průměr ani jiné charakteristiky -také jako u kvalitativních proměnných) -pro analýzu kvalitativních a ordinálních proměnných lze použít kvantitativní metody: ->lze zjišťovat četnosti výskytu jednotlivých kategorií (intervalů výdajů, typů výrobků) ->sledovat závislost dvou a více proměnných (zkoumat, zda interval ročních výdajů domácnosti na potraviny závisí na typu domácnosti) ->aplikovat statistické metody určené pro kombinace kvantitativních a kvalitativních proměnných (pro zkoumání, zda čas potřebný na vyhledání webových stránek závisí na typu internetového vyhledávače, nebo modelování možnosti domácnosti realizovat týdenní dovolenou mimo domov v závislosti na různých faktorech, např. na výši příjmů domácnosti a charakteristice osoby v čele) -logika kvantitativního výzkumu je deduktivní*, na začátku je problém existující buď v teorii nebo v realitě, tento problém je „přeložen" do pracovních hypotéz - ty jsou pak základem pro výběr proměnných *Deduktivní přístup vychází z positivismu, nejprve, na základě teorie, formuluje hypotézy a pomocí logického uvažování a již známých faktů testuje tuto hypotézu. K tomu využívá především kvantitativní data. -výstupem je potom soubor přijatých nebo zamítnutých hypotéz -kvantitativní výzkum vyžaduje silnou standardizaci, která zajišťuje vysokou reliabilitu -silná standardizace vede nutně k silné redukci informace - respondent místo toho, aby plně popsal svoje mínění (zkušenosti), je omezen na volbu jedné kategorie z nabídnutého, často velice malého, souboru kategorií -> vede k nízké validitě +rychlý a přímočarý sběr dat a snadné zobecnění výsledků na celou populaci +data jsou přesná, numerická a lehce ověřitelná +výsledky jsou relativně nezávislé na výzkumníkovi -nebere v potaz lokální specifika, nepřichází s ničím novým, může pouze potvrdit či vyvrátit již zavedené teorie Smíšený výzkum =metodologická triangulace -představuje kombinaci kvalitativních a kvantitativních metod při zkoumání -v triangulaci jde o paralelní užívání různých druhů dat či různých metod při studiu jednoho a téhož problému