Mobilní aplikace pro správu skladu. Bc. Martin Trněný

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Diplomová práce

Mobilní aplikace pro správu skladu Bc. Martin Trněný

Vedoucí práce: Ing. Ondřej Poláček

Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika 2. května 2011

iv

Poděkování Děkuji všem mým známým a přátelům, kterým jsem během vypracovávání této práce působil nepříjemnosti a potíţe. Také děkuji mému vedoucímu práce Ondřeji Poláčkovi za cenné rady a připomínky, za nespočetné mnoţství konzultací a za ochotu, kterou mi věnoval.

v

vi

Prohlášení Prohlašuji, ţe jsem práci vypracoval samostatně a pouţil jsem pouze podklady uvedené v přiloţeném seznamu. Nemám závaţný důvod proti uţití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 2.5.2011

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

vii

viii

Abstract Diploma thesis is devoted to analysis, design, implementation and testing mobile application for warehouse management. The application is developed on the basis of real requirements by private company. The result of the work to be analyzed on the basis of which made the system design and then it will come to pre-tested and implemented applications for warehouse management. The application consists of client and server parts.

Abstrakt Diplomová práce je zaměřena na analýzu, návrh, implementaci a testování mobilní aplikace pro správu skladu. Aplikace je vyvíjena na základě reálných poţadavků soukromé společnosti. Výsledkem práce má být provedená analýza, na základě které bude uskutečněn návrh systému a poté z něj vzejde implementovaná a otestovaná aplikace pro správu skladu. Aplikace se skládá z klientské a serverové části.

ix

x

Obsah 1

ÚVOD ............................................................................................................. - 1 1.1 Budoucnost mobilních zařízení a technologií .............................................. - 2 -

2

SOUČASNÁ ŘEŠENÍ .................................................................................... - 5 -

3

POPIS PROBLÉMU, SPECIFIKACE CÍLE .................................................. - 9 3.1 Popis tématu................................................................................................. - 9 3.1.1

Správa skladu ..................................................................................... - 10 -

3.1.2

Mobilní zařízení – čtečka čárových kódů ........................................... - 10 -

3.2 Projekt A_Terminal++ ................................................................................ - 10 3.2.1

Proč projekt vznikl ............................................................................. - 11 -

3.2.2

Čím se projekt zabývá ........................................................................ - 11 -

3.2.3

Očekávání od projektu........................................................................ - 12 -

3.3 Cílová skupina ........................................................................................... - 12 3.4 Obecné poţadavky na projekt .................................................................... - 13 3.5 Účel a cíl práce........................................................................................... - 13 4

ANALÝZA A NÁVRH ŘEŠENÍ ................................................................. - 15 4.1 Současný stav ve firmě Kovar.................................................................... - 16 4.1.1

Stav současných rolí ........................................................................... - 16 -

4.1.2

Současný proces příjmu a výdeje ....................................................... - 17 -

4.2 Budoucí stav ve firmě Kovar ..................................................................... - 17 4.2.1

Stav budoucích rolí............................................................................. - 18 -

4.2.2

Budoucí proces příjmu a výdeje ......................................................... - 18 -

4.3 User-Centered Design metodika a persona ................................................ - 19 4.3.1

Persona ............................................................................................... - 19 -

4.3.2

Skeletony............................................................................................ - 20 -

4.3.3

Tvorba persony ze skeletonů .............................................................. - 22 -

4.3.3.1 Persona Tomáš ............................................................................. - 23 4.4 Katalog poţadavků .................................................................................... - 25 4.4.1

Funkční poţadavky ............................................................................ - 25 -

4.4.1.1 Poţadavky na systém ................................................................... - 25 4.4.1.2 Poţadavky na část příjmu ............................................................ - 25 4.4.1.3 Poţadavky na část výdeje ............................................................ - 26 4.4.1.4 Poţadavky na část synchronizace ................................................ - 27 4.4.2

Nefunkční poţadavky......................................................................... - 27 -

xi

4.5 Návrh architektury ..................................................................................... - 27 4.5.1

Softwarová architektura ..................................................................... - 28 -

4.5.2

Architektura aplikace A_System++..................................................... - 29 -

4.5.2.1 Řešení tlustý klient ...................................................................... - 30 4.5.2.2 Řešení tenký klient ...................................................................... - 31 4.5.2.3 Řešení chytrý klient ..................................................................... - 33 4.5.2.4 Pouţité architekturní řešení ......................................................... - 34 4.6 Modelování aplikace.................................................................................. - 34 4.6.1

Případy uţití ....................................................................................... - 35 -

4.6.2

Diagramy aktivit ................................................................................ - 37 -

4.6.3

Datový model .................................................................................... - 41 -

4.7 Rozbor výběru klientského zařízení........................................................... - 42 5

IMPLEMENTACE ....................................................................................... - 44 5.1 Pouţité nástroje a technologie ................................................................... - 44 5.1.1

.NET platforma .................................................................................. - 44 -

5.1.2

.NET Compact Framework................................................................ - 45 -

5.1.3

Microsoft Sync Framework ............................................................... - 46 -

5.1.4

Visual Studio...................................................................................... - 49 -

5.1.5

Advantage Data Architect .................................................................. - 49 -

5.1.6

Programovací jazyk C# ...................................................................... - 50 -

5.1.7

Databáze ............................................................................................ - 50 -

5.2 Klientská část............................................................................................. - 52 5.2.1

Prezentační vrstva .............................................................................. - 53 -

5.2.2

Aplikační vrstva ................................................................................. - 53 -

5.2.3

Fyzická vrstva .................................................................................... - 55 -

5.3 Serverová část ............................................................................................ - 56 5.3.1

Prezentační vrstva .............................................................................. - 56 -

5.3.2

Aplikační vrstva ................................................................................. - 57 -

5.3.3

Fyzická vrstva .................................................................................... - 57 -

5.4 Synchronizace............................................................................................ - 58 5.5 Ukázka uţivatelského rozhraní .................................................................. - 61 6

TESTOVÁNÍ ................................................................................................ - 65 6.1 Testování kognitivním průchodem ............................................................ - 65 6.1.1

Nastavení testů ................................................................................... - 65 -

6.1.2

Průběh testů........................................................................................ - 66 -

xii

6.1.3

Vyhodnocení testů.............................................................................. - 68 -

6.2 Testy pouţitelnosti - plánování .................................................................. - 68 6.2.1

Účel testů............................................................................................ - 68 -

6.2.2

Cíle testů............................................................................................. - 69 -

6.2.3

Nastavení testů ................................................................................... - 69 -

6.2.3.1 Pouţité metody testování ............................................................. - 69 6.2.3.2 Průchod procesů aplikace testerem .............................................. - 70 6.2.3.3 Sbíraná data a jejich formát.......................................................... - 71 6.2.3.4 Technické prostředky pouţité při testování.................................. - 71 6.2.4

Testování uţivatelé ............................................................................. - 71 -

6.2.4.1 Pre-test dotazník........................................................................... - 72 6.2.5

Předpokládaný průběh testování......................................................... - 73 -

6.3 Testy pouţitelnosti - průběh testování........................................................ - 73 6.4 Zpracování nasbíraných dat ....................................................................... - 75 6.5 Vyhodnocení testování............................................................................... - 75 6.5.1

Průchod úkolů .................................................................................... - 76 -

6.5.1.1 Procházení mezi záloţkami.......................................................... - 76 6.5.1.2 Snímání čárového kódu ............................................................... - 77 6.5.1.3 Klávesnice a nepopsané textové pole ........................................... - 77 6.5.1.4 Tlačítka pro uloţení ..................................................................... - 77 6.5.1.5 Druhý úkol a neprojíté úlohy ....................................................... - 77 6.5.2

Post-test dotazník ............................................................................... - 78 -

6.6 Návrhy na zlepšení..................................................................................... - 79 6.6.1

Nedostatky beze změny...................................................................... - 80 -

6.6.2

Zredukování počtu záloţek ................................................................ - 80 -

6.6.3

Přemístění prvků na formuláři ............................................................ - 80 -

6.6.4

Zrychlení odezvy................................................................................ - 81 -

6.6.5

Mobilní zařízení ................................................................................. - 81 -

6.7 Shrnutí testování ........................................................................................ - 81 7

ZÁVĚR.......................................................................................................... - 83 7.1 Zhodnocení práce ....................................................................................... - 83 7.2 Další vývoj ................................................................................................. - 84 -

LITERATURA ....................................................................................................... - 85 A.

SEZNAM POUŢITÝCH ZKRATEK ........................................................... - 87 -

B.

DATOVÝ MODEL ....................................................................................... - 88 -

xiii

C.

INSTALACE ................................................................................................ - 89 -

D.

OBSAH PŘILOŢENÉHO CD ...................................................................... - 90 -

xiv

Seznam obrázků Obrázek 1-1 Globální vývoj ICT v průběhu minulých 11 let (1) .............................. - 2 Obrázek 4-1 Tomáš ................................................................................................. - 23 Obrázek 4-2 Klient - server ..................................................................................... - 30 Obrázek 4-3 Případ uţití - příjem zboţí .................................................................. - 36 Obrázek 4-4 Případ uţití - výdej zboţí.................................................................... - 36 Obrázek 4-5 Případ uţití - správa dat ...................................................................... - 37 Obrázek 4-6 Diagram aktivity - Uloţení přijaté zakázky ........................................ - 39 Obrázek 4-7 Diagram aktivity - Přijetí zakázky ...................................................... - 39 Obrázek 4-8 Diagram aktivity - Vydání zakázky .................................................... - 40 Obrázek 4-9 Diagram aktivity – Uloţení vydané zakázky...................................... - 41 Obrázek 4-10 Diagram aktivity – Spuštění systému ............................................... - 41 Obrázek 5-1 Struktura celého .NET frameworku (10) ............................................ - 45 Obrázek 5-2 .NET Compact Framework architektura platformy (11) .................... - 46 Obrázek 5-3 Ukázka moţných zařízení k synchronizování (12) ............................. - 47 Obrázek 5-4 Ukázka architektury komunikace při synchronizaci (12) ................... - 48 Obrázek 5-5 Zařízení pro snímání čárových kódů MC3090 (26) ........................... - 52 Obrázek 5-6 Pohled na architekturu synchronizace v aplikaci A_Terminal++ ........ - 58 Obrázek 5-8 Obrazovka příjmu – seznam přijatých poloţek .................................. - 61 Obrázek 5-7 Obrazovka po spuštění aplikace ......................................................... - 61 Obrázek 5-10 Formulář výdej - načtené údaje podle čárového kódu ...................... - 62 Obrázek 5-9 Formulář výdej - zádávání čárového kódu ......................................... - 62 Obrázek 5-12 Formulář příjem - validace na povinné pole ..................................... - 63 Obrázek 5-11 Formulář příjem - zadávání dodatečných údajů ............................... - 63 Obrázek 6-1 Ukázka nejasnosti při ukládání ........................................................... - 68 Obrázek 6-2 Odstranění přebytečných záloţek ....................................................... - 80 Obrázek B-1 Datový model .................................................................................... - 88 -

xv

xvi

Seznam tabulek Tabulka 3-1 Přehled výhod/nevýhod pouţití nového řešení ..................................... - 9 Tabulka 4-1 Tlustý klient porovnání výhod a nevýhod........................................... - 31 Tabulka 4-2 Tenký klient porovnání výhod a nevýhod........................................... - 32 Tabulka 4-3 Porovnání mobilních zařízení umoţňující snímání čárového kódu .... - 42 Tabulka 5-1 Ukázka práce s knihovnou Symbol..................................................... - 54 Tabulka 5-2 Ukázka klientské metody pro spuštění synchronizace ........................ - 60 Tabulka 6-1 Kognitivní průchod - Výdej zboţí - přidat poloţku ............................ - 66 Tabulka 6-2 Kognitivní průchod - Výdej zboţí - editace poloţky .......................... - 66 Tabulka 6-3 Kognitivní průchod - Výdej zboţí - smazání poloţky ........................ - 66 Tabulka 6-4 Kognitivní průchod - Příjem zboţí - přidat poloţku ........................... - 67 Tabulka 6-5 Kognitivní průchod - Příjem zboţí - editace poloţky ......................... - 67 Tabulka 6-6 Kognitivní průchod - Příjem zboţí - smazání poloţky........................ - 67 Tabulka 6-7 Ukázka průchodu procesu Příjem zboţí.............................................. - 70 Tabulka 6-8 Podrobný popis testovaných osob....................................................... - 71 Tabulka 6-9 Vyhodnocení pre-test dotazníku ......................................................... - 72 Tabulka 6-10 Vyhodnocení post-test dotazníku ...................................................... - 79 -

xvii

xviii

1 ÚVOD „Nejdříve je třeba se naučit tomu, o čem píšeš, potom je třeba se naučit psát. Na jedno i druhé padne celý život.“ Ernest Hemingway Husí brko, lahvička s inkoustem a pergamen slouţící jako papír, to je jiţ dávná minulost, kdy takto a podobně královští úředníci sepisovali královský majetek, aby král věděl, kolik ţe má v sýpce mouky, ve zbrojnici kuší a ve stájích koní. Princip soupisu majetku, zboţí, surovin atp., zůstává jiţ tisíciletí stále stejný, jen se mění technologie, pomocí kterých tento postup provádíme. A právě o technologiích umoţňující záznam, skladování a přenos těchto informacích bude pojednávat i tato práce. Co se přesně myslí pod pojmem technologie u správy skladu? Opět z hlediska historického se nedá mluvit o technologiích, ale spíše o postupech, metodách a pomůckách k tomu určených. Ve dřívějších dobách se pouţíval papír a psací potřeba, kdy osoba k tomu určená, prováděla soupis daných věcí a poté se záznam buď to dále zpracovával, nebo se provedla jeho archivace. Tyto postupy a pouţité pomůcky jiţ byly překonány a jsou nahrazovány výpočetní technikou, informačními systémy a v posledních letech zejména mobilními zařízeními. A i kdyţ základní principy zůstávají i nadále stále stejné tj. potřeba záznamu určité věci, poté zpracování daného záznamu a v neposlední řadě archivace záznamu, technika jakou se to provádí je propracovanější, sofistikovanější a zejména je efektivnější. Při přiblíţení výše uvedených skutečností se jiţ rýsuje samotná náplň této práce – mobilní aplikace pro správu skladu. Správou skladu v kontextu této práce je myšlena evidence zboţí při přijetí na sklad a vyskladnění, kdy data o evidenci zboţí se musí zanést do informačního systému, kde dochází k jejich zpracování a poté se tyto data opět vyuţívají při vyskladnění zboţí. Jak jiţ bylo uvedeno, v dnešní době se čím dál více začínají prosazovat mobilní zařízení i v této oblasti lidské činnosti a proto i tato práce je zaměřena na mobilní aplikaci, která běţí na mobilním zařízení.

-1-

1.1 Budoucnost mobilních zařízení a technologií Poměrně mladá oblast mobilních zařízení a technologií, získává neustále větší a větší uplatnění v různých oblastech lidské činnosti. Jiţ to není pouze hlasová či textová komunikace jako základní funkce, ale přidávají se i další moţnosti vyuţití díky neustálému rozvoji těchto a souvisejících technologií. V posledních letech se mobilní zařízení začínají rozšiřovat také do průmyslu a obchodu, kde výraznou měrou zefektivňují práci a právě díky tomu se staly významnou konkurenční výhodou pro ty, kteří s jejich zavedením, do svých procesů uvnitř společnosti, nečekaly. Náklady ušetřené zavedením mobilních zařízení a technologií se proto staly výraznou poloţkou a mají tak za následek rychle se rozrůstající počet společností vyuţívající mobilní zařízení a technologie. Mobilní zařízení jako i drtivá většina ostatních technických zařízení se neustále vyvíjejí a jejich potenciál ještě není vyčerpán. Úspora energie jako jeden z hlavních parametrů těchto zařízení se den ode dne zlepšuje, s úsporou energie samozřejmě souvisí baterie a displej. Baterie neustále zlepšují svou výdrţ při stejných ba dokonce i menších rozměrech a hmotnostech. Naopak displej získává čím dál větší rozměry při zachování nebo zvětšení rozlišení. Tyto a další zlepšující se parametry dávají mobilním zařízením výborný základ pro další rozšiřování. Global ICT developments, 2000-2010* 100 90

Per 100 inhabitants

80

Mobile cellular telephone subscriptions Internet users

70

Fixed telephone lines

60

Mobile broadband subscriptions

50 40

30 20 10 0

2000 2001 2002 2003 2004 2005 2006 *Estimates Source: ITU World Telecommunication/ICT Indicators database

2007

2008

Obrázek 1-1 Globální vývoj ICT v průběhu minulých 11 let (1)

-2-

2009

2010*

Dle Obrázek 1-1 a předchozích odstavců se dá říci, ţe mobilní zařízení a technologie s nimi spojené mají velkou perspektivu do budoucna a právě proto jsem si i já vybral téma související s těmito zařízeními a technologiemi.

-3-

-4-

2 SOUČASNÁ ŘEŠENÍ „Minulá práce nám může pomoci, avšak musíme žít z práce přítomné.“ George Bernard Shaw Mobilních aplikací dnes nalezneme statisíce moţná milióny díky rozšíření mobilních zařízení. Co se týče mobilních zařízení vyuţitých v průmyslu a aplikací pro ně, zde se setkáme s výrazně niţšími čísly. Projekt A_Terminal++ svým zaměřením na průmysl, lépe řečeno na zařízení umoţňující snímání čárových kódů okruh konkurenčních produktů velmi omezil. Bylo nalezeno několik softwarových řešení v rámci České republiky podobající se působností aplikaci A_Terminal++, ovšem nelze hovořit o přímých konkurentech, jednak z důvodu neznalosti přesných specifik konkurenčních produktů (tyto data nejsou od výrobců k dispozici) a za další z pohledu rozsáhlosti, poněvadţ aplikace A_Terminal+ se zaměřuje na konkrétní případ pouţití, kdeţto konkurence má širší pole záběru. Pro alespoň hrubou představu o dalších aplikacích pro zařízení umoţňující snímání čárových kódů pouţitých ve skladech uvádím následující přehled „podobných― řešení: CCV Řízený sklad Produkt CCV Řízený sklad od společnosti CCV Informační systémy. CCV Řízený sklad je rozsáhlé řešení pro řízení skladů (Warehouse Management Systems) zaloţené na Microsoft Dynamics NAV. Jeden systém tak v reálném čase umoţňuje komplexní správu provozu a dále zaznamenává a řídí všechny skladové operace. Základní vlastnosti řešení  Plná podpora pouţití radiofrekvenčních terminálů  Nástroje na správu logistických údajů a detekování jejich chyb  Optimalizační algoritmy naskladnění a expedice  On-line řízení skladových operací Další informace jsou dostupné v (1). Řízený sklad Accellos WMS Accellos WMS (Warehouse Management System, systém řízeného skladu) dodává na český a slovenský trh společnost Kodys.

-5-

Accellos WMS komplexně řeší automatizaci evidence procesů a zásob ve skladu. Accellos WMS umoţňuje automatickou správu skladového provozu napříč všemi skladovými procesy. Vyuţívá technologií automatické identifikace - čárových kódů, RFID, bezdrátových sítí a hlasového vychystávání. Accellos WMS pouţívá více neţ 600 firem po celém světě. Systém řízeného skladu ovlivňuje zejména následující skladové procesy:  Objednání, příjem a zaskladnění zboţí  Vychystání, zabalení a expedice zboţí  Inventarizace  Analýza dat o zásobě Další podporovaná funkcionalita – například práce s materiálem v průběhu jeho ţivota na skladě (přeskladnění, doplňování), tisk etiket ve všech fázích skladového procesu, práce se sadami. Více na stránkách produktu (2). Mobilní evidence majetku a skladových zásob Produkt společnosti PDA Trade. Software zajišťuje provedení fyzické inventury majetku v terénu pomocí čárového kódu. Umoţňuje zobrazit obsluze detailní informace o načteném majetku a zároveň řeší případnou změnu lokality. V softwaru je moţné zakládat nový majetek, je moţné provádět změny na kartě majetku a vyhledávat majetek ručně dle kódu nebo podřetězce názvu majetku. Software Mobilní evidence majetku a skladových zásob podobně jako A_Terminal++ vyuţívá mobilní zařízení od společnosti Motorola. Základní vlastnosti:  software pro mobilní platformu WinMobile 6.x , WinCe  určené pro odolné terminály firmy Motorola řady MC70, MC3000, MC90  software je připraven i pro větší datové objemy. Více o produktu v (3). MILSOFT – Skladník IS MILSOFT od společnosti Milsoft a její modul Skladník.

-6-

Po spuštění aplikace Skladník (uloţené na aplikačním serveru) z mobilního terminálu je moţné provádět tyto činnosti:  Pořizovat doklady (příjemky, výdejky) do skladové evidence vybraného expedičního skladu vedeného v modulu Zásobník.  Obsah dokladů je moţné zadávat ručně, anebo prostřednictvím snímání čárových

kódů

přepravních

jednotek

(kartonů,

palet).

Čárové kódy musí odpovídat normě EAN 128. Vytvoření a tisk etiket s čárovým kódem ve standardu EAN 128 je moţno zajistit pomocí programu MILSTIT, který je součástí IS MILSOFT.  Na základě objednávky zboţí od zákazníka, kterou obsluha zaznamená v modulu Odbyt je moţno na terminál přenést návrh výdejky. Na displeji terminálu se zobrazují výrobky z objednávky současně s objednaným mnoţstvím.  Pracovník je on-line informován o aktuální zásobě objednaných výrobků. Současně se zápisem výdejového dokladu se skutečnými výdeji do skladové evidence jsou tato data automaticky zapsána zpět do modulu Odbyt v podobě dodacího listu.  Tisk dokladu je umoţněn na libovolnou síťovou tiskárnu. Informace čerpány z (4). Ani jeden z výše uvedených produktů nemá uvedeny na svých webových stránkách podrobnější specifikace implementace či funkčnosti, takţe nelze uvaţovat o společném porovnání těchto produktů, slouţí tedy pouze jako ilustrace moţných podobných řešení.

-7-

-8-

3 POPIS PROBLÉMU, SPECIFIKACE CÍLE „Kdybych měl k dispozici hodinu na zvládnutí problému, na kterém by závisel můj život, strávil bych 40 minut jeho studiem, 15 minut jeho analýzou a 5 minut jeho řešením.“ Albert Einstein

3.1 Popis tématu Tématem práce je zaměření se na ucelený vývoj mobilní aplikace pro správu skladu. Součástí práce je realizace projektu A_Terminal++ popsaného blíţe v kapitole 3.2, na němţ je demonstrován vývoj mobilní aplikace od sběru poţadavků aţ po poskytnutí podpory zákazníkovi. Proč se vlastně vyvíjí zcela nový software a nepouţije se raději některé z jiţ existujících řešení popsaných ve druhé kapitole? Důvodů je hned několik a pro přehlednější porovnání výhod či nevýhod pouţití zcela nového řešení je uvedeno v následující tabulce Tabulka 3-1. Výhody lépe se splní poţadavky zákazníka aplikaci je moţno „ušít na míru―

integrace s ostatnímy systémy je snadnější

Nevýhody vývoj nového řešení zabere čas neznalost technologií pro vývoj mobilní aplikace výskyt „dětských nemocí― při prvním zavedení

pouţití nejnovějších technologií aplikaci je moţno sestavit jako modulární a dále ji tak jednoduše rozšiřovat rozšíření stávajících modulů dle zákazníka Tabulka 3-1 Přehled výhod/nevýhod pouţití nového řešení

Na základě jiţ uvedených skutečností, kdy současná řešení představují buď příliš komplexní, nebo naopak nedostatečnou funkcionalitu a kdy přínosy vývoje nového software předčí jeho nevýhody, je rozhodnutí se pro vývoj zcela nového software opodstatněné.

-9-

3.1.1 Správa skladu Pod tímto pojmem se skrývá vícero činností vykovávaných zejména skladníky. Skladník je osoba zodpovědná za správné vedení evidence v rámci přidělených skladů, eviduje příchozí a odchozí poloţky. V rámci procesu správy skladu rozlišujeme dva základní procesy, příjem a výdej. Příjmem poloţky na sklad rozumíme zvětšení mnoţství daného typu na daném skladě, jeţ je nutné zaevidovat. Přijímaná poloţka můţe pocházet z výroby či jiného skladu v rámci jedné společnosti nebo jako nakoupené zboţí (materiál) od dodavatele. Výdejem poloţky ze skladu rozumíme proces opačný k procesu příjmu poloţky na sklad. Při příjmu můţe nastat situace, kdy poloţka daného typu ještě v evidenci není a tak se musí zaloţit úplně nová a v neposlední řadě se v průběhu skladování mohou měnit parametry poloţek, jako je cena a podobně, takţe následuje úprava těchto hodnot v evidenci.

3.1.2 Mobilní zařízení – čtečka čárových kódů Mobilní zařízení jiţ není jen telefon ale také i další malá zařízení vyskytující se v různých podobách a na různých místech. Jedno z těchto zařízení je i čtečka čárových kódů slouţící k sejmutí čárového kódu z výrobku, zboţí či materiálu a jeho následné identifikaci. Tato zařízení se běţně vyskytují v obchodech u pokladen, kde je čárový kód sejmut kvůli identifikaci ceny zboţí. Zařízení mohou být

vybavena dotykovým displejem,

plnohodnotným operačním systémem i přístupem k internetu.

3.2 Projekt A_Terminal++ Téma práce je zaloţeno na realizaci projektu A_Terminal++, coţ je reálný projekt, který je určen pro společnost Kovar s.r.o, jeţ se zabývá výrobou a prodejem kontejnerů různých velikostí a druhů. Jako dodavatel tohoto projektu vystupuje společnost Miss Software spolupracující se společností Kovar řadu let, mimo jiné Miss Software spravuje ve společnosti Kovar svůj informační systém A_System++. Miss Software působí na českém ICT trhu od devadesátých let minulého století, je to malá softwarová firma poskytující své softwarové produkty a sluţby zákazníkům.

- 10 -

3.2.1 Proč projekt vznikl Společnosti Kovar se v posledních letech velmi dařilo a to zejména díky zavádění standardů v řízení a kontrole procesů probíhajících uvnitř společnosti. Úspěšně několikrát získaly peníze z fondů Evropské unie v rámci operačních programů pomáhajících v rozvoji společnosti a právě jeden z úspěšných projektů ţádajících o evropské dotace obsahoval bod o řízení skladových zásob, coţ bylo dále rozvedeno a popsáno jako zavedení čteček čárových kódů pro správu skladu neboli později představeno jako projekt A_Terminal++. Společnost Kovar při výrobě kontejnerů pouţívá mnoho dílů a součástek, které jsou umístěny v různých skladech v rozlehlém areálu firmy, ale je tu také samotný materiál a samozřejmě vznikající meziprodukty, které se také evidují a skladují. Všechny tyto poloţky se v současné době evidují prostřednictvím informačního systému (dále jen IS) A_System++, coţ ovšem přináší řadu nepříjemností, poněvadţ IS je nainstalován na stolních počítačích pouze na určitých místech v areálu firmy a například zaměstnanec pověřený evidencí nově příchozího materiálu skladujícího se ve venkovních prostorech musí absolvovat nesnadnou evidenci nejprve na místě uloţení a poté ještě zanést záznamy do IS na místě vybavené počítačem s jeho instalací. Tento zdlouhavý proces se denně několikrát opakuje a představuje tak pro společnost zbytečnou ztrátu času v podobě přecházení z místa na místo a dvojího zápisu údajů. Podobně neefektivně na tom můţe být zaměstnanec provádějící vyskladnění určitého zboţí, ten nejen ţe zbytečně několikrát zapisuje údaje a přemisťuje se mezi zboţím a počítačem, ale musí také znát aktuální cenu vyskladňovaného zboţí a mnoţství zboţí, které je na skladu k dispozici. Našly by se mnohé další neefektivní způsoby činnosti v současných procesech příjmu a výdeje. Úspěch firmy znamená být efektivní ve všech procesech vyskytujících se uvnitř společnosti a dále také v procesech působící na vnější vztahy. A právě v rámci zefektivnění procesů příjmu, výdeje a řízení zásob vznikl projekt A_Terminal++ odstraňující drtivou většinu nedostatků provázející současné činnosti v rámci zmiňovaných procesů.

3.2.2 Čím se projekt zabývá Projekt se sestává z několika fází a jako celek představuje mobilní aplikaci poskytující správu skladu a ulehčující řízení zásob. Jednotlivé fáze jsou následující: a) Analýza – vytváří základ pro správný návrh aplikace, patří sem zejména úvodní rozbor problému, sběr a specifikace poţadavků, modelování diagramů

- 11 -

b) Implementace – představuje samotný vývoj aplikace, ale provádí se zde také výběr frameworků, programovacích jazyků, databází a nástrojů pouţitých při implementaci c) Testování a nasazení aplikace – provádí se několik druhů testování, v rámci tohoto projektu je to především testovaní pouţitelnosti; po ukončení testování následuje instalace a konfigurace zařízení a aplikace u zákazníka d) Poskytnutí podpory – zajištění podpory obnáší neustálý monitoring aplikace a kontrolu funkčnosti zařízení Fáze shrnuty výše jsou jednotlivé části této práce. Kaţdá jednotlivá fáze bude podrobně rozebrána a vysvětlena.

3.2.3 Očekávání od projektu Mobilní aplikace má umoţnit zaměstnanci efektivnější a snadnější výkon své práce, coţ povede k větší výkonnosti zaměstnance. Důleţitý je především dopad na firmu jako celek, zde by se měl projevit nárůst výkonnosti zaměstnanců a efektivnější průběh procesů příjmu, výdeje a řízení zásob. Ve výsledku společnost ušetří nezanedbatelné mnoţství času, jeţ se spotřebuje na dalších zakázkách a povede tak k vylepšení finanční situace společnosti. Na zlepšení efektivnosti práce zaměstnance má vliv poskytnutí větší mobility zaměstnancům, a to v tom smyslu, ţe jiţ není nutné ruční zapisování údajů u stolních počítačů. Skladník při příjmu či výdeji má se sebou neustále terminál (čtečka čárových kódů), do níţ zapisuje potřebné údaje, těchto údajů je navíc mnohem méně, neţ zapisoval doposud, poněvadţ sejmutí čárového kódu z poloţky obecně znamená před vyplnění některých údajů z databáze uloţené na terminálu. Údaje uloţené v terminálu se poté prostřednictvím synchronizace přenesou a zapíší do centrální serverové databáze a tak skladník není nucen údaje jakkoliv zapisovat do IS.

3.3 Cílová skupina Cílovou skupinu uţivatelů vyuţívající terminál s mobilní aplikací lze vymezit na základě současných činností zaměstnanců a lze ji rozdělit do několika skupin. První a největší skupinou jsou skladníci, pro které je aplikace primárně určena. Vyuţijí veškerou funkcionalitu mobilní aplikace a především na ně se bude soustředit testování pouţitelnosti.

- 12 -

Druhou malou skupinu uţivatelů zastupují lidé starající se o údrţbu zařízení a aplikace, dá se říci, ţe jde v podstatě o správce aplikace.

3.4 Obecné poţadavky na projekt Projekt, jak jiţ bylo několikrát zmíněno, má přinést úsporu finančních prostředků a zefektivnění práce zaměstnanců, to představuje provedení důkladné analýzy současné situace ve společnosti, tak aby byly zjištěny nedostatky a ty posléze byly nahrazeny efektivnějším řešením. V rámci projektu se mají pouţít moderní technologie, které představují moţnost dlouhodobého vyuţití a případného rozšíření, nejedná se pouze o moderní technologie související s vývojem mobilní aplikace, ale také například o pouţití moderních zařízení. Z funkčních poţadavků kladených na projekt se jedná o umoţnění procesu příjmu a výdeje materiálu, výrobků, atd., a částečně také procesu řízení skladových zásob. Podrobnější specifikace poţadavků kladených na zařízení a aplikaci jsou rozebírány v kapitole 4.

3.5 Účel a cíl práce Cílem práce je ukázat ţivotní cyklus vývoje aplikace pro mobilní zařízení v celé jeho šíři od analýzy aţ po poskytnutí podpory. Co se týče projektu A_Terminal++ je zde cílem vyvinout mobilní aplikaci A_Terminal++, běţící na zařízení umoţňující snímání čárových kódů a poskytující moţnost správy získaných dat, které jsou následně synchronizovány s databázovým serverem. V závěrečném hodnocení páce by nemělo chybět porovnání vývoje aplikací pro mobilní zařízení od vývoje klasických aplikací.

- 13 -

- 14 -

4 ANALÝZA A NÁVRH ŘEŠENÍ „Být připraven je nejdůležitější předpoklad úspěchu.“ Henry Ford Základem úspěšného projektu je provedení důkladné analýzy, neboť nedostatečná příprava před samotnou implementací poté vede k problémům a nedorozuměním mezi zadavatelem a dodavatelem. Důleţitost detailní specifikace umocňuje fakt, ţe zkrátí potřebnou dobu pro vývoj a tedy klesnou celkové finanční náklady vynaloţené na projekt. Role člověka provádějící analýzu - analytika je poměrně sloţitá, musí porozumět odborné oblasti, do které projekt zapadá například při tvorbě systému internetového bankovnictví, musí analytik znát produkty a sluţby nabízené bankou a souvislosti mezi nimi, tak aby je poté dokázal postihnout při psaní specifikace a modelování diagramů. Samozřejmě znalost domény projektu nestačí, analytik musí mít také přehled v technických záleţitostech, aby rozpoznal poţadavky od zadavatele, které nepůjdou danou technologií řešit, a buď se musí zvolit jiná technologie pro vývoj, nebo poţadavek přeformulovat či zrušit. Analýza slouţí na jedné straně dodavateli pro zjištění náročnosti prací, jako podklad k implementaci a kontrole splněných poţadavků a na druhé straně zadavateli pro strukturovaný popis (specifikaci), názorný přehled funkčnosti (UML diagramy) a ke kontrole zda vše zamýšlené bude projekt obsahovat. Kaţdá část projektu vyţaduje podrobný rozbor k určení nejlepších variant. Výběr vhodných variant je určen několika hledisky, mezi hlavní hlediska, jeţ rozhodují o výběru, patří:  Ekonomické hledisko  Časová náročnost  Poţadavky a omezení zadavatele  Moţnosti řešitele Některé z výše uvedených mohou být ve vzájemném konfliktu a výsledek tak záleţí na kompromisu mezi konfliktními aspekty. Výběr řešení můţe být někdy jiţ dopředu omezen poţadavky zadavatele či moţnostmi řešitele. Čím více je omezení ze strany zadavatele, tím menší je samozřejmě manévrovací prostor pro řešitele a je právě úlohou analýzy přesvědčit pomocí získaných údajů zadavatele k moţným ústupkům ve prospěch projektu.

- 15 -

4.1 Současný stav ve firmě Kovar Firma Kovar v současné době vyuţívá jiţ zavedený IS A_System++, který zefektivnil a ulehčil práci zaměstnancům a také urychlil a zpřehlednil i samotné procesy probíhající ve firmě. Co se týče procesu příjmu a výdeje zboţí a materiálu, coţ je hlavní oblast které nás z pohledu tohoto projektu zajímá, je zpracování prováděno v papírové formě a poté ručně vepisováno do aplikace A_System++. Jiţ z popisu provádění práce při daném procesu je zřejmé, ţe dochází ke zbytečně zdlouhavému a pracnému zpracování těchto dat. Zaměstnanec musí kvůli kaţdému příjmu či výdeji odbíhat ke stolnímu počítači a tam poté veškeré nutné údaje ručně vepsat. Chybí tedy část infrastruktury, která by zajistila automatickou nebo alespoň poloautomatickou správu dat při příjmu a výdeji zboţí či materiálu.

4.1.1 Stav současných rolí U kaţdé firmy nalezneme jiné strukturní uspořádání a tedy i jiné role uţivatelů. Pro kaţdou firmu se tedy musí udělat podrobný rozbor, jakou strukturu pouţívají a jaké role mají jednotlivý zaměstnanci. V současné době se ve firmě Kovar na procesu příjmu či výdeje materiálu a zboţí podílejí následující zaměstnanci – účetní a skladník. Pak jednotlivé role v současné situaci jsou a plní funkce:  Skladník o Provádění příjmu v aplikaci A_System++ o Provádění výdeje v aplikaci A_System++ o Kontrola zásob na skladě  Účetní o Provádí zpracování účetnictví o Zpracovává vydané a přijaté poloţky o Kontroluje poloţky výdeje a příjmu

- 16 -

4.1.2 Současný proces příjmu a výdeje Příjem V okamţiku přijímání zboţí se skladník řídí dodacím listem od dodavatele. Nejprve fyzicky zkontroluje, zda souhlasí počet a druh přijímaného zboţí s dodacím listem, poté se musí přemístit ke klientskému zařízení, kde je moţnost přístupu k IS A_System++, zde musí celý dodací list poloţku po poloţce zadat do IS A_System++. Při zadávání poloţek z dodacího listu do IS můţe dojít k překlepům a to poté můţe vést aţ k zanesení chyby do IS A_System++. Výdej Při vydávání zboţí skladník obdrţí ţádanku na materiál (resp. výrobní příkaz1), podle které nejprve provede fyzické vyskladnění, poté přejde ke klientskému zařízení s IS A_System++, kde zadá číslo zakázky a do této zakázky pak vepisuje poloţku po poloţce ze ţádanky. Při ručním vepisování údajů do IS, můţe dojít k výskytu chyb při překlepech, které následně mohou způsobit velké škody, při zpracovávání a fakturování těchto zakázek.

4.2 Budoucí stav ve firmě Kovar Výsledkem snaţení celého projektu má být zefektivnění práce zaměstnanců a ušetření tak finančních prostředků, kterých není zejména v dnešní době nikdy dost a kaţdá firma se snaţí šetřit, jak se dá. Výsledkem první fáze projektu má být především přesvědčený zákazník, který ví o nutnosti zavedení aplikace A_Terminal++ do jeho firmy, pokud chce získat konkurenční výhodu. Důkazem, ţe se tato fáze podařila úspěšně zvládnout, je hladký průběh analýzy, následná podpora zákazníka při implementaci a v neposlední řadě instalace produktu bez jakýchkoliv váţnějších problémů. To vše dává dobrý základ pro spokojeného uţivatele aplikace. Z fáze implementační vzejde hotová aplikace připravená k testování u zákazníka, kde se provedou další testy na reálných datech v reálných podmínkách a aţ poté dochází k distribuci na server (sluţba pro synchronizaci dat) a klientské pracoviště (samotná aplikace A_Terminal++).

1

Výrobní příkaz obsahuje číslo zakázky a rozpis samotného materiálu.

- 17 -

V dalším kroku projektu se očekává dodání potřebného vybavení pro firmu, coţ obnáší hardware a software nutný k běhu aplikace A_Terminal++. Poté instalace sluţby na server a aplikace na mobilní zařízení. Součástí zavedení aplikace je také důkladné zaškolení uţivatelů. Školení bude probíhat i dále po zavedení, tak aby uţivatelé vyuţívali aplikaci bezpečně a efektivně. Jako poslední, ale stejně důleţité jako ostatní je poskytnutí podpory k aplikaci. Podpora bude trvat po celou dobu uţívání produktu.

4.2.1 Stav budoucích rolí U tohoto projektu vycházíme z úzké skupiny uţivatelů, kteří budou aplikaci vyuţívat. Jmenovitě jsou to zaměstnanci ve funkci: skladník a správce IT. Pak jednotlivé role podle uţivatelů jsou a plní funkce:  Správce IT o Přístup do aplikace o Kompletní správa aplikace  Skladník o Přístup do aplikace o Provádění procesu příjmu a výdeje o Synchronizace dat se serverem

4.2.2 Budoucí proces příjmu a výdeje Příjem Při příjmu zboţí má kaţdý typ poloţky svůj interní čárový kód, pokud ještě přijímaný typ zboţí nebyl přijímán, je zaloţena nová skladová karta a k ní vytisknut i nový čárový kód, který je umístěn v místě uskladnění dané poloţky. Skladník při naskladnění načítá pomocí klientského zařízení se čtečkou čárových kódů příslušné interní čárové kódy přijímaných poloţek, kde některé údaje (např. mnoţství) zadává ručně a jiné (např. název poloţky) se mu načítají z klientské databáze. Poté co načte veškeré přijímané zboţí, můţe skladník provést synchronizaci dat, tak aby se naskladněné poloţky ihned dostaly do IS A_System++. Odpadá zde přecházení ke klientskému zařízení a také moţnost překlepů se sníţila díky automatickému procesu načtení a vyhledání příslušné poloţky.

- 18 -

Výdej Při výdeji zboţí je nejprve nutné z výrobního příkazu sejmout čárový kód čísla zakázky, ke které se výdej vztahuje. V rámci této zakázky jsou poté načítány jednotlivé čárové kódy poloţek z výrobního příkazu. Pro kaţdou poloţku se opět část dat předvyplní a část se musí zadat ručně. Po načtení všech poloţek můţe skladník provést synchronizaci dat, aby se vyskladněné poloţky ihned zanesly i do IS A_System++. Opět je zde sníţeno riziko výskytu překlepů a odpadá potřeba přecházet ke klientskému zařízení s IS A_System++.

4.3 User-Centered Design metodika a persona Existuje několik metodik a postupů jak vyvíjet uţivatelské rozhraní. Jiţ před dvaceti lety se začala prosazovat myšlenka vyvíjet a vyrábět uţivatelsky přívětivé zařízení, proto také vznikla metodika User-Centered Design (UCD). Zástupce protilehlé strany vývoje uţivatelského rozhraní se nazývá technologií řízený návrh (technology-driven design), jeţ je odprostěna od zapojení uţivatele do procesu vývoje. Základním kamenem User-Centered Design metodiky je aktivní zapojení uţivatele do ţivotního cyklu výrobku, tak aby se dosáhlo co největší míry porozumění uţivatele a následně jeho spokojenost. UCD se snaţí hledat odpovědi na otázky o ţivateli a jeho potřebách, schopnostech a moţnostech. Náročnost této metodiky spočívá především v potřebě mít reálné uţivetele2, proto se v některých fázích vývoje pouţívá tvz. persona (fiktivní uţivatel), jejíţ chování, poţadavky a potřeby jsou analyzovány stejně důkladně, jakoby se jednalo o skutečného uţivatele.

4.3.1 Persona Persona je popis „prototypu― uţivatele, který slouţí jako vodítko v procesu grafického návrhu a uspořádání informací. Lze si ji představit jako model fiktivního uţivatele na základě určitých charakteristik (např. cílové skupiny či úkolu, který řešíme). Nejedná se o nahrazení uţivatelského testování na skutečných lidech ani sníţení počtu jeho testerů. Je to spíše jakési vcítění do mysli určitého typického uţivatele, které nám pomáhá posuzovat návrh z jiného úhlu pohledu z pohledu uţivatelů. Persony jsou pokaţdé speciálně vytvořeny

2

V rámci této práce není moţné mít v průběhu celého vývoje k dispozici budoucí uţivatele, nehledě na čas nutný k diskuzi s nimi.

- 19 -

pro konkrétní problém a nelze je tedy modelovat jako obecné nezávislé entity. Jiný pohled na personu je uveden v (5). Persona nejčastěji vzniká jako výsledek shrnutí interview s konkrétními uţivateli nebo jejich pozorováním při práci. V (6) je uveden kompletní proces vytváření person. Tvorbě person předchází sestavení kategorií uţivatelů tzv. skeletonů. Jako návod slouţil zdroj (7).

4.3.2 Skeletony Skeletony představují kostry budoucích person. Na základě pozorování uţivatelů jsou identifikovány jednotlivé vlastnosti a poţadavky uţivatelů (uţivateli se v kontextu této práce myslí skladníky). Tyto poţadavky je třeba rozdělit do jednotlivých kategorií tak, aby si vzájemně neodporovaly. Na základě těchto „koster― jsou z jednotlivých kategorií (skeletonů) vytvářeny persony. Je nemoţné převést všechny skeletony na persony a právě proto dochází v tomto kroku k rozdělení skeletonů dle priorit vzhledem k produktu. V bliţším pohledu je toto prioritní rozdělení zaloţeno na „velikosti trhu―, „frekvenci pouţití― a „strategické důleţitosti― a tedy vţdy podle druhu produktu. Jako výsledek prioritního výběru jsou poté některé skeletony převedeny na persony. K sestavení skeletonu je nutné provést interview s potenciálními budoucími uţivateli. Interview obsahuje otázky zaměřené na danou oblast (pouţití mobilní aplikace), ale je vedeno nenásilně a spíše volnou formou, kdy aţ po provedení interview se vypichují jednotlivé odpovědi, tak aby se z nich daly sestavit kategorie pro jednotlivé skeletony. Interview proběhlo se sedmi osobami, a poněvadţ okruh budoucích uţivatelů je omezen na skladníky, všechny dotazované osoby byli skladníci ve společnosti Kovar. Bliţší popis osob je uveden v kapitole 6.2.4. Prováděné interview se neslo v přátelském duchu, kdy jednotlivý budoucí uţivatelé odpovídali na poloţené otázky a byly tak získány data, ze kterých se poté vyextrahovaly potřebné informace pro sestavení skeletonů. Interview trvalo v průměru šest minut a převáţným tématem rozhovoru byly mobilní aplikace, technická zdatnost a působení ve společnosti Kovar. Z kaţdého interview se poté vybralo několik okruhů odpovědí, z nichţ se sestavily základní rysy jednotlivých skeletonů.

- 20 -

Z informací získaných z provedených interview a z analýzy budoucích uţivatelů (kapitola 3.3 a 4.2.1) byly pomocí metodiky UCD (více kap. 4.3) sestaveny dva primární skeletony (přesněji aktivní a pasivní skladník). Za kaţdou popisovanou vlastností je v závorce uveden počet účastníků, u kterých se daná vlastnost vyskytla a za lomítkem velikost relevantní skupiny účastníků. Dále je také uvedeno stručné vysvětlení dané vlastnosti. Skeleton 1 – aktivní skladník 1. Má dobré technické schopnosti (5/7) – Pracovat s technickým zařízením mu nečiní problém. 2. Je zručný při ovládání prstem (2/7) – Nedělá mu problém ovládat displej mobilního zařízení prstem. 3. Je zručný při ovládání zařízení stylusem (3/7) – Výborně zvládá ovládání displeje mobilního zařízení stylusem. 4. Preferuje obrazovku bez hlavního menu (6/7) – Při spuštění aplikace se přesune rovnou na jednu z pracovních záloţek. 5. Poţaduje moţnost potvrdit obrazovku stiskem kláves (3/7) – Odeslání poţadavku z formuláře by mělo být moţné i stiskem určené klávesy. 6. Preferuje uspořádání informací na jednom formuláři (4/7) – Informace raději zhustit na jednom formuláři, neţ aby se muselo přecházet na další stránku. 7. Důleţitost hraje rychlost načtení dat (4/7) – Rychlost načítání dat do formuláře je pro něj důleţitá. 8. Je si jist při provádění akce (3/7) – Při poţadavku provést danou akci si je jist a prochází formulář bez problému. 9. Současný stav povaţuje za nevyhovující (6/7) – Je nespokojený se současným způsobem své práce a tudíţ by rád změnil způsob své práce. Skeleton 2 – pasivní skladník 1. Není zručný při ovládání zařízení (2/7) – Dělá mu problém ovládat displej mobilního zařízení ať jiţ prstem či stylusem. 2. Má raději papír a tuţku neţ technická zařízení (2/7) – Je spokojen při práci kde vyuţívá minimum technických zařízení.

- 21 -

3. Má rád přehled a moţnost výběru (5/7) – Rád si sám určuje, co zrovna dělá a to co dělá, musí být jasně dané. 4. Nevyhovují mu potvrzovací obrazovky (3/7) – Například při zrušení záznamu by preferoval rovnou záznam smazat a nedotazovat se jiţ na potvrzení dané akce. 5. Preferuje málo informací na formuláři (1/7) – Informace na formuláři mají být dostatečně odděleny a nemělo by jich být mnoho. 6. Rychlost načtení dat není určující (2/7) – Rychlost načtení dat pro něj není kritický faktor. 7. Přechází mezi záloţkami a není si jist (3/7) – Při poţadavku provést danou akci si nejistě prochází záloţky a zkoumá je. 8. Současný stav povaţuje za vyhovující (1/7) – Je spokojený se současným způsobem své práce a tudíţ nevidí důvod ke změně.

4.3.3 Tvorba persony ze skeletonů Fakta, která jsou u jednotlivých skeletonů uvedena, musejí být převedena do konkrétní podoby. Například obecné údaje (muţ, 34-40 let, technický typ) jsou převedeny na konkrétní informace (Pavel, 37 let, pouţívá denně počítač a mobilní telefon). Byla vytvořena jedna primární persona pojmenovaná Tomáš, která repprezentuje spíše tu část uţivatelů, jeţ přistupuje k dané doméně aktivně. Odpovídá skeletonu aktivního uţivatele popsaného v kapitole 4.3.2. Tomáš je technicky zdatný, nedělá mu problém ovládání dotykového displeje prsty či stylusem, rád pracuje sviţně a nevyhovuje mu současný způsob provádění práce. Primární persona Tomáš je uvedena na další straně.

- 22 -

4.3.3.1 Persona Tomáš

Jméno: Tomáš

Věk: 41let

Pohlaví: muţ

Bydliště: Vsetín

Tomáš

se

narodil

v malé

krásné

vesničce

Vesník

na Východní Moravě kousek od Vsetína. Tomáš je velmi šikovný, takţe vypomáhal, kde se dalo, aby uspořil nějakou korunu k dobru. Jiţ od mala měl rád motorky, které zprvu musel pouze Obrázek 4-1 Tomáš

obdivovat u svých sousedů. Aţ si konečně i jeho otec jednu

pořídil a někdy ji půjčoval i Tomášovi. Dokázal si spousty poruch na motorce opravit sám a ušetřil tak mnoho peněz za opravnu. Po vystudování střední školy se stal dělníkem v jedné dílně na výrobu různých součástek do automobilů, ale protoţe byla dílna vzdálena přes hodinu a půl cestování, nevydrţel zde Tomáš dlouho. Další prací se pro Tomáše stala společnost zpracovávající dřevo, zde pracoval osm let a poté musel odejít, poněvadţ společnost zkrachovala. Doposud poslední práci si Tomáš našel ve společnosti Kovar vyrábějící Kontejnery pro široké spektrum pouţití. Tomáš je zde zaměstnán jako skladník a má na starosti příjem a výdej materiálu a dalších poloţek. Jeho práce vyţaduje neustálý pohyb, poněvadţ prostory společnosti jsou rozsáhlé a skladovací prostory jsou rozmístěny po celém areálu firmy. Práce mu dává moţnost být neustále v kontaktu s lidmi, kdyţ přebírá nebo vydává materiál. Po pěti letech u této společnosti je Tomáš zatím spokojen, i kdyţ by rád zjednodušení své práce (zdroj 9)3, aby nemusel pořád dokola přebíhat s papíry k počítači, kde musí do IS zavést přijaté a vydané poloţky. Tato činnost Tomáše navíc zdrţuje od dalšího přijmutí materiálu od dodavatele či vydání zboţí. Ve volném čase se Tomáš věnuje rodině, a pokud mu ještě zbude čas, věnuje se jeho koníčku a to opravování historických rádií a podobných starých elektronických přístrojů. Nemá tedy problém s technickými zařízeními, neboť je pouţívá jak v práci tak i doma (zdroj 1).

3

Odkazuje na Skeleton 1 a její příslušnou vlastnost, v tomto případě vlastnost 9.

- 23 -

Tomášovi preference Obecné  Je technicky zdatný  Má rád sviţnější tempo, ale i přesto pro kontrolu je ochotný zpomalit (zdroj 5)  Vyjadřuje nespokojenost se současným stavem vykonávání jeho práce Aplikační  Nechce mít hlavní menu (zdroj 4)  Aplikace se mu ovládá dobře jak prstem, tak stylusem (zdroj 2, 3)  Informace chce mít raději pouze na jednom formuláři (zdroj 6)

- 24 -

4.4 Katalog poţadavků Katalog poţadavků podává strukturované informace o poţadavcích kladených na aplikaci. Poţadavky jsou rozděleny na funkční a nefunkční. V rámci funkčních poţadavků je členění na poţadavky kladené na celou aplikaci a na jednotlivé logické celky.

4.4.1 Funkční poţadavky Funkční poţadavky specifikují konkrétní případy, jeţ mají přímý vliv na implementaci systému. 4.4.1.1 Poţadavky na systém  Umoţnit snímat čárové kódy  Umoţnit příjem poloţek  Umoţnit výdej poloţek  Spravované data mít k dispozici na mobilním zařízení  Data na klientském zařízení musí být aktuální  Data s klientského zařízení se musí na příkaz uţivatele uloţit do serverové databáze  Automatické vytváření klientské databáze  Data z klienta jsou dále zpracovány v IS A_System++ 4.4.1.2 Poţadavky na část příjmu Základní obrazovka Musí umět:  Přehled jiţ přijatých poloţek v podobě seznamu; ke kaţdé přijaté poloţce v seznamu jsou zobrazeny další důleţité informace  Přechod na obrazovky související s procesem příjmu o Samotný příjem o Úprava stávajících přijatých poloţek  Smazat přijatou poloţku Obrazovka zadání příjmu Musí umět:  Načíst data ze snímaného čárového kódu

- 25 -

 Zadat kód pro vyhledání informací ručně  Zobrazit správné a potřebné informace a ty, u kterých je to vyţadované, umoţnit zadat ručně  Kontrolu povinných polí  Uloţit získané a případně ručně zadané informace a poté o Příjem další poloţky (zůstane pořád na obrazovce příjmu) o Přejít zpět na hlavní obrazovku  Vrátit se zpět na hlavní obrazovku Obrazovka úpravy příjmu Musí umět:  Zobrazit správné a potřebné údaje; údaje pro úpravu umoţnit změnit  Uloţit údaje a vrátit se zpět hlavní obrazovku  Vrátit se zpět na hlavní obrazovku bez uloţení změněných údajů 4.4.1.3 Poţadavky na část výdeje Základní obrazovka Musí umět:  Přehled jiţ vydaných poloţek v podobě seznamu; ke kaţdé vydané poloţce v seznamu jsou zobrazeny další důleţité informace  Přechod na obrazovky související s procesem výdeje o Samotný výdej o Úprava stávajících vydaných poloţek  Smazat vydanou poloţku Obrazovka zadání výdeje Musí umět:  Načíst data ze snímaného čárového kódu  Zadat kód pro vyhledání informací ručně  Zobrazit správné a potřebné informace a ty, u kterých je to vyţadované, umoţnit zadat ručně  Kontrolu povinných polí

- 26 -

 Uloţit získané a případně ručně zadané informace a poté o Výdej další poloţky (zůstane pořád na obrazovce výdeje) o Přejít zpět na hlavní obrazovku  Vrátit se zpět na hlavní obrazovku Obrazovka úpravy příjmu Musí umět:  Zobrazit správné a potřebné údaje; údaje pro úpravu umoţnit změnit  Uloţit údaje a vrátit se zpět hlavní obrazovku  Vrátit se zpět na hlavní obrazovku bez uloţení změněných údajů 4.4.1.4 Poţadavky na část synchronizace  Synchronizovat údaje klientské databáze se serverovou  Údaje o přijatých a vydaných poloţkách (tabulka PVPTERM) přenést na serverovou databázi; přenesené údaje se z klientské databáze smaţou  Mít na klientské databázi aktuální údaje z tabulek DODZBOZ (dodavatelé zboţí), CENZBOZ (ceník) a C_SKLADY (číselník skladů)  Tlačítko synchronizace mít pokud moţno neustále k dispozici

4.4.2 Nefunkční poţadavky Nefunkční poţadavky udávají obecné vlastnosti systému, jako je například vysoká spolehlivost, přehlednost, či bezpečnost systému. Přehled nefunkčních poţadavků:  Mobilita  Dlouhá výdrţ mobilních zařízení  Odolnost mobilních zařízení  Snadné ovládání aplikace

4.5 Návrh architektury S vývojem celé IT oblasti se postupně stávaly vznikající systémy sloţitější a komplexnější, nebylo proto moţné zůstat jen u návrhu algoritmů a datových struktur, poněvadţ ty nyní

- 27 -

tvořily pouze základní kameny celého systému. Vznikla tak potřeba větší abstrakce, na systém jiţ nebylo moţno nahlíţet jen jako na posloupnost několika funkcí a metod, které vytváří celý systém, to jiţ nebylo v lidských moţnostech. Softwarový produkt svou rozsáhlostí vyţadoval větší stupeň abstrakce, kde algoritmus je povaţován za jeden ze stavebních kamenů aplikace, tyto a další stavební kameny se skládají ve větší celky a tvoří tzv. komponenty a tyto komponenty jsou opět různými způsoby propojeny a můţou navzájem interagovat. Vyšší stupeň abstrakce sebou přinesl také řadu problémů4, jedním z nich byl problém vyjádření této vyšší abstrakce. Pouze textový popis nedokázal názorně vyjádřit veškeré souvislosti, jelikoţ sloţitost vznikajících systémů vyţadovala jednodušší formu zápisu, tak aby i nově příchozí pracovník lehce vklouzl do dané problematiky. Výsledkem jednoho z mnoha snaţení byl vznik UML (Unified Modeling Language)5 standardizovaný obecný modelovací jazyk pouţívaný v softwarovém inţenýrství. Dále popisovaný v kapitole 4.6. Zmiňovaným vyšším stupněm abstrakce se postupně začal zabývat nově vznikající obor softwarová architektura popisovaný níţe, jeţ měl umoţnit jednodušší návrh sloţitých systémů a to v podobě srozumitelné jak pro vývojáře, tak pro zákazníka.

4.5.1 Softwarová architektura Ţádná oficiální definice pojmu softwarová architektura v současné době neexistuje, avšak všechny dostupné mají společné jádro a liší se jen detailností a svým záběrem. V tomto textu uvedu definici která je výsledkem diskusní skupiny věnované problematice softwarové architektury v Institutu softwarového inţenýrství při Carnegie Mellon University v Pittsburghu. Následuje definice6: Softwarová architektura je struktura komponent programu/systému, jejich vzájemné vazby, principy a předpisy určující jejich návrh a vývoj v průběhu času.7

4

Velká převaha pozitiv ovšem tyto negativa postupně zastiňuje a v současnosti se jedná spíše o názorové rozdíly jednotlivých odborníků na to, jaké řešení se pro daný problém jeví jako optimálnější a správnější. 5 Standard vyvinutý a spravovaný OMG (Object Management Group). 6 Tato definice byla pouţita např. v (21) (22) (23) (24) 7 Původní znění: The structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time.

- 28 -

Moţnosti jak chápat a vysvětlit pojem softwarová architektura je mnoho a kaţdá se hodí více v daném kontextu vyuţití. Následuje zkrácený pohled na celou problematiku softwarové architektury. „Softwarová architektura je obor velmi mladý, a to i v kontextu vývoje softwaru, přičemž její kořeny spadají do konce osmdesátých či začátku devadesátých let. Pokud se podíváte detailněji na strukturu IT složky velkých společností, jako jsou banky, telekomunikační společnosti, pojišťovny apod., naleznete zde zpravidla také oddělení nebo skupinu lidí, kteří se softwarovou architekturou úzce zabývají. Cokoli, co je jejím výstupem, musí být spojeno s nějakým požadavkem či potřebou spjatou s obchodním přínosem organizaci. Softwarová architektura tedy pracuje s potřebami/požadavky a tyto transformuje do struktury vytvářeného systému.“ (8)

4.5.2 Architektura aplikace A_System++ Z pohledu softwarové architektury lze na sestavení systému pohlíţet různými způsoby. Existuje mnoho architektonických stylů a vzorů. Před samotným rozhodnutím, jakou architekturu pro aplikaci A_Terminal++ zvolit, je nutné provést rozbor moţných řešení, které připadají do úvahy. U jednotlivých moţných řešení budou uvedeny specifika, výhody a nevýhody, tak jak je přináší jejich pouţití. Následuje shrnutí poţadavků aplikace na architekturu, ze kterých vzejde architektonický styl a ten bude dále analyzován do specifičtějších podob. Obecné poţadavky související s architekturou je důleţité znát a mít je na paměti při výběru architektury. V rámci projektu je dle poţadavků nutné zajistit synchronizaci mezi klientem a serverem, tím je do značné míry dán také poţadavek na architekturu aplikace. Specifikace dále udává, ţe data směřující z klienta na server se mají dále zpracovávat v IS A_System++, coţ znamená další poţadavek na architekturu aplikace. Klientských zařízení bude více a tak je nutné zajistit, aby nedocházelo ke konfliktu při synchronizaci se serverem. Při výběru architektury aplikace se musí brát v potaz technické moţnosti klientského zařízení, které má být navíc dle specifikace mobilní a nemusí tak vyhovovat kaţdému typu architektury. Z pohledu architektur je nutné zamýšlet se nad moţnostmi pouţití mobilního zařízení, neboť některé z architektur mohou klást vysoké poţadavky na klientské zařízení, coţ můţe mít za následek pomalé odezvy aplikace či dokonce nemoţnost realizace dané architektury.

- 29 -

Na základě poţadavků na architekturu a prostudování moţností jednotlivých stylů architektur byl vybrán architektonický styl klient-server. Dále jsou popsány charakteristiky vybraného stylu a poté k analýze vybrány tři moţné řešení v 4.5.2.1 aţ 4.5.2.3, které architektonický styl klient-server umoţňuje realizovat. Klient-server Klient-server model má rozdělenou strukturu aplikace, kdy část aplikace zpracovává poţadavky a obstarává práci se zdroji, ta se nazývá server8 a zbývající část aplikace poţadavky vytváří a zobrazuje obdrţené výsledky, to je klient. Komunikace mezi serverem a klientem většinou probíhá po datové síti (tzn. server a klient nejsou umístěny na stejném stroji), ale můţou být stejně dobře umístěny na jednom stroji. Server většinou sdílí zdroje spuštěných aplikací s více klienty, kdeţto klient nesdílí ţádné data, pouze o ně server ţádá. Tyto charakteristiky se můţou mírně lišit, pokud je pouţito jiných přístupů k návrhu aplikace. Model klient-server můţe být realizován také jako dvouvrstvá, n-vrstvá, klientklient nebo tzv. cloud computing aplikace, v dalším pohledu to můţou být aplikace typu tlustý klient, tenký klient nebo chytrý klient. A právě tento pohled je vyuţit při analýze moţných řešení modelu klient-server.

Obrázek 4-2 Klient - server

4.5.2.1 Řešení tlustý klient Obecná specifika Tlustý klient v sobě obvykle zahrnuje jak presentační tak i aplikační vrstvu a připojuje se přímo k databázovému nebo jinému serveru. Další typickou vlastností tlustého klienta je,

8

Někdy také označována jako sluţba.

- 30 -

ţe si přes síť stahuje velký objem dat, která zpracuje a výsledek pak přenese zpět na server. Instalace, konfigurace a podpora tlustých klientů je časově a finančně mnohem náročnější neţ je tomu v případě tenkých klientů, protoţe je musíme dostat na kaţdý stroj, na kterém má být tlustý klient provozován. výhody

Nevýhody

server nevyţaduje výkonný HW

klient vyţaduje výkonný HW

snadný a rychlý vývoj

vysoké nároky na šířku přenosového pásma

snadná podpora uţivatelů

obtíţné nasazení

přenositelnost (různé verze pro různé HW a SW platformy) moţnost pracovat offline přívětivé uţivatelské rozhraní

obtíţný update obtíţná správa stopy aplikace v systému (vlastní program, data, DLL, registry)

rychlá odezva aplikace Tabulka 4-1 Tlustý klient porovnání výhod a nevýhod

Specifika pro A_Terminal++ Klient by musel obsahovat veškerou nutnou funkcionalitu pro splnění specifikovaných poţadavků. Tímto řešením klademe velké poţadavky na výkon a paměťové nároky klienta a spolehlivost a rychlost datového připojení klienta se serverem. Server by zde představoval pouze úloţiště dat a nebylo by tedy vyuţito jeho moţností. Jelikoţ má být klient mobilní, objevuje se zde moţný konflikt výkonu a mobility, poněvadţ v současné době mobilní zařízení pro snímání čárových kódů by výkonově nemuselo plně dostačovat, jestliţe by muselo obstarat veškerou synchronizační práci samo. 4.5.2.2 Řešení tenký klient Obecná specifika Tenkým klientem obvykle rozumíme webový prohlíţeč, který s presentační vrstvou komunikuje přes bezestavový HTTP protokol a stará se tak pouze o zobrazování dat. Na tenkém klientovi neprobíhá ţádná rozhodovací logika, pokud nebereme v úvahu např. validaci dat, zadávaných do webového formuláře. Z výše uvedené skutečnosti je snad zřejmé, ţe nároky na instalaci, konfiguraci a podporu tenkých klientů jsou minimální,

- 31 -

protoţe uţivateli takové aplikace stačí, kdyţ má na svém zařízení nainstalován nějaký internetový prohlíţeč. Naprosto tak odpadá starost o to, aby měl klient k dispozici vţdy aktuální verzi, neboť ta je k dispozici všem klientům v okamţiku, kdy je nasazena na serverech. Komunikace mezi tenkým klientem a serverem je intenzivnější neţ v předchozím případě, ale na druhou stranu se mezi nimi přenese menší objem dat (neplatí např. u JS frameworků vyuţívající AJAX, neboť zde se přenáší jen změny, nikoliv celá stránka), protoţe k vlastnímu zpracování dat dochází na serveru a na klienta se přenáší pouze výsledek tohoto zpracování. Určitou nevýhodou je, ţe u aplikací, u kterých není vyţadována autentizace, nikdy přesně nevíme, kolik uţivatelů (tenkých klientů) se k naší aplikaci připojí. V případě tlustého klienta maximální moţný počet současně připojených uţivatelů obvykle víme, protoţe víme, na kolika zařízeních byl nainstalován, a tudíţ je snazší spočítat, jak výkonný HW budeme potřebovat. Vývoj aplikace pro tenkého klienta je náročnější především z důvodu rozčlenění aplikace do jednotlivých vrstev. Výhody

Nevýhody

klient nevyţaduje výkonný HW

server vyţaduje výkonný HW

nízké nároky na šířku přenosového

náročný vývoj

pásma snadné nasazení

strohé uţivatelské rozhraní

snadný update

nemoţnost pracovat offline

snadná správa

pomalá odezva aplikace

snadná podpora uţivatelů

obtíţnější ovládání aplikace

přenositelnost (běţí v kaţdém prohlíţeči) minimální stopy po aplikace v systému (cookies, temp, history) Tabulka 4-2 Tenký klient porovnání výhod a nevýhod

Specifika pro A_Terminal++ Při řešení architektury pomocí tenkého klienta by logika aplikace byla implementována na straně serveru a na samotném klientu by bylo pouze zobrazení poţadovaných dat a odeslání poţadavku na server. Zpracovávání poţadavků a provádění výpočtů by probíhalo

- 32 -

na straně serveru a tedy veškerý potřebný výkon pro chod aplikace by obstaral server. Výkon, potřebná paměť a diskové místo dnes běţně dostupných serverů by jistě postačovalo pro chod serverové části aplikace. Klient z hlediska výkonu musí pouze obstarat zobrazení obdrţených dat, coţ není výpočetně náročná operace a tak velké mnoţství současných mobilních zařízení vyhovuje těmto kladeným kritériím. Problémem se zde jeví nutnost neustálého připojování k serveru k obsluze poţadavků z klienta. Klient je plně závislý na serveru a spojení tak musí mít dostatečnou kapacitu, pro přenos většího objemu dat, ale i velkou spolehlivost a neustálou dostupnost, jinak se aplikace stane nepouţitelnou. Dalším moţným problémem můţe být odezva při poslání poţadavku na server, neboť po nasnímání čárového kódu bude nutné provést vyhledání tohoto čárového kódu a zjištění jeho parametrů a na základě toho zobrazení příslušných dat uţivateli. Latence mezi sejmutím čárového kódu (resp. odesláním poţadavku na server) a zobrazením údajů do formuláře (resp. obdrţením odpovědi ze serveru) je zásadní pro plynulou práci s aplikací. Uţivatel nebude chtít čekat neúnosnou dobu po kaţdém sejmutí čárového kódu, jestliţe tento úkon bude denně provádět s velkou frekvencí. Aplikace by měla uţivateli zkrátit potřebnou dobu pro vykonání potřebných úkonů, coţ by zde bylo náročně splnitelné. 4.5.2.3 Řešení chytrý klient Obecná specifika Chytrý klient vhodně kombinuje výhody tenkého a tlustého klienta a potlačuje jejich nevýhody. Aby mohl pracovat offline, obsahuje určitou logiku a drţí data, která se v okamţiku navázání spojení synchronizují. Vyuţívá místní systémové zdroje jako je např. paměť, procesor a diskový prostor, ale můţe komunikovat a vyuţívat i připojených zařízení. Stejně tak můţe vyuţívat přítomnosti a funkcí, které nabízejí ostatní nainstalované aplikace např. MS Office. Chytrý klient předpokládá, existenci např. .NET Frameworku, JRE nebo pluginu v prohlíţeči. Při svém spuštění si v případě dostupné sítě ověří, zda neexistuje novější verze a pokud ano, tak ji stáhne a spustí. Pokud se nová verze objeví během uţivatelova sezení, je na to uţivatel upozorněn. Právě schopnost pracovat off-line a automatické stahování aktuální verze aplikace v okamţiku navázání spojení se serverem lze povaţovat za základní vlastnost chytrého klienta, ostatní uvedené vlastnosti jsou odvozené. Poněvadţ pouţitím chytrého klienta se nedostatky jak tenkého tak tlustého klienta odstraňují nebo zmenšují, tak v obecném případě hledáme nevýhody těţce. Ovšem můţe

- 33 -

nastat situace, kdy pouţití tenkého nebo tlustého klienta bude specifikovaným poţadavkům vyhovovat více. Specifika pro A_Terminal++ Podle tohoto konceptu by klient mohl mít i vlastní databázi, kde by udrţoval potřebná data, ale většina logiky spojená se synchronizací by byla na straně serveru, který tak obstará část výpočtů a klient tím pádem nebude tak vytíţený. Klient vykonává zpracování dat pro zobrazení na obrazovce a i jejich uloţení do klientské databáze k pozdější synchronizaci se serverem. Klient můţe pracovat offline a není tak závislý na spojení se serverem jako tenký klient. Spojení se vyuţije jen při poţadavku na synchronizaci a tak objem přenesených dat je menší neţ u tlustého klienta a ve většině případů také u tenkého klienta. Odezva na akci uţivatele závisí pouze na výkonu klienta a není tak limitován šířkou přenosového kanálu. Dále část logiky je přesunuta na server, jak jiţ bylo uvedeno a tak část nevýhod tlustého klienta odpadá. 4.5.2.4 Pouţité architekturní řešení Architekturní styl, podle nějţ se budou vytvářet moduly a komunikace mezi nimi v této aplikaci, nese název klient-server. V bliţším pohledu na tento model se provedl rozbor třech moţných řešení s tím, ţe jako nejvýhodnější se jeví pouţití vzoru chytrý klient, kdy nejlépe odpovídá poţadavkům a odstraňuje většinu nedostatků předchozích dvou řešení. Zcela definitivní potvrzení tohoto výběru, bude učiněno aţ po výběru technologií pro tento vzor, tak aby bylo jisté, ţe vůbec existuje přijatelné technologické řešení. A aţ poté bude návrh architektury kompletně završen.

4.6 Modelování aplikace Při návrhu aplikace se pouţívá mnoho pomocných metod pro usnadnění a zefektivnění práce při vývoji. Jednou z takových metod je „modelování― aplikace, coţ ve skutečnosti představuje grafické znázornění různých aspektů aplikace, od modelování částí systému aţ po jeho chování. Tam kde je to nutné se ke grafickému znázornění přidává textový popis. Pouţívaný standard pro grafické znázornění systémů, ale i pro další pouţití se nazývá UML9. V následujících podkapitolách je pouţito UML diagramů pro návrh aplikace A_Terminal++. Z dostupných diagramů je pouţito diagramu případu uţití k zobrazení

9

UML se pouţívá také pro modelování business procesů a vychází z něj řada dalších standardů, které jsou většinou specializované na jednu oblast modelování.

- 34 -

základních vlastností systému, diagramu tříd k zachycení datového modelu aplikace10 a konečně diagramu aktivit k zachycení probíhajících procesů aplikace. Rozsah a hloubka pouţití UML diagramů záleţí na typu projektu, znalostech analytika či návrháře systému. Také způsob pouţití UML diagramů můţe být odlišný, záleţí vţdy na úrovni pouţité abstrakce. V projektu A_Terminal++ byly pouţity výše uvedené diagramy, jelikoţ postačují k zachycení drtivé většiny aspektů aplikace a mohou tak slouţit jak při analýze, implementaci, tak i při sestavování testovacích scénářů a vlastním testování.

4.6.1 Případy uţití Na následujících obrázcích jsou znázorněny případy uţití pro aplikaci A_Terminal++ a to konkrétně:  Příjem zboţí – skladník provádí příjem zboţí o přidání poloţky příjmu – provede se nasnímání nové poloţky příjmu, vyplní se potřebné údaje a poloţka se uloţí do databáze o editace poloţky příjmu – ze seznamu přijatých vybere poloţku k editaci, změny se uloţí do databáze o smazání poloţky příjmu – ze seznamu přijatých vybere poloţku ke smazání, poloţka se smaţe z databáze o prohlíţení poloţky příjmu – prohlíţí seznam přijatých poloţek, kde tento seznam obsahuje důleţité informace ke kaţdé poloţce  Výdej zboţí – skladník provádí výdej zboţí o přidání poloţky výdeje - provede se nasnímání nové poloţky výdeje, vyplní se potřebné údaje a poloţka se uloţí do databáze o editace poloţky výdeje - ze seznamu vydaných vybere poloţku k editaci, změny se uloţí do databáze o smazání poloţky výdeje - ze seznamu vydaných vybere poloţku ke smazání, poloţka se smaţe z databáze

10

Class diagram je prvotně určen k vyjádření implementačně nezávislé struktury tříd aplikace, jeţ vychází z diagramu objektů, ale při odlišné úrovni abstrakce se pouţívá například právě k modelování datového modelu.

- 35 -

o prohlíţení poloţky výdeje - prohlíţí seznam vydaných poloţek, kde tento seznam obsahuje důleţité informace ke kaţdé poloţce uc Use Case Model uc Příj em zboží Aplikace A_Terminal++

Přidat položku příj mu

Edituj položku příj mu

Skladník (from Actors)

Smaž položku příj mu

Prohlížej položky příj mu

Obrázek 4-3 Případ uţití - příjem zboţí uc Use Case Model uc Výdej zboží Aplikace A_Terminal++

Přidat položku v ýdej e

Edituj položku v ýdej e

Skladník

Smaž položku v ýdej e

Prohlížej položky v ýdej e

Obrázek 4-4 Případ uţití - výdej zboţí

- 36 -

 Správa dat11 – skladník synchronizuje data se serverem uc Use Case Model uc Správ a dat Aplikace A_Terminal++

Synchronizace dat Skladník (from Actors)

Obrázek 4-5 Případ uţití - správa dat

Tyto případy uţití představují základní kostru aplikace, jeţ bude dále rozvedena pomocí dalších diagramů. Pojmem skladník se rozumí persona blíţe popsána v 4.3. Proces příjmu a výdeje je rozebrán v 4.2.2.

4.6.2 Diagramy aktivit Na následujících obrázcích jsou zobrazeny diagramy aktivit zachycující proces příjmu, výdeje zakázky a spuštění systému. Aktivita Přijetí zakázky (Obrázek 4-7) Uţivatel vybere typ pohybu, dále musí zvolit interní číslo dodacího listu. Aktivita Uloţení přijaté zakázky (Obrázek 4-6) Uţivatel zadá číslo čárového kódu či ho naskenuje, provede se validace zadaných hodnot, jestliţe zadané hodnoty nevyhovují, je zobrazena chybová hláška a uţivatel opět zadává údaje, v opačném případě dojde k uloţení hodnot do databáze. Dále pokud akce uloţení vedla ze stisku tlačítka Ulož+, dojde k vymazání údajů z formuláře tak, ţe je připraven k dalšímu načítání poloţek. Akce z tlačítka Ulož vede na konec aktivity. Aktivita Vydání zakázky (Obrázek 4-8) Uţivatel vybere typ pohybu, jestliţe vybral Spotřeba, následuje konec aktivity, v případě výběru Spotřeba na zakázku skenuje vydávanou zakázku. V případě naskenování čísla

11

Správou dat se u aplikace A_Terminal++ myslí pouze proces synchronizace, kdy se aktualizují data na klientském zařízení se serverem.

- 37 -

zakázky aktivita končí, v opačném případě dojde k zobrazení informativní hlášky a opět se skenuje vydávaná zakázka. Aktivita Uloţení vydané zakázky (Obrázek 4-9) Uţivatel zadá číslo čárového kódu či ho naskenuje, provede se validace zadaných hodnot, jestliţe zadané hodnoty nevyhovují, je zobrazena chybová hláška a uţivatel opět zadává údaje, v opačném případě dojde k uloţení hodnot do databáze. Dále pokud akce uloţení vedla ze stisku tlačítka Ulož+, dojde k vymazání údajů z formuláře tak, ţe je připraven k dalšímu vydávání poloţek. Akce z tlačítka Ulož vede na konec aktivity. Aktivita Spuštění systému (Obrázek 4-10) Pokud neexistuje konfigurační soubor, je zobrazena chybová hláška a nastane konec aktivity, jinak dojde k načtení konfiguračních údajů. Existuje klientská databáze? Jestliţe ne, dojde k provedení iniciální synchronizace, kdy je tato databáze vytvořena. V případě nalezení klientské databáze, či po jejím vytvoření dojde ke spuštění hlavního okna aplikace a následuje konec aktivity.

- 38 -

act Proces příj mu

Přij etí zakázky

ActivityInitial

Výběr typu pohybu

Zadání interního čísla dodacího listu

ActivityFinal

Obrázek 4-7 Diagram aktivity - Přijetí zakázky

act Proces příj mu

Uložení přij até zakázky

ActivityInitial

Zadání či naskenov ání čárov ého kódu

Validace zadaných hodnot

Vymazat v stupní pole a zneaktiv nit potřebné pole.

Uložení hodnot do databáze

[Ano]

[Ne]

Zobrazení chybov é hlášky

Jsou hodnoty validní?

[Ulož+] Akce Ulož nebo Ulož+?

[Ulož]

ActivityFinal

Obrázek 4-6 Diagram aktivity - Uloţení přijaté zakázky

- 39 -

act Proces v ýdej e

Vydání zakázky

ActivityInitial

Výběr typu pohybu

Vybraný typ pohybu? [Spotřeba na zakázku]

Naskenov ání v ydáv ané zakázky [Spotřeba]

Zobrazeni informativ ního dialogu

[Ne] [Ano] Je číslo zakázky naskenováno?

ActivityFinal

Obrázek 4-8 Diagram aktivity - Vydání zakázky

- 40 -

act Proces v ýdej e

Uložení v ydané zakázky Zadání či naskenov ání čárov ého kódu

Validace zadaných hodnot

Vymazat v stupní pole a zneaktiv nit potřebné pole.

Uložení hodnot do databáze

[Ano]

Zobrazení chybov é hlášky

[Ne]

Jsou hodnoty validní? [Ulož+] Akce Ulož nebo Ulož+? [Ulož]

ActivityFinal

Obrázek 4-9 Diagram aktivity – Uloţení vydané zakázky act Spuštění systému

Spuštění systému Existuje konfigurační soubor?

[Ano] ActivityInitial

Existuje klientská databáze? Načtení konfiguračních údaj ů

[Ano]

[Ne]

[Ne]

Zobrazení chybov é hlášky

Iniciální synchronizace

Spuštění hlav ního okna

ActivityFinal

Obrázek 4-10 Diagram aktivity – Spuštění systému

4.6.3 Datový model Datový model zobrazený v příloze se skládá z tabulek C_SKLADY, CENZBOZ, DODZBOZ a SUPPORT. Všechny tabulky kromě SUPPORT, jsou obsaţeny v klientské i serverové databázi a probíhá na nich synchronizace. Tabulka SUPPORT slouţí pro správné zobrazení interního čísla dodacího listu a je obsaţena pouze v klientské databázi. Datový model je zobrazen v příloze B.

- 41 -

4.7 Rozbor výběru klientského zařízení Na základě poţadavků zadavatele na klientské zařízení bylo vybráno několik zařízení a ty následně porovnány, aby mohlo být vybráno jedno nejlépe vyhovující zařízení. Tabulka 4-3 – v prvním sloupci jsou uvedeny parametry k porovnání a v dalších sloupcích jednotlivé porovnávané zařízení. Parametry\ zařízení

Falcon 4400

Psion teklogix

Casio DT-X7

7530 G2

Motorola MC3090

Hmotnost (g)

660

145

1060

384

Operační systém

Windows CE 5.0 nebo Windows Mobile 6.x

Windows CE 5.0

Windows CE 5.0

Windows CE 5.0 nebo Windows Mobile 6.X

Procesor

PXA255-400MHz

PXA270-416MHz

PXA270-520MHz

PXA270-520MHz

Paměť (ROM)

128 MB

64 MB

64 MB

64 MB

Snímání

80-5330mm

40-400mm

?

?

Baterie (mAh)

2400

1100

1900

2740

barevný LCD,

barevný LCD,

Barevný LCD,

320x240

240x320

240x320

barevný LCD, 320x320

Odolnost

IP54

IP54

IP67

IP54

Komunikace

802.11b/g, bluetooth

802.11b/g, bluetooth, IrDA

802.11b/g, bluetooth

802.11a/b/g, bluetooth

Displej

Tabulka 4-3 Porovnání mobilních zařízení umoţňující snímání čárového kódu

Jak ukazuje Tabulka 4-3, tak nejlépe z hodnocení vychází zařízení Motorola MC3090, tomuto zařízení nahrává také fakt, ţe je k dispozici vývojový balík pro platformu .NET zahrnující knihovny nutné pro práci se snímáním, ale také velké mnoţství předpřipravených ukázkových aplikací z nichţ se dají některé třídy rovnou pouţít.

- 42 -

- 43 -

5 IMPLEMENTACE „Jakmile se něco stane složitým, zjednodušte to. Nemůžete-li to zjednodušit, zrušte to!“ Richard Koch Po části analýzy a návrhu následuje část implementace. Jiţ je rozhodnuto o pouţitých nástrojích a technologiích. V rámci návrhu aplikace bylo namodelováno spoustu diagramů, jeţ popisují celý systém. Na základě diagramů a jejich popisu se nyní budou implementovat jednotlivé části systému. Systém je rozdělen na klientskou a serverovou část, kaţdá bude popsána zvlášť. Nejdříve ale následuje popis pouţitých nástrojů a technologií.

5.1 Pouţité nástroje a technologie Jelikoţ bylo vybráno klientské zařízení Motorola MC3090 s operačním systémem Windows CE, byla tím pádem určena i vývojová platforma a to .NET Compact Framework. S určením vývojové platformy se rovnou nabízí pouţití vývojového prostředí Visual Studio jeţ je určeno právě pro vývoj aplikací pro platformu .NET. V rámci mnoha projektů společnosti Microsoft je jeden vyvíjen za účelem synchronizace různých zdrojů mezi různými zařízeními a nese označení Microsoft Sync Framework, ten byl vybrán pro obslouţení synchronizace mezi klientem a serverem. Serverová databáze je dána zákazníkem, jelikoţ jiţ vyuţívá Advantage Database Server a klientská databáze je dána pouţitím synchronizačního frameworku, který spolupracuje s SQL Server Compact Edition. Dále jsou rozebrány jednotlivé nástroje a technologie:

5.1.1 .NET platforma .NET Framework je zastřešující název pro soubor technologií v softwarových produktech, které tvoří celou platformu, dostupnou nejen pro Web, Windows, ale i Pocket PC. Common Language Infrastructure je standardizovaná specifikace jádra .NET. Základem je snaha sjednotit více technologií v jeden robustní celek. Základní komponentou je Microsoft .NET Framework, prostředí potřebné pro běh aplikací a nabízející jak spouštěcí rozhraní, tak potřebné knihovny. Programátoři tak mohou realizovat své projekty v jakémkoliv jazyce podporujícím CLR, např. Visual Basic.NET, JScript.NET, C#, Managed C++, ale i mutace Perlu, Pythonu a další.

- 44 -

Obrázek 5-1 Struktura celého .NET frameworku (9)

BCL - Base Class Library Base Class Library (BCL) je knihovna obsahující nejčastější pomocné funkce – práci se soubory, třídění, diagnostiku, síťovou komunikaci apod. ADO.NET je knihovna pro práci s daty s moţností jejich XML reprezentace. Dále jsou na obrázku dvě knihovny pro vývoj uţivatelského rozhraní – Windows Forms pro desktop aplikace a ASP.NET pro webové uţivatelské rozhraní. CLR – Common Language Runtime Common Language Runtime je základním kamenem .NET Framework, jak jiţ bylo naznačeno na obrázku výše. CLR je to implementace standardu Common Language Infrastructure (CLI) firmou Microsoft, která definuje prostředí pro vykonávání programového kódu. V rámci projektu je pouţita verze .NET 3.5.

5.1.2 .NET Compact Framework Jak jiţ bylo několikrát uvedeno je .NET Compact Framework pozměněná a zmenšená verze .NET Framework, určená pro vývoj mobilních aplikací. .NET Compact Framework pouţívá některé stejné knihovní třídy jako .NET Framework, ale také speciálně upravené třídy, pro práci s mobilním zařízením jako je např. knihovna InputPanel. Aplikace, které vyuţívají .NET Compact Framework je moţné vyvíjet ve Visual Studiu od verze Visual Studio.NET 2003 aţ po nejnovější Visual Studio 2008 v programovacích jazycích C# a Visual Basic.NET. Aplikace nebo lépe řečeno její zdrojový

- 45 -

kód prochází naprosto stejným procesem jako byl popsán u .NET Frameworku při tvorbě aplikací pro stolní a serverové počítače. Výsledná aplikace je připravena běţet na speciálním JIT kompileru, který je součástí .NET Compact Framework. Z předešlé věty vyplývá, ţe aplikace vyvinuté pod .NET CF, poběţí pouze na zařízeních, které podporují běhové prostředí .NET CF, coţ jsou v současnosti Windows Mobile, Pocket PC a Windows CE. V .NET CF byly zachovány všechny přednosti .NET Framework, ovšem s příslušnými modifikacemi pro mobilní zařízení, tak aby zabíraly co nejméně místa, byly nenáročné na paměť a vyuţívaly co nejvíce moţností mobilních zařízení. Proto byl v úvodu tolik rozebrán .NET Framework. .NET CF jiţ jen vyuţívá vlastností .NET Framework, jako je např. CLR a další. Přehled architektury je naznačen na obrázku Obrázek 5-2.

Obrázek 5-2 .NET Compact Framework architektura platformy (10)

Práce s daty v .NET CF 3.5 je podobná práci s daty v .NET Framework. ADO.NET12 je téměř plně podporován. Co se týče databází, tak je podporován Microsoft SQL Server Compact, který je uzpůsoben právě pro mobilní zařízení.

5.1.3 Microsoft Sync Framework Sync Framework je synchronizační platforma umoţňující spolupráci pro „offline― aplikace, sluţby a zařízení. Synchronizovat se můţou jakékoliv data z jakéhokoliv zdroje přes jakýkoliv protokol po jakékoliv síti, vše se samozřejmě musí brát v kontextu softwarových aplikací. Základem frameworku jsou „providers― (poskytovatelé), jeţ si kaţdý můţe naimplementovat vlastní a budou tak podporovat jeho infrastrukturu, tím je zaručeno široká

12

Technologie přístupu k datům vyuţívající .NET Framework.

- 46 -

moţnost pouţití. Několik hlavních „providers― je jiţ implementováno a lze je tak vyuţít, jsou to například SQL Server Provider, Oracle Provider a další se dají stáhnout jako například Advantage .NET Data Provider. Sync Framework je dále rozdělen podle toho jaký obsah z jakého zdroje synchronizujeme a to na synchronizaci databází, souborů a webových komponent.

Obrázek 5-3 Ukázka moţných zařízení k synchronizování (11)

Po poskytovatelích je v samotné synchronizaci další důleţitý prvek a to tzv. účastník (participant). Účastník je identifikován poskytovatelem a „obrazem― (replica). Replica je vlastně úloţiště informací resp. jeho identifikace, které budeme synchronizovat. Můţe se jednat o sloţku na flash disku, webovou sluţbu či klidně jeden soubor. Účastníky rozdělujeme do tří kategorií, neboť ne všechna zařízení nebo zdroje mají stejné schopnosti:  Úplný účastník (full participant) je zařízení, které dokáţe ukládat přímo k sobě data a dovoluje spouštět aplikace (na sobě). Klasická ukázka je počítač, PDA atp.  Částečný účastník (partial participant) naproti tomu, je zařízení, které dokáţe pouze data ukládat. Musí však umět ukládat i metadata potřebná k synchronizaci. Můţe se tedy jednat o flash disk, MP3 přehrávač atp.  Jednoduchý účastník (simple participant) je nejjednodušší forma. Dokáţe pouze data poskytovat. Nejde na něj data ukládat (z pohledu aplikace). Typickou ukázkou je RSS feed či jednoduchá webová sluţba.

- 47 -

Z výše uvedeného vyplývá, ţe k fungování synchronizace je zapotřebí alespoň jednoho úplného účastníka, poté je další typ a počet zařízení (sluţeb) libovolný. Při synchronizaci je nutné ukládat metadata, jeţ jsou základním kamenem synchronizace a slouţí pro rozhodování při synchronizaci a napomáhají řešit konflikty. Metadata mohou být uloţena kdekoliv, ale v základu implementace jsou uloţeny v databázi SQL Server Compact Edition a obsahují tři podstatné části:  Verze (version) ukládaná u kaţdé synchronizované poloţky. Ukládaná je tzv. „creation version― a „update version―.  Znalost (knowledge) je úsporná informace o změnách v synchronizovaných poloţkách, zvyšuje tak efektivitu synchronizace.  Náhrobky (tombstone) slouţí k udrţování informací o poloţkách, které byly odstraněny. Tyto informace stále narůstají, proto je nutné čas od času tyto údaje pročistit.

Obrázek 5-4 Ukázka architektury komunikace při synchronizaci (11)

Synchronizace můţe probíhat třemi způsoby a to podle směru synchronizace:  „Snapshot sync― (pouze staţení), data ze zdroje (nebo jejich podmnoţina) jsou synchronizovány (staţeny) s klientem.  „Upload-only sync― (pouze nahrání), data z klienta jsou synchronizována (nahrána) se zdrojem  „Bidirectional sync― (obousměrné), data ve zdroji i na klientovi jsou synchronizována

- 48 -

Základní informace o Microsoft Sync Framework napsané v češtině lze nalézt na internetovém portálu Vyvojar (12).

5.1.4 Visual Studio Visual Studio je vývojové prostředí určené pro vývoj aplikací pro operační systémy Microsoft Windows, Windows Mobile a Windows CE. Aplikace je moţné vyvíjet na platformách .NET, .NET CF a Mirosoft Silverlight. Visual Studio podporuje jazyky pomocí jazykových sluţeb, coţ umoţňuje podporu jakéhokoliv programovacího jazyka, jeţ podporuje zmíněné jazykové sluţby. Jazykové sluţby daného programovacího jazyka jsou do Visual Studia instalovány pomocí přídavných balíčků. Obsahuje mnoho nástrojů usnadňující vývoj, ladění chyb, testování i návrh aplikace. V projektu je pouţitá verze Visual Studio Professional 2008.

5.1.5 Advantage Data Architect Advantage Data Architect je nástroj pouţívaný k zefektivnění vývoje a údrţby Advantage databázových aplikací. Tento nástroj umoţňuje mnoho uţitečných věcí, jak při vývoji, konfiguraci, či správě databázových aplikací. Následuje jejich výčet:  vytvořit a udrţovat Advantage Data Dictionaries (datové slovníky)  importovat ostatní typy tabulek (jako je Paradox, Btrieve, Access, a další) do Advantage kompatibilních tabulek  vytvářet tabulky a indexy  měnit strukturu existujících tabulek  zašifrovat a dešifrovat tabulky a slovníky  generovat a testovat Advantage SQL dotazy  testovat ODBC SQL dotazy  testování klientského prostředí, tak aby se předešlo problémům při připojování k Advantage Database Server  spravovat datový slovník  spravovat aktivitu Advantage Database Serveru  vykonávat údrţbové transakce Další podrobné informace lze nalézt například v (13).

- 49 -

Nástroj v rámci projektu slouţil zejména k prohlíţení databáze na serveru a její úpravě při vývoji a dále pak při testování se zde kontrolovala testovaná data.

5.1.6 Programovací jazyk C# Na základě vybrané platformy .NET Framework byl pro implementaci zvolen objektový programovací jazyk C#. Jazyk C# vyvinula firma Microsoft. Byl představen spolu s celým vývojovým prostředím .NET. Výborný úvod do základů jazyka C# popisuje Běhálek Marek v (14). Více informací o správném pouţití jazyka najdeme v dokumentaci (15).

5.1.7 Databáze SQL Server Compact Edition (SQL Server CE) SQL Server Compact Edition je jak sám název napovídá kompaktní relační databáze od společnosti Microsoft pro aplikace běţící na mobilních („embeded―) zařízeních a PC. Pouţívá se především pro menší aplikace, kde není nutné ukládat milióny záznamů. Databázový stroj běţí jako proces v rámci aplikace a databázi představuje pouze jeden soubor s příponou .sdf. „Runtime― kompaktního SQL Serveru zabírá pouze 1,7 MB a po jeho instalaci můţou všechny aplikace na daném zařízení vyuţívat sluţby dané databáze. Jeden databázový soubor můţe mít velikost aţ 4 GB. SQL Server CE nabízí především:  pouţití a distribuce je zdarma  podpora mobilních zařízení  není nutná administrace  podpora mnoho jednoduchých instalačních metod  podporuje podmnoţinu Transaction-SQL syntaxe a SQL Server datových typů  integrace s Visual Studiem V této edici databáze nejsou k dispozici uloţené procedury, pohledy či triggery, více k nalezení v (16) a (17). V projektu je pouţita verze SQL Server Compact Edition 3.5 a slouţí jako databáze na klientském zařízení.

- 50 -

Advantage Database Server (ADS) Advantage Database Server je plně vybavený SŘBD (systém řízení báze dat) z dílny Sybase iAnywhere, coţ je dnes součást společnosti Sybase. Unikátnost ADS spočívá v podpoře typu tabulek „Index Sequential Access Method― (ISAM) a SQL datového přístupu. ADS je určen pro menší aţ střední objemy dat, poskytuje podobné moţnosti jako ostatní databázové stroje a to:  replikaci  online zálohování  pohledy  uloţené procedury  transakce  „ful-text― vyhledávání  krytování indexů a komunikace  a další Správa databázového stroje je snadná a není jí mnoho, není potřeba databázový administrátor jako u jiných SŘDB. ADS má ve skutečnosti dva databázové stroje: lokální a vzdálený. Lokální stroj není opravdový databázový server, protoţe pouţívá souborově orientovaný přístup k datům. Vyuţívá „in-process― knihovnu DLL, která se načte do ODBC driveru na klientském počítači. Vzdálený stroj je opravdový databázový server poskytující všechny výhody architektury klient/server. Advantage Local Server je uţitečný pro testování, pro samostatného vývojáře nebo jako levný (je totiţ zadarmo) databázový stroj pro komerční aplikace, má však oproti Advantage Remote Serveru několik důleţitých omezení. Jeho přínosem je zejména to, ţe zajišťuje mechanismus klient/server, který pak lze v případě potřeby snadno aplikovat na plnohodnotném vzdáleném serveru, ke kterému se dá mimochodem přistupovat i po Internetu, je-li to třeba. Pro vyšší bezpečnost a výkon umoţňuje přenos zašifrovaných a zkomprimovaných dat. Jednou z nejzajímavějších vlastností ADS je, ţe můţe pracovat s daty uloţenými buď ve vlastním formátu (soubory s příponou ADT) nebo v souborech DBF.

- 51 -

Kompletní výčet vlastností, mnoho podpůrných materiálů a diskusní fóra, to vše lze nalézt v (18) nebo ve stručnějším podání v (19). ADS je pouţit u zákazníka jako databáze pro stávající aplikaci A_System++ a nyní v rámci projektu je klientská databáze SQL Server CE synchronizována právě s databází ADS.

5.2 Klientská část Aplikace A_Terminal++ je z velké části tvořena právě klientskou části, která představuje obrazovky pro správu příjmu a výdeje, dále umoţňuje synchronizaci se serverem a v neposlední řadě obsahuje lokální datové úloţiště. Celá klientská část je spouštěna a uloţena na klientském zařízení (Motorola MC3090 – čtečka čárových kódů), proto je vývojový projekt zaloţen ve Visual Studiu jako projekt pro vývoj mobilní aplikace s pouţitím frameworku .NET CF 3.5 pro cílový operační systém Windows CE 5.013.

Obrázek 5-5 Zařízení pro snímání čárových kódů MC3090 (26)

13

Samotná implementace aţ na pouţití specifických částí .NET CF probíhá bez určení cílového operačního systému (OS), poněvadţ aplikace napsané v .NET CF běţí na všech mobilních operačních systémech od Microsoftu. Výběr konkrétního OS je důleţitý aţ pro samotné spuštění a zobrazení, poněvadţ různé zařízení (různé OS), nabízejí různé velikosti obrazovek, různé tlačítka, dotykový či nedotykový displej atp.

- 52 -

V následujících podkapitolách jsou popsány jednotlivé vrstvy aplikace a vyzdvihnuty zvláštnosti pouţitého řešení.

5.2.1 Prezentační vrstva S pouţitím .NET CF se také ve Visual Studiu omezily nástroje pro vývoj GUI, jako jsou komponenty, z nichţ se můţou skládat jednotlivé obrazovky aplikace a na ně navázaná logika jako např. handlery událostí. Kód obrazovek aplikace (jako i ostatní obrazovky vyvíjené pomocí Windows Forms komponent .NET Frameworku) je rozdělen na dva soubory14. Jeden obsahuje kód pro vlastní vytvoření obrazovky, jeţ obsahuje komponenty (panely, layouty, tlačítka, textboxy a další) a definování jejich vlastností. Druhý soubor obsahuje obsluţnou logiku pro obrazovku. Při implementaci byly jednotlivé obrazovky sestaveny přetaţením komponent z panelu „Toolbox― ve Visual Studiu, dále jim byly definovány rozličné vlastnosti, aby obrazovky působily přívětivě pro pouţití na tak specifickém zařízení a nakonec byla ošetřena logika skrývající se za akcemi, které uţivatel mohl na obrazovce provést. Jelikoţ uţivatel v průběhu práce s aplikací zadává údaje, na kterých se provádí další operace nebo se ukládají do databáze, je nutné provádět validace vstupních údajů. Validace byly pouţity zejména pro ošetření zadání číselné hodnoty do číselného pole. Ověření hodnot probíhalo v handlerech příslušných událostí a při neúspěchu validace se uţivateli na obrazovce zobrazuje hláška. Také byla validována povinnost některých polí.

5.2.2 Aplikační vrstva Za vstupní bod do aplikační vrstvy můţeme povaţovat main metodu, kde se načítají konfigurační soubory, ověřuje se dostupnost klientské databáze, případně pokud databáze neexistuje, vytvoří se nová a proběhne iniciální synchronizace (resp. stáhnutí dat do lokální databáze ze serveru). V případě chyb dochází k logování těchto událostí do samostatného souboru. Z main metody je také instanciována první obrazovka a poté provedeno samotné její zobrazení a tím spuštění aplikace (viditelné pro uţivatele).

14

Ve skutečnosti se vytvoří tři, třetí soubor slouţí pro definování rozličných zdrojů pouţitých na obrazovce.

- 53 -

Aplikační logika představuje vlastně tzv. business logiku15 a to v aplikaci A_Terminal++ zahrnuje implementaci snímání čárového kódu, obslouţení logiky při zpracovávání těchto dat a i samotnou logiku nutnou pro proces příjmu a výdeje zboţí. Pro implementaci snímání čárových kódů byl pouţit pomocný vývojový balík pro .NET Framework poskytnutý výrobcem čtečky čárových kódů společností Motorola. Tento balík obsahoval knihovny Symbol.dll a Symbol.Barcode.dll nutné pro komunikaci se zařízením resp. se snímačem čárových kódů, dále pomocné ukázkové projekty, z kterých je převzata třída implementující obsluhu snímání v projektu A_Terminal++. Ze zmíněného balíku je pouţita ještě jedna třída a to pro správné nastavení velikosti oken na zařízení. // Create new reader, first available reader will be used. this.MyReader = new Symbol.Barcode.Reader(); // Create reader data this.MyReaderData = new Symbol.Barcode.ReaderData( Symbol.Barcode.ReaderDataTypes.Text, Symbol.Barcode.ReaderDataLengths.MaximumLabel);

Tabulka 5-1 Ukázka práce s knihovnou Symbol

Podstatná část synchronizační logiky byla vygenerována sama Visual Studiem, kdy se pomocí „wizardu―, zvolila zdrojová databáze (databáze na serveru) a z ní se vybraly synchronizující se tabulky případně jejich podmnoţiny, poté se definovaly další vlastnosti synchronizace (typ synchronizace na tabulkách, atp.). Ještě předtím bylo ovšem nutné do projektu přidat WCF sluţbu, která zprostředkovává komunikaci mezi klientem a serverem. Výsledkem celého procesu klikání pomocí „wizardů― bylo vygenerování několika tříd pro synchronizaci, webové sluţby a vytvoření zcela nového projektu, který představoval serverovou část synchronizace. Celý zde uvedený proces vytvoření projektu s vygenerovanými třídami, sluţbou a novým projektem je podrobně popsán v (20). Po vygenerování logiky pro synchronizaci jiţ jen stačilo nastavit konfigurační údaje a z kódu projektu zavolat samotné spuštění synchronizace, tím byla strana klienta připravena k synchronizaci. Implementace logiky k procesu příjmu a výdeje probíhala většinou přímo v kódu jednotlivých obrazovek (v části pro obsluhu uţivatelských akcí).

15

Funkce definované zákazníkem, rozkreslené pomocí UML diagramů a implementované aplikací.

- 54 -

5.2.3 Fyzická vrstva Jako fyzická vrstva je u klienta pouţita databáze SQL Server CE. Práce s databází v aplikaci je zprostředkována pomocí komponenty .NET Frameworku - ADO.NET. ADO.NET představuje sadu jednotících tříd nabízející sluţby pro práci s daty, jsou to například objekty Connection, Command či DataSet, jeţ jsou pro kaţdou databázi implementovány zvlášť prostřednictvím „providers― (poskytovatelů). Datové schéma, s nímţ se pracuje v kódu aplikace, je vytvořeno pomocí nástrojů Visual Studia z klientské databáze. V aplikaci se pracuje s daty, které jsou jednou dotaţeny z databáze a poté se uchovávají v paměti aţ do doby explicitního uloţení do databáze, tento způsob zaručuje rychlejší přístup k datům a je zprostředkován pomocí objektů DataSet a SqlDataAdapter. DataSet představuje reprezentaci „offline― dat v paměti, můţe obsahovat i více tabulek reprezentovaných jako objekty DataTable a navíc definuje i vazby mezi těmito tabulkami. Abychom mohli s tabulkami (resp. daty) z DataSet pracovat, musíme pomocí objektů SqlDataAdapter (co tabulka, to objekt SqlDataAdapter) definovat spojení na databázi a můţeme také rovnou pomocí tohoto objektu vytvořit sql dotazy (buď obecné generované Visual Studiem nebo specifické napsané individuálně). Při implementaci byl vytvořen jeden DataSet AterminalDS obsahující následující tabulky:  CENZBOZ – podmnoţina serverové tabulky; synchronizují se data pouze ze serveru na klienta („download sync―)  DODZBOZ – podmnoţina serverové tabulky; synchronizují se data pouze ze serveru na klienta („download sync―)  DODTERM – nově vytvářená tabulka pro aplikaci A_Terminal++; v průběhu implementace byla funkcionalita, která ji vyuţívala odloţena do dalších verzí a tím pádem není tabulka vyuţita  C_SKLADY – podmnoţina serverové tabulky; synchronizují se data pouze ze serveru na klienta („download sync―)  PVPterm – nově vytvářená tabulka pro aplikaci A_Terminal++; synchronizují se data z klienta na server („upload sync―)

- 55 -

 pohyb – tabulka vytvořená16 pro lepší práci s daty v aplikaci; data jsou udrţována pouze v paměti, nemá ekvivalent ani v klientské ani v serverové databázi Pro jednotlivé tabulky byly vytvořeny objekty SqlDataAdapter pro správu dat nad tabulkou (resp. tabulkami). V samotné aplikaci se tak volají pouze funkce SqlDataAdapteru, které definují samotné SQL dotazy. Modelovací nástroje pro přístup k datům, tak usnadnily práci s daty v kódu aplikace. Kvůli internímu dodacímu číslu sloţeného mimo jiné z pořadového čísla přijaté zakázky, bylo nutné vytvořit pomocnou tabulku Support s dvěma sloupci (maximální číslo přijaté zakázky, interní číslo dodacího listu), které se pravidelně aktualizovaly.

5.3 Serverová část Část aplikace instalované na serveru, představuje WCF sluţbu (webová sluţba), jeţ je spuštěna jako klasická sluţba operačního systému Windows. Tato sluţba čeká na příchozí poţadavek od klienta na synchronizaci a poté co jej obdrţí, provede počáteční zpracování informací, z kterých se doví, jaké data se mají posílat na klienta a jaké na server. Vývojový projekt této sluţby byl vygenerován Visual Studiem při vytváření synchronizační architektury pro klienta.

5.3.1 Prezentační vrstva Serverová část aplikace neobsahuje ţádné uţivatelské rozhraní, jediný zásah uţivatele na serverovou část je změna údajů v konfiguračním souboru sluţby. V tomto souboru se nastavuje adresa databázového serveru, jméno databáze a další její parametry a v neposlední řadě adresa, na které je vystavena webová sluţba. Do konfiguračního souboru sluţbu byly také umístěny parametry rozlišující působnost pouţití jednotlivých klientských zařízení, neboť je zařízení pouţíváno v určitých skladech, které mají jednoznačný identifikátor, podle něhoţ se v konfiguračním souboru filtruje.

16

V podstatě se jedná o vytvořený pohled v nástroji Visual Studia, ale se všemi moţnostmi jako normální tabulka.

- 56 -

5.3.2 Aplikační vrstva Serverová část slouţí pouze k obsluze synchronizace a proto i logika celé části se smrskla na několik vygenerovaných souborů. Tento vytvořený projekt Visual Studiem ovšem sám o sobě nelze spustit ani instalovat jako sluţbu či něco jiného, bylo proto nutné vytvořit pomocí Visual Studia další navázané projekty. První z nich umoţňuje synchronizační logiku zabalit jako sluţbu a druhý návazný projekt jiţ jen umoţnil z této části udělat instalační balíček pro pohodlnou obsluhu při dodání. Oba tyto navázané projekty nebylo nutné velmi upravovat, pouze se přidaly parametry instalačního balíčku, jako je cesta, kam bude sluţba nainstalována, zda se má sluţba po instalaci sama spustit, atp.

5.3.3 Fyzická vrstva Sluţba vyuţívá připojení k stávající serverové databázi ADS, z čehoţ vyplynulo několik změn. Vygenerované třídy serverové sluţby bylo nutné upravit, poněvadţ „wizard― vytváření synchronizační logiky nepodporoval jako serverovou databázi ADS a tak se muselo implementovat mapování sloupců ADS databáze na SQL Server CE. Jako další problém se ukázalo vygenerované ošetření záznamu času synchronizace pomocí speciálních konstruktů SQL Server databáze (ty byly generovány Visual Studiem a jako default serverová databáze byl vybrán SQL Server), bylo tedy nutné implementovat tuto funkčnost pomocí ADS. Řešení se našlo v podobě přidání AdsHelper knihovny17 a vyuţití jejich metod pro suplování SQL Server konstruktů. Posledním zásahem do vygenerovaného kódu z hlediska práce s daty bylo ošetření synchronizace podle zadaných parametrů (identifikace zařízení = typ skladu, kde se zařízení pouţívá). S pouţitím synchronizace souvisely také zásahy do ADS databáze:  vytvoření nových tabulek („tombstone― – uchovávají informace o smazaných záznamech)  přidání nových sloupců do synchronizovaných tabulek; sloupce obsahují informace nutné pro správný běh synchronizace  vytvoření „triggerů― pro vytváření záznamů do „tombstone― tabulek

17

Knihovna poskytovaná společností Sybase pro usnadnění práce s daty v prostředí .NET.

- 57 -

5.4 Synchronizace Synchronizace představuje nejzajímavější část implementace aplikace A_Terminal++. Pouţitý Microsoft Sync Framework do velké míry usnadňuje práci vývojáře. V rámci synchronizace byla implementována WCF sluţba, která je nutná pro obsluhu komunikace mezi databázemi, poněvadţ framework nedovoluje přímé spojení mezi databázemi. WCF je navrhnuto dle zásad SOA (Service-oriented architecture) a komunikace s klientem či mezi sluţbami samotnými probíhá prostřednictvím SOAP18 zpráv, které jsou nezávislé na přenosovém protokolu. Sluţba s klientem nikdy nekomunikuje přímo, ale vţdy komunikují prostřednictvím proxy19, tím je zaručena jednotná komunikace s jakýmkoliv klientem či sluţbou. cmp Synchronization

Serv er Synchronization Session

SSP Interface

SPP Interface Klient

Serv er Synchronization Prov ider

Synchronization Proxy Prov ider «delegate» WCF

WCF

Synchronization Runtime

Client Synchronization Prov ider

Synchronization Runtime

Adv antage Database Serv er

Sql Serv er Compact Edition

Obrázek 5-6 Pohled na architekturu synchronizace v aplikaci A_Terminal++

Server Na serverové části aplikace tedy běţí WCF sluţba na příslušném portu a ip adrese. WCF se zavede do systému pomocí klasické windows sluţby. Implementace windows sluţby i WCF sluţby byla přímočará díky návodu (20) a je tvořena dvěma závislými projekty.

18

SOAP je specifikace protokolu pro výměnu strukturovaných informací implementovaných webowými sluţbami v počítačových sítích. 19 Proxy v programování je softwarový návrhový vzor. Obecně funguje jako interface k dalšímu pouţití.

- 58 -

Implementování windows sluţby obnášelo vytvoření projektu typu Windows Service s názvem WinSyncService. Tento projekt implementuje spuštění windows service a v rámci spouštěcí metody je získána reference na WCF sluţbu a tím její zavedení do systému. Projekt s názvem SyncService implementuje WCF sluţbu a třídu potřebnou synchronizačním frameworkem. Třída AterminalCache.SyncContract.cs implementuje WCF sluţbu lépe řečeno interface pro komunikaci s okolím. Třída AterminalCache.Designer.cs obsahuje informace nutné ke správnému provedení synchronizace, např. mapování datových typů serverové databáze na klientskou, popis sql dotazů, které se provedou do serverové databáze a další. A v neposlední řadě je to AterminalCache.sync soubor, coţ je xml konfigurační popis synchronizace. Klient Na straně klienta jsou součástí synchronizace soubory AterminalCache.Client.sync a AterminalCache.Client.cs. Soubor AterminalCache.Client.sync představuje xml popis konfigurace potřebné pro synchronizaci, tento soubor je generován nástrojem Visual Studia na základě informací zadaných v průběhu procházení „wizardu― pro vytvoření synchronizace.

Třída

AterminalCache.Client.cs

implementuje

potřebné

věci

pro

synchronizaci jako je tzv. „synchronization agent―, ten zajišťuje projítí všech synchronizovaných tabulek a volání klientského poskytovatele synchronizace (client synchronization provider), jenţ provádí změny do klientské databáze. Dále je to implementace klientského poskytovatele synchronizace, který se stará o odstínění synchronizačního agenta od konkrétní implementace klientské databáze. Tento poskytovatel tak obstarává provedení příslušných operací při změně dat při synchronizaci a také řeší konflikty. Následuje ukázka metody (handleru) volané při stisku tlačítka Synchronizovat Tabulka 5-2.

- 59 -

private void menuItmSync_Click(object sender, EventArgs e) { Cursor.Current = Cursors.WaitCursor; // The WCF Service AtermCacheWebRef.AterminalCacheSyncService webSvcProxy = new terminal.AtermCacheWebRef.AterminalCacheSyncService(); webSvcProxy.Url = "http://" + Program.serviceIP + "/AterminalCacheSyncService/"; // The Remote Server Provider Proxy Microsoft.Synchronization.Data.ServerSyncProviderProxy serverProvider = new Microsoft.Synchronization.Data.ServerSyncProviderProxy(webSvcProxy); // The Sync Agent AterminalCacheSyncAgent syncAgent = new AterminalCacheSyncAgent(); syncAgent.RemoteProvider = serverProvider; syncAgent.SyncInBackground = false; // Add synchronize parameters syncAgent.Configuration.SyncParameters.Add(new Microsoft.Synchronization.Data.SyncParameter(":nUsrIdDBTe", Program.nUsrIdDBTe)); syncAgent.Configuration.SyncParameters.Add(new Microsoft.Synchronization.Data.SyncParameter(":fillDatabase", false)); // Register event handler SqlCeClientSyncProvider cp = (SqlCeClientSyncProvider)syncAgent.LocalProvider; cp.ApplyChangeFailed += new EventHandler<ApplyChangeFailedEventArgs>(cp_ApplyChangeFailed); // Synchronize the databases try { //Synchronizing Microsoft.Synchronization.Data.SyncStatistics stats = syncAgent.Synchronize(); MessageBox.Show("Synchronizace provedena úspěšně."); // Reload the DataSet/Datagrid from the local database if (stats.UploadChangesApplied > 0) { PVPtermTA.DeleteAll(); PVPtermTA.Fill(AterminalDS.PVPterm); } // Write synchronization statistics to log file Program.WriteToLog(Program.SYNCHRO_STATS, this.Name + "-menuItmSync_Click", "Downloaded OK: " + stats.DownloadChangesApplied.ToString() + "\r\n" + "Downloaded Failed: " + stats.DownloadChangesFailed.ToString() + "\r\n" + "Uploaded OK: " + stats.UploadChangesApplied.ToString() + "\r\n" + "Changes Downloaded: " + stats.TotalChangesDownloaded.ToString() + "\r\n" + "Changes Uploaded: " + stats.TotalChangesUploaded.ToString(), ""); } catch (System.Reflection.TargetInvocationException err) { Program.WriteToLog(Program.SYNCHRO, this.Name + "-menuItmSync_Click", err.InnerException.Message, err.StackTrace); MessageBox.Show("Synchronizace neproběhla v pořádku.", "Chyba", MessageBoxButtons.OK, MessageBoxIcon.Hand, MessageBoxDefaultButton.Button1); } catch (System.InvalidCastException err) { Program.WriteToLog(Program.SYNCHRO, this.Name + "-menuItmSync_Click", err.InnerException.Message, err.StackTrace); MessageBox.Show("Synchronizace neproběhla v pořádku.", "Chyba", MessageBoxButtons.OK, MessageBoxIcon.Hand, MessageBoxDefaultButton.Button1); } Cursor.Current = Cursors.Default; }

Tabulka 5-2 Ukázka klientské metody pro spuštění synchronizace

- 60 -

5.5 Ukázka uţivatelského rozhraní Následuje ukázka z uţivatelského rozhraní, zachycuje podstatné obrazovky aplikace. Aplikace obsahuje ještě přechodové dialogy mezi obrazovkou příjmu/výdeje a formulářem příjmu/výdeje.

Obrázek 5-7 Obrazovka po spuštění aplikace

Obrázek 5-8 Obrazovka příjmu – seznam přijatých poloţek

- 61 -

Obrázek 5-9 Formulář výdej - zádávání čárového kódu

Obrázek 5-10 Formulář výdej - načtené údaje podle čárového kódu

- 62 -

Obrázek 5-11 Formulář příjem - zadávání dodatečných údajů

Obrázek 5-12 Formulář příjem - validace na povinné pole

- 63 -

- 64 -

6 TESTOVÁNÍ „Nevěř ničemu, ani tomu, co říkám já. Věř jen tomu, co si sám ověříš.“ Buddha V rámci testování aplikace proběhli testy kognitivním průchodem a poté testy pouţitelnosti a to zejména kvůli specifičnosti pouţitého zařízení, kdy je kladen důraz na pohodlí uţivatele při ovládání aplikace.

6.1 Testování kognitivním průchodem Kognitivní průchod vychází z modelu případně prototypu artefaktu a pomocí uţivatele20 se snaţí nalézt nedostatky zkoumaného artefaktu. Uţivateli je specifikován cíl a zkoumá se, jestli je ho schopen intuitivně pomocí artefaktu dosáhnout. Vychází se přitom ze srovnání chování uţivatele (byť třeba simulovaného) s předpokládaným (předem daným a optimálním) sledem realizovaných akcí s artefaktem. V kaţdém kroku si pozorovatel (fiktivní uţivatel) klade následujcí otázky, které mají za cíl poukázat na to, kde má artefakt slabá místa, která brání uţivateli dosáhnout určeného cíle. 1. Stanoví si uţivatel správný cíl? 2. Je akce, kterou by měl uţivatel udělat, vidět? 3. Je akce správná? 4. Rozumí uţivatel zpětné vazbě?

6.1.1 Nastavení testů  Jako artefakt slouţí aplikace A_Terminal++  Pro průchod testy poslouţí úlohy (procesy) Příjem zboţí a Výdej zboţí. Úlohy budou dále členěny, např. Výdej zboží – přidat poožku  Sled operací při průchodu úkoly jsou popsány v následující kapitole 6.1.2

20

Uţivatele zde představuje samotný vývojář, či tester, jeţ se snaţí vţít do jeho situace. Kognitivní průchod je zaloţen na testování bez skutečných uţivatelů.

- 65 -

 Profil uţivatele – osoba, jeţ bude provádět průchod, by se měla vţít do situace skladníka s průměrnými technickými znalostmi, ale zato s dobrými znalostmi oboru

6.1.2 Průběh testů Procházely se dva procesy, kde kaţdý se skládal ze tří podúkolů podle předem daných scénářů (sledu operací). U kaţdé operace se zodpověděly čtyři otázky uvedené v kapitole 6.1, a pokud byla odpověď nejasná, provedl se záznam této nejasnosti. Vše je podrobně zobrazeno v Tabulka 6-1 aţ Tabulka 6-6.

Výdej zboží - přidat položku Krok operace (obrazovka)/otázka ot1 1. obr. základní ano 2. obr. výdej ano 3. obr. typ pohybu ano 4. obr. výdej-přidat položku ano 4.1. naplnění čárového kódu ano 4.2. změna dat ano 4.3a uložení dat ano 4.3b zavření obrazovky ano

ot2 ano ? ano ano ? ? ano ?

ot3 ano ? ano ano ? ? ? ?

ot4 ano ano ano ano ano ano ? ano

Tabulka 6-1 Kognitivní průchod - Výdej zboţí - přidat poloţku

krok 1. 2. 3. 3.1. 3.2a 3.2b

Výdej zboží - editace položky operace (obrazovka)/otázka ot1 obr. základní ano obr. výdej ano obr. výdej-editace položky ano změna dat ano uložení dat ano zavření obrazovky ano

ot2 ano ? ano ? ano ?

ot3 ano ? ano ? ano ?

ot4 ano ano ano ano ? ano

Tabulka 6-2 Kognitivní průchod - Výdej zboţí - editace poloţky

Výdej zboží - smazání položky krok operace (obrazovka)/otázka ot1 1. obr. základní ano 2. obr. výdej ? 3. obr. potvrzení smazaní ano

ot2 ano ano ano

ot3 ano ? ano

Tabulka 6-3 Kognitivní průchod - Výdej zboţí - smazání poloţky

- 66 -

ot4 ano ano ano

krok 1. 2. 3. 4. 4.1. 4.2. 4.3a 4.3b

Příjem zboží - přidat položku operace (obrazovka)/otázka ot1 obr. základní ano obr. příjem ano obr. typ pohybu ano obr. příjem-přidat položku ano naplnění čárového kódu ano změna dat ano uložení dat ano zavření obrazovky ano

ot2 ano ? ano ano ? ? ano ?

ot3 ano ? ano ano ? ? ? ?

ot4 ano ano ano ano ano ano ? ano

Tabulka 6-4 Kognitivní průchod - Příjem zboţí - přidat poloţku

krok 1. 2. 3. 3.1. 3.2a 3.2b

Příjem zboží - editace položky operace (obrazovka)/otázka ot1 obr. základní ano obr. příjem ano obr. příjem-editace položky ano změna dat ano uložení dat ano zavření obrazovky ano

ot2 ano ? ano ? ano ?

ot3 ano ? ano ? ano ?

ot4 ano ano ano ano ? ano

Tabulka 6-5 Kognitivní průchod - Příjem zboţí - editace poloţky

Příjem zboží - smazání položky krok operace (obrazovka)/otázka ot1 1. obr. základní ano 2. obr. příjem ? 3. obr. potvrzení smazaní ano

ot2 ano ano ano

ot3 ano ? ano

ot4 ano ano ano

Tabulka 6-6 Kognitivní průchod - Příjem zboţí - smazání poloţky

Příkladem popsání nejasnosti můţe být v Tabulka 6-6 druhý krok otázka jedna, kdy se ptáme, zda si uţivatel stanoví správný cíl. V tomto případě si má zvolit za cíl odstranění poloţky v seznamu pomocí tlačítka Zruš. Uţivatel se ale můţe domnívat, ţe nejprve musí danou poloţku vybrat, coţ ještě není špatně, naopak je to správný postup, ovšem v okamţiku vybírání se při dvojkliku na daný řádek otevře poloţka k editaci, coţ je špatně. Správný je jeden klik a poté zmáčknutí tlačítka Zruš. Další příklad je uveden pomocí obrázku Obrázek 6-1.

- 67 -

Obrázek 6-1 Ukázka nejasnosti při ukládání

6.1.3 Vyhodnocení testů Kognitivní průchod odhalil několik problémových míst, které se buď hned opravily, nebo se čekalo na potvrzení nejasností s daným místem na testy pouţitelnosti, kde se testovací scénáře procházely jiţ s reálnými uţivateli. Testování

kognitivními

průchody znamenalo

vcelku

nenáročné

otestování

uţivatelského rozhraní bez nutnosti mít k dispozici skutečné uţivatele, a proto se výborně hodí v období návrhu a počátcích implementace.

6.2 Testy pouţitelnosti - plánování 6.2.1 Účel testů Snaţím se získat odezvu od skutečných uţivatelů aplikace. Jako programátor nejsem schopen postihnout veškeré detaily, které se vyskytují v průběhu jednotlivých procesů. Reálný uţivatel tyto procesy v praxi pouţívá v odlišných podobách a aplikace má tyto procesy co moţná nejvíce simulovat a zefektivnit. Chování uţivatele a jeho kaţdodenní návyky pouţívané při výkonu práce jsou důleţitými informacemi pro vývoj efektivní a přívětivé aplikace.

- 68 -

Testování zjednodušuje odhalení nedostatků aplikace před samotným uvedením aplikace do ostrého provozu. Dále ověřuje také poţadavky kladené na aplikaci. Zákazník se můţe přesvědčit, ţe aplikace se vyvíjí, tak jak poţadoval.

6.2.2 Cíle testů Odpovědět na otázky, které jsem si sám pokládal při průchodu kognitivním testem. Kognitivní test mi dal základní kostru úloh, tyto úlohy (zejména jde o projití určitým procesem v aplikaci) budou slouţit jako základ testování. V průběhu řešení úloh vybranými uţivateli pro testování se zaznamená jejich reakce na zadané problémy. Tyto data budou dále zpracovány a vyhodnoceny. Získaná data by měly poskytnout dostatečné podklady pro odstranění chyb, vylepšení jednotlivých nedostatků a zejména získání reálné odezvy od skutečných uţivatelů, kdy programátor jiţ ví, jak jednotlivé procesy vnímá uţivatel. Získat pro další zlepšení důleţité informace od uţivatele ve formě dotazníku před testem, po testu a interview s uţivatelem, kdy sám subjektivně zhodnotí chování, ovládání, přehlednost a správnost aplikace. Také data získané z uvedených forem poslouţí ke zkvalitnění aplikace, tak aby splňovala nároky kladené zákazníkem. Z výše uvedeného vyplývá, ţe nejostřeji budou sledována místa, která byla označena při kognitivním průchodu za problematická. Dá se jiţ dopředu usuzovat, ţe s těmito místy budou mít testované osoby skutečně problémy, protoţe nebudou zajisté tak technicky zdatní.

6.2.3 Nastavení testů 6.2.3.1 Pouţité metody testování Pouţity budou tři ze základních metod testování a to: dotazník, interview a průchod procesů aplikace testerem (budoucím uţivatelem aplikace). Dále ke kaţdé metodě stručný popis. Dotazník Jde o tzv. pre-test a post-test, tyto testy (dotazníky) se provádí před samotným testováním (průchodem aplikace s testerem) resp. po testování. U pre-testu se snaţím získat prvotní informace o testeru a jeho názor, jak by si aplikaci představoval, co by očekával. Post-test by měl přinést informace testera po ukončení testování, tak aby se získaly jeho kladné či záporné zkušenosti s aplikací.

- 69 -

Interview Interview slouţí k získání informací, které nebylo moţno postihnout dotazníky, tzn. informace získané při rozhovoru testera s monitorem (osobou dohlíţející na testování). Interview poskytuje mnoţství informací, z kterých se musí při zpracování vybrat ty uţitečné. Jak jsem jiţ naznačil interview je velmi náročné na zpracování, ale poskytuje důleţité data pro další vývoj aplikace. 6.2.3.2 Průchod procesů aplikace testerem Jedná se o vlastní testování, kdy moderátor seznámí testera s jeho úkoly a tester pak sám (pouze v krajních případech s nápovědou moderátora) plní jednotlivé úkoly. Chování a prováděné akce testera jsou sledovány a zapisovány případné problémy. Z časových důvodů proběhly jen dva úkoly. Vymezený čas na zaměstnance jsem bohuţel nemohl ovlivnit. Splněné jsou úkoly:  Příjem zboţí  Výdej zboţí 1. Úkol – Příjem zboţí 1. Před sebou máte terminál s aplikací A_Terminal++. Aplikaci lze ovládat buď dotykem prstu nebo stylusem, v některých případech je nutné pouţít klávesnici zařízení. 2.

Přijměte zboţí, které máte před sebou. Uvedené tři zboţí přijměte bez opuštění obrazovky pro příjem. a. U zboţí č. 1 zadejte 5ks, číslo faktury 204 a cena 1ks je 3 260Kč. b. U zboţí č. 2 zadejte cenu 20Kč za kus, mnoţství 230ks, číslo faktury 100. c. U zboţí č. 3 zadejte cenu 30 028Kč za kus, mnoţství 2ks, číslo dodacího listu 106.

3.

Přijměte zboţí, které je uvedeno na skladové kartě před vámi. Čárový kód zadejte ručně bez snímání. Přijměte 10ks, cena 3 988Kč kus, číslo faktury 20762, číslo dodacího listu 1652. 4. Synchronizujte aplikaci se serverem. Vámi přijaté zboţí se odešle na server pro další zpracování. Tabulka 6-7 Ukázka průchodu procesu Příjem zboţí

Z této metody se získá nejdůleţitější část dat pro zlepšení aplikace a odhalení chyb.

- 70 -

6.2.3.3 Sbíraná data a jejich formát Sběr dat bude uskutečněn ve dvou formách. První z nich je audio záznam z průběhu testování, kdy je nezbytné, aby testovaná osoba myslela nahlas. Veškeré pochybnosti či nejasnosti při testování by měl tester vyslovit nahlas, tak aby se tyto poznatky daly později vyuţit k vylepšení aplikace. 6.2.3.4 Technické prostředky pouţité při testování Při testování bude pouţit z technického vybavení pouze záznamník. Video záznam samotné obrazovky zařízení není technicky moţný. Dále bude pouţito poznámkového bloku pro zápis poznámek moderátorem.

6.2.4 Testování uţivatelé Jelikoţ v praxi budou aplikaci vyuţívat v drtivé většině pouze skladníci, byl výběr osob pro testování omezen pouze na skladníky. Testování je omezené počtem skladníků ve firmě, ale i tak bude výběr osob dostatečně reprezentativní, poněvadţ aplikaci budou vyuţívat právě tyto osoby. Narozdíl od provedeného interview, kterého se zůčastnili všechny osoby, u testování nebyla k dispozici osoba číslo pět. Testované osoby zatím neprošli ţádným školením a tak budou procházet jednotlivými procesy aplikace poprvé, coţ je u těchto prvotních testů nutným předpokladem. Následuje podrobný popis testovaných osob Tabulka 6-8. Číslo osoby

Jméno

Věk

Pozice

Počet let

Technická

ve firmě

zručnost

1

Karel Melich

34

skladník

3

střední

2

Pavel Brenka

56

skladník

4

střední

3

Adam Korouch

36

skladník

8

pokročilá

4

Milan Vavřiník

46

skladník

<1

začátečník

5

Otakar Krátký

41

skladník

<1

začátečník

6

Václav Soukal

45

skladník

12

střední

7

Milena Rýnská

38

skladnice

5

střední

Tabulka 6-8 Podrobný popis testovaných osob

- 71 -

6.2.4.1 Pre-test dotazník Jak jiţ bylo zmiňováno, slouţí pre-test dotazník k zjištění prvotních detailních informací o testované osobě. Jsou to především informace typu jak je testovaná osoba technicky zručná a vzdělaná, jak si představuje, ţe bude práce s novou aplikací vypadat a podobně. Následuje tabulka s vyhodnoceným pre-test dotazníkem. Pre-test dotazníku se zůčastnilo šest osob, osoba číslo 5 z Tabulka 6-8 nebyla přítomna. Číslo otázky

Počet odpovědí / Procentuálně 6 / 100% 0 / 0%

Otázka

Odpověď

1

Pouţíváte technické zařízení? (mobil, počítač)

ano ne

2

Jak byste ohodnotil svou technickou zdatnost? (Schopnost ovládat technické zařízení.)

začátečník středně pokročilý pokročilý

2 / 33,3% 3 / 50% 1 / 16,6%

3

Pokud pouţíváte počítač, jak často jej pouţíváte?

denně několikrát do týdne několikrát za měsíc

3 / 50% 3 / 50% 0 / 0%

4

Pouţíval jste jiţ někdy zařízení s dotykovým displejem?

5

Pokud jste pouţíval zařízení s dotykovým displejem, mělo větší displej neţ současné zařízení?

ano ne ano

1 / 16,6% 5 / 83,3% 1 / 100%

6

Pokud jste pouţíval zařízení s dotykovým displejem, pracovalo se vám s ním dobře?

ne ano ne

0 / 0% 1 / 100% 0 / 0%

7

Pokud jste pouţíval zařízení s dotykovým displejem, pouţíval jste prsty nebo stylus pro práci na zařízení?

prsty stylus jiné ………………

1 / 100% 0 / 0% 0 / 0%

8

Pouţíval jste jiţ někdy podobné zařízení jako to, na kterém bude dodávaná aplikace A_Terminal++?

ano ne

2 / 33,3% 4 / 66,6%

9

Vyzkoušel jste si jiţ práci se zařízením, na kterém bude aplikace A_Terminal++?

ano

2 / 33,3%

ne

4 / 66,6%

méně jak 5x 5x aţ 20x

0 / 0% 1 / 16,6%

20x a více méně neţ rok

5 / 83,3% 2 / 33,3%

1 aţ 5 roků

2 / 33,3%

5 roků a více

2 / 33,3%

ano

1 / 16,6%

ne

5 / 83,3%

ano ne

4 / 66,6% 2 / 33,3%

10

Jak často za den si myslíte, ţe budete terminál pouţívat?

11

Jak dlouho jiţ pracujete na vaší pozici?

13

Zdá se vám současný způsob pořízení prvotních dokladů jednoduchý a rychlý? (Pokud ano, tak proč.)

14

Pouţíval jste někdy aplikaci Asystem++?

Tabulka 6-9 Vyhodnocení pre-test dotazníku

- 72 -

Otázka číslo dvanáct zněla „Uveďte prosím váš věk.― A ze získaných odpovědí je průměrný věk testovaných osob 42 let. Coţ svědčí o středně starších zaměstnancích pracujících na pozicích skladník. Z pre-test dotazníku jsem tedy získal dostatečné informace o technickém vzdělání testovaných osob, o pouţívání technických zařízení a další důleţité věci, jeţ mohou pomoci při návrzích na zlepšení aplikace. Závěry, jeţ můţeme z pre-test dotazníku učinit, jsou zejména:  Všechny testované osoby pouţívají technické zařízení, i kdyţ ne všechny jim tak dobře rozumí, proto bude nutné podrobné školení, jak se zařízením zacházet.  Zařízení s dotykovým displejem pouţívala pouze jedna testovaná osoba, přesto by neměl být problém, aby si na tento druh ovládání zvykly i ostatní. Většina povaţuje stávající průběh procesu pořízení prvotních dokladů za špatný, proto snáze uvítají změnu a nebude jim tak vadit nový průběh procesu zpracování prvotních dokladů.

6.2.5 Předpokládaný průběh testování Před samotným testováním proběhne krátké seznámení testované osoby se zařízením a aplikací, tak aby byla testovaná osoba schopna zařízení ovládat. Poté se provede vyplnění pre-test dotazníku, který poskytne prvotní informace o dané testované osobě. Následuje zahájení samotného testování, kdy se testované osobě postupně předkládají úkoly ke zplnění. V průběhu testování moderátor pečlivě sleduje testovanou osobu, ale takovým způsobem, aby ji co nejméně ovlivňoval. Pokud se vyskytne nějaký problém nebo moderátor něco podstatného zpozoroval, zapíše si to do svého bloku. Moderátor do testování zasáhne aţ v krajním případě, kdy je jiţ zřejmé ţe si tester neví rady. Po skončení vlastního testování vyplní testovaná osoba post-test dotazník, z kterého se získá odezve z pouţití aplikace. Testování je zakončeno interview mezi testovanou osobou a moderátorem.

6.3 Testy pouţitelnosti - průběh testování Skutečný průběh testování se lišil od plánovaného. V plánovaném testování se nepočítalo s časovým vytíţením skladníků, a poněvadţ se v průběhu testování ještě kontinuálně

- 73 -

představovaly změny v IS A_System++, byli všichni skladníci přítomni na tomto představování a k testování museli odbíhat, navíc se celé testování muselo uspíšit, tak aby skladníci, byli co nejdříve zpět na svých pracovištích. Před samotným testováním byly skladníkům rozdány pre-test dotazníky, z kterých se měly získat prvotní údaje o zkušenostech s technickými zařízeními a názorech skladníků na chystanou změnu. Dotazník všichni vyplnili a tak se mohlo přejít k další fázi testování – samotný průchod úkolů. Průchod úkolů jako hlavní část testování, kdy měli jednotlivý skladníci projít předem přichystané úkoly (procesy), měl zabírat největší časový úsek z testování, k čemuţ i došlo, ale stále u některých testovaných osob vymezený čas nestačil, a tak se některé úkoly musely vynechat. I přes časovou tíseň se podařilo projít s kaţdým skladníkem nejméně dva úkoly, coţ se později ukázalo jako dostačující. V průběhu testování byly zaznamenávány poznámky a celé testování bylo nahráno na záznamník. U předpokládaného průběhu testování mělo po průchodu testů následovat vyplnění post-test dotazníku a aţ poté interview se skladníkem. V skutečnosti se ale tyto dvě věci prohodily, tzn., ţe nejprve se provedlo interview a aţ poté následovalo vyplnění post-test dotazníku. Prohození těchto dvou věcí by nemělo mít vliv na celkové hodnocení testování. Interview tedy proběhlo ihned po průchodu úkolů a bylo převáţně stručné a cílené. Formou nenucené konverzace testovaná osoba pověděla své dojmy z průchodu úkolů, vysvětlila své postoje vůči této novince a informovala o moţných dalších problémech v souvislosti se zavedením testované aplikace. Jako poslední část testování proběhlo vyplnění post-test dotazníků, které jiţ počítaly s absolvováním průchodu úkolů, protoţe byly zaměřeny na chování a spokojenost skladníků s aplikací a zařízením. Z průběhu testování jsem získal cenné zkušenosti a zejména si uvědomil, ţe dobře naplánované testování ještě neznamená úspěch celého testování. Vţdy je nutné počítat s nepředpokládanými situacemi a to zvláště v případech, kdy testování probíhá přímo ve společnosti, ve které se má testovaná aplikace zavádět. Jednak ne vţdy jde hladce sehnat dostatečný počet testovaných osob, které budou aplikaci při výkonu práce pouţívat a také se nemusí podařit získání dostatečného času pro jednotlivé testované osoby. Zde uvedené problémy jsou jen hrstka těch, které je nutné před, v průběhu a i po testování řešit. Mnou prováděné testování také nebylo ideální a mělo své chyby, ale jiţ samotný průběh průchodu

- 74 -

úkolů ukázal, ţe i přes některé nedostatky poslouţí testování k odstranění zjištěných chyb a ke zlepšení aplikace ve prospěch budoucích uţivatelů.

6.4 Zpracování nasbíraných dat Získaná data pocházejí především z vyplněných pre-test a post-test dotazníků. Tyto data se nejsnáze zpracovávají, poněvadţ byla většina otázek zaškrtávacích a jen málo otázek tzv. otevřených (odpověď vymýšlí testovaná osoba bez nabídnutých odpovědí). Ke zpracování těchto údajů postačil nový sloupec u dotazníků, kam se přidaly počty odpovědí na jednotlivé otázky i s procentuálním zastoupením. Zpracovaný pre-test dotazník je zobrazen v Tabulka 6-9 a post-test dotazník v Tabulka 6-10. Z průběhu průchodu úkolů se získaly psané poznámky a audio záznam. Tyto data poslouţí zejména u sepisování problémů aplikace a při návrzích na zlepšení aplikace. Poznamenané poznámky a audio záznam nebude dále nijak zpracováván, pouze se z nich vyhodnotí odpovídající závěry a navrhnou příslušná opatření pro zlepšení chodu aplikace. Posledními údaji, které bylo nutné nějakým způsobem zpracovat, jsou informace získané při interview. Tyto informace získané díky interview představují důleţitou část dat, která slouţí pro další rozhodování, při vytváření návrhů na zlepšení. Informace poskytnuté testovanou osobou během interview mají význam v tom, ţe jsou získána i taková data, která by se pouhým vyplňováním dotazníku nezískala. Interview bylo také zaznamenáno na záznamník a popřípadě doplněno poznámkami moderátora na papír. Ani zde se neprováděly ţádné další úpravy nasbíraných dat.

6.5 Vyhodnocení testování Získané a zpracované data jsou připraveny podstoupit analýzu a závěrečné vyhodnocení. U vyhodnocování se musí dodrţet určité podmínky, tak aby nedocházelo ke zkreslení získaných dat. Na druhou stranu i při dodrţení těchto podmínek můţou být vyhodnocená data ne zcela průkazná pro vyvození závěrů a to například v případě dotazníku, kdyţ se při zpracování nějaké otázky ukáţe, ţe kaţdá odpověď má stejný počet odpovědí od testovaných osob. Podstatný předpoklad pro správné vyhodnocení je mít dostatek nasbíraných dat, která jsou relevantní. Při nedostatečném mnoţství dat totiţ hrozí nesprávné vyhodnocení a poté můţe díky tomu dojít aţ ke změnám v aplikaci, které budou jen v neprospěch pouţití aplikace. Na otázku, kolik je dostatečné mnoţství, se těţko odpovídá, vţdy to záleţí na dané

- 75 -

situaci. V mém případě s testovanou aplikací přijde do styku v počátcích šest osob a všech těchto šest osob se podařilo zajistit na testování aplikace, takţe v tomto případě je mnoţství malé, ale vzhledem k počtu budoucích uţivatelů více neţ postačující. Z vyhodnocení musí jiţ vyplývat, co je špatně, kde je aplikace špatně navrţena, proč se testovaná osoba nedokáţe správně orientovat v ovládání, atd. Vyhodnocení provedu podle jednotlivých metod pouţitých při testování, tzn., nejprve se zastavím u dotazníků a poté důkladně proberu průchody úkolů.

6.5.1 Průchod úkolů Hlavní část testování spočívala v průchodu procesů, které budou budoucí uţivatelé denně pouţívat ve formě úkolů. Testovaná osoba měla samostatně projít připravenými úkoly, ovšem kaţdá z testovaných osob nakonec potřebovala výpomoc, aby se posunula dál v plnění úkolu. Pokud by testované osoby prošly všechny připravené úkoly bez nápovědy, tak je to na jedné straně vynikající výsledek pro aplikaci na druhou stranu trochu podezřelé, zejména vzhledem ke zjištěným údajům z pre-test dotazníku, kdy ne všechny testované osoby se cítí být technicky zručné a především díky tomu, ţe s testovanou aplikací se před testy setkaly pouze dvě ze šesti testovaných osob. Tento případ ovšem nenastal. Jak jsem jiţ uvedl, testované osoby měly problémy při plnění jednotlivých bodů úkolů a právě z těchto problémů se budou vyvozovat závěry vůči aplikaci. Většina problémů byla společných více testovaným osobám a právě ty jsou nejdůleţitější z hlediska správného vyhodnocení. Dále uvedu právě tyto problémové místa. 6.5.1.1 Procházení mezi záloţkami U prvního úkolu bodu dva měly testované osoby přijmout uvedené druhy zboţí. Většina testovaných osob (konkrétně osoby číslo: 1, 2, 4, 5, 6) ovšem na úvodní obrazovce, která představuje výdej zboţí, hledala, kde se vlastně nové zboţí přijímá a přecházela tak mezi jednotlivými záloţkami, které s příjmem neměly nic společného. Aţ po upozornění moderátora se přesunuli na správnou záloţku, ale i přesto některé testované osoby nepochopily význam tlačítka „Přidej“ a tak je moderátor opět musel navést na správné tlačítko. S významem tlačítka „Přidej“ nebo obecněji s akcí, která má následovat při příjmu zboţí na této obrazovce se jiţ těţko dá něco udělat, k zamyšlení zůstává problém procházení záloţek v aplikaci, i kdyţ podle názvu záloţky nemůţou mít s daným procesem nic společného, testované osoby se na ně zaměřovaly a odcházely tak od úkolu který měly řešit.

- 76 -

6.5.1.2 Snímání čárového kódu V další části prvního úkolu dělalo potíţe sejmutí čárového kódu (osoby číslo: 1, 4, 5), kdy bylo potřeba zařízení správně nasměrovat před snímaný čárový kód, ale to je spíše otázka zvyku neţ problému zařízení jako takového. 6.5.1.3 Klávesnice a nepopsané textové pole Následující fází bylo vyplnění formuláře představující informace o zboţí, při této činnosti se projevila ne moc efektivní klávesnice zařízení a popis tlačítek, ale opět je to o zvyku, poněvadţ zařízení se jiţ určitě měnit nebude a tak si uţivatelé musí zvyknout na poněkud netradiční rozmístění kláves. Nicméně ani formulář v aplikaci nebyl úplně ideálně navrţen, testované osoby (osoby číslo: 2, 4, 5) především mátly nepopsané textové pole, a tak pouze odhadovaly, jak by jej asi tak měly vyplnit. Nepopsané textové pole byly na formuláři ze dvou důvodů. Za prvé pro úsporu místa a za druhé se při návrhu aplikace počítalo s tím, ţe IS A_System++, ze kterého vychází návrhy formulářů pro testovanou aplikaci, pouţívali všichni budoucí uţivatelé testované aplikace a nebudou tak mít problém s nepopsanými textovými poli, coţ se ukázalo jako liché jiţ ze získaných dat z dotazníků, kde na otázku zda přišli do styku s IS A_System++, odpověděli kladně pouze čtyři ze šesti testovaných osob. 6.5.1.4 Tlačítka pro uloţení Po vyplnění všech potřebných polích nastal problém ve vybrání správného tlačítka pro uloţení (osoby číslo: 3, 4, 5), poněvadţ jsou na formuláři dvě tlačítka slouţící k uloţení. Jedno s nápisem „Ulož“ pro klasické uloţení a zavření formuláře a druhé s nápisem „Ulož+“, které je opět inspirací z IS A_System++ a slouţí k uloţení a pokračování na té samé obrazovce pro další příjem zboţí, coţ má vést k urychlení celé operace. Otázkou je, jaká varianta popisu tlačítka bude výhodná, zda ponechat současné stručné s tím, ţe se na tento popis musí budoucí uţivatele upozornit nebo se pokusit vymyslet srozumitelnější popis za cenu delšího textu. 6.5.1.5 Druhý úkol a neprojíté úlohy To jsou zjištěné podstatné nedostatky při průchodu prvním úkolem, a protoţe druhý úkol měl znění „Výdej zboží“ a jelikoţ je tento proces aţ na prvky na formuláři stejný, docházelo ke stejným nedostatkům, ale v menším měřítku. Některé testované osoby jiţ samy bystře pochopily, co mají při druhém úkolu udělat a tak byl průchod druhým úkolem o poznání lepší.

- 77 -

Další původně plánované úkoly se neprošly z jiţ zmíněných časových důvodů. Nakonec to ale není velký problém, poněvadţ souvisely s obrazovkami, které v prvních verzích aplikace nakonec vůbec nebudou a navíc se dočkají rozsáhlých změn, pokud by měly být do aplikace v pozdější době zpět přidány. Průchod testy dokázal odhalit spousty maličkostí, jeţ by se běţnými testy nemuselo podařit odhalit. Zejména tyto získané informace slouţí jako podklady pro sestavení návrhů na zlepšení a také pro odhalení chyb v aplikaci.

6.5.2 Post-test dotazník U post-test dotazníků se zaměřujeme především na odpovědi na otázky ohledně spokojenosti či nespokojenosti s ovládáním aplikace, její rychlosti a vůbec jak celkově aplikace na testovanou osobu zapůsobila. Jde především o zjištění, zda je jiţ aplikace připravena pro ostrý provoz, či jí ještě něco schází či přebývá. Vyhodnocený post-test dotazník je zobrazen v Tabulka 6-10. Upřesnění vyhodnocení odpovědí na první otázku - Na stupnici od jedné do pěti, kde jedna je nejlepší, získala aplikace čtyřikrát za jedna, jednou za dva a jednou za tři, tedy celkem úspěšné hodnocení. Otázky šest, jedenáct, třináct, čtrnáct, sedmnáct a osmnáct byly otevřené. Pouze u otázek jedenáct, sedmnáct a osmnáct byla nějaká odpověď a to u kaţdé právě jedna. U otázky jedenáct testovaná osoba uvedla, ţe to chce praxi a více vyzkoušet. Na otázku sedmnáct to byla odpověď, ţe aplikace se zdá pomalá při odezvách na akci uţivatele. A konečně odpověď na osmnáctou otázku: „Chce to vyzkoušet a vyhodnotit co bude pro mě nejlepší.― Vyhodnocení post-test dotazníku přineslo další uţitečné informace. Ověřil jsem si správnost návrhu aplikace, která plyne z kladného hodnocení od testovaných osob. Také se zjistilo, ţe dotykové ovládání nebude dělat problém při práci s aplikací.

- 78 -

Číslo otázky

Otázka Jak se vám aplikace líbila?

2

Sníţí vám aplikace chybovost při pořízení dokladu?

3

Bude vaše práce efektivnější a rychlejší s aplikací?

4

Zdá se vám aplikace jednoduchá na naučení?

5

Měl jste při testování problém s dotykovým ovládáním?

6

Pokud jste měl problém s dotykovým ovládáním, uveďte na které obrazovce a jaký problém to byl?

7

Ovládá se vám aplikace lépe prsty či stylusem?

8

Chtěl byste celou aplikaci ovládat pouze prsty?

9

Jak se vám pouţívala klávesnice zařízení?

10

Zdálo se vám ovládání při průchodu testy, přívětivé?

11

Pokud jste měl k ovládání výhrady, jaké a kde?

12

Chybělo vám v aplikaci něco?

14

ano ne

6 / 100% 0 / 0%

ano

0 / 0%

ne

6 / 100%

prsty stylusem

1 / 16,6% 5 / 83,3%

ano ne výborně

1 / 16,6% 5 / 83,3% 3 / 50%

průměr nic moc

3 / 50% 0 / 0%

ano

5 / 83,3%

ne

1 / 16,6%

ano

0 / 0%

ne

6 / 100%

ano

2 / 33,3%

ne nevím

2 / 33,3% 2 / 33,3%

ano

1 / 16,6%

ne

5 / 83,3%

Jestliţe vám v aplikaci něco scházelo, co přesně to bylo? Co se vám v aplikaci nelíbilo?

15

16

Zdála se vám aplikace v některém místě pomalá?

18

3 / 50% 5 / 83,3% 1 / 16,6%

nelíbí

1---2---3---4---5

Sníţí vám aplikace náročnost fyzické námahy při práci?

17

ne ano ne

líbí

1

13

ano

Počet odpovědí / Procentuálně 1) 4 / 66,6% 2) 1 / 16,6% 3) 1 / 16,6% 3 / 50%

Odpověď

Pokud se vám zdála aplikace pomalá, tak uveďte ve kterém místě? Chcete ještě něco vyjádřit ohledně testování a aplikace? Tabulka 6-10 Vyhodnocení post-test dotazníku

6.6 Návrhy na zlepšení Získaná data z testování byla nejdříve zpracována, poté ve vyhodnocení testování byly odhaleny jednotlivé problémy, které byly podrobně rozebrány a popsány. Nakonec je zde rozebrán popis moţných náprav těchto nedostatků.

- 79 -

6.6.1 Nedostatky beze změny Ne kaţdý problém se dá vyřešit, ať jiţ z důvodů technických moţností nebo jednoduše z praktického hlediska, kdy je výhodnějším řešením, ponechat problém beze změny a právě některé takové budou ponechány beze změny i v aplikaci A_Terminal++, jsou to především problémy s nápisy na tlačítku a podobné, tzn., ţe nejde o závaţný problém a k vyřešení stačí ochota budoucích uţivatelů, zvyknout si na daný nápis a podobně.

6.6.2 Zredukování počtu záloţek Při úplném začátku průchodů úkoly se objevil problém s velkým počtem záloţek, které testované osoby mátly a bylo by tak lepší ponechat při procesu příjmu a výdeji zboţí pouze tyto dvě záloţky (tzn. Příjem a Výdej). Zbylé záloţky by se buď přenesly o úroveň výš na novou hlavní obrazovku, ze které by se teprve přecházelo na jednotlivé podčásti aplikace, nebo by se záloţky přenesly na horní panel aplikace do menu. Tato úprava se jeví jako velmi vhodná a byla i díky odloţení implementace ostatních záloţek provedena ihned.

Obrázek 6-2 Odstranění přebytečných záloţek

6.6.3 Přemístění prvků na formuláři Nejvíce návrhů ke změně pochází ze špatného rozmístění prvků na obrazovce (formuláři). Zejména při realizaci průchodu úkoly se tento nedostatek projevoval zmatením testované osoby, kdy nevěděla, co který prvek představuje nebo na jaké tlačítko má přejít, aby docílila

- 80 -

poţadované akce. Náprava je snadná, stačí pouze provézt změnu v rozestavení prvků na formuláři, tak jak vyplynula z poţadavků testovaných osob. Tato malá úprava přinese velké zefektivnění práce uţivatelů.

6.6.4 Zrychlení odezvy Poţadavek na urychlení odezvy aplikace lze uspokojit jen částečně, poněvadţ technické parametry zařízení a potaţmo také klientské databáze jiţ umoţňují jen malé pole působnosti, co se týče optimalizace. Aplikace jiţ nyní musí procházet více neţ jedenáct tisíc poloţek, které jsou uloţeny v databázi. Pro stolní pracovní stanice to nepředstavuje v dnešní době ţádný problém, ovšem zařízení s omezenou kapacitou paměti a s nedostatečným výkonem jiţ daný příkaz zpracovává delší dobu a odezva je znatelnější.

6.6.5 Mobilní zařízení Samotné zařízení lépe řečeno jeho dotyková obrazovka a klávesnice v některých případech také činily problémy, ovšem tyto nedostatky nejsou váţného charakteru a jde spíše o zvyk uţivatelů. Zařízení jinak velmi dobře plní svou roli a není nutná jeho výměna za jiné. Z výše uvedených návrhů na vylepšení aplikace by se většina z nich měla implementovat v rámci další verze aplikace, tak aby splnila poţadavky uţivatelů a nedocházelo tak k problémům, ke kterým docházelo při současném testování.

6.7 Shrnutí testování Význam testování se ukázal být výrazný, neboť díky testování se měly odhalit špatně navrţená místa aplikace, které se skutečně podařilo odhalit, dále byl důleţitý názor budoucího uţivatele na podobu aplikace. Na základě interview s testovanou osobou se odhalily chyby, na které by se jinou metodou jen těţko přicházelo. Z průběhu testování vyplynulo mnoho menších nedostatků, které byly zpracovány, analyzovány a navrhnuty návrhy na vylepšení. Mnohé z těchto návrhů byly implementovány a vylepšily tak chování aplikace. Budoucí uţivatel by měl doimplementované vylepšení poznat zejména v pohodlnější a efektivnější práci s aplikací. Prokázala se důleţitost testování pouţitelnosti, jakoţto metody pro odhalení špatného návrhu aplikace. Přímá konfrontace testera a budoucího uţivatele se ukázala jako zásadní prvek testování. Celkově testování splnilo poţadované cíle a ukázalo být důleţitou součástí vývoje aplikace.

- 81 -

- 82 -

7 ZÁVĚR „Každá lidská činnost se nakonec musí nějak projevit v číslech.“ Tomáš Baťa Výsledkem práce měla být navrhnutá a implementovaná aplikace pro správu skladu, coţ se v rámci projektu A_Terminal++ podařilo. Návrh aplikace byl zaloţen na předchozí analýze a obsahoval zejména pouţití UML diagramů pro vyjádření struktury a chování aplikace. Poté po výběru technologií a nástrojů k vývoji následovala implementace navrhnutého systému. Implementace zahrnovala klientskou a serverovou část aplikace. Klientská část se spouští na mobilním zařízení umoţňující snímání čárových kódů a představuje několik obrazovek a dialogů pro proces příjmu a výdeje, zahrnuje také část synchronizační logiky. Na klienta byla umístěna také databáze pro uchovávání dat. Serverovou část představuje sluţba čekající na poţadavky od klientů, zahrnuje většinu synchronizační logiky a je spojena se serverovou databází. Výsledek implementace se měl otestovat v testech pouţitelnosti, k čemuţ také došlo. Testy odhalily některé nedostatky, které byly přepracovány a opět otestovány. Testy pouţitelnosti se ukázaly jako nezbytný prostředek při vývoji aplikací zaměřené na uţivatele.

7.1 Zhodnocení práce Ze zadání práce vyplynulo několik cílů, ty následují s popisem splnění:  Analyzovat poţadavky pro správu skladu – Byly posbírány poţadavky od zákazníka a následně provedena analýza těchto poţadavků.  Aplikace má umoţňovat příjem a výdej zboţí pomocí čtečky čárových kódů – Tento bod vyplynul jiţ ze samotné analýzy zákazníkových poţadavků. Klientská část aplikace se stará právě o příjem a výdej zboţí pomocí zařízení umoţňující snímání čárových kódů.  Aplikaci navrhnout a implementovat – Aplikace byla na základě analýzy navrhnuta pomocí UML diagramů a pomocí těchto diagramů poté implementována.  Správnost návrhu aplikace ověřte v testech pouţitelnosti – Návrh aplikace byl pomocí testů pouţitelnosti ověřen, v případě nutnosti poopraven.

- 83 -

7.2 Další vývoj Na přínosy se můţeme dívat z několika úhlů pohledu. Npříklad z pohledu zákazníka či dodavatele. Zákazník Zákazník resp. společnost Kovar očekávala se zavedením mobilních terminálů s aplikací A_Terminal++ především zefektivnění práce, čehoţ se rozhodně dosáhlo, jak přesně velkou měrou jiţ záleţí na samotných zaměstnancích, jak efektivně budou terminály s aplikací pouţívat. Se zavedením mobilních terminálů se odstranila papírová evidence přijatých a vydaných zakázek, která byla dříve nutná k dalšímu zpracování dat, dále odpadla nutnost mít přístup k IS A_System++, poněvadţ data se do systému dostanou přímo z terminálů pomocí synchronizace a stejně tak jsou data z IS viditelné v aplikaci A_Terminal++. Postupné zavádění dalších informačních technologií můţe dále přispět k zefektivnění procesů uvnitř společnosti. Jiţ nyní se dá odhadovat, ţe přínos zavedení aplikace A_Terminal++ bude znamenat aţ 15% zefektivnění práce skladníka. Ušetření dalších 10% aţ 15% času by se mohlo docílit zavedením systému čárových kódu dále do výroby. V dnešní době se vše točí zejména okolo financí, z tohoto pohledu společnost Kovar ušetří nemalé finanční prostředky zefektivněním procesů příjmu a výdeje. Jak jiţ bylo uvedeno, míra zefektivnění záleţí na koncepci celého hodnototvorného řetězce v rámci společnosti. Dodavatel Pro dodavatele je samozřejmě přínosem finanční obnos získaný za dodanou zakázku. Pokud ovšem chce mít dodavatel moţnost dalšího rozvoje u zákazníka, je předpokladem spokojený zákazník, coţ se v případě dodání aplikace A_Terminal++ a souvisejícího hardwarového vybavení podařilo. Dodavatel dále získal přehled a znalosti dalších technologií a předně má základ pro vývoj dalších podobných aplikací na bázi mobilní zařízení – synchronizace - server.

- 84 -

LITERATURA 1. CCV Informační systémy. CCV Řízený sklad. CCV Informační systémy. [Online] [Citace: 14. 03 2011.] http://www.ccv.cz/podnikove-informacni-systemy/oborovareseni/ccv-rizeny-sklad/. 2. Kodys. Řízený sklad Accellos WMS. Kodys. [Online] [Citace: 14. 03 2011.] http://www.kodys.cz/reseni/logistika-skladovani-a-preprava/rizeny-sklad-accelloswms.html. 3. PDA Trade. Evidence majetku a skladu. PDA Trade. [Online] [Citace: 14. 03 2011.] http://www.repsale.com/mobilni-evidence-majetku.php. 4. MILSOFT. Mobilní terminály v expedičních skladech. MILSOFT. [Online] [Citace: 14. 03 2011.] http://www.milsoft.cz/Aktuality/termskl.html. 5. Dreyfuss, Henry. Designing for People. 1955, str. 261. 6. Pruitt, John a Adlin, Tamara. The Persona Lifecycle : Keeping People in Mind. San Francisco : Morgan Kaufmann, 2006. 7. Vystrčil, Jan. Uţivatelské rozhraní pro navigaci nevidomých osob v budovách. [Online] [Citace: 24. 3 2011.] https://dip.felk.cvut.cz/browse/pdfcache/vystrj1_2008dipl.pdf. 8. Maléř, Ondřej. Softwarová architektura. Computerworld. 11 2008, Sv. 11, XIX. 9. Microsoft. Webový vývoj v ASP.NET 2.0 pomocí bezplatných Express nástrojů pro úplné začátečníky. [Broţura] místo neznámé : Microsoft, 2005. 10. —. .NET Compact Framework. .NET Framework Developer Center . [Online] [Citace: 30. 3 2011.] http://msdn.microsoft.com/cs-cz/netframework/aa497273(en-us).aspx. 11. —. Introduction to Microsoft Sync Framework. Microsoft Sync Framework. [Online] 10 2009. [Citace: 11. 03 2011.] http://msdn.microsoft.com/en-us/sync/bb821992. 12. Činčura, Jiří. Microsoft Sync Framework - Úvod. Vývojář. [Online] 30. 11 2007. [Citace: 11. 03 2011.] http://www.vyvojar.cz/Articles/557-microsoft-sync-frameworkuvod.aspx. 13. Sybase. Advantage Data Architect. devzone.advantagedatabase.com. [Online] [Citace: 11. 03 2011.] http://devzone.advantagedatabase.com/dz/webhelp/advantage9.1/advantage_database_server /introduction/advantage_data_architect.htm. 14. Běhálek, Marek. Programovací jazyk C#. Katedra informatiky, Fakulta elektrotechniky a informatiky, VŠB-TUO. [Online] [Citace: 12. 03 2011.] http://www.cs.vsb.cz/behalek/vyuka/pcsharp/text/. 15. Microsoft. Naming Guidelines. MSDN Library. [Online] [Citace: 12. 03 2011.] http://msdn.microsoft.com/en-us/library/xzf533w0%28VS.71%29.aspx. 16. —. SQL Server Compact 3.5. Microsoft SQL Server. [Online] [Citace: 11. 03 2011.] http://www.microsoft.com/sqlserver/2008/en/us/compact.aspx. 17. Puš, Petr. SQL Server Compact Edition a .NET 3.5. Vývojář. [Online] 27. 12 2007. [Citace: 11. 03 2011.] http://www.vyvojar.cz/Articles/576-sql-server-compact-editiona-net-3-5.aspx.

- 85 -

18. Sybase. Advantage Database Server. Sybase. [Online] [Citace: 11. 03 2011.] http://www.sybase.com/products/databasemanagement/advantagedatabaseserver. 19. Hennig, Doug. Advantage Database Server pro programátory ve Visual FoxPro. Daquas. [Online] [Citace: 11. 03 2011.] http://www.daquas.cz/Files/software/FoxProadvantage-database-server-pro-programatory-ve-VFP.pdf. 20. Microsoft. Walkthrough: Creating an Occasionally Connected Smart Device Application. MSDN Library. [Online] 07 2008. [Citace: 03. 11 2011.] http://msdn.microsoft.com/en-us/library/cc488004%28v=vs.90%29.aspx. 21. Garlan, D. a Perry, D. Introduction to the Special Issue on Software Architecture (Guest editorial). IEEE Transaction on Software Engineering. 1995. 22. Clements, P. a Northrop, L. Software Architecture: An Executive Overview. Pittsburgh : Software Engineering Institute, Carnegie Mellon University, 1996. 23. Chastek, G. a Brownsword, L. A Case Study in Structural Modeling. Pittsburgh : Software Engineering Institute, Carnegie Mellon University, 1996. 24. Smolík, Tomáš. Softwarová architektura. Profinit. [Online] 2007. [Citace: 11. 02 2011.] http://www.profinit.eu/uploads/souvisejici-obsah/dokumenty/cz/academy/swengmaterialy/architecture-design/reading/Profinit_SwArchitectureOverview.pdf. 25. International Telecommunication Union . Market Information and Statistics (STAT) . ITU. [Online] [Citace: 23. 4 2011.] http://www.itu.int/ITUD/ict/statistics/index.html. 26. Barcode Datalink. Barcode Datalink. [Online] [Citace: 28. 4 2011.] http://www.barcodedatalink.com/pages/motorola-mc3090-available-configurations.php.

- 86 -

A. SEZNAM POUŢITÝCH ZKRATEK .NET

dot NET = tečka NET, NET pochází z network, síť

ADO.NET

ActiveX Data Objects .NET

AJAX

Asynchronous JavaScript and XML

CLR

Common Language Runtime

CIL

Common Infrastructure Library

GUI

Graphical User Interface

HTTP

Hypertext Transfer Protocol

HW

Hardware

ICT

Information and communications technology

IT

Information technology

JRE

Java Runtime Environment

JS

JavaScript

SOA

Service-oriented architecture

SOAP

Simple Object Access Protocol

XML

eXtensible Markup Language

WCF

Windows Communication Foundation

- 87 -

B. DATOVÝ MODEL

Obrázek B-1 Datový model

- 88 -

C. INSTALACE Instalace se skládá ze dvou částí, instalace na klienta a na server. Instalace na serveru probíhá pouze jednou a poté při případných aktualizacích instalované sluţby. Instalace klientské části probíhá také pouze jednou, ale to na kaţdého klienta (zařízení umoţňující snímání čárových kódů) zvlášť. Postup instalace aplikace na klientské zařízení je následující:  Nainstalovat potřebné nástroje (.NET CF, knihovny pro SQL Server CE a další) na klientské zařízení.  Do adresáře Program Files přidat adresář terminal, do něj zkopírovat soubor s klientskou aplikací terminal.exe a v tom samém adresáři vytvořit soubor IdTerminal.config a do něj vloţit na první řádek id terminálu a na druhý ip adresu a port, kde běţí serverová sluţba.  Na klientském zařízení musí být paměťová karta, na kterou se vytvoří klientská databáze. Postup instalace sluţby na server je následující:  Spustíme soubor setup.exe a řídíme se postupem na obrazovce.  Pro správný běh sluţby (synchronizace) musíme upravit konfigurační soubor nacházející se v adresáři nainstalované sluţby. V konfiguračním souboru WinSyncService.exe.config je nutné nastavit zejména cestu k serverové databázi, ip adresu na které bude sluţba vystavena a případně další nastavení, které ale nejsou pro základní běh aplikace potřebné.  Sluţba předpokládá nainstalovanou databázi Advantage Database Server s potřebným databázovým schématem.

- 89 -

D. OBSAH PŘILOŢENÉHO CD . |- readme.txt

- popis obsahu jednotlivých adresářů

|- install.txt

- postup instalace na klienta a server

|----- Text

- adresář obsahující vlastní text DP ve formátu PDF

|----- Aterminal - adresář obsahující všechny projekty potřebné k sestavení klientské aplikace a serverové sluţby | |----- .svn

- adresář obsahující potřebné soubory pro verzování projektů

|----- Setup1

- adresář obsahující projekt pro vytvoření instalačních souborů k serverové sluţbě

|----- SynService - adresář obsahující projekt synchronizační sluţby, jeţ bude na serveru |----- terminal

- adresář obsahující projekt klientské části aplikace A_Terminal++

|----- WinSyncService - adresář obsahující projekt nutný k vytvoření windows sluţby

- 90 -