RAZVOJ OBJEKTNO ZASNOVANE PROGRAMSKE REŠITVE ZA OBVLADOVANJE POSLOVNIH PROCESOV

Transcription

1 UNIVERZA V MARIBORU FAKULTETA ZA ORGANIZACIJSKE VEDE MAGISTRSKO DELO RAZVOJ OBJEKTNO ZASNOVANE PROGRAMSKE REŠITVE ZA OBVLADOVANJE POSLOVNIH PROCESOV Mentor: izr. prof. dr. Robert Leskovar Kandidat: Aleš Gregori Kranj, januar 2008

2 Zahvala Najprej bi se rad zahvalil mojemu mentorju profesorju dr. Robertu Leskovarju za pomo in nasvete pri izdelavi magistrske naloge. Hvala tudi sodelavcem Anžetu Robidi, Urošu Strelcu, Gregu Guštinu, Mitji Felcu in Nataši Mehle iz podjetja Laser Computer d.o.o., s katerimi smo skupaj razvijali program LEA ter direktorju podjetja Jakobu Štruklju za finanno pomo pri študiju. Posebna zahvala gre mojim bližnjim sorodnikom - mami Tatjani, oetu Janiju, sestri Mojci, bratu Urošu in prijateljem Nini, Dimitriju in Marku, ki so me ves as študija spodbujali in verjeli v moje ideje. Na koncu bi se zahvalil še mojemu dekletu Klari za strokovno pomo pri študiju ter podporo pri raziskavah na podroju razvoja informacijskih sistemov in izdelavi magistrske naloge.

3 Povzetek Naloga obravnava razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov, s poudarkom na vodenju dokumentov. Organizacije pri poslovanju uporabljajo razline dokumente, ki v svojem življenjskem ciklu potujejo po oddelkih, sektorjih in med razlinimi skupinami ljudi. Pri slabo organiziranem upravljanju dokumentov lahko prihaja do izgubljanja pomembnih dokumentov in do prekoraitev rokov izvedbe. Obvladovanje kljunih dokumentov mora biti zato eden od pomembnih ciljev vsake organizacije. Glavni cilj naloge je bil razviti delujoo programsko rešitev z objektno orientiranim programskim jezikom ter prikazati objektno orientirano analizo, oblikovanje in implementacijo s pomojo diagramov UML. V nalogi so predstavljeni koncepti objektno orientiranega programiranja, programski jeziki, UML ter standardi kakovosti ISO 9001:2000. Jedro naloge predstavljajo objektno orientirana analiza in oblikovanje ter faze inkrementalnoiterativnega razvoja. Razvita programska rešitev predstavlja dodatni modul programa LEA in omogoa elektronsko upravljanje in sledenje dokumentov. S pomojo programa organizacije lažje zagotovijo, da dokumente z enakimi lastnostmi obdelajo po predvidenem postopku. Kljune besede: UML, upravljanje poslovnih procesov, objektno orientirana analiza in oblikovanje, informacijski sistem, objektno orientirano programiranje, Visual Basic.NET

4 Abstract The thesis explores the development of object oriented designed solution for workflow management system, with the main focus on document management. Organizations in their business process use different documents, which through their life cycle pass through several departments and different groups of people. Good management of the key documents must thus be one of the crucial goals of every organization. The main aim of this thesis was to develop a suitable program solution with object oriented programming language and to demonstrate object oriented analysis, design and implementation with UML. The thesis introduces concepts of object oriented programming language, UML and ISO standards 9001:2000. The core of the thesis are object oriented analysis, design and phases of iterative incremental development. Finalized solution is an additional module of LEA program. It enables electronic management and tracking of documents, which allows organizations to ensure that all documents follow the same life cycle, defined in advance. Key words: UML, workflow management system, object oriented analysis and design, information system, object oriented programming, Visual Basic.NET

5 Kazalo 1. Uvod Predstavitev problema Analiza raziskovalnih vprašanj Organizacija Procesna struktura organizacije Objektno orientirano programiranje Zgodovina in razvoj objektno orientiranega programiranja Proces razvoja informacijskih sistemov Linearni pristop Prototipni pristop Objektni pristop Programski jeziki, ki podpirajo objektno orientirano programiranje Lastnosti jezika za objektno programiranje Objekt - predmet Razred Ograjevanje - enkapsulacija Dedovanje Prenos sporoil Polimorfizem Osnovni koncepti jezika za modeliranje UML Zgodovina UML Diagrami UML Diagrami obnašanja Strukturni diagrami ISO standardi Zgodovina Splošno o standardu ISO 9001: Procesni pristop Zahteve za dokumentacijo Zahteve v procesu merjenja, analiziranja in izboljševanja procesov Modeliranje poslovnih procesov Tehnike prikazovanja poslovnih procesov... 48

6 4.2. Opis in analiza elementov Razvoj programske rešitve Zbiranje zahtev Objektno orientirana analiza Objektno orientirano oblikovanje (design) Implementacija Analiza kriterijev uspeha, kritinih dejavnikov in tveganosti vpeljave programske rešitve Primerjava objektno orientiranega pristopa v primerjavi s prototipnim pristopom Zakljuek Literatura in viri... 85

7 1. Uvod V zadnjem asu smo pria neprestanim, hitrim in nepredvidljivim spremembam v poslovnem okolju, ki silijo organizacije v stalno prilagajanje in odzivanje. as in hitrost preureditve organizacije sta odvisna od njene fleksibilnosti, velikosti, podroja dela ter vrste drugih dejavnikov. Le najboljše se bodo obdržale ali izboljšale svoj položaj na trgu, tiste, ki pa ne bodo uspele vpeljati potrebnih sprememb in se prilagoditi novemu okolju, pa bodo postopoma zaele propadati. Avtorja Hammer in Champy o tehnoloških spremembah menita, da bi izkorišanje tehnologije moralo za podjetja postati ena njihovih temeljnih nalog, e želijo biti uspešna v današnjem asu nenehnih sprememb. Tista podjetja, ki bodo bolje spremljala in uporabljala potenciale nove tehnologije, bodo imela nenehno in edalje vejo prednost pred svojimi tekmeci. Izkorišanje tehnoloških potencialov za spreminjanje poslovnih procesov podjetja in doseganje zelo opazne prednosti pred tekmeci torej ni enkraten dogodek. Nenehno spremljanje tehnoloških dosežkov in nain vkljuevanja uenja v organizacijo, mora biti trajno kot druge pomembne funkcije (Vir: Hammer, Champy, 1995, str. 107). V organizacijah raste obenem potreba po pospešitvi pretoka podatkov in informacij, saj organizacije le tako ohranjajo konkurenno prednost. Zato sta kljunega pomena hitrost in možnost prilagoditve raunalniških sistemov v uporabi, ki pa sta v veliki meri odvisni od naina izdelave ter razvoja informacijskega sistema. Razvoj programskih rešitev je celovit proces, sestavljen iz posameznih faz, ki se od metodologije 1 do metodologije razlikujejo. Organizacije uporabljajo razline metode pri razvoju programskih rešitev, pri emer je izbira metode odvisna od velikosti in obsega informacijskega sistema, ki ga želimo ustvariti, števila udeležencev, ki sodelujejo pri razvoju, zahtevane natannosti delovanja programa ter drugih elementov. Pri manjših projektih se obiajno zaetno fazo snovanja ideje lahko opravi ustno na sestanku ter se v fazo programiranja preide zelo hitro. Hkrati pa take prakse ni mogoe uporabiti pri ustvarjanju kompleksnejših sistemov, zato danes organizacije uporabljajo razline metodologije pri razvoju programskih rešitev, da bi tudi pri poveanju obsežnosti programa še vedno imele nadzor nad njegovim delovanjem. Sistematini razvoj programske opreme je pomemben tudi za lažje vzdrževanje, odpravljanje napak in vkljuevanje novih funkcionalnosti. Možnost dograjevanja in dopolnjevanja posameznega dela posameznega programa oz. celotnega programa je odvisna predvsem od njegove celotne sestave. Pri manjših programih sistemski pristop nima kljunega pomena, saj lahko programer ali skupina programerjev obvladuje celotni(celoten) sistem, pa tudi potreben as in stroški za izgradnjo sistema bi bili previsoki. Pri izgradnji vejih informacijskih sistemov pa je sistematizirani pristop 1 Metodologija - skupek metod, ki se uporabljajo pri kakem raziskovanju, mišljenju (Vir: Slovar slovenskega knjižnega jezika). Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 1

8 pomemben, saj se kompleksnost sistema poveuje veliko hitreje kot njegova velikost, kar lahko privede do tega, da se na koncu sistem izjalovi oz. presežemo predvidene stroške izdelave. Pomemben del sistematinega pristopa pri reševanju kompleksnejših problemov so programske tehnike oz. metodologije, ki se uporabljajo za opis zahtev, specifikacij, nartov in modelov. Pri prenovi oz. izgradnji raunalniških sistemov še dandanes uporabljamo številne metodologije, pristope in okvire npr.: RUP 2 metodologija; CDM 3 metodologija; EMRIS enotna metodologija razvoja informacijskih sistemov; MSF Microsoft Solutions Framework; agilne metode razvoja; MDA 4 metodologija itd. Glavni namen metodologij je predstaviti problematiko z ve zornih kotov in doloiti povezave med in znotraj podsistemov. Tako pri doloanju osnovnih konceptov kot tudi v nadaljevanju razvoja sodelujejo razlini profili zaposlenih, saj le tako lahko napravijo celovito zasnovo in kasneje primerno programsko rešitev. Pri veini metodologij se osnovni metamodel (vzorec) nariše grafino, kar omogoi tudi lažjo predstavljivost sistema kot celote. Ravno s pomojo grafinih predstavitev sistema in povezav znotraj njega se lahko v proces razvoja vkljuijo posamezniki z omejenim raunalniškim predznanjem, ki dobro poznajo vsebinsko problematiko. Neodvisno od velikosti raunalniškega programa pa zaradi dinaminega okolja posredujejo konni uporabniki svoje zahteve na dnevni, tedenski, meseni oz. letni ravni, medtem ko se potreben as za vpeljavo dodatnih sprememb in dopolnitev lahko zelo razlikuje glede na nain izgradnje programa. Pri slabo zastavljenih programih je potrebno bistveno ve asa, dogaja se celo, da morajo programerji od zaetka napisati celotne segmente programa, saj obstojea struktura ne omogoa realizacije želenih zahtev. Slika 1 prikazuje razmerje med stroški popravila programa in asom, ko odkrijemo pomanjkljivost. e napako odkrijemo relativno kmalu, se ta lahko odpravi znotraj predvidenih stroškov, kljune napake, odkrite v kasnejšem obdobju, pa lahko stroške izjemno poveajo in hkrati pomenijo tudi izgubo poslovnih partnerjev in celo dobrega imena organizacije. 2 RUP angleški izraz Rational Unified Process predstavlja ponavljajoi se proces razvoja programske opreme (Vir: dan vpogleda ). 3 CDM angleški izraz Custom Development Method (Vir: dan vpogleda ). 4 MDA angleški izraz Model Driven Arhitecture predstavlja razvoj programskih rešitev, kjer zahteve predstavimo s pomojo modelov. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 2

9 Da se takšnim problemom izognemo oz. jih odkrijemo v zgodnjih fazah razvoja, je potrebno uporabljati metodologijo, ki ustreza našim zahtevam. S primerno metodologijo tudi programerji lažje doloijo nain vpeljave želenih zahtev v trenutni sistem oz. ugotovijo, koliko asa bo potrebnega za razvoj celotnega sistema. Vzporedno s sistematinim razvojem programskih rešitev se oblikuje tehnina dokumentacija, ki se uporablja, ko že dokonani aplikaciji želimo spremeniti ali dopolniti doloene funkcionalnosti. Dobra dokumentacija sistema olajša vzdrževanje aplikacije ter povea njeno prilagodljivost in odprtost. Stroški Stroški popravila slabega designa as Slika 1: Stroški popravila slabega nartovanja (Vir: Hansen, Thomsen, 2004, str. 47). V magistrskem delu je glavni poudarek na prikazu objektno orientiranega pristopa pri razvoju objektno orientirane programske rešitve za obvladovanje poslovnih procesov s pomojo UML 5 diagramov. V prvem delu naloge so predstavljena raziskovalna vprašanja, ki se navezujejo na razvoj in izgradnjo programske rešitve za obvladovanje poslovnih procesov v organizaciji ter na primerjavo in analizo prototipnega ter objektno orientiranega pristopa. Na koncu poglavja so predstavljeni tudi osnovni pojmi organizacije s poudarkom na obvladovanju organizacije z vidika procesnega pristopa. Opisane so tudi tehnike, ki se uporabljajo pri predstavitvi poslovnih procesov. Drugo poglavje obravnava objektno orientirano programiranje. Poleg pregleda razvoja objektnih programskih jezikov so opisani trije osnovni pristopi, ki se uporabljajo pri razvoju informacijskih sistemov, njihove glavne prednosti ter pomanjkljivosti. V nadaljevanju je poudarek na osnovnih konceptih objektnega orientiranega programiranja, sledi pa predstavitev strukturnih diagramov in diagramov obnašanja. 5 UML angleški izraz Unified Modeling Language je enotni oblikovalski jezik, ki vsebuje številne diagrame in elemente diagramov, ki se uporabljajo za doloevanje lastnosti programskih rešitev (Vir: Filev, Loton, McNeish, Schoellmann, Slater, Chaur, 2003, str. 9). Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 3

10 Tretje poglavje opisuje ISO standarde, ki so pomembni z vsebinskega vidika obravnavane programske rešitve. Predstavljen je kronološki razvoj ISO standardov z glavnim poudarkom na predpisih poslovnih procesov, zahteve oz. priporoila za vodenje poslovnih procesov v organizaciji ter opisane zahteve za vodenje dokumentacije in zahteve za merjenje ter analizo le-teh. Doloanje poslovnih procesov v praksi lahko izvajamo na ve nainov oz. s pomojo razlinih tehnik. etrto poglavje je namenjeno predstavitvi razlinih tehnik risanja in modeliranja poslovnih procesov v organizacijah. V zadnjem delu poglavja so opisane zahteve elementov, ki jih uporabljamo pri risanju diagramov poteka. V petem delu naloge je poudarek na opisu razvojnih faz programske rešitve. Na zaetku so predstavljene faze objektno orientiranega pristopa in osnovne zahteve konnih uporabnikov. V poglavju Objektno orientirana analiza je podrobno predstavljeno podroje dela, ki ga mora rešitev programsko podpirati. V nadaljevanju je predstavljen kronološki razvoj modula za obvladovanje poslovnih procesov s poudarkom na uporabi razlinih diagramov UML v posameznih fazah razvoja. Ker vsaka sprememba v organizaciji prinaša prednosti in slabosti, kakor tudi nove možnosti, je v šestem poglavju s pomojo SWOT analize prikazan vidik vpeljave modula za upravljanje poslovnih procesov. Zadnji dve poglavji sta namenjeni predstavitvi in analizi pridobljenih dognanj. Prvi del zajema primerjalno analizo prototipnega in objektnega pristopa. Opisane so podobnosti in razlike ter primernost uporabe posameznih pristopov. V zadnjem delu so zajete splošne ugotovitve pri uporabi objektnega pristopa in UML pri razvoju raunalniške aplikacije za obvladovanje poslovnih procesov ter podani odgovori na raziskovalna vprašanja Predstavitev problema Upravljanje dokumentov 6 (ang. Document Management) je postalo pomemben cilj organizacij, ki so spoznale, da urejenost dokumentov predstavlja prednost pred konkurenco in hkrati premoženje organizacije. Ker pa si dokumentov danes ne predstavljamo ve le v papirnati, temve tudi v digitalni obliki, vse pogosteje uporabljamo elektronski sistem za upravljanje z dokumenti (Electronic Document Management System, v nadaljevanju EDMS). Organizacije so namre spoznale, da tako vodstvo kot ostali zaposleni potrebujejo za uspešno 6 Dokument je skupek informacij, pridobljenih iz razlinih virov, shranjenih v razlinih formatih, ki opisujejo posamezno podroje tako kot si ga predstavlja posameznik (Vir: Bielawski L., Boyle J., 1997: 173). Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 4

11 poslovanje hiter in zanesljiv dostop do dokumentov, pri emer se pojavlja težnja po možnosti hkratnega dostopa ve zaposlenih do posamezne informacije oz. dokumenta. Zakonodajna podlaga za vpeljavo teh sistemov je bila v Sloveniji sprejeta leta 1999 z Zakonom o elektronskem poslovanju in elektronskem podpisu, po katerem je dokument v elektronski obliki enakovreden dokumentu v papirnati obliki. Pomembna naloga EDMS sistemov je obvladovanje procesov in življenjskega cikla dokumentov. Za doloanje procesov v organizaciji je potrebno predznanje programiranja, saj se procese definira v obliki programske kode. Težave nastanejo v organizacijah, kjer so zaposleni, ki poznajo potek dela, in zaposleni, ki doloajo procese v EDMS sistemih, razline osebe. V podjetju LASER Computer d.o.o. sodelujemo pri projektu izdelave programskega paketa»laserjev elektronski arhiv«(v nadaljevanju LEA), ki manjšim organizacijam omogoi vpeljavo t.i. pisarno brez papirja (»paperless office«). eprav je vzpostavitev pisarne brez papirja v isti obliki zaenkrat še nedosegljiv cilj, pa prinese organizaciji že vpeljava elektronskega arhiva veliko koristi in prednosti. Osnovno ogrodje programa LEA je napisano v programskem okolju Visual Studio 6.0 in je sestavljeno iz naslednjih modulov: modul za zajem dokumentov; modul za iskanje po dokumentih; modul za optino prepoznavanje znakov (OCR 7 ) in modul za administracijo pravic uporabe programa. Delitev programa na module je bila izbrana zato, ker omogoa uporabo bodisi paketa kot celote bodisi le posamezna podroja, primerna za doloenega konnega uporabnika. Komponente so zgrajene tako, da lahko funkcionirajo skupaj ali neodvisno ena od druge. Pri svojem poslovanju uporabljajo organizacije veliko koliino dokumentov, ki potujejo skozi razline oddelke. Meje služb in oddelkov postajajo ogromna prepreka hitremu pretoku informacij, dokumentov, aktov (Vir: Vila, 2000, str. 90). Zato se poskuša v organizacije uvesti sistem, s katerim bomo dokumente im prej pretvorili v elektronsko obliko in se tako izognili mejam med oddelki, pri emer pa je pomembno, da digitalni dokument pride do prave osebe v pravem asu. Za zadovoljitev tega pogoja je potrebno dokumentom doloiti osnovne lastnosti in njihov življenjski cikel. Znotraj vsake organizacije se odvijajo procesi, ki doloajo nain poslovanja. Pri izgradnji splošne rešitve za nadzor procesov je potrebno pripraviti dovolj odprt raunalniški 7 OCR angleški izraz Optical Character Recognition, ki predstavlja postopek pretvorbe bitne slike besedila v besedilo, ki ga je mogoe obdelovati v urejevalniku besedil. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 5

12 sistem, da ga lahko uporabljajo razline organizacije. Za vsak dokument administrator doloi pot, ki jo dokument opravi v svojem življenjskem ciklu. Doloanje poti je ponazorjeno preko grafinega vmesnika tako, da tudi drugi posamezniki lažje razumejo svojo vlogo v posameznem procesu. Grafini vmesnik omogoa modeliranje procesa z osnovnimi elementi diagrama poteka. Ena pomembnih prednosti raunalniškega beleženja poti dokumenta je lažje nartovanje dela. Hkrati vodstvu organizacije omogoa veji nadzor pretoka dokumentov, hitrejše odkrivanje pomanjkljivosti v procesih in posledino njihovo postopno izboljšanje. Pri tem je potrebno zagotoviti, da sistem uporabljajo vsi zaposleni v organizaciji, saj vsak dokument, ki gre mimo omenjenega raunalniškega sistema, pomeni neuspešno implementacijo sistema v celoti. Zato morajo konni uporabniki razumeti prednosti, ki jih njihovemu delu prinaša aplikacija, obenem pa mora biti ta prijazna za uporabo. Pri razvoju raunalniških projektov se velikokrat zgodi, da se postavljeni roki za izdelavo konne rešitve presežejo, da so stroški razvoja bistveno veji od predvidenih ter da konna rešitev zaradi nesporazuma med razvijalci in naroniki mnogokrat ne doseže priakovanih zahtev. S primerno uporabo metodologije in pravim sistemskim pristopom se možnost, da se bo projekt izjalovil, bistveno zmanjša, hkrati pa so tudi kompleksne aplikacije obvladljive in bolj zanesljive. Cilj magistrske naloge je predstaviti razvojne cikle raunalniške rešitve za obvladovanje poslovnih procesov v organizaciji s pomojo objektnega pristopa v povezavi z diagrami UML. Modul predstavlja pomemben del celotnega sistema LEA, saj brez analize in upravljanja procesov EDMS sistem ne dobi prave vrednosti in predstavlja le elektronski arhiv. Modul za obvladovanje poslovnih procesov zajema vse najpomembnejše dokumente v organizaciji (npr. raun, ponudba, pogodba) Analiza raziskovalnih vprašanj Naloga poleg razvoja objektno orientirane programske rešitve analizira in primerja uporabo objektnega ter prototipnega pristopa. Raziskovalna vprašanja: I. Kako z diagrami UML analizirati in zasnovati programsko rešitev za obvladovanje poslovnih procesov? UML prestavlja nov poenoteni jezik za modeliranje informacijskih sistemov in se tako kot ostale stvari v informatiki zelo hitro razvija; odkar je bil prvi objavljen se je razširil in dopolnil, kar naj bi povealo možnosti uporabe. Vejo uporabo je vsekakor možno zaslediti v razvojnih centrih, kjer sodeluje veje število nartovalcev in programerjev hkrati, medtem ko pri manjših projektih zaradi podaljšanja asa razvoja ne pride v poštev. V nalogi je Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 6

13 ocenjen pomen in donos diagramov UML, ki so bili uporabljeni pri izgradnji programske rešitve za obvladovanje poslovnih procesov. II. Kakšne so lastnosti razvite programske rešitve z uporabniškega vidika? Programske rešitve morajo ob izpolnjevanju postavljenih zahtev biti prijazne za uporabo. V tem delu so opisane znailnosti konnega izdelka v primerjavi z osnovnimi zahtevami konnega uporabnika ter predstavljena mnenja konnih uporabnikov z vidika zapletenosti uporabe. III. Kakšne so prednosti in slabosti uporabe objektnega pristopa in diagramov UML v primerjavi s prototipnim pristopom pri razvoju informacijskih sistemov? Pri prejšnjih projektih smo uporabljali prototipni pristop izgradnje informacijskih sistemov, pri obravnavanem primeru je bil uporabljen objektni pristop. Na podlagi razvoja so opisane podobnosti in razlike med obema pristopoma. IV. Kako je ob hkratni uporabi razlinih programskih jezikov oz. orodij mogoe uporabiti UML pri razvoju programskih rešitev? Avtorji zagovarjajo trditev, da UML ni vezan le na objektne jezike, ampak ga lahko uporabimo pri vsakem programskem jeziku. Pri razvoju programske rešitve je bil uporabljen programski jezik Visual Basic 6.0 in Visual Basic.NET ter raziskana primernost diagramov UML pri uporabi dveh razlinih programskih jezikov Organizacija Za preuevanje poslovnih procesov je potrebno dobro razumevanje organizacije kot tudi razumevanje samega pojma organizacija. Definicijo organizacije je težko enoznano doloiti, saj obstaja skoraj toliko njenih opredelitev kot je organizacijskih in managerskih šol. Razlogi za razvoj velikega števila teorij so tako zgodovinski in kulturni, kot tudi razvoj same organizacijske znanosti ter kompleksnost organizacije. Pojem organizacija izhaja iz latinske besede»organizatio«, ki pomeni združbo, zvezo na primer skupnost ljudi, ki jih veže kak program, cilj, delo (Vir: Verbin, 1994, str. 822). V nadaljevanju so predstavljeni razlini vidiki in definicije organizacij, ki so se oblikovale skozi zgodovino. V tridesetih letih prejšnjega stoletja se je predvsem v ZDA razvila teorija o medloveških odnosih, ki je opredeljevala organizacijo kot socialni kooperativni sistem Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 7

14 odnosov med ljudmi v podjetju. V petdesetih letih je teorija prešla v teorijo o loveških virih, ki obravnava organizacijo kot sociotehnini sistem. Po letu 1950 se je razvila sistemska teorija o organizaciji, ki slednjo opredeljuje kot sistem snovnih in loveških sestavin ter njihovih medsebojnih povezav. Nekateri avtorji, predvsem francoski, razumejo organizacijo kot proces, s katerim se zagotovi smotrno in nemoteno sodelovanje posameznih organov organizma združbe, ta proces pa sestavljajo vsebinsko doloeni prvinski in izvirni procesi. Ti avtorji so predpostavili, da gre najprej za formalno in nato za neformalno procesno opredelitev organizacije. Spet tretji avtorji so poleg formalne opredelitve dodali še socialno noto, kot hoteno zvezo ljudi, združbo ljudi, obliko loveške združbe, loveško skupino ali pa družbeno telo oz. družbeni organizem. Po njihovem poimenovanju gre za subjektivno opredelitev organizacije, ki predstavlja združbo ljudi, ki delujejo zaradi uresnievanja skupnih ciljev (Vir: Miheli, 1999, str ). Podobno definira organizacijo tudi S. Marjanovi: organizacija je vsako loveško združenje z namenom, da bi se dosegli skupni cilji (Vir: Miheli, 1999 a, str. 183). Tudi klasina organizacijska znanost pozna dve opredelitvi organizacije: organska teorija primerja organizacijo z živim organizmom in predpostavlja, da ima ta enako kot organizem smoter, ta pa se leni na funkcije, ki jih opravljajo njeni organi. Vsak del organizacije opravlja doloene funkcije, njihovo delovanje pa je usklajeno in usmerjeno k izvajanju skupne naloge. Iz te teorije so se obdržali tudi številni izrazi, kot so funkcija, organ, analiza, diagnoza. Pripadniki mehanistinega pojmovanja organizacije so to tezo obravnavali kot mehanizem, ki ima splošne znailnosti popolnega stroja. Organizacija je zanje, podobno kot stroj, depersonaliziran aparat, ki omogoa sistem dela in je zasnovan na racionalnih osnovah. Takšen aparat mora delovati brez trenja, brez napak, povzroenih zaradi loveških slabosti in ne sme biti podvržen raznim subjektivizmom (Vir: Ivanko, 2000, str ). Poglejmo si še nekaj drugih definicij organizacij: Douma in Schreuder opredeljujeta organizacijo kot splet pogodb, koalicijo udeležencev oz. ravnateljsko sestavo, ki vzpostavlja enotnost in je zakonito priznana kot taka (Vir: Miheli, 1999 a, str. 187). Po Steayertu in Bownu je organizacija (kot dojeta slika sodelujoih) neprestan proces pogajanja, v katerem ljudje medsebojno souinkujejo in vplivajo drug na drugega, da bi skupno opredelili družbeno stvarnost (Vir: Miheli, 1999 a, str. 187). Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 8

15 Weick in Roberts obravnavata organizacijo kot medsebojno skupno razumevanje z uporabo zamisli o skrbnih medsebojnih razmerjih, ki jih ustvarjajo in spreminjajo posamezniki (Vir: Miheli, 1999 a, str. 187). Za Johannsena in Pagea je organizacija izvedena delitev celovite naloge ravnateljstva z doloanjem odgovornosti in oblasti za izvedbo doloenega dela ter doloitev razmerij, ki naj bi obstajala med nosilci doloenih funkcij in položajev (Vir: Miheli, 1999 a, str. 187) Procesna struktura organizacije Vasih smo si pod pojmom organizacija najprej predstavljali organizacijsko strukturo, ne pa tudi funkcioniranja organizacije, kar predstavlja pomembno pomanjkljivost, saj mora zaposlen, e želi spremeniti svoje delovanje, poznati procese, ki se odvijajo znotraj nje. Po Antunu Vili (2000) je proces doloeno število aktivnosti v nekem zaporedju, povezanih v neko celoto, ki jemljejo nek input, da bi ga pretvorile v doloen output. Transformacija, ki se pojavlja v procesu, mora dodati vrednost inputu in ustvariti output, ki je koristnejši in uinkovitejši za prejemnika. Organizacija, ki je usmerjena v proces, ne pozna meja funkcij, oddelkov in služb. Proces postaja enotna celota, ki se ga preuuje, analizira in organizira. Optimizacija poslovnih procesov se je v praksi uveljavila na dva naina. Pri prvi obliki gre za prenovo poslovnih procesov. Zaradi tega so se v zadnjih letih razvile nove metode za prenovo že obstojeih organizacij, imenovane reinženiring oz. preurejanje poslovanja, ki so se najbolj razširile v ZDA. Preurejanje temelji na vnovinem premisleku poslovnega procesa in njegovem korenitem preoblikovanju, da bi tako dosegli velike izboljšave kritinih kazalcev uinkovitosti, kot so stroški, kakovost storitev in hitrost. Definicija vkljuuje štiri kljune besede: temeljen, korenit, dramatien in proces (Vir: Hammer, Champy, 1995, str. 42). Po besedah avtorjev veina vodilnih poslovnežev preprosto ni procesno usmerjenih, temve so še vedno osredotoeni na naloge, dela, ljudi in strukture, ne pa na procese. Procesi niso nekaj, kar so si izmislili razlini avtorji zato, bi jih lahko obravnavali, temve je vsako podjetje sestavljeno iz njih. Procesi v podjetju se skladajo z naravnimi poslovnimi dejavnostmi, vendar so pogosto razdrobljeni in skriti za organizacijskimi strukturami (Vir: Hammer, Champy, 1995, str. 125). Pri preurejanju procesov je pomembno, da organizacija izbere procese, pri katerih imajo najve težav, so najpomembnejši za odjemalce ter tiste procese, ki jih trenutno najlažje uspešno preuredijo (Vir: Hammer, Champy, 1995, str. 129). Takšen nain optimizacije na stare poslovne procesa gleda kot na zgodovino in želi ustvariti povsem nove procesa od zaetka. Kljub številnim prednostim, ki jih v svoji knjigi opisujeta Hammer in Champy (1995), pa so se pri takšnem nainu optimizacije številni projekti izjalovili in ustvarili celo slabše rezultate kot prej obstojei sistem. Zato se je razvil še drugi pristop, ki predvideva nenehno izboljševanje poslovnih procesov (CPI continuous process improvement). Ta temelji na tem, da na podlagi rezultatov trenutnih procesov opravimo analize ter nato predlagamo nove spremembe oz. izboljšave že obstojeih procesov. S takšnim Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 9

16 pristopom se postopoma odpravljajo napake in pomanjkljivosti trenutnega sistema, namesto da sistem zasnujemo od zaetka. Preurejanje v organizacijah pomeni torej analiziranje in izboljševanje procesov, seveda pa lahko pri tem najvekrat uporabimo novo informacijsko tehnologijo, ki pa je ne moremo enaiti s preurejanjem. Prav tako ne smemo enaiti preurejanja poslovanja s preurejanjem informacijske tehnologije, kjer se posodobi zastarelo programsko in strojno opremo z novejšo (Vir: Hammer, Champy, 1995, str. 57). Zaradi posledic v organizacijah, ki so izvajale preureditve, je termin reinženiring organizacije na žalost postal sinonim za odpušanje zaposlenih in tudi za zmanjšanje števila organizacijskih nivojev (Vir: Vila, 2000, str. 118). Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 10

17 2. Objektno orientirano programiranje Objektno orientirano programiranje (v nadaljevanju OOP) ni revolucija na podroju programiranja, temve lahko govorimo o evoluciji, saj predstavlja nadgradnjo programskih jezikov. Razvoj programskih jezikov je od proceduralnega in modularnega programiranja ter abstraktnih podatkovnih tipov prešel k objektno usmerjenemu programiranju. Proceduralno programiranje daje poudarek proceduri kot abstrakciji, ki opiše obnašanje, vendar ne zašiti podatkov. Modularno programiranje dodatno zašiti podatke tako, da jih kapsulira oz. ogradi. Velika slabost modulov je ta, da ne omogoajo ustvarjanja primerkov. Modul in tip sta tako razlina in nezamenljiva koncepta. To slabost odpravljajo abstraktni podatkovni tipi, ki omogoajo oblikovanje takšnih primerkov tipov, ki so vgrajenim tipom enakovredni. Slabost abstraktnih podatkovnih tipov pa je, da jih pogosto ne moremo razvršati v hierarhije. Znanje o nekem problemu je veliko popolnejše in celovitejše, e poznamo neke splošne zakonitosti, iz katerih sledi specializacija. OOP je nadgradnja abstraktnih podatkovnih tipov, kjer lahko razvrstimo razrede v hierarhije. Prednosti OOP predpišemo predvsem dedovanju, saj lahko že napisano kodo uporabimo vekrat (Vir: Mernik, Žumer, 2003, str. 158). Glavna ideja objektno orientiranega programiranja je v tem, da program predstavlja celoto, sestavljeno iz številnih samostojnih enot oz. objektov. Vsak objekt se lahko preko sporoil sporazumeva z okoljem, procesira podatke in oddaja sporoila drugim objektom. Ena najpomembnejših prednosti OOP je dedovanje, ki omogoa postopni razvoj programov, kjer razred od nadrazredov podeduje lastnosti in obnašanje. V novo nastali razred se dopolni le tiste lastnosti in metode, ki jih nadrejeni razred nima. Dedovanje med razrede/objekte uvede tranzitivno relacijo in jih hierarhino uredi glede na njihove splošne in specifine lastnosti. Objektni jeziki - razredi + razredi Nerazredni jeziki Razredni jeziki + dedovanje + dedovanje Prototipni objektno usmerjeni jeziki Razredni objektno usmerjeni jeziki Slika 2: Hierarhija objektnih jezikov (Vir: Mernik, Žumer, 2003, str. 161). Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 11

18 Programske jezike, pri katerih osnovni koncept predstavlja objekt, imenujemo objektni jeziki. e objekte ustvarimo s pomojo razredov, govorimo o razrednih jezikih. Ko razrednim jezikom dodamo dedovanje, govorimo o razredno objektno usmerjenih jezikih ali objektno usmerjenih jezikih. S pomojo enabe lahko to zapišemo tako: Razredni objektno usmerjeni jezik = objekti + razredi + dedovanje e objekte ustvarimo s pomojo kloniranja, govorimo o nerazrednih jezikih, ko pa jim dodamo še dedovanje, pa o prototipno objektno usmerjenih jezikih ali prototipnih jezikih. To zapišemo s pomojo naslednjega izraza: Prototipno objektno usmerjeni jezik = objekti razredi + dedovanje V praksi so danes razredno objektno usmerjeni jeziki veliko bolj uporabljeni in uveljavljeni, saj imajo nekoliko daljši as razvoja, medtem ko so prototipni objektno usmerjeni jeziki še v fazi razvoja (Vir: Mernik, Žumer, 2003, str ). Med prototipno objektno usmerjene jeziki štejemo: Actor-Based Concurrent Language (ABCL): ABCL/1, ABCL/R, ABCL/R2, ABCL/c+, Agora, Cecil, Cel, ColdC, ECMAScript, ActionScript, DMDScript, E4X, JavaScript, JScript, Factor, Io, Kevo, Lisaac, Logtalk, Lua, LPC, MOO, NewtonScript, Obliq, Omega, OpenLaszlo, Perl, with the Class::Prototyped module, REBOL, Self, Slate, Squeak, Morphic components, Etoys, TADS (Vir: /wiki/prototype-based_programming, datum vpogleda: ) Zgodovina in razvoj objektno orientiranega programiranja Koncept objektov in instanc v programiranju zaznamo z razvojem sistema PDP-1 8 pri MIT 9, ki je predstavljal prvi primer arhitekture, temeljee na poveanju zmožnosti delovanja (capability based architecture). Med prve naznanitve štejemo tudi program Sketchpad, ki ga je razvil Ivan Sutherland leta 1963, ki pa je bil le aplikacija in ne nov vzorec za programiranje. Zaetki objektno orientiranega programiranja segajo v leto 1967 z nastankom programskega jezika Simula-67, ki sta ga razvila Ole-Johan Dahl in Kristed Nygaard iz Norveškega raunalniškega centra v Oslu v okviru projekta, ki je zajemal analizo uinka razlinih atributov na povezave med ladjami. Pri tem sta razline tipe ladij razvrstila v posamezne razrede ter vsakemu razredu doloila lastnosti in procedure. Tako so bili uvedeni koncepti dedovanja, razred in objekt. 8 PDP-1 angleški izraz Programmed Data Processor-1 je bil prvi raunalnik serije Digital Equipment narejen leta MIT angleški izraz Massachusetts Institute of Technology razvojno raziskovalni center v ZDA. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 12

19 Leta 1971 se je zael razvoj objektno usmerjenega jezika Smalltalk, ki je temeljil na naslednjih naelih: vse je objekt (tudi razred); vsak objekt je primerek nekega razreda (razred je tako primerek metarazreda) in vse operacije so obravnavane kot sporoila. Osnovna ideja se je kasneje uporabila tudi pri številnih drugih programskih jezikih kot na primer Lisp, Pascal. Ker jezik Smalltalk vsebuje le osnovne koncepte gre za enostavno uporabo in uenje. Objektni jeziki so res zaživeli šele z nastankom objektno usmerjenega jezika C++. Bjarne Stroustrup je leta 1979 z vpeljavo razredov v jezik»c with Classes«nadgradil programski jezik C. Jezik je bil prvi uradno implementiran konec leta 1983, medtem ko je pravi razmah doživel po letu V devetdesetih letih je bil OOP prevladujo vzorec programiranja in C++ najbolj množino uporabljan objektno usmerjeni jezik. Lastnosti objektno orientiranih jezikov so bile dodane tudi drugim že obstojeim jezikom Ada, BASIC, Lisp, Fortran, Pascal itd. Dodajanje lastnosti jezikom, ki niso bili tako razviti v svojih osnovah, je lahko povzroilo številne probleme s kompatibilnostjo in vzdrževanjem kode. Po drugi strani pa so objektno orientiranim jezikom manjkale še številne znailnosti, ki so jih programerji uporabljali pri drugih jezikih. Da bi zadovoljili tudi tem zahtevam, je Bertrand Meyer razvil nov programskih jezik Eiffel. V prejšnjem desetletju se je najbolj uveljavil programski jezik Java, verjetno tudi zaradi podobnosti s programskim jezikom C in C++ ter zaradi možnosti uporabe na razlinih platformah. Ravno zaradi te lastnosti je Java postala zelo zanimiva za številne programerje, saj se v zadnjih asih uporabljajo številni operacijski sistemi. Tudi Microsoftov jezik.net je objektno orientiran, podpira objektni razvoj in hkrati kompatibilen s prejšnjimi razliicami. V zadnjem asu je cilj številnih objektno orientiranih jezikov kompatibilnost s proceduralnimi metodologijami kot sta Python in Ruby. Poleg Jave, C#, C++ se v zadnjem asu tudi vse bolje uveljavljajo Microsoftovi programski jezik iz razvojnega orodja Visual Studio.NET, ki delujejo na platformi.net. Znailnosti objektno usmerjenega programiranja so: objekti, razredi, dedovanje, pošiljanje sporoil, dinamino klicanje metod, polimorfizem (Vir: /Object_orientation, vpogled: ) Proces razvoja informacijskih sistemov Proces nastajanja in oblikovanja informacijskega sistema imenujemo tudi življenjski ciklus informacijskega sistema. Ta vsebuje faze, ki si sledijo v doloenem zaporedju in so Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 13

20 odvisne od uporabljene metodologije razvoja. Skozi zgodovino so se oblikovali razlini pristopi, ki so skušali imbolj povezati razvoj IS in metodološki pristop projektiranja IS. Na življenjski ciklus razvoja vplivajo zlasti velikost in kompleksnost projekta, metodologija razvoja, ki jih podpirajo vodilni v podjetju in razvijalci ter druge okoljske in kulturne okolišine Linearni pristop Med najstarejše zasnove spada linearni pristop, ki izhaja iz predpostavke, da si procesi sledijo zaporedno. Glavna znailnost takšnega pristopa je, da se nobena faza ne more zaeti, dokler ni v popolnosti zakljuena predhodna faza. Faze razvoja potekajo kaskadno ter so natanno definirane in podrobno dokumentirane. Iz zaetne analitine faze obravnavanega problema se obiajno neposredno preide na izdelavo izvedbenega modela IS, ki je praviloma nenatanen, neformaliziran in zato vir mnogih napak. Glavna prednost takšnega pristopa je dobra preglednost stanja posameznega projekta, standardizacija postopkov, dokumentacija ter nadzor nad sodelavci v projektnem timu. Seveda pa v realnem življenju ni mogoe tono doloiti vsake faze, zato je prehode med njimi težko opredeliti. Zelo pogosto se zgodi, da predhodna faza ni bila dovolj dobro opravljena in se je kasneje potrebno vraati nazaj in spreminjati že narejeno dokumentacijo, kar poveuje stroške in podaljša as realizacije (Vir: Kovai, Vintar, 1994, str 44-47). Postopek klasinega procesa razvoja programskih rešitev je predstavljen na sliki številka 3. Potrditev projekta Zahteve razvoja Grobi nart Podrobni nart Programiranje Testiranje Pomo - vzdrževanje Slika 3: Obiajni življenjski cikel razvoja programskih rešitev po linearnem pristopu (Vir: Filev, Loton, McNeish, Schoellmann, Slater, Chaur, 2004, str. 209). Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 14

21 Prototipni pristop Prototip je prvi primerek, s pomojo katerega želimo ugotoviti njegove lastnosti, stroške, obnašanje itn. Obiajno ni namenjen redni uporabi, se pa z njegovo pomojo izdela konni proizvod. Takšen nain uporabe zasledimo pri linearnem pristopu, kjer lahko konnemu uporabniku pokažemo osnovne funkcije in pri tem zanemarimo detajle ter razline kontrole. Pri izdelavi prototipa se lahko uporabljajo tudi druge metodologije in programski jeziki, kot pri konni rešitvi. Prototipni pristop lahko predstavlja tudi postopen proces razvoja želenega produkta. S pomojo konnega uporabnika izdelamo prototip sistema, ki ga kasneje dopolnjujemo in spreminjamo, dokler ne ustreza vsem zahtevam uporabnika. V tem primeru se prototip postopoma razvije v konni proizvod. Prototipni pristop je nastal zaradi pomanjkljivosti linearnega pristopa v zaetku osemdesetih let, pri emer je bil glavni namen: skrajšati as dostopa do prvih rezultatov; omogoiti stalno interakcijo med konnim uporabnikom in razvijalci ter odkriti morebitne napake in pomanjkljivosti v zaetnih fazah razvoja, ko jih je tudi enostavnejše odpraviti. Prototip mora zato imeti naslednje lastnosti: biti majhen za izvedbo; dovolj vpliven in prepriljiv; dovolj poceni in dolgoroen; dovolj nujen za izvedbo. Z vidika izvajanja postopka je prototip podoben simulaciji (preizkušanje na modelu brez tveganja za original, glavni namen je spoznavanje raziskovalnega pojava, njegovega obnašanja in iskanje uinkovitih ukrepov). V fazi razvoja oblikujemo tako model kot prototip, pri emer obravnavamo enostavnejši koncept in tako raziskujemo obnašanje. Na podlagi pridobljenih izkušenj pridemo do potrebnih ugotovitev. Zagovorniki takšnega pogleda menijo, da uporabniki sami niso zmožni opredeliti informacijskih potreb, dokler teh rešitev ni mogoe praktino preizkusiti. Prototipni pristop je v praksi zelo pogosto uporabljen, saj so problemi slabo strukturirani in zahtevajo vejo pozornost pri razvoju zasnovanega in empirinega modela (Vir: Kovai, Vintar, 1994, str 47-48, ). Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 15

22 Objektni pristop Objektni pristop je najsodobnejši pristop, ki se je uveljavil šele v zadnjih letih. Ideja o takšnem pristopu se je najprej razvila pod okriljem nekaterih objektno orientiranih programskih jezikov, kot so SIMULA, Smalltalk in C++. Objektni pristop rešuje doloene slabosti klasinega razvoja informacijskih sistemov. Prejšnje metodologije so loeno obravnavale statine (podatki) in dinamine (procedure) vidike sistema, kar je povzroalo nekonsistentnost razvoja in prepreevalo tipizacijo osnovnih gradnikov sistema, to pa poveuje as in stroške njegovega razvoja. Pristop temelji na treh temeljnih konceptih: objekt, sporoilo in tip objekta. Nastala je ideja, da bi lahko programsko opremo razvijali podobno kot strojno, to je iz množice sestavnih delov, kjer vsak del deluje kot samostojna celota, lahko pa jih poljubno uporabljamo in to v razline namene (Vir: Kovai, Vintar, 1994, str 48-50). Objektni pristop pri razvoju informacijskih in programskih sistemov je neloljivo povezan z inkrementalno - iterativnim (postopnim, evolucijskim) razvojem, kar je posledica uporabe istih konceptov v vseh fazah razvoja. Na ta nain je odpravljen osnovni problem veine tradicionalnih pristopov, ki uporabljajo v razlinih fazah razline koncepte, notacije in modele, hkrati pa vsiljujejo nenaravno loevanje posameznih vidikov modeliranega sistema. Posledino so ostale neizkorišene možnosti ponovne uporabe (Vir: Sili, Krisper, Rozman, 2000, str. 11). Osnovne koncepte objektnega pristopa podpirajo številne metodologije, zelo pogosto pa je uporabljen Rational Unified Process, ki razdeli razvoj v štiri glavne faze: zahteva, analiza, izgradnja in implementacija. Posamezne faze si sledijo zaporedno, vendar jih ne smemo mešati s sekvennim pristopom, saj se faze ponavljajo pogosteje v precej krajših intervalih. V fazi zahtev se z opredelitvijo splošnih znailnosti doloi obseg projekta. Pri manjših projektih se lahko to fazo izvede z neformalnim pogovorom, pri vejih pa ji je potrebno posvetiti ve asa. Možni dokumenti, ki nastanejo v tej fazi, so: splošni opis projekta; dokument, ki vsebuje glavne zahteve stranke; osnovni slovar; poslovni primeri uporabe; ocenitev morebitnih tveganj in nart projekta. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 16

23 Sledi faza analize, v kateri obdelamo problem in nadalje razdelamo nart projekta, s imer zmanjšamo možnost napake. Na koncu faze moramo imeti pregled celotnega projekta in natanno razumeti, kaj bo sistem moral opravljati. V fazi izgradnje gradimo produkt v obliki spiralnega modela, tako da se posamezne faze ponovijo vekrat. Tone faze vsebuje slika 4. Z zmanjšanjem trajanja izvedbe vsake faze na minimum se izognemo eni glavnih slabosti zaporednega pristopa. Po izvedbi številnih ponovitev bomo imeli sistem, ki bo deloval in ga bomo lahko uporabili. Zahteve Analiza Izgradnja Implementacija Analiza Analiza Analiza Analiza Design Design Design Design Kodiranje Kodiranje Kodiranje.. Kodiranje Testiranje Testiranje Testiranje Testiranje Prva ponovitev Druga ponovitev Tretja ponovitev N-ta ponovitev Slika 4: Faze inkrementalno - iterativnega razvoja (Vir: UML Applied, Object Oriented Analysis and Design using the UML, 2001, str. 14). V zadnji fazi implementacije se osredotoimo na prenos produkta do kupca. Obiajno v tej fazi izvedemo naslednje akcije: izdela se beto razliico programa za testiranje; novo aplikacijo vodimo vzporedno s trenutnim sistemom; prenesemo podatke v nov sistem; izobražujemo konne uporabnike in konno prenesemo produkt in ga prodamo. Pred zadnjo fazo mora biti produkt narejen že skoraj za konno uporabo. Pri vejih sistemih so potrebne posamezne, zgoraj naštete akcije, pri manjših pa se ta faza hitro zakljui. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 17

24 2.3. Programski jeziki, ki podpirajo objektno orientirano programiranje Programski jezik je skupek sintaktinih in semantinih pravil, podatkovnih struktur ter vmesnikov, ki programerjem služijo kot orodje za izdelavo aplikacij. Programske jezike lahko razdelimo na nizkonivojske, ti so bližje strojnemu jeziku in visokonivojske, ki so bližje naravnim jezikom. Trenutno obstaja v svetu ve kot programskih jezikov in v prihodnosti lahko priakujemo še veji razmah (Vir: Mernik, Žumer, 2003, str. 13). Nesmotrno bi bilo priakovati, da bi se v prihodnosti število programskih jezikov zmanjšalo oz. da se bo uporabljalo le nekaj programskih jezikov. Vsekakor pa ne bo nikoli obstajal en univerzalni programski jezik, zato je pri vsakem projektu kljunega pomena tudi izbira programskega jezika. V literaturi so najpogosteje omenjeni naslednji objektno orientirani programski jeziki: ActionScript, Ada 95, Boo, C++, C#, ColdFusion, Common Lisp, CorbaScript, COOL (Object Oriented COBOL), D, Delphi, Dylan, Eiffel, F-Script, Fortran 2003, Gambas, IDLscript, incr Tcl, J, Java, Join Java, Lexico, Lingo, Modula-2, MOO, Oberon, Oberon-2, Object REXX, Objective-C, Ocaml, PHP, PowerBuilder, Python, REALbasic, Sather, Scala, Simula, Smalltalk, Bistro, STOOOP (Tcl extension), Superx++, VBScript, Visual Basic, VB.NET, Visual Prolog, XOTcl in ZZT-oop (Vir: datum vpogleda ) Lastnosti jezika za objektno programiranje Ko govorimo o objektno orientiranemu pristopu, prihaja v praksi do razlinih razumevanj o tem kaj predstavlja objekt. Z vidika raunalniškega sistema razdelimo objekte v tri glavne skupine: objekti na uporabniškem vmesniku so objekti, preko katerih ima uporabnik neposredno interakcijo s programom. Ti objekti imajo doloene lastnosti, lahko izvajajo operacije, se povezujejo med seboj in so povezovalni len s konnim uporabnikom (na primer: gumb, drsnik, okno); v naslednjo skupino spadajo objekti v operacijskem okolju. To so objekti, ki obstajajo nekje v raunalniškem omrežju ali so objekti, ki jih kontrolira operacijski sistem v raunalniku (na primer: koncept odjemalec/strežnik); objekti, povezani z izvedbo doloene naloge so objekti, ki jih ustvarja oz. uporablja raunalniški program. Mednje spadajo objekti dokumentov, multimedijski objekti in objekti, ki pokrivajo podroje problematike. Objekti v prvih dveh skupinah so lažje predstavljivi kot objekti raunalniškega sistema, saj Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 18

25 jih je veina uporabnikov že videla ter se obnašajo kot objekti v realnem svetu. V tretjo skupino spadajo objekti, ki so povezani z delovanjem informacijskega sistema (na primer: stranka, poslovna enota). Takšni objekti predstavljajo abstrakcijo realnega sveta in vsebujejo le lastnosti, ki zanimajo konnega uporabnika. Objekt zna narediti stvari tako, kot jih zahteva uporabnik (Vir: Satzinger, Ovrik, 2001, str ) Objekt - predmet Objekt je združba podatkov in funkcionalne logike. Podatki definirajo stanje objekta, operacije pa predstavljajo funkcije in transformacije, ki jih lahko uporabimo nad objektom oz. jih ta zagotavlja (Vir: Sili, Krisper, Rozman, 2000, str. 5). Predmeti so povsod okoli nas: raunalnik, avto, miza itd. Stanje predmeta opisujemo s samostalnikom, obnašanje pa z glagoli. Resnini primeri so ponavadi dosti bolj zapleteni, zato tudi govorimo o njihovem poenostavljenem modelu, s katerim jih opisujemo v programskem jeziku. Stanje v programskem predmetu shranjuje ena ali ve spremenljivk. Spremenljivkam stanja pravimo tudi lastnosti (angleški izraz property) predmeta. Obnašanje programskega predmeta pa nadzirajo metode (angleški izraz methods). Predmeti se z zunanjim svetom sporazumevajo preko javnih metod in prav tako se lahko spremeni stanje preko klica ustrezne metode (Vir: Mesojedec, Fabjan, str ). Metoda je implementacija neke operacije. Informatik mora poznati nain klica operacije in njen rezultat, medtem ko mora nartovalec poznati zgradbo operacije. Vsak predmet mora imeti doloen svoj identifikator, s katerim ga loimo od ostalih predmetov. Kot identifikator velikokrat lahko uporabimo spremenljivko iz realnega sveta (na primer: davna številka državljana), v ostalih primerih pa je potrebno doloiti lastnost, ki bo enoznano doloala predmet. Pomembna prednost predmetov je v tem, da ni potrebno razumeti detajlov operacije, vendar je potrebno poznati le njihove lastnosti in dogodke, ki jih želimo uporabljati. (Vir: Reynolds, Blair, Crossland, Willis, 2002, str ). Vsak predmet ima osnovne metode in metode po meri. V prvo skupino uvršamo metode, ki dodajo nov predmet (konstruktor), vrnejo lastnosti predmeta, znajo spremeniti lastnosti predmeta in znajo izbrisati predmet (destruktor). Te metode se ujemajo z operacijami podatkovne zbirke dodaj, poizveduj, briši in spremeni. V slednjo skupino metod pa spadajo tiste, ki jih doloa uporabnik in so primerne samo za specifine primere. Pri analizi sistema zato pogosto ignoriramo standardne metode in jih dodamo kasneje pri programiranju. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 19

26 Razred Opis objekta imenujemo razred (angleški izraz class). Vsak objekt je primerek oz. predstavnik instance nekega razreda. Razred definira operacije, ki jih zagotavljajo objekti tega razreda, njihovo implementacijo ter podatkovne tipe, ki definirajo dovoljeno stanje, v katerem se objekt lahko nahaja. Razred je tako neke vrste obrazec, ki se uporablja za kreiranje objektov kot primerkov doloenega razreda. Vsak primerek vsebuje informacijo, ki ga louje od drugih primerkov (id_object). Kadar si objekti istega razreda delijo nek podatek oz. atribut tako po imenu kot po vrednosti, govorimo o razrednih spremenljivkah. Metode, ki dostopajo in operirajo le nad razrednimi spremenljivkami oz. atributi, imenujemo razredne metode. Kadar ena ali ve metod razreda nima doloene implementacije, imamo opraviti z abstraktnimi metodami; ta razred ne more imeti primerkov, ker ga imenujemo abstraktni razred. Razred, katerega predmeti so primerki, pa imenujemo metarazred. (Vir: Sili, Krisper, Rozman, 2000, str. 14). V programskem jeziku VB.NET abstraktni razred doloimo tako, da pred deklaracijo razreda napišemo besedo»mustinherit«, kot je razvidno iz spodnjega primera. Namespace WMSChart Friend MustInherit Class Element End Class End Namespace Vsi objekti se obnašajo enako, lahko pa se razlikujejo po trenutnem stanju. Glavna prednost pred strukturiranim programiranjem je v tem, da se izdelujejo izolirani gradniki programa, ki vsak zase deluje samostojno in neodvisno od drugih gradnikov. Posamezne celote so lažje obvladljive, kar omogoa razvoj zanesljivejših programov ter lažje iskanje napak. Lastnosti vsebujejo informacije o stanju in vrednosti, ki opisujejo predmet, medtem ko metode pojasnjujejo nain spreminjanja lastnosti predmeta in izvajanje operacij na njem (Vir: DePetrillo, 2002, str 66 67) Ograjevanje - enkapsulacija Tehniko, ki omogoa loevanje definicij od podrobnosti implementacije, imenujemo ograjevanje. Noben objekt ne more direktno brati oz. spreminjati lastnosti drugega objekta. Dostop do nekega dela stanja objekta je možen le preko operacij, razen v primeru, kadar objekt dovoljuje direkten dostop. Ta koncept skrivanja lastnosti vodi k nizki sklopljenosti med objekti. Ograjevanje namre omeji domene, o katerih mora uporabnik razmišljati. Zanj je pomembno, katere informacije so na razpolago in kakšne informacije priakujemo od Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 20

27 operacije. Med objektom in klicanim objektom je tako natanno doloena komunikacija in dialog med njima. Sposobnost objekta, da pred uporabniki skrije atribute in metode, se izkaže izredno koristna ob spremembah, saj omogoa boljši nadzor in omejevanje verižnih reakcij (Vir: Sili, Krisper, Rozman, 2000, str. 5-6) Dedovanje Dedovanje omogoa gradnjo novih na temelju že izdelanih razredov. Kadar naredimo nov razred z dedovanjem, znova uporabimo stanje in metode podedovanega razreda, ki jih lahko dopolnimo in spremenimo. Dedovanje tako omogoa ponovno uporabo kode, ki je že napisana in testirana. (Vir: Mesojedec, Fabjan, 2004, str. 147). Predhodniku v predmetnem izrazoslovju pravimo tudi nadrazred (angleški izraz superclass) ali starš (angleški izraz parent), potomcu pa izpeljani razred (angleški izraz derived class), podrazred (angleški izraz subclass) ali otrok (angleški izraz child). Temeljni nadrazred je od vseh ostalih izpeljanih razredov najmanj zmogljiv, saj vsi potomci podedujejo njegove sposobnosti, hkrati pa mu dodamo nove možnosti. Razredi objektov imajo pogosto podobne, a ne identine atribute in operacije. V teh primerih je smiselno uporabiti metode dedovanja lastnosti. Podrazredi podedujejo atribute in operacije nadrazreda. Seveda lahko podrazred predefinira poljubno metodo ali atribut, ki ga dobi od nadrazreda, definira pa lahko tudi nove atribute in operacije, ki pripadajo samo novemu razredu. Dedovanje zagotavlja mehanizem za upravljanje razredov in organiziranje razredne strukture, kjer so splošni razredi višje in specializirani nižje v hierarhiji. Enkratno dedovanje (angleški izraz single inheritance) zasledimo, kadar nek podrazred podeduje znailnosti le od enega neposrednega nadrazreda. Vekratno dedovanje (angleški izraz multiple inheritance) omogoa, da razred deduje od ve neposrednih nadrazredov. Visual Basic.NET omogoa le enkratno dedovanje, kar naredimo s pomojo ukaza»inherits«+ naziv nadrazreda. e želimo, da bo razred»action«dedoval lastnosti od razreda»element«, je potrebno napisati. Namespace WMSChart Friend Class Action Inherits WMSChart.Element End Class End Namespace Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 21

28 Koncept, podoben dedovanju je delegiranje (angleški izraz delegation). Osnovna razlika je v tem, da je dedovanje koncept, ki povezuje razrede, delegiranje pa vzpostavlja povezave med konkretnimi primerki, torej med objekti. Delegiranje je tako nekakšno dedovanje med objekti, pri tem pa velja delegacija za bolj fleksibilen pristop, ki za seboj potegne tudi nekatere negativne lastnosti v primerjavi z dedovanjem. (Vir: Sili, Krisper, Rozman, 2000, str. 6-7.) Dedovanje bi lahko formalno zapisali s pomojo enabe: R = P + R R oznauje nov objekt/razred P oznauje lastnosti, ki so podedovane iz obstojeega razreda/objekta R oznauje dodane nove lastnosti + oznauje operacijo, ki združuje lastnosti P in R (Vir: Mernik, Žumer, 2003, str. 162) Prenos sporoil Medsebojno usklajeno delovanje predmetov omogoajo sporoila, ki si jih predmeti izmenjujejo. Sporoilo v predmetnem programu je pravzaprav klic znane metode predmeta. Klic metode lahko vsebuje enega ali ve parametrov, ki podrobneje opišejo željo uporabnika predmeta (Vir: Mesojedec, Fabjan, 2004, str ). Sporoilo vsebuje ime, ki identificira objekt, ki mu je namenjeno in morebitne parametre. Osnovni namen komuniciranja s prenosom sporoil je torej proženje operacij nad ciljnim objektom. Rezultat operacije se izvornemu objektu vrne kot povratno sporoilo. Primer prenosa sporoil je ponazorjen z spodnjim ukazom. Kliemo metodo»senddocument«, ki vsebuje en parameter»item«. Call SendDocument (Item) Polimorfizem Polimorfizem oz. mnogolinost pomeni, da se lahko razlini razredi objektov odzivajo na isto sporoilo na razline naine. Pomeni tudi, da je ista operacija implementirana na ve razlinih nainov oz. zanjo obstaja ve metod. Loimo osnovne tri tipe polimorfizma: vkljuitveni polimorfizem je posledica tega, da lahko eno samo ime predstavlja objekte razlinih razredov, ki so povezani z nekim skupnim nadrazredom. Dedovanje je zato klju do te oblike polimorfizma; Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 22

29 operacijski polimorfizem je tip polimorfizma, kjer se z istim imenom sklicujemo na operacije, ki ne izkazujejo kakšne skupne povezave v smislu podrazredov oz. razredne hierarhije dedovanja; parameterski polimorfizem glavna znailnost je, da pri deklaraciji splošnega tipa ali razreda kot parametre uporabljamo tipe. (Vir: Sili, Krisper, Rozman, 2000, str. 7-8). S pomojo polimorfizma naredimo razred veliko bolj podoben naravnemu jeziku, saj lahko uporabimo enak naziv metode ali lastnosti, ki pri razlinih parametrih naredi razlino operacijo. Spodaj je predstavljen primer polimorfizma na metodi»delete«, ki izbriše zapis iz seznama. V prvem primeru parameter»index«predstavlja zaporedno številko elementa v seznamu, v drugem primeru parameter»id«predstavlja unikatno številko elementa v podatkovni zbirki, pri zadnjem primeru pa parameter»element«predstavlja grafini objekt na zaslonu. Public Function Delete(ByVal Index As Integer) As Boolean Public Function Delete(ByVal ID As Long) As Boolean Public Function Delete(ByVal Element As WMSElement.Element) As Boolean 2.5. Osnovni koncepti jezika za modeliranje UML Zgodovina UML V devetdesetih letih se je uporabljalo ve kot 50 programskih jezikov za modeliranje, pri emer je vsak podpiral svoja pravila. Vsaka notacija je imela specifine znailnosti, ki so metodo naredile drugano, hkrati pa je vsebovala številna pravila, ki so jih imele tudi druge metode. To je pripeljalo do precejšnje zmede na tem podroju in celo do t.i. metodološke vojne. Sredi devetdesetih so se nato v praksi obdržale tri najpomembnejše metode: Ivar Jacobson je razvil Object Oriented Software Engineering (OOSE) metodo kot poenostavljeno razliico Objectory v okviru razvoja velikega telekomunikacijskega sistema. Glavni poudarek je bil na diagramih primerov uporabe, ki predstavljajo pomembno orodje predstavitve obnašanja celotnega sistema ter so še danes eni pomembnejših diagramov; James Rumbaugh je razvil tehniko Object Modeling Technique (OMT), ki je najbolj primerna za analizo in obdelavo podatkov. V prvi zbirki so bili predstavljeni trije loeni diagrami (statini, kontrolni in diagram cenitev projekta), s katerimi pred implementacijo analiziramo problem. Najveja prednost teh metod je v povezavah med podrobnimi diagrami in kodiranjem; Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 23

30 Booch metod Grady Booch je dal najveji poudarek na design in implementacijo. Booch je bil eden od glavnih snovalcev implementacije objektno orientiranih metod pri jeziku Ada. Leta 1994 je prehod Jima Rumbaugha iz General Electrica k Grady Boochu v Rational Corporation presenetil celoten svet informatike. Glavni cilj združitve je bila povezava njunih idej v splošno metodo»unified Metod«, da bi tako dosegla standardizacijo v industriji. Leto kasneje se je pridružil še Ivar Jacobson ter dodal svoje ideje o diagramih uporabe primerov, notacijo pa so preimenovali v enotni oblikovalski jezik»unified Modeling Language«. Ekipo treh glavnih akterjev - Booch, Rumbaugh in Jacobson - so poimenovali»the three amigos«. Leta 1997 so preko organizacije Rational objavili prvo razliico UML 1.0. Septembra istega leta je jezik priznalo tudi podjetje Object Management Group, ki se ukvarja s standardizacijo in podporo pri objektnih tehnologijah v industriji. Nato so v naslednjih šestih letih izdali pet popravkov prve razliice in v letu 2003 tako izdali verzijo UML 1.5. Letu 2005 so izdali novo verzijo programa UML 2.0, ki je vsebovala precej posodobitev starih diagramov, hkrati pa so dodali asovni diagram, diagram pregleda delovanja, diagram strukture sestavljanja, diagram paketov ter delno spremenjen diagram komponent. Pri uvedbi nove razliice je bilo potrebno zagotoviti, da so spremembe na diagramih še vedno kompatibilne s starimi diagrami ter da jih tako lahko uporabljajo tudi stari razvijalci. Pri razvoju UML so imeli pomemben vpliv tudi številni drugi posamezniki, kot David Harel, ki je razvil diagram stanja; na nekatere spremembe (kot Object Constraint Language, ki ga je podpiral IBM) so vplivali tudi ostali lani skupine OMG (Vir: Filev, Loton, McNeish, Schoellmann, Slater, Chaur, 2003, str ). Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 24

31 Diagrami UML Na sliki 5 je predstavljena hierarhija diagramov UML. Diagram razredov Strukturni diagram Diagram strukture Diagram objektov Diagram komponent Diagram namestitve Diagram paketov Diagram Diagram aktivnosti Diagrami obnašanja Diagram primerov uporabe Diagram stanja Diagram zaporedja Slika 5: Klasifikacija diagramov UML (Vir: Fowler, 2004, str. 12). Diagrami sodelovanja Diagram sporoil Diagram pregleda delovanja asovni diagram Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 25

32 Diagrame UML v grobem delimo na strukturne diagrame in diagrame obnašanja. Med strukturne diagrame spadajo: diagram razredov predstavlja statino strukturo razredov in povezavo med njimi; diagram komponent predstavlja komponente raunalnika in povezave med njimi; diagram strukture sestavljanja omogoa hierarhino razdelitev razreda na ve ravni, kar dovoljuje razbitje kompleksnih objektov na bolj preproste elemente; diagram namestitve predstavlja fizino implementacijo rešitve s trenutno programsko in strojno opremo; diagram objektov predstavlja objekte in povezave med njimi. Od diagramov zaporedja se razlikuje po tem, da ne vsebuje sporoil in je zato nekoliko enostavnejši; diagram paketov prikazuje pakete in njihovo povezanost; Med diagrame obnašanja uvršamo: diagram aktivnosti uporablja se za modeliranje poteka poslovnih procesov in je podoben diagramu poteka. Od diagramov stanj se razlikujejo po tem, da je osredotoen na aktivnosti; diagram primerov uporabe predstavlja zahteve konnega uporabnika na visoki ravni in se ne spuša v tehnine podrobnosti; diagram stanja doloa notranja stanja objektov, pri emer vidimo življenjski cikel objekta in doloimo potrebne funkcionalnosti; diagram zaporedja predstavlja scenarij posamezne naloge v grafini obliki; diagram sodelovanja prikazuje objekte in povezave med njimi. Pri tem ne poudarja asovne komponente, ampak prikazuje zaporedje sporoil v interakciji; diagram sporoil povezovalni diagram s poudarkom na podatkih, ki se v okviru interakcije prenašajo med razlinimi udeleženci; diagram pregleda delovanja združuje diagram aktivnosti in diagram zaporedij. Predstavlja diagram aktivnosti, pri katerem so te nadomešene z majhnimi diagrami zaporedja ali kot diagrami zaporedja, ki vsebujejo lastnosti diagramov aktivnosti; asovni diagram predstavlja povezavo med objekti s poudarkom na asovni omejenosti. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 26

33 Diagrami obnašanja Diagrami primerov uporabe (Use Case Diagram) Diagrami primerov predstavljajo povezavo med akterji, uporabniki sistema in procesi v sistemu. Uporabljajo se predvsem za zajem in analizo zahtev konnih uporabnikov na splošni ravni in ne tehninih zahtev, se pravi z vidika kot ga vidi konni uporabnik. Prav dober konceptualni design pa je kljuen za uspešen zakljuek projekta. Diagram primerov uporabe se uporablja v vseh fazah razvoja, saj služi kot osnova pri definiranju funkcionalnih zahtev, identificiranju in doloanju funkcionalnosti poslovnih objektov, doloanju interakcij med objekti, nartovanju uporabniških vmesnikov, izvajanju integracijskega testiranja in definiranju testnih primerov (Vir: Sili, Krisper, Rozman, 2000, str ). Diagram primerov ima naslednje znailnosti: Akter nekdo ali nekaj, kar se povezuje s sistemom prek sprejemanja ali pošiljanja informacij. Relacija se uporablja za doloitev povezave med akterjem in ostalimi elementi. Povezava obstaja, ko je akter vkljuen v izvedbo diagrama primera. Smer povezave doloimo s pomojo pušice, ki gre od zaetnega izvajalca do primera uporabe. UML pozna tri vrste relacij: povezovalna relacija je povezava med akterjem in diagramom primera. Akter lahko informacijo pošlje procesu ali pa jo prejme. Druga oblika je relacija <<uporablja>>, ki za svoje delovanje uporablja funkcionalnosti drugega primera uporabe. Uporablja se takrat, ko imata enako funkcionalnost dva ali ve primerov uporabe. Zadnja oblika je <<razširjena>> relacija, ki lahko ob izpolnitvi doloenih pogojev uporablja funkcionalnost drugega primera uporabe. Relacijo je možno postaviti med dva diagrama primera ali med dva akterja. Takšen tip relacije se uporablja tudi pri generalizaciji akterjev. Proces Za popolno doloitev diagrama primera je potrebno doloiti proces glavni tok, predpogoje in pogoje, ki bodo izpolnjeni po zakljuku procesa. Korake je potrebno napisati v kronološkem zaporedju izvajanja. Paket paketi prek združevanja razlinih primerov uporabe v skupine omogoajo vejo preglednost UML modela. Meja sistema doloa podroje vseh primerov uporabe, ki predstavljajo neko celoto znotraj sistema. Podroben opis primera uporabe predstavimo z zapisom tonega poteka izvedbe v kronološkem zaporedju, pri emer je potrebno doloiti zaetno stanje (pogoj, da se primer uporabe zane). Do konnega stanja pridemo ob zakljuku primera uporabe, osnovni potek pa opredeljuje korake, potrebne, da se proces zakljui. V primeru izjem doloimo pomožni proces, ki opisuje kronološki potek posebnosti. V literaturi se pri podrobnem opisu primerov Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 27

34 uporabe uporabljajo razlini kriteriji, predvsem je odvisno kako detajlno želimo opisati potek primera uporabe. Naziv: Razporejanje uporabnika Opis: Razvršanje zaposlenih v ekipe in doloanje vloge v ekipi. Zaetno stanje: Administrator ima pravico razporejanja uporabnikov. Konno stanje: Zaposlen je lan ekipe in ima doloeno vlogo v njej. Osnovni potek: 1. administrator želi zaposlenemu doloiti ekipo in vlogo; 2. administrator odpre okno za administracijo ekip zaposlenih in vlog; 3. sistem administratorju prikaže seznam vseh zaposlenih; 4. administrator oznai zaposlenega; 5. sistem izpiše za zaposlenega vse ekipe, katerim ta pripada; 6. administrator zahteva vnos nove ekipe; 7. sistem izpiše seznam vseh ekip; 8. administrator izbere novo ekipo in potrdi odloitev; 9. sistem izpiše seznam vseh vlog; 10. administrator izbere novo vlogo, ki jo ima zaposlen v ekipi; 11. administrator potrdi odloitev; 12. sistem shrani podatke v podatkovno bazo; 13. sistem opozori administratorja, da so podatki shranjeni. Pomožni tok: Naziv ekipe ni shranjen v bazi. A.8. Administrator odpre okno za vnos podatkov o ekipah; A.9. administrator vnese naziv in opis ekipe; A.10. sistem preveri, da ne gre za podvajanje podatkov o ekipah; A.11. sistem preveri, da so vneseni vsi zahtevani podatki; A.12. sistem shrani novo ekipo v podatkovno zbirko; A.13. sistem opozori administratorja, da so spremembe shranjene. Pomožni tok: Vloga še ni doloena. B.10. Administrator odpre okno za administracijo vlog. B.11. administrator vnese naziv in opis vloge; B.12. sistem preveri, da ne gre za podvajanje vloge; B.13. sistem preveri ali so vnesen vsi zahtevani atributi; B.14. sistem shrani vlogo v podatkovno zbirko; B.15. sistem opozori administratorja, da so spremembe shranjene. Na sliki 6 je grafino prikazan primer uporabe za pregled poštnega predala. Ko uporabnik odpre okno poštni predal, to predstavlja primer uporabe»izpis poštnega predala«, ki izpiše dokumente, ki ustrezajo privzetim nastavitvam iskanja. Uporabnik ima možnost preko nastavitve razlinih kriterijev doloiti svoje kriterije iskanja in se zgodi primer uporabe»nastavi iskalne kriterije«in nato sproži izpis dokumentov v poštni predal. V primeru, da je uporabnik dobil dokument v obdelavo, ta lahko opravljen proces dokumenta prekine, tako da Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 28

35 se zgodi primer uporabe»prekini proces dokumentu«oz. pošlje dokument v naslednjo fazo obdelave preko primera uporabe»pošlji dokument«. Ko uporabnik pošlje dokument v naslednjo aktivnost se vedno zgodi primer uporabe»pošlji opozorilo o zastoju«, ki preveri ali se v naslednji aktivnosti kopiijo neobdelani dokumenti in obvesti lastnika procesa o zastoju. Pred pošiljanjem dokumenta pa ima uporabnik možnost pregledati že opravljeno pot izbranega dokumenta in se zgodi primer uporabe»prikaži opravljen proces«. Slika 6: Diagram primerov uporabe poštnega predala Diagram stanja (State Machine Diagram) Diagram stanja spada med diagrame obnašanja. Uporabljamo ga takrat, ko želimo prikazati stanja, v katera lahko prehaja objekt oz. sistem. Ta diagram se najvekrat uporablja v razvoju programske ali strojne opreme, kjer je stanje obravnavanega objekta kljunega pomena in ga ne moremo predstaviti s pomojo razrednega diagrama. Vsak diagram stanja ima doloeno eno zaetno stanje ter ve ali ni konnih stanj. Najpomembnejši element je stanje, ki predstavlja doloen položaj objekta v dolonem trenutku. Stanje ima lahko pasivno vrednost (prižgan, ugasnjen), ali pa predstavlja trenutno aktivnost sistema (pripravljati, istiti). Prehod oznauje menjavo med enim in drugim stanjem. Vsakemu prehodu doloimo dogodek, ki je povzroil prehod med stanji, trenutno stanje v katerem je objekt ter aktivnost, ki se zgodi med prehodom. Smer menjave stanja je doloena s pušico. Diagram stanja temelji na treh elementih: Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 29

36 stanje: je situacija, v katero lahko preide objekt. Diagram stanj ima vedno eno zaetno stanje in enega ali ve konnih stanj; prehod: doloa dogodek, s katerim objekt preide iz enega v drugo stanje; odloitev: se uporablja, ko ima objekt možnost preiti iz trenutnega stanja v razlina stanja odvisno od odloitve. Slika 7: Predstavitev stanja zapisa iz podatkovne zbirke, e je zapis predhodno že shranjen v podatkovni zbirki. Diagram pregleda delovanja (Interaction Overview Diagram) Diagram pregleda delovanja je diagram, ki je bil naknadno dodan verziji UML 2.0. S pomojo diagrama pregleda delovanja dobimo vejo sliko celotnega procesa oz. delovanja sistema. Diagram je sestavljen iz diagrama zaporedja, diagrama sodelovanja in asovnega diagrama z glavnim poudarkom na pošiljanju sporoil, ki pomenijo medsebojno povezovanje. Ta diagram si lahko predstavljamo tudi kot diagram aktivnosti, pri emer so aktivnosti zamenjane s posameznimi diagrami. Glavni namen uporabe takšnih diagramov je: prikazati potek kontrole znotraj poslovnih procesov; prikazati podrobno logiko programskih procesov in povezati razline diagrame skupaj. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 30

37 Diagram sodelovanja (Collaboration - Communication Diagram) Diagram sodelovanja opisuje povezovanje med objekti, pri emer povezave niso asovno podrejene. Predstavijo enake podatke kot diagram zaporedja, pri emer so povezave med objekti oštevilene po vrstnem redu kot se izvajajo. Njihova glavna prednost je v tem, da na skici ne potrebujemo toliko povezav med objekti, medtem ko na drugi strani ob prevelikem številu sporoil izgubimo preglednost nad tokom izvajanja. Diagrami sodelovanja so sestavljenih iz štirih glavnih elementov: akter predstavlja osebo, sistem ali organizacijo, ki ima interakcijo s sistemom; razred grafina oznaka razreda se razlikuje glede na njihov pomen (domenski razred, razred uporabniških vmesnikov in kontrolni razred, ki združuje logiko ve domenskih razredov); povezava je grafino predstavljena kot rta, ki povezuje dva elementa; sporoilo je metoda ali dogodek, ki se sproži pri prenosu sporoila med elementi. Vsako sporoilo ima s pušico doloeno smer prenosa in zaporedno številko. Slika 8: Diagram sodelovanja za vnos nove skupine dokumentov Diagram zaporedja (Sequence Diagram) Diagram zaporedja ali sekvenni diagram se uporablja za dokumentacijo enega scenarija diagrama primerov uporabe v obliki grafa. Obiajno doloa število objektov, ki sodelujejo v diagramu primerov in prikaže sporoila, ki se pošiljajo med objekti. Koraki v Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 31

38 scenariju so doloeni v kronološkem zaporedju, pri emer ima vsak korak za lažjo predstavitev poteka doloeno zaporedno številko. Slika 9: Diagram zaporedja za shranjevanje ekipe uporabniku Diagrami zaporedja so sestavljeni iz naslednjih elementov: objekt predstavlja vsak element znotraj rešitve (oseba ali stvar); dejanje je dogodek, ki sproži posamezen korak. Dogodek lahko povzroi oseba, zunanji sistem, signal, doloena ura v dnevu; sporoilo je ukaz, ki se pošilja med objekti in lahko vsebuje enega ali ve parametrov. Glede na uinek parametrov sporoila razdelimo v štiri skupine; opomba k vsakemu elementu lahko dodamo kratko pojasnilo. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 32

39 Diagram aktivnosti (Activity Diagram) Diagram aktivnosti grafino prikazuje, kako bo sistem dosegel konni cilj, podan v diagramu primerov uporabe. Najpogosteje se uporablja za modeliranje poslovnih procesov ali proceduralne logike. Za oba podroja je znailno, da nas doloeni zaporedni koraki pripeljejo do zastavljenega cilja. Diagram aktivnosti uporablja enake elemente kot diagram poteka, zato je lažje razumljiv najširšemu krogu ljudi. Diagram aktivnosti je sestavljen iz naslednjih elementov: aktivnost je osnovni proces, ki ga mora izvesti akter. Vsaka aktivnost mora imeti natanko en vhod in izhod; prehod s pušico ponazorjen tok prehoda od enega do drugega elementa; stanje lastnost objekta, ki se preko aktivnosti spreminja; odloitev se uporablja, ko iz posamezne aktivnosti izhaja ve prehodov. Odloitev se zakljui tako, da se prehodi ponovno združijo v spojni element in nato v naslednjo aktivnost. Slika 10: Diagram aktivnosti za vnos nove vloge uporabnika Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 33

40 asovni diagram (Timing Diagram) asovni diagrami so se sprva pojavili v elektroinženirstvu in so bili dodani šele v drugo razliico diagramov UML. Po imenu bi sklepali, da je diagram asovno orientiran, vendar gre za postavitev diagrama zaporedja in diagrama sodelovanja v asovni okvir. Uporablja se, kadar želimo za posamezen objekt ali skupino objektov prikazati asovno povezanost med spreminjanji stanj razlinih objektov. Z doloitvijo trajanja dogodka ugotovimo, koliko asa pretee med klicanjem doloenega dogodka ter kako dolgo bo prejemnik v posameznem stanju. Pomembni elementi diagram so: udeleženec - predstavlja razred ali akterja, ki sodeluje v procesu; stanje - vsak objekt gre skozi razlina stanja, ki se spreminjajo, ko prejmemo oz. pošljemo sporoilo; as - as je na diagramu na spodnji osi in tee od leve proti desni. asovni interval je lahko predstavljen relativno ali absolutno v doloeni asovni enoti. Slika 11: Postopek pošiljanja dokumenta, predstavljen s pomojo asovnega diagrama Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 34

41 Strukturni diagrami Razredni diagram (Class diagram) Razredni diagram je eden pomembnejših ter najvekrat uporabljeni diagram, saj z njim ponazorimo statino strukturo rešitve v povezavi z razredi in objekti na najnižji ravni. Na njem doloimo nain implementacije in povezave med razlinimi razredi. Tudi programerji uporabijo ta diagram kot glavni vir za razvoj rešitve, saj vsebuje vse atribute, podatkovne tipe, parametre, imenske prostore in metode. Diagrami lahko predstavljajo: domenski koncept problema; konceptualni model in podroben design objektov, ki se uporabljajo pri programiranju. Za diagram razredov se uporabljajo naslednji elementi: razred - je opis skupine objektov, ki imajo skupno obnašanje in lastnosti; lastnost - predstavlja strukturirane znailnosti razreda; operacija - predstavlja nalogo, ki jo objekt izvede, da spremeni obnašanje; vidnost - predstavlja dostop do lastnosti oz. metod razreda. Nekatere lastnosti bodo tako zasebne (uporablja jih lahko samo razred), druge pa javne (uporabljajo jih lahko vsi). Z doloanjem zasebnih metod in lastnosti naredimo razred bolj enostaven za konnega uporabnika; povezava - je razmerje med razredi ter predstavlja ogrodje za izdelavo strukture novega sistema. V praksi se uporabljajo razline povezave, ki se razlikujejo po moi odvisnosti med razredi. Šibka povezava med razredi Mona povezava med razredi Odvisnost Povezava Agregacija Kompozicija Dedovanje rtkana pušica Povezovalna rta Pušica s praznimi diamantom Pušica s polnim diamantom Prazna pušica Slika 12: UML omogoa pet razlinih tipov povezav med razredi (Vir: Miles, Hamilton, 2006, str. 84). Odvisnost med dvema razredoma pomeni, da mora prvi razred poznati lastnosti drugega razred do take mere, da lahko uporablja objekte tega razreda. e uporabniški vmesnik uporablja razred A, je potrebno narisati rtkano rto. V praksi se to najvekrat uporablja v primeru razreda, ki vsebuje vrsto splošnih funkcij. Povezava dovoli, da prvi razred uporablja objekte drugega razreda. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 35

42 Agregacija je monejša oblika povezave, ki omogoa, da ima razred v lasti drug objekt in ga lahko deli naprej. Kompozicija se uporablja, kadar povezava med objekti pomeni fizino združljivost in je življenjska doba objektov enaka. Dedovanje predstavlja najmonejšo obliko povezave, pri emer podrejeni razred deduje vse lastnosti in metode nadrejenega razreda. S pomojo dedovanja se kompleksne sisteme poenostavi, saj enake dele kode ponovno uporabimo. (Vir: Miles, Hamilton, 2006, str ). Slika 13: Razredni diagram aktivnosti v povezavi s seznamom aktivnosti Diagram strukture sestavljanja (Composite Structure Diagram) Vasih z razrednim diagramom ali diagramom zaporedja ni mogoe opisati vseh znailnosti, zato je primernejši diagram strukture sestavljanja. Ta ponazori, kako objekti kreirajo skupno sliko oz. kako objekti delujejo skupaj znotraj razreda ali kako objekti dosežejo cilj. Diagram spada med bolj zahtevne diagrame in je bil dodan šele k UML 2.0 razliici. Diagram strukture sestavljanja se uporabljajo za: risanje notranje strukture elementov (razredov, komponent ali primerov uporabe) in tok preko katerih se ti elementi povezujejo z zunanjimi sistemi; raziskave, kako zbirke instanc sodelujejo pri doseganju doloenih nalog ter za opis modela ali arhitekture doloenega vzorca oz. strategije. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 36

43 Diagram komponent (Component diagram) Namen diagrama komponent je prikazati implementacijo naše rešitve. Komponente so sestavljene iz poljubnega števila razredov, ki so vkljueni v aplikacijo. Pred implementacijo razredov je za vsakega potrebno doloiti, v kateri datoteki bo fizino implementiran. Osnovni elementi diagramov komponent so: komponenta - predstavlja vrsto programske opreme, kot npr. modul, dinamina knjižnica (dll), program (exe), datoteka itd.; vozel - doloa fizien vir procesiranja - obiajno predstavlja strežnik, na katerem tee program; odvisnost - predstavlja zvezo med funkcionalnostjo enega in drugega elementa; mejna povezava - javna funkcija modula, s katero se povezujejo druge komponente. Najpomembnejše so pri uporabi knjižnic, ki jih nismo razvijali sami, saj prek njih ugotovimo, kako se bodo komponente povezale. Slika 14: Modul za obvladovanje poslovnih procesov z vidika diagrama komponent Diagram paketov (Package diagram) Izgradnja velikih in kompleksnih sistemov pogosto zahteva izdelavo velikega števila (tudi do sto) razlinih razredov, kar bistveno zmanjša preglednost projekta in povzroa programerjem težave pri iskanju relevantnega razreda. Da se temu izognemo, razrede (elemente, ki podpirajo podobne lastnosti) združimo v paket. Programski jezik VB.NET Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 37

44 namesto paketov uporablja imenski prostor 10. Namenski prostor je po naravi hierarhien, kar pomeni, da lahko en imenski prostor vsebuje druge imenske prostore, ki spet združujejo razrede. Tako vsak razred pripada vsaj enemu imenskemu prostoru (Vir: Reynolds, Blair, Crossland, Willis, 2002, str. 184). Razredi znotraj enega imenskega prostora morajo biti unikatni, lahko pa se ime razreda podvoji v razlinih imenskih prostorih. S pomojo diagramov paketov grafino ponazorimo razmerje med paketi oz. imenskimi prostori. Slika 15: Modul za obvladovanja poslovnih procesov v obliki diagrama paketov Diagram namestitve (Deployment diagram) Namestitveni diagram prikazuje fizini izraz novega sistema ob prenosu v realni svet. S pomojo tega diagrama naredimo nadaljnji korak pri opisu rešitve in prikažemo strukturo strojne in programske opreme ter ponazorimo medsebojno sodelovanje komponent programske opreme v realnem asu. Vsak UML model bi moral imeti samo en takšen diagram za opis naina delovanja rešitve v zagonu. Diagram je predstavljen z naslednjimi elementi: vozel - predstavlja strojno ali programsko opremo, ki je primerna za izvajanje programske kode; izdelek - je fizina datoteka, ki se uporablja v rešitvi ali izvede doloeno nalogo; 10 Imenski prostor je logina zbirka razredov (class-es), delegatov (delegates), struktur (structures), vmesnikov (interfaces), ki so smiselno in hierarhino urejeni (Vir: datum vpogleda ). Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 38

45 komponenta - doloa raunalnike, na katerih se rešitev izvaja; povezava - poznamo dve osnovni povezavi - sporoilno povezavo, ki doloa sporazumevanje dveh elementov med seboj in odvisnostno povezavo, ki doloa skladnost dveh elementov. Slika 16: Razvojni diagram za modul obvladovanja poslovnih procesov Diagram objektov (Object Diagram) Diagram objektov predstavlja trenutni posnetek objektov v sistemu v doloeni asovni toki. Za razliko od razrednega diagrama so elementi diagrama instance razredov in ne razredi. Zato jih imenujemo tudi diagrami instance (Vir: Fowler, 2004, str. 87). Uporabljamo jih pri bolj zapletenih sistemih, ko želimo prikazati tono doloen primer objektov v praksi. Slika 17: Diagram objektov procesa, ki vsebuje enega lastnika in eno aktivnost Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 39

46 3. ISO standardi Pri svojem poslovanju uporabljajo organizacije številne interne oz. splošno sprejete standarde, s katerimi želijo opisati oz. dokumentirati svoje poslovanje. Standard ne sme biti sam sebi namen in tako kot le papir ne more zagotavljati poveanja kakovosti. Pridobljeni certifikat organizacijam kakovosti ne zagotavlja, da bo sistem deloval uinkovito, niti ne, da bo organizacija uspešna. Za uspešno vpeljavo standardov je potrebna podpora celotne organizacije. Vodstvo organizacije mora pridobiti osnovno znanje o novih nainih vodenja kakovosti in o modelih kakovosti, doloiti politiko kakovosti in postaviti cilje organizacije na podroju kakovosti ter zavzeti jasno stališe glede uvedbe sistema kakovosti. Notranja ureditev poslovanja tako vpliva na celotno organizacijo, pri emer se pogosto izboljša notranja komunikacija, dodeli se pristojnosti in odgovornosti. Vpeljava novih standardov v organizacijo lahko pomeni precejšnje spremembe. Na eni strani se doloi nain poslovanja, kar pospeši razvoj sistematizacije delovnih mest in omogoi lažji nadzor ter njihovo spreminjanje v želeno smer, na drugi pa pomeni celo vrsto dodatnih opravil, ki prej niso bila potrebna. Glavna razlika med standardom ISO 9000 in ostalimi standardi je v tem, da gre za standard upravljanja in ne standard izdelkov ter je tudi obsežnejši. Standardi ISO so danes eni najbolj razširjenih mednarodnih standardov in kot takšni sledijo sodobnim trendom na podroju vodenja kakovosti. ISO 11 je mednarodna organizacija za standardizacijo, ki prostovoljno razvija tehnine standarde za vse tipe poslovnih operacij. ISO je mreža nacionalnih institucij za standardizacijo v 147 državah s centralnim sekretariatom v Ženevi, ki koordinira sistem. Standarde razvijajo glede na potrebe tržiša. Delo opravljajo eksperti, ki izhajajo iz industrijskega, poslovnega in tehninega sektorja, ki sami povprašujejo po standardih in jih redno uporabljajo. Ti eksperti sodelujejo še z drugimi znanstveniki, vladnimi organizacijami, izobraževalnimi ustanovami in testnimi laboratoriji. (Vir: vpogled: ) Zgodovina V drugi svetovni vojni so eksplozije bomb v britanskih tovarnah z razstrelivom povzroile veliko število nesre, zato je ministrstvo za obrambo vpeljalo nadzornike za pregled postopkov. Da je podjetje ministrstvu še vedno lahko dobavljalo blago, je moralo zapisati postopek izdelave proizvodov. Nadzornik, postavljen s strani ministrstva, pa je ta postopek spremljal in zagotavljal njegovo upoštevanje. 11 ISO ang. International Organization for Standardization. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 40

47 Hiter tehnološki razvoj je v podobne težave pahnil tudi jedrsko industrijo in industrijo za pridobivanje elektrine energije ob tehnoloških prednostih so bili izdelki narejeni prehitro, da bi lahko nadzirali njihove lastnosti. Vodstvo se je pogosto odloalo na podlagi teoretinih podatkov, namesto da bi razumeli in se poglobili v postopek proizvodnje. Leta 1959 so Združene države Amerike (v nadaljevanju ZDA) razvile standard»quality Program Requirements«, MIL-Q-9858a, ki je vseboval standarde za vojaško preskrbovanje in je poudarjal pomembnost prilagodljivosti dobavitelja. Leta 1962 je NASA 12 izdala podoben standard za njihove dobavitelje, šest let kasneje pa je NATO 13 privzel standarde»allied Quality Assurance Procedures«, ki so doloali lastnosti njihove preskrbe. Ideja o zagotavljanju kakovosti se je razširila tudi prek vojaških organizacij. Leta 1966 je britanska vlada vodila svojo prvo nacionalno kampanjo kvalitete in zanesljivosti s sloganom»kvaliteta je posel vsakogar«. Leta 1969 sta britansko podjetje Central Electricity Generating Board in kanadski Ontario Hydrov razvila standard za zašito kvalitete za dobavitelje. V tem asu so bili dobavitelji kontrolirani s strani številnih strank in splošno mnenje je bilo, da gre za v veini primerov za potrato asa in energije. Leta 1969 je angleška komisija priporoila, naj bodo metode dobavitelja bolj cenjene kot splošen standard zagotavljanja kvalitete. Leta 1971 je podjetje British Standard Institute (v nadaljevanju BSI) prvo v Veliki Britaniji izdala standarde za zagotavljanje kakovosti»bs 9000«, ki so bili namenjeni tehnini industriji. Tri leta kasneje so objavili standard»bs 5179 Guidelines for Quality Assurance«. oseba. S tem je breme nadzora od stranke prešlo na dobavitelja, ki ga je nadzorovala tretja Sredi sedemdesetih je BSI organizirala sreanja s proizvajalci, da bi doloili splošne standarde. Tako so leta 1979 izdali standard»bs 5750«, ki je predstavljal prvi veljavni državni standard na podroju sistemov kakovosti v svetu. Velika veina organizacij je tako zavrgla svoje dosedanje standarde in zaelo uporabljati nove. Namen teh standardov je bil preskrbeti splošne pogodbene dokumente. Zagovarjali so tezo, da bodo imeli tako nadzor nad industrijo. Eno od nael ISO standardov je bilo tudi to, da se bodo standardi pregledali in dopolnjevali vsaj vsakih pet let. Tako so nastale naslednje razliice standardov: prva verzija ISO 9000: 1987, originalno izdana kot»bs 5750«, je bila osredotoena na nadzor kvalitete preko povratnih preverjanj in posledinih akcij popravljanja. Zelo velik vpliv so imeli standardi Ameriškega obrambnega 12 NASA National Aeronautics and Space Administration. 13 NATO North Atlantic Territory Organization. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 41

48 ministrstva»milspecs«, zaradi esar je bil standard najbolj primeren za organizacije, ki so imele stroge, nespremenljive, proizvodno delavniške procese. Verzija ISO 9000:1994 je poudarjala zagotavljanje kakovosti preko preventivnih akcij in potrebnih dokazov, ki so predpisani z dokumentiranimi procedurami. Na žalost so se organizacije nagibale k vpeljavi svojih zahtev preko rono napisanih procedur, s imer so podlegli bremenu ISO birokracije. Prilagoditveni in izboljševalni procesi bi bili lahko zelo razlini v takšnem okolju. ISO 9000:2000 je predstavil koncept procesne uinkovitosti preko procesnega pristopa metrike in tako zmanjšal poudarek na dokumentiranih procesih v primerih, kjer že preprost dokaz izraža dejstvo, da procesi delujejo uspešno. Izboljševanje procesov je aktivnost, ki poskuša dvigniti uinek procesa, zlasti na poslovnih procesih z orientacijo na postavljen cilj. Pri projektu izboljšave lahko uporabimo model, ki ga predpisuje proces izboljšave. (Vir: vpogled: ) Splošno o standardu ISO 9001:2000 Standard ISO 9001:2000 temelji na odnosu odjemalec organizacija oz. kupec prodajalec. Standard doloa zahteve za vse tiste aktivnosti, ki jih mora organizacija izvajati, da bi zanesljivo izpolnila potrebe in zahteve odjemalcev za proizvod oz. storitev. Pri tem je glavni cilj izboljšanje zadovoljstva odjemalcev z uinkovito uporabo sistema vodenja kakovosti. Standard podpira novo poslovno razmišljanje, ki temelji na vodljivosti sistema in uporabi naela»nartuj izvedi preveri izboljšaj«ter procesnega pristopa. Slika 18: Demingov krog stalnih izboljšav»nartuj izvedi preveri izboljšaj«(vir: Plos, Kaj nam prinaša novi standard ISO 9001:2000, str. 5). Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 42

49 Novembra 2000 je bila izdana prenovljena tretja razliica standarda ISO 9001, ki združuje naslednje standarde: SIST ISO 9001:2000 Sistemi vodenja kakovosti: SIST ISO 9000:2002 Sistemi vodenja kakovosti; SIST ISO 9004:2002 Sistemi vodenja kakovosti. (Vir: vpogled: ) Procesni pristop Novi standardi ISO 9000:2000 se zavzemajo za prevzem procesnega pristopa pri razvijanju, uvajanju in izboljševanju sistema vodenja kakovosti. Za izboljšanje delovanja in uinkovitosti je potrebno doloiti številne aktivnosti. Vse aktivnosti, ki so potrebne za pretvorbo vhodnih elementov v izhodni produkt, lahko obravnavamo kot proces. Najvekrat v praksi izhod enega procesa pomeni vhod v naslednji proces. Uporabo sistema procesov znotraj organizacije, ki vkljuujejo lastnosti in medsebojno odvisnost lahko imenujemo procesni pristop. V ISO standardih zasledimo definicijo»procesa«kot skupek med seboj povezanih ali vzajemno vplivajoih aktivnosti, ki pretvarjajo vhode v izhode. Vhodi in izhodi so lahko otipljivi ali neotipljivi. Primeri vhodov in izhodov lahko poleg drugega vkljuujejo opremo, materiale, komponente, energijo, informacije in finanne vire. Za izvedbo aktivnosti znotraj procesa morajo biti razporejeni primerni viri. Za zbiranje informacij in podatkov za analizo delovanja procesa ter vhodnih in izhodnih karakteristik se lahko uporabi sistem meritev (Vir: Slovenski inštitut za standardizacijo, 2003). Glavna prednost procesnega pristopa je vsekakor nenehni nadzor nad povezavami med posameznimi procesi, kot tudi nad njihovimi kombinacijami in medsebojnimi vplivi. Slika 19 prikazuje model sistema vodenja kakovosti, ki je osnovan na procesih. Prikazana je pomembnost odjemaleve vloge pri doloanju vhodnih zahtev. Stalno spremljanje zadovoljstva odjemalca zahteva ocenjevanje njegovega zaznavanja ali je organizacija izpolnila njegove zahteve. Model, prikazan na sliki 19, pokriva vse zahteve tega mednarodnega standarda, vendar ne prikazuje procesov podrobneje. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 43

50 O D J E M A L E C Z A H T E V E Vodenje virov vhod NENEHNO IZBOLJŠEVANJE SISTEMA VODENJA Odgovornost vodstva Realizacija proizvodnje / storitev Merjenje analize izboljšave izhod Proizvod Z A D O V O L J S T V O O D J E M A L E C Aktivnosti, ki dodajajo vrednosti Tok informacij Slika 19: Model sistema vodenja kakovosti, osnovan na procesih (Vir: Slovenski inštitut za standardizacijo, 2003, str. 3). Naslednji pomemben princip vodenja kakovosti je sistemski pristop pri vodenju, ki pravi, da»identificiranje, razumevanje in vodenje medsebojno povezanih procesov kot sistema prispeva k uinkovitosti in uspešnosti organizacije pri doseganju njenih ciljev«. Pri tem sistem kakovosti obsega ve medsebojno povezanih procesov. Procesi za vodenje kakovosti poleg osnovnih procesov vsebujejo tudi številne procese vodenja, spremljanja in merjenja, kot so vodenje virov, komuniciranje, notranje presoje, vodstveni pregled in drugi procesi. Pri celotnem procesu pa zelo pomembno vlogo igra odjemaleva povratna informacija glede zadovoljstva ali nezadovoljstva s procesnim izhodom. Ravno ta informacija je bistvena za nenehno izboljševanje sistema vodenja kakovosti. ISO standardi ne predpisujejo procesov, ki morajo biti dokumentirani. Vsaka organizacija mora sama doloiti, kateri procesi bodo dokumentirani, in sicer na podlagi njenih odjemalcev in ustrezne regulative ali zakonskih zahtev, narave njenih aktivnosti in njene celotne strategije. Kjer je ugotovljena nujnost dokumentiranih procesov, je lahko uporabljenih ve metod, kot so grafine predstavitve, napisana navodila, kontrolni seznami, diagrami pretoka, vizualni mediji ali elektronska oblika. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 44

51 Vsak proces je opisan s štirimi glavnimi atributi in sicer: med splošne podatke navedemo naziv procesa, domicilno organizacijsko enoto, kateremu procesu pripada, morebitne druge sodelujoe organizacijske enote, status procesa in reference, kje je obravnavan proces zajet v drugih informacijsko aplikativnih sistemih; v kratek opis procesa podamo v tekstovni obliki opis procesa, pri emer je v tekstu smiselno oznaiti kdo (odgovorno mesto) je za posamezno aktivnost v okviru procesa zadolžen in kateri dokumenti v procesu ali po procesu nastopajo; delovni tok procesa vsebuje grafini prikaz v obliki diagrama poteka. Diagram poteka procesa je opisan z razlinimi tehnikami, za opis posameznih aktivnosti pa uporabljamo standardizirane znake. Praviloma naj bi bili vsi procesi postopkovne narave opisani z enakim naborom znakov; matrika odgovornosti je opcijska, opredeljuje pa vloge pri posameznih aktivnostih v procesu, dokumente, ki vstopajo in izstopajo iz procesa, dokumente, ki nastopajo pri aktivnostih ter odgovornosti Zahteve za dokumentacijo Pomembna sprememba standarda ISO 9001:2000 v primerjavi z prejšnji razliicami je v tem, da so zmanjšali minimalne zahteve za vodenje dokumentacije. Organizacijam tako dopušajo vejo fleksibilnost, saj lahko same doloajo minimalno koliino dokumentacije, s katero bodo izkazovale uinkovito planiranje, delovanje in obvladovanje procesov ter izvajanje in nenehno izboljševanje uinkovitosti svojega sistema vodenja kakovosti. Dokumentacija je lahko shranjena na kateremkoli mediju (papir, magnetni trak, elektronski ali optini raunalniški disk, fotografija, vzorni primerek) oz. katerikoli obliki. ISO 9001:2000 od organizacij izrecno zahteva, da dokumentirajo postopke za naslednjih šest aktivnosti: obvladovanje dokumentov; obvladovanje zapisov; notranja presoja Organizacija mora izvajati notranjo presojo v doloenih intervalih, saj s tem ugotovi ali sistem vodenja kakovosti ustreza nartovanim dogovorom, zahtevam mednarodnega standarda in zahtevam za sistem vodenja kakovosti, ki jih postavi organizacija. e nartovani rezultati niso doseženi, je treba izvesti ustrezne korekcije in korektivne ukrepe, da bi zagotovili skladnost proizvoda; obvladovanje neskladnih proizvodov; korektivni ukrepi in preventivni ukrepi. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 45

52 Dokumente, ki jih zahteva sistem vodenja kakovosti, je treba obvladovati. Zapisi so posebna vrsta dokumentov in jih je treba obvladovati v skladu z zahtevami. Vzpostaviti je treba dokumentiran postopek, ki opredeljuje potreben nain obvladovanja za: odobritev primernosti dokumentov pred njihovo izdajo; pregled in posodobitev ter ponovno odobritev dokumentov, ko je to potrebno; zagotovitev, da so identificirane spremembe in trenutni status popravkov dokumentov; zagotovitev, da so ustrezne izdaje primernih dokumentov na voljo na mestih uporabe; zagotovitev, da dokumenti ostanejo itljivi in prepoznavni brez težav; zagotovitev, da so dokumenti zunanjega izvora identificirani, njihovo razdeljevanje pa obvladano; prepreitev nenamerne uporabe zastarelih dokumentov in uporabo primerne identifikacije zanje, e se obdržijo za kakršenkoli namen Zahteve v procesu merjenja, analiziranja in izboljševanja procesov ISO standardi poudarjajo stalen nadzor nad procesi in posledino njihovo izboljšanje. Organizacija mora identificirati potreben nadzor in merjenja ter nadzorne in merilne naprave za preskrbo dokazov o skladnosti proizvoda z zahtevami. Organizacija mora vzpostaviti procese, s katerimi zagotovi, da se lahko nadzor in merjenje izvaja in da se izvaja na nain, ki je skladen z zahtevami za nadzor in merjenje. Da bi zagotovila veljavne rezultate, mora organizacija po potrebi merilno opremo: v doloenih intervalih ali pred uporabo umerjati ali overiti s pomojo merilnih etalonov, sledljivih do mednarodnih ali nacionalnih merilnih etalonov. e taki etaloni ne obstajajo, je treba dokumentirati osnovo, uporabljeno za umerjanje ali overjanje; nastaviti ali ponovno nastaviti, e je potrebno; identificirati, da omogoi doloitev statusa umerjanja; zašititi pred nepooblašenimi posegi, ki bi lahko pokvarili merilne rezultate; zašititi pred poškodbami in okvarami med ravnanjem, vzdrževanjem in skladišenjem. Poleg tega mora organizacija oceniti in zapisati veljavnost predhodnih merilnih rezultatov, ko ugotovi, da oprema ne izpolnjuje zahtev. Organizacija mora izvesti ustrezne Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 46

53 ukrepe na opremi in proizvodih, pri katerih je bila ta oprema uporabljena. Zapise rezultatov kalibracij in overjanja je treba vzdrževati. e se pri nadzoru in merjenju specifinih zahtev uporablja raunalniška programska oprema, je treba potrditi njeno sposobnost, da zadovolji nameravano uporabo. To je treba storiti pred prietkom uporabe in po potrebi ponovno potrditi. Organizacija mora nartovati in izvajati procese nadzora, merjenja, analiz in izboljševanja, ki so potrebni, da: dokaže skladnost proizvoda; zagotovi skladnost sistema vodenja kakovosti; nenehno izboljšuje uinkovitost sistema vodenja kakovosti. To mora vkljuevati doloitev primernih metod, vkljuno s statistinimi metodami in obseg njihove uporabe. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 47

54 4. Modeliranje poslovnih procesov Zakaj je modeliranje sistemov uporabno? Modeliranje je proces, v katerem izdelujemo, oblikujemo model, ta pa je poenostavljena, abstraktna rešitev realnega sveta, ki poudarja nek pogled na stvarnost. Pri izdelavi modela se tako lahko osredotoimo na manjše število spremenljivk kot jih je v realnem svetu. V model vkljuimo le tiste, ki jih želimo prouevati, ostale pa lahko zanemarimo. Hkrati je grafini prikaz poslovnega procesa bistveno lažje razumeti, kar zaposlenim omogoi razumevanje njihove vloge ter pripadajoe odgovornosti. Razlogi za modeliranje poslovnih procesov: izboljšanje razumevanja procesov na vseh ravneh; ustvarjanje celotne slike poslovanja; odkrivanje slabosti v izvajanju procesov; prikazovanje predlogov prenove ter njihovo preizkušanje na modelih pred uveljavljanjem v praksi in razumevanje informacijskih potreb izvajalcev procesa, ki služijo kot osnova za informatizacijo procesa. Pri modeliranju poslovnih procesov so uveljavljena doloena poslovna pravila in tehnike ali metode za modeliranje. Dandanes obstaja ve sto razlinih tehnik, vendar jih ima veina skupno znailnost, da je poslovni proces sestavljen iz slike oz. grafine predstavitve procesa, ki jo spremlja še opis, znailnosti procesa, kot so vhodi, izhodi ter dogodki, ki sprožijo izvajanje procesa (Vir: Kovai, Jakli, Štemberger, Groznik, 2004, str ) Tehnike prikazovanja poslovnih procesov Za prikaz organiziranosti se uporabljajo razline oblike sistematinega, ustnega ali pisnega izražanja. Verbalno prikazovanje temelji na naravnem jeziku, ki je izražen ustno ali pisno. Ustna predstavitev organizacijske informacije je lahko v obliki poroil, ustne predstavitve. Pod pisno obliko uvršamo zakone, predpise, strokovne kodekse, standarde, splošne akte in organizacijske predpise. Tabelarino prikazovanje organiziranosti je dvodimenzionalno in temelji na primerjanju organizacijsko relevantnih podatkov in informacij. Najpogosteje se uporablja razpredelnino prikazovanje v obliki matrike, sreamo pa tudi poskuse tridimenzionalnega prikazovanja s pomojo kocke ali prizme. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 48

55 Grafien prikaz organiziranosti temelji na prikazu odnosov med prvinami sistema s pomojo veznih rt. Izobrazbena struktura zaposlenih v organizacijah je razlina in naloga organizatorjev je, da prikažejo rešitve v takih oblikah, da jih bodo uporabniki im lažje razumeli in da bodo privlane ter vsestransko uporabne. Zato so grafine predstavitve najprimernejše, saj so enostavne, lahko razumljive in omogoajo hiter vpogled v organiziranost prikazanega podroja. Tehnike prikazovanje Verbalne Tabelarne Grafine Ustne Pisne Tabele Matrike Diagrami Mreže - Poroila - Splošni akti - Komunikacijske tabele - Komunikacijske matrike - Strukturne slike - Referati - Opisi DM - Mrežni diagrami - Predstavitve - Org. predpisi - Prikazi s pomojo delovnih polj Organigrami Tokogrami - Konvencionalni - Karte delovnega poteka - Organizirani za - Simbolini diagrami verazsežnostne - Harmonigrami strukture - Grediasti diagrami - Blokdiagrami - Struktogrami Slika 20: Klasifikacija tehnik prikazovanja organizacijsko relevantnih informacij (Vir: Ivanko, 2000, str ). Na podroju modeliranja poslovnih procesov se uporablja veliko razlinih tehnik. Med najpogostejšimi so procesni diagrami poteka, diagrami toka podatkov, diagrami eepc in Petrijeve mreže (Vir: Kovai, Jakli, Štemberger, Groznik, 2004, str. 82). Diagrami poteka Flow chart diagram Za predstavitev poslovnih procesov se uporabljajo diagrami poteka (ang. Flow Chart Diagram), s katerimi grafino ponazorimo nain izvajanja procesov. So pregledni in enostavni, hkrati pa dovolj obsežni, da lahko zajamejo vse organizacijske zahteve doloanja poslovnih procesov. Njihova najpomembnejša prednost je, da jih razumejo ljudje na razlinih Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 49

56 položajih v organizaciji, tako lastniki procesov, kot tisti, ki v proces niso neposredno vkljueni. Tehnika diagramov poteka vsebuje splošne simbole, ki se uporabljajo za doloitev razlinih dogodkov: Zaetek ali konec procesa Aktivnost Odloitev ali razvejiše Potek izvajanja procesa Podproces Slika 21: Simboli za modeliranje procesov s tehniko diagramov poteka (Vir: Kovai, Jakli, Štemberger, Groznik, 2004, str. 83). Pri diagramih poteka prikažemo s pomojo doloenih simbolov zaporedje operacij v delovnem postopku. Aktivnosti oz. potrebna opravila ugotovimo z opazovanjem poteka izvajanja posameznega opravila. Delovni postopek predstavlja zakljuen proces z jasno doloenim ciljem in koncem. Sestavljen je iz korakov operacij, ki si sledijo v loginem zaporedju kot sledi delovni ciklus. Simboli so med seboj povezani s rto, ki tee z vrha navzdol po kronološkem zaporedju opravil. S pomojo diagramov poteka narišemo tehnološke postopke in podrobne razdelitve opravil ter število izvrševalcev pri posamezni operaciji. Snemanje delovnih procesov z diagrami poteka še ne pomeni reorganizacije delovnih postopkov, temve omogoa pregled nad vsemi aktivnostmi in pridobitev informacije o vseh izvajanih postopkih in nainih njihovega izvajanja. Merjenje izvajanja poteka delovnih procesov so osnova za izboljšanje delovnih postopkov. Glavni cilj prouevanja delovanja organizacije je racionalizacija, ki odseva v boljši izrabi razpoložljivih loveških in materialnih virov (Vir: Ivanko, 2000, str ). S pomojo diagramov poteka dobimo sistematini pregled loveškega dela, ugotovimo vplivne dejavnike, lahko odstranimo nepotrebna dela ter tako izboljšamo delovne postopke v organizaciji. Posodobitev je možno izpeljati le, e poznamo organizacijo in njene dejavnike. Do želenih podatkov pridemo z opazovanjem delovnih procesov, intervjuji, vprašalniki in drugimi metodami. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 50

57 4.2. Opis in analiza elementov Programsko orodje Visual Basic.NET nima primernih objektov, s katerimi bi lahko ponazorili potek poslovnih procesov, zato je bilo potrebno narediti grafine objekte, ki so vsebovali lastnosti in predvsem obliko, primerno za modeliranje poslovnih procesov. Za modeliranje poslovnih procesov smo izbrali splošno sprejete elemente diagramov poteka, ki so tudi v praksi zelo razširjeni. Vsak proces mora imeti doloeno zaetno in konno toko, ki postavljata meje procesa. Ta se zane na eni, kona pa lahko na številnih tokah, lahko pa se zakljui predasno, pri emer se obiajno sproži drug proces v organizaciji. as za prehod od zaetne do konne toke je celotni as izvedbe, vsaka organizacija pa stremi k skrajšanju tega asa, saj daljši as izvedbe predstavlja le nepotrebne stroške. Aktivnost ali operacija je najmanjši del procesa, ki jo je smiselno modelirati. Kot aktivnost obiajno razumemo neko opravilo, ki ga izvaja nek izvajalec ter ga je nesmiselno deliti na manjše dele. Poleg doloitve izvajalca doloimo aktivnostim tudi druge znailnosti, glede na to, kako natanno želimo opisati in analizirati poslovni proces. Vsaki aktivnosti je potrebno doloiti še toen opis, kaj mora izvajalec narediti. To je lahko tudi pomo za vse sodelujoe, ki še ne poznajo vseh podrobnosti aktivnosti. Odloitev je vozliše v procesu, kjer je možno v razlinih primerih izvesti razline aktivnosti. Iz odloitve lahko izhaja ve povezav, ki imajo doloen kriterij. S tem ko doloimo pogoje prehoda v posamezno stanje, tono doloimo potek procesa. Tok oz. potek izvajanja procesa predstavlja gibanje vhodnih ter izhodnih dokumentov. Gibanje dokumenta grafino ponazorimo s pušico na premici. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 51

58 5. Razvoj programske rešitve Projekt izdelave raunalniškega programa je sestavljen iz ve faz, ki si sledijo v predpisanem zaporedju. Za vsako fazo so znailne doloene naloge in koraki, ki jim mora slediti razvojna ekipa. V fazi naredimo zahtevan dokument oz. opravilo in s tem preidemo v naslednjo fazo. Prehodi med fazami obiajno niso jasno doloeni in tako lahko vzporedno potekata dve fazi razvoja. Poleg tega se velikokrat vrnemo še v prejšnjo fazo, da doloene stvari popravimo oz. dopolnimo. V razlinih fazah razvoja sodelujejo razlini posamezniki v organizaciji in njihova vloga se spreminja. V zadnjem asu si faze ne sledijo ve zaporedno, kot to doloa linearni pristop, temve med fazami prehajamo iterativno. Krajši ponavljajoi ciklusi namre omogoajo boljše in hitrejše primerjave med zahtevami ter realizacijo. S tem lahko tudi v zaetnih fazah odkrijemo posamezne pomanjkljivosti, ki jih je lažje, predvsem pa ceneje odpraviti kot v zakljunih fazah razvoja. Velike projekte, ki zahtevajo dolgotrajen razvoj, tako razdelimo na manjše zakljuene dele, pri emer se najprej osredotoimo na kljune naloge, funkcionalnosti ter posebnosti razvijemo v zadnji fazi. V praksi je potrebno zagotoviti, da se v okviru razvoja izvedejo naslednje aktivnosti: - kreiranje koncepta, - specifikacija zahtev, - oblikovanje (design), - kodiranje, - testiranje enot/modulov, - integralno testiranje, - sistemsko testiranje, - testiranje sprejemljivosti rešitve in - uporaba rešitve. V splošnem metode razvoja klasificiramo v strukturne, objektno-orientirane in RAD (rapid application design). Tudi pri uporabi objektno orientiranih metodah je potrebno voditi proces izdelave ter upoštevati korake, ki jih podpira. V primerjavi s klasinimi pristopi oz. metodami se razlikuje samo v tem, da se uporabljajo orodja, ki podpirajo razvoj objektno orientiranih modelov, objektno orientirane podatkovne baze, objektno orientirana analiza in oblikovanje ter objektno orientirani programski jeziki. Pomembna razlika je tudi v tem, da imajo objektno orientirane metodologije drugaen pogled na predmet razprave. Skoraj ne glede na izbrano objektno orientirano metodologijo pa lahko uporabimo UML kot splošno sprejet jezik za modeliranje. Danes je med objektnimi pristopi najpogosteje Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 52

59 uporabljan Rational Unified Process za razvoj informacijskih sistemov, ki se odlino povezuje z diagrami UML. Pri izdelavi modula za obvladovanje poslovnih procesov smo uporabili objektno orientiran pristop, ki je sestavljen iz naslednjih štirih faz: zbiranje zahtev; objektno orientirana analiza; objektno orientirano oblikovanje in implementacija Zbiranje zahtev V prvem delu razvoja so doloiti splošni okvir delovanja aplikacije ter doloili informacijske in organizacijske zahteve, ki morajo biti izpolnjene, da bo projekt uspešno zakljuen. Splošen opis projekta Pri razvoju sistema za upravljanje poslovnih procesov je potrebno loiti proces razvoja na dva glavna dela. Prvi del zajema razvoj sistema, preko katerega administrator ali lastnik procesov definira poslovne procese. V tej fazi se pripravijo šablone oz. vnaprej predvidena pravila, po katerih se obdeluje dokumente v organizaciji. Poslovni procesi so dinamini elementi v organizaciji, ki se stalno spreminjajo. Tem zahtevam je potrebno slediti tudi pri razvoju aplikacije. Sistem za doloitev procesov je tako odprt, da ga lahko konni uporabniki programa nastavijo kot želijo, kar omogoa im vejo integracijo programa s poslovanjem. Ob tem program omogoa primerjalne teste procesa v razlinih asovnih intervalih, s imer spremljamo delovanje procesov. Poleg nastavitev poslovnih procesov spadajo pod prvi del tudi splošne nastavitve o uporabnikih, dokumentih ter drugih lastnostih, ki jih je potrebno doloiti za pravilno delovanje. Prvi del procesa je zato nekoliko bolj splošen in se ne spuša v podrobnosti posamezne organizacije. Prvi del je namenjen predvsem administratorju, drugi del pa je namenjen konnemu uporabniku, saj predstavlja praktino uporabo sistema. Konni uporabniki programa na podlagi pravil in nastavitev, ki jih doloi administrator, uporabljajo sistem, zato mora administrator poznati svojo nalogo v celotnem procesu, saj se le tako lahko uinkovito izvajajo procesi. Uporabnik ima možnost pošiljati dokumente poljubnemu uporabniku, ali pa gre dokument po vnaprej doloenem vrstnem redu. e izbere slednjo možnost, je potrebno izbrati ustreznega uporabnika, ki bo izvrševal naslednjo nalogo. Pomembna prednost, ki jo prinese Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 53

60 program za uporabnika je tudi razvršenost dokumentov po prioriteti obdelave. Tako uporabniku ni potrebno skrbeti, da bi pozabil na kakšen pomemben dokument. Informacijske in organizacijske zahteve Za uspešno izvedbo projekta je potrebno zagotoviti razvojne pogoje na razlinih ravneh organizacije. Pri izgradnji sistema sodeluje ve posameznikov, ki imajo razline vloge, pri tem pa se morajo zavedati pomena njihovega dela in odgovornosti. Glede na to, da se v podjetju ukvarjajo z razvojem programskih rešitev, so osnovni razvoj in testiranje izvedli sami, medtem ko bodo specifine znailnosti posamezne organizacije vkljuene v nadaljevanju. Glavne zahteve so: strokovna usposobljenost sodelujoih v projektu; najpomembnejši akterji pri razvoju rešitve so konni uporabnik in informatiki. Konni uporabnik mora poznati osnovne poslovne procese v organizaciji. Med naloge informatika spada povezovanje dela konnega uporabnika in programerjev. Programerji morajo znati razvijati programske rešitve v izbranem razvojnem orodju. Za ustrezno medsebojno sodelovanje bodo morali vsi akterji vsaj deloma poznati UML metodologijo. Projektno skupino bo potrebno dodatno izobraziti zlasti pri uporabi objektno orientiranih metod, hkrati pa se bodo morali programerji dodatno uiti uporabe.net orodja, saj bomo pri razvoju programske rešitve uporabili kombinacijo programskega orodja Visual Basic 6.0 in Visual Basic.NET. Do sedaj je bilo namre najve projektov razvitih s pomojo starejše razline Visual Basic; raunalniška pismenost; vsi uporabniki, ki bodo sodelovali pri projektu znotraj organizacije, so primerno raunalniško izobraženi in bodo lahko ustrezno sodelovali pri projektu; vrsta programske rešitve; v zaetni fazi še ni potrebna spletna aplikacija. Programska rešitev mora biti zasnovana tako, da bo pri prehodu na spletno aplikacijo im manj posega; programsko orodje, ki združuje UML in razvoj uporabniškega vmesnika; pri razvoju bomo uporabili razvojno orodje Visual Paradigm for UML, razliico Modeler Edition, ki omogoa izdelavo vseh UML 2.0 diagramov. Razliica Modeler sicer ne podpira sinhronizacije med razvojnima orodjema, kar pa tudi ne predstavlja pomembne ovire pri razvoju. Za razvoj uporabniškega vmesnika se bosta uporabili razliica Visual Basic 6.0 ter novejša verzija Visual Basic.NET 2005; strežnik za shranjevanje podatkov; Primeren strežnik za shranjevanje podatkov v organizaciji že imamo; raunalniki za razvoj in testiranje programske rešitve; Raunalniki, ki se trenutno uporabljajo v organizaciji so primerni za razvoj in testiranje, zadovoljivi sta tudi hitrost in delovanje lokalne mreže; razvojno okolje; razvojna programska oprema za razvoj je namešena na vseh raunalnikih kot tudi knjižnice za povezovanje s podatkovnimi zbirkami. V prvi fazi Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 54

61 je tako potrebno pridobiti splošne lastnosti procesov ter pripraviti nekaj dokumentov, ki bodo predstavljali izvedbo procesa; praktinost in uporabnost rešitve; smisel vsakega raunalniškega programa je izboljšati ter olajšati trenutno delo. Uporabniška rešitev mora biti preprosta za uporabo, vendar bo kljub temu od uporabnika zahtevala doloeno raunalniško znanje. Ali bo rešitev tudi praktino uporabna, je odvisno od medsebojnega sodelovanja akterjev razvoja aplikacije. Ravno s kratkimi asovnimi intervali kontrole se bo nadzorovala ustreznost programske rešitve z dejanskimi zahtevami; splošna uporaba sistema; pri uvedbi EDMS sistema je zelo pomembno, da uporabnikom prepreimo obdelavo dokumentov izven tega sistema, saj sicer rešitev nikoli ne doseže želenega uinka. Tudi modul za obvladovanje procesov mora biti postavljen tako odprto, da bo pokrival im veji del poslovanja oz. se bo lahko sistem temu primerno dopolnil; podpora vodstva v organizaciji; podpora vodilnih v organizaciji je eden kljunih dejavnikov za razvoj in kasnejšo vpeljavo informacijskega sistema, saj je vsaka investicija povezana s stroški, o katerih odloajo prav oni; asovni rok izvedbe projekta; projekt je razdeljen na dva dela, sestavljena iz razlinih modulov. Predviden as za pripravo prve testne verzije so štirje meseci. Po potrditvi konnega uporabnika, da program zadoša zahtevam, se bo ta zael tudi praktino uporabljati. Glavni cilj in namen programa je pridobiti vejo kontrolo nad dokumenti, ki se uporabljajo pri poslovanju, saj lahko praktino v vsakem trenutku ugotovimo, kje se kakšen dokument nahaja. Raunalnik uporabnika obveša, katere dokumente je potrebno dokonati na podlagi postavljenih pravil. Potrebno je poudariti, da vpeljava sistema za elektronsko vodenje dokumentov ne predstavlja reorganizacije poslovanja, temve se procesi odvijajo na enak nain, kot pred uvedbo sistema, le da dokumente obdelujejo v elektronski obliki. Tako je bolje govoriti o informatizaciji poslovnega procesa, saj je glavna sprememba v tem, da se uporabi razlino informacijsko tehnologijo Objektno orientirana analiza Objektno orientirana analiza vkljuuje štiri pomembne dele, ki jih je potrebno pokriti: doloimo podrobne znailnosti celotnega sistema; preko primerov uporabe in scenarijev opredelimo funkcionalnosti sistema; postavimo razredne diagrame in modele povezovanja ter zakljuimo analizno dokumentacijo. (Vir: Satzinger, Ovrik, 2001, str. 106). Najprej je bilo potrebno doloiti podrobno definicijo sistema ter kljune primere uporabe, nato pa vzporedno z morebitnimi spremembami v kljunih primerih uporabe zaeti z Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 55

62 razvojem razrednih ter drugih interaktivnih modelov. Pripravljeni konni dokument je bil potrjen s strani konnega uporabnika, ki se strinja z opisom sistema. Pri definiciji sistema smo doloili obseg projekta ter prednosti, ki jih bo prinesel novi sistem. Pri podrobni doloitvi znailnosti sistema smo uporabljali program MS Word in s številnimi intervjuji z uporabniki in informatiki pripravili konni dokument. Podroben opis sistema za obvladovanje poslovnih procesov S splošno definicijo lahko poslovni proces opredelimo kot zakljueno celoto, ki ima doloen vhod (input), ta pa se znotraj procesa prek akcij (korakov) predela v želeni rezultat, ki predstavlja izhod (output) iz procesa. Pogosto je izhod iz enega procesa vhod v nov proces. Pri upravljanju dokumentov delovni tok (angleški izraz workflow) ponazarja gibanje dokumenta skozi številne korake, ki so usmerjeni v dosego priakovanega cilja. Za doloitev osnovne poti dokumentom je zato potrebno poznati poslovne procese v organizaciji. Pri obravnavanju procesov ugotovimo, da se doloen proces ne izvaja le znotraj enega oddelka oz. službe, temve dokument skozi razline faze prehaja med oddelki. Modul za upravljanje poslovnih procesov je namenjen osebi ali skupini ljudi v organizaciji, ki pozna njihov potek. Lastnik procesa oz. administrator sistema s pomojo simbolov za risanje diagramov poteka doloi poslovni proces, z glavnim poudarkom na pretoku dokumentov skozi razline faze oz. aktivnosti. Zaradi pogoste menjave zaposlenih v organizacijah je primernejše, da je lastnik procesa skupina uporabnikov oz. uporabniki, ki imajo doloeno vlogo v skupini. Lastnik procesa je odgovoren za pravilno izvajanje procesa in v primeru nejasnosti nudi pomo ostalim uporabnikom sistema. Samo lastnik procesa ima možnost spreminjati ali dopolnjevati potek procesa. e se spremembe nanašajo na celotno skupino dokumentov, mora skrbnik procesa spremembo pravilno nartovati in doloiti obnašanje dokumentov vkljuenih v proces, ki ga želi spremeniti. Zaradi primerjanja procesov v razlinih asovnih obdobjih je potrebno procese verzionirati in jih shranjevati v repozitorij. V delovnem procesu se uporabljajo razlini dokumenti, ki v procesu prehajajo skozi življenjski cikel. Z vidika upravljanja dokumentov se obravnava vedno le en dokument, ki ima lahko povezavo z drugimi dokumenti oz. drugimi procesi. Pri prehodu med dokumenti se aktivni proces zakljui in zane se nov proces, v katerem se obravnava drug dokument. Pri tem prihaja do povezave med dokumenti razlinega izvora (vhodni in izhodni dokumenti). Poslovni proces sestavlja doloeno število korakov, ki se morajo za dosego želenega cilja zgoditi v doloenem zaporedju. Procesi so povezani z uporabniki, ki opravljajo doloene naloge akcije. Delovne procese delimo v dve glavni skupini: strukturirani procesi so procesi, kjer dokument opravi pot, ki jo vnaprej doloi administrator ali lastnik dokumenta. Takšen nain se uporablja, kadar so pravila za reševanje tono doloena; Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 56

63 ad-hoc procesi predstavljajo procese, ki nimajo tono doloene poti in katerim uporabnik doloi postopek v danem trenutku, glede na okolišine v organizaciji. Poslovanje v organizaciji je obiajno težko tono definirati in program za opravljanje procesov mora omogoati upravljanje dokumentov, ki nimajo vnaprej doloene poti. Tudi takšni poslovni procesi imajo svoj cilj, do katerega mora priti dokument, medtem ko poti za dosego tega cilja nimajo doloene vnaprej. V praksi ne moremo loiti vseh procesov na zgoraj opisana naina, zato se uporablja tudi kombinacija obeh. Vsak dokument lahko opravi tudi poljubno število vnaprej nepredvidenih korakov. Pomembno je le, da dokument nadaljuje proces tam, kjer je iz njega izstopil. Aktivnost Za vsak korak v poslovnem procesu mora biti doloena akcija, torej navodilo uporabniku za delovanje v okviru doloenega koraka. Po izvedbi navodila mora uporabnik posamezno akcijo zakljuiti ali dokument zaradi nepravilnosti oz. pomanjkljivosti poslati v predhodno akcijo. e gre dokument skozi bolj kompleksen proces, lahko uporabnik dokument pošlje tudi nazaj do lastnika dokumenta, s imer ta zane pot od zaetka. V organizacijah se prepletajo tri aktivnosti: sekvenna ali linearna aktivnost, ki predstavlja linearno postavljeno zaporedje aktivnosti, pri emer je vsaka aktivnost odvisna od prejšnje zakljuene aktivnosti A B C Slika 22: Primer linearne aktivnosti (Vir: Bielawski, 1997, str. 140). vzporedna ali paralelna aktivnost, pri kateri dokument lahko pošljemo dokument ve osebam, oz. je dokument istoasno vkljuen v ve aktivnosti. V primerjavi s sekvenno aktivnostjo je as izvedbe krajši; B A C E D Slika 23: Primer vzporedne aktivnosti (Vir: Bielawski, 1997, str. 140). Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 57

64 razvejana aktivnost, ki se uporablja kot pogojni tip korakov, saj je pot dokumenta odvisna od vrednosti lastnosti, ki jih ima dokument. To je lahko odloitev uporabnika ali pa je odloitev avtomatska. Znesek >= 1 mio C A B Znesek < 1 mio D Slika 24: Primer razvejane aktivnosti (Vir: Bielawski, 1997, str. 141). Doloitev poslovnega procesa Eden najbolj razširjenih nainov doloanja poslovnih procesov v praksi je risanje diagramov poteka, ki vsebuje preproste in razumljive elemente. Ravno iz tega razloga smo se odloili, da mora program omogoati modeliranje poslovnih procesov s pomojo splošno znanih elementov te metode. Osnovni elementi za definiranje poslovnih procesov so: zaetek in konec procesa, aktivnost, odloitev, potek izvajanja procesa ter podproces. Vsakemu procesu je potrebno doloiti zaetno toko, ki se simbolino nariše z rombom. Nato doloimo aktivnosti, ki jih povežemo s pušico (ta ponazarja tok dokumentov). e je tok povezan na enega od predhodnih korakov, govorimo o povratni zanki. Do tega v praksi pride, e naloge niso bile pravilno opravljene in morajo prejšnji uporabniki napako popraviti. Aktivnost ali korak v procesu je ponazorjen s pravokotnikom. Vsaka aktivnost mora imeti tono doloeno nalogo, izvajalca ter asovni okvir izvedbe. V primeru razvejane aktivnosti je potrebno doloiti tudi kriterije, ki doloajo pot dokumentu. Te uporabnik sestavi iz splošnih lastnosti dokumenta. Proces se zakljui, ko dokument pride do konne toke v procesu, tega pa doloimo z enakim likom kot zaetek procesa. Preden je potek procesa primeren za uporabo, je potrebno raunalniško preveriti ali je postopek pravilno doloen ter ali so vneseni vsi zahtevani podatki. Raunalnik opozori uporabnika na vse pomanjkljivosti in napake. e uporabnik ne odpravi vseh napak, se postopek shrani v repozitorij kot delovna verzija, ki se ne še more uporabljati v praksi. Sheme procesov, ki so se kadarkoli uporabljali v praksi, morajo biti shranjene v repozitoriju ter jih ne more izbrisati niti administrator programa. Brišejo se lahko le sheme, ki Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 58

65 so uspešno zakljuene ter še niso bile rabljene, ali pa so ostale v fazi osnutkov. Pravico za brisanje sheme ima administrator programa ali lastnik procesa. Uporabniki in skupine V organizaciji je obiajno zaposlenih ve ljudi, ki opravljajo razlina opravila, naloge oz. sodelujejo na razlinih projektih. Ob razdelitvi posameznih nalog med zaposlene oblikujemo neformalne skupine. Skupina vkljuuje posameznike iz razlinih oddelkov, ki znotraj skupine sodelujejo le za as projekta. eprav gre za neformalno skupino, pa se znotraj skupine oblikujejo doloene vloge (vodja skupine, lan itd.). Sistem zagotavlja, da je zaposleni lahko hkrati lan ve skupin, pri emer v vsaki od teh lahko zavzema drugo vlogo. Uporabnik ima lahko doloenega tudi svojega namestnika, ki prevzame izvajanje nalog takrat, ko je uporabnik odsoten z dela. S tem prepreimo kopienje dokumentov pri uporabniku in omogoimo nemoten tok poslovnih procesov. Ljudje so pomemben klju v vsakem poslovnem procesu, pri emer je važno, da razumejo potek celotnega procesa in svojo vlogo v njem. Pri splošnem doloanju procesa njegov lastnik za izvajalca vsake aktivnosti doloi skupino uporabnikov oz. pri vejih sistemih izbere vlogo znotraj skupine uporabnikov. Zaradi stalne migracije zaposlenih vlog ni smiselno doloiti poimensko, temve funkcionalno (glede na položaj zaposlenega v organizaciji). Dodatno prednost EDMS sistema pri obvladovanje skupin in pravic uporabnikov dobimo, e se EDMS sistem poveže na že obstoje sistem skupin in uporabnikov. Smiselna je povezava uporabnikov in skupin, ki so v sistemu za pošiljanje elektronske pošte ali pa sistema skupin in uporabnikov na operacijskem sistemu. Z združevanjem teh sistemov administratorjem skrajšamo as in napor, ki ga potrebujejo pri sinhronizaciji dveh ali ve sistemov pravic. Dokumenti Zaradi velikega števila dokumentov v organizaciji je priporoljivo združevati dokumente z enakimi lastnostmi v skupine. S tem zagotovimo, da podobni dokumenti opravijo enake korake, in konnega uporabnika razbremenimo skrbi za zagotovitev poti, ki jo mora opraviti dokument. Hkrati ima organizacija veji nadzor nad poslovnimi procesi in jih lahko standardizira ter s pomojo analize optimizira. Tudi dokumenti znotraj ene skupine imajo lahko doloene svoje procese, ki se med seboj razlikujejo. Sistem pri izbiri prednastavljenega procesa da prednost procesu, ki je doloen za dokument, v primeru, da je proces doloen tudi za skupino dokumentov. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 59

66 Za vsak dokument moramo imeti zabeležene naslednje lastnosti: kdo je dokument kreiral in kdaj, datum zadnje spremembe, verzija dokumenta in pravice dostopa do dokumenta. Hkrati ima ta tudi poljubno število lastnosti, ki jih doloa administrator ali lastnik dokumenta. Varnost in pravice dostopa do dokumentov EDMS sistemi imajo vse dokumente shranjene na skupnem mestu (datotenem sistemu) in zato hitro pride do zlorabe dokumentov, e imamo neprimeren sistem zašite dokumentov. V prvi vrsti je potrebno poskrbeti za varnost datotenega sistema na ravni operacijskega sistema, hkrati pa prepreiti dostop do vsebine dokumenta uporabnikom, ki vdrejo v datoteni sistem. Za varnost najlažje poskrbimo s šifriranjem in dešifriranjem dokumentov. Vsak dokument, ki pride v EDMS sistem, se kriptografira, nakar se ga prenese na strežnik. Tako je zmanjšana možnost zlorabe, tudi e pri prenosu dokumenta na strežnik pride do napake. Program vse dokumente, ki jih želimo odpreti, najprej prenese na lokalni raunalnik, dešifrira in prikaže vsebino dokumenta. Za nemoteno uporabo sistema je potrebno vsem uporabnikom programa doloiti pravice dostopa do dokumentov. Pravice in opisi dostopov se lahko vežejo na skupino dokumentov ali na posamezen dokument. Ravni pravic so predstavljene v tabeli 2. Dostop Ni dostopa Iskanje Branje Popravljanje Brisanje Tabela 1: Seznam pravic dostopa do dokumenta Opis Uporabnik nima pravice dostopa do dokumenta ali njegovih lastnosti. Uporabnik vidi dokument in njegove lastnosti, ne pa vsebine dokumenta. Uporabnik vidi dokument, njegove lastnosti ter vsebino, vendar je nima pravice spreminjati. Uporabnik ima pravico spreminjati vsebino dokumenta in njegove lastnosti. Popravljanje dokumentov zahteva kopiranje dokumenta iz repozitorija na lokalni raunalnik, nato pa se spremembe ponovno prenesejo v repozitorij. Uporabnik ima pravico brisanja dokumenta iz repozitorija. Administrator Uporabnik ima administratorske pravice nad dokumenti in lahko spreminja pravice dostopa. e je dokument trenutno v procesu, ga je nemogoe spreminjati (je zaklenjen za uporabnika, na katerega je naslovljen), tudi e imamo pravice za popravljanje dokumentov. Dokument se lahko pošlje tudi v vednost, kar pomeni, da uporabnik dobi pravico za branje. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 60

67 Upravljanje dokumentov Pri obdelavi dokumentov skrbi modul za upravljanje procesov, da dokument naredi celotno pot. Pri dokumentih, ki imajo vnaprej definirano pot in vnesene vse potrebne atribute, pozna sistem akcije, ki se morajo zgoditi. V nasprotnem primeru mora uporabnik rono doloiti naslednji korak. Ko uporabnik zakljui aktivnost v procesu ter želi dokument poslati naprej, mora uporabniku sistem pokazati naslednje možne aktivnosti. Te so predhodno doloene v procesu, hkrati pa ima uporabnik še možnost pošiljanja dokumenta do poljubnega uporabnika. Druga možnost je pomembna za vse dokumente, ki nimajo tono doloene poti ter za tiste, ki zaradi okolišin ne gredo po vnaprej doloeni poti. Da se uporabnik lažje odloi za nadaljnji korak, ima možnost vpogleda v trenutni poslovni proces, kjer natanko vidi opravljeno pot dokumenta. Da pa lahko dosežemo stalno spremljanje dokumenta, se podatki o opravljeni aktivnosti shranijo v repozitorij. Upravljanje razliic dokumentov Dokumentu se ob vsaki spremembi povea verzija. Vse razliice dokumenta se shranijo v repozitorij, kar omogoa pregled sprememb. Verzije dokumentov narašajo z višanjem zaporedne številke npr.: 1, 2, 3. e je dokument slika, se spremeni verzija, ko se sliko obdela z dodatnim filtrom, doda beležko ali opombo neposredno na sliko. e pa se sliki spremeni samo postavitev, se verzija dokumenta ne spremeni. S spreminjanjem verzije dokumenta sta povezani dve kljuni funkciji repozitorija, podrobneje opisani v nadaljevanju: prijava dokumenta v sistem je osnovna funkcija, ki jo omogoa repozitorij. Ko dobi zahtevo za vnos novega dokumenta, repozitorij preveri ali ima posameznik to pravico ali ne. Pri vsakem uvoženem dokumentu se dokument shrani na strežnik v datoteni sistem, ostali meta podatki o dokumentu pa v podatkovno zbirko. Za vnos dokumenta v sistem je potrebno vnesti vsaj opis dokumenta, saj je to kljuni parameter za vodenje procesov; odjava dokumenta iz sistema je podobna izposoji knjig v knjižnici. Sistem mora preveriti, kakšno pravico ima uporabnik nad dokumentom, ki ga želi odpreti. e uporabnik lahko dokument samo bere, se ne naredi odjava dokumenta, temve se dokument le prenese na lokalni raunalnik in se ga prikaže uporabniku. e ima uporabnik pravico popravljati vsebino dokumenta, se ta prenese iz repozitorija na osebni raunalnik uporabnika in se zaklene za popravljanje ostalim uporabnikom. Ostali uporabniki imajo zaasno pravico le za branje. e uporabnik, ki ima dokument odprt za popravljanje, tega ne zakljui in ga shrani nazaj v repozitorij, je potrebno ob zaprtju programa vse odprte dokumente z lokalnega raunalnika prenesti v repozitorij, saj bo le tako lahko naprej popravljal dokument tudi na drugem raunalniku. Ostali uporabniki bodo še vedno lahko gledali le zadnji potrjen dokument, ki je shranjen v bazi. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 61

68 Analize in poroila procesov V podatkovno zbirko se shranjujejo podatki o poslovanju, zlasti pretoku dokumentov skozi procese. Iz teh podatkov sistem omogoa prikaz razlinih analiz ter primerjav med poslovnimi procesi. Ravno z analizo lahko ugotovimo, kje se pojavljajo težave in zastoji v procesu, kar nam omogoa postopno odpravljanje pomanjkljivosti. e izhajamo iz Demingovega kroga stalnih izboljšav (nartuj izvedi preveri izboljšaj), predstavlja to tretjo fazo, kjer preverjamo rezultate. Analiza in poroila so namenjena administratorju oz. lastnikom procesov, saj le oni lahko spreminjajo njihov potek. Smiselno je doloiti asovni interval, v katerem se analizirajo rezultati primerjav e je ta prekratek, ni nujno, da odraža realno stanje procesa, saj je opazovani vzorec lahko premajhen. Procesi so dinamini elementi, ki jih je potrebno opazovati, meriti, nadzorovati in izboljševati. S pomojo raunalnikov, ki zelo zanesljivo in hitro obdelujejo veliko koliino podatkov, je nadzorovanje procesov bistveno lažje. Zahteve pri uporabi modula v podjetju Laser Computer d.o.o. Oddelek se v podjetju ukvarja z razvojem poslovnih raunalniških aplikacij predvsem za mala podjetja. Kljub majhnosti oddelka pa se dovolj hitro izgubi nadzor nad programsko dokumentacijo. Modul so zaeli uporabljati za vejo preglednost dokumentov, ki so kljunega pomena za razvoj, poleg tega pa so se odpravile pomanjkljivosti programa. Z intervjuji konnih uporabnikov in drugih sodelavcev v razvoju so pridobili informacije, potrebne za izgradnjo programske rešitve. V tej fazi je pomembno, da konni uporabnik in razvijalci dosežejo konsenz o funkcionalnostih programske rešitve. V nasprotnem primeru se lahko zgodi, da stranke ne bodo zadovoljne s konnim programom, ker ne bodo pokrite vse zahteve. Za njihovo doloitev je smiselno uporabiti primere uporabe na najvišji ravni. Primeri uporabe so napisani v vsakdanjem jeziku, tako da jih lahko razumejo vsi sodelujoi. Pri zapletenejših sistemih potrebujemo listo poslovnih pravil, pri manjših projektih pa lahko takoj preidemo v fazo izdelave primerov uporabe. Poslovno dokumentacijo organizacije pogosto prejmejo v pisni obliki po klasini pošti. e želimo vse dokumente voditi v elektronski obliki, jih je potrebno pretvoriti, kar omogoa modul za zajem dokumentov, elektronske dokumente pa lahko uvozimo v program in jih pošljemo ustreznim uporabnikom. Seveda ne moremo enaiti elektronske pošte z upravljanjem poslovnih procesov, ampak lahko predstavljajo le del poslovnih procesov. Pri pošiljanju elektronske pošte gre namre za izmenjavo sporoil in dokumentov med dvema uporabnikoma, ki ne poznata celotnega procesa ter najpogosteje ne konnega cilja. Organizacija pri svojem poslovanju uporablja veliko razlinih - glavnih in manj pomembnih - dokumentov. Za uvedbo modula je v prvi fazi uvedbe smiselno doloiti pot Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 62

69 kljunim dokumentom, ki so bistveni za uspešno delovanje organizacije. Med te dokumente vsekakor spadajo programska dokumentacija, prejeti in izdani rauni, pogodbe in ponudbe. Ne glede na izvor dokumenta mora programska rešitev omogoiti boljši nadzor nad dokumenti, ki se uporabljajo v organizaciji. V grobem jih delimo v naslednje skupine: prejeti dokumenti (dokumenti, ki pridejo v organizacijo od drugih organizacij); oddani dokumenti (dokumenti, ki nastanejo v organizaciji in se jih pošlje v drugo organizacijo) in interni dokumenti (dokumenti, ki nastanejo v organizaciji in se uporabljajo v organizaciji). Kljunega pomena pri razvršanju dokumentov po poslovnih procesih je opis oz. skupina v kateri je dokument. Ko uporabnik doloi poslovni proces, lahko doloi dokumente, ki ga morajo opraviti. En proces se lahko navezuje na ve dokumentov oz. skupin dokumentov. Še vedno pa ima uporabnik možnost poslati dokument v poljubno aktivnost. Seznam osnovnih primerov uporabe Na podlagi pripravljenega podrobnega opisa posameznih segmentov delovanja programa, so zaeli z modeliranjem diagrama primerov uporabe. Diagrame primerov uporabe so kreirali v programskem orodju Visual Paradigm. Na zaetku so doloili mejo sistema, ki je predstavljala celotni modul za obvladovanje poslovnih procesov in so tako vse funkcionalnosti modula združili. eprav je doloevanje primerov uporabe obiajno delo konnih uporabnikov, ki iz praktinega stališa opredelijo problem, so zaradi pomanjkanja znanja o modeliranju diagramov UML primere uporabe pripravili informatiki. Risanje diagrama primerov uporabe so zaeli z doloevanjem nazivov primerov uporabe ter jih povezati med seboj. Pri tem je bilo potrebno doloiti vrsto povezave ter vsakemu primeru uporabe doloiti stopnjo prioritete in tako postavili asovni okvir, kdaj je bilo potrebno posamezen segment programa zaeti razvijati. Zaradi manjšega števila razvijalcev je bilo nemogoe zaeti z razvojem vseh funkcionalnosti hkrati, s pomojo rangiranja primerov uporabe pa so pridobili ravno na asovni preglednosti projekta. Pomembnejšim primerom uporabe so doloili višjo prioriteto in jih je bilo potrebno razviti v zaetni fazi, saj so predstavljali osnovo za nadaljnje delo. Manj pomembne dele programa pa so zaeli razvijati šele, ko se je program že uporabljal v praksi. Najpomembnejši primeri uporabe so predstavljeni v tabeli 2 in grafino na sliki številka 25. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 63

70 Tabela 2: Seznam primerov uporabe za celotni modul Rang Naziv Opis Nizek Visok Visok Visok Srednji Nizek Visok Nizek Visok Srednji Srednji Nizek Pošlji opozorilo o zastoju Pošlji dokument Poglej poštni predal Nastavi iskalne kriterije Prekini proces dokumentu Prikaži opravljen proces Izpis poštnega predala Analiziraj proces v razlinih obdobjih Doloi potek procesa Preveri pravilnost procesa Spremeni proces Briši proces Pošiljanje opozorila predstavlja dodatno funkcijo, ki omogoa boljši nadzor nad procesi, ni pa nujna za osnovno delovanje sistema. Pošiljanje dokumentov pošlje dokument v naslednjo aktivnost k izbranemu uporabniku. Uporabnik pregleda prejete in poslane dokumente, sporoila ter opozorila. Iskanje dokumentov v poštnem predalu po razlinih kriterijih. Uporabnik prekine naprej doloen potek procesa. Vsebuje tabelarini in grafini prikaz opravljenega procesa. Izpis prejetih oz. poslanih dokumentov v seznam. Analize in poroila predstavljajo zadnjo fazo pri uporabi in so namenjeni vodilnih v organizacijah. S pomojo poroil ugotovimo dobre in slabe lastnosti poslovnih procesov. Uporabnik s pomojo Flow-Chart simbolov doloi poslovni proces. Preverjanje pravilnosti procesa je potrebno izvesti pred shranjevanjem procesa. e je proces brez napake je primeren za uporabo, sicer ga je potrebno dopolniti. Procesi v organizacijah so dinamini, zato jih je potrebno stalno dopolnjevati in izboljševati. Brisanje poslovnega procesa iz repozitorija nima kljunega pomena za delovanje sistema. Zaradi analize podatkov se lahko izbriše le proces, ki ni bil nikoli uporabljen. Visok Prikaži proces Grafien prikaz objektov in izpis njihovih lastnosti. Nizek Visok Visok Visok Srednji Analiziraj vse procese Doloi aktivnost Doloi zaetek procesa Doloi konec procesa Doloi podproces Primerjava procesov med seboj. Uporabnik doloi aktivnost v procesu in njegove lastnosti. Uporabnik doloi zaetni element v procesu. Uporabnik doloi konni element procesa. Procesi se v organizaciji med seboj prepletajo in zaradi hitrejšega risanja procesov je smiselno doloiti reference za procese, ki že obstajajo. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 64

71 Visok Nizek Visok Visok Srednji Srednji Visok Visok Visok Srednji Nizek Nizek Nizek Poveži elementa Vnesi pogoj delovanja Odpri dokument Vnesi opis dokumenta Doloi splošno pravico dostopa do dokumenta Vnesi skupino dokumenta Vnesi vlogo uporabnika Razporedi uporabnika Vnesi ekipo uporabnika Pošlji zahtevo odsotnosti od dela Odjavi uporabnika od dela Doloi pooblašenca Doloi položaj zaposlenega v organizaciji Aktivnosti morajo biti med seboj povezane, saj to predstavlja tok dokumentov v organizaciji. Pogojne aktivnosti predstavljajo dodatno funkcijo, ki proces avtomatizira. Pogoji so sestavljeni iz lastnosti dokumentov. Program odpre dokument, da uporabnik vidi vsebino dokumenta Opis dokumenta je kljuni identifikator, ki se upošteva pri upravljanju dokumentov. V organizaciji se uporabljajo razlini dokumenti, do katerih imajo uporabniki razline pravice dostopa. Vnos naziva skupine dokumentov. Uporabniku doloimo vlogo znotraj ekipe. Uporabnika razporedimo v ekipo. Doloitev naziva ekipe uporabnika. Uporabnik svoj izostanek pošlje nadrejenemu v potrditev. Nadrejeni potrdi izostanek podrejenega. Uporabnik pošlje zahtevo za pridobitev pooblašenca. Doloi položaj zaposlenega v organizaciji. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 65

72 Slika 25: Diagram primerov uporabe za sistem obvladovanja poslovnih procesov Po pripravi grafinega prikaza primerov uporabe je bilo potrebno predvideti njihove scenarije. Vsakemu primeru uporabe so doloili scenarij ter tako pridobili nain, kako mora program delovati. Opisi scenarijev primerov uporabe so predstavljali glavno osnovo nadaljnjega razvoja diagramov obnašanja. Oblikovanje in snovanje scenarijev primerov uporabe, ki vkljuujejo poslovna pravila, je bila asovno najdaljša faza razvoja. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 66

73 5.3. Objektno orientirano oblikovanje (design) Pred zaetkom priprave zasnove programa so ponovno pregledali pripravljene scenarije primerov uporabe ter oblikovali uporabniške vmesnike in doloili prehode med njimi. S pomojo izdelanih uporabniških vmesnikov so konni uporabniki dobili boljšo predstavo, kaj bo program delal in kako bo funkcioniral, hkrati pa je bilo v tej fazi zelo preprosto spremeniti doloene koncepte. Za pripravo uporabniških vmesnikov ni mogoe uporabiti diagramov UML, zato so jih naredili kar v orodju, ki so ga uporabili za razvoj aplikacije. Glavne prednosti, ki so jih pridobimo z izgradnjo uporabniških vmesnikov so bile: konni uporabniki sodelujejo v razvoju; potrditev osnovnih zahtev s strani konnega uporabnika; ugotovimo uporabnost vmesnikov; spoznamo povezave med uporabniškimi vmesniki in že v zaetni fazi ugotovimo, katera okna bomo lahko vekrat uporabili. eprav je postopek, opisan v nadaljevanju, napisan kot sekvenni proces, so koraki potekali iterativno v manjših asovnih intervalih in so vkljuevali naslednje korake: analiza, oblikovanje, kodiranje in testiranje. Najprej so bili razviti kljuni deli programa, na podlagi katerih je bilo možno dopolnjevati in graditi program do konne podobe. Celotni modul obsega številna podroja, ki imajo med seboj razlino stopnjo povezanosti. Pri objektno orientiranih programskih rešitvah je potrebno celotni modul razdeliti na ve samostojnih delov (razredov) ter doloiti relacijo med njimi. V grobem so program razdelili na sedem delov oz. imenskih prostorov. Glavni kriterij razdelitve je bil vsebinsko podroje posameznega razreda. Modul za obvladovanje poslovnih procesov je razdeljen na naslednje samostojne sklope: WMS Employee razredi, povezani z zaposlenimi; WMS Document razredi, povezani z dokumenti; WMS Process razredi, povezani z uporabo procesov; WMS Element razredi, povezani z nastavitvijo poslovnega procesa; WMS Utility - splošne funkcije; GUI - vsi razredi uporabniških vmesnikov in Workflow Management System povezovalni COM 14 len med programom LEA in modulom za obvladovanje poslovnih procesov. 14 COM angleški izraz Component Object Model je razvojni model in tehnologija programa Windows, ki poenostavlja razvoj komponent programske opreme, ki se jih da ponovno uporabiti. (Vir: DePetrillo, 2002, str. 11). Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 67

74 Razrede strokovno delimo glede na njihovo vlogo v tri skupine: domenske razrede, ki pokrivajo delovanje osnovnih poslovnih enot; razrede uporabniških vmesnikov, ki akterjem omogoajo povezavo s sistemom in procesne razrede, ki pokrivajo poslovno logiko, ki se prepleta skozi razline poslovne enote. (Vir: Scott W. Ambler, 2005, str. 9). Sledilo je oblikovanje in postavitev razredov, pri tem pa so bili ponovno glavna osnova pripravljeni scenariji primerov uporabe. V zaetku so pripravili diagrame razredov, ki so pokrivali podroja administracije dokumentov, zaposlenih, vlog ter skupin uporabnikov. Vsak razred ima doloen naziv razreda, podroje obsega ter vsebuje lastnosti in metode glede na predmet obravnave. Lastnostim so doloili podatkovni tip, stopnjo vidnosti ter podatek, ali je mogoe lastnost spreminjati ali je dostopna le za branje. V slednjem primeru uporabniku prepreimo direktno spreminjanje lastnosti, lahko pa lastnost spremenimo prek metod, na primer: število zapisov v seznamu se lahko spreminja preko metode dodaj ali odvzemi, ne pa neposredno. Metodam pa so doloili stopnjo vidnosti in parametre, ki jih metoda potrebuje za izvedbo. V zaetni fazi so veini metod doloili vidnost samo znotraj svojega razreda, potem pa se je v procesu razvoja vidnost po potrebi spreminjala. S tem omogoimo konnemu uporabniku, da vidi le tiste metode in lastnosti, ki jih potrebuje, ostale pa ostanejo skrite v razredu. Ko so bili pripravljeni osnovni domenski razredi, so zaeli z razvojem procesnih razredov, ki so vsebovali osnovne operacije poslovne logike. Ker z razvojem objektno orientiranih informacijskih sistemov niso imeli veliko izkušenj, so si pomagali z naslednjo praktino metodo. Postavili so se v vlogo razredov, ki so jih obravnavali. Pri tem vsak posameznik predstavlja svoj razred in pove svoje lastnosti ter kaj od drugega razreda zahteva oz. katere operacije opravlja sam. To je ena od zelo preprostih tehnik, ki jo lahko uporabimo za boljše oblikovanje razredov. Razrede so znotraj posameznega imenskega prostora glede na medsebojno odvisnost povezali med seboj. Uporabili so vse tipe povezav od odvisnosti med razredi do dedovanja. Pri doloitvi povezav med razredi velikokrat pride do spora med razvijalci ali gre za povezavo kompozicije ali agregacije. Najlažje je upoštevati pravilo, da se kompozicijo uporabi kadar gre za povezovanje fizinih elementov v realnem svetu in agregacijo, ko govorimo o povezovanju abstraktnih elementov. Pri razvoju razredov so uporabili tudi druge objektno orientirane koncepte kot so polimorfizem, ograjevanje, dedovanje in pošiljanje sporoil med razredi. Z uporabo teh konceptov postane celotna struktura programske rešitve preglednejša in lažje obvladljiva. Glede na zapletenost obravnavanega problema so pripravili še dodatne diagrame UML. Najpogosteje so v tej fazi uporabili še sekvenni diagram, diagram sodelovanja, diagram stanja ali diagram aktivnosti. Seveda za vsak primer uporabe niso naredili dopolnilnih diagramov UML, saj bi s tem le podaljšali celotni as izvedbe. V zaetku razvoja Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 68

75 so diagrame pripravili v obliki skic na papirju in jih šele nato prenesli v program Visual Paradigm. Slika 26: Podatkovni model modula za obvladovanje poslovnih procesov Razliica programa Visual Paradigm for UML Developer Edition ne omogoa samodejnega generiranja programske kode na podlagi diagramov razreda, zato je bilo potrebno rono doloiti strukturo in lastnosti razredov. Kodiranje se je prielo s pripravo Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 69

76 domenskih razredov in nadaljevalo s kodiranjem povezovalnih razredov navzgor. Sledilo je povezovanje razredov med seboj in s pomojo osnovnih konceptov objektnega programiranja optimiziranje programske kode. Nato so razvite domenske in procesne razrede vkljuili v razrede uporabniških vmesnikov. Tako so praktino preverili pravilnost delovanja ter postopoma dodajali metode, ki se povezujejo s podatkovno zbirko. Pri tem se je postavilo vprašanje ali je smiselno metode, povezane s podatki, loiti od procesnih razredov. Zaradi specifine uporabe so se odloili, da so metode znotraj procesnih razredov in se zavedali dejstva, da se na ta nain izognemo vekratnemu pisanju enake programske kode, hkrati pa razredi izgubijo na splošnosti, saj so vezani na tono doloen podatkovni model. Za delo s podatki je bilo potrebno pripraviti tudi entitetno-relacijski diagram in izdelati podatkovni model, doloiti strukture tabel in povezave med njimi, vendar so zaradi dobrega poznavanja relacijskih baz podatkov zaeli kar pri razvoju podatkovnega modela. Osnova za izdelavo podatkovnega modela so bili pripravljeni diagrami razredov, povezave pa so doloili s pomojo relacij med razredi. Celoten podatkovni model je predstavljen na sliki 26. Sledil je razvoj glavnega okna za modeliranje poslovnih procesov, ki predstavlja srce celotnega modula in oblikovanje grafinih razredov za prikaz osnovnih elementov diagrama poteka. V prvi vrsti je bilo potrebno zagotoviti, da bo dosežena primerna oblika elementov, da bodo elementi vsebovali zahtevane lastnosti ter da jih bo možno dinamino kreirati. Najtežje je bilo pripraviti metode, ki so zagotavljale primerno obliko elementov in njihovo dinamino doloevanje lastnosti. Ko so imeli pripravljene osnovne grafine gradnike za modeliranje poslovnih procesov, so zaeli z razvojem okna za modeliranje poslovnih procesov. Vsak poslovni proces je sestavljen iz opisnega dela in grafinega prikaza, kot je ponazorjeno na sliki 25. S tem je bila zakljuen prvi del programa, ki je bil namenjen predvsem administratorju. Drugi del programa pokriva splošno uporabo modula s poudarkom na pošiljanju in sprejemanju dokumentov. Na podlagi postavljenih pravil, ki jih je administrator dinamino doloil je bilo potrebno uporabniku omogoiti pošiljanje dokumentov. Ker tudi ta del predstavlja pomembni del programa, so se uporabili dodatni diagrami UML, predvsem diagram zaporedja in diagram sodelovanja, s katerima zelo nazorno prikažemo interakcije med razredi. V tej fazi je bilo potrebno novo nastali modul povezati z obstojeim programom LEA, saj so dokumenti postali pomemben predmet obravnave, te pa je mogoe upravljati prek glavnega programa. Tako kot v prejšnjih fazah so tudi tukaj najprej pripravili domenske razrede, nato procesne razrede ter jih na koncu vkljuili v razrede uporabniških vmesnikov. Na koncu so razvili še okna za prikaz poroil in statistik o opravljenih procesih ter postopoma dodajali še druge funkcionalnosti, ki niso imele kljunega pomena za delovanje programa. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 70

77 Slika 27: Okno za modeliranje poslovnega procesa 5.4. Implementacija Faza implementacije je zadnja faza življenjskega cikla razvoja informacijskega sistema in v tej fazi naredimo plan prenosa programa v produkcijo. e želimo uporabiti diagrame UML je zelo primerno uporabiti diagram komponent in diagram namestitve. Z diagramom namestitve se prikaže fizini prikaz novega sistema ob prenosu v realni svet, pri emer ponazorimo strukturo strojne in programske opreme v realnem asu. Namen diagrama komponent pa je prikazati implementacijo naše rešitve. Komponente so sestavljene iz poljubnega števila razredov, ki so vkljuene v program. Pred implementacijo razredov je potrebno za vsakega doloiti, kje bo fizino implementiran. Za popolno delovanje izdelanega modula na strani klienta je bilo potrebno namestiti ogrodje Microsoft.NET 2.0, program za Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 71

78 povezavo s podatkovno zbirko, registrirati knjižnice modula za obvladovanje poslovnih procesov ter namestiti novo razliico programa LEA. V tej fazi so v produkcijsko podatkovno zbirko prenesli strukturo tabel in osnovne podatke. Po namestitvi programov na raunalnike je sledilo izobraževanje uporabnikov in prvo testiranje programa v realnem okolju. Združevanje programskega orodja Visual Studio 6.0 in Visual Studio.NET 2005 Program LEA so zaeli razvijati konec leta 2004 in so se odloili za razvoj programa v programskem orodju Visual Basic 6.0. Programsko orodje so izbrali predvsem iz praktinih razlogov, saj so imeli veliko ve izkušenj in znanja na podroju razvoja programskih rešitev, hkrati pa se je razliica.net zaela v tistem asu šele dobro uveljavljati v praksi. Ko so prieli z razvojem modula za obvladovanje poslovnih procesov, je podjetje Microsoft že objavilo novo razliico program Visual Studio.NET 2005, ki vsebuje vrsto izboljšav. Leto pred tem je Microsoft tudi objavil, da bo prenehal s spreminjanjem in dopolnjevanjem starejših razliic..net platforma je sestavljena iz.net ogrodja, na katerem temelji razvoj Microsoftovih programskih jezikov. Razvijalci poskušamo preiti na novejše orodje, pri emer je potrebno razumeti koncepte objektnega programiranja in.net ogrodja. Še veji problem kot znanje razvijalcev predstavlja nadaljnji razvoj programov, ki so razviti v stari razliici in se trenutno še uporabljajo. Težav pri prehodu na novo programsko orodje so se zavedali tudi v Microsoftu, zato so morali zagotoviti možnost uporabe starejših komponent v.net okolju. Zato je Microsoft pripravil dve možni rešitvi: s pomojo arovnika pretvorimo programsko kodo iz starejših v novo razliico. Pri tem se veina programske kode samodejno pretvori, medtem ko je pri bolj kompleksnih ukazih potrebno rono dopolnjevanje; uporaba številnih povezovalnih mehanizmov, ki omogoajo delovanje programa razvitega v WIN32 okolju in hkratno uporabo knjižnic, razvitih v.net okolju. Menijo, da je prvo možnost najbolje uporabiti pri manjših projektih z osnovami objektnega programiranja. Sicer je bolje uporabiti drugo rešitev, saj se s tem popolnoma obdrži delovanje starega programa in se novejše module le dodaja. Tudi za konnega uporabnika je ta rešitev primernejša, saj se uporabniški vmesniki ne spremenijo. Prav tako je z vidika stroškov razvijalcev primernejša druga rešitev. Nove funkcije programa se razvije v.net okolju ter se jih doda k starejši razliici programa. Tako obstajata dve tehnologiji - COM Interop in PInvoke, ki vsebujeta orodja za uvažanje knjižninih tipov COM in lahko ustvarita klicljive izvajalne ovojnice, s katerim se poveže.net, ko uporablja predmete COM (Vir: Razumeti Microsoft.NET, 2002, str. 153). Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 72

79 Komponente iz.net okolja je možno uporabiti preko objekta»com Callable Wrapper«(v nadaljevanju CCW). Ta objekt združuje vse COM vmesnike, ki jih lahko klient najde. Obiajno preko vmesnika IUnknown, ki predstavlja glavni vmesnik ter vmesnika IDispetch, ki omogoa dostop do objekta preko programskih jezikov kot so VBScript ali kasnejšega povezovanje in starejših razliic Visual Basic. Glavne naloge CCW so: identifikacija objektov, s imer nastane vedno vsaj ena instanca CCW za vsako instanco.net komponente; skrb za išenje pomnilnika oz. obnavljanje pomnilniškega prostora ter oblikovanje.net izjeme v kodo HRESULT 15, ko metode kliejo nazaj COM klienta. IUnknown COM klient IDisptach IPerson CCW.NET komponenta Slika 28: COM Callable Wrapper objekt (Vir: Francesco Balena, 2004, str. 1156). Da lahko.net ogrodje kreira primeren CCW objekt, moramo kreirati knjižnico s konnico»tlb«za vsak objekt, ki ga želimo objaviti v COM svetu. To lahko naredimo s pomojo nekaterih orodij v.net SDK, tako da izvozimo.net zbirko 16 v»type Library«. Program RegAsm.exe prevede vsa imena iz zbirke in registrira vse razrede ter jih vkljui v sistemski register. To lahko naredimo z ukazom: REGASM sample.dll /tlb:netsample.tlb e na klientovi strani ni na uporabo.net zbirke ali ni bila registrirana v GAC 17, je potrebno izvesti še en ukaz, ki doda vpis kode v register. REGASM sample.dll /codebase (Vir: Francesco Balena, 2004, str ). 15 HRESULT je podatkovni tip, ki se uporablja za doloitev statusa pri izvajanju operacij Microsoftovih COM objektov (Vir: URL: datum vpogleda ). 16.NET zbirka ang..net assembly - je zbirka enega ali ve izvršljivega ali neizvršljivega modula, z loginega vidika pa je najmanjša enota, ki se lahko ponovno uporabi, ima svojo verzijo in svoje podroje vidnosti znotraj.net aplikacij. 17 GAC angleški izraz Global Assembly Cache. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 73

80 6. Analiza kriterijev uspeha, kritinih dejavnikov in tveganosti vpeljave programske rešitve Implementacija sistema v organizacijo je precejšen projekt, zato je potrebno že vnaprej doloiti strategijo in plan uvedbe. Pomembno je narediti SWOT analizo, s pomojo katere predvidimo prednosti, pomanjkljivosti, priložnosti in grožnje projekta. Beseda SWOT izhaja iz angleških besed Strengths = prednosti, Weaknesses = slabosti, Opportunities = možnosti in Threats = grožnje. Pri SWOT analizi nam pomagajo naslednja vprašanja za posamezna podroja: Prednosti: Katere so prednosti? Kaj je tisto kar delaš dobro? Katere pomembne vire imaš? Kje drugi uporabniki vidijo tvoje prednosti? Slabosti: Kaj lahko izboljšaš? Kaj delaš slabo? esa bi se moral izogibati? Možnosti: Katere možnosti se ti kažejo? Kateri so trenutni trendi, ki jih znamo izkoristiti? Grožnje: S katerimi ovirami se sreuješ? Kaj dela tvoja konkurenca? Ali sprememba tehnologije ogroža tvoj položaj? Ali lahko katera lastnost ogrozi tvoje poslovanje? Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 74

81 Prednosti: veji nadzor nad dokumenti pomembne dokumente v organizaciji lahko raunalniško nadzorujemo ter se nam težje zgodi, da bi kakšen pomemben dokument spregledali; dokumenti v elektronski obliki postanejo dinamini papirne dokumente lahko popolnoma nadomestimo z elektronskimi dokumenti; dokumenti hitreje krožijo po organizaciji procesi v organizaciji ne poznajo meja oddelkov, sektorjev, kar omogoa tudi elektronsko vodenje dokumentov. as pošiljanja dokumenta v drug oddelek je zanemarljivo kratek; zmanjšana izguba dokumentov ko dokumenti v papirni obliki krožijo po organizaciji, se lahko izgubijo, medtem ko so elektronski dokumenti vedno shranjeni v repozitoriju; dokumenti ne akajo na pisalnih mizah za obdelavo dokumente v elektronski obliki akajo v elektronskem poštnem predalu in so razvršeni po stopnji prioritete oz. po asu izvora, tako da pridejo pravoasno v obdelavo. e je posamezni uporabnik preobremenjen, je dokument v elektronski obliki lažje poslati drugemu uporabniku kot razporejati dokumente v papirni obliki; delo z dokumenti poteka nemoteno tudi ko smo odsotni program omogoa doloitev pooblašenca, ki je sposoben prevzeti delo ali del dela, ko je uporabnik odsoten z dela. V asu odsotnosti program samodejno pošilja dokumente uporabnika, ki ga nadomešamo: organizacijo zanemo obravnavati z vidika procesne organizacije program ne zahteva reorganizacije poslovanja, je pa potrebno za doloitev poslovnih procesov poznati vidik procesne organizacije; sistem za obvladovanje dokumentov je brez modula za upravljanje poslovnih procesov lahko nepregleden, saj ne vemo kaj se dogaja z dokumenti modul za upravljanje dokumentov je nekakšen elektronski arhiv, kjer so dokumenti predvsem statini elementi, medtem ko z modulom za obvladovanje poslovnih procesov dokumente upravljamo po želji. Dokumente ne shranimo v elektronsko obliko zato, da bomo izkoristili prodnosti elektronskega hranjenja dokumentov, temve jih že v zaetni fazi pretvorimo v elektronsko obliko ter jih nato obdelujemo s pomojo raunalnika; zmanjšuje porabljeni as, ki ga dokumenti porabijo pri»akanju v škatlah«- dokumenti se nabirajo v elektronskem poštnem predalu in tako imamo vedno pregled nad obsegom neopravljenega dela in roki izpolnitve naloge; zmanjšuje as, ki ga porabi dokument pri prenosu med oddelki s papirno obdelavo dokumentov je potrebno precej asa, da pridejo dokumenti iz enega oddelka v drug oddelek, medtem ko je as prenosa elektronskega dokumenta zanemarljiv; zmanjšuje as, ki ga potrebujejo uporabniki za zbiranje informacij raziskave kažejo, da zaposleni v pisarnah porabijo precej asa za iskanje informacij, ki so Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 75

82 shranjene v dokumentih. S pravilno postavljenim sistemom za upravljanje dokumentov lahko dokument pridobimo v nekaj sekundah. Slabosti: modul ne more funkcionirati samostojno modul za upravljanje poslovnih procesov se navezuje na modul za upravljanje dokumentov in je kot samostojen modul brez pomena; za delo potrebujemo raunalnik e želimo v organizacijo uvesti sistem za obvladovanje poslovnih procesov, potrebujejo vsi zaposleni raunalnik, na katerem bodo uporabljali program; program mora biti namešen na vsakem raunalniku program je sestavljen kot okenska aplikacija, ki za svoje delovanje potrebuje namestitev doloenih knjižnic. Za uspešno uporabo programa je potrebno predhodno namestiti program; potrebujemo zmogljiv strežnik za arhiviranje dokumentov dokumenti in ostali meta podatki so shranjeni na podatkovnem strežniku SQL Server Ob vejem številu konnih uporabnikov ter razširjeni uporabi programa je za nemoteno delovanje potreben zmogljiv strežnik; omejitev operacijskega sistema program je razvit v razvojnem orodju Visual Studio.NET 2005, ki ga podpira podjetje Microsoft. Programe, razvite s takšnim orodjem je mogoe uporabiti le na Windows platformah, hkrati pa mora biti na raunalniku namešeno še ogrodje.net 2.0; preobremenjenost mreže vsi podatki o poslovanju in dokumenti se prenašajo po lokalni mreži, ki mora omogoati hiter in zanesljiv prenos podatkov; velika koliina dokumentov oteži iskanje želenega dokumenta dokumenti so v programu vezani na doloenega klienta ter razvršeni tudi po drugih kriterijih (izvor dokumenta, as nastanka itd.) e imamo za enega klienta veje število dokumentov, pride do delne nepreglednosti. Grožnje: programske rešitve ne uporabljajo vsi zaposleni glavni razlog za vpeljavo EDMS sistema za upravljanje dokumentov ter modula za obvladovanje poslovnih procesov je veji nadzor nad dokumenti. e gredo dokumenti v organizaciji še vedno mimo novega sistema, smo rešitev slabo implementirali; spremembe pri poslovanju z uvedbo sistema se prej ali slej zanejo spreminjati poslovni procesi v organizaciji. S tem pa zanemo spreminjati tudi delovne postopke, ki so jih zaposleni navajeni, kar ima lahko tudi negativen uinek na moralo zaposlenih; raunalniška nepismenost za uspešno implementacijo sistema je potrebno znanje uporabe raunalnikov s strani uporabnikov. Težave lahko povzroijo predvsem Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 76

83 starejši zaposleni, ki pri dosedanjem opravljanju poklica niso potrebovali raunalnika, zaradi esar se lahko zgodi, da bodo še naprej vodili dokumente na stari nain; podjetje ima ve dislociranih lokacij organizacije, ki imajo ve enot na oddaljenih lokacijah, imajo lahko težave pri povezovanju na skupno podatkovno zbirko, še zlasti pri prenosu dokumentov v repozitorij. Gre namre za okensko in ne spletno aplikacijo, problem pa je lahko tudi hitrost prenosa podatkov po medmrežju; premajhna podpora vodilnih, da bi bila rešitev sprejeta e želimo v organizacijo vpeljati vejo spremembo, je podpora vodilnih v organizaciji kljunega pomena, saj se sicer lahko uvedba novega sistema izjalovi; nezaupanje posamezniki v organizaciji ne zaupajo v raunalniške rešitve, zaradi esar vodijo vzporedno še stari sistem; nedisciplina doloanje standardov pomeni doloiti natanne smernice, po katerih morajo zaposleni delovati. Te smernice niso nekaj fiksnega in se lahko skozi as spreminjajo, kljub temu pa sistem od zaposlenih zahteva disciplino; težko je doloiti sistem za vodenje kontrole dokumentov ISO standardi zahtevajo, da doloimo kriterije za merjenje, kar je pri vodenju kontrole dokumentov zelo težko, saj se posamezni primeri obdelave med seboj lahko precej razlikujejo; neprijazno orodje za konnega uporabnika glavni namen uporabe raunalnikov je v tem, da uporabniku olajšajo delo in tako enako delo opravi z manj napora. Kljub informatizaciji pa lahko doloeni programi zaradi kompleksnih postopkov poveajo zapletenost uporabe. Možnosti: razširitev funkcionalnosti programa modul za opravljanje poslovnih procesov ima zgrajeno ogrodje, ki predstavlja osnovo za nadaljnje delo. V modul je mogoe vkljuiti še številne kriterije kot jih zahtevajo ISO standardi, možna je razširitev programa na druge vrste dokumentov; vkljuitev modula v drugih programskih orodjih eprav se sedaj modul uporablja kot samostojno knjižnico, ki je vkljuena v programsko orodje Visual Basic 6.0, je modul mogoe uporabiti v drugih razvojnih orodjih, ki podpirajo uporabo COM komponent; povezovanje programa z drugimi programi, ki vsebujejo kljune podatke o organizaciji program za upravljanje dokumentov in upravljanje poslovnih procesov je možno uporabiti v povezavi s programom Datalab Phanteon, ki ga v podjetju uporabljamo v raunovodstvu; specifikacija procesov po ISO standardih specifikacija po ISO standardih mora vsebovati tri obvezna podroja: splošne podatke o procesu, kratek opis procesa in poslovni tok procesa. Veina teh podatkov se že sedaj vnaša v program, tako da bi bilo potrebno samo primerno oblikovati izpis poroila; Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 77

84 osnova za izboljševanje procesov procese lahko izboljšujemo le, e jih kontroliramo, analiziramo ter na podlagi prouevanja korakov znotraj procesa izpopolnjujemo; razširitev modula na podporo sporoil v organizacijah se nekateri procesi odvijajo brez papirne dokumentacije ter jih tako v trenutnem sistemu ne moremo obravnavati. V takih primerih je idealno, e ima uporabnik možnost vnesti sporoilo ter mu doloiti dodatne lastnosti, kot predviden as izvedbe, stopnja prioritete in izvajalca; program se uporablja za pripravo kratkoronega plana modul za obvladovanje poslovnih procesov pokriva obdelavo osnovne papirne dokumentacije in e mu dodamo še sporoila, lahko enostavno naredimo seznam nalog, ki jih mora uporabnik narediti v roku enega tedna. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 78

85 7. Primerjava objektno orientiranega pristopa v primerjavi s prototipnim pristopom Pomen in zaporedje razvojnih faz se med pristopoma bistveno razlikuje, saj je pri prototipnem pristopu najveji poudarek na kodiranju in se zelo malo asa nameni zaetnima fazama - analizi in oblikovanju. Pri prototipnem pristopu želimo zelo hitro priti do nekega izdelka, ki ga bomo lahko pokazali konnemu uporabniku ter nato nadaljnje razvijali program glede na uporabnikove zahteve. Pri objektnem pristopu pa smo ve kot polovico asa porabili v fazah opisa zahtev, analize in oblikovanje. Pri slednjem pristopu v fazo kodiranja preidemo zelo pozno, ko že dobro poznamo zahteve konnega uporabnika. Doslej nismo imeli veliko izkušenj z uporabo objektno orientiranega pristopa, saj smo veino aplikacij naredili po prototipnem pristopu. Glavni razlog za izbiro prototipnega pristopa je vsekakor slabo definirana problematika programiranja. Konni uporabniki oz. stranke ne razumejo, da je izdelovanje programov proces, v katerem morajo sodelovati vsi uporabniki, ne le razvijalci. Hkrati pa veina strank, ki želi kupiti oz. potrebuje nov program, ne pozna dovolj dobro niti delovanja svojega podroja. Pri prototipnem pristopu stranke dobivajo ideje, ko uporabljajo prototipni program ali del programa. Tone podatke o zahtevah konnega uporabnika dobimo tako lahko zelo pozno, kar pa razvijalcem pri razvoju povzroi veliko težav, saj se vasih poslovna logika popolnoma spremeni in je nove spremembe težko in predvsem drago vpeljati v že zgrajen sistem. Zato se pri prototipnem pristopu dogaja, da se program ali del programa naredi ponovno. V primerjavi z objektno orientiranim pristopom se veliko ve asa nameni zaetnim fazam razvoja. Z zbiranjem idej in zahtev se zane oblikovati slika celotnega programa, s imer je bistveno manjša verjetnost, da bomo kakšno kljuno funkcionalnost doloili narobe. V zaetku razvoja aplikacije smo imeli precej težav s pripravo designa, saj je potrebno drugano razmišljanje kot pri dogodkovnem programiranju 18, kamor lahko uvrstimo programski jezik Visual Basic 6.0, ki sicer ima nekatere osnovne lastnosti objektnega jezika, vendar pa ne moremo uporabiti dedovanja in polimorfizma. Pri objektno orientiranem oblikovanju moramo imeti v mislih vedno osnovno idejo objektnega programiranja - program je sestavljen iz ve neodvisnih gradnikov, ki jih med seboj zlagamo. Z dobrim oblikovanjem programa dosežemo, da so metode napisane na enem mestu in jih lahko uporabimo vekrat, kar nam omogoa lažje vzdrževanje programske kode. Oblika programa ni odvisna od izbire pristopa, saj imamo lahko tudi pri objektnem programiranju narejen slab design. Vseeno pa je veliko lažje narediti ustrezen design, ko dobro poznamo podroje razvoja. 18 Dogodkovno programiranje ang. Event-driven programming je programiranje, pri katerem je program sestavljen iz skupin stavkov ali ukazov, ki doloajo, kako se program odziva na dogodke, ki jih sproži uporabnik ali operacijski sistem (Vir: Pahor, 2002, str ). Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 79

86 Za obvladovanje kompleksnejših sistemov je primernejši objektno orientiran pristop, kjer posamezne dele programa razbijemo in jih obravnavamo loeno. Posamezni del programa lahko gledamo kot samostojni modul in s tem bistveno zmanjšamo kompleksnost problema. Takšen nain programiranja je enostavnejši tudi za programerje, saj ni potrebno razumeti celotne logike programa, vendar morajo poznati le nekatere lastnosti in metode objektov ter rezultate, ki jih doloene metode vraajo. Ko na projektu delamo dalj asa oz. sodeluje pri njem ve razvijalcev, ima kljuni pomen pri razvoju vsebinska in tehnina dokumentacija. Pri obeh pristopih je potrebno narediti dokumentacijo, pri emer se pri objektno orientiranem programiranju tehnino dokumentacijo oblikuje soasno z razvojem sistema in imamo ob zakljuku programa pripravljeno vso dokumentacijo. Pri prototipnem pristopu pa ravno zaradi slabo oblikovane zasnove ni smiselno pripraviti konne tehnine dokumentacije, saj se delovanje programa v fazah testiranja še dopolnjuje. Zato se najpogosteje napiše tehnino dokumentacijo na koncu, ko se program že uporablja in je ta namenjena vzdrževanju in kasnejšemu dodajanju. Po naši oceni je tudi vloga konnega uporabnika pri kreiranju dokumentacije nekoliko drugana. Pri obeh pristopih je konni uporabnik vkljuen v testiranje, medtem ko pri objektnem pristopu igra pomembno vlogo tudi v zaetnih fazah razvoja, ko se pripravljajo zahteve. Za pripravo dokumentacije lahko uporabimo CASE orodje, ki nam prek razlinih grafov in poroil to omogoa. Dolgorono se razlikuje tudi as razvoja: pri prototipnem pristopu obiajno že v zgodnji fazi dobimo nek izdelek, medtem ko je pri objektnem pristopu v prvih fazah veliko dela usmerjenega v oblikovanje ogrodja. S primerno oblikovanim ogrodjem pa v nadaljevanju hitreje sestavimo želene funkcionalnosti, saj uporabimo že pripravljene dele programa. Kateri pristop izberemo, je odvisno od asovnega okvira projekta, kompleksnosti in sredstev, ki jih imamo na razpolago za razvoj. Prva dva kriterija se naredita na podlagi zahtev konnega uporabnika in ju je zelo težko tono doloiti, e niti uporabnik niti razvijalec ne poznata dovolj dobro problematike. To je tudi eden od glavnih razlogov, da se veliko število projektov kona neuspešno oz. se asovni roki izdelave programa podaljšajo. Pri majhnih in preprostih sistemih je še vedno bolje uporabiti prototipni pristop, saj so sicer stroški razvoja previsoki. Vendar je v praksi v zaetni fazi težko natanno doloiti ali bo šlo za majhen projekt ali se bo zaradi zanimanja konnih uporabnikov ta razširil. Ko se obseg projekta bistveno povea od prvotno zartane velikosti, je smiselno program loiti na manjše dele ter doloeno programsko kodo napisati ponovno. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 80

87 8. Zakljuek Glavna smernica magistrske naloge je bila prikazati postopek razvoja programskega modula za obvladovanje poslovnih procesov s poudarkom na pretoku dokumentov. Modul je v celoti razvit s pomojo programskega orodja Visual Basic.NET in predstavlja nov modul programa LEA. Z uporabo modula v organizacijah lažje zagotovimo, da bodo dokumenti z enakimi lastnostmi naredili enak življenjski cikel. Poleg tega pa v organizaciji obdelujemo elektronske dokumente, kar prinaša celo vrsto prednosti. Zaradi uporabe razlinega razvojnega orodja pri izdelavi osnovnega programa LEA in tega modula je bilo potrebno modul za obvladovanje poslovnih procesov pripraviti kot COM komponento. Tako pripravljeno knjižnico registriramo na raunalniku in jo lahko uporabimo tudi v orodju Visual Basic 6.0. Najveje težave pri takem programiranju predstavljajo odkrivanje napak med izvajanjem 19, ki nastanejo pri neposrednem povezovanju modulov. Razvoj programa je potekal po objektno orientiranem pristopu in smo kreirali diagrame UML, ki so tudi v praksi velikokrat uporabljeni. UML je uradno nastal leta 1997, odtlej pa se ga dopolnjuje tako z novimi diagrami, obstojeim diagramom pa se dodaja nove lastnosti. Glavna prednost UML je vsekakor v tem, da vsebuje splošne standarde za modeliranje, ki so sprejeti v industriji. Zaradi njegove vsesplošne razširjenosti je danes na trgu precej orodij, ki podpirajo razvoj programskih rešitev s pomojo modeliranja diagramov UML. Ker se UML stalno spreminja in dopolnjuje, doloena orodja ne podpirajo vseh funkcionalnosti, ki so doloene po UML specifikaciji. Pred zaetkom razvoja je bilo zato potrebno pridobiti program, s katerim bomo enostavno modelirali diagrame ter bo podpiral razvoj v programskem jeziku Visual Basic.NET. Po testiranju razlinih orodij smo se odloili za nakup programa Visual Paradigm for UML - Modeler Edition, ki je prijazen za uporabo, hkrati pa omogoa izdelavo vseh diagramov UML 2.0. Program pokriva skoraj vse lastnosti in zahteve UML specifikacije. Pomembna prednost UML je tudi v tem, da skozi razline diagrame uporabljamo enako notacijo in tako ne izgubljamo informacij med prehodi v razline diagrame oz. faze. Hkrati zaradi širokega podroja uporabe UML specifikacija postaja preve obsežna in jo uporabniki vedno težje razumemo. Njena prednost je, da so diagrami UML dinamini modeli, na katerih prikažemo le lastnosti, ki nas zanimajo, ostale pa lahko zanemarimo. Obenem diagrame UML lahko rišemo tudi kot rone skice in pri tem uporabimo prav vse lastnosti UML. V fazi analize in designa smo tako pogosto pred zaetkom razvoja najprej pripravili rono skico. 19 Napaka med izvajanjem (angleški izraz run-time error) napaka v obdelavi podatkov, ki se zgodi med izvajanjem programa in ne med prevajanjem ali nalaganjem programa ali pri hranjenju programa v dodatnem hranilniku (Vir: Pahor, 2002, str. 290). Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 81

88 UML 2.0 vsebuje trinajst razlinih diagramov, ki jih v grobem delimo na diagrame obnašanja in strukturne diagrame. Po izkušnjah, pridobljenih pri izgradnji sistema, je najbolj uporaben diagram primerov uporabe. Ta diagram je tudi ostalim uporabnikom, ki sodelujejo v procesu, najbolj razumljiv, saj predstavlja delovanje programa ter je napisan v naravnem jeziku. Diagrami primerov uporabe pa niso primerni le za zajem zahtev konnih uporabnikov, temve se uporabljajo tudi pri testiranju programa ter kasneje pri pisanju navodil konnim uporabnikom. Pri razvoju so bili uporabljeni tudi razredni diagrami, s katerimi prikažemo statino strukturo elementov sistema in povezave med njimi. Razredni diagrami predstavljajo osnovo za pisanje programske kode in so eni kljunih diagramov za programerje. Pri bolj kompleksnih in kljunih podrojih programa je smiselno podrobno prikazati primere uporabe z enim od diagramov obnašanja. Za detajlni prikaz smo zato uporabljali diagram zaporedja, vasih pa tudi diagram sodelovanja. Celotno zgradbo sistema smo ponazorili z diagramom paketov. Ostali diagrami, uporabljeni v fazi analize in oblikovanja, so diagram stanja ter diagram aktivnosti. V zadnji fazi razvoja smo s pomojo diagrama komponent prikazali umestitev novega modula v program LEA. Kot zagotavljajo avtorji je UML neodvisen od programskega jezika in izbranega objektnega pristopa. Omejitve, ki jih moramo upoštevati pri razvoju diagramov UML, so na strani programskega paketa, s katerim rišemo diagrame, ter programskih jezikov, ki niso popolnoma objektno orientirani. Pri razvoju smo uporabili programski orodji Visual Basic 6.0 (ta ima kar precej omejitev, saj bi ga po klasifikaciji uvrstili med objektne jezike brez dedovanja in polimorfizma), ter Visual Basic.NET 2005 (omejitev le ta, da ne podpira vekratnega dedovanja). e želimo uporabiti UML, je smiselno izbrati enega od objektno orientiranih programskih jezikov, saj se v nasprotnem primeru diagrami UML ne ujemajo popolnoma s programsko kodo. Veliko težavo pri projektih predstavlja usklajevanje modelov in programske kode. CASE orodja to sinhronizacijo do nekatere mere omogoajo (predvsem strukturni diagrami), medtem ko je celo vrsto diagramov obnašanja potrebno rono popraviti, e želimo imeti sinhronizirane podatke o modelu. Pri vejih sistemih, ki se stalno dopolnjujejo, lahko hitro pride do neskladja in je tehnina dokumentacija napana ter tako neuporabna. Ko uporabljamo UML, se moramo zavedati, da je naš glavni cilj še vedno izdelati delujoo programsko rešitev in ne izdelujemo zgolj tehnine dokumentacije. Stranko na drugi strani zanima predvsem konni program ne pa kakšna bo tehnina dokumentacija programa. Stroga uporaba UML celoten proces precej upoasni in s tem podaljša rok izvedbe, kar posledino povea stroške izdelave. Kateri diagrami so primerni in jih je smiselno uporabiti pri doloenih projektih težko izvemo samo z branjem knjig in literature, ampak sposobnost presoje pridobimo z izkušnjami. Za zaetek je najlažje, da uporabimo zdravo pamet ter presodimo ali bomo s pomojo diagrama zajeli pomembne segmente, ki so kljuni za razvoj programa. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 82

89 Diagrami UML so relativno novi in se še stalno razvijajo, pri emer trenutna praznina ostaja predvsem na podroju oblikovanja uporabniških vmesnikov. S pomojo diagramov UML ta trenutek ni mogoe oblikovati designa uporabniškega vmesnika oz. doloiti povezave med njimi. Konni uporabniki ne razmišljajo kot razvijalci in si sistem najlažje predstavljajo, e vidijo uporabniške vmesnike. Doloeni diagrami UML so preve abstraktni, da bi jih konni uporabnik, ki ne pozna osnov informatike in razvoja programskih rešitev, lahko razumel. V zadnjih desetih letih razvoja diagramov UML je bilo napisanih nekaj knjig in druge literature o uporabi UML v praksi. Ker razvijalci poznajo le UML notacijo, tudi veina knjig vsebuje le UML notacijo ter se ne spuša v problematiko pri izdelavi uporabniških vmesnikov, modeliranju oz. doloanju poslovnih pravil. Le nekaj knjig je napisanih tako, da prikazujejo smiselno povezanost razlinih diagramov v fazah razvoja in programske kode. Druga pomanjkljivost pa so enostavni primeri, ki so navedeni v knjigah, s katerimi se nauimo grafino izdelati zelo preproste dele programske kode, medtem ko kompleksnejše primere le redko sreamo. e primerjamo uporabo objektnega pristopa z UML in prototipni pristop pri razvoju informacijskih sistemov, ugotovimo kar nekaj kljunih razlik. Pri objektnem pristopu ter hkratni uporabi UML je bistveno veji poudarek na analizi in oblikovanju, medtem ko pri prototipnem pristopu zelo zgodaj preidemo h kodiranju in izdelavi programa. Za pripravo dobre zasnove za programiranje je kljuno, da so problemi primerno specificirani. Pri slabo popisanih zahtevah konnih uporabnikov je veliko bolj primerno uporabiti prototipni pristop, saj bo uporabnik ob prvem testiranju dobil predstavo ali prototip, ki ustreza njegovim zahtevam. Razvoj vejih informacijskih sistemov zahteva sistematini pristop ter uporabo doloene metodologije. Ko uporabljamo objektno orientirane programske jezike, so diagrami UML v praksi najvekrat uporabljeni. S primernim oblikovanjem zasnove precej zmanjšamo zapletenost ter poveamo preglednost programa. Posamezne dele programa razdelimo na samostojne enote in jih obravnavamo loeno. S tem tudi programerjem olajšamo delo pri razvoju in kasnejšemu odpravljanju ter iskanju napak. Na drugi strani pa je pri manjših programih veliko bolj primeren prototipni pristop, saj bi bili sicer stroški razvoja previsoki. Izdelovanje tehnine dokumentacije se pri prototipnem razvoju zaradi slabo definiranih problemov obiajno piše na koncu, ko prototip ustreza našim zahtevam ter je namenjena predvsem vzdrževanju. Pri uporabi diagramov UML pa se dokumentacijo ustvarja prek razlinih diagramov skozi razvojne faze in se uporablja že pri razvoju programske rešitve. Programski modul za obvladovanje poslovnih procesov je razdeljen na dva glavna dela. Prvi del zajema deklariranje poslovnih procesov s pomojo diagramov poteka ter administracijo splošnih nastavitev, ki se kasneje uporabljajo v programu. Ta del je namenjen Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 83

90 zaposlenim v organizaciji, ki delovanje organizacije dobro poznajo ter je po uporabnikovih besedah nekoliko bolj zapleten za uporabo v primerjavi z drugim delom programa. Postopek kreiranja poslovnega procesa je smiselno speljan in preko funkcije preverjanja pravilnosti izdelanega procesa doloa uporabniku smernice izgradnje. Konnega uporabnika moti, da procesa ne more uporabljati, dokler postopek ne ustreza minimalnim zahtevam in je zato potrebno v zaetni fazi vložiti ve truda. Drugi del programa zaznamuje sprejemanje in pošiljanje dokumentov in sporoil ter prikaz poroil, ki je namenjen vsem zaposlenim v organizaciji. Uporabniški vmesniki za pošiljanje in sprejemanje dokumentov so preprosti za uporabo, kljub temu pa bi bilo potrebno narediti spremembe na povezanosti modula in programa LEA. Po mnenju uporabnikov bi bilo potrebno dati ve poudarka opozarjanju oz. opominjanju, e se proces ne odvija po želenih smernicah oz. e uporabnik ne opravi svojega dela v predvidenem asu. Na koncu se moramo zavedati, da uporaba diagramov UML pri razvoju podaljšuje celotni as razvoja, saj moramo najprej poznati orodje za risanje diagramov, hkrati pa je potrebno logiko, ki je predstavljena na diagramih, prenesti v programski jezik. Doloena CASE orodja sicer znajo pripraviti osnovne lastnosti in metode razredov, celotne logike programa pa ni mogoe napisali v CASE orodju in nato preko generatorjev programskih kod prenesti v program. Glavna prednost CASE orodij je v uporabi vzvratnega programiranja, s pomojo katerega pridemo do tehnine dokumentacije ter doloitvi diagramov, ki so kljuni za razvoj konne rešitve. Kljub nekaterim pomanjkljivostim je pri razvoju programskih rešitev smiselno uporabljati diagrame UML. Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 84

91 9. Literatura in viri Literatura [1] Ambler W. Scott; The Object Primer Agile Model-Driven Development with UML 2.0, Cambridge: Cambridge University Press: 2004 [2] Ambler W. Scott; The Elements of UML 2.0 Style, New York, Cambridge University Press: 2005 [3] Balena Francesco; Programming Microsoft Visual Basic.NET Version 2003, Washington, Microsoft Press: 2004 [4] Barwell Fred, Case Richard, Forgey Bill, Hollis Billy, McCarthy Tim, Pinnock Jonathan, Blair Richard, Crossland Jonathan, Hankison Whitney, Lhotka Rockford, Narkiewicz Jan, Ramachandran Rama, Reynolds Matthew, Roth John, Sheldon Bill, Sempf Bill; Professional VB.NET 2nd Edition, Birmingham, Wrox Press Ltd: 2002 [5] Bielawski Larry, Boyle Jim; Electronic Document Management System, Upper Saddle River, Prentice Hall PTR Corporation: 1997 [6] Bruegge Bernd, Dutoit H. Allen; Object Oriented Software Engeneering Using UML, Patterns, and Java, Združene države Amerike: Pearson Prentice Hall, 2004 [7] Cockburn Alistair; Writing Effective Use Cases, New Jersey: Addison-Wesley, 2001 [8] Deitel J. Paul, Deitel M. Harvey; Visual Basic 2005 for Programmers Second Edition, Pearson Education Inc., New Jersey: 2006 [9] DePetrillo Bart A.; Razumeti Microsoft.NET; Depedrillo [prevod Pasadena], Ljubljana: 2002 [10] Dokumentacija za vodenje raunov, Interna dokumentacija Laser Computer d.o.o.: 2006 [11] Evjen Bill, Lhotka Rockford, Hollis Billy, Sheldon Bill, Sharkey Kent, McCarthy Tim, Ramachandran Rama; Professional VB 2005: Wiley Publishing Inc., Indianapolis: 2006 [12] Filev Andrew, Loton Tony, McNeish Kevin, Schoellmann Ben, Slater John, Wu G. Chaur; Professional UML with Visual Studio.NET Unmasking Visio for Enterprise Architects: Wiley Publishing, Indianapolis: 2003 [13] Fowler Martin; UML Distilled: A brief Guide to the Standard Object Modeling Language, Boston: Addison Wesley Corporation, 2004 [14] Hansen John Erik, Thomsen Carsten; Enterprise Development with Visual Studio.NET, UML, and MSF, Berkeley: Apress, 2004 [15] Hammer Michael; Preurejanje podjetja: Manifest revolucije v poslovanju, Ljubljana: Gospodarski vestnik, 1995 [16] ISO 9000: uvod in podporni paket za sistem: nasveti in informacije o posodobitvah ISO 9001 in ISO 9004: (ISO TC/176/SC2/N 544 R). Napotki za procesni pristop v sistemu vodenja kakovosti = (Guidance on the process approach to quality management systems): Slovenski inštitut za standardizacijo, Ljubljana: Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 85

92 [17] ISO 9000: Uvod in podporni paket za sistem Nasveti in informacije o posodobitvah ISO 9001 in ISO 9004 (ISO TC/176/SC 2/N 525 R). Napotki glede zahtev za dokumentacijo ISO 9001:2000: Slovenski inštitut za standardizacijo, Ljubljana: [18] Ivanko Štefan; Strukture in procesi v organizaciji, Ljubljana: Visoka upravna šola, Univerza v Ljubljani, 2000 [19] Ivanko Štefan, Kajzer Štefan, Kanjuo-Mrela Aleksandra, Kavi Bogdan, Kova Jure, Miheli Miran, Mulej Matjaž, Ovsenik Jože, Rozman Rudi, Urši Duško, Vila Anton; Sodobna razlaga organizacije, Kranj: Moderna organizacija, 1999 [20] Kendall Scott; UML Explained: Addison-Wesley, New York: 2001 [21] Kovai Andrej, Jakli Jurij, Štemberger, Indihar Mojca, Groznik Aleš; Prenova in informatizacija poslovanja, Ljubljana: Ekonomska fakulteta v Ljubljani, 2004 [22] Mernik Marjan, Žumer Viljem; Programski jeziki, Maribor: Fakulteta za elektrotehniko, raunalništvo in informatiko, Inštitut za raunalništvo, 2003 [23] Mesojec Uros, Fabjan Borut, Java 2: Temelji programiranja, Ljubljana: 2004 [24] Miles Russ, Hamilton Kim; Learning UML 2.0, Sebastopol, O'Reilly: 2006 [25] O'Docherty Mike; Object-Oriented Analysis and Design: understanding system development with UML 2.0: John Wiley & Sons Ltd, West Sussex: 2005 [26] Pahor David, Drobni Matija, Batagelj Vladimir, Bratina Simon, Djurdji Vladimir, Gabrijeli Primož, Gams Matjaž, Klanar Matjaž, Kokli Jana, Mesojedec Uroš, Oštir Krištof, Potr Matjaž, Robi Borut, Senik Davorin, Simi Slobodan, Toth Jasna, Leksikon raunalništva in informatike: Pasadena, Ljubljana: 2002 [27] Reynolds Matthew, Blair Richard, Crossland Jonathan, Willis Thearon; Visual Basic.NET od zaetka, Ljubljana, Pasadena: 2002 [28] Satzinger W. John, Ovrik U. Tore; The object-oriented approach: concepts, system development, and modeling with UML, Australia, Course Technology Corporation: 2001 [29] Sili Marin, Colnar Marko, Krispet Marjan, Rupnik Rok, Bajec Marko, Rozman Ivan, Heriko Marjan, Domajnko Tomaž, Juri B. Matjaž, Živkovi Aleš, Beloglavec Simon, Kožman Mitja, Novakovi Aleksander, Stanti Mitja, Rubin Samo, Tomaži Roman, Jensterle Rado; Enotna metodologija razvoja informacijskih sistemov Objektni razvoj IS, Ljubljana: Vlada Republike Slovenije Center vlade RS za informatiko, 2000 [30] Slovenski standard SIST ISO 9001:2000, Ljubljana: 2004 [31] UML Applied Object Oriented Analysis and Design Using the UML, Ariadne Training, 2001 [32] Verbinc France; Slovar tujk: Cankarjeva založba, Ljubljana: 1994 [33] Vila Antun; Organizacija v postmoderni družbi, Ljubljana: Moderna organizacija, 2000 [34] Vintar Mirko, Kovai Andrej; Nartovanje in gradnja informacijskih sistemov, Ljubljana: Državno založbo Slovenije, Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 86

93 Viri [1] Alea portal, id=14, [2] Amebisovo skladiše podatkov Slovar slovenskega knjižnega jezika, Amebis d.o.o., 1997 [3] Mitja Plos, Kaj nam prinaša novi standard ISO 9001:2000, Novi_standard_ISO_9001_2000.pdf, MISTRA QMS d.o.o., Ljubljana [4] Oracle Slovenija, [5] Spletna enciklopedija Wikipedia, , [6] Spletna baza podatkov rešenih primerov razlinih programskih jezikov, [7] Spletna stran Centra vlade RS za informatiko, Informacijska_podpora_ dokumentaciji_sistema_kakovosti_na_cvi.rtf, [8] Spletna stran podjetja ISO Navigator Management Systems, ISO_9000_history.htm, [9] Spletni portal, [10] Svetovna knjižnica znanja Masterliness, [11] Toplak Bakan Metka, Urbajs Alojz: Kakovost po ISO 9001:2000, [12] Uradna spletna stran podjetja Visual Paradigm, Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 87

94 Kazalo slik Slika 1: Stroški popravila slabega nartovanja... 3 Slika 2: Hierarhija objektnih jezikov Slika 3: Obiajni življenjski cikel razvoja programskih rešitev po linearnem pristopu Slika 4: Faze inkrementalno - iterativnega razvoja Slika 5: Klasifikacija diagramov UML Slika 6: Diagram primerov uporabe poštnega predala Slika 7: Predstavitev stanja zapisa iz podatkovne zbirke, e je zapis predhodno že shranjen v podatkovni zbirki Slika 8: Diagram sodelovanja za vnos nove skupine dokumentov Slika 9: Diagram zaporedja za shranjevanje ekipe uporabniku Slika 10: Diagram aktivnosti za vnos nove vloge uporabnika Slika 11: Postopek pošiljanja dokumenta, predstavljen s pomojo asovnega diagrama Slika 12: UML omogoa pet razlinih tipov povezav med razredi Slika 13: Razredni diagram aktivnosti v povezavi s seznamom aktivnosti Slika 14: Modul za obvladovanje poslovnih procesov z vidika diagrama komponent Slika 15: Modul za obvladovanja poslovnih procesov v obliki diagrama paketov Slika 16: Razvojni diagram za modul obvladovanja poslovnih procesov Slika 17: Diagram objektov procesa, ki vsebuje enega lastnika in eno aktivnost Slika 18: Demingov krog stalnih izboljšav»nartuj izvedi preveri izboljšaj« Slika 19: Model sistema vodenja kakovosti, osnovan na procesih Slika 20: Klasifikacija tehnik prikazovanja organizacijsko relevantnih informacij Slika 21: Simboli za modeliranje procesov s tehniko diagramov poteka Slika 22: Primer linearne aktivnosti Slika 23: Primer vzporedne aktivnosti Slika 24: Primer razvejane aktivnosti Slika 25: Diagram primerov uporabe za sistem obvladovanja poslovnih procesov Slika 26: Podatkovni model modula za obvladovanje poslovnih procesov Slika 27: Okno za modeliranje poslovnega procesa Slika 28: COM Callable Wrapper objekt Kazalo tabel Tabela 1: Seznam pravic dostopa do dokumenta Tabela 2: Seznam primerov uporabe za celotni modul Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 88

95 Dodatek A V dodatku so predstavljeni koraki uporabljenega življenjskega cikla razvoja programske rešitve, poleg tega pa so prikazani diagrami UML, ki so bili kreirani v posamezni fazi. Življenjski cikel se zane z doloitvijo zahtev konnih uporabnikov, nato sledita fazi analize in oblikovanja, kona pa se s fazo implementacije. V tem delu je predstavljen le postopek pošiljanja dokumentov in so zato prikazani le ti diagrami. V prvem koraku smo skupaj s konnimi uporabniki napisali splošne zahteve, ki jim mora program zadostovati pri pošiljanju dokumentov. Pri obdelavi dokumentov skrbi modul za upravljanje procesov, da naredi dokument celotno pot življenjskega cikla dokumenta. Pri dokumentih, ki imajo vnaprej definirano pot in vnesene vse potrebne atribute, pozna program akcije, ki se morajo zgoditi. V nasprotnem primeru mora uporabnik rono doloiti naslednji korak. Ko uporabnik zakljui aktivnost v procesu ter želi dokument poslati naprej, mora program uporabniku pokazati naslednje možne aktivnosti. Ti so predhodno doloeni v procesu, hkrati pa ima uporabnik tudi možnost pošiljanja dokumenta do poljubnega uporabnika. Druga možnost je pomembna za vse dokumente, ki nimajo tono doloene poti ter za tiste dokumente, ki zaradi okolišin ne gredo po vnaprej doloeni poti. Da se uporabnik lažje odloi za nadaljnji korak, ima možnost vpogleda v trenutno opravljeni poslovni proces, kjer natanko vidi pot dokumenta. Da pa lahko dosežemo stalno spremljanje dokumenta, se podatki o opravljeni aktivnosti shranijo v podatkovno zbirko. Na podlagi opisanih zahtev smo naredili diagram primerov uporabe, tako da smo najprej naredili grafini prikaz primerov uporabe in doloili njihove povezave. Nato smo pripravili posamezne scenarije primerov uporabe. Slika 1: Grafini prikaz primerov uporabe Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 1

96 Pošlji dokument Opis: uporabnik pošlje dokument v naslednjo aktivnost. Zaetno stanje: uporabnik zakljui aktivnost. Konno stanje: uporabnik pošlje dokument. Glavni akterji: uporabnik. Pomožni akterji: - Povod: uporabnik je zakljuil nalogo. Vkljueni primeri uporabe: - Osnovni potek: 1. uporabnik je zakljuil nalogo znotraj aktivnosti in želi poslati dokument v naslednjo aktivnost; 2. uporabnik izbere možnost pošlji dokument; 3. sistem odpre okno za pošiljanje dokumentov; 4. sistem izpiše vse naslednje aktivnosti, ki so doloene v poslovnem postopku; 5. uporabnik izbere naslednjo aktivnost; 6. uporabnik želi doloiti izvajalca naslednje aktivnosti; 7. uporabnik izbere izvajalca; 8. sistem izpiše izvajalca izbrane aktivnosti; 9. uporabnik želi doloiti osebe, ki bodo dobile dokument v vednost; 10. sistem izpiše seznam vseh oseb izbrane aktivnosti; 11. uporabnik izbere osebe, ki jim želi poslati dokument v vednost; 12. sistem izpiše osebe, ki bodo dobile dokument v vednost; 13. uporabnik ima možnost napisati sporoilo, kaj je potrebno narediti pri naslednji aktivnosti; 14. uporabnik pošlje dokument; 15. sistem zakljui trenutno aktivnost in v novi aktivnosti postavi dokument v akalno vrsto; 16. sistem opozori uporabnika, da je dokument uspešno poslan. Pomožni potek: (Uporabnik želi poslati dokument v aktivnosti, ki ni vnaprej doloena) A.5. uporabnik izbere možnost "poljubna aktivnost"; A.6. uporabnik želi doloiti izvajalca naslednje aktivnosti; A.7. sistem izpiše seznam vseh zaposlenih; A.8. uporabnik izbere zaposlenega, ki mu želi poslati dokument; A.9. sistem v seznam izpiše naziv izbranega uporabnika; A.11. uporabnik želi doloiti osebe, ki bodo dobile dokument v vednost; A.12. sistem izpiše seznam vseh zaposlenih; A.13. uporabnik izbere zaposlenega, ki bo prejel dokument v vednost; A.14. sistem v seznam izpiše osebe, ki bodo dobile dokument v vednost; A.15. uporabnik napiše sporoilo, kaj je potrebno narediti v aktivnosti; A.16. uporabnik pošlje dokument; Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 2

97 A.17. sistem zakljui trenutno aktivnost in postavi dokument v akalno vrsto nove aktivnosti in pri tem obdrži zaporedno številko prejšnjega procesa; A.18. sistem opozori uporabnika, da je bil dokument uspešno poslan. Prikaži opravljen proces Opis: uporabnik, ki dobi dokument v obdelavo, želi pogledati pot, ki jo je dokument že opravil v svojem življenjskem ciklu. Zaetno stanje: uporabnik ima izbran dokument, ki je v obdelavi. Konno stanje: uporabnik vidi opravljeno pot dokumenta. Glavni akterji: uporabnik. Pomožni akterji: Sistem za obvladovanje poslovnih procesov. Vkljueni primeri uporabe: - Povod: Uporabnik želi videti pot, ki jo je opravil dokument. Osnovni potek: 1. uporabnik izbere dokument v poštnem predalu; 2. uporabnik zahteva prikaz opravljene poti dokumenta; 3. sistem izpiše v seznam vse korake v kronološkem vrstnem redu, ki jih je opravil dokument. V seznam se izpišejo naslednji podatki: zaporedna številka zapisa; naziv aktivnosti; naziv pošiljatelja; naziv izvajalca; as, ko je dokument prišel v aktivnost; as, ko je dokument zapustil aktivnost; predviden as izvedbe. Pošlji opozorilo o zastoju Opis: pri vsaki aktivnosti procesa ima administrator možnost doloiti, kolikšna je kritina koliina dokumentov znotraj posamezne aktivnosti. e število dokumentov preseže to število, pošlje sistem lastniku procesa opozorilo o kopienju dokumentov v posamezni aktivnosti. Zaetno stanje: uporabnik pošlje dokument v naslednjo aktivnost. Konno stanje: sistem pošlje opozorilo lastniku procesa, da se v aktivnosti kopiijo dokumenti. Glavni akterji: sistem za administracijo procesov. Pomožni akterji: - Povod: dokument pride v novo aktivnost v procesu. Osnovni potek: 1. uporabnik pošlje dokument v novo aktivnost procesa; 2. sistem preveri koliko dokumentov je trenutno aktivnih; Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 3

98 4. sistem preveri kolikšna je kritina koliina dokumentov; 5. sistem primerja koliino dokumentov v procesu in kritino koliino; 6. sistem pošlje administratorjem procesa opozorilo o kopienju dokumentov. Pomožni potek: kritina koliina ni doloena A.4. aktivnost procesa nima doloenega minimalnega števila dokumentov; A.5. sistem za administracijo procesov ne more poslati opozorila o zastoju. Pomožni potek: koliina dokumentov v procesu je manjše od kritine koliine B.5. koliina dokumentov v aktivnosti je manjša kot je doloena kritina koliina; B.6. sistem zapusti proceduro. V naslednjem koraku smo kreirali diagram razreda in doloili osnovne lastnosti ter metode razredom. Slika 2: Diagram razredov za pošiljanje dokumentov Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 4

99 Nato je bilo potrebno za postopek pošiljanja dokumentov narediti podroben nart, kako bo potekalo pošiljanje dokumentov. Zato je smiselno uporabiti kakšnega od UML vedenjskih diagramov, kot so diagram zaporedja, diagram sodelovanja ali asovni diagram. Zaradi preglednosti in vejega števila razredov, ki so vkljueni, smo v tem primeru naredili diagram zaporedja, medtem ko smo za pošiljanje opozorila o zastoju naredili diagram sodelovanja. Za tabelarini izpis opravljenega procesa se zaradi enostavnosti postopka nismo odloili za izdelavo detajlnega diagrama. Slika 3: Diagram zaporedja za pošiljanje dokumentov Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 5

100 Slika 4: Diagram sodelovanja prikazuje potek pošiljanja opozorila o zastoju Pripravljeni diagrami so bili osnova za pisanje programske kode razredov. Celotno programsko kodo smo rono vnesli v razvojni program Visual Studio Vzporedno s pisanjem programske kode smo pripravili tudi entitetno relacijski model in strukturo tabel v podatkovni zbirki MS SQL Server Slika 5: Podatkovni model tabel za vodenje procesov Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 6

101 Pripravljene domenske in procesne razrede smo vkljuili v razrede uporabniških vmesnikov in zaeli testirati nove segmente programa. Zaradi preobsežnosti programske kode so predstavljeni le uporabniški vmesniki, ki se uporabljajo za pošiljanje dokumentov. Slika 6: Uporabniški vmesnik za pošiljanje dokumentov Slika 7: Uporabniški vmesnik za doloitev izvajalca aktivnosti Aleš Gregori Razvoj objektno zasnovane programske rešitve za obvladovanje poslovnih procesov 7