Sem vložte zadání Vaší práce

Sem vložte zadání Vaší práce.

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

Bakalářská práce

Případová studie vytvoření systému pro moderní obchodování Tomáš Ďuračka

Vedoucí práce: Ing. Pavel Náplava

14. května 2014

Poděkování V první řadě děkuji vedoucímu této bakalářské práce Ing. Pavlu Náplavovi za konzultace, postřehy a nápady, které mi během její tvorby poskytoval, a odborným konzultantům Ing. Tomáši Krátkému, Ing. Robertu Perglovi, Ph.D. a Ing. Zdeňku Rybolovi za jejich praktické podněty v oblasti SW inženýrství. Dále děkuji celé své rodině a přítelkyni za jejich podporu, která mi přináší tolik potřebný klid. A speciálně pak děkuji svému dědovi Ernestu Ďuračkovi, který mě od malička vedl k informačním technologiím a postojům, které zastávám.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval(a) samostatně a že jsem uvedl(a) 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 spracová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 14. května 2014

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

České vysoké učení technické v Praze Fakulta informačních technologií c 2014 Tomáš Ďuračka. 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 Ďuračka, Tomáš. Případová studie vytvoření systému pro moderní obchodování. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2014.

Abstrakt Tato bakalářská práce se zabývá zpracováním případové studie vytvoření systému pro moderní obchodování s cílem zhodnotit v ní pro konkrétního zákazníka smysluplnost pořízení tohoto systému a v případě, že je pořízení vyhodnoceno jako smysluplné, mu sestavit obchodní nabídku. Zmíněného cíle bylo dosaženo provedením analýz systému pro moderní obchodování a konkrétního zákazníka, které byly následně porovnány z hlediska obchodních cílů, pomocí čehož se zjistilo, zda je vytvoření systému pro zákazníka smysluplné. Po zjištění, že je pořízení systému smysluplné, byla vytvořena obchodní nabídka, která je založena na informacích z provedené analýzy požadavků zákazníka na systém a z navržené architektury systému. Využitím uvedeného postupu lze díky datům z provedených analýz již před začátkem tvorby systému rozhodnout, zda zákazník může prostřednictvím systému dosáhnout svých obchodních cílů, a minimalizovat riziko jak nereálně nastavených termínů, tak špatně odhadnutého rozpočtu, jejichž správným odhadem lze přispět k navázání dlouhodobé spolupráce se spokojeným zákazníkem. Klíčová slova případová studie, moderní obchodování, obchodní nabídka, smysluplnost pořízení systému, obchodní analýza, analýza požadavků, SW architektura, 4+1 architektura

ix

Abstract This thesis deals with writing a case study of creation of the modern trading system in order to evaluate meaningfulness of system acquisition for the customer and to make a business offer if the acquisition is evaluated as meaningful. The goal was reached by performing analyzes of the modern trading system and the customer which were compared by business goals and the result answered a question whether the creation of the modern trading system is meaningful and if so a business offer, which is based on information known from requirements analysis and SW architecture, was made. Using this procedure it is possible to decide whether the customer can reach his business goals using the system and minimize the risk of unreal terms and small budget. Long-term cooperation with satisfied customer can be established if terms and budget are set correctly. Keywords case study, modern trading, business offer, meaningfulness of system acquisition, business analysis, requirements analysis, SW architecture, 4+1 architecture

x

Obsah Úvod

1

1 Analýza systémů pro moderní obchodování 1.1 Specifikace pojmu moderní obchodování . . . . . . . . . . . . . 1.2 Analýza existujících systémů . . . . . . . . . . . . . . . . . . .

3 3 3

2 Obchodní analýza systémů pro moderní obchodování 2.1 Porovnání se systémy pro běžné obchodování . . . . . . . . . . 2.2 Analýza obchodních cílů . . . . . . . . . . . . . . . . . . . . . . 2.3 Podmínky pro dosažení obchodních cílů . . . . . . . . . . . . .

7 7 8 8

3 Obchodní analýza zákazníka 3.1 Současná obchodní činnost . . . . . 3.2 Očekávaná budoucí obchodní činnost 3.3 SWOT analýza . . . . . . . . . . . . 3.4 Analýza obchodních cílů . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

11 11 11 11 12

4 Vyhodnocení smysluplnosti pořízení systému zákazníkem

13

5 Obchodní nabídka pro zákazníka 5.1 Způsob prodeje . . . . . . . . . . 5.2 Roadmapa implementace . . . . 5.3 Kalkulace . . . . . . . . . . . . . 5.4 Součinnost zákazníka . . . . . . . 5.5 Pravidla pro akceptaci systému .

15 15 15 16 17 17

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

6 Analýza požadavků zákazníka na systém 19 6.1 Problém –– co komu vadí? . . . . . . . . . . . . . . . . . . . . . 19 6.2 Účel –– k čemu systém slouží a jaký užitek komu přinese? . . . 19 xi

6.3 6.4 6.5 6.6 6.7 7 SW 7.1 7.2 7.3 7.4

Popis problémové domény – co systém dělá a s kým při tom interaguje? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ontologická analýza problémové domény . . . . . . . . . . . . . Role uživatelů . . . . . . . . . . . . . . . . . . . . . . . . . . . . Funkční požadavky . . . . . . . . . . . . . . . . . . . . . . . . . Nefunkční požadavky . . . . . . . . . . . . . . . . . . . . . . . .

19 21 22 23 30

architektura systému Konceptuální (logický) pohled Modulární (vývojový) pohled Procesní (koordinační) pohled Fyzický pohled . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

31 31 32 33 34

8 Zhodnocení případové studie 8.1 Vliv přípravy na sestavení splnitelné nabídky 8.2 Návratnost investovaného času . . . . . . . . 8.3 Obecná využitelnost myšlenek . . . . . . . . . 8.4 Přizpůsobení jinému zákazníkovi . . . . . . . 8.5 Silné stránky . . . . . . . . . . . . . . . . . . 8.6 Slabé stránky . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

37 37 37 38 38 38 39

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Závěr

41

Literatura

43

A Slovník pojmů

45

B Seznam použitých zkratek

47

C Obsah přiloženého CD

49

xii

Seznam obrázků 3.1

SWOT analýza . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

5.1

Ganttův diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

6.1 6.2 6.3 6.4 6.5 6.6 6.7

Konceptuální diagram . . . . . . . . UC diagram – role uživatelů . . . . . UC diagram – přehled . . . . . . . . UC diagram – uživatel . . . . . . . . UC diagram – nepřihlášený uživatel UC diagram – přihlášený uživatel . . UC diagram – správce . . . . . . . .

. . . . . . .

21 22 23 24 25 27 29

7.1 7.2 7.3

Logický diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagram komponent . . . . . . . . . . . . . . . . . . . . . . . . . . Diagram nasazení . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31 32 35

xiii

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

Seznam tabulek 5.1

Kalkulace ceny za vývoj systému . . . . . . . . . . . . . . . . . . .

xv

16

Úvod V dnešní době rozvoje informačních technologií existuje na trhu mnoho malých společností a osob samostatně výdělečně činných, které podnikají v oblasti tvorby webových aplikací. Častým problémem, se kterým jsem se při spolupráci s některými z nich setkal, je absence zkušených lidí na pozicích s odpovědností za zpracování a dodání požadovaných aplikací. Právě absence těchto lidí z mých zkušeností vede k tomu, že se ve společnostech nedoceňuje význam počáteční analýzy zákazníka ani aplikace, a tedy se nezpracovávají. Bez těchto analýz však neexistují podklady ani pro kvalifikovaný odhad rozsahu, termínů a odpovídající ceny prací na vývoji aplikace, ani pro návrh řešení na dosažení obchodních cílů zákazníka. Tyto nedostatky ale mohou ve výsledku vést k nespokojenosti zákazníka s dodanou aplikací i v případě, že naplňuje všechny zákazníkovy požadavky, jelikož jejím využitím nedosahuje svých obchodních cílů, a z tohoto důvodu pro něj její pořízení nebylo smysluplné. Cílem této práce je tedy zhodnotit v případové studii, zda je pro konkrétního zákazníka pořízení systému pro moderní obchodování smysluplné, a v kladném případě mu sestavit obchodní nabídku na implementaci systému. Smysluplnost pořízení systému zhodnotím porovnáním obchodních cílů, které systém umožňuje naplnit, a obchodních cílů, které zákazník potřebuje naplnit. Pokud dojdu k závěru, že je pořízení systému pro zákazníka smysluplné, provedu analýzu požadavků zákazníka na systém a navrhnu architekturu systému. Na základě těchto údajů sestavím obchodní nabídku, která bude obsahovat především informace o ceně, termínech a nutné součinnosti ze strany zákazníka. Obchodní cíle, které zákazník potřebuje naplnit, určím z příležitostí a silných stránek identifikovaných ve SWOT analýze současné obchodní činnosti zákazníka. Pro zjištění obchodních cílů, které systém umožňuje naplnit, nejprve specifikuji moderní obchodování, aby bylo zřejmé, jakým způsobem probíhá, a následně na základě této informace identifikuji a zanalyzuji podobné existující systémy. Nakonec provedu obchodní analýzu systému, ve které porovnám výhody a nevýhody existujících systémů se systémem pro moderní obchodování a vytipuji obchodní cíle, které systém umožňuje naplnit. 1

Kapitola

Analýza systémů pro moderní obchodování Účelem této kapitoly je specifikovat pojem moderní obchodování a provést analýzu podobných existujících systémů.

1.1

Specifikace pojmu moderní obchodování

Pojem moderní obchodování představuje centralizovaný elektronický prodej a nákup zboží založený na využití kombinace různých způsobů prodeje zboží, což prodejci umožní oslovení širší skupiny potenciálních kupců, a zvýší tak šanci na odkup zboží. Pro účely navrhovaného systému budu pod tímto pojmem uvažovat tři způsoby prodeje zboží. Konkrétně se jedná o prodej prostřednictvím inzercí, aukcí a slev.

1.2

Analýza existujících systémů

V současné době jsem na trhu nenalezl žádné existující řešení systému pro moderní obchodování, který by splňoval mou specifikaci. Existují však systémy, nazval jsem je systémy pro běžné obchodování, které implementují vždy jeden ze způsobů prodeje. Příklady systémů pro běžné obchodování jsem zvolil annonce.cz (inzerce), aukro.cz (aukce) a slevomat.cz (slevy).

1.2.1

Aukční systémy

Zástupcem této skupiny systémů jsem zvolil aukční portál aukro.cz, který se na trhu pohybuje už od roku 2003 a do roku 2012 se na něj zaregistrovalo 3

1

1. Analýza systémů pro moderní obchodování 2 500 000 uživatelů, kteří pomocí něho prodají zhruba 32 000 kusů zboží denně, což je dohromady zhruba 12 000 000 kusů zboží ročně [1]. Výhody • Od roku 2012 si mohou uživatelé své zboží vyzvednout v kamenné pobočce (AukroPoint). • Od roku 2011 lze za zboží platit platební kartou, online převodem, složenkou, případně převodem mezi aukro.cz účty pomocí PayU. • Zboží s možností okamžitého nákupu lze koupit i bez registrace. • Celý webový portál je optimalizován i pro mobilní telefony. • Uživatelská podpora včetně dobře zpracované nápovědy. Nevýhody • Náročný a zdlouhavý proces nutný pro zahájení prodeje zboží. – Pro zahájení prodeje se musí uživatel zaregistrovat a vyčkat doručení dopisu s aktivačním kódem, který přijde poštou do 14 dní. – Před začátkem prodeje je také nutné nastavit službu PayU, pomocí které jsou vypláceny platby za prodané zboží. • Mnoho poplatků za prodej zboží, které se liší dle vybrané kategorie. – – – –

Poplatek za vystavení nabídky. Provize z uskutečněného prodeje. Poplatek za uskutečněný prodej uměleckého díla. Volitelný poplatek za propagaci nabídky.

• Bez registrace nelze přihazovat do probíhající aukce zboží.

1.2.2

Slevové systémy

Zástupcem skupiny systémů zprostředkovávajících prodej zboží se slevou jsem vybral slevomat.cz, který je na českém trhu od roku 2010 a od té doby se na něj zaregistrovalo více než 1 000 000 uživatelů, kteří již nakoupili více než 5 800 000 voucherů, čímž ušetřili přes 4 000 000 000 Kč [2]. Výhody • Možnost přihlášení pomocí aplikace facebook.cz bez nutnosti registrace na slevomat.cz. • Testování jednotlivých slev včetně vydání recenze zaměstnancem slevomat.cz. • Věrnostní programy a místo peněz kredity, které lze získat různými formami a uplatnit je při nákupu voucheru. 4

1.2. Analýza existujících systémů • Volitelné zajištění logistiky a skladování zboží pro prodejce – projeví se v individuálním navýšení provize. • Jednoduchý systém zpoplatnění služeb formou propagačních balíčků. Dle výběru balíčku je stanovena fixní výše provize za každou prodanou položku v dané nabídce. Nevýhody • Ověřování nabízené položky, která nemusí být z nějakého důvodu schválena. Pokud však schválena je, tak je následně třeba zaslat ještě vzorek nabízené položky k posouzení kvality. • Prodávat mohou pouze společnosti, které mají k produktu webovou prezentaci s ceníkem, kde je uvedena původní cena bez slevy. Nepodnikající fyzické osoby nemohou prodávat.

1.2.3

Inzertní systémy

Zástupcem skupiny systémů zprostředkovávajících prodej zboží pomocí inzerce jsem vybral portál annonce.cz, který je na trhu již od roku 1997 a od té doby získal zhruba 300 000 registrovaných uživatelů, kteří na portál vloží zhruba 200 000 inzerátů denně [3]. Výhody • Vložení inzerce je možné bez registrace. • Vložení soukromé inzerce klasickým fontem zdarma (kromě vybraných rubrik). • Každý vložený inzerát je zároveň otištěn v novinách – 1 otištění klasickým fontem zdarma. • Volitelné zpoplatněné služby sloužící k podpoření prodeje zboží. • Zpoplatněné vložení inzerátu po telefonu, případně pomocí SMS. Nevýhody • Nelze vložit inzerci pouze na webový portál bez otištění v novinách. • Zpoplatnění podnikatelské inzerce.

5

Kapitola

Obchodní analýza systémů pro moderní obchodování Účelem této kapitoly je identifikovat výhody systémů pro moderní obchodování a obchodní cíle, kterých lze při dodržení předepsaných podmínek jejich využitím dosáhnout.

2.1

Porovnání se systémy pro běžné obchodování

Běžné obchodování je, na rozdíl od moderního, založeného na kombinaci více různých způsobů prodeje zboží, obvykle založeno pouze na jednom jediném způsobu prodeje zboží, například pouze pomocí aukce. Bezesporu nejdůležitější výhodou systémů pro moderní obchodování je jejich centralizovanost, díky které uživatel může spravovat všechny údaje na jednom místě, což umožňuje využití jediného účtu pro veškeré služby, a není tedy nutné pamatovat si více než jedny přístupové údaje, dobíjet peníze na více účtů, pamatovat si více hesel, případně procházet více aplikací pro změnu osobních údajů. Další výhodou, ale zároveň i nevýhodou, je jejich široké zaměření, které umožňuje oslovení velké skupiny lidí, kteří by službu mohli využít, což se v případě jejich zájmu projeví ve vyšší návštěvnosti, a tedy větší šanci pro prodejce naleznout kupce svého zboží. Prodejce, který prodá své zboží, bude mít motivaci vracet se s dalším zbožím a doporučit systém dalším lidem. Větší návštěvnost zároveň zvyšuje šanci nalezení nových prodejců zboží, od kterých získává majitel aplikace peníze. Existuje zde také potenciál pro zavedení reklamních kampaní, z čehož mohou plynout další finance. V tomto přístupu však existuje riziko, že se sníží počet uživatelů z důvodu neoblíbenosti všudypřítomných reklam. Bezesporu nejdůležitější výhodou systémů pro běžné obchodování je jejich přímočarost, díky které uživatel nemusí přemýšlet o tom, který způsob 7

2

2. Obchodní analýza systémů pro moderní obchodování prodeje zboží vybere nebo jakým způsobem ho nakoupí, což mu umožňuje rychlé vložení jeho nabídky. Další výhodou, ale zároveň i nevýhodou, je jejich úzké zaměření. Uživatelé, kteří preferují jiné způsoby prodeje zboží, nemusí být ochotní úzce zaměřené systémy využít. To ale nevadí, pokud je skupina lidí, na kterou se systémy zaměřují, dostatečně početná na to, aby uspokojila finanční požadavky majitele. V takovém případě není potřeba hledat způsoby pro oslovení uživatelů z jiných skupin a je jednodušší odhadnout nové vlastnosti systému nebo reklamní nabídky, o které budou mít uživatelé zájem.

2.2

Analýza obchodních cílů

Jedním z obchodních cílů, kterého lze dosáhnout využitím tohoto typu systémů, je generování příjmů bez nutnosti složité správy systému. Na druhou stranu tyto systémy nejsou příliš vhodné pro propagaci majitele, jelikož existuje riziko ztráty velkého množství uživatelů citlivých na reklamní sdělení. Uživatel by neměl mít pocit, že je součástí systému, jehož využití ve výsledku povede k velkému množství reklamy a různých obchodních sdělení zasílaných prostřednictvím e-mailu. Generování příjmů Generování příjmů je zajištěno poplatkem za vložení nabídky, který se skládá z poplatku za vložení do vybrané kategorie a z případného poplatku za využití rozšiřujících služeb, jako je zvýraznění inzerátu, přednostní zobrazení či zobrazení mezi doporučenými nabídkami.

2.3

Podmínky pro dosažení obchodních cílů

Pro generování příjmů, které minimálně pokryjí výdaje, je nutný buď malý počet vložených nabídek zboží s vysokými poplatky, nebo velký počet vložených nabídek zboží s nízkými poplatky. Pro zajištění dlouhodobého generování příjmů je výhodné vzhledem k možné budoucí konkurenci na trhu zvolit strategii s nízkými poplatky a velkým počtem vložených nabídek zboží. Této strategie lze opět dosáhnout dvěma způsoby, a to buď získáním velkého počtu prodejců, kdy každý vloží malé množství nabídek zboží, nebo menšího počtu prodejců, kdy každý bude pravidelně vkládat větší množství nabídek zboží. Z dlouhodobého hlediska je výhodnější získat věrné prodejce, kteří pravidelně budou vkládat nové nabídky zboží, jelikož celkový počet prodejců na trhu není neomezený a nacházet nové bude časem stále složitější. Pro oslovení většího množství potenciálních prodejců bude nutné provést masivní marketingovou propagaci tohoto systému se zaměřením na jeho 8

2.3. Podmínky pro dosažení obchodních cílů centralizovanost a transparentní nízké poplatky, jelikož je důležité přesvědčit nejen uživatele, kteří doposud žádný systém nevyužívají, ale i uživatele konkurenčních systémů, kteří budou velice pravděpodobně neradi měnit své zvyklosti, a bude jim tedy nutné nabídnout výhody, které jim jejich systém dosud nenabízí a díky kterým se jim přechod na nový systém vyplatí. Po oslovení dostatečného množství potenciálních prodejců prostřednictvím marketingové propagace je nutné přesvědčit prodejce, aby u tohoto systému zůstali dlouhodobě, čehož se nejlépe dosáhne prostřednictvím úspěšného prodeje jejich zboží. Je tedy nutné oslovit také potenciální kupce, kterým je potřeba zobrazit nabídky přehlednou formou s jednoduchým procesem nákupu vybraného zboží. V ideálním případě tedy bude systém denně navštěvovat velké množství uživatelů, kteří budou souběžně provádět velké množství úkonů, a bude tedy zapotřebí obstarat výkonné servery schopné jejich požadavky obsloužit velmi rychle a stabilně, jelikož by libovolný výpadek služeb znamenal ztrátu důvěry uživatelů a následně konec jejich využívání systému.

9

Kapitola

Obchodní analýza zákazníka Účelem této kapitoly je provést na základě informací o obchodní činnosti zákazníka SWOT analýzu a identifikovat na jejím základě obchodní cíle, které je potřeba naplnit.

3.1

Současná obchodní činnost

Z osobní komunikace se zákazníkem jsem zjistil, že se specializuje na prodej historických zbraní a jiných válečných artefaktů. Prodej formou inzerce probíhá skrze cizí webovou aplikaci, ve které je účtován poplatek za vložení zboží k prodeji, a formou aukce skrze jinou cizí webovou aplikaci, ve které je účtován jak poplatek za vložení zboží k prodeji, tak poplatek za prodej.

3.2

Očekávaná budoucí obchodní činnost

Z osobní komunikace se zákazníkem jsem zjistil, že by rád vlastnil webovou aplikaci, která bude spojovat různé metody prodeje, díky čemuž ušetří za poplatky, které vynakládá na prodej zboží. Zároveň je to dle slov zákazníka výhodná investice, která mu nejen bude šetřit náklady, ale také po určité době generovat zisk z poplatků za prodej ostatních prodejců. Od webové aplikace si také slibuje, že bude mít přehled o zboží a prodeji konkurence.

3.3

SWOT analýza

V rámci analýzy zákazníka, kterou jsem založil na informacích získaných při osobní komunikaci, jsem dospěl k závěrům, které jsem uvedl na obrázku 3.1 a ze kterých je patrné, že zákazník má poměrně široké množství silných stránek a příležitostí, na základě kterých jsem následně v kapitole 4 posoudil soulad mezi obchodními cíli, pro jejichž dosažení má zákazník potenciál, a obchodními cíli, jejichž naplnění umožňuje systém pro moderní obchodování. 11

3

3. Obchodní analýza zákazníka V této analýze jsem vycházel z obecného předpokladu, že využitím silných stránek lze dosáhnout většího úspěchu než odstraňováním slabých stránek, a tedy jsem hledal takové obchodní cíle (příležitosti), pro jejichž naplnění disponuje zákazník odpovídajícími silnými stránkami. Identifikované hrozby jsem se rozhodl brát v potaz jako rizika a usilovat o jejich mitigaci (zmírnění).

Obrázek 3.1: SWOT analýza

3.4

Analýza obchodních cílů

Oslovení většího počtu zákazníků Tento obchodní cíl je podpořen všemi silnými stránkami, které zákazník má, a je tedy dobrým kandidátem pro naplnění. Zvýšení příjmů z prodeje zboží Tento obchodní cíl je také podpořen všemi silnými stránkami, které zákazník má, a proto je také dobrým kandidátem pro naplnění. Zlepšení povědomí o konkurenci Pro tento obchodní cíl zákazník potřebuje, aby prodej probíhal centralizovaně. V opačném případě musí sledovat veškeré prodejní způsoby konkurence. V současné chvíli není tento cíl k naplnění ideální.

12

Kapitola

Vyhodnocení smysluplnosti pořízení systému zákazníkem Účelem této kapitoly je porovnat obchodní cíle systému a zákazníka definované v kapitolách 2 a 3 a zodpovědět otázku, zda se zákazníkovi vyplatí investovat finanční prostředky do pořízení tohoto systému a využívat ho pro svou obchodní činnost. Systém zákazníkovi nabízí naplnění jeho vize o centralizovaném elektronickém prodeji zboží pomocí různých prodejních metod s transparentními nízkými poplatky. Pro ziskovost investice je však kritické vzhledem k nízkým poplatkům získat takové množství prodejců, kteří vložením svých nabídek vygenerují příjem vyšší, než je nutný pro pokrytí nákladů a počáteční investice.1 Zákazník na počáteční investici nesmí šetřit vzhledem k nutnosti naplnění potřeby stabilního provozu, kterého docílí pořízením výkonného serveru, a potřeby získání velkého množství prodejců a kupců, čehož docílí jejich oslovením prostřednictvím masivní marketingové kampaně. Dlouhodobě také musí počítat s náklady na údržbu a správu výpočetních zdrojů a také údržbu a případný rozvoj samotného systému.1 Systém je tedy pro zákazníka vhodný vzhledem k jeho obchodním cílům, ale je nutné počítat s velkým rizikem finanční ztráty v případě nenaplnění podmínek pro generování příjmů, které by alespoň pokryly počáteční investici a provozní náklady.

1 Konkrétní marketingová a finanční čísla nejsou předmětem této studie. Cílem je pouze upozornit zákazníka na rizika.

13

4

Kapitola

Obchodní nabídka pro zákazníka Účelem této kapitoly je sestavit obchodní nabídku na implementaci tohoto systému, kterou obchodník osobně představí zákazníkovi se zdůrazněním potřeby součinnosti ze strany jeho spolupracovníků.

5.1

Způsob prodeje

Systém pro moderní obchodování lze prodat pouze jedinému zákazníkovi nejlépe na smlouvu o dílo, jelikož by jinak ztratil svou výhodu unikátnosti na trhu a počáteční investice zákazníka by se vzhledem k nové konkurenci a velikosti trhu stala prakticky nenávratnou.

5.2

Roadmapa implementace

Etapy SW vývoje Návrh Cílem je vytvoření předpisu pro implementaci, testování a nasazení systému. Implementace Cílem je vytvoření systému, který naplní funkční požadavky. Testování Cílem je ověření správné implementace funkčních požadavků. Nasazení Cílem je nasazení otestovaného systému na server. Jednotlivé etapy včetně termínů a odhadu doby trvání zobrazuji formou Ganttova diagramu na následujícím obrázku 5.1. 15

5

5. Obchodní nabídka pro zákazníka

MTS Gantt Chart

May 7, 2014 3 2014

2015 SW Development

Name

May

Begin date

End date

02/06/2014

02/12/2014

SW Design

02/06/2014

13/06/2014

10

SW Implementation

16/06/2014

07/11/2014

105

SW Testing

10/11/2014

28/11/2014

15

SW Deployment

01/12/2014

02/12/2014

2

SW Development

Duration

June

July

August

September October

November December

January

132

Obrázek 5.1: Ganttův diagram

5.3

Kalkulace

Kalkulace představuje cenu za dodání hotového systému včetně nasazení na server zákazníka. Profesní zařazení

Cena/den2 [Kč]

Počet lidí2

Počet dní2

Celkem [Kč]

Senior vývojář

9 600

1

50

480 000

Junior vývojář

5 600

2

105

1 176 000

UI designer

5 600

1

10

56 000

CSS kóder

4 000

1

15

60 000

Tester

4 000

1

15

60 000

Správce systému

4 000

1

2

8 000

Tabulka 5.1: Kalkulace ceny za vývoj systému Z tabulky 5.1 je patrné, že v celkovém součtu je vývoj projektu kalkulován na 1 840 000 Kč s dobou vývoje 132 pracovních dnů, počátkem projektu 2. 6. 2014 a koncem projektu 2. 12. 2015. Tuto analýzu v ceně 120 000 Kč, což je cena za práci analytika, SW architekta a projektového manažera, dostane zákazník v případě zájmu o dodání tohoto systému zdarma. Konec projektu je naplánován tak, aby potenciální prodejci stihli své zboží nabídnout ještě před Vánoci, kdy je obecně očekáván největší zájem ze strany kupců. Součástí této kalkulace není údržba systému nad rámec opravy závažných chyb bránících v běžném užívání aplikace, kterou lze sjednat mimo rámec této analýzy. 2 Hodnoty vycházejí z mého vlastního odhadu, který jsem učinil na základě svých zkušeností s malými společnostmi.

16

5.4. Součinnost zákazníka

5.4

Součinnost zákazníka

Zákazníka je nutné seznámit s časovým, profesním a kapacitním rozsahem součinnosti, kterou je nutné, aby pro úspěch projektu poskytl. Velká část potřebné součinnosti zákazníka proběhla již v rámci zpracovávání této studie. V dalších fázích implementace, testování a údržby už bude potřeba minimální součinnost zákazníka a bude uplatňována v rámci konzultací na pravidelných setkáních s prezentacemi postupu prací o délce zhruba 2 hodiny vždy jednou za 3 týdny. Zákazník si sám musí provést kalkulaci ušlé příležitosti a nákladů na své vlastní pracovníky během poskytování součinnosti.

5.5

Pravidla pro akceptaci systému

Na akceptaci systému má zákazník 2 týdny, během kterých je nutné, aby ověřil správnou implementaci systému dle parametrů uvedených v analýze požadavků zákazníka na systém a nahlásil dodavateli veškeré nalezené nedostatky, jejichž nápravu zajistí dodavatel neprodleně po nahlášení s délkou zpracování určenou na základě povahy nalezeného nedostatku. V případě, že bude akceptace trvat déle než 2 týdny, bude za každý další pracovní den účtována plná cena za práci vývojářů vyhrazených na tento projekt ve výši 16 000 Kč.

17

Kapitola

6

Analýza požadavků zákazníka na systém Účelem této kapitoly je získat veškeré informace o aplikaci z pohledu zákazníkem požadovaných funkcionalit, nefunkčních parametrů a cílů, kterých uživatel aplikace bude jejím prostřednictvím dosahovat.

6.1

Problém –– co komu vadí?

Na trhu existují v současnosti tři nejrozšířenější typy zprostředkování prodeje zboží. Konkrétně se jedná o zprostředkování prodeje formou aukcí, inzerce a slev. Neexistuje však doposud žádná aplikace, která by tyto tři způsoby prodeje spojovala, a umožnila tak uživateli centralizovaný prodej zboží.

6.2

Účel –– k čemu systém slouží a jaký užitek komu přinese?

Účelem je vytvořit aplikaci, která spojí všechny tři výše uvedené způsoby zprostředkování prodeje a umožní uživateli centralizovaný prodej zboží.

6.3

Popis problémové domény – co systém dělá a s kým při tom interaguje?

Systém pro moderní obchodování, což je název pro aplikaci zmiňovanou v předchozím odstavci, musí uživatelům umožnit registraci a rozlišovat, zda se jedná o registraci pro soukromé účely, nebo pro podnikatelské účely. Po registraci se uživateli vytvoří profil a účet dle údajů z registrace. Soukromá osoba po registraci může prodávat prostřednictvím inzerce nebo aukce. Prodej prostřednictvím slev není soukromým osobám umožněn. Pod19

6. Analýza požadavků zákazníka na systém nikatelé mohou prodávat ve všech kategoriích. Prodej je zpoplatněn jednorázovým poplatkem při vložení nabídky a skládá se z poplatku za kategorii, do které je nabídka vložena, a z poplatku za volitelné služby, které zvýhodní nabídku před ostatními. Jedná se o zvýraznění, přednostní zobrazení a zobrazení v doporučených nabídkách. Nákup zboží v inzerci a ve slevě probíhá pro nepřihlášeného kupce tak, že vyplní formulář u zboží svého zájmu, systém zašle na jeho e-mail odkaz, kterým je nutné objednávku potvrdit, a teprve po potvrzení je prodejci zaslán e-mail s poptávkou. Po uskutečnění prodeje prodejce v aplikaci ukončí nabídku, případně sníží kapacitu dostupného zboží. Přihlášení kupci nemusí objednávku potvrzovat. Nákup zboží v aukci probíhá dvěma způsoby, a to buď okamžitou koupí, nebo aukcí. Okamžitá koupě probíhá stejně jako nákup zboží v inzerci nebo ve slevě. Aukce je umožněna pouze přihlášeným uživatelům a probíhá formou příhozů. Na konci aukce je zaslán prodejci e-mail s informacemi o kupci. V případě, že registrovaný kupec odmítne prodejci zaplatit za zboží nebo nekomunikuje, může prodejce zažádat správce o zablokování účtu kupce a správce žádost posoudí, a pokud je oprávněná, zablokuje účet kupce. Aplikace musí uživateli umožnit zobrazení, případně změnu údajů o jeho profilu. Stejně tak musí umožnit zobrazení informací o vlastním účtu, který musí být možné dobít prostřednictvím SMS platby s možností budoucího rozšíření o další druhy plateb. Uživateli musí být umožněno zobrazení ostatními uživateli nabízených slev, aukcí a inzercí včetně zobrazení detailu. Také musí mít možnost spravovat své vlastní nabídky, což zahrnuje jejich vytvoření, zobrazení, úpravu, ukončení a smazání. Každý uživatel může prostřednictvím formuláře odeslat dotaz prodejci vybrané inzerce, aukce nebo slevy, případně vybranou slevu nahlásit správci, pokud si myslí, že nabídka porušuje pravidla pro obchodování v rámci této aplikace. Aplikace musí být spravovatelná správcem prostřednictvím administrace. Správci musí být umožněno zobrazit seznam všech registrovaných uživatelů, detail vybraného uživatele a také zablokování nebo odblokování vybraného uživatele. Dále musí být správci umožněno přidat, upravit, zobrazit, zablokovat nebo odblokovat libovolnou kategorii a zobrazit transakce (SMS platby) uživatelů.

20

6.4. Ontologická analýza problémové domény

6.4

Ontologická analýza problémové domény

Pomocí notace OntoUML je na obrázku 6.1 zobrazena struktura problémové domény formou konceptuálního modelu, který pomůže analytikům a vývojářům pochopit problémovou doménu a navrhnout podle ní aplikaci. «kind» Image type: String[1] name: String[1] description: String[0..1] hash: String[1]

1..* «mediation»

1 «relator» ImageAssignment

«category» ContactableSubject email: String[1] phone: String[0..1]

«relator» CategoryParentAssignment «mediation» 0..1

«mediation» 0..1

0..1 «mediation»

isParentOf «material»

{disjoint} «subkind» Person

«phase» Registered «kind» Visitor name: String[1]

«subkind» Company ICO: String[1] DIC: String[0..1]

{disjoint, complete} {disjoint, complete}

«phase» Unregistered {disjoint, complete}

1 «kind» Product name: String[1] description: String[1] capacity: Integer[1] unitsSold: Integer[1] unitsAvailable: Integer[1] pricePerUnit: Currency[0..1] discountedPricePerUnit: Currency[0..1] discountPercentPerUnit: Percent[0..1]

«kind» Feature name: String[1] description: String[1] fee: Currency[0..1] 1..* «mediation»

0..* «relator» FeatureAssignment

«role» User username: String[1] password: String[1]

1 {essential, inseparable}

1

0..1 «mediation»

1 0..1 «kind» Category name: String[1] description: String[1] fee: Currency[0..1]

0..*

1..*

1..* «mediation»

0..* «relator» CategoryAssignment

1 «mediation»

«mediation» 1 1 «relator» Registration

«phase» Active

{disjoint, complete}

«phase» Closed

1 «kind» Account number: String[1] balance: Currency[1] creationDate: Date[1]

«phase» Active

1

«phase» Closed

name: String[1] description: String[1] paymentMethod: String[0..1] expirationDate: Date[1] visitsNo: Integer[1]

1 «mediation» «phase» Blocked

1 «kind» TradeOffer

«mediation» 1

0..*

«relator» OfferCreation date: Date[1]


«phase» Blocked

«phase» Deleted «mediation» 1

1 «phase» Expired

1 «mediation»

0..* «relator» Recharge


«subkind» Ad transactionType: String[0..1]

«subkind» Discount

«subkind» Auction buyImmediatelyPricePerUnit: Currency[0..1]

1 «mediation»

1

1 «mediation»

«kind» Payment

{disjoint}

«subkind» SMSPayment

0..* «relator» Bidding authorEmail: String[1] date: Date[1] 1 «mediation»

1 «mediation»

1 «relator» CodeVerification «kind» SMS code: String[1] price: Currency[1] currency: String[1] keyword: String[1] identifier: String[1] sender: String[1] recipient: String[1] receptionDate: Date[1]

1 «kind» Bid price: Currency[1]

1 «mediation»


1 «role» Charged

Obrázek 6.1: Konceptuální diagram

21

6. Analýza požadavků zákazníka na systém

6.5

Role uživatelů

Uživatel Tato role představuje libovolného uživatele aplikace. Nepřihlášený uživatel Tato role představuje uživatele, který se neautentizoval prostřednictvím přihlašovacího formuláře aplikace. Přihlášený uživatel Tato role představuje registrovaného uživatele, který se autentizoval prostřednictvím přihlašovacího formuláře aplikace. Správce Tato role představuje registrovaného a přihlášeného uživatele aplikace, který má kompletní práva pro správu aplikace.

Agilian Standard Edition(Czech technical university of Prague)

User

Member

Guest

Admin

Obrázek 6.2: UC diagram – role uživatelů

22

6.6. Funkční požadavky

6.6

Funkční požadavky

Na obrázku 6.3 jsou zobrazeny hlavní uživatelské případy využití tohoto systému, což po přečtení dokumentace umožní vývojářům rychlou orientaci v požadavcích. Agilian Standard Edition(Czech technical university of Prague)

Administration Account Management

Category Management

Admin Payment Management

Business Account Management Create Account Trade Management

Member

Payment Management

Guest

Purchase Item

Bid at Auction

User

Obrázek 6.3: UC diagram – přehled

23


6.6.1

Uživatel

Nákup zboží Libovolný uživatel systému si může koupit zboží pouze z detailu nabídky, na který se dostane buď z výsledků vyhledávání internetového vyhledávače kliknutím na odkaz nalezeného záznamu, nebo z přehledu nabídek systému kliknutím na tlačítko „Bližší informace“. Po kliknutí na tlačítko „Koupit zboží“, na detailu nabídky, se zobrazí formulář objednávky obsahující jméno a příjmení kupce, jeho e-mailovou adresu, volitelnou poznámku a tlačítko „Závazně objednat“. Po kliknutí na tlačítko „Závazně objednat“, na formuláři objednávky, se provede ověření správnosti vyplněných údajů. V případě nalezení nedostatku se o něm kupci zobrazí informace a zůstanou předvyplněna data, která zadal. V opačném případě se chování liší dle role kupce. Přihlášenému kupci se zobrazí informace o úspěšném odeslání objednávky a jeho objednávka se odesílá e-mailem prodejci. Nepřihlášenému kupci se zobrazí formulář potvrzení e-mailu s informací, že mu byl na uvedenou e-mailovou adresu zaslán e-mail s kódem, který musí vyplnit kvůli potvrzení platnosti jeho e-mailové adresy. Po zadání správného potvrzovacího kódu a kliknutí na tlačítko „Ověřit e-mail“, na formuláři potvrzení e-mailu, se prodejci odešle e-mailem objednávka. Objednávka zasílaná prodejci obsahuje název zboží a informace uvedené ve formuláři objednávky.


MTS

Purchase Item

User

Obrázek 6.4: UC diagram – uživatel

24

6.6. Funkční požadavky

6.6.2

Nepřihlášený uživatel

Vytvoření účtu Nepřihlášený uživatel aplikace si může z libovolné stránky systému vytvořit účet. Po kliknutí na tlačítko „Vytvořit účet“, v horním menu, se uživateli zobrazí registrační formulář obsahující jméno a příjmení, email, uživatelské jméno, heslo a heslo pro ověření. Po kliknutí na tlačítko „Uložit“, v registračním formuláři, se provede ověření správnosti vyplněných údajů a v případě nalezení nedostatku se o něm uživateli zobrazí informace a zůstanou předvyplněna data, která zadal. V opačném případě se uživateli zobrazí informace o úspěšném vytvoření účtu a nutnosti jeho aktivace, vytvoří se mu zablokovaný účet a přijde mu e-mail s aktivačním odkazem. Po kliknutí na tento odkaz se uživateli aktivuje účet a bude se moci přihlásit.


MTS

Create Account

Guest

Obrázek 6.5: UC diagram – nepřihlášený uživatel

25


6.6.3

Přihlášený uživatel

Správa účtu Přihlášený uživatel může spravovat svůj účet, což zahrnuje zobrazení stavu účtu včetně možnosti jeho dobití a zobrazení uživatelských údajů včetně možnosti jejich úpravy. Stav účtu a osobní údaje uživatele se zobrazí po kliknutí na tlačítko „Můj účet“, které se nachází v uživatelském menu. Osobní údaje lze změnit po kliknutí na tlačítko „Změnit osobní údaje“, které se nachází u osobních údajů, a vyplnění zobrazeného formuláře, který obsahuje předvyplněné osobní údaje uživatele z registrace. Vedle stavu účtu se zobrazí také tlačítko „Dobít účet“. Po kliknutí na něj se zobrazí dobíjecí formulář s výběrem SMS služby a polem pro zadání kódu, který uživatel obdržel na telefon po zaslání SMS v předepsaném tvaru na předepsané telefonní číslo dle výběru SMS služby. Po kliknutí na tlačítko „Dobít“, v dobíjecím formuláři, se provede ověření správnosti zadaného kódu. V případě neúspěchu se uživateli zobrazí informace o důvodech. V případě úspěchu je navýšen stav účtu uživatele. SMS brána a finance ze zasílání SMS plynoucí jsou řešeny externím komerčním systémem, jehož nastavení má na starosti zákazník. Správa obchodních nabídek Přihlášený uživatel může spravovat své obchodní nabídky, což zahrnuje zadání nové nabídky a zobrazení seznamu všech vlastních nabídek. Zadání nové nabídky je možné provést kliknutím na tlačítko „Vytvořit nabídku“, které se nachází v uživatelském menu, a následným vyplněním formuláře, který obsahuje položky název, popis, cenu, metody propagace a délku zveřejnění. Po stisknutí tlačítka „Uložit nabídku“ se provede ověření správnosti údajů. V případě neúspěchu se uživateli zobrazí informace o důvodech. V případě úspěchu dojde k uložení nabídky do databáze a zobrazení zprávy o úspěchu uživateli. Seznam vlastních nabídek obsahuje všechny nabídky zadané zákazníkem, které se zobrazí po kliknutí na tlačítko „Moje obchodní nabídky“, které se nachází v uživatelském menu. U každé nabídky se zobrazí její název, datum expirace, cena a tlačítka „Bližší informace“, „Upravit“, „Uzavřít“, „Smazat“. Po stisknutí tlačítka „Bližší informace“, u záznamu obchodní nabídky, dojde k zobrazení všech informací obchodní nabídky. Po stisknutí tlačítka „Upravit“ se zobrazí formulář úprav s předvyplněnými údaji nabídky, které může uživatel změnit a po kliknutí na tlačítko „Uložit nabídku“, ve formuláři úprav, i změnit. Po kliknutí na tlačítko „Uzavřít“ se provede změna stavu nabídky na uzavřenou. Po kliknutí na tlačítko „Smazat“ se provede změna stavu nabídky na smazanou. Správa plateb Přihlášený uživatel může spravovat své platby, což zahrnuje zobrazení všech provedených plateb. Seznam plateb se zobrazí po kliknutí na tla26

6.6. Funkční požadavky čítko „Seznam plateb“, které se nachází v uživatelském menu. Každá platba obsahuje informace o výši platby a datu provedení. Přihození v aukci Přihlášený uživatel může přihodit do aukce částku nejméně o 5 Kč vyšší, než je aktuální nejvyšší částka. Přihození se provede kliknutím na tlačítko „Přihodit do aukce“, které se nachází na detailu zboží, a vyplněním požadované částky.


MTS

Account Management

Trade Management

Member Payment Management

Bid at Auction

Obrázek 6.6: UC diagram – přihlášený uživatel

27


6.6.4

Správce

Správa účtů Správce může spravovat účty všech uživatelů, což zahrnuje zobrazení osobních údajů a stavu účtu, zobrazení plateb a zablokování, úpravu a smazání účtu. Vyjmenované akce provádí správce ze seznamu všech účtů, který se mu zobrazí po kliknutí na tlačítko „Zobrazit účty“, které se nachází v administračním menu. Každý záznam v seznamu účtů obsahuje stav účtu, datum založení, jméno a příjmení vlastníka a tlačítka „Bližší informace“, „Seznam plateb“, „Zablokovat“, „Smazat“. Po kliknutí na tlačítko „Bližší informace“ se správci zobrazí stav účtu a osobní údaje uživatele včetně tlačítka „Upravit osobní údaje“. Po kliknutí na tlačítko „Upravit osobní údaje“, které se nachází vedle osobních údajů uživatele, se zobrazí formulář úprav s předvyplněnými údaji uživatele, které správce může upravit a kliknutím na tlačítko „Uložit osobní údaje“, které se nachází ve formuláři úprav, změnit. Po kliknutí na tlačítko „Seznam plateb“, které se nachází u položky seznamu, se zobrazí seznam všech plateb provedených vlastníkem daného účtu. Každý záznam obsahuje datum provedení platby a její výši. Po kliknutí na tlačítko „Zablokovat“, které se nachází u položky seznamu, se provede změna stavu účtu na blokovaný. Po stisknutí tlačítka „Smazat“, které se nachází u položky seznamu, se provede změna stavu účtu na smazaný. Správa kategorií Správce může spravovat kategorie, což zahrnuje přidání nové kategorie dle způsobu prodeje zboží, úpravu kategorie a její zneaktivnění či zaktivnění. Po kliknutí na tlačítko „Vytvořit kategorii“, které se nachází v administračním menu, dojde k zobrazení formuláře s poli název, popis, poplatek a způsob prodeje. Po kliknutí na tlačítko „Uložit kategorii“, které se nachází ve zmíněném formuláři, dojde k ověření správnosti dat a v případě úspěchu i k jejich uložení a zobrazení informace o úspěchu uživateli. Po kliknutí na tlačítko „Zobrazit kategorie“, které se nachází v administračním menu, se zobrazí seznam všech kategorií. Každý záznam obsahuje název kategorie, výši poplatku a tlačítka „Bližší informace“, „Upravit kategorii“, „Zneaktivnit kategorii“, „Zaktivnit kategorii“. Po stisknutí tlačítka „Bližší informace“, které se nachází u položky seznamu, dojde k zobrazení všech informací kategorie. Po stisknutí tlačítka „Upravit kategorii“, které se nachází u položky seznamu, se zobrazí formulář s předvyplněnými údaji kategorie, které může správce změnit a po kliknutí na tlačítko „Uložit kategorii“, ve formuláři, i změnit. Po stisknutí tlačítka „Zneaktivnit kategorii“, které se nachází u položky seznamu, dojde k zneaktivnění kategorie a zobrazení informace o úspěchu provedené akce uživateli. Tlačítko „Zaktivnit kategorii“, zmíněné výše, má přesně opačnou funkci, než tlačítko „Zneaktivnit kategorii“. 28

6.6. Funkční požadavky Správa plateb Správce aplikace může spravovat platby všech uživatelů, což zahrnuje zobrazení seznamu všech plateb. Seznam se zobrazí po kliknutí na tlačítko „Zobrazit platby“, které se nachází v administračním menu. Každý záznam obsahuje výši platby, datum provedení a jméno a příjmení vlastníka účtu.


MTS

Account Management

Category Management

Admin Payment Management

Obrázek 6.7: UC diagram – správce

29


6.7

Nefunkční požadavky

Dostupnost • Aplikace musí být dostupná prostřednictvím webových prohlížečů (Safari 5+, Opera 20+, Mozzila Firefox 28+, Chrome 34+, IE 9+) a nativních mobilních webových prohlížečů pro nejnovější verze operačních systémů Android, Windows Phone a iOS nezávisle na rozlišení obrazovky až do verzí existujících v době nasazení aplikace na server alespoň 6 měsíců na trhu. • Bude vytvořena pouze jedna verze webového portálu pro všechna zařízení. • Načtení webové stránky nesmí při měření na serveru trvat déle než 4 sekundy a přesáhnout 500 KB přenesených dat. • Musí být umožněn současný přístup k aplikaci v řádu tisíců uživatelů. Rozšiřitelnost a modifikovatelnost • V případě potřeby musí být možné změnit webový či databázový server bez zásahů do kódu aplikace. Bezpečnost • Zabezpečená komunikace prostřednictvím protokolu HTTPS při provádění operací s citlivými daty (registrace, přihlášení, správa účtu a profilu, obchodování). • Heslo uživatele nesmí být přenášeno ani ukládáno v čitelné či v reálném čase (v řádu desetiletí) odhalitelné formě. • Všechny formuláře musí být chráněny proti automatizovanému rozesílání spamu.

30

Kapitola

SW architektura systému Účelem této kapitoly je navrhnout stabilní základ pro naplnění funkčních a nefunkčních požadavků kladených na tuto aplikaci. Na SW architekturu lze nahlížet odlišnými způsoby. Ve svém přístupu k architektuře následuji v této práci myšlenky takzvané 4+1 architektury [4].

7.1

Konceptuální (logický) pohled

Konceptuální pohled na architekturu zobrazuje na implementačních rozhodnutích nezávislou množinu abstrakcí objektů z problémové domény potřebnou k vyjádření funkčních požadavků na systém [5]. Agilian Standard Edition(Czech technical university of Prague)

Person

Company

Image

User

owner

images

1

1

TradeOffer

Account

1

0..*

1 1

product

tradeOffers

Product

1

0..* 0..*

1

features

Feature

0..* 0..*

payments

0..*

categories

Payment

Category

1..*

0..*

0..1

Sms

sms

0..1

SmsPayment

Ad

Discount

Auction

1

1

bids 0..*

Obrázek 7.1: Logický diagram 31

parent

Bid

7

7. SW architektura systému

7.2

Modulární (vývojový) pohled

Modulární pohled na architekturu informuje o rozčlenění systému na nezávislé podsystémy, které mohou být vyvíjeny samostatně malým počtem programátorů a které jsou organizovány v hierarchické struktuře vrstev, z nichž každá poskytuje své rozhraní vyšší vrstvě [5]. Díky rozdělení podsystému do nezávislých vrstev – komunikujících skrze rozhraní pouze se sousedními vrstvami – lze kteroukoli vrstvu kdykoli vyměnit za jinou bez nutnosti zásahu do kódu samotné aplikace. Moduly, případně podsystémy mohou být seskupeny do podsystémů na základě mnoha různých kritérií [5]. Nejprve jsem tedy celý systém logicky uspořádal do jednotlivých podsystémů a poté jsem seskupil moduly na základě jejich účelu, což znamená, že jsem je rozdělil do 3 podsystémů – prezentačního, logického a datového, které hierarchicky tvoří stejnojmenné vrstvy shora v pořadí, v jakém jsem je zapsal, viz 7.2. Tyto 3 podsystémy dohromady tvoří jeden podsystém vrstvené architektury, který je základním kamenem tohoto systému. V prezentační a logické vrstvě podsystému vrstvené architektury jsem využil návrhový vzor MVP [6]. Technologie pro vývoj PHP 5.4, Nette Framework 2.1, ORM Doctrine 2, HTML 5, CSS 3, jQuery 2.1, správce PHP závislostí composer, verzovací systém GIT Agilian Standard Edition(Czech technical university of Prague)

<> Layered Architecture <> Presentation Layer


<> MTS <> Administration

<> Business

<> Layered Architecture


<<use>>

<> View (Template)

<> Presenter

<<use>>

<> Ad

<> Business Layer


<> Model

<> Auction <> Layered Architecture

<> Data Layer

<> Discount <> Layered Architecture

<> Entity

Obrázek 7.2: Diagram komponent

32

<<use>>

<> DAO

7.3. Procesní (koordinační) pohled

7.3

Procesní (koordinační) pohled

Procesní pohled na architekturu poskytuje informace o systémových procesech, jejich vzájemné komunikaci a synchronizaci během zpracování aplikačních úloh [5]. Webová aplikace je nasazena na serveru apache s nastaveným MPM prefork, což znamená, že se pro zpracování každého HTTP požadavku využívá samostatný apache proces s vlastním paměťovým prostorem. Pokud jsou všechny apache procesy využity, vytvoří se nový. Toto řešení je sice pomalé a paměťově náročné, jelikož vytvoření nového procesu zahrnuje kopii původního procesu a jeho dat, ale je také velmi robustní, jelikož chyba v jednom procesu neovlivní ostatní procesy a ani si procesy navzájem nemohou přepsat paměť [7]. Apache má k dispozici také MPM worker, který pro zpracování každého HTTP požadavku využívá samostatné vlákno apache procesu. Pokud jsou všechna vlákna využita, vytvoří se nové. Toto řešení je paměťově méně náročné, jelikož vlákna využívají sdílenou paměť, a rychlejší, jelikož při vytvoření vlákna není nutná kopie původního vlákna a dat, ale pokud některý modul není thread-safe, jsou také nepředvídatelné a nestabilní. Chyba v jednom vlákně může způsobit ukončení všech ostatních vláken i samotného procesu a kvůli sdílené paměti existuje riziko, že si vlákna chybně navzájem přepíší paměť. Tento MPM pro svou stabilitu a předvídatelnost tedy vyžaduje, aby všechny apache moduly byly thread-safe, což u apache modulu mod_php není zaručeno, protože využívá knihovny třetích stran, které nejsou vždy thread-safe [7]. Zvolením MPM prefork je tedy upřednostněna stabilita před nižší paměťovou náročností a vyšší rychlostí a zároveň je vyřešena synchronizace přístupů do paměti, jelikož má každý proces vlastní část paměti a žádný proces nebude pro účely jiné než řídící vytvářet a využívat sdílenou paměť. Správa procesů je plně v kompetenci webového serveru apache. Jediné, co je třeba v tomto případě vyřešit, je synchronizace přístupů ke sdíleným datům uloženým v databázi. Problémové situace mohou nastat v případech, kdy dva správci aplikace budou ve stejný moment upravovat stejná data, případně když uživatel bude upravovat svá data ve stejný moment z různých webových prohlížečů. Vždy se tedy data přepíší posledním požadavkem. Vzhledem k nízké pravděpodobnosti těchto jevů tyto problémové situace nebudou žádným způsobem řešeny a budou evidovány jako riziko.

33

7. SW architektura systému

7.4

Fyzický pohled

Fyzický pohled na architekturu poskytuje informace o požadovaných výpočetních zdrojích, protokolech, jakými spolu komunikují, a o rozmístění jednotlivých částí aplikace na výpočetních zdrojích [5]. Pro návrh jsem zvolil obecně využívaný architektonický vzor klient-server, který určuje role dvěma fyzickým zařízením, která spolu komunikují prostřednictvím určitého protokolu. Jak je z názvu patrné, jedná se o zařízení na straně klienta (počítač či telefon) a zařízení na straně serveru (serverový stroj). Schéma uvádím na obrázku 7.3. Na zařízení na straně klienta nejsou kladeny žádné výkonnostní požadavky. Musí být na něm však spuštěn webový prohlížeč, který pomocí protokolu HTTP či HTTPS komunikuje s webovým serverem umístěným na zařízení na straně serveru, které přijme požadavek, předá ho ke zpracování aplikaci a nakonec zašle odpověď klientovi. Na zařízení na straně serveru musí být nainstalován OS Unix a spuštěn jak webový server, tak databázový server, který slouží jako úložiště dat, jejichž struktura je předepsána datovým schématem. Pro tuto komerční aplikaci jsem jako webový server zvolil Apache 2.4, který licenčně neomezuje bezplatné využití v komerčních aplikacích, a jako databázový server jsem zvolil MySQL Community Server 5.6, který lze zdarma použít, jelikož je aplikace vyvíjena v jazyce PHP, a tedy využívá PHP licenci, která se nachází v seznamu FOSS licencí, díky čemuž se na ní vztahuje FOSS licenční výjimka [8]. Enterprise edice obsahuje navíc pouze uživatelskou podporu a nástroje. Aplikace komunikuje s databází prostřednictvím dotazů jazyka SQL, které jsou předávány jako parametry metodám rozhraní ODBC a následně pomocí aplikačního protokolu, vybraného ODBC ovladačem pro určenou databázi, v tomto případě MySQL Client/Server protocol, zasílány databázi ke zpracování. Díky ODBC rozhraní lze snadno vyměnit databázový server za jiný pouhou změnou identifikátoru datového zdroje (DSN) v konfiguraci aplikace. Pro přístup k aplikaci může uživatel využít libovolný prohlížeč, který umí pracovat s protokoly HTTP a HTTPS. Dle specifikace nefunkčních požadavků však bude aplikace plně podporovat pouze prohlížeče v ní uvedené.

34

7.4. Fyzický pohled


<<device>> PC/Phone <<executionEnvironment>> Web Browser

<<device>> Server HTTP(S)

<<executionEnvironment>> Apache 2.4 <> MTS

<> ODBC

MySQL Client/Server Protocol

<<executionEnvironment>> MySQL Community Server 5.6 <> DB Schema

Obrázek 7.3: Diagram nasazení

35

Kapitola

Zhodnocení případové studie Účelem této kapitoly je zhodnotit zpracovanou případovou studii z hlediska vlivu přípravy na sestavení splnitelné nabídky, návratnosti investovaného času, silných a slabých stránek, obecné využitelnosti myšlenek a přizpůsobení jinému zákazníkovi.

8.1

Vliv přípravy na sestavení splnitelné nabídky

Tuto práci jsem zahajoval s myšlenkou, že se malé firmy a osoby samostatně výdělečně činné nezabývají zpracováním analýz, kterými by mohli podložit své odhady při sestavování obchodní nabídky. V této práci jsem provedl dvě analýzy, které slouží jako základ pro odhad parametrů obchodní nabídky. Konkrétně se jedná o analýzu požadavků zákazníka na systém a návrh architektury. Sám jsem si nejprve vyzkoušel odhadnout termíny, cenu a požadovanou součinnost bez podkladů a následně jsem tak učinil i s podklady. Rozdíl byl obrovský a lišila se také míra osobního přesvědčení o tom, že je rozpočet nastaven správně. S podklady byly hodnoty jednoznačně lepší, z čehož vyplývá, že vliv přípravy na sestavení splnitelné nabídky je velký za předpokladu, že odhad včetně analýz provádí člověk s určitou mírou znalostí a zkušeností v oboru.

8.2

Návratnost investovaného času

Z hlediska investovaného času se tvorba případové studie jeví jako velmi nákladná a kvalifikaci vyžadující činnost, což může být při rozhodování silný argument proti její tvorbě. O návratnosti investice však nemám pochyb, jelikož v případě kvalitního zpracování povede k reálným odhadům času a financí, což mimo jiné minimalizuje riziko špatně nastaveného rozpočtu a termínů, a přispěje tak ke spokojenosti zákazníka. 37

8

8. Zhodnocení případové studie

8.3

Obecná využitelnost myšlenek

Základní myšlenky použité v této případové studii a jejich provázání lze využít i v jiných případových studiích zabývajících se tvorbou aplikací. Obecně je nutné pro získání dostatečného množství dat pro další rozhodování provést analýzu existujících řešení a jejich výhod a nevýhod, identifikovat obchodní cíle, jejichž naplnění aplikace nabízí, zjistit skutečné obchodní potřeby a cíle zákazníka, vyhodnotit smysluplnost pořízení aplikace, provést analýzu požadavků zákazníka na aplikaci a sestavit nabídku na pořízení aplikace obsahující cenu, termíny a požadovanou součinnost. Pro sestavení nabídky je vhodné taktéž navrhnout architekturu aplikace, ze které budou patrné požadavky na výpočetní zařízení a technologie, které se mohou v ceně taktéž promítnout.

8.4

Přizpůsobení jinému zákazníkovi

Může se stát, že vybraný zákazník odmítne pořízení aplikace. V takovém případě stačí pouze provést analýzu nového zákazníka a nové vyhodnocení smysluplnosti pořízení systému zákazníkem. Ostatní části mohou zůstat stejné, pokud zákazník systém odmítl z důvodů nesouvisejících s aplikací. Pokud zákazník odmítl systém například z důvodu vysoké ceny, je možné upravit patřičné parametry případové studie, případně zlepšit argumentaci.

8.5

Silné stránky

Zdroj informací pro kvalifikované závěry Na základě informací z analýz provedených kvalifikovaným zaměstnancem lze činit odhady, které nebudou daleko od skutečného stavu. Zdroj informací pro nové zaměstnance Každá studie je uložena v archivu společnosti, a tedy v případě nahrazení zaměstnance někým jiným lze snadno dohledat všechny informace na jediném místě. Opakovaná využitelnost postupů a myšlenek Časem a zkušenostmi ověřené postupy a myšlenky lze opakovaně využívat i v dalších projektech. Znak profesionality a důvěryhodnosti pro zákazníka Zákazník dostane precizně zpracovaný dokument s argumentací pro veškerá doporučení, což působí velmi profesionálně a důvěryhodně. 38

8.6. Slabé stránky

8.6

Slabé stránky

Časová náročnost a nákladnost zpracování Vzhledem k potřebě precizního zpracování a množství analýz je zpracování studie časově náročné a vzhledem k nutné kvalifikaci i velice nákladné. Nutná kvalifikace a preciznost tvůrce V případě chybného zpracování případové studie může dojít k chybným odhadům a závěrům, což může vést až ke ztrátě zákazníka.

39

Závěr V rámci této bakalářské práce jsem se zabýval zpracováním případové studie vytvoření systému pro moderní obchodování s cílem zhodnotit v ní, zda je pořízení systému pro moderní obchodování pro konkrétního zákazníka smysluplné, a v kladném případě mu sestavit obchodní nabídku na jeho implementaci. Na základě provedeného zhodnocení jsem zjistil, že se vybranému zákazníkovi pořízení tohoto systému vyplatí z hlediska naplnění jeho obchodních cílů, ale existuje velké riziko, že jeho investice bude ve výsledku ztrátová. I přes hrozící ztrátovost jsem však, díky tomu, že jsem vyhodnotil pořízení systému jako smysluplné, sestavil zákazníkovi obchodní nabídku, ze které je patrné, že vývoj systému bude stát 1 840 000 Kč, potrvá 132 pracovních dnů s dokončením před Vánoci, bude vyžadována součinnost ze strany zákazníka v rozsahu 2 hodin vždy jednou za 3 týdny a jako bonus zákazník dostane zdarma tuto případovou studii. Cíle práce jsem tedy splnil. Zpracováním této bakalářské práce jsem se utvrdil ve svém názoru, že je důležité před sestavením obchodní nabídky nejprve zjistit, zda je pořízení systému pro zákazníka smysluplné, jelikož se tím snižuje riziko, že bude s dodaným systémem nespokojený z důvodu, že jeho využitím nedosahuje svých obchodních cílů. Zároveň jsem se dozvěděl mnoho nových informací o SW architektuře a analýze požadavků zákazníka, které určitě ještě využiji. Osobně tuto práci uplatním v praxi při komunikaci se zákazníkem, který vytvoření systému pro moderní obchodování inicioval a nadále požaduje. Myšlenky a postupy v ní uvedené jsou však dle mého názoru využitelné obecně při vyhodnocování různých zadání na tvorbu aplikací. Práci je možné dále rozvíjet především z marketingového a finančního hlediska, která mohou detailněji seznámit zákazníka se způsoby oslovení prodejců či kupců a s přesným počtem prodejci vložených nabídek nutných k dosažení ziskovosti investice.

41

Literatura [1]

O nás [online]. [cit. 2014-05-05]. Dostupné z: http://info.aukro.cz/ about/

[2]

Historie Slevomat.cz [online]. [cit. 2014-05-05]. Dostupné z: http:// www.slevomat.cz/historie

[3]

O ANNONCI [online]. [cit. www.annonce.cz/o-annonci/

[4]

Kruchten, P.: Architectural Blueprints—The “4+1” View Model of Software Architecture. IEEE Software 12 (6), November 1995: s. 42–50.

[5]

Smolík, T.: Softwarová architektura [online]. Profinit, s.r.o., [cit. 201405-05]. Dostupné z: http://www.profinit.eu/fileadmin/Content/ profinit.eu/Academy/sweng-materialy/architecture-design/ reading/Profinit_SwArchitectureOverview.pdf

[6]

Microsoft: The Model-View-Presenter (MVP) Pattern [online]. [cit. 2014-05-05]. Dostupné z: http://msdn.microsoft.com/en-us/library/ ff649571.aspx

[7]

The Apache Software Foundation: Multi-Processing Modules (MPMs) [online]. [cit. 2014-05-05]. Dostupné z: http://httpd.apache.org/docs/ 2.4/mpm.html

[8]

Oracle: FOSS License Exception [online]. [cit. 2014-05-05]. Dostupné z: http://www.mysql.com/about/legal/licensing/foss-exception/

[9]

International Institute of Business Analysis: What is Business Analysis? [online]. [cit. 2014-05-05]. Dostupné z: http://www.iiba.org/Careers/ What-is-Business-Analysis.aspx

2014-05-05].

Dostupné

z:

http://

[10] Society, I. C.: IEEE Recommended Practice for Architectural Description of Software-Intensive Systems. IEEE Std 1472000, 2000. 43

Literatura [11] Cunningham & Cunningham, Inc.: Problem Domain [online]. [cit. 201405-05]. Dostupné z: http://c2.com/cgi/wiki?ProblemDomain [12] Oracle: Thread Safety [online]. [cit. 2014-05-05]. Dostupné z: http:// docs.oracle.com/cd/E26502_01/html/E35303/compat-14994.html [13] Microsoft: Microsoft Open Database Connectivity (ODBC) [online]. [cit. 2014-05-05]. Dostupné z: http://msdn.microsoft.com/en-us/library/ ms710252.aspx [14] Microsoft: About Drivers and Data Sources [online]. [cit. 2014-05-05]. Dostupné z: http://msdn.microsoft.com/en-us/library/ms710285.aspx [15] The Internet Society: Hypertext Transfer Protocol – HTTP/1.1 [online]. [cit. 2014-05-05]. Dostupné z: http://www.w3.org/Protocols/rfc2616/ rfc2616.html

44

Příloha

Slovník pojmů Obchodní analýza je soubor činností prováděných za účelem identifikace obchodních potřeb organizace, na základě kterých lze doporučit řešení, která přinesou vlastníkům požadovaný přínos [9]. SW architektura je elementární uspořádání systému složeného z navzájem provázaných komponent, prostředí, ve kterém se nachází, a ze zásad, jimiž se řídí jeho návrh a rozvoj [10]. Problémová doména je souhrn všech informací, které je nutné znát k vyřešení problému [11]. FOSS je označení aplikace užívající licenci ze stanoveného seznamu [8]. FOSS licenční výjimka je prostředek umožňující vývojářům FOSS aplikací využívat klientské knihovny MySQL (používající GPL) za podmínek licence, kterou používají ve své aplikaci [8]. Thread-safe je označení pro část kódu, která je užívána více vlákny naráz, a přesto se chová logicky správně, a to i v případě přístupu ke sdíleným zdrojům a jejich případné úpravy [12]. Open Database Connectivity je aplikační rozhraní umožňující aplikacím přistupovat k datům uloženým v různých systémech řízení báze dat (SŘBD = DBMS) [13]. Data Source Name je identifikátor databáze nebo souboru [14]. Hypertext Transfer Protocol je aplikační protokol sloužící mimo jiné ke komunikaci mezi webovým prohlížečem a webovým serverem [15]. Model-View-Presenter je návrhový vzor umožňující oddělení aplikační logiky od způsobu zobrazení a zpracování událostí [6].

45

A

Příloha

Seznam použitých zkratek MTS Modern Trading System ODBC Open Database Connectivity DSN Data Source Name FOSS Free and Open Source Software HTTP Hypertext Transfer Protocol MPM Multi Processing Module MVP Model-View-Presenter IE Internet Explorer

47

B

Příloha

Obsah přiloženého CD

readme.txt...................................stručný popis obsahu CD src thesis ...................... zdrojová forma práce ve formátu LATEX text BP_Duracka_Tomas_2014.pdf ............ text práce ve formátu PDF BP_Duracka_Tomas_2014.ps ............... text práce ve formátu PS 49

C

Sem vložte zadání Vaší práce

Recommend Documents