Srovnávací analýza metodik vývoje software

Rozměr: px
Začít zobrazení ze stránky:

Download "Srovnávací analýza metodik vývoje software"

Transkript

1 Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb Vladimír Popelka Srovnávací analýza metodik vývoje software Bakalářská práce 2009

2 Zadání bakalářské práce

3 Prohlášení Prohlašuji, že jsem bakalářskou práci na téma Srovnávací analýza metodik vývoje software vypracoval samostatně. Všechny zdroje použité při zpracování této bakalářské práce uvádím v přiloženém seznamu použité literatury. V Praze dne Vladimír Popelka

4 Poděkování Rád bych věnoval své poděkování paní PhDr. Heleně Kučerové za odborné vedení, ochotu, připomínky a cenné rady při zpracování tématu bakalářské práce. Dále děkuji panu Ing. Josefu Gabrielovi, zaměstnanci společnosti Unicorn a.s., za odborné konzultace.

5 Obsah 1. Úvod Cíl práce Klíčová slova Hypotéza Metodologie práce Zdůvodnění výběru tématu práce Představení společnosti UNICORN Rizika spojená s návrhem a realizací software Problémy při vývoji software Základní příčiny problémů Příčiny výskytu chyb Eliminace problémů vývoje software Porovnání metodik vývoje software Agilní a rigorózní metodiky Charakteristika směrů vývoje software Tabulka porovnání rigorózních a agilních metodik Porovnání a rozdíly směrů vývoje software Manifest agilního vývoje software Výběr metodik pro porovnání Metodika RUP zástupce rigorózního vývoje Výběr agilních metodik Základní popis zvolených metodik Metodika Rational Unified Process Extrémní programování (XP) Feature Driven Development (FDD) Test Driven Development Výběr vhodné metodiky pro projekt Charakteristika projektu Formulace problému Vymezení problému Stanovení kritérií pro porovnání Kritéria klasifikace metodik

6 4.2.2 Popis kritérií pro porovnání metodik Metodiky podle stanovených kritérií Analýza číselného hodnocení kritérií Stanovení vah pro kritéria Výběr vhodné metodiky podle optimalizační metody Řešení problému pomocí metody TOPSIS Návrh vhodné metodiky pro projekt Testovací strategie Testovací cyklus Kategorizace testů podle metodiky RUP Klasifikace testů podle viditelnosti kódu Klasifikace testů podle dimenze času Klasifikace testů podle dimenze typů testů Návrh testovací strategie Závěr Zhodnocení dosažení cílů Vyhodnocení cílů Vyhodnocení hypotézy práce Závěrečné shrnutí práce Vyhodnocení porovnání metodik software Vyhodnocení návrhu testovací strategie Seznamy a přílohy Seznam použité literatury Seznam obrázků Seznam tabulek Přílohy

7 Abstrakt Srovnávací analýza metodik vývoje software Tématem této bakalářské práce jsou metodiky vývoje software. Úkolem je stanovit rizika spojená s návrhem a realizací software, vymezit problémy a jejich příčiny při vývoji software. Hlavním cílem bakalářské práce je porovnání metodik pro vývoj software. V rámci této bakalářské práce byla porovnána metodika RUP (Rational Unified Process), jako zástupce rigorózního vývoje, s metodikami XP, TDD, FDD, jako zástupci agilního vývoje. Porovnání bylo realizováno pomocí vícekriteriální optimalizační metody TOPSIS. Vybrané metodiky byly porovnány se zaměřením na oblast testování. Na základě specifikace požadavků projektu byla zvolena vhodná metodika pro vývoj software. Pro vhodnou metodiku byla navrhnuta testovací strategie pro pokrytí systému testy, zahrnující testovací cyklus a klasifikaci testů. 7

8 Abstract The comparative analysis of software development methodologies This bachelor work deals with different methodologies of software development. It aspires to define risks connected with design and realization of software and to depict problems encountered during software development as well as their causes. The main aim of my bachelor work is to compare different methodologies of software development. I tried to compare the RUP methodology (Rational Unified Process), as a representative of rigorous development, with XP, TDD and FDD methodologies, as representatives of agile development. Comparison was carried out by the multicriterion optimalization method TOPSIS. Chosen methodologies were compared with focus on software-testing issues. In accordance with specification of project requirements the suitable software development methodics was chosen. For this suitable methodology the test strategy for coverage of system with tests, including the testing cycle and tests classification, was designed. 8

9 1. ÚVOD 1. Úvod 1.1 Cíl práce Hlavním cílem bakalářské práce je porovnání metodik pro vývoj software se zaměřením na oblast testování. V rámci této bakalářské práce budu porovnávat metodiku RUP (Rational Unified Process), jako zástupce rigorózních metodik, s metodikami XP, TDD, FDD, jako zástupci agilního vývoje. Porovnání bude realizováno pomocí vícekriteriální optimalizační metody TOPSIS. Dalším úkolem je stanovit rizika spojená s návrhem a realizací software, vymezit problémy a jejich příčiny při vývoji software. Na základě specifikace požadavků projektu zvolím vhodnou metodiku pro vývoj software. Pro vhodnou metodiku navrhnu testovací strategii pro pokrytí systému testy, zahrnující testovací cyklus a klasifikaci testů. 1.2 Klíčová slova metodiky vývoje software agilní a rigorózní metodiky Rational Unified Process testování software testovací strategie TOPSIS 1.3 Hypotéza Hlavním předpokladem této práce je, že na základě porovnání metodik vývoje software zaměřeného na problematiku testování a na základě jasně definovaných požadavků na projekt bude pro řízení softwarového projektu zvolena metodika RUP. Tato metodika patří v současné době k jedné z nejlépe popsaných. Lze tedy očekávat, že její použití bude mít pozitivní vliv na efektivnější řízení vývojového procesu. 9

10 1. ÚVOD 1.4 Metodologie práce V úvodu práce jsem se soustředil na nejčastější problémy při vývoji software. Moje zkoumání bylo založeno na studiu odborné literatury. Rovněž jsem postupoval podle praktických zkušeností z projektu vývoje software, uplatnil jsem tedy metodu pozorování. V návaznosti na problémy jsem se zaměřil na jejich řešení pomocí metodik. Na základě kritérií jsem porovnal nejprve dva směry vývoje software, rigorózní a agilní metodiky, a poté metodiku RUP a vybrané zástupce agilního vývoje. Výběr metodiky vývoje software jsem prováděl na základě zadání projektu. Volba požadavků nevycházela z žádného skutečného projektu. Porovnání metodik bylo prezentováno na modelové situaci. Pro výběr metodiky jsem použil optimalizační metodu manažerského rozhodování TOPSIS. Nejprve jsem stanovil kritéria, následně jim přiřadil váhy, pak jsem provedl výpočet, jehož výsledkem byla jedna optimální metodika. Klíčovou metodou při porovnávání a výběru metodiky bylo kvalitativní srovnání metodik vývoje software, při němž jsem použil matematické metody. Pro vybranou metodiku jsem zpracoval návrh testovací strategie, kde jsem se zaměřil na testovací cyklus a rozdělení typů testů do kategorií. Při stanovení testovací strategie jsem využil metodu klasifikační analýzy. Nejprve pro každou fázi testovacího cyklu jsem definoval činnosti, které se v ní budou vykonávat, a následně každému aspektu testování jsem přidělil jednotlivé typy testů. Na závěr jsem navrhl testovací strategii, která obsahovala seznam kroků a pravidel, podle kterých se má řídit úspěšné testování. V závěru jsem provedl vyhodnocení zjištěných výsledků. 1.5 Zdůvodnění výběru tématu práce V rámci této bakalářské práce jsem se zaměřil na porovnání metodik vývoje software. Hlavním záměrem práce je porovnání metodiky RUP (Rational Unified Process), jako představitele rigorózních metodik, s vybranými zástupci agilního vývoje. Hlavním důvodem tohoto rozhodnutí byla myšlenka, zda-li metodika RUP představuje vhodné řešení pro řízení projektu a vývoj software. Zúčastnil jsem se projektu pro společnost Unicorn, kde jsem působil v roli test analytika v rámci zajišťování kvality softwarového produktu informačního systému firmy Unicorn. Rovněž mám zkušenost z projektu v oblasti bankovnictví. Na obou těchto projektech byla vždy aplikována metodika RUP. 10

11 1. ÚVOD Volbu vhodné metodiky pro vývoj software a řízení projektu považuji za klíčovou. Proto si myslím, že porovnání metodik vývoje software podle nejrůznějších aspektů a hledisek představuje první krok pro volbu vhodné metodiky a nejdůležitější krok pro efektivní průběh celého projektu. 1.6 Představení společnosti UNICORN UNICORN je největší česká společnost poskytující komplexní služby v oblasti informačních systémů a informačních a komunikačních technologií. [12] Společnost Unicorn byla založena v roce 1990 a využívá více než 17 let zkušeností. Unicorn zajišťuje efektivní řešení a služby zejména v oblastech: projekce, konstrukce, integrace a provozu informačních systémů, dodávky software, konzultací a školení. Pro své zákazníky poskytuje společnost Unicorn služby zaměřené na všechna odvětví průmyslu, pokrývá důležité obchodní a technologické oblasti trhu, zejména pak oblast bankovnictví, financí, telekomunikací, informačních technologií a energetiky. [12] 11

12 2. RIZIKA SPOJENÁ S NÁVRHEM A REALIZACÍ SOFTWARE 2. Rizika spojená s návrhem a realizací software Základním cílem každé firmy bez ohledu, zda-li působí v oblasti bankovnictví, pojišťovnictví, telekomunikací, informačních a komunikačních technologií anebo v dalších segmentech trhu, je uspět v podmínkách tržního hospodářství a otevřené konkurence. Klíčem k úspěchu je v současné době pružně reagovat na změny trhu, přizpůsobit nabídku potřebám zákazníka, schopnost inovovat, prohlubovat vzdělání a neustále se zdokonalovat. Cílem firmy je proniknout na nové trhy a poskytnout svým zákazníkům konkurenční výhodu a přidanou hodnotu v podobě kvality služeb. Schopnost obstát v konkurenci, která se může díky dynamickému charakteru trhu a také vlivem expanze informačních technologií vynořit odkudkoliv, záleží hlavně na efektivním a strategickém řízení firemních procesů. Vzájemnou součinnost a propojenost podnikových procesů, ať už se jedná o řízení lidských zdrojů, strategické rozhodování a plánování, efektivní řízení firemních informací nebo optimalizaci znalostních toků, výrazně usnadňuje informační systém. Kvalitní softwarový produkt je dnes nezbytným řešením jak pro velké organizace, tak i pro malé firmy. Vývoj informačního systému však není jednoduchou záležitostí. Při jeho vývoji dochází k mnoha problémům. Detailnímu rozboru rizik a problémů spojených s návrhem a realizací software se bude věnovat celá tato kapitola. 2.1 Problémy při vývoji software Vývoj software vyžaduje improvizaci, náročné přemýšlení, tvůrčího ducha. Výsledkem práce softwarového inženýrství jsou nehmotné informace, tedy zcela odlišný typ zboží než v uvedených oblastech trhu. Tato skutečnost je základem většiny problémů. Závažné problémy při vývoji software popisuje obrázek (obr.2.1). [6, s. 9] 12

13 2. RIZIKA SPOJENÁ S NÁVRHEM A REALIZACÍ SOFTWARE Obr.2.1. Problémy při vývoji software [6, s. 15] Asi nejčastějším problémem při vývoji software je zpoždění proti stanovenému plánu. Pokud je pevně stanovený termín dokončení a navíc je vázaný na další událost, pak každé zpoždění je kritické. Za problém, který se projeví v pozdních fázích vývoje, je považována nedostatečná výkonnost. Systém špatně funguje pod zátěží, častým jevem jsou výpadky a zpomalení systému. Zátěž výrazně přesahuje limity, které byly odhadovány během vývoje. Aplikace má výkonnostní limit, který lze překročit jen výjimečně. Zjištění nedostatečné výkonnosti během ostrého provozu znamená velký problém, kterému lze předcházet testováním výkonnosti v rámci celého vývojového cyklu. [6, s ] Za další problém bývá označována vysoká chybovost neboli častý výskyt chyb. Chyby se vyskytují téměř vždy. V případě zanedbání testování se při každém zásahu do stávajícího kódu může množství chyb navyšovat. Odladění chyby v hotovém programu je velmi náročné, eliminace chyb může znamenat zpoždění projektu. Zde platí obecné pravidlo, že později objevená závažná chyba značně ovlivňuje růst nákladů. V případě, že je nutné program upravit a k dispozici není dostatečně podrobná dokumentace nebo kód je uveden bez komentáře, každá změna je nesmírně náročná. Pokud se program mnohokrát upravuje, rozšiřuje a zdokonaluje, stává se jeho údržba a správa obtížnou. V tomto případě se jeví jako lepší řešení naplánovat kompletně novou verzi aplikace. [6, s ] Pokud program nesplňuje požadované funkční požadavky, jedná se o další závažný problém, který úzce souvisí se špatnou nebo nedostatečnou vzájemnou komunikací 13

14 2. RIZIKA SPOJENÁ S NÁVRHEM A REALIZACÍ SOFTWARE mezi zadavatelem a řešitelem nebo v rámci vývojového týmu. Komunikační překážky mezi programátory a testery bývají také často umocněny i nepřesnostmi v terminologii. Jestliže se návrh řešení nesetkává s očekáváním koncového uživatele např. z hlediska složitého uživatelského rozhraní, můžeme tuto skutečnost klasifikovat jako další nedostatek. Příliš nepřehledné nebo nepochopitelné uživatelské rozhraní znamená další rizikový faktor. [6, s ] Dalšími problémy, které do jisté míry navazují a doplňují již dříve uvedené, jsou nekoordinovaná součinnost týmu, neslučitelnost jednotlivých programovým modulů a nejasně definované požadavky mezi zákazníkem a řešitelskou firmou. [6, s ; 9] 2.2 Základní příčiny problémů Po provedení analýzy neúspěšného projektu se pro daný problém téměř vždy vyskytne více vzájemně souvisejících příčin, které ho způsobují. Hranice mezi úspěchem a neúspěchem softwarového projektu bývá velmi úzká. [6, s.18] Většina z projektů se řadí mezi tyto dva extrémní stavy. Pokud se vyskytnou problémy obvykle se je podaří překonat za cenu např. zpoždění nebo vynechání plánovaných funkčností programu. Hlavní příčiny, proč softwarové projekty selhávají ukazuje obrázek (obr.2.2). [6, s ; 9] Obr.2.2. Základní příčiny problémů [6, s. 18] Špatné projektové řízení může vést k nesprávné koordinaci týmu, v případě návaznosti práce musí jeden člen týmu čekat na výsledek druhého kolegy. Manažer projektu musí provést objektivnější odhad posloupnosti činností. Tato příčina má společný jmenovatel a pokrývá všechny zde uvedené příčiny. Za nejrozšířenější příčinu problémů softwarového vývoje se považuje podcenění náročnosti projektu. Manažer 14

15 2. RIZIKA SPOJENÁ S NÁVRHEM A REALIZACÍ SOFTWARE projektu neodhadne všechny rizika spojená s projektem a zvolí nevhodný způsob řízení a plánování např. bez ohledu na velikost a rozsah projektu. Jinou významnou příčinou problémů bývá nedostatečné testování. Programátoři snižují důležitost testů, zákazníci význam zkušebního provozu. Jestliže se projekt dostane do skluzu, testy se zkracují a testeři mají časově omezené podmínky pro vyhledávání chyb. [6, s ] Další významné a časté příčiny problémů softwarových projektů jsou špatně definované zadání, nedostatečná analýza požadavků, nekontinuální a nekonzistentní projektový plán. Manažer projektu se nesmí dopustit chyby podcenění projektu a musí si uvědomit všechna rizika, která mohou nastat. Nesprávné rozložení činností v jednotlivých fázích projektu může způsobit např. podcenění analýzy a brzké psaní samotného kódu a programování aplikace. Každý požadovaný aspekt zvyšuje složitost projektu, prodlužuje dobu vývoje, komplikuje budoucí úpravy a snižuje výkon v reálném provozu. Mnoho požadavků a náročné zadání vedou k přílišné složitosti projektu, která je další příčinou problému. Špatná kvalita programového kódu způsobuje mnoho problémů ve fázi testování, nasazení a údržby. Kód je nepřehledný, nesrozumitelný, nejasně okomentovaný a příliš chybový. [6, s ] 2.3 Příčiny výskytu chyb Pokud se v průběhu některé fáze projektu anebo v již dokončené a otestované aplikaci objeví neobvykle mnoho chyb, nastala situace, kdy je velmi pravděpodobný neúspěch softwarového projektu. Vysoká chybovost ve většině případů znamená selhání projektů. Nenalezené chyby mohou způsobit velkou finanční ztrátu. [6, s ] Mezi nejčastější příčiny, které způsobují velké množství chyb a následné selhání projektu patří : [6, s ] Špatná komunikace Dokončení v termínu za každou cenu Nové technologie Nedostatečná zkušenost, znalosti a kvalifikace Nedostatečná (neúplná) definice požadavků Složitost projektu 15

16 2. RIZIKA SPOJENÁ S NÁVRHEM A REALIZACÍ SOFTWARE Chce-li řešitelská firma zabránit velkému výskytu chyb a snížit riziko neúspěchu projektu, musí nutně předejít případným překážkám při komunikaci a vyhnout se nedorozumění. Jestliže zadavatel projektu zapomene zmínit některé požadavky ve specifikaci třeba z důvodu, že je považuje ve svém oboru za samozřejmé, jedná se o jasný příklad špatné komunikace mezi zadavatelem a řešitelem software. Naopak tvůrce, ať už analytik anebo programátor, může mít tendenci zjednodušovat problémy klienta a zaměřit se na technické otázky. Existuje-li hrozba nedodržení termínu, nesmí se stát první obětí testování. Některé nevyřešené funkčnosti systému, které se nestihnou dokončit, se mohou přesunout do následující verze systému. Při snaze o dodržení termínu za každou cenu a dokončení software včas se tvůrci mohou dopustit velkého počtu chyb. Řešením může být posílení týmu nebo zjednodušení požadavků. [6, s ] Používání zcela nové technologie může také způsobit mnoho problémů. První verze nové technologie nemusí být kompatibilní s použitým hardwarem nebo softwarem, v případě nastání potíží není jednoduché najít zkušeného odborníka, který se v technologické novince dokonale vyzná. Proto je prozíravější se nevyzkoušené technologii vyhnout, zejména u velkých projektů. I když je hrozba nefungující technologie minimální, pokud nastane, jedná se o závažné chyby, závažnější než chyby nalezené v programu. Podcenění definice požadavků na systém může mít za následek neustálou změnu požadavků v průběhu nebo dokonce ve finální fázi projektu. Rovněž zkreslení nebo nepochopení požadavků analytikem může vést k chybám. [6, s ] Malá zkušenost, nedostatečná kvalifikace anebo nerovnoměrné rozložení znalostí jednotlivých členů vývojového týmu může znamenat snížení produktivity a výkonu práce při řešení úkolů. Za klíčový se považuje výběr jednotlivých členů týmu. Důležité je stavět týmy vyvážené a nepodceňovat rozdíly znalostí mezi vývojáři. Pro úspěšné dokončení úkolu musí být v týmu dostatek zkušených a schopných vývojářů. Dobrou volbou může být i zapojení nováčka, zvláště pokud se jedná o projekt menšího rozsahu. Častou příčinou selhání projektu je přílišná složitost projektu. Odhad náročnosti projektu musí být reálný stejně jako odhad času, který je nutný na jeho realizaci. Součástí projektového plánu musí být i rezervy na nepředvídatelné události. Někdy je výhodnější zaměřit se na primární aspekty aplikace a doplňky řešit v další verzi programu. [6, s ] 16

17 2. RIZIKA SPOJENÁ S NÁVRHEM A REALIZACÍ SOFTWARE 2.4 Eliminace problémů vývoje software Cílem vývojového procesu software je snížení výskytu problémů. Problémy, které jsou spojené s návrhem a realizací software se snaží eliminovat metodiky vývoje software. Metodika je tvořena obecně uznávanými postupy a návody, které popisují činnosti při návrhu, vývoji, nasazování software, řízení projektu atd. Cílem metodiky je formalizovat postupy, definovat zodpovědnosti a pravidla komunikace. [3, s. 173] Metodika tedy vymezuje pravidla a kompetence, kdo má provádět jaké činnosti a jakým způsobem během vývoje. Přispívá k efektivní organizaci práce na projektu. Definuje postup řešení jeho priority, zabývá se plánováním, dokumentací a všemi aspekty celého procesu tvorby software. [2, s ; 3, s. 173] V praxi se zcela jistě nenajde softwarový projekt, který by probíhal hladce podle přesně definované metodiky vývoje. Členové vývojového procesu se nikdy nesetkají s podrobnou specifikací dokonale vystihující požadavky zákazníka, nebo s dokonale propracovanou analýzou a návrhem architektury. Proces implementace a testování nikdy nebude bezproblémový. Použití vhodné metodiky pro vývoj software však výrazně přispívá k efektivnějšímu průběhu celého vývojového procesu. Proto její výběr podle požadavků na zadání projektu má klíčový význam pro úspěch celého projektu. Podrobnému popisu metodik vývoje software a porovnání dvou směrů softwarového inženýrství je věnována následující kapitola. 17

18 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE 3. Porovnání metodik vývoje software 3.1 Agilní a rigorózní metodiky Charakteristika směrů vývoje software Softwarové inženýrství přineslo za dobu své existence celou řadu metodik a životních cyklů. V současné době existují dva hlavní směry v metodickém přístupu vývoje software, jedná se o rigorózní a agilní metodiky. Rigorózní metodiky podrobně a přesně popisují jednotlivé procesy vývoje software, definují posloupnost činností, obsahují objemné dokumentace a jsou založeny na sériovém (vodopádovém) vývoji. Zpětnou vazbu mezi fázemi se snaží získat prostřednictvím řízení změn. Rigorózní metodiky umožňují popsat, plánovat a řídit procesy při návrhu a realizaci IS/ICT (informačních systémů a technologií). Některé rigorózní metodiky jsou realizovány iterativním způsobem tzn., že při vývoji jsou opakovaně prováděny jednotlivé fáze anebo inkrementálním způsobem tzn., že systém je vyvíjen v přírůstcích. V následujícím přehledu jsou uvedeny jen nejznámější zástupce rigorózních metodik. [2, s. 29 ; 5, s. 53] 1) Vodopádový model životního cyklu 2) Spirálový model životního cyklu 3) Unified Process (= Metodika Unified Software Development Process) 4) Rational Unified Process 5) Enterprise Unified Process Vývoj software patří mezi dynamicky se měnící odvětví. Změny přicházejí nejen ze strany konkurence a softwarového trhu, ale také nastávají vlivem rostoucího množství, kvality a dostupnosti nových vývojových prostředí a nástrojů. Právě již zmíněný dynamický vývoj vede k přehodnocení popřípadě změnám ve způsobu vedení vývoje software. Tradiční rigorózní přístup se zaměřuje na důkladnou podrobnou analýzu a propracovaný návrh. Některé rigorózní metodiky postupně přestávají naplňovat očekávání a přestávají být použitelné. V současnosti se však začali postupně prosazovat metodiky zaměřené na co nejrychlejší vývoj software a reakci na měnící se požadavky a 18

19 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE zadání. K tradičnímu vývoji se v posledním desetiletí objevil nový proud vývoje, jehož principy jsou poměrně odlišné. [5, s ; 2, s ] Agilní metodiky umožňují vytvořit řešení velmi rychle a pružně je přizpůsobovat měnícím se požadavkům, nesnaží se potlačovat změny, ale naopak jich využívají. Agilní metodiky jsou v rozporu s osvědčenými klasickými postupy softwarového inženýrství, vycházejí totiž z přesvědčení, že správná cesta upřednostňuje rychlý vývoj a následné úpravy změn na základě zpětné vazby od koncového uživatele. Ukazují dosavadním postupům novou cestu a boří některé představy vývoje software, které byly dosud považovány za nedotknutelné. Snaží se řešit požadavky na rychlý a flexibilní vývoj aplikací. [5, s ] Následující přehled představuje jen nejznámější zástupce agilního vývoje. Výčet obsahuje konkrétní metodiky, které vycházejí z agilního manifestu. [5, s. 123 ; 2, s. 44] 1) Adaptive Software Development Adaptivní vývoj software 2) Feature-Driven Development Vlastnostmi řízený vývoj 3) Lean Development 4) Extreme Programming Extrémní programování 5) SCRUM Development Process 6) Crystal metodiky 7) Test-Driven Development Testy řízený vývoj 8) Dynamic System Development Method DSDM Tabulka porovnání rigorózních a agilních metodik Hlavní rozdíly mezi oběma směry vývoje přibližuje tabulka porovnání rigorózních a agilních metodik (Tab.3.1), která je uspořádána podle vybraných hledisek porovnání. 19

20 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE 1. Proces vývoje software 2. Změny a požadavky 3. Zapojení zákazníka na řízení projektu Rigorózní metodiky Přesně a podrobně definovaný proces, lze ho opakovat. Minimalizace změn (sběr požadavků předem a plánování předem), změny jsou součástí řízení změn. Bez zásahu. Nedůvěra v zákazníka - Po podpisu smlouvy a vymezení dokumentu specifikace požadavků v počáteční fázi, zákazníka zajímá až konečné řešení. Agilní metodiky Empirický proces, není možné ho opakovat, ale vyžaduje adaptaci. Akceptace změn (přírůstkové shromažďování požadavků, plánování pro iteraci) přehodnocení požadavků, snaha o umožnění změn (v závislosti na nových znalostech). Participace a spolupráce - Zákazník se aktivně zapojuje do celého projektu, může měnit priority funkcí při každé iteraci. 4. Kvalita Více zaměřeny na kvalitu vlastních procesů, než na výsledek pro zákazníka. Zaměření na priority zákazníka, na užitnou hodnotu pro zákazníka, tedy na výslednou kvalitu produktu. 5. Způsob a rozsah řešení 6. Rozložení teamového know-how Podrobný popis procesů a činností, složité řešení. Při vývoji obsaženy všechny funkce, snaha o zabudování budoucích požadavků. Každý člen týmu má přiřazeny činnosti, v rámci role, kterou zastává. Požadavek na specializaci zaměstnanců. Převládá písemná forma komunikace (dokumentace). Eliminace nepotřebných činností, jednoduché řešení. Při vývoji zahrnuty jen potřebné funkce, snaha o minimalizaci, žádné začlenění budoucích požadavků. Sdílení znalostí v týmu, spolupráce (kooperace) a aktivní komunikace v rámci týmu, společné řešení problémů, řízení a integrace znalostních toků. 7. Lidský faktor Pohled na lidi jako na sekundární faktor, procesy doplňovány rozsáhlou dokumentací. Jedinci jsou nahraditelní. Lidé jako primární a klíčový faktor úspěchu projektu. Využití schopností a dovedností jedinců (individualit), důraz na znalosti, kvalifikaci. 8. Způsob vývoje Vodopádový životní cyklus, iterativní s dlouhými iteracemi. Přírůstkový (inkrementální) vývoj s velmi krátkými iteracemi. Tab.3.1. Porovnání agilních a rigorózních metodik [2, s ; 7] 20

21 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE Porovnání a rozdíly směrů vývoje software Množina požadavků na funkcionalitu je jednoznačně stanovena na začátku vývoje. Prioritou tradičního přístupu vývoje zůstává tedy naplnění funkčnosti, přičemž potřebné náklady na projekt stejně jako čas nutný k jeho dokončení se jen odhadují, nikoliv přesně stanovují. Formulace požadavků na funkcionalitu zůstává fixní, variabilní jsou zdroje a čas. Metodiky agilního vývoje naopak přesně vymezují konečný termín dokončení pro realizaci projektu a nejvyšší možné zdroje na začátku projektu. Předmětem změn se stávají jednotlivé funkčnosti aplikace. Požadavky na funkcionalitu se přizpůsobují v průběhu vývoje, zatímco čas a zdroje zůstávají neměnné. [5, s. 119] Agilní metodiky jsou využívány na projektech, kde se zadání často mění nebo není přesně specifikováno. Právě z důvodu častých změn je nutné průběžné a opakované ověřování správnosti zdrojového kódu. Automatizované testování by mělo předcházet implementaci. Silný důraz je kladen na psaní programového kódu, které začíná ihned po vymezení cílu projektu a tvorbě testů. Agilní přístupy kladou důraz na komunikaci mezi procesy (např. párové programování), proto jsou chyby a problémy dříve odhaleny. Nové funkčnosti jsou implementovány poměrně v krátkých dodávkách, proto je iterativní a inkrementální způsob vývoje spojen s velmi krátkými iteracemi. Zákazník má možnost monitorovat a upravovat průběžné konfigurace. Obsahují podstatně menší objem dokumentů, jejich dokumentace není tak rozsáhlá jako u rigorózních metodik. [5, s ] Manifest agilního vývoje software Agilní metodiky prosazují rychlý vývoj a následnou reakci na změny. Trend směřuje k agilnímu vývoji, protože vznikl jako reakce na nedostatky tradičního rigorózního přístupu a zdůrazňuje efektivitu vývojového procesu. Manifest agilního vývoje popisuje následující text. [2, s. 43] Odhalili jsme lepší způsob vývoje software, 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 software před obsažnou dokumentací, spolupráci se zákazníkem před sjednáváním kontraktu, reakci na změnu před plněním plánu. [2, s. 43] 21

22 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE Manifest agilního vývoje vyplývá ze dvou základních myšlenek: [5, s. 120] 1) Efektivnější je přijmout změnu než se jí bránit. 2) Nepředvídatelné události určitě nastanou, proto je změna jedinou jistotou. Manifest deklaruje základní principy agilního vývoje, které jsou shrnuty do následujících řádek. Vítané jsou velmi krátké iterace a zkrácení cyklu dodávky fungujícího software. Preferují se jednoduché postupy vývojového procesu. Na začátku projektu se definují hrubé požadavky pro návrh architektury, přičemž v průběhu projektu je možná jejich úprava na základě přání zákazníka, nebo-li zákazník je aktivním členem týmu. [2, s ; 5, s ] Vítané jsou změny, dokonce i pozdních fázích projektu, neboť můžou znamenat konkurenční výhodu. Zadavatel musí mít z konečného řešení software užitek a přidanou hodnotu. Změnové požadavky promítnuté ve zdrojovém kódu jsou chápány jako přirozené a jen zdůrazňují kvalitu návrhu. O úspěchu projektu rozhodují lidé s knowhow a potřebnou motivací. Proto dlouhodobé přetěžování členů týmu vede k poklesu produktivity práce. Pochopení problému se nejlépe dosáhne pomocí přímé komunikace, nikoliv studiem dokumentace. [2, s ; 5, s ] 3.2 Výběr metodik pro porovnání Metodika RUP zástupce rigorózního vývoje Mezi nejznámější zástupce rigorózních metodik patří vodopádový a spirálový životní cyklus, metodika UP (Unified Process), RUP (Rational Unified Process), EUP (Enterprise Unified Process). Metodika RUP vychází z metodiky UP, jedná se vlastně o její nejrozšířenější a nejúspěšnější variantu. Princip metodik je podobný, rozdíly spočívají v hloubce propracování a v detailech. Zatímco UP je bezplatně dostupná, RUP je komerčním produktem firmy Rational. Metodika UP je otevřený standard, který může použít kdokoliv pro vývoj aplikací. Na rozdíl od metodiky RUP však nepopisuje do hloubky všechny procesy a aktivity, postrádá smysl pro detailní propracování a nemá k dispozici doplňkové nástroje. Metodika EUP zase představuje rozšíření metodiky RUP zejména ve dvou směrech rozšíření na úroveň celé organizace a rozšíření o provoz, údržbu a odstranění produktu z používání. EUP je víceméně doplnění metodiky RUP. [1, s. 56 ; 2, s. 39 ; 5, s ] 22

23 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE Spirálový model představuje sekvenci cyklů. Jedná se o přístup řízený riziky, postup vývoje závisí na opakované a kvalitně provedené analýze rizik a problémů. Vodopádový model definuje sekvenční pojetí jednotlivých fází, to znamená, že nelze provádět více fází najednou, po skončení jedné fáze je zahájena následující. Striktní posloupnost kroků a fází má za následek zpoždění projektu, nedostatečné testování, které není průběžné a neschopnost přizpůsobit nové požadavky během vývoje. Vodopádový model však nedostatečně vystihuje požadavky dnešní doby, proto se podle něj vyvíjí stále méně projektů, a to hlavně z důvodu komplikovanosti, nepružnosti a neschopnosti reagovat na změny. [5, s ; 7, s ] Výběr agilních metodik Při výběru agilních metodik pro vzájemné porovnávání s metodikou RUP bude postupováno podle následujících bodů. Metodiky popsané v dostatečné šíři a rozsahu. Metodiky dostupné v česky vydané literatuře. Metodiky odpovídající požadavkům na specifikaci a zadání projektu. Známější a více používanější zástupce agilního vývoje [5, s. 123] Metodiky zaměřené na problematiku testování. Oblast agilních metodik je velmi rozmanitá, konkrétních zástupců existuje velké množství, proto výčet agilních metodik není zcela jistě úplný. Pro výběr metodik do porovnání byly zvoleny rozšířenější a používanější metodiky a hlavně metodiky, které v dostatečné míře popisují problematiku testování software. Většina z agilních metodik se zaměřuje na jiný problematický aspekt, nedostatek tradičního vývoje, nepopisují komplexně všechny fáze, metody a posloupnost kroků. Některé agilní metodiky jsou zaměřeny procesně, projektově, nástrojově, jiné zdůrazňují technické řešení, další se orientují na lidský faktor. Některé z agilních metodik jsou spíše určeny pro krátkodobý a rychlý vývoj. Jako další hledisko výběru je považováno, že některé z metodik nebyly popsány v plné šíři a v dostatečném rozsahu v české literatuře. Proto jsou v práci uvedeny pouze metodiky dostatečně popsané. Uvedeným bodům nejvíce odpovídají agilní metodika Extrémní programování, Feature-Driven Development a Test-Driven Development. Ostatní metodiky nepopisují 23

24 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE proces testování v uspokojivé míře. Zabývají se především jedním aspektem vývoje, neobsahují dostatečně nadefinované fáze a posloupnost kroků vývoje není rovnoměrná. Z tohoto důvodu nebyly zařazeny metodiky SCRUM a Lean Development do užšího porovnání. Metodiky Crystal, DSDM a ADS jsou vhodnější pro rychlý vývoj hlavně pro internetové aplikace. Při výběru byly hodnoceny i principy dalších agilních metodik. Jejich krátký popis byl zařazen do následujících řádků. Z popisu jsou patrné důvody jejich nezařazení do užšího porovnání. [2, s ] Lean Development vychází z výrobních odvětví, má těsné vazby na podnikovou strategii, definuje pravidla a principy, jejichž dodržování slibuje efektivnější vývoj software. Metodika Scrum je zaměřená na řízení projektu, procesy při vývoji software považuje za empirické. Produktivitu a pružnost vývoje zvyšuje pomocí přístupu k organizaci práce v týmu. Monitoruje iterace (sprinty), vývojové epizody, používá praktiky jako jsou denní porady (Scrum meeting). Metodika DSDM zavádí kategorizaci třídění požadavků na základě priorit a také pojem timebox, čili fixní časový interval pro realizaci požadavků. Základní technikou při realizaci je prototypování. ADS popisuje mezníky, konkrétní body a meziprodukty, je označována za proces vzájemného ovlivňování účastníků vývoje, což je hlavní přínos metodiky. ADS je vhodná pro projekty vyznačující se velkými změnami. Metodika Crystal klade důraz především na lidský faktor projektu. Představuje skupinu metodik se stejnými hodnotami a principy, odlišující se díky použitým technikám a nástrojům. 24

25 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE 3.3 Základní popis zvolených metodik Metodika Rational Unified Process Obr.3.1. Metodika RUP [11] Nejlepší praktiky vývoje metodiky RUP [11] Metodika RUP představuje souhrn šesti základních praktik. Jejich použití má za následek předcházení problémů při vývoji software, zajišťuje efektivnější vývoj, lepší řízení kvality. Nejlepší praktiky vývoje metodiky RUP jsou: [5, s ; 9] Iterativní vývoj Během každé iterace proběhnou v menším nebo větším zastoupení všechny vývojové disciplíny. Iterace spočívá v rozdělení vývoje na části, díky tomu je vývoj software efektivnější, snižuje rizikovost projektu, protože dochází k průběžné detekci rizik. Správa a řízení požadavků požadavky jsou dynamické, mění se v čase. Nedefinuje-li zákazník na začátku projektu všechny požadavky, mohou nové požadavky přicházet i v průběhu vývoje projektu. 25

26 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE Vizuální modelování je vhodné ke komunikaci. Slouží k vizuálnímu zachycení problému, k zpřehlednění návrhu. Pro znázornění vztahu mezi objekty se často používá modelovací jazyk UML (Unified Modelling Language). Použití komponentové architektury RUP nabízí šablony, návrhové vzory a architektonické styly. Znovupoužití hotové komponenty představuje výraznou úsporu zdrojů. RUP hledá efektivní cestu návrhu a vývoje. Průběžné zajišťování a ověřování kvality Pozdní odhalení chyby může způsobit výrazné škody, její odstranění může být nákladné. Pokud je problém odhalen např. v návrhu, na jeho řešení se vynaloží méně úsilí a prostředků než např. při implementaci. Proto je dobré odhalit problém co nejdříve, je to méně nákladnější a méně náročnější na čas. Řízení změn - RUP je připraven na výskyt změn a na jejich správu a integraci do vývojového procesu. Fáze metodiky RUP [2, s ] RUP je organizován podle časového hlediska do čtyř fází. Fáze zahájení (Inception) Přípravná fáze (Elaboration) Konstrukční fáze (Construction) Fáze předání - transitní (Transition) Ve fázi zahájení se stanovuje rozsah projektu, probíhá návrh předběžné architektury vývoje a tvorba postupů, definují se priority. V rámci incepce se zjišťují celkové náklady a nutné zdroje, definují se potencionální rizika, odhaduje se potřebný čas na projekt a probíhá příprava prostředí projektu. Po dohodě se zadavatelem probíhá vymezení, sběr a analýza základních požadavků. [3, s ; 11] V přípravné fázi nebo také ve fázi projektování se definuje ověření návrhu, předvedení a odsouhlasení architektury. Probíhá návrh stabilního modelu architektury daného systému, vytváří se jeden nebo více prototypů. Při odsouhlasení se musí dokázat, že daná architektura je schopná zvládnout požadavky. Během elaborace se vytváří plán pro následující iteraci a částečná analýza rizik. [3, s ; 11] Konstrukční fáze se zaměřuje hlavně na implementaci. Cílem je dokončení návrhu, kompletuje se analýza a design. Provádí se vytvoření, otestování a dodání první funkční verze systému. V rámci realizace probíhá samotný vývoj software, průběžné testování 26

27 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE systému a vyhodnocování kvality. V průběhu konstrukce je evidentní snaha o paralelní vývoj vybraných Use Case (případů užití). Kontroluje se komplexnost systému a náklady na splnění požadavků. [3, s ; 11] Tranzitní fáze znamená předání finální verze systému koncovým uživatelům. Nasazení produktu u zákazníka je spojeno s jeho podporou. Předávání produktu uživatelům zahrnuje dodání produktu i školení uživatelů, podporu a údržbu až do okamžiku spokojenosti uživatele. Kompletní systém je dodáván s dokumentací a manuály. Provádí se beta testování a drobné úpravy v systému, dále instalace, konfigurace a ladění chyb. [3, s ; 11] Obr.3.2. Disciplíny metodiky RUP Disciplíny metodiky RUP [11] Obsah metodiky RUP je organizován do disciplín (Obr.3.2). Metodika RUP popisuje disciplínu jako sadu aktivit se společným zájmem. [2, s ; 3, s ] Tvorba podnikového modelu - pro znázornění podnikových procesů se používá jazyk UML (business modelování), zajištění komunikace se zadavatelem, zjišťujeme jeho požadavky a potřeby. Správa požadavků - systematický přístup ke tvorbě požadavků na systém, definuje se rozsah a objem požadavků. Analýza a návrh propojují požadavky na systém s jeho implementací, členění systému na komponenty. Implementace - převedení návrhu modelu do spustitelné podoby, vývoj systému, vytváření programu. 27

28 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE Testování - průběžné testování a kontrola v každé fázi, cílem testování je ověřit funkčnost systému. Nasazení - zavedení výsledného produktu u klienta do provozu (instalace, konfigurace). Řízení projektu, řízení změn a konfigurace, správa prostředí Cílem metodiky RUP je vytvořit software vysoké kvality bez velkých problémů. RUP definuje kvalitu jako přidanou hodnotu z hlediska zadavatele. Proto má pro ověřování kvality nadefinovanou dimenzi kvality FURPS. Typy testů FURPS by měly zajišťovat kvalitu systému a výrazně snížit výskyt defektů (chyb) hlavně z hlediska funkčnosti, použitelnosti, spolehlivosti, výkonu a podporovatelnosti aplikace. RUP rovněž definuje klíčové body tzv. mezníky (milníky), které slouží pro zhodnocení stavu projektu na konci jednotlivé fáze cyklu. [9 ; 5, s ] Extrémní programování (XP) Základní charakteristika a popis XP XP patří mezi nejrozšířenější metodiku agilního vývoje, přestože její historie je velmi krátká, její vznik se datuje do roku XP představuje relativně účinný, flexibilní a předvídatelný postup vývoje software, využívá velmi rozumný přístup a realistický způsob myšlení, avšak jejich používání dotahuje do extrémů. XP vymezuje určitou šíři, v jejímž rozmezí se pohybuje zadání. Šíře zadání specifikuje množinu funkcí, které zadavatel vyžaduje. Jasně definuje, které funkce jsou pro zákazníka klíčové a které jsou méně důležité. XP vychází primárně z principu jednoduchosti základní funkčnosti, ostatní změny, budou-li potřeba, řeší někdy v budoucnu. Klíčem k úspěchu je zabývat se tím, co je důležité nyní, a nikoliv předpokládanou budoucností, která se pravděpodobně nevyhnutelně změní. [5, s ; 13] Testování je jednou z nejdůležitějších metod pro realizaci zpětné vazby v XP. Až výsledky testování určí, zda-li všechny funkce a moduly projdou anebo se prokáže nutnost oprav a modifikací. Testování v XP probíhá na několika úrovních. Programátoři píší testy pro ověřování aplikační logiky, zákazníci píší testy funkcionality pro jednotlivé moduly. XP deklaruje, že pravděpodobnost úspěšného dokončení projektu je závislá na množství napsaných testů, intenzitě pátrání po chybách a na různorodosti 28

29 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE ověřování zpětné vazby. V případě výskytu problému, nalezení kritické chyby XP zdůrazňuje chybu opravit za každou cenu, i kdyby to znamenalo ztrátu podstatné části zdrojového kódu nebo přepracování celého dosavadního návrhu a architektury. [5, s ; 13] Praktiky a pravidla XP XP dodává nejjednodušší možné verze, které jsou schopné provozu, verze dodává po velmi krátkých iteracích. Architektura (metafora) může být chápána jako abstrakce, která umožní uživateli sjednotit sdílený pohled na systém. Systém je neustále sestavován a integrován, vždy po dokončení nějakého nového úkolu. XP doporučuje dodržování systémové metafory tzn. konzistentní pojmenovávání tříd a metod. Pojmenování objektů je důležité pro porozumění celkového návrhu a znovupoužitelnost kódu. [5, s ] Pro kontrolu zdrojového kódu je využívána technika párového programování. Kód je psán dvěma programátory u jednoho počítače. Úprava zdrojového kódu bez změny jeho funkčnosti se provádí pomocí techniky refaktorování. Refaktorování výrazně zlepšuje čitelnost kódu, odstraní duplicity, usnadňuje budoucí údržbu a rozšiřování systému. Průběžné testování zahrnuje hlavně testování modulů (unit testing), dále testování funkcionality, testování v produkci zákazníkem a v rozsáhlejších projektech i testování integrace. [5, s ] Všechny informace jsou uchovány ve formě zdrojového kódu, XP nepodporuje žádné dokumentace, naopak podporuje standardy pro psaní zdrojového kódu. Kódování je totiž první činnost v počátečních stádiích vývoje, proto je nutná čitelnost, strukturovanost a srozumitelnost kódu. Pro XP je charakteristické společné vlastnictví kódu, kdy každé části rozumí jeden expert. [5, s ] Životní cyklus projektu vyvíjeného pomocí XP: XP nedefinuje posloupnost fází projektu, ale zvláštní postup určený k plánování projektu, k rozhodování o náplni iterací a vývojových fází. XP nedodává žádné dokumentace, nepopisuje žádné milníky nebo kontrolní body během celého životního cyklu, protože upřednostňuje přímou komunikaci nad zdrojovým textem. [5, s ] 29

30 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE Základní činnosti XP: Obr.3.3. Základní činnosti XP Testování probíhá před kódováním, nejprve se programuje test modulu, každý modul musí projít automatizovanými testy, poté proběhne integrace modulu. Pomocí automatizovaných testů provádí vývojáři refaktorizaci. Neustálé testování umožňuje snížit čas dodání aplikace. Psaní zdrojového kódu nastane po napsání testů. Po implementaci modulu dojde k nasazení. Návrh představuje strukturu, jak uspořádat logiku v systému. Změna v jedné části systému, nevyžaduje změny v dalších subsystémech. Komunikace zákazníka jako zadavatele a programátora jako řešitele je nutnou podmínkou. [5, s ] Základní činnosti XP: Plánování Specifikace činnosti šíře zadání, hrubý plán, plán verze Návrh refactoring, metafora - znovupoužitelnost kódu, princip jednoduchosti základních funkčností Kódování (psaní zdrojového kódu) Testování párové programování, společné vlastnictví kódu, integrace změn kódu, tvorba kódu pro unit testy, tvorba zdrojového kódu, standardy kódu unit testy, akceptační testy Tab.3.2. Základní činnosti XP 30

31 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE XP se rovněž zaměřuje na práci s lidmi. Význam motivace lidí a složení vývojového týmu je důležitý v případě, že se zjistí nějaký nedostatek nebo chyba a nelze pokračovat dále, napsaný zdrojový kód se musí vyhodit a vývoj se musí vrátit zpět a začít znovu. To, že vývoj XP směřuje zpět, je poměrně častým jevem. XP je postavené na myšlence, že ztráta hotové části kódu není selhání. Pokud současná architektura nevyhovuje, bez otálení se přepracuje i za cenu zahození zdrojového kódu. [5, s ] Mezi výhody vývoje pomocí XP patří široká možnost úprav a přímočarý postup k cíli. Problémy a obtíže jsou při praktické realizaci, hlavně na začátku, kdy si vývojový tým na metodiku teprve zvyká. [5, s ] Feature Driven Development (FDD) Základní charakteristika a popis FDD Metodika FDD klade silný důraz na disciplínu modelování, která se tak stává důležitou složkou celého procesu. Jedná se o vývoj řízený užitnými vlastnostmi, tedy výsledkem funkčnosti, hodnotným pro zákazníka, který lze měřit, popsat a realizovat v rámci iterace. Během iterace se provádí návrh a realizace jednotlivých užitných vlastností. FDD nepřeceňuje význam procesů při vývoji, přesto je podporuje, což je u agilních metodik neobvyklé. [5, s ] FDD se snaží eliminovat množství nejistoty a zmatku při vývoji, zaměřuje se na dodávku kvalitní aplikace, soustředí se tedy na maximalizaci výsledného produktu. Metodika vychází z krátkých iterací. Důležitým znakem FDD je průběžné dodávání mezivýsledků a nových verzí produktu zákazníkovi. Zákazník se tak pomocí průběžné kontroly a hodnocení nových funkčních přírůstků může ujistit, že vývoj postupuje správným směrem. [5, s ] Vývojové fáze v metodice FDD Životní cyklus FDD definuje pět klíčových procesů. Návaznost jednotlivých kroků je následující. [5, s ] 1. vytvoření celkového modelu 2. vytvoření seznamu vlastností 3. plánování 4. návrh 5. implementace 31

32 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE Obr.3.4. Vývojové fáze v metodice FDD [5, s. 183] Vývoj podle metodiky FDD začíná vytvořením globálního modelu. Na začátku se stanoví cíl a zaměření projektu, požadavky na systém a prostředí pro nasazení systému. Jako první krok při objektově orientovaném vývoji se může využít notace UML. Pro modelování objektů z reálného světa se používá vysoká míra abstrakce. Na základě fáze celkového modelu, funkční specifikace nebo případů užití se systém musí úzce vymezit a definovat základní množinu vlastností. Proto se vytvoří podrobný seznam vlastností, kde jsou vlastnosti klasifikovány podle preference a rozdělovány do skupin podle vzájemné souvislosti a logiky. Nikdy nelze vytvořit konečný seznam. [5, s ] Plán pro další vývoj obsahuje neměnné datum ukončení vývoje, ostatní mezníky mohou být posouvány např. datum ukončení pro jednotlivé skupiny vlastností. Plán rovněž stanovuje na základě priorit, v jakém pořadí budou vlastnosti implementovány. Návrh podle vlastností definuje třídy, které danou vlastnost pokrývají. Výběr jedné nebo více konkrétních vlastností z dané skupiny probíhá podle důležitosti a vzájemných závislostí mezi vlastnostmi. Návrh se zaměřuje na tvorbu diagramu posloupnosti a vyladění objektového modelu pro danou vlastnost. Vypracuje se podrobný plán pro implementaci vlastností. [5, s ] Hlavní činnost ve fázi implementace se soustředí na realizaci podle vlastností. Za implementaci třídy je zodpovědný její vlastník. Vlastník vytváří metody a navrhuje testovací případy pro třídu. Proces testování, inspekce napsaného kódu a testování jednotek probíhá v rámci fáze implementace. Po ověření funkčnosti třídy, tzn. po dokončení všech testů včetně testů modelů tzv. unit testů, následuje umístění třídy do systému pro správu tříd (repozitoře tříd). Poté je vlastnost integrována do verze aplikace. Vlastník třídy může být členem více týmů, jejichž složení se průběžně mění. 32

33 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE Předpokládá se existence více týmů vývojářů pracujících paralelně. Otestované, fungující třídy a metody se implementují pro danou vlastnost. Výsledkem je dokončená vlastnost. [5, s ] Ale dokončená vlastnost může způsobit určité změny v celkové architektuře systému, proto je po implementaci možné provést nutné modifikace v první fázi tvorby globálního modelu. Průběh fází probíhá postupně od první do páté fáze, přičemž fáze návrhu a implementace mohou proběhnout několikrát, jsou iterativně opakovány. Poté se celý cyklus fází opakuje od začátku. [5, s ] Hlavní aspekty vývoje FDD Metodika FDD se do určité míry odlišuje od ostatních metodik především tím, že přichází s několika novými principy a přínosy. FDD umožňuje vývoj podle vlastností. Mezi hlavní znaky FDD patří rovněž vlastnictví tříd a sestavení týmu podle vlastností. [5, s ] Test Driven Development Základní charakteristika a popis TDD Při každém procesu vývoje software je fáze testování nezastupitelná, protože testování je jedna z nejdůležitějších složek v oblasti zajišťování kvality. Existuje ale jedna metodika, která proces testování povyšuje nad ostatní kroky při vývoji, metodika, která klade důraz na testování a označila ho za základ celého vývojového procesu. Tuto myšlenku prosazuje Test-Driven Development. Český ekvivalent pro TDD je programování řízené testy. [5, s ] TDD vyžaduje pro každou funkčnost nejprve napsání testu a až poté napsání kódu. Poté co je testovací kód dokončen, následuje programování samotné funkčnosti. Implementujeme přesně takové množství kódu, kolik dokáže projít testem. [5, s. 198] Nikdy méně, ani více. Když je hotový zdrojový kód, který projde testem, nastává fáze úprav, zefektivnění a zjednodušení zdrojového kódu a kódu testu. Úprava zdrojového kódu bez změny funkčnosti se nazývá refaktorizace. [5, s ] První aktivita v rámci TDD je napsání testu. TDD, ale prohlašuje, že je nutné vytvořit takový test, který selže, jinak nelze implementovat funkci. Implementace je dokončena až pokud funkce projde tímto testem. TDD napravuje chyby dokud jsou ještě 33

34 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE aktuální, eliminuje je v místě jejich výskytu, nebo-li předchází jejich vzniku. [5, s ] TDD není příliš procesně zaměřená. Používání TDD vyžaduje velké nároky na lidský přístup a znalosti, ať už na vedení projektu anebo na programátory, neboť vývojáři se musí vypořádat s psaním testů pro kód, který neexistuje. [5, s. 211] Životní cyklus metodiky TDD Obr.3.5. Životní cyklus metodiky TDD Životní cyklus metodiky TDD se skládá ze tří fází, nejprve probíhá testování, pak implementace a nakonec návrh. Tento způsob vývoje software zcela vylučuje fázi hledání chyb, protože chyby jsou odhaleny již při průchodu testovacím scénářem. Metodika TDD představuje netradiční postup ve vývojovém procesu, kdy testování předchází implementaci. Dodržování takovéto posloupnosti kroků má za následek kompletně otestovanou aplikaci podle všech aspektů kvality. [5, s ] Průběžné ověřování probíhá na úrovni programového kódu, kdy vývojáři zjišťují jeho kvalitu a spolehlivost. Nicméně kromě jednotkových (unit) testů musí být provedeny ještě další typy testů, největší důraz TDD klade na testování uživatelského rozhraní pomocí akceptačních testů a testování integrace. Tyto druhy testu nelze provádět v plné míře automaticky pomocí testovacích nástrojů, ale musí být prováděny také manuálně. Pro podporu testování potřebuje metodika TDD použít nějaký podpůrný nástroj. Velmi užívaným je rodina nástrojů xunit např. nástroj JUnit. [5, s ] 34

35 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE TDD se příliš nezabývá formálními záležitostmi jako tvorbou různých specifikací a dokumentací. Testovací případy v přehledné formě mohou doplňovat technické dokumentace nebo se stát součástí funkční specifikace, ale v žádném případě dokumentaci nesmí zastupovat jako kompletní a dostačující řešení. Čím vyšší existuje riziko selhání projektu, tím intenzivnější a důslednější testování musí být. Pokud systém dosáhne 100% pokrytí kódu testovacími případy, každá řádka zdrojového kódu projde testy. [5, s ] Lze proto říci, že výsledky metodiky TDD (pokud jde o otestovanost výsledné aplikace) jsou lepší něž v případě aplikací vyvíjených tradičními metodikami a testovaných tradičními technikami. [5, s. 202] 35

36 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT 4. Výběr vhodné metodiky pro projekt 4.1 Charakteristika projektu Formulace problému Bankovní instituce požaduje vytvoření programového řešení bankovního produktu. Jedná se o vytvoření nové verze účetního systému rozšiřující dosavadní systém o nové funkčnosti. Jeho nejdůležitější inovací v nové verzi bude účtování on-line. Základním cílem je implementace změnových požadavků a nových funkčností do stávající, již zavedené verze systému. Úkolem je vytvoření funkční aplikace zprostředkující zpracování účtování jak během účetního dne tak během účetní uzávěrky. Programové řešení nové verze musí splňovat funkční požadavky: V rámci zpracování účtování během účetní uzávěrky: kapitalizace úroků účtování automatických převodů rušení a zakládání účtů aktualizace databázových tabulek a registrů a zálohování stavu účetního dne V rámci zpracování účtování během účetního dne: obraty platebního styku finanční transakce mezi účty vedenými v jiných bankách a v pobočkách transakce on-line účtování trvalé příkazy Po vyhotovení programového řešení nové verze bankovního produktu požaduje zadavatel rovněž zajištění kvality softwarového řešení jeho otestováním. Pro ověření kvality softwarového produktu jsou nastaveny akceptační kritéria pro počet defektů a jejich severitu. Testování bude ověřovat funkčnost softwarového produktu podle návrhu a správnost implementace požadavků. Případné defekty v kvalitě softwaru budou zdokumentovány. 36

37 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT Podle výsledků výběrového řízení na základě rozhodnutí managementu byla zakázka přidělena externí softwarové firmě. Softwarová firma bude zajišťovat služby pro bankovní instituci formou team-leasingového projektu. Management softwarové firmy je postaven před problém, kdy se musí rozhodnout na základě porovnání pro vhodnou metodiku vývoje software. K dispozici má čtyři metodiky a šest kritérií, podle kterých se bude rozhodovat pro jednu z metodik. Pro výběr použije optimalizační metodu minimalizace vzdálenosti od ideální alternativy, metodu TOPSIS (Technique for order preference by similarity ideal solution) Vymezení problému Bankovní instituce jako zadavatel definovala softwarové firmě jako řešiteli následující požadavky na vývoj řešení softwarového produktu. Pro implementaci systému zadavatel preferuje objektově-orientovaný vývoj. Požadavky na funkcionalitu jsou primární. Jakékoliv změny funkcionality zjištěné během vývoje je možno zapracovat, některé méně prioritní změnové požadavky se mohou vyřešit v další verzi. Dodávka do produkce je plánována na přesně stanovený termín. Zadavatel povoluje možnost posunutí termínu dokončení projektu a jeho nasazení na produkci, ale jen v případě potíží při implementaci primárních změnových požadavků. Náklady na projekt jsou vyčleněny ve stanoveném rozmezí, počítá se s finanční rezervou nepřesahující 10% nákladů na projekt. Velikost projektového týmu je stanovena, rozšíření nebo doplnění týmu se nepředpokládá, ani pokud nastanou problémy při vývojovém procesu. Pro případ dalšího rozšíření systému je nutná přehledná dokumentace. Na další verzi systému může pracovat jiná firma, proto zadavatel požaduje dokumentaci. Zadavatel požaduje po řešiteli otestovat výslednou aplikaci. Testování by mělo zajišťovat kvalitu systému. Kvalitu aplikace zadavatel po řešiteli požaduje v následujícím rozsahu. Aplikace musí splňovat v první řadě zajištění funkčnosti, použitelnosti a spolehlivosti, dále stabilitu a výkon. Zároveň aplikace musí mít jednoduché uživatelské rozhraní na ovládání a grafickou podporu komponent. V neposlední řadě aplikace musí pokrývat potencionální rozšiřitelnost a flexibilitu systému, a také kompatibilitu (slučitelnost) verzí. Cílem zadavatele je získat aplikaci, která bude odpovídat funkčním požadavkům ve specifikaci. Bude dodána ve stanovený termín a s přesně vymezenými náklady. 37

38 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT 4.2 Stanovení kritérií pro porovnání Kritéria klasifikace metodik Asi nejzávažnější překážkou při vyhledávání vhodné metodiky pro určitý projekt je neexistence jednotné klasifikace metodik, která by definovala způsob porovnání a následného výběru. Tento nedostatek má příčinu v různorodosti jednotlivých projektů. Projekty se mohou lišit např. velikostí týmu, znalostmi a schopnostmi jedinců v rámci týmu, postavením na trhu, dále podle využití produktu, nebo doméně projektu, jinými slovy pro jaký účel je software vyvíjen. Protože každý projekt je jedinečný, vyžaduje použití různé metodiky. Právě zmíněné odlišnosti, jsou příčinnou pro využití různých metodik podle požadavků na projekt. [2, s. 19] Pro porovnání metodik pro vývoj software pomocí optimalizační metodiky TOPSIS jsou zde využita některá kritéria klasifikace metodik a jejich hodnoty, tak jak je vymezila Alena Buchalcevová v knize s názvem Metodiky vývoje a údržby informačních systémů. Z této práce bylo pro třídění metodik využito kritérium typ řešení [2, s. 28] a přístup k řešení [2, s. 28] a do jisté míry i kritérium váha metodiky [2, s. 28], které bylo přetransformováno do podoby míra složitosti. V rámci této bakalářské práce byla stanovena další kritéria se zaměřením na proces testování. [2, s ; 2, s. 27] Doména vyvíjeného software vymezuje určitou oblast zaměření, účel nebo předmět využití software a zároveň představuje určitou skupinu podnikových procesů. Kritérium doména nebylo zařazeno do porovnání hlavně z důvodu jasného využití software definovaného ve formulaci problému (viz kapitola 4.1.1) a také z důvodu obecné použitelnosti metodik pro různé druhy vyvíjeného software. Metodiky zařazené do konečné fáze porovnání, jsou všeobecně aplikovatelné pro různé typy informačních systémů, čili jen těžce by se mezi nimi stanovovaly rozdíly a odlišnosti. Doménou vyvíjeného software může být např. plánování podnikových zdrojů (ERP), manažerské informační systémy (MIS). [2, s ] 38

39 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT Popis kritérií pro porovnání metodik Pro každé kritérium je připojen krátký popis, kde je charakterizován jeho význam a přiblíženy hodnoty kritéria. Seznam kritérií a jejich hodnoty jsou uvedeny v tabulce (Tab.4.1). Kritérium číslo 1: Typ řešení Při vývoji software se nemusí vždy jednat o vývoj nového řešení od začátku, ale může se provádět např. rozšíření, integrace stávajícího informačního systému anebo jen inovace funkčnosti zavedeného. [2, s. 24] Kritérium číslo 2: Přístup k řešení [2, s. 27] Využívá se hlavně při vývoji nového anebo při rozšíření stávajícího systému. Jeho význam klade důraz na hlavní fáze vývoje analýzu, návrh a implementaci. Přístupy se často kombinují tzn. přístup k řešení je jiný ve fázi analýzy a jiný ve fázi implementace. Hodnoty kritéria přístup k řešení jsou: Objektově-orientovaný pomocí objektů a tříd, využívá dědičnost, polymorfismus a zapouzdření Strukturovaný volání funkcí a procedur RAD (Rapid application development) rychlý vývoj aplikací Kritérium číslo 3: Míra složitosti metodiky Zahrnuje počet, návaznost, rozsah a hloubku fází vývojového procesu. Hodnotí míru podrobnosti, definuje propracovanost a obsáhlost, stanovuje počet kontrolních prvků, jejich propojenost a také velikost týmu. [2, s ] Kritérium číslo 4: Zaměření testování (typ testů) Popisuje na jaké typy a fáze testů (viz kapitola 5.2) se metodika zaměřuje. Jaké typy testů má metodika nadefinované, obsáhlé a které podporuje. Která metodika je nejlépe popsaná z hlediska testování? Kritérium číslo 5: Rozsah (a hloubka) testování Toto kritérium pomáhá nalézt odpověď na otázku, v jaké fázi vývoje se začíná testovat? 39

40 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT Kritérium číslo 6: Zaměření metodiky na fázi vývoje Každá metodika se do jisté míry vymezuje oproti ostatním. Přichází s nějakou novinkou, věnuje pozornost určitému aspektu vývojového cyklu. Toto kritérium popisuje na jakou fázi popř. fáze klade metodika největší důraz. Kritérium Vymezení Hodnota / významu kritéria 1. Typ řešení [2, s. 28] a) nové řešení, b) rozšíření stávajícího, c) integrace řešení, d) inovace [2, s. 28] 2. Přístup k řešení [2, s. 28] a) objektově-orientovaný, b) strukturovaný, c) RAD rychlý vývoj aplikací [2, s. 28] 3. Míra složitosti metodiky (propracovanost, obsáhlost) a) velmi náročná na složitost b) složitá metodika b) střední náročnost c) jednoduchá metodika [2, s ] 4. Zaměření testování (typ testů) a) Základní typy testů: white box a black box b) Fáze testu: unit testy, testy integrace, smoke testy funkční testování, uživatelsko akceptační testy c) ostatní typy testů 5. Rozsah (a hloubka) testování a) testování na začátku vývoje (v počáteční fázi) před implementací b) průběžné testování v každé fázi po každé iteraci během celého vývoje c) testování na konci vývoje před implementací d) testování na konci vývoje v rámci fáze implementace 6. Zaměření metodiky na fázi vývoje a) vyzdvihuje (klade důraz na) jednotlivou fázi : požadavky, návrh, implementace, testování atd. b) rovnoměrné rozložení fází Tab.4.1. Seznam kritérií a jejich hodnot 40

41 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT 4.3 Metodiky podle stanovených kritérií V následující tabulkové části je zpracován základní popis metodik podle stanovených kritérií. Pro jednotlivé metodiky byla každému kritériu porovnání přiřazena hodnota kritéria a číselné ohodnocení kritéria podle formulace zadání a vymezení projektu. Každá tabulka obsahuje kritérium, jeho hodnotu, která co nejvíce vystihuje metodiku, a číselné hodnocení jednotlivých kritérií pro uvedené metodiky vývoje. Jednotlivé metodiky byly vzájemně porovnány na základě kritérií. Každá metodika byla číselně ohodnocena podle požadavků na projekt. Jednotlivá kritéria jsou ohodnocena podle hodnotící stupnice od 1 do 10. Minimální hodnota 1 znamená, že metodika nevyhovuje požadavkům na projekt. Maximální hodnota 10 znamená, že metodika nejlépe vyhovuje požadavkům na projekt. RUP - Rational Unified Process Kritérium Hodnota kritéria Hodnocení 1. Typ řešení spíše nové řešení (rozšíření zavedeného) 4 2. Přístup k řešení objektově-orientovaná ve všech fázích 7 3. Míra složitosti metodiky velmi náročná na složitost 8 4. Zaměření testování (typ testů) black box testy, funkční testování, definuje FURPS 5. Rozsah (a hloubka) testování průběžné testování v každé fázi (po každé iteraci během celého vývoje) Zaměření metodiky na fázi vývoje rovnoměrné rozložení fází 8 Tab.4.2. Hodnoty kritérií a jejich hodnocení metodiky RUP 41

42 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT XP Extrémní programování Kritérium Hodnota kritéria Hodnocení 1. Typ řešení rozšíření stávajícího, integrace zavedeného 6 2. Přístup k řešení strukturovaný, RAD 3 3. Míra složitosti metodiky jednoduchá metodika 3 4. Zaměření testování (typ testů) White box testování, unit testy, testy integrace, UAT (viz kapitola 5.2) 6 5. Rozsah (a hloubka) testování testování na konci vývoje před implementací 6 6. Zaměření metodiky na fázi vývoje Kódování (implementace) 6 Tab.4.3. Hodnoty kritérií a jejich hodnocení metodiky XP FDD Feature-Driven Development (vlastnostmi řízený vývoj) Kritérium Hodnota kritéria Hodnocení 1. Typ řešení nové řešení 4 2. Přístup k řešení objektově-orientovaná ve všech fázích 8 3. Míra složitosti metodiky střední náročnost 6 4. Zaměření testování (typ testů) nedefinováno 3 5. Rozsah (a hloubka) testování testování na konci vývoje v rámci fáze implementace 4 6. Zaměření metodiky na fázi vývoje Požadavky seznam vlastností 5 Tab.4.4. Hodnoty kritérií a jejich hodnocení metodiky FDD 42

43 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT TDD Test-Driven Development (testy řízený vývoj) Kritérium Hodnota kritéria Hodnocení 1. Typ řešení rozšíření stávajícího, integrace zavedeného 6 2. Přístup k řešení strukturovaný, RAD 3 3. Míra složitosti metodiky jednoduchá metodika 3 4. Zaměření testování (typ testů) white box testování, unit testy, testy integrace (viz kapitola 5.2) 5. Rozsah (a hloubka) testování na začátku vývoje v počáteční fázi před implementací Zaměření metodiky na fázi vývoje testování 9 Tab.4.5. Hodnoty kritérií a jejich hodnocení metodiky TDD 4.4 Analýza číselného hodnocení kritérií V následující kapitole byla provedena interpretace tabulkové části. Provedená analýza vyjadřuje porovnání metodik podle kritérií. Hlavním cílem je vysvětlení a zdůvodnění číselného vyjádření hodnot kritérií pro každou metodiku podle zadání projektu. Kritérium typ řešení Pro toto kritérium je nejvíce žádoucí metodika rozšiřující stávající systém o nové funkčnosti popř. o implementaci změnových požadavků již zavedených funkčností. Toto kritérium podle požadavků na projekt nejlépe splňují metodiky TDD a XP, proto byly číselně ohodnoceny jako lépe vyhovující pro realizaci projektu. Metodiky RUP a FDD byly spíše navrhnuty pro vývoj nového řešení informačního systému, nikoliv pro jeho změny či inovace. 43

44 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT Kritérium přístup k řešení V rámci definování požadavků na vývoj řešení softwarového produktu zadavatel požaduje objektově-orientovaný vývoj. Požadavkům pro toto kritérium nejvíce vyhovují metodiky RUP a FDD, které využívají právě objektově orientovaný vývoj. Zatímco metodika RUP využívá objektově orientovaný vývoj ve fázi analýzy a řízení požadavků, metodika FDD ve fázi tvorby modelu. Pro vizuální modelování objektů z reálného světa se využívá vysoká míra abstrakce a notace UML. Metodiky XP a TDD využívají strukturovaný vývoj, který je založený na volání procedur a funkcí. V rámci tohoto vývoje se uplatňuje technika pro úpravu kódu založená na odstranění duplicit a zavedení standardů pro čitelnost a strukturovanost zdrojového kódu. Pro tento vývoj je charakteristická znovupoužitelnost kódu. Metodiky XP a TDD jsou podle požadavků na projekt nevyhovující. Kritérium míra složitosti metodiky Přestože v případě metodiky XP činí ztráta části napsaného zdrojového kódu nebo přepracování návrhu architektury vývoj výrazně složitý, jedná se stejně jako v případě TDD o velmi jednoduchou metodiku. TDD není příliš zatížená procesy, ale je náročnější na znalosti a lidský faktor. Změny v návrhu dokončené vlastnosti, podle které je řízen vývoj metodiky FDD, má za následek opakování průběhu některých fází vývoje. Z hlediska návaznosti fází je pak FDD klasifikována jako středně pokročilá. Z hlediska hloubky a rozsahu je velmi náročná na složitost metodika RUP. Lze ji označit za nejpropracovanější a nejobsáhlejší z uvedených metodik. Složení a velikost týmu je totiž definována rolemi. Obsah metodiky RUP je uspořádán do disciplín. Pro efektivnější vývoj software se využívá šesti základních praktik vývoje. Metodika RUP je klasifikována jako nejsložitější a označena nejvyšší číselnou hodnotou. Pro zadání projektu je však žádoucí jednoduchá metodika. Z tohoto důvodu má optimalizační metoda TOPSIS toto kritérium nastaveno jako minimalizační. Kritérium zaměření testování Základní rozdíl je v přístupu k testování. Zatímco metodika RUP je založena na black box testování, metodiky TDD a XP provádějí white box testování. V rámci zajišťování kvality produktu metodiky TDD a XP provádějí testy jednotlivých modulů (unit testy), akceptační testy uživatelského rozhraní, testy integrity a funkcionality. Metodika RUP má nadefinovanou bohatou sadu testů FURPS vyjadřující jednotlivé 44

45 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT aspekty kvality: funkcionalitu, použitelnost, spolehlivost, výkon a podporovatelnost. Pro otestování každého aspektu kvality je k dispozici několik typů testů. Z uvedeného vyplývá, že metodika RUP je z hlediska rozsahu typů testů nejvhodnější pro otestování aplikace navrhované pro projekt. Kritérium rozsah testování Toto kritérium je zaměřeno na fázi vývoje, přesněji na okamžik, kdy se aplikace začíná testovat. Metodika RUP definuje průběžné testování nejen v každé fázi vývoje, ale i během každé iterace. Proces testování je tedy do jisté míry zastoupen v každé iteraci. Metodika TDD klade velký důraz na testování do takové míry, že ho pokládá za základ celého vývoje, nicméně se mu nevěnuje po celý jeho průběh, ale pouze na jeho začátku. Testování v rámci TDD probíhá na začátku vývoje před implementací, nejprve probíhá napsání testu a až poté napsání kódu. Metodika XP stanovuje testování na konec vývoje před fázi implementace. Nejdříve probíhá vytváření testů, následně samotné testování a až poté dochází k psaní zdrojového kódu. Metodika FDD stanovuje proces testování pouze v rámci fáze implementace a až na konci celého vývoje. Z tohoto důvodu je pro zadání projektu v porovnání s ostatními metodikami nejméně vyhovující. Hodnocení kvality softwarového produktu je primárně založeno na nedokončenosti, protože nelze vždy otestovat všechny aspekty software. Na testování klade zadavatel projektu velký důraz hlavně z hlediska funkčnosti produktu, proto je žádoucí, aby testování bylo zastoupené v každé fázi vývoje. Tento požadavek nejlépe splňuje metodika RUP. Kritérium zaměření metodiky na fázi vývoje Zatímco metodika RUP definuje rovnoměrné rozložení všech fází, ostatní porovnávané metodiky se vždy více zaměřují na jeden aspekt vývoje a vyzdvihují jednu fázi vývoje nad ostatní. Metodika FDD se zabývá procesem modelování a zpracování vlastností, podle kterých je řízen vývoj. Metodika XP staví tvorbu zdrojového kódu nad ostatní fáze při vývojovém procesu. Metodika TDD vyzdvihuje disciplínu testování nad ostatní kroky a považuje ji za základ vývoje software. Vzhledem k požadavkům na zadání tomuto kritériu nejlépe vyhovují metodiky RUP a TDD. 45

46 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT 4.5 Stanovení vah pro kritéria Pro jednotlivá kritéria 1 až 6 jsou stanoveny následující váhy (Tab.4.6). Kritéria popisující testování byla nastavena na vyšší číselnou hodnotu. Kritérium Váha 0,06 0,12 0,10 0,28 0,24 0,20 Tab.4.6. Stanovení vah pro kritéria Vyčíslení jednotlivých kritérií pro uvedené metodiky vývoje ukazuje tabulka (Tab.4.7). Kritérium míra složitosti je vymezeno jako minimalizační z důvodu zadání projektu. Kritérium max max min max max max RUP XP FDD TDD Tab.4.7. Kriteriální matice metody TOPSIS Na základě číselného ohodnocení jednotlivých kritérií a stanovených vah pro každé kritérium bude provedena optimalizační metoda TOPSIS. Podle výsledků metody TOPSIS bude rozhodnuto pro výběr jedné metodiky. Nejvhodnější metodika bude navržena pro realizaci softwaru. 46

47 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT 4.6 Výběr vhodné metodiky podle optimalizační metody Řešení problému pomocí metody TOPSIS [4, s ] Všechny výpočty optimalizační metody TOPSIS jsou uvedeny v příloze (viz kapitola 7.4). Teoretický postup řešení problému pomocí manažerské metody rozhodování TOPSIS je rozdělen do šesti kroků. 1. krok: Stanovení kriteriální matice Y=(y i j ) Nejprve upravíme kriteriální matici (Tab.7.1) na tvar, kdy všechna kritéria budou maximalizační. Pro minimalizační kritéria určíme nejhorší maximální hodnoty. Uděláme rozdíl mezi maximálními (nejhoršími) hodnotami a hodnotami kriteriální matice. Od maximální hodnoty každého minimalizačního kritéria odečteme hodnoty kritéria pro danou alternativu. 2. krok: Získaná upravená matice (Tab.7.2) Všechna kritéria jsou zde již maximalizační. Tabulka (Tab.7.3) ukazuje rovněž upravenou matici, která slouží jako mezivýpočet pro získání normalizované kriteriální matice. Obsahuje hodnoty předchozí upravené matice umocněné na druhou y 2 i j, dále jejich sumu (součet) y 2 i j a následně odmocninu y 2 i j. 3. krok: Vytvořená normalizovaná kriteriální matice R (Tab.7.4) R i j podle vztahu : R i j = y i j / y 2 i j 4. krok: Vytvořená vážená kriteriální matice W (Tab.7.5) Každý sloupec matice R se vynásobí odpovídající vahou ve formě řádkového vektoru vah. Kriteriální váhy byly stanoveny managementem firmy. v 1 r 11 v 2 r v 1 r 21 v 2 r W =.... Obr.4.1. Vážená kriteriální matice 47

48 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT Vytvoříme řádkové vektory pro obě alternativy jak bazální D, tak ideální H. Řádkový vektor H obsahuje maximální hodnoty pro každé kritérium f1 až f6 vážené kriteriální matice W a analogicky vektor D obsahuje minimální hodnoty. 5. krok: Výpočet vzdáleností variant od ideální alternativy (Tab.7.6) a (Tab.7.7) Provede se výpočet podle vztahu pro všechna i: d i + = j (w i j - H j ) 2 d i - = j (w i j - D j ) 2 6. krok: Relativní ukazatel vzdálenosti (Tab.7.8) Vypočte se relativní ukazatel vzdálenosti alternativ od bazální alternativy podle vztahu pro všechna i, čili pro všechny alternativy. c i = d - + i / (d i + d - i ) Varianty se uspořádají podle klesajících hodnot c i. Jako nejlepší se vybere ta alternativa, která se umístila na prvním místě (má největší hodnotu c i ). 4.7 Návrh vhodné metodiky pro projekt Největší hodnotu relativního ukazatele vzdálenosti (Tab.7.9) má metodika RUP. Podle výsledků optimalizační metody TOPSIS vyplývá, že nejvhodnější metodikou pro řízení modelového softwarového projektu je metodika RUP. Výsledek porovnání metodik pomocí optimalizační metody TOPSIS výrazně závisí na volbě kritérií a stanovení vah pro jednotlivá kritéria. Porovnání metodik bylo zaměřené na problematiku testování, z toho důvodu byly přiděleny vyšší hodnoty vahám, které se nejvíce zabývají testováním. 48

49 5. TESTOVACÍ STRATEGIE 5. Testovací strategie Testovaní je nejdůležitější proces zajišťování kvality software. Proto je důležité tento proces organizovat, plánovat a řídit. Tento úkol se snaží vyřešit testovací strategie. Strategie testování stanovuje postup, podle kterého bude testovací tým provádět ověřování a kontrolu funkčnosti software. Popisuje časový plán testů, definuje sledování výsledků testování z hlediska chybovosti a rovněž vymezuje rizikové oblasti testování. Na základě výsledků optimalizační metody je testovací strategie určena metodice RUP. 5.1 Testovací cyklus Cyklus testování metodiky RUP je založen na iterativním vývoji. V následující tabulce (Tab.5.1) je stručně popsáno jaké činnosti probíhají a jaké dokumenty jsou vytvářeny v jednotlivých fázích testovacího cyklu. Fáze testovacího cyklu (kompetentní role) Plánování testů (Test manager) Návrh testů (Test architect) Vytváření testů (Test designer & tester ) Vykonávání testů (Tester) Vyhodnocení testů (Test manager) Sledování defektů Činnosti Definice testovacího rozsahu Plánování zdrojů a cílů testování Identifikace rizik Definice typů testů Příprava manuálních a automatizovaných testů Definice testovacích dat Zhodnocení testů Dokumenty Rozsah testů (Test scope) Testovací plán Testovací požadavky Strategie testů Definice prostředí Testovací případy Testovací scénáře Test report Testovací výsledky Seznamy chyb Závěrečné shrnutí Test protokol Defect report Tab.5.1. Fáze testovacího cyklu [10] 49

50 5. TESTOVACÍ STRATEGIE Z hlediska role mohou disciplínu testování provádět tester, test designer, test architect, a test manager. Následující obrázek (obr.5.1) ukazuje jaké aktivity má daná role vykonávat a za jaké dokumenty je jednotlivá role zodpovědná. Obr.5.1. Testovací cyklus [10] 50

51 5. TESTOVACÍ STRATEGIE Testovací cyklus představuje posloupnost činností, které na sebe navazují a do jisté míry se vzájemně překrývají a doplňují. Výstupy z jedné fáze představují přímé vstupy do následující fáze. Posloupnost jednotlivých kroků testování je vysvětlena pomocí životního cyklu testování. Pro každou fázi životního cyklu je uveden její popis pro přiblížení činností a postupů, které se v ní odehrávají. 1) Plánování testů V první fázi testovacího cyklu probíhá definice projektu, vymezuje se testovací plán, stanovují se testovací požadavky. Výsledkem je pak definování rozsahu testů, který specifikuje činnosti testování. Testovací plán popisuje proces dosažení cílů, soustředí se na rozsah a zaměření testů, zahrnuje časový rozvrh jednotlivých aktivit a termíny dodávek. Testovací požadavky přibližují chování testované aplikace a potřebné testovací zdroje. Testovací požadavky popisují návrh uživatelského rozhraní, průběh konfigurace a instalace, specifikují potřebný výkon aplikace, hraniční podmínky, neboli objem testování. [7, s ; 10] 2) Návrh testů Ve fázi návrhu dochází k upřesnění cílů a milníků testování, je nadefinováno testovací prostředí. Výsledkem návrhu je strategie testů, která upřesňuje sadu požadavků na chování a přesně stanovuje jaké typy testů budou prováděny. V rámci strategie testů se rovněž stanovují testovací techniky, nástroje a kritéria pro dokončení testů. Konečná verze strategie testů musí být následně schválena zákazníkem. [7, s ; 10] 3) Vytváření testů [7, s ; 10] V této etapě testovacího cyklu je proveden detailní popis jednotlivých testovacích případů a skriptů, je definována struktura testovacích dat. Výsledkem jsou testovací scénáře, podle kterých probíhá testování. S popisy testovacích scénářů je průběžně seznamován zákazník. V případě, že testovací plán zahrnuje použití automatizovaných testů, pak jsou v této fázi připravovány procedury a skripty pro automatizované provádění testů. Fáze návrh testů a vytváření testů lze pojmenovat jednotně jako příprava testů. 51

52 5. TESTOVACÍ STRATEGIE Testovací případ (test case) je seznam kroků vycházející z konkrétních funkčností, které se musí vykonat. Testovací data jsou konkrétní data potřebná pro provádění testů. (např. uživatelské účty, data pro zadávání do systému, připravené xml zprávy atd.) Testovací skript (test script) Testovací script se skládá z konkrétních testovacích případů, testovacích dat a jasně definovaného očekávaného výsledku testování. Testovací scénář (Test suit) je komplexní test napříč systémem. Obsahuje sadu testovacích skriptů, které jsou definované v přesném pořadí. Testovací scénář ověřuje průchod systémem. Obr.5.2. Testovací scénář 4) Vykonávání testů Během etapy vykonávání testů jsou prováděny testy podle předem připravených testovacích scénářů, testy jsou vykonávány průběžně v každé iteraci. Výsledky testů jsou zaznamenávány ve formě dokumentů - defekt report a záznam o provedení testů. [7, s ; 10] 5) Vyhodnocení testů Během vyhodnocování testů dochází k analýze výsledků testů a určení, zda byly splněny testovací požadavky a kritéria definovaná během plánování. Každé vykonání testů je vyhodnocováno, jsou popsány nalezené defekty ve formě hlášení problému. Na konci testů se provádí závěrečné shrnutí. Závěrečná zpráva o výsledcích testování obsahuje stručné zhodnocení testů a vyhodnocení výsledků testování. Za vyhodnocení testů je odpovědný test manager. Výstupem je testovací protokol, který přesně popisuje průběh testů, seznam otestovaných funkčností, výsledky testů doplňuje o seznam nalezených chyb. [7, s ; 10] 52

X36SIN: Softwarové inženýrství. Životní cyklus a plánování

X36SIN: Softwarové inženýrství. Životní cyklus a plánování X36SIN: Softwarové inženýrství Životní cyklus a plánování 1 Kontext Minule jsme si řekli, co to je deklarace záměru, odborný článek, katalog požadavků, seznam aktérů a seznam událostí. Seznam aktérů a

Více

TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE

TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE Tel. +420 543426329 TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE Autor: Vít Chvál Verze dokumentu: 1.0 Datum poslední změny: 18.2.2013 Obsah: 1 Pracovník 3 2 Pracovní činnosti (Náplň práce)

Více

End-to-end testování. 26. dubna Bořek Zelinka

End-to-end testování. 26. dubna Bořek Zelinka End-to-end testování 26. dubna 2013 Bořek Zelinka Bořek Zelinka Unicorn Systems, Test architekt Unicorn, 2004 Testování Quality Assurance ČVUT, Fakulta stavební, 2004 2 Agenda Princip end-to-end testů

Více

Ročníkový projekt. Jaroslav Žáček jaroslav.zacek@osu.cz

Ročníkový projekt. Jaroslav Žáček jaroslav.zacek@osu.cz Ročníkový projekt Jaroslav Žáček jaroslav.zacek@osu.cz Cíle předmětů Vytvoření fungující aplikace, která splňuje definované požadavky Vyzkoušet si celý životní cyklus projektu - specifikace zadání, formování

Více

Agile Software Development

Agile Software Development Agile Software Development Agile Software Development Jiri Fabian www.jirifabian.net O čem to bude O metodologiích RUP Agile XP Scrum Co je softwarový vývoj Umění? Manufaktura? Modelování? Co je softwarový

Více

PŘÍLOHA C Požadavky na Dokumentaci

PŘÍLOHA C Požadavky na Dokumentaci PŘÍLOHA C Požadavky na Dokumentaci Příloha C Požadavky na Dokumentaci Stránka 1 z 5 1. Obecné požadavky Dodavatel dokumentaci zpracuje a bude dokumentaci v celém rozsahu průběžně aktualizovat při každé

Více

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Osnova přednášky Co to je softwarové inženýrství Softwarový proces Metodika a metoda Evoluce softwarových

Více

Zuzana Šochová 30.10.2008. MFF Modelování a realizace softwarových projektů

Zuzana Šochová 30.10.2008. MFF Modelování a realizace softwarových projektů Zuzana Šochová 30.10.2008 1 Metody řízení projektů Týmová spolupráce Agilní metody Scrum proces Backlog úloh a odhady Jak plánovat Tým a zákazník 2 Executive support User involvement Experienced project

Více

XINF1. Jaroslav Žáček jaroslav.zacek@osu.cz

XINF1. Jaroslav Žáček jaroslav.zacek@osu.cz XINF1 Jaroslav Žáček jaroslav.zacek@osu.cz Tutoriály 24.10. - 3h 6.11. - 2,2h 27.11. - 1,5h Tutoriály budeme věnovat nejen teorii, ale také cvičení a workshopům. Přečtěte si skripta dříve, než týden před

Více

Řízení reálných projektů, agilní metodiky

Řízení reálných projektů, agilní metodiky Agent Technology Group Katedra kybernetiky Fakulta elektrotechnická - České vysoké učení technické Praha, 2009 Osnova Lze vyvíjet software bez metodiky? - bohužel ano menší komerční firmy (zejména vývoj

Více

Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT)

Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT) Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT) Charta projektu má za cíl poskytnout úplné a pevné informační základy pro schválení projektu. Následně je Charta projektu rozpracována do

Více

Management. Ing. Jan Pivoňka

Management. Ing. Jan Pivoňka Management Ing. Jan Pivoňka Stanovení osobní vize V souladu s kotvou Konkrétní představa Citový náboj Stimul pro aktivní jednání Krátkodobější cíle motivace Výjimky Jasná vize Pohodoví lidé Úspěch bez

Více

Jednotný NIS Prezentace k zahájení projektu pro Radu kraje Vysočina. Projektový manažer - Ing. Ivan Sokolov, Ph.D.

Jednotný NIS Prezentace k zahájení projektu pro Radu kraje Vysočina. Projektový manažer - Ing. Ivan Sokolov, Ph.D. Prezentace k zahájení projektu pro Radu kraje Vysočina Projektový manažer - Ing. Ivan Sokolov, Ph.D. Obsah Úvod Cíle projektu Rozsah projektu Projektové řízení základní východiska Základní organizační

Více

S T R A T E G I C K Ý M A N A G E M E N T

S T R A T E G I C K Ý M A N A G E M E N T S T R A T E G I C K Ý M A N A G E M E N T 3 LS, akad.rok 2014/2015 Strategický management - VŽ 1 Proces strategického managementu LS, akad.rok 2014/2015 Strategický management - VŽ 2 Strategický management

Více

WORKFLOW. Procesní přístup. Základ perspektivního úspěšného podnikového řízení. Funkčnířízení založené na dělbě práce

WORKFLOW. Procesní přístup. Základ perspektivního úspěšného podnikového řízení. Funkčnířízení založené na dělbě práce WORKFLOW Procesní přístup Základ perspektivního úspěšného podnikového řízení Funkčnířízení založené na dělbě práce Procesní řízení princip integrace činností do ucelených procesů 1 Funkční řízení Dělba

Více

Základy analýzy. autor. Jan Novotný http://blog.novoj.net/ 15. února 2007

Základy analýzy. autor. Jan Novotný http://blog.novoj.net/ 15. února 2007 Základy analýzy autor Jan Novotný http://blog.novoj.net/ 15. února 2007 V prezentaci jsou použity diagramy z: Wikipedia, Sparx UML Tutorial, Argo UML Metodiky vývoje Různé metodiky vývoje vazba na fáze

Více

SOFTWAROVÉ INŽENÝRSTVÍ 1

SOFTWAROVÉ INŽENÝRSTVÍ 1 Metodický list č. 1 Název tématického celku: Úvod do softwarového inženýrství Základním cílem tohoto tematického celku je vysvětlení smyslu discipliny nazývané softwarové inženýrství. Tematický celek zahrnuje

Více

Analýza a Návrh. Analýza

Analýza a Návrh. Analýza Analysis & Design Návrh nebo Design? Design = návrh Není vytváření použitelného uživatelského prostředí (pouze malinká podmnožina celého návrhu) Často takto omezeně chápáno studenty nedokáží si představit,

Více

POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ

POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ ŽIVOTNÍ CYKLUS IS Stejně jako stroje a technologické linky, které jsou pořízeny, provozovány a následně, po opotřebování vyřazeny, má i informační systém svůj

Více

CobiT. Control Objectives for Information and related Technology. Teplá u Mariánských Lázní, 6. října 2004

CobiT. Control Objectives for Information and related Technology. Teplá u Mariánských Lázní, 6. října 2004 CobiT Control Objectives for Information and related Technology Teplá u Mariánských Lázní, 6. října 2004 Agenda Základy CobiT Pojem CobiT Domény CobiT Hodnocení a metriky dle CobiT IT Governance Řízení

Více

Vývoj informačních systémů. Obecně o IS

Vývoj informačních systémů. Obecně o IS Vývoj informačních systémů Obecně o IS Informační systém Informační systém je propojení informačních technologií a lidských aktivit směřující k zajištění podpory procesů v organizaci. V širším slova smyslu

Více

SWOT ANALÝZA. Příloha č. 2, Pracovní list č. 1 SWOT analýza 28.4.2014. SWOT analýza - obsah. SWOT analýza. 1. Základní informace a princip metody

SWOT ANALÝZA. Příloha č. 2, Pracovní list č. 1 SWOT analýza 28.4.2014. SWOT analýza - obsah. SWOT analýza. 1. Základní informace a princip metody SWOT ANALÝZA 1 SWOT analýza - obsah 1. Základní informace a princip metody 2. Vnější a vnitřní faktory 3. Užitečné tipy a příklady z praxe 2 SWOT analýza I. ZÁKLADNÍ INFORMACE A PRINCIP METODY 3 1 SWOT

Více

ÚVOD DO PROBLEMATIKY PROJEKTŮ, KATEGORIE

ÚVOD DO PROBLEMATIKY PROJEKTŮ, KATEGORIE PROJEKTOVÉ ŘÍZENÍ STAVEB ÚVOD DO PROBLEMATIKY PROJEKTŮ, KATEGORIE Vysoká škola technická a ekonomická v Českých PROJEKTŮ Budějovicích Institute of Technology And Business In České Budějovice Tento učební

Více

Manažerská ekonomika

Manažerská ekonomika PODNIKOVÝ MANAGEMENT (zkouška č. 12) Cíl předmětu Získat znalosti zákonitostí úspěšného řízení organizace a přehled o současné teorii a praxi managementu. Seznámit se s moderními manažerskými metodami

Více

Projektové řízení jako základ řízení organizace

Projektové řízení jako základ řízení organizace Projektové řízení jako základ řízení organizace Aleš Chudý, ředitel divize IW ales.chudy@microsoft.com Technický seminář Bratislava 6.10.2008 Obsah Potřeby byznysu a IT Řešení EPM Microsoft EPM Optimalizační

Více

Stav řešení Enterprise Architektury na Moravskoslezském kraji

Stav řešení Enterprise Architektury na Moravskoslezském kraji Stav řešení Enterprise Architektury na Moravskoslezském kraji Zpracoval(a): Ing. Tomáš Vašica Datum: 23. 9. 2015 Obsah prezentace 1. Představení projektového záměru 2. Co očekává Moravskoslezský kraj od

Více

Ing. Pavel Reich, PA Consulting Group 31. října 2001

Ing. Pavel Reich, PA Consulting Group 31. října 2001 Řízení rizik v rozsáhlých projektech Ing. Pavel Reich, PA Consulting Group 31. října 2001 Riziko je vlastní každému snažení o úspěch Zisk bez rizika neexistuje Délka projektu Znalosti & zkušenosti Složitost

Více

Association for the advancement of Cost Engineering International (AACE) Australian Institute of Project Management (AIPM) English Association of

Association for the advancement of Cost Engineering International (AACE) Australian Institute of Project Management (AIPM) English Association of Association for the advancement of Cost Engineering International (AACE) Australian Institute of Project Management (AIPM) English Association of Project Managers (APM) Association for Project Management

Více

Optimalizaci aplikací. Ing. Martin Pavlica

Optimalizaci aplikací. Ing. Martin Pavlica Optimalizaci aplikací Ing. Martin Pavlica Vize: Aplikace v dnešním světě IT Ze všech částí IT jsou aplikace nejblíže businessu V elektronizovaném světě významným způsobem podporují business, ten se na

Více

InternetovéTechnologie

InternetovéTechnologie 8 InternetovéTechnologie webdesign, mobile first Ing. Michal Radecký, Ph.D. www.cs.vsb.cz/radecky Webové stránky a aplikace - Webové stránky - množina vzájemně propojených stránek, které obsahují informace

Více

Enterprise Architecture na MPSV 23.9.2015

Enterprise Architecture na MPSV 23.9.2015 Enterprise Architecture na MPSV 23.9.2015 Mgr. Bc. et Bc. Robert Baxa, náměstek ministryně Mgr. Jiří Károly, ředitel odboru rozvoje a bezpečnosti ICT Enterprise Architecture (EA) na MPSV Východiska pro

Více

Agile. nejžádanější způsob vývoje software. Tomáš Tureček. Business consultant, Lean&Agile coach Tieto tomas.t.turecek@tieto.com

Agile. nejžádanější způsob vývoje software. Tomáš Tureček. Business consultant, Lean&Agile coach Tieto tomas.t.turecek@tieto.com 2010 Tieto Corporation Agile nejžádanější způsob vývoje software Tomáš Tureček Business consultant, Lean&Agile coach Tieto tomas.t.turecek@tieto.com 2012 Tieto Corporation Tieto Aktivity ve více než 20

Více

Školení v rámci zemědělské a lesnické činnosti 2014

Školení v rámci zemědělské a lesnické činnosti 2014 Vindex JIH, s.r.o. Platnéřská 191 110 00 Praha IČO: 25173278 Název projektu: Školení v rámci zemědělské a lesnické činnosti 2014 Číslo projektu: 13/0181310b/131/000199 Financováno z Programu Rozvoje Venkova

Více

Příspěvek je věnován základním informacím o způsobu volby vhodné strategie řízení kontinuity činností v organizaci.

Příspěvek je věnován základním informacím o způsobu volby vhodné strategie řízení kontinuity činností v organizaci. Mgr. Monika Johaníková Ochrana & Bezpečnost 2013, ročník II., č. 3 (podzim), ISSN 1805-5656 Stanovení strategie řízení kontinuity činností Anotace Příspěvek je věnován základním informacím o způsobu volby

Více

Operační program Lidské zdroje a zaměstnanost

Operační program Lidské zdroje a zaměstnanost Operační program Lidské zdroje a zaměstnanost EDUCA III Další profesní vzdělávání zaměstnanců společnosti T-MAPY spol. s r.o. 2013-2015 září 2013 - únor 2015 Charakteristika projektu Projekt je zaměřen

Více

Zpráva o Digitální cestě k prosperitě

Zpráva o Digitální cestě k prosperitě Zpráva o Digitální cestě k prosperitě Milena Tvrdíková Milena Tvrdíková Katedra aplikované informatiky, VŠB- Technická Univerzita Ostrava Sokolská třída 33. 701 21Ostrava 1 milena.tvrdikova@vsb.cz Ve vyspělých

Více

Informační systémy ve strojírenství

Informační systémy ve strojírenství 3 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení Informační systémy ve strojírenství Radim Farana 1 Obsah Životní cyklus vývoje SW. Informační

Více

5 Požadavky a jejich specifikace

5 Požadavky a jejich specifikace 5 Požadavky a jejich specifikace 5.1 Inženýrství (requirements engineering) - proces stanovení služeb, které by měl vyvíjený systém poskytovat a omezení, za nichž musí pracovat - CO má systém dělat, ne

Více

PROCESY CO ZÍSKÁTE: Předpoklad pro certifikace ISO. Lean Six Sigma Fast Track

PROCESY CO ZÍSKÁTE: Předpoklad pro certifikace ISO. Lean Six Sigma Fast Track PROCESY CO ZÍSKÁTE: Jasná pravidla pro provádění činností, uložení know-how Jasně definované zodpovědnosti za celý proces i jednotlivé kroky Zprůhlednění organizace plynoucí z jasně definovaných vstupů,

Více

Odbor informatiky a provozu informačních technologií

Odbor informatiky a provozu informačních technologií POLICEJNÍ PREZIDIUM ČR Odbor informatiky a provozu informačních technologií Příloha č. 1 a) název zakázky, Technická podpora software pro systém NS-VIS a VISMAIL b) předmět a rozsah plnění veřejné zakázky

Více

AGILNÍ METODIKY VÝVOJE SOFTWARE

AGILNÍ METODIKY VÝVOJE SOFTWARE AGILNÍ METODIKY VÝVOJE SOFTWARE Postupy předchozích metodik, založené na důsledné analýze a propracovaném návrhu jsou obecně nejlepší. Ale Děláte web půl roku? Konkurence mezitím spustila dva Zdánlivě

Více

14 Úvod do plánování projektu Řízení projektu

14 Úvod do plánování projektu Řízení projektu 14 Úvod do plánování projektu Řízení projektu Plánování projektu Vývoj - rozbor zadání odhad pracnosti, doby řešení, nákladů,... analýza rizik strategie řešení organizace týmu PLÁN PROJEKTU 14.1 Softwarové

Více

SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE

SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE Václav Šebesta Ústav informatiky Akademie věd ČR, e-mail: vasek@cs.cas.cz Abstrakt Jestliže ještě před

Více

Management. Rozhodování. Ing. Vlastimil Vala, CSc. Ústav lesnické a dřevařské ekonomiky a politiky

Management. Rozhodování. Ing. Vlastimil Vala, CSc. Ústav lesnické a dřevařské ekonomiky a politiky Management Rozhodování Ing. Vlastimil Vala, CSc. Ústav lesnické a dřevařské ekonomiky a politiky Vytvořeno s podporou projektu Průřezová inovace studijních programů Lesnické a dřevařské fakulty MENDELU

Více

Vnitřní kontrolní systém a jeho audit

Vnitřní kontrolní systém a jeho audit Vnitřní kontrolní systém a jeho audit 7. SETKÁNÍ AUDITORŮ PRŮMYSLU 11. 5. 2012 Vlastimil Červený, CIA, CISA Agenda Požadavky na VŘKS dle metodik a standardů Definice VŘKS dle rámce COSO Role interního

Více

Projektová dokumentace pro tvorbu internetových aplikací

Projektová dokumentace pro tvorbu internetových aplikací Projektová dokumentace pro tvorbu internetových aplikací Tomáš Kuthan PhDr. Milan Novák, Ph.D. Školní rok: 2008-09 Abstrakt Bakalářská práce stanovuje vzor pro vytváření projektové dokumentace internetových

Více

CorSet KNIHA 5. Informační architektura. David Melichar Tomáš Hrabík Tomáš Kuba Michal Hala Ivana Protivová

CorSet KNIHA 5. Informační architektura. David Melichar Tomáš Hrabík Tomáš Kuba Michal Hala Ivana Protivová CorSet KNIHA 5 Informační architektura David Melichar Tomáš Hrabík Tomáš Kuba Michal Hala Ivana Protivová 31. 07. 2008 Shrnutí Metodický referenční rámec CorSet vznikl proto, aby organizace ve veřejném

Více

INFORMAČNÍ SYSTÉMY (IS) Ing. Pavel Náplava Katedra počítačů K336, ČVUT FEL Praha 2004/2005

INFORMAČNÍ SYSTÉMY (IS) Ing. Pavel Náplava Katedra počítačů K336, ČVUT FEL Praha 2004/2005 INFORMAČNÍ SYSTÉMY (IS) Ing. Pavel Náplava Katedra počítačů K336, ČVUT FEL Praha 2004/2005 AGENDA definice IS, zavedení pojmů možnosti a rozdělení typická struktura technologie nasazení praktická ukázka

Více

Příloha č. 3 Smlouvy Součinnost stran při poskytování některých plnění

Příloha č. 3 Smlouvy Součinnost stran při poskytování některých plnění Příloha č. 3 Smlouvy Součinnost stran při poskytování některých plnění Nástroje pro poskytování součinnosti 1.1 Help desk Poskytovatel vytvoří a zajistí službu pro hlášení vad/požadavků/připomínek (dále

Více

Ing. Jiří Fejfar, Ph.D. Geo-informační systémy

Ing. Jiří Fejfar, Ph.D. Geo-informační systémy Ing. Jiří Fejfar, Ph.D. Geo-informační systémy Definice, budování a život GIS Kapitola 1: Vztahy strana 2 Data, informace, IS, GIS Kapitola 1: Vztahy strana 3 Rozhodnutí Znalosti Znalostní systémy. Informace

Více

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda 1. Lze vždy z tzv. instanční třídy vytvořit objekt? 2. Co je nejčastější příčinou vzniku chyb? A. Specifikace B. Testování C. Návrh D. Analýza E. Kódování 3. Je defenzivní programování technikou skrývání

Více

INFORMAČNÍ SYSTÉMY. 03. 01. 2006, Ing. Jiří Mráz

INFORMAČNÍ SYSTÉMY. 03. 01. 2006, Ing. Jiří Mráz INFORMAČNÍ SYSTÉMY 03. 01. 2006, Ing. Jiří Mráz PŘEDNÁŠEJÍCÍ Jiří Mráz Production Coordinator UNICORN jiri.mraz@unicorn.cz AGENDA Informační a komunikační technologie (ICT) podniku Informační systémy Zakázkový

Více

KATALOG SLUŽEB NÁSLEDNÉ PODPORY

KATALOG SLUŽEB NÁSLEDNÉ PODPORY KATALOG SLUŽEB NÁSLEDNÉ PODPORY Společnost WEBCOM a. s. Vám nabízí kompletní pokrytí Vašich požadavků na zajištění služeb technické podpory Microsoft Dynamics přesně podle Vašich potřeb a v požadovaném

Více

Softwarové inženýrství 01. doc. Ing. František Huňka, CSc.

Softwarové inženýrství 01. doc. Ing. František Huňka, CSc. Softwarové inženýrství 01 doc. Ing. František Huňka, CSc. Obsah kurzu Softwarové inženýrství obecně vodopádová model spirálový model RUP agilní metodiky vývoj řízený vlastnostmi (Feature Development Design)

Více

Agilní metodiky vývoje softwaru

Agilní metodiky vývoje softwaru vývoje softwaru : důraz na průběžnou komunikaci mezi vývojovým týmem a zákazníkem důraz na tvorbu kvalitního kódu a funkcí, které mají přímou obchodní hodnotu pro zákazníka týmovou spolupráci a samoorganizaci

Více

Design systému. Komponentová versus procesní architektura

Design systému. Komponentová versus procesní architektura Design systému Komponentová versus procesní architektura Architektura : třídy statické aspekty propojení logický pohled struktura popisu systému Architektura procesů: objekty dynamické aspekty koordinace

Více

Vývoj IS. Vladimíra Zádová, KIN, EF TUL- ISN3

Vývoj IS. Vladimíra Zádová, KIN, EF TUL- ISN3 Vývoj IS Metodika Metoda Nástroje Technika Životní cyklus Etapy Přístupy k vývoji Základní alternativy vývoje a provozu Integrace Doporučený souhrn etap, přístupů, zásad, postupů, pravidel, metod, technik,

Více

PILOTNÍ OVĚŘOVÁNÍ v aktivitě Ekonomická gramotnost

PILOTNÍ OVĚŘOVÁNÍ v aktivitě Ekonomická gramotnost PILOTNÍ OVĚŘOVÁNÍ v aktivitě Ekonomická gramotnost 1. Úvod V souladu s aktivitami projektu byl výukový modul Ekonomická gramotnost pilotně ověřen na primární (děti) i sekundární (pedagogové) cílové skupině.

Více

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz RUP - Disciplíny Jaroslav Žáček jaroslav.zacek@osu.cz Disciplíny Množství disciplíny v dané iteraci Disciplíny podle RUP Šest základních: Business modeling - pro pochopení problémové domény Requirements

Více

Obsah. Úvod 9 Poděkování 10 Co je obsahem této knihy 10 Pro koho je tato kniha určena 11 Zpětná vazba od čtenářů 11 Errata 11

Obsah. Úvod 9 Poděkování 10 Co je obsahem této knihy 10 Pro koho je tato kniha určena 11 Zpětná vazba od čtenářů 11 Errata 11 Úvod 9 Poděkování 10 Co je obsahem této knihy 10 Pro koho je tato kniha určena 11 Zpětná vazba od čtenářů 11 Errata 11 KAPITOLA 1 Co je třeba znát aneb důležité pojmy 13 Krátce o požadavcích 13 Stakeholdeři

Více

Projektové řízení a rizika v projektech

Projektové řízení a rizika v projektech Projektové řízení a rizika v projektech Zainteresované strany Zainteresované strany (tzv. stakeholders) jsou subjekty (organizace, lidé, prostory, jiné projekty), které realizace projektu ovlivňuje. Tyto

Více

3. Očekávání a efektivnost aplikací

3. Očekávání a efektivnost aplikací VYUŽÍVANÍ INFORMAČNÍCH SYSTÉMŮ V ŘÍZENÍ FIREM Ota Formánek 1 1. Úvod Informační systémy (IS) jsou v současnosti naprosto nezbytné pro úspěšné řízení firem. Informačním ním systémem rozumíme ucelené softwarové

Více

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování 1. Teoretické základy modelování na počítačích 1.1 Lambda-kalkul 1.1.1 Formální zápis, beta-redukce, alfa-konverze 1.1.2 Lambda-výraz jako data 1.1.3 Příklad alfa-konverze 1.1.4 Eta-redukce 1.2 Základy

Více

Přípravné činnosti projektu. Mgr. Lenka Svrčinová Ing. Jan Ministr, Ph.D.

Přípravné činnosti projektu. Mgr. Lenka Svrčinová Ing. Jan Ministr, Ph.D. Přípravné činnosti projektu Mgr. Lenka Svrčinová Ing. Jan Ministr, Ph.D. Obsah prezentace Seznámení s problematikou Procesy a roviny před implementací projektu Obchodní rovina Implementační rovina Řešení

Více

Zátěžové testy aplikací

Zátěžové testy aplikací Zátěžové testy aplikací Obsah Zátěžové testy v životním cyklu vývoje software Kdy a proč provádět zátěžové testy Projekt zátěžového testu Fáze zátěžového testu Software pro zátěžové testy Zátěžové testy

Více

Projekt Systematickým vzděláváním k rozvoji zaměstnanců a kvalitě řízení Městského úřadu Luhačovice"

Projekt Systematickým vzděláváním k rozvoji zaměstnanců a kvalitě řízení Městského úřadu Luhačovice Projekt Systematickým vzděláváním k rozvoji zaměstnanců a kvalitě řízení Městského úřadu Luhačovice" Registrační číslo: CZ.1.04/4.1.01/69.00060 Zkrácený název projektu: Vzdělávání v MěÚ Luhačovice Datum

Více

D1 Trvalá organizace

D1 Trvalá organizace Projektový manažer 250+ Kariéra projektového manažera začíná u nás! D Útvarové a procesní řízení D1 Trvalá organizace Toto téma obsahuje informace o trvalé organizaci, jejích základních principech a prostředí.

Více

Leady & MERK Integrace Microsoft Dynamics CRM s aplikacemi Leady a MERK

Leady & MERK Integrace Microsoft Dynamics CRM s aplikacemi Leady a MERK Integrace Microsoft Dynamics CRM s aplikacemi Leady a MERK Strana 1 z 12 Obsah 1. Leady... 3 a. Shrnutí... 3 b. Popis modulu... 3 c. Technické podrobnosti o modulu... 5 2. MERK... 6 a. Shrnutí... 6 b.

Více

Představení projektu Metodika

Představení projektu Metodika Představení projektu Metodika přípravy veřejných strategií Strategické plánování a řízení v obcích metody, zkušenosti, spolupráce Tematická sekce Národní sítě Zdravých měst Praha, 10. května 2012 Obsah

Více

egovernment ready úřad

egovernment ready úřad egovernment ready úřad Ing. Václav Koudele Strategy architect Tel.: +420 602 191 122 Vaclav.koudele@microsoft.com Ing. Zdeněk Dutý Ředitel pro egovernment Tel.: +420 910 972 131 zdenek.duty@autocont.cz

Více

Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace

Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace B5 Program Téma obsahuje informace o programech a programovém řízení a klade si za cíl především vysvětlit

Více

1.1 Zátěžové testování

1.1 Zátěžové testování 1.1 Zátěžové testování Předpokladem pro toto stádium testování je ukončení funkčních testů a zamražení systému pro zátěžové testování. Toto stádium testování má podpořit systémové testování a poukázat

Více

Úvod do projektu. Standardizace provozních funkcí ÚSC. Součást projektu Korporátní styl řízení ve veřejné správě

Úvod do projektu. Standardizace provozních funkcí ÚSC. Součást projektu Korporátní styl řízení ve veřejné správě Úvod do projektu Standardizace provozních funkcí ÚSC Součást projektu Korporátní styl řízení ve veřejné správě Měníme zvyky a posouváme mentální bloky POPTÁVKA Tlak na rozpočet, obtížně stanovitelné rozpočtové

Více

PODNIKATELSKÝ PLÁN. Střední odborná škola a Gymnázium Staré Město. Ing. Miroslava Kořínková III/2 Inovace a zkvalitnění výuky prostřednictvím ICT

PODNIKATELSKÝ PLÁN. Střední odborná škola a Gymnázium Staré Město. Ing. Miroslava Kořínková III/2 Inovace a zkvalitnění výuky prostřednictvím ICT Název školy Číslo projektu Autor Název šablony PODNIKATELSKÝ PLÁN Střední odborná škola a Gymnázium Staré Město CZ.1.07/1.5.00/34.1007 Ing. Miroslava Kořínková III/2 Inovace a zkvalitnění výuky prostřednictvím

Více

GIS Libereckého kraje

GIS Libereckého kraje Funkční rámec Zpracoval: Odbor informatiky květen 2004 Obsah 1. ÚVOD...3 1.1. Vztah GIS a IS... 3 2. ANALÝZA SOUČASNÉHO STAVU...3 2.1. Technické zázemí... 3 2.2. Personální zázemí... 3 2.3. Datová základna...

Více

Příloha č.3 Otázka pro hodnocení manažera

Příloha č.3 Otázka pro hodnocení manažera Příloha č.3 Otázka pro hodnocení manažera 1. Sleduje profesní a technický vývoj? 2. Připravuje a dodržuje realistický rozpočet? 3. Zaměřuje se na podstatné informace a neztrácí se v nedůležitých detailech?

Více

Informační strategie. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz

Informační strategie. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Informační strategie Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz 23 1 Firemní strategie Firma Poslání Vize Strategie Co chceme? Kam směřujeme? Jak toho dosáhneme? Kritické faktory úspěchu CSF 23 2 Strategie

Více

PROJEKTOVÁ VÝUKA, ŘÍZENÍ PROJEKTŮ A VÝZNAM CERTIFIKACE PRO BUDOUCÍ KARIÉRNÍ RŮST

PROJEKTOVÁ VÝUKA, ŘÍZENÍ PROJEKTŮ A VÝZNAM CERTIFIKACE PRO BUDOUCÍ KARIÉRNÍ RŮST PROJEKTOVÁ VÝUKA, ŘÍZENÍ PROJEKTŮ A VÝZNAM CERTIFIKACE PRO BUDOUCÍ KARIÉRNÍ RŮST Ing. Jan Doležal Agenda 2 Projektové řízení a projektová výuka Jaké jsou požadavky praxe? Význam a možnosti certifikace

Více

Hodnocení železničních systémů podle Evropských standardů. Doc. Dr. Ing. Tomáš Brandejský Ing. Martin Leso, PhD Fakulta dopravní ČVUT v Praze

Hodnocení železničních systémů podle Evropských standardů. Doc. Dr. Ing. Tomáš Brandejský Ing. Martin Leso, PhD Fakulta dopravní ČVUT v Praze Hodnocení železničních systémů podle Evropských standardů Doc. Dr. Ing. Tomáš Brandejský Ing. Martin Leso, PhD Fakulta dopravní ČVUT v Praze Obecné požadavky Přechod do bezpečnějšího stavu při poruše Náhodné

Více

Životní cyklus vývoje SW. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Životní cyklus vývoje SW. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Životní cyklus vývoje SW Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Proč potřebujeme definovat proces vývoje Při vývoji SW nemáme tvrdá fakta, jako v jiných vědách (fyzika, chemie,

Více

ORACLE ŘÍZENÍ FINANCÍ

ORACLE ŘÍZENÍ FINANCÍ ORACLE ŘÍZENÍ FINANCÍ Modul Oracle řízení financí je celopodnikové řešení pro správu likvidity a řízení peněžních prostředků. Tento modul je součástí Aplikací Oracle. To je integrovaná sada aplikací elektronického

Více

Procesy, procesní řízení organizace. Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje

Procesy, procesní řízení organizace. Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje Procesy, procesní řízení organizace Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje Co nového přináší ISO 9001:2008? Vnímání jednotlivých procesů organizace jako prostředku a nástroje

Více

Prof. Ing. Miloš Konečný, DrSc. Nedostatky ve výzkumu a vývoji. Klíčové problémy. Tyto nedostatky vznikají v následujících podmínkách:

Prof. Ing. Miloš Konečný, DrSc. Nedostatky ve výzkumu a vývoji. Klíčové problémy. Tyto nedostatky vznikají v následujících podmínkách: Podnik je konkurenčně schopný, když může novými výrobky a službami s vysokou hodnotou pro zákazníky dobýt vedoucí pozice v oboru a na trhu. Prof. Ing. Miloš Konečný, DrSc. Brno University of Technology

Více

Výhody a rizika outsourcingu formou cloud computingu

Výhody a rizika outsourcingu formou cloud computingu Výhody a rizika outsourcingu formou cloud computingu Jiří Voříšek katedra informačních technologií Vysoká škola ekonomická v Praze vorisek@vse.cz 1 Výchozí model MMDIS pro identifikaci možností outsourcingu

Více

Téma dizertační práce - Strategie ŠKODA AUTO pro čínský trh

Téma dizertační práce - Strategie ŠKODA AUTO pro čínský trh Téma dizertační práce - Strategie ŠKODA AUTO pro čínský trh - Spolupráce při stanovování dlouhodobé strategie ŠKODA AUTO pro čínský trh se zaměřením na produktový management - Analýza současné pozice ŠKODA

Více

METODIKA FEATURE-DRIVEN DEVELOPMENT NEOPOUŠTÍ MODELOVÁNÍ A PROCESY, A PŘESTO PŘINÁŠÍ VÝHODY AGILNÍHO VÝVOJE ing. Alena Buchalcevová, Ph.

METODIKA FEATURE-DRIVEN DEVELOPMENT NEOPOUŠTÍ MODELOVÁNÍ A PROCESY, A PŘESTO PŘINÁŠÍ VÝHODY AGILNÍHO VÝVOJE ing. Alena Buchalcevová, Ph. METODIKA FEATURE-DRIVEN DEVELOPMENT NEOPOUŠTÍ MODELOVÁNÍ A PROCESY, A PŘESTO PŘINÁŠÍ VÝHODY AGILNÍHO VÝVOJE ing. Alena Buchalcevová, Ph.D Katedra informačních technologií VŠE Praha nám. W.Churchilla 4,

Více

Metodická pomůcka pro specifikaci dočasných opatření. doc. Ing. Pavel Šenovský, Ph.D. Ing. Pavlína Ježková

Metodická pomůcka pro specifikaci dočasných opatření. doc. Ing. Pavel Šenovský, Ph.D. Ing. Pavlína Ježková Metodická pomůcka pro specifikaci dočasných opatření doc. Ing. Pavel Šenovský, Ph.D. Ing. Pavlína Ježková Vysoká škola báňská Technická univerzita Ostrava, Fakulta bezpečnostního inženýrství Ostrava 2013

Více

Zápočtová úloha z předmětu KIV/ZSWI DOKUMENT SPECIFIKACE POŽADAVKŮ

Zápočtová úloha z předmětu KIV/ZSWI DOKUMENT SPECIFIKACE POŽADAVKŮ Zápočtová úloha z předmětu KIV/ZSWI DOKUMENT SPECIFIKACE POŽADAVKŮ 10. 5. 2011 Tým: Simplesoft Členové: Zdeněk Malík Jan Rada Ladislav Račák Václav Král Marta Pechová malikz@students.zcu.cz jrada1@students.zcu.cz

Více

Informační systém pro centrální správu lokální sítě a služeb ISP

Informační systém pro centrální správu lokální sítě a služeb ISP MASARYKOVA UNIVERZITA Fakulta informatiky PV098 Řízení implementace IS semestrální práce Informační systém pro centrální správu lokální sítě a služeb ISP Jiří Kratochvíla, učo 207622, semestr 6, ročník

Více

Procesní řízení operačních sálů Mgr. Martin Gažar

Procesní řízení operačních sálů Mgr. Martin Gažar Procesní řízení operačních sálů Mgr. Martin Gažar Procesy Procesy Procesní analýza Procesní mapa Modely procesů Optimalizace procesů Přínosy procesní analýzy Procesy a modely Procesy Abychom mohli úspěšně

Více

Bakalářský studijní obor hospodářská informatika

Bakalářský studijní obor hospodářská informatika Bakalářský studijní obor hospodářská informatika Předpoklady Struktura studia Přihlášky Poradenství Bakalářský studijní obor hospodářská informatika nabízí fundované vědecké a praktické vzdělání v oblasti

Více

ODŮVODNĚNÍ VEŘEJNÉ ZAKÁZKY

ODŮVODNĚNÍ VEŘEJNÉ ZAKÁZKY ODŮVODNĚNÍ VEŘEJNÉ ZAKÁZKY v souladu s 156 odst. 1 zákona č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů (dále jen zákon ) Zadavatel: Česká republika Ministerstvo financí Sídlo: Letenská

Více

Metodický list pro první soustředění kombinovaného studia. předmětu Management ve finančních službách

Metodický list pro první soustředění kombinovaného studia. předmětu Management ve finančních službách Metodický list pro první soustředění kombinovaného studia předmětu Management ve finančních službách Název tematického celku: Základní koncepční přístupy a osobnost manažera Cíl: V návaznosti na poznatky

Více

Informační systémy. Jaroslav Žáček jaroslav.zacek@osu.cz

Informační systémy. Jaroslav Žáček jaroslav.zacek@osu.cz Informační systémy Jaroslav Žáček jaroslav.zacek@osu.cz Úvod - co možná umíte z předmětu SWENG Rozdělení IT Architektura IS Klíčový prvek řízení IS z něj vycházejí detailní analytické i plánovací charakteristiky

Více

Obsah. 1. část Definice projektových cílů

Obsah. 1. část Definice projektových cílů Předmluva 1 Proč je řízení projektů tak důležité 1 Komu je kniha určena 1 Pojetí výkladu řízení projektů v této knize 2 Užitečné a unikátní rysy knihy 2 Jak je kniha uspořádána 3 Poděkování 4 1. Co je

Více

VÝROBA. Helios Orange + něco navíc. Adresa: SAPERTA s.r.o. Presy 371 53701 Telefon: 777 071 626 E-mail: saperta@saperta.cz WWW: saperta.

VÝROBA. Helios Orange + něco navíc. Adresa: SAPERTA s.r.o. Presy 371 53701 Telefon: 777 071 626 E-mail: saperta@saperta.cz WWW: saperta. VÝROBA Helios Orange + něco navíc Adresa: SAPERTA s.r.o. Presy 371 53701 Telefon: 777 071 626 E-mail: saperta@saperta.cz WWW: saperta.cz MODUL VÝROBY Modul Řízení výroby vychází z osvědčeného základního

Více

Obsah. ÚVOD 1 Poděkování 3

Obsah. ÚVOD 1 Poděkování 3 ÚVOD 1 Poděkování 3 Kapitola 1 CO JE TO PROCES? 5 Co všechno musíme vědět o procesním řízení, abychom ho mohli zavést 6 Různá důležitost procesů 13 Strategické plánování 16 Provedení strategické analýzy

Více

Zařízení pro kontrolu výrobků

Zařízení pro kontrolu výrobků Zařízení pro kontrolu výrobků Školení Obsluha Manažeři zabezpečování jakosti Technici údržby Školení Využívejte svá zařízení naplno Školení ke kontrolním přístrojům Školení uživatelů Jistota a know-how

Více

1 Strukturované programování

1 Strukturované programování Projekt OP VK Inovace studijních oborů zajišťovaných katedrami PřF UHK Registrační číslo: CZ.1.07/2.2.00/28.0118 1 Cíl Seznámení s principy strukturovaného programování, s blokovou strukturou programů,

Více

TOGETHER WE CAN projekt interních koučů v UniCredit Bank

TOGETHER WE CAN projekt interních koučů v UniCredit Bank TOGETHER WE CAN projekt interních koučů v UniCredit Bank Firma: UniCredit Bank Czech Republic, a.s. Na Příkopě 858/20 111 21 Praha 1 www.unicreditbank.cz Kontaktní osoba: Lenka Štěpánová Learning & Development

Více