Testni centri ECDL E3 ES SE AT T«J TA ustvarjalne komunikacije IZOBRAŽEVANJE INFORMACIJSKE STORITVE TEIES - ICES EIRO :om Simply logical UNIVERZA V LJUBLJANI IfT ji RflSM 1-akulteta za pomorstvo in promet ^ M INFORMACIJSKE TEHNOLOGIJE #{vANUŠA^^ \^Contf\ct^/ /ČOPA (M) LJUDSKA UNIVERZA KOPER 1 -jj- i i junsmt uNiumzii II J RIIRSHR MIUIITR ^Micro Tcam^ Much spin UPI LJUDSKA UNIVERZA ŽALEC /uyazsurf. fai/i AWk -.E VSEBINA UPORABNA INFORMATIKA 2003 ŠTEVILKA 1 JAN/FEB/MAR LETNIK XI ISSN 1318-1882 B Uvodnik B Razprave Heinrich Reinermann: E-Gouernment and Politics 5 Izidor Golob, Tatjana VVelzer, Boštjan Brumen: Analiza in primerjaua pristopov pri gradnji podatkovnih skladišč 12 Tomaž Kralj Metode določevanja obsega funkcionalnosti 23 B Poročila Damjan Kosec: Globalni dostop do EAN identifikacijskih številk 32 Boris Milikič: Certifikat za razvijalca KML tehnologij 39 B Rešitve Franc Brcar, Andrej Kovačič: Primer uspešne informatizacije delovnega procesa 42 Matej Gomboši, Borut Žalik, Danijel Rebolj: Uporaba standarda LandKML in razširitev PmcHML 47 B Obvestila Občni zbor Slovenskega društva INFORMATIKA 52 Dnevi slovenske informatike 2003 53 B Koledar prireditev S4 fi uuuumf! j US Revijo sofinancira Ministrstvo za šolstvo, znanost in šport ra Navodila avtorjem Revija Uporabna informatika objavlja originalne prispevke domačih in tujih avtorjev na znanstveni, strokovni in informativni ravni. Namenjena je najširši strokovni javnosti, zato je zaželeno, da so tudi znanstveni prispevki napisani čim bolj poljudno. Članke objavljamo v slovenskem jeziku, prispevke tujih avtorjev pa tudi v angleškem jeziku. Vsak članek za rubriko Razprave mora za objavo prejeti dve pozitivni recenziji. Prispevki naj bodo lektorirani, v uredništvu opravljamo samo korekturo. Po presoji se bomo posvetovali z avtorjem in članek tudi lektorirali. Polno ime avtorja naj sledi naslovu prispevka. Imenu dodajte naslov organizacije in avtorjev elektronski naslov. Prispevki za rubriko Razprave naj imajo dolžino cca 30.000 znakov, prispevki za rubrike Rešitve, Poročila, Obvestila itd. pa so lahko krajši. Članek naj ima v začetku izvleček v slovenskem in Abstract v angleškem jeziku. Izvleček naj v 8 do 10 vrsticah opiše vsebino prispevka, dosežene rezultate raziskave. Abstract naj se začenja s prevodom naslova prispevka v angleščino. Pišite v razmaku ene vrstice, brez posebnih ali poudarjenih črk, za ločilom na koncu stavka napravite samo en presledek, ne uporabljajte zamika pri odstavkih. Revijo tiskamo v črno beli tehniki s folije, zato barvne slike ali fotografije kot originali niso primerne. Objavljali tudi ne bomo slik zaslonov, razen če niso nujno potrebne za razumevanje besedila. Slike, grafikoni, organizacijske sheme itd. naj imajo belo podlago. Po možnosti jih pošiljajte posebej, ne v okviru članka. Članku dodajte kratek življenjepis avtorja (do 8 vrstici, v katerem poudarite predvsem delovne dosežke. Za vsa vprašanja se obračajte na tehnično urednico Miro Turk Škraba. Prispevke pošiljajte na disketi in papirju na naslov Slovensko društvo INFORMATIKA (za M. Turk Škraba), Vožarski pot 12, 1000 Ljubljana, ali po elektronski pošti na naslov ui@drustvo-informatika.si. Po odločitvi uredniškega odbora, da bo članek objavljen v reviji, bo avtor prejel pogodbo, s katero bo prenesel vse materialne avtorske pravice na Slovensko društvo INFORMATIKA. Po izidu revije pa bo prejel plačilo avtorskega honorarja po tedaj veljavnem ceniku ali po predlogu odgovornega urednika. © Slovensko društvo INFORMATIKA, Ljubljana Naslov uredništva: Slovensko društvo INFORMATIKA, Uredništvo revije Uporabna informatika, Vožarski pot 12, 1000 Ljubljana www. drustvo-i nformati ka .si/posta 2 UPORABNA NFORMATIKA UVODNIK Spoštovane bralke, spoštovani bralci, pred petimi leti sem ob izvolitvi za predsednika Slovenskega društva INFORMATIKA pojasnil svoje videnje tega položaja: predsednik je član društva s posebnimi zadolžitvami in odgovornostmi. Društvo namreč ni niti predsednik niti izvršni odbor, je vse članstvo - smo vsi, ki smo se odločili, da bomo delovali za popularizacijo informatike. Občni zbor društva decembra 2002je bil priložnost za obračun opravljenega dela in za pogled v prihodnost - kaj naj bodo usmeritve društva, kam naj le-to naravna pozornost. Cilji, ki smo si jih zastavili pred petimi leti, so bili jasni. Da bi jih dosegli, smo se odločili za pot, ki jo označujejo odprtost, odličnost in povezovanje. Dejavnost društva ni bila več nepoznana: Dneve slovenske informatike so spoznali domači in tuji informatiki, izhajali sta reviji Informatica in Uporabna informatika. Odprtost se je dokazala kot pravi pristop: posvetovanje nastaja v sodelovanju s poslovnim svetom, obe reviji izdajata posebne številke, ki jih urejajo gostujoči uredniki. Strokovna odličnost se ne zgodi sama od sebe. Potrebno je dovolj številno zaledje strokovnjakov in način za odkrivanje njihovih dosežkov. Že imenovanje častnega predsednika dr. Antona P. Železnikarja je pokazalo, da za to čast ne bi mogli izbrati primernejše osebe. Na Dnevih slovenske informatike smo začeli javno podeljevati priznanja za dosežke posameznikom in podjetjem, v častno članstvo smo sprejeli ustanovne člane in jim podelili priznanja na svečani seji izvršnega odbora, sprejeli smo kodeks poklicne etike in pravilnik o priznanjih. S tem smo pokazali trajno naravnanost k strokovni odličnosti, ki mora biti izkazana na etično nesporen način. Povezovanje smo razumeti kot sodelovanje z organizacijami in društvi, ki delujejo na področju informatike in na sorodnih področjih v Sloveniji in tujini. Društvo je bilo sprejeto v dve najuglednejši mednarodni organizaciji, IFIP in CEPIŠ, in ECDL Foundation. Skupna iniciativa 1FIP in Slovenskega društva informatika o regionalnem sodelovanju IT STAR je postala tako privlačna, da so se ji poleg društev informatikov Italije, Madžarske in Avstrije, ki so bila soustanovitelji tega telesa, pridružila še društva hrvaških, čeških in slovaških informatikov. Vsi poizkusi niso bili tako uspešni. Kot pobudnik in soustanovitelj je društvo odigralo pomembno vlogo pri ustanovitvi slovenskega foruma za informacijsko družbo, ki se zdi, da je zdaj, ko je ustanovljen, kar nekako odveč. Ponovno izvolitev za predsednika sprejemam kot priznanje za uspešno delovanje društva in zadolžnico za prihodnja štiri leta. Tudi za prihodnost ostajajo cilji in delo vsaj na naslednjih področjih: opaženost, prepoznavnost in vpliv na strategije področja informatike, intenzivnejše sodelovanje z gospodarskimi subjekti in njihovo vključevanje v aktivnosti društva, vključevanje v mednarodne projekte, imenovanja članov društva v telesa mednarodnih organizacij, vključitev v projekt EUC1P, sodelovanje na vidnih mednarodnih dogodkih. Precej dela nas čaka v društvu. Ciljev in poti do njih je veliko; na vseh pa se moramo zavedati, da smo društvo vsi njegovi člani. Niko Schlamberger Vabilo avtorjem k pripravi prispevkov za tematsko številko revije Uporabna informatika Tema: Informacijska varnost Obseg podatkov v elektronski obliki nezadržno narašča; za okrog 250 megabytov letno na prebivalca našega planeta. Čeprav je že 95 % vseh dokumentov vsaj v eni fazi obdelanih v elektronski obliki, jih je le 3 % shranjenih v elektronskih arhivih. Z vse večjim obsegom raste tudi potreba po zagotavljanju zasebnosti in varnosti pri elektronskem poslovanju ter zaščiti podatkov. Na eni strani lahko spremljamo razvoj standardov, na primer znanega BS 7799 za področje informacijske varnosti, ki je leta 2000 dobil tudi mednarodnega naslednika ISO/IEC 17799, na drugi pa razvoj tehnologije, ki to omogoča. Predstavniki Intela na vprašanje, zakaj potrebujemo vse zmogljivejše mikroprocesorje, odgovarjajo, da preprosto zato, ker bo v prihodnje 90 % procesorske moči namenjene varovanju in zaščiti podatkov pri različnih oblikah prenosa. Kje smo na področju informacijske varnosti v Sloveniji? Na vprašanje bomo skušali odgovoriti v posebni številki revije Uporabna informatika. Prepričani smo, da ni dovolj, da se pomena informacijske varnosti zavedamo in pri tem računamo na to, da bodo komercialne rešitve kmalu naprodaj. Sprašujemo se, kakšne so znanstvene in razvojne rešitve na tem področju? S katerim znanjem razpolagata danes naši univerzi? Ali lahko v prihodnosti pričakujemo domače rešitve, s katerimi bomo lahko osvojili svoj delež svetovnega trga? Vaše prispevke pričakujemo z željo, da Uporabna informatika ostane eden izmed trdnejših mostov med stroko in prakso. Področju informacijske varnosti se v bančništvu, zavarovalništvu, zdravstvu in javni upravi že doslej nismo mogli izogniti in zagotovo razpolagamo z ustreznimi izkušnjami in znanjem. Kakšno je stanje v gospodarstvu? Kako ste k zagotavljanju informacijske varnosti pristopili v vaši organizaciji? Vabimo vas, da predstavite konkretne rešitve in koncepte, ki jih vpeljujete v vašem okolju. Informacijska varnost predstavlja temelj za nadaljnje poslovne korake in je zagotovo aktualna tema v trenutku, ko tudi v Sloveniji vse več uporabljamo svetovni splet, mobilne komunikacije in elektronsko poslovanje. Vaše prispevke z oznako »Tema2003« pričakujemo na e-naslov: ui@drustvo-informatika.si do 1. septembra 2003. Aljoša Domijan, gostujoči urednik RAZPRAVE 0 E-Government and Politics Deueloping Transformation Paths to E-Government Heinrich Reinermann German University of Administrative Sciences Speyer Post Box 14090-67324 Speyer, Germany reinermann@dhv-speyer.de Abstract What is it that makes e-Government different from earlier forms of IT-application in puhlic administration? It is mainly the potential to create new models of State and administration, based an a drastically improved electronic accessibility of persons, data, or Computer programs anywehre and anytime on the globe. Hovvever, exactly because of this spanning potential, e-Government is much more challenging than traditional EDP. The author holds that a proper understanding of true eGovernment and the necessary support by politicians and puhlic managers have yet to be developed. Povzetek E-uprava in politika - Tranzicijske poti do e-uprave Kaj je tisto, po čemer se e-uprava razlikuje od zgodnejših oblik uporabe informacijske tehnologije v javni upravi? To je predvsem sposobnost oblikovanja novih modelov delovanja države in njene uprave, ki temeljijo na bistveno izboljšani elektronski dostopnosti oseb, podatkov ali računalniških programov kjerkoli so in kadarkoli jih potrebujemo. Prav zaradi teh svojih hitro rastočih potencialov je e-uprava veliko večji izziv kot tradicionalna AGP. Avtor trdi, da se le-tej šele razviti. 1 Introduction fllthough a lot of progress in the e-government arena can be observed, most of us uvould agree that the practise of e-government does not at ali liue up to its potential yet.1 Houvever, uvhat is e-government in the first plače? Is it e-government uvhen ali puhlic agencies have their vvebsite? E-government is nothing less than the latest gene-ration of information technology (IT). Each generation before - from the original mainframe over tele-processing, Personal Computers, Client/Server Sys-tems or Local Area Netvvorks - has had an influence on sfructures and procedures of puhlic administration. In other vvords: each IT generation has enabled nevv models of administration. Just one example of this is the wave of decentralisation in the vvake of the Personal Computer. The main characteristic of e-government as the latest IT generation is the "nezv accessibility" of people, data, programs and objects (equipped with a chip) regardless of time, space, and hierarchy. This nevv accessibility is mainly due to the Internet technologies mora pravo razumevanje e-uprave in nujne menedžerske podpore like the VVorld Wide Web (WWW), E-Mail or File Transfer (FTP) vvhich became knovvn on a vvorldvvide scale in the mid nineties. Again, we can observe that this nevv IT generation enables nevv models of administration. "Nevv accessibility" means a "nevv shape-ability" of State and administration. People, data, programs, and objects vvhich vvere out of reach during earlier stages of IT applications, can be novv incor-porated into nevv e-government Solutions. Making use of boundary-penetrating potential of today's IT, making use of the nevv accessibility - that is vvhat vve should have in mind vvhen vve speak about e-government.2 Hovvever, the road to nevv models of State and administration seems to be long and rough. It contains quite a fevv barriers. Helping to overcome these and paving the vvay to e-government, are tvvo of the important tasks and duties of politics and politicians in these days. Some aspects of this task vvill be addressed in the follovving. 1 See Heinrich Reinermann andJorn von Lučke, Electronic Government in Deutschland, Speyerer Forschungsberichte Nr. 226, Speyer 2002. 2 Ali States seem to be in a similar situation here. ForSiovenia see Mirko Vintar, E-Government in Slowenien, in: Vervvaltung & Management, Juli/Au-gust 2002, p. 228-233. 2 Visions and strategies Life experience teaches us that vve leave "vvell-trodden paths" only reluctantly. Science calls this phenomenon "path dependency of human beha-viour". Since our puhlic administrations vvork quite well: why should vve leave the trodden paths of tradition and undergo the burden of change to e-government? Since our administrative information systems seem to be vvorking quite vvell: vvhat is the benefit, the pay-off of introducing e-government? Why change a vvinning team? Our governments have very seldom ansvvered such questions. Therefore, vve need more visions of e-government. For the first time and due to recent technological progress vve can treat ali participants in administrative activities as a unity: politicians, employees in ministries, agencies and offices, their clients, like citizens or companies, and their suppliers. We can share the data, vvhich are stored and pro-cessed, vvith these participants. We can integrate the procedures, vve can organize the necessary vvork betvveen application and decree, betvveen question and ansvver, as holistic supply chains. Thus State and administration can become more transparent, res-ponsive, accountable, participative, cost-efficient and Professional. With e-government vve have a much better chance to create a puhlic sector corresponding to the expectations of information society. We need more visions of e-government vvhich vvould reflect this IT potential.3 Beyond visions, our politicians must have strategies hovv to transform today's administration into e-government. It is like building a subvvay system in a large city: although this could be done step by step, one needs an overall plan of future lines, stations and connecting knots. In addition, one needs goals and resources and feedback vvhether these goals and means have proven to be realistic. When it comes to e-government, hovvever, very often such strategies are lacking.4 This is a pity considering the fact that e-government is ambitious because it tries to connect parts of administration vvhich vvere separated so far, because it involves many decision makers and because it usually requires the adaption of many lavvs and regulations. 3 Knouuledge Management Those, vvho vvant to deal vvith e-government effec-tively, need knovvledge in several areas. Hovvever, often this knovvledge is not provided because there is no institution in charge of knovvledge management in the field of e-government. In that čase, firstly, the potential of today's IT vvill probably be underestimated, the "nevv accessibility" not appreciated. Secondly, our mental ability to create nevv models of administration on the basis of modern IT or to re-invent government is rather limited anyvvay. We need stimulating examples, othervvise vve are in danger to digitalize traditional administrative patterns more or less 1:1 vvhich may lead to "e-agencies" or "e-activities" but not to "e-government". Thirdly, history has taught us that only those technical inventions vvhich meet the values and ex-pectations of society, have a chance to survive. Taking into account the change of value systems in the information society, vve should consider the follovving criteria as relevant for sustainable e-government Solutions: freedom of access to netvvorks and to information, transparency of public affairs, privacy of personal data, peer-to-peer communication, con-sensual decision-making, and professionality of each knot vvithin the nevv netvvorks of collaboration. Fourthly, knovvledge management must provide an overvievv of e-government projects nationvvide and, even better, vvorldvvide since space and time are no barriers to information systems any longer. Too often vve try to re-invent the vvheel. Instead, vve need a national division oflabor for e-government. Solutions can be and should be made available for others via the Web and their quality should be evaluated and certified. This vvould also spur competition and lead to "best of breed" applications. And fifthly, knovvledge management should raise the avvareness of the many complcmentary mcasures necessary to make e-government a success, such as organizational, financial, personal, technical or legal provisions. 4 Leadership and Management VVith the afore mentioned features e-government needs political and administrative leaders to stay in 3 See e. g. Heinrich Reinermann, Vervvaltung in der Informationsgesellschaft, in: Klaus Konig (ed.), Deutsche Vervvaltung an der Wende zum 21. Jahr-hundert, Baden-Baden 2002, p. 163-205. 4 Similar Janet Caldow, Seven E-Government Leadership Milestones, in: Posebna številka revije Uporabna informatika na temo e-uprava, Letnik 9, št. 4, str. 184-190. povver. It can be observed, hovvever, that politicians or top executives - after an initial phase of euphoric support of e-government - too soon loose their interest and turn away. This is harmful for several reasons. Leadership is necessary to define and to shape true e-government projects vvhich utilize the boundary-penetrating potential of modern IT and often cut across traditional division of labor. Motor vehicle registration by local agencies might serve as an example. Technical vehicle data provided by the manufactures are needed there, as vvell as Insurance data, data kept by national registers about motor vehicles and driving licences, statistical data et cetera. The new accessibility opens opportunities for process integration, multiple use of data resources and so on. "E-government" projects should not only justify this term by including into information systems persons, data, programs, and objects, which were formerly out of reach - they should be also convincing to the puhlic because of their added value. The development of such projects requires inno-vation netvvorks. On one hand the emplopees, who actually do the daily work, must be involved. For they know best about potential improvements and requi-rements for better Solutions. Hovvever, such an involvement of the civil Service requires enough time, equipment and qualification. And this can be granted only by political and administrative leaders. On the other hand the clients of puhlic admi-nistration need to be part of these innovation netvvorks. E-government means greater external orien-tation of puhlic agencies5, therefore it is necessary to learn from experiences and expectations of citizens, companies and other partners. Financing e-government projects is obviously another important leadership responsibility. The follovving context needs to be taken into account: modernization of puhlic administration requires innovation. Innovation costs money. Budget money is a scarce resource. For an agency it is easier to get budget allocations if it can prove corresponding savings and revenues. Savings in resources often are possible, indeed. To realize them, hovvever, an e- government project needs to be considered a business čase: vvho benefits from the project and could con-tribute financially? Are fees justified? Which savings are possible? A prerequisite for this to happen is, of course, that the political and administrative leaders remain involved in e-government projects to the end in order to shift the svvitches and to back unpleasant decisions. 5 Systematization of the Public Sector As far as the substance of e-government is concerned, politicians and politics have to make sure that the projects deal vvith tvvo fields: systematization of the puhlic sector, and nevv forms of governance vvhich have become possible. The nevv accessibility of persons, data, programs and objects means, vvithout any doubt, a big step forvvard. Hovvever, at the same time it becomes evident hovv large has actually become the varietp of our public institutions over time. Obviously, this is especially true for federal States vvith autonomous local communities. Consequently e-government is faced vvith the task of bringing a certain degree of order mainly into data and procedures. Thus e-government means stock-taking, transparency, clearing-up, complementation, correction, harmoni-zation, standardization, reorganization et cetera. VVithout a certain level of order the boundary-penetrating potential of modern IT cannot be utilized. The Internet is in other vvords the end of many technical problems, but at the same time the begining of many organizational problems. So far Internet technologies have been used to help IT experts, novv vve need to focus vvith our support on managers and organizers. VVith respect to data this means more exchan-geability via XML, more compatibiliti/ in terms of syntax, semantics and pragmatics of administrative data, but also the digitalization of the files, vvhich are stili stored analogously, and the vvarranty of quality as far as the content of the Internet is concerned. As regards procedures e-government means star-ting processes in order to integrate former islands of IT applications and to utilize nevv softvvare concepts like 5 See also Mirko Vintar, Effective Approaches to Reform of the Government/Citizen Relationship, in: Proceedings of the Second NISPAcee Civil Forum: Openness and Transparency in Governance, Maastricht 1999. middlevvare or vveb Services for application inte-gration within and betvveen puhlic agencies or e ve n pri vate companies.6 But there is a big question which has to be solved by our politicians: To vvhat extent do we really want "seamless government"? For a long time many have called for "unity of administration", but since it has become possible, we need to decide vvhich of the built-in cracks in the flow of Information we want to keep up in order to prevent side-effects vvhich are considered harmful. 6 Neuu Forms of Gouernance Poli tičal impuls and support is also necessary in order to realize the potentials of today's IT for the new forms of governance. The input legitimacy of puhlic activities as well as their output legitimacy can be raised this way. In other vvords, there is room to improve the effectiveness of the State and administration from two sides: by making better use of Information and knovvledge for puhlic decisions and by delivering better Service at higher productivity. In order to demonstrate some nevv models of puhlic action here, let us look briefly at each side of a triangle betvveen citizens (meant to include business companies and other clients), politics and parliament and government, administration and justice. Citizens/ politics: This side of the triangle repre-sents the opinion-making phase of puhlic decision-making. The Internet has already had a deep impact there.7 Our puhlic institutions have become transparent as never before. But improvement is stili possible. Imagine a "democracy button" on the home-pages of each agency, allovving you to get information on ali relevant lavvs, tasks, organization, forms, goals, impacts, outputs or costs. E-mail is also being used very frequently, but stili needs improvement in order to make sure that each petition by a Citizen is con-firmed immediately and directed to an employee in charge vvhere the suggestions will be dealt with and the results communicated back to the citizens. Such procedures also require electronic file processing with nevv requirements, e. g. for data security, for long-term filing etc. Politics/administration: This side can benefit a lot from parliamentary and leadership information systems. Given the high degree of Computer pene-tration in our societies, much more digital data is available vvhich reflect the effects, puhlic activities are having. In accordance vvith the ideas of Nevv Public Management these data can be fed into planning, decision-making, moderation and evaluation procedures. It is a rather nevv situation that - via the Internet - citizens have almost the same access to information as politicians and the civil Service, and that citizens are able to check if this information is used in the political processes. Rather nevv is also the situation that persons in a certain agency, in charge of vvorking out or amending a lavv or a statute, novv - via the Internet - can look for others, dealing vvith a similar process, vvhose experience can be utilized by telecooperating vvith them. Administration/citizens: A final look at the third side of our triangle also reveals nevv models of puhlic administration, here regarding production and distribution of Services. The most important is perhaps the fact that modern IT has reduced the "ground adhesion" of puhlic administration. This is expressed by the term "ubiquitous or u-government". Due to the nevv accessibility, many puhlic Services can be handled anyvvhere - think of putting a laptop and a celi phone in a car and delivering Services on the spot in a hospital or in an elderly home. Visible effects of u-government vvill be: more decentralization in respect of "front offices" and more concentration in respect of "back offices". Multi-channel access is another area of nevv models of puhlic administration. Due to modern IT, physical access to agencies, city halls and other outlets like citizens offices, but also call centers and online-tele-administration have meanvvhile become a reality. The Citizen is given a choice hovv to do business vvith puhlic administration. VVith respect to online-administration, portals represent a nevv phenomenon: they organize information, commu-nication and transaction around life situations (like marriage, building a house or retirement) or around business situations (like founding a company or getting a concession to run a firm). A pre-condition for 6 See Mirko Vintar, Von Business Process Reengineeringzu VVorkflovv Management in der Regionalvervvaltung, in: Verwaltung& Management, Marž/ April 1998, p. 99-104. 7 See e. g. Claus Leggewie and Christa Maa s (eds.), Internetpolitik - Von der Zuschauer- zur Beteiligungsdemokratie, Kol n 1998. effective multi-channel access, hovvever, is a res-pective knowledge management because Information input via one channel must be available simul-taneously at ali others if necessary. 7 Sociopolitics and E-Government VVhereas the foregoing paragraphs have dealt with administrative politics, the concluding remarks vvill concentrate on socio-, economic, technological and legal policies. Both fields taken together constitute "e-governance" understood as ali efforts of State and administration to čope vvith today's "digital revo-lution". As far as sociopolitics is concerned, the main challenge is to avoid a "digital divide". Qualification in exploiting and handling modem IT is among the first public tasks which come to our minds. New models of public administration are enabled by IT but they must be created and applied by human beings. In addition to qualification, physical access of ali citizens to electronic modes of public administration must be secured - either directly or indirectly via public kiosks, call centers or Citizen offices. Generally e-government should be accompanied by a social dialogue lest IT is better developed than our avvareness of the goals we want to pursue by IT. Such a social dialogue has begun e. g. on the European level vvith the so called "Bangemann Report" 1994 or vvith the initiative "eEurope2002" by the European Commission and on the national levels as vvell, but needs to be intensified a lot by our politicians in order to engage vvide sec-tions of our populations. 8 Economic Policy A nation vvanting to be at the forefront of e-government needs a nevv layer of companies capable to deliver the necessary products, Services and data. Hardvvare and Softvvare, application and vveb Service development, user support, the creation of useful vveb content and the refinement of ravv data for nevv purposes represent a nezo class of Services Corning along vvith e-government. Politics can do a lot to promote these nevv companies like the advancement of research and development, encouragement of bu-siness foundations, financial support, placing of orders, engaging nevv companies in e-government products, reduction of bureaucratic and legal barriers or ensuring that a qualified labor force is available. Another important field for economic policy vvith respect to e-government is to stimulate competition on the telecommunication market in order to keep the access ratcs to the Internet on an affordable level. E-government needs participation of vvide sections of population and this participation depends to a high degree on the cost the citizens and companies have to bear. 9 Technology Polici/ Most of the time the influence of IT on govemment is being discussed. Hovvever, the necessary influence of govemment on IT should not be overlooked either. Information systems ready for e-government must be easy to handle, fast and secure. Politicians should direct respective demands at Computer and telecommunication industry and define respective procurement requirements. Computer netvvorks have become an important part of our critical national infrastructures. They need appropriate protection. And the citizens vvill not take to e-government on a broad scale if they do not trust that their data are secure. Public key infrastructures, vvhich can solve many problems here, are technically ready and available, but seem to need strong sup-portive measures before they vvill be used on a vvide scale. If vve vvant to stimulate e-government, broadband networks vvill have to be introduced nationvvide in order to speed up e-government applications. 10 Legal Policy Legal policy is another field, vvhere vve can observe that some of the analogous structures of our societies must be adapted to the nevv digital models of public administration. An adequate legal infrastructure is a prerequisite for the development of effective transformation paths to e-government. By the vvay, most of us vvould agree by novv that the Internet, by no means, is a space vvithout lavv. The established system of lavv is naturally in alignment vvith our traditional communication media. Therefore, quite often further development of lavvs, rules and regulations vvithin e-government is ne-cessary. Handvvritten personal signatures are a typical example. Today they can be substituted by electronic signatures, but this requires the amendment of quite a fevv lavvs. Hovvever, a vvord of vvarning seems to be appropriate here, as vve should not be "more catholic than the pope" in making electronic signatures a pre-requisite for citizen/administration communication. In the majority of cases easier forms of authentification, like passwords or the knovvledge of context, will suffice and thus reduce the barriers to e-government. Freedom of information is another example vvhich concerns legislation. With most of the data in puhlic agencies digitized and accessible via the Internet, the fundamental question is being posed vvhich data should be public and vvhich data should be secret. In most States respective lavvs have been released already or are on their way. A third and final example are the privaci/ lavvs. They are also being amended in many States right novv because of nevv dangers but also because of new ways of protection brought about by modem IT like encryption, chipcards, or anonymity. Because technical progress is fast but the process of amending lavvs slovv, experimental clauses should be used more often. 11 Character of Political Decision-making The transformation to e-government can be com-pared to a mathematical function vvith e-government being the dependent variable and vvith the afore mentioned influence factors being the independent variables. But often mathematical functions also contain parameters or constants, vvhich also influence the result, but are difficult or impossible to change. In the čase of transformation of e-government some typical properties of our political decision processes resemble those parameters or constants. Unfortunately the time horizon of politicians in a parliamentary democracy is rather short and very often coincides vvith the date of the next elections. This is harmful considering the fact that e-government needs long-term strategies. Another parameter is lack of competition for most of our public agencies, and this means that they can survive vvithout product or process innovation. Therefore the incentive to turn to nevv models of behaviour is less frequent than for private enterprises in a market economy. Thirdly, in some States a "denatured federalism" can be observed. It is characterized by the fact that most major public decisions are coordinated over and over again betvveen federation, States, and local communities. This takes a long time and the results are often meager. You might call this parameter the "convoy syndrom" because it is the slovvest vessel that determines the pace of progress. If, on the other hand, agencies become impatient and try a solo attempt, their electronic connectivity to other institutions is in danger vvhereas - as vve have stressed above - the "nevv accessibility" is one of the most important features of e-government. Politics must strike the right balance here. 12 E-Gouernment and the Electorate The message of this paper - in a nutshell - has been: exploitation of the "enabling technology" available today requires an "enabling government". About seven years after the VVorld Wide Web has made the Internet technologies knovvn vvorldvvide, vve have only scratched the surface of the e-government potential. Considering the size of the task ahead of us this is not alarming. But novv vve need a breakthrough. Will politics and politicians take čare of this? According to political scientists, like David Easton, politicians supportively react to demands.8 But: vvhere are the demands for e-government, loudly expressed by our electorates? So far, elections have not been decided by issues like e-government. Is it imaginable at ali that just public administration given its image becomes a campaign issue? At this point vve realize that the hurdles to e-govemment vve have dealt vvith before, are standing in a circle because to raise the interest of politicians via the electorate requires the development of convincing visions of a vvell functioning state and administration in the information society. In order to make this happen several levers need to be operated, like the media, consultants, scientists, interest groups, employees, clients and, of course - acting politicians. Only then e-government vvill become a reality. References Heinrich Reinermann and Jorn von Lučke, Electronic Government in Deutschland, Speyerer Forschungsberichte Nr. 226, Speyer 2002. Mirko Vin tar, E-Government in Slovvenien, in: Vervvaltung & Management, Juli/August 2002, p. 228-233. 8 David Easton, A Systems Analysis of Political Ufe, Nevv York 1964. Heinrich Reinermann, Vervvaltung in der Informationsgesellschaft, in: Klaus Kčnig (ed.), Deutsche Vervvaltung an der VVende zum 21. Jahrhundert, Baden-Baden 2002, p. 163-205. Janet Caldow, Seven E-Government Leadership Milestones, in: Posebna številka revije Uporabna informatika na temo e-uprava, Letnik 9, st. 4, str. 184-190. Mirko Vintar, Effective Approaches to Reform of the Government/ Citizen Relationship, in: Proceedings of the Second NISPAcee Civil Forum: Openness and Transparency in Governance, Maastricht 1999. Mirko Vintar, Von Business Process Reengineering zu VVorkflovv Management in der Regionalvervvaltung, in: Vervvaltung & Management, Marz/April 1998, p. 99-104. Claus Leggewie and Christa Maas (eds.), Internetpolitik - Von der Zuschauer - zur Beteiligungsdemokratie, Kol n 1998. David Easton, A Systems Analysis of Political Life, New York 1964. Heinrich Reinermann holds the Chain for Computer Systems in Public Administration at the German University of Administrative Sciences Speyer. Among his fields of interest are: New Public Management and Electronic Governance. Since 2002 he is also member of editorial board of Uporabna informatika. Slovensko društvo INFORMATIKA zbira na podlagi 53. člena statuta in pravilnika o priznanjih predloge za priznanja Slovenskega društva INFORMATIKA 1. Priznanje se lahka podeli posamezniku ali pravni osebi za: ■ dosežke na področju uporabne in znanstvene informatike ter vidne prispevke na področju razvoja informacijske družbe in razvoja novih načinov in tehnologij dela na področju informatike • dolgoletno uspešno delo v društvu ali v drugih društvih, ki so sodelovala z društvom pri programskih vprašanjih • razvoj mednarodnega sodelovanja in izmenjavo dosežkov na tem področju • izjemne dosežke na področju razvoja konceptov, programskih orodij, naprav in tehnologij v zvezi z informatiko ■ uspešno sodelovanje z društvom • publicistično delo na področju informatike in informacijske družbe in • izjemne dosežke na področjih, ki zadevajo vprašanja informatike. 2. Predlog mora vsebovati: • podatke o prejemniku priznanja ■ opis dosežka . predlagano priznanje • dokazila o dosežku ■ podatke o predlagatelju Za priznanje je mogoče predlagati posameznike in pravne osebe, posebej pa opozarjamo, da je v pravilniku predvideno tudi priznanje za študentski dosežek. Podrobni pogoji so navedeni v pravilniku o priznanjih na naslovu http://www.drustvo-informatika.si. Predloge pošljite do vključno 4. aprila 2003 na naslov: Slovensko društvo INFORMATIKA 1000 Ljubljana, Vožarski pot 12 z oznako “PRIZNANJA 2003" ali po elektronski pošti na naslov info@drustvo-informat:ika.si. Predloge bo pregledala, ocenila in o njih odločila komisija za priznanja. Priznanja bodo javno podeljena na otvoritvi posvetovanja Dnevi slovenske informatike 2003 dne 1B. aprila 2003. RAZPRAVE 0 Analiza in primerjava pristopov pri gradnji podatkovnih skladišč Izidor Golob, Tatjana VVelzer, Boštjan Brumen Fakulteta za elektrotehniko, računalništvo in informatiko Univerza v Mariboru, Smetanova 17, 2000 Maribor {izidor.golob, vvelzer, brumen}@uni-mb.si Izvleček Podatkovno skladiščenje s svojimi strukturami in procesi, prirejenimi v podporo poslovnemu procesu, ter podatki, prečiščenimi in integriranimi v procesu migracije podatkov, omogoča celovit pogled na podatke posamezne organizacije. V prispevku analiziramo in primerjamo tri temeljne pristope pri gradnji podatkovnih skladišč. Glede na izbrani pristop je rezultat centralizirana, porazdeljena ali federativna zgradba podatkovnega skladišča. Rezultati primerjave kažejo, da se pristopi bistveno razlikujejo po osnovnih sestavnih elementih, uporabljenem podatkovnem modelu in metodologiji izgradnje. Na podlagi rezultatov podajamo smernice za izbiro optimalnega pristopa pri gradnji podatkovnega skladišča za določeno organizacijo. Splošna najboljša rešitev ne obstaja, saj ima vsak pristop svoje posebnosti, tako dobre kot slabe. Abstract Analysis and Comparison of Apprnaches to Building Data VVarehouses Data vvarehousing along vvith its structures and processes, is designed to support the business process. A data vvarehouse, containing data, cleansed and integrated in the data migration process, gives an integrated view on the enterprise's business data. In this paper three basic approaches to building data vvarehouse are analyzed and compared. Depending on the approach chosen, the result is centralized, distributed or federated data vvarehouse architecture. The results show that there is a fundamental difference among the presented approaches due to differences in concepts, data models and methodology used. Based on the results, a method for determining an optimal approach to building data vvarehouse for given enterprise is given. In general, the perfect approach does not exist as each one has its own strengths and vveaknesses. 1 Uuod Pri upravljanju informacij podjetja ločimo dve vrsti računalniških sistemov: za sprotno obdelavo transakcij (OLTP, angl. on-line transaction processing) in analiziranje. Sistemi za sprotno obdelavo transakcij, ali krajše transakcijski sistemi, podpirajo procese z značilnimi transakcijskimi procesnimi sistemi, ki s svojimi operativnimi podatkovnimi bazami zajemajo transakcije - poslovne dogodke. Sistemi za analiziranje so povezani z analizo informacij o osnovnih procesih in njihovim nadzorom s sredstvi sistemov za upravljanje informacij. Osnovna značilnost operativnih podatkovnih baz iz sistemov za sprotno obdelavo transakcij so podrobni atomarni podatki, shranjeni v stabilnih normaliziranih podatkovnih strukturah, optimiziranih za zajem transakcij ter vpis in ažuriranje podatkov [Barqufn 1997; Anahory 1997; Bischoff, 1997]. Operativni sistemi in sistemi podatkovnih skladišč nosijo številne nasprotne značilnosti. Če jim pridružimo še omejitve strojne in programske opreme, operativne podatkovne baze niso dovolj prilagodljive hitro se spreminjajočim zahtevam uporabnikov (največkrat so to vodilni delavci - poslovodstvo, upravljavci ali analitiki), ki želijo informacije za sprejemanje odločitev v sprejemljivem času. Prav podatkovno skladiščenje (angl. data vvarehousing) s svojimi strukturami in procesi, prirejenimi v podporo poslovnemu procesu (podatkovna skladišča so oblikovana za kompleksna ad hoc povpraševanja) ter podatki, prečiščenimi in integriranimi v procesu migracije podatkov, omogoča tistim, ki odločajo in skrbijo za razvoj podjetja, celovit pogled na podatke posamezne organizacije ne glede na uporabljene strojne in programske rešitve v posameznih operativnih okoljih. V sinergiji z dodatnimi programskimi analitičnimi orodji, izmed katerih je še posebej pomembna sprotna analitična obdelava (angl. On-Line Analytical Processing - OLAP), ter podatkovnim rudarjenjem predstavljajo vrh današnje informacijske podpore, saj omogočajo celovit pogled na poslovanje organizacije skozi različne vidike. Pomen podatkovnega skladiščenja, dosedanje uspehe in pripravljenost investitorjev v še večje investicije potrjujejo tudi zadnja poročila, ki napovedujejo rast investicij iz 37,4 milijard USD, kolikor so znašale investicije v podatkovno skladiščenje v svetovnem merilu leta 1999, na 150 milijard USD leta 2003 [Hammond 2000], kar predstavlja 40-odstotno letno rast. Podatkovno skladiščenje kljub uspešnim izdelkom še ni zrela disciplina. Predvsem zaradi napredkov v strojni in programski opremi se nenehno pojavljajo nove rešitve in zgradbe. Ena izmed najpomembnejših odločitev, s katero se mora soočiti vsak načrtovalec podatkovnega skladišča že na začetku, je izbira primernega pristopa pri gradnji podatkovnega skladišča. Izbira pristopa je kritična, saj le-ta določa podatkovni model, vlogo področnih skladišč ter sosledje korakov v razvojnem ciklu. Glede na izbran pristop je rezultat centralizirana, porazdeljena ali federativna zgradba podatkovnega skladišča. Kljub navedenemu je prav na področju poznavanja in razumevanja pristopov pri gradnji podatkovnih skladišč največ zmede; dodatno jo povzročajo še avtorji in zagovorniki posameznih pristopov s svojimi opozorili o neprimernosti ostalih. Cena projekta podatkovnega skladiščenja je v primerjavi z ostalimi projekti na področju informatike visoka, saj vključuje poznavanje podrobnosti obstoječih in novih sistemov. Zato je strah pred nepravilno izbiro pristopa utemeljen. 1.1 Metodologija raziskave Preliminarna raziskava je pokazala, da zaradi razlik med poimenovanji, med razvojnimi cikli in med izhodišči neposredna primerjava pristopov pri gradnji podatkovnih skladišč, ki rezultirajo v različnih zgradbah podatkovnih skladišč, ni možna. Zato je po uvodni predstavitvi izvedena identifikacija stičnih točk pristopov. Le na podlagi identificiranih medsebojno primerljivih elementov je namreč možno izvesti veljavno primerjalno analizo. Na podlagi njenih rezultatov so identificirane želene in neželene lastnosti posameznih pristopov in iz njih izhajajočih zgradb. Ugotovitve so strnjene v tabelo, ki predstavlja metodo za določitev optimalnega pristopa pri gradnji podatkovnega skladišča za posamezno organizacijo glede na parametre. 2 Pristopi pri gradnji podatkovnih skladišč 2.1 Centralizirani pristop V središču centralizirane zgradbe, ki je rezultat uporabe centraliziranega pristopa gradnje podatkovnega skladišča je podatkovno skladišče zaključenega organiziranega sistema. Le-to »hrani« področna skladišča, polni pa se iz operativnih podatkovnih baz ter operativnega podatkovnega skladišča (slika 1). Največji zagovornik takšne zgradbe je Inmon [Inmon 1996,1999b]. Strogo rečeno so v taki zgradbi področna skladišča odvisna struktura, saj so podatki pridobljeni oz. naloženi izključno iz podatkovnega skladišča organizacije. 2.1.1 Načrtovanje in gradnja centraliziranega podatkovnega skladišča Razlike med operativnim svetom in svetom podatkovnega skladišča so izrazito vidne tudi iz opisa razvojnih ciklov. Operativno okolje je podprto s klasičnim razvojnim ciklom, ki je vodeno s strani zahtev. Tako je potrebno najprej razumeti zahteve, šele nato preidemo v faze načrtovanja in razvoja. Razvojni cikel podatkovnega skladišča je podatkovno voden, saj pričnemo s podatki. Po integraciji podatkov pogledamo, če je potrebno njihovo dodatno ugla-ševanje in to po potrebi tudi storimo. Rezultati programov so analizirani in šele na koncu razumemo Q 0 področna I—] skladišča integracija / transformacija podatkovno skladišče podatkovno rudarjenje aplikacije operativna podatkovna shramba Slika 1: Centralizirana podatkovno skladišče zahteve. Vrstni red posameznih faz razvojnega cikla operativnega okolja in okolja podatkovnega skladišča je popolnoma obrnjen. 2.1.2 Podatkovni model v centralizirani zgradbi podatkovnega skladišča Struktura podatkovnega skladišča je normalizirana. V maloštevilnih primerih je struktura le delno denor-malizirana. Delno denormaliziranost, torej delno odstopanje od zahtev po doseganju tretje normalne oblike, lahko uvedemo v naslednjih primerih: . Kjer je znano, da se bodo redundantni podatki redno uporabljali skupaj z drugimi podatki in zato dopuščamo redundantnost. . Kjer so enkrat izračunani podatki večkrat uporabljeni (npr. shranimo letno bruto plačo, čeprav je to izpeljan, izračunljiv podatek). . Če sklepamo, da bodo skupine podatkov normalno in pogosto uporabljene skupaj, formiramo zanje nov skupen prostor. Tako lahko npr. mesečne podatke za mesece januar, februar itn. fizično nakopičimo na eno samo lokacijo in s tem poenostavimo in povečamo hitrost fizičnega dostopa. . Če sklepamo, da se verjetnost dostopa do posameznih podatkovnih elementov (atributov) pri uporabi bistveno razlikuje in zato izvedemo ločitev podatkov. Kljub morebitni denormaliziranosti strukture oziroma podatkovnega modela podatki obdržijo značilnost močne normaliziranosti, saj delna denormalizacija ne odraža zahtev posameznega oddelka, temveč le izboljša učinkovitost vsem uporabnikom. Podatki v podatkovnem skladišču imajo različno stopnjo granularnosti. Manj podrobni (detajlni) so podatki, višja je stopnja granularnosti. Določanje granularnosti je pomembno, saj stopnja granularnosti bistveno vpliva na količino podatkov in na vrsto poizvedb, na katere je možno odgovoriti. V nekaterih primerih iz razloga čim hitrejšega dostopa in zmožnosti po analizi čim bolj podrobnih podatkov hranimo podatke dveh različnih stopenj granularnosti. Za osnovno modelirno tehniko uporabljamo E-R model. 2.1.3 Področno skladišče in operativna podatkovna hramba v centralizirani zgradbi podatkovnega skladišča Operativna podatkovna hramba je v predstavljeni strukturi eden izmed podatkovnih virov podatkovnega skladišča. Je hibridna struktura, ki izpolnjuje tako operativne kot tudi analitične zahteve: zagotavlja majhen transakcijski odzivni čas, hkrati pa je tudi prostor integriranih podatkov. V primerjavi s podatkovnim skladiščem izpolnjuje zahteve po predmetni usmerjenosti in integriranosti, ne vsebuje pa zgodovinskih podatkov, temveč le trenutne, aktualne in detajlne podatke določene organizacije. Nasprotno kot podatkovno skladišče pa je operativna podatkovna hramba lahko ažurirana na podlagi transakcij [Inmon 1999b]. Izhajajoč iz zgradbe centraliziranega podatkovnega skladišča (gl. sliko 1) je osrednje podatkovno skladišče edini vir podatkov za področno skladišče. Področno skladišče ne ločuje med podatki, ki so prišli v podatkovno skladišče neposredno iz operativnega sveta ali preko operativne podatkovne hrambe. Osnovne značilnosti, ki ločijo področno skladišče in podatkovno skladišče so naslednje: . podatkovno skladišče vsebuje veliko količino zelo podrobnih podatkov iz daljšega obdobja (npr. 10 let) v enostavnih strukturah, področno skladišče pa le podatke omejene vsebine, s takšno stopnjo granularnosti in iz takega časovnega obdobja, kot narekujejo potrebe oddelka [Inmon 1999a]; . strukture podatkovnega skladišča so namenjene neznani uporabi, strukture področnega skladišča pa so načrtovane za specifične, znane namene; . področna skladišča so manjša in . podatkovno skladišče vsebuje tako podatke nižje granularnosti kot tudi sumarne podatke poslovanja celotne organizacije. 2.2 Pristop gradnje porazdeljene zgradbe podatkovnega skladišča Področno skladišče je podmnožica podatkovnega skladišča določene organizacije. V porazdeljeni zgradbi je podatkovno skladišče le unija področnih skladišč. Področno skladišče igra ponavadi vlogo oddelčnega, krajevnega ali funkcionalnega podatkovnega skladišča in podpira eno ali več specifičnih področij. Tipično porazdeljeno zgradbo, katere največji zagovornik je Kimball [Kimball 1998], prikazuje slika 2. Organizacija kot del iterativnega procesa gradnje podatkovnega skladišča zgradi vrsto porazdeljenih področnih skladišč in jih na koncu poveže v logično podatkovno skladišče celotne organizacije. Hackney tak pristop brez zadržkov poimenuje "od zgoraj navzdol" [Hackney 2000a]. izvorni podatki podatkovno skladišče neodvisno področno skladišče neodvisno področno skladišče neodvisno področno skladišče transformacija Slika 2: Porazdeljeno podatkovno skladišče Področna skladišča postavljajo specifične oblikovalske zahteve. Vsako področno skladišče mora biti predstavljeno z dimenzijskim modelom, ki mora biti znotraj enotnega podatkovnega skladišča skladen. Skladna dimenzija (angl. conformed dimension) je dimenzija, za katero je značilno, da ima enoličen pomen, ne glede na to, s katero tabelo dejstev jo povežemo. Zagotavlja tudi, da je podatek predstavljen le enkrat. Glavna naloga skupine načrtovalcev podatkovnega skladišča pri načrtovanju porazdeljene zgradbe podatkovnega skladišča je vzpostavitev, objava in vzdrževanje skladnih dimenzij, kot tudi zagotavljanje njihove dosledne uporabe. Brez upoštevanja koncepta skladnih dimenzij podatkovno skladišče ne more delovati kot integrirana celota. 2.2.1 Podatkovni model v porazdeljeni zgradbi podatkovnega skladišča Struktura področnih skladišč je denormalizirana, v določenih primerih le delno normalizirana. Osnovni podatkovni model je dimenzijski, za osnovno mo-delirno tehniko pa uporabljamo dimenzijsko modeliranje. Dimenzije, še posebej skladne, imajo navadno atomarne (granularne) podatke. To pomeni, da morajo biti tudi osnovne tabele dejstev na najnižjem nivoju, ki obstaja med pripadajočimi dimenzijami. To dejstvo olajšuje prehod podatkov iz operativnih podatkovnih baz v tabele dejstev. 2.2.2. Ostale posebnosti Zgradba omogoča razmeroma hitro gradnjo prvega področnega skladišča, ki ima visok poslovni (pozitivni) vpliv oziroma pomen, hkrati pa jo je razmeroma enostavno implementirati. Potrebe organizacije po analizah so razvidne iz poslovnih zahtev, od koder nato izhaja tudi določitev prioritet. Tak pristop je zelo pomemben, saj v najkrajšem času pridobimo delujoče podatkovno skladišče, s tem pa podporo zagovornikov s strani vodstva in uporabnikov. Le-to omogoča naslednjo iteracijo, t. j. gradnjo novega področnega skladišča. 2.3 Federativni pristop h gradnji podatkovnega skladišča Federativno podatkovno skladišče (angl. federated data vvarehouse) je hibridna rešitev, temelječa na skupnem poslovnem modelu (angl. common business model) in področjih priprave informacij (angl. infor-mation staging areas), ki so v skupni rabi [VVhite 2000; Hackney 2000a, b, c, d] (slika 3). Takšna zgradba zagotavlja nizke stroške in hitro povrnitev vloženih sredstev z uporabo neodvisnih področnih skladišč, pri čemer kasnejša podatkovna integracija ni potrebna. izvorni podatki metapodatki področja priprave podatkov transformacija neodvisna področna skladišča centralizirano podatkovno skladišče odvisna področna skladišča metapodatki skupni informacijski model orodja OLAP Slika 3: Federativno podatkovno skladišče 2.3.1 Gradnja federativnega podatkovnega skladišča Gradnjo federativnega podatkovnega skladišča bi lahko strnili v šest korakov [Hackney 2000b]: (1) Dokumentiranje obstoječih sistemov podatkovnih in področnih skladišč rezultira v entitetnem diagramu, ki prikazuje sisteme in vse podatkovne tokove med njimi, vključno s tokom meta podatkov. (2) Dokumentiranje obstoječih sistemov na nivoju toka podatkov vključuje podatkovni tok, pripadajoče korake transformacije in integracije ter repozitorije meta podatkov. Vsak podatkovni element mora biti ocenjen v smislu kakovosti, razpoložljivosti in enostavnosti dostopa. (3) Določitev podatkov, ki prinašajo dodano vrednost in imajo dovolj visok pomen oziroma vpliv v celotnem sistemu. V tem koraku se išče posebna, najbolj pomembna podatkovna integracija. (4) Zbiranje kandidatov iz prejšnjega koraka in analiziranje njihovega vpliva in možnosti za implementacijo. V tem koraku so tudi izbrani ustrezni kandidati z najnižjo stopnjo tveganja, taki, ki tudi največ prispevajo k izpolnitvi strateškega načrta organizacije. Pomembno je, da so izpuščeni tisti, ki so zanimivi le za ožji krog (čeprav poslovnih) uporabnikov. (5) Implementacija orodja za zajem, transformacijo in polnjenje podatkov, ki podpira skupen, globalni repozitorij metapodatkov sistemov podatkovnih in področnih skladišč. (6) Gradnja manjše, strogo namenske in usmerjene iteracije federativne zgradbe, katerega osnova je v četrtem koraku izbran kandidat. Sledi dokumentiranje in objava doseženega z namenom, da se pridobi ali obdrži politično volja, potrebna za nadaljnje iteracije. Pomembno je, da so posamezne iteracije majhnega dometa, osredotočene na najbolj pereče točke poslovanja, merljive (moramo biti sposobni oceniti uspeh) in čimbolj tržne. Opisani pristop podpira iterativni razvoj podatkovnega skladišča, ki vsebuje neodvisna področna skladišča. Ključni element podatkovne integracije je skupni poslovni model poslovnih informacij, ki ga polni in upravlja podatkovno skladišče. Izdelava skupnega poslovnega modela zagotavlja doslednost pri uporabi imen podatkov in poslovnih definicij v vseh procesih podatkovnega skladišča. Skupni poslovni model se ažurira z vsakim novim primerkom področnega skladišča. Kadar obstoječi podatki v operativnih sistemih narekujejo načrtovanje področnih skladišč, uporabimo skupni poslovni model (in ga po potrebi ažuriramo), vzporedno z razvojem podatkovnih modelov podrejenih področnih skladišč. V okoljih, kjer so vodilo poslovne zahteve uporabnikov, najprej razvijemo skupni poslovni model in ga nato uporabimo za razvoj podatkovnih modelov podrejenih področnih skladišč. Tak razvoj omogoča več obstoječih rešitev. Pri uporabi analitične programske opreme "iz škatle" (kot je npr. tipično orodje OLAF) pa je pomembno to, da je možno spremeniti poslovne modele in jih integrirati v skupni poslovni model organizacije. Razvoj skupnega poslovnega modela in pripadajočih podatkovnih modelov se lahko izvede hitreje, če uporabimo že vnaprej pripravljene, a spremenljive vzorci poslovnih področij (angl. business area templates). Le-ti dokumentirajo poslovne metrike in pravila, ki se uporabljajo pri analizi in modeliranju poslovnega procesa. Ob dodajanju novih področnih skladišč v sistem podatkovnega skladišča se obstoječe rutine za zajem in podatki v področjih priprave po potrebi ponovno uporabijo oziroma izboljšajo. Tak način še posebej dobro deluje v federativnem podatkovnem skladišču, kjer lahko skupni poslovni model uporabimo pri načrtovanju področij priprave in programskih rutin za zajem podatkov. 3 Primerjava pristopov Za določitev učinkovitega in ustreznega pristopa pri gradnji podatkovnega skladišča, katerega rezultat je zagotovljen najmanjši odzivni čas in učinkovita izraba virov, je nujno potrebno poznavanje lastnosti posameznih pristopov, pozitivnih in negativnih. Pravilna odločitev zmanjša tveganje pri novih projektih podatkovnega skladiščenja (po nekaterih virih [VVells 2000] propade kar 70 % projektov podatkovnih skladišč), prispeva k izboljšanju obstoječih podatkovnih skladišč z novimi področnimi skladišči zaradi odprtosti sistemov ter omogoča prilagoditev preveč centraliziranih podatkovnih skladišč, ki ne morejo učinkovito delovati v nehierarhičnem okolju, na bolj federativno zgradbo. Pri primerjavi pristopov smo zajeli tiste elemente, ki določajo zgradbo: osnovne komponente, uporabljen podatkovni model, razvojni cikel ter zgradbo meta podatkov in način njihovega upravljanja. 3.1 Osnovne sestavne komponente Predstavljene zgradbe, ki so posledica uporabe izbranega pristopa, vsebujejo različne osnovne komponente. Zaradi prekrivanja nekaterih komponent, ki imajo v vseh sistemih identično vlogo in jih lahko zato pri primerjavi izpustimo, se omejimo le na sistem podatkovnega skladišča in pri tem privzamemo, da so vedno prisotni: • vhodni operativni sistemi ter . orodja za zajem, transformacijo in polnjenje. V centralizirani (C) zgradbi podatkovnega skladišča lahko tako nastopajo naslednje komponente: osrednje podatkovno skladišče, področna skladišča, posebna namenska področna skladišča, namenjena raziskovanju in operativne podatkovne shrambe. V porazdeljeni (P) zgradbi podatkovnega skladišča samostojno nastopajo le področne shrambe. Federativna (F) zgradba dopušča združevanje samostojnega podatkovnega skladišča ali sistemov podatkovnih skladišč, področnih shramb, orodij za podatkovno rudarjenje in analitičnih aplikacij, katerih tipični predstavniki so orodja OLAP. Tabela 1 prikazuje možne udeležene samostojne komponente v posameznih zgradbah: 3.1.1 Diskusija Pomembna razlika med pristopi je v pojmovanju vloge področnega skladišča. V centralizirani zgradbi je področno skladišče odvisno (izpeljano) iz osrednjega, podatkovnega skladišča. To je hkrati največja moč področnega skladišča in hkrati njegova najšibkejša točka. Moč zato, ker jih zgradimo dokaj enostavno, saj podatke le izpeljemo iz osrednjega skladišča, kar pogosto rezultira v njihovem (pre)-velikem številu. Prav vzdrževanje večjega števila Pristop Konstrukt C P F Podatkovno skladišče DA, osrednje NE NE Področno skladišče DA DA DA Operativna podatkovna shramba DA NE (je vgrajena v sistem porazdeljene zgradbe) DA Ostali NE NE DA Tabela 1: Primerjava udeleženih samostojnih komponent strukturnih elementov je šibka točka centralizirane zgradbe. Prav tako zaradi svoje odvisnosti od podatkovnega skladišča zaključenega organiziranega sistema (ZOS), področnega skladišča ne moremo izgraditi, preden ni podatkovno skladišče ne samo načrtovano in izdelano, ampak tudi implementirano. Zaradi zmanjšane količine podatkov, ki jo je potrebno predelati pri povpraševanjih, so lahko področna skladišča ugodnejša rešitev kot podatkovna. Vendar je težko zagotoviti, da nobeno izmed povpraševanj nad izbranim področnim skladiščem ne bo zahtevalo podatka, ki ga v področnem skladišču ni. Področna skladišča so po definiciji manjša, v centralizirani zgradbi pa tudi praviloma bolj denor-malizirana. V primerjavi s podatkovnimi skladišči jih zato hitreje zgradimo, jih lažje upravljamo, pa tudi cena upravljanja je nižja. Kljub vsemu navedenemu zasledimo v virih mnogo opozoril, da so samostojna oziroma neodvisna področna skladišča le "metanje peska v oči" in so "izum podjetij, ki bi rada na hitro zaslužila". Izkušnje so pokazale, da samostojna področna skladišča niso rešitev problemov in vodijo v daljšem časovnem obdobju v še večjo množico samostojnih, neintegriranih podatkovnih baz. Med posameznimi pristopi prihaja znova do velikih razlik pri vlogi in razumevanju operativne podatkovne shrambe. Inmonova definicija pravi, da je to integrirana, nestanovitna, vendar do minute verna slika poslovnega procesa. Takšna struktura je med drugim uporabna pri trženju in stikih s strankami, skratka v vseh področjih, kjer so zadnje transakcije pomembne za operativni poslovni proces. Kimball, kot zagovornik porazdeljenega pristopa gradnje podatkovnega skladišča, kjer operativna podatkovna shramba nima posebne vloge, označuje operativne podatkovne shrambe kot strukture, kjer hranimo podrobne transakcijske podatke. Potrebno je poudariti, da tudi centralizirana in porazdeljena zgradba dopuščata in podpirata ostale komponente, ki se nahajajo v sistemih za analiziranje sodobno informacijsko podprtega podjetja, kot so orodja za sprotno analitično obdelavo. Vendar jih podpirata le implicitno ali v najboljšem primeru delno eksplicitno kot v primeru orodij za sprotno analitično obdelavo pri porazdeljeni zgradbi. Federativna zgradba s svojim skupnim področjem priprave podatkov eksplicitno podpira in zato vključuje tudi ostale komponente. 3.2 Podatkovni model Izjemno pomembna je uporaba različnih podatkovnih modelov, saj izbira podatkovnega modela bistveno vpliva na načrtovanje podatkovne baze sistema podatkovnega skladišča. Podatkovni model določa tudi vsebino in strukturo podatkovne baze podatkovnega ali področnega skladišča. Najpomembneje je, da zagotavlja uporabnikom sprejemljivi odzivni čas. Tabela 2 prikazuje možne podatkovne modele pri posameznih pristopih: Model Pristop C P F Normalizirani (E-R) DA NE DA Denormalizirani DA, (dimenzijski) vendar le za področna skladišča DA DA Drugi (npr. objektni) NE NE DA Tabela 2: Podatkovni model v posameznih pristopih (primerjalno) 3.2.1. Diskusija Zagovorniki centralizirane zgradbe, po njenem največjem zagovorniku imenovani tudi »inmonisti«, trdijo, da mora biti podatkovno skladišče razvito z uporabo E-R modela, ker so normalizirani podatki idealna struktura podatkovnega skladišča. Vendar je za gradnjo področnega skladišča dovoljena in celo priporočena tudi uporaba dimenzijskega modeliranja. Nasprotno pa zagovorniki porazdeljene zgradbe na čelu s Kimballom verjamejo, da je podatkovno skladišče možno modelirati izključno z dimenzijskim modeliranjem oziroma zvezdasto shemo. Uporaba dimenzijskega modeliranja - zvezdaste sheme pomeni boljše razumevanje in boljšo učinkovitost glede na E-R model, njegova uporaba pa naj ne bi prinašala nobene izgube informacij. Vsak E-R model podatkovnega skladišča je lahko namreč predstavljen kot množica zvezdastih shem, in to brez izgube informacij [Kimball 1996; Firestone 1998[. Federativna zgradba dopušča obe, normalizirano in denormalizirano strukturo. 3.3 Razvojni cikel Izbira pristopa pri gradnji podatkovnega skladišča vpliva tudi na razvojni cikel. V tabeli 3 so primerjalno prikazani razvojni cikli posameznih pristopov. 3.3.1 Diskusija Ugotovimo lahko, da se predlagani razvojni cikli vseh predstavljenih pristopov bistveno razlikujejo med seboj in se razlikujejo tudi od tradicionalnega razvojnega cikla. Sistemi, razviti po centraliziranem pristopu, temeljijo na podatkovno vodenem razvoju. Intervjuji z uporabniki zaradi pridobivanja zahtev niso zaželeni, saj so zahteve uporabnikov preveč variabilne. Prav to je najmočnejši protiargument dimenzijskemu modelu. Nasprotno pa razvojni cikel pristopa gradnje porazdeljenega podatkovnega skladišča izhaja iz poslovnih zahtev. To je razumljivo, saj je v zgradbi porazdeljenega podatkovnega skladišča uporabljen dimenzijski model, ki je izpeljan iz zahtev. Zato je, nasprotno kot pri centraliziranem pristopu, zbiranje zahtev s pomočjo intervjujev zelo zaželeno. Federativni pristop kot hibrid dopušča obe možnosti, čeprav močno zagovarja začetno zbiranje zahtev - tudi z intervjuji, ki vključuje natančne definicije in analizo poslovnih potreb. Federativna zgradba ima kot zgradba zgradb posebni razvojni cikel, ki se bistveno razlikuje od obeh ostalih. C P F implementacija definicije dokumentiranje podatkovnega poslovnih obstoječih skladi'ča zahtev sistemov, izdelava E-R modela 4 4 4 integracija izdelava določitev podatkov načrta in kandidatov dimenzijskega z dodano modela vrednostjo 4 4 4 testiranje in specifikacija orodij analiza izboljšave za končnega in izbira 4 uporabnika kandidatnih podatkov z največjo dodano vrednostjo 4 4 programiranje izbira in implementacija namestitev orodij, orodij za zajem, fizično oblikovanje transformacijo in polnjenje 4 4 4 oblikovanje načrt priprave gradnja sistema za podporo podatkov skladišča odločanju analiza rezultatov in razvoj orodij razvoj aplikacij 4 dokumentiranje 4 razumevanje zahtev za uporabnika 4 uporaba Tabela 3: Razvojni cikli zgradb (primerjalno) Prav tako lahko ugotovimo, da izbira podatkovnega modela ne vpliva na izbiro razvojnega cikla, temveč na to vpliva lastnost posameznega pristopa v celoti. Tako uporabljamo pri centraliziranem pristopu gradnje podatkovnega skladišča isti razvojni cikel za načrtovanje osrednjega podatkovnega skladišča kot tudi področnih skladišč, kljub njuni popolnoma različni vlogi, strukturi in namenu uporabe. 3.4 Drugi parametri V kontekstu podatkovnega skladiščenja izluščimo še naslednje parametre pristopov, pri katerih se lahko posamezni pristopi razlikujejo: . upravljanje meta podatkov (pri centraliziranemu pristopu so meta podatki nujno porazdeljeni); . enostavnost začetne gradnje (trud, potreben za izgraditev podatkovnega skladišča ali prve delujoče področne shrambe); . upravljanje (trud, potreben za učinkovito upravljanje "zakulisja"); . nadgradljivost (trud, potreben za prilagoditev na nove razmere, nastale zaradi novih zahtev uporabnikov ali organizacijskih sprememb); . skalabilnost (stopnja možnih razširitev zaradi večjega števila uporabnikov, večje količine podatkov, večje podpore povzetim podatkom, bolj kompleksnih povpraševanj); . varnost in zaščita; • možnost vpeljave zunanjih sodelavcev; . potrebna politična volja in . razmerje med porabo virov na nivoju ZOS in posameznih oddelkov. Omenjeni parametri se v praksi določijo nad končnimi orodji, kajti šele izbrani uporabljeni sistemi in orodja določajo končne lastnosti sistema podatkovnih skladišč. V zaključku, v tabelah 4, 5 in 6, primerjalno zapišimo še najpomembnejše razlike med posameznimi pristopi: C F Monolitski sistem Množica povezanih sistemov, ki si delijo skupne podatke Atomarne informacije na Atomarne informacije na različnih enem, centralnem mestu lokacijah Homogeni sistem Heterogeni sistem Tabela 4: Centraliziran in federativni pristop [primerjalno) P F Sestavljena je iz izključno področnih skladišč. Mešane strukture (klasična centralizirana podatkovna skladišča kot tudi skladišča, sestavljena iz področnih skladišč) Vsi podatki nastopajo na podatkovnem vodilu. Ne zahteva nujno delitve vseh podatkov na podatkovnem vodilu. Dimenzijski model je ekskluzivni model. Priznava, da so atomarna podatkovna skladišča (E-R model) boljša rešitev v določenih okoljih, kjer je to dovoljeno in zaželeno. Tabela 5: Centraliziran in porazdeljeni pristop (primerjalno) C P Uporablja rigorozne, že znane tehnike za zbiranje, modeliranje in implementiranje zahtev končnih uporabnikov. Dimenzijski model omogoča boljše razumevanje in boljšo učinkovitost v smislu hitrejšega izvajanja povpraševanj. Temelji na področno usmerjenem podatkovnem modelu, ki minimizira integracijske probleme med posameznimi projekti podatkovnega skladiščenja. Atomarne informacije na različnih lokacijah. Dovoljuje gradnjo podrejenih, odvisnih področnih skladišč in s tem omogoča vodljivo uporabo tehnologije področnih skladišč. Množica povezanih, vendar decentraliziranih področnih skladišč, ki si delijo skupne podatke. Omogoča bolj centralističen nadzor nad sistemom podatkovnega skladišča. Omogoča hitrejšo gradnjo sistema podatkovnega skladišča in njegovo hitrejše prilagajanje spremembam. Tabela 6: Porazdeljeni in federativni pristop [primerjalno) 3.5. Izbira primernega pristopa Ne glede na izbrani pristop, strategijo in orodja mora uspešen projekt podatkovnega skladiščenja: . zadostiti trenutnim zahtevam uporabnikov; . biti upravljan s sprejemljivimi stroški; . biti dovolj prilagodljiv glede na spremembe zahtev uporabnikov in organizacijske spremembe; ■ nuditi konsistentne in visokokakovostne podatke in ■ omogočati uporabnikom lažjo navigacijo in razumevanje podatkov ter jim pomagati pridobiti iz podatkov največ, kar se da. Na podlagi izvedene primerjave v prejšnjem poglavju, v nadaljevanju predlagamo napotke za izbiro ustreznega pristopa. Strnjeno so predstavljeni v tabeli 7. Naslednji dejavniki dajejo prednost uporabi centraliziranega pristopa pri gradnji podatkovnega skladišča: . Stabilno, hierarhično strukturiran ZOS, kjer so usmeritve (razvojne, organizacijske) določene z višjega nivoja in niso predmet sodelovanja med posameznimi oddelki. Tako okolje poenostavlja integracijo, saj lahko v primeru neskladij in nesoglasij med oddelki učinkovito nastopi vodstvo. . Velika želja po podpori odločanju, bodisi da je ta želja že prisotna med uporabniki, ali pa je to le zaveza vodstva. ■ Stabilen in z viri močan oddelek informacijske tehnologije (IT) na nivoju ZOS. . Oddelek IT na nivoju ZOS, ki dobro pozna poslovne probleme v organizaciji in ima sposobnosti in motivacijo za reševanje poslovno-nivojskih integracij, ki so del gradnje in vzdrževanja podatkovnega skladišča in ni le tehnično usmerjen. Zadržki pri uporabi centraliziranega pristopa so naslednji: ■ potrebna je precejšnja investicija finančnih sredstev in časa, zato je tudi tveganje večje; . nujno je potrebno pokroviteljstvo s strani članov vodstva in to za celoten čas izvajanja projekta; . za integracijo operativnih podatkov s celotnega ZOS v koherentno celoto je potrebno vključiti informatike z nivoja organizacije in ne oddelka, kar je prevečkrat nedosegljiv ideal, ker se informatiki soočajo z množico neintegriranih operativnih sistemov že na nivoju oddelkov in ne želijo ponavljati te izkušnje na projektu podatkovnega skladiščenja; . težja prilagodljivost organizacijskim spremembam; » daljša odzivnost na spremembo lokalnih zahtev in . odvisnost področnega skladišča od osrednjega (v daljšem času). Pristop gradnje porazdeljenega podatkovnega skladišča označujejo naslednje želene značilnosti: . omogoča hitro gradnjo razmeroma enostavno obvladljivih področnih skladišč, ki predstavljajo rešitev prioritetnih (poslovnih) problemov; ■ manjši projekti omogočajo preizkušanje metodologij, orodij in strategij, brez večjih izgub oziroma stroškov in usodnih vplivov na kasnejše dele projekta in ker . omogoča razmeroma enostavno rešitev polnjenja iz operativnih sistemov v področno shrambo (znotraj posamezne iteracije in le za podatke na nivoju elementarnih transakcij). Pri oblikovanju porazdeljene zgradbe podatkovnega skladišča je največja nevarnost v tem, da posamezna področna skladišča hitro postanejo nepovezana z ostalimi, torej "informacijski otoček sredi oceana". Osnovni razlog je v tem, da se želijo ali vodstvo ali projektni vodje izogniti zahtevani investiciji v začetne korake, ki med drugim definirajo skladne dimenzije in dejstva, skupna poslovna pravila in semantiko, kar rezultira v skupnih meta podatkih. Omenjeno je mogoče doseči le s trdim delom ob podpori vodstva. Nepovezljivost oziroma neintegriranost, ki je posledica množice samostojnih nepovezljivih področnih skladišč, krši enega izmed osnovnih razlogov za odločitev za podatkovno skladišče in predstavlja skoraj nepremostljivo oviro za nadaljnji razvoj podatkovnega skladišča na nivoju ZOS, saj je kasnejša integracija nemogoča ali vsaj zelo težavna. Ostale pomanjkljivosti decentraliziranega pristopa: . oddelki imajo svoje, njim lastne podatke, ki jih ne želijo deliti z drugimi oddelki; . oddelki imajo svoje zahteve, zato mora podatkovno skladišče, sestavljeno le iz področnih shramb, optimalno integrirati prav vse zahteve vseh uporabnikov; . težavna pogajanja o političnih (katera področna shramba je najpomembnejša in jo je potrebno prioritetno zgraditi) in tehnoloških odločitvah med oddelki; - potreben dogovor o skupni zgradbi, poslovnih pravilih in semantiki med različnimi skupinami; ■ validacija zgrajenega sistema v razvojnem ciklu ni eksplicitno podana; ■ pristopa raje ne uporabimo, če imajo oddelki bistveno različne potrebe (manjša prekrivanost zahtev). Federativna zgradba uspešno integrira množico komponent v sistemu: kupljena in zgrajena podatkovna in področna skladišča ter analitične aplikacije, podatkovno rudarjenje, orodja za sprotno analizo, orodja za povpraševanja in poročanje, orodja za izdelavo poročil iz operativnega dela, orodja za povečanje kakovosti podatkov, orodja za zajem, transformacijo in polnjenje podatkov, orodja za sistemsko upravljanje, orodja za dostavo informacij, informacijske duri ZOS, sisteme za poročanje in sistemi za upravljanje podatkovnih baz. Vsekakor velja pristop gradnje federativne zgradbe uporabiti pri množici sistemov podatkovnih skladišč znotraj ZOS, kar danes ni več redkost. V takem primeru lahko federativno zgradbo obravnavamo kot generično oziroma kot metamodel sistemov podatkovnih skladišč. Za oblikovanje in razvoj federativne zgradbe se je potrebno odločiti ali vsaj razmišljati ob naslednjih situacijah: • Ob prevzemu in prodaji podjetij - čemur smo dnevno priča tudi v Sloveniji - bi bilo neracionalno in nesmiselno zavreči popolnoma delujočo infrastrukturo podatkovnega skladišča, zato je za integracijo virov nujna prilagoditev na federativno zgradbo. • Tržišče se premika v stopnjo razvoja, kjer se programski izdelki le še kupujejo in ne razvijajo več, in to velja tudi za podatkovna skladišča. Tako je lahko novi celoviti poslovni rešitvi (ERP, angl. Enterprise Resource Planning) ali sistemu OLTP priloženo tudi delno razvito podatkovno skladišče, ki ga je potrebno integrirati v že zgrajen sistem podatkovnega skladišča. . V primeru več različnih sistemov podatkovnih oziroma področnih skladišč. • V primeru analitičnih aplikacij, pogosto ne več vzdrževanih, ki jih je potrebno integrirati. Pomanjkljivosti federativnega pristopa so: . Razmeroma težavno usklajevanje in koordiniranje aktivnosti, potrebnih pri gradnji podatkovnega skladišča. • Težavno "prebijanje ledu" pri političnih in lastniških odločitvah. . Zahteva dogovor o poslovnih pravilih in semantiki med različnimi skupinami. . Kompleksno in zahtevno tehniško okolje. • Pogosto ima več repozitorijev metapodatkov. Omenjene ugotovitve lahko strnemo v tabelo, ki predstavlja metodo za določitev optimalnega pristopa pri gradnji podatkovnega skladišča (tabela 7). Predstavljena je primernost posameznega pristopa glede na parameter, ki opisuje stanje v organizaciji ali določeno zahtevo, ki jo je potrebno zadovoljiti. Pristop C P F Parameter Nehierarhična organiziranost in nadzor ZOS N P P Potreba po hitri rešitvi N P N Potrebe po različnih natančnosti posameznih podatkov (različna granularnost) P N N Dinamične spremembe v organizaciji N P P Potreba po različnih virih (izvorih) podatkov P N P Z viri šibek oddelek IT na nivoju ZDS N P P Pokroviteljstvo projekta podatkovnega skladišča ni zagotovljeno N P P Želja po preizkušanju orodij N P NP Množica obstoječih rešitev v sistemu za analiziranje N N P Množica sistemov podatkovnih skladišč PP N P Možnost vpeljave zunanjih sodelavcev P PP PP Potreba po močnih varnostnih mehanizmih P N N Zahtevana odprtost modela N P P Legenda: P-primerna, N - neprimerna, PP-pogojno primerna Tabela 7 Določitev optimalne zgradbe podatkovnega skladišča Splošno najboljši pristop ne obstaja, saj ima vsak svoje dobre in slabe lastnosti. Vsekakor težimo k optimalni zgradbi, ki je v večini primerov decentralizirana, porazdeljena in predstavlja najboljšo izbiro za večino organizacij. Za podrobnejše informacije je bralec napoten na [Golob 2001]. 4 Povzetek ugotovitev in sklep Naše ugotovitve ne potrjujejo ugotovitev v [Gallas 1999], kjer je postavljena hipoteza, da imata avtorja Inmon in Kimball razmeroma skladne pristope, le da se njuni poimenovanji struktur razlikujeta. Nasprotno, naše ugotovitve, zbrane v tem prispevku, nakazujejo na veliko razliko pri: • pristopu h gradnji podatkovnega skladišča: različen razvojni cikel; . zgradbi: od-zgoraj-navzdol (centralizirana) oziroma od-spodaj-navzgor (porazdeljena) in ■ uporabi osnovnega podatkovnega modela: E-R oziroma dimenzijski model. Ugotovitve prav tako potrjujejo neskladnost jezika, ki ga avtorja uporabljata za opis svojih metodologij (drugačno razumevanje vloge in lastnosti podatkovnega skladišča, področnih skladišč, operativne podatkovne shrambe). Rezultati naše primerjave v tretjem poglavju prav tako kažejo nasprotno, kot trdi [Gallas 1999], ki navaja, da se oba eksperta strinjata v tem, da je uspeh podatkovnega/področnega skladišča najprej odvisen od učinkovitega zbiranja poslovnih zahtev, ki določajo nadaljnje oblikovanje skladišča. Pokazali smo namreč, da razvojni cikel centraliziranega pristopa postavlja analizo zahtev na zadnji korak, v inkre-mentalni pa je postavljen čisto na začetek. Vendar na dokončno izbiro večkrat vplivajo zunanji dejavniki ali odločitve, na katere imamo le omejen vpliv ali pa ga sploh nimamo. V takem primeru so rezultati prispevka uporabni pri identifikaciji šibkih točk izbranega pristopa ali določene zgradbe. Splošno najboljša rešitev ne obstaja, saj ima vsak pristop (in s tem zgradba) svoje lastnosti, dobre in slabe, potrebno pa se je odločiti za tisto, ki najbolj ustreza posamezni organizaciji. LITERATURA Anahory, S., Murray, D. (1997): “Data VVarehousing in the Real VVorld: A practical Guide for Building Decision Support", Systems Addison Wesley Longman Limited, Harlow, England. Barquin, R.C., Edelstein, H. (1997): “Planningand Designingthe Data Warehouse", Prentice Hall, UpperSaddle River, N.J. Bischoff, J., Alexander, T. (1997): “Data VVarehouse: Practical Advice from the Experts", Prentice Hall, Upper Saddle River, N.J. Firestone, Joseph M. (1998): “Dimensional Modeling and E-R Modeling In The Data Warehouse”. Gallas, S. (1999): “Kimball Vs. Inmon.’’, DM Revievv. Golob, I. (2001): “Arhitekture podatkovnih skladišč", magistrsko delo, Univerza v Mariboru. Hackney, D (2000a): “Data VVarehouse Delivery: Federated FAQs.’’, DM Revievv. Hackney, D. (2000b): “Data VVarehouse Delivery: How to Federate", DM Review. Hackney, D. (2000c): “Data VVarehouse Delivery: The Federated Future", DM Revievv. Hackney, D. (2000d): “Data VVarehouse Delivery: VVhen to Federate", DM Revievv. Hammond, M. (2000): ZDNet: eVVEEK: Survey traces huge grovvth in data vvarehouse market, http://www.zdnet.com/ Inmon, W. H. (1996): "Building the Data VVarehouse”, Wiley, New York. Inmon, VVilliam H. (1999a): “Data Mart Does Not Equal Data VVarehouse”, D M Review. Inmon, VVilliam H (1999b): “Operational Data Store”. Kimball, R. (1996): “The Data VVarehouse Toolkit: Practical Techniques for Building Dimensional Data VVarehouses”, John Wiley & Sons, New York, Chichester. Kimball, R. et al. (1998): “The Data VVarehouse Lifecycle Toolkit: Expert Methods for Designing, Developing and Deploying Data VVarehouses", Wiley, New York. VVells, D., Hope, M. (2000): “Ovum Evaluates: the Datamart - the Sucessful Route to Data VVarehousing", Ovum. VVhite, C. (2000): "The Federated Data VVarehouse”, DM Review. Izidor Golob je doktorski študent na Fakulteti za elektrotehniko, računalništvo in informatiko v Mariboru, kjer je tudi zaposlen kot asistent za področje informatika. Na raziskovalnem področju se ukvarja s podatkovnimi bazami, kakovostjo informacij in podatkovnimi skladišči. Tatjana VVelzer je izredna profesorica na Fakulteti za elektrotehniko, računalništvo in informatiko v Mariboru, kjer predava na dodiplomski in podiplomski stopnji in vodi laboratorij za podatkovne tehnologije. Na raziskovalnem področju se ukvarja predvsem s podatkovnimi bazami, kakovostjo podatkov in podatkovnim modeliranjem. Boštjan Brumen je doktorski študent na Fakulteti za elektrotehniko, računalništvo in informatiko v Mariboru, kjer je zaposlen kot asistent za področje informatika. Na raziskovalnem področju se ukvarja s podatkovnimi bazami in podatkovnim rudarjenjem. RAZPRAVE 0 Metode določevanja obsega funkcionalnosti Tomaž Kralj Univerza v Mariboru, Fakulteta za elektrotehniko, računalništvo in informatiko tomaz.kralj-ptuj@gov.si Izvleček Merjenje je v programskem svetu vse bolj prisotno, saj omogoča analize, ki se uporabljajo za prikazovanje stanja posameznega projekta. Funkcijske točke so se izkazale kot primerna metrika določevanja obsega informacijskih rešitev. Z njimi merimo funkcionalnost in tako dosegamo neodvisnost metrike od tehnologije in metodologije implementacije. Obstaja več metod, ki ustrezajo standardu ISO 14143, kjer se ne opredelijo metode, temveč pogoji, ki jih mora zagotavljati metoda, da se lahko označi kot veljavna za merjenje obsega funkcionalnosti. V prispevku so predstavljene štiri metode določevanja obsega funkcionalnosti in kratka primerjava med njimi. Abstract Methods far Measuring Functionality Measurement in softvvare vvorld is more common nowadays, because it ensures us the base for analyses to track projects. Function point analysis is the most appropriate metric for the size of softvvare application. We measure functionality - this is the reason, why a method is independent of technology and methodology of implementation. There are several methods, vvhich correspond to the ISO 14143 standard. The ISO standard determines conditions vvhich a method must comply to become a legal function point method. In this article we describe and compare four function point methods. 1 Uvod V programskem svetu se z merjenjem srečujemo kratek čas. Lahko rečemo, da se nahajamo v fazi razvoja metrik merjenja informacijskih rešitev. V primerjavi z drugimi industrijami, kjer je bila potreba po merjenju prisotna že od vsega začetka, je merjenje v programskem svetu šele v povojih. Rezultati merjenja omogočajo primerjavo izdelkov in posledično njihovo izboljšavo. Za to potrebujemo pravo enoto, postopke merjenja in merilo, s pomočjo katerih se nedvoumno predstavi velikost izdelka uporabniku ali pa so pridobljeni podatki osnova za analize oz. poročila. Iz enakih razlogov merimo v svetu informacijskih rešitev. Zelja po izboljšavi procesa izdelave informacijskih rešitev je vodilo pri zagotavljanju ustrezne metrike, s pomočjo katere ugotovimo prednosti oz. slabosti vnešenih sprememb. Trenutna dinamika zahteva čim krajši čas od zajemanja zahtev do končnega testiranja in predaje informacijske rešitve stranki, pri čemer krajši čas ne sme biti v škodo natančnosti, funkcionalnosti in majhnemu številu odpovedi informacijske rešitve, ki jo uporabnik prevzame [4]. 2 Funkcijske točke Merjenje obsega PO s pomočjo funkcijskih točk je trenutno vodilna metrika programskega sveta [7]. Ena izmed metrik določanja obsega informacijskih rešitev je tudi določevanje obsega funkcionalnosti, ki nam prikaže rezultat v funkcijskih točkah. Obseg določimo s funkcionalnimi specifikacijami, kar pomeni, da se obseg informacijske rešitve lahko določi že v začetni fazi, ko so dokončno podane uporabniške funkcionalne zahteve. Takšen način štetja omogoča neodvisnost merjenja obsega od metodologije in tehnologije implementacije. Funkcijske točke niso nastale šele pred kratkim. Imajo podobno zgodovino kot objektno orientirana (OO) tehnologija, ki je bila definirana in predstavljena veliko prej, preden je postala paradigma programskega sveta. Idejni oče funkcijskih točk je Alan Albrecht - funkcijske točke so rezultat njegove študije v sedemdesetih letih 20. stoletja. V današnjem času dosegajo razmah, ki pomeni novo obdobje merjenja informacijske rešitve oz. pomoč pri definiranju novih postopkov. Funkcijske točke nudijo širok spekter uporabe. Ena izmed prednosti je možnost uporabe funkcijskih točk kot normalizacijske metrike, ki omogoča primerjavo med informacijskimi rešitvami, implementiranimi v različnih programskih jezikih [3]. Nekaj primerov uporabe: - določevanje obsega opazovane informacijske rešitve; . ocenjevanje potrebnih virov projekta, ko so izdelane funkcionalne specifikacije zahtev [6]; . podlaga za primerjanje med konkurenčnimi organizacijami, saj omogočajo izvajanje primerjalnih testov v svetu PO ne glede na metodologijo načrtovanja in tehnologijo implementacije; ■ omogočajo možnost izdelave resnih ekonomskih analiz [2]. Znanih je že nekaj metod, s pomočjo katerih merimo obseg funkcionalnosti informacijskih rešitev. Metode morajo ustrezati standardu ISO 14143, kjer se ne opredelijo metode, temveč pogoji, ki jih mora zagotavljati metoda, da se lahko označi kot veljavna za merjenje obsega funkcionalnosti. Sledi kratka predstavitev štirih najpogostejših metod določevanja obsega funkcionalnosti, njihove glavne značilnosti in kratka primerjava med njimi. 3 Standardna metoda FPfl (Function Point Anali/sisJ Avtor metode FPA, ki jo imenujemo tudi osnovna oz. standardna metoda FPA, je Alan Albrecht. Za standardno metodo FPA je od leta 1984 odgovorna neprofitna organizacija IFPUG (International Function Point Users Group), ki skrbi za njen nadaljnji razvoj. V standardni metodi FPA se srečamo s petimi temeljnjimi komponentami, ki bodo podrobneje opisane v korakih algoritma na sliki 1 [7], [8], [9], [10]: . notranje podatkovne strukture ILF (Internat Logical File); • zunanje vmesniške podatkovne strukture EIF (External Interface File); . zunanji vhodi El (External Input); ■ zunanji izhodi EO (External Output); ■ zunanja povpraševanja EQ (External incjuiry). Standardna metoda FPA je predstavljena v obliki algoritma. Rezultat algoritma je obseg funkcionalnosti merjene informacijske rešitve. Algoritem vsebuje naslednje korake: a) Določitev tipa štetja . Razvojni projekt - želimo določiti obseg projekta, pri katerem je končana faza analize in načrtovanja. To pomeni, da so specificirane funkcionalnosti, ki jih mora vsebovati informacijska rešitev. Med razvojem se večkrat zgodi, da se kakšna funkcionalnost doda fsčope creep), zato je treba popraviti uporabniške funkcionalne zahteve, s tem pa se spremeni tudi obseg informacijske rešitve. . Nadgradnja programa - merijo se modifikacije v obstoječi informacijski rešitvi, v kateri je bila dodana, spremenjena ali brisana funkcionalnost. - Program - meri se obseg informacijske rešitve, ki je instalirana oz. v uporabi. Ta vrednost se imenuje obseg osnovne verzije (baseline), ki jo je treba ažuri-rati sproti (še posebej po nadgradnji informacijske rešitve). b) Identifikacija meje štetja in mej programov pomeni določitev konceptualne meje med informacijsko rešitvijo in uporabnikom. Deluje kot membrana, skozi katero prehajajo podatki v informacijsko rešitev in preko transakcij tudi iz nje. tip štetja ' ■ meje štetja podatkovne transakcijske funkcije funkcije neprilagojena vrednost FT faktor VAF prilagojena vrednost FT Slika 1: Postopek štetja FT Znotraj meje informacijske rešitve obstajajo logične strukture, ki jih vzdržuje opazovana informacijska rešitev. Od zunaj prihajajo podatkovne strukture, ki se uporabljajo preko vmesnikov, njihovo stanje pa vzdržuje informacijska rešitev zunaj meja opazovanega sklopa, c) Štetje podatkovnih funkcij - podatkovne funkcije predstavljajo podatkovne zahteve, ki jih je definiral uporabnik. Predpišejo podatkovne strukture, katerih naloga je hranjenje podatkov. Pri identificiranju podatkovnih funkcij se je treba distancirati od tehničnih rešitev in se skoncentrirati na uporabnikove zahteve. To pomeni, da fizična implementacija ne pomeni tudi logične definicije podatkovnih skupin, lahko pa sovpadata. Podatkovne funkcije morajo biti uporabljene vsaj v eni transakcijski funkciji, v nasprotnem primeru njihov obstoj ni upravičen. Podatkovne funkcije se delijo na tiste, ki se vzdržujejo znotraj informacijske rešitve (ILF), in podatkovne funkcije, ki se le uporabljajo znotraj informacijske rešitve (EIF) in so drugje zastopane kot notranje podatkovne funkcije. Ko so identificirane, se določi kompleksnost in izračuna prispevek podatkovnih funkcij k skupni vrednosti funkcijskih točk s pomočjo obstoječih tabel, č) Štetje transakcijskih funkcij - transakcijske funkcije predstavljajo funkcionalnost procesiranja podatkov v informacijski rešitvi. Predstavljajo manipulacijo s podatki, ki so shranjeni v podatkovnih funkcijah. Poznamo tri tipe transakcijskih funkcij (slika 2): . El (Extcrnal Input) zunanji vhod je elementarni proces, ki procesira podatke ali kontrolne informacije, ki pridejo od zunaj glede na mejo štetja. Osnovni namen je vzdrževanje ene ali več ILF znotraj meje štetja in/ali sprememba obnašanja sistema. • EO (External Output) zunanji izhod je elementarni proces, ki pošilja podatke na drugo stran meje informacijske rešitve. Osnovni namen je prikaz informacij uporabniku s pomočjo poslovne logike. Procesorska logika mora vsebovati vsaj en podatek, ki se pridobi s pomočjo formule ali kalkulacije. Vsebuje sestavljen podatek, vzdržuje eno ali več podatkovnih funkcij ILF in/ ali spremeni stanje sistema. ■ EQ (External inQuiry) zunanje poizvedovanje je prav tako elementarni proces in je podobno zunanjemu izhodu, le da prikazuje podatke brez nadaljnje obdelave in zato ne sme vsebovati sestavljenih podatkov oz. podatkov, ki vsebujejo matematično formulo. Ne sme vzdrževati podatkovnih funkcij ILF in spreminjati stanja sistema. Tudi pri transakcijskih funkcijah se določi kompleksnost in prispevek le-teh k skupni vrednosti funkcijskih točk merjene informacijske rešitve. d) Določevanje neprilagojene vrednosti funkcijskih točk - gre za vsoto števila funkcijskih točk podatkovnih in transakcijskih funkcij. e) Določanje vrednosti faktorja prilagoditve VAF (Vcilue Adjustment Eactor) - faktor VAF se izračuna na podlagi 14 splošnih sistemskih karakteristik GSC (General System Characteristic). Za vsako karakteristiko se posebej oceni vpliv v opazovani informacijski rešitvi z vrednostmi od 0 (ni vpliva) do 5 (močan vpliv). f) Izračun prilagojene vrednosti funkcijskih točk - prilagojena vrednost pomeni, da so upoštevane dodatne zahteve informacijske rešitve, kot so stopnja varnosti, zahtevnost procesiranja ipd. Te karakteristike se zrcalijo v faktorju prilagoditve. Prilagojeni obseg merjene informacijske rešitve se izračuna tako, da se dobljeno število funkcijskih točk pomnoži s faktorjem prilagoditve (VAF). 4 Metoda MK IIFPA MK II FPA pomeni MarK II Function Point Analysis. Varianto MK II FPA je leta 1988 definiral Charles Symons. Trenutno skrbi za njen razvoj Metrics Prac-tices Committee (MFC) UK Softvvare Metrics Asso-ciation [16]. Slika 3 prikazuje proces merjenja z metodo MK II FPA, kjer je metoda razdeljena na tri dele: merjenje obsega funkcionalnosti, produktivnosti in prilagojene vrednosti funkcijskih točk (opcijsko). Algoritem vsebuje naslednje korake: a) Določitev namena in tipa štetja - poznamo tri vidike: . projektni vidik - t. i. delovni vidik; . aplikacijsko vodeni vidik - obseg informacijskih rešitev za specifično poslovno področje; • poslovni vidik - obseg informacijskih rešitev podjetja. b) Določitev meje štetja - konceptualna meja med informacijsko rešitvijo in uporabnikom. c) Identifikacija logičnih transakcij - najprej je treba definirati pojem logična transakcija: gre za poslovni proces na najnižjem nivoju, ki ga zagotavlja merjena informacijska rešitev. Vsebuje tri osnovne elemente: ■ vhod podatkov preko programske meje; ■ procesiranje podatkov; . izhod podatkov preko programske meje. Vsaka logična transakcija mora biti prožena z unikatnim dogodkom, ki je iniciran zunaj programske meje. Zahtevati jo mora uporabnik, pri tem pa mora transakcija pustiti sistem po končanem procesiranju v konsistentnem stanju, č) Identifikacija in kategorizacija entitetnih tipov Poslovni uporabnik ima predstavo o svojem poslovnem svetu, zato lahko točno definira START KONEC 7. Določitev projekta truda 5. Štetje vhodov, procesov in izhodov 10. Izračun faktorja prilagoditve 4. Identifikacija in kategorizac. entitetnih tipov 9. Stopnja vpliva splošnih karakteristik 1. Določitev namena in tipa štetja 2. Določitev meje štetja 3. Identifikacija logičnih transakcij 11. izračun prilagojene vrednosti FT 8. Izračun produktivnosti 6. Izračun obsega funkcionalnosti podatke, ki jih potrebuje. Logične skupine takih podatkov imenujemo entitete. Primer take entitete je stranka, ki vsebuje več podatkovnih elementov DET (Data Element Type): ime in priimek, bivališče, davčna številka itd. Pri metodi MK II FPA gre pri merjenju obsega logične transakcije za preštevanje entitetnih tipov. Poznamo dve vrsti le-teh: . primarni entitetni tip so stvari v realnem svetu; . neprimarni entitetni tip - vse neprimarne entitete združimo v eno entiteto, ki jo imenujemo sistemska entiteta (šifranti). Določena entiteta je lahko primarna za eno informacijsko rešitev in neprimarna za drugo. Takšna klasifikacija prikazuje podobnost s podatkovnimi funkcijskimi tipi standardne metode FPA: . primarna entiteta - ILF, . neprimarna entiteta - EIF. d) Štetje vhodov, procesov in izhodov Ko so identificirane logične transakcije in entitetni tipi, se začne preštevanje vhodnih in izhodnih podatkovnih elementov. Pri vhodu in izhodu se prešteje število unikatnih podatkovnih elementov, pri procesiranju pa število referenciranih entitet. Ponavljanje posameznega elementa znotraj logične transakcije se upošteva kot en element. e) Izračun obsega funkcionalnosti Obseg funkcionalnosti je obtežena vsota komponent vhoda, procesiranja in izhoda. Izračuna se tako, da se pomnoži število vhodnih elementov DET (N;), število entitet, ki so bile referencirane v procesiranju (Nc), in število izhodnih elementov DET (N„) z industrijskimi utežmi, ki so empirično določene. Prva formula vrne kot rezultat neprilagojeno vrednost funkcijskih točk, ki se pri metodi MK II FPA označuje z oznako FPI (Function Point Indeks). FPI = Wl*YJNl+W'*YJN' + w°*'LN0 (1) Industrijske uteži so določene kot konstante: W, = 0.58 We = 1.66 W„ = 0.26 f) Stopnja vpliva splošnih karakteristik Pri metodi MK II FPA je faktor vpliva, ki je odraz splošnih sistemskih karakteristik, faktor prilagoditve tehnične kompleksnosti TCA (Technical Coplexity Adjustment). Tudi tukaj se ocenjuje posamezna karakteristika z vrednostmi od 0 (brez vpliva) do 5 (močan vpliv). Razlika je v številu sistemskih karakteristik, saj se jih pri metodi MK II FPA ocenjuje 19 (pri VAF le 14). g) Izračun prilagojene vrednosti funkcijskih točk -tudi tukaj se izračuna prilagojena vrednost merjene informacijske rešitve kot produkt števila funkcijskih točk s faktorjem prilagoditve. 5 Metoda COSMIC-FFP COSMIC (COmmon Softivare Measurement International Cosortium) je najmlajša med naštetimi. Avtorji te metode trdijo, da vsebuje najboljše lastnosti naslednjih metod: standardne metode FPA, NESMA, MK II FPA in Full Function Point. Metoda COSMIC-FFP je nastala zaradi pomanjkljivosti standardne metode FPA. Po mnenju avtorjev metode COSMIC-FFP so pomanjkljivosti standardne metode FPA naslednje [1]: . FPA ima omejeno uporabnost zunaj MIS (Management Information System) sveta - primer takega sistema so sistemi v realnem času [5],[12]; . FPA tehnike niso vedno kompatibilne z modernimi metodami načrtovanja PO; . rezultati metode FPA so subjektivni; ■ vprašljiva je natančnost in konsistentnost rezultatov FPA metod; . nezadovoljivi rezultati pri določanju obsega funkcionalnosti tehničnih sistemov. Osnova za določanje obsega funkcionalnosti so, enako kot pri drugih metodah, uporabniške funkcionalne specifikacije. Na ta način dosegajo metode določevanja obsega funkcionalnosti neodvisnost od tehnologije in metodologije implementacije. Na podlagi funkcionalnih zahtev se zgradi programski model, v katerem so združene vse informacije, ki so potrebne za merjenje (slika 4). Faze procesnega modela COSMIC-FFP: a) Faza preslikave Vhod v fazo preslikave so uporabniške funkcionalne zahteve. V tej fazi nastane programski model, ki vsebuje vse podatke, potrebne za merjenje obsega z metodo COSMIC-FFP. Najprej nastane kontekstni model, ki je v pomoč pri izdelavi programskega modela. b) Kontekstni model V kontekstnem modelu je treba razmejiti informacijsko rešitev in operacijsko okolje. Slika 5 prikazuje splošni primer kontekstnega modela skupaj s pretokom podatkov. preslikava merjenje uporabniške funkcionalne zahteve kontekstni model COSMIC-FFP model programski model model merjenja pravila in procedure Slika 4: CDSMIC-FFP procesni model merjenja c) Programski model Programski model se zgradi na osnovi kontekst-nega modela, ki ga prikazuje slika 5. Uporabniške funkcionalne zahteve so implementirane s funkcionalnimi procesi, ki so sestavljeni iz podprocesov. Le-ti so sestavljeni iz premikanja podatkov in manipulacij z njimi. V programskem modelu poznamo štiri tipe premikanja podatkov: vhod, izhod, branje in pisanje. Podatki vstopijo v proces in izstopijo k uporabniku, branje in pisanje se izvrši preko pomnilniških enot. č) Faza merjenja Merjenje obsega funkcionalnosti z metodo COSMIC-FFP pomeni štetje podprocesov premikanja podatkov v programskem modelu. Tipi premikanja so osnovne komponente metode COSMIC-FFP. Osnovne značilnosti merjenja so: « enota merjenja je Cfsu (Cosmic Functional Size Unit), ki pomeni en premik podatkov na nivoju podprocesov; . določiti je mogoče tudi natančnejše enote (analogija meter - centimeter); . obseg funkcionalnosti posameznega nivoja je enak vsoti vrednosti obsega funkcionalnosti posameznih funkcionalnih procesov, celotne merjene informacijske rešitve pa vsoti vrednosti obsega funkcionalnosti posameznih nivojev; . najmanjši obseg dela informacijske rešitve je 2 Cfsu, saj mora imeti najmanjši funkcionalni proces vsaj en vstop in en izhod oz. vpis. Zgornje meje ni. Agregacijske rezultati se računajo tako, da se obseg delov merjene informacijske rešitve prišteje k skupni vrednosti obsega funkcionalnosti. Za določevanje obsega funkcionalnosti posameznega nivoja, ki je izražen v enotah Cfsu, je na voljo formula 2: Velikost cfm {nivo,) = /j velikost(vhodi,) + ^ velikost{izhodi,) + ^ velikost{branja,) + y velikost(pisanja,) (2) uporabnik VSTOPI BERE programska oprema IZSTOPI 6 Metoda NESMA NESMA (NEtherlands Softivare Metrics uscrs Association) je ena izmed prvih uporabniških skupin EPA. Zasnovana je bila na standardni metodi EPA, definirani v priročniku IFPUG CP2 2.0. Standardna metoda EPA je bila takrat namenjena predvsem merjenju produktivnosti, zato je merila končane projekte. Metoda NESMA je želela zapolniti to vrzel in omogočiti načrtovanje stroškov za dokončanje projekta na podlagi uporabniških funkcionalnih specifikacij. Metodi sta se približali leta 1994, ko je IFPUG izdala priročnik CPM 4.0, v katerem je predstavila metodo štetja funkcijskih točk na podlagi funkcionalnih specifikacij. NESMA je izdala trenutno aktualni priročnik Function Point Mamml (FPM) 2.0 [14], v katerem je istoimenska metoda natančneje opisana. Koraki določevanja obsega funkcionalnosti metode NESMA so skoraj identični kot pri standardni metodi EPA. Metoda NESMA je specifična glede treh tipov štetja: • detajlno štetje funkcijskih točk; • ocenjevanje funkcijskih točk; ■ določevanje (indicative) funkcijskih točk. Zakaj takšno ločevanje? Z metodo NESMA se poskuša približati funkcijske točke uporabnikom, saj metoda na ta način omogoča grob vpogled v razsežnosti informacijske rešitve kakor tudi natančen obseg funkcionalnosti. Koraki algoritma posameznega štetja so naslednji: a) Detajlno štetje funkcijskih točk - standardni postopek: • identifikacija vseh funkcijskih tipov (ILF, EIF, EO, El, EQ); ■ določitev kompleksnosti posamezne funkcije; • izračun neprilagojene vrednosti funkcijskih točk (UPE). b) Ocenjevanje funkcijskih točk - ne določamo kompleksnosti posamezne funkcije: ■ identifikacija vseh funkcijskih tipov (ILF, EIF, EO, El, EQ); ■ določitev kompleksnosti posamezne podatkovne funkcije (nizka) in vsake transakcijske funkcije (srednja); ■ izračun neprilagojene vrednosti funkcijskih točk. c) Označevanje (indicative) funkcijskih točk: ■ identifikacija podatkovnih funkcijskih tipov (ILF, EIF); . izračun neprilagojene vrednosti funkcijskih točk po formuli 3: UFP = 35* število_ILF + 15 * število_EIF (3) Formula 3 temelji na naslednji predpostavki: ■ za vsako podatkovno funkcijo ILF bodo obstajale: ■ tri transakcijske funkcije El (dodajanje, brisanje in spreminjanje), • dve EO, . ena EQ. ■ za vsako podatkovno funkcijo EIF bo obstajala: • ena EO, ■ ena EQ. Predpostavke so rezultati analize večih projektov. Zadnja metoda je znana kot »the Dutch Metliod«. Nudi hiter postopek za približno oceno obsega informacijske rešitve. 7 Primerjava metod Sledi primerjava med standardno metodo FPA in drugimi metodami določevanja obsega funkcionalnosti. Izpostavljene bodo prednosti oz. slabosti posamezne metode, ki so razvidne že iz samih definicij metod. 7.1 Standardna metoda FPA - metoda MK II FPA Obe metodi imata veliko stičnih točk. Ob primerjanju rezultatov do 400 funkcijskih točk so rezultati primerljivi, pri informacijskih rešitvah obsega nad 400 FT postanejo razlike bolj očitne [15]. Kje prihaja do razlik oz. na kakšen način je mogoče primerjati rezultate merjenja obsega funkcionalnosti obeh metod? Faktor prilagoditve Obe metodi uporabljata faktor, s katerim se prilagodi vrednost funkcijskih točk glede na uporabniške zahteve informacijske rešitve. Povprečne vrednosti, ki jih dosegajo faktorji posamezne metode, so naslednje [15]: • standardna metoda FPA 1.0 • metoda MK II FPA 0.85 Logične transakcije Metoda MK II FPA poskuša opisati uporabniške zahteve z logičnimi transakcijami. Vsaka logična transakcija vsebuje vhod, procesiranje in izhod. Logična transakcija se proži z dogodki zunaj meje informacijske rešitve, ki predstavljajo interese uporabnika. Industrijske uteži za metodo MK II FPA (za vhod, procesiranje in izhod) so prilagojene tako, da so rezultati merjenj obeh metod primerljivi za projekte obsega 200 do 400 FT. Seštevek uteži da vrednost 2.5 (vhodi 0.58, procesiranje 1.66, izhod 0.26), zato ima najbolj preprosta logična transakcija obseg 2.5 FT. Zakaj razlika v obsegu? Standardna metoda meri obseg transakcijske funkcije tako, da najprej oceni kompleksnost transakcijske funkcije in nato odčita število funkcijskih točk (odvisno od kompleksnosti) iz točno določenih tabel. Na ta način se za posamezno transakcijsko funkcijo določi obseg od 3 do 7 funkcijskih točk (odvisno od kompleksnosti in tipa transakcijske funkcije). To pomeni, da nobena transakcijska funkcija ne more biti ocenjena z manj kot 3 funkcijskimi točkami, pa naj je še tako preprosta. Enako velja za zgornjo mejo, saj je le-ta nastavljena na 7 funkcijskih točk ne glede na obsežnost oz. kompleksnost transakcijske funkcije. Pri metodi MK II FPA tega problema ni, saj se z večanjem vhodnih oz. izhodnih elementov in refe-renciranih podatkovnih funkcij povečuje tudi izmerjeni obseg transakcijske funkcije. 7.2 Standardna metoda FPA - metoda COSMIC-FFP V metodi COSMIC-FFP so združene dobre lastnosti drugih metod. Metoda je produkt obstoječih metod, še najbolj podobna metodi FFP (Full Function Point), zato tudi kratica FFP v njenem imenu. Principi metode FFP niso opisani posebej, ker so podobni metodi COSMIC-FFP. V literaturi zasledimo, da standardna metoda FPA ne prikaže adekvatnih rezultatov pri merjenju aplikacij sistemov v realnem času, saj se le-te razlikujejo od poslovnih sistemov, za katere je bila razvita standardna metoda FPA. Pri aplikacijah sistemov v realnem času je veliko podprocesov, kar ne ustreza standardni metodi FPA. Metoda COSMIC-FFP upošteva podprocese znotraj unikatnega procesiranja tako, da identificira podatkovne skupine podatkov, ki jih podproces prejme, pošlje, bere ali zapiše. Posledica tega je večje število funkcijskih točk ob koncu merjenja, kar pomeni adekvatnejšo meritev obsega funkcionalnosti merjene informacijske rešitve. Standardni metodi FPA se očita neprimernost faktorja prilagoditve, ki ne prikaže pravih rezultatov za sisteme v realnem času, zato so v teku pogajanja za modifikacijo faktorja prilagoditve oz. njegovo ukinitev. Vzrok za nastanek razlik Razlogi za razlike so pri podatkovnih in transakcijskih funkcijah: . podatkovne funkcije: v sistemih v realnem času je veliko podatkovnih skupin, ki vsebujejo le en zapis. Slednje je težje opisati s pomočjo podatkovnih funkcij ILF in EIF standardne metode FPA; . transakcijske funkcije: sistemi v realnem času vsebujejo veliko podprocesov znotraj ene transakcije. Naslednji primer kaže vpliv velikega števila podprocesov na štetje funkcijskih točk: Glavni proces sistema v realnem času ima nalogo prikazati količino tekočine. Identificirani so trije podprocesi: . senzor odčita količino tekočine; . količina se primerja glede na dovoljene meje; « pošiljanje sporočila v primeru odstopanja od dovoljene meje. Identificirani so trije podprocesi. Pri standardni metodi FPA bi bila v tem primeru identificirana le ena transakcijska funkcija, ker je treba upoštevati navodilo, da se identificira transakcijska funkcija takrat, ko gre za elementarni proces (vsi trije podprocesi tvorijo zaključeno celoto). 7.3 Standardna metoda FPA - metoda NESMA Podobnost metod se kaže v naslednjih stičnih točkah: ■ uporabljata pet funkcijskih tipov (El, EO, EQ, ILF, EIF); . uporabljata enake tabele za določevanje kompleksnosti; . uporabljata 14 splošnih sistemskih karakteristik za določevanje faktorja prilagoditve; . uporabljata in določata sledeče koncepte: . neprilagojena vrednost funkcijskih točk UFP; . faktor prilagoditve; ■ prilagojena vrednost funkcijskih točk AFP. Kot je možno razbrati, metodi uporabljata enake koncepte in enako metodologijo merjenja obsega funkcionalnosti. Pomembneje sta se razlikovali na začetku nastanka metode NESMA, sedaj lahko glavne razlike strnemo le v nekaj točkah: - možnost povpraševanja s spremenljivim izhodom, kar pomeni, da uporabnik na vhodu določi, katere podatke bo pridobil s povpraševanjem. Standardna FPA prepozna tako transakcijsko funkcijo kot zunanje povpraševanje, saj ni dodanega nobenega sestavljenega polja oz. polja, pridobljenega s kakršno koli kalkulacijo. NESMA določa takšen tip funkcije kot zunanji izhod, saj uporabnik pridobi podatke spremenljive velikosti. . velikokrat je treba uporabniku prikazati podatke, preden jih izbriše oz. spremeni. Tako uporabnik vidi, kateri podatki se bodo spremenili. Tako prikazovanje podatkov se imenuje implicitno povpraševanje (implicit inquiry). Kako obravnavata tako funkcionalnost obe metodi? Standardna FPA šteje tako povpraševanje kot zunanje povpraševanje, če slednje zahteva uporabnik. Metoda NESMA šteje tako povpraševanje kot dodatni EQ le v primeru, če uporabnik zahteva prikazovanje posebne oblike. V nasprotnem primeru upošteva implicitno povpraševanje kot del algoritma za brisanje oz. shranjevanje spremenjenih podatkov. 8 Zaključek Določanje obsega funkcionalnosti je metoda, ki pomaga pri upravljanju informacijske rešitve in stroškov znotraj organizacije. Izbira ustrezne metode je opravilo, ki se ga je treba lotiti preudarno. Pa vendarle je najbolj pomemben prvi korak, ko se odločimo za merjenje z eno od metod določevanja obsega funkcionalnosti. S prikazovanjem obsega informacijske rešitve s pomočjo enote funkcijskih točk bomo pridobili na več področjih znotraj organizacije: . možnost natančnejšega planiranja potrebnih virov za dokončanje projekta; b možnost izvajanja resnih analiz na nivoju uprav-ljalca projektov; . izdelava poročil na najvišjem nivoju vodstva, saj je razumljivejši pojem obseg funkcionalnosti kakor število vrstic programske kode, ki v poročilih privedejo tudi do nekonsistentnih rezultatov. Primerjave metod prikažejo prednosti oz. slabosti posamezne metode. Ugotovili smo, da je standardna metoda FPA primerna za informacijske rešitve poslovnega sveta in kot taka ne daje zadovoljivih rezultatov pri aplikacijah sistemov v realnem času. Pri le-teh se bolj izkažeta metodi MK II FPA in metoda COSMIC-FFP. Poplava različnih metod bi lahko odvrnila morebitne uporabnike merjenja s funkcijskimi točkami in obratno: če bi obstajala močna baza, ki bi promovirala merjenje s pomočjo funkcijskih točk in skrbela za njihov razvoj, bi tovrstno merjenje pridobilo na popularnosti, kar bi posledično pomenilo izboljšanje metode in splošno zadovoljstvo uporabnikov. Velik korak je storjen že, če se zavedamo potrebe merjenja v svetu informacijskih rešitev, saj brez merjenja ni mogoče izvajati ustreznega nadzora. 9 Literatura [1] Abram Alain, Jean-Marc Desharnais, Serge Oligny, Denis ST-Pierre, Charles Symons: COSMIC-FFP Measurment Manual, version 2.1, Maj 2001 [2] Arifoglu.A.: A Methodology for Softvvare Cost Estimation. Software Engineering Notes, 1993 [3] Garmus David, Flerron David: Function Point Analysis, Addison-Wesley, 2000 [4] Guidelines to Softvvare Measurement - Release 1.1, 1996, IFPUG [5] Flo, V.T., Abran, A., Oligny, S.: Usirig COSMIC-FFP to Quantify Functional Reuse in Software Development, in Escom-Scope 2000, April 18-20, 2000 [6] Hurten Robert: Function-Point Analysis - Theorie und Praxis, Expert Verlag, Renningen-Malmsheim, 1999 [7] IFPUG Function Point Counting Practices Manual -Release 4.1, januar 1999, IFPUG [8] IFPUG Function Point Counting Practices: Čase Study 1 -Release 1.0, 1994, IFPUG [9] IFPUG Function Point Counting Practices: Čase Study 3 -Release 1.0, 1994, IFPUG [10] IFPUG Guidelines to Softvvare Measurement - Release 1.1, 1996, IFPUG [11] Jones, Capers: Backfiring - Converting Lines of Code to Function Points, IEEE Computer 28, 11, November 1995: 87-8 [12] Krishna C. M., KangG. Shin: Real-Time Systems, McGravv-Hill, 1997, str: 1-39 [13] Meli, R., Abran, A., Ho, V.T., Oligny, S.: On the Applicability of COSMIC-FFP for Measuring Softvvare Throughout its Ufe Cycle, in Escom-Scope 2000, April 18-20 [14] Netherlands Softvvare Metrics Association (NESMA): Definitions and Counting Guidelines for the Application of Function Point Analysis, Version 2.0. Amsterdam, 1997 [15] Symons Charles: Conversion betvveen IFPUG 4.0 and Mkll FPA Function Points -Version 3.0, Softvvare Measurement Services Ltd, 1999 [16] United Kingdom Softvvare Metrics Association (UKSMA): MK II Function Point Analysis - Counting Practices Manual, version 1.3.1, UKSMA, september 1998 Tomaž Kralj je leta 1997 diplomiral na Fakulteti za elektrotehniko, računalništvo in informatiko Univerze v Mariboru, 2002 pa je na tej fakulteti končal podiplomski študij z zagovorom magistrskega dela. Kot svetovalec direktorja Davčne uprave Republike Slovenije je zaposlen na Davčnem uradu na Ptuju. POROČILA 0 Globalni dostop do EAN identifikacijskih številk Damjan Kosec Hermes plus, d. d. Šlandrova 2, Ljubljana Izvleček Elektronsko poslovanje se vse bolj integrira s klasičnim. Poslovanje brez uporabe informacijskih tehnologij ni več mogoče, saj ne moremo postati konkurenčni brez hitrega dostopa do informacij. V članku je opisano združenje EAN Slovenija, član združenja EAN International, v katerega je vključenih 96 organizacij z vsega sveta. Ker vsaka od teh organizacij vzdržuje svojo bazo podatkov o članih, je bilo treba najti rešitev, kako hitro in učinkovito dostopati do podatkov. Zato je združenje EAN izdelalo rešitev GEPIR, elektronski katalog vseh članov. V GEPIR prek spletnega pregledovalnika vnesemo zahtevo po podatkih o podjetju, spletni strežnik zahtevo procesira ali generira XML zahtevo in jo pošlje drugemu strežniku. Ta XML zahtevo sprejme, jo procesira z izvedbo ustrezne SOL poizvedbe v lastno podatkovno zbirko in vrne XML odgovor, ki se pretvori v HTML obliko, ta pa se prikaže v spletnem pregledovalniku. Rešitev omogoča 24-urni učinkovit in hiter dostop do podatkov. Ključne besede: GEPIR, XML, elektronski katalog, spletne storitve Abstract Global flcces to EAN Identification Numbers Today electronic business is becoming integral part of classical business. Business vvithout the use of various information technologies is not feasible, for it is impossible to imagine competitiveness vvithout a prompt access to ali the information needed. The article represents the EAN Slovenia association, a part of EAN International association, vvhich comprises 96 organizations from ali over the vvorld. Each organization supports their own member’s database, therefore it was imperative to find a way to a prompt/guick and accurate access to the data. Consequently, the GEPIR association prepared an electronic catalogue of ali the users. VVith GEPIR application, we can search for any company through web brovvsers. The web server responds to that reguest or forvvards it to another web server anywhere in the vvorld. VVhen the server, that holds the desired information, is found, an ansvver is sent back to the brovvser, vvhich is finally displayed to a user in a HTML form. This application thus allovvs an around the clock access to the desired information. Key VVords: GEPIR, XML, electronic catalogue, Web Services 1 Uuod Danes si težko predstavljamo učinkovito in produktivno poslovanje podjetij brez uporabe informacijskih tehnologij. Elektronsko poslovanje se uvaja v vse dimenzije poslovanja podjetij in ga lahko opredelimo kot izmenjavo poslovnih informacij prek omrežij s pomočjo računalniške izmenjave podatkov (EDI) in vseh podobnih tehnologij. Elektronska pošta, elektronske oglasne deske, faksimilni stroji, EFT transferi so tipične oblike elektronskega poslovanja. Pri tem EDI (angl. electronic data interchange) oziroma RIP (računalniška izmenjava podatkov) označuje standardizirane oblike izmenjave poslovnih informacij (http://www.ris.org/ep/epodef.html). Slovenska podjetja s težavo dohajajo evropska in ameriška v učinkovitosti poslovanja in doseganju tržnega deleža. Zaradi slabe organiziranosti, velikih stroškov poslovanja, nizke produktivnosti in majh- nega vlaganja v razvoj izgubljamo tržni delež na zahtevnejših trgih Evropske unije in ZDA. Za izboljšanje tega stanja bo treba izbrati pravilno strategijo ter iskati priložnosti in ideje predvsem v integriranju sedanjega poslovanja z informacijsko tehnologijo. Elektronsko poslovanje ponuja Sloveniji izvrstno priložnost za hiter gospodarski razvoj in njenemu gospodarstvu enakopravno tekmovanje z veliko večjimi državami, saj ravno v elektronskem svetu velikost povsem izgublja svoj pomen. Podjetja na trgu ponujajo veliko informacijskih rešitev, ki pa jih je treba pravilno izkoristiti. Najbolj pogost strandard za prenos podatkov po internetu je XML (angl. extensible markup language), ki je idealna rešitev, saj je XML tekstovni format in je združljiv z vsemi operacijskimi sistemi. Trend v elektronskem poslovanju je predvsem B2B (angl. Business to Business) poslovanje, saj podjetja s pravočasnimi in točnimi podatki dosegajo nižje stroške in večjo kvaliteto, kar povečuje konkurenčnost. Naj Bolj pogoste rešitve s področja medpodjetniških integracij so rešitve, ki nudijo aplikacijsko integracijo (Microsoft Biztalk Server, IBM VVeBsphere, RosetaNet, BeaVVeBLog itd.) 2 Predstavitev podjetja EAN Slovenija EAN (angl. european article numBer) International je mednarodno združenje, ki razvija sisteme za identifikacijo izdelkov, storitev, naslovov, prodajnih in transportnih enot. Prav tako razvija sistem računalniške izmenjave poslovnih dokumentov med udeleženci preskrbovalnih verig vsega sveta, ki temelji na tej identifikaciji. EAN International, s sedežem v Bruslju v Belgiji je združenje 96 organizacij iz 98 držav z vseh celin. Skupaj s svetom Uniforme Code Council (UCC), ki pokriva ZDA in Kanado, vodi globalni sistem za identifikacijo izdelkov, storitev, lokacij, transportnih enot in pripomočkov in svojih 900.000 članov po svetu oskrbuje s potrebnimi elektronskimi komercialnimi standardi (EAN.SI, april 2002). EAN International vključuje organizacije po vsem svetu in ker vsaka organizacija vzdržuje svojo bazo podatkov o članih, je bilo zamudno in težavno priti do točnih podatkov. Klasične rešitve so bile telefonski klic, faks, elektronska pošta itd. Te niso omogočale učinkovitega poslovanja, zato je bilo treba izbrati drugo strategijo za dostop do podatkov. Za identifikacijo izdelkov uporabljamo EAN identifikacijske oznake različnih tipov. EAN Slovenija dodeljuje naslednje oznake: • EAN.UCC 13 - v veliki večini se članom podeljuje ta tip številk, in sicer v treh različnih skupinah: . Gl, ki omogoča označevanje do 1000 artiklov, • G2, ki omogoča označevanje do 10000 artiklov, • G3, ki omogoča označevanje do 100000 artiklov • EAN.UCC 8 se uporablja za označevanje zelo majhnih predmetov (artiklov); te oznake se dodeljujejo za vsak artikel posebej, • variabilna vsebina, ki se uporablja v primerih, ko je v kodi treba označiti težo ali ceno artikla. Te kode se dodeljuje v paketih, . UPC - kadar podjetje izvaža v ZDA, se mu lahko dodeli ameriško 12-mestno kodo UPC, . lokacijska številka določa lokacijo podjetja; dodeli se iz sklopa številk EAN.UCC 13. 3 Priložnosti elektronskega poslovanja v EAN International Ko govorimo o elektronskem poslovanju, ne moremo mimo elektronske izmenjave podatkov EDI ali RIP. EDI lahko definiramo kot izmenjevanje poenotenih, kodiranih sporočil med dvema računalniškima rešitvama (aplikacijama). Princip delovanja računalniške izmenjave je tak, da se vsak poslovni dokument pretvori (kodira) v strukturirano elektronsko sporočilo, ki ga je mogoče po elektronski poti poslati kamorkoli. Prejemnik takšnega sporočila natančno ve, kako je sporočilo sestavljeno in ga lahko po obratni poti dekodira v dokument. Za prenos sporočil je potreben standard in EAN je že pred časom začel uvajati standard EANCOM, ki je povzetek standarda EDIFACT, vendar se je v Sloveniji bolj slabo uveljavil. Zaradi velikih stroškov izvedbe se vse bolj uveljavlja XML. XML je razvil konzorcij VVorld VVide Web. XML določa standardiziran način opisa podatkov. Ker so podatki v tekstovni obliki, lahko brez problemov prehajajo čez omrežja ter delajo z raznimi tipi operacijskih sistemov. (Homer, 2000) V EAN International ne vidijo XML kot zamenjave za EDIFACT, ampak verjamejo, da bo implementacija le-tega v naslednjih petih do desetih letih rasla, in da bosta XML in EDIFACT uporabljana kot dopolnilna standarda. (Novice, december 2000) Microsoftove rešitve, ki se trenutno uporabljajo na trgu za B2B poslovanje, so Microsoftov BizTalk strežnik in spletne storitve. BizTalk strežnik je skupina orodij, ki omogočajo B2B izmenjavo podatkov. Opredelimo ga lahko kot vmesnik (kanal), ki prenaša sporočila med udeleženci komunikacije. Sporočilo je lahko v kateremkoli formatu, vendar je najpogosteje uporabljan XML format. Udeleženci komunikacije so lahko podjetja, komponente, aplikacije ali deli operacijskih sistemov. BizTalk podpira veliko protokolov za prenos podatkov. Ti so: SMTP, FTP, HTTP, HTTPS, MSMQ in X.4G0. BizTalk strežnik 2000 temelji na BizTalk ogrodju (angl. framevvork). To je odprto ogrodje za B2B poslovanje in je vgrajeno v večino večjih B2B produktov. Strežnik BizTalk lahko uporabljamo v naslednjih primerih: • integracija trgovanja med podjetji: spletno ali tradicionalno internetno izmenjevanje podatkov (EDI), integracija osrbovalnih verig, upravljanje naročanja ter koordinacija dostave; . avtomatska nabava: spremljanje naročil; . B2B portali: trgovske skupnosti, upravljanje elektronskih katalogov, postprodajno upravljanje s ku pci; . integracija ali izmenjava poslovnih procesov (http://www.microsoft.com/biztalk/). Druga pomembna rešitev, ki se vedno bolj uporablja, so spletne storitve (angl. web Services), ki omogočajo dostop do programskih komponent prek standardnih web protokolov, kot so HTTP, HTTPS, SOAP in GXA. Z uporabo XML lahko izvajamo programske komponente prek interneta z drugimi sistemi neodvisno od programskega jezika, operacijskega sistema ali regionalnih nastavitev. Spletne storitve so podobna rešitev kot DCOM z razliko, da so dostopni širšemu krogu odjemalcev. COM (angl. component object model) komponente so lahko uporabljali le odjemalci temelječ na Win32 arhitekturi, spletne storitve pa lahko izvajajo odjemalci z vgrajenimi ustreznimi vmesniki za podporo spletnim storitvam. XML je ključna tehnologija v spletnih storitvah in se uporablja v naslednjih področjih Microsoft.NET ogrodja za spletne storitve: . web Service wire format omogoča univerzalno razumevanje izmenjave podatkov med ponudnikom spletnih storitev in uporabnikom ter določa format podatkov v zahtevi in odgovoru. Spletne storitve trenutno podpirajo tri protokole: HTTP GET, HTTP POST in SOAP (angl. simple object accesss protocol); . web Service description in WSDL (angl. web Service description language) - jezik, ki opisuje, kako lahko uporabljamo spletne storitve; . web Service discovery - proces oglaševanja in objave dela programa kot storitve in omogočanje odkritja te storitve na internetu. Varnost v spletnih storitvah izvajamo na dveh ravneh: . sistemska varnost - ena od metod, ki jo omogoča operacijski sistem Windows (basic authentication, basic over SSL authentication, digest authentication, integrated windows authenticatin, client certificates authentication); . aplikacijska varnost. (Thai, 2001) Po poročilih IDC (hčerinskega podjetja CXO Mcdia Inc.) naj bi podjetja v letošnjem letu porabila za elektronsko trgovanje 7 milijard dolarjev. Po oceni podjetja Jupiter Media Metrix pa naj bi se 53 odstotkov menedžerjev na področju informacijske tehnologije v tem letu odločilo za uporabo spletnih storitev v podjetju, saj si ne morejo privoščiti, da bi vsako rešitev razvijali od začetka, ampak jih bodo integrirali s spletnimi storitvami. Tako kot pri večini tehnologij bodo minila leta, preden se bodo spletne storitve uporabljale v B2B poslovanju, saj smo še daleč od vizije, v kateri bodo podjetja namesto izvajanja poslovnih informacijskih rešitev v hiši, uporabljala omrežja spletnih storitev. (Varon, 2001) 4 Elektronski katalogi Zaradi kompleksnosti organizacije EAN International, ki vključuje organizacije po vsem svetu, in katerih vsaka vodi svojo bazo podatkov o uporabnikih, je bilo treba najti rešitev, kako hitro in učinkovito dostopati do točnih podatkov. Rešitev so vsem dostopni elektronski katalogi. Zanimanje zanje se je v zadnjih letih zelo povečalo, glavni razlog je ekspanzija elektronskega poslovanja in potreba po odprtosti in dosegljivosti podatkov predvsem v mednarodni trgovini. Dolgoročni cilj EAN International je omogočiti združljivost in povezanost elektronskih katalogov po vsem svetu. "E-katalog je repozitorij podatkov, kjer poslovna partnerja dobita, vzdržujeta in si izmenjujeta informacije o vsakem proizvodu, storitvi ali lokaciji v standardnem formatu na elektronski način." (Šafarič, 2000) Elektronskih katalogov je več vrst, glavni so vsekakor katalog lokacij, izdelkov in storitev. Obstajajo pa tudi specializirani katalogi, ki so aktivni v ožji skupini partnerjev, (www.gepir.com) Prednosti elektronskih katalogov: . uveljavitev standardne identifikacije prodajnih artiklov v celotni preskrbovalni verigi, . podpora pri usklajevanju matičnih podatkov med poslovnimi partnerji, . večja ažurnost skupnih podatkov, . podpora elektronskemu naročanju, . možnost izdelave optimalnejše predkalkulacije, • možnost avtomatskega iskanja optimalne cene prodajnih enot. Nekatere osnovne definicije, ki se nanašajo na elektronske kataloge, so: . Element (angl. item) je katerikoli artikel ali storitev, o kateri je treba pridobiti nekatere vnaprej določene podatke. Značilno za element je, da ima lahko ceno, da se ga lahko naroči ali plača v kateremkoli delu preskrbovalne verige. . Lokacija (angl. party/location) je katerakoli legalna funkcionalna ali fizična enota, ki je na katerikoli točki vključena v preskrbovalno verigo in za katero je treba pridobiti podatke. . Matični podatki (angl. master data) so skupina podatkov, ki opisujejo in specificirajo vse elemente in lokacije, vključene v preskrbovalno verigo. Vsak podatek je enolično določen z identifikacijsko oznako za artikel (GTIN) ali za lokacijo (GLN). Matične podatke lahko razdelimo na neodvisne (nevtralne) in odvisne. Neodvisni so tisti podatki, ki jih uporabljajo vsi sodelujoči partnerji (identifikacijska oznaka, opis artikla, mere artikla, standardni pogoji, naslovi itd.). Odvisni podatki pa so tisti, ki so medsebojno dogovorjeni med posameznimi partnerji (na primer pogoji prodaje, posebne cene, popusti, rabati, logistični pogoji in podobno). . Usklajevanje matičnih podatkov (angl. master data aligment) je proces, s katerim se redno ažurira vsebina kataloga, distribuiranje in sinhroniziranje ažuriranih podatkov. Kvalitetno identificiranje artiklov in storitev je prvi pogoj za poravnavanje podatkov, saj je samo tako možno enolično identificirati posamezni artikel ali storitev. (Šafarič, 2000) Vsi elektronski katalogi morajo vsebovati naslednje funkcije: . vpis matičnih podatkov, . spreminjanje matičnih podatkov, « dodajanje novih elementov in lokacij, . brisanje nepotrebnih elementov in lokacij, e planiranje dosegljivosti elementov (od kdaj do kdaj bo element dosegljiv). Usklajevanje je proces, s katerim se zagotovi ažurnost podatkov na vseh lokacijah. To je tudi ključni namen elektronskih katalogov. Zahteve za uspešno poravnavanje podatkov v elektronskem katalogu so: . Enotnost oziroma usklajenost med posameznimi elektronskimi katalogi. Načeloma mora veljati, da povezave med katalogi sestavljajo en sam velik logični e-katalog. e Pri izmenjavi podatkov med trgujočimi strankami ne sme priti do nikakršne izgube podatkov. e Dostopnost do podatkov mora biti ciljno naravnana. . Varnost dostopa mora biti zagotovljena z uporabniškimi profili, gesli in ključi tako, da se zanesljivo identificira vsak partner in omogoči dovoljen dostop do podatkov. (Novice, december 2000) 5 Elektronski katalog lokacij nosilcev Efll\l številk Lokacije EAN so naslovi in osnovni podatki nosilcev identifikacikih številk EAN, ki jih morajo dati člani združenja EAN ob včlanitvi, so torej nekakšen register podjetij. EAN International je leta 1999 odprl projekt elektronskega kataloga z imenom GEPIR (angl. global EAN.UCC party information register), v katerem morajo sodelovati vse nacionalne organizacije. Ta katalog naj bi bil javen, koncipiran pa tako, da lahko preko EAN številke kateregakoli artikla dobimo nosilca te številke. Cilj projekta je pospešiti dostop do podatkov o nosilcih, saj podjetja pogosto potrebujejo zelo hitre in natančne podatke o nosilcih. Vsaka nacionalna organizacija dobiva zahteve za podatke tako o lokalnih kot mednarodnih EAN nosilcih in razumljivo je, da je precej nerodno iskati te številke po telefonu, faksu ali elektronski pošti. Ta katalog omogoča dostop do podatkov prek interneta (URL naslov je www.gepir.org) komurkoli in kadarkoli. GEPIR temelji na internetnem protokolu HTTP in XML. Nacionalne podatkovne baze morajo biti povezane s spletnimi stranmi, prek katerih se vpisujejo in izvajajo poizvedbe. Poizvedbe in rezultati se prenašajo v formatu XML. Rešitev tehnično ni zahtevna in jo je razmeroma preprosto integrirati v informacijski sistem. Pogoja za vzpostavitev sta: e podatkovna baza članov, e lastna spletna stran. Prednosti internetne rešitve so tudi naslednje: e Uporabniki delajo v svojem običajnem okolju. e Sistem je neodvisen od podatkovnih struktur v podatkovnih bazah. e Prav tako je neodvisen od tipa podatkovne baze (SQL Server, Oracle). e Neodvisen je tudi od programske (Windows, UNIX) in strojne opreme. e Omogoča preprosto komunikacijo med podatkovnimi strežniki nacionalnih organizacij. . Omogočea preprosto dodajanje novih povezav. (Šafarič, Novice) B GEPIR Rešitev GEPIR omogoča prostovoljno izmenjavo podatkov. Uporabnik, ki se poveže z lokalnim elektronskim katalogom z namenom, da pošlje zahtevo, dela lokalno ne glede na to, kateremu elektronskemu katalogu pošljemo zahtevo. Odločitev, ali zahtevo pošljemo naprej v povezan (angl. inter-connected) katalog, sprejme lokalni strežnik. Rešitev GEPIR se nahaja na spletni strani www.gzs.si/ean-gepir. Izdelana rešitev se sestoji iz večnivojske ureditve odjemalec-strežnik, ki si izmenjujeta zahteve in odgovore v obliki XML dokumentov z uporabo HTTP protokola po diagramu na naslednij strani: Ko prek spletnega pregledovalnika pošljemo zahtevo po GLN številki na lokalni strežnik, ta na podlagi EAN predpone države obdela zahtevo, če je predpona 383 (Slovenija) ali generira XML zahtevo, ki jo pošlje drugemu strežniku. Ta strežnik XML zahtevo sprejme, jo procesira z izvedbo ustrezne SQL poizvedbe v lastno podatkovno zbirko in vrne XML odgovor, ki se prek XSL (angl. extensible stylesheet language) transformacije pretvori v HTML in prikaže na spletnem pregledovalniku. Predpone držav so shranjene v xml datoteki, kjer so shranjeni tudi drugi podatki: URL naslov, kamor naj pošlje zahtevo, EAN Primer opisa države v KML datoteki: FR 30 37 Gencod - EAN France 3027000000100 annuaire.eannet-france.org/php/gepir_srv.php www.eannet-france.org/fille/e/e2.htm Christian Lenoir clenoir@gencod-ean.fr 2.0 predpona, kratica države itn. Ker je seznam držav v tekstovni datoteki, ga lahko enostavno dopolnjujemo in ažuriramo. Zahteve za strežnik so: . Iskanje podatkov o podjetju na osnovi GTIN ali SSCC je iskanje na osnovi EAN/ UPC kode enega od petih tipov (EAN.UCC 8, EAN.UCC 13, EAN.UCC 14, UPC12, SSCC). • Iskanje podatkov o podjetju na osnovi GLN omogoča uporabniku iskanje po globalni EAN/UPC lokacijski številki. . Iskanje podatkov o podjetju na osnovi imena podjetja omogoča poiskati podjetje na osnovi besede ali dela besede iz imena podjetja. Zahtevan je vnos najmanj treh znakov. Iskanje lahko omejimo tudi na kraj ali poštno številko podjetja. V vseh primerih je treba vnesti celo število ali zadostno število znakov za enolično EAN številko. Rešitev zaradi omejitve velikega prenosa podatkov vrne le prvih 20, čeprav je zadetkov več. Pri rešitvi je treba poskrbeti za osnovne varnostne ukrepe, najbolj pomembno pa je, da ne pride do vdora v podatkovne baze in do uničenja ali spremembe podatkov. Elementi v XML zahtevi, ki jo pošljemu zunanjemu strežniku, so: Ime elementa Opis elementa T0095 GLN lastnika zahteve TYPE 1 - iskanje po GTIN ali SSCC 2 - iskanje po GLN 3 - iskanje po imenu SUBTYPE Za tip 1: 8 - iskanje po EAN-8 12 - iskanje po UPC-12 13 - iskanje po EAN-13 14 - iskanje po EAN-14 18 - iskanje po SSCC privzeto - vsak zadetek Za tip 2: 0 - iskanje po GLN 1 - iskanje po glavnem GLN 2 - iskanje seznama GLN številk podjetja VAL Vrednost iskanja ZIP Vsaj 3 znaki poštne kode CITY Vsaj 3 znaki imena kraja podjetja CASCADE število nivojev iskanja po strežniku (privzeto 10). Vsak strežnik, ki poda iskanje naprej drugemu strežniku, zmanjša to število za 1. Strežnik, ki dobi število 1, prekine iskanje. m:. : E*» £d* X»w Favorit »s Iook tj* ra 4-rBack - -♦ • & 3 -3 ^Ssarch _jJFavcr*« ^ ^ ~ši ’ _d Ajdres* http:/Vivww.gz$.s/ean-9epr/t**(t!.a$.pdangua9<'-Sl ~3 ** EAN m SLOVENI JA «< Naz^i na glavno stran TIP ISKANJA-------------- r iskanje po 13 mestni kodi (GTIN ali S5CC) C iskanje po lokacijski kodi (GLN) '• n mje po imenu pod GEPIR EAN SLOVENIJA VNOS ZAHTEVE lasal LOKACIJA PODJETJA I India 3 & Mesto G PoSta ti Cone o Vsi tipi- Iskanje samo sa Slovenijo o GLN-globalna lokacijska številka o SSCC-1S mestna številka o Variabilna vsebina- začne se s 25 ali 26 MČ M BC R O F EAN M IN T E R N ATI O N A t •C lrternct Slika 1: Rešitev GEPIR - iskanje podjetja Asa v Indiji (strežnik generira KML zahtevo in pošlje po internetu do zunanjega strežnika) Elementi v XML odgovoru, ki ga pošlje zunanji strežnik lokalnemu strežniku, so: Ime elementa Opis elementa T0093 Število zadetkov T095 GLN imetnika, ki je dal odgovor T0212 EAN Identifikacijska številka podjetja T0213 Ime podjetja T0214 Naslov podjetja T0215 Kraj podjetja T0217 Poštna številka podjetja To218 Številka države TD219 Kontaktna oseba T0220 Telefon kontaktne osebe T0221 Fax kontaktne osebe T0222 Elektronska pošta kontaktne osebe T0223 X.400 kontaktne osebe T0224 URL za splošne podatke T0225 URL za dodatne podatke T0226 URL za podatke o produktu T0232 Kode napak od 0 do 8 T0233 EDIFACT kodna lista za 3035 T0234 Lokacijska številka podjetja, na zahtevo katerega je bila izvršena T0234 7 ZAKLJUČEK Z rešitvijo GEPIR je EAN International omogočil vsem združenjem po svetu in drugim uporabnikom enostaven in hiter dostop do točnih podatkov. Vsak uporabnik lahko prek EAN identifikacijske številke, ki jo najde na izdelku, enostavno poišče podjetje, ki izdeluje ta izdelek in dobi druge podatke o podjetju, npr. kontaktno osebo. Pridobivanje teh podatkov po telefonu ali faksu je bilo zamudno in je dodatno obremenjevalo zaposlene na EAN-u. Rešitev je sestavljena iz ASP (angl. active server pages) in HTML (angl. hypertext markup language) spletnih strani, za prenos podatkov pa uporablja standard XML, ki ni odvisen od operacijskega sistema in od podatkovnih baz, ki jih imajo združenja. Z uporabo te rešitve so se združenja spojila v virtualni elektronski katalog. Rešitev je enostavna in uporabna, saj omogoča nemoten in enostaven dostop do informacij po vsem svetu. Rešitev GEPIR se nahaja na spletni strani www.gzs.si/ean-gepir. £Bxk * "♦ - £ jk| {3 $5*»* JJFevot*« $Me<*a J) LJjt V3 _J AjJOre« http://ww.9zs $i,kflr>-<)fpff/Re$uk.»sp?langi>»Qe»SI 3 iUnke * EAN »" SLOVENI JA [Posredoval: 8900000000005 [Število zadetkov: 20 Napaka: Več kot 20 zadetkov Omejite iskanje! KLIKNITE NA IME PODJETJA! M.MOTILAL MASALAWALA KANTILAL KESHAVJ1 MASALAWALA KUSUM MAS A LA PRODUCTS. VASAMTDADA SHETKARI SAH. SAKHAR KARKHANA LTD. PRAVI N MASALEVVALE OKASA PHARMA LTD, OKASA LTD, SIPCO MASALAS LTD. SP E E SREENIVASA FRU1T PROCESSING 1NDUSTPV KARfMBHAI HA5ANBHAI &■ SONS S£SfclASA:v££J!AP££^m.&QABDS LIMITED GEPIR EAN SLOVENIJA PODJETJE EAN številka Ime podjetja Poštna Številka. Drugi naslov. Koda države 3901017000002 M.MOTILAL MASALAWALA 405, GRANT ROAD 400007 MU MB Al OPP NOVELTV CINEMA IN KONTAKTNA OSEBA Kontaktna oseba: MR. A.PATEL Telefon 91-22-3746324 DODATNE INFORMACIJE X 400: URL splošne ml: URL dodatne inf: URL inf o produktu EDI FACT koda EDI FACT kodo zahteval: M j M | £ R O F EAN 1 IN IE R N ATION Al igj Oon<. O Internet Slika 2: Aplikacija GEPIA - transformirani XML odgovor in prikaz v pregledovalniku Literatura 1. Homer, A. (2000). Alex Homer’s Professional ASP 3.0 Web Techniques, Wrox Birmingham. 2. Konda, Z. (2002). Intervju Henri Barthel, EAN.Sl, april 2002, št. 4, str. 4-5. 3. Šafarič, B. (2000). Elektronsko poslovanje, izmenjava podatkov in mi, EAN Slovenija - Novice, št. 2, str. 6-8. 4. Toplišek, J. (1988). Elektronsko poslovanje, Atlantis. 5. Thai, T., Hoang Lam, Q. ( 2001). NET Framevvork Essentials, 0’Reilly. 6. Varon, E. (2001). Hury Up and Wait; CIO Magazine, November 2001. 7. www.geoir.com , 22. 8. 2002. 8. www.microsoft.com/biztalk/. 22. 8. 2002. Damjan Kosec je diplomiral na Fakulteti za organizacijske vede, smer organizacijska informatika. Vpisan je v drugi letnik podiplomskega študija management elektronskega poslovanja. Zaposlen je v podjetju Hermes plus, d. d., kjer dela na oddelku za elektronsko poslovanje. POROČILA B Certifikat za razvijalca KML tehnologij Boris Milikič Ministrstvo za finance, Služba za informacijsko tehnologijo Župančičeva 3,1000 Ljubljana boris.milikic@mf-rs.si Povzetek Certifikat odraža izkušnje, znanje in zmožnosti za opravljanje dela. Opisan je izpit za certifikat za XML in sorodne tehnologije. Potrebna je le odločitev za ponudnik-nevtralen ali ponudnik-povezan XML certifikat. Certifikati se uveljavljajo kot dopolnilo k formalni izobrazbi. Abstract Certification for KML Technologies Developer Certification shovvs the users exactly what you want them to know. It reflects your experience, your knovvledge, and your ability to perform the job. The article describes the certification for XML related technology. XML Certification will validate your XML experience and skills. The guestion is vendor-neutral or vendor-special XML certification. Certificates are becoming more popular as addition to formal education. Uvod Razvijalec KML aplikacij ima naloge načrtovanja in implementiranja aplikacij, ki omogočajo uporabo KML sorodnih tehnologij, kot so: KML shema, KSLT, KPath, KLink, KPointer itd. Razvijalec dobro razume osnove in koncepte KML tehnologije, povezavo med KML tehnologijami in podatki, posebno povezavo z KML shemo, KML procesiranjem, KML predstavitvijo in spletnimi servisi. Natančno pozna 1AI3C priporočila za KML tehnologije in ima praktično znanje. KML certifikat je namenjen korporacijskim IT strokovnjakom, IT svetovalcem, IT razvijalcem in arhitektom ter IT inštruktorjem. Osnove za opravljanje izpita Pred prijavo za izpit je treba preveriti zahtevnost izpita, potrebno predznanje, zahtevane izkušnje in razpoložljivost ponudnikov in centrov za izpit. Priporočena predznanja (pred začetkom priprave za certifikat) so: • izkušnje v programiranju v programskih in skript-nih jezikih, ■ razumevanje osnove računalniških modelov in podatkovnih modelov, . poznavanje XML sorodnih računalniških konceptov (drevesne strukture, DOM model, rekurziv-nost, ponovna uporaba kode, formatiranje-CSS), . poznavanje internetnih standardov in konceptov (odjemalec-strežnik, večnivojska arhitektura, HTML, brskalnik, spletne aplikacije, JSP, ASP), ■ izkušnje pri načrtovanju in implementaciji objektno orientiranih aplikacij, • izkušnje pri delu z relacijskimi bazami podakov. Ponudniki za certifikat iz XML in sorodnih tehnologij, ki ga je mogoče opravljati v Sloveniji v avtoriziranih centrih, so: . IBM (Tivoli-141 oz. XML AND RELATED TECHNOLOGIES), . HP (Star 1H0-722 -XML AND RELATED TECHNOLOGIES), . Microsoft (DEV XML VVEB SERVICES&SERVER COMP W/MS VIS VB.NET&MS.NET FARME-WORK, DEV XML VVEB SERVICES&SERVER COMP W/MS VIS C#.NET& MS.NET FRAME-WORK). Za test Star-722 je na internetni strani informacija, da je certifikat namenjen prodajalcem v HP, test DEV XML VVEB SERVICES je namenjen MS.NET okolju. Tivoli-141 je najbolj nevtralen test za XML in sorodne tehnologije. Glede na mojo usmeritev za Java okolje in s tem za (od platforme) neodvisen test sem izbral test IBM Certified Developer-XML and Related Technologies. Zato je nadaljevanje članka omejeno na test Tivoli-141. Ponudnik testa se v nadaljevanju nanaša na IBM. Ostali ponudniki XML testov omogočajo spletne teste (web based), pri katerih je vprašljiva njihova veljavnost oz. koliko so priznani. Prijava za izpit Podjetji, ki omogočata računalniški izpit za test in imata avtorizirane centre tudi v Sloveniji, sta: . VUE, Virtual University Enterprises Testing, http://www.vue.com/, . THOMSON-PROMETRIC, Inc., formerly Sylvan Prometric, http://www.2test.com. Za THOMSON-PROMETRIC je v Sloveniji na njihovi spletni strani šest testnih centrov: . QSTC, d. o. o., Železna cesta 18, 1000 Ljubljana, tel. 01 234 53 17, . SRC Sl, d. o. o., Tržaška cesta 116, p. p. 2988, 1111 Ljubljana, tel. 01 242 80 00, . UNISTAR LC, d. o. o., Kotnikova 32, 1000 Ljubljana, tel. 01 475 550, . REPRO MS, d. o. o., Šmartinska 106, 1001 Ljubljana, tel. 01 585 34 11, . IBM SLOVENIJA, d. o. o., Trg republike 3, 1000 Ljubljana, tel. 01 479 66 37, . KOMPAS XNET, Pražakova 4, 1514 Ljubljana, tel. 01 234 43 94. Za VUE je na njihovi spletni strani sedem testih centrov v Sloveniji: . ATLANTIS, d. o. o., Parmova 51, 1000 Ljubljana, tel. 01 475 07 21, ■ Housing Computers, d. o. o., Mlinska 22, 2000 Maribor, tel. 02 250 09 00, . Housing Computers, d. o. o., Vodovodna 100, 1000 Ljubljana, tel. 01 568 40 40, ■ LANCom, d. o. o., Tržaška cesta 63, 2000 Maribor, tel. 02 330 03 00, ■ Repro MS, d. o. o., Šmartinska 106, p. p. 4089, 1000 Ljubljana, tel. 01 585 34 11, ■ Unistar LC, d. o. o., Kotnikova 32, 1000 Ljubljana, tel. 01 475 55 02, . IBM Slovenija, d. o. o., Trg republike 3, 1000 Ljubljana, tel. 01 479 66 37. Pred prijavo vplačate vavčer, ki velja eno leto. Izpit opravljate v prostorih podjetja. S seboj morate imeti identifikacijski dokument s sliko. Odjava je možna pred naročenim datumom izpita. Plačilo je vezano na prijavo. Za odjave po določenem roku pred izpitom ali neopravljanje naročenega izpita zaračunajo polno ceno izpita. Vsebina testa Poudarek je predvsem na XML procesiranju, modeliranju in arhitekturi. Največ vprašanj je s teh področij. Vsebina testa po sekcijah: . arhitektura: XML načrtovanje, SAX2 parser, DOM2 parser, SOAP, VVSDL, UDDI, XML podpis, XML enkripcija, . informacijsko modeliranje: DTD shema, XML shema, pretvorba shem, . procesiranje: SAX2 API za obdelavo XML podatkov, DOM2 API za obdelavo XML podatkov, prečenje XML dokumenta z XPath, transformacija XML z uporabo XSLT, . XML upodabljanje: definiranje optimalnega upo-dabljanja/transformcije (npr. zaslon, tiskalnik, datoteka), uporaba XSLT in Formatting Objects za stiliziranje XML dokumentov, . testiranje in uglaševanje: določitev odgovarjajoče enkratne ali večkratne transformacije, optimiranje izvajanja XML aplikacije (npr. includes, import, id, idref, keys), kreiranje instanc za XML aplikacije (npr. na osnovi podatkovnega modela, mejnih vrednosti), načrtovanje modela aplikacije (na osnovi podatkovnega modela, integracije podatkov, upodobitve podatkov in iskanja podatkov). Priprava na test Ponudnik na svojih spletnih straneh navaja literaturo in spletne povezave za njo. Povezave na spletne strani, ki jih navaja ponudnik, in sem jih tudi sam uporabljal, so: ■ http://www.w3c.org/TR (W3C Technical Reports and Publications), . http://xml.apache.org (Apache XML Projekt: Xerces Java 2, Xerces C+ +, Xerces, Perl, Xalan Java 2, Xalan C++, POP, SOAP idr.), . http://www.ibm.com/developerworks/xml (XML Tools and products, Code and components, Education, Articles, Columns & Tips idr.), ■ http://www-l.ibm.com/certify/tests/saml41.shtml (XML and Related Technologies Pre-Assessment/ Sample Test 141), . http://www.w3schools.com (XML Tutorials: XML, XSL, DTD, DOM, WAP, XML Schema, XPath, XForms, SOAP, VVSDL), . http://www.xml.com/axml/axml.html (Tim Bray's annotated XML specification), . http://www.xml.org (applaying XML and web Services standards in industry), . http://www.javasoft.com/xml (JavaTM Technology and XML), . http://xml.oreilly.com/ (XML books, news & Articles), . http://www.whizlabs.com (IBM XML Certification - Test 141 Simulator), . http://www.boson.com (IBM XML and Related Technologies Exam #141), . http://msdn.microsoft.com/library/ (XML Web Services). Opravljanje testa Test je popolnoma računalniški in ga v centru, kjer opravljate, naložijo iz omrežja ponudnika na svoj računalnik. Zato je za prestavitev datuma opravljanja testa postavljen rok, ki je dan ali več pred testom. Opravljanje testa je enkratna ali večkratna izbira s potrditvijo polja. Pri večkratni izbiri vas program sam omeji na maksimalno število odgovorov. Število vprašanj se spreminja. Ko sem 25. novembra 2002 opravljal test, je imel 55 vprašanj. Test traja 90 minut. Za pozitiven rezultat oz. za opravljen test je bilo treba doseči vsaj 58 % pravilnih odgovorov. Izpit je obsežen. Kandidat sme imeti pri sebi samo svinčnik in prazen list papirja. Iskanje po priročnikih ne bi pomagalo, ker za to ni dovolj časa. Tehnika reševanja testa je enaka kot pri vseh računalniških testih: po zadnjem vprašanju naj ostane še 10-20 minut za markirana vprašanja in za hiter celoten pregled. Za dobro pripravo so nujni računalniški testi, ki simulirajo pravi test. Prednosti certifikata Certifikat pomeni prednost tako za zaposlenega kot za delodajalca. Za certifikacijo podjetja je lahko pogoj določeno število zaposlenih z opravljenim certifikatom znanja. Certifikat podjetja omogoča boljše nastopanje na trgu, pridobitev statusa poslovnega partnerja itd. V globalni ekonomiji imajo organizacije delavce zaposlene po vsem svetu, daleč od sedeža podjetja. Pri zaposlovanju na daljavo je certifikat lahko eno od zagotovil za ustrezno kvalifikacijo. Posamezniku se s pridobljenim certifikatom formalna stopnja izobrazbe ne zviša; ovrednotenje je torej v presoji delodajalca. Pridobljeni certifikat pa lahko pomeni prednost pri iskanju zaposlitve, še posebej če to delodajalec zahteva. Certifikat je potrditev, da razvijalec dobro razume osnove in koncepte XML in sorodnih tehnologij, natančno pozna W3C priporočila za XML in sorodne tehnologije in ima praktično znanje iz XML in sorodnih tehnologij, kot so XML shema, XSLT, XPath, XLink, XPointer. Sklep Izbran test in učenje XML in sorodnih tehnologij (XML sheme, SOAP, WSDL) je prvi korak do spletnih servisov. Pred uvajanjem spletnih servisov mora biti organizacija domača v XML formatiranju podatkov, ker to je ključ za povezovanje z drugimi aplikacijami. Učenje XML in sorodnih tehnologij (XML sheme, SOAP, VVSDL idr.) je šele začetek spletnih servisov. Boris Milikič je sodeloval kot svetovalec, razvijalec in programer v več projektih prenove in nadgradnje informacijskih sistemov v državni upravi in proizvodnih organizacijah. Zaposlen ja na Ministrstvu za finance v sektorju za informacijsko tehnologijo. Ima certifikat Java programerja, Java razvijalca in XML razvijalca. REŠITVE B Primer uspešne prenove delovnega procesa Franc Brcar, Andrej Kovačič Povzetek V članku opisujemo primer uspešne informatizacije delovnega procesa nabave računalniški strojne in programske opreme v večjem slovenskem podjetju. Med postopkom informatizacije smo proces preučili in delno prenovili. Postopek lahko razširimo tudi na poslovne procese. Abstract Operation procedure reengineering In this article, successful informatisation of hardvvare and softvvare procurement operation procedure in one of the largest Slovenian companies is described. During the informatisation process, the operation procedure was analysed and activities redesigned. The approach can be extended to business processes. 1 Uvod Tempo razvoja informacijskih sistemov je izredno hiter. Podjetja mu sledijo, za kar so potrebna velika vlaganja, sestavljena iz začetnega vložka in vsakoletnega vlaganja v širitve in vzdrževanje sistema. Podjetje mora imeti zgrajeno jasno vizijo, zakaj namerava investirati v informacijsko tehnologijo. Nekateri od teh ciljev so: • boljša kakovost, . zniževanje stroškov, • doslednejše spoštovanje rokov. Nekatera podjetja so že na tako visoki stopnji informatizacije, da je postal informacijski sistem življenjskega pomena. Načrtovanje informacijskih sistemov je vitalnega pomena za ohranjanje oz. ustvarjanje konkurenčnih prednosti podjetja. Pri tem mislimo tako na gradnjo novih sistemov ali podsistemov kot tudi na prenovo obstoječih sistemov. Vodstvo podjetja se je odločilo prenoviti in informatizirati proces nabave računalniške opreme. Čas nabave opreme od ideje do realizacije je bil nekaj mesecev, celo pol leta in več. Vodstvo je prišlo do zaključka, da je proces neučinkovit in da so stroški, povezani s tem, previsoki. Večina uporabnikov je bilo s takšnim stanjem nezadovoljna. Zahteva vodstva je bila zmanjšanje potrebnega časa za nabavo opreme vsaj za polovico. 2 Opis procesa Nabava je ena od najpomembnejših poslovnih funkcij v podjetju (VVeele, 1998). Uspešnost podjetja je neposredno odvisna tudi od uspešnosti nabave. V nekaterih podjetjih stroški porabljenega materiala predstavljajo več kot polovico vseh stroškov. V zadnjih letih se je vloga nabave v podjetjih spremenila. Ta sprememba je še posebej očitna v prenovljenih podjetjih. Najbolj se to kaže pri odnosih z dobavitelji. Kupec in dobavitelj postaneta strateška partnerja, ki si skupaj prizadevata doseči čim boljše poslovne rezultate. Nekatere od prednosti, ki so rezultat takega sodelovanja, so: krajši čas razvoja izdelka, dobava ravno ob pravem času in visoka kakovost materialov. Nabavo opreme smo opredelili kot delovni proces podjetja. Pojem opreme smo omejili na računalniško in informacijsko opremo, ki vključuje strojno in programsko opremo. Pri zasnovi informacijskega sistema nabave opreme smo izhajali iz obstoječega klasičnega sistema, za katerega je bilo značilno, da so bili vsi dokumenti v papirnati obliki in da so potovali od akterja do akterja po klasični pošti. Cilj zasnove sistema nabave opreme je bil izboljšanje funkcionalnosti, pretvorba dokumentov v elektronsko obliko in uvedba elektronskega prenosa. Sam proces nabave opreme je bil nekoliko zastarel in ni v celoti izpolnjeval pričakovanj. Med informatizacijo delovnega procesa smo izvedli še prenovo (Hammer, Champy, 1995). Najpomembnejši pokazatelj učinkovitosti sistema nabave opreme je čas, ki preteče od zahteve uporabnika do njegove realizacije. Za uporabnika je pomembno tudi, da lahko v času realizacije sledi, kako se njegova zahteva izvaja in na kakšni stopnji realizacije je v določenem trenutku. Vsem sodelujočim mora biti sistem razumljiv in enostaven za uporabo. Vsem mora biti na voljo sledljivost posameznih zahtev in izdelava poročil. Za vodstvene akterje je pomembno, ali so investicije v skladu s plani in kakšen je nivo izvedbe investicij. Nasprotno je za uporabnika pomembno, da je sistem čim bolj fleksibilen in da omogoča hitro izvedbo njegovih potreb. 3 Informacijske potrebe Za uspešno izvedbo projekta je pomembno, da se zavedamo vseh tveganj. Nevarnostim se lahko izognemo le, če jih dobro poznamo. Osnova so informacijske potrebe, ki smo jih združili v deset splošnih smernic za načrtovanje informacijskih sistemov (Damij, 2000): . celovitost: Informacijski sistem nabave opreme je zaključena celota, ki ni ločena od ostalega informacijskega sistema, temveč je vanj integrirana. Prenos podatkov med različnimi deli informacijskega sistema mora biti zagotovljen. Načelo, da je vsak podatek zapisan le enkrat v bazi podatkov, mora biti dosledno uveljavljeno. . uporabnik/sistem: Komunikacija med uporabnikom in sistemom naj bo čim bolj enostavna. Komunikacijski vmesniki morajo biti izdelani tako, da uporabnika vodijo in da preprečujejo nepravilne vnose. Prikazi morajo biti pregledni in morajo nuditi pričakovane informacije vsem vrstam uporabnikov. . tekmovalnost: Globalno gledano lahko večjo tekmovalnost podjetja zagotavljamo tudi s hitrejšim pretokom informacij in z zagotavljanjem večje kakovosti informacij. Informacijski sistem nabave opreme je le del skritih možnosti, ki jih lahko podjetje izkoristi v ta namen. . kakovost in uporabnost informacij: V informacijskem sistemu nabave opreme nastopa množica uporabnikov, ki imajo specifične potrebe. Vse potrebe je nujno identificirati. Pomembno je, da vsak uporabnik v informacijski sistem vnese informacije iz svojega delovnega področja in da ima dostop do tistih informacij, ki ga zanimajo in ki jih potrebuje pri svojem delu. Posebno skrb je potrebno posvetiti delu informacijskega sistema za podporo vodstvu. . sistemske zahteve: Sistem mora biti uporabnikom dostopen in zagotovljene morajo biti možnosti širitve v prihodnosti in prilagoditve novim zahtevam. . obdelava podatkov: Pri zasnovi informacijskega sistema je treba upoštevati količino podatkov, kompleksnost obdelave podatkov in časovne zahteve obdelav. . organizacijski dejavniki: Do informacijskega sistema morajo imeti dostop uporabniki iz različnih služb. Pri tesnejšem sodelovanju z dobavitelji imajo lahko tudi ti dostop do določenih delov baze podatkov. . stroškovne zahteve: Izgradnja informacijskega sistema mora omogočiti povečanje produktivnosti uporabnikov. Kljub temu je strošek izgradnje sistema pomemben dejavnik. Izgradnja naj, če je le mogoče, izkoristi obstoječe informacijske kapacitete. . človeški dejavnik: Informacijski sistem naj bo enostaven za uporabo. Predvideti je treba izobraževanje za vse uporabnike. . zahteve izvedljivosti: Pri načrtovanju sistema je nujno upoštevati tehnične in ekonomske možnosti podjetja. 4 Akterji, objekti, primeri uporabe in scenarij Akterji so entitete, ki so v interakciji s sistemom in imajo specifično vlogo. Delimo jih na notranje in zunanje. Naš sistem vsebuje enajst akterjev: uporabnik, vodja službe, direktor gospodarske družbe, informatik, vodja informatike, nabavnik, vodja nabave, kontrolor poslovanja, finančnik, pravnik in dobavitelj, ki je zunanji akter. Zahteva za izvedbo investicije (Zli), pogodba za investicijo (PZI), zahteva za nabavo (ZN), povpraševanje, ponudba, izbor, pogodba, naročilo, prevzem in račun so objekti. Eden od akterjev dokument kreira, pooblaščeni akterji ga potrdijo s podpisom. Če dokumenta ne potrdijo, pripišejo opombe in ga vrnejo akterju, ki ga je izdelal. Akter dokument popravi in postopek potrjevanja se ponovi. Poenoteni jezik modeliranja (UML) uvaja uporabo »primerov uporabe« za opis zahtev informacijskega sistema (Schneider, VVinters, 1997). Identificiramo osnovne primere uporabe kreiranja in potrjevanja. Za objekta ponudba in račun imamo še primera uporabe evidentiranje in plačevanje (tabela 1). Ostali primeri uporabe so še brisanje, spreminjanje in prikazovanje dokumentov. Kreira/briše/spremeni Objekt Potrdi/zavrne Uporabnik Zli Vodja službe in vodja informatike Informatik PZI Vodja informatike, vodja službe, direktor gospodarske družbe in kontrolor poslovanja Informatik ZN Vodja informatike, kontrolor poslovanja in vodja nabave Nabavnik Povpraševanje Dobavitelj dostavi ponudbo Nabavnik evidentira ponudbo Ponudba Informatik Nabavnik Izbor Vodja informatike, direktor gospodarske družbe, vodja nabave in pravnik Nabavnik Pogodba Vodja nabave in pravnik Nabavnik Naročilo Vodja nabave Informatik Prevzem Vodja informatike Nabavnik evidentira račun Račun Finančnik izvede plačilo Tabela 1: Primeri uporabe Na prvi pogled je ta sistem izvedbe investicij zelo kompleksen in dolgotrajen. Obstaja občutek, da so nekateri koraki nepotrebni ali da se podvajajo. Pozitivnost tega sistema je v večkratnem preverjanju, kar preprečuje zgrešene investicije. Pri večjih investicijah, kjer so tudi zneski višji, ta dolgotrajnost ni tako moteča. Pri manjših investicijah je postopek nekoliko predolg in zato neprimeren. Ta postopek uporabljamo za investicije nad 1.000.000 SIT. Za vsak primer uporabe določimo tok dogodkov. V začetku upoštevamo najbolj naraven tok, tako dobimo primarni scenarij (Sturm, 1999). Primarni brisanje kreiranje Zli ^ «uses>> 'spreminjanji uporabnik potrjevanje vodja informatike <> kreiranje «uses» vodja službe informatik kontrolor poslovanja vodja tovarne Slika 1 Diagram primerov uporabe scenarij temelji na predpostavki, da vse deluje brez napak, in vsebuje osnovne primere uporabe. Sekundarni scenarij dobimo tako, da upoštevamo tudi alternativne poti, pogoje in napake. Na splošno ima lahko vsak problem več scenarijev. V našem primeru smo določili le primarni in sekundarni scenarij. V sekundarnem scenariju upoštevamo primere uporabe brisanja in spreminjanja vseh dokumentov. Poleg tega navedemo še primer uporabe prikazovanje dokumentov. Ta primer uporabe je namenjen izpisu informacij. Akterji lahko dobijo informacije o posameznem dokumentu tako, da izpišejo dokument oz. objekt z njegovimi atributi. Lahko pa dobijo informacije o več dokumentih. V tem primeru izberejo dokumente po kakem kriteriju, npr. po datumu ali avtorju, ki je kreiral dokument. V diagramu primerov uporabe prikažemo vse akterje in osnovne primere uporabe. Diagram primerov uporabe je narejen na podlagi opravljenih pogovorov z vsemi akterji. Primeri uporabe si sledijo eden za drugim. Ko je predhodni primer uporabe končan, se lahko začne naslednji. Primeri uporabe so povezani z akterji. Akter lahko v določenem primeru kreira, evidentira ali potrjuje dokument. Pri potrjevanju lahko pride do potrditve ali do zavrnitve. Primarni scenarij predpostavlja, da vedno pride do potrditve dokumenta. Akter, ki potrjuje dokument, lahko le-tega tudi zavrne. V tem primeru mora akter, ki je kreiral dokument, le-tega spremeniti, popraviti. Potrjevanje se začne od začetka. To situacijo prikazuje sekundarni scenarij (slika 1). V diagramu primerov uporabe prikažemo tudi možnost brisanja in spreminjanja + operacijeO - atributi + operacijeO - atributi izbor + operacijeO ponudba - atributi prevzemnica + operacijeO - atributi + operacijeO - atributi račun + operacijeO - atributi + operacijeO naročilo - atributi + operacijeO pogodba - atributi + operacijeO - atributi tehponudba + operacijeO - atributi komponudba + operacijeO - atributi povpraševanje + operacijeO - atributi Slika 2: Diagram razredov dokumenta. Na sliki prikažemo le primere uporabe za dokumenta Zli in PZI. Ta princip velja za vse ostale primere uporabe. Diagram razredov (slika 2) prikazuje deset razredov in dva podrazreda. Razred ponudba je generični razred, ki ima dva podrazreda. To je posledica ločevanja objekta ponudba na tehnični in na komercialni del. Za vsak razred navedemo štiri atribute, to so identifikacijska številka, naslov dokumenta, ime avtorja in datum kreiranja dokumenta. Razredi ali obstaja spreminjanje Zli Zli kreiran brisanje Zli v skladu s plani ali brišemo Zli potrjevanje Zli Zli potrjen Z Slika 3: Diagram aktivnosti vsebujejo operacije, ki jih lahko izvajamo nad njimi. Večina razredov ima operacije kreiraj, potrdi, spremeni in briši. Razred račun vsebuje še operacijo plačaj. Razreda ponudba in račun vsebujeta namesto operacije kreiraj operacijo evidentiraj. Operacija evidentiraj dejansko vsebuje evidentiranje dokumenta prispelega od dobavitelja in tudi kreiranje tega dokumenta v informacijskem sistemu. Tako majhno število atributov in operacij smo navedli zaradi preglednosti. V realnih pogojih izvedbe bi lahko navedli še mnogo dodatnih atributov in operacij. Prikažemo še diagram aktivnosti (slika 3). Diagram prikazuje aktivnosti in stanja. Po aktivnosti kreiranje Zli preidemo v stanje Zli kreiran, po aktivnosti potrjevanje Zli preidemo v stanje Zli potrjen itn. Pred vsako aktivnostjo kreiranje se moramo vprašati, ali ta dokument že obstaja. Če še ne obstaja, ga kreiramo in preidemo v stanje kreiran. Če pa ta dokument že obstaja, preidemo direktno v stanje kreiran. Pred vsako aktivnostjo potrjevanje se vprašamo, ali je dokument v skladu s plani. Če je ustrezen, ga potrdimo in preidemo v stanje potrjen, v nasprotnem primeru ga zavrnemo. Dokument popravi akter, ki ga je kreiral. Po aktivnosti spreminjanje zopet preidemo v stanje kreiran, po aktivnosti brisanje se vrnemo na začetek. V diagramu aktivnosti prikažemo le aktivnosti kreiranje, potrjevanje, spreminjanje in brisanje za dokument Zli. Za vse druge dokumente je postopek enak. 5 Sklep S prenovo in informatizacijo procesa nabave opreme smo dosegli natančno definiranost in poenostavitev procesa. Stroški procesa so nižji, povečala se je učinkovitost nabavne službe. Na splošno lahko rečemo, da so vsi udeleženci v procesu bistveno bolj zadovoljni, kot so bili v preteklosti. V poprečju se je čas nabave opreme prepolovil, v nekaterih primerih pa je še bistveno krajši. Vsi akterji v procesu imajo jasno in natančno določene naloge, zato ne prihaja več do nesporazumov zaradi nedorečenih pristojnosti in odgovornosti. Informacijski sistem spodbuja vse k še tesnejšemu sodelovanju. Način kreiranja dokumentov, način spreminjanja dokumentov in tok dokumentov so natančno opredeljeni. Nekateri akterji lahko dokumente kreirajo, drugi imajo samo možnost vpogleda v določene podatke. Uporabniški vmesniki so izdelani tako, da so uporabniku v pomoč in da ga vodijo pri delu. Poleg tega so vgrajeni mehanizmi, ki preprečujejo nepravilne vnose ali izgubo podatkov zaradi napačne uporabe. Informacije vnesemo v informacijski sistem tam, kjer nastanejo oz. kjer se zgodi dogodek. S prehodom na elektronsko obliko dokumentov smo v veliki meri zmanjšali ali odpravili nepotrebno delo. Prenos dokumentov je bistveno hitrejši. Izgub dokumentov ni več, kar se je ob uporabi klasične pošte pogosto dogajalo. Elektronska oblika dokumentov ravno tako omogoča hiter nadzor in izdelavo poročil o procesu nabave opreme. Za podporo odločanju je pomembno, v kolikšnem času so naročila izvedena, ali dobavitelji spoštujejo dobavne roke, kakšna je kakovost dobavljene opreme, kako je s plačili itn. Informacijski sistem nabave opreme za svoje delovanje uporablja tudi informacije drugih informacijskih podsistemov oz. sistemov. Pretok podatkov med različnimi informacijskimi sistemi je zagotovljen. Informacijski sistem vsebuje vse potrebne varnostne mehanizme za vrnitev podatkov v primeru izgube. V ta namen smo izkoristili centralni sistem shranjevanja in vračanja podatkov. Na relativno enostavnem primeru smo prikazali, kako je mogoče informatizirati in prenoviti delovni proces. Z vidika stroškov, rokov in kakovosti je prenova izpolnila pričakovanja. Posredno smo prispevali k dvigu kakovosti proizvodnje v tovarni. Razmere na trgu bodo čedalje pogosteje spodbujale podjetja, da se odločijo za prenovo in informatizacijo svojih delovnih in poslovnih procesov. 6 Iliri in literatura [1] Damij Talib: Poslovna informatika. Ljubljana: Ekonomska fakulteta, 2000. [2] Hammer Michael, Champy James: Preurejanje podjetja. Manifest revolucije v poslovanju. Ljubljana: Gospodarski vestnik, 1995. [3] Schneider Geri, VVinters R Jason: Applying Use Cases. A Practical Guide. Boston: Addison-Wesley, 1997. [4] Sturm Jake: VB6 UML. Design and Development. Birmingham: Wrox Press, 1999. [5] VVeele A. J. van: Nabavni management. Analiza, planiranje in praksa. Ljubljana: Gospodarski vestnik, 1998. Mag. Franc Brcar je leta 1999 diplomiral na Fakulteti za strojništvo v Mariboru. Magistrski študij je zaključil na Ekonomski fakulteti v Ljubljani iz informacijsko upravljalskih ved. Od leta 1986 se ukvarja z izgradnjo različnih informacijskih sistemov. Dr. Andrej Kovačič je v zadnjih desetih letih delal kot projektant, razvijalec in svetovalec na projektih strateške prenove in informatizacije poslovanja. Je izredni profesor s področja poslovne informatike na Ekonomski fakulteti in Visoki upravni šoli ter predstojnik Inštituta za poslovno informatiko pri EF v Ljubljani. Je član izvršnega odbora Slovenskega društva Informatika, odgovorni urednik revije Uporabna informatika, svetovalec in veščak s področja vodenja in upravljanja podjetij [PHARE, Zveza ekonomistov) in pooblaščeni revizor informacijskih sistemov. REŠITVE 0 Uporaba standarda LandMML in razširitev PmcKML Matej Gomboši, Borut Žalik Fakulteta za elektrotehniko, računalništvo in informatiko, Univerza v Mariboru, Smetanova 17, 2000 Maribor Danijel Rebolj Fakulteta za gradbeništvo, Univerza v Mariboru, Smetanova 17, 2000 Maribor matej.gombosi@uni-mb.si, zalik@uni-mb.si, rebolj@uni-mb.si Izvleček Standard LandXML predstavlja razširljiv jezik XML za potrebe informatizacije na področjih gradbenega inženirstva in izmenjave podatkov predvsem v procesih gradbene in transportne industrije. Omogoča prenos podatkov med ponudniki in uporabniki ter ponuja podatkovni format za dolgoročno shranjevanje ter standardni format za elektronsko posredovano načrtovanje. LandXML omogoča opis prostorskih elementov, kot so cesta, parcela, model terena, ter njihove spremljajoče infrastrukture. Za naše potrebe smo shemo standarda LandXML razširili z dodatnimi elementi in tako dobili razširjeno shemo PmcXML. Abstract The Usage of Standard LandHML and the Entention PmcKML Standard LandXML represents an extensible XML language. It was designed for informatization of civil engineering and survey data used in construction and transportation industries. It enables transfer of engineering data betvveen suppliers and users and provides a format suitable for long term archiving and a standard format for electronic exchange of design data. LandXML enables description of spatial elements as roads.parcels, digital terrain models including accompanying infrastructure. We extended LandXML specifi-cation with additional elements to obtain a new specification named PmcXML. 1 Uvod LandHML je zasnoval Autodesk decembra 1999 kot industrijsko podprti odprti standard KML za izmenjavo prostorskih podatkov (Kvamme 1997). S tem se je približal potrebam gradbenikov, geodetov, razvijalcev programske in strojne opreme in ponudnikov storitev s področja geografskih informacijskih sistemov (GIS). Prva shema standarda LandHML je bila izpeljana iz predhodnega standarda EAS-E (Engineering and Surveying - Evchange) za izmenjavo podatkov v formatu ASCII. Strukture podatkov v standardu LandNML omogočajo: ■ prenos prostorskih podatkov in meritev med izvajalci in uporabniki, • podatkovni format za dolgotrajno shranjevanje podatkov, • standardni format za uradno elektronsko poslovanje. Podatki LandXML se lahko uporabljajo tudi kot (LandXML 2002): • osnova za ocenitev stroškov in zagona projektov, ■ osnova za izračune in poročila po meri uporabnika, • izmenjava podatkov iz merilnih naprav, • format za iskanje in dodajanje informacij v baze GIS, ■ standard za prenos inženirskih podatkov med različnimi aplikacijami. V letu 2002 je precej računalniških programov (Microsoft Office, AutoCAD) ter baz podatkov (Microsoft SQL 2000, IBM DMBS in Oracle) privzelo standard LandXML in s tem tudi vse podprte značilnosti. LandXML je specializiran XML format (LandXML 2002) za prostorske podatke, ki se na ta način lahko uporabljajo na različne načine v poslovnih in tehničnih aplikacijah in bazah podatkov, ki podpirajo XML. V prispevku bomo opisali uporabo standarda LandXML in njeno razširitev za opis modela ceste. 2 Osnovna shema LandHML LandXML v svoji najnovejši verziji temelji na shemi standarda XML konzorcija W3C (VVorld Wide Web Consortium). Podatki XML so organizirani z uporabo sheme XML (Marchal 2000), ki je standard W3C za opis podatkovnih struktur in tipov podatkov v formatu XML (Birbeck 2001, St. Laurent 1998). LandXML opisuje prostorske podatkovne strukture kot so merski sistem, podatki o točkah, geometrija cest, geometrija parcel, podatki meritev na terenu in podobno. Spodnji primer prikazuje preprost dokument LandXML, ki opisuje parcelo.
3144.170572 2097.339412
3221.037433 2253.014210 3297.983320 2132.660352 2987.138471 1988.824807
2707.150400 1986.240192
2979.887278 2049.601027
V tem primeru lahko enostavno najdemo podatke o projektu, uporabljene merske enote, informacije o programu, ki je ustvaril podatke, in podatke o parceli. Vendar pa LandXML ne opisuje samo točk. Tabela 1 prikazuje podatkovni model sheme LandXML na najvišjem nivoju: V tabeli 1 in v prikazanem primeru vidimo, da LandXML ne določa, kako naj točke, črte, parcele ali drugi elementi izgledajo na prikazovalniku. Podatke prikažemo s pomočjo aplikacije, ki jo uporabljamo. LandXML vključuje vse prednosti standarda XML: « standard podpira W3C, . postaja standardni metajezik za prenos podatkov v računalniški industriji, • je objektno orientiran in s tem podpira aktualne programske koncepte, . je čitljiv in . je razširljiv. Z uporabo XML za opis LandXML dobimo samostojne podatke, ki ne potrebujejo dodatnega opisa. To pomeni, da so sami podatki uporabni tudi zunaj konteksta aplikacije, ki jih je kreirala. To omogoča Projekt Ime in opis projekta CoordinateSystem Kartezijski ali georeferenčni koordinatni sistem Units Dolžinske, kotne in ploščinske enote CgPoints Zbirka točk geometrije Survey Zbirka podatkov in parametrov iz meritev Parcels Parcele Alignments Zbirka podatkov za cestne osi PipeNetworks Zbirka podatkov o omrežjih CoordGeom Urejen seznam geometrije (črte, krivulje, spirale) CrossSect Prečni prerezi PlanFeatures Druge značilnosti načrta (ograje, drevesa, svetilke) Surfaces Elementi za opis modela površja Tabela 1 Shema LandKML na najvišjem nivnju dobra strukturiranost in preglednost XML jezika. Tako se podatki v drugih aplikacijah lahko uporabijo in prikažejo na različne načine. 3 PmcKML Pri računalniškem opisovanju cest bi radi pogosto opisali ne samo osnovne podatke o cesti, ampak tudi podatke o spremljajočih objektih, kot so zidovi, mul-de, nosilci ipd. Za opis cest in pripadajočih objektov smo v sodelovanju s Centrom za gradbeno informatiko na Fakulteti za gradbeništvo Univerze v Mariboru razširili shemo standarda LandXML in jo poimenovali PmcXML. 3.1 Predstavitev modela Shema PmcXML predstavlja nadgradnjo sheme LandXML. V obstoječi shemi LandXML namreč ni strukture, ki bi celostno opisovala 3D elemente ceste. Pri tem mislimo na objekte, ki se vzdolž ceste pojavljajo v večih prečnih presekih in so v LandXML predstavljeni kot množica nepovezanih elementov prečnih presekov. Slika 1 kaže primer ceste in dveh sten (wall), ki sta postavljeni vzdolž osi ceste (axis). Vidimo, da se obe steni pojavljata v več prečnih prerezih. Objekt predstavimo kot množico povezanih elementov prečnih presekov. Slika 2 kaže primer prečnega prereza na poziciji n iz slike 1. Za opis novih struktur v shemi PmcXML smo morali uvesti nekaj novih pojmov v shemo LandXML: . Novi element Object3D. Ta predstavlja posamezni 3D element ceste. Slika 1 Tloris cestnega odseka crossection n zid 2,n os l,n jarek L,n Slika 2 Prečni prerez cestnega odseka . Novi element Object3DType. Ker so elementi tipizirani, jih lahko s pomočjo vnaprej definiranih tipov laže klasificiramo. S tem tudi enostavno opišemo podatke o posameznem tipu objekta. . Integracija novih elementov v shemo LandXML. Nove elemente je bilo treba skladno s pravili LandXML uvrstiti na ustrezna mesta v obstoječo strukturo, da bi omogočili čim boljšo in enostavnejšo integracijo. Poglejmo sedaj naštete spremembe v zgradbi sheme LandXML. Na sliki 3 sta prikazani obe shemi (levo LandXML, desno PmcXML). Obe shemi sta okrnjeni samo na osnovne elemente, koristne za ponazoritev razlik. Spremembe smo izvedli tako, da je nadgradnja LandXML v OmcXML čim bolj smiselna. Na sliki smo prikazali samo podatke o osi ceste (Alignment) in podrejenih podatkih, ker le v tej strukturi pride do sprememb. Kot je razvidno iz slike, smo na najvišjem nivoju dodali element Object3DTypes, ki predstavlja seznam za elemente Object3DType. Ta element se lahko uporablja v vseh strukturah Pmc-XML, zato je zaradi dostopa uvrščen na vrh sheme. To pomeni, da se lahko elementi določenega tipa pojavljajo v različnih oseh ceste. <0bject3DTypes> <0bject3DType name="tip 1" points="107> <0bject3DType name=”tip 2‘ points="67> <0bject3DType name="tip 3" points="57> Vsak Object3DType ima svoj identifikator, prek katerega se Object3D sklicuje nanj. Ta identifikatorje shranjen v obliki parametra v enem in drugem elementu in nam predstavlja glavni ključ za povezovanje elementov Object3D in Object3DType. Drugi novi element je Object3D, ki se tudi nahaja znotraj seznama Objects3D. Vsak objekt je vezan na določeno cesto oz. njeno os in je zato dodan v shemo pod os ceste. Vsaka cesta tako ima lahko svoje objekte (3D elemente), pri tem pa en objekt ne more pripadati več cestam. Ta element ni eksplicitno zapisan v datoteki, ampak je shranjen s pomočjo identifikatorjev znotraj ploskev v prečnih prerezih. <0bjects3D> <0bject3D name="0bjekt3D 1" type="tip 1" material="concrete" connected=”yes7> <0bject3D name=”0bjekt3D 2" type=”tip 3" material="aluminium" connected="no7> Tako kot cesta sama ima tudi vsak 3D objekt prečne prereze. Za vsako ploskev v prečnem prerezu se prek identifikatorja poda objekt, kateremu le-ta pripada. Na ta način natančno vemo, v katerih prečnih prerezih se pojavlja določen objekt in ga zato tudi ni težko prebrati iz datoteke. Kot lahko vidimo, se dejanski podatki o objektih shranijo v enem naj nižjih nivojev sheme PmcXML. 3.2 Implementacija Za zapis podatkov v PmcXML smo napisali funkcije, ki sprejmejo ustrezne podatke o cestnem modelu in jih sproti zapisujejo v strukturo PmcXML. Ko so vsi podatki vnešeni, se zapišejo v datoteko XML. Celotna implementacija je bila izvedena v okolju Windows s programskim orodjem Visual C++ NET. Program je shranjen v knjižnici DLL, ki jo je mogoče uporabljati tudi v drugih programskih okoljih (Delphi, Visual Basic, C++ Builder). Land XML 5.., -'B-ii i— Alignments 5 0.. Alignment Y i.. EET CrossSects E E CrossSect E E T -CrossSectSurf Prnc XML 1 ! y X X s U ,Object3DType : i=r}\ T 0.. Alignments r / < X s 0.. Alignment E TET v ! ^ CrossSects i_z^____ E E i/* Objects3D E CrossSect Z z T bT r.....i----- ! w ObjectSD T .CrossSectSurf Slika 3: Primerjava LandKML (levo) in PmcKML (desno) sheme Opise bomo podali v obliki, kot se pojavljajo v programu, torej v C++ deklaracijah. Uporabljene so naslednje funkcije: . Add0bject3DType (char8 a0bject3DTypeName, int aNumOfPoints) vhod: a0bject3DtypeName - ime oz. id tipa, aNumOfPoints - število točk, ki opisujejo tip. Funkcija ustvari in doda nov tip objekta. ■ AddObjectSD (char* aAlignmentName, char8 a0bject3DName, char* a0bject3DType, char8 aMaterialType, bool aAlignmentConnection) vhod: aAlignmentName - ime osi ceste, kamor se doda objekt, aObjectSDname - ime oz. id objekta, a0bject3DType - ime oz. id tipa objekta, aMaterialType - material objekta, aAlignmentConnection - ali je objekt vezan na os. Funkcija ustvari nov objekt in ga doda v ustrezno os ceste. . ReadObject3Dlnfo (char* aAlignmentName, char” a0bject3DName, char” OType, char* OMaterial, char* OConnect, intS. OCrossSectionsCount, intS OTypePointsCount) vhod: aAlignmentName - ime osi ceste, kamor se doda ploskev, aObjectSDname - ime objekta, izhod: OType - tip objekta, OMaterial - material objekta, OConnect - ali je objekt vezan na os ceste, OCrossSectionsCount - število prečnih prerezov, v katerih se nahaja objekt, OTypePointsCount - število točk, ki opisujejo ta tip objekta v prečnem prerezu. Funkcija prebere informacije o objektu. » ReadObjectSDData (char® aAlignmentName, char* aObjectSDName, int aCrossSectionsCount, int aTypePointsCount, char** OSurfaceNames, double* OPoints) vhod: aAlignmentName - ime osi ceste, kamor se doda ploskev, aObjectSDname - ime objekta, aCrossSectionsCount - število prečnih prerezov, v katerih se nahaja objekt, aTypePointsCount - število točk, ki opisujejo ta tip objekta v prečnem prerezu, izhod: OSurfaceNames - seznam imen ploskev, ki tvorijo objekt, OPoints - seznam točk objekta. Funkcija prebere dejanske podatke o objektu. Imena ploskev so urejena glede na stacionažo prečnih prerezov. Prav tako so urejene tudi točke. . ReadObjects3DCount (char* aAlignmentName) Funkcija vrne število objektov v določeni osi ceste. . ReadObjectSDNames (char® aAlignmentName, int alength, char** 00bjects3DNames) vhod: aAlignmentName - ime osi ceste, kjer iščemo objekte, alength - število objektov, izhod: 00bjects3DNames - seznam imen objektov. Funkcija prebere imena objektov v določeni osi ceste. . ReadObject3DTypesCountO Funkcija vrne število definiranih tipov objektov. . Read0bject3DTypesData (char **OTypeNames, int” OPointsCount) izhod: OtypeNames - polje nizov imen, OPointsCount - polje števil točk. Funkcija prebere imena in število točk, ki definirajo posamezni tip objekta. 4 Zaključek V prispevku smo predstavili standard LandXML, ki predstavlja razširljiv jezik XML za potrebe gradbenega inženirstva in izmenjave podatkov. Videli smo, kako je mogoče opis elementov, potrebnih v gradbeni informatiki, spremeniti in dodati nove elemente, ki nam omogočajo popolnejši opis, s tem pa tudi višjo stopnjo interpretacije podatkov (primer prikazuje slika 4). Slika 4: Avtomatsko generirani 3D model cestnega telesa 5 Literatura [1] Birbeck, M. et al. (2001). Professional XML 2nd edition, Wrox Press, UK. [2] Kvamme, K. (1997). Geografski informacijski sistemi, Znanstveno raziskovalni center SAZU, Ljubljana. [3] LandXML shema 1.0 (2002). http://www.landxml.org. [4] Marchal, B. (2000). XML by example, Que Programming, US. [5] St. Laurent, S. (1998). XML a primer, MIS Press, US. Mag. Matej Gomboši je asistent na Fakulteti za elektrotehniko, računalništvo in informatiko Univerze v Mariboru. Diplomiral je leta 1999 in magistriral leta 2002. Kot asistent se od leta 1999 ukvarja z algoritmi računalniške geometrije in uporabo teh v sistemih GIS. Dr. Borut Žalik je vodja laboratorija za geometrijsko modeliranje in algoritme multimedijev na Fakulteti za elektrotehniko, računalništvo in informatiko Univerze v Mariboru. Doktoriral je leta 1993 na takratni Tehniški fakulteti v Mariboru. Na raziskovalnem področju se ukvarja z geometrijskim modeliranjem, računalniško geometrijo, sistemi GIS in tehnikami stiskanja podatkov. Dr. Danijel Rebolj je diplomiral na področju gradbeništva in magistriral na področju računalništva in informatike. Doktorat tehniških znanosti je dosegel na Tehniški univerzi v Gradcu s področja gradbene informatike, s katero se ukvarja na znanstvenem in izobraževalnem področju. Od leta 1995 je na Fakulteti za gradbeništvo predstojnik Centra za gradbeno informatiko, od leta 1999 pa tudi prodekan za izobraževalno dejavnost. Občni zbor Slovenskega društva INFORMATIKA Občni zbor Slovenskega društva INFORMATIKA se je sestal 4. decembra 2002 z enoletno zamudo, katere glavni razlog je bilo zamujanje pri pripravi sprememb statuta društva, ki ga je bilo treba uskladiti s spremenjeno zakonodajo. Statut smo želeli posodobiti tako, da bo primeren za prihodnje delovanje društva, pri čemer smo se vsaj delno zgledovali po statutih mednarodnih društev, v katera se je društvo včlanilo leta 1938: International Federation for Information Processing (IFIP) in Council of European Professional Informatics Societies (CEPIŠ). Eno leto zakasnitve pri sklicu občnega zbora nam ni v čast, vsaj delno opravičilo pa je, da je bil vmesni občni zbor leta 1999 med Dnevi slovenske informatike v Portorožu, ki sicer ni bil volilni, se je pa vendar sestal zaradi aktualnih odločitev o nastajanju slovenske strategije prehoda v informacijsko družbo - modre knjige. Na istem občnem zboru je bil sprejet tudi kodeks poklicne etike društva. Čas do sklepčnosti občnega zbora (po določilih statuta 1 ura) je tokrat zapolnila Katarina Puc, predsednica sekcije za jezik, ki je predstavila internetni slovar strokovnih izrazov informatike, ki je javnosti na ogled na domačih straneh društva. Glede na to, da je bila sekcija ustanovljena šele 2000, je izdelek vreden spoštovanja. Odprt je vsej javnosti, mogoče je pregledovati izraze, vpisovati predloge za nove ter posredovati mnenja in komentarje. Uredniške pravice omogočajo urejanje zbranega gradiva, v načrtu je poskusni snopič, kasneje pa še slovar v knjižni obliki. Doslej je slovar nastajal brez zunanjega financiranja, izostala so celo že obljubljena državna sredstva. Ustaljeni del občnega zbora so poročila predsednika, izvršnega odbora, nadzornega odbora, sekcij in uredništev društvenih publikacij. Iz poročil predsednika in izvršnega odbora povzemamo, da je bilo delovanje društva vidno tako v državi kakor tudi mednarodno. Reviji Informatica in Uporabna informatika smo redno izdajali, sekciji za jezik in operacijske raziskave sta dejavni, sekcija za informacijske sisteme (ustanovljena leta 1998) žal nekoliko manj, redno objavljamo novice na domačih straneh (www.drustvo-informatika.si), Dnevi slovenske informatike so postali največji neodvisni slovenski strokovni dogodek leta. V mednarodnem okolju smo postali opazni in zanimivi. V Ljubljani je bil leta 2001 sestanek izvršnega odbora CEPIŠ, na Bledu leta 2002 sestanek izvršnega odbora IFIP; slednjega je obiskal tudi minister za informacijsko družbo dr. P. Gantar. L. 2000 je društvo postalo član European Driving Licence Foundation in ustanovilo 14 testnih centrov v Sloveniji in enega v Zagrebu. Vse to in usmeritev v odprtost in sodelovanje je verjetno vplivalo na zanimanje za članstvo v društvu, ki je štelo na dan občnega zbora 392 članov, kar je za Slovenijo že spoštovanja vredna številka, čeprav še daleč od tiste, ki bi jo mogli pričakovati glede na število informatikov in pomen informatike. Vsa prizadevanja pa pričakovanih sadov niso obrodila. Sklep občnega zbora, da društvo v sodelovanju z Združenjem raziskovalcev Slovenije ustanovi slovenski forum za informacijsko družbo, smo uresničili, vendar forum ni zaživel. Mogoče smo precenili potrebo Slovenije po takem forumu, mogoče se forum ni znal ponuditi kot posrednik med oblastjo in gospodarstvom in kot telo, ki bi zastopalo interese gospodarstva na dovolj poljuden (in priljuden) način, mogoče so bili za to še drugi vzroki, ki se nam bodo razkrili kasneje. Zavedamo se, da so potrebni za dosego ciljev različni poizkusi in da ni jamstva za uspeh kateregakoli izmed njih, vsak poizkus pa je izkušnja več. Forum je vendarle ustanovljen, od vseh nas pa je odvisno, ali bo uresničil pričakovanja. Ugotovitev nadzornega odbora je bila, da je društvo poslovalo uspešno in zakonito. Finančno stanje društva je bilo vseskozi pozitivno in predlog za razrešitev vseh organov društva je bil sprejet. Pomembna točka dnevnega reda je bil predlog statuta. Glavne novosti so predvsem vtem, da so podrobneje določene nekatere podrobnosti in zadeve, ki smo jih izvajali v praksi. Sicer niso bile v nasprotju s statutom, vendar je bolje, da so opredeljene v njem. Tako je zdaj predpisana tipografija črk na žigu; določeno je angleško ime Slovenian Society INFORMATIKA: področje delovanja društva je razširjeno z operacijskimi raziskavam; sekcija za informacijske raziskave je posebej navedena in določen je tudi njen angleški naziv Section for Operation Research: častni člani so lahko poleg fizičnih tudi pravne osebe; svet društva sestavljajo predstavniki častnih članov - pravnih oseb; domače strani na internetu so določene kot tretja publikacija društva; višino članarine določa izvršni odbor (prej jo je občni zbor, kar je bila zelo nepraktična ureditev); število članov izvršnega odbora je zmanjšano od 19 na 11 in določena so področja njihovega delovanja; opredeljen je konflikt interesov v primeru, da je kakšen član izvršnega odbora v vlogi, ki bi vplivala na njegovo glasovanje; sekretar društva je imenovan in ne več voljen. Statut je bil sprejet in pričakujemo, da bo tako prenovljen omogočal še uspešnejše delovanje društva. Na občnem zboru je bil sprejet tudi pravilnik o priznanjih. Priznanja je društvo javno podeljevalo že več let na Dnevih slovenske informatike in leta 1999 so bili sprejeti v častno članstvo vsi ustanovni člani društva. Vse to kaže na trajno usmeritev društva v strokovno odličnost, ki pa ne more biti dlje časa prepuščena uvidevnosti in prostemu preudarku. S pravilnikom je društvo določilo vrste priznanj, postopek za zbiranje in obravnavo predlogov in seveda tudi njihovo obliko in vsebino. Naj se ob tem pohvalimo, da je v pravilniku predvideno tudi priznanje za študentski dosežek, s katerim želimo vzpodbujati strokovno odličnost prav v času, ko je tako priznanje močan motiv za nadaljnje strokovno delovanje. Letošnji občni zbor je po razrešitvi dosedanjih organov društva izvolil novega predsednika, izvršni odbor, nadzorni odbor, disciplinsko komisijo in komisijo za priznanja. Izvršni odbor sestavljajo predsednik Niko Schlamberger, podpredsednika Franci Pivec in Lidija Zadnik Štirn ter člani Andrej Kovačič, Marjan Krisper, Vladislav Rajkovič, Ivan Rozman, Katjuša Skukan, Pavel Tepina, Ivan Vezočnik in Tatjana VVelzer. V nadzorni odbor so bili izvoljeni Tomaž Banovec, Ljubica Djordjevič in Vid Mikulič, v disciplinsko komisijo Milan Svetlin, Franc Žerdin in Tatjana Šeremet, v komisijo za priznanja pa Janez Grad, Katarina Puc in Milan Katič. N. S. Dnevi slovenske informatike 2003 Slovenska informatika za tretje tisočletje: v družbi najrazvitejših Portorož, 16.-18. april 2003 Dnevi slovenske informatike 2003 so deseto jubilejno posvetovanje slovenskih informatikov, ki si je priborilo ugled najpomembnejšega slovenskega strokovnega srečanja na področju informatike. Pravimo priborilo, kajti tak sloves ne more biti podeljen vnaprej. Zanj si je prizadevalo Slovensko društvo INFORMATIKA v sodelovanju z vsemi organizacijami, ki so želele prispevati k ugledu in razvoju informatike kot znanosti ter stroke in oh tem odpirati tudi osebne in poslovne stike. Postalo je viden dogodek, ki se ga kot vabljeni predavatelji radi udeležijo tudi tuji strokovnjaki in tisti slovenskega rodu, ki delujejo v tujini. Seveda gredo zasluge za dosežek predvsem domačim informatikom, ki se potrudijo preliti svoja spoznanja in dosežke v referate in jih predstaviti kolegom na posvetovanju, z objavo v zborniku pa tudi najširši javnosti. Rdeča nit DSI 2003 je Slovenska informatika za tretje tisočletje: v družbi najrazvitejših, kar se bo odrazilo tudi v prispevkih. Program letošnjega posvetovanja obsega več kot 100 prispevkov, katerih avtorji so strokovnjaki iz slovenskih podjetij in ustanov. Na posvetovanju bodo nastopili vabljeni predavatelji iz Slovenije in tujine. Organizirani bosta dve okrogli mizi, na katerih bodo sodelovali številni ugledni strokovnjaki, udeleženci pa bodo z njimi in med seboj lahko izmenjali svoja mnenja o aktualnih vprašanjih. V program posvetovanja smo uvrstili tudi delavnico in študentski forum, ki je namenjen mladim informatikom. Med odmori si bodo udeleženci lahko ogledali razstavo, na kateri se bodo predstavljala nekatera podjetja. Organizirani bodo že tradicionalni družabni dogodki, ki so bili vedno odlično sprejeti. Prepričani smo, da so Dnevi slovenske informatike dogodek, ki je zanimiv za Vas, zato Vas vabimo, da se ga udeležite. Organizatorji Slovensko društvo INFORMATIKA Gospodarska zbornica Slovenije - Združenje za informatiko in telekomunikacije Infos, d. o. o. Sekcije . A: Poslovna informatika in elektronsko poslovanje, v kateri bo govora predvsem o medorganizacijskem povezovanju in integraciji poslovnih procesov, o tem, kako lahko informacijska tehnologija prispeva k uspešnosti poslovanja in o sprejemanju strateških odločitev na področju informatike. . B: Informacijske tehnologije in internet, ki pokriva informacijsko arhitekturo, nove pristope in koncepte, sodobne razvojne tehnologije ter zgradbo, izgradnjo in praktične primere portalov. . C: Informacijska kultura in družba, ki je posvečena vprašanjem širšega družbenega konteksta, v katerega se umešča informatika. Prispevki se povezujejo v vsebinske kroge, ki zajemajo vpliv informatike na socialni razvoj, informacijsko podporo demokraciji in upravljanju, izobraževanje in kulturo na področju informatike ter skrb za slovenski jezik. Uabljena predavanja . dr. Marjan Krisper, Fakulteta za računalništvo in informatiko: Agilnost - nov pristop k razvoju informacijskih sistemov • mag. Charles Abrams, Gartner: Web Services: Technology Implementation and Business Drivers Through 2007 • dr. Tak Kamae, Laboratories of Image Information Science and Technology, Japonska: ITDiffusion into the Home m dr. Zsusza Toeszegi, John von Neumann Digital Library, Madžarska: Digitization ofthe Hungarian Cultural Heritage . dr. Vito Smolej, Carl Zeiss Vision, Nemčija: Ouantitative Image Analysis • dr. Gustav J. Olling, DaimlerChrysler Corporation, ZDA: Technical Computing in Digital Product Creation . Djordje Dukič, Dubravka Djurič, Nataša Lalovič, Vugoslav Informatic Alliance: Yugoslav IT Association JISA Okrogli mizi e Slovenska informatika pred vstopom v Evropsko unijo (vodi minister za informacijsko družbo dr. Pavel Gantar) e Vpliv informatike na uspešnost poslovanja (vodi dr. Andrej Kovačič, Ekonomska fakulteta) Delavnica e UMTS in mobilna informacijska prihodnost (vodi dr. Janez Bešter, Fakulteta za elektrotehniko) Študentski forum Razstava Družabni dogodki KOLEDAR PRIREDITEV http://www.cgo.org/reg/reg.php http://wirving.gfx.hu/applicationform.html laura.seed@hungary.com Fax: + 361 212 21 79 avenkate@uni.edu http://www.crito.uci.edu/noah/hoit2003 Fax: + 1 949 82 48091 http://www.dsi2003.org dsi2003@drustvo-informatika.si pbueso@posta.unizar.es http://www.ptwalqa.com/laboratorios/workshop.asp Fax: + 349 76761499 mka@aueb.gr http://www.sec2003.org holler@ifs.uni-linz.ac.at http://falcon.ifs.uni-linz.ac.at/ Fax: +43 0732 2468 9308 jean-paul.zolesio@sophia.inria.fr http://www.devinci.fr/cs/ifip caise03@isys.uni-klu.ac.at http://www. isys.uni-klu.ac.at/caise03 dferraiolo@nist.gov http://www.acm.org/sigsac/sacmat2003.html Fax: + 301 948 0279 efg@ncsu.eduh, ttp://www4.ncsu.edu/~efg/ Fax: (919) 513-7075 http://eCom.fov. uni-mb.si/Bled http://www.ifip.or.at Fax: +43 2236 736169 http://cot.uni-mb.si/ots2003 cot@uni-mb.si ales.zivkovic@uni-mb.si http://www.iiisci.org/sci2003 jcastellano@iiis.org Isd2003@sims.monash.edu.au http://www.monash.edu.au/conference/isd2003 renaldas.gudauskas@kf.vu.lt Fax: + 370 2 366 104 g.w.m.rauterberg@tue.nl http://www.interact2003.org http://www.drustvo-informatika.si/sekcije/sor lidija.zadnik@uni-lj.si http://www.pactconf.org pact2003@gup.jku.at http://www.forte2003.de.vu § i I 1 UNIDO - United Nations Industrial Development Organisation, Government of Hungary IFIP WG9.3 Slovensko dru'tvo INFORMATIKA, GZS - Združenje za informatiko in telekomunikacije, Infos SB 3M dldl IFIPTC11, GCS Institute of Applied Computer Science, University of Linz, Altenbergerstr. 69, 4040 Linz, Austria IFIP TC7, INRIA Faculty of Organizational Sciences, University of Maribor, Government of the Republic of Slovenia, Organizations in Slovenia's eCommerce Project, Ministry of Education, Science and Šport, Chamber of Commerce and lndustry, European Commission IFIP WG 6.1 Center za objektno tehnologijo 1C0T) in FERI Maribor IFIP, UN/UNESCO/UNU/OECD IFIP TC 13 Slovensko društvo INFORMATIKA IFIP TC6/VVG6.1 San Francisco, Califomia, US E s ra Irvine, CA, US Portorož Albarracin, Spain Athens, GR Rhodes Island, Greece Sophia, Antipolis, FR Klagenfurt, Velden, Austria Como, ltaly San Diego, CA, USA Bled Rio de Janeiro, Brazil Maribor Orlando, Florida, US Melbourne, Australia Vilnius, LT € 1 <3 1 e Zurich, CH Podčetrtek New Orleans, LA, US Berlin, Germany | L’Aquila, ltaly 23.-26. 3. 2003 27.-29. 3. 2003 6.-8. 4. 2003 16.-18. 4. 2003 8.-10. 5. 2003 26.-28. 5. 2003 26.-28. 5. 2003 26.-29. 5. 2003 16.-20. 6. 2003 § CD Ojj C\j 8. 6. 2003 1 CD 5 16.-20. 6. 2003 18.-19. 6. 2003 27.-30. 7. 2003 25.-27. 8. 2003 27.-29. 8. 2003 1.-5. 9. 2003 1.-5. 9. 2003 24. - 28. 9. 2003 27. 9.-1. 10. 2003 29. 9.-2. 10. 2003 21.10.-24.10.20031 CGO 2003 - International Symposium on Gode Generation and Optimization with Special Emphasis on Feedback-Directed and Runtime Optimization Technology Foresight Summit 2003 HOIT 2003 DSI - Dnevi slovenske informatike Workshop on Teaching of e-Govemment: Legal, Economical and Technical Aspects 18th IFIP Intl.Information Security Conf. SBC 2003 Knovvledge Management Electronic Government -KMGov-2003 Work Conference on Testing of Communicating Systems CAISE’03 The 15-Jl Conference on Advanced Information Systems Engineering Klagenfurt/Velden SACMAT 2003, ti* ACM Symposium on Access Control Models and Technologies 30* International Symposium on Computer Architeture at the Federated Computing Research Conference eTransformation, 16* Bled eCommerce Conference IFIP WG6.1 International Middlevvare Conference OTS 2003 - 8. konferenca Objektna tehnologija v Sloveniji SCI 2003 - 7* World Multi -Conference on Systemics, Cibernetics and Informatics 12th International conference on Information systems development (Methods&Tools; TheoryS.Practice) E E i | 2:n EGOV Conference From E-Government to E-Governance 9th IFIP TC 13 Intl. Conference on Human - Computer Interaction SOR '03 PACT'03 - 12" International Conference on Parallel Architectures and Compilation Technigues FORTE 2003 - 23"c International Conference on Formal Technigues for Netvvorked and Distributed Systems | CHARME 2003 Pristopna izjava Želim postati član Slovenskega društva Informatika Prosim, da mi pošljete položnico za plačilo članarine SIT 5.200 (kot študentu SIT 2.400) in me sproti obveščate o aktivnostih v društvu. (ime in priimek, s tiskanimi črkami) (poklic) (domači naslov in telefon) (službeni naslov in telefon) (elektronska pošta) Datum: Podpis: ---------------------------------------------------------------»§- — Včlanite se v Slovensko društvo INFORMATIKA. Članarina SIT 5.200,- (plačljiva v dveh obrokih) vključuje tudi naročnino za revijo Uporabna informatika. Študenti imajo posebno ugodnost: plačujejo članarino SIT 2.400,- in za to prejemajo tudi revijo. Izpolnjeno naročilnico ali pristopno izjavo pošljite na naslov: Slovensko društvo INFORMATIKA, Vožarski pot 12, 1000 Ljubljana. Lahko pa izpolnite obrazec na domači strani društva http://www.drustvo-informatika.si INTERNET ■ INTERNET ■ INTERNET ■ INTERNET ■ INTERNET ■ INTERNET Vse člane in bralce revije obveščamo, da lahko najdete domačo stran društva na naslovu: http://www.drustvo-informatika.si Obiščite tudi spletne strani mednarodnih organizacij, v katere je včlanjeno naše društvo: IFIP: www.ifip.or.at, ECDL: www.ecdl.com, CEPIŠ: www.cepis.com Revija Uporabna informatika je od številke VI11/4 vključena v mednarodno bazo INSPEC. Naročilnica Naročam(o) revijo UPORABNA INFORMATIKA Q s plačilom letne naročnine SIT 4.600 Q ......izvodov, po pogojih za podjetja SIT 13.800 za eno letno naročnino in SIT 8.900 za vsako nadaljnjo naročnino Q po pogojih za študente letno SIT 2.000 Naročnino bom(o) poravnal(i) najkasneje v roku 8 dni po prejemu računa (ime in priimek, s tiskanimi črkami) (podjetje) (davčna številka) (ulica, hišna številka) (pošta) Datum: Podpis: »g--- UPORABNA INFORMATIKA ISSN 1318-1882 Ustanovitelj in izdajatelj: Slovensko društvo Informatika, 1000 Ljubljana, Vožarski pot 12 Odgovorni urednik: Andrej Kovačič Uredniški odbor: Marko Bajec, Vesna Bosilj Vukšič, Dušan Caf, Aljoša Domijan, Janez Grad, Jurij Jaklič, Milton Jenkins, Andrej Kovačič, Tomaž Mohorič, Katarina Puc, Vladislav Rajkovič, Heinrich Reinermann, Ivan Rozman, Niko Schlamberger, John Taylor, Ivan Vezočnik, Mirko Vintar, Tatjana VValzer Dmžovec Tehnična urednica: Mira Turk Škraba Oblikovanje: Zarja Vintar, Dušan Weiss, Ada Poklač Naslovnica: Bons Tisk: Prograf Naklada: 700 izvodov Revija izhaja četrtletno. Cena posamezne številke je 3.500 SIT. Letna naročnina za podjetja SIT 13.800, za vsak nadaljnji izvod SIT 8.900; za posameznike SIT 4.600, za študente SIT 2.000. Celotni Oraclov E-Business Suite. Oracle E-Business Suite Marketing <žf Spletna trgovina <žf Prodaja <žf Podpora uporabnikom Nabava <žf Dobavna veriga (žf Finance (vf Človeški viri (žf Aplikacijski strežnik Podatkovni strežnik Oraclove rešitve so razvite za povezano delovanje. Aplikacije različnih proizvajalcev zahtevajo sistemsko integracijo. Sistemska integracija stane veliko več kot sama programska oprema. Razmislite o tem. ORACLE SOFTVVARE POVVERS THE INTERNETM www.oracle.si 0 Razprave Heinrich Reinermann E-Government and Politics Izidor Golob, Tatjana VVelzer, Boštjan Brumen Analiza in primerjava pristopov pri gradnji podatkovnih skladišč Tomaž Kralj Metode določevanja obsega funkcionalnosti 0 Poročila Damjan Kosec Globalni dostop do EAN identifikacijskih številk Boris Milikič Certifikat za razvijalca KML tehnologij 0 Rešitve Franc Brcar, Andrej Kovačič Primer uspešne informatizacije delovnega procesa Matej Gomboši, Borut Žalik, Danijel Rebolj Uporaba standarda LandKML in razširitev PmcMML issn ma-iaas