razvoj aplikacije za podporo administrativnim … · marketinga vodja µv}À} À vodja vodja it...

Diplomsko delo univerzitetnega študija Organizacija in management informacijskih sistemov

RAZVOJ APLIKACIJE ZA PODPORO ADMINISTRATIVNIM PROCESOM V

ORGANIZACIJI

Mentor: doc. dr. Davorin Kofjač Kandidat: Simon Kralj

Kranj, september 2017

ZAHVALA Zahvaljujem se mentorju, doc. dr. Davorinu Kofjaču, za nasvete in pomoč pri izdelavi naloge, Romani Špenko za lekturo in podporo v času študija, ter svoji družini za podporo v času študija.

POVZETEK

Podjetja veliko pozornosti posvečajo temu, da svojim strankam ali naročnikom nudijo najboljše možne storitve, pri tem pa pogosto pozabljajo na izboljšave pri vodenju internih procesov. Ti so pogosto vodeni oz. dokumentirani v papirni obliki, zaradi česar je upravljanje z zahtevami ob rasti podjetja oteženo, interni stroški pa višji. Z vpeljavo aplikacije za vodenje internih poslovnih procesov v elektronski obliki lahko podjetja znižajo svoje stroške, saj se čas, ki bi ga zaposleni porabili za tiskanje in prenašanje zahtev v papirni obliki znatno zmanjša. V diplomski nalogi je predstavljen proces razvoja aplikacije, ki bo končnemu naročniku omogočila informacijsko podporo za vodenje internih poslovnih procesov. V nalogi so ovrednoteni tudi stroški, ki so povezani s tovrstnimi internimi poslovnimi procesi in prihranek, ki bi ga dosegli ob uvedbi aplikacijske podpore.

KLJUČNE BESEDE: - Spletna aplikacija - Poslovni procesi - JAVA - JSF - MYSQL - Open Source - Slapovna metodologija

ABSTRACT Businesses today are focused on providing the best possible service to their customers, but often forget about their own internal processes and how they are managed. These processes are often still paper-based, and with company growth, such processes are more difficult to manage and present a greater cost for the company. With the introduction of an application for managing internal business processes electronically, companies can lower their costs because the time spent by employees for printing and transferring paper requests will be significantly reduced. The thesis presents the development process of an application that will enable the client to electronically manage internal business processes. The thesis also includes evaluation of costs associated with such internal business processes and the savings due to the switch to application support.

KEYWORDS: - Web application

- Business processes - JAVA - JSF - MYSQL - Open Source

- Waterfall methodology

KAZALO 1. Uvod ....................................................................................... 1

1.1. Predstavitev problema ............................................................ 1 1.2. Predstavitev okolja ................................................................ 1 1.3. Predpostavke in omejitve ......................................................... 2 1.4. Metode dela......................................................................... 2

2. Teoretične osnove ....................................................................... 4 2.1. Opredelitev osnovnih pojmov .................................................... 4

3. Obstoječe stanje ....................................................................... 14 4. Popis funkcionalnosti sistema ........................................................ 17

4.1. Prijava v sistem in varnost ....................................................... 17 4.2. Orodna vrstica ..................................................................... 19 4.3. Administracija uporabnikov ..................................................... 19 4.4. Administracija zahtevkov ........................................................ 20 4.5. Začetna stran ...................................................................... 23 4.6. Vsebina zahtevka ................................................................. 24 4.7. Postopek dodeljevanja ZAHTEVKOV ............................................ 27 4.8. Primer procesa .................................................................... 29

5. Izdelava aplikacije ..................................................................... 37 6. Zaključki ................................................................................. 40

6.1. Ocena učinkov ..................................................................... 40 6.2. Pogoji za uvedbo .................................................................. 40 6.3. Možnosti nadaljnjega razvoja ................................................... 41

Literatura in viri ............................................................................. 42 Kazalo slik .................................................................................... 44 Kazalo izvlečkov kode ....................................................................... 45

Univerza v Mariboru – Fakulteta za organizacijske vede Diplomsko delo univerzitetnega študija

Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 1

1. UVOD V današnjem času kljub vse širši uporabi IT v organizacijah ni dovolj poudarka na optimizaciji in avtomatizaciji internih procesov, ki potekajo vsakodnevno. Marsikateri takšen proces še vedno poteka v papirni obliki. Primer takšnega internega procesa je proces za oddajo zahteve za dopust. Zaposleni v organizaciji poišče ustrezen obrazec, ga natisne in izpolni, nato pa odnese v podpis nadrejenemu, itd. Korake procesa, kot so izpolnjevanje in prenos zahtevka se z uporabo IT tehnologij lahko časovno skrajša in poenostavi, si čimer v organizaciji zmanjšamo stroške. V diplomski nalogi bo predstavljen proces izgradnje spletne aplikacije, ki omogoča avtomatizacijo vodenja oziroma upravljanja zahtevkov. Ključna funkcionalnost takšne aplikacije je tudi, da administrator lahko definira poljubno različnih procesov z minimalnimi programskimi spremembami. V diplomski nalogi bomo predstavili tudi nekaj tipičnih primerov procesov ter vpliv na stroške organizacije.

1.1. PREDSTAVITEV PROBLEMA V diplomski nalogi bomo opisali postopek izdelave aplikacije, ki bo srednje veliki izbrani organizaciji omogočila elektronsko vodenje poslovnih procesov. V podjetju se vse od ustanovitve vsi poslovni procesi vodijo v papirni obliki. Vodilni v podjetju so ugotovili, da s takšnim načinom vodenja poslovnih procesov nastajajo dodatni stroški, ki pa bi jih želeli na dolgi rok čimbolj zmanjšati. Uvedba novega sistema bi bila postopna. V prvi fazi bi bila implementirana aplikacija in izdelan samo en tip poslovnega procesa. Kasneje pa bi se dodajali dodatni postopki in naloge, ki so v podjetju pogoste. Poleg tega se vodstvo podjetja zaveda, da izdelava takšnega sistema prinaša določene stroške. Na dolgi rok pa želijo, da nov sistem temelji na tem, da bodo sprotni stroški (stroški licenc) karseda nizki, ter da bi bil sistem preprost za uporabo.

1.2. PREDSTAVITEV OKOLJA V podjetju se ukvarjajo s proizvodnjo ter dostavo in montažo pohištva po naročilu končnim strankam, ki so tako fizične kot pravne osebe. Podjetje je bilo ustanovljeno leta 1990 in ima 76 zaposlenih. Novi sistem bi uporabljali vsi zaposleni. Vsak ima svoj računalnik, podjetje pa ima svoj IT oddelek in postavljeno strežniško infrastrukturo. Ker zaposleni v IT oddelku nimajo programerskega znanja, bo novi sistem razvil zunanji izvajalec. Organizacijsko shemo podjetja prikazuje slika 1.



Direktor

Vodja marketinga

Vodja računovodstva

Vodja proizvodnjeVodja IT Vodja razvoja

3 zaposleni

Administratorji

10 zaposlenih

Izdelovalci

10 zaposlenih

Komercialisti

5 zaposlenih

15 zaposlenih

Monterji

10 zaposlenih

Vodja nabave

5 zaposlenih

Vodja kadrovske službe

5 zaposlenih

5 zaposlenih

Prodaja

Slika 1: Organizacijska shema podjetja

1.3. PREDPOSTAVKE IN OMEJITVE Vodstvo podjetja želi zmanjšati stroške, kar pomeni, da mora nova aplikacija delovati na tehnologijah, pri katerih ne bo dodatnih stroškov z licencami, ali pa bodo ti karseda nizki. Strežniška infrastruktura je v podjetju že vzpostavljena in operativna. V podjetju imajo IT oddelek, ki je odgovoren za operativno delovanje IT sistemov, aplikacijo pa bo razvil zunanji izvajalec.

1.4. METODE DELA Opredelitev problema Vodenje zahtev v podjetju poteka izključno v papirni obliki, kar v praksi pomeni veliko tiskanja obrazcev, ročnega izpolnjevanja, itd. Pri tem pa prihaja tudi do napak, kot so na primer napačno izpolnjeni ali nepotrjeni obrazci. Ker se v organizaciji velik del zahtev nanaša tudi na povračilo stroškov, se zaradi prej omenjenih napak dogaja, da so izplačila zaposlenim napačna ali pridejo z zakasnitvijo. Poleg tega imajo v podjetju tudi težave z arhiviranjem, saj na letnem nivoju natisnejo približno 3500 zahtevkov, ki pa niso dosledno shranjeni na enem mestu. Z novo aplikacijo ročno arhiviranje ne bo več potrebno. Opredelitev ciljev naloge Cilj diplomske naloge je prikazati postopek izdelave sistema za elektronsko vodenje poslovnih procesov. Predstavljeni bosta slapovna in agilna razvojna metodologija. Prav tako bo predstavljeno vrednotenje prihrankov, ki ga takšen sistem prinese. V diplomski nalogi bomo prikazali, kako poteka načrtovanje in implementacija takšne aplikacije. Predvideni rezultati naloge Rezultat diplomske naloge bo aplikacija, ki bo imela omogočene naslednje funkcionalnosti:

Elektronsko vodenje poslovnih procesov

Urejanje in definiranje poslovnih procesov



Predlagane metode in orodja Aplikacija bo temeljila na tronivojski arhitekturi. Izdelane bodo bazne skripte in prevedena koda, ki bo primerna za namestitev na bazni in aplikacijski strežnik. V diplomski nalogi bodo uporabljena naslednja orodja:

Oracle Virtual box

Linux OS za bazni in aplikacijski strežnik

MySql podatkovna baza

Javanski aplikacijski strežnik (WildFly)

MySQL Workbench

Razvojno orodje Eclipse Izdelava aplikacije za vodenje zahtevkov je projekt, za vodenje katerega bo uporabljena kombinacija slapovne in agilne metodologije. Prvi del projekta bo voden po slapovni metodologi, saj bodo začetne funkcionalnosti znane, kasneje pa se projekt lahko vodi tudi po metodologiji agilne, saj se bodo za potrebe posameznih zahtevkov dodajale funkcionalnosti, ki ne bodo nujno povezane s obstoječimi funkcionalnostmi.



2. TEORETIČNE OSNOVE

2.1. OPREDELITEV OSNOVNIH POJMOV TRONIVOJSKA ARHITEKTURA (Pobega, 2016): Model tronivojske arhitekture segmentira logične komponente aplikacije v tri nivoje. Ti nivoji ne odražajo nujno fizičnih lokacij na različnih računalnikih, povezanih z mrežo. Porazdelitev logičnih komponent oziroma nivojev ne odraža nujno fizične porazdeljenosti (fizične topologije). Obe sta lahko predmet neodvisnih zahtev in specifik. Logični nivoji so:

Predstavitveni nivo. Namenjen je interakciji med uporabniki in sistemom.

Je tudi vstopna/povezovalna točka med sistemom in perifernimi napravami

(tiskalnik, ostale naprave). Omogočati mora hiter in učinkovit vnos podatkov

ter nuditi uporabniku intuitiven vmesnik pri izvajanju poslovnih procesov.

Na predstavitvenem nivoju se izvaja le osnovno preverjanje poslovnih pravil.

Poslovni nivo. Namenjen je izvajanju poslovnih procesov in aktivnosti. Prav

tako je odgovoren za uveljavljanje poslovnih pravil in omejitev. Poslovni

nivo je lahko razdeljen na več slojev. Običajno ga sestavljata aplikacijski

sloj (odgovoren za potek procesov, integracije ...) in poslovni sloj

(osredotoča se na poslovna pravila in entitete).

Podatkovni nivo. Namenjen je zanesljivemu, trajnemu hranjenju podatkov.

Poleg tega s svojo zbirko orodij omogoča tudi napredne statistične obdelave

in analize.

(Pobega, 2016): Med življenjskim ciklom aplikacije omogoča tronivojska arhitektura določene prednosti (v primerjavi z dvo- ali enonivojsko), kot so ponovna uporabnost, prožnost, obvladljivost, vzdrževalnost in nadgradljivost. Po drugi strani je zaradi večje razpršenosti fizičnih lokacij nivojev (glede na dvo- ali enonivojsko arhitekturo) več mrežnega prometa po mrežnih povezavah. Potek komunikacije med posameznimi nivoji prikazuje shema na sliki 2.

Zahteva

Zahteva podatke Vrača podatke

Vrača rezultate

Slika 2: Potek komunikacije v tronivojski arhitekturi

JAVA (Oracle, n.d.): Java je programski jezik in računalniška platforma, ki jo je prvotno razvil Sun Microsystems leta 1995. Java je programski jezik, ki temelji na sočasnosti,



je objektno orientiran in zasnovan tako, da je čim manj odvisen od implementacije. Namen je, da razvijalcem omogoča »zaženi enkrat, zaženi povsod«. Kar pomeni, da se javanska koda lahko izvaja na vseh platformah, ki podpirajo Javo, brez potrebe po prevajanju kode. Javanske aplikacije se lahko izvaja samo znotraj javanskega virtualnega stroja (JVM), ne glede na arhitekturo računalnika. Java je od leta 2016 najbolj popularen programski jezik. Shema javanskega virtualnega stroja je prikazana na sliki spodaj.

Izvorna koda (.java)

JAVAC prevajalnik

"Bytecode" (.class)

JVM JVM JVM

Windows Linux Mac

Slika 3: Delovanje javanskega virtualnega stroja (JVM)



JSF (Burns, Schalk, & Griffin, 2010): V jedru je JavaServer Faces (JSF), standardno javansko ogrodje za izdelavo uporabniškega vmesnika spletnih aplikacij. Njegova najpomembnejša funkcija je, da poenostavlja razvoj uporabniškega vmesnika, ki je ponavadi najtežji in najbolj dolgočasen del razvoja spletne aplikacije. Čeprav je možno izdelati uporabniški vmesnik z uporabo temeljnih javanskih spletnih tehnologij (na primer Java servlets ali JavaServer Pages), brez celovitega ogrodja, zasnovanega za razvoj poslovnih spletnih aplikacij, te tehnologije lahko vodijo v vrsto razvojnih in vzdrževalnih težav, ki jih ob uporabi JSF ni potrebno reševati. Takšnemu pristopu bi lahko rekli tudi “grajenje ogrodja znotraj hiše”. JavaServer Faces se z robustnimi, dobro uveljavljenimi razvojnimi vzorci, tem problemom izogne. JavaServer Faces je preko Java Community Process (JCP) ustvarila skupina vodilnih tehnoloških podjetij, med katerimi so Sun Microsystems, Oracle, Borland, BEA in IBM, v sodelovanju z Java in spletnimi strokovnjaki. Začetna javanska specifikacija za JavaServer Faces je bila predstavljena v 2001 in je dosegla mejnik 1.0 marca 2004, skupaj z J2EE 1.4. (Burns, Schalk, & Griffin, 2010): JavaServer Faces je zasnovan tako, da poenostavi razvoj uporabniških vmesnikov za Javanske spletne aplikacije na naslednje načine:

Zagotavlja pristop k razvoju spletnega uporabniškega vmesnika, ki je komponentno osredotočen in neodvisen od odjemalca. Posledično pa povečuje razvijalčevo produktivnost in enostavnost uporabe,

Poenostavlja dostop in upravljanje z aplikacijskimi podatki preko spletnega uporabniškega vmesnika,

Samodejno upravlja stanje uporabniškega vmesnika med več zahtevami in več klienti na preprost in nevsiljiv način,

Prinaša razvojno ogrodje, ki je prijazno za različne razvijalce z različnimi znanji,

Opisuje standardni nabor arhitekturnih vzorcev za spletno aplikacijo. (Schalk, 2005): JSF zagotavlja, da so aplikacije dobro zasnovane, saj v svojo arhitekturo vključuje uveljavljen vzorec oblikovanja Model-View-Controller (MVC):

Model – podatki

View – uporabiški vmesnik

Controller – poslovna logika Vzorec oblikovanja Model-View-Controller prikazuje slika 4.



Faces ServletJSF Pages

Controller View Model

Slika 4: MVC

MYSQL (Oracle Corporation, 2017): MySQL je najbolj popularen odprtokodni sistem za nadzor podatkovne baze. MySQL razvija, distribuira in vzdržuje Oracle. Podatkovna baza je zbirka podatkov, ki je lahko preprost nakupovalni seznam, galerija slik ali ogromne količine informacij v omrežju organizacije. Za upravljanje z podatkovno bazo je potreben sistem, kot je, na primer, MySQL server. Odkar znajo računalniki zelo dobro upravljati z velikimi količinami podatkov, sistem za nadzor podatkovne baze igra ključno vlogo pri procesiranju v enostavnih ali zapletenih aplikacijah. MySQL je relacijska podatkovna baza. Namesto, da bi vse podatke shranili v veliko podatkovno skladišče, pri uporabi MySQL podatke shranjujemo v ločenih tabelah. Struktura podatkovne baze je organizirana v fizične datoteke, ki so optimizirane, da se s tem omogoči čim hitrejše delovanje. Logični model podatkovne baze sestavljajo tabele, pogledi, vrstice in stolpci, ki omogočajo prilagodljivo programsko okolje. Programer določi pravila, ki urejajo relacije med različnimi podatkovni polji, na primer: ena proti ena, ena proti več, unikatno, obvezno, ter kazalnike med različnimi tabelami. Ta pravila morajo biti določena zato, da aplikacije ne vračajo nekonsistentnih, podvojenih, zastarelih ali manjkajočih podatkov. SQL je del MySQL in pomeni strukturiran poizvedovalni jezik (ang. Structured Query Language). SQL je najbolj pogost jezik, ki se uporablja za poizvedovanje po podatkovni bazi. Definira ga ANSI/ISO SQL standard, ki se razvija od leta 1986, obstaja pa v več različnih različicah. Open Source (What is open source?, n.d.): Izraz "odprta koda" (ang. Open Source) se nanaša na kodo, ki jo uporabniki lahko spremenijo in delijo, saj je njena zasnova javno dostopna. Izraz izvira iz pristopa k razvoju programske opreme, ki temelji na izmenjavi in sodelovanju skupnosti razvijalcev.



"Odprtokodna programska oprema" je programska oprema z izvorno kodo, ki jo lahko vsakdo pregleda, spreminja in dopolnjuje. Lastniško programsko opremo lahko legalno pregledujejo, kopirajo in spreminjajo samo avtorji. Pred uporabo lastniške programske opreme se morajo uporabniki strinjati, praviloma s podpisom licence, da v programsko opremo ne bodo posegali brez dovoljenja avtorja. V primeru odprte kode pa avtorji kode dovoljujejo, da jo vsakdo lahko pregleduje, kopira, spreminja, ali se iz nje uči. Primer lastniške kode bi bil programski paket Microsoft Office, primer odprte kode pa LibreOffice. Tako, kot pri lastniški programski opremi, morajo tudi pri odprtokodni programski opremi uporabniki sprejeti licenčne pogoje, vendar se ti s pravnega vidika bistveno razlikujejo od tistih, ki veljajo za lastniško programsko opremo. Virtualizacija (Red Hat, Inc., 2017): Virtualizacija je tehnologija, ki omogoča izdelavo uporabnih IT servisov, ki so praviloma vezani na strojno opremo računalniškega sistema. Virtualizacija omogoča boljši izkoristek računalniške strojne opreme tako, da njene zmožnosti razdeli večim uporabnikom ali okoljem. V praksi to bi ta način lahko opisali s primerom treh fizičnih strežnikov, ki služijo različnim namenom. Prvi je strežnik za elektronsko pošto, drugi je strežnik za spletno aplikacijo, tretji pa je poganja zaledne storitve. Vsak strežnik porablja približno 30% kapacitet, ki jih omogoča strojna oprema. Delovanje samostojnih strežnikov in porabo njihovih virov prikazuje slika 5.

Slika 5: Strežniki brez virtualizacije

Z virtualizacijo lahko dosežemo, da poštni strežnik razdelimo na dva strežnika, ki lahko upravljata neodvisne naloge z isto strojno opremo, kot je prikazano na sliki 6.



Slika 6: Strežniki z uporabo virtualizacije

Slapovni (Waterfall) proces vodenja projekta Gre za najstarejšo in najbolj poznano metodologijo, kjer si posamezni koraki sledijo en za drugim. Ko se en korak v izvedbi zaključi, vrnitev na ta korak ni več mogoča, oz. vrnitev na že zaključen korak ni mogoča v kolikor se celoten projekt ne začne znova. Koraki metodologije (Weitzer, 2009):

Analiza zahtev Zbiranje zahtev za softverski produkt je prvi korak pri njegovem razvoju. Medtem, ko je stranka ali naročnik prepričan, da ve, kaj naj bi produkt počel, je po drugi strani potrebno veliko spretnosti in izkušenj s strani izvajalca, da prepozna nepopolne, dvoumne ali celo nasprotujoče si zahteve.

Izdelava specifikacij Naloga le-te je izdelava natančnega opisa funkcionalnosti, uporabnosti in značilnosti softverskega produkta v izdelavi. Ta opis je lahko strogo matematičen ali uporabniško usmerjen – pomembno je, da je opis jasen in razumljiv tako za naročnike, kot tudi razvijalce. Tu igra najpomembnejšo vlogo opis zunanjega vmesnika produkta, ki je naročniku tudi najbolj poznan in domač del produkta.

Načrt in arhitektura Ta določa generalni način delovanja produkta brez osredotočanja na podrobnosti. V primeru, ko se pokaže, da je začetno zamišljeni načrt nemogoč za implementacijo, je le-tega lažje spremeniti znotraj te faze, kot pa ta problem odkriti šele kasneje med integracijo posameznih programskih sklopov v skupno celoto. To je tudi poglavitni namen »Big Design Up Front-a« (BDUF) – podrobnega načrtovanja pred fazo implementacije. Slapovni model in BDUF sta primerna za projekte, kjer:

o Se začetne zahteve produkta ne spreminjajo, o Je pričakovati, da so načrtovalci sposobni predvideti vsa tveganja, ki

se lahko pojavijo v teku razvojnega cikla, o Imajo razvijalci izkušnje iz prejšnjih podobnih projektov in so

sposobni predvideti vse projektne grožnje brez potrebe po vnaprejšnjem implementiranju in izgradnji prototipa.



Koordiniranje in implementacija Preslikava načrta v programsko kodo je nedvomno najbolj očiten del razvoja programske opreme, vendar ni nujno tudi najobsežnejši. Proti koncu te faze se posamezni softverski deli integrirajo v skupno celoto.

Testiranje Testiranje ali preizkušanje sestoji iz preizkušanja produkta po integraciji posameznih sklopov v zaključeno celoto, ter iz izvajanja regresijskih testov, ki dokazujejo, da je dosedanja funkcionalnost produkta ostala neprizadeta. Samo izvajanje preizkušanja je lahko ročno ali avtomatsko.

Dokumentiranje in inštalacija Pomemben del razvoja je tudi dokumentiranje notranjega načrta produkta za namen kasnejšega vzdrževanja in izboljševanja. V primeru prekinitve projekta v fazi, ko še ni na voljo zadostne količine implementirane programske kode, se projekt lahko nemoteno nadaljuje pozneje, ko je na voljo zadostna mera razpoložljive projektne dokumentacije.

Vzdrževanje Vzdrževanje in izboljševanje softvera z namenom kosati se z na novo odkritimi problemi in zahtevami, lahko zahteva več kot začeten razvoj. Dve tretjini vseh sofverskih inženirjev deluje na pordročju vzdrževanja, a le manjši del le-teh popravlja napake v softveru. Večina vzdrževanja se nanaša na razširjanje sistema na novo funkcionalnost in uporabnost.

Na sliki 7 so prikazani koraki slapovne metodologije.

Analiza zahtev in

izdelava specifikacij

Načrtovanje

Implementacija

Testiranje in

inštalacija

Delovanje in

vzdrževanje

Slika 7: Slapovna metodologija



Prednosti slapovne metodologije:

Poudarja natančno vodenje dokumentacije in posledično omogoča, da lahko v prihodnje načrtujemo dodatne izboljšave v programu,

Naročnik ve, kaj lahko pričakuje v smislu obsega, stroškov, terminskega plana in delovanja aplikacije,

V primeru fluktuacije razvijalcev delo po tej metodologiji omogoča minimalen vpliv na projekt.

Kot ugotavlja Weitzer (Weitzer, 2009), so pomanjkljivosti slapovnega pristopa naslednje:

Razvojna metodologija mora biti odzivna na spremembe. Običaj je, da stranke neprestano spreminjajo svoje zahteve, zato je nerealno vlagati velike napore v BDUF pod predpostavko, da bodo zahteve ostale nespremenjene;

Težko je predvideti, kaj vse je potrebno narediti v posamezni fazi razvojnega cikla, predno se vsaj določen del aktivnosti ne začne tudi na naslednji fazi razvoja. Zatorej je potrebna povratna informacija iz naslednje faze razvoja, da lahko zagotovo trdimo, da je prejšnja faza uspešno zaključena;

Potrebno je neprestano testiranje že od faze “načrtovanje in arhitektura” naprej, da se ovrednotijo vse predhodne faze razvojnega cikla;

Pogosta izgradnja in dostava produkta povečuje zaupanje in samozavest razvojne ekipe, kot tudi stranke;

Težko je vnaprej točno oceniti čas in stroške, potrebne za zaključek posamezne razvojne faze. Razen, seveda, če ima razvojna ekipa že veliko predhodnih izkušenj na tovrstnih produktih;

Le določeno število članov razvojne ekipe je kvalificiranih za sodelovanje v posamezni fazi razvoja, kar pomeni tratenje razpoložljivih človeških virov.

Agilni procesi vodenja projekta Weitzer (Weitzer, 2009) je o njih zapisal: Agilni procesi razvoja programske opreme temeljijo na iterativnem razvoju. Za razliko od klasičnih pristopov dodajo temu temelju lahkotnejši, bolj človeško naravnan pristop. Kot kontrolni mehanizem delovanja uporabljajo povratne informacije, ne pa sledenja projektnemu planu. Povratne informacije podajajo redno testiranje in dostava razvijajočega se produkta. Agilni procesi so na pogled učinkovitejši od starejših metodologij in trošijo manj razvijalskega časa za izdelavo bolj funkcionalnega in kvalitetnejšega programskega izdelka. Njihova slaba stran pa je, da iz poslovnega vidika ne ponujajo zmožnosti dolgoročnega planiranja. V osnovi agilni procesi obljubljajo večji izkupiček za vložen trud, ne povejo pa natančno, kaj točno ta izkupiček bo. Agilni razvoj programske opreme je konceptualno družina procesov, ki zajema številne agilne metodologije. Večina agilnih metodologij poizkuša minimizirati tveganja projekta z razvojem produkta v kratkih časovnih intervalih, imenovanih iteracije. Te običajno trajajo od enega do štirih tednov. Vsaka iteracija je po svoje kot projekt v malem in vsebuje vse faze, potrebne za dostavo inkrementalne funkcionalnosti: planiranje, analizo zahteve, načrtovanje dizajna in arhitekture,



kodiranje, testiranje in dokumentiranje. Cilj vsake iteracije je dostava izpopolnjenega delujočega softvera. Na koncu vsake iteracije se ponovno ocenijo prioritete projekta. Agilne metodologije postavljajo neprestano medosebno komunikacijo pred pisno dokumentacijo. Rezultat tega je, da njeni kritiki agilno metodologijo označujejo kot »kavbojsko kodiranje« (ang. Cowboy coding). Večina »agilnih« ekip je nastanjena na skupni lokaciji in vsebuje vse potrebno osebje za dokončanje projekta. To osebje sestavljajo najmanj programerji in predstavniki naročnikov, lahko pa je razširjena še s testerji, pisci dokumentacije, projektnimi vodji in arhitekti. Agilne metodologije poudarjajo, da je delujoči softver edino merilo napredka na projektu. Štiri načela agilnosti, kot jih je definiral Beck in ostali (Beck, et al., 2001) Weitzer (Weitzer, 2009) razloži na sledeč način:

Posamezniki in interakcije pred procesi in orodji Projekt bo gotovo bolj uspešen, če sta komunikacija in sodelovanje članov projekta dobra in imajo člani ustrezna znanja – pa čeprav se ne držijo nobenega predpisanega procesa; kot pa v primeru, da je proces predpisan in so na voljo najboljša orodja, komunikacija med člani in njimi pa slaba oziroma člani nimajo ustreznih znanj;

Delujoča programska oprema pred vseobsežno dokumentacijo Delujoč program je glavni cilj razvoja programske opreme in je najbolj pomemben izdelek, ki ga končni uporabnik dobi. Modeli, sistemska, uporabniška in druga dokumentacija so vsekakor koristni, vendar brez delujočega programa nimajo uporabne vrednosti;

Sodelovanje s stranko pred pogodbenimi pogajanji Za uspešnost projekta je dobro razumevanje naročnika in izvajalca ključnega pomena. Naročnik najbolje ve, kaj potrebuje, čeprav tega pogosto ne zna razložiti, zato je dobro sodelovanje še toliko bolj pomembno;

Odziv na spremembe pred togim sledenjem načrtom Spremembe v zahtevah pri razvoju programske opreme so dejstvo, na katerega je potrebno računati. Naivno je pričakovati, da bomo lahko že v začetni fazi projekta zajeli vse zahteve, ki se pozneje ne bodo spreminjale. Projektni plan je koristen, vendar mora dopuščati spremembe. Najslabše je slepo sledenje zastarelemu projektnemu planu.

Na podlagi predstavljenih načel Beck in ostali (Beck, et al., 2001) naštejejo še dvanajst osnovnih priporočil agilnosti:

Naša najvišja prioriteta je zadovoljiti stranko z zgodnjim in nepretrganim izdajanjem vredne programske opreme;

Sprejemamo spremembe zahtev, celo v poznih fazah razvoja. Agilni procesi vprežejo tovrstne spremembe v prid konkurenčnosti naše stranke;

Delujočo programsko opremo izdajamo pogosto, znotraj obdobja nekaj tednov, do nekaj mesecev, s preferenco po krajšem časovnem okvirju;

Poslovneži in razvijalci morajo skozi celoten projekt dnevno sodelovati;



Projekte gradimo okrog motiviranih posameznikov. Omogočimo jim delovno okolje, nudimo podporo in jim zaupamo, da bodo svoje delo opravili;

Najboljša in najučinkovitejša metoda posredovanja informacij razvojni ekipi in znotraj ekipe same, je pogovor iz oči v oči;

Delujoča programska oprema je primarno merilo napredka;

Agilni procesi promovirajo trajnostni razvoj. Sponzorji, razvijalci in uporabniki morajo biti zmožni konstantnega tempa za nedoločen čas;

Nenehna težnja k tehnični odličnosti in k dobremu načrtovanju izboljša agilnost;

Preprostost - umetnost zmanjševanja količine nepotrebnega dela - je bistvena;

Najboljše arhitekture, zahteve in načrti izhajajo iz tistih ekip, ki so samoorganizirane.

V rednih časovnih razdobjih ekipa išče načine, kako postati učinkovitejša ob rednem prilagajanju svojega delovanja.



3. OBSTOJEČE STANJE V izbrani organizaciji trenutno ni podpore za aplikacijsko vodenje poslovnih procesov oziroma zahtevkov. Trenutno to rešujejo tako, da imajo na intranetu objavljene vse relevantne zahtevke, vključno z navodili procesa. V teh navodilih je navedeno, katera oseba mora zahtevek odobriti, komu je treba zahtevek odnesti v nadaljnjo obravnavo, itd. V praksi en proces oziroma zahtevek izgleda tako, da ga zaposleni natisne in izpolni, nato pa odnese osebi, ki je zadolžena za določen korak v procesu. V organizaciji na tak način vodijo več poslovnih procesov, ki so si med sabo različni in imajo različno številko korakov. V splošnem te procese lahko razdelimo na nekaj ključnih korakov:

Izpolnjevanje zahteve

Potrjevanje zahteve

Obravnava zahteve

Arhiviranje

Procesni diagram navedenih korakov prikazuje slika 8.

Zaposleni

Izpolni zahtevek

Potrjevanje zahtevka

Zahtevek

Povratna informacija

Obdelava zahtevka

Potrjen zahtevek

Arhiviranje zahtevka

Zavrnjen zahtevek

Obdelan zahtevek

Slika 8: Diagram poslovnega procesa

Slika 9 prikazuje diagram zahtevka za oddajo dopusta, v katerem so poleg posameznih korakov in odločitev, vključeni še oddelki oziroma odgovorne osebe.



Funkcijski diagram - dopustO

dgo

vorn

a o

seb

aZa

po

slen

iA

rhiv

Fin

ance

ZačetekIzpis in

izpolnjevanje zahtevka

Pregled ustreznosti in potrjevanje

zahtevka

Ali je zahteva odobrena?

Arhiviranje

Ne

Knjiženje ur

Da

Konec

Slika 9: Funkcijski diagram zahtevka za oddajo dopusta

Pri izdelavi novega sistema se bomo oprli tudi na SWOT analizo obstoječega načina vodenja poslovnih procesov. V organizaciji so poslovni procesi dobro definirane, kar je precejšnja prednost, ki bo pomembno pripomogla k uspehu projekta. Trenutni način vodenja poslovnih procesov pa ima svoje pomanjkljivosti, ki bi jih učinkovito rešili z novo aplikacijo. SWOT analiza je prikazana na sliki 10.

Po

ziti

vno

Prednosti Priložnosti

Dobro definirani procesi Zmanjšanje porabljenega časa Avtomatizacija preprostih nalog Ni papirnega arhiva Trend (oblačne storitve) Lažje spreminjanje procesov Vsi procesi bodo na enem mestu

Neg

ativ

no

Slabosti Nevarnosti

Izguba časa Ni avtomatskih kontrol Velik arhiv Težja uveljavitev sprememb procesa

Napačna definicija procesa v konfiguracijski datoteki Odpoved IT opreme

Slika 10: SWOT analiza



V tabeli 1 so podane ocene porabljenega časa v procesu po zgornjem funkcijskem diagramu. Korak v procesu Porabljen čas [min]

Izpolnjevanje zahtevka 3 Prenos zahtevka do odgovorne osebe 5 Pregled in potrjevanje zahtevka 6 Prenos zahtevka v odgovorni sektor 5 Obravnava zahtevka 4 Arhiviranje 7

SKUPAJ 30 Tabela 1: Časovne ocene trenutnega stanja



4. POPIS FUNKCIONALNOSTI SISTEMA

4.1. PRIJAVA V SISTEM IN VARNOST Prijava v sistem poteka preko uporabniškega imena in gesla. Uporabniško ime in geslo sta nepovezana z uporabniki, ki se uporabljajo za prijavo v računalnik. Kasnejše dopolnitve aplikacije bi lahko omogočale integracijo z ActiveDirectory. Za avtentikacijo in avtorizacijo uporabnika se uporablja javanska implementacija varnosti, imenovana Javanska avtentikacijska in avtorizacijska storitev (ang. Java Authentication and Authorization Service), v nadaljevanju JAAS. JAAS se uporablja za dva namena:

Za avtentikacijo uporabnikov - da se zanesljivo in varno določi, kdo izvaja javansko kodo, ne glede na to, ali se koda izvaja kot aplikacija, applet, bean ali servlet;

Za avtorizacijo uporabnikov - da se določi ali da imajo uporabniki pravice za izvajanje akcij.

Podatki o uporabnikih se v podatkovni bazi nahajajo v tabeli SEC_USERS. Tabela hrani naslednje podatke:

ID uporabnika - primarni ključ v tabeli;oloča se s pomočjo sekvence oz. autoincrement funkcionalnosti podatkovne baze;

Uporabniško ime - poljuben niz dolžine do 45 znakov; določi ga administrator, ki ga lahko naknadno tudi spremeni;

Geslo - se v bazi hrani v kodirani obliki; ob nastavljanju gesla se izvede kodiranje z algoritmom MD5, v bazo pa se shrani z Base64 kodiranjem; Primer kodiranega gesla prikazuje tabela 2.

Geslo Kodirano geslo

Test1234 LJNBykzz2HueTrkF1qPsRQ==

Tabela 2: Kodirano geslo

Oddelek - povezovalni ključ s šifrantom oddelkov SIF_ODDELEK;

Ime - uporabnikovo ime; vpiše ga administrator, lahko vsebuje poljuben niz do 45 znakov;

Priimek - uporabnikov priimek; vpiše ga administrator, lahko vsebuje poljuben niz do 45 znakov;

Elektronski naslov - vpiše ga administrator, lahko vsebuje poljuben niz do 45 znakov;

Indikator aktivnosti uporabnika - indikator, ki določa, ali je uporabnik aktiven; neaktivni uporabniki se ne morejo prijaviti v aplikacijo.

Podatki o uporabnikovih vlogah so shranjeni v povezovalni tabeli med uporabniki in šifrantom vlog (SEC_ROLE), imenovani SEC_USER_ROLE. Prijava uporabnika poteka v dveh korakih. V prvem koraku aplikacijski strežnik preveri, ali je vpisano uporabniško ime v podatkovni bazi in ali se vpisano geslo ujema. Gesli se vedno primerjata v kodirani obliki.



Pridobivanje podatkov se izvede z poizvedbo, zapisano v izvlečku kode 1. SELECT PASSWORD

FROM ZAHTEVKO.SEC_USER

WHERE USERNAME = ?

AND IND_AKTIVEN = 'D'; Izvleček kode 1: Poizvedba za pridobivanje gesla

V kolikor je prvi korak uspešen, se izvede še pridobivanje uporabnikovih vlog. Uporabnikove vloge pridobi poizvedba v izvlečku kode 2. SELECT SR.SIFRA AS 'Roles',

'Roles' AS 'RoleGroup'

FROM ZAHTEVKO.SEC_USER SU,

ZAHTEVKO.SEC_USER_ROLE SUR,

ZAHTEVKO.SEC_ROLE SR

WHERE SU.USERNAME = ?

AND SU.SEC_USER_ID = SUR.SEC_USER_ID

AND SUR.SEC_ROLE_ID = SR.SEC_ROLE_ID; Izvleček kode 2: Poizvedba za pridobivanje uporabnikovih rol

Aplikacijski strežnik WildFly za uporabo JAAS ne zahteva dodatne kode oz. implementacije prijave, temveč samo pravilno konfiguracijo strežnika. Izsek konfiguracije prikazuje izvleček kode 3. <security-domain name="zahtevko-realm" cache-type="default">

<authentication>

<login-module name="Zahtevko" code="Database" flag="required">

<module-option name="dsJndiName" value="java:/jboss/datasources/dsZahtevko"/>

<module-option name="principalsQuery" value="SELECT PASSWORD FROM ZA-

HTEVKO.SEC_USER WHERE USERNAME = ? AND IND_AKTIVEN = 'D'"/>

<module-option name="rolesQuery" value="SELECT SR.SIFRA AS 'Roles', 'Roles'

AS 'RoleGroup' FROM ZAHTEVKO.SEC_USER SU, ZAHTEVKO.SEC_USER_ROLE SUR, ZA-

HTEVKO.SEC_ROLE SR WHERE SU.USERNAME = ? AND SU.SEC_USER_ID = SUR.SEC_USER_ID

AND SUR.SEC_ROLE_ID = SR.SEC_ROLE_ID"/>

<module-option name="hashAlgorithm" value="MD5"/>

<module-option name="hashEncoding" value="Base64"/>

</login-module>

</authentication>

</security-domain> Izvleček kode 3: Konfiguracija JAAS na strežniku WildFly

Slika 11 prikazuje entitetno relacijski diagram uporabnikov v aplikaciji.

Slika 11: Podatkovni model uporabnikov

Prijavna stran aplikacije je prikazana na sliki 12. Stran je preprosta in vsebuje dve vnosni polji (uporabniško ime in geslo) in gumb za prijavo.



Slika 12: Prijavna stran

4.2. ORODNA VRSTICA Ko je uporabnik prijavljen, ima na vseh straneh aplikacije na voljo orodno vrstico. . Elementi orodne vrstice:

Ime in priimek - izpisuje se ime in priimek prijavljenega uporabnika;

Gumb za odjavo iz aplikacije - ob kliku na gumb se izvede odjava uporabnika iz aplikacije;

Meni za navigacijo med posameznimi moduli - gumbi za preklapljanje med posameznimi moduli; v aplikaciji sta implementirana modula:

o Zahtevki o Administracija

Na sliki 13 je prikazana orodna vrstica v aplikaciji.

Slika 13: Orodna vrstica

4.3. ADMINISTRACIJA UPORABNIKOV Na strani z administracijo uporabnikov je mogoče urejati podatke o posameznih uporabnikih aplikacije. Dostop do te strani imajo samo uporabniki z vlogo administrator. Na strani se nahaja tabela, v kateri so nanizani vsi uporabniki. Administrator lahko doda novega uporabnika s klikom na gumb »+ Dodaj«. Odpre se dialog za dodajanje novega uporabnika. Pri vsakem uporabniku se nahaja tudi gumb za urejanje podatkov. Ob kliku na ta gumb se odpre dialog s podatki uporabnika. Slika 14 prikazuje stran z izpisanimi vsemi uporabniki v aplikaciji.



Slika 14: Administracija uporabnikov

Slika 15 prikazuje dialog, v katerem administrator lahko ureja podatke posameznega uporabnika.

Slika 15: Dialog s podatki uporabnika

4.4. ADMINISTRACIJA ZAHTEVKOV Na strani za konfiguracijo lahko uporabnik naloži novo konfiguracijsko datoteko. Dostop do te strani imajo samo uporabniki z vlogo administrator. Zahtevki niso kodirani v aplikaciji, temveč so zapisani v XML obliki. Prednost takšne implementacije je, da za posamezne zahtevke ne potrebujemo sprememb v kodi, razen, če se pojavi potreba po implementaciji novih funkcionalnosti (npr. implementacija novega vnosnega polja). Konfiguracijska datoteka je shranjena na podatkovni bazi v tabeli CONFIG_XML. Oblika in vsebina ni poljubna, ampak mora slediti pravilom pisanja v XML formatu. Struktura vsebine XML datoteke mora biti sledeča:

Zahtevki To je korensko vozlišče datoteke, v katerem se nahajajo posamezni

zahtevki. V aplikaciji je lahko poljubno število zahtevkov. V tem vozlišču

uporabnik lahko poda naslednje atribute:



o Name – naziv menija za nove zahtevke; lahko se določi poljuben niz.

Zahtevek To vozlišče predstavlja vsebino enega zahtevka. Vsebina zahtevka je

razdeljena na več korakov, ki pa jih je na nivoju enega zahtevka lahko

poljubno število. V tem vozlišču uporabnik lahko poda naslednje atribute:

o Name – kratek naziv zahtevka; lahko se določi poljuben niz; o longName – dolgi naziv zahtevka; lahko se določi poljuben niz; o code – šifra zahtevka; lahko se določi poljuben niz.

Korak To vozlišče predstavlja vsebino enega koraka zahtevka. En zahtevek ima

lahko poljubno število korakov, vsak korak pa mora imeti določeno vsebino.

V tem vozlišču uporabnik lahko poda naslednje atribute:

o Step – številka oz. šifra koraka; lahko se določi poljubna številka; o Terminal – določa, ali gre za končen korak; končen korak je zadnji

korak zahtevka, nadaljnje akcije pa niso več dovoljene. Dovoljeni vrednosti sta »true« in »false«.

UI To vozlišče določa izgled in vsebino uporabniškega vmesnika; tukaj določimo

gradnike uporabniškega vmesnika s pod-vozlišči »Element«.

Element S posameznim elementom določimo ali se posamezen gradnik prikazuje, ali

ne. Za en gradnik, ki ga lahko prikažemo na uporabniškem vmesniku, dodamo

eno vozlišče Element.

V tem vozlišču uporabnik lahko določi naslednje atribute:

o Code – šifra elementa za prikaz na uporabniškem vmesniku; uporabnik ne more določiti poljubnega niza, saj so šifre povezane z nazivi elementov na strani;

o Name – naziv, ki se prikazuje na uporabniškem vmesniku; uporabnik lahko zapiše poljuben niz;

o Mandatory – določa, ali je v določenem koraku vnos elementa obvezen, ali ne; dovoljeni sta vrednosti »true« in »false«;

o Editable – določa, ali je polje v določenem koraku dovoljeno za vnos; dovoljeni sta vrednosti »true« in »false«.

Za posamezen zahtevek mora biti definirana tudi odločitev na posameznem

koraku. To sta dva gumba, ki imata šifri »ok« in »cancel«. Pri teh dveh

elementih so dodatno na voljo tudi atributi:

o NavigateToStep – določa naslednji korak zahtevka; zapiše se šifra naslednjega koraka, določena v konfiguraciji zahtevka;

o setStatus – določa naslednji status zahtevka; zapiše se status zahtevka, dovoljen je poljuben niz znakov;

o assignPerson – določa, komu naj se zahteva dodeli v obravnavo. Ta nastavitev je povezana z nastavitvijo assignSector. Dovoljene se naslednje vrednosti:

VODJA_ODDELKA - logika aplikacije na podlagi nastavljenih uporabnikov poišče vodjo oddelka in zahtevo dodeli tej osebi;

NONE - zahteva se ne dodeli nikomur; Določen uporabnik - zahteva se bo vedno dodelila točno

določenemu uporabniku.



o assignSector – določa, kateremu oddelku naj se zahteva dodeli. Ta nastavitev je povezana s nastavitvijo assignPerson. Dovoljene so naslednje vrednosti:

USERS_SECTOR - določa, naj se uporabi isti sektor, kot je uporabnikov;

NONE - sektor se ne izbere; Šifra sektorja - vedno se izbere isti sektor.

Primer konfiguracijske datoteke z enim zahtevkom je prikazan v izvlečku kode 4. <?xml version="1.0" encoding="UTF-8" ?>

<ZAHTEVKI name="Nov zahtevek">

<ZAHTEVEK name="Dopust" code="DOP" longName="Zahteva za odobritev dopusta">

<KORAK step="1" terminal="false">

<UI>

<ELEMENT code="dateFrom" name="Datum zacetka:" mandatory="true"/>

<ELEMENT code="dateTo" name="Datum konca:" mandatory="true"/>

<ELEMENT code="person" name="Namestnik" mandatory="true"/>

<ELEMENT code="note" name="Opomba"/>

<ELEMENT code="ok" name="Oddaj" navigateToStep="2" setStatus="CAKA_ODO-

BRITEV" assignPerson="VODJA_ODDELKA" assignSector="USERS_SECTOR"/>

</UI>

</KORAK>

<KORAK step="2" terminal="false">

<UI>

<ELEMENT code="dateFrom" name="Datum zacetka:" mandatory="true"

editable="false"/>

<ELEMENT code="dateTo" name="Datum konca:" mandatory="true"

editable="false"/>

<ELEMENT code="person" name="Namestnik" mandatory="true"

editable="false"/>

<ELEMENT code="note" name="Opomba" editable="false"/>

<ELEMENT code="ok" name="Potrdi" navigateToStep="3" setStatus="ODOBRENO"

assignPerson="ANY" assignSector="FIN"/>

<ELEMENT code="cancel" name="Zavrni" navigateToStep="3" setStatus="ZAVR-

NJENO" assignPerson="NONE" assignSector="none"/>

</UI>

</KORAK>

<KORAK step="3" terminal="true">

<UI>

<ELEMENT code="dateFrom" name="Datum zacetka:" mandatory="true"

editable="false"/>

<ELEMENT code="dateTo" name="Datum konca:" mandatory="true"

editable="false"/>

<ELEMENT code="person" name="Namestnik" mandatory="true"

editable="false"/>

<ELEMENT code="note" name="Opomba" editable="false"/>

</UI>

</KORAK>

</ZAHTEVEK>

</ZAHTEVKI>

Izvleček kode 4: Konfiguracijska datoteka



Proces takšne zahteve prikazuje procesni diagram na sliki 16.

Start

Prikaži uporabniški

vmesnik

Oddaj zahtevo

Obravnava

zahteve

Ali je zahteva

odobrena

Nastavi status

ODOBRENO

Da

Nastavi status

ZAVRNJENO

Ne

Konec

Slika 16: Procesni diagram zahtevka

4.5. ZAČETNA STRAN Po uspešni prijavi v aplikacijo se uporabniku odpre začetna stran, preko katere lahko pregleda zahtevke, ki so mu dodeljeni, ali pa pregleduje zgodovino zahtevkov, ki jih je odprl. Poleg tega uporabnik na tej strani lahko odpira nove zahtevke. Na levi strani se nahaja vertikalni meni, v katerem so nanizani novi zahtevki. Vsebina menija se prenese neposredno iz konfiguracijske datoteke, in sicer se nanizajo vsi zahtevki, ki so definirani v vozliščih //ZAHTEVKI/ZAHTEVEK. Slika 17 prikazuje relacijo med vertikalnim menijem in nastavitvami v konfiguracijski datoteki.



Slika 17: Vertikalni meni

Slika 18 prikazuje celotno vstopno stran, ki se odpre po prijavi v aplikacijo. Na strani se privzeto izpišejo zahtevki, ki so uporabniku dodeljeni.

Slika 18: Vstopna stran

Uporabnik lahko odpre tudi zgodovino svojih zahtevkov, kar je prikazano na sliki 19.

Slika 19: Zgodovina zahtevkov

4.6. VSEBINA ZAHTEVKA



To je stran, na kateri se prikazuje vsebina posameznega zahtevka. Izgled strani je povezan z vsebino konfiguracijske datoteke. Na tej strani se nahajajo vnaprej dogovorjeni elementi, ki pa jih je mogoče konfigurirati. V aplikaciji so na strani Vsebina zahtevka trenutno implementirana naslednja polja:

ID zahtevka - pomožno polje, ki se v aplikaciji ne prikazuje. Gre za primarni

ključ v tabeli ZAH_ZAHTEVEK. To vrednost samodejno določa podatkovna

baza;

Šifra zahtevka - pomožno polje, ki se v aplikaciji prikazuje samo na seznamu

zahtevkov. Vrednost se prenese iz konfiguracijske datoteke, iz atributa

//ZAHTEVKI/ZAHTEVEK/@code. V podatkovni bazi je ta vrednost zapisana v

polju ZAH_ZAHTEVEK.SIFRA_ZAHTEVKA;

Naziv zahtevka - polje, v katerem se prikazuje dolg naziv zahtevka. Ta

vrednost se prenese iz konfiguracijske datoteke, iz atributa

//ZAHTEVKI/ZAHTEVEK/@longName. V podatkovni bazi je ta vrednost

zapisana v polju ZAH_ZAHTEVEK.NAZIV_ZAHTEVKA;

Trenutni korak - pomožno polje, v katerem je zapisan trenutni korak. V

aplikaciji je vrednost vidna samo seznamu zahtevkov. Ta vrednost se prenaša

iz konfiguracijske datoteke, iz atributa

//ZAHTEVKI/ZAHTEVEK/KORAK/UI/ELEMENT/@navigateToStep. Ta vrednost

se zapiše v odvisnosti od koraka, v katerem je bil zahtevek odprt. V

podatkovni bazi je ta vrednost zapisana v polju

ZAH_ZAHTEVEK.TRENUTNI_KORAK;

Status - pomožno polje, v katerem je zapisan trenutni status. V aplikaciji je

ta vrednost vidna samo na seznamu zahtevkov. Prenaša se iz konfiguracijske

datoteke, iz atributa

//ZAHTEVKI/ZAHTEVEK/KORAK/UI/ELEMENT/@setStatus. Ta vrednost se

zapiše v odvisnosti od koraka, v katerem je bil zahtevek odprt. V podatkovni

bazi je vrednost zapisana v polju ZAH_ZAHTEVEK.STATUS;

Datum od - polje, v katerega uporabnik vnese poljuben datum. V aplikaciji

je ta vrednost zapisana na zahtevku, v podatkovni bazi pa je zapisana v polju

ZAH_ZAHTEVEK.DATUM_OD;

Datum do - polje, v katerega uporabnik vnese poljuben datum. V aplikaciji


ZAH_ZAHTEVEK.DATUM_DO.

Opomba - polje, v katerega uporabnik vnese poljuben niz znakov. V aplikaciji


ZAH_ZAHTEVEK.OPOMBA;

Namestnik - spustni seznam, v katerem se izpišejo vsi nazivi zaposlenih iz

tabele SEC_USERS. V aplikaciji je ta vrednost zapisana na zahtevku, v

podatkovni bazi pa je zapisana kot tuji ključ v polju

ZAH_ZAHTEVEK.NAMESTNIK_USER_ID.

Dodeljen uporabnik - pomožno polje, ki se v aplikaciji ne prikazuje. Vanj se

zapiše primarni ključ zaposlenega, ki mu je zahteva dodeljena v obravnavo.

V podatkovni bazi je ta vrednost zapisana kot tuji ključ v polju

ZAH_ZAHTEVEK.DODELJEN_USER_ID;

Začetni uporabnik - pomožno polje, ki se v aplikaciji ne prikazuje. Vanj se

zapiše primarni ključ zaposlenega, ki je zahtevek kreiral. V podatkovni bazi



je ta vrednost zapisana kot tuji ključ v polju

ZAH_ZAHTEVEK.ZACEL_USER_ID;

Datum zahtevka - pomožno polje, v katerem je zapisan trenutni korak. V

aplikaciji je ta vrednost vidna samo na seznamu zahtevkov. V tem polju je

zapisan datum, ko je bil zahtevek kreiran.

Slika 20 prikazuje celotno stran z vsebino zahtevka.

Slika 20: Stran z vsebino zahtevka

Na sliki 21 je prikazana celotna stran v povezavi z konfiguracijsko datoteko.

Slika 21: Stran z vsebino zahtevka v povezavi z konfiguracijsko datoteko

Na sliki 22 je prikazan entitetno – relacijski model zahtevkov.



Slika 22: Podatkovni model zahtevkov

4.7. POSTOPEK DODELJEVANJA ZAHTEVKOV V aplikaciji je vgrajen algoritem za dodeljevanje zahtevka ustreznim osebam. Dodelitev se zgodi, ko zahtevek dobi nov status, kar pa je praviloma po kliku na gumb s šifro »ok« ali »cancel«.V osnovi dodeljevanje poteka s sestavljanjem SQL poizvedbe med zaposlenimi v organizaciji. Poizvedba je prikazana v izvlečku kode 5. SELECT SU.SEC_USER_ID AS SEC_USER_ID,

SU.USERNAME AS USERNAME,

SU.IME AS IME,

SU.PRIIMEK AS PRIIMEK,

SR.SIFRA AS SIFRA_VLOGE,

SD.SIFRA_ODDELKA AS SIFRA_ODDELKA,

SD.SIF_ODDELEK_ID AS SIF_ODDELEK_ID

FROM ZAHTEVKO.SEC_USER SU,

ZAHTEVKO.SEC_USER_ROLE SUR,

ZAHTEVKO.SEC_ROLE SR,

ZAHTEVKO.SIF_ODDELEK SD

WHERE SU.SEC_USER_ID = SUR.SEC_USER_ID

AND SUR.SEC_ROLE_ID = SR.SEC_ROLE_ID

AND SU.SIF_ODDELEK_ID = SD.SIF_ODDELEK_ID

ORDER BY SU.USERNAME, SR.SIFRA; Izvleček kode 5: Osnovna poizvedba za postopek dodeljevanja

Poizvedbo smo za lažjo uporabo prevedli v bazni pogled, tako je začetna poizvedba enaka, kot je prikazana v izvlečku kode 6. SELECT *

FROM ZAHTEVKO.W_ZAPOSLENI

WHERE 1=1 Izvleček kode 6: Bazni pogled



Postopek nato z definicije gumba prebere nastavitev za dodeljevanje med sektorji. Definicija sektorja je zapisana v atributu »assignSector«. Podprte so naslednje vrednosti:

USERS_SECTOR - določa, da mora biti nova oseba v istem sektorju, kot je

sektor uporabnika, ki je odprl zahtevo. V tem primeru se zgornji poizvedbi

doda nov pogoj (označen z rumeno), kot je prikazano v izvlečku kode 7,

namesto vprašaja pa se zapiše ID uporabnikovega sektorja;

SELECT * FROM ZAHTEVKO.W_ZAPOSLENI WHERE 1=1 AND SIF_ODDELEK_ID = ?

Izvleček kode 7: Dodaten pogoj USERS_SECTOR

Katerakoli vrednost iz šifranta sektorjev, v polju »šifra sektorja« - dodelitev

na točno določen sektor. V tem primeru se zgornji poizvedbi doda nov pogoj

(označen z rumeno), kot je prikazano v izvlečku kode 8, namesto vprašaja

pa se zapiše šifra sektorja iz konfiguracijske datoteke;

SELECT * FROM ZAHTEVKO.W_ZAPOSLENI WHERE 1=1 AND SIFRA_ODDELKA = '?'

Izvleček kode 8: Dodaten pogoj za poljuben sektor

None - sektor ni pomemben, poizvedba se ne spremeni.

Postopek nato z definicije gumba prebere nastavitev za dodeljevanje med zaposlenimi. Definicija zaposlenega je zapisana v atributu »assignPerson«. Podprte so naslednje vrednosti:

VODJA_ODDELKA - določa, da mora imeti nova oseba vlogo vodje oddelka

oziroma sektorja. V tem primeru se zgornji poizvedbi doda nov pogoj

(označen z rumeno), kot je to prikazano v izvlečku kode 9;

SELECT * FROM ZAHTEVKO.W_ZAPOSLENI WHERE 1=1 AND SIFRA_ODDELKA = '?' AND SIFRA_VLOGE = 'VODJA_ODDELKA'

Izvleček kode 9: Dodaten pogoj VODJA_ODDELKA

NONE - dodeljevanje se ne izvede, zato v poizvedbo dodamo nesmiseln pogoj

(označen z rumeno), kot je to prikazano v izvlečku kode 10;

SELECT * FROM ZAHTEVKO.W_ZAPOSLENI WHERE 1=1 AND 1=2



Izvleček kode 10: Nesmiseln pogoj poizvedbe

ANY - uporabnik ni pomemben, poizvedba se ne spremeni;

Točno določen uporabnik aplikacije - dodelitev točno določenemu

uporabniku. V tem primeru se zgornji poizvedbi doda nov pogoj (označen z

rumeno), kot je to prikazano v izvlečku kode 11. Namesto vprašanja se

zapiše uporabniško ime osebe, ki ji želimo dodeliti zahtevo;

SELECT *

FROM ZAHTEVKO.W_ZAPOSLENI

WHERE 1=1

AND SIFRA_ODDELKA = '?'

AND USERNAME = '?'

Izvleček kode 11: Dodaten pogoj za točno določenega uporabnika

Algoritem za dodeljevanje nato izvede sestavljeno poizvedbo. V odvisnosti od nastavitev so pričakovani trije možni rezultati:

Poizvedba ne vrne osebe, ki bi ustrezala kriterijem. Dodelitev se ne izvede;

Poizvedba vrne točno eno osebo, ki ustreza kriterijem in zahteva se dodeli

tej osebi;

Poizvedba vrne več kot eno osebo, ki ustreza kriterijem. V tem primeru

zahtevo dodelimo naključni osebi s seznama.

4.8. PRIMER PROCESA V tem poglavju je opisan primer celotnega življenjskega cikla zahtevka za oddajo dopusta. Proces je prikazan v diagramu na sliki 23. Definicija procesa, predstavljenega na sliki 23, je zapisana v konfiguracijski datoteki, kot je to prikazano v izvlečku kode 12.



Začetek

Izpolni zahtevek za

odobritev dopusta.

Oddaj zahtevek v

odobritev nadrejeni

osebi.

Ali je zahtevek

odobren?

Oddaj zahtevek v

arhiv.

Ne

Oddaj zahtevek v

finance, v knjiženje.

Da

Konec

Knjiženje ur

Slika 23: Življenjski cikel zahtevka za odobritev dopusta



<ZAHTEVEK name="Dopust" code="DOP" longName="Zahteva za odobritev dopusta"> <KORAK step="1" terminal="false"> <UI> <ELEMENT code="dateFrom" name="Datum zacetka:" mandatory="true"/> <ELEMENT code="dateTo" name="Datum konca:" mandatory="true"/> <ELEMENT code="person" name="Namestnik" mandatory="true"/> <ELEMENT code="note" name="Opomba"/> <ELEMENT code="ok" name="Oddaj" navigateToStep="2" setStatus="CAKA_ODOBRITEV" assig-

nPerson="VODJA_ODDELKA" assignSector="USERS_SECTOR"/> </UI> </KORAK> <KORAK step="2" terminal="false"> <UI> <ELEMENT code="dateFrom" name="Datum zacetka:" mandatory="true" editable="false"/> <ELEMENT code="dateTo" name="Datum konca:" mandatory="true" editable="false"/> <ELEMENT code="person" name="Namestnik" mandatory="true" editable="false"/> <ELEMENT code="note" name="Opomba" editable="false"/> <ELEMENT code="ok" name="Potrdi" navigateToStep="3" setStatus="ODOBRENO-CAKA_KNJIZENJE"

assignPerson="ANY" assignSector="FIN"/> <ELEMENT code="cancel" name="Zavrni" navigateToStep="4" setStatus="ZAVRNJENO" assig-

nPerson="NONE" assignSector="none"/> </UI> </KORAK> <KORAK step="3" terminal="false"> <UI> <ELEMENT code="dateFrom" name="Datum zacetka:" mandatory="true" editable="false"/> <ELEMENT code="dateTo" name="Datum konca:" mandatory="true" editable="false"/> <ELEMENT code="person" name="Namestnik" mandatory="true" editable="false"/> <ELEMENT code="note" name="Opomba" editable="false"/> <ELEMENT code="ok" name="Koncaj" navigateToStep="4" setStatus="KONCANO" assignPer-

son="NONE" assignSector="none"/> </UI> </KORAK> <KORAK step="4" terminal="true"> <UI> <ELEMENT code="dateFrom" name="Datum zacetka:" mandatory="true" editable="false"/> <ELEMENT code="dateTo" name="Datum konca:" mandatory="true" editable="false"/> <ELEMENT code="person" name="Namestnik" mandatory="true" editable="false"/> <ELEMENT code="note" name="Opomba" editable="false"/> </UI> </KORAK> </ZAHTEVEK>

Izvleček kode 12: Konfiguracijska datoteka

Začetek procesa Uporabnik bo oddal nov zahtevek. Na osnovni strani v levem vertikalnem meniju

izbere željeni zahtevek. Levi vertikalni meni je prikazan na sliki 24.

Slika 24: Izbira zahtevka iz levega vertikalnega menija

1. korak Uporabniku se odpre prvi korak zahtevka, kjer mora vpisati zahtevane podatke.

Uporabniški vmesnik prikazuje slika 25.



Slika 25: Forma za vnos zahtevka v prvem koraku

Če uporabnik ne vnese zahtevanih podatkov, zahtevka ne bo mogel oddati, saj se

bodo sprožile blokade, kot je prikazano na sliki 26.

Slika 26: Blokade v primeru manjkajočih podatkov

Po oddani zahtevi se vsa vnosna polja zaklenejo, uporabniku pa se izpiše obvestilo,

da je zahtevek uspešno oddal - prikazano na sliki 27.



Slika 27: Primer uspešne oddaje zahtevka

2. korak Uporabnik, ki mu je zahteva dodeljena se prijavi v sistem. V seznamu zahtevkov, ki

so mu dodeljeni, vidi zahtevek, ki čaka na njegovo ukrepanje. Dodeljeni zahtevki

so prikazani na sliki 28.,

Slika 28: Seznam dodeljenih zahtevkov

Ko uporabnik zahtevek odpre lahko vidi podatke, ki jih je vnašalec vpisal v

predhodnem koraku. Uporabnik, ki mu je zahteva dodeljena, ima na voljo gumb za

potrditev in gumb za zavrnitev zahtevka. Celoten uporabniški vmesnik prikazuje

slika 29.



Slika 29: Drugi korak zahtevka

V odvisnosti od tega, kateri gumb bo uporabnik kliknil, se bo nastavil status

zahtevka. Če bo kliknil na Potrdi se bo nastavil status »ODOBRENO-

CAKA_KNJIZENJE«. V nasprotnem primeru, pa se bo nastavil status »ZAVRNJENO«.

Nov status je določen preko konfiguracijske datoteke, v vozliščih z definicijo

gumbov, kot je to prikazano v izvlečku kode 13.

<ELEMENT code="ok" name="Potrdi" navigateToStep="3" setStatus="ODOBRENO-CAKA_KNJIZENJE"

assignPerson="ANY" assignSector="FIN"/> <ELEMENT code="cancel" name="Zavrni" navigateToStep="4" setStatus="ZAVRNJENO" assignPer-

son="NONE" assignSector="none"/>

Izvleček kode 13: Definicija gumbov – drugi korak

Uporabnik, ki je zahtevek začel, v tem koraku ne more ničesar spremeniti, saj so

vsa polja onemogočena, kot to prikazuje slika 30.



Slika 30: Pogled uporabnika, ki nima pravic za urejanje zahtevka

3. korak Ta korak se izvede, če je uporabnik v 2. koraku potrdil zahtevek. V tem primeru se

zahtevek dodeli naključni osebi v oddelku financ. Dodeljevanje je določeno preko

konfiguracijske datoteke, v vozliščih z definicijo gumbov, kot je to prikazano v

izvlečku kode 14.

<ELEMENT code="ok" name="Potrdi" navigateToStep="3" setStatus="ODOBRENO-CAKA_KNJIZENJE"

assignPerson="ANY" assignSector="FIN"/> <ELEMENT code="cancel" name="Zavrni" navigateToStep="4" setStatus="ZAVRNJENO" assignPer-

son="NONE" assignSector="none"/>

Izvleček kode 14: Definicija gumbov – tretji korak

Uporabnik, ki mu je zahteva dodeljena, se prijavi v sistem. V seznamu zahtevkov,

ki so mu dodeljeni, vidi zahtevek, ki čaka na njegovo ukrepanje. Dodeljeni zahtevki

so prikazani na sliki 31.

Slika 31: Seznam dodeljenih zahtevkov

Potem, ko je vknjižil ure, lahko uporabnik zahtevek zaključi. Uporabniški vmesnik

tretjega koraka je prikazan na sliki 32.



Slika 32: Tretji korak zahtevka

4. korak Končni korak, kjer je na voljo samo še pregled zahtevka, brez možnosti

spreminjanja podatkov. Uporabniški vmesnik četrtega koraka je prikazan na sliki

33.

Slika 33: Končni korak zahtevka



5. IZDELAVA APLIKACIJE Za izvedbo projekta izgradnje novega sistema je bil izdelan terminski plan, ki sledi slapovni metodologiji, izdelan pa je bil s pomočjo Orodja Microsoft Visio. Naloge v terminskem planu:

Analiza zahtev in priprava načrta

Naročnik je izdelal željen seznam funkcionalnosti, na podlagi katerega je

izvajalec pripravil funkcionalne specifikacije za implementacijo aplikacije.

Pri tem koraku sta naročnik in izvajalec sodelovala. Poleg tega so bile v tem

koraku izrisane slike uporabniškega vmesnika, definiran je bil tudi

podatkovni model. Korak je bil zaključen, ko sta se naročnik in izvajalec

dogovorila o vseh funkcionalnostih in načinih implementacije.

Na strani naročnika so bili v tej nalogi vključeni skrbniki posameznih

procesov, ki so določili, kaj posamezni proces vsebuje. Na strani izvajalca

pa so bili vključeni:

o Projektni vodja in analitik - njuna naloga je bila priprava

funkcionalne specifikacije in usklajevanje z naročnikom glede

implementiranih funkcionalnosti;

o Glavni programer - njegova naloge je bila, da raziskovanje, katere

tehnologije so potrebne za implementacijo funkcionalnosti. Poleg

tega je opozarjal na morebitne »pasti« (funkcionalnosti, ki so na

papirju morda enostavne, vendar težke/nemogoče za

implementacijo) in pripravil podatkovni model.

Ponudba

Izvajalec je na podlagi funkcionalnih specifikacij izdelal finančno oceno za

izdelavo sistema. V finančni oceni so bile zajete vse funkcionalnosti, ki bodo

izvedene. Ta korak se je zaključil, ko sta se naročnik in izvajalec dogovorila

o končni ceni.

Na strani naročnika je bilo v tej nalogi vključeno vodstvo, na strani izvajalca

pa sta bila vključena:

o Projektni vodja - je pripravil oceno in končno ponudbo za izdelavo

aplikacije;

o Glavni programer - je pomagal pri pripravi ocen za posamezne

sklope/funkcionalnosti.

Implementacija

Ta korak je izvajal samo izvajalec, ki je na podlagi funkcionalnih specifikacij

izdelal aplikacijo.

Pri tej nalogi so bili vključeni:

o Projektni vodja - sicer ni bil ves čas prisoten, je pa spremljal

napredek projekta. Pred začetkom programiranja je razdelil



izgradnjo aplikacije na posamezne manjše naloge, ki jih je vnesel v

namensko aplikacijo Jira, nato pa jih je razdelil posameznim

programerjem;

o Glavni programer - njegova naloga v tem koraku je bila pomoč

ostalim programerjem pri implementaciji ter izvajanje pregledov

kode in izdelane dokumentacije;

o Programerji - vključeni so bili trije t.i. »full stack razvijalci«. Ko so s

posamezno nalogo končali, so jo dodelili analitiku v interno

testiranje.

Poleg razvoja aplikacije so imeli programerji tudi dodatne naloge:

Priprava samodejnih build-ov aplikacije (ant/maven skripte),

Priprava navodil za namestitev na testno okolje,

Priprava okolja za stres test aplikacije (gatling),

Izdelava samodejnih unit testov;

o Analitik - izvajal je interno testiranje aplikacije po nalogah, ki so jih

programerji izdelali, in potrjeval njihovo usklajenost s

funkcionalnimi specifikacijami. V primeru pomanjkljivosti pa je

nalogo vrnil programerju.

Prevzem na testno okolje

Pri tem koraku sta izvajalec in naročnik sodelovala. Izvajalec je pripravil

navodila za namestitev aplikacije in pomagal naročniku pri namestitvi. Pri

tem koraku je bil na strani izvajalca prisoten glavni programer.

Izdelava konfiguracijske datoteke

Ta korak je izvedel naročnik, izvajalec pa je nudil podporo. Naročnik je

izdelal konfiguracijsko datoteko z vsemi zahtevki, ki se bodo uporabljali tudi

na produkcijski postavitvi. Na strani izvajalca je bil prisoten analitik, ki je

tekom analize zahtev najbolj podrobno spoznal naročnikove procese.

Testiranje

Tudi pri tem koraku sta izvajalec in naročnik sodelovala. Naročnik je na svoji

postavitvi izvedel temeljito testiranje novega sistema. Ta korak se je

zaključil, ko je bil sistem v celoti testiran.

S strani naročnika so bili pri testiranju prisotni skrbniki procesov. Vsak

skrbnik pa je v proces testiranja vključil še vsaj dve osebi, ki sta izvajali

testiranje. Tako je aplikacijo s strani naročnika vsebinsko testiralo 10 ljudi.

Pri testiranju so bili prisotni tudi zaposleni v IT oddelku, vendar se niso

posvečali vsebini aplikacije, temveč so spremljali njeno delovanje (porabo

virov). Tekom testiranja se je ob vsaki verziji izvedel tudi obremenitveni

test s pomočjo gatling testov. Izvedena je bila simulacija 200 sočasnih

uporabnikov, ki so v roku 5 minut vnesli 100 zahtevkov (celoten proces – vnos

in potrjevanje). Naročnikovo testiranje je potekalo 10 dni, vendar so zaradi

ostalih službenih obveznosti testiranju lahko namenili le 4 ure na dan.

Naročnik je imel pred začetkom testiranja pripravljene konkretne testne

scenarije, vse napake, opažanja ali dodatne želje pa so bile sproti vnesene

v Jiro.



Na strani izvajalca so bili v tem koraku vključeni:

o Analitik in projektni vodja - analitik je vsako javljeno težavo preveril

in v primeru napake nalogo dodelil programerju v reševanje. Naloga

projektnega vodje je bila, da je skupaj z naročnikom razčistil

morebitne nejasnosti:

o Programerji - zadolženi so bili za odpravljanje napak, pripravo novih

verzij ter izvajanje gatling in unit testov.

Prevzem na produkcijo

Ta korak je izvedel naročnik samostojno. Vse potrjene verzije so namestili

na produkcijsko okolje, s čimer se je začela produkcijska uporaba.

Celoten terminski plan prikazuje Ganttov diagram na sliki 34.

Terminski plan

ID Task Name Start Finish Durationjun. 2017

11.630.4 4.6

1

7

15d23. 05. 20173. 05. 2017Analiza zahtev in priprava načrta

1d1. 08. 20171. 08. 2017Prevzem na produkcijo

maj 2017

21.57.5 28.514.5 18.6

3 25d5. 07. 20171. 06. 2017Implementacija

6 10d31. 07. 201718. 07. 2017Testiranje

4 3d10. 07. 20176. 07. 2017Prevzem na testno okolje

jul. 2017 avg. 2017

25.6 2.7 9.7 16.7 23.7 30.7

5 5d17. 07. 201711. 07. 2017Izdelava konfiguracijske datoteke

6.8 13.8

2 5d31. 05. 201725. 05. 2017Ponudba

Slika 34: Terminski plan izvedbe



6. ZAKLJUČKI 6.1. OCENA UČINKOV Prvi cilj vodstva v podjetju je zmanjšanje stroškov. V uvodu naloge je določeno, da je v podjetju zaposlenih 76 oseb, prav vsi pa bodo uporabljali novi računalniški sistem. V podjetju so se odločili, da bodo v začetku implementirali samo en poslovni proces, in sicer oddajo zahteve za dopust, kasneje pa bodo dodali še ostale. Ker je vodstvo zanimalo končno stanje, so pripravili statistiko obstoječih poslovnih procesov in prišli do sledečih ugotovitev:

Povprečno porabljen čas za administracijo ene iteracije procesa je 30 minut - to vključuje iskanje obrazca, izpis in izpolnjevanje obrazca, potrjevanje zahteve, prenašanje obrazca med zaposlenimi/oddelki;

Povprečno vsak zaposleni letno odda 4 zahteve za dopust;

Povprečno vsak zaposleni letno odda 3 zahteve za bolniško odsotnost:

Povprečno vsak zaposleni letno odda 1 zahtevo za spremembo uporabniških pravic;

Povprečno vsak zaposleni letno odda 5 zahtev za odsotnost med delovnim časom, kar vključuje tudi predčasni odhod ali prihod na delovno mesto;

V podjetju je 25 terenskih delavcev, ki gredo v povprečju dvakrat na teden na teren, kar skupno pomeni 2500 zahtevkov za povračilo potnih stroškov, oziroma 33 zahtevkov na zaposlenega na leto;

Lastna cena dela znaša 30 €/h. Z upoštevanjem zgoraj navedenega tako vsak zaposleni odda 46 zahtevkov letno, kar lahko prevedemo v stroške:

0,5ℎ ∗ 30€/ℎ ∗ 46 ∗ 76 = 52.440,00 € Z uvedbo novega sistema je pričakovano, da se bo čas za administracijo zahtevkov zmanjšal za vsaj 40%:

0,3ℎ ∗ 30€/ℎ ∗ 46 ∗ 76 = 31.464,00 € Prihranek na letnem nivoju bo v tem primeru znašal:

52.440,00 € − 31.464,00 € = 20.976,00 €

6.2. POGOJI ZA UVEDBO V začetku naloge smo predpostavili, da imajo v podjetju že delujočo strežniško infrastrukturo. Strošek bi torej predstavljal nakup aplikacije in čas, porabljen za izdelavo specifikacij, testiranje in nameščanje na strežnik. Ključna funkcionalnost nove aplikacije je, da administratorji v podjetju lahko sami urejajo in definirajo poslovne procese. Naloga odgovornih za posamezne procese pa je, da v času priprave specifikacij predvidijo vsa potrebna vnosna polja, ki morajo biti implementirana v aplikaciji. V kolikor vsa vnosna polje ne bodo implementirana, lahko kasneje nastajajo dodatni stroški z izdelavo novih oz. dodatnih vnosnih polj.



6.3. MOŽNOSTI NADALJNJEGA RAZVOJA Aplikacija omogoča vnos katerega koli procesa preko konfiguracijske datoteke. Konfiguracijska datoteka je zapisana v XML obliki in je za človeka težko berljiva. V naslednjih iteracijah bi torej lahko izdelali nov modul, ki bi ključnim uporabnikom omogočal grafično urejanje konfiguracijske datoteke. V aplikacijo bi bilo smiselno vpeljati tudi sporočanje po elektronski pošti o spremembi posameznega zahtevka. Tako bi bili vpleteni pri posamezni zahtevi hitreje obveščeni o stanju njihovih zahtev ali novih zahtevah, ki so jim dodeljene.



LITERATURA IN VIRI Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M.,

Thomas, D. (2001). Manifest agilnega razvoja programske opreme.

Pridobljeno iz http://agilemanifesto.org:

http://agilemanifesto.org/iso/sl/manifesto.html

Burns, E., Schalk, C., & Griffin, N. (2010). JavaServer Faces 2.0: The Complete

Reference. The McGraw-Hill Companies.

Juneau, J. (2016, 6 7). Java EE 8 Web Frameworks: A Look at JSF vs MVC.

Pridobljeno iz slideshare.net:

https://www.slideshare.net/javajuneau/java-ee-8-web-frameworks-a-

look-at-jsf-vs-mvc

Oracle and/or its affiliates. (2016). Java Authentication and Authorization Service

(JAAS) Reference Guide. Pridobljeno iz Java Documentation.

Oracle Corporation. (2017, 04 08). Pridobljeno iz MySQL 5.7 Reference Manual:

https://downloads.mysql.com/docs/refman-5.7-en.a4.pdf

Oracle. (n.d.). What is Java technology and why do I need it? Pridobljeno iz

java.com: https://www.java.com/en/download/faq/whatis_java.xml

Pobega, D. (2016). Primer izboljšave odzivnosti trinivojske aplikacije. Pridobljeno

iz UNIVERZA V LJUBLJANI: https://repozitorij.uni-

lj.si/Dokument.php?lang=slv&id=87966&dn=

Red Hat, Inc. (2017). What is virtualization? Pridobljeno iz Rad Hat:

https://www.redhat.com/en/topics/virtualization/what-is-virtualization

Schalk, C. (2005, April). Introduction to Javaserver Faces - What is JSF? Pridobljeno

iz Oracle.com: http://www.oracle.com/technetwork/topics/index-

090910.html

Weitzer, A. (2009). Primerjava in vrednotenje procesov razvoja programske

opreme. Ljubljana.

What is open source? (n.d.). Pridobljeno iz Opensource.com:

https://opensource.com/resources/what-open-source

Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M.,

Thomas, D. (2001). Manifest agilnega razvoja programske opreme.

Pridobljeno iz http://agilemanifesto.org:

http://agilemanifesto.org/iso/sl/manifesto.html

Burns, E., Schalk, C., & Griffin, N. (2010). JavaServer Faces 2.0: The Complete

Reference. The McGraw-Hill Companies.

Juneau, J. (2016, 6 7). Java EE 8 Web Frameworks: A Look at JSF vs MVC.

Pridobljeno iz slideshare.net:

https://www.slideshare.net/javajuneau/java-ee-8-web-frameworks-a-

look-at-jsf-vs-mvc



Oracle and/or its affiliates. (2016). Java Authentication and Authorization Service

(JAAS) Reference Guide. Pridobljeno iz Java Documentation.

Oracle Corporation. (2017, 04 08). Pridobljeno iz MySQL 5.7 Reference Manual:

https://downloads.mysql.com/docs/refman-5.7-en.a4.pdf

Oracle. (n.d.). What is Java technology and why do I need it? Pridobljeno iz

java.com: https://www.java.com/en/download/faq/whatis_java.xml

Pobega, D. (2016). Primer izboljšave odzivnosti trinivojske aplikacije. Pridobljeno

iz UNIVERZA V LJUBLJANI: https://repozitorij.uni-

lj.si/Dokument.php?lang=slv&id=87966&dn=

Red Hat, Inc. (2017). What is virtualization? Pridobljeno iz Rad Hat:

https://www.redhat.com/en/topics/virtualization/what-is-virtualization

Schalk, C. (2005, April). Introduction to Javaserver Faces - What is JSF? Pridobljeno

iz Oracle.com: http://www.oracle.com/technetwork/topics/index-

090910.html

Weitzer, A. (2009). Primerjava in vrednostenje procesov razvoja programske

opreme. Ljubljana.

What is open source? (n.d.). Pridobljeno iz Opensource.com:

https://opensource.com/resources/what-open-source



KAZALO SLIK Slika 1: Organizacijska shema podjetja ...................................... 2 Slika 2: Potek komunikacije v tronivojski arhitekturi ...................... 4 Slika 3: Delovanje javanskega virtualnega stroja (JVM) ................... 5 Slika 4: MVC ...................................................................... 7 Slika 5: Strežniki brez virtualizacije .......................................... 8 Slika 6: Strežniki z uporabo virtualizacije ................................... 9 Slika 7: Slapovna metodologija .............................................. 10 Slika 8: Diagram poslovnega procesa ....................................... 14 Slika 9: Funkcijski diagram zahtevka za oddajo dopusta ................ 15 Slika 10: SWOT analiza ....................................................... 15 Slika 11: Podatkovni model uporabnikov ................................... 18 Slika 12: Prijavna stran ....................................................... 19 Slika 13: Orodna vrstica ...................................................... 19 Slika 14: Administracija uporabnikov ....................................... 20 Slika 15: Dialog s podatki uporabnika ...................................... 20 Slika 16: Procesni diagram zahtevka ....................................... 23 Slika 17: Vertikalni meni ..................................................... 24 Slika 18: Vstopna stran ....................................................... 24 Slika 19: Zgodovina zahtevkov ............................................... 24 Slika 20: Stran z vsebino zahtevka .......................................... 26 Slika 21: Stran z vsebino zahtevka v povezavi z konfiguracijsko datoteko ................................................................................... 26 Slika 22: Podatkovni model zahtevkov ..................................... 27 Slika 23: Življenjski cikel zahtevka za odobritev dopusta ............... 30 Slika 24: Izbira zahtevka iz levega vertikalnega menija ................. 31 Slika 25: Forma za vnos zahtevka v prvem koraku........................ 32 Slika 26: Blokade v primeru manjkajočih podatkov ...................... 32 Slika 27: Primer uspešne oddaje zahtevka ................................. 33 Slika 28: Seznam dodeljenih zahtevkov .................................... 33 Slika 29: Drugi korak zahtevka .............................................. 34 Slika 30: Pogled uporabnika, ki nima pravic za urejanje zahtevka .... 35 Slika 31: Seznam dodeljenih zahtevkov .................................... 35 Slika 32: Tretji korak zahtevka .............................................. 36 Slika 33: Končni korak zahtevka ............................................. 36 Slika 34: Terminski plan izvedbe ............................................ 39



KAZALO IZVLEČKOV KODE Izvleček kode 1: Poizvedba za pridobivanje gesla ...................................... 18 Izvleček kode 2: Poizvedba za pridobivanje uporabnikovih rol ....................... 18 Izvleček kode 3: Konfiguracija JAAS na strežniku WildFly ............................. 18 Izvleček kode 4: Konfiguracijska datoteka ............................................... 22 Izvleček kode 5: Osnovna poizvedba za postopek dodeljevanja ...................... 27 Izvleček kode 6: Bazni pogled ............................................................. 27 Izvleček kode 7: Dodaten pogoj USERS_SECTOR ........................................ 28 Izvleček kode 8: Dodaten pogoj za poljuben sektor .................................... 28 Izvleček kode 9: Dodaten pogoj VODJA_ODDELKA ...................................... 28 Izvleček kode 10: Nesmiseln pogoj poizvedbe ........................................... 29 Izvleček kode 11: Dodaten pogoj za točno določenega uporabnika .................. 29 Izvleček kode 12: Konfiguracijska datoteka ............................................. 31 Izvleček kode 13: Definicija gumbov – drugi korak ..................................... 34 Izvleček kode 14: Definicija gumbov – tretji korak ..................................... 35

razvoj aplikacije za podporo administrativnim … · marketinga vodja µv}À} À vodja vodja it...

Documents