POSODOBITEV INFORMACIJSKEGA SISTEMA ZA ...Evidenten primer uporabe optimizacijskega postopka je tudi integracija Googleove storitve, s katero pridobimo ustrezen optimiziran podatek

UNIVERZA V MARIBORU FAKULTETA ZA LOGISTIKO

Tadej Korošec

POSODOBITEV INFORMACIJSKEGA SISTEMA ZA OPTIMIZACIJO

ORGANIZACIJE PREVOZOV V INVALIDSKI ORGANIZACIJI

magistrsko delo

Celje, november 2012

UNIVERZA V MARIBORU FAKULTETA ZA LOGISTIKO

Tadej Korošec

POSODOBITEV INFORMACIJSKEGA SISTEMA ZA OPTIMIZACIJO

ORGANIZACIJE PREVOZOV V INVALIDSKI ORGANIZACIJI

magistrsko delo

Mentor: doc. dr. Roman Gumzej Somentor: izred. prof. dr. Bojan Rosi

Celje, november 2012

IZJAVA O AVTORSTVU

magistrskega dela

Spodaj podpisan ____________________________________________________,

študent magistrskega študija Logistika sistemov z vpisno številko

_____________________________________, sem avtor magistrskega dela z

naslovom:

______________________________________________________________________

______________________________________________________________________.

S svojim podpisom zagotavljam, da:

• je predloženo delo rezultat izključno mojega lastnega raziskovalnega dela; • sem poskrbel, da so dela in mnenja drugih avtorjev oz. avtoric, ki jih uporabljam v

magistrskem delu, navedena oz. citirana v skladu s navodili Fakultete za logistiko Univerze v Mariboru;

• sem poskrbel, da so vsa dela in mnenja drugih avtorjev oz. avtoric navedena na seznamu virov, ki je sestavni del diplomskega dela in je zapisan v skladu s navodili Fakultete za logistiko Univerze v Mariboru;

• sem pridobil vsa dovoljenja za uporabo avtorskih del, ki so v celoti prenesena v diplomsko delo, in sem to tudi jasno zapisal v magistrskem delu;

• se zavedam, da je plagiatorstvo – predstavljanje tujih del, bodisi v obliki citata, bodisi v obliki skoraj dobesednega parafraziranja, bodisi v grafični obliki, s katerim so tuje misli oz. ideje predstavljene kot moje lastne – kaznivo po zakonu (Zakon o avtorskih in sorodnih pravicah, Uradni list RS, št. 21/95), prekršek pa podleže tudi ukrepom Fakultete za logistiko Univerze v Mariboru v skladu z njenimi pravili;

• se zavedam posledic, ki jih dokazano plagiatorstvo lahko predstavlja za predloženo delo in za moj status na Fakulteti za logistiko Univerze v Mariboru;

• je magistrsko delo jezikovno korektno in da je delo lektorirala _____________________________.

V Celju, dne _____________ Podpis avtorja/-ice:__________________

Tadej KOROŠEC

21001846

Posodobitev informacijskega sistema za organizacijo prevozov invalidov v

invalidski organizaciji

univ. dipl. slovenistka Manica Baša

30. 11. 2012

ZAHVALA

Spoštovanemu mentorju doc. dr. Romanu Gumzeju in somentorju izred. prof. dr. Bojanu

Rosiju se iskreno zahvaljujem za vse usmeritve in nasvete pri obravnavi strokovnih

vprašanj.

Posebna zahvala gre mojima staršema, ki me brezpogojno podpirata pri mojih

življenjskih projektih.

Posodobitev informacijskega sistema za optimizacijo organizacije prevozov v invalidski organizaciji

Magistrsko delo je koncipirano na dveh segmentih. Prvi podrobneje obravnava sedanji informacijski sistem (IS) za organizacijo prevozov v invalidski organizaciji, drugi pa predlaga rešitve za njegovo posodobitev v smeri avtomatiziranega razporejanja zahtevkov za prevoz (ZZP). Posodobitev IS smo predvideli z implementacijo petih algoritmov za avtomatizirano razporejanje ZZP, ki temeljijo na kontroli porabe razpoložljivih virov (kapacitete vozil, specifikacije uporabnikov prevozov in voznikov), hkrati pa uvajajo različne postopke optimizacije. Pri tem si pomagamo z vpeljavo pojmov statičnih in dinamičnih časovnih parametrov in ustreznimi izračuni nad podatki o zgodovini realiziranih prevozov. Evidenten primer uporabe optimizacijskega postopka je tudi integracija Googleove storitve, s katero pridobimo ustrezen optimiziran podatek poti ali časa, ko razporejamo ZZP ustreznemu vozilu, uporaba koncepta sistema za podporo odločanju pa nam pomaga upoštevati prenekatere pogoje v fazi razporejanja ZZP. Poleg predstavitve novih algoritmov je rezultat tega dela tudi izdelava študije izvedljivosti implementacije predlaganih posodobitev na sedanjem informacijskem sistemu v invalidski organizaciji. Klju čne besede: informacijski sistem, optimizacija, prevozi, časovni parameter, Google

Upgrade of information system for managing of transport optimization in disability organization

The master's thesis is conceived in two segments. The first elaborates on the existing information system (IS) for managing transports in a disability organization, while the other proposes its improvements in the direction of automated transportation request classification. The IS upgrade processes are foreseen through the implementation of five algorithms for the automated transportation request classification, based on usage of resource control (vehicles capacity, transport users and drivers' specifications) that also introduce a variety of optimization procedures. The improvements are accomplished by introducing the concepts of static and dynamic time parameters and by a corresponding analysis of data on the history of completed transports. An evident example of the optimization process usage is the integration of a Google's service that provides us with relevant optimized data on the path or time while the appropriate transportation request on a vehicle is classified. The usage of the decision support system concept helps us to consider different conditions in the phase of transportation request classification. In addition to the presentation of the novel algorithms the result of this thesis is also a feasibility study on the implementation of the pertaining information system’s upgrade. Keywords: information system, optimization, transportation, time parameter, Google

Fakulteta za logistiko Univerze v Mariboru Magistrski študijski program

Tadej Korošec: Posodobitev informacijskega sistema za optimizacijo organizacije prevozov v invalidski organizaciji

v

KAZALO

UVOD ............................................................................................................................... 1

1 METODE DELA ..................................................................................................... 3

2 RAZISKAVA .......................................................................................................... 4

2.1 PREDSTAVITEV INVALIDSKE ORGANIZACIJE ........................................................... 4

2.2 POSEBNI SOCIALNI PROGRAM PREVOZI DISTROFIKOV ............................................. 5

2.3 VRSTE ČASOVNIH PARAMETROV ............................................................................ 6

2.4 OSNOVNE ZNAČILNOSTI INVALIDSKIH PRIPOMOČKOV V PREVOZIH ...................... 10

2.5 SEDANJI IS ZA ORGANIZIRANJE PREVOZOV .......................................................... 13

2.6 APLIKACIJA PREVOZIDDS IN NJENI PODPROGRAMI ............................................. 14

2.7 PODPROGRAM UPORABNIK PROGRAMA ............................................................... 18

2.8 PODPROGRAM INTERNET DOSTOP ČLANOV .......................................................... 21

2.9 PODPROGRAM LASTNO GESLO ............................................................................. 23

2.10 PODPROGRAM ČLANI ....................................................................................... 23

2.11 PODPROGRAM VOZILA ..................................................................................... 24

2.12 PODPROGRAM VOZNIKI ................................................................................... 25

2.13 PODPROGRAM KRATICE LOKACIJ ..................................................................... 26

2.14 PODPROGRAM PARTNERJI ................................................................................ 26

2.15 PODPROGRAM RAZPORED VOZNIKOV .............................................................. 27

2.16 PODPROGRAM RAZPORED VOZIL ...................................................................... 28

2.17 PODPROGRAM PREVOZI2 ................................................................................. 29

2.17.1 Vnos novega ZZP .................................................................................... 32

2.17.2 Seznam shranjenih ZZP .......................................................................... 33

2.17.3 Listek ABCD ........................................................................................... 35

2.17.4 Spreminjanje statusov ZZP ..................................................................... 36

2.17.5 Obveščanje uporabnikov prevozov o spremembah statusov ZZP ........... 40

2.17.6 Koncept in merila razporejanja ter potrjevanja ZZP (operacija človek) 43

2.18 SPLETNA APLIKACIJA PORTALDDS ................................................................. 44

2.18.1 Modul Prevozi ......................................................................................... 47

2.18.2 Modul Nastavitve .................................................................................... 56

2.18.3 Modul Razpored voženj .......................................................................... 58

3 PREDLOGI ZA IZBOLJŠAVE SEDANJEGA IS ............................................ 60



vi

3.1 UVEDBA ŠIFRANTA ULIC ...................................................................................... 61

3.2 VPELJAVA MANJKAJOČIH ATRIBUTOV INDEKSOV VELJAVNOSTI RAZLIČNIH ENTITET63

3.3 DOPOLNITEV FUNKCIONALNOSTI GUI ZA UPRAVLJANJE NOVIH INDEKSOV

VELJAVNOSTI ............................................................................................................... 65

3.4 DOPOLNITEV ŠIFRANTA ČLANOV V KONTEKSTU DOLOČANJA VOLUMENSKE

ZASEDENOSTI NA RAVNI PODATKOV IN USTREZNA PREUREDITEV GUI ......................... 67

3.5 ALGORITMI ZA AVTOMATIZIRANO RAZPOREJANJE ZZP ....................................... 69

3.5.1 Splošno o algoritmih in njihovi predstavitvi ............................................... 70

3.5.2 Inicializacijski algoritem ............................................................................ 75

3.5.3 Algoritem za avtomatizirano razporejanje ZZP z upoštevanjem statično

določenih časovnih parametrov (A_SČP) ............................................................... 86

3.5.4 Algoritem za avtomatizirano razporejanje ZZP z upoštevanjem dinamično

določenih časovnih parametrov (A_DČP) .............................................................. 92

3.5.5 Algoritem za avtomatizirano razporejanje ZZP z upoštevanjem združevanja

ZZP na isti relaciji (A_Z) ...................................................................................... 103

3.5.6 Algoritem za avtomatizirano razporejanje ZZP z upoštevanjem optimizacije

poti (A_OP) ........................................................................................................... 107

4 ANALIZA ............................................................................................................ 121

ZAKLJU ČEK .............................................................................................................. 123

LITERATURA IN VIRI ............................................................................................ 129

PRILOGE

KAZALO SLIK

SLIKA 1: ČASOVNI PARAMETRI ZA IZVEDBO ENEGA ZZP ............................................. 6

SLIKA 2: PRIMER PRITRDILNIH MEHANIZMOV ................................................................ 8

SLIKA 3: VSTOPANJE INVALIDA NA ELEKTROMOTORNEM VOZIČKU V

NOTRANJOST VOZILA ........................................................................................................... 11

SLIKA 4: INVALIDSKI VOZI ČEK NA ROČNI POGON ....................................................... 12

SLIKA 5: INVALIDSKI VOZI ČEK NA ELEKTROMOTORNI POGON ............................... 12

SLIKA 6: ELEKTROMOTORNI SKUTER .............................................................................. 12



vii

SLIKA 7: ROLATOR, HODULJA IN BERGLE ....................................................................... 12

SLIKA 8: OSNOVNI KONCEPT DELOVANJA SEDANJEGA IS ......................................... 14

SLIKA 9: VRSTE UPORABNIKOV APLIKACIJE PREVOZIDDS ........................................ 15

SLIKA 10: ARHITEKTURA SEDANJEGA IS ......................................................................... 16

SLIKA 11: PRIJAVNO OKNO APLIKACIJE PREVOZIDDS ................................................. 18

SLIKA 12: UPORABNIK PROGRAMA: ADMINISTRACIJA UPORABNIKA .................... 19

SLIKA 13: UPORABNIK PROGRAMA: PRAVICE MENIJEV .............................................. 20

SLIKA 14: UPORABNIK PROGRAMA: STATISTIKE OPRAVIL UPORABNIKA ............. 21

SLIKA 15: INTERNET DOSTOP ČLANOV ............................................................................ 22

SLIKA 16: LASTNO GESLO .................................................................................................... 23

SLIKA 17: ŠIFRANT – ČLANI ................................................................................................. 24

SLIKA 18: ŠIFRANT – VOZILA .............................................................................................. 25

SLIKA 19: ŠIFRANT – VOZNIKI............................................................................................. 25

SLIKA 20: ŠIFRANT – KRATICE LOKACIJ .......................................................................... 26

SLIKA 21: ŠIFRANT – PARTNERJI ........................................................................................ 27

SLIKA 22: ORODJA – RAZPORED VOZNIKOV ................................................................... 28

SLIKA 23: ORODJA – RAZPORED VOZIL (S POTNIM NALOGOM)................................. 29

SLIKA 24: SHEMATSKI PRIKAZ PODROČIJ GUI PODPROGRAMA PREVOZI2 ............ 30

SLIKA 25: ORODJA – PREVOZI2 ........................................................................................... 31

SLIKA 26: ELEMENTI POMOŽNEGA MENIJA ZA OPERACIJE NA GLAVNEM

SEZNAMU ZZP ......................................................................................................................... 35

SLIKA 27: NATISNJEN LISTEK ABCD ................................................................................. 36

SLIKA 28: MOŽNOSTI PREHAJANJA STATUSOV ZZP ..................................................... 39

SLIKA 29: PRIJAVA V PORTALDDS ..................................................................................... 45

SLIKA 30: GLAVNO OKNO PORTALA ................................................................................. 46

SLIKA 31: MODUL PREVOZI – OSNOVNO .......................................................................... 48

SLIKA 32: MODUL PREVOZI – DATUM IZBRAN ............................................................... 49

SLIKA 33: MODUL PREVOZI – PREKLIC ZZP ..................................................................... 50



viii

SLIKA 34: MODUL PREVOZI – PRIMARNI PREVOZ ......................................................... 53

SLIKA 35: MODUL PREVOZI – SEKUNDARNI PREVOZ ................................................... 54

SLIKA 36: MODUL PREVOZI – POTRDITEV PRAVILNOSTI PODATKOV ..................... 54

SLIKA 37: MODUL PREVOZI – DIAGRAM POTEKA SHRANJEVANJA ZZP .................. 55

SLIKA 38: NASTAVITVE – OSEBNI PODATKI ČLANA ..................................................... 56

SLIKA 39: NASTAVITVE – NAČIN OBVEŠČANJA O SPREMEMBAH PREVOZOV ...... 57

SLIKA 40: NASTAVITVE – SPREMEMBA OSEBNEGA GESLA ........................................ 58

SLIKA 41: RAZPORED VOŽENJ ............................................................................................. 59

SLIKA 42: ATRIBUTI ENTITETE ULICA .............................................................................. 62

SLIKA 43: NOVA ATRIBUTA ENTITETE VOZNJA IN NJENA POVEZAVA Z ENTITETO

ULICA ........................................................................................................................................ 63

SLIKA 44: NOVI ATRIBUTI V ENTITETAH VOZILO, VOZNIK IN CLAN ....................... 64

SLIKA 45: POVEZAVA ENTITET SIFRANT_SIFRANTOV, SIFRANT IN CLAN ............. 68

SLIKA 46: RAZVOJ ALGORITMA.......................................................................................... 71

SLIKA 47: GRADNIKI DIAGRAMA POTEKA ...................................................................... 73

SLIKA 48: PRIMER ZAPISA ALGORITMA V PROGRAMSKEM JEZIKU ......................... 74

SLIKA 49: INICIALIZACIJSKI ALGORITEM 1/2 .................................................................. 78

SLIKA 50: INICIALIZACIJSKI ALGORITEM 2/2 .................................................................. 79

SLIKA 51: ALGORITEM A_SČP 1/2 ....................................................................................... 87

SLIKA 52: ALGORITEM A_SČP 2/2 ....................................................................................... 88

SLIKA 53: ALGORITEM A_DČP 1/2 ....................................................................................... 93

SLIKA 54: ALGORITEM A_DČP 2/2 ....................................................................................... 94

SLIKA 55: ALGORITEM A_DČP (IZRAČUN ČASA T1) ...................................................... 95





SLIKA 60: ALGORITEM A_DČP (IZRAČUN ČASA T6) .................................................... 100



ix

SLIKA 61: ALGORITEM A_DČP (IZRAČUN ČASA T7) .................................................... 100

SLIKA 62: ALGORITEM A_Z 1/3 .......................................................................................... 104



SLIKA 65: ALGORITEM A_OP 1/2 ....................................................................................... 113

SLIKA 66: ALGORITEM A_OP 2/2 ....................................................................................... 114

SLIKA 67: ALGORITEM A_OP (IZRAČUN ČASA T1) ....................................................... 115







KAZALO TABEL

TABELA 1: MINIMALNE SISTEMSKE ZAHTEVE ZA OPTIMALNO DELOVANJE

APLIKACIJE PREVOZIDDS ..................................................................................................... 16

TABELA 2: ZGRADBA MENIJEV IN OSNOVNI PODPROGRAMI APLIKACIJE

PREVOZIDDS ............................................................................................................................. 17

TABELA 3: PRIMER PODATKOV ENTITETE ULICA .......................................................... 62

TABELA 4: OPREDELITEV ŠIFRANTA VRST ORTOPEDSKIH PRIPOMOČKOV V

SEDANJI PODATKOVNI TABELI SIFRANT_SIFRANTOV ................................................. 67

TABELA 5: OPREDELITEV NOVIH VRST ORTOPEDSKIH PRIPOMOČKOV V SEDANJI

PODATKOVNI TABELI SIFRANT ........................................................................................... 67

TABELA 6: VZPOSTAVITEV NOVE PODATKOVNE TABELE

GLOBALNASPREMENLJIVKA ............................................................................................... 81

TABELA 7: PODATKI TABELE GLOBALNASPREMENLJIVKA ........................................ 81

TABELA 8: VZPOSTAVITEV NOVE PODATKOVNE TABELE VOZNIKTUJINA ............ 83



x

TABELA 9: VZPOSTAVITEV NOVE PODATKOVNE TABELE VOZILOTUJINA............. 83

TABELA 10: VZPOSTAVITEV NOVE PODATKOVNE TABELE VOZNIKSLOVENIJA ... 83


VOZNIKIZMENSKODELO ....................................................................................................... 84

TABELA 12: VZPOSTAVITEV NOVE PODATKOVNE TABELE VOZNIKLD ................... 84

TABELA 13: OPREDELITEV ŠIFRANTA TIPOV VOŽNJE V SLOVENIJI V

PODATKOVNI TABELI SIFRANT_SIFRANTOV .................................................................. 84

TABELA 14: OPREDELITEV NOVIH ZAPISOV ZA VOŽNJE V SLOVENIJI V SEDANJI


TABELA 15: OPREDELITEV ŠIFRANTA TIPOV IZMENSKEGA DELA V PODATKOVNI

TABELI SIFRANT_SIFRANTOV ............................................................................................. 85

TABELA 16: OPREDELITEV NOVIH ZAPISOV IZMENSKEGA DELA V SEDANJI


TABELA 17: OPREDELITEV ŠIFRANTA TIPOV LOKACIJ VOŽENJ VOZNIKA V

PODATKOVNI TABELI SIFRANT_SIFRANTOV .................................................................. 85

TABELA 18: OPREDELITEV NOVIH ZAPISOV LOKACIJ VOŽENJ VOZNIKA V


TABELA 19: VZPOSTAVITEV NOVEGA ATRIBUTA

PRILJUBLJENALOKVOZNJE_SIF_ID V PODATKOVNI TABELI VOZNIK ...................... 85


UPOIZOGIBANJEVOZNIKOV ................................................................................................. 91

TABELA 21: VZPOSTAVITEV NOVE PODATKOVNE TABELE UPOIZOGIBANJEVOZIL91

TABELA 22: VZPOSTAVITEV NOVE PODATKOVNE TABELE UPOIZOGIBANJEUPO 91


VOZNIKIZOGIBANJEUPO ....................................................................................................... 92

TABELA 24: ZGRADBA IN ATRIBUTI ENTITETE 'POZICIJE' S PRIMEROMA

PODATKOV .............................................................................................................................. 102



xi

KRATICE

IS informacijski sistem

GUI grafični uporabniški vmesnik (angl. graphical user interface)

OP organizator prevoza

ZZP zahtevek za prevoz



1

UVOD

V zadnjih letih se naglo povečuje vpeljevanje novih tehnologij in različnih

informacijskih rešitev v poslovna okolja, ki temeljijo na optimizaciji poslovnih in

drugih procesov v organizaciji. Optimizacijo pogosto spremljajo postopki

informatizacije, ki z razvojem informacijskih sistemov (IS) pozitivno vpliva na

poslovanje organizacije. Ti postopki morajo biti skrbno načrtovani in usklajeni z vsemi

akterji informacijskega sistema. Informatizacija se navadno prične s študijo izvedljivosti

prenove IS in konča z uvedbo na novo razvitega IS v poslovno okolje, pri čemer mora

biti zagotovljeno, da je po prenovi IS delo v organizaciji mogoče opraviti učinkoviteje,

v krajšem času in z manjšimi stroški.

Podrobneje se bomo seznanili s sedanjim IS za organiziranje prevozov v invalidski

organizaciji, ki je prvi informatiziran način delovanja takšne organizacije na področju

logistike pri nas. Ta IS še ne podpira naprednejših storitev, ki bi vključevale različne

optimizacijske metode v logistiki. Zato se bomo v magistrskem delu posvetili obravnavi

konkretnega primera nadgradnje IS v invalidski organizaciji, v kateri bodo te storitve

vključene.

Z nadgradnjo IS želimo spremeniti koncept delovanja sedanjega IS, tako da ga

preoblikujemo iz osnovnega orodja za zbiranje podatkov v naprednejši IS, v katerem bo

mogoče samodejno opraviti pomembnejši del opravil, s čimer se bo zmanjšala potreba

po prisotnosti človeka (organizatorja prevozov) v sedanjem obsegu. Tako se funkcija

organizatorja prevozov, kot pomembnega akterja v IS invalidske organizacije, spremeni

iz upravljavske v nadzorno. To pomeni razbremenitev organizatorja prevozov pri

upravljanju novega IS na eni strani ter uporabo sistema za podporo odločanju na drugi,

kar lahko pozitivno vpliva na učinkovitost, kakovost, hitrost opravljenega dela in ne

nazadnje na stroškovno komponento pri organiziranju ter izvajanju prevozov invalidov.

Pri tem je treba upoštevati mnogo posebnosti invalidske organizacije, ki so pomembne z

vidika logistike. Tako smo pred izzivom optimizacije organizacije prevozov, pri čemer

moramo poudariti, da ne gre za tipičen prevoz oseb, ampak za specializiran prevoz



2

invalidov. Zato je treba poskrbeti, da se zaradi novega sistema, ki bo uveljavljen z

nadgradnjo IS, ne poslabša kakovost prevozov.

Glavna cilja tega magistrskega dela sta tako:

• opisati invalidsko organizacijo, pomen izvajanja prevozov ter podrobneje

predstaviti sedanji IS za organiziranje prevozov v invalidski organizaciji, pri čemer

bomo opredelili tudi naloge in postopke dela organizatorja prevozov ter drugih

uporabnikov informacijskega sistema;

• predlagati algoritme za izvedbo naprednejšega IS, ki bo znal brez posredovanja

organizatorja prevozov samostojno določati proste voznike in vozila ter jim

ustrezno razporediti (dodeliti) zahtevke za prevoz (ZZP), s čimer se vloga

organizatorja prevozov spremeni iz upravljavske v nadzorno.

Predpostavljamo, da bo z uporabo predlaganih algoritmov novega IS mogoče

optimizirati čas in pot voznikov, IS pa bo sposoben samostojno načrtovati prevoze z

ustreznimi postopki razporejanja ZZP. Konkretno vprašanje, s katerim se bomo

ukvarjali, je torej implementacija ustreznih informacijskih rešitev, kar se nanaša na

izvedbeno dokumentacijo, ki jo lahko razvijalci programske opreme uporabijo kot

specifikacijo ob prihodnji in neizbežni posodobitvi sedanjega IS za organiziranje

prevozov v invalidski organizaciji.



3

1 METODE DELA

Magistrsko delo temelji na naslednjih metodah, ki smo jih uporabili pri raziskavi:

• metoda deskripcije;

• metoda analize notranjih in zunanjih virov;

• metoda formalnih opisov podatkovnega in funkcionalnega modela;

• metoda strukturiranega besedila pri opisu algoritmov;

• metoda diagramov poteka pri predstavitvi algoritmov.

Z metodo deskripcije opišemo sedanji IS in njegove bistvene funkcionalnosti. Metoda

analize notranjih in zunanjih virov nam pomaga zbrati dovolj dejstev, s katerimi

predstavimo invalidsko organizacijo in pomen izvajanja prevozov. Z metodo formalnih

opisov podatkovnega in funkcionalnega modela podatkov opišemo tiste dele

podatkovne baze, ki se skozi implementacijo rešitev spreminjajo. Za lažjo grafično

ponazoritev algoritmov si bomo pomagali z metodo diagramov poteka. Navedene

metode nam omogočajo, da lahko celovito predstavimo delovanje in bistvene

funkcionalnosti sedanjega IS ter tudi grafično, z diagrami poteka in diagrami Swimlane,

predstavimo izboljšave IS, pri čemer je govor o posodobitvi IS.



4

2 RAZISKAVA

2.1 Predstavitev invalidske organizacije

Društvo distrofikov Slovenije (v nadaljevanju društvo) je reprezentativna invalidska

organizacija, ki v slovenskem prostoru deluje že od leta 1969. V Jugoslaviji je bila

ustanovljena prva oblika današnjega društva, ki si že od tedaj prizadeva združevati

distrofike, njihove ožje in širše družinske člane ter prijatelje. Seveda pa združevanje še

zdaleč ni edina dejavnost društva. Pomembno je tudi njegovo delovanje na

zdravstvenem in socialnem področju, poleg tega si prizadeva za enakopravno

integracijo invalidov v družbo.

V društvo, ki deluje na območju celotne Slovenije, je vključenih več kot tisoč rednih

članov in skoraj toliko podpornih članov. Redni član društva je oseba, ki ima na podlagi

medicinskih indikacij potrjeno eno izmed oblik progresivnih mišičnih ali živčno-

mišičnih obolenj. To medicinsko indikacijo član pred včlanitvijo v društvo izkaže z

ustrezno dokumentacijo. Stopnja invalidnosti distrofikov je velikokrat stoodstotna, pri

čemer govorimo o tako imenovani gibalni invalidnosti, ki se najpogosteje izraža kot

izjemno otežena hoja ali uporaba invalidskega vozička, na poznejših stopnjah bolezni pa

se ti klinični znaki še poslabšajo.

Distrofiki kljub visoki stopnji invalidnosti uspešno razvijajo svoje intelektualne

potenciale tudi s pomočjo društva. Zaradi narave invalidnosti namreč za delovanje in

življenje potrebujejo nekatere elemente, ki jih društvo vključuje v izvajanje posebnih

socialnih programov za blažitev socialnih, medicinskih in družbenih razlik v procesu

integracije distrofikov v družbo. Posebni socialni programi, ki jih društvo sedaj izvaja,

so: prevozi distrofikov, osebna asistenca, celovita obnovitvena rehabilitacija,

usposabljanje za aktivno življenje in delo, ohranjevanje zdravja, podpora pri

izobraževanju, informativna dejavnost, podporno bivanje in prilagajanje okolja

distrofikom, oskrba s tehničnimi pripomočki, dnevni center druženja in ustvarjalnosti,

prva socialna pomoč, nega in fizična pomoč, športne dejavnosti distrofikov, kulturno



5

udejstvovanje distrofikov ter mladi distrofiki in Evropa ("Društvo distrofikov Slovenije"

[O društvu], b. d.).

Za boljše razumevanje delovanja društva bi bilo treba natančneje poznati vseh petnajst

posebnih socialnih programov, ki jih društvo samostojno izvaja, kar pa ni osnovni

namen tega dela. Za razumevanje naše nadaljnje obravnave je treba nekoliko

podrobneje predstaviti en program, in sicer posebni socialni program prevozi

distrofikov.

2.2 Posebni socialni program prevozi distrofikov

Eden ključnih in najpomembnejših posebnih socialnih programov, ki jih Društvo

distrofikov Slovenije samostojno izvaja, je organizacija in izvedba prevozov

distrofikov. Prevozi se izvajajo s posebej prilagojenimi vozili, ki omogočajo vstop

enega ali več uporabnikov programa v vozilo. Uporabniki imajo navadno invalidski

voziček, skuter, bergle, hodulje ali druge invalidske pripomočke. V vozilu se lahko

poleg invalida vozijo tudi osebni asistenti, ki samostojno sedijo na sedežu vozila.

Prevozi distrofikov potekajo na območju celotne Slovenije s koncentracijo v Ljubljani,

Mariboru in Izoli, glede na zmožnosti in potrebe pa tudi v tujini. Namen posameznega

prevoza je različen. Zaradi omejenih finančnih sredstev se prevozi izvajajo predvsem za

prevoz distrofikov na delo, v šolo, na fakulteto, v zdravstvene ustanove in podobno.

Sledijo prevozi na kulturne in druge prireditve ter prevozi, ki se uvrščajo med

prostočasne dejavnosti člana.

Pomen izvajanja posebnega socialnega programa prevozov distrofikov je zagotavljanje

prilagojenega prevoza distrofikom in drugim invalidom glede na njihove specifične

potrebe, saj so druge oblike prevoza (na primer javni prevoz) distrofikom težje dostopne

tako finančno kot zaradi arhitektonskih ovir in usposobljenosti voznikov. Bistvena

posebnost izvajanja takih prevozov je, da gre za prevoz invalidov v prilagojenih vozilih

in specifično obliko izvajanja prevoza. Voznik je tudi usposobljen, da ustrezno zavaruje

tovor v vozilu. V našem primeru gre za ustrezno pritrditev invalidskih pripomočkov in

namestitev invalidov v vozilu. Voznik mora vožnjo nenehno prilagajati invalidu, saj

preveč tresljajev med vožnjo negativno vpliva na njegovo počutje.



6

Ker pa ima društvo razmeroma malo prilagojenih vozil, je treba čim bolj optimalno

uporabljati vire voznikov, vozil in drugih sredstev, da je mogoče vsak dan ustreči čim

več invalidom, ki želijo prevoz, ter da se te vožnje tudi opravijo. Za vse to poskrbi

oseba, odgovorna za organizacijo. Organizator prevozov zbira in ureja podatke o

prevozih. Njegova glavna naloga pa je, da v množici zahtevkov za prevoz (ki mu jih

posredujejo uporabniki prevozov oziroma invalidi) določi tiste, ki imajo večjo prednost,

in jih razporedi glede na razpoložljive voznike. Pri tem skuša poskrbeti, da se opravi

čim več prevozov in ni večjih časovnih zamud.

Prevoz invalida tako lahko opišemo kot vožnjo iz kraja A v kraj B. Kraj A navadno

imenujemo mesto (kraj) odhoda. To je kraj, na katerem invalid čaka na voznika.

Praviloma je to vnaprej dogovorjena lokacija zunaj stavb, ki jo je praviloma mogoče

opredeliti z nazivom institucije (na primer Fakulteta za logistiko, Celje) ali z ulico in

hišno številko. Kraj B pa po analogiji imenujemo mesto (kraj) prihoda. Gre za ciljno

lokacijo, kamor je treba invalida dostaviti. Tudi to je vnaprej dogovorjena lokacija zunaj

stavb, opredeljena glede na naziv institucije ali njen naslov. Za celovito informacijo o

vožnji, ki jo je treba opraviti, pa voznik potrebuje še podatek o datumu in času vožnje

ter uporabniku prevoza (invalidu), ki ga je treba prepeljati na želeni cilj. To so tudi

elementi zahtevka za prevoz, ki ga opisujemo v poglavju 2.17.1.

2.3 Vrste časovnih parametrov

Kot smo nakazali v prejšnjih poglavjih, se logistika, ki jo obravnavamo v tem

magistrskem delu, nanaša na organiziranje prevozov invalidov v Sloveniji in redkeje

tudi v tujini. Pri izvedbi posameznega prevoza je zelo pomembna časovna komponenta.

Pri tem imamo v mislih čas, ki je potreben za prevoz invalida. Razčlenimo ga lahko na

naslednji način:

Slika 1: Časovni parametri za izvedbo enega ZZP

t1 t2 t3 t4 t5

Tj

t6 t7



7

Slika 1 tako opredeljuje časovne intervale pri prevozu invalida v vsakdanjih

okoliščinah, ki jim pravimo tudi časovni parametri:

• t1: čas, da se voznik pripelje na lokacijo uporabnika (mesto odhoda v ZZP);

• t2: čas, ko voznik čaka na prihod uporabnika;

• t3: čas priprave vozila pred pričetkom vožnje (odpiranje vrat in/ali rampe,

namestitev pritrdilnih sidrišč v kabino vozila);

• t4: čas za ustrezno namestitev invalida v vozilu in njegovo zavarovanje s

pritrditvami;

• t5: čas vožnje (zajema tudi čas postavitve vozila na ustrezno lokacijo, ki omogoča

čim bolj varen in najlažji izstop invalida iz vozila);

• t6: čas, potreben za odstranitev varnostnih pritrditev in izstop invalida iz vozila;

• t7: čas priprave vozila po zaključku vožnje (zapiranje vrat in/ali rampe, odstranitev

pritrdilnih sidrišč iz kabine vozila).

V nadaljevanju so opisani posamezni časovni parametri:

• Čas t1 je čas, ki ga voznik porabi, da se pripelje na lokacijo odhoda uporabnika. Pri

tem uporabnik včasih potrebuje nekaj časa, da pride do vozila, in ga mora voznik

počakati. V idealnih okoliščinah bi bil ta čas enak 0 in bi uporabnik voznika že

čakal na dogovorjeni lokaciji.

• V praksi pa mora voznik žal pogosto čakati na prihod uporabnika. Zgodi se celo, da

mora po uporabnika v stanovanje, šolo ipd., saj slednji zaradi invalidnosti ne more

sam do vozila. V čas t2 so zajeti tudi opisani dejavniki.

• Pred vstopom invalida je treba v kabino vozila namestiti pritrdilne mehanizme

(Slika 2), ki ustrezajo potrebam invalida in dimenzijam njegovega ortopedskega

pripomočka (invalidski voziček, hodulja ipd.). Voznik zatem ustrezno namesti

invalida v vozilo, pri čemer s pritrdilnimi mehanizmi invalidski voziček fiksno

pritrdi na tla vozila. To zajema čas t3.

• Čas t4 vključuje čas za ustrezno namestitev invalida v vozilu in njegovo

zavarovanje z ustreznimi pritrditvami.

• Sledi čas t5, ki je čas vožnje uporabnika od začetne do končne točke. Ta čas

vključuje tudi čas postavitve vozila na ustrezno lokacijo, ki omogoča invalidu čim

bolj varen in udoben izstop iz vozila.



8

• Čas t6 je potreben za odstranitev varnostnih pritrditev in izstop invalida iz vozila.

• Tako kot čas t3 je tudi čas t7 potreben za pripravo vozila po koncu vožnje, pri čemer

se odstranijo pritrdilna sidrišča iz kabine vozila. Vozilo je tako pripravljeno na

naslednjo vožnjo.

Kot opazimo, se pred vožnjo in po njej porabi precej časa. K temu je treba dodati še

precizno in upočasnjeno vožnjo, ki se prilagaja vsakemu invalidu posebej, tako da je

vožnja varna in udobna (če so vozišča delno poškodovana, je še zamudnejša zaradi

invalidu prilagojenega načina in tehnike vožnje).

Slika 2: Primer pritrdilnih mehanizmov

Vir: "Primer pritrdilnih mehanizmov" [Sumaprojekt d. o. o.], b. d.

Povejmo, da je Tj vsota vseh časovnih parametrov pri posameznem ZZP in pomeni čas,

ki je potreben za izvedbo enega ZZP, torej prevoz invalida od začetne do končne

lokacije. Voznik ima v delovniku praviloma dodeljenih več ZZP, ima pa tudi pravico do

obveznega odmora za malico (označimo ga s Tm, pri predstavitvi algoritmov pa

uporabimo vrednost globalne spremenljivke gCasTrajanjeMalice). Tako nam končni

čas zasedenosti voznika, ki ga označimo s T, pove, koliko časa bo voznik angažiran v

delovniku. Pomembno je, da čas T posameznega voznika ne preseže njegove delovne

obveznosti. Povedano lahko matematično zapišemo z naslednjima formulama, kjer

enačba [1] prikazuje izračun vsote vseh časovnih parametrov za en ZZP, enačba [2] pa

izračun časa zasedenosti voznika v delovniku:



9

�� = ∑ ��; � = �, �, … , ��=� [1]

� = ∑ �� + �� ; = �,�, … , = š�.�� [2]

Časovne parametre glede na način določitve njihove vrednosti v IS delimo na:

• statične časovne parametre in

• dinamične časovne parametre.

Statični časovni parametri so zgoraj omenjeni časovni intervali, ki so določeni statično.

To pomeni, da jih v posebnem šifrantu določi OP in se med procesom razporejanja ZZP

ne spreminjajo. OP ima sicer možnost, da statične časovne parametre spremeni

kadarkoli po končanem procesu razporejanja ZZP. Ker se med fazo razporejanja ZZP

časovni parametri ne spreminjajo, pravimo, da so statični. Statični časovni parametri so

časi: t1, t2, t3, t4, t5, t6 in t7.

V primerjavi s statičnimi so dinamični časovni parametri tisti, ki se določajo sproti.

Tudi to so časovni intervali pri prevozu invalida. Ker se izračunavajo pred vsako

ponovitvijo razporejanja ZZP, pravimo, da so dinamični. Izračuni vrednosti dinamičnih

časovnih parametrov potekajo na podlagi podatkov o zgodovini opravljenih prevozov.

Dinamični časovni parametri so časi: t1, t2 in t5, ne morejo biti pa tudi časi t3, t4 t6 in t7,

saj naprave GPS v vozilih niso opremljene za njihovo merjenje. Zato moramo pri

obravnavi dinamičnih časovnih parametrov čase t3, t4 t6 in t7 izpustiti. Njihove vrednosti

morajo tako nadomestiti statični časovni parametri, da lahko poteka proces

avtomatiziranega razporejanja ZZP, ki ga opisujemo v nadaljevanju.

Časovne parametre po dominantnosti delimo na:

• statične časovne parametre na globalni ravni;

• dinamični časovni parametri na globalni ravni;

• statične časovne parametre na lokalni ravni;

• dinamični časovni parametri na lokalni ravni.



10

Statični časovni parametri na globalni ravni so parametri, določeni v nastavitvah

programa, določi in modificira pa jih OP. Za vse uporabnike prevozov veljajo enako.

Posamezne lastne časovne parametre uporabnika prevozov imenujemo statični časovni

parametri na lokalni ravni. Ti parametri tudi prevladujejo, saj se statični časovni

parametri na globalni ravni pri avtomatiziranem načinu razporejanja ZZP ne upoštevajo

pri izračunu časa T, če so določeni tudi statični časovni parametri na lokalni ravni. Če

pa kateri od statičnih časovnih parametrov na lokalni ravni pri uporabniku ni določen, se

za manjkajoči časovni interval upoštevajo statični časovni parametri na globalni ravni.

Dinamičnih časovnih parametrov na globalni ravni in dinamičnih časovnih parametrov

na lokalni ravni za obravnavo zadevnega problema avtomatiziranega načina

razporejanja ZZP ne potrebujemo, zato jih ne opisujemo podrobneje.

2.4 Osnovne značilnosti invalidskih pripomo čkov v prevozih

Invalid za svoje čim bolj neodvisno gibanje uporablja različne invalidske pripomočke,

ki so odvisni od njegove stopnje invalidnosti. Invalidi, ki jih obravnavamo v okviru

izvajanja in opravljanja prevozov, so uporabniki različnih vrst invalidskih pripomočkov

in jih lahko razdelimo v več kategorij, glede na prakso izvajanja prevozov v invalidski

organizaciji. To so uporabniki:

• navadnega invalidskega vozička;

• invalidskega vozička na elektromotorni pogon;

• elektromotornega skuterja;

• rolatorja, hodulje in bergel.

Poznavanje teh kategorij je pomembno, saj bomo tehnične značilnosti invalidskih

pripomočkov potrebovali v nadaljevanju, ko bomo obravnavali zmogljivost vozila na

stopnji razporejanja zahtevkov za prevoz. Pri tem bo treba upoštevali tehnične podatke

invalidskega pripomočka uporabnika prevoza, zato si poglejmo osnovne značilnosti

invalidskih pripomočkov, ki jih invalidi v prevozih s prilagojenimi vozili najpogosteje

uporabljajo.

Pozicioniranje invalidskega vozička v vozilo mora biti izvedeno v skladu z varnostnimi

usmeritvami in ga opravi voznik ali invalid po navodilih voznika, kot prikazuje Slika 3.



11

Slika 3: Vstopanje invalida na elektromotornem vozičku v notranjost vozila

Invalidski voziček na ročni in elektromotorni pogon

Invalidski voziček na ročni pogon (Slika 4) je osnovni pripomoček, ki invalidom

omogoča premagovanje krajših razdalj samostojno ali s pomočjo druge osebe. Ta lahko

invalidski voziček potiska od zadaj in invalidu lajša premagovanje ovir. Invalid se lahko

poganja tudi sam z rokami, če njegovo zdravstveno stanje dopušča, da uporablja roke v

ta namen. Nekateri vozički so zložljivi. Pri invalidih s hujšimi oblikami invalidnosti pa

se pogosto uporabljajo invalidski vozički na elektromotorni pogon (Slika 5). Njihova

bistvena značilnost je, da so namenjeni za uporabo doma in zunaj doma, zato so

konstrukcijsko bolj ojačeni, robustnejši in težji. Tak voziček invalid praviloma upravlja

sam s komandno ročico. Njegovi sestavni deli so še akumulatorji in elektromotorja.

Vsak invalidski voziček je po umestitvi v vozilo ustrezno fiksiran na tla vozila s

pritrdilnimi sidrišči.

Fakulteta za logistiko Univerze v Mariboru

Tadej Korošec: Posodobitev informacijskega sistema za optimizacijo invalidski organizaciji

Slika 4: Invalidski voziček na roč

Vir: "Voziček navadni" [Ortosana d.o.o.

Elektromotorni skuter

Elektromotorni skuter (Slika

elektromotorni pogon. Primeren je za invalide, ki se lahko postavijo na noge in lahko za

krajši čas samostojno ali

vozilo pa so skuterji nekoliko manj okretn

jih ni mogoče, invalid pa

Rolatorji, hodulje in bergle

Invalidi z manjšo stopnjo invalidnosti

rolatorja, hodulje ali bergel (

s štirimi kolesi. Ker se invalid tudi

jih invalid upravlja z rokami. Znač

lahka in do določene mere zložljiv

vozilu sedijo na sedežih.

Slika 6: Elektromotorni

Vir: "Skuter" [Ortosana d.o.o.


Posodobitev informacijskega sistema za optimizacijo organizacije prevozov v invalidski organizaciji

ček na ročni pogon

Ortosana d.o.o.] , b.d.

Slika 5: Invalidski voziček na elektromotorni

pogon

Vir: "Voziček elektromotorni" [

Slika 6) je funkcionalno zelo podoben invalidskemu vozič


čas samostojno ali s pomočjo druge osebe stojijo. Z vidika prostorske umestitve v

vozilo pa so skuterji nekoliko manj okretni in so daljši od invalidski

, invalid pa med vožnjo praviloma sedi v sedežu skuterja.

bergle

z manjšo stopnjo invalidnosti so praviloma zmožni samostojno hoditi z uporabo

ergel (Slika 7). Rolator je naprednejša oblika hodulje, opremljena

s štirimi kolesi. Ker se invalid tudi dejansko naslanja nanj, je opremljen

invalid upravlja z rokami. Značilnost obeh, rolatorja in hodulje, pa je, da sta izjemno

čene mere zložljiva. Invalidi, ki uporabljajo rolator, hoduljo ali bergle

vozilu sedijo na sedežih.

Elektromotorni skuter

sana d.o.o.] , b.d.

Slika 7: Rolator, hodulja in bergle

Vir: "Pripomočki" [ Ortosana d.o.o.

Magistrski študijski program

organizacije prevozov v 12

ček na elektromotorni

" [ Ortosana d.o.o.] , b.d.

elo podoben invalidskemu vozičku na


stojijo. Z vidika prostorske umestitve v

invalidskih vozičkov. Zložiti

praviloma sedi v sedežu skuterja.

so praviloma zmožni samostojno hoditi z uporabo

. Rolator je naprednejša oblika hodulje, opremljena

opremljen z zavorami, ki

pa je, da sta izjemno

rolator, hoduljo ali bergle, v

: Rolator, hodulja in bergle

Ortosana d.o.o.] , b.d.



13

Rampe

Poznamo več vrst ramp, ki omogočajo vstop invalida z invalidskim vozičkom v vozilo.

Najbolj znana in v invalidskih organizacijah priljubljena je zložljiva ploščad, ki je

pritrjena v zadnji del vozila. Ob odprtju se položi na zunanjo stran vozila, tako da

invalid lahko vstopi. Na rampah so pritrjene plinske vzmeti, ki omogočajo lažje

odpiranje in zapiranje. Primer take rampe je prikazan na Slika 3. Uporabljajo pa se tudi

druge vrste ramp, kot so aluminijaste teleskopske rampe in hidravlične dvigalne rampe.

Te se dvigajo in spuščajo s hidravliko in pripadajočimi motorji.

2.5 Sedanji IS za organiziranje prevozov

Število zahtevkov za prevoz v Društvu distrofikov Slovenije se iz leta v leto povečuje.

To pomeni, da poseben socialni program 'prevozi distrofikov' napreduje in postaja

logistično vedno bolj kompleksen. Ob predpostavki, da je treba vse prejete zahtevke za

prevoz čim hitreje obdelati in spraviti v obliko, ki omogoča tudi poznejši dostop do

statističnih podatkov o prevozih, so se v Društvu distrofikov Slovenije odločili razviti

informacijski sistem za podporo logistiki v Službi prevozov. Sistem so razvijali fazno in

ga sproti dopolnjevali glede na interne potrebe in zahteve financerjev, ki jim je treba

redno poročati o izvajanju prevozov.

Osnovni koncept delovanja sedanjega IS je zasnovan na petih segmentih, in sicer (Slika

8):

• uporabniki posebnega socialnega programa;

• koordinator prevoza;

• WIN32-aplikacija PrevoziDDS;

• podatkovna baza 'prevozi';

• spletna aplikacija PortalDDS.

Kot smo že omenili, so uporabniki posebnega socialnega programa prevozov invalidi, ki

se jim omogoča transport s prilagojenimi društvenimi vozili. Ti na društvo podajo tako

imenovan zahtevek za prevoz (ZZP), in sicer na dva načina. Ena možnost je, da prek

telefona pokličejo Službo prevozov v času uradnih ur. Koordinator prevoza sprejme



14

njihov klic in z računalniškim programom PrevoziDDS v informacijski sistem shrani

vse ključne podatke, ki jih zahtevek za prevoz predvideva (glej poglavje 2.17.1). Druga

možnost pa je, da uporabniki prevoza vstopijo v spletno aplikacijo PortalDDS, kjer

imajo možnost 24 ur na dan (vsak dan) oddati poljubno število zahtevkov za prevoz.

Obakrat se zahtevki za prevoz oddajajo za naslednji delovni dan (o razlogih za časovne

omejitve pri oddaji nekoliko pozneje), izjemoma pa lahko koordinator prevoza zahtevek

namesto uporabnika vnese v sistem tudi za tekoči delovni dan, če presodi, da gre za

posebne okoliščine (nujni prevoz k zdravniku ipd.). Vsi navedeni podatki, ki jih

koordinator prevoza pridobi prek telefonskega klica in jih v sistem vnaša prek

aplikacije, imenovane PrevoziDDS, ter podatki, ki jih uporabniki prevoza sami vnesejo

prek spletne aplikacije PortalDDS, se shranjujejo v enotno podatkovno bazo, imenovano

'prevozi'. To vsem uporabnikom IS omogoča vpogled v ažurne podatke, ko jih

potrebujejo. Predstavitvi osnovnega koncepta delovanja sedanjega IS sledi podrobnejša

seznanitev z njegovimi tehničnimi značilnostmi in funkcionalnostmi.

2.6 Aplikacija PrevoziDDS in njeni podprogrami

Aplikacija PrevoziDDS je del sedanjega društvenega informacijskega sistema, ki deluje

v okolju Microsoft Windows. Sestavlja jo mnogo podprogramov, ki so namenjeni

posameznim vsebinskim problematikam. Skupaj sestavljajo obširnejšo aplikacijo

PrevoziDDS, namenjeno različnim vrstam uporabnikov (Slika 9): predvsem

organizatorju prevoza, poleg sistemskega administratorja pa še analitikom in delavcem

Slika 8: Osnovni koncept delovanja sedanjega IS



15

Finančne službe. Osnovni namen aplikacije je elektronsko vodenje vseh podatkov o

prevozih. Aplikacija se je med razvojem in uporabo dopolnjevala, in sicer se

pridobivajo tudi nekateri analitični podatki ter vnašajo finančni podatki, povezani s

prevozi. Ne glede na vsebinsko delitev aplikacije pa lahko povemo, da gre za tako

imenovano WIN32-aplikacijo, ki je tipični predstavnik Application Program Interface

(API), v katerem so združeni ukazi, funkcije in protokoli, ki jih programerji uporabljajo

pri razvoju programske opreme za točno določen operacijski sistem.

Slika 9: Vrste uporabnikov aplikacije PrevoziDDS

Aplikacija PrevoziDDS je razvita v programskem jeziku Visual Basic.NET, zato njene

bistvene komponente temeljijo na ogrodju .NET Framework. Podroben opis ogrodja

.NET Framework presega okvire tega dela, mogoče je vseeno smiselno navesti, da je

aplikacija PrevoziDDS napisana in prevedena tako, da deluje v verzijah .NET

Framework 3.0, 3.5 in 4.0. Kar zadeva podatkovne tokove, pa lahko povemo, da je

aplikacija povezana z glavno podatkovno bazo MySQL verzije 5.0.51a-community-nt,

ki deluje na ločenem strežniku kot samostojna aplikacija (Slika 10). Aplikacija

PrevoziDDS je tako locirana na glavnem društvenem strežniku, ta pa komunicira s

podatkovnim strežnikom. Takšna arhitektura zagotavlja varnost podatkov in

neodvisnost delovanja aplikacije od podatkovnega strežnika. Njena učinkovitost se

pokaže pri nadgradnjah aplikacije, ko je treba posodobiti ustrezne datoteke le na eni

strani strežnika, novo verzijo pa takoj dobijo vsi uporabniki sistema. Res pa je, da je

posodobitve treba opravljati ponoči, ko uporabniki aplikacije ne uporabljajo.



16

Aplikacija PrevoziDDS je bila testirana v različnih verzijah operacijskega sistema

Microsoft Windows, predvsem XP in Windows 7. Minimalne sistemske zahteve za

optimalno delovanje aplikacije PrevoziDDS lahko razdelimo na dva dela, in sicer glede

na strojno in programsko opremo. Oboje predstavljamo v spodnji Tabela 1, pri čemer

naj poudarimo, da gre za optimalne minimalne vrednosti, pri katerih je potekalo tudi

praktično testiranje aplikacije med razvojem.

Slika 10: Arhitektura sedanjega IS

Tabela 1: Minimalne sistemske zahteve za optimalno delovanje aplikacije PrevoziDDS

STROJNA OPREMA PROGRAMSKA OPREMA

Procesor 1,3 GHz OS Microsoft Windows XP

RAM 500 MB MUI1 Slovenski jezik

Trdi disk 200 MB .NET Framework Verzija 3.0

Grafični pomnilnik 256 MB MySQL conn Ver. 5.0.51a-community-

nt

Program za

pošiljanje

elektronske pošte

Microsoft Outlook 2007

Advanced security

for Outlook2

Verzija 1.04.0003

Tabela 2 pa prikazuje strukturo menijev aplikacije PrevoziDDS in torej tudi sestavo

osnovnih posameznih podprogramov. Poudarimo, da se bomo pri obravnavi omejili le

na podprograme, ki so pomembni za razumevanje delovanja celotnega informacijskega

sistema, in tiste, ki so neposredno v središču, ko obravnavamo organizacijo prevozov v

invalidski organizacij. Zaradi preobsežne obravnave se bomo v nadaljevanju izognili 1 MUI – Multilingual User Interface Pack. 2 Program, ki omogoča samodejno pošiljanje elektronske pošte prek odjemalca MS Outlook.



17

opisom podprogramov aplikacije PrevoziDDS, ki vsebinsko niso neposredno povezani s

postopkom izvajanja prevozov ali pa v njem nimajo pomembnejše vloge.

Vsak element menija pomeni dejanski podprogram v aplikaciji, ki obravnava določeno

problematiko. Vsakemu takemu podprogramu pa pripada tudi tako imenovani

uporabniški grafični vmesnik (angl. Graphical User Interface – GUI), ki je osrednja

točka za komunikacijo uporabnika aplikacije z informacijskim sistemom. GUI prikazuje

uporabniku razumljive informacije ter mu omogoča, da prek njega zapisuje podatke v IS

in z njimi manipulira. GUI je sicer sestavljen iz množice gradnikov, s katerimi je

uporabnik v interakciji prek miške in tipkovnice. Vsak gradnik ima definirane dogodke,

v katerih je zapisana programska koda, ki se izvede ob sprožitvi dogodka.

Tabela 2: Zgradba menijev in osnovni podprogrami aplikacije PrevoziDDS

Orodja Možnosti Šifranti

Razpored voznikov Lastno geslo Člani

Razpored vozil Internet dostop članov Vozila

Prevozi2 Uporabnik programa Vozniki

Kratice lokacij

Partnerji

Ko uporabnik na svoji delovni postaji klikne na ikono za zagon aplikacije PrevoziDDS,

se odpre prijavno okno (Slika 11), ki ga pozove, da se identificira v IS z ustreznim

uporabniškim imenom in geslom. Te prijavne podatke mu zagotovi administrator

programa s podprogramom 'Uporabnik programa', ki ga opisujemo v podpoglavju 2.7.

Pomembna informacija, ki jo to okno podaja, je tudi verzija programa. Med pisanjem

tega dela se uporablja verzija reda 2.1.2.7.

Ko uporabnik vnese pravilne prijavne podatke, preide v glavno okno programa, v

katerem se mu glede na dodeljene pravice odprejo različni elementi menijske vrstice.

Podprograme, za katere je vsebinsko zadolžen, lahko tudi odpre. Če dostopa do

posameznih vsebin nima, jih tudi ne more odpreti v meniju.

V nadaljevanju si oglejmo funkcionalnosti posameznih podprogramov.



18

Slika 11: Prijavno okno aplikacije PrevoziDDS

Vir: "GUI aplikacije PrevoziDDS" [PrevoziDDS], b. d.

2.7 Podprogram Uporabnik programa

Podprogram 'Uporabnik programa' združuje osnovne funkcionalnosti, ki jih mora imeti

administrator sistema pri upravljanju uporabnikov aplikacije. Vsebinsko je razdeljen na

tri zavihke oziroma sklope:

• administracija uporabnika;

• pravice menijev in

• statistike opravil uporabnika.

Zavihek 'Administracija uporabnika', prikazan na Slika 12, združuje funkcionalnosti

vnosov novih uporabnikov, pri čemer se poleg osnovnih podatkov določi tudi

uporabniško ime (sistem ga na podlagi imena in priimka predlaga sam) in opredeli, ali

je nov uporabnik administrator programa ali ne (Slika 12, polje 'Je ADMIN'), opredeli

se tudi veljavnost uporabnika (Slika 12, polje 'Veljavnost'). Če je veljavnost enaka 1,

sistem uporabniku dovoli vstop, sicer pa ne. Celoten seznam uporabnikov je prikazan v

tabeli desno od vnosnih polj. Tako je mogoče izvajanje različnih opravil v zvezi z že

vnesenimi uporabniki. Ko z desno miškino tipko kliknemo na uporabnika na seznamu,

se odpre pomožni meni, v katerem lahko izberemo eno izmed treh možnosti: 'Uredi',

'Izbriši', 'Pošlji prijavne podatke sodelavcu na email'.



19

S klikom na 'Uredi' se podatki iz tabele prenesejo v vnosna polja, kjer jih je mogoče

spremeniti. Ukaz 'Izbriši' izbriše uporabnika (oziroma nastavi njegov indeks veljavnosti

na 0), ob kliku na ukaz 'Pošlji prijavne podatke sodelavcu na email' pa se sproži

procedura, ki v uporabnikovem poštnem odjemalcu samodejno ustvari elektronsko

sporočilo z vsemi ključnimi podatki o ustvarjenem računu ter vse te prijavne podatke

pošlje novemu uporabniku po elektronski pošti.

Slika 12: Uporabnik programa: administracija uporabnika


Slika 13 prikazuje drugi sklop, in sicer 'Pravice menijev'. To je drugi zavihek

podprograma, s katerim določamo stopnjo pravic, ki jih ima posamezen uporabnik v

aplikaciji PrevoziDDS. Ta zavihek sestavljajo tri področja, in sicer 'Seznam

uporabnikov', ki prikazuje vse veljavne uporabnike programa, določene v prvem

zavihku, 'Seznam menijev', ki prikazuje vse veljavne menije, in področje 'Seznam

pravic', ki določa, kakšen tip pravice naj velja za označeni meni in uporabnika.

Tip pravice najprej določa, ali uporabnik lahko vidi posamezen menijski element ali ne.

Če ne, je določanje preostalih pravic nesmiselno. Sicer pa se določi še pravico 'lahko

odpre okno'. Če ta ni odkljukana, uporabnik ne more odpreti menijske vrstice, čeprav jo



20

vidi. Tako je seznanjen, da za neko področje dela obstaja ustrezen podprogram, a zanj

nima ustreznih pravic.

Pravica 'lahko vnaša podatke' se nanaša na dovoljenje, ali uporabnik aplikacije lahno

vnaša nove podatke v sistem s podprogramom, ki ga določa tisti menijski element. Če te

pravice nima, ima samo možnost pregledovanja podatkov, ne more jih pa vnašati.

Podobno velja za preostali dve pravici: 'lahko spreminja podatke' in 'lahko briše

podatke'. Spreminjanje podatkov pomeni predvsem možnost, da uporabnik v

posameznem podprogramu v celoti ali delno ureja podatke. Kar zadeva brisanje, pa gre

večinoma za možnost spreminjanja indeksa veljavnosti posameznega zapisa. V praksi to

pomeni, da se zapis zaradi vezanih zapisov oziroma tujih ključev (angl. foreign key) v

drugih podatkovnih tabelah dejansko ne zbriše, ampak se vrednost posebej določenega

atributa nastavi iz 1 v 0, kar se upošteva tudi pri nadaljnjih obdelavah in prikazih

podatkov. Povedano drugače, podatek, ki ga je uporabnik izbrisal, je še vedno v bazi, a

ga sistem pri obravnavi ne upošteva.

Slika 13: Uporabnik programa: pravice menijev




21

Zadnji, tretji zavihek podprograma 'Uporabnik programa' pa je prikazan na Slika 14. Ko

na levi izberemo uporabnika aplikacije, na desni izpiše njegovo statistiko aktivnosti v

aplikaciji. Seznam statistik je urejen datumsko padajoče, zato na vrhu vedno vidimo

sveže podatke o uporabnikovih aktivnostih. Poleg datuma je v statistikah aktivnosti

prikazan še podatek o IP-številki, s katere je uporabnik dostopal do aplikacije, in

opombo, v kateri je podrobno opisano, kateri podprogram je uporabnik odprl in katera

funkcija ali procedura se je s tem sprožila. Ti podatki koristijo administratorju sistema v

postopku razhroščevanja aplikacije.

Slika 14: Uporabnik programa: statistike opravil uporabnika


2.8 Podprogram Internet dostop članov

Ta podprogram (Slika 15) omogoča popoln nadzor administratorja nad člani društva, ki

so tudi uporabniki spretne aplikacije PortalDDS (za podrobno predstavitev glej poglavje

2.18). Vsebinsko je razdeljen na tri področja. Razdelek 'Informacije o članu' prikaže vse

ustrezne podatke o izbranem članu. Uporabnik programa nima možnosti spreminjanja

vseh podatkov o članu (ker to ni namen tega podprograma), ampak le tiste, ki se

vsebinsko nanašajo na članov dostop do spletne aplikacije PortalDDS. Tako lahko

spremeni le članovo elektronsko pošto (pozneje bomo videli, da je to pomemben



22

podatek, ki ga sistem poleg GSM-številke uporablja za komunikacijo s članom), enoto

Službe prevozov, ki ji član pripada, ter uporabniško ime in geslo, ki ju mora član imeti

za uspešno prijavo v spletno aplikacijo. Tukaj ima uporabnik podprograma možnost, da

ponastavi geslo člana, pri čemer sistem sam naključno generira niz naključnih znakov

(kombinacije črk in številk). Poleg tega lahko članu omogoči uporabo portala (gumb

'Omogoči internet dostop'), mu jo onemogoči oziroma zablokira (gumb 'Blokiraj

internet dostop') ter ponastavi števec napačnih prijav v sistem (gumb 'Resetiraj št.

napačnih'). Če se članu v petih poskusih ne uspe prijaviti v portal, se njegov račun

samodejno zaklene. To je pomemben varnostni element, ki hekerjem onemogoča

samodejno ugotavljanje gesel. Drugo področje je 'Generiraj SQL', ki služi le

administratorju sistema za izvajanje poglobljenih poizvedb v podatkovni bazi. Tretje

področje 'Vse aktivnosti člana' pa prikazuje tabelo prijav in odjav iz portala glede na

časovno komponento in podatke o IP-številki, s katere je član dostopal do portala.

Dodajmo še, da je vsak član pred dodelitvijo uporabniških podatkov seznanjen z

njihovim zbiranjem. Podpisati mora tudi posebno vlogo za pridobitev dostopa do

portala, s čimer privoli, da se tovrstni podatki lahko spremljajo za preučevanje

morebitnih nepooblaščenih vstopov in drugih sistemskih incidentov.

Slika 15: Internet dostop članov




23

2.9 Podprogram Lastno geslo

Funkcionalnost tega podprograma (Slika 16) je standardna in omogoča uporabniku

aplikacije PrevoziDDS, da sam kadarkoli (brez posredovanja administratorja sistema)

spremeni vstopno geslo.

Slika 16: Lastno geslo


2.10 Podprogram Člani

Šifrant člani vsebuje osnovne podatke o članih društva, ki so vključeni v posebni

socialni program prevozov invalidov. Tako kot večina šifrantov je tudi ta namenjen le

administratorju sistema, ki ima polni dostop do teh podatkov. GUI tega šifranta

prikazuje Slika 17. Vidimo, da je GUI razdeljen na dva dela. Prvi vsebuje vsa polja,

potrebna za vnos novega člana, drugi pa vsebuje seznam članov, ki so shranjeni v bazi.

Mogoč je tudi prikaz članov glede na prvo črko priimka. Pri vnosu novega člana so s

krepkim tiskom označena polja, ki so obvezna pri vnosu. Vnosno polje 'Veljavnost'

prikazuje, ali je posamezna oseba vsebovana v šifrantu ali ne (operacija brisanja), polje

'Član DDS' pa določa, ali je oseba član društva ali ne. Uporabniki prevozov so namreč

izjemoma lahko tudi osebe, ki niso člani društva, kljub vsemu pa so invalidi in mora

društvo zanje organizirati nujen prevoz. Omenimo še, da so tudi v tem šifrantu mogoče

standardne operacije urejanja in brisanja zapisov.



24

Slika 17: Šifrant – člani


2.11 Podprogram Vozila

Ta šifrant vsebuje vse informacije o vozilih, ki jih društvo uporablja pri izvajanju

prevozov (Slika 18). 'Znamka', 'Model', 'Oznaka GPS', 'Vrsta goriva', 'Krajevno

lastništvo' in 'Veljavnost' so obvezna vnosna polja. Omenimo še pomembne podatke, ki

jih bomo pri posodobitvi sedanjega IS še potrebovali, to so podatki, koliko sedežev ima

vozilo, koliko invalidskih vozičkov in koliko skuterjev sprejme prazno vozilo. Pri

oznaki GPS je navedeno, kakšno oznako GPS ima posamezno vozilo. Ta podatek je

pomemben tudi pri povezovanju tega IS s sistemi, ki priskrbijo podatke o opravljenih

vožnjah. Krajevno lastništvo pa pove, kateri krajevni izpostavi pripada vozilo. Društvo

ima za zdaj tri izpostave v Sloveniji, kjer so locirana vozila.



25

Slika 18: Šifrant – vozila


2.12 Podprogram Vozniki

Slika 19 prikazuje preprost šifrant voznikov, ki vozijo vozila, predstavljena v šifrantu

vozil. Vsebuje osnovne podatke o vozniku z njegovo kontaktno GSM-številko. Tudi ta

šifrant omogoča osnovne operacije za delo z zapisi, kot sta urejanje in brisanje.

Slika 19: Šifrant – vozniki




26

2.13 Podprogram Kratice lokacij

Kratice lokacij (Slika 20) so šifrant, s katerim organizator prevozov določi kratice, s

katerimi želi opisati dolgi naziv kraja prihoda ali odhoda. To sta pomembna podatka pri

vnosu zahtevka za prevoz v sistem. Kratice torej le kratko opišejo dolgi naziv, na primer

UKC za Univerzitetni klinični center in podobno.

Slika 20: Šifrant – kratice lokacij


2.14 Podprogram Partnerji

Slika 21 prikazuje GUI šifranta partnerjev. To so poslovni partnerji, ki sodelujejo v

procesu izvajanja prevozov. To so predvsem dobavitelji goriva, avtohiše, ki izvajajo

servisne posege na vozilih, in podobno. Te partnerje uporabljamo pri vnosu računov v

sistem, ki se nanašajo na potrošni material in storitve za vozila. Vsa vnosna polja tega

šifranta so pri vnosu obvezna, z izjemo vnosnega polja 'Kontakt'. Tudi ta šifrant vsebuje

vse osnovne operacije za delo z zapisi, kot sta njihovo urejanje in brisanje. Omenimo

tudi, da se pri vpisu poštne številke samodejno izpiše kraj, ki je povezan s to številko.



27

Slika 21: Šifrant – partnerji


2.15 Podprogram Razpored voznikov

Razpored voznikov je podprogram, s katerim organizator prevozov opredeli termin

(izmeno) dela za posameznega voznika (Slika 22). Mogočih je več terminov dela, ki so

opredeljeni v glavnem šifrantu (glej šifrant v prilogah). Termin dela se določa za ves

teden vnaprej po dogovoru z vozniki in z upoštevanjem splošnega internega pravila

rotacije voznikov. To pravilo določa, da morajo vozniki izmenično delati en teden

dopoldan, drugi teden pa popoldan. Seveda pa zaradi narave dela in odpovedi zaradi

bolniških odsotnosti to pravilo ni nujno vedno upoštevano. Organizator prevozov se

tako odloča, kako bodo vozniki delali v prihodnjem tednu, glede na podatke o terminu

dela voznika v tekočem tednu in potrebah po vožnjah za prihodnji teden. Razpored

voznikov se tako določa vsak petek za ves prihodnji teden (od ponedeljka do petka). Če

je petek dela prosti dan, se razporejanje voznikov opravi pred praznikom. Sam proces

razporejanja voznikov je tak, da organizator prevozov najprej označi teden v mesecu,

izbere voznika in določi termine dela voznika za vsak dan posebej, od ponedeljka do

nedelje. Lahko pa izkoristi tudi funkcijo enotnega določanja termina dela, ki za ves

teden določi vozniku enotni termin (na primer delo dopoldan), pri čemer pa se

posamezni dnevi še vedno lahko naknadno predefinirajo (na primer delo popoldan).



28

Slika 22: Orodja – razpored voznikov


2.16 Podprogram Razpored vozil

Ko organizator prevozov določi, kdaj in v katerem terminu vozniki delajo (glej poglavje

2.15), lahko nadaljuje razporejanje vozil (Slika 23). To je postopek, v katerem se določi,

katero vozilo je dodeljeno posameznemu vozniku za posamezen datum. Najprej se

označi vozilo, potem se določi datum, za katerega želimo razporediti vozilo. Nato

uporabnik programa klikne na gumb 'najdi voznike za ta datum', kjer se na seznamu

prikažejo le vozniki, ki na izbrani datum delajo oziroma so razporejeni na delo. Ko je

vozilo dodeljeno vozniku, se ti podatki izpišejo na seznamu razporedov vozil.

Določanje razporedov vozil je pomembno tudi z vidika izdaje ustreznega potnega

naloga, ki se tudi izvede v tem podprogramu (področje 'Vnos novega potnega naloga').

Tu se določijo vse pomembne karakteristike za izdelavo potnega naloga. Enega

natisnemo vozniku za ves teden, a le če isti voznik vozi isto vozilo ves teden. Sicer je

treba natisniti ustrezno število nalogov. Vsak nalog se natisne v dveh izvodih na enem

listu formata A4, pri čemer en izvod dobi voznik, drugi pa gre v arhiv. Primer potnega

naloga, ki se ustvari s tem podprogramom, dodajamo v prilogi. Organizator prevozov

voznikov izvod tudi podpiše in ožigosa.



29

Slika 23: Orodja – razpored vozil (s potnim nalogom)


2.17 Podprogram Prevozi2

Osrednji podprogram aplikacije PrevoziDDS je podprogram, imenovan Prevozi2.

Število 2 pomeni, da je ta podprogram naslednik verzije 1, ki je v tem delu ne bomo

opisovali, je pa bolj izpopolnjena in funkcionalno bogatejša. Ko organizator prevoza

določi voznike (glej poglavje 2.12) in vozila, ki jih vozniki za določen datum upravljajo

(glej poglavje 2.11), sledi nekaj najpomembnejših postopkov v procesu organiziranja

prevozov. V tem poglavju se bomo zato osredotočili na razlago postopkov in

funkcionalnosti podprograma Prevozi2, ko organizator prevoza vnaša nove zahtevke za

prevoz v IS, ureja podatke o samih ZZP in izvaja operacije razporejanja ZZP.

Preden se posvetimo podrobnejši razlagi funkcionalnosti osrednjega podprograma

Prevozi2, povejmo, da je njegov GUI razdeljen na šest področij (Slika 24), in sicer:

Vnos novega ZZP, Seznam shranjenih ZZP – glavni seznam, Listek A, Listek B, Listek

C in Listek D. Nove ZZP organizator prevoza shrani v področju 'Vnos novega ZZP'.

Podatki, vneseni v vnosna polja tega področja, se v obliki vrstičnega seznama prikažejo

na 'Seznamu shranjenih ZZP', ki ga v nadaljevanju pogosto imenujemo tudi 'glavni

seznam'. V spodnjem delu GUI pa so od leve proti desni pozicionirani listki A do D. To

je dejanski seznam ZZP, ki jih mora voznik z določenim vozilom opraviti.



30

LISTEK A LISTEK B LISTEK C LISTEK D

SEZNAM SHRANJENIH ZZP – GLAVNI SEZNAM

VNOS NOVEGA ZZP

Slika 24: Shematski prikaz področij GUI podprograma Prevozi2



31

Slika 25: Orodja – Prevozi2




32

2.17.1 Vnos novega ZZP

O fazi vnosa novih zahtevkov za prevoz govorimo, ko se vnašajo novi zahtevki za

prevoz v IS. Vnos lahko izvedeta:

• organizator prevoza prek aplikacije PrevoziDDS (s podprogramom Prevozi2) in

• uporabnik prevozov, ki je član društva (invalid), prek interneta (z uporabo spletne

aplikacije PortalDDS; to opisujemo v poglavju 2.18).

Organizator prevoza vnaša podatke, ko uporabnik prevozov (invalid) nima dostopa do

interneta in organizatorja prevoza pokliče po telefonu. Na podlagi telefonskega

pogovora organizator prevoza izlušči ključne podatke, ki določajo zahtevek za prevoz

(ZZP):

• priimek in ime člana društva, ki potrebuje prevoz;

• datum odhoda;

• uro odhoda;

• kraj3 odhoda;

• kraj prihoda;

• namen prevoza;

• opombo.

Podatke o zahtevku za prevoz organizator prevoza vpiše v sistem s podprogramom

Prevozi2 (Slika 25), in sicer v področje 'Vnos novega zahtevka za vožnjo'. Priimek in

ime člana društva najde v šifrantu članov. Datum in uro odhoda izbere s spustnih

menijev. Poudarimo, da je ura odhoda določena s fiksnim časovnim intervalom 15

minut. Tega intervala glede na že razviti IS ni mogoče spreminjati. Kraj odhoda in kraj

prihoda lahko organizator prevoza vpiše z uporabo tipkovnice, uporabi pa lahko spustni

meni, v katerem so shranjene kratice lokacij (glej poglavje 2.13), ali pa uporabi enega

izmed prednastavljenih ukaznih gumbov 1 do 4. Ob kliku na gumb se ena izmed štirih

najpogosteje uporabljenih kratic zapiše v ustrezno vnosno polje kraja odhoda ali kraja

prihoda. Namen prevoza je podatek iz glavnega šifranta, ki opredeljuje namene

3 Kraj prihoda in odhoda je v GUI imenovan kot mesto prihoda in odhoda.



33

prevozov. V opombo pa se zapiše dodatna obrazložitev glede izvedbe samega prevoza.

To sporočilo je namenjeno predvsem organizatorju prevoza in vozniku.

2.17.2 Seznam shranjenih ZZP

Ko organizator prevoza shrani zahtevek za prevoz v področju 'Vnos novega ZZP', se mu

ta pokaže v področju 'Seznam zahtevkov voženj', če je datum prikaza isti datumu

odhoda zahtevka za prevoz. Ta seznam kaže ključne podatke o ZZP, ki jih OP potrebuje

za uspešno nadaljnjo obdelavo in odločanje. Seznam se osvežuje vsakih pet minut, saj

se na istem seznamu prikazujejo tudi zahtevki, ki jih uporabniki prevozov oddajo prek

interneta z uporabo spletne aplikacije PortalDDS (glej poglavje 2.18), zato je

osveževanje nujno.

To področje tudi vizualno prikazuje, ali je na glavnem seznamu še kaj nepregledanih

ZZP. Če jih ni, se na vrhu seznama izpiše zelena oznaka 'OK', sicer pa rdeč znak '!'. Ta

znaka OP bolj nazorno prikazujeta situacijo ob vnovičnem samodejnem osveževanju

seznama, ko je uporabnik prevozov v sistem prek spleta vnesel nov ZZP ali pa ga je

preklical. Desno od te oznake se izpisujejo številčni podatki o številu oddanih ZZP prek

Službe prevozov (v IS jih je vpisal OP), o številu oddanih ZZP prek interneta (v IS jih

vpiše uporabnik prevoza), njunem seštevku in o številu nepregledanih ZZP. Vsi ti

številčni podatki se nanašajo na število ZZP na prikazanem seznamu, ki je opredeljen z

datumom, ko naj bi se ZZP tudi opravil.

Sledi segment za odpiranje listkov ABCD. Tu organizator prevozov najprej izbere

oznako tabele (ta je lahko A, B, C ali D). Nato se samodejno napolni roletni meni s

podatki o voznikih, ki so za datum, kot ga določa datum za pregled glavnega seznama,

prisotni na delovnem mestu in na voljo za delo (ti vozniki so v IS določeni s

podprogramom Razpored voznikov, ki ga opisujemo v poglavju 2.15). Ko OP v tem

roletnem meniju izbere želenega voznika, se samodejno napolni še drugi roletni meni z

vozili, ki so za ta datum dodeljena v prvem meniju izbranemu vozniku (ta vozila so v IS

določena s podprogramom Razpored vozil, ki ga opisujemo v poglavju 2.16). S tem je

enolično mogoče dobiti tudi termin, v katerem izbrani voznik dela, zato se ta podatek

kot dodatna informacija OP tudi izpiše. Če je izbranemu vozniku v istem datumu



34

določeno le eno vozilo, se listek ABCD odpre samodejno, sicer pa je v drugem roletnem

meniju treba izbrati še ustrezno vozilo.

Področje 'Seznam zahtevkov voženj' na koncu vsebuje še vnosno polje, ki omogoča

hitro iskanje ZZP glede na prve črke priimka uporabnika prevozov, ki je zahteval

prevoz. Ta funkcionalnost se je izkazala za uporabno, ko OP išče točno določen ZZP.

Seznam shranjenih ZZP tako prikazuje naslednje podatke:

• uporabnik (priimek in ime uporabnika prevozov, ki je oddal ZZP);

• ura odhoda (čas, ki ga opredeli uporabnik prevozov);

• kraj prihoda (opisni podatek območja ali naslov, ki ga opredeli uporabnik

prevozov);

• kraj odhoda (opisni podatek območja ali naslov, ki ga opredeli uporabnik

prevozov);

• status (status ZZP, ki se spreminja – glej poglavje 2.17.4);

• voznik (priimek in ime voznika, ki bo vožnjo opravil);

• vozilo (oznaka vozila, sestavljena iz GPS-oznake, znamke in modela vozila);

• GSM in tel (kontaktni podatki uporabnika prevozov, da ga voznik lahko pokliče ob

morebitni zamudi);

• čas oddaje (čas, ko je bil ZZP oddan v sistem);

• namen prevoza (šifrant, ki opredeljuje namen prevoza);

• opomba (dodatno polje, v katerem uporabnik prevozov ali OP vozniku posredujeta

dodatno informacijo o ZZP).

Ko na glavnem seznamu označimo en ZZP in kliknemo desno miškino tipko, se odpre

pomožni meni, kot prikazuje Slika 26. Prvi element menija je 'Hitro odpiranje listka

ABCD'. To je funkcija, ki odpre prvi prosti listek ABCD s seznamom ZZP, ki so

dodeljeni vozilu in vozniku za termin, določen z označenim ZZP na glavnem seznamu.

Drugi element menija je 'Razporedi na', ki ponuja možnost, da na glavnem seznamu

označeni ZZP razporedimo na listek A, B, C ali D. OP lahko v glavnem meniju označi

in na želeni listek ABCD prestavi le en ZZP naenkrat, saj je treba vsak ZZP obravnavati

individualno in ga po tehtnem razmisleku razporediti na ustrezen listek ABCD. V

meniju sledi tretji element 'Uredi zahtevek za prevoz', s katerim OP lahko spremeni

ključne podatke ZZP. Sledi 'Kopiranje zahtevkov za prevoz…', ki omogoča odprtje



35

posebnega podprograma za enostavno in hitro kopiranje ZZP (tega ne opisujemo

posebej). Sledi 'Trajno izbriši označen zahtevek', ki omogoča brisanje ZZP iz baze. Gre

za možnost, ki jo ima le administrator programa in je omogočena le za testne namene.

'Prekliči zahtevek za prevoz' je predzadnji element menija, s katerim OP prekliče že

shranjeni ZZP. Zadnji element 'Preveri SMS-status' omogoča OP, da preveri, ali je bil

SMS z obvestilom odposlan uporabniku prevozov (glej poglavje 2.17.5).

Slika 26: Elementi pomožnega menija za operacije na glavnem seznamu ZZP


2.17.3 Listek ABCD

Kot lahko že sklepamo iz imena, gre za štiri sezname (tako imenovane listke), od

katerih vsak vsebuje informacije o vozilu in vozniku ter, kar je najpomembneje, o ZZP,

ki pripadajo določenemu vozniku in vozilu. En ZZP je lahko le na enem izmed listkov

ABCD. Ko OP razporedi ZZP na enega izmed teh listkov, razporeja zahtevke. Pri tem

ZZP z glavnega seznama (področje 'Seznam zahtevkov voženj', Slika 24) razporedi na

enega izmed listkov ABCD in tako dejansko določi, kdaj mora voznik opraviti vožnjo in

kakšna naj bo.

ZZP je mogoče tudi premikati med listki z ukaznima gumboma '<' in '>'. Ta

funkcionalnost je uporabna predvsem, ko:

• voznik s terena sporoči OP, da posameznega prevoza ne bo utegnil opraviti zaradi

zastojev na cesti ali drugih kritičnih dogodkov, ali

• ko OP v fazi razporejanja ZZP išče najbolj optimalno možnost za izvedbo vožnje.



36

Premikanje med listki pa ni edina možnost. ZZP je mogoče premikati tudi na samem

listku. To je uporabno predvsem, ko ima voznik na seznamu več ZZP različnih

uporabnikov za prevoz z istim časom odhoda.

Ko je OP zadovoljen z razporeditvijo ZZP na listku, ima možnost potrditi vse ZZP

naenkrat s pritiskom na ukazni gumb 'Potrdi vse', lahko pa potrdi le označene ZZP. To

je uporabno, ko je OP prepričan, da posameznih ZZP ne bo več prestavljal k drugemu

vozniku na drug listek, medtem ko neodločene ZZP lahko pusti še nepotrjene. Vsekakor

pa velja, da je treba vse ZZP na listku potrditi, sicer listka ni mogoče natisniti. Natisnjen

listek pa je dejansko navodilo vozniku in seznam voženj, ki jih mora opraviti. Primer

natisnjenega listka je na Slika 27, vsebuje pa podatek o:

• uri predvidenega časa odhoda;

• uporabniku (priimek, ime, GSM in telefon uporabnika prevozov);

• kraju prihoda;

• kraju odhoda;

• opombo (izpiše se le, če obstaja).

Slika 27: Natisnjen listek ABCD

Vir: "Tiskan izvod listka ABCD" [PrevoziDDS], b. d.

2.17.4 Spreminjanje statusov ZZP

Shranjeni zahtevek za prevoz ima v življenjskem ciklu tudi različne statuse, prek katerih

se spremlja stanje in dogajanje o zahtevku. Glede na splošni šifrant poznamo naslednje

statuse zahtevka za prevoz:

• čaka na potrditev;



37

• podatki so bili spremenjeni (to je storila Služba prevozov) – prevoz čaka na

potrditev;

• v fazi razporejanja;

• potrjen v celoti;

• preklicala Služba prevozov;

• preklical uporabnik.

Vsak ZZP, ki se shrani v sistem, takoj dobi status 'čaka na potrditev'. To pomeni, da je

zahtevek uspešno shranjen v sistemu in čaka, da ga organizator prevozov potrdi.

Potrjevanje zahtevkov je faza, v kateri OP določi, kateri ZZP sodi k določenemu

vozniku. Povedano drugače, OP določi, katerega uporabnika prevozov (invalida) točno

določen voznik odpelje s točke 'mesto odhoda' na točko 'mesto prihoda', in to v času, ki

je določen v ZZP. S tem postopkom (dodeljevanje ZZP točno določenemu vozniku in s

tem tudi vozilu) OP razporeja zahtevke za prevoz. To naredi tako, da najprej odpre

enega izmed tako imenovanih listkov A, B, C ali D (v nadaljevanju ABCD). Ko se ZZP

razporedi na enega izmed listkov ABCD, se zahtevku spremeni status iz 'čaka na

potrditev' v 'v fazi razporejanja'. Poudarimo, da se je ZZP v tem primeru navidezno

kopiral z glavnega seznama v področju 'Seznam zahtevkov voženj' na enega izmed

listkov ABCD (listek si določi OP), zato je viden tako na listku ABCD kot na glavnem

seznamu. Če uporabnik prevoza med statusom ZZP 'v fazi razporejanja' organizatorju

prevoza sporoči, da vožnjo preklicuje, OP preprosto označi ta ZZP na listku ABCD in

ga prekliče (razen preklica drugo spreminjanje statusov ZZP na glavnem seznamu ni

mogoče, dokler je ta na listku ABCD). Ob preklicu sta mogoči dve situaciji, in sicer:

ZZP, ki ga OP preklicuje:

• je potrjen (ima status 'potrjen v celoti') ali

• ni potrjen (ima status 'v fazi razporejanja').

Če je ZZP potrjen, dobi ob preklicu (preklic na listku ABCD) status 'preklican s strani

Službe prevozov'. Tako se ZZP tudi odstrani z listka ABCD. Če pa ZZP ni potrjen, ob

preklicu (preklic na listku ABCD ali na glavnem seznamu) spet dobi status 'čaka na

potrditev'.



38

Vrnimo se na situacijo, ko je ZZP že razporejen na enega izmed listkov ABCD in ima

status 'v fazi razporejanja'. Povedali smo že, kaj se s statusom ZZP dogodi ob preklicu

takega prevoza. Sedaj pa si poglejmo, kaj se zgodi ob potrditvi. Ko je ZZP na listku

ABCD v fazi razporejanja (ima status 'v fazi razporejanja') in ko organizator prevoza

intuitivno oceni, da bo vožnjo mogoče tudi opraviti, lahko ZZP potrdi. S tem izrazi

strinjanje, da se vožnja s podatki, kot jih določa ZZP, lahko opravi. ZZP tako dobi status

'potrjen v celoti'. Od tu je mogoče ZZP le še preklicati, s čimer spremenimo status ZZP

iz 'potrjen v celoti' v 'preklican s strani Službe prevozov'. Da lahko vozniku natisnemo

listek ABCD, morajo biti vsi ZZP na njem potrjeni. OP tako vsak konec delovnika z

listkov ABCD natisne seznam voženj za vsakega voznika posebej.

Seveda pa se zgodi, da oddani ZZP ne more biti vedno opravljen v času, ki ga kot željo

izrazijo uporabniki prevozov (premalo prostih zmogljivosti, okvara vozila, nenadna

bolniška odsotnost voznika ipd.), mogoča pa je izvedba te vožnje ob drugem času. OP

navadno to oceni, še preden sploh razporedi ZZP. Takrat mora spremeniti podatke

zahtevka za prevoz (navadno gre le za spremembo ure odhoda, spremeni pa lahko tudi

druge podatke, z izjemo priimka in imena člana). Ko spremenjeni ZZP shrani, ta dobi

status 'podatki so bili spremenjeni (s strani Službe prevozov) – prevoz čaka na

potrditev'. Zatem pa je ta ZZP spet mogoče ali razporediti na enega izmed listkov

ABCD ali pa ga preklicati. Lahko pa se seveda tudi zgodi, da uporabnik prevoza sam po

telefonu obvesti OP, da odpoveduje vožnjo. V tem primeru ZZP dobi status 'preklican s

strani uporabnika'.

Vse opisane možnosti prehajanja statusov ZZP grafično prikazuje tudi Slika 28.



39

Oddaja

ZZP

ČAKA NA

POTRDITEV

ID=1

Razporeditev

na A,B C, D

Sprememba

podatkov

Preklic

ZZP

V FAZI

RAZPOREJANJA

ID=27

Potrditev

prevoza

PREKLICAN S

STRANI SP

ID=3

Preklic

POTRJEN V

CELOTI

ID=5

Preklic POTRJEN?

DA

NE ID=2 ali 5

podatki so bili spremenjeni

(s strani Službe prevozov),

prevoz čaka na potrditev

ID=20

PREKLICAN S

STRANI SP

ID=3

Shrani

D.klik-

razporedi

D.klik-

Uredi ZZP

D.klik-

prekliči •Gumb

POTRDI

VSE

•D.klik-

POTRDI

OZNAČENE

ZZP

D.klik-

prekliči

Slika 28: Možnosti prehajanja statusov ZZP



40

2.17.5 Obveščanje uporabnikov prevozov o spremembah statusov ZZP

Izjemno pomembno je, da so uporabniki prevozov sproti in takoj obveščeni o vsaki

spremembi statusa ZZP v njegovi življenjski dobi. Tako so obveščeni, kaj se z njihovim

oddanim ZZP dogaja in, kar je najpomembneje, ali je njihov ZZP potrjen (pomeni, da

bo vožnjo mogoče tudi dejansko opraviti), spremenjen (navadno OP spremeni čas

odhoda) ali preklican (vožnje zaradi objektivnih razlogov ni mogoče opraviti).

Podprogram Prevozi2 tako ponuja naslednje možnosti obveščanja:

• obveščanje prek elektronske pošte;

• obveščanje prek besedilnih sporočil SMS.

Vsekakor pa mora uporabnik prevoza nedvoumno izraziti svojo željo o obliki

obveščanja. To stori z uporabo spletne aplikacije PortalDDS, v kateri je mogoče v

nastavitvah opredeliti želeno obliko obveščanja (glej poglavje 2.18.2). Organizator

prevoza nima niti možnosti niti pooblastila za spreminjanje teh nastavitev pri

posameznem uporabniku prevoza.

Pri obveščanju prek elektronske pošte informacijski sistem sam generira personalizirano

elektronsko sporočilo, ki vsebuje pomembne informacije o ZZP in njegovem statusu. Z

uporabo poštnega odjemalca (v našem primeru Microsoft Outlooka) in podpornega

programa (Advanced Security for Outlook), ki omogoča integracijo podatkov za

kreiranje in samodejno pošiljanje elektronskih sporočil iz Outlooka, podprogram

Prevozi2 pošlje uporabniku prevoza elektronsko sporočilo na naslov, shranjen v

podatkovni bazi. Glede na končni status ZZP uporabnik prevoza lahko prejme naslednja

elektronska sporočila:

• ZZP je v celoti potrjen;

Spoštovani(a) Novak Janja, obveščamo vas, da JE vaš zahtevek za prevoz potrjen. Podatki prevoza so: datum odhoda: 16.02.2012 ura: 13:30 mesto odhoda: FDV mesto prihoda: Verovškova 55



41

PROSIMO, DA STE KARSEDA TOČNI IN ČAKATE NA PREVOZ OB DOGOVORJENEM ČASU IN NA DOGOVORJENEM MESTU. Vse ostale informacije najdete na našem portalu oziroma na naslovu https://www.drustvo-distrofikov.si/portaldds/ Če boste želeli ta prevoz odpovedati, lahko to storite preko portala (če je odpoved dana v predpisanem roku), sicer pa nas o vaši odpovedi OBVEZNO obvestite po telefonu na 01/47-20-559. Lep pozdrav, Miha Kovač Služba prevozov ------------------------------ OPOZORILO: To sporočilo je generirano in poslano avtomatsko. Če ste ga prejeli po pomoti in niste ta oseba, kot je zapisano v sporočilu, nas o tem nemudoma obvestite na [email protected] ter sporočilo takoj izbrišite. PrevoziDDS verzija:2.1.2.3 ------------------------------

• ZZP je potrjen s spremenjenimi podatki;

Spoštovani(a) Novak Janja, obveščamo vas, da smo zaradi optimizacije prevozov vašemu zahtevku za prevoz morali SPREMENITI nekatere podatke ter da je prevoz potrjen s spremenjenimi podatki. Podatki spremenjenega prevoza so: datum odhoda: 16.02.2012 ura: 13:45 mesto odhoda: BTC mesto prihoda: DDS PROSIMO, DA STE KARSEDA TOČNI IN ČAKATE NA PREVOZ OB DOGOVORJENEM ČASU IN NA DOGOVORJENEM MESTU. Vse ostale informacije najdete na našem portalu oziroma na naslovu https://www.drustvo-distrofikov.si/portaldds/ Če boste želeli ta prevoz odpovedati, lahko to storite preko portala (če je odpoved dana v predpisanem roku), sicer pa nas o vaši odpovedi OBVEZNO obvestite po telefonu na 01/47-20-559. Lep pozdrav, Miha Kovač Služba prevozov ------------------------------ OPOZORILO: To sporočilo je generirano in poslano avtomatsko. Če ste ga prejeli po pomoti in niste ta oseba, kot je zapisano v sporočilu, nas o tem nemudoma obvestite na [email protected] ter sporočilo takoj izbrišite. PrevoziDDS verzija:2.1.2.3 ------------------------------



42

• ZZP ni potrjen;

Spoštovani(a) Novak Janja, obveščamo vas, da zaradi optimizacije prevozov vašemu zahtevku za prevoz nismo mogli ugoditi glede na termin, ki ste ga navedli. Podatki prevoza so: datum odhoda: 10.02.2012 ura: 16:30 mesto odhoda: DDS mesto prihoda: Steletova 8 Svetujemo, da pravočasno oddate ponovni zahtevek za prevoz, katerega bo informacijski sistem obravnaval in ga skušal uvrstiti med ostale prevoze. Vse ostale informacije najdete na našem portalu oziroma na naslovu https://www.drustvo-distrofikov.si/portaldds/ Lep pozdrav, Miha Kovač Služba prevozov ------------------------------ OPOZORILO: To sporočilo je generirano in poslano avtomatsko. Če ste ga prejeli po pomoti in niste ta oseba, kot je zapisano v sporočilu, nas o tem nemudoma obvestite na [email protected] ter sporočilo takoj izbrišite. PrevoziDDS verzija:2.1.2.2 ------------------------------

Obveščanje prek besedilnih sporočil SMS pa dopolnjuje zgoraj opisani način

obveščanja prek elektronske pošte. Pri besedilnih sporočilih SMS (angl. Short Message

Service) se uporabnik prevozov o statusu njegovega prevoza obvesti neposredno na

njegov mobilni telefon. Tako prejme informacijo kjerkoli (osnovni pogoj je, da je v

območju GSM-signala), ne da bi mu bilo treba spremljati status ZZP prek spletne

aplikacije PortalDDS. Glede na različne statuse ZZP lahko uporabnik prevoza prejme

naslednja SMS-sporočila:

• ZZP je v celoti potrjen;

Spoštovani, vaš prevoz 20.02.2012 JE potrjen. Odhod ob 16:30 DDS, prihod Jelinčičeva 4. Več info

na PortalDDS ali na 01/4720559. Lp, Miha Kovač



43

• ZZP je potrjen s spremenjenimi podatki;

Spoštovani(a) Novak Janja, vaš prevoz 20.02.2012 JE potrjen s SPREMENJENIMI podatki. Odhod

ob 08:15 Cesta na loko 22 a, prihod Tbilisijska 59. Več info na PortalDDS ali na 01/4720559. Lp,

Miha Kovač

• ZZP ni potrjen;

Spoštovani(a) Novak Janja, vaš prevoz 17.02.2012 NI potrjen. Odhod ob 12:00 Palmejeva 12,

prihod Linhartova 36. Več info na PortalDDS ali na 01/4720559. Lp, Miha Kovač

2.17.6 Koncept in merila razporejanja ter potrjevanja ZZP (operacija človek)

Organizator prevozov med delovniki opoldne pregleda glavni seznam prejetih ZZP in

jih razporedi med listke ABCD. To počne intuitivno in predvsem ob upoštevanju časa

odhoda, navedenega v ZZP, prostih zmogljivosti voznikov in vozil ter prostih

zmogljivosti v vozilu. OP približno pozna in oceni:

• koliko časa bo voznik potreboval, da se pripelje do uporabnika;

• koliko časa bo voznik čakal na uporabnika;

• koliko časa bo porabil za namestitev uporabnika v vozilo ter

• koliko časa bo potreboval za prevoz uporabnika do cilja.

Ocene zgoraj naštetih dejavnikov so odvisne tudi od vremena in s tem povezanih razmer

na cesti. V postopku odločanja, kateri ZZP dodeliti kateremu vozniku (temu rečemo tudi

faza razporejanja ZZP vozniku na listek ABCD), obstaja veliko neznank, na katere

vplivajo različni dejavniki. Vse pa temelji predvsem na izkušnjah OP in rezultatih

voženj, ki so bile v preteklosti izvedene z istimi uporabniki prevozov na istih relacijah.

OP mora med razporejanjem ZZP upoštevati še veliko dejavnikov, ki jih v strnjeni

obliki navajamo spodaj. To so tudi merila, ki jih sistem uporablja za podporo odločanju:

• nekateri vozniki lahko vozijo le nekatera vozila, drugi pa vsa;

• mestne in medkrajevne vožnje morajo biti razporejene izmenično po voznikih

(voznik en dan opravlja mestne, drug dan medkrajevne vožnje);

• za vožnje v tujini so pooblaščeni le nekateri vozniki in vozila ter se morajo

izmenično menjati (število opravljenih voženj v tujini po posameznih pooblaščenih

voznikih mora biti čim bolj enakomerno porazdeljeno, da niso preobremenjeni);



44

• predvidene in nepredvidene odsotnosti voznikov z dela;

• okvare vozil (vnaprej predvideni servisi in nepredvidene okvare);

• nekateri vozniki se ne smejo peljati skupaj v vozilu z nekaterimi uporabniki;

• nekateri uporabniki se ne smejo peljati skupaj v istem vozilu;

• nekateri uporabniki se lahko vozijo le z nekaterimi vozniki;

• nekateri vozniki delajo le v eni izmeni, drugi izmenično dopoldan in popoldan, spet

tretji kadarkoli;

• delovna obveznost voznikov (lahko se razlikuje po posameznih voznikih);

• nekatere vožnje se lahko izvedejo z majhno zamudo, druge pa morajo biti točne

(treba jih je izvesti z nekaj časovne rezerve);

• vožnje se morajo izvajati po najbolj optimalnih poteh, pri čemer se skuša zagotoviti

čim večjo točnost glede časa odhoda, naveden v ZZP.

Iz naštetega je mogoče razbrati, da je mnogokrat nemogoče upoštevati vse navedene

dejavnike, a OP skuša kljub temu razporediti ZZP tako, da se ob upoštevanju navedenih

dejavnikov vožnje tudi čim bolj uspešno in pravočasno izvedejo. S tem so zadovoljni

tako uporabniki prevozov kot vozniki.

2.18 Spletna aplikacija PortalDDS

PortalDDS je tipična spletna aplikacija, namenjena članom Društva distrofikov

Slovenije, ki po načelu spletne banke z društvom komunicirajo 24 ur vsak dan. Je del

društvenega IS in pomeni sodoben paralelni komunikacijski kanal. PortalDDS je

napisan v programskem jeziku ASP.NET. Domuje na ločenem spletnem strežniku (IIS

verzija 6) in podobno kot aplikacija PrevoziDDS deluje v okviru ogrodja .NET

Framework 4. Z vidika mrežne varnosti komunikacija med odjemalcem (brskalnik

uporabnika prevozov) in spletnim strežnikom poteka prek varne povezave z uporabo

protokola https. Povemo lahko, da je spletna aplikacija PortalDDS, podobno kot

aplikacija PrevoziDDS, vsebinsko zgrajena iz več podprogramov, ki uporabnikom

omogočajo uporabo različnih storitev društva. V nadaljevanju se bomo omejili na opis

tistih funkcionalnosti spletne aplikacije, ki obravnavajo prevoze, in aktivnosti, ki so z

njimi vsebinsko povezane.



45

Ko administrator aplikacije PrevoziDDS (na podlagi prejete vloge za pridobitev dostopa

do interneta) v IS omogoči uporabniku prevozov uporabo spletne aplikacije PortalDDS

(glej poglavje 2.18), mu po pošti na dom pošlje osnovna navodila za uporabo portala in

uporabniške prijavne podatke. Uporabnik tako s svojim spletnim brskalnikom obišče

posebno spletno mesto, na katerem se z dodeljenim uporabniškim imenom in geslom v

portal tudi prijavi (Slika 29).

Slika 29: Prijava v PortalDDS

Vir: "GUI spletne aplikacije PortalDDS" [PortalDDS], b. d.

Spletna aplikacija PortalDDS ima naslednjo strukturo:

• glavna stran (Slika 30);

• prevozi (Slika 31):

o pregled ZZP po datumu (Slika 32),

o preklic že oddanega ZZP (Slika 33),

o oddaja novega primarnega ali primarnega in sekundarnega ZZP (Slika 34, Slika

35),

� potrditev podatkov (Slika 36),

• shranjevanje ZZP in obvestilo o uspešnosti shranjevanja;

• nastavitve:

o osebni podatki člana (Slika 38),

o način obveščanja o spremembah prevozov (Slika 39),

o sprememba gesla (Slika 40),

o ukinitev uporabniškega računa;



46

• vaše mnenje;

• razporedi voženj4;

• izhod.

Po uspešni prijavi se uporabniku odpre glavno okno portala (Slika 30), kjer lahko

spreminja svoje uporabniške nastavitve, komunicira z društvom (le v svojem imenu) in

oddaja ZZP. Vsako okno vedno prikazuje ime in priimek v portal prijavljenega

uporabnika (levo zgoraj), sistemski čas (desno zgoraj), ki je pomemben pri časovno

odvisnih funkcijah, in glavni meni (levo pod imenom uporabnika).

Slika 30: Glavno okno portala


Ob kliku na 'Obvestilo' v meniju se prikažejo obvestila, ki jih društvo sporoča

uporabnikom portala. Ta stran je vidna tudi ob prijavi v portal, kot prikazuje Slika 30.

Drugi element menija je imenovan 'Prevozi'. To je osrednji modul portala, ki mu bomo

namenili največ pozornosti in se nanaša na prevoze. Modul omogoča oddajo novih in

4 Dostop do te funkcionalnosti ima le administrator sistema.



47

preklic že shranjenih ZZP. 'Nastavitve' vsebujejo vse podatke, ki jih uporabniki portala

lahko spreminjajo, in s tem prilagodijo delovanje portala svojim potrebam. Omenimo še

elementa menija 'Vaše mnenje' in 'Razporedi voženj', ki ju pozneje ne bomo podrobneje

opisovali. Prvi je namenjen temu, da uporabniki prevozov društvu sporočijo povratno

informacijo, kako so s portalom zadovoljni in katere vsebine še pogrešajo, medtem ko je

drugi element namenjen le administratorju sistema in prikazuje seznam potrjenih ZZP

po voznikih. S klikom na 'Izhod' se uporabnik odjavi iz spletne aplikacije.

2.18.1 Modul Prevozi

Ob kliku na element 'Prevozi' se odpre okno, kot kaže Slika 31. Ta modul omogoča

uporabniku prevozov društva, da prek spleta oddaja ZZP in tudi spremlja, kaj se s

statusi njegovih zahtevkov dogaja. V procesu razporejanja ZZP spreminja njihove

statuse organizator prevozov (glej poglavje 2.17.4). V zgornjem delu odprtega okna so

na kratko zapisana navodila, kako uporabljati to okno. Spodaj pa uporabnik v koledarju

najprej izbere datum, za katerega želi pregledati seznam že oddanih ZZP. Obenem se

mu odpre možnost za vnos novega ZZP, ki ga lahko odda. Ta funkcionalnost

uporabniku prevozov omogoča, da lahko kadarkoli (24 ur na dan) odda svoj ZZP brez

neposrednega stika z OP.



48

Slika 31: Modul Prevozi – osnovno


Po izbiri datuma dobi uporabnik pregled nad vsemi že oddanimi ZZP za izbrani datum.

Poudariti moramo, da se na seznamu vidijo zahtevki, ki jih je uporabnik oddal po

telefonu v Službo prevozov, in zahtevki, ki jih je oddal prek portala PortalDDS. Slika

32 kaže seznam, na katerem so prikazani vsi pomembni podatki ZZP in ustrezne

možnosti, ki jih lahko uporabnik izvede pri posameznem zahtevku. Pri tem ima na voljo

dve dejanji; prvo je povezava 'Prekliči', ki omogoča uporabniku, da ZZP prekliče, in

drugo, ki se pokaže zgolj kot obvestilo, da ZZP ni mogoče več preklicati. V skladu z

veljavnimi internimi pravili društva je mogoče že oddan ZZP prek spleta preklicati 24

ur pred izvedbo. Če želi uporabnik preklicati ZZP po tem terminu, se mu pokaže

obvestilo (namesto povezave 'Prekliči'), da mora za preklic poklicati OP po telefonu in

ga o tem tudi obvestiti. Če uporabnik klikne na povezavo 'Prekliči', je preusmerjen na

stran, na kateri lahko še enkrat preveri podatke o ZZP in se dokončno odloči, ali želi

ZZP res preklicati (Slika 33). Ob preklicu se status ZZP takoj spremeni v 'preklican s



49

strani uporabnika'. To OP v aplikaciji zazna kot spremembo (prikaz znaka '!') in mu

sporoča, da so v ZZP vnesene spremembe. Uporabnik je o uspešnem preklicu obveščen

z obvestilom na zaslonu.

Slika 32: Modul Prevozi – datum izbran




50

Slika 33: Modul Prevozi – preklic ZZP


Poleg dejanj na že obstoječih (shranjenih) ZZP modul Prevozi omogoča tudi oddajo

novih. To uporabnik stori s klikom na povezavo 'ODDAJ ZAHTEVEK ZA PREVOZ',

ki je na dnu zaslona (Slika 32). Pri tem se odpre okno, prikazano na Slika 34, v katero

uporabnik vnese primarni prevoz. To je prevoz z lokacije A na lokacijo B, medtem ko je

povratni (sekundarni) praviloma prevoz z lokacije B nazaj na lokacijo A. Vidimo, da je

enota Službe prevozov vnaprej določena, saj v tej verziji IS ni mogoče oddajati ZZP za

druge enote Službe prevozov. Datum odhoda ostaja fiksen in ga ni mogoče spreminjati,

saj ga je uporabnik prevoza določil ob odprtju modula prevozi, ko je izbiral datum za

pregled že shranjenih ZZP. Tako uporabnik vnese le še preostale podatke, ki

opredeljujejo ZZP (glej poglavje 2.17.1); ima namreč možnost, da vnese še povratni

(sekundarni) prevoz (klik na gumb 'Istočasno želim oddati tudi povratni prevoz') – v tem

primeru se mu odprejo dodatna, ustrezno predizpolnjena polja – ali pa nadaljuje

shranjevanje. Za podrobnejši opis glej diagram poteka, ki ga prikazuje Slika 37. S

klikom na povezavo 'Naprej >' uporabnik preide na stran, na kateri še enkrat preveri vse

podatke in če so pravilni, jih tudi shrani (Slika 36). Ko so podatki shranjeni, dobi o tem



51

ustrezno obvestilo. Tako je oddal ZZP prek spleta z uporabo spletne aplikacije

PortalDDS.

Ker je proces shranjevanja novega ZZP nekoliko zahtevnejši (Slika 37), ga opisujemo

podrobneje. V prvi fazi tako uporabnik prevozov najprej izbere datum pregleda, pri

čemer se na seznamu prikažejo vsi za tisti dan določeni ZZP. Postopek njihovega

preklica smo opisali zgoraj. Sedaj opišimo še postopek oddaje novega ZZP.

Uporabnik prevoza najprej vnese podatke za primarni ZZP, kot prikazuje Slika 34.

Obvezen je vnos vseh podatkov razen opombe. Če želi oddati še sekundarni ZZP, lahko

to stori v istem pogovornem oknu s pritiskom na tipko 'Istočasno želim oddati tudi

povratni prevoz'. Če oddaja le primarnega, se sproži 'preverjanje vnosov 1', pri čemer se

preverijo naslednji dejavniki:

• ali so izpolnjena vsa zahtevana vnosna polja;

• ali dolžine nizov vnosnih polj ustrezajo definiciji podatkovnega tipa in dolžini

njenega niza;

• ali je bil ZZP oddan dovolj zgodaj (ZZP mora biti glede na interna pravila društva

oddan najmanj 24 ur pred izvedbo) in

• ob istem datumu in uri odhoda v sistemu še ne obstaja noben ZZP tega uporabnika

(v istem časovnem intervalu lahko uporabnik prevoza odda le en ZZP).

Če na vsa zgornja štiri vprašanja sistem odgovori pritrdilno, preide na stran ponovne

potrditve podatkov vnesenega ZZP, sicer pa nazaj na vnos podatkov za

primarni/sekundarni ZZP. Če uporabnik ugotovi, da vneseni podatki niso pravilni (da se

je pri vnosu zmotil), klikne na povezavo 'Nazaj' in spet preide na stran za vnos podatkov

za primarni/sekundarni ZZP, kjer lahko podatke spremeni. Če so vneseni podatki

pravilni, pa nadaljuje s klikom na povezavo 'Shrani', kjer se preveri, ali je ZZP oddan v

dovoljenem terminu oddaje. Pri preverjanju, ali se ZZP lahko shrani v sistem glede na

čas, se upoštevajo naslednja pravila:

• če je petek in uporabnik prevoza oddaja ZZP za:

o soboto, sistem ne dovoli oddaje ZZP;

o nedeljo, sistem prav tako ne dovoli oddaje ZZP;



52

o ponedeljek, sistem še preveri uro odhoda želenega ZZP in ne dovoli oddaje

ZZP, če je ura odhoda ZZP manjša ali enaka 12:00.

Povedano drugače, če uporabnik prevoza oddaja ZZP v petek in želi, da bi bila vožnja

opravljena v soboto ali nedeljo, sistem oddaje takega zahtevka ne dovoli, saj Služba

prevozov med vikendi praviloma ne deluje. Če uporabnik prevoza odda ZZP v petek in

želi, da bi bila njegova vožnja opravljena v ponedeljek dopoldan pred 12. uro, sistem

prepreči oddajo takega ZZP in uporabnika prevoza obvesti, da skuša oddati zahtevek

zunaj dovoljenega časa oddaje. Če pa želi, da bi bila njegova vožnja opravljena v

ponedeljek po 12. uri, sistem dovoli oddajo takega zahtevka. Navedene omejitve so

uvedene, ker OP razporeja v sistem prispele ZZP do trenutka razporejanja (to je

navadno vsak delovnik okrog 12. ure). Zato mora sistem omejiti vnos ZZP, ki so oddani

vsak petek po 12. uri za prihajajočo soboto, nedeljo in ponedeljek, saj OP po 12. uri v

petek ne razporeja več ZZP in bi tako brez navedene časovne omejitve oddaje lahko

uporabnik prevozov oddal ZZP čez vikend za ponedeljek dopoldan, kar pa ne bi bilo

razporejeno na ustrezne listke ABCD. Če sistem ugotovi, da so izpolnjeni vsi pogoji, ki

ustrezajo dovoljenemu času oddaje ZZP, se ta shrani v podatkovno bazo in uporabnika

obvesti o uspešni oddaji ZZP. V nasprotnem primeru pa uporabnika prevoza obvesti, da

ZZP ni mogoče oddati zaradi časovnih omejitev. Uporabnik prevozov ima potem

možnost, da se vrne in ustrezno popravi podatke v zahtevku za prevoz.

Vrnimo se na stanje, ko se uporabnik prevozov odloči, da bo poleg primarnega oddal

tudi sekundarni ZZP. Takrat se sproži 'preverjanje vnosov 2', pri katerem se preveri isto

stanje pravilnosti vnosov podatkov kot pri primarnem ZZP, le da se tokrat preverjajo

vnosi za dva ZZP. Če na katerem od oddanih ZZP niso pravilni, se uporabnik vrne na

stran za vnos podatkov za primarni/sekundarni ZZP, sicer pa preide na ponovno

potrditev podatkov, kjer se s klikom na povezavo 'Nazaj' vrne na stran za vnos podatkov

za primarni/sekundarni ZZP. S klikom na povezavo 'Shrani' pa preide v fazo

ugotavljanja dovoljenega časa oddaje ZZP (primarni in sekundarni), pri čemer se

podobno kot pri primarnem ZZP ugotovi, ali se zahtevka za prevoz lahko shranita v

sistem za prevoz glede na časovne omejitve. Uporabnik je tudi ustrezno obveščen o tem

s sporočilom na zaslonu.



53

Slika 34: Modul Prevozi – primarni prevoz




54

Slika 35: Modul Prevozi – sekundarni prevoz


Slika 36: Modul Prevozi – potrditev pravilnosti podatkov




55

Slika 37: Modul Prevozi – diagram poteka shranjevanja ZZP

(*)

-vsa polja so polna,

-dolžine nizov OK,

-dovolj zgodnja oddaja ZZP,

-še ne obstaja ZZP ob istem času

(**)

Isto kot (*), le da preverja za 2 ZZP

(***) Preveri, ali lahko odda ZZP glede na čas:

-če je PET in oddaja za

-SOB�ne pusti

-NED�ne pusti

-PON�če je zdaj<12:00�OK pusti oddati ZZP,

sicer ne pusti.

-če je SOB in oddaja za

-NED�ne pusti

-PON�ne pusti

-če je NED in oddaja za

-PON�ne pusti. PRIMARNI

ZZP?

DA

NE

PREVERJANJE VNOSOV 1

(primarni ZZP)

VNOSI

PRAVILNI?*

NE

DA KLIK NA

'SHRANI'?

NE DOVOLJEN

ČAS ODAJE

ZZP?***

DA

NE

Obvestilo, da ZZP ni

mogoče oddati zaradi

časovnih omejitev.

Izbira datuma

pregleda/oddaje ZZP

Ponovna potrditev

podatkov vnesenega ZZP

Vnos podatkov za

primarni/sekundarni ZZP

PREVERJANJE VNOSOV 2

(sekundarni ZZP)

DA

VNOSI

PRAVILNI?**

Ponovna potrditev podatkov

vnesenih PZZ-jev

KLIK NA

'SHRANI'?

DOVOLJEN ČAS

ODAJE PZZ1 in

PZZ2?***

Obvestilo, da ZZP ni

mogoče oddati zaradi

časovnih omejitev.

Obvestilo o uspešni

oddaji ZZP

DA

DA

DA

NE

NE

NE



56

2.18.2 Modul Nastavitve

Ta modul omogoča, da si uporabnik brez posredovanja administratorja sistema sam

nastavi nekatere pomembne parametre sistema, kot so:

• osebni podatki člana;

• način obveščanja o spremembah prevozov;

• sprememba vstopnega gesla v portal;

• ukinitev uporabniškega računa v spletni aplikaciji PortalDDS.

Podstran 'osebni podatki člana' (Slika 38) dajejo članu le vpogled v podatke, ki jih ima

društvo o članu. Možnost, ki jo okno ponuja, je le skok nazaj, pri katerem uporabnik

izbira med različnimi nastavitvami, naštetimi zgoraj.

Slika 38: Nastavitve – osebni podatki člana


Druga podstran, imenovana 'način obveščanja o spremembah prevozov', omogoča, da si

uporabnik nastavi eno izmed štirih možnosti za obveščanje o spremembah statusov

ZZP. Prva možnost je obveščanje prek elektronske pošte, druga samo prek SMS, tretja

prek elektronske pošte in SMS, obstaja pa tudi možnost, da član ne želi prejemati

obvestil. Osnovni pogoj za uspešno prejemanje obvestil sta pravilna podatka o

uporabnikovi elektronski pošti in GSM-številki ter delovanje SMS-strežnika. Poleg tega

Nastavitve - Osebni podatki člana

Če ugotovite napačne podatke nas o tem nemudoma obvestite na 01/12-23-456.

Osebni podatki člana: Ime: Janja Priimek: Novak

Kontaktni naslov: Stalni naslov: Kreslinska ul. 63/1 1000 Ljubljana

Ameriška cesta 91/c 2000 Maribor

Stacionarni tel.: ni podatka

GSM: 040123456

E-mail: [email protected]

< Nazaj



57

je pomembno, da ima uporabnik ustrezno nastavljen filter nezaželene pošte, in sicer

tako, da dopušča prejemanje pošte z domene portala. Kar zadeva prejemanje SMS

sporočil, pa je pomembno, da ima uporabnik prevozov pri svojem mobilnem operaterju

omogočeno prejemanje komercialnih sporočil. Primere sporočil, ki jih uporabnik prejme

ob spremembi statusa ZZP, smo opisali v poglavju 2.17.5. Poleg opcij o načinu

obveščanja so prikazani še podatki o uporabnikovih veljavnih kontaktnih podatkih in

statusu SMS-strežnika (sporočilo, ko SMS-strežnik ne dela).

Slika 39: Nastavitve – način obveščanja o spremembah prevozov


Slika 40 prikazuje standardni vmesnik za spremembo gesla. Vpisati je treba staro geslo

in dvakrat novo. Geslo mora biti dolgo najmanj 6 alfa-numeričnih znakov in začne

veljati takoj po uspešno shranjeni spremembi.



58

Slika 40: Nastavitve – sprememba osebnega gesla


Zadnja možnost v nastavitvah je ukinitev uporabniškega računa, s čimer si uporabnik

blokira dostop do portala PortalDDS. Po ukinitvi računa lahko z vložitvijo prošnje in

izpolnitvijo vloge, ki jo dobi na društvu, spet pridobi dostop do portala.

2.18.3 Modul Razpored voženj

Slika 41 prikazuje razpored voženj za izbrani datum. Pri tem se izpišejo vsi listki ABCD

na eni strani. To pomeni, da seznam prikazuje tudi seznam vseh v terminih aktiviranih

voznikov. Izpis je namenjen posameznim uporabnikom in omogoča pregled potrjenih

ZZP za izbrani datum.



59

Slika 41: Razpored voženj




60

3 PREDLOGI ZA IZBOLJŠAVE SEDANJEGA IS

Med posodobitve IS prištevamo izboljšanje njegovih funkcionalnosti in spremembo

nekaterih delov njegove arhitekture. Predenj opredelimo izboljšave, je treba kritično

obravnavati pomanjkljivosti sedanjega informacijskega sistema z uporabniškega vidika

in z vidika razvoja programske opreme ter razpravljati o njih. Vsak razvijalec ima svoje

zamisli za izboljšave, pri čemer pa velikokrat pozabimo, da so funkcionalnosti sistema

tesno prepletene med seboj in so podaljšek sedanjih delovnih procesov. Z njihovo

spremembo lahko nehote vplivamo na že utečene delovne procese v organizaciji. Ker so

ti medsebojno povezani, se lahko zgodi, da s spremembo ene funkcionalnosti IS

neposredno vplivamo tudi na sam delovni proces. Razvijalci programske opreme

morajo biti zato zelo pozorni, da z uvajanjem novih informacijskih rešitev ne posegajo v

dobro delujoče segmente osnovnega koncepta sedanjega IS. Upoštevajo naj se le

rešitve, ki so nujne in bodo organizaciji na eni strani omogočile enostavnejše, hitrejše in

učinkovitejše poslovanje, na drugi strani pa zagotavljale ustrezno stopnjo informacijske

varnosti. To je bilo tudi naše osnovno vodilo pri izbiri funkcionalnosti, ki jih bomo

upoštevali pri posodobitvi sedanjega IS.

Nedvomno drži, da sedanji IS ponuja elektronsko hrambo različnih podatkov o vožnjah

ter omogoča OP, da zbira in ureja ZZP ter organizira vožnje. To je ena bistvenih

prednosti in pomeni začetek informatizacije na področju prevozov v društvu.

Konkretneje, aplikacija PrevoziDDS ponuja možnost, da OP operira s tistimi ZZP, ki jih

uporabniki prevozov sami oddajo prek spletne aplikacije PortalDDS. Ponuja tudi

tiskanje potnih nalogov in omogoča enostaven nadzor nad vožnjami. Omogoča tudi

različne načine obveščanja uporabnikov prevozov o spremembi statusa njihovih ZZP.

Ravno zaradi elektronskega shranjevanja podatkov pa je mogoče hitro in enostavno

dostopati tudi do različnih statistik, ki se nanašajo na izvedbo voženj. Te podatke

potrebujejo strokovne službe društva pri pripravi najrazličnejših poročil.

Kljub vsem prednostim, ki jih ima aplikacija PrevoziDDS v primerjavi z ročnim

načinom vodenja in organiziranja prevozov, ima tudi pomanjkljivosti, ki so se pokazale

med nekajletno redno uporabo. V nadaljevanju bomo predstavili za to delo najbolj



61

bistvene pomanjkljivosti aplikacije PrevoziDDS in predlagali ustrezne izboljšave, ki so

tudi okvir za nadgradnjo sedanjega informacijskega sistema.

3.1 Uvedba šifranta ulic

Opis problema

ZZP je v osnovi zelo precizno zgrajen (glej poglavje 2.17.1) in vsebuje pomembne

podatke, ki opredeljujejo posamezno vožnjo. V vnosna polja sedanje aplikacije za kraj

odhoda in kraj prihoda je mogoče vnesti opisno obliko lokacije (na primer le kratica FL

za Fakulteto za logistiko) ali ročno vpisati ulico (na primer Mariborska cesta 7). Pri

takšnem načinu vnosa posamezne ulice niso vpisane enotno. V nizih ročno vpisanih ulic

so namreč pogosto tipkarske napake. Poleg ročno vpisanih ulic pa se v sistem pogosto

vnašajo tudi kratice lokacij, ki jih vozniki poznajo, uporabniku prevozov in OP pa

omogočajo, da hitreje opiše kraj odhoda in kraj prihoda. Vnos, pri katerem lahko eno

lokacijo poimenujemo na več različnih načinov, pa ni dober zaradi nadaljnje obdelave

podatkov. Zato je treba uvesti šifrant ulic in IS pri vnašanju ZZP preurediti tako, da bo

ponujal možnost izbire iz šifranta ulic pri vseh lokacijskih podatkih. Sedanji sistem

namreč ne omogoča izbire podatka o kraju odhoda in kraju prihoda iz šifranta, ki bi

enolično identificiral ulice.

Predlog za izboljšavo

Slika 42 prikazuje zgradbo entitete ulica, ki je podlaga za vzpostavitev šifranta ulic.

Vidimo, da je entiteta ulica zgrajena iz sedmih atributov, pri čemer je za primarni ključ

določen idUlica. Atributi drzava, mesto, ulicainhisnast in ind_velj so podatkovnega tipa

varchar, medtem ko sta atributa x in y tipa double. Atribut ulicainhisnast vsebuje

podatek o ulici in hišni številki zaradi strukture podatkov, ki jih dobivamo iz GPS-

naprav in jih uporabimo za polnjenje šifranta ulic. Zgradbo entitete pozicije, od koder

črpamo podatke za šifrant ulic, smo opisali v poglavju 0. Atribut ind_velj pa opisuje

stanje indeksa veljavnosti posamezne ulice. Mogoči vrednosti tega atributa sta 0 ali 1,

kar nam pove, ali je posamezna ulica upoštevana pri obdelavi podatkov (vrednost 1) ali

ni (vrednost 0). Če ima ulica vrednost enako 0, ne bo upoštevana pri prikazu seznama

ulic v šifrantu. Zelo pomembna sta tudi atributa x in y, pri čemer x shranjuje vrednosti o



62

zemljepisni dolžini, y pa o zemljepisni širini ulice. Primer podatkov za entiteto ulica je

prikazan v Tabela 3.

Slika 42: Atributi entitete ulica

Tabela 3: Primer podatkov entitete ulica

idUlica drzava mesto ulicainhisnast x y ind_velj

1 SLOVENIJA LJUBLJANA LINHARTOVA CESTA 2 14.50854333 46.06330833 1

2 SLOVENIJA LJUBLJANA LINHARTOV PODHOD 1 14.50879833 46.06342833 1



5 SLOVENIJA LJUBLJANA LINHARTOVA CESTA 9 14.510.095 46.06454833 1

6 SLOVENIJA LJUBLJANA LINHARTOVA CESTA 11 14.51047333 46.06468833 1

Izvedba posodobitve v sedanjem IS

Na ravni podatkovnega modela je ob vzpostavitvi šifranta ulic treba uvesti nekatere

spremembe tudi v entiteti voznja, ki združuje vse pomembne podatke o ZZP. Ključna

sprememba je, da v sedanji entiteti voznja nadomestimo atributa mesto_odhoda in

mesto_prihoda z atributoma idUlica_mesto_odhoda in idUlica_mesto_prihoda. Tako

povežemo entiteto voznja z entiteto ulica in omogočimo uporabo šifranta ulic pri

določanju ključnih podatkov ZZP na ravni podatkov. Povezavo obeh entitet prikazuje

Slika 43. Opozarjamo, da smo nekatere atribute entitete voznja na sliki izpustili zaradi

lažjega prikaza, saj za obravnavo te posodobitve niso pomembni.

Poleg posodobitve na ravni podatkovnega modela je treba nekoliko modificirati tudi

GUI aplikacije PrevoziDDS in spletno aplikacijo PortalDDS, in sicer pri obeh tako, da



63

se ob vnosu podatkov namesto običajnih vnosnih polj za kraj odhoda in kraj prihoda

doda ustrezni spustni meni, v katerega se vnesejo podatki o atributih idUlica in

ulicainhisnast iz šifranta ulic na podlagi nekaj vpisanih začetnih črk ulice. Ob izbiri

želene ulice iz šifranta se tako v tabelo voznja shrani id izbrane ulice iz šifranta. Tako

pri vsakem ZZP dobimo celovito informacijo o kraju odhoda in prihoda, ki je enolično

definirana in vsebuje tudi geografske podatke (potrebovali jih bomo v nadaljevanju, ko

bo obravnavali avtomatizirano razporejanje ZZP).

Slika 43: Nova atributa entitete voznja in njena povezava z entiteto ulica

3.2 Vpeljava manjkajočih atributov indeksov veljavnosti različnih

entitet

Opis problema

Ko želimo izpeljati posodobitve v IS, je treba opredeliti tudi nekatere nove atribute, ki

določajo veljavnost atributa, kjer vrednost 0 ali 1 atributa kaže, ali je posamezen atribut

na voljo za uporabo pri nadaljnji obdelavi podatkov ali ne. Opredelitev teh atributov je

torej nujna tudi zato, ker brez njih ni mogoče uresničiti avtomatiziranega razporejanja

ZZP.



64

Predlog izboljšave

Sedanji sistem ne vsebuje naslednjih indeksov veljavnosti, zato jih je treba vpeljati, kot

prikazuje Slika 44:

• brezhibnost vozila (entiteta vozilo);

• razpoložljivost voznika (entiteta voznik);

• uporaba mobilne aplikacije iPrevoziDDS pri vozniku (entiteta voznik);

• samodejno razporejanje ZZP pri uporabniku prevozov (entiteta clan).

Slika 44: Novi atributi v entitetah vozilo, voznik in clan


Indeks veljavnosti vozila (entiteta vozilo), ki govori o njegovem stanju, je pomemben

podatek, ko želimo, da sistem sam dodeljuje voznike vozilom. Enako velja za voznike.

OP ima v sedanjem sistemu že celovito informacijo, ali je vozilo brezhibno in tako na



65

voljo za dodelitev vozniku, ter ali bo voznik na voljo za določen termin. Uvedba

indeksa brezhibnosti vozila in indeksa razpoložljivosti voznika sta eni od glavnih

funkcionalnosti, ki jih je treba uvesti, če želimo zagotoviti samodejno dodeljevanje

voznikov vozilom. Oba atributa, ki to določata, smo v entitetah vozilo in voznik

poimenovali z ind_velj in sta tipa varchar.

Indeks veljavnosti oziroma atribut, ki določa možnost uporabe mobilne aplikacije pri

vozniku, smo poimenovali iPrevoziDDS (entiteta voznik) in pomeni, ali lahko točno

določen voznik uporablja mobilno aplikacijo iPrevoziDDS ali ne (vrednost tega atributa

je lahko 1, kar pomeni, da lahko voznik prek mobilne aplikacije dostopa do IS, sicer je

ta vrednost 0). Nekateri vozniki ne bodo imeli ustreznih mobilnih naprav, zato je

navedeni indeks treba uvesti zaradi informacijske varnosti.

Indeks veljavnosti samodejnega razporejanja ZZP pri uporabniku prevozov (entiteta

clan) smo poimenovali z atributom autoZZP, ki kaže, ali so uporabnikovi ZZP lahko

upoštevani v procesu samodejnega razporejanja ali ne. Sedanja podatkovna tabela

članov (uporabnikov prevozov) ne vsebuje podatka o indeksu veljavnosti za samodejno

razporejanje njegovih ZZP. Uvedba tega indeksa je eden izmed osnovnih pogojev, da se

lahko uporabnikovi ZZP razporedijo samodejno. V procesu samodejnega razporejanja

ZZP morajo biti namreč upoštevane tudi izjeme. Pri njih ZZP, ki so jih oddali

posamezni uporabniki prevozov, v procesu samodejnega razporejanja niso upoštevani in

jih mora OP naknadno razporediti ročno (posebne izjeme pri nekaterih uporabnikih

prevozov) ali pa ostanejo nerazporejeni in zastarijo. Primeri, ko je treba ZZP nekaterih

uporabnikov izvzeti iz procesa samodejnega razporejanja, so sicer redki, a se lahko

zgodijo v posebnih okoliščinah.

3.3 Dopolnitev funkcionalnosti GUI za upravljanje novih indeksov

veljavnosti

Opis problema

Odločitev o vrednostih vseh indeksov veljavnosti, omenjenih v poglavju 3.2, mora

sprejemati OP, zato mora imeti možnost, da jih v ustreznem šifrantu kadarkoli tudi



66

spreminja. GUI sedanje aplikacije PrevoziDDS ne omogoča spreminjanja naslednjih

indeksov veljavnosti:

• brezhibnosti vozila;

• razpoložljivosti voznika;

• uporabe mobilne aplikacije iPrevoziDDS pri vozniku;

• samodejnega razporejanja ZZP pri uporabniku prevozov.

Predlog za izboljšave

Kot lahko vidimo v poglavju 2.11, je v sedanjem GUI šifranta vozil že vzpostavljena

funkcionalnost za spreminjanje vrednosti indeksa veljavnosti vozila, a se ni uporabljala.

Če je vozilo brezhibno in na voljo za uporabo, ima v podatkovni bazi vrednost 1 in je v

GUI označeno z 'Da', sicer je njegova vrednost v podatkovni bazi enaka 0, v GUI pa je

označeno z 'Ne' (Slika 18).

Podobno velja za šifrant voznikov, ki je opisan v poglavju 2.12, pri čemer je

funkcionalnost za spreminjanje vrednosti indeksa razpoložljivosti vozila v GUI že

vzpostavljena, v praksi pa se ni uporabljala. Tako je treba prilagoditi GUI za

funkcionalnost spreminjanja vrednosti indeksa uporabe mobilne aplikacije iPrevoziDDS

pri vozniku.

Možnost spreminjanja indeksa, ki določa dovoljenje samodejnega razporejanja ZZP pri

uporabniku prevozov, je še zadnja adaptacija v okviru te posodobitve. Podobno kot pri

ostalih indeksih veljavnosti, opisanih v tem poglavju, se tudi pri tem uvedejo

spremembe, pri čemer OP v šifrantu članov določi, ali so ZZP določenega uporabnika

prevozov lahko vključeni v proces avtomatiziranega razporejanja ZZP ali ne.


Omenili smo že, da indeksa veljavnosti brezhibnost vozila in razpoložljivost

voznika že obstajata, a se v praksi nista uporabljala. Enako realiziramo tudi indeks

veljavnosti iPrevoziDDS in autoZZP. Tako v paketu dobimo štiri izjemno pomembne

atribute, ki jih bomo uporabljali v procesu avtomatiziranega razporejanja ZZP.



67

3.4 Dopolnitev šifranta članov v kontekstu določanja volumenske

zasedenosti na ravni podatkov in ustrezna preureditev GUI

Opis problema

Entiteta član ne vsebuje atributa, s katerim bi določili vrsto ortopedskega pripomočka,

ki ga invalid uporablja, prav tako sedanji GUI ne omogoča spreminjanja vrednosti tega

atributa, ki je pomemben podatek pri določanju volumenske zasedenosti vozila in

izračunavanju prostora v vozilu pri avtomatiziranem razporejanju ZZP.

Predlog za izboljšave

Pri tej izboljšavi nastopajo tri med sabo povezane entitete, in sicer: sifrant_sifrantov,

sifrant in clan. Entiteta sifrant_sifrantov vsebuje vse podatke o različnih šifrantih,

katerih vrednosti so shranjene v splošnem šifrantu, ki ga upodobimo z entiteto sifrant.

Zato v sedanji podatkovni tabeli sifrant_sifrantov dodamo nov zapis tako, kot kaže

Tabela 4:

Tabela 4: Opredelitev šifranta vrst ortopedskih pripomočkov v sedanji podatkovni

tabeli sifrant_sifrantov

ID: Naziv: Opis:

19 Vrsta ortopedskega

pripomočka

Šifrant, ki vsebuje podatke o

vrsti ortopedskih

pripomočkov.

V sedanji podatkovni tabeli sifrant moramo opredeliti vse nove vrste ortopedskih

pripomočkov, kot so opisani v poglavju 2.4 in prikazani v Tabela 5:

Tabela 5: Opredelitev novih vrst ortopedskih pripomočkov v sedanji podatkovni tabeli

sifrant

ID: vsif_id: Naziv: ind_velj:

86 19 Invalidski voziček na ročni pogon 1

87 19 Invalidski voziček na elektromotorni pogon 1

89 19 Elektromotorni skuter 1

90 19 Rolator 1



68

91 19 Hodulja 1

92 19 Bergle 1

Entiteto clan pa moramo posodobiti tako, da ji dodamo nov atribut, ki ga poimenujemo

vrsta_ort_prip_sif_id in je tuj ključ splošnega šifranta sifrant. Slika 45 prikazuje

povezavo vseh v tem poglavju omenjenih entitet, s čimer smo na ravni podatkov izvedli

posodobitev.

Slika 45: Povezava entitet sifrant_sifrantov, sifrant in clan



69


V sedanjem IS je treba na ravni GUI vzpostaviti še funkcionalnost, ki bo omogočala

povezavo s sistemom članske evidence, pri čemer bo mogoče atribut

vrsta_ort_prip_sif_id entitete clan tudi dejansko določiti pri vsakem članu posebej.

Vzpostavitev te funkcionalnosti na ravni ločene aplikacije za člansko evidenco ni

predmet tega dela, zato ga tukaj ne opisujemo. Tako smo zagotovili le pogoje, da se

uporaba atributa vrsta_ort_prip_sif_id entitete clan tudi dejansko uporabi v postopkih

avtomatiziranega razporejanja ZZP.

3.5 Algoritmi za avtomatizirano razporejanje ZZP

Osrednji izziv te naloge je uveljaviti ustrezen model in z njim uresničiti postopek

avtomatiziranega razporejanja zahtevkov za prevoz z IS za organiziranje prevozov v

Društvu distrofikov Slovenije. Kot smo že opisali v zgornjih poglavjih, je razporejanje

ZZP v sedanjem IS mogoče le s pomočjo organizatorja prevozov. Ker moramo pri

razvrščanju ZZP upoštevati veliko pogojev, ki se lahko med seboj tudi izključujejo, se

OP pogosto znajde v težavnem položaju, saj ZZP ni mogoče trivialno, predvsem pa

hitro razporediti ustreznemu vozniku. OP zato uporablja različne tehnike, ki temeljijo na

intuitivnem odločanju, velikokrat pa mora spregledati tudi prenekateri osnovni pogoj, da

lahko ZZP ustrezno razporedi. Rezultat takšnega načina razporejanja logistično ni

optimalen, saj ob veliki količini različnih želja uporabnikov OP porabi veliko časa za

vnos in razporejanje ZZP, marsikdaj je zaradi velikega števila osnovnih pogojev takšen

ZZP težko ustrezno razporediti (zelo širok spekter osnovnih pogojev, opisanih v

poglavju 2.17.6), za izvedbo ZZP se porabi več časa, s tem pa se povečajo tudi stroški,

povezani s prevozi in njihovo izvedbo. Po drugi strani pa ima zapleten način

razporejanja ZZP, kakršnega poznamo, najmanj dve neželeni posledici:

• povečanje števila ZZP, ki jih spremeni OP (to povzroča težave uporabnikom

prevozov);

• povečanje prevoznih in drugih stroškov, ki nastajajo pri izvajanju ne optimalno

razporejenih ZZP.

Če želimo razporejanje ZZP avtomatizirati in ga izvesti tako, da bo informacijski sistem

znal suvereno predlagati čim bolj optimalne rešitve, moramo realni problem modelirati s



70

primerno teoretično podlago, ki temelji na vnaprej dobro opredeljenih postopkih. V

našem primeru imamo tako opravka s sistemom za podporo odločanju, ki organizatorju

prevozov kot rešitev predlaga eno izmed mogočih končnih rešitev, to je optimalno

razporejen seznam ZZP. Mogočih končnih rešitev je sicer lahko več, IS pa naj OP

predlaga prvo5 najdeno rešitev. OP je tako še vedno odgovoren, da predlog dobljene

rešitve (seznam razporejenih ZZP) pregleda, izvede morebitne modifikacije in ga na

koncu sprejme oziroma potrdi. Z avtomatiziranim razporejanjem ZZP bo organizatorju

prevozov prihranjen čas pri razporejanju, odločitve pa bodo bolj rezultat optimizacijskih

postopkov.

V splošnem lahko trdimo, da bomo problematiko razporejanja ZZP reševali s sistemom

za podporo odločanju, pri čemer je treba izpolniti množico vnaprej opredeljenih meril in

upoštevati, da morajo biti ZZP izvedeni čim bolj pravočasno in da imamo za izvedbo

prevozov na voljo omejene vire. Vire, ki jih spremljamo med procesom razporejanja

ZZP, lahko gledamo z vidika:

• vozil (razpoložljiva vozila in zmogljivost v vozilih) ter

• voznikov (delovna obveznost in upoštevanje odmora).

V nadaljevanju se tako ne bomo ukvarjali s klasičnimi optimizacijskimi problemi,

temveč bomo izdelali algoritme, katerih rezultat bo prispeval h končnemu cilju, da IS

samostojno in avtomatizirano razporedi ZZP voznikom ter da dobimo ustrezno

optimiziran seznam ZZP, pri čemer se upošteva prej omenjena poraba virov.

3.5.1 Splošno o algoritmih in njihovi predstavitvi

Avtorja Goodaire in Parmenter (2006, str. 248) navajata, da se izraz algoritem danes

uporablja v splošnem pomenu, kot sinonim za proceduro oziroma postopek. Sestavine

algoritma so vhodni in izhodni podatki ter zaporedja točno določenih korakov, ki

spremenijo vhodne podatke v izhodne.

5 Iskanje optimalne rešitve v množici končnih rešitev zaradi obsežnosti problematike v nadaljevanju ni zajeto.



71

Kononenko in Robnik Šikonja (2003, str. 5) pa navajata, da se v procesu reševanja

problemov spreminja njihova definicija. Ta v prvi fazi govori, kaj je treba napraviti za

rešitev problema, in se spremeni v zaporedje operacij, ki natančno opredeljujejo, kako

se nek problem tudi reši. Algoritem je torej opis postopka, s katerim rešimo problem. V

splošnem pa lahko navedemo naslednji dikciji algoritma:

• »Algoritem je končno zaporedje natančno določenih ukazov, ki opravljajo neko

nalogo v končnem številu korakov. Algoritem sprejme vhodne podatke in vrne

rezultat.«

• »Program je algoritem, ki ga lahko izvajamo na računalniku, tj. program je

algoritem, ki je zapisan v programskem jeziku.«

V našem primeru bodo seveda zanimivi algoritmi, ki jih lahko uporabimo za izvajanje

na računalniku. Algoritem lahko izrazimo na različne načine, in sicer:

• v naravnem jeziku;

• s psevdokodo;

• z diagrami poteka ali

• z ustreznim zapisom v programskih jezikih.

Za obravnavo naše problematike se bomo v nadaljevanju tako omejili na ponazoritev

algoritma v naravnem jeziku in z diagrami poteka, saj želimo biti pri razpravi o

algoritmih za avtomatizirano razporejanje ZZP neodvisni glede programskih jezikov.

Psevdokoda omogoča formulacijo algoritma v neodvisni obliki, zato jo tudi opisujemo v

nadaljevanju.

Z neformalnim algoritmom tako opišemo matematični model, abstraktni podatkovni tipi

so vsebovani v psevdokodi, že izoblikovane podatkovne strukture pa izvedemo v

programu. Razvoj algoritma kaže Slika 46.

Slika 46: Razvoj algoritma

��č��

�� →

��

��→

��

��

Vir: Kononenko, Robnik-Šikonja, Algoritmi in podatkovne strukture I, 2003, str. 9



72

Psevdokoda

Če želimo postopke algoritma zapisati v splošni obliki, ga moramo zapisati v

psevdokodi. Psevdokoda (angl. pseudocode) je strnjen in neformalen visokonivojski

zapis računalniškega algoritma. Čeprav je zapis neformalen, vključuje strukturne

dogovore, ki sicer tudi veljajo za programske jezike. V psevdokodi navadno izpuščamo

podrobne podprograme, deklaracije spremenljivk in kompleksnejšo sintakso, ki je

specifična za vsak programski jezik posebej. S takim načinom formalizacije algoritma

bralcu omogočimo njegovo lažjo interpretacijo in razumevanje, saj ga lahko razumejo

tudi tisti, ki ne poznajo specifik točno določenega programskega jezika. Poleg lažje

interpretacije algoritma pa psevdokoda omogoča neodvisnost programskih jezikov, saj

je splošen opis delovanja določenega algoritma, obogatenega z opisi podrobnosti v

naravnem jeziku. Grafična ponazoritev psevdokode pa so diagrami poteka.

Glede na psevdokodo, ki jo navaja Drozdek (2005, str. 433), lahko algoritem (v

konkretnem primeru je to Fleuryjev algoritem) po vzoru Kramberger (2010, str. 56)

zapišemo takole:

Tudi avtorji (Sánchez–Torrubia, Torres–Blanc & Giménez–Martínez, 2007, str. 87)

upodobijo psevdokodo za Fleuryjev algoritem podobno.



73

Diagrami poteka

Algoritem lahko preprosto upodobimo tudi z diagramom poteka, katerega gradniki so

med seboj povezani z usmerjenimi puščicami. Slika 47 prikazuje najosnovnejše

gradnike diagramov poteka.

Diagrami swimlane

Z diagrami poteka ilustrativno prikažemo potek algoritmov. Da bi povečali njihovo

izrazno moč, so bili razviti tako imenovani diagrami swimlane, ki poleg procesnega

vidika obravnavajo še organizacijsko strukturo podjetja in pri tem pomagajo opredeliti

nosilce posameznih aktivnosti. V ta namen se uporabljajo steze (angl. swimlane) v

kombinaciji z gradniki diagramov poteka.

Slika 47: Gradniki diagrama poteka



74

Osnova diagrama swimlane je tako dvodimenzionalni koordinatni sistem, pri čemer so

na eni osi steze (angl. lanes), ki predstavljajo oddelke, hierarhične ravni v podjetju,

posameznike, ipd., ki sodelujejo v procesu, na drugi osi pa modeliramo procesne faze in

aktivnosti z diagrami poteka (angl. flowchart).

Ta ponazoritev omogoča hitro opredelitev projektnih faz oziroma aktivnosti in njihovih

nosilcev. Pri tem so komunikacijski tokovi med aktivnostmi ponazorjeni s puščicami, ki

ne ločijo podatkovnih od krmilnih tokov.

Ravno zaradi ustreznosti diagramov swimlane za naš primer smo za predstavitev

prenovljenih postopkov uporabili to notacijo.

Zapis v programskem jeziku

Slika 48 ponazarja zapis algoritma v programskem jeziku Visual Basic.NET. To je

preprosta funkcija z imenom VrniNakljucniString, ki na vhod prejme podatek o dolžini

niza (spremenljivka intLen tipa integer) in kot rezultat vrne naključen niz dolžine

intLen.

Slika 48: Primer zapisa algoritma v programskem jeziku

V nadaljevanju bomo predstavili en inicializacijski algoritem, ki opravi nekaj osnovnih

postopkov nad podatki ter štiri algoritme za avtomatizirano razporejanje ZZP:

• algoritem za avtomatizirano razporejanje ZZP z upoštevanjem statično določenih

časovnih parametrov (A_SČP);

• algoritem za avtomatizirano razporejanje ZZP z upoštevanjem dinamično določenih

časovnih parametrov (A_DČP);



75

• algoritem za avtomatizirano razporejanje ZZP z upoštevanjem združevanja ZZP na

isti relaciji (A_Z) ter

• algoritem za avtomatizirano razporejanje ZZP z upoštevanjem optimizacije poti

(A_OP).

3.5.2 Inicializacijski algoritem

Inicializacijski algoritem je sklop postopkov, ki jih je treba izvesti nad podatki pred

samim postopkom avtomatiziranega razporejanja ZZP, da se v IS zagotovijo ustrezni

podatki in pogoji, ki jih sistem potrebuje v nadaljevanju. Algoritem lahko opišemo z

diagramom poteka tako, kot prikazujeta Slika 49 in Slika 50, vsebinsko pa ga razdelimo

na šest segmentov:

• 1 – določitev pravil o rotaciji voznikov za vožnje po Sloveniji;

• 2 – določitev pravil o rotaciji voznikov za vožnje v tujini;

• 3 – določitev pravil o rotaciji vozil za vožnje v tujini;

• 4 – določitev pravil o izmenskem delu voznikov;

• 5 – sprememba statusa zastarelim ZZP in

• 6 – definiranje kvartarnih geografskih območij.

Kot kaže Slika 49, se algoritem prične z določitvijo pravil o rotaciji voznikov za vožnje

po Sloveniji. Najprej se iz podatkovne tabele preberejo vsi aktivni vozniki, ki imajo kot

priljubljeno vožnjo določeno območje Slovenije (atribut

voznik.priljubljenaLokVoznje_sif_id). Organizatorja prevozov sistem nato vpraša, ali naj

IS sam določi pravila o rotaciji voznikov v Sloveniji. Na pritrdilen odgovor se v

podatkovni bazi preberejo podatki iz tabele VoznikSlovenija (Tabela 10) za vsakega

voznika, pri čemer se shranjujejo statistike o voznikovih dodelitvah za vožnjo po

Sloveniji v preteklem obdobju (na primer prejšnji delovni dan). Nato se ustrezno izvede

rotacija voznikov. To pomeni, da se za aktivne voznike za vožnjo v Sloveniji določijo

tisti, ki morda prej niso bili določeni, in nasprotno. Naj ponazorimo: med vozniki, ki

raje opravljajo delo v Sloveniji, se menjujeta mestni in medkrajevni tip vožnje za

aktualno obdobje (na primer datum razporejanja ZZP), pri čemer se v podatkovni tabeli

ustrezno določa atribut VoznikSlovenija.TipVoznjeVslo_sif_id za vsakega

razpoložljivega voznika posebej. Če pa se OP odloči, da IS samostojno ne določa pravil



76

o rotaciji voznikov v Sloveniji, mora ta pravila o rotaciji določiti sam. V obeh primerih,

če se za to odloči IS ali OP, se s tem shranijo pravila o rotaciji voznikov za vožnje po

Sloveniji v podatkovno tabelo VoznikSlovenija in zaključi se prvi segment.

Sledi določitev pravil o rotaciji voznikov za vožnje v tujini, pri čemer se preberejo

aktivni vozniki iz podatkovne tabele voznik in upoštevajo tisti, ki imajo kot priljubljeno

določeno vožnjo v tujini. OP nato določi, ali IS sam določi pravila o rotaciji voznika v

tujini in v primeru pritrdilnega odgovora se preveri podatkovna tabela VoznikTujina za

vsakega voznika posebej (za prejšnji delovni dan). Nato se ustrezno izvede rotacija

voznikov za vožnjo v tujini. To pomeni, da se za aktivne voznike za vožnjo v tujini

določijo tisti, ki morda prej niso bili določeni, in nasprotno. Naj ponazorimo: če tujino

preferira več voznikov, vožnja pa je samo ena, se določi voznik z dotlej najmanjšim

številom opravljenih voženj v tujini. Pravila se shranijo prav tako v podatkovno tabelo

VoznikTujina. Če se OP odloči, da IS samostojno ne določa pravil o rotaciji voznikov v

tujini, mora voznike določiti sam. S tem se shranijo pravila o rotaciji voznikov za

vožnje v tujini.

Ko algoritem določi pravila o rotaciji voznikov, nadaljuje z določitvijo pravil o rotaciji

vozil za vožnje v tujini, pri čemer se analogno že opisanima segmentoma najprej

preberejo aktivna vozila iz podatkovne tabele vozilo, OP določi, kdo izdela pravila o

rotaciji vozil v tujini, prebere se podatkovna tabela VoziloTujina za vsako vozilo,

določeno za vožnjo v tujini, sledi proces določanja novih pravil in njihovega

shranjevanja v isto podatkovno tabelo.

Za lažje razumevanje navedimo primer rotacije voznikov v Sloveniji in tujini. Imamo

šest voznikov: A, B, C, D, E in F. Vozniki A, B, C, D raje vozijo v Sloveniji, E in F pa

v tujini. Inicializacijski algoritem najprej določa rotacijo voznikov za vožnje v

Sloveniji, zato obravnava le voznike A, B, C in D. Preveri, kako so vozili v preteklem

obdobju (na primer prejšnji delovni dan). Recimo, da sta bila A in B zadolžena za

mestne, C in D pa za zunajmestne vožnje. Algoritem zato za aktualno obdobje (na

primer današnji delovni dan) zamenja lokacijo vožnje tako, da vozniku A in B določi

zunajmestne vožnje, vozniku C in D pa mestne vožnje. Nato se v drugem segmentu

algoritma posveti še voznikoma E in F, ki raje vozita v tujini. Algoritem preveri, kako



77

sta vozila v preteklem obdobju, in za vsakega posebej prešteje, koliko voženj v tujini sta

opravila. Če je vožnja za tujino ena, na voljo pa imamo dva voznika, se dodeli tisti z

manj opravljenimi vožnjami v tujini, ipd. Pravil, kako natančneje določati rotacijo

voznikov in vozil, tukaj ne obravnavamo, saj je pred tem potrebna natančna uskladitev z

internimi pravili invalidske organizacije o rotaciji voznikov in vozil. Podobno velja za

rotacijo vozil. Zato je z algoritmom opisan le osnovni koncept, ki pa ga je mogoče v

prihodnje še razširiti.

Nadaljujemo s četrtim segmentom inicializacijskega algoritma, ki določa pravilo o

izmenskem delu voznikov. Če se OP odloči, da ta pravila določi sistem, se najprej

preberejo podatki o voznikovih predvidenih odsotnostih z dela iz podatkovne tabele

VoznikLD. Sledi branje podatkov o izmenskem delu voznika v Sloveniji iz podatkovne

tabele VoznikIzmenskoDelo. Prebrani podatki so podlaga za določitev pravil, ki se

shranijo v isto tabelo. Tako kot v predhodnih segmentih ima OP tudi tukaj možnost, da

ta pravila določi sam.

Peti segment spreminja status tistim ZZP, ki so zaradi različnih razlogov zastareli.

Algoritem preveri, ali je sedanji čas razporejanja večji ali enak razliki med časom

odhoda, ki je zabeležen v ZZP, in globalno spremenljivko

gCasovnaRezervaPriRaporejanju. Če je odgovor pritrdilen, se status ZZP spremeni na

zastarel, vse pa se evidentira v podatkovni tabeli voznja. Namen tega segmenta

algoritma je eliminirati zastarele ZZP v procesu avtomatiziranega razporejanja ZZP, ki

sledi.

Kot zadnji segment tega algoritma pa se opredelijo kvartarna geografska območja. To

so območja, določena na zemljepisni karti, ki jo (glede na privzeto vrednost) delijo na

štiri enaka območja z določeno središčno točko. Koordinate te točke so pridobljene iz

dveh globalnih spremenljivk gSrediscnaTockaX in gSrediscnaTockaY, ki določata njeno

zemljepisno širino in dolžino. V našem primeru smo sicer obravnavali štiri kvartarna

območja, posodobljen informacijski sistem pa jih lahko obravnava tudi več, odvisno od

prednastavljene vrednosti globalne spremenljivke gStKvartarnihPodrocij, ki mora biti

večje ali enako štiri. Če je gStKvartarnihPodrocij večja kot štiri, mora biti ostanek pri

njenem deljenju z dva enak nič.



78

Slika 49: Inicializacijski algoritem 1/2



79

Slika 50: Inicializacijski algoritem 2/2



80

Povejmo, da smo pri inicializacijskem algoritmu na novo opredelili šest podatkovnih

tabel, ki jih predstavljamo v nadaljevanju:

• GlobalnaSpremenljivka (podatkovna tabela za shranjevanje vrednosti globalnih

spremenljivk), kot prikazuje Tabela 6, ter podatki v tej tabeli, kot prikazuje Tabela

7;

• VoznikTujina (podatkovna tabela za evidenco dodeljenih voznikov za tujino), kot

prikazuje Tabela 8;

• VoziloTujina (podatkovna tabela za evidenco dodeljenih vozil za tujino), kot

prikazuje Tabela 9;

• VoznikSlovenija (podatkovna tabela za evidenco pravil o rotaciji voznikov za

vožnje v Sloveniji), kot prikazuje Tabela 10;

• VoznikIzmenskoDelo (podatkovna tabela za evidenco pravil o izmenskem delu

voznikov Sloveniji), kot prikazuje Tabela 11;

• VoznikLD (podatkovna tabela za evidenco voznikovih načrtovanih odsotnosti z

dela), kot prikazuje Tabela 12.

Poleg deklaracij novih podatkovnih tabel pa so bile potrebne naslednje modifikacije

sedanjega informacijskega sistema na področju že uveljavljenih šifrantov:

• v sedanji podatkovni tabeli sifrant_sifrantov opredeliti šifrant tipov vožnje v

Sloveniji, kot prikazuje Tabela 13;

• v sedanji podatkovni tabeli sifrant opredeliti dva nova zapisa vožnje v Sloveniji, in

sicer tako, kot prikazuje Tabela 14;

• v sedanji podatkovni tabeli sifrant_sifrantov opredeliti šifrant tipov izmenskega

dela, kot prikazuje Tabela 15;

• v sedanji podatkovni tabeli sifrant opredeliti dva nova zapisa izmenskega dela, kot

prikazuje Tabela 16;

• v sedanji podatkovni tabeli sifrant_sifrantov opredeliti šifrant tipov lokacij voženj

voznika, kot prikazuje Tabela 17;

• v sedanji podatkovni tabeli sifrant opredeliti dva nova zapisa lokacije voženj

voznika, kot prikazuje Tabela 18.



81

v sedanji podatkovni tabeli voznik opredeliti nov atribut

voznik.priljubljenaLokVoznje_sif_id, ki govori o voznikovi priljubljeni lokaciji za

vožnjo (v Sloveniji ali v tujini), kot prikazuje

Tabela 19.

Tabela 6: Vzpostavitev nove podatkovne tabele GlobalnaSpremenljivka

Ime atributa: Podatkovni tip: Opis atributa: Primer:

ID int(11) Primarni ključ 1

Naziv varchar(50) Naziv globalne spr. gMestniRadius

Vrednost varchar(100) Vrednost globalne

spr.

30

Opis varchar(200) Dodatni opis spr. v kilometrih opredeljuje kateri ZZP

spadajo v območje mestnih in kateri

v območje zunajmestnih voženj

ind_velj varchar(1) Indeks veljavnosti 1

Tabela 7: Podatki tabele GlobalnaSpremenljivka

ID: Naziv: Vrednost: Opis: ind_velj:

1 gMestniRadius 30 v kilometrih opredeljuje

kateri ZZP spadajo v

območje mestnih in kateri

v območje zunajmestnih

voženj

1

2 gCasVarFakVoznika 15 v minutah določa časovni

varnostni faktor voznika

1

3 gCasMaliceDopoldan 11:00 ura, ko je predviden čas

malice voznika dopoldan

1

4 gCasMalicePopoldan 17:00 ura, ko je predviden čas

malice voznika popoldan

1

5 gCasTrajanjaMalice 30 v minutah določa čas

trajanja malice

1

6 gGlParkX 14.529835 zemljepisna dolžina

glavnega parkirišča v

decimalnih stopinjah

1



82

7 gGlParkY 46.05458333 zemljepisna širina

glavnega parkirišča v


1

8 gStDniNazajPZP 15 število dni, ko se od dne

preiskovanja za nazaj

upoštevajo podatki o

zgodovini prevozov (PZP)

1

9 gMaxStUpostevanihRelacij 30 maksimalno število

upoštevanih relacij

najdenih v podatkih o

zgodovini prevozov (PZP)

1

10 gSrediscnaTockaX 14.529835 zemljepisna dolžina

središčne točke v


1

11 gSrediscnaTockaY 46.05458333 zemljepisna širina

središčne točke v


1

12 gStKvartarnihPodrocij 4 določa število kvartarnih

področij

1

13 gCasovnaRezervaPriRaporejanju 8 v urah določa časovno

rezervo, ko ZZP še ni

zastarel

1

14 g_t1 0 globalna spremenljivka za

časovni parameter t1

1



1



1



1



1



1

20 g_t7 0 globalna spremenljivka za 1



83


21 gStPozPost 5 število pozicij, ki se

upoštevajo pri postankih

1

22 gMaxCasOdstopanjeZZP 30 v minutah določa za koliko

minut lahko čas odhoda

odstopa od časa pričetka

dejanske realizacije ZZP

1

Tabela 8: Vzpostavitev nove podatkovne tabele VoznikTujina



Voznik_id int(11) Tuj ključ na voznik.id 36

Datum datetime Datum poti v tujini 2011-12-08

Mesto varchar(100) Ime mesta v tujini Düsseldorf

Drzava varchar(100) Ime države v tujini Nemčija

Dogodek varchar(200) Naziv dogodka Udeležba na strokovnem

sejmu


Tabela 9: Vzpostavitev nove podatkovne tabele VoziloTujina



Vozilo_id int(11) Tuj ključ na vozilo.id 15

Datum datetime Datum poti v tujini 2012-11-03

Mesto varchar(100) Ime mesta v tujini Budimpešta

Drzava varchar(100) Ime države v tujini Madžarska

Dogodek varchar(200) Naziv dogodka Udeležba na konferenci AGM


Tabela 10: Vzpostavitev nove podatkovne tabele VoznikSlovenija






84

Datum datetime Datum poti v

Sloveniji

2011-12-08

TipVoznjeVslo_sif_id Int(11) Tuj ključ na sifrant.id 93


Tabela 11: Vzpostavitev nove podatkovne tabele VoznikIzmenskoDelo




DatumOd datetime Datum začetka

terminskega dela

2011-12-08

DatumDo datetime Datum konca terminskega

dela

2011-12-13

TipIzmenskegaDela_sif_id int(11) Tuj ključ na sifrant.id 95


Tabela 12: Vzpostavitev nove podatkovne tabele VoznikLD




DatumOd datetime Datum prvega dneva odsotnosti 2012-06-01

DatumDo datetime Datum zadnjega dneva odsotnosti 2012-06-06


Tabela 13: Opredelitev šifranta tipov vožnje v Sloveniji v podatkovni tabeli

sifrant_sifrantov

ID: Naziv: Opis:

20 Tip vožnje v Sloveniji Šifrant, ki vsebuje podatke o tipu vožnje

Tabela 14: Opredelitev novih zapisov za vožnje v Sloveniji v sedanji podatkovni tabeli

sifrant


93 20 Mestna vožnja 1



85

94 20 Medkrajevna vožnja 1

Tabela 15: Opredelitev šifranta tipov izmenskega dela v podatkovni tabeli

sifrant_sifrantov

ID: Naziv: Opis:

21 Tipi izmenskega dela Šifrant, ki vsebuje podatke o

tipih izmenskega dela

Tabela 16: Opredelitev novih zapisov izmenskega dela v sedanji podatkovni tabeli

sifrant


95 21 dopoldan 1

96 21 popoldan 1

97 21 ponoči 1

Tabela 17: Opredelitev šifranta tipov lokacij voženj voznika v podatkovni tabeli

sifrant_sifrantov

ID: Naziv: Opis:

22 Tipi lokacij voženj voznika Šifrant, ki vsebuje podatke o

tipih lokacij voženj voznika

Tabela 18: Opredelitev novih zapisov lokacij voženj voznika v podatkovni tabeli sifrant


98 22 Po Sloveniji 1

99 22 V tujini 1

Tabela 19: Vzpostavitev novega atributa priljubljenaLokVoznje_sif_id v podatkovni

tabeli voznik

Ime atributa: Podatkovni

tip:

Opis atributa: Primer:


Ime varchar(50) Ime voznika Janez

Priimek varchar(100) Priimek voznika Novak



86

GSM varchar(20) GSM voznika 041964001


priljubljenaLokVoznje_sif_id int(11) Voznikova

priljubljena lokacija

za vožnjo

98

3.5.3 Algoritem za avtomatizirano razporejanje ZZP z upoštevanjem statično

določenih časovnih parametrov (A_SČP)

A_SČP je algoritem, s katerim avtomatiziramo razporejanje ZZP glede na razpoložljive

vire (glej poglavje 3.5) z uporabo statično določenih časovnih parametrov. Ti dejansko

predstavljajo časovni interval (izražen s celimi števili v minutah), v katerem se

posamezno opravilo opravi. Časovni parametri se po tem algoritmu določijo statično.

To pomeni, da se določijo enkrat in se med izvajanjem algoritma praviloma ne

spreminjajo. Določi in spreminja jih OP, pri čemer pri vsakem uporabniku prevozov

posebej (glede na izkušnje poteka prevozov iz preteklosti) določi vse izmed sedmih

časovnih parametrov. Nekateri časovni intervali so lahko določeni na 'globalni ravni' in

se upoštevajo le, če uporabnik prevozov nima določenih svojih 'lokalnih' vrednosti

parametrov. Vrste časovnih parametrov smo obravnavali v poglavju 2.3. Pri tem

poudarjamo osnovni pogoj za začetek delovanja tega algoritma, in sicer morajo biti pred

pričetkom razporejanja določeni vsi časovni parametri na globalni ravni. Če v sistemu

za podporo odločanju upoštevamo merila, navedena v poglavju 2.17.6, lahko potek

algoritma A_SČP opišemo, kot prikazujeta Slika 51 in Slika 52.



87

Slika 51: Algoritem A_SČP 1/2



88

Slika 52: Algoritem A_SČP 2/2



89

Algoritem A_SČP najprej preveri, ali so določeni vsi statični časovni parametri na

globalni ravni. Opredeljeni morajo biti v podatkovni tabeli, ki združuje vse globalne

spremenljivke (Tabela 7). Če vrednost teh parametrov ni določena, se ta algoritem ne

more nadaljevati. V tem primeru dobi OP obvestilo o nepopolno določenih statičnih

časovnih parametrih na globalni ravni, pri čemer sledi prekinitev izvajanja tega

algoritma. Če so vsi parametri določeni, se naredi seznam razpoložljivih vozil, to so

vozila, ki niso v okvari in imajo določeno isto krajevno lastništvo. Zatem se naredi

seznam razpoložljivih voznikov, pri čemer je treba upoštevati naslednja tri pravila:

• pravilo o rotaciji voznikov za vožnje v Sloveniji (podatkovna tabela

VoznikSlovenija) in tujini (podatkovna tabela VoznikTujina);

• pravila o rotaciji vozil za vožnje v tujini (podatkovna tabela VoziloTujina) in

• pravila o izmenskem delu voznikov (podatkovna tabela VoznikIzmenskoDelo) in

njihovih predvidenih odsotnosti z dela (podatkovna tabela VoznikLD).

Sedaj se na ravni podatkovne baze z upoštevanem dovoljenja voznikov za upravljanje

vozil (podatkovna tabela DovoljenjaVoznikVozila) dodelijo ustrezna vozila k voznikom.

S tem je enolično določen voznik k vozilu. Ti podatki se shranijo v podatkovno tabelo

vozilo_voznik. Nato se preveri, ali so na voljo vozila z dodeljenimi vozniki. Če so, sledi

izračun števila prostih mest v vozilu z uporabo podatkovne tabele vozilo, pri čemer se

prebere podatek o zmogljivosti vozila, in sicer:

• število mest za prevoz invalidskega vozička;

• število mest za prevoz skuterjev in

• število mest za prevoz hodečih posameznikov.

Po tem se ugotavlja število uporabnikov, ki so oddali ZZP (podatkovna tabela voznja),

na podlagi česar se naredi seznam nerazporejenih ZZP. Obenem se izračunava

zmogljivost samega vozila, če se ta ZZP dodeli izbranemu vozilu, pri čemer se upošteva

invalidnost uporabnika prevozov. Algoritem tu preveri, ali obstajajo razpoložljiva vozila

z vozniki. Če ne obstajajo, sledita obvestilo OP o pomanjkanju zmogljivosti vozil in

zaključek algoritma, sicer pa se izbere vozilo z voznikom s seznama razpoložljivih vozil

in voznikov. Algoritem nato preveri, ali je voznik dosegel delovno obveznost. Če jo je,

se vnemo na točko, na kateri preverimo stanje o razpoložljivih vozilih. Sicer pa

nadaljujemo z izbiro ZZP s seznama še nerazporejenih voznikov, upoštevajoč njihovo



90

izmeno dela. Sledi preverjanje pogojev izogibanja voznikov, uporabnikov in vozil.

Natančneje, pri uporabniku se v podatkovni tabeli UpoIzogibanjeVoznikov preveri

izogibanje uporabnikov voznikom, uporabnikov vozilom v podatkovni tabeli

UpoIzogibanjeVozil in izogibanje uporabnikov drugim uporabnikom v podatkovni

tabeli UpoIzogibanjeUpo. Na ravni voznika pa se preveri njegovo izogibanje

uporabniku v podatkovni tabeli VoznikIzogibanjeUpo. Sledi izračun vsote Ti, ki pomeni

seštevek vseh sedmih statičnih časovnih parametrov posameznega izbranega ZZP. K tej

vsoti se prišteje še časovni varnostni faktor voznika, ki je shranjen kot vrednost v

globalni spremenljivki gCasVarFakVoznika ali lokalno v atributu voznik.CasVarFak.

Algoritem upošteva, da imajo lokalne vrednosti spremenljivk dominantno vlogo. Sledi

izračun časa, ko bo voznik dosegljiv za naslednjo vožnjo. Algoritem nadaljuje s

segmentom, v katerem preveri odmor voznika. Najprej preveri, ali trenutno izračunan

čas Ti že presega ali pa je enak času za malico (primerja z vrednostjo ustrezne globalne

spremenljivke gCasMaliceDopoldan oziroma gCasMalicePopoldan). Nato preveri, ali

je voznik slučajno že imel odmor. Če čas za odmor vozniku še ni bil dodan in ga v

tekočem delovniku še ni imel, se mu doda z izračunom Ti=Ti+gCasTrajanjeMalice, kjer

je gCasTrajanjeMalice določena globalna spremenljivka. Po dodelitvi odmora vozniku

algoritem preveri, ali bi z morebitnim dodajanjem tega ZZP k vozniku ta presegel svojo

delovno obveznost. Ta je opredeljena z novo vpeljanim atributom

voznik.delovnaObveznost. Če voznik z dodanim ZZP delovne obveznosti ne preseže, se

preveri zmogljivost vozila, in če ima vozilo na voljo ustrezne zmogljivosti, se ZZP

dodeli vozniku in ustrezno se zmanjšajo števci za zmogljivost vozila. Če se delovna

obveznost voznika preseže, se vrnemo na stopnjo algoritma, na kateri se preverja, ali

obstajajo še druga razpoložljiva vozila z vozniki. Postopek je isti, če niso na voljo

ustrezne zmogljivosti vozila. Nazadnje preverimo, ali obstajajo še nerazporejeni ZZP, in

če obstajajo, se vrnemo na stopnjo algoritma, na kateri se preverja, ali še obstajajo

razpoložljiva vozila z vozniki, sicer sledi obvestilo OP o uspešno zaključenem

razporejanju ZZP. Tu se algoritem tudi konča.

Povejmo še, katere nove podatkovne tabele je treba vpeljati pri algoritmu A_SČP:

• UpoIzogibanjeVoznikov (podatkovna tabela za evidenco pravil o izogibanju

uporabnika voznikom), kot prikazuje Tabela 20;



91

• UpoIzogibanjeVozil (podatkovna tabela za evidenco pravil o izogibanju uporabnika

vozilom), kot prikazuje Tabela 21;

• UpoIzogibanjeUpo (podatkovna tabela za evidenco pravil o izogibanju uporabnika

uporabnikom), kot prikazuje Tabela 22;

• VoznikIzogibanjeUpo (podatkovna tabela za evidenco pravil o izogibanju voznika

uporabnikom), kot prikazuje Tabela 23.

Vpeljati pa je treba tudi nov atribut delovnaObveznost v tabeli voznik, ki naj bo

podatkovnega tipa integer, s katerim opredelimo delovno obveznost voznika (na primer

8 ur, 6 ur …). Poleg tega pa še atribute t1, t2, t3, t4, t5, t6 in t7 v podatkovni tabeli clan,

ki so vsi podatkovnega tipa integer in v minutah izražajo posamezne statične časovne

parametre.

Tabela 20: Vzpostavitev nove podatkovne tabele UpoIzogibanjeVoznikov



Clan_ID int(11) Tuj ključ na clan.id 862

IzogniVoznik_ID int(11) Tuj ključ na voznik.id, ki se mu želi

uporabnik izogniti

31

Ind_velj Varchar(1) Indeks veljavnosti 1

Tabela 21: Vzpostavitev nove podatkovne tabele UpoIzogibanjeVozil




IzogniVozilo_ID int(11) Tuj ključ na vozilo.id, ki se mu želi

uporabnik izogniti

15


Tabela 22: Vzpostavitev nove podatkovne tabele UpoIzogibanjeUpo





92


IzogniClan_ID int(11) Tuj ključ na vozilo.id, ki se mu želi

uporabnik izogniti

15


Tabela 23: Vzpostavitev nove podatkovne tabele VoznikIzogibanjeUpo



Voznik_ID int(11) Tuj ključ na voznik.id 751

IzogniClan_ID int(11) Tuj ključ na vozilo.id, ki se mu želi voznik

izogniti

15


3.5.4 Algoritem za avtomatizirano razporejanje ZZP z upoštevanjem dinamično

določenih časovnih parametrov (A_DČP)

Rdeča nit algoritma A_SČP je avtomatiziramo razporejanje ZZP na podlagi predhodno

ročno opredeljenih časovnih parametrov uporabnika. Ker so tam časovni parametri

določeni enkrat in se njihova vrednost ne spreminja, govorimo o statično določenih

časovnih parametrih (SDČP). Pri algoritmu A_DČP je glavna funkcionalnost

avtomatizirano določanje časovnih parametrov. Ker se ti spreminjajo skozi čas glede na

izmerjene časovne intervale, so pridobljeni z računanjem povprečnih vrednosti časovnih

intervalov iz arhivskih podatkov preteklih uporabnikovih voženj ter se izračunavajo

avtomatizirano pred samo fazo razporejanja vsakega ZZP na listek ABCD, govorimo o

dinamičnem določanju časovnih parametrov (DDČP). Začetni in končni del algoritma

A_DČP je enak algoritmu A_SČP. Bistvena razlika pa je v koraku 5 (glej opis algoritma

A_SČP), pri katerem algoritem A_DČP dinamično izračuna vse časovne parametre za

posamezno vožnjo in ti niso več statično določeni. Algoritem A_DČP opisujeta Slika 53

in Slika 54.



93

Slika 53: Algoritem A_DČP 1/2



94

Slika 54: Algoritem A_DČP 2/2



95

Nekateri deli algoritma A_DČP so identični delom algoritma A_SČP, zato jih tukaj ne

opisujemo ponovno. Nadaljujmo na stopnji, kot jo prikazuje začetek Slika 54. Najprej

izberemo ZZP s seznama še nerazporejenih in preverimo pogoje izogibanja voznikov,

uporabnikov in vozil. Nato sledi pomemben segment izračunavanja dinamičnih

časovnih parametrov, kot jih prikazujejo Slika 55, Slika 56, Slika 57, Slika 58, Slika 59,

Slika 60 in

Slika 61. Po izračunu dinamično določenih časovnih parametrov sledi izračun vsote Ti

za vsak ZZP, ki se razporeja. Do konca sledi postopek, ki je identičen algoritmu

A_SČP. Tu je treba natančneje opisati, kako se dinamični časovni parametri v algoritmu

A_DČP izračunavajo.

Slika 55: Algoritem A_DČP (izračun časa t1)



96

Izračun časa t1 se prične s preverjanjem, ali predhodno izveden ZZP obstaja. Če da, se

izluščijo podatki o zemljepisni širini in dolžini tega ZZP za kraj prihoda, s čimer

opredelimo točko A. Če ne, pa pomeni, da je vozilo še v garaži, zato algoritem vzame

koordinate o zemljepisni širini in dolžini iz globalne spremenljivke, ki opredeli glavno

parkirišče (gGlParkX in gGlParkY), kjer prav tako dobimo točko A. Algoritem

nadaljuje tako, da prebere podatke o zemljepisni dolžini in širini za kraj odhoda iz

aktualnega ZZP, ki se bo razporedil, s čimer dobimo točko B. V naslednjem koraku

algoritem preišče podatke o zgodovini opravljenih prevozov za posameznega

uporabnika na relaciji od točke A do točke B in izlušči relacije od A do B, pri čemer je

potrebna uporaba globalnih spremenljivk gStDniNazajPZP in

gMaxStUpostevanihRelacij. Prva pomeni, za koliko dni nazaj preiskujemo podatke o

zgodovini opravljenih prevozov, druga pa, kolikšno je največje število relacij, ki se pri

izračunu povprečja upoštevajo. Tu si zapomnimo ID zadnjih pozicij vsake najdene

relacije, ki bo všteta pri računanju povprečja časov na relacijah od A do B, saj bomo ta

podatek potrebovali v nadaljevanju. Sledi izračun povprečja časov na vseh dobljenih

relacijah od A do B, s čimer dobimo želeni čas t1. Ta postopek prikazuje Slika 55.

Slika 56 prikazuje izračun časa t2 z metodo dinamičnega določanja časovnih

parametrov. Tudi tu gre za preiskovanje podatkov o zgodovini opravljenih prevozov,

zato se najprej preverita atribut pozicije.intervaltk in njegova dolžina. Če je ta daljša od

petih sekund, gre za postanek, in prav te moramo upoštevati v nadaljnjih izračunih. Že

pri izračunu časa t1 smo opredelili točko B, ki jo tukaj tudi uporabimo. V njeni bližini

namreč preiskujemo podatke, in sicer tam, kjer smo preiskovanje v tabeli pozicije

končali pri računanju časa t1. Iz teh podatkov izračunamo povprečje in dobimo čas t2.

Če je vrednost atributa pozicije.intervaltk enaka petim sekundam, gre za standarden

premik vozila in s tem njegove lokacije, zato takšni časovni intervali tu ne morejo biti

upoštevani. Preiskovanje se tako nadaljuje na naslednji poziciji, dokler ne dosežemo

pogoja, ki ga omejuje globalna spremenljivka gStPozPost in pomeni število pozicij, ki

se upoštevajo pri postankih.



97


Slika 57 prikazuje izračun časa t3. Ker tega časa ni mogoče izmeriti z napravami, ki so

na voljo v vozilih, je treba ta parameter določiti statično. Določen je na globalni ravni z

uporabo globalne spremenljivke g_t3 ali na lokalni ravni z atributom voznik.t3,

dominantno vloga pa ima seveda atribut, določen na lokalni ravni. Če ta pri vozniku ni

določen, se upošteva spremenljivka, določena na globalni ravni. Algoritem pričenja s

preverjanjem ravno teh elementov in pri končnem stanju prevzame eno izmed teh

vrednosti za čas t3.

Izračun časa t4 je pri algoritmu A_DČP identičen izračunu časa t3 pri algoritmu

A_DČP, saj se čas t4 s sedanjo tehnologijo v vozilih ne meri. Slika 58 podrobneje

prikazuje potek izračuna časa t4.



98





99

Izračun časa t5 se nadaljuje tam, kjer smo končali preiskovanje podatkov o zgodovini

opravljenih prevozov pri izračunavanju časa t2. Točko A opredelimo s koordinatami

kraja odhoda ZZP, ki jih dobimo iz šifranta ulic. Analogno opredelimo točko B s

koordinatami kraja odhoda ZZP. Nadaljujemo s preiskovanjem podatkov o zgodovini

opravljenih prevozov za posameznega uporabnika prevozov na relaciji od A do B, pri

čemer se izluščijo relacije od A do B. Kot smo opisali pri izračunu časa t1, je tudi tukaj

nujna uporaba globalnih spremenljivk gStDniNazajPZP in gMaxStUpostevaihRelacij, ki

omejita preiskovanje s podatki zasičeno tabele o zgodovini opravljenih prevozov. Za čas

t5 algoritem tako prevzame vrednost povprečja časov na vseh dobljenih relacijah od A

do B. Slika 59 opisuje algoritem pri izračunu časa t5.


Izračun časa t6 je analogen izračunu časa t4, prikazuje pa ga Slika 60. Čas t7 določa z

globalno spremenljivko g_t7, saj podatkov, potrebnih za izračun teh časov, iz statistik o

zgodovini opravljenih prevozov ni mogoče pridobiti iz merilnih senzorjev, nameščenih

v vozilih.



100



Dodajmo še nekaj opomb, ki jih je treba upoštevati pri izvajanju algoritma A_DČP.

Osnovni pogoj za njegovo ustrezno izvajanje je uvedba šifranta ulic s podatki o nazivu

ulice, hišni številki, poštni številki, občini, državi ter, zelo pomembno, podatek o

zemljepisni širini in dolžini za to ulico. Zato je treba najprej vzpostaviti šifrant in

uvoziti ulice iz podatkov o zgodovini opravljenih prevozov. Kot vidimo, smo kljub

prizadevanju za čim bolj avtomatizirano razporejanje ZZP pri algoritmu A_DČP močno

odvisni od dobljenih podatkov GPS-naprav, nameščenih v vozilih, ki v posebnih



101

datotekah zbirajo podatke o zgodovini opravljenih prevozov (glej naslednje

podpoglavje). Poudariti je tudi treba, da ti podatki ne zajemajo vseh meritev, ki bi jih

potrebovali za popolno avtomatizirano razporejanje ZZP. Zato smo za izračun časov t3,

t4, t6 in t7 morali poseči po uvedbi globalnih ali lokalnih spremenljivk, ki jih

individualno določi organizator prevozov. Takšen pristop nam omogoča, da lahko z

algoritmom A_DČP kljub nekaterim pomanjkljivim podatkom o zgodovini opravljenih

prevozov razporejanje ZZP izvedemo avtomatizirano.

Povzemimo še, katere modifikacije podatkovne baze so potrebne za realizacijo

algoritma A_DČP. V sedanji podatkovni tabeli voznik je treba opredeliti nove atribute

voznik.t3, voznik.t4 in voznik.t6. Vsi so podatkovnega tipa integer in pomenijo različne

časovne parametre, ki so izraženi v minutah kot pozitivna cela števila.

Podatki o zgodovini opravljenih prevozov

Podatki o zgodovini opravljenih prevozov so podatki, dobljeni iz sledilnih GPS-naprav,

ki so nameščene v večini društvenih vozil. Naprava v vozilu v nekajsekundnih

intervalih pošilja v nadzorni center različne podatke o stanju vozila (podatki o trenutni

poziciji vozila, času, hitrosti, ulici ipd.), ki se zbirajo in hranijo na posebnem mestu v

obliki CSV-datotek (angl. comma-separated values). Za vsako vozilo je pripravljena

lastna datoteka, ki vsebuje podatke o njem za preteklih 24 ur. Te datoteke se ročno

kopirajo s strežnika nadzornega centra na strežnik društva na posebno lokacijo, kjer se s

posebej prilagojenimi podprogrami aplikacije PrevoziDDS podatki tudi obdelajo in

uvozijo v aktualno podatkovno bazo, tam pa so na voljo za nadaljnje delo. Postopkov

obdelave in uvoza v tem delu ne bomo obravnavali, podrobneje si poglejmo le strukturo

podatkovne tabele pozicije in nekaj primerov podatkov v njej za lažje razumevanje

vsebine algoritmov pri izračunavanju časovnih parametrov uporabnika v nadaljevanju.

Tabela 24 v nadaljevanju prikazuje atribute podatkovne tabele pozicije, kamor za lažjo

predstavo dodajamo še po dva primera podatkov konkretnih pozicij, ki sta shranjena v

tej tabeli:



102

Tabela 24: Zgradba in atributi entitete 'pozicije' s primeroma podatkov

Ime atributa: Podatkovni tip:

Opis atributa: Primer:

idpozicije int(11) Primarni ključ 160

vozilo varchar(45) GPS-oznaka vozila 15

cas datetime Datum in čas pozicije 2011-12-08 07:32:17

naslov text Naslov (ulica) pozicije SLOVENIJA, LJUBLJANA, ZALOŠKA CESTA 16

razdalja int(11) Razdalja, prevožena od zadnje pozicije.

32

hitrost int(11) Hitrost vozila 20

tock varchar(45) Glej opombo6 1

intervaltk varchar(45) Časovni interval7 0000:00:05

x double Zemljepisna dolžina8 v decimalnih stopinjah

14.529835

y double Zemljepisna širina9 v decimalnih stopinjah

46.05458333

digital varchar(45) Glej opombo6 8

keytk varchar(45) Glej opombo6 0

datumincas_vnosa datetime Čas vnosa pozicije v bazo 2011-12-31 15:46:12

idvoznja int(11) Id vožnje, ki mu ta pozicija pripada.

ime_datoteke varchar(100) Datoteka nadzornega centra, v kateri je ta pozicija.

Pozicije_2011_12_ 08_113012.csv

ulica_parsana varchar(1) Indikator, ali je naslov te pozicije že vnesen v šifrant ulic.

1

Pri vzpostavljanju šifranta ulic so za nas najpomembnejši atributi te podatkovne tabele

zagotovo vozilo, naslov, x in y. Pri računanju vrednosti časovnih parametrov pa je zelo

pomemben atribut intervaltk. Ta interval je navadno velik 5 sekund (na toliko časa GPS-

naprava navadno pošlje podatke v nadzorni center), lahko pa je seveda večji in v tem

primeru pomeni postanek vozila. Če sta x in y prejšnje pozicije v primerjavi s trenutno

6 Nekateri atributi vsebinsko niso pomembni za našo obravnavo in se nanašajo na tehnični del podatkov, dobljenih iz

GPS naprav, zato jih pri opisu izpustimo. 7 Kadar je ta časovni interval večji od 5 sekund, nam pove, koliko časa je vozilo mirovalo. 8 Zemljepisna dolžina (angl. longitude) Ljubljane je 14°30'30'' vzhodno od Greenwicha (E) oziroma 14,5083333

decimalnih stopinj. 9 Zemljepisna širina (angl. latitude) Ljubljane je 46°03'20'' severno od ekvatorja (N) oziroma 46,05555555

decimalnih stopinj.



103

pozicijo ista, intervaltk pa večji od 5 sekund, je vozilo stalo na poziciji toliko časa,

kolikor kaže vrednost intervaltk. Atributi tock, digital in keytk za našo obravnavo niso

pomembni.

3.5.5 Algoritem za avtomatizirano razporejanje ZZP z upoštevanjem

združevanja ZZP na isti relaciji (A_Z)

Naslednji algoritem, ki ga vpeljujemo, je algoritem za združevanje ZZP na isti relaciji

(A_Z). Povejmo, da ta algoritem vključuje funkcionalnosti predhodno opisanih

algoritmov A_SČP in A_DČP, saj se je razvil iz njiju. Kljub vsemu pa je njegova

bistvena značilnost, da skuša optimizirati stroške prevozov na podlagi združevanja

prevozov, ki se izvajajo na isti relaciji. Po algoritmu je v združevanje mogoče vključiti

le tiste ZZP, ki imajo določen fleksibilen čas odhoda (pomeni, da je želen čas odhoda

lahko nekoliko drugačen od navedenega in se uporabnik prevoza s tem strinja). Pri

združevanju prevozov namreč obstaja velika možnost, da bo čas odhoda, ki je naveden

v ZZP, poznejši od želenega. Katere ZZP upoštevati pri združitvi, pove atribut

voznja.flexCasOdhoda, ki določa, ali uporabnik dovoljuje časovno fleksibilnost pri

izvedbi njegovega ZZP ali ne, koliko ZZP dejansko združiti na isti relaciji, pa

spremljamo prek dveh vidikov:

• zmogljivosti vozila glede na to, koliko invalidskih vozičkov, skuterjev in hodečih

potnikov lahko namestimo v vozilo hkrati, ter

• lokacijske ustreznosti ZZP, ki ga skušamo dodati k že dodeljenim ZZP na isto

vozilo.

Glavna funkcionalnost tega algoritma je torej izvedba lokacijske ustreznosti ZZP, ki

ugotavlja, ali je neki ZZP ustrezen za pridružitev k že dodeljenim ZZP na podlagi

informacije o lokaciji ali ne. Potek algoritma A_Z lahko opišemo tako, kot je prikazano

na Slika 62, Slika 63 in Slika 64.



104

Slika 62: Algoritem A_Z 1/3



105




106


Ta algoritem je vsebinsko zelo podoben algoritmu A_DČP, zato ga ne bomo posebej

razčlenjevali. Poudariti je treba le mesto, kjer iščemo ZZP za združitev, pri čemer se

upošteva lokacijska ustreznost (Slika 64). Pričnemo z inicializacijo v algoritmu

deklarirane lokalne spremenljivke n in nadaljujemo z izborom ZZP, ki je kandidat za

razporeditev k vozilu. Pri tem smo tega kandidata označili v obliki ZZP(n), kar pri

vrednosti števca n=1 pomeni ZZP1. V tej iteraciji algoritem preveri, ali ima kandidat

ZZP1 določen fleksibilen čas odhoda. Če ne, preidemo nazaj na proces, označen s

številko 5, kjer izberemo naslednji ZZP s seznama še nerazporejenih. Če da, pa

izračunamo čas, ko bo voznik dosegljiv za naslednjo vožnjo. Tako algoritem preveri, ali

je Ti manjši ali enak voznikovi delovni obveznosti. Če ne, potem preidemo na proces,

označen s številko 6, kjer se preveri, ali obstajajo nova razpoložljiva vozila z vozniki.

Če da, potem se izračunajo zmogljivosti vozila. Če prostih zmogljivosti vozil ni, se spet



107

vrnemo na proces, označen s številko 6, sicer pa nadaljujemo z ugotavljanjem lokacijske

ustreznosti kandidata ZZP. Če lokacijska ustreznost ne obstaja (z logističnega vidika to

pomeni, da je bolj optimalno, da ta voznik tega ZZP ne opravi), se spet vrnemo na

proces, označen s številko 6, sicer pa ZZP dodelimo vozniku. Nato se ustrezno zmanjša

zmogljivost vozila in preidemo v naslednjo iteracijo.

Za realizacijo tega algoritma je na sedanjem IS treba uvesti:

• nov atribut voznja.flexCasOdhoda, ki določa, ali uporabnik dovoljuje časovno

fleksibilnost pri izvedbi njegovega ZZP. Atribut naj bo podatkovnega tipa

varchar(1);

• globalno spremenljivko gMaxCasOdstopanjeZZP, ki določa, za koliko minut lahko

čas odhoda odstopa od časa, določenega v ZZP, in bo mogoče ta ZZP izvesti skupaj

z drugim ZZP, ki se pelje na isti relaciji.

3.5.6 Algoritem za avtomatizirano razporejanje ZZP z upoštevanjem

optimizacije poti (A_OP)

Optimizacija poti je eden od načinov, s katerimi v logistiki skušamo znižati prevozne in

druge stroške. Glavni namen algoritmov iz prejšnjih poglavij je avtomatizirati

razporejanje ZZP. V tem poglavju pa bomo avtomatizirano razporejanje obogatili s

funkcionalnostjo optimizacije poti. Gre predvsem za to, da je voznik doslej imel le

podatka o kraju odhoda in kraju prihoda, ki ju je prebral na natisnjenem seznamu vseh

ZZP in ju je moral upoštevati pri opravljanju svojih delovnih dolžnosti. Algoritem za

optimizacijo poti, opisan v tem poglavju, pa kot rezultat poleg avtomatiziranega

razporejanja vrne tudi seznam optimizirane poti, po kateri naj bi voznik peljal. Ta je

določena z dvema izključujočima se optimizacijskima meriloma, pri čemer:

• voznik prevozi najkrajšo mogočo razdaljo (vendar porabi več časa) ali

• voznik za prevoženo razdaljo porabi manj časa (vendar prevozi daljšo razdaljo).

Tako lahko rečemo, da obakrat izvajamo optimizacijo poti, pri čemer v prvem primeru

stremimo k čim manj prevoženim kilometrom, v drugem pa k čim manj porabljenega

časa. OP pa mora preizkusiti obe možnosti in se odločiti za tisto, ki po je njegovi presoji

najboljša.



108

Za namen optimizacije poti si bomo pomagali z Googlovo brezplačno10 storitvijo,

imenovano "Google Directions API" (več informacij o njej je mogoče dobiti na naslovu

https://developers.google.com/maps/documentation/directions/), ki na podlagi poslane

HTTP-zahteve in v njej ustrezno zapisanih parametrov kot rezultat vrne pot med

želenima lokacijama. Rezultat, ki ga HTTP-zahteva vrne, je lahko v dveh oblikah, in

sicer v obliki JSON (angl. JavaScript Object Notation) ali v obliki razširljivega

označevalnega jezika XML (angl. Extensible Markup Language). Neodvisno od oblike

zapisa rezultata pa je v rezultatu zapisana pot, po kateri mora voznik peljati. Zaradi

enotne obravnave pri razčlenjevanju in nadaljnji obdelavi rezultata v sedanjem IS se

bomo odločili za obliko zapisa v formatu XML.

Pred opisom poteka algoritma A_OP si poglejmo nekaj osnovnih lastnosti storitve

Google Directions API. HTTP-zahtevo pošljemo na strežnik Google s spletnim

brskalnikom, in sicer tako, da ga usmerimo na povezavo:

http://maps.googleapis.com/maps/api/directions/output?parameters.

Na koncu te povezave sta dva pomembna dela, in sicer:

• output – pove obliko zapisa rezultata (mogoči vrednosti sta json ali xml);

• parameters – različni parametri, ki specificirajo iskalno zahtevo. Ti so med seboj

ločeni z znakom & pred vrednostjo parametra pa stoji znak =. Več parametrov in

njihovih vrednosti bi povezali v skupen niz tako:

parameter1=vrednost1&parameter2=vrednost2&parameter3=vrednost3.

V tem delu bomo opisali le parametre, ki jih bomo potrebovali. Prikažimo to na

konkretnem primeru; domnevajmo, da iščemo vse mogoče poti (neodvisno od prej

navedenega optimizacijskega merila) med Fakulteto za računalništvo in informatiko,

Tržaška 25, 1000 Ljubljana (lokacija A) in Univerzo v Ljubljani, Kongresni trg 12,

1000 Ljubljana (lokacija B). Najprej moramo pridobiti podatek o zemljepisni širini in

dolžini obeh lokacij. Za lokacijo A sta to 46,045848 in 14,48944, za lokacijo B pa

46,049974 in 14,504117. Poudarimo, da podatke o zemljepisni širini in dolžini lokacij

pridobimo iz šifranta ulic, ki smo ga že opisali v prejšnjih poglavjih. Prav tako je 10 Brezplačna različica Google Directions API ima kar nekaj funkcionalnih omejitev: do 2500 poizvedb na dan,

uporaba do največ osem vmesnih točk. Omejeni pa smo z največjo dolžino URL-naslova (2048 znakov).



109

pomembno, da je ta podatek zapisan v decimalnih in ne kotnih stopinjah ter da

decimalno vejico, zaradi pravilne sintakse, nadomestimo s piko. Z vejico namreč ločimo

koordinati točke (lokacije) med seboj. HTTP-zahteva z vnesenimi lokacijskimi

informacijami je sedaj takšna:

http://maps.googleapis.com/maps/api/directions/xml?origin=46.045848,14.48944&desti

nation=46.049974,14.504117.

K temu pa moramo dodati še dva parametra, in sicer:

• alternatives – če je ta vrednost true, storitev vrne vse mogoče poti med lokacijama;

v našem primeru je ta parameter vedno true;

• sensor – označuje, ali zahteva prihaja iz naprave, ki vsebuje lokacijski senzor

(mobilna naprava ipd.); v našem primeru je ta parameter vedno false.

HTTP-zahteva z vsemi za naš primer uporabnimi informacijami je tako:

http://maps.googleapis.com/maps/api/directions/xml?origin=46.045625,14.489366&des

tination=46.049974,14.504117&alternatives=true&sensor=false.

Ko pošljemo to zahtevo na Googleov strežnik, nam ta v spletni brskalnik vrne rezultat

poizvedbe, ki ga moramo za nadaljnjo uporabo še ustrezno računalniško razčleniti (angl.

parse). Rezultat v XML-obliki za obravnavano poizvedbo je zelo dolg, zato njegovo

celotno vsebino navajamo le v prilogi. Nakažemo pa lahko pomembnejše dele te

datoteke s primerom, ki vrne krajši rezultat. Prva vrstica dobljenega rezultata deklarira

XML-datoteko (verzijo XML in kodiranje znakov z atributom encoding). Vrstica 2

odpre oznako (angl. tag) DirectionsResponse, ki se zapre v zadnji, 64. vrstici. Tretja

vrstica z oznako status govori o statusu poizvedbe. Mogoči statusi so:

• OK – poizvedba je vrnila pravilen rezultat;

• NOT_FOUND – vsaj enega od parametrov (origin, destination, or waypoints) ni

bilo mogoče lokacijsko opredeliti;

• ZERO_RESULTS – poti ni bilo mogoče najti glede na podano začetno in končno

lokacijo;

• MAX_WAYPOINTS_EXCEEDED – število vmesnih točk je preseglo limito

osmih točk;

• INVALID_REQUEST – napačna zahteva;



110

• OVER_QUERY_LIMIT – preseženo število zahtev, prejetih v določenem

časovnem obdobju;

• REQUEST_DENIED – servis je prepovedal uporabo storitve;

• UNKNOWN_ERROR – zahteve ni bilo mogoče sprocesirati zaradi napake na

strežniku.

Oznaka route se odpre v vrstici 4 in zapre v vrstici 63 ter v nadaljnjih vrsticah

opredeljuje pot. Za nas pomembna je tudi vrstica 5, ki z nekaj besedami opiše samo pot.

Deveta in trinajsta vrstica vsebujeta podatek o zemljepisni širini in dolžini začetne in

končne točke. Vrstica 21 pove trajanje poti v sekundah, 22. pa v minutah (zaokroženo

navzgor). Vrstica 24 opisno poda navodilo za izvedbo tega dela poti, o prevoženi

razdalji pa govorita vrstici 26 (izraženo v metrih) in vrstica 27 (v kilometrih). Vsi

navedeni podatki so v oznaki step, ki se začne v 7. in konča v 29. vrstici. Če bi bilo

navodil za pot več, bi bilo v skladu s tem več tudi oznak step. Ker teh v našem primeru

ni, se od 30. do 45. vrstice izpišejo sumarni podatki o celotni poti (seštejejo se

prevožena pot in potreben čas iz vseh oznak step). Vrstici 46 in 47 povesta začetni in

končni naslov, sledijo pa še informacije o avtorskih pravicah storitve ter drugih

področjih, ki za našo obravnavo niso toliko pomembne. Rezultat v XML navajamo

tukaj:

1<?xml version="1.0" encoding="UTF-8"?> 2 <DirectionsResponse> 3 <status>OK</status> 4 <route> 5 <summary>Kersnikova ulica</summary> 6 <leg> 7 <step> 8 <travel_mode>DRIVING</travel_mode> 9 <start_location> 10 <lat>46.0554100</lat> 11 <lng>14.5036900</lng> 12 </start_location> 13 <end_location> 14 <lat>46.0569700</lat> 15 <lng>14.5044300</lng> 16 </end_location> 17 <polyline> 18 <points>iebxGawowAy</points> 19 </polyline>



111

20 <duration> 21 <value>33</value> 22 <text>1 min</text> 23 </duration> 24 <html_instructions>Pojdite v smeri…</html_instructions> 25 <distance> 26 <value>183</value> 27 <text>0,2 km</text> 28 </distance> 29 </step> 30 <duration> 31 <value>33</value> 32 <text>1 min</text> 33 </duration> 34 <distance> 35 <value>183</value> 36 <text>0,2 km</text> 37 </distance> 38 <start_location> 39 <lat>46.0554100</lat> 40 <lng>14.5036900</lng> 41 </start_location> 42 <end_location> 43 <lat>46.0569700</lat> 44 <lng>14.5044300</lng> 45 </end_location> 46 <start_address>Kersnikova ulica 2-10, 1000 Ljubljana, Slovenija</start_address> 47 <end_address>Kersnikova ulica 12, 1000 Ljubljana, Slovenija</end_address> 48 </leg> 49 <copyrights>Podatki na zemljevidu ©2012 Tele Atlas</copyrights> 50 <overview_polyline> 51 <points>iebxGawowAwHsC</points> 52 </overview_polyline> 53 <bounds> 54 <southwest> 55 <lat>46.0554100</lat> 56 <lng>14.5036900</lng> 57 </southwest> 58 <northeast> 59 <lat>46.0569700</lat> 60 <lng>14.5044300</lng> 61 </northeast> 62 </bounds> 63 </route> 64 </DirectionsResponse>



112

Ko smo tako na kratko opisali delovanje in uporabo Googlove storitve Google

Directions API, lahko nadaljujemo z opisom algoritma za optimizacijo poti (A_OP).

Glavni koraki algoritma sledijo zaporedju, ki ga prikazujeta Slika 65 in Slika 66.

Algoritem A_OP se je razvil iz algoritma A_DČP, zato vsebuje veliko podobnih

procesov in jih pri razčlenjevanju ne bomo ponavljali. Podrobneje pa moramo

predstaviti način izračunavanja časovnih parametrov, čeprav so nekateri deli pri

izračunu časovnih parametrov v tem algoritmu podobni predhodnim. Ker je bralec že

seznanjen z vsebino predhodnih algoritmov, bomo izpostavili le ključne dopolnitve, ki

jih ima algoritem A_OP.

Pri izračunu časa t1 (Slika 67) je bistvena sprememba v uporabi Googleove storitve. Tu

se najprej generira HTTP-zahteva, ki mora biti v skladu s specifikacijo Google

Directions API in se v ozadju, skrito uporabniku, izvede v spletnem brskalniku. Vrnjeni

rezultat algoritem obdela tako, da izlušči podatke o najbolj optimalni poti, prevoženih

kilometrih in času, ki se bo za to vožnjo predvidoma porabil. Nato OP izbere način

optimizacije. Mogoča sta optimizacija poti (opravimo manjšo razdaljo) ali optimizacija

časa (porabimo manj časa), v kateri se pot opravi. Če OP izbere optimizacijo glede na

pot, se upošteva pot, pri kateri je najmanj skupno prevoženih kilometrov, oziroma, če

OP izbere optimizacijo časa, se upošteva pot z najkrajšim skupnim časom za prevoz od

začetne do končne točke. Oba postopka nas privedeta do želenega časa t1.

Izračun časa t2 po algoritmu A_OP, kot ga prikazuje Slika 68, je identičen izračunu,

opisanemu v algoritmu A_DČP, zato ga pri podrobnem opisu tukaj izpustimo. Enako

velja za izračun časa t3 in t4.



113

Slika 65: Algoritem A_OP 1/2



114

Slika 66: Algoritem A_OP 2/2



115

Slika 67: Algoritem A_OP (izračun časa t1)



116




117





118


Tudi izračun časa t5 po algoritmu A_OP je podoben algoritmu, opisanemu pri A_DČP,

vendar ne v celoti. Bistvena pri tokratnem algoritmu sta določitev točke A in B (za obe

namreč potrebujemo zemljepisne koordinate za kraj odhoda in kraj prihoda iz šifranta

ulic) ter generiranje HTTP-zahteve v skladu s specifikacijo Google Directions API.

Nadaljnji postopek za izračun časa t5 je enak izračunu časa t1 pri algoritmu A_OP.

Izračun časa t5 po algoritmu A_OP prikazuje Slika 71.

Izračun časa t6 in t7 pa sta analogna izračunom časov t6 in t7 pri algoritmu A_DČP,

zato ju tu ne opisujemo podrobneje.



119



S tem algoritmom in s storitvijo Google Directions API za vsak ZZP, ki ga algoritem

razporeja, dobimo seznam ZZP, ki je optimiziran glede na pot ali čas. Poleg tega

pridobimo tudi natančna navodila za samo izvedbo poti. Ta podatek je pomemben, saj

ga je pri nadaljnjih posodobitvah sistema mogoče koristno uporabiti za podajanje

informacij in natančnih navodil vozniku o priporočenih poteh vožnje. Tako bo imel

voznik možnost, da se tudi v realnem svetu (vožnja na terenu) čim bolj približa z

algoritmom izračunanim časovnim parametrom. Treba se je namreč zavedati, da



120

predlagana optimalna pot ni vedno tudi najboljša z vidika kakovosti izvajanja storitve

prevozov, saj so lahko posamezni predlagani cestni odseki slabše vzdrževani, kar

uporabniku prevoza ne zagotavlja ustreznega udobja. Velja tudi, da so različni cestni

odseki obremenjeni različno v različnih delih dneva, zato se kaj lahko zgodi, da

predlagana pot z vidika poti ali časa ni najbolj optimalna. Ugotovimo lahko tudi, da

krajša pot ne pomeni vedno tudi krajšega časa, v katerem se ZZP opravi. Seveda pa drži

tudi nasprotno, da lahko krajši čas pomeni tudi daljšo opravljeno pot (na primer čas,

potreben za prevoz po obvoznici, je krajši kot po lokalni cesti, a pomeni daljšo

prevoženo pot). Iz navedenega lahko ugotovimo, da se pot in čas v našem primeru

medsebojno izključujeta. Zato s tem algoritmom optimiziramo le na podlagi ene

komponente hkrati, torej glede na pot ali čas. Drži pa, da lahko na podlagi ugotavljanja

časa trajanja poti bolje predvidimo čas za izvedbo celotnega ZZP, predvsem pa s tem

upoštevamo in sproti spremljamo tudi obremenjenost voznikov. Kot smo videli, je

pomen tega algoritma dvojen; bolj realna določitev skupnega časa Ti vsakega ZZP na

podlagi določitve časa vožnje (čas t1 in t5) s storitvijo Google Directions API ter

razporeditev ZZP k ustreznemu (razpoložljivemu) vozniku, pri čemer razpolagamo s

celovito informacijo o navodilih za izvedbo posamezne poti.



121

4 ANALIZA

V tem magistrskem delu smo na podlagi predlogov za posodobitev informacijskega

sistema za optimizacijo organizacije prevozov v invalidski organizaciji izdelali nabor

izboljšav, ki zadevajo aplikacijski in podatkovni del IS. Posodobitve obeh delov se

prepletajo, zato je ločnico med njimi težko določiti. Kljub vsemu gre na eni strani za

posodobitev GUI in funkcionalnosti, ki jih ta vsebuje, na drugi strani pa za posodobitve

na ravni podatkovne baze in postopkov ravnanja s podatki.

Temeljne posodobitve sedanjega IS v invalidski organizaciji lahko strnemo v pet

algoritmov. Naloga prvega, tako imenovanega inicializacijskega algoritma je

vzpostavitev postopkov na ravni podatkovne baze, ki omogočijo pogoje za nadaljnjo

avtomatizirano razporejanje ZZP. Bistvena prednost tega algoritma je samostojna

določitev pravil o rotaciji voznikov za vožnje po Sloveniji in tujini, določitev pravil o

rotaciji vozil za vožnje v tujini, določitev pravil o izmenskem delu voznikov ter

opredelitev kvartarnih geografskih območij. Naloga tega algoritma je tudi, da spremni

statuse tistim ZZP, ki so zastareli in se pri nadaljnjih postopkih razporejanja ne

upoštevajo. Ko so vzpostavljeni ti inicializacijski pogoji, je mogoče nadaljevati s

preostalimi štirimi algoritmi, ki so namenjeni predvsem olajšanju dela in skrajšanju

časa, ki ga OP porabi za razporejanje ZZP. Prednosti navedenih algoritmov vidimo

ravno v tem, da vzpostavimo pogoje na ravni IS, ki omogočajo samostojno izvajanje

avtomatiziranega razporejanja ZZP v nadaljevanju. Vse to je mogoče ob deklaraciji

novih globalnih spremenljivk, novih podatkovnih tabel in novih atributov v sedanjih

tabelah IS.

Algoritem za avtomatizirano razporejanje ZZP z upoštevanjem statično določenih

časovnih parametrov (A_SČP) je prvi izmed algoritmov, ki se vsebinsko loti obravnave

problema avtomatiziranega razporejanja ZZP. Z njim opredelimo pojem statičnih

časovnih parametrov, ki dejansko pomenijo časovne intervale v procesu prevoza

invalida. Z uporabo teh statičnih časovnih parametrov lahko algoritem sam izračunava

čas trajanja za izvedbo posameznega ZZP in na podlagi tega izvaja specifične kontrole

glede razpoložljivosti voznika, upošteva pa tudi porabo virov oziroma zmogljivosti v

vozilu. Poleg tega algoritem uvaja preverjanje pogojev izogibanja voznikov,



122

uporabnikov in vozil, kar pomeni še dodatno funkcionalnost pri izbiri voznika in vozila

v fazi razporejanja ZZP k vozniku. Upoštevata se tudi obveznost odmora voznika v

delovnem času in njegova delovna obveznost, ki se razlikuje po posameznih voznikih.

Algoritem za avtomatizirano razporejanje ZZP z upoštevanjem dinamično določenih

časovnih parametrov (A_DČP) je drugi algoritem, ki vsebinsko obravnava problem

avtomatiziranega razporejanja ZZP. Ta algoritem je nadgradnja algoritma A_SČP in

vsebuje tudi mnogo njegovih procesov, ki se v algoritmu A_DČP ponovijo. Bistvena

prednost algoritma A_DČP pa je uvedba dinamičnih časovnih parametrov. Ti se

večinoma izračunavajo z analizo statistik opravljenih prevozov iz preteklosti, ki

potekajo na istih relacijah z istimi uporabniki prevozov. Kljub vsemu se nekaterih

časovnih parametrov s statističnimi metodami ne da izračunati, saj strojna oprema,

nameščena v vozilih, ki meri različne podatke in polni tabelo o zgodovini opravljenih

prevozov, ne omogoča merjenja nekaterih specifičnih podatkov, ki bi jih potrebovali za

izračun vseh dinamičnih časovnih parametrov. Uvaja tudi lastnost dominantnosti

lokalno določenih časovnih parametrov nad globalno določenimi.

Algoritem za avtomatizirano razporejanje ZZP z upoštevanjem združevanja ZZP na isti

relaciji (A_Z) je prav tako nadgradnja predhodnega algoritma A_DČP. Njegova

prednost je združevanje ZZP na istih relacijah. Bistveno merilo za določanje tega je

ugotavljanje lokacijske ustreznosti posameznega ZZP pred njegovo dejansko

razporeditvijo vozniku. Seveda pa se tudi tukaj upoštevajo zmogljivosti vozila glede na

to, koliko invalidskih vozičkov, skuterjev in hodečih potnikov lahko namestimo v

vozilo hkrati, upoštevata se tudi voznikova delovna obveznost in največji čas odstopanja

združenega ZZP.

Algoritem za avtomatizirano razporejanje ZZP z upoštevanjem optimizacije poti

(A_OP) je zadnji v nizu algoritmov, ki jih uvajamo v tem delu. Njegova bistvena

prednost je uporaba brezplačne Googleove storitve, imenovane "Google Directions

API", ki z lastnimi optimizacijskimi postopki izračuna najbolj optimalno pot med

dvema točkama. Optimizacijsko merilo (pot ali čas) določi OP. S tem algoritmom

dobimo tudi spisek poti, ki jih mora voznik opraviti, da ustreza merilu optimalnosti.



123

ZAKLJU ČEK

Ocena učinkov

Sedanji IS v invalidski organizaciji ne ponuja dodatnih storitev, ki bi OP omogočale

laže in hitrejše delo v fazi razporejanja ZZP. Kot smo že omenili, je sedanji IS le

pomožno orodje za zajem množice podatkov. Dejstvo je, da OP porabi razmeroma

veliko časa že za vnos ZZP v sistem. Preprosta poizvedba v sedanji podatkovni bazi

nam pove, da OP v povprečju porabi 57 sekund za vnos enega ZZP v IS, medtem ko za

spreminjanje podatkov ZZP pred njegovo razporeditvijo na listek ABCD v povprečju

porabi 10 sekund. Koliko časa OP porabi za razporejanje enega ZZP, ki zahteva največ

miselnega napora, ni znano. Prav tako ni znano, koliko časa OP porabi za razporejanje

voznikov in vozil. Vseeno pa lahko na podlagi spremljanja uporabe sedanjega IS v

praksi trdimo, da v povprečju OP potrebuje najmanj toliko časa za razvrstitev ZZP na

ustrezen listek ABCD kot za sam vnos ZZP v IS. Tako ugotovimo, da OP porabi veliko

časa in energije v fazi razporejanja ZZP, saj ta proces od njega zahteva razmeroma

veliko angažiranost (poleg upoštevanja časa in optimalne poti mora OP pri razporejanju

upoštevati še veliko meril, opisanih v poglavju 2.17.6). Posodobljeni IS pa v celoti

prevzame nalogo razporejanja voznikov in vozil ter ZZP. To pomeni, da mora OP le še

nadzirati IS, torej je njegova obveznost le še nadzor nad obdelanimi podatki. To

pravzaprav pomeni prehod funkcije OP iz upravljalske v nadzorno. Bistveni učinki

posodobljenega IS so tako:

• pospešitev procesa razporejanja voznikov in vozil;

• pospešitev procesa razporejanja ZZP, ki ga IS izvede v nekaj milisekundah;

• razbremenitev OP pri razporejanju voznikov, vozil in ZZP;

• funkcija OP preide iz upravljalske v nadzorno;

• večja podatkovna povezanost IS med posameznimi podsistemi (PrevoziDDS in

PortalDDS);

• večja kompatibilnost posodobljenega IS s prihodnjimi storitvami, ki omogočajo

mobilno poslovanje (aplikacija iPrevoziDDS in dvosmerna SMS-komunikacija z

IS).



124

Pogoji za uvedbo rešitve

Niz posodobitev, kot jih navajamo v tem magistrskem delu, lahko obravnavamo tudi iz

vidika pogojev, ki so potrebni za realizacijo rešitev. Glede človeških virov ocenjujemo,

da sta za izvedbo posodobitve potrebna dva razvojna inženirja oziroma razvijalca

programske opreme. Prvi bi bil zadolžen za razvoj, implementacijo in testiranje novih

rešitev na aplikativni in podatkovni ravni. Drugi pa bi skrbel za vzdrževanje sedanjega

in pozneje novega IS. Za razvoj invalidska organizacija ne potrebuje drugih tehničnih

sredstev kot primerno razvojno okolje za navedena inženirja z ustrezno strojno in

programsko opremo. Upoštevati pa je treba tudi finančna sredstva za financiranje

razvijalcev. Ta so za realizacijo rešitve lahko bistveno nižja, če se predlagana

posodobitev IS izvede z že obstoječimi človeškimi viri, ne pa z zunanjimi izvajalci.

Možnosti za nadaljnji razvoj

Statistike v podatkovni bazi sedanjega IS kažejo, da se trend oddanih ZZP vztrajno

dviguje. Tako se bodo kmalu pokazale potrebe, da se sedanji posebni socialni program

'prevoz distrofikov' razširi tako z organizacijskega in kadrovskega vidika kot z vidika

informacijskih tehnologij. Zato je pomembno o morebitni vsebinski reorganizaciji in

posodobitvah tega posebnega socialnega programa intenzivno razmišljati že sedaj. Z

vidika informacijskih tehnologij to nedvomno pomeni vlaganje v nadaljnji razvoj IS. Z

rešitvami, predstavljenimi v prejšnjih poglavjih, se razvojni cikel IS za optimizacijo

organizacije prevozov v invalidski organizaciji nikakor ne konča. Prinašajo namreč le

prehod na višjo stopnjo informatizacije. Nakažimo pet signifikantnih vsebinskih

dopolnil IS, ki jih bo v prihodnosti treba še implementirati.

Razvoj mobilne aplikacije iPrevoziDDS

Voznik mora imeti možnost, da z uporabo ustrezne terminalne opreme in mobilne

aplikacije iPrevoziDDS sam izvaja interakcijo z IS. Ključne funkcionalnosti mobilne

aplikacije iPrevoziDDS morajo biti enostavne za uporabo ter morajo zajemati:

• identifikacijo uporabnika v IS (prijava v sistem in odjava iz njega);

• povezavo z matičnim IS prek mobilnega omrežja z uporabo varne kriptirane

povezave;



125

• zmožnost delovanja tudi v območju brez mobilnega signala (začasno shranjevanje

podatkov na lokalni pomnilnik terminalne opreme);

• samodejno sinhronizacijo podatkov ob ponovnem vstopu na območje, pokrito z

mobilnim signalom;

• možnost voznika, da prekliče njemu dodeljeni ZZP (če uporabnik prevoza vozniku

po telefonu sporoči preklic ZZP, in to v času, ko Služba prevozov ne deluje –

popoldan, vikendi in drugi dela prosti dnevi);

• voznikovo potrjevanje opravljenih prevozov (Voznik s čitalcem črtnih kod prebere

kodo uporabnika prevozov, ki mu jo ta na članski izkaznici pokaže na koncu vožnje

in s tem evidentira, da je bil prevoz opravljen. Prek mobilnega omrežja se ti podatki

prenesejo v podatkovno bazo IS.);

• vnos novih ZZP (Če uporabnik prevoza ali OP nista oddala ZZP v IS, voznik pa je

moral vožnjo kljub temu opraviti (višja sila), mora imeti voznik možnost, da prek

mobilne aplikacije vnese ZZP v sistem. Potrditev izvedbe takega ZZP pa lahko

opravita OP z aplikacijo PrevoziDDS ali uporabnik prevoza s spletno aplikacijo

PortalDDS, z dvosmerno SMS-komunikacijo ali z mobilno aplikacijo

iPrevoziDDS.);

• možnost odpovedi nekaterih ali vseh vozniku že razporejenih ZZP zaradi

nepredvidenih situacij in njihovo takojšnjo prerazporeditev razpoložljivemu

vozniku (Na koncu faze razporejanja ZZP lahko voznik zaradi nepredvidenih

situacij, kot so nenadna okvara vozila, bolniška odsotnost voznika, ipd., ugotovi, da

voženj ne bo mogel opraviti. Takrat mora imeti možnost, da to z uporabo mobilne

aplikacije iPrevoziDDS ustrezno sporoči IS in razlog tudi navede. Sistem mora v

teh primerih znati že razporejene in hkrati odpovedane ZZP postaviti v čakalno

vrsto ter jih samodejno prerazporediti med preostale razpoložljive voznike oziroma

znati mora angažirati tudi dodatne zmogljivosti. V tem primeru IS vozniku pošlje

SMS-obvestilo ali posreduje obvestilo v aplikacijo iPrevoziDDS, hkrati pa mora o

morebitnih zamudah obvestiti uporabnike prevozov.);

• zagotovitev sledljivosti dogodkov nad ZZP v IS.

Vzpostavitev podsistema enotne članske evidence (ClaniDDS)

Treba je vzpostaviti enotno člansko evidenco rednih in podpornih članov društva ter jih

ustrezno povezati z obstoječimi deli informacijskega sistema. Funkcionalnosti tega



126

vmesnika morajo zajemati vpoglede v reševanje vlog (Socialna služba …), eVlog,

prijav na obnovitveno rehabilitacijo ipd. Vsebinsko se ta podsistem neposredno ne

dotika vprašanja logistike, a je pomemben vezni člen med obstoječimi deli IS in ga je

treba pri nadaljnjem razvoju upoštevati, saj spremembe v članski evidenci vplivajo tudi

na spremembe v drugih podsistemih (na primer vpis novega člana v invalidsko

organizacijo in podsistem ClaniDDS samodejno pomeni dodelitev uporabniških

podatkov za uporabo spletnega portala PoralDDS, izpis člana iz invalidske organizacije

pa pomeni onemogočanje uporabe vseh informacijskih in drugih storitev člana …).

Uvedba dinamičnih ZZP

Zaradi vedno večje stopnje avtomatiziranega načina delovanja IS brez interakcije OP se

bistveno spremeni vloga ZZP. Ti so v sedanjem IS obravnavani kot statični ZZP, saj jih

fiksno opredeljujeta časovna (datum in čas odhoda) in geografska komponenta (kraj

odhoda in prihoda). Tako imajo ZZP opredeljen življenjski cikel, ki se začne z rojstvom

ob oddaji ZZP v IS (dobi status 'čaka na potrditev') in konča s smrtjo (dobi status

'potrjen v celoti', 'preklican s strani Službe prevozov' ali 'preklican s strani uporabnika').

V slednjem primeru statusa ZZP ni mogoče več spremeniti nazaj v status 'čaka na

potrditev'. Zato govorimo o statičnih ZZP. Kaže pa se potreba po spremembi

življenjskega cikla ZZP in vpeljavi dinamičnih ZZP. Ko mora IS sam spreminjati

statuse glede na situacijo iz okolja (informacije dobiva z aplikacijo iPrevoziDDS) in

dogajanje v IS, govorimo o dinamičnih ZZP. Življenjska doba dinamičnega ZZP se tako

lahko večkrat spremeni iz 'potrjen v celoti' nazaj v 'čaka na potrditev' in življenjsko

dobo konča šele, ko je ZZP potrjen in evidentiran kot dejansko opravljena vožnja.

Vzpostavitev dvosmerne SMS-komunikacije z IS

Za uspešno komunikacijo med uporabnikom prevozov in IS invalidske organizacije,

brez uporabe interneta ali klica v Službo prevozov, je treba vzpostaviti dvosmerno

komunikacijo prek sistema kratkih besedilnih sporočil SMS, ki mora vključevati

naslednje funkcionalnosti:

• preverjanje konsistentnosti SMS-sporočil (poslana morajo biti v predpisani obliki);

• obveščanje uporabnikov o nujnih vzdrževalnih delih na sistemu;

• možnost člana, da naredi poizvedbo o stanju in statusu ZZP za želeni datum;

• možnost člana, da vnese nov ZZP v IS;



127

• možnost člana, da prekliče enega ali več ZZP hkrati;

• možnost člana, da potrdi dejansko opravljene ZZP;

• obveščanje člana v realnem času (na primer pet minut pred prihodom vozila, ob

prihodu vozila …).

Uvedba več enot Službe prevozov

Obstoječi IS omogoča, da OP organizira in upravlja prevoze le v okviru ene enote

Službe prevozov, ki je trenutno locirana v Ljubljani in je logistično tudi najbolj

intenzivna. Ker pa ima invalidska organizacija tudi enoti v Mariboru in Izoli, se kaže

potreba po njuni vključitvi v enoten IS. Sedaj OP, ki pripada eni enoti Službe prevozov,

ne more razporejati voznikov, jim dodeljevati vozil, vnašati novih in urejati obstoječih

ZZP ali izvajati drugih dejavnosti v sistemu tudi v okviru druge Službe prevozov. To pa

je pomembno, če želimo informatizirati še druge Službe prevozov po Sloveniji.

Zaklju čne ugotovitve

Magistrsko delo obravnava niz posodobitev sedanjega informacijskega sistema v

invalidski organizaciji, ki se ukvarja z organizacijo prevozov. V okviru posodobitev se

predlagajo ključni algoritmi, s katerimi bo posodobljen IS čim bolj samostojno izvajal

eno izmed najpomembnejših operacij, to je avtomatizirano razporejanje ZZP ustreznim

vozilom in voznikom. Ta postopek se izvede z enim inicializacijskim in štirimi

vsebinsko usmerjenimi algoritmi, od katerih vsak zase rešuje problem avtomatiziranega

razporejanja ZZP ob upoštevanju specifičnih pogojev. S temi algoritmi smo izdelali

sistem za podporo odločanju, katerega končni rezultat je seznam ustrezno razporejenih

ZZP. Izvedba teh rešitev v sedanjem IS nedvomno razbremeni OP v fazi razporejanja

ZZP, pri čemer ni več intuitivnega načina razporejanja, ampak to sloni na vnaprej

opredeljenih pogojih (omejitvah) na eni in razpoložljivih virih na drugi strani. To je

bistvena prednost vseh predlaganih rešitev in vodi k naprednejšemu informacijskemu

sistemu v invalidski organizaciji.

Poudariti moramo, da smo se med preučevanjem mogočih rešitev za posodobitev

informacijskega sistema srečevali z mnogimi preprekami. Na eni strani je šlo za

ugotavljanje ustreznosti izvedbe zastavljene rešitve, ki bi čim bolj temeljila na



128

matematičnih predpostavkah v kontekstu optimizacije poti, časa ali drugih komponent.

Pri takšnih situacijah smo zaradi kompleksnosti problemov pogosto zašli na področje

reševanja NP-polnih problemov. Zato se je kot ena izmed možnosti ponujala uporaba

metahevrističnih metod. Ker bi za reševanje takšnih optimizacijskih problemov

potrebovali več informacij o vožnjah, kot jih ponujajo v vozilih nameščene GPS-

naprave, se za nadaljnji razvoj in uporabo navedenih metod v sedanjih posodobitvah

nismo odločili. Glavna omejitev torej izhaja iz sedanjih virov informacij, ki jih je bilo

mogoče izmeriti in pridobiti iz meritev. Zato smo se odločili za trivialnejši pristop

reševanja problema, pri katerem smo kot podlago uporabili sistem za podporo

odločanju.

Če povzamemo ugotovitve, smo s tem delom naredili podrobnejši opis sedanjega stanja

IS za organizacijo prevozov v invalidski organizaciji, hkrati pa izdelali specifikacijo

predlaganih posodobitev na sedanjem informacijskem sistemu ob upoštevanju vseh

internih pravil invalidske organizacije pri razporejanju ZZP. S specifikacijo smo

pokazali, da je v začrtani smeri mogoče dejansko uresničiti predlagane posodobitve

informacijskega sistema.



129

LITERATURA IN VIRI

Drozdek, A. (2005). Data structures and algorithms in Java. Boston: Thomson

Learning.

Društvo distrofikov Slovenije [O društvu], (b. d.). Najdeno 20. februarja 2012 na

spletnem naslovu http://www.drustvo-distrofikov.si/index.php/o-drustvu

Goodaire, E. G. & Parmenter, M. M. (2006). Discrete mathematics with graph theory.

New York: Pearson Prentice Hall.

GUI aplikacije PrevoziDDS [PrevoziDDS], (b. d.).

GUI spletne aplikacije PortalDDS [PortalDDS], (b. d.).

Kononenko, I. & Robnik Šikonja, M. (2003). Algoritmi in podatkovne strukture I.

Ljubljana: Založba FE in FRI.

Kramberger, T. (2010). Problem kitajskega poštarja s prioritetnimi vozišči. Doktorska

disertacija. Maribor: FERI.

Neznani avtor (2012). The Google Directions API. Najdeno 10. avgusta 2012 na

spletnem naslovu https://developers.google.com/maps/documentation/directions/

Primer pritrdilnih mehanizmov [Sumaprojekt d. o. o.] , (b. d.). Najdeno 15. maja 2012

na spletnem naslovu http://www.predelave-vozil.si/index.php/dodelave-za-

prevoz-invalidnih-oseb/pritrdilne-letve

Pripomočki [Ortosana d.o.o.], (b.d.). Najdeno 15. maja 2012 na spletnem naslovu

http://www.ortosana.si/si/ponudba/pripomocki/za_hojo/

Sánchez-Torrubia, G., Torres-Blanc, C., Giménez-Martínez, V. (2007). Interactive Java

tutorial for E&B-learning Fleury’s algorithm. Zbornik druge mednarodne

konference “Modern (e-) Learning” (str. 85–89). Sofia: Institute of Information

Theories and Applications.

Skuter [Ortosana d.o.o.], (b. d.). Najdeno 15. maja 2012 na spletnem naslovu

http://www.ortosana.si/si/ponudba/elektricni_skuterji/

Tiskan izvod listka ABCD [PrevoziDDS], (b. d.).

Voziček elektromotorni [Ortosana d.o.o.], (b. d.). Najdeno 15. maja 2012 na spletnem

naslovu http://www.ortosana.si/si/ponudba/invalidski_vozicki/elektromotorni

_vozicki/164

Voziček navadni [Ortosana d.o.o.], (b. d.). Najdeno 15. maja 2012 na spletnem naslovu

http://www.ortosana.si/si/ponudba/vozicki_na_rocni_pogon_lahki/

PRILOGE

KAZALO PRILOG

PRILOGA 1: POTNI NALOG ZA PREVOZ OSEB.................................................................... 1

PRILOGA 2: VSEBINA PODATKOVNE TABELE SIFRANT_SIFRANTOV PRED

POSODOBITVIJO IS ................................................................................................................... 2

PRILOGA 3: VSEBINA PODATKOVNE TABELE SIFRANT PRED POSODOBITVIJO IS . 3

PRILOGA 4: REZULTAT STORITVE GOOGLE DIRECTIONS API V XML OBLIKI .......... 6

1

Priloga 1: Potni nalog za prevoz oseb

2

Priloga 2: Vsebina podatkovne tabele sifrant_sifrantov pred posodobitvijo IS

ID: Naziv:

1 statusi prevozov

2 poštne številke

3 kraji

4 države

5 način oddaje prevoza

6 termini dela

7 enota Službe prevozov

8 statusi SMS-jev

9 statusi članov

10 vrsta goriva

11 pravica menija

12 vrsta stroška (vnaša FRS)

13 vrsta stroška (vnaša Služba prevozov)

14 študijsko leto

15 opcije pri novoletnih koledarjih

16 vrsta pošiljke

17 statusi naročil koledarjev

18 nameni prevozov

3

Priloga 3: Vsebina podatkovne tabele sifrant pred posodobitvijo IS

ID: vsif_id: Naziv: ind_velj: 1 1 čaka na potrditev 1

2 1 potrjen s spremembo ure in/ali lokacije 1

3 1 preklican s strani Službe prevozov 1

4 1 preklican s strani uporabnika 1

5 1 potrjen v celoti 1

6 1 rezerva2 0

7 5 prevoz oddan preko weba 1

8 5 prevoz oddan v Službi prevozov 1

9 6 dopoldan 1

10 6 popoldan 1

11 6 zvečer 1

12 6 Boris-dopoldan 1

13 6 Boris-popoldan 1

14 6 Boris-zvečer 1

15 6 vikend 1

16 6 dopust 1

17 6 bolniška 1

18 6 praznik 1

19 6 [prazno] 0

20 1 podatki so bili spremenjeni (s strani Službe prevozov), prevoz čaka na potrditev

1

21 6 tujina 1

22 6 ure 1

23 5 prevoz generiran na podlagi WIN32 predlog 1

24 7 Ljubljana 1

25 7 Maribor 1

26 7 Izola 1

27 1 v fazi razporejanja 1

28 1 zastarel 1

29 5 prevoz kopiran ročno v Službi prevozov 1

30 8 SMS odposlan na Si.mobilov strežnik 1

31 8 SMS uspešno dostavljen na Si.mobilov strežnik (200, OK) 1

32 8 Napačna avtentikacija uporabnika. Preverite če uporabljate pravilno uporabniško ime in geslo (403 FORBIDDEN)

1

33 8 Parametri zahtevka so napačni (400 BAD_REQUEST) 1

34 8 Interna napaka na strežniku Si.mobil (500 SERVER_ERROR)

1

35 8 sporočilo je uvrščeno v sistem in čaka na pošiljanje (ready) 1

36 8 sporočilo poslano naslovniku vendar še ni dostavljeno (sent)

1

37 8 sporočilo je bilo uspešno dostavljeno na naslovnikov GSM (done)

1

38 8 sporočilo ni bilo uspešno dostavljeno na naslovnikov GSM (fail)

1

4

39 8 sporočilo ni bilo uspešno dostavljeno ker uporabnik nima dovolj denarja na prednaročniškem računu za sprejem sporočila (poor)

1

40 9 Aktiven 1

41 9 Izpisan 1

42 9 Umrl 1

43 9 Podporni 1

44 9 Izpisan podporni 1

45 9 Umrl podporni 1

46 10 95 oktanski 1

47 10 100 oktanski 1

48 10 Diesel 1

49 10 Avtoplin 1

50 11 vidi menijsko vrstico 1

51 11 lahko odpre okno 1

52 11 lahko vnaša podatke 1

53 11 lahko spreminja podatke 1

54 11 lahko briše podatke 1

55 13 gorivo 1

56 13 materialni strošek (olje vitrex) 1

57 12 vinjeta 1

58 12 cestnina 1

59 12 tunelnina 1

60 12 parkirnina 1

61 12 poslovna storitev Petrola 1

62 12 skupni strošek 1

63 14 2010/2011 1

64 14 2011/2012 1

65 15 samo koledar 1

66 15 samo voščilnica 1

67 15 voščilnica in koledar 1

68 16 navadna pošiljka 1

69 16 priporočena pošiljka s povratnico 1

70 16 pošiljatelj pošiljko dostavi osebno 1

71 16 prejemnik prevzame pošiljko osebno 1

72 17 čaka na prevzem 1

73 17 prevzeto in poslano tiskarju 1

74 12 popust 1

75 18 dejavnosti društva 1

76 18 ohranjevanje zdravja 1

77 18 obnovitvena rehabilitacija 1

78 18 prevoz na delo in iz dela 1

79 18 izobraževanje in usposabljanje 1

80 18 prevoz medicinsko-tehničnih pripomočkov 1

81 18 športne aktivnosti 1

5

82 18 kulturne prireditve 1

83 18 prostočasne aktivnosti 1

84 18 obisk zdravstvenih in drugih državnih ustanov 1

85 18 dejavnost BORI 1

6

Priloga 4: Rezultat storitve Google Directions API v XML obliki

<?xml version="1.0" encoding="UTF-8"?> <DirectionsResponse> <status>OK</status> <route> <summary>Tržaška cesta</summary> <leg> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0455800</lat> <lng>14.4896400</lng> </start_location> <end_location> <lat>46.0449900</lat> <lng>14.4875400</lng> </end_location> <polyline> <points>{g`xGg_mwA?@BFNt@DTBLLh@?B@BFXH^Lv@Jj@@HLp@Fb@BN</points> </polyline> <duration> <value>11</value> <text>1 min</text> </duration> <html_instructions>Pojdite v smeri jugozahod po Tržaška cesta proti Šestova ulica</html_instructions> <distance> <value>175</value> <text>0,2 km</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0449900</lat> <lng>14.4875400</lng> </start_location> <end_location> <lat>46.0459600</lat> <lng>14.4868700</lng> </end_location> <polyline> <points>ed`xGcrlwAULkDvB</points> </polyline> <duration> <value>19</value> <text>1 min</text> </duration> <html_instructions>Zavijte desno na Šestova ulica</html_instructions> <distance> <value>119</value> <text>0,1 km</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location>

7

<lat>46.0459600</lat> <lng>14.4868700</lng> </start_location> <end_location> <lat>46.0474500</lat> <lng>14.4911300</lng> </end_location> <polyline> <points>gj`xG}mlwAg@gBk@iC[aAwA{FaBcH</points> </polyline> <duration> <value>76</value> <text>1 min</text> </duration> <html_instructions>Zavijte desno na Postojnska ulica</html_instructions> <distance> <value>368</value> <text>0,4 km</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0474500</lat> <lng>14.4911300</lng> </start_location> <end_location> <lat>46.0462900</lat> <lng>14.4919500</lng> </end_location> <polyline> <points>qs`xGqhmwAjCaBFG\Qd@[NK</points> </polyline> <duration> <value>32</value> <text>1 min</text> </duration> <html_instructions>Zavijte desno na Oražnova ulica</html_instructions> <distance> <value>145</value> <text>0,1 km</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0462900</lat> <lng>14.4919500</lng> </start_location> <end_location> <lat>46.0472500</lat> <lng>14.4962300</lng> </end_location> <polyline> <points>il`xGummwAAGWgAkA{E]wAI]]sAU_AUkACQCQCKAK@U@I@ODYPq@F]</points> </polyline> <duration> <value>61</value>

8

<text>1 min</text> </duration> <html_instructions>Zapeljite v 2. odcep z leve na Tržaška cesta</html_instructions> <distance> <value>364</value> <text>0,4 km</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0472500</lat> <lng>14.4962300</lng> </start_location> <end_location> <lat>46.0463000</lat> <lng>14.5009400</lng> </end_location> <polyline> <points>ir`xGmhnwALg@RyAPgB~@iHhAyK</points> </polyline> <duration> <value>30</value> <text>1 min</text> </duration> <html_instructions>Nadaljujte po Aškerčeva cesta</html_instructions> <distance> <value>379</value> <text>0,4 km</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0463000</lat> <lng>14.5009400</lng> </start_location> <end_location> <lat>46.0499000</lat> <lng>14.5025800</lng> </end_location> <polyline> <points>kl`xG{eowAOC[IiASuAYiAIm@MMEYKw@e@SKSKg@Wq@a@_@Wi@]SKWMSK_@M</points> </polyline> <duration> <value>54</value> <text>1 min</text> </duration> <html_instructions>Zavijte levo na Slovenska cesta</html_instructions> <distance> <value>423</value> <text>0,4 km</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode>

9

<start_location> <lat>46.0499000</lat> <lng>14.5025800</lng> </start_location> <end_location> <lat>46.0495300</lat> <lng>14.5045800</lng> </end_location> <polyline> <points>{baxGcpowAHy@Da@ôDXcC</points> </polyline> <duration> <value>33</value> <text>1 min</text> </duration> <html_instructions>Zavijte desno na Kongresni Trg</html_instructions> <distance> <value>159</value> <text>0,2 km</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0495300</lat> <lng>14.5045800</lng> </start_location> <end_location> <lat>46.0498000</lat> <lng>14.5040500</lng> </end_location> <polyline> <points>qàxGs|owA_@ACNAJAHMdA</points> </polyline> <duration> <value>21</value> <text>1 min</text> </duration> <html_instructions>Polkrožno zavijte pri Gosposka ulica<div style="font-size:0.9em">Cilj bo na desni strani</div></html_instructions> <distance> <value>60</value> <text>60 m</text> </distance> </step> <duration> <value>337</value> <text>6 min</text> </duration> <distance> <value>2192</value> <text>2,2 km</text> </distance> <start_location> <lat>46.0455800</lat> <lng>14.4896400</lng> </start_location> <end_location>

10

<lat>46.0498000</lat> <lng>14.5040500</lng> </end_location> <start_address>Tržaška cesta 18-22, 1000 Ljubljana, Slovenija</start_address> <end_address>Kongresni Trg, 1000 Ljubljana, Slovenija</end_address> </leg> <copyrights>Podatki na zemljevidu ©2012 Tele Atlas</copyrights> <overview_polyline> <points>{g`xGg_mwAl@tCj@|CZnBaEdCg@gBk@iC[aAwA{FaBcHjCaBd@Yt@g@cCcKg@qBk@kCM{@JiAXoALg@RyAPgB~@iHhAyKOCeB]uAYiAI{@SYKw@e@g@WyAy@iAu@k@Ys@YN{Ax@sH_@ACNCTMdA</points> </overview_polyline> <bounds> <southwest> <lat>46.0449900</lat> <lng>14.4868700</lng> </southwest> <northeast> <lat>46.0499000</lat> <lng>14.5045900</lng> </northeast> </bounds> </route> <route> <summary>Tržaška cesta</summary> <leg> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0455800</lat> <lng>14.4896400</lng> </start_location> <end_location> <lat>46.0433700</lat> <lng>14.4819100</lng> </end_location> <polyline> <points>{g`xGg_mwA?@BFNt@DTBLLh@?B@BFXH^Lv@Jj@@HLp@Fb@BNJl@\jBXzAFXTbAH\@@@FLf@Lf@@D@BBJf@rCLr@p@|Dt@zDPÀ</points> </polyline> <duration> <value>42</value> <text>1 min</text> </duration> <html_instructions>Pojdite v smeri jugozahod po Tržaška cesta proti Šestova ulica</html_instructions> <distance> <value>645</value> <text>0,6 km</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0433700</lat> <lng>14.4819100</lng> </start_location> <end_location>

11

<lat>46.0439600</lat> <lng>14.4815900</lng> </end_location> <polyline> <points>az_xG}nkwAe@Nu@\YP</points> </polyline> <duration> <value>19</value> <text>1 min</text> </duration> <html_instructions>Zavijte desno na Kogejeva ulica</html_instructions> <distance> <value>70</value> <text>70 m</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0439600</lat> <lng>14.4815900</lng> </start_location> <end_location> <lat>46.0437200</lat> <lng>14.4806200</lng> </end_location> <polyline> <points>w}_xG}lkwADVDXDRBJDVBRF^BPBP</points> </polyline> <duration> <value>19</value> <text>1 min</text> </duration> <html_instructions>Zapeljite v 1. odcep z leve na Tržna ulica</html_instructions> <distance> <value>80</value> <text>80 m</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0437200</lat> <lng>14.4806200</lng> </start_location> <end_location> <lat>46.0430800</lat> <lng>14.4809000</lng> </end_location> <polyline> <points>g|_xG{fkwAl@Q`@MPGLGHEDA</points> </polyline> <duration> <value>14</value> <text>1 min</text> </duration> <html_instructions>Zavijte levo na Gregorinova ulica</html_instructions>

12

<distance> <value>74</value> <text>74 m</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0430800</lat> <lng>14.4809000</lng> </start_location> <end_location> <lat>46.0472500</lat> <lng>14.4962300</lng> </end_location> <polyline> <points>gx_xGshkwAG[EUGYMu@UgAQaAu@{Dq@}DMs@g@sCCKACAECg@QaAKc@Ms@Ia@SeAQ{@Oy@?CE]ESCUIc@Gg@Kc@COESUcAIa@[sAMk@WkA_C{JEOAGWgAkA{E]wAI]]sAU_AUkACQCQCKAK@U@I@ODYPq@F]</points> </polyline> <duration> <value>126</value> <text>2 min</text> </duration> <html_instructions>Zavijte levo na Tržaška cesta</html_instructions> <distance> <value>1289</value> <text>1,3 km</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0472500</lat> <lng>14.4962300</lng> </start_location> <end_location> <lat>46.0463000</lat> <lng>14.5009400</lng> </end_location> <polyline> <points>ir`xGmhnwALg@RyAPgB~@iHhAyK</points> </polyline> <duration> <value>30</value> <text>1 min</text> </duration> <html_instructions>Nadaljujte po Aškerčeva cesta</html_instructions> <distance> <value>379</value> <text>0,4 km</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0463000</lat> <lng>14.5009400</lng>

13

</start_location> <end_location> <lat>46.0499000</lat> <lng>14.5025800</lng> </end_location> <polyline> <points>kl`xG{eowAOC[IiASuAYiAIm@MMEYKw@e@SKSKg@Wq@a@_@Wi@]SKWMSK_@M</points> </polyline> <duration> <value>54</value> <text>1 min</text> </duration> <html_instructions>Zavijte levo na Slovenska cesta</html_instructions> <distance> <value>423</value> <text>0,4 km</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0499000</lat> <lng>14.5025800</lng> </start_location> <end_location> <lat>46.0495300</lat> <lng>14.5045800</lng> </end_location> <polyline> <points>{baxGcpowAHy@Da@ôDXcC</points> </polyline> <duration> <value>33</value> <text>1 min</text> </duration> <html_instructions>Zavijte desno na Kongresni Trg</html_instructions> <distance> <value>159</value> <text>0,2 km</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0495300</lat> <lng>14.5045800</lng> </start_location> <end_location> <lat>46.0498000</lat> <lng>14.5040500</lng> </end_location> <polyline> <points>qàxGs|owA_@ACNAJAHMdA</points> </polyline> <duration> <value>21</value>

14

<text>1 min</text> </duration> <html_instructions>Polkrožno zavijte pri Gosposka ulica<div style="font-size:0.9em">Cilj bo na desni strani</div></html_instructions> <distance> <value>60</value> <text>60 m</text> </distance> </step> <duration> <value>358</value> <text>6 min</text> </duration> <distance> <value>3179</value> <text>3,2 km</text> </distance> <start_location> <lat>46.0455800</lat> <lng>14.4896400</lng> </start_location> <end_location> <lat>46.0498000</lat> <lng>14.5040500</lng> </end_location> <start_address>Tržaška cesta 18-22, 1000 Ljubljana, Slovenija</start_address> <end_address>Kongresni Trg, 1000 Ljubljana, Slovenija</end_address> <via_waypoint> <location> <lat>46.0435950</lat> <lng>14.4827100</lng> </location> <step_index>0</step_index> <step_interpolation>0.8968436</step_interpolation> </via_waypoint> </leg> <copyrights>Podatki na zemljevidu ©2012 Tele Atlas</copyrights> <overview_polyline> <points>{g`xGg_mwAl@tCj@|CZnBjAnGb@jB^xAjBpKfA|F{Al@YPDVJl@TvAFb@nA_@n@Wc@aCg@iCgByJ{@wEEm@]eB}@wE[oBMy@SkAi@iCaEgQgEeQa@{B?a@BYl@qCd@aE~@iHhAyKk@M_Dm@iAIm@Mg@QgCuAoCcBk@Y_@MHy@d@qEXcC_@AEZOnA</points> </overview_polyline> <bounds> <southwest> <lat>46.0430800</lat> <lng>14.4806200</lng> </southwest> <northeast> <lat>46.0499000</lat> <lng>14.5045900</lng> </northeast> </bounds> </route> <route> <summary>Jamova cesta</summary> <leg> <step> <travel_mode>DRIVING</travel_mode>

15

<start_location> <lat>46.0455800</lat> <lng>14.4896400</lng> </start_location> <end_location> <lat>46.0449900</lat> <lng>14.4875400</lng> </end_location> <polyline> <points>{g`xGg_mwA?@BFNt@DTBLLh@?B@BFXH^Lv@Jj@@HLp@Fb@BN</points> </polyline> <duration> <value>11</value> <text>1 min</text> </duration> <html_instructions>Pojdite v smeri jugozahod po Tržaška cesta proti Šestova ulica</html_instructions> <distance> <value>175</value> <text>0,2 km</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0449900</lat> <lng>14.4875400</lng> </start_location> <end_location> <lat>46.0449600</lat> <lng>14.4875600</lng> </end_location> <polyline> <points>ed`xGcrlwADC</points> </polyline> <duration> <value>27</value> <text>1 min</text> </duration> <html_instructions>Zavijte levo na Šestova ulica</html_instructions> <distance> <value>5</value> <text>5 m</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0449600</lat> <lng>14.4875600</lng> </start_location> <end_location> <lat>46.0433100</lat> <lng>14.4886400</lng> </end_location> <polyline> <points>_d`xGgrlwAHEÛNIl@[~@i@bAi@|AaA</points> </polyline> <duration>

16

<value>49</value> <text>1 min</text> </duration> <html_instructions>Nadaljujte po Jadranska ulica</html_instructions> <distance> <value>201</value> <text>0,2 km</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0433100</lat> <lng>14.4886400</lng> </start_location> <end_location> <lat>46.0457500</lat> <lng>14.4962700</lng> </end_location> <polyline> <points>uy_xG_ylwAiBmIEKk@gCi@_CyAkGoBeIq@}DKg@QaAGY</points> </polyline> <duration> <value>108</value> <text>2 min</text> </duration> <html_instructions>Zavijte levo na Jamova cesta</html_instructions> <distance> <value>649</value> <text>0,6 km</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0457500</lat> <lng>14.4962700</lng> </start_location> <end_location> <lat>46.0472500</lat> <lng>14.4962300</lng> </end_location> <polyline> <points>}h`xGuhnwAg@\y@f@a@R_@?[Im@]}@i@</points> </polyline> <duration> <value>29</value> <text>1 min</text> </duration> <html_instructions>Zavijte levo na Groharjeva cesta</html_instructions> <distance> <value>181</value> <text>0,2 km</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location>

17

<lat>46.0472500</lat> <lng>14.4962300</lng> </start_location> <end_location> <lat>46.0463000</lat> <lng>14.5009400</lng> </end_location> <polyline> <points>ir`xGmhnwALg@RyAPgB~@iHhAyK</points> </polyline> <duration> <value>58</value> <text>1 min</text> </duration> <html_instructions>Zapeljite v 1. odcep z desne na Aškerčeva cesta</html_instructions> <distance> <value>379</value> <text>0,4 km</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0463000</lat> <lng>14.5009400</lng> </start_location> <end_location> <lat>46.0499000</lat> <lng>14.5025800</lng> </end_location> <polyline> <points>kl`xG{eowAOC[IiASuAYiAIm@MMEYKw@e@SKSKg@Wq@a@_@Wi@]SKWMSK_@M</points> </polyline> <duration> <value>54</value> <text>1 min</text> </duration> <html_instructions>Zapeljite v 2. odcep z leve na Slovenska cesta</html_instructions> <distance> <value>423</value> <text>0,4 km</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0499000</lat> <lng>14.5025800</lng> </start_location> <end_location> <lat>46.0495300</lat> <lng>14.5045800</lng> </end_location> <polyline> <points>{baxGcpowAHy@Da@ôDXcC</points> </polyline>

18

<duration> <value>33</value> <text>1 min</text> </duration> <html_instructions>Zavijte desno na Kongresni Trg</html_instructions> <distance> <value>159</value> <text>0,2 km</text> </distance> </step> <step> <travel_mode>DRIVING</travel_mode> <start_location> <lat>46.0495300</lat> <lng>14.5045800</lng> </start_location> <end_location> <lat>46.0498000</lat> <lng>14.5040500</lng> </end_location> <polyline> <points>qàxGs|owA_@ACNAJAHMdA</points> </polyline> <duration> <value>21</value> <text>1 min</text> </duration> <html_instructions>Polkrožno zavijte pri Gosposka ulica<div style="font-size:0.9em">Cilj bo na desni strani</div></html_instructions> <distance> <value>60</value> <text>60 m</text> </distance> </step> <duration> <value>390</value> <text>7 min</text> </duration> <distance> <value>2232</value> <text>2,2 km</text> </distance> <start_location> <lat>46.0455800</lat> <lng>14.4896400</lng> </start_location> <end_location> <lat>46.0498000</lat> <lng>14.5040500</lng> </end_location> <start_address>Tržaška cesta 18-22, 1000 Ljubljana, Slovenija</start_address> <end_address>Kongresni Trg, 1000 Ljubljana, Slovenija</end_address> <via_waypoint> <location> <lat>46.0454350</lat> <lng>14.4951350</lng> </location> <step_index>3</step_index>

19

<step_interpolation>0.8542618</step_interpolation> </via_waypoint> </leg> <copyrights>Podatki na zemljevidu ©2012 Tele Atlas</copyrights> <overview_polyline> <points>{g`xGg_mwAl@tCj@|CZnB~@i@lBeA`DkBeEaRiEqQ}@eFY{AaBdAa@R_@?[Im@]}@i@Lg@d@aE~@iHhAyKk@M_Dm@iAIm@Mg@QkAq@{@c@qAy@}@i@k@Y_@MHy@d@qEXcC_@AEZOnA</points> </overview_polyline> <bounds> <southwest> <lat>46.0433100</lat> <lng>14.4875400</lng> </southwest> <northeast> <lat>46.0499000</lat> <lng>14.5045900</lng> </northeast> </bounds> </route> </DirectionsResponse>

Documents

POSODOBITEV INFORMACIJSKEGA SISTEMA ZA ...Evidenten primer uporabe optimizacijskega postopka je tudi integracija Googleove storitve, s katero pridobimo ustrezen optimiziran podatek