Izpitni centri ECDL ECDL (European Computer Driving License), ki ga v Sloveniji imenujemo evropsko računalniško spričevalo, je standardni program usposabljanja uporabnikov, ki da zaposlenim potrebno znanje za delo s standardnimi računalniškimi programi na informatiziranem delovnem mestu, delodajalcem pa pomeni dokazilo o usposobljenosti. V Evropi je za uvajanje, usposabljanje in nadzor izvajanja ECDL pooblaščena ustanova ECDL Fundation, v Sloveniji pa je kot član CEPIS (Council of European Professional Informatics) to pravico pridobilo Slovensko društvo INFORMATIKA. V državah Evropske unije so pri uvajanju ECDL močno angažirane srednje in visoke šole, aktivni pa so tudi različni vladni resorji. Posebno pomembno je, da velja spričevalo v 158 državah, ki so vključene v program ECDL. Doslej je bilo v svetu izdanih že več kot 8,5 milijonov indeksov, v Sloveniji več kot 12.700 in podeljenih več kot 7.800 spričeval. Za izpitne centre v Sloveniji je usposobljenih 23 organizacij, katerih logotipe objavljamo. McJ.J Ui VIZIJA RAZVOJA soi=-r IZOBRAŽeVANje INFORMAClJSKe STORITVE ICES /SKRATEL Inforrr sdjska tennckicija, d.o.o. INFORMACIJSKE TEHNOLOGIJE rj r^j f ^ #COPfV LJUDSKA UNIVERZA MURSKA SDBDTA VSEBINA UPORABNA I N F O R MATI 1 K A 2010 ©TEVILKA 3 JUL/AVG/SEP LETNIK XVIII ISSN 1318-1882 Uvodnik B Znanstveni prispevki Ana Saša, Marjan Krisper: Analitski vzorci za poslovno-informacijske arhitekture 129 B Pregledni znanstveni prispevki Gregor Polancic, Boštjan Sumak: Pregled in analiza programskih ogrodij in sorodnih tehnologij 144 Strokovni prispevki Antonela Divic Mihaljevic: Informacijska podpora poslovnih procesov zavarovalnice s predstavitvijo prilagojenega modela upravljanja znanja 155 Luka Babnik, Aleš Groznik: Vloga informatike pri izboljšanju procesa poslovnega planiranja 168 Peter Konda, Jure Peljhan: Primer uporabe podatkovnega rudarjenja v skupini NLB 175 Informacije Iz Islovarja 181 Koledar prireditev 185 UPORABNA INFORMATIKA 2010 ŠTEVILKA 3 JUL/AVG/SEP LETNIK XVIII ISSN 1318-1882 Ustanovitelj in izdajatelj Slovensko društvoINFORMATIKA Revija Uporabna informatika Vožarski pot 12, 1000 Ljubljana Predstavnik Niko Schlamberger Odgovorni urednik Jurij Jaklič Uredniški odbor Marko Bajec, Vesna Bosilj Vukšič, Gregor Hauc, Jurij Jaklič, Milton Jenkins, Andrej Kovačič, Katarina Puc, Vladislav Rajkovič, Heinrich Reinermann, Ivan Rozman, Rok Rupnik, Niko Schlamberger, John Taylor, Mirko Vintar, Tatjana Welzer Družovec Recenzenti Marko Bajec, Marko Bohanec, Vesna Bosilj Vukšič, Dušan Caf, Srečko Devjak, Tomaž Erjavec, Matjaž Gams, Izidor Golob, Tomaž Gornik, Janez Grad, Miro Gradišar, Jozsef Györkös, Marjan Heričko, Mojca Indihar Štemberger, Jurij Jaklič, Milton Jenkins, Andrej Kovačič, Jani Krašovec, Katarina Puc, Vladislav Rajkovič, Heinrich Reinermann, Ivan Rozman, Rok Rupnik, Niko Schlamberger, Tomaž Turk, Mirko Vintar, Tatjana Welzer Družovec, Lidija Zadnik Stirn, Alenka Žnidaršič Tehnična urednica Mira Turk Škraba Oblikovanje Bons Ilustracija na ovitku: Luka Umek za BONS Prelom in tisk Boex DTP d. o. o., Ljubljana Naklada 550 izvodov Naslov uredništva Slovensko društvo INFORMATIKA Uredništvo revije Uporabna informatika Vožarski pot 12, 1000 Ljubljana www.uporabna-informatika.si Revija izhaja četrtletno. Cena posamezne številke je 20,00 EUR. Letna naročnina za podjetja 85,00 EUR, za vsak nadaljni izvod 60,00 EUR, za posameznike 35,00 EUR, za študente in seniorje 15,00 EUR. V ceno je vključen DDV. Revijo sofinancira Javna agencija za knjigo RS. Revija Uporabna informatika je od številke 4/VII vključena v mednarodno bazo INSPEC. Revija Uporabna informatika je pod zaporedno številko 666 vpisana v razvid medijev, ki ga vodi Ministrstvo za kulturo. © Slovensko društvo INFORMATIKA Vabilo avtorjem V reviji Uporabna informatika objavljamo kakovostne izvirne članke domačih in tujih avtorjev z najširšega področja informatike v poslovanju podjetij, javni upravi in zasebnem življenju na znanstveni, strokovni in informativni ravni; še posebno spodbujamo objavo interdisciplinarnih člankov. Zato vabimo avtorje, da prispevke, ki ustrezajo omenjenim usmeritvam, pošljejo uredništvu revije po elektronski pošti na naslov ui@drustvo-informatika.si ali po pošti na naslov Slovensko društvo INFORMATIKA, Vožarski pot 12, 1000 Ljubljana. Avtorje prosimo, da pri pripravi prispevka upoštevajo navodila, objavljena v nadaljevanju. Za kakovost prispevkov skrbi mednarodni uredniški odbor. Članki so anonimno recen-zirani, o objavi pa na podlagi recenzij samostojno odloča uredniški odbor. Recenzenti lahko zahtevajo, da avtorji besedilo spremenijo v skladu s priporočili in da popravljeni članek ponovno prejmejo v pregled. Uredništvo pa lahko še pred recenzijo zavrne objavo prispevka, če njegova vsebina ne ustreza vsebinski usmeritvi revije ali če članek ne ustreza kriterijem za objavo v reviji. Pred objavo članka mora avtor podpisati izjavo o avtorstvu, s katero potrjuje originalnost članka in dovoljuje prenos materialnih avtorskih pravic. Nenaročenih prispevkov ne vračamo in ne honoriramo. Avtorji prejmejo enoletno naročnino na revijo Uporabna informatika, ki vključuje avtorski izvod revije in še nadaljnje tri zaporedne številke. S svojim prispevkom v reviji Uporabna informatika boste prispevali k širjenju znanja na področju informatike. Želimo si čim več prispevkov z raznoliko in zanimivo tematiko in se jih že vnaprej veselimo. Uredništvo revije Navodila avtorjem člankov Članke objavljamo praviloma v slovenščini, članke tujih avtorjev pa v angleščini. Besedilo naj bo jezikovno skrbno pripravljeno. Priporočamo zmernost pri uporabi tujk in -kjer je mogoče - njihovo zamenjavo s slovenskimi izrazi. V pomoč pri iskanju slovenskih ustreznic priporočamo uporabo spletnega terminološkega slovarja Slovenskega društva Informatika Islovar (www.islovar.org). Znanstveni članek naj obsega največ 40.000 znakov, strokovni članki do 30.000 znakov, obvestila in poročila pa do 8.000 znakov. Članek naj bo praviloma predložen v urejevalniku besedil Word (®.doc ali ®.docx) v enojnem razmaku, brez posebnih znakov ali poudarjenih črk. Za ločilom na koncu stavka napravite samo en prazen prostor, pri odstavkih ne uporabljajte zamika. Naslovu članka naj sledi za vsakega avtorja polno ime, ustanova, v kateri je zaposlen, naslov in elektronski naslov. Sledi naj povzetek v slovenščini v obsegu 8 do 10 vrstic in seznam od 5 do 8 ključnih besed, ki najbolje opredeljujejo vsebinski okvir članka. Pred povzetkom v angleščini naj bo še angleški prevod naslova, prav tako pa naj bodo dodane ključne besede v angleščini. Obratno pa velja v primeru predložitve članka v angleščini. Razdelki naj bodo naslovljeni in oštevilčeni z arabskimi številkami. Slike in tabele vključite v besedilo. Opremite jih z naslovom in oštevilčite z arabskimi številkami. Vsako sliko in tabelo razložite tudi v besedilu članka. Če v članku uporabljate slike ali tabele drugih avtorjev, navedite vir pod sliko oz. tabelo. Revijo tiskamo v črno-beli tehniki, zato barvne slike ali fotografije kot original niso primerne. Slik zaslonov ne objavljamo, razen če so nujno potrebne za razumevanje besedila. Slike, grafikoni, organizacijske sheme ipd. naj imajo belo podlago. Enačbe oštevilčite v oklepajih desno od enačbe. V besedilu se sklicujte na navedeno literaturo skladno s pravili sistema APA navajanja bibliografskih referenc, najpogosteje torej v obliki: (Novak & Kovač, 2008, str. 235). Na koncu članka navedite samo v članku uporabljeno literaturo in vire v enotnem seznamu po abecednem redu avtorjev, prav tako v skladu s pravili APA. Več o APA sistemu, katerega uporabo omogoča tudi urejevalnik besedil Word 2007, najdete na strani http://owl.english.purdue.edu/owl/resource/560/01/. Članku dodajte kratek življenjepis vsakega avtorja v obsegu do 8 vrstic, v katerem poudarite predvsem strokovne dosežke. Spoštovani bralke in bralci! Informatizacijo poslovanja danes razumemo kot uvajanje informacijske tehnologije v poslovanje, pri čemer tehnologija po eni strani omogoča, po drugi pa zahteva spremembe v načinu izvajanja poslovnih procesov, v poslovnih modelih, v menedžerskih pristopih idr. Vse z namenom povečevanja učinkovitosti in uspešnosti poslovanja. Zato se zdijo številne nove tehnologije, ki omogočajo tovrstne spremembe, zelo zanimive in vabljive. Pri tem pogosto pozabljamo na drugo stran te zgodbe, da uvajanje novih tehnologij tudi zahteva spremembe. Tu pa naletimo na razlog za pogosto neuspešne projekte informatizacije. Prepoznati moramo, da je eden od ključnih dejavnikov uspeha projektov prenove in informatizacije poslovanja realna ocena absorpcijske sposobnosti organizacije. Koliko in katere spremembe dejansko lahko uveljavimo? Ali smo res v polni meri sposobni izrabiti priložnosti, ki jih ponuja tehnologija? V kakšni meri lahko dejansko izboljšamo poslovne procese? To so vprašanja, ki si jih moramo zastaviti, ko razmišljamo o novih projektih. V tej številki najdete dva prispevka, ki predstavljata zanimive sodobne tehnologije s področja poslovne inteligence. Eden govori o informatizaciji poslovnega planiranja, drugi pa o podatkovnem rudarjenju. V obeh primerih so zgoraj omenjena razmišljanja gotovo relevantna. Podobno velja za prispevek, ki predstavlja primer uvajanja upravljanja znanja v poslovne procese zavarovalnice. Če se ukvarjate z menedžmentom informatike, boste zagotovo z zanimanjem prebrali prispevek o analitskih vzorcih po-slovno-informacijske arhitekture. Razvijalce pa bo pritegnil prispevek, ki pregledno prikazuje programska ogrodja. Želimo vam veliko zanimivega branja v tej številki in vas vabimo k novemu branju konec leta. Jurij Jaklič, odgovorni urednik "Največji izziv managementa predstavlja, kako uresničiti usklajeno poslovanje." (Frank Buytendijk, Performance Leadership) MEDNARODNA POSLOVNA KONFERENCA 20. in 21. OKTOBER 2010 kongresni center Hotela MÖNS v Ljubljani Program in prijava za udeležence: wvs^.process-conference.org ZNANSTVENI PRISPEVKI B Analitski vzorci za poslovno-informacijske arhitekture Ana Šaša, Marjan Krisper Univerza v Ljubljani, Fakulteta za računalništvo in informatiko, Tržaška 25, 1000 Ljubljana ana.sasa@fri.uni-lj.si; marjan.krisper@fri.uni-lj.si Izvleček Poslovno-informacijske arhitekture so se v poslovnih sistemih izkazale kot sredstvo za učinkovitejše uresničevanje vizije in ciljev ter za zagotavljanje zveznosti in skladnosti posameznih delov poslovnega sistema. Pomembno področje poslovno-informacijskih arhitektur je doseganje skladnosti poslovnega in informacijskega sistema ter celostno obvladovanje informatike. Arhitekturna analiza je pri tem ena izmed ključnih aktivnosti. Predstavlja temelj za doseganje koristi, ki jih lahko poslovni sistem pridobi s poslovno-informacijsko arhitekturo. Analitske arhitekturne tehnike so podlaga načrtovanju in odločanju in se uporabljajo za ocenjevanje različic arhitekture, za bolj informirane odločitve in študijo vpliva sprememb v poslovno-informacijski arhitekturi. V prispevku predstavljamo vlogo arhitekturne analize na področju poslovno-informacijskih arhitektur in ogrodje poslovno-informacijskih arhitektur ArchiMate, na katerem temelji naše delo. Podajamo pregled analitskih tehnik ogrodja ArchiMate in predstavljamo predlog razširitve tehnik z množico osnovnih analitskih vzorcev, ki se lahko uporabijo za ugotavljanje bolj in manj primernih struktur. Pri tem je poudarjena ustreznost aplikativne podpore poslovnim procesom in podatkovnim objektom. Ključne besede: poslovno-informacijska arhitektura, arhitekturna analiza, arhitekturni vzorec, poslovni proces, storitev. Abstract ANALYTICAL PATTERNS FOR ENTERPRISE ARCHITECTURES In business systems, enterprise architectures have become an important means of facilitating fulfilment of business vision and goals, and of ensuring coherence and consistency of different parts of the business system. Important application domains of enterprise architectures are business-IT alignment and holistic IT governance. In this context, architectural analysis plays a central role and is the basis for achieving the potential enterprise architecture benefits. Architectural analysis techniques are the foundation for planning and decision making using enterprise architectures, and are used especially for evaluation of different versions of an architecture for more informed decisions, and cause-effect analysis in enterprise architectures. In this paper, we present the role of architecture analysis in the field of enterprise architectures and introduce the ArchiMate framework, which is the basis for our work. We give an overview of the ArchiMate analysis techniques and present an enhancement of architecture analysis efforts with a set of basic analytical patterns for a discovery of more or less suitable structures. The focus is on information system support for business processes and business objects. Key words: enterprise architecture, architectural analysis, architectural pattern, business process, service. 1 UVOD formiranih odločitev o nekaterih ključnih tematikah, kot so Poslovno-informacijske arhitekture predstavljajo bazo zna- integracija informacijskih sistemov, povezovanje z zunanjimi nja poslovnega sistema, katere jedro zajema elemente no- poslovnimi in informacijskimi sistemi, optimizacija poslovnih tranjega in zunanjega okolja poslovnega sistema in povezave procesov, obvladovanje poslovnih sprememb in sprememb med njimi. Z naraščajočimi zahtevami po agilnosti poslovnih informatike itn. sistemov ter usklajenosti poslovnega sistema in informacij- Osnova za koristi, ki jih lahko pridobi poslovni skih sistemov so poslovno-informacijske arhitekture (angl. sistem s poslovno-informacijsko arhitekturo, je arhi-enterprise architectures) postale zelo pomembno področje, tekturna analiza. Različne tehnike arhitekturne ana-ki mu veliko pozornosti posvečajo strokovnjaki in razisko- lize so pomembne predvsem za podporo odločanju, valci tako s področja informatike kot iz poslovne domene. za načrtovanje in za optimizacijo arhitekture. Vedno Predstavljajo orodje za doseganje zveznosti in skladnosti po- ko je potrebna sprememba v poslovno-informacijski sameznih delov poslovnega sistema, povezanosti strateških arhitekturi, igra arhitekturna analiza pri tem osred-elementov s poslovnimi procesi, povezanosti poslanstva in njo vlogo. Analitske arhitekturne tehnike se uporab-poslovnih ciljev s cilji informatike ter za doseganje bolj in- ljajo za ocenjevanje različic arhitekture, za bolj infor- mirane odločitve pri sklepanju kompromisov, npr. med stroški, kvaliteto in učinkovitostjo, ter pri študiji vpliva sprememb v poslovno-informacijski arhitekturi [9]. Brez ustreznih analitskih tehnik poslov-no-informacijska arhitektura služi predvsem za predstavitve in za komunikacijo, medtem ko so teže realizirana druga področja uporabe in s tem tudi koristi, ki bi jih lahko pomenila le-ta. V prispevku podajamo predlog razširitve tehnik arhitekturne analize z množico osnovnih analitskih vzorcev, ki se lahko uporabijo za ugotavljanje bolj in manj ustreznih struktur v dani poslovno-informacij-ski arhitekturi. Pri tem je poudarek na ustreznosti aplikativne podpore poslovnim procesom in podatkovnim objektov ter na ponovni uporabi posameznih storitev in podatkovnih objektov. Obstoječe tehnike ne obsegajo tovrstnih analitskih vzorcev, kar analitikom otežuje pridobivanje pomembnih informacij o arhitekturnih rešitvah, ugotavljanje pomembnih lastnosti in odločanje. Vzorce lahko uporabimo kot podlago za opredelitev smernic, ki nam povedo, ali je obstoječa poslovno-informacijska arhitektura ustrezna, kaj bi lahko izboljšali, za ocenjevanje različnih ciljnih arhitektur in njihovo primerjavo. V predlogu analitskih vzorcev se osredinimo na arhitekturno analizo na podlagi ogrodja ArchiMate, saj gre za ogrodje, ki je usmerjeno k medsebojnim povezavam različnih arhitekturnih plasti. V prispevku se ne ukvarjamo z analitskimi tehnikami, ki se nanašajo samo na posamezno arhitekturno plast, saj se v ta namen lahko uporabljajo specializirane tehnike posameznih področij. 2 PREDSTAVITEV PODROČJA POSLOVNO-INFORMACIJSKIH ARHITEKTUR Konceptualna osnova področja arhitektur je bila postavljena leta 2000 s sprejetjem standarda IEEE 14712000 (IEEE Recommended Practice for Architectural Description of Software-Intensive Systems) [5]. Standard pomeni teoretično osnovo za definiranje, analizo in opis arhitekture sistemov, kot je informacijski sistem [11]. Standard podaja tole definicijo arhitekture sistema: Arhitektura je ključni sestav sistema, ki vključuje njegove komponente, njihove medsebojne povezave in povezave z okoljem ter načela, ki vodijo njeno načrtovanje in razvoj. (Standard IEEE 1471-2000, IEEE Computer Society, 2000 [5]) Na področju poslovno-informacijskih arhitektur še ne obstaja konsenz nad različnimi elementi in de- finicijami, zato standard IEEE 1471-2000 še vedno predstavlja pomemben temelj tudi na tem področju. Prav tako obstaja več bolj ali manj različnih definicij izraza poslovno-informacijska arhitektura (PIA). Med njimi podajamo definicijo, ki jo je opredelila organizacija The Open Group in je med bolj razširjenimi: Poslovno-informacijska arhitektura je formalen opis sistema ali podrobni plan sistema na nivoju komponent, ki usmerja njegovo implementacijo. Zajema strukturo komponent, njihovih medsebojnih povezav in načel ter smernic, ki vodijo njihovo načrtovanje in evolucijo skozi čas. (The Open Group, 2009 [15]) Poslovno-informacijska arhitektura je eden od ključnih dejavnikov za zagotavljanje dolgoročne uspešnosti poslovnega sistema in je še posebno pomembna v kompleksnih poslovnih sistemih. Uporablja se predvsem za tri ključne namene, in sicer: 1) kot osnova za predstavitve in komunikacijo: Poslovno-informacijska arhitektura daje celovit pogled na delovanje poslovnega sistema in njegovo sodelovanje navzven. Različni modeli, ki izhajajo iz poslovno-informacijske arhitekture, posameznim deležnikom predstavijo natančno točno tisti njen del, ki je zanje relevanten, in na način, ki ga umešča v celostni pogled na poslovni sistem. S tem so tudi podlaga za komunikacijo med različnimi deležniki; 2) kot osnova za načrtovanje: Poslovno-informacijska arhitektura lahko zajema opis obstoječega stanja ali želenega stanja. Pri tem lahko analiziramo različne variante in razhajanja med njimi - kaj je treba spremeniti, dodati, prilagoditi, da bi dosegli želeno stanje. Pri tem igrajo pomembno vlogo tehnike arhitekturne analize, npr. analiza vpliva sprememb; 3) za zagotavljanje skladnosti in zveznosti vseh delov poslovnega sistema: Poslovno-informacijska arhitektura omogoča zagotavljanje povezanosti poslanstva, vizije, poslovnih ciljev, poslovne strategije itn. s poslovnimi procesi in organizacijo. S tem so strategija in cilji posameznih delov poslovnega sistema usklajeni s strategijo in cilji celotnega poslovnega sistema, kar pomeni usmerjen fokus delovanja posameznih delov sistema pri uresničevanju strategije in poslanstva ter doseganju poslovnih ciljev in vizije. Nekatere ključne koristi uporabe poslovno-infor-macijskih arhitektur lahko povzamemo v naslednjih točkah: ■ poslovno-informacijska arhitektura daje celovit pogled na delovanje poslovnega sistema in njegovo sodelovanje navzven, ■ zagotavlja zveznost in skladnost posameznih delov poslovnega sistema ter usmerjen fokus delovanja različnih delov poslovnega sistema k doseganju poslovnih ciljev ter vizije, ■ zagotavlja povezanost poslanstva, vizije, poslovne strategije in poslovnih ciljev s poslovnimi procesi, z rezultati poslovnih procesov, z organizacijo poslovnega sistema, ■ strategija in cilji informatike so usklajeni s poslovno strategijo in s poslovnimi cilji, ■ je podlaga za optimizacijo poslovnih procesov, ■ omogoča analizo vpliva sprememb (npr. kako se nov poslovni cilj odraža v izvajanju poslovnih procesov, v informacijski podpori poslovnih procesov, v organizacijski strukturi itn.), ■ je podlaga za strateško planiranje tako poslovnega sistema kot njegovega informacijskega sistema, ■ je podpora za odločanje, ■ je sredstvo za komunikacijo in obvladovanje znanja v poslovnem sistemu, ■ je podlaga za zagotavljanje interoperabilnosti, ■ omogoča merjenje zmogljivosti in optimizacijo gradnikov arhitekture itn. Za doseganje večine izmed potencialnih koristi poslovno-informacijskih arhitektur igra arhitekturna analiza osrednjo vlogo. 2.1 Pregled pristopov k poslovno-informacijskim arhitekturam Najstarejše in med najbolj razširjenimi ogrodji po-slovno-informacijskih arhitektur je Zachmanovo ogrodje, ki izhaja iz leta 1987 [16]. Zachmanovo ogrodje je shema, ki omogoča klasifikacijo artefaktov poslovno-informacijskih arhitektur in opisuje različne poglede deležnikov na poslovni sistem v skladu z njihovi interesi. Jedro ogrodja je matrika dimenzije 6 x 6, ki identificira 36 pogledov na arhitekturo. Pri tem stolpci temeljijo na vprašalnicah: Kaj? Zakaj? Kdaj? Kdo? Kje? Zakaj? Vrstice temeljijo na konkretizaciji in predstavljajo različne zorne kote: identifikacija, opredelitev, predstavitev, specifikacija, konfiguracija in konkretizacija [17]. Drugi pomemben pristop, ki poslovno-informa-cijsko arhitekturo obravnava celostno, je TOGAF (The Open Group Architecture Framework). Razvija se pod okriljem organizacije The Open Group^ in zajema različne vidike, smernice, referenčne modele, metamodel in aktivnosti, ki so potrebni za zajem in vzdrževanje poslovno-informacijske arhitekture. Sestavljen je iz več delov, med katerimi jedro predstavlja arhitekturna metoda TOGAF ADM (Architecture Development Method). Pomembno razlikovanje med ogrodjem TOGAF in Zachmanovim ogrodjem je prav v metodi. Zachmanovo ogrodje namreč ne predpisuje, kako naj zajamemo ali vzdržujemo po-slovno-informacijsko arhitekturo, temveč omogoča klasifikacijo arhitekturnih artefaktov po poljubnem pristopu. Najnovejši pristop k poslovno-informacijskim arhitekturam je ArchiMate. Prav tako ga razvija organizacija The Open Group in zelo hitro pridobiva na pomenu. Podrobneje je predstavljen v razdelku 3 (Predstavitev ogrodja in analitskih tehnik ArchiMate). Druga pomembnejša in zelo razširjena pristopa sta še FEAF (Federal Enterprise Architecture Framework) [1] in Gartnerjevo ogrodje za poslovno-informacijske arhitekture [6]. V posameznih okoljih se pri uvedbi poslovno-informacijskih arhitektur bodisi uporabi enega izmed splošno namenskih pristopov bodisi se ga prilagodi za specifično okolje ali se razvije lasten pristop. 2.2 Zorni koti in pogledi Poslovno-informacijska arhitektura navadno opisuje veliko množico komponent in relacij med njimi. V poslovnem sistemu nastopajo različni akterji z različnimi vlogami. Ker se poslovno-informacijska arhitektura uporablja kot podlaga za predstavitve, komunikacijo, načrtovanje, analizo in odločanje, so posamezni modeli namenjeni različnim deležnikom z različnimi nalogami. Za vsakega izmed njih je relevanten le del poslovno-informacijske arhitekture. Modeli, ki bi vsebovali vse elemente in povezave med njimi, bi za posameznega deležnika vsebovali velik del informacij, ki so zanj nebistvene, postranskega pomena ali celo nepomembne. Poleg tega lahko na poslovno-informacijsko arhitekturo gledamo z različnih ravni podrobnosti. Za posameznega deležnika je ustrezna določena raven podrobnosti. To po- 1 The Open Group je organizacija, katere vizija je omogočanje na odprtih standardih in globalni interoperabilnosti temelječega dostopa do integriranih informacij znotraj in med poslovnimi sistemi. Je konzorcij, ki je neodvisen od ponudnikov rešitev. Njeni člani izhajajo iz vseh sektorjev skupnosti, povezanih z informacijsko tehnologijo - stranke, dobavitelji sistemov in rešitev, ponudniki orodij, integratorji, svetovalci, akademiki in raziskovalci. meni, naj bi modeli za posameznega deležnika vsebovali natanko tiste elemente, ki jih zanimajo, na ustrezni ravni podrobnosti. V ta namen večina pristopov poslovno-informacijskih arhitektur opredeljuje zorne kote in poglede glede na posamezne deležnike. Zorni kot (ali vidik; angl. viewpoint) določa, kateri tipi elementov in na kateri ravni podrobnosti naj bodo vsebovani v modelu, namenjenemu danemu deležniku. Na podlagi zornega kota in danega opisa poslovno-informacijske arhitekture dobimo pogled na nanjo, ki je ustrezen za danega deležnika. Pogled je predstavitev sistema glede na zanimanja določenega deležnika. 3 PREDSTAVITEV OGRODJA IN ANALITSKIH TEHNIK ARCHIMATE ArchiMate je najnovejši pristop k poslovno-informacij-skim arhitekturam. Del pristopa sestavlja jezik Archi-Mate, ki je bil kot tehnični standard sprejet v lanskem letu pri organizaciji The Open Group [13]. Ključni cilj ArchiMata je integracija arhitekturnih domen [9]. Zato ArchiMate določa enoten jezik za opisovanje strukture in delovanja poslovnih procesov, organizacijske strukture, informacijskih tokov, sistemov informacijske tehnologije in tehnične infrastrukture. Ključna motivacija je preseči razhajanja med različnimi arhitekturnimi domenami, ki navadno obstajajo v poslovnih sistemih, npr. med domenami poslovnih procesov, tehnične arhitekture in aplikativne arhitekture [14]. Elemente jezika ArchiMate lahko delimo v tri skupine, in sicer na aktivne strukturne elemente, elemente obnašanja in pasivne strukturne elemente (slika 1). Aktivni strukturni elementi so nosilci obnašanja, npr. poslovni akterji ali aplikativne komponente. Aktivnim strukturnim elementom so zato navadno dodeljeni elementi obnašanja, npr. določena funkcija je dodeljena poslovnemu akterju, ki je zadolžen za je dostopan s C dostopa S do realiziral OBJEKT je realizirana dostopa z do |je dostopan z | [dodeljen dodeljena uporablja sestavljen je uporabljena sestavlja uporabl^ je uporabljen s dodelje prožen/je nadaljevanje T dodeljen prožl/se nadaljuje v _'_ STRUKTURNI ELEMENT PASIVNA STRUKTURA OBNA©ANJE AKTIVNA STRUKTURA Slika 1: Metamodel ključnih elementov ArchiMate njeno izvajanje. Pasivni strukturni elementi so objekti, na katerih se izvaja obnašanje ali so pod vplivom elementov obnašanja, npr. poslovni objekt, ki je ažu-riran v poslovnem procesu. Pri ArchiMatu je pomembno tudi razlikovanje med notranjim in zunanjim pogledom na sistem (slika 1); npr. pri vidiku obnašanja načelo zunanjega in notranjega pogleda odraža storitveno usmerjenost. Koncept storitve v ogrodju ArchiMate igra osrednjo vlogo. Po ArchiMatu je storitev enota funkcionalnosti, ki jo dana entiteta (poslovni sistem, aplikativni sistem, organizacijska enota itn.) ponuja svojemu (zunanjemu ali notranjemu) okolju in ki eni ali več entitetam iz okolja predstavlja določeno vrednost [9] [12]. Storitve so lahko po naravi in po granularnosti zelo različne. Storitvena usmerjenost vodi v večplastni pogled na poslovno-informacijsko arhitekturo, pri čemer je storitev osrednja vez med različnimi plastmi. Archi-Mate ločuje med tremi arhitekturnimi plastmi [12], in sicer med poslovno, aplikativno in tehnološko plastjo. Vsako plast deli v dve ravni, in sicer: ■ na raven zunanjih storitev, ki obsega storitve, ki jih plast daje svojemu zunanjemu okolju in se uporabljajo na višjih arhitekturnih plasteh, in ■ na implementacijsko raven, ki vsebuje komponente in relacije med njimi ter storitve, ki se uporabljajo znotraj posamezne plasti (notranje storitve). Stranka Zunanja poslovna storitev Zunanja aplik. storltev Zunanja teh. storitev Poslovna plast Notranja posl. J, storitev J Aplikacijska plast f Notranja aplik. A storitev J Notranja teh. storitev Tehnološka plast TRA Slika 2: Večplastna arhitektura in koncept storitve [8] Implementacijska raven realizira storitveno raven. Slika 2 ponazarja posamezne plasti in njihovo povezovanje s konceptom storitve. Tabela 1 podaja legendo simbolov jezika, ki bodo uporabljeni v nadaljevanju prispevka. Tabela 1: Legenda uporabljenih simbolov jezika ArchiMate Simbol A -o Kratekop is Proces (Process) Zaporedje podprocesov oz. funkcij, ki vodijo do določenih rezultatov - izdelkov ali storitev. Storitev (Service) Navzven vidna enota funkcionalnosti, ki ima svoj pomen. Lahko gre za organizacijsko storitev (storitev, ki jo organizacija nudi svojemu okolju) ali aplikativno storitev (storitev, ki jo določen aplikativni sistem ponuja poslovnemu sistemu). Aplikativna komponenta (Application component) Modularni, zamenljivi del sistema, ki ponuja funkcionalnost prek vmesnikov. Z aplikativno komponento lahko predstavimo aplikativni sistem ali posamezne module aplikativnega sistema. Objekt (Object) Ločimo med dvema tipoma objektov: poslovni objekt predstavlja koncept, ki ima s poslovnega vidika določen pomen, podatkovni objekt pa predstavlja podatek ali množico podatkov, primerno za avtomatsko procesiranje -lahko je realizacija poslovnega objekta. Predstavitev (Representation) Predstavitev je zaznavna realizacija poslovnega objekta, npr. dokument v papirni obliki. Proženje (Triggering) Relacija med dvema entitetama obnašanja, npr. procesoma, ki pomeni, da konec prve entitete proži začetek druge. Realizacija (Realization) Relacija, ki prikazuje, kako so logične entitete, npr. storitve, realizirane z bolj oprijemljivimi entitetami, npr. z aplikativno komponento. Uporaba (Used-by) Relacija, ki prikazuje medsebojno uporabo gradnikov, npr. proces uporablja storitev. Dodelitev (Assignement) Relacija, ki se lahko uporablja za dodelitev določenega elementa obnašanja aplikativni komponenti ali funkciji. »e je npr. poslovni proces dodeljen aplikativni komponenti, to pomeni, da aplikativna komponenta avtomatizira proces. Dostop (Access) ..> Relacija, ki prikazuje, kako proces, funkcija, storitev ali dogodek dostopajo do poslovnega ali podatkovnega objekta. Agregacija (Aggregation) Relacija, ki kaže, da objekt združuje skupino drugih objektov. Kompozicija (Composition) Relacija, ki kaže, da je objekt sestavljen iz drugih objektov. 3.1 Obstoječe tehnike arhitekturne analize pristopa ArchiMate 3.1.1 Kvantitativna arhitekturna analiza Kvantitativna arhitekturna analiza se ukvarja s povezovanjem med različnimi elementi in plastmi po-slovno-informacijske arhitekture s kvantitativnega vidika. Uporablja se za optimizacijo s kvantificira-njem učinka različic načrtovalskih odločitev, za pridobitev meril, ki podpirajo analizo vpliva sprememb, in za planiranje kapacitet, npr. koliko ljudi mora sodelovati, da se proces izvede v roku. Cilj kvantitativne analize po ArchiMatu je določiti naslednja perfor-mančna merila: ■ delovna obremenitev (workload) ali Xa za vsak element poslovno-informacijske arhitekture (vozlišče). Če nobeden izmed virov ni preobremenjen, je prepustnost (throughput) vsakega vozlišča enaka njegovi delovni obremenitvi; ■ čas procesiranja Ta in odzivni čas Ra, za vsak element obnašanja; ■ uporaba Ur posameznega vira r. Izračun meril poteka na podlagi kvantitativnih vhodnih podatkov modela, in sicer (slika 3): ■ za vsako relacijo tipa e uporaba (Used-by) in dostop (Access) je podana utež n, ki predstavlja povprečje uporabe in dostopov; ■ za vsak element obnašanja a je podan storitveni čas Sa, ki predstavlja notranji čas, ki ga sistem porabi za realizacijo storitve (tj. čas procesiranja brez časa, ki ga sistem porabi za čakanje drugih uporabljenih storitev). Pri tem se predvideva, da storitev podeduje storitvene časovne vrednosti elementa, ki jo realizira; ■ za vsak vir r je podana kapaciteta Cr; ■ za vsako vozlišče a je podana frekvenca prihajanj fa. Navadno so frekvence prihajanj specificirane na vrhnji plasti modela, čeprav so lahko podane za poljubno vozlišče modela. Izračun meril poteka v treh korakih: 1. normalizacija vhodnega modela z uporabo transformacij modelov z namenom izdelave modela, ki je skladen s strukturo, predstavljeno na spodnji sliki (slika 3); 2. izračun delovnih obremenitev A od zgoraj navzdol (top-down); 3. izračun performančnih meril T, U in R na podlagi pristopa od spodaj navzgor (bottom-up). Storitvena raven storitev A f' S , R, T j J 0..1I Implementacijska raven f ■n = 1- objekt * ^—— 0..1 f' S notranje ^ obnašanje f' C ' R' T -n = 1 Storitvena raven f' S f storitev ^ ' R' T Slika 3: Osnovni koncepti kvantitativne arhitekturne analize po pristopu ArchiMate 3.1.2 Kvalitativna arhitekturna analiza ArchiMate loči med dvema tipoma kvalitativne arhitekturne analize (ali funkcionalne arhitekturne analize), in sicer med statičnim ali strukturnim tipom ter dinamičnim tipom ali tipom obnašanja. Pri statični analizi arhitektur se uporabljajo formalizmi opisne logike. Opisna logika in na njej temelječi jeziki za predstavitev znanja so prilagojeni za zajem znanja o konceptih in hierarhijah konceptov. Na področju poslovno-informacijskih arhitektur je najbolj pomembno področje uporabe opisne logike pri določanju vpliva spremembe na arhitekturo. Tehnike dinamične kvalitativne analize arhitektur temeljijo na formalnih pristopih, kot so npr. procesna algebra in omrežja podatkovnih tokov. Pri tem se lahko identificirajo suboptimalni deli arhitekture, ki se nanašajo na logične napake v arhitekturi, npr. dve sočasno aktivni vlogi, katerih aktivnosti so ne-kompatibilne (npr. prepisovanje, brisanje/uničevanje narejenega). Dinamična kvalitativna analiza pripomore k izboljševanju konsistentnosti in se osredini na logiko modelov. 4 ANALITSKI VZORCI POSLOVNO-INFORMACIJSKE ARHITEKTURE V razdelku podajamo predstavitev osnovnih vzorcev kvalitativne analize poslovno-informacijske arhitekture, ki smo jih razvili z namenom formalizacije ocenjevanja poslovno-informacijskih arhitektur. Na- našajo se na statične in dinamične vidike kvalitativne analize. Predstavljajo podlago za vizualizacijo različnih arhitekturnih struktur in za poizvedbe po neop-timalnih in drugih arhitekturnih strukturah. Poslovno-informacijske arhitekture podjetij in drugih poslovnih sistemov so navadno kompleksne in obsegajo veliko število elementov in relacij med njimi. Osrednji del informacijskih sistemov za po-slovno-informacijske arhitekture je navadno repozi-torij, ki vsebuje informacije o elementih, o njihovih atributih in medsebojnih povezavah med elementi. Pri uporabi tovrstnih sistemov smo ugotovili, da je eden izmed večjih problemov pri analiziranju po-slovno-informacijskih arhitektur v tem, da na voljo ni pristopa, ki bi opredeljeval, katere značilnosti po-slovno-informacijskih arhitektur bi bilo treba obravnavati, kakšne informacije nosijo ter kako te poiskati iz kompleksnih repozitorijev poslovno-informacij-skih arhitektur. Kljub temu da poslovno-informacij-ske arhitekture zajemajo koristne informacije, se zaradi pomanjkanja tovrstnih mehanizmov uporabniki srečujejo s številnimi problemi, kot so težave pri iskanju relevantnih informacij, ki bi koristile pri ocenjevanju obstoječe arhitekture, nepopolne informacije pri planiranju ciljne arhitekturne rešitve in težave pri primerjavi različnih potencialnih rešitev. Za zmanjšanje tovrstnih težav in omogočanje bolj informiranih odločitev ter argumentov pri analizi obstoječe in načrtovanju ciljne poslovno-informacijske arhitektu- re predlagamo uporabo analitskih vzorcev. V prispevku se osredinjamo na analizo podpore poslovnim procesom in poslovnim objektom s pomočjo poslovno-informacijskih arhitektur. Pristop smo razvili na podlagi izkušenj, pogostih praks in težav, v katerimi smo se srečevali na projektih v petih večjih slovenskih poslovnih sistemih. Cilj prispevka je predstaviti, kako lahko opredelimo karakteristike poslovno-informacijskih arhitektur, ki naslavljajo vidika podpore poslovnim procesom in poslovnim objektom, in omogočiti učinkovit način za njihovo prepoznavanje v kompleksnih repozitorijih poslov-no-informacijskih arhitektur. Za opredelitev teh karakteristik uporabljamo koncept vzorcev. Vzorec je abstrakcija od konkretnega, ki se pojavlja v določenih nepoljubnih kontekstih [10]. V danem prispevku izraz analitski vzorec pomeni množico elementov poslovno-informacijske arhitekture, ki odražajo arhitekturne strukture z določenim pomenom za analitika. Pri tem ne gre za klasične načrtovalske ali analitske vzorce, kot se pogosto uporabljajo v informatiki in računalništvu, saj niso namenjeni reševanju problemov z načrtovanjem aplikativnih sistemov ali s poslovnim modeliranjem [3][4]. Naš pristop temelji na odkrivanju vzorcev poslovno-informacijske arhitekture. Cilj je prepoznati vzorce, ki se pojavljajo v po-slovno-informacijski arhitekturi: ugotovljeni vzorci za dani element nosijo informacije, ki jih analitik lahko uporabi kot vhod za arhitekturno analizo. Informacije lahko uporabi za različne namene, npr. za ugotavljanje, ali trenutna rešitev podpira poslovne cilje in zahteve, za določanje prednosti in slabosti obstoječe poslovno-informacijske arhitekture in za ugotavljanje, ali je primerna z vidika podpore poslovnim procesom oz. jo je treba izboljšati. Posamezen vzorec v prispevku predstavljamo kot množico elementov, ki jo formaliziramo z nujnimi in zadostnimi pogoji pripadnosti množici (pogoji pripadnosti vzorca). Če določen element poslovno-informacijske arhitekture izpolnjuje pogoje pripadnosti vzorca, potem pravimo, da ustreza vzorcu ali da izkazuje vzorec. Zaradi kompleksnih množic elementov in njihovih medsebojnih povezav v poslovno-informacijski arhitekturi je bil eden izmed ciljev opredeliti vzorce na način, ki omogoča njihovo implementacijo v informacijskih sistemih za poslovno-informacijsko arhitekturo. Vzorci so formalno opredeljeni s pogoji pripadnosti, kar omogoča ne le uporabo tehnik za njihovo zaznavanje, temveč tudi njihovo implementacijo v orodjih za zajem in vzdrževanje poslovno-informa-cijskih arhitektur, ki podpirajo jezik ArchiMate in omogočajo uporabo skriptnega ali poizvedbenega jezika. Zadnje velja za večino obstoječih orodij, ki podpirajo ArchiMate, npr. za BiZZdesign Architect (BiZZdesign), ARIS ArchiMate Modeler (IDS Scheer AG) in IBM Rational System Architect (IBM). Podpora vzorcem v orodju za zajem in vzdrževanje poslov-no-informacijske arhitekture lahko služi za različne primere uporabe, npr. v obliki avtomatskih opozoril, če so zaznane neoptimalne strukture, ali v obliki podpore odločanju pri primerjavi različnih potencialnih ciljnih rešitev. V nadaljevanju so najprej podani simboli, ki se bodo uporabljali za opredelitev vzorcev, nato pa so opredeljeni analitski vzorci. Posamezen analitski vzorec je podan z opisom, pogoji pripadnosti in primerom v jeziku ArchiMate. 4.1 Opredelitev uporabljenih simbolov Tabela 2: Opredelitev uporabljenih simbolov BP Množica vseh poslovnih procesov BF Množica vseh poslovnih funkcij BI Množica vseh poslovnih interakcij BE Množica vseh poslovnih dogodkov BO Množica vseh poslovnih objektov DO Množica vseh podatkovnih objektov R Množica vseh predstavitev OS Množica vseh organizacijskih storitev AS Množica vseh aplikativnih storitev TS Množica vseh tehnoloških storitev AK Množica vseh aplikativnih komponent AnBP Množica analiziranih poslovnih procesov: AnBP: AnBP C BP AnBO Množica analiziranih poslovnih objektov: AnBO: AnBO C BO BBE Množica vseh elementov obnašanja: BBE = BP U BF U BI U BE X+ Tranzitivno zaprtje relacije X Opomba: Posamezne množice se nanašajo na elemente v dani poslovno-informacijski arhitekturi. Posamezne relacije, ki jih navajamo, vključujejo tudi tranzitivno izpeljane relacije. 4.2 Vzorci aplikativne podpore poslovnih procesov V arhitekturnem opisu v jeziku ArchiMate je podpora poslovnih procesov zajeta z relacijama uporaba in dodeljevanje. Z vidika avtomatiziranosti in podpore poslovnih procesov ločimo med naslednjimi vzorci aplikativne podpore poslovnih procesov: ■ vzorec avtomatiziranega poslovnega procesa: poslovni proces je dodeljen aplikativni komponenti, ki ga popolnoma avtomatizira; ■ vzorec delno avtomatiziranega poslovnega procesa: poslovni proces uporablja informacijski sistem, ki avtomatizira oz. podpira določene aktivnosti v procesu. Preostale aktivnosti izvajajo zaposleni v poslovnem sistemu; ■ vzorec aplikativno nepodprtega (neavtomatizira-nega) poslovnega procesa: poslovni proces nima podpore v informacijskem sistemu; ■ vzorec neaplikativno podprtega poslovnega procesa: poslovni proces izvajajo poslovni akterji brez aplikativne podpore; ■ vzorec (strogo) nepodprtega poslovnega procesa: poslovni proces nima ne aplikativne podpore niti ga ne izvaja poslovni akter. Gre lahko bodisi za procese, ki jih planiramo in aplikativna podpora ter odgovorne vloge še niso določene, ali za procese, ki jih opuščamo. Glede na raznolikost aplikativnih sistemov, ki lahko nastopajo v poslovnem procesu, ločimo dva vzorca aplikativne podpore poslovnega procesa: ■ vzorec heterogene aplikativne podpore poslovnega procesa: poslovni proces podpira več različnih aplikativnih sistemov; ■ vzorec homogene aplikativne podpore poslovnega procesa: poslovni proces podpira en aplikativni sistem. Ločimo tudi med različnimi vzorci aplikativne podpore posameznih procesnih aktivnosti. Ti v prispevku niso obravnavani. Določen poslovni proces lahko izkazuje več vzorcev. S pomočjo vzorcev aplikativne podpore poslovnih procesov lahko ugotavljamo stopnjo aplikativne podprtosti poslovnih procesov in njihovih podproce-sov. Glede na naravo procesnih aktivnosti lahko analitik informacije uporabi za presojo, ali je smiselno dvigniti stopnjo aplikativne podpore ali ne, ter kot podlago za nadaljnje analitske aktivnosti, kot npr. za analizo vpliva spremembe ob dvigu stopnje podpore. V nadaljevanju podrobneje predstavljamo nekatere izmed zgoraj navedenih vzorcev. Primeri, ki so podani za posamezne vzorce, se nanašajo na zorni kot aplikativne podpore analiziranih poslovnih procesov: vsebujejo analizirane poslovne procese, aplikativne storitve, ki jih uporabljajo ti procesi, aplikativne komponente, ki realizirajo storitve, ter vloge in aplikativne komponente, ki so jim dodeljeni procesi. Ne prikazujejo npr. drugih aplikativnih storitev, ki se ne uporabljajo v analiziranih procesih. Prav tako, razen relacij uporabe aplikativne storitve, dodelitve ter realizacije aplikativnih storitev ne prikazujejo drugih relacij med posameznimi elementi, četudi morda obstajajo v dani poslovno-informacijski arhitekturi. 4.2.1 Vzorec avtomatiziranih poslovnih procesov Vzorec naslavlja poslovne procese, ki so v celoti avtomatizirani in ne vsebujejo aktivnosti, ki jih izvajajo ljudje. Če je poslovni proces avtomatiziran, potem je dodeljen vsaj eni aplikativni komponenti. Naj funkcija SP(bp) dani poslovni proces bp G BP preslika v množico njegovih podelementov obnašanja: podprocesov, poslovnih funkcij, poslovnih dogodkov in poslovnih interakcij, ki so del poslovnega procesa bp: SP(bp) = {sp -| I sp E BBE : (bp, sp) E [composition]^ + v (bp, sp) E Aggregation'} (FD1) Avtomatizirane poslovne procese lahko opredelimo z naslednjo množico: [ABP] ^AnBP = {a -| | a E AnBP a ((Eb e AK: (b,a) e Assignment) v (Vsp e SP(a): 3ac E AK a (ac, sp) E Assignment))} (FD2) Slika 4 prikazuje primer pogleda aplikativne podpore analiziranega poslovnega procesa A, ki je po- polnoma avtomatiziran z aplikativno komponento AK1. 4.2.2 Vzorec delno avtomatiziranih poslovnih procesov Poslovni proces je delno avtomatiziran, če ni polno avtomatiziran (vzorec avtomatiziranih poslovnih procesov) in drži vsaj ena izmed naslednjih trditev: 1) poslovni proces uporablja vsaj eno aplikativno storitev, 2) vsaj eden izmed njegovih podelementov obnašanja je dodeljen aplikativni komponenti ali uporablja aplikativno storitev. Slika 4: Aplikativno podprt poslovni proces - popolna avtomatizacija [SABP] ^AnBP = {a ] | a e AnBP [ABP] ^AnBP a ((Eb e AS; (b,a) e UsedBy) v (Esp1 e SP(a), 3ac e AK : (ac, sp1) e Assignment) v (Esp2 e SP (a), Eas e AS : (as, sp2) e UsedBy))} (FD3) Slika 5 prikazuje primer pogleda aplikativne podpore poslovnega procesa A, ki je delno avtomatiziran z uporabo dveh aplikativnih storitev. rih uporabniki pri izvajanju procesa prehajajo med več različnimi aplikativnimi sistemi. Npr. pri izvedbi prvega dela procesa delajo s prvim aplikativnim sistemom, pri izvedbi drugega dela procesa z drugim aplikativnim sistemom in pri izvedbi tretjega dela procesa s tretjim. To med drugim pomeni tudi, da ni podprt tok poslovnega procesa. Gre za neoptimalno strukturo, ki lahko potencialno povzroča ozka grla in odvečno delo. Heterogena aplikativna podpora se nanaša tudi na avtomatizirane poslovne procese, ki so dodeljeni več kot eni aplikativni komponenti. Slika 5: Aplikativno podprt poslovni proces - delna avtomatizacija 4.2.3 Vzorec heterogene aplikativne podpore poslovnega procesa Poslovni proces s heterogeno aplikativno podporo je podprt z dvema različnima aplikativnima sistemoma ali več. Heterogena aplikativna podpora se nanaša na tiste delno avtomatizirane poslovne procese, pri kate- Poslovna plast | Poslovni proces B / / V J I Aplikativna plast ^ S . Aplikativna storitev AS2i \ - . . J k ; ^ ^ I^Pd Aplikativna komponenta AK^ A Aplikativna storitev ASSl -5- Aplikativna komponenta AK3 Slika 6: Heterogena aplikativna podpora poslovnega procesa Za nadaljnje opredelitve vzorcev opredelimo tri preslika v množico aplikativnih komponent, ki se funkcije: uporabljajo v procesu ali v njegovih podelementih ■ ACU(bp): funkcija, ki dani poslovni proces bp E BP obnašanja: ACU(bp) = {ac ] I ac E AK a (({ac, bp) E UsedBy) v (Esp e SP(bp) : (ac, sp) E UsedBy))} (FD4) ■ ACA(bp): funkcija, ki poslovni proces bp E BP preslika v množico aplikativnih komponent, katerim je dodeljen proces: ACA(bp) = {ac \ I ac E AK a {{ac, bp) E Assignment)} (FD5) ■ ACSPA(bp): funkcija, ki poslovni proces bp E BP preslika v množico aplikativnih komponent, ki so dodeljene podelementom obnašanja procesa bp: ACSPA(bp) = {ac -| | ac E AK a (Bsp E SP(bp): (ac, sp) E Assignment)} (FD6) Poslovne procese, ki so heterogeno aplikativno podprti, lahko opredelimo z naslednjo množico: [HeASBP] ^AnBP = {a ] \ a E AnBP a \ ACU (a) U ACA(fl) U ACSPA (a) \ a 2} (FD7) Primer pogleda aplikativne podpore poslovnega nemu procesu, uporablja tudi druge aplikativne procesa, ki kaže na heterogeno aplikativno podporo, sisteme, vendar je to z vidika uporabnika transpa-prikazuje slika 6. rentno. Avtomatizirani poslovni proces je vedno homogeno aplikativno podprt. Delno avtomatizira-4.2.4 Vzorec homogene aplikativne podpore poslovnega ni poslovni proces je homogeno aplikativno podprt, procesa če uporabniki pri izvajanju procesa uporabljajo en Poslovni proces s homogeno aplikativno podporo sam aplikativni sistem. Poslovne procese, ki so apli-je podprt z enim aplikativnim sistemom. Pri tem kativno homogeno podprti, opredelimo z množico: lahko aplikativni sistem, ki nudi podporo poslov- [HoASBP] ^AnBP = {a ] | a E AnBP a (| ACU (a) U ACA(fl) U ACSPA (a) | = 1)} (FD8) Primer pogleda aplikativne podpore poslovnega 4.3 Vzorci podpore poslovnih objektov procesa, ki kaže na homogeno aplikativno podporo, Z naraščajočimi količinami podatkov je pomembno, prikazujeta sliki 4 in 5. da so poslovni objekti podprti v informacijskem siste- mu. V arhitekturnem opisu v jeziku ArchiMate je pod- prtost poslovnih objektov zajeta z relacijo realizacija (Realization). Zato je osnovni vidik za analizo nepod-prtosti poslovnih objektov vidik realizacije poslovnih objektov. Poslovni objekt je lahko realiziran bodisi s predstavitvijo ali s podatkovnim objektom. Ločimo med petimi vzorci podpore poslovnih objektov: ■ vzorec (strogo) nepodprtih poslovnih objektov: poslovni objekt ni realiziran niti s predstavitvijo niti s podatkovnim objektom; ■ vzorec neaplikativno podprtih poslovnih objektov: poslovni objekt ni podprt v informacijskem sistemu, vendar je realiziran s predstavitvijo, npr. z dokumentom v papirni obliki; ■ vzorec delno neaplikativno podprtih poslovnih objektov: poslovni objekt je delno realiziran s predstavitvijo; ■ vzorec aplikativno nepodprtih poslovnih objektov: poslovni objekt ni podprt z informacijskim sistemom; ■ vzorec delno aplikativno podprtih poslovnih objektov: v informacijskem sistemu je poslovni objekt zajet (implementiran) le delno; ■ vzorec aplikativno podprtih poslovnih objektov: poslovni objekt je v celoti implementiran v informacijskem sistemu. Med podprtimi poslovnimi objekti lahko glede na števnost in vrsto realizacije (aplikativna, fizična) ločimo tudi med naslednjimi vzorci: ■ vzorec večkratne realizacije poslovnega objekta, ■ vzorec večkratne aplikativne realizacije poslovnega objekta, ■ vzorec večkratne neaplikativne realizacije poslovnega objekta, ■ vzorec enkratne realizacije poslovnega objekta, ■ vzorec enkratne aplikativne realizacije poslovnega objekta, ■ vzorec enkratne neaplikativne realizacije poslovnega objekta. V nadaljevanju podrobneje predstavljamo nekatere izmed zgoraj navedenih vzorcev. Primeri, ki so podani za posamezne vzorce, se nanašajo na zorni kot aplikativne podpore in predstavitev analiziranih poslovnih objektov: vsebujejo analizirane poslovne objekte, poslovne objekte, ki jih sestavljajo ali agregi-rajo, ter podatkovne objekte in predstavitve, ki realizirajo dane poslovne objekte. 4.3.1 Vzorec aplikativno podprtih poslovnih objektov Če je poslovni objekt aplikativno podprt, potem ga realizira (vsaj eden) podatkovni objekt. Aplikativno podprte poslovne objekte lahko opredelimo z množico: [FABO] ^AnBO = {a -I | a e AnBO a ((Eb e DO: (b,a) e Realization) v (Ebo e BO : (((bo, a) e Composition) v (bo, a) Aggregation) ) a (Ec e DO : (c, bo) e Realization))} (FD9) Slika 7 prikazuje primer pogleda realizacije po- no podprti (realizirani) s podatkovnim objektom slovnih objektov PO1, PO1B in PO1C, ki so aplikativ- PO1. Poslovna plast Aplikativna plast Poslovni objekt P0l Slika 7: Aplikativno podprt poslovni objekt 4.3.2 Vzorec delno aplikativno podprtih poslovnih vih delov realiziran s podatkovnim objektom. Po- objektov slovni objekt je lahko združuje več poslovnih objek- Poslovni objekt je delno aplikativno podprt, če ni tov (agregacija) ali je sestavljen iz več poslovnih aplikativno podprt v celoti (vzorec aplikativno pod- objektov (kompozicija). Delno aplikativno podprte prtih poslovnih objektov) in je vsaj eden izmed njego- poslovne objekte lahko opredelimo z množico: [PABO] ^AnBO = {a ] | a E AnBO \ [FABO] ^AnBO) a (Bb E BO: (a,b) E Composition v (a, b) E Aggregation) a (Bc E DO : (c, b) E Realization))} (FD1) Slika 8 prikazuje dva primera pogleda realizacije poslovnega objekta, ki kažeta na delno aplikativno podporo. (A) (B) Poslovna plast Poslovni objekt PO2.1a Poslovna plast Aplikativna piast Poslovni objekt PO2.1a -- j 1 Aplikativna plast 1 Poslovni objekt PO2.2a Poslovni objekt PO2.2b Slika 8: Delno aplikativno podprt poslovni objekt 4.3.3 Vzorec aplikativno nepodprtih poslovnih objektov Poslovni objekt je aplikativno nepodprt, če niti po- ziciji danega poslovnega objekta) ni realiziran s poslovni objekt niti kateri izmed njegovih delov (drugi datkovnim objektom. Aplikativno nepodprte po-poslovni objekti, ki nastopajo v agregaciji ali kompo- slovne objekte lahko opredelimo z množico: [AUSBO] ^AnBO = AnBO \ (,FABO - AnBO. [ u PABO] lAnBO) (FD2) Slika 9 prikazuje primer pogleda realizacije poslovnega objekta PO3, ki je aplikativno nepodprt v poslovnem sistemu, vendar je realiziran z dokumentom D1. Poslovna plast Poslovni objekt PO3 ^- Slika 9: Aplikativno nepodprt poslovni objekt 4.3.4 Vzorec neaplikativno podprtih poslovnih objektov in delno neaplikativno podprtih poslovnih objektov Neaplikativno podprt poslovni objekt je realiziran z vsaj eno predstavitvijo. Neaplikativno podprte poslovne objekte lahko opredelimo z množico: [FCBO] ,AnBO = {a ] | a E AnBO a ((Eb E R: (b,a) E Realization) v (Ebo E BO : (((bo, a) E Composition) v (bo, a) E Aggregation) ) a (Ec E R : (c, bo) E Realization)))} (FD3) Opazimo lahko, da je opredelitev vzorca neapli-kativno podprtih poslovnih objektov analogna opredelitvi vzorca aplikativno podprtih poslovnih objektov (FD10). Prav tako je opredelitev vzorca delno neaplikativno podprtih poslovnih objektov analogna vzorcu delno aplikativno podprtih poslovnih objektov. Zato je ne bomo posebej navajali. Slika 9 prikazuje primer pogleda realizacije poslovnega objekta PO3, ki je neaplikativno podprt v poslovnem sistemu. 4.3.5 Vzorec strogo nepodprtih poslovnih objektov Primeri, ko poslovni objekt ne bi bil realiziran niti s predstavitvijo niti s podatkovnim objektom, so zelo redki. To bi namreč pomenilo, da poslovni objekt v poslovnem sistemu ni kakor koli dokumentiran, temveč obstaja le kot tacitna informacija. Če obstajajo v opisu poslovno-informacijske arhitekture strogo nepodprti poslovni objekti, to največkrat pomeni, da arhitekturni opis ni pravilen. Koristno je, če orodje opozori uporabnika na to. V tem primeru lahko uporabnik model bodisi ustrezno popravi ali potrdi, da poslovni objekt res nima realizacije. Če poslovni objekt nima realizacije in hkrati nastopa v poslovnih procesih, pomeni, da gre za situacijo, ki bi jo bilo treba nasloviti. Strogo nepodprte poslovne objekte lahko opredelimo z množico: [URBO] ^AnBO = AnBO \ (, FCBO - AnBO. [ u PCBO] ^AnBO u [FABO] ^AnBO [u PABO] lAnBO) (FD4) Pri tem PCBOAnBO predstavlja množico delno ne-aplikativno podprtih poslovnih objektov. 4.3.6 Vzorec večkratne realizacije poslovnega objekta Posamezni poslovni objekt je lahko v poslovnem sistemu večkrat realiziran, npr. z različnimi dokumenti v papirni obliki, v več podatkovnih bazah itn. Vzorec večkratne realizacije poslovnega objekta največkrat kaže na neoptimalne strukture in na podvajanje podatkov v poslovnem sistemu, ki lahko vodi v znane probleme, kot sta npr. težje vzdrževanje podatkov in večje tveganje za nekonsistentnost podatkov. Poslovna plast Poslovna plast Poslovni objekt PO1 - 'I DokumenrDr^ Poslovni objekt PO4 mentoil^ Dokument D4.^ I Dokument D4.2 Aplikativna plast 1 Aplikativna plast i Poslovni objekt PO1 ; Poslovni objekt PO4.^ Poslovni objekt PO4.2 i L (A) Večkratna realizacija poslovnega objekta (B) Večkratna realizacija poslovnega objekta Poslovna plast Poslovni objekt PO3 ■- Dokument D3.1 Dokument D3.2 Poslovna plast Poslovni objekt PO2 -ET" (C) Večkratna neaplikativna realizacija poslovnega objekta (Č) Večkratna aplikativna realizacija poslovnega objekta Slika 10: Večkratna realizacija poslovnega objekta Naj bo BOR(bo) funkcija, ki dani poslovni objekt bo preslika v množico elementov, ki ga realizirajo: BOR{bo) = {rdo ] | (rdo e R U DO) a (((rdo, bo) e Realization) v (Ebo1 e BO : (((bo1, bo) e Composition) v ((bo1, bo) e Aggregation) ) a (rdo, bo1) e Realization))} (FD5) Poslovne objekte, ki so v poslovnem sistemu 4.3.7 Vzorec enkratne realizacije poslovnega objekta večkrat realizirani, lahko opredelimo z množico: [MRBO] lAnBO = {a ] \ a e AnBO a \BOR(a) \ a 2} (FD6) Zgornje slike (slika 10 (A-Č)) prikazujejo različne primere večkratne realizacije poslovnega objekta. Vzorec enkratne realizacije poslovnega objekta pomeni, da ima poslovni objekt v poslovnem sistemu natanko eno realizacijo. Ta je lahko bodisi aplikativna ali neaplikativna. Poslovne objekte, ki so v poslovnem sistemu enkrat realizirani, lahko opredelimo z množico: [SRBO] ^AnBO = {a ] \ a e AnBO a |BOR(a)| = 1} (FD7) Primera enkratne realizacije poslovnega objekta prikazujeta sliki 7 in 9. 5 SKLEP V prispevku smo prestavili vlogo arhitekturne analize na področju poslovno-informacijskih arhitektur. Predstavili smo problematiko področja, ki izhaja iz pomanjkanja mehanizmov, ki bi omogočali iskanje določenih tipičnih struktur, pomembnih za analitika na učinkovit način. V ta namen smo predlagali uporabo vzorcev v poslovno-informacijski arhitekturi in opredelili množico vzorcev za ugotavljanje ravni podpore poslovnih procesov in poslovnih objektov. Predstavljeni analitski vzorci omogočajo zaznavanje tipičnih struktur v poslovno-informacijski arhitekturi in njihovo primerjavo. Vzorci so formalizirani na način, ki omogoča njihovo implementacijo in avtomatizacijo zaznavanja struktur. Ker je fokus na med-plastnem povezovanju, predlagani analitski vzorci temeljijo na jeziku ArchiMate. Organizacija The Open Group pripravlja novo različico jezika ArchiMate, ki bo integrirala pristopa Ar-chiMate in TOGAF ter ohranjala skladnost z obstoječima različicama pristopov. Integracija obeh pristopov bo predstavljala naslednjo razvojno stopnjo dveh najbolj priznanih pristopov, integriranih v enega samega. Predlagani analitski vzorci bodo uporabni tudi za naslednjo različico ogrodja. Avtorji so predstavljene analitske vzorce uporabili pri strateškem planiranju informatike v petih velikih slovenskih poslovnih sistemih s področja elektro-distribucije, telekomunikacij, javne uprave in finančnega trgovanja. Izkazali so se kot koristno orodje pri analizi obstoječega stanja ter kot formalna podlaga za odločitve pri izdelavi strateškega načrta. Avtorji zato obstoječo različico strateškega planiranja enotne metodologije razvoja informacijskih sistemov [7] dopolnjujejo s pristopi poslovno-informacijskih arhitektur z uporabo predstavljenih vzorcev. 6 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] LITERATURA Chief Information Officer Council (2001). A Practical Guide to Federal Enterprise Architecture. Dostopno na: http://www. enterprise-architecture.info/Images/Documents/Federal%20 Enterprise%20Architecture %20Guide%20v1a.pdf. Fowler, M. (1997). Analysis patterns: reusable object models. Addison-Wesley. Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (2002). Design patterns: abstraction and reuse of object-oriented design. Software pioneers: contributions to software engineering. Springer-Verlag New York, Inc., 701-717. IEEE Computer Society (2000). IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE Standard 1471-2000. James, G. A., Handler, R. A., Lapkin, A., Gall, N. (2005). Gartner Enterprise Architecture Framework: Evolution 2005. Gartner. Krisper, M. et al. (2003). EMRIS - Enotna metodologija razvoja informacijskih sistemov - Strateško planiranje. Ljubljana, Vlada Republike Slovenije, Center Vlade RS za informatiko. Krisper, M., & Rožanec, A.: Obvladovanje informatike v poslovnih sistemih : pomen strategije in arhitektur. Uporabna informatika, 13(4), 185-198. Lankhorst, M. et al. (2009). Enterprise Architecture at Work -Modelling, Communication and Analysis, 2. izdaja, Springer Berlin Heidelberg. Riehle, D., & Züllighoven, H. (1996). Understanding and using patterns in software development. Theor. Pract. Object Syst., 2, 3-13. Rožanec, A., & Krisper, M. (2009). Poslovno informacijska arhitektura uprave. V Povežimo informacijske otoke: zbornik konference Informatika v javni upravi. Kongresni center Brdo pri Kranju, Ljubljana, Slovensko društvo Informatika. The Open Group (2009). ArchiMate 1.0 Specification, Van Haren Publishing. The Open Group (2010a). The ArchiMate Forum. Dostopno na: http://www.opengroup.org/archimate/. The Open Group (2010b). The Power of Enterprise Architecture. Dostopno na: http://www.archimate.org. The Open Group (2008). TOGAF™ Version 9, TOGAF Series, Van Haren Publishing, 9. izdaja. Zachman J. A. (1987). A Framework for Information System Architecture, IBM System Journal, 26(3), 276-292. Zachman, J. A. (2010). The Zachman Framework™, http:// www.zachmaninternational.com/. Ana Šaša je leta 2005 diplomirala in leta 2009 doktorirala na Fakulteti za računalništvo in informatiko Univerze v Ljubljani. Ukvarja se s poslovno-informacijskimi arhitekturami, avtomatizacijo poslovnih procesov, storitveno usmerjenimi arhitekturami, usklajevanjem poslovne domene in IT-domene, sistemi za podporo odločanju, ontologijami in strateškim planiranjem. Sodelovala je na številnih znanstvenoraziskovalnih projektih in projektih iz gospodarstva. Je članica več strokovnih in znanstvenih združenj. Objavila je vrsto prispevkov v priznanih mednarodnih revijah ter na domačih in tujih konferencah. Leta 2009 je prejela prvo nagrado za raziskovalne dosežke Fakultete za računalništvo in informatiko Univerze v Ljubljani. Marjan Krisper je izredni profesor na Fakulteti za računalništvo in informatiko Univerze v Ljubljani, kjer je tudi predstojnik katedre za informatiko in predstojnik laboratorija za informatiko. Njegova bibliografija obsega več kot dvesto strokovnih člankov in znanstvenih razprav. Vodi številne projekte razvoja informacijskih sistemov, elektronskega poslovanja in metodologij razvoja informacijskih sistemov v največjih sistemih v gospodarstvu, državni upravi in javnem sektorju. Je ustanovni član mednarodnega združenja za informacijske sisteme AIS (Association for Information Systems) in član izvršnega odbora Slovenskega društva Informatika. PREGLEDNI ZNANSTVENI PRISPEVKI B Pregled in analiza programskih ogrodij in sorodnih tehnologij Gregor Polančič, Boštjan Šumak Univerza v Mariboru, Fakulteta za elektrotehniko, računalništvo in informatiko, Inštitut za informatiko {gregor.polancic, bostjan.sumak}@uni-mb.si Izvleček V prispevku so predstavljena programska ogrodja, ki danes predstavljajo eno izmed ključnih tehnologij razvoja programske opreme in storitev. Predstavljeni so zgodovina in osnovne značilnosti programskih ogrodij ter položaj, ki ga ta zasedajo med tehnikami ponovne uporabe. Sledi pregled poglavitnih prednosti in slabosti programskih ogrodij in njihovo mesto v procesu razvoja programske opreme, ki je ponazorjeno v obliki procesa. Širokemu spektru uporabe programskih ogrodij je namenjen razdelek, ki navaja vrste in klasifikacije ogrodij. Ker se ogrodja pogosto zamenjujejo s sorodnimi tehnologijami, so v predzadnjem razdelku predstavljene podobnosti in razlike med koncepti in tehnologijami, ki so sorodne oz. komplementarne ogrodjem. Abstract AN INTRODUCTION TO SOFTWARE FRAMEWORKS This article presents a high-level introduction to software frameworks, which nowadays represent a focal technology for software and service development. The history, main characteristics and position of software frameworks in software reuse techniques are presented. Afterwards, the main benefits and drawbacks of using frameworks in the process of software development are explained. The wide scope of software frameworks usage is illustrated by means of defining basic frameworks types and their classifications. In order to avoid the frameworks being mistaken with other software reuse techniques, a complete chapter is assigned to the explanation of similarities and differences with similar or complementary software reuse techniques. 1 UVOD »lani projektov razvoja programske opreme se ubadajo z vedno večjimi konkurenčnimi pritiski, ki vladajo na trgu programske opreme. Ustrezen odziv na vse večjo in kakovostno ponudbo zahteva hiter razvoj novih programskih proizvodov oz. nadgradenj obstoječih proizvodov, širitev ponudbe, zagotavljanje skladnosti s standardi in visoko stopnjo povezljivosti z drugimi proizvodi. Ponovna uporaba je učinkovito sredstvo za doseganje omenjenih ciljev. Ponovna uporaba v programskem inženirstvu je definirana kot primer dejanj, v katerih se enak programski izdelek uporabi v različnih kontekstih. Izmed številnih vrst ponovne uporabe (Leach 1996; Sindre, Conradi & Karlsson 1995) spadajo produktne linije (angl. product line software) med najučinkovitejše in predstavljajo enega izmed kritičnih faktorjev uspeha ponovne uporabe (slika 1). Neuspeh Slika 1: Poglavitni faktorji, ki vplivajo na uspešnost ponovne uporabe (Morisio, Ezran & Tully 2002) Ideja produktnih linij temelji na razvoju družine izdelkov, ki so zgrajeni na enotni programski osnovi (angl. core asset base). Pokazalo se je, da takšen pristop zagotavlja dolgoročne ekonomske prednosti glede na razvoj posameznih izdelkov, kar je razvidno iz ekonomskega modela produktnih linij (Bockle et al. 2004). Produktne linije se najpogosteje implementirajo z razvojem na podlagi programskih ogrodij. Ta omogočijo produktnim linijam enotno podlago s tem, da zagotavljajo generične rešitve za množico podobnih problemov v domeni produktne linije. V nadaljevanju prispevka so podrobneje predstavljena programska ogrodja, njihova zgodovina, položaj v programskem inženirstvu in v procesu razvoja programske opreme. Predstavljene so vrste, prednosti in slabosti ogrodij. V tretjem razdelku so predstavljene tehnologije in koncepti, ki so podobni programskim ogrodjem oz. se dopolnjujejo z njimi. V zadnjem razdelku so podane sklepne misli. 2 PROGRAMSKA OGRODJA Programska ogrodja (v nadaljevanju ogrodja) so nepopolni sistemi, ki vsebujejo gradnike, enotne vsem aplikacijam v produktni liniji, in gradnike, ki jih je mogoče prilagajati in predstavljajo edinstvene dele posameznih aplikacij v produktni liniji (Srinivasan 1999). Ogrodja se razlikujejo od preostalih vrst ponovne uporabe v programskem inženirstvu (programske komponente, knjižnice, načrtovalski vzorci), saj težijo k ponovni uporabi večjih delov programske kode in zasnove na višji ravni (slika 2) (Mo-risio, Romano & Stamelos 2002). V nasprotju z drugimi tehnikami ponovne uporabe programske kode definirajo ogrodja tok izvajanja in zato delujejo kot podlaga na njih temelječih aplikacij. Ogrodja spadajo med učinkovitejše tehnike ponovne uporabe, saj poleg ponovne uporabe programske kode enkapsulira-jo še znanje načrtovanja (Oliveira et al. 2004). Aplikacija Ogrodje Načrtovalski vzorci Razredi in knjižnice Slika 2: Ogrodja in njihova povezava z drugimi tehnikami ponovne uporabe (Sangdon et al. 1999) Ogrodja predstavljajo tehniko ponovne uporabe, zato je njihov glavni cilj dvig produktivnosti v programskem inženirstvu (Mattsson 1996). Z vidika obsega ponovne uporabe se programska ogrodja uvrščajo med tehnike področne ponovne uporabe (angl. domain reuse) oz. ponovne uporabe, ki je namenjena družinam programskih izdelkov (angl. product families). Z vidika zrnatosti se programska ogrodja nahajajo na visokem (grobem) nivoju zrnatosti (glej območje kvadra na sliki 3). Usmerjenost Znanost splošna področja , .. ■ Področje družine izdelkov Slika 3: Umestitev ogrodij v REBOOT-klasifikacijo ponovne uporabe Najpogosteje uporabljena definicija ogrodja je (Johnson & Foote 1988): Ogrodje je množica razredov, ki vključujejo abstrakten načrt rešitve za družino povezanih problemov.1 Večina sodobnih ogrodij je objektno orientiranih (angl. Object-Oriented Framework - OOF) (Krajnc 2006). Definicija objektno orientiranega ogrodja je povzeta po Gamma et al. (Gamma et al. 1995) in se glasi: Ogrodje je množica sodelujočih razredov, ki sestavljajo ponovno uporaben načrt za specifično vrsto programske opreme. Ogrodje določa arhitekturne smernice z razdelitvijo načrta v abstraktne razrede in z definiranjem njihovih odgovornosti in sodelovanj. Razvijalec prilagaja ogrodje za posamezno aplikacijo s povezovanjem primerkov razredov ogrodja. Obstaja še več definicij ogrodij, ki jih je analiziral Mattsson (1996) in na njihovi podlagi oblikoval lastno, generično definicijo ogrodja: Ogrodje predstavlja generično arhitekturo, ki je zasnovana z namenom A framework is a set of classes that embodies an abstract design for solutions to a family of related problems. zviševanja ponovne uporabnosti. Ogrodja vključujejo množico sodelujočih abstraktnih in konkretnih razredov, ki enkapsulirajo obnašanje podedovanih specia-lizacij.2 Ogrodja so torej vzorci, ki vsebujejo zamisel načrta rešitve določene problemske domene in množico gradnikov, ki vsak zase izpolnjujejo posamezno vlogo v ogrodju. Poenostavljeno povedano predstavljajo ogrodja programsko opremo, ki jo lahko programer uporabi, prilagodi in razširi z namenom ustrezati zahtevam končne programske rešitve. Ogrodja (objektno orientirana) temeljijo na uveljavljenih vzorcih in izkoriščajo prednosti treh konceptov objektne paradigme: abstraktnih podatkov (razredov), poli-morfizma in dedovanja. Takšnim ogrodjem so skupne naslednje karakteristike (Johnson & Foote 1988): ■ razredi odjemalci (angl. client classes) - Končne programske rešitve se ogrodju prilegajo na t. i. razširitvenih točkah; ■ sodelovanje objektov (angl. collaboration of objects) - (Abstraktni) razredi ogrodja definirajo model obnašanja (angl. model of interaction). Končne programske rešitve se zato obnašajo po definiranem modelu; ■ zamenjava nadzora (angl. inversion of control) -Model obnašanja ogrodja določa način vključevanja razredov odjemalcev, kar pomeni, da igra ogrodje vlogo glavnega programa (v nasprotju z vključevanjem programskih knjižnic). Koncept je poznan kot »hollywoodsko načelo« (angl. Hollywood principle). 2.1 Zgodovina ogrodij Pojem »programska ogrodja« ni nov, saj se je koncept ogrodij pojavil že v osemdesetih letih prejšnjega stoletja, in sicer v okoljih Smalltalk (Adele 1984) in Apple Inc. (Kurt 1986). Prvo široko uporabljeno ogrodje je bil uporabniški vmesnik Smalltalk-80, znan pod imenom model-pogled-nadzornik (angl. Model-View-Controller) ali krajše MVC. V devetdesetih letih prejšnjega stoletja so se ogrodja iz domene uporabniških vmesnikov razširila na preostale programske domene. Med pomembnejša ogrodja, razvita v devetdesetih, spadajo CommonPoint,3 HotDraw,4 ACE,5 JAWS,6 CORBA (angl. Common Object Request Broker Architecture) in MFC (angl. Microsoft Foundation Classes). Ogrodje MVC je bilo ob ogrodju OWL (angl. Object Windows Library) kar nekaj časa dejansko industrijski standard za razvoj grafičnih aplikacij za osebne računalnike. K razširitvi in uveljavitvi ogrodij v devetdesetih letih je pripomogel tudi programski jezik java. Večina ogrodij za javo nastaja znotraj delovnih skupin v procesu JCP (angl. Java Community Process), ki ga upravlja podjetje Sun. Med ogrodja, ki so nastala v okviru JCP, spadajo EJB (angl. Enterprise JavaBeans), RMI (angl. Remote Method Invocation), AWT (angl. Abstract Window Toolkit), Swing, JFC (Java Foundation Classes), JSP (JavaServer Pages), JSF (angl. JavaServer Faces), Collection Framework, JMF (angl. Java Media Framework) in JAF (angl. JavaBeans Activation Framework). Veliko ogrodij na podlagi jave nastaja tudi v odprtokodnih projektih. Primeri takšnih ogrodij so Struts, Spring, Hybernate, JUnit, Avalon in JCorporate Expresso (Krajnc & Heričko 2004). Med najpomembnejša in najpogosteje uporabljana ogrodja zadnje generacije spadajo Microsoft.NET, Spring, Jakarta Struts, Django, Hybernate, Ruby on Rails in Eclipse framework. Poleg omenjenih ogrodij, ki so javno dostopna, številna podjetja razvijajo še lastna ogrodja (angl. in--house framework). Takšna ogrodja se uporabljajo samo interno in niso namenjena za prodajo ali javno uporabo. V zadnjem času je mogoče zaslediti tudi uporabo ogrodij za razvoj programskih orodij (Krajnc et al. 2005). Primer takšnega orodja je Eclipse IDE. 2.2 Prednosti in slabosti ogrodij Programerji in vodje projektov se za razvoj na podlagi ogrodij odločajo predvsem zaradi: (1) minimizira-nja obsega implementacije, ki je potrebna za razvoj aplikacij, in (2) lažjega obvladovanja znanja domene, v kateri organizacija razvija aplikacije (Mattsson 1996). Prednosti ogrodij so torej: ■ Hitrejši in učinkovitejši razvoj. Z uporabo ogrodja aplikacije nikoli ne gradimo od začetka, temveč ponovno uporabimo programsko kodo oz. storitve, ki jih zagotavlja ogrodje. Ker aplikaci- 2 A (generative) architecture designed for maximum reuse, represented as a collective set of abstract and concrete classes; encapsulated potential behavior for sub-classed specializations. 3 Množica ogrodij za hitrejši razvoj aplikacij. 4 Ogrodje za izgradnjo grafičnih urejevalnikov, napisano v jeziku Smalltalk. 5 ADAPTIVE Communication Environment - objektno orientirano ogrodje, namenjeno za komunikacijsko programsko opremo. 6 Adaptive Web Server - spletni strežnik in ogrodje za izgradnjo drugih vrst strežnikov. je, ki temeljijo na enakem ogrodju, gradimo po ustaljenem vzorcu, se učinkovitost razvoja še dodatno poveča. ■ Boljša kakovost programske opreme. Izvorna koda ogrodij običajno temelji na preizkušenih programskih vzorcih in je zaradi večkratne uporabe izpostavljena obsežnim testiranjem. ■ Ogrodja omogočajo ponovno uporabo izvorne kode in načrtovanja. ■ Omogočajo preusmeritev fokusa s področja sistemskih problemov na področje domene. Sistemski problemi so rešeni v ogrodjih, zato se razvijalcem aplikacij z njimi ni treba ubadati. ■ Zagotavljajo visoko stopnjo medizvedljivosti (angl. interoperability). Aplikacije, ki temeljijo na enakem ogrodju, so si glede arhitekture sorodne. Skupaj s podporo uveljavljenim standardom imajo na ogrodju temelječe aplikacije zagotovljeno visoko stopnjo medsebojne izvedljivosti. Avtorja (Fayad & Schmidt 1997) navajata, da izhajajo prednosti uporabe ogrodij iz naslednjih lastnosti ogrodij: ■ Ponovna uporabnost (angl. reusability). Stopnja ponovne uporabe ogrodja je običajno višja kot pri preostalih tehnikah ponovne uporabe.7 Ogrodja omogočajo ponovno uporabo na nivoju programske kode, vzorcev in opisa konceptov, potrebnih za reševanje določenega problema. Z opisovanjem konceptov definirajo ogrodja slovar za problemsko področje. Razvijalec, ki uporablja ogrodje, vidi problemsko področje prav skozi slovar ogrodja. S tem zagotavljajo ogrodja še ponovno uporabo konceptov analize (Roberts & Johnson 1997). ■ Modularnost (angl. modularity). Ogrodja zvišujejo modularnost programske opreme z ločevanjem vmesnikov od implementacije. Zaradi večje modularnosti je identifikacija napak in sprememb v takšni programski opremi lažja. S tem se: (1) zmanjša napor za razumevanje in vzdrževanje programske opreme in (2) zvišuje kakovost programske opreme. ■ Razširljivost (angl. extensibility). Ogrodja povečujejo razširljivost programske opreme z zagotavljanjem standardnih razširitvenih točk (angl. hook methods). Razširitvene točke zagotavljajo stabilnost vmesnikov ogrodij z njihovimi najpogostejši- mi implementacijami. Zaradi razširitvenih točk so ogrodja lahko hkrati stabilna in razširljiva. Če zgoraj navedene prednosti programskih ogrodij strnemo in finančno ovrednotimo, ugotovimo, da se prednosti uporabe ogrodij povečujejo s številom ponovnih uporab ogrodij, kar ponazarja slika 4. ^prod 12 2.4 13 0.72 Creuse 0.84 Cost comparison 1 4 7 10 13 Number of products 16 Number of products 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Product line development 15.40 16.96 18.52 20.08 21.64 23.20 24.76 26.32 27.88 29.44 31.00 32.56 34.12 35.68 37.24 38.80 Traditional development 0.00 12.00 24.00 36.00 48.00 60.00 72.00 84.00 96.00 108.00 120.00 132.00 144.00 156.00 168.00 180.00 7 Ogrodja predstavljajo tudi do 80 odstotkov kode končnega izdelka (Seddon, Staples, Patnayakuni & Bowtell 1999). Slika 4: Skupni stroški »običajnega razvoja« in razvoja na podlagi produkt-nih linij (Bockle, Clements, McGregor, Muthig, & Schmid 2004) Iz slike 4 je mogoče razbrati, da je za razvoj z uporabo ogrodij (krivulja Product line development) značilen začetni ekonomski deficit, ki nastane zaradi spremembe procesov razvoja (Corg) in razvoja lastnega ogrodja oz. spoznavanja obstoječega (Ccab). Prednosti ogrodij se nato večajo (relativno glede na »tradicionalni razvoj«) s številom ponovnih uporab ogrodja (»number of products«). Potencialne slabosti uporabe ogrodij so (Mattsson 1996; Roberts & Johnson 1997): ■ Zapleten razvoj ogrodij. Razvoj kakovostnega ogrodja je težaven in običajno zahteva bogate izkušnje v arhitekturni zasnovi aplikacij in problemski domeni. ■ Težavno dokumentiranje ogrodij. Zaradi kompleksnosti je ogrodja težko dokumentirati. Če ogrodja niso ustrezno dokumentirana, jih razvijalci aplikacij ne uporabljajo. ■ Težavno zagotavljanje povezljivosti. Ogrodja se nenehno razvijajo in spreminjajo, zato je težavno zagotavljati kompatibilnost s predhodniki in njihovimi primerki. ■ Zmanjšana učinkovitost aplikacij. Splošnost in prožnost ogrodij lahko predstavljata omejitve za razvijalce aplikacij in učinkovitost razvitih aplikacij. ■ Težavno razhroščevanje. Razhroščevanje ogrodij in primerkov ogrodij je težavno, saj pogosto ni mogoče lokalizirati napak (»Ali se napaka pojavlja v ogrodju ali v aplikaciji?«). Prav tako so lahko napake, ki se pojavijo v ogrodju, neodpravljive za uporabnike ogrodij.8 ■ Pomanjkanje standardov. Na področju ogrodij standardi ne obstajajo ali so šele v povojih, kar zmanjšuje njihovo zamenljivost (angl. replaceabi-lity). V zadnjem času se podjetja lotevajo omenjene težave z delovnimi skupinami, v katere so vključena različna podjetja in odprtokodne skupnosti. ■ Odvisnost od programskega jezika. Ker so ogrodja napisana v določenem programskem jeziku, so vezana nanj. Namestitev ogrodja v okolje, ki temelji na drugačnem programskem jeziku, zato ni mogoče. 2.3 Ogrodja v procesu razvoja programske opreme Proces razvoja programske opreme na osnovi ogrodij predstavlja poseben primer procesa razvoja na podlagi ponovno uporabne programske opreme. Procesov oz. modelov razvoja programske opreme na osnovi ogrodij je več (Mattsson 1996). Na sliki 5 so v obliki modela BPMN9 predstavljeni štirje procesi razvoja ogrodij in na ogrodju temelječih aplikacij: Proces razvoja ogrodja, ki temelji na izkušnjah razvoja aplikacij. Takšen proces se začne z razvojem (družin) aplikacij (glej začetna dogodka A). Na podlagi podobnosti med aplikacijami in izkušenj razvijalcev se lahko razvijalci odločijo skupne funkcionalnosti prenesti v ogrodje. Po izdaji ogrodja se nato vse samostojne aplikacije preoblikujejo v aplikacije, ki temeljijo na ogrodju. Izkušnje pri razvoju takšnih aplikacij se nato ponovno prenesejo v razvoj ogrodja in proces se ponovi. Proces razvoja ogrodja, ki temelji na analizi domene. Začetek takšnega procesa predstavlja analiziranje abstrakcij v domeni, ki se nato vključijo v razvoj ogrodja (glej začetna dogodka B). Na osnovi ogrodja se nato začnejo razvijati končne aplikacije. Izkušnje z razvojem končnih aplikacij in odzivi uporabnikov se nato upoštevajo pri vzdrževanju ogrodja. Proces razvoja ogrodja, ki temelji na uporabi vzorcev načrtovanja. Proces se začne z razvojem samostojne aplikacije (glej začetna dogodka A). Na podlagi analiziranja aplikacij se nato z upoštevanjem vzorcev načrtovanja začne razvoj ogrodja. V nadaljevanju se ogrodje posodablja na podlagi izkušenj pri razvoju aplikacij in njihovih uporabnikov. Q A. Začetek razvoja samostojnih aplikacij Razvoj in vzdrževanje aplikacij a B. Začetek razvoja aplikacij z uporabo ogrodja Aplikacije OA. Razvoj ogrodja, ki temelji na izkušnjah aplikacij I OH • ^ B. Razvoj ogrodja, Analiza izkušenj in podobnosti Izdaja aplikacij Nove zahteve .•• Prenehanje razvoja ■ Novo Novo ogrodje Konec razvoja aplikacij Analiza domene Uporaba vzorcev načrtovanja ki temelji na analizi domene Rain razvoj generičnega ogrodja Razvoj in vzdrževanje ogrodja - n IT Razvoj, ki temelji na vzorcih načrtovanja Ogrodje Prenehanje razvoja Konec razvoja ogrodij Izdaja ogrodja ^TestiranjaT ogrodja na testnih aplikacijah Slika 5: Različni procesi razvoja ogrodja, prikazani v modelu BPMN 8 V primeru lastniških, zaprtokodnih ogrodij. 9 BPMN je akronim za Business Process Modelling Notation. Proces razvoja generičnega ogrodja. Razvoj generičnega ogrodja se začne z analiziranjem domene (glej začetna dogodka B). Na podlagi analize domene se začne razvoj generičnega ogrodja. Testiranje ogrodja se izvede s testnimi aplikacijami, na podlagi katerih se nato izboljšuje ogrodje. Takšen proces je lahko popolnoma neodvisen od razvoja aplikacij. Programskim jezikom sorodna orodja Grafična razvojna okolja Finozrnate komponente Vključitveni objekti Knjižnice razredov Ogrodja bele škatle Ogrodja črne škatle "Trije primerki« -Čas- Slika 6: Evolucija ogrodij, temelječa na vzorcih zasnove (Roberts & Johnson 1997)9 Vzporedno s procesom razvoja in vzdrževanja so ogrodja izpostavljena tudi evoluciji oz. »zorenju« ogrodja. Roberts in Johnson (1997) sta na podlagi vzorcev zasnove ogrodij opredelila stopnje zrelosti ogrodij: ■ Ogrodja bele škatle (angl. white-box framework). Instanciranje takšnega ogrodja temelji na modifikacijah izvorne kode ogrodja in na dedovanju razredov ogrodja. ■ Knjižnice komponent (angl. component library). Razredi, ki so skupni aplikacijam v domeni ogrodja, so v ogrodje vključeni v obliki knjižnic. ■ Vroče točke (angl. hot spots). V takšnih orodjih je koda, ki se pogosto spreminja, ločena od kode, ki se ne spreminja (angl. frozen spots). Zaradi lažjega obvladovanja je koda, ki se spreminja, združena v razredih, ki se najpogosteje razširjajo s kompozicijo. ■ Vključitveni objekti (angl. pluggable objects). Namesto trivialnih podrazredov vsebuje takšno 9 Prvo fazo v vzorcih evolucije ogrodij predstavljajo trije primerki razvoja aplikacij v domeni, v kateri naj bi se razvilo ogrodje. Taksen pristop razvoja ogrodij je skladen s procesom razvoja ogrodja na izkušnjah razvoja aplikacij (slika 4). ogrodje podrazrede, ki jih je mogoče parameteri-zirati. ■ Drobnozrnate komponente (angl. fine-grained components). S ciljem povečanja stopnje ponovne uporabnosti so razredi in knjižnice v takšnih ogrodjih drobnozrnati. ■ Ogrodja črne škatle (angl. black-box frameworks). V takšnih ogrodjih so knjižnice strukturi-rane na osnovi dedovanja, medtem ko se za njihovo povezovanje uporablja kompozicija. ■ Grafična razvojna okolja (angl. visual building tools). Grafična razvojna okolja so v pomoč razvijalcem aplikacij pri specifikaciji in povezovanju objektov v primerkih ogrodja. ■ Programskim jezikom sorodna orodja (angl. language tools). Takšnim ogrodjem so dodana orodja za njihov nadzor izvajanja in pomoč pri razhro-ščevanju. 2.4 Vrste in klasifikacije ogrodij Ogrodja se po svoji zasnovi, obsežnosti in namenu zelo razlikujejo. Čeprav obstajajo najrazličnejše klasifikacije ogrodij, ogrodja najpogosteje delimo na (Johnson & Foote 1988): ■ domenska ogrodja (angl. domain framework) -naslavljajo določene problemske domene (npr. zavarovalništvo, računovodstvo in upravljanje človeških virov), ■ orodna ogrodja (angl. utility framework) - naslavljajo določene programske domene (npr. trajnost podatkov, uporabniški vmesnik in testiranje kod), ■ aplikacijska ogrodja (angl. application framework) - obsežna ogrodja, ki so uporabna za različne problemske domene in naslavljajo številne programske domene. V zadnjem času je vse več poskusov uveljavljanja t. i. organizacijskih ogrodij (angl. enterprise frameworks), ki zaokrožujejo posamezno problemsko domeno poslovanja. Če jih primerjamo z drugimi ogrodji, so organizacijska ogrodja po obsegu večja in bolj kompleksna; v njih so lahko vsebovane najrazličnejše komponente in druga ogrodja. Organizacijska ogrodja vključujejo infrastrukturni, domenski in arhitekturni vidik (Fayad & Hamu 2000). Poleg predstavljene delitve se ogrodja pogosto delijo glede na tip razvoja, in sicer na: (1) odprtoko-dna (angl. open source frameworks), (2) lastniška (angl. proprietary frameworks) in (3) ogrodja, ki so razvita za lastne potrebe (angl. in-house frame- Vroče točke works). Glede na tehniko uporabe lahko ogrodja razvrstimo na ogrodja bele škatle in ogrodja črne škatle. Za ogrodja bele škatle je značilno, da se za doseganje razširljivosti močno opirajo na lastnosti objektivno orientiranih jezikov, kot sta dedovanje ali povezovanje v času izvajanja (angl. dynamic binding). Ogrodja črne škatle podpirajo razširljivost skozi definicijo vmesnikov za komponente, ki jih lahko nato vključimo v ogrodje z uporabo kompozicije objektov. Obstajajo še ogrodja sive škatle in steklene škatle, ki predstavljajo vmesne rešitve (slika 6). Siva škatla Steklena škatla USMERJENOST K SEGMENTOM I 2007 > USMERJENOST K POSAMEZNIKU Enovita ponudba Masovne komunikacije Enotne prodajne poti Prilagoditev ponudbe segmentom Masovne komunikacije Segmentom prilagojeni mediji Segmentom prilagojene prodajne poti Posamezniku prilagojena ponudba Individualni pristop pri komuniciranju Prodajne poti po meri posameznika Slika 3: Prehod iz storitvenega trženja k individualiziranemu Podatkovno rudarjenje se uveljavlja v zadnji razvojni fazi, prikazani na sliki 4. Razlogi za njegovo vpeljavo so predvsem v: ■ večji natančnosti pri izbiri potencialnih strank, ■ hitrosti izvedbe projekta, saj z orodji za hiter razvoj (angl. Rapid Application Development) prej pridemo do boljših rezultatov, ■ merljivosti natančnosti, saj z individualnim pristopom dobimo ustrezen odziv stranke, tega pa lahko uporabimo za oceno kakovosti napovedi. Rezultate lahko neposredno uporabljata kontaktni center in poslovna mreža. Oddelek za raziskave in analize periodično primerja rezultate modelov z dejanskimi podatki iz poslovanja. Spremljanje kakovosti modelov je ključno za uspešno podatkovno rudarjenje. 50,00 % 40,00 % 30,00 % 20,00 % 10,00 % 0,00 % Internetno bančništvo I Starost < 30 let < 50 let < 80 let < 100 let Slika 4: Razmerje med starostjo strank in uporabo internetnega bančništva 3.2 Analiza in priprava podatkov NLB uporablja podatkovno skladišče, ki je osnovano na IBM-ovih tehnologijah s podatkovno zbirko DB2, zato je treba podatke pred začetkom modeliranja prenesti na platformo SQL Server 2008. Temu postopku pravimo tudi ETL (angl. Extract, Transform, Load). Rezultat transformacije je tabela, ki ima v vrsticah stranke, v stolpcih pa njihove atribute, npr. starost, kraj bivanja, število sklenjenih storitev ipd. Ključen je binarni razredni atribut, ki pove, ali je stranka v določenem obdobju sklenila depozit ali ne. Za analizo podatkov uporabljamo statistične metode. Korelacija denimo pokaže moč linearne povezanosti med posameznimi atributi. Z uporabo grafov lahko hitro ugotovimo frekvenčne porazdelitve posameznih atributov, kar je na začetku koristno za spoznavanje s podatki. Na sliki 4 je primer takšne porazdelitve. Seznam atributov komitenta za modeliranje pripravimo skupaj z tržnimi analitiki in komercialisti. Prvi poznajo objektivne razloge za sklenitev depozita, drugi pa subjektivne, saj so dnevno v stiku s komitenti. 3.3 Algoritmi Algoritmi za podatkovno rudarjenje se delijo v dve skupini: nadzorovani (angl. supervised) in nenadzorovani (angl. unsupervised). Pri nadzorovanih se odvisna spremenljivka izračuna na podlagi neodvisnih. Rečemo tudi, da ti algoritmi potrebujejo učitelja (odvisno spremenljivko), da se lahko učijo. Nenadzorovani algoritmi obravnavajo vse spremenljivke neodvisno. Takšni algoritmi se ne učijo na podlagi ciljne spremenljivke, temveč skozi serijo ponovitev kon-vergirajo proti cilju. Takšen primer je segmentacija, pri kateri cilj predstavlja stabilno ločnico med posameznimi segmenti. Za izračun naklonjenosti stranke k sklenitvi depozita se uporabljajo klasifikacijski (nadzorovani) algoritmi, npr. odločitvena drevesa, nevronske mreže, naivni Bayes in logistična regresija. Klasifikacija pomeni uvrščanje objektov (komitentov) v binarni razred: 1 - sklene depozit, 0 - ne sklene depozita. Vsako stranko opisujejo določeni atributi (lastnosti). Atributi so lahko diskretne ali zvezne neodvisne spremenljivke. Vrednost binarnega razreda se izračuna iz vrednosti neodvisnih spremenljivk. Algori- tem iz učne množice podatkov inducira pravila za klasifikacijo strank, ki so shranjena v modelu. Pravil- nost modela se preveri na testnih podatkih. Postopek učenja in testiranja modela prikazuje slika 5. Učna množica ID Atribut 1 Atribut 2 Atribut 3 Razred 1 Da Velik 125K Da 2 Ne Majhen 50K Da 3 Da Srednji 10K Ne 4 Da Srednji 20K Ne 5 Da Velik 30K Ne 6 Ne Velik 90K Da 7 Ne Velik 75K Da 8 Da Srednji 212K Da 9 Ne Srednji 15K Ne 10 Ne Majhen 60K Ne Testna množica ID Atribut 1 Atribut 2 Atribut 3 Razred 11 Da Srednji 72K ? 12 Da Velik 115K ? 13 Ne Velik 95K ? 14 Ne Majhen 30K ? 15 Ne Srednji 50K ? Algoritem Učenje modela Testiranje modela Model Slika 5: Postopek reševanja klasifikacijskega problema Posebno pozornost je treba posvetiti izbiri učne in testne množice. Običajno imamo pri podatkovnem rudarjenju opravka z veliko količino neenakomerno razporejenih podatkov, zato uporabimo vzorčenje (SAS Institute Inc., 1998). Razmerje odzivnih strank proti neodzivnim je v celotni populaciji majhno. To lahko povzroča težave pri indukciji pravil. Ta so lahko ali preveč prilagojena učni množici ali pa preveč splošna, zaradi česar je model nenatančen. Problem neuravnovešenosti klasifikatorja v podatkih stroka rešuje na različnih delavnicah (Chawla, Japkowitz in Kolcz, 2004). 3.4 Modeliranje in vrednotenje rezultatov Pripravi podatkov sledi modeliranje, to je uporaba ustreznega algoritma, ki pravila shrani v modelu. Platforma SQL Server 2008 ima za klasifikacijo na voljo naslednje algoritme: odločitvena drevesa, nevron- ske mreže, naivni Bayes in logistična regresija. Vsi algoritmi z izjemo naivnega Bayesa uporabljajo diskretne in zvezne vhodne atribute. Med vhodne atribute glede na poslovni problem štejemo demografske podatke (kraj bivanja, starost), podatke o poslovanju (uporaba mobilnega bančništva, število sklenjenih storitev) in podatke o materialnem stanju (sredstva, obveznosti). Vrednost izhodnega atributa je binarna in pove, ali je stranka v določenem obdobju sklenila depozit ali ne. Rezultati procesiranja modela se shranijo v podatkovni bazi. Natančnost napovedi štirih modelov preverimo na testni množici podatkov z uporabo dveh metod; to sta odzivni diagram (angl. Lift Chart) (Vuk in Curk, 2006) in križno preverjanje na podmnožicah (angl. K-fold Cross Validation) (Microsoft, Cross-Validation (Analysis Services - Data Mining)). Odzivni diagram za dva algoritma je na sliki 6. 100 % 90 % 80 % 70 % 60 % 50 % 40 % 30 % 20 % 10 % 0 % 0 % 10 % 20 % 30 % 40 % 50 % 60 % 70 % 80 % 90 % 100 % Slika 6: Nevronska mreža ima pri enaki velikosti vhodne populacije večji odziv kot naivni Bayes. Slika prikazuje napovedno moč modela. Ta pri 10 odstotkih populacije pravilno napove kar 80 odstotkov vseh strank, ki so sklenile depozit. V teoriji to pomeni v primerjavi z naključnim izborom osemkratno zmanjšanje stroškov, potrebnih za kontaktiranje strank. Primerjava med algoritmi kaže, da razlik med algoritmi - z izjemo naivnega Bayesa - tako rekoč ni. Do razlik pride šele z uporabo križnega preverjanja. Ta metoda na podmnožicah izvede klasifikacijski algoritem in izračuna statistične metrike: število pravilno klasificiranih primerov, kvadratni koren povprečne kvadratne napake (RMSE) ipd. Rezultati križnega preverjanja kažejo, da so odločitvena drevesa nekoliko boljša od preostalih algoritmov. V praksi je dobro izbrati algoritem, ki deluje dobro ne glede na vhodno množico. Takšen je denimo algoritem logistična regresija, ki se je v NLB izkazal za uspešnega pri napovedi sklenitve depozitov. Napovedna moč tega modela je boljša od segmentno usmerjenih metod, ki ciljajo na določene značilnosti strank, npr. starostni segment (mladi, zaposleni, upokojenci) ali tip osebnega računa (študentski, srebrni, zlati itn.). 3.5 Uporaba rezultatov V NLB rezultate uporabljajo komercialisti v poslovalnicah in kontaktni center. Komercialisti za poslovanje s fizičnimi osebami uporabljajo informacijski sistem za podporo poslovanju na bančnem okencu (NBO). Njegovo programsko ogrodje omogoča preprost prikaz rezultatov iz podatkovnega skladišča z uporabo transakcij. Pri tem je treba paziti, da s prenosom rezultatov iz platforme SQL Server 2008 ne zaklenemo zapisov v tabelah podatkovnega skladi- šča DB2. Temu se izognemo tako, da rezultate najprej zapišemo v klonirano ciljno tabelo, nato pa podatke preklopimo naenkrat. Komercialisti depozit ponudijo tistim strankam, ki imajo v podatkovnem skladišču zapisano visoko verjetnost za sklenitev depozita, npr. nad 95-odstot-no. NBO uporablja sistem za povratno informacijo strank o njihovi odločitvi. Drugi del uporabnikov predstavlja kontaktni center, ki izvaja neposredno trženje. Ti uporabniki prejmejo seznam najbolj potencialnih strank za sklenitev depozita. Seznam je lahko v poljubni obliki, pomembni so le kontaktni podatki osebe in njen odziv na ponudbo. V preskusnem obdobju seznam omejimo na 100-200 strank, kasneje pa število omejimo glede na pričakovani donos. Kontaktni center po koncu akcije pošlje povratno informacijo oddelku za raziskave in analize, ki preveri ujemanje napovedi z dejansko sklenjenimi posli. Povratne informacije uporabljamo pri nadaljnjem razvoju modelov. 4 SKLEP Opisani primer potruje Gartnerjevo napoved o povečevanju vlaganj v poslovno obveščanje. S projektom napovedi sklenitve depozitov bi v teoriji lahko za osemkrat zmanjšali stroške obveščanja komitentov. Čeprav bi bil ekonomski učinek manjši, podatkovno rudarjenje kaže velik potencial. Uporabo podatkovnega rudarjenja bomo v NLB razširili tudi na druge storitve, kot so sklepanje kreditov, kartično poslovanje, obvladovanje kreditnega tveganja ipd. Dodatno bomo gradili tudi na predvidevanju potreb strank z uporabo naprednih analitik. 5 premišljenim načrtovanjem lahko obstoječo struk- turo podatkov uporabimo pri vseh modelih, pri katerih so komitenti v središču opazovanja. Razvoj poslovnega obveščanja usmerjamo v združevanje sorodnih družin izdelkov, kot so poročila, OLAP-kocke in podatkovno rudarjenje. Rezultate tovrstnega razvoja prikazujemo na sodobnih portalih, kot je npr. SharePoint. S tem se izognemo visokim stroškom lastnega razvoja, še posebno ker gre za tehnologije istega proizvajalca. Tovrstno združevanje na skupnem portalu ima za posledico večjo povezanost sodelavcev iz različnih oddelkov, kar je ključnega pomena pri učinkovitem razvoju informacijske tehnologije. Z uporabo podatkovnega rudarjenja smo v NLB dosegli pomembne poslovne učinke z uporabno najsodobnejših tehnologij in pripravili temelje za doseganje večje učinkovitosti ter širitve znanja znotraj celotne skupine NLB. 5 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] VIRI IN LITERATURA Gartner. (2009). Gartner Reveals Five Business Inteiiigence Predictions for 2009 and Beyond. Pridobljeno 8. 9. 2010 s http://www.gartner.com/it/page.jsp?id=856714. Kononenko, I. in Kukar, M. (2007). Machine learning and data mining. Chichester: Horwood Publishing, Ltd. Ghani, R. in Soarez, C. (2009). Editorial: Data Mining for Business Applications. Special Interest Group on Knowledge Discovery and Data Mining. Shearer, C. (2000). The CRISP-DM Model: The New Blueprint for Data Mining. Journal of Data Warehousing, V (4), str. 13-21. Chapman, P., Clinton, J., Kerber, R., Khabaza, T., Reinartz, T., Shearer, C. idr. (1999). CRISP-DM 1.0 Step-by-step data mining guide. Pridobljeno 8. 3. 2010 s http://www.crisp-dm.org/. SAS Institute Inc. (1998). Data Mining and the Case for Sampling. SAS Institute Inc. Chawla, N. V., Japkowitz, N. in Kolcz, A. (2004). Editorial: Special Issue on Learning from Imbalanced Data. Pridobljeno 8. 3. 2010 s http://www.sigkdd.org/explorations/issu-es/6-1-2004-06/edit_intro.pdf. Konda, P. (2009). Izvedba podatkovnega rudarjenja v bančništvu z uporabo metodologije CRISP-DM. Diplomska naloga. Vuk, M. in Curk, T. (2006). ROC Curve, Lift Chart and Calibration Plot. Metodološki zvezki, 3 (1). Microsoft. Cross-Validation (Analysis Services - Data Mining). Pridobljeno 8. 3. 2010 s: http://msdn.microsoft.com/en-us/ library/bb895174.aspx. Peter Konda je diplomiral na Fakulteti za računalništvo in informatiko Univerze v Ljubljani na temo podatkovnega rudarjenja. Leta 2009 se je zaposlil v upra-vljalskem centru za informacijsko tehnologijo v NLB. Trenutno se ukvarja z novimi področji uporabe podatkovnega rudarjenja in integracijo storitev poslovnega obveščanja na SharePoint portalu. Jure Peljhan je leta 1998 diplomiral na Fakulteti za organizacijske vede v Kranju Univerze v Mariboru. Na Ekonomski fakulteti Univerze v Ljubljani je leta 2002 je končal specialistični študij, leta 2003 pa še magistriral s področja celovitega obvladovanja kakovosti. Prispevki s tega področja so bili predstavljeni tudi na mednarodnih konferencah v Benetkah in Zagrebu. Poklicno pot je začel v skupini NLB kot sistemski analitik programer na področju plačilnega prometa v okolju centralnega računalnika ter nadaljeval na področju spletnih tehnologij. Vodil je projekte s področij kadrovskega, plačnega, izobraževalnega informacijskega sistema, skrbniških storitev vzajemnih in pokojninskih skladov ter menedžerskega informacijskega sistema. Bil je svetovalec člana uprave, odgovornega za področje informacijske tehnologije, in direktor sektorja za strateško načrtovanje in upravljanje informacijskega sistema banke. Od leta 2008 dela kot direktor centra za informacijsko tehnologijo v skupini NLB. Iz Islovarja Islovar je spletni terminološki slovar informatike, ki ga od leta 2001 objavlja Slovensko društvo INFORMATIKA na naslovu http://www.islovar.org. Objavljamo aktualno zbirko izrazov, ki smo jo zaključili te dni. Veliko številko sinonimov izhaja iz odločitve, da priznavamo izraza »programska oprema« in »programje« kot enakovredna sinonima. Izraze lahko komentirate, tako da se prijavite v poglavju Nov uporabnik, poiščete izraz, ki ga želite komentirati, in zapišete svoj komentar ali predlog spremembe. avtorska pravica -e -e ž (angl. copyright) pravica, ki avtorju zagotavlja uresničevanje premoženjskih in osebnih interesov v zvezi z izkoriščanjem lastnega avtorskega dela, npr. materialna avtorska pravica, moralna avtorska pravica; prim. copyleft brezplačna programska oprema -e -e -e ž (angl. freeware) programska oprema, za katere uporabo nosilec materialne avtorske pravice ne zahteva nadomestila, lahko pa postavlja druge omejitve, npr. prepoved spreminjanja, prepoved razširjanja; sin. zastonjsko programje, brezplačno programje, zastonjska programska oprema; prim. komercialna programska oprema brezplačni program -ega -a m (angl. freeware program) računalniški program, za katerega uporabo nosilec materialne avtorske pravice ne zahteva nadomestila, lahko pa postavlja druge omejitve, npr. prepoved spreminjanja, prepoved razširjanja; sin. zastonjski program; prim. komercialni program brezplačno programje -ega -a s (angl. freeware) programje, za katerega uporabo nosilec materialne avtorske pravice ne zahteva nadomestila, lahko pa postavlja druge omejitve, npr. prepoved spreminjanja, prepoved razširjanja; sin. zastonjsko programje, brezplačna programska oprema, zastonjska programska oprema; prim. komercialno programje copyleft -a [kopileft] m (angl. copyleft) politika licenciranja, ki podeljuje vsakemu uporabniku pravico do rabe, razširjanja in spreminjanja računalniških programov, dokumentov; prim. splošna javna licenca GNU, avtorska pravica GNU GNU-ja [gnu] m, krat. (angl. GNU's not Unix, krat. GNU) 1. operacijski sistem, podoben Unixu, ki je sestavljen edino iz prostega programja 2. projekt, katerega cilj je izdelati tak operacijski sistem javna programska oprema -e -e -e ž (angl. public domain software) programska oprema, katere raba ni omejena z varovanjem materialnih avtorskih pravic; sin. javno programje; prim. lastniška programska oprema, prosta programska oprema javni program -ega -a m (angl. public domain program) računalniški program, katerega raba ni omejena z varovanjem materialnih avtorskih pravic; prim. lastniški program, odprtokodni program javno programje -ega -a s (angl. public domain software) programje, katerega raba ni omejena z varovanjem materialnih avtorskih pravic; sin. javna programska oprema; prim. lastniško programje, prosto programje komercialna programska oprema -e -e -e ž (angl. commercial software, payware) programska oprema, za uporabo katere nosilec materialne avtorske pravice zahteva nadomestilo, navadno ob dodatnih omejitvah, npr. prepoved spreminjanja, prepoved razširjanja; sin. komercialno programje; prim. brezplačna programska oprema komercialni program -ega -a m (angl. commercial software program) računalniški program, za uporabo katerega nosilec materialne avtorske pravice zahteva nadomestilo, navadno ob dodatnih omejitvah, npr. prepoved spreminjanja, prepoved razširjanja; prim. brezplačni program komercialno programje -ega -a s (angl. commercial software, payware) programje, za uporabo katerega nosilec materialne avtorske pravice zahteva nadomestilo, navadno ob dodatnih omejitvah, npr. prepoved spreminjanja, prepoved razširjanja; sin. komercialna programska oprema; prim. brezplačno programje lastniška dodatna kartica -e -e -e ž (angl. proprietary add-on card) dodatna kartica za preprečevanje nepooblaščene rabe lastniškega programja; prim. zaščitni ključ (1) lastniška programska oprema -e -e -e ž (angl. proprietary software) programska oprema, pri kateri licenčna pogodba omejuje uporabo, spreminjanje ali razširjanje; sin. lastniško programje, zakonsko zaščitena programska oprema; prim. javna programska oprema, odprtokodna programska oprema lastniški program -ega -a m (angl. proprietary program) računalniški program, pri katerem licenčna pogodba omejuje uporabo, spreminjanje ali razširjanje; prim. javni program, odprtokodni program lastniško programje -ega -a s (angl. proprietary software) programje, pri katerem licenčna pogodba omejuje uporabo, spreminjanje ali razširjanje; sin. lastniška programska oprema, zakonsko zaščitena programska oprema; prim. javno programje, odprtokodno programje licenca -e ž (angl. licence) dovoljenje za uporabo, spreminjanje, razširjanje programske opreme, digitalne vsebine; prim. licenčna pogodba licenčna pogodba -e -e ž (angl. license agreement) pogodba, v kateri sta opredeljena način in obseg prenosa pravic do uporabe, spreminjanja, razširjanja programske opreme, digitalne vsebine; prim. licenca licenčno določilo -ega -a s (angl. licensing term) določilo, opredeljeno v licenčni pogodbi materialna avtorska pravica -e -e -e ž (angl. economic right) vsaka od avtorskih pravic, ki varuje premoženjska upravičenja nosilca in mu daje izključno pravico nad posameznimi oblikami izkoriščanja avtorskega dela, npr. pravica do reprodukcije, pravica do javnega izvajanja, pravica distribuiranja, pravica dajanja v najem; prim. moralna avtorska pravica moralna avtorska pravica -e -e -e ž (angl. moral right) vsaka od neodtujljivih avtorskih pravic, ki avtorju zagotavlja uresničevanje moralnih interesov v zvezi z avtorskim delom, npr. pravica priznanja avtorstva, pravica spoštovanja dela ; prim. materialna avtorska pravica odprta koda -e -e ž (angl. open source) politika zasnove, razvoja in razširjanja programja, pri kateri je dostopna izvorna koda, ki se jo sme spreminjati in razširjati odprta programska oprema -e -e -e ž (angl. open source software, krat. OSS) gl. odprtokodna programska oprema in odprtokodno programje in prosta programska oprema in prosto programje odprto okolje -ega -a s (angl. open environment) programsko okolje, ki je prosto dostopno, avtorsko nezaščiteno odprto programje -ega -a s (angl. open source software, krat. OSS) gl. odprtokodno programje in odprtokodna programska oprema in prosta programska oprema in prosto programje odprto učno programje -ega -ega -a s (angl. open learning management system) odprto programje za upravljanje učenja odprtokodna programska oprema -e -e -e ž (angl. open source software, krat. OSS) programska oprema, pri kateri licenčna pogodba daje uporabniku pravico uporabe, razširjanja, spreminjanja; sin. odprta programska oprema, odprto programje, odprtokodno programje, prosta programska oprema, prosto programje; prim. lastniška programska oprema odprtokodni program -ega -a m (angl. open source program) računalniški program, pri katerem licenčna pogodba daje uporabniku pravico uporabe, razširjanja, spreminjanja; prim. javni program, lastniški program odprtokodno programje -ega -a s (angl. open source software, krat. OSS) programje, pri katerem licenčna pogodba daje uporabniku pravico uporabe, razširjanja, spreminjanja; sin. prosto programje, odprto programje, odprtokodna programska oprema, odprta programska oprema, prosta programska oprema; prim. lastniško programje okrnjeno programje -ega -a s (angl. crippleware) lastniško programje za ogled plačljive, neokrnjene različice, pri katerem je omogočeno omejeno preizkušanje predstavitveno programje -ega -a s (angl. demoware) lastniško programje za predstavitev plačljive, neokrnjene različice, pri katerem je omogočen brezplačen ogled, omejeno preizkušanje preizkusna programska oprema -e -e -e ž (angl. shareware) lastniška programska oprema, ki se lahko določeno časovno obdobje uporablja brezplačno; sin. preizkusno programje preizkusni program -ega -a m (angl. shareware program) lastniški program, ki se lahko določeno časovno obdobje uporablja brezplačno preizkusno programje -ega -a s (angl. shareware) lastniško programje, ki se lahko določeno časovno obdobje uporablja brezplačno; sin. preizkusna programska oprema programje na pokušino -a----m (angl. shareware) neustr. gl. preizkusno programje in preizkusna programska oprema prosta programska oprema -e -e -e ž (angl. free software) programska oprema, pri kateri licenčna pogodba daje uporabniku pravico uporabe, razširjanja, spreminjanja; sin. odprto programje, odprta programska oprema, odprtokodna programska oprema, odprtokodno programje, prosto programje; prim. lastniška programska oprema, javna programska oprema prosto programje -ega -a s (angl. free software) programje, pri katerem licenčna pogodba daje uporabniku pravico uporabe, razširjanja, spreminjanja; sin. odprto programje, odprta programska oprema, odprtokodna programska oprema, odprtokodno programje, prosta programska oprema; prim. lastniško programje, javno programje splošna javna licenca GNU -e -e -e -- [gnu] ž (angl. GNU General Public License) licenca, pod katero so dostopni programi projekta GNU in drugi prosti programi; prim. copyleft vzorčni -a -o prid. (angl. demo) ki je namenjen preskušanju, spoznavanju, npr. vzorčno gradivo, vzorčni program vzorčni program -ega -a m (angl. demo program) računalniški program, ki je namenjen preskušanju ali spoznavanju zakonsko zaščitena programska oprema -- -e -e -e ž (angl. proprietary software) gl. lastniška programska oprema in lastniško programje zastonjska programska oprema -e -e -e ž (angl. freeware) programska oprema, za uporabo katere nosilec materialne avtorske pravice ne zahteva nadomestila, lahko pa postavlja druge omejitve, npr. prepoved spreminjanja, prepoved razširjanja; sin. brezplačna programska oprema, brezplačno programje, zastonjsko programje; prim. komercialna programska oprema zastonjski program -ega -a m (angl. freeware program) računalniški program, za uporabo katerega nosilec materialne avtorske pravice ne zahteva nadomestila, lahko pa postavlja druge omejitve, npr. prepoved spreminjanja, prepoved razširjanja; sin. brezplačni program; prim. komercialni program zastonjsko programje -ega -a s (angl. freeware) programje, za katerega uporabo nosilec materialne avtorske pravice ne zahteva nadomestila, lahko pa postavlja druge omejitve, npr. prepoved spreminjanja, prepoved razširjanja; sin. brezplačno programje, brezplačna programska oprema, zastonjska programska oprema; prim. komercialno programje Koledar prireditev MPP2010 - Mednarodna poslovna konferenca Management poslovnih procesov 2010 20.-21. okt. 2010 Ljubljana, Slovenija http://www.process-conference.org Digital Agenda Stakeholder Day 25. okt. 2010 Bruselj, Belgija http://ec.europa.eu/information_ society/events/dae/2010 Practical guide to the EU Labyrinth - European Public Affairs intensive course 2.-5. nov. 2010 Bruselj, Belgija http://www.e-t-i.be AmI-10 - 1st International Joint Conference on Ambient Intelligence 10.-12. nov. 2010 Malaga, Španija http://www.ami-10.org Informatika v javni upravi 2010 22.-23. nov. 2010 Brdo pri Kranju, Slovenija http://www.iju2010.si Employment Week, the European Employment Forum 24.-25. nov. 2010 Bruselj, Belgija http://www.employmentweek.com ORSI 2010 - 43rd Annual Convention of Operations Research Society of India & International Conference on Operations Research for Urban and Rural Development 15.-17. dec. 2010 Madurai, Indija http://www.tce.edu/orurd2010 Pomembni spletni naslovi ^ IFIP News: http://www.ifip.org/images/stories/ifip/public/Newsletter/news ali www.ifip.org ^ Newsletter ^ IT Star Newsletter: www.itstar.eu ^ ECDL: www.ecdl.com ^ CEPIS: www.cepis.com Dostop do dveh tujih strokovnih revij ^ Revija Upgrade (CEPIS)vangleščini (ISSN 1684-5285)jedostopna naspletnem naslovu: http://www.upgrade-cepis.org/issues/2008/4/ upgrade-vol-IX-4.html. ^ Revija Novatica (CEPIS) v španščini (ISSN 0211-21 24) je dostopna na spletnem naslovu: http://www.ati.es/novatica/. Ill lüiGinnii INFORMATIKA KOT GONILO OJ ij- RAZVOJA JAVNE UPRAVE (J .1A i»MT m.m. nm.m.n j , i v JAVNiDioioaiaio .aupRAvioeaiQ Informatika v javni upravi 2010 Spoštovani! 22. in 23. novembra 2010 bo v Kongresnem centru Brdo pri Kranju potekala 2. konferenca Informatika v javni upravi. v decembru 2009 je bita pod okriljem Ministrstva za javno upravo. Ministrstva za visoko šolstvo, znanost in tehnologijo ter v izvedbi Slovenskega društva INFORMATIKA organizirana t. konferenca Informatika v javni upravi (IJtJ 2009), ki je v vsebinskem smislu nasledila konferenco Informatika v državnih organih (INDO). S konferenco lJU 2009, ki seje je udeležilo preko 370 udeležencev, nam je uspelo pripraviti strokovno, vsebinsko bogato in kakovostno konferenco, to pa je želja organizatorjev tudi letos. Vodilna misel letošnje konference je »Informatika kot gonilo razvoja javne uprave«, v ospredju so prizadevanja, da bi javna uprava delovala kot prijazen in učinkovit servis, da bi imeli uporabniki - državljani in podjetja - čim manj težav z birokracijo in da bi bili postopki hitri in enostavni. Pri modernizaciji igra ključno vlogo informatika, ki že v osnovi lahko bistveno pripomore k učinkovitim in kakovostnim storitvam z nižjimi stroški tako za državljane kot podjetja. Predvsem gre za prenovo tn prilagoditev poslovnih procesov, ki z uporabo sodobnih informacijsko-telekomunikacijskih sredstev dobivajo nove možnosti in priložnosti za racionalizacijo, optimizacijo, standardizacijo ter usmerjenost k uporabnikom. Koordinacija delovanja informatike in normativne dejavnosti, skladen razvoj, pretok informacij, prenos znanja in dobrih praks ter souporaba informacijsko-komunikacijske infrastrukture med vsemi resorji so namreč ključnega pomena za dolgoročen tn uspešen razvoj javnih informacijskih storitev v Sloveniji. PrOQr^rn konference bo pokrival področja informatizacije funkcij in storitev od zdravja, sociale, pravosodja, šolstva, znanosti, kulture, okolja in prostora, kmetijstva, gospodarstva do lokalnih skupnosti. Še posebej bo poudarek namenjen horizontalnim funkcijam in skupnim gradnikom informatizacije v javni upravi, prenovi procesov in zmanjševanju administrativnih ovir. Najpomembnejši cilji konference so ponovno zbrati uporabnike, informatike in najvidnejše osebnosti, ki delujejo v javnem sektorju, vzpostaviti forum za izmenjavo izkušenj in informacij, informacijskih rešitev, pa tudi mnenj in stališč o problemih ter o aktualnih razvojnih dogajanjih na področjih e-uprave, e-pravosodja, e-zdravja. e-sociale, prenove procesov, zmanjševanja administrativnih ovir in drugih področij delovanja organizacij javne uprave, kjer potekajo prizadevanja za približanje storitev uporabnikom z uvajanjem In intenzivnejšo uporabo sredstev informacijske tehnologije. Dodana vrednost letošnji konferenci bo poudarjena mednarodna udeležba strokovnjakov s področja informatike. Posebnost konference je sprejetje deklaracije konference. Deklaracija bo predstavila povzetek dognanj konference in izrazila pričakovanja, ki jih imajo udeleženci konference do organov javne uprave in še posebej državnih organov, kar bo obenem tudi dragocena orientacija za razvojne načrte vseh subjektov javnega sektorja. Več informacij o konferenci je na voljo na spletni strani VVWW,iju2010.si. > i Pridružite se nam! http://vwifMf.iju2010.si I tju@drgstvo-informatika.si Popravek V prejšnji številki revije je v kazalu napaka, pravilna navedba je: B Vmesna poročila raziskav Borut Jereb: Princip modeliranja tveganj s segmentacijo javnosti pri upravljanju procesov 90 B Strokovni prispevki Alenka Brezavšček, Stane Moškon: Vzpostavitev sistema za upravljanje informacijske varnosti v organizaciji 101 Boštjan Kožuh: Trendi na področju poslovnega obveščanja 109 Na strani 108 zgoraj je pravilno: Alenka Brezavšček, Stane Moškon: Vzpostavitev sistema za upravljanje informacijske varnosti v organizaciji Avtorjem in bralcem se opravičujemo za neljubi napaki. Včlanite se v Slovensko društvo INFORMATIKA Pristopna izjava za članstvo v Slovenskem društvu INFORMATIKA Pravne osebe itnolnijo samo Jrugi del razpredelnice Ime in priimek Datum rojstva Stopnja izobrazbe Naziv Domači naslov Poštna št. in l