INFORMATIČKO RJEŠENJE JEDINSTVENE BAZE ŠTETNIKA
– PROJEKTNI ZADATAK –
SARAJEVO, februara-veljače, 2010. godine
UDRUŽENJE DRUŠTAVA ZA OSIGURANJE U FEDERACIJI BOSNI I HERCEGOVINI UDRUGA DRUŠTAVA ZA OSIGURANJE U FEDERACIJI BOSNI I HERCEGOVINI ASSOCIATION OF INSURANCE COMPANIES IN FEDERATION OF BOSNIA AND HERZEGOVINA 71000 SARAJEVO, Zmaja od Bosne 4/IX-3 ODBOR ZA INFORMATIKU
1. INFORMATIČKO RJEŠENJE JEDINSTVENE BAZE ŠTETNIKA
– PROJEKTNI ZADATAK
Informatičko rješenje jedinstvene baze štetnika ima cilj da pruži pouzdan, brz i siguran pristup bazi
štetnika. Pristup treba da obezbijedi jedostavan način za unos i konzumaciju podataka kroz različite
kanale, koji podrazumijevaju distribuciju podataka putem web aplikacije, GSM/GPRS servisa, uz
postojanje interfejsa u vidu WEB servisa. Jedinstvena baza štetnika treba biti skalabilno i lako
nadogradivo rješenje za razvijanje dodatnih kanala pristupa. Rješenje mora da garantuje jednostavan
i siguran transfer podataka uz mogudnost egzaktnih mehanizama kontrole pristupne politike,
podataka (prvenstveno izdatih polica i predmeta šteta). Rješenje treba biti bazirano na zadnjim
dostupnim informacionim tehnologijama koje omogudavaju visoku pouzdanost, dostupnost i
sigurnost, te mogudnost lake nadogradnje i unapređenja.
1.1. Okvir projekta
Jedinstvena knjiga štetnika predstavlja osnovni element podrške implementaciji pravne regulative
vezane za uređivanje oblasti saradnje društava za osiguranje u FBiH.
Jedinstvena knjiga
štetnika
Treće strane
(Biro zelene
karte, Agencije
osiguranja,
Zaštitni fond i
ostali...)
Članice
UdruženjaUnutrašnji
interfejsi
UDOFBiH
Ilustracija 1 - Blok šema interoperabilnosti jedinstvene knjige štetnika
1.1.1. Osnovni principi i koncepti informacionog sistema
Osnovne principe i koncepte sistema trebaju predstavljati komponente potrebne za rad modernih IT
sistema, i to sljededih 5 komponenti:
Dijeljena infrastruktura
Informacije
Servisno orjentisana infrastruktura
Razvojno okruženje
Nadzor i upravljanje sistemima i aplikacijama
U nastavku de biti specificirani konkretni zahtijevi za svaku od 5 prikazanih komponenti.
Ra
zvo
jno
okru
že
nje
Up
ravlja
nje
sis
tem
ima
i
ap
lika
cija
ma
Servisno orijentirana
arhitektura
Informacije
Dijeljena infrastruktura
Softverska arhitektura
Ilustracija 2 - Model softverske arhitekture
1.1.1.1. Dijeljena infrastruktura
Dijeljena infrastruktura treba :
Omoguditi maksimalan povrat investicije u infrastrukturu IT sistema
Smanjiti vrijeme iskorištenja i vlasništva uređaja za pohranu podataka (Storage), servera, softvera i aplikacija
Omoguditi kvalitetan nivo servisa krajnjim korisnicima IT sistema IT sistem baziran na dijeljenoj infrastrukturi treba biti u mogudnosti odgovoriti na zahtjeve
poslovanja, da je fleksibilan, da nije kompleksan i skup za održavanje, te da je u stanju pružiti
odgovarajudi nivo servisa krajnjim korisnicima.
Dijeljena infrastruktura treba se sastojati od uređaja za pohranu podataka, odvojenih servera baze
podataka, komponenti srednjeg sloja-aplikacijskog servera kao i alata za nadzor i upravljanje
cjelokupne dijeljene infrastrukture.
Na nivou Storage-a treba omoguditi automatsko upravljanje raspoloživim diskovnim prostorom –
Automatic Storage Management kako bi Storage omogudio jedinstven logički pogled na sve objekte
(različite tipove podataka) koji se u njega pohranjuju bez obzira na klasifikaciju podataka i tehnologiju
na kojoj se Storage zasniva.
Storage treba obezbijediti prostor na zahtjev i mogudnost da se njime automatski upravlja kroz
automatizirane procedure, kako bi se najbolje iskoristio prostor i optimizirao i balansirao I/O, u cilju
spriječavanja uskih grla.
Kako se podaci moraju pohranjivati i izvan sistema – offline backup, potrebno je omoguditi da su
procedure za njihovo održavanje dostupne i da su podaci istovremeno dostupni ali i zaštideni, u
slučaju gubljenja ili otuđenja medija na kojima su pohranjeni.
Na nivou servera baze podataka potrebno je predvidjeti mogudnosti dinamičkog iskorištenja
klasterske tehnologije – udružiti i dijeliti više servera te omoguditi aplikacijama da raspolažu
resursima servera baze podataka prema potrebama tj. definiranje servisa koji de omoguditi da se kroz
alocirane resurse izvrše potrebne operacije na serveru baze podataka u granicama zahtjevanog
kvaliteta servisa, uz balansiranje opteredenja servera.
Također, potrebno je predvidjeti i mogudnost kopiranja podataka na rezervnu lokaciju, s koje de, u
razumnom vremenskom roku biti mogude neometano nastaviti raditi u slučaju da primarna lokacija
nije u funkciji (bilo da je došlo do logičkih ili fizičkih oštedenja, zbog katastrofe bilo koje vrste).
Na srednjem sloju je potrebno predvidjeti da se ravnomjerno iskoriste resursi aplikacijskih serverskih
resursa, te obezbijediti raspoloživost i sposobnost aplikacijskih servera da funkcioniraju po principu
klastera servera baze podataka.
Potrebno je omoguditi monitoring iskorištenja resursa na srednjem sloju i dinamičko podešavanje
kapaciteta prema zahtjevima aplikacija, na osnovu specifičnih politika održavanja nivoa servisa –
predvidjeti neku vrstu ekspertnog sistema koji može prilagođavati raspoloživost kapaciteta servera i
predlagati najbolje politike na bazi iskustva u ponašanju rada aplikacija.
Potrebno je predvidjeti komponente/alate za nadzor i upravljanje kojima se automatski i jednostavno
može kontrolisati iskorištenost resursa dijeljene infrastrukture. Alati trebaju omoguditi automatski i
centralizitan nadzor i upravljanje zasnovano na definiranim politikama rada aplikacija. Potrebno je
omoguditi neprekidan nadzor svih prikupljenih informacija sa resursa koji se koriste: diskova, servera,
svake softverske komponente (operativni sistem, baza podataka, komponente aplikacijskih servera,
aplikacije), s jednog mjesta kako bi se imala mogudnost donošenja ispravnih odluka kod dodjele
resursa aplikacijama i obezbjeđenju nivoa servisa korisniku.
1.1.1.2. Informacije
Softver u komponenti „informacija“ sistemu treba omoguditi sljedede:
Iskorištenje informacija u punom opsegu na način da su dostupne svima kojima su potrebne
Poboljšanja kvaliteta informacija a time i vrijednosti koje one donose organizaciji
Isporučivanju trenutnih, pouzdanih informacija onima kojima su potrebne za obavljanje njihovog posla
Zbog potreba da se zadovolje zahtjevi koje postavljaju različiti autoriteti s kojima de se razmjenjivati
određene informacije i na određen način, komponenta arhitekture koja se odnosi na informacije
mora biti posebno naglašena, i to iz više razloga. Neki od razloga su povedanje količine informacija
tokom vremena i direktna interakcija između učesnika u razmjeni informacija.Tako se dolazi do
zahtjeva koji se odnose na kvalitet informacija, kontrolu pristupa do informacija, mogudnost analize i
izvještavanja na bazi informacija i sl.
Potrebno je predvidjeti visoku dostupnost, raspoloživost, skalabilnost, te povjerljivost, zaštitu i
integritet podataka uz potreban nivo interoperabilnosti.
1.1.1.3. Servisno orijentirana, događajima upravljana infrastruktura
Softver u komponenti servisno orijentirane, događajima upravljane infrastrukture (Service Oriented
Event Driven Application Infrastucture) treba obezbijediti:
Izgradnju zajedničkih intra- i inter- poslovnih procesa kojima de se optimizirati poslovni tokovi
Odgovor na sve poslovne promjene činedi fleksibilnu aplikaciju
Mogudnost konzumacije podataka od strane klijenta bez obzira na izvorni kod jedinstvene
knjige štetnika uz transparentan, standardiziran i jasno definisan interfejs
Sistem treba što efikasnije i pouzdanije omoguditi informacije potrebne za poslovanje i treba
posjedovati mogudnost kreiranja i upravljanja fleksibilnih procesa koji de se koristiti unutar cijele
organizacije i izvan nje, za potrebe razmjene informacija s okruženjem.
Komponente servisno orijentirane, događajima upravljane infrastrukture su u mogudnosti odgovoriti
na ovakve izazove jer posjeduju generičke komponente softvera sa maksimalno prilagodljivim
poslovnim procesima i informacijama kritičnim za poslovanja unutar i izvan organizacije.
Dodatno, za integraciju sa ostalim sistemima u okruženju i komunikaciju sa njima, potrebno je
osigurati zajedničku komponentu zasnovanu na standardima, i sa podrškom više protokola za
razmjenu poruka baziranih na web servisima.
Za potrebe nadzora i upravljanja poslovnih procesa potrebno je obezbijediti mehanizme kojima se
mogu definirati i kontrolirati poslovni procesi – Business Rules Engine, upravljati događajima - Event
Management i mogu vršiti analize i izvještavanja rezultata poslovanja - Business Activity Monitoring.
Zajedno sa ovim treba omoguditi Identity Management kao integriranu komponentu koja de
obezbijediti robusno i sveobuhvatno upravljanje identitetima korisnika sistema, i to: Access
Management – za kontrolu pristupa, s omogudenim samouslužnim servisom administracije korisnika,
uz podršku LDAP directory servisa, sinhronizacije sa ostalim tipovima direktorija i upravljanja web
servisima.
Za potrebe uspješnog upravljanja ovakvim okruženjem treba predvidjeti komponentu kojom se mogu
nadgledati poslovni process, partnerski linkovi (linkovi prema društvima za osiguranje, različitim
autoritetima sa kojima se vrši razmjena informacija) i eventualne greške i zastoji u izvršenju procesa.
1.1.1.4. Razvojno okruženje
Softver u komponenti razvojnog okruženja treba omoguditi visoko produktivno okruženje za brzi
razvoj, efikasno korištenje i lako održavanje komponenti aplikacija. Kad se pomene razvoj onda se
podrazumjeva, kako horizontalno širenje nadopunjavanjem novim modulima, tako i vertikalno
povezivanje sa drugim autoritetima i/ili udaljenim lokacijama.
Razvojno okruženje treba da se sastoji od skupa visoko produktivnih alata za razvoj aplikacija, baze
podataka i alata za poslovno izvještavanje – Business Intelligence kojima je mogude podržati razvoj i
tehnološku platformu na kojoj se on izvodi.
Osnovni dio aplikacije treba da je otvoren i dostupan kroz razvojno okruženje koje treba omoguditi
dio razvoja na bazi podataka sa SQL, XML treba da je dostupan kao standardni SQL kao i ostale
opštedostupne programske jezike.
Potrebno je predvidjeti što je mogude više razvojnih alata otvorenog koda dostupnih za odabranu
razvojnu platformu.
1.1.1.5. Nadzor i upravljanje sistemom i aplikacijama
Softver u komponenti upravljanja treba omoguditi aktivno upravljanje širokim sistemom i pružiti
automatski odziv kako bi se održao kvalitetan nivo servisa IT sistema.
1.2. Tehničke specifikacije jedinstvene knjige štetnika
Sistem treba činiti centralna aplikacija integrisana sa sistemima u centralama osiguravajudih kuda. Sva
komunikacija sa centralnom aplikacijom mora biti kriptovana i pružati zaštitu od Man in the Middle
napada. Autorizacioni sistem treba sadržavati mehanizam zaštite od brute force napada na korisničke
račune.
Server baze podataka
Aplikacija
Interfejsi
Elektronska razmjena podataka
Centrale društava za osiguranje
Agenti
Treće strane/autoriteti
Aplikacija
WEB aplikacija (WEB, SMS, GPRS/EDGE/UMTS
Modul administracije
Modul za upravljanje podacima
Modul za napredno izvještavanje
Ilustracija 3 - koncept tehničke specifikacije jedinstvene knjige štetnika
1.2.1. Centralna baza podataka
Centralna baza podataka treba da bude projektovana tako da može sakupljati podatke o štetnicima,
policama osiguranja i štetama. Struktura treba da bude pogodna za pretraživanje podataka potrebnih
za određivanje bonusa i malusa prilikom pravljenja nove police osiguranja.
U bazi je potrebno držati i podatke o korisnicima koji imaju pristup zajedno sa jednosmjernom
enkripcijom zaštidenom šifrom korisnika.
Pristup bazi podataka mora biti omoguden samo aplikacijama koje služe kao interfejs prema
korisnicima. Direktni pristup izvana mora biti zabranjen.
Struktura baze mora podržavati funkcionalnost bilježenja historije svih promjena nad slogovima
zajedno sa vremenom i korisnikom koji je izmjene napravio, i strukturu zapisivanja svih važnih akcija
na ostalim nivoima aplikacije zajedno sa korisničkim imenom i vremenom poduzimanja akcije.
1.2.2. Web aplikacija za upravljanje podacima
Web aplikacija za upravljanje podataka mora omogudavati korisnicima iz osiguravajudih kuda
pretragu, pregled i modifikovanje svih podataka, napredne prilagodljive izvještaje i administraciju
korisnicima, te bilježiti pristup sistemu kroz upis u log koji sadrži pored opisa akcije, ime korisnika, tip
akcije (radi lakšeg pretraživanja).
Web aplikacija mora podržati sljedede uloge korisnika:
Globalni administrator
o Može podešavati sistem i dodavati sve vrste korisnika, pregledati log.
Lokalni administrator
o Može podešavati sistem za osiguravajudu kudu kojoj pripada, pregledati podskup loga
za osiguravajudu kudu, dodavati manje privilegovane korisnike za svoju osiguravajudu
kudu.
Agent
o Pripada osiguravajudoj kudi
o Može pristupiti podskupu informacija dovoljnom da se odrede uslovi izdavanja nove
police.
o Može slati upite SMS-om
Operater
o Pripada osiguravajudoj kudi
o Može sve što i Agent, a dodatno modifikovati, pregledati i pretraživati podatke za
svoju osiguravajudu kudu
o Može vršiti grupni upload podataka o policama, štetnicima i štetama za određeni
period kroz web interfejs.
Statistika
o Može pristupati modulu naprednih izvještaja.
Elektronski pristup za osiguravajude kude
o Može pristupati web servisima za osiguravajude kude
Elektronski pristup za trede strane
o Može pristupati web servisima namijenjenim tredim stranama
1.2.2.1. Modul za administraciju
Modul za administraciju treba da podrži dodavanje, onemogudavanje pristupa i izmjenu korisničkih
podataka za globalnog administratora kao i lokalne administratore na nivou osiguravajudih kuda. U
njemu se treba nalaziti i interfejs za podešavanja sistema kao i izmjenu šifrarnika koji postoje u
sistemu, dodavanje i modifikaciju podataka o osiguravajudim kudama itd..
U ovom modulu administratorima treba omoguditi i pregled i pretraživanje log-a akcija koje su
vezane za nivo administriranja (globalni administrator treba imati pristup cijelom logu, lokalni
administrator samo akcijama vezanim za podatke osiguravajude kude kojoj pripada)
1.2.2.2. Modul za upravljanje podacima
Omogudava korisnicima iz osiguravajudih kuda pretragu, pregled i modifikovanje svih podataka,
Potrebno je pratiti historiju promjena za svaki slog i spriječiti mogudnost trajnog gubljenja podataka.
Osim modifikacije postojedih podataka, korisniku treba omoguditi da izvrši grupni upload podataka o
štetnicima, policama i štetama.
Podrška za slanje podataka mora raditi validaciju poslanih podataka te odbiti upis ukoliko podaci nisu
prošli validaciju. Korisnik mora biti detaljno obaviješten o greški kako bi grešku mogao ispraviti.
1.2.2.3. Modul za napredno izvještavanje
Prema zahtjevima osiguravajudih kuda i tredih strana potrebno je pripremiti izvještaje i omoguditi
pristup njima.
1.2.3. Interfejsi za elektronsku razmjenu podataka
Interfejsi za elektronsku razmjenu podataka trebaju predstavljati skalabilnu platformu koja de prije
svega omoguditi tri posebna, transparenta i standardizirana interfejsa:
- Interfejs za komunikaciju prema agentima
- Interfejs za komunikaciju sa centralama osiguravajudih kuda
- Interfejs za komunikaciju sa tredim stranama/autoritetima
Potrebno je predvidjeti širenje ovih interfejsa, posebno pazedi na zakonsku regulativu, a najviše na
Zakon o zaštiti ličnih podataka. Ukoliko se ukaže opravdan zahtjev za proširenje broja interfejsa ili
karakteristika njegovog tipa
1.2.3.1. Interfejs za komunikaciju prema agentima
Softver treba omoguditi slanje informacija dovoljnih da se odrede uslovi izdavanja nove police kao
odgovor na upit slanjem SMS poruke sa broja upisanom u korisničkim podacima.
Svaki zahtjev se sa vremenom i korisnikom mora zapisati u log.
1.2.3.2. Interfejs za komunikaciju sa centralama osiguravajudih kuda
Softver korištenjem SOAP Web servisa mora omogudavati slanje jednog ili više podataka o
štetnicima, policama i štetama kao i dohvatanje podataka za osiguravajudu kudu. Web servis mora
vršiti validaciju te informisati klijentsku aplikaciju o greškama koje su se desile. Aplikacija se mora
autenticirati prije korištenja servisa računom sa ulogom “Elektronski pristup za osiguravajude kude”.
1.2.3.3. Interfejs za komunikaciju sa tredim stranama/autoritetima
Softver korištenjem SOAP Web servisa mora omogudavati preuzimanje dogovorenih podataka nakon
autenticiranja računom sa ulogom “Elektronski pristup za trede strane/autoritete”.
1.3. Logika rada i tok podataka
Prikupljanje podataka se treba vršiti putem unosa (importa) podataka sa police i unosa (importa)
štetnika. Ova dva importa trebaju logički biti odvojena i mogu se odvijati neovisno. Distribuciju
podataka treba vršiti putem više kanala i s ciljem da budu uvijek i svugdje dostupni.
1.3.1. Import podataka polica
Prva faza toka podataka jeste import u bazu ili akvizicija podataka. Pravilo je da svaki Korisnik koji se
logira na sistem može importovati podatke samo svog Društva. Ovo se odnosi i na import podataka
sa polica i na import štetnika. Import polica se ne može vršiti ukoliko podaci nisu homogeni u smislu
porijekla od strane društa za osiguranje koje importuje podatke. Dakle, društvo je dužno dostaviti
validne podatke, u protivnom podaci moraju biti odbijeni . Import podataka se treba vršiti na više
načina. Jedan način je dostavljanje podataka u XML file-u koji bi se importovao u bazu kroz aplikaciju.
Struktura XML datoteke bi bila jasno definisana i sve XML datoteke se moraju uklapiti u XML šemu
koja bi bila predložena/dostavljena od strane sistema svim društvima. XML datoteka treba biti
organizovana tako da je čitljiva bazi i import podataka iz njega bi se odvijao brzo, jednostavno i
korisnički transparentno.
Također, mogude je predložiti klijentsku desktop aplikaciju, ili WEB modul unutar aplikacije
jedinstvene knjige štetnika koja bi mogla da provjeri XML datoteku koju treba poslati. Sama WEB
aplikacija mora sadržati kontrolni mehanizam upozorenja korisnika.
Drugi način bi bio slanje strukturirane datoteke (npr. CSV), gdje bi se poštovala identična procedura
kao i kod XML datoteke. Ukoliko bi došlo do greške prilikom importa, neophodno je implementirati
log sistem za detekciju greške i upozoravanje korisnika, gdje bi se detektovale i upisale sve ispravne i
neispravne akcije nad sistemom.
Tredi način importa podataka bi bio import iz Excel datoteke. Excel datoteka treba biti jasno
definisana (tačan naziv sheet-a, kolona, struktura redova itd.) i import bi se odvijao po logici
specificiranoj u prva dva slučaja.
U sistemu je neophodno implementirati dodatne mehanizme kontrole (provjera broja polica,
popunjenost obaveznih polja, odgovarajuda polja pripadaju odgovarajudem osiguravajudem
društvu...) koji de korisnika izvještavati o mogudem problemu, uspjehu importa i slično.
1.3.2. Import podataka štetnika
Po sličnoj logici importa kao i kod importa podataka polica postupilo bi se i pri importu podataka
štetnika. Implementacija kontrolnih mehanizama za provjeru ispravnosti importa, bilježenje i
izvještavanje za svaku akciju nad sistemom je obavezna. Potrebno je omoguditi kvalitetan
mehanizam podešavanja kriterija provjere importa od strane Udruženja društava za osiguranje FBiH.
1.3.3. Distribucija podataka
Mehanizme distribucije podataka potrebno je obezbijediti preko više kanala. Svaki kanal
podrazumijeva kvalitetno definisanu i implementiranu autorizacionu politiku.
WEB aplikacija - dostupna korištenjem WEB tehnologija
WEB servisi – interfejs namijenjen za automatsko uvezivanje sistema društava za osiguranje,
Udruženja i drugih autoriziranih...
SMS interackija – jednostavnim, predefinisanim SMS upitima je potrebno poslati odgovor
korisniku sa tačnom informacijom iz baze (u smislu JMB:xxxxx dati odgovor iz baze o štetniku
sa JMB-om xxxx i sl.). Omoguditi jednostavne i jasno predefinisane SMS inserte koji
autoriziranom licu omogudavaju da sudjeluje u dopunjavanju baze. Sve to implicira da de
sistem morati posjedovati vlastiti, sigurnan i transparentan SMS protokol za rad nad
sistemom sa implementiranim mehanizmima detekcije greške.
Sarajevo, februara-veljače 2010. godine Odbor za informatiku
2. Sadržaj
1. INFORMATIČKO RJEŠENJE JEDINSTVENE BAZE ŠTETNIKA – PROJEKTNI ZADATAK ......................... 1
1.1. Okvir projekta .......................................................................................................................... 2
1.1.1. Osnovni principi i koncepti informacionog sistema ........................................................ 2
1.2. Tehničke specifikacije jedinstvene knjige štetnika .................................................................. 6
1.2.1. Centralna baza podataka ................................................................................................. 7
1.2.2. Web aplikacija za upravljanje podacima ......................................................................... 7
1.2.3. Interfejsi za elektronsku razmjenu podataka .................................................................. 8
1.3. Logika rada i tok podataka ...................................................................................................... 9
1.3.1. Import podataka polica ................................................................................................... 9
1.3.2. Import podataka štetnika .............................................................................................. 10
1.3.3. Distribucija podataka ..................................................................................................... 10
2. Sadržaj ........................................................................................................................................... 11