Návrh a tvorba mobilních aplikací v podnikovém prostředí

Transkript

1 Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií Návrh a tvorba mobilních aplikací v podnikovém prostředí Diplomová práce Autor: Bc.David Kopřiva Informační technologie Vedoucí práce: Ing. Jan Háněl Praha Duben 2012

2 Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací. V Praze, dne David Kopřiva

3 Anotace Předmětem diplomové práce Návrh a tvorba mobilních aplikací v podnikovém prostředí je popsání postupu návrhu a tvorby mobilní aplikace od rámcového zadání problému do návrhu konkrétního řešení. V první části práce jsou popsána východiska, moţné aktivity a technické aspekty řešení. Ve druhé části práce je na základě poţadavků společnosti CETELEM ČR, a.s. proveden výběr a návrh řešení. V závěru je porovnán návrh s původním zadáním, dále je provedeno zhodnocení cílového stavu a provedeného postupu. Klíčová slova: mobilní aplikace, prohlíţeč, swot analýza, vícekriteriální rozhodování, UML, Annotation The thesis "Design and creation of mobile applications in an enterprise environment" describes step by step how to design and create mobile applications from the scratch to specific design solution. The first part describes current situation, possible activities and technical aspects of the solution. The second part contains selection and design of solution based on the requirements defined by CETELEM CR. Proposed solution is compared with the original typing, evaluation process and the target state is described in the conclusion. Key words: mobile applications, browser, swot analysis, multicriteria analysis, UML, project management

4 Obsah ÚVOD... 7 ZVOLENÉ METODY ZPRACOVÁNÍ VSTUP DO PROBLEMATIKY Penetrace mobilních sluţeb a mobilního internetu ČR Uţití v ČR dle typu kanálu Trendy v oblasti chytrých telefonů Nástup Smartphone telefonů Integrace a sbliţování sluţeb mobilní singularita Auditované měření návštěvnosti mobilního obsahu a sluţeb PŘEHLED POTENCIONÁLNÍCH SLUŢEB Mobilní samoobsluha/podnikové WAPové stránky Mobilní telefon jako platební nástroj Mapy/Location based services (LBS) Augmented reality Mobilní web-content a s ním spojená reklama MMS marketing Samoobsluţné SMS automaty SMS/MMS Dodatkové sluţby pro tisk TECHNICKÉ ŘEŠENÍ MOBILNÍCH APLIKACÍ Aplikace pro mobilní prohlíţeč Historie standartu mobilních stránek Typy mobilních prohlíţečů Zabezpečení dat v mobilních prohlíţečích Vývoj pro prohlíţeč Nativní aplikace

5 3.2.1 Prostředí pro vývoj nativních aplikací Specifika nejrozšířenějších OS platforem Vývoj nativní aplikace Aplikace na bázi WAP Výhody a nevýhody vývojových prostředí Vývoj pro prohlíţeč Nativní vývoj aplikace WAP aplikace TEORETICKÝ APARÁT PRO ŘEŠENÍ SWOT analýza UML modelování Jazyk UML Vícekriteriální rozhodování Matematické postupy pouţité při výběru Techniky odhadu pracnosti Expertní odhady a analogie Odhady zaloţené na modelu Karnerova metoda UCP Ostatní metody Karnerova metoda UCP Řízení projektů SPOLEČNOST CETELEM ČR, A.S Popis společnosti Popis výchozího stavu SWOT analýza tvorby mobilních aplikací Vyhodnocení SWOT analýzy a definice kritérií VÝBĚR TECHNICKÉHO ŘEŠENÍ

6 6.1 Zadání problému Metodika pro výběr řešení Sestrojení normalizované matice Odhad vah kritérií metodou Fullerova trojúhelníku Vícekriteriální hodnocení variant metodou váţeného součtu WSA Seřazení a výběr řešení ÚVODNÍ STUDIE Odborný článek ANALÝZA A NÁVRH ŘEŠENÍ Zvolený postup pro provedení analýzy pomocí jazyka UML Katalog poţadavků Vazba uţivatelských poţadavků na případy uţití Diagram případů uţití Návrh hlavní stránky mobilní aplikace ODHAD NÁKLADŮ, ČASOVÉHO PLÁNU A BEZPEČNOST ŘEŠENÍ Odhad nákladů na realizační fázi za pomoci Karnerovy metody Rekapitulace odhadu nákladů na realizaci systému Časový plán projektu Rizika projektu Bezpečnost mobilních aplikací Typologie útoků na mobilní aplikace Návrh bezpečnostních testů ZÁVĚRY A DOPORUČENÍ SEZNAM POUŢITÉ LITERATURY SEZNAM OBRÁZKŮ SEZNAM TABULEK SEZNAM GRAFŮ

7 ÚVOD Cílem této diplomové práce je navrhnout a popsat postup tvorby mobilních aplikací v prostředí finanční společnosti CETELEM ČR, a.s. tak, aby byla splněna očekávání, která vedení společnosti od tohoto návrhu očekává. Společnost CETELEM ČR, a.s. lze charakterizovat jako silnou a stabilní společnost, která se svojí patnáctiletou tradicí na českém finančním trhu patří mezi největší a nejvýznamnější nebankovní poskytovatele úvěrových produktů a sluţeb. Prostřednictvím svých poboček a sítě obchodních partnerů nabízí klientům: klasické spotřebitelské úvěry v prodejnách obchodních partnerů účelové a neúčelové osobní půjčky kreditní karty produkty určené k financování motorových vozidel různé typy pojištění Vzhledem k dynamickému rozvoji sluţeb v prostředí Internetu a vzrůstajícím moţnostem přístupu k těmto informacím pomocí mobilních prostředků společnost CETELEM ČR, a.s. vnímá tuto situaci jako příleţitost pro vznik nového obchodního kanálu. Ten by mohl umoţnit rozšíření stávajících sluţeb z klasického desktopového prostředí do prostředí mobilních aplikací, kde se skrývá potencionál pro oslovení jak stávajících, tak nových klientů. Na základě tohoto návrhu se společnost CETELEM ČR, a.s. poté rozhodne, zda bude toto řešení realizovat či nikoliv. ZVOLENÉ METODY ZPRACOVÁNÍ Při zpracování této diplomové práce byl zvolen postup, který systematicky popisuje jednotlivé kroky od rámcového zadání problému aţ do fáze návrhu, ve kterém jsou shromáţděny a vyhodnoceny všechny údaje a informace nutné pro konečné rozhodnutí o realizaci. V rámci 7

8 těchto kroků jsou pouţity všeobecně známé a ověřené metody či techniky, které tyto dílčí kroky zprůhledňují a významně zkracují dobu nutnou pro vytvoření návrhu. Nejdříve je provedeno zmapování stavu mobilních sluţeb ve vazbě na prostředí Internetu (zejména s ohledem na Českou Republiku), stručný popis potencionálních sluţeb v tomto prostředí a technické aspekty při tvorbě mobilních aplikací. Vyuţití těchto poznatků je klíčové při vlastním procesu tvorby návrhu aplikace. Nedílnou součástí je rovněţ popis metod a postupů, které budou při návrhu a tvorbě aplikací vyuţity. V rámci zmapování výchozího stavu jsou nejdříve vyhodnoceny přístupy z mobilních zařízení na firemní web společnosti CETELEM ČR, a.s. Následně jsou za pomoci SWOT analýzy identifikovány interní a externí faktory, které umoţňují definici výběrových kritérií kladených na výběr vhodného technického řešení takovéto aplikace. Vlastní výběr technického řešení je proveden pomocí některé z metod multikriteriální analýzy. Na základě tohoto výběru je dále proveden návrh a dekompozice systému za pomoci prostředků jazyka UML včetně odhadu nákladů na celé řešení. Nedílnou součástí návrhu je také návrh plánu prací a popis bezpečnostních aspektů při návrhu aplikace. V závěru práce je provedeno jak zhodnocení provedených postupů, tak porovnání prvotních poţadavků na aplikaci s dosaţenými cíli. To má společnosti jiţ v poměrně rané fázi návrhu usnadnit rozhodnutí, zdali tento projekt za stávajících podmínek realizovat či nikoliv. 8

9 1 VSTUP DO PROBLEMATIKY Pro správné rozhodnutí a volbu vhodného řešení je nejdříve nutné zmapovat stav mobilních sluţeb a nejčastěji pouţívaných mobilních zařízení, včetně technických aspektů při tvorbě aplikací. Veškeré poznatky z teoretické části práce budou postupně uplatněny při návrhu a tvorbě mobilní aplikace. 1.1 Penetrace mobilních sluţeb a mobilního internetu ČR Mobilní telefon se v České republice řadí řadu let jiţ k základním potřebám. Telefon vlastní 92,5% obyvatel ve věkovém rozmezí 16 aţ 74 let, na 100 obyvatel pak připadá cca 130 aktivních SIM karet (toto se vysvětluje zahrnutím zahraničních vlastníků českých karet a vícenásobným vlastnictvím SIM tj. domácí a firemní/více operátorů). Pokrytí domácností v ČR představuje následující graf, v roce 2009 jsou všechny skupiny pokryty na cca 95%. Graf č. 1 Penetrace mobilních sluţeb v ČR Zdroj: ČSÚ Veřejná databáze Lze konstatovat, ţe postupným sniţováním cen za smluvní sluţby a zavedením datových tarifů dochází k přechodu od předplacených karet k sluţbám placeným po jejich konzumaci uţivatelem. Čísla o českém trhu prezentovaná na Mobile Fóru : počet obyvatel: 10,5M aktivních SIM karet: 14,3M počet SIM karet s mobilním internetem: 2,5M (oproti 1,5M v 2009) 1 Konference je společnou akcí serveru Lupa.cz provozovaného společností Internet Info a sdruţení TUESDAY Business Network v rámci jeho řady konferencí COMMUNICATION WEDNESDAY. 9

10 15% pouţívá mobilní internet pro připojení PC/notebook cca. 1,5M uţivatelů vlastní jiţ smartphone většina uţivatelů smartphone pouţívá mobilní internet (intenzivně na denní bázi) V roce 2010 došlo k výraznému zvýšení přenosové kapacity a cenové dostupnosti mobilního internetu v ČR. Většina operátorů přešla na paušální flat-fee tarify, přičemţ cena za internet v mobilním telefonu se za poslední rok sníţila aţ o 50%. Bariérou rozšíření mobilního internetu v ČR byla v posledních letech jednoznačně cena - technologie běţných přístrojů byla dostačující. Díky tomuto cenovému poklesu byl v letech 2010/2011 zaznamenán výrazný nárůst cílové skupiny disponující pouţitelným mobilním přístupem. 1.2 Uţití v ČR dle typu kanálu SMS - dle statistik operátorů je odesláno nejvíce zpráv právě přes 70 miliónů zpráv. Cena SMS se pohybuje od 1,20 Kč po 5,50 Kč. Uţití SMS v ČR stále patří mezi světový i Evropský nadprůměr. MMS - nejvíce MMS zpráv je odesláno a to cca tisíc. Penetrace MMS na stávajícím trhu je cca 60% - mobilní telefony, které nedokáţou přijmout MMS (či uţivatel nemá aktivovánu MMS sluţbu), mají moţnost si MMS vyzvednout v operátorově samoobsluze. Nejvíce MMS je posláno pouze s obrazovou přílohou, hlasové zprávy se vyskytují v méně neţ 1 % případů. Cena odeslané MMS je od 2,50 Kč, přijetí je zdarma. - nárůstem podílu BlackBerry 2 zařízení na českém trhu, integrací ového klienta do Symbian platformy a příchodem iphone/android zařízení dochází k nárůstu pouţívání tohoto kanálu. Díky sníţení ceny za datové připojení začíná pomalu přebírat zákazníky MMS, kteří mohou díky ům odesílat obrazová nebo zvuková data komukoliv bez nutnosti mít vhodné přijímací zařízení. Mobilní prohlížeč - pouţití mobilního prohlíţeče je v České republice vysoké díky relativně nízké ceně datového připojení. Nástupem iphone 3 zařízení se většina českých operátorů přiklání k datovým tarifům bez omezení, coţ umoţňuje připravit mnohem kvalitnější internetové prezentace vhodné pro mobilní zařízení. 2 Řada mobilních telefonů vyráběná společností Research in Motion (RIM) 3 Mobilní telefon od společnosti Apple 10

11 Na níţe uvedeném grafu jsou znázorněny podíly přístupu na webové stránky dle společnosti GEMIUS SA 4 řazené podle výrobce zařízení pro Českou republiku. Graf č. 2. Přístup na www stránky v České republice dle zařízení provedený společností GEMIUS SA Zdroj: GEMIUS SA J2ME 5 a Nativní aplikace - J2ME je podporováno přes 60% aktuálně dostupných telefonů v ČR. Podíl smartphone (tzv. chytrých telefonů) umoţňujících instalaci a provoz nativních aplikací roste strmě i v České republice. Níţe uvedený graf znázorňuje stáhnutí J2ME aplikací uţivateli dle výrobce zařízení, celkový objem činí cca staţení měsíčně. Graf č. 3 Staţení J2ME aplikací uţivateli v Q3 Zdroj: T-Mobile 4 Společnost GEMIUS SA se dlouhodobě zaměřuje na výzkum internetového trhu, 5 J2ME- Java Platform Micro Edition je jedna ze základních platforem Javy určená pro vývoj softwaru na malých zařízeních 11

12 1.3 Trendy v oblasti chytrých telefonů Nástup Smartphone telefonů [5] Jednoznačným trendem je rychle rostoucí podíl tzv. chytrých telefonů smartphones. Tento typ telefonu je charakteristický svými pokročilými funkcemi (např. datová konektivita, integrovaným prohlíţečem, přehrávání hudby atd.) a aplikačním rozhraním, které umoţňuje instalaci dalších programů do jeho operačního systému. Mezi nejznámější systémy patří Symbian OS, ios, Windows Mobile, Android a Blackberry. V roce 2011 podíl prodaných smartphones činil cca 50% V následujícím roce se očekává penetrace okolo 60% (60% pouţívaných telefonů budou tzv. chytré telefony) Cenová hladina za telefon definovatelný jako smartphone se neustále sniţuje: o 2009 cca 6000 Kč o 2010 smartphone = cca 3500 Kč Graf č. 4: Prodeje smartphonů v ČR za první pololetí 2011 Zdroj: mobil.cz Integrace a sbliţování sluţeb mobilní singularita Mobilní svět se stává méně samostatným a je čím dál tím více propojen a sloučen s ostatními komunikačními kanály. Stírá se rozdíl mezi mobilním obsahem či aplikací a jeho ekvivalentem pro desktop. Uţivatelé vyţadují přístup k datům a aplikacím různým způsobem, při různých situacích a Toto lze charakterizovat uţivatelskými scénáři začíná být standardem mít vybudován přístup k jedné a téţe funkci pomocí desktopu, mobilního prohlíţeče či nativní mobilní 12

13 aplikaci. Specifika mobilních konceptů neleţí dnes primárně v technologické rovině, ale v rovinách: Jiných uţivatelských scénářů use cases (co a jak jsou lidé zvyklí pomocí mobilního telefonu dělat) Jiného typu ovládání a očekávané UX user experience (typicky nástup dotykového ovládání a optimalizace pro něj) 1.4 Auditované měření návštěvnosti mobilního obsahu a sluţeb V České republice aktuálně probíhají aktivity pro podchycení jednotného a auditovaného měření mobilních sluţeb a obsahu. Tyto aktivity zaštiťuje tzv. mobilní metokomise, jejímţ členem jsou jak operátoři, tak přední poskytovatelé mobilního obsahu. [9] Aktivita jako taková je koordinována a zajišťována Sdruţením pro Internetovou reklamu viz Z posledního průzkumu, který se uskutečnil v listopadu 2011, jsou dostupné následující údaje o činnostech prováděných pomocí různých zařízení pro přístup na Internet. Graf č. 5: Činnosti prováděné prostřednictvím jednotlivých zařízení (internetová populace 15+), N=3000 Zdroj dat: NetMonitor - SPIR - Mediaresearch & Gemius, gemiusadhoc, listopad 2011 Překvapující je velký nárůst podílů u činností prováděných prostřednictvím mobilního telefonu. Proti minulé vlně průzkumu z jara 2011 se zvýšil podíl činnosti získávání praktických informací pomocí mobilního telefonu o 9 % a přístup k u o 7 %. 13

14 2 PŘEHLED POTENCIONÁLNÍCH SLUŢEB Abychom byly schopni zmapovat základní moţnosti v oblasti tzv. mobilního marketingu 6 a na něj navazující převod podnikových aplikací, je velice uţitečné provést stručnou rekapitulaci současného stavu. V tomto kontextu je nutné chápat mobilní telefon jako informační portál, který kaţdý nosí v kapse. Moţnost touto cestou doručit více relevantních informací dává téměř ihned obrovský potenciál ke zvýšení efektivity propagace. Mobilní sluţby jsou obvykle konzumovány v časech, kdy uţivatel není přítomen u počítače, tzn. je na cestách. Informace uţivateli lze doručit dvěma formami - internetovým přenosem nebo přímým kontaktem skrze WIFI/Bluetooth. Pro ilustraci, četnost registrace mobilních zařízení do buňky komunikační sítě poskytovatele sluţeb umoţňuje sledovat pohyb osob a vhodně rozmístěné snímače v prodejně dokáţou dle aktuálního pohybu zákazníků přehodnocovat rozmístění reklamy na obrazovkách. Dále se objevují pro-aktivní Bluetooth reklamní plochy poskytující mobilní verzi tištěné reklamy, WIFI zdarma slouţí primárně k propagaci výrobků na prodejnách atd. Rozvíjí se pouţití Location based services, které umoţňují vyhledávat uţivateli informace o svém okolí - obvykle v reálném světě, ale začíná se prosazovat i Augmented reality - virtuální svět na pozadí skutečného. Prostřednictvím vestavěné kamery můţete telefonem sledovat jak reálný svět okolo vás, tak i jeho virtuální verzi - od virtuálních reklamních ploch aţ po uţivatelem stvořené světy. 2.1 Mobilní samoobsluha/podnikové WAPové stránky Mobilní samoobsluha je forma aktivního přístupu klienta ke svým sluţbám. Neliší se od internetové samoobsluhy, ale při vhodné implementaci autentifikace klienta se zvyšuje komfort přístupu k těmto sluţbám. Výhodou pro klienta je pak dostupnost těchto sluţeb na cestách. Podnikové wapové stránky jsou určeny primárně k rychlé orientaci v aktuálním dění: od jednoduchých informačních stránek aţ po zábavní zónu. V kombinaci s WIFI připojením se jedná o další moţnost jak oslovit např. klienty čekající na pobočce. 6 Mobilní marketing je forma komunikace zaměřená na uţivatele mobilních telefonů 14

15 2.2 Mobilní telefon jako platební nástroj Rozmach Prémium SMS sluţeb sebou nese nové moţnosti prodeje jak skutečného, tak virtuálního zboţí. Prémium SMS se vyuţívá od zpoplatnění láhve výrobců nápojů aţ po virtuální vstupenky na různé informační zdroje. V přípravě je také systém, který integruje do mobilních zařízení plnohodnotnou platební kartu, která bude umoţňovat platby na platebních terminálech. Jednou z aktivit tuzemských operátorů je aktuální spolupráce na jednotné značce pro mikroplatební systémy z mobilu více viz Plať mobilem Mapy/Location based services (LBS) Mobilní zařízení vybavené GPS moduly (či umoţňující AGPS pozice ze sítě) mohou být pouţity k hledání objektů, které se nachází poblíţ. Příkladem můţe být mapa poboček firmy v rámci celé ČR, včetně informací o otevíracích dobách, nabízených sluţbách a dalších pobočkových specifik. Tato sluţba není primárně mobilní, ale je pouze doplňková pro jiţ stávající internetové řešení, které toto musí také zohledňovat. Převáţně se tyto informace zveřejňují v masově dostupných zdrojích (např. Google maps) či v rámci podnikových aplikací, které umoţňují získávat pozici ze zařízení. Existuje mnoho volných (či placených) LBS, které umoţňují shromaţďovat různé informace - od map nejbliţších obchodů aţ po dopravní informace. 2.4 Augmented reality Příkladem je projekt Layar 7, který umoţňuje vydavatelům připravit vrstvu s jejich daty, které lze pak prohledávat a zobrazovat uţivateli jako by se díval skrze telefon. Integrované senzory v zařízení umoţňují správné umísťovat objekty v prostoru a uţivatel tak můţe snadněji získávat informace o svém okolí. 2.5 Mobilní web-content a s ním spojená reklama Reklama se začíná dostávat jiţ i do mobilních telefonů. Velcí hráči na poli mobilní reklamy jiţ mají své mobilní reklamní systémy, které fungují na stejném principu jako internetové. Na českém trhu se mobilní reklamně věnují jak významní provozovatelé portálů (např. seznam.cz), tak i přímo operátoři. 7 Dostupný na adrese 15

16 Dalším kanálem se staly tzv. 'ad-sponsored gaming', které umoţňují firmám propagovat výrobky na plochách zapojených do těchto sítí. Obdobné reklamní plochy se také nabízí v rámci nativních free aplikací. 2.6 MMS marketing Přímý MMS marketing se v České republice vyuţívá minimálně, jeho nevýhodou je nízké pokrytí příjmů MMS a limit při posílání MMS ve velkém mnoţství. Pro tyto potřeby musí být vytvořeno spojení s kaţdým z operátorů - celá operace je relativně časově náročná. Obvyklé vyuţití MMS marketingu je zaměřeno na jiţ stávající sluţby, které mají známý okruh příjemců. 2.7 Samoobsluţné SMS automaty Rozmachem Prémium SMS přišly na řadu i čísla, která nic nestojí, coţ umoţňuje beznákladovou samoobsluhu pro firmy. Výhodou jsou nízké náklady na vývoj a údrţbu systému, coţ umoţňuje implementovat např. výzkumy spokojenosti zákazníků. Nevýhodou těchto automatů je nízká SMS gramotnost pro starší uţivatele. 2.8 SMS/MMS SMS umoţňují všechny mobilní telefony a v posledních 6 letech se s rozvojem pevných telefonních linek objevují i telefonní stanice umoţňující příjem a odeslání SMS. Limitace pro starší telefony je 160 znaků na SMS, bez české diakritiky (s diakritikou pak 70 znaků). Novější verze SMS umoţňují uţ i rozličné znakové sady a rozdělování SMS. Pomocí SMS lze přenášet jak melodie (tóny) tak i černobílé obrázky. Další SMS uţití jsou 'WAP Push' zprávy ty jsou pouţívány pro odesílání URL adres či konfiguraci internetu. Problematické u těchto zpráv je, ţe se v telefonech objevují obvykle v příchozích zprávách a ne v příchozích SMS. 2.9 Dodatkové sluţby pro tisk Dodatkové sluţby pro tištěnou reklamu jsou obvykle jako součást větší marketingové kampaně, tištěným prvkem jsou adresy (QR kódy) které umoţňují nasměrovat potencionální klienty na elektronickou verzi reklamy, která můţe obsahovat mnohem více informací neţ jen tištěná reklama. 16

17 3 TECHNICKÉ ŘEŠENÍ MOBILNÍCH APLIKACÍ Cílem této kapitoly je popsat moţné způsoby technického řešení mobilních aplikací, specifika vývojových prostředí, platformy a stručně porovnat výhody a nevýhody těchto řešení. 3.1 Aplikace pro mobilní prohlíţeč Prohlíţeče v mobilních zařízeních prošly velkým rozkvětem v průběhu posledních 15 let. Od černobílých 3 řádkových stránek aţ k plnohodnotnému PC internetu. Mobilní připojení prošlo vývojem od vytáčeného spojení (přenosová rychlost 28 KBit) přes GPRS(variabilní, od 32kBit aţ k 128kBit) aţ po 3/4G sítě ( > 21 Mbit). S tímto vývojem nutně přicházely změny systému zpoplatnění - od plateb za provolanou minutu, přes platbu za kb aţ k předplacenému přístupu. V dnešní době existují 2 modelyneomezený internet za paušální poplatek (obvykle doplněn FUP 8 ) či předplacený objem dat, v cenovém rozmezí od 150 Kč do 700 Kč měsíčně. V případě podnikových aplikací je moţné dojednat dohodu s operátory o nezpoplatnění uţivatelů při pouţití této aplikace (fixní náklady platí objednatel). Počet předplatitelů neomezených dat pouţívajících k přístupu pouze telefon se jako samostatné číslo nezveřejňuje, ale počet předplatitelů mobilního internetu bylo na konci roku 2009 cca 2,2 miliónů Historie standartu mobilních stránek Standard HDML 9 byl vytvořen v roce 1996 firmou Openwave a byl určen pro přístup mobilních zařízení na internetové stránky. HDML je koncipován s ohledem na moţnosti mobilních zařízení jako je velikost displeje, ovládacích prvků a přenosové rychlosti vytáčených linek. HDML mimo formátování textu, obrázků (dvoubarevných) obsahuje také skriptovací prvky - akci na základě vstupu uţivatele (vpřed/vzad, klávesové zkratky), moţnost více různých 'aktivit' v rámci jedné stránky (jednoduché kalkulačky atd.). V roce 1998 vzniká WML(Wirelles Markup Language) standart - veřejná specifikace pokrývající vlastnosti HDML a zároveň splňující kritéria XML. V Japonsku vzniká chtml se stejnými vlastnostmi, ale v Evropě není téměř uţíván. 8 FUP-Fair User Policy je způsob jak při sdílení přenosového pásma zamezit přílišnému stahovaní dat jednoho uţivatele na úkor ostatních 9 Handheld Device Markup Language 17

18 V roce 2001 vzniká specifikace XHTML Mobile Profile, odvozena od XHTML 1.0 doplněna o klávesové zkratky a jednoduché skriptování - dopředu/vzad. V roce 2005 společnost Google kupuje firmu zabývající se portováním Linuxu na mobilní zařízení - Android, Inc. a začíná vyvíjet operační systém pro mobilní zařízení zaloţený na Open Source platformě. To sebou přináší plnohodnotný prohlíţeč, který umoţňuje procházet stávající stránky Typy mobilních prohlíţečů Openwave Prohlíţeče jsou nainstalovány v různých verzích do velké škály mobilních zařízení, obvykle niţších cenových hladin. Podporují od WML aţ po XHTML-MP. Prohlíţeč odesílá detailní informace o verzi telefonu Opera (Opera mini) Podporovaná na PocketPC, MDA a Symbian Smartphones. Opera zvládá v jistě míře XHTML a ECMA 11 skriptování. Opera mini je dostupná pro J2ME (instalována jako Web'n'walk prohlíţeč). Obě Opery se identifikují jako Opera, ale odesílají dodatečnou informaci o zařízení Apple iphone a Android Zařízení podporují HTML5 pomocí Javascriptu je umoţněn přístup k dotykové obrazovce, geo informace, rozšířené instrukce pro CSS styly a implementováno SVG 12. Nevýhodou je nutnost testování na skutečných zařízeních, díky rozdílným podmínkám (fonty, rozlišení obrazovky) je také potřeba brát v úvahu více grafických verzí mobilní aplikace Podpora flash Flash je podporován na mobilních zařízeních s operačním systémem Android 2.2. Flash lite v browseru je podporován pouze pro Nokia Series60.V tomto módu můţe fungovat jako lokální aplikace, či síťová aplikace. 10 Wireless Markup Language je značkovací jazyk na bázi XML 11 ECMA je skriptovací jazyk spravovaný společností ECMA International 12 Scalable Vector Graphics je prostředek pro práci s grafickými objekty 18

19 3.1.3 Zabezpečení dat v mobilních prohlíţečích Zabezpečený přenos prostřednictvím protokolu HTTPS 13 je těmito zařízeními podporován. Problém ale vyvstává s důvěryhodnosti certifikátů, protoţe nainstalované certifikáty obvykle obsahují kořenové certifikáty Thawte/Verisign a operátorem dodané certifikáty. Na většině chytrých telefonů lze doinstalovat kořenové/klientské certifikáty, na ostatních nejdou z pravidla instalovat ţádné to můţe v některých případech vést aţ k nemoţnosti pouţívat aplikace. Unikátní identifikaci uţivatele (telefonní číslo) operátoři poskytují pouze na dohodnuté domény, smluvní proces trvá řádově měsíc Vývoj pro prohlíţeč Vývoj pro prohlíţeč lze charakterizovat jako orientovaný na server-side skriptování, tj. odpadá jakákoliv distribuce změn funkcionality. Skript musí být schopen rozpoznat zařízení a dle toho uzpůsobit výstup. Změny se týkají jak formátu výstupu), datových limitu, tak i třeba rozlišné interpretace odkazu s vnořeným obrázkem a textem. Existují Open Source i komerční projekty usnadňující tento vývoj. Při vývoji je potřeba kontrolovat kvalitu a konzistenci výstupu při existenci velké mnoţství zařízení. Zde se můţe stát, ţe klienti přistupující skrze brány operátorů se budou lišit. Při provozu aplikace je zároveň potřeba udrţovat aktuální seznam mobilních zařízení pro identifikaci a starat se o vzhled aplikace na nových zařízeních. 13 HTTPS je zabezpečený protokol určený pro komunikaci mezi serverem a prohlíţečem 19

20 3.2 Nativní aplikace Prostředí pro vývoj nativních aplikací Operační systémy mobilních zařízení procházejí vývojem tak, jak se vyvíjí technologické moţnosti hardwaru. Od jednoduchých 'programů' které fungovali pouze a jen na jednom typu zařízení aţ k plnohodnotným 'PC' operačním systémům distribuovaným mezi pěti výrobci. Existuje mnoho platforem, od primárně mobilních aţ k PC platformám konvertovaným na mobilní zařízení. Udrţet funkční kompatibilitu mezi těmito platformami je problematické, vzhledem k moţnostem a omezením, které jednotlivé platformy poskytují. Pro jednoduché aplikace vyţadující pouze vstup uţivatele se obvykle vyuţívá J2ME, která je s malými modifikacemi pouţitelná na naprosté většině zařízení na českém trhu. Nevýhodou je rozdílná implementace grafických prvků, proto se pouţívá obvykle vlastní implementace grafických prvků, coţ sebou nese náročnější vývojový cyklus. Pro lepší aplikace (např. integrace reklamy do videa nativně v telefonu) je jiţ zapotřebí pouţít programovací platformu určenou přímo pro toto zařízení. To sebou nese zvýšené náklady na lidské zdroje. Výrobci operačních systému se pokoušejí zvýšit podíl na trhu zavedením jednotného aplikačního trhu (iphone App market, Android market, Nokia Ovi store, Samsung Store atd.), coţ sice vede k zvýšení dostupného SW pro uţivatele, ale zároveň ke zvýšeným nákladům na straně vývojářů - aplikace se musí certifikovat. Samotné operační systémy mají implementovány bezpečnostní protokoly zaměřené proti zneuţití aplikačních prostředků, takţe uţivatel má jakousi kontrolu nad tím, co aplikace dělá. V případě Android/iPhone je moţné do originálního systému instalovat aplikace pouze z důvěryhodných zdrojů, tzn. 'not-rooted iphone/android' nepovolí nainstalovat aplikaci odjinud neţ ţe zabudovaného obchodu. Toto omezení lze obejít, pro případ Android je moţné povolit stahování z 'nedůvěryhodných' zdrojů, iphone tuto moţnost zatím neposkytuje Specifika nejrozšířenějších OS platforem Symbian OS Symbian OS je operační systém pro chytré telefony, který byl vyvinut na základě operačního systému firmy EPOC. První verze Symbian OS 6.1 se dostala na svět v roce 2001 spolu s 20

21 telefonem Nokia 9210 Communicator. V roce 2003 je vydán Symbian OS 7.0 pro Smartphones Sony Ericsson/Motorola (verze UIQ) a Nokia Series 60/80/90. Všechny se převáţně liší v GUI a ovládacími prvky. V roce 2008 došlo k zaloţení neziskového uskupení Symbian Foundation, které se stará o Symbian platformu jako celek pro všechny výrobce zařízení. K dnešnímu dní je Symbian OS pouţíván 5 výrobci - Nokia, Sony Ericsson, Sharp, Fujitsu a Mitsubishi. K vývoji se pouţívá programovací jazyk C++, který umoţňuje přístup k vnitřním knihovnám zařízení. Pro Symbian OS jsou tyto informace přístupné pouze autorizovaným vývojářům. Symbian umoţňuje plně ovládat mobilní telefon, od přístupu ke kontaktům aţ ke kontrole odchozích hovoru. Dále také umoţňuje běh aplikace na pozadí, mimo Nokia Series40 zařízení. Symbian umoţňuje podepisování aplikaci, ale to ve skutečnosti jen znamená, ţe vydavatel je registrován jako Symbian vývojář. Většina verzí obsahuje systém práv umoţňující uţivateli kontrolovat přístup k uţivatelským informacím a zdrojům zařízení. Symbian OS obsahuje nativně prostředí pro J2ME. Od verze OS 7.0 jsou dodávány s podporou Flash Lite. Nokia podporuje svůj vlastní aplikační obchod Nokia OVI store. Symbian se v posledních dvou letech stal OpenSource, nicméně nyní se opět stává uzavřenou platformou (informace z roku 2010). Nokia podporuje tvorbu Symbian aplikací různými online nástroji např. jednoduchým Ovi App Wizard Windows CE/Pocket PC/Windows Mobile Operační systém zaloţený na jádře Windows, jehoţ vývoj se datuje od roku Operační systém primárně určený pro HPC (Handheld PC), později adaptován pro Pocket PC/Smartphone. Systém CE je určen pro jednoúčelová zařízení (obvykle jediný program na popředí) s dotykovou obrazovkou, hardware klávesnicí a dalšími perifériemi pro komunikaci. Pocket PC je pouţíván primárně jako operační systém pro PDA (Personal Digital Assistent), po přidání GSM modulu do těchto zařízení slouţí jako MDA - Mobile Digital Assistant. Platforma umoţňuje streamovat audio/video, podporuje multitasking, 14 Dostupný na adrese 21

22 Vývoj je zaloţen na jazyce C++ a s vývojem.net pro PC se objevuje verze.net CF - Compact Framework, která je určena pro mobilní zařízení. V současné době se pro vývoj pouţívá.net pro aplikace a C++ pro specifické knihovny či jednoúčelové zařízení. Většina verzí obsahuje systém práv umoţňující uţivateli kontrolovat přístup k uţivatelským informacím a zdrojům zařízení. Windows neobsahuje nativně prostředí pro J2ME, Flash verze je v přípravě. Microsoft podporuje svůj vlastní aplikační obchod Windows Market. Lze konstatovat, ţe v současné době většina výrobců mobilních zařízení do svých nových produktů zařazuje spíše Android neţ Windows Google Android Operační systém zaloţený na Linuxu, spravovaný firmou Google. Plnohodnotný operační systém, který je určený primárně pro mobilní telefony. Aplikace se vyvíjí pomocí vlastního programovacího jazyka zaloţeného na JAVA, který umoţňuje plně kontrolovat telefon, zavedený multitasking umoţňuje více najednou spuštěných aplikaci. Obsahuje vestavěný systém práv umoţňující uţivateli kontrolovat přístup k uţivatelským informacím a zdrojům zařízení. Android má Flash verzi v přípravě. Google podporuje aplikační obchod - Android Market iphone / ios Zařízení společnosti Apple, které bylo vyvinuto a prodáváno od roku 2007, zaznamenalo od té doby obrovský nástup. Proprietární platforma jako první přinesla multitouch, větší vyuţití GPS/Location based services a defacto donutila operátory připravit neomezené datové balíčky. Aplikace se vyvíjí pomocí vlastního programovacího jazyka Objective C, který umoţňuje plně kontrolovat telefon, zavedený multitasking umoţňuje více najednou spuštěných aplikaci J2ME J2ME - Java 2 Mobile Edition. Verze mobilní Javy byla představena v roce 1998, v té době ještě jako PersonalJava, určena pro zařízení s omezenými prostředky. J2ME je dodávána jako hardwerová součást telefonu. U niţších cenových skupin obvykle představuje mikročip, u zařízení s operačním systémem je J2ME interpret instalován jako software. J2ME má několik verzi, kde kaţdá novější podporuje více vlastnosti a funkci. 22

23 MIDP - Mobile Information Device Profile, rozhraní umoţňující přistupovat k síťovým prostředkům. Verze MIDP 1.0 umoţňuje pracovat aplikaci na telefonu (základní aplikační cyklus, http spojení, uţivatelské rozhraní a trvale úloţiště dát). Verze MIDP 2.0 rozšiřuje verzi 1.0 o zabezpečené http spojení, ovládání multimédií, přístupová práva aplikace a podepisování aplikace. Nevýhodou vývoje pro J2ME je nutnost připravovat mnoţství verzí aplikací, ať uţ z důvodů rozličných velikosti obrazovky, schopností přístroje či maximální velikostí aplikace. Podepisování aplikace slouţí k zajištění 'důvěryhodnosti' vydavatele aplikace - certifikovaná autorita zkontroluje aplikaci, zdali neumoţňuje nevhodné chování a zároveň umoţní přístup k citlivým informacím bez souhlasu uţivatele. Nedůvěryhodné aplikace jsou při kaţdém takovém dotazu přerušeny a uţivatel je dotázán, zdali povolí aplikaci přístup. J2ME neumoţňuje běh aplikace na pozadí, při kaţdém předání řízení (příchozí SMS, příchozí volání) je aplikace zastavena a poté můţe být znovu spuštěna. J2ME je moţné provozovat na platformě iphone/android/windows mobile pouze s doinstalovaným J2ME prostředím, které je dostupné v mnoha verzích. Obecně se ale toto nedoporučuje výrobci zařízeni mají svůj vlastní aplikační jazyk Flash Flash lite je podporován na téměř všech Symbian zařízeních v různých verzích, umoţňující programovat samostatné aplikace, šetříce obrazovku a tapety. Flash podporuje přístup na internet, obsluhu kontaktů a ostatních osobních údajů, dále pak komunikace s perifériemi. Zabudovaný bezpečnostní systém umoţňuje uţivateli kontrolovat vše, co aplikace dělá. Podepisování aplikaci je prováděno vývojářem, který musí být zaregistrován u výrobce Flash - společnosti Adobe. 23

24 3.2.3 Vývoj nativní aplikace Vývoj nativní aplikace lze rozdělit do 2 fází: příprava modelové verze, při které se vyrobí prvotní verze aplikace na modelové zařízení dále se modifikuje modelové verze pro ostatní zařízení. Při vývoji se stává, ţe aplikace v dané podobě není schopna běţet na minoritním zařízení a proto je buď z podpory vyškrtnuta, či se musí napsat vlastní verze. Pro J2ME se připravuje cca 17 rozdílných verzí aplikace, cca 6 rozlišení a 5 různých platforem. Pro zvýšení důvěryhodnosti aplikace je vhodné ji podepsat, tj. odeslat ji certifikační autoritě, která tuto verzi aplikace podepíše. Tím uţivateli odpadne nutnost povolovat jednotlivé akce aplikace např. ohledně způsobu komunikace, práce s kontakty atp. Pro iphone se vyrábí jen jedna verze, pro Android verzi je třeba jedna aplikace, která zvládne čtyři rozlišení. Dále následuje distribuce aplikace, která se skládá buďto z publikace na vlastních stránkách nebo v případě iphone/android se zveřejňuje na stránkách vestavěného obchodu. 24

25 3.3 Aplikace na bázi WAP Další alternativou při tvorbě mobilních aplikací můţe být řešení zaloţené na bázi protokolu WAP Wireless Application protocol. Jedná se o technologii, resp. mnoţinu protokolů, které umoţňují zobrazení obsahu www stránek v mobilních zařízeních, kde není nebo nebyl k dispozici dostatečný výpočetní výkon (málo výkonné CPU, malá velikost paměti, malý displej, klávesnice atd.) [7] Celé řešení bylo nejdříve komerčně dostupné ve verzi 1.0, která vyţadovala stránky napsané v jazyce WML(Wireless Markup Language). Toto byla zjevná nevýhoda, protoţe v případě provozování klasické i mobilní verze stránek musely být udrţovány dva odlišné zdrojové kódy HTML a XML. Nástupcem je verze 2.0, která je jiţ pouţívá jazyk XHTML MP (XHTML Mobile Profile), který je zaloţený na obecném jazyce XML. Hlavním grafickým formátem je zde PNG, verze jiţ není závislá na WAP gateway (tedy prostředník mezi koncovým mobilním zařízením a serverem, který poskytuje obsah), podporuje CSS styly (různá barva textu a jiných prvků). Architektura je tvořena těmito vrstvami: Aplikační vrstva (WAE) v zásadě programátorské prostředí, vrstva je zaloţena na kombinaci WWW a technologie mobilních přístrojů. Relační vrstva (WSP)-komunikační rozhraní, sluţby nad transakčním protokolem WTP a nad datagramovou sluţbou WDP Transakční vrstva (WTP) vrstva poskytující transakční protokol pro klientskou stranu Bezpečnostní vrstva (WTLS)-obdoba bezpečnostního protokolu SSL Transportní vrstva (WDP)- nabízí transportní sluţby vyšším vrstvám WAP jako takový je v zásadě ekvivalent k internetovým protokolům v GSM, historicky je podporován téměř všemi typy mobilních telefonů a dostupný v rámci nabídky sluţeb mobilních operátorů. 25

26 3.4 Výhody a nevýhody vývojových prostředí V následující kapitole jsou uvedeny nejčastější výhody a nevýhody jednotlivých vývojových prostředí. Cílem není detailní porovnání, ale spíše obecný přehled hlavních předností a nedostatků Vývoj pro prohlíţeč Výhody Existují standardy umoţňující sdílet vývoj pro různá zařízení/výrobce (WebKit jádro, HTML5) Standardizace prohlíţečů je podporována výrobci a odbornými skupinami obecně potenciálně niţší náklady na vývoj a údrţbu Není třeba instalovat do cílového zařízení Nové verze není třeba jakkoli distribuovat funkce instant update Ze své podstaty vţdy pro uţivatele zdarma Prohlíţečem disponuje i řada hloupých telefonů bez OS Niţší nároky na paměť telefonu Tabulka č. 1 Výhody a nevýhody vývoje pro prohlíţeč Zdroj: Autor Nevýhody 26 Prohlíţeč má omezenu maximální velikost stránky, včetně přiloţených zdrojů. Z důvodu čitelnosti a přehlednosti je potřeba stránku optimalizovat pro velké mnoţství zařízení. Velkým problémem bývá dodrţení jednotného vzhledu. Starší prohlíţeč má striktní validaci a ţádné opravné mechanismy, např. pokud u obrázku chybí alternativní text. Openwave prohlíţeč zobrazí chybu stránka není v pořádku. Prohlíţeč dokáţe udrţet omezený počet Cookie. Např. starší telefony udrţí jen 20 Cookies, přetrvávající do vypnutí telefonu, či zařízení, které datum expirace cookies mají nastaveno na maximálně 30 dní. Prohlíţeč nemá přístup k ţádné informaci v telefonu. Nedokáţe 100% uchovat identitu zákazníka, ale je moţné poţádat operátory o poskytování těchto informaci pomocí jejich vnitřní infrastruktury. Verze prohlíţeče je obvykle vztaţená k Firmware telefonu, dva stejné telefony s různým firmware mohou zobrazovat stránku rozdílně. Prohlíţeč přistupuje na aktuální stránku veškeré statické zdroje jsou umístěny mimo zařízeni. Telefony si umí uchovávat některé zdroje v paměti toto má ale omezeni např. Nokia Series40 pojme cca 2 MB obrázků.

27 3.4.2 Nativní vývoj aplikace Výhody Aplikace má přístup k vlastnostem telefonu (specifikováno v API). Můţe načítat unikátní identifikátory zařízení (SIM, IMEI), zjišťovat informace ze sítě atd. Aplikace má po schválení přístup k datům v telefonu (SMS, adresář) a k určení polohy Aplikace po instalaci stahuje jen potřebná data (menší datový provoz). Zároveň vyţaduje striktní implementaci přenosového protokolu, který musí být orientován na data. Aplikace můţe pouţívat i SMS/MMS pro komunikaci. K tomuto kroku obvykle dochází, pokud je uzavřena smlouva s operátorem a v tomto případě je SMS/MMS komunikace zdarma. Můţe lépe vyuţít specifika telefonu (GUI, grafika, integrace ovládání) Tabulka č. 2 Výhody a nevýhody vývoje nativní aplikace Zdroj: Autor Nevýhody Aplikační prostředí je závislé na modelové řadě a vybavení zařízení. Problematická bývá síťová komunikace, přístup k audio a video funkcím a chování periférií (SD karta atd.). Obecně vyšší náklady na vývoj a údrţbu při stejném pokrytí trhu Aplikace má integrovaný graficky design a předdefinované chování. Vzhledem k roztříštěnosti grafického rozhraní mobilních zařízení, je potřeba aplikaci koncipovat v několika rozměrech a verzích ovládání telefonní klávesnice, touchscreen, multitouch. Aplikaci pro změny funkcionality je potřeba znovu redistribuovat klientům pomocí obvykle uţivatelem vyvolané aktualizace. Při vylepšování aplikace je obvykle nutné zachovávat zpětnou kompatibilitu nebo notifikační systém, který uţivatele informuje o nové verzi WAP aplikace Výhody Prověřená technologie Dostupnost a podpora téměř na všech typech mobilních telefonů Nevýhody slabší grafická prezentace oproti nativní aplikaci nebo aplikaci vytvořené přímo pro prohlíţeč nejasná budoucnost a další vyuţití protokolu WAP v současné době můţe být jiţ chápana jako zastaralá technologie Tabulka č. 3 Výhody a nevýhody vývoje WAP Aplikace Zdroj: Autor 27

28 4 TEORETICKÝ APARÁT PRO ŘEŠENÍ 4.1 SWOT analýza SWOT analýza představuje ucelenou metodu kvalitativního vyhodnocení veškerých relevantních stránek právě řešeného problému. Je v celku lhostejno, zdali se jedná např. o projekt, tvorbu strategie nebo procesů či uvedení nového produktu na trh. SWOT je také důleţitým nástrojem pro celkovou analýzu vnitřních a vnějších činitelů. Analýza spočívá v rozboru a hodnocení současného stavu (interní analýza) řešeného problému, kdy se hodnotí silné (Strenghts) a slabé (Weaknesses) stránky a současně situace okolí (externí analýza), kdy jsou hodnoceny hrozby (Threats) a příleţitosti (Opportunities) spojené s řešenou problematikou. Pokud např. hodnotíme podnik jako celek, tak těţiště úspěchu bude spočívat v maximalizaci jeho předností (silných stránek) a příleţitostí, a naopak minimalizací jeho nedostatků (slabých stánek) a hrozeb. SWOT analýza také můţe být chápána jako rozvaha, kdy jednotlivé faktory rozdělíme podle níţe uvedené tabulky. SWOT- analýza Silné stránky Interní analýza Slabé stránky E x t e r n í a n a l ý z a Příležitosti Hrozby S-O-Strategie: W-O-Strategie: Vývoj nových metod, které Odstranění slabin pro vznik jsou vhodné pro rozvoj silných nových příleţitostí. stránek společnosti (projektu). W-T-Strategie: S-T-Strategie: Vývoj strategií, díky nimţ je Pouţití silných stránek pro moţné omezit hrozby, zamezení hrozeb. ohroţující naše slabé stránky. Tabulka č. 4. Uspořádání jednotlivých kvadrantů Swot analýzy Zdroj: 28

29 4.2 UML modelování Jazyk UML [2] Jazyk UML (Unified Modeling Language) lze charakterizovat jako prostředek pro grafickou tvorbu objektových modelů. Jazyk jako takový se je znám od poloviny devadesátých let, kdy došlo ke sloučení do té doby dvou nejvíce pouţívaných metodik Booch 15 a OMT 16. Nejdříve vznikla verze 1.0, která začala být konsorciem OMG 17 doporučována jako standard, coţ umoţnilo její rozšíření. V současné době je UML k dispozici ve verzi 2.0, kde jsou k dispozici nové typy diagramů, zejména diagram přehledu interakcí, načasování a smíšené struktury. Obrázek č.1 Unified Modeling Language Zdroj: Diagram balíčků (Package Diagram) Slouţí k dekompozici systému a seskupení souvisejících prvků v modelu. Jejich prostřednictvím je moţné znázornit závislosti mezi dílčími částmi systému 15 Booch metodika zaměřená zejména na design a implementaci 16 OMT: Object Modeling Technique 17 OMG: Object Management Group 29

30 Diagram aktivit (Activity Diagram) Modeluje chování systému a znázorňují tok činností, tj. sled jejich provádění včetně větvení na základě splněných podmínek. Diagram případů užití (Use Case Diagram) Slouţí ke znázornění chování systému z pohledu uţivatele(actora), lze znázornit interakci systému a uţivatelů při vykonávání určité ohraničené jednotky činností. Diagram tříd (Class Diagram) Slouţí ke znázornění statické struktury modelovaného systému, znázorňuje typy objektů a vztahy mezi nimi. Jedná se patrně o nejznámější diagram. Stavový diagram (State Machine Diagram) Slouţí ke znázornění stavů a přechodů mezi nimi. Typicky se jedná o stavy jedné třídy nebo ţivotní cyklus entity. Diagram komunikace (Communication Diagram) Dokumentují spolupráci objektů při řešení úlohy a zobrazují toky událostí mezi třídami včetně jejich pořadí (dříve se nazývaly diagramy kolaborace) Diagram komponent (Component Diagram) Zobrazuje a popisuje jednotlivé komponenty, ze kterých se celý systém skládá. Diagram vnitřní struktury (Composite Structure Diagram) Jsou určeny pro vyjádření kolaborace instancí a instancí komunikačních struktur Diagram nasazení (Deployment Diagram) Popisují fyzické rozmístění jednotlivých komponent v rámci výpočetního systému. Diagram přehledu interakcí (Interaction Overview Diagram) Zachycuje tok řízení v rámci systému nebo procesu. Kaţdý uzel nebo aktivitav rámci diagramu můţe reprezentovat další diagram interakce. Objektový diagram (Object Diagram) Znázorňuje objekty a jejich vztahy na úrovni jejich konkrétních instancí. Sekvenční diagram (Sequence Diagram) Znázorňuje, jak se jednotlivé akce instancí tříd mění v čase včetně vzájemné komunikace mezi nimi. 30

31 4.3 Vícekriteriální rozhodování [1] Podstatou úloh vícekriteriálního rozhodování se rozumí výběr jedné varianty z mnoţiny (v dané chvíli potencionálně realizovatelných) variant na základě zvolených kritérií. Volba optimální varianty je závislá na celé řadě faktorů a zejména na zvolených vahách kritérií. Velmi častou chybou je snaha o zjednodušení celého procesu tím, ţe se zredukuje počet kritérií hodnocení. Jedním z klíčových momentů je volba metody, která je pro daný typ rozhodnutí pouţita. Některé metody jsou zaloţené na převodu kritérií na společnou jednotku, která můţe mít buď hodnotové vyjádření (za pouţití tzv. převodních můstků např. do peněţní formy) nebo na nějakou bezrozměrnou veličinu. Zde je opět důleţitý způsob, jakým jsou stanoveny váhy jednotlivých kritérií. Metody mohou zaloţené na přímém stanovení vah (bodová metoda, metoda pořadí) nebo na párovém srovnávání (metoda párového srovnávání 18 nebo Saatyho metoda). Pokud je kritérií vice (zpravidla více neţ 10), tak lze vyuţít metodu postupného rozvrhu vah, která umoţňuje ohodnotit významnost kritérií etapově. Dále je důleţité zdůraznit, ţe zvolená varianta na prvním místě preferenčního uspořádání je variantou optimální pouze v případě, ţe: soubor hodnotících kritérií obsahuje všechna významná hlediska a faktory bude platit, ţe po realizaci této varianty se nezmění hodnoty, ze kterých se vycházelo v momentě rozhodování Multikriteriální vyhodnocovací metody je moţné rozdělit podle výpočetního principu dle: maximalizace uţitku minimalizace vzdálenosti od ideální varianty vyhodnocování variant na základě preferenční relace Mezi nejznámější metody, které jsou zaloţeny na těchto principech, patří např.: Metoda váţeného součtu (WSA Weight Sum Approach) Metoda ideálních bodů (IPA - Ideal Points Analysis) Metoda TOPSIS (Technique for Order Preference by Similarity to Ideal Solution) Metoda shody a neshody (CDA - Concordance Discordance Analysis) 18 téţ známa jako Fullerův trojúhelník 31

32 4.3.1 Matematické postupy pouţité při výběru Výpočet vah kritérií v i -normovaná váha i-tého kritéria p i -počet preferencí i-tého kritéria k-počet kritérií Metoda WSA - Maximalizační kritérium y ij dílčí funkce uţitku i-tého kritéria D j nejniţší kriteriální hodnota kritéria y ij (při maximalizaci nejhorší varianta a opačně) H j nejvyšší kriteriální hodnota kritéria y ij (při maximalizaci nejhorší varianta a opačně) Metoda WSA - Minimalizační kritérium Celkový uţitek varianty Celkový uţitek jedné varianty se vypočítá jako váţený součet dílčích uţitků jednotlivých kritérií. X varianta rozhodování v j váha i-tého kritéria y ij dílčí funkce uţitku i-tého kritéria k - počet kritérií 32

33 4.4 Techniky odhadu pracnosti [4] Provedení odhadu ceny vývoje SW řešení nebo tvorby nové aplikace a její zavádění do informačního systému společnosti je v rámci procesu dalšího rozhodování o způsobu implementaci poměrně kritickou záleţitostí. Metody odhadu nákladů lze rozdělit zhruba do níţe uvedených kategorií, které vycházejí zejména z druhu a mnoţství vstupních informací, které o systému či softwaru máme: - Expertní odhady a analogie - Odhady zaloţené na modelu (Cocomo, FPA) - Ostatní metody Expertní odhady a analogie Tento typ odhadu je prováděn expertem, na základě jeho znalostí. Lze pouţít všude tam, kde při odhadu návrhu systému nejsou k dispozici měřitelná data. Hlavním cílem je provedení odhadu velikosti jednotlivých fází, tj. analýzy, návrhu, kódování, testování, vytvoření dokumentace a následné uvedení do provozu. Analogický typ odhadu lze pouţít ve chvíli, kde jsou k dispozici údaje o podobných projektech, na základě kterých jsme schopni popsat rozdíly mezi těmito projekty a námi navrhovaným systémem. Tyto rozdíly poté ovlivňují na námi odhadovanou pracnost Odhady zaloţené na modelu Pojem model lze chápat jako závislost velikosti projektu na pracnosti, který byl vytvořen na základě nashromáţděných dat ze skutečných projektů. Nejznámější metody odhadu nákladů zaloţené na modelu jsou: Cocomo (Constructive Cost Model) Jedná se o metodu vytvořenou B.Boehmem 19, která vychází z úvahy, ţe pracnost, cena a čas nutný pro vytvoření nového systému je úměrný velikosti zdrojových souborů kódu takového systému. 19 B.Boehm je americký softwarový inţenýr, který metodu COCOMO publikoval v roce

34 Metoda pouţívá různé úrovně detailu výpočetního modelu (základní, střední a pokročilý model) a složitosti vývoje (tzv. organický,bezprostřední a vázaný mód). Základní vztahy pro výpočet úsilí (E-effort) a času (T-Time) jsou následující: E= a (KSLOC)^b T=c E^d Symboly a,b,c,d představují parametry zvolené podle úrovně detailu a sloţitosti, hodnota KSLOC se uvádí jako tisíce řádků programového kódu. Z výše uvedeného je zřejmé, ţe v případě, kdy není k dispozici odhad velikosti budoucího kódu, je tato metoda nepouţitelná. Function Point Analysis(FPA) Při této metodě jsou jako měřítko sloţitosti pouţity tzv. funkční body, které lze chápat jako jednotku výroby při tvorbě softwaru. Nejdříve se stanoví tzv. neupravené funkční body NFP (identifikované dle transakčních nebo datových funkcí), které se poté rozdělí do skupin podle typu a sloţitosti. Počet těchto bodů z kaţdé skupiny se vynásobí vahou a následně se vše sečte, čímţ se získá hodnota NFP Dále se odhadovaný systém ohodnotí 14 faktory, které jej charakterizují (např. jaká je poţadovaná dostupnost dat). Kaţdý faktor je poté hodnocen číslem od 0 do 5. Součtem těchto hodnocení získáme sumu všech charakteristik - Σ Fi Upravené funkční body získáme následovně: FP = 0,65. 0,01 Σ Fi. NFP Celkový odhad je poté proveden podle pracnosti kaţdého funkčního bodu FP Karnerova metoda UCP Tato metoda je podrobněji popsána v kapitole

35 4.4.4 Ostatní metody Metody jako Pricing to win nebo Parkinsonův zákon jsou v praxi často pouţívány, ale vţdy je nutné zváţit jejich objektivitu. Termín Pricing to win chápeme jako částku, kterou je zákazník ochoten investovat bezprostředně do vývoje čí koupě SW na základě rozpočtu, který na takový vývoj má. Zároveň se počítá s tím, ţe k dokončení plné funkcionality produktu dojde aţ později, např. formou víceprací, zvýšenou údrţbou atd. Podle Parkinsonova zákona bude pracnost taková, ţe spotřebuje všechny dostupné zdroje a čas. Pokud má být projekt dokončen nejpozději do jednoho roku a k dispozici jsou 4 pracovníci, tak celková pracnost bude 48 člověko-měsíců. 4.5 Karnerova metoda UCP [6] Metoda byla vyvinuta v roce 1993 Gustavem Karnerem. Je zaloţena na analýze function points, která vznikla v 70. letech ve výzkumných laboratořích IBM. Výhodou této metody je fakt, ţe můţe být pouţita jiţ v rané fázi návrhu systému, kdy ještě není k dispozici podrobná analýza funkcionalit navrhovaného systému. V této fázi máme pouze hrubý přehled funkcí systému, které budou poţadovány budoucími uţivateli. Modely jednání - use case - mohou být v tomto případě jednoduše pouţity pro odhad sloţitosti vývoje softwaru a jeho testování. Výpočet use case points se skládá ze tří částí: 1. Neupravený UCP o Počet aktorů: aktoři se rozdělí do třech kategorií, kterým se přidělí váhy Jednoduchý: jiný systém připojený na odhadovaný systém přes interface, váha=1 Průměrný: další systém, který na odhadovaný systém komunikuje přes protokol, váha=2 Sloţitý: představuje osoby, které komunikují se systémem přímo přes grafické rozhraní, váha=3 Získaná hodnota představuje celkovou nevyrovnanou váhu aktorů (Total Unadjusted Actor Weight uaw) o Počet use case: jednotlivé případy uţití se zařadí do kategorie sloţitosti podle počtu transakcí v jednotlivém případu: - jednoduchý (méně neţ 4 transakce) 35

36 - střední (4 aţ 7 transakcí) - sloţitý (více neţ 7 transakcí). a těmto kategoriím se přidělí váhy: 5 (jednoduchý), 10 (střední) nebo 15 (sloţitý). Získaná hodnota představuje celkovou nevyrovnanou váhu počtu případů uţití Unadjusted Use Case Weight uucw) (Total Neupravený UCP (Unadjusted use case points) je součtem obou předchozích, tedy uucp = uaw + uucw 2. Technický faktor Provede se ohodnocení systému z technického pohledu, kde se 13 technických faktorů ohodnotí známkou od 0 do 5. Nejniţší hodnota představuje bezvýznamný vliv na systém, naopak čím je hodnota vyšší, tím faktor významně ovlivňuje navrhovaný systém. Výsledkem je sumární tfactor, celkový technický faktor pak: tcf = 0,6 + (0,01 * tfactor ) 3. Faktor prostředí Provede se ohodnocení 8 faktorů, které souvisejí se znalostmi a dovednostmi zaměstnanců. Známky jsou stejné jako u technického faktoru, výsledkem je sumární efactor, celkový faktor prostředí pak: ef = 1,4 + (-0,03 * efactor ) Celkový počet UCP získáme roznásobením nevyrovnané části UCP technickým faktorem a faktorem prostředí: aucp = uucp * tcf * ef Tuto hodnotu (v této chvíli se jedná o bezrozměrné číslo) je potřeba převést na skutečnou pracnost, kterou představuje hodnota člověkohodina. Dle Karnera je doporučeno 20 hodin na jeden aucp, dle jiných autorů kolísá hodnota v rozmezí hodin. 36

37 4.6 Řízení projektů Pojem projekt je třeba chápat jako souhrn koordinovaných aktivit za účelem změny stávajícího stavu do stavu nového. Je jasné, ţe do celého procesu jiţ vstupujeme s jistými omezeními a v jeho průběhu je třeba počítat s různými rizikovými faktory. Jak velice vhodný nástroj můţe být pouţití některé ze známých metodik. Tu chápeme jako souhrn definovaných pravidel a postupů, které nám při jejich dodrţení umoţní lepší zvládnutí celého procesu. [3] Mezi nejznámější metodiky patří např. PRINCE2 20. Mezi klíčové vlastnosti projektu patří zejména: Určení jednoznačného cíle Vypracování smysluplného, resp. do fázích rozděleného plánu (harmonogramu) Alokaci patřičných zdrojů Jasné určení rolí ve smyslu zákazníka nebo zadavatele Akceptační kritéria: stanovit na začátku projektu, musí být měřitelná Mezi kritické faktory projektu řadíme: Součinnost jak mezi řešiteli, tak uţivateli Podporu vedení společnosti-aktivní roli sponzora Specifikaci poţadavků Plán prací Očekávání V rámci ţivotní cyklu projektu je třeba naplánovat jednotlivé etapy tak, aby výstup jednotlivé fáze navazoval na další a nedocházelo k neţádoucímu návratu do předchozího stavu. Jedinou výjimkou by měl být proces řízené změny, který se můţe objevit ve fázi realizace celého projektu. Nejčastěji se jedná o pozdě nebo nedostatečně identifikované poţadavky mezi původním zadáním (představou zadavatele) a způsobem realizace řešitelem (tj. dodavatelem). 20 Metodika PRINCE2 je spravována a rozvíjena organizací The Office of Government Commerce(OGC) 37

38 Ţivotní cyklus projektu je vhodné rozdělit do čtyř fází, které musí mít jasné výstupy. To je předpokladem zahájení jak další fáze, tak moţnosti provádět průběţné kontroly a vyhodnocovat plnění a dodávky na projektu. Fáze1-Iniciace: popis výchozího a cílového stavu (zejména proč jej chceme dosáhnout), tvorba dokumentu na úrovni studie proveditelnosti. Výstupem je schválení projektu. Fáze2-Plánování a návrh řešení: Tvorba rozpočtu a detailního harmonogramu, volba vhodného technického řešení, smluvní zajištění. Výstupem je schválené řešení. Fáze3-Realizace (implementace) řešení: Vlastní tvorba řešení, integrace do okolních systémů, testování a školení. Výstupem je akceptace implementovaného řešení v této části projektů podle výsledku integračních testů. Fáze4-Zavedení do provozu: Provozní testy, zkušební a pilotní provoz, na který navazuje proces plného převzetí díla do provozu. Výstupem je protokol o převzetí a vyhodnocení celého projektu nejčastěji formou posouzení shody s původním zadáním z fáze 1. Rizika projektu je nutné chápat jako určitou míru nejistoty, která provází celý ţivotní cyklus projektu. Rizika můţou mít kladný (jejich poznáním a řízením eliminujeme neúspěch projektu) nebo záporný vliv (nedostatečná identifikace vede k zvýšení nákladů projektu a prodluţování doby celkové realizace) na splnění cílů projektu. Proces řízení rizik projektu je znázorněn na následujícím obrázku tak, jak jej chápe metodika PRINCE2. Obrázek č.2 Procedura řízení rizik Zdroj: Managing Successful Projects with PRINCE2 38

39 Procedura risk managementu je tedy rozčleněna do pěti oblastí: Identifikace rizik: zjištění potencionálních oblastí a rozpad na dílčí rizika, popsání rizik. Lze vyuţít různé techniky, např. brainstorming, risk checklist, rozhovor atd. Posouzení rizik: zejména kvalitativních (hodnocení pravděpodobnosti a dopadu těchto rizik, jejich velikost a priorita) a kvantitativních (číselné odhady dopadů). Plánování řízení rizik Stanovení plánu postupu a kontroly projektu tak, aby byly redukovány nebo odstraněny hrozby a naopak naplněny příleţitosti, které má projekt přinést Implementace opatření spočívá zejména v dohledu nad prováděnými opatřeními, rovněţ je důleţitá identifikace vlastníka rizika Komunikace Je nutné chápat jako průběţnou činnost ve všech fázích, kde je formou reportů (kontrolní, zápis ze schůzky, ukončení) prováděn neustálý monitoring stavu řízení rizika. 39

40 5 SPOLEČNOST CETELEM ČR, A.S. 5.1 Popis společnosti Společnost CETELEM ČR, a.s. je silná a stabilní společnost, která se svojí patnáctiletou tradicí na českém finančním trhu patří mezi největší a nejvýznamnější nebankovní poskytovatele úvěrových produktů a sluţeb. Prostřednictvím svých poboček a sítě obchodních partnerů nabízí klientům: klasické spotřebitelské úvěry v prodejnách obchodních partnerů účelové a neúčelové osobní půjčky kreditní karty produkty určené k financování motorových vozidel různé typy pojištění Jak jiţ bylo konstatováno v úvodu, společnost CETELEM ČR, a.s. vnímá zpřístupnění vybraných sluţeb, které jsou doposud poskytovány výhradně prostřednictvím klasického stolního počítače, jako příleţitost pro tvorbu nového obchodního kanálu. Ten by měl být k dispozici jak stávajícím klientům, tak novým potencionálním zájemcům o sluţby společnosti. Vzhledem k tomu, ţe společnost podniká ve vysoce konkurenčním prostředí jako je poskytování spotřebitelských úvěrů, tak je také nutné věnovat patřičnou pozornost aktivitám konkurence. Lze konstatovat, ţe společnosti obdobného typu jiţ mají nebo se chystají poskytnout aplikace podobného typu. Jako příklad lze uvést mobilní aplikaci společnosti GE Money 21, která umoţňuje přístup k hlavním bankovním sluţbám. 5.2 Popis výchozího stavu Jako první krok bylo provedeno vyhodnocení přístupu na dva hlavní weby společnosti, a to: firemní web, který poskytuje ucelené informace o sluţbách a produktech produktový web zaměřený na jeden z hlavních produktů společnosti- revolvingovou kartu Statistika přístupů byla provedena pro dva typy segmentů: 21 Aplikace je dostupná na adrese 40

41 Operační systémy: tedy z prostředí stolního počítače. Zde se projevila jasná dominance systému Windows ve všech jeho klonech. Detail této statistiky je uveden v příloze. Mobilní zařízení: tedy z přenosných zařízení, detail je na níţe uvedeném obrázku Graf č. 6 Statistika přístupů na hlavní weby společnosti Zdroj: Autor Jedná se o výstup z programu Google Analytics 22 za období od 1/2011 do 10/2011, kde je vidět na prvních třech místech skupinu zařízení na bázi platforem Android/ SymbianOS /IPhone. Je zřejmé, ţe klienti (ať stávající či potencionální) pro přístup na tyto stránky pouţívají také přenosná zařízení. Počet přístupů z těchto zařízení v této chvíli sice představuje jedno procento z celkového počtu, ale je nutné si uvědomit, ţe oba tyto weby nejsou optimalizovány pro přístup z těchto zařízení. Zobrazení na těchto zařízeních tedy zdaleka není optimální. Podobně jako tradiční www stránky se předpokládá prakticky časově neomezený přístup k mobilním aplikacím, coţ by opět mohl být vhodný doplněk k poskytovaným sluţbám na klasických kamenných pobočkách. 22 Google Analytics (GA) je statistický program běţící na serverech společnosti Google, který uţivatelům umoţňuje dát si do vlastních stránek měřící kódy, které lze za pomoci tohoto programu poté vyhodnocovat. 41

42 5.3 SWOT analýza tvorby mobilních aplikací V níţe uvedené tabulce jsou silné a slabé stránky pro vytvoření souboru mobilních aplikací a dále pak hrozby a příleţitosti vyplývající z implementace mobilních sluţeb. SWOT analýza byla vybrána jako vhodný nástroj pro následnou definici výběrových kritérií, která bude nutné při výběru vhodného řešení dodrţet. Silné stránky - Stabilní produktové portfolio - Vhodnost klientského portfolia pro tento typ mobilních sluţeb - Informační systém společnosti umoţňuje snadný přístup k informacím pro budoucí mobilní aplikaci SWOT Interní faktory vnitřní prostředí - Dostatečná interní kapacita vývojového týmu Externí faktory vnější prostředí Příležitosti Slabé stránky - Zkušenost s technologiemi v dané oblasti - Řešení bezpečnosti v tomto způsobu komunikace - Robustnost navrhovaného řešení Hrozby - Zpřístupnění sluţeb stávajícím klientům novým komunikačním kanálem - Lepší cílení produktů na konkrétního zákazníka - Inovativnost - Zlepšení povědomosti o společnosti - Rostoucí počet konkurenčních řešení při mobilním poskytování úvěrových produktů - Měnící se technologie-nutnost neustále sledovat dění v této oblasti - Legislativní omezení Tabulka č. 5 SWOT analýza příleţitosti tvorby mobilních aplikací Zdroj: Autor Analýza jako taková byla vytvořena z pohledu budoucího řešitele, tj. jedná se pohled zevnitř společnosti. 42

43 5.4 Vyhodnocení SWOT analýzy a definice kritérií Na základě vyhodnocení SWOT analýzy a poznatků získaných v rámci přehledu potencionálních sluţeb společnost CETELEM ČR, a.s. stanovila tyto poţadavky, které musí být navrhované řešení splňovat. 1. Z pohledu stávajících klientů: zaměřit se na oblast kreditních karet a osobních půjček. Tyto oblasti nabízí nejvíce moţností vyuţití a zároveň jej lze okamţitě nabídnout stávajícím klientům. 2. Z pohledu nových klientů: připravit úvěrový kalkulátor tak, aby umoţnil simulaci výpočtu výše úvěru. Téţ připravit konsolidační kalkulátor pro klienty, kteří uvaţují o sloučení více půjček do jedné konsolidace spotřebitelských úvěrů. 3. Nabídnout sluţby, ve kterých je spojitost mezi klienty společnosti a obchodními partnery 23, např. vyhledání nejbliţšího prodejce na mapě 4. Vlastní realizaci provést za pomoci interních vývojových kapacit a znalostí, tj. neimplementovat externí řešení. Hlavním důvodem je zejména bezpečnost řešení a sdílení know-how v oblasti poskytování a rozhodování o schválení úvěrů. 5. Odezva aplikace musí být srovnatelná nejenom s konkurenčními řešeními v dané oblasti, ale i s podobnými portály, např. m.idnes.cz, m.ihned.cz atd. 6. Ekonomické parametry návrhu: a. Čas implementace nesmí přesáhnout 10 měsíců b. Na celý projekt můţe být alokováno max. 8 lidí, preferovaná varianta je z interních zdrojů společnosti c. Celková cena řešení nesmí přesáhnout 2 miliony Kč. Z výše uvedeného vyplývá, ţe se jedná o funkční (kalkulátor, vyhledávač) a nefunkční (robustnost, odezva aplikace) poţadavky. Jejich rozdělení stačí sice provést aţ při analýze vlastního řešení, ale je třeba na ně pamatovat jiţ při návrhu výběrových kritérií. 23 Obchodním partnerem se rozumí smluvní prodejce společnosti, který nabízí a prodává její úvěrové produkty 43

44 6 VÝBĚR TECHNICKÉHO ŘEŠENÍ 6.1 Zadání problému Výběr technického řešení je pro tvorbu takovéto aplikace zcela zásadní. Je nutné si uvědomit, ţe ve fázi případné realizace jiţ nelze způsob řešení změnit, protoţe tím by se zcela změnily podmínky, za kterých bylo učiněno rozhodnutí realizovat tvorbu této aplikace. V kapitole č.3 Technické řešení mobilních aplikací byly popsány tyto moţné způsoby řešení: 1. Vývoj pro prohlíţeč (browser) 2. Nativní vývoj aplikace (native) 3. Vývoj na bázi WAP (wap) Cílem je tedy porovnat tyto způsoby řešení a jeden z výše uvedených doporučit k realizaci. Výběrová kritéria jsou navrţena následovně: 1. Odhad úsilí, které bude třeba vyvinout při tvorbě základu mobilního portálu 2. Odhad úsilí, které bude třeba vyvinout při tvorbě kalkulátoru úvěru 3. Odhad úsilí, které bude třeba vyvinout při tvorbě transakcí v oblasti platebních karet 4. Ostatní funkcionality, např. vyhledávač prodejců 5. Robustnost řešení v kontextu celého informačního systému společnosti 6. Odhad celkového času 7. Alokace lidských zdrojů 8. Náklady na řešení 44

45 6.2 Metodika pro výběr řešení Sestrojení normalizované matice - V řádcích budou tři moţná řešení, ve sloupcích výběrová kritéria - Zvolená kritéria v kombinaci se způsoby budou obodována - Hodnoty v matici budou upraveny do jednotného formátu tak, aby se dal zjistit uţitek jednotlivých scénářů Odhad vah kritérií metodou Fullerova trojúhelníku - Kritéria budou vzájemně porovnána a tím budou získány jednotlivé váhy. Některá kritéria jsou tzv. dominantní a zvolené řešení je musí splňovat, jiná budou maximalizační nebo minimalizační (např. délka trvání implementace) Vícekriteriální hodnocení variant metodou váţeného součtu - Cílem je kvantitativním způsobem vyjádřit uţitek jednotlivých způsobů řešení - Celkový uţitek kaţdého řešení se spočítá jako váţený součet dílčích uţitků jednotlivých kritérií - Ve výsledné matici bude nový sloupec, ve kterém bude vyjádřen uţitek jednotlivých scénářů. Seřazení a výběr řešení - Matice je počítána jako maximalizační, tedy řešení s nejvyšší hodnotou bude doporučeno k realizaci Vlastní výpočet byl proveden (dle matematických postupů popsaných v teoretické části) ta pomoci MS Excel. Hodnoty, které jsou uvedené v tabulkách, jsou výsledkem několika iterací celého rozhodovacího procesu. Hlavním důvodem bylo zejména ověření citlivosti preferenčního uspořádání při změně vah a hodnot některých kritérií, jejichţ hodnota musela být víceméně odhadnuta. 6.3 Sestrojení normalizované matice Kritériím 1-5 jsou přiděleny a následně sečteny body v rozsahu od 1 do 5. Toto značí, jaké úsilí se bude muset věnovat návrhu, vývoji a implementaci dané oblasti při zvoleném způsobu řešení. Menší hodnota znamená mnoho úsilí, protoţe daná funkcionalita můţe v rámci tohoto řešení komplikovaná. V tomto případě se jedná o maximalizační kritérium. Platí tedy, ţe čím je hodnota vyšší, tím je to pro hodnocenou variantu lepší. Minimalizační kritéria jsou odhad 45

46 Mobilní portálzáklad Kalkulátor úvěru Podpora karetních operací Ostatní funkce Robustno st řešení Čas implemen tace Lidé Cena Mobilní portálzáklad Kalkuláto r úvěru Podpora karetních operací Ostatní funkce Robustn ost řešení Čas impleme ntace Lidské zdroje Cena času implementace, který je uveden v měsících, lidé jsou v počtu a cena je ve statisících korun Řešení/Kritérium Vývoj pro prohlížeč (browser) Nativní vývoj aplikace (native) Vývoj na bázi WAP(wap) Tabulka č. 6 Sestrojení normalizované matice Zdroj: autor 6.4 Odhad vah kritérií metodou Fullerova trojúhelníku Fullerův trojúhelník umoţňuje porovnávat jednotlivá kritéria mezi sebou. V našem případě se jedná 8 kritérii. Kaţdá dvojice se při porovnání vyskytuje právě jednou. Důleţitější kritérium se viditelně označí. V případě, ţe jsou obě kritéria stejně důleţitá, označí se obě. f1 f2 f3 f4 f5 f6 f7 f8 Řešení/Kriterium Mobilní portál-základ f1/f2 f1/f3 f1/f4 f1/f5 f1/f6 f1/f7 f1/f8 Kalkulátor úvěru f2/f3 f2/f4 f2/f5 f2/f6 f2/f7 f2/f8 Podpora karetních operací f3/f4 f3/f5 f3/f6 f3/f7 f3/f8 Ostatní funkce f4/f5 f4/f6 f4/f7 f4/f8 Robustnost řešení f5/f6 f5/f7 f5/f8 Čas implementace f6/f7 f6/f8 Lidé f7/f8 Cena Tabulka č. 7 Odhad vah kritérií metodou Fullerova trojúhelníku Zdroj: Autor Takto označená kritéria jsou obodována podle počtu výskytů. Pokud je kritérium preferováno, tak dostane přidělen 1 bod. V případě stejné důleţitosti s druhým kritériem 0,5 bodu. Poté je proveden součet všech bodů a tímto výsledkem vydělen počet jednotlivých bodů kritérií. Pro stanovení vah jednotlivých kritérií je dále zapotřebí určit jejich typ, tj. zdali jsou maximalizační nebo minimalizační. To je uvedeno ve druhém řádku s názvem max/min= 1/0. Je zřejmé, ţe v zájmu kaţdého projektu je spotřebovat co nejméně lidských zdrojů a minimalizovat čas nutný k realizaci. 46

47 Mobilní portálzáklad Kalkulátor úvěru Podpora karetních operací Ostatní funkce Robustnost řešení Čas implementace Lidské zdroje Overall Benefit of scenario Celkový užitek řešení Mobilní portálzáklad Kalkuláto r úvěru Podpora karetních operací Ostatní funkce Robustn ost řešení Čas impleme ntace Lidské zdroje Cena Kritérium max/min = 1/ Váha kritéria 0,1944 0,0556 0,0903 0,155 0,1544 0,124 0,1506 0,0757 Tabulka č. 8 Váhy výběrových kritérií Zdroj: autor Z výše uvedené tabulky vyplývá, ţe důleţitými kritérii pro výběr řešení je tvorba základu mobilního portálu a ostatní funkcionalita spolu s robustností celkového řešení, za nimi přibliţně na stejné úrovni alokace lidských zdrojů pro realizaci. 6.5 Vícekriteriální hodnocení variant metodou váţeného součtu WSA Metoda váţeného součtu je zaloţena na konstrukci lineární funkce uţitku v rozmezí od 0 do 1. Tyto hodnoty představují krajní uţitky variant v rámci jednotlivých kritérií. 0 přestavuje nejniţší uţitek, naopak hodnota 1 nejvyšší. Celkový uţitek kaţdého řešení se vypočítá jako váţený součet dílčích uţitků jednotlivých řešení Řešení/Kritérium Vývoj pro prohlížeč (browser) 0,1944 0,0556 0,0602 0,1033 0,1544 0,062 0,0505 0,1054 0,7858 Nativní vývoj aplikace (native) 0,0972 0,0278 0,0903 0,155 0, ,4732 Vývoj na bázi WAP(wap) ,124 0,0757 0,1506 0,3503 max/min = 1/ Váha kritéria 0,1786 0,0536 0,0536 0,0536 0,1786 0,1786 0,1427 0,1607 Tabulka č. 9 Celkové uţitky jednotlivých řešení Zdroj: autor 47

48 6.6 Seřazení a výběr řešení V následující tabulce jsou jednotlivá řešení seřazena sestupně podle svého klesajícího uţitku. Pořadové číslo určuje způsob řešení, který bude doporučen k realizaci. Pořadí Řešení/Kritérium uţitek řešení 1. Vývoj pro prohlíţeč (browser) 0, Nativní vývoj aplikace (native) 0, Vývoj na bázi WAP(wap) 0,3503 Tabulka č. 10 Seřazení a výběr řešení Zdroj: autor Dle zobrazeného pořadí je jasné, ţe největší uţitek řešení přináší vývoj pro prohlíţeč. To je dáno zejména kombinací faktorů: úsilí, které je nutné vyvinout při tvorbě základu mobilního portálu v kombinaci s robustností celkového řešení. Při hodnocení tohoto kritéria byl zohledněn fakt, ţe vytvoření jednoho univerzálního řešení pro prohlíţeč je v dané chvíli jednodušší neţ tvorba a údrţba několika nativních aplikací pro různé typy mobilních telefonů. Z pohledu zabezpečení lidských zdrojů při vývoji jasně zvítězil varianta pro prohlíţeč před nativní aplikací to je jednak důsledkem faktu, ţe společnost jako jedno z kritérií definovala vytvoření vlastními silami a zdroji, coţ v případě nativní aplikace nelze v současné době zajistit. Vývoj na bázi WAP řešení se umístil na třetím místě to je dáno zejména faktem, ţe v současné době jiţ tato technologie není schopna poskytnout na stejné prezentační úrovni všechny poţadované sluţby jako řešení pro prohlíţeč nebo nativní aplikace. Přesto byla brána do úvahy jako jedna z alternativ, protoţe byla zajímavá z pohledu lidských zdrojů (její realizace by byla pro pracovníky společnosti nejjednodušší) a ceny řešení. V této chvíli lze tedy učinit dílčí závěr, ţe celé řešení bude realizováno formou vývoje pro prohlíţeč. 48

49 7 ÚVODNÍ STUDIE 7.1 Odborný článek Cílem tohoto projektu je vytvoření souboru mobilních aplikací, které umoţní klientům přístup ke sluţbám za pomoci mobilních prostředků. Předpokládá se přístup jak stávajících klientů společnosti, tak nových zájemců o tyto sluţby. Celé řešení bude koncipováno jako portál na dedikované adrese m.cetelem.cz. Tento portál nebude ekvivalentem firemního webu ( ale bude naopak sdruţovat obsah, sluţby a odkazy na funkce vyvinuté na míru mobilním zařízením. Bude jakýmsi přístupovým bodem ke všem mobilním sluţbám poskytovaným společností CETELEM ČR, a.s. Okruhy k řešení jiţ byly definovány v rámci vyhodnocení SWOT analýzy tvorby mobilní aplikace, coţ nyní umoţňuje jejich rámcový popis jakoţto jednotlivých funkcí navrhovaného řešení. Klient po otevření úvodní stránky portálu bude mít k dispozici následující menu: 1. Úvodní stránka: obsahuje odkazy o Nás, kontakty, ochrana dat, reklamní banner 2. Kalkulátor osobní půjčky: bude obsahovat splátkovou kalkulačku zaměřenou na produkt osobní půjčka Kalkulátor konsolidací: bude obsahovat combi kalkulátor optimalizovaný pro slučování více půjček do jedné 4. Společné funkce pro kalkulátory: v mobilním zařízení musí být umoţněn komfortní a dobře ovladatelný výpočet podporující úpravy základních parametrů (výše půjčky, výše měsíčních splátek, délka splácení). Jakékoliv další sloţitější operace budou směřovány do plnohodnotné kalkulačky umístěné na firemním webu Zavolat si o půjčku: aktivuje telefonní aplikaci 25 daného zařízení a nabídne předvyplněné telefonní číslo xxx xxx xxx 24 Produktů společnosti CETELEM ČR,a.s., který klientovi umoţňuje pořízení účelové půjčky 49

50 Dokončit online: aktivuje nové okno mobilního prohlíţeče směřované na firemní web a otevře stránku s kalkulačkou a naplní ji vstupními informacemi z mobilní simulace Přeposlat ţádost: Aktivuje ovou aplikaci daného zařízení s nevyplněnou ovou adresou, kam můţe uţivatel napsat libovolnou adresu, včetně své vlastní. V těle u bude vygenerován text, souhrn parametrů, výsledku dotazu a odkaz na adresu, který kliknutím přenese uţivatele na plnohodnotnou kalkulačku kde budou vyplněny zadané vstupní parametry. Kontaktujte mne: Aktivuje kontaktní formulář, který odešle informace typu jméno, příjmení, a vypočtené informace z výpočtu osobní půjčky. 5. Kreditní karta: Kaţdá jednotlivá transakce v této části se bude ověřovat specifickým heslem, kódem či privátní informací. Podporovány musejí být tyto transakce: -disponibilní zůstatek - transakční historie karty - zaslání peněz na účet - blokace karty - platba Virtuální kartou - obnova PINu kreditní karty 6. Vyhledávač prodejců: umoţní klientovi najít nejbliţší obchod, kde jsou poskytovány sluţby společnosti CETELEM ČR, a.s. Dále musí být umoţněna správa a publikace obsahu s vyuţitím stávajícího CMS 26 a s příslušnou technologickou podporou - logika identifikace cílových zařízení a platforem, podpora pro variantní aplikaci šablon a stylů dle těchto zařízení a mapování vzhledu dle zařízení a rozlišení. Dále pak obecné publikační moţnosti a příprava vzhledů a stylů pro podporovaná zařízení. Očekává se i podpora pro jednoduchý banner management. V rámci výběru technického řešení, které bylo provedeno v kapitole 6, byl zvolen způsob realizace formou vývoje pro prohlíţeč. V teoretické části práce bylo provedeno zmapování 25 Některá zařízení zobrazují potvrzovací dialog, jiná přenášejí uţivatele do volby telefonního čísla, kde toto číslo bude předvyplněné. Tuto funkci nelze ovlivnit, protoţe se jedná o systémovou záleţitost a je závislá na konkrétním zařízení. 26 Containt Management Systém slouţí pro správu obsahu webových stránek bez znalostí programování 50

51 nejčastěji pouţívaných mobilních zařízení včetně trendů jejich vyuţití do budoucna. Tyto znalosti nyní umoţňují specifikovat podporovaná zařízení a zobrazovací schopnosti mobilního frameworku vůči těmto zařízením. Podporované platformy budou rozděleny do tří skupin, kdy skupina A umoţní nejlepší zobrazení a skupina C základní zobrazení. Vzhledem k designu stránek budou pouţity některé elementy CSS verze 3, které nemusí některé zařízení ze seznamu A podporovat. V praxi to bude znamenat, ţe návštěvník těchto stránek, který má zařízení nepodporující nové funkce CSS3, uvidí design nepatrně jinak (například kulaté rohy budou hranaté, nesystémový font Helvetica bude nahrazen systémovým Arialem atp.). Tato skutečnost neovlivňuje samotnou A B C podporu, jen vizuální záţitek z prohlíţení webu. Seznam podporovaných zařízení dle výše navrhovaného členění je uveden v příloze. 51

52 8 ANALÝZA A NÁVRH ŘEŠENÍ 8.1 Zvolený postup pro provedení analýzy pomocí jazyka UML Protoţe jazyk UML není metodika, ale pouze notace zápisu, existuje mnoho způsobů, jak postupovat při samotné analýze. Při návrhu tohoto řešení byl zvolen následující postup: 1. Odborný článek, studium uţivatelských poţadavků, interview se zadavatelem. Zaloţení úloţiště pro EA model Vytvoření katalogu uţivatelských poţadavků, validace, kategorizace poţadavků (funkční a nefunkční). 3. Propojení uţivatelských poţadavků (na základě katalogu) s jednotlivými případy uţití, definice aktorů systému a jejich následná validace zadavatelem 4. Návrh uţivatelského rozhraní v kombinaci s případy uţití 5. Odhad nákladů pomocí Karnenovy metody 8.2 Katalog poţadavků Katalog poţadavků na tvorbu souboru mobilních aplikací byl vytvořen na základě odborného článku. Struktura katalogu poţadavků je rozčleněna na logické části, které de facto představují jiţ základní UC-případy uţití. Poţadavky jsou dále rozděleny na funkční (FP) a nefunkční poţadavky (NFP). FP: Funkční poţadavky FP1:Základ portálu P.1.1 identifikovat cílové zařízení a podle toho optimalizovat stránku P.1.2 vygenerovat hlavní stránku, tzv. homepage a sestavit úvodní menu(dále statické stránky o nás, kontakty, ochrana dat P.1.3 načíst obsah vytvořený DMS systémem P.1.4 algoritmus detekce pro přesměrování na mobilní vs. plnou verzi webu FP2.Kalkulátor-osobní půjčka P.2.1 sestavení úvodní info stránky o osobní půjčce 27 UML modelování je provedeno pomocí nástroje Enterprise Architect 7.5 od firmy Sparx System 52

53 P.2.2 výpočet osobní půjčky, zobrazeni účelu úvěru, výše úvěru a délky splácení P.2.3 zobrazení výsledku simulace a moţnost změnit parametry P.2.4 podpůrné funkce kalkulátorů: umoţní dokončení simulace tím, ţe nabídne tyto moţnosti dokončení ţádosti: telefonické dokončení, přechod na formulář na přeposlání výsledku simulace na libovolnou ovou adresu, volba kontaktujte mě formou vyplnění kontaktního formuláře FP3.Kalkulátor-konsolidace P.3.1 sestavení úvodní info stránky o konsolidaci P.3.2 výpočet konsolidace formu kombi kalkulačky, zobrazeni hodnot zbývá k doplacení, měsíčně splácíte, nové prostředky,účel nových prostředků a délku splácení P.3.3 zobrazení výsledku simulace a moţnost změnit parametry P.3.4 podpůrné funkce kalkulátorů: umoţní dokončení simulace tím, ţe nabídne tyto moţnosti jak dokončit ţádost: telefonické dokončení, přechod na formulář na přeposlání výsledku simulace do libovolného mailu, volba kontaktujte mě formou vyplnění kontaktního formuláře FP4 Kreditní karta P.4.1 sestavení úvodní info stránky s informacemi o kreditní kartě P.4.2 algoritmus umoţňující ověření vybraných transakcí pomocí sms zprávy P.4.3 provádět tyto transakce: -disponibilní zůstatek - transakční historie karty - zaslání peněz na účet - blokace karty - platba Virtuální kartou - obnova PINu kreditní karty FP5. Vyhledávač prodejců P5.1 formou vrstvy přes google maps zobrazit adresy nejbliţších obchodních partnerů Cetelem. P5.2 informace o adresách partnerů načítat z datového interfejsu, vyuţít geolokaci mobilního telefonu FP6.Publikace obsahu P6.1 vytvoření a propagování obsahu FP7.Datový interface P.7.1 Vytvoření rozhraní pro vstup dat z informačního systému do základu portálu 53

54 NFP: Nefunkční poţadavky NFP1: Platforma a Architektura NFP.1.1 základ portálu: CMS LARS VIVO 28 NFP.1.2 zdroj informací: Databáze Oracle 11g NFP.1.3 Framework m.jquery pro určení typu mobilního zařízení 29 NFP2: Výkonnostní a datové požadavky NFP.2.1 Obsah přenášených dat v rámci jedné stránky se musí pohybovat v rozpětí 300kB-500kB NFP.2.2 Přechod a načtení jednotlivých stránek nesmí přesáhnou 5 sekund NFP3: Ostatní NFP.3.1 Deduplikace předávaných informací: totoţné informace nahrané z informačního systému nesmějí být znovu v rámci řešení ukládány NFP.3.2 Aplikace musí být dimenzovaná na paralelní přístup cca 100 zařízení Tabulka č. 11 Katalog poţadavků Zdroj: Autor 28 Contain Management Systém společnosti Lundegaard, informace jsou dostupné na 29 Aktuální seznam podporovaných zařízení je na adrese: 54

55 8.3 Vazba uţivatelských poţadavků na případy uţití V tomto kroku je provedeno propojení jednotlivých uţivatelských poţadavků s případy uţití. Cílem je zajistit, aby ţádný poţadavek nezůstal nerealizován. Obrázek č.3 Vazba uţivatelských poţadavků na případy uţití Zdroj: autor 8.4 Diagram případů uţití Diagram případů uţití znázorňuje vztah mezi uţivateli systému a jednotlivými případy uţití. Zároveň je provedena dekompozice případů uţití do jednotlivých částí budovaného systému. Při návrhu informačního systému lze případy uţití také vyuţít v následujících oblastech: 55

56 Tvorbu testovacích scénářů a dokumentace Řízení projektu na základě případů uţití ve vazbě na vhodnou projektovou metodiku 30 Pro stanovení odhadu pracnosti je diagram případů uţití důleţitý pří výpočtu nevyrovnané části UCP, kde pomůţe určit jak počet actorů v jednotlivých UC, tak i rozsah a sloţitost kaţdého takového případu uţití. Obrázek č.4 Diagram případů uţití Zdroj: Autor 30 Např. metodika Select Perspective, která se vyuţívá při iterativním vývoji za pomoci případů uţití 56

57 8.5 Návrh hlavní stránky mobilní aplikace Jiţ v této fázi návrhu je vhodné vytvořit návrh obrazovek budoucí aplikace a provázat je s jednotlivými případy uţití. Jednak je tím jasně znázorněno, ţe kaţdý případ uţití realizuje některou část budoucí aplikace a dále pak je výrazně usnadněna komunikace se zadavatelem, který získá konkrétní představu o navrhovaném rozhraní. Obrázek č.5 Návrh hlavní stránky mobilní aplikace Zdroj: Autor Na základě tohoto návrhu je jiţ moţné připravit jednoduché grafické návrhy, tzv. wireframes. Níţe je zobrazen návrh hlavní stránky, zbývající návrhy jsou v příloze. Obrázek č. 6 Grafický návrh hlavní stránky mobilní aplikace Zdroj: Autor 57

58 9 ODHAD NÁKLADŮ, ČASOVÉHO PLÁNU A BEZPEČNOST ŘEŠENÍ 9.1 Odhad nákladů na realizační fázi za pomoci Karnerovy metody Popis a význam hodnot byl jiţ popsán v kapitole 4.5, níţe jsou uvedeny jiţ konkrétní výpočty hodnot. Pro vlastní výpočet byl pouţit excelový kalkulátor, který je dostupný na webových stránkách společnosti Komix 31. Neupravený UCP Přidělení vah aktorům Actor Type Weighting Factor Number of Actors Total Simple (machine with API) Average (human) Complex (human with GUI) Total uaw 6 Tabulka č. 12 Karnerova metoda odhadu nákladů přidělení vah aktorům Zdroj: Komix a autor Přidělení vah případům uţití Weighting Use Case Type Number of transactions per UC Factor Number of use case Total Simple < Average 4 to Complex > Total uuaw 75 Tabulka č. 13 Karnerova metoda odhadu nákladů přidělení vah případům uţití Zdroj: Komix a autor Výpočet nevyrovnané části UCP je proveden jako součet dvou výše uvedených vah, tj. uucp= jaw + uuvw, celkem tedy uucp= 81 Technický faktor Technical Factors Weight Factor (0-5) Distributed Systém No influence Response adjectives Average influence End-user efficiency Strong influence Complex processing Reusable code Komix, 58

59 Easy to install 0,5 1 0,5 Easy to use 0,5 3 1,5 Portable Easy to change Concurrent Security features Access for third parties Special training required Technical complexity factor 0,93 Tabulka č. 14 Karnerova metoda odhadu nákladů technický faktor Zdroj: Komix a autor Faktor prostředí Environmental factors Factor (0-5) Familiar with RUP 1, No influence Application experience 0,5 3 1,5 3 Average influence Object-oriented experience Strong influence Lead analyst capability 0,5 4 2 Motivation Stable requirements Part time workers Difficult programming language ,5 Environmental factor 0,76 Tabulka č. 15 Karnerova metoda odhadu nákladů faktor prostředí Zdroj: Komix a autor Celkový počet UCP Pro získání vyrovnaného počtu UCP roznásobíme získané hodnoty z předchozích kroků, tj. UCP=UUCP*TCF*EF ->UCP= 57,25 Hodnota UCP představuje pracnost, v této chvíli jde však o bezrozměrné číslo. Obecně je doporučována hodnota 20 člověkohodin 32 na jeden UCP, v našem případě tedy: 57,25 x 20 = 1145,00 hodin. 32 Téţ závisí na zkušenosti z jiných projektů, ale hodnota by se měla pohybovat v rozmezí hodin na jeden UCP 59

60 9.1.1 Rekapitulace odhadu nákladů na realizaci systému Díky této metodě jsme relativně rychle schopni odhadnout náklady na vytvoření této nové funkcionality Náklady Počet pracovníků 3,5 Člověkodny 40,89 Člověkoměsíce 2,04 Počet prac.hodin/den 8 Člověkoden Kč Člověkohodina 875 Kč Počet prac dnů/měsíc 20 Měsíčně Kč Total Kč Tabulka č. 16 Rekapitulace odhadu nákladů na realizaci systému Zdroj: Autor Výše uvedený výpočet vychází z předpokladu, ţe na vytvoření systému bude vyčleněna plná kapacita jednoho analytika a dvou programátorů, poloviční kapacita je vyhrazena na testování. Cena za člověkoden je na spodní hranici, která je obvyklá u těchto typů profesí. Lze tedy konstatovat, ţe pokud na tvorbě souboru mobilních aplikací bude pracovat 3,5 člověka na plný úvazek, tak odhadovaná doba realizace jsou dva měsíce a za dílo společnost zaplatí cca jeden milion korun. 60

61 9.2 Časový plán projektu Nedílnou součástí návrhu je časový plán jednotlivých činností a fází projektu, který je zpracován formou časového plánu. Z něho je patrné, kdy jednotlivé činnosti začínají a kdy končí, které činnosti na které navazují a jaké se vzájemně překrývají. Takto připravený plán, při jehoţ návrhu bylo vyuţito všech předchozích znalostí a informací z návrhu a analýzy řešení, dává společnosti celkový obrázek o čase a činnostech nutných pro realizaci celého řešení. Číslo osnovy Název úkolu Doba trvání Zahájení Dokončení Předchůdci 1 Fáze1-Iniciace projektu 8 dny vypracování a odsouhlasení záměru 3 dny dokumentace projektu 5 dny klíčové role na projektu 1 den SS 1.4 definice formálních pravidel na projektu 1 den schválení projektu 0 dny Fáze2-plánování a návrh řešení 15 dny vlastní návrh řešení 15 dny rozpočet a detailní harmonogram 3 dny SS 4 schválení řešení 0 dny Fáze3-realizace řešení 50 dny Tvorba systému dle návrhu řešení 40 dny Testování 10 dny akceptace integračních testů 0 dny Fáze4-zavádění do provozu 17 dny Provozní (výkonnostní) testy 2 dny zkušební provoz 5 dny pilotní provoz 10 dny předání do provozu 0 dny Vyhodnocení a uzavření projektu 0 dny Tabulka č. 17 Harmonogram projektu Zdroj: Autor Harmonogram byl připraven v prostředí MS Project 2010 a znázorňuje úkoly nejvyšší úrovně spolu s dílčími kroky kaţdé etapy. Zvolené termíny zahájení a ukončení jsou pouze ilustrativní, ale doba trvání dílčích etap by se v případě posunu zahájení projektu nezměnila. 61

62 9.3 Rizika projektu Úspěch případného projektu tvorby mobilních aplikací můţe být do značné míry ovlivněn řadou faktorů a rizik, jejichţ identifikace a popis je vhodné provést jiţ ve fázi návrhu řešení. V průběhu návrhu byla identifikována tato případná rizika: Cíle projektu: soubor mobilních aplikací nemá ambice nahradit stávající www stránky společnosti. Na toto je nutné zadavatele výslovně upozornit Plánování jednotlivých činností: Věnovat patřičnou dobu testování celé aplikace, zejména důsledně vyhodnotit pilotní provoz. V případě nutnosti ještě rozdělit projekt na menší části a na ně pohlíţet jako na dílčí milníky v projektu Volba technického řešení: zvolené řešení formou pro prohlíţeč bylo vybráno jako vhodné řešení. Nelze od něho poţadovat funkcionality, které jednak nebyly poţadovány a které lze realizovat pouze v reţimu tvorby nativní aplikace (např. získávání specifických informací z mobilního zařízení a SIM karty ve vazbě na uţivatele) Odezva aplikace: je zřejmé, ţe aplikace musí z pohledu uţivatele poskytovat přiměřenou dobu odezvy. Vzhledem k tomu, ţe aplikace v průběhu jejího pouţívání komunikuje s informačním systémem společnosti, tak je nutné zohlednit jeho případnou momentální vytíţenost Uţivatelská přívětivost aplikace: nesnaţit se za kaţdou cenu o graficky perfektní vzhled, ale spíše preferovat funkčnost na jednotlivých mobilních zařízeních Bezpečnost řešení: po celou dobu tvorby aplikace je třeba mít na paměti, ţe do této aplikace je přistupováno z prostředí internetu a zároveň jsou získávána data z vnitřního systému. To klade zvýšené nároky nejen na vývoj a testování, ale i na provoz budoucí aplikace 62

63 9.4 Bezpečnost mobilních aplikací [6] S rozšiřováním funkčností chytrých telefonů (smartphones) a jejich stále většímu vyuţití pro přístup k aplikacím (zejm. finančního charakteru) z prostředí Internetu se mobilní aplikace dostávají do zorného úhlu profesionálních útočníků primárně zaměřených na zisk. Současně je z principu oslabena moţnost dvoukanálové autorizace transakcí či aktivit, neboť potvrzovací SMS zpráva směřuje na stejné zařízení, ze kterého byl zaslán poţadavek. Lze konstatovat, ţe problematice zabezpečení mobilních aplikací je a bude třeba v budoucnu věnovat větší pozornost neţ zabezpečení klasických webových aplikací Typologie útoků na mobilní aplikace Útok můţe být směřován v zásadě třemi směry: 1. Na samotné mobilní zařízení 2. Na síť přenášející data z/do mobilního zařízení 3. Serverovou část aplikace na straně poskytovatele takovéto sluţby V následující tabulce je uveden přehled nejčastějších způsobů Aktivum Telefon Prohlíţeč Aplikace Síť Web server Databáze Způsob útoku, charakteristika Baseband attacs, SMiShing Phishing,Framing,Man-in-the-Mobile,Data cacing Ukládání citlivých dat, nesprávné šifrování,ssl certifikáty-validace Podvodný Access Point,sniffing,Man-in-the-Middle,DNS poisoning Špatná konfigurace XSS, útoky hrubou silou SQL injection, eskalace práv, zneuţití příkazů OS Tabulka č. 18 Nejčastější způsoby útoků na mobilní aplikace Zdroj: Autor V kontextu těchto informací je nutné si uvědomit, ţe mobilní aplikace jsou ve většině případů softwarová díla na zakázku, takţe nejčastějším zdrojem chyb je programátor (lhostejno, zdali se jedná o zaměstnance či dodavatele). Tyto jedinečné chyby neodhalí ţádný automatizovaný nástroj pro testování zranitelností (tzv. vulnerability scanner) a proto je nutné provést řadu manuálních testů na tyto specifické slabiny. Celou řadu doporučení můţeme 63

64 nalézt na stránkách sdruţení OWASP 33 (The Open Web Application Security project), pro oblast mobilních zařízení je nově vydáván tzv. OWASP Top Ten Mobile Risks 34. [8] Nejvýznamnější rizika jsou uvedena v následujícím přehledu 1. Insecure Data Storage: nedůsledná ochrana uţivatelských dat, která v případě ztráty umoţňuje útočníkovi ovládnout mobilní zařízení 2. Weak Server Side Controls: nedostatečnou validací zaslaných dat na serverové straně jsou do aplikace/databáze uloţena nesmyslná nebo nepravdivá data 3. Insufficient Transport Layer Protection: Transportní vrstva protokolu TCP/IP je nedostatečně chráněna 4. Client Side Injection: na straně mobilního zařízení lze vloţit škodlivý kód za běhu aplikace 5. Poor Authorization and Authentication: nedostatečné mechanismy pro zajištění kontroly přístupu, hrozící ztráta autentizačních údajů-jména a hesla, certifikáty 6. Improper Session Handling: uloţené hodnoty v seancích (tzv.cookies) nejsou řádně ošetřeny, útočník můţe tuto slabinu vyuţít k nekorektnímu zacházení(podsouvání, unášení regulérních relací. 7. Security Decisions Via Untrusted Inputs: ochranné mechanismy aplikace zaloţené na hodnotách vstupů mohou být útočníkem upravena tak, aby šlo např. uţívat sluţby placené řádným uţivatelem nebo si eskalovat oprávnění 8. Side Channel Data Leakage: únik dat na přenosové cestě, nejčastěji chybnou implementací šifrovaného přenosového protokolu 9. Broken Cryptography: získání šifrovaných dat chybou např. slabé kryptografické funkce aplikace 10. Sensitive Information Disclosure: typicky ztráta zdrojového kódu aplikace Na základě znalostí těchto nejčastějších útoků a rizik jsme lépe schopni odhadnout a poté navrhnou způsob testování aplikace z bezpečnostního pohledu. 33 Informace o sdruţení jsou dostupné na adrese 34 Dostupný na adrese _Top_Ten_Mobile_Risks 64

65 9.4.2 Návrh bezpečnostních testů Cílem návrhu těchto testů je co moţná nejpřesněji určit reálnou zranitelnost aplikace vůči skutečným útokům, jinými slovy je potřeba co nejpřesněji aplikovat postupy potencionálního útočníka. Testování by mělo být provedeno v těchto fázích: 1. Testování bezpečnostního designu aplikace: zejména s ohledem na konkrétní chování na koncovém mobilním zařízení z pohledu získání, instalace, aktivace a autorizace aplikace vůči serveru. Prověřit mechanismy autentizace 35 a autorizace 36 a způsobu uloţení dat (pokud k němu dochází) na mobilním zařízení. Vlastní test provést ve dvou úrovních: Testování z anonymní úrovně: bez znalostí samotné aplikace, co nejvíce simulovat běţného uţivatele Testování se znalostí zdrojového kódu aplikace: podrobit zdrojový kód revizi a s touto znalostí postupně provádět test 2. Testování ochrany komunikace: prověřit komunikační a aplikační protokoly, certifikáty, práce s cookies atd. 3. Testování serverové části aplikace: Prověřit řízení přístupových práv, moţnost manipulace s formátem předávaných zpráv, ověření validace vstupů na serverové straně před jejich zpracováním a ověření odolnosti serverové části proti známým útokům typu SQL injection, data mining nebo útokům na session management. Závěrečné doporučení v oblasti bezpečnosti: vzhledem k tomu, ţe aplikace bude vyvíjena za pomoci vlastních kapacit společnosti CETELEM ČR, a.s., tak doporučuji provést testování za pomoci externích dodavatelů. Znalost zdrojového kódu a ostatních souvislostí běhu aplikace v kontextu s informačním systémem v zásadě znemoţňuje objektivní aplikace jako celku. 35 Autentizace-Ověření identity 36 Autorizace-ověření oprávnění 65

66 ZÁVĚRY A DOPORUČENÍ Cílem této práce bylo provést návrh tvorby mobilní aplikace tak, aby byly splněny podmínky, které společnost CETELEM ČR, a.s. předem definovala. Výchozí stav by se dal zhruba popsat následovně Pro klienty je potřeba vytvořit aplikaci pro mobilní telefony, aby naše služby nebyly dostupné pouze prostřednictvím stolních PC nebo limitovány otevírací dobou poboček. Z toho je zřejmé, ţe se jedná o poměrně široké zadání, které vyţadovalo systematický přístup k dané problematice. Nejdříve jsem provedl zmapování situace na trhu mobilních sluţeb a mobilního Internetu, včetně trendů ve vývoji mobilních zařízení. To umoţnilo zvolit spektrum sluţeb, které lze klientům nabídnout. Dílčím cílem bylo zmapování jak současného stavu, tak i sluţeb které budou moci být nabídnuty i v budoucnu. Protoţe jedním z hlavních cílů práce bylo provedení samotného návrhu aplikace, tak jako další logický krok bylo provedeno zpracování přehledu technických aspektů, které je třeba dodrţet při vlastním návrhu. Tím vznikli tři moţné způsoby, jak takovouto aplikaci vytvořit: Vývoj pro prohlíţeč (browser) Nativní vývoj aplikace (native) Vývoj na bázi WAP (wap) Vlastní návrh aplikace jsem provedl ve třech na sebe navazujících etapách: 1. Etapa výběru technického řešení ze třech variant Na základě provedené SWOT analýzy tvorby mobilní aplikace byly stanoveny poţadavky, které umoţnili nadefinovat výběrová kritéria. Protoţe výběr technického řešení je v rámci návrhu zcela klíčovou záleţitostí, tak vlastní výběr byl proveden pomocí jedné z metod multikriteriální analýzy: stanovení vah pomocí párového srovnání (tzv.fullerův trojúhelník) a následné vyhodnocení uţitku řešení za pomoci metody váţeného součtu-wsa. Výsledkem této etapy bylo rozhodnutí, ţe řešení bude provedeno formou vývoje pro prohlíţeč. 2. Analýza a návrh řešení na základě vybraného řešení 66

67 Cílem této etapy nebyl detailní návrh řešení, ale na základě odborného článku vytvořit popis základních funkcionalit navrhovaného systému tak, aby byly zohledněny všechny poţadavky, které má aplikace splňovat. Za pomoci modelovacího jazyka UML byl vytvořen základní přehled případů uţití (tzv. use case) a jejich provázání s funkčními poţadavky. Jiţ v této fázi jsem připravil návrh vzhledu základní stránky navrhované mobilní aplikace tak, aby společnost měla konkrétní představu o jejím budoucím vzhledu. 3. Ostatní aspekty návrhu Díky dekompozici návrhu řešení na jednotlivé případy uţití jsem vyuţil Karnerovu metodu odhadu nákladů, která mi pomohla jiţ v rané fázi návrhu provést odhad doby trvání a nákladů na realizační fázi. Protoţe společnost poţadovala odhad celkové doby trvání vytvoření mobilní aplikace, tak jsem provedl návrh plánu prací včetně přehledu potencionálních rizik. Zde doporučuji celý vývoj řídit jako samostatný projekt ve čtyřech na sebe navazujících etapách. Vzhledem k tomu, ţe celá aplikace má být provozována v prostředí internetu s přístupem do informačního systému společnosti, tak je zvláštní kapitola návrhu věnována bezpečnostním aspektům a testování aplikace. Jedním z klíčových poznatků při návrhu a tvorbě aplikace se ukázala důleţitost teoretických znalostí a metod. Jejich aplikace značně zprůhledňuje navrhované řešení a zároveň zkracuje nutnou dobu pro vytvoření návrhu jako takového. Rovněţ lze konstatovat, ţe poţadavky, které společnost CETELEM ČR, a.s. stanovila na tvorbu mobilní aplikaci, byly návrhem splněny. 67

68 SEZNAM POUŢITÉ LITERATURY Monografie [1] FOTR, J. a kol. Manažerské rozhodování postupy, metody, nástroje. Praha: Ekopress, ISBN [2] KANISOVÁ, Hana; MULLER, Miroslav. UML srozumitelně. 2.aktualizované vydání. Brno: Computer Press, ISBN [3] MURRAY, Andy. Managing Succesfull projects with Prince ISBN [4] KOPŘIVA, David. Jaké znáte metody odhadu nákladů na informační systém. Praha, Semestrální práce. BIVŠ. Elektronické zdroje: [5] MATURA, Jan. Česko, země věrná nokiím [online]. 2011, [cit ]. Dostupné z: < 0vs/mob_tech.aspx?c=A110811_134029_mob_tech_jm> [6] PINKAVA, Jaroslav. Bezpečnostní střípky: zajímavé výsledky na konferenci 27C3 [online]. 2011, [cit ]. Dostupné z:< [7] Material from Affiliates - Wireless Application Protocol. Open Mobile Alliance Ltd. [online] [cit ]. Dostupné z: < [8] The Open Web Application Security Project. OWASP [online] [cit ]. Dostupné z: < [9] Tisková zpráva: Využívání internetových služeb z mobilního telefonu rychle roste. SPIR Z.S.P.O. [online] [cit ]. Dostupné z: < < 68

69 SEZNAM OBRÁZKŮ Obrázek č. 1 Unified Modeling Language Obrázek č. 2 Prince2 - procedura řízení rizik Obrázek č. 3 Vazba uţivatelských poţadavků na případy uţití Obrázek č. 4 Diagram případů uţití Obrázek č. 5 Návrh hlavní stránky mobilní aplikace Obrázek č. 6 Grafický Návrh hlavní stránky mobilní aplikace SEZNAM TABULEK Tabulka č. 1 Výhody a nevýhody vývoje pro prohlíţeč Tabulka č. 2 Výhody a nevýhody vývoje nativní aplikace Tabulka č. 3 Výhody a nevýhody na bázi SMS/MMS řešení Tabulka č. 4. Uspořádání jednotlivých kvadrantů Swot analýzy Tabulka č. 5 SWOT analýza příleţitosti tvorby mobilních aplikací Tabulka č. 6 Sestrojení normalizované matice Tabulka č. 7 Odhad vah kritérií metodou Fullerova trojúhelníku Tabulka č. 8 Váhy výběrových kritérií Tabulka č. 9 Celkové uţitky jednotlivých řešení Tabulka č. 10 Seřazení a výběr řešení Tabulka č. 11 Katalog poţadavků Tabulka č. 12 Karnerova metoda odhadu nákladů přidělení vah aktorům Tabulka č. 13 Karnerova metoda odhadu nákladů přidělení vah případům uţití Tabulka č. 14 Karnerova metoda odhadu nákladů technický faktor Tabulka č. 15 Karnerova metoda odhadu nákladů faktor prostředí Tabulka č. 16 Rekapitulace odhadu nákladů na realizaci systému Tabulka č. 17 Harmonogram projektu Tabulka č. 18 Nejčastější způsoby útoků na mobilní aplikace 69

70 SEZNAM GRAFŮ Graf č. 1 Penetrace mobilních sluţeb v ČR Graf č. 2 Přístup na www stránky v ČŘ dle zařízení podle spol. GEMIUS SA Graf č. 3 Stahování J2ME aplikací uţivateli v Q3 Graf č. 4 Prodeje smartphonů v ČR za první pololetí 2011 Graf č. 5 Činnosti prováděné prostřednictvím jednotlivých mobilních zařízení Graf č. 6 Statistika přístupů na hlavní weby společnosti SEZNAM PŘÍLOH Příloha č. 1 Statistika přístupů na dle operačních systémů Příloha č. 2 Návrh obrazovek souboru mobilních aplikací Příloha č. 3 Seznam podporovaných mobilních zařízení 70

71 Příloha č. 1 Statistika přístupů na dle operačních systémů 1

72 Příloha č. 2 Návrh obrazovek souboru mobilních aplikací 1