Mobilní systém pro podporu v ela ské práce. Ond ej Mandík. ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta

eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·

Bakalá°ská práce

Mobilní systém pro podporu v£ela°ské práce

Ond°ej Mandík

Vedoucí práce:

Ing. Zden¥k Míkovec, PhD.

Studijní program: Softwarové technologie a management, Bakalá°ský

Obor: Softwarové inºenýrství

26. kv¥tna 2010

iv

v

Pod¥kování Velmi rád bych pod¥koval a vyslovil uznání v²em, kte°í mi pomáhali p°i vývoji a testování této práce. P°edev²ím bych cht¥l pod¥kovat Ing. Zde¬ku Míkovcovi, PhD. za za trp¥livé vedení této práce a mnoºství praktických rad. Dále bych cht¥l pod¥kovat pracovník·m eského svazu v£ela°ského a to p°edev²ím MVDr. Miloslavu Peroutkovi, CSc., Ing. Vilému Frischovi a RNDr. Robertu miedovi. Dal²í dík je ur£en pro Ing. Dalibora Tit¥ru z Výzkumného ústavu v£ela°ského a Ing. Bo°ivoje Zbuzka ze Státní rostlinoléka°ské správy, Miloslava Zímu, Lubo²e P°ibyla, Jarslava Kasprzika a Martina Mezihoráka. Nakonec bych cht¥l pod¥kovat v²em ostatním kte°í se podíleli na vzniku této práce, nebo jakkoli podporovali její vznik.

vi

vii

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 20. 5. 2008

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

viii

Abstract This thesis deals with development and evaluation of applications that can be used to facilitate the beekeepers work. The developed application is designed for mobile devices. First were analyzed basic beekeeping business processes. We sought for the potentional problems that might need to be promoted by the mobile application. Another point was to design and implement the system that can solve these problems. As a result a prototype application was made suitable for both - amateurs and also professionals. This prototype was testedfor eight beekeepers in articial conditions and also during real beekeeping operations.

Abstrakt Práce se zabývá vývojem a evaluací aplikace, která má usnadnit práci chovatel·m v£el. Vyvíjená aplikace je koncipována pro mobilní za°ízení. Nejprve se analyzují základní v£ela°ské pracovní procesy a vyhledávají se potenciální problémy, které je vhodné podpo°it pomocí mobilní aplikace. Dále se práce zabývá návrhem a implementací systému, který tyto problémy °e²í. Výsledkem je prototyp aplikace ur£ené jak pro v£ela°e amatéry tak i profesionály. Tento prototyp je v práce také testován na osmi v£ela°ích a to jak v laboratorních podmínkách, tak i v p°ímo v terénu.

ix

x

Obsah 1 Úvod

1

1.1

Pro£ se zabývat podporou v£ela°ství

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

1

1.2

Letmý pohled na sv¥t o£ima v£ela°e

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

2

1.3

Stav v£ela°ení v R v roce 2009 . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.4

Lze algoritmizovat v£ela°ské procesy? . . . . . . . . . . . . . . . . . . . . . . .

2

1.5

Pro£ mobilní telefony? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.6

Zdroje znalostí

3

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

2 Analýza v£ela°ské problematiky 2.1

2.2

2.3

2.4

2.5

2.6

5

Charakteristika cílového uºivatele . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1.1

Malov£ela°

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

5

2.1.2

Velkov£ela°

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

6

Business procesy v oboru v£ela°ství . . . . . . . . . . . . . . . . . . . . . . . .

6

2.2.1

7

BPMN - Medobraní

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

Specikace problém· a pot°eb cílových uºivatel·

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

7

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

9

2.3.1

Zápisy, pozorování a plánování

2.3.2

Vytvá°ení, ru²ení v£elstev a vým¥na matek

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

9

2.3.3

Chov matek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.3.4

Medobraní a prodej medu, vosku . . . . . . . . . . . . . . . . . . . . .

10

2.3.5

Krmení v£elstev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.3.6

Administrace a statistika . . . . . . . . . . . . . . . . . . . . . . . . . .

12

Specikace cíl·

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

12

2.4.1

Vedení administrace chovu a plánování akcí

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

12

2.4.2

Správa prodeje v£elích produkt·

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

12

2.4.3

Administrace v£ela°ského inventá°e . . . . . . . . . . . . . . . . . . . .

12

2.4.4

Automatické vytvá°ení povinných formulá°· . . . . . . . . . . . . . . .

12

Existující software

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

13

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

13

2.5.1

EDBi

2.5.2

BKeeping

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

13

2.5.3

V£elár 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

Specikace poºadavk·

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

14

2.6.1

Funk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.6.2

Nefunk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

xi

xii

OBSAH

3 Návrh uºivatelského rozhraní 3.1

Anity diagram

3.2

Papírový prototyp

3.3

3.4

19

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

19

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

20

3.2.1

Cíl prototypu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.2.2

Vyhodnocení evaluace a výsledná opat°ení . . . . . . . . . . . . . . . .

22

High delity prototyp 0.1

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

22

3.3.1

Cíle prototypu

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

22

3.3.2

Vyhodnocení a výsledná opat°ení . . . . . . . . . . . . . . . . . . . . .

24

High delity prototyp 0.2 3.4.1

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

24

Vyhodnocení a výsledná opat°ení . . . . . . . . . . . . . . . . . . . . .

25

3.5

Výsledná podoba uºivatelského rozhraní

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

25

3.6

Uºivatelské rozhraní v praxi . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

3.6.1

Specické cíle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

3.6.2

Výsledky evaluace

28

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

4 Implementace

29

4.1

Pouºitá vývojová prost°edí a emulátory

4.2

Pouºité knihovny t°etích stran . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.2.1

Kuix UI framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.2.2

Floggy persistence

30

4.3

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

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

Popis struktury aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.3.1

Celkový pohled na strukturu aplikace . . . . . . . . . . . . . . . . . . .

31

4.3.2

Na£ítání a ukládání dat

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

32

4.3.3

Lokalizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

4.3.4

Business logika a zpracování událostí . . . . . . . . . . . . . . . . . . .

35

4.3.5

Vzhled aplikace a kompozice aplikace . . . . . . . . . . . . . . . . . . .

37

5 Evaluace 5.1

5.2

29

41

Laboratorní evaluace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

5.1.1

Papírový prototyp, storyboardy . . . . . . . . . . . . . . . . . . . . . .

41

5.1.2


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

44

5.1.3


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

46

Evaluace v terénu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

5.2.1

48

Roz²i°ování v£elstev na v£elnici . . . . . . . . . . . . . . . . . . . . . .

6 Dokumentace

51

7 Záv¥r

53

7.1

Hodnocení spln¥ní cíl· aplikace

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

53

7.1.1

Vedení administrace chovu a plánování akcí

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

53

7.1.2

Správa prodeje v£elích produkt·

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

53

7.1.3

Administrace v£ela°ského inventá°e . . . . . . . . . . . . . . . . . . . .

54

7.1.4

Automatické vytvá°ení povinných formulá°· . . . . . . . . . . . . . . .

54

7.2

Pokra£ování práce

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

54

7.3

Záv¥re£né zhodonocení aplikace . . . . . . . . . . . . . . . . . . . . . . . . . .

55

xiii

OBSAH

Literatura

57

A Seznam pouºitých zkratek

59

B Zadání úkol· v rámci testování

61

B.1


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

61

B.2


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

62

C Storyboardy

65

D BPMN Diagramy

75

E Obsah p°iloºeného CD

85

xiv

OBSAH

Seznam obrázk· 2.1

BPMN - Medobraní

2.2

EDBi screenshot

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

8

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

13

2.3

BKeeping screenshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.4

V£elár 2.0 screenshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

2.5

Storyboard - Medobraní

17

3.1

Anity diagram - Medobraní

3.2

Ukázky z papírového prototypu . . . . . . . . . . . . . . . . . . . . . . . . . .

21

3.3

Ukázky z high delity prototypu

23

3.4

V£ela°ská kukla, rukavice a kombinéza

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

26

3.5

V£elnice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.1

Kuix - Schéma zpracování událostí, zdroj: [18] . . . . . . . . . . . . . . . . . .

30

4.2

Floggy persitence schéma, zdroj [15]

31

4.3

Struktura aplikace na mobilním telefonu se standartní klávesnicí.

4.4

Pouºití návrhového vzoru DAO

4.5 4.6

Schéma pr·b¥hu metody

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

38

4.7

Struktura elementu

[18]

39

5.1

Testovací za°ízení Nokia 2700

5.2

Foto-p°íb¥h experimentální evaluace

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

50

6.1

Ukázka webu projektu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

C.1

Jarní prohlídka

65

C.2

Podlední prohlídka

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

66

C.3

Spojování v£elstev

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

67

C.4

Chov matek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

C.5

Medobraní . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

C.6

Zdravotní stav v£el . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

C.7

Osi°ení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

C.8

Protokoly a výkazy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

C.9

Výpo£et náklad· a výnos· . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

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

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

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

20

. . . . . . .

32

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

33

Správa události pomocí vzoru Command . . . . . . . . . . . . . . . . . . . . .

36

C.10 Prodej medu

run() . Screen, zdroj

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

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

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

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

C.11 Vytvo°ení odd¥lku

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

xv

44

72 73

xvi

SEZNAM OBRÁZK

D.1

Vým¥na dna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

D.2

Jarní prohlídka

76

D.3

Jarní ru²ení v£elstva

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

D.4

Protirojová opat°ení

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

78

D.5

Medobraní . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

D.6

Chycení a usazení roje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

80

D.7

Krmení v£elstva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

81

D.8

Podletní prohlídka

82

D.9

Podletní ru²ení v£elstva

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

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

77

83

Seznam tabulek 2.1

asový rozvrh vývoje matek . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xvii

10

xviii

SEZNAM TABULEK

Kapitola 1

Úvod Na úvod této práce bych si dovolil objasnit d·vod, pro£ je jsem se rozhodl v¥novat práv¥ podpo°e v£ela°· pomocí aplikace pro mobilní telefony. Nejprve se podíváme, kdo to v£ela°i vlastn¥ jsou a jaké jsou jejich zájmy a pot°eby. Ukáºeme si také, jak vypadají jejich problémy a nesnáze a nakonec se pokusíme velmi lehce nahlédnout na v£ela°ství v R pohledem statistik z roku 2009. Je d·leºité uvést tento základní a moºná pon¥kud rozsáhlý p°ehled, abychom se v pozd¥j²ích kapitolách, které se jiº v¥nují velmi konkrétním problém·m, neztráceli.

1.1 Pro£ se zabývat podporou v£ela°ství D·vod· pro£ je dobré podporovat v£ela°e, by bylo moºné najít desítky. Mohli bychom zde mluvit o ekologii, pot°eb¥ opylení hmyzosnubných rostlin, zvy²ování zisk· ze zem¥d¥lských plodin, ale vynechme tyto obecn¥ známé d·vody a podívejme se na v£ela°ení hloub¥ji z jiného pohledu. Podívejme se na chov v£el z provozn¥-ekonomického pohledu, který je v trºním hospodá°ství jedním z nejd·leºit¥j²ích. Uve¤me si nejprve n¥kolik tezí a fakt·, kterými popí²eme v£ela°skou farmu pomocí náklad· a výnos·. Výnosy tvo°í p°eváºn¥ trºby z prodeje medu. P°edpokládejme podle [23], ºe pr·m¥rný výnos z jednoho v£elstva je alespo¬ 40kg medu. V roce 2010 je b¥ºná prodejní cena medu 110 CZK/kg. Pro v¥t²í názornost si nyní p°edstavme, ºe jsme malov£ela°i s 10 v£elstvy, která máme umíst¥na na kraji své zahrádky. Kdybychom prodali pouze 60% své produkce ze dvora, £inil by ná² zisk 26400 CZK. Náklady na krmení na²ich v£el jsou ur£eny cenou a mnoºstvím cukru, který pouºíváme jako krmivo. M·ºeme p°edpokládat, ºe krmíme jedno v£elstvo na 22kg cukru. Cena cukru se v období velikonoc v roce 2009 pohybovala pod 10 CZK/kg. Cukr lze v suchém prost°edí skladovat tém¥° neomezenou dobu - jeden v£ela° kdysi °ekl, ºe tuna cukru pod postelí je lep²í, neº zlato v bance. Náklady na krmení na²ich 10 v£elstev bychom mohli vy£íslit na 2200 CZK. Kdybychom zanedbali ostatní p°íjmy, jako je nap°íklad dotace, prodej vosku a ostatní náklady, m·ºeme si ud¥lat hrubý obrázek, ºe malov£ela° s 10 v£elstvy vyd¥lá více neº 22000 CZK za rok. Z uvedeného p°íkladu by m¥lo být názorné, ºe ve svém základním principu (rozdíl ceny medu a ceny cukru) je teoreticky chov v£el dob°e nan£n¥ ohodnocená £innost. Praxe ale bohuºel ukazuje opak. Nech´ je motivací této práce snaha najít kritická místa v oblasti chovu

1

2

KAPITOLA 1.

ÚVOD

v£el a pokusit se co je nejvíce zvý²it efektivitu práce a podpo°it v£ela°e ve sniºování v²ech náklad· (zejména £asových) tak, aby se chov v£el stal výnosnou £inností.

1.2 Letmý pohled na sv¥t o£ima v£ela°e D°íve, neº budeme mluvit o v£ela°ské praxi, musíme si poloºit dv¥ základní a d·leºité otázky. Kdo to je v£ela°? A co vlastn¥ d¥lá? V£ela° je p°edev²ím chovatel a pozorovatel. Jako chovatel je velmi podobný b¥ºnému chovateli zví°at - nap°íklad chovateli koní, ps· nebo ovcí. Jako dobrý chovatel se snaºí chápat a porozum¥t svým sv¥°enc·m. Snaºí se s nimy ºít ve vzájemné symbióze a pomáhat jim. Stejn¥ jako v¥t²ina ostatních chovatel· musí um¥t pro své sv¥°ence (tedy v£ely) vybudovat p°íst°e²ky, °íkáme jim v£elí úly, musí um¥t v£ely nakrmit a ochránit p°ed predátory, jako jsou nap°íklad mravenci, sr²ni, my²i, rejskové a hmyzoºravé ptactvo. V£ela° se na rozdíl od chovatel· koní a ps· v¥nuje velmi detailn¥ okolní p°írod¥, ve které v£ely ºijí. Sleduje rozkv¥t v²ech druh· rostlin ve svém okolí a má p°ehled o pohybu teplot, tlaku a sráºek na svém stanovi²ti. Specialitou chovatele v£el je odebírání medu, jeho zpracování, skladování a následná distribuce - to v²e musí v£ela° v pr·b¥hu své práce sledova a zaji²óvat. Nakonec musíme zmínit i lé£ení v£elstev a vedení administrace spojené s chovem, coº je nezbytnou sou£ástí v£ela°ského provozu.

1.3 Stav v£ela°ení v R v roce 2009 K 31.12.2009 p·sobilo na území £eské republiky 44 768 v£ela°·, z toho pouze 141 v£ela°· chová p°es 150 v£elstev. V£ela° který chová 150 a více v£elstev je ozna£ován jako profesionální v£ela° a z pravidla je v£ela°ení jeho hlavní pracovní náplní, ostatní v£ela°i £asto chovají v£ely jen jako hobby. M·ºeme tedy prohlásit, ºe v£ela°ení v R je záleºitostí p°eváºn¥ zájmovou. Pro ilustraci dodejme, ºe 31 230 v£ela°· chová pouze jedno aº deset v£elstev v úlech umíst¥ných na své zahrádce nebo na chat¥. Pro více informací o statistikách v£ela°ství ke 31.12.2009 doporu£uji prostudovat [25].

1.4 Lze algoritmizovat v£ela°ské procesy? Nedocenitelnou výhodou provád¥ní jakékoli praktické, £i v¥decké práce v oblasti v£ela°ství je velmi kvalitní dokumentace v²ech v£ela°ských business proces·. Velmi dobrým zdrojem je nejen literatura (nap°íklad [16], [19] nebo [13]), ale i odborné internetové portály a diskuse. Komunita zájmových v£ela°· je v oblasti znalostí, které b¥hem svého ºivota nasbírala, velmi sdílná a v¥t²inou pln¥ chápe pot°ebu modernizace p°ístupu k chovu. Na za£átku své práce, jsem se detailn¥ zabýval otázkou, zda-li je v·bec moºné jednotlivé v£ela°ské úkony a procesy algoritmizovat a jejich b¥h podpo°it softwarovou aplikací? Jiº v první fázi p°íprav jsem zjistil, ºe drtivou v¥t²inu business proces· z této oblasti, lze velmi dob°e zachytit jako BPMN diagram (viz [22]). To nazna£uje, ºe v£ela°ské procesy jsou algoritmizovatelné, bohuºel jsou ale vstupem jednotlivých rozhodovacích struktur jsou velmi £asto data popisující aktuální po£así na stanovi²ti. Tato data, lze jen velmi obtíºn¥ získávat a musím bohuºel prohlásit, ºe práce s historií, sou£asným stavem a predikcí po£así by p°ekra£ovala moºnosti této práce. Nyní mám na mysli zejména £asové moºnosti a to jak £ást

1.5.

PRO MOBILNÍ TELEFONY?

3

na podrobné studium tak i algoritmizaci této problematiky. Dodejme ºe, zji²óvání t¥chto dat je moºné v sou£asném konceptu aplikace pouze dv¥ma cestami. První moºnost je automatické získávání dat z internetu, p°ípadn¥ z vlastních senzor· umíst¥ných na stanovi²ti. To by významn¥ zvý²ilo bu¤ provozní nebo výrobní náklady aplikace. Druhá moºnost spo£ívá v donucení uºivatele tyto hodnoty manuáln¥ m¥°it a zadávat do aplikace, coº by mohlo významn¥ zvý²it £asové náklady na provoz aplikace a uºitek (nap°íklad u²et°ený £as v plánování) z takto získaných dat, by mohl být niº²í neº £as vynaloºený na zadávání dat do aplikace.

1.5 Pro£ mobilní telefony? Pro£ vyvíjet v£ela°skou aplikaci jako aplikaci pro mobilní telefony? Odpov¥dí se nabízí hned n¥kolik. N¥které z nich si nyní popi²me. Prvním d·vodem je mobilita - v£ela° pracuje p°eváºn¥ v terénu, protoºe chovat v£ely v jakémkoli uzav°eném prostoru je v zásad¥ nemoºné. Dal²ím d·vodem je nezávislost na elektrické p°ípojce - v£ely se totiº £asto chovají v bezpe£né vzdálenosti od lidských obydlí a navíc se s nimy ko£uje k r·zným polím, nebo do les·. Takºe absence zdroje elektrického nap¥tí je z°ejmá. T°etím d·vodem pouºití mobilní aplikace je moºnosti vyuºití systému upomínek. Velkým problémem v£ela°·, jak bude vysv¥tleno dále, je zapomínání. V neposlední °ad¥ je také d·leºité zmínit, ºe mobilní telefon je dnes (2009) naprosto b¥ºn¥ pouºívané za°ízení, které narozdíl od osobního po£íta£e drtivá v¥t²ina v£ela°· vlastní a pouºívá.

1.6 Zdroje znalostí Pro tuto práci bylo vyuºito n¥kolik n¥kolik r·zných zdroj· znalostí. P°edev²ím se jednalo o pracovníky eského svaz v£ela°·, o. s. a pracovníky Výzkumného ústavu v£ela°ského v Dole, s.r.o, kte°í b¥hem vývoje a testování velmi ochotn¥ poskytli mnoºství cenných informací nejen z oblasti samotného chovu, ale i z oblastí s chovem p°ímo a nep°ímo souvisejících. Dal²ím významným zdrojem znalostí a informací byly rozhovory se v£ela°i, provád¥né b¥hem celého procesu vývoje a testování. Krom¥ lidských zdroj· byly také hojn¥ vyuºívány zdroje ti²t¥né a internetové. Více informací m·ºete najít v seznamu literatury.

4

KAPITOLA 1.

ÚVOD

Kapitola 2

Analýza v£ela°ské problematiky 2.1 Charakteristika cílového uºivatele V£ela°e lze v zásad¥ d¥lit podle dvou základních kritérií: podle velikosti jejich farmy (na velkov£ela°e a malov£ela°e) a podle jejich zku²eností a znalostí (na za£áte£níky a zku²ené chovatele). V rámci této práce bylo pouºito d¥lení podle velikosti v£elí farmy, protoºe je vzhledem ke zp·sobu podpory pomocí softwarové aplikace více relevantní. Byly tedy vypracovány dv¥ charakteristiky cílových uºivatel·, malov£ela° a velkov£ela°. B¥hem realizace jsem se pozd¥ji zam¥°il více na podporu malov£ela°·, protoºe je jich v R n¥kolikanásobn¥ více, neº velkov£ela°· (viz kapitola 1.3) a také proto, ºe v¥t²ina velkov£ela°· v sou£asné dob¥ jiº pouºívá r·zné typy vlastního zp·sobu administrace a zápis· - od papírové administrace, aº po komplikované tabulky v programu MS Excel. Bohuºel v¥t²ina z nich neprojevila zájem v¥novat se diskusím a testování tohoto softwaru. Návrh aplikace v²ak pracuje s ob¥ma charakteristikami.

2.1.1 Malov£ela° Za malov£ela°e budeme povaºovat kaºdého b¥ºného chovatele, který má jedno, nebo dv¥ stanovi²t¥ a celkový po£et jeho v£el je zhruba do 10, maximáln¥ do 15 v£elstev. Dal²ím významným znakem malov£ela°e je ru£ní práce a tém¥° ºádná automatizace provozu. Nap°íklad vytá£ení medu probíhá na medometu s ru£ním pohonem (klika), va°ení cukerného roztoku, který je pot°eba pro krmení je realizované v domácí kuchyni v b¥ºném hrnci, apod. Umíst¥ní úl· je zpravidla na konci zahrádky, nebo na chat¥ a neprovádí ko£ování (tj. p°esun v£elstev k práv¥ kvetoucím polím a sad·m za ú£elem zvý²ení medného zisku). Malov£ela°i mají tém¥° vºdy chov jako koní£ek. Jejich hlavním cílem bývá £asto pouze medný zisk, a opylení hmyzosnubných rostlin na své zahrádce. Z hlediska znalostí a zku²eností mohou být malov£ela°i jak za£áte£níky v chovu v£el, tak i zku²enými chovateli. I p°esto, ºe se v této skupin¥ pohybují opravu velmi zku²ení v£ela°i, z globálního hlediska stále platí fakt, ºe tato skupina v£ela°· se b¥ºn¥ nezabývá ²lecht¥ním a chovem v£elích matek a nemá tak hluboké znalosti z biologie v£el, fenologie a botaniky.

5

6

KAPITOLA 2.

ANALÝZA VELASKÉ PROBLEMATIKY

2.1.2 Velkov£ela° Za velkov£ela°e budeme povaºovat kaºdého v£ela°e, který se chovem v£elstev ºiví - jedná se o jeho hlavní p°íjem. Po£et v£elstev by m¥l být vy²²í neº 150. S tímto po£tem v£elstev lze p°edpokládat, ºe velkov£ela° bude mít více, neº 4 stanovi²t¥. Dal²ím typickým znakem je vysoká automatizace provozu - od programovatelných medomet· pohán¥ných motory, p°es varné soustavy na krmivo, za°ízení na vyva°ování vosku aº k pln¥ automatizovaným výtá£ecím linkám. Velkov£ela° chová v¥t²inu svých v£elstev na stanovi²tích, která jsou ekonomicky výhodná a ko£uje s nimy. K tomu je pot°eba dobrý £asový management a za°ízení pro efektivn¥ p°esuny velkého po£tu v£elstev najednou, nap°íklad paletové systémy, nebo u nás velmi roz²í°ené ko£ovné maringotky. Velkov£ela° t¥ºí zpravidla ze v£el v²e, co t¥ºit lze (med, vosk, propolis, mate°í ka²i£ka, jed a plemenný materiál). U tohoto typu chovatele m·ºeme p°edpokládat, ºe se jedná vºdy o zku²eného v£ela°e s rozsáhlej²ími znalostmi v oblastech biologie v£el, fenologie, botaniky apod.

2.2 Business procesy v oboru v£ela°ství Po úvodní £ásti popisující cílové uºivatele, si popí²eme základní business procesy, které v£ela°ovu práci provází. V kapitole 1.4 jsme se snaºili odpov¥d¥t na otázku, zda-li lze algoritmizovat v£ela°ské procesy? Zjistili jsme, ºe to moºné je, ale pokud je vstupní paramater ur£ité rozhodovací struktury stav aktuálního po£así, m·ºe nastat problém. Tento problém byl °e²en v zásad¥ t°emi r·znými zp·soby. Procesy, kde je vliv po£así nezanedbatelným faktorem jsem se snaºil rozd¥lit na men²í úseky, které uºivatel spou²tí samostatn¥, podle své pot°eby. Pokud tento princip d¥lení nebylo moºné aplikovat, volil jsem opa£ný p°ístup. Zvý²il jsem míru abstrakce na takovou úrove¬, kde po£así jiº tolik nerozhoduje. Nap°íklad p°i chovu matek nevíme,jestli oplození nové mati£ky prob¥hne do dvou dn· nebo dvou týdn·. Po£así je zde hlavní faktor a akt oplození nelze rozd¥lit na více £ástí. Pokud ani jedna z moºností nebyla vhodná, pouºíval jsem triku, kde v£ela° akci nejprve provede, a aº pozd¥ji pouºije software jako zápisník provedené akce. S pomocí t¥chto t°í princip· m·ºeme prohlásit, ºe v¥t²inu v£ela°ských proces· provád¥ných b¥ºným v£ela°em se poda°ilo algorytmizovat a lze je podpo°it pomocí softwaru. V rámci této práce jsem vypracoval n¥kolik základních BPMN diagram·. Diagramy jsem rozd¥lil do skupin podle fází v£ela°ského roku, uve¤me si nejprve jejich seznam:

• Jaro, r·st v£elstva

Jarní prohlídka Jarní ru²ení v£elstva Vým¥na dna

• Léto, vedení v£elstva

Proti rojová opat°ení Medobraní Chycení a usazení roje

2.3.

SPECIFIKACE PROBLÉM A POTEB CÍLOVÝCH UIVATEL

7

• Podletí, p°íprava na zimu

Krmení v£elstva Podletní prohlídka Podletní ru²ení v£elstva

V²echny tyto diagramy m·ºete najít v p°íloze D na stránce 75. Zkusme se nyní alespo¬ na jeden z diagram· podívat podrobn¥ji a doplnit jej o velmi stru£ný výklad.

2.2.1 BPMN - Medobraní Podíváme-li se na diagram 2.1, uvidíme t°i pooly - tedy t°i r·zné pohledy na pracovní proces medobraní. První z nich je samotná v£elí kolonie, která £eká na vydatnou sn·²ku nektaru. Za vydatnou sn·²ku m·ºeme povaºovat nap°íklad rozkv¥t pole plného °epky, nebo strá¬ rozkvetlých akát·. Jakmile rostliny za£nou poskytovat nektar, v£elstvo jej sebere, p°em¥ní na med a uloºí do medníku. Medník je sou£ást úlu, kam v£ely ukládají med - zpravidla se jedná o horní t°etinu, nebo horní polovinu úlu. Jakmile med v medníku vyzraje, v£elstvo jej za£ne ví£kovat. B¥hem sb¥ru nektaru a zrání medu je v£ela°ovou prací kontrolovat medník a vy£kávat, neº bude £as jej odebrat. V£ela° plánuje kontroly medníku podle po£así na stanovi²ti a svého odborného úsudku. Nelze p°esn¥ denovat, kdy p°esn¥ kaºdá dal²í kontrola bude. Jakmile p°ijde £as, odebere se v£elám medník. Je velmi £astým zvykem, a to i u malov£ela°·, ºe vytá£ení medu se provádí ve dvou. Jako pomocník £asto pracuje v£ela°·v partner nebo jeho d¥ti, p°ípadn¥ vnuci. V£ela° p°edává plné medníky pomocníkovy, který se postará o odví£kování. Má-li v£ela° k dispozici medníky rezervní, ihned po sejmutí plného medníku jej rychle nahradí prázdným rezervním medníkem. Pokud rezervní medník není k dispozici, musí v£ely po£kat aº bude med vyto£en a medník dostanou zp¥t aº po vyto£ení. Pomocník dostává medník plný zaví£kovaných zásob medu. Jakmile je odví£kuje vloºí je do medometu a med vyto£í. Pak ho zcedí a sto£í do sud·. Tím jeho práce kon£í. Pomocník

1 a m¥l by pouze obsluhovat medárnu.

by teoreticky nem¥l p°ijít se v£elami fyzicky do styku

Za medárnu povaºujeme místnost, kde se med stá£í. Celý proces kon£í, jakmile mají v£ely zp¥t sv·j medník a med je sudech, nebo konvích p°ipraven k a²kování a následné distribuci.

2.3 Specikace problém· a pot°eb cílových uºivatel· Analýza business proces· ve v£ela°ství poskytla p°edev²ím vymezení základních £inností, které v£ela° b¥hem roku provádí. Jedná se o první p°iblíºení toho, co by bylo dobré zachytit a podpo°it. B¥hem studia t¥chto proces· vy²la najevo první sada pot°eb a kritických situací, se kterými se v této oblasti setkáváme. Nyní si tyto problematické situace zkusme podrobn¥ji nastínit. Nejprve si vºdy popí²eme situaci a po té uvedeme vý£et problém·, které v takové situaci mohou nastat.

V praxi bohuºel není moºné být na v£ela°ské farm¥ a nep°ijít se v£elami do styku. Zbloudilé v£ely m·ºete nalézt ve£er v posteli i ráno v kuchyni. 1

8

KAPITOLA 2.

Obrázek 2.1:


BPMN - Medobraní

2.3.


9

2.3.1 Zápisy, pozorování a plánování Podstatnou £ástí v£ela°ovi práce je pozorování a hodnocení. Pozorování v£el, pozorování stanovi²t¥, rostlin, vývoje po£así apod. Pe£livé pozorování ale p°iná²í výsledky jen, kdyº z n¥j máme kvalitní zápisky a poznámky. Zde naráºíme na první kritický bod. Kdyº v£ela° své v£ely pozoruje, musí si d¥lat poznámky. Správný v£ela° by si m¥l poznamenat kaºdý zásah, p°i kterém p°i²el se v£elami do styku, i kdyº by ²lo i úplnou trivialitu, jakou je t°eba jen vým¥na dna úlu. V£ela°i mají £asto problém s mnoºstvím papírk· a se²it·, které pouºívají. Poznámky jsou obvykle psané zkratkami, kterým rozumí jen oni. Celá dokumentace se pak nap°íklad p°i p°edávání nebo prodeji musí de²ifrovat. Je²t¥ v¥t²í problémy pak nastávají, kdyº papírky a se²ity nemají a spoléhají na svou pam¥´. Typickým p°íkladem je, ºe v£ela° prohlédne 10 v£elstev a pak si sedne ke stolu a chce si zapsat výsledky. Není si ale v·bec jist, jestli daný jev nastal u v£elstva £íslo 4 nebo 5? Dal²ím d·leºitým pravidlem kaºdého dobrého chovatele v£el je rychlost a p°ipravenost. ím déle, nebo £ast¥ji v£ely vyru²ujeme tím, h·°e a hlavn¥ déle se z toho vzpamatovávají a nenosí ºádný med. V£ela° proto kaºdý zásah p°ed jeho provedením pe£liv¥ naplánuje, a snaºí se ho provést co nejrychleji. Kdyº je to jen trochu moºné snaºí se na jedno otev°ení v£el provést co nejvíce zákrok·, aby dal²í vyru²ení nastalo za co nejdel²í dobu. ím mén¥ zákrok· mu na o²et°ování v£elstva b¥hem roku sta£í, tím lep²í poskytuje svým v£elám podmínky.

2.3.2 Vytvá°ení, ru²ení v£elstev a vým¥na matek Práce se v£elami není jen pozorování p°írody a odebírání medu. Nemén¥ podstatná je £innost ²lechtitelská. B¥hem roku se v£ela° musí £asto rozhodovat o tom, zda-li není vhodné v£elstvo zru²it, nebo spojit s jiným v£elstvem. P°i tomto rozhodování musí £asto procházet dokumentaci a hledat s kterým v£elstvem je vhodné ru²ené v£elstvo spojit? Nebo zda-li ho v·bec ru²it? Nap°íklad pokud v£ela° najde v dokumentaci, ºe v£elstvo produkuje málo medu, ale má vydatný stavební pud, m·ºe se z n¥j stát v£elstvo ur£ené k produkci vosku. P°irozené rozmnoºování v£elstev probíhá pomocí mechanizmu rojení. Rojení se ale v£ela° snaºí ze v²ech sil zabránit a pokud je úsp¥²ný, v£elstva se nerojí. V takovém p°ípad¥ se pak provádí alternativní (um¥lý) zp·sob rozmnoºování v£elstev, nap°íklad tvorbou smetence nebo odd¥lku. P°i takové £innosti m·ºe nastat problém se znalostí inventá°e. Nejedno v£elstvo se jiº ocitlo kv·li nedostatku úl· v papírové krabici. P°ed tím, neº se v£ela° rozhodne odd¥lek vytvo°it by m¥l v¥d¥t, zda-li je k dispozici dostatek úl·, krmítek apod. Velmi d·leºitým parametrem v£elstva je stá°í a stav jeho matky. Matky je t°eba po ur£ité dob¥ m¥nit. V£ela° je m·ºe chovat sám, nebo je kupovat z v£ela°ských farem zam¥°ených na jejich chov. A´ tak nebo tak, jejich vým¥ny musí provád¥t zhruba kaºdé dva roky, protoºe star²í matky ztrácí svou výkonnost. Vým¥na matky musí probíhat p°esn¥ podle zvolené metodiky. Metodika pak vymezuje rozmezí dn·, ve kterých se mají provád¥t ur£ité úkony. Pokud v£ela° na n¥který úkon jednodu²e zapomene, nastane problém. A problém s matkou m·ºe být pro v£elstvo velmi kritický. U v²ech t¥chto zásah·, by m¥l mít v£ela° detailní p°ehled o stavu svých v£elstev. Je t°eba znát faktory jako jsou: rojivost, bodavost, stavební pud apod. Je nezbytn¥ nutné znát dosavadní výnosy medu a vosku, p°ípadn¥ i propolisu. Také je vhodné mít p°ístup dal²ím

10

KAPITOLA 2.


parametr·m, jejichº vysv¥tlení by p°ekra£ovalo rámec této práce, nap°íklad parametry související k dispozicím v£elstva k ur£itým chorobám, nebo odolnosti proti v£elím parazit·m. V²echny tyto parametry spolu se v£ela°ovou zku²eností nakonec rozhodují, které v£elstvo bude dále mnoºeno (bude z n¥j odebírán plemenný materiál), a které v£elstvo se nevyplácí chovat.

2.3.3 Chov matek V p°edchozí kapitole o ²lechtitelské práci jsme se jiº zmínily o chovu matek. Víme ºe je v£ela° m·ºe chovat sám. Na rozdíl od chovu v£elstev je to ale n¥kolikanásobn¥ t¥º²í práce a to jak z hlediska biologie a genetiky, tak i z hlediska administrace a plánování. Chovatelé matek odevzdávají na rozdíl od b¥ºných v£ela°· podrobné výkazy o plemenných v£elstvech, kde pracují se £ty°stup¬ovým hodnocením vlastností v£elstev a vypo£tenými indexy a ukazateli k biologickým dispozicím matky. Matka je základ celého v£elstva jelikoº v²echny ostatní v£ely jsou její potomci, a tudíº d¥di£ky jejího genofondu. Chovu matek se p°ikládá ve v£ela°ství velká váha a s tím je spojeno i mnoho papírování. ást administrace, jako nap°íklad genealogické stromy apod. je nepovinná, ale velmi uºite£ná. Druhá £ást dokumentace, jako nap°íklad výkaz o chovu matek, úlové výkazy apod. je v R povinná. Typickým problémem chovu matek je zapomínání a ²patné plánování. Pro ilustraci si m·ºete prohlédnout plán chovu matek v tabulce 2.1. Tento plán je nutné z biologické podstaty líhnutí matky dodrºet, ov²em je velmi snadné na n¥který úkon zapomenout a t¥º²í je to o to víc, £ím více matek chováme.

Den Akce -4

Vloºení sou²e pro zakladení chovnou matkou

0

P°íprava sádky, vloºení p°elarveného plemeniva

1

P°eloºení série do medníku dochovného v£elstva

2-3

Moºné p°emísóvání mate£ník·

5-6

Moºná kontrola zaví£kování

10

kolkování mate£ník·

12

Líhnutí matek

13

Zna£ení a zuºitkování matek Tabulka 2.1: asový rozvrh vývoje matek

2.3.4 Medobraní a prodej medu, vosku Základem komer£ního pojetí v£ela°ení je odb¥r v£elích produkt·. Hlavním v£elím produktem je med, ale nemén¥ významnými produkty jsou nap°íklad vosk, propolis mate°í ka²i£ka nebo t°eba i pyl. V£ela°ovou prací je nejprve pozorování stavu zásob jednotlivých produkt· a to v kaºdém úlu zvlá²´. Následuje odb¥r, zpracování a distribuce. Kaºdý ze v£elích produkt· se odebírá a zpracovává jiným zp·sobem. V sou£asné dob¥ je klí£ovým v£elím produktem med, pov¥zme si tedy n¥co víc o tom, co s v²e musí v£ela° zvládnout, neº Vám podá do rukou sklenici plnou £istého a kvalitního medu.

2.3.


11

Nejprve je t°eba rozli²it které v£elstvo bude produk£ní. Volba v£elstva závisí na statistice produkce z minulého roku, kterou je t°eba mít. Takové v£elstvo je pak celé p°edja°í a jaro chováno tak, aby ve chvíli rozkv¥tu v£ela°sky významných plodin m¥lo co nejvy²²í moºný po£et d¥lnic, to v²e je pot°eba sledovat a v p°ípad¥, ºe v£elstvo není v dostate£ní síle, je vhodné s ním naloºit jinak. Jakmile v£elstvo za£ne sbírat nektar a produkovat med, v£ela° jej odebírá, cedí a stá£í do sud·. V sudech m·ºe med zkrystalizovat, coº se u kvalitního medu d¥je velmi £asto. Pak je nutné med rozeh°ívat a ztekucovat tak, aby ho bylo moºné ze sudu sto£it. Ztekucování se d¥je v ur£itém p°esn¥ daném rozmezí teplot a £asu. V£ela° m·ºe z medu vyráb¥t i druhovýrobky jako jsou nap°íklad med s mate°í ka²i£kou, nebo o°í²ky v medu. V¥t²ina v£ela°· se ale zam¥°uje na produkci £istého medu, nebo medu pastovaného. Pastování je mechanické roz²lehání medu b¥hem jeho krystalizace v p°edem ur£ených £asových intervalech. Pastovaný med pak dále nem¥ní svou konzistenci. P°i práci se skladem medu nastává drtivá v¥t²ina problém·, protoºe mnoho malov£ela°· nemá p°íli² zku²eností s efektivním vedením skladu. asto se stává, ºe n¥kte°í v£ela°i ani neví, kolik medu na sklad¥ je a kolik ho mohou je²t¥ prodat. Na odb¥ratele tento fakt £asto nep·sobí dob°e. Pokud má být med prodáván p°ímo kone£nému odb¥rateli je vhodné jej sto£it do men²ích sklenic. Musí se zvolit a nakoupit vhodná velikost sklenic a nalepit etikety. Zde je d·leºité v¥d¥t z jakých rostlin med pochází (med akátový, lesní, lu£ní nebo i smí²ený) a kdy byl sto£en, aby bylo moºné ur£it dobu trvanlivosti. Bez kvalitních záznam· a dob°e vedeného skladu se v této fázi provádí jakási magie, která £asto kon£í tím, ºe ve sklenicích s etiketou Kv¥tový med 2009 je medovicový med z roku 2008. Jakmile je med ve sklenicích, v£ela° musí zvolit vhodný druh reklamy a p°ilákat klienty, kterým pak r·zné druhy medu prodává za r·zné ceny. Je d·leºité znát p°esn¥ zisky z prodeje medu, aby bylo moºné ud¥lat na konci roku kone£nou bilanci. Nap°íklad lze pak zjistit, který druh a typ produkovaného medu je nejvýnosn¥j²í a na jeho produkci se v dal²ím období zam¥°it. Do fáze výsledné bilance, se ale uº dostane jen málokterý v£ela°.

2.3.5 Krmení v£elstev Krmení v£elstev je proces provád¥ný po posledním medobraní. V£ely totiº nevytvá°ejí zásoby medu pro svého chovatele, ale sami pro sebe, aby m¥ly co konzumovat v obdobích, kdy v p°írod¥ není dostate£ný zdroj nektaru. Pokud jim v£ela° ze zjevných komer£ních d·vod· med násiln¥ odebere, musí jim poskytnout náhradu. Krmí se nej£ast¥ji rozva°eným roztokem krystalového °epného cukru a vody v pom¥ru 3:2. Krmivo se v£elstvu podává v krmítkách r·zných objem·, lze nap°íklad krmit i 4 litrovými zava°ovacími sklenicemi. V£ela° vºdy krmí v£ely na p°edem stanovenou hodnotu podle síly v£elstva. Zpravidla krmíme na 12 aº 18 litr·. Z toho je z°ejmé, ºe se krmení musí rozloºit na n¥kolik £ástí. Není dobré kdyº zapomeneme a v£elstvo podrkmíme, nebo díky zmatku v poznámkách na papírovém ubrousku, který jsme m¥li p°i prvním krmení v kapse, v£elstvo p°ekrmíme.

12

KAPITOLA 2.


2.3.6 Administrace a statistika O d·leºitosti vedení kvalitní dokumentace jsme se jiº zmínili v p°edchozích odstavcích této kapitoly. Dodejme proto hlavn¥ to, ºe £ást dokumentace chovu je v R povinná a proto je t°eba, ji za kaºdou cenu na konci roku odevzdat. Nevedeme-li si dokumentaci poctiv¥, nezbývá na konci roku nic jiného, neº zp¥tný hrubý odhad - tedy v£ela°ská administrativní magie. Tím ov²em jen dále roz²i°ujeme zmatek, který v chovu panuje.

2.4 Specikace cíl· Nyní, kdyº uº máme základní pov¥domí o kritických místech a problémech v£ela°ské práce, stanovme si £ty°i základní cíle pro vývoj na²í aplikace. Napln¥ní t¥chto cíl· by m¥lo p°edejít problém·m popsaným v p°edchozí kapitole a usnadnit tak v£ela°·m jejich práci. Z hlediska hlavní motivace této práce uvedené v kapitole 1.1, by napln¥ní t¥chto cíl· m¥lo sníºit náklady na provoz v£ela°ského chovu a to zejména náklady £asové.

2.4.1 Vedení administrace chovu a plánování akcí Aplikace by m¥la poskytovat rozhraní pro vedení administrace v²ech základních v£ela°ských aktivit, jako jsou nap°íklad: prohlídky, krmení, roz²i°ování a zuºování, tvo°ení nových v£elstev, vým¥na matky, nebo medobraní. Dále by m¥la umoº¬ovat plánování £asov¥ náro£n¥j²ích v£ela°ských akcí a v p°ípad¥ pot°eby by m¥la um¥t poskytovat ve²keré údaje spojené s konkrétním v£elstvem, které jsou pot°eba p°i rozhodování o chovu a ²lecht¥ní.

2.4.2 Správa prodeje v£elích produkt· Prodej a distribuce v£elích produkt· je manaºersky velmi náro£ná práce. Aplikace by proto m¥la umoº¬ovat vést jednoduchou administraci skladovaného, objednaného a prodaného medu. Bylo by více neº vhodné aby um¥la po£ítat výnosnost celého podniku, medný výt¥ºek z konkrétního v£elstva, nebo predikovat výnosy na p°í²tí rok.

2.4.3 Administrace v£ela°ského inventá°e Správa v£ela°ského inventá°e je d·leºitá £innost kaºdého provozu. Databáze inventá°e by m¥la evidovat r·zné druhy vybavení, které jsou pro v£ela°ení nezbytné a m¥la by poskytovat snadný p°ehled o nasazených i rezervních zásobách vybavení jako jsou nap°íklad: úlové sou£ásti, sklenice na stá£ení medu nebo krmítka.

2.4.4 Automatické vytvá°ení povinných formulá°· Jednou z nejd·leºit¥j²ích £ástí aplikace by m¥lo být pln¥ automatické vytvá°ení v²ech formulá°· nutných jak pro zájmový, tak pro profesionální chov v£el. Aplikace by m¥la um¥t sbírat po celý rok data, a na konci roku kliknutím na jediné tla£ítko vytvo°it ve²kerou pot°ebnou dokumentaci, která je v R vyºadována.

2.5.

13

EXISTUJÍCÍ SOFTWARE

2.5 Existující software Z konzultace dne 11.9.2009 se zástupci SV vyplynulo, ºe zatím neexistuje ºádný dostupný software pro podporu základních úkon· v£ela°e, který lze spustit na mobilním telefonu. Toto tvrzení bylo ov¥°eno pátráním na internetu a nakonec se ukázalo, ºe v sou£asné dob¥ je pravdivé (duben 2010). Existují v²ak r·zné v£ela°ské softwary ur£ené pro osobní po£íta£e, konkrétn¥ pro opera£ní systém Microsoft Windows. Podívejte se nyní na n¥které z nich.

2.5.1 EDBi EDBi je velmi roz²í°ený v£ela°ský software od Jorna Johanessona z Dánska. Celý software je zdarma a je p°eloºen ne n¥kolika sv¥tových jazyk· a to i do £e²tiny. Bohuºel v R není p°íli² populární pro svou sloºitost ovládání. Ukázky si m·ºete prohlédnout na obrázku 2.2. Výhodou EDBi je podpora chovu matek, a obsáhlé moºnosti psaní úlových poznámek. Nevýhodou je neintuitivní ovládání a nesoulad s £eskými normami hodnocení v£elstev. Pro více informací o tomto programu m·ºete hledat v [17].

Obrázek 2.2:

EDBi screenshot

2.5.2 BKeeping BKeeping je software vyvinutý Keithem McIlvridem z Austrálie. Jedná se o placený software s moºností 60ti denní shareware verze. Uºivatelská p°ív¥tivost aplikace je na mnohem vy²²í úrovni, neº v p°edchozí aplikace. BKeeping obsahuje v¥t²inu v²ech pot°ebných funkcí, které by v£ela°ská aplikace m¥la mít. Bohuºel zatím není p°eloºen do £e²tiny. Ukázky si m·ºete prohlédnout na obrázku 2.3. Pokud by jste cht¥li software vyzkou²et, více informací m·ºete nalézt v [20].

14

KAPITOLA 2.


Obrázek 2.3: BKeeping screenshot

2.5.3 V£elár 2.0 Posledním program, který byl v rámci této práce testován je velmi zda°ilý software slovenského v£ela°e s p°ezdívkou fraky. K dispozici je pouze slovenská verze, to by ale pro £eské uºivatele nem¥l být ºádný problém. V£elár je nejen administra£ním nástrojem, ale obsahuje také mnoºství návod· a teoretických £lánk·, které souvisejí s v£ela°stvím. Jedná se o velmi obsáhlý produkt, který je modulárn¥ £len¥n pomocí DLL knihoven. Uºivatelské rozhraní je tomu úm¥rn¥ sloºité, ale i tak z·stává ve v¥t²in¥ míst intuitivn¥ ovladatelné. Screenshot si m·ºete prohlédnout na obrázku 2.4 a podrobn¥j²í studium je moºno provést v [12].

2.6 Specikace poºadavk· 2.6.1 Funk£ní poºadavky Specikace poºadavk· byla denována pomocí metody storyboard·. Tato metoda byla zvolena pro její názornost, jednoduchou interpretaci a p°ehlednost a také proto, ºe není lehké zachytit funk£ní poºadavky pouze pomocí seznamu vlastností, bez uvedení kontextu. Storyboardy nám poskytly moºnost zachytit nejen akce které má aby aplikace provád¥t, ale i kontext ve kterém jsou provád¥ny. Dal²ím d·vodem pouºití storyboard· byla moºnost jejich vyuºití p°i prezentaci práce t°etím osobám. Také byly pouºívány jako podklady pro diskuse o zp·soby nasazení aplikace v praxi. Nejprve si uve¤me seznam v²ech storyboard· které byly v rámci práce vytvo°eny. Pro p°ehlednost si je op¥t rozd¥lme podle v£ela°ských období.

• Jaro, r·st v£elstva

Jarní prohlídka Spojování v£elstev

2.6.

SPECIFIKACE POADAVK

15

Obrázek 2.4: V£elár 2.0 screenshot

• Léto, vedení v£elstva

Chov matek

Vytvo°ení odd¥lku

Medobraní

Prodej medu

Zdravotní stav v£el

• Podletí, p°íprava na zimu


Osi°ení

• Podzim a zima

Krmení v£elstva


Podletní ru²ení v£elstva

Kompletní storyboardy m·ºete nalézt v p°íloze C na stránce 65. Jako p°íklad si zde uve¤me alespo¬ jeden z nich. Zvolme si op¥t problém medobraní, abychom mohli plynule navázat na BPMN diagram 2.1 z minulé kapitoly. Storyboard je zachycen na obrázku 2.5 a je sám o sob¥ velmi jednodu²e £itelný a pochopitelný, proto k n¥mu není t°eba dopl¬ovat ºádný popis.

16

KAPITOLA 2.


2.6.2 Nefunk£ní poºadavky Nefunk£ní poºadavky, byly zvoleny s ohledem na koncept uºivatelského rozhraní a pouºité framework·m. I kdyº jsme si o uºivatelském rozhraní a implementaci systému je²t¥ nic ne°ekli, nefunk£ní poºadavky si v rámci zachování standardní struktury denice poºadavk· uve¤me jiº nyní. Software tedy vyºaduje pro sv·j b¥h mobilní telefon s t¥mito parametry:

1. Java ME CLDC 1.0 (viz [2]). 2. Java ME MIDP 2.0 (viz [6]). 3. Alespo¬ 14 MB pam¥ti v telefonu. 4. Standardní klávesnice se stisknutelným k°íºovým ovlada£em a dv¥ma funk£ními tla£ítky, nebo dotykový display. 5. Barevný display s minimálním rozli²ením 240x320 px.

Dodejme, ºe nefunk£ní parametry byly zvoleny vzhledem k p°edpokladu, ºe v sou£asné dob¥ (2010) se za°zení spl¬ující tyto poºadavky více a více roz²i°ují a dokonce tyto poºadavky p°ekonávají. V dohledné dob¥ by m¥ly být tyto poºadavky spln¥ny v¥t²inou telefonních p°ístroj·.

2.6.

SPECIFIKACE POADAVK

Obrázek 2.5: Storyboard - Medobraní

17

18

KAPITOLA 2.


Kapitola 3

Návrh uºivatelského rozhraní V minulé kapitole byly pro na²í aplikaci denovány funk£ní a nefunk£ní poºadavky. Zde se pokusíme zvolit vhodnou formu uºivatelského rozhraní, které by m¥lo tyto poºadavky naplnit. Nejprve si popí²eme, jak lze provést základní roz£len¥ní aplikace na jednotlivé sekce, podsekce a koncové akce. Popí²eme první papírový prototyp a vyhodnotíme jeho evaluaci. Dále si p°edstavíme dv¥ verze prototypu, který lze spustit p°ímo na mobilním za°ízení a op¥t se seznámíme s jejich evaluací. Nakonec se pro kompletní otestování aplikace podíváme je²t¥ na evaluaci provedenou p°ímo v terénu a opat°ení, které z ní vyplývají.

3.1 Anity diagram Jedním z prvních krok· vedoucím k vypracování uºivatelského rozhraní byl návrh anity diagramu. Tento diagram rozd¥luje v²echny akce, které aplikace uºivateli poskytuje, do hierarchické struktury. V zásad¥ byly v²echny v£ela°ské akce rozd¥leny do n¥kolika základních skupin. Tyto skupiny pak byly dále £len¥ny na podskupiny. Finální anity diagram byl vypracován pro p¥t základních skupin aº do nejmen²ích detail·. Jeho rozsah je v²ak p°íli² velký, neº aby se ve²el na jeden nebo dva listy formátu A4. Protoºe jsme se v p°edchozích kapitolách práce zabývali podrobn¥ problematikou medobraní, bude v jejím popisu pokra£ovat a uvedeme si zde alespo¬ malou výse£ z anity rozsáhlého diagramu, která problematiku medobraní zahrnuje (obrázek 3.1). Na vý°ezu z diagramu je vid¥t n¥kolik pomocných symbol·. Symbol tuºky nazna£uje, ºe akce vede k formulá°i, kde m·ºe uºivatel libovoln¥ m¥nit hodnoty. Zm¥na v tomto formulá°i se v zásad¥ nepromítne do jiných £ástí programu. Symbol kouzelné h·lky nazna£uje, ºe se jedná o pr·vodce. Pr·vodce zpravidla vede uºivatele v n¥kolika krocích a po svém ukon£ení zm¥ní data ve více £ástech programu. Symbol £ervené ²ipky pak nazna£uje ve které £ásti programu dojde k dané zm¥n¥. Pro vytvo°ení diagramu byl pouºit program FreeMind 0.8.1 ur£ený primárn¥ pro tvorbu my²lenkových map. Uváºíme-li fakt, ºe anity diagram má v podstat¥ seskupovat jednotlivé akce do skupin podle toho jak moc spolu vzájemn¥ souvisejí, je z°ejmé, ºe je my²lenkové map¥ velmi blízký. Více informací o tomto programu naleznete v [21].

19

20

KAPITOLA 3.

Obrázek 3.1:

NÁVRH UIVATELSKÉHO ROZHRANÍ

Anity diagram - Medobraní

3.2 Papírový prototyp Následujícím krokem tvorby uºivatelského rozhraní bylo vytvo°ení papírového prototypu, který pokrýval základní akce z oblasti chovu v£elstev, správy inventá°e, administrace produkce a krmiva, statistiky, ú£etnictví a plánování událostí. Prototyp byl vytvo°en pomocí demo verze programu Balsamiq Mockups 1.6.67. Pro hlub²í seznámení s papírovým prototypem je vhodné prohlédnout si jej ve form¥ klikacího PDF. Soubor se jmenuje a naleznete jej na p°iloºeném CD v adresá°i

\papirovy_prototyp.

papirovy_prototyp.pdf

Jedním ze základních rys· uºivatelského rozhraní bylo rozd¥lení v²ech akcí do dvou r·zných skupin: zobrazování informací a provád¥ní akcí. Toto d¥lení m¥lo slouºit ke snadn¥j²ímu pochopení, co která akce zp·sobí. Ukázky si m·ºete prohlédnou na obrázku 3.2.

3.2.

21

PAPÍROVÝ PROTOTYP

Obrázek 3.2:

Ukázky z papírového prototypu

22

KAPITOLA 3.


3.2.1 Cíl prototypu Hlavním d·vodem vytvo°ení prototypu bylo vyhledání kritických míst v uºivatelském rozhraní. Za kritické místo budeme povaºovat jakékoli místo aplikace, které nelze intuitivn¥ ovládnout. Pro testování nad tímto prototypem byly v souladu s d·vodem jeho vytvo°ení denovány díl£í/specické cíle. Uve¤me si jejich seznam: 1. Zjistit, jestli se uºivatelé dokáºí zorientovat v menu a nalézt ke kaºdou poºadovanou akci. 2. Ov¥°it, zda-li si uºivatel pod kaºdým zvoleným pojmenováním akce, nebo popiskem formulá°e p°edstaví opravdu to, co bylo p°i tvorb¥ prototypu o£ekáváno. 3. Ov¥°it, zda-li uºivatel v rámci aplikace chápe rozd¥lení na zobrazování informací a provád¥ní akcí.

3.2.2 Vyhodnocení evaluace a výsledná opat°ení Evaluace papírového prototypu probíhala v rámci prvního kola testování popsaného v kapitole 5.1.1 na stran¥ 41, kde m·ºete také nalézt její záv¥r. Zde si uve¤me pouze seznam opat°ení, která byla provedena na základ¥ vý²e odkazovaných výsledk· evaluace.

•

Rozd¥lení na zobrazování informací a provád¥ní akcí bylo kv·li naprostému nepochopení odstran¥no z celé aplikace.

•

Bylo kompletn¥ p°epracováno rozhraní v£ela°ského inventá°e. Odstran¥no bylo sloºité nastavování rozm¥r· a byla zvý²ena úrove¬ abstrakce.

•

Byla zavedena podpora pouze pro nástavkový systém v£ela°ení v celé aplikaci.

•

Prob¥hlo roz²í°ení sekce zabývající se produkcí a zásobami o dal²í v£elí produkty.

Výsledkem t¥chto zm¥n byla druhá verze papírového prototypu, která jiº neslouºila dal²í evaluaci, nýbrº návrhu prvního funk£ního prototypu, který si popí²eme v následující kapitole.

3.3 High delity prototyp 0.1 Po úsp¥²ném vytvo°ení, otestování a p°epracování papírového prototypu byl navrºen první prototyp spustitelný p°ímo na mobilním telefonu. Implementace je popsána v samostatné kapitole 4 (strana 29). Ukázky prototypu si m·ºete prohlédnout na obrázku 3.3.

3.3.1 Cíle prototypu Hlavním cílem prvního prototypu, spustitelném na reálném za°ízené, bylo otestování ovládání uºivatelského rozhraní. Je z°ejmé, ºe ovládání aplikace je v rámci mobilního telefonu velmi specické a papírový prototyp nedokáºe odhalit chyby, které jsou s ním spojené. Od této chvíle byla jediným prost°edkem interakce uºivatele a na²í aplikace klávesnice a display mobilního za°ízení. Vzhledem k vý²e uvedenému hlavnímu cíli bylo pro evaluaci op¥t stanoveno n¥kolik specických cíl·:

3.3.

HIGH FIDELITY PROTOTYP 0.1

Obrázek 3.3:

Ukázky z high delity prototypu

23

24

KAPITOLA 3.


•

Ov¥°it jestli je vhodn¥ zvolena velikost písma.

•

Vyzkou²et schopnosti navigace jak ve vertikálním sm¥ru (seznamy), tak i v horizontálním sm¥ru (záloºky).

•

Ov¥°it zda-li uºivatelé dokáºí pracovat s grackými elementy, zejména vysouvací nabídky, za²krtávací polí£ka a vstupní textová pole.

•

Ov¥°it, zda-li se uºivatelé neztrácí v p°íli²ném zano°ování a dokáºí se vºdy dostat do výchozího bodu (hlavní menu).

3.3.2 Vyhodnocení a výsledná opat°ení Evaluace prototypu probíhala v rámci druhého kola testování, které je popsáno v kapitole 5.1.2 na stran¥ 44, kde m·ºete také nalézt výslednou sadu chyb, a poznatk·, které z ní vyplynuly. Na základ¥ této evaluace byla p°ijata následující dv¥ opat°ení:

•

Ve v²ech místech aplikace kde bylo moºné zv¥t²it velikost písma byla velikost písma zv¥t²ena.

•

Byly vytvo°eny nové popisky pro potvrzování akcí v kalendá°i, aby bylo zabrán¥no nesrovnalostem v pochopení kdy akci smazat a kdy ji potvrdit.

Nevy°e²eným problémem z·stal fakt, ºe vypl¬ování textových polí zp·sobuje uºivatel·m men²í ²ok. B¥hem psaní textu do t¥chto polí se totiº aplikace p°epne do systémového uºivatelského rozhraní daného výrobcem mobilního telefonu. Tím se naru²í celý design aplikace, nap°íklad se zm¥ní pozadí z bíle barvy na £ernou. P°í£innou tohoto problému je pouºitý framework s názvem Kuix (viz [18]), který vypl¬ování t¥chto vstupních polí z hlediska uºivatelského rozhraní implementuje velmi nevhodn¥. Bohuºel oprava frameworku by byla nad moºnosti této práce. Dal²í opat°ení nebylo moºné p°ijmout, protoºe testování prob¥hlo pouze na dvou osobách, a ostatní problémy souvisely p°edev²ím s umíst¥ním poloºek v hierarchii menu a jejich pojmenováním, p°i£emº ob¥ osoby vykazovaly rozdílné problémy na rozdílných místech. To co jedna osoba nezvládla, ta druhá bez problému splnila a naopak. Z tohoto d·vodu bylo rozhodnuto zatím hierarchii menu a problematické popisky poloºek ponechat a pokra£ovat v dal²ím testování.

3.4 High delity prototyp 0.2 Po rozporuplném testování high delity prototypu 1.0 (viz kapitola 3.3) byly p°ijata dv¥ opat°ení související s uºivatelským rozhraním. Hlavní cíl i specické cíle druhého prototypu byly tedy z v¥t²í £ásti shodné s cíli prvního reálného prototypu popsaného v p°edchozí kapitole. Dále prob¥hlo roz²í°ení prototypu o dal²í akce. P°idána byla podpora vým¥ny matky, jarní prohlídka a kontrolní prohlídka. Také bylo do v²ech prohlídek p°idáno hodnocení základních faktor· popisujících chování v£el b¥hem roku, jako je nap°íklad faktor rojivosti, rychlost jarního rozvoje apod. Specické cíle byly p°ejaty z p°edchozího kola testování a dopln¥ny o tyto nové specické cíle:

3.5.

25

VÝSLEDNÁ PODOBA UIVATELSKÉHO ROZHRANÍ

•

Ov¥°it, zda-li nové popisky pro potvrzování akcí v kalendá°i vy°e²ily problém správného potvrzení akce.

•

Ov¥°it, nesrovnalosti v za°azení poloºek v menu získané b¥hem druhého kola testování a p°ípadn¥ nalézt nové.

•

Nalézt nesrovnalosti v ozna£ení ovládacích prvk· a popisk· aplikace.

3.4.1 Vyhodnocení a výsledná opat°ení Evaluace druhé verze reálného prototypu probíhala v rámci t°etího kola testování, které je popsané v kapitole 5.1.3 na stran¥ 46. Seznam krok·, které je t°eba u£init pro nápravu chyb, plynoucích z této evaluace je následující:

•

Do kalendá°e aplikace je nutné p°idat moºnost pro naplánování libovolné akce.

•

Do sekce Výkazy a statistika je nutné p°idat odkaz na úlový výkaz.

•

Do sekce Produkce a krmivo a podsekce Cukr je nutné p°idat odkaz vedoucí na krmení v£elstev.

•

Bylo by výhodné do hlavního menu aplikace p°idat odkaz vedoucí na úlový deník.

•

Potvrzení nebo smazání naplánovaných akcí v kalendá°i je nutné provád¥t ve dvou krocích. V prvním kroku uºivatel potvrdí smazání úkolu a ve druhém kroku se ho systém zeptá, zda-li akce prob¥hla úsp¥²n¥, £i nikoli.

•

Je nezbytn¥ nutné nov¥ navrhnout uºivatelské rozhraní pro medobraní a prodej medu.

•

Potvrzení nebo smazání objednávky medu je nutné vy°e²it ve dvou krocích obdobn¥ jako bylo navrºeno u plánování akcí.

Vzhledem k £asovému omezení této práce, nebyla tato výsledná sada zm¥n a opat°ení p°ijatých v rámci poslední experimentální evaluace implementována. Návrh °e²ení tedy z·stává pouze návodem, pro dal²í krok ve vývoji aplikace.analytické

3.5 Výsledná podoba uºivatelského rozhraní Konkrétní °e²ení uºivatelského rozhraní jednotlivých akcí a proces· je moºné nalézt ve form¥ prototypu na p°iloºeném CD v adresá°i

\high_fidelity_prototyp_0.2.

Je zde k dispozici jak zdrojový kód aplikace, tak i zkompi-

lovaná verze programu ve form¥ JAD a JAR soubor·. Dal²í moºností, jak si prohlédnout uºivatelské rozhraní aplikace jsou ukázková videa, která naleznete také na p°iloºeném CD ve sloºce

\ukazkova_videa,

spustitelný p°ímo z webového prohlíºe£e viz kapitola 6.

nebo on-line prototyp

26

KAPITOLA 3.


3.6 Uºivatelské rozhraní v praxi Poslední evaluací uºivatelského rozhraní byla evaluace provedená p°ímo v terénu a v reálných podmínkách. Jejím cílem bylo odhalení chyb, které laboratorní evaluace odhalit nem·ºe. P°edev²ím se o£ekávalo otestování chyb spojených s prost°edím, ve kterém bude aplikace ovládána. P°i návrhu specických cíl·, bylo t°eba p°ihlédnout k n¥kolika fakt·m, které platí pro v¥t²inu v£ela°ských zákrok· provád¥ných p°ímo mezi v£elstvy. Nejprve si tato fakta rozebereme a poté z nich vyvodíme specické cíle testování.

Ochranné pom·cky V£ela°i a zejména v£ela°i za£áte£níci pouºívají p°i práci se v£elami nejr·zn¥j²í ochranné pom·cky. Mezi základní pom·cky pat°í v£ela°ská kukla, v£ela°ské rukavice, kombinéza a uzav°ená obuv. Platí pravidlo, ºe £ím je v£ela° zku²en¥j²í, tím mén¥ ochranných pom·cek pouºívá. První ochranou, kterou v£ela° odkládá jsou rukavice. D¥je se tak proto, ºe p°i své práci pot°ebuje mít v rukou cit a také proto, ºe mezi v£ela°i se pouºívání rukavic povaºuje za neprofesionální. V£ela°skou kuklu, p°ípadn¥ klobouk, profesionální v£ela°i také odkládají, ale pouze v n¥kterých p°ípadech, protoºe bodnutí do oka není jiº tak bezpe£né, jako je bodnutí do rukou. Prakticky lze v£ela°it i v sandálech krátkých kalhotách a tri£ku s krátkým rukávem - a d¥je se to. Bohuºel v¥t²ina £eských v£ela°· ochranné pom·cky stále pouºívá v plném rozsahu jak je vid¥t na obrázku 3.4. Kukla a rukavice tak mohou být významnou p°ekáºkou v ovládání aplikace.

Obrázek 3.4:

V£ela°ská kukla, rukavice a kombinéza

3.6.

27

UIVATELSKÉ ROZHRANÍ V PRAXI

V£elnice a v£elíny V£ela°ské zákroky provád¥né p°ímo u v£el jsou úzce spjaty z prost°edím, kde jsou v£elstva umíst¥na. V£elstva mohou být umíst¥na bu¤ v p°íst°e²ku, kterému °íkáme v£elín, nebo pod otev°eným nebem. Jsou-li v£elstva umíst¥na pod otev°eným nebem, °íkáme takovému místu v£elnice. V£elnice mají na rozdíl od v£elín· z hlediska na²í aplikace aplikace velkou nevýhodu. V£ely se otevírají v zásad¥ pouze za velmi p¥kného a slune£ného po£así, kdy je v¥t²ina z nich venku na pastv¥. V úlu tak zbudou pouze mladé v£ely, které nejsou tolik bodavé a je jich podstatn¥ mén¥. Na v£elnici ale nemá v£ela° k dispozici ºádnou ochranu p°ed sluncem a £tení displeje mobilního telefonu tak m·ºe být velmi ztíºeno sv¥telnými podmínkami. Malou v£elnici se ²esti v£elstvy pod otev°eným nebem si m·ºete prohlédnout na obrázku 3.5.

Obrázek 3.5:

V£elnice

Za²pin¥ní rukou T°etí komplikací, kterou si zde popí²eme je za²pin¥ní rukou. V£ely jak je známo v²e, co je uvnit° úlu (v£etn¥ jeho st¥n), nat°ou a zalepí propolisem, p°ípadn¥ zatmelí voskem. Jakmile v£ela° otev°e úl,tém¥° vºdy si ruce od vosku a propolisu zamaºe. Kdyº pak zdvihne nap°íklad rámek se zásobami, m·ºe si být jistý, ºe se umaºe i od medu. Takto zamazané ruce mu p°i práci se v£elami sice nevadí, ale p°i práci s mobilním telefonem by to mohl být problém. Zejména v p°ípad¥, kdy si v£ela° sv·j drahý telefon od vosku a medu za²pinit nechce.

3.6.1 Specické cíle Vzhledem k vý²e popsaným problém·m bylo stanoveno n¥kolik specických cíl· pro experimentální evaluaci. Nyní si uve¤me jejich seznam:

1. Ov¥°it, zda-li lze ovládat software ve v£ela°ské kukle.

28

KAPITOLA 3.


2. Vyzkou²et a zhodnotit ovládání aplikace s nasazenými v£ela°skými rukavicemi. 3. Ov¥°it, zda-li nebude v praxi problém se sv¥telnými podmínkami. 4. Zjistit, zda-li nebude mobilní telefon v£ely dráºdit, nebo jim manipulace s ním v t¥sné blízkosti úlu nebude jinak vadit. 5. Ov¥°it jestli v£ela°i nebude vadit, ºe b¥hem práce se v£elami musí ovládat dal²í nástroj. 6. Ov¥°it, jestli nebude za²pin¥ní rukou od vosku a medu vadit p°i pouºití mobilního p°ístroje.

3.6.2 Výsledky evaluace Detailní popis a foto-p°íb¥h evaluace naleznete v kapitole 5.2.1 na stran¥ 48. Na stejném míst¥ pak naleznete i výsledek evaluace. My se zde budeme op¥t zabývat pouze návrhem °e²ení jednotlivých problém·, které b¥hem tohoto testování nastaly.

1. Vzhledem k tomu, ºe ovládání aplikace ve v£ela°ských rukavicích není moºné, je t°eba v budoucnu roz²í°it aplikaci o ovládání hlasem, nebo se zam¥°it pouze na chovatele, kte°í pracují bez rukavic. 2. Sv¥telné podmínky neumoº¬ují pracovat s telefonem pod p°ímým slune£ním sv¥tlem na v£elnici. V£ela° tak musí vyuºívat stínu mezi úly, nebo si stínit vlastním t¥lem, chce-li aplikaci na v£elnici pouºívat. Hlasové ovládání by by tento problém vy°e²ilo. 3. Vzhledem k problematickému ovládání telefonu b¥hem otev°ení úlu, je t°eba uºivatel·m doporu£it, aby nejprve vºdy provedli zákrok, a zápis provád¥li v mezi£ase mezi uzav°ením jednoho úl· a otev°ením druhého. Problém by mohlo °e²it op¥t hlasové rozhraní, ov²em mohlo by také v£ela°e p°i práci s otev°eným v£elstvem stresovat.

Vý²e uvedená opat°ení obdobn¥ jako opat°ení z p°edchozí kapitoly nebyla zatím implementována. Jedná se tedy o opat°ení, která by m¥la být provedena v p°ípad¥ pokra£ování tvorby aplikace. Je z°ejmé, ºe v¥t²inu hlavních praktických problém· by °e²ilo ovládání aplikace pomocí hlasu, a m¥lo by se tudíº stát hlavním cílem dal²ího vývoje.

Kapitola 4

Implementace 4.1 Pouºitá vývojová prost°edí a emulátory Pro vývoj aplikace bylo zvoleno vývojové prost°edí Eclipse Classic 3.5.2 (viz [11]) s roz²í°ením pro vývoj mobilních aplikací: DSDP - Mobile Tools for Java (viz [10]). Vývojové prost°edí i emulace probíhala vºdy pod opera£ním systémem Linux, distribuce Ubuntu. Testování b¥hem vývoje probíhalo na dvou softwarových emulátorech. První z nich je emulátor rmy Oracle (d°íve Sun Microsystems), který je sou£ástí balíku Sun Java Wireless Toolkit 2.5.2 (viz [7]). Jako alternativa byl zvolen emulátor MicroEmulator 2.0.4 (viz [24]), který

na rozdíl od prvního emulátoru umoº¬uje testovat i dotykové ovládání aplikace.

4.2 Pouºité knihovny t°etích stran Aplikace aktivn¥ pouºívá dv¥ knihovny t°etích stran: Kuix 1.1.0 (viz [18]) a Floggy persitence 1.3.1 (viz [15]). Ob¥ dv¥ knihovny významn¥ ovliv¬ují jak implementaci, tak i uºivatelské

rozhraní aplikace. Proto d°íve, neº p°ejdeme k samotnému popisu implementace, ukaºme si v následujících odstavcích základní rysy obou zmín¥ných framework·.

4.2.1 Kuix UI framework Kuix je framework postavený nad standardní Java ME. Jeho cílem je zjednodu²it vývoj aplikací pro mobilní telefony. Poskytuje knihovnu grackých element·, jako jsou nap°íklad tla£ítka, vstupní textová pole, menu a seznamy. V²echny gracké elementy umoº¬uje upravovat pomocí CSS (kaskádových styl·), podobn¥ jako webové stránky. Také kompozice element· na jednotlivé obrazovky je °e²ena velmi elegantním zp·sobem - pomocí XML soubor·. Struktura a výsledné aplikace je op¥t velmi podobná XHTML. Framework zaji²úje plnou kompatibilitu s telefony, které jsou schopny pracovat s CLDC 1.0 and MIDP 2.0 a to jak pro standardní klávesnice, tak i pro dotykové obrazovky. Dal²ím d·leºitým rysem tohoto frameworku je velmi kvalitn¥ navrºené p°etíºení obsluhy událostí v závislosti na kontextu obrazovky pomocí návrhového vzoru Chain of responsibility (viz obrázek 4.1). V praxi to znamená, ºe vývojá° pí²e pouze jakési controllery, které

29

30

KAPITOLA 4.

spl¬ují rozhraní

Frame,

IMPLEMENTACE

kde je naprogramována vlastní business logika celého systému a

jsou sem p°edávány zprávy ze vstupních za°ízení. V neposlední °ad¥ je t°eba zmínit, ºe Kuix poskytuje kvalitní podporu lokalizace pomocí standardních .properties soubor·. Praktické ukázky z oblasti lokalizace si p°edvedeme v následujících kapitolách.

Obrázek 4.1: Kuix - Schéma zpracování událostí, zdroj: [18] Kuix lze svobodn¥ pouºít pod licencí GNU General Public License (viz [14]). Je ale moºné si framework koupit i pod jinou licencí, která je vhodn¥j²í pro komer£ní nasazení. Konkrétní ukázky jak, se jednotlivé prvky tohoto frameworku pouºívají si p°edstavíme v následujících kapitolách p°ímo v souvislosti s reálnými problémy z na²í aplikace. Více informací o Kuix frameworku, m·ºete je nalézt v [18].

4.2.2 Floggy persistence Floggy Persistence je framework ur£ený pro práci s persistentním uloºením objekt· v Java ME aplikacích. Cílem tohoto frameworku je poskytnout abstraktní vrstvu mezi objekty v opera£ní pam¥ti telefonu a objekty v RMS databázi - tedy persistentním úloºi²t¥m. Floggy se skládá ze dvou hlavních modul·: frameworku a weaveru. Framework poskytuje jednoduché API pro ukládání a na£ítání objekt· a weaver analyzuje a upravuje bytekód t°íd, které spl¬ují rozhraní pro persistenci nazvané ukazuje obrázek 4.2.

Persistable.

P°ehledný diagram jak celý proces funguje

4.3.

POPIS STRUKTURY APLIKACE

31

Obrázek 4.2: Floggy persitence schéma, zdroj [15]

Hlavním d·vodem pro nasazení tohoto frameworku v na²í aplikaci je obrovská úspora místa nutného pro uloºení persistentních dat. Floggy je vyvíjen pod licencí Apache License, version 2.0 (viz [9]). Pro hlub²í studium tohoto frameworku doporu£uji [15].

4.3 Popis struktury aplikace V této kapitole si v hrubých rysech jakým zp·sobem je na²e aplikace implementována. Nejprve si popí²eme, jak je realizováno ukládání a na£ítání dat a jakým zp·sobem je realizován systém p°eklad·. Následn¥ p°ejdeme k °e²ení business logiky - vysv¥tlíme si, jak aplikace s daty manipuluje. Nakonec si prohlédneme, jakým zp·sobem bylo vytvo°eno uºivatelské rozhraní a tím odpovíme na otázku, jak se data zobrazují.

4.3.1 Celkový pohled na strukturu aplikace D°íve neº se pustíme do konkrétních ukázek jednotlivých prvk·, ze kterých se aplikace skládá p°edstavíme si diagram 4.3, který nám poskytne celkový pohled na interakci jednotlivých komponent v aplikaci. Vysv¥tleme si, jak interakce uºivatele a jednotlivých komponent aplikace probíhá. Za£n¥me u uºivatele, který pouºívá pro jako vstup tla£ítka na klávesnici mobilního za°ízení.

32

KAPITOLA 4.

IMPLEMENTACE

Obrázek 4.3: Struktura aplikace na mobilním telefonu se standartní klávesnicí.

Událost zpracuje framework Kuix (viz kapitola 4.2.1), a p°edá ji objektu

FrontController,

Command (viz kapitola 4.3.4). Dále se mohou na£íst data DAO a framework Floggy z RMS (viz kapitola 4.3.2). Command nakonec po²le frameworku

který z události vytvo°í objekt typu p°es

Kuix, instrukce - nap°íklad pro zobrazení ur£ité obrazovky. Kuix na£te obrazovku z XML a aplikuje na ni CSS a nakonec ji zobrazí na fyzické obrazovce mobilního za°ízení (viz kapitola 4.3.5). Uºivatel pak získá informace pohledem na obrazovku fyzického za°ízení.

4.3.2 Na£ítání a ukládání dat Persistenci objekt· °e²í v na²í aplikaci vý²e zmín¥ný framework s názvem Floggy. Bohuºel tento framework nativn¥ nespolupracuje s druhým pouºitým frameworkem (Kuix). Bylo proto nutné vyuºít návrhový vzor pocházející z technologie Java EE (viz [3]) nazývaný Data Access Object, zkrácen¥ DAO. Nejprve si prohlédn¥me diagram t°íd, který nám mohl objasní,

jakým zp·sobem je DAO implementován.

DaoFactory,

krom¥ návrhového vzoru Singleton, aplikuje také návrhový vzor FlyWei-

ght. D·vodem je úspora místa v opera£ní pam¥ti. Podívejme se nyní na stru£nou ukázku

zdrojového kódu, která nám objasní jakým zp·sobem

DaoFactory

pracuje.

public final class DaoFactory { ... private static final int _daoPoolLength = 4; private static FloggyDao [] _daoPoolObjects ; private static int [] _daoPoolCounter ; private DaoFactory () { this . _daoPoolObjects = new FloggyDao [ DaoFactory . _daoPoolLength ]; this . _daoPoolCounter = new int [ DaoFactory . _daoPoolLength ]; }

4.3.

33


Obrázek 4.4: Pouºití návrhového vzoru DAO

private FloggyDao _getDao ( Class c ) { int min = 0; for ( int i =0; i < DaoFactory . _daoPoolLength ; i ++) { if ( DaoFactory . _daoPoolObjects [ i ]. getClass (). equals ( c )) { DaoFactory . _daoPoolCounter [ i ] += 1; return DaoFactory . _daoPoolObjects [ i ]; } if ( DaoFactory . _daoPoolCounter [ i ] < DaoFactory . _daoPoolCounter [ min ]) { min = i ; } } DaoFactory . _daoPoolCounter [ min ] = 1; try { DaoFactory . _daoPoolObjects [ min ] = ( FloggyDao ) c . newInstance (); } catch ( Exception e ) { } }

}

return DaoFactory . _daoPoolObjects [ min ];

public HoneyDao getHoneyDao () { return ( HoneyDao ) this . _getDao ( HoneyDao . class ); } ...

Jak je ze zdrojového kódu patrné,

DaoFactory má cache nazvanou daoPoolObjects ur£e-

nou pro uloºení £ty° nejpouºívan¥j²ích DAO objekt·. Ukládá se sem kaºdý nový objekt dokud není místo napln¥no. Jakmile dojdou v²echny £ty°i pozice, nový objekt vºdy nahrazuje, jiný objekt, který je zvolen podle nejniº²ího po£tu p°ístup·. DAO objekty, jak bylo vid¥t na UML diagramu vý²e, d¥dí od t°ídy

FloggyDao,

která

34

KAPITOLA 4.

IMPLEMENTACE

vyuºívá a p°et¥ºuje API frameworku Floggy. T°ída poskytuje pouze £ty°i, základní metody:

load, save, find

a

delete.

Tyto metody jsou dále vyuºívány konkretními DAO objekty.

P°edstavme si malou ukázku, jak je celý systém navrºen. Nejpve si ukaºme, jak bylo p°etíºením rozhraní

Persistable

zaji²t¥no, aby kaºdý objekt ukládaný do RMS, znal své unikátní

ID. Floggy framwork tímto rozhraním ozna£uje objekty ur£ené k persistenci.

public interface FloggyPersistableInterface extends Persistable { public void setId ( int id ); public int getId (); }

Po té bylo t°eba vytvo°it metody pro na£ítání, mazání a ukládání objekt·, pomocí Floggy API. P°edve¤me si zde malou ukázku, jak lze implementovat nap°íklad ukládání objekt·.

public abstract class FloggyDao {

}

protected int _save ( FloggyPersistableInterface p ) { PersistableManager pm = PersistableManager . getInstance (); try { if (! pm . isPersisted ( p )) { int id ; id = pm . save ( p ); p . setId ( id ); } return pm . save ( p ); } catch ( FloggyException e ) { e . printStackTrace (); } return -1; } ...

Z ukázky je vid¥t, ºe byla pouºita technika dvojitého ukládání. Pokud objekt v minulosti nebyl je²t¥ uloºen, nemá své ID. V takovém p°ípad¥ je nutné mu je p°id¥lit.Objekt je proto nejd°íve poprvé uloºen, £ímº je získáno jeho ID. Toto ID je mu pak p°id¥leno pomocí metody

setId() a následn¥ je objekt uloºen znovu. P°i tomto druhém uloºení objekt jiº své

ID zná. Výsledná implementace ukládání objekt· v konkrétním DAO objektu pak vypadá následovn¥:

public class HoneyDao extends FloggyDao { ... public int saveHoneyOrder ( HoneyOrder tempHoneyOrder ) { return this . _save ( tempHoneyOrder ); } ... }

Na£ítání a mazání objekt·, nebo jejich skupin, je °e²eno o n¥co sloºit¥ji, ale princip z·stává stejný.

4.3.

35


4.3.3 Lokalizace Lokalizace aplikace je °e²ena s pomocí frameworku Kuix, který nám pro tento problém poskytuje velmi p°íjemné API. Zatím je k dispozici bohuºel pouze jeden p°eklad (£e²tina), ale i v tomto p°ípad¥ je systém lokalizace aktivn¥ vyuºíván. Samotné texty jsou uloºeny v souborech .properties, messages.properties.

jak je v jazyce Java zvykem. Uve¤me si malou ukázku ze souboru

... production_honey_type_name = Typ medu production_honey_type_price = Cena ... Ve zdrojovém kódu aplikace se pak pouºívá statická metoda

getMessage() objektu Kuix,

která vrací p°eklad. Jedná se o velmi jednoduché API:

Kuix . getMessage ( " production_honey_type_name " ); Pro design aplikace jsou pouºity i XML soubory, ve kterých je také nutné mít p°ístup k lokalizovaným text·m. Stejný p°eklad jako je uveden vý²e, lze zajistit obalením identika£ního °et¥zce do znak· %. Ukázka by vypadá následovn¥:

< screenTopBar > < picture src = " / img / icon /20/ honey . png " / > < textarea >% production_honey_type_name %

4.3.4 Business logika a zpracování událostí V souvislosti se zpracováním událostí si nejprve p°ipome¬me °e²ení, které nám poskytuje framework Kuix (obrázek 4.1 na stran¥ 30). Události, jsou p°edávány objekt·m, které musí implementovat rozhraní

Frame.

Tyto objekty jsou skládány do zásobníku a pomocí návrho-

vého vzoru Chain of responsibility si p°edávají události do té doby, neº ji n¥který z nich obslouºí. P°edává se vºdy název akce a pole argument·. Tento zp·sob zpracování událostí je velmi zajímavý, ale pro na²i aplikaci bohuºel naprosto nevhodný. Vyvolaná událost vºdy spou²tí £ást na£í aplika£ní logiky. Framework p°edpokládá, ºe tato logika je naprogramována p°ímo v objektech typu

Frame,

to je ov²em ná² klí£ový problém.

Je t°eba uváºit fakt, ºe v¥t²ina aplika£ní logiky v na²í aplikaci, by m¥la být serializovatelná. D·vodem je plánování akcí. Lze p°edpokládat, ºe kaºdou akci lze spustit, nejen kliknutím na p°íslu²nou poloºku v menu, ale také spu²t¥ním události, která je uloºena v kalendá°i (plánování akcí). Teoreticky lze tedy kaºdou akci spou²t¥t minimáln¥ ze dvou kontext·. Kdybychom se drºeli p·vodního schématu, pak by z mnoha jiných

Frame

Frame

obsluhující kalendá°, duplikoval kód

objekt· a do²lo by tak k hrubému poru²ení DRY principu (viz [1],

stejný kód by se opakoval na více r·zných místech aplikace). Výhodn¥j²í by bylo, kdyby aplika£ní logika byla spjata p°ímo s volanou akcí, a ne z objektem, který ji obsluhuje. Tento koncept logicky vede k návrhovém vzoru Commad, který byl také pouºit. Mechanizmus objekt· implementujících rozhraní vzorem FrontController viz obrázek 4.5.

Frame, byl p°etíºen návrhovým

36

KAPITOLA 4.

IMPLEMENTACE

Obrázek 4.5: Správa události pomocí vzoru Command

Podívejme se nyní na tento problém hloub¥ji a ukaºme si klí£ová místa zdrojového kódu, které s ním souvisí. Nejprve si ukáºeme jakým zp·sobem vytvá°í t°ída objekty typu

Command.

CommandFactory nové

public final class CommandFactory { ... private static final String CLASS_NAME_PREFIX = ... public String getSmallClassName ( Class c) { String name = c . getName (); name = name . substring ( CommandFactory . CLASS_NAME_PREFIX . length ()); return name ; } public Command getCommand ( String name ) { return this . getCommand ( name , null ); } public Command getCommand ( Class c ) { return this . getCommand ( this . getSmallClassName ( c )); }

}

public Command getCommand ( String name , Object [] args ) { Command cmd ; try { Class c = Class . forName ( CommandFactory . CLASS_NAME_PREFIX + name ); cmd = ( Command ) c . newInstance (); } catch ( ClassNotFoundException e ) { return null ; } catch ( InstantiationException e ) { return null ; } catch ( IllegalAccessException e ) { return null ; } return cmd ; }

Tento jednoduchý skript pracuje s názvem t°ídy a polem argument·. Z názvu t°ídy, který

4.3.

37


je reprezentován jako textový °et¥zec, vytvo°í instanci objektu a pokud nenastane výjimka, p°edá tuto instanci jako návratovou hodnotu.

FrontController

pak

CommandFactory

vyu-

ºívá následujícím zp·sobem:

public final class FrontController implements Frame { ... public void onAdded () { Command cmd = new MainMenuShowCommand (); cmd . run (); } public boolean onMessage ( Object arg0 , Object [] arg1 ) { Command cmd ; try { CommandFactory cmdFactory = CommandFactory . getInstance (); cmd = cmdFactory . getCommand (( String ) arg0 , arg1 ); cmd . run ( arg1 ); } catch ( Exception e ) { ... } return false ; }

}

public void onRemoved () { ... }

run() objektu typu Command je uloºena samotná aplika£ní logika. Samotná run() se pak drºí jednoduchého schématu, které zaji²úje £i²t¥ní událostí v kalendá°i

Aº v metod¥ metoda

a plánování návazných akcí. Schéma bylo zachyceno pomocí diagramu aktivit na obrázku 4.6.

4.3.5 Vzhled aplikace a kompozice aplikace Nyní uº víme jak aplikace data na£ítá a jakým zp·sobem je implementována business logika. Zbývá objasnit zp·sob jakým se data prezentují. Pro prezenta£ní £ást aplikace byl op¥t vyuºit framework Kuix. Základními prvky umoº¬ujícími prezentaci dat jsou takzvané obrazovky (Screen). Obrazovka pak m·ºe, obsahovat dal²í elementy jako jsou tla£ítka, textová pole, nadpisy apod. Jednotlivé elementy pro kaºdou obrazovku mohou být denovány pomocí jazyka XML. Zde je ukázka:

< screen > < screenTopBar > < picture src = " / img / icon /20/ honey . png " / > < textarea >% production_honey % < scrollpane > < list class = " menu " > < listitem onaction = " HoneyOrdersShowCommand " > % production_honey_orders % ...

38

KAPITOLA 4.

Obrázek 4.6: Schéma pr·b¥hu metody

run()

IMPLEMENTACE

4.3.

39


< screenfirstmenu onAction = " SelectCommand " > < picture src = " / img / icon /20/ select . png " / > < text >% select % < screensecondmenu onAction = " ProductionMenuShowCommand " > < picture src = " / img / icon /20/ back . png " / > < text >% back % Abychom objasnili gracký význam základních podelement· ko°enového elementu

screen,

prohlédn¥me si obrázek 4.7 pocházející z dokumentace frameworku Kuix.

Obrázek 4.7: Struktura elementu

Screen,

zdroj [18]

Strukturu jednotlivých element· lze krom¥ vý²e uvedeného XML denovat i standardním zp·sobem, pomocí zdrojového kódu v jazyce Java. Tento zp·sob byl volen v p°ípad¥, ºe obrazovka byla dynamicky generována. Samoz°ejm¥ je moºné oba zp·soby voln¥ kombinovat, nap°íklad kostru vytvo°it v XML a ur£ité £ásti pak doplnit pomocí kódu v jazyce Java. Jakmile je struktura hotová je vhodné p°idat element·m ur£itou grackou podobu. Grackou podobu lze denovat pomocí CSS soubor·, které framework Kuix nativn¥ podporuje.

40

KAPITOLA 4.

IMPLEMENTACE

Nejedná se bohuºel o plné CSS, jak jej známe z technologií pro webové stránky. Nap°íklad jedinou jednotkou, kterou m·ºeme pouºívat je jednotka pixel (px), apod. Ukaºme si nyní velmi stru£nou ukázku z CSS souboru:

... screen . mainMenu button { layout : borderlayout ; min - size : 0 90; } screen . mainMenu button textarea { layout - data : bld ( south ); align : center ; margin : 0; font - size : small ; } screen . mainMenu button picture { layout - data : bld ( center ); align : center ; } ... Na vý²e uvedené ukázce si ukaºme jednu zajímavou techniku, o kterou framwork Kuix, svou implementaci CSS roz²í°il. Bude to zp·sob jak rozestavit jednotlivé gracké elementy na

layout. V na²í ukázce si borderlayout. Ten funguje obdobn¥, jako

obrazovku. Kaºdý prvek m·ºe mít denovanou vlastnost nazvanou: m·ºeme v²imnout, ºe je zde pouºit layout nazvaný

ve standardní Jav¥ pro desktopové aplikace, nap°íklad v knihovn¥ Swing viz [8]. (Rozd¥luje plochu na p¥t £ástí: st°ed a £ty°i sv¥tové strany.) Kdyº pak chceme ur£it který element

layout-data a p°i°adíme bld(center). Obdobn¥ lze vyuºívat i jiné zp·soby tablelayout, flowloayout nebo gridlayout.

bude umíst¥n nap°íklad ve st°edu, pouºijeme vlastnost nazvanou jí, p°esn¥ denovaný textový °et¥zec: rozloºení nap°íklad:

Kapitola 5

Evaluace V této kapitole, zabývající se evaluací jednotlivých prototyp· aplikace se budeme v¥novat dv¥ma druh·m evaluace. Nejprve se seznámíme s evaluaci laboratorní, která byla provád¥na b¥hem vývoje softwaru ve t°ech kolech se sedmi r·znými ú£astníky a po té se seznámíme s evaluací v terénu. Ta probíhala pouze v jednom kole a s jedním ú£astníkem testu. U kaºdého kola evaluace si uvedeme nejprve její cíl, nebo d·vod pro£ byla provedena. Dále si popí²eme jednotlivé pr·b¥hy evaluace vzhledem k ú£astník·m testu a na záv¥r vºdy vyvodíme z evaluace výslednou sadu problém· a poznatk·.

5.1 Laboratorní evaluace 5.1.1 Papírový prototyp, storyboardy Hlavním cílem prvního kola testování, které probíhalo formou interview, bylo ov¥°it správný sm¥r vývoje aplikace denovaný pomocí storyboard· a ov¥°it pouºitelnost uºivatelského rozhraní pomocí papírového prototypu. Z tohoto hlavního cíle byly vyvozeny následující specické cíle: 1. Dodenovat ²í°i zadání pomocí storyboard·. Zjistit, co vy°adit a co je²t¥ doplnit. 2. Rozhodnout, které druhy a typy úl·, rámk· a nádob na skladování medu podporovat a které ne. Vy°e²it problém podpory dvouprostorových úl· a nástavkových úl·. 3. Denovat, jakým zp·sobem by aplikace m¥la nakládat s problematikou v£elích chorob a parazit·. 4. Zjistit, zda-li uºivatel dokáºe v navrºeném menu najít kaºdou z cílových akcí. 5. Ov¥°it, zda-li si uºivatel pod kaºdým zvoleným pojmenováním akce nebo popiskem formulá°e p°edstaví opravdu to, co autor pojmenování o£ekával. 6. Ov¥°it, zda-li uºivatel v rámci aplikace chápe rozd¥lení na akce, které pouze zobrazují informace a akce které umoº¬ují informace m¥nit. 7. Zkontrolovat storyboardy a odstranit p°ípadné logické chyby vycházející ze ²patn¥ zachycené v£ela°ské praxe.

41

42

KAPITOLA 5.

EVALUACE

Plán evaluace Testování bylo provedeno formou interview ve dvou £ástech odd¥lených krátkou p°estávkou (cca 5min). V první £ásti byla testovaná osoba seznámena s hlavním cílem aplikace a následn¥ byla vedena diskuse nad storyboardy. První fáze se snaºila získat informace týkající se specických cíl· 1,2,3 a 7. Druhá fáze testování probíhala formou diskuse nad papírovým prototypem, p°i£emº jsme se v¥novali specickým cíl·m 4,5 a 6.

Ú£astník testu P1 První testovaná osoba ozna£ovaná dále jako P1 je velmi zku²ený v£ela°, který chová více neº 10 v£elstev. Dob°e ovládá jak mobilní telefon i osobní po£íta£. V¥ková kategorie je 50 a více let. Podle P1 je ²í°e zadání dosta£ující tak, jak ji storyboardy denují. Byly navrºeny drobné zm¥ny v textech jednotlivých storyboard· a jeden ze storyboard· doporu£il P1 rozd¥lit na dva r·zné storyboardy, nebo´ zde byly zmateny v£ela°sky p°esn¥ denované termíny odd¥lek a smetenec. Problematiku podpory r·zných druh· úl· P1 navrhl °e²it tak, ºe dvouprostorové úly není t°eba podporovat. P1 vycházel z faktu, ºe moderní sm¥r vývoje v£ela°ství vede pouze a jen k úl·m nástavkovým. Problematika rámkových mír je obdobný problém, kde P1 navrhl významnou zm¥nu. V£ela° by m¥l mít ve svém hospodá°ství jen jednu rámkovou hlavní míru a p°ípadn¥ jednu polovi£ní. Její p°esné rozm¥ry se mohou li²it. Proto navrhl drºet se v oblasti rámkových mír na nejvy²²í úrovni abstrakce a pracovat pouze s pojmy rámek a polorámek. P°ípadné p°esné rozm¥ry by pak bylo moºné inicializovat nap°íklad p°i prvním

spu²t¥ní aplikace, nebo v nastavení aplikace. Problematika evidence uskladn¥ní medu a nádob na uskladn¥ní, byla ponechána podle p·vodního návrhu. Podpora evidence lé£ení a nemocí v£elstev byla ozna£ena jako velmi netriviální, p°i£emº bylo zji²t¥no, ºe do termínu odevzdání by nebylo moºné ji ani detailn¥ nastudovat a analyzovat, natoº pak zachytit v aplikaci. Diskuse nad papírovým prototypem ukázala ºe není jasné zda-li poloºka medobraní pat°í mezi chov a ²lecht¥ní, nebo produkci a zásoby. P1 dále navrhl p°ejmenovat poloºku hlavního menu z p·vodního ozna£ení Chov a ²lecht¥ní na Chov v£elstev. Slovo ²lecht¥ní se nezdálo býti vhodné, protoºe b¥ºný chovatel tuto £innost v zásad¥ neprovádí. Jednozna£nost pojmenování aplikace se zdála být v po°ádku aº na rozd¥lení: zobrazovaní informací a spou²t¥ní pr·vodc· akcí. Objevily se velké nejasnosti v implementaci inventá°e, naprosto nejasné bylo to, ºe uºivatel si nejprve musí nastavit typ poloºky (nastavit nap°íklad rozm¥ry dna, a kompatibilitu s ostatním prvky) a pak teprve zadat po£et poloºek. V sekci produkce, by bylo dobré evidovat je²t¥ pyl, propolis a mate°í ka²i£ku.

Ú£astník testu P2 Druhá testovaná osoba ozna£ovaná dále jako P2 je v£ela° s více neº 20 letmými zku²enostmi. P2 velmi dob°e ovládá jak mobilní telefon i osobní po£íta£ ale nemá techniku p°íli² v lásce. V¥ková kategorie je 40-50 let.

5.1.

LABORATORNÍ EVALUACE

43

Podle P2 je ze ²í°e zadání moºná nadimenzována a aplikace chce p°íli² mnoho vstupních údaj· na to, kolik poskytuje výsledk·. P2 doporu£il zam¥°it se na to, aby cena získaných údaj· výstupních p°evý²ila cenu zadávání vstupních údaj·. ádné zm¥ny ve storyboardech nedoporu£il. (Chyby které odhalil P1 jiº byly opraveny.) Konzultace nad prototypem prokázala, ºe je evidentní ºe medobraní pat°í do produkce a s chovem v£elstev nemá nic spole£ného. Základní struktura aplikace se ukázala jako dobrá, pojmenování se zdálo také v po°ádku, aº na rozd¥lení: zobrazovaní informací a spou²t¥ní pr·vodc· akcí - stejn¥ jako u P1. Inventá° vybavení P2 ne°e²il, úlový výkaz se mu zdál na první pohled v po°ádku. P2 ocenil hlavn¥ my²lenku p°ipomínání a plánování akcí a export dat do MS Excelu. Export do dat PDF mu p°i²el zbyte£ný, protoºe podle P2 s exportovanými daty chce v¥t²ina uºivatel· dál pracovat. Dále poznamenal, ºe výhodné by bylo ovládání pomocí hlasu, protoºe i kdyº pracuje bez rukavic, má ruce £asto za²pin¥né voskem a medem, a necht¥l by si pak zamazat je²t¥ telefon.

Ú£astník testu P3 P3 je víkendový v£ela°, coº je specický typ v£ela°e, který v zásad¥ m·ºe ke svým v£elám jen na víkendy, tudíº pouºívá pozm¥n¥ný systém pracovních proces·. Prakticky to znamená, ºe kaºdou v£ela°skou akci m·ºe provést vºdy jen v rozmezí sedmi dn·, i kdyº by bylo t°eba ji provést nap°íklad za dev¥t nebo t°i dny. P3 podobn¥ jako P2 povaºuje ²í°i zadání za hodn¥ komplexní a rozsáhlou, ale klidn¥ by ji tak nechal, se slovy: Ono se samo £asem ukáºe, co lidi pouºívají a co ne.. Navrhl, ºe aplikace by se m¥la ur£it¥ vydat sm¥rem k podpo°e souvislostí mezi v£elami a fenologickým kalendá°em, protoºe je z°ejmé, ºe se jím v£ely celkem dob°e °ídí. Odhady na základ¥ kv¥tu rostlin podle P3 fungují - na rozdíl od ostatních metod odhad· ve v£ela°ství. Bohuºel by to ale znamenalo, ºe by uºivatel musel zadávat velmi mnoho dat o rozkv¥tu roslin ve svém okolí, coº by asi t¥ºko n¥kdo d¥lal. P3 prý zná jen minimum lidí, co si tyto záznamy vedou. Konzultace nad prototypem ukázala, ºe by se bez problém· v aplikaci zorientoval. Problém bylo op¥t pouze rozd¥lení na akce a zobrazování informací. P3 zaujala moºnost exportu záznam· do MS Excelu, protoºe pokud by telefon pouºíval, tak spí²e jako prost°edníka mezi v£elami a po£íta£em. Dále podpo°il my²lenku plánování akcí protoºe jako víkendovému v£ela°i by tato moºnosti p°inesla významné uleh£ení jeho práce. Záporn¥ hodnotil, jednoduché výpo£ty typu kolik mezist¥n a cukru budu pot°eba na leto²ní rok. Prý to rychleji spo£ítá v hlav¥ neº neº aby nasazoval brýle a 10x klikal do telefonu.

Výsledky evaluace 1. Rozd¥lení na akce a zobrazování informací, je nutné p°epracovat nebo úpln¥ vypustit. 2. Je t°eba rozd¥lit storyboard o tvo°ení nových v£el, tak aby nedo²lo k zám¥n¥ termínu odd¥lek a smetenec.

3. Je nutné znovu nov¥ navrhnout uºivatelské rozhraní pro správu v£ela°ského inventá°e. Pracovat pouze s nástavkovým systémem, rámky a polorámky. Odstranit sloºitý systém nastavování rozm¥r·.

44

KAPITOLA 5.

Obrázek 5.1:

EVALUACE

Testovací za°ízení Nokia 2700

4. Export dat je pot°eba pouze do formátu MS Excel, ostatní druhy exportu je moºné z návrhu vy°adit. 5. Do oblasti lé£ení v£elstev je vhodné v první verzi aplikace v·bec nevstupovat. 6. Produkce medu by m¥la být schopna evidovat v²echny v£ela°ské produkty. 7. Najít moºnosti práce s fenologickým kalendá°em a do aplikace jej zapracovat.

5.1.2 High delity prototyp 0.1 Cílem druhého kola evaluace bylo ov¥°it moºnosti ovládání uºivatelského rozhraní p°ímo na mobilním za°ízení. Testování probíhalo na mobilním telefonu Nokia 2700 (viz obrázek 5.1). Specické cíle testování byly stanoveny takto:

1. Ov¥°it, je-li vhodn¥ zvolena velikost písma . 2. Vyzkou²et, zda-li uºivatele pochopí ovládaní navigace jak ve vertikálním sm¥ru (seznamy), tak i v horizontálním sm¥ru (záloºky). 3. Ov¥°it, zda-li uºivatelé dokáºí pracovat s grackými elementy, zejména vysouvací nabídky, za²krtávací polí£ka a vstupní textová pole. 4. Ov¥°it, zda-li se uºivatelé neztrácí v p°íli²ném zano°ování a dokáºí se vºdy dostat do výchozího bodu (hlavní menu). 5. Najít dal²í kritická místa uºivatelského rozhraní, která mohou p·sobit jakékoli problémy.

5.1.


45

Plán evaluace B¥hem testování byly testované osob¥ zadávány r·zné úkoly a pozorovatel si zapisoval problémy, které b¥hem testování nastaly. Jednotlivé úkoly si m·ºete prohlédnout v p°íloze B.1 na stran¥ 61. Vzhledem k velkému rozsahu tohoto testu, není jiº moºné uvád¥t jednotlivé problémy vzhledem ke kaºdému z ú£astník· testu. Jednotlivé ú£astníky si proto nejprve p°edstavíme a velmi stru£n¥ popí²eme jejich pocity z testování. Poté si uvedeme souhrnný seznam chyb a problém·, které b¥hem testování nastaly a nebude rozli²ovat, který ú£astník problém objevil.

Ú£astník testu P4 Ú£astník testu P4 je v£ela° ve v¥ku 40-50 let a chová mén¥ neº 10 v£elstev. P4 ovládá pouze základní funkce mobilního telefonu a neumí pracovat s po£íta£em. P4 naprosto selhal v ovládání aplikace. B¥hem testování nás z vedlej²í místnosti pozorovala jeho partnerka, která nevydrºela jen ne£inn¥ p°ihlíºet a testovací za°ízení si od ú£astníka P4 vyp·j£ila a rychle se sama seznámila s rozhraním aplikace. Partnerka P4 bohuºel není v£ela°ka, tudíº nerozum¥la odborným pojm·m, se kterými aplikace pracuje. Navrhla ale ú£astníkovy P4, ºe bude p°ístroj ovládat a on ji bude °íkat co a jak má do aplikace zadat. Tímto zp·sobem p°ekvapiv¥ velmi rychle a velmi dob°e ovládli celou aplikaci a splnili tém¥° v²echny zadané úkoly. Komplikace nastaly pouze v popisu n¥kterých tla£ítek a za°azení n¥kterých poloºek v menu.

Ú£astník testu P5 Ú£astník testu P5 je chovatelem mén¥ neº 10 v£elstev a jeho v¥ková kategorie je 40-50 let. Velmi dob°e ovládá osobní po£íta£, mobilní telefon ale pouºívá pouze pro volání a tvrdí, ºe neumí psát sms. P5 m¥l celkov¥ z pouºívání aplikace velmi dobrý pocit. Sám se snaºil prozkoumat, co v²e aplikace nabízí. Navrhl, ºe by si aplikaci klidn¥ koupil, pokud by ²la ovládat hlasem. P5 v sou£asné dob¥ pouºívá pro evidenci následující systém. P°i prohlídkách si na diktafon nahraje jednotlivé poznatky a ve£er v²e p°epí²e do p°ipravených tabulek v programu MS Excel. Pokud by aplikaci bylo moºné ovládnout hlasem, odpadla by mu nep°íjemná práce spojená s p°episováním poznámek. V ovládání aplikace m¥l P5 problém s tím, ºe za výchozí bod aplikace nepovaºoval hlavní menu ale kalendá°. Podle jeho slov kaºdou akci musí nejprve naplánovat a pak aº provést. Drobné potíºe s popisky tla£ítek zp·sobovaly nedokon£ení nebo brzké ukon£ení n¥kterých proces·.

Výsledky evaluace Výsledkem evaluace je následující sada poznatk· a problém·, které b¥hem testování nastaly.

1. Uºivatelé hledají akce které mají provést nejprve kalendá°i a pak aº v menu aplikace. 2. Vypl¬ování textového pole, které je implementováno frameworkem Kuix, zp·sobuje men²í ²ok.

46

KAPITOLA 5.

EVALUACE

3. Malé písmo zp·sobuje v n¥kterých £ástech aplikace problémy, st°ední a velké písmo je £itelné bez problém·. 4. Opakované pouºití tla£ítka zp¥t funguje jako perfektní záchrana, pokud se uºivatel ztratí. 5. P°i potvrzování naplánované události v kalendá°i uºivatelé klikají na tla£ítko smazat, £ímº p°eru²í sled naplánovaných událostí. 6. Tla£ítko s popiskem upravit ve skladu medu, uºivatelé nepochopili. 7. U akcích spojených s konkrétním v£elstvem uºivatelé nejprve hledají název akce, a nenapadne je nejprve zvolit v£elstvo. 8. P°i objednávání medu, nebo medobraní uºivatelé nepochopily tla£ítko nazvané P°idat med / P°idat v£elstvo. 9. Navigace v aplikaci nep·sobila ºádnému ú£astníkovi test· problémy. A to ani v jednom sm¥ru. 10. Zakrmení uºivatelé hledají v sekci produkce a její podsekci nazvané cukr.

5.1.3 High delity prototyp 0.2 T°etí kolo testování nad funk£ním prototypem verze 0.2 plynule navazuje na p°edchozí testování, které nazna£ilo rozpory v oblasti za°azení poloºek v menu a jejich pojmenování. Uvedené rozpory byly zatím ponechány dal²ímu testování. Jedním z cíl· tohoto prototypu je tyto rozpory vyvrátit nebo potvrdit. Dále byl prototyp roz²í°en o dal²í akce jako nap°íklad systém pro plánování vým¥ny matek nebo jarní a kontrolní prohlídka. Navíc byla do v²ech prohlídek p°idána moºnost hodnocení v£el z hlediska rojivosti, mírnosti apod. Specické cíle evaluace byly odvozeny z výsledk· evaluace p°edchozího testování a dopln¥ny o nové cíle. Uve¤me si jejicsih seznam: 1. Ov¥°it, zda-li nové popisky pro potvrzování akcí v kalendá°i vy°e²ily problém správného potvrzení akce. 2. Ov¥°it nesrovnalosti v za°azení poloºek v menu získané b¥hem druhého kola testování a p°ípadn¥ nalézt nové. 3. Nalézt nesrovnalosti v ozna£ení ovládacích prvk· a popisk· aplikace. 4. Ov¥°it schopnost pouºívat problematická tla£ítka ve formulá°ích pro prodej medu a medobraní. Testování op¥t probíhalo formou zadávání úkol· a jejich pln¥ní. Byl pouºit upravený seznam úkol· vzhledem k roz²í°ení prototypu. P°esné zadání jednotlivých úkol· m·ºete nalézt v p°íloze B.2 na stran¥ 62. Op¥t si zde kv·li velkému rozsahu test· nebudeme uvád¥t, jednotlivé problémy ve vztahu ke kaºdému ú£astníku test·, ale budeme se drºet struktury, která byla pouºita v p°edchozím kole testování. Nejprve se seznámíme s jednotlivými ú£astníky a jejich pocity z na²í aplikace a po té p°ejdeme rovnou k výsledné sad¥ problém·.

5.1.


47

Ú£astník testu P6 Ú£astník testu P6 je v£ela° ve v¥ku 30-40 let. Chová mén¥ neº 10 v£elstev. Denn¥ vyuºívá mobilní telefon na psaní poznámek a aktivn¥ na svém mobilním telefonu vyuºívá systém upomínek. Osobní po£íta£ ovládá velmi dob°e. Ú£astníkovi P6 se koncept aplikace velmi zalíbil. Vzhledem k tomu, ºe mobilní telefon £asto pouºívá nem¥l z ovládáním aplikace ºádný v¥t²í problém. Komplikace nastaly pouze p°i prvním setkání s se vstupním textovým polem a za°azením jednotlivých poloºek v menu.

Ú£astník testu P1 Charakteristika ú£astníka P1 byla jiº popsána v kapitole 5.1.1. P°ipome¬me si , ºe se jedná o zku²eného v£ela°e ve v¥kové kategorii 50 a více let, který chová více neº 10 v£elstev. P1 m¥l moºnost pozorovat vývoj aplikace jiº od prvního papírového prototypu a podílel se na hodnocení storyboard·. Práce s aplikací pro n¥j tedy byla o n¥co snaz²í neº pro ostatní ú£astníky, kte°í vid¥li aplikaci p°i testování poprvé. S ovládáním aplikace nem¥l P1 ºádné v¥t²í problémy. Men²í problémy nastaly v za°azení n¥kterých poloºek do menu a v ²oku p°i vypl¬ování textového pole.

Ú£astník testu P7 Ú£astník testu P7 je aktivní v£ela° ve v¥kové kategorii nad 50 let. Je chovatelem mén¥ neº 10 v£elstev. Mobilní telefon a osobní po£íta£ pouºívá denn¥ ke své práci. P7 hodnotil koncept aplikace velmi opatrn¥. Uºivatelské rozhraní mu zpo£átku p·sobilo men²í potíºe, ale po vy°e²ení druhého úkolu si na n¥j zvykl. P°i práci s aplikací nastávaly pouze men²í potíºe a v²echny úkoly byly aº na jednu výjimku spln¥ny. Byly odhaleny drobné nesrovnalosti v pojmenování n¥kterých akcí.

Výsledky evaluace 1. Uºivatelé hledají ve²keré události, které mají provést nejprve kalendá°i a pak aº v menu aplikace. 2. Úlový výkaz hledají uºivatelé v sekci Výkazy a statistika. Úlový deník, který je sou£ástí úlového výkazu uºivatelé aº na výjimky nemohou nalézt v·bec. 3. Naplánované úkoly se i po zm¥n¥ popisk· tla£ítek stále neda°í potvrdit. 4. P°i objednávání medu, nebo medobraní uºivatelé nedokáºí ovládnout tla£ítko nazvané P°idat med / P°idat v£elstvo. V sou£asném stavu to p·sobí na v¥t²inu uºivatel· zmaten¥. 5. Místo potvrzení objednávky medu, uºivatelé objednávku maºou. Tím znemoºní zapo£ítání objednávky do systému náklad· a výnos·.

48

KAPITOLA 5.

EVALUACE

5.2 Evaluace v terénu 5.2.1 Roz²i°ování v£elstev na v£elnici Cílem evaluace provád¥né p°ímo v terénu bylo ov¥°ení pouºitelnosti softwaru v reálných podmínkách. Testování probíhalo na malé v£elnici se ²esti v£elstvy a bylo stanoveno n¥kolik specických cíl· testování:

1. Ov¥°it, zda-li lze ovládat software ve v£ela°ské kukle. 2. Vyzkou²et a zhodnotit ovládání aplikace s nasazenými v£ela°skými rukavicemi. 3. Ov¥°it, zda-li nebude v praxi problém se sv¥telnými podmínkami, protoºe práce na v£elnici probíhá v zásad¥ pouze za velmi slunných dn·. 4. Zjistit, zda-li nebude mobilní telefon v£ely dráºdit, nebo jim manipulace s ním v t¥sné blízkosti úlu nebude jinak vadit. 5. Ov¥°it, jestli v£ela°i nebude vadit, ºe b¥hem práce se v£elami musí ovládat dal²í nástroj. 6. Ov¥°it, jestli nebude za²pin¥ní rukou od vosku a medu vadit p°i pouºití mobilního p°ístroje.

Plán evaluace Nejprve bude v£ela° seznámen se situací a úkonem, který má provést. Budou mu poskytnuty v²echny pot°ebné nástroje, ochranné pom·cky a materiál pot°ebný k vykonání zadaného úkolu. Následn¥ se v£ela° i pozorovatel odebere na v£elnici, kde v£ela° sám splní úkol.

Zadání úkolu Roz²i°te v£elstvo £íslo 1 a v£elstvo £íslo 2 o jeden nástavek s mezist¥nami.

Ú£astník testu P8 P8 je v£ela° s mén¥ neº 10 v£elstvy. V¥ková kategorie je 20-30 let. Mobilní telefon i osobní po£íta£ pouºívá P8 denn¥ ke své práci. Postup evaluace si je zdokumentován na foto-p°íb¥hu zobrazeném na obrázku 5.2.

Výsledky evaluace 1. V£ela°ská kukla nep·sobí v ovládání telefonu ºádné významné problémy. 2. Ve v£ela°ských rukavicích se v zásad¥ nelze tret p°esn¥ na jedno tla£ítko, a je tém¥° nemoºné ovládnout k°íºový ovlada£. 3. Sv¥telné podmínky neumoº¬ují pracovat s telefonem pod p°ímým slune£ním sv¥tlem, úly v²ak vºdy poskytují stín, nebo je moºné stínit si vlastním t¥lem.

5.2.

EVALUACE V TERÉNU

49

4. Pouºití mobilního telefonu v£ely nedráºdí ani jinak neprovokuje. 5. Ovládání mobilního telefonu b¥hem provád¥ní v£ela°ského úkonu je problematické. Vhodné je ale pouºití mobilního telefonu v £ase, kdy je práv¥ dokon£ena práce nad jedním úlem a chceme za£ít práci nad druhým. 6. B¥hem zákroku roz²i°ování nep·sobí za²pin¥ní rukou ºádný problém v ovládání telefonu.

50

KAPITOLA 5.

EVALUACE

K dispozici byla kukla, rukavice, ku°ák, n·º, rozp¥rák a husí brk na ometání v£el.

Pro vykonání úkolu byly p°ipraveny dva nástavky plné mezist¥n.

Testování probíhalo na v£elnici o ²esti nástavkových úlech. Pracovalo se ale jen na dvou z nich.

P8 otev°el první úl.

Nasazování nástavku prob¥hlo bez v¥t²ích problém·.

Po nasazení byla umíst¥na stropní fólie a úl byl uzav°en.

Po uzav°ení úlu bylo otev°eno o£ko v nástavku.

P8 si cht¥l zapsat data do aplikace, ale rukavice mu bránily v ovládání.

V£ela° se rozhodl zadání dat do aplikace odloºit a otev°el druhý úl.

V£ely sed¥ly klidn¥ a na p°ítomnost mobilního telefonu nijak nereagovaly.

Ú£astník P8 p°idal dal²í nástavek.

Mezist¥ny bylo t°eba posunout. Ú£astník P8 si sundal rukavice, aby s mezist¥nami mohl lépe manipulovat.

Byla op¥t nasazena stropní fólie a úl byl uzav°en.

P8 se znovu pokusil zadat záznam o roz²í°ení do mobilního telefonu.

Práci mu bez rukavic zt¥ºovalo pouze slune£ní sv¥tlo.

Obrázek 5.2:

Foto-p°íb¥h experimentální evaluace

Kapitola 6

Dokumentace Po celou dobu vývoje a testování aplikace byla vedena ve²kerá dokumentace on-line na webových stránkách projektu. Zve°ej¬ování ve²kerých nových informací o stavu aplikace probíhalo pr·b¥ºn¥, b¥hem jejího vývoje. Webová prezentace byla primárn¥ ur£ena pro zvý²ení informovanosti partner·, spolupracujících subjekt· a zadavatele (vedoucího) práce. Webové stránky projektu m·ºete nalézt na adrese:

http://benman.ondramandik.com/beeper-pro-mobilni-zarizeni Na vý²e uvedené adrese m·ºete nalézt ve²keré diagramy a podklady pro tuto práci. Navíc je zde moºnost vyzkou²et on-line prototyp aplikace, nebo si m·ºete ve Flash p°ehráva£i, který je sou£ásti webu, prohlédnout vzorová videa z pouºívání aplikace. Hlavním d·vodem vedení webových stránek projektu byl fakt, ºe vývoj aplikace bude pokra£ovat nadále i po uzav°ení této práce. Po odevzdání práce se pak webová prezentace stane hlavním zdrojem informací, který bude na rozdíl od tohoto tiskopisu udrºován v aktuálním stavu vzhledem k poslední vydané verzi. Ukázku webové prezentace si m·ºete prohlédnout na obrázku 6.1.

51

52

KAPITOLA 6.

Obrázek 6.1:

Ukázka webu projektu.

DOKUMENTACE

Kapitola 7

Záv¥r V rámci analýzy v£ela°ské problematiky v kapitole 2.4 na stran¥ 12 byly stanoveny £ty°i cíle, o jejichº spln¥ní b¥hem vývoje celé aplikace usilujeme. V této záv¥re£né kapitole se pokusíme o stru£né shrnutí, které ze stanovených cíl· se povedlo naplnit a které ne. U kaºdého problému, nebo úsp¥chu se pokusíme nalézt jeho p°í£inu. Následn¥ si ukáºeme, jakými sm¥ry se bude ubírat dal²í vývoj aplikace a nakonec se podíváme na napln¥ní hlavní motivace této práce.

7.1 Hodnocení spln¥ní cíl· aplikace 7.1.1 Vedení administrace chovu a plánování akcí Uºivatelské rozhraní pro vedení administrace chovu a plánování akcí, bylo v rámci papírového prototyp navrºeno a otestováno v plném rozsahu. V rámci implementace, jsme se systémem plánovaní akcí zabývali velmi detailn¥. Administrace chovu byla také implementována tém¥° v plném rozsahu. Bez implementace z·stal pouze chov matek a podpora tvo°ení nových v£el. P°í£inou byl fakt, ºe k uvedeným proces·m se váºe obrovské mnoºství metod a r·zných zp·sob·, jakým je lze realizovat. Nebyla tedy pln¥ vy°e²ena otázka, jaký p°ístup k t¥mto proces·m zvolit. Testování b¥hem vývoje ukázalo, ºe velmi kvalitn¥ se poda°ilo implementovat p°edev²ím systém prohlídek v£elstev, plánovaní vým¥ny matek, zakrmení a úlový výkaz, který je propojen s administrací skladu v£elích produkt·.

7.1.2 Správa prodeje v£elích produkt· Správa prodeje v£elích produkt· byla velmi dob°e navrºena jiº v rámci papírového prototypu. Implementace prob¥hla pouze pro administraci jednoho produktu a to medu. Administrace medu je °e²ena od fáze výb¥ru vhodného v£elstva aº po fázi prodeje medu koncovému zákazníkovy, coº pln¥ pokrývá celý skute£ný proces práce s medem popsaný v kapitole 2.2.1 na stran¥ 7. Systém je také napojen do administrace celkových náklad· a výdaj· a do správy úlových výkaz·. Podpora ostatních v£elích produkt· nebyla zatím implementována z d·vodu nízkého zájmu ze strany malov£ela°·. Ten zap°í£inil vy°azení t¥chto £ástí z prvních verzí prototyp·.

53

54

KAPITOLA 7.

ZÁVR

Dopln¥ní správy v£elích produkt· by v²ak bylo velmi snadné, pokud by se zájem o n¥ b¥hem dal²ího vývoje zvý²il.

7.1.3 Administrace v£ela°ského inventá°e Administrace v£ela°ského inventá°e byla v rámci papírového prototypu navrºena do nejmen²ích podrobností a v rámci prvního kola evaluace byla také detailn¥ testována. Bohuºel zájem uºivatel· o administraci inventá°e nebyl p°íli² vysoký a spí²e zde panovaly obavy, ºe se jedná p°esn¥ o tu £ást aplikace, kde náklady na zadávání údaj·, p°evy²ují zisky z informací které poskytuje. Vzhledem k tomu, ºe vývoj aplikace se °ídí, p°edev²ím poºadavky uºivatel·, byl tento cíl vy°azen z dal²í implementace.

7.1.4 Automatické vytvá°ení povinných formulá°· Oblast automatického vytvá°ení povinných formulá°· byla navrºena a otestována pouze v rámci papírového prototyp·. Do reálných prototyp· se automatické vytvá°ení dokumentace zatím nedostalo. D·vodem je fakt, ºe automatické generování jakýchkoli dat m·ºe pln¥ fungovat aº ve chvíly, kdy budou pln¥ funk£ní i systémy pro zadávání t¥chto dat. Prioritou aplikace v prvních fázích vývoje bylo tedy dokon£ení práv¥ systému pro zadávání dat. Aº po té bylo naplánováno vybudování automatického vytvá°ení dokumentace.

7.2 Pokra£ování práce Vzhledem k omezeným £asovým moºnostem této práce a také vzhledem k obecnému konceptu práce, který vyºaduje nejen práci n¥kde za£ít, ale také ji n¥kde skon£it, musel být vývoj aplikace v ur£itou chvíli ukon£en. Mimo tuto práci ale bude vývoj aplikace pokra£ovat dál. Sm¥r vývoje, jak jiº bylo mnohokrát nep°ímo nazna£eno ur£ují primárn¥ uºivatelé, kte°í nám b¥hem evaluace systému poskytly n¥kolik zásadních sm¥r·, kterými by se budoucí vývoj m¥l ubírat. Uve¤me si zde alespo¬ ty nejzásadn¥j²í z nich.

Hlasové ovládání Hlasové ovládání bylo vyºadováno drtivou v¥t²inou v²ech osob, které se zú£astnily vývoje nebo testování aplikace. Tento zp·sob ovládání aplikace by také mohl být °e²ením v¥t²iny problém·, které vyplynuly z evaluace v terénu.

Chov matek Chov matek je velmi náro£ná £innost i pro zku²ené v£ela°e. Podpora chovu matek je druhou nejd·leºit¥j²í £ástí aplikace, protoºe je také druhou nejpoptávan¥j²í £ástí aplikace. Za°azení chovu matek do aplikace podporuje jak SV tak i Výzkumný ústav v£ela°ský v Dole.

7.3.

ZÁVRENÉ ZHODONOCENÍ APLIKACE

55

Vyuºití fenologického kalendá°e Nápad na vyuºití fenologického kalendá°e vyplynul z jednoho z prvních interview na p·d¥ Výzkumného ústavu v£ela°ského v Dole. Pokud by se poda°ilo výhody, které vyuºití fenologického kalendá°e skýtá, poskytnout uºivatel·m na²í aplikace. Informace, které fenologie poskytuje by byly obrovskou pomocí p°edev²ím pro plánování zásah· do v£elstva a predikci výnos· v£elích produkt·. V budoucnu bude t°eba provést d·kladnou analýzu této problematiky a vyuºít v²ech pouºitelných informací, které fenologie poskytuje.

Podpora lé£ení v£elstev Lé£ení v£elstev je £innost, která bývá £asto zanedbávaná a m·ºe zp·sobit velké ztráty jak z lokálního, tak i z globálního hlediska. Podpora lé£ení je velmi dob°e algoritmizovatelné £innost, a uºitek, který tato funkcionalita poskytuje významn¥ p°evy²uje náklady na její za°azení do aplikace. Podporu lé£ení v£elstev pomocí GABONU, VARIDOLU a FORMIDOLU podporuje zejména SV.

Stanovi²t¥ a ko£ování Pro roz²í°ení aplikace mezi velkov£ela°e je nutné zapracovat také systém ko£ování a podporu více stanovi²´. Toto roz²í°ení op¥t není p°íli² £asov¥ náro£né, ale uºitek který z n¥ho m·ºe plynout v podob¥ roz²í°ení aplikace i mezi velkov£ela°e by mohl být zna£ný.

7.3 Záv¥re£né zhodonocení aplikace Na úplný záv¥r bychom m¥li zmínit, ºe vývoj aplikace pokra£uje i po odevzdáním této práce. Z evaluace vyplynulo ºe, pokud budou spln¥ny vý²e uvedené cíle, lze ji ²í°it i komer£ním zp·sobem - coº by mohla být dal²í motivace pro její vývoj. Pokud by Vás dal²í vývoj aplikace zajímal, aktuální informace m·ºete nalézt na webu projektu, který je uveden v kapitole6.

56

KAPITOLA 7.

ZÁVR

Literatura [1] Andy Hunt, D. T.: Orthogonality and the DRY Principle.

,

stav z 22. 5. 2010.

[2] Corporation, O.: Connected Limited Device Conguration (CLDC); JSR 139.

,

stav z 9. 5. 2010.

[3] Corporation, O.: Core J2EE Patterns - Data Access Object.

,

stav z 9. 5. 2010.

[4] Corporation, O.: Java Platform, Enterprise Edition (Java EE).

,

stav z 23. 5. 2010.

[5] Corporation, O.: Java Platform, Micro Edition (Java ME).

,

stav z 10. 5. 2010.

[6] Corporation, O.: Mobile Information Device Prole (MIDP); JSR 118.

,

stav z 9. 5. 2010.

[7] Corporation, O.: Sun Java Wireless Toolkit 2.5.2.

,

stav z 9. 5. 2010.

[8] Corporation, O.: Swing.

,

stav

z

22. 5. 2010. [9] Foundation, A. S.: Apache License, Version 2.0.

,

stav z 9. 5. 2010.

[10] Foundation, E.: DSDP - Mobile Tools for Java (MTJ).

,

stav z 9. 5. 2010.

[11] Foundation, E.: Eclipse Classic 3.5.2.

,

stav z 9. 5. 2010.

[12] Fraky: V£elár 2.0.

,

stav z 8. 5. 2010.

[13] Franti²ek Kamler, K. : V£ela°íme nástavkov¥. eský svaz v£ela°·, 2003, ISBN 80-9033090-8.

57

58

LITERATURA

[14] Free Software Foundation, I.: GNU General Public License.

,

stav z 9. 5. 2010.

[15] Group, F. O. S.: Floggy Persistence 1.3.1.

,

stav z 9. 5. 2010.

[16] Ing. Vladimír Veselý, C. a. k.: V£ela°ství. Státní zem¥d¥lské nakladatelství Praha, 1985, ISBN 07-056-85. [17] Johanesson, J.: HiveNote - EDBi.

,

stav z 30. 4. 2010.

[18] Kalmeo: Kuix 1.1.0.

,

stav z 9. 5. 2010.

[19] Lampeitl, F.: Chováme v£ely. BLESK, 1996, ISBN 80-85606-96-8. [20] McIlvride, K.: The Ultimate in Beekeeping Software.

,

stav z 30. 4. 2010.

[21] Mueller, J.; aj.: FreeMind - free mind mapping software.

,

stav z 12. 5. 2010.

[22] Object Management Group, I.: Business Process Modelling Notation.

,

stav z 22. 5. 2010.

[23] Sedlá£ek, M.: V£ela°ství Sedlá£ek Bu£ovice - V£ela°ský rok 2009.

,

stav

5. 5. 2010. [24] Team, M.: MicroEmulator.

,

stav z 9. 5. 2010.

[25] eský svaz v£ela°·: Zpráva o £innosti a hospoda°ení eského svazu v£ela°·.

,

stav z 29. 4. 2010.

z

Dodatek A

Seznam pouºitých zkratek API

Aplication Public Interface

BPMN CSS

Business Process Modelling Notation, viz [22]

Kaskádové styly

SV

eský svaz v£ela°·, o.s., viz [25]

DAO

Data Access Object, viz [3]

DRY

Don't repeat yourself, viz [1]

Java EE

Java Platform, Enterprise Edition, viz [4]

Java ME

Java Platform, Micro Edition, viz [5]

XHTML

Extensible Hypertext Markup Language

XML

Extensible Markup Language

59

60

DODATEK A.

SEZNAM POUITÝCH ZKRATEK

Dodatek B

Zadání úkol· v rámci testování B.1 High delity prototyp 0.1 Úkol 1. - Podletní prohlídka P°edstavte si ºe je podletí. Prohlédnul jste v£elstvo £íslo 2 a b¥hem prohlídky odhadl plodo-

2

vou plochu na 20dm , zásoby na 4kg. V£elstvo obsedá jen 6 rámk·. Zji²t¥né údaje si nyní chcete poznamenat do aplikace.

Úkol 2. - Medobraní Vyto£il jste 8kg medu ze v£elstva £íslo 1 a 9kg medu ze v£elstva £íslo 2. Protoºe je léto vytá£íte kv¥tový med. Uloºte nyní údaje do aplikace.

Úkol 3. - Objednávka Potkal jste p°ítele jménem Jan Novák. Chce si u Vás objednat 5kg kv¥tového medu. Zkontrolujte své skladové zásoby a v p°ípad¥, ºe objednávku m·ºete uskute£nit ji zadejte do systému.

Úkol 4. - Prodej objednávky Práv¥ jste Janu Novákovy prodal med co si u Vás objednal. Jan Vám jiº zaplatil a med si odná²í sebou. V systému, máte ale po°ád jeho objednávku. Tuto objednávku nyní ukon£ete.

Úkol 5. - Nový typ medu Ve skladu jste na²el 20kg akátového medu z minulého roku. Byl za krabicí od medometu, takºe jste si ho d°íve nev²iml. P°idejte si tento med do skladu. Pokud tento druh medu v systému je²t¥ nemáte, zaloºte si nejprve nový typ medu.

61

62

DODATEK B.

ZADÁNÍ ÚKOL V RÁMCI TESTOVÁNÍ

Úkol 6. - Zakrmení Práv¥ jste se rozhodl zakrmit v£elstvo £íslo 1 cukerným roztokem v pom¥ru 3:1. Chcete za£ít krmit hned te¤ a nakrmit ho na 14kg. K dispozici máte pouze 3 litrové krmítko a pot°ebujete tedy krmení rozplánovat na del²í £asové období. Naplánujte krmení.

B.2 High delity prototyp 0.2 Úkol 1. - Zaloºit v£elstvo P°edstavte si, ºe jste si práv¥ nainstalovali na²í aplikaci a pot°ebujete tedy zaloºit nové v£elstvo ozna£ené jako v£elstvo £íslo 1. V£elstvo je umíst¥no v nástavkovém úlu ve dvou nástavcích bez mate°í m°íºky. Matka je ro£ník 2009.

Úkol 2. - Jarní prohlídka Práv¥ za£alo jaro. Provedl jste jarní prohlídku v£elstva £íslo 1 a zjistil jste, ºe v£elstvo má je²t¥ 6kg zásob. Zásoby jste tedy po²krábal jako podn¥covací krmení. Plodovou plochu jste odhadl na

15dm2 .

Královnu jste nezahlédl. V£elstvo bylo b¥hem prohlídky velmi mírné a

sed¥lo pevn¥ na plodu. Zapi²t¥ si nyní tyto údaje ke v£elstvu.

Úkol 3. - Roz²í°ení v£elstva V£elstvo £íslo 1 jste práv¥ roz²í°il o jeden nástavek mezist¥n. V nástavku jste otev°el o£ko na maximum. Uloºte do aplikace záznam o roz²í°ení tohoto v£elstva.

Úkol 4. - Zakrmení v£elstva Práv¥ jste se rozhodl zakrmit v£elstvo £íslo 1 cukerným roztokem v pom¥ru 3:1. Chcete za£ít krmit hned te¤ a nakrmit ho na 14kg. K dispozici máte pouze 3 litrové krmítko a pot°ebujete tedy krmení rozplánovat na del²í £asové období. Naplánujte krmení.

Úkol 5. - Vým¥na matky Práv¥ jste se rozhodl vym¥nit v£elstvu £íslo 1 matku. Vým¥nu provedete pomocí p°idávací klícky. Uzav°enou klícku jste vloºil do v£elstva. Nyní nastartujte proces vým¥ny matky a naplánujte otev°ení klícky za 5 dní.

Úkol 6. - Medobraní Vyto£il jste 8kg medu ze v£elstva £íslo 1 a 9kg medu ze v£elstva £íslo 2. Protoºe je léto vytá£íte kv¥tový med. Uloºte nyní údaje do aplikace.

B.2.

HIGH FIDELITY PROTOTYP 0.2

63

Úkol 7. - Nový typ medu Ve skladu jste na²el 20kg akátového medu z minulého roku. Byl za krabicí od medometu, takºe jste si ho d°íve nev²iml. P°idejte si tento med do skladu. Pokud tento druh medu v systému je²t¥ nemáte, zaloºte si nejprve nový typ medu.

Úkol 8. - Objednávka Potkal jste p°ítele jménem Jan Novák. Chce si u Vás objednat 5kg kv¥tového medu. Zkontrolujte své skladové zásoby a v p°ípad¥, ºe objednávku m·ºete uskute£nit ji zadejte do systému.

Úkol 9. - Prodej objednávky Práv¥ jste Janu Novákovy prodal med co si u Vás objednal. Jan Vám jiº zaplatil a med si odná²í sebou. V systému, máte ale po°ád jeho objednávku. Tuto objednávku nyní ukon£ete.

64

DODATEK B.

ZADÁNÍ ÚKOL V RÁMCI TESTOVÁNÍ

Dodatek C

Storyboardy

Obrázek C.1: Jarní prohlídka

65

66

DODATEK C.

Obrázek C.2: Podlední prohlídka

STORYBOARDY

67

Obrázek C.3: Spojování v£elstev

68

DODATEK C.

Obrázek C.4: Chov matek

STORYBOARDY

69

Obrázek C.5: Medobraní

70

DODATEK C.

Obrázek C.6: Zdravotní stav v£el

Obrázek C.7: Osi°ení

STORYBOARDY

71

Obrázek C.8: Protokoly a výkazy

72

DODATEK C.

Obrázek C.9: Výpo£et náklad· a výnos·

Obrázek C.10: Prodej medu

STORYBOARDY

73

Obrázek C.11: Vytvo°ení odd¥lku

74

DODATEK C.

STORYBOARDY

Dodatek D

BPMN Diagramy

Obrázek D.1: Vým¥na dna

75

76

DODATEK D.

Obrázek D.2: Jarní prohlídka

BPMN DIAGRAMY

77

Obrázek D.3: Jarní ru²ení v£elstva

78

DODATEK D.

Obrázek D.4: Protirojová opat°ení

BPMN DIAGRAMY

79

Obrázek D.5: Medobraní

80

DODATEK D.

Obrázek D.6: Chycení a usazení roje

BPMN DIAGRAMY

81

Obrázek D.7: Krmení v£elstva

82

DODATEK D.

Obrázek D.8: Podletní prohlídka

BPMN DIAGRAMY

83

Obrázek D.9: Podletní ru²ení v£elstva

84

DODATEK D.

BPMN DIAGRAMY

Dodatek E

Obsah p°iloºeného CD / readme.txt......................................................... Návod na instalaci a spu²t¥ní affinity_diagram...............................................................Anity diagram affinity_diagram.mm....................................Zdrojový soubor programu FreeMind affinity_diagram.png ............................................. Diagram ve formátu PNG bpmn_diagramy ..................................... BPMN diagramy °azené podle ro£ních období jaro jarni_prohlidka.png ... .... high_fidelity_prototyp_0.2...........................................High delity prototyp 2.0 high_fidelity_prototyp_0.2.jar ................................. Zkompilovaný JAR soubor high_fidelity_prototyp_0.2.jad ................................... Deskriptor JAR souboru source_code.zip ....................................... Zdrojový kód prototypu v jazyce Java papirovy_prototyp_0.2.............................................. Papírový prototyp verze 2.0 papirovy_prototyp_0.2.pdf ....................................... Prototyp ve formátu PDF source_code.zip .............................. Zdrojové soubory programu Balsamiq Mockups storyboardy .................................................. Storyboardy °azené podle kategorií 1_podletni_prohlidka 1.png ... ... text.................................................................................. Text práce mandik_bachelor_thesis.pdf video_ukazky...................................................... Video ukázky ve formátu FLV medobrani.flv ...

85

Mobilní systém pro podporu v ela ské práce. Ond ej Mandík. ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta

Recommend Documents