Diplomsko delo

Transkripcija

1 UNIVERZA V MARIBORU FAKULTETA ZA ORGANIZACIJSKE VEDE Smer Informatika v organizaciji in managementu PROGRAMSKA REŠITEV ZA SPREMLJANJE UPORABE SLUŽBENIH MOBILNIH TELEFONOV Mentor: doc. dr. Borut Werber Kandidat: Miro Stefanišin Kranj, April 2009

2 ZAHVALA Zahvaljujem se mentorju doc. dr. Werber Borutu za pomoč in nasvete pri pripravi in izdelavi diplomske naloge. Posebna zahvala gre podjetju GORA d.o.o., Ljubljana, informacijski inženiring, ki mi je plačalo šolanje in nudilo pomoč pri izdelavi seminarskih nalog. Hvala tudi vsem ostalim, ki so me podpirali skozi vsa študijska leta ali pa kakorkoli pomagali pri izdelavi moje diplomske naloge, predvsem pa moji ženi Jasni.

3 POVZETEK Diplomska naloga predstavlja razvoj prototipne programske rešitve za spremljanje uporabe službenih mobilnih telefonov. Namen rešitve je poenostaviti obračun in porazdeliti stroške pogovorov s službenimi mobilnimi telefoni med podjetjem in delavci. Osnova za obračun so podatki o porabi posameznih službenih mobilnih telefonov, ki jih dobimo v elektronski obliki od mobilnega operaterja. Programska rešitev omogoča delitev stroškov s pomočjo ločevanja telefonskih številk na službene in zasebne. S pomočjo dodatne označitve lahko določimo, katere storitve se priznavajo kot službene. Podjetje znesek zasebnega stroška delavcu obračuna pri obračunu plače. V uvodnem delu naloge smo podrobno predstavili problem in okolje podjetja Gora d.o.o., Ljubljana, ki se ukvarja z razvojem, uvajanjem in vzdrževanjem bančne informacijske tehnologije. Kot omejitev je predstavljen problem dostopa do podatkov mobilnega operaterja, prav tako pa tudi format zapisa le teh. Sledi opis prototipne metode razvoja. V osrednjem delu je opisana izgradnja in razvoj prototipne programske rešitve, narejene v profesionalnem okolju za razvoj aplikacij ZIM. Na koncu so ocenjeni učinki in opisana uvedba ter možnosti nadaljnjega razvoja. KLJUČNE BESEDE programska rešitev obračun stroškov mobilni telefon programsko orodje ZIM

4 ABSTRACT The thesis presents the development of a prototype software solution for monitoring the use of company mobile phones. The purpose of the solution is to simplify the calculation and to distribute the costs of conversations with company mobile phones among the company and workers. The basis for calculation is the data on the use of individual mobile phone, which is obtained in electronic form from the network operator. The software solution allows the division of costs through the separation of telephone numbers to official and private, and further characterization determines which services are recognized as official. The company settles the account of employee s private costs in the calculation of wages. The introductory part of the thesis presents in detail the problem and environment of the company GORA d.o.o., Ljubljana, which deals with the development, implementation and maintenance of a bank s information technology. As a restriction, the problems of access and format of data from the network operator are presented. A description of a prototype development follows. In the central part the creation and development of prototype software solutions are described; they are made in a professional environment for developing applications called ZIM. At the end we described the estimated effects, implementation and the possibilities of further development. KEYWORDS software solutions the settlement of the account a mobile phone ZIM Software tool

5 KAZALO 1. UVOD PREDSTAVITEV PROBLEMA PREDSTAVITEV OKOLJA PREDPOSTAVKE IN OMEJITVE METODE DELA POSNETEK OBSTOJEČEGA STANJA PRETOK PODATKOV PRI OBSTOJEČEM STANJU KRITIČNA ANALIZA OBSTOJEČE REŠITVE IZGRADNJA INFORMACIJSKEGA SISTEMA IDEJNA REŠITEV PROBLEMA ZASNOVA PODATKOVNEGA MODELA DOLOČANJE ENTITET IN NJIHOVIH LASTNOSTI NORMALIZACIJA PODATKOVNE STRUKTURE DOLOČANJE TABEL PODATKOVNI MODEL RAZVOJ PROTOTIPNE APLIKACIJE IZBIRA ORODJA ZA RAZVOJ PROTOTIPNE APLIKACIJE PRETOK PODATKOV V PROTOTIPNI APLIKACIJI PRETOK PODATKOV V FAZI OBRAČUNA PROTOTIPNA APLIKACIJA ANALIZA PROBLEMA USTVARJANJE PODATKOVNEGA SLOVARJA USTVARJANJE OBJEKTOV V PODATKOVNEM SLOVARJU ENTITETE RELACIJE IN MOŽICE DOKUMENTI SPREMENLJIVKE USTVARJANJE VNOSNIH EKRANOV IZDELAVA POTREBNIH PROGRAMOV IN TESTIRANJE KONVERZIJA VHODNIH FORMATOV GLAVNI PROGRAM TESTIRANJE ZAKLJUČKI OCENA UČINKOV POGOJI ZA UVEDBO MOŽNOSTI NADALJNEGA RAZVOJA...44 LITERATURA IN VIRI...45

6 1. UVOD 1.1. PREDSTAVITEV PROBLEMA Diplomska naloga je nastala kot pomoč podjetjem, ki bi rada učinkoviteje vodila in spremljala porabo službenih mobilnih telefonov. Izbrali smo podjetje GORA d.o.o., Ljubljana. Uporaba mobilnih telefonov v poslovnem svetu je danes obvezna in zato mnogo podjetij uporablja službene mobilne telefone. Službeni mobilni telefoni so običajno nepogrešljivi za delavce, ki opravljajo dežurstvo ali pa nudijo podporo strankam v načinu 24/7. Normalno je, da podjetje plačuje uporabo službenega mobilnega telefona. Zasebne mobilne telefone pa ima danes praktično že vsak. To pomeni, da imajo uporabniki službenih mobilnih telefonov možnost, da: uporabljajo (in prenašajo) 2 mobilna telefona službenega ter zasebnega uporabljajo službeni telefon tudi za zasebne potrebe Običajno se izkaže, da se največ uporablja druga možnost uporaba službenega telefona tudi za zasebne potrebe. Danes na trgu ne obstaja splošno razširjena aplikativna rešitev, ki bi podpirala spremljavo in porabo službenih mobilnih telefonov. Možni rešitvi sta dve, in sicer da podjetje v celoti plačuje račun za službeni mobilni telefon ali pa se uporablja pavšalni način obračuna službenih mobilnih telefonov (v nadaljevanju SMT). Slednje pomeni, da podjetje plača določen znesek računa, preostanek pa plača uporabnik. V našem primeru podjetje plača naročnino, pogovore v MPO omrežju ter določen pavšalni znesek. Ta način pa ni pravičen, kajti v primeru, da uporabnik SMT nima službenih klicev in ima samo zasebne klice, se celotni znesek pavšala porabi za plačilo zasebnih klicev. Če pa imamo uporabnika SMT, ki ima samo službene klice vendar le ti presegajo dogovorjen pavšal, mora uporabnik plačati za službene klice. Osnovna ideja je, da se izdela programsko rešitev, ki bi spremljala porabo uporabnikov SMT in bi nato podjetje plačalo samo naročnino ter stroške, povezane s službenimi številkami, uporabnik SMT pa bi plačal razliko PREDSTAVITEV OKOLJA Za izvedbo diplomske naloge smo izbrali podjetje GORA d.o.o., Ljubljana. Podjetje ima sedež na Dunajski cesti 21 v Ljubljani. Podjetje je bilo ustanovljeno leta 1990 in je v zasebni lasti. Domača internet stran podjetja se nahaja na Predstavitev podjetja smo povzeli po dokumentu GORA_PORTFELJ_2008_V3. Poslanstvo podjetja je usmerjeno v cilje, ki zagotavljajo visoko strokovno podporo na področju razvoja, implementacije, vzdrževanja in servisiranja bančne informacijske tehnologije. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 1

7 Zavedajo se procesa poenotenja informacijske tehnologije za podporo poslovnim procesom na nivoju globalnega tržišča in pritiska globalne konkurence. Svojo priložnost vidijo v znanju, ki povezuje globalni svet z lokalnim okoljem. Njihov osnovni cilj je zadovoljstvo odjemalcev. Z dobavitelji in odjemalci vzpostavljajo dolgoročne partnerske odnose. V ta namen so s formalnim obnavljanjem certifikata kakovosti kakor tudi vsebinsko zavezani standardom kakovosti ISO 9001:2000. Svoje kompetence dokazujejo: z bogatim znanjem s področja bančne in informacijske tehnologije; s tradicijo uspešnega delovanja v bančnem sektorju; z jasno vizijo usmerjenosti v vodilno pozicijo na področju ponudbe bančne tehnologije; glavna referenca so jim zadovoljne stranke; prilagajajo se zahtevam strank s strategijo poslovanja na zahtevo - organizirani so tako, da lahko ponudijo ustrezne rešitve točno takrat, ko jih stranka potrebuje. Podjetje ima preko 20 SMT od tega 4 samo za prenos podatkov (oddaljen dostop dežurnih delavcev do podjetja za potrebe podpore strankam). Podjetje ima stranke v Sloveniji in tudi v tujini, tako da so med zneski računov za SMT lahko precejšnja odstopanja in je zelo težko postaviti pavšalni znesek, ki ga podjetje priznava. Predstavitev podjetja Kot je navedeno v internem dokumentu podjetja GORA_PORTFELJ_2008_V3 (GORA d.o.o., Ljubljana 2008), je bilo podjetje ustanovljeno leta Osnovni kapital podjetja znaša ,00 EUR. V podjetju je zaposlenih preko 50 delavcev. Osnovno vodilo podjetja GORA d.o.o., Ljubljana temelji na znanju, izkušnjah in obvladovanju sodobne informacijske tehnologije na področju bančništva in vodenja vrednostnih papirjev. V začetku je bila osnovna dejavnost podjetja izgradnja informacijskih rešitev na področju bančništva. Ponosni so, da jim je uspelo v preteklih letih uspešno izvesti in uvesti integralne informacijske rešitve na področju bančnih informacijskih sistemov v slovenskih in hrvaških bankah. Kompleksnost problemov področja bančnih informacijskih sistemov, zakonodaja in strogi varnostni predpisi so v podjetju izoblikovali specializirana področja, ki jih sedaj ponujajo kot posamezne storitve ali pa v sklopu celotnih rešitev. Produkti in storitve podjetja GORA d.o.o. Ljubljana: Lasten integralni informacijski sistem za banke»omega«. Sistem podpira celovito bančno poslovanje na vseh segmentih delovanja banke. Lasten razvoj in sodobne tehnološke rešitve usklajene s standardi politike bančnega poslovanja. Razpoložljivost sistema non-stop - 24/7. Največje število istočasnih uporabnikov preko 1000, dodatno še internet uporabniki, on-line bankomati itd, kar pomeni zelo robustno in zanesljivo delovanje. Podprti so vsi informacijsko bančni standardi, poročanje in zahteve narodnih bank Slovenije, Hrvaške ter EU. Že več kot 17 let Izkušenj. Integralni informacijski sistem Omega je zasnovan parametrično, kar pomeni enostavno prilagajanje banki glede na Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 2

8 spremembe na trgu. Je zelo prijazen uporabniku, ponuja možnost uporabe domačega jezika ter vodenja uporabnika skozi proces dela. Priprava tehnoloških zahtevkov in oblikovanje programskih modelov na področju bančnega poslovanja in področju vrednostnih papirjev na zahtevo stranke. Pri tem upoštevajo zakonitosti poslovnega okolja stranke (zakonodaja, standardi, tržišče) ter trende in standarde informacijske tehnologije (robustnost, prožnost, varnost...). Certificirani svetovalci za področje uvajanje in vzdrževanja programskega produkta GLOBUS s 4 letnimi izkušnjami pri uvajanju tega produkta v Novi Ljubljanski banki d.d. Sodelovanje na projektih uvedbe novih informacijskih tehnologij na področju bančništva kot del projektnih skupin partnerjev. Poleg strokovnosti prinašajo veliko profesionalnost in odgovornost do postavljenih ciljev projekta. Nadgradnja transakcijskih sistemov v bankah z analitičnimi bazami za potrebe poslovnega obveščanja in zakonsko zahtevanih poročil - Business intelligence (BI) Povezovanje in integracija posameznih informacijskih sistemov v bankah v integralne informacijske sisteme tako v internem kot zunanjem informacijskem okolju (Connecting Solutions). Postavitev sodobnih informacijskih tehnologij ter aplikativnih rešitev za varen in kontroliran dostop do informacij informacijskega sistema ter avtomatsko izmenjavo podatkov med sistemi. Strojno in sistemsko okolje (IBM-AIX, SUN-Solaris, HP) Širok spekter orodij za izdelavo IS (ZIM, ORACLE, DB2, Java,.NET, COBOL...) Izdelava internetnih aplikacij s tehnologijo Microsoft.NET Varnostni sistemi (paralelna okolja, disaster recovery sistemi) Spremljanje, vzdrževanje in diagnostika delovanja informacijskih rešitev s sodobno organizirano podporo uporabnikom - HELP-DESK. GORA d.o.o., Ljubljana je na tržišču prepoznavna kot podjetje z jasno postavljeno strategijo poslovanja na zahtevo (On Demand), visoko usmerjenost k nadgradnji znanja in izkušenj, velika profesionalnost pri delu. Vse to jih postavlja v vlogo zaupanja vrednega partnerja pri izgradnji, uvajanju, ter vzdrževanju in servisiranju informacijskih rešitev. Podjetje ima od leta 2005 certifikat kakovosti ISO 9001:2000, katerega so že dvakrat uspešno obnovili. V fazi uvajanja certifikata so v celoti optimizirali poslovne procese, v katere smo vgradili izjemno dobre kontrolne mehanizme, s čemer smo dvignili kvaliteto dela in produktivnost zaposlenih. Področja delovanja ORACLE poslovna inteligenca in 'Oracle BI Enterprise Edition' Področje poslovne inteligence oziroma nadgradnje različnih sistemov v sistem poslovnega obveščanja podjetju predstavlja poseben izziv. V ta namen imajo organizirano posebno ekipo. Naloge te ekipe so predvsem v akumulaciji potrebnih znanj s področja BI za potrebe trga. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 3

9 Poudarjajo, da z znanji, ki jih imajo, lahko pristopijo k izgradnji sistemov BI ali pa se aktivno vključijo v že aktiven projekt. Trenutno imajo izgrajena podatkovna skladišča za potrebe poročanja narodnim bankam in predvsem potrebam poročanja EU regulative ter nudenju vseh potrebnih informacij vodstvenemu kadru za potrebe odločanja. Prav tako je razvit sistem za spremljanje tržnih akcij ter merjenje uspešnosti le teh na trgu. ORACLE/DB2 DBA Podjetje že tri leta sodelujejo v procesu administracije baze podatkov na področjih aplikacij, ki delujejo v zahtevnih on-line okoljih. Njihova vloga je izvajanje del administratorja baz podatkov nad več med seboj povezanih sistemih. Odgovorni so za izvajanje help-deska v režimu 24/7. Na razpolago imajo dva visoko usposobljena administratorja. Lahko prevzamejo celoten nadzor nad administracijo baz podatkov, kot tudi občasno spremljanje in svetovanje na zahtevo naročnika. Znanja, ki jih koristijo v okviru DBA: 1. instalacije in konfiguriranje baz in instanc 2. usposobitev pristopa bazi in konfiguriranje za pristop preko mreže (Net8) 3. monitoriranje in tuning 4. backup in recovery 5. postavljanje skript za nadzor nad bazo podatkov (kontrola prostora nad tablespaceom, dinamika in nadzor kritičnih tabel...) 6. postavljanje in analiza statistike (po potrebi ali redno izvajanje - v odvisnosti od načina optimizacije na bazi (CBO ali RBO)) 7. pomoč pri postavljanju podatkovnega modela in svetovanje pri postavljanju objektov za izboljšanja dela v odnosu do dostopa do podatkov. 8. podpora v slučaju potrebe po hitri intervenciji Microsoft.NET tehnologija Področje Microsoft tehnologij pokriva posebna ekipa, ki se ukvarja s programsko opremo, ki je dosegljiva prek spleta. Najodmevnejši projekt skupine je izgradnja portala ki predstavlja celovito rešitev za vodenje vrednostnih papirjev ter izračun kapitalskih dobičkov. Prav tako je del portala namenjen»kalkulatorjem«za primerjavo različnih bančnih produktov za širšo uporabo internetnega trga. Poudariti je potrebno, da je uporabljena tehnologija v skladu z zadnjimi varnostnimi elementi na trgu internetne tehnologije. Prav tako je zelo dobra osnova za nadaljnji razvoj internetnih aplikacij. GORA lokalni partner podjetja FinArch FinArch's Financial Studio ( je prva popolna integralna rešitev za finančno planiranje v bankah (FRP) ter ostalih finančnih institucijah. Sistem pokriva celotno regulativo BASEL II, izračune in simulacije profitabilnosti, upravljavski informacijski sistem ter sistem poročanja. Podjetje ima reference po celem svetu v velikih svetovnih bankah. Sam sistem je enostaven za implementacijo. Podjetje Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 4

10 GORA d.o.o., Ljubljana ima za cilj pripeljati to tehnologijo v Adriatic regijo. V ta namen imajo sklenjeno pogodbo o skupnem sodelovanju. V bodočnosti želijo nuditi regionalno implementacijo produkta ter regionalno pomoč uporabnikom. Pomembne reference RAIFFEISENBANK Austria d.d., Zagreb POŠTNA BANKA SLOVENIJE d.d., Bančna skupina Nove KB Maribor d.d. Slovenska investicijska banka d.d. Ljubljana S&T - Nova ljubljanska banka d.d. RAIFFEISEN FACTORING d.d. Zagreb SKB BANKA d.d. SOCIETE GENERALE GROUP E-FUNDS d.o.o., Ljubljana Organizacijska struktura Slika 1 Shema notranje organizacije podjetja GORA d.o.o., Ljubljana Organizacijsko strukturo podjetja smo dobili v internem dokumentu podjetja Gora d.o.o., Ljubljana z imenom»pravilnik Notranja organizacija v_5 priloga 1 shema«miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 5

11 1.3. PREDPOSTAVKE IN OMEJITVE Izbrano podjetje uporablja storitve mobilnega operaterja Mobitel d.d. (v nadaljevanju operater). Prikazana rešitev uporablja datoteke, ki jih operater za svoje uporabnike pripravi na svojem portalu»monitor«( Za dostop do portala je potrebno pridobiti certifikat, ki omogoča varen in kontroliran dostop do podatkov o uporabi SMT. Prikazana rešitev je po konceptu univerzalna, tako da se lahko uporabi tudi za druge mobilne operaterje. Potrebna prilagoditev je samo na nivoju pridobivanja podatkov s strani izbranega operaterja METODE DELA Obstoječ proces obračuna SMT je, da delavka v službi splošnih poslov ročno obdela podatke, ki jih dobimo od operaterja ter ročno pripravi podatke o bremenitvah posameznih delavcev za obračun plač, ki se izvaja v računovodskem servisu. Obstoječ proces ni uporaben za novo rešitev, zato moramo za potrebe nove rešitve najprej izgraditi podatkovni model, ki bo omogočal avtomatski obračun porabe SMT ter pripravil vse potrebne izhodne dokumente. Za praktično izvedbo rešitve bom uporabil orodje ZIM, v katerem je razvit integralni informacijski sistem OMEGA. Pri izboru načina dela smo glede na zapiske predavanja iz predmeta Metode in tehnike informacijske analize (Prof. dr. Jože Zupančič, 2007) izbrali prototipni pristop, ker: Uporabnik laže oceni, ali delujoče aplikacija ustreza njegovim zahtevam kot da v naprej opredeli zahteve S prototipom (poenostavljeno verzijo končne aplikacije ali dela le-te) lahko uporabnik eksperimentira, jo oceni, razvijalec jo lahko (večkrat) dopolni,, dokler dovolj dobro ne ustreza zahtevam uporabnika Oceniti hočemo vpliv načrtovane aplikacije (na delo, poslovanje, ) Prototipni pristop je primeren tudi zaradi tega, ker: so zahteve uporabnikov nejasne in/ali mehke se zahteve hitro spreminjajo s časom je aplikacija in/ali tehnologija inovativna bo aplikacija pomembno vplivala na delo organizacije imamo razmeroma majhne dimenzije projekta imamo razmeroma majhno število uporabnikov imamo razmeroma kratek čas razvoja projekta Odločiti smo se morali tudi, ali bomo prototip zavrgli (throw away prototype, expendable prototype) ali pa ga bomo izpopolnjevali do končne aplikacije (razvojni prototip - Evolutionary prototype). Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 6

12 Zaradi specifičnosti razvojnega okolja in orodja smo se odločili za mešan prototipni pristop, kjer bomo prototip delno zavrgli, ker: če bo končni rezultat upravičeval zastavljene cilje, bomo razvili novo aplikacijo, ki jo podjetje lahko ponudi na trgu je za potrebe analize smotrnosti dovolj, da se izdela nekaj osnovnih uporabniških vmesnikov, doda nekaj osnovnih funkcionalnosti, imamo lahko poenostavljeno bazo podatkov uporabimo lahko orodje ZIM, s katerim je mogoče najhitrejše in najlaže razviti prototipno rešitev je dokumentacija skromna V primeru, da bo končni rezultat upravičeval zastavljene cilje, bomo za osnovo izgradnje nove aplikacije uporabili prototipni podatkovni model, samo aplikacijo pa bomo razvili v.net okolju, ki nam bo omogočal trženje te storitve preko interneta (ponudniki storitve) ali pa kot samostojne aplikacije. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 7

13 2. POSNETEK OBSTOJEČEGA STANJA 2.1. PRETOK PODATKOV PRI OBSTOJEČEM STANJU Slika 2 Pretok podatkov pri obstoječem stanju S pomočjo zgornje slike lahko razberemo, da je potrebno za vsakega delavca preveriti njegov račun za SMT, izračunati razliko med zneskom računa in naročnino, pogovori MPO, pavšalnim zneskom ter v primeru, da je znesek večji od nič, pripraviti podatke za računovodski servis, ki izračunano razliko odtegne pri izplačilu plače KRITIČNA ANALIZA OBSTOJEČE REŠITVE Glede na veliko število uporabnikov SMT (20+) se v službi splošnih poslov porabi veliko časa za izračun porabe. Ker je vse delo ročno, lahko prihaja tudi do napak, kar pomeni angažiranje dodatnega delavca za kontrolo podatkov. Podjetje uporablja storitev MPO (Mobitelovo Poslovno Omrežje), kjer operater ponuja popust na klice, ki so v okviru podjetja, vendar to ne rešuje klice strankam. Izračun razlike zato upošteva, da podjetje plača naročnino na SMT, klice znotraj Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 8

14 MPO omrežja ter določen pavšalni znesek. Morebitno razliko do zneska računa nato plača delavec. Veliko komuniciranja med zaposlenimi in tudi strankami se opravlja preko SMS sporočil, kar pa obstoječ način obračuna ne upošteva. Na prejetem računu ni napisanega imena lastnika SMT, tako da je potrebno ročno poiskati in dopisati lastnika na račun, preden se lahko začne z ročnim obračunom. Še največji problem pa je nepravičen obračun porabe SMT, kajti zaradi narave dela (službeni klici v Sloveniji in v tujino, dnevna dežurstva veliko komuniciranja s strankami) se kaj lahko zgodi, da je en delavec neupravičeno obremenjen za službene klice (če presegajo pavšalni znesek) in drug delavec ne plača zasebnih klicev (če ima porabo SMT pod dogovorjenim pavšalom). Zato je prišlo do logične rešitve, da se razvije računalniška podpora za spremljavo porabe SMT, ki bo pravično izračunala znesek porabe SMT, ki ga mora posamezen delavec plačati. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 9

15 3. IZGRADNJA INFORMACIJSKEGA SISTEMA 3.1. IDEJNA REŠITEV PROBLEMA Osnovna ideja za rešitev problema je, da se delavcu računa samo dejansko opravljene zasebne pogovore. Če vzamemo račun, ki ga od operaterja dobimo za posamezen SMT, lahko vidimo, da je sestavljen iz več postavk, med drugim za naročnino, popust za naročnino ter pogovori znotraj MPO. Telefonska številka Oznaka Storitve Storitev Cena (EUR) Davek (EUR) Davek (%) Znesek (EUR) Naročnina 14,99 3, , Popust na naročnino -7,00-1, , Pogovori v omrežjih Mobitel 0,71 0, , Pogovori znotraj MPO 0,05 0, , Pogovori v ostala slovenska omrežja 4,25 0, , Kratka sporočila - SMS 8,14 1, , Sprejeti klici v tujini 2,53 0, , Pogovori / storitve v tujini 7,17 1, , Posredovanje pogovorov/storitev v tujini 1,07 0, , Popust -0,39-0, ,47 Tabela 1 Izgled računa za posamezni SMT Kot lahko vidimo, na računu ni specifikacije posameznih klicev, kar pomeni, da na osnovi prejetega računa ni možno izdelati želene rešitve. Za izdelavo želene rešitve potrebujemo natančno specifikacijo klicev za posamezni SMT. To nam izbrani operater omogoča preko svojega portala in sicer kot mesečno poročilo»razčlenjen račun«: Datum in čas Destinacija Tip klica Znesek s pop. Telefonska številka : **** Telefonija 0, : **** Telefonija 0, : **** Telefonija 0, : **** Telefonija 0, : SMS oddaja 0, : **** SMS oddaja 0, : **** SMS oddaja 0, : **** SMS oddaja 0, : **** SMS oddaja 0, : **** Telefonija 0, : **** Telefonija 0, Tabela 2 Skrajšan izgled specifikacije klicev posameznega SMT Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 10

16 Slika 3 Portal»Monitor«mobilnega operaterja Mobitel Na osnovi natančne specifikacije računa lahko za posamezen SMT ugotovimo, koliko stroškov je bilo povezanih s službenimi številkami in koliko je ostalih stroškov. Zahteva podjetja je, da se delavcu prizna naročnina in popust na naročnino ter vsi stroški, povezani s službenimi številkami (klici, SMS, itd). Z izgradnjo ustreznega informacijskega sistema bi lahko na podlagi vnesenih službenih številk podjetja (telefonske številke strank) naredili pravičen izračun porabe za posamezen SMT ZASNOVA PODATKOVNEGA MODELA Kot navaja Mohorič T. (2002), se zasnove podatkovnega modela lotimo tako, da na globalnem nivoju analiziramo in organiziramo podatke iz okolja, v katerem naj bi deloval ciljni informacijski sistem. Najlažje to storimo s pomočjo kriterijev, s katerimi presojamo podatke: Prepoznavanje glavne aktivnosti. To je v našem primeru obračun porabe SMT. Prepoznavanje objektov (entitet) te funkcije in aktivnosti, povezane z njo. Posamezne postopke, ki nastopajo v glavni aktivnosti razčlenimo v zaporedje dogodkov. Na ta način identificiramo vse entitete ter relacije med njimi. V našem primeru lahko prepoznamo naslednje glavne entitete: delavec Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 11

17 (edelavec), službeni mobilni telefoni (etelefon), račun (eracun), specifikacija računa (especrac), službene številke (estevilke) ter storitve (estoritve). Prepoznavanje lastnosti (atributov) teh objektov (entitet). Za osnovo smo vzeli kar atribute, ki so definirani z vhodnimi podatki, ki jih imamo na voljo podatki o delavcu, računu in specifikaciji računa. Prepoznavanje razmerij med objekti. Za naš primer velja, da ima lahko služben mobilni telefon samo 1 lastnika, posamezen služben mobilni telefon v obračunskem obdobju več opravljenih telefonskih klicev ter več poslanih SMS sporočil. Vsak od teh zapisov pa je lahko na službeno številko ali pa na zasebno. Posamezna storitev se lahko pojavi na specifikaciji ali pa ne DOLOČANJE ENTITET IN NJIHOVIH LASTNOSTI Naslednji korak pri izdelavi baze podatkov je določitev vseh entitet in atributov, ki sodelujejo pri poslovanju. Entiteta je objekt, ki ga opisujemo v podatkovni bazi. Objekt je lahko fizični, na primer: delavec, račun, telefon ali pa pojmovni, na primer storitve. Vsak objekt (entiteta), ki ga spremljamo, lahko opišemo z njegovimi lastnostmi, ki jih imenujemo atributi. V nadaljevanju bomo s pomočjo tabele v dveh stolpcih predstavili glavni entiteti in njune atribute. Objekt Entiteta RAČUN SPECIFIKACIJA RAČUNA Lastnosti - Atributi Telefonska številka Oznaka Storitve Storitev Cena (EUR) Davek (EUR) Davek (%) Znesek (EUR) Datum in čas Destinacija Tip klica Znesek s popustom Telefonska številka Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 12

18 3.4. NORMALIZACIJA PODATKOVNE STRUKTURE Kaj je normalizacija? Kot navaja Bradač P. (2005), je normalizacija zaporedje spreminjanja struktur tabel. Bistvo normalizacije je v postopnem odpravljanju nepravilnosti v zgradbi zbirke. Na koncu normalizacije pa je seveda potrebno preveriti, ali nove tabele, ki so nastale s postopkom normalizacije, ustrezajo predpisanim pogojem. Pri postopku normalizacije pa poleg večjega števila tabel dobimo tudi relacije med njimi. Relacija je matematični izraz za dvodimenzionalno tabelo. Predstavljajo nam par tuj ključ v eni tabeli in ustrezni primarni ključ v drugi. V nove tabele, ki jih ustvarimo, združujemo lastnosti/atribute objekta/entitete, ki naj jo ta tabela predstavlja. Podatke uredimo ter med enim ali več lastnostmi/atributi določimo ključ, ki bo enolično določal zapis znotraj tabele. To pa tudi pomeni, da ključa ne moremo spreminjati (referenčna integriteta podatkov). Lastnosti/atributi se lahko v tabeli ponovijo samo enkrat, ker s tem zagotovimo točnost vseh v bazo vnesenih podatkov. Lastnosti/atribute, ki se ponavljajo, pustimo le pri tistih objektih/entitetah, ki jo najbolje predstavljajo, drugje pa izbrišemo. Postopek normalizacije lahko poteka po naslednjih korakih: Prva normalna oblika: Vse skupine podatkov, ki se ponavljajo, damo v novo tabelo ali tabele. Odvisno od vsebinske povezanosti teh podatkov. Novi tabeli damo ključ prvotne tabele in ključ, ki enolično določa novo tabelo. Tako dobimo sestavljeni ključ. Druga normalna oblika: Pri tej obliki odstranimo odvisnost od delov ključa. V tabelah s sestavljenim ključem preverimo za vsak atribut, če je odvisen od celega sestavljenega ključa. Vsak atribut, ki ne ustreza tej predpostavki, damo v novo tabelo. Novi tabeli dodamo ključ, ki jo enolično določa in jo povežemo s tabelo, iz katere smo jo izpeljali. Tretja normalna oblika: Da dosežemo to stopnjo normalne oblike, pa moramo odstraniti vzajemne soodvisnosti. Atribute, ki so soodvisni, izločimo v novo tabelo. Ključ nove tabele postane atribut iz prvotne tabele, od katerega so izločeni podatki odvisni. V prvotni tabeli ostane kot tuji ključ. Po pravilno opravljenem postopku normalizacije so vsi podatki, ki označujejo lastnosti objektov, ki jih obravnavamo, napisani samo na enem mestu. Podatke na ta način veliko lažje posodabljamo in brišemo. Odpravimo podvajanje podatkov, zato se možnost napak zelo zniža. Prav tako se zelo zmanjša možnost obstoja nedoslednih podatkov. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 13

19 3.5. DOLOČANJE TABEL euporabnik Ime: Tip: Velikost: Opis: iduporabnik Int 5 Šifra uporabnika nuporabnik Alpha 30 Naziv uporabnika geslo Alpha 30 Geslo uporabnika Tabela 3 Uporabniki Ne vezano za postopek normalizacije smo morali ustvariti okolje, v katerem bomo lahko kontrolirali dostop do aplikacije. V ta namen smo ustvarili entiteto euporabnik, ki vsebuje naslednje atribute: iduporabnik šifra uporabnika, ki vsebuje enotno oznako uporabnika, nuporabnik naziv uporabnika ter geslo uporabnika. Ker izdelujemo prototipni model se ne bomo ukvarjali s prioritetami in pravicami posameznih uporabnikov ampak bodo vsi uporabniki imeli vse pravice na aplikaciji. eobdelava Ime: Tip: Velikost: Opis: idobdelava Int 5 Številka obdelave iduporabnik Int 5 Šifra uporabnika DatObd Date 8 Datum obdelave (LLLLMMDD) CasObd Alpha 6 Čas obdelave (UUMMSS) Obdobje Date 8 Za katero obdobje je obdelava (LLLLMMDD) Tabela 4 Obdelave Še ena entiteta, ki ni posledica normalizacije ampak je potrebna za boljše delovanje aplikacije. V tej entiteti bomo beležili, kdo in za katera obdobja je izvajal obdelavo. Sestavljajo jo naslednji atributi: idobdelava številka obdelave, vsebuje enotno številko obdelave, iduporabnik šifra uporabnika, ki je izvedel obdelavo, DatObd datum izvajanja obdelave, CasObd ura izvajanja obdelave ter Obdobje datumsko polje, ki vsebuje zadnji dan v mesecu, za katerega se je izvajala obdelava. Entiteta se bo polnila avtomatsko, ob vsakem izvajanju obdelave. Uporabnik bo imel na voljo pregled izvedenih obdelav. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 14

20 etelefon Ime: Tip: Velikost: Opis: TelStev Alpha 30 Telefonska številka iddelavca Int 5 Šifra delavca, ki ima SMT idnacobracuna Alpha 1 Način obračuna za izbran SMT Tabela 5 Telefoni V postopku normalizacije smo za naše potrebe iz objekta Račun naredili entiteto etelefon, ki jo sestavljajo atributi TelStev telefonska številka, tuja ključa iddelavca šifra delavca, ki ima SMT ter idnacobracuna kdo bo poravnal račun za SMT (posebna entiteta). edelavec Ime: Tip: Velikost: Opis: iddelavca Int 5 Šifra delavca ndelavca Alpha 30 Naziv delavca Alpha 30 Elektronski naslov delavca iddelkadslu Alpha 30 Šifra delavca v kadrovski službi Tabela 6 Delavci Entiteto edelavec sestavljajo atributi iddelavca šifra delavca, ndelavca naziv delavca, naslov elektronske pošte, kamor pošiljamo specifikacije računov in iddelkadslu šifra delavca v kadrovski službi, potrebna za izdelavo specifikacije, ki se pošilja kadrovski službi za odtegljaj pri obračunu plač. eracun Ime: Tip: Velikost: Opis: idobdelava Int 5 Številka obdelave TelStev Alpha 30 Telefonska številka SMT idstoritev Int 5 Šifra storitve Znesek VastInt 17,2 Znesek storitve Tabela 7 Računi Za naše potrebe smo iz objekta Račun naredili entiteto eracun, v kateri smo dodali atribut idobdelava kateri obdelavi pripada račun in ohranili atribute TelStev telefonska številka SMT ter Znesek znesek storitve. Šifro storitve in njen naziv pa smo v postopku normalizacije prestavili v samostojno tabelo, v tabeli eracun pa je ostal atribut idstoritev šifra storitve kot tuj ključ. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 15

21 estoritev Ime: Tip: Velikost: Opis: idstoritev Int 5 Šifra storitve nstoritev Alpha 30 Naziv storitve Priznano Alpha 1 Storitev priznana kot olajšava D Da N Ne Tabela 8 Storitve Tabela estoritev je nastala v postopku normalizacije in jo sestavljajo atributi idstoritev šifra storitve, nstoritev naziv storitve. Za potrebe obdelave podatkov smo dodali atribut Priznano storitev priznana kot olajšava, na osnovi katerega lahko podjetje npr. priznava naročnino ter klice MPO kot priznane olajšave. Zaradi posebnega polja za namen priznavanja olajšav smo dosti bolj prilagodljivi in se lahko v primeru, da mobilni operater doda novo storitev, odločimo, ali bo ta nova storitev priznana kot olajšava ali pa ne. Oznako lahko po potrebi spreminjamo tudi obstoječim storitvam. V našem primeru se je podjetje odločilo, da bo priznavalo storitev naročnina. especrac Ime: Tip: Velikost: Opis: idobdelava Int 5 Številka obdelave TelStev Alpha 30 Telefonska številka SMT idtipklica Int 5 Šifra tipa klica Stevilka Alpha 30 Na katero številko smo klicali DatKlica Date 8 Datum klica (LLLLMMDD) CasKlica Alpha 6 Čas klica (UUMMSS) Znesek VastInt 17,2 Znesek Tabela 9 Specifikacija opravljenih klicev Pri normalizaciji objekta specifikacija računa smo v osnovni tabeli pustili naslednje atribute: idobdelava številka obdelave, TelStev telefonska številka SMT, Stevilka številko, na katero smo klicali, DatKlica datum opravljenega klica, CasKlica ura opravljenega klica ter Znesek vrednost opravljenega klica. Z normalizacijo smo dobili še tabelo etipklica, v osnovni tabeli pa pustili idtipklica kot tuj ključ. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 16

22 etipklica Ime: Tip: Velikost: Opis: idtipklica Int 5 Šifra tipa klica Obracun Alpha 1 Ali upoštevamo kot olajšavo D/N Tabela 10 Tipi klicev V tabeli etipklica imamo atribute idtipklica šifra tipa klica ter atribut Obracun oznaka, ali se posamezni tip klica upošteva kot olajšava ali ne. V našem primeru bomo priznavali tip klica»telefonija«ter»sms oddaja«kot priznane, če bo klicana številka vpisana v tabeli službenih številk. estevilka Ime: Tip: Velikost: Opis: Stevilka Alpha 30 Službena številka Lastnik Alpha 30 Lastnik številke NacinVnosa Alpha 30 Ali je bila številka generirana ali ročno vnesena Tabela 11 Službene številke Tabela estevilka je namenjena za shranjevanje številk, ki jih podjetje definira kot službene številke. V praksi to pomeni, da se v tej tabeli nahajajo vse službene številke podjetja ter vse številke poslovnih partnerjev. Sestavljajo jo naslednji atributi: Stevilka službena številka, Lastnik lastnik številke in NacinVnosa ali je številka generirana ali ročno vnesena v tem primeru se vnese ime uporabnika, ki je številko dodal. Ker imajo poslovni partnerji več telefonskih številk v območju npr. od do , bomo namesto ročnega vnosa velikega števila telefonskih številk imeli program za generiranje telefonskih številk v območju. enacobracuna Ime: Tip: Velikost: Opis: idnacobracuna Alpha 1 Šifra načina obračuna nnacobracuna Alpha 30 Naziv načina obračuna Tabela 12 Načini obračuna Tabela enacobracuna je nastala v postopku normalizacije. Sestavljata jo dva atributa in sicer idnacobracuna šifra načina obračuna in nnacobracuna naziv načina obračuna. Atribut idnacobracuna ima lahko dve vrednosti in sicer;»c«- Podjetje v celoti poravna račun (npr. velja za UMTS telefone, s katerimi se dežurni delavci povezujejo z podjetjem oddaljen dostop) ali pa»d«- delno, plačilo po specifikaciji, kar pomeni, da podjetje priznava stroške na službene številke. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 17

23 3.6. PODATKOVNI MODEL Slika 4 Podatkovni model Zgornja slika prikazuje končni podatkovni model, ki je nastal kot rezultat postopka normalizacije. V podatkovni model smo dodali tudi nekaj entitet, s katerimi bomo lažje upravljali z aplikacijo (euporabnik, eobdelava). Potrebno je poudariti, da je prikazani model poenostavljen model, ki pa vendarle v celoti pokriva vse zahteve in lahko na osnovi tega naredimo prototipno aplikacijo, s katero bomo potrdili zastavljene cilje na začetku projekta. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 18

24 3.7. RAZVOJ PROTOTIPNE APLIKACIJE Za razvoj prototipne aplikacije je potrebno ustvariti posamezne tabele z njihovimi atributi ter narediti programe za vnos posameznih tabel (Storitve, Tipi klicev, Številke in Telefone). Glavni del aplikacije pa predstavlja program, s katerim obdelamo datoteko računov ter specifikacije računov in na osnovi parametrizacije posameznih telefonov, storitev ter tipov klicev naredimo ustrezen obračunski list za imetnika telefona. Kot poseben dodatek pa je potrebno na koncu obdelave vseh telefonov ustvariti še dodaten izpis za računovodski servis, kjer se izračunani zneski, ki jih morajo poravnati posamezni delavci, vnesejo v program za izračun plač in se nato odtegnejo od plače IZBIRA ORODJA ZA RAZVOJ PROTOTIPNE APLIKACIJE Kot smo že omenili v poglavju METODE DELA, bomo naredili prototipno aplikacijo v orodju ZIM, ki ga podjetje uporablja že več kot 18 let in ima v njem narejen tudi lasten integralni informacijski sistem za banke»omega«. Kaj je ZIM? ZIM je profesionalno okolje za razvoj aplikacij, ki tesno povezuje vse gradnike, ki jih potrebujemo za hitro načrtovanje, razvoj, testiranje, dokumentiranje in vzdrževanje kompleksnih aplikacij. Osnovni koncepti ZIM-a: Objektno-relacijski model (ang. Entity-Relationship), nadgradnja relacijskega modela Delo z množicami (ang. Set processing) Enostaven a močan objektno orientiran jezik 4 generacije (ang. 4GL) Uporabniški vmesnik temelji na dogodkih (ang. Event driven user interface) Vgrajen, visoko zmogljiv, odprt, več uporabniški sistem za upravljanje baz podatkov (ang. DBMS) Glede na enostavnost programskega jezika in leta osebnih delovnih izkušenj, je bila izbira ZIM-a logična rešitev. Ker gre za prototipni izdelek, je pomembna samo hitrost izdelave prototipa, da lahko ocenimo uporabnost aplikacije. Če bo prototip dokazal smiselnost izdelave aplikacije, se bo kot osnovo uporabil prototipni podatkovni model in se nadgradil v pravo aplikacijo, ki pa bo narejena v.net okolju. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 19

25 3.9. PRETOK PODATKOV V PROTOTIPNI APLIKACIJI Pri prototipni aplikaciji imamo sledeč pretok podatkov: najprej se prevzame podatke o opravljenih klicih s portala mobilnega operaterja (v našem primeru monitor.mobitel.si), ki se jih shrani na lokalni direktorij. Za pridobitev podatkov je potrebno imeti certifikat, ki se ga dobi pri mobilnem operaterju in omogoča varen dostop do podatkov o službenih mobilnih telefonih podjetja. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 20

26 Za prototipno rešitev smo se odločili, da bomo te podatke prenašali ročno, ker bi sicer porabili preveč časa na vzpostavljanju in izgradnji varnega protokola za avtomatsko izmenjavo podatkov med podjetjem in mobilnim operaterjem. Po opravljenem ročnem prenosu se podatke o opravljenih klicih posameznih službenih mobilnih telefonov prevzame v aplikacijo, kjer se jih obdeluje naprej. V fazi priprave podatkov se lahko vnaša morebitne nove službene številke ali pa se vnesejo številke, ki jih naknadno prijavijo zaposleni kot službene, ko dobijo kontrolni obračun. V fazi obračuna se obračuna dejanska poraba službenega mobilnega telefona, ki se nato izpiše in po -u pošlje uporabniku službenega mobilnega telefona. Vsak uporabnik je dolžan preveriti prejeti obračun in javiti morebitne nove službene številke, da se dodajo v bazo in upoštevajo pri obračunu. Ko vsi uporabniki potrdijo pravilnost obračuna, se pripravi datoteka s podatki o bremenitvah za posameznega lastnika službenega mobilnega telefona, ki se jo posreduje računovodskemu servisu, ki obračunava plače. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 21

27 3.10. PRETOK PODATKOV V FAZI OBRAČUNA Sam obračun poteka tako, da se entiteta etelefon, ki vsebuje vse službene mobilne telefone, poveže z entiteto eracun, v kateri imamo podatke o prejetih računih za službene mobilne telefone po storitvah ter nato še naprej z entiteto estoritev, v kateri imamo označeno, katere storitve plačuje podjetje in katere ne (atribut estoritev.priznano). Za posamezni službeni mobilni telefon seštejemo vse storitve, da dobimo celoten znesek računa za posamezni službeni mobilni telefon. Nato seštejemo vse storitve posameznega službenega mobilnega telefona, ki imajo oznako, da se priznavajo. Sedaj imamo za posamezni službeni mobilni telefon znesek računa ter znesek priznanih storitev, rabimo pa še znesek priznanih klicev. Za znesek priznanih klicev pa moramo povezati entiteto etelefon in entiteto especrac, v kateri imamo specifikacijo opravljenih klicev za posamezni službeni mobilni telefon. To naprej povežemo z entiteto etipklica, v kateri imamo atribut Obracun, ki nam pove, ali posamezen klic priznavamo kot olajšavo ali pa ne. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 22

28 Tako lahko sedaj za vsak službeni mobilni telefon izračunamo vsoto priznanih klicev. V prejšnjem koraku smo dobili znesek računa in znesek priznanih storitev, sedaj pa imamo še znesek priznanih klicev. To pa je tudi vse, kar potrebujemo za obračun, koliko mora posamezni imetnik službenega mobilnega telefona plačati za uporabo le tega. Ker ima lahko imetnik službenega mobilnega telefona vsak mesec nove službene klice na nove službene številke, moramo imetniku službenega telefona posredovati, katere številke, ki jih ima na specifikaciji računa, nismo upoštevali kot službene klice. Imetnik po elektronski pošti dobi račun z vsemi storitvami, vsoto priznanih klicev ter končni znesek, ki ga mora plačati, prav tako pa seznam številk z zneskom, ki se mu ne priznavajo kot službene številke. Na osnovi tega dokumenta lahko imetnik službenega mobilnega telefona sporoči, da ima za pretekli mesec še kakšno novo službeno številko in kdo je lastnik te številke, nato pa lahko pooblaščen uporabnik to številko vnese v bazo službenih številk (entiteta estevilka). Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 23

29 4. PROTOTIPNA APLIKACIJA Izdelava aplikacije v ZIM-u običajno poteka po naslednjem vrstnem redu: Analiza problema Ustvarjanje podatkovnega slovarja za novo aplikacijo Ustvarjanje potrebnih objektov v podatkovnem slovarju (entitete, relacije, dokumenti, spremenljivke, ) Ustvarjanje vnosnih ekranov (mask) Izdelava potrebnih programov in testiranje 4.1. ANALIZA PROBLEMA Sama analiza problema je že opisana v predhodnih poglavjih USTVARJANJE PODATKOVNEGA SLOVARJA ZIM za svoje delovanje potrebuje podatkovni slovar (ang. Data Dictionary), v katerega se zapisujejo informacije o ustvarjenih objektih. Ustvarjanje se izvede z ukazom ZIMINIT, ki ustvari prazen podatkovni slovar, na katerem lahko začnemo z delom USTVARJANJE OBJEKTOV V PODATKOVNEM SLOVARJU Za dodajanje, spreminjanje in brisanje objektov se uporablja ZIM razvojni center (ang. Development center). Slika 5 ZIM razvojni center Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 24

30 Uporabljamo opcijo Podatkovni slovar (ang. Data Dictionary), ki nam omogoča upravljanje z vsemi razpoložljivimi objekti. Slika 6 ZIM podatkovni slovar ENTITETE Spodnja slika prikazuje pregled ustvarjenih entitet: Slika 7 Pregled entitet Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 25

31 Slika 8 Pregled polj entitete edelavec Slika 9 Pregled atributov polja edelavec.iddelavca Na zgornji sliki vidimo, katere atribute lahko definiramo posameznemu polju: Tip polja. Možni tipi: alpha, varalpha, char, varchar, date, int, longint, vastint ali numeric. Razlika med tipoma alpha in char je v tem, da je tip char občutljiv na velike in male črke (ang. Case sensitive). Razlika med tipoma alpha in varalpha pa je v tem, da se pri tipu alpha v podatkovno bazo zapiše dejansko število zlogov, kot znaša vrednost v polju»dolžina polja«, pri tipu varalpha pa se v podatkovno bazo zapiše dejansko vneseni znaki + 2 zloga za informacijo o dolžini zapisa. Tip varalpha uporabljamo takrat, ko pričakujemo relativno majhno povprečno dolžino polja vendar imamo izjeme, ki od tega odstopajo. ZIM prepoznava datum kot svoj tip in v primeru operacij z datumskim poljem tudi pravilno izvaja računske operacije - npr. pri odštevanju dveh datumov dobimo Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 26

32 kot rezultat število dni med tema datuma. Numerični tipi int, longint in vastint pa se razlikujejo po velikosti zapisa v bazi in sicer zasedajo 2, 4 oz. 8 zlogov. Tip numeric pa zasede po en zlog za vsak znak (digit). Ta tip je poleg alpha tudi edini možni zapis števila v dokumentu s polji. Dolžina polja Prikazana dolžina polja (uporabno pri npr. polnem nazivu podjetja, ki je lahko maksimalno 440 znakov, vendar ne želimo, da nam pri pregledu celoten ekran zakrije samo to polje) Število decimalnih mest Zaporedna številka polja v entiteti vpliva na vrstni red izpisa polj Indeks možne opcije No, Yes, Unique Virtualno/navidezno polje ZIM omogoča, da se v entitetah uporablja tudi polje, ki se lahko dinamično izračunava. Formula, ki definira polje, je lahko kakršna koli veljavna ZIM formula ni nobenih omejitev, lahko se npr. uporabljajo sistemske spremenljivke, konstante, polja v tabeli itd Obveznost vnosa Osnovna vrednost (ang. Default) ko želimo polju prirediti neko inicialno vrednost pri dodajanju npr. sistemski datum v polje datum knjiženja Ime, ki se izpisuje nad poljem v pregledih in poročilih Maska, s katero lahko prilagodimo izgled polja v pregledih in poročilih V podatkovnem slovarju lahko tudi označimo, kako je polje selektivno pri iskanju po enakosti, v območju (ang. Between) in odprtem območju (večje, manjše, ). Na ta način lahko vplivamo na hitrost izvajanja posameznih ukazov, ki sicer uporablja v naprej definirana pravila (če v pogoju iskanja nastopa polje z indeksom in polje brez indeksa, bo ZIM Strategy Analyzer uporabil polje z indeksom). Poleg entitet, ki smo jih opisali v poglavju DOLOČANJE TABEL, moramo v ZIM podatkovnem slovarju ustvariti tudi relacije med entitetami: Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 27

33 RELACIJE IN MOŽICE Slika 10 Relacije med entitetami ZIM kot objektno relacijski model in kot 4 generacija programskih jezikov (4GL) omogoča zelo enostavno in intuitivno povezovanje entitet ter obdelovanje podatkov v njih. Za primer vzamemo povezovanje entitet edelavec in etelefon. V entiteti etelefon se nahaja tuj ključ iddelavca, ki nam pove, kdo uporablja telefon. V običajni relacijski podatkovni bazi bi ti dve entiteti povezali z naslednjim SQL stavkom: SELECT * FROM edelavec, etelefon WHERE edelavec.iddelavca=etelefon.iddelavca Če moramo npr. izbrati samo delavce s telefoni, ki imajo način obračuna = 'C' v celoti podjetje, moramo dodati še en pogoj: SELECT * FROM edelavec, etelefon WHERE edelavec.iddelavca=etelefon.iddelavca AND etelefon.idnacobracuna='c' Kot vidimo na zgornjem primeru, se hitro zgubi preglednost, kaj je pogoj za povezovanje in kaj so dodatni kriteriji. Sam pogoj za povezovanje običajno nastopa na več mestih in zato moramo v primeru spremembe pogoja za povezovanje popravljati več programov. Prednost ZIM-a je v tem, da ima pogoje za povezovanje (relacije) zapisane v podatkovnem slovarju in na ta način je zadeva bolj pregledna in učinkovita. ZIM pozna SQL strukturo ukazov in lahko zgoraj naveden primer tudi izvedemo: Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 28

34 Slika 11 Primer uporabe SQL v ZIM-u Slika 12 Primer uporabe relacij in množic Slika 12 prikazuje povezovanje dveh tabel z uporabo relacije rdel_telefon, ki ima v podatkovnem slovarju opisan pogoj za povezavo teh tabel: Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 29

35 Slika 13 Opis relacije v ZIM-u Vendar pa ima ZIM še eno prednost, ki smo jo omenili na začetku delo z množicami. Slika 12 tudi prikazuje, da smo med povezovanjem entitet edelavec in etelefon ustvarili množico z imenom x_set, v katero smo dobili 4 zapise (4 processed). Ustvarjena množica se obnaša kot entiteta, zato jo lahko pregledujemo (ukaz LIST), urejamo, brišemo, Množica v ZIM-u so samo kazalci, ki kažejo na dejanske zapise v podatkovni bazi, zato se pri uporabi množice ne more več uporabljati indeksov. Nam pa množice omogočajo enostavno sprehajanje po zapisih v množici (skok na začetek TOP, na dno BOTTOM, na n-ti zapis itd)., kar s pridom uporabljamo pri prikazovanju podatkov uporabniku. Velika prednost nad relacijskimi bazami podatkov je tudi možnost spreminjanja zapisov v sestavljeni množici (množica, ki je sestavljena iz več tabel). Ker se množica obnaša kot entiteta, lahko enostavno v enem koraku priredimo polju v prvi entiteti vrednost polja iz druge entitete. V primeru relacijskih baz je za to potrebno uporabljati ugnezden SQL stavek. Nad množicami lahko izvajamo 3 operacije Unija (ang. Union), Presek (ang. Intersect) ter Razlika (ang. Minus). Pogoj za izvajanje teh operacij je enaka struktura množic. Prav tako pa lahko pri ustvarjanju množic uporabimo še tri dodatne ukaze: COMPLETE, ko želimo povezati dve tabeli ne glede na to, ali posamezen zapis izpolnjuje pogoje za povezovanje (v relacijski bazah je to OUTER JOIN) UNRELATED, ko želimo dobiti nepovezane zapise. Končni rezultat je enak, kot če bi naredili razliko med COMPLETE povezano množico in normalno povezano množico. KEEP, ko želimo iz sestavljene množice obdržati samo določene entitete (eno ali več) Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 30

36 DOKUMENTI Slika 14 Dokumenti Dokumenti, ki jih ustvarimo v podatkovnem slovarju, imajo logično ime (DocName) in fizično ime (FileName). Logično ime se uporablja znotraj ZIM-a v programih, fizično ime pa pove, kje na disku se datoteka nahaja in kakšno ime ima na disku. Prav tako mora fizično ime upoštevati omejitve datotečnega sistema, na katerem se izvaja ZIM aplikacija (dolžina imena, prepovedani znaki itd). Dokumenti v ZIM-u se lahko uporabljajo na več načinov. Najbolj običajen je, da je v dokumentu zapisana ZIM koda, ki se lahko izvaja. V tem primeru lahko govorimo o programu. Vendar pa dokumente lahko uporabljamo tudi na druge načine. Način dela v podjetju Gora d.o.o., Ljubljana je takšen, da se vse izpise najprej kreira v datoteko (listo), ki jo nato ponudimo uporabniku v pregled. Nato pa ima uporabnik možnost, da listo pošlje na poljuben tiskalnik, ki je definiran na sistemu. Takšen način dela z izpisi je ostal še iz časov, ko so uporabniki dostopali do aplikacije podjetja preko terminalov, ki so bili priključeni na centralni strežnik in ni bilo običajno, da bi vsak uporabnik imel svoj tiskalnik. Dodatna prednost takšnega načina dela z izpisi pa je tudi ta, da uporabniku ni potrebno izpisati celotno poročilo, da bi pogledal vsoto na zadnji strani, kar se je običajno dogajalo v praksi. V ZIM-u pa lahko dokumentom dodamo tudi polja in se na ta način dokument obnaša kot entiteta, seveda z zelo omejeno funkcionalnostjo. Podatke lahko zapisujemo, beremo, ne moremo pa jih (enostavno) spreminjati. Takšen dokument lahko povežemo z ostalimi entitetami ali dokumenti z relacijo, ki jo definiramo na enak način kot pri entitetah. Prav tako lahko npr. enostavno seštejemo vrednosti posameznega atributa v celotni datoteki, ali pa pod določenimi pogoji. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 31

37 Običajno takšne dokumente uporabljamo za uvažanje podatkov v aplikacijo ali pa kot pomožne entitete, v katere shranjujemo vmesne rezultate obdelav. Za en program običajno potrebujemo 4 dokumente. Če si pogledamo na primeru entitete edelavec, imamo narejene naslednje dokumente: pdelavec koda programa za vnos in spreminjanje entitete idelavec izpis vsebine entitete ldelavec dokument (lista), v katerega izpišemo vsebino entitete vdelavec koda programa za izbiro zapisa iz entitete (ang. LookUp) Za potrebe uvoza podatkov v aplikacijo smo definirali tudi 2 dokumenta (xracun in xspecrac) SPREMENLJIVKE Slika 15 Seznam globalnih spremenljivk ZIM zahteva definiranje vseh globalnih spremenljivk v podatkovnem slovarju, kar pripomore k kvaliteti napisanih programov. Tipi spremenljivk so enaki kot pri definiranju atributov entitete. Globalna spremenljivka je definirana na nivoju posameznega uporabnika in se lahko spreminja v različnih programih. Poleg globalnih spremenljivk pa ZIM pozna tudi lokalne spremenljivke, ki se definirajo v vsakem programu, vendar se vrednost le teh ne prenaša izven programa. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 32

38 4.4. USTVARJANJE VNOSNIH EKRANOV Za vnos podatkov v entitete je potrebno ustvariti forme (ang. Forms). Posamezne forme se lahko združujejo v zaslone (ang. Displays), ki jih običajno uporabljamo. Vsak zaslon je običajno sestavljen iz vsaj dveh form in sicer splošne forme z imenom fhead, v kateri so definirana polja, ki se ponavljajo na vsakem ekranu (naslov programa, funkcijske tipke, pomoč, informacije itd) ter iz namenske forme za določeno opravilo (npr. vnos/pregled/spreminjanje entitete). Slika 16 Zaslon ddelavec med izdelavo Na zgornji sliki vidimo izgled zaslona v programu za izdelavo form in zaslonov (ang. Form Painter). Ko urejamo zaslon, lepo vidimo, da je zaslon sestavljen iz dveh form in sicer sta zgornji 2 vrstici in spodnje 3 vrstice del forme fhead, na kateri se prikazujejo splošne informacije kot so naslov programa, datum, funkcijske tipke ter sredinskega dela, ki je namenjen za delo z entiteto edelavec (forma fdelavec). Slika 17 prikazuje, kako je zaslon ddelavec viden v aplikaciji. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 33

39 Slika 17 Izgled zaslona ddelavec v aplikaciji Slika 18 Prikaz atributov polja na zaslonu Slika 18 prikazuje, kateri atributi sestavljajo polja na zaslonu. Vsako polje ima: Ime polja, ki je običajno enako imenu v entiteti Ime forme, na kateri se polje nahaja Številka polja, preko katere lahko program dobi informacijo, na katerem polju se je zgodil določen dogodek Zaporedna številka Tip polja ali je labela (Prompt) ali pa vnosno polje (Variable) Podatkovni tip (Numeric, Calculator, Date, Box, Line ter Message) Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 34

40 Zaščita (Protected, Unprotected, Guarded - lahko gremo v polje vendar ni možno spreminjati vsebine) Obveznost vnosa (No, Yes, Immediate - ne moremo zapustiti polja, če ne vnesemo vrednosti) Vrstica, v kateri se nahaja polje na ekranu Stolpec, v katerem se nahaja polje na ekranu Širina polja Višina polja Če je polje preveliko za prikaz na ekranu, se lahko omogoči pomikanje vsebine Način prikaza (Normal, Reverse, Underline, High intensity, Blink, Invisible, Suppress) Barva ozadja Barva pisave S katerim znakom je napolnjeno polje Ali se po vnosu zadnjega znaka v polju avtomatsko prestavi v novo polje Ali se pri novem vnosu avtomatsko izbriše stara vrednost Poravnava vrednost v polju (No, Left, Center, Right, Wrap) Velikost znakov (Mixed, Lower, Upper) Ali so možne okrajšave glede na pravila vnosa Stiskanje ali se podatkovna maska vključuje v vrednost polja ali ne Minimalna dolžina vnosa Ali je dovoljena vrednost null (v ZIM-u $null) Ali se po vstopu v polje vrne kontrola programu (No, Yes) Ali se po izhodu iz polja vrne kontrola programu (No, Yes, Always) Pravila kontrole Maska za prikaz podatkov Sporočilo za pomoč pri vnosu, ki se prikazuje v polju tipa Message Sporočilo v primeru napake, ki se prikazuje v polju tipa Message Osnovna vrednost Kot vidimo iz zgoraj naštetih atributov, se v podatkovnem slovarju nahaja podroben opis, kako naj se posamezno polje obnaša pri vnosu podatkov. V prilogi 1 je podrobneje opisan ZIM način dela pri delu z zasloni. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 35

41 4.5. IZDELAVA POTREBNIH PROGRAMOV IN TESTIRANJE Kot smo že omenili, moramo za vsako entiteto narediti program za vnos, spreminjanje in brisanje ter za izpis. Pri entitetah, ki jih uporabljamo kot tuje ključe, pa moramo narediti še programe za vpogled. To smo podrobneje opisali v poglavju DOKUMENTI. Potrebno je izdelati tudi program za prijavo v aplikacijo, menu ter še nekaj ostalih pomožnih programov. Ker smo za razvojno okolje izbrali orodje, ki se že vrsto let uporablja v podjetju Gora d.o.o., Ljubljana, smo te programe že imeli in smo jih samo vključili v našo prototipno aplikacijo. Slika 19 Začetni meni aplikacije V prilogah 2 in 3 smo tudi podrobneje opisali osnovne načine delovanja ZIM-a pri vnosu, spreminjanju in brisanju podatkov v entitetah ter način izdelave poročil. Na tem mestu bi samo na kratko opisali program za vpogled in izbiro tujih ključev. Če imamo v entiteti tuj ključ, potem uporabniku dovolimo, da s standardno tipko F7- Šifrant odpre posebno okno, v katerem lahko najde zapis v tuji tabeli ter ga izbere za vnos. Znotraj tega programa lahko s tipkama F7 in F8 urejamo zapise po šifri in nazivu, s tipkami Home, End, PageUp, PageDown, Gor, Dol se sprehajamo po zapisih ter s tipko Enter izberemo želen zapis. S tipko Esc pa se lahko premislimo in prekinemo izbor tujega ključa. Slika 20 prikazuje izgled programa za vpogled in izbiro tujih ključev. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 36

42 Slika 20 Vpogled (ang. LookUp) v tuj ključ V poglavju DOKUMENTI smo napisali, da se vse izpise naredi v poseben dokument (listo), ko jo nato pokažemo uporabniku. Uporabnik lahko izdelano listo pogleda na ekran ali pa natisne na tiskalnik, ki ga ima na razpolago. Slika 21 Možnost pregleda poročila in izbire tiskalnika Na zgornji sliki vidimo, da ima uporabnik možnost pregleda poročila na ekranu (opcija 1) ali pa izpis na različnih tiskalnikih (opcije 2 do 5). Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 37

43 Slika 22 Izgled izpisne liste delavcev Če uporabnik izbere opcijo 1 Ekran, potem lahko pregleda izdelano poročilo na ekranu. Na ta način uporabniku ni potrebno izpisati celotne liste, da bi npr. pogledal končni rezultat na zadnji strani poročila. Ker za pregled in izpis poročil uporabljamo program, ki je definiran na sistemskem nivoju in ne na aplikativnem (v sami aplikaciji), lahko končni uporabnik samostojno brez vmešavanja v aplikacijo dodaja nove tiskalnike KONVERZIJA VHODNIH FORMATOV Za potrebe uvoza podatkov v aplikacijo smo definirali tudi 2 dokumenta (xracun in xspecrac). Ker se v datoteki specifikaciji računa nahaja več različnih formatov (za nas zanimiv IZPIS ODHODNIH POGOVOROV ter še dodatna IZPIS ZUNANJIH STORITEV ter IZPIS POSREDOVANIH PLAČIL), smo morali iz datoteke izločiti dodatna formata. Ker posamezna vrstica na začetku nima oznake, v katerem formatu so podatki ter ker ne potrebujemo vseh polj v vrstici, smo se odločili za rešitev, ki nam omogoča, da v enem koraku rešimo oba problema. UNIX okolje je znano po majhnih vendar zelo učinkovitih programčkih, kjer lahko na nivoju lupine (ang. Shell) izvedemo kompleksne obdelave z relativno enostavnimi ukazi. Rešitev naših težav je program z imenom AWK. Kot lahko preberemo na spletni strani je AWK programski jezik, narejen za obdelavo tekstnih podatkov v datotekah ali tokovih (ang. Streams). Naredili so ga leta 1977 v AT&T Bell Laboratories. Ime je sestavljeno iz prvih črk priimkov avtorjev Alfred Aho, Peter Weinberger in Brian Kernighan. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 38

44 AWK je zaradi svojih lastnosti prvo močno orodje na Unix-u za delo z besedilom, zaradi tega pa je zelo uporaben pri skrbništvu sistema in pri vsakdanjem delu navadnih uporabnikov. AWK jezik se razlikuje od vsakdanjih programerskih jezikov po tem, da je odvisen od dogodkov. To se odraža pri njegovi skladnji. Program je sestavljen iz pogojev, ki jim ustreza iskalni regularni izraz, in iz dejanj, ki sledijo, če je pogoj izpolnjen. Da obdelamo neko datoteko (vhodna_datoteka) z AWK -om, poženemo ukaz: awk f ukazi.awk vhod.txt Parameter f pove, da se ukazi za izvajanje nahajajo v datoteki ukazi.awk. Vhodni podatki pa se nahajajo v datoteki vhod.txt. Kot smo že omenili, je program sestavljen iz pogojev in dejanj. Pogoj, pri katerem se izvede neko dejanje, opišemo z logičnim izrazom, ali z regularnim izrazom med poševnicami. Tolmač za AWK izvede datoteko z ukazi (skripto) po naslednjem receptu: 1. naloži skripto in jo prevede v interno obliko, to pa hitro izvaja, 2. izvede stavke v bloku BEGIN, če ta obstaja, 3. odpre vhodno datoteko, 4. prebere vrstico vhodne datoteke, 5. izvede vsa dejanja, za katera je pogoj resničen, 6. dokler nismo na koncu vhodne datoteke, se vrne na točko 4, 7. zapre vhodno datoteko, 8. izvede stavke v bloku END, če ta obstaja. AWK pozna nekaj uporabnih dogovorov, kaj naj stori, če izpustimo katerega od skladenjskih elementov. Če manjka pogoj, se dejanje izvede za vse vrstice. Če smo zapisali pogoj, vendar manjka dejanje, AWK privzame, da je to izpis tekoče vrstice z ukazom { print; }. Za naš primer je pomembno, da lahko definiramo, kateri znak je ločilo med posameznimi polji v zapisu in kateri znak je ločilo med zapisi. Če pogledamo AWK program za pripravo podatkov o specifikacijah računov, lahko vidimo, da smo za ločilo med polji (ang. Field Separator) izbrali znak»\t«, ki predstavlja tabulator. BEGIN {FS="\t"} { if ($12>"") print $1 "#" $12 "#" $10 "#" $11 "#" $4 "#" $5 } Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 39

45 V nadaljevanju se za vsako vrstico (zapis) preverja, ali je polje 12 vsebuje vrednost in če je ta pogoj izpolnjen, izpišemo polja 1, 12, 10, 11, 4 in 5. Na ta način se znebimo nepotrebnih polj, hkrati pa tudi spremenimo ločilo med polji na znak»#«, ki ga ZIM lažje obdeluje. Prav tako spremenimo tudi vrstni red polj. V primeru prevzema podatkov za račune pa imamo na začetku ponovno definiran tabulator kot znak za ločilo med polji, v nadaljevanju pa izpišemo polja 1, 2, 3, 4 in 7 in sicer le v primeru, če se prvo polje začne s številko. BEGIN {FS="\t"} { if ($1 ~ /^[0-9]/) print $1 "#" $2 "#" $3 "#" $4 "#" $7 } GLAVNI PROGRAM Slika 26 Začetni ekran obdelave prikazuje, da kot vhodni parameter vnašamo leto in mesec, za katerega želimo izvesti obdelavo. V imeniku, kjer se nahajajo vhodne datoteke, se pričakuje, da imajo datoteke v imenu tudi leto in datum, za katerega vsebujejo podatke. Tako program pričakuje račune v datoteki z imenom racunllmm*.xls, kjer LL pomeni dvomestno leto, MM pa mesec. Nadaljevanje imena ni pomembno, važno je le, da ima končnico».xls«specifikacije računov se morajo prav tako nahajati v datotekah s končnico».xls«, vendar pa je oblika imena *LLLLMM.xls, kjer je LLLL leto in MM mesec. Po pritisku na tipko F10 se najprej izvede AWK program, ki iz navedenih vhodnih datotek ustvari datoteko računov (xracun.dat) in datoteko specifikacij računov (xspecrac.dat). Kot smo že omenili v poglavju KONVERZIJA VHODNIH FORMATOV, smo podatke tudi ustrezno prilagodili našim potrebam. Ko podatke prevzamemo v aplikacijo, najprej preverimo, ali imamo morda pomanjkljivo parametrizacijo. Tako nas npr. program opozori, če se pojavi nov mobilni telefon: Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 40

46 Slika 23 Kontrola vhodnih podatkov Po opravljenih kontrolah se izvede obračun in kot rezultat dobimo specifikacijo računa za vsakega delavca. Specifikacija se po elektronski pošti pošlje vsakemu delavcu, ki jo nato pregleda in sporoči morebitne nove službene številke. Primer specifikacije računa, ki se jo pošilja delavcu: GORA d.o.o. MOBITEL poraba Stran: 5 pnapolni 19/02/ :06 ================================================================================ 41760XXX Delavec_01 KS_01 Storitev Naročnina Popust na naročnino Pogovori v omrežjih Mobitel Pogovori znotraj MPO Pogovori v ostala slovenska om Pogovori iz Slovenije Sprejeti klici v tujini Pogovori / storitve v tujini Posredovanje pogovorov/storite Prenos podatkov - GPRS/UMTS Kratka sporočila - SMS Multimedijska sporočila - MMS Popust Priznano SMS oddaja Priznano Telefonija Znesek računa: Naročnina: 7.99 Priznano: Za plačilo: 3.12 Nepriznani klici XXX XXX XXXXX XXX XXX XXX XXX 0.32 Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 41

47 V nadaljevanju vidimo še zbirno porabo vseh mobilnih telefonov s kadrovsko številko. Lista se posreduje računovodskemu servisu, da lahko pri obračunu plač poravna obveznosti delavca za služben mobilni telefon. GORA d.o.o. MOBITEL poraba - zbirno Stran: 1 pnapolni 19/02/ :06 Telefon Imetnik Račun Naročnina Priznano Plačilo ================================================================================ 51375XXX C Delavec_24 KS_ XXX C Delavec_25 KS_ XXX C Delavec_26 KS_ XXX C Delavec_30 KS_ XXX D Delavec_01 KS_ XXX D Delavec_02 KS_ XXX D Delavec_03 KS_ XXX D Delavec_05 KS_ XXX D Delavec_06 KS_ XXX D Delavec_07 KS_ XXX D Delavec_08 KS_ XXX D Delavec_10 KS_ XXX D Delavec_11 KS_ XXX D Delavec_12 KS_ XXX D Delavec_13 KS_ XXX D Delavec_14 KS_ XXX D Delavec_15 KS_ XXX D Delavec_16 KS_ XXX D Delavec_17 KS_ XXX D Delavec_18 KS_ XXX D Delavec_19 KS_ XXX D Delavec_20 KS_ XXX D Delavec_21 KS_ XXX D Delavec_22 KS_ XXX D Delavec_23 KS_ XXX D Delavec_27 KS_ XXX D Delavec_28 KS_ XXX D Delavec_29 KS_ ================================================================================ Po končanem pregledu nas program še vpraša, ali potrdimo obdelavo: Slika 24 Potrditev obdelave Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 42

48 Za lažjo kontrolo izvedenih obdelav smo naredili tudi pregled izvedenih obdelav: Slika 25 Pregled obdelav TESTIRANJE Samo testiranje aplikacije se je redno izvajalo med razvojem programov, prav tako pa smo po končanem razvoju aplikacije izvedli še celoten test aplikacije. V testiranje smo vključili tudi vse imetnike službenih mobilnih telefonov, ki so morali preveriti pravilnost svojega obračuna za mesec December 2008 ter pripraviti službene številke, na katere kličejo. Po vnosu vseh novih službenih številk smo ponovili obdelavo ter delavcem v kontrolo ponovno poslali specifikacijo. Na novo prejete specifikacije delavci niso imeli pripomb. Miro Stefanišin: Programska rešitev za spremljanje uporabe službenih mobilnih telefonov stran 43