Analyzujte požadavky na CRM systém v prostředí cloud. Systém navrhněte a implementujte. Jako prostředí cloud zvolte platformu Google App Engine. CRM systém bude umožňovat obvyklou funkcionalitu pro tento typ aplikací, to znamená, že systém bude umožňovat: správu firem, osob, obchodních případů, produktů a aktivit. Systém bude také poskytovat různé obchodní reporty, například měsíční a roční obraty firem, hodnocení prodejců, atp. Všechny části projektu budou pečlivě dokumentovány v souladu se zvyklostmi softwarového inženýrství. Systém otestujte na jeho bezchybnou funkci. Součástí práce bude také příručka uživatele a administrátora.

České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství

Diplomová práce

CRM systém v prostředí cloud Bc. Martin Zahradnický

Vedoucí práce: Ing. Martin Molhanec, CSc.

1. ledna 2013

Poděkování Na tomto místě bych chtěl poděkovat lidem, kteří mne po celou dobu studia a v průběhu tvorby této práce podporovali. Poděkování patří především mé rodině a přátelům, dále pak všem účastníkům testování. Velký dík patří také vedoucímu mé diplomové práce panu Ing. Martinu Molhancovi, CSc. za množství užitečných připomínek, informací, cenných rad a vedení práce.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů. V souladu s ust. § 46 odst. 6 tohoto zákona tímto uděluji nevýhradní oprávnění (licenci) k užití této mojí práce, a to včetně všech počítačových programů, jež jsou její součástí či přílohou a veškeré jejich dokumentace (dále souhrnně jen „Dílo“), a to všem osobám, které si přejí Dílo užít. Tyto osoby jsou oprávněny Dílo užít jakýmkoli způsobem, který nesnižuje hodnotu Díla a za jakýmkoli účelem (včetně užití k výdělečným účelům). Toto oprávnění je časově, teritoriálně i množstevně neomezené. Každá osoba, která využije výše uvedenou licenci, se však zavazuje udělit ke každému dílu, které vznikne (byť jen zčásti) na základě Díla, úpravou Díla, spojením Díla s jiným dílem, zařazením Díla do díla souborného či zpracováním Díla (včetně překladu), licenci alespoň ve výše uvedeném rozsahu a zároveň zpřístupnit zdrojový kód takového díla alespoň srovnatelným způsobem a ve srovnatelném rozsahu, jako je zpřístupněn zdrojový kód Díla.

V Praze dne 1. ledna 2013

.....................

České vysoké učení technické v Praze Fakulta informačních technologií c 2013 Martin Zahradnický. Všechna práva vyhrazena.

Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.

Odkaz na tuto práci ZAHRADNICKÝ, Martin. CRM systém v prostředí cloud. Diplomová práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2013.

Abstract The aim of this work is to develop a CRM system on the Google App Engine cloud platform. It acquaints reader to the concept of cloud computing, development platforms and methodologies. Describes the entire development process from introductory study through analysis, design to its implementation, and testing. As a result, there is the functional CRM system and also user’s and administrator’s guides. Keywords Cloud computing, Software as a Service, Customer relationship management, Google App Engine, Java EE, UWE.

Abstrakt Tato práce si klade za cíl vyvinout CRM systém v cloudovém prostředí na platformě Google App Engine. Seznamuje čtenáře s konceptem cloud computingu, použitými vývojovými platformami a metodikami. Popisuje celý proces vývoje od provedení úvodní studie, přes analýzu, návrh až po jeho realizaci a testování. Výsledkem práce je funkční CRM systém, uživatelská příručka a příručka administrátora. Klíčová slova Cloud computing, software jako služba, řízení vztahů se zákazníky, Google App Engine, Java EE, UWE.

ix

Obsah Úvod Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Struktura práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Použité technologie a koncepty 1.1 Cloud computing . . . . . . . . 1.2 CRM systém . . . . . . . . . . 1.3 Java EE . . . . . . . . . . . . . 1.4 Google App Engine . . . . . . . 1.5 Metodika UWE . . . . . . . . . 2 Úvodní studie 2.1 Deklarace záměru . . . . . 2.2 Rešerše existujících řešení 2.3 Katalog požadavků . . . . 2.4 Návrh architektury řešení 2.5 Analýza rizik . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

1 1 3 4

. . . . .

5 5 11 12 13 15

. . . . .

17 17 19 25 31 31

3 Analýza 37 3.1 Konceptuální datový model . . . . . . . . . . . . . . . . . . . . 37 3.2 Model případů užití . . . . . . . . . . . . . . . . . . . . . . . . 46 4 Návrh 67 4.1 Návrh uživatelského rozhraní . . . . . . . . . . . . . . . . . . . 67 4.2 Výběr implementačního prostředí . . . . . . . . . . . . . . . . . 73 4.3 Architektura systému . . . . . . . . . . . . . . . . . . . . . . . 74 5 Realizace 5.1 Integrační vrstva . 5.2 Datová vrstva . . . 5.3 Prezentační vrstva 5.4 Aplikační logika . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . xi

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

77 77 80 84 87

6 Testování 91 6.1 White-box testování . . . . . . . . . . . . . . . . . . . . . . . . 91 6.2 Black-box testování . . . . . . . . . . . . . . . . . . . . . . . . . 92 6.3 Testování použitelnosti . . . . . . . . . . . . . . . . . . . . . . . 92 Závěr 97 Zhodnocení dosažených cílů . . . . . . . . . . . . . . . . . . . . . . . 97 Zhodnocení použitých technologií . . . . . . . . . . . . . . . . . . . . 98 Popis další práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Literatura

101

A Seznam použitých zkratek

107

B Obrázky a modely

111

C Uživatelská příručka C.1 První pohled na aplikaci C.2 Hlavní menu . . . . . . C.3 Top-bar menu . . . . . . C.4 Obsah stránek . . . . . C.5 Dialogová okna . . . . . C.6 Zadávání vstupu . . . . C.7 Notifikace systému . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

117 117 117 119 119 120 121 122

D Příručka administrátora 123 D.1 Lokální testování . . . . . . . . . . . . . . . . . . . . . . . . . . 123 D.2 Nasazení CRM systému na GAE . . . . . . . . . . . . . . . . . 124 D.3 Správa aplikace v administrační konzoli . . . . . . . . . . . . . 124 E Obsah přiloženého CD

127

xii

Seznam obrázků 0.1

Hype cycle pro cloud computing, 2012 (zdroj: Gartner [44]) . . . .

1.1 1.2 1.3

Cloud computing - úrovně abstrakce (zdroj: Strategi Co. [45]) . . . 8 Srovnání architektur pro CRM aplikaci (zdroj: Strategi Co. [45]) . 8 Využití hardwarových prostředků: Tradiční model dodávky infrastruktury (zdroj: Vitvar [47]) . . . . . . . . . . . . . . . . . . . . . . . . 10 Využití hardwarových prostředků: Cloudové řešení dodávky infrastruktury (zdroj: Vitvar [47]) . . . . . . . . . . . . . . . . . . . . 10

1.4

2

2.1 2.2 2.3 2.4

Rozhraní CRM systému . . . . . . . . . . . . . . . . Salesforce.com (zdroj: Salesforce.com [41]) . . . . . . Raynet Cloud CRM (zdroj: Raynet [36]) . . . . . . . INEX online CRM systém (zdroj: MAXprojekt [28])

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

18 19 20 21

3.1 3.2 3.3 3.4 3.5 3.6 3.7

Konceptuální datový model . . . . . . . . . . UC model - Aktéři systému . . . . . . . . . . UC model - UC1: CRM Common . . . . . . . UC model - UC2: Web presentation . . . . . UC model - UC3: Front office . . . . . . . . . UC model - UC4: CRM Business Operations UC model - UC6: CRM Reminder . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

38 46 48 52 55 60 65

4.1 4.2 4.3 4.4 4.5 4.6

Návrh navigace v UWE . . . . . . . . . . . . Návrh prezentace v UWE . . . . . . . . . . . Mockup prototyp - Úprava účtu . . . . . . . Logická architektura systému . . . . . . . . . Fyzická architektura systému . . . . . . . . . Distribuce zátěže systému na platformě GAE

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

69 69 70 74 75 76

5.1 5.2

Diagram tříd – datová vrstva . . . . . . . . . . . . . . . . . . . . . Architektura JSF (zdroj: Goncalves [15]) . . . . . . . . . . . . . . .

82 84

B.1 Salesforce.com - Editace příležitosti (zdroj: Salesforce.com [41]) . . 113 B.2 Raynet Cloud CRM - Editace obchodního případu (zdroj: Raynet [36]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 xiii

B.3 B.4 B.5 B.6 B.7 B.8

Mockup Mockup Mockup Mockup Mockup Mockup

C.1 C.2 C.3 C.4 C.5 C.6 C.7 C.8 C.9 C.10 C.11

UI UI UI UI UI UI UI UI UI UI UI

-

prototyp prototyp prototyp prototyp prototyp prototyp

-

Seznam účtů . . . . . . Filtrování seznamu účtů Smazání účtu . . . . . . Detail účtu . . . . . . . Úprava účtu . . . . . . Záložka komunikace . .

Hlavní menu . . . . . . . . . Seznam firem . . . . . . . . Top-bar menu . . . . . . . . Akční tlačítka . . . . . . . . Seznamy . . . . . . . . . . . Dialog smazání firmy . . . . Dialog přidání firmy . . . . Maska vstupního pole . . . Výběr položky s filtrováním Hodnocení . . . . . . . . . . Systémová notifikace . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

114 114 115 115 116 116

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

117 118 119 119 120 120 121 121 122 122 122

D.1 Administrační konzole GAE . . . . . . . . . . . . . . . . . . . . . . 125

xiv

Seznam tabulek 2.1 2.2 2.3 2.4 2.5 2.6

Srovnaní CRM systémů - Standardní funkce . . . Srovnaní CRM systémů - Nadstandardní funkce . Srovnaní CRM systémů - Uživatelské rozhraní . . Srovnaní CRM systémů - Platební modely . . . . Srovnaní CRM systémů - Hodnocení . . . . . . . Vyhodnocení analýzy rizik . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

21 22 23 24 25 36

B.1 Šablona případu užití . . . . . . . . . . . . . . . . . . . . . . . . . 111 B.2 UWE profil 1.9 - Výčet použitých stereotypů (zdroj: Kroiss [24]) . 112

xv

Úvod Motivace V oblasti dodávky ICT1 služeb byl dlouhodobým lídrem tradiční model, kde je software poskytován pod určitou licencí. Poskytovatel vytvoří software a následně ho instaluje na ICT infrastrukturu konkrétního zákazníka. V poslední době se do čela dostává nový způsob dodávky ICT služeb založený na konceptu cloud computingu. Specializovaný poskytovatel provozuje na své vysoce škálovatelné, cloudové infrastruktuře služby (software, úložiště, infrastrukturu), které poskytuje velkému počtu zákazníků prostřednictvím internetu. Službu tak může snadno a rychle zprovoznit a využívat mnohem více uživatelů než u tradičního modelu. Cloud computing je v současnosti jedním z nejsledovanějších a nejvíce diskutovaných témat v oblasti ICT, zahrnuje širokou škálu aspektů a stále se objevují nové. Je zde několik trendů a odhadů do budoucna. Hovoří se dokonce o nahrazení osobního počítače osobním cloudem. Což se již ve velké míře projevuje na používanosti aplikací poskytovaných jako SaaS2 . Příkladem jsou Google Documents, které nahrazují klasickou kancelářskou sadu nástrojů a umožňují editaci a sdílení těchto dokumentů na cloudu. Dokumenty tak nejsou uloženy v osobním počítači a jsou vždy a všem dostupné. A nejenom tyto dokumenty, ale i všechna ostatní data můžeme snadno ukládat a sdílet na cloudu. Například pomocí synchronizovaného datového úložiště (DropBox, Google Drive aj.), které ukládá data uživatelů na cloud. Ty mohou být přístupné klienty na několika různých platformách a operačních systémech (Android, iOS atd.). Společnost Garner [44] dokonce předpovídá, že osobní cloud nahradí osobní počítač jako centrum digitálního života uživatelů již v roce 2014. V privátním sektoru je jedním z předních poskytovatelů SaaS společnost Salesforce.com, která vyvíjí CRM3 systém. Jejich systém používá tisíce společností z celého světa. Data a informace můžeme mít díky cloud computingu k dispozici na různých přístrojích a kdykoli potřebujeme, což tento koncept řadí na přední příčky 1

Information and Communication Technologies Software as a service 3 Customer Relationship Management 2

1

Úvod zájmu společností, veřejnosti i expertů z oblasti vývoje software. O značné popularitě a obsáhlosti cloud computingu hovoří také skutečnost, že přední analytická společnost Gartner vytváří od roku 2010 pro cloud computing samostatnou hype cycle4 křivku. Tyto křivky znázorňují vyspělost předních technologií z různých oblastí. Cloud computing obsahuje tolik různých aspektů, že má křivku vlastní viz obrázek 0.1.

Obrázek 0.1: Hype cycle pro cloud computing, 2012 (zdroj: Gartner [44]) Pozice SaaS na této křivce značí, že se pohybuje ve stavu vyzrálosti. Společnosti tedy už ví jak mohou SaaS pro svůj byznys využívat a v rozhodování o jeho zavedení již nejsou tak konzervativní. Gartner [44] informuje o tom, že SaaS je v podnicích velmi rychle přijímán a osvojován. Na základě toho dále předpovídá, že více než 50% společností bude mít ve svých strategiích v roce 2015 v nějaké formě zahrnuty aplikace založené na SaaS. Cloudová infrastruktura zajišťuje škálovatelnost výpočetních zdrojů. Aplikace na cloudové infrastruktuře se chovají elasticky - pružně reagují na změnu požadavků (poptávku po službách). Hardwarové prostředky jsou optimálně využity. Což je pro určité typy systémů žádoucí. Platebním modelem u cloudových řešení je většinou pay-per-use nebo pay-as-you-go, kde se platí za skutečně využité zdroje (počet uživatelů, výkon, objem uložených dat). Odpadají 4

Hype cycle křivky slouží, dle definice společnosti Gartner [13], jako grafické znázornění vyspělosti a stupně přijetí nových technologií a aplikací. Určují relevantnost jejich nasazení při řešení skutečných byznys problémů a pohled na to, jak se budou v čase vyvíjet. Technologie se může nacházet na křivce v pěti fázích. Po počátečním uvedení prochází fází rozšíření, velkými očekáváními, selháním až po uzrávání a konečnou produktivitu (přechod do mainstreamu).

2

Cíl práce tak nákladné počáteční investice společností do vlastní ICT infrastruktury. A i menší společnosti mohou používat stejně kvalitní, moderní technologie a aplikace jako jejich vetší konkurenti. Model SaaS má do budoucna velmi dobré vyhlídky. Pro mnoho společností může být správnou cestou. Je natolik vyzrálý, že je přijímán a začíná se běžně používat. Je na místě, aby vývojáři software tuto technologii uvážili při modernizaci nebo vývoji nových aplikací a pokusili se jít touto cestou, je-li to účelné.

Cíl práce Předmětem práce je vývoj CRM systému, který bude použitelný pro široké spektrum zákazníků. Systémy CRM slouží pro správu informací, aktivit a interakcí se zákazníkem. Více viz kapitola 1.2 CRM systémy. Systém bude vyvíjen jako TASW5 (typově aplikační software viz Voříšek [48]). Tedy jako obecný CRM systém určený pro použití několika různými společnostmi a uživateli, který je vytvořen na základě generalizace požadavků pro tento typ aplikací. Pro aplikace tohoto charakteru je účelné zvolit model SaaS a vyvinout systém jako webovou aplikaci. Chceme-li systém vyvíjet jako SaaS, musíme pro něj zajistit škálovatelnost výpočetních zdrojů. Nevíme kolik uživatelů bude aplikaci skutečně využívat. Počet uživatelů se může rychle měnit - prudce narůstat i klesat. Potřebnou elasticitu výpočetních zdrojů nám zajistí cloudová infrastruktura. Existují tři základní varianty jejího použití v daném kontextu - nasazení aplikace na existující cloudovou infrastrukturu IaaS6 nebo PaaS7 , anebo vytvoření vlastní cloudové infrastruktury pomocí vlastních zdrojů. Pro vyvíjený CRM systém byla zvolena varianta nasazení na PaaS. Problematika cloud computingu je detailněji popsána v kapitole 1.1 Cloud computing. Cílem práce je analýza, návrh, implementace, testování a nasazení CRM systému, který bude poskytován jako SaaS a bude vyvinut na platformě GAE8 (PaaS) v jazyku Java. Funkcionalita CRM bude obvyklá pro tento typ aplikací. Systém bude umožňovat správu firem, osob, obchodních případů, produktů a aktivit a nad těmito daty bude vytvářet obchodní reporty (analýzy prodeje obchodníků apod.). Požadavky budou upřesněny na základě rešerše existujících řešení. Součástí práce bude rovněž vytvoření uživatelské příručky a příručky pro administrátora systému. 5

Typový aplikační software Infrastructure as a service 7 Platform as a service 8 Google App Engine 6

3

Úvod

Struktura práce Práce je rozdělena do těchto částí: Teoretický úvod Popis konceptů cloud computingu, definice CRM systému, popis platformy Java EE9 a GAE v kapitole 1 Použité technologie a koncepty. Analytická část Zahrnuje úvodní studii práce (kapitola 2), kde je popsán záměr a funkcionalita systému, provedena rešerše existujících řešení a analýza rizik. Dále obsahuje kapitolu 3 Analýza s konceptuálním datovým modelem a modelem případů užití. Poslední částí je návrh (kapitola 4), ve kterém je popsán návrh uživatelského rozhraní, architektury systému a výběr implementačního prostředí. Praktická část Realizace (kapitola 5) a testování systému (kapitola 6) obsahují popis důležitých částí implementace, jednotlivých vrstev aplikace, použitých technologií, tvorbu funkčních testů a testování použitelnosti. Závěr Hodnotí dosažené výsledky a použité technologie. Rozebírá možnosti dalšího rozšíření systému a určuje kroky dalšího vývoje.

9

4

Java Enterprise Edition

Kapitola

Použité technologie a koncepty 1.1

Cloud computing

Jak bylo již zmíněno, systém CRM je vyvíjen jako SaaS na platformě GAE, která poskytuje služby PaaS. Následující část je věnována definici pojmů z oblasti cloud computingu, aby byl zřejmý koncept řešení vyvíjeného systému. Cloud computing přišel také s novým platebním modelem, který je v závěru kapitoly popsán. Pro služby cloud computingu neexistuje zcela jednotná taxonomie, ani není jednotný názor na to, jaké musejí být vlastnosti ICT služby, abychom ji mohly zařadit mezi služby “cloudu” viz Bruckner [5]. Jednou z uznávaných definicí cloud computingu je definice NIST10 [29]. Podle ní je cloud computing model, který umožňuje všudypřítomný, pohodlný, on-demand přístup přes síť ke sdíleným konfigurovatelným výpočetním zdrojům (např. sítím, serverům, datovým úložištím, aplikacím a službám), které mohou být rychle poskytnuty a nasazeny s minimálním úsilím na jejich správu nebo interakci s poskytovatelem služeb. Cloud computing podle ní musí splňovat pět základních charakteristik, musí být poskytnuta jedním ze tří modelů služeb a jedním ze čtyř modelů nasazení.

1.1.1

Základní charakteristiky

On-demand self-service (Samoobslužnost na vyžádání) • uživatelé přistupují a využívají výpočetní prostředky (čas serveru, síťové úložiště atd.) dle jejich okamžité potřeby • přístup je automatický (bez nutnosti interakce s poskytovatelem)

Broad network access (Síťový přístup) • prostředky dostupné přes síť standardními mechanizmy, které podporují použití různých klientů (např. mobilní telefony, tablety, notebooky, pracovní stanice) 10

National Institute of Standards and Technology U.S. Department of Commerce

5

1

1. Použité technologie a koncepty Resource pooling (Pooling zdrojů) • výpočetní prostředky jsou seskupeny tak, aby je bylo možno na základě okamžité poptávky dynamicky přidělit několika zákazníkům (multi-tenant model) • konzument může někdy volit lokaci prostředků na úrovni zemí, států, datových center (např. Amazon EC2)

Rapid elasticity (Rychlá elasticita) • flexibilní, rychlá, automatická dostupnost zdrojů dle okamžité poptávky • pro konzumenta se jeví prostředky jako neomezené (kdykoli, v jakémkoli množství osvojitelné)

Measured service (Měřitelná služba) • cloudové systémy automaticky řídí přidělování zdrojů na základě jejich monitorování a měření • využité zdroje jsou reportovány tak, aby byly transparentní pro obě strany

1.1.2

Modely nasazení

Private cloud (Soukromý cloud) • cloudová infrastruktura je poskytnuta pro exkluzivní použití jedné organizace • spravována je samotnou organizací nebo třetí stranou • může být provozován interně i externě

Public cloud (Veřejný cloud) • cloudová infrastruktura je poskytnuta pro volné užití široké veřejnosti • spravována podnikovou, vládní nebo akademickou organizací • provozována v prostorách poskytovatele cloudu

Community cloud (Komunitní cloud) • cloudová infrastruktura je poskytnuta pro exkluzivní použití specifické komunitě tvořené několika organizacemi • spravována je jednou nebo více organizacemi z komunity nebo třetí stranou • může být provozován interně i externě

Hybrid cloud (Hybridní cloud) • cloudová infrastruktura je kompozicí dvou a více jiných infrastruktur

6

1.1. Cloud computing

1.1.3

Modely služeb

IaaS (Infrastructure as a Service) • poskytovatel dodává zákazníkům jako službu zpracování, úložiště, síť a další výpočetní zdroje, na kterých má možnost nasadit a spustit libovolný software (operační systém, aplikaci) • zákazník nemůže nijak spravovat a ovládat cloudovou infrastrukturu ležící na nižší vrstvě • tuto službu využijí IT architekti a vývojáři software • příklady poskytovatelů: Amazon EC2, GoGrid

PaaS (Platform as a Service) • poskytovatel dodává zákazníkům jako službu aplikační platformu (programovací jazyky, knihovny, služby, nástroje), na které zákazník může vyvinout a nasadit svoji vlastní aplikaci • zákazník nemůže nijak spravovat ani ovládat cloudovou infrastrukturu ležící na nižší vrstvě (sítě, servery, operační systém, úložiště), má ale kontrolu nad nasazenými aplikacemi a konfigurací prostředí aplikačního hostingu • tuto službu využijí vývojáři software • příklady poskytovatelů: Google App Engine, Microsoft Azure

SaaS (Software as a Service) • aplikace jsou přístupné z různých klientských zařízení jak přes rozhraní tenkého klienta jako je webový prohlížeč, tak přes programové rozhraní • zákazník nemůže nijak spravovat ani ovládat cloudovou infrastrukturu ležící a nižší vrstvě (sítě, servery, operační systém, úložiště, aplikační platformu), aplikace může jen customizovat a omezeně spravovat • službu využijí koncoví uživatelé (společnosti, lidé) • příklady poskytovatelů: Salesforce.com, Google Documents

Pro lepší pochopení modelů služeb a jejich správné oddělení popíšeme dva obrázky společnosti Strategi Consulting, které zachycují modely služeb napříč jednotlivými úrovněmi architektonické abstrakce. Na obrázku 1.1 jsou zobrazeny dvě základní vrstvy, v rámci kterých jsou poskytovány sdílené výpočetní zdroje cloudu – infrastrukturní (Infrastructure Layer) a softwarová vrstva (Software Layer), která se dá rozdělit vrstvu aplikační (Application Layer) a vrstvu aplikační platformy (Application Platform Layer). Infrastrukturní vrstva poskytuje zákazníkovi výpočetní výkon, úložiště, rozdělování zátěže mezi virtuální stroje pomocí load balanceru atd. Vrstva aplikační platformy poskytuje zákazníkovi služby, API11 , middleware a nástroje, které zákazník použije na vývoj svých systémů, přičemž o infrastrukturu, která leží pod ní, se vůbec nemusí starat. 11

Application Programming Interface

7

1. Použité technologie a koncepty

Obrázek 1.1: Cloud computing - úrovně abstrakce (zdroj: Strategi Co. [45])

Na aplikační vrstvě je zákazníkovi poskytnut konkrétní systém, který používá pomocí klienta (webového prohlížeče, mobilní aplikace atd.). O infrastrukturu a aplikační platformu se zákazník nijak nestará.

Obrázek 1.2: Srovnání architektur pro CRM aplikaci (zdroj: Strategi Co. [45]) Obrázek 1.2 ilustruje rozdělení architektonických vrstev a porovnává modely služeb cloud computingu s klasickým řešením bez cloudu na konkrétním příkladu, kterým je architektura CRM aplikace. Využijeme-li tradiční model dodávky (viz sloupec „No Abstraction“), pak máme ve své vlastní režii výběr technologií pro vývoj CRM aplikace na všech 8

1.1. Cloud computing vrstvách řešení (viz sloupec „Layer“) – od hardwarové infrastruktury (servery a jejich parametry), přes operační systém, aplikační platformu (DBMS12 , aplikační server atd.), implementaci kódu aplikace (výběr programovacího jazyka, knihoven, frameworků, technologií), až po samotný produkt (funkcionalita, design, platforma). Použijeme-li model IaaS odpadají starosti s vrstvou hardware. U modelu PaaS neovlivníme výběr operačního systému a technologií na aplikační platformě (především DBMS, aplikační server), máme rovněž omezené možnosti výběru programovacího jazyka, technologií a frameworků. U modelu SaaS nezasahujeme ani do infrastruktury, ani vývoje aplikací. Je nám poskytnuta konkrétní aplikace, kterou můžeme jen omezeně spravovat a případně customizovat, jsou-li k tomu dostupné prostředky.

1.1.4

Platební model pro služby cloud computingu

Platebním modelem pro cloudové řešení bývá zpravidla pay-per-use resp. payas-you-go. Zákazník platí za skutečně využité zdroje (výpočetní výkon, úložiště, použité služby, počet uživatelů). Jeden s poskytovatelů IaaS GoGrid [14] uvádí, že se platí za konzumaci těchto služeb: objem datového přenosu za měsíc, výpočetní výkon za hodinu (počet instancí za hodinu), užití RAM13 za hodinu a využitou kapacitu úložiště za měsíc. Platební model PaaS je podobný předešlému. Ceník GAE [16] uvádí, že pro každou aplikaci jsou nastaveny kvóty na denní využití zdrojů a služeb. Pokud běh aplikace nepřesáhne dané kvóty, je v provozu zdarma. Pokud ale některou kvótu přesáhne, začíná se platit. Platí se za výpočetní výkon za hodinu (počet instancí za hodinu), velikost úložiště za měsíc, za 1 GB odchozího datového přenosu, počet operací nad databází a za použití různých API (např. počet odeslaných emailů nad denní kvótu 100). Platby se ovšem liší dle poskytovatelů PaaS. U modelu SaaS se ve většině případů platí za jednoho uživatele za měsíc. Poskytovatel může mít víc cenových kategorií, které se liší v závislosti na rozšiřujících službách nebo jejich kvalitě. Takový model má například poskytovatel CRM Salesforce.com [39]. Tyto platební modely osvobozují zákazníky od velkých fixních nákladů, starostí s plánováním nákupu a údržby hardware a transformují je do menších variabilních nákladů. U tradičního modelu dodávky ICT jsou investice do hardwarových zdrojů skokového charakteru, viz obrázek 1.3. Už prvotní investice je vysoká. Dále předpokládáme určitý vývoj poptávky po hardwarových zdrojích a v naplánovaných intervalech investujeme do jejich rozšíření. U tohoto modelu mohou nastat dvě extrémní situace. U první, která nastává vždy, nejsou zdroje plně 12 13

Database Management System Random Access Memory

9

1. Použité technologie a koncepty využity (nízká poptávka, velká kapacita). Druhá situace je kritická. Nastane, překročí-li poptávka možnosti našich zdrojů (vyšší poptávka, nedostatečná kapacita). Aplikace pak není výkonná, uživatelé nejsou spokojeni a můžeme přijít o zákazníky.

Obrázek 1.3: Využití hardwarových prostředků: Tradiční model dodávky infrastruktury (zdroj: Vitvar [47]) U cloudového řešení dodávky odpadá zatížení způsobené velkou prvotní investicí do vybudování ICT infrastruktury, viz obrázek 1.4. Od začátku používání platíme jen za to, co skutečně spotřebujeme (pay-as-you-go). Nemůže nastat kritická situace. Infrastruktura roste flexibilně spolu s poptávkou po našich službách. Zde vidíme hlavní výhody cloudového řešení.

Obrázek 1.4: Využití hardwarových prostředků: Cloudové řešení dodávky infrastruktury (zdroj: Vitvar [47]) 10

1.2. CRM systém

1.2

CRM systém

Dohnal [11] říká, že CRM (řízení vztahů se zákazníky) zahrnuje pracovníky, podnikové procesy a technologii IS/ICT14 s cílem maximalizovat loajalitu zákazníků, a v důsledku toho i ziskovost podniku. Je součástí podnikové strategie a jako takové se stává součástí podnikové kultury. Technologicky stále více využívá potenciálu a možností internetu. Řízení vztahů se zákazníky je podle něj postaveno na čtyřech základních pilířích viz Chlebovský [7]: • Lidé: aktivní účast zaměstnanců • Procesy: CRM sjednocuje procesy marketingu, prodeje a služeb, optimalizované procesy CRM zefektivňují • Technologie: nástroje umožňující uplatnění moderního řízení vztahů se zákazníky i při velkém počtu oslovovaných klientů • Data: sběr dat, možnosti jejich uchování, vyhledávání, třídění a analýz jejich závislostí vede k plnohodnotnému CRM

Pojem „CRM systém“ definuje Hommerová [19] jako soubor hardwarových a softwarových technologií a nástrojů podporujících celkovou strategii podniku, vedoucí k poznávání zákazníků, posílení jejich loajality, zvýšení zájmů o další produkty a služby podniku. Systém používá ke sběru dat různé informační zdroje (vnitropodnikové i vnější), které poskytují informace o zákaznících, produktech, službách, marketingové informace o kampaních, jejich výsledcích, stejně jako informace získané v rámci komunikace se zákazníkem. Úkolem je i předání těchto informací kompetentním pracovníkům. Cílem CRM je vytvoření vztahu mezi firmou a zákazníkem, který je prospěšný pro obě strany. Řízení vztahů se zákazníky je obchodní strategií, ve které hrají informační technologie podpůrnou roli. Často ale bývá chápáno mylně – jako softwarový prostředek nebo podniková filozofie. Dle průzkumů Hommerové [19] převažuje přístup jako k podnikové filosofii založené na komunikaci se zákazníkem a na obecném marketingovém přístupu. Ve skutečnosti se jedná o spojení obou. Výzkum [3] týkající se řízení vztahů se zákazníky uvádí hlavní nevýhody zavedení CRM v podniku. Jsou jimi finanční, časová a personální náročnost (vysoká cena, zaškolení personálu apod.) a nárůst administrativní činnosti. Dopady těchto nevýhod může zmírnit volba vhodného CRM systému. Zvolíme-li systém, který poskytován jako SaaS s platebním modelem payas-you-go, pak odpadají vysoké pořizovací a časové náklady (investice do ICT infrastruktury a vývoje systému). Personální náročnost můžeme, z hlediska zaškolování, ovlivnit pouze vývojem kvalitního uživatelského rozhraní a provedením testováním použitelnosti. Výsledkem by pak měla být CRM aplikace, kterou budou uživatelé rádi používat. 14

Information Systems / Information and Communication Tech.

11

1. Použité technologie a koncepty Přesně takový systém, který by vyhovoval širokému spektru zákazníků, respektuje moderní trendy a potlačuje hlavní nevýhody zavedení CRM, bude na snaze vyvinout.

1.3

Java EE

Pro implementaci systému byla zvolena platforma Java EE, která je tvořena souhrnem specifikací (JSR15 ) a technologií postavených nad základní verzí Java SE16 . Umožňuje vývoj distribuovaných, robustních, výkonných, škálovatelných a vysoce přístupných webových a podnikových aplikací. Platforma Java EE poskytuje otevřené standardy, které jsou implementovány několika komerčními (Websphere, WebLogic) i open source (GlassFish, JBoss, Hibernate atd.) frameworky, jež zabezpečují transakční zpracování, držení stavu komponent, persistenci objektů, bezpečnost a tak dále viz Goncalves [15]. Jednotlivé specifikace jsou implementovány různými kontejnery (běhovými prostředími pro Java EE), které hostujícím komponentám poskytují své služby – správu životního cyklu, dependency injection, aj. Modelem Java EE aplikací je distribuovaný vícevrstvý model viz Jendrock [21]. Aplikační logika je rozdělena na několik komponent, které jsou nasazeny na různých zařízeních (strojích) v závislosti na jejich funkci a vrstvě vícevrstvého Java EE prostředí, na kterou komponenta patří. Aplikace jsou většinou považovány za třívrstvé resp. čtyřvrstvé, protože jsou distribuovány na tři místa: klientské zařízení (klientská vrstva), Java EE server (webová a business vrstva) a databázový server (EIS17 vrstva). Klientskou vrstvu tvoří aplikace, pomocí kterých klient komunikuje s Java EE aplikací. Klient odesílá požadavky na Java EE server, na kterém je aplikace nasazen. Server sestaví a odešle odpověď. Klientem může být buď aplikační klient (aplikace na zařízení klienta) nebo webový klient (tenký klient). Webový klient se skládá ze dvou částí. Dynamicky generované stránky (HTML18 , XML19 ) komponentami běžícími na webové vrstvě aplikace a webový prohlížeč na straně klienta, který stránky renderuje. Webovou vrstvu tvoří komponenty, které obsluhují požadavky a komunikují s nižšími vrstvami (business a databázovou vrstvou). Vrstva zajišťuje generování webových stránek ve formátu HTML, XML aj., obsluhu session klientů, navigaci mezi stránkami, držení stavu a vykonává i logiku. Standardem Java EE je pro tuto vrstvu JSF20 framework, pomocí něhož je rozdělen vývoj webové části aplikace na UI21 (tagy v HTML stránkách) a aplikační logiku 15

Java Specification Request Java Standard Edition 17 Enterprise Information System 18 HyperText Markup Language 19 Extensible Markup Language 20 JavaServer Faces 21 User Interface 16

12

1.4. Google App Engine (Java bean komponenty). Dalším standardem je framework Facelets, který je součástí JSF od verze 2.0. Slouží k tvorbě šablon stránek. Existuje celá řada dalších frameworků pro vývoj webové vrstvy, které nejsou součástí Java EE specifikace. Business vrstva slouží k implementaci aplikační logiky. Standardy této vrstvy jsou Java Persistence Entities (třídy definující datové entity) a EJB22 beany (aplikační logika). Vrstva komunikuje s jinými systémy pomocí webových služeb (standardy JAX-WS23 a JAX-RS24 ) a s databázemi. Vrstvu EIS tvoří okolní systémy, ze kterých aplikace čerpá data. Může se jednat o databázové systémy nebo jiné systémy (ERP25 apod.), které slouží jako datový zdroj pro aplikaci.

1.4

Google App Engine

Platforma GAE poskytuje PaaS služby pro vývojáře software. Použitím GAE odpadají starosti s infrastrukturou systému. Nemusíme se starat o hardware, síť, úložiště, škálovatelnost atd. Pro vývoj aplikací slouží speciální SDK26 , ze kterého je možno aplikaci přímo nahrát na GAE a nasadit ji tak do testovacího nebo ostrého online provozu. Na platformě existují běhová prostředí pro tři programovací jazyky: Java, Python a Go. Aplikace je možno nasadit i bezplatně. Platební model je standardní pro služby cloud computingu – pay-as-you-go – platí se za spotřebované služby, které překročí bezplatné kvóty. Nasazené aplikace se dají spravovat v administrační konzoli, jejíž součástí je zobrazení reportů, kvót, log souborů, správa verzí, úložiště, nastavení plateb, přístupových práv pro vývojáře atd.

1.4.1

Aplikační prostředí

Mezi vlastnosti a funkce platformy GAE [17] patří provoz dynamických webových aplikací, podpora standardních webových technologií, perzistentní úložiště (spouštění dotazů, řazení dat a podpora transakcí), automatická škálovatelnost, load balancing, API pro autentizaci uživatelů a posílání emailů pomocí Google Accounts, vývojové prostření podporující všechny funkce GAE umožňující jeho lokální simulaci, fronta pro spouštění asynchronních úkolů, spouštění naplánovaných úloh (cron jobs) v určených časových intervalech. Existují tři způsoby pro persistenci dat. Prvním je App Engine Datastore, který poskytuje NoSQL objektovou databázi bez schématu s dotazovacím strojem a atomickými transakcemi. Další možností je Google Cloud SQL, která 22

Enterprise Java Beans Java API for XML Web Services 24 Java API for RESTful Web Services 25 Enterprise Resource Planning 26 Software Development Kit 23

13

1. Použité technologie a koncepty poskytuje klasickou relační SQL databázi založenou na MySQL RDBMS27 . Poslední je Google Cloud Storage, který poskytuje služby (REST28 API) pro uložení objektů a souborů do velikosti terabajtů. Poslední dvě jsou placené. App Engine podporuje integraci s Google Accounts (Users API). Aplikace umožňuje přihlášení uživatele pomocí Google účtu, zobrazení jeho jména a emailu. Má-li uživatel založen takový účet, nemusí si vytvářet speciální účet pro přihlášení do aplikace. Další služby a API, které platforma zahrnuje jsou URL Fetch (přístup aplikací k externím zdrojům v síti internet), Mail API (odesílání emailů z aplikace), Image Manipulation (změna velikosti obrázků, rotace,. . . ), Memcache API (k aplikaci je asociována key-value cache paměť, která je dostupná všemi instancemi aplikace). Škálovatelnost aplikací je na App Engine zajištěna tzv. „load balancerem“. Ten přiděluje, dle aktuálního zatížení, klientům instance aplikace, které je mají obsluhovat (přidává nové instance nebo ubírá a určuje, kterého klienta obslouží jaká instance). Každá nová instance aplikace je vytvořena na novém virtuálním stroji JVM29 . Proces vytváření nových instancí je časově velmi náročný. Inicializace aplikace při prvním požadavku nebo při vytvoření nové instance se nazývá „loading request“. Vysoká časová náročnost se dá zmírnit použitím lazy inicializace (při požadavku se načítá pouze nutná část zobrazených dat), sdílením dat náročných na výpočet mezi jednotlivými instancemi v Memcache (kde jsou rychle načtena při startu jiné JVM) nebo použitím lightweight knihoven a konfigurací.

1.4.2

Vývoj v jazyku Java

Pro vývoj v jazyku Java lze použít obvyklé vývojové nástroje a API. Prostředí App Engine [17] poskytuje Java 6 JVM, rozhraní Java Servlet, rozhraní pro přístup k úložišti Datastore a další služby jako JDO30 , JPA31 , JavaMail či JCache. Pro vývojové prostředí Eclipse IDE32 existuje zásuvný modul, který přidává podporu pro vývoj aplikací na GAE v Javě. Plugin zahrnuje kompletní App Engine SDK, které umožňuje lokální testování i nasazení aplikací na platformu GAE. Jsou dostupné i pluginy pro vývoj v ostatních IDE. Platforma GAE používá pro webové aplikace standard Java Servlet. Obsluha požadavků klienta aplikace probíhá na základě zpracování servletů, JSP33 stránek a deskriptoru nasazení (web.xml). 27

Relational Database Management System Representational State Transfer 29 Java Virtual Machine 30 Java Data Objects 31 Java Persistence API 32 Integrated Development Environment 33 JavaServer Pages 28

14

1.5. Metodika UWE 1.4.2.1

Nepodporované standardy

Existuje několik omezení a pro vývoj v Javě na platformě GAE [17]. Běhové prostředí obsahuje určité restrikce, které jsou implementovány přímo v JVM. Aplikace může použít jakýkoli bytecode pro JVM nebo knihovnu, neporušujeli některou z restrikcí (např. bytecode, který se pokusí otevřít socket pro zápis do souboru způsobí výjimku). App Engine nepodporuje veškeré komponenty Java EE specifikace, jen některé z nich: JDO, JPA, JSF, JSP, Java Servlet API, JAXB34 , JAX-WS, JavaMail, API pro zpracování XML – DOM35 a SAX36 . I u těchto komponent však existují různá omezení nebo jejich zprovoznění vyžaduje dočasné obejití v kódu. Nejsou podporovány tyto důležité části Java EE: EJB, JDBC37 , JMS38 , JNDI39 a další. Ze známých webových frameworků a knihoven nejsou podporovány: – Hibernate, Tapestry 5.1, ICEFaces Polo-podporovanými, které vyžadují dočasné obejití v kódu, jsou: – Wicket, RichFaces, PrimeFaces, JBoss Seam, Guice, Grails, Spring Security Podporovanými jsou: – Spring MVC, Struts, MyFaces, Facelets, Google Web Toolkit

1.5

Metodika UWE

Metodika UWE40 poskytuje sadu elementů specifických pro webovou doménu určených pro modelování webových systémů viz Kroiss [24]. Podobně jako ostatní přístupy pro modelování webu je i UWE založeno na principu oddělení zodpovědností (Separation of Concerns). Modely jsou tvořeny v různých fázích vývojového procesu od sběru požadavků přes analýzu, návrh a implementaci a představují různé pohledy na webovou aplikaci – pohled na obsah, navigační strukturu, prezentaci viz Rossi [38]. Hlavní charakteristikou UWE je použití jazyku UML41 2.0 jako základu pro tvorbu modelů, který rozšiřuje o nové prvky. Elementy metamodelu UWE jsou potomky elementů metamodelu UML viz Koch [22]. Metodika UWE ale není jen modelovací jazyk pro grafické znázornění webových aplikací a metamodel elementů. Jejím cílem je pokrýt celý proces vývoje webových aplikací. Z tohoto důvodu poskytuje modelem řízenou metodiku (model-driven methodology), podporu pro tvorbu modelů a podporu pro automatické generování 34

Java Architecture for XML Binding Document Object Model 36 Simple API for XML 37 Java Database Connectivity 38 Java Message Service 39 Java Naming and Directory Interface 40 UML-based Web Engineering 41 Unified Modeling Language 35

15

1. Použité technologie a koncepty kódu. Generování webových aplikací není zatím plně automatizované (jako je tomu např. u metodiky WebML42 viz Ceri [6]), je ve fázi vývoje. Modely lze tvořit ve dvou CASE43 nástrojích po instalaci pluginů, ve kterých je specifikován UWE profil – ArgoUML (plugin ArgoUWE) a MagicDraw (MagicUWE). Podle UWE je prvním krokem vývoje webových systémů identifikace požadavků, které jsou popsány modelem požadavků (Requirements model) viz Rossi [38]. V tomto modelu je pomocí diagramu případů užití hrubě popsána funkcionalita. Jednotlivé případy užití mohou být podrobněji znázorněny pomocí diagramů aktivit. Metodika UWE případy užití dále člení na navigační (prohlížení obsahu stránek), procesní (byznys požadavky transakčního charakteru), adaptační (customizace systému uživatelem) nebo observační (sledování akcí uživatele) viz Kozuruba [23]. V diagramu bývá takový případ užití označen buď klasickým stereotypem jazyka UML nebo zástupným symbolem v podobě ikony (viz tabulka stereotypů UWE profilu v příloze B.2). Na pomezí mezi analýzou a návrhem webového systému stojí model obsahu (Content model), jehož cílem je specifikace konceptů aplikační domény, které tvoří především obsahovou část systému. Často ovšem zahrnují i webové entity představující uživatelský profil a kontext, které jsou potřebné ke customizaci systému. Pro tyto entity se zpravidla tvoří separátní „User model“. Na základě předešlých modelů je následně vytvořen model navigační (Navigation model), jež reprezentuje navigační (hypertextovou) strukturu systému. Je tvořen navigačními uzly (NavigationNode) a odkazy resp. orientovanými hranami (Link), které uzly spojují a představují směr, kterým může uživatel mezi uzly přecházet. Podrobnou strukturu všech modelů a jejich elementů popisuje Kroiss [24] v referenční příručce UWE. Podle metodiky je prvním krokem tvorby navigačního modelu tzv. počáteční model navigační struktury, který vznikne transformací tříd a vazeb z modelu obsahu na navigační třídy a odkazy. V dalším kroku je model rozšířen o procesní třídy, které reprezentují byznys procesy a jsou odvozeny od „nenavigačních“ případů užití. Autoři metodiky doporučují rozdělení navigačního modelu do více diagramů pokrývajících různé aspekty systému. Procesy figurující v navigačních diagramech bývají následně rozkresleny do procesního modelu (Process model). Nad navigačním modelem je sestaven prezentační model (Presentation model). Ten představuje abstraktní kompozici uživatelského rozhraní. Neřeší přesné rozestavení prvků webových stránek, layout systému a design. Namísto toho popisuje základní strukturu UI tím, že specifikuje elementy obsažené v jednotlivých navigačních uzlech – textová pole, odkazy, tlačítka atd. Model je vizualizován jako diagram tříd. Jeho základním elementem je prezentační třída, která je založena přímo na nějakém navigačním uzlu navigačního modelu. Prezentační třída je kompozicí UI elementů, které jsou jejími vnořenými třídami a označují se různými stereotypy (viz stereotypy UWE v příloze B.2). 42 43

16

Web Modeling Language Computer-Aided Software Engineering

Kapitola

Úvodní studie V úvodní studii je uveden záměr této práce. Následně je provedena rešerše existujících řešení, odvozeny požadavky na systém, popsán návrh architektury systému a analyzována rizika spojená s vývojem.

2.1

Deklarace záměru

Záměrem této práce je vývoj obecného CRM systému určeného pro mnoho klientů – velké podniky i malé firmy z různých odvětví. Důležitými vlastnostmi finálního produktu jsou cenová dostupnost (nízké pořizovací náklady), použitelnost aplikace (propracované UI) a okamžitá dostupnost aplikace (online na vyžádání). Systém bude vyvinut jako webová aplikace. Bude dostupný online přes webový prohlížeč tak, aby jej mohlo využívat více klientů zároveň. Cílem je získávat nové a nové klienty v neomezené míře. Pro zajištění maximální dostupnosti aplikace, je nutné, aby narůstající počet klientů neměl vliv na funkcionalitu aplikace (odezvu, výpadky aplikace). Pokud bychom aplikaci nasazovali na vlastní ICT infrastrukturu, museli bychom zajistit to, že bude působit jako by měla neomezené zdroje (výpočetní, kapacitní). Tyto starosti přenecháme společnosti Google tím, že nasadíme aplikaci na cloudovou platformu GAE, jejíž infrastrukturu tvoří obrovské množství výpočetních uzlů v datových centrech po celém světě. Okamžitá dostupnost aplikace a cenová dostupnost bude zajištěna tím, že bude aplikace vyvinuta jako SaaS. Budeme se držet principů SaaS z definice NIST (viz kapitola 1.1). Uživatel bude moct aplikaci zprovoznit sám, na vyžádání (princip On-demand self-service). Čili ve webovém rozhraní přístupném všem uživatelům, zvolí možnost „začít používat aplikaci“ (alternativně „vyzkoušet aplikaci“) a aplikace mu bude ihned k dispozici pro používání (na vyzkoušení). Cenovou dostupnost zajistíme použitím platebního modelu pay-as-you-go. 17

2

2. Úvodní studie Klient (společnost, firma) bude platit určitý finanční obnos za každého uživatele používajícího aplikaci za měsíc (x Kč/uživatel/měsíc). Přesný platební model bude zvolen po dokončení vývoje. Velký důraz bude kladen na návrh uživatelského rozhraní. Aplikace musí působit přehledně, být jednoduchá na ovládání a na klienty musí působit přirozeně. Pouze to může zajistit její úspěch na trhu. Uživatelské rozhraní bude obsahovat moderní prvky webového rozhraní jako jsou modální okna (dialogy), nástěnka, grafy apod. Dle principů snadné navigace bude používat obrázky u položek menu. Nad celým systémem CRM budou existovat tři logicky oddělené části resp. rozhraní (viz ilustrace 2.1): 1. Webová prezentace „WEB“: Poskytuje běžnému návštěvníkovi webu informace o CRM systému a rozhraní pro vstup do aplikace (jak pro registrované uživatele, tak pro návštěvníky, kteří si chtějí aplikaci vyzkoušet). 2. Aplikace „CRM“: Aplikace, kterou využívají uživatelé (pracovníci klientských společností). Spravují zde účty svých zákazníků, osoby, obchodní případy atd. 3. Front office „FO“: Rozhraní pro správu aplikace a klientských společností, kterou provádí manažeři a administrátoři z týmu, který systém CRM vyvíjí a prodávají.

Obrázek 2.1: Rozhraní CRM systému U jednotlivých částí systému jsou v uvozovkách uvedeny jejich pracovní jména. Pomocí těchto jmen se na tyto části systému budeme v textu odkazovat. Označení CRM systém (resp. „CRMaaS“ nebo „CRM App“) budeme 18

2.2. Rešerše existujících řešení používat pro celý systém – všechny jeho části. Upřesníme i názvy dosud zmíněných aktérů: • Klient: klientská společnost, firma, organizace nebo osoba, které dodáváme CRM • Uživatel (User): zaměstnanec klienta, který pracuje s CRM aplikací • Návštěvník (Visitor): potenciální klient, který prohlíží WEB a může si vyzkoušet demo verzi CRM • Manažer (Manager): manažer systému, který spravuje klienty ve FO • Admin: administrátor systému, který spravuje aplikaci ve FO

2.2

Rešerše existujících řešení

V této části je provedena rešerše tří CRM systémů dostupných přes webové rozhraní. U každého řešení jsou popsány standardní funkce, rozšiřující funkce, uživatelské rozhraní, platební model a provedeno jejich hodnocení.

2.2.1

Salesforce.com

Salesforce.com [40] je americká společnost, která se zabývá poskytováním služeb v cloudovém prostředí. Vlajkovou lodí je stejnojmenné CRM řešení (viz obrázek 2.2), na kterém vybudovala své podnikání. Nyní nabízí několik dalších cloudových služeb (např. PaaS systém Force.com rozšiřující Salesforce.com).

Obrázek 2.2: Salesforce.com (zdroj: Salesforce.com [41]) Systém CRM Salesforce.com je poskytován formou SaaS. Cloudové prostředí je tvořeno vlastními výpočetními zdroji, servery, které jsou umístěny 19

2. Úvodní studie v několika datových centrech rozmístěných po celém světě. Salesforce.com má přes sto tisíc zákazníků z celého světa viz [40] a jeho roční obrat přesahuje miliardu dolarů viz [42].

2.2.2

Raynet cloud CRM

Raynet [37] je česká společnost, která se zabývá vývojem software a zejména jejich mateřského produktu Raynet Cloud CRM (viz obrázek 2.3). V roce 2010 dostala ocenění od nezávislé auditorské společnosti Delloite jako 4. nejprogresivnější technologická firma ve střední Evropě v kategorii „Rising Stars“.

Obrázek 2.3: Raynet Cloud CRM (zdroj: Raynet [36])

Raynet Cloud CRM je poskytován jako SaaS. Všichni klienti přistupují k systému skrze jedno webové rozhraní a nemusejí se starat o nasazení systému a jeho údržbu. Není známo na jaké infrastruktuře je systém nasazen, společnost tyto informace neposkytuje. Může se jednat o interní i externí infrastrukturu. Může jít i o cloudovou infrastrukturu. Systém používají desítky klientů na českém trhu. Do budoucna má velký potenciál.

2.2.3

INEX online CRM systém

INEX online CRM systém [28] je produktem české společnosti MAXprojekt s.r.o., která se orientuje výhradně na vývoj tohoto produktu (viz obrázek 2.4). Systém je poskytován tradičním způsobem. Klient si zaplatí licenci za tento software, nasadí ho na vlastní hardwarovou infrastrukturu a zpřístupní ho přes síť internet všem svým pracovníkům. Jeho údržbu musí zajistit vlastními zdroji. Tento systém používají desítky především českých klientů. 20

2.2. Rešerše existujících řešení

Obrázek 2.4: INEX online CRM systém (zdroj: MAXprojekt [28])

2.2.4

Porovnání CRM systémů

Standardní funkce Všechny tři systémy poskytují standardní funkcionalitu. Tabulka 2.1 uvádí přehled základních funkcí jednotlivých systémů. V systémech se liší pojmenování a smysl některých základních entit jako například „Account“ (účet) resp. „Contact“ (kontakt) v Salesforce.com je ve zbylých systémech ekvivalentem pro „Firma“ resp. „Osoba“. V tomto směru je Salesforce.com obecnější. Salesforce.com

Raynet cloud CRM

INEX online CRM systém

Standardní funkce Správa účtů, kontaktů, obchodních příležitostí, kampaní, smluv, nástěnek, dokumentů, prognóz prodeje, událostí, úkolů, uživatelských rolí, nápadů, produktů. Tvorba vlastních reportů. Kalendář. Chat se spolupracovníky. Nápověda na jednotlivých stránkách, kontextové nápovědy u jednotlivých stránek, entit a panelů. Připomínač aktivit (úkolů a událostí). Nástěnka. Správa firem, osob, obchodní případů, nabídek, objednávek, projektů, produktů, ceníků, úkolů, aktivit, dokumentů. Administrace uživatelů a nastavení oprávnění. Kalendář. Komentování obchodních entit (chat). Nápověda na jednotlivých stránkách. Připomínač aktivit (úkolů a událostí). Reporty. Nástěnka. Správa firem, osob, příležitostí, nabídek, objednávek, faktur, projektů, úkolů, aktivit, produktů a jejich kategorií, kampaní, dokumentů, reportů, benefitů. Administrace skupin, uživatelů a nastavení oprávnění. Kalendář. Chat. Připomínač aktivit, diskuzí a chatu.

Tabulka 2.1: Srovnaní CRM systémů - Standardní funkce 21

2. Úvodní studie Nadstandardní funkce Všechny systémy poskytují různé nadstandardní funkce jako integraci do dalších systémů, možnost použití mobilního klienta, migraci dat ze starého systému, importy dat apod. (viz tabulka 2.2). Nejvíce rozšiřujících služeb nabízí Salesforce.com. I Raynet jde moderní cestou, poskytuje nad systémem REST API. Salesforce.com

Raynet cloud CRM

INEX online CRM systém

Nadstandardní funkce Propojení s Data.com (vyhledávání nad databází účtů a kontaktů). Chat, do kterého je možné zapojit i zákazníky, které klienti Salesforce.com v systému evidují. Následování uživatelů (podobná funkcím „follow“, „followers“ na Twitteru). Správa úloh (chyb a připomínek) a jejich řešení. Customizovatelnost stránek (nastavení zobrazení panelů na stránkách apod.). Tvorba vlastních reportů, integrace e-mailu s aplikacemi Gmail a Outlook, mobilní přístup, tvorba vlastních aplikací a webových stránek nad systémem. Integrace s Google AdWords (aplikace pro sledování reklamních kampaní). Podporuje standard iCalendar (možnost synchronizace kalendáře s dalšími zařízeními). Poskytuje REST API (možnost integrace s aplikacemi třetích stran). Mobilní přístup k systému přes zařízení na platformách iOS, Android, BlackBerry, Windows Phone 7. Import dat ze souborů v binárním formátu XLS nebo formátu CSV44 . Integrace s účetními systémy (Pohoda, Money S3/S5 apod.) a ERP systémy (QI, K2, Helios apod.). Ovšem není uvedeno, zda je integrace s těmito systémy již implementována a jestli je poskytována za příplatek nebo zdarma.

Tabulka 2.2: Srovnaní CRM systémů - Nadstandardní funkce

Uživatelské rozhraní Uživatelské rozhraní je důležitým kritériem pro výběr systému a spokojenost klientů. U každého systému jsou použity moderní prvky UI, ale obsahují určité nedostatky, které by se daly určitým způsobem vylepšit. V tomto tvrzení a následujícím srovnání UI systémů (viz tabulka 2.3), vycházím z obecných principů návrhu uživatelského rozhraní podle Nielsena [32] a Kruga [25] a jednotlivé systémy podle nich subjektivně hodnotím. V rešerši jsou srovnána webová rozhraní aplikací, vyvíjený systém bude rovněž webovou aplikací. Celkově působí nejlepším dojmem rozhraní Raynet Cloud CRM. I tomu ale můžeme vytknout některé nedostatky - položky hlavního menu jsou přístupné až po rozbalení určité kategorie, do nekonečna se otvírají záložky. V systému Salesforce.com nejsou zvýrazněna tlačítka „potvrdit“ oproti tlačítkům „zrušit“, komplexita některých stránek evokuje nepřehlednost. Minimalistický design systému INEX nepůsobí přehledně, na stránce je příliš mnoho informací, některé ikony neodpovídají současným konvencím UI, chybí ikony u položek a podpoložek hlavního menu. 22

2.2. Rešerše existujících řešení

Salesforce.com

Raynet cloud CRM

INEX online CRM systém

Uživatelské rozhraní Na obrázku 2.2 můžeme vidět rozložení stránky (layout) aplikace Salesforce.com, hlavní menu je řešeno jako jednoúrovňové vertikální, položky menu je možné nastavit. Nápověda je na každé stránce a i u panelů. Salesforce.com je velmi komplexní systém, například stránka s detailem příležitosti obsahuje mnoho informací, což nepůsobí přehledně. Stránku ale můžeme customizovat a zakázat zobrazení některých panelů. Po úpravě záznamu je upravená položka barevně odlišena. Tlačítko pro uložení změn ale zvýrazněno není, navíc každý panel má vlastní (viz obrázek B.1). Uživatel se zde může ztrácet. Připomínač funguje formou vyskakovacích oken, což nemusí být praktické. Layout aplikace Raynet je velmi přehledný (viz obrázek 2.3). Hlavní menu je řešeno formou harmoniky (accordion menu), takže nejsou vždy viditelné všechny jeho položky a uživatel musí rozklikávat kategorie. Každé položce menu ale přísluší výstižný obrázek a to naopak práci uživatele usnadní. V aplikaci je obecně hodně ikon a obrázků, které uživateli usnadní orientaci. Každá otevřená položka se zobrazí v záložkách systému. Pokud záložky uživatel průběžně nezavírá, jejich počet roste a view se stává nepřehledným (viz obrázek 2.3). Po editaci nějaké položky se u jména entity zobrazí text „změněno“ a zároveň dojde ke zvýraznění tlačítka „uložit“ (jedno pro celou stránku). Tato situace je pro uživatele přehledná (viz obrázek B.2). Aplikace INEX (viz obrázek 2.4) působí jako desktopová aplikace. V horní části obrazovky je mezi dvěma logy zbytečně moc nevyužitého místa. Hlavní menu s kategoriemi položek je netradičně v levém dolním rohu a položky se otevírají v prostoru nad ním. U kategorií a položek postrádám obrázky. Na obrázku je otevřena kategorie „adresář“ a rozbalena podkategorie „firmy“. Pokud máme v seznamu firem víc záznamům než dva, které jsou na ukázce, a rozbalíme strom firem se všemi položkami, nevejdou se položky na stránku. Jak je řešena tato situace není bohužel známo. Mezi tlačítky „storno“, „uložit“ a „smazat“ v kontextu záznamů není žádný vizuální rozdíl, mohou být snadno zaměněna. Po změně záznamu není tlačítko „uložit“ nijak zvýrazněno.

Tabulka 2.3: Srovnaní CRM systémů - Uživatelské rozhraní

Platební modely Jediný systém, který je dodáván tradičním způsobem je INEX. Zbylé dva jsou poskytovány jako SaaS a uplatňují platební model pay-as-you-go (platí se za skutečně použité zdroje, u modelu SaaS je to cena za každého uživatele, který aplikaci používá daný měsíc). Pořizovací náklady a náklady na správu jsou samozřejmě menší u SaaS systémů. Nejlevnější variantou ze srovnávaných systémů je Salesforce.com (viz tabulka 2.4), za který menší firma s pěti pracovníky zaplatí měsíčně cca 500 Kč, ročně 6 000 Kč (nemá ale k dispozici veškerou funkcionalitu a je omezena pouze na pět uživatelů). Raynet by ve stejném případě stál měsíčně 2 500 Kč, ročně 30 000 Kč. INEX má vysoké pořizovací náklady (v řádech desítek i stovek tisíc korun) a vysoké ceny za servis a podporu. V modelovém případě by 23

2. Úvodní studie klient systému INEX zaplatil za měsíční správu serveru stejnou částku jako za používání systému Raynet včetně veškerého servisu – 2 500 Kč. V této situaci je zřejmé, který poskytovatel se více vyplatí. Salesforce.com

Raynet cloud CRM INEX online CRM systém

Platební modely x$/uživatel/měsíc po dobu používání systému dle zvoleného tarifu: - Contact Manager (Správa kontaktů pro maximálně 5 uživatelů) - 5$ - Group (Základní prodej a marketing pro max. 5 uživatelů) - 15$ - Professional (Kompletní CRM pro neomezený počet uživatelů) - 65$ - Enterprise (Customizovatelný CRM pro celý podnik) - 125$ - Unlimited (Na míru optimalizovaný CRM pro celý podnik) - 250$ Všechny uvedené ceny platí při uzavření minimálně ročního kontraktu pro zákazníky z USA viz Salesforce.com [39]. Ceny liší dle lokace zákazníka (např. v EU jsou vyšší). 500 Kč/uživatel/měsíc po dobu používání systému viz Raynet [37] Tradiční model dodávky software, platíme za licenci (neznámo kolik, cena není uvedena na stránkách) a dále za rozšiřující služby (viz MAXprojekt [28]), například: - servis a podpora - 680 Kč / započtená půlhodina - instalace systému na zařízení odběratele - 10 500 Kč - podpora provozu - 12 000 Kč / den - měsíční správa serveru odběratele - 2 500 Kč - školení uživatelů (nejmenší jednotka 1 den) - 1 450 Kč / hodina

Tabulka 2.4: Srovnaní CRM systémů - Platební modely

Hodnocení V poslední tabulce 2.5 jsou uvedeny klady a zápory všech tří systémů. V celkovém hodnocení je na tom nejlépe Salesforce.com. Neznamená to ale, že je doporučen k použití ve všech situacích. Vhodný je pro klienty, kteří ve zvolené verzi využijí všechny jeho funkce. Nemusí být produktivní ve všech případech.

2.2.5

Závěr rešerše

Z úspěchů zmíněných poskytovatelů je patrné, že na kvalitním CRM systému se dá postavit dobrý byznys. V případě poskytování systému formou SaaS je výhodou to, že si klienti mohou aplikaci jednoduše, bezplatně vyzkoušet a na základě toho se rozhodnout zda systém opravdu chtějí. Pro poskytovatele to navíc znamená úsporu časových a finančních nákladů (nemusíme příliš komunikovat s klientem, jezdit za ním a osobně prezentovat demo apod.). Vyvíjený systém, nemůže obsáhnout takové množství funkcionality jako nabízí Salesforce.com. Budeme se soustředit především na implementaci standardních funkcí a ostatní, rozšiřující ponecháme dalšímu vývoji. Při návrhu UI se necháme inspirovat systémem Raynet Cloud CRM, který působí nejlépe. Pokusíme se eliminovat jeho nedostatky a naopak přidat ně24

2.3. Katalog požadavků

Salesforce.com

+

-

Raynet cloud CRM

+

INEX online CRM systém

+ -

Hodnocení Široké spektrum funkcí, možnost customizace stránek. Propracovaná nápověda. Množnost integrace s několika aplikacemi. Klienti pro mobilní zařízení. Minimální náklady na zavedení a provoz ze strany klienta. Cena za uživatele u základní verze. Online demo. Lokalizace do několika jazyků. Drobné nedostatky v UI. Připomínač formou vyskakovacích oken. Vysoká cena za vyšší verze s veškerou funkcionalitou CRM. Omezený počet uživatelů pro nižší tarify. Jednoduché a přehledné UI. Výuková videa. Mobilní klienti. Export dat do formátu iCalendar. REST API. Minimální náklady na zavedení a provoz ze strany klienta. Online demo. Chybí lokalizace. V rozbalovacím hlavním menu nejsou viditelné všechny položky. Chybí funkce správy kampaní. Lokalizace do dvou jazyků. Možnost integrace s účetními a ERP systémy. Chybí podpora pro mobilní klienty. Vysoká cena za licenci, vysoká cena za podporu. Zodpovědnost za provoz a nasazení systému na straně klienta. Pouze globální nápověda. Pro spuštění online dema je nutná interakce s poskytovatelem.

Tabulka 2.5: Srovnaní CRM systémů - Hodnocení

které zajímavé prvky z ostatních aplikací. Na základě návrhu uživatelského rozhraní vybereme vhodné implementační prostředí tak, aby bylo možné splnit požadavky návrhu. Aplikace bude vyvíjena jako SaaS. Platební model bude standardní pro tento typ služeb. Jeho konkrétní podoba je součástí byznys strategie, která není předmětem této práce.

2.3

Katalog požadavků

Požadavky jsou schopnosti a podmínky, které systém a obecněji projekt musí splňovat viz Jacobson [20]. Hlavním cílem analýzy požadavků je nalezení, sdělení a poznamenání toho, co je opravdu potřeba ve formě, která je čitelná jak pro klienta, tak i pro členy vývojového týmu viz Larman [26]. Velmi často se rozlišují dva typy požadavků – funkční a nefunkční viz Arlow [1]. Funkční požadavky určují, jaké chování bude systém nabízet. Nefunkční specifikují vlastnosti nebo omezující podmínky daného systému.

Aktéři systému Seznam aktérů systému a jejich krátký popis byl již uveden v kapitole deklarace záměru 2.1. Chybí uvedení jednoho dosud nezmíněného aktéra – zodpovědná osoba (responsible). Je to jeden ze zaměstnanců klienta, který je zodpovědný za správu uživatelských účtů ostatních svých kolegů, kteří používají CRM aplikaci. 25

2. Úvodní studie Názvy aktérů systému vystupují v popisu funkčních požadavků. Podrobný popis aktérů je součásti modelu případů užití viz kapitola 3.2.1.

2.3.1

Funkční požadavky

U každého požadavku je uvedena číselná hodnota stanovující prioritu řešení požadavku. Požadavek s nejvyšší hodnotou priority označuje důležitou funkcionalitu, která bude do systému implementována v první iteraci realizace. Požadavky s nižšími prioritami budou realizovány postupně v dalších iteracích. Pracuji se čtyřmi stupni priority (0 až 4). F001: Systém bude umožňovat správu účtů (společností, firem) Uživatel bude moct vytvořit nový účet (společnost, firmu). Pro vytvoření nového účtu musí vyplnit jeho název, stav a typ. Volitelně vyplní další informace jako adresu, telefonní kontakt, oblast působení atd. Po vytvoření účtu se uživatel stává jeho vlastníkem. Uživatel bude moct zobrazit seznam všech účtů, které jsou vlastněny klientem, pod kterého uživatel spadá. Tyto účty bude moct filtrovat, řadit a editovat. • Priorita - 4 F002: Systém bude umožňovat správu kontaktů (osob) Uživatel bude moct vytvořit nový kontakt (osobu). Pro vytvoření nového kontaktu musí vyplnit jeho jméno, příjmení a email. Volitelně vyplní další informace jako telefon, pohlaví apod. Zároveň může kontakt navázat na nějakou společnost (účet). Po vytvoření kontaktu se uživatel stává jeho vlastníkem. Uživatel bude moct zobrazit seznam všech kontaktů, které jsou vlastněny klientem, pod kterého uživatel spadá. Tyto kontakty bude moct filtrovat, řadit a editovat. • Priorita - 4 F003: Systém bude umožňovat správu produktů Uživatel bude moct vytvořit nový produkt. Pro vytvoření nového produktu musí vyplnit jeho název, cenu a kódové označení. Volitelně vyplní další informace jako kategorii, popis atd. Po vytvoření produktu se uživatel stává jeho vlastníkem. Uživatel bude moct zobrazit seznam všech produktů, které jsou vlastněny klientem, pod kterého uživatel spadá. Tyto produkty bude moct filtrovat, řadit a editovat. • Priorita - 4 F004: Systém bude umožňovat správu obchodních případů Uživatel bude moct vytvořit nový obchodní případ. Pro vytvoření nového obchodního případu musí vyplnit jeho předmět. Volitelně vyplní další informace jako pravděpodobnost uskutečnění, předpokládanou dobu uzavření, zdroj atd. Může na něj zároveň navázat produkty, které jsou 26

2.3. Katalog požadavků v rámci daného případu předmětem prodeje. Po vytvoření obchodního případu se uživatel stává jeho vlastníkem. Uživatel bude moct zobrazit seznam všech obchodních případů, které jsou vlastněny klientem, pod kterého uživatel spadá. Tyto obchodní případy bude moct filtrovat, řadit a editovat. • Priorita - 4 F005: Systém bude umožňovat správu aktivit Uživatel bude moct vytvořit novou aktivitu. Pro vytvoření nové aktivity musí vyplnit její název, datum jejího konání a její typ (telefonát, schůzka, úkol, událost atd.). Volitelně vyplní další informace jako čas připomenutí, její stav (realizována, naplánována, zrušena) atd. Může na ni zároveň navázat uživatele, kteří se aktivity účastní, případně navázat obchodní entitu (obchodní případ, kontakt, účet, produkt atd.), které se aktivita týká. Po vytvoření aktivity se uživatel stává jejím vlastníkem. Uživatel bude moct zobrazit seznam všech jeho aktivit. Tyto aktivity bude moct filtrovat, řadit a editovat. • Priorita - 3 F006: Systém bude umožňovat správu ceníků Uživatel bude moct vytvořit nový ceník. Pro vytvoření nového ceníku musí vyplnit jeho název. Volitelně na něj naváže produkty a stanoví jejich novou ceníkovou cenu. Po vytvoření ceníků se uživatel stává jeho vlastníkem. Uživatel bude moct zobrazit seznam všech ceníků, které jsou vlastněny klientem, pod kterého uživatel spadá. Tyto ceníky bude moct filtrovat, řadit a editovat. • Priorita - 2 F007: Systém bude umožňovat zobrazení reportů Uživatel bude moct zobrazit reporty. Uživatel specifikuje pro jaké období chce report zobrazit. Systém bude poskytovat report zobrazující objem prodeje uživatelů (počet realizovaných obchodních případů) za určité období ve formátu sloupcového grafu. Systém bude poskytovat report zobrazující úspěšnost prodeje dle různých kritérií (zdroje obchodního případu, jeho kategorie, stavu atd.) ve formátu koláčového diagramu. Systém bude poskytovat report zobrazující vývoj prodeje za zvolené období ve formátu sloupcového grafu. • Priorita - 1 F008: Systém bude umožňovat zobrazení účtu kolegy Uživatel bude moct zobrazit seznam svých kolegů (uživatelů systému, kteří spadají pod stejného klienta) a zobrazit detailní informace o uživateli (jméno, kontakt). • Priorita - 2 27

2. Úvodní studie F009: Systém umožní přidání komentáře k obchodním entitám Uživatel bude moct přidávat komentáře k obchodním entitám (produktům, obchodním případům, aktivitám, účtům, kontaktům a ceníkům). Na komentář může odpovědět jiný uživatel. • Priorita - 3 F010: Systém zobrazí upozornění na blížící se aktivity Systém bude zobrazovat upozornění na naplánované aktivity uživatele (události, úkoly, schůzky atd.) v čase, na který bude stanovena připomínka. Uživatel bude moct zobrazit seznam upozornění na naplánované aktivity a přejít na detailní informace o těchto aktivitách. • Priorita - 3 F011: Systém zobrazí upozornění na změnu vlastníka obchodní entity Systém bude zobrazovat upozornění na změnu vlastnictví obchodní entity (kontaktu, účtu, produktu, obchodního případu atd.) uživateli, který ji vlastnil před tím, než došlo ke změně vlastnictví. Uživatel bude moct zobrazit seznam upozornění na změny vlastnictví a přejít na detailní informace o těchto změnách, kde bude uvedeno, kdo a kdy změnu provedl. • Priorita - 3 F012: Systém zobrazí upozornění na odpovědi ke komentářům Systém bude zobrazovat upozornění na odpovědi ke komentářům, které do systému vložil uživatel k nějaké obchodní entitě (kontaktu, účtu, obchodnímu případu atd.). Uživatel bude moct zobrazit seznam upozornění na odpovědi ke komentářům a přejít na zvolené vlákno komentářů obchodní entity. • Priorita - 3 F015: Systém bude umožňovat správu nástěnky Uživatel bude moct nastavit jaké panely chce zobrazovat na nástěnce. Můžou to být panely zobrazující reporty, seznam aktivit, rychlé volby apod. • Priorita - 2 F021: Systém bude umožňovat správu uživatelského účtu Uživatel bude moct upravovat svůj uživatelský účet. Bude moct editovat své kontaktní údaje nebo heslo pro přístup do systému. • Priorita - 3 F022: Systém bude umožňovat zobrazení nápovědy Uživatel bude moct zobrazit nápovědu k používání aplikace. V systému bude globální nápověda obsahující obecné informace o tom, jak systém používat. U některých prvků rozhraní bude kontextová nápověda. 28

2.3. Katalog požadavků • Priorita - 2 F023: Systém bude umožňovat obnovení zapomenutého hesla Uživatel bude moct obnovit zapomenuté heslo pro přihlášení do systému. Systém vygeneruje nové heslo a odešle ho uživateli na email. • Priorita - 1 F031: Systém bude umožňovat správu uživatelů klienta Zodpovědná osoba bude moct odeslat pozvánku pro vstup do systému novému uživateli (kolegovi) prostřednictvím emailu. Zodpovědná osoba bude moct zobrazit seznam všech uživatelů spadajících do jeho společnosti a bude mít právo zneplatnit uživatelský účet (odepřít uživateli přístup do systému). • Priorita - 3 F051: Systém bude umožňovat správu klientů Manažer bude moct zobrazit seznam všech klientů systému a zodpovědných osob pro tyto klienty. Manažer bude moct změnit kontaktní údaje klienta nebo zodpovědné osoby. • Priorita - 3 F052: Systém bude umožňovat odeslání faktury klientovi Systém bude automaticky odesílat elektronickou verzi faktury na email klienta. Celková částka k uhrazení bude vypočítána jako součin počtu aktivních uživatelů, kteří spadají pod klienta a ceny za měsíční používání CRM aplikace jedním uživatelem. • Priorita - 1 F053: Systém bude umožňovat správu faktur Manažer bude moct zobrazit seznam vystavených faktur a detail zvolené faktury, ve kterém bude moct upravit fakturační údaje. Upravenou fakturu bude moct odeslat v elektronické verzi na email klienta. • Priorita - 1 F061: Systém bude umožňovat správu manažerů Administrátor systému bude moct zobrazit seznam všech manažerů. Bude moct založit nový manažerský účet nebo zneplatnit účet stávajícímu manažerovi. • Priorita - 2 F062: Systém bude umožňovat nastavení ceny za používání CRM Administrátor systému bude moct nastavit cenu za jednoho uživatele za měsíc používání CRM aplikace. • Priorita - 2 29

2. Úvodní studie F071: Systém bude zaznamenávat systémové informace o entitě Každá nově vytvořená entita systému (uživatel, klient, produkt, kontakt apod.) sebou ponese informaci o tom, který uživatel a kdy ji založil. Entita bude rovněž obsahovat informace o poslední změně – uživateli, který ji změnil a čase. • Priorita - 4 F072: Systém bude poskytovat zkušební verzi systému (demo) Návštěvník webu bude moct vyzkoušet demo verzi CRM aplikace. Přihlásí se pod účtem s názvem „demo“, který spadá pod vzorového klienta. Každý den nahraje systém vzorové záznamy navázané na tohoto klienta (produkty, obchodní případy, účty, kontakty atd.). Tímto způsobem bude zajištěno, že si návštěvník bude moct vyzkoušet veškerou funkcionalitu aplikace. • Priorita - 1 F073: Systém bude umožňovat objednání CRM systému Návštěvník webu bude moct objednat CRM aplikaci. Pro objednání bude nutné, aby se nejprve registroval ve webovém rozhraní a vytvořil klientský účet. Po registraci a přihlášení do systému v roli zodpovědné osoby bude moct objednat CRM aplikaci pro zvolený počet uživatelů. Následně pozve uživatele tak, že zadá jejich emailové adresy, na které systém odešle email s pozvánkou a vygenerovaným heslem. • Priorita - 1

2.3.2

Nefunkční požadavky

Grady [18] uvádí způsob kategorizace požadavků zvaný FURPS45 , který využívá i metodika UP46 . Písmeno „F“ v názvu označuje funkční požadavky, ostatní písmena značí kategorie nefunkčních požadavků. Toto členění nefunkčních požadavků je zde z části použito. Systém bude nasazen jako webová aplikace a bude přístupný prakticky jakémukoli uživateli sítě internet. Webové aplikace jsou vystaveny potenciálně neomezenému množství současně pracujících uživatelů. To má dopad na zvýšené nároky na bezpečnost, ovladatelnost, škálovatelnost a dostupnost. Tato skupina pojmů tvoří další kategorie nefunkčních požadavků. Bezpečnost Systém bude standardním způsobem autentizovat uživatele pro vstup do systému a autorizovat jeho přístup k datům. 45 46

30

Functional, Usability, Reliability, Performance, Suppotability Unified Process

2.4. Návrh architektury řešení Škálovatelnost Systém bude flexibilně reagovat na změnu svého zatížení bez nutnosti zásahu lidského faktoru. Dostupnost a spolehlivost Systém bude dostupný v režimu 24/7 (24 hodin denně, 7 dní v týdnu) s minimálními výpadky. Použitelnost Systém bude poskytovat komplexní nápovědu pro jeho používání a u některých prvků i nápovědu kontextovou. Bude vytvořena uživatelská příručka. Systém bude přístupný přes webový prohlížeč. Primárně podporovanými prohlížeči jsou Mozilla Firefox a Google Chrome. Systém bude optimalizován pro minimální rozlišení obrazovky 1280x800. Podpora Systém bude poskytovat podporu pro více jazyků (lokalizaci). Výchozí lokalizací bude angličtina, další podporovanou čeština. Systém bude umožňovat uživateli nastavení a customizovatelnost. Funkcionalita systému bude ověřena jednotkovým testováním. Použitelnost uživatelského rozhraní bude ověřena testováním použitelnosti. Implementace Systém bude nasazen na platformě GAE a vyvinut v jazyce Java. Obchodní a právní aspekty Systém bude poskytován formou SaaS.

2.4

Návrh architektury řešení

Systém bude realizován jako webová aplikace, která bude nasazena v PaaS prostředí, na platformě Google App Engine. Uživatel bude k aplikaci přistupovat přes webový prohlížeč instalovaný na jeho počítači. Konkrétní fyzická architektura navrhovaného systému je včetně diagramu nasazení (viz obrázek 4.5) a obrázku zobrazujícího mechanizmus rozdělení zátěže na GAE popsána v kapitole 4.3.2.

2.5

Analýza rizik

Analýza a řízení rizik je řada kroků, které pomáhají softwarovému týmu odhalit a řídit nejistoty, které mohou v průběhu celého životního cyklu vývoje software nastat viz Pressman [35]. Softwarový projekt může být ohrožen mnoha problémy. Riziko je potenciální problém – může nastat, ale nemusí. Bez ohledu 31

2. Úvodní studie na to zda nastane či nikoli, je dobré jej identifikovat, vyhodnotit ho, určit pravděpodobnost jeho výskytu, odhadnout jeho dopady a vytvořit plán pro situaci, kdyby k danému problému skutečně došlo. Účelem provedení analýzy rizik bylo odhalení problémů, které by mohly nastat a předejití časovým a finančním ztrátám. Pressman [35] uvádí tři obecné kategorie rizik: Projektová rizika (P) ohrožují plán projektu. To znamená, že pokud riziko skutečně nastane, je pravděpodobné, že bude harmonogram projektu ve skluzu a zvýší se náklady. Projektová rizika identifikují potenciální problémy spojené s rozpočtem, harmonogramem, personálem, zdroji, zákazníkem a požadavky a určují jejich dopad na softwarový projekt. Technická rizika (T) ohrožují kvalitu a včasnost dodání softwarového produktu. Pokud nastane technické riziko, může být implementace obtížná nebo zcela nemožná. Technická rizika identifikují potenciální problémy spojené s návrhem, implementací, rozhraními, verifikací a údržbou. Byznys rizika (B) ohrožují uskutečnitelnost vyvíjeného software (projektu i produktu). Byznys neboli obchodní rizika identifikují potenciální problémy spojené s poptávkou po produktu, měnící se podnikovou strategií, schopností prodeje produktu, změnami podpory projektu ze strany vedení podniku a rozpočtovými a personálními ztrátami.

2.5.1

Identifikace rizik

V této kapitole jsou popsána rizika, která byla identifikována u tohoto projektu. U každého rizika je uvedeno jeho označení, kategorie, název a popis. Vyhodnocení rizik je uvedeno v tabulce 2.6 v následující podkapitole 2.5.2. R01-P: Kvalita a dostupnost vývojových nástrojů Zvolím neosvědčený vývojový nástroj, který nesplní mé očekávání nebo nebude splňovat požadavky. Jedná se především o volbu IDE pro implementaci systému, nástrojů CASE pro modelování systému a systému pro správu verzí projektu. Tyto nástroje jsou v dnešní době na podobné úrovni, jejich volba by se neměla ve větší míře projevit na vývoji. – Dopad: zanedbatelný, Pravděpodobnost: 5 % R02-P: Špatně odhadnutá velikost projektu Plánovaná doba vývoje se protáhne kvůli tomu, že špatně odhadu velikost projektu nebo špatně naplánuji vývoj. Jelikož aplikace není primárně určena pro žádného konkrétního zákazníka, nemá toto riziko kritický dopad. V případě prodloužení vývoje není sice nutné hradit žádné penále, prodloužení doby vývoje mě časově a finančně zatíží. – Dopad: marginální, Pravděpodobnost: 30 % 32

2.5. Analýza rizik R03-T: Nepřehledné, nepoutavé, nepoužitelné uživatelské rozhraní Vytvořím uživatelské rozhraní bez předchozího návrhu a otestování. To v konečném důsledku nebude vyhovovat koncovým uživatelům – nebude přehledné, dostatečně intuitivní a poutavé. Tím ztratím nebo si nezískám zákazníky, což může mít až katastrofální dopad na celý projekt. – Dopad: katastrofální, Pravděpodobnost: 25 % R04-B: Nízká poptávka po produktu Produkt budu nabízet špatné skupině zákazníků. Atraktivní zákazníci se o produktu nedozví. Poptávka po produktu bude nízká a produkt nebude rentabilní, přijdu o investice vložené do projektu. Toto riziko má vyšší pravděpodobnost. Nemám potřebné zkušenosti s nabídkou software. Riziko je možné eliminovat outsourcingem v této oblasti, proto není jeho dopad tak velký. – Dopad: marginální, Pravděpodobnost: 35 % R05-B: Špatný marketing a prodej produktu Nebudu schopen vlastními silami prodat produkt. Zákazníci se o produktu nedozví kvůli špatné marketingové strategii a projekt nebude rentabilní. Riziko má velkou pravděpodobnost. Nemám zkušenosti s marketingem a prodejem. Tyto služby ale můžu outsourcovat, proto nemají na projekt takový dopad. – Dopad: marginální, Pravděpodobnost: 40 % R06-T: Škálovatelnost webové aplikace Systém nedokáže pružně reagovat na měnící se počet požadavků, který budou zákazníci a uživatelé aplikace klást. Nezvládne větší zátěž. To povede ke ztrátě zákazníků. Systém ale bude nasazen na cloudovou platformu, která se o škálovatelnost postará. Pravděpodobnost výskytu tohoto rizika je tedy nízká, dopad by ovšem byl kritický. – Dopad: kritický, Pravděpodobnost: 5 % R07-T: Bezpečnost systému Nasadím systém, který nebude dostatečně zabezpečen a dojde k odcizení nebo manipulaci s citlivými podnikovými informacemi některého ze zákazníků. Nebo bude na systém proveden útok, který ho vyřadí z provozu. Toto riziko má katastrofální důsledky – ztráta zákazníků a možné právní spory. Nemá zanedbatelnou pravděpodobnost, musí být řízeno. – Dopad: katastrofální, Pravděpodobnost: 20 % R08-P: Technické schopnosti a zkušenosti Přecením své schopnosti. Mám malé zkušenosti s vývojem na platformě GAE a nebudu schopen vyvinout systém v takové kvalitě jaká je od něj očekávána. Tento problém by měl kritický dopad na vývoj systému. Jeho pravděpodobnost není zanedbatelná. – Dopad: kritický, Pravděpodobnost: 30 % 33

2. Úvodní studie R09-P: Špatné stanovení požadavků na systém Nesprávně určím funkční a nefunkční požadavky, neprovedu jejich analýzu. Špatný odhad požadavků může mít kritický dopad na vývoj systému a celý projekt, který by mohl být v konečném důsledku nepoužitelný. Pokud opomenu nějaký zásadní požadavek, jeho dodatečná implementace může způsobit velký, nákladný zásah do logiky systému. S analýzou požadavků mám zkušenosti. Toto riziko může i přesto nastat. – Dopad: kritický, Pravděpodobnost: 25 % R10-T: Technologie nebo framework nesplní očekávání Technologie nebo framework, který použiji pro vývoj nesplní očekávání a nebudu moci implementovat nějakou funkcionalitu. Budu ji muset nahradit za jinou. Závažnost tohoto rizika se liší dle času kdy nastane. Nastane-li v pokročilé fázi projektu např. těsně před nasazením, má kritické důsledky. Budu volit ověřené technologie. Ty ovšem na GAE nemusejí fungovat, proto není pravděpodobnost zanedbatelná. – Dopad: kritický, Pravděpodobnost: 15 % R11-T: Nasazení neověřeného systému Nasadím systém, který bude vykazovat velké množství chyb a zákazník s ním nebude moci pracovat. To povede ke ztrátě zákazníka. Může mít kritický dopad. Neprovedu-li testování je pravděpodobnost výskytu tohoto problému vysoká. – Dopad: kritický, Pravděpodobnost: 30 % R12-T: Platforma GAE bude vykazovat výkonnostní nedostatky Nasadím systém na platformu GAE, doba jeho odezvy bude nepřiměřená. Zákazník bude dlouho čekat než systém obslouží jeho požadavky a práce se systém bude pro něj ztrátová. Mohlo by vést ke ztrátě zákazníka, což by mělo katastrofální dopad. App Engine garantuje v SLA47 parametry nabízených služeb. Není pravděpodobné, že by vznikl problém v důsledku výkonnostních nedostatků ze strany GAE. – Dopad: katastrofální, Pravděpodobnost: 5 % R13-T: Platforma GAE bude vykazovat technologické nedostatky Některé prvoplánové a ověřené technologie nebudu moci použít (budu muset přejít na jiné) nebo bude jejich použití vyžadovat nestandardní postupy a dojde k prodloužení doby vývoje systému. Prodloužení doby vývoje nemá vysoký vliv na finanční ztráty. Platforma App Engine ale nepodporuje mnoho technologií a tento problém může nastat. – Dopad: marginální, Pravděpodobnost: 20 % R14-B: GAE změní platební podmínky, zvýší se provozní náklady Systém bude závislý na platformě GAE, na které bude provozován. Společnost Google ale může změnit platební podmínky služeb GAE, což 47

34

Service Level Agreement

2.5. Analýza rizik zvýší náklady na provoz systému a sníží můj zisk. Není příliš pravděpodobné a časté aby došlo ke změně platebních podmínek. Dopad na projekt by neměl být velký, závisí na velikosti změny. – Dopad: marginální, Pravděpodobnost: 10 % R15-B: Obtížná rozšiřitelnost systému Navrhnu a implementuji systém tak, že jej nebude možno v budoucnu rozšířit nebo upravit (např. vyvinout mobilního klienta, API nad systémem). Nemožnost nebo komplikovaný způsob rozšíření povede k tomu, že bude rozšíření příliš nákladné nebo zcela nemožné. Neexistence rozšíření se může stát konkurenční nevýhodou. S návrhem systémů mám určité zkušenosti. I tak je pravděpodobné, že nastane nějaký problém s rozšiřitelností. Dopad ovšem není kritický. – Dopad: marginální, Pravděpodobnost: 25 %

2.5.2

Vyhodnocení

Výstupem analýzy rizik je vyhodnocení (viz tabulka 2.6), ve které jsou uvedena všechna známá rizika spojená s tímto projektem, uveden stupeň jejich závažnosti a způsob jejich zmírnění nebo řízení. Kategorie rizika je označena v jeho identifikátoru. Ve sloupci „D“ tabulky 2.6 je uvedeno ohodnocení závažnosti rizika (dopad), ve sloupci „P“ pravděpodobnost toho, jestli riziko nastane a ve sloupci „H“ jeho hodnota vypočítaná jako součin hodnoty dopadu a pravděpodobnosti. Rozlišují se čtyři stupně závažnosti (dopadu) rizika: 1. zanedbatelný 2. marginální 3. kritický 4. katastrofický Rizika jsou seřazena sestupně od toho s nejvyšší hodnotou. Poslední sloupec obsahuje popis opatření, které bude provedeno pro jeho zmírnění, případně eliminaci pokud nastane.

35

2. Úvodní studie Riziko

P [%]

D

H

Opatření

R03-T Nepřehledné, nepoutavé, nepoužitelné uživatelské rozhraní R08-P Technické schopnosti a zkušenosti

25

4

1

30

3

0,9

R11-T Nasazení neověřeného systému R05-B Špatný marketing a prodej produktu R07-T Bezpečnost systému R09-P Špatné stanovení požadavků na systém R04-B Nízká poptávka po produktu R02-P Špatně odhadnutá velikost projektu

30

3

0,9

40

2

0,8

20

4

0,8

25

3

0,75

35

2

0,7

30

2

0,6

R15-B Obtížná rozšiřitelnost systému

25

2

0,5

R10-T Technologie nebo framework nesplní očekávání R13-T Platforma GAE bude vykazovat technologické nedostatky

15

3

0,45

20

2

0,4

R12-T Platforma GAE bude vykazovat výkonnostní nedostatky

5

4

0,2

R14-B GAE změní platební podmínky, zvýší se provozní náklady

10

2

0,2

R06-T Škálovatelnost webové aplikace

5

3

0,15

R01-P Kvalita a dostupnost vývojových nástrojů

5

1

0,05

Provedu návrh uživatelského rozhraní a jeho testování. Na hotové aplikaci provedu testovaní použitelnosti se zástupci cílových skupin. Nastuduji technologie a „best practicies“ z oblasti návrhu a vývoje aplikací v jazyku Java na platformě GAE. Projekt budu konzultovat s externími experty pro tuto oblast vývoje. Implementuji jednotkové testy a provedu další druhy testování systému. Budu konzultovat nebo outsourcovat odborníky z oblasti marketingu a prodeje. Nastuduji a implementuji obecné a doporučené bezpečnostní mechanismy pro platformu GAE. Provedu rešerši předních CRM systémů na trhu, na jejíž základě stanovím požadavky. Provedu analýzu trhu a zacílím marketing na klíčové skupiny zákazníků. Odhadnu pracnost na základě zkušeností z předchozích projektů, na kterých jsem pracoval. Stanovím harmonogram projektu a milníky, ve kterých budu práci prezentovat vedoucímu práce. Nastuduji „best practicies“ z oblasti OOD48 , OOP49 a technologií pro vývoj podobných systému. Navrhnu a implementuji systém podle těchto doporučení tak, aby byl rozšiřitelný. Budu dbát na psaní dokumentace kódu i projektu. Nastuduji technologie a frameworky, které jsou plánovány pro vývoj a ověřím jejich funkčnost na prototypu aplikace. Nastuduji a vyberu technologie, které je možno použít pro vývoj na platformě GAE v jazyku Java. Pokud nějaká technologie nebude použitelná, zvolím adekvátní náhradu a cyklus zopakuji. Budu se držet doporučení pro vývoj na GAE a dle nich systém optimalizuji. Budou-li patrné výkonností nedostatky, přejdu na vyšší, placenou verzi GAE, která má lepší výkonnostní parametry. Tuto situaci ošetřím ve smlouvě o poskytování služeb (SLA) systému CRM, který vyvíjím. Uvedu v ní, že bude možné zvýšit cenu poskytovaných služeb na základě zvýšení cen služeb subdodavatele. Implementuji mechanizmy pro podporu škálovatelnosti aplikace (Memcache apod.), o kterou se stará load balancing na platformě GAE. Zvolím osvědčené nástroje a při výběru IDE uvážím doporučení pro vývoj v jazyku Java na platformě GAE.

Tabulka 2.6: Vyhodnocení analýzy rizik

36

Kapitola

Analýza V první části je rozebrán konceptuální datový model, jeho jednotlivé entity a vztahy mezi nimi. Druhá část je věnována modelu případů užití systému, definici aktérů systému a specifikaci případů užití systému.

3.1

Konceptuální datový model

Konceptuální datový model slouží k vizualizaci konceptů reálného světa v kontextu problémové domény viz Larman [26]. Tyto koncepty jsou reprezentovány formou konceptuálních tříd, které odpovídají reálným prvkům problémové domény, a vztahů, které mezi nimi jsou. Nejedná se o diagramy, které popisují doménovou vrstvu softwarové architektury, softwarové artefakty (komponenty jako např. databáze) nebo softwarové třídy (Java nebo C# třídy – obsahují metody). Může ale sloužit jako inspirace pro návrh softwarových tříd. Konceptuální datový model CRM systému je zobrazen na obrázku 3.1. Základní entitou je „AppUser“, která reprezentuje uživatele systému. Jeho potomky jsou „User“ – pracovník klienta systému a „Manager“ – pracovník CRM systému, který spravuje účty klientů „Client“ a faktury jim vystavené „Invoice“. Stěžejními entitami systému, se kterými pracuje uživatel, jsou obchodní entity, které jsou potomky entity „BusinessEntity“. Jsou to entity „Account“ (účet, společnost, firma, zákazník), „Contact“ (kontakt, osoba), „Product“ (produkt, výrobek, služba), „PriceList“ (ceník produktů), „Activity“ (aktivita) a „BusinessCase“ (obchodní případ, příležitost). Ke všem těmto entitám je možné přidávat komentáře (entita „Comment“). Entita reprezentující připomínku ( „Reminder“), na kterou je uživatel upozorněn, může být trojího typu – „Alarm“ (připomenutí aktivity), „Communication“ (odpověď na komentář) a „Warning“ (změna vlastnictví obchodní entity). Jednotlivé entity, atributy a vztahy mezi entitami jsou popsány níže. Na základě tohoto modelu a zvoleného způsobu ukládání dat na GAE bude navržen fyzický datový model. 37

3

3. Analýza

38 Obrázek 3.1: Konceptuální datový model

3.1. Konceptuální datový model

3.1.1

Entity a jejich atributy

GenericEntity(«generic») obecná entita, která je předkem pro všechny entity systému (tato vazba není uvedena v konceptuálním modelu 3.1) createdDate – čas a den vytvoření entity modifiedDate – čas a den provedení poslední změny entity version – verze entity (inkrementuje se s každou změnou) AppUser obecný uživatel systému, každá osoba, která má vytvořen uživatelský účet, může se přihlásit do systému a pracovat s ním blocked – označuje, zda je uživatelský účet zablokován firstName – křestní jméno email – email language – preferovaný jazyk CRM aplikace lastName – příjmení password – heslo pro přihlášení do systému username – přihlašovací jméno do CRM systému User reprezentuje aktéra „Uživatel“ viz model aktérů 3.2.1 dashboardItems – nastavení zobrazovaných panelů na nástěnce lastLoginDate – čas a den posledního přihlášení aktéra „Uživatel“ CrmService nastavení CRM služeb monthPrice – cena za měsíční používání CRM služeb jedním uživatelem currency – měna ceny BusinessEntity obchodní entita, předek pro entity obchodního charakteru, které můžou uživatelé komentovat, vázat na ně své aktivity apod. note – poznámka k obchodní entitě Account účet representuje firmu nebo společnost, se kterou obchoduje a má v evidenci klient CRM systému companyId – identifikátor, který používá klient k identifikaci společnosti email – email společnosti employeesCount – počet zaměstnanců společnosti name – název společnosti phone – telefonní kontakt revenue – roční příjem společnosti web – webové sídlo společnosti Contact kontakt na osobu, kterou eviduje klient u nějaké své společnosti email – email na osobu firstName – křestní jméno lastName – příjmení language – jazyk preferovaný pro komunikaci phone – telefonní kontakt web – webové stránky osoby 39

3. Analýza Product produkt, který má klient v prodejním katalogu a prodává ho enabled – označení toho, zda je produkt momentálně určen k prodeji code – kódové označení produktu currency – měna ceny description – popis produktu name – název produktu price – cena produktu PriceList ceník má klient vytvořen pro skupinu produktů (obsahuje produkty a jejich ceníkové ceny) enabled – – označení toho, zda je ceník momentálně určen k nabídce name – – název ceníku Activity aktivita je událost, schůzka nebo úkol, který má uživatel naplánován dateFrom – – čas začátku aktivity dateTo – – čas konce aktivity name – – název aktivity BusinessCase obchodní případ (nebo příležitost), který klient uzavírá s nějakou společností, kterou v systému eviduje jako svého zákazníka. Může na sebe mít navázány produkty, které jsou předmětem prodeje closedDate – datum uzavření obchodního případu (zaplacen) confirmedDate – datum potvrzení (schválení) prodeje obchodního případu (čeká se na platbu od zákazníka) estimatedCloseDate – předpokládaná doba uzavření o. p. probability – pravděpodobnost uzavření o. p. subject – název o. p., předmět prodeje finalPrice – koncová cena o. p. costsValue – odhadované náklady klienta na realizaci o. p. Reminder připomínka, která uživatele ve stanovený čas upozorňují na naplánovanou aktivitu, změnu v záznamech nebo odpověď na jeho komentář active – označení toho, zda již bylo upozorněno na připomínku remindTime – čas pro upozornění na připomínku Alarm připomínka typu alarm, která slouží k upozornění na naplánovanou aktivitu Warning připomínka typu varování, která slouží k upozornění na změnu v záznamu obchodní entity (změnu vlastnictví obchodní entity, kterou vlastnil uživatel) Communication připomínka typu komunikace, která slouží k upozornění na odpověď na komentář uživatele Comment komentář, který vložil uživatel k nějaké obchodní entitě nebo jako odpověď na jiný komentář date – datum vložení komentáře text – text komentáře 40

3.1. Konceptuální datový model Address poštovní adresa subjektu city – město country – stát, země houseNo – číslo popisné street – ulice zipCode – poštovní směrovací číslo WorksInCompany(«asociační třída») vztah mezi kontaktem (osobou) a účtem (společností), který definuje zaměstnaneckou pozici osoby ve společnosti position – pozice osoby ve společnosti primary – označení primárního zaměstnání osoby ve společnosti PriceListItem(«asociační třída») vztah mezi ceníkem a produktem, který vyjadřuje zahrnutí produktu do ceníku a stanovení jeho ceníkové ceny listPrice – ceníková cena produktu currency – měna ceny ProductItem(«asociační třída») vztah mezi produktem a obchodním případem, který vyjadřuje zahrnutí produktu na seznam objednaných produktů v rámci obchodního případu a stanovení jeho prodejní ceny, slevy, názvu a množství discount – sleva z prodejní ceny produktu v o. p. name – název produktu v o. p. quantity – počet kusů produktu na objednávce o. p. salesPrice – prodejní cena produktu v o. p. Client klient je společnost, která objednala CRM systém. Několik pracovníků klienta má uživatelský účet a používá CRM systém. Tyto služby jsou klientovi měsíčně fakturovány. Na klienta se vážou uživatelé a kategorie, které si vytvořil companyId – identifikace klienta companyName – název klienta email – email klienta maxUsers – limit pro počet uživatelských účtů phone – telefonní kontakt na klienta trialEndDate – den, kdy vyprší zkušební doba web – webové sídlo klienta Manager manažer CRM systému starající se o klienty a spravující jejich účty Invoice faktura vystavená klientovi za užívání systému invoiceDate – datum vystavení faktury invoiceNumber – číslo faktury payDate – datum splatnosti faktury totalAmount – celková částka faktury currency – měna celkové částky 41

3. Analýza InvoiceItem položka faktury price – cena položky comment – komentář k položce discount – sleva ceny položky quantity – množství currency – měna ceny položky name – název položky unit – jednotka položky IndustryField oblast působení definovaná klientem name – název oblasti působení ContactCategory kategorie kontaktů definované klientem name – název kategorie kontaktů ProductCategory kategorie produktů definované klientem name – název kategorie produktů BusinessCaseSource zdroj získání obchodního příp. definovaný klientem name – název zdroje získání o. p.

3.1.2

Vztahy mezi entitami

dědičnost (GenericEntity, *) – Každá entita dědí od obecné entity (GenericEntity). createdBy (GenericEntity, AppUser) [M:1] – Uživatel aplikace (AppUser) může vytvořit několik obecných entit (GenericEntity). Obecná entita je vytvořena právě jedním uživatelem. lastModifiedBy (GenericEntity, AppUser) [M:0..1] – Uživatel aplikace (AppUser) může být posledním upravujícím uživatelem několika obecných entit (GenericEntity). Obecná entita může být naposledy upravena nejvýše jedním uživatelem. hasReminders (User, Reminder) [kompozice 1:M] – Uživatel (User) vlastní několik připomínek (Reminder), na které má být upozorněn. Připomínka je vlastněna právě jedním uživatelem. hasComments (BusinessEntity, Comment) [kompozice 1:M] – Obchodní entita (BusinessEntity) může být opatřena několika komentáři (Comment). Komentář je napsán k právě jedné obchodní entitě. ownedBy (BusinessEntity, User) [agregace M:1] – Obchodní entitu (BusinessEntity) vlastní právě jeden uživatel (User). Uživatel může vlastnit několik obchodních entit. hasIndustry (Account, IndustryField) [M:0..1] – Společnost (Accout) má nejvýše jednu oblast působení (IndustryField). Oblast působení může být společná pro několik různých společností. 42

3.1. Konceptuální datový model hasState (Account, AccountState [M:1] – Společnost (Accout) se nachází v právě jednom stavu (AccountState). Stav společnosti (aktuální, potenciální, nezajímavý) může být společný pro několik různých společností. hasType (Account, AccountType) [M:1] – Společnost (Accout) je právě jednoho typu (AccountType). Typ společnosti (konkurence, zákazník, partner) může být společný pro několik různých společností. hasShippingAddress (Account, Address) [kompozice 1:0..1] – Společnost (Accout) může mít nejvýše jednu doručovací adresu (Address). Adresa patří právě jedné společnosti. hasBillingAddress (Account, Address) [kompozice 1:0..1] – Společnost (Accout) může mít nejvýše jednu fakturační adresu (Address). Adresa patří právě jedné společnosti. hasGender (Contact, GenderType) [M:0..1] – Osoba (Contact) může mít uvedeno pohlaví (GenderType). Stejného pohlaví (muž, žena) může být několik osob. inCategory (Contact, ContactCategory) [M:0..1] – Osoba (Contact) může být zařazena nejvýše v jedné kategorii osob (ContactCategory). V jedné kategorii osob může být zařazeno několik osob. inCategory (Product, ProductCategory) [M:0..1] – Produkt (Product) může být zařazen nejvýše v jedné kategorii produktů (ProductCategory). V jedné kategorii produktů může být zařazeno několik produktů. participates (Activity, User) [M:N] – Uživatel (User) se může účastnit několika aktivit (Activity). Aktivita může být naplánována pro několik uživatelů. hasState (Activity, ActivityState) [M:0..1] – Aktivita (Activity) může nacházet nejvýše jednom stavu (ActivityState). Stav aktivity (naplánována, uskutečněna, zrušena) může být společný pro několik různých aktivit. hasType (Activity, ActivityType) [M:0..1] – Aktivita (Activity) může mít nejvýše jeden typ (ActivityType). Typ (úkol, událost, telefonát, email, schůzka) může být společný pro několik různých aktivit. relatedTo (Activity, BusinessEntity) [M:0..1] – Aktivita (Activity) může být navázána na nejvýše jednu obchodní entitu (BusinessEntity). Obchodní entita může být navázána na několik aktivit. participates (Activity, Contact) [M:N] – Aktivity (Activity) se může účastnit několik osob (Contact). Osoby se mohou účastnit několika aktivit. hasState (BusinessCase, BusinessCaseState) [M:0..1] – Obchodní případ (BusinessCase) se může nacházet nejvýše v jednom stavu (BusinessCaseState). Stav obchodního případu (v jednání, potvrzen, výhra, prohra) může být společný pro několik různých obchodních případů. 43

3. Analýza hasSource (BusinessCase, BusinessCaseSource) [M:0..1] – Obchodní případ (BusinessCase) může mít nejvýše jeden zdroj původu (BusinessCaseSource). Zdroj původu obchodního případu může být společný pro několik různých obchodních případů. offeredFor (BusinessCase, Account) [M:1] – Obchodní případ (BusinessCase) je nabízen a uzavírán pro právě jednu společnost (Account). Se společností může být uzavřeno několik obchodních případů. contractedWith (BusinessCase, Contact) [M:0..1] – Obchodní případ (BusinessCase) může být sjednán nejvýše s jednou osobou (Contact). Osoba může sjednat několik obchodních případů. remindedBy (Alarm, Activity) [M:1] – Alarm upozorňuje na právě jednu aktivitu (Activity). Na jednu aktivitu může být upozorněno několika alarmy (pro každého uživatele účastnícího se aktivity). warnsEntity (Warning, BusinessEntity) [M:1] – Varování (Warning) upozorňuje právě na jednu obchodní entitu (BusinessEntity), která byla změněna. Na jednu obchodní entitu může upozornit několik varování. remindedBy (Communication, Comment) [M:1] – Připomínka na komunikaci (Communication) upozorňuje na právě jeden komentář. Na jeden komentář může upozornit několik připomínek na komunikaci. repliesTo (Comment, Comment) [kompozice 1:M] – Ke komentáři (Comment) může být vloženo několik odpovědí (Comment). Odpověď je vložena na právě jeden komentář. sendsComment (Comment, User) [M:1] – Uživatel (User) může vložit několik komentářů (Comment). Komentář je vložen právě jedním uživatelem. employs (Contact, WorksInCompany, Account) [1:M, N:1] – Jedna osoba (Contact) může mít několik pracovních vztahů (WorksInCompany), pracovní vztah se váže na právě jednu osobu a na právě jednu společnost (Account). Společnost může mít uzavřeno několik pracovních vztahů. hasProducts (Product, PriceListItem, PriceList) [1:M, N:1] – V jednom ceníku (PriceList) může figurovat několik ceníkových položek (PriceListItem), ceníková položka se váže na právě jeden ceník a na právě jeden produkt (Product). Produkt může figurovat v několika cenících. sellsProducts (Product, ProductItem, BusinessCase) [1:M, N:1] – V rámci jednoho obchodního případu (BusinessCase) může být nabízeno několik prodejních položek (ProductItem), prodejní položka se váže na právě jeden obchodní případ a na právě jeden produkt (Product). Produkt může figurovat v několika obchodních případech. 44

3.1. Konceptuální datový model hasEmployees (Client, User) [kompozice 1:M] – Uživatel (User) je pracovníkem právě jednoho klienta (Client). Klient zaměstnává několik pracovníků, kteří pracují se systémem. responsibleFor (Client, User) [0..1:1] – Klient (Client) má právě jednu zodpovědnou osobu (User), která je uživatelem systému. Uživatel může být zodpovědnou osobou pro nejvýše jednoho klienta. hasType (Client, ClientAccountType) [M:1] – Účet klienta (Client) se nachází právě v jednom stavu (ClientAccountType). Stav klientského účtu (aktivován, trial, k aktivaci, deaktivován) může být společný pro několik různých klientů. issuedFor (Client, Invoice) [1:M] – Pro klienta (Client) může být vystaveno několik faktur (Invoice). Každá faktura je vystavena pro právě jednoho klienta. hasAddress (Client, Address) [kompozice 1:1] – Klient (Client) má uvedenu právě jednu adresu (Address). Adresa patří právě jednomu klientovi. hasIndrustryFields (Client, IndustryField) [kompozice 1:M] – Klient (Client) má nadefinováno několik oblastí působení (IndustryField). Oblast působení je definována právě jedním klientem. businessCaseSources (Client, BusinessCaseSource) [kompozice 1:M] – Klient (Client) má nadefinováno několik zdrojů obchodních případů (BusinessCaseSource). Zdroj obchodního případu je definován právě jedním klientem. hasContactCategories (Client, ContactCategory) [kompozice 1:M] – Klient (Client) má nadefinováno několik kategorií kontaktů (ContactCategory). Kategorie kontaktů je definována právě jedním klientem. hasProductCategories (Client, ProductCategory) [kompozice 1:M] – Klient (Client) má nadefinováno několik kategorií produktů (ProductCategory). Kategorie produktů je definována právě jedním klientem. managedBy (Manager, Client) [1:M] – Manažer CRM systému (Manager) je správcem několika klientských účtů (Client). Klientský účet je spravován právě jedním manažerem. hasState (Invoice, InvoiceState) [M:1] – Faktura (Invoice) se nachází v právě jednom stavu (InvoiceState). Stav faktury (nezaplacená, zaplacená) může být společný pro několik různých faktur. hasItems (Invoice, InvoiceItem) [kompozice 1:1..M] – Faktura (Invoice) je vystavena na jednu a více položek (InvoiceItem). Fakturační položka je uvedena na právě jedné faktuře. 45

3. Analýza

3.2

Model případů užití

Model případů užití obsahuje množinou scénářů, které určují typické použití systému uživateli viz Larman [26]. Vedle textových dokumentů může zahrnovat i diagram případů užití v UML, který zobrazuje jména případů užití, aktéry a vztahy mezi nimi. Případ užití je textovým dokumentem, ve kterém je zachycena interakce uživatele a systému. Existují různé formáty, úrovně formality a šablony pro zápis případu užití. Zde je použit plně specifikovaný formát a šablona (viz tabulka B.1), která byla vytvořena na základě široce rozšířené šablony Alistara Cockburna [9]. Způsob hledání, modelování a popisu případů užití vychází z Larmana [26] a Cockburna [9]. Generalizace případů užití vychází z Arlowa a Neustadta [1]. V následujících podkapitolách jsou zobrazeny všechny diagramy případů užití systému. Většina případů užití je podrobně popsána ve scénářích.

Obrázek 3.2: UC model - Aktéři systému

3.2.1

Model aktérů systému

Aktér je jakýkoli subjekt mající nějaké chování včetně systému samotného, který může volat služby jiných systémů viz Larman [26]. Primární a podpůrní aktéři se vyskytují v jednotlivých akcích scénářů případů užití. Aktéři jsou role vyjadřující nejenom osoby, ale i organizace, software a stroje. Na diagramu 3.2 je znázorněn model primárních aktérů systému. Zobrazuje aktéry CRM systému a vztahy mezi nimi. Vztahy jsou vysvětleny přímo u popisu jednotlivých aktérů. V popisu aktérů jsou zahrnuty i zainteresované osoby (podpůrní aktéři). System (Systém) reprezentuje CRM systém. Figuruje jako primární aktér v některých případech užití. Ve stanovený moment spouští určité akce. 46

3.2. Model případů užití AppUser (Obecný uživatel) je obecný uživatel CRM systému (abstraktní aktér), který má vytvořen uživatelský účet, může se přihlásit do CRM systému a účet upravovat. Admin (Administrátor) je administrátorem CRM systému. Má na starosti správu CRM systému a účtů manažerů. Dědí od obecného uživatele všechny role a relace k případům užití. Manager (Manažer) je manažerem CRM systému. Stará se o klienty CRM systému, kontaktuje je, spravuje jejich účty a má možnost editovat jejich faktury. Dědí od obecného uživatele všechny role a relace k případům užití. Visitor (Návštěvník) je návštěvníkem webové prezentace CRM systému a potenciální klientem. CRM systém může vyzkoušet online demo aplikací. Může se registrovat a založit tak nového klienta. Může CRM systém objednat. Automaticky se pak stává zodpovědnou osobou pro nového klienta. Responsible (Zodpovědná osoba) je zaměstnancem klientské společnosti. Zodpovídá za správu uživatelských účtů klienta. Může přidávat nové účty nebo zneplatnit stávající účty. Uživatel, kterému byl zneplatněn účet, nemůže s CRM systémem pracovat. Dědí od uživatele všechny role a relace k případům užití. Klient je zainteresovanou osobou (nepoužívá systém), která reprezentuje klientskou společnost, firmu, organizaci nebo osobu, které je dodáván CRM systém a jsou odesílány faktury za jeho používaní. User (Uživatel) je zaměstnancem klientské společnosti. V systému může zobrazovat a spravovat účty (společnosti), kontakty (osoby), produkty, ceníky, obchodní případy, aktivity apod. Dědí od obecného uživatele všechny role a relace k případům užití.

3.2.2

UC1: CRM Common

Tato část obsahuje popis případů užití, které může vykonávat obecný uživatel systému (pracovník CRM systému nebo uživatel). Skupina případů užití pokrývá obecné operace CRM systému – přihlášení do systému, odhlášení, správu uživatelského účtu apod. Je zobrazena na diagramu případů užití 3.3. 47

3. Analýza

Obrázek 3.3: UC model - UC1: CRM Common Případ užití - UC101: Log in Context of Use: Uživatel chce použít CRM systém a musí se přihlásit. Scope: CRM systém Level: Cíl uživatele Primary actor: Obecný uživatel (AppUser) Stakeholders and Interests: – Obecný uživatel: Chce používat CRM systém. Preconditions: – Success End: Obecný uživatel je přihlášen do CRM systému a může ho používat. Main success scenario: 1. Obecný uživatel chce použít CRM systém. 2. Systém zobrazí formulář pro přihlášení do systému (přihlašovací jméno a heslo). 3. Obecný uživatel zadá přihlašovací údaje (uživatelské jméno a heslo) a zvolí přihlášení do systému. 4. Systém autentizuje uživatele INCLUDE: UC106: Authenticate. 5. Systém zobrazí výchozí obrazovku CRM systému. Alternative flows: 4a. Uživatel nebyl autentizován (špatné přihlašovací údaje). 1. Systém zobrazí uživateli chybou hlášku a nabídne mu možnost obnovy zapomenutých přihlašovacích údajů. 2. Uživatel pokračuje krokem 2 hlavního scénáře. 2a. Uživatel zvolí obnovu přihlašovacích údajů INCUDE: UC105: Reset forgotten login information. Special Requirements: Uživatel přistupuje k systému přes webový prohlížeč. Frequency of Occurrence: Často – kdykoli chce kterýkoli uživatel spustit CRM systém.

48

3.2. Model případů užití Případ užití - UC102: Log out Context of Use: Obecný uživatel je přihlášen do CRM systému a chce se odhlásit. Scope: CRM systém Level: Cíl uživatele Primary actor: Obecný uživatel (AppUser) Stakeholders and Interests: – Obecný uživatel: Chce bezpečně ukončit práci s CRM systémem. Preconditions: Uživatel je autentizován a přihlášen. Success End: Obecný uživatel je odhlášen z CRM systému. Main success scenario: 1. Obecný uživatel chce ukončit práci s CRM systémem. 2. Obecný uživatel vyvolá akci pro odhlášení. 3. Systém odhlásí uživatele ze systému. 4. Systém zobrazí obrazovku s informací o úspěšném odhlášení. Alternative flows: – Frequency of Occurrence: Často – kdykoli se chce kterýkoli uživatel odhlásit ze systému.

Případ užití - UC103: Manage user profile Context of Use: Obecný uživatel chce upravit svůj uživatelský účet. Scope: CRM systém Level: Cíl uživatele Primary actor: Obecný uživatel (AppUser) Stakeholders and Interests: – Obecný uživatel: Chce aktualizovat záznamy svého uživatelského účtu. – Ostatní uživatelé systému: Chtějí znát aktuální informace o uživateli. Preconditions: Uživatel je autentizován a přihlášen. Success End: Uživatelský účet obecného uživatele je upraven. Main success scenario: 1. Obecný uživatel chce upravit svůj uživatelský účet. 2. Obecný uživatel zobrazí detail svého uživatelského účtu. 3. Systém zobrazí informace o uživatelském účtu – jméno uživatele, příjmení, email, přihlašovací jméno a jazyk. Vše kromě přihlašovacího jména může uživatel editovat. Systém zobrazí možnost změny přihlašovacího hesla. 4. Obecný uživatel upraví nějaký záznam (jméno, příjmení, email nebo jazyk). 5. Systém upozorní uživatele, že upravil záznamy a měl by uložit provedené změny. Obecný uživatel opakuje krok 4 do té doby, než provede všechny požadované změny. 6. Obecný uživatel zvolí akci pro uložení změn. 7. Systém zkontroluje validitu záznamů a uloží změny do systému. Alternative flows: *a. Kdykoli se může uživatel odhlásit ze systému: 1. Uživatel zvolí odhlášení ze systému. 2. IF odhlášení po kroku 4 z hlavního scénáře THEN systém pokračuje krokem *b. 3. Systém odhlásí uživatele INCLUDE: UC102: Log out. *b. Uživatel chce opustit obrazovku. 1. IF uživatel se snaží opustit obrazovku po kroku 4 z hlavního scénáře THEN systém upozorní uživatele, že se pokouší opustit obrazovku a neuložil provedené změny. 2. Uživatel pokračuje krokem 6 hlavního scénáře. 2a. Uživatel nechce změny uložit, ignoruje upozornění.

49

3. Analýza 3. Systém přejde na jinou obrazovku. 4a. Obecný uživatel zvolí změnu přihlašovacího hesla. 1. Systém zobrazí formulář pro změnu hesla (staré heslo, nové heslo, potvrzení nového hesla). 2. Uživatel vyplní formulář pro změnu hesla. 3. Uživatel zvolí akci pro potvrzení změny hesla. 3a. Uživatel zvolí akci pro zrušení změny hesla. 1. Systém pokračuje krokem 3 z hlavního scénáře. 4. Systém ověří správnost starého hesla, splnění bezpečnostní politiky pro nové heslo a ověří shodnost nového hesla s jeho potvrzením. 4a. Uživatel zadal nesprávné staré heslo, jeho nové heslo nesplňuje bezpečnostní požadavky nebo se nové heslo neshoduje s jeho potvrzením. 1. Systém upozorní uživatele na problém, který nastal. 2. Uživatel pokračuje krokem 4a. 5. Systém uloží nové heslo. 7a. Uživatel zadal nevalidní data. 1. Systém upozorní na nevalidní data, která byla zadána uživatelem. 2. Uživatel pokračuje krokem 4 hlavního scénáře. Frequency of Occurrence: Málo – uživatel upravuje svůj profil velmi zřídka.

Případ užití - UC105: Reset forgotten login information Context of Use: Uživatel se nemůže přihlásit do systému, chce změnit přihlašovací údaje. Scope: CRM systém Level: Cíl uživatele Primary actor: Obecný uživatel (AppUser) Stakeholders and Interests: – Obecný uživatel: Zapomněl své přihlašovací údaje, potřebuje je změnit a přihlásit se do systému pomocí nových. Preconditions: – Success End: Obecný uživatel si změnil přihlašovací údaje. Main success scenario: 1. Obecný uživatel chce změnit přihlašovací údaje do systému. 2. Systém zobrazí formulář pro obnovu přihlašovacích údajů (email, přihlašovací jméno). 3. Obecný uživatel zadá email, na který mu má být odesláno nové heslo a zvolí akci obnovu přihlašovacích údajů. 4. Systém vyhledá uživatelský účet se zadaným emailem, vygeneruje pro něj nové heslo a heslo uloží. 5. Systém odešle na email uživatele přihlašovací údaje do systému. 6. Systém informuje uživatele, že mu byly odeslány přihlašovací údaje na email. Alternative flows: 3a. Uživatel chce obnovit heslo zadáním přihlašovacího jména. 1. Uživatel zadá přihlašovací jméno a zvolí akci obnovu přihlašovacích údajů.. 2. Systém vyhledá uživatele se zadaným přihlašovacím jménem, vygeneruje pro něj nové heslo a heslo uloží. 2a. Přihlašovací jméno, které uživatel zadal, systém nenalezl. 1. Systém upozorní uživatele, že nenalezl uživatele s daným přihlašovacím jménem. 2. Uživatel pokračuje krokem 2 z hlavního scénáře. 3. Systém odešle na email uživatele nové heslo k přihlášení do systému. 4. Systém informuje uživatele, že mu bylo odesláno přihlašovací heslo na email (zobrazí pouze část emailové adresy). 4a. Uživatelský účet, který má email odpovídající tomu, jež zadal uživatel, nenalezen.

50

3.2. Model případů užití 1. Systém upozorní uživatele, že nenalezl uživatele s daným emailem. 2. Uživatel pokračuje krokem 2 z hlavního scénáře. Frequency of Occurrence: Málo – uživatel obnovuje přihlašovací údaje velmi zřídka.

Případ užití - UC106: Authenticate Context of Use: Systém obdržel přihlašovací údaje uživatele a autentizuje podle nich uživatele. Scope: CRM systém Level: Funkce Primary actor: Systém Stakeholders and Interests: – Obecný uživatel: Chce se přihlásit do CRM systému z nějakého zařízení. Preconditions: – Success End: Úspěšná autentizace do systému. Main success scenario: 1. Systém chce autentizovat uživatele. 2. Systém vyhledá uživatele podle přihlašovacího jména. 3. Systém ověří, zda přihlašovací heslo odpovídá tomu, které má nastaveno uživatel na svém účtu. 4. Systém informuje o úspěšném pokusu o přihlášení. Alternative flows: 2a. Uživatel nebyl nalezen. 1. Systém vrátí chybu při pokusu o autentizaci. 3a. Hesla si neodpovídají. 1. Systém vrátí chybu při pokusu o autentizaci. Frequency of Occurrence: Často – kdykoli chce kterýkoli uživatel spustit CRM systém.

Případ užití - UC104: Generate sample records for CRM demo Context of Use: Systém ve stanovený čas spustí úlohu, která nahraje vzorová data do demo instance CRM systému. Scope: CRM systém Level: Funkce Primary actor: Systém Stakeholders and Interests: – Návštěvník: Chce si prohlédnout a vyzkoušet demo aplikaci, která se tváří jako skutečná aplikace v níž jsou nahrána data, se kterými může manipulovat. – Poskytovatel CRM systému: Chce získat nové zákazníky tím, že jim umožní vyzkoušení funkční CRM aplikace, ve které jsou vzorová data. Preconditions: – Success End: Vzorová data jsou úspěšně vložena do demo instance. Trigger: Systém spouští scénář jedenkrát denně ve 4:00. Main success scenario: 1. Systém chce nahrát vzorová data do systému. 2. Systém nahraje vzorová data data do demo instance. 3. Systém informuje administrátora CRM systému o úspěšném nahrání vzorových dat odesláním zprávy na jeho email. Alternative flows:

51

3. Analýza 2a. Při nahrávání se vyskytne chyba. 1. Systém odešle zprávu o neúspěšném nahrání vzorových dat administrátorovi a popíše v ní chybu, která se vyskytla. Frequency of Occurrence: Málo – jedenkrát denně.

3.2.3

UC2: Web presentation

Tato část obsahuje popis případů užití, které může spustit návštěvník, který se pohybuje ve webové prezentaci CRM systému – vyzkoušení CRM aplikace, registrace do systému a jeho objednání. Skupina případů užití je zobrazena na diagramu případů užití 3.4.

Obrázek 3.4: UC model - UC2: Web presentation Případ užití - UC201: Try CRM demo Context of Use: Návštěvník webové prezentace chce vyzkoušet CRM aplikaci. Scope: Webová prezentace Level: Cíl uživatele Primary actor: Návštěvník Stakeholders and Interests: – Návštěvník: Chce si prohlédnout a vyzkoušet demo CRM aplikace. – Poskytovatel CRM systému: Chce získat nové zákazníky tím, že jim umožní vyzkoušení funkční CRM aplikace. Preconditions: – Success End: Návštěvník si vyzkoušel demo CRM aplikace. Main success scenario: 1. Návštěvník chce vyzkoušet demo CRM aplikace. 2. Návštěvník spustí akci pro vyzkoušení demo CRM aplikace. 3. Systém zobrazí předvyplněný formulář přihlášení do systému (zadáno je přihlašovací jméno a heslo). 4. Návštěvník se přihlásí do demo CRM aplikace.

52

3.2. Model případů užití 5. Systém zvolí náhodného uživatele demo CRM aplikace a přihlásí návštěvníka do aplikace pod jeho účtem. 6. Systém zobrazí úvodní obrazovku CRM aplikace. Návštěvník pracuje se systémem v roli uživatel. 7. Návštěvník se odhlásí ze systému INCLUDE UC102: Log out. Alternative flows: – Frequency of Occurrence: Málo – frekvence závisí na počtu návštěvníků webové prezentace.

Případ užití - UC202: Order CRM Context of Use: Návštěvník webové prezentace chce objednat CRM aplikaci. Scope: Webová prezentace Level: Cíl uživatele Primary actor: Návštěvník, Zodpovědná osoba Stakeholders and Interests: – Návštěvník: Chce objednat CRM aplikaci. – Poskytovatel CRM systému: Chce získat nového zákazníka. Preconditions: – Success End: Návštěvník si objednal CRM aplikaci. Main success scenario: 1. Návštěvník chce objednat CRM aplikaci. 2. Návštěvník spustí akci pro objednání CRM aplikace. 3. Systém zobrazí formulář pro objednání CRM aplikace (počet uživatelských účtů). 4. Návštěvník vyplní formulář a potvrdí objednávku. 5. Systém vyzve uživatele k přihlášení do systému a nabídne i možnost pro zaregistrování se jako nového klienta. 6. Návštěvník zvolí přihlášení do systému INCLUDE UC101: Log in. Návštěvník se přihlásil v roli zodpovědná osoba. 7. Systém rekapituluje objednávku a dotáže se, zda chce zodpovědná osoba potvrdit objednání CRM aplikace. 8. Zodpovědná osoba potvrdí objednávku. 9. Systém nastaví účet klienta (limit počtu uživatelů) podle objednávky a aktivuje pro něj CRM aplikaci (typ účtu „aktivní“). 10. Systém informuje zodpovědnou osobu u úspěšném objednání CRM aplikace. Alternative flows: 4a. Návštěvník chce zrušit objednání CRM systému. 1. Systém zruší proces objednávky. 5a. Návštěvník se chce zaregistrovat jako nový klient. 1. Návštěvník zvolí registraci do systému INCLUDE UC203: Register as a new client. 2. IF návštěvník není přihlášen THEN systém vyzve návštěvníka pro přihlášení do systému INCLUDE UC101: Log in. 3. Systém pokračuje krokem 7 z hlavního scénáře. 6a. Návštěvník se přihlásil do systému v roli uživatel. 1. Systém upozorní uživatele, že není oprávněn pro objednání CRM aplikace. 2. Systém zruší proces objednávky. 6b. Návštěvník se nepřihlásil do systému. 1. Návštěvník pokračuje krokem 5 z hlavního scénáře. 8a. Zodpovědná osoba zruší objednávku. 1. Zodpovědná osoba zvolí akci pro zrušení objednávky.

53

3. Analýza 2. Systém zruší proces objednávky. 8b. Zodpovědná osoba se odhlásila ze systému. 1. Systém zruší proces objednávky. Frequency of Occurrence: Málo – nový klient objednává CRM aplikaci zřídka.

Případ užití - UC203: Register as a new client Context of Use: Návštěvník webové prezentace chce zaregistrovat svoji společnost do systému. Scope: Webová prezentace Level: Cíl uživatele Primary actor: Návštěvník Stakeholders and Interests: – Návštěvník: Chce registrovat svou společnost do systému. Vytvoří se klientský účet a návštěvník, který provádí registraci se stane zodpovědnou osobou za klientskou společnost. – Poskytovatel CRM systému: Chce získat nové zákazníky. Preconditions: – Success End: Návštěvník registroval svoji společnost do systému a je její zodpovědnou osobou. Main success scenario: 1. Návštěvník chce zaregistrovat svoji společnost. 2. Návštěvník spustí akci pro registraci do systému. 3. Systém zobrazí registrační formulář (název společnosti, email, telefonní kontakt, web a jméno návštěvníka, příjmení, email, přihlašovací údaje). 4. Návštěvník vyplní registrační formulář a potvrdí registraci. 5. Systém zkontroluje validitu zadaných údajů, registruje nového klienta na základě dat z formuláře (nastaví typ účtu na „k aktivaci“), vytvoří nový uživatelský účet pro návštěvníka a nastaví mu roli zodpovědná osoba. 6. Systém odešle zprávu o registraci na email zodpovědné osoby a vyzve zodpovědnou osobu k dokončení registrace čtením zprávy v emailu. Návštěvník přečte email a vyvolá akci pro aktivaci účtu. 7. Systém aktivuje účet klienta, nastaví jeho typ na „trial“, limit počtu uživatelů na čtyři a nastaví třicetidenní limit na vyzkoušení CRM aplikace. 8. Systém odešle zprávu o úspěšné aktivaci na email zodpovědné osoby. 9. Systém informuje návštěvníka o úspěšném dokončení registrace a nabídne mu možnost přihlášení do CRM aplikace. 10. EXTEND UC101: Log in IF návštěvník se chce přihlásit do systému. Alternative flows: 5a. Návštěvník zadal ve formuláři nevalidní data. 1. Systém upozorní návštěvníka na nevalidní data, která zadal. 2. Návštěvník pokračuje krokem 4 z hlavního scénáře. Frequency of Occurrence: Málo – frekvence závisí na počtu návštěvníků webové prezentace.

3.2.4

UC3: Front office

Tato část obsahuje popis případů užití, které vykonávají pracovníci CRM systému (manažeři a administrátoři). Skupina případů užití pokrývá operace z 54

3.2. Model případů užití části Front office – správu klientů, vystavování a správu fakturu apod. Je zobrazena na diagramu případů užití 3.5.

Obrázek 3.5: UC model - UC3: Front office

Případ užití - UC301: Manage manager Context of Use: Administrátor CRM systému chce spravovat účty manažerů. Scope: Front office Level: Cíl uživatele Primary actor: Administrátor Stakeholders and Interests: – Administrátor: Chce spravovat účty manažerů – zobrazit seznam účtů, přidat nový, upravit stávající, deaktivovat účet. Preconditions: Uživatel je autentizován a přihlášen. Success End: Administrátor upravil účet manažera. Main success scenario: 1. Administrátor chce upravit účet manažera. 2. Administrátor spustí akci pro zobrazení seznamu manažerů. 3. Systém zobrazí seznam manažerů CRM systému, možnost pro řazení a filtrování tohoto seznamu (podle jména), možnost pro přechod na detail manažera a možnost pro přidání nového manažera. 4. Administrátor zvolí akci pro přechod na detail vybraného manažera. 5. Systém zobrazí detailní informace o zvoleném manažerovi – jméno, příjmení, přihlašovací jméno, email, stav jeho účtu, seznam jeho klientů. Administrátor může editovat pouze email nebo stav jeho účtu (povolen, blokován). 6. Administrátor upraví nějaký záznam (email, stav účtu). 7. Systém upozorní uživatele, že upravil záznamy a měl by uložit provedené změny. Administrátor opakuje krok 6 do té doby, než provede všechny požadované změny. 8. Administrátor zvolí akci pro uložení změn. 9. Systém zkontroluje validitu záznamů, uloží změny a informuje o úspěšném uložení.

55

3. Analýza

Alternative flows: *a. Kdykoli se může uživatel odhlásit ze systému: 1. Uživatel zvolí odhlášení ze systému. 2. IF odhlášení po kroku 6 z hlavního scénáře THEN systém pokračuje krokem *b. 3. Systém odhlásí uživatele INCLUDE: UC102: Log out. *b. Uživatel chce opustit obrazovku. 1. IF uživatel se snaží opustit obrazovku po kroku 6 z hlavního scénáře THEN systém upozorní uživatele, že se pokouší opustit obrazovku a neuložil provedené změny. 2. Uživatel pokračuje krokem 8 hlavního scénáře. 2a. Uživatel nechce změny uložit, ignoruje upozornění. 3. Systém přejde na jinou obrazovku. 4a. Uživatel chce seřadit data v seznamu manažerů. 1. Uživatel zvolí akci pro seřazení seznamu podle vybraného sloupce (jméno, příjmení). 2. Systém seřadí seznam. 3. Systém pokračuje krokem 3 hlavního scénáře. 4b. Uživatel chce filtrovat data v seznamu manažerů. 1. Uživatel zvolí akci pro filtrování seznamu podle vybraného sloupce (jméno, příjmení). 2. Systém aplikuje filtr na seznam. 3. Systém pokračuje krokem 3 hlavního scénáře. 4c. Uživatel chce přidat nového manažera. 1. Uživatel zvolí akci pro přidání nového manažera. 2. Systém zobrazí formulář pro přidání nového manažera, ve kterém může uživatel vyplnit jméno, příjmení, email, přihlašovací jméno a jazyk. 3. Uživatel vyplní formulář a potvrdí přidání nového manažera. 3a. Uživatel chce zrušit přidání nového manažera. 1. Uživatel zvolí akci pro zrušení přidání nového manažera. 2. Systém pokračuje krokem 3 z hlavního scénáře. 4. Systém zkontroluje validitu záznamů, vytvoří nového manažera podle zadaných dat z formuláře, povolí jeho účet, vygeneruje přihlašovací heslo, uloží ho a informuje uživatele o úspěšném uložení záznamů. 4a. Uživatel zadal nevalidní data nebo nezadal všechna povinná data. 1. Systém upozorní uživatele na povinná nebo nevalidní data, která zadal. 2. Systém pokračuje krokem 4c.2 z alternativního scénáře. 5. Systém odešle na zadaný email manažera pozvánku do aplikace s přihlašovacími údaji. 6. Systém pokračuje krokem 3 hlavního scénáře. 8a. Uživatel chce zrušit úpravu záznamů manažera. 1. Uživatel zvolí akci pro zrušení úpravy záznamů manažera. 2. Systém pokračuje krokem 3 hlavního scénáře. 9a. Uživatel zadal nevalidní data. 1. Systém upozorní uživatele na nevalidní data, která zadal. 2. Uživatel pokračuje krokem 6 hlavního scénáře. Frequency of Occurrence: Málo – administrátor nespravuje účty manažerů často.

Případ užití - UC303: Manage CRM service price Context of Use: Administrátor CRM systému chce změnit cenu za měsíční použití CRM služeb jedním uživatelem. Scope: Front office Level: Cíl uživatele Primary actor: Administrátor Stakeholders and Interests: – Uživatel: Chce znát aktuální cenu za použití CRM služeb. – Administrátor: Chce změnit cenu za použití CRM služeb.

56

3.2. Model případů užití – Poskytovatel CRM systému: Chce změnit cenu za použití CRM služeb. Preconditions: Uživatel je autentizován a přihlášen. Success End: Administrátor změnil cenu za měsíční používání CRM služeb. Main success scenario: 1. Administrátor chce změnit měsíční cenu za použití CRM služeb. 2. Administrátor spustí akci pro správu ceny za CRM služby. 3. Systém zobrazí měsíční cenu za použití CRM služeb a měnu ceny. Administrátor může oba záznamy editovat. 4. Administrátor upraví nějaký záznam (cenu, měnu). 5. Systém upozorní uživatele, že upravil záznamy a měl by uložit provedené změny. Administrátor opakuje krok 4 do té doby, než provede všechny požadované změny. 6. Administrátor zvolí akci pro uložení změn. 7. Systém zkontroluje validitu záznamů, uloží změny a informuje o úspěšném uložení. Alternative flows: *a. Kdykoli se může uživatel odhlásit ze systému: 1. Uživatel zvolí odhlášení ze systému. 2. IF odhlášení po kroku 4 z hlavního scénáře THEN systém pokračuje krokem *b. 3. Systém odhlásí uživatele INCLUDE: UC102: Log out. *b. Uživatel chce opustit obrazovku. 1. IF uživatel se snaží opustit obrazovku po kroku 4 z hlavního scénáře THEN systém upozorní uživatele, že se pokouší opustit obrazovku a neuložil provedené změny. 2. Uživatel pokračuje krokem 6 hlavního scénáře. 2a. Uživatel nechce změny uložit, ignoruje upozornění. 3. Systém přejde na jinou obrazovku. 7a. Uživatel zadal nevalidní data. 1. Systém upozorní uživatele na nevalidní data, která zadal. 2. Uživatel pokračuje krokem 4 hlavního scénáře. Frequency of Occurrence: Málo – cena služeb se bude měnit méně než jedenkrát ročně.

Případ užití - UC311: Manage client Context of Use: Manažer CRM systému spravuje účty klientů. Scope: Front office Level: Cíl uživatele Primary actor: Manažer Stakeholders and Interests: – Manažer: Chce spravovat účty klientů – zobrazit seznam klientů, přidat nového, upravit stávající, deaktivovat klienta. – Klient: Chce aby mu byl vytvořen nebo upraven účet. – Poskytovatel CRM systému: Chce získat nového klienta a mít aktuální data o klientech. Preconditions: Uživatel je autentizován a přihlášen. Success End: Manažer upravil účet klienta. Main success scenario: 1. Manažer chce upravit účet klienta. 2. Manažer spustí akci pro zobrazení seznamu klientů. 3. Systém zobrazí seznam klientů, možnost pro řazení a filtrování tohoto seznamu (podle názvu, adresy, zodpovědné osoby a počtu uživatelů), možnost pro přechod na detail klienta a možnost pro přidání nového klienta. 4. Manažer zvolí akci pro přechod na detail vybraného klienta.

57

3. Analýza 5. Systém zobrazí detailní informace o zvoleném klientovi – název, identifikační číslo, typ účtu, email, max. a skutečný počet uživatelů, telefonní kontakt, adresu, zodpovědnou osobu, seznam jeho uživatelů apod. Manažer může editovat všechny tyto záznamy. 6. Manažer upraví nějaký záznam. 7. Systém upozorní uživatele, že upravil záznamy a měl by uložit provedené změny. Manažer opakuje krok 6 do té doby, než provede všechny požadované změny. 8. Manažer zvolí akci pro uložení změn. 9. Systém zkontroluje validitu záznamů, uloží změny a informuje o úspěšném uložení. Alternative flows: *a. Kdykoli se může uživatel odhlásit ze systému: 1. Uživatel zvolí odhlášení ze systému. 2. IF odhlášení po kroku 6 z hlavního scénáře THEN systém pokračuje krokem *b. 3. Systém odhlásí uživatele INCLUDE: UC102: Log out. *b. Uživatel chce opustit obrazovku. 1. IF uživatel se snaží opustit obrazovku po kroku 6 z hlavního scénáře THEN systém upozorní uživatele, že se pokouší opustit obrazovku a neuložil provedené změny. 2. Uživatel pokračuje krokem 8 hlavního scénáře. 2a. Uživatel nechce změny uložit, ignoruje upozornění. 3. Systém přejde na jinou obrazovku. 4a. Uživatel chce seřadit data v seznamu klientů. 1. Uživatel zvolí akci pro seřazení seznamu podle vybraného sloupce (název, adresa). 2. Systém seřadí seznam. 3. Systém pokračuje krokem 3 hlavního scénáře. 4b. Uživatel chce filtrovat data v seznamu klientů. 1. Uživatel zvolí akci pro filtrování seznamu podle vybraného sloupce (název, adresa). 2. Systém aplikuje filtr na seznam. 3. Systém pokračuje krokem 3 hlavního scénáře. 4c. Uživatel chce přidat nového klienta. 1. Uživatel zvolí akci pro přidání nového klienta. 2. Systém zobrazí formulář pro přidání nového klienta a jeho zodpovědné osoby, ve kterém může uživatel vyplnit název, adresu, kontaktní informace, max. počet uživatelů, typ účtu klienta a jméno, příjmení, email, uživatelské jméno zodpovědné osoby. 3. Uživatel vyplní formulář a potvrdí přidání nového klienta a zodpovědné osoby. 3a. Uživatel chce zrušit přidání nového klienta. 1. Uživatel zvolí akci pro zrušení přidání nového klienta. 2. Systém pokračuje krokem 3 z hlavního scénáře. 4. Systém zkontroluje validitu záznamů, vytvoří nového klienta a zodpovědnou osobu podle zadaných dat z formuláře, vygeneruje přihlašovací heslo pro účet zodpovědné osoby, uloží ho. 4a. Uživatel zadal nevalidní data nebo nezadal všechna povinná data. 1. Systém upozorní uživatele na povinná nebo nevalidní data, která zadal. 2. Systém pokračuje krokem 4c.2 z alternativního scénáře. 5. Systém odešle na email zodpovědné osoby pozvánku do aplikace s přihlašovacími údaji. 6. Systém informuje uživatele o úspěšném uložení záznamů. 7. Systém pokračuje krokem 3 hlavního scénáře. 8a. Uživatel chce zrušit úpravu záznamů klienta. 1. Uživatel zvolí akci pro zrušení úpravy záznamů klienta. 2. Systém pokračuje krokem 3 hlavního scénáře. 9a. Uživatel zadal nevalidní data. 1. Systém upozorní uživatele na nevalidní data, která zadal. 2. Uživatel pokračuje krokem 6 hlavního scénáře. Frequency of Occurrence: Často – správa klientů je hlavní aktivitou manažerů.

58

3.2. Model případů užití Případ užití - UC313: Send invoices Context of Use: Systém vygeneruje pro každého klienta fakturu za používání CRM služeb a odešle ji klientům na email. Scope: Front office Level: Funkce Primary actor: Systém Stakeholders and Interests: – Klient: Chce obdržet měsíční vyúčtování a fakturu za konzumované služby CRM systému. – Poskytovatel CRM systému: Chce pro každého klienta vystavit měsíční fakturu za poskytované CRM služby. – Systém: Chce zkompletovat a odeslat faktury pro všechny klienty. Preconditions: – Success End: Systém zkompletoval a odeslal faktury za používání CRM služeb všem klientům CRM systému. Trigger: Systém spouští scénář jedenkrát za měsíc, vždy pátý den v měsíci v 5:00. Main success scenario: 1. Systém chce zkompletovat a odeslat faktury klientům. 2. Systém vypočte částku za měsíční používání CRM služeb pro klienta INCLUDE UC314: Calculate month price for services. 3. Systém sestaví měsíční fakturu pro klienta, která obsahuje číslo faktury, datum splatnosti a vystavení, částku za služby, fakturované položky a údaje o poskytovateli CRM služeb a klientovi (fakturační adresa apod.). 4. Systém odešle fakturu na email klienta a jeho zodpovědné osoby. Systém opakuje kroky 2 až 4 pro všechny klienty CRM systému. Alternative flows: – Frequency of Occurrence: Málo – jedenkrát měsíčně.

Případ užití - UC314: Calculate month price for services Context of Use: Systém vypočítá částku za měsíční používání CRM služeb pro zvoleného klienta. Scope: Front office Level: Funkce Primary actor: Systém Stakeholders and Interests: – Klient: Chce na faktuře obdržet správnou částku za používání CRM služeb. – Poskytovatel CRM systému: Chce, aby byly uvedeny správné částky na fakturách vystavených klientům. – Systém: Chce správně spočítat částku za měsíční používání CRM služeb klientem. Preconditions: – Success End: Systém spočítal částku za měsíční používání CRM služeb klientem. Main success scenario: 1. Systém chce spočítat částku za měsíční používání CRM služeb pro zvoleného klienta. 2. Systém vynásobí aktuální počet uživatelů klienta měsíční cenou za použití CRM služeb. 3. Systém vrátí výsledek výpočtu. Alternative flows: – Frequency of Occurrence: Málo – při odesílání faktur klientům a při správě faktur klientů.

59

3. Analýza

3.2.5

UC4: CRM Business Operations

Tato část obsahuje popis případů užití, které vykonávají pracovníci klienta CRM systému (uživatelé a zodpovědné osoby). Skupina případů užití pokrývá stěžejní operace CRM aplikace – správu obchodních entit (účtů, kontaktů, produktů, obchodních případů, aktivit, ceníků), zobrazení reportů apod. Je zobrazena na diagramu případů užití 3.6.

Obrázek 3.6: UC model - UC4: CRM Business Operations Abstraktní případ užití - UC450: Manage business entity Context of Use: Uživatel spravuje obchodní entitu (účet, kontakt, produkt, obchodní případ, aktivitu nebo ceník), může zobrazit seznam všech entit daného typu, entity upravovat, přidávat, komentovat apod. Scope: CRM aplikace Level: Cíl uživatele Primary actor: Uživatel Stakeholders and Interests: – Uživatel: Chce spravovat obchodní entity (účty, kontakty, produkty, obchodní případy, aktivity nebo ceníky), zobrazovat jejich seznamy, upravovat je a přidávat nové. Preconditions: Uživatel je autentizován a přihlášen. Success End: Uživatel upravil obchodní entitu. Main success scenario: 1. Uživatel chce upravit obchodní entitu. 2. Uživatel spustí akci pro zobrazení seznamu obchodních entit.

60

3.2. Model případů užití 3. Systém zobrazí seznam obchodních entit, možnost pro řazení a filtrování tohoto seznamu, možnost pro přechod na detail entity a možnost pro přidání nové entity. 4. Uživatel zvolí akci pro přechod na detail zvolené entity. 5. Systém zobrazí detailní informace o zvolené entitě, komentáře a vazby na další entity. Uživatel může editovat záznamy, komentovat entitu a zobrazit vazby na další entity. 6. Uživatel upraví nějaký záznam. 7. Systém upozorní uživatele, že upravil záznamy a měl by uložit provedené změny. Uživatel opakuje krok 6 do té doby, než provede všechny požadované změny. 8. Uživatel zvolí akci pro uložení změn. 9. Systém zkontroluje validitu záznamů, uloží změny a informuje o úspěšném uložení. Alternative flows: *a. Kdykoli se může uživatel odhlásit ze systému: 1. Uživatel zvolí odhlášení ze systému. 2. IF odhlášení po kroku 6 z hlavního scénáře THEN systém pokračuje krokem *b. 3. Systém odhlásí uživatele INCLUDE: UC102: Log out. *b. Uživatel chce opustit obrazovku. 1. IF uživatel se snaží opustit obrazovku po kroku 6 z hlavního scénáře THEN systém upozorní uživatele, že se pokouší opustit obrazovku a neuložil provedené změny. 2. Uživatel pokračuje krokem 8 hlavního scénáře. 2a. Uživatel nechce změny uložit, ignoruje upozornění. 3. Systém přejde na jinou obrazovku. 4a. Uživatel chce seřadit data v seznamu entit. 1. Uživatel zvolí akci pro seřazení seznamu podle vybraného sloupce. 2. Systém seřadí seznam. 3. Systém pokračuje krokem 3 hlavního scénáře. 4b. Uživatel chce filtrovat data v seznamu entit. 1. Uživatel zvolí akci pro filtrování seznamu podle vybraného sloupce. 2. Systém aplikuje filtr na seznam. 3. Systém pokračuje krokem 3 hlavního scénáře. 4c. Uživatel chce přidat novou entitu. 1. Uživatel zvolí akci pro přidání nové entity. 2. Systém zobrazí formulář pro přidání nové entity. 3. Uživatel vyplní formulář a potvrdí přidání nové entity. 3a. Uživatel chce zrušit přidání nové entity. 1. Uživatel zvolí akci pro zrušení přidání nové entity. 2. Systém pokračuje krokem 3 z hlavního scénáře. 4. Systém zkontroluje validitu záznamů, vytvoří novou entitu. 4a. Uživatel zadal nevalidní data nebo nezadal všechna povinná data. 1. Systém upozorní uživatele na povinná nebo nevalidní data, která zadal. 2. Systém pokračuje krokem 4c.2 z alternativního scénáře. 5. Systém informuje uživatele o úspěšném uložení záznamů. 6. Systém pokračuje krokem 3 hlavního scénáře. 6a. Uživatel chce přidat komentář INCLUDE UC451: Comment business entity. 6b. Uživatel chce zobrazit vazby na další entity INCLUDE UC453: Show connections. 6c. Uživatel chce zobrazit nápovědu k entitě INCLUDE UC452: Show business entity help. 8a. Uživatel chce zrušit úpravu záznamů entity. 1. Uživatel zvolí akci pro zrušení úpravy záznamů entity. 2. Systém pokračuje krokem 3 hlavního scénáře. 9a. Uživatel zadal nevalidní data. 1. Systém upozorní uživatele na nevalidní data, která zadal. 2. Uživatel pokračuje krokem 6 hlavního scénáře.

61

3. Analýza Frequency of Occurrence: Velmi často – tento případ užití se vyskytuje nejčastěji, několikrát denně ho spouští většina uživatelů CRM aplikace.

Případ užití - UC401: Manage account Parent: UC450: Manage business entity Context of Use: Uživatel spravuje účet (společnost, firmu), může zobrazit seznam všech účtů, účty upravovat, přidávat, komentovat apod. Scope: CRM aplikace Level: Cíl uživatele Primary actor: Uživatel Stakeholders and Interests: – Uživatel: Chce spravovat účty, zobrazovat seznam účtů, upravovat účty a přidávat nové. Preconditions: Uživatel je autentizován a přihlášen. Success End: Uživatel upravil účet. Main success scenario: 1. (o1.) Uživatel chce upravit účet. 2. (o2.) Uživatel spustí akci pro zobrazení seznamu účtů. 3. (o3.) Systém zobrazí seznam účtů, možnost pro řazení a filtrování tohoto seznamu (podle názvu, vlastníka, stavu, typu, adresy atd.), možnost pro přechod na detail účtu a možnost pro přidání nového účtu. 4. (o4.) Uživatel zvolí akci pro přechod na detail zvoleného účtu. 5. (o5.) Systém zobrazí detailní informace o zvoleném účtu (název, kontaktní informace, stav, typ, zaměření, vlastníka), seznam zaměstnanců, komentáře a vazby na další entity (obchodní případy, kontakty, aktivity). Uživatel může editovat záznamy, spravovat zaměstnance, přidat komentář k účtu a zobrazit vazby na další entity. 6. (6.) Uživatel upraví nějaký záznam. 7. (7.) Systém upozorní uživatele, že upravil záznamy a měl by uložit provedené změny. Uživatel opakuje krok 6 do té doby, než provede všechny požadované změny. 8. (8.) Uživatel zvolí akci pro uložení změn. 9. (9.) Systém zkontroluje validitu záznamů, uloží změny a informuje o úspěšném uložení. Alternative flows: *a. (*a.) Kdykoli se může uživatel odhlásit ze systému. *b. (*b.) Uživatel chce opustit obrazovku. 4a. (o4a.) Uživatel chce seřadit data v seznamu účtů. 4b. (o4b.) Uživatel chce filtrovat data v seznamu účtů. 4c. (o4c.) Uživatel chce přidat nový účet (ve formuláři v podkroku 2 může vyplnit název účtu, typ, stav, zaměření, kontaktní údaje atd.). 6a. (6a.) Uživatel chce přidat komentář INCLUDE UC451: Comment business entity. 6b. (6b.) Už. chce zobrazit vazby na další entity INCLUDE UC453: Show connections. 6c. (6c.) Už. chce zobrazit nápovědu k entitě INCLUDE UC452: Show business entity help. 6d. Uživatel chce spravovat zaměstnance (kontakty) přiřazené k účtu. 1. Uživatel zvolí přidání zaměstnance (kontaktu). 1a. Uživatel chce odebrat zaměstnance. 1. Uživatel zvolí odebraní zaměstnance. 2. Systém zruší zaměstnanecký vztah a informuje o tom uživatele. 3. Systém pokračuje krokem 5 hlavního scénáře. 2. Systém zobrazí seznam kontaktů (osob). 3. Uživatel vybere kontakt a nastaví její zaměstnanecký vztah k účtu (společnosti). 4. Systém uloží zaměstnanecký vztah a informuje o tom uživatele. 5. Systém pokračuje krokem 5 hlavního scénáře. 8a. (o8a.) Uživatel chce zrušit úpravu záznamů účtu.

62

3.2. Model případů užití 9a. (9a.) Uživatel zadal nevalidní data. Frequency of Occurrence: Velmi často – tento případ užití spouští několikrát denně většina uživatelů CRM aplikace.

Případ užití - UC404: Manage business case Parent: UC450: Manage business entity Context of Use: Uživatel spravuje obchodní případ, může zobrazit seznam všech o. p., upravit nějaký, přidat nový, okomentovat apod. Scope: CRM aplikace Level: Cíl uživatele Primary actor: Uživatel Stakeholders and Interests: – Uživatel: Chce spravovat o. p., zobrazovat jejich seznam, upravovat a přidávat nové. Preconditions: Uživatel je autentizován a přihlášen. Success End: Uživatel upravil obchodní případ. Main success scenario: 1. (o1.) Uživatel chce upravit obchodní případ. 2. (o2.) Uživatel spustí akci pro zobrazení seznamu obchodních případů. 3. (o3.) Systém zobrazí seznam obchodních případů, možnost pro řazení a filtrování tohoto seznamu (podle názvu, předmětu prodeje, účtu, vlastníka, stavu, ceny atd.), možnost pro přechod na detail o. p. a možnost pro přidání nového o. p. 4. (o4.) Uživatel zvolí akci pro přechod na detail zvoleného obchodního případu. 5. (o5.) Systém zobrazí detailní informace o zvoleném obchodním případu (předmět prodeje, vlastníka, stav, pravděpodobnost, cenu, náklady), navázaný účet a kontaktní osobu, seznam produktů, komentáře a vazby na další entity (aktivity). Uživatel může editovat záznamy, spravovat navázaný kontakt, spravovat seznam produktů, přidat komentář k účtu a zobrazit vazby na další entity. 6. (6.) Uživatel upraví nějaký záznam. 7. (7.) Systém upozorní uživatele, že upravil záznamy a měl by uložit provedené změny. Uživatel opakuje krok 6 do té doby, než provede všechny požadované změny. 8. (8.) Uživatel zvolí akci pro uložení změn. 9. (9.) Systém zkontroluje validitu záznamů, uloží změny a informuje o úspěšném uložení. Alternative flows: *a. (*a.) Kdykoli se může uživatel odhlásit ze systému. *b. (*b.) Uživatel chce opustit obrazovku. 4a. (o4a.) Uživatel chce seřadit data v seznamu obchodních případů. 4b. (o4b.) Uživatel chce filtrovat data v seznamu obchodních případů. 4c. (o4c.) Uživatel chce přidat nový obchodní případ (ve formuláři v podkroku 2 může vyplnit předmět prodeje, pravděpodobnost, cenu, navázat účet atd.). 6a. (6a.) Uživatel chce přidat komentář INCLUDE UC451: Comment business entity. 6b. (6b.) Už. chce zobrazit vazby na další entity INCLUDE UC453: Show connections. 6c. (6c.) Už. chce zobrazit nápovědu k entitě INCLUDE UC452: Show business entity help. 6d. Uživatel chce spravovat navázanou kontaktní osobu. 1. Uživatel zvolí přidání kontaktní osoby. 1a. Uživatel chce odebrat kontaktní osobu. 1. Uživatel zvolí odebraní kontaktní osoby. 2. Systém odebere vazbu a informuje o tom uživatele. 3. Systém pokračuje krokem 5 hlavního scénáře. 2. Systém zobrazí seznam zaměstnanců navázaného účtu. 3. Uživatel vybere kontaktní osobu se seznamu zaměstnanců.

63

3. Analýza 4. Systém naváže kontaktní osobu na obchodní případ a informuje o tom uživatele. 5. Systém pokračuje krokem 5 hlavního scénáře. 6e. Uživatel chce spravovat seznam produktů obchodního případu. 1. Uživatel zvolí přidání produktu. 1a. Uživatel chce odebrat produkt. 1. Uživatel zvolí odebraní produktu. 2. Systém odebere produkt a informuje o tom uživatele. 3. Systém pokračuje krokem 5 hlavního scénáře. 1b. Uživatel chce upravit položku v seznamu produktů. 1. Uživatel upraví doplňující informace položky (název, cenu, slevu, množství). 2. Systém pokračuje krokem 7 hlavního scénáře. 2. Systém zobrazí seznam dostupných produktů. 3. Uživatel vybere produkt. 4. Systém přidá produkt do seznamu produktů obchodního případu. 5. Systém pokračuje krokem 5 hlavního scénáře. 8a. (o8a.) Uživatel chce zrušit úpravu záznamů obchodního případu. 9a. (9a.) Uživatel zadal nevalidní data. Frequency of Occurrence: Velmi často – tento případ užití spouští několikrát denně většina uživatelů CRM aplikace.

Případ užití - UC451: Comment business entity Context of Use: Uživatel komentuje obchodní entitu (účet, kontakt, produkt, ceník, aktivitu, obchodní případ) nebo odpovídá na jiný komentář. Scope: CRM aplikace Level: Cíl uživatele Primary actor: Uživatel Stakeholders and Interests: – Uživatel: Chce komentovat obchodní entity a odpovídat na komentáře kolegů. Preconditions: Uživatel je autentizován a přihlášen. Success End: Uživatel okomentoval obchodní entitu. Main success scenario: 1. Uživatel chce komentovat obchodní entitu. 2. Uživatel okomentuje obchodní entitu a potvrdí vložení komentáře. 3. Systém vloží komentář k entitě a informuje o tom uživatele. Alternative flows: 2a. Uživatel chce vložit odpověď na komentář. 1. Uživatel napíše odpověď a potvrdí její odeslání. 2. Systém vloží odpověď ke komentáři a informuje o tom uživatele. 3. Systém upozorní na odpověď uživatele, který vložil původní komentář a i všechny uživatele, kteří na něj odpovídali INCLUDE UC601: Remind user. Frequency of Occurrence: Často – komunikace ohledně každé obchodní entity.

Případ užití - UC409: Show reports Context of Use: Uživatel nastaví parametry pro zobrazení reportu a report zobrazí. Scope: CRM aplikace Level: Cíl uživatele Primary actor: Uživatel Stakeholders and Interests:

64

3.2. Model případů užití – Uživatel: Chce zobrazit vývoj prodeje na základě různých parametrů. Preconditions: Uživatel je autentizován a přihlášen. Success End: Uživatel zobrazil parametrizovaný report vývoje prodeje. Main success scenario: 1. Uživatel chce zobrazit report, podle parametrů, které zadá. 2. Uživatel zadá parametry reportu (časové období, prodejce, produkt). 3. Systém graf vývoje prodeje na základě stanovených parametrů. Alternative flows: 3a. Nelze sestavit graf na základě stanovených parametrů. 1. Systém informuje uživatele, že graf vývoj prodeje nelze sestavit. Frequency of Occurrence: Málo – vývoj prodeje je sledován cca jedenkrát týdně.

3.2.6

UC6: CRM Reminder

Tato část obsahuje popis případů užití, které se týkají připomínek – upozornění na připomínku, zobrazení připomínky uživatelem. Skupina případů užití je zobrazena na diagramu případů užití 3.7.

Obrázek 3.7: UC model - UC6: CRM Reminder Případ užití - UC601: Remind user Context of Use: Systém upozorní uživatele na připomínku (komunikaci, varování, alarm). Scope: CRM aplikace Level: Funkce Primary actor: Systém Stakeholders and Interests: – Uživatel: Chce být upozorněn, když někdo odpoví na jeho komentář, změní vlastnictví jeho entity nebo na nadcházející aktivitu, kterou má vykonat. Preconditions: –

65

3. Analýza Success End: Systém upozornil uživatele na připomínku. Trigger: Někdo odpověděl na komentář uživatele nebo je čas na připomenutí aktivity uživateli nebo někdo změnil vlastníka obchodní entity, kterou vlastnil uživatel. Main success scenario: 1. Systém upozorní uživatele na připomínku, která spustila případ užití. Frequency of Occurrence: Velmi často – viz trigger.

Abstratní případ užití - UC602: Show reminder Context of Use: Uživatel zobrazí připomínku, na kterou ho upozornil systém(komunikaci, varování, alarm). Scope: CRM aplikace Level: Cíl uživatele Primary actor: Uživatel Stakeholders and Interests: – Uživatel: Chce zobrazit detail připomínky, na kterou ho upozornil systém. Preconditions: Uživatel je autentizován a přihlášen. Success End: Uživatel zobrazil připomínku. Main success scenario: 1. Uživatel chce zobrazit připomínky. 2. Uživatel zvolí akci pro zobrazení seznamu připomínek. 3. Systém zobrazí seznam připomínek. 4. Systém deaktivuje upozornění na zobrazené připomínky. Frequency of Occurrence: Velmi často – vždy, když je uživatel na něco upozorněn.

Případ užití - UC604: Show communication Context of Use: Uživatel zobrazí připomínku na komunikaci. Scope: CRM aplikace Level: Cíl uživatele Primary actor: Uživatel Stakeholders and Interests: – Uživatel: Chce zobrazit detail připomínky na komunikaci, na kterou ho upozornil systém. Preconditions: Uživatel je autentizován a přihlášen. Success End: Uživatel zobrazil připomínku na komunikaci. Main success scenario: 1. (o1.) Uživatel chce zobrazit připomínky na komunikaci. 2. (o2.) Uživatel zvolí akci pro zobrazení seznamu připomínek na komunikaci. 3. (o3.) Systém zobrazí seznam připomínek na komunikaci. U každé připomínky je zobrazeno jméno uživatele, který odpověď vložil, text odpovědi a obchodní entita, na kterou se komentář váže. Uživatel může odpovědět na komentář nebo zobrazit obchodní entitu. 4. (4.) Systém deaktivuje upozornění na zobrazené připomínky. 5. EXTEND UC451: Comment business entity IF uživatel chce odpovědět na komentář. Alternative flows: 4a. Uživatel chce zobrazit detail obchodní entity, na kterou se váže připomínka INCLUDE UC450: Manage business entity. Frequency of Occurrence: Velmi často – vždy, někdo odpoví na komentář uživatele.

66

Kapitola

Návrh V této kapitole je popsán návrh uživatelského rozhraní, výběr prostředí implementace a zvoleného vývojového prostředí, popsána logická a fyzická architektura systému a fyzický datový model.

4.1

Návrh uživatelského rozhraní

Jak bylo zmíněno v úvodní studii, existuje riziko, že koncový uživatel nebude schopen ovládat aplikaci, kvůli špatně navrženému uživatelskému rozhraní, což povede k tomu, že se systém nebude používat. Aby bylo toto riziko eliminováno je důležité věnovat pozornost návrhu uživatelského rozhraní a jeho testování. Existuje několik způsobů a metodik pro návrh uživatelského rozhraní. Jelikož je systém CRM webovou aplikací, rozhodl jsem se pro návrh navigace mezi stránkami a kompozice stránek využít webovou metodiku. Rozhodoval jsem se mezi dvěma metodikami – WebML a UWE. Ačkoli mám zkušenosti s metodikou WebML, zvolil jsem metodiku UWE. Důvodem volby byla její jednoduchost, založení na standardu UML, podpora v CASE nástrojích a podobnost navigačního modelu UWE s „task modelem“, který je poslední fází metody tvorby návrhu uživatelského rozhraní, která je založena na popisu a vizualizaci „tasků“ (úloh). V metodice WebML se navíc znázorňuje model navigace i kompozice do jednoho diagramu (hypertextového modelu), který je poté velmi rozsáhlý a obtížně prezentovatelný. Dalším krokem návrhu UI je vytvoření „mockup“ prototypu systému, čili vytvoření ilustrací několika obrazovek systému, které slouží jako podklady k testování návrhu UI. V závěru kapitoly je provedeno vyhodnocení tohoto testování.

4.1.1

Návrh navigace a kompozice

Jak již bylo uvedeno, pro návrh navigace a kompozice byla použita metodika UWE (více viz kapitola 1.5), konkrétně navigační a prezentační model. V me67

4

4. Návrh todice UWE se používají dva modely jako podklad pro tvorbu navigačního modelu - model požadavků a obsahu. Ty jsou zde vynechány a zastoupeny již hotovými modely systému z kapitoly analýza (model případů užití 3.2 a konceptuální datový model 3.1). Na navigačním modelu systému jsou zobrazeny navigační a procesní uzly a odkazy (viz obrázek 4.1). Na diagramu není zobrazeno rozhraní „Front office“, jen část webové prezentace a CRM aplikace. Do aplikace CRM lze přistoupit z webové prezentace po přihlášení viz byznys proces „Login“. Webová prezentace dále nabízí možnost vyzkoušení demo verze aplikace (TryDemo), zaregistrování (Register) nebo objednání (OrderCrm). Po vstupu do CRM aplikace je uživatel přesměrován na domovskou stránku této části označenou stereotypem „isHome“ – nástěnku (Dashboard). Poté může uživatel pokračovat na jakýkoli uzel diagramu, který je označen stereotypem „isLandmark“, který značí, že je uzel dostupný ze kteréhokoli uzlu navigačního grafu. Nejdůležitějšími uzly grafu jsou seznamy účtů (AccountsList) a kontaktů (ContactsList), které dědí společné vlastnosti z obecného seznamu obchodních entit (BusinessEntitiesList) – tj. řazení a filtrování prvků seznamu (FilterList, OrderList), mazání entit seznamu (RemoveEntity). Ze seznamů lze přejít na konkrétní uzel obsahující detailní informace o obchodní entitě (Account resp. Contact) nebo spustit proces vytvoření nové entity (CreateAccount resp. CreateContact). Detaily obchodních entit opět dědí vlastnosti od obecného uzlu (BusinessEntity) – tj. uložení změn editování (UpdateEntity), smazání entity, zobrazení navázaných entit (RelatedEntityList), navázání existující entity (CreateRelatedBusinessEntity), zobrazení komunikace. Model prezentace viz obrázek 4.2 zobrazuje abstraktní kompozici UI pomocí prezentačních elementů, kterých existuje hned několik (viz tabulka stereotypů UWE profilu v příloze B.2). Na diagramu je zobrazena pouze malá část celého prezentačního modelu – domovská stránka aplikace CRM a prezentační skupiny týkající se účtů. Hlavním elementem je prezentační stránka reprezentující domovskou stránku aplikace CRM (CrmHome). Ta obsahuje obrázek loga (CrmLogo), horní menu (TopBarMenu), hlavní menu (MainMenu) a panel s alternativami obsahu (ContentPanelAlternatives), ve kterém může být viditelná jedna z uvedených prezentačních skupin. Výchozí prezentační skupinou je nástěnka (Dashboard). Jednou z dalších alternativ jsou například účty (Accounts). Tato prezentační skupina obsahuje kontejner pro zobrazení seznamu účtů (AccountList). Každá položka seznamu je tvořena odkazem na detail účtu (navázán na název (Name)), typem účtu (Type), vlastníkem (Owner) a odkazem na skrytý formulář smazání účtu (DeleteAccount), který se vyvolá po přechodu na něj. Účty dále obsahují vstupní pole a selekce pro filtrování seznamu (NameFilter atd.) a tlačítko s odkazem na formulář vytvoření nového účtu. Dalším zajímavým prvkem je detail účtu (Account), který obsahuje panel záložek (ActualTabPanelAlternatives) se třemi alternativami. Výchozí záložka, která je zobrazena, obsahuje detailní informace účtu (AccountDetailTab). 68

4.1. Návrh uživatelského rozhraní

Obrázek 4.1: Návrh navigace v UWE

Obrázek 4.2: Návrh prezentace v UWE

69

4. Návrh

4.1.2

Mockup prototyp

Termínem mockup rozumíme low-fidelity50 prototyp aplikace (např. papírové ilustrace, snímky obrazovek nebo jednoduché obrazovky s limitovanou možností interakce). Prototypování je důležitou částí návrhu UI, ve které jsou vytvořeny, vyhodnoceny a propracovány návrhy až dosáhnou požadovaného stupně použitelnosti. Prototypů je celá řada od jednoduchých náčrtků (lowfidelity prototypy) až po funkční prototypy celých systémů, které obsahují většinu funkcionality koncového systému (high-fidelity). V rámci mockup prototypu byla vytvořena sada návrhů obrazovek CRM aplikace (např. obrázek 4.3). Další náčrtky obrazovek, které reprezentují vzorový průchod aplikací, jsou součástí přílohy (viz obrázky B.3, B.4, B.5, B.6, B.7 a B.8). Mockup prototyp vychází z předešlého návrhu navigace a kompozice, který v mnohých ohledech rozšiřuje. Zakládá rovněž na doporučení pro návrh webových aplikací viz Krug [25] a účelné použití komponent viz Tidwell [46].

Obrázek 4.3: Mockup prototyp - Úprava účtu

4.1.3

Testování návrhu UI

Návrh uživatelského rozhraní byl testován jednou z metod testování bez uživatelů – provedením heuristické analýzy na mockup prototypu. Po realizaci 50

Low-fidelity prototyp je neúplný, zběžný náčrtek, který má určité charakteristiky cílového produktu, ale je velmi jednoduchý. Vytváří se za účelem rychlé produkce prototypu pro testování všeobecných konceptů.

70

4.1. Návrh uživatelského rozhraní systému bylo provedeno testování uživatelského rozhraní s uživateli – testování použitelnosti (viz kapitola 6.3). Cílem heuristické analýzy je nalezení možných problémů s použitelností systému viz Nielsen [32]. Provádí ji několik (ideálně pět) expertů nezávisle na sobě, kteří proházejí rozhraní, definují při tom svůj názor na něj a kontrolují, zda splňuje určitou sadu principů neboli heuristik. Původní Nielsenova heuristika [32] obsahovala deset pravidel. Ty se postupem času díky novým zařízením a přístupům k návrhu vyvinuly v tyto: 1. Viditelnost stavu systému: Uživatelům je poskytnuta informace (zpětná vazba) o tom co systém provádí. 2. Shoda systému s realitou: Použití termínů a konceptů, které cílová skupina dobře zná. Informace by měly odpovídat tomu, co uživatelé očekávají a na co jsou zvyklí z reálného světa. 3. Minimální zodpovědnost a stres: Uživatelé by měli mít pocit, že mají interakci se systémem pod kontrolou. 4. Zachování konzistence a standardů: Ovládání, ikony, terminologie, podoba chybových hlášek by měla být konzistentní napříč rozhraním. Měly by být dodrženy standardy pro danou platformu. 5. Prevence chyb: Rozhraní obsahuje prvky, které slouží k tomu, aby interakce uživatele se systémem nevedla k chybovému stavu. 6. Rozpoznání místo rozvzpomínání: Snížení zátěže na „pamatování si“ uživatele uvedením známých ikon a akcí kdekoli je to účelné. 7. Flexibilita a efektivita použití: Systém by měl být snadno použitelný pro začátečníky a pokročilým uživatelům by měl nabídnout urychlující řešení apod. 8. Estetický a minimalistický design: Vyvarování se zobrazení nadbytečného množství informací a designových prvků na úkor důležitých informací. 9. Smysluplné chybové hlášky: Poskytnutí chybových hlášek, které instruují k tomu, co a jak opravit. 10. Nápověda a dokumentace: Měla by být přístupná nápověda, dokumentace a případně uživatelská podpora.

Heuristická analýza Heuristickou analýzu prováděli tři kolegové z oblasti IT. Byli předem seznámeni s testovaným systémem a scénáři testování. Podle scénářů procházeli mockup prototyp a do záznamových archů popsali každé porušení principů zmíněné heuristiky. Každý provedl dva průchody podle scénářů a na závěr ještě jeden nezávisle na scénáři. Z vyplněných záznamových archů byly do výsledného seznamu (viz níže) agregovány všechny připomínky. Každá položka byla ohodnocena stupněm závažnosti (prioritou v rozmezí 1 až 3 – zanedbatelný, marginální, závažný) a opatřena komentářem. 71

4. Návrh 1. Viditelnost stavu systému Z prototypu není jasné, jestli jsou akce systému okamžité (např. načítání seznamů) a není potřeba upozornit uživatele, že systém vykonává úlohu pomocí nějakého „progress“ indikátoru. Rovněž není jasné, zda je uživatel nějakým způsobem informován o úspěšném vykonání akcí jako např. vytvoření nebo smazání kontaktu apod. Indikátory stavu i notifikace o provedení akcí v prototypu chybí. V systému budou implementovány obě tyto funkce. – Priorita: 2 2. Shoda systému s realitou Na stránkách obchodních entit (účtů, obchodních případů atd.) je záložka jménem „komunikace“, lepším názvem by byl „chat“. Označení „účty“ je zavádějící, srozumitelnější by bylo označení „zákazníci“ nebo „firmy“. Stejně tak „Kontakty“ by mohly být pojmenovány slovem „osoby“. Záložka „komunikace“ bude přejmenována na „chat“. Názvy obchodních entit zůstanou prozatím zachovány. – Priorita: 3 3. Minimální zodpovědnost a stres – 4. Zachování konzistence a standardů Měly by být sjednoceny tlačítka v dialozích – v dialogu s upozorněním na opouštění stránky s entitou, která byla upravena, jsou tlačítka „Opustit bez uložení“ a „Zrušit“, v dialogu potvrzení smazání entity je „Zrušit“ odkazem. Dialogy budou sjednoceny. Méně významná akce bude odkazem. – Priorita: 1 5. Prevence chyb Pod některými formulářovými poli by měl být uveden formát očekávaných hodnot a omezení (např. formát telefonních čísel, omezení pro nové heslo, maximální cena). Tyto informace mohou být případně uvedeny formou tooltip nápovědy. V detailech obchodních entit (např. kontaktu) by mohla být označena povinná pole formuláře. Formát očekávaných hodnot a omezení bude k formulářovým polím přidán. Na stránkách detailů kontaktů případně jiných entit budou označena povinná formulářová pole tučným fontem. – Priorita: 2 6. Rozpoznání místo rozvzpomínání Na aktuální stránce není uvedena pozice ve stromové struktuře a odkazy na nadřazené stránky. To by mohlo být uvedeno formou breadcrumb. Tlačítka „Uložit“, „Nový“ a „Smazat“ na stránce entity by neměla být zobrazena, pokud se pohybujeme na záložkách „Komunikace“ nebo „Vazby“. Struktura aplikace není komplexní, aby uživatel nevěděl kde se nachází a potřeboval odkazy na nadřazené stránky. Tlačítka budou ve stavu „disabled“. Na prototypu to není zřetelné.

72

4.2. Výběr implementačního prostředí – Priorita: 1 7. Flexibilita a efektivita použití Uložení změn na stránkách entit by mohlo být provedeno pomocí klávesové zkratky „Ctrl+s“. Odeslání komentáře nebo odpovědi v komunikaci by mohlo být provedeno zkratkou „Shift+Enter“. Klávesová zkratka pro uložení změn není u webových aplikací standardní, nicméně tento požadavek bude navržen jako rozšiřující funkce. Zkratka pro odeslání komentáře bude implementována. – Priorita: 1 8. Estetický a minimalistický design – 9. Smysluplné chybové hlášky – 10. Nápověda a dokumentace Kontextová nápověda u seznamu produktů v obchodním případu by měla obsahovat místo popisu obsahu panelu příklady akcí, které může uživatel provést. Kontextová nápověda by mohla být uvedena na každé stránce nebo panelu, který umožňuje provedení různých akcí. Kontextové nápovědy budou přidány na stránkách entit ke všem panelům, které definují vazby na jiné entity. – Priorita: 2

4.2

Výběr implementačního prostředí

Systém bude vyvinut na platformě Java EE. Jak bylo již zmíněno, pro tento způsob vývoje existují na GAE určitá omezení, které se týkají některých komponent a webových frameworků, které buď nelze vůbec použít nebo jejich použití vyžaduje dočasné obejití v kódu (viz kapitola 1.4.2.1). Výběr technologií byl tedy omezený a obtížný. Webová vrstva aplikace bude tvořena několika frameworky. Jako webový aplikační framework byl zvolen JSF 2.1, který je Java EE standardem. Aplikační logika bude obsažena v Managed bean komponentách JSF. Prezentační vrstva bude tvořena XHTML51 stránkami a frameworkem pro tvorbu šablon stránek Facelets. Pro tvorbu prezentační vrstvy bude použita knihovna komponent pro JSF s názvem PrimeFaces verze 3.4.2. Pro vytváření srozumitelných URL52 a navigaci mezi stránkami bude použit framework PrettyFaces 3.3.3. Jako persistentní úložiště bude zvolena NoSQL objektová key-value databáze App Engine Datastore. App Engine Java SDK poskytuje pro přístup k Datastore low-level API (základní operace – get, put, delete, query). Im51 52

Extensible HyperText Markup Language Uniform Resource Locator

73

4. Návrh plementuje ale i Java EE standardy JDO a JPA, které zahrnují mechanizmy pro definici entit a dotazování. Nad low-level API existují další frameworky, které ulehčují práci s Datastore – Objectify, Twig, Slim3. Pro přístup k Datastore bude zvolen Objectify 4.0b1. Nad tímto frameworkem bude vytvořena DAO53 vrstva, která bude spolu s entitami sloužit vyšším vrstvám pro přístup k datům. Aplikační logika bude využívat i další služby, které poskytuje App Engine formou různých API. Pro odesílání emailů bude použito Mail API, pro přihlašování uživatelů Users API apod. S výběrem implementačního prostředí souvisí i výběr vývojového prostředí. Pro Java EE jich existuje hned několik. Platforma GAE ovšem poskytuje plugin pro Eclipse (Google plugin for Eclipse), který zahrnuje SDK – sadu nástrojů pro vývoj aplikací, která slouží pro vývoj a emulaci reálného prostředí GAE. Pomocí něj lze testovat aplikace lokálně nebo je nasadit přímo na App Engine. Jako IDE byl zvolen Eclipse ve verzi Juno se zmíněným pluginem.

Obrázek 4.4: Logická architektura systému

4.3 4.3.1

Architektura systému Logická architektura

Logickou architekturou je myšleno organizování softwarových tříd do balíčků (nebo jmenných prostor) subsystémů a vrstev viz Larman [26]. Název „logická“ je z toho důvodu, že nerozhoduje o tom, kde a jak jsou elementy nasazeny (na jakých fyzických zařízeních apod.). Fyzické nasazení je předmětem fyzické architektury systému. 53

74

Data Access Object

4.3. Architektura systému Logická architektura se modeluje pomocí UML diagramu balíčků (Package diagram). Obrázek 4.4 zobrazuje logickou architekturu CRM systému zasazenou do kontextu Java EE projektu, který obsahuje implementaci systému. Webové aplikace vyvíjené v Java EE mají podobnou strukturu, projekt zahrnuje dva základní balíčky – „src“, ve kterém jsou zdrojové soubory aplikace v jazyku Java a balíček „web“, který obsahuje zdroje, knihovny, konfigurační soubory, webové stránky, jejich šablony a deskriptory popisující nasazení systému. Po kompilaci a sestavení projektu jsou soubory obsahem jediného WAR54 archivu. Aplikace jsou většinou rozděleny na tři logické vrstvy – uživatelské rozhraní, doménu a technické služby viz Larman [26]. Vrstva uživatelského rozhraní je v CRM systému reprezentována balíčkem „web“ s webovými stránkami a dalšími zdroji. Doménu tvoří balíčky „Managed Beans“, „DAO“, „Entity“ a další, které obsahují Java třídy s aplikační logikou nebo rozhraním pro přístup k persistentnímu úložišti a k dalším externím službám. Obsahem vrstvy technických služeb jsou služby, které poskytuje platforma GAE jako Datastore API, Memcache API aj.

Obrázek 4.5: Fyzická architektura systému

4.3.2

Fyzická architektura

Fyzická architektura definuje infrastrukturu, na které bude systém CRM nasazen. Je zobrazena UML diagramem nasazení, který může obsahovat tři typy elementů viz Larman [26]. Zařízení (Device) je fyzický výpočetní zdroj, který poskytuje zpracování, paměťové služby a umožňuje spuštění software (např. počítač, server, mobilní zařízení). Výpočetní prostředí (Execution environment) je softwarový výpočetní zdroj (např. operační systém, virtuální stroj, webový prohlížeč, databázový stroj), který běží na nějakém vnějším uzlu (např. počítači) a poskytuje hostitelské služby pro jiné spustitelné softwarové elementy. Artefakt (Artifact) specifikuje fyzickou informaci, která je použita nebo vyprodukována procesem vývoje software nebo nějakou operací systému viz OMG UML [33]. Příkladem jsou soubory modelu, zdrojové sou54

Web Archive

75

4. Návrh bory, skripty, spustitelné soubory atd. Artefakt je zdrojem nasazen na uzel (zařízení nebo výpočetní prostředí). Uživatel bude k systému přistupovat ze stanice s webovým prohlížečem, který umožní zabezpečený přistup pomocí HTTPS55 viz obrázek 4.5. Systém CRM bude nasazen na platformu App Engine v archivačním souboru WAR. Fyzická infrastruktura platformy GAE je tvořena cloudovou infrastrukturou společnosti Google (datová centra). Distribuci zátěže systému zabezpečuje GAE pomocí „load balanceru“. K systému přistupuje v jednu chvíli několik uživatelů 4.6. Na App Enginu existuje několik paralelních instancí systému, které jsou virtuálně (zpravidla i fyzicky) umístěny na různých strojích. Load balancer má na starosti přidělení konkrétní obslužné instance CRM systému uživateli.

Obrázek 4.6: Distribuce zátěže systému na platformě GAE Pokud vzroste počet uživatelů systému, jsou vytvořeny další instance systému a tito noví uživatelé jsou obslouženi těmito novými instancemi. Klesne-li počet uživatelů, je některá instance zrušena a její uživatelé jsou přiděleni jiné instanci. Všechny instance využívají společné služby, které GAE poskytuje (Datastore, Memchace atd.).

55

76

Hypertext Transfer Protocol Secure

Kapitola

Realizace Tato kapitola popisuje realizaci systému. Je rozdělena do čtyř částí odpovídajících jednotlivým vrstvám aplikace (integrační, datová, prezentační a aplikační logika). Obsahuje popis klíčových a jiných zajímavých částí implementace.

5.1

Integrační vrstva

Integrační vrstva je tvořena službami platformy GAE [17]. Nejdůležitější z nich je Datastore, která slouží k persistenci dat. Mezi další použité patří Cron Service (spouštění naplánovaných úloh) a Users Service (autentizace uživatelů).

5.1.1

Datastore

Datastore není klasickou relační databází, ale distribuovanou NoSQL objektovou key-value databází. Z konceptuálního pohledu je Datastore hash mapa složená z klíčů k entitám a entity jsou hash mapy složené z názvů atributů a jejich hodnot. Nad Datastore lze provést pouze čtyři základní operace – put() uložení entit, delete() smazání entit, get() získání entit a query() dotazování na entity. Každá entita je identifikována tzv. klíčem Key, který se složeninou tří hodnot – názvu entity, rodiče a hodnoty id (řetězec nebo celé číslo). Entity se fyzicky ukládají a formují do struktur podobných souborovému systému, kde má každá z nich podobně jako soubor svého rodiče. Tento vztah se vytvoří při vzniku entity a je permanentní. Entita, která nemá předka je nazývána kořenovou. Entita a strom jejích potomků patří do jedné „entitní skupiny“. V rámci jedné transakce je povoleno získat data z pouze jedné takové skupiny. Je ale možno vykonávat transakce napříč více skupinami tzv. XG (cross-group) transakce. K získávání entit na základě hodnot jejich atributů se používají dotazy, které jsou provedeny nad daným typem. Mohou specifikovat filtry na hodnoty atributů, klíčů a předků. Výsledky jsou vráceny v seznamu. K určení výsledků 77

5

5. Realizace dotazů se využívají indexy, které jsou automaticky nebo manuálně tvořeny nad atributy. V systému CRM není pro přístup k Datastore použito low-level API, ale framework Objectify, který práci s Datastore v mnoha směrech usnadňuje a zpřehledňuje. Jeho specifikace a popis použití je uvedena v kapitole 5.2.1. 5.1.1.1

Fyzický datový model

Tato část popisuje transformaci konceptuálního datového modelu na fyzický datový model, čili způsob reprezentace entit, atributů a vztahů na perzistentním úložišti platformy GAE (Datastore). Datové typy atributů byly voleny podle příručky pro vývoj na GAE [17] – pro čísla jsou to int, long, float, řetězce str, db.Text, logický typ bool, datum datetime.date a reference db.Key. Vazby mezi entitami jsou řešeny několika způsoby. Kompozice jsou převedeny na entitní skupiny – entity, které jsou z konceptuálního hlediska součástmi složeného objektu, jsou v rámci entitních skupin potomky. Generalizace je řešena přidáním dvou skrytých atributů na straně potomka – hodnota diskriminátoru (název třídy) a seznam všech diskriminátorů třídy (název třídy, třídy předka atd.). Datastore umí nativně ukládat kolekce jednoduchých datových typů (včetně kolekcí klíčů Key). Tímto přístupem jsou řešeny vazby typu 1:M resp. M:N. U vazby 1:M je na straně zdrojové entity definován seznam klíčů na cílové entity. Vazba M:1 je řešena přidáním klíče cílové entity do zdrojové entity. Konkrétní řešení záleží na jednotlivých vazbách a dotazech, které jsou nad nimi prováděny. Entity spojené vazbou M:N nesou seznam klíčů na entity protější strany. Asociační třídy jsou řešeny vazební entitou.

5.1.2

Cron Service

Cron Service slouží k nastavení a spouštění naplánovaných úloh, které se vykonávají v pravidelných intervalech nebo ve stanovený čas. Tyto úlohy jsou běžně nazývány pojmem „cron jobs“. V systému existují dvě naplánované úlohy – odeslání faktur klientům (provádí se jedenkrát měsíčně) a vygenerování záznamů demo aplikace (provádí se denně). Úlohy spouští služba Cron Service automaticky tak, že ve stanovený čas přistoupí pomocí požadavku HTTP56 GET na stanovené URL. Nastavení je provedeno v souboru cron.xml viz kód 5.1. U druhé úlohy je nastaven identifikátor nasazené verze, na které je spuštěna a časová zóna. Zdrojový kód 5.1: cron.xml 1 2 3

56

78

Hypertext Transfer Protocol

5.1. Integrační vrstva 4 5 6 7 8 9 10 11 12 13 14 15

/ c r o n / s e n d I n v o i c e s Sends i n v o i c e s t o c l i e n t s e v e r y month <s c h e d u l e>2nd sunday o f month 03 : 0 0 / c r o n / generateDemo G e n e r a t e s sample data f o r demo e v e r y day <s c h e d u l e>e v e r y day 03 : 0 0 Europe / Prague v e r s i o n −2

Jelikož systém úlohy spouští přístupem na URL adresy, nechceme, aby k těmto adresám mohli přistupovat běžní uživatelé. Zabezpečení je provedeno standardním způsobem pomocí bezpečnostního omezení v souboru web.xml.

5.1.3

Users Service

Uživatel GAE aplikace může být autentizován třemi způsoby – pomocí Google Accounts, účtem z vlastní domény na Google Apps nebo OpenID identifikátory. Aplikace pozná, zda je uživatel přihlášen, může ho přesměrovat na stránku s přihlášením a rozezná jeho roli. V systému je použita autentizace pomocí Google Accounts. Ta je však omezená v tom, že rozeznává pouze dvě uživatelské role (přihlášený uživatel, administrátor). Vlastní role vytvářet nelze. Do aplikace se tedy může přihlásit jakýkoli uživatel vlastnící Google Accounts účet. Po přihlášení systém ověří, jestli se jedná o právoplatného uživatele systému – uživatele CRM (spadá pod nějakého klienta) nebo pracovníka CRM (manažera nebo administrátora), spáruje přihlašovací účet se skutečným účtem systému a přesměruje uživatele na jeho domovskou stránku (CRM home resp. Front-office). Pokud není účet nalezen je návštěvník přesměrován na demo verzi aplikace. Účty se ověřují a párují podle emailu přihlašovacího účtu, který je získán tímto kódem UserServiceFactory.getUserService().getCurrentUser().getEmail(). Je nutné rovněž specifikovat restrikce přístupu uživatelů k jednotlivých částem aplikace. To je provedeno standardní formou v deskriptoru nasazení web.xml viz kód 5.2. Název role pro pracovníka CRM je admin, pro uživatele je role označena symbolem hvězdičky. Zdrojový kód 5.2: web.xml 1 2 3 4 5 6 7 8 9 10 11

<web−app . . . > ... <s e c u r i t y −c o n s t r a i n t> <web−r e s o u r c e −c o l l e c t i o n> /crm /∗ ∗

79

5. Realizace 12 13 14 15 16 17 18 19 20 21

<s e c u r i t y −c o n s t r a i n t> <web−r e s o u r c e −c o l l e c t i o n> / admin /∗ admin ...

5.2

Datová vrstva

Vrstva přístupu k datům (resp. datová) spadá svým obsahem pod vrstvu integrační. Slouží k přístupu a manipulaci s daty, které jsou uloženy na persistentním úložišti (Datastore). Je navržena pomocí J2EE vzoru „Generic DAO“ [4] a GoF57 vzoru „Abstract Factory“ [12]. K její realizaci je použit framework Objectify.

5.2.1

Objectify

Objectify [43] je Java API, které slouží pro přístup k Datastore platformy GAE. Je praktičtější alternativou k low-level API a použitelnější než JDO nebo JPA. Umožňuje ukládání, mazání, získávání a dotazování nad objekty vlastních typů. Zahrnuje všechny nativní vlastnosti Datastore. Poskytuje typově bezpečné a jednoduché dotazování. Automaticky ukládá data do cache paměti. Podporuje polymorfizmus, má jednoduchý transakční model, není závislý na jiných knihovnách a má kvalitní dokumentaci. Framework Objectify byl použit při definici entitních tříd a operací, které slouží k manipulaci s daty. Pro jeho použití bylo nutno do projektu přidat knihovnu objectify-4.0.jar, odebrat geronimo-jpa_3.0.jar a nastavit filtr v souboru web.xml. 5.2.1.1

Entity a relace

Entita je objekt, který nese hodnoty dat uložených v databázi a odpovídá jedné definované POJO58 třídě. V rámci Datastore je entita objektem v hash mapě, na který je odkazováno pomocí klíče. Každá entita musí být opatřena anotací @Entity frameworku Objectify a registrována, aby mohl být při spuštění aplikace vytvořen metamodel entit sloužící k efektivní manipulaci s daty. Registrace je provedena ve třídě ObjectifyDaoFactory.java (viz kód 5.7). Pokud je entita potomkem jiné entity, značí se anotací @EntitySubclass viz kód 5.3 řádek 3. K tomu, aby správně fungoval polymorfizmus, musíme zapnout indexování index=true. 57 58

80

Gang of Four Plain Old Java Object

5.2. Datová vrstva V každé entitě musí být označen jeden atribut anotací @Id, jehož hodnota slouží k tvorbě klíče a identifikaci. Relace jsou řešeny prostřednictvím klíčů, které jsou uloženy jako hodnoty atributů entit. Existuje několik variant jejich definování. Použita je buď generická verze Key nebo Ref. Z hlediska způsobu uložení v Datastore jsou oba způsoby identické. Verze Ref navíc umožňuje uchování reference na instanci jiné entity. Aby byla při načítání entity inicializována i odkazovaná entita, je nutné uvést anotaci @Load viz kód 5.3 řádek 12. Následně se reference zapouzdřuje do „getter“ a „setter“ metod. Vazba na seznam aktivit je realizována seznamem klíčů aktivit List>. Zdrojový kód 5.3: Contact.java 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

import com . g o o g l e c o d e . o b j e c t i f y . a n n o t a t i o n . ∗ ; @ E n t i t y S u b c l a s s ( i n d e x=true ) public c l a s s Contact extends B u s i n e s s C a s e { //@Id Long i d ; // i d d e f i n e d i n s u p e r c l a s s String email ; String firstName ; S t r i n g lastName ; GenderType g e n d e r ; L i s t > a c t i v i t i e s = A r r a y L i s t >() ; @Load Ref c a t ; ... public C o n t a c t C a t e g o r y ge tC at ( ) { return c a t . g e t ( ) ; } public void s e t C a t ( C o n t a c t C a t e g o r y c ) { c a t = Ref . c r e a t e ( c ) ; } }

5.2.1.2

Operace a dotazy

Všechny příkazy pro manipulaci s daty jsou provedeny pomocí instance Objectify, která drží perzistentní kontext. Existuje několik způsobů jak načítat, ukládat a mazat entity. V kódu 5.4 jsou uvedeny nejpoužívanější. Dotazy pro načítání dat mohou obsahovat filtry, ve kterých se mohou používat relační operátory. Složitější manipulace s daty se provádí transakcemi. Zdrojový kód 5.4: Operace a dotazy 1 2 3 4 5 6 7 8 9 10 11 12 13

// g e t e n t i t y by i t s i d Contact c1 = o f y ( ) . l o a d ( ) . t y p e ( Contact . c l a s s ) . i d ( 1 2 3L) . g e t ( ) ; // g e t l i s t o f e n t i t i e s L i s t c s = o f y ( ) . l o a d ( ) . t y p e ( Contact . c l a s s ) . f i l t e r ( " g e n d e r " , GenderType .MALE) . l i s t ( ) ; // g e t f i r s t e n t i t y o f a r e s u l t l i s t Contact c2 = o f y ( ) . l o a d ( ) . t y p e ( Contact . c l a s s ) . f i l t e r ( " lastName " , "Wong" ) . f i l t e r ( " f i r s t N a m e ␣ != " , " Wai " ) . f i r s t ( ) . g e t ( ) ; // s a v e e n t i t y o f y ( ) . s a v e ( ) . e n t i t y ( c1 ) . now ( ) ; // d e t e l e e n t i t i e s o f y ( ) . d e l e t e ( ) . e n t i t i e s ( c1 , c2 ) . now ( ) ;

81

5. Realizace

5.2.2

Data Access Object

Data Access Object (DAO) je návrhovým vzorem z Core J2EE Pattern katalogu [27]. Slouží k abstrakci a zapouzdření přístupu k datovým zdrojům a správě spojení k nim. Motivací k použití tohoto vzoru je oddělení aplikační logiky od konkrétní realizace mechanizmů pro perzistenci dat. Existuje několik strategií pro jeho konkrétní použití viz Bien [4]. Já jsem zvolil generické DAO v kombinaci s doménově specifickým.

Obrázek 5.1: Diagram tříd – datová vrstva Generické DAO je obecné rozhraní, které definuje předpisy metod sloužících k základní manipulaci s daty. Není závislé na frameworku Objectify, může být implementováno i jinými frameworky a přístupy (např. pomocí GAE low-level API). Je generické, definuje parametrizovaný typ T, který je v době použití kódu nahrazen některou entitou (viz GenericDao.java kód 5.5). Toto rozhraní je implementováno pomocí frameworku Objectify ve třídě ObejctifyGenericDao.java, ze které následně dědí konkrétní DAO třídy (např. ObjectifyContactDao.java viz diagram 5.1). Zdrojový kód 5.5: GenericDao.java 1 2 3 4 5 6 7 8 9 10 11

public i n t e r f a c e GenericDAO { T s a v e (T e n t i t y ) ; T s a v e A l l ( I t e r a b l e e n t i t i e s ) ; T g e t E n t i t y ( Long i d ) ; T g e t E n t i t y B y P r o p s (Map<S t r i n g , Object> p r o p e r t i e s ) ; C o l l e c t i o n g e t L i s t ( ) ; C o l l e c t i o n g e t L i s t B y P r o p s (Map<S t r i n g , Object> p r o p e r t i e s ) ; void d e l e t e (T e n t i t y ) ; void d e l e t e A l l ( I t e r a b l e e n t i t i e s ) ; ... }

Pro každou entitu je vytvořen zvláštní DAO objekt. Ten může kromě metod z generického DAO implementovat i jiné metody, které jsou zpravidla 82

5.2. Datová vrstva definovány v příslušném rozhraní. Například v ContactDao.java je definován předpis pro metodu getContactsEmployers(), která slouží k získání všech zaměstnavatelů osoby a je specifická pro danou entitu.

5.2.3

Abstract Factory

Je-li možné, že dojde ke změně způsobu uložení dat (jiná databáze) nebo přístupu k nim (jiný framework), je vhodné pro DAO vrstvu implementovat vzor „Abstract Factory“ [27]. Tato strategie poskytuje abstraktní třídu, která má na starosti konstrukci konkrétních továrních tříd, pomocí nichž jsou vytvořeny skupiny DAO objektů viz diagram 5.1. V celé aplikaci smí existovat pouze jedna instance pro přístup k datovému zdroji, proto je ve třídě DaoFactory.java použit návrhový vzor „Singleton“ viz kód 5.6, který toto chování zajišťuje. Zdrojový kód 5.6: DaoFactory.java 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

public abstract c l a s s DaoFactory { private s t a t i c DaoFactory i n s t a n c e = n u l l ; public s t a t i c DaoFactory g e t I n s t a n c e ( ) { i f ( i n s t a n c e == n u l l ) { i n s t a n c e = new O b j e c t i f y D a o F a c t o r y ( ) ; } return i n s t a n c e ; } public s t a t i c void s e t I n s t a n c e ( DaoFactory i n s t a n c e ) { DaoFactory . i n s t a n c e = i n s t a n c e ; } public abstract AccountDao getAccountDao ( ) ; public abstract ContactDao getContactDao ( ) ; ... }

V konkrétních továrnách je většinou nastaveno spojení s databází nebo jiná konfigurace a jsou implementovány metody pro přístup ke konkrétním DAO objektům. V továrně ObjectifyDaoFactory.java je například provedena navíc registrace entitních tříd pro framework Objectify viz kód 5.7. Zdrojový kód 5.7: ObjectifyDaoFactory.java 1 2 3 4 5 6 7 8 9 10 11 12

public c l a s s O b j e c t i f y D a o F a c t o r y extends DaoFactory { static { O b j e c t i f y S e r v i c e . r e g i s t e r ( Account . c l a s s ) ; O b j e c t i f y S e r v i c e . r e g i s t e r ( Contact . c l a s s ) ; ... } @Override public ContactDao getContactDao ( ) { return new O b j e c t i f y C o n t a c t D a o ( ) ; } ... }

83

5. Realizace

5.3

Prezentační vrstva

Prezentační vrstva systému je tvořena XHTML webovými stránkami frameworku JSF, šablonami webových stránek deklaračního jazyka Facelets, komponentami knihovny PrimeFaces a dalšími zdroji jako jsou CSS59 kaskádové styly, skripty v jazyku JavaScript a obrázky.

5.3.1

JavaServer Faces

Komponentový framework JSF je standardem pro vývoj prezentační vrstvy webových aplikací na platformě Java EE viz Jendrock [21]. Skládá se ze dvou částí. První je API, které slouží pro reprezentaci komponent a správu jejich stavu, obsluhu událostí, validaci a konverzi dat, definici navigace mezi stránkami, podporu internacionalizace a přístupnosti a rozšiřitelnost těchto funkcí. Druhou je knihovna tagů reprezentující komponenty, které mohou být umístěny na webové stránky a spojeny s objekty na serveru. JSF aplikace je standardní webová apli- Obrázek 5.2: Architektura JSF kace, která na serveru zpracovává HTTP po- (zdroj: Goncalves [15]) žadavky klienta a produkuje HTML stránky, které klientovi odesílá jako odpověď viz Goncalves [15]. Framework JSF je stejně jako většina webových frameworků založen na návrhovém vzoru MVC60 , který odděluje view (stránky) od modelu (dat, které stránky zobrazují). Kontroler obsluhuje akce uživatele, které mění model a na základě toho je aktualizováno view (pohledy). U frameworku JSF je kontrolerem servlet s názvem FacesServlet (viz obrázek 5.2), který vyhodnocuje požadavky a volá akce nad modelem pomocí „managed bean“ komponent. Servlet se konfiguruje ve faces-config.xml souboru nebo od verze JSF 2.0 anotacemi v Java třídách ( „managed beanách“, konvertorech, komponentách a validátorech). Stránky tvořící view mohou být definovány v různých deklaračních jazycích (JSP, XHTML). Od verze JSF 2.0 se pro deklaraci stránek a komponent standardně používá Facelets (XHTML stránky, ve kterých jsou pro zobrazení komponent použity JSF tagy). Renderer slouží pro vykreslování komponent a překlad vstupu uživatele na hodnoty komponent. Validátory jsou komponenty, které ověřují správnost vstupních hodnot uživatele. Konvertory převádějí hodnoty objektů na řetězce, které je možno na stránkách zobrazit a naopak. Konfigurační soubor faces-config.xml se nachází v projektu ve složce ../war/WEB-INF. Obsahuje pouze nastavení lokalizace. Ostatní nastavení je 59 60

84

Cascading Style Sheets Model–view–controller

5.3. Prezentační vrstva provedeno anotacemi přímo v „managed beanách“. Popis managed bean komponent je součástí kapitoly „aplikační logika“ 5.4.1. 5.3.1.1

Facelets

Deklarační jazyk Facelets slouží k tvorbě prezentační vrstvy JSF aplikací, je součástí JSF specifikace a náhradou za JSP. Důležitým rozšířením je podpora pro tvorbu šablon. Formátem stránek je XHTML, který je postaven na standardu XML. V kódu stránek jsou deklarovány jmenné prostory různých knihoven tagů, které slouží k definici komponent. Existuje několik standardních knihoven, jež mohou být na stránky přidány. Nejčastěji to jsou knihovny pro tvorbu šablon (JSF Facelets Tag Library, prefix ui:), pro definici UI komponent (JSF HTML Tag Library, prefix h:) a pro obsluhu akcí (JSF Core Tag Library, prefix f:). Je podporována i tvorba vlastních komponent a knihoven komponent, pro které se vytváří vlastní prefix. Komponenty deklarované pomocí tagů na stránkách mohou být asociovány s metodami a vlastnostmi v Java třídách ( „managed beanách“) pomocí výrazů zapsaných v jazyce EL61 . Zdrojový kód 5.8 zobrazuje fragment šablony CRM aplikace. V šabloně jsou deklarovány jmenné prostory pro všechny použité knihovny tagů. Dále obsahuje komponenty popisující layout aplikace. Element definuje místo v šabloně, na které je možno vložit obsah elementu umístěného ve stránkách, které šablonu používají. Zdrojový kód 5.8: appTemplate.xhtml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

< !DOCTYPE HTML PUBLIC " −//W3C//DTD␣HTML␣ 4 . 0 1 ␣ T r a n s i t i o n a l //EN" " h t t p : // www. w3 . o r g /TR/ html4 / l o o s e . dtd "> ...

...

< u i : i n s e r t name=" c o n t e n t "> [ c o n t e n t ] ...

Šablona je použita například v kódu 5.9. V klientské stránce je element . Jeho atribut template slouží k definici jména šablony. 61

Expression Language

85

5. Realizace Následuje element , jehož obsah se vloží do šablony na místo označené elementem . Ze standardních UI komponent je v uvedeném fragmentu pouze element reprezentující formulář. Ostatní komponenty (s prefixem p:) jsou z frameworku PrimeFaces. Spojení UI komponenty s objektem v managed beaně, který využívá zápis v EL je například na řádce 13, kde je pro tabulku v atributu value definován datový zdroj (seznam kontaktů – contactList) EL zápisem value=”{#contactBean.contactList}”. Na managed beaně s názvem contactBean (viz kód 5.10) je zavolán příslušný „getter“ – metoda getContactList(), která vrací daný seznam.

5.3.2

PrimeFaces

PrimeFaces je open source knihovna komponent pro JSF s mnoha rozšířeními a vlastnostmi. Sada komponent PrimeFaces obsahuje vedle standardních komponent (inputText, commandButton, dataTable, column aj.) i velmi pokročilé komponenty jako jsou např. HTML editor, dialog (modální okno), autocomplete (podpora automatického dokončování resp. napovídání textu), kalendář, grafy nebo myšlenkové mapy. V PrimeFaces je zabudován AJAX62 , který je založen na standardním JSF 2.0 AJAX API a využívá knihovnu jQuery63 . Pro použití PrimeFaces stačí do projektu přidat pouze jednu knihovnu formátu JAR. Tato knihovna není závislá na jiných knihovnách a pro její použití není potřeba žádné další konfigurace. Pro vývoj systému byla použita verze PrimeFaces 3.4. K tomu, aby bylo možné komponenty používat, je nutné ve jmenných prostorech XHTML stránek deklarovat příslušnou knihovnu tagů (viz kód 5.9, řádek 5). Komponenty knihovny PrimeFaces bývají zpravidla uvozeny p: prefixem. Ve fragmentu kódu 5.9 je jich použito hned několik. Na řádku 8 je sloužící pro zobrazení notifikace, která po šesti sekundách automaticky zmizí. Hned pod ním je použit panel , který ohraničuje a seskupuje vnořené prvky. Další komponentou je tabulka , ve které jsou zobrazeny prvky seznamu. Seznam, který má být zobrazen, je získán z přidružené managed beany a musí být instancí třídy java.util.Collection nebo jejího potomka, zde je to List (viz kód 5.10, řádek 5). Třída Contact.java je jednou z entit systému. Tabulka obsahuje několik dalších nastavení viz příručka PrimeFaces [8]. Sloupce tabulky jsou definovány elementem , který svými atributy nastavuje řazení a filtrování nad celou tabulkou. Důležitou komponentou je modální okno , které se vyvolá po stisku odkazu (viz řádek 22) javascriptovou akcí oncomplete="delDialog.show()". 62

AJAX (Asynchronous JavaScript and XML) je technologie vývoje interaktivních webových aplikací, u kterých se dynamicky mění obsah stránek a není nutné ho opětovně načítat. Využívá technologie (X)HTML, CSS, DOM, JavaScript, XMLHttpRequest. 63 jQuery je javascriptová knihovna určená pro skriptování HTML na straně klienta.

86

5.4. Aplikační logika Zdrojový kód 5.9: contactList.xhtml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

< u i : d e f i n e name=" c o n t e n t ">

#{msg [ ’ C o n t a c t L i s t ’ ] }

#{c . l a s t n a m e } ... ...

...

5.4

Aplikační logika

Vrstvu aplikační logiky tvoří managed bean třídy frameworku JSF, které slouží ke zpracování požadavků webové vrstvy, při čemž využívají služeb integrační vrstvy k manipulaci s daty v databázi. Součástí je rovněž framework PrettyFaces pro tvorbu navigace mezi stránkami.

5.4.1

Managed Beans

Managed beans jsou speciální Java třídy JSF frameworku, které slouží k synchronizaci hodnot s UI komponentami, zpracování aplikační logiky a obsluze navigace mezi stránkami viz Goncalves [15]. V předešlé kapitole 5.3 byly uvedeny příklady přidávání komponent na stránky a jejich spojování s managed beanami pomocí tagů a výrazů EL. Tato část je věnována čistě vývoji managed bean. 87

5. Realizace Managed beany mohou být konfigurovány v souboru faces-config.xml nebo anotacemi přímo v kódu. Při vývoji byl použit druhý způsob. Třída, reprezentující managed beanu je označena anotací @ManagedBean (viz kód 5.10, řádek 1) a díky ní je při spuštění serveru automaticky registrována. Další anotací je označen způsob správy doby života (scope), po kterou beana v aplikaci existuje. V projektu jsou použity pouze tyto čtyři – @ApplicationScoped (přetrvává po celou dobu běhu aplikace), @SessionScoped (přetrvává po dobu sezení klienta), @ViewScoped (přetrvává po dobu interakce uživatele s jednou stránkou aplikace), @RequestScope (přetrvává po dobu jednoho HTTP požadavku). Instance managed bean jsou vytvářeny až v době, kdy jsou poprvé použity ( „lazy-instantiated“). Pro navigaci mezi stránkami je použita tzv. implicitní navigace nebo je řešena s využitím frameworku PrettyFaces (viz kapitola 5.4.2). Managed beany musí být spojeny s DAO objekty, které slouží pro manipulaci s daty v databázi. Toto spojení se obvykle řeší pomocí „dependeny injection“. Platforma GAE ovšem žádnou implementaci specifikace JSR 299 [31], která definuje CDI64 pro platformu Java EE, nepodporuje. Dependency injection tedy použít nelze. Místo toho jsou všechny DAO objekty vytvořeny dle návrhového vzoru „Abstract “ ve třídě DaoFactory.java a vloženy do managad bean v metodě init(), která je označena anotací @PostConstruct. Tato anotace je součástí specifikace JSR 250 [30] a zajistí, že je metoda zavolána po vytvoření instance managed beany pouze jedenkrát v průběhu jejího životního cyklu. Beana je poté předána správci jejího životního cyklu a je připravena odpovídat na požadavky uživatele. Ve fragmentu kódu 5.10 je v metodě init() načtena vazba na DAO objekt do proměnné contactDao. Tento objekt je následně využit v metodě loadContactList() k načtení seznamu kontaktů z databáze. Zdrojový kód 5.10: ContactBean.java 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

@ManagedBean ( name=" c o n t a c t B e a n " ) @ViewScoped public c l a s s ContactBean implements S e r i a l i z a b l e { private ContactDao contactDao ; private L i s t c o n t a c t L i s t ; private Contact c o n t a c t ; private Long c o n t a c t I d ; ... @PostConstruct public void i n i t ( ) { contactDao = DaoFactory . getContactDao ( ) ; } public void l o a d C o n t a c t L i s t ( ) { c o n t a c t L i s t = contactDao . l i s t A l l ( ) ; } public void l o a d C o n t a c t ( ) { t h i s . c o n t a c t = contactDao . g e t ( c o n t a c t I d ) ; } ... 64

88

Contexts and Dependency Injection

5.4. Aplikační logika 20 21 22 23

public L i s t g e t C o n t a c t L i s t ( ) { return c o n t a c t L i s t ; } }

5.4.2

PrettyFaces

Knihovna PrettyFaces je rozšířením pro Servlet, Java EE a JSF. Umožňuje vytváření srozumitelných, uživatelsky přívětivých URL ve stylu REST, které jsou vhodné pro SEO65 optimalizaci viz dokumentace PrettyFaces [2]. Řeší několik problémů např. vlastní přepisování URL, spuštění akce po načtení stránky, dynamické přiřazení „view-id“, parsování managed parametrů v beanách a integraci s navigací v JSF. Tato knihovna je v systému použita pro řešení navigace mezi stránkami, tvorbu „pěkných“ URL a spouštění akcí po načtení stránek. Konfiguruje se v souboru web.xml přidáním filtru a jeho mapování. Samotné nastavení přepisování URL je provedeno v pretty-config.xml souboru (viz kód 5.11). Na řádku 7 je provedeno mapování na stránku seznamu kontaktů, který bude dostupný na URL /crm/contactList namísto /faces/crm/contactList.xhtml. Toto mapování dědí část URL /crm z mapování předka (viz řádek 3). Mapování detailu kontaktu (viz řádek 12) způsobí, že bude detail dostupný na URL /crm/contact/[contactId], kde musí být za parametr cesty [contactId] dosazen identifikátor kontaktu. Toto dosazení je definováno např. v komponentě , hodnotou odkazu je /crm/contact/#{c.id} (viz kód 5.9, řádek 18). Skutečná hodnota parametru se poté předá pomocí EL výrazu #{contactBean.contactId} (řádek 13 v mapování) přímo do proměnné contactId příslušné managed beany (viz kód 5.10, řádek 7). V rámci mapování je definována metoda #{contactBean.loadContact}, která má být na managed beaně spuštěna po provedení mapování viz řádek 15. Tato metoda načte kontakt z databáze (viz kód 5.10, řádek 17). Zdrojový kód 5.11: pretty-config.xml 1

2 3 4 5 6 7 8 9 10 11 12

...

#{c o n t a c t B e a n . l o a d C o n t a c t L i s t } 65

Search Engine Optimization

89

5. Realizace 13 14 15 16 17 18

#{c o n t a c t B e a n . l o a d C o n t a c t } ...

90

Kapitola

Testování Cílem testování je zlepšení kvality, verifikace a validace a odhadování spolehlivosti produktu viz Pan [34]. Existuje široké spektrum metod a technik testování, které se provádí v různých fázích životního cyklu projektu a každá z nich slouží k mnoha odlišným účelům. Tato kapitola seznamuje s provedenými způsoby testování CRM systému. Jedno testování bylo již popsáno dříve – testování návrhu UI provedením heuristické analýzy viz kapitola 4.1.3.

6.1

White-box testování

Testování „white-box“ je strategie, u které je testování založeno na znalosti a analýze interní struktury a implementace testované části software viz Copeland [10]. Často bývá ztotožňováno s jednotkovým testováním. Tento způsob testování byl uplatněn například pro ověření integrace systému s Datastore. Pro jeho realizaci byl použit framework JUnit verze 4 viz jednoduchý příklad v kódu 6.1, který ověřuje správnost zápisu do Datastore. Zdrojový kód 6.1: AccountTest.java 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

public c l a s s AccountTest { @Rule public EmbeddedDataStore s t o r e = new EmbeddedDataStore ( ) ; @BeforeClass public s t a t i c void s e t U p B e f o r e C l a s s ( ) throws E x c e p t i o n { O b j e c t i f y S e r v i c e . r e g i s t e r ( Account . c l a s s ) ; } @Test public void t e s t ( ) { Objectify ofy = O b j e c t i f y S e r v i c e . begin () ; o f y . put (new Account ( ) ) ; a s s e r t E q u a l s ( 1 , o f y . query ( Account . c l a s s ) . l i s t ( ) . s i z e ( ) ) ; } }

91

6

6. Testování

6.2

Black-box testování

Testování „black-box“ je strategie, u které je testování založeno výhradně na požadavcích a specifikaci viz Copeland [10]. Na rozdíl od „white-box“ testování nevyžaduje znalost interní struktury nebo implementace testované části software. Tímto způsobem byla ověřena funkcionalita některých částí systému. Pro jeho realizaci byl použit framework Selenium, který je určený k testování webových aplikací. Umožňuje záznam kroků provedených při manuálním testování aplikace ve webovém prohlížeči a jejich následné přehrávání nebo přímý export do tříd určených pro jednotkové testování v různých programovacích jazycích. Pro jazyk Java se testovací případy exportují do tříd již zmiňovaného frameworku JUnit viz kód 6.2, na kterém je znázorněno ověření funkce filtrování seznamu podle sloupce obsahujícího názvy firem. Zdrojový kód 6.2: FilterListTest.java 1 2 3 4 5 6

public c l a s s F i l t e r L i s t T e s t { private D e f a u l t S e l e n i u m s e l e n i u m ; @Before public void setUp ( ) throws E x c e p t i o n { s e l e n i u m = new D e f a u l t S e l e n i u m ( " l o c a l h o s t " , 4 4 4 4 , " ∗ chrome " , " h t t p : / / l o c a l h o s t : 8 8 8 8 / crm/ a c c o u n t L i s t " ) ; selenium . s t a r t () ; }

7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

@Test public void t e s t F i l t e r L i s t ( ) throws E x c e p t i o n { s e l e n i u m . open ( " /crm/ a c c o u n t L i s t " ) ; s e l e n i u m . t y p e ( " i d=a c c o u n t s T a b l e : nameCol : f i l t e r " , " v e r b a " ) ; s e l e n i u m . keyUp ( " i d=a c c o u n t s T a b l e : nameCol : f i l t e r " , " a " ) ; Thread . s l e e p ( 2 0 0 0 ) ; a s s e r t E q u a l s ( " Verbatim , ␣ I n c . " , s e l e n i u m . g e t T e x t ( " // d i v [ @id=’ a c c o u n t s T a b l e ’ ] / t a b l e / tbody / t r [ 1 ] / td [ 1 ] / d i v / a " ) ) ; } @After public void tearDown ( ) throws E x c e p t i o n { selenium . stop () ; } }

6.3

Testování použitelnosti

Systém CRM není vyvíjen pro konkrétního zákazníka. Před jeho finálním nasazením tedy nemůže probíhat akceptační testování, které by provedl externí zadavatel projektu. Jedinou možností pro ověření kvality a odhalení nedostatků systému je provedení testování použitelnosti (Usability Testing). Jedná se o nejlepší cestu k porozumění toho, jaké mají skuteční uživatelé dojmy z aplikace. 92

6.3. Testování použitelnosti Byla testována část systému „aplikace CRM“, částí „Web“ a „FO“ (viz obrázek 2.1) se testování netýkalo. Uživatelem CRM aplikace může být prakticky jakákoli osoba v aktivním pracovním věku. Skupinu lidí, které se tohoto testování účastnili, tvořily tři osoby, které byly pozorovány při provádění předem připravených úkolů. Jejich chování bylo zaznamenáno, analyzováno a vyhodnoceno.

6.3.1

Scénář testování

Testování bylo provedeno ve druhé iteraci vývoje UI. Cílem byla především verifikace správného rozložení komponent aplikace, položek menu, snadnosti ovládání systému a porozumění zobrazených informací. Účastníci prováděli tento scénář: 1. Přihlaste se do CRM aplikace. (uživatelské jméno: test, heslo: test) 2. Zkontrolujte, zda máte nějaké nové upozornění od systému. Zaznamenejte kolik z jich se týká „chatu“. 3. Vyberte si jedno z upozornění na „chat“, prohlédněte si ji a zadejte libovolnou odpověď. 4. Potřebujete rychle vyhledat tři nejlépe hodnocené „aktivní“ firmy z města „Štolmíř“. Zaznamenejte jejich názvy. 5. Exportujte předešlý seznam firem do dokumentu ve formátu PDF. 6. Změňte jazyk aplikace na anglický. 7. Na konferenci jste dostal vizitku od pana Nováka ze společnosti ABC, s.r.o., který by měl zájem o koupi 42 ručníků typu „TX 100“. Zaznamenejte do systému pana Nováka a případně i společnost, ve které pracuje. Vytvořte obchodní případ ohledně koupě ručníků. (vizitka: Jan Novák; ABC, s.r.o.; 911 112 007; [email protected]) 8. Odhlaste se ze systému.

6.3.2

Průběh testování

Účastníci měli k dispozici scénář a byli pozorováni při vykonávání jednotlivých úkolů. Krom kroků scénáře byly instruováni ke spuštění CRM systému zadáním URL adresy do webového prohlížeče a obeznámeni s účelem systému. Testování neprobíhalo v laboratoři určené k testování použitelnosti, ale na místě – v kanceláři účastníků (tzv. „in situ“). Nevěděl-li si účastník s nějakým krokem rady, byl mu postup ukázán tak, aby mohl být dokončen celý scénář. Na závěr byli účastníci dotázáni na to, jaký mají z aplikace dojem, jak hodnotí její použitelnost a co by navrhovali pro její vylepšení. 93

6. Testování Účastník A Účastník A (muž, 55 let, mírně pokročilý uživatel), pracuje v menší firmě jako obchodní zástupce. Do styku s počítačem se při své práci dostává téměř každodenně při používání emailu nebo vyhledávání informací na internetu. Na úvodní obrazovce jen chvíli hledal formulář pro přihlášení do systému. U druhého úkolu příliš neporozuměl zadání, nevěděl co znamenají „upozornění systému“. V sociálních aplikacích, které nepoužívá, je tato funkcionalita běžná. Se zadáním odpovědi na komentář nebyl problém. Firmy nejprve začal vyhledávat procházením seznamu, bylo upřesněno, že má použít funkcí seznamu. S filtrováním stavu firmy a města trvalo přijatelně dlouho, seřazení seznamu podle hodnocení bylo delší, nejprve musel být požádán o seřazení podle názvu, pak už se chytil. Tlačítko pro export seznamu, hledal přímo v tabulce, trvalo pár sekund a všiml si jeho umístění v pravém horním rohu. Tlačítko pro přechod do nastavení i samotná změna jazyku proběhla rychleji. Pro záznam nové osoby do systému správně přešel na položku „Osoby“, přidání nové osoby původně zkoušel provést stiskem pravého tlačítka na seznamu (čekal, že se mu zobrazí kontextové menu). Zadání osoby proběhlo v pořádku. U zadávání firmy již věděl, kde hledat tlačítko pro vyvolání modálního okna. Nový obchodní případ byl zadán správně. Odhlášení našel velmi rychle. Na tomto účastníkovi bylo nejvíc vidět jak si ze začátku nevěděl rady a postupně se v práci se systémem zlepšoval – pamatoval si kde hledat tlačítka atd. Velké problémy dělala maska u vstupního pole položky „interní id“. Po najetí myší na pole se sice zobrazil „tooltip“ s nápovědou tvaru masky „a*999-a999“, tomu ovšem nebylo porozuměno. Účastník B Druhý účastník (žena, 22 let, pokročilá uživatelka), studuje a pracuje na projektech neziskové organizace. S počítačem pracuje denně, velmi často řeší práci na sociálních sítích. Co se týče zkušeností s webovými aplikacemi je na pokročilé úrovni. S pochopením úkolů a jejich provedením neměla větší problémy. Při jejím testování byla odhalena chyba ve funkcionalitě řazení při procházení stránek seznamu firem. Měla stejný problém s nepochopením nápovědy k masce vstupního pole, ale postupným zadáváním různých znaků přišla na význam symbolů určujících tvar masky. Účastník C Třetí účastník (muž, 25 let, expert), je vystudovaným softwarovým inženýrem s tříletou praxí v oboru. Jeho zaměřením je především integrace systémů. Podílel se rovněž na testování návrhu UI viz kapitola 4.1.3. S provedením úkolů scénáře neměl sebemenší problémy. Spíše upozornil na nedostatky UI, které při práci zaznamenal: 94

6.3. Testování použitelnosti 1. Seznam společností není seřazen podle abecedy. Pokud začíná název malým písmenem je řazen na konec seznamu. 2. V případě, že má být vlastník firmy evidován i jako osoba v CRM, bylo by vhodné v seznamu firem udělat jeho jméno jako odkaz vedoucí na jeho detail. 3. Při stisku tlačítka „Nový“, např. u seznamu obchodních případů trvá vyvolání modálního okna dlouhou dobu. Při tomto čekání by bylo vhodné zobrazení komponenty „spinning wheel“ nebo „throbber“66 . 4. Hodnota filtru sloupce „Interní id“ v seznamu firem je aplikována porovnávací metodou „starts with“. U tohoto sloupce by byla lepší metoda „contains“. 5. Ve formuláři zadávání adresy je pole „země“, které je předvyplněné na hodnotu „Andora“. Uživatelé mohou v důsledku přehlédnutí pole ignorovat a nevědomky vytvoří adresu se zemí „Andora“. 6. Animace „tooltipu“ je zbytečná – rozbalení obsahu nápovědy je příliš zdlouhavé.

6.3.3

Vyhodnocení

Rozložení komponent aplikace a položek v menu se ukázalo být vyhovující. Výhrady jsou spíše k ovládání systému a porozumění prezentovaných informací. Z nich byl sestaven seznam navrhovaných změn, které bude třeba provést: 1. Implementace kontextového menu vyvolaného stiskem pravého tlačítka. 2. Doplnění popisu znaků, které je možno zobrazit v nápovědě k maskám. 3. Oprava chyby v řazení při procházení stránek seznamu firem. 4. Odkazy nad jmény vlastníků v seznamech. 5. Oprava chyby v řazení malých písmen za velká u seznamů. 6. Implementace „spinning wheel“ pro dlouho trvající akce. 7. Změna metody porovnávání u filtru sloupce „Interní id“ na „contains“. 8. Nastavení prázdné implicitní hodnoty na vstupním poli „země“. 9. Odstranění animací u „tooltip“ nápověd.

66

Throbber je grafickým prvkem uživatelského rozhraní software, který zobrazuje jednoduchou animaci vyjadřující to, že systém vykonává blokující akci. Často používanou animací je „spinning wheel“ – malé disky uspořádané do kruhu, připomínající hodiny, které jsou postupně proti směru hodinových ručiček zvýrazňovány.

95

Závěr Zhodnocení dosažených cílů V rámci této práce jsem navrhl a implementoval CRM systém, který se skládá ze tří logicky oddělených částí – webové prezentace systému, CRM aplikace a aplikace sloužící k její administraci CRM. Systém funguje na cloudové infrastruktuře, která je zajištěna poskytovatelem PaaS Google App Engine. Díky flexibilitě využití výpočetních zdrojů, která je zajištěna touto platformou, může být CRM aplikace poskytována jako SaaS a platebním modelem může být pay-as-you-go. Funkční požadavky na CRM aplikaci byla stanoveny na základně provedení rešerše existujících řešení. Mezi hlavní funkce patří správa firem, osob, produktů, ceníků, aktivit a obchodních případů, zobrazení reportů formou grafů a zobrazení upozornění na úkoly, chat a další události. V rámci analýzy systému byl detailně popsán konceptuální datový model a většina scénářů případů užití systému. Další důležitou částí práce byl návrh uživatelského rozhraní, ve kterém byla pro návrh kompozice a navigace použita metodika UWE. Následně byl vytvořen a otestován mockup prototyp CRM aplikace. Systém byl vyvinut v Java EE. Byly implementovány různé API, které poskytuje GAE. K realizaci byly použity návrhové vzory (DAO, Abstract Factory) a několik frameworků, z nichž nejdůležitějšími byly Objectify starající se o persistenci dat a JSF řídící aplikační logiku a prezentaci. Testování probíhalo několika způsoby v různých fázích vývoje. Prvním bylo testování návrhu uživatelského rozhraní. Poté byly vyvinuty jednotkové testy pro white-box i black-box testování systému. Jako poslední bylo provedeno testování použitelnosti. Na závěr byla vytvořena uživatelská příručka, která čtenáře seznamuje s uživatelským rozhraním CRM aplikace a příručka pro administrátora, která slouží jako návod pro testování a nasazení systému. Obě jsou umístěny v přílohách. Výsledkem práce je funkční aplikace, která může být nasazena a používána pro poskytování CRM systému formou SaaS. U průběhu celého vývoje jsem se seznámil s novými metodikami, technikami a frameworky. V tomto směru pro mě byla práce velkým přínosem. 97

Závěr

Zhodnocení použitých technologií Při implementaci jsem narazil na několik komplikací vycházejících z omezení stanovených pro vývoj na platformě GAE. Některá omezení bylo možné nějakým způsobem obejít. Mnoho úsilí stálo zprovoznění frameworku JSF, který by bez provedení určitých změn nebylo možno použít. Spousta standardů a frameworků se ale použít vůbec nedala. Většina z nich je popsána na stránkách věnovaných vývoji na GAE. Ovšem stránky například nezmiňují to, že nelze použít implementace specifikace JSR 299 definující CDI pro platformu Java EE. Velkým usnadněním práce bylo použití frameworku Objectify sloužícího pro přístup k Datastore platformy GAE na místo low-level API, jehož použití by vyžadovalo nesrovnatelně větší množství práce. V průběhu vývoje došlo k migraci z verze Objectify 3.4 na verzi 4.0b1 (změna majoritní verze), díky které se vývoj prodloužil. Velmi se osvědčilo použití komponentového frameworku pro JSF s názvem PrimeFaces. Jeho použití můžu doporučit. Je po všech stránkách na vysoce kvalitní úrovni.

Popis další práce Vývoj takto komplexního systému není krátkodobou záležitostí. S příchodem nových zákazníků přicházejí i nové požadavky na implementaci rozšiřujících funkcí nebo na opravu defektů. V budoucnu budu tomto projektu nadále pokračovat. Otázkou není pouze vývoj, ale i další disciplíny spojené s projektem jako tvorba byznys strategie, marketing, prodej atd. Co se týče dalšího vývoje CRM systému, je v zásobě hned několik možností pro rozšíření: • Mobilní aplikace: Vývoj aplikací pro mobilní zařízení (chytré telefony, tablety) na platformě Android nebo operačním systému iOS, které by tvořili alternativu k CRM aplikaci. Součástí tohoto projektu by byl i vývoj REST webových služeb sloužících k integraci systému s aplikacemi. • Integrace rejstříků: Integrace webových služeb poskytovaných rejstříkem firem a rejstříkem dlužníků, které by sloužily pro usnadnění zadávání nových firem (našeptávání názvů firem a automatické načtení informací z rejstříku firem) a ověření věrohodnosti firem nebo kredibility. • Implementace Memcache API: Memcache API slouží pro krátkodobé ukládání dat, která jsou dostupná mezi různými instancemi aplikace nasazené na platformě GAE. • Implementace kampaní: V konkurenčních CRM systémech je často implementována možnost tvorby a sledování kampaní. Tuto funkci by 98

Popis další práce mohli někteří zákazníci postrádat. • Sdílení kalendáře: Implementace kalendáře a možností jeho sdílení s jinými systémy (Google Calendar, MS Outlook, iCal) pomocí exportování do formátu standardu pro výměnu kalendářových dat iCalendar. • Integrace sociální sítí: Prozkoumání možností integrace se sociálními sítěmi (Facebook, Twitter apod.) a implementace integrace.

99

Literatura [1]

ARLOW, Jim a NEUSTADT, Ila. UML 2 a unifikovaný proces vývoje aplikací. Brno: Computer Press, a.s., druhé vydání, 2007. ISBN 978-80251-1503-9.

[2]

BAXTER, Lincoln a KALTEPOTH, Christian. PrettyFaces Reference c Guide, [online]. OCPSoft, 2012. [cit. 13.11.2012]. Dostupné z: http: //ocpsoft.org/prettyfaces/docs

[3]

BERKA, Aleš: Řízení vztahů se zákazníky. Scientific papers of the University of Pardubice. Series D, Faculty of Economics and Administration. 2006 [cit. 14.9.2012], ISSN 1211-555X. Dostupné z: http://hdl.handle. net/10195/32290

[4]

BIEN, Adam. Real World Java EE Patterns – Rethinking Best Practices. press.adam-bien.com, první vydání, 2009. ISBN 978-05-570-7832-5.

[5]

BRUCKNER, Tomáš et al. Tvorba informačních systémů: Principy, metodiky, architektury. Praha: Grada Publishing, a.s., první vydání, 2012. ISBN 978-80-247-4153-6.

[6]

CERI, Stefano et al. Designing Data-Intensive Web Applications. San Francisco: Morgan Kaufmann, první vydání, 2003. ISBN 978-15-5860843-6.

[7]

CHLEBOVSKÝ, Vít. CRM - řízení vztahů se zákazníky. Brno: Computer Press, a.s., první vydání, 2005. ISBN 80-251-0798-1.

[8]

c CIVICI, Cagatay. PrimeFaces: User’s Guide 3.4, [online]. 2012. [cit. 13.11.2012]. Dostupné z: http://primefaces.googlecode.com/files/ primefaces_users_guide_3_4.pdf

[9]

COCKBURN, Alistar. Writing Effective Use Cases. Addison-Wesley Professional, první vydání, 2000. ISBN 978-02-017-0225-5.

[10] COPELAND, Lee. A Practitioner’s Guide to Software Test Design. Artech House, první vydání, 2004. ISBN 978-15-805-3791-9. 101

Literatura [11] DOHNAL, Jan. Řízení vztahů se zákazníky: procesy, pracovníci, technologie. Management v informační společnosti, Grada, 2002. ISBN 80-2470401-3. [12] GAMMA, Erich, HELM, Richard, JOHNSON, Ralph a VLISSIDES, John. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, první vydání, 1994. ISBN 978-02-016-33610. [13] GARTNER. Research Methodologies: Hype Cycles, [online]. Gartner c Inc., 2012 [cit. 6.9.2012]. Dostupné z: http://www.gartner.com/ technology/research/methodologies/hype-cycle.jsp c [14] GOGRID. GoGrid Pricing, [online]. GoGrid, 2012 [cit. 15.9.2012]. Dostupné z: http://www.gogrid.com/products/pricing [15] GONCALVES, Antonio. Beginning Java EE 6 Platform with GlassFish 3: From Novice to Professional. New York: Apress, první vydání, 2009. ISBN 978-14-302-1955-2. [16] GOOGLE APP ENGINE. Google App Engine Pricing, [online]. Google c App Engine, 2012. Poslední změna 26.6.2012 [cit. 15.9.2012]. Dostupné z: http://cloud.google.com/pricing/ [17] GOOGLE APP ENGINE. Developer’s Guide - Google App Engine, c [online]. Google App Engine, 2012. Poslední změna 26.6.2012 [cit. 21.10.2012]. Dostupné z: http://developers.google.com/appengine/ docs/ [18] GRADY, Robert B.. Practical Software Metrics for Project Management and Process Improvement. Prentice Hall, první vydání, 1992. ISBN 97801-372-0384-0. [19] HOMMEROVÁ, Dita. CRM v podnikových procesech. Praha: Grada Publishing, a.s., první vydání, 2012. ISBN 978-80-247-4388-2. [20] JACOBSON, Ivar, BOOCH, Grady a RUMBAUGH, James. The Unified Software Development Process. Addison-Wesley Professional, první vydání, 1999. ISBN 978-02-015-7169-1. [21] JENDROCK, Eric, EVANS, Ian, GOLLAPUDI, Devika, HASSE, Kim a SRIVATHSA, Chinmayee. The Java EE 6 Tutorial: Basic Concepts, Fourth Edition. Prentice Hall, čtvrté vydání, 2010. ISBN 978-01-3708185-1. [22] KOCH, Nora a KRAUS, Andeas. Towards a Common Metamodel for the Development of Web Applications. Third Int. Conference on 102

Literatura c Web Engineering (ICWE’03), LNCS 2722 Springer Verlag, 2003. Dostupné z: http://www.pst.informatik.uni-muenchen.de/personen/ kochn/ICWE2003-final-Koch-Kraus.pdf [23] KOZURUBA, Sergej. Model-based Requirements Analysis for the Development of adaptive RIAs. München, 2010. Master’s thesis. LudwigMaximilians-Universität. Institute for Informatics. Supervisor: Dr. Nora Koch. Dostupné z: http://uwe.pst.ifi.lmu.de/publications/ KozurubaDA.pdf [24] KROISS, Christian, KOCH, Nora a KOZURUBA, Sergej. UWE Metamodel and Profile 1.9: User Guide and Reference, [online]. München, 2011. Ludwig-Maximilians-Universität. Institute for Informatics. Technical Report 1101. Dostupné z: http://uwe.pst.ifi.lmu.de/download/ UWE-Metamodel-Reference-v1.9.pdf [25] KRUG, Steve. Don’t Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition. New Riders, druhé vydání, 2005. ISBN 97803-213-4475-5. [26] LARMAN, Craig. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. Prentice Hall PTR, třetí vydání, 2005. ISBN 978-01-314-8906-6. [27] MALKS, Dan, ALUR, Deepak a CRUPI, John. Core J2EE Patterns: Best Practices and Design Strategies. London: Pearson Education, první vydání, 2001. ISBN 978-01-306-4884-6. [28] MAXPROJEKT. Online CRM systém INEX, [online]. MAXprojekt s.r.o., c

2005-2012 [cit. 20.9.2012]. Dostupné z: http://www.inex-crm.cz/ [29] MELL, Peter a GRANCE, Timothy. The NIST Definition of Cloud Computing, [online]. NIST, listopad 2011. Special Publications, 800-145. Dostupné z: http://csrc.nist.gov/publications/nistpubs/800-145/ SP800-145.pdf [30] MORDANI, Rajiv. JSR 250: Common Annotations for the Java c Platform, [online]. Sun Microsystems, Inc., October 2009 [cit. 13.11.2012]. Dostupné z: http://download.oracle.com/otndocs/jcp/ common_annotations-1.1-mrel-oth-JSpec/ [31] MUIR, Pete a KING, Gavin. JSR 299: Contexts and Dependency Injection for the Java EE platform, [online]. CDI 1.1 Expert Group, c

September 2011 [cit. 13.11.2012]. Dostupné z: http://docs.jboss. org/cdi/spec/1.1.EDR1/ [32] NIELSEN, Jakob. Usability Engineering. San Francisco: Morgan Kaufmann, 1993. ISBN 1-12-518406-9. 103

Literatura [33] OMG UML. OMG Unified Modeling Language (OMG UML): Version 2.5 c FTF – Beta 1, [online]. Object Management Group, Inc., October 2012 [cit. 29.10.2012]. Dostupné z: http://www.omg.org/spec/UML/2.5 [34] PAN, Jiantao. Software Testing, [online]. Carnegie Mellon University, 18849b Dependable Embedded Systems. Spring 1999. [cit. 19.12.2012]. Dostupné z: http://www.ece.cmu.edu/~koopman/des_s99/sw_testing/ [35] PRESSMAN, Rodger S.. Software Engineering: a practitioner’s approach. McGraw-Hill Higher Education, páté vydání, 2001. ISBN 0-07-365578-3. c [36] RAYNET. RAYNET Cloud CRM: Demo, [online]. Raynet, s.r.o., 2012 [cit. 20.9.2012]. Dostupné z: https://raynet.cz/demo/ c [37] RAYNET. RAYNET Cloud CRM systém, [online]. Raynet, s.r.o., 2012 [cit. 20.9.2012]. Dostupné z: http://raynet.cz/ [38] ROSSI, Gustavo, PASTOR, Oscar, SCHWABE, Daniel a OLSINA, Luis. Web Engineering: Modelling and Implementing Web Applications. London: Springer, první vydání, 2008. ISBN 978-18-462-8922-4. [39] SALESFORCE.COM. Salesforce Pricing & Editions: Sales Cloud, [onc line]. Safesforce.com, Inc., 2000-2012 [cit. 15.9.2012]. Dostupné z: http: //www.salesforce.com/crm/editions-pricing.jsp [40] SALESFORCE.COM. CRM Company Information, [online]. Safesc force.com, Inc., 2000-2012 [cit. 20.9.2012]. Dostupné z: http://www. salesforce.com/company/ [41] SALESFORCE.COM. salesforce.com - Professional Edition: free 30-day c trial, [online]. Safesforce.com, Inc., 2000-2012 [cit. 20.9.2012]. Dostupné z: https://eu2.salesforce.com/ [42] SALESFORCE.COM. Salesforce.com Announces Fiscal 2012 Fourth c Quarter and Full Year Results, [online]. Safesforce.com, Inc., 2000-2012 [cit. 20.9.2012]. Dostupné z: http://www.salesforce.com/company/ news-press/press-releases/2012/02/120223.jsp c [43] SCHNITZER, Jeff. Objectify v4: User’s Guide, [online]. 2012. Poslední změna 30.10.2012 [cit. 15.11.2012]. Dostupné z: https://code.google. com/p/objectify-appengine/wiki/Introduction [44] SMITH, David Mitchell. Hype Cycle for Cloud Computing, 2012, [online]. c Gartner Inc., 2012 [cit. 6.9.2012]. Research G00230930. Dostupné z: http://www.gartner.com/id=2102116 104

Literatura [45] STRATEGI CONSULTING. Abstraction: The key understanding cloud computing, [online]. Strategi Consulting c LLC,

2009 [cit. 4.9.2012]. Dostupné z: http://www. strategi-consulting.com/OurIdeas/Blog/tabid/108/EntryId/ 3/Abstraction-The-key-understanding-cloud-computing.aspx [46] TIDWELL, Jenifer. Designing Interfaces. O’Reilly Media, druhé vydání, 2012. ISBN 978-14-493-7970-4. [47] VITVAR, Tomáš. Middleware and Web Services: Lecture 1 - Motivation c and Course Overview, [online]. FIT ČVUT, 2011. Poslední změna 13.8.2011 23:22 [cit. 7.9.2012]. Dostupné z: https://edux.fit.cvut.cz/ oppa/MI-MDW/prednasky/mdw-1.pdf [48] VOŘÍŠEK, Jiří et al. Principy a modely řízení podnikové informatiky. Praha: Oeconomica, 2008. ISBN 978-80-245-1440-6.

105

Příloha

Seznam použitých zkratek Acronyms API Application Programming Interface. CASE Computer-Aided Software Engineering. CDI Contexts and Dependency Injection. CRM Customer Relationship Management. CSS Cascading Style Sheets. CSV Comma-separated values. DAO Data Access Object. DBMS Database Management System. DOM Document Object Model. EIS Enterprise Information System. EJB Enterprise Java Beans. EL Expression Language. ERP Enterprise Resource Planning. FURPS Functional, Usability, Reliability, Performance, Suppotability. GAE Google App Engine. GoF Gang of Four. 107

A

Slovník HTML HyperText Markup Language. HTTP Hypertext Transfer Protocol. HTTPS Hypertext Transfer Protocol Secure. IaaS Infrastructure as a service. ICT Information and Communication Technologies. IDE Integrated Development Environment. IS/ICT Information Systems / Information and Communication Tech.. Java EE Java Enterprise Edition. Java SE Java Standard Edition. JAX-RS Java API for RESTful Web Services. JAX-WS Java API for XML Web Services. JAXB Java Architecture for XML Binding. JDBC Java Database Connectivity. JDO Java Data Objects. JMS Java Message Service. JNDI Java Naming and Directory Interface. JPA Java Persistence API. JSF JavaServer Faces. JSP JavaServer Pages. JSR Java Specification Request. JVM Java Virtual Machine. MVC Model–view–controller. NIST National Institute of Standards and Technology U.S. Department of Commerce. OOD Object-oriented design. OOP Object-oriented programming. 108

Slovník PaaS Platform as a service. POJO Plain Old Java Object. RAM Random Access Memory. RDBMS Relational Database Management System. REST Representational State Transfer. SaaS Software as a service. SAX Simple API for XML. SDK Software Development Kit. SEO Search Engine Optimization. SLA Service Level Agreement. TASW Typový aplikační software. UI User Interface. UML Unified Modeling Language. UP Unified Process. URL Uniform Resource Locator. UWE UML-based Web Engineering. WAR Web Archive. WebML Web Modeling Language. XHTML Extensible HyperText Markup Language. XML Extensible Markup Language.

109

Příloha

Obrázky a modely Případ užití - «identifikátor»: «Název případu užití» Parent: (Předek) «id předka případů užití» Context of Use: (Kontext použití) «bližší specifikace cíle případu užití» Scope: (Rámec) «název navrhovaného systému nebo jeho části» Level: «{cíl uživatele, funkce}» Primary actor: (Primární aktér) «název aktéra, který používá systém za účelem využití jeho služeb» Stakeholders and Interests: (Zainteresované osoby a zájmy) «seznam zainteresovaných osob a jejich klíčových zájmů v případu užití» «– Osoba: zájem» Preconditions: (Vstupní podmínky) «co musí být splněno před spuštěním případu užití» Success End: (Úspěšný konec) «co musí být splněno při úspěšném ukončení» Trigger: (Spouštěč)«co spouští případ užití, může se jednat o časovou událost» Main success scenario: (Hlavní scénář) «typický úspěšný scénář, který nezahrnuje podmínky» «krok #» «popis akce» Označení kroků ve scénáři, který je potomkem jiného scénáře: «#a (#b)» «krok „a“ tohoto scénáře je zděděný z kroku „b“ předka» «#a (o#b)» «krok „a“ tohoto scénáře překrývá krok „b“ předka» «#a» «krok „a“ je nový, není v předkovi» Alternative flows: (Alternativní běh) «alternativní scénář s úspěšnými nebo chybovými variantami hlavního scénáře» «krok alternativy #» «popis akce» Special Requirements: (Speciální požadavky) «související nefunkční požadavky» Technology and Data Variations: (Technologiecké a datové alternitivy) «popis alternativy vstupně-výstupní metody nebo datového formátu» «krok alternativy #» «popis alternativy» Frequency of Occurrence: (Frekvence výskytu) «jak často se případ užití spouští {často, velmi často, málo}»

Tabulka B.1: Šablona případu užití 111

B

B. Obrázky a modely UWE stereotyp

Iko- Bázová na třída UML

Význam

Navigační diagram «externalNode»

class

Uzel, který nepatří do struktury aplikace.

«index»

class

Index odkazů na instance obsahových tříd.

«menu»

class

Menu se používá k řešení více alternativních navigačních cest z jednoho uzlu.

«navigationClass»

class

«navigationLink»

association

«navigationProperty»

property

Navigovatelný uzel hypertextové struktury. Odkaz, který spojuje jakékoli uzly navigačního diagramu kromě procesních tříd. Atribut navigační třídy, který je odvozen od asociované vlastnosti obsahové třídy.

«processClass» «processLink»

class association

Reprezentuje spuštění byznys procesu. Spojení procesních tříd s ostatními uzly.

«query»

class

Získání obsahu z datového zdroje (dotaz).

Prezentační diagram (bázovou třídou pro všechny třídy je class) «anchor»

Odkaz umožňuje uživateli přechod v rámci navigačního modelu.

«button»

Reprezentuje tlačítko, které slouží k vyvolání nějaké akce (většinou odeslání formulářových dat).

«image»

Zobrazení obrázku.

«inputForm»

Uskupuje elementy sloužící ke sběru a zpracování dat.

«iteratedPresentation Group»

Slouží pro modelování seznamů. Kontejner jehož obsah je prezentován pro každý prvek množiny (seznamu prvků).

«presentationPage»

Kořenová prezentační třída. Nesmí být zahrnuta v jiné prezentační skupině.

«presentationAlternatives»

Množina prezentačních skupin, které mohou být v rámci oblasti prezentovány. Viditelná je vždy jen jedna.

«presentationGroup»

Definuje skupinu elementů v rámci jedné oblasti stránky.

«selection»

Výběr umožňuje zvolit jednu a více hodnot z množiny alternativ.

«tab»

Reprezentuje záložky, které slouží k organizaci informací do skupin, z nichž jedna je vždy v popředí.

«textInput»

Pole, do kterého uživatel zadává textový vstup.

«text»

Zobrazení statického, needitovatelného textu.

Tabulka B.2: UWE profil 1.9 - Výčet použitých stereotypů (zdroj: Kroiss [24]) 112

Obrázek B.1: Salesforce.com - Editace příležitosti (zdroj: Salesforce.com [41])

Obrázek B.2: Raynet Cloud CRM - Editace obchodního případu (zdroj: Raynet [36])

113

B. Obrázky a modely

Obrázek B.3: Mockup prototyp - Seznam účtů

114

Obrázek B.4: Mockup prototyp - Filtrování seznamu účtů

Obrázek B.5: Mockup prototyp - Smazání účtu

Obrázek B.6: Mockup prototyp - Detail účtu

115

B. Obrázky a modely

Obrázek B.7: Mockup prototyp - Úprava účtu

116

Obrázek B.8: Mockup prototyp - Záložka komunikace

Příloha

Uživatelská příručka Tato příručka slouží uživateli CRM systému jako manuál k jeho použití. Seznamuje uživatele s uživatelským rozhraním – rozložením stránky, položkami menu, funkcemi, ovládacími prvky a způsoby interakce se systémem.

C.1

První pohled na aplikaci

Stránka CRM aplikace je rozdělena do čtyř hlavních regionů viz obrázek C.2. Hlavička (nahoře) obsahuje logo a v pravé části „top-bar menu“. V patičce (dole) jsou údaje o autorských právech. V levém sloupci je umístěno hlavní menu. Část s proměnným obsahem stránky je napravo.

C.2

Hlavní menu

Hlavní menu obsahuje jedenáct položek (viz obrázek C.1). Nástěnka je výchozí stránkou aplikace, na které jsou umístěny různé přehledy a důležité informace. Položky kategorií „Seznam kontaktů“, „Business“ a „Aktivity“ slouží pro přechod na stránky se seznamy, které obsahují prvky různých obchodních entit – firem, osob, obchodních případů, produktů, ceníků a aktivit (viz např. seznam firem na obrázku C.2). Obrázek C.1: UI Položky „Události“, „Úkoly“ a „Telefonáty“ jsou Hlavní menu pouze zkratkami pro přechod na předfiltrovanou stránku se seznamem aktivit. Položka „Report“ je určena pro přechod na stránku, která slouží ke zobrazení parametrizovatelných grafů zobrazujících výsledky obchodních aktivit ve zvolených časových intervalech.

117

C

Obrázek C.2: UI - Seznam firem

C. Uživatelská příručka

118

C.3. Top-bar menu

C.3

Top-bar menu

Top-bar menu zahrnuje tři skupiny položek viz obrázek C.3. Zleva jsou jimi připomínky ( „Alarm“, „Chat“ a „Varování“), uživatelský účet a systémové akce ( „Nastavení“, „Nápověda“ a „Odhlášení“).

Obrázek C.3: UI - Top-bar menu Položky první skupiny slouží pro přechod na seznamy konkrétních připomínek. Mohou být označeny číslem, které vyjadřuje počet událostí, na které ještě nebyl přihlášený uživatel upozorněn. Dle obrázku C.3 existuje 12 připomínek na různé aktivity, žádné upozornění na komunikaci a 1 varování. Prostřední položka zobrazuje jméno přihlášeného uživatele a slouží rovněž jako odkaz pro přechod na nastavení uživatelského účtu. Pod položkou „Nastavení“ je možno spravovat veškerá nastavení CRM aplikace s ohledem na práva přihlášeného uživatele. Tlačítko „Nápověda“ slouží pro zobrazení nápovědy k použití aplikace. Posledním tlačítkem je „Odhlášení“, které slouží k odhlášení z aplikace a přechod na stránku s přihlášením.

C.4

Obsah stránek

Prostor pro obsah stránek je zobrazen v pravé části view aplikace. Každá stránka má v levém horním rohu tohoto prostoru zobrazeno logo, které vystihuje její obsah viz logo kontaktu na obrázku C.4.

Obrázek C.4: UI - Akční tlačítka Následuje název entity a detailní informace přibližující danou entitu. Na obrázku C.4 je to jméno osoby a společnost, ve které je primárně zaměstnána. V pravé části jsou akční tlačítka pro danou stránku. V tomto případě tlačítka „Nový“, „Uložit“ a „Smazat“. Akční tlačítka se liší dle zobrazené stránky (srovnej s tlačítky na stránce se seznamem firem viz obrázek C.2). Tato tlačítka existují celkem čtyři: • Uložit: uložení stavu upravované entity • Nový: navázaní nové entity na aktuální 119

C. Uživatelská příručka • Smazat: smazání aktuální entity • Export: export prvků seznamu zobrazené tabulky do různých formátů

C.4.1

Práce se seznamy

Častým obsahem stránek jsou seznamy, které mají zpravidla mnoho položek a pro jejich zobrazení je nutno několika stránek. Pro přechod mezi stránkami se používají tlačítka v oblasti stránkování seznamu. Tato oblast je umístěna pod seznamem prvků viz obrázek C.2. Počet prvků na stránce lze zvolit. K usnadnění vyhledání prvků lze seznamy filtrovat a řadit. Na obrázku C.5 je ukázka těchto možností.

Obrázek C.5: UI - Seznamy Ve sloupci „Stav“ je nastaven filtr na hodnotu „Aktivní“, sloupec „Vlastník“ je filtrován podle řetězce „martin“ a na celý seznam je na závěr aplikováno seřazení podle sloupce „Hodnocení“. Výsledkem je daleko kratší a přehlednější seznam položek.

C.5

Dialogová okna

Pro vytváření nových entit, úpravu vazeb a potvrzování důležitých akcí jsou použita modální dialogová okna. Ta se po aktivaci zobrazí na popředí stránky, kterou uživatel právě prochází a čekají na interakci s uživatelem viz obrázky C.6 nebo C.7.

Obrázek C.6: UI - Dialog smazání firmy Dialogová okna je možno zavřít kliknutím na křížek v pravém horním rohu okna. Typicky má okno dvě tlačítka – tlačítko pro potvrzení provedení akce („Vytvořit“, „Ok“, „Smazat“) a odmítnutí ( „Zrušit“). 120

C.6. Zadávání vstupu

C.6

Zadávání vstupu

Pro zadávání vstupních informací uživatelem je využito mnoho standardních i moderních technik (viz vstupní pole na obrázku C.7).

Obrázek C.7: UI - Dialog přidání firmy Některá vstupní pole jsou opatřena maskou, která definuje přesný formát vstupu. Na obrázku C.8 je maska ve formátu „a*-999-a999“. Za znak „a“ je možno dosadit kterékoli písmeno, za znak „9“ číslice, za „*“ jakýkoli znak. Ostatní znaky masky (v tomto případě „-“) jsou fixní. Formát masky je možné customizovat po stisku tlačítka napravo od vstupního pole.

Obrázek C.8: UI - Maska vstupního pole 121

C. Uživatelská příručka U dlouhých seznamů, které slouží pro výběr položek, je urychleno vyhledávání prvků možností zadání textového filtru, který ze seznamu odebere prvky, jež neodpovídají jeho hodnotě (viz obrázek C.9).

Obrázek C.9: UI - Výběr položky s filtrováním

Obrázek C.10: UI - Hodnocení

Pro zadání číselného hodnocení entity je použita speciální komponenta, která zobrazuje hvězdičky. Počet výrazných hvězdiček určuje číselnou hodnotu hodnocení. Rozsah hodnocení je v případě obrázku C.10 v rozmezí „0..5“. Hodnota „0“ se nastavuje stisknutím kulatého tlačítka s pomlčkou v levé části. Pro zadávání vstupů je použito mnoho dalších komponent jako např. kalendář, „slider“, automatické dokončování vstupu atd. Způsob jejich ovládání je dostatečně intuitivní.

C.7

Notifikace systému

Systém uživatele několika různými způsoby notifikován o činnostech, které provádí systém. Příkladem je dočasné (pětisekundové) zobrazení oznámení o vytvoření nové entity (viz obrázek C.11), smazání entity apod. nebo zobrazení informací o chybném zadání vstupu ve formulářích (viz obrázek C.7).

Obrázek C.11: UI - Systémová notifikace

122

Příloha

Příručka administrátora Tato příručka slouží administrátorovi CRM systému jako návod k instalaci a provozu systému. Obsahuje popis lokálního testování z vývojového prostředí, nasazení na GAE a možnosti nastavení aplikace v administrační konzoli GAE.

D.1

Lokální testování

Nejsnadnější cestou pro lokální otestování chodu aplikace je instalace vývojového prostředí Eclipse IDE s pluginem „Google plugin for Eclipse“ a import projektu s CRM systémem. Prerekvizitou je Java SDK ve verzi 6 a vyšší (instalační soubor dostupný na přiloženém CD ve složce inst). Postupujte dle těchto kroků: 1. Instalace IDE: Stáhněte Eclipse IDE z oficiálních webových stránek http://www.eclipse.org/downloads/ dle vašeho operačního systému a nainstalujte jej. Pro vývoj byl použit balíček „Eclipse IDE for Java EE Developers“ a verze „Eclipse Juno (4.2) SR1 Packages“. Tato verze je dostupná i na přiloženém CD ve složce inst. 2. Instalace Google Plugin for Eclipse: Zvolte Help > Install New Software.. v Eclipse. Do textového pole Work with: zadejte adresu http://dl.google.com/eclipse/plugin/4.2. V dalším kroku vyberte komponenty „Google App Engine Java SDK“ a „Google Plugin for Eclipse“ a pokračujte v instalaci. Alternativou k online instalaci je instalace z lokálního archivu. Ten je dostupný na přiloženém CD ve složce inst. Archiv rozbalte, ve stejném okně jako v předchozím případě zvolte možnost Add.. a přidejte složku, do které jste rozbalili plugin. 3. Import projektu s CRM systémem: Projekt je dostupný na přiloženém CD ve složce src/impl. Zvolte File > Import.. > Existing Projects into Workspace v Eclipse, vyberte složku s projektem a potvrďte. 123

D

D. Příručka administrátora 4. Testování systému: Označte projekt v Eclipse a zvolte Run > Run As > Web Application. Projekt bude sestaven, nasazen na lokální server a dostupný na localhostu. Eclipse automaticky spustí webový prohlížeč a přistoupí na adresu aplikace.

D.2

Nasazení CRM systému na GAE

Pro nasazení CRM systému je nutné provést první tři kroky předešlého návodu D.1. Poté může být systém nasazen na platformu GAE. Pro nasazení je nutné mít na GAE vytvořen účet a prostor, do kterého bude aplikace nasazena: 1. Vytvoření prostoru pro aplikaci: Ve webovém prohlížeči přejděte na adresu http://appengine.google.com. Zvolte možnost vytvoření aplikace Create Application (tento krok vyžaduje přihlášení pomocí účtu na Google). Zadejte identifikační jméno aplikace a postupujte podle dalších instrukcí k vytvoření aplikace. 2. Nastavení projektu v Eclipse: Zvolte Project > Properties > Google > App Engine v Eclipse. Do textového pole Deployment > Application ID zadejte identifikační jméno vaší aplikace . Alternativou je provedení tohoto nastavení v souboru appengine-web.xml viz kód D.1. 3. Nasazení aplikace: Zvolte Deploy to App Engine.. v rozbalovacím menu tlačítka GDT Pulldown umístěného v „tool baru“ Eclipse (nutno zapnout přes Window > Customize Perspective..) a potvrďte akci pro nasazení. 4. Ověření dostupnosti aplikace: Zadejte do webového prohlížeče adresu vaší aplikace ve formátu http://.appspot.com. Zdrojový kód D.1: appengine-web.xml 1 2 3 4 5 6

app−i d 1 ...

D.3

Správa aplikace v administrační konzoli

Platforma GAE poskytuje administrační konzoli, ve které je možné sledovat a spravovat nasazené aplikace viz obrázek D.1. Po nasazení aplikace není potřeba provést žádnou významnou změnu oproti výchozímu nastavení. V konzoli je dostupný procentuální přehled čerpaných služeb pro aktuální den. Kvóty čerpaných služeb se obnovují denně. Pokud některá kvóta překročí limit, aplikace se stane nedostupnou. 124

D.3. Správa aplikace v administrační konzoli

Obrázek D.1: Administrační konzole GAE

Na nástěnce jsou zobrazen graf ilustrující zvolený způsob zatížení aplikace (počet požadavků za sekundu, využití paměti, zátěž procesoru aj.) ve zvoleném časovém období (hodiny, dny). V konzoli je dále možné zobrazit log aplikace, spravovat verze (na GAE lze nasadit několik verzí, což je užitečné pro testování), zobrazit seznam naplánovaných úloh, zobrazit historii plateb za spotřebované služby platformy, spravovat nastavení aplikace a práva pro členy vývojového týmu. Důležitou funkcí je administrace Datastore. Umožňuje zobrazení uložených entit, jejich statistik, zálohování, mazání a provádění GQL dotazů nad entitami (podobné SQL dotazům).

125

Příloha

Obsah přiloženého CD

README.txt .......................................... popis obsahu CD src impl...................................zdrojové kódy implementace thesis ...................... zdrojová forma práce ve formátu LATEX text ....................................................... text práce DP_Zahradnicky_Martin_2013.pdf ...... text práce ve formátu PDF inst.................soubory potřebné ke spuštění aplikace ve Windows jdk-6u27-windows-x64.exe ................ Java Development Kit 6 eclipse-jee-juno-win32-x86_64.zip..................Eclipse IDE com.google.gdt.eclipse.suite.4.2.update.site_3.1.2.zip Google Plugin for Eclipse 127

E