Aplikace pro podporu odhadu nákladů nasazování informačního … · 2016-01-04 · Čestné prohlášení Prohlašuji, že jsem tuto práci: Aplikace pro podporu odhadu nákladů

Mendelova univerzita v Brně Provozně ekonomická fakulta

Brno 2015

Aplikace pro podporu odhadu nákladů nasazování

informačního systému

Diplomová práce

Vedoucí práce:

doc. Ing. Oldřich Trenz, Ph.D. Bc. Tomáš Mikóczy

Tímto bych velmi rád poděkoval vedoucímu této diplomové práce doc. Ing. Oldři-chu Trenzovi Ph.D. za odborné vedení této práce, při kterém mi poskytl velmi cen-né připomínky a rady.

Čestné prohlášení

Prohlašuji, že jsem tuto práci: Aplikace pro podporu odhadu nákladů nasazování informačního systému vypracoval samostatně a veškeré použité prameny a informace jsou uvedeny v seznamu použité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s § 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů, a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací.

Jsem si vědom, že se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a že Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a užití této práce jako školního díla podle § 60 odst. 1 Autorského zákona.

Dále se zavazuji, že před sepsáním licenční smlouvy o využití díla jinou osobou (subjektem) si vyžádám písemné stanovisko univerzity o tom, že předmět-ná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to až do jejich skutečné výše.

V Brně dne 28. prosince 2015 _______________________________

Abstract

Mikóczy, T. Application supporting cost estimation of information system deploy-ment. Diploma thesis. Brno: Mendel University, 2015. This diploma thesis deals with cost estimation issue and design of software appli-cation assisting while creating such estimates. This application should provide an alternative to other approaches of information system cost estimates. In the theo-retical part we acquire an overview of existing methods of estimate creations and the possibilities of their use. The practical part contains a design of an application assisting estimations. The correctness of the proposed design is verified by partial implementation of the application later on in the last part of the thesis.

Keywords

Information system deployment, cost estimation, COCOMO, function points, Py-thon, application modelling, UML.

Abstrakt

Mikóczy, T. Aplikace pro podporu odhadu nákladů nasazování informačního sys-tému. Diplomová práce. Brno: Mendelova univerzita v Brně, 2015. Tato diplomová práce se zabývá problematikou odhadu nákladů a navržení aplika-ce, která tyto odhady bude podporovat. Aplikace by měla nabídnout alternativu v přístupech k odhadům nasazování informačních systémů. Teoretická část je za-měřena na získání přehledu existujících metod provádění odhadu a možnostech jejich využití. Praktická část obsahuje návrh aplikace pro podporu odhadů. Správ-nost návrhu aplikace je dále v poslední části této práce ověřena implementací části aplikace.

Klíčová slova

Nasazování informačního systému, odhad nákladů, COCOMO, funkční celky, Pyt-hon, návrh aplikace, UML.

Obsah 11

Obsah

1 Úvod a cíl práce 19

1.1 Úvod .......................................................................................................................................... 19

1.2 Cíl práce ................................................................................................................................... 19

2 Vývoj informačního systému a jeho řízení 21

2.1 Přístupy k vývoji systému ............................................................................................... 21

2.1.1 RUP .................................................................................................................................. 21

2.1.2 SCRUM ........................................................................................................................... 22

2.1.3 Prototypování ............................................................................................................. 22

2.1.4 Extrémní programování ........................................................................................ 22

2.2 Fáze vývoje informačního systému ............................................................................. 23

2.3 Projektové řízení ................................................................................................................. 23

3 Odhady a jejich přínosy 24

3.1 Proč odhad? ........................................................................................................................... 24

3.1.1 Co je to odhad? ........................................................................................................... 24

3.1.2 Dobrý odhad ............................................................................................................... 24

3.2 Charakteristiky odhadů .................................................................................................... 25

3.2.1 Přesnost odhadů ....................................................................................................... 26

3.2.2 Konzistentnost ........................................................................................................... 27

3.2.3 Užitečnost ..................................................................................................................... 27

3.3 Metriky odhadů .................................................................................................................... 27

3.3.1 Počítání řádků kódu ................................................................................................ 28

3.3.2 Funkční celky .............................................................................................................. 28

3.3.3 Případy užití ................................................................................................................ 28

3.3.4 Lidská práce za jednotku času ............................................................................ 29

3.4 Kalibrace dat ......................................................................................................................... 29

3.5 Používané metodiky pro odhad .................................................................................... 30

3.5.1 Metody s použitím analogie ................................................................................. 30

3.5.2 Metoda s použitím zástupce ................................................................................. 30

12 Obsah

3.5.3 Metoda expertních odhadů ................................................................................... 32

3.5.4 Skupinové hodnocení .............................................................................................. 33

4 Algoritmické přístupy k odhadům 34

4.1 Putnamův model .................................................................................................................. 34

4.2 Cocomo II ................................................................................................................................ 34

4.2.1 Early Design a Post-Architecture model ......................................................... 35

4.2.2 Možnosti přizpůsobení modelu konkrétní organizaci .............................. 38

4.3 Metoda bodů případů užití (Use Case Points) ......................................................... 39

4.4 Analýza funkčních celků (FPA) ...................................................................................... 39

4.4.1 Hlavní komponenty .................................................................................................. 39

4.4.2 Upravené funkční celky .......................................................................................... 41

4.4.3 Nizozemská metoda ................................................................................................. 45

4.5 Analýza případů užití ......................................................................................................... 45

4.6 Odhadování pracnosti projektu .................................................................................... 47

4.7 Odhadování časového rámce projektu ....................................................................... 47

4.8 Odhadování ceny projektu .............................................................................................. 48

4.8.1 Rizika a hrozby ........................................................................................................... 48

4.8.2 Odhadování chyb ....................................................................................................... 48

4.8.3 Počet prostředí ........................................................................................................... 50

4.8.4 Přímé náklady ............................................................................................................. 50

4.8.5 Přesčasy ......................................................................................................................... 50

4.9 Možné druhy prezentace odhadu ................................................................................. 50

4.10 Existující aplikace ................................................................................................................ 51

5 Nástroje pro návrh aplikace 52

5.1 Softwarové požadavky ...................................................................................................... 52

5.2 Notace UML ............................................................................................................................ 52

5.2.1 Struktura jazyka ......................................................................................................... 52

5.2.2 Diagram případů užití ............................................................................................. 54

5.2.3 Diagram aktivit ........................................................................................................... 55

5.2.4 Stavový diagram ........................................................................................................ 55

5.2.5 Diagram tříd ................................................................................................................ 55

Obsah 13

5.3 Diagram požadavků ........................................................................................................... 55

5.4 Eriksson-Penker .................................................................................................................. 55

6 Metodika řešení 57

6.1 Vybrané metodiky .............................................................................................................. 57

7 Návrh řešení 58

7.1 Identifikace uživatele a definice účelu aplikace ..................................................... 58

7.2 Analýza požadavků ............................................................................................................. 59

7.2.1 Designové požadavky ............................................................................................. 59

7.2.2 Funkční požadavky .................................................................................................. 59

7.2.3 Požadavky na výkon ................................................................................................ 60

7.2.4 Omezení návrhu ........................................................................................................ 60

7.2.5 Vlastnosti systému ................................................................................................... 60

7.3 Popis logické funkcionality systému........................................................................... 61

7.4 Diagram případů užití ....................................................................................................... 63

7.5 Rozbor hlavních metod .................................................................................................... 65

7.5.1 Obecný postup při tvorbě projektu .................................................................. 65

7.5.2 Automatické určení metody tvorby projektu ............................................... 67

7.5.3 Uložení odhadu .......................................................................................................... 69

7.5.4 Načtení uloženého odhadu ................................................................................... 70

7.5.5 Použití historických dat ......................................................................................... 71

7.6 Diagram tříd .......................................................................................................................... 72

7.7 Struktura datových úložišť ............................................................................................. 73

8 Implementace navrženého řešení 74

8.1 Návrh vzhledu ...................................................................................................................... 74

8.2 Popis použitých nástrojů ................................................................................................. 76

8.2.1 QT Designer ................................................................................................................. 76

8.2.2 Python ............................................................................................................................ 77

8.2.3 Propojení kódu v Pythonu s QT návrhem ...................................................... 77

8.3 Definice rozsahu implementace ................................................................................... 78

8.4 Navržená aplikace ............................................................................................................... 79

14 Obsah

9 Diskuze a závěr 84

9.1 Návrh na využití v praxi .................................................................................................... 85

10 Literatura 86

A Diagram požadavků 91

B Obsah přiloženého CD 93

Obsah 15

16 Seznam obrázků

Seznam obrázků

Obr. 1 Křivka představující pravděpodobnost dokončení projektu (Atreya, 2011) 25

Obr. 2 Kužel nejistoty (Jůza, 2012) 26

Obr. 3 Přehled reprezentací vlastností systému v různých fázích vývoje (Hansen, 2012) 28

Obr. 4 Rozdělení UML diagramů (Arlow, 2007) 54

Obr. 5 Základní schéma aplikace pomocí „Eriksson-Penker notace“ 63

Obr. 6 Diagram případů užití 64

Obr. 7 Diagram aktivit – Tvorba projektu 66

Obr. 8 Stavový diagram – Přehled stavů při ukládání a načítání dat z paměti 70

Obr. 9 Diagram aktivit – Načtení uloženého odhadu 71

Obr. 10 Diagram tříd aplikace 72

Obr. 11 Návrh vzhledu úvodní obrazovky 74

Obr. 12 Návrh vzhledu obrazovky s přehledem výstupu 75

Obr. 13 Zobrazení přechodů mezi jednotlivými nástroji 76

Obr. 14 Diagram tříd implementované aplikace 78

Obr. 15 Implementace – Úvodní strana 79

Obr. 16 Implementace – Tvorba projektu, krok 1 80

Obr. 17 Implementace – Tvorba projektu, krok 2 81

Obr. 18 Implementace – vzorek trénovacích dat 81

Obr. 19 Implementace – Ukázka kódu pracujícího s trénovacími daty 82

Obr. 20 Implementace – Ukázka kódu implementujícího výpočet pracnosti projektu pomocí metody ISBSG 82

Obr. 21 Implementace – Výstup aplikace 83

Obr. 22 Diagram požadavků doplněný o případy užití realizující jednotlivé požadavky 91

Seznam tabulek 17

Seznam tabulek

Tab. 1 Přehled jednotlivých faktorů a jejich popis 36

Tab. 2 Hodnoty faktorů metody Cocomo II 38

Tab. 3 Multiplikátory objektů FPA 41

Tab. 4 FPA – Stupně vlivu charakteristik na informační systém 41

Tab. 5 FPA – Přehled základních charakteristik ovlivňujících systém 43

Tab. 6 Rozdělení jazyků pro převod funkčních celků na řádky kódu 44

Tab. 7 Rozdělení aktérů a váhy skupin 45

Tab. 8 Přehled faktorů technické složitosti a jejich vah 46

Tab. 9 Přehled faktorů prostředí a jejich vah 46

Tab. 10 Typická hustota chyb dle velikosti systému 49

Tab. 11 Typické odstranění chyb dle zvoleného postupu 49

Tab. 12 Výsledky analýzy metod 67

Tab. 13 Rozdělení možných vstupů pro jednotlivé oblasti 68

Tab. 14 Seřazené ohodnocení faktorů metod 68

Tab. 15 Přehled otázek k uživateli pro vstup 68

Tab. 16 Přehled struktury úložiště historických dat 73

Tab. 17 Přehled struktury uložených odhadů 73

Tab. 18 Srovnání výhod tvorby rozhraní v Qt 77

18 Seznam tabulek

Úvod a cíl práce 19

1 Úvod a cíl práce

1.1 Úvod

Informační systémy se staly velmi důležitým prvkem každé společnosti, která po-mýšlí na úspěch v dnešním konkurenčním prostředí a možností využití takového systému je bezpočet. Využívá se například jako správa zdrojů a zakázek nebo fi-remní komunikace. S nasazením podobného systému do společnosti však vzniká potřeba plánování rozsahu prací a finančních nákladů.

Jedním z nejdůležitějších vstupů pro plánování a řízení SW projektů je odhad finančních a časových nákladů, které bude třeba vynaložit. Takový odhad může nejen poskytnout reálnější pohled na plány společnosti, které se vývojem software zabývají, ale také ujasnit představy společnostem, které o nasazení nového systé-mu do budoucna uvažují. Takové společnosti ovšem velmi ojediněle disponují zdroji, které by jim umožňovaly odhady provádět z vlastních zdrojů. U některých firem údajně panuje přesvědčení, že odhadovací proces může být příliš složitý a časově náročný pro využití na menší projekty (McConnell, 2006). I malá firma by ale měla mít možnost využít techniky odhadů a při minimálním vynaloženém úsilí a času obdržet mnohem lepší odhady nákladů nových projektů.

Tato práce se bude blíže zabývat rozborem jednotlivých metod, které by umožňovaly podpořit provádění kvalitních odhadů nákladů nasazení informačního systému i uživatelům, kteří nemají zkušenosti a zdroje pro rozsáhlé analýzy nebo je potřebují provést rychle a s minimem nákladů. V teoretickém základu této práce bude poskytnut úvod do problematiky informačních systémů, jejich vývoje a řízení. V dalších částech bude přiblížena terminologie a uveden přehled dostupných me-tod používaných k tvorbě odhadů systémů. Vyskytovat se zde bude také rozbor funkčnosti a postup tvorby odhadů pomocí jednotlivých metod.

Praktická část práce se bude věnovat návrhu aplikace založeného na vybra-ných metodách. Tato aplikace bude poskytovat odhad na základě uživatelských vstupů. Při návrhu bude dbáno na přenositelnost řešení a oproštění od konkrét-ních implementačních nástrojů. Správnost návrhu bude ověřena implementací čás-ti aplikace, kde bude kladen důraz na dodržení návrhu funkcionality.

1.2 Cíl práce

Existuje mnoho obecných technik odhadování, které by mohly společnosti využí-vat. Pro přesné odhady lze využít i historických dat reprezentující data o vlastních ukončených projektech společnosti. V případě, že taková data nejsou k dispozici, je možné použít obecné odhadovací techniky založené na algoritmických modelech kalibrovaných pomocí dat z ukončených projektů společností zavádějících podob-né systémy. Tato skutečnost se sice odrazí na přesnosti samotného odhadu, ale v prvotních fázích projektu by měl být pro začínající uživatele i přesto dostatečným vodítkem pro ucelení si představy o budoucnosti projektu.

20 Úvod a cíl práce

Cílem této práce je za pomoci znalostí získaných v teoretické části navrhnout aplikaci, která bude podporovat odhadování finančních a časových nákladů spoje-ných se zaváděním informačního systému do společnosti, a to i neodborným uživa-telům. Čtenář se v práci seznámí s problematikami vývoje informačních systémů, řízení projektů a odhadování projektů.

Vývoj informačního systému a jeho řízení 21

2 Vývoj informačního systému a jeho řízení

Dle definice v mezinárodních normách týkajících se životního cyklu systému, soft-waru a popisu architektury je systém soubor komponent účelově uspořádaných k dosažení určitého cíle nebo skupiny cílů. Systém může být obecný, tedy poskytu-jící produkt nebo službu v definovaném prostředí a uspokojující potřeby uživatelů, nebo softwarově intenzivní, kde software převažuje (Doležal, Máchal, 2012).

Informační systém je dle Voříška a spol. (2008) souborem softwaru, hardwa-ru, lidí, činností a zdrojů. Důležitým aspektem systému je ICT složka, tedy infor-mační a komunikační technologie, které usnadňují plnění účelu systému. U infor-mačního systému, kterému se proto také často říká IS/ICT, nás zajímají veškeré možné informace plynoucí z dat, ze kterých bychom mohli mít užitek (Vymětal, 2009).

V praxi se setkáváme se dvěma hlavními důvody pro zavádění informačního systému. Buďto je to informační systém jako podpůrný nástroj pro řízení, nebo je to přístup, který se snaží o co nejvýhodnější poměr cena/kvalita/přidaná hodnota systému. Pokud se někdo rozhodne využít jiného přístupu k vývoji systému, nebu-de tak efektivní a ponese s sebou velká rizika (KLČOVÁ, SODOMKA, 2009).

2.1 Přístupy k vývoji systému

Metodika zvolená pro vývoj systému, která určuje přístup k vývoji a repetitivitu jednotlivých kroků, má vliv na odhad. Přesnějších odhadů dříve dosáhneme u opa-kujících se metodik, u kterých dříve získáme historická data týkající se daného pro-jektu ke zpřesnění odhadu. Více o tomto přístupu najdete v kapitole 3.4. V rámci odhadů se uvažují postupné a opakující se přístupy k vývoji. Hlavní rozdíl mezi těmito přístupy je v procentuálním podílu definování požadavků na začátku pro-jektu (McConnell, 2006).

2.1.1 RUP

Tato metodika je charakterizována jako proces, který představuje přístup přiřazu-jící úkoly a odpovědnosti v organizaci, která se zabývá vývojem softwaru. V této metodice se mimo jiné využívá iterativního vývoje, komponentové architektury a řízení požadavků a změn (BUCHALCEVOVÁ, 2009). Každý projekt je rozdělen do 4 fází:

počáteční fáze, elaborační fáze, konstrukční fáze, fáze nasazení.

Každá fáze je ukončena milníkem s vyhodnocením splnění cílů a rozhodnutím o dalším postupu. Pro odhady je tedy uvažován tento přístup jako postupný.

22 Vývoj informačního systému a jeho řízení

2.1.2 SCRUM

Jedná se o iterativní agilní metodiku založenou na společné cestě celého vývojové-ho týmu k cíli po jednotlivých krocích, tzv. SPRINTech o maximální délce jednoho měsíce. Ty obsahují jednotlivé přírůstky hotového software, které se postupně vy-bírají ze zásobníků dříve plánovaných úkolů. Často se pořádají velmi krátké schůz-ky, kde členové týmu řeší každodenní problémy při vývoji systému (BUCHALCE-VOVÁ, 2009). Z pohledu jednotlivých SPRINTů se jedná o postupný odhad, v širším pohledu, kdy mezi jednotlivými sprinty nejsou známy další požadavky, se ovšem jedná o postup opakovaný (SUTHERLAND, 2014).

2.1.3 Prototypování

K vývoji informačních systémů zpravidla patří i vysoké finanční náklady rozloženy na dlouhé časové období, ať už se jedná o strukturovaný nebo objektový přístup. To vedlo k tomu, že se nejprve začalo využívat metody prototypů. Ty dokážou rychle vyvinout základní funkce, které byly předvedeny uživateli (RÁBOVÁ, 2008). Mezi hlavní výhody patří:

Zapojení uživatelů v brzkých fázích vývoje. Možnost přizpůsobování vedlejších funkcí dle uživatelských připomínek ve fá-

zi testování hlavních funkcí aplikace. Větší kontrola nad plněním plánu vývoje.

Mezi hlavní nevýhody prototypování patří:

Mnohdy není kladen dostatečný význam dokumentaci. Nebezpečí neorganizovaného vývoje při nedostatečném plánování. To by

mohlo vést k zavádění chyb do vyzkoušených funkcí nebo zavádění funkcí bez dostatečného provázání se zbytkem funkcí aplikace.

Často se uživatel mylně domnívá, že se projekt nachází v pokročilejší fázi.

Z pohledu odhadů se jedná o opakující se přístup.

2.1.4 Extrémní programování

Metoda extrémního programování je založena na extrémním provádění obdobných úkonů jako při ostatních metodách. Neustále se reviduje zdrojový kód pomocí pá-rového programování, aplikace se opětovně testuje vývojáři i zákazníkem, každo-denně se navrhují nové postupy, tzv. refaktorizace ve velmi krátkých iteracích. (Buchalcevová, 2009) Mezi hlavní principy této metody se řadí:

Programování pouze aktuálně nejdůležitějších částí za neustálého zjednodu-šování.

Spolupráce s uživatelem nebo jeho zástupcem a využívání zpětné vazby. Maximální využití iterativního postupu.

U odhadů extrémního programování se jedná o často se opakující přístup.

Vývoj informačního systému a jeho řízení 23

2.2 Fáze vývoje informačního systému

Odhad softwarového projektu je úzce spjatý s fází, ve které se právě odhadovaný projekt nachází. Vývoj a realizaci informačního systému můžeme rozdělit na dvě části: projekční a implementační (Vrana, Richta, 2005).

U projekční fáze se zejména snažíme o sběr a analýzu požadavků klienta a rozhodujeme o způsobu naplnění těchto požadavků. U implementační fáze se již snaha z předchozí fáze přeformuluje do reálného výstupu v podobě samotného systému a následně se zavádí do provozu (Basl, 2012).

Zjednodušený a obecně vzatý přehled činností prováděných při zavádění in-formačního systému, který by bylo možno aplikovat všemi přístupy, je možné vní-mat následovně:

1. Prvním krokem je tzv. úvodní studie, která se také nazývá zadání. Zde se popi-suje záměr, rozsah funkčnosti, termíny a rozpočet.

2. Zachycení požadavků na systém týkajících se funkčnosti, designu, návaznosti na jiné systémy, integrace s ostatními systémy, reakční doby atd.

3. Tvorba konceptuálního modelu (zachycení skutečností v rámci modelu).

4. Tvorba implementačního modelu (jedná se již o konkrétní návrh IS).

5. Implementace a zavedení.

6. Testování.

7. Udržování systému a provoz.

2.3 Projektové řízení

Projektem rozumíme časově omezenou a organizovanou činnost za účelem dosa-žení cíle. Jasně určeny by měly být cíle projektu, časový rozsah, zdroje a postup vypracování. To ovšem není vždy jednoduché určit (Rosenau, 2010).

Řízením projektu rozumíme využívání všech dostupných poznatků, nástrojů a dovedností tak, aby byly splněny požadavky kladené účastníky na projekt. Úkolem manažera projektu je tedy splnit předem určený plán a dokázat jej spojit s prezen-tovaným odhadem (Schwalbe, 2011).

Důležitým faktorem pro úspěšné projektové řízení je mít přístup k odhadu, který se co nejvíce blíží realitě. Zejména z důvodu, že hlavní omezení, která na pro-jekt působí, jsou náklady, čas a rozsah, je třeba co nejdříve mít jasnou představu o těchto veličinách. Ne jen v úvodu projektu, ale i v jeho průběhu, významně ulehčují správně odhadnuté veličiny projektu úlohu projektovým vedoucím (Vytlačil, 2008). Stejnou ne-li důležitější funkci plní právě projektové řízení v ohledu na správnost odhadu. Sebelépe provedený odhad je totiž závislý na správnosti projek-tového řízení, a pokud toto projekt a jeho vedení nesvedou, je odhad, jak bude pro-jekt probíhat a jaké zdroje bude potřebovat, jen velmi obtížný (Řepa, 2008).

24 Odhady a jejich přínosy


3.1 Proč odhad?

Ve většině případů je před počátkem vývoje softwaru potřeba udělat kalkulaci. Pro kalkulaci je potřebné mít plán. A aby bylo možné plán navrhnout, popř. začít se sliby, kdy bude projekt hotový, je nezbytné odhadnout, za jak dlouho je daný soft-ware možné vyvinout.

3.1.1 Co je to odhad?

Mezi odhadem a plánem je tedy nutné rozlišovat, neboť se jedná o rozdílné pojmy. Plán je nutné vytvářet s jasnými cíli a měl by obsahovat, jak daného cíle dosáhnout. Odhad by měl reprezentovat realitu a bez zaujetí analyzovat, kdy je možné dosáh-nout v konkrétní situaci výsledku bez snahy o konkrétní výstup.

3.1.2 Dobrý odhad

Ve většině případů není zvolen správný přístup k požadavkům na odhady. Není možné v prvotních fázích projektu poskytnout jasnou a přesnou představu o ceně a délce projektu okamžitě. Nedostatek informací zatěžuje prováděné výpočty a předpovědi chybou, která se velmi těžce odstraňuje.

Pro budoucí zlepšení a úsudky nad správností prováděných odhadů je velmi vhodné mít možnost, odhady porovnat. A to není vzhledem ke komplexnosti, množství kategorií a různým reprezentacím rizik jednoduchý úkol. Stejný případ nastává při snaze o srovnání aktuálních odhadů s historickými daty. Je proto třeba při tvorbě odhadů vždy dodržovat pevně danou strukturu a mít jasně určený obsah jednotlivých kategorií. To ulehčí revidování, porovnání, i zpětnou analýzu vzhle-dem k reálně získaným hodnotám.

Dobrý odhad by měl procentuálně vyjadřovat pravděpodobnost dokončení v určitém časovém nebo finančním rozsahu. Pro následující průběh plánování a vývoje je důležité vědět, jak pravděpodobné je dokončení činnosti na softwaru v daném termínu. Mělo by se respektovat, že odhady jsou nepřesné a různé termí-ny budou mít různou pravděpodobnost dokončení, což lze reprezentovat křivkou na Obr. 1. Zatímco nejdříve možný termín dokončení je možné odhadnout, událostí, které mohou teoreticky tento termín oddálit, je nespočet a pravá část křivky je te-dy protažena do nekonečna.

Odhady a jejich přínosy 25

Obr. 1 Křivka představující pravděpodobnost dokončení projektu (Atreya, 2011)

Dle McConnella (2006) by měl dobrý odhad poskytovat dostatečnou představu o reálném projektu, aby jeho vedení mohlo provádět správná rozhodnutí a dopo-moct mu tak k dosažení cíle.

Dle Stutzke (2005) je nejčastějším standardem pro dobrý odhad považovaný takový odhad, který v 75 % příležitostí odhadne projekt v rozmezí 25 % od sku-tečnosti. Pravidlo devadesát na devadesát:

Prvních 90 procent kódu odpovídá prvním 90 procentům času vývoje. Zbývají-cích 10 procent kódu odpovídá dalším 90 procentům času vývoje.1

3.2 Charakteristiky odhadů

Dvě nejdůležitější vlastnosti metod jsou přístup a užitečnost. To jsou základní charakteristiky, které je třeba uvažovat při výběru vhodné metody jako první, byť samozřejmě samy o sobě pro rozhodnutí nestačí. Z těchto vlastností je nejviditel-nější, zda jde o odhad shora-dolů nebo zdola-nahoru. To je zásadně určeno výcho-zími předpoklady a aktuální fází projektu a zásadně také ovlivňuje výsledky a přesnost odhadu.

1 Tom Cargill, Bell Labs


3.2.1 Přesnost odhadů

Při tvorbě odhadů se setkáváme s tzv. kuželem nejistoty. Ten představuje projekt v různých fázích vývoje, a čím více se blíží svému konci, tím přesnějšího odhadu lze dosáhnout. Z tohoto kuželu vyplývá, že v úvodní analýze se odhad může od statis-tik lišit až čtyřnásobně oproti skutečnosti v obou směrech. Nadcenění je z pohledu dodavatele méně závažný problém než podcenění. V případě provádění odhadů v brzkých fázích je tedy v pořádku, pokud uvedeme větší rozsah, který lze realis-ticky odůvodnit (PROFINIT, 2013).

Obr. 2 Kužel nejistoty (Jůza, 2012)

Hofstadterův zákon: Každá činnost vždy zabere více času než by se čekalo, dokonce i v případě, kdy zapo-čítáte Hofstadterův zákon.2 Ani delší časové období poskytnuté pro vytvoření odhadu nepomůže snížit nejisto-tu v poskytovaném odhadu. Dle McConella (2006) průzkumy ukázaly, že přesnost

2 Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid

Gödel, Escher, Bach: An Eternal Golden Braid. 20th anniversary ed., 1999, p. 152. ISBN 0-465-

02656-7.


odhadů závisí na úrovni rafinovanosti definice softwaru. Propracovaněji definova-né aplikace mají přesnější odhady. Důvodem variabilní složky odhadu je, že tuto variabilitu obsahuje již projekt samotný. Jedinou možností, jak snížit variabilitu odhadu je snížit ji v samotném projektu.

Přesnost odhadu tedy záleží na více než jednom faktoru a nejsilněji jej ovliv-ňují právě:

funkce vybrané metody, správnost aplikace zvolené metody na řešený problém, moment aplikace zvolené metody ve vývojovém stupni projektu.

3.2.2 Konzistentnost

Pro případ, kdy by bylo potřebné odhady zpětně revidovat a ověřit tak například správnost původních předpokladů, je třeba, aby byly odhady vytvářeny konzis-tentně. Primárně by měly být proto využívány přístupy, které lze snadno a konzis-tentně opakovat. Takovým typem jsou zejména výpočetní metody. U algoritmic-kých metod by proto měla zachovávat opakovatelnost algoritmu.

3.2.3 Užitečnost

Užitečnost metodik se určuje zejména dle 3 základních vlastností:

Přizpůsobitelnost – Určuje jednoduchost přizpůsobení dané metodiky k po-užití v konkrétním případě. V rychle se měnících prostředích se také využije možnost aktualizace modelu nebo postupu o nové analytické techniky a me-todiky.

Pružnost – Za velmi pružnou metodiku můžeme označit takový postup, kte-rým lze stejně vhodně odhadovat malé a krátkodobé úkoly stejně jako velké a rozsáhlé. Dále lze pružnost metodik určit dle možnosti jejího použití v různých prostředích. Nižší pružnost pak snižuje i užitečnost dané metody. V konkrét-ních situacích je specifičnost metody ovšem výhodou.

Efektivita – U metodik, které lze ohodnotit jako efektivní, by nemělo být ob-tížné pochopit jeho použití. U aplikací, které podporují modely, by tuto vlast-nost měly splňovat aplikace, které jsou jednoduché k použití, a jejich výstup lze jednoduše pochopit.

3.3 Metriky odhadů

Metrika softwaru je standard, pomocí kterého se dá určit vlastnost aplikace nebo systému. Jedná se o objektivní a počitatelnou reprezentaci vlastností prvku. Počí-tání této reprezentace se obecně nazývá měřením, z něhož dostaneme výsledné hodnoty. Počitatelná měření a srovnání jsou velmi důležitá pro všechny vědní obo-ry, a proto se podobného postupu používá i při vývoji software. Cílem měření je získat objektivní, opakovatelné a počitatelné zástupce vlastností systému, kteří by


se dali dále použít při plánování, odhadování, odstraňování chyb, testování a dal-ších činnostech (Učeň, 2001).

Obr. 3 Přehled reprezentací vlastností systému v různých fázích vývoje (Hansen, 2012)

3.3.1 Počítání řádků kódu

Řádky zdrojového kódu (jinak též LOC = lines of code, též SLOC = Source LOC) je mezí ostatními metodami jednou z nejrozšířenějších a nejstarších. Snadný výpočet všech řádků kódu v celé aplikaci napříč všemi moduly a všemi funkcemi ji řadí me-zi jednoduše zjistitelné metriky v konečných fázích projektu. Na její výpočet slouží jednoduché nástroje, je ale potřeba dodat hotové zdrojové kódy. Ač je spočítání řádků akcí jednoduchou, výsledky se mohou napříč programy různit vzhledem k neucelené představě o tom, co vše by se mělo za kód považovat. Některé progra-my mohou započítat například komentáře. Různí programátoři navíc velmi často napíší funkčně srovnatelný kód v různé délce.

3.3.2 Funkční celky

Korelativním přístupem k LOC představující velikost odhadovaného systému jsou tzv. funkční celky, funkční body neboli Function Points. Tato metrika umožňuje měření velikosti softwaru (popř. jeho částí) nezávisle na použitých vývojových ná-strojích. Metrika se zaměřuje na funkčnost, kterou by měla odhadovaná aplikace obsahovat a je proto vhodnější pro rané fáze projektu. Lze ji jednoduše určit již z požadavků uživatele, je ale potřeba mít jasnou představu o konečné funkčnosti systému. Mezi nevýhody je možné zařadit nemožnost použití automatizace počítá-ní funkčních celků v podobě, jakou známe u počítání řádků kódu (GARMUS, 2000).

3.3.3 Případy užití

Za metriku představující velikost systému lze považovat i případy užití (HANSEN, 2012). Použití této veličiny je možné ještě v dřívějších etapách vývoje systému než při použití počtu řádků kódu nebo i funkčních celků (GARMUS, 2000).


3.3.4 Lidská práce za jednotku času

Při odhadech pracnosti projektu je obvyklé vyjadřovat tuto hodnotu v čase, který zabere v závislosti na jednoho člověka. Tato metrika se dle časového období, které uvažujeme, nazývá člověkohodina, člověkoden nebo a člověkoměsíc, popř. v dlouhých časových intervalech i člověkorok.

Jedná se o důležitou vlastnost pro plánování, odhad a případnou alokaci dal-ších zdrojů v případě potřeby.

3.4 Kalibrace dat

Kalibrace je mocný nástroj ke zpřesnění odhadu. Použít se dají data podobného projektu ze stejného odvětví, data historická z jiných projektů společnosti a data z již dokončených částí odhadovaného projektu.

Data z odvětví – vylepšení odhadovaných veličin dospějeme použitím dat ji-ných společností, které již měly možnost podobný projekt vytvářet. Odhalí se mnohá úskalí a ucelí se přehled, jak dlouho mohou některé činnosti skutečně zabrat.

Historická data – krokem blíž k přesným odhadům je použití dat naší společ-nosti na již ukončených projektech. V případě, že se jedná o podobný projekt se stejnými účastníky zasahujícími do vývoje, budou tyto odhady mnohem přesnější.

Projektová data – největší zpřesnění dosáhneme použitím dat z již probíhají-cího projektu. Je z nich jasné, jakou výkonnost mohou pracovníci poskytnout a jakým tempem se projekt do nynějška pohyboval vpřed.

Ke zlepšení odhadu při použití historických dat organizace dochází, protože tato data dokáží vnést hodnotu vlivů v patřičné organizaci. Zejména pak schopnosti a kompetence projektového týmu. Dobrá data tedy dokáží přiblížit, zda:

Je vývojový tým stabilní a projektový manažer má pravomoc odvolat problé-mové členy.

Jsou požadavky na vývoj neměnné v průběhu projektu. Bývají projektové týmy soustředěné na jednu úlohu nebo musejí souběžně vy-

víjet více projektů. Podporuje organizace efektivní a jasně dané postupy.

Data, která lze shromažďovat z minulých projektů mohou být:

velikost projektu, množství práce, spotřebovaný čas, počet chyb.

Tato data začínají být dle McConnella (2006) efektivní od 3 hotových projektů a pomohou také s určením hodnot přepočtů práce zaměstnanců na měsíc.


3.5 Používané metodiky pro odhad

Existuje mnoho způsobů, jak k odhadům přistupovat. Může to být cestou zkušenos-tí, které nasbírali odborníci ve svých oborech, mohou to být data uložená v databázi nebo například porovnávání modelů jednotlivých projektů s odhadem založeným na jejich podobnostech.

Tato kapitola bude přibližovat způsob tvorby odhadu kombinací vstupních parametrů těch nejpoužívanějších z nich.

Mezi hlavní postupy, se kterými je možné se setkat ve všech metodikách je přístup shora-dolů (top-down) a přístup zdola-nahoru (bottom-up). Tyto přístupy určují, zda se celek rozdělí na dále již nedělitelné části, které se odhadnou, a jejich spojením vznikne odhad kompletního systému, nebo zda se odhadne celek. Každá z možností má svá pro a proti. Pro odhad počátečních fází velkých projektů se hodí spíše metoda shora-dolů, zatímco pro odhad pozdních fází velkých projektů nebo malých projektů je vhodnější přístup zdola-nahoru, kdy se na odhadech podílejí jedinci, kteří na projektu budou skutečně pracovat. Každý tak nejpřesněji odhadne svou část.

3.5.1 Metody s použitím analogie

Analogie značí, že odhadovaný projekt budeme srovnávat s jiným, již dokončeným projektem. Tento postup je úspěšný v případě, že máme dostupných dostatek srovnávacích projektů, ze kterých lze vybrat ten nejpodobnější a také co nejpo-drobnější rozbor veličin těchto projektů.

V případě odhadování použitím analogie je nutné nejprve získat co nejde-tailnější obraz srovnávaného projektu s údaji o velikosti, množství práce a cenách. Poté srovnat velikosti projektů v co možná nejnižší úrovni. To znamená ne jako celek, ale jednotlivé části projektů. Toto srovnání poté vyjádřete procentuálně v poměru mezi sebou. Nakonec je nutné vytvořit odhad nového projektu v závis-losti na předchozím, přičemž je třeba kontrolovat soulad předpokladů.

Výsledný odhad nově odhadovaného systému tedy bude tvořit odhad před-chozího systému vynásobený zjištěným poměrem mezi nimi. Velké odchylky mo-hou nastat zejména kvůli práci jiného týmu vývojářů, rozdílnosti použitých jazyků nebo použitím nevhodného projektu pro srovnání.

3.5.2 Metoda s použitím zástupce

Využití zástupce pro odhady je vhodné zejména pro ulehčení odhadu velikosti softwaru. Odhadnout přesně počet řádků celého informačního systému je možné jen velmi zřídka s požadovanou přesností. Odhadnout ovšem například počet funkcí, a zda se jedná o funkci velkou nebo malou, již možné je a pomocí průměr-ných hodnot, vypočtených za pomocí historických dat, nám poskytne relativně přesné odhady.

Fuzzy logika hraje v používání zástupců hlavní roli a jsou primárním zjedno-dušením při odhadování právě velikosti systému. Pomocí fuzzy logiky je vybraná veličina rozdělena do množin, kdy každé je přiděleno fixní číslo reprezentující


průměrné hodnoty pro tuto množinu. To znamená, že není třeba přidělit každé veličině svůj odhad, ale pouze danou vlastnost systému přidělit do množiny.

Průměrné hodnoty by měly být přiděleny již před začátkem odhadování jako fixní představitelé dané hodnoty v množině. Nejvhodnější je tuto hodnotu vypočí-tat z historických dat organizace. Dle Putnama a Meyerse (1992) by rozsah mezi dvěma průměrnými hodnotami v množině měl být řádově dvojnásobný až čtyřná-sobný. To znamená, že pokud bude první hodnotu v množině reprezentovat prů-měr 200, druhou hodnotu ve skupině by nemělo reprezentovat číslo nižší než 400–800.

Přitom je třeba sledovat, zda rozsah určený před odhadem a rozsah vnímaný uživatelem je stejný. To se nejjednodušeji docílí tak, že uživatel bude vědět, jaký rozsah je v aplikaci nastaven a měl by mít možnost toto nastavení ovlivnit. V případě, že nejsou komplexní historická data dostupná nebo v případě, že navr-hujete architektonicky podobné aplikace, je možno využít i tzv. Standardní kom-ponentu. Ta by částečně nahrazovala vypočtenou průměrnou hodnotu. Odhad by se týkal počtu funkcí o rozdílných velikostech. Odhady by se poté propojily pomocí vzorce PERT. Pod touto zkratkou se skrývá metoda pro vyhodnocování a kontrolu programu (Program Evaluation and Review Technique).

in ( )

Kde:

OPK je zkratkou pro Odhadovaný počet komponent MinP je zkratkou pro Minimální možný počet NP je zkratkou pro Nejpravděpodobnější počet MaxP je zkratkou pro Maximální možný počet

Ve vzorci se celková hodnota dělí 6. V tomto případě, kdy hledáme očekávanou hodnotu, nemusíme řešit dělení jiným číslem jako u standardní odchylky.

Metoda standardních komponent ušetří mnoho času při raných fázích projek-tu a vzhledem k očekávané nepřesnosti v těchto fázích je možné jí využít. Aby dob-ře fungovala, doporučuje se použít historická data z minimálně 10 předchozích projektů (McConnell, 2010).

Jako další možnost využití fuzzy logiky můžeme brát Uživatelské příběhy neboli Story Points. U této metody se odhadují větší celky, které jsou týmem při-dělujícím jim bodové ohodnocení z vybrané škály. Toto ohodnocení může používat například škálu mocnin čísla 2 nebo Fibonacciho posloupnost. V dalším plánování se poté počítá spíše s bodovým ohodnocením a plánuje se, kolik bodů bude možno dodat v časovém intervalu. Po dokončení úvodní fáze může dojít ke zpřesnění v rámci projektu, kdy se shrne počet dodaných bodů v rámci vynaloženého času a úsilí. Velmi dobře se popsané metody využije při krátkých iteracích, kdy se brzy docílí kýžené zpřesnění odhadu.

Při použití číselné škály je třeba dbát na možnost, kdy o stupeň vyšší číselné ohodnocení nebude odpovídat poměru koeficientů mezi hodnotami. V takovém


případě může dojít ke zmatení odhadovatele a snížení platnosti výpočtů a je vhod-nější využít rozdělení do slovních kategorií.

Posledním často používaným druhem rozdělení hodnot pomocí fuzzy množin se nazývá konfekční velikost neboli T-shirt sizing. To se využívá v brzkých fá-zích vývoje, kde ještě není jisté, které části aplikace mají být implementovány. Vyu-žívá se při ní ohodnocení jednotlivých funkcí pomocí konfekčních velikostí – S, M, L a XL. K tomuto ohodnocení dojde celkově dvakrát, ze strany vývoje a ze strany marketingu. Jedno ohodnocení bude tedy reprezentovat obchodní hodnotu a druhé pak cenu vývoje. Netechničtí uživatelé poté dojdou ke snadnějšímu závěru, zda se funkce vyplatí. K tomu se využívá číselné ohodnocení, které bude nejvyšší pro lev-né a důležité části aplikace a nejnižší pro drahé a postradatelné funkce.

3.5.3 Metoda expertních odhadů

Expertní odhady jsou založené na úsudcích expertů a mohou být skupinové nebo individuální. Pro individuální je napříč všemi zdroji doporučováno, aby odhad da-né aplikace tvořil vývojář dané funkce, nikoli odhadovatel sám, který má zásadně vyšší sklony k podhodnocení jednotlivých úkolů. V prvotních fázích projektu, kdy jednotlivé úkoly nebyly dosud rozděleny, by to měl být odhadovatel sám.

Odhady se nejlépe odhadují po rozložení úkolů na úroveň takového detailu, kdy jedna odhadovaná část je nanejvýš v rámci několika dnů, ideálně pak nanejvýš jednoho dne. Tento odhad by měl uvažovat vždy dvě hodnoty, a to odhad nejlepší-ho případu a případu, kdy se pokazí úplně vše. To často vede uvědomení si aktivit, na které by se jinak nepřišlo.

Z nejoptimističtějších a nejpesimističtějších odhadů poté můžeme odvodit očekávaný případ, a sice vzorcem PERT uvedeným v kapitole 3.5.2.

Očekávaný odhad = [Nejoptimističtější odhad + (4x Nejpravděpodobnější odhad) + Nejpesimističtější odhad] / 6

Důležitým krokem po provedení odhadů je jejich srovnání s realitou, při kterém je možné ohodnotit své odhady a postupně je vylepšovat. K tomu se používá následu-jícího vzorce:

V V V

V

Kde:

VRCH = Velikost relativní chyby odhadu AM = Absolutní měřítko SV = Skutečný výsledek OV = Očekávaný výsledek


3.5.4 Skupinové hodnocení

Cílem metody skupinového hodnocení je zvýšení přesnosti expertního odhadu provedeného jednotlivci. Základem je tedy provést několik individuálních odhadů, které se poté zvoleným způsobem porovnají a vytvoří se jeden, který bude přes-nější. Čím důkladnější bude diskuze při porovnávání rozdílností odhadů, tím přes-nější bude výsledný odhad. Není vhodné pouze zprůměrovat poskytnuté odhady, ale provést podrobnější analýzu rozporů. Na výsledném odhadu by se měli podílet všichni původní odhadovatelé a všichni by také měli odsouhlasit konečný odhad. Nejvhodnější pro tvoření odhadů touto formou je dle McConnella (2006) spojit alespoň 3 experty s různou průpravou používající různé metody.

Jednou z využívaných metod, která popisuje strukturovaný přístup k řízení skupinových hodnocení je Wideband Delphi. Je vytvořena ze starší metody Delphi, která udávala svolání odborníků, kteří vytvořili vlastní odhady a v diskuzi je poté srovnávali a upravovali, dokud nedošli ke stejnému výsledku, který byl všemi účastníky přijat. Modernější Wideband metoda čítá celkem 8 kroků, které se mohou velmi často opakovat a snaží se o eliminaci politického tlaku na odhadova-tele a prosazení méně asertivních typů osob. Nejvýznamnější změnou je anonymita individuálních odhadů a následného hlasování o přijetí průměrného odhadu. K finálnímu jednočíselnému odhadu je poté třeba dojít jednohlasným odsouhlase-ním.

U této metody není třeba uplatňovat skupinového osobního setkání, jde při ní využít i elektronické komunikace, popř. individuálních setkání. Komunikaci ale vypustit z této metody nejde a vzhledem jejímu množství se jedná o nákladnou metodu odhadů a není vhodné ji používat pro specifický odhad jednotlivých úkolů.

34 Algoritmické přístupy k odhadům


Algoritmické metody využívají výpočtu odhadů na základě matematických funkcí, které jsou založeny na empirickém zpracování historických dat. U většiny těchto metod jsou základem vstupní parametry a jejich ohodnocení. Odhad pomocí algo-ritmických modelů lze vytvořit i bez použití odhadovacího software, který daný model implementuje, nicméně použití takového nástroje je díky ušetřené práci výhodnější.

Nejdříve si představíme metody pro odhad velikosti systému, poté jeho prac-nosti, časového harmonogramu a nakonec i ceny. Uvedeny zde budou i metody, které jsou na základě historických dat schopny poskytnout odhad všech těchto ve-ličin.

4.1 Putnamův model

Putnamův model byl vyvinut Larrym Putnamem už na konci sedmdesátých let. Tento model je základem i modelu SLIM (Software Life Cycle Model), který je ale proprietární a pro jeho použití je potřeba zakoupit SLIM software. Klasický Put-namův model je jednodušší než třeba COCOMO II (PUTNAM, 2003). Pro výpočet úsilí se nejčastěji používá v uvedeném tvaru:

[

]

Pracnost představuje celkovou pracnost v člověkoměsících. Velikost projektu může být určena v různých jednotkách, například ESLOC (Effective Source Lines of Co-de). Produktivita je schopnost organizace vytvořit systém specifické velikosti s určitou úrovní chybovosti. Čas je určením rozvrhu projektu v měsících. Proměnná B představuje měřítko velikosti zjištěné funkcí velikosti projektu.

4.2 Cocomo II

Dvojka v názvu této metody představuje přepracovanou verzi původní metody Cocomo (nyní se pro odlišení označuje jako Cocomo 81) vytvořenou roku 1981 Barry W. Boehmem. Pro porovnání jednotlivých verzí modelu doporučuji (Al-bakri, 2012), kde je přehledné porovnání včetně analýzy jejich efektivity. Ke změ-nám v novém modelu, který plně nahrazuje původní, došlo zejména z důvodů vý-voje nových technik v oboru vývoje software a Cocomo (Constructive cost model) s těmito změnami muselo držet krok (Codeproject, 2005). Nový model byl aktuali-zován zejména s cílem být evoluční a může být dle aktuálních potřeb změněn. To s sebou nese další označení, jež berou v potaz i aktuální verzi metody. Verze z roku 2000 se nazývá COCOMO II.2000.

lgoritmické přístupy k odhadům 35

Základem metody je regresní funkce odvozená od analýzy dat mnoha projek-tů. Vstupem této metody jsou řádky kódu odhadovaného systému. Rozdělit lze na dva pod-modely: Early Design model (EDM) a Post-Architecture model (PAM). První z nich lze vhodně využít zejména ve fázích projektu s méně daty o samotném projektu, kdy například není jasná architektura softwaru. Druhý z nich je podrob-nější verzí, která je aplikovatelná na pozdější fáze vývoje systému. Výpočty těchto pod-modulů jsou si podobné.

V případě, že probíhá vývoj odhadovaného systému pomocí moderních RAD technik, existuje pro tento účel Application Point model (APM) jako rozšíření mo-delu COCOMO.

4.2.1 Early Design a Post-Architecture model

Oba tyto modely používají pro výpočet velikosti odhadovaného systému stejný postup výpočtu a odlišují se tak právě v množství vyžadovaných vstupů. Oba mo-dely jsou určeny vzorci pro výpočet úsilí a celkové doby trvání projektu:

Veliko t ∑ Ú

∑

Úsilí zde označováno jako ČM (člověkoměsíce) využívá ke svému výpočtu několik proměnných a konstanty. Velikost je určena v tisících řádků kódu (KSLOC). Hlav-ními způsoby zjištění této hodnoty jsou např. pomocí analogií, automatických pro-gramů pro počítání již vytvořeného kódu nebo převodu z funkčních celků, viz Tab. 6.

Použité konstanty A a B nabývají v této verzi metody hodnot A = 2.94 a B = 0.91. Faktorů velikosti (FV) je celkem pět a určují relativní ekonomické a neeko-nomické faktory pro projekty různých velikostí. NÚ jsou násobiče úsilí, kterých je 17 u modelu Post-Architecture a 7 u modelu Early Design. Veškerým faktorům se přiřadí hodnota vlivu, a to buď velmi nízká (VL), nízká (L), nominální (N), vysoká (H), velmi vysoká (VH) a případně u některých extra vysoká (XH). Hodnoty vlivu, které lze přiřadit jednotlivým faktorům, jsou uvedeny v tabulce níže. Konkrétní hodnoty NÚ a faktorů velikosti jsou uživatelem určeny dle vlastností projektu a vývojového prostředí. Exponent velikost E určuje ekonomické hledisko měřítka.

Přehled faktorů velikosti naleznete v tabulce níže. Faktory velikosti jsou shodné pro oba modely metody. Násobitelé modelu Post-Architecture se dále dělí do oblastí, kterých se týkají.


Tab. 1 Přehled jednotlivých faktorů a jejich popis

Typ faktoru Označení a název faktoru Popis faktoru

Faktory velikosti

PREC - Precedentedness Míra zkušenosti s

podobnými projekty

FLEX - Development

Flexibility Flexibilita vývoje

RESL - Architecture / Risk

Resolution

Řešení architektury a

rizika

TEAM - Team Cohesion

Soudržnost týmu

(podobné cíle,

zkušenosti, firemní

kulturu)

PMAT - Process Maturity Vyspělost procesu

Faktory modelu Post-Architecture

Vlastnosti produktu

RELY - Required Software

Reliability

Požadovaná spolehlivost

SW

DATA - Database Size Velikost databáze

CPLX - Product Complexity Složitost produktu

RUSE - Developed for

Reusability

Vývoj znovupoužitelného

kódu

DOCU - Documentation Adekvátnost rozsahu

dokumentace

Vlastnosti platformy

TIME - Execution Time

Constraints

Omezení na použitý

strojový

čas

STOR - Main Storage

Constraint

Omezení na využití

paměti počítače

PVOL - Platform Volatility Proměnlivost platformy

Charakteristiky lidí

ACAP - Analyst Capability Schopnosti analytiků

PCAP - Programmer

Capability Schopnosti programátorů

PCON - Personnel

Continuity Trvanlivost zaměstnanců

APEX - Application

Experience

Zkušenosti s vývojem

typu systému

PLEX - Platform

Experience

Zkušenosti s danou

platformou

LTEX - Language and Tool

Experience

Zkušenosti s

programovacím jazykem

a nástroji


Vlastnosti projektu

TOOL - Use of Software

Tools

Stupeň použití

softwarových nástrojů

pro vývoj

SITE - Multisite

Development Vývoj na více místech

SCED - Required

Development Schedule

Požadovaný termín

dokončení

Faktory modelu Early Design

RCPX - Product Reliability

and Complexity

Kombinace

multiplikátorů RELY,

DATA, CPLX a

DOCU

RUSE - Developed for

Reusability Stejný jako v PA modelu

PDIF - Platform Difficulty

Kombinace

multiplikátorů TIME,

STOR a PVOL

PERS - Personnel

Capability

Kombinace

multiplikátorů ACAP,

PCAP a PCON

PREX - Personnel

Experience

Kombinace

multiplikátorů APEX,

PLEX a LTEX

FCIL - Facilities

Kombinace

multiplikátorů TOOL a

SITE z PA modelu

SCED - Required

Development Schedule Stejný jako v PA modelu

Zdroj: Boehm, 2000

Všechny tyto hodnoty se hodnotí v rozsahu šesti hodnot dle tabulky níže. V přípa-dě, že je vliv násobitelů normální, je jeho hodnota 1 a nebude tak ovlivňovat celko-vé úsilí.


Tab. 2 Hodnoty faktorů metody Cocomo II

FAKTOR TYP VL L N H VH XH

PREC SF 0.5 0.04 0.03 0.02 0.01 0

FLEX SF 0.5 0.04 0.03 0.02 0.01 0

RESL SF 0.5 0.04 0.03 0.02 0.01 0

TEAM SF 0.5 0.04 0.03 0.02 0.01 0

PMAT SF 0.5 0.04 0.03 0.02 0.01 0

RELY EM 0.75 0.88 1 1.15 1.4

DATA EM

0.94 1 1.08 1.16

CPLX EM 0.75 0.88 1 1.15 1.3 1.65

RUSE EM

0.89 1 1.16 1.34 1.56

DOCU EM 0.85 0.93 1 1.08 1.17

TIME EM

1 1.11 1.3 1.66

STOR EM

1 1.06 1.21 1.56

PVOL EM

0.87 1 1.15 1.3

ACAP EM 1.5 1.22 1 0.83 0.67

PCAP EM 1.37 1.16 1 0.87 0.74

PCON EM 1:26 1.11 1 0.91 0.83

AEXP EM 1.23 1.1 1 0.88 0.8

PEXP EM 1.26 1.12 1 0.88 0.8

LTEX EM 1.24 1.11 1 0.9 0.82

TOOL EM 1.2 1.1 1 0.88 0.75

SITE EM 1.24 1.1 1 0.92 0.85 0.79

SCED EM 1.23 1.08 1 1.04 1.1

Zdroj: Boehm, 2000

Výpočet doby trvání projektu je vypočítán dle níže zobrazených rovnic.

V

∑ ( )

Konstanty C a D nabývají ve verzi COCOMO II.2000 hodnot 3,67 a 0,28.

4.2.2 Možnosti přizpůsobení modelu konkrétní organizaci

Možnosti přizpůsobení metody COCOMO II umožňují dosáhnout ještě lepších vý-sledků odhadu. Celkem lze metodu přizpůsobit třemi způsoby.

Kalibrace modelu pomocí vlastních historických dat spočívající v úpravách hodnot konstant.


Přidání nových redundantních multiplikátorů úsilí. Odstranění redundantních multiplikátorů úsilí.

Specifická kalibrace konstant A a B je nejvýznamnější z možností přizpůsobení. Kalibrace se provádí pomocí historických dat.

4.3 Metoda bodů případů užití (Use Case Points)

Popsal ji roku 1993 Gustav Karner. Hlavní výhodou této metody je její nezávislost na programovacích jazycích. Jedná se o techniku předpovědi velikosti softwarové-ho projektu při použití UML (Rational Modeling Language) a RUP (Rational Unified Process) na návrh a implementaci aplikace. Metoda je založena na případech užití, které reprezentují požadavky aplikace, a ohodnocení jejich složitosti. Výstup me-tody lze použít pro výpočet odhadu pracnosti projektu.

4.4 Analýza funkčních celků (FPA)

Od roku 1979, kdy Allan Albrecht představil tehdy novou metodiku odhadů v IBM, se stále tento model analýzy funkčních celků používá. Je založen na měření funkci-onalit konečného kódu aplikace nabízeného uživateli na rozdíl od Cocomo, kde se počítají řádky kódu. Funkční požadavky jsou rozděleny do pěti kategorií:

externí vstupy, externí výstupy, externí dotazy, interní logické soubory, externí soubory rozhraní.

Identifikovaným funkcím jsou poté přiřazeny funkční celky. Naměřené hodnoty mohou být poté použity pro odhad celkových nákladů. Postup odhadu se dá dle Garmuse (2000) rozdělit do následujících výpočtů a stanovení:

1. typ aplikace - nová, upravovaná, hotová,

2. rozsahu a hranic aplikace,

3. datových funkcí,

4. transakčních funkcí,

5. stanovení neupravených funkčních celků,

6. vliv obecných charakteristik systému,

7. upravených funkčních celků.

4.4.1 Hlavní komponenty

Nejprve je nutné určit hlavní komponenty systému rozdělením funkcí na 5 dříve zmíněných hlavních kategorií. Ty určují hranice systému s jeho okolím, které musí být definovány před rozdělením komponent. Hranice je určena z pohledu uživatele


a rozděluje tak funkce v měřené aplikaci od těch externích. Tyto funkce je možné rozdělit na transakční a datové. Kategorie řadící se do transakčních funkcí:

• Externí vstupy – EI (External Inputs) Do této kategorie se řadí data přicházející z okolí systému a překračují tak jeho hranici. Může se jednat o ovládací nebo datové vstupy do systému. Příkladem mohou být obrazovky, dialogová okna nebo kontrolní signály ke správě dat.

• Externí výstupy – EO (External Outputs) Veškerý tok informací opačným směrem se bude řadit do kategorie EO (externích výstupů). Zejména jsou to data tvořící výstupy nebo jsou po-slány do jiných aplikací. Těmito daty je možné ovládat i interní logické soubory. Příkladem mohou být např. výstupní zprávy, grafy nebo automa-tická data.

• Externí dotazy – EQ (External Queries) Tato kategorie je určena pro komponenty vstupu i výstupu, jejichž cílem je získání dat z jednoho nebo více interních logických souborů nebo ex-terní soubory rozhraní. Důležité je, že vstupy neaktualizují vnitřní struk-turu dat a výstup neobsahuje žádná odvozená data. Příkladem jsou např. vstupy a výstupy na obrazovce s nápovědou, vyhledávání dat.

Kategorie řadící se do datových funkcí:

• Interní logické soubory – ILF (Internal Logical Files) Vstupní i výstupní komponenty získávající data z interních logických sou-borů. Jedná se o záznamy, které vytváří aplikace a jsou lokálně dostupné. Příkladem jsou např. soubory a tabulky dostupné uživateli.

• Externí soubory rozhraní – EIF (External Interface Files) V této kategorii jsou logicky spojená data uživateli používaná pro referen-ci nalézající se kompletně mimo systém a nejsou pod její správou. Může se jednat o data, která jsou pro jiný systém v kategorii ILF. Typickým příkla-dem je databáze čtená jinou aplikací.

Objekty, které se podařilo identifikovat a rozdělit do jednotlivých kategorií jsou následně rozděleny do skupin dle typu a složitosti. Konečný zůstatek objektů v každé kategorii je dle Jonese (1997) vynásobený váhou určenou v následující tabulce.


Tab. 3 Multiplikátory objektů FPA

Komplexnost Charakteristika Nízká Průměrná Vysoká

EI 3 4 6

EO 4 5 7

EQ 3 4 6

ILF 7 10 15

EIF 5 7 10

Zdroj: http://www.softwaremetrics.com/fpafund.htm

Celkový počet funkčních celků před úpravou pak dostaneme aplikací níže uvede-ného vzorečku.

∑( )

Kde:

NFB je počet neupravených funkčních celků, O je jeden z objektů aplikace – EI, EO, EQ, ILF, EIF, W je váha určená tabulkou níže.

Tab. 4 FPA – Stupně vlivu charakteristik na informační systém

Stupeň Vliv 0 Žádný 1 Náhodný 2 Nízký 3 Průměrný 4 Významný 5 Velmi silný


4.4.2 Upravené funkční celky

Krokem, který obvykle navazuje na určení neupravených funkčních celků, je určení počtu těch upravených na základě následujících vztahů zohledňující faktor přizpů-sobení:

http://www.softwaremetrics.com/fpafund.htm



∑

Kde:

UFP je počet upravených funkčních celků, FPH je faktor přizpůsobení hodnoty, TDI představuje stupeň vlivu ohodnocený 1-5 dle základních charakteristik

systému.


Tab. 5 FPA – Přehled základních charakteristik ovlivňujících systém

Základní systémové vlastnosti Krátký popis

1. Datová komunikace S kolik entitami je třeba komunikovat?

2. Distribuované zpracování dat

Jak se zachází s distribuovanými daty a funkcemi?

3. Výkon Byl průtok nebo odezva uživatelským

požadavkem?

4. Plné využití konfigurace

Vytíženost aktuálního hardware, kde bude systém spuštěný?

5. Přenosová rychlost Frekvence spouštění přenosů(denně,

týdenně, měsíčně)

6. Vstup síťových dat Jaké procento dat je zdáváno online?

7. Efektivnost uživatele Byla aplikace navržena pro efektivnost

koncového uživatele?

8. Síťová aktualizace Kolik ILF je aktualizováno online

přenosy?

9. Složitost Má aplikace logicky nebo matematicky

složitou funkcionalitu?

10. Znovupoužitelnost Byla aplikace vyvinuta dle požadavků

jednoho nebo více uživatelů?

11. Jednoduchost

instalace Jak složitá je instalace?

12. Jednoduchost ovládání Jak efektivní a automatizované jsou

metody spuštění a zálohy?

13. Množství pracovišť Byla aplikace vyvinuta k instalaci na více

pracovištích pro více organizací?

14. Jednoduchost úprav Byla aplikace vyvinuta pro ulehčení

úprav?


Dle závěrů analýz provedených v publikacích (Kemerer, 1987) a (Gaffney, Werling, 1991) mají ale závěry po úpravě funkčních celků dle subjektivních prvků nižší přesnost než použití neupravených funkčních celků.

Výstup z FPA lze převést z funkčních celků na řádky kódu. K tomu je třeba znát použitý programovací jazyk a koeficient pro převod mezi funkčními celky a řádky kódu. Přehled koeficientů pro nejpoužívanější jazyky je v tabulce níže.



Tab. 6 Rozdělení jazyků pro převod funkčních celků na řádky kódu

Programovací jazyk

Převod SLOC/FP

Průměr Medián Minimum Maximum

ABAP (SAP) 28 18 16 60

ASP 51 54 15 69

Assembler 119 98 25 320

Brio 14 14 13 16

C 97 99 39 333

C++ 50 53 25 80

C# 54 59 29 70

COBOL 61 55 23 297

Excel 209 191 131 315

HTML 34 40 14 48

J2EE 46 49 15 67

Java 53 53 14 134

JavaScript 47 53 31 63

JCL 62 48 25 221

LINC II 29 30 22 38

Lotus Notes 23 21 19 40

.NET 57 60 53 60

Oracle 37 40 17 60

Perl 24 15 15 60

PL/SQL 37 35 13 60

SQL 21 21 13 37

VB.NET 52 60 26 60

Visual Basic 42 44 20 60

Zdroj: http://www.qsm.com/resources/function-point-languages-table

Opět platí, že převod funkčních celků na řádky kódu značně zpřesní dostupná his-torická data s informacemi o této činnosti v minulosti.

http://www.qsm.com/resources/function-point-languages-table


4.4.3 Nizozemská metoda

V případě, že se jedná o ranou fázi projektu, existuje tzv. informativní metoda počí-tání funkčních celků navržená Nizozemskou asociací softwarových metrik (NEM-SA). V této metodě jsou počítány pouze ILF a EIF. Informativní součet je poté vy-počten z rovnice:

( ) ( )

Přičemž dané násobky hodnot jsou pouze orientační a bližší určení zajistí kalibrace historickými daty.

4.5 Analýza případů užití

Velmi podobný postup výpočtu jako právě popsaná metoda analýzy funkčních cel-ků má i analýza případů užití. Tento postup vyvinul Gustav Karner ze Švédska v roce 1993. Při výpočtu, před kterým je třeba znát samotné případy užití, na kte-rých je tento přístup založen, se postupuje následovně (HANSEN, 2012).

Jednotlivé případy se rozdělí do skupin dle složitosti a jejich počet se vynásobí váhou 5, 10 a 15 pro poslední skupinu. Součtem těchto mezivýsledků dostaneme neupravené váhy případu užití (UUCW – Unadjusted Use Case Weight). Neuprave-né váhy aktérů (UAW – Unadjusted Actor Weight) dostaneme obdobným způso-bem, aktéři ale budou rozděleni do skupin zobrazených v tabulce níže.

Tab. 7 Rozdělení aktérů a váhy skupin

Skupina aktérů Váha Lokální systém 1

Vzdálený systém 2

Uživatel 3

Zdroj: http://www.allaboutrequirements.com/2012/12/use-case-point-estimation-estimate-your-project-by-looking-at-your-use-cases.html

Pro končené skóre poté potřebujeme zjistit ještě faktor technické složitosti systé-mu (TCF – Technical Complexity Factor) a faktor složitosti prostředí (ECF – Envi-ronmental Complexity Factor). Níže zobrazené tabulky popisují jednotlivé faktory a jejich váhy.

http://www.allaboutrequirements.com/2012/12/use-case-point-estimation-estimate-your-project-by-looking-at-your-use-cases.html



Tab. 8 Přehled faktorů technické složitosti a jejich vah

Technický faktor Váha Distribuce systému 2

Výkon 1

Efektivita koncového uživatele 1

Složité vnitřní procesy 1

Znovupoužitelnost 1

Jednoduchost instalace 0,5

Jednoduchost použití 0,5

Přenositelnost 2

Jednoduchost změn 1

Souběžnost 1

Speciální ochranné prvky 1

Přímý přístup třetích stran 1

Požadavek speciálních školení 1


Tab. 9 Přehled faktorů prostředí a jejich vah

Faktor prostředí Váha Obeznámenost s UML 1,5

Pracovníci na částečný úvazek -1

Schopnosti analytika 0,5

Zkušenosti s aplikací 0,5

Zkušenosti s objekty 1

Motivace 1

Složitost programovacího jazyka -1

Stálost požadavků 2


Každý z faktorů je dále vynásoben relevantností (pro TCF) nebo mírou dopadu (pro ECF), vždy v rozsahu od 0 do 5, a sečten. Vzorce pro výpočet výsledného TCF a ECF jsou uvedeny níže:

ý

( ý )





Algoritmické přístupy k odhadům 47

Výsledné ohodnocení plánovaného systému metodou analýzy případů užití (UCP – Use Case Points) je získáno z rovnice níže.

( )

Tato hodnota sama o sobě není moc přínosná. Ovšem při srovnání s historickými daty je možné získat jasnou představu o náročnosti projektu a získat hrubé finanč-ní i časové náklady.

4.6 Odhadování pracnosti projektu

Po použití metod na odhad velikosti projektu je možné tuto veličinu použít i pro odhad pracnosti na vývoj daného systému. Odhad pracnosti projektu se obecně odvozuje právě od vypočítané veličiny představující velikost tohoto projektu. Jed-nak je možné porovnat podobné projekty z historických dat, popř. průměru odvět-ví. Při odhadech z historických dat je vhodné použít projekty podobné velikosti a odhadnout tak rozsah možných pracností z podobně velkých projektů. Dle McCon-nella (2006) je nejméně přesným přístupem odhad na základě průměru dat z odvětví, která se dají využít v případě chybějících historických dat.

Nejzajímavější je metoda vyvinutá mezinárodní skupinou pro standardy po-rovnávání software (ISBSG – International Software Benchmarking Standards Group), která je založena na velikosti systému určené ve funkčních celcích, druhu vývojového prostředí, maximální velikosti týmu a 8 rovnicích na těchto veličinách založených (ISBSG, 2010). Níže jsou zobrazeny 2 rovnice pro výpočet pracnosti projektu v člověkoměsících, kde první z těchto rovnic uvádí hodnotu při rozšíření systému a druhá při vývoji nového systému.

r cno t nk n elk ý

ý

4.7 Odhadování časového rámce projektu

Nejvhodnějším a také nejčastěji aplikovaným přístupem pro výpočet odhadu časo-vého rámce v dřívějších etapách vývoje systému na základě hodnot zjištěných při odhadu velikosti a pracnosti systému je dle McConnella (2006) tzv. základní rovni-ce pro rozvrh:

√

Při výpočtu časového rámce lze ale použít i přístup popsaný při odhadu pracnosti a to například srovnání s historickými daty, popř. průměr odvětví.

Také je možné využít hrubého výpočtu, který popsal Jones (1997). Udává tam mocnitele funkčních celků pro odhad časové náročnosti projektu. Rovnice zobra-


zena níže udává odhad v kalendářních měsících při průměrné produktivitě vývojo-vého týmu.

4.8 Odhadování ceny projektu

Finanční stránka odhadu softwarového projektu je přímo úměrná na práci. To znamená, že více funkcí bude znamenat prodražení projektu. Cena se zvyšuje také v případě, že se bude snižovat doba k vývoji. Z toho by mohlo vyplynout, že odha-dování finanční stránky softwaru je jednoduchou příležitostí a lze jednoduše od-vodit od odhadu množství práce. Je zde ovšem několik faktorů, které mohou odhad ceny zásadně ovlivnit.

4.8.1 Rizika a hrozby

Každý projekt by měl disponovat jistou rezervou. Velikost této rezervy se odvíjí od rizikovosti projektu, konkrétně dle množství hrozících rizik, pravděpodobnosti výskytu těchto rizik a jejich závažnosti.

Nejčastěji se vyskytující rizika spojená s vývojem softwarových aplikací jsou dle Ráčka (2006) následující:

nedostatek pracovníků, plány, rozpočty, proces, COTS, externí komponenty, neshody v požadavcích, neshody v uživatelském rozhraní, architektura, výkon, kvalita, změny v požadavcích, zděděný software, externě řešené úlohy, přecenění možností informatiky.

4.8.2 Odhadování chyb

Ve vývoji každého systému se produkují chyby a je možné odhadnout pravděpo-dobnost jejich výskytu. Dle Jonese (2000) je pro typický projekt průměrný počet chyb 50 na 1000 řádků kódu. To se dá dále přesněji určit dle velikosti projektu, kdy při vývoji menších systémů je nižší výskyt chyb.


Tab. 10 Typická hustota chyb dle velikosti systému

Velikost systému (v řádcích kódu) Typická hustota chyb (na 1000 řádek

kódu) Méně než 2000 0 – 25 2000 – 16000 0 – 40

16000 – 64000 0,5 – 50 64000 – 512000 2 – 70

512000 a více 4 – 100

Zdroj: McConnell, 2006

Pro zpřesnění daných odhadů se doporučuje použití historických dat, ve kterých je zanesen počet nalezených chyb v předešlých vlastních, popř. podobných projek-tech.

Přitom odhad množství zanesených chyb musí následovat také odhad jejich odstranění. Toho je možné dosáhnout mnoha různými postupy, které byly za dobu výzkumu v této oblasti společnostmi vyvinuty. Tabulka níže zobrazuje jejich zá-kladní přehled a typické procento odstranění chyb.

Tab. 11 Typické odstranění chyb dle zvoleného postupu

Postup odstranění Odstraněných chyb

Regresní testování 25 % Neformální revize kódu 25 % Testování po jednotkách 30 %

Testování nových komponent 30 % Neformální revize kódu 35 %

Nízkokapacitní beta testování 35 % Osobní revize kódu 40 %

Systémové testování 40 % Formální inspekce kódu 55 % Formální inspekce kódu 60 %

Modelování nebo prototypy 65 % Vysokokapacitní beta testování 75 %

Zdroj: Jones, 2000

Efektivita odstraňování chyb lze poté odhadnout dle vybraného postupu odstraně-ní. Dle Jonese (2000) je průměr celého softwarového průmyslu při odstraňování chyb přibližně 85 %.

Dle Boehma a spol. (2000) snížení chybovosti systému z 5 % na 1% zvýší vý-daje na projekt o 25 % a z 1 % na 0,01 % pozvedne náklady o dalších 25 %.


4.8.3 Počet prostředí

Čím více je dostupných testovacích a vývojových prostředí, tím menší je možnost zanesení chyb v případě oprav, implementace a testů. Je možné měnit funkce bez obav o zničení produkčního prostředí, je možné posouvat čas pro případ potřeby testování dlouhodobých činností, je možné testovat změny v návaznosti na zbytek kódu apod.

4.8.4 Přímé náklady

Je možné, že do odhadované ceny bude nutné připočítat další náklady mimo práce zaměstnanců. Mimo mzdy, daní a odměn zaměstnanců je nutné platit také marke-ting, cenu obchodníků, režii nebo například speciální vývojové nástroje a hardwa-re.

4.8.5 Přesčasy

Je možné, že do finančních odhadů bude nutné začlenit i přesčasy osob placených od hodiny nebo externích osob, což se může výrazně odrazit na celkových nákla-dech i větších projektů.

4.9 Možné druhy prezentace odhadu

V datech je třeba vyjádřit míru nejistoty v prezentovaném odhadu a hodnoty, které jsou jen málo pravděpodobné, vůbec nepředkládat uživateli. Míra nejistoty se dá vyjádřit více způsoby. Například pomocí:

znaménka plus mínus, koeficientu pravděpodobnosti, intervalů, odhadu pomocí případů, graficky prezentovaného odhadu.

V každém případě by měl uživatel, který odhad obdrží, získat z prezentovaných výsledků jasnou představu o minimální a maximální hranici, ve kterých se dokon-čení projektu může pohybovat. Tyto hodnoty představují podíl rizik, která mohou nastat v dané kategorii. Minimální hranice pak bude představovat standardní nej-více optimistickou hodnotu, která by se naplnila v případě, že by vše šlo naprosto ideálně a bez problémů. Vrchní hranice by určovala nejhorší předpokládaný pří-pad, ve kterém by se pokazilo vše, co by mohlo. Tato hranice může ovšem růst na-de všechny meze, to by ale uživatel neakceptoval.

Nejvhodnějším prostředkem pro prezentaci odhadů v aplikaci se zdá být gra-fické, kde lze jednoduše vyjádřit závislost několika jevů. Uživatel tak dostane rych-le jasnou představu, s jakou pravděpodobností nastane dokončení projektu v daném termínu, jakou pracnost bude tento termín vyžadovat, nebo kolik finanč-ních prostředků bude pro dokončení v tomto termínu potřeba.

Algoritmické přístupy k odhadům 51

4.10 Existující aplikace

Aktuálně je na trhu několik aplikací, které mají za úkol automatizovat odhady. Je-jich ceny se různí a stejně tak jejich použitelnost a funkčnost. Obecný přístup k odhadům pomocí automatizovaných procesů v podobě aplikací se užívá zejména pro poskytování hrubých odhadů v prvotních fázích projektu (McConnell, 2006). V dalších fázích se již doporučuje použít těchto přístupů pouze jako druhotný zdroj informací pro ověření jiných metod odhadů. Největším rozdílem v aktuálně existu-jících aplikacích rozdělených dle finančních nákladů na jejich pořízení je v množství historických dat, které poskytují. Je na každém, aby zvážil, zda mu při-daná hodnota dražších aplikací stojí za investici navíc. Dle McConnella (2006) ale přesnější odhady poskytuje i levnější nástroj s vlastními historickými daty, a to již od tří sledovaných projektů. Přehled aktuálně existujících aplikací je níže.

Angel – poskytuje podporu při odhadech projektů na základě analogií s minu-lými projekty.

Cocomo II – aplikace implementující metodu Cocomo II poskytnutá zdarma univerzitou Jižní Kalifornie (the University of Southern California).

Construx Estimate – nástroj vyvinutý předními experty na odhady, které vedl Steve McConnell. Tento volně šiřitelný nástroj s jednoduchým ovládáním je založen na Putnamově modelu odhadů a simulacích Monte Carlo.

Costar – placená aplikace implementující metodu Cocomo II vytvořená spo-lečnosti Softstar Systems.

KnowladgePLAN – Placená aplikace postavená na úzké spolupráci s progra-mem Microsoft Project.

52 Nástroje pro návrh aplikace


5.1 Softwarové požadavky

Správná identifikace, analýza a navržení zásadních požadavků na systém je pro návrh samotné aplikace stěžejní a bude na ni proto kladen důraz. Požadavky na systém představují potřeby a podmínky kladené na nový software (Eeles, Cripps, 2011). Analýza požadavků je důležitá činnost dostatečně detailního definování těchto potřeb pro účely návrhu systému. Základní rozdělení požadavků je na funkční a nefunkční. Funkční požadavky představují veškerou interakci aplikace s uživatelem a její funkčnost, nefunkční požadavky se dále dělí na designové, vý-konnostní a různá systémová omezení od potřeb konektivity systému až po hard-warem specifikovaná omezení návrhu.

5.2 Notace UML

UML (Unified Modeling Language) je standardem pro grafické vyjádření návrhu modelu softwarových aplikací. Jeho notace zahrnuje mnoho diagramů pro účely dynamické a statické reprezentace aplikace. Jedná se o univerzální jazyk určený pro modelování s pěvně danou grafickou syntaxí. Využívá se zejména k modelování objektově orientovaných systémů a je proto vhodné, aby se lidé, kteří s návrhem pracují při jeho tvorbě nebo následné implementaci, v jazyce orientovali. Jeho pra-vý potenciál se projeví zejména při návrhu rozsáhlých systémů, na kterých pracují celé vývojové týmy a také při odhadu nákladů systému.

5.2.1 Struktura jazyka

Struktura jazyka UML je postavena na třech elementech, které jsou reprezentovány v grafické podobě formou značek. Tyto elementy nazýváme:

předměty, relace, diagramy.

Diagramy lze rozdělit do následující struktury:

1. Diagramy reprezentující statickou strukturu systému:

Diagram tříd (Class diagram) prezentuje třídy a jejich vztahy. Diagram objektů (Object diagram) prezentuje objekty a jejich vztahy. Diagram balíků (Package diagram) prezentuje systém rozdělený do tzv. balí-

ků. Diagram komponent (Component diagram) prezentuje systémovou strukturu

systému pomocí softwarových komponent, rozhraní a jejich vztahů.

2. Diagramy reprezentující dynamické chování systému:

troje pro návrh aplikace 53

Diagram případů užití (Use case diagram) z pohledu uživatele systému pre-zentuje dynamickou strukturu.

3. Diagramy reprezentující dynamické chování jedné třídy:

Stavový diagram (State-chart diagram) prezentuje stavy objektu a přechody mezi nimi.

Diagram aktivit (Activity diagram) prezentuje postupnou návaznost akcí sys-tému.

Diagramy interakcí (Interaction diagram) zahrnují 4 typy diagramů: o Sekvenční diagram (Sequence diagram) prezentující spolupráci ob-

jektů sekvencemi posílaných zpráv. o Komunikační diagram (Communication diagram) prezentuje inter-

akci objektů mezi sebou podle jejich propojení. o Diagram časovaní (Timming diagram) zaznamenává časové omezení

spojené se změnou stavu jednotlivých objektů. o Diagram přehledu interakcí (Interaction overview diagram) spojuje

vlastnosti diagramu aktivit a sekvenčního diagramu.

Jako pomocného nástroje diagramů jazyka UML lze využít textová specifikace pří-padu užití (Textual specification) popisující činnosti odehrávající se v případech užití na vybraném diagramu (Kanisová, Müller, 2006).


Obr. 4 Rozdělení UML diagramů (Arlow, 2007)

5.2.2 Diagram případů užití

Diagram případů užití, neboli Use Case model, je grafickým zobrazením části do-kumentu specifikace požadavků ze strany uživatele (Arlow, 2007). Hlavními prvky tohoto diagramu jsou aktéři a případy užití. Aktér představuje skupinu lidí užívají-cích systém se stejnými právy a možnostmi používání aplikace. Případy užití jsou činnosti nebo posloupnost činností, které lze v aplikaci provádět identifikovanými aktéry (Cockburn, 2005).

Mezi případy užití mohou být také vazby rozšiřující jejich funkčnost. Relace include a extend se vyznačuji v diagramu plnou čárou s popisem. Primární odliš-ností platnou pro relaci extend od relace include je skutečnost, že původní případ užití, který relací extend rozšiřujeme, neví o rozšiřujícím případu užití a je soběs-tačný i bez něho. Naopak případ užití s relací include je funkčně závislý na před-chozím případu užití.

troje pro návrh aplikace 55

5.2.3 Diagram aktivit

Jednotlivé aktivity představují chování systému při běhu metody nebo několika metod po sobě. Vhodně vyjadřuje například procesy a jejich workflow. Postup je reprezentován sekvencí jednotlivých kroků v podobě akcí, aktivit a je spojujícího řídícího toku mezi nimi. Aktivita se od akce liší dělitelností, přičemž akce je již dále nedělitelný děj (Kanisová, Müller, 2006).

5.2.4 Stavový diagram

Tento typ diagramu v notaci UML může představovat systém nebo jeho část s ko-nečným počtem stavů. Diagram je tvořen stavy a přechody mezi stavy. Stav je při-tom konfigurace systému za neměnných podmínek. Přechod tyto podmínky mění.

5.2.5 Diagram tříd

Třídy jsou předpisem objektů využívajících se při implementaci a dávají proto jas-nou představu o struktuře aplikace. Diagram těchto tříd proto tvoří základ v návr-hu statické stránky systému. Základní prvky tohoto diagramu tvoří třídy a vztahy mezi nimi. Vztahy mezi třídami jsou asociace, agregace a kompozice, která je z těchto vztahů nejtěsnější. U vztahů jsou definovány atributy určující vlastnosti objektů a metody rozšiřující třídu, které definují funkční složku objektu. Tyto prv-ky třídy mohou být soukromé (pouze pro danou třídu a její metody), chráněné (pouze pro danou třídu a její metody) nebo veřejné (dostupné pro všechny objek-ty) (KUČEROVÁ, 2007).

5.3 Diagram požadavků

Jedná se o grafické vyjádření požadavků na systém v notaci SysML založené na no-taci UML. Lze doplnit o případy užití a může tak do jisté míry nahradit Diagramy případů užití, přičemž však nezobrazuje přístup jednotlivých uživatelů k funkcím aplikace. Tuto vlastnost diagramu případů užití je nutné nahradit v dalším přístu-pu.

5.4 Eriksson-Penker

Je jedním z nejpoužívanějších profilů UML, zejména pro potřeby modelování pod-nikových procesů. Tato integrovaná metoda je velmi podrobně vysvětlena v (Erik-son, Penker, 2000). Vznikla jako reakce na praktickou nepoužitelnost původních rozšíření jazyka UML pro modelování organizačních procesů a dle Řepy (2012) se pro svou obsáhlost a praktičnost rychle stala nejpoužívanějším profilem modelo-vání procesů organizace. Tato notace umožňuje více pohledů na organizaci a její procesy.

Notace Eriksson-Penker také obsahuje mnoho modelů a diagramů, z nichž pro účely této práce bude nejvhodnější využít diagram případů užití, který je postave-ný na diagramu případů užití z UML. Tento diagram definuje požadovanou funkci-


onalitu softwarových aplikací a jeho pomocí se může určit i přístup uživatele k jednotlivým funkcím.

Tento diagram se stane představitelem hlavního procesu aplikace. Jeho první úroveň bude zejména informativní z hlediska základní a zjednodušené funkčnosti aplikace a bude vhodná pro rychlé získání přehledu o jejích hlavních prvcích.

Metodika řešení 57

6 Metodika řešení

Cílem této práce je navrhnout aplikaci s inovativní funkcionalitou poskytující od-had nákladů vývoje, případně rozšíření, informačního systému jednoduchou for-mou. Z toho plynou dva základní požadavky na danou aplikaci:

1. Aplikace bude podporovat metodiky pro odhad.

2. Bude disponovat uživatelským rozhraním pro jednoduchou orientaci a zadá-vání dat.

Byly určeny následující kroky vedoucí ke splnění těchto požadavků:

1. Identifikace uživatele aplikace a určení jejího účelu. To povede k lepšímu po-chopení znalostí a dovedností hlavního využivatele jejích funkcí a budeme moci lépe vybrat hlavní funkce aplikace.

2. Stanovení základních funkčních prostředků založených na účelu aplikace, jimiž bude aplikace disponovat, a jejich grafické vyjádření v podobě diagramu.

3. S využitím znalostí získaných v provedených analýzách předešlých částí sta-novení celkové funkcionality aplikace a její struktury. Na konci tohoto kroku by měla být možná implementace aplikace ve finální podobě.

4. Implementace takových částí navržené aplikace, aby bylo možné výsledné zhodnocení správnosti návrhu této aplikace.

Samotný návrh bude vycházet z kapitol předešlých a bude proto založen zejména na uživatelích a jejich potřebách a schopnostech. Návrh bude oproštěn od kon-krétních implementačních technik a nástrojů.

6.1 Vybrané metodiky

Pro implementaci algoritmických metod výpočtu odhadů touto aplikací byly vy-brány metody analýzy funkčních celků, COCOMO II, Případy užití a Nizozemská metoda. Tyto metody byly vybrány z důvodu jejich komplexního pokrytí poskytnu-tí odhadů vzhledem k fázi projektu a vstupů, které může uživatel v daných fázích zadat.

V aplikaci budou využity i další přístupy popsané v teoretickém základu této práce, například odhad s použitím zástupce. U tohoto přístupu budou nejvyšší a nejnižší hodnoty funkcí rozděleny do fuzzy množin. Naplnění množin bude rozdě-leno dle podobných projektů v historických datech. K určování očekávaných hod-not odhadů bude využito vzorce PERT.

Je možné zvolit i odlišný přístup a vytvořit novou metodiku než doposud exis-tující. Pokusit by se o to mohl znatelně zkušenějších odborník v rozsáhlejší práci.

58 Návrh řešení

7 Návrh řešení

Typickým uživatelem aplikace bude uživatel i s méně pokročilými znalostmi uží-vání informačních technologií a alespoň minimálními znalostmi o systému nebo jeho částech, jež chce odhadovat. Uživatel nebude muset znát jednotlivé metody používané v této aplikaci.

Hlavní částí této práce je navržení právě takové aplikace, která by identifiko-vaného uživatele podporovala ve tvorbě odhadů pomocí automatizace časových a finančních předpovědí při nasazování informačního systému do společnosti. Po-skytovala by tak pomyslný odrazový stupínek pro snížení nákladů spojených s tímto procesem.

Samotný návrh řešení bude naprosto oproštěn od konkrétních způsobů im-plementace, možných implementačních prostředí nebo platformách. Bude co nej-obecněji popisovat možný způsob navržení zamýšlené aplikace. V této části se na-lézají pouze diagramy důležité pro pochopení práce programu. Ostatní diagramy se nalézají v příloze této práce.

V úvodu návrhu řešení budou analyzované metodiky popsané v předchozích částech práce použity k návrhu aplikace podporující odhady manažerů. Pro návrh aplikace použiji diagram požadavků vycházející z UML notace a notaci Eriksson-Penker, která je rozšířením notace BPMN použitelnou k návrhu aplikace. K po-drobnějšímu popisu aplikace budou dále použity diagramy UML notace.

Cílem tvorby diagramů je, aby první diagramy jednoduše popisovaly základní funkčnost aplikace a byly proto vhodné i pro neznalého uživatele. Nižší úrovně a další diagramy budou poté z rozdílných úhlů pohledu detailněji rozebírat podrob-nou funkcionalitu programu.

7.1 Identifikace uživatele a definice účelu aplikace

Definice hlavního účelu aplikace je v počátcích jejího vývoje velmi podstatné pro určení směru jeho dalšího postupu. Ke správné definici je nejprve nutno identifi-kovat, pro koho bude aplikace vytvořena a komu má ulehčit zamýšlené úkoly.

Samotná aplikace bude poskytovat odhad nákladů na implementaci informač-ního systému na základě uživatelských vstupů. Důležitým aspektem bude možnost uživatele zvolit tzv. „bleskový odhad“, při které bude odhad proveden vybráním modulů odhadovaného systému. To povede ke zjednodušení a zrychlení procesu pro odhadovatele.

Na výběr bude i možnost klasičtějšího postupu při odhadu, kdy bude automa-ticky vybrán přístup k odhadu na základě zadaných vstupů. Touto metodou bude možné dosáhnout odhadu s vyšší přesností.

vrh řešení 59

7.2 Analýza požadavků

7.2.1 Designové požadavky

1. Uživatel by měl při spuštění aplikace mít jasně dané možnosti na výběr.

2. Úvodní obrazovka by měla poskytovat seznam dříve uložených projektů.

3. Výstup by měl obsahovat grafické a slovní hodnocení výsledků odhadu.

7.2.2 Funkční požadavky

1. Aplikace bude po spuštění umožňovat vytvoření nového projektu nebo ote-vření uloženého projektu.

2. Každý projekt by mělo být možné uložit v průběhu jeho tvorby a po vytvoření.

2.1. Každý projekt bude automaticky uložen po provedené změně a také ve 30 sekundových intervalech.

3. Uložený projekt bude možné odstranit.

4. Aplikace by měla umožňovat načtení historických dat.

4.1. Historická data bude možné načíst z databáze.

4.2. Historická data bude možné načíst ze souboru ve formátu TXT, XLS, CSV, HTML.

5. Po vytvoření nebo otevření projektu by měl uživatel mít možnost změnit veš-keré vstupy.

6. Aplikace bude umožňovat více způsobů tvorby odhadů.

6.1. Aplikace bude umožňovat tvorbu projektu pomocí přidávání modulů.

6.2. Aplikace bude umožňovat tvorbu projektů pomocí průvodce s nápově-dou.

7. Aplikace bude nabízet různé metodiky výpočtu odhadu.

7.1. Aplikace bude provádět výpočet odhadu pomocí Cocomo II.

7.2. Aplikace bude provádět výpočet odhadu pomocí FPA.

7.3. Uživatel bude moci manuálně zvolit preferovanou metodiku výpočtu.

7.4. Uživatel bude moci zvolit porovnání dvou metodik výpočtu odhadu.

8. Aplikace bude produkovat výstupy v podobě grafů s popisy

8.1. Výstup aplikace bude možné uložit i vytisknout.

8.2. Z výstupu odhadu bude možné automaticky vytvořit výstupní zprávu

8.2.1. Výstupní zprávu bude možné uložit nebo vytisknout.

8.3. Výstup odhadu bude možné exportovat jako historická data do souboru ve formátu TXT, XLS, CSV, HTML.

8.4. Výstup souboru bude možné uložit do databáze jako historická data.

60 Návrh řešení

7.2.3 Požadavky na výkon

Požadavky v této části poskytují přehled požadavků na rychlost reakcí aplikace.

1. Doba odezvy

Popis: Rychlost odezvy aplikace. Metrika: Měření získaná z testů. Nutnost: Méně než 2 sekundy ve 100 % případů. Přání: Méně než 1 sekunda ve 100 % případů.

2. Doba provádění výpočtů

Popis: Rychlost provádění výpočtů. Metrika: Měření získaná z testů. Nutnost: Méně než 10 sekund ve 100 % případů. Přání: Méně než 5 sekund ve 100 % případů.

7.2.4 Omezení návrhu

Tato část obsahuje omezení návrhu software způsobená hardwarem.

1. Velikost na disku

Popis: Velikost lokálního prostoru použitého aplikací. Metrika: MB. Nutnost: Méně než 20 MB. Plán: Méně než 15 MB. Přání: Méně než 10 MB. MB definice: Megabyte.

2. Využití pamětí počítače

Popis: Velikost paměti využívaného aplikací. Metrika: MB. Popis: Pozorování logů během výkonnostních testů. Nutnost: Méně než 50 MB. Plán: Méně než 20 MB. Přání: Méně než 10 MB. MB definice: Megabyte.

7.2.5 Vlastnosti systému

Požadavky v této části určují požadovanou spolehlivost dostupnost, bezpečnost a přenositelnost systému.

1. Spolehlivost

Metrika: Měření získaná z testů. Nutnost: V 30 % příležitostí odhadne projekt v rozmezí 60 % od skutečnosti.

vrh řešení 61

Plán: V 50 % příležitostí odhadne projekt v rozmezí 45 % od skutečnosti. Přání: V 75 % příležitostí odhadne projekt v rozmezí 30 % od skutečnosti.

2. Dostupnost

Popis: Aplikace by měla být dostupná ke stažení zdarma. Popis: Aplikace by měla být spustitelná na přístrojích bez nutnosti instalace.

3. Internetové připojení

Popis: Aplikace by měla být připojena k Internetu. Odůvodnění: Připojena by aplikace měla být pro možnost komunikace

s databází.

V příloze 0 je přiložen celkový diagram požadavků rozšířený o případy užití im-plementující jednotlivé funkční požadavky.

7.3 Popis logické funkcionality systému

Logická struktura aplikace bude představena slovním popisem s grafickým vyjád-řením pomocí notace Eriksson-Penker, která dokáže jednoduše popsat jednotlivé procesy probíhající v aplikaci. Hlavním cílem tohoto diagramu je popsat základní proces, který bude probíhat při plnění účelu aplikace.

Aplikace bude sloužit pro vytvoření časového a finančního odhadu vývoje in-formačního systému na základě metodik vybraných v teoretické části. Důraz je kladen na jednoduchost zadávání informací a na úkor přesnosti i výpočtu odhadu s co možná nejméně vstupy.

Po spuštění aplikace bude uživatel vyzván k výběru akce. Bude moci spravo-vat dříve vytvořené odhady nebo vytvořit nový. Pro načtení uložených odhadů bu-de sloužit na úvodní stránce seznam, ze kterého bude možné vybrat a otevřít dříve uložené odhady.

Nový odhad bude moci být vytvořen třemi způsoby:

1. Zvolením modulů, které by uživatel chtěl v odhadovaném informačním systé-mu implementovat a zda se jedná o nový vývoj nebo vývoj již nasazeného sys-tému. Hodnoty pro vstup do funkcí budou moci být zvoleny uživatelem v případě, že těmito daty disponuje, nebo vypočítány z historických dat. K výpočtu bude využita Nizozemská metoda, kde je zapotřebí počet IFL a EIF. Pokud by tato data uživatel neznal, byla by tato informace vyextrahována z historických dat. Tak by došlo k odhadu velikosti projektu a na jeho základě i odhadu pracnosti a také časových a finančních nákladů.

2. Uživatel bude moci tvořit odhad postupným zadáváním hodnot pomocí prů-vodce s popisem jednotlivých vstupů. Průvodce vytvoření bude obsahovat mnohá zjednodušení pomocí FUZZY množin, která by měla nezkušeným uži-vatelům ulehčit zadávání hodnot. U zadávaných hodnot bude moci uživatel zvolit úroveň významu dané konstanty na projekt. Tuto úroveň bude zadávat uživatel a vybírat bude moci z množiny hodnot velmi nízký, nízký, normální,

62 Návrh řešení

velký, velmi velký a extrémně velký. Nejvhodnější metoda pro odhad bude au-tomatickým procesem založeným na návrhu v (Bielas, 2013) vybrána na zá-kladě uživatelských vstupů. Uživateli tak budou předloženy jen potřebné otázky k odhadu danou metodou. Po zodpovězení otázek bude uživateli před-ložen odhad velikosti projektu a na jeho základě i pracnosti a také časových a finančních nákladů.

3. Uživatel bude mít jako možnost i vybrání konkrétní metody, která se k provedení odhadu použije. Tímto způsobem může ovlivnit, jakou metodou bude odhad proveden a nemusí spoléhat na navržený algoritmus. V tomto případě bude moci určit porovnání jednotlivých metod, kdy bude dotázán na hodnoty potřebné pro více metod a po dokončení zadávací části mu bude předložen výstup s oběma odhady v přehledné formě vhodné pro jejich po-rovnání.

Rozpracovaný projekt bude možné uložit a vrátit se k němu později. Uživateli bude také umožněno nahrání dat, která by značně zvýšila přesnost prováděného odha-du. Tato data ponesou informaci o podobných již odhadovaných a dokončených projektech ze stejného nebo jiného oboru, popř. o jiných částech právě odhadova-ného informačního systému. Tato data by po nahrání byla použita pro zpřesnění odhadů a snížení nejistoty v prováděných odhadech. Po nahrání vlastních historic-kých dat bude uživatel požádán o souhlas s anonymním použitím těchto údajů v databázi pro pomoc ostatním. V případě, že uživatel nemá vlastní data, bude jeho projekt upřesněn daty z databáze.

Výstup z aplikace bude zejména v podobě grafů a faktického shrnutí odhadu. Výstup bude možné vytisknout nebo uložit jako obrázek nebo PDF. V aplikaci bude existovat i možnost vytvoření výstupní zprávy, která bude strukturovaná a obsa-hovat bude veškerá data v grafické i textové podobě související s provedeným od-hadem.

V závěru bude uživatel mít možnost doplnit svá historická data o právě pro-vedený odhad. Tím by dosáhl větší přesnosti v budoucnosti.

vrh řešení 63

Obr. 5 Základní schéma aplikace pomocí „Eriksson-Penker notace“

7.4 Diagram případů užití

Pro zvýšení přehlednosti a zdůraznění funkcionality aplikace byl vytvořen i uživa-telský pohled na použití aplikace a její funkcionalitu v podobě diagramu Případů užití. Tento diagram poskytuje základní přehled funkcí, které bude aplikace schop-ná vykonat.

64 Návrh řešení

Obr. 6 Diagram případů užití

vrh řešení 65

7.5 Rozbor hlavních metod

Pro celistvost je v této kapitole proveden podrobnější rozbor hlavních metod s využitím diagramů aktivit.

7.5.1 Obecný postup při tvorbě projektu

Aplikace bude umožňovat více způsobů tvorby projektu. Jejich přehled a postup tvorby jednotlivými možnostmi je zobrazen na diagramu aktivit níže. Všechny způ-soby tvorby projektu budou probíhat v prostředí tzv. průvodce, který zajistí dosta-tečné informování uživatele a jejich směrování k zadání všech správných hodnot současně s udržením vysokého uživatelského komfortu. Při tvorbě modelu prů-vodcem bez využití přímé volby metody nebo rychlé tvorby odhadu, se metoda výpočtu odhadu určí algoritmem. Po zvolení způsobu manuálního výběru metody se budou nabízet stejná dialogová okna jako při předchozí možnosti, nebude ale využito algoritmu pro výběr metody. Ta již bude vybrána uživatelem.

66 Návrh řešení

Obr. 7 Diagram aktivit – Tvorba projektu

vrh řešení 67

7.5.2 Automatické určení metody tvorby projektu

Automatický výběr metody algoritmem volně vychází z návrhu uvedeného v (Bie-las, 2013). Tento návrh je založen na vícekriteriálním rozhodování s využitím mo-difikované metody PRIAM. V této publikaci byl proveden podrobný rozbor jednot-livých metod s analýzou výsledků a poté byl získán přehled vhodnosti použití jed-notlivých metod v závislosti na různých vstupech. Je zde navržen algoritmus výbě-ru vhodné metody na základě pěti vstupů. Přehled výsledků analýzy je shrnut v tabulce níže.

Tab. 12 Výsledky analýzy metod

Faktor Funkční celky

COCOMO II Případy užití Nizozemská metoda

F1 - Fáze projektu Kdykoliv Kdykoliv Střední fáze Brzká fáze

F2 - Přesnost Poměrně přesná

Velice přesná Poměrně přesná

Nepřesná

F3 - Zkušenosti Vysoké Nižší Střední Nižší

F4 - Rychlost Střední Nízká Vyšší Vyšší

F5 – Znalost vstupů Funkční cel-ky

Nutné FP nebo LOC

Případy užití Funkční cel-ky

Zdroj: Bielas, 2013

Přehled požadovaných vstupů do algoritmu s rozšířením o potřeby navrhované aplikace je v tabulce níže.

68 Návrh řešení

Tab. 13 Rozdělení možných vstupů pro jednotlivé oblasti

Zjišťovaná oblast Možné vstupy

Fáze vývoje 1 – Kdykoliv 2 – Střední fáze 3 – Brzká fáze

Přesnost návrhu 1 – Velice přesná 2 – Poměrně přesná 3 – Nepřesná

Zkušenosti týmu 1 – Vyšší 2 – Střední 3 – Nižší

Rychlost 1 – Nižší 2 – Střední 3 – Vyšší

Znalost vstupů 1 – Není nutná 2 – Nutná znalost FP nebo LOC 3 – Nutná znalost případů použití

Zdroj: Bielas, 2013

Uvedené faktory pak ohodnotíme číselnými hodnotami.

Tab. 14 Seřazené ohodnocení faktorů metod

F5 F3 F1 F2 F4

Funkční celky 1 3 1 2 2

COCOMO 2 1 1 1 3

Případy užití 3 2 2 2 1

Nizozemská metoda

2 3 3 3 3

Zdroj: Bielas, 2013

Po sestavení tohoto modelu je již potřeba jen specifikovat vhodné otázky, které by uživateli umožnily vyjádřit stav odhadovaného projektu, a zároveň podaly jasné vstupy pro algoritmus automatického výběru vhodné metody pro provedení odha-du.

Tab. 15 Přehled otázek k uživateli pro vstup

Velikost projektu

Neznáme velikost projektu.

Máme okamžitě k dispozici velikost, vyjádřenou v řádcích kódu.

Máme okamžitě k dispozici velikost, vyjádřenou pomocí funkčních celků.

Neznáme velikost projektu, ale před odhadem jsme schopni získat velikost, vyjádřenou v řádcích kódu.

Neznáme velikost projektu, ale před odhadem jsme schopni získat velikost, vyjádřenou

vrh řešení 69

pomocí funkčních celků.

Neznáme velikost projektu, ale před odhadem jsme schopni získat případy užití.

Známe velikost projektu, vyjádřenou v případech užití.

Zkušenosti s odhady

Nemáme žádné zkušenosti s odhady a analytik má nižší zkušenosti.

Nemáme žádné zkušenosti s odhady a analytik má střední zkušenosti.

Nemáme žádné zkušenosti s odhady a analytik má vyšší zkušenosti.

Máme základní zkušenosti s odhady.

Máme pokročilé zkušenosti s odhady.

Máme bohaté zkušenosti s odhady.

Fáze, ve které se projekt nachází

Jsme na úplném začátku projektu, máme pouze zadání.

Jsme ve fázi návrhu, bez jakýchkoliv hotových analýz.

Jsme ve fázi návrhu, máme k dispozici analýzy (případy užití).

Jsme ve fázi plánování.

Jsme ve fázi implementace.

Požadovaná přesnost odhadu

Požadujeme co nejpřesnější odhad.

Stačí nám hrubý odhad, který v následujících fázích případně zpřesníme.

Priorita rychlosti nasazení systému

Nespěcháme, máme dost času, než budeme odhad potřebovat.

Máme poměrně dostatek času a zdrojů.

Požadujeme odhad v co nejkratší době.

Zdroj: Bielas, 2013

Po získání odpovědí uživatele bude pomocí metody PRIAM určena nejvhodnější metoda pro výpočet. Algoritmus postupuje postupně a vyřazuje takové metody, které v dané otázce budou mít nižší hodnotu než je pro danou otázku a metodu uvedeno v Tab. 15. V případě, že nebude vybrána žádná metoda, bude zvolena ta, která byla vyřazena jako poslední. V případě, že bude metod vybráno více, zvolena bude ta metoda, která bude na seznamu první.

7.5.3 Uložení odhadu

Odhad bude při tvorbě automaticky ukládán po potvrzení každé skupiny voleb do paměti aktuální práce. Skupinou voleb je myšleno potvrzení přechodu na další ob-razovku zadávání vstupních hodnot. Také každých 30 sekund proběhne automa-tické uložení projektu do této paměti. Po dokončení tvorby projektu je možné zvo-lit uložení projektu. K tomu dojde přesunem dat z paměti aktuální práce do data-báze uložených odhadů a uvolněním paměti aktuální práce.

70 Návrh řešení

Obr. 8 Stavový diagram – Přehled stavů při ukládání a načítání dat z paměti

7.5.4 Načtení uloženého odhadu

Po zvolení načtení odhadu, který byl dříve aplikací uložen, se přesunou odpovídají-cí data z databáze uložených odhadů do paměti aktuální práce a tím dojde i k aktu-alizaci zobrazovaného obsahu aplikace. Hlavní obrazovka tak již nebude zobrazo-vat nabídku pro otevření nebo vytvoření odhadu, ale bude zobrazen výstupní od-had z dostupných dat a vybrané metody. V případě, že budou data načtená v paměti aktuální práce nekompletní, mělo by se otevřít odpovídající dialogové okno v průvodci tvorby odhadu, kde byla tvorba přerušena.

vrh řešení 71

Obr. 9 Diagram aktivit – Načtení uloženého odhadu

7.5.5 Použití historických dat

Historická data budou použita ke zpřesnění výpočtu prováděných odhadů. U jed-notlivých metod bude historických dat využito pro zjištění různých průměrných hodnot v závislosti na používané metodě. V případě rychlého odhadu budou tato data poskytovat hodnoty pro vstup do výpočetní funkce. Vstup bude vypočten z průměrných historických dat a dojde tak k hrubému odhadu bez nutnosti složi-tých vstupů od uživatele. U ostatních metod budou historická data sloužit pro do-plnění vstupů, které uživatel nevyplnil. Tím dojde k vyplnění všech vstupů, zatímco uživatelský komfort zůstane nezměněný.

72 Návrh řešení

7.6 Diagram tříd

Podrobnější náhled na logickou strukturu aplikace bude představovat diagram tříd, pomocí kterého se identifikují základní stavební prvky objektového návrhu aplikace.

Obr. 10 Diagram tříd aplikace

V diagramu tříd zobrazeném výše bylo celkem identifikováno 7 tříd reprezentují-cích zmíněnou logickou strukturu. Třída Metoda výpočtu je abstraktní třídou a ob-sahuje atributy odpovídající metody, které budou její potomci. Metody této třídy provádějí výpočty vybrané metody a vracejí výsledky odhadu. Datová úložiště je abstraktní třídou, z níž dědí třídy Historická data a Databáze dat uložených odhadů. Ty reprezentují úložiště, kde se uchovávají historická data, resp. kam se ukládají data uložených odhadů v případě druhé zmíněné třídy. Právě prováděný odhad bude reprezentován třídou Paměť pro aktuální odhad. Ta je oproti třídě Databáze dat uložených odhadů obohacena o atribut určující, zda byla tvorba projektu do-končena, a metody které obstarávají správu dat v paměti. Vykreslování grafu zajiš-ťuje třída Graf a její metody. Kompletní funkcionalitu aplikace zastřešuje třída Od-

vrh řešení 73

had, která obsahuje zásadní metody pro volání metod ostatních tříd. Metody této třídy zajišťují tvorbu nového odhadu, správu již vytvořených odhadů, zobrazování grafů a správu historických dat.

7.7 Struktura datových úložišť

Datová úložiště budou představovat zejména dva strukturálně odlišné návrhy. Prvním z nich bude návrh úložiště ukládající rozpracovaný projekt a druhým z nich bude úložiště uchovávající informace o historických datech.

Historická data, jak bylo uvedeno v teoretickém základu, budou představovat fakta o již dokončených projektech. Základem těchto dat budou informace o identi-fikátoru projektu pro jejich odlišení, základních vlastnostech nasazovaného systé-mu a skutečných hodnotách nasazování. Tyto hodnoty budou moci být dále rozší-řeny o data z dříve prováděného odhadu pro porovnání. Strukturu tohoto souboru je možné vidět v tabulce níže.

Tab. 16 Přehled struktury úložiště historických dat

Atribut Popis atributu Název projektu Název projektu, kterého se odhad týká

Použité moduly Moduly, které byly v daném projektu nasazovány do systému

Velikost nasazovaného projektu Velikost vyjádřená v SLOC/FP Délka nasazení systému Délka nasazování určená v měsících

Pracnost nasazení systému Pracnost projektu vyjádřená v člověkoměsících

Cena nasazení systému Cena vyjadřující finanční náklady na projekt

Pro uložení dat ve vytvářených odhadech bude sloužit datová struktura úložiště rozpracovaných a uložených odhadů. Tato data budou uchovávat informace o jedi-nečném identifikátoru odhadu, způsob tvorby vybraný uživatelem při jeho vytvo-ření, data zadaná uživatelem v průběhu jeho tvorby a názvu projektu zadaného uživatelem při tvorbě odhadu. Ten nemusí být jedinečný, v jednom projektu tak může být více odhadů s odlišeným jedinečným identifikátorem.

Tab. 17 Přehled struktury uložených odhadů

Atribut Popis atributu

Identifikátor Jedinečný identifikátor odhadu určující pořadové číslo prováděného odhadu

Název projektu Název projektu, ze kterého odhad pochází Způsob tvorby Způsob, jakým byl odhad vytvářen Metoda výpočtu Metoda, která byla k výpočtu použita Vstupní data Vstupní data od uživatele

74 Implementace navrženého řešení


V této části bude provedena částečná implementace navrženého řešení pro ověření správnosti uvažování v předešlých kapitolách.

8.1 Návrh vzhledu

Jednoduchý návrh s jasným vstupním bodem. Ten představují dvě rozměrná tlačít-ka uprostřed hlavní obrazovky.

Obr. 11 Návrh vzhledu úvodní obrazovky

Obrazovka s načteným odhadem bude zaměřena na přehledný výpis vypočtených dat a grafické zobrazení možných nákladů.

Implementace navrženého řešení 75

Obr. 12 Návrh vzhledu obrazovky s přehledem výstupu

Obrazovky s tvorbou projektu jsou zaměřeny zejména na sběr dat a jejich grafický návrh proto nebude prioritou. Hlavním cílem bude jejich přehlednost a komfort uživatele. Na jednom místě by tedy nemělo být mnoho vstupních bodů.


8.2 Popis použitých nástrojů

Obr. 13 Zobrazení přechodů mezi jednotlivými nástroji

8.2.1 QT Designer

Základní 3 principy tvorby uživatelského rozhraní pomocí knihovny Qt jsou:

tvorba pomocí jazyka QML, pomocí ovládacích prvků, zobrazovat obsah webových aplikací.


Tab. 18 Srovnání výhod tvorby rozhraní v Qt

Qt Quick Qt Widgets Qt WebKit Použité jazyky QML/JS C++ HTML/CSS/JS

Nativní vzhled X X Vlastní vzhled X X (X) Plovoucí animované GUI X Dotykové obrazovky X Standardní ovládací prvky X Programování model/view (X) X Zrychlený UI vývoj X (X) Grafická HW akcelerace X Grafické efekty X Široké možnosti práce s textem X X Existující webový obsah X

Zdroj: Qt Project, 2015

Qt Widgety jsou určeny pro tvorbu uživatelského rozhraní v rámci desktopových aplikací a jsou proto nejvhodnější k využití na desktopových aplikacích. Jeho výho-dou je klasické uživatelské rozhraní, na které je většina uživatelů zvyklá. Ovládací prvky mají dobrou integritu pro jednotlivé platformy, což poskytuje přirozený vzhled a možnost intuitivního ovládání ve všech nejrozšířenějších operačních sys-témech. Nabízejí velký výběr prvků vhodných pro statická uživatelská rozhraní.

I proto je nejvhodnějším přístupem k tvorbě této aplikace přístup QT Widgets. Tabulka výše poskytuje přehled technologií pro usnadnění rozhodnutí. Žlutě jsou zvýrazněna ta kritéria, která hrála největší roli při volbě vhodného přístupu.

8.2.2 Python

Název jazyka Python je inspirovaný vášní jeho tvůrce Guida van Rossuma pořadem společnosti BBC Monty Python's Flying Circus. Jedná se o vysokoúrovňový skripto-vací jazyk podporující i objektové programování, který se chová dle očekávání. Je to univerzální jazyk, ve kterém se stejně dobře píše GUI jako back-end skripty pro složité výpočty. Skripty napsané v Pythonu lze jednoduše vložit do aplikací v naprogramované v jiném jazyce. Práce s ním je efektivní a velký důraz se klade na stručnost zápisu.

8.2.3 Propojení kódu v Pythonu s QT návrhem

Pro propojení grafického uživatelského rozhraní se skripty napsanými v Pythonu bylo využito modulu PyQt. Alternativou k tomuto přístupu může být například PySide. Oba tyto nástrojové balíčky jsou si ve svých funkcích a aktivitě údržby ví-ceméně rovny a výběr mezi nimi je proto na preferencích vývojáře.


8.3 Definice rozsahu implementace

Rozsah implementované funkcionality je prezentován diagramem tříd. Rozdílnost mezi tímto diagramem a diagramem tříd z části návrhu aplikace je způsoben změ-něnou úrovní abstrakce a metodami potřebnými k implementaci za použití vybra-ných technologií.

Obr. 14 Diagram tříd implementované aplikace

Jako historická data byla použita data trénovací vygenerovaná náhodným algorit-mem. V reálném systému by tato data byla vložena uživatelem nebo by byla použi-ta reálná historická data. Trénovací data byla zvolena v rozsahu 12000-120000 pro data LOC velikosti projektu a v rozsahu 50-300 pro velikost reprezentovanou jednotlivými funkčními celky.


8.4 Navržená aplikace

Implementovaná desktopová aplikace se zaměřuje na část návrhu, která je neméně náročná na vstupy od uživatele. Měla by tak odhady podporovat zejména ve velmi brzkých fázích nových projektů bez zdlouhavých vstupů od uživatele.

Úvodní obrazovka je dle návrhu jednoduše řešená s jasnými vstupními body, kde je možné vytvořit nový odhad nebo otevřít jeden z uložených odhadů. Na ob-rázku níže je zobrazen vzhled implementace úvodní strany.

Obr. 15 Implementace – Úvodní strana

Tvorba nového odhadu je implementována jedním z navržených způsobů. Vybrán byl způsob rychlého odhadu, při kterém je po uživateli vyžadováno co nejméně vstupů pro vytvoření hrubého odhadu na samotném začátku projektu.


Obr. 16 Implementace – Tvorba projektu, krok 1

Na obrázku výše je možné vidět, že v kroku č. 1 průvodce tvorbou odhadu je povo-lená pouze první možnost. Na této obrazovce je nutné zadat název nového odhadu.

Dalším krokem tvorby nového odhadu je vybrání modulů, které bude uživatel chtít v novém projektu nasadit a tedy odhadnout. Na výběr jsou v této ukázce zvo-leny moduly firemního informačního systému z výčtu nákup, prodej, výroba, skla-dy, účetnictví, banka.


Obr. 17 Implementace – Tvorba projektu, krok 2

V dalších krocích již probíhá pouze potvrzení ukončení průvodce a aplikace se pře-sune na okno s výsledky odhadu. Stejné okno se zobrazí po otevření uloženého odhadu. Samotný odhad se zde počítá Nizozemskou metodou popsanou v kapitole 4.4.3. Vstupy pro tuto metodu se berou z průměrných hodnot v historických da-tech. Tím je docíleno vysokého uživatelského komfortu a hrubého odhadu bez nut-nosti vyplňovat vstupy do aplikace. Jako historická data byla použita odpovídající trénovací data. Pro představu je níže zobrazena krátká ukázka použitých trénova-cích dat:

Obr. 18 Implementace – vzorek trénovacích dat

K uchovávání hodnot byl zvolen textový soubor se záznamy rozdělenými do řádků a jednotlivými položkami oddělenými pomocí středníků. Níže je pro ilustraci zob-razena funkce, která načítá hodnoty z tohoto souboru s trénovacími daty a používá je pro načtení průměrných hodnot.


Obr. 19 Implementace – Ukázka kódu pracujícího s trénovacími daty

V další ukázce je metoda implementující výpočet pracnosti projektu pomocí meto-dy ISBSG. Vstupy do této metody přicházejí v parametrech metody a k rozhodnutí, kterou z rovnic metody využít je použito vstupu uživatele při tvorbě projektu.

Obr. 20 Implementace – Ukázka kódu implementujícího výpočet pracnosti projektu pomocí me-tody ISBSG


Obr. 21 Implementace – Výstup aplikace

Výstup aplikace zobrazuje textově popsané hodnoty reprezentující nejpravděpo-dobnější odhad doby tvorby nasazování projektu, pracnost projektu a jeho celko-vou cenu. Výsledné hodnoty je možné dále ovlivnit nastavením maximální velikosti týmu pomocí posuvníku. Data jsou také graficky reprezentována pomocí diagramu, který uvádí závislost měsíců práce zaměstnanců na rozvrhu práce v měsících.

84 Diskuze a závěr

9 Diskuze a závěr

V předešlých částech této práce byla úspěšně navrhnuta aplikace pro podporu tvorby odhadů zavádění informačního systému do společnosti dle požadavků v cíli práce. Úspěšnost návrhu byla dle záměru ověřena implementací částí návrhu, kte-rá na základě uživatelských vstupů dokáže samostatně vytvořit hrubý odhad ná-kladů. Postup vedoucí ke tvorbě a návrhu této aplikace byl zvolen s úmyslem na-vrhnout aplikaci se všemi náležitostmi týkajících se kvalitního návrhu bez zaměře-ní se na konkrétní druh hardware nebo software. V úvodních částech proběhlo se-známení se s teoretickými východisky a získání přehledu o principech odhadování software. V této části bylo využito zejména dostupné citované literatury.

Dalším krokem bylo provedení návrhu této aplikace. K tomu bylo využito gra-fického vyjádření funkčnosti aplikací s pomocí notace UML, která je uznávaná a univerzální. Zkušenosti nabrané za dobu univerzitního studia dopomohly tento velmi užitečný prostředek představující strukturu a funkčnost provést dostatečně jednoduše a přehledně. Díky využití návrhu za pomoci grafického nástroje je mož-no rychle se v provedené analýze zorientovat.

V implementační části této práce se objevily drobné prvky, které by mohly být v návrhu vylepšeny, nejednalo se ovšem o citelné ohrožení výsledné funkčnosti aplikace a byly to spíše drobnosti. Navržená aplikace disponuje funkcionalitou, která jí zajišťuje konkurenceschopnost na poli odhadů a odlišuje ji od existujících aplikací. Účel, cíle a požadavky na funkčnost aplikace stanovené v úvodu práce byly návrhem splněny. Diagramy návrhu byly provedeny s cílem maximalizace infor-movanosti a přehlednosti. Nebylo na nich proto zbytečně zobrazeno velké množ-ství prvků, které by do návrhu nepřinášely dostatečné zvýšení informovanosti čte-náře a pouze by snižovali jejich přehlednost a čitelnost.

Jednotlivé funkce rozebrané v předchozích kapitolách této práce jsou navrže-ny s ohledem na uživatelský komfort a jednoduchost práce s nimi. Po komplexním pohledu na celou aplikaci je možné konstatovat, že z uživatelského pohledu je možné celým tokem aplikace bez jakýchkoliv problémů projít. Aplikace poskytne základ pro vytvoření odhadu. V rámci testovací fáze implementované funkce byla aplikace předložena osobám bez zkušeností s odhady. Jejich postup byl intuitivní a za pomoci průvodce a přiložených nápověd bylo možné bez problémů odhad vy-tvořit. Jedná se o odhad za pomoci matematických funkcí jednotlivých metod a je-ho přesnost je tak dlouhodobě vyšší než u expertních odhadů. Hlavní nepřesnosti odhadu mohou nastat při změně podmínek vývoje informačního systému nebo zásadních neočekávaných změn.

V rámci budoucího vývoje by bylo vhodné provést průzkum, zda by uživatelé považovali data vkládaná do této aplikace za bezpečnostní riziko a v případě že ano, zvýšit bezpečnost ukládaných dat pomocí kódování nebo přístupových práv. V rámci této práce se vkládaná data nepovažovala za citlivé a bezpečnost byla ře-šena pouze ve smyslu ztráty těchto dat. Proti ztrátě byla navržena automatická opatření, která budou zajišťovat uložení vložených dat i po neočekávaném přeru-šení práce. Dalším důležitým krokem k budoucímu vylepšení aplikace by bylo zvý-

Diskuze a závěr 85

šení uživatelské přívětivosti aplikace, na kterou nebyl v této práci kladen velký důraz vzhledem k ověřovací funkci implementace.

Nástroje, které byly zvoleny pro částečnou implementaci a ověření správnosti návrhu, se ukázaly být vhodnými pro konstrukci výpočetně náročné aplikace, jako je tato. Implementace nebyla výběrem nástrojů limitována a byl na výběr bohatý rozsah modulů rozšíření.

Celá aplikace je dostupná na přiloženém CD. Ve složce Aplikace se nalézají zdrojové soubory implementované aplikace. Za pomoci těchto souborů je možné kompletní sestavení dané aplikace a její funkčnosti.

9.1 Návrh na využití v praxi

Navrženou aplikaci by bylo možné využít v praxi pro tvorbu rychlého hrubého od-hadu na počátku vývoje systému i pro tvorbu propracovaného a poměrně přesné-ho odhadu v průběhu jeho tvorby. Přesto, že tato aplikace může poskytnout velmi cenné odhady, je vhodné ji přesto kombinovat s dalšími přístupy k provedení od-hadů a tyto odhady poté kombinovat pro dosažení ještě vyšší přesnosti a spolehli-vosti.

Navržená aplikace je vhodná pro uživatele různých zkušeností s odhady. Pro méně zkušené uživatele je poskytován odhad s použitím minimálních vstupů a vý-sledného hrubého odhadu. Zkušenější uživatelé využijí zejména možnost vybrat si vlastní metodu výpočtu a jejich případné porovnání. To z této aplikace dělá velmi cenný nástroj pro tvorbu analýz na základě dostupných metod a srovnání výsled-ných odhadů pro různé vstupy.

86 Literatura

10 Literatura

ALBAKRI, M. M., QUERESHI, M. R. J. Measuring Effectiveness of COCOMO I and CO-COMO II Using a Case Study. Department of Information Technology, Faculty of Computing and Information Technology, King Abdulaziz University, Saudi Arabia. 2012 [cit. 2015-11-23]. Dostupné online: http://www.academia.edu/5890544/Measuring_Effectiveness_of_COCOMO_I_and_COCOMO_II_Using_a_Case_Study.

ARLOW, J. -- NEUSTADT, I. UML 2 a unifikovaný proces vývoje aplikací: objektově orientovaná analýza a návrh prakticky. 2. vyd. Brno: Computer Press, 2007. 567 s. ISBN 978-80-251-1503-9.

ATREYA, CH. On estimating project tasks. The Kanban Way: 2011 [cit. 2015-11-21]. Dostupné online: http://www.kanbanway.com/on-estimating-project-tasks.

BASL, J. -- BLAŽÍČEK, R. Podnikové informační systémy. Podnik v informační společ-nosti. 3. vyd. Praha: Grada Publishing, 2012. 325 s. ISBN 978-80-247-4307-3

BOEHM, B. Software Cost Estimation with COCOMO II. Prentice-Hall, 2000. 544 s. 978-0137025763.

BUCHALCEVOVÁ, A. Metodiky budování informačních systémů. Praha: Oeconomica 2009. 205s. 978-80-245-1540-3.

COCKBURN, A. Use Cases: jak efektivně modelovat aplikace. 1. vyd. Brno: Computer Press, 2005. 262 s. ISBN 80-251-0721-3.

CODEPROJECT, Software Project Cost Estimates Using COCOMO II Model. Codepro-ject [online]. 2005 [cit. 2015-11-16]. Dostupné online: http://www.codeproject.com/Articles/9266/Software-Project-Cost-Estimates-Using-COCOMO-II-Model.

DOLEŽAL, J. -- MÁCHAL, P. -- LACKO, B. a kol. Projektový management podle IP-MA. 2. vyd. Praha: Grada Publishing, 2012. 526 s. ISBN 978-80-247-4275-5.

EELES, P. CRIPPS, P. Architektura softwaru. Vyd. 1. Brno: Computer Press, 2011, 328 s. ISBN 978-80-251-3036-0.

ERIKSSON, H. E. -- PENKER, M.; (2000). Business Modeling with UML. Dostupné on-line: http://ges.dc.ufscar.br/posgraduacao/UML_2_Toolkit.pdf

GARMUS, D. -- HERRON, D., Function Point Analysis: Measurement Practices for Suc-cessful Software Projects. Upper Saddle River, NJ, USA: Addison-Wesley Profes-sional, 2000. 400 s. 978-0201699449.

HANSEN, J. Use Case Point Estimation. Estimate your project by looking at your use cases. All about requirements [online]. 2012 [cit. 2015-11-24]. Dostupné onli-ne: http://www.allaboutrequirements.com/2012/12/use-case-point-estimation-estimate-your-project-by-looking-at-your-use-cases.html

ISBSG. Practical Software Project Estimation: A Toolkit for Estimating Software De-velopment Effort & Duration. 1. Vyd. McGraw-Hill Education, 2010. 312 s. 978-0071717915.

http://ges.dc.ufscar.br/posgraduacao/UML_2_Toolkit.pdf

Literatura 87

JONES, C. Applied software measurement: assuring productivity and quality. 2. vyd. Hightstown, NJ, USA. McGraw-Hill, Inc., 1997. 0-07-032826-9.

JONES, C. Software Assessments, Benchmarks, and Best Practices. Addison-Wesley Professional, 2000. 688 s. 978-0201485424.

JŮZA, P. Odhadování projektů [online]. 2012, [cit. 2015-12-01]. Dostupné online: http://javicka.blogspot.cz/2012/09/odhadovani-projektu.html

KANISOVÁ, H. -- MÜLLER, M. UML srozumitelně. 2. vyd. Brno: Computer Press, 2006. 176 s. ISBN 80-251-1083-4.

KLČOVÁ, H. -- SODOMKA, P. Informační systémy v podnikové praxi. Brno: Computer press, 2010. ISBN 978-80-251-2878-7.

KUČEROVÁ, H. Diagram tříd [online]. Praha: Vyšší odborná škola informačních slu-žeb. 2007, [cit. 2010-12-07]. Dostupné online: http://web.sks.cz/users/ku/pri/tridy.htm

MCCONNELL, S. Odhadování softwarových projektů: jak správně určit rozpočet, ter-mín a zdroje. 1. vyd. Brno: Computer Press, 2006. 317 s. ISBN 80-251-1240-3.

PROFINIT. Doporučení pro tvorbu odhadů [online]. 2013 [cit. 2015-09-15]. Dostup-né online: http://www.newfrontier.eu/fileadmin/Content/profinit.eu/Academy/sweng-materialy/odhady/Profinit_metodika_tvorby_odhadu.pdf

PUTNAM, L. H.; WARE M. Five core metrics : the intelligence behind successful soft-ware management. Dorset House Publishing, 2003. ISBN 0-932633-55-2.

Qt Project [online]. © 2015 [cit. 2015-12-08]. Dostupné online: http://doc.qt.io/

RÁBOVÁ, I. Podnikové informační systémy a technologie jejich vývoje. Brno: Tri-bun EU, 2008. 978-80-7399-599-7.

RÁČEK, Jaroslav. Strukturovaná analýza systémů. Brno: Masarykova univerzita, 2006. 104 s. FI. ISBN 80-210-4190-0.

ROSENAU, M D. Řízení projektů. 3. vyd. Brno: Computer Press, 2010. 344 s. ISBN 978-80-251-1506-0.

ŘEPA, V. Podnikové procesy: Procesní řízení a modelování. 2., aktualizované a rozší-řené vydání. Praha: Grada Publishing, 2007. 282 stran. ISBN: 978-80-247-2252-8.

ŘEPA, V. Procesně řízená organizace. Praha: Grada Publishing, 2012. 302 stran. ISBN: 978-80-247-4128-4.

SCHWALBE, K. Řízení projektů v IT: kompletní průvodce. Brno: Computer Press, 2011. 632 s. ISBN 978-80-251-2882-4.

STUTZKE, R. Estimating Software-Intensive Systems. Upper Saddle River, NJ: Addi-son-Wesley, 2005. 978-0321904928.

SUTHERLAND, J. Scrum: The Art of Doing Twice the Work in Half the Time. Crown Business, 2014. 256 s. 978-0385346450.

UČEŇ, P. Metriky v informatice: jak objektivně zjistit přínosy informačního systému. Praha: Grada, 2001. 139 s. 80-247-0080-8.

https://is.muni.cz/osoba/3444

88 Literatura

VOŘÍŠEK, J. a kol. Principy a modely řízení podnikové informatiky. 1. vyd. Praha: Oe-conomica, 2008. ISBN 978-80-245-1440-6.

VRANA, I. -- RICHTA, K. Zásady a postupy zavádění podnikových informačních sys-témů: praktická příručka pro podnikové manažery. 1. vyd. Praha: Grada Pu-blishing, 2005. 187 s. Management v informační společnosti. ISBN 80-247-1103-6.

VYMĚTAL, D. Informační systémy v podnicích. Praha: Grada Publishing, 2009. 144 s. ISBN 978-80-247-3046-2.

VYTLAČIL, D. Projektové řízení a řízení projektů. Praha: Česká technika - naklada-telství ČVUT, 2008. 142 s. ISBN 978-80-010-4001-0.

Přílohy 89

Přílohy

90

Diagram požadavků 91

A Diagram požadavků

Obr. 22 Diagram požadavků doplněný o případy užití realizující jednotlivé požadavky

92 Diagram požadavků

Obsah přiloženého CD 93

B Obsah přiloženého CD

Na přiloženém CD jsou přiloženy zdrojové soubory k implementované aplikaci a instalační soubory prostředí WinPython, pomocí kterého se nainstalují všechny potřebné knihovny a aplikace potřebné ke spuštění těchto souborů.

V souboru Aplikace se nacházejí zdrojové kódy implementované aplikace.

V souboru WinPython se nacházejí instalační soubory prostředí WinPython s knihovnami. Pomocí tohoto nástroje je možné plně sestavit přiložené zdro-jové soubory a spustit aplikaci. Použitá verze tohoto nástroje WinPython-64bit-3.4.3.5 je možné také stáhnout na oficiální stránce: http://winpython.github.io/

http://winpython.github.io/

Documents

Aplikace pro podporu odhadu nákladů nasazování informačního … · 2016-01-04 · Čestné prohlášení Prohlašuji, že jsem tuto práci: Aplikace pro podporu odhadu nákladů