RAZVOJ APLIKACIJE ZA PODPORO ADMINISTRATIVNIM PROCESOM V ORGANIZACIJI

Transkripcija

1 Organizacija in management informacijskih sistemov RAZVOJ APLIKACIJE ZA PODPORO ADMINISTRATIVNIM PROCESOM V ORGANIZACIJI Mentor: doc. dr. Davorin Kofjač Kandidat: Simon Kralj Kranj, september 2017

2 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.

3 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

4 KAZALO 1. Uvod Predstavitev problema Predstavitev okolja Predpostavke in omejitve Metode dela Teoretične osnove Opredelitev osnovnih pojmov Obstoječe stanje Popis funkcionalnosti sistema Prijava v sistem in varnost Orodna vrstica Administracija uporabnikov Administracija zahtevkov Začetna stran Vsebina zahtevka Postopek dodeljevanja ZAHTEVKOV Primer procesa Izdelava aplikacije Zaključki Ocena učinkov Pogoji za uvedbo Možnosti nadaljnjega razvoja Literatura in viri Kazalo slik Kazalo izvlečkov kode... 45

5 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 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 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. Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 1

6 Direktor Vodja nabave Vodja IT Vodja proizvodnje Vodja marketinga Vodja računovodstva Vodja razvoja Vodja kadrovske službe 5 zaposlenih Administratorji 3 zaposleni Izdelovalci 10 zaposlenih Komercialisti 10 zaposlenih 5 zaposlenih 10 zaposlenih 5 zaposlenih Monterji Prodaja 15 zaposlenih 5 zaposlenih 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 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 Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 2

7 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. Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 3

8 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 Vrača rezultate Zahteva podatke Vrača podatke 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 Java je programski jezik, ki temelji na sočasnosti, Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 4

9 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) Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 5

10 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. Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 6

11 Faces Servlet JSF 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. Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 7

12 "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. Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 8

13 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 Fronta«(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. Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 9

14 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 Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 10

15 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, Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 11

16 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; Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 12

17 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. Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 13

18 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 Povratna informacija Izpolni zahtevek Zahtevek Potrjevanje zahtevka Zavrnjen zahtevek Potrjen zahtevek Obdelava zahtevka Obdelan zahtevek Arhiviranje zahtevka 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. Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 14

19 Funkcijski diagram - dopust Zaposleni Začetek Izpis in izpolnjevanje zahtevka Odgovorna oseba Pregled ustreznosti in potrjevanje zahtevka Ali je zahteva odobrena? Da Arhiv Finance Ne Knjiženje ur Arhiviranje 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. Pozitivno Prednosti Dobro definirani procesi Priložnosti Zmanjšanje porabljenega časa Avtomatizacija preprostih nalog Ni papirnega arhiva Trend (oblačne storitve) Lažje spreminjanje procesov Vsi procesi bodo na enem mestu Negativno Slabosti Izguba časa Ni avtomatskih kontrol Velik arhiv Težja uveljavitev sprememb procesa Slika 10: SWOT analiza Nevarnosti Napačna definicija procesa v konfiguracijski datoteki Odpoved IT opreme Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 15

20 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 Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 16

21 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 Test1234 Kodirano geslo 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. Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 17

22 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. Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 18

23 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. Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 19

24 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: Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 20

25 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 o obvezen, ali ne; dovoljeni sta vrednosti»true«in»false«; 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 o o NavigateToStep določa naslednji korak zahtevka; zapiše se šifra naslednjega koraka, določena v konfiguraciji zahtevka; setstatus določa naslednji status zahtevka; zapiše se status zahtevka, dovoljen je poljuben niz znakov; 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. Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 21

26 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 Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 22

27 Proces takšne zahteve prikazuje procesni diagram na sliki 16. Start Prikaži uporabniški vmesnik Oddaj zahtevo Obravnava zahteve Da Ali je zahteva odobrena Ne Nastavi status ODOBRENO Nastavi status ZAVRNJENO 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. Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 23

28 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 Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 24

29 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 je ta vrednost zapisana na zahtevku, v podatkovni bazi pa je zapisana v polju ZAH_ZAHTEVEK.DATUM_DO. Opomba - polje, v katerega uporabnik vnese poljuben niz znakov. V aplikaciji je ta vrednost zapisana na zahtevku, v podatkovni bazi pa je zapisana v polju 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 Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 25

30 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. Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 26

31 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 Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 27

32 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 Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 28

33 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 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. Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 29

34 Začetek Izpolni zahtevek za odobritev dopusta. Oddaj zahtevek v odobritev nadrejeni osebi. Ne Ali je zahtevek odobren? Da Oddaj zahtevek v arhiv. Oddaj zahtevek v finance, v knjiženje. Knjiženje ur Konec Slika 23: Življenjski cikel zahtevka za odobritev dopusta Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 30

35 <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" 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-caka_knjizenje" assignperson="any" assignsector="fin"/> <ELEMENT code="cancel" name="zavrni" navigatetostep="4" setstatus="zavrnjeno" assignperson="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" assignperson="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. Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 31

36 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. Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 32

37 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. Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 33

38 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" assignperson="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. Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 34

39 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" assignperson="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. Simon Kralj: Razvoj aplikacije za podporo administrativnim procesom v organizaciji stran 35