Aplikace pro podporu odhadu nákladů nasazování informačního systému

Mendelova univerzita v Brně Provozně ekonomická fakulta

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 Brno 2015

Tímto bych velmi rád poděkoval vedoucímu této diplomové práce doc. Ing. Oldřichu Trenzovi Ph.D. za odborné vedení této práce, při kterém mi poskytl velmi cenné 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ětná 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 deployment. Diploma thesis. Brno: Mendel University, 2015. This diploma thesis deals with cost estimation issue and design of software application assisting while creating such estimates. This application should provide an alternative to other approaches of information system cost estimates. In the theoretical 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, Python, application modelling, UML.

Abstrakt Mikóczy, T. Aplikace pro podporu odhadu nákladů nasazování informačního systému. Diplomová práce. Brno: Mendelova univerzita v Brně, 2015. Tato diplomová práce se zabývá problematikou odhadu nákladů a navržení aplikace, 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 zaměř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ávnost 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, Python, návrh aplikace, UML.

Obsah

11

Obsah 1

2

Úvod a cíl práce 1.1

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

1.2

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

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

3

19

21

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

Odhady a jejich přínosy 3.1

24

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

4

Obsah

3.5.3

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

3.5.4

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

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í 6.1

7

8

57

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

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

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

9

Obsah

Diskuze a závěr 9.1

84

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

26

Kužel nejistoty (Jůza, 2012)

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

71

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

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


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

83

Implementace – Výstup aplikace

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á pomýš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 firemní 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 metod 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 vybraný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étních implementačních nástrojů. Správnost návrhu bude ověřena implementací části 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 podobné 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ů spojených se zaváděním informačního systému do společnosti, a to i neodborným uživatelů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, softwaru 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 poskytují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, hardwaru, lidí, činností a zdrojů. Důležitým aspektem systému je ICT složka, tedy informační a komunikační technologie, které usnadňují plnění účelu systému. U informač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, nebude 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 opakujících se metodik, u kterých dříve získáme historická data týkající se daného projektu 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 projektu (McConnell, 2006). 2.1.1

RUP

Tato metodika je charakterizována jako proces, který představuje přístup přiřazují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


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ě vybírají ze zásobníků dříve plánovaných úkolů. Často se pořádají velmi krátké schůzky, kde členové týmu řeší každodenní problémy při vývoji systému (BUCHALCEVOVÁ, 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ždodenně 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.


2.2

23

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í informač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 popisuje 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 prezentovaný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 projekt 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 projektového řízení, a pokud toto projekt a jeho vedení nesvedou, je odhad, jak bude projekt probíhat a jaké zdroje bude potřebovat, jen velmi obtížný (Řepa, 2008).

24

Odhady a jejich přínosy

3 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ý software 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áhnout 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 vzhledem 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 tedy protažena do nekonečna.


Obr. 1

25

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 dopomoct 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 skuteč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 nejviditelnější, zda jde o odhad shora-dolů nebo zdola-nahoru. To je zásadně určeno výchozí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

26

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 statistik 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 realisticky 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 nejistotu v poskytovaném odhadu. Dle McConella (2006) průzkumy ukázaly, že přesnost 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-46502656-7. 2


27

odhadů závisí na úrovni rafinovanosti definice softwaru. Propracovaněji definované 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 konzistentně. Primárně by měly být proto využívány přístupy, které lze snadno a konzistentně opakovat. Takovým typem jsou zejména výpočetní metody. U algoritmický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 použ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 metodiky.  Pružnost – Za velmi pružnou metodiku můžeme označit takový postup, který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étních situacích je specifičnost metody ovšem výhodou.  Efektivita – U metodik, které lze ohodnotit jako efektivní, by nemělo být obtížné pochopit jeho použití. U aplikací, které podporují modely, by tuto vlastnost 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í obory, 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

28


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í mezi 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é programy 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

29

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 jiný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ě vyví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.

30

3.5


Používané metodiky pro odhad

Existuje mnoho způsobů, jak k odhadům přistupovat. Může to být cestou zkušeností, 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 nejpodrobnější rozbor veličin těchto projektů. V případě odhadování použitím analogie je nutné nejprve získat co nejdetailně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ávislosti 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ředchozího systému vynásobený zjištěným poměrem mezi nimi. Velké odchylky mohou 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ěrný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 zjednoduš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í


31

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 navrhujete architektonicky podobné aplikace, je možno využít i tzv. Standardní komponentu. 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 projektu 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řidě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

32


případě může dojít ke zmatení odhadovatele a snížení platnosti výpočtů a je vhodně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 levné 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 dané 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ásledujícího vzorce: V Kde:    

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

V

V V


3.5.4

33

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řesnější. Čím důkladnější bude diskuze při porovnávání rozdílností odhadů, tím přesně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 odhadovatele 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 odsouhlasení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


4 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í algoritmický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 pracnosti, č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 velič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ý Putnamů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 Code). 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 (Albakri, 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 aktualizová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 projektů. 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 podrobně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í modelu 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 modely 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). Hlavními způsoby zjištění této hodnoty jsou např. pomocí analogií, automatických programů 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 neekonomické 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í.

36


Tab. 1

Přehled jednotlivých faktorů a jejich popis

Typ faktoru

Faktory velikosti

Označení a název faktoru

Popis faktoru

PREC - Precedentedness

Míra zkušenosti s podobnými projekty

FLEX - Development Flexibility

Flexibilita vývoje

RESL - Architecture / Risk Resolution

TEAM - Team Cohesion

PMAT - Process Maturity

Řešení architektury a rizika Soudržnost týmu (podobné cíle, zkušenosti, firemní kulturu) Vyspělost procesu

Faktory modelu Post-Architecture RELY - Required Software Reliability Vlastnosti produktu

DATA - Database Size CPLX - Product Complexity RUSE - Developed for Reusability DOCU - Documentation TIME - Execution Time Constraints

Vlastnosti platformy

Charakteristiky lidí

STOR - Main Storage Constraint PVOL - Platform Volatility ACAP - Analyst Capability PCAP - Programmer Capability PCON - Personnel Continuity APEX - Application Experience PLEX - Platform Experience LTEX - Language and Tool Experience

Požadovaná spolehlivost SW Velikost databáze Složitost produktu Vývoj znovupoužitelného kódu Adekvátnost rozsahu dokumentace Omezení na použitý strojový čas Omezení na využití paměti počítače Proměnlivost platformy Schopnosti analytiků Schopnosti programátorů Trvanlivost zaměstnanců Zkušenosti s vývojem typu systému Zkušenosti s danou platformou Zkušenosti s programovacím jazykem a nástroji


37

Stupeň použití softwarových nástrojů pro vývoj

TOOL - Use of Software Tools Vlastnosti projektu

SITE - Multisite Development SCED - Required Development Schedule

Vývoj na více místech 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

PERS - Personnel Capability PREX - Personnel Experience FCIL - Facilities SCED - Required Development Schedule

Kombinace multiplikátorů TIME, STOR a PVOL Kombinace multiplikátorů ACAP, PCAP a PCON Kombinace multiplikátorů APEX, PLEX a LTEX Kombinace multiplikátorů TOOL a SITE z PA modelu Stejný jako v PA modelu

Zdroj: Boehm, 2000

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

38


Tab. 2

Hodnoty faktorů metody Cocomo II

FAKTOR PREC FLEX RESL TEAM PMAT RELY DATA CPLX RUSE DOCU TIME STOR PVOL ACAP PCAP PCON AEXP PEXP LTEX TOOL SITE SCED

TYP SF SF SF SF SF EM EM EM EM EM EM EM EM EM EM EM EM EM EM EM EM EM

VL 0.5 0.5 0.5 0.5 0.5 0.75 0.75 0.85

1.5 1.37 1:26 1.23 1.26 1.24 1.2 1.24 1.23

L 0.04 0.04 0.04 0.04 0.04 0.88 0.94 0.88 0.89 0.93

0.87 1.22 1.16 1.11 1.1 1.12 1.11 1.1 1.1 1.08

N 0.03 0.03 0.03 0.03 0.03 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

H 0.02 0.02 0.02 0.02 0.02 1.15 1.08 1.15 1.16 1.08 1.11 1.06 1.15 0.83 0.87 0.91 0.88 0.88 0.9 0.88 0.92 1.04

VH 0.01 0.01 0.01 0.01 0.01 1.4 1.16 1.3 1.34 1.17 1.3 1.21 1.3 0.67 0.74 0.83 0.8 0.8 0.82 0.75 0.85 1.1

XH 0 0 0 0 0

1.65 1.56 1.66 1.56

0.79

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.


39

 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 metody 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í funkcionalit 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

40


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 poslá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 automatická 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 externí soubory rozhraní. Důležité je, že vstupy neaktualizují vnitřní strukturu 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 souborů. 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 referenci 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říkladem 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.

lgoritmické přístupy k odhadům Tab. 3

41

Multiplikátory objektů FPA

Charakteristika EI EO EQ ILF EIF

Komplexnost Průměrná 4 5 4 10 7

Nízká 3 4 3 7 5

Vysoká 6 7 6 15 10

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

Celkový počet funkčních celků před úpravou pak dostaneme aplikací níže uvedené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ň 0 1 2 3 4 5

Vliv Žádný Náhodný Nízký Průměrný Významný 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í:

42


∑ 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.


43

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

3.

Výkon

4.

Plné využití konfigurace

5.

Přenosová rychlost

Jak se zachází s distribuovanými daty a funkcemi? Byl průtok nebo odezva uživatelským požadavkem? Vytíženost aktuálního hardware, kde bude systém spuštěný? Frekvence spouštění přenosů(denně, týdenně, měsíčně)

6.

Vstup síťových dat

7.

Efektivnost uživatele

8.

Síťová aktualizace

9.

Složitost

10.

Znovupoužitelnost

11.

Jednoduchost instalace

12.

Jednoduchost ovládání

13.

Množství pracovišť

14.

Jednoduchost úprav

Jaké procento dat je zdáváno online? Byla aplikace navržena pro efektivnost koncového uživatele? Kolik ILF je aktualizováno online přenosy? Má aplikace logicky nebo matematicky složitou funkcionalitu? Byla aplikace vyvinuta dle požadavků jednoho nebo více uživatelů? Jak složitá je instalace? Jak efektivní a automatizované jsou metody spuštění a zálohy? Byla aplikace vyvinuta k instalaci na více pracovištích pro více organizací? 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.

44


Tab. 6

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

Programovací jazyk ABAP (SAP) ASP Assembler Brio C C++ C# COBOL Excel HTML J2EE Java JavaScript JCL LINC II Lotus Notes .NET Oracle Perl PL/SQL SQL VB.NET Visual Basic

Převod SLOC/FP Průměr 28 51 119 14 97 50 54 61 209 34 46 53 47 62 29 23 57 37 24 37 21 52 42

Medián 18 54 98 14 99 53 59 55 191 40 49 53 53 48 30 21 60 40 15 35 21 60 44

Minimum 16 15 25 13 39 25 29 23 131 14 15 14 31 25 22 19 53 17 15 13 13 26 20

Maximum 60 69 320 16 333 80 70 297 315 48 67 134 63 221 38 40 60 60 60 60 37 60 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á historická data s informacemi o této činnosti v minulosti.


4.4.3

45

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 (NEMSA). V této metodě jsou počítány pouze ILF a EIF. Informativní součet je poté vypoč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 celků 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 který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). Neupravené váhy aktérů (UAW – Unadjusted Actor Weight) dostaneme obdobným způsobem, 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ů Lokální systém Vzdálený systém Uživatel

Váha 1 2 3

Zdroj: http://www.allaboutrequirements.com/2012/12/use-case-point-estimation-estimate-yourproject-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 – Environmental Complexity Factor). Níže zobrazené tabulky popisují jednotlivé faktory a jejich váhy.

46 Tab. 8

Algoritmické přístupy k odhadům Přehled faktorů technické složitosti a jejich vah

Technický faktor Distribuce systému Výkon Efektivita koncového uživatele Složité vnitřní procesy Znovupoužitelnost Jednoduchost instalace Jednoduchost použití Přenositelnost Jednoduchost změn Souběžnost Speciální ochranné prvky Přímý přístup třetích stran Požadavek speciálních školení

Váha 2 1 1 1 1 0,5 0,5 2 1 1 1 1 1

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

Přehled faktorů prostředí a jejich vah

Faktor prostředí Obeznámenost s UML Pracovníci na částečný úvazek Schopnosti analytika Zkušenosti s aplikací Zkušenosti s objekty Motivace Složitost programovacího jazyka Stálost požadavků

Váha 1,5 -1 0,5 0,5 1 1 -1 2

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

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: ý (

ý

)


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. Jednak je možné porovnat podobné projekty z historických dat, popř. průměru odvětví. 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 McConnella (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 porovná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 časové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í rovnice 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-

48


zena níže udává odhad v kalendářních měsících při průměrné produktivitě vývojové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 odhadování finanční stránky softwaru je jednoduchou příležitostí a lze jednoduše odvodit 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ěpodobnost 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.


49

Typická hustota chyb dle velikosti systému

Velikost systému (v řádcích kódu) Méně než 2000 2000 – 16000 16000 – 64000 64000 – 512000 512000 a více

Typická hustota chyb (na 1000 řádek kódu) 0 – 25 0 – 40 0,5 – 50 2 – 70 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 projektech. 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í Regresní testování Neformální revize kódu Testování po jednotkách Testování nových komponent Neformální revize kódu Nízkokapacitní beta testování Osobní revize kódu Systémové testování Formální inspekce kódu Formální inspekce kódu Modelování nebo prototypy Vysokokapacitní beta testování

Odstraněných chyb 25 % 25 % 30 % 30 % 35 % 35 % 40 % 40 % 55 % 60 % 65 % 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 %.

50


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é marketing, cenu obchodníků, režii nebo například speciální vývojové nástroje a hardware. 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ákladech 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í nejví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 nade všechny meze, to by ale uživatel neakceptoval. Nejvhodnějším prostředkem pro prezentaci odhadů v aplikaci se zdá být grafické, kde lze jednoduše vyjádřit závislost několika jevů. Uživatel tak dostane rychle 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.


51

4.10 Existující aplikace Aktuálně je na trhu několik aplikací, které mají za úkol automatizovat odhady. Jejich 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ě existují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řidaná 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 minulý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á společnosti Softstar Systems.  KnowladgePLAN – Placená aplikace postavená na úzké spolupráci s programem Microsoft Project.

52


5 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 hardwarem 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 pravý 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 prezentuje 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í systému.  Diagramy interakcí (Interaction diagram) zahrnují 4 typy diagramů: o Sekvenční diagram (Sequence diagram) prezentující spolupráci objektů sekvencemi posílaných zpráv. o Komunikační diagram (Communication diagram) prezentuje interakci 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).

54


Obr. 4

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

5.2.2


Diagram případů užití, neboli Use Case model, je grafickým zobrazením části dokumentu 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ěstačný i bez něho. Naopak případ užití s relací include je funkčně závislý na předchozím případu užití.

troje pro návrh aplikace

5.2.3

55

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 konečným počtem stavů. Diagram je tvořen stavy a přechody mezi stavy. Stav je přitom 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 jasnou představu o struktuře aplikace. Diagram těchto tříd proto tvoří základ v návrhu 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 prvky 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 objekty) (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 notaci 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řístupu.

5.4

Eriksson-Penker

Je jedním z nejpoužívanějších profilů UML, zejména pro potřeby modelování podnikových procesů. Tato integrovaná metoda je velmi podrobně vysvětlena v (Erikson, 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 modelová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 postavený na diagramu případů užití z UML. Tento diagram definuje požadovanou funkci-

56


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í odhad nákladů vývoje, případně rozšíření, informačního systému jednoduchou formou. 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 pochopení 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í stanovení 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 konkré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 vybrá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í poskytnutí 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 hodnot odhadů bude využito vzorce PERT. Je možné zvolit i odlišný přístup a vytvořit novou metodiku než doposud existují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 identifikované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. Poskytovala 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ů implementace, možných implementačních prostředí nebo platformách. Bude co nejobecněji popisovat možný způsob navržení zamýšlené aplikace. V této části se nalé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 ErikssonPenker, která je rozšířením notace BPMN použitelnou k návrhu aplikace. K podrobně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 podrobnou 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 identifikovat, 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 automaticky 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í

7.2

59

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 otevř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    

2.

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ů. 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      

2.

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. 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í implementují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 informač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 spravovat dříve vytvořené odhady nebo vytvořit nový. Pro načtení uložených odhadů bude 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 systé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živatelů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 automatický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ředlož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 porovná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 odhadu. 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ě odhadované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 historický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 obsahovat bude veškerá data v grafické i textové podobě související s provedeným odhadem. V závěru bude uživatel mít možnost doplnit svá historická data o právě provedený odhad. Tím by dosáhl větší přesnosti v budoucnosti.

vrh řešení

Obr. 5

7.4

63

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


Pro zvýšení přehlednosti a zdůraznění funkcionality aplikace byl vytvořen i uživatelský 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 schopná vykonat.

64

Obr. 6

Návrh řešení


vrh řešení

7.5

65

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í dostateč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

Obr. 7

Návrh řešení

Diagram aktivit – Tvorba projektu

vrh řešení

7.5.2

67

Automatické určení metody tvorby projektu

Automatický výběr metody algoritmem volně vychází z návrhu uvedeného v (Bielas, 2013). Tento návrh je založen na vícekriteriálním rozhodování s využitím modifikované metody PRIAM. V této publikaci byl proveden podrobný rozbor jednotlivých metod s analýzou výsledků a poté byl získán přehled vhodnosti použití jednotlivý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ů

Nutné FP Funkční celnebo LOC ky

Případy užití Funkční celky

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 1 – Kdykoliv 2 – Střední fáze 3 – Brzká fáze 1 – Velice přesná 2 – Poměrně přesná 3 – Nepřesná 1 – Vyšší 2 – Střední 3 – Nižší 1 – Nižší 2 – Střední 3 – Vyšší 1 – Není nutná 2 – Nutná znalost FP nebo LOC 3 – Nutná znalost případů použití

Fáze vývoje Přesnost návrhu Zkušenosti týmu Rychlost Znalost vstupů Zdroj: Bielas, 2013

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

Seřazené ohodnocení faktorů metod

F5 Funkční celky COCOMO Případy užití Nizozemská metoda

1 2 3 2

F3 3 1 2 3

F1 1 1 2 3

F2 2 1 2 3

F4 2 3 1 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í odhadu. 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ší obrazovku zadávání vstupních hodnot. Také každých 30 sekund proběhne automatické uložení projektu do této paměti. Po dokončení tvorby projektu je možné zvolit uložení projektu. K tomu dojde přesunem dat z paměti aktuální práce do databá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 aktualizaci zobrazovaného obsahu aplikace. Hlavní obrazovka tak již nebude zobrazovat nabídku pro otevření nebo vytvoření odhadu, ale bude zobrazen výstupní odhad 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í

Obr. 9

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

7.5.5

Použití historických dat

71

Historická data budou použita ke zpřesnění výpočtu prováděných odhadů. U jednotlivý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žitých vstupů od uživatele. U ostatních metod budou historická data sloužit pro doplně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

7.6

Návrh řešení

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 obsahuje 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 dokonč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 identifiká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 Název projektu Použité moduly Velikost nasazovaného projektu Délka nasazení systému Pracnost nasazení systému Cena nasazení systému

Popis atributu Název projektu, kterého se odhad týká Moduly, které byly v daném projektu nasazovány do systému Velikost vyjádřená v SLOC/FP Délka nasazování určená v měsících Pracnost projektu vyjádřená v člověkoměsících 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 jedineč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 Identifikátor Název projektu Způsob tvorby Metoda výpočtu Vstupní data

Popis atributu Jedinečný identifikátor odhadu určující pořadové číslo prováděného odhadu Název projektu, ze kterého odhad pochází Způsob, jakým byl odhad vytvářen Metoda, která byla k výpočtu použita Vstupní data od uživatele

74


8 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čítka 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ů.


Obr. 12

75

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ů.

76


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í.

Implementace navrženého řešení Tab. 18

77

Srovnání výhod tvorby rozhraní v Qt

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

Qt Quick QML/JS X X X X

Qt Widgets C++ X X

(X) X X X X

Qt WebKit HTML/CSS/JS (X)

X X (X) X 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ýhodou 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 systé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ý skriptovací 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.

78

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í vybraných technologií.

Obr. 14

Diagram tříd implementované aplikace

Jako historická data byla použita data trénovací vygenerovaná náhodným algoritmem. V reálném systému by tato data byla vložena uživatelem nebo by byla použita 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

79

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 obrá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.

80

Obr. 16



Na obrázku výše je možné vidět, že v kroku č. 1 průvodce tvorbou odhadu je povolená 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 zvoleny moduly firemního informačního systému z výčtu nákup, prodej, výroba, sklady, účetnictví, banka.


Obr. 17

81


V dalších krocích již probíhá pouze potvrzení ukončení průvodce a aplikace se přesune 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 datech. Tím je docíleno vysokého uživatelského komfortu a hrubého odhadu bez nutnosti 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énovací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 zobrazena 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.

82

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í metody 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í metody ISBSG


Obr. 21

83

Implementace – Výstup aplikace

Výstup aplikace zobrazuje textově popsané hodnoty reprezentující nejpravděpodobnější odhad doby tvorby nasazování projektu, pracnost projektu a jeho celkovou 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, která 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 navrhnout aplikaci se všemi náležitostmi týkajících se kvalitního návrhu bez zaměření se na konkrétní druh hardware nebo software. V úvodních částech proběhlo sezná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 grafické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 informovanosti 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 čtenář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ženy 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 vytvořit. Jedná se o odhad za pomoci matematických funkcí jednotlivých metod a jeho 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 odhadu 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í odhadů a tyto odhady poté kombinovat pro dosažení ještě vyšší přesnosti a spolehlivosti. 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ýsledných odhadů pro různé vstupy.

86

Literatura

10Literatura ALBAKRI, M. M., QUERESHI, M. R. J. Measuring Effectiveness of COCOMO I and COCOMO 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. Codeproject [online]. 2005 [cit. 2015-11-16]. Dostupné online: http://www.codeproject.com/Articles/9266/Software-Project-CostEstimates-Using-COCOMO-II-Model. DOLEŽAL, J. -- MÁCHAL, P. -- LACKO, B. a kol. Projektový management podle IPMA. 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é online: http://ges.dc.ufscar.br/posgraduacao/UML_2_Toolkit.pdf GARMUS, D. -- HERRON, D., Function Point Analysis: Measurement Practices for Successful Software Projects. Upper Saddle River, NJ, USA: Addison-Wesley Professional, 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é online: http://www.allaboutrequirements.com/2012/12/use-case-pointestimation-estimate-your-project-by-looking-at-your-use-cases.html ISBSG. Practical Software Project Estimation: A Toolkit for Estimating Software Development Effort & Duration. 1. Vyd. McGraw-Hill Education, 2010. 312 s. 9780071717915.

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, termí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]. Dostupné online: http://www.newfrontier.eu/fileadmin/Content/profinit.eu/Academy/swengmaterialy/odhady/Profinit_metodika_tvorby_odhadu.pdf PUTNAM, L. H.; WARE M. Five core metrics : the intelligence behind successful software 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: Tribun 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-2472252-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: Addison-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.

88

Literatura

VOŘÍŠEK, J. a kol. Principy a modely řízení podnikové informatiky. 1. vyd. Praha: Oeconomica, 2008. ISBN 978-80-245-1440-6. VRANA, I. -- RICHTA, K. Zásady a postupy zavádění podnikových informačních systémů: praktická příručka pro podnikové manažery. 1. vyd. Praha: Grada Publishing, 2005. 187 s. Management v informační společnosti. ISBN 80-2471103-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 - nakladatelství ČVUT, 2008. 142 s. ISBN 978-80-010-4001-0.

Přílohy

89

Přílohy

90

Diagram požadavků

A Diagram požadavků

Obr. 22

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

91

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é zdrojové soubory a spustit aplikaci. Použitá verze tohoto nástroje WinPython64bit-3.4.3.5 je možné také stáhnout na oficiální stránce: http://winpython.github.io/

Aplikace pro podporu odhadu nákladů nasazování informačního systému

Recommend Documents