1
Tehnične zahteve za
aplikacijo URBAR
2
Kazalo 1.1 Interakcije in reference ............................................................................................ 3
1.2 Avtomatski prevzem sprememb podatkov iz zunanjih podatkovnih baz ................... 4
1.3 Migracija podatkov .................................................................................................. 5
1.3.1 Obstoječe stanje .............................................................................................. 5
1.3.2 Varnost............................................................................................................. 7
1.4 Tehnične zahteve .................................................................................................... 7
1.5 Projektno vodenje in metodologija razvoja programske opreme ............................11
1.6 Obremenitveni test in optimizacija ..........................................................................11
1.7 Spisek poslovnih procesov .....................................................................................11
3
1.1 Interakcije in reference
Področje zakupa kmetijskih zemljišč oz. zadevnega projekta je v tesni povezavi z drugimi
dejavnostmi Sklada in programskimi rešitvami, ki jih podpirajo. V spodnji tabeli je seznam
aplikacij iz katerih bo aplikacija pridobivala podatke. Navedeni so tudi nabori podatkov, ki jih
pridobiva aplikacija iz teh aplikacij. Ponudnik mora na baznem nivoju (bazni paketi,
procedure) pripravit vmesnik za uvoz podatkov. Informacije za pripravo vmesnikov do
podatkov bo dobil na SKZG.
Naziv Opis
ROS Evidenca zemljišč v upravljanju Sklada. Pri EZP je ta evidenca pomembna,
ker opredeljuje zemljišča v upravljanju Sklada. Informacija o lastništvu iz te
PB ima prednost pred lastniškim statusom PIS.
Primer ROS podatkov:
PIGS Parcele v interesu gozdarskega sektorja Sklada. Je vsebinsko sorodna
rešitev za področje gozdarstva. Za EZP je pomembna v segmentu, kjer se
lahko prekrivata zakup in koncesije za gospodarjenje z gozdovi. Ko bodo
tudi gozdne parcele oz. njeni deli opredeljeni s poligoni, bo izvedena tudi
interakcija s poligoni zemljišč v zakupu.
Ponudbe ZKZ Programska rešitev za pripravo ponudb za zakup kmetijskih zemljišč, ki
predstavlja enega od vhodnih virov za pripravo zakupnih pogodb.
FIS Programska rešitev za podporo finančnega sektorja Sklada s katero si EZP
izmenjuje podatke o strankah, fakturah in nekaterih drugih dogodkih, ki so
vezani na zakupno pogodbo.
Soglasja in
Služnosti
Aplikacija za pripravo služnostnih pogodb in pogodb o soglasjih, ki so v
pretežnem delu vezana tudi na podatke o zakupu KZ.
Coprnik Program za analizo podatkov o »velikih« (pogodbe, ki vključujejo veliko
število zemljiških parcel) zakupnih pogodbah, ki na podlagi vrste zgoraj
navedenih podatkov (podrobneje opisan v dokumentaciji).
PorTab Cross-over programska rešitev, ki agregira in analizira podatke o delu
kmetijskega sektorja na več ravneh (osnovna raven agregiranja podatkov je
katastrska občina). Med drugimi tako zajema tudi podatke o zakupu (število,
4
pogodb, število zemljiških parcel, površina v zakupu in zakupnina).
Pregledovalniki
EZP
Vrsta spletnih pregledovalnikov podatkov o zakupu KZ.
1.2 Avtomatski prevzem sprememb podatkov iz zunanjih podatkovnih baz
SKZG (parcele Sklada)
o Dnevno osveževanje prostorskega sloja »parcele Sklada« preko internega
spletnega servisa ROS-a
GURS (zemljiški kataster, KO, PARCELE, RPE(UE, OB, NA, UL, HS, RASTRI)
o Dostop preko WFS servisov (tedenski prenos)
o Ponudnik naj pripravi rešitev za tedenski prepis atributnih in grafičnih
sprememb KO, PARCELE, RPE
o Ponudnik implementira algoritem avtomatskega primerjanja sprememb
katastrskih podatkov v primerjavi s slojem dejanske rabe(MKGP), GERK-i
(MKGP), zakupnimi poligoni(SKZG)
o Izvajalec implementira algoritem avtomatskega ažuriranja podatkov na
dokumentih glede na spremembo katastra
o Merilo: Spremembe min 10000 parcel na uro
MKGP (dejanska raba, GERK-i)
o Dostop s pomočjo dblink-a (tedenski prenos)
o Ponudnik implementira algoritem avtomatskega primerjanja sprememb
katastrskih podatkov v primerjavi s slojem dejanske rabe(MKGP), GERK-i
(MKGP), zakupnimi poligoni(SKZG)
o Izvajalec implementira algoritem avtomatskega ažuriranja podatkov na
dokumentih glede na spremembo katastra
o Merilo: Spremembe min 10000 parcel na uro
ARSO (nvatlas)
o Priprava spletnega servisa za prepis slojev
o Naročnik bo sam nastavljal frekvenco ažuriranja podatkov – cca. enkrat na tri
mesece
ZGS (gozdna maska / odseki-oddelki)
o Priprava spletnega servisa za prepis slojev
o Naročnik bo sam nastavljal frekvenco ažuriranja podatkov – cca. enkrat letno
Sistem prevzemanja/repliciranja podatkov preko spletnih servisov mora biti zasnovan tako,
da lahko naročnik sam po potrebi dodaja nove servise.
5
1.3 Migracija podatkov
1.3.1 Obstoječe stanje
Prenos SHP datotek iz Kmetijska grafike
<SLOJ="Občine" DC="SHP" PTH="$SHP_ROOT$\ob.shp"
<SLOJ="Upravne enote" DC="SHP" PTH="$SHP_ROOT$\ue.shp"
<SLOJ="Hišne številke" DC="SHP" PTH="$SHP_ROOT$\ehis.shp"
<SLOJ="Zakupne pogodbe" DC="SHP" PTH="$SHP_ROOT$\zakupne
pogodbe.shp"
<SLOJ="Deli KO" DC="SHP" PTH="$SHP_ROOT$\del_ko_gr.shp"
<SLOJ="GGE" DC="SHP" PTH="$SHP_ROOT$\gope00_GGE_region.shp"
<SLOJ="Odseki" DC="SHP" PTH="$SHP_ROOT$\SLOods_gm.shp"
<SLOJ="Dejanska raba" DC="SHP" PTH="$SHP_ROOT$\draba_gr.shp"
Prenos SDE slojev iz podatkovne baze
<SLOJ="Parcelne številke" DC="SDE"
PTH="webgis.webgis.par_del_gr_centroid.featureID.Points"
<SLOJ="Parcele sklada" DC="SDE"
PTH="webgis.webgis.par_del_gr.featureID.polygons"
<SLOJ="Parcelni deli" DC="SDE"
PTH="webgis.webgis.par_del_gr.featureID.polygons"
<SLOJ="M sloj" DC="SDE" PTH="webgis.webgis.msloj.featureID.polygons"
<SLOJ="Zakupni poligoni" DC="SDE"
PTH="webgis.webgis.f_zakpog.featureID.polygons"
<SLOJ="Soglasja" DC="SDE" PTH="webgis.webgis.soglasja.featureID.polygons"
<SLOJ="Parcelne številke" DC="SDE"
PTH="webgis.webgis.par_del_gr_centroid.featureID.Points"
6
<SLOJ="Izmera" DC="SDE" PTH="webgis.webgis.izmera.featureID.polygons"
theme="$THEME_SKZGRS$">
Struktura baze podatkov aplikacije EZP
Ocena količine podatkov EZP:
o 25 000 dokumentov (zakupne pogodbe, ponudbe, soglasja,…)
o 20 000 strank v povezavi z različnimi dokumenti
o 12 GB - Podatkovna baza EZP
Ocena količine podatkov kmetijske Grafike:
o 500 GB DOF posnetkov
o 7 GB rasterskih posnetkov
o 10 GB grafičnih slojev
Rešitev mora zagotoviti, da bo v fazi migracije rešen problem strank na obstoječih
dokumentih, ki ne obstajajo več v registru komitentov finančne aplikacije. Naročnik
mora imeti zagotovljen popoln vpogled na te dokumente.
7
1.3.2 Varnost
Uporabniki aplikacije in pravice
V program se vgradi evidenca delavcev Sklada oz. uporabnikov programa, ki se bo
poljubno polnila iz aktivnega imenika Skladove domene. Za vsakega uporabnika se
lahko določi pravice dostopa do podatkov in dokumentov glede na katastrske občine
(KO). Uporabniki, ki pripadajo neki izpostavi imajo pravico dela nad KO-ji, ki pripadajo
tej izpostavi.
Podatki o uporabniku programa:
Delavec + uporabniško ime Primer: Milena Trdan - kzg084
Tehnične zahteve modula za urejanje pravic uporabnika
Modul za urejanje pravic naj bo izveden ločeno od aplikacije, kot samostojna
aplikacija. Modul za urejanje pravic mora omogočati pregled in urejanje podatkov
naslednjih entitet: Sektorji, uporabniki, profili, pravice, profili_pravice,
uporabniki_pravice, uporabniki_profili, aplikacije, objekti, področje. Ponudnik mora
razviti bazne programske vmesnike za preverjanje pravic posameznega uporabnika,
ki morajo biti splošno uporabni za vse bodoče aplikacije na Skladu. Ti vmesniki
morajo biti uporabljeni tudi v tem modulu.
Prijava v aplikacijo
Aplikacija naj preverja identiteto uporabnika preko Microsoft aktivnega imenika
(avtentikacija uporabnika). Avtorizacijo dostopa do posameznega objekta aplikacije
pa naj se preverja preko baznega programskega vmesnika (glej predhodno poglavje).
Revizijska sled
Podatkovni model mora na nivoju baze zagotoviti beleženje vseh dogodkov (vpis,
izbris, sprememba). Vsaka zabeležka mora vsebovati informacije o tem kateri
uporabnik in kdaj je naredil spremembo.
Aplikacija naj omogoča tudi beleženje poizvedb nad baznimi tabelami. Nabor tabel
nad katerimi se izvajajo beleženje bo izbiral sam administrator sistema.
1.4 Tehnične zahteve
Arhitektura sistema mora biti spletna in več nivojska (podatkovna zbirka, aplikacijski
strežniki, spletni strežniki, spletni brskalniki). Aplikacija bo delovala v okviru državnega
omrežja HKOM.
Splošne zahteve:
Sistem mora biti zgrajen modularno. Predstavitveni nivo mora biti logično ločen od
poslovne logike.
8
Aplikacija mora do baze dostopati s prijavo na posebnega, namensko postavljenega
baznega uporabnika (»proxy aplikacijski uporabnik« …). Ta ima dodeljene pravice
(»Grant Execute«) za izvajanje samo tistih namensko spisanih baznih procedur in
funkcij, ki jih za svoje delovanje nujno potrebuje. Bazna procedura lahko opravlja tudi
druge funkcije, npr. preverjanje pravic izvajanja v varnostni shemi, ustvarjanje
revizijskih sledi, ...
Aplikacija do baze ne dostopa neposredno prek SQL poizvedb v tabelah, ampak prek
klicev baznih procedur. V nobenem primeru se na bazo ne sme prijavljati s povezavo
(bazno sejo), vzpostavljeno neposredno na shemo, ki je lastnik baznih objektov
(tabel, baznih procedur..).
Poslovna logika aplikacija mora biti implementirana v podatkovni bazi.
Ponudnik mora zagotoviti namestitvene pakete za vse aplikativne module in
razumljivo dokumentacijo za namestitev in nastavitev sistema v produkcijskem okolju.
Imamo 30 izpostav / hitrost povezav do izpostav = 1MB/ uporabnika (10
uporabnikov/izpostavo) + 50 uporabnikov na centrali. Vsi uporabniki sistema na
izpostavah so povezani s centralo Sklada preko HKOM omrežja.
sočasno max 100 uporabnikov (tudi grafika), v primeru nabave licenc je zahteva za
150 uporabnikov.
merilo odzivnosti aplikacije / čas priprave 1 velike zakupne pogodbe s 100 parcelami
= 20 sek
za dolgotrajne procese zagotoviti vmesno shranjevanje stanj na zahtevo uporabnika
in končno potrditev ob zaključku naloge/dokumenta/koraka v procesu
centralizirana postavitev podatkovnih in aplikacijskih strežnikov
uporaba obstoječe MS SQL baze s podporo Spatial operacijam v bazi podatkov
alternativna rešitev lahko temelji na podatkovni bazi Oracle 11g s podporo Spatial
operacijami v bazi podatkov s tem, da mora ponudnik v ponudbo vključiti dobavo
strošek vseh potrebnih licenc, namestitve in vzdrževanja
SKGZ sistemsko skrbi za platformo MS Server 2008, MS-SQL, IIS
V primeru, da ponudnik ponudi rešitve na drugačni sistemski programski opremi mora
v ponudbeno ceno vključiti tudi dobavo vseh potrebnih licenc, namestitve in
vzdrževanje te programske opreme za obdobje vzdrževanja
Programske vmesnike (na nivoju baze ali kot interna spletne storitve) za dostop do
podatkov drugih aplikacij mora razviti ponudnik
Rešitev lahko uporabi obstoječi ESRI ArcGIS strežnik s podporo z vsemi
odprtokodnimi standardi za izmenjavo GIS podatkov ali katerokoli drugo rešitev
(odprtokodna, licenčna), ki ima vsaj 50 namestitev v svetu
Ponudnik mora dobaviti ali razviti grafični pregledovalnik kot programski modul, ki ga
bo možno vključiti v katerokoli aplikativno rešitev. Dokumentirane morajo biti vse
funkcionalnosti modula in način vključitve modula tudi v druge aplikativne rešitve
razvite v .NET ali JAVA tehnologiji, ki niso predmet tega razpisa.
Vse rešitve razvite v okviru tega projekta (aplikativna programska oprema, dopolnitve,
nadgradnje odprto kodnih rešitev, sistemske nastavitve, …) mora izvajalec predati
popolno tehnično dokumentacijo in vso izvorno kodo razvite programske opreme.
Ponudnik mora predložiti standarde za poimenovanje in pisanje programske kode.
Aplikacija mora biti napisana v skladu s temi standardi.
9
Ponudnik mora pripraviti sistem poimenovanja objektov na bazi podatkov in na osnovi
tega sistema izdelati podatkovni model in ga predati v potrditev naročniku.
Komentarji v programski kodi morajo jasno opisovati namen kode na katero se
nanašajo.
Združljivost sistemske strojne opreme o Izbrani ponudnik bo imel na razpolago testno okolje, ki bo s prevzem
aplikacije prešlo v produkcijo možnost dela na strežnikih IBM serije x3650 in x3850 ali v VMware 4.0. virtualnem okolju.
o ponudnik mora sam poskrbeti za namestitev operacijskega sistema, baz podatkov in aplikativnih strežnikov v testno okolje
o namestitev OS-a in baz podatkov v testno okolje mora biti dokumentirana, nastavitev strežnikov bo revidiral in potrdil sistemski administrator SKGZ
o ponudnik bo imel možnost oddaljenega dostopa v okviru omrežja HKOM o prepis relevantnih produkcijskih podatkov v testno okolje izvede SKGZ na
osnovi dokumenta pripravljenega s strani ponudnika
Združljivost uporabniške programske opreme o na nivoju odjemalca mora rešitev delovati na spletnih brskalnikih IE Explorer 8
ali Mozila FireFox v 3.6
Združljivost sistemske programske opreme o na nivoju aplikacijskih strežnikov mora rešitev delovati na operacijskem
sistemu MS Windows Server 2008
Aplikacija mora zagotavljat avtomatski prenos zaključenega dokumenta SherePoint dokumentni sistem Sklada DOK/SPIS. DOK/SPIS pri vnosu zahteva naslednje podatke:
o Številko dokumenta o Datum nastanka dokumenta o Avtorja dokumenta o PDF dokumenta
Aplikacija:
Aplikacija mora biti razvita v .NET ali JAVA tehnologiji
Spletni moduli ne smejo uporabljati neobičajnih vtičnikov (angl. Plug-ins)
Pregledovalnik podatkov o parcelah – poizvedba v grafiki na posamezno parcelo –
prikaz vseh atributnih podatkov parcele in omogočen vpis dodatnih informacij (prosti
tekst iz šifranta). Ostale zahteve:
o Prikaz podatkov glede na parcelo ali odsek
o Prikaz podatkov povezanih s parcelo – specifikacija interface
o Specifikacija prikazovanja slik, dokumentov, …
o Prikazovanje podatkov glede na uporabnika (uporabniška pred nastavitev
pogleda/pregleda)
Izhodna datoteka dokumenta aplikacije naj bo v enem od standardnih formatov, ki jih
določi naročnik v fazi implementacije
10
Povezava z aplikacijo Uresk in registrom osnovnih sredstev (ROS)
o Vse spremembe na ROS-u ažurno odražajo v enotni evidenci podatkov
o Sprememba v ROS-u aktivira posamezne aktivnosti v drugih PP
Povezava z aplikacijo Gozdar – uporabljala bo grafični modul, ki bo razvit v okviru
tega razpisa. Pregledovalnik podatkov o parcelah mora prikazati tudi atribute
aplikacije Gozdar.
Grafični modul:
Velikost merila prikaza po posameznih slojih – prilagoditev glede na velikost izbrane
parcele/odseka/poligona.
Vsak posamezni uporabnik mora imeti možnost oblikovanja izpisa po vseh vsebinah
najmanj pa po velikosti, slojih, merilu, obliki, formatu.
Iskanje/Poizvedba v grafiki na posamezen odsek/oddelek
Predpriprava oblik (layout) tiskanja grafičnih slojev v standardnih v naprej določenih
velikosti (A1, A3, A4, za zakupne pogodbe,za aplikacijo Gozdar, …) ter možnost
izbire oblike s strani uporabnika. Formate se lahko naknadno spreminja.
Osnovne funkcionalnosti pregledovalnik naj bodo kot v področjih »Navigacija« in
»Orodja« v obstoječi kmetijski grafiki. Izbira Izmera bi se nadomestila z funkcijo
markiranja objekta (točka, linija poligon). Tako označen objekt je jasno viden ne glede
na merilo. Pregledovalnik naj ima možnost vključitve različnih slojev, ki jih uporabnik
po želji vklopi in izklopi.
Ponudnik mora dobaviti ali razviti samostojni grafični urejevalnik z identično
funkcionalnostjo kot jo ima obstoječi urejevalnik vendar naslednjimi razlikami:
o Branje seznama razpoložljivih grafičnih slojev iz Spatial podatkovne baze
odvisno od uporabniških pravic
o Možnost nastavitve odpiranja novih form na preddefiniranih funkcijskih
gumbih. Nastavitve se naj spreminjajo dinamično glede na to iz katere
aplikacije je bil odprt pregledovalnik tako, da je možno programsko nastaviti
katera atributna forma se odpre na klik funkcijskega gumba v kontekstu
izbranega aktivnega sloja. Če v grafiki spremenimo izbor objekta, se morajo v
skladu s tem prikazati v odprti atributni formi podatki za izbran objekt.
Možnost forme za prikaz atributnih podatkov, da se lahko pozicionira znotraj
pregledovalnika ali kot samostojno okno in se ta nastavitev shrani glede na
uporabnika.
o Iskalnik integriran v grafični urejevalnik mora biti tehnično odprt za dodajanje
dodatnih funkcionalnosti (vsebine) ta preko nastavitev v nastavitvenih tabelah
ali datotekah. Tako, da lahko poljuben izvajalec dodaja dodatno vsebino brez
posegov v grafični urejevalnik. Grafični urejevalnik mora imeti dokumentiran
API za komunikacijo z atributnimi aplikacijami. Možnost zunanje forme za
iskanje, da se lahko pozicionira znotraj pregledovalnika ali kot samostojno
okno in se ta nastavitev shrani glede na uporabnika.
o Za potrebe podpore poslovnega procesa usklajevanja stanja na terenu s
stanjem v evidenci in obratno je potrebno urediti uvoz/izvoz terenskih grafičnih
slojev (v standardnih izmenjevalnih formatih) – Nadomesti se M sloj iz opisa
obstoječih funkcionalnosti.
11
o Urejevalnik mora omogočati pripravo podatkov (preko čarovnika) za izvoz za
uporabo v GNSS napravah in obratno, podatke zajete z GNSS napravami
(preko čarovnika) prenesti na aktiven sloj v urejevalniku. Tehnične zahteve so:
omogočati izvoz/uvoz linije, točke in poligona iz/v prostorskega sloja.
1.5 Projektno vodenje in metodologija razvoja programske
opreme
Izvajalec mora navesti, kateri metodologiji projektnega vodenja in razvoja programske
opreme uporablja. Navesti mora kateri izdelki, poleg tistih, ki so eksplicitno navedeni v
okviru razpisa, bodo rezultat projekta in razvoja programske opreme.
Izvajalec mora imeti sistem za planiranje in spremljanje izvedbe posameznih opravil na
projektu, za prijavljanje napak in spremljanje njihove odprave. Izvajalec mora vzpostaviti
portal s projektno dokumentacijo, ki bo dostopen vsem udeležencem na projektu.
Izvajalec mora imeti razvoj programske opreme voditi tako, da razvojne izdelke hrani v
repozitoriju izvorne kode ter jih sproti testira. Obvladovati mora spremembe (repozitorij,
številčenje različic). Izvajalec je dolžan voditi evidenco ter vse spremembe ustrezno
označevati in dokumentirati tako, da je verzija jasno razvidna. Pravilo velja za spremembe
aplikacije, spremembe baznih objektov ter spremembe spremljajoče dokumentacije. O vseh
spremembah, ki jih izvajalec načrtuje, mora obveščati naročnika.
1.6 Obremenitveni test in optimizacija
Izvajalec je dolžan programsko kodo in bazne objekte optimizirati. Vse rešitve, ki se na
podlagi testiranja izkažejo kot neoptimalne, mora izvajalec odpraviti pred izročitvijo izdelka v
produkcijo. Enako velja tudi za vse posege v obdobju garancije in vzdrževanja.
Naročnik bo izvedel obremenitveni test s hkratnim izvajanjem najbolj zahtevnih procesov na
sistemu. Izvajalec je dolžan zagotoviti pri tem vso podporo. Uspešen izveden obremenitveni
test je pogoj za prehod v produkcijo.
1.7 Spisek poslovnih procesov
Poslovni proces - PP Status Aplikativna
programska
podpora - APO
Dokumentacija PP Dokumentacija
APO
Izjave in Sklepi Predmet
razpisa
Ne obstaja Ne obstaja Ne obstaja
Zakup kmetijskih zemljišč Predmet razpisa Obstaja Na voljo na vpogled – Opis
PPSklad -13.9 –
ZakupKmetijskihZemljišč z
dne 28.10.2008. Dokument bo
potrebno dopolniti glede na
aktualno stanje procesa.
Opisati bo potrebno povezavo
z finančno aplikacijo
Na voljo na vpogled -
Tehnična dokumentacija
EZP
12
Posredniške zakupne pogodbe Predmet razpisa Ne obstaja Ne obstaja Ne obstaja
Soglasja, služnosti ter stavbna
pravica Predmet razpisa Obstaja Na voljo na vpogled – Opis
PPSklad -13.8 –
SoglasjainSlužnosti z dne
3.11.2008. Dokument bo
potrebno dopolniti glede na
aktualno stanje procesa.
Opisati bo Stavbno pravico
Na voljo na vpogled -
Tehnična dokumentacija
Soglasja in služnosti
Gospodarje z gozdovi
Kontrola sečnje/gojitvenih del
Kontrola zaključenih delovišč
Kontrola desetletnega plana
Ni predmet
razpisa
Obstaja Na voljo na vpogled – Opis
PPSklad -13.9 –
GospodarjenejeZGozdovi z
dne 28.10.2008.
Na voljo na vpogled -
Tehnična dokumentacija
Gozdar
Register osnovnih sredstev Ni predmet
razpisa
Obstaja Na voljo na vpogled – Opis
PPSklad -13.1 –
VodenjeKnjigogodstvaZemljišč
z dne 28.10.2008.
Na voljo na vpogled -
Tehnična dokumentacija
Uresk
Finance in računovodstvo Ni predmet
razpisa
Obstaja - uvaja
se nova rešitev
Ni na voljo Na voljo na vpogled -
Recommended
