MODEL ODRŽAVANJA POSLOVNIH APLIKACIJA U UVJETIMA PROMJENE POSLOVNOG OKRUŽENJA

1. UVOD

Izazov informatizaciji u sve većoj trendovskoj globalizaciji postavljaju sve teže zahtjeve kako prema krajnjem korisniku tako i prema regulatoru. Nepobitne činjenice su da su u svijetu velike količine podataka, strateška prednost onoga koji može iz velike količine informacija filtrirati korisne podatke, te na temelju tako dobivenih podataka donijeti brzu odluku. Sa druge strane zahtjevi regulatora višeg informacijskog sustava prvenstveno su usmjereni na unapređenju funkcionalnosti te na sigurnost svojih izloženih sustava. Izloženost sustava manifestira se prvenstveno zbog razmjene nformacija, koja se odvija dvosmjerno i to u smjeru nižeg informacijskog sustava prema većem i obrtnuto. Razmjena podataka uobičajeno se vrši putem datoteka formata (pdf, xml, rtf, txt, csv, xls, xlsx, doc, docx i drugih datoteka). Nerijetko regulatori mijenjaju strukturalnu shemu datoteka za razmjenu podataka, a integracija i važnost kompatibilnosti informacijskih sustava sve više postaje bitan faktor u poslovnom svijetu pa se niži informacijski sustavi moraju prilagoditi novonastalim uvjetima.

Primjena standarda u fazi razvoja i arhitekture rezultira dobivanjem maksimalne karakteristike softvera.

Metodološkom primjenom standardaISO/IEC 25010:2011 omogućavamo:

Prikladnost softvera za održavanje jedan je od ISO faktora ocjene kvalitete. Unaprjeđenjem kvalitete softvera u procesu razvoja smanjuje se intenzitet aktivnosti na održavanju softvera. Implementiranje svih funkcionalnosti sustava tijekom razvoja softvera od iznimne je važnosti jer implementiranje funkcionalnosti u procesu održavanja rezultiranje lošijim performansama softvera (Sretenović i Kovačić, 2020).

Unatoč dosljednoj primjeni standardaISO/IEC 25010:2011, nije moguće u potpunosti predvidjeti sve aspekte održavanja, ali je nužno održavanje temeljiti na dosljednim metodološkim planskim principima održavanja poslovnih aplikacija.

Očekivani rezultati primjenom modela održavanja poslovnih aplikacija u uvjetima promjene poslovnog okruženja su:

Kako bi korisnik dobio pravovaljane i brze odgovore, informacijski sustavi se moraju redovito prilagođavati, unapređivati i održavati.

Automatizacija zahtijeva određenu dozu jasnoće procesa već u fazi projektiranja, a modeliranje procesa kao i sam razvoj aplikacije moraju pratiti suvremene trendove s krajnjim ciljem zadovoljstva korisnika (Sretenovic et al., 2016).

Definirana su sljedeća istraživačka pitanja:

1. Model održavanja baziran na vremenskoj komponenti primjenjiv je u procesima održavanja poslovnih aplikacija?

2. Predloženim modelom održavanja baziran na vremenskoj komponenti smanjuje vrijeme održavanja poslovnih aplikacija?

Istraživanju i koncipiranju rada pristupili smo metodološki principom autoraGregora i Hevnera kroz šest poglavlja i to:

2. PREGLED LITERATURE

Informacijski sustavi izloženi su vanjskim utjecajem i možemo ih prezentirati zahjevima korisnika i funkcionalnim okruženjem. Troškovi održavanja su veliki zbog same činjenice da je životni vijek softvera vezan za održavanje. Nakon predaje softvera u eksploatacijsku produkciju pa do njegovog gašenja, period je kada je održavanje neophodno, kako bi zadovoljio funkcionalnim zahjevima korisnika, tako i funkcionalnim zahjevima viših informacijskih sustava regulatora. Nakon što je softver ušao u fazu eksploatacije bilo kakva intervencija na softveru smatra se održavanje.

IEEE [IEEE610.12-1990] je standard koji definira sposobnost programskog inženjerstva za održavanje softvera radi zadovoljenja specificiranih zahtjeva [ISO, 1990]. Ovim standardom definirane su kategorije kvaliteta održavanja s ciljem umanjenja troška održavanja, te pristupa održavanju.

Sistemskim pristupom održavanja određujemo podjelu održavanja na: održavanje sheme ili pogleda te održavanje usmjereno na verzioniranje shema.

U svome istraživanju, skup formalnih operacija održavanja autoriBlaschka et al. baziraju na formalnom modelu uređene šestorke te navode da je poslovno okruženje posljedica korisnikovog zahtjeva na održavanju, u svom radu model održavanja pristupaju modelom održavanja sheme.

Formalni model definiraju kao:

gdje su konačni skupovi:

Fc – činjenica

Ld – dimenzija

Ab – atributa

Funkcije:

Gr – povezivanja činjenica i dimenzija

Cl – relacije

At – povezivanja atributa činjenice i razine dimenzija.

U okviru definiranog modela autori su definirali skup formalnih operacija održavanja. Konceptualnim pristupom model definira održavanje sheme, te nakon funkcionalne prilagodbe slijedi proces implementacije (Blaschka et al., 1999).

Rad autora Papastefanatos et al. iz područja Održavanje verzioniranjem sheme održavanje definira rješavanjem problema analizom podataka na izvoru. U svojem istraživanju predlaže održavanja jedinstvenim modelom relacije te modelom grafa I prikazom stanja, pogleda i upita (Papastefanatos et al., 2007).

Rad na temu održavanja pogleda autori Bouzeghoub i Kedad opisuju procesom postupnog održavanja pogleda, te u svojem istraživanju navode da se proces mora sageldavati u četiri prizme dimenzija i to: informacije, jezika, promjena i instance (Bouzeghoub i Kedad, 2000).

Autor Djerdjouri u svom radu pojašnjava ključnu ulogu umjetne inteligencije u konkurentnosti malih i srednjih poduzeća te potrebu što je većeg opsega ulaganja I implementacije aplikatvnih rješenja baziranih na umjetnoj inteligenciji. Nadalje navodi da su bez poslovne inteligencije tvrtke izložene riziku donošenja kritičnih odluka na temelju bilo nedovoljne ili netočne informacija. Korištenjem umjetne inteligencije omogućava se jednostavno kreiranje detaljnih financijskih izvješća, izvješća o operacijama, korisnicima i dobavljačima (Djerdjouri, 2020).

Autor Waszkowski u svom radu pojašnjava nove trendove u razvoju I održavanju poslovnih aplikacija. Platforma niskog koda omogućuje brzo generiranje i isporuku poslovnih aplikacija s minimalnim naporom pisanja programskog koda a ujedno zahtijeva najmanji mogući napor za instalaciju i konfiguracija okruženja, te obuka i implementacija. Ovaj rad opisuje korištenje niskokodne platforme Aurea BPM za automatizaciju poslovanja (Waszkowski, 2019).

Autori Rahman et al. u svom radu akcentiraju vremensku komponentu održavanja, navode da održavanje aplikacije oduzima znatnu količinu vremena i sredstava svake godine. Gotovo 60 % IT proračuna troši se samo na održavanje aplikacija. Razloge za korištenjem usluga održavanja vanjskih korisnika nije samo u smanjenje troškova održavanja, već i oslobađanje resurse i zadržanju fokusa na temeljnim proizvodima. Korištenjem usluga održavanja vanjskih korisnika je uobičajena poslovna strategija koje tvrtke koriste za postizanje uštede troškova od oko 20 - 50 %. Međutim, proces donošenja odluka održavanja aplikacije složena je pojava. Temelji se na nizu čimbenika utjecaja, klijentovih zahtjeve i prirodu projekta (Rahman et al., 2020).

3. METODE

Studija Metodologija istraživanja znanosti o dizajnu (DSRM) je metodologija koju koristimo u ovom istraživačkom radu. Ova metodologija istraživanja znanosti o dizajnu provodi se u šest koraka, a to su:

4. OPIS ARTEFAKTA

4. 3 Dizajn i razvoj

Dizajn modela održavanja uključuje:

1. Definiranje formalnog zapis transformacijskog modela održavanja

a. definiranje formalnog zapisa strukture relacijske baze podatka (RLDT)

b. uvođenje vremenske komponente transformacijskog modela i definiranje algoritama transformacijskog modela za prijelaze između stanja RLDT

2. izrada konceptualnog modela održavanja

Dijagram prijelaza između stanja RLDT uvođenjem vremenske komponente modela predstavlja usmjereni graf. Čvorovi grafa odgovaraju stanjima automata a grane prijelaza označene su alfabetom. Prikazom funkcije prijelaza između čvorova dobivamo konačni automat (Slika 1.).

Formalni model održavanja poslovnih aplikacija u uvjetima promjene poslovnog okruženja zasnovan je na relacijskoj algebri i teoriji skupova.

Formalno možemo definirati uređenom petorkom, gdje je konačni skup stanja definiran:

$$\mathrm{MR}=(K,p,\alpha ,q_0,\mathrm{ZS})$$

Za koji vrijedi da je:

K = MR = {F₁, F₂, F₃, ..., F_n} – konačni skup stanja

p = {0, 1} - iskazna logika

α – funkcija prijelaza, za koju vrijedi da je

α: K×p → R(K) gdje je R(K) particija od K,

dok je stanje prijelaza definirano: F₁→F₂, F₂→F₃, ..., F_n-1→F_n

q₀ – početno stanje, za koju vrijedi da je q₀∈K, F₁ za α₁ vrijeme implementacije i predstavlja početno stanje

ZS – skup završnih stanja, ZS⊆K , opisuje je stanje F_n za trenutak v_n.

Slika 1. Dijagram prijelaza modela

Izvor: Autor

Formalni zapis transformacijskog modela uključuje formalni zapis strukture baze podataka te uvođenje vremenske komponente transformacijskog modela te definiranjem algoritama transformacijskog modela. Zbog detaljnosti formalnog zapisa transformacijskog modela, prezentiran je samo formalni zapis transformacije RLDT, tablica i atributa.

Relacijskih shema za relacijsku bazu definiramo je skupom:

RSHEMA₁ = {ZSHE₁, ZSHE₂,….., ZSHE_n};

ZSHE₁ = {nosh₁, vrem₁, vrem₂} – zapis relacijske sheme modela za datumski period

nosh₁ – identifikator modela za relacijsku bazu

vrem₁ – datum početka primjene

vrem₂ – datum kraja primjene

Element strukture relacijske baze modela:

$${\mathrm{ES}}_{\mathrm{TRLDTn,i}}=({\mathrm{RLDT}}_n,({\mathrm{nosh}}_i,\{0,1\}\left)\right);n,i\in \mathrm{N}$$

RLDT_n – relacijska baza podataka

nosh_i – identifikator modela

Funkcija aktivacije i deaktivacije transformacijskog modela prikazana je utablici 2.

Tablica 1. Tablica prijelaza modela za relacijsku bazu

Staro stanje	Funkcija aktivacije	Novo stanje
ESTRLDTn,i = (RLDTn, (noshi,0))	f1(RLDTn,noshi))→ts:0→1	ESTRLDTn,i = (RLDTn, (noshi,1))
Staro stanje	Funkcija deaktivacije	Novo stanje
ESTRLDTn,i = (RLDTn, (noshi,1))	f2(RLDTn,noshi))→ts:1→0	ESTRLDTn,i = (RLDTn, (noshi,0))

Izvor: autor

Element strukture podatka tablice RTB_n,t relacijske baze RLDT_n čini uređeni par:

$${\mathrm{ES}}_{\mathrm{TBn,t}}=({\mathrm{RLDT}}_n,{\mathrm{RTB}}_{n,t});n,t\in \mathrm{N}$$

RLDT_n – relacijska baza podataka

RTB_n,t – relacijska tablica u relacijskoj bazi RLDT_n.

Funkcija aktivacije i deaktivacije transformacijskog modela prikazana je utablici 3.

Tablica 2. Tablica prijelaza transformacijskog modela za relacijske tablice

Staro stanje	Funkcija aktivacije	Novo stanje
ESTRTBn,i = (ESTBn,t, (noshi,0))	f3(ESTBn,t,noshi))→ts:0→1	ESTRTBn,i = (ESTBn,t, (noshi,1))
Staro stanje	Funkcija deaktivacije	Novo stanje
ESTRTBn,i = (ESTBn,t, (noshi,1))	f4(ESTBn,t,noshi))→ts:1→0	ESTRTBn,i = (ESTBn,t, (noshi,0))

Izvor: autor

Element strukture podatka atributa at_n,t,m tablice RTB_n,t relacijske baze RLDT_n čini uređena trojka:

$${\mathrm{ES}}_{\mathrm{ATn,t,m}}=({\mathrm{RLDT}}_n,{\mathrm{RTB}}_{n,t},{\mathrm{at}}_{n,t,m});n,t,m\in \mathrm{N}$$

RLDT_n – relacijska baza podataka

RTB_n,t – relacijska tablica u relacijskoj bazi RLDT_n

at_n,t,m – atribut relacijske tablice RTB_n,t relacijske baze RLDT_n.

Funkcija aktivacije i deaktivacije transformacijskog modela prikazana je utablici 4.

Tablica 3. Tablica prijelaza modela za atribute relacijske tablice

Staro stanje	Funkcija aktivacije	Novo stanje
ESTRATn,t,m = (ESATn,t,m, (noshi,0))	f5(ESATn,t,m,noshi))→ts:0→1	ESTRATn,t,m = (ESATn,t,m, (noshi,1))
Staro stanje	Funkcija deaktivacije	Novo stanje
ESTRATn,t,m = (ESATn,t,m, (noshi,1))	f6(ESATn,t,m,noshi))→ts:1→0	ESTRATn,t,m = (ESATn,t,m, (noshi,0))

Izvor: autor

Naslici 2 prikazan je konceptualni model korišten za razvoj informacijskog sustava podržanog za modelom održavanja zasnovanog na vremenskoj komponenti.

Elementi modela prikazani su naslici 2 i sastoje se od:

• mehanizam za sakupljanje znanja - u procesu prikupljanja znanja vrše se procesi analize, provjera i oblikovanja znanja koje pohranjujemo u bazu znanja

• baza znanja - sastoji se od dva modula i to baza činjenica u kojem se evidentiraju početna stanja i baza pravila u kojem se nalaze operatori čija je funkcija pretvaranja stanja problema u rješenje

• mehanizam analize, ima ulogu provjeravati upite te pronaći podatke u bazi činjenica za datumski period

• mehanizam izuzetaka ima ulogu da vrati korisniku informaciju o definiranju upita izvan datumskog perioda

• mehanizam zaključivanja, ima ulogu usporedbe činjenica sa pravilima, te na temelju toga zaključuje o pokretanju akcije koje će se izvršiti prema pravilima u bazi pravila, za upit proslijeđen od mehanizma analize pretraživanjem baze znanja donosi odluku o pokretanju akcija

• kontrolno-logički mehanizam, nastavlja se na mehanizam zaključivanja, u slučaju da je upit izvan datumskih kriterija u mehanizmu rezultata neće biti promjena u odnosu na trenutno stanje sustava, dok u uvjetima da je upit unutar datumskih varijabli putem mehanizma transformacije pokreće se prilagodba postojećeg stanja novom stanju sustava.

• mehanizam transformacije, sastoji se od pravila za prilagodbu i prilagodbe povratnim procesima te nakon potvrde kontrolno-logičkog mehanizma nakon prilagodbi dolazi do mehanizma rezultata

• mehanizam rezultata, mehanizam u kojem se rezultiraju prethodni koraci

• korisničko sučelje, omogućuje interakciju korisnika sa sustavom.

Slika 2. Konceptualni model

Izvor: autor

5. EVALUACIJA I RASPRAVA

Učinkovitost modela demonstrirana je usporedbom vremena potrebnog u procesu održavanja uslijed Zakonskih izmjena uvođenjem nulte stope PDV-a.

Provedenom procjenom zaključujemo da je moguće implementirali i dizajnirati model koji je ubrzao proces održavanja poslovnih aplikacija, čime smo odgovorili na drugo postavljeno istraživačko pitanje. Doprinos ovog istraživanja je model koji ima cilj unaprijediti poslovanje u segmentu poslovnih aplikacija, te unaprijediti održavanje i životni ciklus aplikacija.

Održavanje poslovnih aplikacija iz područja poreznog Zakonodavstva je posebno osjetljiv dio poslovanja zbog niza faktora koji određuje Zakonodavac u svojim pravilima. Svaka pogreška može uzrokovati Zakonske posljedice za korisnika. Korištenjem predloženog modela povećavamo produktivnost i zadovoljstvo korisnika. Ukupni doprinos ovog istraživanja sastoji se u primjeni modela u rješavanju problema automatizacije procesa održavanja poslovnih aplikacija bez intervencije u programski kod aplikacija. Problem održavanja poslovnih aplikacija vrlo su česti, a cilj ovog istraživanja je smanjiti vrijeme i utjecaj intervencije na programski kod. Ujedno ovakvi modeli održavanja predstavljaju automatizirane procese i pomažu korisniku u uštedi vremena, novca i resursa. Ovaj model automatiziranog sustava ubrzava poslovne procese iz domene menadžmenta i iz domene primjene i pridržavanja Zakonskih pravila. Ovakvi automatizirani modeli umanjuju mogućnost pogreške, prvenstveno zbog minimalnog ljudskog utjecaja na proces. Budućnost nam sigurno donosi nove promjene u shemi vezanoj za porezno zakonodavstvo, te ostavlja prostor za daljnje unapređenje modela. Buduća istraživanja trebaju biti usmjerena na potpunu automatizaciju poslovnih procesa održavanja uz što manje intervencije na strukturnu promjenu programskog koda i oblika te strukturnu promjenu sheme baze podataka.

Izvor podatakaTablice 7 kolona prosječno vrijeme održavanja provedenih pomoću programa Google Forms iz doktorskog rada Sretenović (Sretenovic, 2019), bez primjene modela i primjenom modela na reprezentativnom uzorku kod pravnih subjekata koji su razvrstan po Nacionalnoj klasifikaciji djelatnosti u područje J - Informacije i komunikacije, nedvojbeno potvrđuje opravdanost projektiranja i primjene modela. Iz same tablice razvidno je da je očekivano prosječno vrijeme održavanja poslovnih aplikacija bez primjene modela 405,50 minuta, dok je očekivano vrijeme održavanja primjenom modela 234,01 minuta. Prosječna očekivana razlika iznosi 171,49 minuta.

6. ZAKLJUČAK

Pouzdana i brzo dostupna usluga održavanja danas je tendencija u poslovnim procesima Za očekivati je da će se porezno-financijski standardi nadograđivati i unapređivati, kako na prijedloge korisnika, teko i na prijedloge Zakonodavca. Predloženi model može se primijeniti i na specijalizirane izvještaje korisnika, brzina informacija u poslovnom svijetu je ponekad presudna, tako da predloženi model ima još veću težinu u svojoj primjeni.

Radi se o modelu kojeg je moguće implementirati i koji ima jedinstven pristup održavanju, ima niz direktnih i indirektnih prednosti. Direktne prednosti su brzina, lakoća održavanja te izbjegavanje intervencije u programski kod, nadalje omogućava jedinstven pristup izradi izvještaja po zahtjevu korisnika. Sa druge strane ovakav model štedi novac i financijske resurse potrebne za održavanje, kao i ne manje vrijednu činjenicu da ovakav model produljuje životni vijek poslovne aplikacije. Krajnji cilj modela je pomoći nositeljima donošenja odluka o korištenju modela, kao i ponuditi smjernice za razvoj vlastitih modela održavanja baziranog na ovom modelu.