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

Transkript

1 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

2

3

4

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

6

7 Č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

8

9 Abstract Mikóczy, T. Application supporting cost estimation of information system deployment. Diploma thesis. Brno: Mendel University, 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ě, 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.

10

11 Obsah 11 Obsah 1 Úvod a cíl práce Úvod Cíl práce Vývoj informačního systému a jeho řízení Přístupy k vývoji systému RUP SCRUM Prototypování Extrémní programování Fáze vývoje informačního systému Projektové řízení Odhady a jejich přínosy Proč odhad? Co je to odhad? Dobrý odhad Charakteristiky odhadů Přesnost odhadů Konzistentnost Užitečnost Metriky odhadů Počítání řádků kódu Funkční celky Případy užití Lidská práce za jednotku času Kalibrace dat Používané metodiky pro odhad Metody s použitím analogie Metoda s použitím zástupce... 30

12 12 Obsah Metoda expertních odhadů Skupinové hodnocení Algoritmické přístupy k odhadům Putnamův model Cocomo II Early Design a Post-Architecture model Možnosti přizpůsobení modelu konkrétní organizaci Metoda bodů případů užití (Use Case Points) Analýza funkčních celků (FPA) Hlavní komponenty Upravené funkční celky Nizozemská metoda Analýza případů užití Odhadování pracnosti projektu Odhadování časového rámce projektu Odhadování ceny projektu Rizika a hrozby Odhadování chyb Počet prostředí Přímé náklady Přesčasy Možné druhy prezentace odhadu Existující aplikace Nástroje pro návrh aplikace Softwarové požadavky Notace UML Struktura jazyka Diagram případů užití Diagram aktivit Stavový diagram Diagram tříd... 55

13 Obsah Diagram požadavků Eriksson-Penker Metodika řešení Vybrané metodiky Návrh řešení Identifikace uživatele a definice účelu aplikace Analýza požadavků Designové požadavky Funkční požadavky Požadavky na výkon Omezení návrhu Vlastnosti systému Popis logické funkcionality systému Diagram případů užití Rozbor hlavních metod Obecný postup při tvorbě projektu Automatické určení metody tvorby projektu Uložení odhadu Načtení uloženého odhadu Použití historických dat Diagram tříd Struktura datových úložišť Implementace navrženého řešení Návrh vzhledu Popis použitých nástrojů QT Designer Python Propojení kódu v Pythonu s QT návrhem Definice rozsahu implementace Navržená aplikace... 79

14 14 Obsah 9 Diskuze a závěr Návrh na využití v praxi Literatura 86 A Diagram požadavků 91 B Obsah přiloženého CD 93

15 Obsah 15

16 16 Seznam obrázků Seznam obrázků Obr. 1 Křivka představující pravděpodobnost dokončení projektu (Atreya, 2011) 25 Obr. 2 Kužel nejistoty (Jůza, 2012) 26 Obr. 3 Přehled reprezentací vlastností systému v různých fázích vývoje (Hansen, 2012) 28 Obr. 4 Rozdělení UML diagramů (Arlow, 2007) 54 Obr. 5 Základní schéma aplikace pomocí Eriksson-Penker notace 63 Obr. 6 Diagram případů užití 64 Obr. 7 Diagram aktivit Tvorba projektu 66 Obr. 8 Stavový diagram Přehled stavů při ukládání a načítání dat z paměti 70 Obr. 9 Diagram aktivit Načtení uloženého odhadu 71 Obr. 10 Diagram tříd aplikace 72 Obr. 11 Návrh vzhledu úvodní obrazovky 74 Obr. 12 Návrh vzhledu obrazovky s přehledem výstupu 75 Obr. 13 Zobrazení přechodů mezi jednotlivými nástroji 76 Obr. 14 Diagram tříd implementované aplikace 78 Obr. 15 Implementace Úvodní strana 79 Obr. 16 Implementace Tvorba projektu, krok 1 80 Obr. 17 Implementace Tvorba projektu, krok 2 81 Obr. 18 Implementace vzorek trénovacích dat 81 Obr. 19 Implementace Ukázka kódu pracujícího s trénovacími daty 82 Obr. 20 Implementace Ukázka kódu implementujícího výpočet pracnosti projektu pomocí metody ISBSG 82 Obr. 21 Implementace Výstup aplikace 83 Obr. 22 Diagram požadavků doplněný o případy užití realizující jednotlivé požadavky 91

17 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 18 Seznam tabulek

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

21 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) 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 22 Vývoj informačního systému a jeho řízení 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 (BUCHALCE- VOVÁ, 2009). Z pohledu jednotlivých SPRINTů se jedná o postupný odhad, v širším pohledu, kdy mezi jednotlivými sprinty nejsou známy další požadavky, se ovšem jedná o postup opakovaný (SUTHERLAND, 2014) 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 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.

23 Vývoj informačního systému a jeho řízení 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 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 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 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.

25 Odhady a jejich přínosy 25 Obr. 1 Křivka představující pravděpodobnost dokončení projektu (Atreya, 2011) Dle McConnella (2006) by měl dobrý odhad poskytovat dostatečnou představu o reálném projektu, aby jeho vedení mohlo provádět správná rozhodnutí a 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 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 26 Odhady a jejich přínosy 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 2 Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid Gödel, Escher, Bach: An Eternal Golden Braid. 20th anniversary ed., 1999, p ISBN

27 Odhady a jejich přínosy 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 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 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 28 Odhady a jejich přínosy 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) 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 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) 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).

29 Odhady a jejich přínosy 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 30 Odhady a jejich přínosy 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 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í 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 Odhady a jejich přínosy 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ž 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 32 Odhady a jejich přínosy 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 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 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: Kde: V V V V VRCH = Velikost relativní chyby odhadu AM = Absolutní měřítko SV = Skutečný výsledek OV = Očekávaný výsledek

33 Odhady a jejich přínosy 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 34 Algoritmické přístupy k odhadům 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.

35 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 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 = 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 36 Algoritmické přístupy k odhadům Tab. 1 Přehled jednotlivých faktorů a jejich popis Typ faktoru Označení a název faktoru Popis faktoru PREC - Precedentedness Míra zkušenosti s podobnými projekty FLEX - Development Flexibility Flexibilita vývoje Řešení architektury a RESL - Architecture / Risk rizika Resolution Faktory velikosti Soudržnost týmu TEAM - Team Cohesion (podobné cíle, zkušenosti, firemní kulturu) PMAT - Process Maturity Vyspělost procesu Faktory modelu Post-Architecture RELY - Required Software Reliability Požadovaná spolehlivost SW Vlastnosti produktu Vlastnosti platformy Charakteristiky lidí DATA - Database Size CPLX - Product Complexity RUSE - Developed for Reusability DOCU - Documentation TIME - Execution Time Constraints 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 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 lgoritmické přístupy k odhadům 37 Vlastnosti projektu TOOL - Use of Software Tools Stupeň použití softwarových nástrojů pro vývoj SITE - Multisite Vývoj na více místech Development SCED - Required Požadovaný termín Development Schedule dokončení Faktory modelu Early Design Kombinace RCPX - Product Reliability multiplikátorů RELY, and Complexity DATA, CPLX a DOCU RUSE - Developed for Stejný jako v PA modelu Reusability Kombinace PDIF - Platform Difficulty multiplikátorů TIME, STOR a PVOL PERS - Personnel Capability Kombinace multiplikátorů ACAP, PCAP a PCON Zdroj: Boehm, 2000 PREX - Personnel Experience FCIL - Facilities SCED - Required Development Schedule Kombinace multiplikátorů APEX, PLEX a LTEX Kombinace multiplikátorů TOOL a SITE z PA modelu Stejný jako v PA modelu 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 38 Algoritmické přístupy k odhadům Tab. 2 Hodnoty faktorů metody Cocomo II FAKTOR TYP VL L N H VH XH PREC SF FLEX SF RESL SF TEAM SF PMAT SF RELY EM DATA EM CPLX EM RUSE EM DOCU EM TIME EM STOR EM PVOL EM ACAP EM PCAP EM PCON EM 1: AEXP EM PEXP EM LTEX EM TOOL EM SITE EM SCED EM 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, 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 lgoritmické přístupy k odhadům 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ů 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 40 Algoritmické přístupy k odhadům 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.

41 lgoritmické přístupy k odhadům 41 Tab. 3 Multiplikátory objektů FPA Komplexnost Charakteristika Nízká Průměrná Vysoká EI EO EQ ILF EIF Zdroj: 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ň Vliv 0 Žádný 1 Náhodný 2 Nízký 3 Průměrný 4 Významný 5 Velmi silný Zdroj: 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 42 Algoritmické přístupy k odhadům 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 lgoritmické přístupy k odhadům 43 Tab. 5 FPA Přehled základních charakteristik ovlivňujících systém Základní systémové vlastnosti Krátký popis 1. Datová komunikace S kolik entitami je třeba komunikovat? 2. Distribuované zpracování dat 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 Jaké procento dat je zdáváno online? 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 Zdroj: 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 44 Algoritmické přístupy k odhadům Tab. 6 Rozdělení jazyků pro převod funkčních celků na řádky kódu Programovací jazyk Převod SLOC/FP Průměr Medián Minimum Maximum ABAP (SAP) 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 Zdroj: 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.

45 lgoritmické přístupy k odhadům Nizozemská metoda V případě, že se jedná o ranou fázi projektu, existuje tzv. informativní metoda počítání funkčních celků navržená Nizozemskou asociací softwarových metrik (NEM- SA). V této metodě jsou počítány pouze ILF a EIF. Informativní součet je poté 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 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ů Váha Lokální systém 1 Vzdálený systém 2 Uživatel 3 Zdroj: 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 46 Algoritmické přístupy k odhadům Tab. 8 Přehled faktorů technické složitosti a jejich vah Technický faktor Váha Distribuce systému 2 Výkon 1 Efektivita koncového uživatele 1 Složité vnitřní procesy 1 Znovupoužitelnost 1 Jednoduchost instalace 0,5 Jednoduchost použití 0,5 Přenositelnost 2 Jednoduchost změn 1 Souběžnost 1 Speciální ochranné prvky 1 Přímý přístup třetích stran 1 Požadavek speciálních školení 1 Zdroj: Tab. 9 Přehled faktorů prostředí a jejich vah Faktor prostředí Váha Obeznámenost s UML 1,5 Pracovníci na částečný úvazek -1 Schopnosti analytika 0,5 Zkušenosti s aplikací 0,5 Zkušenosti s objekty 1 Motivace 1 Složitost programovacího jazyka -1 Stálost požadavků 2 Zdroj: 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 Algoritmické přístupy k odhadům 47 Výsledné ohodnocení plánovaného systému metodou analýzy případů užití (UCP Use Case Points) je získáno z rovnice níže. ( ) Tato hodnota sama o sobě není moc přínosná. Ovšem při srovnání s historickými daty je možné získat jasnou představu o náročnosti projektu a získat hrubé finanční i časové náklady. 4.6 Odhadování pracnosti projektu Po použití metod na odhad velikosti projektu je možné tuto veličinu použít i pro odhad pracnosti na vývoj daného systému. Odhad pracnosti projektu se obecně odvozuje právě od vypočítané veličiny představující velikost tohoto projektu. 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 48 Algoritmické přístupy k odhadům 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 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 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 lgoritmické přístupy k odhadům 49 Tab. 10 Typická hustota chyb dle velikosti systému Velikost systému (v řádcích kódu) Typická hustota chyb (na 1000 řádek kódu) Méně než , a více 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í Odstraněných chyb Regresní testování 25 % Neformální revize kódu 25 % Testování po jednotkách 30 % Testování nových komponent 30 % Neformální revize kódu 35 % Nízkokapacitní beta testování 35 % Osobní revize kódu 40 % Systémové testování 40 % Formální inspekce kódu 55 % Formální inspekce kódu 60 % Modelování nebo prototypy 65 % Vysokokapacitní beta testování 75 % Zdroj: Jones, 2000 Efektivita odstraňování chyb lze poté odhadnout dle vybraného postupu odstranění. Dle Jonese (2000) je průměr celého softwarového průmyslu při odstraňování chyb přibližně 85 %. Dle Boehma a spol. (2000) snížení chybovosti systému z 5 % na 1% zvýší výdaje na projekt o 25 % a z 1 % na 0,01 % pozvedne náklady o dalších 25 %.

50 50 Algoritmické přístupy k odhadům 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 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 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 Algoritmické přístupy k odhadům 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 52 Nástroje pro návrh aplikace 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 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:

53 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 54 Nástroje pro návrh aplikace Obr. 4 Rozdělení UML diagramů (Arlow, 2007) Diagram případů užití 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í.

55 troje pro návrh aplikace 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) 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í 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 56 Nástroje pro návrh aplikace 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.

57 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 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 Eriksson- Penker, 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í.

59 vrh řešení Analýza požadavků 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 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í 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 Historická data bude možné načíst z databáze 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ů Aplikace bude umožňovat tvorbu projektu pomocí přidávání modulů 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 Aplikace bude provádět výpočet odhadu pomocí Cocomo II Aplikace bude provádět výpočet odhadu pomocí FPA Uživatel bude moci manuálně zvolit preferovanou metodiku výpočtu 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 Z výstupu odhadu bude možné automaticky vytvořit výstupní zprávu Výstupní zprávu bude možné uložit nebo vytisknout Výstup odhadu bude možné exportovat jako historická data do souboru ve formátu TXT, XLS, CSV, HTML Výstup souboru bude možné uložit do databáze jako historická data.

60 60 Návrh řešení Požadavky na výkon Požadavky v této části poskytují přehled požadavků na rychlost reakcí aplikace. 1. Doba odezvy Popis: Rychlost odezvy aplikace. Metrika: Měření získaná z testů. Nutnost: Méně než 2 sekundy ve 100 % případů. Přání: Méně než 1 sekunda ve 100 % případů. 2. Doba provádění výpočtů Popis: Rychlost provádění výpočtů. Metrika: Měření získaná z testů. Nutnost: Méně než 10 sekund ve 100 % případů. Přání: Méně než 5 sekund ve 100 % případů Omezení návrhu Tato část obsahuje omezení návrhu software způsobená hardwarem. 1. Velikost na disku Popis: Velikost lokálního prostoru použitého aplikací. Metrika: MB. Nutnost: Méně než 20 MB. Plán: Méně než 15 MB. Přání: Méně než 10 MB. MB definice: Megabyte. 2. Využití pamětí počítače Popis: Velikost paměti využívaného aplikací. Metrika: MB. Popis: Pozorování logů během výkonnostních testů. Nutnost: Méně než 50 MB. Plán: Méně než 20 MB. Přání: Méně než 10 MB. MB definice: Megabyte 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.

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

63 vrh řešení 63 Obr. 5 Základní schéma aplikace pomocí Eriksson-Penker notace 7.4 Diagram případů užití Pro zvýšení přehlednosti a zdůraznění funkcionality aplikace byl vytvořen i už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 64 Návrh řešení Obr. 6 Diagram případů užití

65 vrh řešení Rozbor hlavních metod Pro celistvost je v této kapitole proveden podrobnější rozbor hlavních metod s využitím diagramů aktivit 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 66 Návrh řešení Obr. 7 Diagram aktivit Tvorba projektu

67 vrh řešení 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ů Funkční celky Nutné FP nebo LOC 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 68 Návrh řešení Tab. 13 Fáze vývoje Rozdělení možných vstupů pro jednotlivé oblasti Zjišťovaná oblast Přesnost návrhu Zkušenosti týmu Rychlost Znalost vstupů Zdroj: Bielas, 2013 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í Uvedené faktory pak ohodnotíme číselnými hodnotami. Tab. 14 Seřazené ohodnocení faktorů metod F5 F3 F1 F2 F4 Funkční celky COCOMO Případy užití Nizozemská metoda 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

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

71 vrh řešení 71 Obr. 9 Diagram aktivit Načtení uloženého odhadu Použití historických dat 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 72 Návrh řešení 7.6 Diagram tříd Podrobnější náhled na logickou strukturu aplikace bude představovat diagram tříd, pomocí kterého se identifikují základní stavební prvky objektového návrhu aplikace. Obr. 10 Diagram tříd aplikace V diagramu tříd zobrazeném výše bylo celkem identifikováno 7 tříd reprezentujících zmíněnou logickou strukturu. Třída Metoda výpočtu je abstraktní třídou a 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-

73 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 Atribut Název projektu Použité moduly Přehled struktury úložiště historických dat 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 Atribut Identifikátor Název projektu Způsob tvorby Metoda výpočtu Vstupní data Přehled struktury uložených odhadů 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 74 Implementace navrženého řešení 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ů.

75 Implementace navrženého řešení 75 Obr. 12 Návrh vzhledu obrazovky s přehledem výstupu Obrazovky s tvorbou projektu jsou zaměřeny zejména na sběr dat a jejich grafický návrh proto nebude prioritou. Hlavním cílem bude jejich přehlednost a komfort uživatele. Na jednom místě by tedy nemělo být mnoho vstupních bodů.

76 76 Implementace navrženého řešení 8.2 Popis použitých nástrojů Obr. 13 Zobrazení přechodů mezi jednotlivými nástroji 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í.

77 Implementace navrženého řešení 77 Tab. 18 Srovnání výhod tvorby rozhraní v Qt Qt Quick Qt Widgets Qt WebKit Použité jazyky QML/JS C++ HTML/CSS/JS Nativní vzhled X X Vlastní vzhled X X (X) Plovoucí animované GUI X Dotykové obrazovky X Standardní ovládací prvky X Programování model/view (X) X Zrychlený UI vývoj X (X) Grafická HW akcelerace X Grafické efekty X Široké možnosti práce s textem X X Existující webový obsah X Zdroj: Qt Project, 2015 Qt Widgety jsou určeny pro tvorbu uživatelského rozhraní v rámci desktopových aplikací a jsou proto nejvhodnější k využití na desktopových aplikacích. Jeho vý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 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 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 78 Implementace navrženého řešení 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 pro data LOC velikosti projektu a v rozsahu pro velikost reprezentovanou jednotlivými funkčními celky.

79 Implementace navrženého řešení 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 80 Implementace navrženého řešení Obr. 16 Implementace Tvorba projektu, krok 1 Na obrázku výše je možné vidět, že v kroku č. 1 průvodce tvorbou odhadu je 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.

81 Implementace navrženého řešení 81 Obr. 17 Implementace Tvorba projektu, krok 2 V dalších krocích již probíhá pouze potvrzení ukončení průvodce a aplikace se př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 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.