Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií
Softwarová podpora práce operátorů Call Centra Diplomová práce
Autor:
Bc. Matěj Šedivý Informační technologie a management
Vedoucí práce:
Praha
Ing. Vladimír Beneš
Duben 2013
Poděkování:
Rád bych touto cestou poděkoval panu Ing. Vladimíru Benešovi za projevenou podporu při zpracování mé diplomové práce.
Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.
V Praze dne 15. 4. 2013
Matěj Šedivý
Anotace Předmětem diplomové práce “Softwarová podpora práce operátorů Call Centra” je popsání postupu analýzy návrhu a vývoje aplikace od zadání problému business uţivatelem do realizace konkrétního řešení. V první části jsou popsána metodická východiska a zasazení budoucí aplikace do technické infrastruktury. Ve druhé části je provedena analýza, návrh a implementace konkrétního řešení. V závěru je porovnán výsledek provedené implementace s původním zadáním, včetně zhodnocení postupu práce a cílového stavu.
Klíčová slova:
call centrum, UML, projektové řízení, Karnerova metoda odhadu nákladů, návrhové vzory
Annotation The thesis: "Software support operators work Call Center" is a description of the analysis procedure, design and development of applications from business user input problem in the implementation of specific solutions. The first section describes the methodological background and place the future applications into the technical infrastructure. In the second part of the analysis, design and implementation of a particular solution. In the end the result is compared with the original implementation carried out the assignment, including an assessment of the work and the target state.
Keywords:
call center, UML, project management, Karner‘s effort estimation method, design patterns
Obsah
ÚVOD......................................................................................................................................... 8 1
2
3
METODICKÁ VÝCHODISKA ......................................................................................... 9 1.1
Zvolené metody zpracování ......................................................................................... 9
1.2
Teoretický aparát pro řešení......................................................................................... 9
1.2.1
Odhadování nákladů ........................................................................................... 10
1.2.2
Uml ..................................................................................................................... 12
BUSINESS POŢADAVKY ............................................................................................. 15 2.1
Vstup do problematiky............................................................................................... 15
2.2
Popis výchozího stavu................................................................................................ 15
POUŢITÉ TECHNOLOGIE ............................................................................................ 16 3.1
Zadání problému ........................................................................................................ 16
3.2
Pouţité technologie .................................................................................................... 16
3.2.1
Technické řešení Call Centra.............................................................................. 16
3.2.2
Pouţitá databáze ................................................................................................. 18
3.2.3
Doporučená technologie pro vývoj aplikace ...................................................... 18
3.3 4
Výběr technického řešení........................................................................................... 19
ANALÝZA A NÁVRH ŘEŠENÍ ..................................................................................... 20 4.1
Odhad nákladů, časového plánu, rizika a bezpečnost řešení ..................................... 20
4.1.1
Odhad nákladů na realizační fázi za pomoci Karnerovy metody ....................... 20
4.1.2
Rekapitulace odhadu nákladů na realizaci systému ........................................... 23
4.1.3
Časový plán projektu .......................................................................................... 24
4.1.4
Rizika projektu ................................................................................................... 25
4.1.5
Bezpečnost .......................................................................................................... 26
4.2
Analýza ...................................................................................................................... 27
4.2.1
Sběr uţivatelských poţadavků ........................................................................... 27 5
4.2.2
Katalog poţadavků ............................................................................................. 28
4.2.3
Diagram případů uţití ......................................................................................... 29
4.2.4
Definice aktorů ................................................................................................... 33
4.2.5
Analýza uţivatelského rozhraní aplikace ........................................................... 34
4.2.6
Doménový model aplikace ................................................................................. 35
4.2.7
Závěr analýzy ..................................................................................................... 36
4.3
5
4.3.1
Návrhový model tříd........................................................................................... 37
4.3.2
Datový model ..................................................................................................... 43
4.3.3
Návrhový model obrazovek aplikace GUI ......................................................... 44
4.3.4
Sekvenční diagram ............................................................................................. 46
4.3.5
Model komponent ............................................................................................... 47
4.3.6
Model nasazení ................................................................................................... 48
4.3.7
Aktivity diagram ................................................................................................. 48
4.3.8
Závěr návrhu aplikace ........................................................................................ 49
IMPLEMENTACE, TESTOVÁNÍ A NASAZENÍ ......................................................... 51 5.1
Implementace ............................................................................................................. 51
5.2
Testování .................................................................................................................... 53
5.2.1
Unit testy ............................................................................................................ 53
5.2.2
Testy komponent ................................................................................................ 54
5.2.3
UAT testy ........................................................................................................... 54
5.2.4
Tvorba testovacích prostředí .............................................................................. 57
5.2.5
Testovaní v praxi plus typické problémy ........................................................... 57
5.3 6
Nasazení do provozu .................................................................................................. 59
VYHODNOCENÍ PROJEKTU ........................................................................................ 61 6.1
7
Návrh aplikace ........................................................................................................... 37
Vyhodnocení projektu................................................................................................ 62
SLOVNÍK POUŢITÝCH POJMŮ ................................................................................... 64 6
SEZNAM POUŢITÉ LITERATURY ...................................................................................... 65 SEZNAM OBRÁZKŮ ............................................................................................................. 66 SEZNAM TABULEK .............................................................................................................. 66
7
ÚVOD Cílem mé diplomové práce je popsání postupu analýzy, návrhu a implementace aplikace pro softwarovou podporu práce operátorů Call Centra společnosti CETELEM ČR, a.s. (dále jen finanční společnost). Finanční společnost je silná a stabilní nebankovní instituce, která na českém finančním trhu působí jiţ šestnáctým rokem, tedy od roku 1997. Za tuto dobu se stala hráčem číslo jedna v poskytování uvěrových produktů a sluţeb na poli nebankovních finančních společností. V jejím portfoliu sluţeb, které nabízí na českém finančním trhu jsou: klasické spotřebitelské úvěry v prodejnách obchodních partnerů, účelové a neúčelové osobní půjčky, kreditní karty, produkty určené k financování motorových vozidel, různé typy pojištění. Finanční společnost je ze 100 % ve vlastnictví francouzské banky BNP Paribas, která poskytuje spotřebitelské úvěry jiţ od roku 1953 a působí ve více jak třech desítkách zemí celého světa na čtyřech kontinentech. Prostřednictvím členství a aktivitou v profesních a zájmových sdruţení a asociací se finanční společnost aktivně podílí na formování prostředí pro poskytování finančních sluţeb nebankovními subjekty. Je členem: Sdruţení právnických osob SOLUS, Česká leasingová a finanční asociace (ČLFA), Sdruţení pro bankovní karty (SBK), MasterCard International, Asociace pro elektronickou komerci (APEK). [8]
8
1 METODICKÁ VÝCHODISKA 1.1 Zvolené metody zpracování Při zpracování mé diplomové práce jsem zvolil postup, který systematicky popisuje jednotlivé kroky od rámcového zadání problému aţ do fáze nasazení hotové aplikace. V rámci těchto kroků jsou pouţity všeobecně známé a ověřené metody či techniky, které tyto dílčí kroky zpřehledňují a významně zkracují dobu nutnou pro vytvoření aplikace. Nejprve provedeme sběr poţadavků na funkčnosti nové aplikace u budoucích uţivatelů. V této fázi je důleţité shromáţdit poţadavky na různých úrovních detailu, tak abychom v co největší šíři postihli co největší úroveň detailu. Nedílnou součástí je rovněţ popis metod a postupů, které budou při návrhu a tvorbě aplikace vyuţity. V této fázi nijak nespecifikujeme technické řešení, ale pouze poţadované funkčnosti. S vyuţitím těchto poznatků v další fázi sestavíme katalog uţivatelských poţadavků jako základ pro analýzu aplikace. Po tomto kroku musí dojít k hrubému odhadu pracnosti vytvářené aplikace a k rámcovému zasazení do technické infrastruktury zadavatele tak, abychom byli schopni rozhodnout, zdali další analýza a vývoj aplikace bude přínosem. V další fázi bude provedena analýza s vyuţitím prostředků metodiky UML. Součástí analýzy je mimo jiné upřesnění odhadů pracnosti na vývoji aplikace. Po provedené analýze bude následovat popis technického řešení (návrh), kde bude vznikající aplikace zasazena do technologického prostředí (pouţitý programovací jazyk, infrastruktura, bezpečnost). Následuje iterativní vývoj aplikace a nezbytných unit testů a testovacích scénářů. V další části popisuji způsob testování aplikace formou UAT testů a její nasazování do testovacího a preprodukčního prostředí. Následuje popis deploymentu aplikace do produkčního prostředí ve vazbě na infrastrukturní tým zákazníka. V poslední části je provedeno vyhodnocení projektu z hlediska kvality času a nákladů.
1.2 Teoretický aparát pro řešení V této kapitole popisuji teoretické metody pouţité v jednotlivých fázích analýzy a návrhu aplikace.
9
1.2.1 Odhadování nákladů Pro odhad nákladů budoucího vývoje aplikace je moţno vyuţít některou ze standardních metod odhadu nákladů. Odhadování je většinou prováděno pomocí expertních znalostí bez vyuţití exaktních nástrojů. Metoda expertního odhadu je efektivní, ale významně závislá na osobě, která odhad provádí. Know-how způsobu odhadu odchází ze společnosti současně s osobou analytika provádějící odhad. Z tohoto důvodu je vhodné poţít některou z metod nezávislých na konkrétní osobě. Tyto metody byly vytvořeny přesně z důvodů uvedených v tomto odstavci. Exaktní postup sniţuje riziko závislosti na konkrétní osobě. Pro odhad nákladů jsou vyuţívány následující metody: 1) Metody zaloţené na expertních odhadech. V našem případě je tato metoda vyuţita pro odhad částí projektu, pro které nelze vyuţít jiné metody. 2) Metody zaloţené na modelu. Z těchto metod zmíníme Cocomo1, Karnerovu metodu a Funciton point analysis (FPA).2 Ve finanční společnosti je pro většinu softwarových projektů vyuţívána Karnerova metoda odhadu nákladů. Z tohoto důvodu je vhodné ji pouţít i v tomto případě. Opakované vyuţití exaktní metody zpřesňuje v kaţdé iteraci dosaţené výsledky. [7] Metodu vyvinul v roce 1993 pan Gustav Karner. Je zaloţena na analýze fiction points, která vznikla v 70. letech ve výzkumných laboratořích IBM. Výhodou této metody je fakt, ţe můţe být pouţita jiţ v rané fázi návrhu systému, kdy ještě není k dispozici podrobná analýza funkcionalit navrhovaného systému. V této fázi máme pouze hrubý přehled funkcionalit systému, které budou poţadovány budoucími uţivateli. Modely jednání - use case - mohou být v tomto případě jednoduše pouţity pro odhad sloţitosti vývoje softwaru a jeho testování.
1
Cocomo (Constructive Cost Model) metodu vytvořenou B.Boehmem. coţ je americký softwarový inţenýr, který metodu COCOMO publikoval v roce 1981
2
Metoda odhadu nákladů vyuţívající funkční body 10
Výpočet use case points se skládá ze tří částí:
1. Neupravený UCP o Počet aktorů: aktoři se rozdělí do třech kategorií, kterým se přidělí váhy: a. Jednoduchý: jiný systém připojený na odhadovaný systém přes interface, váha=1. b. Průměrný: další systém, který na odhadovaný systém komunikuje přes protokol, váha=2. c. Sloţitý: představuje osoby, které komunikují se systémem přímo přes grafické rozhraní, váha=3. Získaná hodnota představuje celkovou nevyrovnanou váhu aktorů (Total Unadjusted Actor Weight – uaw) o Počet use case: jednotlivé případy uţití se zařadí do kategorií podle počtu transakcí v jednotlivém případu (sloţitost USE CASE): -
jednoduchý (méně neţ 4 transakce),
-
střední (4 aţ 7 transakcí),
-
sloţitý (více neţ 7 transakcí).
a těmto kategoriím se přidělí váhy: 5 (jednoduchý), 10 (střední) nebo 15 (sloţitý). Získaná hodnota představuje celkovou nevyrovnanou váhu počtu případů uţití (Total Unadjusted Use Case Weight – uucw) Neupravený UCP (Unadjusted use case points) je součtem obou předchozích, tedy: uucp = uaw + uucw 2. Technický faktor Provede se ohodnocení systému z technického pohledu, kde se 13 technických faktorů ohodnotí známkou od 0 do 5. Nejniţší hodnota představuje bezvýznamný vliv na systém, naopak čím je hodnota vyšší, tím faktor významně ovlivňuje navrhovaný systém. Výsledkem je sumární tFactor, celkový technický faktor pak: tcf = 0,6 + (0,01 * tFactor )
11
3. Faktor prostředí Provede se ohodnocení 8 faktorů, které souvisejí se znalostmi a dovednostmi zaměstnanců. Známky jsou stejné jako u technického faktoru, výsledkem je sumární eFactor, celkový faktor prostředí pak: ef = 1,4 + (-0,03 * eFactor )
Celkový počet UCP získáme roznásobením nevyrovnané části UCP technickým faktorem a faktorem prostředí: aucp = uucp * tcf * ef Tuto hodnotu (v této chvíli se jedná o bezrozměrné číslo) je potřeba převést na skutečnou pracnost, která je reprezentována jednotkou člověkohodina. Dle Karnera je doporučeno 20 hodin na jeden aucp, dle jiných autorů kolísá hodnota v rozmezí 15-30 hodin.
1.2.2 Uml Z mé bakalářské práce uvádím popis jazyka UML [4]. Jazyk UML (Unified Modeling Language) je výrazový prostředek usnadňující a zpřehledňující práci analytika a návrháře informačního systému. Je to jazyk založený na grafické reprezentaci objektů tak, aby dosáhl jednoduchosti vyjadřování a zároveň vysoké flexibility modelů. Jazyk UML vznikl na základě sloučení metodik Booch3 a OMT4 v polovině devadesátých let. Verze 1.0, která vznikla tímto sloučením a dosáhla rozšíření díky tomu, že začala být doporučována konsorciem OMG5 jako standard pro modelování. V roce 2011 je UML k dispozici ve verzi 2.0, kde jsou k dispozici nové typy diagramů, zejména diagram přehledu interakcí, načasování a smíšené struktury.
3
Booch metodika zaměřená zejména na design a implementaci
4
OMT: Object Modeling Technique
5
OMG: Object Management Group 12
Obr. 1: Hierarchická struktura jazyka UML Zdroj: http://upload.wikimedia.org/wikipedia/commons/d/d6/Uml_diagram2.png
Diagram balíčků (Package Diagram) Slouží k dekompozici systému a seskupení souvisejících prvků v modelu. Jejich prostřednictvím je možné znázornit závislosti mezi dílčími částmi systému. Diagram aktivit (Activity Diagram) Modelují chování systému a znázorňují tok činností, tj. sled jejich provádění včetně větvení na základě splněných podmínek. Diagram případů užití (Use Case Diagram) Slouží ke znázornění chování systému z pohledu uživatele (aktora), lze znázornit interakci systému a uživatelů při vykonávání určité ohraničené jednotky činností. Diagram tříd (Class Diagram)
Slouží ke znázornění statické struktury modelovaného
systému, znázorňuje typy objektů a vztahy mezi nimi. Jedná se patrně o nejznámější diagram. Stavový diagram (State Machine Diagram) Slouží ke znázornění stavů a přechodů mezi nimi. Typicky se jedná o stavy jedné třídy nebo životní cyklus entity. Diagram komunikace (Communication Diagram)
Dokumentují spolupráci objektů při
řešení úlohy a zobrazují toky událostí mezi třídami včetně jejich pořadí (dříve se nazývaly diagramy kolaborace). 13
Diagram komponent (Component Diagram) Zobrazuje a popisuje jednotlivé komponenty, ze kterých se celý systém skládá. Diagram vnitřní struktury (Composite Structure Diagram) Jsou určeny pro vyjádření kolaborace instancí a instancí komunikačních struktur. Diagram nasazení (Deployment Diagram) Popisují fyzické rozmístění jednotlivých komponent v rámci výpočetního systému. Diagram přehledu interakcí (Interaction Overview Diagram) Zachycuje tok řízení v rámci systému nebo procesu. Každý uzel nebo aktivita v rámci diagramu může reprezentovat další diagram interakce. Objektový diagram (Object Diagram) Znázorňuje objekty a jejich vztahy na úrovni jejich konkrétních instancí. Sekvenční diagram (Sequence Diagram) Znázorňuje, jak se jednotlivé akce instancí tříd mění v čase, včetně vzájemné komunikace mezi nimi. V mé diplomové práci je vyuţito několika dalších variant diagramu tříd. Jedná se o tzv. analytický model tříd, někdy téţ nazývaný doménový model. A dále o diagram databázových objektů, coţ je speciální případ diagramu tříd s vyuţitím notace E-R (entity-relationship).
14
2 BUSINESS POŢADAVKY 2.1 Vstup do problematiky Finanční společnost vyuţívá interní call centrum pro efektivní komunikaci se svými klienty a to včetně klientů potenciálních. Tato komunikace je zaloţena na aktuálních informacích o právě kontaktovaném klientovi. Například pokud klient volá do call centra s poţadavkem na sdělení zůstatku na účtu, operátor call centra musí mít všechny dostupné informace o klientovi k dispozici v co nejkratší době po započetí telefonního hovoru s klientem. V současné době musí operátor volajícího klienta dohledávat podle jím sdělených údajů v několika systémech. Tento postup je časově náročný a můţe docházet k přehlédnutí některých důleţitých informací. Například klient je aktuálně v prodlení se splácením úvěru. Aby bylo moţno zvýšit efektivitu práce call centra, je nutno vytvořit jednu aplikaci, která v sobě obsahuje všechny informace potřebné pro práci operátora call centra. Tato aplikace musí zohledňovat různé reţimy práce operátorů. Operátoři jsou rozděleni do skupin, které aktivně oslovují klienty, jiní operátoři obsluhují příchozí telefonické hovory s poţadavky klientů a další operátoři kontaktují klienty, kteří mají nějaké problémy například se splácením úvěru. Podle těchto rozdělení se liší struktura informací, kterou má daný operátor k dispozici. Vedení společnosti ve spolupráci s metodiky práce call centra analyzovali stávající stav jako neuspokojivý, neboť společnost si zakládá na dobré komunikaci se svými zákazníky. Za tímto účelem a na základě výše uvedených poţadavků, bylo vedením finanční společnosti rozhodnuto provést analýzu, návrh řešení a posléze jeho realizaci.
2.2 Popis výchozího stavu Jak jiţ bylo zmíněno v kapitole 2.1, aktuální stav softwarového řešení pro call centrum je nevyhovující, neboť operátor call centra nemá k dispozici jednotnou aplikaci. V současné době je operátor call centra nucen v průběhu hovoru pracovat se třemi aţ čtyřmi zcela nesourodými aplikacemi (interní systémy finanční společnosti) a dále ještě s aplikací MS Excel, kde provádí evidenci uskutečněných hovorů a přeplánování hovorů, které nebyly uskutečněny. Toto klade zvýšené nároky na kvalitu operátora. Je nutno jej proškolit pro práci se všemi aplikacemi, tak aby byl schopen rychle reagovat v průběhu telefonického hovoru. Operátor je nucen se naučit i postupy, které nejsou nezbytně nutné pro výkon jeho práce, ale jsou vyţadovány konkrétními aplikacemi. 15
3 POUŢITÉ TECHNOLOGIE 3.1 Zadání problému Výběr technického řešení je pro tvorbu takovéto aplikace zcela zásadní. Je nutné si uvědomit, ţe ve fázi případné realizace jiţ nelze způsob řešení změnit, protoţe tím by se zcela změnily podmínky, za kterých bylo učiněno rozhodnutí realizovat tvorbu této aplikace.
3.2 Pouţité technologie Aplikace není stavěna „Na zelené louce“, ale je závislá na existujících a podporovaných technologiích v rámci finanční společnosti. Důvodem je vyuţití existujících týmů technické podpory tak, aby byly minimalizovány náklady na školení specialistů technické podpory na nové technologie. V současné době je klíčovou částí, na které je budoucí aplikace závislá, telefonní infrastruktura. Dalším prvkem infrastruktury je databázové řešení v rámci finanční společnosti.
3.2.1 Technické řešení Call Centra V této kapitole bych se rád zmínil o technickém řešení, na kterém celá aplikace bude provozována. Toto je velice důleţité z pohledu celého návrhu a výběru technologie. Jádro interní komunikační infrastruktury bude představovat Cisco Unified Communications Manager (dále jen CUCM) hostovaný na třech virtuálních platformách poskytované HW platformou Unified Computing Systems (dále jen UCS). UCS se vyznačuje vysokou dostupností, která je zaručena zdvojením všech klíčových HW komponent. Z důvodu zajištění geografické redundance bude HW platforma UCS nasazena ve dvou datových centrech v lokalitách Praha Anděl (primární) a Praha Nagáno (záloţní). Stejně tak bude i systém CUCM tvořit geografický aplikační cluster, který zajistí po dobu výpadku jednoho datového centra veškeré sluţby spojené s komunikační infrastrukturou společnosti a tím pádem zachování dostupnosti aplikací pro podporu práce operátorů Call Centra. Další důleţitou komponentou je systém kontaktního centra zaloţený na produktech Cisco Unified Contact Center Enterprise (dále jen UCCE) a Cisco Unified Intelligent Center (dále jen CUIC). Komponenta UCCE je stejně jako CUCM hostována na platformě UCS. Systém kontaktního centra tvoří v kombinaci s UCS platformou v obou datových centrech jeden 16
celek, který je geograficky nezávislý, a v případě výpadku jednoho datového centra či jen jeho části, přebírá veškerou funkcionalitu záloţní datové centrum a to bez dopadu na dostupnost sluţby, kterou systém kontaktního centra poskytuje zákazníkům společnosti. Součástí systému kontaktního centra je téţ reportovací nástroj, který poskytuje aplikace CUIC. Tato aplikace je taktéţ hostována na virtuální platformě poskytované systémem UCS. Poslední, ne však méně důleţitou komponentou celého řešení, je Outbound Option – Dialer. Tato komponenta zajišťuje automatizaci a logiku pro odchozí volání prostřednictvím systému kontaktního centra. Jako jediná je tato komponenta instalována na oddělených HW prostředcích od UCS. Důvodem je nepodporované nasazení komponenty Dialer na virtuální platformu. Architektura Cisco Unified Computing System umoţňuje profilovou portabilitu fyzických i virtuálních strojů, kde můţe být identita serveru, LAN/SAN, nastavení I/O, firmware a profily síťové konektivity dynamicky poskytovány kterékoli části hardwaru v rámci systému. Toto vysoce dynamické a jednoduché prostředí můţe být adaptováno tak, aby vyhovovalo rychle se měnícím potřebám v dnešních datových centrech. To zahrnuje včasný rozvoj nových počítačových zdrojů a bezpečný pohyb tradičních a virtuálních pracovních zátěţí. Cisco Unified Computing System zlepšuje dostupnost, bezpečnost a výkon prostřednictvím integrovaného designu. Tato technologie je přímo optimalizovaná pro provoz virtualizovaných řešení. Poskytuje ve všech oblastech maximální flexibilitu, dostupnost a v neposlední řadě technické vlastnosti, které umoţňují velmi jednoduché rozšiřování řešení. Nad touto hardware vrstvou je provozována virtualizační vrstva, která má za úkol oddělit aplikace od vlastního hardware. Tím se dosáhne stavu, kdy je moţné provozovat dotyčné aplikace nezávisle na vlastních fyzických serverech a mimo jiné také umoţní provozování více virtuálních strojů na jediném fyzickém stroji a tak lépe vyuţít výpočetní zdroje a investice do nich vloţené. VMware ESXi server poskytuje standardizované virtualizované prostředí pro běh operačních systémů a aplikací. Takto realizované prostředí bude spravováno a monitorováno VMware vCenter serverem.
17
Diskové kapacity potřebné pro provoz kontaktního centra jsou alokovány v rámci stávajících diskových polí. Takto navrhované nasazení poskytuje maximální míru zastupitelnosti jednotlivých komponent kontaktního centra a interního komunikačního systému. Schéma zapojení topologie je ukázáno na Obr. 2.
Obr. 2:Topologie zapojení Zdroj: Autor
3.2.2 Pouţitá databáze Ve finanční společnosti je jako primární databázový systém vyuţita technologie ORACLE ve verzi 11.2.x. Z tohoto důvodu i navrhovaná aplikace musí vyuţívat tuto technologii. Důvodem je maximální rychlost přístupu k jiţ existujícím datům a v neposlední řadě i k ochraně investic do jiţ zakoupených databázových licencí.
3.2.3 Doporučená technologie pro vývoj aplikace Jelikoţ finanční společnost investovala nemalé finanční prostředky do najmutí a proškolení specialistů technické podpory pro platformu .NET bylo rozhodnuto všechny nově vznikající aplikace vytvářet na této platformě. Kromě výše uvedeného důvodu je platforma .NET výhodná i z pohledu poţadavku rychlé odezvy aplikace pracující v reálném čase s telefonním hovorem. 18
3.3 Výběr technického řešení Výběr technického řešení je v daném případě limitován technologiemi popsanými v kapitole 3.2. Výběr konkrétního technického řešení je určen technologiemi pouţitými v informačním systému finanční instituce. Implementace navrţené aplikace je závislá na implementaci telefonního subsystému CISCO Unified Manager a Aplikace Cisco Unified Call Centre Enterprise. Provozování operátorské aplikace v prostředí jiného telekomunikačního subsystému by bylo moţné pouze za předpokladu adaptace aplikace pro prostředí jiného subsystému. Obdobně pouţitá HW technologie její sizing vychází z prostředí a velikosti finanční instituce. Cisco Unified Manager i Cisco UCCE je moţné provozovat v různých reţimech a na různých HW platformách tak, aby jejich implementace maximálně vyhovovala prostředí společnosti, ve které je uvedená technologie provozována. Vţdy je ale nutné striktně dodrţet doporučení výrobce a splnit podmínky definované výrobcem v maticích kompatibility pro daný systém. I výběr systému databáze, je moţné zobecnit a pouţít jakýkoliv standardní databázový systém. Řešení Cisco UCCE je standardně postavené nad databázovým prostředím Microsoft SQL Server, které by mohlo být pouţité bez výhrad i pro ukládání dat námi navrhované aplikace. Výběr systému ORACLE vychází pro danou implementaci ze standardů finanční společnosti. Kaţdá nová technologie pouţitá při návrhu aplikace je potenciální rizikem při integraci aplikace do stávajícího funkčního informačního systému společnosti.
19
4 ANALÝZA A NÁVRH ŘEŠENÍ 4.1 Odhad nákladů, časového plánu, rizika a bezpečnost řešení 4.1.1 Odhad nákladů na realizační fázi za pomoci Karnerovy metody V této kapitole se budu zabývat jiţ konkrétním výpočtem hodnot, které uvádím níţe. Teorie Karnerovy metody včetně významu hodnot byla popsána v kapitole 1.2.1. Výpočet byl proveden za pouţití excelového kalkulátoru společnosti Komix6.
Neupravený UCP (Use Case Points) Rozdělení vah aktorům Váha
Typ Aktora
Počet Aktorů
Celkem
Jednoduchý (strojová komunikace přes API)
1
5
5
Průměrný (člověk)
2
0
0
Komplexní (člověk s GUI)
3
5
15
Celkem jaw
20 Tabulka č. 1: Karnerova metoda odhadu nákladů – rozdělení vah aktorům Zdroj: Komix a autor
Rozdělení vah případům uţití
Typ Use Case Počet transakcí na jeden UC Váha Jednoduchý
Počet Use Case
Celkem
<4
5
4
20
Průměrný
4 to 7
10
10
100
Komplexní
>8
15
7
105
Celkem uuaw
225 Tabulka č. 2: Karnerova metoda odhadu nákladů – rozdělení vah případům uţití Zdroj: Komix a autor
6
Komix, www.komix.cz 20
Výpočet nevyrovnané části UCP je proveden jako součet dvou výše uvedených vah, tj. uucp=jaw + uuvw , celkem tedy uucp= 245
Technický faktor Hodnota faktoru (0 - 5)
Váha
Technické Faktory Distribuovaný systém
2
3
6
0
Žádný vliv
Požadavky na odezvu
1
3
3
3
Průměrný vliv
End-user účinnost
1
2
2
5
Silný vliv
Komplexnost zpracování
1
2
2
Znovupoužitelný kód
1
2
2
Jednoduchost instalace
0,5
1
0,5
Jednoduchost použití
0,5
3
1,5
Přenositelnost
2
2
4
Snadnost změny
1
2
2
Souběžné zpracování
1
2
2
Bezpečnostní prvky
1
3
3
Přístup třetím stranám
1
2
2
Nutnost specielního zaškolení
1
3
3 33
Faktor technické složitosti (TCF)
0,93
Tabulka č. 3: Karnerova metoda odhadu nákladů – technický faktor Zdroj: Komix a autor
Faktory prostředí Faktory prostředí
Váha
Faktor (0 - 5)
Znalost metodiky RUP
1,5
4
6
0
Žádný vliv
Znalost aplikace
0,5
3
1,5
3
Průměrný vliv
1
1
1
5
Silný vliv
0,5
4
2
Motivace
1
3
3
Stabilní požadavky
2
4
8
Vývojáři na částečný úvazek
-1
0
0
Složitost programovacího jazyka
-1
0
0
Znalost OOP Schopnost vedení analýzy
21,5 21
Faktor prostředí (EF)
0,76
Tabulka č. 4: Karnerova metoda odhadu nákladů – faktor prostředí Zdroj: Komix a autor
Celkový počet UCP (Use Case points) Pro získání vyrovnaného počtu UCP roznásobíme získané hodnoty z předchozích kroků, tj. UCP=UUCP*TCF*EF ->UCP: 245*0,93*0,76=173,17 Hodnota UCP představuje pracnost, v této chvíli jde však o bezrozměrné číslo. Obecně je doporučována hodnota 20 člověkohodin7 na jeden UCP, v našem případě pouţijeme hodnotu 10, která je sice mimo doporučovaný rozsah hodnot, ale v našem případě byla tato hodnota zjištěna jako zpětná vazba na základě jiţ realizovaných projektů. Při pouţití vyšších hodnot docházelo ke zkreslení odhadů směrem nahoru. Výpočet bude vypadat následovně: 173,17 x 10 = 1731,70 hodin.
7
Téţ závisí na zkušenosti z jiných projektů, ale hodnota by se měla pohybovat v rozmezí 15-30 hodin na jeden UCP 22
4.1.2 Rekapitulace odhadu nákladů na realizaci systému Na základě této metody jsme relativně rychle schopni odhadnout náklady na vytvoření této nové aplikace.
Náklady Počet pracovníků
4 Člověkodny
54,12 Člověkoměsíce
2,71
Počet prac.hodin/den
8 Člověkoden
7 000 Kč Člověkohodina
875 Kč
Počet prac dnů/měsíc
Celkem
20
Měsíčně
140 000 Kč
1 515 238 Kč Tabulka č. 5: Rekapitulace odhadu nákladů na realizaci systému Zdroj: Autor
V tabulce 5 vidíme, ţe cena implementace aplikace bude finanční společnost stát kolem 1,5 miliónu korun českých. Na vývoj aplikace je moţno alokovat tým čtyř vývojářů. Větší počet členů týmu by byl neefektivní pro daný typ aplikace. Tento počet nezahrnuje analytika a testery aplikace. Nicméně tato tabulka neukazuje reálné trvání realizační fáze. Důvodem je nemoţnost paralelizovat všechny činnosti na sto procent. Ze zkušeností při realizaci předchozích projektů se ukazuje, ţe paralelizovat vývoj lze v průměru u dvaceti procent vyvíjeného kódu. Při pokusu nasadit větší mnoţství vývojářů za účelem zkrácení času vývoje roste prudce náročnost řízení projektu a zároveň roste i chybovost výsledného kódu. Pokud je aplikace takového rozsahu, ţe není z časových důvodů moţné vyuţívat malý tým vývojářů, je třeba počítat s více, ale samostatně řízenými týmy, které mají jasně specifikované zadání. Rozpad projektu v čase je ukázán v kapitole 4.1.3. Kromě nákladů na implementaci je nutno počítat také s časovou a finanční náročností analytické fáze. Tento čas nelze odhadovat Karnerovou metodou, protoţe provedená analýza tvoří předpoklad pro pouţití Karnerovy metody. Čas analýzy je odhadován expertním způsobem na základě předchozích projektů. V tomto případě byl čas odhadnut na 18 člověkodnů. Stejně je nutno postupovat i při odhadu fáze nasazení do provozu. Zde byl expertní metodou čas odhadnut na cca jednu třetinu času implementační fáze, tedy 17 dní. Teprve po zpracování časového plánu projektu jsme schopni dodat celkovou cenu za všechny fáze projektu. 23
4.1.3 Časový plán projektu Na základě vypočtených nákladů na realizaci projektu je zpracován časový plán projektu. Tento plán vychází ze zdrojů dostupných pro realizaci (lidské zdroje, čas, rozpočet). Plán je sestaven formou Ganttova diagramu v nástroji MS Project 2010. Na počátku projektu jsou do plánu zahrnuty pouze důleţité milníky. Jsou to: iniciace projektu, schválení projektu, schválení řešení, akceptace integračních testů, předání do provozu a vyhodnocení a uzavření projektu. Jednotlivé milníky jsou dále v průběhu projektu zpřesňovány a popisovány do většího detailu, neboť na začátku projektu by přílišný detail zanášel do plánu vysoké procento odhadové chyby. Níţe zobrazená tabulka ukazuje plán projektu v jeho rané fázi, ještě před doplněním detailních kroků. Řádek „Fáze3-realizace řešení“ v následující tabulce obsahuje časové údaje získané jako výstup z Karnerovy metody odhadu nákladů na realizaci, kapitola 4.1.2. Číslo osnovy
1
Název úkolu
Doba trvání
Zahájení
Dokončení
Fáze1-Iniciace projektu
5 dny
2.4. 12
6.4. 12
1.1
vypracování a odsouhlasení záměru
3 dny
2.4. 12
4.4. 12
1.2
klíčové role na projektu
1 den
5.4. 12
5.4. 12
1.3
definice formálních pravidel na projektu
1 den
6.4. 12
6.4. 12
2
schválení projektu
0 dny
6.4. 12
6.4. 12
3
Fáze2-plánování analýza a návrh řešení 18 dny
6.4. 12
24.4. 12
3.1
analýza a návrh řešení
15 dny
6.4. 12
21.4. 12
3.2
rozpočet a detailní harmonogram
3 dny
22.4. 12
24.4. 12
4
schválení řešení
0 dny
24.4.12
24.4.12
5
Fáze3-realizace řešení
54 dny
25.4.12
18.6. 12
5.1
Tvorba systému dle návrhu řešení
40 dny
25.4.12
4.6. 12
5.2
Testování
14 dny
5.6. 12
18.6. 12
6
akceptace integračních testů
0 dny
18.6. 12
18.6. 12
7
Fáze4-zavádění do provozu
17 dny
19.6. 12
6.7.12
7.1
Provozní (výkonnostní) testy
2 dny
19.6. 12
20.6.12
7.2
zkušební provoz
5 dny
21.6.12
25.6.12
7.3
pilotní provoz
10 dny
26.6. 12
6.7.12
24
Předchůdci
7.4 8
předání do provozu
0 dny
6.7.12
6.7.12
Vyhodnocení a uzavření projektu
0 dny
6.7.12
6.7.12
Tabulka č. 6: Diagram časového plánu projektu Zdroj: Autor
4.1.4 Rizika projektu Při odhadování časové náročnosti projektu je třeba vzít do úvahy moţná rizika, která se projeví během průběhu projektu. Rizika jsou podle pouţité metodiky odhadů buď přímo zahrnuta v odhadech, nebo jsou specifikována zvlášť jako součást dokumentace. Rizika mohou být několika typů: technologická, rizika na straně lidských zdrojů, rizika součinnosti. 4.1.4.1 Technologická rizika Tento typ rizika je dán podceněním sloţitosti vyvíjené aplikace. Důsledkem je nemoţnost dokončit vývoj v konečném čase a nákladech. Dalším typem tohoto rizika je podcenění infrastruktury, do které bude vyvíjená aplikace zasazena. Důsledek je v podstatě stejný jako podcenění sloţitosti aplikace. Obě tato rizika jdou na vrub analytického týmu, který nebyl schopen na začátku projektu toto rozpoznat. Dalším rizikem, které má přesah do následujícího typu, je podcenění profesních znalostí a zkušeností členů týmu. Důsledkem je zvýšená pracnost projektu a moţná sníţená kvalita výstupu. 4.1.4.2 Rizika na straně lidských zdrojů Riziko je dáno mírou předpokládané fluktuace vývojářů a klíčových pracovníků na pozicích analytik a architekt systému. Dalším aspektem je přetíţení pracovníků během trvání projektu a z toho plynoucí horší kvalita kódu. 4.1.4.3 Rizika součinosti Tato rizika přicházejí ke slovu jednak ve fázi analýzy, kdy není díky nesoučinnosti pracovníků zadavatele moţné získat všechny relevantní informace v poţadovaném čase, coţ vede k prodluţování projektu. Dále se s nimi setkáváme ve fázi testování, a to ve formě nezajištění pracovníků z provozu na testování aplikace. V neposlední řadě přicházejí součinnostní rizika ke slovu při nasazování aplikace do infrastruktury budoucího provozního 25
prostředí. Zde se jedná o nutná technologická “okna”, plánované odstávky a dostupnost pracovníků infrastruktury.
4.1.5 Bezpečnost Dalším velice důleţitým bodem při analýze, návrhu a následném kódování aplikace je téţ neopomenout aspekt bezpečnosti. Jelikoţ velice častým jevem bývá to, ţe vývojáři a testeři aplikací se zaměřují na poţadované funkčnosti a jejich správné fungování a na oblast bezpečnosti nekladou aţ tak velký důraz. V našem případě se jedná o interní aplikaci, která se bude ze sta procent provozovat ve vnitřní infrastruktuře firmy. Proto se dá předpokládat, ţe jiţ tento fakt do jisté míry zabezpečí přístup k samotné aplikaci. Např. nebude moţné přistupovat k dané aplikaci z prostředí internetu. Nicméně i v takovém případě je třeba provést analýzu bezpečnostních rizik směrem k interním zaměstnancům firmy, tak aby aplikaci nebylo moţno zneuţít například pro interní fraud. Bezpečnostní politika, která definuje chování aplikací interním prostředí společnosti je definována interními bezpečnostními předpisy. Tyto předpisy a zároveň i bezpečnostní politiky jsou vytvářeny a udrţovány pracovníky oddělení vnitřní kontroly na základě těchto předpisů a norem: Mezinárodní standardy: ISO/IEC 270018, ISO/IEC 270029, ISO/IEC 2700510 Standardy pro posuzování bezpečnostních vlastností jednotlivých komponent informačního systému: zejména ISO/IEC 1540811 nebo standard ITSEC12[4] Na základě bezpečnostních poţadavků na vyvíjenou aplikaci vznikají téţ nefunkční poţadavky do katalogu poţadavků. Tyto poţadavky jsou vytvářeny v souladu s interní bezpečnostní politikou a ve spolupráci s pracovníky oddělení vnitřní kontroly. Před spuštěním aplikace do ostrého provozu, je třeba aplikaci otestovat od nezávislé společnosti formou penetračních testů a výsledné bezpečnostní nálezy si nechat od vývojářů zapracovat. Více k této problematice je uvedeno v kapitole 5.
8
Information Security Management System, nahrazuje normu BS 7799-2
9
Code of Practice for Information Security Management, nahrazuje ISO/IEC 17799:2005
10
Information Security Risk Management, dříve ISO/IEC 13335
11
Standard je známý téţ pod názvem Common Criteria
12
Information Technology Security Evaluation Criteria 26
4.2 Analýza Zvolený postup pro provedení analýzy pomocí jazyka UML. Protoţe jazyk UML není metodika, ale pouze notace zápisu, existuje mnoho způsobů, jak postupovat při samotné analýze. Při návrhu tohoto řešení byl zvolen následující postup: 1. Studium uţivatelských poţadavků, interview se zadavatelem. Zaloţení úloţiště pro EA model13. 2. Vytvoření katalogu uţivatelských poţadavků, validace, kategorizace poţadavků (funkční a nefunkční). 3. Propojení uţivatelských poţadavků (na základě katalogu) s jednotlivými případy uţití, definice aktorů systému a jejich následná validace zadavatelem. 4. Návrh uţivatelského rozhraní v kombinaci s případy uţití. 5. Tvorba analytického modelu tříd.
4.2.1 Sběr uţivatelských poţadavků Analytické práce musí vţdy vycházet z definice poţadavků na cílovou aplikaci, které analytik získá z interview se zadavatelem. Pokud je tento bod podceněn, nebo zcela vypuštěn je výsledkem takové práce aplikace, která z části nebo plně neodpovídá poţadavkům zadavatele. Cílem interview se zadavatelem je pomocí strukturovaného analytického rozhovoru získat informace o poţadovaných funkcích systému, dále o poţadovaných výkonnostních parametrech systému a v neposlední řadě i specifikaci toho co je ještě součástí systému a co jiţ není. Pokud tento poslední bod neprovedeme, hrozí riziko obtíţného dokončení analýzy. Pokus o namodelování „Vesmíru“ v případě nepřesného určení okolí systému. Analytických interview bývá typicky více, neboť je vhodné informace získávat iterativně. Po kaţdém interview je třeba vytvořit zápis a tento zápis nechat schválit zadavatelem. Předejde se tím vzniku myšlených předpokladů. Po ukončení všech interview je třeba získané informace, ať jiţ formou dokumentu, nebo prezentace probrat na setkání se zadavatelem. Dokument musí
13
UML modelování je provedeno pomocí nástroje Enterprise Architect 7.5 od firmy Sparx System 27
obsahovat jednotlivé prvky funkčnosti budoucí aplikace, tak jak byly identifikovány v průběhu analytických interview. Zatím bez ohledu na jejich priority. Toto je základem pro vytvoření katalogu poţadavků.
4.2.2 Katalog poţadavků Katalog poţadavků je vytvořen jako formální zápis funkčností a vlastností zjištěných v průběhu analytických interview. Tento katalog rozděluje zjištěné informace na dvě skupiny. Vlastnosti systému jako například poţadovaná odezva aplikace, nebo pouţitá databázová technologie jsou v katalogu uvedeny jako nefunkční poţadavky. Veškeré informace získané z interview, které poţadují nějakou funkci aplikace, jsou v katalogu jako funkční poţadavky. Tyto funkční poţadavky se de facto stávají základem USE CASE modelu. Neboť jejich splněním (realizace USE CASE) je aplikace vytvořena dle poţadavku zadavatele.
Obr. 3: Katalog uživatelských požadavků Zdroj: Autor
28
4.2.3 Diagram případů uţití Po studiu zápisů z analytických interview bude vytvořen prvotní model případů uţití. Tento model musí ve své první fázi obsahovat všechny případy uţití tak, jak jsou zachyceny v katalogu poţadavků v části funkční poţadavky. Následně je model případů uţití upravován tak, aby společná funkcionalita některých případů uţití byla prezentována samostatným objektem v diagramu.
Obr. 4: Ukázka include vazby v případu užití (use case) Zdroj: Autor
Na obrázku je ukázán stav diagramu po prvotním zachycení informací z interview a katalogu poţadavků. Dalším krokem je přiřazení objektů z katalogu poţadavků objektům v modelu případu uţití formou asociace (UML vazba). Tento krok nám ukáţe, zda jsme na některý uţivatelský poţadavek při tvorbě modelu případu uţití nezapomněli. Ze zkušeností z jiných projektů je vhodné tuto vazbu udrţovat jako samostatný model, abychom do modelu případu uţití nevnášeli rušivé prvky s modelem nesouvisejícím.
29
Obr. 5: Vazba katalogu požadavků na případy užití (use case) Zdroj: Autor
Práce s modelem případu uţití nekončí jeho prvotním vytvořením, ale jedná se o iterativní proces probíhající ve spolupráci se zadavatelem po celou dobu analýzy. Důvodem je skutečnost, ţe zadavatel mohl při analytických interview opomenout některou funkčnost, nebo byly chybné závěry analytika. Kaţdý případ uţití, který není „include“ musí být asociován s alespoň jedním aktorem. Pokud toto není splněno je chybné zadání. Kaţdý případ uţití musí obsahovat popis. Popis říká, co přesně daný případ uţití dělá. Tento popis je udrţován buď formou strukturovaného analytického textu, nebo formou vloţeného diagramu. Strukturovaný analytický text uvádím na příkladu z mé bakalářské práce. [4]
30
Type:
UseCase
Name:
Identifikace volajícího
Status:
Proposed. Version 1.0. Phase 1.0.
Popis UseCase: realizovat vyhledání klienta na základě předané identifikace načíst informace o klientovi z proměnných předávaných CTI OS na základě předaných proměnných vyhledat klienta v databázi klientů zobrazit kolekci vyhledaných klientů v GUI CTI (obrazovka vyhledání klienta ) Popis interakce UseCase s okolím: UC představuje pro uživatele skryté funkce prováděné na komunikační vrstvě CTI OS a logiky na úrovni aplikace CTI Pro správnou činnost je třeba nejdříve implementovat: UC Přenos identifikace z IVR Další informace a poznámky pro programátora: Po dokončení návrhu aplikace bude tento popis doplněn o specifikaci tříd a jejich metod tak, aby popis sloužil jako úplné zadání pro programátora
Vloţený diagram nám znázorňuje dynamiku vyuţití jednotlivých vzájemně závislých případů uţití a zpravidla se jedná o sekvenční diagram.
31
Obr. 6: Volání telefonního čísla z externího systému Zdroj: Autor
U komplikovanějších případů uţití je k popisu jejich chování kromě strukturovaného textu vyuţit i sekvenční diagram. V případu uţití „Volání telefonního čísla z externího systému“ byl tento postup pouţit. Sekvenční diagram pro uvedený případ uţití je ukázán na Obr. 6. Takto zpracovaný model případů uţití v sobě obsahuje všechny informace získané od zadavatele a je jedním startovním místem pro technický návrh aplikace.
32
4.2.4 Definice aktorů Jednou z informací, které jsou získávány během analytických interview je seznam uţivatelských rolí nebo uţivatelů, kteří budou nějakým způsobem v interakci s vyvíjeným systémem. Jsou to uţivatelé, kteří prostřednictvím práce se systémem pouţívají funkčnosti definované v katalogu poţadavků. Mohou to být nejenom lidé, ale i systémy komunikující s aplikací. Obecně se těmto uţivatelů říká aktoři. Pro úspěšné namodelování případů uţití je třeba v analytické fázi získat úplný seznam aktorů. Tento seznam je následně zapsán do modelu případu uţití ukázaném na Obr. 7.
Obr. 7 Případy užití (Use Case) Zdroj: Autor
33
Definice aktorů a definice případů uţití nám popisuje takzvané okolí systému. Toto je velice důleţité pro jasné vymezení jaká funkcionalita nebo činnost bude, respektive nebude součástí budoucího řešení.
4.2.5 Analýza uţivatelského rozhraní aplikace Uţivatel komunikuje s aplikací pomocí uţivatelského rozhraní. Jelikoţ se jedná o aplikaci, která je vázána na telefonický hovor probíhající v reálném čase je velice důleţité navrhnout ergonomické uţivatelské rozhraní. Tento návrh začíná jiţ ve fázi analýzy a to jiţ ve formě modelování uţivatelských obrazovek v analytickém nástroji EA.
Obr. 8: Analytické schéma uživatelského rozhraní Zdroj: Aplikace CTI, Autor
Toto nám umoţní propojit případy uţití s obrazovkami, které slouţí jako realizace daného případu uţití. Provedeme tím kontrolu, ţe kaţdý případ uţití, který je v interakci s uţivatelem 34
má odpovídající reprezentaci ve formě obrazovky. Dále zde vidíme základní přechody mezi jednotlivými obrazovkami, coţ bude ve fázi návrhu pouţito pro modelování diagramu tříd budoucí aplikace. Diagram vazby jednotlivých obrazovek na případy uţití je vhodné udrţovat jako samostatný model z důvodu zachování přehlednosti diagramu případu uţití.
Obr. 9: Vazba případů užití a objektů doménového modelu na uživatelské rozhraní Zdroj: Autor
4.2.6 Doménový model aplikace Po vytvoření modelu případu uţití a definici okolí systému je třeba vydefinovat problémové oblasti (doména) se kterými bude aplikace pracovat. Například klient, úvěr, kontakt na klienta. Tyto entity popisujeme na abstraktní úrovni formou doménového modelu aplikace. Jedná se o analytický model tříd, pomocí kterého zafixujeme všechny business entity pouţívané aplikací, včetně jejich vzájemných vazeb. V této fázi neprovádíme detailní popis entit, ale pouze jejich pojmenování a vazby.
35
Obr. 10: Doménový model Zdroj: Autor
Jednotlivé entity a jejich vazby z tohoto modelu budou ve fázi návrhu slouţit jako východisko pro tvorbu datového modelu aplikace a zároveň jako jedno z východisek pro návrh modelu tříd. Jako doplňující diagram je vhodné entity pouţité v doménovém modelu navázat na model obrazovek, abychom ověřili, ţe kaţdá z definovaných obrazovek pracuje nad nějakou mnoţinou dat.
4.2.7 Závěr analýzy Po vytvoření všech modelů popsaných v předchozích kapitolách následuje fáze jejich validace se zadavatelem. Zde je vhodné provádět tuto validaci několikrát během probíhající analýzy. Zamezí se tím chybám z myšlených předpokladů, nebo nedostatečným zadáním. Výsledkem 36
ukončené analýzy je zafixování poţadavků zadavatele a souhlas zadavatele se způsobem jak bude nová aplikace fungovat a vypadat. Pro další kroky (návrh a realizace) je nutné jiţ schválenou analýzu neměnit. Pokud je toto ze závaţných důvodů třeba, je nutno se vrátit do fáze analýzy coţ můţe přinést vícenáklady na celý projekt. Optimálním řešením je změny přesunout do další fáze vývoje aplikace.
4.3 Návrh aplikace Po úspěšně zakončené a akceptované analýze následuje fáze návrhu budoucí aplikace. I tato část vývojového cyklu pouţívá jazyk UML pro specifikaci detailního technického popisu aplikace. Na rozdíl od analytické části, která by neměla obsahovat technické podrobnosti budoucího řešení, návrh je specificky technický popis budoucí funkčnosti aplikace a jejího zasazení do existující infrastruktury organizace. Technický návrh lze rozdělit na dvě samostatné části. Návrh architektury aplikace a návrh jejího zasazení do infrastruktury. Funkční poţadavky, které jsme shromáţdili během analýzy a s nimi související USE CASE modely, jsou základem pro návrh architektury aplikace. Naopak nefunkční poţadavky nám určují budoucí zasazení aplikace do infrastruktury. Proces návrhu aplikace se skládá z několika částí. Tyto části vţdy korespondují s jiţ provedenou analýzou. Poznatky získané během analýzy dále rozpracovávají pouţité technologie pro vývoj aplikace. Výběr této technologie byl proveden v kapitole 3. Při návrhu projektu je výběr technologie většinou proveden aţ po fázi analýzy. Zde bylo zadání technologie specifické, tak jak je popsáno v kapitole 3.
4.3.1 Návrhový model tříd V průběhu analýzy byl vytvořen doménový model. Tomuto modelu se také říká analytický model tříd. Popisuje jednotlivé logické entity, které vstupují do vzájemných statických vztahů. V části návrhu je tento základní model rozpracován do jednotlivých tříd budoucího kódu aplikace. Při tomto procesu jsou pouţity standardní návrhové vzory. Tyto jsem čerpal ze zdrojů [1], [5] a [6]. Model tříd nám popisuje budoucí statické chování aplikace, tak abychom pokryli všechny vytvořené USE CASE. Tento postup se nazývá realizace USE CASE. Jelikoţ jsme v průběhu analýzy doplnili USE CASE modely o vazby na budoucí obrazovky aplikace a dále o strukturovaný popis funkčnosti, kterou má daný USE CASE pokrýt, je tvorba struktury tříd 37
výrazně zjednodušena. Vţdy postupujeme tak, ţe funkčnost popsaná strukturovaným textem USE CASE je namodelována jako co nejmenší moţný počet tříd a jejich vazeb. Toto postupně provádíme pro jednotlivé USE CASE bez toho abychom v této první fázi vyhledávali společné funkčnosti.
Obr. 11: První fáze (iterace) modelu tříd Zdroj: Autor
Jakmile je takto staticky popsána budoucí funkčnost aplikace, doplníme tento model ještě o objekty z doménového modelu, pokud jiţ nevznikly během realizace USE CASE modelu. V další fázi, kdy stále ještě ignorujeme dynamiku vztahů, provedeme detekci moţných návrhových vzorů ve vytvořeném modelu tříd. Tento proces není jednokrokový, ale iterativní. V další iteraci se snaţíme o vyhledání se stejnou nebo podobnou funkčností. Zde je třeba dát velký pozor na zdánlivě podobné funkčnosti, které ovšem spadají do jiné části problémové domény. Další postup čištění modelů tříd je silně závislý na pouţitých návrhových vzorech. 38
Výsledkem iterativní tvorby modelu tříd, je model tříd včetně metod, atributů a vzájemných vazeb, který je jednou z částí zadání práce pro programátora. V následujícím textu je na jednom případu uţití ukázán postup tvorby diagramu tříd z analytického modulu tříd s vyuţitím návrhových vzorů.
Obr. 12: Class diagram (model tříd) Zdroj: Autor
39
V průběhu analýzy budoucí aplikace jsme identifikovali moţnost vyuţít návrhových vzorů pro některé části aplikace. Tyto vzory se pouţívají ve specifických situacích jako určitý druh šablony pro návrháře systému. Principem pouţití návrhových vzorů je jejich opakované pouţití, coţ do značné míry eliminuje chyby při návrhu aplikace. Návrhář nemusí znovu vymýšlet vymyšlené. Před chybami, které mohou vznikat z nedomyšlení všech důsledků určitého návrhu, a které jiţ před ním udělala spousta jiných návrhářů, chrání právě pouţití šablony návrhového vzoru. V našem případě přicházelo do úvahy vyuţití jednoho z nejčastěji pouţívaných návrhových vzorů, a to vzoru „Facade“. Na následujícím obrázku je ukázán princip vzoru.
Obr. 13: Ukázka Class Modelu vzoru Facade Zdroj: Autor
Vzor je zaloţen na myšlence zjednodušení práce se sloţitým rozhraním systému. Pokud navrhovaná aplikace musí komunikovat s jiným systémem, který z rozličných důvodů disponuje pouze sloţitým rozhraním s mnoha závislostmi, je nepouţití vzoru Facade 40
u sloţitější aplikace takřka jistým zdrojem budoucích problémů. Naopak její vyuţití výrazně usnadňuje vývoj a zpřehledňuje vytvářený kód aplikace. V následující ukázce psané pomocí symbolického kódu je tento princip jasně vidět na příkladu volání třídy „Telephony“ z objektu „Client“. Třída „Telephony“ zde reprezentuje fasádu, která zakrývá objekty „Ccm“, „Memory Manager“ a „Persistence“. /* Symbolicky zapsany princip navrhoveho vzoru facade */
/* slozite rozhrani */ class CCM { public void freeze() { ... } public void init(long position) { ... } public void execute() { ... } }
class MemoryManager { public void load(long position, byte[] data) { ... } }
class Persistence { public byte[] read(long data, int size) { ... } }
/* implementace navrhoveho vzoru Facade */
class Telephony { private CCM callmanager; private MemoryManager pamet; private Persistence uloziste;
public Telephony() { this.callmanager = new CCM(); this.pamet = new MemoryManager(); this.uloziste = new Persistence(); }
41
public void start() { callmanager.freeze(); pamet.load(ADDRESS, uloziste.read(DATA, DATA_SIZE)); callmanager.init(ADDRESS); callmanager.execute(); } }
/* Pouziti fasady v ukazce kodu */
class Client { public static void main(String[] args) { Telephony facade = new Telephony(); facade.start(); } }
Vyvíjená aplikace má jako jeden ze svých spolupracujících systémů důleţitý, ale zároveň velice sloţitý systém telefonie. Programátorská dokumentace pro programování tohoto systému čítá cca 900 stran textu. Systém je extrémně sloţitý a rozsáhlý, takţe návrhový vzor zde přesně splnil svoji funkci, a zakryl tuto sloţitost do relativně snadněji pouţitelného rozhraní. Zde je třeba se zmínit ještě o druhém aspektu vyuţití některých typů návrhových vzorů. Typicky se jedná o vzor Facade, Adapter a Decorator14. Jejich pouţití činí aplikaci méně citlivou na změny v systému. V našem případě aktualizace telefonního subsystému nebude znamenat zásah do celé aplikace, ale pouze do její menší části, tedy do implementačního kódu návrhového vzoru. Na výše uvedeném fragmentu symbolického kódu by se jednalo o změnu objektu „Telephony".
14
Návrhové vzory, týkající se struktury programu 42
4.3.2 Datový model Při návrhu datového modelu je třeba vycházet z analytického modelu tříd (doménový model), který definuje jednotlivé datové entity. Doménový model definuje budoucí entity na abstraktní úrovni. Při návrhu datového modelu aplikace provádíme optimalizaci doménového modelu formou jeho transformace na ER diagram. Tento diagram rozděluje logické entity doménového modelu tak, abychom optimálně vyuţili daný databázový stroj a zároveň data ukládali pokud moţno v normalizované formě15. Tímto postupem zamezíme hazardům při aktualizaci tabulek v databázi. Datový model musí být tvořen i s přihlédnutím k jiţ existujícímu modelu tříd, který je na základě vytvořeného datového modelu doplněn o třídy a návrhové vzhory pro přístup k datům (Data Access Objects).
Obr. 14: ER diagram Zdroj: Autor
15
Jedná se o normální formy ve vztahu ke struktuře databázového modelu 43
4.3.3 Návrhový model obrazovek aplikace GUI V průběhu analýzy byl vytvořen a uţivatelem schválen logický model GUI. Tento model obsahoval pouze kostry budoucích obrazovek aplikace a jejich vzájemných vazeb. Při návrhu GUI vycházíme z tohoto modelu. A jednotlivé obrazovky aplikace jsou nyní rozpracovány do detailní podoby včetně grafického ztvárnění. Obrazovky musí ve fázi návrhu obsahovat všechny budoucí vizuální prvky včetně specifikace zobrazovaných dat, jejich typů, moţných rozsahů a logických kontrol. Toto není moţno znázornit v jednou diagramu, neboť tento by se stal nečitelným. Detailní popisy obrazovek jsou rozděleny na část grafickou, která bývá vytvořena grafikem firmy na základě grafického manuálu společnosti. Jednotlivé vizuální prvky budoucí obrazovky jsou identifikovány referenčním číslem a detailní popisy typů vazeb a kontrol jsou vytvořeny ve formě tabulky s referenčními čísly vizuálních prvků. Tento postup zajistí, ţe aplikace bude z pohledu uţivatele pracovat tak, jak bylo specifikováno. Vytvořená tabulka detailních popisů vizuálních prvků, je zároveň jedním z podkladů pro tvorbu testovacích scénářů budoucí aplikace. Stejným způsobem jsou popsány i vazby mezi jednotlivými obrazovkami aplikace. Pokud je to moţné, tak vyuţijeme pro popis dynamiky aplikace sekvenční diagram.
Obr. 15: Sekvenční diagram vyhledání klienta Zdroj: Autor
44
Kompletně popsané GUI aplikace je nyní nutno navázat na datový model a na model tříd. Cílem je, aby kaţdá poloţka v GUI měla odpovídající reprezentaci v datovém modelu a zároveň, aby kaţdý funkční prvek měl odpovídající reprezentaci v modelu tříd. Tato vazba je doplňována do tabulky s referenčními čísly vizuálních prvků. Je nutné opět zdůraznit, ţe tento proces je iterativní. Většinou se jedná o pět aţ deset iterací.
Obr. 16: Detailní popis GUI aplikace Zdroj: Aplikace CTI, Autor
Objekt ID Typ
Rozsah hodnot
Logické vazby
1
Textbox
Textové max. 30
Minimálně 4 povinné znaky
2
Textbox
Numerické 10
Maska / po 6 znaku, pouze vizuálně
3
Textbox
Datum DDMM
Z důvodu vyhledávání je rok oddělen do
Datum RRRR
samostatného pole
4
Textbox
Formát
platného
telefonního čísla 5
Textbox
Numerické max. 10
6
Textbox
Numerické 12
Interní identifikátor klienta 45
7
Textbox
Textové max. 50
8
Textbox
Textové max. 50
9
Textbox
Numerické 5
Maska mezera po 3 znacích pouze vizuálně
10
Textbox
Numerické 12
Interní identifikátor úvěru
11
Textbox
Numerické 12
12
Textbox
Numerické 18
13
Button
Akce provede smazání zapsaných hodnot ze všech polí
14
Button
Akce provede naplnění gridview (16) vyhledáním v databázi podle specifikace 1 aţ 12. Při vyplnění více neţ jedné poloţky je pro vyhledání pouţit operátor „and“.
15
Button
Akce provede
uzavření
vyhledávacího
formuláře. 16
Gridview
Vizuální komponenta zobrazující záznamy klientů vyhledané pomocí 14. Dvojklik na řádek provede přechod na detailní formulář shodně jako nepopsané tlačítko „detail“.
17
Listbox
V závislosti na záznamu vybraném v 16 ukazuje seznam karet vydaných klientovi.
18
Listbox
V závislosti na záznamu vybraném v 16 ukazuje seznam úvěrových případů klienta. Tabulka č. 7: Detailní popis prvků GUI Zdroj: Autor
4.3.4 Sekvenční diagram Sekvenční diagram je při návrhu aplikace vyuţit tehdy, kdyţ potřebujeme postihnout dynamický aspekt návrhu. Tedy jedná se o interakci objektů v čase. Některé USE CASE nelze jednoznačně popsat pouze strukturovaným textem ani statickým modelem tříd. Například 46
proto, ţe akci na daném objektu nelze provádět kdykoliv, ale pouze v návaznosti na jinou akci. Typickým příkladem této situace je přihlášení do aplikace a její následné pouţívání. Pokud nebyl proveden krok přihlášení, není moţno provádět další akce specifikované USE CASE. Toto chování aplikace popíšeme právě pomocí sekvenčního diagramu. Takto popsaná dynamika je další z částí zadání pro programátora. Pouţití sekvenčního diagramu je ukázáno na Obr. 15.
4.3.5 Model komponent Toto je první část návrhu, která nepracuje pouze s budoucím kódem aplikace, ale především se způsobem, jak bude aplikace členěna pro její nasazení do prostředí finanční společnosti. Předchozí návrhové modely popisovaly vznikající aplikaci jako celek, bez jejího rozdělování do funkční komponenty. Jelikoţ některé části aplikace mohou být v budoucnu vyuţity i jiným způsobem (například data z datového modelu), je třeba vytvořit model, který specifikuje soubory návrhových objektů (kód, data, logika) jako komponenty budoucí aplikace. Mezi těmito komponentami jsou jasně specifikovaná rozhraní. Toto nutně neznamená, ţe aplikace je budována jako distribuované řešení, pouze je takto specifikována moţnost rozdělit v budoucnu aplikaci na více částí.
Obr. 17: Model komponent Zdroj: Autor
47
Na Obr. 17Obr. 17 je znázorněn model komponent. V extrémním případě můţe být celá aplikace jedna komponenta.
4.3.6 Model nasazení Aplikaci je kromě jejího vyvinutí a otestování třeba nasadit do prostředí infrastruktury finanční společnosti. Tento proces je popisován pomocí modelu nasazení. Jednotlivé komponenty aplikace popsané v kapitole 4.3.5 musí být umístěny na odpovídající místa v infrastruktuře. Na Obr. 18Obr. 18 je zobrazen model nasazení aplikace. Diagram nasazení popisuje přesné umístění na jednotlivé fyzické počítače a je základem pro tvorbu instalační a administrátorské dokumentace.
Obr. 18: Model nasazení aplikace (deployment diagram) Zdroj: Autor
4.3.7 Aktivity diagram Diagram aktivity vyuţijeme pro detailní popis implementace jednotlivých tříd a to v případě, ţe logika implementace vyţaduje popis větvení. Dále je tento diagram vyuţíván pro popis vzájemné interakce mezi jednotlivými třídami budoucí aplikace. Na Obr. 19Obr. 19 je znázorněn Aktivity diagram. Aktivity diagramy jsou společně s diagramem tříd nedílnou součástí zadání pro implementaci.
48
Obr. 19: Aktivity diagram Zdroj: Autor
4.3.8 Závěr návrhu aplikace Návrh budoucí aplikace je stejně jako analýza iterativní proces. Běţně bývá provedeno jedna aţ pět iterací. Po kaţdé iteraci je třeba informovat zadavatele formou schůzky a prezentace výsledků o postupující práci. Předejdeme tím rozčarování zadavatele, pokud návrh aplikace neprobíhá dle jeho představ. První iterace je hrubý návrh budoucí aplikace včetně GUI, pouţitých technologií a zasazení aplikace do existující infrastruktury. Další iterace tento návrh upřesňují do většího detailu. Díky interakci se zadavatelem je moţno případné problémy návrhu zachytit co nejdříve. Hotový návrh představuje kompletní zadání pro implementaci a nasazení. Ve fázi implementace by nemělo docházet ke změnám v definicích objektů a technologií bez jejich promítnutí do návrhu. 49
Návrh aplikace je předáván formou modelu v nástroji pro modelování UML, nebo ve formě strukturovaného dokumentu. Tento dokument nebo model je nutné schválit technickými zástupci zadavatele. V okamţiku kdy je hotov návrh aplikace, je moţno provést odhad pracnosti implementace aplikace viz kapitola 4.1. Na základě provedeného návrhu a časového odhadu implementace je proveden výběr týmu pro implementaci.
50
5
IMPLEMENTACE, TESTOVÁNÍ A NASAZENÍ
5.1 Implementace Pro implementaci řešení je třeba mít tým vývojářů, se zkušenostmi s technologiemi pro vývoj aplikace. Velikost týmu je dána mimo jiné časem poskytnutým na vývoj aplikace a moţnostmi paralelizace vývoje. Tyto moţnosti vychází z analýzy a návrhu, kde existují určité části budoucí aplikace, které je moţno vyvíjet paralelně. Typicky se jedná o paralelizaci databázového a aplikačního vývoje. Nedílnou součástí implementace kódu, je tvorba UNIT testů pro veškerá veřejná rozhraní tříd. Programátor dostává zadání pro vývoj na základě informací uvedených v návrhu aplikace. Toto je pro něj veřejné rozhraní, které musí implementovat. Postup implementace je popsán formou UML diagramů (USE CASE, SEKVENČNÍ DIAGRAM, AKTIVITY DIAGRAM, CLASS DIAGRAM, ER DIAGRAM a DIAGRAM GUI). Pro kaţdou jednotku implementace dostane programátor pouze ty části uvedených diagramů, které mají dle názoru architekta pro danou úlohu smysl. Prvním krokem implementace je napsání automatizovaných postupů pro implementované třídy. Teprve následně je prováděna implementace funkčnosti, která můţe být takto pravidelně testována. S tím jak vznikají větší funkční celky, jsou automatizované funkční testy doplňovány i o testy těchto celků. Uvedený postup umoţňuje udrţet vývoj konsistentní i v případě nutných zásahů do jiţ existujícího kódu. Pokud jsou správně napsány testy, má architekt jistotu, ţe je zárodek aplikace funkční vţdy, kdyţ testy dopadnou v pořádku. Jelikoţ vývoj aplikace sebou nese i riziko změny zadání během vývoje, je tento postup vhodný i pro implementaci těchto změn. Teoreticky by se vývojový tým měl změnám zadání v průběhu implementace bránit. Ale v praxi toto není moţné. Vývoj aplikace, stejně jako všechny předchozí kroky probíhá iterativně. Obvyklá délka iterace je jeden týden. Na začátku vývoje jsou stanoveny milníky pro dokončení jednotlivých funkčních celků aplikace. Kaţdý funkční celek je ohodnocen svojí prioritou. Tato priorita určuje pořadí vývoje jednotlivých celků a to na základě jejich potřebnosti pro vývoj dalších celků, anebo pro jejich prezentaci zadavateli. Pro kaţdou týdenní iteraci musí být stanoveno, co má být dokončeno. Pokud není některá část kódu dokončena, rozhoduje se o přesunutí do další iterace. 51
Po dokončení funkčního celku vývojový tým prezentuje výsledky své práce zadavateli. Zde není vhodné zvolit postup „ukáţeme vám výsledek aţ na konci“, protoţe je vysoké riziko chybných očekávání zadavatele. Mnohem vhodnější je pravidelná účast zástupců zadavatele v průběhu vývoje právě formou prezentace dílčích výsledků. Pokud dochází k rozporu očekávání zadavatele od prezentované skutečnosti, je moţno tento rozpor vyřešit s výrazně menšími náklady, neţ pokud by se na něj přišlo aţ při akceptaci hotové aplikace. Pro usnadnění vývoje aplikace, jsou vyuţívány nástroje pro správu verzí kódu (CVS, Subversion, Mercurial, Git)16. V tomto případě je vyuţit nástroj Subversion17, jelikoţ je pouţíván pro správu kódu všech projektů ve finanční společnosti. Tvorba jednotlivých buildů budoucí aplikace je prováděna nástrojem Hudson18, který je pouţíván i pro ostatní projekty v rámci finanční společnosti. Tímto způsobem jsou spouštěny i pravidelné noční automatizované testy kódu. Jakmile programátor umístí do Subversion repository chybný kód, který nevyhovuje existujícím testům, je toto detekováno a následně reportováno. Vývojový tým musí v průběhu vývoje hlídat časové rámce stanovené pro vývoj jednotlivých částí aplikace. Pokud se některá část vývoje výrazně zpoţďuje, je třeba okamţitě hledat příčinu tohoto stavu a její řešení. Příčin můţe být celá řada. Nejtypičtější jsou: Špatný výběr členů vývojového týmu – nedostatečné zkušenosti vývojářů s danou technologií, nebo přecenění schopností Špatný návrh aplikace nebo pouţitých technologií – vyuţití nedostatečně stabilních technologií, nebo podcenění návrhu zasazení aplikace do infrastruktury Velké mnoţství změn ze strany zadavatele v průběhu implementace – nedostatečná analýza problematiky, nebo špatný projekt management Špatná součinnost infrastrukturního týmu zadavatele – nejsou včas k dispozici počítače, data nebo síťové prostředky Řešení popsaných problémů je v kompetenci projektového manaţera projektu. Většinu těchto problémů lze dopředu eliminovat správnou a úplnou analýzou rizik projektu, tak jak je popsána v kapitole 4.1.4.
16
Nástroje pro distribuovanou správu kódu.
17
Nástroj pro správu a verzování zdrojových kódů
18
Nástroj pro kontinuální integraci 52
5.2 Testování Kaţdá vyvíjená komerční aplikace musí v průběhu vývoje a po jeho ukončení procházet fází testování. Testování aplikace je nedílnou součástí vývoje, neboť pouze kvalitně testovaná aplikace splňuje poţadavky zadavatele a zároveň je dokumentováno, ţe aplikace pracuje očekávaným způsobem. Kvalitní otestování aplikace není moţné bez spolupráce s vývojovým týmem a s pracovníky zadavatele. Testy aplikace jsou rozděleny do několika fází, podle toho kdo a kdy tyto testy provádí.
5.2.1 Unit testy Jako první jsou prováděny tzv. unit testy, tedy testy vytvářené přímo vývojáři. Toto jsou testy určené k udrţení integrity vyvíjené aplikace během procesu vývoje. Testy jsou zaměřeny na kontrolu veřejného rozhraní jednotlivých objektů aplikace. Pokud vývojář provádí nějakou změnu v chování vyvíjeného objektu a tato změna má jakýkoliv dopad na rozhraní objektu (například změna typu návratové hodnoty funkce), musí test pro daný objekt tuto změnu odhalit. Z výše uvedeného je zřejmé, ţe vývoj unit testů můţe být i ekvivalentní náročnosti vývoje aplikace. Projektový management má při vývoji tendenci rozsah unit testů omezovat, aby sníţil náročnost vývoje aplikace. Ne vţdy jsou výsledkem ušetřené náklady. Podcenění testů na této základní úrovni vede k velice nepříjemným chybám, které se následně projeví v dalších fázích testování. Další nepříjemný projev podceněných unit testů přichází v okamţiku, kdy zadavatel v průběhu vývoje pozmění zadání. Jelikoţ je tvorba unit testů pro celou aplikaci opravdu velice náročná činnost, je vhodné a doporučené při jejich tvorbě postupovat tak, ţe nejprve jsou vytvořeny testy pro nejdůleţitější části aplikace, nebo pro ty kde je předpoklad jejich častější změny v průběhu vývoje. Aby unit testy měly přínos pro vývoj, je nutné je pravidelně provádět a vyhodnocovat jejich výsledky. Toto je zajištěno pomocí k tomu vytvořených nástrojů. V našem konkrétním případě vývoje aplikace pro podporu operátorů call centra byl k tomuto účelu vyuţit nástroj Hudson. Pokud je při spuštění definovaných testů zjištěna chyba, je o tom vyrozuměn jednak vývojář, který chybný kód umístil do kódového repository, a jednak technický manager daného projektu. Testy musí být udrţovány a vyvíjeny současně s aplikací nebo dříve. Jenom tak předejdeme situaci, kdy kód je v pořádku a chyba je v testu. V ideálním případě by unit testy měl psát jiný vývojář, neţ ten který vyvíjí testovaný kód. V praxi to bohuţel často takto není. 53
5.2.2 Testy komponent Dalšími testy jsou testy komponent aplikace. Zde jiţ nejde o automaticky prováděné testování, ale o práci členů testovacího týmu. Členové testovacího týmu dostávají jako zadání pro svoji práci testovací scénáře. Coţ jsou detailní popisy práce s budoucí aplikací, nebo s jejími částmi. Na základě provádění jednotlivých popsaných kroků v testovacím scénáři testeři vyhodnocují tyto kroky stylem „v pořádku“, nebo „chyba“. Toto mohou provést díky tomu, ţe testovací scénář obsahuje popis očekávaného chování aplikace, nebo její části. Při testování komponent aplikace se ještě nejedná o uţivatelské testy popsané dále, ale o funkční testy vyvinutého kódu ve větších celcích. I kdyţ je k dispozici testovací scénář musí tester disponovat schopnostmi pracovat s technickými nástroji pouţívanými při vývoji aplikace. Například SQL nástroje, vývojové nástroje pouţité pro vývoj aplikace. ID
Krok Předpoklady Test
1
1.1
Konektivita na
Očekávaný výsledek
Spustit aplikaci CTI v prostředí Zobrazilo se
LDAP VS2010 s parametsrem -TEST
server 1.2
nejsou
aplikace Do pole jméno zapsat text TEST Text zapsán focus na a stisknout klávesu TAB
1.3
nejsou
přihlašovací okno
poli heslo
Do pole heslo zapsat text TEST a Text zapsán, kliknout na tlačítko OK
přihlašovací okno uzavřeno bez chybových hlášení
Tabulka č. 8: Ukázka scénáře testu komponent Zdroj: Autor
5.2.3 UAT testy UAT testy, neboli uţivatelské akceptační testy, jsou pouţívány ve fázi dokončování aplikace a jejího předávání budoucím uţivatelům. Tyto testy se dělí podle typu aplikace na několik kategorií: Testy uţivatelů, které mají na základě testovacích scénářů pro UAT testy dokumentovat shodu vlastností vyvinuté aplikace se zadáním. Tyto UAT testy jsou 54
vytvářeny z katalogu uţivatelských poţadavků. Na testech se jako členové testovacího týmu podílejí i budoucí skuteční uţivatelé aplikace. Výsledkem tohoto typu testu je dokument „akceptační protokol“, kde je písemně potvrzena shoda předpokládané a skutečné funkčnosti aplikace. Pokud dojde při UAT testech k neshodám mezi poţadovanou a skutečnou funkčností, je třeba další iterace vývoje a testování. Toto probíhá v cyklu tak dlouho aţ je aplikace akceptována. ID
Krok Předpoklady Test
Očekávaný výsledek
1
1.1
Zobrazilo se
Nejsou
Spustit aplikaci CTI
přihlašovací okno aplikace 1.2
Nejsou
Do pole jméno zapsat text TEST Text zapsán focus na a stisknout klávesu TAB
1.3
Nejsou
poli heslo
Do pole heslo zapsat text TEST a Text zapsán, kliknout na tlačítko OK
přihlašovací okno uzavřeno bez chybových hlášení
Tabulka č. 9: Ukázka scénáře UAT testu Zdroj: Autor
Integrační testy jsou pouţity v případě, ţe daný typ aplikace je provázán s větším mnoţstvím dalších spolupracujících systémů. Toto je typické pro SOA aplikace, nebo pro aplikace pracující ve spolupráci s větším mnoţstvím dalších systémů. Tyto testy nazývané téţ END to END testy mají ověřit chování aplikace v kontextu svého okolí. Testovací scénáře jsou vytvářeny nikoliv pro chování aplikace jako takové, ale pro její zapojení do práce s ostatními aplikacemi. V případě námi vyvíjené aplikace bylo nutno tento typ testů vyuţít, neboť některé vstupy vyvíjené aplikace pocházely z dalších spolupracujících systémů infrastruktury CISCO. Tvorba scénářů pro END to END testy vyţaduje spolupráci se specialisty pro komunikující systémy, protoţe jenom tak jsme schopni otestovat chování kooperace aplikace v celém rozsahu. Forma testovacích scénářů je i zde sekvence testovacích kroků a předpokládaných výsledků pro úspěšné splnění testů. 55
ID
Krok Předpoklady Test
Očekávaný výsledek
1
1.1
Zobrazilo se
nejsou
Spustit aplikaci CTI
přihlašovací okno aplikace 1.2
nejsou
Do pole jméno zapsat text TEST Text zapsán focus na a stisknout klávesu TAB
1.3
Nejsou
poli heslo
Do pole heslo zapsat text TEST a Text zapsán, kliknout na tlačítko OK
přihlašovací okno uzavřeno bez chybových hlášení
2
2.1
Konektivita na
2.2
Pomocí LDAP admin nástroje Heslo změněno
LDAP změnit uţivateli TEST heslo na
server
hodnotu 1234
nejsou
Opakovat
test
ID
1
kroky Výsledek testu musí
1.1,1.2,1.3 2.3
Konektivita na server
být chyba
Pomocí LDAP admin nástroje Heslo změněno
LDAP změnit uţivateli TEST heslo na hodnotu TEST Tabulka č. 10: Ukázka scénáře end to end testu Zdroj: Autor
Výkonové testy. Pokud katalog uţivatelských poţadavků ve své části nefunkčních poţadavků obsahuje výkonové parametry, například rychlost odezvy aplikace, rychlost přístupu do databáze, je třeba provést sadu testů výkonu tak, abychom tyto poţadavky splnili. Pro tento typ testů je nutno vytvořit testovací prostředí, které se svými parametry blíţí budoucímu produkčnímu prostředí pro nasazení aplikace. Pokud toto není moţné z důvodu kapacitních, nebo jiných, je třeba vytvořit takové testovací prostředí, abychom mohli na něm dosaţené výsledky aproximovat na budoucí produkční prostředí. Pro výkonové testy musíme vyuţít nástrojů schopných simulovat reálnou zátěţ aplikace například formou souběţné práce předpokládaného počtu uţivatelů. Výstupem testů je protokol, který ukazuje dosaţené odezvy systému 56
v závislosti na vstupní zátěţi. Pokud systém v zátěţovém testu neobstojí, je třeba hledat příčinu selhání ve špatném návrhu infrastruktury aplikace a/nebo ve špatném designu vyvíjené aplikace. V kaţdém případě je odstraňování tohoto typu problému jedno z nejnáročnějších jak časově tak finančně.
5.2.4 Tvorba testovacích prostředí Kromě úvodní fáze vývoje kdy vývojáři pracují na svých pracovních stanicích je po celou dobu vývoje aplikace, testování a nasazení do provozu, třeba mít vytvořená testovací prostředí. Toto je nutné především z důvodu izolace testovaného kódu od jeho vývoje. Předejde se tím chybám typu „u mě to funguje“. Dále je testovací prostředí nutné pro to, ţe na běţnou vývojářskou pracovní stanici není moţné a ani vhodné instalovat kompletní infrastrukturu nutnou pro běh aplikace. Na testovací prostředí dále není moţné nasazovat jakýkoliv kód aplikace, který neprošel základním unit testováním. Toto nutí vývojový tým od začátku vývoje k vytváření fungujících distribučních balíčků, a tudíţ tato velice důleţitá součást vývoje aplikace není vytvářena na konci vývojového cyklu ve spěchu. Testovací prostředí je vytvářeno podle poţadavku architekta vyvíjeného systému pracovníky infrastrukturního týmu zadavatele. Tento krok je důleţitý, neboť umoţňuje identifikovat případné problémy s provozem aplikace jiţ v raných fázích testování. V průběhu vývoje aplikace můţe vzniknout několik testovacích prostředí. Důvodem je potřeba testování různých aspektů vyvíjené aplikace, nebo souběţná práce týmu testerů, kteří mají na starosti testy modulů aplikace a týmu který provádí integrační testy. Další testovací prostředí vzniká v okamţiku provádění výkonových testů. V některých případech mohou být zapotřebí ještě speciálně připravená prostředí pro určité specifické druhy uţivatelského testování. Mezi tyto speciality patří například práce s citlivými daty klientů, kdy takováto data nesmí být podle interních předpisů finanční společnosti k dispozici na běţných testovacích prostředích. Vznik jednotlivých prostředí je plně ve správě oddělení infrastruktury finanční společnosti, pod řízením managera vývoje a testování aplikace.
5.2.5 Testovaní v praxi plus typické problémy Teorie testování je bohuţel většinou velice odlišná od praktického provedení. Vytvořit kvalitní tým testerů je finančně i organizačně velice náročné. Vyuţití externích firem zajišťujících testování naráţí naopak na interní směrnice finanční společnosti. K testování jsou proto vyuţíváni pracovníci vývojového oddělení ve spolupráci s reálnými uţivateli 57
aplikace. Tento model testování přináší vysokou zátěţ pro pracovníky pověřené testováním. Například pracovník call centra, který pracuje v testovacím reţimu s novou aplikací, je současně testerem, ale zároveň se můţe stát, ţe vyřizuje běţný příchozí hovor, coţ samozřejmě musí provádět starým způsobem současně s prací s novou aplikací. Jiným způsobem neţ reálným provozem nelze některé části aplikace otestovat. Zásadní vliv na kvalitu testování a tudíţ i na kvalitu výsledné aplikace má způsob vytvoření a detailnost testovacích scénářů. Zde se můţe analytik při jejich vytváření dopustit dvou zásadních chyb. Buď vytvoří tak detailní testovací scénáře, ţe je nelze v reálném čase testovacího cyklu dokončit, nebo naopak vytvoří scénáře na tak hrubé úrovni, ţe výsledek testu nelze korektně interpretovat a zjednat nápravu v případě selhání testu. Pro tvorbu testovacích scénářů je třeba vyuţít pracovníka se zkušenostmi s touto prací. Kvalitní testovací scénář musí obsahovat pro kaţdý jednotlivý testovací krok všechny potřebné předpoklady (předpokladem se rozumí stav testovaného systému, ve kterém se tento musí nacházet před začátkem testu), dále jednoznačný popis testovacího kroku, který neumoţňuje mnohoznačný výklad a dále přesnou specifikaci úspěchu či neúspěchu daného testovacího kroku. Pokud nejsou výše uvedené podmínky splněny, dochází k nejednoznačným výsledkům testování. Nelze tedy na základě výsledku testu říci, zdali je aplikace opravdu v pořádku či nikoliv. Testy aplikace musí být prováděny jiţ v rané fázi vývoje. Čím dříve je aplikace testována, tím levnější je odstraňování chyb a nejednoznačností. S postupujícím vývojem jsou následky chyby v kódu obtíţněji odstranitelné. Respektive jejich odstranění je náročnější. Zde opět vidíme důleţitost kvalitních unit testů. Oproti tomu je jejich funkce nejčastěji podceňovanou částí vývoje a testování. Často dochází k situaci, kdy vývojový tým sice vytváří unit testy, ale takovým způsobem, ţe test vţdy skončí správně nezávisle na tom, co je testováno, protoţe test psal tentýţ vývojář jako testovaný kód a z nějakého důvodu, většinou z důvodu nedostatku času, vytvořil chybný test. To co je na jedné straně ušetřeno na obsazení vývojového týmu testery schopnými vytvářet kód unit testů, je na druhé straně zaplaceno méně kvalitním kódem a náročností dalších fází testování. Pro kvalitní provedení UAT testů je nutno vyuţít kombinaci práce testera a zaměstnance z reálného provozu. Pokud tito pracují v součinnosti, je výsledek jejich práce vţdy kvalitnější, neţ kdyţ se tester musí naučit provozní záleţitosti a naopak pracovník z provozu kvalitně porozumět testovacím scénářům a metodikám.
58
Neméně důleţitá je funkce managera testování. Tento je zodpovědný za provádění jednotlivých typů testů, zjištěné problémy reportuje vývojovému týmu a ve spolupráci s vedoucím vývojového týmu plánuje jednotlivé iterace a typy testů. Testovaní je proces, který není jednorázový, ale vţdy cyklický. Zpravidla je prováděno několik iterací UAT testů (dvě aţ tři) v závislosti na kvalitě dodaného kódu. Je třeba zdůraznit, ţe ve fázi UAT testů jiţ není moţno provádět samostatné jednotlivé testy, ale vţdy je nutno provést regresní testování funkčnosti. Běţně dochází při vývoji k situaci, kdy oprava chyby v jedné části aplikace vytvoří indukovanou chybu zcela jinde.
5.3 Nasazení do provozu Před nasazením aplikace do provozu je nutné provést školení budoucích uţivatelů aplikace. Součástí tohoto školení je předání uţivatelské dokumentace. Školení provádí k tomu určený pracovník vývojového týmu na jednom z vytvořených testovacích prostředích. V našem případě bylo školení vzhledem k velkému počtu pracovníků call centra organizováno tak, ţe nejprve byli proškoleni vedoucí jednotlivých úseků call centra a ti následně proškolili své týmy. Pokud došlo při školení týmů k nejasnostem, byl pro pracovníky, kteří měli nějaké nejasnosti, uspořádán další cyklus školení pracovníky vývojového týmu. Pracovníci call centra dostali po dobu školení k dispozici jedno z testovacích prostředí na seznámení s aplikací. Toto seznámení nebylo prováděno formou UAT testů, ale volnou formou studia dokumentace a aplikace. Po úspěšném dotestování aplikace, zaškolení pracovníků a funkční akceptaci, dochází k nasazení aplikace do pilotního provozu. Tato fáze je přechodem mezi testováním a produkcí. V okamţiku přechodu aplikace do pilotního provozu musí být k dispozici veškerá provozní dokumentace k aplikaci, kde je kromě jiného popsán i detailní instalační postup. Tento postup vznikal ve spolupráci s infrastrukturním týmem při vytváření jednotlivých testovacích prostředí, takţe je jiţ odladěn a zde pouze formalizován. Pilotní provoz probíhá jiţ na produkčním prostředí, takţe pokud nebylo k dispozici prostředí pro výkonové testy je tyto moţno provést nyní. Pokud to okolnosti dovolují. Pilotní provoz je organizačně náročnou částí vývojového cyklu, neboť pracovníci z provozu musí po dobu pilotního provozu zvládat vysokou zátěţ práce starým i novým způsobem. Jakýkoliv problém nové aplikace přináší velké problémy, protoţe se prodluţuje čas pilotního provozu. Po úspěšném dokončení pilotního provozu je aplikace připravena k běţnému provozu. Zde starost o chod aplikace 59
přebírá oddělení provozu finanční společnosti. Vývojový tým musí vyčlenit část svých kapacit pro podporu aplikace v reálném provozu. Vývoj aplikace většinou neskončí nasazením první verze do provozu, ale pokračuje další iterací analýzy návrhu a vývoje další fáze. V této další fázi jsou implementovány nové funkčnosti a zároveň zapracovány připomínky a poţadavky uţivatelů z reálného provozu aplikace. Jednou z opomíjených částí vývoje aplikace je testování instalačních balíčků a postupů. Jak jiţ bylo výše uvedeno, optimálním způsobem provedení tohoto typu testu je tvorba instalačních balíčků jiţ v rané fázi testování aplikace. Pokud je tento postup ignorován a výsledné balíčky jsou vytvářeny na úplném konci vývojového cyklu, je nutno provést dodatečné testování těchto balíčků jako samostatný test. Toto samozřejmě prodluţuje dobu dodání aplikace a zvyšuje náklady na vývoj. Při testování instalace se mohou objevit závaţné problémy související s infrastrukturou, do které je aplikace instalována. Například nekompatibilita některých knihoven s cílovým 64-bitovým prostředím. Takový stav je jednoznačně chybou architekta systému a v této fázi znamená vţdy značné náklady na změnu. V extrémním případě můţe dojít i k redesignu některé části vyvíjené aplikace. I proto je vhodné provádět testy instalace, tak jak bylo popsáno výše. Stejný postup je třeba dodrţet i při tvorbě a následném testování instalační a provozní dokumentace. Čím častěji je proveden instalační postup (v rámci testování), tím kvalitnější dokumentace bude dodána. Instalační a provozní dokumentaci je třeba vytvářet osvědčenou formou checklistu se zahrnutím všech moţných variant. Tato dokumentace je velice podobná struktuře testovacích scénářů. De facto je také určitou formou testovacího scénáře. Pracovník oddělení infrastruktury by měl při instalaci postupovat striktně dle dodané dokumentace bez dalších myšlených předpokladů. Pokud se v průběhu tvorby instalačního postupu takový myšlený předpoklad vyskytne, je třeba informovat autora dokumentace a tuto doplnit. Důleţitou součástí testů instalační dokumentace a instalačních balíčků je i test extrémních stavů. Kupříkladu instalace při nedodrţení instalačních předpokladů, coţ můţe být například neexistující povinná komponenta operačního systému, nebo nedostatečné hardware vybavení pro běh aplikace. Instalace musí i v tomto případě končit definovaným způsobem.
60
6 VYHODNOCENÍ PROJEKTU Cílem této práce bylo provést analýzu, návrh a vývoj aplikace pro podporu operátorů call centra tak, aby byly splněny podmínky, které finanční společnost předem definovala. Zadání pro vývoj bylo relativně krátké: „Zlepšit a zefektivnit práci operátorů call centra tak, aby oddělení dosahovalo vyššího pracovního výkonu.“ Z toho je zřejmé, ţe se jedná o velice rozsáhlé zadání, které vyţaduje systematický přístup k dané problematice a jasné stanovení priorit jiţ od počátku práce na analýze.
Nejdříve jsem uskutečnil pohovory s pracovníky zadavatele tak, abych co nejvíce porozuměl jejich zadání. Na základě těchto pohovorů jsem byl schopen začít s analytickými pracemi. Důleţitou součástí mé práce v této fázi, byla i volba technologií pouţitých při budoucím vývoji a běhu aplikace. Obecně se v analytické fázi technologie nevolí, ale v tomto případě byly pouţité technologie jednou ze součástí zadání. Zde jsem jako analytik neměl moţnost volby.
Vlastní analýzu, návrh a vývoj aplikace jsem provedl ve čtyřech etapách: 1.
Etapa analýzy Na základě shromáţděných uţivatelských poţadavků a technických poţadavků byla provedena analytická fáze. Tato fáze sestávala z tvorby a validace katalogu uţivatelských poţadavků, dále pak z tvorby modelu případů uţití. Další částí byl návrh uţivatelského rozhraní ve formě analytického modelu a návrh analytického modelu tříd pro zafixování okolí systému z hlediska problémové domény viz Obr. 10: Doménový model. Modely byly vytvořeny v syntaxi jazyka UML, pomocí nástroje EA19. Součástí této etapy byla i intenzivní komunikace se zástupci zadavatele, tak aby výsledek odpovídal očekávání. Pro účely mé práce byla analytická část popsána tak, abych ukázal způsob práce s jednotlivými prvky pouţitými v průběhu analytického procesu.
19
Enterprise Architect 7.5 od firmy Sparx System 61
2.
Etapa návrhu Návrhem je myšleno obohacení výstupu analýzy o technické aspekty budoucího řešení. V této etapě jsem provedl tvorbu modelu tříd budoucí aplikace s vyuţitím návrhových vzorů, dále pak tvorbu datového modelu a detailní návrh uţivatelského rozhraní budoucí aplikace. Stejně jako v případě analytické, fáze i zde byl k tvorbě modelů vyuţit jazyk UML. V této fázi jsem také provedl, pro účely mé práce, zjednodušení výstupu tak, aby pokrýval typické aspekty návrhu aplikace. I v této etapě byla nedílnou součástí mé práce intenzivní komunikace se zadavateli a zároveň i s architektem infrastruktury finanční společnosti.
3.
Etapa implementace Tato etapa vývoje jiţ není moţná bez skutečného vývojového týmu, kterým nemůţe být pro takto rozsáhlou aplikaci jeden člověk. Pro vývoj aplikace jsem vyuţil interní vývojový tým finanční společnosti, ve kterém jsem figuroval na pozici vedoucího vývojového týmu a zároveň i na pozici analytika a návrháře. V textu mé práce nejsou uvedeny části kódu aplikace, ale zejména postupy a typické problémy, ke kterým při vývoji aplikace docházelo.
4.
Etapa testování a nasazení V etapě testování byly provedeny testy na základě vytvořených testovacích scénářů. Zde se ukázalo, jak kvalitní byly předchozí etapy. Vzhledem k tomu, ţe práce vývojářů vykazovala vyšší chybovost, bylo nutno testovací etapu opakovat ve více iteracích. Běţným standardem jsou 2 aţ 3 cykly testů. Zde bylo nutno provést úplné 4 cykly testů. Důvodem pro toto prodlouţení testovací fáze, byla malá zkušenost vývojářů s prací na tak rozsáhlé aplikaci. Jelikoţ se jednalo o interní vývojový tým, nebylo vţdy moţné získat vývojáře s dostatečnými zkušenostmi. Nasazení aplikace do produkčního prostředí naopak proběhlo bez výrazných problémů a to díky vysoce kvalifikovanému infrastrukturnímu týmu a díky důsledné tvorbě instalačních balíčků jiţ v průběhu testování.
6.1 Vyhodnocení projektu Kaţdý realizovaný softwarový projekt musí ve svém závěru obsahovat vyhodnocení úspěšnosti práce. Toto je důleţité pro analytický tým, jelikoţ takto získává zpětnou vazbu pro 62
svoji další práci. Je zde vidět schopnost správného odhadu detailu analýzy. Dále je vyhodnoceno splnění časových odhadů. Další částí je vyhodnocení nákladů projektu. Zde je třeba jasně ukázat, kterou část projektu se nepodařilo realizovat v plánovaném čase. Toto je nutno nejenom konstatovat, ale také detekovat příčiny problémů a získané zkušenosti pouţít při plánování dalšího projektu. V našem případě byl podhodnocen odhad pracnosti vývoje GUI aplikace a zároveň byly podhodnoceny schopnosti vývojového týmu. Pro příští projekt je třeba buď získat kvalifikovanější vývojáře nebo počítat s rizikem prodlouţení vývojové fáze. Pro analytika plyne poučení pro návrh GUI aplikace, ještě detailněji popsat závislosti jednotlivých funkčních prvků GUI. Toto se ukázalo jako největší zdroj zpoţdění. Jelikoţ testovací a infrastrukturní týmy naopak pracovaly nad očekávání dobře, podařilo se dodrţet poţadované zadání a to jak do rozsahu, tak do kvality a termínu.
63
7 SLOVNÍK POUŢITÝCH POJMŮ -
API application programing interface: aplikační programovací rozhraní
-
CTI computer telephony integration: Integrace hlasového subsystému a výpočetní techniky
-
CTI OS server: komponenta IPCC řídící zpracování hovorů v rámci IP call centra
-
CUIC: Cisco Unified Intelligent Center
-
CUCM: Cisco Unified Communications Manager
-
DB: databáze
-
Design pattern: Návrhový vzor, představuje obecné řešení problému, které se vyuţívá při návrhu programů
-
EA enerprise architekt: nástroj pro modelování informačních systémů
-
End to end: testování napříč více spolupracujícími aplikacemi
-
Facade: návrhový vzor pro aplikace s uţivatelským rozhraním
-
Finanční společnost: společnost CETELEM ČR, a.s.
-
GUI grafical user interface: grafické uţivatelské rozhraní
-
IVR Interactive voice response: Interaktivní hlasové ovládání
-
OOP Object oriented programing: metodika objektového vývoje
-
SOA Service oriented architecture: architektura aplikace orientovaná na sluţby
-
SQL structured query language: standardizovaný dotazovací jazyk pouţívaný pro práci s daty v DB
-
RUP Rational Unified Process: metodika vývoje vyuţívaná společností IBM
-
UAT: uţivatelské akceptační testy
-
UCCE: Unified Contact Center Enterprise
-
UCS Intelligent Contact Manager: plní roli řídícího a monitorovacího prvku kontaktního centra
-
UML unified modeling language: jazyk pro modelování informačních systémů
-
XML extensible markup language: rozšiřitelný značkovací jazyk
64
SEZNAM POUŢITÉ LITERATURY Monografie:
[1]
FOWLER Martin a kol. Patterns of Enterprise Application Architecture. Indiana: Addison Wesley, 2009. ISBN 0-321-12742-0.
[2]
KANISOVÁ, Hana; MULLER, Miroslav. UML srozumitelně. 2.aktualizované vydání. Brno: Computer Press, 2007. ISBN 80-251-1083-4.
[3]
MURRAY, Andy. Managing Succesfull projects with Prince2. 2009. ISBN 978-0-11331059-3
[4]
ŠEDIVÝ, Matěj. Jednotná identifikace klienta v prostředí hlasových služeb. Praha, 2011. Bakalářská práce. BIVŠ.
[5]
PECINOVSKÝ, Rudolf. Návrhové vzory. Computer Press, 2007. ISBN 978-80-2511582-4.
[6]
GAMMA, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John. Design Patterns: Elements of Reusable Object-Oriented Software. AddisonWesley, 1994. ISBN 0-20163361-2.
[7]
ŠEDIVÝ, Matěj. Jaké znáte metody odhadu nákladů na informační systém? Na čem jsou založeny statistické metody odhadu (COCOMO)? Na čem je založena technika odhadu dekompozicí?. Praha, 2011. Semestrální práce. BIVŠ.
Elektronické zdroje: [8]
Cetelem se představuje [online]. 2013 [cit. 2013-03-05]. Dostupné z:
65
SEZNAM OBRÁZKŮ Obr. 1: Hierarchická struktura jazyka UML Obr. 2:Topologie zapojení Obr. 3: Katalog uţivatelských poţadavků Obr. 4: Ukázka include vazby v případu uţití (use case) Obr. 5: Vazba katalogu poţadavků na případy uţití (use case) Obr. 6: Volání telefonního čísla z externího systému Obr. 7 Případy uţití (Use Case) Obr. 8: Analytické schéma uţivatelského rozhraní Obr. 9: Vazba případů uţití a objektů doménového modelu na uţivatelské rozhraní Obr. 10: Doménový model Obr. 11: První fáze (iterace) modelu tříd Obr. 12: Class diagram (model tříd) Obr. 13: Ukázka Class Modelu vzoru Facade Obr. 14: ER diagram Obr. 15: Sekvenční diagram vyhledání klienta Obr. 16: Detailní popis GUI aplikace Obr. 17: Model komponent Obr. 18: Model nasazení aplikace (deployment diagram) Obr. 19: Aktivity diagram
SEZNAM TABULEK Tabulka č. 1: Karnerova metoda odhadu nákladů – rozdělení vah aktorům Tabulka č. 2: Karnerova metoda odhadu nákladů – rozdělení vah případům uţití 66
Tabulka č. 3: Karnerova metoda odhadu nákladů – technický faktor Tabulka č. 4: Karnerova metoda odhadu nákladů – faktor prostředí Tabulka č. 5: Rekapitulace odhadu nákladů na realizaci systému Tabulka č. 6: Diagram časového plánu projektu Tabulka č. 7: Detailní popis prvků GUI Tabulka č. 8: Ukázka scénáře testu komponent Tabulka č. 9: Ukázka scénáře UAT testu Tabulka č. 10: Ukázka scénáře end to end testu
67
